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

• AI 프로그래밍 어시스턴트 Sketch 개발에서 가장 놀라운 점은, 도구 사용을 붙인 LLM 에이전트가 9줄 수준의 단순한 루프로도 강력하게 동작한다는 점임
• 기본 흐름은 사용자 입력을 LLM에 보내고, 응답에 도구 호출이 있으면 실행 결과를 다시 대화에 넣어 다음 판단에 쓰는 방식임
• 시스템 프롬프트와 대화 이력, 도구 설명만으로도 LLM은 정해진 스키마에 맞춰 bash 같은 도구를 호출할 수 있음
• Sketch는 Claude 3.7 Sonnet과 bash만으로 git 작업, merge 1차 처리, 타입 체커 오류 수정 등을 수행하지만, 테스트를 건너뛰려는 답답한 행동도 보임
• 개발자 워크플로에 맞춘 추가 도구와 임시 에이전트 루프가 늘어나면, 기존 자동화로 다루기 어려웠던 일상 작업을 더 많이 맡길 수 있음

---

9줄에 가까운 에이전트 루프

• Sketch는 최근 몇 달간 개발 중인 AI 프로그래밍 어시스턴트임
• 핵심 루프는 사용자 입력을 받고 LLM 호출 결과를 확인한 뒤, 도구 호출이 있으면 실행 결과를 다음 메시지로 넣고, 없으면 다시 사용자 입력을 받음
• 전체 구현에는 부가 코드가 필요하지만, 핵심 아이디어는 9줄짜리 루프에 가까움
  • 전체 스크립트: agent_loop.py
• llm() 함수는 시스템 프롬프트, 지금까지의 대화, 다음 메시지를 LLM API로 보내는 역할을 함
• 도구 사용은 LLM이 특정 스키마에 맞는 출력을 반환하는 방식임
  • 전체 스크립트에서는 시스템 프롬프트와 도구 설명 프롬프트를 통해 LLM이 bash에 접근할 수 있음을 알려줌

Sketch로 확인한 가능성과 한계

• bash라는 범용 도구 하나만으로도 현재 모델, 특히 Claude 3.7 Sonnet은 여러 개발 작업을 처리할 수 있음
  • 난해한 git 작업을 찾아보고 복사해 붙여넣는 대신 Sketch에 요청할 수 있음
  • git merge를 수동으로 처리하기 전에 Sketch가 1차 시도를 맡을 수 있음
  • 타입 변경 뒤 발생하는 타입 체커 오류를 하나씩 고치는 작업도 Sketch에 맡겨볼 수 있음
• 적절히 프롬프트하면 에이전트 루프는 지속적으로 동작함
  • 필요한 도구가 설치돼 있지 않으면 설치함
  • grep의 명령줄 옵션이 환경마다 다르면 그 차이에 맞춰 적응함
• 한계도 뚜렷함
  • 테스트가 통과하지 않자 그냥 건너뛰려는 식의 행동이 나올 수 있음
• Sketch는 bash만 쓰지 않고, 품질과 반복 속도, 개발자 워크플로를 개선하기 위해 몇 가지 추가 도구를 사용함
• LLM이 텍스트를 정확히 편집하게 만드는 도구는 의외로 까다로움
  • LLM이 sed 한 줄 명령에서 고전하는 모습은 시각적 편집기가 줄 단위 편집기와 다른 강점을 갖는다는 점을 보여줌
• 에이전트 루프는 일반 목적 도구로는 너무 구체적이고, 전통적 자동화로는 너무 난해하거나 불안정했던 일상 자동화 작업에 더 많이 들어갈 수 있음
  • 스택 트레이스와 git 커밋을 연결하는 작업은 LLM이 1차 처리를 잘할 수 있는 예임
  • 맞춤형·임시 LLM 에이전트 루프가 bin/ 디렉터리에 더 많이 생길 수 있음

[GN⁺]

Hacker News 의견들

