큰 작업을 진행하는 법: 컨텍스트와 검증 가능한 단계

큰 작업은 대개 그럴듯하게 들리는 요청으로 시작합니다. "로케일 카탈로그를 만들어 주세요. 목록, 검색, 국가별 필터, 그리고 괜찮은 디자인까지요." 한 시간 뒤 여러분 앞에 있는 페이지는 이렇습니다. 목록은 절반만 완성됐고, 검색은 일부 필드에서만 작동하며, 디자인은 벌써 두 번이나 바뀌었습니다. 대화는 너무 길어져서 어디까지가 검증된 결과이고 어디부터가 그냥 말로만 한 약속인지 구분할 수 없습니다.

가능한 원인 중 하나는 작업을 명확한 결과가 있는 단위로 나누지 않았다는 데 있습니다. 그렇다고 코드에 버그가 없다는 뜻은 아니지만, 지금 무엇이 동작해야 하는지 분명하면 버그를 확인하기도 쉬워집니다. 큰 작업을 검증 가능한 단계로 나누는 방법, 현재 단계에서 에이전트에게 어떤 정보를 줘야 하는지, 그리고 내일(같은 대화에서든 새 대화에서든) 작업으로 돌아왔을 때 기억에 의존해 모든 걸 다시 끌어모으지 않도록 무엇을 기록해 둘지 살펴보겠습니다.

카탈로그는 이런 모습이 되어야 합니다. 검색이 있는 목록, 각 행에는 로케일 코드, 언어, 국가, 통화, 도메인이 있는 모습이죠. 이 목업을 기억해 두세요. 실습에서 단순한 그림이 아니라 스타일의 기준으로 쓰일 겁니다.

큰 작업과 긴 대화

긴 작업은 코드에 버그가 생기기도 전에 멈춰 설 수 있습니다. 과정이 형태를 잃는 것이죠. 컨텍스트는 계속 늘어나고, 추측과 이미 내린 결정이 뒤섞이고, 검색 작업 옆으로 디자인 손질이 슬그머니 끼어듭니다. 컨텍스트 창이 제한되어 있다는 것도 문제지만, 더 큰 문제는 지금 무엇을 하고 있고 무엇이 이미 끝났는지 알 수 없게 된다는 점입니다.

TASK_SPEC은 전체 작업의 목표, 범위, 검증 방법을 고정합니다. 그런 다음 이 명세에 따른 작업을 검증 가능한 단계, 즉 milestone으로 나눕니다. 각 단계에는 결과와 범위가 있습니다. 예를 들어 데이터와 디자인은 그대로 두고 검색만 추가하는 식입니다. 이렇게 하면 Claude가 본론에 집중하기 쉬워지고, 여러분도 작업이 어디까지 왔는지 파악할 수 있습니다.

작업이 아직 불분명하다면 첫 단계는 탐색이 될 수 있습니다. 핵심 파일 두세 개를 읽고, 가능한 접근법과 위험 요소를 정리한 다음, 작업 설명과 다음 단계들을 다듬는 것입니다.

각 단계는 검증과 짧은 요약(summary)으로 마무리하세요. 무엇을 했는지, 무엇으로 확인했는지, 다음은 무엇인지 적습니다. 프로젝트가 Git으로 관리된다면 검증된 변경 사항을 작은 커밋으로 저장하세요. 요약은 결정 사항을, 커밋은 코드 버전을 보존합니다. 둘이 함께 있어야 결과를 검증하고 쉬었다 온 뒤에도 작업을 이어갈 수 있습니다.

무엇을 하나의 단계로 볼까요

Milestone, 즉 이정표는 작업에 중간 결과가 생기고 그 결과를 검증할 수 있는 지점입니다. 이 지점까지의 작업을 앞으로 단계라고 부르겠습니다.

단계에는 반드시 있어야 할 세 가지 요소가 있습니다.

• 결과 - 정확히 무엇이 동작하기 시작하는가;
• 범위 - 이번에는 건드리지 않는 것;
• 검증 - 확인을 위해 무엇을 살펴볼 것인가.

표현만 봐도 차이가 드러납니다. "검색 기능을 손본다"에는 끝나는 지점이 없습니다. 무한정 작업할 수 있고, "완료"라는 순간은 아무나 정할 수 있습니다. "검색이 로케일 코드로 행을 찾고, 빈 검색어는 전체 목록을 반환한다"에는 끝나는 지점이 있고, 브라우저에서 30초면 확인할 수 있습니다.

