하네스 엔지니어링 (Harness Engineering): AI 에이전트를 작동하게 만드는 화려하지 않은 작업

요약(TLDR): 모두가 어떤 AI 모델을 사용할지에 집착합니다. 하지만 실제 운영되는 에이전트 시스템(production agent systems)에서 병목 현상(bottleneck)은 모델인 경우가 드뭅니다. 진짜 병목은 모델을 둘러싼 스캐폴딩(scaffolding, 구조물)입니다. 하네스 엔지니어링(Harness engineering)은 실행 오케스트레이션(execution orchestration), 평가(evaluation), 관측 가능성(observability), 안전 가드레일(safety guardrails), 그리고 메모리(memory)와 같은 스캐폴딩을 구축하는 규율입니다. 이는 화려하지 않고 과소평가되어 있지만, 진정한 차별화가 발생하는 지점입니다. 이를 사후 고려 사항으로 취급하는 팀은 데모(demo)를 출시하지만, 이를 진지하게 받아들이는 팀은 제품(product)을 출시합니다.

모두가 모델에 대해 이야기합니다. GPT-4 대 Gemini 대 Claude. 벤치마크 점수. 컨텍스트 윈도우(Context windows). 추론 능력(Reasoning capabilities). 이것은 헤드라인을 장식하는 AI의 부분입니다. 하지만 단순히 질문에 답하는 것이 아니라, 행동을 취하고, 결정을 내리며, 여러 단계에 걸쳐 작동하는 시스템인 AI 에이전트를 구축하는 데 실제로 시간을 보냈다면, 모델이 병목 현상인 경우는 거의 없다는 것을 알게 될 것입니다. 병목은 모델 주변의 모든 것입니다. 그 "모델 주변의 모든 것"에는 이름이 있습니다: 하네스 엔지니어링 (harness engineering).

하네스(Harness)란 무엇인가? 전통적인 소프트웨어에서 테스트 하네스(test harness)는 코드 조각을 실행하고, 관찰하며, 올바르게 작동하는지 검증하기 위해 그 주변에 구축하는 스캐폴딩(scaffolding)입니다. 사용지에게 하네스를 배포하지는 않습니다. 하네스는 당신이 실제로 관심을 두는 대상을 제어, 관찰 및 평가하기 위해 존재합니다. AI 에이전트를 위한 하네스 엔지니어링은 이 개념을 에이전트 시스템의 전체 생명주기(lifecycle)로 확장합니다. 이는 에이전트를 감싸고, 제어하고, 모니터링하며, 제약하는 인프라(infrastructure)로, 모델 가중치(model weights) 자체를 제외한 모든 것을 의미합니다. 모델이 엔진이라면, 하네스는 샤시(chassis), 대시보드(dashboard), 안전벨트(seatbelts), 그리고 정비사의 진단 도구(diagnostic tools)를 한꺼번에 모아놓은 것과 같습니다.

하네스 엔지니어링의 5가지 계층

1. 실행 하네스 (Execution Harnesses)
   이것은 오케스트레이션 계층(orchestration layer)입니다. 즉, 에이전트가 세상에서 어떻게 행동을 취하는지를 관리하는 스캐폴딩입니다. 에이전트가 도구(tool)를 호출하기로 결정하면, 무언가가 해당 호출을 올바른 함수로 라우팅(route)하고, 에러를 우아하게 처리하며, 재시도(retries)를 관리하고, 타임아웃(timeouts)을 강제하며, 결과를 에이전트의 컨텍스트(context)로 다시 전달해야 합니다.

여러 에이전트가 협업해야 할 때는 무언가가 핸드오프(handoffs, 인계)를 조정해야 합니다. LangGraph, CrewAI와 같은 프레임워크나 커스텀 오케스트레이터(orchestrators)가 모두 이 계층에 속합니다. 여기서 내리는 결정들 — 상태(state)를 어떻게 모델링할지, 실패를 어떻게 처리할지, 단계를 어떻게 시퀀싱(sequencing)할지 — 은 에이전트가 신뢰할 수 있는지 아니면 혼란스러운지에 엄청난 영향을 미칩니다.

