금융권의 Amazon Bedrock 도입, Claude Code 개발자는 무엇을 만들어야 하나

금융권이 Amazon Bedrock을 도입한다는 소식은 Claude Code를 쓰는 개발자에게 무엇을 바꿔 놓을까. 클코단에서는 관련 글이 여러 차례 공유됐지만 구현 방식에 관한 토론은 이어지지 않았다. 답을 찾으려면 ‘모델을 어디서 호출하나’와 ‘직원이 어떤 자료를 확인하게 하나’를 나눠 봐야 한다.

금융권 사례의 출발점은 내부 문서를 찾는 일이었다

AWS가 공개한 Coast Capital Savings 사례에서 첫 사용자는 고객이 아니라 대출 업무 직원이었다. 직원이 방대한 사내 자료에서 필요한 답을 찾도록 챗봇을 만들었고 이후 인사 관련 내용도 검색 범위에 넣었다. AWS에 따르면 작동하는 시제품을 만드는 데 3주가 걸렸다. (aws.amazon.com)

이 사례의 성과를 수익 증가나 업무 자동화로 확대해서 읽어서는 안 된다. AWS가 제시한 인사 부서 문의 감소율 25~30%는 실현된 감소치가 아니라 잠재적 효과다. 더 구체적인 산출물은 챗봇이 답과 함께 원문으로 가는 연결을 제공했다는 점이다. (aws.amazon.com)

클코단에서 공유된 금융권 글의 세부 내용은 대화에 남아 있지 않다. 그 글이 특정 금융사의 도입 효과를 입증했다고 말할 근거도 없다. 확인 가능한 Coast Capital Savings 사례는 다른 질문을 남긴다. 직원이 답을 믿기 전에 근거 문서까지 확인할 수 있게 만들었는가?

문서 챗봇은 자료 정리부터 답변 검사까지 이어진다

Coast Capital Savings는 처음에 Amazon Kendra를 사용하다 Amazon Bedrock Knowledge Bases로 옮겼다. 운영 과정에서 팀이 중요하게 본 문제는 모델 교체보다 문서의 정확도와 관련성이었다. AWS 사례는 자료를 정리하는 작업도 뒤따랐다고 설명한다. (aws.amazon.com)

같은 유형의 시제품을 만든다면 입력은 승인된 업무 지침과 FAQ 문서다. 먼저 오래된 판본과 중복 파일을 가려내고 접근 가능한 문서만 Amazon S3에 둔다. Bedrock Knowledge Bases에서 S3를 데이터 소스로 연결한 뒤 임베딩 모델과 벡터 저장소를 고르고 동기화한다. AWS 문서는 저장소 선택지로 Amazon OpenSearch Serverless와 Amazon S3 Vectors 등을 안내한다. (docs.aws.amazon.com)

그다음 ‘해당 대출 상품의 신청 조건은 무엇인가’처럼 실제 직원이 물을 질문으로 검색을 시험한다. Knowledge Bases는 관련 문서 조각을 가져와 모델의 답변에 활용할 수 있다. 화면에는 생성된 답뿐 아니라 확인에 쓴 원문도 보여줘야 한다. 자료에 없는 조건을 물었을 때 답을 꾸며내지 않는지도 별도로 검사해야 한다. (docs.aws.amazon.com)

여기까지의 산출물은 직원용 문서 검색 서비스다. Claude Code의 대화창에 문서를 넣어 답을 받는 일과는 다르다. 동료들이 반복해서 쓸 데이터 소스와 검색 흐름, 접근 권한, 검증 절차가 필요하다.

Claude Code를 Bedrock에 연결해도 챗봇이 생기지는 않는다

Claude Code 공식 문서는 Amazon Bedrock을 모델 호출 경로로 지원한다. AWS 인증과 사용 가능한 리전·모델을 준비한 뒤 시작 화면에서 타사 플랫폼과 Amazon Bedrock을 선택할 수 있다. 이미 Claude Code를 쓰고 있다면 /setup-bedrock 설정 마법사도 제공된다. 수동 설정에서는 CLAUDE_CODE_USE_BEDROCK=1을 지정하고 필요하면 AWS_REGION을 설정한다. (code.claude.com)

