DevOps 플랫폼 운영 및 접근 관리

동기

다른 카드들이 시작과 끝이 있는 구축이라면 이 카드는 상시 책임입니다. 2026년 1월에 사내 도구셋 관리를 맡으면서 시작됐고, 그 뒤로 사람이 로그인하고 서버에 붙고 권한을 받는 경로 전체가 제 쪽이 됐습니다.

처음에 제일 어려웠던 것은 인증과 권한 체계였습니다. 도구마다 사용자와 권한을 따로 들고 있고 그 모델이 서로 달라서, 어느 도구에서 누가 무엇을 할 수 있는지를 한 자리에서 답할 수 없는 상태였습니다. 그 질문에 답할 수 있게 만드는 것이 이 일의 큰 축이었습니다.

내가 담당한 트랙

로그인 통합부터 계정 수명 주기, 인프라 접근, 클러스터 운영, 권한·자격증명 정책까지 제가 합니다. 항목별 내역은 오른쪽 「주요 업무」에 있습니다.

신원을 한 곳으로 모으기

도구를 하나씩 들여올 때마다 그 도구의 사용자 목록과 권한 모델이 따로 생깁니다. 사람이 늘고 도구가 늘면 이 조합이 곱으로 늘고, 퇴사자 계정을 지우는 일이 도구 수만큼의 작업이 됩니다.

그래서 신원을 하나로 모으고 도구들이 그것을 바라보게 했습니다. 로그인은 한 곳에서 하고, 그룹과 역할도 거기서 정하며, 다중 인증과 세션 정책도 도구별 설정이 아니라 그쪽 정책으로 강제합니다. 도구마다 권한 모델이 다른 것은 매핑으로 흡수합니다.

접근 통제도 같은 방향으로 모았습니다. 서버에 붙는 것, 클러스터 API 를 쓰는 것, 데이터베이스에 붙는 것을 각각 다른 열쇠로 하지 않고 한 통제 아래 두었습니다. 세션 기록과 감사 로그는 기본으로 켜 두고, 오래 살아 있는 자격증명 대신 필요할 때 짧게 받는 흐름으로 옮겼습니다.

이 구성을 코드로 관리하는 것이 그다음 과제였습니다. 로그인 쪽 설정과 접근 통제 정책, 비밀 저장소, 클러스터 권한이 각각 다른 곳에 손으로 들어가 있으면 “지금 누가 무엇에 접근할 수 있는가” 를 읽을 방법이 없습니다. 이 넷을 코드로 모으고 접근 정보의 정본을 한 곳으로 정했습니다.

서명키 하나가 로그인을 막은 일

인증을 한곳으로 모으면 그 한곳이 흔들릴 때 파급이 넓어집니다. 실제로 그런 일이 있었습니다.

클러스터의 서명키가 회전했습니다. 관리형 서비스가 주기적으로 하는 정상 동작입니다. 문제는 클러스터 밖에서 그 서명을 확인하는 쪽이 공개키를 설정에 복사해 두고 있었다는 것이었습니다. 새 키로 서명된 토큰이 나오자 검증이 실패했고, 그 인증에 의존하던 보조 프로세스가 계속 재시작에 빠졌습니다.

여기까지는 기능 하나가 죽은 것입니다. 크게 만든 것은 그 보조 프로세스가 로그인을 처리하는 컨테이너와 같은 파드 안에 있었다는 점입니다. 파드의 준비 상태는 그 안 컨테이너들의 조합이라, 한쪽이 죽자 파드 전체가 준비 안 됨이 됐고, 그러자 서비스가 그 파드를 트래픽 목록에서 뺐습니다. 로그인 처리는 멀쩡히 살아 있었는데 갈 길이 끊긴 것입니다. 그 보조 프로세스가 열어 주던 통로는 로그인 경로가 쓰지도 않는 것이었습니다.

먼저 한 것은 원인 수정이 아니라 파드를 가르는 일이었습니다. 보조 프로세스를 밖으로 빼서, 그것이 어떤 이유로 죽든 로그인 경로의 준비 상태를 끌어내리지 못하게 했습니다. 원인 쪽은 그 위에서 고쳤습니다 — 처음에는 키가 바뀌면 감지해서 설정을 갱신하고 변경 요청을 만들어 알리는 자동화를 붙였고, 실제로 엿새 뒤 같은 회전을 사람보다 먼저 잡았습니다.

그런데 끝까지 가서 내린 답은 자동화를 더 잘하는 것이 아니었습니다. 공개키를 손에 들고 있지 않고 발급기관 주소만 신뢰하는 방식으로 바꾸면 갱신할 스냅샷 자체가 없어집니다. 상세한 기록은 사이드바 「관련 글」에 따로 적어 두었습니다.

반복을 절차로 굳히기

상시 운영에서 하는 일은 대체로 두 번째부터입니다. 같은 요청이 두 번 오면 그때부터는 처리하는 대신 처리할 필요가 없게 만드는 쪽을 봅니다. 한 번 푼 제약은 다시 풀 일이 없어야 합니다.

인프라 변경은 저장소를 고쳐 리뷰를 받고 배포되는 경로로만 들어갑니다. 클러스터에 직접 손대는 변경을 금지한 것은 그렇게 바꾼 것이 어디에도 안 적히기 때문입니다. 사고가 나면 원인을 찾는 것으로 끝내지 않고, 어떤 제약이나 정책이 이걸 미리 막았어야 했는지를 거꾸로 물어 다음 사이클에 넣습니다.

배운 점

• 장애 대응 중에 “이 상태를 어떻게 자동화할까” 라는 질문까지 왔다면 한 번 더 물어봐야 합니다. “이 상태를 아예 안 가져도 되는가.” 이번 건에서는 자동화가 실제로 작동해서 재발을 잡았는데도, 더 나은 답은 그 상태를 없애는 쪽이었습니다.
• 파드 안에 같이 넣은 보조 컨테이너는 핵심 경로의 준비 상태를 끌어내릴 수 있습니다. 로그인은 그 보조 프로세스의 통로를 쓰지도 않았는데 막혔습니다. 무엇을 한 파드에 묶을지는 편의로 정하기 쉬운데, 묶는 순간 장애 경계가 같이 묶입니다.