'AI가 코드를 짜준다'는 말은 이제 낡았다. 진짜 질문은 이것이다. AI 에이전트를 어떤 예산 안에서, 어떤 컨텍스트 구조 위에서 굴릴 것인가. dev.to에 올라온 두 편의 실전 가이드—풀스택 프로덕션 플레이북과 Claude 구독 플랜별 워크플로우 분석—는 서로 다른 각도에서 같은 결론에 도달한다. 도구보다 설계가 먼저다.
병목은 타이핑이 아니라 사고다
풀스택 플레이북이 제시하는 첫 번째 진실은 날카롭다. AI는 인간보다 5~20배 빠르게 코드를 생성하지만, 생산성이 실제로 10배가 되는 팀과 1.5배에 그치는 팀의 차이는 일하는 방식을 바꿨느냐에 있다. 티켓 작성 → 배정 → 대기 → 리뷰라는 낡은 흐름을 유지한 채 AI를 끼워 넣으면, 에이전트는 빠른 타이피스트 한 명을 추가한 것에 불과하다.
여기서 핵심 메타포가 등장한다. '타이피스트'에서 '디렉터'로. 시니어 엔지니어의 생산성은 이제 이 공식에 가깝다. 생산성 ≈ 스펙의 명확도 × 하네스 품질 × 검증 속도. 셋 중 하나라도 약하면 에이전트는 당신을 1.5배 증폭시키고 토큰 비용을 10배 태운다.
컨텍스트 엔지니어링: 프롬프트보다 먼저 설계해야 할 것
플레이북이 가장 강조하는 개념이 바로 컨텍스트 엔지니어링이다. 프롬프트가 아무리 훌륭해도, CLAUDE.md가 없고 코드베이스 컨벤션이 없고 잘못된 디렉터리를 바라보는 환경에서는 평범한 프롬프트보다 나쁜 결과가 나온다. "AI가 별로야"라는 불만의 대부분은 사실 컨텍스트 불만이라는 지적은 뼈아프다.
하네스(harness)란 에이전트가 읽고 쓰고 실행하는 모든 외부 구조물을 말한다. CLAUDE.md, .cursorrules, 슬래시 커맨드, MCP 서버, 훅, 테스트 러너, 린트 규칙. 플레이북은 새 프로젝트 첫 1~3일을 하네스 구축에 쏟는 것이 단일 최고 ROI 활동이라고 못 박는다. 기능 코드는 그 다음이다.
그리고 CLAUDE.md의 길이는 짧을수록 좋다. 300줄짜리 파일은 세션마다 로드되며 토큰을 갉아먹는다. 25줄의 핵심 지침이 200줄의 백과사전보다 항상 낫다. 이건 예산 플랜에 상관없이 통하는 원칙이다.
예산 심리가 워크플로우를 결정한다
Claude 구독 플랜 분석 아티클은 흥미로운 통찰을 제공한다. 워크플로우를 바꾸는 건 모델 성능이 아니라 예산 심리라는 것. 하루 한도를 30분 만에 태울 수 있다는 걸 알면 코딩 방식 자체가 달라진다.
Pro($20)에서는 제약이 곧 규율이다. Opus는 되돌릴 수 없는 결정이나 두 번의 시도로도 못 잡은 버그에만 아낀다. 더 중요한 건 /clear의 타이밍이다. 하루가 끝날 때가 아니라 태스크가 바뀔 때마다 컨텍스트를 지워야 한다. 서로 다른 세 가지 주제가 섞인 세션은 깨끗한 세션 세 개보다 토큰을 3배 태운다. "모멘텀"이 깨지는 느낌이 들지만, 일일 한도에서 차이는 실재한다.
질문의 정밀도도 경제학이다. "이 파일을 어떻게 개선할까?"는 전체 분석을 트리거한다. "47번째 줄의 buildPayload() 함수가 null 케이스를 처리하나?"는 10배 저렴하고 더 유용한 답을 준다.
Max($100)에서 진짜 달라지는 건 '방어적 계획'의 소멸이다. 이 질문을 감당할 수 있을까를 더 이상 묻지 않아도 된다. 500줄 모듈 전체 리뷰가 사치에서 일상 실천으로 바뀐다. 5개 파일에 걸친 리팩터링을 파편화 없이 한 세션에서 끝낼 수 있다. 병렬 에이전트를 두 개 돌려도 죄책감이 없다.
Max($200)에서는 반대의 규율이 필요해진다. 상시 Opus, 카운터 없음. 하지만 200개 파일을 로드한 2시간짜리 세션은 하나의 문제에 집중한 깔끔한 세션보다 느리고 때로 덜 정확하다. /clear는 여전히 유용하다. 이제는 토큰을 아끼기 위해서가 아니라, 짧은 컨텍스트가 과부하된 컨텍스트보다 낫기 때문에.
예산이 달라도 바뀌지 않는 두 가지
두 아티클이 공통적으로 강조하는 원칙이 있다. 첫째, 질문의 정밀도는 경제학이 아니라 커뮤니케이션 스킬이다. "전체 코드베이스를 보고 아키텍처를 개선해줘"는 어떤 플랜에서도 나쁜 질문이다. 비싸서가 아니라 모호하기 때문에. 둘째, 짧은 CLAUDE.md. Pro에서는 예산을 아끼고, Max $200에서는 속도를 지킨다. 결과는 같다.
그리고 플레이북이 '7번째 진실'로 경고하는 것을 잊으면 안 된다. 이해하지 못한 코드를 받아들이는 건 일회용 스크립트에선 괜찮고 프로덕션에서는 재앙이다. Andrej Karpathy가 말한 "코드가 존재한다는 사실도 잊어버리는" 바이브 코딩은 보안 침해와 새벽 2시 알람의 원인이다. 당신이 엔지니어 오브 레코드다. 항상.
실행 레이어로 내려오면
이 두 가이드가 함께 그리는 그림은 결국 하나다. AI 에이전트의 레버리지는 모델 선택이나 프롬프트 기교에서 오지 않는다. 스펙을 명확히 쓰는 능력, 하네스를 구조적으로 설계하는 능력, 에이전트 산출물을 빠르게 검증하는 능력—이 세 가지가 실제 생산성의 곱셈 인자다.
예산은 제약이 아니라 설계 변수다. Pro 사용자는 제약이 규율을 만든다는 걸 역이용할 수 있고, Max 사용자는 제약이 사라진 자리에서 속도와 정밀도라는 새로운 최적화 목표를 찾아야 한다. 어느 쪽이든 컨텍스트를 설계하지 않은 에이전트는 빠른 타이피스트에 불과하다.
프로토타이핑에서 프로덕션으로 가는 경로를 AI와 함께 걷고 싶다면, 먼저 하네스 데이를 선언하라. 기능 코드는 그 다음이다.