에이전틱 코딩 프롬프트 5원칙: 한 번에 다 시키면 망한다
에이전틱 코딩의 성패는 프롬프트를 잘게 쪼개 검증 가능하게 시키는 데 달려 있다. 안드레이 카파시는 2026년 "한 번에 다 시키면 망한다"며 작은 단위로 점진적으로 시킬 때 에이전트가 일관되게 정확한 코드를 낸다고 말했다. 핵심은 다섯 가지 원칙이다. ASAP은 복붙 가능한 패턴으로 정리한다.
카파시가 짚은 다섯 개의 장치
에이전트에게 잘 시키는 법은 5개 원칙으로 압축되고, 순서대로 적용하면 실패율이 떨어진다.
- 작게 쪼개라: 한 번에 한 PR 크기의 작업만. 큰 기능은 단계로 나눠 차례로 시킨다.
- 검증 기준을 같이 줘라: 완료 조건·테스트·예상 출력을 프롬프트에 명시한다.
- 맥락을 먼저 읽혀라: 관련 파일·규칙을 먼저 읽게 한 뒤 작업을 시작시킨다.
- 한 번에 한 목표: 여러 의도를 한 프롬프트에 섞지 않는다.
- 검증·반영 루프: 결과를 테스트로 확인하고, 실패를 다음 프롬프트에 반영한다.
이 다섯이 '한 번에 다 시키기'를 막는 장치이다.
왜 하필 '작게'가 1번인가
다섯 중 나머지 넷은 사실 첫째 원칙을 지키기 위한 보조 장치로 읽힌다. 검증 기준을 같이 주는 것도, 맥락을 먼저 읽히는 것도, 작업이 한눈에 잡히는 크기여야 성립한다. 카파시가 2026년 에이전트가 '도와주지만 지저분한' 단계에서 '일관되게 맞는 코드를 내는' 단계로 넘어갔다고 한 것도 결국 작은 단위를 전제로 한 이야기다. 큰 작업을 한 번에 시키면 에이전트가 검증 없이 멀리 가버리고, 프롬프트가 너무 크면 중간에 어긋나도 되돌릴 지점이 사라진다. 즉 '작게'는 다른 원칙들이 작동할 무대를 깔아주는 조건이지, 다섯 중 하나로 나열하고 말 항목이 아니다.
복붙 패턴에 검증이 박혀 있는 이유
원칙은 한 줄짜리 프롬프트 골격으로 바꿀 수 있다. 다음은 검증을 내장한 패턴이다.
| 상황 | 프롬프트 골격 |
|---|---|
| 새 기능 | "먼저 X·Y 파일을 읽어라. 그다음 A만 구현하고, B 테스트로 검증해라." |
| 버그 수정 | "이 테스트가 실패한다. 원인을 먼저 설명하고, 최소 수정 후 테스트를 통과시켜라." |
| 리팩터 | "동작을 바꾸지 말고 C만 정리해라. 기존 테스트가 모두 통과해야 한다." |
세 골격의 공통점은 지시가 아니라 '멈춰서 확인할 지점'을 함께 준다는 데 있다. 사람에게 일을 시킬 때는 완료 기준을 생략해도 알아서 되묻지만, 에이전트는 되묻지 않고 그럴듯한 방향으로 끝까지 달린다. 그래서 검증 기준이 프롬프트 밖에 있으면 사실상 없는 것과 같다. 골격 안에 테스트와 완료 조건을 박아두는 것은 에이전트가 스스로를 멈춰 세울 브레이크를 미리 쥐여주는 셈이다.
한국 개발 현장에 옮길 때
국내 팀이 이 원칙을 그대로 적용하려면 걸림돌이 하나 있다. '작게 쪼개기'는 곧 작은 PR과 촘촘한 테스트를 전제하는데, 테스트 커버리지가 얇은 코드베이스에서는 2번 원칙(검증 기준)부터 무너진다. 검증할 테스트 자체가 없으면 골격의 절반이 빈칸이 되기 때문이다. 반대로 말하면, 에이전트를 잘 쓰려는 노력이 자연스럽게 테스트와 작은 커밋 문화를 앞당기는 압력으로 작용할 수 있다. 다만 이 글의 원칙들은 카파시의 관찰에 기반한 실천 지침이지 벤치마크로 검증된 수치가 아니라는 점은 짚어둘 만하다. 팀마다 코드베이스 성숙도가 다른 만큼, 다섯을 교리처럼 받기보다 자기 환경에서 어느 원칙이 먼저 깨지는지부터 확인하는 편이 낫다.
출처: Andrej Karpathy, "From Vibe Coding to Agentic Engineering"(Sequoia AI Ascent 2026) 기반 ASAP 정리. 관련: 에이전틱 코딩 전문성 연구(Anthropic, 2026).

AI·테크 이슈,
가장 깊게
단순 소식을 넘어, 맥락과 구조까지 파고듭니다
AGI Soon As Possible · asapai.co.kr