만드는 순서

먼저, 실력이 느는 순서

AI와 한동안 일해 보면 느는 순서가 대체로 비슷합니다. 처음엔 한 번을 잘 시키는 데 매달리다가, 같은 설명을 매번 반복하는 게 지겨워져서 파일로 저장하게 되고, 나중엔 아예 도구를 만들게 됩니다.

아래 9단계는 이 세 가지를 실제 작업 순서에 놓은 것입니다. 1~2단계에서 프롬프트를, 3단계에서 컨텍스트를, 8단계에서 도구를 만듭니다.

이 문서는 도구 이름이 아니라 순서와 원칙을 다룹니다. 특정 서비스·프레임워크는 예시로만 나오고, 그것들이 바뀌어도 순서는 그대로입니다. 알리는 쪽의 순서는 마케팅 — 앱을 알리는 순서에 따로 정리해 두었습니다.

가장 흔한 실패는 머릿속에만 있는 것을 AI에게 시키는 것입니다. 본인도 아직 안 정한 걸 시키면 나오는 것도 딱 그만큼입니다.

AI에게 시키기 전에 나한테 먼저 시킵니다. 적다 보면 아직 안 정한 부분이 어디인지 그냥 보입니다.

여섯 줄이면 충분합니다. 이걸 적는 데 10분도 안 걸리지만, 안 적으면 며칠을 되돌립니다.

• 여섯 줄을 실제로 적었다(머릿속 말고 글로)
• What을 핵심 기능 하나로 줄여봤다
• How에 "어떻게 돈이 도는가"가 들어 있다

여섯 줄을 기획서 한 문서로 키웁니다. 이 문서가 앞으로 모든 작업의 기준이 됩니다.

기획서가 기준입니다. 코드가 기획서와 어긋나면, 기획서를 먼저 고치고 코드를 고칩니다.

순서를 반대로 하면 문서가 금방 낡아서 아무도 안 보게 됩니다. 그러면 매번 처음부터 다시 설명하는 자리로 돌아갑니다.

기획서를 직접 쓸 필요는 없습니다. 재료를 주고 형식을 지정하면 AI가 씁니다.

아래 정보로 기획서를 작성해줘.

## 프로젝트
- 이름 / 한 줄 정의 / 사용 환경

## 5W1H
- Why / Who / What / When / Where / How
  (앞에서 적은 여섯 줄을 그대로)

## 화면 목록
- [필요한 화면을 나열]

## 문서 성격
이 문서가 기준이다. 이후 각 부분을 만들 때
항상 이 문서를 먼저 참조한다. 특정 대목만 콕 집어 참조할 수
있도록 섹션 번호와 앵커를 갖출 것.

## 포함하지 말 것
디자인 방향(색·서체·여백)은 이 문서에 넣지 말 것.
디자인은 별도 문서에서 관리한다.

## 출력 형식
1. 개요 · 2. 대상 사용자 · 3. 핵심 기능 · 4. 화면 구조
· 5. 성공 지표(정량 목표)

작성 후 파일로 저장하고, 다른 수정 없이 멈춰줘.

마지막 줄이 중요합니다. "다른 수정 없이 멈춰줘"를 빼면 AI가 신이 나서 코드까지 만들기 시작합니다. 아직 만들 단계가 아닙니다.

• 기획서가 파일로 저장돼 있다
• "코드가 어긋나면 문서를 먼저 고친다"를 원칙으로 정했다
• 디자인 얘기는 기획서에서 빠져 있다

AI는 대화를 새로 시작할 때마다 앞을 기억하지 못합니다. 그래서 매번 같은 말을 다시 하게 됩니다. 색은 무엇이고, 말투는 어떻고, 뭘 하면 안 되는지.

한 번만 적어서 파일로 두면, AI가 매번 시작할 때 자동으로 읽습니다.

문서는 성격에 따라 나눕니다. 섞으면 둘 다 못 씁니다.

규칙 문서에서 가장 값어치 있는 항목은 "절대 하지 말 것"입니다. AI가 같은 실수를 반복하면 그때마다 한 줄씩 추가해 둡니다. 이 목록이 길어질수록 확실히 덜 헤맵니다.

디자인을 따로 두는 이유는 파일 하나만 갈아끼우면 분위기 전체가 바뀌기 때문입니다. 화면을 한 군데씩 고치는 것보다 훨씬 빠릅니다.

규칙은 두 곳에 둘 수 있습니다. 이 프로젝트에서만 쓸 규칙은 프로젝트 폴더에, 어떤 작업을 하든 항상 지킬 규칙은 전역에 둡니다. 저희는 "배포 전에 검토를 통과해야 한다"를 전역에 두고 모든 프로젝트가 상속받게 했습니다.

• 규칙 문서와 디자인 문서를 분리했다
• "절대 하지 말 것"에 최소 3줄이 들어 있다
• 전역 규칙과 프로젝트 규칙을 구분해서 뒀다

