에이전트 루프(Agent Loop)와 하네스(Harness): AI 운영에 대한 실무적 엔지니어링 관점

실제 환경에서 AI 에이전트(AI agents)를 구축, 평가, 보안 강화 및 운영하는 팀을 위한 친절한 엔지니어링 노트입니다.

서론
엔지니어들이 AI 에이전트에 대해 이야기할 때, 대화는 종종 모델(model)로 바로 건너뜁니다: GPT, Claude, Gemini, Llama, Qwen 또는 다른 파운데이션 모델(foundation model) 말입니다. 이는 이해할 수 있는 부분입니다. 모델은 시스템에서 가장 눈에 띄는 부분이기 때문입니다. 모델은 추론(reasoning)하고, 글을 쓰고, 요약하며, 도구(tools)를 호출하고, 우리가 보는 답변을 생성합니다. 하지만 프로덕션(production) 환경에서 모델은 운영의 한 부분일 뿐입니다. 실제 엔지니어링 작업은 모델 주변에서 이루어집니다. 그 주변 시스템을 흔히 에이전트 하네스(agent harness)라고 부릅니다. 하네스는 모델이 지침을 받는 방식, 컨텍스트(context)를 얻는 방식, 도구를 호출하는 방식, 오류를 처리하는 방식, 인간이 작업을 승인하는 방식, 로그(logs)가 캡처되는 방식, 그리고 작업이 완료된 후 에이전트가 평가되는 방식을 제어합니다. 이를 간단하게 설명하자면 다음과 같습니다: 모델은 추론(reasons)하고, 에이전트 루프(agent loop)는 결정하고 행동하며(decides and acts), 하네스는 운영을 제어 가능하고(controlled), 관찰 가능하며(observable), 안전하게(safe) 유지합니다. 이러한 구분은 중요합니다. 강력한 하네스 안에 있는 더 약한 모델은 여전히 유용한 작업을 수행할 수 있는데, 이는 하네스가 명확한 지침, 신뢰할 수 있는 도구, 반복 가능한 워크플로우(workflows), 피드백 및 안전한 경계(boundaries)를 제공하기 때문입니다. 반면, 부실한 하네스 안에 있는 강력한 모델은 잘못된 도구를 호출하거나, 상태(state)를 잃거나, 데이터를 노출하거나, 끝없이 루프를 돌거나, 적절한 승인 없이 행동할 수 있기 때문에 여전히 심각하게 실패할 수 있습니다. 이것이 바로 AI 운영(AI operations)이 실제 소프트웨어 엔지니어링(software engineering)이 되는 지점입니다.

에이전트 루프(Agent Loop)가 실제로 하는 일
에이전트 루프(agent loop)는 AI 에이전트가 작업을 완료하기 위해 따르는 반복적인 사이클입니다. 하나의 답변을 내놓고 멈추는 대신, 에이전트는 추론(reasoning), 행동(action), 관찰(observation), 수정(correction)의 시퀀스를 통해 작업을 수행합니다. 전형적인 루프는 다음과 같습니다:

1. 사용자의 목표를 수신합니다.
2. 현재 상태를 이해합니다.
3. 다음의 유용한 단계를 결정합니다.
4. 도구를 선택하거나 답변을 생성합니다.
5. 애플리케이션 또는 플랫폼을 통해 도구 호출을 실행합니다.
6. 결과를 관찰합니다.
7. 메모리(memory) 또는 작업 상태(task state)를 업데이트합니다.
8. 계속할지, 도움을 요청할지, 에스컬레이션(escalate)할지, 또는 중단할지를 결정합니다.

순수하게 엔지니어링 관점에서 말하자면, 에이전트 루프(agent loop)는 제어 루프(control loop)입니다. 이는 DevOps나 보안 운영(security operations)에서 자동화 시스템이 작동하는 방식과 유사합니다. 모니터링 규칙(monitoring rule)이 특정 상태를 감지하면, 자동화 플레이북(automation playbook)이 컨텍스트(context)를 확인하고, 시스템이 단계를 실행한 다음, 다음 단계로 넘어가기 전에 출력값을 평가합니다. 차이점은 AI 에이전트가 언어 모델(language model)을 사용하여 다음에 어떤 단계가 수행되어야 하는지 추론(reasoning)한다는 점입니다.

여기 간단한 예시가 있습니다. 개발자가 에이전트에게 다음과 같이 요청합니다: "실패하는 이 CI 빌드의 원인을 찾고 수정안을 제안해 주세요." 에이전트 루프는 다음과 같이 작동할 수 있습니다:

