프롬프트에서 하네스까지: AI 개발 패러다임 3번의 전환이 말하는 것 (bits-bytes-nn.github.io)
한줄 요약
AI 개발 엄밀함의 위치가 바뀌었다 — 프롬프트에서 컨텍스트로, 다시 시스템 아키텍처로.
무엇이 달라지나?
AI 개발 패러다임은 2022년부터 2026년 사이에 세 차례 전환을 겪었다. 프롬프트 엔지니어링, 컨텍스트 엔지니어링, 하네스 엔지니어링이 그 순서다. 각 전환은 이전 패러다임이 약속을 지키지 못한 데서 촉발됐다는 점이 핵심이다.
**프롬프트 엔지니어링 시대 (2022~2024)**는 "어떻게 말하느냐"가 성패를 결정한다는 믿음 위에 세워졌다. GitHub Copilot이 2022년 6월 상업 출시됐고, 같은 해 11월 ChatGPT가 등장하면서 "영어가 곧 프로그래밍 언어"라는 명제가 업계를 지배했다. Chain-of-Thought, ReAct 같은 프롬프팅 기법이 논문으로 쏟아졌고, 모델에게 보내는 지시문 한 줄의 차이가 벤치마크 수치를 수십 퍼센트 단위로 바꿨다. GSM8K에서 CoT 하나로 PaLM 540B의 정확도가 17.9%에서 58.1%로 뛴 건 그 상징이었다.
그러나 Tree-of-Thought처럼 추론의 "너비"를 확장하는 방향으로 밀어붙이자 비용이 폭발했다. 프롬프트를 아무리 정교하게 다듬어도, 모델이 참조할 수 있는 정보의 범위 자체가 병목이라는 사실이 드러나기 시작했다.
**컨텍스트 엔지니어링 시대 (2025)**의 방아쇠를 당긴 건 2025년 6월 Shopify CEO Tobi Lütke의 발언이었다. 일주일도 안 돼 Karpathy, Andrew Ng을 포함한 수백 명의 엔지니어가 합류하면서 "prompt engineering"이라는 단어가 타임라인에서 사라지기 시작했다. 질문이 바뀌었다. "어떻게 말하나"에서 "컨텍스트 윈도우에 무엇을 채우나"로. 프롬프트 품질보다 어떤 정보를 모델에게 넘기느냐가 더 중요하다는 인식이 업계 전반으로 퍼졌다.
**하네스 엔지니어링 시대 (2026)**는 한 단계 더 올라간다. 컨텍스트를 소비하는 전체 시스템의 설계 자체가 문제라는 인정이다. GitHub Copilot의 진화가 이 흐름을 압축해서 보여준다. 2022년 단일 파일 자동완성으로 시작한 Copilot은 2025년 2월 Agent Mode에서 멀티파일 편집과 터미널 실행을 루프 안에서 처리하기 시작했고, 같은 해 5월에는 이슈 할당부터 PR 생성까지 완전 자율 워크플로우를 구현했다. 2026년의 핵심 메트릭은 프롬프트 품질이 아니라 KV-cache hit rate와 하네스 복잡도다.
Ruby 커뮤니티의 원로이자 Honeycomb CTO인 Chad Fowler는 이 흐름을 "Relocating Rigor"라고 명명했다. 엄밀함이 사라진 게 아니라 더 높은 추상화 수준으로 이동했다는 것이다. XP 운동이 설계 문서 대신 자동화된 테스트를 택했을 때, 동적 언어가 컴파일러 타입 검사 없이 배포를 시작했을 때도 같은 비판이 나왔다. 매번 틀렸다. 이번도 다르지 않을 가능성이 높다.
실무에서 어떤 의미인가?
이 패러다임 이동은 "AI를 어떻게 쓰나"보다 "AI를 위한 시스템을 어떻게 설계하나"로 질문을 바꾼다. 프롬프트를 다듬는 데 시간을 쏟던 엔지니어가, 이제는 에이전트가 어떤 정보를 언제 참조하는지를 설계해야 한다. ReAct에서 출발한 Thought-Action-Observation 루프는 오늘날 Claude Code, Cursor Agent, GitHub Copilot Coding Agent 모두에서 살아 있는 구조다. 패턴을 이해하면 어떤 도구가 등장해도 빠르게 적응할 수 있다.
또 하나는 비용 구조다. 하네스 엔지니어링 시대에서 KV-cache hit rate가 핵심 메트릭으로 부상했다는 건, 같은 계산을 얼마나 효율적으로 재활용하느냐가 운영 비용과 직결된다는 의미다. 단순히 "좋은 프롬프트"를 쓰는 것과 "시스템이 캐시를 잘 활용하게 설계"하는 것은 차원이 다른 문제다.
도입 전 체크포인트
AI 에이전트나 LLM 기반 시스템 도입을 검토한다면 아래 세 가지를 먼저 점검하는 것이 실용적이다.
- 현재 병목이 어디인가: 프롬프트 품질 문제인지, 컨텍스트 구성 문제인지, 아니면 시스템 아키텍처 문제인지를 먼저 진단해야 한다. 엉뚱한 층위에서 최적화하면 비용만 낭비된다.
- 에이전트 루프의 범위를 정의했는가: 에이전트가 어떤 도구를 언제 사용할 수 있는지, 루프의 종료 조건은 무엇인지 명시하지 않으면 시스템이 예측 불가능하게 동작한다.
- KV-cache 재활용 구조를 고려했는가: 반복 호출이 많은 워크플로우라면 캐시 히트율이 운영 비용을 좌우한다. 초기 설계 단계에서 반영하지 않으면 나중에 구조를 뜯어야 한다.
자주 묻는 질문
Q.프롬프트 엔지니어링은 이제 의미 없는 기술인가?
완전히 무의미해진 건 아니다. 다만 그것만으로 해결할 수 있는 문제의 범위가 좁아졌다. 현재의 복잡한 AI 시스템에서 프롬프트 품질은 여러 레이어 중 하나일 뿐이고, 더 큰 병목은 컨텍스트 설계와 시스템 아키텍처에 있는 경우가 많다. 프롬프트를 잘 짜는 능력은 여전히 유용하지만, 그것을 에이전트 루프와 하네스 설계 역량으로 확장하지 않으면 한계가 빠르게 온다.
Q.하네스 엔지니어링을 배우려면 어디서부터 시작해야 하나?
ReAct 논문에서 제시한 Thought-Action-Observation 루프 구조를 이해하는 것이 출발점이다. 이 패턴은 현재 대부분의 AI 에이전트 프레임워크에서 실제로 작동하는 방식이기 때문에, 특정 도구에 종속되지 않는 이해를 준다. 그 위에 GitHub Copilot Agent Mode나 Claude Code 같은 실제 도구를 실습하면서 컨텍스트 윈도우 관리와 도구 호출 흐름을 직접 관찰하는 것이 효과적이다. 이론과 실습을 병행하는 구조가 가장 빠른 경로다.
Q.KV-cache hit rate는 일반 개발팀이 신경 써야 하는 지표인가?
LLM API를 단순 일회성으로 호출하는 수준이라면 당장 우선순위가 높지 않을 수 있다. 그러나 에이전트가 반복적으로 유사한 컨텍스트를 처리하거나, 대량 호출이 발생하는 프로덕션 환경이라면 캐시 히트율이 비용과 응답 속도 모두에 직접 영향을 준다. 시스템 설계 초기에 캐시 친화적인 컨텍스트 구조를 잡아두는 것이 나중에 리팩토링하는 것보다 훨씬 저렴하다.