계획부터 합의하기

작은 요청은 바로 만들어도 된다. 하지만 "결제 페이지를 만들어줘"처럼 큰 작업을 곧장 구현하게 하면, 에이전트는 여러 결정을 혼자 내리며 수백 줄을 쏟아낸다. 그 방향이 틀리면 전부 되돌려야 한다. 큰 작업일수록 먼저 계획을 받아 합의한 뒤 구현에 들어가는 편이 훨씬 안전하고 빠르다.

학습 목표

• 언제 계획부터 받아야 하는지 판단할 수 있다.
• 에이전트에게 구현 전 계획을 요청하고 검토할 수 있다.
• 큰 작업을 검토 가능한 단계로 쪼갤 수 있다.

왜 계획을 먼저 받나

구현은 코드 수정이라 되돌리는 비용이 크지만, 계획은 글이라 고치는 비용이 거의 0이다. 방향이 틀렸다면 코드 300줄보다 계획 한 줄을 고치는 편이 압도적으로 싸다.

• 의도 오해를 코드가 쌓이기 전에 잡는다.
• 빠진 요구사항(에러 처리, 빈 상태, 권한 등)을 미리 드러낸다.
• 큰 덩어리를 검토 가능한 단계로 자연스럽게 나눈다.

구현 전에 계획을 요청한다

"바로 만들지 말고 계획부터 달라"고 명시적으로 말한다. Claude Code에는 코드를 수정하지 않고 분석·계획만 수행하는 플랜 모드가 있다. 입력창에서 Shift+Tab으로 권한 모드를 순환하면 플랜 모드로 전환되며, 이 상태에서는 에이전트가 파일을 고치지 않고 계획만 제안한다. 큰 작업을 시작할 때 활용하면 좋다.

> 댓글 기능을 추가하려고 해. 바로 코드를 짜지 말고,
> 먼저 어떤 파일을 만들고 고칠지, 데이터 구조와 단계별 순서를 계획으로 보여줘.
> 내가 검토한 뒤에 진행할게.

에이전트가 내놓은 계획을 읽고, 다음을 점검한다.

• 내가 의도한 것과 같은가?
• 빠진 경우(에러, 빈 목록, 인증 실패)는 없는가?
• 단계가 너무 크지 않은가? 각 단계를 따로 실행·확인할 수 있는가?

계획을 함께 다듬는다

계획은 협상의 대상이다. 마음에 안 드는 부분을 짚어 고쳐 달라고 한다.

> 좋아. 다만 3번 단계에서 새 라이브러리를 추가하지 말고,
> 이미 쓰고 있는 fetch 래퍼를 사용해줘.
> 그리고 댓글 삭제 기능은 이번 범위에서 빼자.

범위를 줄이는 것도 중요한 결정이다. 한 번에 다 하려 하지 말고, 이번에 꼭 필요한 것만 남긴다.

단계로 쪼개는 기준

좋은 단계는 각각 독립적으로 실행하고 눈으로 확인할 수 있는 크기다.

1. 댓글 데이터 타입과 목 데이터 정의 → 화면에 목록만 렌더
2. 댓글 작성 폼 추가 → 제출하면 목록에 추가(메모리)
3. 백엔드 API 연결 → 새로고침해도 유지
4. 에러/빈 상태 처리 → 실패 시 메시지, 댓글 없을 때 안내

각 단계가 끝날 때마다 실행해서 확인하고 커밋한다(다음 강의 주제). 이렇게 하면 어느 단계에서 문제가 생겼는지 바로 알 수 있다.

작은 작업까지 계획할 필요는 없다

오해를 막기 위해: 모든 요청에 계획서가 필요한 건 아니다. 버튼 색 바꾸기, 오타 수정, 함수 하나 추가 같은 작업은 바로 시키는 게 효율적이다. 계획은 결정이 많고 되돌리기 비싼 작업을 위한 도구다. 작업 규모에 맞게 골라 쓴다.

요약

큰 작업은 구현 전에 계획을 받아 합의하는 것이 핵심이다. 계획은 고치는 비용이 싸고, 의도 오해와 빠진 요구사항을 일찍 드러내며, 작업을 검토 가능한 단계로 나눠 준다. 플랜 모드를 활용해 계획을 받고, 범위를 함께 다듬고, 단계마다 실행·확인하라. 단, 작은 작업까지 매번 계획할 필요는 없다.