Claude Code 만든 사람의 손버릇 — 지우고, 어렵게 주고, 검증시켜라

홍승아2026.08.2212분

1. 이 글은 무엇에 관한 글인가?

한 줄로 요약하면 이렇습니다.

에이전트를 잘 쓰는 법은 더 좋은 지시문을 쓰는 게 아니라, 쓰던 지시문을 지우고 대신 채점기를 만드는 것 입니다.

여기서 채점기 는 에이전트가 스스로 돌려서 통과·실패를 알 수 있는 명령입니다 — 타입체크, 테스트, 스크린샷 비교 같은 것들이요. 이 글 내내 나오는 단어라 먼저 붙여둡니다.

Y Combinator Startup School 2026에서 Diana Hu가 Claude Code를 만든 Boris Cherny를 인터뷰했습니다. 화제가 된 건 주로 무용담이었습니다. "코드베이스 하나를 11일 만에 다른 언어로 재작성했다", "2주째 혼자 도는 작업이 있다", "에이전트를 수천 개 띄웠다".

그런데 무용담은 결과이지 방법이 아닙니다. 이 글은 그 결과를 만든 쪽, 그러니까 조건과 손버릇을 주니어 개발자가 따라 할 수 있는 크기로 풀어 씁니다.

지난 글들은 이런 순서로 왔습니다. FE 하네스로 도구를 어떻게 짜는가 → 자가치유 하네스로 스스로 고치게 하는가 → 덜어내는 컨텍스트 엔지니어링으로 무엇을 뺄 것인가 → Claude 모델 고르기로 어디에 돌릴 것인가. 이번 글은 그 도구를 매일 쓰는 사람의 손버릇 입니다.

이 글의 뼈대 — 동작 세 개

인터뷰 전체를 관통하는 동작은 셋뿐입니다. 나머지는 전부 이 셋의 응용입니다.

① 지운다      내가 써둔 지시문 중 지금 모델에겐 방해인 것을 걷어낸다
② 어렵게 준다  할 수 있을까 싶은 크기로 주고, 방법은 안 정해준다
③ 검증시킨다   틀렸다는 걸 스스로 알 방법을 같이 준다  ← 가장 많이 빠뜨림

셋 중 ③이 빠지면 ①②는 그냥 사고입니다. 지시를 지웠는데 채점기가 없으면 통제가 사라지고, 어려운 일을 줬는데 채점기가 없으면 오래 돌수록 더 멀리 잘못 갑니다.

2. 먼저 좌표 — 모델과 하네스는 다른 층이다

본론에 앞서 층을 하나 나눠야 합니다. 주니어가 가장 자주 하는 귀속 오류가 여기서 나옵니다. 결과가 나쁘면 모델을 의심하지만, 실제로 파일을 읽고 명령을 실행한 건 모델이 아닙니다.

내가 친 프롬프트
      │
      ▼
┌─ 하네스 (Claude Code) ─────────────────────────────────
│  시스템 프롬프트 · 도구 설명 · CLAUDE.md   매 요청마다 다시 읽힌다
│  권한 검사 · 훅                          모델 판단과 무관하게 실행
│           │  위를 전부 합쳐서 넘긴다
│           ▼
│      [ 모델 ]  ← 글자를 이어 만드는 일만 한다
│           │
│           └──▶ 결과를 다시 넣는다 (반복 루프)
└────────────────────────────────────────────────────────
      │
      ▼
화면에 보이는 답

하네스(harness) 는 모델을 감싼 프로그램 전체입니다. Vitest를 떠올리면 됩니다 — 테스트 함수를 짜는 건 나지만, 어떤 순서로 실행하고 무엇을 통과로 볼지는 러너가 정하죠. 모델과 Claude Code의 관계가 정확히 그렇습니다. 같은 모델도 하네스가 다르면 능력이 전혀 달라 보이는 이유입니다.

