금융권 DevOps 도구셋 구축 및 현장 상주 전환

SVN + ChangeFlow 환경을 GitLab 기반으로 전환하여 개발자 105~125명 대상 DevOps 도구셋을 설계했습니다. 5개 시스템의 전환을 병렬 수행하며, ITSM 통제 환경(squash/rebase/force push 금지)에 맞는 Git 전략을 수립하고 상황별 운영 가이드와 장애 대응 가이드를 작성했습니다. 보안 감사 요건을 충족하며 Rootless Docker 제약 하에서 컨테이너 기반 플랫폼을 구축했습니다.

Architecture

동기

은행은 SVN 과 ChangeFlow 로 형상을 관리하고 있었습니다. 바꾸려는 이유는 둘이었습니다. 하나는 병렬 개발입니다. 여러 건이 동시에 도는데 파일을 잠그고 순서를 맞추는 방식은 그것을 받아 주지 못합니다. 다른 하나는 감사입니다. 누가 언제 무엇을 바꿨고 그 변경이 어떤 승인을 거쳐 운영에 올라갔는지를 따로 관리하는 대장 없이 저장소 이력만으로 증명하고 싶다는 것이었습니다.

이 둘은 보통 같이 가지 않습니다. 브랜치를 자유롭게 파는 팀일수록 이력을 다듬는 기능을 함께 씁니다. 커밋 여러 개를 하나로 합치고(squash), 분기점을 옮겨 다시 얹고(rebase), 그 결과로 리모트를 덮어씁니다(force push). 셋 다 이미 남은 이력을 다시 쓰는 동작이라 이력이 곧 증거인 곳에서는 못 씁니다. 그래서 과제가 브랜치는 마음껏 파되 한 번 남은 것은 아무도 지울 수 없게 만드는 쪽으로 좁혀졌습니다.

내가 담당한 트랙

SVN + ChangeFlow 에서 GitLab 으로 5개 시스템을 옮기고, ITSM 통제에 맞춘 브랜치 전략과 운영 가이드를 설계했으며, GitLab·전용 Runner·관측성 스택·Keycloak·Vault·N8N 을 세웠습니다. 항목별 내역은 오른쪽 「주요 업무」에 있습니다.

트랙경계
ITSM은행이 이미 쓰던 자산입니다. 제가 한 것은 브랜치와 승인 흐름을 그것에 연동한 일입니다
CodePrism · Clarity · Fortify역시 은행 자산이고, 파이프라인의 검사 단계로 편입했습니다

브랜치와 ITSM 문서의 대응

브랜치 이름을 ITSM 문서 체계와 1:1 로 맞췄습니다. 변경요청 하나에 브랜치 하나가 열리고 그 아래에 개발 작업 브랜치와 결함 수정 브랜치가 달립니다. 저장소만 봐도 그 코드가 어느 변경요청에서 나왔는지 이름으로 드러나고, ITSM 문서에서 저장소로 찾아 들어오는 길도 같이 생깁니다.

저장소 설정으로 막은 것들

개발자가 직접 push 할 수 있는 곳은 자기 작업 브랜치뿐입니다. 나머지는 전부 보호 브랜치로 두고 push 권한을 아무에게도 주지 않았습니다. 관리 권한을 가진 사람도 예외가 없어서, 코드가 그 브랜치에 들어가는 길은 병합 요청 하나만 남습니다. 커밋을 합치는 선택지는 프로젝트 설정에서 지웠고, 리모트를 덮어쓰는 동작은 따로 켜야 열리는 것이라 끈 채로 뒀습니다. 변경요청에서 배포 묶음으로 넘어가는 구간에는 ITSM 승인이 걸려서 승인 전에는 병합 자체가 되지 않습니다.

에어갭

망이 완전히 끊겨 있어서 밖에서 가져오는 모든 것이 절차입니다. 패키지 하나의 의존성이 맞지 않아도 그 자리에서 받아 해결할 수 없고, 무엇이 필요한지 미리 다 헤아려 들어가야 합니다. 컨테이너도 보안 감사가 요구한 조건(rootless) 안에서 돌려야 해서 바깥에서 쓰던 방식이 그대로 통하지 않는 자리가 계속 나왔습니다.

없앨 수 있는 제약이 아니라 일정에 넣어야 하는 제약입니다. 한 번 들어갈 때 확인할 것을 모아 가는 쪽이 언제나 쌉니다.

SVN 만 쓰던 개발자들

도구를 세우는 일보다 사람 쪽에 시간이 더 들었습니다. 100명이 넘는 개발자가 그때까지 SVN 만 써 왔고, 새로 받은 브랜치 전략은 검색으로 나오는 답이 잘 안 통하는 형태였습니다. 인터넷의 해법은 대개 분기점을 옮겨 다시 얹은 뒤 리모트를 덮으라고 하는데 여기서는 둘 다 막혀 있고, 되돌리는 방법도 이력을 지우지 않고 되돌렸다는 사실을 새 커밋으로 남기는 쪽뿐입니다.

그래서 문의가 많이 들어왔고 그 응대가 이 일의 큰 부분이었습니다. 같은 상황이 반복되는 만큼 답을 상황 단위로 적어 뒀고, 그것이 상황 단위로 짜인 운영 가이드가 됐습니다. 목차가 기능이 아니라 상황으로 짜인 이유가 여기 있습니다. 개발자는 “rebase 사용법” 을 찾지 않고 “머지하려는데 충돌이 났고 직접 커밋은 막혀 있다” 를 찾습니다.

배운 점

  • 브랜치 전략은 그림으로는 어떤 형태든 성립합니다. 실제로 지켜지는 건 저장소가 거부하는 동작뿐이라, 설계에서 제일 오래 붙든 것이 화살표가 아니라 어느 동작을 어디서 막을지였습니다.
  • 커밋을 합쳐 로그를 깔끔하게 만드는 일이 다른 곳에서는 정리인데 여기서는 증거가 사라지는 일입니다. 도구의 기본값이 이 환경에서 무엇을 뜻하는지부터 다시 따져야 했습니다.
  • 이관이 끝난 시점보다 개발자들이 막히는 자리를 스스로 넘기 시작한 시점이 한참 뒤였습니다. 그 사이를 메운 것이 문의 응대와 가이드입니다.