• 같은 요지를 훨씬 더 자세하고 설득력 있게 보여주는 이 글도 강력 추천함. 저자가 실제로 코딩 에이전트를 처음부터 만들어 봄: https://ampcode.com/how-to-build-an-agent
  도구를 호출할 수 있는 LLM을 반복문 안에 넣는 것만으로도 온갖 작업에서 지금처럼 잘 동작한다는 게 정말 놀라움. 가끔 폭주하고 마지막 10% 신뢰성을 확보하는 문제가 있지만, 조금도 놀랍지 않다면 30분 정도 들여 직접 이런 걸 대충 만들어 보길 권함.
  AI가 특정 용도에 실제로 효과적인지에 대한 건전한 회의심을 유지하면서도, 이런 것들에 대한 경이감은 가질 수 있음. LLM을 루프에 넣었을 때의 비합리적인 효과가 Claude Code, Windsurf, Cursor, Cline, Copilot, Aider, Codex 같은 수많은 코딩 에이전트가 쏟아지는 이유이기도 함.
  비밀 소스가 있는 게 아니라 마법의 95%는 LLM 자체와 도구 호출에 맞춘 미세조정에 있고, Claude Code의 주요 개발자도 최근 인터뷰에서 이를 솔직히 인정함.[0] 물론 이런 도구를 잘 만들려면 엄청난 작업이 들어가지만, 결국 핵심은 모두 단순함.
  [0] https://www.youtube.com/watch?v=zDmW5hJPsvQ

  • LLM이 이런 방식으로 효과적일 때는 보통 제공된 도구만으로 더 효율적인 비-LLM 해법이 존재한다는 뜻임. LLM은 입력과 출력의 합성, 그리고 필요한 단계의 순서를 찾아주는 역할을 함.
    LLM이 매번 도구를 써서 문제를 푸는 건 비싸고 느림. 다음 단계는 자주 나오는 도구 호출 패턴을 하나의 순수 함수로 바꾸고, 입력과 출력 변환을 그 안에 넣은 뒤, 간단하고 싼 분류기를 학습시켜 새 함수로 바로 보내 LLM을 완전히 우회하는 것임.
    시간이 지나면 LLM은 점점 덜 쓰이고, 분류할 수 없는 새로운 문제에만 제한적으로 쓰이게 될 것임. 문제 형태를 키로 삼는 LLM 문제풀이 캐시에 가까움.
    같은 문제를 같은 방식으로 24시간 풀게 LLM을 돌리는 시대는 먼 기억이 되어야 함. 다만 API 호출을 최대한 많이 팔고 싶은 AI 회사는 사람들이 그런 미래를 상상하길 원하지 않을 것임. 이상적으로는 새로운 문제마다 LLM을 한두 번만 쓰고 더 싼 코드로 대체해야 함
  • 처음 링크한 글의 Ruby 포트도 있음. 기능은 거의 같지만, 나처럼 Python보다 Ruby를 더 좋아한다면 두 글을 모두 읽을 만함:
    https://news.ycombinator.com/item?id=43984860
    https://radanskoric.com/articles/coding-agent-in-ruby
  • LLM이 몇 번 이상 반복문 안에서 스스로 하게 둘 만큼 충분히 잘하는 일을 딱히 떠올리기 어려움. 몇 번 돌리면 다시 내가 잡아줘야 함
  • PocketFlow라는 그래프 추상화 라이브러리로 비슷한 걸 만드는 글도 있음[0]. 직접 써보고 있는데 단순해서 마음에 듦.
    [0] https://github.com/The-Pocket/PocketFlow-Tutorial-Cursor/blo...
  • 아, Thorsten Ball이었구나. “Writing an Interpreter”를 정말 재밌게 읽었으니, 이제 에이전트를 만들어 보게 될 듯함