1. CI 에러 로그를 읽습니다.
2. 리포지토리(repository) 구조를 조사합니다.
3. 실패하는 테스트를 검색합니다.
4. 관련 소스 파일을 엽니다.
5. 테스트 기대값(test expectation)과 구현(implementation)을 비교합니다.
6. 패치(patch)를 제안합니다.
7. 테스트를 다시 실행합니다.
8. 테스트가 실패하면 새로운 에러를 조사합니다.
   수정 사항이 검증되거나 에이전트가 중단 조건(stopping condition)에 도달할 때까지 이 과정을 반복합니다.

이것이 바로 루프입니다. 중요한 세부 사항은 모델이 직접 "모든 것을 수행하는 것"이 아니라는 점입니다. 모델은 통제된 환경(controlled environment) 내에서 의사결정을 내리는 것입니다. 하네스(harness)는 파일 접근, 셸 실행(shell execution), 코드 검색, 테스트 실행, 티켓 조회(ticket lookup), 문서 검색(documentation retrieval), 배포 상태(deployment status) 또는 클라우드 텔레메트리(cloud telemetry)와 같은 도구들을 모델에게 제공합니다. 하네스가 없다면 모델은 대부분 똑똑한 텍스트 생성기에 불과합니다. 하지만 훌륭한 하네스가 있다면, 모델은 운영 워크플로(operational workflow)의 일부가 됩니다.

에이전트 하네스의 핵심 구성 요소
훌륭한 하네스는 단순히 API 호출을 감싸는 래퍼(wrapper)가 아닙니다. 그것은 하나의 엔지니어링 시스템입니다. 최소한 다음과 같은 계층(layers)을 포함해야 합니다.

1. 지시 계층 (Instruction Layer)
   이곳은 에이전트가 자신의 역할(role), 경계(boundaries), 작업 정의(task definition) 및 교전 규칙(rules of engagement)을 전달받는 곳입니다. 예를 들면 다음과 같습니다:

• 당신은 코드 리뷰 어시스턴트입니다.
• 프로덕션(production) 파일을 수정하지 마십시오.
• 수정안을 제안하기 전에 로그를 읽으십시오.
• 파괴적인 명령(destructive commands)을 실행하기 전에 승인을 요청하십시오.
• 승인된 내부 문서 소스만 사용하십시오.
• 근거와 함께 구조화된 출력(structured output)을 반환하십시오.
  지시 계층은 프로덕션 설정(production configuration)처럼 취급되어야 합니다.

이는 버전 관리(versioning), 검토(review), 테스트(testing) 및 변경 제어(change control)가 필요합니다. 조용한 프롬프트 변경은 코드 변경만큼이나 시스템 동작을 변화시킬 수 있습니다.

2. 컨텍스트 및 메모리 계층 (Context and Memory Layer)
   모델에는 컨텍스트(context)가 필요하지만, 컨텍스트는 반드시 제어되어야 합니다. 일반적으로 다음과 같은 다양한 유형의 메모리가 존재합니다:

• 단기 상태 (Short-term state): 현재 작업에서 일어나고 있는 일.
• 검색된 컨텍스트 (Retrieved context): 문서, 코드, 로그, 티켓, 경고 또는 지식 베이스(knowledge base) 항목.
• 장기 메모리 (Long-term memory): 지속적인 선호도, 이전 결정 또는 워크플로(workflow) 이력.

위험 요소는 컨텍스트 오염(context pollution)입니다. 잘못된 문서, 오래된 티켓, 악의적인 프롬프트 또는 관련 없는 로그 항목이 컨텍스트 윈도우(context window)에 들어오면, 에이전트는 확신에 차 있지만 잘못된 결정을 내릴 수 있습니다. 이것이 검색 품질(retrieval quality), 소스 순위 지정(source ranking), 메타데이터(metadata) 및 데이터 경계(data boundaries)가 중요한 이유입니다. 프로덕션 환경에서 검색은 단순한 편의 기능이 아닙니다. 그것은 제어 평면(control plane)의 일부입니다.

3. 도구 계층 (Tool Layer)
   도구는 에이전트가 행동할 수 있게 해주는 요소입니다. 도구는 계산기나 검색 기능처럼 단순할 수도 있습니다. 또는 다음과 같이 운영 측면에서 강력할 수도 있습니다:

• Jira 티켓 생성.
• SIEM 쿼리 실행.
• Kubernetes 명령 실행.
• CI/CD 워크플로 트리거.
• 클라우드 설정 읽기.
• 풀 리퀘스트(pull request) 오픈.
• 취약점 스캐너(vulnerability scanner) 쿼리.
• 침해 사고 대응(incident response) 워크플로 시작.

