Claude Code·Cursor로 만들기 전에, 기획은 어디서 하나요?

엔진이 강해질수록 또렷해진 빈칸

Claude Code, Cursor, Codex 같은 코딩 에이전트는 코드를 짜고, 고치고, 테스트까지 해요. 저도 매일 써요. 그런데 엔진이 강해질수록 오히려 더 또렷해진 빈칸이 있어요. 엔진에 무엇을 태울지예요.

• •누구를 위한 건지
• •그 사람이 어떤 불편 때문에 쓰고, 무엇에 돈을 낼지
• •처음에 꼭 들어가야 하는 기능은 무엇인지
• •이번에는 하지 않을 것은 무엇인지

이 네 가지를 정하는 법은 앱 만들기 전에 정할 다섯 가지에 정리했어요. 이게 정해지지 않은 채 맡기면 에이전트는 빈칸을 그럴듯한 가정으로 채워요. 결과물은 나와요. 다만 그 가정이 맞는지는 아무도 확인하지 않은 상태예요.

에이전트는 시키는 대로 잘 만들어요. 그래서 무엇을 시킬지가 비어 있으면, 잘 만든 엉뚱한 결과물이 나와요.

에이전트와의 매 턴도 소통이에요

설계 없이 감으로 던지는 지시는, 경험 많은 실무자에게 설계도 없이 "이거 한번 해 보죠"라고 건네는 것과 비슷해요. 실무자는 무엇을 원하는지 이해하려고 다시 묻고, 만든 뒤에 또 고쳐요. 기획 단계가 부실하면 만드는 단계로도 제대로 못 가고, 중간에 엎어지기도 해요.

에이전트도 같아요. 빈칸이 많을수록 되묻고, 다시 만들고, 고치는 턴이 늘어요. 그만큼 시간과 사용량이 새요. 그래서 에이전틱 코딩에서 중요한 건 턴을 줄이는 거예요. 사람과의 소통 비용을 줄여 병목을 줄이는 것처럼요. (원래 글)

같은 창 안에서 일어나는 일

연결

Docs의 도구별 안내대로 퍼플프린트를 연결하고 앱을 한 번 다시 열어요. 그다음부터는 평소 쓰던 대화창에서 "퍼플프린트 시작해 줘"라고 말하면 돼요. 쓰던 AI 도구의 구독과 사용료는 그 도구 몫이에요.

설계

맥락, 쓸 사람, 문제, 기능, 사용 흐름, 화면, 점검, 시장 진입, 개발 설계, 인계까지 0~9단계를 순서대로 거쳐요. 정해야 할 게 나오면 후보와 추천, 고르지 않은 이유를 보여 주고 확인은 내가 해요.

문서

합의한 내용은 내 작업 폴더에 설계 문서로 남아요. 다음 날 다른 창을 열어도 그 문서를 읽고 이어 가요.

구현

개발 단계로 넘어가면 같은 에이전트가 그 문서를 읽고 만들어요. 화면을 고칠 때도 처음 정한 결정을 문서에서 다시 꺼내 볼 수 있어요.

예시로 보는 한 번의 흐름

동네 반찬을 정기 배송하는 서비스를 Claude Code에서 처음 기획한다고 해 볼게요. 아래는 흐름을 보여 주려고 만든 예시예요.

• •"퍼플프린트 시작해 줘"라고 쓰면 코치가 "어떤 걸 만들고 싶으세요?"라고 물어요
• •"맞벌이 부부에게 반찬을 정기 배송하고 싶어요"라고 답하면, 쓸 사람 후보 두세 개와 추천, 나머지를 고르지 않은 이유가 나와요
• •고르고 나면 그 사람이 지금 반찬을 어떻게 해결하는지, 무엇이 불편한지를 하나씩 물어요
• •정리가 끝나면 요약을 보여 주고, 확인을 받은 뒤 작업 폴더에 맥락문서를 저장해요
• •이어서 문제, 핵심 기능, 사용 흐름, 화면을 같은 방식으로 정하고 문서가 단계마다 쌓여요
• •개발 단계에서 "설계 문서대로 첫 화면을 만들어 줘"라고 하면, 같은 에이전트가 그 문서를 읽고 만들어요

이 흐름에서 사람이 하는 일은 고르고 확인하는 거예요. 무엇을 물어야 할지, 어떤 순서로 정할지는 코치가 이끌고, 만드는 일은 에이전트가 해요.

반찬 서비스가 아니어도 순서는 같아요. 법률 사무소의 상담 접수 도구든, 매장 직원용 근무표 도구든, 쓸 사람과 불편이 먼저예요.

설계 문서가 있으면 에이전트 작업이 이렇게 바뀌어요

• •매번 맥락을 처음부터 설명하지 않아도 돼요. 에이전트가 문서를 읽고 시작해요
• •다음 날 새 창을 열어도 같은 결정에서 이어 가요
• •화면을 고칠 때 처음 정한 이유가 남아 있어서 덜 흔들려요
• •되묻는 질문이 줄어 턴과 사용량이 덜 새요

에이전트에게 일을 잘 시키는 사람은 지시를 한 번에 구체적으로 전달해요. 설계 문서는 그 구체적인 지시를 미리 써 둔 것과 같아요.

같은 창에서 기획할 때 좋은 점과 주의할 점