그리고 하네스가 잘못 개입하는 방향은 둘입니다. 족쇄(hobbling) 는 모델은 할 수 있는데 내 설정이 가로막는 경우(권한이 편집을 거부해 계속 diff만 출력하는 상황 같은 것), 오버행(product overhang) 은 모델은 할 수 있는데 꺼내 쓸 창구를 아예 안 만든 경우입니다. 버전은 올렸는데 changelog를 아무도 안 읽어 팀 전체가 여전히 손으로 구현하고 있는 상태 말이죠. 정리하면 결과가 나쁠 때 먼저 의심할 곳은 모델이 아니라 내 하네스 입니다.

3. 동작 ① — 지운다

Claude Code는 새 모델이 나올 때마다 시스템 프롬프트를 대거 지웁니다. Opus 5 대응으로는 80%를 삭제했고요. 이 사실 자체는 덜어내는 컨텍스트 엔지니어링에서 이미 다뤘으니, 여기서는 어떻게 지우는가 만 봅니다.

먼저 삭제 기준입니다. 길어서 지우는 게 아닙니다.

시스템 프롬프트에 있던 상당수는 모델이 알았어야 했는데 못 하던 행동을 교정하는 내용 이었습니다. 지금 모델은 그냥 합니다.

즉 지워도 되는 건 모델을 고치려고 쓴 줄 이고, 남겨야 하는 건 모델이 알 수 없는 사실 입니다. 이 기준으로 제 블로그 저장소의 CLAUDE.md를 실제로 훑으면 이렇게 갈립니다.

적혀 있는 문장	판정	이유
"테스트 코드를 임의로 지우지 마라"	❌ 삭제 후보	모델 결함 교정용 — 지금 모델은 시키지 않아도 안 지운다
"커밋 전에 `pnpm lint`를 돌려라"	➡️ 훅으로	요청이 아니라 강제 가 필요한 것
"배포는 `develop` → `master` → `gh-pages`"	✅ 유지	추론으로 복원 불가능한 프로젝트 사실
"태그 페이지는 쿼리 기반 필터를 쓴다"	✅ 유지	왜 그 예외가 있는지는 코드 어디에도 안 적혀 있다

두 번째 행의 훅(hook) 은 도구 실행 전후처럼 정해진 시점에 하네스가 무조건 돌리는 명령입니다. 프롬프트는 확률이고 훅은 결정입니다 — "항상 ~해라"가 정말로 항상이어야 한다면 문서가 아니라 훅으로 옮기세요(설정 형식은 버전마다 다르니 claude 문서에서 hooks를 확인하시고요). 그리고 되살리는 조건은 딱 하나입니다.

같은 지점에서 반복해서 넘어질 때 만 되살립니다. 너무 일찍 넣지 마세요. 그 지시문은 쓸 때마다 매번 다시 읽힙니다.

어블레이션 — 지우기는 청소가 아니라 측정이다

이 방법에는 이름이 있습니다. 어블레이션(ablation) — 구성요소를 일부러 빼보고 결과가 얼마나 나빠지는지로 기여도를 재는 실험 방법입니다. 의존성을 하나 빼고 빌드가 여전히 통과하면 그건 없어도 됐던 것이죠. 목적이 청소가 아니라 측정 이라는 게 핵심입니다. 지우고 한 번 돌려보고 "괜찮네" 하는 건 어블레이션이 아니라 그냥 삭제입니다.

"6개월마다 CLAUDE.md·스킬·훅을 다 지워보라"는 조언이 인터뷰에 나오는데, 팀 저장소에서 그대로 하면 사고입니다. 개인 저장소에서, 되돌릴 수 있는 상태로 하세요.