• 오늘 처음으로 GPT-4o와 4.1로 바이브 코딩을 해봤음. 자동 에이전트가 아니라 canvas 인터페이스에 컴파일 오류, 경고, 제안을 반복해서 직접 넣는 방식이었고, 파일은 약 150줄로 작았음.
  결과는 좋지 않았음. 4o는 deprecated 패키지를 썼고, 그걸 지적해도 모든 사용처를 고치지 않아 직접 수정해야 했음. 작은 로직 변경을 제안했더니 foo() } return ))) 같은 수준으로 문법을 완전히 망가뜨리고 회복하지 못함.
  원시 컴파일 오류를 계속 넣어도 문법이 틀렸다는 사실 자체를 인식하지 못하고 코드의 엉뚱한 부분만 다시 작성했음. 4.1은 코딩에 더 낫다길래 시도했지만 canvas 사용을 거부하고 “이렇게 바꾸면 된다”는 설명만 했음.
  밀어붙여서 canvas를 쓰고 전체 코드를 돌려받게 했더니, 이번엔 // omitted for brevity 같은 주석이 들어간 잘린 코드를 줬고, 거기서 포기함. 에이전트가 이런 걸 어떻게 고치는지 모르겠고, 지금 경험으로는 완전히 망가진 느낌임. 여기에 bash 접근 권한을 주는 건 너무 위험해 보임

  • “deprecated 패키지를 썼다”는 건 모델에 학습 기준일이 있기 때문임. LLM으로 작업할 때는 그걸 고려하는 게 중요함: https://simonwillison.net/2025/Mar/11/using-llms-for-code/#a...
    요즘은 ChatGPT에서 o4-mini-high를 많은 코드 작업의 기본 모델로 쓰고 있는데, 검색 기능으로 최신 문서를 찾아볼 수 있기 때문임.
    “라이브러리 X의 최신 버전을 찾아서 그걸 사용해”라고 말하면 꽤 자주 잘 동작함. 최근 짜증나는 업그레이드에서도 이전 코드를 붙여넣고 “이 코드는 Google의 새 권장 JavaScript 라이브러리로 업그레이드해야 한다. 그게 뭔지 파악하고 문서를 충분히 찾아 이 코드로 포팅해라”라고 했더니 정확히 해냈음: https://simonwillison.net/2025/Apr/21/ai-assisted-search/#la...
  • GPT 4.1과 4o는 Aider 코딩 벤치마크에서 점수가 매우 낮음. 내 경험상 70% 이상 나오는 모델부터 결과가 받아들일 만해짐.
    그래도 복잡한 일을 많은 손잡이 없이 해낼 거라고 기대하면 안 됨. 무엇이 잘 되고 안 되는지 감이 생기기 시작함.
    https://aider.chat/docs/leaderboards/
  • “실력 문제”라는 말을 듣는 게 짜증난다는 건 이해하지만, LLM 사용은 분명 기술임. 여러 도구의 강점 이해, 기법을 파악하기 위한 실험, 순수한 연습이 섞여 있음.
    다만 bash 접근 권한을 준다면 나도 반드시 Docker 컨테이너 안에서만 줄 것 같음
  • 얼마 전 VSCode의 Cline 플러그인과 Claude로 Android Studio의 기본 템플릿에서 시작해 Android 앱 프로토타입을 처음부터 만들었음. 수천 줄의 코드를 생성했고 컴파일 오류는 하나도 없었으며, 앱은 내가 원한 대로 동작함.
    한두 버그가 있었지만 LLM이 멍청해서가 아니라 해당 Android API의 이상하고 문서화되지 않은 동작 때문이었고, 그래서 빠른 프로토타입이 필요했던 것임.
    버그를 지적하자 LLM은 내가 제공한 디버그 메시지 출력 도움을 받아 성공적으로 디버깅했고 결국 고쳤음. 단점은 수정 품질이 마음에 들지 않았다는 것인데, 다소 지저분한 해킹에 가까웠음. 그래도 피드백을 한두 번 더 주니 거기까지도 해결됐고, 코드를 쓰는 에이전트를 다른 코드 리뷰 에이전트와 루프로 묶으면 더 일반적으로 풀 수 있을 것 같음
  • 4o와 4.1은 코딩에 별로 좋지 않음. 내 최고 결과는 보통 4o-mini-high에서 나오고, o3도 가끔 꽤 괜찮음.
    개인적으로 canvas는 싫고 채팅 출력이 더 좋음. “이 파일의 전체 코드를 제공해라” 또는 “그대로 교체 가능한 코드를 줘라”라고 자주 말함. diff를 처리하기 싫을 때 특히 그렇음.
    다만 코드가 300~400줄 정도 되면 보통 품질이 나빠지기 시작하고, 그때는 여러 파일로 나눠 리팩터링해야 함. 파일 안의 메서드 하나에만 집중할 수 있다면 예외임