• •좋은 점: 기획과 구현이 같은 맥락에서 이어져요. 문서가 작업 폴더에 남아 에이전트가 바로 읽어요
• •좋은 점: 따로 창을 오가며 내용을 옮겨 적을 일이 없어요
• •주의할 점: 기획 대화도 쓰던 AI 도구의 사용량을 써요
• •주의할 점: 도구마다 연결하고 다시 여는 방법이 조금씩 달라요
• •주의할 점: 대화가 아주 길어지면 정리가 필요해요. 그때는 코치가 정리와 인계 문서를 먼저 권해요

웹 코치와는 무엇이 다른가요

웹 코치는 브라우저에서 설치 없이 쓰는 같은 설계 코치예요. 대화와 문서는 계정에 보관되고, 무료 체험에서는 0~2단계까지 쓸 수 있어요. MCP로 연결하면 쓰던 코딩 도구 안에서 쓰고, 문서는 작업 폴더에 남고, 무료 체험이어도 전 단계를 쓸 수 있어요.

코딩 도구를 아직 안 쓴다면 웹 코치로 시작하고, 개발 단계에 들어갈 때 쓰던 도구에 연결해도 돼요.

설계 문서는 어떻게 생기나요

단계가 끝날 때마다 코치가 요약을 먼저 보여 주고, 확인을 받은 뒤 문서를 저장해요. 맥락문서, 설계문서, 사용 흐름, 화면 구조 순서로 쌓이고, 문서 맨 위에는 어느 앞 문서를 바탕으로 했는지가 적혀 있어요. 그래서 나중에 문서 하나를 고쳐도 어디까지 영향이 가는지 따라갈 수 있어요.

개발 단계에서 에이전트에게 하는 말

• •"설계 문서대로 첫 화면을 만들어 줘"
• •"화면 구조 문서의 두 번째 화면을 고쳐 줘"
• •"과업정의서의 다음 과업을 진행해 줘"

문서를 가리키면 에이전트가 맥락을 다시 묻지 않고 바로 일을 시작해요. 사람은 결과가 문서에서 정한 것과 맞는지만 보면 돼요.

누가 무엇을 맡나요

• •퍼플프린트: 무엇을 왜 만들지 정하는 질문, 후보와 추천, 고르지 않은 이유, 결정의 문서화
• •코딩 에이전트: 그 문서를 읽고 구현하고, 테스트하고, 배포하기
• •사람: 가정과 결정이 맞는지 확인하기

이 나눔이 분명하면 결과가 마음에 안 들 때 어디를 고칠지도 분명해요. 무엇을 만들지가 틀렸으면 문서를, 만든 방식이 틀렸으면 코드를 고쳐요.

하네스나 문서 기반 개발 도구와는 어떻게 다른가요

여러 에이전트를 묶는 하네스나 문서 기반 개발 도구도 같은 자리에 있어요. 이런 도구는 무엇을 만들지 이미 아는 사람을 더 빠르고 정확하게 만들어요. 저도 그 방식에서 많이 배웠어요.

퍼플프린트가 겨냥하는 건 그보다 앞의 결정이에요. 무엇을 만들지가 아직 흐릿하거나, 만들었는데 왜 안 쓰이는지 모르는 상태요. 그래서 둘은 대신하는 관계가 아니라 이어지는 관계예요.

이미 하네스를 쓰고 있다면 퍼플프린트가 만든 설계 문서를 그 하네스의 입력으로 그대로 넣어 쓰면 돼요. 문서는 평범한 마크다운 파일이라 어느 도구에서도 읽혀요.

ChatGPT나 Claude 웹으로 기획하면 안 되나요

할 수 있어요. 대화형 AI로도 기획하고, 리서치하고, 문서를 쓸 수 있어요. 차이는 모델의 지능이 아니라, 설계 과정을 내가 직접 짜야 하느냐예요. 퍼플프린트는 그 과정을 순서, 추천과 이유, 문서, 다음 행동이 이어지는 흐름으로 미리 짜 두었어요.

이럴 땐 퍼플프린트 없이 바로 만들어도 돼요

모든 작업에 설계 코치가 필요한 건 아니에요. 아래 경우라면 바로 에이전트에게 맡겨도 괜찮아요.

• •무엇을 누구에게 만들지 이미 분명하고, 바꾸기 쉬운 부분만 시험할 때
• •나 혼자 쓰는 작은 도구를 만들 때
• •도구 사용법을 익히려고 연습 삼아 만들어 볼 때

반대로 다른 사람이 쓰고 돈을 낼 서비스를 만든다면, 만들기 전에 정할 것부터 정하는 편이 결국 빨라요.

이미 에이전트로 만들고 있다면

지금 가진 기획서나 설계 문서를 하이퍼 리뷰에 먼저 넣어 보세요(샘플 리포트). 39개 관점에서 빈틈과 근거, 고칠 순서를 보여 줘요. 리포트의 "이 리포트로 고쳐 가기"에서 쓰던 AI 도구를 고르면, 연결 안내와 보낼 말이 나와 그 자리에서 이어서 고칠 수 있어요.

고친 뒤에는 같은 문서로 하이퍼 리뷰를 한 번 더 돌려 볼 수 있어요. 점검은 한 번 더 돌려도 새 빈틈이 나오지 않을 때까지 반복하고, 정해진 횟수 안에서 멈추면 리포트에 그렇게 적어요. 문서 점검이 실제 고객 검증이나 코드 시험을 대신하지는 않아요.