① 브랜치를 판다        git switch -c ablation/claude-md
② 통째로 치운다        mv CLAUDE.md CLAUDE.md.bak
③ 일주일 평소대로 쓴다  고치지 말고 notes/stumbles.md 에 기록만 한다
④ 2회 이상 반복된 것만  한 줄로 되살린다
⑤ 비교한다            diff CLAUDE.md.bak CLAUDE.md
                      → 되살리지 않은 줄 = 이번 세대엔 낭비였던 컨텍스트

참고로 지금 버전(2.1.241)에는 실험용 스위치도 실제로 있습니다.

claude --system-prompt "..."   # 시스템 프롬프트를 통째로 갈아끼운다
claude --bare                  # CLAUDE_CODE_SIMPLE=1 — 훅·자동 메모리·CLAUDE.md 탐색까지 끈다

다만 --bare는 구독 로그인을 안 읽고 ANTHROPIC_API_KEY만 봅니다 — 구독으로 쓰고 있다면 위의 mv 방식이 낫습니다. 플래그는 버전마다 바뀌니 claude --help로 먼저 확인하고, 팀 워크플로를 이 위에 세우지는 마세요.

4. 동작 ② — 어렵게 준다

두 번째 손버릇은 할 수 있을까 싶은 크기로 주고, 방법은 안 정해주는 것 입니다.

인터뷰가 지목한 가장 흔한 실수가 과잉 명세, 즉 앞에서 말한 족쇄 의 대표적인 형태입니다. 그리고 이건 경력이 길수록 더 심한 실패 모드로 명시됩니다. 예전 시스템은 그렇게 만들어야 했으니까요.

이전 (단계로 못 박기):

먼저 posts.ts를 열어서 getAllPosts를 찾고, 거기에 파라미터를 하나 추가하고, 그다음 PostCard.tsx에서 props를 바꾸고, 그다음…

지금 (세 줄로):

과제 — 태그 필터가 URL 쿼리와 뒤로가기에서 어긋나는 버그를 고쳐줘. 가드레일 — 정적 익스포트가 깨지면 안 돼. 기존 라우트 구조는 유지해. 종료 조건 — pnpm test && pnpm typecheck && pnpm build가 전부 통과하면 끝.

과제 · 지켜야 할 선 · 끝났다고 볼 기준. 이 셋만 주고 맡기라는 겁니다. 어느 파일을 어떤 순서로 고칠지는 내가 정할 일이 아닙니다. 순서를 못 박는 순간, 내가 아는 해법의 크기가 그대로 상한이 됩니다.

못 하는 게 아니라 배선이 없는 경우

인터뷰에서 가장 실용적인 장면은 정작 무용담이 아니라 그 앞이었습니다. 2주째 도는 그 유명한 작업도, 시작은 큰 프롬프트가 아니라 확인 질문 두 개였습니다. "맥OS 러너에 접근돼?" → 안 됨 → 붙여줌. "이 저장소에 접근돼?" → 안 됨 → 붙여줌. 본 작업 지시는 그다음이었습니다.

에이전트가 "못 한다"고 할 때, 상당수는 능력이 아니라 배선 문제 입니다. 그러니 큰 프롬프트 앞에 한 줄을 붙이세요. "먼저 필요한 것들에 실제로 접근되는지 확인해서 표로 보고하고, 안 되는 게 있으면 시작하지 마라."

다만 접근을 붙여주는 것과 아무거나 넘기는 것은 다릅니다. 읽기 전용 토큰·개인 저장소·로컬 러너까지가 붙여줄 것이고, 프로덕션 자격증명과 배포 키는 아닙니다. "요즘 모델은 프롬프트 인젝션에 안 넘어간다"는 말이 돌지만, 인터뷰의 표현도 "우리는 더 이상 재현해내지 못한다" 는 경험적 진술이고 그것도 모델 단독이 아니라 세 겹(정렬 학습 + 전 트래픽 탐지 분류기 + 자동 모드 분류기)을 쌓은 결과입니다. 재현 실패는 불가능의 증명이 아닙니다.

5. 동작 ③ — 검증시킨다