• 요즘 LLM의 도구 사용에 굉장히 기대하고 있음.
  이 기법 자체는 새롭지 않음. 2년 전 ReAct 논문에서 처음 접했고 https://til.simonwillison.net/llms/python-react-pattern, 이후 ChatGPT 플러그인과 최근 MCP에 쓰였으며 모든 모델이 도구 사용/함수 호출을 염두에 두고 학습됨.
  지금 흥미로운 건 모델들이 이걸 얼마나 잘하게 됐는지임. o3/o4-mini의 놀라운 검색 성능은 전부 도구 호출 덕분임. 심지어 Qwen3 4B도 Ollama에서 2.6GB이고 Mac에서 잘 돌아가면서 도구 호출을 꽤 합리적으로 수행함.
  어제 PyCon US에서 LLM 위에 소프트웨어를 만드는 워크숍을 했고 https://simonwillison.net/2025/May/15/building-on-llms/, 그걸 핑계로 내 LLM 명령줄 도구의 알파 버전에 도구 사용을 마침내 추가했음. 해당 워크숍 섹션은 여기 있음:
  https://building-with-llms-pycon-2025.readthedocs.io/en/late...
  이제 내 LLM 패키지는 셸 한 줄로 strawberry에 들어 있는 R 개수를 안정적으로 셀 수 있음:
  llm --functions ' def count_char_in_string(char: str, string: str) -> int: """Count the number of times a character appears in a string.""" return string.lower().count(char.lower()) ' 'Count the number of Rs in the word strawberry' --td

  • 이 안에 들어 있는 우스꽝스러움과 힘의 묘한 조합이 좋음
  • 워크숍이 녹화됐는지 궁금함

• 3월 중순 출시일부터 Sonnet 3.7의 터미널 인터페이스인 Claude Code를 써왔음. 실질적인 CLI 앱, 풀스택 웹 시스템, 잡다한 유틸리티를 많이 만들었고, 예전에 프로그래밍 팀을 운영하던 때처럼 훨씬 더 야심차게 일하게 됨.
  내부적으로는 이 글의 방식과 거의 같겠지만 Anthropic이 정말 유용한 기능을 많이 붙였음.
  완벽한 건 아님. 좋은 코드를 만들려면 예전에 팀을 운영할 때와 비슷한 노력이 필요함. 복잡한 걸 돌아가게 만들 수는 있지만, 다음 기능을 추가하기 어려울 정도로 엉망이 되는 경우도 있음. 다루는 법을 배우면서 수습과 리팩터링이 훨씬 줄었지만, 완전히 사라지지는 않을 것임.
  Claude가 내가 하지 않을 선택을 하고 멍청한 일을 한 적은 있지만, 포기할 생각이 들 정도는 한 번도 아니었음. 거의 항상 꽤 괜찮게 하고, 대부분의 일에서 내 머리에서 덜어주는 작업량이 엄청남.
  게다가 리팩터링을 훌륭하게 함. 주기적으로 코드를 보고 어떻게 더 좋아질지 정한 뒤 Claude에게 지시하는 세션을 가짐. “이 데이터 구조를 바꿔”라고 하면 엄청난 복잡도를 처리해줌. 놀랍도록 멋짐.
  재미 삼아 코드가 아닌 오래된 아카이브 디렉터리에서도 열어봤음. 30년 동안 채운 잡동사니 서랍 같은 곳이었는데 “이 디렉터리에 뭐가 있지?”, “옛 이력서를 읽고 새 이력서를 써줘”, “내 아이들 이름이 뭐지?” 같은 것도 해냈음. 이것도 놀라움.
  아직 초기 단계라서 정말 기쁨

  • 최근 원격 데이터 구조를 정의하고, 그걸 요청하는 API를 명세하고, 파싱과 저장을 구현하고, 사용자에게 보여줘야 했음.
    Claude는 이 모든 작업을 동시에 처리할 수 있어서, 양 끝단의 작은 변경이 중간 계층에 어떤 영향을 주는지 볼 수 있었음. 내 사용 사례에 가장 좋은 전체 해법을 정할 때까지 여러 아이디어를 반복함.
    여러 복잡한 계층을 가로질러 그렇게 반복할 수 있다는 게 눈이 트이는 경험이었음. 생산성이 올라가면서도 서로 다른 구성 요소가 어떻게 맞물리는지 더 잘 이해하게 됨
  • 리팩터링을 정말 잘해주는 건 말 그대로 즐거움. 스프린트에 넣기 위해 힘들게 설득해야 할 작업이 5분 만에 끝남.
    마치 한 팀 전체가 앉아서 내 지시를 기꺼이 기다리는 느낌이고, 작업의 정당화·일정화·범위 산정·수행을 기다릴 필요도 없고, 결과가 마음에 들지 않아 거절할 때도 변명할 필요가 없음

