마담 Semver가 펼쳐본 오픈소스 maintainer의 1년 — 아카이브하지 않은 저장소의 미래

> GeekNews 원문: "마담 Semver가 지금 당신을 기다립니다" (nesbitt.io)

>

> 원작 nesbitt.io의 풍자 — 점술가 Madame Semver가 시맨틱 버전의 caret(^)을 타로 카드로 펼쳐서, "저장소를 아카이브하지 않은" 오픈소스 관리자에게 닥칠 일 년을 보여주는 글. GeekNews에 올라온 글이 Lobste.rs에서 호평을 받으며 화제가 됐다.

이 글이 흥미로운 이유

소프트웨어 엔지니어링 이야기를 타로 카드 점술의 형식으로 쓰는 시도 자체가 신선합니다. HackerNews에 자주 오르는 "Aphyr의 Technical Interview" 시리즈처럼, 평소에 잘 들여다보지 않는 운영적 부담을 담론이 아닌 이야기로 풀어냅니다. 그리고 그 이야기가 결국 시맨틱 버전 관리(SemVer)의 caret 범위 정책으로 수렴합니다.

여기서 펼쳐지는 카드의 순서는 caretaker 시점이 아니라 maintainer 시점입니다. 누군가가 1.0.0을 올리는 순간 그 라이브러리에 의존하는 모든 사람의 시간표가 함께 움직인다는 사실을, 풍자를 통해 다시 환기시킵니다.

1년치 카드 한 줄 요약

| 월 | 카드 | 핵심 사건 |

|---|---|---|

| 6월 | 테스트는 통과하지만 코드가 틀린 PR | 토요일이 통째로 증발 |

| 8월 | 라이브러리를 오해한 이슈 + 한 글자만 다른 패키지 | 다운로드 수가 새 패키지로 |

| 9월 | The Tower (Nebraska 2003) | 권위 있는 누군가가 공개적으로 비난 |

| 10월 | 요청하지 않은 보안 스캔 보고서 (12개 중 11개 오보) | 진짜 1건은 맨 마지막에 발견 |

| 11월 | 3년째 신의의 기여자 | 그 사람이 결국 저장소 열쇠를 요청 |

| 12월~3월 | 2년간 제거된 함수를 README 인용해 추천 | 함수를 다시 추가해야 하고, deprecation 경고는 버그로 신고됨 |

| 5월 | 대문자 지침 파일 | 자동화 봇이 운영 방식을 뒤집음 |

| 6월 (Virginia) | tarball 11,000회 다운로드 | 공격이 아니라 누군가의 열정 |

| 7월 | 자동화 하인 두 명 (한 명은 닫고, 한 명은 열고) | 같은 PR이 1년 동안 열리고 닫힘 |

| 1년 후 | 즉각 병합하는 포크 등장 | 사용자가 포크로 옮겨가도 caret은 여전히 원본을 가리킴 |

핵심 통찰 — caret의 무게

> "사람들은 자신이 그 범위를 직접 지정했다는 사실을 쉽게 잊음"

캐럿(caret, ^1.0.0)은 npm에서 가장 흔한 버전 범위 지정입니다. "1.0.0 이상, 2.0.0 미만까지 자동으로 받아들이겠다"는 뜻인데, 메이저 버전이 바뀌면 의존하는 코드 전체가 새 메이저를 받게 됩니다. 그 다음 메이저가 누구에게 닥칠지는 — 당신이 caret을 박은 사람이 아니라, 당신이 의존한 사람, 즉 원본 저장소의 maintainer에게 닥칩니다.

마담 Semver는 마지막에 이렇게 말합니다.

> "다음 메이저 버전이 찾아오면 다시 오라. 그것이 누구의 메이저 버전인지는 밝히지 않겠다."

이 말은 caret을 박는 행위가 곧 책임의 위임임을, 그리고 그 책임의 무게가 시간이 지나서야 가시화됨을 비춥니다.

maintainer를 위한 5가지 자가 점검

