나는 물건을 만드는 물건을 만들었다: Tres Comas Scrum

I’m happy to translate the article for you, but I’ll need the full text you’d like translated (excluding the source line you already provided). Could you please paste the content you want translated?

설정

아키텍처는 매우 단순합니다:

• CEO는 제품 백로그를 보관하고, 스프린트를 계획하며, 전달물을 검토하고 프로젝트가 “완료”되었는지 결정합니다.
• Coder는 티켓을 받고, 기존 코드베이스를 읽은 뒤 XML 형식으로 코드를 전달합니다.
• Tester는 4 스프린트마다 깨어나서 구축된 내용을 검사하고, 깨졌거나 누락된 부분을 기반으로 새로운 스토리를 생성합니다.

각 전달물은 디스크에 기록되기 전에 격리된 샌드박스(bwrap on Linux)에서 테스트됩니다. 테스트가 실패하면 Coder에게 오류가 전달되고 최대 3번까지 다시 시도합니다.

바로 그것입니다. 오케스트레이션 프레임워크도, LangChain도, AutoGen도 없습니다. SQLite 데이터베이스와 수백 줄의 Python, 그리고 레이트 제한을 지키기 위한 많은 time.sleep(4)만 있습니다.

무엇이 잘못됐는가 (하이라이트 릴)

• The Coder kept writing ````python` inside XML tags. Every sprint. We added a regex to strip markdown backticks, then added a visual example to the system prompt, but it still happened occasionally.
• code.py is a reserved name. Our test runner was named code.py and Python kept importing the stdlib code module instead. Renamed it to test_runner.py, fixing two hours of debugging.
• sys.exit() makes bwrap angry. The sandbox intercepted pytest’s exit call and threw a fit. Removing the sys.exit() wrapper solved the issue instantly.
• The Coder delivered 0 files and the tests passed. No delivery = no test files = the runner returned success: True. Added checks: “no files = failure” and “no test files = failure”. The Coder has been slightly more motivated since then.
• argparse isn’t in the stdlib imports list. Our system strips external imports before inlining code into the test runner. We forgot about many stdlib modules. Added argparse, subprocess, random, zipfile, gzip, statistics, decimal, etc., expanding the list as needed.

잘된 점

• CEO가 스스로 올바른 빌드 순서를 찾아냈다. 먼저 기반(Agent, LLM, Memory, Tools)을 만들고, 그 다음 실행 루프, 그 다음 에이전트 간 통신, 그 다음 도구 라이브러리, 마지막으로 문서화를 진행했다. 이는 별다른 지시 없이 시니어 개발자가 할 법한 순서와 정확히 일치한다.

• Sprint 8에서 테스터의 피드백이 실제로 큰 도움이 되었다:

  “테스트는 통과하지만 실제로 프레임워크를 사용할 수가 없다. 버스 패턴은 구현돼 있지만 에이전트가 이를 사용하지 않는다. CLI도 없고, 예제도 없으며, 오류 처리도 없다.”

  CEO는 이를 여섯 개의 실행 가능한 스토리로 전환했고, 모두 Sprint 12까지 해결했다.

• Sprint 12가 되자 생성된 프레임워크는 다음을 포함하고 있었다:

  • Agent 클래스에 run() 및 run_autonomous() 메서드 구현
  • 에이전트 간 pub/sub을 담당하는 MessageBus
  • 검색 및 태깅 기능을 갖춘 영구 Memory
  • 16개의 사전 구성된 도구를 가진 Tools 레지스트리
  • LLM 제공자에 대한 오류 처리
  • YAML에서 에이전트를 로드하는 ConfigManager
  • README 파일

  코드가 전혀 없던 상태에서 시작한 것에 비하면 꽤 괜찮은 결과다.

메타 사물

이 실험의 전체 목적은 에이전트가 에이전트를 만들 때 사용하는 바로 그 프레임워크를 구축할 수 있는지 확인하는 것이었습니다. 대부분은 성공했습니다. 생성된 코드는 곳곳에 Pydantic V2 경고가 표시되고 Message가 BaseModel을 상속하지 않기 때문에 model_dump()가 프로덕션에서 충돌합니다 — 하지만 아키텍처는 견고합니다.

다음 단계는 그 프레임워크를 사용해 이 빌더를 다시 작성하는 것입니다: 자체 생성에 의해 오케스트레이션되는 에이전트들이 qwen3:8b와 함께 로컬 Ollama에서 실행됩니다. 거북이들이 끝없이 이어집니다.

Try It

The project is on GitHub: Tres Comas Scrum

You’ll need Linux (bwrap for sandboxing), Python 3.10+, and an OpenRouter API key. The free tier is enough to run a full build — just set the model to arcee-ai/trinity-large-preview:free and wait.

Fair warning: it will take a few hours, the Coder will occasionally deliver empty XML, and you will at some point stare at an IndentationError that makes no sense. That’s part of the experience.

Named after the Tres Comas tequila from Silicon Valley. Three agents, three commas. Russ Hanneman would not be impressed, but he’d probably try to invest anyway.