요약 — AI 에이전트는 질문에 답만 하는 챗봇과 달리, 파일을 직접 만들고 명령을 실행하며 여러 단계를 스스로 이어가는 프로그램이다. 이 글에서는 에이전트가 정보를 담아두는 공간인 Context Window, 역할을 나눠 맡기는 Subagent, 자주 쓰는 지시를 저장해두는 Skill, 외부 도구에 연결하는 통로인 MCP를 순서대로 정리한다.
이 블로그는 지금까지 팔란티어 Foundry와 온톨로지를 주로 다뤄왔습니다. 그런데 최근 Claude Code, Codex, AI Pro 같은 AI 에이전트 도구를 실제로 써보면서, “온톨로지를 몰라도 지금 당장 AI를 실무에 쓰는 사람”에게 필요한 개념이 따로 있다는 걸 느꼈습니다. 이번 글부터 몇 편은 그 개념들을 다룹니다.
AI 에이전트는 챗봇과 뭐가 다른가
ChatGPT 같은 챗봇에 질문하면, AI는 텍스트로 답만 하고 끝납니다. 다음 행동은 사람이 직접 합니다.
AI 에이전트는 여기서 한 걸음 더 나갑니다. 파일을 직접 만들고, 코드를 실행하고, 결과를 확인한 뒤 다음 단계로 스스로 넘어갑니다. 사람이 “이 로그 파일을 분석해서 그래프로 만들어줘”라고 한 번 말하면, 에이전트는 파일을 읽고, 데이터를 정리하고, 그래프를 그리는 코드를 작성하고, 실행까지 혼자 진행합니다.
비유하자면 챗봇은 전화로 물어보는 상담원이고, 에이전트는 직접 자리에 앉아서 일을 처리하는 직원에 가깝습니다.
Context Window — 에이전트가 지금 기억하고 있는 것
AI 에이전트에게 프롬프트를 입력하면, 그 내용이 바로 AI 모델로 들어가지 않습니다. Context Window라는 공간에 먼저 담긴 뒤, 그 공간에 있는 내용 전체가 모델에 입력됩니다.
이 공간에는 다음과 같은 것들이 함께 들어갑니다.
- 사용자가 방금 입력한 프롬프트
- 프로젝트 규칙이 적힌 파일(뒤에서 다룰 AGENTS.md 같은 것)
- 지금까지 주고받은 대화 내용
- 에이전트가 읽은 파일의 내용
이 공간은 무한하지 않습니다. 일정 용량을 넘으면 에이전트는 오래된 내용을 요약하거나 잘라내야 하는데, 이 과정에서 중요한 맥락이 손실되면 에이전트가 갑자기 엉뚱하게 행동하는 경우가 생깁니다. Context Window가 꽉 차갈수록 에이전트가 지시를 조금씩 안 지키는 현상이 나타나는 것도 이 때문입니다.
실무 팁: 작업이 길어질수록 이 공간이 채워지고 있다는 걸 의식하는 것이 좋습니다. 중간중간 필요 없는 대화나 파일 내용을 정리해서 공간을 비워주면, 에이전트가 더 안정적으로 동작합니다.
Subagent — 한 명이 다 하는 것보다 나눠 맡기는 게 나은 이유
AI 에이전트 하나에게 복잡한 작업을 전부 맡기면, 그 에이전트의 Context Window 안에 계획·구현·검증까지 모든 정보가 뒤섞입니다. 정보가 많고 다양할수록 헷갈려서 실수할 확률도 올라갑니다.
Subagent는 이 문제를 해결하는 방법입니다. 하나의 큰 작업을 여러 개의 독립적인 에이전트로 쪼개서, 각자 자기 몫만 집중하게 만드는 것입니다.
예를 들어 마케팅 카피 초안을 여러 편 만드는 작업을 생각해봅시다.
- 단일 에이전트에게 맡기면: “초안을 쓰고, 브랜드 톤에 맞는지 검토하고, 오탈자도 확인하고, 경쟁사 카피와 겹치지 않는지도 봐줘”를 한 에이전트가 동시에 신경 써야 합니다.
- Subagent로 나누면: 카피라이터 에이전트는 초안만 쓰고, 톤 검토 에이전트는 브랜드 가이드에 맞는지만 보고, 교정 에이전트는 오탈자만 확인합니다. 마지막에 총괄 에이전트가 세 결과를 모아 정리합니다.
각 Subagent는 자신의 역할에 필요한 정보만 Context Window에 담고 있기 때문에, 헷갈릴 일이 적고 결과물의 정확도가 올라갑니다.
Skill — 반복되는 지시를 하나의 명령으로 저장해두기
같은 지시를 매번 길게 타이핑하는 건 비효율적입니다. Skill은 자주 쓰는 프롬프트나 작업 절차를 하나의 명령어로 저장해두는 기능입니다.
Skill이 될 수 있는 것은 크게 두 가지입니다.
- 자주 반복하는 프롬프트 자체를 하나의 명령으로 만든 것 (예: “이 문서를 우리 회사 톤으로 다듬어줘”라는 긴 지시를
/tone-check한 줄로) - 파일 편집, 명령어 실행, 웹 검색 같은 특정 도구 사용법을 묶어서 명령으로 만든 것 (예: PDF를 읽고 요약하는 절차 전체를
/pdf-summary로)
Skill을 잘 쌓아두면, 같은 작업을 반복할 때마다 매번 설명할 필요 없이 명령 하나로 실행할 수 있습니다.
주의할 점: Skill 안에는 실행 가능한 코드가 들어있는 경우가 많습니다. 출처가 불분명한 Skill을 그대로 설치하면 보안 위험이 있을 수 있으니, 공식적으로 검증된 Skill을 우선 사용하는 것이 안전합니다.
MCP — 에이전트가 외부 도구에 연결되는 통로
AI 에이전트는 기본적으로 자기 안에 있는 기능만 쓸 수 있습니다. 그런데 브라우저를 직접 조작하거나, 특정 회사의 서비스 데이터를 가져오려면 외부 프로그램과 연결되어야 합니다.
MCP(Model Context Protocol)는 이 연결을 위한 공통 규격입니다. 에이전트(MCP Client)가 외부 도구(MCP Server)에게 “이 작업을 해줘”라고 요청하면, MCP Server가 그 작업을 수행하고 결과를 돌려줍니다.
비유하면, 에이전트가 직접 모든 외국어를 배우는 대신, 필요할 때마다 그 분야 전문 통역사(MCP Server)를 통해 대화하는 것과 비슷합니다. 에이전트는 통역사를 통해 자신이 못 하는 일도 처리할 수 있게 됩니다.
실제로 많이 쓰이는 예로는 웹 브라우저를 자동으로 조작하는 MCP, 특정 회사의 데이터베이스에 연결하는 MCP 등이 있습니다. 이 블로그에서 다룬 OMCP(Ontology MCP)도 같은 원리로, AI 에이전트가 팔란티어 온톨로지 데이터에 연결되게 해주는 통로입니다.
정리
| 개념 | 한 줄 정의 |
|---|---|
| Context Window | 에이전트가 지금 기억하고 참고하는 정보가 담기는 공간 |
| Subagent | 큰 작업을 역할별로 나눠서 여러 에이전트가 각자 맡는 방식 |
| Skill | 자주 쓰는 지시나 작업 절차를 하나의 명령으로 저장해둔 것 |
| MCP | 에이전트가 외부 도구·서비스에 연결되는 공통 통로 |
이 네 가지는 앞으로 다룰 프롬프트/컨텍스트 엔지니어링, 하네스 엔지니어링, 에이전틱 엔지니어링을 이해하는 데 필요한 기본 어휘입니다. 다음 글에서는 프롬프트 엔지니어링과 컨텍스트 엔지니어링이 정확히 어떻게 다른지 다룹니다.