Claude, Codex, Cursor — AI 코딩 에이전트를 매일 쓰고 있는데, 왜 어떤 사람은 10배 빠르게 일하고 어떤 사람은 여전히 복붙 수준일까요? X의 @systematicls가 공개한 "세계적인 에이전트 엔지니어가 되는 법"을 보면, 핵심은 플러그인이나 도구가 아니라 일하는 방식 자체에 있어요.
이게 뭔데?
"에이전틱 엔지니어링(Agentic Engineering)"은 2025년 Andrej Karpathy가 만든 "바이브 코딩(Vibe Coding)"의 다음 단계예요. 바이브 코딩이 "대충 시키면 알아서 해주겠지"였다면, 에이전틱 엔지니어링은 AI 에이전트가 계획하고, 코드를 쓰고, 테스트하고, 배포까지 하는 과정을 체계적으로 설계하는 엔지니어링 방법론이에요.
Peter Steinberger(OpenAI 합류)는 한 팟캐스트에서 "바이브 코딩은 이제 거의 비하 표현이다. 나는 내가 하는 일을 에이전틱 엔지니어링이라고 부른다"고까지 말했어요. Karpathy 본인도 이 구분을 강조했고요. "agentic"은 에이전트에게 일을 위임하기 때문에, "engineering"은 거기에 설계와 전문성이 필요하기 때문에 붙인 이름이에요.
그러면 구체적으로 뭘 어떻게 하는 건지가 궁금하잖아요. @systematicls의 원문과 여러 실전 사례를 종합하면, 핵심 원칙은 크게 5가지로 정리돼요.
핵심 구분
바이브 코딩 = "ChatGPT한테 물어보고 복붙하기"
에이전틱 엔지니어링 = "에이전트가 스스로 계획-실행-검증-배포하도록 시스템을 설계하기"
둘 다 AI를 쓰지만, 결과물의 품질이 완전히 달라요.
뭐가 달라지는 건데?
원칙 1. 컨텍스트 엔지니어링 — 쓸데없는 정보는 빼고, 정확한 맥락만 먹여라
"컨텍스트 윈도우가 100만 토큰이니까 다 넣으면 되겠지?"라고 생각하기 쉽지만, Meta 스태프 엔지니어 John Kim의 말이 정곡을 찔러요: "모델은 확률적 출력이에요. 정확히 필요한 만큼만 넣어야 정확한 결과가 나와요. 더 넣는다고 더 잘하는 게 아니에요." Claude Code의 CLAUDE.md, 슬래시 커맨드, MCP 같은 기능은 결국 컨텍스트를 체계적으로 관리하는 도구예요.
OpenAI 내부에서도 이걸 "Harness Engineering"이라고 부르면서, 도메인 지식을 코드베이스에 직접 밀어넣는 실험을 했어요. 결론은 단호했대요: "도메인 지식이 코드베이스에 없으면, 에이전트에겐 존재하지 않는 것이다."
원칙 2. 에이전틱 검증 — 에이전트가 자기 결과물을 스스로 확인하게 만들어라
Claude Code 창시자 Boris Cherny가 강조한 핵심이에요. 에이전트한테 코드를 시키고, 직접 눈으로 확인하고, 수정 지시하고... 이러면 바이브 코딩이랑 다를 게 없어요. 대신 에이전트가 자기 결과물을 검증할 수 있는 루프를 만들어야 해요. 백엔드라면 테스트 자동 실행, 프론트엔드라면 Playwright로 브라우저를 열어 스크린샷 캡처 후 비교, 모바일이면 ADB 시뮬레이터로 인터랙션 확인 — 이런 식이에요.
PulseMCP는 이걸 "에이전틱 루프를 닫는다(closing the agentic loop)"고 표현했어요. 루프가 닫히면 사람이 5분 투자해서 에이전트를 띄우고, 에이전트가 30분 이상 혼자 돌면서 PR까지 열어요. CI 그린, 테스트 통과, 셀프 리뷰까지 다 끝난 상태로요.
| 바이브 코딩 (수동 확인) | 에이전틱 엔지니어링 (자동 검증 루프) | |
|---|---|---|
| 결과물 확인 | 개발자가 직접 눈으로 검토 | 에이전트가 테스트·브라우저·로그로 셀프 검증 |
| 피드백 속도 | 개발자가 확인할 때까지 대기 | 실행 즉시 피드백, 자동 수정 반복 |
| 개발자 역할 | 코드를 한 줄씩 리뷰 | 검증 시스템을 설계하고 최종 PR만 리뷰 |
| 에이전트 실행 시간 | 프롬프트 1회 → 결과 1회 | 5분 투자 → 30분+ 자율 실행 |
| 품질 일관성 | 개발자 컨디션에 의존 | 검증 시스템이 일관된 기준 적용 |
원칙 3. 에이전틱 도구 — 에이전트의 마찰을 제거하는 도구를 직접 만들어라
Peter Steinberger는 이걸 "friction"이라고 불러요. 에이전트가 뭔가를 못 하는 지점, 막히는 지점이 바로 기회예요. 특정 API가 CLI로 접근이 안 된다? CLI를 만들어요. 특정 검증이 자동화가 안 된다? MCP 서버를 만들어요. Steinberger 본인이 그렇게 미리 만들어둔 CLI 도구들 덕분에 OpenClaw 프로젝트가 성공할 수 있었대요.
Simon Willison은 여기에 중요한 원칙을 하나 더해요: "할 줄 아는 것들을 모아둬라(Hoard things you know how to do)." 작은 코드 실험, 해결한 문제, 잘 작동한 프롬프트 — 이런 걸 축적해두면 에이전트한테 새로운 기능을 시킬 때 강력한 레퍼런스가 돼요. 에이전틱 엔지니어링에서 개발자의 진짜 자산은 "코드를 치는 속도"가 아니라 "무엇이 가능한지 아는 범위"예요.
원칙 4. 에이전틱 코드베이스 — AI가 읽기 좋은 코드베이스를 만들어라
여러분의 코드베이스는 AI 에이전트에게 최적화되어 있나요? 대부분 아닐 거예요. 죽은 코드, 반쯤 끝난 마이그레이션으로 두 가지 패턴이 공존하는 코드, 경쟁하는 프레임워크... 이런 게 에이전트의 컨텍스트에 들어가면 독처럼 작용해요. 에이전트가 이상한 패턴으로 코드를 생성하면, 그건 에이전트 탓이 아니라 코드베이스의 혼란스러운 신호 탓이에요.
OpenAI 팀은 한 발 더 나갔어요. 파일 구조를 에이전트가 일관되게 생성할 수 있도록 표준화하고, 에이전트 전용 로깅을 추가하고, 문서를 사람뿐 아니라 에이전트도 읽을 수 있도록 작성해요. 그들이 말하는 "골든 원칙(Golden Principles)"을 레포 안에 직접 인코딩하는 거예요.
원칙 5. 복합 엔지니어링 — 위 4가지를 팀 전체가 복리로 쌓아가라
Every의 공동 창업자 Dan Schipper가 제시한 "Compound Engineering" 개념이에요. 컨텍스트 설계, 검증 루프, 도구, 코드베이스 최적화 — 이걸 혼자만 하면 개인 생산성만 올라가요. 하지만 팀 전체가 CLAUDE.md에 지식을 쌓고, 새로운 MCP를 만들고, 검증 스크립트를 공유하면 복리 효과가 발생해요. 다음 세션의 에이전트가 이전 세션보다 더 많은 도구와 맥락을 가지고 시작하는 거죠.
이 숫자들은 개인이 아니라 조직이 에이전틱 엔지니어링을 체계적으로 도입한 결과예요. Stripe의 Minions 시스템은 개발자가 Slack에 작업을 올리면, 에이전트가 코드를 쓰고 CI를 통과시키고 PR을 열어요. 사람은 최종 리뷰와 머지만 해요. 작업 할당부터 PR 오픈까지 사람의 개입이 제로예요.
핵심만 정리: 시작하는 법
- CLAUDE.md(또는 AGENTS.md)를 "에이전트 온보딩 문서"로 다시 쓰기
프로젝트의 빌드 명령어, 코딩 컨벤션, 아키텍처 결정사항을 적으세요. "TypeScript를 사용한다" 같은 뻔한 건 빼고, Claude가 틀릴 만한 것만 남기세요. 도메인 지식이 코드베이스에 없으면 에이전트에겐 없는 거예요. - 검증 루프 하나를 닫기
가장 자주 하는 작업에서 에이전트가 스스로 결과를 확인하도록 만드세요. 백엔드면 "테스트를 실행하고 전부 통과할 때까지 반복해"라고 지시하고, 프론트엔드면 Playwright MCP로 브라우저에서 직접 확인하게 하세요. 하나만 닫아도 체감이 달라져요. - 마찰 지점 하나를 도구로 해결하기
에이전트가 못 하는 일 중 가장 자주 발생하는 걸 찾으세요. 그게 웹사이트에서 수동으로 뭔가를 바꾸는 건지, 특정 API를 호출하는 건지 파악하고, CLI 도구나 MCP 서버를 만들어 해결하세요. "다음에 이 작업 또 나오면 에이전트가 혼자 처리할 수 있는가?"가 기준이에요. - 코드베이스에서 죽은 코드와 경쟁 패턴 정리하기
반쯤 끝난 마이그레이션, 두 가지 방식으로 혼재된 패턴, 사용하지 않는 코드를 정리하세요. 에이전트는 확률적으로 작동하기 때문에, 모순되는 패턴이 있으면 랜덤으로 따라 해요. - 팀 공유 & 복리 축적 시작
새로 만든 스킬, MCP 서버, 검증 스크립트를 레포에 커밋하세요. "내가 만든 이 도구가 다음 사람(또는 다음 에이전트 세션)에도 쓰일 수 있는가?"가 기준이에요. 혼자만 쓰는 워크플로우는 복리가 안 돼요.
주의: 안티패턴 3가지
Simon Willison이 명확히 경고한 것들이에요.
1. 에이전트가 쓴 코드를 리뷰 없이 PR 올리지 마세요. 에이전트의 PR 설명문도 사람이 검증해야 해요.
2. 에이전트가 만든 테스트를 맹신하지 마세요. 하드코딩된 값으로 통과하는 "자기충족적 테스트"가 나올 수 있어요.
3. "작동하니까 됐지"로 넘어가지 마세요. 코드 생성 비용이 낮아졌다고 리뷰 기준을 낮추면, 기술 부채가 AI 속도로 쌓여요.