여기가 이 인터뷰의 진짜 알맹이입니다. 사람들이 제대로 못 하는 것 중 가장 중요한 하나로 꼽는 게 있는데, 프롬프트가 아닙니다.

검증(verification)이야말로 사람들이 제대로 해내지 못하는 것 중 아마도 가장 중요한 하나입니다.

"The verification is probably the single most important thing that people do not get right, largely."

여기서 검증 수단의 목적이 품질이 아니라는 점이 중요합니다. 막히지 않는 것 이 목적입니다. 스스로 확인할 방법이 있으면 사람이 안 봐도 혼자 진행하니까요.

	채점기 없음	채점기 있음
5분 뒤	맞는지 아직 아무도 모름	첫 실패가 이미 찍힘
1시간 뒤	사람이 계속 붙어 있어야 함	혼자 진행
하루 뒤	되돌릴 수 없게 멀리 감	방향이 수렴함

시간이 지날수록 격차가 벌어진다 는 게 핵심입니다.

11일이 가능했던 진짜 이유

화제가 된 사례부터 봅시다. Bun(Node.js 대신 쓰는 자바스크립트 런타임)의 코드베이스를 Zig에서 Rust로 통째로 옮긴 작업이 11일 만에 끝났고, 지금 프로덕션에 올라가 있습니다. 사람이 했다면 1년 이상 걸릴 일이라고 합니다.

그런데 인터뷰가 강조하는 건 모델이 아닙니다.

Bun의 좋은 점은 테스트가 아주 촘촘하다 는 것입니다. Bun에도 큰 테스트 스위트가 있고 Node.js에도 있습니다. 그래서 제대로 옮겼는지 알기가 쉽습니다.

Bun은 Node 호환을 목표로 하니 Node의 테스트 스위트까지 그대로 채점기로 빌려 쓸 수 있었던 겁니다. 채점기가 먼저 있었기 때문에 가능했던 일이지, 검증할 수 없는 코드베이스에 같은 프롬프트를 던지면 이 결과는 안 나옵니다. 한 방에 된 것도 아니고요 — 중간에 사람이 방향을 잡아줬다고 본인이 곧바로 정정합니다.

두 번째 사례는 더 노골적입니다. Electron으로 만든 데스크톱 앱을 Swift로 다시 쓰라고 시키면서 준 지시가 이겁니다.

Electron 앱을 Swift로 다시 써라 → 맥 가상머신에서 실행해라
  → 스크린샷을 찍어라 → Swift 버전과 픽셀 단위로 비교해라
  → 끝날 때까지 멈추지 마라

여기서 실행 → 스크린샷 → 픽셀 비교 가 통째로 채점기입니다. 프롬프트의 절반이 "무엇을 만들라"가 아니라 "무엇으로 판정하라"에 쓰였다는 점을 보세요. 참고로 이 작업은 인터뷰 시점에 2주 넘게 여전히 돌고 있었습니다.

프롬프트를 쓰기 전에 답해야 하는 한 문장

그래서 실무 지침은 아주 단순해집니다. 프롬프트를 쓰기 전에 이 질문에 답하세요.

에이전트가 무엇을 실행하면 자기가 틀렸다는 걸 알 수 있나?

답이 없다면, 그것부터 만드는 게 오늘의 작업입니다. 싼 것부터 셋만 기억하면 됩니다. ① 타입·린트 (없으면 이것부터) → ② 실패하는 테스트 (고쳐야 할 걸 빨간불로 먼저 박아둔다) → ③ 실행 결과 비교 (스크린샷·스냅샷·벤치마크 — 눈으로 볼 것을 기계가 보게 한다).

그리고 루프를 프롬프트에 박아 넣습니다.

작업 → 검증 명령 실행 ─┬─ 통과 → 다음 단계
                       └─ 실패 → 원인 수정 → 다시 실행
                                   │
                    같은 실패 3회 ─┘→ 멈추고 보고

