코딩 에이전트가 덜 삽질하게 만드는 프롬프트 한 줄 2026 — 100% 이해 전 질문 규칙 체크리스트

Posted on by

AI한테 코딩 시켰더니 원하는 것과 완전히 다른 걸 만들어 온 적 있죠?

“로그인 페이지 만들어줘”라고 했더니 회원가입·비밀번호 재설정·2FA까지 딸려 온 경험. “이 함수 좀 고쳐줘”라고 했더니 인접한 파일 세 개가 같이 리팩토링된 경험. 분명히 짧게 지시했는데 AI가 알아서 해석해서 엉뚱한 방향으로 달려간 경험.

그게 AI가 멍청해서가 아닙니다. 오히려 반대입니다. 너무 자신감이 넘쳐서 생기는 문제입니다.

Claude Code를 포함한 코딩 에이전트들은 2026년 기준으로 모호한 요청을 받으면 질문하는 대신 추측합니다. 그리고 그 추측이 틀렸을 때 이미 수백 줄의 코드를 완성한 상태입니다. 돌이키는 데 더 많은 시간이 걸립니다.

해결책은 단순합니다. CLAUDE.md에 딱 한 줄을 추가하거나, 프롬프트에 조건 하나를 박아두는 겁니다. “이해되지 않으면 질문부터 해라.”

핵심 결론: “100% 이해되기 전에는 코딩을 시작하지 마라. 모호한 게 있으면 먼저 물어봐라.”라는 규칙을 CLAUDE.md 또는 프롬프트에 명시하는 것만으로도 에이전트의 삽질 루프를 크게 줄일 수 있다. 이 글에서는 그 규칙을 실제로 작동하게 만드는 구체적인 장치들을 정리한다.

왜 에이전트는 이해 못 해도 일단 달려들까

Claude Code의 기본 동작 모드는 “빠르게 결과를 냅니다.” 모호한 지시를 받으면 자체적으로 해석해서 실행합니다. 2026년 3월 기준 Claude Code v2.1.79의 시스템 프롬프트는 약 40개의 리마인더를 포함하고 있는데, 그 안에 “모호하면 실행 전에 확인하라”는 명시적 규칙은 없습니다.

공식 문서(code.claude.com)는 이렇게 설명합니다. “Claude Code는 복잡하고 모호한 작업에 대해 3~5개의 질문을 통해 요구사항 명세를 먼저 만들 수 있습니다.” 가능하다는 거지, 기본값이라는 게 아닙니다.

실제로 개발자들이 겪는 문제는 두 가지입니다.

첫째, 추측 실행. 에이전트가 “로그인 페이지”를 만들어달라는 지시를 받으면 자신이 아는 가장 완전한 로그인 시스템을 만듭니다. 여러분이 원하는 게 단순한 폼 하나였더라도요. 에이전트 입장에서는 자신이 아는 범위에서 가장 완성도 높은 결과를 냈을 뿐입니다. 잘못이 없습니다. 지시가 불완전했던 것입니다.

둘째, 규칙 망각. CLAUDE.md에 200줄짜리 규칙을 써놔도 서너 번의 대화가 지나면 에이전트는 점점 무시하기 시작합니다. GitHub Issue #18660(“CLAUDE.md instructions are read but not reliably followed”)이 2026년에도 여전히 오픈 상태인 이유입니다. 컨텍스트 창의 특성상 대화가 길어질수록 초반에 설정한 규칙의 가중치가 낮아집니다.

그래서 “질문부터 해라” 규칙은 단순히 적어두는 것만으로는 부족합니다. 에이전트가 실제로 따르게 만드는 구조가 필요합니다.

왜 이게 2026년에도 해결이 안 됐나

모델이 발전할수록 더 똑똑하게 추측합니다. 틀릴 확률이 낮아지는 게 아니라, 틀렸을 때 더 많은 코드를 만들어 놓습니다. 에이전트가 “아마 이럴 거야”라고 판단하는 기준의 신뢰도가 높아지기 때문에 오히려 질문을 덜 합니다.

2026년 3월 현재 개발자 커뮤니티의 결론은 이렇습니다. “Prompt instructions are suggestions. Hooks are enforcement. CLAUDE.md is a wish list, not a contract.” 이 말의 핵심은 모델 수준에서 해결될 문제가 아니라는 겁니다. 사용자가 입력 구조를 바꿔야 합니다.