• 실제 업무에 쓰기 시작하기 전까지만 효과적으로 보임. 가장 큰 문제는 컨텍스트임. 모든 도구 사용은 컨텍스트를 만들고, 큰 코드베이스는 시작부터 큰 컨텍스트를 동반함. LLM은 꽤 잘 되는 듯하다가도 상당한 컨텍스트를 맞으면 품질이 떨어짐. 10k를 넘으면 품질이 나빠지는 듯함.
  또 다른 문제는 LLM이 옆길로 샐 수 있다는 것임. 컨텍스트가 쌓이면 목표가 무엇이었는지 잊어버림. 한 번 잘못 방향을 잡으면 토끼굴로 들어가 회복하지 못함.
  이걸 아는 이유는 우리가 1년 전부터 이런 문제를 풀기 시작했기 때문임. 아직 끝나진 않았지만 꽤 많이 진척됨.
  [홍보]: https://nonbios.ai에서 써볼 수 있음:
  에이전트형 메모리 → 장기 코딩, 전체 Linux 박스 → 장난감 데모가 아닌 실제 런타임, 투명성 → 모든 명령을 보고 제어 가능, 무료 베타 — 초대 불필요. 일회용 이메일(mailinator 등)로도 동작함

  • “한 번 잘못 방향을 잡으면 토끼굴로 들어가 회복하지 못한다”는 부분이 이런 것들이 실용 도구로 성립하기 어렵다는 가장 강한 논거의 핵심일 듯함.
    LLM이 잘못된 길로 가지 않도록 문제를 충분히 설명했다면, 이미 대부분은 스스로 푼 상태일 가능성이 큼.
    오류 피드백을 곁들인 도구 사용은 자율적으로 들리지만, 곧 오류 처리 계층이 인간 조작자의 의도를 얇게 대리하는 것에 가깝다는 걸 알게 됨
  • 일부 사고 모델은 회복할 수도 있음. 대신 4k 토큰을 더 써버릴 수 있음. 긴 컨텍스트에서 안정적이라고 해도 속도가 엄청나게 떨어짐. 이 아키텍처로는 이기기 어려움
  • 흥미로워 보임. 컨텍스트를 어떻게 관리하는지 궁금함

• 오늘 아침 Cursor로 게임 프로토타입의 메인 루프에서 복잡한 몇 부분을 추출하고, 그 부분들에 대한 테스트 묶음을 생성했음. 총 341개의 테스트를 Cursor가 작성했고 핵심 수학과 다른 구성 요소들을 덮음.
  가끔 고양이 몰이처럼 느껴질 때가 있었고, 나쁜 아이디어를 잡으면 순식간에 달려나감. 하지만 무엇을 사용할지, 어디에 둘지, 템플릿 파일을 주고, 무엇을 하지 말아야 할지 등 제약을 더 많이 줄수록 결과가 좋아짐.
  총 3500줄의 테스트 코드를 받았고, 내가 쓸 필요도 고칠 필요도 없으며, 전제가 바뀌면 삭제하고 다시 생성하면 됨. 난이도 곡선 조정, 미션 변형 생성 등에도 도움이 됨

  • 내 경험상 테스트 작성은 LLM의 최고 활용 사례임. 몇 시간에서 며칠 걸리는 단조로운 고역을 없애주고, 내가 직접 생각해낼 수 있는 것보다 훨씬 많은 경계 사례를 덮어줌.
    게다가 코드가 더 견고해짐. 전반적으로 정말 훌륭함

