글

오케스트레이션이 제품이 됐다 — Sakana Fugu가 말하는 것과 안 말하는 것

이미지
Sakana Fugu는 그 오케스트레이션 자체를 모델로 만들어 파는 제품이다. 오늘(2026-06-22) 정식 출시됐다. 써보진 않았다. 그래서 후기는 아니다. 공개된 자료로 주장과 빈칸만 따졌다. 한 줄로 정리하면 이렇다. Fugu에는 진짜 새로운 한 가지와, 아직 아무도 독립 검증하지 않은 여러 빈칸이 같이 들어 있다. 누가 읽으면 좋은가 멀티에이전트·오케스트레이션을 직접 엮어본 사람 “모델이 모델을 부린다”가 마케팅인지 진짜 새 구조인지 궁금한 사람 LangGraph나 OpenRouter를 쓰면서 그다음이 뭔지 보는 사람 Fugu가 진짜 새로운 한 가지 Fugu는 라우팅 규칙을 손으로 짠 게 아니라, 오케스트레이션을 학습한 모델 이다. 작업을 받으면 직접 풀거나, 전문 모델들을 불러 팀을 꾸리고, 검증·합성까지 한다. 자기 자신을 재귀로 다시 부르며 “1차 답이 부족했다”를 인지하고 교정하기도 한다. 근거는 Sakana의 ICLR 2026 논문 두 편이다. TRINITY (arXiv 2512.04695)는 진화 전략으로 학습한 0.6B 지휘자가 Thinker·Worker·Verifier 역할을 나눠주고, The Conductor 는 7B 모델을 강화학습으로 훈련해 자연어 협응 전략을 스스로 찾게 한다. Fugu는 이 둘을 개선해 상품화한 것이다(제품 지휘자 크기는 비공개). 풀에는 Opus 4.8, Gemini 3.1 Pro, GPT-5.5가 들어간다. 그리고 이 풀을 지휘해 풀 멤버 각각보다 더 잘한다 고 주장한다. 라우터(한 개 고르기)도 프레임워크(손으로 배선)도 아닌, “훈련된 오케스트레이터 = 모델”이라는 자리는 카테고리상 분명히 새롭다. 그런데 — 빈칸들 여기서부터가 불편한 부분이다. 벤치마크는 전부 Sakana 자체 보고고 독립 검증이 아직 없다. Fugu Ultra가 SWE-Bench Pro 73.7로 Opus 4.8(69.2)을 앞선다지만, 정작 풀에 없는 Fable 5가 그 벤치와 Humanity’s Las...
댓글 쓰기
자세한 내용 보기

테스트 113개 다 통과했는데 실제론 0개를 긁었다 — AI가 짠 수집기의 함정

이미지
AI에게 수집기(웹에서 데이터를 긁어오는 코드) 두 개를 맡겼더니, 테스트 113개를 전부 통과시켰다. 초록불. 그런데 실제로 돌려보니 한쪽은 0개를 긁었다. 전에 이 블로그에서 이 트렌드 수집 도구의 데이터 소스가 어떻게 죽는지 썼다. 이번엔 거기에 기능을 붙이다가 더 불편한 걸 배웠다. 테스트는 통과했는데 코드는 작동하지 않았다 — 이게 어떻게 동시에 참일 수 있나. 한 줄이면 이렇다. 추정한 입력에 맞춰 짠 테스트는 그 추정이 맞다는 것만 증명한다. 실제 세계가 추정과 같은지는 아무도 검증하지 않았다. 누가 읽으면 좋은가 AI(Claude·Cursor 등)에게 코드를 맡기고 테스트 초록불을 받아본 사람 특히 외부 API나 웹페이지를 긁는 코드를 AI에 시켜본 사람 “테스트 다 통과했으니 됐겠지”로 넘어간 적 있는 사람 113개 초록불, 라이브에선 0개 무슨 일이었나부터. 트렌드 도구에 “해외에서 잘나가는 신제품”을 자동으로 잡아낼 수집기 두 개를 붙이려 했다. 하나는 Show HN(해커뉴스 신제품 게시판), 하나는 Product Hunt(신제품 등록 사이트). 작업은 서브에이전트에 맡겼다. 테스트를 먼저 쓰고 구현하는 방식으로, 규칙도 빡빡하게 줬다. 에이전트는 코드와 테스트를 짜서 “113개 통과”를 보고했다. 여기서 멈췄으면 끝이었다. 초록불이니까. 그런데 안 믿고 실제로 돌렸다. Show HN은 실제 런칭 5건을 정확히 긁어왔다. Product Hunt는 0개였다. 대신 에러 하나 — “제품을 하나도 파싱하지 못함”. 테스트는 왜 통과했나 이게 핵심이다. 0개를 긁는 코드의 테스트가 어떻게 113개나 통과했나. 답은 단순했다. 에이전트는 Product Hunt의 실제 응답을 한 번도 본 적이 없다. 줄 수도 없었다. 그 응답은 실제로 한 번 긁어봐야 나온다. 그래서 “이렇게 생겼겠지” 하고 가짜 샘플을 만들었고, 그 샘플에 맞춰 파싱 코드를 짰고, 다시 그 샘플로 테스트를 돌렸다. 테스트는 “추정이 추정과 일치...
댓글 쓰기
자세한 내용 보기