2. 평가 하네스 (Evaluation Harnesses)
   여러분의 에이전트가 정말 성능이 좋은지 어떻게 알 수 있을까요? 평가 하네스(Evaluation harnesses)는 정의된 일련의 작업들을 에이전트에게 실행하게 하고, 그 결과물을 정답(ground truth), 인간의 평가 기준(human rubrics), 또는 또 다른 AI 판사(AI judge)와 비교하여 점수를 매깁니다. LangSmith나 Braintrust 같은 도구들은 이를 위해 특화되어 제작되었습니다. 탄탄한 평가 하네스(eval harness)가 없다면, 프롬프트(prompt)를 변경하거나, 모델을 교체하거나, 새로운 도구(tool)를 추가할 때마다 눈을 가리고 비행하는 것과 같습니다. 이 계층은 종종 가장 소홀히 다뤄지며, 팀들이 건너뛰었다가 가장 먼저 후회하게 되는 부분이기도 합니다.

3. 관측성 하네스 (Observability Harnesses)
   에이전트는 미묘한 방식으로 실패합니다. 모델이 올바른 도구(tool)를 호출하면서 잘못된 파라미터(parameter)를 사용할 수도 있습니다. 다단계 추론 체인(multi-step reasoning chain)이 세 번째 단계에서 빗나갈 수도 있습니다. 관측성(observability)이 없다면, 여러분은 추측에 의존하여 디버깅을 해야 합니다. 관측성 하네스(Observability harnesses)는 에이전트가 수행하는 모든 작업의 상세한 트레이스(traces)를 캡처합니다: 어떤 도구를 어떤 순서로 호출했는지, 어떤 입력값(inputs)을 사용했는지, 그리고 어떤 결과가 돌아왔는지 등을 기록합니다. 여기서 OpenTelemetry, LangSmith 트레이스, 그리고 PostHog와 같은 제품 분석(product analytics) 도구들이 통합되어, 실제 사용 환경에서의 에이전트 동작을 들여다볼 수 있는 창을 제공합니다.

4. 안전 및 제약 하네스 (Safety and Constraint Harnesses)
   데이터베이스에 기록하거나, 이메일을 보내거나, API 호출을 하는 등 실제 세계에서 행동을 취하는 에이전트에게는 가드레일(guardrails)이 필요합니다. 안전 하네스(Safety harnesses)는 작업이 실행되기 전에 이를 가로채서 허용된 작업인지 확인합니다. 이는 승인된 도구 호출의 허용 목록(allowlist) 정도로 간단할 수도 있고, 고위험 작업에 대해 인간 참여형(human-in-the-loop) 승인 대기열을 두는 것처럼 정교할 수도 있습니다. 예산 제한(budget limits), 속도 제한(rate limiting), 정책 집행(policy enforcement) 또한 모두 이 계층에 해당합니다. 에이전트의 능력이 향상됨에 따라, 이 계층은 선택 사항이 아닌 필수 사항이 되어갑니다.

5. 메모리 하네스 (Memory Harnesses)
   기본적으로 언어 모델(language models)은 지속적인 메모리(persistent memory)를 가지고 있지 않습니다.

모든 대화는 새롭게 시작됩니다. 메모리 하네스(Memory harnesses)는 에이전트가 여러 턴(turns), 여러 세션(sessions), 그리고 더 큰 시스템의 서로 다른 부분에 걸쳐 어떤 컨텍스트(context)에 접근할 수 있는지를 관리함으로써 이 문제를 해결합니다. 여기에는 의미론적 검색(semantic retrieval)을 위한 벡터 저장소(vector stores), 과거의 상호작용을 저장하기 위한 에피소드 메모리(episodic memory), 그리고 작업 중 관련 상태를 컨텍스트 내에 유지하기 위한 워킹 메모리 버퍼(working memory buffers)가 포함됩니다. 이 계층을 얼마나 잘 설계하느냐에 따라 당신의 에이전트가 일관성 있고 인지 능력이 있는 것처럼 느껴질지, 아니면 기억상실증에 걸린 듯 혼란스러워 보일지가 결정됩니다.

훌륭한 하네스 엔지니어링(Harness Engineering)의 실제 모습

