Pi와 Maka 하네스 문서의 유사도는 어느 정도였나요?

에이전트로 두 아키텍처 문서를 줄 단위로 비교한 결과 전체 유사도는 약 50%였고, 로그가 진실이고 상태는 투영이다라는 핵심 원리와 툴 부작용 경계는 약 80%가 겹쳤습니다.

두 하네스가 공통으로 도착한 지점은 무엇인가요?

예비 로그(WAL), 이벤트 소싱, 복구 가능한 지속 연산이라는 데이터베이스의 고전 원리입니다. 에이전트가 죽었다 살아나도 이어서 달리려면 DB가 크래시에서 살아남는 법을 배워야 한다는 뜻입니다.

Pi는 원 연산을 살려둔 채 resume()으로 이어가고, Maka는 옛 Run을 봉인하고 새 runId로 다시 시작합니다. 같은 원리 위에서 복구 철학만 갈렸습니다.

Pi의 harness v2 문서를 본 Maka 개발자가 놀랐습니다. 자기 팀이 만든 파이프라인과 거의 같았거든요. 그가 올린 트윗 한 줄이 조회 10만을 넘겼습니다.

"Pi 새 아키텍처와 Maka가 말해준다. 하네스의 답은 DB 논문에 진작 있었다!!"

올린 사람은 Apache Arrow, DataFusion, Doris 세 프로젝트의 PMC입니다. 데이터베이스로 밥 먹고 산 사람이 하네스 판을 보고 내린 진단이에요.

말로만 비슷하다는 게 아닙니다. 본인이 에이전트를 시켜 두 아키텍처 문서를 줄 단위로 비교했어요.

전체 유사도는 약 50%. 그런데 핵심으로 들어가면 달라집니다. "로그가 진실이고, 상태는 투영이다"라는 원리와 툴 부작용 경계(의도 기록, 실행, 결과 기록)는 약 80%가 겹쳤어요.

공유한 용어도, 타입 이름도, 문서 구조도 없었습니다. 시점도 독립적이에요. Maka의 로그 챕터가 7월 12일, Pi의 harness-v2 문서가 7월 29일. 17일 차이로 같은 곳에 도착한 겁니다.

두 팀이 만난 지점은 새 발명이 아니라 DB의 고전이에요. 예비 로그(WAL), 이벤트 소싱, 복구 가능한 지속 연산. 에이전트가 죽었다 살아나도 이어서 달리려면, 결국 DB가 크래시에서 살아남는 법을 배워야 한다는 겁니다.

갈림길도 있습니다. 크래시 복구에서 Pi는 원 연산을 살려둔 채 resume()으로 잇고, Maka는 옛 Run을 봉인하고 새 runId로 다시 시작해요. 병렬 처리도 Pi는 lane, Maka는 자식 Session. 같은 원리 위에서 복구 철학만 갈린 거죠.

이벤트 재실행은 부작용 재실행이 아니라는 지적이 달렸어요. 로그에 툴 시작만 있고 결과가 없으면 상태를 모르는 채로 남고, 같은 연산 ID로 외부와 대사를 맞추지 않으면 결제와 메일이 두 번 나간다는 겁니다.

DB 이론을 들여오면 DB의 숙제도 같이 옵니다. 멱등성은 하네스에서도 공짜가 아니에요.

저자의 해석이 이 사건의 핵심이라고 저는 봅니다. 독립된 두 팀이 다른 길로 같은 곳에 도착하면, 그 방향이 맞을 확률이 높다.

하네스마다 자기만의 마법을 내세우던 시기가 끝나가는 신호로 읽혀요. 합의는 OS와 DB에서 빌려온 것이고, 수십 년 된 아이디어입니다. 본인 표현대로 엔지니어링에 은탄환은 없습니다. 새 분야의 성숙은 낡은 교과서를 다시 펴는 데서 시작하고요.

저도 하네스를 고쳐 쓰다 같은 자리에 닿았어요. 그 순서를 16쪽으로 묶어뒀어요.

FAQ

Pi와 Maka 하네스 문서의 유사도는 어느 정도였나요?: 에이전트로 두 아키텍처 문서를 줄 단위로 비교한 결과 전체 유사도는 약 50%였고, 로그가 진실이고 상태는 투영이다라는 핵심 원리와 툴 부작용 경계는 약 80%가 겹쳤습니다.
두 하네스가 공통으로 도착한 지점은 무엇인가요?: 예비 로그(WAL), 이벤트 소싱, 복구 가능한 지속 연산이라는 데이터베이스의 고전 원리입니다. 에이전트가 죽었다 살아나도 이어서 달리려면 DB가 크래시에서 살아남는 법을 배워야 한다는 뜻입니다.
크래시 복구 방식에서 두 하네스는 어떻게 갈리나요?: Pi는 원 연산을 살려둔 채 resume()으로 이어가고, Maka는 옛 Run을 봉인하고 새 runId로 다시 시작합니다. 같은 원리 위에서 복구 철학만 갈렸습니다.