ICLR 2026(국제 학습 표현 컨퍼런스) 현장에서 데이터 사이언티스트 T씨는 에이전트를 설명하는 '하네스'와 '스캐폴드'라는 용어가 사람마다 다르게 쓰이는 것을 보고 당혹감을 느꼈다. 특히 여러 전문가의 설명을 들었음에도 불구하고, 왜 이 용어들이 하나의 정의로 수렴되지 않는지에 대해 깊은 의문을 가졌다.

단순히 단어 선택의 문제가 아니다. 모델을 어떻게 감싸느냐에 따라 AI의 행동 방식이 완전히 달라지기 때문이다. 특히 최근 등장한 에이전트 도구들은 모델의 성능만큼이나 그 주변을 둘러싼 실행 환경의 설계가 중요하다는 점을 시사한다. 모델은 기본적으로 텍스트를 입력받아 출력하는 역할만 수행할 뿐, 스스로 루프를 돌거나 외부 도구를 실행할 능력이 없다. 모델이 도구를 호출하겠다는 '의도'를 표현할 수는 있지만, 이를 실제로 실행에 옮기려면 반드시 외부의 보조 장치가 필요하다. 결국 모델을 '에이전트'로 만드는 것은 그 외부에 붙는 보이지 않는 구조물들이다.

많은 실무자가 이 구조물을 단순히 '프롬프트'나 '코드' 정도로 뭉뚱그려 생각하곤 한다. 이로 인해 협업 과정에서 서로 다른 개념을 같은 단어로 부르거나, 반대로 같은 기능을 다른 용어로 설명하며 소통 비용을 낭비하는 일이 빈번하다. 특히 모델 학습 단계와 추론 단계에서 이 용어들이 갖는 의미가 미묘하게 달라지면서 혼란은 가중된다. 이런 곤란을 겪는 개발자가 늘고 있다.

Claude Code와 Codex가 보여주는 '하네스'의 실체

개발자가 터미널에서 Claude Code(앤스로픽의 코딩 에이전트)를 실행해 복잡한 버그를 수정하게 시키는 장면을 떠올려보자. 단순히 코드를 짜달라고 요청하는 것과 내 컴퓨터의 파일을 직접 읽고 수정하며 테스트까지 수행하는 것은 완전히 다른 차원의 작업이다. 여기서 핵심은 모델 그 자체가 아니라 모델을 감싸고 있는 실행 계층의 존재다. 쉽게 말하면 뇌만 있는 상태에서 팔다리와 감각 기관을 달아준 것과 같다. 오픈AI의 Codex(코드 생성 모델)는 훌륭한 코드를 생성하지만 스스로 그 코드를 실행해 결과를 확인하고 수정하는 능력은 없다. 모델은 그저 텍스트를 입력받아 텍스트를 내뱉는 함수일 뿐이며 호출과 호출 사이의 기억이나 반복 루프를 스스로 생성하지 못한다.

모델의 이런 한계를 메우기 위해 도입된 개념이 하네스(Harness)다. 비유하자면 암벽 등반가가 몸에 착용하는 안전벨트나 강아지 산책용 가슴줄처럼 모델이 외부 세계와 안전하게 연결되어 실제로 움직일 수 있게 돕는 장치다. 앤스로픽은 공식 문서에서 "Claude Code serves as the agentic harness around Claude"라고 명시하며 Claude Code가 모델을 둘러싼 에이전트적 하네스 역할을 한다고 설명했다. 하네스는 모델이 도구를 사용하겠다는 의사를 밝히면 실제로 그 도구를 실행하고 그 결과를 다시 모델에게 전달하는 루프를 관리한다. 모델이 응답을 마치고 멈추는 시점을 결정하거나 실행 중 오류가 발생했을 때 어떻게 대처할지 제어하는 실행 계층이 바로 하네스의 정체다.

하네스의 설계 방식에 따라 제품의 성격이 완전히 갈리는 지점이 여기서 나타난다. Claude Code나 Codex 같은 제품은 특정 모델에 최적화되어 강력하게 결합되어 있다. 반면 Antigravity CLI(명령줄 인터페이스 기반 에이전트 도구)나 Hermes Agent(오픈소스 기반 에이전트 프레임워크)는 하네스라는 틀은 유지한 채 내부의 모델만 자유롭게 갈아 끼울 수 있는 구조를 취한다. 이는 마치 고성능 로봇 슈트를 구입한 뒤 그 안에 어떤 인공지능 칩을 넣느냐에 따라 작동 방식이 달라지는 것과 비슷하다. 동일한 모델을 사용하더라도 하네스가 어떤 제어 로직을 선택하느냐에 따라 사용자가 체감하는 제품의 성능과 경험은 완전히 달라진다.

