AI Agent를 사용하기 전에 알아둘 핵심 개념

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

AI Agent는 답변만 생성하는 상태 없는 LLM과 달리 목표를 작은 작업으로 나누고 Tool을 호출하며 결과를 관찰하는 반복 구조로 업무를 수행합니다. 이 과정에서 이전 대화와 Tool 결과를 매 호출에 다시 담기 때문에 Token과 Context Window의 증가가 비용·지연·품질 저하로 이어질 수 있습니다. Tool은 외부 시스템과 연결되는 함수이고 MCP는 여러 클라이언트와 도구 사이의 연동 부담을 MxN에서 M+N으로 줄이는 규약이며, Skill은 도구 조합 순서를 담은 작업 지침입니다. 규모가 커질수록 Subagent로 컨텍스트를 격리하고 Hook·Supervisor·Harness Engineering으로 실행 범위와 검증 절차를 구조화하는 방식이 중요합니다.

빠른 이해

새로운 점

AI Agent의 능력 확장보다 실행 범위 통제와 실패 검증을 담당하는 Harness Engineering을 상위 구조로 묶어 설명한 점입니다.

핵심 메커니즘

사용자가 목표를 입력하면 Agent가 이를 작은 Task로 분해하고 순서를 정한 뒤, LLM의 판단으로 필요한 Tool과 인자를 선택합니다. Agent는 모델의 실행 요청을 받아 실제 파일·검색·API 작업을 수행하고 결과를 다시 컨텍스트에 넣어 다음 판단을 반복합니다. MCP는 클라이언트와 Tool 사이의 연결 규격을 통일하고, Skill은 Tool 조합 절차를 필요할 때 불러오며, Subagent는 별도 Context Window에서 탐색한 결론만 Main Agent에 반환합니다. Hook·Supervisor·검증 게이트는 실행 범위와 진행 상태를 통제하고 실패를 다음 동작에 반영해 최종 결과가 정해진 조건을 통과하도록 만듭니다.

핵심 수치

MCP 연동 복잡도: M×N → M+N- AI 클라이언트 M개와 연결할 Tool N개가 있을 때 개별 SDK 연동 대신 표준 MCP 서버를 사용하는 구조입니다.
Token 예시: tokenization → token / ization (2 토큰)- 참고용 예시이며 실제 개수는 모델과 토크나이저 버전에 따라 달라집니다.
한글 Token 예시: 토큰화 → 토 / 큰 / 화 또는 그보다 더 잘게 (3 토큰 이상)- 원문이 제시한 참고용 예시입니다.
대화 기록 재전송: 10번째 호출에서 앞선 9턴을 다시 읽음- Context Window가 매 호출의 시스템 프롬프트와 대화 기록을 함께 처리하는 구조를 설명하는 사례입니다.
Subagent 탐색 사례: 파일 20개·검색 5회 후 정리된 결론만 반환- 탐색 과정의 내용을 Main Agent 컨텍스트와 분리하는 예시입니다.

섹션별 상세

LLM과 Agent의 차이

LLM은 입력을 받아 출력을 내놓는 상태 없는 함수로, 이전 대화를 기억하는 것이 아니라 매 호출마다 대화 기록 전체를 다시 받으며 연속 대화를 구현합니다. 따라서 스스로 인터넷을 검색하거나 로컬 파일을 수정하지 못하지만, AI Agent는 사용자의 목표를 실행 가능한 Task로 쪼개고 Tool을 호출해 결과를 확인하면서 처음부터 끝까지 작업을 진행합니다. Codex, Claude Code, Gemini CLI가 Agent의 사례로 언급되며, Agent의 자율성은 긴 루프에서 컨텍스트와 비용을 누적시키고 권한 밖의 파일까지 건드릴 위험을 함께 키웁니다. 두 개념을 구분해야 단순 텍스트 생성과 외부 환경을 실제로 조작하는 실행 계층을 각각 설계할 수 있습니다.

ReAct와 실행 루프

