왜 지금인가 — 은행이 'AI가 짜는 개발'을 조직으로 만들다
2026년 7월 1일, KB국민은행은 서울 여의도에 'KB AI Dev 센터'를 개소했다. 이환주 행장이 직접 개소식을 주재했고, 이튿날인 7월 2일 공식 발표가 나왔다. 센터의 역할은 명확하다. 코드 자동생성, 프로토타입 제작, 보안·오류 검증, 최신 AI 기술의 적용 테스트를 전담하는 AI 개발 전초기지다.
가장 눈에 띄는 대목은 개발 방식 자체가 바뀐다는 점이다. 기존에는 개발자가 직접 설계하고 코딩했다면, 이제는 사용자가 원하는 기능을 일상적인 언어로 설명하기만 하면 AI가 이를 분석해 설계·코드 생성·프로토타입·실시간 오류 검증까지 일괄 지원한다. 그리고 그 실무 개발 과정에 글로벌 AI 코드 에이전트인 Claude Code를 '패스트트랙' 체계로 연계한다.
"사용자가 원하는 기능을 일상적인 언어로 설명하면 AI가 이를 분석해 설계·개발·실시간 오류 검증까지 지원한다 — 금융의 본질인 신뢰와 안정성을 기술 혁신으로 강화하겠다." — KB국민은행, 'KB AI Dev 센터' 개소 (2026.07.02 발표)
우리는 이 흐름을 계속 추적해 왔다. EP30 우리은행×삼성SDS(SI 주도 멀티에이전트), EP63 신한은행(AI팀 주도 4-Agent 개발 파이프라인), EP72 IBK기업은행(현업 731명 시민개발자)까지. KB가 보여주는 건 또 다른 축이다. 자체 LLM을 만들거나 현업에게 빌더를 쥐여주는 대신, 이미 검증된 상용 코딩 에이전트를 그대로 쓰되, 은행의 규정 준수를 자동화하는 통제 레이어로 감싸는 접근이다. 그 통제 레이어의 이름이 바로 '하네스'다.
BEFORE — "그냥 AI에게 맡기면" 은행에서 왜 안 되나
AI 코딩 도구의 생산성은 이미 논쟁의 대상이 아니다. 문제는 금융권이라는 환경이다. 일반 스타트업이라면 개발자가 프롬프트를 던져 나온 코드를 곧바로 병합해도 된다. 그러나 은행은 다르다. 코드 한 줄이 이체·여신·인증 흐름에 닿고, 규정 위반은 그대로 감독 대상 사고가 된다.
① 보안정책 미준수 (Security Drift)
AI가 생성한 코드에 하드코딩된 시크릿, 미검증 입력 처리, 과다 권한 부여가 그대로 커밋될 수 있다. 개인 개발자가 매번 눈으로 잡아내야 한다면 언젠가 반드시 샌다.
② 표준 이탈 (Standard Drift)
은행에는 공통 프레임워크, 로깅 규약, 인증·인가 표준이 있다. AI가 이를 모른 채 '동작하는 코드'만 만들면, 표준을 벗어난 파편적 코드가 쌓이고 유지보수·감사 비용이 폭증한다.
③ 감사 공백 (Traceability Gap)
누가 어떤 프롬프트로 무슨 코드를 만들어 넣었는지 추적할 수 없으면, 사고 발생 시 책임 규명이 불가능하다. 전자금융거래법 개정(EP52)이 대표이사·CISO 책임을 강화한 지금, 추적성은 선택이 아니다.
이 세 가지가 묶이면, AI는 코드를 '빠르게' 만들지만 규정 준수는 결국 개발자 개인 역량에 맡겨진다. 은행 규모에서 개인 역량에 의존하는 통제는 통제가 아니다.
AFTER — 하네스: AI 코드 에이전트를 감싸는 4단계 게이트
KB의 해법은 상용 코딩 에이전트를 대체하는 게 아니라 감싸는 것이다. Claude Code는 그대로 쓴다. 대신 요구사항 기획부터 코드 생성, 빌드, 테스트에 이르는 개발 전 과정에 은행의 개발표준과 보안정책을 자동으로 주입·검증하는 레이어를 얹는다. 이것이 자체 개발한 '하네스' 체계다.
핵심은 S2와 S3의 분리다. 생성은 상용 AI에 맡기되, 통과는 은행이 정한 게이트가 결정한다. AI의 속도를 그대로 취하면서, 은행 규정의 책임은 놓지 않는다. 이 구조가 'AI 코딩 거버넌스'의 핵심 문법이다.
하네스는 어떻게 작동하나 — Policy-as-Code
하네스의 통제가 개념에 그치지 않으려면, 표준·보안 규칙이 실행 가능한 코드여야 한다. 사람이 매번 체크리스트를 읽는 방식으로는 규모를 못 견딘다. 아래는 하네스의 정책이 어떤 형태로 표현될 수 있는지를 보여주는 구조 예시다(개념 도식).
agent: "claude-code" # 패스트트랙 연계
stages:
requirement:
inject: ["secure-coding.md", "bank-api-std"] # 규칙 주입
generate:
allow_framework: ["kb-common", "spring-secure"] # 승인된 것만
build: # 자동 게이트 — 위반 시 병합 차단
- sast: block_on_high # 정적분석 고위험
- secret_scan: true # 하드코딩 시크릿
- deps_cve: block # 취약 의존성
test:
human_approval: required # 최종 승인은 사람
audit_log: "prompt + diff 전수" # 추적성 확보
deploy: "거버넌스 통과 후에만" # 표준 미준수 배포 불가
이 정책 파일이 갖는 무게가 있다. human_approval: required는 6.22 시행된 금융 AI 7대 원칙 중 '보조수단성' 원칙(EP69)이 개발 파이프라인으로 내려온 것이다. build 게이트는 EP34(LiteLLM 공급망 공격)·EP38(가짜 SOC 2 인증)에서 본 위협 — 검증 없는 코드/의존성 유입 — 에 대한 방어선이다. audit_log는 전자금융거래법 개정(EP52)이 요구하는 책임 추적성을 코드 레벨에서 확보한다.
BEFORE → AFTER: AI 코딩 도입 모델의 차이
| 항목 | BEFORE — 통제 없는 Raw AI 코딩 | AFTER — 하네스 거버넌스 |
|---|---|---|
| 코딩 주체 | 개발자 + AI (개인 판단) | Claude Code + 하네스 게이트 |
| 보안 준수 | 개인 역량 의존 | SAST·시크릿·CVE 자동 차단 |
| 표준 반영 | 사후 코드리뷰 | 승인 프레임워크로 사전 강제 |
| 추적성 | 불투명 (누가·뭘) | prompt+diff 전수 감사 로그 |
| 배포 결정 | 병합=배포 | 거버넌스 통과 + 사람 승인 |
| 속도 vs 통제 | 속도만 | 속도 유지 + 통제 자동화 |
센터가 맡는 것 — 그리고 국내 3사의 다른 길
KB AI Dev 센터는 코드 자동생성·프로토타입 제작·보안 및 오류 검증·최신 AI 기술 적용 테스트를 전담한다. 특히 '최신 AI 기술의 적합성 평가'를 센터 기능에 명시한 점이 눈에 띈다. 상용 AI 코드 에이전트 생태계가 빠르게 바뀌는 만큼, 새 도구를 은행 환경에 안전하게 편입할지 판단하는 상시 게이트키핑 조직을 둔 것이다.
신한은행 (EP63) — AI팀 주도 4-Agent 개발 파이프라인. 개발·테스트·코드리뷰·배포검증을 4개 에이전트가 나눠 맡고, 망분리 온프레미스 LLM 위에서 돌린다. 자체 구축·자체 모델 노선.
IBK기업은행 (EP72) — 현업 731명이 사내 플랫폼 '제니' 위에서 업무 에이전트를 직접 빌드. 현업 주도·시민개발자 노선.
KB국민은행 (EP73) — 상용 Claude Code를 그대로 쓰되 자체 하네스로 통제. 상용 툴 + 거버넌스 레이어 노선. 자체 모델 구축 부담 없이 최신 도구 성능을 빠르게 취하면서, 규정 준수는 게이트로 강제하는 절충안이다.
어느 노선이 정답이라고 단정할 수 없다. 다만 KB의 접근은 'AI 도구는 계속 좋아진다'는 전제 위에서 유연하다. 모델·에이전트가 바뀌어도 하네스라는 통제 레이어는 유지되기 때문이다. 통제의 무게중심을 '어떤 AI를 쓰느냐'가 아니라 '무엇을 통과시키느냐'에 둔 설계다.
커리어 인사이트 — AI 네이티브 뱅킹 개발 3직무
AI가 코드를 짜는 시대에 개발자의 가치는 사라지는 게 아니라 이동한다. '얼마나 빨리 짜느냐'에서 '무엇을 통과시키고, 무엇을 막느냐'로. KB의 하네스 모델은 이 전환을 세 축의 직무로 분화시킨다.
특히 시큐어 코딩·AppSec 트랙의 수요가 구조적으로 커진다. AI가 코드를 대량 생산할수록, 그 코드를 자동으로 검문하는 게이트의 정교함이 병목이자 경쟁력이 되기 때문이다. '코드를 짜는 사람'보다 '코드를 통과시킬지 판단하는 시스템을 만드는 사람'의 값이 오른다.
타임라인 — 한국 뱅킹 AI 개발의 진화
마무리 — AI가 짜도, 책임은 은행이 진다
KB AI Dev 센터의 진짜 메시지는 'AI로 코딩한다'가 아니다. 그건 이미 모두가 한다. 핵심은 AI의 속도를 취하면서 은행의 책임을 놓지 않는 방법을 조직과 코드로 명문화했다는 점이다. 생산성은 상용 Claude Code에서, 통제는 자체 하네스에서. 이 분리가 KB가 연 문의 본질이다.
물론 과제도 분명하다. 하네스 밖의 셰도우 AI를 어떻게 막을지, 게이트가 개발 속도를 다시 병목으로 만들지 않을지, 상용 도구 의존이 새로운 벤더 락인이 되지 않을지. 그러나 방향은 옳다. 전자금융거래법 개정과 금융 AI 7대 원칙이 요구하는 '책임 추적 가능한 AI'는, 결국 이런 게이트 없이는 구현되지 않는다.
커리어 관점에서 이 흐름은 하나의 신호를 보낸다. AI가 코드를 대량 생산할수록, 값이 오르는 건 코드를 통과시킬지 판단하는 시스템을 설계하는 사람이다. 플랫폼 엔지니어든, AppSec든, AI 거버넌스든 — 'AI가 만든 코드를 은행 규정 안에서 안전하게 흘려보내는 파이프라인'을 만들어 본 경험이, 앞으로 5년간 가장 강력한 시그널이 된다.
- 서울경제 (2026.07.02) KB국민은행, AI가 코딩하는 'KB AI Dev 센터' 출범 https://www.sedaily.com/article/20063160
- 서울신문 (2026.07.03) KB국민은행, AI 코딩으로 금융 서비스 개발 https://m.seoul.co.kr/news/2026/07/03/20260703023005
- 파이낸셜투데이 (2026.07) 국민은행, 'AI 개발 전진기지'로 금융 패러다임 바꾼다 https://www.ftoday.co.kr/news/articleView.html?idxno=361476
- 뉴스핌 (2026.07.02) KB국민은행, AI 활용 금융서비스 개발 방식 혁신 위한 'KB AI Dev 센터' 출범 https://www.newspim.com/news/view/20260702000367
- 헤럴드경제 (2026.07) KB국민은행, AI 개발 전초기지 'KB AI Dev 센터' 출범 https://biz.heraldcorp.com/article/10795693
- 금융위원회 「금융분야 AI 통합 가이드라인」 7대 원칙 (2026.06.22 시행) — FinIT Log EP69
- FinIT Log 연결 EP — EP17(은행 자체 LLM), EP52(전자금융거래법 개정), EP53(KB AWS 정보계), EP63(신한 4-Agent), EP69(AI 7대 원칙), EP72(IBK 제니)
