AI Agent (Harness)
LLM_Agent 2026. 6. 19. 11:51

AI Agent (Harness)

@Beemo9
목차

Agent, Harness, 코딩 에이전트 등등 현재는 용어가 너무 혼재되어 있습니다.
본 문서는 Claude Code와 같은 코딩 에이전트를 Harness라고 지칭합니다.

Concept

AI가 발전하면서 Agent라는 키워드가 부수적으로 화두에 오르고 있습니다.

Anthropic에서도 이러한 Agent에 대해서 명확한 정의를 내놓지는 않고 있습니다.


다만, 워크플로우랑 에이전트의 구분을 아래와 같이 정의하고 있습니다.

  • 워크플로는 LLM과 도구가 미리 정의된 코드 경로를 통해 조율되는 시스템입니다.
  • 반면 에이전트는 LLM이 자체 프로세스와 도구 사용을 동적으로 지시하고 작업을 수행하는 방식을 제어하는 시스템입니다.

최근 시장에서는 어떠한 작업에 LLM이라는 요소만 있으면 에이전트라고 부르는것 같습니다.

※이렇게까지 명확한 정의가 없는 기술들이 우후죽순으로 나오는것은 AI 기술의 성장 속도가 너무 빨라서 제대로 된 용어 정립할 시간이 없나봅니다.

 

AI Agent에 대한 추가적인 정보는 아래 huggingface 아티클을 참고해주시면 됩니다. (5.25 발행)

https://huggingface.co/blog/agent-glossary

 

Harness, Scaffold, and the AI Agent Terms Worth Getting Right

We’re on a journey to advance and democratize artificial intelligence through open source and open science.

huggingface.co

Harness 명칭도 위 아티클을 참고하여 본 문서에서 정의하고 있습니다.

 


LLM ≠ Agent

기본적으로 LLM Foundation Model은 질문에 대한 응답만 합니다.
이말은 즉, 되묻거나 실행하는 것은 구조적으로 불가능합니다.

 

그렇다면 직접 실행하고 동작하는 AI 에이전트는 어떻게 가능한지 의문입니다.

 

자율적으로 동작하는 것처럼 보이는 에이전트는 일종의 프로그램입니다.

LLM의 응답에 대해 읽기/쓰기와 같은 작업을 실행하거나 혼자 추론을 계속하는 것처럼 보이는 것은 단순히 LLM이 주는 응답 데이터에 따라 이와 같은 행동을 정의해둔 프로그램이 동작하기 때문입니다.

 


Agent Harness

huggingface 아티클 외에도 Antigravity CLI 발표에서도 위에서 설명한 프로그램을 "Agent Harness"라고 표현합니다.

이번 절에서는 Agent Harness가 어떤 프로그램적 구성 요소를 가지고 있는지 살펴봅니다.

코딩 에이전트를 기준으로 설명합니다.
※코딩 에이전트 : Claude Code(Anthropic), Codex(OpenAI), Antigravity(Google)

 


에이전트 하네스를 구성하는 레이어

AI 생성 이미지

※ 레이어의 순서는 상관없고, 에이전트 프로그램은 LLM 코어 외에도 어떤 추가적인 요소들이 있는지만 참고합니다.

 

하네스 제품군별로 성능 체감이 느껴지는 것은 위 레이어들의 구현방식이 서로 다르기 때문입니다.

 

Tool/ACI 레이어를 예로 특정 파일 내용의 변경을 요청했을 때 다음과 같은 차이를 가질 수 있습니다.

  • Claude Code: diff 명령어를 통해서 변경분만 수정
  • Antigravity: 파일 전체를 재작성

Anthropic에서는 실제로 Tool/ACI 레이어가 하네스 품질의 높은 점유율을 가지고 있다고 말합니다.
※ LLM이 제대로 된 응답을 해도, 잘못된 Tool 실행으로 작업을 망칠 수 있기 때문입니다.

 


오케스트레이션 레이어 (Agent Loop)

오케스트레이션 레이어는 LLM 모델을 언제, 몇 번, 어떤 입력으로 다시 호출할지 결정하는 컨트롤 루프입니다.

하네스(Claude Code 등)는 해당 레이어로 인해 혼자서 실행하고 추측하고 자율적으로 동작하는 것처럼 보이게 됩니다.

 

Agent Loop는 아래와 같은 판단 및 오케스트레이션을 수행합니다.

  • 멈출지, 계속할지
    • LLM 응답이 Text만 반환될 경우 최종 응답을 반환합니다.
    • 읽기/쓰기와 같은 작업(tool_use)가 반환될 경우 실행 및 LLM 재호출을 수행합니다.
      • tool_use의 결과를 입력으로 재구성하여 LLM 호출
  • 컨텍스트/메모리가 가득찰 경우 압축할지, 새로운 세션으로 이어갈지

지휘자처럼 관리하는 느낌으로 오케스트레이션이라는 용어를 사용합니다.

💡또한 그 외의 레이어들은 Scaffolding이라는 용어로 불리우며,
에이전트가 의존하는 인프라 구성의 집합을 의미합니다.

 


하네스를 직접 개발하는 케이스

사용중인 코딩 에이전트(Claude Code, Codex 등)는 완성형 제품입니다.
즉 위의 모든 레이어가 제조사(Anthropic, OpenAI)에서 개발이 다 된 배포판입니다.

 

완성형 제품 특성 상 사용자의 입맛에 맞게 커스텀해서 사용하는것은 불가능합니다.

 

만약 커스텀해서 개인 하네스를 가지고 싶다면 LangChain/ LangGraph 같은 SDK 툴을 사용해서 만들 수 있습니다.

 