시간이나 파일 수에 대한 보편적인 제한은 없습니다. 하지만 크기는 중요합니다. 하나의 단계 안에 서로 독립된 변경 사항 여러 개가 섞여 있어서 한눈에 결과를 확인할 수 없다면 단계를 줄이는 게 좋습니다. 기준은 따로 얻어서 따로 검증할 수 있는, 가장 가까운 유용한 결과입니다.

결과를 동작하는 부분으로 나누기

학습용 로케일 카탈로그를 예로 들어 보겠습니다. 레코드의 필드는 위 목업과 같습니다. 로케일 코드, 언어, 국가, 통화, 도메인. 간단하게 만들기 위해 완성된 배열을 index.html에 연결된 app.js에 바로 둡니다. 페이지가 별도 요청으로 데이터를 불러오지 않으므로 서버 없이 브라우저에서 열 수 있습니다. 데이터 세트는 다음과 같습니다.

[
  { "code": "en-US", "language": "English", "country": "United States", "currency": "USD", "tld": ".us" },
  { "code": "de-DE", "language": "German", "country": "Germany", "currency": "EUR", "tld": ".de" },
  { "code": "fr-CA", "language": "French", "country": "Canada", "currency": "CAD", "tld": ".ca" },
  { "code": "ja-JP", "language": "Japanese", "country": "Japan", "currency": "JPY", "tld": ".jp" }
]

요청 전체는 이렇습니다. 목록, 검색, 국가별 필터. 도입부의 "괜찮은 디자인"은 별도 단계로 두지 않습니다. 기본 모양은 M1에서 목록과 함께 만들어지고, "나중에 할 것"에는 새 디자인, 즉 테마 변경만 들어갑니다. 요청을 세 단계로 나눠 보겠습니다.

먼저 동작하는 목록이 필요합니다. 이를 기준으로 레코드 선별을 검증하기 편하니까요. 검색과 필터는 어떤 순서로 추가해도 되는데, 여기서는 검색을 먼저 선택했고 M3에서 두 기능이 함께 동작하는지 검증합니다. 단계 사이의 화살표는 이전 결과가 이미 검증되었다는 뜻이고, 초록색 M3는 요청이 완전히 완료되는 단계입니다.

여기서는 작업을 결과 기준으로 나눕니다. 각 단계에는 코드 읽기, 수정, 검증이 모두 포함됩니다. "HTML을 먼저 다 만들고, 그다음 JS를 다 만들고, 마지막에 전부 확인한다"는 계획은 동작 검증을 맨 끝으로 미룹니다. 완성된 마크업도 유용한 중간 결과일 수 있지만, 그것만으로는 검색이 동작하는지 알 수 없습니다.

에이전트는 알아서 이런 계층별 계획, 즉 마크업을 전부 만들고 나서 로직을 전부 만드는 쪽으로 끌리는 경향이 있다는 점을 알아 두세요. AI 에이전트와 많이 작업하는 사람들도 같은 이야기를 합니다. Matt Pocock도 그중 하나로, 자신의 작업 방식에 관한 워크숍에서 이를 언급했습니다. 결과 기준으로 나눠 달라고 명시적으로 요청해도 그런 계획이 나온다는 것이죠. 그러니 에이전트가 제안한 단계는 한 가지 기준으로 검토하세요. 각 단계가 끝난 뒤 무언가를 열어서 동작하는 모습을 볼 수 있는가.

그리고 여기서 세 단계는 예시일 뿐 규칙이 아닙니다. 두 단계일 때도 있고 여섯 단계일 때도 있습니다.

현재 단계에 맞는 컨텍스트 주기

단계를 정했다면 에이전트에게는 프로젝트 전체가 아니라 그 단계에 필요한 정보만 주면 됩니다. 학습용 카탈로그의 M2 요청은 다음과 같은 모습일 수 있습니다.

로케일 목록에 검색을 추가합니다.
네 개 레코드 목록은 이미 동작합니다. 필드와 디자인은 그대로 두고,
원본 배열의 내용은 바꾸지 마세요. 검색에 필요한 요소만 추가하세요.

@index.html과 @app.js를 읽어 주세요.