마지막 줄이 중요합니다. 중단 기준을 시작 전에 정해두지 않으면 검증 루프는 요금만 늘립니다. 그리고 정직하게 남겨둘 것 하나 — 검증 루프는 기능 회귀만 잡습니다. 설계 부채도 보안도 초록불이 판정해주지 않고, 에이전트가 만든 대규모 변경을 사람이 어떻게 리뷰할 것인가에 대한 답은 인터뷰에 없었습니다.

6. 세 동작을 곱하면 — 반복과 오케스트레이션

여기까지가 개인의 손버릇이고, 이걸 곱하는 장치가 인터뷰 후반에 나옵니다. 이름만 정리해두면 충분합니다.

장치	무엇을 하나	익숙한 비유
다이나믹 워크플로	큰 일 하나 를 단계로 쪼개고 단계마다 에이전트를 펼친다	매트릭스 잡으로 팬아웃했다 다음 스테이지에서 모으는 CI
loop	같은 일을 주기적으로 반복한다 (내 컴퓨터에서)	로컬 크론
routine	같은 일을 주기적으로 반복한다 (클라우드에서)	매일 새벽에 도는 GitHub Actions 스케줄 잡

반복 실행은 매번 대화 문맥이 초기화됩니다(메모리는 공유될 수 있다고 합니다). 그러니 확실히 이어져야 하는 정보는 파일·이슈·PR처럼 바깥에 남겨두는 편이 안전합니다.

Anthropic은 이 routine을 자기 코드베이스 유지보수에 매일 20~30개씩 돌리고 있다고 합니다. 죽은 코드 찾아 삭제 PR 올리기, 100%까지 나간 실험 정리하기, 커버리지 빈 곳에 테스트 추가하기, 쓸모없어진 테스트 삭제하기, 그리고 여러 곳에 흩어진 거의 같은 추상화를 찾아 합치기(본인이 "아마 abstraction police라고 불렀던 것 같다"고 한 루틴)까지.

여기서 주니어가 가져갈 크기는 개인 저장소에 하나 입니다.

프롬프트 — "이 저장소에서 어디서도 참조되지 않는 코드를 찾아 삭제하고, 테스트와
            타입체크가 통과하면 PR을 올려라. 확신이 없는 항목은 지우지 말고
            PR 본문에 목록으로만 남겨라."
 
규칙   — ① 반드시 PR로만 (기본 브랜치 직접 커밋 금지)
          ② 첫 주는 매일 직접 읽고 오탐률을 기록
          ③ 익숙해진 다음에 두 번째 루틴

20~30개는 리뷰를 흡수할 팀과 사내 인프라가 있을 때의 숫자 입니다. 팀 저장소에 합의 없이 봇 PR을 밀어넣으면 내가 아낀 시간을 동료의 리뷰 시간으로 옮긴 셈이라, 기술적으로 성공해도 사회적으로 실패합니다. 그리고 매일 도는 크론은 매일 청구됩니다.

7. 오해하기 쉬운 지점

오해 1 — "11일, 수천 개 에이전트… 나도 그렇게 해야 하나?"

아닙니다. 11일짜리 재작성은 한 방에 된 게 아니라 중간에 사람이 방향을 잡아준 결과이고, 애초에 재작성을 시도해보자고 결정하고 테스트 스위트를 정의한 것도 Bun 팀의 엔지니어였습니다. "수천 개"라는 숫자도 확인된 값이 아니라 본인의 추측입니다. 에이전트 개수는 성과 지표가 아니라 청구서 입니다. 개인 요금제라면 11일이 아니라 몇 시간 단위로 내리고, 중단 기준부터 정하세요.

오해 2 — "코딩은 이제 해결됐다"

"코딩은 해결됐다"는 말은 이 대담에서 진행자가 그의 과거 발언 으로 끌어온 것이고, 정작 본인은 그 질문을 받자마자 단서부터 답니다.