에이전트의 구조를 수식으로 표현하면 모델과 하네스의 결합체라고 할 수 있다. 모델이 지능을 담당한다면 하네스는 그 지능이 현실에서 작동하게 만드는 물리적 실행력을 담당한다. 하네스 엔지니어링(Harness Engineering)이라는 분야가 중요해지는 이유도 여기에 있다. 단순히 프롬프트를 잘 쓰는 수준을 넘어 에이전트가 언제 작업을 멈춰야 하는지, 가드레일을 어떻게 설정해 엉뚱한 동작을 막을지 설계하는 것이 에이전트의 완성도를 결정한다. 모델은 텍스트를 생성하는 역할에 그치지만 하네스는 그 텍스트를 실제 환경에서의 행동으로 변환하는 핵심 엔진 역할을 수행한다.

스캐폴드와 하네스, '설계도'와 '엔진'의 차이

개발자가 바로 체감하는 변화는 응답 속도보다 제어권이다. LLM(거대언어모델) 단독으로는 텍스트를 주고받는 대화만 가능하지만, 여기에 스캐폴드와 하네스라는 장치가 붙으면 스스로 도구를 쓰고 작업을 완수하는 에이전트가 된다. 모델 자체는 입력을 받아 텍스트를 내뱉는 함수에 가깝기에 스스로 기억을 유지하거나 외부 도구를 직접 실행할 능력이 없다. 모델이 도구를 사용하겠다는 의지를 표현하면 이를 가로채어 실제 동작으로 연결하는 외부 시스템이 필요한데, 이것이 바로 스캐폴드와 하네스의 역할이다.

먼저 스캐폴드(Scaffold)는 모델이 어떻게 행동해야 할지 정의하는 가이드라인이다. 비유하자면 건축 현장의 임시 가설물이나 정교한 설계도와 같다. 여기에는 모델에게 부여하는 정체성인 시스템 프롬프트부터, 사용할 수 있는 도구의 상세 설명, 모델의 답변을 어떻게 해석할지에 대한 파싱 규칙, 그리고 대화의 흐름을 기억하는 컨텍스트 관리 방식이 포함된다. 쉽게 말하면 모델이 세상을 바라보는 관점과 행동 양식을 결정하는 틀이다. 특히 컨텍스트 관리는 모델이 이전 단계에서 무엇을 했고 어떤 결과를 얻었는지 기억하게 하여 다음 행동을 결정하게 만드는 핵심적인 설계 요소가 된다.

반면 하네스(Harness)는 이 설계도를 바탕으로 실제로 모델을 구동하는 실행 계층이다. 비유하자면 설계도대로 움직이게 만드는 엔진이나 제어 장치에 가깝다. 하네스는 모델을 호출하고, 모델이 도구를 쓰겠다고 신호를 보내면 실제로 그 도구를 실행하며, 언제 작업을 멈출지 결정하는 루프(반복 과정)를 담당한다. 모델은 단지 텍스트로 도구 호출 의사를 밝힐 뿐이지만, 하네스는 이를 실제 API 호출이나 코드 실행으로 전환해 결과를 다시 모델에게 전달한다. 이 과정이 반복되며 에이전트는 복잡한 목표를 단계적으로 달성하게 된다.

에이전트의 실체는 모델에 하네스를 입힌 결과물이다. 더 세분화하면 모델과 스캐폴드, 그리고 하네스가 결합한 형태라고 볼 수 있다. 여기서 하네스 엔지니어링(Harness Engineering)이라는 전문 영역이 등장한다. 이는 에이전트가 무한 루프에 빠지지 않도록 중단 시점을 정교하게 설계하고, 예상치 못한 에러가 발생했을 때의 처리 경로를 만들며, 안전하게 작동하도록 가드레일(제한 장치)을 세우는 학문이다. 동일한 모델을 쓰더라도 하네스를 어떻게 설계하느냐에 따라 에이전트의 성능과 사용자 경험은 완전히 달라진다. 하네스가 부실하면 모델이 아무리 똑똑해도 엉뚱한 곳에서 멈추거나 치명적인 오류를 일으키기 때문이다.

도구(Tool)부터 서브 에이전트(Sub-agent)까지의 계층 구조

