AI기술

하네스 엔지니어링 완전 해설: AI 에이전트가 스스로 돌아가는 식당을 만드는 기술

마지막 업데이트: 2026-06-02

1. 요리를 잘한다고 식당이 돌아가는 건 아니다

1.1. 2편에서 여기까지

1편에서 셰프에게 요리를 가르치는 법(프롬프트 엔지니어링)을, 2편에서 셰프에게 재료와 도구를 세팅하는 법(컨텍스트 엔지니어링)을 다뤘습니다. 여기까지 하면 한 번의 좋은 요리는 나옵니다. 질문 하나에 대해 최적의 컨텍스트를 조립해서 좋은 답변을 내놓는 것까지는 됩니다.

프롬프트 엔지니어링 완전 해설 (1편) 컨텍스트 엔지니어링 완전 해설 (2편)

1.2. 식당 운영은 차원이 다르다

그런데 이 셰프로 식당을 열면 문제가 터집니다. 손님이 3명 동시에 들어오면 혼자서 못 돌립니다. 여러 셰프가 있으면 누가 지시하고 결과를 합칩니까. 재료가 상했으면 검수 체크리스트가 필요합니다. 오븐이 고장나면 대응 매뉴얼이 필요합니다. 교대 시 인수인계가 필요합니다. 어제 손님이 짜다고 했으면 오늘 간을 줄여야 합니다.

요리 실력 위에 식당이 돌아가게 만드는 모든 것이 필요합니다.

1.3. 하네스 엔지니어링의 정의

Anthropic이 한 문장으로 정의합니다. "하네스란 언어 모델과 실제 세계 사이의 모든 것이다." 모델은 텍스트를 생성하고, 하네스는 그 텍스트가 무엇에 닿을 수 있는지를 결정합니다. (Anthropic Engineering)

하네스 엔지니어링은 단순히 매뉴얼을 만드는 것이 아닙니다. 매뉴얼을 만들고, 그 매뉴얼대로 자동으로 돌아가는 시스템까지 구축하는 것입니다. 주문 접수 태블릿, 주방 디스플레이, 재고 자동 차감, 위생 점검 알림까지 실제로 돌아가는 시스템을 깔아주는 겁니다. 셰프는 요리에만 집중하고, 나머지는 시스템이 처리합니다.

이 용어는 2025년 11월 Anthropic 엔지니어링 블로그에서 처음 공식 사용되었습니다. 2024년 12월 "Building Effective Agents"에서는 아직 등장하지 않았고, 불과 11개월 만에 업계 표준 용어로 자리잡았습니다.

시리즈 "AI 엔지니어링의 진화" 3부작 中 3편. 1편은 프롬프트 엔지니어링, 2편은 컨텍스트 엔지니어링을 다뤘습니다.

2. 하네스의 7가지 기술

식당 운영에 필요한 것을 하나씩 기술 용어로 연결하겠습니다. 예시로는 HiveWorks Invest에서 실제로 개발하고 있는 기업 분석 밸류에이션 리포트 사례로 설명합니다.

2.1. 에이전트 루프: 셰프가 스스로 루프를 돈다

1편에서는 사람이 매번 "이렇게 해"라고 지시했습니다. 2편에서는 재료와 도구를 세팅해줬지만, 여전히 한 번의 요청-응답이었습니다. 3편에서는 셰프가 스스로 루프를 돕니다.

이 루프를 AI가 스스로 "됐다"고 판단할 때까지 반복합니다. 학계에서는 이를 ReAct(Reasoning + Acting) 패턴이라고 부릅니다. 2022년 논문에서 제안되었고, 지금 거의 모든 AI 에이전트의 기본 동작입니다. (Yao et al., 2022)

기업 분석 AI에서 이 루프는 이렇게 돌아갑니다. 종목을 받으면, 공시 읽기, 재무 데이터 수집, 경쟁사 비교, 밸류에이션 계산, 리포트 초안 작성, 팩트 체크, 완성. 사람이 매 단계를 지시하지 않습니다.

중요한 건 루프를 언제 멈추느냐입니다. "요리 완성"을 셰프가 스스로 판단하는데, 이 판단이 틀리면 문제가 됩니다. 너무 일찍 멈추면 반쪽짜리 리포트가 나가고, 안 멈추면 무한히 돌면서 비용만 먹습니다.

