독서: 개발 프로세스에 관하여, 애플리케이션 계층 개발, 에러

오늘은 오랜만에 친 누나가 집에 놀러왔다. 누나는 나보다 먼저 IT 업계로 커리어 변경을 해서, 개발자가 되기 이전 이런저런 관련된 이야기를 해주었었다. 최근에는 퍼블리싱에서 이제는 개발자로서 일한다고 이야기를 했었다. 이 이야기를 생각해보면, 내가 취업하기 직전에 이야기를 했었으니, 벌써 1년이나 되었다.. 시간이 정말 빠르다.

 

무튼 오늘은 누나와 개발 관련된 이야기를 많이 나눴다. 지금 가진 이슈는 무엇이 있는지, 기술 스택은 어떤것을 사용하고 있는지, 어떤 공부를 하고 있는지 등등.. 다방면으로 이야기를 많이 나눴다. 그리 이야기를 나눌수록 복잡 미묘한 감정을 느꼈다. 현실이라는 단어가 참 무섭게 느껴졌다. 현실이 뭐길래.. 분명 개발자가 되고 싶다했던 누나였는데, 개발자가 자기랑은 안맞는 직업인것인가 심각하게 고민을 하고 있다고하니.. 조금은 속상하기도 했다..

 

이야기하고, 외식을 하다보니 오늘은 개발을 많이 하지 못했다. 얼마 하지는 못했지만 오랜만에 가족 다같이 외식을 했기에 나는 만족한다!

---

독서: 개발 프로세스에 관하여

 

나는 최근 개발 프로세스에 대한 고민이 많다. 좀 더 정확히는 개발 속도에 대한 고민이 많다. 특히, 언제까지 해당 기능(계층)을 개발 완료하겠다 다짐했지만, 자꾸만 밀리는 일정이 고민이 된다. 이 부분은 모든 개발자의 고민이라고 생각한다.

 

이전 회사에서 가장 어려웠던 부분은 기능개발 기간을 지정하는 것이었다고 말할 수 있다. 개발일정에 있어, 기간을 정해놓는 것은 당연한 것인데, 이것이 어려웠다. 당시 사수님의 조언은, "개발하다보면 감이생긴다.", "지금 생각하는 일정에 1주일을 더해라" 를 이야기해주셨었다. 그리고 나는 "그래, 나는 경험이 없으니깐 이는 당연한거야" 하는 자기합리화를 하게됬다.

 

시간이 지나 지금, 이 방법들은 문제가 많다고 생각한다. 가장 심각한 문제는 "감"이다. 감이라는 것은 명확하고 객관적인 기준이 되지 못한다. 그럼에도 불구하고 나는 지금까지 모든 일정을 감으로 설정했다.

 

나는 이 문제를  해결하기 위해선 어떻게 해야할까? 고민을 했다. 처음에는 일정을 조금 더 세분화하여, 하루 목표치를 세웠다. 하지만 이것은 여전히 문제를 해결하지 못했다. 오히려 악순환을 가져왔다. 하루 목표를 마치지 못하면 잠을 자지않아, 다음날 개발에 영향을 주었다. 그래서 나는, 개발실력이 문제의 원인이라 생각했다. 이는 현실적으로 맞는 말이다. 그런데 개발실력이 어떻게 일정을 정하는데 기준이 될 수 있는거지? 하는 생각이 들었다. 개발실력이 일정 내에 개발을 마치지 못한 문제의 원인이 될 수 있으나, 개발 실력을 키운다해도 일정을 세우는데 기준이 될 수 없음을 알게되었다.

 

그렇다면 어떻게 해야 일정을 어떻게 계획해야 할까? 나는 깊은 고민과 부담을 항상 갖게되었다. 그리고 이 문제의 답에 대한 힌트를 전혀 생각지 못한 곳에서 얻을 수 있었다.

 

---

점진/반복적인 스크럼 생명주기

 

나는 매일 소프트웨어 관련 독서를 하는 루틴이 존재한다. 그리고 이 루틴 덕에 내가 생각하는 문제 해결의 힌트를 얻을 수 있었다.

 

독서를 하다, 점진/반복적인 스크럼 생명주기 에 대한 섹션을 읽게되었다. 나는 애자일, 스크럼을 들어본적은 있으나, 실제 업무에 적용을 해본적은 없다. 단순히, 스크럼을 통해 매일 자기가 할 작업을 공유한다..? 정도만 알고있었다.

 

해당 섹션의 내용을 인용하면 다음과 같다.

기본 생명 주기는 스크럼의 스프린트를 활용한다. 스프린트는 스크럼의 점진, 반복적인 생명주기이며, 보통 1~4주동안 실행된다. 백로그는 일감 목록을 기반으로 각 스프린트에 일감이 배분되어 진행되며, 매 스프린트마다 실제로 동작하는 소프트웨어를 시연하고 피드백을 얻는다.