개발자가 에이전트를 설계할 때 가장 먼저 고민하는 지점은 외부 세계와 어떻게 연결할 것인가이다. 가장 기초적인 단계가 바로 도구(Tool)다. 도구는 API(응용 프로그램 인터페이스)나 코드 인터프리터, 데이터베이스, 웹 검색처럼 외부의 특정 기능을 호출하는 수단을 의미한다. 비유하자면 도구는 망치나 계산기 같은 단순한 장비와 같다. 사용자가 망치질을 하라고 명령하면 정확히 그 지점을 때리는 것처럼, 도구는 입력된 값에 따라 정해진 결과만을 반환한다. 모델이 스스로 생각해서 결과를 만드는 것이 아니라 외부의 정해진 기능을 빌려 쓰는 방식이다.

단순한 도구만으로는 여러 단계를 거쳐야 하는 복잡한 업무를 처리하기 어렵다. 이때 필요한 것이 스킬(Skill)이다. 스킬은 다단계 작업을 가능하게 만드는 재사용 가능한 지식 패키지다. 쉽게 말하면 도구가 개별적인 연장이라면, 스킬은 그 연장들을 어떻게 사용해 결과물을 만들지 적어둔 매뉴얼이나 레시피에 가깝다. 버그를 조사하고 가설을 세운 뒤 수정안을 작성하는 일련의 과정이 하나의 스킬로 묶일 수 있다. 개발자는 매번 복잡한 지시를 내리는 대신 미리 정의된 스킬을 호출함으로써 에이전트가 일관된 방식으로 고난도 작업을 수행하게 만든다.

하지만 스킬조차 결국 정해진 절차를 따르는 패키지에 불과하다는 한계가 있다. 여기서 한 단계 더 나아간 것이 서브 에이전트(Sub-agent)다. 서브 에이전트는 단순히 기능을 수행하는 수준을 넘어 자체적인 모델과 스캐폴드(Scaffold, 모델의 동작을 정의하는 기본 구조)를 가진 독립적인 개체다. 비유하자면 도구가 망치고 스킬이 목공 매뉴얼이라면, 서브 에이전트는 숙련된 전문 목수와 같다. 메인 에이전트가 구체적인 방법론을 일일이 지시하지 않아도, 서브 에이전트는 스스로 상황을 추론하고 판단하여 최선의 결과를 도출해 돌아온다.

서브 에이전트와 일반 도구의 결정적인 차이는 바로 이 추론 능력과 독립성에 있다. 도구는 호출되면 정해진 함수를 실행하고 끝나는 일방향적 구조지만, 서브 에이전트는 목표를 달성하기 위해 스스로 계획을 세운다. 심지어 필요하다면 또 다른 서브 에이전트를 호출해 협업하는 계층적 구조를 형성하기도 한다. 단순한 기능 호출인 도구에서 시작해 지식의 묶음인 스킬을 거쳐, 스스로 생각하고 행동하는 서브 에이전트로 이어지는 이 계층 구조는 에이전트가 단순한 챗봇을 넘어 복잡한 자율 시스템으로 진화하는 핵심 경로가 된다.

컨텍스트 엔지니어링이 결정하는 에이전트의 성능과 비용

에이전트가 한 번에 읽어들일 수 있는 정보의 양인 컨텍스트 윈도우는 AI의 시야와 같다. 컨텍스트 엔지니어링은 이 제한된 시야 안에 무엇을 집어넣을지 정교하게 설계하는 과정이다. 여기에는 에이전트의 정체성을 규정하는 시스템 프롬프트, 사용할 수 있는 도구에 대한 상세 설명, 그리고 지금까지 주고받은 대화 이력과 외부에서 검색해 온 지식이 모두 포함된다. 비유하자면 전문 비서에게 업무를 맡기기 전, 책상 위에 꼭 필요한 서류와 업무 매뉴얼만 골라 배치하는 작업과 비슷하다. 무엇을 보여주고 무엇을 가릴지 결정하는 이 설계가 에이전트가 상황을 판단하고 행동하는 기준이 된다.

기억의 관리 방식은 단기와 장기로 구분하여 운영한다. 단기 기억은 단일 실행 과정에서 컨텍스트 윈도우 내에 유지되는 대화 이력이나 도구의 실행 결과 같은 정보들이다. 쉽게 말하면 지금 당장 책상 위에 붙여놓은 포스트잇처럼 즉각적으로 참조할 수 있는 데이터다. 반면 장기 기억은 여러 세션에 걸쳐 유지되는 정보로, 외부 저장소에 보관했다가 특정 시점에 필요하다고 판단될 때만 검색하여 다시 주입하는 방식이다. 이는 거대한 서류 보관함에서 필요한 파일만 찾아 책상으로 가져오는 과정에 비유할 수 있다. 하네스(Harness, 모델을 실행하고 제어하는 실행 계층)는 이 두 기억 체계를 조율하며 모델이 현재 단계에서 가장 적절한 정보만을 바라보게 만든다.

