21. 효과적인 프롬프팅과 큰 코드베이스

🎯 이 장의 목표

피드백 루프(테스트·브라우저·스크린샷)로 결과 품질을 높이는 법을 안다
큰 코드베이스를 다룰 때의 컨텍스트 전략을 안다
"context rot"(긴 세션의 품질 저하)을 이해하고 대응한다
검증 가능한 작업으로 만들어 신뢰도를 높인다

다시, 핵심은 컨텍스트

5장에서 프롬프트의 기본을 다뤘습니다. 이 장은 그 위에 실전 기법을 얹습니다. 거의 모든 베스트 프랙티스가 하나의 제약에서 나옵니다: Claude의 컨텍스트 윈도우는 빠르게 차고, 차오를수록 성능이 떨어진다(4장).

이걸 context rot(컨텍스트 부패)이라 부릅니다. 세션이 길어질수록 오래된 컨텍스트의 가중치가 떨어지고 초기 지시가 뒷전으로 밀리며, 실패가 컨텍스트를 더 늘려 다음 호출이 더 나빠지는 악순환입니다.

flowchart LR
    A[긴 세션]:::danger --> B[오래된 컨텍스트 가중치↓]:::danger
    B --> C[초기 지시 뒷전]:::danger
    C --> D[실패 → 컨텍스트 더 늘어남]:::danger
    D --> A
    E[대응: 작은 스코프 + 자주 /clear]:::result

    classDef danger fill:#EF9A9A,stroke:#E53935,color:#000
    classDef result fill:#A5D6A7,stroke:#43A047,color:#000

피드백 루프: 스스로 검증하게 하라

가장 강력한 패턴은 Claude가 자기 작업을 검증할 수 있는 루프를 만들어 주는 것입니다. 검증 수단이 있으면 Claude가 "되는지 확인하고 안 되면 고치는" 반복을 스스로 돕니다.

테스트로 피드백 주기

CODE

> 이 함수에 대한 테스트를 먼저 작성하고,
  구현한 뒤 테스트가 통과하는지 직접 실행해서 확인해줘.
  통과할 때까지 반복해.

테스트는 AI 코딩에서 더더욱 중요합니다. AI가 만든 코드는 겉보기엔 "되는 것 같아도" 미묘한 버그가 있을 수 있어, 테스트가 유일한 신뢰할 검증 수단인 경우가 많습니다.

스크린샷·브라우저로 피드백 주기

UI 작업이라면 스크린샷을 붙여넣어 시각적 피드백을 줄 수 있습니다(5장). 에러 화면, 잘못된 레이아웃을 보여주면 Claude가 무엇이 틀렸는지 봅니다.

더 나아가 브라우저 접근을 주면(MCP·플러그인) Claude가 직접 페이지를 열어 결과를 확인하고 고치는 루프를 만들 수 있습니다. 두 강의 모두 "스크린샷으로 피드백"과 "브라우저 접근으로 피드백 루프"를 강조했습니다.

flowchart TB
    A[Claude가 변경]:::agent --> B[검증<br/>테스트 실행 / 스크린샷 / 브라우저]:::tool
    B --> C{통과?}:::danger
    C -->|아니오| D[차이를 보고 수정]:::agent
    D --> A
    C -->|예| E[완료]:::result

    classDef agent fill:#80DEEA,stroke:#00ACC1,color:#000
    classDef tool fill:#90CAF9,stroke:#1E88E5,color:#000
    classDef danger fill:#EF9A9A,stroke:#E53935,color:#000
    classDef result fill:#A5D6A7,stroke:#43A047,color:#000

큰 코드베이스 다루기

큰 코드베이스의 핵심 도전은 "전부 다 보여줄 수 없다"는 것입니다. 전략:

전략	방법	참고
경로를 짚어주기	"src/auth/부터 봐" — 추상적 표현 대신 정확한 위치	6장
탐색은 서브에이전트	Explore로 열린 탐색을 격리 실행	13장
CLAUDE.md로 구조 안내	폴더 목적·아키텍처를 미리 알려주기	9장
작은 스코프로 쪼개기	"전체 리팩터" 대신 "이 함수"	5장
계획 먼저	Plan Mode로 탐색→계획→구현	7장

💡 팁

일부 모델은 매우 큰 컨텍스트 윈도우를 제공해 모노레포·전체 문서를 한꺼번에 담을 수 있습니다. 하지만 "담을 수 있다"와 "담는 게 효율적이다"는 다릅니다 — 큰 컨텍스트도 채우면 비용·context rot이 따라옵니다(22장).

좋은 프롬프트가 탐색 토큰을 아낀다

"버그 고쳐줘"는 Claude가 코드베이스를 뒤지고 무엇을 찾았는지 설명하게 만들어 탐색 토큰을 낭비합니다. 반면 "src/routes/users.ts 42번 줄의 null 체크가 틀렸어"는 곧장 수정으로 갑니다. 적게 탐색하고, 많이 행동하게 — 이게 품질과 비용을 동시에 잡습니다.

전통적 엔지니어링 원칙은 여전히 중요

AI와 일할 때 오히려 더 중요해지는 것들:

작은 변경 단위: 변경은 필요한 것만 건드리기(surgical changes). 안 망가진 걸 "개선"하지 않기.
기존 스타일 따르기: 내가 다르게 짤지라도 기존 코드 스타일에 맞추기.
테스트·리뷰: AI 코드의 "겉보기엔 됨"을 잡아내는 안전망.
버전 관리: 체크포인트와 Git(18장).

📌 핵심

좋은 코드 리뷰 스킬은 버그를 커밋 전에 잡아, "방금 넣은 버그 고쳐줘" 같은 왕복을 줄여 토큰까지 아낍니다(12장).

⚠️ 과잉 검출 주의: "빈틈을 찾아라"라고 시키면 리뷰어는 멀쩡한 코드에서도 뭔가를 보고합니다. 그걸 다 쫓으면 불필요한 추상화·방어 코드·일어날 수 없는 케이스 테스트로 과잉 엔지니어링이 됩니다. "정확성이나 요구사항에 영향을 주는 빈틈만 보고하고 나머지는 선택사항으로 두라" 고 지시하세요.

이 장에서 배운 것

거의 모든 베스트 프랙티스는 "컨텍스트는 빨리 차고 차면 성능이 떨어진다"는 제약에서 나온다. 긴 세션의 context rot을 경계한다.
피드백 루프(테스트·스크린샷·브라우저)를 만들어 Claude가 스스로 검증·수정하게 한다.
큰 코드베이스는 경로 지정·서브에이전트 탐색·CLAUDE.md 구조 안내·작은 스코프·계획 먼저로 다룬다.
구체적 프롬프트가 탐색 토큰을 아낀다. 전통적 엔지니어링 원칙(작은 변경·테스트·버전 관리)은 더 중요해진다.
리뷰는 "정확성에 영향 주는 것만"으로 한정해 과잉 검출을 막는다.

✍️ 확인 문제

"context rot"이 무엇이며, 이를 줄이는 가장 기본적인 대응은 무엇인가요?
UI 작업에서 Claude에게 피드백 루프를 만들어 주는 방법 두 가지는?
"버그 고쳐줘"보다 "src/x.ts 42번 줄 null 체크가 틀렸어"가 비용 면에서 나은 이유는?

다음 장: 22. 비용·토큰 관리 — $47,000 청구서를 피하는 법.

← 이전20. 원격 제어와 자동화 루프다음 →22. 비용·토큰 관리