AI 에이전트에서 모델을 감싸는 모든 것, 하네스 엔지니어링의 정의와 등장 배경, 그리고 5가지 핵심 역할을 살펴봅니다.
2025년은 AI 에이전트가 '작동할 수 있다'는 것을 증명한 해였습니다. 코드를 작성하고, 문서를 분석하며, 복잡한 워크플로우를 자동화하는 에이전트들이 속속 등장했습니다. 그런데 흥미로운 현상이 하나 있었습니다. 동일한 모델을 사용하는 두 팀이 작업 완료율에서 40점 이상의 차이를 보인 것입니다. 모델이 같은데 왜 이런 격차가 발생할까요? 답은 모델 바깥에 있었습니다.
하네스 엔지니어링(Harness Engineering)이란 AI 에이전트에서 모델 자체를 제외한 모든 것을 설계하고 구축하는 기술 분야입니다. 모델이 두뇌라면, 하네스는 그 두뇌가 실제 세계에서 작동할 수 있도록 감싸는 모든 구조물입니다.
Agent = Model + Harness
이 공식은 단순해 보이지만, 실제로 프로덕션 수준의 AI 시스템을 구축해 본 엔지니어라면 하네스가 전체 코드베이스의 80% 이상을 차지한다는 사실을 알고 있습니다. 모델 API를 호출하는 코드는 몇 줄에 불과하지만, 그 호출을 안전하고 효율적으로 만드는 코드는 수천 줄에 달합니다.
구체적으로 하네스에는 다음과 같은 요소들이 포함됩니다.
2025년까지의 AI 개발은 '더 큰 모델, 더 나은 성능'이라는 단순한 공식을 따랐습니다. 하지만 2026년에 들어서며 패러다임이 전환되었습니다.
주요 파운데이션 모델(Foundation Model)들의 벤치마크 점수가 수렴하기 시작했습니다. GPT, Claude, Gemini 간의 원시 성능 차이는 줄어들고 있습니다. 이제 경쟁력은 모델 자체가 아니라, 모델을 얼마나 잘 활용하느냐에서 결정됩니다.
실험 단계를 넘어 실제 비즈니스에 에이전트를 배포하는 조직이 급증했습니다. 프로덕션 환경은 실험실과 다릅니다. 안정성, 관측 가능성, 보안, 비용 효율성 모두가 중요합니다. 이 모든 것이 하네스의 영역입니다.
Martin Fowler는 소프트웨어 아키텍처 관점에서 AI 시스템의 하네스 패턴을 분석하기 시작했고, Anthropic은 CLAUDE.md와 AGENTS.md 같은 하네스 설정 파일 표준을 제안했습니다. LangChain과 OpenAI 역시 하네스 계층의 중요성을 강조하는 기술 문서를 발표하고 있습니다.
하네스 엔지니어링은 크게 5가지 역할로 구분할 수 있습니다. 이 시리즈에서는 각 역할을 깊이 있게 다룰 예정입니다.
AI 시스템의 출력은 비결정적(non-deterministic)입니다. 같은 입력에도 매번 다른 출력이 나올 수 있습니다. 전통적인 단위 테스트의 assertEqual으로는 이런 시스템을 검증할 수 없습니다. 테스트 하네스는 속성 기반 테스트, 시맨틱 유사도 비교, 회귀 테스트 등의 기법으로 AI 시스템의 품질을 보증합니다.
모델의 성능을 체계적으로 측정하는 파이프라인입니다. lm-evaluation-harness, Inspect AI, HELM 같은 프레임워크가 이 영역에 해당합니다. 새 모델 버전이 나왔을 때, 기존 모델 대비 어떤 점이 개선되고 어떤 점이 퇴보했는지를 정량적으로 파악할 수 있게 해줍니다.
복잡한 에이전트 워크플로우를 조율합니다. 도구 호출 순서 관리, 서브에이전트 간의 통신, 상태 전이, 에러 발생 시의 복구 전략 등을 담당합니다. 단순한 챗봇에서는 필요 없지만, 멀티스텝 에이전트에서는 핵심적인 역할을 합니다.
AI 시스템의 안전 장치입니다. 입력 단계에서 프롬프트 인젝션을 감지하고, 출력 단계에서 유해 콘텐츠를 필터링하며, 실행 단계에서 위험한 동작을 차단합니다. 프로덕션 AI 시스템에서 가장 중요하면서도 가장 간과되기 쉬운 영역입니다.
프로덕션에서 AI 시스템의 상태를 관측합니다. 토큰 사용량, 지연시간, 비용, 품질 메트릭을 실시간으로 추적하고, 이상 징후를 감지하면 알림을 발생시킵니다. 또한 사용자 피드백을 수집하여 시스템 개선에 반영하는 피드백 루프를 구성합니다.
하네스라는 개념 자체는 새로운 것이 아닙니다. 소프트웨어 테스트에서 테스트 하네스(Test Harness)는 오래전부터 사용되어 왔습니다. 하지만 AI 시스템의 하네스는 전통적인 하네스와 근본적으로 다른 도전을 안고 있습니다.
| 측면 | 전통 소프트웨어 | AI 시스템 |
|---|---|---|
| 출력 예측 | 결정적 (동일 입력 = 동일 출력) | 비결정적 (확률적 출력) |
| 테스트 전략 | 정확한 값 비교 | 속성/범위 기반 검증 |
| 에러 유형 | 크래시, 예외 | 환각, 편향, 품질 저하 |
| 배포 롤백 | 코드 버전 롤백 | 모델 + 프롬프트 + 설정 롤백 |
| 모니터링 | CPU, 메모리, 응답시간 | 토큰, 비용, 품질 메트릭 |
| 버전 관리 | 코드만 관리 | 코드 + 모델 + 프롬프트 + 데이터 |
전통 소프트웨어에서 add(2, 3)은 항상 5를 반환합니다. 하지만 AI 모델에게 "2와 3을 더하면?"이라고 물으면 "5입니다", "결과는 5예요", "2 + 3 = 5" 등 다양한 형태의 답변이 나올 수 있습니다. 이 비결정성은 테스트, 평가, 모니터링 등 하네스의 모든 영역에 근본적인 영향을 미칩니다.
# 전통 소프트웨어 테스트
def test_addition():
assert add(2, 3) == 5 # 결정적: 항상 통과# AI 시스템 테스트: 속성 기반 검증
def test_math_response():
response = llm.generate("2와 3을 더하면?")
# 정확한 문자열 비교가 아닌 속성 검증
assert "5" in response.text
assert response.confidence > 0.9
assert response.latency_ms < 3000하네스 엔지니어링은 AI 모델의 비결정적 특성을 인정하면서도, 시스템 전체의 동작을 예측 가능하고 신뢰할 수 있게 만드는 것이 핵심 목표입니다.
하네스 엔지니어링의 부상은 새로운 역할의 등장을 의미하기도 합니다. 하네스 엔지니어(Harness Engineer)는 ML 엔지니어와 소프트웨어 엔지니어의 교차점에 위치합니다.
하네스 엔지니어링은 별도의 직군이라기보다, 모든 AI 시스템 개발자가 갖추어야 할 핵심 역량에 가깝습니다. 모델 API를 호출하는 것만으로는 프로덕션 수준의 AI 시스템을 만들 수 없습니다.
2장에서는 하네스를 실제로 어떻게 설계하는지, 구체적인 아키텍처 패턴들을 살펴봅니다. 래핑 패턴, 미들웨어 패턴, 사이드카 패턴, 파이프라인 패턴, 이벤트 기반 패턴 등 실전에서 활용되는 5가지 설계 패턴과 각각의 적용 시나리오를 다룹니다.
이 글이 도움이 되셨나요?
관련 주제 더 보기
래핑, 미들웨어, 사이드카, 파이프라인, 이벤트 기반 등 AI 시스템 하네스의 5가지 핵심 아키텍처 패턴과 적용 시나리오를 분석합니다.
모델 추상화 계층 설계, 프롬프트 구성과 컨텍스트 주입, 스키마 기반 출력 제어, 폴백 전략 등 AI 모델의 입출력을 체계적으로 관리하는 방법을 다룹니다.
비결정적 출력 테스트, 스냅샷 테스트, 속성 기반 테스트, 회귀 테스트, 에이전트 행동 테스트 등 AI 시스템 테스트의 핵심 기법을 다룹니다.