필요한 것:
- 목록 위에 검색 필드;
- 로케일 코드와 언어 이름으로 검색;
- de-DE와 German 검색어는 de-DE 레코드를 찾는다;
- zzz 검색어는 목록에 아무 행도 남기지 않는다;
- 빈 검색어는 전체 목록을 보여준다.

이번에는 국가별 필터를 추가하지 않습니다.
다른 파일이 필요하면 이름을 말하고 읽으세요.
먼저 결과와 이 단계의 범위를 말해 주세요. 파일은 아직 수정하지 마세요.

제안된 범위가 마음에 든다면 다음 메시지로 M2를 실행하고 브라우저에서 확인할 검증 항목을 나열해 달라고 요청하세요. 이때 에이전트가 직접 확인한 것과 여러분이 앞으로 확인해야 할 것을 구분해 달라고도 하세요.

예시의 경로는 임의로 든 것이고, 여러분은 자신의 파일을 씁니다. 요청에 없는 자료가 필요하다면 에이전트가 그 이름을 말하고 직접 읽어야 합니다. 파일 이름만 보고 내용을 추측하는 것은 좋지 않은 방법이고, 그렇게 해 달라고 요청해서도 안 됩니다.

여기서 디자인은 별개의 정보이고, 이 단계에서는 바로 그것을 그대로 유지합니다. 반대인 경우도 있습니다. 예를 들어 페이지가 처음 등장할 때는 외형 자체가 단계의 결과에 포함됩니다. 말로는 정할 수 없습니다. "예쁘게 만들어 주세요"라는 요청에는 검증할 만한 내용이 전혀 없고, 결정은 에이전트에게 넘어갑니다. 그럴 때는 목업, 스크린샷, 또는 색상과 클래스 이름을 담은 작은 파일 같은 참고 자료를 첨부하세요.

이런 문장에 한계가 있다는 점도 기억해 둘 만합니다. "이번에는 필터를 추가하지 않는다"는 지시일 뿐 기술적인 장벽이 아닙니다. 방향은 정하지만 아무것도 막지는 않으므로, 결과는 여전히 여러분이 직접 확인해야 합니다.

단계를 줄여야 할 때

단계는 작업 도중 점점 커지는 경향이 있습니다. 검색으로 시작했는데 하다 보니 데이터 구조도 바꾸면 좋겠고, 디자인도 새로 손보고, 상단에 내비게이션도 추가하면 좋겠다는 생각이 듭니다. 익숙한 이야기죠.

새로 나온 요청마다 선택한 결과에 정말 필요한지 물어보세요. 새 색상 테마와 내비게이션은 미뤄도 되지만, 눈에 보이는 검색 입력 필드는 꼭 필요합니다. 검색할 정보가 레코드에 부족하다면 먼저 범위를 명확히 하세요. 현재 단계에서 데이터를 보충할 수도 있고, 데이터 준비를 별도의 검증 가능한 단계로 뗄 수도 있습니다. "데이터를 바꾸지 않는다"는 규칙을 작업 도중 조용히 뒤집을 수는 없습니다.

범위를 다시 좁히는 요청은 짧게 끝납니다.

이번에는 데이터, 디자인, 내비게이션을 바꾸지 않습니다.
나중을 위해 별도 항목으로 적어 두세요.
코드와 언어로 검색하는 것만 남깁니다: 입력 필드, 일치 결과, 빈 검색어.

합의된 결과가 나오고 그 검증이 끝나면 단계가 완료됩니다. 검증이 실패했다면 먼저 현재 단계를 해결하세요. 다음 단계로 넘어가면 불확실성만 늘어납니다.

단계가 잘 풀리지 않을 때도 있습니다. 여러분이 에이전트를 바로잡고, 에이전트가 다시 만들고, 또 원하는 결과가 아닙니다. 실패한 시도는 사라지지 않습니다. 대화 속에 그대로 남고, 다음 시도는 그걸 바탕으로 이어집니다. Claude Code 문서는 간단한 기준을 제시합니다. 같은 것을 두 번 넘게 고쳐야 했다면 지금까지 알게 된 모든 내용을 담아 새 대화를 시작하세요. 예를 들어 "검색용 별도 배열 방식은 맞지 않았습니다. 원본 데이터와 어긋납니다. 기본 배열을 직접 검색하세요."처럼요. 이런 요청은 대개 세 번째 수정보다 더 잘 작동합니다. 그래도 도움이 되지 않는다면 단계가 너무 커서 나눠야 할 가능성이 높습니다.

