# 에이전트를 직접 만들어봐야 하는 이유 > Clean Markdown view of GeekNews topic #24202. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24202](https://news.hada.io/topic?id=24202) - GeekNews Markdown: [https://news.hada.io/topic/24202.md](https://news.hada.io/topic/24202.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-11-07T12:33:03+09:00 - Updated: 2025-11-07T12:33:03+09:00 - Original source: [fly.io](https://fly.io/blog/everyone-write-an-agent/) - Points: 51 - Comments: 2 ## Summary 요즘의 **LLM 에이전트** 논의는 복잡한 프레임워크보다, 직접 몇 줄의 **Python 코드와 OpenAI Responses API**로 만들어보는 실험에서 더 많은 통찰을 줍니다. 핵심은 **상태 없는 LLM과의 반복 호출 루프**를 스스로 설계하며, 대화 맥락을 어떻게 관리하고 도구 호출을 어떻게 통합할지 고민하는 과정 자체가 ‘컨텍스트 엔지니어링’의 본질이기 때문입니다. 거대한 MCP나 외부 프로토콜 없이도 **자율적 행동과 안전한 구조 설계**를 구현할 수 있다는 점은 특히 흥미롭습니다. 결국 이 글은 “뭔가를 이해하는 가장 빠른 방법은 직접 만들어보는 것”이라는 말을 상기시켜줍니다. ## Topic Body - **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 기술 이해의 출발점임 ## Comments ### Comment 46081 - Author: [hidden] - Created: 2025-11-09T00:37:42+09:00 - Points: 1 [숨김 처리된 댓글입니다] ### Comment 46031 - Author: neo - Created: 2025-11-07T12:33:04+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=45840088) - 해야 할 게 정말 많음. **NAND 게이트**로 CPU를 브레드보드에서 직접 만들고 싶고, Rust로 CDN도 만들어보고 싶지만 시간이 부족함 대신 Karpathy의 튜토리얼을 따라 LLM을 만들어봤는데, 이런 식으로 조금씩 **실험**해보는 게 꽤 괜찮다고 느낌 - 끝이 없는 곡선 같음. 예전에 8비트 컴퓨터를 브레드보드로 만들었다가, 이번엔 비행 훈련(PPL)에 빠졌음 항상 ‘이제 다 했다’ 싶을 때마다 **결승선이 더 멀어지는 느낌**임. 결국 우리 같은 사람들은 완전히 만족하지 못하는 부류인 듯함 - TFA 초반부에서 얼마나 쉽게 할 수 있는지를 설명함. 그게 바로 글의 핵심 포인트임 - 예시에서는 GPT-5를 사용하지만, 쿼리 인터페이스는 이미 **산업 표준** 수준임 예를 들어 [OpenRouter.ai](https://openrouter.ai/models?fmt=cards&order=pricing-low-to-high)를 연결하면 런타임 중에 모델과 제공자를 쉽게 바꿀 수 있음 무료 모델(예: DeepSeek)도 제공하지만 느리고 제한적임. 그래도 실험용으로는 훌륭함 - 몇 달 전 Ruby로 **에이전트**를 직접 만들어봤음. 정말 재미있었음 핵심 로직은 단 네 줄로, 개념적으로 놀라울 만큼 단순했음 ``` until mission_accomplished? or given_up? or killed? determine_next_command_and_inputs run_next_command end ``` - 2년 전 PHP 25줄로 에이전트를 만들었는데, 당시엔 **tool calling**도 없었지만 꽤 잘 작동했음 LLM은 내게 `sed`나 `awk` 같은 **UNIX 텍스트 조작 도구**처럼 느껴짐 — 입력과 명령을 주면 출력을 내놓는 구조임 이런 식으로 LLM 호출을 조합하고 루프나 분기를 만들면 꽤 강력한 시스템이 됨 관련 코드: [hubcap](https://github.com/dave1010/hubcap), [llm](https://github.com/simonw/llm) - hubcap을 정말 좋아함. 코드가 적은데도 **결과가 인상적**이었음 [Simon Willison의 글](https://simonwillison.net/2023/Sep/6/hubcap/)을 보고 큰 영감을 받았음 - Claude Code의 대안을 직접 만드는 부분이 특히 공감됨. **자기 개선형 코딩 에이전트**를 만드는 건 거의 마법 같은 경험임 모델을 자유롭게 교체할 수 있고, **Cerebras**처럼 빠른 모델을 쓰면 대화형 툴 호출에서도 큰 차이를 느낌 여기에 메모리, 음성 인식 등을 추가하면 훨씬 효율적임. 몇 분이면 구현 가능하고 정말 재미있음 - 어떤 음성 인식 모델을 쓰는지 궁금함. Whisper는 느리고 정확하지 않았고, GPT 오디오 모델은 **거부 응답**을 자주 함 Google 모델은 품질이 낮았고, Mistral 모델은 빠르지만 가끔 텍스트에 반응해버림 그래서 가끔 내가 한 말을 대신 LLM의 **의식의 흐름**으로 받아적는 경우가 생김 - “build your own lightsaber”라는 표현이 정말 마음에 듦 처음엔 내부 구조를 이해하려고 만들었는데, 생각보다 단순해서 이제는 내가 원하는 기능을 직접 추가 중임 팀 단위 제품보다 빠르게 기능을 넣을 수 있음. 에이전트는 **놀라울 만큼 단순한 구조**임 - 입문하려면 어디서 시작해야 할지 모르겠음. **Cerebras**가 뭔지도 처음 들음. 지금은 VS Code에서 Copilot만 사용 중임 이게 로컬 모델 기반인지 궁금함 - Cerebras는 이제 **glm 4.6**을 제공함. 여전히 엄청 빠르고, 이제는 훨씬 똑똑해짐 - 이 글을 보면 **Unix 철학** — 한 가지 일을 잘하는 도구 — 를 다시 만들고 싶어짐 에이전트를 단순하게 만들 뿐 아니라 보안성도 높아짐 - 2021년에 네트워크 연결을 테스트하는 에이전트를 만들었는데, **ping, dig, traceroute** 같은 기본 도구를 에이전트에 맡기면 꽤 괜찮은 결과를 냄 사람이 직접 만든 텔레메트리 시스템보다 완벽하진 않지만, **90% 수준의 유용성**을 훨씬 쉽게 달성할 수 있었음 - 인간에게 직접 노출되는 **제한된 목적의 도구 모음**을 상상해볼 수도 있음 - 한 가지 일을 잘하려면 더 많은 도구가 필요하고, 그만큼 **맥락 이해력**이 커짐 LLM의 이상적인 크기는 전통적인 Unix 도구보다 약간 더 큰 중간 지점일 것 같음 - “에이전트를 꼭 만들어야 하나?”라는 의문이 듦. 모든 AI 제공자가 적자를 보고 있는 상황에서 **지속 가능한 수익 모델**이 가능할지 회의적임 - 직접 만들어보면 에이전트의 작동 원리와 한계를 **직관적으로 이해**할 수 있음. 그게 핵심임 - 이건 단순히 기술을 **재미로 실험**하는 글임. 수익화와는 무관함 Python을 쓰지 않겠다는 이유로 Astral의 적자를 드는 것과 비슷한 논리임 - AI 기업들이 전부 적자를 내는 건 아님. 다음 모델 훈련 비용이 커서 자금이 필요한 것이지, **추론 단계는 수익성**이 있음 - 직접 **AI 제공자**가 될 수도 있음 - 이 댓글에는 약간의 **감정적 피로감**이 느껴짐. 혹시 연차가 많은 개발자인지 궁금함 - **컨텍스트 엔지니어링** 부분이 특히 와닿음 나는 개인 비서를 만들고 있는데, 일반 에이전트보다 **기억, 작업 추적, 문제 해결 능력**이 더 많음 여러 에이전트가 서로 대화하며 문제를 해결하도록 설계했고, 첫 번째 에이전트는 **작업 관리 감독자** 역할을 함 이 과정이 깊어질수록 점점 더 **엔지니어링적인 문제**로 변함 자세한 내용은 [내 블로그 글](https://ooo-yay.com/blog/building-my-own-personal-assistant/)에 정리했음 - 정말 멋진 프로젝트로 들림 - 모두가 에이전트 만드는 건 좋아하지만 **디버깅은 싫어함** 처음엔 마법처럼 잘 작동하다가, 점점 **확률적 실패**가 쌓이면서 재현이 어려워짐 한 단계당 0.5초씩 걸리니, 어디서 틀렸는지 확인하려면 10~20분씩 기다려야 함 - 그래서 나는 **병렬 실행 도구**를 만들어, 수정한 코드를 수백 번 돌려보고 과거 시나리오도 다시 돌려서 아무 것도 깨지지 않았는지 검증함 - 제공된 코드를 기반으로 **MCP**를 만들어봤음: [gurddy-mcp.fly.dev](https://gurddy-mcp.fly.dev) 소스 코드는 [GitHub 저장소](https://github.com/novvoo/gurddy-mcp)에서 볼 수 있음