지금 결론: 작동하는 질문 허용 규칙 3가지

이걸 먼저 드립니다. 이유는 뒤에서 설명합니다.

규칙 1: CLAUDE.md 최상단에 박아두기

## 실행 전 필수 확인 규칙

- 요청이 100% 명확하지 않으면 코딩을 시작하지 마라
- 모호한 부분이 있으면 실행 전에 반드시 질문하라
- 질문은 최대 3개까지, 핵심적인 것만
- "아마도 이런 뜻이겠지"라고 추측하고 진행하지 마라

이게 전부입니다. 단, 위치가 중요합니다. CLAUDE.md의 최상단에 있어야 합니다. 문서 아래로 내려갈수록 에이전트가 무시할 확률이 높아집니다. CLAUDE.md가 길다면 이 섹션을 파일 첫 번째 ## 헤딩으로 두세요.

규칙 2: 개별 프롬프트에 조건 추가하기

[작업 시작 전 조건]
이 요청에서 불명확한 부분이 하나라도 있으면 코딩 전에 질문하라.
질문 없이 진행한다면 요청을 완전히 이해했다는 뜻이다.

모든 세션에 CLAUDE.md를 적용하기 어렵다면 프롬프트 앞부분에 이 조건을 붙입니다. “질문 없이 진행한다면 요청을 완전히 이해했다는 뜻이다”라는 역논리가 핵심입니다. 에이전트가 스스로 자신의 이해도를 점검하게 만듭니다.

이 조건의 장점은 CLAUDE.md 없이도 적용된다는 겁니다. 임시 세션이나 동료와 공유하는 환경에서도 그냥 붙여넣으면 됩니다.

규칙 3: 성공 기준 명시로 질문 유도하기

목표: 사용자 로그인 폼 구현
성공 기준:
- 이메일 + 비밀번호 입력 필드만 있는 단순 폼
- 서버 연동 없이 프론트엔드 컴포넌트만
- React 사용, 외부 라이브러리 없음
- 비밀번호 재설정·회원가입 기능은 포함하지 않음

위 기준에서 불명확한 부분이 있으면 시작 전에 물어봐라.

성공 기준을 명시하면 두 가지 효과가 있습니다. 하나는 에이전트의 추측 범위를 줄이는 것. 다른 하나는 기준에 맞지 않는 부분이 생기면 자연스럽게 질문하게 만드는 것입니다.

성공 기준이 있으면 에이전트는 “내가 이해한 게 기준과 맞는지” 체크합니다. 그 체크 과정에서 불일치가 발견되면 질문이 나옵니다. 규칙이 질문을 강제하는 게 아니라, 기준이 질문을 자연스럽게 만드는 구조입니다.

왜 이 방식이 다른 접근법보다 잘 작동하나

“자세히 설명하면 된다”의 함정

많은 개발자가 더 긴 프롬프트를 쓰면 해결된다고 생각합니다. 틀렸습니다. Addy Osmani(Chrome Dev Relations 리드)가 AI 에이전트를 위한 스펙 작성 가이드에서 지적한 것처럼, 긴 명세가 있어도 “요구사항이 모호하거나 불완전할 때 업데이트하지 않으면 에이전트는 새 요청을 이전 스펙으로 재해석”합니다.

요점은 길이가 아니라 구조입니다. 에이전트가 따라야 할 조건과 성공 기준이 있어야 합니다. 500자짜리 프롬프트도 성공 기준이 없으면 에이전트는 추측합니다. 50자짜리 프롬프트도 성공 기준이 명확하면 에이전트는 그 기준에 맞게 동작합니다.

“더 나은 AI를 쓰면 된다”의 함정

Claude Code, Codex, Cursor 모두 동일한 근본적 문제를 갖고 있습니다. 모호한 입력에 대해 자신감 있는 추측을 선택하도록 훈련되어 있습니다. 이건 모델의 결함이 아니라 설계 방향입니다. 사용자가 바꿀 수 있는 건 입력의 구조뿐입니다.

더 강력한 모델은 더 자신감 있게 추측합니다. GPT-4o 대비 Claude 3.7 Sonnet이 질문을 더 적게 하는 경향이 있다는 게 커뮤니티에서 자주 보고됩니다. 더 스마트하다는 게 더 많이 묻는다는 뜻이 아닙니다.

