에이전트는 죽어도 작업은 남는다; 실제 프로덕션에서 유용했던 시스템을 공개하니, 한번 부숴봐 달라.
the agents can die; the work survives; this was useful on a real production system; please try to break it.
핵심 요약
코딩 에이전트의 작업 연속성과 관측 가능성을 보장하는 오픈소스 시스템 'mishe-tauftauf'를 공개하며 실전 테스트를 요청함.
- 관측 지향 개발 — 에이전트의 불확실성을 'UNKNOWN' 상태로 즉시 노출하여 오류를 방지함.
- 에이전트의 일시성 — 에이전트 자체의 연속성보다 작업 상태와 증거를 기록하는 '벽(wall)'을 통해 연속성을 유지함.
- 실전 검증 — 실제 광고 기술 DSP 구축에 사용되어 4개월 만에 프로덕션 환경에 배포된 경험이 있음.
- 오픈소스 공개 — CC0 1.0 라이선스로 배포되어 누구나 자유롭게 수정 및 활용 가능함.
TL;DR: 코딩 에이전트를 위한 소규모 로컬 조정 시스템인 mishe-tauftauf를 오픈소스로 풀었다. 이미 실무에서 써먹어 본 놈이다. 초기 버전으로 3명짜리 팀이 애드테크 DSP를 만들어서 운영까지 해봤다. 4개월 만에 0에서 프로덕션까지 올렸고, 초당 5만 건(50k RPS) 처리, RTB 경매, 실제 돈이 오가는 환경에서 온콜까지 다 겪었다.
이제 다른 사람들도 자기네 실제 프로젝트에 박아보고 제대로 박살 내줬으면 좋겠다. 잘 아는 코드베이스를 던져주고, 에이전트가 새로운 컨텍스트에서 작업하게 한 뒤에 조정이나 복구, 증거가 어디서부터 신뢰를 잃는지 확인해봐라. 문서 작업, 연구, 데이터 파이프라인, 개판인 레거시 시스템, 하드웨어까지 뭐든 좋다. 뻔한 코딩 데모보다는 낯선 환경에서 굴려보는 게 훨씬 도움 된다.
프로젝트 전체는 CC0 1.0이다. 포크해서 이름을 바꾸든, 절반을 뜯어내든, 메커니즘 하나만 훔쳐가든 마음대로 해라. 출처 표기 같은 거 필요 없다.
깃허브 주소: genaforvena/mishe-tauftauf
이 프로젝트의 핵심 아이디어는 내가 **관측 가능성 지향 프로그래밍/개발(observability-oriented programming/development)**이라고 부르는 것이다.
보통 관측 가능성(observability)은 소프트웨어가 다 만들어진 다음에야 시작된다. 시스템이 뭘 하는지 알려고 계측(instrument)을 하는 식이지. 나는 이 원칙을 개발 과정 자체에 적용하고 싶었다. 에이전트가 작업이 성공했는지 모른다면, 그 불확실성이 즉시 관측 가능해야 한다. 증거가 낡았으면 그게 눈에 보여야 하고, 체크 로직이 자기 주장을 입증하지 못하면 UNKNOWN을 뱉어야 한다.
목표는 다음 단계 사이의 살얼음판 같은 피드백 루프를 만드는 거다.
뭔가 알 수 없음 → 부족한 게 뭔지 드러냄 → 관측 → 행동 → 다시 관측
말은 쉬워 보이는데, 실제 에이전트들은 이 단계 사이의 틈새에서 죄다 삽질한다. 관측되지 않은 게 그냥 '가정'이 되어버리고, 옛날 결과가 '현재의 진실'로 둔갑한다. 명령어 하나 성공했다고 "작업 완료"라고 퉁쳐버린다. 새로 투입된 에이전트는 자기가 직접 확인할 수 있는 데이터 대신, 이전 에이전트가 쓴 썰만 읽고 작업을 이어받는다.
Mishe는 그 틈새를 최대한 좁히려고 만든 거다.
여기 에이전트들, 즉 "마인드(minds)"는 일부러 일회용으로 설계했다. 재시작하거나, 교체하거나, 새로운 컨텍스트를 줘도 상관없다. 에이전트 자체의 연속성을 유지하려고 애쓰지 않는다. 대신 작업이 연속성을 짊어지고 간다. 새로 작성된 상태 문서("벽"), 공유 텍스트 테이프, 체크 로직, 아티팩트, 그리고 명시적으로 남겨진 미완성 작업들을 통해서 말이다.
새로운 마인드가 투입되면, 현재 상태를 훑어보고 뭐가 안 끝났는지 확인한 뒤 바로 이어서 작업하면 된다. 이전 에이전트가 무슨 생각을 했는지 굳이 복구할 필요가 없다.
기본 루프는 의도적으로 아주 작게 잡았다.
관측 → 제한된 행동 하나 선택 → 행동 → 결과 관측 → 반복
체크 로직은 GREEN, RED, UNKNOWN 중 하나를 반환한다. 여기서 UNKNOWN이 중요하다. CI 접근이 끊겼거나, 센서 업데이트가 멈췄거나, 증거가 충돌하거나, 체크 로직 자체가 자기 주장을 입증할 수 없으면 결과는 무조건 알 수 없음이다. 증거가 없는데 성공으로 퉁치는 짓은 절대 안 한다.
에이전트는 자기가 의존하는 기계 장치를 직접 수리할 수도 있다. 체크 로직이 구라를 치면, 그 체크 로직을 고치는 게 작업이 된다. 명령어가 계속 멍청한 짓을 하면, 그 명령어를 바꾸면 된다. 즉, 이 시스템은 소프트웨어만 관측하는 게 아니라, 소프트웨어에 대한 결정을 내리는 데 사용되는 '관측의 품질'까지 관측한다.