이어갈 지점 저장하기

왼쪽 갈래는 같은 단계의 수정으로 돌아갑니다. 그 결과가 아직 확인되지 않았다는 뜻이죠. 오른쪽 갈래는 상태를 기록하고 다음 단계로 이어집니다. 노트에는 통과한 검증뿐 아니라 검증 범위 밖에 남은 것도 적어 두세요.

결과를 검증했다면 상태를 기록하세요. 노트는 보고를 위한 것이 아니라, 하루가 지나거나 다른 대화에서도 채팅을 뒤지며 히스토리를 복원하지 않도록 하기 위한 것입니다.

파일 이름은 무엇이든 상관없고, 이미 있는 작업 노트를 써도 됩니다. 여기서는 PROGRESS.md라고 하겠습니다. 아래는 M1 검증 후의 학습용 예시입니다. 여러분의 노트에는 실제로 하고 관찰한 것만 적으세요.

# 로케일 카탈로그

## 완료
M1: 페이지가 app.js의 배열에서 로케일 목록을 보여준다.

## 검증됨
index.html을 브라우저에서 열었다: 레코드 4개, 각 행의 다섯 필드가 모두
app.js의 원본 배열과 일치한다.

## 검증 안 됨
데이터 세트가 비어 있을 때 페이지가 무엇을 보여주는지.
이 검증은 M1 기준에 포함되지 않았다. 빈 배열에 대한 동작은 아직 모른다.

## 결정
데이터는 app.js에 배열로 보관하고, 별도의 데이터 로딩은 없다.
검색을 추가할 때 레코드 구성과 디자인은 그대로 유지한다.

## 제외됨
별도 JSON 파일에서 데이터를 불러오는 방식: 서버 없이는 브라우저가
이 파일을 읽을 수 없고, 페이지는 파일로 열려야 한다.

## 파일
index.html, app.js

## 남은 단계
M2: 로케일 코드나 언어 이름으로 검색이 동작한다.
검증: de-DE와 German은 de-DE 레코드를 찾는다;
zzz는 레코드를 찾지 못한다; 빈 검색어는 네 개 모두를 보여준다.

M3: 국가별 필터가 검색과 함께 동작한다.
검증: Canada + French는 fr-CA만 남긴다;
Canada + German은 빈 목록을 반환한다;
두 조건을 모두 지우면 네 개의 레코드가 돌아온다.

## 다음 단계
M2를 실행한다. 국가별 필터는 아직 추가하지 않는다.

여기서 핵심은 "검증됨" 섹션입니다. "다 잘 됩니다"라는 기록은 일주일 뒤에 아무 의미가 없지만, "브라우저에서 열었고, 레코드 4개, 필드가 일치합니다"는 의미가 있습니다. 검증 안 된 내용을 위한 별도 섹션이 필요한 이유는 정확히 이겁니다. 내일이면 그 차이를 기억하지 못하니까요.

"제외됨" 섹션은 프로젝트에 없는 것을 다루므로 불필요해 보이기 쉽습니다. 하지만 새 대화에서 에이전트는 이전 시도에 대해 아무것도 모르기 때문에 같은 방식을 선의로 다시 제안할 수 있습니다. 이유를 한 줄만 적어 두면 같은 시행착오를 한 번 더 겪지 않아도 됩니다.

노트 작성은 에이전트에게 맡길 수 있지만, 현재 파일과 검증 결과에 맞는지 대조하세요. 에이전트는 대화 히스토리에 기댈 수 있는데, 그 안에는 실행한 작업 옆에 계획도 함께 놓여 있습니다. 브라우저에서 관찰한 내용은 누가 확인했는지 밝히세요. 에이전트가 실행하지 않은 검증을 에이전트가 한 것처럼 적지 마세요.

두 가지 제한이 있습니다. 작업의 일시적인 진행 상황은 CLAUDE.md로 옮기지 않습니다. 거기에는 프로젝트의 영구적인 규칙이 있지, 오늘 하고 있는 일이 있는 게 아닙니다. 그리고 노트는 코드 버전을 저장하지 않습니다. 상태에 관한 텍스트일 뿐, 파일의 사본이 아닙니다.

필요한 정보와 함께 이어가기

