2026년 6월 22일, Martin Tournoij(arp242)가 짧은 글을 발표했다. 제목은 고전적인 원칙에서 한 글자만 바뀌었다 — Fence가 Finger가 되었다. 이 언어유희 뒤에는 실제 소프트웨어 엔지니어링 재앙 현장이 있었다. 그는 13년 된 코드베이스를 인수받았고, 그 전에 있던 사람들은 모두 떠났다. git log에는 총 295줄의 커밋 설명이 있었지만, dependabot 자동 커밋과 “fix typo”를 제외하면 단 167줄만 남았다. 월평균 한 줄 꼴이었다. 설계 문서도 없었고, 코드에는 거의 주석이 없었다. 완료되지 않은 리팩토링, 삭제된 기능의 잔해, 그리고 작성되었지만 어떤 페이지에서도 참조되지 않은 기능들이 남아 있었다.
Tournoij는 이것을 체스터턴의 중지(Chesterton’s Finger)라고 불렀다. “그래, 우리는 이 모든 이상한 일들을 했고, 아무에게도 그 이유를 말할 생각이 없어. ㅎㅎ, 엿 먹어라.”
Chesterton’s Fence 원칙은 G.K. Chesterton의 1929년 저서 《The Thing》에서 유래했다. 우화는 간단하다: 한 개혁가가 길 한복판에 서 있는 벽을 보고 쓸모없다며 허물려고 한다. Chesterton이 말한다: 허물기 전에, 왜 처음에 지었는지 먼저 이해하라. 아직 그 이유를 모를 수도 있지만, 그 이유는 분명 존재했다. 이 원칙은 소프트웨어 엔지니어링 커뮤니티에서 반복적으로 인용된다. 정확히 빈번한 사고 시나리오를 맞히기 때문이다: 누군가 “쓸모없어 보이는” 코드를 삭제하고, 몇 달 후 프로덕션이 다운된다. 그 코드는 3년에 한 번씩 트리거되는 경계 조건을 처리하고 있었다. 아무도 그 코드가 왜 거기에 있는지 알지 못했다. 원래 작성한 사람은 이미 2년 전에 퇴사했기 때문이다.
arp242가 Fence를 Finger로 바꾼 것은 단순한 장난이 아니다. Tournoij가 경험한 코드베이스의 문제는 코드가 나쁘게 작성되었다는 것이 아니다 — 나쁜 코드는 어디에나 있다. 문제는 “왜”에 대한 기록을 아무도 남기지 않았다는 것이다. 13년간의 축적된 결정, 모든 트레이드오프, 모든 역사적 제약, 모든 밟아본 함정이 전부 증발했다. 인수자는 “벽을 넘는” 상황이 아니었다 — 벽은 적어도 가시적인 물리적 존재로서 “여기서 누군가 한때 결정을 내렸다”는 것을 암시한다. 그가 마주한 것은 완전한 정보의 진공이었다. 이것은 벽보다 훨씬 나쁘다. 벽은 침묵의 알림이고, 중지는 침묵의 조롱이다.
이 차이는 코드 주석의 가장 핵심적인 가치를 찌른다. 코드 자체는 이미 “무엇을 했는지” 말해준다 — 언어가 의도적으로 난독화되지 않았다면 로직을 읽을 수 있다. 하지만 코드는 결코 “왜 A 대신 B를 선택했는지”를 말해주지 않는다. 그 기괴한 workaround는 특정 라이브러리 버전의 버그 때문이었고, 그 불필요해 보이는 null 검사는 2019년 어느 금요일 오후의 P0 사고 때문이었으며, 그 이상한 정렬 로직은 하류 시스템이 순서에 하드 의존성을 가지고 있었고 그 의존성 자체가 역사적 실수였기 때문이다. 이 정보들이 주석이나 커밋 메시지에 없으면 영원히 사라진다. Tournoij의 질문은 매우 직설적이다 — 이것을 작성하는 것은 선택적인 추가 작업이 아니라, 개발 작업의 일부다. 잘 쓰지 못해도 괜찮고, 영어가 서툴러도 괜찮으며, 일부 세부 사항을 잊어도 괜찮다. 하지만 적어도 “무언가”는 있어야 한다. 아무것도 없는 것은, 모든 후임자에게 중지 손가락을 내미는 것이다.
Lobsters 토론에서 ChrisDenton(18표)은 이 주제를 조직 수준으로 끌어올렸다. 그는 더 교묘한 딜레마를 지적했다: 때로는 그 순간에 어떤 정보가 나중에 중요해질지 아무도 알 수 없다. 결정을 둘러싼 논의가 기록되지 않았다면 — 이메일, 채팅 기록, 이슈를 막론하고 — 후대의 “디지털 고고학”은 거의 불가능하다. 그리고 조직이 개발자를 상호 교환 가능한 부품으로 취급할 때, 이러한 취약성은 극대화된다. 아무도 충분히 오래 머물지 않고, 아무도 시스템 전체에 대한 직관적 이해를 축적하지 못하며, 같은 실수가 반복되고, 바퀴의 재발명이 일상이 된다. ChrisDenton의 표현은 절제되어 있지만, 결론은 날카롭다: 개발자를 상호 교환 가능한 부품으로 취급하는 조직이 가장 취약한 조직이다.
david_chisnall(8표)은 코드 리뷰의 관점에서 한 방 더 먹였다. 그는 코드 리뷰의 가장 큰 가치는 명확하지 않은 결정에 주석을 달도록 강제하는 것이라고 말했다 — 버그 발견은 부산물일 뿐이다. 가장 큰 가치는 “두 번째 사람이 명확하지 않은 결정에 주석을 달도록 강제하는 것”이다. 그는 자신이 명확하지 않다고 생각되는 부분에 주석을 쓴다. 리뷰어는 리뷰어가 명확하지 않다고 생각되는 부분에 질문한다. 두 라운드를 거치면 주석은 두 사람이 각각 설명이 필요하다고 생각한 부분을 커버한다. 후임자가 이 코드를 읽을 때, 이해할 확률이 더 이상 0이 아니다. 이 메커니즘의 교묘함은 작성자의 자각에 의존하지 않는다는 점이다 — 지식 보존을 반드시 수행해야 하는 프로세스에 내장시킨다.
하지만 모든 벽이 남아 있어야 할까? 문제에는 반대 측면도 있다. Steph Tulkens는 《Chesterton’s Gap》을 썼다 — 벽이 아직 세워지지도 않았는데, 일단 벽부터 세우라는 것이다. 과도한 보수주의도 해롭다: 모든 팀은 아무도 건드리지 못하는 전통 코드를 본 경험이 있다. 주변 로직은 세 번이나 바뀌었고, 그 코드가 원래 처리하던 문제는 더 이상 존재하지 않을 수 있지만, “원래 왜 작성되었는지 모르니까” 계속 남아 있다. 기술 부채는 코드를 마구 고쳐서만 생기는 것이 아니다. 코드를 고치지 못하는 것도 기술 부채를 축적한다. 언제 벽을 허물고 언제 남겨둬야 하는지, 자동으로 판단해주는 알고리즘은 없다. 판단력은 시스템에 대한 충분히 깊은 이해에서만 나온다 — 이것은 정확히 ChrisDenton의 주장으로 돌아간다: 조직이 개발자를 교체 가능한 부품으로 취급한다면, 이런 판단력조차 기를 수 없다.
다음은 질문 목록 형태의 단순화된 판단 프레임워크다:
| 차원 | 보존 쪽으로 | 제거 쪽으로 |
|---|---|---|
| 컨텍스트 획득 가능성 | 원 팀 전원 퇴사, 문서/주석 없음 | 원 의사결정자仍在, 직접 물어볼 수 있음 |
| 변경 영향 범위 | 핵심 비즈니스 경로 관련, 오류 시 결과 심각 | 고립된 모듈, 완전한 테스트 커버리지 있음 |
| 코드 의도 명확성 | ”왜”를 설명하는 주석 있음, 로직 일관됨 | 주석이 “무엇을”만 설명하고 코드 동작과 불일치 |
| 트리거 빈도 | 낮은 빈도지만 높은 영향의 경계 조건 처리 | 코드가 실행되지 않음이 입증됨 |
| 대체 비용 | 재작성 시 모든 경계 조건 재발견 필요 | 명확한 사양서를 참조하여 재작성 가능 |
이 표는 어떤 문제도 해결하지 않는다. 단지 상기시켜줄 뿐이다: 벽을 허물지 말지 판단하는 것은, 허물기 자체보다 더 많은 정보를 필요로 한다.
Tournoij의 글은 Lobsters에서 82표를 받았다. 그가 새로운 것을 말했기 때문이 아니다. Chesterton’s Fence는 소프트웨어 엔지니어링 커뮤니티에서 10년 넘게 논의되어 왔다. 공명은 그가 명명한 감정에서 비롯되었다 — 나쁜 코드를 작성하는 것이 반드시 악의를 의미하지는 않지만, 설명 한 줄 없이 떠나는 것은 모든 후임자에 대한 경멸이다. 새벽 3시에 “이해할 수 없는 전통 코드” 때문에 깨는 모든 개발자는 이 중지 손가락을 알아본다. 그것을 고치는 데 더 많은 프로세스 규칙이 필요한 것이 아니라, 커밋 메시지를 인도물의 일부로 간주하는 것만으로 충분하다. 13년 동안의 167줄 — 그 숫자 자체가 가장 효과적인 논증이다.