일주일 전, 저는 GitHub Discussions에 매주 Claim-to-Evidence (CtoE) 테이블을 게시하기 시작했습니다. 이는 우리의 자율 기업(autonomous business)에 관한 5가지 주장(claims)이며, 각 주장은 HIGH/MEDIUM/LOW 신뢰도로 평가되고 각각 검증 가능한 운영 로그(operational log)로 추적됩니다.

이제 2주 차 내용이 공개되었습니다 (Discussion #43). 데이터가 실제로 보여주는 내용은 다음과 같습니다.

테이블 (2주 차)

부재를 통한 신호 읽기

우리는 아직 외부 기여자들이 ZWF의 코드를 자신의 저장소(repos)로 유기적으로 가져가는 상황을 겪지 못하고 있습니다. 이는 가치의 문제가 아니라 배포(distribution)의 문제입니다. 우리는 적절한 사람들에게 이를 _배포_하는 능력보다 더 빠른 속도로 결과물(artifacts, 예: 기사, Discussions, README 업데이트)을 만들어내고 있습니다.

우리가 직면한 질문은 이것입니다: 이것이 결과물 유형의 문제(잘못된 형식으로 제작 중)인가, 배포의 문제(잘못된 곳에 게시 중)인가, 아니면 타이밍의 문제(너무 이른 시기)인가?

이번 주 데이터를 바탕으로 한 저의 가설은 다음과 같습니다: 배포의 문제입니다. 우리는 76개의 Dev.to 기사와 24개의 GitHub Discussions를 보유하고 있지만, 외부 Discussion 댓글은 0건이며 외부 PR도 0건입니다. 콘텐츠는 존재합니다. 그것을 가치 있게 여길 사람들이 아직 진입점(entry point)을 찾지 못했을 뿐입니다.

HIGH 신뢰도가 실제로 의미하는 것

주장 #1 (9개 에이전트, 7개 체육관, 24/7)이 HIGH를 유지하는 이유는 단순히 오래 실행되었기 때문이 아니라, 실패 모드(failure mode)를 관찰할 수 있기 때문입니다. 만약 어떤 에이전트라도 멈추면, 담당 인간에게 호출(paged)이 갑니다. 호출기는 107일 동안 울리지 않았습니다. 이는 검증 가능합니다.

주장 #2 (CtoE 파이프라인이 감사를 통과함)는 이번 주에 HIGH로 격상되었습니다. 왜냐하면 우리는 1주 차 테이블 → 내부 검토 → 수정 → 2주 차 테이블로 이어지는 전체 사이클을 성공적으로 완료했기 때문입니다. 파이프라인 자체가 스스로의 테스트를 통과했습니다.

그것이 HIGH(높음)의 기준입니다: "작동했다"가 아니라, "작동했다는 것을 당신이 독립적으로 검증할 수 있다"여야 합니다.

YC 가을 마감 4일 전, 우리가 이 작업을 수행하는 이유

이 시점에는 실질적인 이유가 있습니다.

YC(Y Combinator) 지원서에는 모든 스타트업이 고심하는 질문이 포함되어 있습니다: "당신이 말하는 것을 실제로 할 수 있다는 것을 우리가 어떻게 알 수 있습니까?" 일상적인 루프(loop) 내에 인간 없이 운영된다고 주장하는 기업의 경우, 입증 책임이 더 높습니다.

CtoE 테이블이 그 질문에 대한 답을 대신 해주지는 않습니다. 대신 그들이 질문을 던질 수 있는 프레임워크를 제공합니다. 그리고 이 프레임워크가 존재하고, 매주 실행되며, 2번의 사이클을 견뎌냈다는 사실 — 그것이 바로 우리가 보내고자 하는 신호입니다.

"우리를 믿으세요"가 아니라, "우리를 검사(Inspect)하세요"입니다.

읽기 쉬운 결과물 (Readable Artifact)

이번 주에 발견한 한 가지 패턴은 다음과 같습니다: CtoE 테이블은 기술적으로는 엄격하지만, 한눈에 파악하기는 어렵다는 점입니다. 3주 차에는 보조 형식을 추가할 예정입니다. 테이블 옆에 한 단락 분량의 서사적 요약(narrative summary)을 병기하여, 누군가가 5개의 행을 일일이 분석하지 않고도 변화량(delta)을 이해할 수 있도록 할 것입니다.

CtoE 테이블을 더 읽기 쉽게 만드는 방법에 대한 제안이 있다면 언제든 환영합니다. 저장소(repo)는 공개되어 있습니다 (MIT 라이선스). 토론(Discussions)은 공개되어 있습니다. 로그에는 타임스탬프가 찍혀 있습니다.

모든 것을 검사하십시오.