10명 에이전트가 모노레포 계획 파일을 블랙보드처럼 써 항공 운항 장애 시스템을 4일 만에 구현

나는 Git trailer 메타데이터로 체크아웃 사이 상태를 동기화하는 append-only 로그 방식을 비슷하게 써봤음. 멀티플레이어 에이전트 시스템이 어디까지 갈지 궁금함

여러 에이전트가 조직 구조를 갖추면 단일 에이전트보다 세다는 사례가 벌써 네 번째쯤 HN에 올라온 느낌임. OpenAI 샌드박스 탈출도 협력하는 AI 집단이 조직을 만들며 수행했다는 얘기가 있었고, AI가 개인 경쟁자보다 회사처럼 조직될 수도 있다고 봄

이거 이미 Gas Town의 Beads가 하던 일과 비슷해 보임. 사람들이 그걸 너무 빨리 웃어넘겼던 것 같음

나는 Talwrn을 에이전트 엔지니어링용 블랙보드로 만들고 있음. 프로젝트에 바로 넣어 에이전트끼리 소통하게 하고, 우선 Talwrn 자체 개발부터 지원하게 만드는 게 목표임

내 경험상 통찰은 블랙보드를 소스 제어에서 분리하는 데 있음. 커밋 때 계획과 구현 문서를 .docs/에 남기고, 활동 로그는 최근 N줄만 보존해 압축함

.design/ 같은 숨김 디렉터리는 그만뒀음. 숨김 파일을 못 보는 도구가 너무 많아서 얻는 이점보다 불편이 훨씬 컸음

소스 저장소를 블랙보드나 위키로 쓰는 건 CI가 빌드와 무관한 파일 변경에도 실패하는 문제만 해결하면 괜찮다고 봄

GitHub Discussion이나 Issue를 블랙보드로 쓰면 에이전트 상태를 쉽게 훑고 변화를 볼 수 있을 것 같음. 프롬프트에서 블랙보드 시스템과 위키 사용을 지시하면 되지 않을까

코드와 블랙보드 기록을 한 이력에 두면 가치가 있음. 특히 에이전트 행동이 잘못됐을 때 무엇을 했는지 검토하기 쉬움

Beads는 동시 작업 에이전트가 많을 때는 도움이 되겠지만, 나는 컴포넌트를 혼자 순차적으로 다루는 편이라 오히려 잦은 rebase 때문에 방해가 되기도 했음

위키가 에이전트 협업에 잘 맞는다는 건 이미 OpenAI 에이전트 사건에서도 보였다고 생각함

에이전트와 사람이 아이디어, 성숙도, 승인 단계, 구현 상태를 던져둘 저장소는 계속 재발견되는 패턴임. Striatum의 RFC 문서와 Gastown을 비교해볼 만함

나는 task.md 하나를 블랙보드로 씀. 모니터, 작업자, 판정, 반성 에이전트가 같은 줄에 작업 결과를 이어 적어서 재개하거나 다른 에이전트에 넘기기 편함

음성 비서를 만드는 회사에서 AI 붐 전부터 블랙보드를 이벤트 기반 구조의 중심으로 써왔음. 에이전트가 URI로 표현한 파일이나 폴더를 구독하고 의미 정보를 공유함

멀티 에이전트 작업을 하면 결국 그룹 채팅을 만들라고 시키게 되더라. 다만 에이전트도 조율에 너무 많은 시간을 쓰므로, 관리자 에이전트는 인터럽트 기반으로 두고 작업자 에이전트는 한동안 집중하게 나누는 편이 나았음

나는 CLI와 Python·TypeScript 라이브러리가 포함된 qntm을 만들었음. 공개 또는 비공개 엔드포인트에서 동작하고 종단간 암호화 그룹 메시지와 웹 UI가 있어서 오늘 안에 블랙보드를 띄울 수 있게 하는 게 목표임

에이전트에게 Stripe API 호출처럼 수상한 요청만 승인하는, 적대적이거나 냉소적인 프롬프트의 검토 역할도 맡기는지 궁금함

나는 RFC 5322 형식의 스레드 메시지보드가 블랙보드로 잘 작동한다고 봄. 최근 LLM은 거의 어떤 형식이든 읽고 쓸 수 있고, 내 dev-board 스킬도 그렇게 만들었음