⚡ 3줄 요약
- AI 코딩 도구가 느려지는 진짜 원인은 느린 생성이 아니라 어긋난 목표다.
- 큰 작업은 코드부터 짜게 하지 말고 계획 모드(읽기 전용)로 먼저 이해시킨다.
- 속도의 기준은 ‘얼마나 빨리 짰나’가 아니라 ‘재작업을 얼마나 안 했나’다.
Claude Code나 Codex를 처음 붙여보면 다들 같은 착각을 한다. “코드를 빨리 뽑아주니까 일이 빨라지겠지.” 그런데 며칠 써보면 이상한 일이 벌어진다. 코드는 분명 몇 초 만에 나오는데, 하루가 끝나면 오히려 더 지친다. 원인은 도구의 속도가 아니다. 내가 원한 것과 도구가 이해한 것이 어긋나 있었기 때문이다. 코드 생성은 이 작업에서 가장 싼 부분이다. 비싼 건 그 뒤에 붙는 검토, 설명, 재작업이다.
짧은 지시는 빠른 게 아니라 비싼 것이다
기능 이름 하나에 “이거 만들어줘”만 던지면, 도구는 빈칸을 스스로 메운다. 화면이 어떻게 생겨야 하는지, 규칙이 무엇인지, 기존 코드와 어떻게 엮이는지를 전부 추측한다. 추측이 맞으면 운이 좋은 거고, 틀리면 그때부터 진짜 일이 시작된다 — 예제만 던진 도구가 오히려 더 느렸다는 실측도 같은 이야기다. 결과를 뜯어보고, 뭐가 틀렸는지 말로 설명하고, 다시 시켜야 한다. 이 왕복이 두세 번 돌면 코드 생성으로 아낀 몇 초는 흔적도 없이 사라진다.
원문 저자의 표현이 정확하다 — “코딩 에이전트와 목표가 어긋나면 시간이 엄청나게 든다.” 도구를 무엇으로 고르느냐보다, 요청을 어떻게 구성하느냐가 결과를 더 크게 가른다.
⚠️ 가장 흔한 착각
“짧게 시키는 게 빠르다”는 건 착각이다. 짧은 지시는 도구에게 추측할 여지를 넘기는 행위고, 그 추측 비용은 나중에 검토 시간으로 청구된다. 앞에서 5초 아끼고 뒤에서 20분 쓴다.
목표를 맞춘다는 건 배경을 붙여준다는 것
목표 정렬은 거창한 개념이 아니다. 내가 원하는 결과와 도구가 이해한 조건을 같은 방향으로 세우는 일이다. 방법은 단순하다. 기능 이름만 적지 말고, 사용자가 보게 될 화면, 지켜야 할 규칙, 기존 기능과의 관계를 함께 넣는다.
여기서 중요한 발상 전환이 하나 있다. 배경 자료는 새로 쓰는 게 아니라 이미 회사 어딘가에 있다. Slack 대화에 붙은 스크린샷, Notion에 정리된 기능 규칙과 제품 맥락. 원문 저자도 좋은 출처로 “관련 스크린샷이 담긴 Slack 메시지나 Notion 지식 베이스”를 꼽는다. 새 문서를 쓰느라 시간 빼지 말고, 있는 자료를 지시문에 연결하면 된다. 단, 도구가 그 자료에 실제로 접근할 수 있는지는 확인해야 한다.
| 지시문에 넣을 것 | 이유 |
|---|---|
| 구현할 기능과 원하는 최종 상태 | 도구가 ‘완료’를 판단할 기준이 된다 |
| 배경·규칙·화면 자료·참고 문서 | 추측할 여지를 없앤다 |
| 기존 코드에서 확인할 범위 | 엉뚱한 파일을 건드리지 않게 한다 |
| 지켜야 할 조건 / 제외할 범위 | 과잉 구현을 막는다 |
| 완료 여부 판단 기준 | 검증을 도구에게도 사람에게도 명확히 한다 |
지시문이 길어지는 걸 두려워할 필요는 없다. 결과에 영향을 주는 정보라면, 짧게 줄이는 것보다 빠짐없이 주는 편이 낫다. 길이가 문제가 아니라 빈칸이 문제다.
큰 작업은 코드부터가 아니라 ‘계획 모드’부터
여러 파일과 규칙을 건드리는 작업이라면, 바로 코드를 바꾸게 하지 마라. Claude Code에는 계획 모드(Plan Mode)가 있다. Shift+Tab으로 진입하면 도구가 코드를 수정하지 않고 저장소를 읽기 전용으로 훑은 뒤 구현 계획을 세운다. 이 모드에선 파일 쓰기·코드 편집·셸 실행이 아예 거부된다. 읽고, 검색하고, 질문만 한다.
원문의 정의가 간결하다 — “계획 모드는 본질적으로 에이전트가 저장소를 읽기 전용으로 훑고, 요청한 기능을 어떻게 구현할지 계획을 세우게 하는 것”이다. 핵심은 순서다. 구현보다 이해가 먼저 온다. 사람은 코드가 바뀌기 전에 도구가 어떤 파일과 구조를 근거로 삼는지 확인할 수 있다.
계획 모드의 진짜 가치는 여기서 나온다. 사람이 도구의 속을 추측하며 질문을 던지는 대신, 도구가 먼저 빈 조건을 드러내며 질문하게 만드는 것이다. “제 이해가 맞습니까?”라고 되묻게 하면, 도구는 확인하거나, 부분 정정하거나, 아예 틀린 전제를 바로잡는다.
🧭 이 기법이 통하는 이유 — webhook vs cron 사례
원문 저자는 어떤 시스템이 “10분마다 도는 cron job”으로 동작한다고 믿고 있었다. 계획 모드에서 도구가 코드를 읽고 나서 알려준 사실은 달랐다. 실제로는 특정 사건 뒤에 알림을 보내는 webhook이었다. 사람이 틀린 전제로 지시했다면 계획 전체가 어긋났을 것이다. 코드를 한 줄도 바꾸기 전에 오해가 잡힌 셈이다.
계획을 받아보면 이런 걸 점검한다.
- 수정하려는 파일과 기능 범위가 실제로 맞는가
- 기존 규칙과 화면 요구사항이 계획에 반영됐는가
- webhook(사건 기반 알림)과 cron job(정해진 시각 실행)을 혼동하지 않았는가
- 계획에 없던 변경이 슬쩍 끼어들지 않았는가
계획이 목표와 다르면 구현 전에 바로잡는다. 계획과 조건이 맞아떨어질 때 비로소 실제 코드 작성을 요청한다.
그렇다고 모든 작업에 계획을 강요하지 마라
여기서 균형이 필요하다. 오탈자 수정이나 범위가 뻔한 작은 변경에까지 긴 지시문과 계획 단계를 붙이면, 확인 절차 자체가 짐이 된다. 작은 작업은 짧게, 큰 작업은 이해와 계획을 얹어서. 이게 전부다.
| 작업 상황 | 권장 방식 | 확인할 내용 |
|---|---|---|
| 작은 수정 (오탈자 등) | 짧고 분명한 지시문 | 변경 파일·완료 조건 |
| 새 기능 구현 | 배경 자료 포함 상세 지시문 | 화면·규칙·기존 구조 |
| 여러 영역을 바꾸는 작업 | 계획 모드 → 구현 | 계획 범위·빠진 조건 |
| 기존 연결 방식 탐색 | 관련 문서·업무 대화 제공 | webhook과 cron의 구분 |
이 표는 고정 규칙이 아니다. 작아 보여도 기존 구조를 크게 흔드는 변경이라면 계획 단계를 추가한다. 판단 기준은 ‘작업 크기’가 아니라 ‘도구가 추측해야 할 빈칸의 크기‘다.
🎯 FEEDON의 선택 — 우리라면 이렇게 한다
AI 코딩 도구를 ‘더 빠른 타이핑’으로 보는 순간 진다. 우리는 이걸 ‘추측을 줄이는 협업’으로 본다. 도구는 이미 충분히 빠르다. 병목은 언제나 사람과 도구 사이의 오해에 있다.
그래서 순서는 늘 같다 — 원하는 결과를 한 문장으로 → 배경·규칙·자료 붙이기 → 큰 작업이면 계획 모드로 이해 확인 → 그다음 구현. 그리고 마지막 한 가지, 계획을 아무리 잘 세웠어도 최종 코드 검토는 절대 생략하지 않는다. 배경을 많이 줬다고 도구가 의도를 100% 이해한다는 보장은 없다. 화면이 요구사항과 맞는지, 예외를 처리하는지, 기존 기능을 깨지 않는지는 사람이 확인한다.
도구의 효과를 재는 잣대도 바꿔야 한다. ‘얼마나 빨리 짰나’가 아니라 ‘검토·피드백·재작업에 든 시간까지 합쳐서 결국 빨라졌나’다. 이 잣대로 보면 짧은 지시가 왜 손해인지 한눈에 드러난다.
내일 당장 바꿀 것
- 새 기능을 맡기기 전, 원하는 결과를 한 문장으로 먼저 적는다
- 그 문장에 배경·규칙·화면 자료·참고 문서(Slack·Notion)를 붙인다
- 여러 파일에 걸친 작업이면 계획 모드로 저장소부터 읽힌다
- 계획이 내 의도와 맞는지 확인한 뒤 구현을 시작한다
- 구현이 끝나면 속도와 무관하게 코드를 검토한다
반대로 이건 피한다 — 기능 이름만 던지고 결과를 추론에 맡기기, 화면·규칙 없이 코드부터 만들게 하기, 계획이 어긋나는데 그대로 밀어붙이기, 빨리 나왔다는 이유만으로 품질을 인정하기.
내일 당장 바꿀 순서
🛠️ 목표부터 맞추고 시작하기
- 기능 이름만 던지지 말고, 원하는 최종 결과를 한 문장으로 먼저 적는다.
- 그 문장에 화면·규칙·기존 코드 범위, 그리고 Slack·Notion에 이미 있는 배경 자료를 연결한다. 도구가 그 자료에 접근되는지도 확인한다.
- 여러 파일·규칙을 건드리는 작업이면 Shift+Tab으로 계획 모드에 들어가 저장소를 읽기 전용으로 훑고 계획부터 세우게 한다.
- 도구가 내놓은 계획에서 파일 범위·빠진 조건·전제 오해(webhook을 cron으로 착각 같은)를 짚고, 어긋나면 구현 전에 바로잡는다.
- 계획이 맞을 때만 구현을 시키고, 빨리 나왔든 아니든 최종 코드는 사람이 반드시 검토한다.
출처: Towards Data Science 「How to Effectively Align Your Intent with Claude Code」, Anthropic Claude Code 문서(Plan Mode) · 도구 사양은 변동될 수 있음
이 글은 FEEDON이 공개 1차 자료를 바탕으로 작성·검증했습니다.