다섯 가지 계층을 아는 것과, 사려 깊게 설계된 하네스와 임시방편으로 급하게 만들어진(duct-taped) 하네스를 구분하는 법을 아는 것은 별개의 문제입니다. 다음은 실제 운영 환경(production)에서 견고하게 작동하는 시스템에서 나타나는 몇 가지 패턴입니다:

• 멱등적 도구 호출 (Idempotent tool calls): 에이전트가 실패한 작업을 재시도할 때, 실수로 동일한 이메일을 두 번 보내거나 동일한 데이터베이스 행을 두 번 작성하게 해서는 안 됩니다. 우수한 실행 하네스는 도구 호출을 기본적으로 멱등적(idempotent) 연산으로 취급하여, 부작용(side effects) 없이 안전하게 재시도할 수 있도록 합니다.
• 구조화된 실패 모드 (Structured failure modes): 취약한 하네스는 실패가 조용히 전파되도록 방치합니다. 강력한 하네스는 도구 타임아웃(timeout), 잘못된 형식의 출력(malformed output), 안전 규정 위반(safety violation) 등 모든 계층에서 '실패'가 무엇을 의미하는지 정의하고, 오류를 넘어 환각(hallucination)을 일으키거나 시스템이 충돌하는 대신 각 오류를 적절한 핸들러(handler)로 라우팅합니다.
• 평가 주도 개발 (Eval-driven development): 최고의 팀들은 소프트웨어 팀이 테스트를 다루는 것과 동일한 방식으로 평가(evals)를 다룹니다. 즉, 제품을 출시하기 전에 평가를 작성하고, 모든 변경 사항에 대해 실행하며, 회귀(regression)가 발생하면 배포를 차단합니다. 프롬프트 수정으로 인한 미세한 능력 저하(silent capability regression)를 처음 잡아내기 전까지는 이 과정이 느리게 느껴질 수 있습니다.
• 최소한의 메모리 점유 (Minimal memory footprint): 더 많은 컨텍스트가 항상 더 좋은 것은 아닙니다. 에이전트의 메모리를 과도하게 채우면 속도가 느려지고 비용이 많이 들며, 역설적으로 정확도는 떨어집니다. 모델은 긴 컨텍스트(long contexts) 내에서 집중력을 잃을 수 있기 때문입니다. 훌륭한 메모리 하네스는 무한정 내용을 추가하는 대신, 선택적으로 압축하고 요약합니다.

팀들이 가장 자주 범하는 실수

대부분의 하네스 엔지니어링 (harness engineering) 실수는 잘못된 도구를 선택하는 문제가 아니라, 하네스를 사후 고려 사항 (afterthought)으로 취급하는 데서 발생합니다.

에이전트를 먼저 구축한 뒤 하네스를 만드는 것: 에이전트를 먼저 작동하게 만든 다음 "관측성 (observability)은 나중에 추가하자"라고 유혹하기 쉽습니다. 하지만 프로덕션 환경의 장애를 디버깅해야 할 시점이 되면, 그 '나중'이라는 시간은 이미 큰 대가를 치르게 만듭니다. 관측성 (observability) 및 평가 (eval) 인프라는 첫날부터 구축하는 것이 나중에 소급 적용 (retrofit)하는 것보다 훨씬 쉽습니다.

실행 계층 (execution layer)과 안전 계층 (safety layer)을 혼동하는 것: 이들은 별개의 관심사입니다. 실행 로직 (execution logic)은 에이전트가 어떻게 행동할지를 결정합니다. 안전 로직 (safety logic)은 에이전트가 행동해야 하는지 여부를 결정합니다. 이 둘을 동일한 코드 내에 섞어버리면 두 가지 모두 추론 (reasoning)과 감사 (audit)를 어렵게 만듭니다.

메모리를 로그 (log)로 취급하는 것: 모든 상호작용을 메모리 저장소에 추가하는 것은 메모리 엔지니어링이 아닙니다. 그것은 단지 추가적인 단계가 붙은 로깅 (logging)일 뿐입니다. 진정한 메모리 하네스 (memory harness)는 현재 작업에 따라 무엇을 유지하고, 무엇을 압축하며, 무엇을 잊고, 무엇을 표면화할지에 대한 결정을 포함합니다.