* 백로그(BackLog): 시스템의 모든 요구사항

그리고 나는 스크럼의 주요 개념들 중, 스프린트 계획 수립 과정에서, 속도라는 개념을 알게되었다.

스프린트 계획 수립 단계: 시스템의 모든 요구사항은 제품 백로그에 담긴다. 그 다음 일정에 맞게 스프린트를 몇번 수행할 것인가 결정한다. 스프린트 횟수가 졀정되면 제품 백로그에 담긴 백로그를 각 스프린트에 적절해 배분한다. 스프린트가 종료되면 백로그 완료 일감을 기준으로 팀의 생산성이 결정되며, 이를 속도라고 부른다.

 

지난날을 돌이켜 볼 때, 나는 개발일정에 대한 계획은 있었으나, 개발 완료 후, 이에 대한 피드백을 하지 않았다. 단지, 개발이 일정보다 많이 밀렸다.. 정도의 문제 인식뿐이었다. 속도를 통해, 다음 개발 계획을 세워야하는데, 개선 없이 문제를 계속 반복했던 것이다.

 

속도에 맞춰 다음 스프린트 계획을 세우는 과정을 지속적인 계획(Continuous Planning) 이라 한다. 그리고 이것이 내 고민의 답이 될 수 있을 것이라 생각하게 되었다.

 

고정된 계획과, 지속적인(적응적) 계획

 

지속적인 계획(Continuous Planning) 은 기존의 고정된(fixed) 계획이 아니라 적응적(adaptive 계획을 말한다. 고정된 계획은 범위가 고정되어 있고, 일정 비용, 품질 이 그에 맞춰 유동적으로 움직인다. 반면, 적응적 계획은 일정, 비용, 품질이 고정돼 있고 그에 따라 범위가 조정되는 것을 말한다.

 

즉, 지속적인 계획을 하게된다면, 할 일의 우선순위를 정하게 되고, 우선순위가 높은 핵심 기능에 집중할 수 있게 된다.

 

나는 지금까지 전통적인 일정관리, 범위에 맞춰진 개발을 하면서, 적응적 계획을 하고자 하고 있었다. 계획에 우선순위를 부여하고, 지금 개발해야할 것을 정해두었지만, 개발 속도에 따라 일정을 조정하지 않았다.

 

앞으로는 문제에 대한 피드백을 좀더 적극적으로 해볼 수 있도록 노력해야겠다.

 

 

---

애플리케이션 계층 개발, 에러

 

오늘은 계속해서 애플리케이션 계층을 개발했다. 언제나 그렇듯, 흐름을 그린 뒤, 호출하는 메서드 인터페이스를 만들어놓고테스트코드를 작성하여 이를 구현했다. 그런데 개발 과정 중 문제가 발생했다.

 

 

자꾸만 실패하는 테스트, initializationError 가 발생했다.

해당 OrderCreateHelper 클래스를 작성하면서, 문제가 발생했다. OrderRespository를 포함한 OutPorts 인터페이스를 모두 찾지 못한다는 에러를 뱉었다. 해당 인터페이스를 Component 로 등록하고서 테스트를 실행해보았지만, 여전히  처음에는 IDE가 또 맛탱이가 갔나 하는 마음에 껏다켜보았지만 IDE문제는 아니였다.

 

자꾸만 OrderRepository 를 찾지 못한다. 뿐만아니라, 다른 Ports(인터페이스)를 찾지 못했다.

클래스를 잘못읽어오나? 경로를 확인했지만 이 또한 문제의 원인은 아니였다. 결국 외식 전까지 해결하지 못하고, 밥먹으면서 계속 문제의 원인을 고민해보았다.

 

---

원인: TestConfig 설정 문제

 

원인은 TestConfig 설정이었다. 나는 밥을 먹고 와서도 이를 해결하지 못했다. 그리고 오늘 기록을 남기는 순간까지도 해결하지 못했다. 작성한 클래스를 다시 다 삭제했다 다시 해보기도 하는 삽질도 했다. 하지만 삽질은 삽질일 뿐, 침대에 누워야할 때 까지 해결하지 못했다. 새벽 2시가 넘도록 내가 무엇을 놓쳤을까 고민을 해보았다. 아무리 책상에서 생각해도 모르겠어서, 결국 누웠다가, 문제의 원인이 침대에서 생각이 났다.

 

TestConfiguration 클래스, 나는 테스트 관련하여 설정을 따로 하고 있다.

 

나는 테스트 설정을 하지 않았다. 그래서 테스트를 실행할 때 에러가 발생했던 것이다. 설정을 등록하고서 문제는 해결이 되었다...

지금시간 새벽 3시30분.. 살짝 현타가 온다..

 

나.... 바본가.....