보안 관점에서 도구는 위험이 실체화되는 지점입니다. 모델이 답변을 환각(hallucination)하는 것은 하나의 문제입니다. 검증 없이 프로덕션에 영향을 미치는 도구를 호출하는 모델은 훨씬 더 큰 문제입니다. 강력한 하네스(harness)는 도구 스키마(tool schemas), 권한(permissions), 속도 제한(rate limits), 실행 경계(execution boundaries) 및 승인 요구 사항(approval requirements)을 정의해야 합니다.

4. 오케스트레이션 계층 (Orchestration Layer)
   이 계층은 워크플로를 제어합니다. 어떤 에이전트는 단순한 루프(loop)로 실행됩니다. 다른 에이전트는 그래프(graphs), 상태 머신(state machines), 이벤트 기반 흐름(event-driven flows) 또는 멀티 에이전트 협업(multi-agent collaboration)을 사용합니다. 오케스트레이션 계층은 다음에 무엇이 일어날지, 그리고 에이전트가 계속 진행할지, 분기할지, 일시 중지할지, 에스컬레이션(escalate)할지 또는 중단할지를 결정합니다.

이 지점에서 OpenAI Agents SDK, Anthropic의 MCP를 활용한 도구 사용 (tool use), Google ADK, LangGraph, Microsoft Agent Framework, LlamaIndex Workflows, CrewAI와 같은 프레임워크들이 유용해집니다. 이러한 프레임워크들은 다단계 (multi-step) 및 다중 에이전트 (multi-agent) 동작을 구조화하는 다양한 방법을 제공합니다. 엔지니어링 측면에서의 핵심은 특정 프레임워크가 항상 더 낫다는 것이 아닙니다. 핵심은 애플리케이션 팀에게 명시적인 오케스트레이션 모델 (orchestration model)이 필요하다는 점입니다. 그렇지 않으면 에이전트는 불분명한 상태 (state), 불분명한 소유권 (ownership), 그리고 불분명한 중단 조건 (stop conditions)을 가진 느슨한 루프 (loose loop)가 되어버립니다.

5. 가드레일 (Guardrails) 및 정책 계층 (Policy Layer)
   가드레일은 마법이 아닙니다. 그것은 엔지니어링 제어 장치 (engineering controls)입니다. 유용한 가드레일에는 다음이 포함됩니다:

• 입력 검증 (Input validation)
• 출력 검증 (Output validation)
• 도구 권한 확인 (Tool permission checks)
• 비밀 정보 삭제 (Secrets redaction)
• 프롬프트 인젝션 탐지 (Prompt injection detection)
• 인간 승인 게이트 (Human approval gates)
• 환경 분리 (Environment separation)
• 정책 기반 동작 차단 (Policy-based action blocking)
• 구조화된 출력 강제 (Structured output enforcement)
• 최대 루프 제한 (Maximum loop limits)
• 비용 및 토큰 제한 (Cost and token limits)

DevSecOps 팀의 경우, 이 계층은 애플리케이션 보안 제어 설계와 같이 취급되어야 합니다. 핵심 질문은 다음과 같습니다: 에이전트가 무엇을 읽을 수 있는가? 에이전트가 무엇을 변경할 수 있는가? 어떤 동작에 승인이 필요한가? 에이전트가 행동한 후 어떤 증거가 캡처되는가? 도구 호출 (tool call)이 실패하면 어떻게 되는가? 롤백 경로 (rollback path)는 무엇인가?

6. 관측 가능성 계층 (Observability Layer)
   에이전트 루프를 추적 (trace)할 수 없다면, 이를 안전하게 운영할 수 없습니다. 에이전트 관측 가능성 (observability)은 다음을 캡처해야 합니다:

• 사용자 요청 (User request)
• 시스템 지침 버전 (System instruction version)
• 검색된 컨텍스트 (Retrieved context)
• 도구 호출 (Tool calls)
• 도구 응답 (Tool responses)
• 모델 응답 (Model responses)
• 오류 및 재시도 (Errors and retries)
• 인간 승인 (Human approvals)
• 최종 출력 (Final output)
• 비용, 지연 시간 (latency) 및 토큰 사용량 (token usage)
• 보안 관련 이벤트 (Security-relevant events)

