최근 저는 필리핀 바기오에 있는 영어 학원의 반 친구들에게 영어로 이 강연을 했습니다. 그들 대부분은 ChatGPT를 사용해 본 적이 있었습니다. 하지만 AI 에이전트 (AI agent)를 사용해 본 사람은 거의 없었습니다. 그리고 이 두 경험 사이의 차이를 설명하는 것은 제가 예상했던 것보다 훨씬 더 어려웠습니다.

문제는 구성 요소들이 어떻게 쌓여 있는지 이해하지 못하면, AI 에이전트가 마법처럼 보인다는 점입니다. 도구가 마법처럼 보일 때, 당신은 그것을 사용하는 데 능숙해질 수 없습니다. 그저 이것저것 건드려 보며 운이 좋기를 바랄 뿐입니다.

그래서 이것은 제가 가졌으면 좋았을 설명에 대한 저의 시도입니다. 무엇이 발명되었는지, 발명된 순서대로, 그리고 각 계층 (layer)이 무엇을 가능하게 했는지를 살펴봅니다. 저는 직관을 위해 약간의 기술적 정밀함을 양보했습니다. 목표는 마지막에 도달했을 때, 에이전트가 하는 그 어떤 일도 당신을 놀라게 하지 않는 것입니다.

대상 독자: ChatGPT를 사용해 본 적은 있지만 코딩 에이전트 (coding agent)를 사용해 본 적은 없는 사람, 그리고

그것은 자신이 무엇을 모르는지조차 모릅니다. 모델은 정보를 검색하기보다는 가장 그럴듯한 (plausible) 다음 토큰을 생성하기 때문에, 정답만큼이나 자신감 있고 유창하며 완전히 조작된 답변을 아주 쉽게 내놓을 것입니다. 이것이 사람들이 말하는 환각 (hallucination)이며, 이는 패치로 해결될 수 있는 버그가 아니라 작동 방식 그 자체의 직접적인 결과입니다. 이 글의 나머지 모든 내용은 어떤 방식으로든 이를 보완하려는 시도입니다.

2. 컨텍스트 윈도우 (The context window)

컨텍스트 윈도우 (context window)는 모델이 한 번에 시야에 담을 수 있는 텍스트의 양을 의미합니다. 즉, 사용자의 프롬프트 (prompt), 대화 기록, 붙여넣은 모든 문서, 그리고 모델 자신의 답변을 모두 합산하여 토큰 (tokens) 단위로 계산한 것입니다.

2026년 중반 기준으로, 그 한계치는 크게 상승했습니다:

100만 토큰은 대략 수천 페이지에 달하는 분량입니다. 이 정도면 더 이상 걱정할 필요가 없을 것처럼 들리지만, 두 가지 이유 때문에 그렇지 않습니다.

첫째, 윈도우가 커질수록 비용이 더 많이 들고 속도가 느려집니다. 윈도우에 포함된 모든 토큰은 매 턴마다 처리되어야 합니다.

둘째, 그리고 더 중요한 점은, 거대한 컨텍스트 윈도우를 가진 모델이라 할지라도 그 안에 담긴 모든 정보에 똑같이 주의를 기울이지는 못한다는 것입니다. 900,000 토큰의 노이즈(noise) 사이에 중요한 한 줄을 묻어버리면 모델이 이를 놓칠 가능성이 큽니다. 더 많은 컨텍스트가 자동으로 더 나은 컨텍스트가 되는 것은 아닙니다.

이것이 바로 "그냥 모든 것을 다 붙여넣으라"는 전략이 실패하는 이유이며, 이 글을 마무리하는 아이디어의 씨앗이 됩니다.

3. RAG: 모델이 배우지 못한 지식을 제공하기

결국 모델은 당신의 정보를 알지 못합니다. 이를 해결하는 데에는 두 가지 방법이 있으며, 이 둘은 종종 서로 혼동되곤 합니다.

옵션 A: 미세 조정 (fine-tuning). 모델을 당신의 데이터로 계속 학습시켜 지식이 모델의 가중치 (weights)에 내재되도록 합니다. 이 방법은 실제로 효과가 있지만, 비용이 많이 들고, 크고 깨끗한 데이터셋이 필요하며, 모델을 더 좋게 만들었는지 아니면 더 나쁘게 만들었는지 평가하는 것 자체가 하나의 연구 과제입니다. 또한 데이터가 변경되는 순간 다시 수행해야 합니다. "모델이 우리의 내부 문서를 알아야 한다"라는 목적을 위해서는 거의 항상 잘못된 도구입니다.

