AI 에이전트한테 "이거 해줘"라고 말하는 게 전부였던 시절이 있었어요. 불과 2년 전 얘기예요. 그런데 지금은 에이전트가 실수하면 에이전트가 아니라 시스템을 고친다는 게 상식이 됐어요. 프롬프트 엔지니어링 → 컨텍스트 엔지니어링 → 하네스 엔지니어링. 4년 사이에 패러다임이 세 번이나 바뀐 거예요.
이게 뭔데?
AWS Korea 데이터 사이언티스트 김영민님이 정리한 "AI 에이전틱 패턴 4년의 기록"이 최근 개발자 커뮤니티에서 화제예요. 단순한 트렌드 정리가 아니라, 각 시대가 왜 실패했는지를 추적하는 부검 보고서에 가깝거든요.
핵심은 이거예요. 2022년에 우리는 "어떤 말을 해야 하나?"를 고민했어요. 프롬프트만 잘 쓰면 AI가 알아서 해줄 거라고 믿었죠. 2025년이 되니까 "어떤 정보를 넣어야 하나?"로 바뀌었어요. 프롬프트보다 컨텍스트 윈도우에 뭘 채울지가 더 중요하다는 걸 깨달은 거예요. 그리고 2026년, "어떤 시스템을 만들어야 하나?"가 됐어요.
재밌는 건 이 전환의 기원이에요. "하네스 엔지니어링"이라는 말은 2026년 2월, Terraform 창시자 Mitchell Hashimoto가 처음 썼어요. 그의 원칙은 단순했어요. "에이전트가 실수할 때마다, 그 실수가 다시 발생할 수 없도록 환경을 고쳐라." 프롬프트를 고치는 게 아니라, 에이전트를 둘러싼 시스템 — 규칙, 도구, 제약, 피드백 루프 — 을 바꾸는 거예요.
그런데 놀라운 건 그 직후에 벌어진 일이에요. 2주 만에 OpenAI, Martin Fowler(ThoughtWorks), Ethan Mollick(와튼 교수)이 서로 독립적으로 같은 결론을 발표했거든요. 사전 조율이 아니었어요. 모두가 같은 벽에 부딪히고 있었기 때문에 가능한 "동시 발견"이었어요.
핵심 공식
에이전트 = 모델 + 하네스
하네스란 "에이전트에서 모델을 뺀 나머지 전부"예요. 모델은 엔진, 하네스는 운영체제. 아무리 강력한 엔진이라도 운영체제 없이는 쓸모없잖아요.
뭐가 달라지는 건데?
Chad Fowler(Honeycomb CTO)가 이 변화를 한 문장으로 정리했어요. "엄밀함은 사라지지 않는다. 이동할 뿐이다." XP 운동이 "설계 문서 대신 테스트 코드"를 주장했을 때도, 동적 언어가 컴파일러 없이 배포하겠다고 했을 때도, 기존 진영은 "엄밀함이 사라진다"고 비판했어요. 매번 틀렸죠. 엄밀함은 더 높은 추상화 수준으로 이동한 것이었을 뿐이에요.
| 차원 | 프롬프트 엔지니어링 (2022) | 컨텍스트 엔지니어링 (2025) | 하네스 엔지니어링 (2026) |
|---|---|---|---|
| 핵심 질문 | "뭐라고 말하지?" | "뭘 보여주지?" | "어떤 시스템을 만들지?" |
| 비유 | 이메일 작성법 | 받은편지함 관리 | 이메일 시스템 설계 |
| 실패 원인 | Blind prompting, 비결정론 | 컨텍스트 오염, 정보 과부하 | 오케스트레이션 버그 |
| 핵심 메트릭 | 응답 품질 (주관적) | KV-cache hit rate | 태스크 완료율, 비용/태스크 |
| 필요 역량 | 언어 감각 | 정보 아키텍처 | 시스템 설계 + 보안 |
가장 중요한 포인트는 이거예요. 각 시대는 이전 시대를 대체하지 않고 포함해요. 하네스 엔지니어링 안에 컨텍스트 엔지니어링이 있고, 그 안에 프롬프트 엔지니어링이 있어요. "프롬프트 엔지니어링이 죽었다"는 말은 틀렸어요. 죽은 게 아니라 승진한 거예요 — 더 큰 시스템의 서브모듈이 된 거죠.
실전 사례를 보면 더 명확해요. OpenAI는 Codex로 100만 줄 코드베이스를 수동 코드 0줄로 만들었어요. 7명의 엔지니어가 5개월간 코드를 한 줄도 안 썼어요. 대신 코드가 안정적으로 생성될 수 있는 환경을 설계했어요. Anthropic은 3-에이전트 아키텍처로 만드는 에이전트, 평가하는 에이전트, 계획하는 에이전트를 분리했고요.
핵심만 정리: 지금 바로 시작하는 법
- AGENTS.md를 "테이블 오브 컨텐츠"로 만들기
거대한 지침서 대신, 100줄짜리 지도를 만드세요. 에이전트가 필요한 정보를 직접 찾아가게 하는 거예요. OpenAI가 "지도를 줘라, 1000페이지 매뉴얼 말고"라고 강조한 이유예요. - 실수할 때마다 하네스를 업데이트하기
에이전트가 잘못된 명령을 반복 실행하면 AGENTS.md를 고치고, 구조적 실수를 반복하면 린터나 테스트를 추가하세요. Hashimoto의 핵심 원칙 — "에이전트를 탓하지 말고 하네스를 개선하라". - 기계적 강제를 도입하기
문서화만으론 부족해요. 커스텀 린터, 구조적 테스트로 아키텍처 규칙을 강제하세요. 에이전트가 린터를 통과하려고 스스로 코드를 수정하게 하는 거예요. - "뜯어낼 수 있는" 하네스 설계하기
모델이 발전하면 기존 에러 복구 로직의 절반이 불필요해져요. 하네스는 뜯어낼 수 있어야(rippable) 해요. 과도한 엔지니어링은 다음 모델 업데이트의 발목을 잡아요. - 에이전트를 항상 돌리기
Hashimoto의 목표는 "항상 에이전트가 돌아가는 상태"예요. 하루 마지막 30분에 에이전트를 돌리고, 퇴근 후 진행 상황을 다음 날 확인하는 패턴으로 시작하세요.
보안 주의: Lethal Trifecta
Simon Willison이 경고한 세 가지가 동시에 존재하면 보안 사고는 필연이에요: (1) 신뢰할 수 없는 외부 입력 처리 (2) 민감한 데이터 접근 (3) 상태 변경 능력. Meta의 "Rule of Two" — 에이전트에게 이 중 최대 두 가지만 동시에 허용하세요.
