3개월짜리 터널 프로젝트는 비즈니스 애플리케이션을 망치는 가장 좋은 방법입니다.

계획하고, 개발하고, 마지막에 보여줍니다. 그리고 마침내 사용자가 비용이 많이 드는 문장을 말합니다. '아, 하지만 저희는 이렇게 하지 않는데요.'

다음은 이를 피하기 위해 사용하는 분할 방식입니다. 혁신적인 것은 아니지만, 결과물을 바꾸는 몇 가지 구체적인 규칙들이 있습니다.

수직적 조각(Tranche Verticale)의 원칙

배포 가능한 조각은 전체 스택을 가로지릅니다: 데이터베이스, 로직, 인터페이스. 실제 사용자가 처음부터 끝까지 사용할 수 있어야 합니다.

이는 '전체 DB'를 만든 다음 '전체 API'를 만들고 마지막에 '전체 프론트엔드'를 만드는 계층별 분할 방식의 반대입니다. 이 방식은 끝날 때까지 테스트 가능한 결과물을 아무것도 만들어내지 못합니다.

❌ 1주차: 전체 DB 스키마
❌ 2주차: 모든 API 라우트
❌ 3주차: 모든 화면

✅ 1주차: 주문을 생성하고 목록에서 확인하기 — 화면 포함
✅ 2주차: 수정하고 상태 변경하기
✅ 3주차: 검색 및 필터링

첫 주가 지나면, 누군가가 도구를 열고 실제로 무언가를 할 수 있습니다. 바로 이때 진짜 피드백이 올라옵니다.

파일 하나에 담는 명세서(Spec) 형식

각 조각은 하나의 파일을 가집니다. 항상 같은 구조를 가지며, 팀뿐만 아니라 코드 어시스턴트에게도 유용합니다.

# Tranche 03 — 주문 상태 변경

## 사용자가 할 수 있는 것
...

범위 외(Hors périmètre) 섹션이 가장 많은 작업을 수행하게 만듭니다. 이는 프로젝트가 제대로 관리되지 않을 때 흔히 발생하는 추가 부하의 30~50%를 차지하는 범위 확장(glissement de périmètre)을 방지합니다.

완료 시점(Fini quand) 섹션은 '완료'가 무엇을 의미하는지에 대한 또 다른 전형적인 의견 불일치를 방지합니다.

이 형식이 코드 어시스턴트와 잘 작동하는 이유

우리는 일상적으로 Claude Code를 사용합니다. 이 파일 형식은 가장 좋은 결과를 제공하는데, 그 이유는 간단합니다. 어시스턴트는 컨텍스트가 암묵적일 때 실패하기 때문입니다.

명문화된 비즈니스 규칙("관리자 외에는 되돌리기 불가")은 처음부터 올바른 코드를 생성합니다. 하지만 같은 규칙을 프로젝트 매니저의 머릿속에만 남겨두면, 그 결과물은 그럴듯하지만 틀린 코드입니다.

'범위 외(Out of Scope)'를 지정하는 것은 유용한 부작용이 있습니다. 그것은 어시스턴트가 앞서 예측하는 것을 막아주기 때문입니다. 이 섹션이 없다면, 논리적으로 보인다는 이유만으로 스팸성 이메일 알림을 자발적으로 추가하며, 결과적으로 아무도 요청하거나 검토하지 않은 코드를 받게 됩니다.

절대 타협할 수 없는 한 가지는 '완료 시점(Done when)'의 기준이 승인되기 전에 테스트 케이스가 된다는 점입니다. 2026년에 발표된 분석에 따르면, AI가 생성한 코드 중 최소 하나 이상의 취약점을 포함하는 것이 약 45%에 달합니다. 이 수치가 도구를 단죄하는 것은 아니지만, 인간의 검토가 어디에 필요한지 상기시켜 줄 뿐입니다.

트랜치(Tranche) 순서가 중요한 이유

우리는 항상 다음 순서로 분류해야 합니다:

1. 사용성을 증명하는 트랜치. 이 부분이 설득력이 없으면 전체 프로젝트가 무효화됩니다. 따라서 예산이 남아있을 때 가장 먼저 진행되어야 합니다.
2. 기술적 위험 트랜치. 기존 시스템과의 통합, 지저분한 데이터 가져오기(import), 문서화가 미흡한 타사 API 등이 해당합니다. 절대로 마지막에 와서는 안 됩니다.
3. 편의 기능(Comfort). 필터, 내보내기(export), 대시보드 같은 기능들입니다. 유용하지만, 4주 차에 이런 기능이 없다고 해서 프로젝트가 망하는 일은 없습니다.

흔한 실수는 '기본'이라는 이유로 인증 및 계정 관리를 먼저 시작하는 것입니다. 이는 흥미로운 것을 보여주기까지 세 주나 걸리는 시간입니다. 초기 단계에서는 최소한의 인증만으로 충분합니다.

구체적으로 달라지는 점

이점은 순수한 속도가 아닙니다. 잘못된 범위 설정(scoping error)에 대한 비용을 3개월 대신 일주일 만에 지불할 수 있다는 것입니다.

표준 비즈니스 애플리케이션의 경우, 사용 가능한 첫 번째 버전이 6주에서 10주 사이에 나올 수 있으며, 두 번째 주부터 사용자 피드백을 받을 수 있습니다.

무엇보다 중요한 것은, 고객이 "우리는 이렇게 하지 않습니다"라고 말하는 날에 그 비용이 거의 들지 않을 만큼 일찍 알게 된다는 것입니다.

프로젝트의 전체 단계, 실제 일정 및 예산은 여기에서 확인하세요: 맞춤형 애플리케이션 제작하기.