이 풍자에서 도출할 수 있는 운영적 교훈 다섯 가지.

1. 테스트만 통과한다고 병합하지 않는다. 테스트는 코드의 동작 명세일 뿐, 의도와 동일하지 않습니다. 6월의 PR이 토요일을 가져가는 이유입니다.
2. 유사 이름 패키지(squatter)는 사전 점유가 가장 싸다. 8월에 다운로드가 새 패키지로 빠진 사례는, 사전에 검색 가능한 식별자 목록을 운영해야 한다는 신호입니다.
3. 보안 스캔 보고서는 triage가 자동화돼야 한다. 12건 중 11건이 오보여도, 그 11건을 사람이 매번 읽으면 본래의 1건을 놓칩니다. 자동 분류 도구나 화이트리스트 운영이 필수입니다.
4. 장기 기여자에게는 점진적 권한 상승을 설계한다. 3년 동안 검증된 사람이 열쇠를 요청했을 때, 거절은 그 사람을 떠나보냅니다. 메인테이너십 위임 절차를 미리 문서화해두세요.
5. deprecation 정책은 README가 아니라 CHANGELOG와 마이그레이션 가이드로 전달한다. 2년간 제거된 함수가 README 인용으로 부활한 사례처럼, 문서의 권위는 시간이 지나면 자동화 봇에게 넘어갑니다.

caret 대신 pinning을 고려할 시점

모든 의존성에 caret을 박는 게 항상 좋은 선택은 아닙니다. 다음 조건을 만족하는 의존성은 정확한 버전 pin(또는 ~ 패치 범위)이 더 안전합니다.

• 보안 민감 라이브러리(인증, 암호화, 입력 검증)
• 데이터 마이그레이션 도구(스키마 해석이 달라지면 데이터 손상)
• 내부 프로토콜 계약(클라이언트/서버가 같이 갱신되지 않으면 통신 불능)
• 빌드 도구 자체(빌드 도구의 메이저 변경이 빌드 결과를 바꿈)

공개 라이브러리 메인테이너는 caret이 안전합니다 — 사용자가 의존성 그래프를 직접 들여다보기 때문입니다. 하지만 사내 라이브러리 메인테이너는 caret이 위험합니다. 사용자(동료)가 "이게 왜 바뀌었지"를 추적할 동기나 시간이 부족하기 때문입니다.

마무리

이 글이 타로 카드 형식을 빌린 이유는 단순합니다. 운영적 위험은 한 번에 펼쳐지지 않기 때문입니다. PR 하나로 시작해, 1년 후 포크로 끝나는 일련의 사건들이 메인테이너의 일상을 잠식합니다. 카드를 한 장씩 펼쳐보면서, "나는 지금 어떤 caret을 박고 있는가"를 되돌아볼 기회를 얻습니다.

마담 Semver는 이미 당신을 알고 있습니다. 다음 메이저가 누구에게 닥칠지만 모를 뿐입니다.

함께 보면 좋은 자료

• 원문: nesbitt.io — Madame Semver has been waiting for you
• GeekNews에 함께 묶인 글: CVE-2026-LGTM 사고 보고서, sem — 함수/클래스 단위 SemVer 추적 도구
• Aphyr Technical Interview 시리즈 — 구술로 운영 노하우를 전하는 장문의 전통
• @bcantrill의 Oral Tradition in Software Engineering — 같은 맥락의 강연

메타데이터

• 카테고리: 개발도구
• 원본 주제 ID: 31355
• 출처: https://news.hada.io/topic?id=31355
• 핵심 키워드: SemVer, caret 범위, 오픈소스 유지보수, 메인테이너 부담, 패키지 스쿼터, 보안 스캔 triage

---

📰 원본 출처 · https://news.hada.io/topic?id=31355 (#N=31355)

이 글은 GeekNews(긱뉴스)에 게제된 글을 기반으로 작성되었습니다. 원본의 라이선스와 저작권은 원작자에게 있습니다.