셀프 머지를 금지하는 규칙을 문서로 적었고, 그 문서가 그 규칙 아래 놓인 첫 풀 리퀘스트였다.
검토자는 아직 붙지 않은 상태였다.
규칙을 발효시키려면 규칙을 쓴 사람이 자기 규칙을 어기면서 머지해야 하는 순환이 열려 있었다.
문제
결정 기록은 둘로 나눴다.
기술 결정은 ADR(아키텍처 결정 기록)로 쌓고, 워크플로와 외부 협조와 통화 결과처럼 코드 바깥에서 갈리는 사내 상황은 별도의 비기술 결정 문서로 쌓았다.
둘 다 GitHub 풀 리퀘스트로 메인 브랜치에 누적하고, 매일 출근해서 머지하는 것으로 업무를 시작하는 구조였다.
회의와 녹음에서 나온 결정을 텍스트로 옮겨 메인 브랜치에 넣는 일은 내가 맡기로 확정됐다.
그 체계의 첫 규칙 중 하나가 셀프 머지 금지였다.
결정 문서는 팀의 기록이므로 작성자가 자기 문서를 그대로 통과시키지 못하게 막는 조항이다. 문제는 그 규칙을 담은 문서가 첫 셋업 풀 리퀘스트에 함께 실려 있었다는 것이다.
그 첫 풀 리퀘스트에는 기술 결정 문서 일곱 건과 비기술 결정 문서 세 건이 한꺼번에 실렸다(그 풀 리퀘스트 기록 기준).
기술 결정 문서 한 건은 그 뒤에 따로 올렸다.
체계를 세우는 작업이라 규칙을 정한 문서와 그 규칙을 적용받는 문서가 같은 묶음에 들어갔다.
온보딩 국면이라 그 저장소를 검토할 사람이 아직 없었다.
규칙을 발효시키려면 누군가 그 풀 리퀘스트를 머지해야 하고, 머지하는 순간 규칙의 첫 적용 사례가 규칙의 첫 위반 사례가 된다.
규칙이 자기 자신에게 걸렸다.
이 순환은 셋업 단계에만 생긴다.
검토자가 한 명이라도 배정되면 저절로 사라진다.
위반이 일어나기 전에 예외를 박았다
검수 라운드에서 수정 다섯 건이 나왔고(그 검수 라운드 기록 기준), 그중 핵심이 이 순환이었다.
고를 수 있는 답은 셋이었다.
규칙을 빼거나, 규칙을 남겨 둔 채 첫 번째만 조용히 어기거나, 예외를 문서에 적는 것이다.
앞의 둘은 값이 컸다.
규칙을 빼면 검토자가 붙은 뒤에 그것을 다시 넣을 근거가 사라진다.
조용히 어기면 그 규칙의 첫 실행 기록이 위반 기록으로 남고, 나중에 같은 예외를 요구하는 사람에게 댈 기준도 없어진다.
어느 쪽이든 문서와 실제 동작이 어긋난 채로 굴러가기 시작한다.
그래서 규칙 문서 안에 초기 셋업 예외를 한 조항으로 넣었다.
검토자가 배정되기 전의 셋업 풀 리퀘스트에 한해 작성자 머지를 허용한다는 내용이고, 그 아래에 종료 시점을 같이 적었다.
다음 회의 이후 이 예외는 끝난다.
예외의 이름을 초기 셋업으로 붙인 것도 같은 이유다.
언제 끝나는지가 이름에 이미 들어 있다.
조항에 만료 시점이 붙는 순간 예외는 편법에서 규칙의 일부가 된다.
예외 조항은 혼자 오지 않는다
같은 검수 라운드에서 함께 고친 것들이 전부 같은 성질이었다.
문서에 적힌 것과 실제로 있었던 일이 어긋난 지점을 하나씩 찾아 맞추는 작업이다.
그 라운드에서 고친 항목은 이렇다.
| 고친 항목 | 무엇이 어긋나 있었나 |
|---|---|
| 셀프 머지 금지 조항 | 그 조항을 담은 문서가 그 조항의 첫 적용 대상이었다 |
| 비기술 결정 문서의 시점 표기 | 회의에서 정해진 시점과 문서로 적은 시점이 구분되지 않았다 |
| 같은 문서들의 수정 방식 | 나중 수정이 원문을 덮어써 결정 당시의 상태가 남지 않았다 |
| 권한 관련 항목 | 사실과 다르게 적혀 있었다 |
| 기술 결정 문서의 용어 | 한 글자 차이로 뜻이 다른 단어가 들어가 있었다 |
시점 표기와 수정 방식은 한 묶음으로 처리했다.
결정이 회의에서 내려진 시각과 문서로 적힌 시각을 나눠 적게 하고, 이후 수정은 원문을 고치지 않고 아래에 덧붙이기만 하는 노트로 남기게 했다.
이렇게 두면 문서를 나중에 여는 사람이 결정 당시에 알려져 있던 것과 뒤에 추가된 것을 구분할 수 있다.
결정 기록에서 자주 무너지는 것이 이 구분이다.
나중에 알게 된 사실이 결정 당시의 판단으로 섞여 들어가면 그 기록은 근거로 쓸 수 없다.
권한 관련 항목은 사실과 다르게 적어둔 것을 정정했다.
용어 쪽은 hardness라고 적혀 있던 것을 harness로 고쳤다. 한 글자가 어긋나면 뜻이 통째로 달라진다.
규칙 문서 운영은 내용을 정한 뒤에 시작됐고, 어긋남을 계속 찾아내는 일이 그 운영의 대부분이었다.
자동화를 거절한 지점
결정 기록을 자동으로 작성하는 에이전트를 도입하자는 제안이 PM에게서 나왔다.
답은 한 줄이었다.
사람이 판단해야 정확하다.
그래서 회의와 녹음에서 나온 결정을 메인 브랜치에 넣는 일은 자동화 없이 내 시간으로 처리했다.
이 선택의 성격은 앞 두 절이 보여준다.
예외의 종료 시점을 어디에 걸지, 어떤 항목이 사실과 어긋났는지를 가르는 일은 문장을 만드는 작업보다 판정에 가깝다.
회의록에는 결정된 것과 논의만 된 것이 같은 무게로 섞여 있고, 둘을 가르는 기준은 그 회의에 있던 사람에게만 있었다.
그 기준을 자동화에 넘기려면 무엇이 결정인지를 먼저 문서로 굳혀야 하는데, 그 문서를 만드는 일이 아직 진행 중이었다.
자동화를 만드는 일을 하면서 자기 업무의 한 지점에서 자동화를 거절한 기록이다.
결론
거버넌스에서 지켜야 할 것은 규칙의 무결성보다 규칙과 현실이 어긋난 지점이 문서에 남는가다.
예외는 어차피 생기고, 규칙을 만든 사람이 그 규칙의 첫 대상이 되는 국면은 셋업 단계에서 거의 항상 나온다.
문서와 실제 동작이 어긋난 채로 남아 있는 상태가 규칙이 하나 적은 상태보다 위험하다.
그 국면에서 갈리는 지점은 예외에 끝을 적어 두었는가다.
만료 시점 없는 예외는 조항의 모양을 하고 관행으로 굳는다. 만료 시점이 붙은 예외는 다음 회의까지만 살아 있는 한시 조항이고, 그 회의의 안건 하나가 미리 잡힌다.
2026년 5월 말의 그 첫 풀 리퀘스트에서 고른 것은 셋 중 마지막, 예외를 조항으로 적는 쪽이었다.
한계·재검토 트리거
2026-09 기준 / 재검토 트리거: 만료 시점을 적어 둔 예외 조항이 그 시점을 지나고도 문서에 남아 발동한 사례가 한 건이라도 관측되면 이 판정을 다시 연다.