단계의 경계는 다음에 어떤 대화에서 작업할지 정하기 좋은 지점입니다. 질문은 간단합니다. 지금 대화가 다음 단계에 도움이 되나요, 아니면 이미 방해가 되나요?

도움이 된다면 그 대화에서 계속하세요. 특별히 할 일은 없습니다. "단계마다 대화를 지운다"는 규칙은 존재하지 않고, 몇 퍼센트를 넘으면 새로 시작해야 한다는 기준도 없습니다.

히스토리가 얼마나 자리를 차지했는지 모르겠다면 /context를 실행해 컨텍스트 창 사용량을 확인하세요. 이를 작업 진행 상황과 비교해 보세요. 다음 단계에 어떤 긴 출력과 논의가 계속 필요한가요? 이 명령은 분량을 가늠하는 데 도움이 될 뿐, 어떤 정보가 유용한지는 여전히 여러분의 판단입니다.

관련 없는 내용이 쌓여 깨끗한 대화를 새로 시작하기로 했다면 먼저 노트를 저장하세요. /clear 명령은 새 대화를 시작합니다. 이전 히스토리는 작업 컨텍스트로 넘어가지 않고, 소스 파일은 디스크에 그대로 남으며, 프로젝트 지침은 계속 로드됩니다. 이전 대화를 영구히 삭제하는 것은 아닙니다. 저장된 대화에는 /resume으로 다시 돌아갈 수 있습니다. 다만 새 세션에서 이어가려면 필요한 결정을 명시적으로 전달하는 편이 좋습니다.

작업을 이어가기 전에 두 화살표가 만납니다. 노트는 결정 사항과 검증 결과를 전달하고, 파일은 현재 코드를 보여줍니다. 에이전트는 두 원천을 모두 읽고 상태를 요약합니다. 여러분은 M2를 맡기기 전에 그 답을 확인합니다.

새 대화를 시작하는 모습은 평범합니다.

@PROGRESS.md, @index.html, @app.js를 읽어 주세요.
이미 완료되고 검증된 것과 남은 것을 직접 정리해서 설명해 주세요.
파일은 아직 수정하지 마세요.

답변을 꼼꼼히 읽으세요. 에이전트가 여러분이 하지 않은 일을 완료했다고 말했다면 그 말을 노트, 파일, 검증 결과와 대조하세요. 원인은 부정확한 기록, 오래된 코드, 혹은 에이전트 자체의 실수일 수 있습니다. 새로운 수정에 앞서 불일치를 바로잡으세요. 대화를 새로 시작하는 것만으로는 잘못된 작업 정의가 고쳐지지 않고, 올바른 이해도 보장되지 않습니다.

카탈로그를 처음부터 끝까지 직접 해보기

해설은 여기까지고, 이제 같은 카탈로그를 직접 만들어 볼 차례입니다. 빈 폴더부터 검증된 M2와 이어갈 지점까지요. 네 단계는 글의 순서를 따릅니다. 각 단계에서 먼저 스스로 프롬프트를 작성해 보고, 저희가 준비한 버전은 두 번째 의견으로만 열어 보세요. 목표는 문장을 그대로 베끼는 것이 아니라 에이전트에게 어떤 정보가 필요한지 스스로 결정하는 것입니다.

1단계. 코드 없는 계획

아직 프로젝트가 없으니 가장 먼저 하고 싶은 말은 "카탈로그를 만들어 줘"일 겁니다. 그러면 결정보다 파일이 먼저 생깁니다. 이 단계의 목표는 반대입니다. 파일은 하나도 없이 계획만 받는 것이죠. 입력하기 전에 다음 네 가지를 머릿속으로 짚어 보세요.

• 에이전트가 바로 코드부터 쓰지 않도록 어떻게 막을 것인가;
• 아직 없는 파일 대신 어떤 정보를 줄 것인가;
• 불필요한 도구가 끼어들지 않도록 어떤 기술적 범위를 말해 둘 것인가;
• 아직 만들 것이 없을 때 결과물로 무엇을 요청할 것인가.

저희 버전입니다.

학습용 로케일 카탈로그를 만들고 싶습니다. 레코드 목록, 검색,
국가별 필터가 필요합니다. 아직 프로젝트는 없습니다.

페이지는 서버나 빌드 없이 파일로 브라우저에서 열려야 합니다:
index.html, styles.css, app.js만 씁니다. 레코드 필드는 로케일 코드(en-US),
언어, 국가, 통화, 도메인입니다.

