인프라 문서가 라이브 설정의 거울이 되다
목차
도메인 자동화 구조를 라이브에 적용하고 문서화했다. 작은 변경처럼 보이지만, 인프라 문서가 실제 운영 상태를 정확히 반영하는 것이 얼마나 중요한지 다시 한 번 느낀 작업이다.
와일드카드 DNS란 무엇인가
와일드카드 DNS(*.saju.opsvoro.com)는 특정 도메인의 모든 서브도메인을 하나의 IP 주소로 라우팅하는 설정이다. 구체적으로:
기존 방식 (와일드카드 없음):
- api.saju.opsvoro.com → 1.2.3.4
- admin.saju.opsvoro.com → 1.2.3.4
- web.saju.opsvoro.com → 1.2.3.4
- (각각 등록 필요)
와일드카드 적용:
- *.saju.opsvoro.com → 1.2.3.4
- (모든 서브도메인 자동 커버)
이렇게 하면 새로운 마이크로서비스나 관리 도구를 추가할 때마다 DNS 레코드를 하나씩 등록할 필요가 없다. 인프라 확장 속도가 빨라지고, 관리 포인트도 줄어든다.
문서화가 운영에 미치는 영향
여기서 중요한 포인트는 "라이브 반영"이라는 표현이다. 단순히 DNS를 바꾸고 끝내는 게 아니라, 그 결과를 운영 문서에 정식으로 기록하는 것이 팀의 신뢰도를 결정한다.
팀을 리딩하는 입장에서, 인프라 문서는 다음 역할을 한다:
- 새 팀원의 온보딩: "우리 도메인 구조가 어떻게 되어 있는가"를 빠르게 학습할 수 있다.
- 장애 대응: 밤 3시에 도메인 관련 오류가 발생했을 때, 문서가 현재 상태를 정확히 반영하고 있으면 진단 시간이 절감된다.
- 의사결정 근거: "왜 이런 구조로 했는가"를 기록해두면, 추후 개선이나 마이그레이션 시 판단 자료가 된다.
만약 문서가 실제 설정과 어긋난다면? 팀 내 불신이 쌓인다. "문서는 구시대 정보인가 봐" 하면서 각자 다른 정보 소스를 참고하게 되고, 의사결정이 분산된다.
비슷한 작업에서의 베스트 프랙티스
이번 경험에서 얻은 교훈을 일반화하면:
1. 설정 변경과 문서 동기화의 순서
- 설정 변경 후 → 문서 업데이트: 이 순서는 인정. 실제 프로덕션에서 문제가 없는지 확인 후 문서화하는 것이 안전하다.
- 단, 문서 업데이트 자체를 빼먹지 말 것. 변경을 했으면 반드시 기록해야 한다.
2. 문서의 범위와 정확도
단순히 "와일드카드 DNS 추가됨"이라 한 줄 쓰는 게 아니라:
- 왜 이 결정을 했는가 (배경)
- 어떤 서브도메인들이 영향받는가 (범위)
- 혹시 예외 케이스가 있는가 (경계 사항)
- 앞으로 어떻게 유지할 것인가 (유지보수 계획)
3. 버전 관리와 변경 로그
문서 시스템(Git, Confluence, 위키 등)에서 변경 히스토리를 남기면, 나중에 "이건 언제 어떻게 바뀌었는가"를 추적할 수 있다.
개인적 회고
작은 변경처럼 보이지만, 이 과정은 팀의 운영 신뢰도를 한 단계 높이는 일이었다. 특히 인프라 영역은 한 번 설정을 잘못하면 되돌리기 어려운 경우가 많기 때문에, "문서화라는 보조 작업"이 실제로는 가장 중요한 리스크 관리 수단이다. 응급 상황에서 문서가 정확하면 빠르게 판단할 수 있고, 그렇지 않으면 추측과 재확인으로 시간을 낭비한다.
앞으로 어떤 인프라 변경이든, 문서를 "라이브 환경의 거울"로 유지하는 것을 기준으로 삼을 생각이다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.