이는 단순히 디버깅만을 위한 것이 아닙니다. 감사 가능성 (auditability), 사고 대응 (incident response), 컴플라이언스 (compliance), 그리고 모델 개선을 위해서도 필요합니다. 추적 기능이 없는 프로덕션 에이전트는 신뢰하기 어렵습니다. 에이전트가 어떤 답변을 생성했는지는 알 수 있어도, 무엇을 읽었는지, 무엇을 무시했는지, 어떤 도구를 사용했는지, 또는 왜 그런 결정을 내렸는지는 알 수 없을 수도 있습니다.

왜 하네스 (Harness) 엔지니어링이 많은 팀이 깨닫는 것보다 더 중요한가
모델은 똑똑할 수 있지만, 운영 측면에서는 실패할 수 있습니다.

예를 들어: Kubernetes 문제를 이해할 수는 있지만 잘못된 네임스페이스 (namespace)를 호출할 수 있습니다. IAM 문제를 정확하게 설명할 수는 있지만 현재 역할 (role)이 해당 리소스를 조사할 수 없다는 점을 놓칠 수 있습니다. 좋은 코드 패치 (code patch)를 생성할 수는 있지만 올바른 테스트를 실행하는 데 실패할 수 있습니다. 보안 경고를 요약할 수는 있지만 소스 로그가 오래되었다는 점을 간과할 수 있습니다. 위험한 설정을 식별할 수는 있지만 운영 트래픽을 중단시키는 해결책을 제안할 수도 있습니다. 이것들은 단지 모델의 문제만이 아닙니다. 이것들은 하네스 (harness)의 문제입니다. 훌륭한 하네스 엔지니어링은 다음을 개선합니다: 불필요한 모델 호출을 제한하고, 반복적인 작업을 피하며, 결정론적 작업 (deterministic tasks)을 결정론적 도구로 라우팅하고, 비용을 제어함으로써 연산 (Computation)을 개선합니다. 에이전트에게 코드, 테스트, 문서, 이슈 컨텍스트 (issue context), 그리고 리뷰 워크플로우 (review workflows)에 대한 안전한 접근 권한을 부여함으로써 개발 (Development)을 개선합니다. 권한을 제어하고, 도구 호출 (tool calls)을 검증하며, 승인 절차를 강제하고, 폭발 반경 (blast radius)을 줄임으로써 보안 (Security)을 개선합니다. 에이전트를 CI/CD, 관측성 (observability), 장애 대응 워크플로우 (incident workflows), 그리고 변경 관리 (change management)에 통합함으로써 DevOps를 개선합니다. 다시 말해, 하네스의 품질은 AI 에이전트가 유용한 엔지니어링 어시스턴트처럼 동작할지, 아니면 언어 모델이 부착된 예측 불가능한 자동화 스크립트처럼 동작할지를 결정합니다.

일반적인 에이전트 하네스의 명확한 관점과 적용 위치
시장은 빠르게 움직이고 있지만, 안정적인 엔지니어링 원칙은 다음과 같습니다: 하네스는 대개 모델에 의해서만 결정되는 것이 아니라 애플리케이션 팀에 의해 선택됩니다. 아래는 일반적인 옵션들에 대한 실무적인 관점입니다.

OpenAI: Responses API 및 Agents SDK
OpenAI의 현재 에이전트 스택은 Responses API와 Agents SDK를 중심으로 구성되어 있습니다. 이 플랫폼은 웹 검색 (web search), 파일 검색 (file search), 컴퓨터 사용 (computer use), 코드 실행 (code execution), MCP/커넥터 (connectors), 그리고 기타 도구 패턴과 같은 호스팅된 도구 및 도구 통합을 지원합니다. Agents SDK는 에이전트 정의, 도구, 핸드오프 (handoffs), 가드레일 (guardrails), 상태 (state), 트레이싱 (tracing), 그리고 평가 (evaluation) 지원과 같은 애플리케이션 수준의 빌딩 블록을 추가합니다.

이 스택은 도구 사용 (tool use), 구조화된 출력 (structured output), 트레이싱 (tracing), 그리고 다단계 워크플로 (multi-step workflows)가 필요한 OpenAI 모델 기반 애플리케이션을 구축하는 팀에게 강력한 도구입니다. 또한, 모든 루프 (loop)를 수동으로 구축하지 않고 모델 호출 (model calls)에서 에이전트 운영 (agent operations)으로 이어지는 직접적인 경로를 원하는 팀에게도 유용합니다. 가장 적합한 사례: 제품 엔지니어링 (Product engineering). 내부 어시스턴트 (Internal assistants). 도구 사용 애플리케이션 (Tool-using applications). 멀티 에이전트 핸드오프 (Multi-agent handoffs). 트레이싱 (tracing)을 포함한 제어된 자동화 (Controlled automation). 인간의 검토 또는 재개 가능한 상태 (resumable state)가 필요한 워크플로 (workflows). 엔지니어링 노트 (Engineering note): 이는 관리형 모델 플랫폼과 더불어 에이전트 패턴 (agent patterns), 관측성 (observability), 그리고 평가 (evaluation)를 위한 SDK 수준의 지원을 원할 때 강력한 옵션입니다.