AI 코딩 설정도 코드처럼 썩는다 — 가짜 보안 훅과 죽은 에이전트 11개

이미지
하네스(AI 도구를 내 방식대로 굴리는 설정·규칙·자동화 묶음)를 만드는 법은 전에 썼다. 그런데 만든 다음, 그 AI 코딩 설정이 계속 작동하는지는 아무도 점검하지 않는다. 며칠 전 처음으로 내 설정을 전수 점검했다. 몇 달 동안 잘 굴러간다고 믿었던 설정이다. 다 열어보고 든 생각은 하나였다. 절반이 조용히 죽어 있거나, 가짜로 작동하고 있었다. 가장 충격적인 건 보안 훅이었다. API 키가 새는 걸 막으려고 달아둔 훅이, 필드명 오타 하나 때문에 설치된 날부터 한 번도 실행된 적이 없었다. 개발 에이전트 11개는 주석 한 줄 때문에 세션에 등록조차 안 되고 있었다. 설정도 코드처럼 썩는다. 만들고 방치하면 죽은 참조와 작동 안 하는 안전장치가 쌓인다. 영어로는 이걸 설정 부패(config rot)라고 부른다. 누가 읽으면 좋은가 Claude Code·Cursor에 CLAUDE.md·에이전트·훅을 세팅해 본 사람 설정을 한참 전에 만들어두고 그 뒤로 열어본 적 없는 사람 “에러가 안 나니까 잘 돌고 있겠지”라고 믿고 있는 사람 한 줄로 요약하면, 설정 파일에 등록돼 있다는 것과 그 기능이 실제로 작동한다는 것은 전혀 다른 문제였다. 주석 한 줄에 사라진 에이전트 11개 점검에서 가장 먼저 걸린 건 개발 에이전트들이었다. architect, planner, code-reviewer… 정의 파일은 멀쩡히 다 있었다. 그런데 세션에서 단 하나도 호출되지 않고 있었다. 원인은 파일 맨 위에 무심코 넣은 주석 한 줄이었다. # Part of … 같은 한 줄이 그 아래 frontmatter 파싱을 깨뜨렸고, 시스템은 그 파일들을 에이전트로 인식하지 못했다. 정의는 있는데 시스템은 그들을 보지 못한 것이다. 11개가 이 상태였다. 에러도, 경고도 없었다. 그냥 명단에서 빠져 있었다. 한 번도 돌지 않은 보안 훅 더 무서운 건 보안 훅이었다. 시크릿이 화면에 노출되는 걸 막으려고 만든 훅인데, 코드는 tool_result 라는 필드를 보...
댓글 쓰기
자세한 내용 보기

리뷰는 좋아졌는데 단가는 2배 — Claude Fable 5 이틀 실사용