옵션 B: 검색 증강 생성 (RAG, Retrieval-Augmented Generation). 모델은 그대로 둡니다. 지식은 별도의 검색 가능한 저장소에 보관합니다. 질문이 들어오면 먼저 저장소를 검색한 다음, 질문과 검색 결과 둘 다 모델에게 전달하고, 그것들을 사용하여 답변하도록 요청합니다.

사용자: "유급 휴가는 어떻게 신청하나요?"
   ↓
앱: 내부 지식 베이스를 검색함
...

RAG가 승리했습니다. 그것이 더 우아해서가 아니라, _운영적 (operational)_이기 때문입니다. 문서를 업데이트하면 재학습 없이도 시스템의 지식이 즉시 업데이트됩니다. 그리고 결정적으로, 모델은 이제 기억(memory)이 아니라 당신이 실제로 눈앞에 놓아준 텍스트를 바탕으로 답변합니다. 이것이 환각 (hallucination)을 실질적으로 줄인 첫 번째 성과입니다.

기억해야 할 핵심 아이디어: 모델이 찾아볼 수 있는 외부 메모리를 얻었다는 것입니다.

4. 함수 호출 (Function calling) → MCP: 모델에게 손을 달아주기

RAG는 모델이 세상을 읽을 (read) 수 있게 해줍니다. 하지만 여전히 세상을 만질 (touch) 수는 없습니다.

2023년 6월, OpenAI는 함수 호출 (function calling) 기능을 출시했으며, 그 형태는 대부분의 사람들이 예상하는 것보다 훨씬 단순합니다. 당신은 모델에게 평문 (plain text)으로 도구들을 설명합니다. 모델은 아무것도 실행할 수 없습니다. 단지 어떤 도구를 어떤 인자 (arguments)와 함께 사용하고 싶은지만 말할 뿐입니다. 실행은 당신의 코드가 합니다. 그런 다음 당신은 그 결과를 다시 모델에게 전달합니다.

사용자: "도쿄 날씨는 어때?"    (+ get_weather 도구 설명 포함)
   ↓
LLM: "get_weather(city='Tokyo')를 호출하고 싶습니다."
...

그 격차 — 모델이 _요청(ask)_하고, 당신의 코드가 _실행(act)_하는 것 — 가 에이전트에 대해 내재화해야 할 가장 중요한 핵심입니다. 에이전트는 스스로 움직일 수 있는 손이 없습니다. 에이전트가 하는 모든 일은 당신의 프로그램에 그 일을 해달라고 요청함으로써 이루어집니다. 즉, 당신이 원하는 모든 가드레일 (guardrail) 은 바로 그 지점에 구축해야 한다는 의미입니다.

그다음은 통합 (integration) 문제였습니다. 모든 도구는 각 AI 제품마다 맞춤형 접착제 (glue) 가 필요했습니다. N개의 도구에 M개의 앱이 곱해지는 상황이었죠.

2024년 11월, Anthropic은 **MCP (Model Context Protocol)**를 출시하고 오픈 소스로 공개했습니다. 이는 AI 애플리케이션이 도구나 데이터 소스에 연결되는 단 하나의 표준화된 방식입니다. 당신의 서비스에 대해 MCP 서버를 한 번만 구축하면, MCP를 지원하는 어떤 클라이언트 (client) 도라도 이를 사용할 수 있습니다. 사람들은 이를 "AI를 위한 USB-C"라고 불렀는데, 이는 꽤 적절한 비유입니다.

이 방식은 성공했습니다. 2026년까지 MCP는 OpenAI, Google, Microsoft에 의해 채택되었으며, 10,000개 이상의 공개 서버가 실제로 운영되고 있습니다. 한 벤더 (vendor) 가 출시한 프로토콜이 그들의 직접적인 경쟁사들에 의해 채택되는 것은 드문 일이며, 이는 대안 — 즉, 모든 이가 영원히 맞춤형 통합 (bespoke integrations) 을 유지해야 하는 상황 — 이 모두에게 더 나쁜 결과였기에 가능했습니다.

