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

4 hours ago 1

LLM 에이전트는 단순히 개념으로 이해하기보다 직접 구현해봐야 작동 원리를 체감할 수 있는 기술 구조
불과 수십 줄의 Python 코드로 OpenAI Responses API를 이용해 대화형 에이전트를 만들 수 있으며, 여기에 도구 호출(tool call) 기능을 추가하면 자율적 행동이 가능
에이전트의 핵심은 상태 없는 LLM과의 반복 호출 루프이며, 대화 맥락(context)을 직접 관리함으로써 다중 회차 대화를 구현
Context Engineering은 실제 프로그래밍 과제 수준의 문제로, 토큰 한계 내에서 입력·출력·도구 설명을 최적화하는 설계 필요
현재 에이전트 설계는 열린 소프트웨어 공학 문제 공간으로, 개인 개발자도 실험을 통해 새로운 접근을 시도할 수 있는 영역

에이전트 작성의 단순함

LLM 에이전트는 복잡한 설정 없이 OpenAI Responses API 하나로 구현 가능
- 예시 코드에서는 context 리스트를 통해 사용자와 모델의 대화를 저장하고, 이를 반복 호출하여 ChatGPT와 같은 대화형 응답 생성
“좋은 성격”과 “나쁜 성격”을 가진 두 개의 컨텍스트를 만들어 다중 인격 대화를 시뮬레이션할 수 있음
- LLM은 상태가 없으며, 대화의 연속성은 사용자가 관리하는 문자열 배열(context) 로 유지됨
이 단순한 구조만으로도 다중 회차 대화가 가능하며, LLM의 작동 원리를 직접 체험할 수 있음

도구(tool) 통합과 자율적 동작

에이전트에 ping 함수를 도구로 등록해 네트워크 연결 상태를 점검하는 기능 추가
- OpenAI API는 JSON 형식으로 도구 정의를 요구하며, LLM이 필요 시 도구 호출을 요청하면 Python 코드가 이를 실행하고 결과를 다시 전달
LLM은 명시적 지시 없이도 여러 호스트(google.com, www.google.com, 8.8.8.8)를 자동으로 ping함
- 이는 LLM이 “도구 사용 권한”만으로도 자율적 판단을 수행했음을 보여줌
전체 루프는 단순히 “도구 호출 요청 → 실행 → 결과 반환” 구조로, 복잡한 제어 로직 없이도 자율적 에이전트 동작 구현 가능

실제 응용과 MCP 비판

예시 코드는 단순하지만, 여기에 추가 도구(traceroute 등) 나 SQLite 기반 컨텍스트 저장을 결합하면 실용적 확장 가능
MCP(Multi-Context Protocol) 은 Claude Code나 Cursor의 플러그인 인터페이스일 뿐, 필수 기술이 아님
- 직접 API를 다루면 MCP 없이도 동일한 기능 구현 가능
MCP는 코드 제어권이 없는 환경에서만 유용하며, 오히려 에이전트 아키텍처의 유연성을 제한할 수 있음
LLM 보안은 복잡하지만, 분리된 컨텍스트와 도구 제한을 통해 안전한 구조 설계 가능

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

“프롬프트 엔지니어링”은 과장된 개념이지만, 컨텍스트 엔지니어링은 실제 프로그래밍 문제
- 컨텍스트 윈도우 내 토큰 수는 제한되어 있으며, 입력·출력·도구 설명이 모두 공간을 차지
- 이 한계를 넘으면 모델의 응답 품질이 불안정해짐
해결책으로 서브 에이전트(sub-agent) 를 만들어 각기 다른 컨텍스트와 도구를 부여하고, 서로 요약·교환하도록 설계 가능
- 이러한 구조는 트리형 에이전트 네트워크나 실시간 요약 기반 압축 등 다양한 실험으로 확장 가능
복잡한 아이디어라도 30분 내 구현 가능한 수준의 단순성을 가짐

열린 공학 문제와 실험의 가치

현재 수많은 스타트업이 취약점 탐지용 에이전트를 개발 중이며, 개인 개발자도 동일한 실험 가능
에이전트 설계는 다음과 같은 미해결 공학 과제를 포함
- 비결정성과 구조적 프로그래밍의 균형
- 현실 검증(ground truth)과 루프 조기 종료 방지
- 다단계 에이전트 간 데이터 교환 형식(JSON, SQL, Markdown 등)
- 토큰 할당과 비용 제어
이러한 문제들은 대규모 연구가 아닌 개인 단위 실험으로도 탐구 가능한 영역이며, 각 반복은 수십 분 내 시도 가능
결론적으로, 직접 에이전트를 만들어보는 경험이 LLM 기술 이해의 출발점임

Read Entire Article