금융권 AWS Bedrock 도입, 망분리 풀려도 왜 더딘가

금융 시스템통합(SI) 업계에서 최근 부쩍 자주 나오는 질문이 있다. 망분리가 조금씩 풀리는 지금, 은행이나 보험사가 생성형 AI를 쓰려면 API를 직접 호출하는 게 나을까, 아니면 AWS Bedrock 같은 관리형 서비스를 거치는 게 나을까. 보안과 감사 편의성만 보면 답은 뻔해 보이지만, 물량과 비용을 따지기 시작하면 얘기가 달라진다. 이 질문에 답하려면 먼저 무엇이 실제로 풀렸고 무엇이 여전히 막혀 있는지부터 짚어야 한다.

4월 20일, 무엇이 풀렸나

금융위원회는 2024년 8월 '금융분야 망분리 개선 로드맵'을 내놓은 뒤 단계적으로 규제를 완화해왔고, 2026년 4월 20일 전자금융감독규정 시행세칙 개정안이 시행되면서 침해사고 대응기관의 평가를 통과한 SaaS에 한해 내부 업무망 사용이 공식 허용됐다. 그전까지는 외부 인터넷과 단절된 망 안에서 메신저나 화상회의 같은 기본 협업 도구조차 쓰기 어려웠던 게 현실이다.

다만 평가를 통과한 서비스만 쓸 수 있다는 전제가 붙는다. 금융보안원은 AWS·구글클라우드·KT클라우드·마이크로소프트·네이버클라우드·NHN클라우드·오라클·삼성SDS·카카오엔터프라이즈 9개 클라우드 사업자와 함께 보안 관리 참고서를 마련했고, 2026년 취약점 분석·평가 기준에는 '클라우드 관리체계' 항목 73개를 신설해 평가 항목을 869개로 늘렸다. 규제가 풀렸다기보다 보안 평가와 사후 통제를 전제로 예외가 허용됐다고 보는 편이 정확하다. 은행권은 클라우드 도입률이 상대적으로 낮은 축에 속해, 이번 개정의 체감 효과가 가장 크게 나타날 업권으로 꼽힌다.

Bedrock이 유리하다는 근거는 실재한다

방 논의에서 나온 "Bedrock이 API 직접 호출보다 보안·감사 편의성에서 유리하다"는 주장은 근거가 있다. Bedrock은 AWS IAM 권한 체계로 접근을 통제하고 CloudTrail로 API 호출 이력을, 모델 호출 로깅으로 입출력 데이터와 토큰 수까지 별도로 남긴다. API 키를 여러 벤더별로 따로 관리할 필요가 없고, 이미 AWS 인프라와 빌링 체계를 쓰는 조직이라면 새 계약이 아니라 기존 구조의 연장으로 AI를 붙일 수 있다.

컴플라이언스 쪽 무게도 가볍지 않다. Bedrock 계열 서비스는 PCI DSS·PCI 3DS 인증 범위에 포함돼 있고 SOC 2, ISO 27001 등 국제 인증도 갖췄다. AWS Audit Manager는 생성형 AI 구현을 권장 모범 사례와 대조해 살펴볼 수 있는 사전 구축 프레임워크까지 제공한다. 감사 대응 인력이 따로 크지 않은 조직 입장에서는 이런 기성 체계를 그대로 가져다 쓸 수 있다는 게 실질적인 이점이다. 개인신용정보처럼 유출 시 파급력이 큰 데이터를 다루는 금융권에서 이 부분이 갖는 무게는 다른 산업과 다르다.

"물량이 안 되면 구독제가 더 싸다"는 반박

방에서 나온 반박도 무시하기 어렵다. 자체 서빙이든 관리형 서비스 기반 구축이든 초기 인프라 투자가 크고, 이후에는 모델 유지·데이터 갱신·보안 관리 비용이 계속 들어간다. 반면 상용 API 구독은 초기 투자가 거의 없는 대신 사용량에 비례해 비용이 늘어난다. 어느 쪽이 유리한지는 결국 요청량이 갈라놓는데, 방에서 언급된 손익분기 감각은 물량이 중요하다는 점을 보여준다.

