금융 클라우드 DevOps 플랫폼 구축 및 레거시 전환

SVN + Change Flow 파일 단위 배포 환경을 에어갭 GitLab CI/CD로 전환했습니다. 기존 프라이빗 클라우드 인프라 위에 DevOps 도구셋을 구축하고 온프레미스 GitLab Runner를 연동하여 사용자 1,994명·프로젝트 579개 규모로 운영했습니다. Helm Chart 해시, 컨테이너 Digest 검증 기반 이미지 무결성 체계를 구축했습니다.

Architecture

동기

SVN 과 Change Flow 로 파일 단위 배포를 하고 있었습니다. 바꾸려는 이유는 금융권에서 흔한 두 가지입니다. 여러 건을 동시에 굴리고 싶다는 것, 변경 이력이 감사에 그대로 쓰이게 하고 싶다는 것.

조건이 두 개 더 있었습니다. 외부망이 완전히 끊긴 폐쇄망이고, 도구를 올릴 자리가 고객사가 이미 운영하던 프라이빗 클라우드 위 Kubernetes 였습니다. 바닥을 새로 깔지 않고 남의 바닥 위에 얹는 일입니다.

내가 담당한 트랙

클러스터 위에서 할 수 있는 일이 우리 몫입니다. GitLab·Mattermost 구축, ITSM 연동 브랜치 전략, 이미지 무결성 검증과 Harbor, 관측성 스택, 그리고 2025년 하반기부터 2026년 7월까지 이어진 업그레이드·개선·장애 대응이 여기 들어갑니다. 항목별 내역은 오른쪽 「주요 업무」에 있습니다.

트랙경계
Kubernetes 클러스터와 프라이빗 클라우드 인프라고객사 것입니다. 우리는 그 위에 올라가는 것만 다뤘습니다
ITSM고객사 자산이고, 배포 흐름에 연동했습니다

이미지 무결성 검증

규제와 감사 요건이라 Helm Chart 의 해시와 컨테이너 이미지의 digest 를 대조하는 검증을 넣었습니다.

이미지 태그는 옮겨 붙습니다. v1.2.3 이라는 이름을 다른 내용물에 다시 붙일 수 있으니, 태그만 보고는 지금 도는 것이 승인받은 그것인지 확인할 수 없습니다. digest 는 내용이 한 바이트만 달라져도 값이 달라집니다. 차트 해시도 같은 용도입니다.

배포 피크의 job stuck

배포가 몰리는 시간에 파이프라인 하나가 배포 작업 14개를 펼쳤습니다. 13개는 20~60초대에 끝났고 하나가 85분 동안 멈춰 있었습니다. 운영팀이 화면에서 강제 취소를 눌러 점유를 풀었고, 재시도로 회복될 때까지 두 시간이 걸렸습니다.

멈춘 작업 자체는 그 서버에 붙은 실행기가 SSH 로 붙어 일하다 매달린 것이었습니다. 다른 서버들은 멀쩡했습니다.

후속 작업까지 밀린 이유는 따로 있었습니다. GitLab 의 PostgreSQL 이 커넥션 한도 100 으로 돌고 있었습니다. 설정 파일에 그 값을 적은 줄이 없어서 차트 기본값이 그대로 쓰였고, 한가한 시간에도 60개 남짓을 쓰고 있었습니다. 피크에 슬롯이 마르자 커넥션을 못 얻은 백그라운드 워커들이 죽었는데, 그중에 다음 작업을 큐에서 꺼내는 워커와 파이프라인 잠금을 푸는 워커가 있었습니다. 한 대가 매달린 일이 그 한 대에서 끝나지 않은 이유입니다.

조치는 두 가지였습니다. 그 서버의 실행기를 SSH 방식에서 셸 방식으로 바꾸고(태그 한 줄), 커넥션 한도를 200 으로 명시했습니다. 이후 사용량은 200 중 77 입니다.

못 밝힌 것도 남았습니다. 그 시각의 커넥션 수치는 아무도 수집하고 있지 않았고, 멈춘 작업의 로그는 파드가 재시작되며 사라졌으며, 누가 언제 강제 취소를 눌렀는지는 그 버전에 기록하는 자리 자체가 없었습니다. 애플리케이션 로그는 여섯 시간마다 회전해 이미 지워진 뒤였습니다. 관측성 스택은 이 사고 뒤에 깔았습니다.

업그레이드 중 볼륨 detach 지연

GitLab 을 올리던 중 파드가 새 노드로 옮겨 뜨면서 볼륨이 따라오지 못했습니다. 이전 노드가 아직 그 디스크를 쥐고 있어서 Redis 는 10분쯤, PostgreSQL 은 15분쯤 붙지 못했고, 그동안 마이그레이션 작업이 실패해 다시 도는 바람에 다운타임이 20분 늘었습니다.

이미지 태그만 바뀌는 업그레이드에서는 안 나는 일입니다. 차트 버전이 올라가며 설정값이 함께 바뀌면 파드 정의가 바뀐 것으로 인식돼 파드가 새로 뜨고, 스케줄러가 다른 노드를 고르면 위 상황이 됩니다. 한 노드에만 붙을 수 있는 디스크를 쓰는 구성에서는 구조적으로 가능한 일입니다.

다음 회차부터 순서를 바꿨습니다. 파드를 먼저 0으로 내려 디스크가 떨어진 것을 확인한 뒤 올리고, 다시 뜰 때 원래 노드로 돌아오게 했습니다. 볼륨 왕복이 7분으로 줄었습니다.

배운 점

  • 구축을 끝내고 그대로 운영까지 맡은 자리라, 구축 때 정한 것이 1년 뒤에 어떻게 돌아오는지를 직접 봤습니다. 커넥션 한도를 적지 않은 것도 그때의 선택이었습니다.
  • 볼륨이 제때 떨어지지 않는 건 우리가 손댈 수 있는 층이 아니었습니다. 스토리지는 그대로 두고 올리는 순서만 바꿔 20분을 7분으로 줄였습니다. 폐쇄망에서 남의 인프라 위에 얹혀 일하면 이런 식의 조치가 많아집니다.