소프트웨어 개발 순서를 적어 두면 기획서, 기술요구서, 개발계획서, 개발 스펙으로 깔끔하게 이어진다. 그런데 이 순서가 있는 이유는 문서를 다 갖추기 위해서가 아니라, 되돌리는 값이 싼 자리에서 먼저 틀려 보기 위해서다.
그래서 순서표에서 제일 중요한 칸은 무엇이 나오느냐가 아니라 “여기서 멈출 수 있나”다. 멈출 수 없는 단계는 단계가 아니라 그냥 일정이다. 아래는 계약과 발주가 붙는 프로젝트를 기준으로 잡았고, 혼자 AI에게 시켜 만드는 경우의 순서는 바이브코딩으로 웹 게임 만들기에 따로 적어 뒀다.
순서를 지키면 무엇이 달라지나
늦게 발견할수록 값이 비싸진다. 기획서 한 줄을 고치는 값과, 이미 일 년 치 자료가 쌓인 시스템의 데이터 모델을 바꾸는 값은 자릿수가 다르다.
영국 정부가 공개한 GOV.UK 서비스 매뉴얼은 이걸 대놓고 적어 뒀다. 알파 단계의 핵심은 “제일 위험한 가정을 찾아 시험하는 것”이고, 이때 쓴 코드는 “알파가 끝나면 버릴 것으로 예상하라”고 한다. 더 중요한 문장은 그다음이다. 디스커버리가 끝난 뒤에 알파를 할 가치가 없다고 판단해도 괜찮다고, 알파가 끝나고도 자신이 없으면 아예 멈추거나 앞 단계를 다시 해도 된다고 적혀 있다. 멈춰도 된다는 말이 공식 문서에 있는 것, 그게 단계를 게이트로 만든다.
권리 검토를 왜 기획서보다 앞에 두나
여기서 막히면 아래가 전부 무의미해지기 때문이다. 저작권과 라이선스, 개인정보, 그리고 만들려는 산출물이 어느 정도 규모인지. 이 셋은 기획서를 기다릴 이유가 없으니 첫날부터 같이 굴린다.
문서에 적힌 권리와 실물의 권리가 다를 수 있다는 것도 여기서 확인한다. 폰트 만들기 사이트를 살펴보다가 Metaflop에서 폰트를 하나 내려받아 파일 안을 들여다본 적이 있다. 사이트 안내에는 OFL 1.1이라고 적혀 있었는데, 실제 OTF 파일 안 문자열은 GPL v3과 OFL 1.1 이중이었고 예약 폰트 이름 조항까지 붙어 있었다(2026년 7월 확인). 폰트 한 벌에서 그랬다. 남의 자료를 수천 건 모아 쓰는 프로젝트라면 이건 나중에 할 확인이 아니다.
PoC는 무엇을 적고 시작하나
검증할 항목, 성공 기준, 기간, 예산. 여기까지는 대개 적는다. 빠지는 칸은 하나다. 기준에 못 미쳤을 때 무엇을 할 것인가.
성공 기준만 적고 시작하면 숫자가 나온 다음에 기준이 움직인다. 90%를 보려고 했는데 74%가 나오면 “초기치고는 괜찮은데요”라는 말이 회의에서 나온다. 아주 틀린 말도 아니라서 반박이 어렵다. 범위를 줄일지, 각도를 바꿀지, 접을지를 숫자 보기 전에 적어 두면 그 대화가 아예 안 생긴다. 판정할 사람이 누구인지도 같이 적어 둔다.
재는 항목은 프로젝트마다 다르다. 한 건 처리하는 데 드는 비용, 사람이 손대야 하는 시간, 같은 입력에 같은 결과가 나오는지, 제일 오래 걸릴 때 얼마나 걸리는지 같은 것들이다. 나중에 계약서와 일정표에 들어갈 숫자를 여기서 미리 만든다고 보면 된다.
왜 자료가 아니라 실측인가
읽은 숫자와 직접 잰 숫자가 자주 어긋나서다. GIF 사이트 다섯 곳을 비교하면서 Gifer에서 같은 클립을 두 형식으로 받아 본 적이 있다. GIF 파일은 18,368,428바이트였고, 그 페이지가 실제로 재생하고 있던 MP4는 244,984바이트였다(2026년 7월 직접 내려받아 확인). 75배다. 어느 소개 문서에도 안 적혀 있었고 눌러 봐야 나왔다.
PoC에서 나온 숫자가 나중에 일정과 예산의 근거가 된다. 그래서 “되긴 되더라”로 끝나면 PoC를 한 게 아니라 데모를 한 것이다.
일정과 예산은 언제 확정하나
PoC 숫자가 나온 다음이다. 그 전에 적은 일정은 예측이 아니라 희망이다.
요구사항을 확정하는 일 자체가 본 개발과 분리될 수 있다는 건 우리나라 법에도 적혀 있다. 소프트웨어 진흥법 제44조는 발주할 때 요구사항을 상세하게 작성해 공개하라고 해 두고, 그 상세한 요구사항을 쓰기 위해 “별도로 분석 또는 설계사업을 분리하여 발주할 수 있다”고 이어 붙였다(2025년 4월 23일 시행판 기준).
확정한 다음에 요구가 바뀌면 어떻게 하나. 같은 법 제50조가 과업심의위원회를 두게 하는데 심의 사항이 두 개다. 과업 내용의 확정, 그리고 과업 내용 변경의 확정과 그에 따른 계약금액·계약기간 조정. 확정과 변경이 같은 자리의 두 안건이다. 바꾸지 말라는 게 아니라 바꾸면 돈과 기간도 같이 움직인다는 뜻이고, 법이 안 걸리는 사내 프로젝트에도 그대로 옮겨 쓸 만하다.
개발이 끝나면 무엇이 남나
오픈, 그리고 운영 이관이다. 순서표가 개발과 시험, 내부 파일럿에서 끝나면 그다음이 아무의 일도 아니게 된다.
필요한 건 셋이다. 장애가 났을 때 누가 무엇을 하는지 적은 런북, 지표를 계속 보는 모니터링, 그리고 개발 스펙에 적어 둔 평가 기준을 운영에서도 주기적으로 다시 돌리는 일. 특히 마지막이 자주 빠진다. 평가 기준은 개발 끝에 한 번 통과하려고 만든 게 아니다. 들어오는 데이터가 바뀌면 품질은 소리 없이 내려간다.
우리 것은 SI 프로젝트가 아니라 블로그 한 채지만 같은 일이 있었다. 사이트 속도를 재 봤더니 홈 첫 화면이 2.8MB였고 그 대부분이 최적화하지 않은 PNG였다. 만들 때는 아무도 안 봤다. 올리고 한참 지나서 재 보고야 알았다.
순서 한눈에 보기
| 단계 | 나오는 것 | 넘어가기 전 질문 |
|---|---|---|
| 1. 성립성 확인 | 권리·법무 검토, 목표 규모 | 여기서 막히면 나머지가 의미 있나 |
| 2. 기획서 | 무엇을 왜 만드나 | 안 만들면 무슨 일이 나나 |
| 3. 기술요구서 초안 | 불확실성 목록 | 제일 위험한 가정이 무엇인가 |
| 4. PoC 계획서 | 검증항목·성공기준·기간·예산, 미달이면 할 행동 | 기준을 숫자로 적었나 |
| 5. PoC 실행 | 실측치 | 재려던 것을 실제로 쟀나 |
| 6. 판정 | 계속·축소·중단 | 누가 결정하나 |
| 7. 요구사항 확정, 아키텍처 설계 | 데이터 모델, 비기능 요구 | 나중에 못 바꾸는 게 무엇인가 |
| 8. 개발계획서 | 일정·예산 확정 | 근거가 실측인가 |
| 9. 개발 스펙 | 기능 스펙, 평가 기준 | 합격선이 있나 |
| 10. 개발·시험·파일럿 | 돌아가는 것 | 진짜 사용자가 써 봤나 |
| 11. 오픈, 운영 이관 | 런북·모니터링·회귀 평가 | 내일 장애 나면 누가 보나 |
순서표에서 어느 칸부터 채우나
두 칸만 먼저 채운다. 4번의 “미달이면 할 행동”과 마지막 11번 줄. 나머지는 사람이 붙으면 대개 알아서 채워지는데, 이 둘은 아무도 안 물으면 끝까지 비어 있다. 그리고 공교롭게도 프로젝트가 크게 어긋날 때 항상 이 두 자리가 비어 있다.
여기 적은 순서는 공식 문서와 법조문을 읽고 정리한 것이지 대형 SI 프로젝트를 굴려 본 이야기가 아니다. 위에 붙인 경험은 전부 블로그 한 채 크기다. 순서보다 회의에서 오가는 말이 먼저 걸린다면 개발 회의 용어 쪽을 먼저 보는 게 낫다.