개발 프로젝트에서 기획과 프로세스는 얼마나 중요한가?

아니 왜? 끝까지 못 달릴까?

졸업 작품을 시작으로 개발 업계에 발을 들인 지 5년, 이제 1인 개발자로 홀로서기를 준비하면서 그 동안 내가 진행했던 프로젝트들을 돌아봤다.

결과는 매우… 수치스러웠다.

회사 및 프리랜서 프로젝트 완주율: 100%
개인 프로젝트 완주율: 5% 미만

타인의 돈이나 계약이 걸린 프로젝트는 어떻게든 끝을 보았으나, 온전히 나의 의지로 시작한 개인 프로젝트는 대부분 끝까지 달리지 못했다. 특히 2개 정도는 진짜 마무리만 하면 끝나는 수준이었는데, 그 마무리를 하지 못하고 덮어졌다.

천천히 생각해봤다.

아니 왜? 왜 실패했을까?

곰곰히 생각해서 내가 도출한 실패의 원인은 코딩 실력이 아닌 기획의 부재와 관리의 부재였다.

초반에 아무리 좋은 동기로 팍! 치고 나가면 뭐하나, 결국에 후반에는 그 동력을 잃고 나자빠지는데…

특히나 신나게 코딩을 하다가 마무리 부분 정도 됐을 때, “이제 뭐 해야하지?” 를 몰라서 방황하다가 결국엔 방치하거나 혹은 설계의 문제를 코드를 다 짜놓고 깨달았을 때는 돌아가서 다시 시작할 연료가 없었다.

이를 깨닫고, 이번 프로젝트에서는 코딩 보다는 철저한 문서 기반의 개발(Documentation-Driven Development)과 1인 Agile 프로세스를 중심으로 뒀다.

이게 꽤나 충격적이게도 잘 먹혀서…

이 글에서는 그 과정과 구체적인 방법론을 공유하고자 한다.

개발 문서는 왜 이 순서여야만 하는가?

기획 문서는 단순히 개발할 내용을 적어두는 메모가 아니다.

앞 단계의 문서가 뒷 단계 문서의 근거가 되는 논리적 상호 의존성(Logical Dependency)을 가지며, 이는 꽤나 절대적이고, 효율적이기 까지 하다.

나는 이렇게 진행했다.

Phase 1. 추상적 아이디어의 구체화

가장 먼저 [사업 기획서]를 작성했다.

뭐 아무것도 아닌 토이 프로젝트라도 이걸 작성하면서 제작 의도, BM, 핵심 타겟(페르소나)을 정의해놓지 않으면 중간에 길을 찾을 수가 없다.

그리고나서 이를 기반으로 [요구사항 정의서]를 도출했다.

기획서에 ‘편리한 회원가입’이 있다면, 정의서에는 ‘카카오 소셜 로그인 기능’이라는 구체적 기능이 명시되는 것이다.

Phase 2. 스코프와 데이터의 확정 (Screen & Data)

요구사항이 나오면 Screen IDentify를 통해 필요한 화면의 개수를 확정해야 한다. 사용자가 어떤 화면을 봐야 하는 지를 먼저 정의를 해놓고 가는게 편하다.

마치 물 길을 미리 만들어 놓는 느낌이다.

화면 목록이 나와야 비로소 데이터가 흐르는 길이 보인다.

이를 토대로 [엔티티 명세서]와 [DB 테이블 명세서]를 작성할 수 있다.

화면 구성 요소와 기능 목록이 확정된 상태에서의 데이터 모델링은 수정 소요를 획기적으로 줄여주며, 정규화의 기준이 명확해진다.

Phase 3. 시각화와 검증 (UI/UX & Scenario)

DB 구조가 잡히면 [화면 기획서(SB)]를 그린다.

이미 데이터 구조가 잡혀있기에 “이 데이터는 어디서 가져오지?”라는 고민이 없으니, 그냥 예쁜 UI 편리한 UX 만들기에 집중할 수 있다.

이후 만들어진 화면 기획서에 이리 저리 선을 그으며 유저 스토리보드를 짤 수 있다.

