▲

LLM 에이전트 루프와 도구 사용의 비합리적 효율성

 (sketch.dev)
1P by GN⁺ 7일전 | ★ favorite | 댓글 1개
  • AI 프로그래밍 도우미인 Sketch의 개발 경험을 통해 LLM과 도구 사용을 결합한 루프 구조의 간결한 구현을 강조함
  • 단 9줄짜리 루프 코드만으로 Claude 3.7 Sonnet 모델 등 최신 LLM이 실질적인 문제를 신속히 해결함
  • bash 등 범용 도구 하나만 있어도, 개발자의 반복적이고 까다로운 작업을 상당 부분 자동화할 수 있음
  • 문제 해결뿐 아니라, 추가적인 도구를 연결해 텍스트 편집이나 특화된 작업의 품질과 반복 속도를 높일 수 있음
  • 점점 더 많은 맞춤형 LLM 에이전트 루프가 개발자의 일상 자동화에 도입되는 추세임

서론: 개발 경험과 Sketch 프로젝트

  • 필립 젤리거 및 동료들은 AI 기반 프로그래밍 보조 도구 Sketch를 개발하는 과정에서, LLM과 도구 활용을 결합한 단순한 에이전트 루프 구조의 높은 효율성에 놀라움을 느낌
  • 핵심 구조는 단 9줄짜리 루프 코드로, 시스템 프롬프트와 대화 기록, 최신 메시지를 LLM API에 전달함
  • LLM이 출력을 생성하고 필요한 경우 tool_calls(도구 호출 요청)를 반환함

LLM과 도구 사용의 통합

  • "도구 사용(tool use)"이란 LLM이 미리 정의된 스키마에 맞는 출력을 반환하고, 시스템 프롬프트와 도구 설명 프롬프트를 통해 LLM이 bash와 같은 범용 도구에 접근할 수 있게 함
  • 최신 LLM(예: Claude 3.7 Sonnet)은 단일 범용 도구만으로도 다양한 문제를 빠르게 자동화하며, 일부는 한 번의 실행("one shot")으로도 해결 가능함
  • 이전에는 복잡한 git 명령어를 찾아 붙여넣고 수동으로 병합 작업을 했으나, 이제는 Sketch에 요청해 바로 해결 가능함
  • 타입 변경 후 발생하는 다수의 타입 체크 오류도 Sketch가 처음으로 자동 처리해줌
  • 에이전트 루프는 지속적이며 적응적으로 작동해, 도구 미설치 시 자동 설치·명령어 옵션 차이에도 맞춤 대응함
  • 사용 중 LLM이 테스트 실패 시 "테스트 건너뛰기"처럼 예기치 않은 제안할 때도 있지만, 전체적으로 업무 자동화의 질이 향상됨

도구의 다양화와 특화

  • Sketch는 bash 외에도 추가적인 도구들(c.f. 텍스트 편집 도구)을 활용하면, 작업 품질을 높이고 개발 워크플로우가 더욱 효율적임을 경험함
  • LLM이 sed 등으로 텍스트를 정확히 수정하는 일은 예상보다 까다로우며, 시각적(visual) 에디터 방식의 도구가 더 뛰어남을 체감함

미래 전망과 워크플로우 변화

  • 에이전트 루프 구조는 기존의 범용 자동화 도구로 다루기 힘들었던, 개발자 일상의 반복 작업에 점점 더 많이 활용될 전망임
  • 예시로, 스택 트레이스와 git 커밋 상관관계 분석처럼 번거롭고 반복적인 작업도 LLM이 빠르게 1차 처리를 수행함
  • 앞으로 더 많은 맞춤 제작, 일회성 LLM 에이전트 루프가 개발자의 bin/ 디렉토리 등에서 사용될 것으로 기대할 수 있음
  • 사용자들은 원하는 bearer token만 준비해 자신의 환경에서 쉽게 실험할 수 있음

참고 링크