“Hook으로 강제하면 된다”의 함정

2026년 CLAUDE.md 커뮤니티의 결론은 “Prompt instructions are suggestions. Hooks are enforcement”입니다. 맞습니다. 그런데 Hook은 코드 실행 후 결과를 검증하는 용도지, 실행 전 이해도를 확인하는 용도가 아닙니다. 질문 규칙은 프롬프트 레벨에서 해결해야 합니다.

Hook으로 “커밋 전에 테스트 통과했는지 확인”은 가능합니다. “요청을 충분히 이해했는지 확인”은 Hook으로 할 수 없습니다. 이해도는 실행 전의 문제고, Hook은 실행 후의 장치입니다.

에이전트가 질문을 건너뛰는 5가지 상황

질문 규칙을 추가했는데도 에이전트가 그냥 달려드는 경우가 있습니다. 이 패턴을 알면 대처할 수 있습니다.

상황 1: 요청이 짧고 자신감 있어 보일 때

❌ "버튼 컴포넌트 만들어줘"

에이전트 입장에서 이건 충분히 이해한 요청입니다. 버튼이 뭔지 알고, 컴포넌트가 뭔지 알고, 만드는 방법도 압니다. 당연히 질문 없이 실행합니다.

✅ "버튼 컴포넌트 만들어줘. 성공 기준: [스타일 라이브러리 없이, props로 색상만 받는 단순 버튼]. 기준에 맞지 않는 부분이 있으면 시작 전 질문."

짧은 요청일수록 성공 기준을 명시해야 합니다. 에이전트는 짧은 요청을 “자유도가 높은 요청”으로 해석하기 때문입니다.

상황 2: 파일 경로나 컨텍스트가 없을 때

에이전트가 기존 코드를 모르는 상태에서 “기존 auth 로직이랑 연동해줘”라는 지시를 받으면 추측합니다. 파일 경로를 명시하거나 관련 파일을 먼저 읽게 시키세요.

✅ "auth.js 파일 읽고, 현재 로직을 설명한 다음 어디서 연동할지 계획만 먼저 얘기해봐. 내가 확인하고 나서 시작해."

“계획만 먼저”는 실행 없이 이해도를 먼저 검증하는 방법입니다. 계획이 맞으면 “진행해”, 틀리면 “아니, 이 부분을 다시 봐”로 방향을 잡을 수 있습니다.

상황 3: 긴 대화 끝에 새 작업을 줄 때

대화가 길어지면 초반에 설정한 질문 규칙이 묻힙니다. 컨텍스트 창에서 오래된 내용일수록 가중치가 낮아집니다. 새 작업을 시작할 때마다 규칙을 상기시키거나, 새 세션을 시작하세요.

✅ "[새 작업] 이해 안 되는 부분 있으면 시작 전 질문해줘: [작업 내용]"

“[새 작업]” 태그 자체가 에이전트에게 “지금부터 다른 작업 시작”이라는 신호를 줍니다. 이전 대화의 관성에서 벗어나게 만드는 장치입니다.

상황 4: 스코프가 열려 있을 때

“이 부분 개선해줘”처럼 개선의 범위가 없으면 에이전트는 자신이 발견한 모든 문제를 고치려 합니다. 스코프를 명시하세요.

❌ "이 함수 개선해줘"
✅ "이 함수의 성능 부분만 개선해줘. 로직 변경 없이, 반복 계산만 줄여줘."

스코프가 없으면 에이전트는 선의로 더 많이 고칩니다. 더 많이 고친다는 게 항상 좋은 게 아닙니다. 여러분이 검토해야 하는 변경 사항이 늘어납니다.

상황 5: 작업 유형이 모호할 때

“이거 고쳐줘”는 버그 수정인지, 리팩토링인지, 기능 추가인지 에이전트가 선택합니다. 작업 유형을 명시하세요.

❌ "이거 좀 고쳐줘"
✅ "버그만 수정해줘. 리팩토링이나 스타일 변경은 하지 마."

작업 유형 명시는 에이전트가 무엇에 집중해야 하는지 범위를 잡아줍니다. 버그 수정이라면 최소 변경으로 문제를 해결해야 합니다. 리팩토링이라면 기능 변경 없이 코드 구조를 바꿔야 합니다. 이 두 가지를 명확히 하지 않으면 에이전트는 섞어서 합니다.