Bedrock 요금 구조를 실제로 뜯어본 쪽에서는 온디맨드 요금 자체보다 부가 비용이 변수라는 지적이 많다. 소규모 트래픽에서는 벡터 스토어나 예약 처리량 같은 부가 요소가 기본 API 비용의 상당 부분을 더 얹는다는 분석도 나온다. 캐싱을 붙이지 않은 프롬프트, 트래픽 예측 없이 예약해둔 처리량이 비용을 불필요하게 키우는 전형적인 패턴으로 꼽힌다. 물량이 작은 조직이라면 관리형 서비스의 편의 대가로 붙는 이런 비용이 구독제보다 오히려 비싸질 수 있다는 뜻이다. 이 계산은 금융권만의 이야기가 아니다. 소규모 팀이 어떤 AI 서비스를 쓸지 고를 때도 똑같은 잣대가 적용된다 — 트래픽이 작을 때는 관리형 인프라의 부가 비용이 상용 구독보다 부담스러울 수 있다.

여러 회사 모델을 하나의 API로 갈아탈 수 있다는 벤더 종속 회피 논리도 완전하지는 않다. Bedrock 안에서 모델을 바꾸는 건 쉽지만, Bedrock의 에이전트·지식베이스·가드레일·IAM·VPC 통합까지 엮이고 나면 AWS 생태계 자체에 대한 의존은 오히려 깊어진다는 지적도 있다. 이미 특정 모델에 맞춰 프롬프트와 운영 흐름을 정교하게 다듬어온 팀 사이에서는, 모델을 바꾸는 순간 그 튜닝을 다시 해야 한다는 불만도 나온다. 편의를 사는 대신 다른 종류의 종속을 사는 셈이라는 얘기다.

post-training은 누가 맡는가

방 논의에서 나온 "post-training은 기업이 아니라 AI 프로바이더가 담당하는 구조"라는 설명도 대체로 맞다. 파인튜닝과 post-training은 다른 작업이다. 파인튜닝은 모델의 지식이나 행동을 특정 목적에 맞게 조정하는 기법이며, post-training은 지도학습·선호학습·강화학습 등을 포괄하는 더 넓은 개념이다. 구글과 앤트로픽의 일부 모델은 클라우드 플랫폼을 통해 파인튜닝할 수 있고, OpenAI는 2026년 5월 8일 신규 사용자에 대한 파인튜닝 플랫폼 접근을 중단한다고 밝혔다.

기업이 직접 손대는 영역에는 소규모 모델에 LoRA 같은 경량 기법을 얹는 방식이 있다. 이 구조를 받아들이면 "기업은 무엇을 살지 고르고, 모델 자체를 빚는 일은 프로바이더 몫"이라는 역할 분담이 자연스럽게 따라온다.

규제가 풀려도 못 움직이는 이유

망분리가 완화됐다고 금융권이 곧바로 움직이는 것도 아니다. 금융연구원 쪽 분석에 따르면 해외에서는 비자·마스터카드·스트라이프 같은 회사들이 AI 에이전트 관련 파일럿을 활발히 돌리는 반면, 국내 금융사는 규제 안에서 공격적으로 움직이기 어려운 처지다. 결제를 자동으로 수행하는 AI가 오류를 내면 책임 소재 분쟁으로 번질 수 있는데, 지금 구조에서는 책임 배분 기준이 불분명하다. 여기에 개인신용정보 국내 보관 의무, 낡은 결제 인프라, 백오피스 자동화가 인력 재배치로 이어지기 어려운 조직 경직성까지 겹친다.

전통 금융권이 구조적으로 보수적이어서 상위 정책 없이는 자발적 변화가 어렵다는 방 논의의 결론은, 규제 완화 로드맵과 평가 체계 확장이라는 실제 정책 흐름과도 맞아떨어진다. 다만 그 정책이 만들어내는 건 전면 개방이 아니라 "승인받은 서비스만, 승인받은 방식으로" 쓰는 좁은 통로다. Bedrock이든 직접 API든, 그 통로 안에서 물량과 책임 구조를 감당할 수 있는 회사부터 먼저 움직이게 될 것이다.