5. 추론 모델 (Reasoning models): 먼저 생각하고, 그다음에 답변하라

지금까지의 모든 과정은 여전히 질문 하나에 답변 하나가 나오는 구조를 가정했습니다. 질문하고, 생성하고, 끝나는 방식이었죠.

2024년 9월, OpenAI의 o1은 그 가정을 깨뜨렸습니다. 추론 모델은 답변하기 전에 생각합니다. 내부적으로 문제를 상당한 시간 동안 풀어낸 뒤에야 비로소 응답을 생성합니다.

마지막 행이 과소평가된 부분입니다. 추론 모델은 프롬프트 엔지니어링 (prompt-engineering) 기술의 필요성을 훨씬 줄여주었습니다. 모델은 사용자의 의도를 첫 시도에 완벽하게 설명할 필요 없이, 스스로 파악할 수 있는 여유를 갖게 되었습니다.

2026년에 이르러 이는 적응형 (adaptive) 으로 진화했습니다. 모델은 주어진 작업에 얼마나 많은 사고가 필요한지 스스로 결정하며, 사용자는 토큰 예산 (token budget) 을 수동으로 조정하는 대신 단 하나의 "노력 (effort)" 다이얼로 이를 조절합니다. 쉬운 질문에는 빠른 답변을, 어려운 질문에는 모델이 충분한 시간을 들여 처리하게 됩니다.

6. 2025년: 조각들이 하나로 맞춰지다

에이전트(agents)를 위해 근본적으로 새로운 것이 필요했던 것은 아닙니다. 모든 것은 이미 준비되어 있었습니다. 2025년에는 단지 그것들이 조립되었을 뿐입니다:

• 추론 (Reasoning) → 모델이 계획을 세울 수 있음
• 함수 호출 (Function calling) / MCP → 행동할 수 있음
• RAG (검색 증강 생성) → 정보를 찾아볼 수 있음
• 긴 컨텍스트 (Large context) → 전체 과업을 한눈에 파악할 수 있음

이것들을 하나의 루프(loop) — 계획, 행동, 결과 관찰, 조정, 다시 행동 — 안에 넣으면, 그것이 바로 에이전트가 됩니다.

이를 구체적으로 보여주는 대조 사례는 초기 GitHub Copilot입니다. Copilot은 다음 몇 줄을 자동 완성했습니다. 단발성(Single shot)이었고, 메모리도 계획도 없었습니다. 유용했지만, 규모가 작았습니다.

현대의 코딩 에이전트는 사용자가 개입하지 않아도 수십 개의 파일에 걸쳐 코드를 변경하고, 테스트 스위트(test suite)를 실행하고, 실패 내용을 읽고, 에러를 위해 웹을 검색하고, 가설을 세우고, 이를 수정하고, 테스트를 다시 실행합니다. 근간이 되는 모델 제품군(model family)은 동일합니다. 차이점은 전적으로 루프(loop)에 있습니다.

이 과정 위에 등장한, 알아둘 가치가 있는 두 가지가 있습니다:

에이전트 스킬 (Agent Skills, 2025년 10월). 스킬(skill)은 무언가를 수행하는 방법 — 절차, 스타일 가이드, 체크리스트 등 — 을 설명하는 마크다운(Markdown) 파일이 들어 있는 폴더입니다. 에이전트는 과업이 요구할 때만 이를 로드합니다. 이는 모든 프롬프트(prompt)를 비대하게 만들지 않으면서 에이전트에게 전문 지식을 전달하는 방법입니다.

흔한 오해 중 하나는 스킬이 MCP를 대체했다는 것입니다. 그렇지 않으며, 그 차이를 정확히 이해하는 것이 중요합니다: MCP는 에이전트를 외부 세계와 연결합니다. 스킬은 에이전트에게 업무 수행 방법을 가르칩니다. 두 가지를 모두 사용합니다. 또한 스킬은 단순한 마크다운 형식이기에, 프로세스를 소유한 사람이 엔지니어 없이도 직접 유지 관리할 수 있습니다.