Anthropic: Claude Tool Use, Claude Code, 그리고 MCP
Anthropic의 Claude 생태계는 도구 사용 (tool use)과 모델 컨텍스트 프로토콜 (Model Context Protocol, MCP)을 지원합니다. 일반적인 도구 사용 흐름에서, Claude는 사용자 요청과 도구 설명 (tool descriptions)을 기반으로 도구를 호출할 시점을 결정한 다음, 구조화된 도구 호출 (structured tool call)을 반환합니다. 애플리케이션 또는 플랫폼은 해당 호출을 실행하고 그 결과를 Claude에 반환하여 다음 추론 단계 (reasoning step)를 진행합니다. MCP는 AI 애플리케이션을 외부 시스템에 연결하기 위한 개방형 프로토콜 (open protocol)입니다. MCP 서버는 호환 가능한 클라이언트 (clients)에 도구 (tools), 리소스 (resources), 그리고 프롬프트 (prompts)를 노출할 수 있습니다. 이를 통해 MCP는 에이전트를 파일, 리포지토리 (repositories), 문서 (documentation), 이슈 트래커 (issue trackers), 데이터베이스 (databases), 그리고 내부 시스템에 연결하는 데 유용합니다. 가장 적합한 사례: 소프트웨어 엔지니어링 어시스턴트 (Software engineering assistants). 코드베이스 탐색 (Codebase navigation). 내부 도구 통합 (Internal tool integration). MCP 기반의 엔터프라이즈 연결성 (enterprise connectivity). 인간이 감독하는 개발 워크플로 (Human-supervised development workflows). 보안 노트 (Security note): MCP는 도구 접근 (tool access)을 표준화하기 때문에 강력합니다. 이는 또한 권한 (permissions), 서버 신뢰도 (server trust), 입력 검증 (input validation), 명령 실행 경계 (command execution boundaries), 그리고 프롬프트 인젝션 방어 (prompt injection defense)를 매우 중요하게 만듭니다.

Google: Agent Development Kit 및 Gemini Enterprise Agent Platform
Google의 에이전트 개발 키트 (Agent Development Kit, ADK)는 에이전트를 구축, 디버깅 및 배포하기 위한 오픈 소스 프레임워크입니다. 이는 에이전트 및 도구 추상화 (abstractions)를 지원하며, 멀티 에이전트 워크플로 (multi-agent workflows)로 확장되도록 설계되었습니다.

이 스택은 이미 Google Cloud 또는 Gemini 기반 애플리케이션 패턴을 사용 중인 팀, 특히 배포(deployment), 엔터프라이즈 통합(enterprise integration), 그리고 멀티 에이전트 동작(multi-agent behavior)이 중요한 팀에게 실질적으로 적합합니다. 최적의 활용 사례: Google Cloud 환경, Gemini 기반 애플리케이션, 엔터프라이즈 에이전트 워크플로(enterprise agent workflows), 멀티 에이전트 시스템(multi-agent systems), 클라우드 배포 경로를 갖춘 오픈 소스 프레임워크를 원하는 팀. 엔지니어링 노트: ADK는 팀이 임시방편적인 프롬프트 및 도구 코드(ad hoc prompt-and-tool code) 대신 구조화된 에이전트 개발 모델을 원할 때 유용합니다. LangGraph: 내구성이 있고 상태를 유지하는 에이전트 워크플로 (Durable, Stateful Agent Workflows) LangGraph는 명시적인 워크플로 제어, 상태(state), 그래프 기반 라우팅(graph-based routing), 인간 참여형 검토(human-in-the-loop review), 그리고 내구성이 있는 실행(durable execution)이 필요할 때 유용합니다. 이는 경로가 단순한 선형 체인(linear chain)이 아닌, 장기 실행되거나 복잡한 워크플로에 흔히 사용됩니다. 최적의 활용 사례: 상태 유지 에이전트 워크플로(stateful agent workflows), 장기 실행 작업(long-running tasks), 인간 참여형 운영(human-in-the-loop operations), 다단계 결정 그래프(multi-step decision graphs), 지속성(persistence)과 재