Anthropic은 이 문제의 실전 해결책을 제시합니다. 200개 이상의 세부 기능을 JSON 목록으로 만들어서 에이전트에게 주는 겁니다. "이 목록의 모든 항목이 완료되어야 끝이다." 조기 종료를 구조적으로 방지합니다. (Anthropic Engineering)

2.2. 멀티에이전트: 셰프 혼자서는 한계가 있다

에이전트 루프가 기본 동작이라면, 왜 에이전트 하나로 안 될까요. 리서치도 하고 분석도 하고 글도 쓰는 에이전트 하나면 되지 않을까요.

안 됩니다. 리서치할 때 필요한 지식(검색 전략, 데이터 소스)과 글 쓸 때 필요한 지식(톤 가이드, 글쓰기 규칙)이 다릅니다. 하나의 컨텍스트 윈도우에 전부 넣으면 어느 것도 제대로 못합니다. 한 셰프가 전채부터 디저트까지 전부 만드는 것과, 전문 셰프가 각자 맡는 것의 차이입니다.

기업 분석 AI라면 이런 팀이 됩니다. 리서치 에이전트(데이터 수집 전문), 분석 에이전트(밸류에이션 계산 전문), 작성 에이전트(리포트 변환 전문), 검증 에이전트(수치 정합성·출처 유효성 체크 전문). 각 에이전트는 자기 전문 영역의 컨텍스트만 갖습니다.

Anthropic의 멀티에이전트 연구 시스템 데이터가 이를 뒷받침합니다. 리드 에이전트 + 서브에이전트 구조가 단일 에이전트 대비 90.2% 성능 향상을 보였습니다. 병렬화로 복잡한 작업의 연구 시간을 최대 90% 단축했습니다. (Anthropic Engineering)

다만 비용이 있습니다. 같은 연구에서 멀티에이전트는 단일 에이전트 대비 토큰을 15배 소비했습니다. 성능은 올라가지만 비용도 올라갑니다. 셰프 4명 월급이 1명보다 비싼 것과 같습니다.

2.3. 오케스트레이션: 주방장이 필요하다

셰프 4명이 각자 요리하면 식당이 돌아갈까요. 안 됩니다. "너는 리서치 해, 너는 분석 해, 리서치 끝나면 결과를 분석에 넘겨"라고 지시하는 주방장이 필요합니다. 이것이 오케스트레이션입니다.

핵심 패턴이 4가지 있습니다.

Supervisor(주방장)

주방장 에이전트가 각 전문 에이전트에게 지시하고 결과를 합칩니다. 가장 보편적인 패턴입니다. HiveWorks Invest에서 팀장 에이전트가 전문가 팀원을 지휘하는 구조입니다.

Pipeline(릴레이)

리서치, 분석, 작성, 검증. 앞 에이전트 결과가 뒤 에이전트 입력이 됩니다. 순서가 고정된 작업에 적합합니다.

Swarm(자율 분업)

주방장 없이 각 에이전트가 스스로 "내가 할 일이 있네"를 판단하고 작업합니다. 100개 종목을 동시 분석할 때 적합합니다. 확장성은 최고지만 추적이 어렵습니다.

Hierarchical(계층 위임)

팀장, 파트장, 실무자. "반도체 분석해"라고 하면 반도체 파트장이 "삼성 너 해, 하이닉스 너 해"로 재위임합니다. 대규모(50개 이상 에이전트) 작업에 적합합니다.

Anthropic은 이를 Workflow와 Agent로 구분합니다. Workflow는 미리 정의된 코드 경로(Pipeline처럼 순서 고정), Agent는 LLM이 동적으로 지시(Supervisor처럼 상황 판단). "필요에 맞는 올바른 시스템을 구축하는 것이 핵심이다." (Anthropic Research)

2.4. 가드레일: 이건 손님한테 못 내보내

AI가 "SK하이닉스 적정가 $250, 지금 당장 사세요"라고 쓰면 법적으로 문제가 됩니다. 출처 없이 "HBM 시장점유율 90%"라고 쓰면 신뢰가 무너집니다. 가드레일은 "이건 하면 안 돼"를 시스템으로 강제하는 것입니다.

