에이전트를 직접 만들어봐야 하는 이유

LLM 에이전트, 개념보다 ‘직접 구현’이 중요한 이유

요즘 AI 분야에서 가장 많이 언급되는 키워드 중 하나가 바로 ‘에이전트(Agent)’입니다. 하지만 많은 개발자들이 이 개념을 문서나 영상으로만 접하고, 실제로 구현해보는 경험은 부족합니다.

LLM 에이전트는 단순한 API 호출로 만들어지는 대화형 인공지능이 아닙니다. 상태 없는 언어 모델과의 반복적인 상호작용을 통해 스스로 맥락을 관리하고, 필요 시 도구를 호출해 자율적으로 행동할 수 있는 구조를 가집니다.

이 글에서는 Fly.io에서 제시한 예시를 바탕으로, 왜 에이전트를 직접 만들어봐야 하는지, 그리고 그 경험이 LLM 기술 이해에 어떤 통찰을 주는지를 살펴보겠습니다.

반응형

---

에이전트의 단순한 구조 이해하기

LLM 에이전트는 복잡한 설정이 필요하지 않습니다. 불과 몇 줄의 Python 코드로 OpenAI Responses API를 사용해 대화형 에이전트를 만들 수 있습니다.

핵심 구조는 간단합니다.
사용자와 모델 간의 대화 내용을 context 리스트에 순차적으로 저장하고, 이를 반복적으로 모델에 전달하는 방식으로 동작합니다. 이렇게 하면 LLM이 상태를 직접 유지하지 않아도, 외부 코드가 대화의 맥락을 관리하게 됩니다.

이 단순한 구조만으로도 다중 회차 대화가 가능합니다.
예를 들어, “좋은 성격”과 “나쁜 성격”이라는 두 가지 컨텍스트를 만들어 서로 다른 대화 패턴을 시뮬레이션할 수 있습니다. 이를 통해 대화형 에이전트가 어떻게 응답을 만들어내는지 직접 체감할 수 있습니다.

---

도구 통합과 자율적 동작의 구현

에이전트는 단순히 대화하는 것에 그치지 않습니다. 외부 도구를 통합하면 ‘자율적으로 행동하는’ 에이전트를 만들 수 있습니다.

예를 들어, ping 함수를 도구로 등록하면 LLM은 네트워크 상태를 점검할 수 있습니다. OpenAI API는 도구를 JSON 형식으로 정의하도록 요구하며, 모델은 필요할 때 스스로 도구 호출을 요청합니다.

이때 놀라운 점은 LLM이 명시적인 지시 없이도 여러 호스트(예: google.com, www.google.com, 8.8.8.8)에 대해 ping을 시도한다는 것입니다. 이는 단순히 “도구 사용 권한”을 부여했을 뿐인데도, 모델이 자율적으로 판단하고 행동했다는 뜻입니다.

즉, 전체 구조는 단순한 루프입니다.
“도구 호출 요청 → 실행 → 결과 반환”의 흐름만으로도 복잡한 제어 로직 없이 자율적 에이전트가 동작할 수 있습니다.

---

MCP에 대한 비판과 대안적 접근

최근 일부 도구나 프레임워크에서는 MCP(Multi-Context Protocol)를 활용한 플러그인 인터페이스를 강조하지만, 이는 필수 기술이 아닙니다.

MCP는 Claude Code나 Cursor와 같은 환경에서 제어권이 제한된 상황에서는 유용할 수 있습니다. 하지만 직접 API를 다루는 환경에서는 오히려 유연성을 해칠 수 있습니다.

Fly.io의 접근은 단순합니다.
MCP에 의존하지 않고, 직접 OpenAI Responses API를 활용해 동일한 기능을 구현합니다.
이 방식은 코드 제어권을 완전히 개발자가 가질 수 있게 하며, 환경 제약 없이 실험적 시도를 할 수 있다는 장점이 있습니다.

---

컨텍스트 엔지니어링의 중요성

많은 사람들이 ‘프롬프트 엔지니어링’에 집중하지만, 실제로 더 중요한 것은 ‘컨텍스트 엔지니어링’입니다.

LLM은 입력 토큰 수에 제한이 있습니다. 따라서 대화 맥락, 도구 설명, 출력 등을 효율적으로 구성하지 않으면 응답 품질이 불안정해집니다. 이 문제를 해결하기 위해서는 입력·출력·도구 설명을 균형 있게 설계해야 합니다.

하나의 해결책으로는 서브 에이전트(sub-agent) 구조가 있습니다.
각 서브 에이전트는 자신만의 컨텍스트와 도구를 가지고 특정 역할을 수행하며, 서로 결과를 요약해 교환할 수 있습니다. 이를 통해 토큰 한계 문제를 완화하고, 보다 복잡한 문제를 단계적으로 처리할 수 있습니다.

이처럼 컨텍스트 엔지니어링은 단순한 설정이 아닌, 실제 프로그래밍 과제 수준의 설계 영역입니다.

---

열린 실험의 가치: 직접 만들어보는 이유

현재 수많은 스타트업이 보안 진단, 취약점 탐지, 데이터 분석 등 다양한 분야에서 LLM 에이전트를 실험 중입니다. 그러나 이 영역은 여전히 열린 공학 문제로 남아 있습니다.

에이전트 설계에는 다음과 같은 미해결 과제가 포함되어 있습니다.

• 비결정성과 구조적 프로그래밍의 균형
• 현실 검증(ground truth)과 루프 조기 종료 방지
• 다단계 에이전트 간의 데이터 교환 형식(JSON, SQL, Markdown 등)
• 토큰 할당과 비용 제어

이러한 문제들은 대규모 인프라가 없어도 실험 가능합니다. 개인 개발자도 수십 분 내에 반복적인 테스트를 수행하며 자신만의 접근법을 검증할 수 있습니다.

결국 LLM 에이전트를 직접 만들어보는 경험은 단순한 학습을 넘어, 기술을 ‘이해’하는 가장 빠른 길입니다.

---

728x90

직접 만들어보는 순간, LLM이 ‘보인다’

에이전트 개발은 복잡해 보이지만, 실제로는 단순한 루프 구조로 시작할 수 있습니다. 중요한 것은 이론이 아니라 직접 손으로 코드를 돌려보는 경험입니다.

OpenAI API를 이용해 기본적인 대화형 에이전트를 만들어보고, 여기에 도구 호출 기능을 추가해보면 LLM의 작동 원리와 한계를 자연스럽게 체감할 수 있습니다.

지금의 에이전트 기술은 여전히 진화 중이며, 개인의 실험이 그 발전의 한 축을 담당하고 있습니다. 직접 만들어보는 순간, LLM의 ‘블랙박스’가 조금씩 투명해집니다.

300x250

https://fly.io/blog/everyone-write-an-agent/

You Should Write An Agent