이미지
Claude Fable 5가 6월 10일에 나왔다. Hacker News 출시 스레드가 하루 만에 2,280점(댓글 1,774개)을 받았고, 출시 당일부터 Claude Code 기본 모델을 Fable 5로 바꿔 이틀을 썼다. 이틀 동안 좋아진 건 분명히 있었다. 그런데 공식 단가표와 커뮤니티 반응이 서로 반대 방향을 가리키고 있어서, 갈아탈지 판정은 미루기로 했다. 요약하면 이렇다. 글 리뷰 능력은 실측으로 좋아졌고, 단가는 Opus 4.8의 2배가 됐다. “싸다”는 커뮤니티 반응과 공식 가격의 간극, 안전 필터 강화 보고까지 — 의문 4가지가 풀려야 전환을 정할 수 있다. 누가 읽으면 좋은가 Claude Code 기본 모델을 Fable 5로 바꿀지 고민 중인 사람 출시 첫 주의 들뜬 후기 말고 판정 유보 조건이 궁금한 사람 Opus 4.8 대비 비용이 실제로 어떻게 변하는지 확인하고 싶은 사람 한 줄로 요약하면, 글 리뷰는 실측으로 좋아졌지만 가격·필터·사용량 의문이 풀릴 때까지 판정은 유보다 . 검증 다섯 단계를 통과한 글에서 나온 결함 6건 전환 당일, 발행 직전이던 블로그 글을 Fable 5에 다시 리뷰시켰다. 그 글은 Opus 4.8 기반 검증을 다섯 단계(구조 리뷰 → 채점 루프 → AI 클리셰 검사 → 한국어 윤문 → 가독성 점검)로 통과한 상태였다. 그런데 결함 6건이 새로 나왔다. 주어와 서술어가 안 맞는 문장, 시스템에 쓸 수 없는 동사 선택, 연속 세 단락에 같은 구절 반복, 표기 혼용까지. 전부 사람이 보면 바로 어색한 것들인데 이전 검증에서는 안 잡혔다. 다만 이걸 모델 차이라고 단정은 못 한다. 같은 글을 두 번째 읽으면 누구든 더 잘 잡는다. 모델 효과와 재독 효과를 분리하려면 첫 리뷰부터 Fable 5로 돌린 다음 글에서 확인해야 한다. 단가 2배와 “싸다”는 반응 사이의 간극 공식 가격은 입력 $10, 출력 $50이다(100만 토큰 기준). Opus 4.8($5/$25)의 정확히 2배다. Cl...
댓글 쓰기
자세한 내용 보기

코드는 빨랐는데 — jira-agent 다섯 에이전트 4일 회고 (구축기 3편)

시리즈 1편에서 jira-agent의 결과(7분 PR)를, 2편에서 그 흐름을 만든 4일 구축 과정을 다뤘다. 4일을 돌아보던 중 r/ClaudeAI에 “Claude를 쓰다 보니 코딩이 병목이 아니었다는 걸 깨달았다”는 글이 올라온 걸 봤다. 읽어 보니 같은 결론에 닿았다. 유료 backend 전환 글을 쓰려다 먼저 정리할 게 보였다. 다섯 개의 에이전트가 동시에 돌아간 4일 동안 코드 작성이 늦어서 시간이 걸린 적은 없다. 늦은 건 따로 있었다. 시간을 따로 측정한 건 아니고 4일을 돌아보며 받은 인상이다. 2편이 사흘 동안 무엇을 만들었는지를 다뤘다면 3편은 그 과정에서 에이전트 분담이 풀지 않은 영역을 짚는다. 다섯 개의 에이전트가 푼 건 코드 작성 속도였고, 그 위 층 세 군데(스펙·검증·통합)가 남은 병목이었다. 검증 영역은 같은 모델 풀이 가진 사각지대라 다른 풀로 분리해야 해소된다. 누가 읽으면 좋은가 1편·2편을 보고 “에이전트 분담만 잘 짜면 빠른가” 궁금한 사람 코딩 자동화 도구를 쓰면서 코드 작성 속도는 늘었는데 결과 시간이 안 줄어 답답한 사람 AI 에이전트 다층 검증이 검증을 강화해주는지 의심이 드는 사람 한 줄로 요약하면, 코드 작성은 에이전트들이 빠르게 풀었고 스펙·검증·통합 세 군데에서 시간이 다시 들어갔다 . 스펙을 4일 동안 두 번 고쳤다 5월 18일에 architect가 스펙을 처음 작성했다. 결정 12개와 다섯 섹션이었다. module-builder는 이 스펙을 받아 모듈 22개를 같은 날 만들었다. 코드 작성 자체는 막힘이 없었다. 그런데 5월 19일에 운영 중 backend 전환 가능성이 생기면서 LLMBackend 추상화를 추가해야 한다는 게 명확해졌다. 5월 20일에는 다중 파일과 동적 저장소 확장이 더 필요해져 9개 모듈을 새로 만들어야 했다. 코드를 빨리 짜는 능력은 그대로였는데 스펙을 다시 써야 하니 에이전트들이 함께 다시 움직였다. archit...
댓글 쓰기
자세한 내용 보기