프롬프트·컨텍스트·하네스 엔지니어링을 분리해 AI 에이전트 역량 설계하기

에이전트의 성과는 지시문 바깥에서 결정되기도 한다

프롬프트 엔지니어링(2022~24), 컨텍스트 엔지니어링(2025), 하네스 엔지니어링(2026)은 서로 대체하는 유행어가 아니다. 모델에 무엇을 지시할지, 모델이 무엇을 알게 할지, 그리고 에이전트가 주어진 일을 신뢰성 있게 끝낼 환경을 어떻게 만들지를 안쪽부터 바깥으로 감싸는 구조다.

이 프레이밍이 자리 잡으면서 AI 활용 역량의 범위도 지시문 작성에서 에이전트 환경 전체 설계로 넓어졌다. 말(words)에서 지식(knowledge)으로, 다시 시스템(systems)으로 옮겨가는 변화다. 조직이 어느 계층까지 다루는지를 보면 AI 활용 성숙도를 가늠할 수 있다.

2026년 초 Terraform·Ghostty 제작자 Mitchell Hashimoto가 하네스 엔지니어링이라는 용어를 대중화한 것으로 알려졌다. 같은 해 3월 LangChain 엔지니어링 팀은 모델을 바꾸지 않고 하네스 최적화만으로 Terminal Bench 2.0 순위를 30위에서 5위로 끌어올렸다.

지시·정보·환경을 나눠 설계하는 구조

프롬프트 계층은 단일 상호작용에서의 작업 정의를 맡는다. 시스템 프롬프트, 출력 스키마, 예시 세트와 불확실한 상황에서의 행동 규정이 이 계층의 산출물이다. 이런 자산은 버전 관리 대상이며, 모델 세대가 바뀌면 다시 검증해야 한다.

컨텍스트 계층은 컨텍스트 창에 넣을 정보와 제외할 정보, 그리고 배치 순서를 정한다. 검색 결과, 대화 이력, 도구 출력, 시스템 지시를 조립하고 컨텍스트 예산과 관련성 랭킹 로직을 관리한다. 프롬프트가 단일 상호작용의 지시를 다룬다면, 컨텍스트는 하나의 컨텍스트 창에서 여러 턴에 걸쳐 필요한 정보를 큐레이션한다.

하네스는 이 둘의 바깥에서 작동한다. 컨텍스트 리셋, 구조화된 인계 산출물, 단계 게이트를 통해 여러 컨텍스트 창을 넘나드는 목표 지향 작업을 다룬다. 동작하는 환경과 넘을 수 없는 경계, 실패했을 때 복구를 돕는 시스템을 만드는 계층이다.

도구 등록, 메모리, 실행 환경, 관측은 하네스의 핵심 구성이다. 도구 목록 자체도 컨텍스트를 소비하므로 도구 등록 계층과 컨텍스트 조립 계층은 완전히 분리되지 않는다. 단기 기억과 장기 기억을 어떻게 나눌지, 무엇을 저장하고 회수할지 역시 결과에 영향을 준다. 무엇을 기억시킬지가 무엇을 검색할지보다 더 큰 영향을 주는 경우도 많다.

⤢✕

실행 환경에서는 샌드박스 경계와 파일시스템·네트워크 접근 범위, 실행 결과를 확인하는 수단을 정한다. 검증은 마지막에 한 번 몰아서 하기보다 각 단계 뒤에 두는 편이 오류를 일찍 잡는다. 실행 로그, 도구 호출 이력, 토큰 소비, 실패 지점을 관측하지 못하면 하네스 최적화는 추측에 머문다. 순위를 25계단 끌어올린 사례도 측정 가능한 벤치마크가 있었기에 개선 근거를 확보할 수 있었다.

조직에 남는 산출물로 바꾸기

역할을 계층에 맞춰 나누면 하네스 문제를 프롬프트 수정으로 해결하려는 반복을 줄일 수 있다. 프롬프트 계층은 도메인 전문가와 제품 담당자, 컨텍스트 계층은 데이터·검색 담당자, 하네스 계층은 플랫폼 엔지니어가 주도하는 분담이 자연스럽다.

역량을 점검할 때는 프롬프트가 버전 관리되는지, 컨텍스트 조립 로직이 코드로 분리돼 있는지, 도구 권한과 검증 루프가 설계돼 있는지, 실행을 관측하는지를 확인한다. 각 계층을 없음·임시·표준화·측정 기반 개선의 4단계로 평가하면 다음 투자 지점을 찾을 수 있다.

산출물도 분리해 관리해야 한다.

프롬프트 계층: 저장소 관리와 회귀 평가셋
컨텍스트 계층: 컨텍스트 예산 정의서와 조립 템플릿
하네스 계층: 도구 카탈로그, 권한 매트릭스, 검증 루프 설계서