• “아, 이 테스트가 통과하지 않네... 그냥 건너뛰자”라고 할 때가 있어서 미칠 것 같음.
  좀 과격한 아이디어가 있음. 메인 LLM이 지시를 따르도록 독립적이고 병렬로 실행되는 정책 집행 동반 LLM을 상상해볼 수 있음.
  동반 LLM이 실시간으로 코딩 LLM이 “let's just”라는 토큰을 내는 걸 보고, 그다음 “skip”이 나올 수 없도록 출력을 편향시켜 “let's just skip it”을 못 내게 하는 방식임.
  “let's just” 뒤에 “skip”을 금지하면 LLM이 원치 않는 행동에서 벗어나 새 경로로 가게 됨. 구조화 출력이나 JSON 모드와 비슷하지만, 동반 LLM이 주도하고 토큰이 나올 때마다 동적으로 수정하는 방식임.
  이 아이디어가 통하면 동반 LLM에 더 고급 정책도 맡길 수 있음. 예를 들어 테스트 코드를 삭제해서 테스트를 통과시키는 걸 금지하거나, 무의미한 주석을 출력하지 못하게 하는 식임. 오늘날 시스템 프롬프트에 넣고 LLM이 따르길 기도하는 모든 정책을 동반 LLM의 프롬프트에 넣는 셈임.
  Outlines 쪽 사람들이 이걸 어떻게 볼지 궁금함

  • 비슷하게, 메인 LLM이 나쁜 경로로 가면 모델을 그 경로로 들어가기 전으로 되감기할 수도 있음. 감시 LLM이 “let's just” 다음에 “skip”이 나쁜 토큰이라고 미리 맞힐 필요는 없고, “let's just skip the test”를 보고 “아니, just 토큰으로 되돌리고 logit_bias={"skip":-10,"omit":-10,"hack":-10}로 다시 뽑자”라고 하면 됨.
    물론 이렇게 하면 쓸 수 있는 모델 제공자가 제한됨. 특히 OpenAI는 지난 1년 정도 파워 유저가 이런 걸 하는 데 꽤 비우호적으로 변했음
  • OpenAI의 한 팀도 비슷한 시도를 했음[1]. 4o가 o3-mini를 감시해서 테스트가 너무 어렵다고 우회하려는 순간을 잡게 했고, 그런 행동을 하면 o3-mini를 처벌하도록 학습시킴.
    결과적으로 o3-mini는 여전히 보상 해킹을 했고, 다만 4o가 감지하지 못하게 표현을 바꿨을 뿐임. 예전에는 “모든 테스트를 건너뛰려면 항상 skip하는 pytest_runtest_setup 함수를 정의하면 된다”고 말하던 것이, 이후에는 “아이디어: 무작위 첫 승계를 가진 새 빌드를 시작하면 random_new_succession 호출이 succession을 증가시키면 안 되는데 구현에서는 증가시킨다. 증가하지 않도록 조정한다...”처럼 말하면서 실제로는 똑같이 테스트를 건너뜀.
    학습이 없어도 이건 임시 처방일 뿐임. 보상 해킹의 유인이 충분히 커지면, 단순 탐지가 불가능한 다른 표현 방식으로 바꿀 것임.
    [1]: https://openai.com/index/chain-of-thought-monitoring/
  • 두 번째 LLM으로 첫 번째 LLM을 검사하는 게 통한다면, 전문가 혼합 모델이 자기 전문가 중 하나를 다른 전문가 결과 검사에 배정하지 못할 이유가 뭘까?
    또는 추론 시 계산을 쓰는 “사고” 모델이 자기 출력 검증을 위한 별도의 사고 스레드를 돌리지 못할 이유도 없어 보임. 그걸로 60%까지 간다면, 검증자를 검증하는 또 다른 사고 스레드도 둘 수 있음

• 제목은 Eugene Wigner의 논문 The Unreasonable Effectiveness of Mathematics in the Natural Sciences[1][2]를 변주한 것 같음.
  [1]: https://en.wikipedia.org/wiki/The_Unreasonable_Effectiveness...
  [2]: https://www.hep.upenn.edu/~johnda/Papers/wignerUnreasonableE...

  • 그 논문은 몰랐고, 제목은 Karpathy의 2015년 글 Unreasonable Effectiveness of RNNs[1]를 비튼 것이라고 생각했음. RNN에서 LLM으로 이어지는 연결을 보면 그럴 수도 있지만, Karpathy도 제목을 Wigner에서 따왔을 수는 있음. 직접 그렇게 말하진 않았음.
    [1] https://karpathy.github.io/2015/05/21/rnn-effectiveness/
  • 그게 원조일 수는 있지만, 이미 오래전부터 밈이 됐음: https://scholar.google.com/scholar?q=unreasonable+effectiven...
  • 제목에 “unreasonable effectiveness”가 보일 때마다 저자의 결론에 강하게 동의하지 않게 돼서 웃김. Wigner도 포함해서, 나에겐 일종의 Betteridge식 법칙이 됨