실전 CLAUDE.md 질문 규칙 템플릿

복사해서 바로 쓸 수 있는 형태로 드립니다. 기존 CLAUDE.md 최상단에 추가하세요.

## AI 실행 전 필수 확인 규칙

### 질문 허용 규칙
- 요청이 100% 명확하지 않으면 코딩을 시작하지 마라
- 다음 중 하나라도 모호하면 실행 전에 반드시 질문하라:
  1. 작업 범위 (어디까지 고쳐야 하는가)
  2. 성공 기준 (어떤 상태가 완료인가)
  3. 제약 조건 (쓰면 안 되는 것, 바꾸면 안 되는 것)
  4. 기존 코드와의 관계 (새로 만드는가, 기존 것을 수정하는가)
- 질문은 최대 3개, 핵심적인 것만
- "아마도 이런 뜻이겠지"라고 추측하고 진행하지 마라
- 가정을 명시하고 진행하는 것도 금지. 반드시 사람의 확인을 받아라

### 성공 기준 없는 요청 처리
- 성공 기준이 명시되지 않은 요청은 계획을 먼저 설명하고 확인받아라
- 확인 후 진행하라

### 스코프 제한
- 요청된 파일/함수만 수정하라
- 인접한 코드를 "개선"하지 마라
- 요청하지 않은 기능을 추가하지 마라

이 템플릿에서 자신의 상황에 맞게 조항을 더하거나 빼면 됩니다.

체크리스트: 이 규칙이 제대로 작동하고 있는가

규칙을 추가한 후 아래 체크리스트로 효과를 확인하세요.

기본 작동 확인
– [ ] 모호한 요청을 줬을 때 에이전트가 질문하는가
– [ ] 질문 없이 진행할 때 요청이 실제로 명확했는가
– [ ] 질문의 수가 3개 이하인가 (너무 많으면 프롬프트가 과도하게 제한적인 것)

스코프 제어 확인
– [ ] “A 고쳐줘”라고 했을 때 A만 수정하는가
– [ ] 인접한 파일이나 함수를 건드리지 않는가
– [ ] 요청하지 않은 기능이 추가되지 않는가

성공 기준 확인
– [ ] 완료 조건이 명시된 작업은 그 조건에 맞게 끝나는가
– [ ] 완료 후 에이전트가 성공 기준을 충족했는지 보고하는가

규칙 지속성 확인
– [ ] 긴 세션 후반부에서도 질문 규칙을 따르는가 (아니라면 새 세션 필요)
– [ ] 다음 날 새 세션에서도 규칙이 로드되는가 (CLAUDE.md 위치 확인)

자주 하는 실수 TOP 4

이 규칙을 설정하고 나서도 이 실수들 때문에 효과가 반감됩니다.

실수 1: CLAUDE.md 하단에 규칙을 두기

에이전트는 문서를 위에서 아래로 읽습니다. 중요한 규칙일수록 위에 있어야 합니다. 질문 규칙이 문서 하단에 있으면 긴 세션에서 무시될 가능성이 높습니다.

실제로 Dev.to에서 200줄 CLAUDE.md 실험을 한 개발자의 결론은 이렇습니다. “CLAUDE.md instructions are read but not reliably followed.” 읽는다는 거랑 따른다는 건 다릅니다. 최상단에 있어야 따를 확률이 높습니다.

실수 2: “질문해도 된다”와 “질문해야 한다”를 혼동

“궁금한 게 있으면 질문해도 돼요”는 허가입니다. 에이전트 입장에서 허가는 선택사항입니다. “모호하면 반드시 질문해라”는 의무입니다. 규칙을 의무 형태로 써야 합니다.

허가와 의무의 차이가 실제 동작에서 드러납니다. “질문해도 된다”고 했더니 에이전트가 이미 이해했다고 판단해서 질문 없이 진행했다는 사례가 많습니다.

실수 3: 규칙만 쓰고 성공 기준을 안 쓰기

“이해 안 되면 질문해라”라고만 해두면 에이전트가 이해했다고 판단하면 그냥 진행합니다. 성공 기준이 있어야 에이전트가 자신의 이해와 기준을 대조할 수 있습니다.

규칙만 있고 기준이 없으면 에이전트는 자신의 이해도를 스스로 평가합니다. 그리고 자기평가는 대체로 너그럽습니다.