개발자는 이렇게 연결한 Claude Code에 챗봇의 검색 API, 문서 동기화 작업, 테스트 코드 작성을 맡길 수 있다. 그러나 Bedrock으로 Claude Code를 실행했다고 직원용 Knowledge Bases가 생성되거나 사내 파일의 열람 권한이 정해지지는 않는다. 코딩 도구의 모델 접속 설정과 실제 서비스의 데이터 설계는 별개다. (code.claude.com)

접속 설정에도 경계가 있다. 공식 문서는 모델 호출에 필요한 IAM 권한을 명시하고 조직별로 사용할 모델과 추론 프로필의 접근 범위를 좁힐 수 있다고 안내한다. 선택한 AWS 리전에서 모델을 호출할 수 있는지도 확인해야 한다. 금융권 팀은 기존 AWS 권한 체계 안에서 Claude Code를 사용할 때 이 권한 범위를 구체화해야 한다. (code.claude.com)

고객 정보까지 다루면 검색 도구마다 권한이 달라진다

직원용 지침 검색과 고객별 신용 분석은 요구 조건이 다르다. AWS가 2026년 7월 공개한 참조 아키텍처는 대출 규정 PDF를 Amazon S3에 두고 고객 자료는 Snowflake에서 조회한다. 에이전트는 Bedrock Knowledge Bases 검색 도구와 Snowflake 조회 도구를 MCP로 호출해 근거가 포함된 적격성 *권고안*을 만든다. 실제 은행의 승인 실적이 아니라 AWS의 참조 구현이다. (aws.amazon.com)

설계에서 눈여겨볼 부분은 검색 경로의 구분이다. 공통 규정 문서는 에이전트의 IAM 역할로 찾지만 고객 자료는 분석가 개인의 인증을 거쳐 조회한다. AWS는 고객 자료를 다루는 도구에 별도 접근 정책을 적용하고 민감정보를 가리는 Guardrails를 설정했다. MCP 연결만으로 사용 권한까지 해결된다는 이야기가 아니다. (aws.amazon.com)

규제 업무에 공급한다는 이유만으로 이 구성을 통째로 복제할 필요는 없다. 작은 팀이 직원용 문서 챗봇을 납품한다면 먼저 공통 문서만 검색하는 범위를 정할 수 있다. 고객별 기록을 붙이는 순간에는 누가 어떤 도구로 어느 자료를 조회했는지 추적할 설계가 추가된다. AWS의 금융서비스 아키텍처 지침도 AI의 데이터 접근과 도구 사용을 통제 대상으로 다룬다. (docs.aws.amazon.com)

도입 가능성과 운영 가능성은 다른 시험이다

Bedrock Guardrails는 입력과 출력에 필터를 적용할 수 있지만 정책을 구성하고 호출에 연결해야 작동한다. Claude Code 역시 Guardrail을 만들고 버전을 게시한 뒤 설정에 연결하는 절차를 문서화했다. AWS 문서는 보호 조치를 적용한 뒤에도 요구 조건에 맞는지 계속 시험하라고 권고한다. (docs.aws.amazon.com)

감사 기록도 자동으로 남는다고 가정하면 위험하다. AWS에 따르면 Bedrock의 모델 호출 로깅은 기본적으로 꺼져 있으며 활성화하면 입력과 출력이 로그 대상에 포함될 수 있다. 기록이 필요한 범위와 그 기록에 누가 접근할지는 함께 결정해야 한다.

써본 사람들 사이에서는 벡터 저장소의 지속 비용과 필터의 과잉 차단을 걱정하는 반응도 있다. 개별 경험을 일반적인 장애율이나 비용으로 바꿔 말할 수는 없다. (docs.aws.amazon.com)

금융권 Bedrock 도입을 개발자의 작업으로 번역하면 첫 결과물은 ‘AI가 답하는 화면’이 아니다. 정리된 문서를 검색하고 근거를 보여주며 허용된 사람만 자료에 닿게 하는 서비스다. Claude Code는 그 서비스를 만드는 데 쓸 수 있고 Bedrock에서 모델을 호출할 수도 있다. 둘을 연결한 다음에도 남는 질문은 같다. 답이 틀리거나 자료가 바뀌었을 때, 누가 어느 문서와 호출 기록을 확인할 수 있는가?