일기 slecs

외부 도메인 등록 시 inventory와 정책 동시 문서화

목차

새로운 도메인(blindboxdex.com)을 K3 외부 인프라에 등록하고, 이를 docs 폴더의 두 곳에 동시에 기록했다. 단순해 보이는 작업이지만, 인프라 투명성과 팀 온보딩 관점에서 꽤 중요한 선택이 있었다.

왜 도메인 등록 시 문서화가 필수인가

팀이 성장하면서 운영하는 도메인과 서비스가 늘어난다. 그런데 많은 팀이 도메인 등록 자체는 하면서도, "어느 인프라에 등록됐는지", "누가 관리하는지", "정책이 뭔지"를 남기지 않는 실수를 한다. 그러다가 장애가 터지면:

  • "아, 이 도메인 누가 등록했지?"
  • "왜 갑자기 DNS 응답이 느려?"
  • "여기도 보안 정책 적용해야 하나?"

이런 질문들이 Slack 쓰레드를 돌고, 시간을 낭비한다. 훨씬 최악인 경우는 도메인 유효기간 만료를 놓친다든지, 중복 등록이 되기도 한다. 이번에는 등록 직후 즉시 문서화해서 이런 문제를 미리 차단하기로 했다.

두 문서에 기록한 이유

문서 역할 기록되는 정보
hedvion-CLAUDE.md (inventory) 단일진실 소스. 모든 인프라/도메인의 master list 도메인명, 인프라 위치(K3), 등록일, 담당자
sites-detail.md 도메인별 정책 & 운영 규칙 해당 사이트의 콘텐츠 정책, SEO 설정, 인증 정책, 모니터링 규칙

이 둘을 분리한 이유는 관심사의 분리다. Inventory는 "우리가 뭘 관리하고 있는가"의 답변. Sites-detail은 "각각을 어떻게 다뤄야 하는가"의 답변이다.

신입이 온보딩될 때, inventory를 읽으면 전체 그림이 보인다. Sites-detail을 읽으면 각 도메인의 운영 방식과 제약을 안다. 한 파일에 모두 섞이면 너무 크고 복잡해진다.

비슷한 작업에서의 베스트 프랙티스

도메인을 등록할 때마다 같은 패턴을 따르도록 정했다:

  • 등록 직후 inventory에 기록 (누락 방지)
  • 정책/콘텐츠 제약이 있으면 sites-detail 추가 (팀 전체가 숙지)
  • CI/CD, 모니터링 설정 후 문서에 링크 (운영 자동화 추적)
  • 담당자 연락처 기록 (장애 시 빠른 대응)

이 과정 자체가 "정말로 필요한 도메인인가", "중복은 없나" 재검토 기회가 된다. 문서화를 미루면 나중에 "어라, 이 도메인 뭐지?" 하는 좀비 도메인이 남기도 한다.

팀 관점에서의 의미

인프라 투명성은 팀 신뢰의 기초다. 누구든 docs/ 를 열면 우리 시스템의 윤곽이 보여야 한다. 그래야 온보딩이 빠르고, 변경할 때도 영향도가 명확해진다.

이번 작업은 작아 보이지만, 이런 규율이 쌓여야 "인프라 관련 의사결정을 문서 기반으로 한다"는 팀 문화가 만들어진다. 그게 결국 야근과 장애를 줄인다.


🛒 이 글과 어울리는 추천 상품

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.

댓글 0

첫 댓글 달아줘.