실수 4: 긴 대화에서 규칙 상기 없이 새 작업 주기

대화가 10~15턴을 넘으면 초반의 규칙이 컨텍스트 창 안에서 희석됩니다. 새 주제나 새 작업을 시작할 때 “[새 작업]” 태그와 함께 질문 규칙을 다시 명시하거나, 새 세션을 시작하세요.

세션을 자주 나누는 게 번거롭게 느껴질 수 있지만, 긴 세션 말미에서 에이전트가 규칙을 무시하고 엉뚱한 방향으로 달리다가 원상복구하는 것보다는 훨씬 효율적입니다.

비교: 규칙 없을 때 vs 있을 때

이 규칙이 실제로 어떤 차이를 만드는지 두 시나리오로 비교합니다.

시나리오: 결제 모듈에 새 결제 수단 추가

규칙 없을 때 흐름:

개발자: "결제 모듈에 카카오페이 추가해줘"

에이전트: [추측 실행]
  - 기존 결제 코드 전체 리팩토링
  - 카카오페이 SDK 설치
  - 결제 실패 처리 로직 새로 작성
  - 웹훅 엔드포인트 추가
  → 파일 12개 변경, 신규 파일 4개 생성

개발자: "이거 아닌데..."
  - 기존 코드와 충돌 발견
  - 불필요한 변경 사항 롤백
  - 원하는 방향 다시 설명
  → 추가 소요 시간: 30분+

규칙 있을 때 흐름:

개발자: "결제 모듈에 카카오페이 추가해줘.
  성공 기준: 기존 결제 추상화 레이어에 카카오페이 어댑터만 추가.
  기존 코드 변경 없음. 불명확한 부분 있으면 먼저 질문해."

에이전트: "결제 추상화 레이어의 인터페이스 파일 경로를 알려주시겠어요?
  그리고 카카오페이 SDK는 이미 설치돼 있나요?"

개발자: "src/payments/base.ts가 인터페이스야. SDK는 아직."

에이전트: [정확한 범위 실행]
  - src/payments/kakao.ts 신규 생성 (base.ts 구현)
  - package.json에 SDK 추가
  → 파일 2개만 변경, 15분 완료

질문 한 번으로 30분을 아꼈습니다.

어떤 유형의 작업에서 차이가 가장 큰가

작업 유형 규칙 효과 이유
기존 코드에 기능 추가 높음 범위와 인터페이스 불명확
버그 수정 중간 원인 범위 불명확
새 컴포넌트 작성 낮음-중간 기존 코드 의존성 낮음
리팩토링 높음 범위 정의가 핵심
탐색/분석 낮음 결과물 범위가 유연해도 됨

고급 적용: 성공 기준 명세 패턴

질문 규칙에서 한 단계 더 나아가면 성공 기준 명세 패턴이 있습니다. SDD(Specification-Driven Development) 방식의 축약 버전입니다. 이전에 발행한 SDD 명세 기반 개발이 AI 시대에 중요한 이유의 현장 적용 버전이기도 합니다.

모든 작업을 이 구조로 줍니다.

[작업 유형]: 버그 수정 / 기능 추가 / 리팩토링 / 탐색
[대상]: 파일명, 함수명, 컴포넌트명
[성공 기준]: 완료 상태를 검증할 수 있는 조건
[제약]: 바꾸면 안 되는 것, 써도 되는 것/안 되는 것
[모호한 부분]: 시작 전에 이 부분을 먼저 확인해줘

예를 들면 이렇게 됩니다.

[작업 유형]: 버그 수정
[대상]: src/auth/login.ts의 validatePassword 함수
[성공 기준]: 빈 문자열 입력 시 false를 반환 (현재 true 반환 중)
[제약]: 함수 시그니처 변경 없음, 기존 테스트 통과 유지
[모호한 부분]: 이 함수를 호출하는 다른 파일은 건드리지 말 것.
  그런데 콜스택에서 이 함수에 직접 의존하는 상위 함수가 있는지
  확인 후 알려줘.

이 구조를 쓰면 에이전트가 질문할 부분이 자연스럽게 드러납니다. “모호한 부분” 섹션에서 미리 인정한 불확실성은 에이전트가 명시적으로 확인하고 넘어갑니다.