중요도가 높은 작업에서 인간 참여 (human-in-the-loop)를 생략하는 것: 초기 단계의 팀들은 속도를 내기 위해 승인 게이트 (approval gates)를 생략하는 경우가 많습니다. 낮은 위험도의 도구라면 이는 합리적인 트레이드오프 (tradeoff)입니다. 하지만 금융 시스템을 다루거나, 외부 통신을 보내거나, 공유 상태 (shared state)를 수정하는 에이전트는 체크포인트 (checkpoints)가 필요합니다. 이는 영구적인 설계로서가 아니라, 시스템이 자율성 (autonomy)을 얻을 때까지 신뢰를 구축하기 위한 메커니즘으로서 필요합니다.

왜 이곳이 진짜 작업이 일어나는 곳인가

현대 AI 개발에 대한 솔직한 진실은 다음과 같습니다: 모델은 점점 더 범용화된 상품 (commodity)이 되고 있습니다. 주요 프런티어 모델 (frontier models)들은 대부분의 유스케이스 (use case)에서 성능 차이가 크지 않기 때문에, 특정 모델을 다른 모델보다 선택하는 것이 제품의 성패를 결정하는 경우는 드뭅니다.

차별화는 바로 하네스 (harness)에서 일어납니다. 잘 설계된 하네스는 제대로 구축되지 않은 시스템에서 더 약한 모델이 더 강력한 모델보다 더 나은 성능을 내도록 만들 수 있습니다. 하네스는 문제가 발생했을 때 에이전트가 디버깅 가능한지, 실제 행동을 맡길 수 있을 만큼 충분히 안전한지, 대규모로 실행할 수 있을 만큼 비용 효율적인지, 그리고 사용자가 다시 돌아올 만큼 충분히 신뢰할 수 있는지를 결정합니다. 또한 솔직히 말해서, 프롬프트 (prompt)보다 복제하기가 훨씬 더 어렵습니다.

누구나 최신 모델로 교체할 수는 있습니다. 하지만 충돌 탐지 (conflict detection), 결정 이력 추적 (decision history traversal), 메모리 아키텍처 (memory architecture), 그리고 평가 인프라 (evaluation infrastructure)에 걸쳐 수년간 쌓아온 세심한 작업들을 재구축하는 것은 완전히 다른 차원의 문제입니다. 주목할 만한 변화: 오랫동안 AI 분야는 모델의 능력 (model capability)에 집착해 왔습니다. 그 경쟁은 계속되고 있습니다. 하지만 에이전트 (agent)가 데모를 넘어 실제 서비스 (production) 단계로 넘어가면서, 대화의 중심은 다른 질문들로 옮겨가고 있습니다. 에이전트가 틀렸을 때 어떻게 알 수 있는가? 에이전트가 해서는 안 될 행동을 하는 것을 어떻게 방지할 것인가? 15번의 도구 호출 (tool calls) 과정에서 발생한 실패를 어떻게 디버깅할 것인가? 에이전트에게 모든 것을 다 주지 않으면서 어떻게 메모리 (memory)를 부여할 것인가? 이것들이 바로 하네스 엔지니어링 (harness engineering)의 질문들입니다. 그리고 이 질문들에 대해 진지한 해답을 만들어가는 팀들 — 가장 화려한 데모를 보여주는 팀이 아니라, 가장 사려 깊은 인프라를 갖춘 팀들 — 이 실제로 지속 가능한 것들을 만들어내고 있습니다. 모델이 공로를 인정받지만, 실제 작업은 하네스 (harness)가 수행합니다. 연결 및 공유: 저는 Faham입니다. 현재 University at Buffalo에서 석사 과정을 밟으며 AI/ML 분야를 깊이 연구하고 있습니다. 저는 실제 AI 앱을 구축하며 배우는 것들을 공유합니다. 이 글이 도움이 되었거나 궁금한 점이 있다면, LinkedIn과 X (구 Twitter)에서 연결해 주세요. AI 공개: 이 블로그 포스트는 연구, 콘텐츠 구조화 및 이미지 생성을 위해 AI 도구의 도움을 받아 Faham이 작성했습니다. 모든 기술적 콘텐츠는 정확성을 위해 검토 및 검증되었습니다.