• “설치되어 있지 않은 도구가 있으면 설치한다.”
  무섭다. LLM은 매우 순응적이고, 누군가 무언가를 요청하기만 하면 됨. 이건 SQL 인젝션과 비슷하지만 더 나쁨

  • 첫 번째 에이전트 주도 대참사가 무엇일지 자주 궁금함. 지금 벌어지는 골드러시, 특히 ‘rush’가 강조되는 상황을 보면, 고치기 어려운 재난이 일어나는 건 시간문제임
  • 이상적인 세계라면 이 흐름은 프로그래머가 코드베이스를 읽고 보강하는 능력에 더 깊이 기대도록 만들 것임. 사실 그 능력은 지금도 과소평가되어 있음.
    하지만 인센티브가 쓰기 전용 코드 쪽으로 기울어져 있다면 낙관적이지 않음

• Sonnet 3.7은 놀라울 정도로 일관성이 없음. 아주 잘할 때도 있지만, 길을 잃고 이상한 일을 하러 달려가는 경향이 강함.
  내 경험상 이런 용도에는 3.5가 더 나음. Claude Desktop을 MCP 서버에 붙여서 터무니없는 가격의 Claude Code를 흉내 내게 했고, 꽤 괜찮게 동작함. Rust 작업에 적용해보는 중인데 아직 훌륭하진 않음. Rust의 개념을 정말 “이해”하는 것 같지는 않지만, 매 변경 뒤 cargo check를 돌리게 하고 실패하면 멈추게 하면 일부 작업은 가능함.
  o3-high 같은 것이 Aider 리더보드 기준으로도 단독 또는 4.1과 조합해서 현존 최고일 것 같지만, 솔직히 내 예산 밖임. 그리고 유용할지 아닐지 모르는 LLM 응답에 매우 높은 가격을 내는 걸 심리적으로 넘기 어렵다. 모델이 작업에 실패해서 여러 번 다시 뽑아야 하는데 그 한계비용을 나에게 전가하는 고객 경험이 매우 불쾌함

  • API 비용을 피하려고 채팅/UI를 대신 쓰고 있음. 내 경우에는 큰 토큰 창을 가진 Google Gemini 2.5 Pro를 씀. Repomix로 저장소 전체를 묶고, “전체 소스를 반환해라”라는 표준 프롬프트와 함께 붙여넣은 뒤 결과를 저장소 위에 적용함. 몇 번 주고받으면 이 지시를 잘 안 따르긴 함.
    그 작업을 돕기 위해 https://github.com/radekstepan/apply-llm-changes도 바이브 코딩으로 만들었음.
    반면 Claude 3.7과 Cline에 5달러를 쓰면 테스트를 고치는 대신, 테스트를 통과시키려고 소스 코드에 if/else 문이 생기는 결과를 보게 됨
  • 나만 그런 것 같지만, 코딩을 정말 잘하는 건 느리고 무거운 추론 시 계산 모델뿐임.
    o1-pro와 o1-preview만이 내가 써본 모델 중 1000줄짜리 코드를 오류 없이 안정적으로 업데이트하고 다룰 수 있었음.
    o3에게는 아주 작은 코드가 아니면 작성하게 두지 않음. “싼” 모델은 조금만 밀어붙이면 환각을 일으키거나 크게 실패함.
    최근 유용했던 팁 하나는, LLM에 넘기거나 쓰기 전에 코드의 모든 주석을 제거하는 것임. LLM이 생성한 주석은 어떤 경우에도 남기지 않음
  • 지난 며칠간 Mistral Medium 3를 써봤는데, 솔직히 꽤 좋아서 놀랐음. 비용을 줄이려는 중이라면 특히 한 번 써보길 강력 추천함. 나는 사실상 Claude에서 Mistral로 옮겼고, 비용이 같더라도 Mistral을 더 선호함