언제 이 패턴이 특히 유효한가

  • 기존 코드베이스가 복잡할 때: 파일 간 의존성이 많을수록 범위 확인이 중요합니다
  • 여러 사람이 같은 에이전트를 쓸 때: 구조화된 형식이 팀 내 일관성을 높입니다
  • 반복 작업일 때: 같은 유형의 작업이면 템플릿을 미리 만들어두고 대상과 기준만 바꾸면 됩니다
  • 중요한 배포 전: 실수의 비용이 높을수록 명세를 더 꼼꼼히 쓸 가치가 있습니다

이 패턴의 한계

모든 작업에 이 형식을 쓰면 오버헤드가 생깁니다. 빠른 탐색이나 실험적인 코딩에는 이 정도의 명세가 필요하지 않습니다. 결과가 예상대로 나오지 않을 때 수정 비용이 크다면 명세를 써라. 탐색 단계라면 짧게 지시하고 결과를 보면서 좁혀가도 됩니다.

FAQ

Q: CLAUDE.md에 적어도 에이전트가 무시하면 어떻게 하나요?

A: CLAUDE.md 규칙은 세션이 길어질수록 잘 무시됩니다. 두 가지 방법이 있습니다. 하나는 새 작업마다 프롬프트에 규칙을 반복 명시하는 것. 다른 하나는 Hooks를 활용해 실행 전에 플래그를 확인하게 만드는 것입니다. 완벽한 해결책은 없지만, 규칙을 최상단에 두고 짧게 유지하면 망각 속도를 늦출 수 있습니다. 5개 이상의 규칙 중에서 질문 규칙 하나만 최상단에 둬도 효과가 다릅니다.

Q: 질문이 너무 많아지면 오히려 불편하지 않나요?

A: 맞습니다. 그래서 “최대 3개, 핵심적인 것만”이라는 제한을 둡니다. 에이전트가 5개 이상 묻기 시작하면 프롬프트가 너무 제한적이거나 요청 자체가 너무 모호한 것입니다. 질문이 많아지는 건 명세를 더 명확히 해야 한다는 신호로 보세요. 에이전트가 5개를 물어본다는 건 여러분이 5개의 모호한 부분을 남긴 거라는 뜻이기도 합니다.

Q: 매번 성공 기준을 쓰는 게 번거롭습니다. 더 간단한 방법이 없나요?

A: “계획 먼저, 실행 나중” 방식이 있습니다. 작업 전에 “실행하기 전에 계획을 먼저 설명해봐”라고 하면 에이전트가 무엇을 할지 먼저 서술합니다. 그 계획이 맞으면 “진행해”라고 하면 됩니다. 완전한 성공 기준 명세보다는 덜 정밀하지만, 기본적인 방향 확인에는 충분합니다. 단계적으로 도입하려면 이것부터 시작하세요.

Q: Cursor나 Windsurf에도 같은 규칙이 적용되나요?

A: AGENTS.md(Cursor), .windsurfrules(Windsurf) 등 각 툴마다 다른 설정 파일을 씁니다만, 원리는 동일합니다. 파일 이름만 다를 뿐, “이해 안 되면 질문해라”는 규칙은 어떤 에이전트에서도 같은 방식으로 작동합니다. Cursor는 .cursor/rules/ 폴더, Windsurf는 .windsurfrules 파일에 같은 내용을 넣으면 됩니다.

Q: 에이전트가 질문하는 대신 가정을 명시하고 진행하면 어떻게 처리하나요?

A: 이건 에이전트가 규칙을 영리하게 우회하는 방식입니다. “가정: 단순 폼만 만들면 됨 — 진행합니다”처럼요. 이걸 막으려면 규칙에 “가정을 명시하고 진행하는 것도 금지. 반드시 사람의 확인을 받아라”를 추가하세요. 앞서 제시한 CLAUDE.md 템플릿에 이미 이 조항이 포함되어 있습니다.

Q: 이 규칙이 에이전트를 느리게 만들지 않나요?

A: 질문 한 번의 시간 비용과 잘못 만들어진 코드를 수정하는 시간 비용을 비교해보세요. 짧은 확인 질문에 10초가 걸린다면, 잘못된 방향으로 만들어진 50줄 코드를 되돌리는 데는 몇 분이 걸립니다. 전체적으로는 훨씬 빠릅니다. 느려지는 게 아니라 덜 삽질하는 겁니다.

참고 자료

관련 글

Claude Code 실전 허브의 다른 글: