이슈에 적힌 설계가 틀렸다고 워커가 실측으로 반박해왔다 — 이슈 15건 자율 처리기

Об этом предложении

등록해 둔 GitHub 이슈 15건을 "처리해줘" 한 줄로 던졌습니다. 워크트리 15개, tmux 워커 15개가 붙어서 각자 하나씩 맡는 구조입니다. 사람 개입은 게이트 두 번 — 태스크 분할 승인과 병합 전 최종 확인뿐이었고요. 끝나고 보니 전체 스위트 2467개가 그린이었는데, 정작 기억에 남는 건 테스트 숫자가 아니라 워커들이 이슈에 적힌 대로 구현하기를 거부한 순간들 이었습니다. 먼저 결론부터 봅시다 이슈 문면은 계약이 아니라 가설 입니다. 이슈를 쓸 때 저는 코드를 다 보고 쓰지 않았어요. "이렇게 하면 되겠지"를 적어둔 겁니다. 그런데 워커는 그 문장을 명세로 받아서 그대로 구현하려 들죠. 여기서 "문면과 실측이 어긋나면 실측을 이겨서 보고하라"는 규칙을 걸어두면, 이슈를 쓸 때 잘못 생각한 것들이 구현 단계에서 드러납니다. "그 PK, 같은 DB에서 두 번 돌리면 충돌합니다" 가장 명확했던 건 아웃박스 테이블 이슈였습니다. 이벤트를 sqlite 테이블에 쌓아두고 외부에서 드레인하는 구조인데, 저는 이슈에 이렇게 적었습니다. emission_id 를 PK로 쓰라고요. 이벤트마다 붙는 고유 ID니까 당연히 PK라고 생각했습니다. 워커가 반박해왔습니다. emission_id 는 프로세스-로컬 카운터 라서 프로세스가 새로 뜨면 다시 처음부터 매겨진다는 것. 그래서 같은 DB 파일에 두 번째 실행을 붙이면 PK 충돌이 납니다. 추론이 아니라 실제로 돌려서 확인한 결과였습니다. 이건 제가 이슈를 쓸 때 놓친 게 맞습니다. 행의 정체성을 프로세스가 아니라 저장소가 소유 해야 한다는 걸 놓친 거죠. 결론은 seq를 도입해서 PK를 저장소 쪽으로 옮기는 것이었습니다. lnpl_outbox( seq INTEGER PRIMARY KEY AUTOINCREMENT, emission_id TEXT NOT NULL, event, payload TEXT(JSON), created_at, delivered_at NULL ) emission_id 는 PK 자리에서 내려왔지만 사라지진 않았습니다. 소비자 쪽 중복 감지(dedupe)에는 여전히 필요하거든요. 그리고 삭제 대신 delivered_at 상태 마킹을 쓰는 건 그대로 뒀습니다 — at-least-once가 성립하려면 소비 기록이 남아야 하니까요. 재밌는 건 이 결정이 뒤에 붙은 태스크로 그대로 흘러갔다는 점입니다. seq가 단조 증가하는 커서라서, 그다음 SSE 구독 태스크의 Last-Event-ID 로 그대로 쓸 수 있었습니다. 이슈 문면대로 갔으면 커서가 없어서 거기서 또 막혔을 겁니다. 이슈 안에서 두 문장이 서로 싸우고 있었다 다른 태스크에서는 워커가 구현을 멈추고 질문을 올렸습니다. 이슈에 이런 두 조건이 같이 적혀 있었거든요. 새 기능에 시드 정책을 적용한다 기존 예제의 출력은 바이트 동일 해야 한다 (회귀 기준) 시드를 적용하면 값이 바뀌고, 값이 바뀌면 바이트 동일이 깨집니다. 제가 이슈를 쓰면서 두 요구를 각각 적었는데, 붙여놓으면 동시에 만족할 수 없는 조합이었던 겁니다. 코디네이터로서 판정해야 했습니다. 시드는 조건 없이 일반 적용하고, "바이트 동일"의 범위를 컴파일 표면으로 한정 해석 하기로 했습니다. 대신 조건 세 개를 붙였어요 — 의미가 바뀐다는 사실을 RFC 문면에 명시할 것, 테스트 두 건이 시드 값 자체까지 단언하도록 강화할 것. 해석으로 넘어간 부분은 문서에 남겨야 다음 사람이 안 헤맵니다. 판정 근거를 문서에 남기지 않으면 반박이 무의미하다 이 런에서 규칙처럼 굳어진 게 하나 있습니다. 이슈 문면에서 이탈할 때는 이탈 근거를 문서에 남긴다. 새로 만든 RFC가 세 편(0028/0029/0030)인데, 그중 두 편이 이런 판정 기록입니다. 안 그러면 몇 주 뒤에 이슈를 다시 읽은 사람이 "여기 emission_id PK라고 적혀 있는데 코드는 왜 seq지?"에서 멈춥니다. 워커의 반박이 아무리 정확해도, 기록이 없으면 그냥 구현이 명세를 안 지킨 걸로 보입니다. 정작 사고는 병합에서 났다 자율 처리가 매끄러웠던 것에 비해, 제 손이 닿는 병합 단계에서 같은 실수를 두 번 했습니다. 브랜치를 합치면서 README 충돌을 --ours / --theirs 로 한 방에 정리했는데, 그때마다 다른 태스크가 추가한 RFC 표 행이 같이 날아갔습니다. 두 번 다 통합 스위트의 README 최신성 테스트가 즉시 잡아냈습니다. 복원 커밋으로 해소하긴 했지만, 두 번째에는 절차를 바꿨습니다 — 카운트 충돌을 해소하기 전에 양쪽 diff에서 카운트가 아닌 변경분을 먼저 대조 하는 것으로요. 충돌 해소는 "둘 중 하나 고르기"처럼 보이지만, 표가 걸려 있으면 사실은 병합입니다. 배운 것 자율 처리 런의 품질은 워커가 얼마나 똑똑한가보다 어긋남이 올라올 채널이 있는가 에 더 달려 있었습니다. 이슈 문면을 계약으로 두면 워커는 틀린 설계를 성실하게 구현해냅니다. 가설로 두면 실측이 올라오고, 대신 코디네이터가 매번 판정을 해야 합니다. 15건 중 두 건에서 판정이 필요했으니 비용이 크진 않았어요. 그리고 사람이 개입한 구간이 제일 위험했다는 게 좀 웃깁니다. 워커 15개가 만든 코드는 리뷰와 스위트를 통과했는데, 정작 제가 손으로 한 --ours 두 번이 데이터를 날렸으니까요. 테스트가 없었으면 조용히 넘어갔을 겁니다.

Детали предложения