3계층으로 나뉩니다.

입력 가드레일: "메뉴에 없는 건 안 만듭니다"

시스템 지시를 우회하려는 입력(프롬프트 인젝션)을 차단합니다. OWASP 2025 기준 AI 보안 취약점 1위이며, 2025년 하반기 공격 시도가 전년 대비 340% 증가했습니다. (Obsidian Security)

출력 가드레일: "이건 손님한테 못 내보내"

매매 권유 표현, 면책 누락, 출처 없는 수치를 발행 전에 걸러냅니다. HiveWorks Invest의 "발행 전 자동 검증"이 이 역할입니다.

행동 가드레일: "셰프가 금고에 손대지 못하게"

에이전트가 할 수 있는 행동 자체를 제한합니다. 리서치 에이전트는 데이터를 읽을 수만 있고, 발행은 사람의 최종 승인이 있어야만 가능합니다.

Anthropic은 이 설계를 "추론과 집행의 분리"라고 표현합니다. 모델이 하고 싶은 것을 결정하고, 다른 시스템이 허용 여부를 결정합니다. 셰프가 메뉴를 제안하고, 사장이 승인하는 구조입니다.

실수가 나는 지점은 균형입니다. 가드레일을 너무 느슨하게 하면 위험한 출력이 나가고, 너무 빡빡하게 하면 에이전트가 아무것도 못 합니다. 재료 검수를 너무 엄격하게 해서 멀쩡한 재료도 다 버리는 상황입니다.

2.5. 에러 핸들링: 오븐이 고장났을 때

리포트를 만드는 도중 증권사 데이터 소스가 404입니다. 실적 API가 타임아웃입니다. 리서치 에이전트가 수집한 데이터와 분석 에이전트의 계산이 안 맞습니다.

재시도: "불 세기 조절해서 다시"

API 타임아웃이면 간격을 늘려가며 재시도합니다. 1초, 2초, 4초, 8초. 같은 간격으로 반복하면 서버에 부하만 더합니다.

대안 전환: "가스 안 되면 전기 오븐"

데이터 소스 하나가 막히면 같은 내용의 다른 소스로 전환합니다.

에스컬레이션: "사장님, 이건 저는 못합니다"

에이전트가 해결 못 하는 문제는 사람에게 넘깁니다.

가장 위험한 실수는 에러를 에러로 인식하지 못하는 것입니다. 리서치 에이전트가 존재하지 않는 가상 URL을 만들어내고, 검증 에이전트가 이를 통과시키면, 출처가 허구인 리포트가 나갑니다. HiveWorks Invest에서 모든 URL을 수집 즉시 검증하는 규칙을 만든 이유가 이것입니다.

2.6. 상태 관리: 교대 시 인수인계

2편에서 다뤘듯이 AI는 매 세션 백지에서 시작합니다. 밸류에이션 리포트는 하루에 안 끝납니다. 여러 세션에 걸쳐 여러 에이전트가 작업합니다. 어제 리서치에서 발견한 핵심 인사이트를 오늘 분석 에이전트가 모릅니다.

상태 관리는 교대 시 인수인계 메모입니다. 에이전트 간 작업 결과를 구조화된 형태로 전달하여 연속성을 만듭니다. 에이전트의 기억이 아니라, 파일에 기록된 상태가 연속성의 원천입니다.

Anthropic은 이를 구조화된 파일(claude-progress.txt, JSON 기능 목록)과 Git 커밋으로 구현합니다. 새 세션이 시작되면 진행 파일을 읽고, Git 로그를 확인하고, 중단된 지점부터 이어갑니다. (Anthropic Engineering)

인수인계가 불완전하면 구버전 잔재가 남습니다. 이전 단계에서 수치를 수정했는데, 다음 에이전트가 수정 전 숫자를 쓰는 겁니다. "3번 테이블 알레르기 있다"를 인수인계 안 하면 사고가 납니다.

2.7. 피드백 루프: 어제 짜다고 했으니 오늘 간 줄여