기능부터 만들면 무엇을 만들고 있는지 눈으로 확인할 수 없습니다. 화면이 있으면 잘못된 방향을 하루 만에 발견합니다.

먼저 골격을 세웁니다. 화면은 다 있고 동작만 없는 상태를 먼저 만듭니다.

화면 하나하나의 프롬프트를 직접 짜지 않아도 됩니다. "각 화면을 만들 프롬프트를 화면별로 만들어줘"라고 먼저 시키면, AI가 화면별 지시문을 한 번에 정리해 줍니다. 그다음 그것들을 하나씩 돌립니다.

기획서를 참조해서 [화면 이름] 을 만들거야. (지금은 화면만,
실제 동작 연결은 나중에)

이 화면에 들어갈 것을 위에서 아래로:
  1. [영역] — [무엇을 보여주는가]
  2. [영역] — [무엇을 보여주는가]
  3. ...

빈 상태일 때 무엇을 보여줄지도 함께 정해줘.
말투·간격·색은 규칙 문서와 디자인 문서를 따를 것.

먼저 이 화면의 기획을 상세하게 해줘. (만들기 전에)

"먼저 기획을 해줘"가 핵심입니다. 바로 만들게 하면 내 생각과 다른 것이 완성된 채로 나옵니다. 기획 단계에서 고치는 게 훨씬 쌉니다.

• 화면 목록을 먼저 확정했다
• 화면별 지시문을 AI에게 먼저 만들게 했다
• 만들기 전에 기획을 받아 확인했다
• 빈 상태·에러 상태 화면까지 정했다

기획서를 만들었다고 "이대로 다 만들어줘" 하면 안 됩니다. 결과가 나와도 어디가 어떻게 만들어졌는지 따라갈 수 없습니다.

한 조각씩 — 요청 → 생성 → 확인 → 수정. 이 네 박자를 반복합니다.

그리고 첫 결과를 그대로 통과시키지 않습니다. 한두 번 피드백을 줘야 비로소 내 것이 됩니다. 피드백은 길 필요가 없습니다. "후기 영역은 빼고 비교표로 바꿔줘" 정도의 한 줄이면 됩니다.

작업 범위를 좁혀서 주면 정확도가 올라갑니다. 파일 하나만 고치게 할 때는 그 파일만, 폴더 전체를 손볼 때는 그 폴더만 지정합니다. 프로젝트가 커질수록 이 차이가 커집니다.

• 한 번에 하나씩 시키고 있다
• 첫 결과를 그대로 통과시키지 않고 피드백을 줬다
• 작업할 파일·폴더 범위를 지정해서 준다

내 컴퓨터에서만 도는 건 아직 없는 거나 마찬가지입니다. 노트북을 끄면 같이 사라지고, 남에게 보여줄 수도 없습니다.

기능을 다 만든 다음에 배포하지 않습니다. 화면 골격이 서자마자 배포 경로를 먼저 뚫습니다.

배포는 처음 한 번이 어렵고 그다음부터는 거의 자동입니다. 그 어려운 한 번을 기능이 복잡해진 뒤로 미루면 원인 찾기가 배로 힘들어집니다. 골격만 있을 때 뚫어 두면, 이후로는 저장할 때마다 사이트가 저절로 갱신됩니다.

• 화면 골격 상태에서 배포를 한 번 성공시켰다
• 이후 갱신이 자동으로 되는 것을 확인했다
• 공개된 주소를 실제로 다른 기기에서 열어봤다

로그인·저장·결제 같은 것은 직접 만들지 않습니다. 그 일만 전문으로 하는 회사의 창구를 빌립니다.

외부 서비스를 붙이는 일은 종류가 달라도 절차가 같습니다. ① 가입하고 열쇠를 받는다 ② 그 열쇠를 안전한 곳에 둔다 ③ 연결하고 실제로 되는지 확인한다.

세 번째가 늘 빠집니다. "연결했다"와 "작동한다"는 다릅니다. 붙일 때마다 실제로 한 번 써보고 다음으로 넘어갑니다.

열쇠는 코드에 적지 않습니다. 별도 파일에 두고, 그 파일은 절대 공개 저장소에 올라가지 않게 합니다. 이건 AI에게 맡기지 말고 직접 확인하는 편이 안전합니다. 한 번 새어 나가면 되돌릴 수 없습니다.

그리고 쓸수록 돈이 나가는 것이 여기서 붙습니다. 사용량에 따라 요금이 붙는 서비스를 연결했다면, 그 순간부터 그건 유지비입니다. 가격을 어떻게 받을지는 마케팅 6단계에서 다룹니다.

• 외부 서비스를 하나씩 붙이고 매번 실제로 확인했다
• 열쇠가 공개 저장소에 올라가지 않는 것을 직접 확인했다
• 사용량에 따라 요금이 붙는 것이 무엇인지 목록으로 안다

