옆자리 동료가 슬랙에 한 줄을 던져요. "이 버그 좀 잡아줘." 그리고 점심을 먹으러 가요. 돌아왔더니 PR이 열려 있어요. CI 그린, 테스트 통과, 셀프 리뷰 코멘트까지 달려서요. 동료가 거기에 쓴 시간은 5분이에요. 에이전트가 혼자 돈 시간은 30분 이상이고요.
그런데 당신은 똑같은 Claude, 똑같은 Cursor를 쓰는데도 여전히 프롬프트 넣고, 결과 보고, "아니 그게 아니라" 하면서 한 줄씩 고치고 있어요. 같은 도구인데 왜 누구는 점심을 먹고, 누구는 에이전트 옆에 붙어 앉아 있을까요?
X의 @systematicls가 공개한 "세계적인 에이전트 엔지니어가 되는 법", Simon Willison의 패턴 가이드, Meta·OpenAI·Stripe 내부 사례를 종합해보면 답은 의외로 단순해요. 10배 빠른 사람들은 더 좋은 프롬프트를 쓰는 게 아니라, 자기가 검토 루프에서 빠지는 시스템을 만들어요. 그게 "에이전틱 엔지니어링"이고요.
한 줄 정의
바이브 코딩 = "ChatGPT한테 물어보고 복붙하기"
에이전틱 엔지니어링 = "에이전트가 스스로 계획·실행·검증·배포하도록 시스템을 설계하기"
둘 다 AI를 쓰지만, 당신이 루프 안에 있느냐 밖에 있느냐가 갈려요.
이건 단어 장난이 아니에요. Karpathy가 만든 "바이브 코딩"의 다음 단계로, 2025년 들어 업계가 의식적으로 선을 그은 개념이에요. OpenAI에 합류한 Peter Steinberger는 한 팟캐스트에서 "바이브 코딩은 이제 거의 비하 표현이다. 나는 내가 하는 일을 에이전틱 엔지니어링이라고 부른다"고까지 했어요. "agentic"은 에이전트에게 일을 위임하니까, "engineering"은 거기에 설계와 전문성이 필요하니까 붙은 이름이에요.
그래서, 점심 먹는 사람들은 뭘 다르게 할까
당신을 루프 밖으로 빼주는 건 다섯 개의 장치예요. 하나씩 보면 별거 아닌데, 안 했을 때 정확히 어디서 막히는지부터 짚을게요. 자기 진단처럼 읽어보세요.
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 오픈. 루프가 안 닫혀 있으면, 당신은 영원히 그 옆에 앉아 있어야 해요.
| 루프 안에 갇힌 당신 | 루프 밖으로 빠진 사람 | |
|---|---|---|
| 결과물 확인 | 개발자가 직접 눈으로 검토 | 에이전트가 테스트·브라우저·로그로 셀프 검증 |
| 피드백 속도 | 개발자가 확인할 때까지 대기 | 실행 즉시 피드백, 자동 수정 반복 |
| 개발자 역할 | 코드를 한 줄씩 리뷰 | 검증 시스템을 설계하고 최종 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. 코드베이스를 사람이 아니라 에이전트가 읽기 좋게 만든다
당신이 막히는 지점: "에이전트가 또 이상한 패턴으로 짰네." 그게 에이전트 탓이라고 생각해요.
아니에요. 에이전트가 이상하게 짠다면, 십중팔구 코드베이스가 모순된 신호를 보내고 있는 거예요. 죽은 코드, 반쯤 끝난 마이그레이션으로 두 패턴이 공존하는 코드, 경쟁하는 프레임워크 — 이런 게 컨텍스트에 들어가면 독처럼 작용해요. 에이전트는 확률적으로 골라요. 코드베이스에 A 방식과 B 방식이 섞여 있으면, 에이전트는 동전 던지기로 따라 해요.
OpenAI 팀은 한 발 더 나갔어요. 파일 구조를 에이전트가 일관되게 생성하도록 표준화하고, 에이전트 전용 로깅을 추가하고, 문서를 사람뿐 아니라 에이전트도 읽도록 작성해요. 그들이 말하는 "골든 원칙(Golden Principles)"을 레포 안에 직접 인코딩하는 거죠. 코드베이스 자체가 에이전트의 가장 큰 컨텍스트예요.
5. 이 모든 걸 혼자 안 하고, 팀에 쌓아 복리로 굴린다
당신이 막히는 지점: 좋은 CLAUDE.md, 끝내주는 MCP를 만들어놓고 — 당신 로컬에만 둬요.
Every 공동 창업자 Dan Schipper가 제시한 "Compound Engineering"이에요. 컨텍스트 설계·검증 루프·도구·코드베이스 최적화를 혼자만 하면 당신 생산성만 올라요. 하지만 팀 전체가 CLAUDE.md에 지식을 쌓고, MCP를 공유하고, 검증 스크립트를 커밋하면 복리가 발생해요. 다음 세션의 에이전트가 이전보다 더 많은 도구와 맥락을 들고 시작하는 거예요. 이게 개인기와 시스템의 차이고요.
이 숫자들은 개인 천재가 아니라 조직이 다섯 장치를 체계적으로 도입한 결과예요. Stripe의 Minions 시스템은 개발자가 슬랙에 작업을 올리면 에이전트가 코드를 쓰고 CI를 통과시키고 PR을 열어요. 사람은 최종 리뷰와 머지만 하고요. 작업 할당부터 PR 오픈까지 사람 개입이 제로예요. 맨 위 장면이 한 조직 전체에서 매주 천 번씩 일어나는 거예요.
오늘 당장 루프 밖으로 한 발 빼기
다섯 개를 한꺼번에 할 필요 없어요. 순서대로 하나씩, 각각 30분이면 충분해요.
- CLAUDE.md(또는 AGENTS.md)를 "에이전트 온보딩 문서"로 다시 쓰기
빌드 명령어, 코딩 컨벤션, 아키텍처 결정사항을 적으세요. "TypeScript를 쓴다" 같은 뻔한 건 빼고, Claude가 틀릴 만한 것만 남기세요. 기준은 하나예요. "내 머릿속에만 있어서 에이전트가 매번 헷갈리는 규칙이 뭐지?" - 검증 루프 하나를 닫기
가장 자주 하는 작업에서 에이전트가 스스로 결과를 확인하게 하세요. 백엔드면 "테스트를 실행하고 전부 통과할 때까지 반복해", 프론트면 Playwright MCP로 브라우저에서 직접 확인하게요. 딱 하나만 닫아도 "옆에 안 앉아 있어도 되는" 체감이 와요. - 마찰 지점 하나를 도구로 해결하기
에이전트가 못 해서 당신이 매번 대신 해주는 일을 찾으세요. 웹에서 수동 클릭이든, 특정 API 호출이든. 그걸 CLI 도구나 MCP 서버로 만드세요. 기준은 "다음에 이 작업이 또 나오면, 에이전트가 혼자 처리할 수 있는가?" - 죽은 코드와 경쟁 패턴 정리하기
반쯤 끝난 마이그레이션, 두 방식으로 혼재된 패턴, 안 쓰는 코드를 치우세요. 에이전트는 확률적이라, 모순된 패턴이 있으면 랜덤으로 따라 해요. 코드베이스 청소가 곧 프롬프트 튜닝이에요. - 팀에 커밋해서 복리 시작하기
새로 만든 스킬·MCP·검증 스크립트를 레포에 커밋하세요. 기준은 "이 도구가 다음 사람(또는 다음 에이전트 세션)에게도 쓰일까?" 혼자만 쓰는 워크플로우는 복리가 안 붙어요.
다만, 루프 밖으로 빠진다고 책임까지 내려놓진 마세요 — 안티패턴 3가지
Simon Willison이 명확히 경고한 것들이에요.
1. 에이전트가 쓴 코드를 리뷰 없이 PR 올리지 마세요. 에이전트의 PR 설명문도 사람이 검증해야 해요.
2. 에이전트가 만든 테스트를 맹신하지 마세요. 하드코딩된 값으로 통과하는 "자기충족적 테스트"가 나올 수 있어요.
3. "작동하니까 됐지"로 넘어가지 마세요. 코드 생성 비용이 낮아졌다고 리뷰 기준을 낮추면, 기술 부채가 AI 속도로 쌓여요.
핵심은 이거예요. 10배 빠른 사람은 손이 빠른 게 아니라, 자기가 빠져도 굴러가는 시스템을 먼저 만든 사람이에요. 오늘 다섯 개 중 하나만 닫아보세요. 점심 먹으러 갈 명분이 하나 생겨요.