리포트를 발행했습니다. 끝이 아닙니다. 다음 분기에 실적이 나옵니다. 가정한 수치가 실제와 다릅니다. 적정가가 바뀌어야 합니다. 독자가 "이 표현은 오해를 살 수 있다"고 피드백합니다.

실시간 검증: "매일 아침 재료 상태 체크"

발행 종목의 가정을 매일 점검합니다. 실적 발표, 공시, 환율 변동. 확정 데이터가 가정과 달라지면 갱신합니다.

시스템 학습: "같은 클레임 3번이면 레시피 자체를 수정"

동일한 피드백이 반복되면 개별 수정이 아니라 전체 시스템의 규칙으로 승격합니다. 한 번의 실수를 고치는 게 아니라, 같은 실수가 재발하지 않는 구조를 만듭니다.

이것이 하네스와 단순 자동화의 차이입니다. 단순 자동화는 정해진 대로 반복합니다. 하네스는 결과를 보고 스스로를 개선합니다.

3. 구체적으로 어떻게 만드는가

3.1. 두 가지 길

하네스를 구축하는 길은 두 가지입니다.

길 1: 프레임워크를 쓴다

LangGraph, CrewAI, OpenAI Agents SDK 같은 도구를 가져다 씁니다. 프랜차이즈 매뉴얼을 받아서 운영하는 겁니다. 빠르지만, 우리 식당에 안 맞을 수 있습니다.

길 2: 직접 만든다

LLM API를 직접 호출하는 코드를 짜서, 우리 서비스에 딱 맞는 하네스를 만듭니다. Anthropic이 이쪽을 권장합니다. "프레임워크의 기저 코드를 이해하라", "필요에 맞는 올바른 시스템을 구축하라." (Anthropic Research)

HiveWorks Invest는 길 2입니다. 기업 분석이라는 도메인 특성상, 면책 규칙, 밸류에이션 검증 로직, 종목별 가정 모니터링 같은 것은 범용 프레임워크에 없습니다. 자체 하네스를 설계하고 계속 개선하고 있습니다.

3.2. 1단계: 셰프 한 명부터

LLM API를 호출하고, "너는 기업 분석가다"라는 시스템 프롬프트를 주고, 시세 조회, 웹 검색, 파일 작성 같은 도구를 연결합니다. 에이전트 루프를 만듭니다. "도구를 쓸 필요가 있으면 써, 끝났다고 판단하면 멈춰."

이것만으로 기본적인 분석이 나옵니다.

Anthropic도 이를 권장합니다. "단일 에이전트 + 좋은 프롬프트 + 도구로 먼저 최적화하라. 복잡성은 필요할 때만 추가하라."

그리고 Anthropic이 강조하는 포인트가 있습니다. "프롬프트 최적화보다 도구 설계에 더 많은 시간을 쓰라." 셰프의 레시피를 다듬는 것보다, 셰프가 쓰는 도구를 좋은 걸로 바꾸는 게 더 효과적입니다. 검색 도구가 엉뚱한 결과를 가져오면 프롬프트를 아무리 잘 써도 소용없습니다.

3.3. 2단계: 팀을 꾸린다

한 에이전트가 리서치도 하고 분석도 하고 글도 쓰니까, 어느 것도 제대로 못합니다. 그래서 쪼갭니다. 에이전트마다 별도 시스템 프롬프트를 설계합니다. 그리고 어떤 순서로 일하고, 결과를 어떻게 전달할지 오케스트레이션을 설계합니다.

3.4. 3단계: 문제가 터질 때마다 시스템을 보강한다

팀이 리포트를 만들기 시작하면 처음 보이지 않던 문제들이 터집니다.

검증 없이 내보냈더니 출처가 가짜인 리포트가 나갔습니다. 가드레일을 추가합니다.

API가 죽어서 리서치가 중간에 멈췄습니다. 에러 핸들링을 추가합니다.

어제 리서치한 데이터를 오늘 분석 에이전트가 모릅니다. 상태 관리를 추가합니다.

발행한 리포트의 가정이 틀렸는데 아무도 모릅니다. 피드백 루프를 추가합니다.

