▲

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

 (fly.io)
2P by GN⁺ 8시간전 | ★ favorite | 댓글 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 기술 이해의 출발점임
▲
GN⁺ 8시간전  [-]
Hacker News 의견

  • 해야 할 게 정말 많음. NAND 게이트로 CPU를 브레드보드에서 직접 만들고 싶고, Rust로 CDN도 만들어보고 싶지만 시간이 부족함
    대신 Karpathy의 튜토리얼을 따라 LLM을 만들어봤는데, 이런 식으로 조금씩 실험해보는 게 꽤 괜찮다고 느낌

    • 끝이 없는 곡선 같음. 예전에 8비트 컴퓨터를 브레드보드로 만들었다가, 이번엔 비행 훈련(PPL)에 빠졌음
      항상 ‘이제 다 했다’ 싶을 때마다 결승선이 더 멀어지는 느낌임. 결국 우리 같은 사람들은 완전히 만족하지 못하는 부류인 듯함
    • TFA 초반부에서 얼마나 쉽게 할 수 있는지를 설명함. 그게 바로 글의 핵심 포인트임

  • 예시에서는 GPT-5를 사용하지만, 쿼리 인터페이스는 이미 산업 표준 수준임
    예를 들어 OpenRouter.ai를 연결하면 런타임 중에 모델과 제공자를 쉽게 바꿀 수 있음
    무료 모델(예: 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, llm

    • hubcap을 정말 좋아함. 코드가 적은데도 결과가 인상적이었음
      Simon Willison의 글을 보고 큰 영감을 받았음

  • 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 제공자가 될 수도 있음
    • 이 댓글에는 약간의 감정적 피로감이 느껴짐. 혹시 연차가 많은 개발자인지 궁금함

  • 컨텍스트 엔지니어링 부분이 특히 와닿음
    나는 개인 비서를 만들고 있는데, 일반 에이전트보다 기억, 작업 추적, 문제 해결 능력이 더 많음
    여러 에이전트가 서로 대화하며 문제를 해결하도록 설계했고, 첫 번째 에이전트는 작업 관리 감독자 역할을 함
    이 과정이 깊어질수록 점점 더 엔지니어링적인 문제로 변함
    자세한 내용은 내 블로그 글에 정리했음

    • 정말 멋진 프로젝트로 들림

  • 모두가 에이전트 만드는 건 좋아하지만 디버깅은 싫어함
    처음엔 마법처럼 잘 작동하다가, 점점 확률적 실패가 쌓이면서 재현이 어려워짐
    한 단계당 0.5초씩 걸리니, 어디서 틀렸는지 확인하려면 10~20분씩 기다려야 함

    • 그래서 나는 병렬 실행 도구를 만들어, 수정한 코드를 수백 번 돌려보고
      과거 시나리오도 다시 돌려서 아무 것도 깨지지 않았는지 검증함

  • 제공된 코드를 기반으로 MCP를 만들어봤음: gurddy-mcp.fly.dev
    소스 코드는 GitHub 저장소에서 볼 수 있음

답변달기