코딩은 제가 하는 종류의 코딩 에 한해 해결됐습니다. 모두에게 해결된 게 아닙니다.

그가 직접 지목한 미해결 영역은 깊은 시스템 코드베이스, 분산 시스템, 그리고 픽셀 단위 UI 검증입니다. 주니어의 실무는 상당 부분 이 영역과 겹칩니다.

오해 3 — "그럼 다 지우면 되겠네"

지우기는 절차의 1단계일 뿐입니다. 지우고 → 쓰고 → 반복해서 넘어지는 것만 되살리기 가 전체입니다. 그리고 프롬프트를 다 없앴을 때 모델이 조금 더 똑똑해 보이더라는 관찰에는 바로 뒤에 단서가 붙습니다 — 제품으로 쓸 때는 사용자가 기대하는 방식으로 동작하게 하려고 일부 프롬프트를 일부러 남긴다고요.

오해 4 — "그래서 잘 쓰는 사람만 아는 비법이 있는 거네"

이건 인터뷰가 가장 직접적으로 부정한 부분입니다.

다들 "한 방에 되는 요령" 을 찾는데, 그런 건 없습니다.

그리고 이 원칙은 인터뷰 자체에도 적용됩니다. 한 회사, 한 스택, 한 사람의 관찰이지 통제된 증거가 아닙니다. 결론을 복사하지 말고 절차를 복사하세요 — 돌려보고, 어디서 막히는지 보고, 그것만 고치는 절차 말입니다.

8. 정리 — 지울 것과 만들 것

이 글의 조언을 압축하면 한 표입니다.

	무엇을	왜
지운다	모델을 고치려고 써둔 지시문	매 요청마다 다시 읽히는 비용이고, 지금 모델엔 방해다
어렵게 준다	방법이 아니라 과제·가드레일·종료 조건	순서를 못 박으면 내 해법 크기가 상한이 된다
검증시킨다	틀렸다는 걸 스스로 알 명령어	이게 없으면 오래 돌수록 더 멀리 잘못 간다

그리고 이건 앞선 글들과 같은 이야기의 다음 칸이기도 합니다.

FE 하네스 — 하네스를 만들기
자가치유 하네스 — 하네스가 스스로 고치는 루프
덜어내는 컨텍스트 엔지니어링 — 컨텍스트를 덜어내기
Claude 모델 고르기 — 모델을 고르기
이번 글 — 무엇이 정말 필요했는지 측정하기

핵심 메시지는 하나입니다.

지울 것은 모델을 고치려던 지시문이고, 만들 것은 모델이 스스로 틀렸음을 알 수 있는 명령어입니다.

마지막으로 한 가지. 인터뷰 끝에서 "그럼 학생은 뭘 손으로 배워야 하나"라는 질문에 돌아온 답은 '컴퓨터과학 말고'가 아니라 '컴퓨터과학 에 더해'였습니다. 이론만이 아니라 그걸 적용하는 법 — 설계 감각, 비즈니스 감각, 데이터 사이언스, 사용자와 대화하는 법 — 을 같이 기르라는 것이었죠. 코드를 에이전트에게 넘기는 건 괜찮습니다. 다만 그 결과가 좋은지 나쁜지 가리는 판단까지 넘기면, 이 글의 나머지 조언이 전부 무너집니다. 채점기를 만드는 것도 결국 그 판단이 있어야 할 수 있는 일이니까요.

참고 문서

Y Combinator, Boris Cherny: We Cut 80% of Claude Code's Prompt (2026) — 영상
Root Access, Boris Cherny: Building Claude Code (2026) — 대담 전문
Anthropic, Claude Code documentation — 플래그·기능은 버전마다 다르니 claude --help로 확인
이전 글 — 덜어내는 컨텍스트 엔지니어링 · Claude 모델 고르기 · 자가치유 하네스