[유저 스토리보드]를 통해 페르소나가 실제 서비스를 이용하는 시나리오를 시뮬레이션하며, 이 과정에서 기획의 논리적 허점이 대부분 발견된다. (이 기획의 논리적 허점이 바로 내가 매번 개인 프로젝트를 엎어 먹는 가장 큰 걸림돌이었다.)

Phase 4. 개발 계약 수립 (Interface)

마지막으로 [API 명세서]를 작성한다. 앞선 모든 문서(화면, DB, 시나리오)가 완료되었기에, 프론트엔드와 백엔드가 주고받아야 할 데이터의 형식이 명확하고, 그저 “엑셀로 하는 코딩”을 진행하면 된다.

Insight: 이 순서를 지킴으로써 얻은 가장 큰 이점은 재작업의 최소화다. API를 먼저 짜고 화면을 그렸다면, 화면이 바뀔 때마다 API를 뜯어고치고, 새롭게 생각나는 컬럼이 있으면 또 파일 몇 개를 뜯어야 한다. 상위 설계가 하위 설계를 통제하는 구조가 확립되자, 개발 속도는 체감상 20~30배 빨라졌다.

3. 1인 Agile: 나를 객관화하는 시스템

기획이 완벽해도 실행이 따라주지 않으면 무용지물. 개인 프로젝트의 가장 큰 적은 ‘나태함’과 ‘타협’이다. “아, 이번 달까지만 하면 되지 뭐…”는 망함의 지름길이다. 이를 통제하기 위해 회사와 동일하게 Jira를 도입하고 스스로를 PL이자 개발자로 분리하는 1인 Agile 체제를 시험해봤다.

1) 스프린트(Sprint) 주기 설정

목표 없는 개발은 늘어지기 마련. 1주 단위의 스프린트를 설정하고, 해당 기간 내에 처리할 수 있는 티켓(Task)의 총량을 산정했다. “언젠가 하겠지”가 아니라 “이번 스프린트 안에 끝낸다”는 마감 기한의 압박을 스스로에게 부여했다.

2) 모닝 셀프 스탠드업 (Self-Standup)

매일 아침 개발 시작 전, 당장 할 일이 있어도 잠시 멈추고 커피 한 잔을 마시며 Jira 보드를 띄워두고 스스로와 미팅을 한다.

“어제 하다가 막힌 이슈(Blocker)는 무엇인가?”
“오늘 처리할 티켓은 무엇인가?”
“일정이 지연되고 있다면 우선순위를 어떻게 재조정할 것인가?”

이 짧은 의식(Ritual)이 은근히 내가 무슨 CEO가 된 것마냥 만족감이 있고, 곧 바로 앉아서 일하는 것보다 일의 효율을 증가시켜준다.

3) 이슈 트래킹의 시각화

단순한 버그 수정부터 기능 구현까지 모든 작업을 Jira 티켓으로 생성했다. (진짜 사소한 UI CSS 뜯어 고치는 것까지.) To Do -> In Progress -> Done으로 카드가 넘어가는 시각적 피드백은 1인 개발자에게 큰 성취감과 동기부여를 제공한다. 티켓의 총량이 있으니 카드 몇 개 깔짝대고 만족해서 쉬러가지도 못한다.

또한, 개발 도중 발생하는 기획 변경 사항을 단순히 머리로 기억하는 게 아니라 티켓에 기록함으로써 프로젝트의 히스토리를 관리했다. (이 보고서가 은근히 나중에 봤을 때 동기부여가 된다. Gemeni한테 던지고 칭찬 받기도 좋고)

4. 결론: 개발은 코딩이 아니라 설계와 관리다

이번 프로젝트를 통해 뼈저리게 느낀 점은, 성공적인 프로젝트 완료는 키보드 위에서가 아니라 키보드를 잡기 전의 책상 위에서 결정된다는 사실이다.

체계적인 문서화는 개발의 네비게이션이 되어주었고, Jira를 활용한 Agile 프로세스는 나를 계속해서 모니터 앞으로 이끌었다.

이제 배포를 목전에 두고 있는 상황에서, 이 경험은 앞으로 내가 나아갈 1인 개발자로서의 홀로서기에 좋은 무기가 될 것 같다.

프로젝트의 성공을 원한다면, 코드를 치기 전에 먼저 설계를 하고, 시스템을 구축해라.

300km로 달리기만 하면 뭐하나, 네비가 있어야지.

마침.