클로드를 켜자마자 "이런 앱 만들어줘"라고 던지면, 처음 30분은 놀랍도록 잘 굴러가다가 중반부터 무너집니다. 화면마다 버튼 색이 다르고, API 키가 코드에 그대로 박히고, 한 곳을 고치면 엉뚱한 곳이 깨집니다. 이건 AI 성능 문제가 아니라 입력이 부실해서 생기는 문제입니다. 첫 프롬프트를 넣기 전에 준비해야 할 5단계와 각 단계의 산출물을 정리했습니다.
1. 왜 준비 없이 시작하면 무너질까
언어 모델은 빈칸을 스스로 채웁니다. 로그인 방식을 정해주지 않으면 그때그때 다른 방식을 고르고, 버튼 모양을 정해주지 않으면 화면마다 다르게 그립니다. 각각은 합리적인 선택이지만, 모아놓으면 통일성이 없습니다.
더 큰 문제는 수정 비용입니다. 화면 스무 개를 만든 뒤에 "데이터 구조를 바꾸자"고 하면 스무 개를 전부 손봐야 합니다. 시작 전에 30분 쓰는 것과 나중에 이틀 쓰는 것의 차이입니다.
💡 핵심 준비 단계의 목적은 완벽한 설계가 아닙니다. AI가 마음대로 정하면 곤란한 것들만 미리 못 박아두는 것이 전부입니다.
2. 시작 전 5단계 한눈에 보기
| ① PRD | 요구사항 문서 | 대화할 때마다 기능 범위가 달라짐 |
| ② 디자인 가이드 | 색·폰트·컴포넌트 규칙 | 화면마다 스타일이 제각각 |
| ③ 데이터 구조 | 저장할 항목과 관계 | 후반에 전체를 갈아엎게 됨 |
| ④ 보안 기준 | 비밀값 관리·인증 방식 | 키가 코드와 깃 기록에 남음 |
| ⑤ 규칙 파일 | 프로젝트 상시 지침 | 같은 지시를 매번 다시 설명 |
3. 각 단계에서 딱 하나만 챙긴다면
① PRD — '무엇을 안 만들지'를 쓰세요.
만들 기능을 나열하는 것보다, 첫 버전에서 제외할 기능을 명시하는 쪽이 훨씬 강력합니다. 범위가 고정되면 결과물이 흔들리지 않습니다.
② 디자인 가이드 — 색 3개와 폰트 1개를 고정하세요.
메인 컬러, 보조 컬러, 배경 컬러 세 가지와 본문 폰트 하나만 정해줘도 화면 통일감이 확 달라집니다.
③ 데이터 구조 — 화면보다 데이터가 먼저입니다.
"무엇을 저장하고, 무엇과 연결되는가"를 먼저 정리하세요. 화면은 데이터에서 파생되지만, 반대 방향은 성립하지 않습니다.
④ 보안 — 비밀값 목록부터 만드세요.
API 키, 데이터베이스 비밀번호, 토큰이 각각 어디에 보관되는지 표로 정리해 두면 실수가 크게 줄어듭니다.
⑤ 규칙 파일 — 반복해서 말하게 되는 것을 적으세요.
"주석은 한국어로", "테스트 없이 배포하지 말 것" 같은 지시를 파일로 만들어 두면 매번 설명할 필요가 없습니다.
4. 순서를 바꾸면 손해가 커집니다
이 다섯 가지는 순서 자체가 의미를 가집니다. PRD 없이 디자인부터 하면 결국 쓰지 않을 화면을 예쁘게 만들게 됩니다.
데이터 구조 없이 화면부터 만들면, 나중에 항목 하나를 추가할 때마다 여러 파일을 동시에 고쳐야 합니다.
보안을 마지막으로 미루는 것이 가장 위험합니다.
한 번 커밋된 키는 파일에서 지워도 깃 기록에는 그대로 남습니다. 나중에 지우는 것보다, 처음부터 넣지 않는 편이 압도적으로 쉽습니다.
5. 시작 전 체크리스트
아래 여섯 줄에 답할 수 있다면 준비는 끝난 것입니다. 종이에 적어도 되고, 메모장에 적어도 됩니다.
- 이 서비스를 누가 쓰는지 한 문장으로 말할 수 있는가
- 첫 버전에서 빼기로 한 기능 세 가지는 무엇인가
- 메인 컬러·보조 컬러·배경 컬러가 정해졌는가
- 저장할 데이터 항목을 목록으로 적을 수 있는가
- 비밀값이 몇 개이고 각각 어디에 보관되는가
- 매번 반복하게 될 지시 다섯 줄을 적었는가
6. 준비 단계도 클로드와 같이 하면 빨라집니다
문서를 혼자 붙잡고 앉아 있을 필요는 없습니다. 다만 "PRD 써줘"라고 던지는 것과 질문을 시키는 것은 결과가 완전히 다릅니다.
가장 효과가 좋은 방식은 먼저 질문하게 만드는 것입니다. "내가 설명한 아이디어에서 아직 정해지지 않은 것 열 가지를 질문으로 뽑아줘"라고 요청하면, 스스로는 떠올리지 못했던 빈칸이 드러납니다.
답을 채운 뒤에는 "이 조건에서 문제가 생길 만한 지점을 지적해줘"라고 한 번 더 검토를 시키세요. 만들기 전에 발견한 허점은 비용이 거의 들지 않습니다.
⚠️ 주의 이때 나온 답변을 그대로 확정하지 마세요. 제외할 기능과 완료 조건만큼은 본인이 결정해야 합니다. 이 둘은 정답이 있는 문제가 아니라 목적과 취향의 문제입니다.
7. 자주 하는 착각 세 가지
"대화로 자세히 설명하면 되지 않나요?"
대화 내용은 세션이 바뀌면 사라집니다. 계속 유지되어야 할 규칙은 파일로 남겨야 합니다.
"일단 만들고 나중에 고치면 되죠."
코드가 늘어날수록 되돌리는 비용이 급격히 커집니다. 방향을 바꿀 거라면 파일이 열 개일 때가 백 개일 때보다 훨씬 쌉니다.
"보안은 배포 직전에 하면 되죠."
키 노출은 배포 시점이 아니라 처음 코드에 적은 순간 발생합니다. 첫 줄부터 분리해서 관리해야 합니다.
자주 묻는 질문 (FAQ)
Q. 개인 토이 프로젝트인데도 이걸 다 해야 하나요?
A. 전부 할 필요는 없습니다. 다만 비밀값 분리(④)는 규모와 무관하게 반드시 하세요. 나머지는 화면이 다섯 개를 넘어가는 시점부터 효과가 커집니다.
Q. 준비 문서를 클로드에게 대신 쓰게 해도 되나요?
A. 좋은 방법입니다. 다만 초안을 받은 뒤 직접 읽고 고치는 과정은 생략하지 마세요. 내가 이해하지 못한 요구사항은 결국 결과물에서도 어긋납니다.