앞 편 인터페이스를 정한다까지 오면 무엇을 만들지, 어떤 모양으로 만들지가 GitHub에 적혀 있습니다. 이번 편은 "언제 끝난 것으로 볼 것인가"를 정합니다. 완성의 정의, 추적할 숫자 하나, 이번엔 안 할 목록. 이 세 가지를 docs/output.md 한 장에 적고 나면 다음 편 전부 통째로 넘긴다에서 AI에게 일을 맡길 준비가 끝납니다.
핵심 요약
- 완성을 정의하지 않으면 AI는 계속 만들고, 사람은 계속 고치고, 공개는 오지 않습니다.
- 첫 공개의 정의는 부끄러울 정도로 작게 적습니다. 우리 8주 과정의 완성 기준은 "실행하면 ~가 나온다" 한 문장입니다.
- 추적할 숫자는 하나만 고릅니다. 그 숫자가 이후 모든 판단(개선, 접기)의 근거가 됩니다.
- 안 할 것을 문서로 적어야 AI도, 나도 곁길로 새지 않습니다.
무엇이 나와야 성공인가
기획을 적을 때는 다들 "좋은 도구"를 상상합니다. 그런데 좋은 도구는 완성 기준이 아닙니다. 완성 기준은 눈으로 확인할 수 있는 결과물이어야 합니다. 우리 8주 과정 7주차에서 개인 프로젝트를 확정할 때 요구하는 문장이 그것입니다. "실행하면 무엇이 나온다"를 증거로 확인할 수 있게 한 문장으로 적는 것입니다.
정책지도사 수강생의 예를 들면 "지원사업 공고 모니터링 도구"는 기획이고, "매일 아침 8시에 새 공고 목록이 내 메일함에 도착해 있다"가 아웃풋입니다. 전자는 언제 끝났는지 알 수 없지만, 후자는 내일 아침에 메일함을 열어 보면 판정이 납니다. 아웃풋을 정한다는 것은 이렇게 판정 가능한 문장을 먼저 갖는 일입니다.
완성의 정의를 먼저 적는다
완성의 정의는 만들기 전에 적어야 합니다. 만든 뒤에 적으면 이미 만들어진 것에 맞춰 정의가 늘어나고, 결승선이 계속 뒤로 밀립니다. 이 코스에서는 docs/output.md에 "첫 공개의 정의"라는 제목으로 적습니다. 첫 공개란 나 말고 누군가 한 사람이 실제로 써 보는 순간입니다.
# docs/output.md
## 첫 공개의 정의
- 동료 컨설턴트 1명이 내 서버에서 도는 공고 알림 메일을 일주일 동안 받는다.
- 메일에는 공고명, 접수 마감일, 원문 링크 세 가지만 들어 있다.
- 실행 로그가 매일 남고, 실패한 날은 실패했다고 표시된다.
## 추적할 숫자 (하나만)
- 동료가 메일에서 원문 링크를 눌러 열어 본 공고 건수 (주간)
## 이번엔 안 하는 목록
- 로그인, 회원가입 화면
- 고객사별 맞춤 추천
- 예쁜 대시보드
이 파일은 docs/ 폴더에 두고 GitHub에 함께 올립니다. Claude Code는 CLAUDE.md를 세션 시작 때 읽고, @docs/output.md처럼 파일을 지목하면 그 내용을 대화에 통째로 가져옵니다. 그래서 완성의 정의를 파일로 적어 두면 사람이 매번 설명하지 않아도 AI가 같은 결승선을 보고 일합니다.
CLAUDE.md 안에 @docs/output.md라고 적어 두면 세션이 시작될 때 자동으로 함께 읽힙니다. 다만 가져온 내용도 시작 컨텍스트에 그대로 들어가고 CLAUDE.md는 200줄 이하가 권장이므로, 완성 정의처럼 짧고 매번 필요한 문서만 가져옵니다.
추적할 숫자를 여기서 하나만 정한다
추적할 숫자는 "이 도구가 쓸모 있었는가"를 한 번에 말해 주는 값입니다. 여러 개를 고르면 하나가 오르고 하나가 내릴 때 판단이 마비됩니다. 하나만 고르는 대신, 그 하나는 실제 행동을 재는 값이어야 합니다. 공고 알림 도구라면 메일 발송 건수가 아니라 동료가 링크를 열어 본 건수입니다. 발송은 도구가 한 일이고, 열어 본 것은 사람이 가치를 느낀 증거이기 때문입니다.
우리 8주 과정에서 자주 나오는 도구로 예를 들면 이렇습니다.
| 도구 | 도구가 한 일 (고르지 않음) | 사람의 행동 (추적할 숫자) |
|---|---|---|
| 녹음을 회의록으로 바꾸는 변환기 | 변환한 파일 수 | 수정 없이 그대로 노션에 올린 회의록 건수 |
| 흩어진 고객 자료 정리기 | 읽어 들인 파일 수 | 표준 10항목이 모두 채워진 고객 수 |
| 지원사업 공고 알림 | 보낸 메일 수 | 메일에서 원문 링크를 연 건수 |
이 숫자는 뒤에 나올 계측 편과 개선 루프 편에서 그대로 쓰입니다. 지금 정하는 이유는 "무엇을 잴지"가 정해져야 계측을 공개 전에 심을 수 있기 때문입니다. 재는 방법은 지금 정하지 않아도 됩니다. 무엇을 잴지만 적어 두면 방법은 AI에게 맡길 수 있습니다.
안 할 것을 정한다 (이번엔 안 하는 목록)
AI는 시키지 않은 일도 곧잘 합니다. 우리 5주차 교재에서 "알아서 고쳐줘"가 왜 위험한지를 다루는 이유와 같습니다. 요청이 모호하면 AI는 과하게 추측해서 로그인 화면을 붙이고 설정 페이지를 만듭니다. 그래서 안 할 목록은 AI를 향한 울타리이자, 다음 날 아침 "이것도 있으면 좋겠다"고 생각하는 나 자신을 향한 울타리입니다.
이 목록은 실제로 일을 넘길 때 효과가 납니다. Issue를 넘기면서 @docs/output.md를 함께 붙이면 AI는 로그인 화면이 필요해 보이는 순간에도 "안 할 목록에 있어 넘어갑니다"라고 보고하고 지나갑니다.
목록에는 "영원히 안 함"이 아니라 "이번엔 안 함"을 적습니다. 좋은 아이디어를 버리는 것이 아니라 순서를 뒤로 미루는 것이므로, 적어 두면 오히려 잊어버릴 걱정 없이 지금 것에 집중할 수 있습니다.
해 보기
docs/output.md를 만들고 위 세 항목의 제목을 적습니다.- 첫 공개의 정의를 세 줄 이내로 적습니다. 각 줄이 "확인 가능한가"를 스스로 묻습니다.
- 추적할 숫자를 하나만 적습니다. 도구가 한 일이 아니라 사람이 한 행동인지 확인합니다.
- 이번엔 안 할 목록을 다섯 개 이상 적습니다.
- GitHub에 올리고, Claude Code에서
@docs/output.md를 붙여 "기획 문서와 대조해 줘"라고 시켜 봅니다.
정리
- 완성의 정의는 만들기 전에, 확인 가능한 문장으로 적습니다.
- 첫 공개는 작을수록 빨리 옵니다. 작아서 부끄러운 것이 정상입니다.
- 추적할 숫자는 하나, 사람의 행동을 재는 값으로 고릅니다.
- 안 할 목록은 AI와 나를 동시에 묶는 울타리입니다.
자주 묻는 질문
첫 공개의 정의는 얼마나 작게 잡아야 하나요?
"한 사람이 한 번 실제로 쓴다"가 기준입니다. 동료 한 명이 일주일 동안 받아 보는 메일, 내가 매일 아침 여는 표 한 장이면 충분합니다. 우리 8주 과정에서도 무인 잡의 완료 기준은 "노트북을 끄고 다음 날 아침 결과가 나와 있는가" 하나입니다.
그림은 크게 키우라고 했는데 첫 공개를 작게 잡으면 모순 아닌가요?
모순이 아니라 순서입니다. 큰 그림은 방향을 정하고, 작은 첫 공개는 그 방향으로 가는 첫 발자국입니다. 그림이 크기 때문에 첫 걸음을 어디로 디딜지 고를 수 있고, 첫 걸음이 작기 때문에 실제로 공개까지 도달합니다.
추적할 숫자로 방문자 수를 고르면 안 되나요?
방문자 수는 도구가 쓸모 있었는지를 말해 주지 않습니다. 들어왔다가 아무것도 안 하고 나간 사람도 방문자입니다. 링크를 눌렀는가, 파일을 내려받았는가, 다음 주에 다시 왔는가처럼 가치를 느낀 뒤에만 나오는 행동을 고르세요.
이번엔 안 할 목록은 왜 따로 적어야 하나요?
적지 않으면 AI가 추측으로 채우고, 나는 "있으면 좋겠다"에 끌려다닙니다. 목록으로 적는 순간 그 기능은 "버린 것"이 아니라 "다음 바퀴 후보"가 되어, 지금은 안 만들어도 마음이 편해집니다.
추적할 숫자를 재는 방법도 지금 정해야 하나요?
아니요. 지금은 무엇을 잴지만 정합니다. 재는 방법(GA4, 로그, 카운터)은 뒤의 계측 편에서 AI에게 통째로 맡깁니다. 무엇을 잴지가 정해져 있으면 방법은 AI가 여러 안을 제시할 수 있습니다.