개발 작업을 시작 할 때 에디터 열고, 소스 코딩 부터 하는 개발자들을 종종 볼 수 있다. 특히 주니어 개발자들에게서 많이 볼 수 있는 모습이다. 일필휘지로 술에 취한 듯 코딩하고, 단번에 컴파일되어 에러 없이 돌아가는 프로그램이 개발자들의 로망임을 이해 못하는 바는 아니나, 여기에는 몇가지 문제가 있다. 이 이야기를 조금 해보려고 한다.

‘공돌이의 글은 두괄식으로’ 라는 말 대로 결론부터 말하자면, 코딩 하기 전에 데브플랜 써보는 습관을 가져야 한다. 가장 큰 이유는 협업 때문이고, 두번째는 베이비스텝 때문이다.

데브플랜을 쓰게 되면 개발 방향에 대한 빠른 공유가 가능하다. 코딩 전 작성된 데브플랜을 통해 동료들의 리뷰를 가능한 이른 시점에 받아 볼 수 있다. 동료들 중에 비슷한 일을 이미 해봤거나, 과거에 작업했던 코드들을 활용해서 개발 과정에서 혹시라도 중복되어 발생할 작업들을 사전에 처리할 수 있다. 또한 주어진 태스크가 너무 큰 경우, 이를 쪼개어 다른 동료와 협업을 진행할 수 있다.

또 데브플랜을 쓰게 되면 스스로 가지고 있는 인지편향을 바로 잡을 수 있는 장점도 있다. 개발 계획 상에 스스로 내린 의사결정들에 대해 객관적으로 돌아볼 기회가 생긴다는 말이다. 개발상에서 인지편향은 다양한 형태로 나타나게 되는데, 예를 들어 특정 프레임웍에 너무 강력한 호감을 느낀 나머지 실제 문제 해결보다도 큰 범위로 일을 처리하는 걸 예로 들 수 있다. 기술사용 그 자체가 목표가 되어 버린 경우이다.

리스크 관리를 체계적으로 할 수 있다는 장점도 있다. 데브플랜을 쓰다보면 자연스럽게 검증해야할 것들이 생겨나게 된다. 귀찮음 등으로 당연히 그럴꺼야 하고 넘어간 작은 부분들의 사실관계가 달라지면 전체 설계에도 영향을 미친다. 약간 더 시간이 걸리더라도 신중을 기할 수 있는 기회가 생기고, 각 검증요소들이 실패할 경우 대안에 대해서도 앞당겨 생각해 볼 수 있다.

무엇보다 개발자 본인에게 가장 큰 장점은 어려워 보이는 일을 차근차근 밀고 나갈 힘을 만들어 준다는 것이다. 한번에 너무 크게 발을 딛으려고 하면, 실패할 확률이 높아진다. 보폭을 작고 짧게 만들어 진행하는 연습을 해야한다. 이를 베이비스텝이라고 하는데, 데브플랜은 베이비스텝을 딛을 수 있도록 도와주는 훌륭한 도구다.

자 그럼 이제 데브플랜을 써보자. 데브플랜 쓰는 정해진 형식은 없다. 이메일이나 필요하다면 도형등을 첨부할 수 있는 워드나 구글닥스 같은 것들도 괜찮다. 리뷰를 받고 코멘트를 남겨줄 수 있는 형태면 무엇이든 상관 없다. 다만 작성했던 데브플랜들을 보관해서 나중에라도 다시 한번 볼 수 있으면 더욱 좋을 것이다.

데브플랜에 담아야 하는 내용에도 역시 정해진 바는 없으나 최소한 다음과 같은 것들은 포함하는 것이 좋다.

• 문제 설명 : 주어진 과제에 대한 설명을 쓴다.
• 문제 분석 : 문제가 일어난 원인에 대해 분석한다.
• 요구 사항 : 문제 해결에 필요한 기타 요구사항을 한 문장 단위로 명확하게 쓴다.
• 디자인 : 어떻게 문제를 해결할 것인지 쓴다.
• 테스팅 : 해결책이 잘동작하는 지 어떻게 검증할 것인지 쓴다.
• 일정 : 주어진 과제의 마감일 또는 중요 마일스톤에 대해 쓴다.

이 정도만 정리되어도 훌륭한 데브플랜이다. 문서의 가장 중요한 내용들은 디자인 항목에 들어갈 것이다. 그러자면 충분한 문제 설명과 분석이 뒷받침되어야 한다. 문제분석에 시간을 많이 쓸 수록 좋은 디자인이 빠른 시간 안에 나온다. 이 외에도 검증해야될 이슈들 목록을 함께 정리해두는 것도 좋다.

아마 초급 개발자들은 데브플랜을 쓰는 것에 익숙하지 않을 것이다. ‘새 문서’ 버튼을 눌러 하얀 화면을 열어 놓고 진행을 못하는 일을 겪을 것이다. 그럴 때는 위의 항목들을 복사해서 채워넣기 해보는 것이 도움이 된다. 다음과 같은 구체적인 질문을 던져보면 좋을 것이다.

• 지금 해결하고자 하는 버그는 무엇인가? 기대했던 동작은 무엇인고, 실제 동작은 무엇인가?
• 버그로 인한 고객의 피해는 어느 정도인가?
• 버그의 원인은 무엇인가? 그 원인이 일어난 근본 원인은 또 무엇인가?
• 원인은 코드에 있는가? 사람에 있는가? 프로세스에 있는가?
• 내가 고칠 수 있는 문제인가?
• 기대했던 동작을 이루기 위해 가장 적절한 방법은 무엇인가?
• 해결책에 불필요한 변경사항이 있진 않은가?

데브플랜은 질보다 양이고, 개발 과정에서 실패하고 실수한 내용들을 솔직하게 적는 노트이다. 데브플랜은 결과물로서 누군가에게 제출되는 것이 아니고, 좋은 코드를 만들기 위한 중간 과정으로서 작성되는 부산물일 뿐이다. 하지만 효과적인 공유를 위해 꼭 필요한 부산물이다.