하네스 엔지니어링 뜻과 개념 — 프롬프트·컨텍스트 엔지니어링과 무엇이 다른가

핵심 메시지

• 하네스 엔지니어링은 프롬프트·컨텍스트 엔지니어링을 포함하는 더 큰 개념으로, 코딩 에이전트를 실제로 작동시키기 위한 설계 결정 전체를 뜻한다.
• LLM은 도구가 없으면 코드 검색 같은 질문에 환각으로 답하며, read·grep·bash 같은 도구를 붙이는 순간 모델은 에이전트가 된다.
• 도구가 늘수록 어떤 도구를 언제 쓸지 정하는 시스템 프롬프트와 도구 설명(프롬프트 엔지니어링), 그리고 커지는 대화 기록을 압축·관리하는 컨텍스트 엔지니어링이 필요하다.
• 하네스는 LLM·프롬프트·컨텍스트 관리·서브에이전트·라이프사이클 훅·가드레일 여섯 요소를 묶은 것으로, Claude Code·Codex는 닫힌 하네스, Pi는 열린 하네스의 예다.
• 용어에 겁먹지 말고 매일 쓰는 Claude Code 같은 실제 사례에 대입해 제1원리로 설명하면 면접에서도 흔들리지 않는다.

쉽게 이해하기

영상은 요즘 LLM 면접에서 자주 나오는 "하네스 엔지니어링이란 무엇인가", "프롬프트·컨텍스트·하네스 엔지니어링은 어떻게 다른가"라는 질문을 다룬다. 발표자는 정의를 암기해 나열하지 말고 예시를 들어 제1원리로 설명해야 개념을 제대로 이해했음을 보여줄 수 있다고 강조한다.

예시는 방대한 코드베이스를 C#·C++에서 Rust 같은 현대 언어로 마이그레이션하는 작업이다. 이때 LLM에게 "코드에서 if-else가 어디에 있나", "반복문 카운터가 쓰인 곳은 어디인가"를 물으면, 언어 모델은 도구가 없어 세상에서 학습한 정보에 기대어 대체로 잘못되거나 환각된 답을 내놓는다.

해결책은 모델에 read(읽기), grep(정규식 검색), bash(터미널 실행), search 같은 도구를 붙이는 것이다. 도구를 가진 모델을 발표자는 에이전트라고 부른다. 다만 도구가 많아질수록 에이전트가 어떤 도구를 언제 쓸지 판단하기 어려워지므로, 시스템 프롬프트를 잘 쓰고 각 도구마다 상세한 설명을 다는 프롬프트 엔지니어링이 필요해진다.

에이전트가 도구를 반복 호출하면 사고·행동·관찰 루프의 입력과 출력이 컨텍스트에 계속 쌓여, Gemini나 Opus의 100만 토큰 컨텍스트 창마저 넘어설 수 있다. 그래서 최근 세 개 도구 기록만 남기거나 한도에 도달하면 대화를 압축(compaction)하는 등 컨텍스트를 언제 어떻게 줄일지 정하는 컨텍스트 엔지니어링이 등장한다.

여기에 더해 탐색·구현·검증처럼 성격이 다른 하위 작업을 서브에이전트에 나눠 맡기는 서브에이전트 관리, 가상머신·클라우드에서 .env 로드나 Git 설치를 자동으로 처리하게 하는 라이프사이클 훅, 그리고 가드레일까지 설계해야 비로소 자신만의 코딩 에이전트가 완성된다. 이 여섯 가지 설계 결정을 하나로 묶은 것이 하네스이며, 그 설계 기술이 하네스 엔지니어링이다.

주요 인사이트

• LLM을 엔진, 하네스를 자동차 전체에 비유할 수 있다. 아무리 좋은 Opus·Sonnet이라도 시스템 프롬프트·컨텍스트 관리·도구·스킬·서브에이전트·가드레일·훅이 둘러싸지 않으면 스스로 무엇을 할지 모른다.
• Claude Code와 Codex는 소스가 공개되지 않은 닫힌 하네스라 시스템 프롬프트 등을 알 수 없지만, 열린 하네스인 Pi의 GitHub 저장소를 보면 시스템 프롬프트 설계·컨텍스트 압축·서브에이전트 처리 방식을 직접 확인할 수 있다.
• Pi는 모든 것을 하네스에 넣는 대신 필요할 때 스킬 파일을 주입하는 철학을 택해 시스템 프롬프트가 다른 하네스보다 훨씬 작다.
• 하네스 엔지니어링이 주목받는 이유는 Claude Code·Codex가 비싸기 때문이다. 여섯 구성 요소를 직접 설계할 줄 알아야 자신만의 저렴한 코딩 에이전트를 만들 수 있다.
• 새 용어는 앞으로도 계속 등장하지만, 제1원리로 설명하고 이해하는 습관이 있으면 어떤 신조어에도 혼동하지 않는다.

자주 묻는 질문

관련 AI 소식