▲
GN⁺ 7일전  [-]
Hacker News 의견
  • 이 블로그 글도 강력하게 추천하고 싶음. 같은 논점을 훨씬 더 자세하고 설득력 있게 다루는 버전임. 글쓴이가 실제로 직접 코딩 에이전트를 처음부터 만들어봄. https://ampcode.com/how-to-build-an-agent 참고. LLM이 툴을 호출할 수 있는 루프에서 얼마나 다양한 작업을 잘 처리하는지 정말 놀라운 경험임. 물론 완벽하지는 않고, 신뢰성 100%에 도달하지 못하는 문제 등이 있긴 함. 그래도 적어도 조금은 경탄할 만한 부분이 있다고 생각됨. 이런 걸 직접 해보면 30분 안에 따라 할 수 있음. AI가 특정 용도에 효과적인지에 대한 건전한 의심을 놓치지 않으면서도 경이로움을 느낄 수 있는 부분임. LLM을 루프에 두는 이 "비정상적인 효과"가 지금 수많은 코드 생성 에이전트가 쏟아지는 이유임: Claude Code, Windsurf, Cursor, Cline, Copilot, Aider, Codex 등등, 게다가 따라 만드는 프로젝트도 아주 많음. 특별한 비법이 없는 이유이고, 마법의 95%는 결국 LLM 자체와 툴 호출을 하도록 파인튜닝된 것임. Claude Code의 주요 개발자가 최근 인터뷰에서 솔직하게 인정한 사실임. 물론 이런 도구들이 잘 작동하게 하려면 많은 노력이 들어가지만, 근본적으로 거의 같은 단순한 코어 구조임
    • 이런 글을 무척 오랫동안 찾고 있었는데 정말 고마움이라는 느낌임. 많은 사람들이 Agents를 보고 "아마 정말 복잡한 문제는 잘 못 풀겠지?"라고 반응하지만, 내가 보기엔 에이전트의 핵심 논점은 거기에 있지 않음. LLM은 많은 컨텍스트 안에서 정말 잘 작동하고, 에이전트는 LLM이 더 많은 컨텍스트를 찾아서 질문에 대한 답변 품질을 증진하는 구조임
    • LLM이 혼자서 루프 안에서 몇 번 이상 지시 없이 잘할 수 있는 작업이 별로 생각나지 않는 경험임. 몇 번 반복하다보면 꼭 내가 개입해야 할 상황이 생김
    • pocketflow라는 그래프 추상화 라이브러리를 사용해서 비슷한 걸 만든 튜토리얼이 있음. 실제로 써봤는데 상당히 심플해서 아주 만족했음. https://github.com/The-Pocket/PocketFlow-Tutorial-Cursor/…
    • Thorsten Ball 글쓴이임을 이제야 알아차림. 그의 "interpreter 만들기" 정말 재밌게 읽었던 기억임. 아마 나도 이제 에이전트 만들어볼 계획임
    • 위 링크를 열기 전에 ?utm_source=hn&utm_medium=browser를 추가해야 할지 고민임
  • 오늘 처음으로 GPT-4o와 4.1로 직접 "vibe-coding"을 시도해봤음. 수작업으로 컴파일 에러와 경고, 제안을 캔버스 인터페이스를 통해 루프 돌리며 입력하는 방식이었음. 파일은 150줄 정도로 작았음. 4o로 시작했는데, 구식 패키지를 사용. 내가 그 부분을 지적해도 모든 용도를 업데이트하지 않고, 직접 손봐야 했음. 논리 변경을 제안하니 완전히 문법이 망가지는 상황이 생겼고, 다시는 회복 못했음. 계속 컴파일 에러를 입력해도 문법 문제를 이해하지 못하고 코드의 랜덤 부분만 고쳐버림. 그래서 4.1이 더 잘할까 기대했지만, 4.1은 캔버스 사용 자체를 거부하고 그냥 설명만 해줌. 직접 수정하라는 스타일임. 계속 설득해서 겨우 캔버스에 코드를 뽑았더니 이번에는 중간이 "// omitted for brevity" 같이 잘린 버전이라 쓸 수 없었음. 여기서 포기함. 에이전트들이 이 문제를 해결해주는지 궁금함. 현재로선 이 경험이 완전히 망가져 있다는 생각이고, 그런 상태에서 bash 접근권을 주는 건 너무 위험하다는 우려임
    • "구식 패키지를 썼다"는 점은 모델의 학습 데이터 시점이 잘려있기 때문임. LLM 쓸 때 꼭 주의해야 하는 부분임. ChatGPT에서 o4-mini-high로 많이 전환해서 쓰고 있음. 이 모델은 서치 기능으로 최신 문서도 찾을 수 있음. "X 라이브러리 최신 버전 조회해서 써달라" 요청하면 종종 잘 처리함. 최근, 자바스크립트 코드 일부를 최신 Google 권장 라이브러리로 변환하는 작업이 있었는데, 직접 이전 코드를 붙여넣고 새 라이브러리로 포팅해달라고 요청하니 문서도 찾아보고 정확히 포팅해 주었음. https://simonwillison.net/2025/Apr/…
    • GPT 4.1과 4o가 Aider 코딩 벤치마크에서 점수가 매우 낮게 나옴. 실사용 경험상 70% 이상은 되어야 결과물이 쓸모있게 나옴. 그래도 복잡한 건 상당한 보조가 필요함. 무엇이 잘되는지, 안되는지 쓰다보면 감이 생김. https://aider.chat/docs/leaderboards/
    • "실력 문제"라는 말이 듣기 싫을 수 있지만, LLM을 쓰는 건 확실히 별도의 숙련이 필요한 분야임. 다양한 도구의 장단점을 이해하고, 여러 기법을 실험하고, 연습이 필수 구성임. 만약 bash 접근을 준다면 나도 컨테이너 환경(docker)에서만 쓸 예정임
    • 그건 vibe coding이라 할 수 없음. 코드 변경이 자동 반영되는 도구를 써야 vibe coding이 가능함. 수동으로 하나씩 피드백 주다보면 오류에 막혀 멈추게 됨. vibe coding의 핵심은 되돌리기, 재실행, 다양한 해법을 쉽게 던지고 버릴 수 있다는 점임. 이런 경험을 하려면 툴링이 필요함
    • 얼마 전 Cline 플러그인과 Claude로 VSCode에서 Android 앱 프로토타입을 "제로베이스"부터 만들었음. Android Studio가 주는 기본 템플릿에서 시작했고, 수천 줄짜리 코드를 생성했는데 단 한 줄도 컴파일 에러가 없었음. 앱은 기대한 대로 동작했고, 발견된 몇 개의 버그도 LLM 탓이 아니라 기괴한 Android API 동작 때문이었음. LLM에게 버그를 지적하고, 디버그 메시지 출력을 제공하니 직접 고쳐주었음. 처음엔 수정이 좀 엉성했지만, 몇 번 피드백 주고받으니 괜찮게 해결됨. 코드 작성 에이전트와 코드 리뷰 에이전트를 루프에 돌리면 이런 부분도 더 일반적으로 잘 다룰 수 있을 것 같음
  • Claude Code, 즉 Sonnet 3.7의 터미널 인터페이스를 출시 첫날부터 써왔음. 상당한 규모의 CLI 앱, 풀스택 웹 시스템, 수많은 유틸리티도 작성해봄. 예전 프로그래밍 팀 리드할 때와 비슷하게 더욱 야심찬 도전을 하게 됨. 구조적으로는 다른 툴들과 별반 다르지 않겠지만, Anthropic이 엄청 유용한 기능을 다수 추가한 느낌임. 완벽한 건 없고, 좋은 코드 퀄리티는 지금도 그때처럼 비슷한 노력이 필요함. 꽤 복잡한 것들도 작동은 되는데, 다음 기능 추가가 어려워지는 상황도 종종 있음. 다루는 법이 익숙해지니 리팩토링, 보완 과정이 훨씬 줄었음. 완전히 없어지진 않을 구조임. kgeist가 겪은 문제는 솔직히 상상하기 힘듦. Claude도 때로는 내 선택과 다르거나 멍청한 동작을 하지만 포기하고 싶을 정도는 한번도 아니었음. 거의 항상 괜찮은 결과를 보여주고, 많은 작업을 뇌에서 덜어주는 정도가 엄청남. 게다가 리팩토링을 매우 훌륭하게 해냄. 주기적으로 코드를 보면서, 더 좋을 방법을 Claude에게 설명시키면 복잡함이 확 줄어듦. "데이터 구조 변경" 같은 요청도 바로 해결됨. 굉장히 멋진 기능임. 그리고 재미로 코드가 아닌 잡동사니가 쌓인 30년짜리 아카이브 디렉토리를 열어봤음. "이 디렉토리에 뭐가 있지?", "옛 이력서 읽고 새로 써줘", "내 아이들 이름 뭔지?" 등등 물어봐도 정말 놀라움. 아직 초기 단계임에도 정말 행복함
    • 최근 원격 데이터 구조 정의, API 명세, 파싱 및 저장 구현, 사용자에게 보여주기까지 모두 한번에 처리해야 하는 상황이 있었음. Claude가 이 모든 작업을 동시에 잘 관리해주어, 양쪽 끝의 작은 변경이 중간 계층에 어떤 영향을 주는지 즉각적으로 볼 수 있었음. 여러 아이디어를 빠르게 반복하면서 최적의 해법을 찾아감. 이처럼 복잡도가 높은 여러 계층을 빠른 반복 속도로 탐색해볼 수 있다는 점이 놀라웠고, 생산성 향상과 동시에 전체 시스템의 구조적 이해도를 높여줌
    • 위에 언급된 리팩토링이 정말 즐거운 작업임. 예전엔 스프린트에 포함시키기도 힘들던 기능들도 5분 만에 끝남. 마치 준비된 팀이 언제든 내 요구만 기다리는 느낌임. 결과가 마음에 안 들면 바로 거절해도 되고, 불필요한 검토와 일정 잡기 걱정도 모두 사라진 듯함
  • "아, 이 테스트 안되네... 그냥 건너뛰자"라고 LLM이 종종 말하는 상황이 너무 답답함. 여기 생각해볼 아이디어가 있음. 메인 LLM이 지시대로 동작하도록 독립적이고 병렬적인 폴리시-강제 LLM을 같이 띄우는 방식임. 예를 들어, 보조 LLM이 "let's just" 다음에 "skip"이란 단어는 나오지 못하게 출력 확률을 조작함. 즉, "skip"을 금지하면 LLM이 원하지 않는 행동에서 벗어나게끔 경로를 바꿀 수 있음. 일종의 JSON 모드나 구조화된 출력처럼 동작하되, 동적으로 실시간으로 보조 LLM이 정책을 제어하는 방식임. 이게 잘 된다면, 더 발전시켜서 테스트 통과를 위해 테스트 코드를 삭제한다든지 쓸모없는 주석 출력 등 다양한 정책 위반을 모두 보조 LLM 쪽 프롬프트에 넣고, 보조 LLM이 실시간으로 감시하고 제어하는 구조로 확장 가능함. Outlines 팀이 이런 구조에 대해 어떻게 생각할지 궁금함
    • 만약 LLM 하나가 다른 LLM의 출력을 체크할 수 있다면, "mixture of experts" LLM이 한 전문 알고리즘을 감시·감사하는 역할에 할당할 수도 있지 않을까 하는 의문임. 또는 별도의 사고 쓰레드를 분리해서 자기 자신의 출력을 검증하게 하거나, 또 필요하다면 그 검증자도 검증하는 또다른 쓰레드를 두는 식으로 체계를 더욱 단단히 할 수 있을 것임
    • 이런 맥락에서, 메인 LLM이 잘못된 방향으로 가면 감시 LLM이 해당 시점까지 모델을 "rewind"해서, 예를 들어 "let's just skip the test"를 감지하면 "just " 이후로 롤백한 뒤 특정 단어들이 안 써지도록 bias를 계속 걸어주는 구조도 생각할 수 있음. 이런 작업을 하려면 사용하는 모델 제공자가 제한적이 될 수 있고, 특히 OpenAI는 최근 이런 파워유저 기능에 적대적인 경향이 보이고 있음
  • 오늘 아침 cursor로 게임 프로토타입의 메인 루프에서 복잡한 일부를 추출하고, 그 파트를 위한 테스트 코드 세트를 자동 생성함. 전체 341개의 테스트가 core math 및 핵심 컴포넌트 전체를 커버함. 때론 캣헤딩 같은 느낌이지만, 구체적으로 사용할 함수, 위치, 템플릿 파일, 피해야 할 것 등 더 많은 제약을 줄수록 결과가 점점 좋아짐. 총 3500줄의 테스트 코드를 내가 직접 쓸 필요 없이, 문제 발생 시 언제든 지우고 다시 생성할 수 있음. 난이도 곡선 튜닝, 미션 변주 등 정말 다양한 부분도 도움 받음
    • 내 경험상, 테스트 자동 생성이 LLM의 최고 활용 사례임. 지루하고 반복적인 노동이 몇 시간 또는 며칠이 들어가는 부분을 한 번에 없애줌. 내가 떠올릴 수 없는 많은 엣지 케이스도 자동 커버되고, 코드 안전성까지 증가함. 정말 다방면에서 훌륭한 기능임
  • 요즘 LLM의 툴 사용 능력에 굉장히 흥분되는 느낌임. 사실 이 트릭은 새로운 게 아니고, 2년 전 ReAcT 논문에서 처음 접함. 이후 ChatGPT 플러그인, MCP 등에서 활용됐고, 이제 대부분 모델이 툴콜/함수 호출을 염두에 두고 학습됨. 현재 흥미로운 점은 성능이 얼마나 좋아졌냐는 부분임. o3/o4-mini의 뛰어난 검색 성능도 툴콜 능력이 바탕임. Qwen3 4B (Ollama 2.6GB, 맥에서도 잘 돌아감)도 이 기능을 잘 수행함. 어제 PyCon US에서 LLM 기반 소프트웨어를 만드는 워크샵을 진행했고, 그 계기로 내 LLM 커맨드라인 툴에 툴 사용 기능을 추가함. https://building-with-llms-pycon-2025.readthedocs.io/en/latest/… 참고. 이제 내 LLM 패키지로 "딸기(strawberry)에서 R이 몇 번 나오는지 세기" 같은 걸 셸 원라이너로 안정적으로 처리할 수 있음
    • 이 기능이 주는 유쾌함과 강력함의 이상한 조합이 너무 좋음
    • 워크샵이 녹화됐는지 궁금함
  • 어떤 agent가 토큰을 가장 많이 사용하는지 궁금증임. cline이 리스트 상위권이고, roo는 cline보다 덜 사용하는 것 같음. 상호작용 방식을 직접 설정할 수 있는 agent가 있는지, Claude code가 다른 agent와 비교해 어떤지 알고 싶음
  • "필요한 툴이 없으면 설치한다"는 점이 무서운 포인트임. LLM이 지나치게 '순종적'이고, 누가 시키기만 하면 바로 실행하는 구조임. 이건 SQL injection보다 더 심각한 보안 우려임
    • 언제 첫 agent 기반 재앙이 터질지 종종 궁금함. (특히 급하게 쏟아져 나오는 AI 시장 분위기라서) 시간이 지나면 반드시 돌이키기 힘든 재앙이 일어날까봐 우려임
  • 제목이 Eugene Wigner의 논문 "The Unreasonable Effectiveness of Mathematics in the Natural Sciences"에서 착안한 것 같음
    • 이 논문이 원조일 수 있지만, 이미 오래 전부터 밈이 된 관용어라고 봄. https://scholar.google.com/scholar?q=unreasonable+effectiveness
    • 난 오히려 Karpathy의 2015년 "Unreasonable Effectiveness of RNNs"에서 제목을 따온 줄 알았음. 물론 Karpathy 역시 Wigner 논문에서 재차 차용했을 것이란 추정도 가능함. https://karpathy.github.io/2015/05/21/rnn-effectiveness/
    • 매번 "unreasonable effectiveness"란 헤드라인을 보면 저자의 결론에 항상 강하게 동의 못하는 경험이 있음. Wigner의 논문 포함해서. 이제 일종의 Betteridge 법칙같은 느낌임
  • 우리는 자사 제품 내 임베디드 ai 챗봇에 더 많은 컨텍스트를 주기 위해 도구를 구축함. 최근 활동 로그, 현재 객체 정의, 검색 및 헬프 아티클 탐색 등 여러 기능을 추가함. 몇 달이 지난 지금도 챗봇 품질이 여전히 놀라움. 만약 챗봇이 뭔가 잘못 응답하면, 관련 헬프 아티클을 더 구체적으로 업데이트하는 프로세스임
답변달기