핵심은 처음부터 7가지를 다 설계하는 게 아니라, 1→2→3 단계로 필요할 때 추가한다는 겁니다. Anthropic 표현을 빌리면, "모든 하네스 구성요소는 모델이 혼자서 할 수 없다는 가정을 인코딩한다." 모델의 한계를 발견할 때마다 하네스가 한 겹씩 두꺼워집니다.

4. 한계와 미래: 하네스는 끝이 아니다

4.1. 현재 한계: 식당 사장은 여전히 사람이다

지금까지 설명한 모든 것을 AI 엔지니어가 설계합니다. 어떤 에이전트에게 어떤 도구를 주고, 어떤 순서로 실행하고, 어떤 에러에 어떻게 대응할지. 전부 사람의 판단입니다.

Anthropic이 정확히 짚습니다. "모든 하네스 구성요소는 모델이 혼자서 할 수 없다는 가정을 인코딩한다." (Anthropic Engineering)

그런데 이 방향도 바뀌고 있습니다. AI가 다른 AI의 결과를 평가하는 LLM-as-Judge, AI가 스스로 작업 계획을 세우는 자율 계획, AI가 피드백을 기반으로 자기 행동을 수정하는 자기 개선 에이전트까지. 사람이 설계하던 하네스의 일부를 AI 스스로가 만들어가는 단계로 넘어가고 있습니다. 아직 초기이지만, 방향은 명확합니다. 식당 사장의 역할도 점점 자동화되는 쪽으로 가고 있습니다.

4.2. 모델이 좋아지면 하네스가 바뀐다

작년에는 AI가 긴 작업 중간에 포기하는 문제(context anxiety)가 있어서 강제 분할 하네스가 필요했습니다. 올해 모델에서는 이 문제가 사라졌습니다. 그 하네스 코드는 이제 불필요합니다. (Anthropic Engineering)

"더 나은 모델을 얻으면, 하네스를 다시 검토하고 불필요한 부분을 제거하는 것이 일반적 관행이다." 그런데 흥미로운 점이 있습니다. "흥미로운 하네스 조합의 공간은 축소되지 않는다. 이동한다." 기존 문제가 해결되면 더 어려운 문제에 도전하게 되고, 그 문제를 위한 새로운 하네스가 필요해집니다.

4.3. 지금 세상은 어디까지 왔는가

Agentic AI 시장이 폭발하고 있습니다. 2025년 $7.55B에서 2034년 $199B으로 성장이 예측됩니다(CAGR 43.84%). Gartner는 2026년 말까지 기업 애플리케이션의 40%에 AI 에이전트가 포함될 것으로 예측합니다. (Precedence Research)

AI 코딩 에이전트 Devin은 $26B 기업 가치를 인정받았고, 자기 회사 코드의 90%를 AI가 작성하는 수준까지 왔습니다. (Bloomberg)

에이전트 간 통신도 표준화되고 있습니다. 2편에서 다룬 MCP가 "에이전트와 도구의 연결"이었다면, Google이 주도하는 A2A(Agent-to-Agent) 프로토콜은 "에이전트와 에이전트의 연결"입니다. 150개 이상 조직이 참여하고 있습니다. 식당 하나의 운영을 넘어, 식당들끼리 협업하는 시대가 열리고 있습니다. (Google Developers)

🔬MCP란 무엇인가? AI를 세상과 연결하는 오픈 표준 프로토콜

AI의 단절 문제, 이전 시도의 실패, MCP의 해결 방식, 실전의 벽까지 완전 해설합니다

→

4.4. 시리즈를 마치며

1편에서 셰프에게 요리를 가르치는 법을 배웠습니다. 어떻게 지시하면 더 좋은 결과가 나오는지. 2편에서 셰프에게 재료와 도구를 세팅하는 법을 배웠습니다. 컨텍스트 윈도우 안에 무엇을, 어떤 순서로 넣을지. 3편에서 셰프 여러 명이 식당을 운영하는 시스템을 설계하는 법을 다뤘습니다. 에이전트 루프, 분업, 조율, 안전장치, 에러 대응, 인수인계, 학습까지.

프롬프트에서 컨텍스트로, 컨텍스트에서 하네스로. AI를 키우는 과정은 한 번의 좋은 결과에서, 매일 돌아가는 시스템으로 진화하는 여정입니다.