인프라로서의 에이전트 (Agents as infrastructure, 2026년). 이제 에이전트는 호스팅된 서비스로서 실행됩니다: 장기 실행(long-lived)되고, 예약 가능하며, 세션 간 지속적인 메모리(persistent memory)를 가지고, 관리되는 샌드박스(sandbox) 환경에서 작업합니다. 매일 밤 실행되어 아침에 보고하는 에이전트는 이제 평범한 일이 되었습니다.

실제로 중요한 부분

이제 사고방식의 전환에 대해 이야기하겠습니다. 위의 내용이 '무엇(what)'에 관한 것이라면, 이 부분은 '그래서 무엇이 중요한가(so what)'에 관한 것이기 때문입니다.

프롬프트 엔지니어링에서 컨텍스트 엔지니어링으로

과거의 게임은 완벽한 프롬프트 (prompt)를 작성하는 것이었습니다. 마법 같은 문구를 찾아내고, 주문을 발견하며, 템플릿을 수집하는 것이었죠.

그 게임은 이제 거의 끝났습니다. 추론 모델 (Reasoning models)은 의도를 추론하는 능력이 충분히 뛰어나기 때문에, 영리한 문구 작성이 더 이상 병목 현상 (bottleneck)이 되지 않습니다.

새로운 게임은 모델이 무엇을 보게 할 것인가를 결정하는 것입니다. 컨텍스트 윈도우 (context window)는 유한하며, 그 안의 공간을 차지하기 위해 경쟁하는 모든 요소는 트레이드오프 (tradeoff) 관계에 있습니다.

하나에 소비하는 모든 토큰 (token)은 다른 것에 사용할 수 없는 토큰입니다. 그리고 섹션 2에서 보았듯이, 컨텍스트 윈도우가 가득 찼다고 해서 그것이 잘 활용되고 있다는 뜻은 아닙니다.

따라서 이제 기술은 더 이상 '문구 작성'이 아닙니다. 그것은 큐레이션 (curation) — 무엇이 관련이 있고, 무엇이 노이즈이며, 무엇을 제외할지를 결정하는 것입니다. 이것은 엔지니어링 문제이며, 훨씬 더 흥미로운 문제입니다.

"AI에게 지시하기"에서 "AI와 함께 생각하기"로

과거의 루프 (loop):

인간이 지시함 → AI가 생성함 → 인간이 판단함 → 반복

당신이 생각을 합니다. AI는 타이핑을 합니다. 당신은 결과물을 채점합니다.

새로운 루프:

인간 ⟷ AI: 함께 생각하기
인간 ⟷ AI: 방향성에 대해 합의하기
인간 ⟷ AI: 그것을 구축하기

마지막 행이 이 글 전체를 한 줄로 요약한 것입니다. 오늘날 에이전트 (agent)가 잘못 작동할 때, 그 해결책은 거의 결코 더 정교한 문구의 프롬프트가 아닙니다. 에이전트에게 필요한 무언가 — 파일, 제약 조건, 이유, 혹은 당신의 머릿속에는 있었지만 윈도우에는 전달되지 못한 정보의 조각 — 가 없었기 때문입니다.

이는 정확히 이전 섹션을 마무리했던 문제와 같습니다. 두 가지는 동일한 문제입니다.

어디서부터 시작할 것인가

여기까지 읽었음에도 에이전트를 한 번도 구동해 본 적이 없다면, 다음 단계는 더 많은 글을 읽는 것이 아닙니다. 에이전트를 하나 열고, 장난감이 아닌 실제 업무에서 사용하는 진짜 과업을 부여하는 것입니다. 그것이 무엇을 하는지 지켜보세요. 어디서 잘못되는지 지켜보세요. 그런 다음 스스로에게 진단 질문을 던지십시오.

내가 알고 있었지만, 에이전트는 몰랐던 것은 무엇인가?

그 질문에 답하고, 그 답을 앞에 둔 채 다시 시작하십시오. 그 루프(loop)가 바로 기술입니다. 이 글의 나머지 모든 내용은 단지 그것을 위한 배경 지식일 뿐입니다.

캐나다로 이주하는 일본인 소프트웨어 엔지니어가 작성했습니다. 저는 AI 엔지니어링과 제2외국어로 커리어를 재구축하는 것이 어떤 것인지에 대해 글을 씁니다. 댓글을 통한 수정과 의견 차이는 언제나 환영합니다.