Agent는 목표를 받은 뒤 작업 순서를 세우고, 지식이 부족하면 등록된 Tool의 설명을 읽어 적절한 함수를 선택합니다. LLM이 추론하고 Agent가 Action을 실행한 뒤 결과를 관찰하며 다시 판단하는 순환이 ReAct 패턴의 핵심이며, 오늘날에는 네이티브 tool calling으로 구현 방식이 달라져도 판단→행동→관찰→재판단의 뼈대가 유지됩니다. 루프는 모델의 완료 선언, 최대 반복 횟수나 Token 예산, 외부 테스트 통과 같은 종료 조건을 가져야 하며, 이 가운데 테스트 통과가 가장 신뢰할 만한 기준으로 언급됩니다. 종료 조건이 없으면 무한 실행이 발생하고 너무 엄격하면 작업이 끝나기 전에 중단되므로, 실행 비용과 결과 검증을 함께 기준으로 삼아야 합니다.

Token과 컨텍스트 관리

Token은 글자나 단어가 아니라 토크나이저가 나눈 조각이며, 원문은 tokenization이 token과 ization 두 토큰으로 나뉘고 토큰화는 토·큰·화 또는 그보다 잘게 쪼개질 수 있다는 참고 예시를 듭니다. 모델과 토크나이저 버전에 따라 실제 수치가 달라지고 입력·출력에 별도 단가가 붙을 수 있으므로 비용이 민감한 작업에서는 Token Counting API로 직접 확인해야 합니다. Context Window에는 시스템 프롬프트, 전체 대화 기록, Tool 목록, 실행 결과와 새 답변이 함께 들어가며 대화가 10턴이면 10번째 호출에서 앞선 9턴을 다시 읽습니다. 한도에 도달하면 오래된 내용이 삭제되거나 요약되고, 한도 전에도 긴 컨텍스트의 중간 정보가 묻힐 수 있어 현재 작업과 무관한 기록을 줄이는 관리가 필요합니다.

json

{ "name": "read_file", "description": "주어진 경로의 파일 내용을 UTF-8 텍스트로 반환한다", "input_schema": { "type": "object", "properties": { "path": { "type": "string", "description": "읽을 파일의 경로" } }, "required": ["path"] } }

Agent가 로컬 파일을 읽는 Tool의 이름, 기능 설명, 입력 인자 스키마를 모델에 전달하는 명세입니다.

확장성을 만드는 구성요소

Tool은 함수 이름·설명·입력 스키마를 모델에 제공하고, 모델은 실행 요청만 내놓으며 실제 파일 읽기나 API 호출은 Agent가 수행합니다. 예시의 read_file 명세는 경로를 문자열 인자로 받아 UTF-8 파일 내용을 반환한다고 정의하며, 설명이 모호하면 잘못된 Tool을 선택하고 도구를 과도하게 등록하면 명세만으로도 컨텍스트를 소모합니다. MCP는 클라이언트 M개와 도구 N개의 개별 연동을 MxN에서 M+N으로 줄이는 표준 규약으로, Tools뿐 아니라 읽기 전용 Resources와 재사용 가능한 Prompts도 다룹니다. Skill은 Tool을 어떤 순서와 방식으로 조합할지 담은 SKILL.md 기반 지침이고, Plugin은 Tool·Skill·MCP 서버를 묶은 패키지이며 Marketplace는 이를 유통하지만 외부 코드를 실행하는 것과 같으므로 제공처의 신뢰성을 확인해야 합니다.

Agent를 통제하는 하네스