산출물이 있어야 리뷰와 인수인계가 가능하다. 머릿속에만 있는 설계는 조직 자산으로 남지 않는다. 프롬프트의 형식 준수율, 컨텍스트의 관련 정보 회수율·토큰 효율, 하네스의 작업 완료율·자기 수정률·에스컬레이션 빈도를 각각 측정하면 최종 작업 완료율이 흔들릴 때 수정할 계층을 찾을 수 있다.

로드맵은 프롬프트 자산화에서 시작해 컨텍스트 조립 코드화, 도구·권한 설계, 검증 루프, 관측 기반 개선으로 이어진다. 컨텍스트 관리 없이 하네스부터 만들면 도구는 많지만 판단이 흐린 에이전트가 될 수 있다.

권한 스코프 변경은 보안 검토 대상으로, 프롬프트 변경은 품질 검토 대상으로 두는 식으로 승인 주체도 구분할 수 있다. 도구 목록, 권한, 메모리 범위를 포함한 하네스 구성은 형상관리 항목으로 등록해야 재현성과 감사를 확보할 수 있다.

반복 운영 에이전트에서 하네스가 갖는 의미

구분	하네스 중심 설계	프롬프트 튜닝 중심
성과 지속성	모델 교체에도 유지	모델 세대마다 재작업
초기 투자	큼	작음
개선 근거	관측 데이터	시행착오
실패 대응	구조적 복구 경로	재시도
조직 자산화	시스템으로 축적	개인 노하우
적합 상황	반복 운영 에이전트	일회성·탐색 작업

프롬프트 튜닝은 빠르게 효과를 낼 수 있지만, 모델이 바뀌면 상당 부분을 다시 작업해야 하고 개인 노하우로 남기 쉽다. 반면 하네스는 도구, 메모리, 검증 루프를 시스템으로 축적하므로 모델 교체 뒤에도 성과를 유지할 수 있다. 같은 모델로 25계단을 끌어올린 사례는 개선 여지가 프롬프트보다 하네스에 크게 남아 있을 수 있음을 보여준다.

계층을 분리하면 변경 영향 범위와 담당 역할이 선명해진다. 초기에는 프롬프트 파일 하나에 지시, 컨텍스트 조립, 도구 설명을 함께 두는 방식이 단순해 보일 수 있다. 하지만 규모가 커지면 손대기 어려운 파일이 된다. 계층 분리는 소프트웨어 공학의 관심사 분리를 에이전트 설계에 적용하는 방식이다.

자체 하네스는 도메인에 맞는 검증 루프와 권한 모델을 설계할 수 있지만 시간이 든다. 상용 에이전트 프레임워크는 도구 등록, 메모리, 관측을 기본 제공해 빠르게 시작할 수 있으나 프레임워크의 추상화에 맞춰야 한다. 하네스가 성과의 주요 변수라면, 프레임워크 선택은 성과 상한 선택이기도 하다. 검증 루프를 얼마나 커스터마이징할 수 있는지가 판단 기준이 된다.

역량관리와 지식관리 관점에서 본 성숙도

AI 활용 역량을 프롬프트 작성 능력으로만 정의하면 조직의 역량은 개인기에 머문다. 계층 구조는 역량을 직무별로 나누고, 채용과 교육에서 각 인력이 맡을 계층을 명시할 수 있게 한다.

계층별 4단계 성숙도 진단은 CMM류 성숙도 모델과 동형이다. 측정 기반 개선 단계에 도달하려면 관측 계층이 먼저 갖춰져야 한다. 기반이 부족한 조직이 상위 계층에 먼저 투자하면 효과가 나기 어렵다.

도구 카탈로그, 권한 매트릭스, 검증 루프 같은 하네스 설계 산출물은 조직의 지식 자산이다. 문서화하지 않으면 담당자 이탈과 함께 사라진다. 프롬프트 자산과 하네스 구성을 함께 버전 관리해야 특정 성과가 어떤 조합에서 나왔는지도 재현할 수 있다.

2026년에 보이는 변화

하네스 엔지니어링은 독립 직무 영역으로 인식되면서 플랫폼 엔지니어링 조직에 흡수되는 흐름을 보인다. 에이전트 성능을 비교할 때도 모델과 하네스를 나눠 보고하고, 벤치마크 결과에 하네스 구성을 명시하도록 요구하는 방향이 확산되고 있다.

도구 카탈로그 형식, 권한 매트릭스, 검증 루프 설계서처럼 계층별 산출물의 표준도 조직 간에 공유할 수 있는 형태로 정립되는 중이다. 상용 프레임워크가 하네스 계층 기능을 흡수하면서 자체 구축과 프레임워크 채택의 경계는 검증 루프 커스터마이징 가능 여부로 좁혀지고 있다.