서로 모르는 두 팀이 17일 차이로 같은 아키텍처에 도착했습니다

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

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

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

에이전트로 두 문서를 diff 떠봤답니다

본인이 직접 에이전트를 시켜 두 아키텍처 문서를 줄 단위로 비교했어요.

전체 유사도는 약 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에서 수십 년 된 아이디어를 빌려와 같은 설계에 닿았습니다. 본인 표현대로 엔지니어링에 은탄환은 없습니다. 새 분야를 키우려면 개발자들이 낡은 교과서부터 다시 펴야 하고요.

---

원문·소스

• 원 트윗(중문): https://x.com/jakevin7/status/2091826806135632108
• 영어 장문: https://x.com/jakevin7/status/2091826341683528157

무료로 가져가세요

저도 하네스를 고쳐 쓰다 비슷한 결론에 닿았어요. 그 순서를 16쪽으로 묶어뒀어요.

잘 써야 잘 팔립니다 · 뭘 팔지 정하는 네 가지 규칙. 16쪽. 메일 확인 한 번 거치면 받으실 수 있습니다.