📢 하네스 개발 SDK
raw API + 직접 짠 루프(while loop, 외부 의존성 X),
Anthropic의 Claude Agent,
SDKOpenAI의 OpenAI Agents SDK,
CrewAI·AutoGen(MS)·Strands Agents SDK(AWS)·Pydantic AI 같은 서드파티 프레임워크 등

개인 사용이 목적이라면 완성형 하네스를 사용하는게 좋겠지만,

다음과 같은 이유로 하네스를 직접 개발해야하는 케이스가 있을 수 있습니다.

자체 서비스 내에 AI 어시스턴스 기능을 도입하는 경우

※ 완성형 제품을 서버 내 라이브러리로 넣을 순 없기에, 직접 개발하여 구축해야 합니다.

 

그 외에는 다음과 같은 여러 케이스들이 있을 수 있습니다.

  • 특정 컴플라이언스 요구사항(특정 스텝에서 반드시 사람 승인, 특정 로그 포맷 강제)
  • 비용/레이턴시 최적화(불필요한 오케스트레이션 오버헤드 제거)
  • 디버깅 가시성(프레임워크 추상화가 프롬프트/응답을 가리면 문제 추적이 힘들어짐)
  • 온프레미스나 특정 인프라 제약

 


부록: Multi-Agent

멀티 에이전트의 경우 세션이 여러개가 동시에 실행되면서 협업한다고 생각하면 됩니다.

 

본질적으로는 여러 개의 독립적인 LLM 컨텍스트(Context)를 관리하고 조율하는 시스템입니다.

 

단일 에이전트 방식은 하나의 컨텍스트에 모든 페르소나, 규칙(시스템 프롬프트), 작업 이력을 전부 밀어넣기 때문에 컨텍스트가 길어질수록 모델 성능이 떨어지거나 비용이 급증하는 문제가 발생합니다.

 

반면, 멀티 에이전트 시스템은 [기획자 에이전트], [개발자 에이전트], [평가자 에이전트]처럼 각 에이전트마다 역할에 꼭 필요한 최소한의 컨텍스트(프롬프트와 메모리)만 독립적으로 유지합니다.

 

각각의 에이전트는 독립적이기 때문에 에이전트 간 협업하는 방식은 다양합니다.

멀티 에이전트의 협업 방식은 아래 아티클을 참고하면 좋을 듯 합니다.

https://tech.ktcloud.com/entry/2025-03-ktcloud-ai-agent-에이전트-협업시스템

 

[Tech Series] kt cloud AI 에이전트 #4 : 에이전트의 협업 시스템

[kt cloud 마케팅커뮤니케이션팀 김지웅 님 ] Intro안녕하세요, kt cloud 테크 마케터 김지웅 입니다. 🙋‍♂️“혼자 가면 빨리 가지만, 함께 가면 더 멀리 간다”는 말처럼, AI 기술도 이제 ‘협업’

tech.ktcloud.com

 

이러한 멀티 에이전트 협업 방식들이 좋은지는 아직도 시장에서 평가중이며, 아래 논문은 이 내용에 대해 다루고 있습니다.

https://research.google/blog/towards-a-science-of-scaling-agent-systems-when-and-why-agent-systems-work/

 

Towards a science of scaling agent systems: When and why agent systems work

Conclusion As foundational models like Gemini continue to advance, our research suggests that smarter models don't replace the need for multi-agent systems, they accelerate it, but only when the architecture is right. By moving from heuristics to quantitat

research.google

 

+ 여담으로 Google의 Antigravity의 경우 대부분의 경우 Multi-Agent 방식을 채택합니다.

오픈 소스에 따르면 큰/복잡한 작업이 주어질 경우, 매니저 에이전트가 분석해서 서브태스크로 쪼개고, 코드 작성·터미널 명령·브라우저 테스트 같은 특화된 에이전트들이 동시에 작업을 수행한다고 합니다.

https://www.aimadetools.com/blog/antigravity-2-complete-guide/#how-the-agent-system-works

 

Google Antigravity 2.0 Complete Guide: The Agent-First Coding Platform

Everything about Google Antigravity 2.0 — the new desktop app, CLI tool, SDK, and how it replaces Gemini CLI. Setup, pricing, features, and comparison with Claude Code and Codex CLI.

www.aimadetools.com

 


부록: 시장에 출시된 에이전트들.

아래는 AI 시장에서 에이전트 라는 이름으로 산재하는 도구들입니다.

카테고리 핵심 정의 도구
1. 코딩 및 개발 에이전트
(Coding & Dev)
IDE, CLI, 터미널 환경에 결합하여 자율적으로 코드를 작성·수정·배포하는 도구 Claude Code, Codex, Cursor, AntiGravity, Devin, GitHub Copilot, Cline, Windsurf, Gemini CLI, Aider, Replit Agent
2. 에이전트 빌드 프레임워크
(Frameworks & Orchestration)
개발자가 직접 에이전트 아키텍처, 멀티 에이전트 협업, 상태(State) 관리를 코딩하는 도구 Semantic Kernel, LlamaIndex agents, Pydantic AI, Google ADK, OpenAI Agents SDK, LangGraph, CrewAI, AutoGen, Agno, Mastra
3. 노코드 워크플로우 오케스트레이션
(No-Code & Automation)
GUI 기반으로 LLM과 외부 API, 레거시 시스템을 연결하여 업무 파이프라인을 자동화하는 도구 Dify, Zapier, Make, MS Copilot Studio, n8n
4. 오픈소스 및 자율형 에이전트
(Autonomous & Open-Source)
커뮤니티 중심으로 주도되는 로컬 구동 지향형 혹은 독립형 오픈소스 에이전트 프로젝트 Hermes Agent, OpenClaw
Beemo9
@Beemo9
개발 기술 블로그, Dev 포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!
image