규제준수는 개발자와 회사 모두에게 스트레스다. 수십, 수백명의 개발자를 동원하기도 하는 금융회사는 각 개발자의 소스코드를 일일이 검사하고, 규제 위반 사항을 찾아 교정하기 어렵다. 개발자 입장에서도 개발 단계마다 하나하나 규제를 따져가며 설계하고 코드를 만들어야 한다면 생산성이 떨어진다.
하물며 금융산업은 개인정보와 금융거래정보를 다루는 만큼 더 큰 책임을 요구받는다. 금융회사 소속 IT 개발자와 엔지니어라고 규제에서 벗어나지 않는다. 디지털 금융이 일상화된 세상에서 소프트웨어 직종의 책임은 갈수록 커지고 있다.
카카오뱅크 서신혁 데브옵스(DevOps)엔지니어링팀 팀장은 지난 29일 <바이라인네트워크>가 양재 엘타워에서 개최한 ‘2024 금융 테크 컨퍼런스’에서 금융 규제를 준수하면서 동시에 개발자 친화적인 환경을 위해 데브옵스 파이프라인을 구축한 사례를 발표했다.
서신혁 팀장은 “개발자가 행복해야 생산성이 향상된다고 생각한다”며 “금융권 클라우드 규제가 확립되지 않을 때 단순히 규제를 따르는 것 이상으로 고민하고 노력해야 했기 때문에 은행에서 이런 파이프라인을 구축하는 과정이 쉽지는 않았다”고 말했다.
오늘날 소프트웨어 개발과 IT 시스템 운영은 기획-개발-테스트-운영-폐기의 단방향적 주기를 갖지 않는다. 기획부터 폐기의 단계가 이어져 계속 반복되는 무한 루프다. 데브옵스 파이프라인은 사용자인 개발자에게 편리한 개발운영 과정을 제공하는 사용자경험(UX) 플랫폼이면서, 자연스럽게 규제를 준수하게 하는 관리적 틀이기도 하다. 만약 회사의 IT엔지니어링 조직이 규제 요건에 맞게 파이프라인을 잘 설계하면 개발 생산성을 높이면서도 안전한 IT 환경을 구축할 수 있게 된다.
서신혁 팀장은 금융 규제 환경에서 개발자들의 업무 효율성을 높이기 위해 수년에 걸쳐 어떤 도전과 혁신을 이뤄왔는지 소개하고, 이를 ▲결재와 증적 ▲접근제어 ▲망분리까지 3가지 금융 규제 측면에서 기술적 해결책을 소개했다.
결재와 증적에 대해 서 팀장은 “금융 규제에서 결제와 증적은 아주 중요한 부분으로, 금융 업무의 투명성을 보장하기 위해 증적이 필요하고, 개인에게 너무 많은 권한을 주지 않도록 통제해야 되기 때문에 결제가 필요하다”며 “결제와 증적을 요구하는 시스템으로 형상관리시스템이 있다”고 말했다.
카카오뱅크는 형상관리시스템으로 깃랩(GitLab)을 사용 중이다. 과거 깃랩 관리를 IT서비스관리(ITSM)란 결재 증적 시스템의 요청을 받고 처리했다고 한다. 그러나 깃랩과 ITSM 간 연동을 위해 중간에 사람을 개입시켜 연계해야 하는 문제가 있었다.
서 팀장은 “데브옵스 엔지니어가 ITSM에서 요청을 받아 깃랩에 들어가 요청사항을 적용했다”며 “이 요청이 처리될 때까지 개발 업무 흐름이 끊기게 되므로, 개발자가 집중력을 유지한 상태로 개발 업무를 쭉 이어가려면 결제와 개발 파이프라인의 연계가 필요했다”고 설명했다.
카카오뱅크는 깃랩을 형상관리시스템에서 데브옵스 플랫폼으로 확장하려는 계획을 갖고 있었다. 깃랩 서비스의 지속통합·지속배포(CI/CD), 아티팩트 레지스트리 기능들을 활용해 깃랩에서 배포 파이프라인을 수행하려 했던 것이다.
서 팀장은 “이런 경우 깃랩은 배포 시스템이 되며, 깃랩의 권한과 설정을 배포 시스템 수준으로 통제해야 했다”며 “배포 시스템은 전자금융감독규정 29조에 명시될 만큼 중요한 통제 대상 중에 하나”라고 설명했다.
그는 “그래서 깃랩의 통제를 깃옵스(GitOps) 형태로 구현해보려 했다”고 말했다.
카카오뱅크는 문제 해결을 위해 코드형 인프라(IaC) 도구인 ‘테라폼(TerraForm)’을 실험했다. 테라폼은 인프라 형상을 선언적 코드로 만들고 IT 자원을 프로비저닝하게 하는 도구다. 카카오뱅크는 테라폼을 깃(Git)에 저장하고 변경 사항에 대해 코드 리뷰를 받아 CI/CD 파이프라인에서 프로비저닝하게 했다. 이렇게 하면 깃랩 내의 변경 사항이 계속 기록되는 과정을 거치게 된다. 추가적으로 깃랩의 코드 리뷰 기능인 ‘머지 리퀘스트 어프로벌(Merge Request Approvals)’을 사용해 결재 프로세스에 대응했다.
추가적으로 일부 깃랩 리퀘스트 중 결재선을 달리해야 하는 요구 사항에 대응하기 위해 깃랩의 ‘코드 오너스(Codeowners)’ 기능을 활용했다. 파일마다 소유자를 지정하고 머지 리퀘스트에서 소유자 설정된 파일이 변경되면 해당 파일 소유자의 승인을 거쳐야 최종 처리되도록 했다.
서 팀장은 “개발 워크플로우에서도 결제와 증적을 이미 중요하게 다뤄왔다고 생각한다”며 “소프트웨어 변경에 대해 코드 리뷰를 받는 점이 결재와 비슷하고, 버전 관리라는 부분은 소프트웨어 개발 히스토리를 투명하게 관리하기 때문에 증적과 동일한 목적을 지향한다”고 말했다.
그는 “디테일은 조금 다르긴 하지만 규제가 추구하는 목표가 어느 정도 개발 워크플로우의 지향점과 맞닿아 있다”고 강조했다.
다음으로 접근제어 방안을 소개했다. 접근제어는 금융회사뿐 아니라 모든 기업에서 중요한 보안 통제 활동이다. 카카오뱅크는 컨테이너 이미지를 빌드할 때 대중적 방식인 ‘도커 데몬’을 사용했었다. 컨테이너를 운영하는 쿠버네티스 환경으로 아마존웹서비스(AWS) EKS를 사용하고 있었기 때문에 도커 데몬이 있는 사내 호스트 서버와 외부의 컨테이너가 특수부여권한을 활용해야 했다.
서 팀장은 “이 부분이 잠재적 보안 위협이 될 수 있는데, 컨테이너와 호스트 서버가 완전히 격리되지 않고 특수 권한으로 호스트 서버에 접근할 수 있는 경로가 만들어지기 때문”이라며 “이런 보안 위협에 대응하려고 관련 보안 규정들을 좀 찾아봤는데 당시에 클라우드의 노드를 위한 보안 규정이 따로 있지는 않았고, 궁극적으로 보안 위협의 해결책을 찾아야 했다”고 말했다.
카카오뱅크는 도커 데몬을 쓰지 않는 ‘데몬리스(daemonless)’ 빌드 도구를 탐색하며 해결책을 찾아갔다. 카니코(Kaniko), Jib, 빌드킷(Buildkit) 등이 검토돼 최종적으로 빌드킷으로 전환해 보안 위협을 최소화했다.
서 팀장은 “카니코가 개발 커뮤니티에서 가장 많이 언급됐고 구글 컨테이너 툴즈의 프로젝트면서 깃랩에서도 사양을 공식 가이드하고 있어 최우선으로 고려했다”며 “자바 코틀린 프로젝트의 경우 도커 파일을 작성하지 않고도 플러그인만 설정하면 컨테이너 이미지를 빌드해주는 jib를 추가로 선택했다”고 말했다.
그는 “반신반의했지만 적용했을 때 도커 데몬리스 빌드가 잘 이뤄졌다”며 “추가적으로 데몬리스 빌드를 도입하면서 쿠버네티스 1.24에서 도커 데몬을 쓸 수 없게 된 문제도 해결하게 됐다”고 덧붙였다.
문제가 여기서 완전히 해소되진 않았다. 카니코를 2년 정도 사용하면서 빌드 실패나 중단 문제가 조금씩 발생한 것이다. 그래서 더 안정적인 도구로 빌드킷의 데몬리스 스크립트를 활용하는 것으로 전환했다.
그는 “빌드킷의 데몬리스 스크립트는 내부에서 데몬을 실행하고 겉으로 데몬이 없는 것처럼 추상화한다”며 “컨테이너 안에서 이미지를 빌드할 수 있고, 도커의 빌드를 담당하는 공식 모듈이어서 검증되고 안정성도 확보된 도구를 쓸 수 있게 됐다”고 말했다.
카카오뱅크의 데브옵스엔지니어링팀은 또한, AWS 리소스 접근을 위한 권한 제어를 위해 깃랩 러너(GitLab Runner)를 여러 개 운영해 각 러너에 AWS IRSA(IAM Roles for Service accounts)를 부여하는 방식으로 시작했다. 최종적으로 깃랩 CI/CD와 AWS OIDC(OpenID Connect) 연동을 통해 접근제어를 개선했다.
그는 “AWS 상 서비스를 구축하다 보면 다양한 AWS 리소스를 사용하게 되는데 여기에도 접근제어가 필요하다”며 “CI/CD 파이프라인에서 AWS의 다양한 리소스에 접근해야 하는데 테라폼 파이프라인을 사용하면 AWS 인프라 프로비저닝에 대부분의 인프라 리소스에 어드민 수준의 권한으로 접근하게 된다”고 설명했다.
그는 “IAM 사용자의 액세스 키를 사용하는 방식이 가장 쉽지만 주기적으로 키를 갱신해야 한다는 보안 약점을 갖고 있어서 제외시켰다”며 “그 다음이 깃랩 CI/CD에 개방형 표준의 분산 인증 프로토콜을 사용하는 AWS OIDC를 연동하는 방식이었다”고 말했다.
애초에 시도된 방식은 매 CI/CD 시행 시마다 토큰을 노출하기 때문에 보안상 좋지 않고, 향후 배제될 예정이었다. 그래서 깃랩 러너를 여러개 만들어 CI/CD 파이프라인 각각에 AWS IRSA로 권한을 부여하는 방안을 적용했다고 한다. 하지만 이는 깃랩 러너를 계속 증가시키는 유지보수 측면의 불합리를 만들어냈고, 개선 필요성을 다시 만들어냈다. 그러다 작년 깃랩 CI/CD와 AWS OIDC를 연동하는 방식이 ID 토큰제 방식으로 개선됐고, AWS IAM으로부터 깃랩으로 유입되는 외부 인터넷 접근 문제도 깃랩의 퍼블릭 엔드포인트에 웹 애플리케이션 방화벽(WAF)을 둬서 AWS IAM의 IP 대역과 함께 통제하도록 해결했다고 한다..
서 팀장은 “카카오뱅크는 CI/CD 파이프라인을 통해 쿠버네티스 애플리케이션, 람다 애플리케이션, 아마존 S3, 스태틱 리소스 배포, 테라폼 파이프라인 등 다양한 배포 환경이 구축돼 있다”며 “접근 제어를 준수하기 위한 노력이 있었기 때문에 퍼블릭 클라우드에서 CI/CD 파이프라인을 안전하게 사용할 수 있게 된 것 같다”고 말했다.
세번째 사례로 망분리 규제 문제가 설명됐다. 망분리는 외부망과 내부망을 분리하는 것으로 카카오뱅크는 외부망에서 만든 소스코드를 내부망에서 운영해야 했다.
서 팀장은 “카카오뱅크의 개발자는 외부망인 경영망에서 개발하고, 내부망인 금융망에서 운영하는 것으로 개발과 운영을 한다”며 “이런 구조가 작동하려면 경영망에서 개발한 소스코드가 금융망으로 넘어가는 망연계 파이프라인이 중요하다”고 말했다.
그는 “망연계는 규정상 제3자 검수가 필수이고 증적을 확보해야 하는 등 엄격하게 통제된다”며 “과거 카카오뱅크는 자체적으로 구현한 깃랩 동기화 시스템으로 구현하고 있었다”고 말했다.
당시의 깃랩 동기화 시스템은 제3자 검증 목적 때문에 깃랩의 머지 리퀘스트를 생성한 사람과 머지를 수행한 사람이 다르면 동기화 이벤트가 발생하는 형태였다. 동기화 이벤트 발생 시 전체 리포지터리가 복제되기 때문에 대용량인 경우 망간 네트워크 통제 시스템에서 지연을 발생시켰다.
그는 “개선 작업은 클라우드 네이티브 환경 구축이 카카오뱅크의 주요 기술 목표로 잡힌 4년 전의 시점에 시작됐다”며 “깃랩 엔터프라이즈의 기능으로 망간 동기화의 성능 개선이나 통제를 효과적으로 수행할 수 있는지 개념검증(Poc)을 거쳤고, 해당 이슈들을 해결할 수 있다는 것을 확인했다”고 말했다.
그는 “AWS에 깃랩 엔터프라이즈를 신규로 구축하는 것도 함께 검토해 문제없음을 확인했다”며 “클라우드에 깃랩을 구축하면 자체 데이터센터에 장애 발생 시 클라우드 상의 파이프라인을 이용해 빠르게 시스템을 복원할 수 있다는 장점이 있다”고 덧붙였다.
카카오뱅크는 AWS 2개의 망에 각각 깃랩 엔터프라이즈를 설치하고, 경영망과 금융망(FIN)을 연계하는 형태를 구축했다. 또한 금융망과 경영망 간 망연계 시 컨테이너 레지스트리 인증 리다이렉션 문제를 해결함으로써 망분리된 환경에서 서비스 운영의 안정성을 높였다.
서 팀장은 “지난 3년 동안 데브옵스 파이프라인을 구축하면서 규제의 추구 가치가 무엇인지를 이해하는 것이 중요하다는 것을 생각하게 됐다”며 “규제의 추구 가치가 무엇인지를 이해하면 그 가치에 부합하는 기술이 어딘가에는 있었다”고 말했다.
그는 “지금 여러분의 머리속을 복잡하게 만드는 규제가 있다면 그 규제가 추구하고자 하는 가치가 무엇인지를 다시 한번 생각해보는 시간을 가져보셨으면 좋겠다”고 강조했다.
글. 바이라인네트워크
<김우용 기자>yong2@byline.network
