이 자리가 왜 생겼을까요
카카오뱅크는 2025년 2월 기술 블로그에서 초기에는 온프레미스 VM과 BM(Bare-Metal) 환경에 모놀리식 애플리케이션을 배포했고, 지금은 Terraform과 Kubernetes를 활용한 근본적인 해결책을 마련하고 있다고 밝혔습니다. 같은 글에서 Prometheus 지표를 임계값으로 삼아 트래픽 가중치를 조절하는 카나리 배포를 온프레미스 환경에서 준비하고 있다고 적었습니다. 2024년 6월 보안 점검 도구 VulShot 소개 글에서는 GitLab 파이프라인에 정적·동적 점검을 연동하고 배포 증적 생성까지 자동화한다고 설명했습니다. 팀 소개는 개발자가 '금융 환경의 compliance를 충족하면서도 가능한 빨리 소프트웨어를 안정적으로 출시할 수 있도록' 개발 환경과 CI/CD 파이프라인을 만든다고 적었습니다. 이 공고가 표준 CI/CD 파이프라인과 배포 Workflow 시스템 개발을 맡기고 모니터링 시스템과 연동한 배포 전략 경험을 우대하는 것도 이 전환과 이어집니다.
- 카카오뱅크 기술블로그 - 은행에 서비스 디스커버리 도입하기(2025-02-07)
- 카카오뱅크 기술블로그 - VulShot으로 시작하는 DevSecOps & 보안 점검 자동화(2024-06-10)
- DevOps 엔지니어 공고
카카오뱅크가 지금 어떤 사업에 집중하고 있는지는 카카오뱅크 채용 분석에서 이어서 볼 수 있습니다.
1하게 될 업무
카카오뱅크 표준 CI/CD 파이프라인과 CLI 도구를 GitLab CI와 Go로 개발하고 운영합니다.
이렇게 볼 수 있어요
「표준」 파이프라인은 여러 개발팀이 각자 만들지 않고 가져다 쓰는 공통 틀이라, 카카오뱅크가 기술 블로그에서 밝힌 GitLab 파이프라인의 정적·동적 보안 점검 연동과 배포 증적 생성 같은 금융권 요건도 이 틀 안에서 처리될 것으로 보입니다. 파이프라인과 함께 개발자가 쓰는 CLI 도구까지 Go로 만드는 자리라, Go로 사내 도구나 CLI를 만들어 배포해 봤다면 그 도구를 쓴 팀과 사람 수가 경험의 크기를 보여 줍니다.
GitLab, ArgoCD, Nexus, AWX 같은 CI/CD 도구를 AWS EKS, helm, gitops 환경에서 운영합니다.
이렇게 볼 수 있어요
목록의 도구는 역할이 다릅니다 - GitLab은 코드 저장소와 CI, ArgoCD는 Git 기준 배포(GitOps), Nexus는 빌드 산출물과 패키지 저장소, AWX는 Ansible 작업을 웹에서 돌리는 도구입니다. AWX는 주로 VM이나 물리 서버 설정을 자동화할 때 쓰여, 카카오뱅크가 기술 블로그에서 밝힌 온프레미스 VM·BM 환경도 이 팀의 운영 범위에 있을 가능성이 큽니다. 써 본 도구는 어떤 규모의 환경에서 운영했는지를, 안 써 본 도구는 Jenkins·Artifactory·Flux처럼 같은 역할의 도구 경험으로 설명하는 편이 낫습니다.
카카오뱅크 배포 Workflow 시스템을 개발합니다.
이렇게 볼 수 있어요
배포 절차 자체를 시스템으로 만드는 일입니다. 팀 소개에 금융 compliance를 지키면서 빠르게 출시하는 것을 목표로 적었으므로, 승인 단계나 기록을 배포 흐름에 넣어 본 경험이 가장 직접적인 근거가 됩니다.
2자격 요건
하나의 서비스를 1년 이상 개발하고 운영해 본 경험이 필요하며, B2C, B2B, 사내 서비스 모두 인정합니다.
이렇게 볼 수 있어요
이 조건은 인프라 경력만이 아니라 서비스를 개발하고 운영해 본 경험을 요구합니다. 사내 서비스도 인정하므로 개발자용 내부 도구를 운영한 기간도 여기에 넣을 수 있습니다.
CI/CD 파이프라인을 직접 만들고 운영해 본 경험이 필요합니다.
이렇게 볼 수 있어요
같은 회사 쿠버네티스 엔지니어 공고는 Kubernetes 운영을 위한 CI/CD를 설계하는 업무를 적었고, 이 공고는 CI/CD 파이프라인을 직접 만들고 운영해 본 경험을 필수로 요구합니다. 이미 있던 파이프라인을 고친 경험과 처음부터 설계한 경험은 나눠 적고, 다른 팀이 가져다 쓰도록 템플릿이나 공용 단계로 만든 적이 있다면 그 부분을 자세히 쓰는 편이 업무의 「표준 CI/CD 파이프라인」과 맞습니다.
Go, Ruby, Kotlin, Javascript, Java 같은 언어 가운데 하나 이상을 능숙하게 써야 합니다.
이렇게 볼 수 있어요
첫 업무의 CLI 도구와 표준 파이프라인이 Go로 개발되므로 Go 경험이 하게 될 일과 가장 가깝습니다. 같은 회사 쿠버네티스 엔지니어 공고도 오퍼레이터와 자동화 언어로 Go를 먼저 적어, 이 회사 플랫폼 쪽 도구가 Go로 모여 있는 것으로 보입니다. 다른 언어라면 그 언어로 만든 도구나 서비스를 예로 들 만합니다.
문제 해결을 즐기는 분이어야 합니다.
이렇게 볼 수 있어요
이 팀의 배포 경로는 GitLab CI에서 Nexus와 ArgoCD를 거쳐 EKS까지 이어질 수 있어, 배포가 실패하면 원인이 러너·저장소·클러스터 가운데 어느 층에 있는지부터 좁히는 일이 먼저입니다. 배포 장애처럼 원인이 여러 곳에 걸친 문제를 끝까지 추적해 해결한 사례라면 어느 층에서 원인을 찾았는지까지 말할 때 이 태도가 드러납니다.
기술과 비즈니스, 도메인을 균형 있게 고려할 수 있어야 합니다.
이렇게 볼 수 있어요
금융 도메인에서는 compliance가 이 균형의 한쪽에 놓입니다. 기술적으로 더 나은 방법이 있었지만 규정이나 사업 일정 때문에 다른 선택을 한 경험이 있다면 그 판단 과정이 이 조건에 대한 답이 됩니다.
경력이 5년 이상이어야 합니다.
이렇게 볼 수 있어요
쿠버네티스 엔지니어 공고는 「관련 경력」 5년을 적었고, 이 공고는 분야를 붙이지 않은 경력 5년에 서비스를 1년 이상 개발·운영한 경험을 따로 묻습니다. 백엔드 개발로 시작해 배포 자동화로 옮겨 온 경력도 이 5년에 함께 적을 수 있고, 그 안에서 CI/CD 파이프라인을 직접 만들고 운영한 서비스를 자세히 쓰면 필수 경험 두 줄이 한 경력 안에서 설명됩니다.
3우대 사항
GitLab CI, Github Action, CircleCI, Travis CI, CodeShip 같은 SaaS형 CI/CD 서비스를 써 본 경험을 우대합니다.
이렇게 볼 수 있어요
이 팀의 표준 CI/CD 파이프라인은 GitLab CI와 Go로 개발합니다. 다른 SaaS형 CI/CD를 써 왔다면 그 도구에서 만든 파이프라인 구조와 재사용 방식이 GitLab CI에서는 어떻게 구현되는지 설명할 수 있어야 합니다.
Go, Ruby, Kotlin, Javascript, Java 같은 언어 가운데 두 가지 이상을 능숙하게 쓰는 분을 우대합니다.
이렇게 볼 수 있어요
같은 회사 백엔드 개발자 공고가 Java·Kotlin을 서버 언어로 적어, Go로 만든 표준 파이프라인이 실제로 빌드하는 서비스는 다른 언어일 가능성이 큽니다. 두 번째 언어로 운영 중인 서비스나 도구를 만들어 봤다면 그 언어의 빌드·테스트 방식을 파이프라인에 어떻게 반영했는지까지 말할 수 있어 능숙함이 분명해집니다.
CI/CD 파이프라인과 애플리케이션 모니터링 시스템을 연동해 배포 전략을 구현해 본 경험을 우대합니다.
이렇게 볼 수 있어요
카카오뱅크는 기술 블로그에서 Prometheus 지표를 임계값으로 삼아 트래픽 가중치를 조절하는 카나리 배포를 온프레미스 환경에서 준비하고 있다고 밝혔습니다. 배포 중 지표를 보고 진행하거나 되돌리는 방식을 만들어 봤다면 어떤 지표와 임계값을 썼는지가 이 준비 작업에서 그대로 필요한 내용입니다.
4기타 사항
- 게시일 : 2026년 1월 1일
- 고용형태 : 정규직
- 근무지 : 카카오뱅크 판교오피스 (경기도 성남시 분당구 분당내곡로 131)
- 경력 조건 : 경력 5년 이상
- 학력 조건 : 해당 내용은 원본 공고에서 확인되지 않습니다.
쓰는 기술
공고 본문에 적힌 기술만 모은 목록입니다.
- GitLab CI
- Go
- GitLab
- ArgoCD
- Nexus
- AWX
- AWS EKS
- helm
- gitops
- Ruby
- Kotlin
- Javascript
- Java
- Github Action
- CircleCI
- Travis CI
- CodeShip
전형과 지원
카카오뱅크는 공고마다 영입 프로세스를 따로 적습니다. 과제전형이 있는 공고와 없는 공고, 실무진 면접이 두 번인 공고, 실무진과 경영진 면접 사이에 그룹장 면접이 있는 공고가 섞여 있어서 지원하려는 공고의 프로세스와 서류전형 결과 발표일을 먼저 확인해야 합니다.
공고마다 다른 단계
기본 흐름은 서류전형, 실무진 면접전형, 경영진 면접전형, 연봉 및 처우 협의, 최종합격이고, 공고에 따라 그 사이에 그룹장 면접이 들어갑니다. 공고에 따라 서류 뒤에 과제전형이나 코딩테스트전형이 붙고, IR 담당자 공고처럼 1차 실무진 면접 대상자에게 사전과제가 나오기도 합니다. 1차 실무진 면접 대상자는 면접 전에 컬처핏 프로파일 검사를 받습니다. 경영진 면접 뒤에는 레퍼런스 체크가 진행될 수 있습니다.
이렇게 볼 수 있어요
컬처핏 프로파일은 서베이 형태이고 결과로 합격 여부를 정하지 않는다고 적었습니다. 대신 면접에서 컬처핏 질문을 하는 데 쓰이므로, 일하는 방식 일곱 가지에 맞춘 사례를 1차 면접 전에 정리해 두는 편이 좋습니다.
중복 지원과 공동체 지원
채용 FAQ는 중복 지원이 어렵다고 밝히고, 먼저 지원한 직무에서 불합격 안내를 받으면 다른 직무로 다시 지원할 수 있다고 적었습니다. 카카오 공동체 회사 사이의 중복 지원은 가능합니다.
이렇게 볼 수 있어요
카카오뱅크 안에서는 공고 하나를 골라 지원해야 합니다. 같은 분류에 비슷한 공고가 여럿이면 업무 목록과 필수 경험에 적힌 일을 내가 가장 많이 해 본 공고를 고르면 됩니다.
재지원은 언제든 가능합니다
재지원은 언제든 가능하지만 같은 직무라면 이전 전형의 아쉬운 점을 보완할 수 있도록 최소 6개월 정도 간격을 두기를 권장한다고 적었습니다. 전형에 대한 개별 피드백은 기본적으로 제공하지 않습니다.
이렇게 볼 수 있어요
6개월은 기간 제한이 아니라 권장 사항입니다. 피드백을 받을 수 없으므로 같은 직무에 다시 지원한다면 그사이 새로 쌓은 경험이 분명히 보이도록 이력서를 고쳐야 합니다.
결과 안내 기간과 연봉 결정
과제 결과는 제출일로부터 2주 이내, 실무진 면접 결과는 2주 이내, 경영진 면접 결과는 1주 이내에 안내한다고 적었습니다. 공고에 연봉이 없으면 마지막 면접 합격 뒤 소득 자료를 받아 보상 담당자가 연봉을 제안하고, 협의를 거쳐 최종 합격이 정해집니다.
이렇게 볼 수 있어요
단계별 대기 기간이 공개되어 있어 다른 회사 일정과 맞춰 볼 수 있습니다. 소득 자료를 내야 하므로 원천징수영수증 같은 서류를 미리 확인해 두면 마지막 단계가 늦어지지 않습니다.
경력직 기준과 신용정보 조회
정규직, 계약직, 파견직 근무 기간이 만 1년 이상이면 경력직으로 영입하고, 1년 미만이면 정규직 전환형 인턴 전형 참여 의사를 확인한 뒤 진행한다고 적었습니다. 마지막 면접 뒤에는 카카오뱅크 대출 상품을 이용할 수 있는 신용 점수를 기준으로 신용정보 조회를 한다고 밝혔습니다.
이렇게 볼 수 있어요
경력 1년 미만이라면 경력직 공고에 지원해도 인턴 전형으로 바뀔 수 있습니다. 신용정보 조회는 은행이라 생기는 절차이므로 최종 단계 전에 내 신용 상태를 한 번 확인해 두는 편이 안전합니다.
공고마다 접수 마감일이 있습니다
공고에는 모집기간을 영입 완료 시 마감이라고 적으면서도 접수 마감일과 서류전형 결과 발표일을 함께 표시합니다. 분석 시점에 진행 중이던 공고도 모두 접수 마감일이 따로 잡혀 있었습니다.
이렇게 볼 수 있어요
접수 마감일이 지나면 공고가 목록에서 빠지고 이 페이지에도 마감으로 표시됩니다. 같은 직무가 새 공고로 다시 올라오는 경우도 있으므로 마감된 공고라면 채용 사이트에서 같은 이름의 공고를 다시 찾아보면 됩니다.
이 공고만 다른 점
서류 뒤에 코딩테스트전형이 있고 화상으로 1시간 가량 라이브로 진행됩니다. 그다음 1차 실무진 면접과 2차 경영진 면접이 이어집니다.
라이브 코딩이라 혼자 푸는 시험과 달리 풀이 과정을 말로 설명해야 합니다. 접수 기간은 2026년 10월 14일까지, 서류전형 결과 발표는 10월 21일 이내로 적혀 있습니다.
지원 전 준비할 것
- 1
파이프라인 설계 사례
처음부터 만든 CI/CD 파이프라인 하나를 골라 구성, 쓴 도구, 줄어든 배포 시간을 정리해 두세요.
- 2
라이브 코딩 연습
코딩테스트가 화상 라이브로 1시간 가량 진행됩니다. 풀이를 말로 설명하며 푸는 연습을 따로 해 두는 것이 좋습니다.
- 3
규정과 속도를 함께 다룬 경험
보안 검토나 승인 절차를 배포 흐름에 넣으면서도 배포 속도를 지킨 경험이 있다면 팀이 내건 목표와 바로 맞는 사례가 됩니다.