대규모 프로젝트를 하나의 Agent에 맡기면 컨텍스트가 과도하게 커져 품질이 낮아질 수 있어, Multi-Agent Orchestration은 Main Agent가 작업을 나누고 Subagent가 별도 컨텍스트에서 탐색한 뒤 정리된 결과만 반환하는 방식으로 대응합니다. Supervisor는 실행 상태를 감시하다가 무한 루프나 반복 실패가 발생하면 Nudge를 보내고, 해결되지 않으면 인간에게 Escalate하며, Hook은 파일 저장이나 커밋 직전에 린트·테스트·금지된 파일 수정 차단을 자동 실행합니다. Harness Engineering은 이 장치들을 Control·Monitoring·Feedback으로 묶어 권한과 린트 규칙으로 범위를 제한하고 로그와 검증 게이트로 상태를 추적하며 위반 결과를 다음 컨텍스트에 되돌립니다. “반드시 XYZ를 하라”는 프롬프트가 준수 확률에 머무는 반면 빌드를 깨뜨리는 검증 스크립트는 실패를 재사용 가능한 운영 자산으로 남기므로, 모델 교체 뒤에도 같은 제어 구조를 적용할 수 있습니다.

용어 해설

ReAct 패턴(ReAct Pattern): — ReAct는 LLM의 추론과 외부 도구 실행을 번갈아 수행하는 Agent 패턴입니다. 목표를 작은 작업으로 나눈 뒤 판단하고, Tool을 호출하고, 결과를 관찰해 다음 행동을 정합니다. 2022년 논문에서 제안됐으며, 현재의 네이티브 함수 호출 구현에도 판단→행동→관찰→재판단이라는 구조가 남아 있습니다.
토큰(Token): — Token은 모델의 토크나이저가 텍스트를 쪼갠 처리 단위입니다. 글자나 단어와 일치하지 않으며, 언어와 토크나이저에 따라 같은 의미의 문장도 다른 개수로 변환됩니다. 입력·출력 비용과 처리량을 가늠하는 기준이 되고, 한글은 영어보다 더 많은 토큰을 사용할 수 있습니다.
컨텍스트 윈도우(Context Window): — Context Window는 한 번의 모델 호출에서 처리할 수 있는 Token의 총량입니다. 시스템 프롬프트, 대화 기록, Tool 명세, 실행 결과와 생성 답변이 모두 이 한도에 포함됩니다. 내용이 길어지면 비용과 지연이 늘고, 오래된 정보가 잘리거나 요약되며, 한도에 닿기 전에도 중간 내용의 활용도가 낮아질 수 있습니다.
점진적 공개(Progressive Disclosure): — Progressive Disclosure는 필요한 정보만 단계적으로 컨텍스트에 올리는 Skill 설계 방식입니다. 세션 시작에는 Skill의 이름과 설명만 제공하고, Agent가 필요성을 판단하면 본문을 읽으며, 본문 속 상세 문서는 실제 필요 시 추가로 불러옵니다. 항상 읽히는 규칙 파일보다 세션 비용을 줄이는 데 적합합니다.
하네스 엔지니어링(Harness Engineering): — Harness Engineering은 모델 자체를 더 똑똑하게 만들기보다 Agent가 일하는 환경에 제어·감시·개선 장치를 배치하는 방식입니다. Hook과 권한 모델로 허용 범위를 제한하고, Supervisor와 로그로 상태를 추적하며, 실패 결과를 다음 동작에 반영합니다. 프롬프트의 준수 확률을 구조적 검증으로 보완하는 접근입니다.
함수 호출(Function Calling): — Function Calling은 모델이 등록된 함수의 이름과 인자를 선택해 실행 요청을 내놓는 방식입니다. 모델이 파일이나 API를 직접 실행하는 것이 아니라, Agent가 요청을 받아 실제 함수를 호출하고 결과를 다시 모델에 전달합니다. 함수의 설명과 입력 스키마가 도구 선택의 근거가 되므로 명세의 명확성과 범위가 중요합니다.

기술

LLM
AI Agent
Codex
Claude Code
GitHub Copilot
Gemini CLI
ReAct
Tool
MCP
LangChain
CrewAI
Skill
Plugin
Marketplace
Supervisor
Hook
Harness Engineering
CLAUDE.md
AGENTS.md
Token
Context Window
Function Calling

언급된 리소스

문서원문 링크