지난 1년간의 혁신이 주로 엔지니어링 중심으로 흘러온 게 흥미로움
MCP, agent, skill 등 새로운 개념들이 쏟아졌지만, 여전히 환각·부정확성·문맥 붕괴 같은 근본 문제는 해결되지 않았음
이런 문제는 단순한 엔지니어링이 아니라 기초 연구로만 풀릴 것 같음
지금의 개선과 발표들은 투자자들의 기대를 유지하기 위한 하이프 사이클의 일부처럼 느껴짐
솔직히 AI라는 내러티브가 지쳐서, 이 기술이 실제로 어디에 유용한지 명확해지는 시점으로 빨리 넘어가고 싶음
이런 기능이 멋지긴 하지만, 하루 종일 agent를 돌릴 수 있는 사람이 얼마나 될까 하는 의문이 있음
Cursor를 쓰면서 토큰 소모량이 너무 커서 Ultra로 업그레이드했는데, 사용량이 비례하지 않는 느낌임
다행히 오픈소스 LLM 진영이 빠르게 따라오고 있어서 희망적임
나는 Claude Max의 월 200회 한도도 다 못 씀. 매일 코딩하고 꽤 무거운 작업을 하는데도 그렇음
이런 건 사실상 실험 단계라, Gas Town처럼 실패할 수도 있음
많은 회사가 연봉 15만 달러짜리 주니어 엔지니어를 고용할 수 있음. AI 구독료가 그보다 비싸다면 문제임
게다가 지금 얘기하는 건 Cursor가 아니라 Claude Code임. 차라리 Claude Max를 써보길 권함
이런 걸 하루 종일 돌릴 수 있는 건 VC 자금 받은 2인 스타트업 정도일 것 같음
Claude Code Max는 토큰 단가 대비 30배 가치가 있어서, 다 못 쓰면 본인 책임임. 전기요금보다 쌀지도 모름
Steve Yegge가 예전에 Anthropic 같은 회사에 agent orchestrator 아이디어를 제안했었음
(Welcome to Gas Town)
Anthropic이 이제 Agent Teams를 내놓은 걸 보면, 이미 그때부터 준비했거나 같은 결론에 도달한 듯함
어쨌든 Steve의 비전이 검증된 셈이라 흥미로움. 곧 “폴캣 길들이기” 시즌이 올지도 모름
나도 GasTown 열풍 전에 간단한 agent 팀 구조를 만들어봤음. 여러 Claude 인스턴스를 tmux 세션으로 돌리고, .claude.lock으로 동기화했음
꽤 잘 돌아갔지만, 아직은 효율적이지 않음. 스펙 작성 속도와 QA 품질이 병목임
사실 이런 구조는 actor 프레임워크에서 이미 존재하던 개념임. Akka 같은 시스템과 비교하면 새로울 게 없음
LLM provider들이 이제야 이런 걸 배우는 걸 보면, 실시간으로 성장 중이라는 생각이 듦
Kubernetes for agents라는 말도 과장이 아님. 나도 로컬에서 그렇게 연결해 씀
Anthropic 엔지니어들이 이런 아이디어를 몰랐을 리 없다고 생각함. ChatGPT 초창기부터 이런 얘기 많았음
사실 이런 multi-agent 시스템은 2023년부터 arxiv와 GitHub에 많았음
그때는 모델이 덜 똑똑하고 context window가 작았을 뿐, 지금은 충분히 가능해진 것뿐임
나는 여러 Claude Code 인스턴스를 tmux 기반 CLI agent로 돌려 협업시키는 워크플로를 써왔음
이번 orchestration 기능은 공통 task list를 공유하고 메인 agent가 조율해주기 때문에 훨씬 유용함 tmux-cli 도구로 agent 간 협업을 자동화할 수 있음
이런 기능이 언젠가 기본 내장될 게 뻔해서 지금까지 배우지 않았는데, 이제는 써볼 시점인 듯함
내 $20/월 구독이 10분도 못 버틸 것 같다는 걱정이 있음
개인이 직접 결제한다면 Kimi나 GLM을 쓰는 게 더 합리적임
나도 같은 생각임. 이런 구조가 실제로 가치를 낼 수 있을지 의문임
특정 작업에서는 Haiku가 꽤 좋은 결과를 줬음
이건 Gas Town과 비슷해 보임
프로젝트가 너무 기괴하거나 장난스럽게 가면, 결국 덜 유치한 클론이 나와서 이길 가능성이 큼
그런데 폴캣은 어디 갔는지, 시장의 유머 감각이 궁금함
Gas Town이 뭔지는 모르지만, 나는 이미 Claude Code Agent Teams와 비슷한 구조를 써왔음
메인 대화에서 하위 agent를 생성해 작업을 분리하면 문맥 손실 없이 오래 일할 수 있음
디자인이 더 단순해 보임. 리더 agent 하나와 여러 worker 구조로, Gas Town의 복잡한 역할 체계보다 깔끔함
하지만 폴캣이 없다는 점은 아쉬움
나는 Claude Code를 대형 작업에 독립적으로 맡길 수 없음
코드 품질을 유지하려면 설계 과정에 직접 개입해야 함
agent 팀은 오히려 리뷰와 리팩터링 부담만 늘릴 것 같음
코드베이스 구조와 패턴 사용 규칙을 skill로 인코딩하면, sub-agent가 이를 감독하도록 할 수 있음
이런 식으로 계획·설계·QA·리뷰 agent를 나눠 협업시키는 게 바로 이 기능의 본질임
Claude 내에서 적대적 모델을 만들어 품질을 높이는 방법도 있음. 한 agent가 수정하고, 다른 agent가 검증하는 식임
인간도 큰 작업은 쪼개서 처리하듯, Claude에게 계획과 테스트 기준을 세우게 하면 효율적임
나는 Beads의 대안을 직접 만들다가, 결국 비슷한 구조로 GitHub 프로젝트와 동기화되는 agent 시스템을 완성했음
곧 오픈소스로 공개할 예정이며, 티켓 시스템과 연동되는 게 장기적으로 더 유용하다고 생각함
agent에 종속되지 않는 agnostic한 대안이 많아지는 게 바람직함
Hacker News 의견들
지난 1년간의 혁신이 주로 엔지니어링 중심으로 흘러온 게 흥미로움
MCP, agent, skill 등 새로운 개념들이 쏟아졌지만, 여전히 환각·부정확성·문맥 붕괴 같은 근본 문제는 해결되지 않았음
이런 문제는 단순한 엔지니어링이 아니라 기초 연구로만 풀릴 것 같음
지금의 개선과 발표들은 투자자들의 기대를 유지하기 위한 하이프 사이클의 일부처럼 느껴짐
솔직히 AI라는 내러티브가 지쳐서, 이 기술이 실제로 어디에 유용한지 명확해지는 시점으로 빨리 넘어가고 싶음
이런 기능이 멋지긴 하지만, 하루 종일 agent를 돌릴 수 있는 사람이 얼마나 될까 하는 의문이 있음
Cursor를 쓰면서 토큰 소모량이 너무 커서 Ultra로 업그레이드했는데, 사용량이 비례하지 않는 느낌임
다행히 오픈소스 LLM 진영이 빠르게 따라오고 있어서 희망적임
게다가 지금 얘기하는 건 Cursor가 아니라 Claude Code임. 차라리 Claude Max를 써보길 권함
Steve Yegge가 예전에 Anthropic 같은 회사에 agent orchestrator 아이디어를 제안했었음
(Welcome to Gas Town)
Anthropic이 이제 Agent Teams를 내놓은 걸 보면, 이미 그때부터 준비했거나 같은 결론에 도달한 듯함
어쨌든 Steve의 비전이 검증된 셈이라 흥미로움. 곧 “폴캣 길들이기” 시즌이 올지도 모름
claude-code-orchestrator
.claude.lock으로 동기화했음꽤 잘 돌아갔지만, 아직은 효율적이지 않음. 스펙 작성 속도와 QA 품질이 병목임
LLM provider들이 이제야 이런 걸 배우는 걸 보면, 실시간으로 성장 중이라는 생각이 듦
Kubernetes for agents라는 말도 과장이 아님. 나도 로컬에서 그렇게 연결해 씀
그때는 모델이 덜 똑똑하고 context window가 작았을 뿐, 지금은 충분히 가능해진 것뿐임
나는 여러 Claude Code 인스턴스를 tmux 기반 CLI agent로 돌려 협업시키는 워크플로를 써왔음
이번 orchestration 기능은 공통 task list를 공유하고 메인 agent가 조율해주기 때문에 훨씬 유용함
tmux-cli 도구로 agent 간 협업을 자동화할 수 있음
이런 기능이 언젠가 기본 내장될 게 뻔해서 지금까지 배우지 않았는데, 이제는 써볼 시점인 듯함
내 $20/월 구독이 10분도 못 버틸 것 같다는 걱정이 있음
이건 Gas Town과 비슷해 보임
메인 대화에서 하위 agent를 생성해 작업을 분리하면 문맥 손실 없이 오래 일할 수 있음
나는 Claude Code를 대형 작업에 독립적으로 맡길 수 없음
코드 품질을 유지하려면 설계 과정에 직접 개입해야 함
agent 팀은 오히려 리뷰와 리팩터링 부담만 늘릴 것 같음
이런 식으로 계획·설계·QA·리뷰 agent를 나눠 협업시키는 게 바로 이 기능의 본질임
관련 논문
나는 Opus를 메인으로, 하위 agent는 Gemini나 Codex로 돌리는 멀티 LLM 오케스트레이션을 찾고 있음
모두 중국 개발자가 만든 프로젝트지만, 써본 결과 꽤 훌륭했음
관련 경험을 트위터 글에 정리했음
review skill 코드, Greptile PR 분석기도 함께 씀
GPT-5.2 Codex Max로 계획, Opus 4.5로 구현, Gemini로 리뷰를 맡기는 구조도 가능함
나는 Beads의 대안을 직접 만들다가, 결국 비슷한 구조로 GitHub 프로젝트와 동기화되는 agent 시스템을 완성했음
곧 오픈소스로 공개할 예정이며, 티켓 시스템과 연동되는 게 장기적으로 더 유용하다고 생각함
agent에 종속되지 않는 agnostic한 대안이 많아지는 게 바람직함