검색 인프라 권한 관리 혼선 제거와 문서 정정
목차
인프라 문서를 정비하다가 발견한 흥미로운 케이스다. GSC 접근 권한이 여러 ADC로 산재되어 있었는데, 실제로는 단일 계정이 전 도메인을 관리할 수 있는 상황이었다. 개발 환경용 ADC가 불필요했다는 걸 깨닫고 문서를 정정했다.
문제의 발현
처음에는 작은 의문으로 시작했다. 새 팀원이 온보딩될 때마다 "GSC는 어느 계정으로 접근하나요?"라는 질문을 반복 받았는데, 우리 인프라 문서에는 여러 ADC가 혼재되어 있었다. 특히 개발 도메인과 프로덕션 도메인이 다른 권한 계층으로 관리되는 것 같은 인상을 줬고, 실제로 그렇게 문서화되어 있었다.
그런데 권한을 추적해보니 현실은 단순했다. support@hedvion이라는 단일 계정이 이미 전 도메인에 대한 ADC 권한을 갖고 있었고, 별도의 개발 환경 ADC는 사실 불필요한 레거시였다. 예전에는 환경별로 권한을 분리하려던 의도가 있었을 것 같은데, 어쨌든 현재 상태와 맞지 않았다.
왜 이런 혼선이 생기나
팀이 성장하면서 인프라 접근 정책이 여러 번 변경되곤 한다. 초기에는 모든 팀원이 모든 것에 접근하다가, 보안/감시 필요성으로 환경을 분리하고, 나중에는 다시 통합하는 식이다. 문서화가 리얼타임으로 따라가지 못하면 이런 "유령" 정책이 남아 있는다.
특히 ADC 같은 권한 관리는 누가 "언제 어디서" 정정했는지 명확하지 않으면 문제가 커진다. 개발팀은 "dev ADC로 해야 한다고 알고 있는데", 데브옵스는 "그거 안 쓰고 있는데?"라는 식의 대화가 반복되는 것이다. 결국 그 혼선이 온보딩 시간을 늘리고, 권한 리뷰 때 헷갈린다.
단일 ADC 통합의 의미
이번 정정이 중요한 이유는 몇 가지다.
첫째, 권한 추적의 단순성. 여러 ADC가 있으면 누가 뭘 했는지 감시하기 어렵다. 감시 로그를 분석할 때 "이건 dev ADC가 한 건가, prod ADC가 한 건가?"라는 의문이 생기고, 보안 감사 시에도 설명해야 할 복잡도가 늘어난다. 단일 ADC라면 "support@hedvion 계정의 행동"이라는 명확한 초점이 생긴다.
둘째, 운영 오류 감소. 온보딩 문서가 명확하지 않으면 팀원이 "어떤 ADC로 접근해야 하나"를 물어볼 때마다 대답이 달라질 수 있다. 또는 스스로 "둘 다 시도해봐야겠다"는 시행착오를 거친다. 단일 진실의 소스가 있으면 이런 낭비가 줄어든다.
셋째, 향후 정책 변경 시 기반이 명확. 나중에 "특정 팀원만 접근 가능하게 하자" 같은 정책이 필요할 때, 기준이 단일하면 새로운 정책도 깔끔하게 구성할 수 있다. 여러 ADC가 난잡하게 있으면 "근데 기존 dev ADC는?"이라는 레거시 질문이 계속 나온다.
회고
이 작업이 코드가 아니라 문서 정정이라서 "큰" 변화로 안 보일 수 있지만, 인프라 투명성 관점에서는 꽤 중요하다. 팀이 일정 규모 이상으로 커지면 "실제 정책"과 "문서된 정책"의 불일치가 얼마나 조용하지만 지속적으로 마찰을 일으키는지 깨달았다.
특히 권한/인증처럼 누구나 다를 수 있는(각자 다른 경로로 접근할 수 있는) 영역일수록 단일 진실 문서의 가치가 크다. 그리고 dev 환경 같이 "이전에는 필요했던 것"은 정기적으로 검토하고 불필요해진 부분은 빨리 정리하는 게 낫다. 오래된 정책이 남아 있으면 나중에 더 큰 혼선을 초래한다.
앞으로도 이런 식의 문서 정정은 최우선순위는 아니지만, 월 1-2회 정도는 의도적으로 "혹시 맞지 않는 부분 없나?"를 검토하려고 한다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.