먼저 계획을 세워 주세요:
- 전체 작업의 목표, 범위, 검증 방법을 말해 주세요;
- 작업을 세 단계로 나눠 주세요;
- 각 단계마다 결과와 제가 검증할 때 보게 될 것을 말해 주세요;
- 저에게서 어떤 정보가 더 필요한지 말해 주세요;
- 만들 파일 목록을 알려 주세요.

파일은 아직 만들지 마세요.

받은 단계들을 위의 M1-M3 표와 대조해 보세요. 순서가 다르더라도 괜찮습니다. 에이전트가 "마크업 전부, 그다음 JS 전부"로 나눴다면 각 단계 이후 페이지가 무언가를 할 수 있도록 다시 짜 달라고 요청하세요. 어떤 단계에 눈에 보이는 동작이 명시되지 않았다면 지금 표현을 고치세요. 첫 코드 줄이 나오기 전이라면 한 마디면 충분합니다.

2단계. M1만, 참고 자료와 함께

범위는 좁습니다. 페이지가 레코드 네 개를 보여주는 것, 그게 전부입니다. 검색도 필터도 없습니다. 하지만 외형은 미룰 수 없습니다. 페이지가 처음 나타나는 순간이니 어떤 모습이든 갖게 됩니다. 그러니 참고 자료를 첨부하세요. 프로젝트 폴더에 mockup.html을 저장하는데, JavaScript 없이 색상과 클래스 이름만 있는 정적 마크업입니다.