여기가 세 번째 단계입니다. 매번 길게 적던 지시문을 한 줄로 줄이는 것.

두 번 이상 한 작업은 도구로 만듭니다. 세 번째부터 시간이 되돌아옵니다.

거창할 필요 없습니다. 저희가 실제로 쓰는 것도 이 정도입니다. 코드를 훑어서 규칙 문서를 최신으로 맞추는 것, 배포 전 검토를 돌리는 것, 기획을 질문으로 다듬는 것.

새로 만든 도구는 AI를 껐다 켜야 인식됩니다. "만들었는데 목록에 없다"는 대부분 이것 때문입니다.

• 두 번 이상 반복한 작업을 목록으로 적었다
• 그중 하나를 도구로 만들었다
• 항상 쓸 도구는 전역에, 이 프로젝트 전용은 프로젝트에 뒀다

AI가 만든 코드는 그럴듯하게 틀립니다. 사람이 쓴 코드는 어설프게 틀리는데, AI가 쓴 코드는 완성된 얼굴로 틀립니다. 그래서 눈으로 읽는 것만으로는 못 잡습니다.

부품 하나가 도는 것과 사람이 실제로 쓰는 길 전체가 도는 것은 다릅니다. 내보내기 전에 확인하는 건 후자입니다.

처음 들어와서 끝까지 가는 길을 한 번 통째로 따라가 봅니다. 각 화면이 잘 뜨는지가 아니라, 화면과 화면 사이에서 끊기지 않는지가 문제입니다. 버그는 대부분 그 이음매에 있습니다.

저희는 이걸 습관이 아니라 절차로 만들었습니다. 배포 명령 자체를 막아두고, 검토를 통과한 기록이 있을 때만 열립니다. 검토 후에 코드가 한 줄이라도 바뀌면 그 기록이 자동으로 무효가 되어 다시 막힙니다. 사람의 의지에 기대지 않는 편이 확실합니다.

• 처음부터 끝까지 가는 길을 한 번 통째로 확인했다
• 화면 사이 이음매를 특히 봤다
• 검증을 습관이 아니라 절차로 만들었다

순서 밖에서, 상시로

좋은 지시문의 세 조건

결과가 마음에 안 들 때는 대개 지시문 쪽에 문제가 있습니다. 세 가지를 모두 갖춰야 합니다.

가장 자주 빠지는 건 맥락입니다. 왜 필요한지를 알려주면 톤과 판단까지 맞춰집니다.

목표를 끝까지 밀고 가는 법

큰 작업을 맡길 때는 두 가지를 함께 줘야 합니다. 하나만 주면 각각의 약점이 그대로 나옵니다.

목표: [무엇을 완성하는 것]

완수 기준 — 아래가 전부 참이면 끝난 것으로 본다:
  - [확인 가능한 조건]
  - [확인 가능한 조건]

진행 방식:
  - 큰 목표를 체크리스트로 잘게 나눠서 하나씩 처리할 것
  - 오류가 나면 원인을 찾아 고치고 다시 시도할 것
  - 완수 기준을 모두 만족할 때까지 계속할 것
  - 끝나면 무엇을 했는지 요약해서 알려줄 것

완수 기준은 "확인 가능한 것"으로 적습니다. "잘 작동한다"는 확인할 수 없습니다. "이 주소를 열면 목록이 보인다"는 확인할 수 있습니다.

에러가 났을 때

빨간 글씨가 떠도 대부분은 AI가 스스로 고칩니다. 문제는 언제 기다리고 언제 개입하냐입니다.

그리고 같은 에러가 세 번 반복되면 방식을 바꿉니다. 같은 지시로 네 번째를 시키는 건 시간 낭비입니다. 범위를 좁히거나, 맥락을 더 주거나, 잘게 쪼갭니다.

하지 않을 것

• 머릿속에만 있는 것을 시키지 않는다. 먼저 적는다
• 기획서 없이 만들지 않는다
• 한 번에 통째로 시키지 않는다
• 첫 결과를 그대로 통과시키지 않는다
• 열쇠를 코드에 적지 않는다
• 검증을 사람의 의지에 맡기지 않는다. 절차로 만든다

마지막으로, 요약하면

적는다 → 기획서 → 규칙 문서 → 화면 → 쪼개서 만들기 → 배포 → 뒷단 → 도구 → 검증. 앞의 셋은 코드를 한 줄도 안 씁니다. 그런데 여기서 대충 하면 뒤에서 전부 되돌아옵니다.

코드는 AI가 씁니다. 사람 몫으로 남는 건 무엇을 만들지 정하고, 규칙을 세우고, 결과를 확인하는 것입니다. 나머지는 시키면 됩니다.

이 순서를 따라 만든 다음에는 알리는 순서가 이어집니다. 저희도 아직 그 길 위에 있고, 배운 것이 생기면 이 페이지를 고쳐 나가겠습니다. 틀린 부분이 보이면 알려주세요.