이러한 컨텍스트 설계의 성패는 곧 에이전트의 성능과 운영 비용으로 직결된다. 추론 단계에서 설계 실수가 발생해 엉뚱한 응답이 나온다면 프롬프트를 수정하고 다시 배포하는 정도로 비교적 가볍게 해결할 수 있다. 하지만 학습 단계에서의 실수는 차원이 다른 문제를 야기한다. 모델이 어떤 맥락을 통해 정답을 도출해야 하는지 배우는 과정에서 컨텍스트가 잘못 제공되었다면, 모델의 내부 가중치 자체가 왜곡되어 학습되기 때문이다. 이 경우 단순한 텍스트 수정이 아니라 막대한 컴퓨팅 자원과 시간을 투입해 모델을 처음부터 다시 학습시켜야 하는 최악의 상황이 발생한다. 이러한 정교한 설계 전략과 기억 주입 방법론은 HF(허깅페이스)의 Context Engineering Course에서 상세하게 다루고 있다.

한국 AI 실무자가 주목해야 할 '정책(Policy)'과 시스템 설계

동일한 최신 모델을 API로 연결했는데 A 서비스는 능숙하게 과업을 완수하고 B 서비스는 엉뚱한 대답만 반복하는 광경을 자주 본다. 개발자가 체감하는 이 차이는 모델의 성능보다 하네스(Harness) 설계의 완성도에서 갈린다. 쉽게 말하면 모델은 텍스트를 입력받아 텍스트를 내뱉는 엔진일 뿐이며, 이를 실제로 구동해 도구를 실행하고 멈춤 시점을 결정하는 제어 시스템이 바로 하네스다. 비유하자면 모델이 강력한 엔진이라면 하네스는 조향 장치와 브레이크가 포함된 차체와 같다. 따라서 모델, 하네스, 제품은 서로 완전히 다른 세 가지 개념으로 구분해야 한다. 동일한 모델을 쓰더라도 어떤 하네스를 입히느냐에 따라 사용자가 느끼는 제품 경험은 완전히 달라지기 때문이다.

여기서 실무자가 주목해야 할 핵심 개념이 정책(Policy)이다. 정책은 에이전트가 특정 상황에서 어떤 행동을 할 확률을 정의하는 규칙이다. 많은 이들이 정책을 모델의 가중치, 즉 학습된 지능이라고만 생각하지만 실제로는 모델 가중치와 스캐폴드(Scaffold, 시스템 프롬프트나 도구 설명), 그리고 하네스가 결합된 결과물이다. 쉽게 말하면 모델의 지능에 하네스의 제어 규칙과 스캐폴드의 지침이 더해져 최종적인 행동 양식이 결정되는 구조다. 비유하자면 숙련된 운동선수의 경기력은 타고난 신체 능력뿐만 아니라 팀의 전술판과 감독의 실시간 지시가 합쳐져 나타나는 것과 비슷하다. 모델을 교체하는 것보다 하네스의 제어 로직을 최적화하는 것이 제품의 사용자 경험을 결정짓는 더 빠르고 효율적인 변수가 되는 이유가 여기에 있다.

이러한 시스템 설계의 근간에는 강화학습(RL)의 파이프라인이 자리 잡고 있다. 에이전트의 작동 방식은 환경(Environment)에서 관찰한 정보를 바탕으로 행동(Act)을 취하고, 그 결과에 대해 보상(Reward)을 받는 루프의 반복이다. 모델이 텍스트를 생성하는 것에 그치지 않고 외부 API를 호출하거나 코드를 실행해 결과를 확인하고 다시 판단하는 과정이 바로 이 루프의 구현이다. 한국의 AI 실무자들은 단순히 더 큰 모델을 찾는 경쟁에서 벗어나 이 루프를 얼마나 정교하게 설계할 것인지 고민하는 하네스 엔지니어링에 집중해야 한다. 에러가 발생했을 때 어떻게 복구할지, 어떤 가드레일을 세워 모델의 이탈을 막을지 결정하는 하네스의 디테일이 곧 제품의 경쟁력이 된다.