<style>
  body   { background:#0f172a; color:#e2e8f0; font-family:system-ui, sans-serif; padding:24px }
  .search{ width:100%; margin-bottom:12px; padding:10px 14px; border-radius:10px;
           background:#1e293b; color:#e2e8f0; border:1px solid #334155 }
  table  { width:100%; border-collapse:collapse }
  th, td { padding:10px 12px; text-align:left; border-bottom:1px solid #334155 }
  th     { color:#8b98b1; font-size:13px }
  .code  { font-family:ui-monospace, monospace; font-weight:700; color:#818cf8 }
</style>

<input class="search" placeholder="Search by code or language">
<table>
  <tr><th>Code</th><th>Language</th><th>Country</th><th>Currency</th><th>TLD</th></tr>
  <!-- 샘플 행; 실제 행은 app.js가 그립니다 -->
  <tr><td class="code">en-US</td><td>English</td><td>United States</td><td>USD</td><td>.us</td></tr>
</table>

참고 자료에는 검색 필드가 이미 그려져 있지만, M1에서는 페이지에 옮기지 않습니다. 아무것도 하지 않는 빈 필드는 검증하기 어렵기 때문입니다. 그 스타일은 .search 클래스에 있고 M2에서 쓰입니다.

한 가지 더 있습니다. 데이터는 에이전트에게 명시적으로 줘야 합니다. 그러지 않으면 에이전트가 자기 나름의 데이터를 만들어 내고, 표에 있던 검증 항목(네 개 행, de-DE, Canada)이 맞지 않게 됩니다. 이제 프롬프트입니다. 에이전트를 한 단계 안에 묶어 두는 방법, 수정 전에 무엇을 보여 달라고 할지, 결과를 무엇으로 검증할지 생각해 보세요.

M1만 실행합니다: 페이지가 app.js의 배열에서
로케일 목록을 보여줍니다. 이번에는 검색도 필터도 없습니다.
참고 자료의 검색 필드는 아직 추가하지 마세요.

데이터는 이 네 개 레코드 배열이고, 내용을 바꾸지 마세요:
[글에 있는 배열을 붙여넣으세요]

외형은 @mockup.html에서 가져오세요: 색상과 클래스 이름을 그대로 쓰고,
새로 만들지 마세요.

먼저 파일 계획을 보여주고 어디까지 진행할지 말해 주세요.
제가 계획을 확인하기 전까지는 파일을 만들지 마세요.
수정 후에는 제가 무엇을 열어 무엇과 대조할지 말해 주세요.

M1 이후에는 멈추세요. 제 승인 없이 M2로 넘어가지 마세요.

계획이 커졌다면 승인하지 말고 먼저 검증 가능한 결과 하나로 단계를 줄이세요. 계획이 괜찮다면 수정을 허용하고, 페이지를 열어 네 개 행을 배열과 대조하세요. 이 시점부터 기본 외형은 고정됩니다. 이후로는 그대로 유지되고, 완전한 테마 변경은 나중 항목으로 남습니다.

3단계. M2와 솔직한 노트

M2 프롬프트는 이미 "현재 단계에 맞는 컨텍스트 주기"에서 다뤘습니다. 그리로 돌아가 여러분의 경로로 바꿔 넣으세요. 그 예시에는 파일이 두 개였지만, M1 이후 여러분에게는 세 개가 있습니다. index.html과 app.js에 styles.css가 더해졌으니 이것도 함께 적으세요. 그리고 한 줄을 덧붙이세요. 외형은 이제 정하는 것이 아니라 유지하는 것이라고요.

디자인은 이미 M1에서 @mockup.html로 정해졌습니다. 그대로 유지하고,
검색 필드는 거기 있는 .search 클래스로 꾸며 주세요.

에이전트가 범위를 정확히 말했다면 수정을 허용하세요. 필터나 데이터 구조까지 건드리려 했다면 작업 전에 다시 확인하세요. 검색 검증 세 가지가 통과하면 위의 예시대로 PROGRESS.md에 상태를 기록하되, 이번에는 M2 이후 상태로, 여러분의 파일 목록으로 기록하세요.

그리고 노트가 튼튼한지 시험해 보세요. "검증됨" 섹션 대신 "거의 다 끝났고 조금 남았습니다"라는 줄이 있다고 상상해 보세요. 일주일 뒤에는 아무 의미가 없습니다. 그 노트만 보고도 작업을 이어갈 수 있도록 다시 쓰세요. 정확히 무엇을 열어서 무엇을 봤는지, 검증 범위 밖에 남은 것은 무엇인지, 다음 단계는 무엇인지요. 기준은 이런 식입니다. "M2: de-DE와 German 검색어는 de-DE를 찾고, zzz는 아무것도 찾지 못하고, 빈 검색어는 네 개 레코드를 반환한다", "빈 데이터 세트에 대한 동작은 검증하지 않았다", "다음 단계는 M3, 국가별 필터".

4단계. 깨끗한 대화에서 이어가기

마지막 단계는 코드가 아니라 노트를 검증합니다. 새 대화를 시작해 PROGRESS.md와 최신 파일(styles.css를 포함한 세 개 모두)을 바탕으로 상태를 요약해 달라고 요청한 다음, 그 요약을 여러분이 실제로 한 일과 비교하세요. 에이전트가 여러분이 검증하지 않은 것을 완료했다고 말했다면 노트가 너무 두루뭉술하게 쓰였을 가능성이 큽니다. 해결책은 노트를 고치는 것이지 대화를 또 새로 시작하는 것이 아닙니다. 하지만 파일과도 대조하세요. 원인은 코드에 있을 수도, 에이전트 자체의 실수일 수도 있습니다. 모든 것이 맞아떨어졌다면 여러분에게는 검증된 M1, 검증된 M2, 그리고 M3가 시작될 지점이 있는 것입니다.

다음 단계로 넘어가는 법

최종 순서는 짧습니다.

1. 검증할 수 있는 가장 가까운 결과를 고른다;
2. 에이전트에게 이 단계에 맞는 자료를 주고 범위를 말한다;
3. 현재 단계를 실행한다. 새로 나온 요청은 따로 적어 둔다;
4. 합의된 검증을 실행한다. 우리 예제에서는 브라우저에서 페이지의 동작을 확인한다;
5. 상태를 기록한다: 완료, 검증됨, 검증 안 됨, 제외한 것, 다음 단계;
6. 이 대화를 계속할지 깨끗한 대화를 시작할지 정한다.

한 단계가 메시지 한 개는 아닙니다. 세 개가 들 수도, 열다섯 개가 들 수도 있고, 그건 정상입니다. 단계 수가 대화 수와 같은 것도 아닙니다. 이웃한 단계 두 개가 한 대화 안에서 무리 없이 진행될 수도 있고, 무거운 단계 하나가 두 대화를 차지할 때도 있습니다.

그 대신 어느 시점에서든 지금 무엇이 동작하고 그것이 어떻게 검증되었는지 답할 수 있습니다. 큰 작업에서는 아마 이것이 가장 중요할 것입니다.