Executive Summary
- 고객 맥락 이해(Context Layer): 고객 상황과 업무 지식을 연결해, AI 응답의 개인화 수준과 정확도를 높입니다.
- 금융 실행 통제(Control Layer): AI의 실행 요청을 권한·규정에 따라 검증해, 금융 사고 위험을 줄입니다.
- 업무 지식의 자산화: 은행 고유의 지식과 통제 기준을 AI가 활용할 수 있도록 체계화해, 차별화된 경쟁력을 확보합니다.
금요일 저녁 7시. 한 고객이 은행 앱에서 친구에게 300만 원을 이체하려다 실패 메시지를 받습니다. 다시 눌러도 마찬가지라 고객은 챗봇을 열고 묻습니다.
"이체가 왜 안 돼요?"
"이체가 되지 않는 원인은 잔액 부족, 한도 초과, 계좌 상태 이상 등 다양합니다. 자세한 내용은 고객센터로 문의해 주세요."
틀린 말은 없지만 도움도 되지 않습니다. 문제는 은행이 이미 답을 알고 있었다는 데 있습니다. 로그에는 10분 전 1일 이체 한도 초과로 2회 실패한 기록이 있고, 계정계는 이 고객의 한도가 비대면 기본값 200만 원임을 알며, 상품 규정에는 추가 인증 시 상향이 가능하다고 적혀 있습니다. 필요한 정보는 모두 은행 안에 있었고, 챗봇에 닿지 않았을 뿐입니다.
이 보고서는 이 간극에서 출발합니다. AI 에이전트의 상황 인지를 완성하는 Context Layer가 왜 Agentic Banking의 첫 번째 과제인지, 그리고 안전한 금융 실행을 위해 Control Layer가 왜 반드시 병행되어야 하는지 살펴보겠습니다.
앞으로 은행 AI의 병목은 지능(모델)이 아니라 맥락(Context)이다. 암묵지와 코드 속에 흩어진 업무 지식을 기계 판독형으로 구조화해 AI에게 알려주는 계층(Context Layer), 그리고 비결정적 에이전트의 금융 거래 요청을 최종 단계에서 검증해 지키게 하는 게이트웨이(Control Layer). 이 두 계층을 통해 금융 에이전트의 성능을 끌어올리는 동시에, 추론 오류와 규제 리스크를 방어해야 합니다.
전사 플랫폼을 처음부터 노리기보다 단일 유스케이스에서 출발하되, 두 가지는 초기부터 기준선으로 삼아야 합니다. 하나는 Context Layer가 '미확인 상태'를 명시해 환각을 억제하는 것이고, 다른 하나는 Control Layer가 해당 시점에 사용한 맥락(맥락 스냅샷)과 결합한 감사 기록을 남기는 것입니다.
똑똑한 은행 AI, 왜 고객의 문제를 풀지 못하는가
앞의 장면이 특별한 상황은 아닙니다. Capgemini 조사에서 은행 챗봇 이용 고객의 61%는 답변에 만족하지 못해 결국 상담원에게 다시 문의했습니다.[1] DECTA의 유럽 은행·결제 앱 분석에서 결제 차단 문제를 챗봇이 해결한 비율은 11.4%에 그쳤고, 50.0%는 상담원 이관, 14.9%는 미해결로 종결됐습니다.[2] 미국 소비자금융보호국(CFPB)은 질문이 복잡해질수록 챗봇 효용이 급감하며, 화면에 표시된 계정 상태와 실제 상태의 괴리가 대표 민원이라고 진단했습니다.[3]
이 실패들의 공통점은 질문이 고객 고유의 상황("나의 맥락")에 닿아 있다는 점입니다. "영업시간 안내"는 누구에게나 답이 같지만, "내 이체가 왜 막혔는지", "지난주 중단한 대출 신청을 이어갈 수 있는지"는 고객별 상태 데이터를 결합해야만 답할 수 있습니다. 금융 문의의 상당수가 이런 유형의 질문입니다. Bank of America의 Erica 사례에서도 누적 32억 건의 상호작용 중 19억 건이 고객 데이터 기반의 선제적·개인화 인사이트였다고 합니다.[4]
고객이 AI에서 체감하는 효용은 범용 정답이 아니라 '내 상황'에 부합하는 답에서 나옵니다. 은행 AI의 본질적 병목은 모델의 지능이 아니라 맥락의 부재입니다.
평준화된 모델 성능, Agentic AI 서비스 차별점은 맥락(Context)
지난 2년간 금융권 AI 논의는 “어떤 LLM을 도입할 것인가”에 집중되어 있었습니다. 하지만 Stanford AI Index 2025에 따르면 상황이 달라지고 있습니다. Chatbot Arena 1위와 10위 모델의 격차는 1년 사이 11.9%에서 5.4%로 줄었고, GPT-3.5급 성능의 추론 비용은 2022년에서 2024년 동안 280분의 1 이하로 떨어졌습니다.[5] 이제는 비슷한 모델을 비슷한 가격에 쓰는 시대가 오고 있습니다.
모델이 평준화되면 차별점은 그 모델에게 무엇을 알려줄 수 있느냐에서 나옵니다. 은행은 수십 년의 거래·여신·상담 이력과 그것을 해석하는 업무 규정이라는, 누구도 갖지 못한 자산을 쥐고 있습니다. 문제는 이 자산이 AI가 쓸 수 있는 형태가 아니라는 것입니다. Anthropic이 2025년 "프롬프트 엔지니어링에서 컨텍스트 엔지니어링으로의 전환"을 선언하고,[6] Gartner가 2026년 3월 AI 에이전트를 위한 Context Layer를 별도 아키텍처 계층으로 규정하며 의미(Semantics), 운영 상태(Operational State), 출처 추적(Provenance)을 핵심 구성요소로 제시한 배경이 여기에 있습니다.[7]
그런데 이 개념을 처음 접한 사람들은 거의 예외 없이 같은 질문을 던집니다.
"그거 그냥 RAG나 MCP 아닌가?"
AI가 최종적으로 받는 것이 조회된 정보가 담긴 프롬프트라는 점에서, RAG(Retrieval-Augmented Generation), MCP(Model Context Protocol)와 혼선이 발생합니다. 그 차이는 다음과 같습니다.
첫째, RAG나 API 조회는 "가져오는 수단"이고, Context Layer는 "무엇을, 어떤 의미와 권한으로 줄지 정한 체계"다. 앞의 이체 사례를 구현하려면 누군가 결정해야 합니다. 어떤 로그를 가져올 것인가. STAT_CD = 'H'는 지급정지인가 휴면인가. 잔액은 실시간인가 D-1 기준인가. 기존 프로그램도 이런 조회를 합니다. 하지만 그 결정들은 코드 안에 묻혀 있기 때문에, 그 결정 로직을 소비하는 주체가 프로그램에서 AI로 바뀌는 순간 그것들을 밖으로 꺼내야 합니다.
둘째, MCP는 연결 규격이지 통제가 아니다. 콘센트 규격이 정해졌다고 전기가 어디서 오고 얼마나 흘러도 되는지가 정해지지 않습니다. MCP 사양 스스로가 도구에 붙은 "읽기 전용", "파괴적 행동" 같은 표시를 신뢰할 수 없는 힌트로 취급하라고 명시하고 있습니다.[8] Gartner는 의미 계층 없이 MCP에만 의존하는 에이전트 프로젝트의 60%가 2028년까지 실패할 것이라고 경고했습니다.[9] 기존 API에 MCP만 씌우면 이름만 바뀐 API가 될 뿐입니다. AI 행동을 통제하는 별도 Layer가 필요합니다.
셋째, Context Layer는 기술이 아니라 공통 자산화라는 투자 결정이다. 유스케이스가 하나뿐이라면 "챗봇에 고객 데이터 조회 기능을 붙인다"로 충분합니다. 그러나 상담 챗봇, 상담원 보조, 심사 보조가 각자 같은 계좌 상태를 조회하고 같은 코드값을 각자 해석하기 시작하면, 같은 고객에 대해 AI마다 다른 답을 내놓게 됩니다. Context Layer라는 이름은 "맥락을 유스케이스마다 따로 만들지 않고 한 곳에서 정의해 공유하겠다는 결정을 가리킵니다.
| 개념 | 정체 | 답하는 질문 |
|---|---|---|
| RAG / API 조회 | 정보를 가져오는 수단 | 어떻게 가져오는가 |
| MCP | AI와 도구를 잇는 연결 규격 | 어떻게 연결하는가 |
| Context Layer | 상황별 맥락을 정의하고 생성하는 체계 | 무엇을, 어떤 의미와 권한으로 줄 것인가 |
| Control Layer | AI의 행동을 검증하는 실행 게이트웨이 | 무엇을 허용할 것인가 |
“RAG와 API는 재료를 가져오는 방법이고, Context Layer는 그 재료로 무엇을 만들지 정한 레시피이자 주방이다.”
코드 안에 묻혀 있던 업무 지식을 꺼내는 일
기존 프로그램에서는 조회 범위를 개발자가 미리 정해 코딩했고, CRD_GRD 컬럼이 내부 등급인지 CB 등급인지는 개발자의 경험과 주석에 있었습니다. 요건 충족 여부는 if 문이, 고객의 가능한 행동은 화면 설계가 결정했습니다. API는 데이터만 주면 충분했습니다. 의미, 판단, 통제는 호출하는 프로그램이 책임졌기 때문입니다. 하지만 AI 에이전트에는 그 코드가 없습니다. 무엇을 조회하고 어떻게 해석하며 다음에 무엇을 할지를 실행 시점에 스스로 정하므로, 코드가 맡던 역할은 갈 곳을 잃습니다.
| 기존 프로그램(코드 내재화) | 에이전트 환경(필수 요구사항) |
|---|---|
| 개발자가 사전에 조회 쿼리 확정 | 목적에 따라 동적으로 맥락을 조립하는 엔진 |
| 필드 의미를 개발자 주석·경험으로 파악 | 데이터 자체에 기계 가독형 의미 메타데이터 부착 |
| 하드코딩된 if 문으로 규정 판단 | 외부 규칙 엔진이 계산된 판단 결과를 제공 |
| 화면 흐름으로 행동과 단계를 제한 | 허용·금지 행동 및 진행 단계를 명시적 파라미터로 제공 |
| 정적 호출 경로로 감사 용이 | 동적 실행 경로에 대한 출처·근거 추적 필수 |
따라서 Context Layer 구축의 본질은 신규 API 개발이 아니라, 코드와 실무자의 암묵지에 갇혀 있던 업무 지식을 외재화하여 기계가 읽을 수 있는 형태로 규격화하는 작업입니다. 기술적으로 새로운 것은 많지 않지만, 은행이 이 일을 체계적으로 해본 적은 없습니다. 그래서 "첫걸음"이 됩니다.
알려주는 계층과 지키게 하는 계층
흔한 오해는 Context Layer가 AI를 "통제할 수 있다"고 생각하는 것입니다. AI는 알려준 내용을 따르지 않을 수 있습니다. 프롬프트에 "규정을 준수하라"고 쓰는 것은 통제가 아니라 권고입니다. 따라서 역할을 둘로 나눠야 합니다. Palantir Foundry의 Ontology가 객체·관계를 정의하는 의미 요소(semantic)와 상태를 변경하는 통제된 행동인 실행 요소(kinetic)를 분리한 것도 같은 원리입니다.[10]
Context Layer: AI가 무엇을 알아야 하는가
업무 상황별로 어떤 정보를 어떤 의미와 권한 범위로 조합할지 정의하고, 그 정의에 따라 맥락을 생성해 AI에게 제공하는 계층.
Context Layer가 알려주는 것은 다섯 가지입니다.
- 현재 상황: 고객 식별, 보유 상품, 직전 발생 이벤트, 진행 중인 업무 단계
- 할 수 있는 것: 현 단계에서 허용되는 행동 범위
- 해서는 안 되는 것: 확정 금리 안내, 수익 보장 표현 등 금지 사항
- 반드시 해야 하는 것: 설명의무 고지, 고령 고객 추가 확인 등 규정상 의무
- 확인되지 않은 것: 데이터 기준 시각과 출처, 그리고 은행이 알지 못하는 것
다섯 번째는 흔히 빠뜨리지만, 환각(Hallucination) 억제의 핵심입니다. 고객이 대출 신청 화면을 사흘 연속 보다가 나갔다는 사실은 로그에 남지만, 왜 중단했는지, 아직 원하는지는 로그에 없습니다. 행동 로그는 맥락을 구성하는 신호이지 의도의 증거가 아닙니다. 이 구분을 명시하지 않으면 AI는 "고객님께서 대출을 원하셔서"라고 단정하는 문장을 자연스럽게 생성하게 됩니다. 확인된 사실과 추정의 구분은 금융에서 선택이 아니라 규율입니다.
한 가지 더 유의할 점이 있습니다. Context Layer가 알려주는 것은 "무엇을 해야 하는가"가 아니라 "무엇을 할 수 있는가"입니다. 그 범위 안에서 무엇을 할지 고르는 것은 AI의 몫이며, 선택까지 정해버리면 기존 프로그램과 다를 바 없어집니다. 규정상 제약이 아니라면 AI 자율성을 잘 활용할 수 있는 Context를 제공해야 합니다.
Control Layer: AI가 무엇을 해도 되는가
기존 뱅킹 API 전면에 독립적으로 위치해, AI의 행동 요청을 검증하고 통과 여부 결정·승인·기록을 수행하는 실행 게이트웨이.
AI는 기간계 API를 직접 호출할 수 없으며 오직 Control Layer에 행동을 '요청'합니다. 이는 OWASP가 LLM 10대 위험으로 꼽은 과도한 행위 권한(Excessive Agency) 대응 원칙, 즉 호출 가능 기능의 최소화, 고영향 행동에 대한 사람의 승인, AI 요청을 신뢰하지 않고 하위 시스템에서 재검증하는 원칙과도 부합합니다.[11]
| 구성 요소 | 역할 |
|---|---|
| 행동 카탈로그 | AI가 요청 가능한 행동 화이트리스트와 위험 등급. 목록에 없는 행동은 불가 |
| 신원·위임 확인 | 어떤 에이전트가, 어느 고객의 위임을 받아, 어떤 범위와 만료 조건으로 행동하는지 검증 |
| 정책·맥락 대조 | 요청된 행동이 이 고객·이 상황에서 허용되며 Context Layer의 허용 범위 안인지 확인 |
| 승인 절차 | 위험 등급에 따른 고객 추가 인증(MFA) 또는 직원 승인 연계 |
| 안전장치 | 멱등성 키, 호출 빈도 제한, 제한된 재시도, 서킷 브레이커 |
| 감사 기록 | 요청·판단·승인·실행 전 과정을 맥락 스냅샷과 결합해 보존 |
이 중 신원·위임 확인은 기존 채널 통제에 없던 항목입니다. 지금까지 은행 시스템의 사용자는 로그인한 사람 아니면 배치 프로그램이었습니다. 에이전트는 둘 다 아닙니다. 사람의 세션을 빌려 쓰지만 사람이 아니고, 프로그램이지만 정해진 경로만 타지 않습니다. "누가 어떤 에이전트에게 어떤 목적으로 권한을 위임했고 언제 만료되는가"를 사람의 로그인 세션과 분리해 추적해야 합니다. OAuth 2.0 Token Exchange(RFC 8693)는 위임 주체와 행위자를 토큰에 표현하는 표준적 선택지입니다.[12] 다만 표준은 표현 수단일 뿐, 어떤 위임을 어디까지 허용할지는 은행의 정책입니다.
Control Layer는 기존 업무 통제를 대체하지 않습니다. 이체 한도, 여신 요건, 거래 권한 검사는 기존 시스템이 원래대로 수행합니다. 같은 규칙을 두 곳에 두면 반드시 어긋납니다. Control Layer가 새로 맡는 것은 AI라는 새로운 대리 주체 때문에 생긴 통제뿐입니다. 모바일 뱅킹이 등장했을 때 은행은 코어를 다시 만들지 않고 채널계를 정비해 채널별 인증과 한도를 추가했습니다. AI는 새로운 채널이고, Control Layer는 그 채널의 통제 체계입니다.
| 구분 | Context Layer | Control Layer |
|---|---|---|
| 주요 질문 | AI가 무엇을 알아야 하는가? | AI가 무엇을 해도 되는가? |
| 데이터 흐름 | 은행 → AI (읽기 경로) | AI → 은행 (쓰기 경로) |
| 상호 접점 | 허용 행동 범위를 알려준다 | 제공된 범위를 실행 시점에 강제 검증한다 |
[그림1] Context Layer 와 Control Layer 아키텍처 구성 (출처: 저자 자체 제작)
- 무엇을 알아야 하나 (읽기) → Context Layer : 상황 · 의미 · 판단 결과, 허용 / 금지 / 의무 / 미확인
- 이걸 해도 되나 (쓰기) → Control Layer : 행동 카탈로그 · 신원/위임 · 정책 판단, 승인 · 실행 게이트
- 계정계
- 정보계 / CRM
- 룰 엔진 / FDS
- 규정 · 약관 문서
동작 구조와 설계 원칙
[그림2] AI 요청 처리 흐름: 맥락 조립부터 실행·검증까지 (출처: 저자 자체 제작)
이 흐름에는 중요하게 고려할 다섯 가지 설계 원칙이 있습니다.
- 기본 맥락의 선제 조립: "필요하면 찾아보라"고 맡기면 중요한 맥락을 빠뜨립니다. 특히 금지·의무 사항은 AI의 요청 여부와 무관하게 오케스트레이터가 먼저 주입하고, AI는 부족한 정보만 추가 요청합니다.
- 목적 중심의 맥락 경량화: 긴 입력 중간의 정보를 모델이 활용하지 못하는 "Lost in the Middle"[13]과, 최신 모델 18종 모두에서 입력이 길수록 신뢰도가 떨어진 "Context Rot"[14] 연구가 보여주듯, 맥락은 많을수록 좋은 것이 아닙니다. 목적에 맞게 덜어내는 것이 Context Layer의 핵심 기능입니다.
- 읽기 모델과 원장의 분리: Context Layer가 제공하는 상태는 여러 시스템을 연결한 읽기 모델입니다. 이벤트 스트림은 원천보다 늦을 수 있고 중복·순서 역전이 발생합니다.[15] 맥락에는 기준 시각과 출처가 붙어야 하며, 금전이나 계약 조건을 바꾸는 행동은 실행 직전 원천 시스템에서 현재 상태를 재확인해야 합니다.
- 결과 응답의 교차 검증: 대부분의 요청은 행동 없이 끝나지만 응답 검증은 반드시 거칩니다. 응답의 금리·금액·날짜가 맥락으로 받은 값과 일치하는지 규칙 기반으로 대조하는 것만으로 수치 조작형 환각의 상당 부분을 막습니다.
- 감사 기록의 분리 보존: "AI가 그때 왜 그렇게 답했는가"를 설명하려면 당시의 맥락 스냅샷과 규정·모델 버전을 재현할 수 있어야 합니다. 동시에 고객 원문 질문과 계좌 정보가 운영 관측 로그에 그대로 쌓여서는 안 됩니다. 추적 식별자와 성능 지표는 운영 로그에, 프롬프트와 도구 결과는 접근 통제·마스킹·보유 기간이 별도 설계된 감사 저장소에 둡니다. OpenTelemetry의 생성형 AI 규약은 호출 추적을 표준화하지만, 금융 감사 정책을 대신하진 않습니다.[16]
시나리오: 금리인하 요구 상담
고객이 "대출 금리를 낮출 수 있나요?"라고 묻는다면, Context Layer는 이를 "금리인하 상담" 상황으로 받아 필요한 정보만 조립하며, 가족 계좌나 카드 내역은 처음부터 제외됩니다.
{
"situation": "금리인하 요구 상담",
"customer": { "segment": "직장인", "credit_grade_change": "5→3 (2026-08)" },
"products": [{ "type": "신용대출", "rate": 6.2, "source": "계정계", "as_of": "2026-10-10T19:02:11" }],
"policy_result": {
"rule": "금리인하 요구권", "eligible": true,
"reason": "신용등급 2단계 상승", "source": "여신규정 제12조 v3.1"
},
"recent_events": ["2026-10-03 앱에서 금리인하 신청 중 이탈"],
"unconfirmed": ["이탈 사유", "현재 신청 의사"],
"allowed_actions": ["신청서 사전 작성", "상담원 연결"],
"forbidden": ["인하 후 금리 확정 안내"],
"obligations": ["심사 결과에 따라 인하 여부가 달라질 수 있음 고지"]
}
핵심은 policy_result와 unconfirmed입니다. 금리인하 대상 여부는 AI가 아니라 기존 룰 엔진이 계산한 결과이고, 고객이 지난주 왜 중단했는지는 은행이 모른다는 사실이 명시돼 있습니다. 그래서 AI는 "신용등급 상승으로 금리인하 신청 대상입니다. 지난주 작성하시던 신청서를 이어서 진행해 드릴까요?"라고 단정이 아닌 확인 질의를 던집니다. 고객이 동의하면 AI는 Control Layer에 신청서 사전 작성을 요청하고, Control Layer는 허용 목록·위임 범위·계좌 소유를 확인한 뒤 고객 확인을 거쳐 여신 시스템으로 전달하며, 여신 시스템은 그 시점의 실제 상태로 요건을 재검증합니다.
판단은 기존 프로그램이, 해석과 대화는 AI가, 연결은 Context Layer가, 강제는 Control Layer가, 확정은 원천 시스템이 맡습니다.
은행에서 Context가 더 중요한 이유
"정확성과 통제가 그렇게 중요하다면 지금처럼 프로그램으로 처리하는 편이 낫지 않은가"라는 반론이 가능합니다. 정형화된 업무에 한해서는 옳습니다. 그러나 AI가 필요한 영역은 애초에 프로그램으로 만들 수 없던 영역입니다. 비정형 질문의 해석, 분기로 만들 수 없는 롱테일 문의, 서류·상담 기록·규정을 읽고 종합하는 일. 이 일들은 지금 사람이 하고 있습니다. 비교 대상은 "AI 대 프로그램"이 아니라 "AI 대 사람"이며, 정확성과 통제의 중요성은 "AI를 쓰지 말자"가 아니라 "쓴다면 프로그램과 검증된 데이터에 묶어서 쓰자"의 근거입니다.
금융권에서 Context Layer가 유독 중요한 이유는 세 가지입니다.
- 오류 비용의 비대칭성: 커머스 추천이 틀리면 클릭 하나를 놓치지만, 금융 오안내는 금전 손실, 민원, 법적 분쟁으로 직결됩니다. 특히 개인화된 오답은 일반적 오답보다 신뢰를 훨씬 크게 훼손합니다.
- 규제의 입증 책임: 금융소비자보호법은 분쟁 시 충분히 설명했다는 사실을 판매자가 입증하도록 합니다.[17] 블랙박스 모델 자체로는 입증할 수 없으며, 질의 당시 AI에게 주입된 Context Layer의 시점별 맥락 스냅샷과 Control Layer의 응답 검증. 실행 감사 기록이 결합되어야 증명력을 갖습니다.
- 데이터 복합성: 수십 년 된 계정계, 업무별로 쪼개진 시스템, 가입 시점마다 달라지는 약관. 한 고객의 상황을 조합하는 난이도가 어느 산업보다 높고, 그만큼 연결 계층의 가치도 큽니다.
커머스의 Context가 전환을 늘리는 공격적 수단이라면, 뱅킹의 Context는 AI를 안전하게 쓰기 위한 방어적 기반입니다. 그런데 이 방어적 기반이 역설적으로 경쟁 무기가 됩니다. 고객은 자신의 상황을 말하고 곧바로 해결 받기를 기대하지만, 금융에서 AI는 통제된 범위 안에서만 허용됩니다. 자유와 통제라는 상충하는 요구를 동시에 충족시키는 것이 두 계층의 역할이며, 모든 금융사가 같은 규제를 받는 이상, 이 기반을 먼저 갖추는 쪽이 앞섭니다.
규제 지형: 두 계층은 컴플라이언스 요건과 맞닿아 있다
Context Layer와 Control Layer는 기술적 권장사항에 그치지 않고, 국내외 규제가 요구하는 요건을 시스템적으로 충족하는 수단입니다.
- 「인공지능 발전과 신뢰 기반 조성 등에 관한 기본법」(2026.1.22 시행): 고영향 AI 사업자에게 위험관리, 설명가능성 확보, 이용자 보호 및 인적 관리·감독, 관련 문서 보관 조치를 요구합니다.[18] Control Layer의 승인 게이트는 '인적 감독'을, Context Layer의 버전 관리와 출처 메타데이터는 '설명가능성'과 '문서화'를 담보하는 구현체가 됩니다.
- 금융 분야 AI 가이드라인 (보조수단성·책임성 원칙): AI는 의사결정의 보조수단이며 종국적 판단과 실행은 금융회사의 통제 아래 있어야 합니다.[19] "읽기 모델은 원장이 아니다", "확정은 원천 시스템이 한다"는 설계 원칙은 이 원칙과 직결됩니다.
- 금융보안원 AI 에이전트 보안 평가기준 (2026.10 발표, 2027 정식 적용): AI 레드티밍(Red Teaming) 점검 항목으로 프롬프트 인젝션을 통한 한도 초과 이체 등 에이전트 고유 위협에 대한 대응을 평가합니다.[20] 프롬프트가 아닌 Control Layer에서 행동을 강제하고 실행 직전 원천 재검증을 수행하는 구조가 이 위협에 대한 구조적 방어입니다.
데이터를 보는 관점의 전환
Context Layer가 가져오는 가장 근본적인 변화는 새 데이터 수집이 아니라 기존 데이터의 해석 방식 전환입니다. 은행은 로그를 MAU·이탈률 같은 집계 지표로, Exception을 오류율·장애 건수로 보았습니다. 운영자가 전체를 내려다보는 시각입니다. Context Layer는 같은 데이터를 한 고객의 시간 흐름 속 업무 상태로 읽습니다.
| 데이터 | 기존 시각 (운영자 중심 집계) | Context 시각 (고객 중심 시계열) | 확인된 것 / 미확인 |
|---|---|---|---|
| 화면 로그 | 화면별 이탈률 | 대출 신청 본인확인 후 서류 제출 단계에서 정지 | 단계 이탈은 확인 / 사유는 미확인 |
| Exception | 오류율, 장애 건수 | 10분 전 한도 초과 이체 실패 2회 발생 | 실패 사실·원인은 확인 |
| 검색어 | 인기 검색어 순위 | '해지', '중도상환수수료' 검색 이력 | 검색은 확인 / 해지 의사는 미확인 |
특히 Exception의 위상 변화가 중요합니다. 시스템 안정성 지표였던 오류 데이터가 고객이 지금 겪는 애로를 가장 직접적으로 보여주는 신호로 격상됩니다. 보고서 첫머리에서 챗봇에 필요했던 정보가 바로 이것입니다. 다만 저절로 되진 않습니다. 로그에 고객 식별자를 붙이고, 화면 로그와 백엔드 이벤트를 신청 식별자로 엮고, ERR_5021 같은 기술 코드를 "1일 한도 초과, 추가 인증 시 상향 가능"이라는 업무 의미로 번역하며, 노이즈 중 의미 있는 패턴만 맥락으로 승격시켜야 합니다.
그래서 가능해지는 일은 선제 대응("방금 이체가 두 번 실패하셨습니다. 한도를 올려드릴까요?"), 업무 이어가기("지난주 대출 신청은 서류 검증 오류로 멈춰 있습니다"), 이관 품질(맥락과 대화가 상담원에게 그대로 인계), 그리고 심사·내부통제의 검토 초안 작성입니다. 주목할 점은 이 대부분이 AI가 직접 실행하지 않는 업무라는 사실입니다. 규제상 AI의 거래 실행이 제한되는 현 단계에서 AI의 역할은 맥락을 정확히 이해하고 제시하는 것이며, 따라서 지금 단계에서 Context Layer는 AI 품질의 거의 전부입니다. 실행 권한은 저위험 행동부터 단계적으로 열릴 것이고, 그때 Control Layer가 본격적으로 역할을 합니다. 선제 대응은 고객이 감시받는다고 느끼지 않도록, 이미 겪은 문제를 확인된 사실만으로 해결하는 맥락에 한정하는 것이 안전합니다.
기술이 아니라 구조가 막고 있다
고객 맥락의 중요성은 은행도 오래전부터 알고 있었으나 이 수준에 도달한 곳은 드뭅니다. 고객의 최신 상태는 계정계에 있지만 계정계는 대량 조회를 감당하도록 설계되지 않았고, 대안인 정보계는 D-1 배치라 "방금 막힌 결제"를 모릅니다. 개인화된 답변일수록 은행의 책임 범위가 넓어지므로 리스크·준법 부서는 보수적일 수밖에 없습니다. 그리고 챗봇은 채널 부서, 데이터는 데이터 부서, 코어는 IT, 규정은 상품·준법 부서 소관이라 끌고 갈 주인이 없습니다. McKinsey는 이 상태를 좁은 실험에 머물러 확산하지 못하는 "파일럿 연옥(pilot purgatory)"이라 부르며, 데이터 기반과 운영 모델을 함께 재설계해야 한다고 지적하기도 했습니다.[21]
한 가지 이유가 더 있었습니다. LLM 이전의 시나리오형 챗봇은 맥락을 넣어줘도 활용할 능력이 없었습니다. 이 마지막 제약은 이제 풀렸습니다. 남은 것은 데이터 구조, 규제, 책임, 조직의 문제이며, Context Layer를 기술 프로젝트가 아니라 이 네 가지를 함께 푸는 아키텍처 합의 프로젝트로 정의해야 하는 이유입니다.
유스케이스 하나에서 시작하는 실행 전략
Context 모델 정의와 데이터 구조
유스케이스 단위로 업무 구조를 버전 관리되는 Context 모델로 정의하고, 비즈니스 데이터를 그 모델에 매핑한 뒤, 상황과 목적에 따라 필요한 맥락을 조립해 제공합니다.
"업무 구조"는 엔티티만을 뜻하지 않습니다. 고객·계약·상품 같은 엔티티, 신청→심사→승인 같은 프로세스 상태, 상태별 규칙과 가능한 행동까지 포함해야 매핑된 데이터가 "정보"가 아니라 "상황"이 됩니다. Gartner가 의미와 함께 운영 상태를 Context Layer의 구성요소로 꼽은 이유입니다.[7] 이 구조는 상품 출시와 규정 개정에 따라 변하므로 처음부터 버전 관리와 변경 승인 절차가 필요합니다.
기간계를 재구축할 필요는 없습니다. 계정계를 직접 조회하는 대신 변경 로그를 CDC(Change Data Capture)로 읽어 이벤트 스트림으로 흘려보내는 읽기 전용 계층을 얹어 실시간성을 확보합니다. 여러 글로벌 은행이 메인프레임 부하 분산을 위해 검증한 패턴입니다.[22] 다만 이 층은 읽기 모델이며, 확정은 원천 시스템의 몫입니다.
| 아키텍처 요소 | 기존 구조 | Context Layer에 필요한 구조 |
|---|---|---|
| 엔티티 구성 | 시스템·업무별 물리 테이블 | 비즈니스 엔티티 중심 (고객, 계약, 상품, 이벤트) |
| 동기화 주기 | D-1 배치 스냅샷 | 실시간 CDC 스트림 + 기준 시각 메타데이터 |
| 의미 | 컬럼명·코드값 | 정의·단위·기준 시점·출처가 부착된 데이터 |
| 규정 관리 | 문서 + 코드 내 if 문 | 룰 엔진과 연결된 실행 가능 규칙 + 근거 조항 |
| 문서 지식 | 파일 단위 PDF·HWP | 조항 단위 청크 + 상품·버전·시행일 메타데이터 |
| 권한 관리 | 화면/DB 테이블 단위 | 민감도·이용 목적·위임 토큰 기반 제어 |
| 이력 | 최신값 덮어쓰기 | 시점별 버전 보존 (당시 상태 재현 가능) |
범위 전략: 작은 공통 코어와 유스케이스별 확장
전사 데이터 표준화로 시작하면 끝나지 않습니다. 과거 EA와 전사 표준화 프로젝트가 같은 이유로 멈췄습니다. 반대로 유스케이스마다 독립된 체계를 만들면 상담 챗봇과 심사 보조가 "연체"를 서로 다르게 정의하는 순간 사일로가 되살아납니다.
현실적 해법은 공통 코어를 작게 유지하고 유스케이스별로 확장하는 것입니다. 코어에는 고객 식별, 계약·상품 기본, 공통 이벤트, 민감도·권한, 핵심 용어처럼 모든 유스케이스가 같은 의미로 써야 하는 최소한만 둡니다. 업무 고유의 상태·규칙·조립 방식은 각 도메인이 설계하고, 두 곳 이상에서 필요해진 개념만 코어로 승격합니다. 공유 가치가 증명된 것만 표준화하는 방식이며, 목표는 "전사 확대"가 아니라 "공통 코어가 점진적으로 두꺼워지는 것"입니다. Gartner도 포괄적 Context Layer를 한 번에 구축하지 말고, 가치가 높은 유스케이스에서 시작하라고 권고하며,[7] 도메인 주도 설계의 Bounded Context와 데이터 메시의 연합형 거버넌스가 같은 사고방식입니다.[23]
단계별 로드맵
[그림3] Context Layer 단계별 구축 로드맵 (출처: 저자 자체 제작)
- 0. 측정 : 상담원 이관 로그 분석, 맥락 부족 실패 비율 확인
- 1. 첫 유스케이스 : 엔티티·상태·의미·민감도 정의, 현업 합의
- 2. 최소 구현 : 목적 기반 접근 · 규칙 판단, 응답 검증 · 감사 기록
- 3. 평가와 확장 : 대표 질문 세트 평가, 두 번째 유스케이스 · 코어 승격
- 4. 실행 개방 : Control Layer 본격화, 저위험 행동부터
- 0단계 (실패 측정): 운영 중인 챗봇의 상담원 이관 로그를 샘플링해 실패 원인을 의도 파악 실패, 고객 맥락 부족, 규정·지식 부족, 실행 권한 부족으로 분류합니다. "고객 맥락이 있었다면 해결됐을" 비율이 가장 현실적인 투자 근거입니다. 봉쇄율만 보면 틀린 답으로 끝난 대화도 해결로 집계되므로 재문의율을 반드시 함께 계측합니다.
- 1단계 (업무 구조 합의): 가장 오래 걸리는 것은 기술이 아닙니다. "서류 검증 오류"가 정확히 무엇이고 어느 시스템이 그 상태를 확정하는지, "신청 미완료"와 "신청 취소"는 어떻게 다른지를 업무 오너와 IT가 합의하는 일입니다. 이 작업의 일정과 담당 조직을 먼저 확보해야 합니다.
- 2단계 (최소 구현): 조회·안내 중심이라면 목적 기반 접근, 규칙 판단, 응답 검증, 감사 기록이면 충분합니다. 각 맥락 응답에는 대상, 목적, 기준 시각, 출처, 권한, 미확인 항목이 계약(contract)처럼 고정된 형식으로 포함되어야 다음 단계의 평가가 가능합니다.
- 3단계 (종합 평가): 이벤트 누락·지연·중복, 만료된 상품 조건, 사유를 알 수 없는 중단 같은 불편한 사례를 포함한 질문 세트로 평가합니다. 지표는 업무 완료율, 재접촉률, 근거 일치율, 상태 최신성, 권한 위반 차단율을 함께 보며, 컨텍스트마다 업무 오너·갱신 주기·유효 기간을 지정해야 품질이 유지됩니다. NIST AI RMF가 Govern·Map·Measure·Manage를 생애주기 전반의 반복 기능으로 제시하는 것과 같은 취지입니다.[24]
- 4단계 (실행 개방): 기존 시스템은 최대한 건드리지 않습니다. AI 채널 식별 코드와 위임 토큰 추가, AI 요청 ID와 거래 로그의 연결, 그리고 AI가 기존 API를 직접 호출하지 못하도록 하는 접근 차단 수준으로만 보완합니다. 금전 이동이나 고객의 권리·조건을 바꾸는 행위는 멱등 처리, 재검증, 보상 절차, 승인 단계를 갖춘 API에만 엽니다.
피해야 할 다섯 가지 안티 패턴
- 기존 조회 API에 MCP만 씌우고 Context Layer라 부르는 것: 의미 구조가 결여된 단순 포장입니다.
- 유스케이스 없이 전사 플랫폼부터 구축하는 것: 활용되지 않는 인프라로 전락합니다.
- 추정을 사실처럼 맥락화하는 것: "화면을 오래 봤으니 원한다"는 해석이 섞이면 AI는 고객의 의도를 자신 있게 단정합니다.
- 읽기 모델을 원장으로 간주하는 것: 10분 전 이벤트로 조립한 상태를 믿고 실행하면 이중 처리나 만료된 조건의 거래로 이어집니다.
- 프롬프트로 행동을 강제하려는 것: "규정을 지켜라"는 통제가 아니라 권고입니다. 강제는 Control Layer의 몫입니다.
맺으며: 은행이 자신의 업무를 다시 쓰는 일
처음의 금요일 저녁으로 돌아가 보면, 두 계층을 갖춘 은행에서는 같은 상황에서 다음과 같은 응답을 고객에게 던집니다.
"방금 300만 원 이체가 1일 이체 한도(200만 원) 초과로 두 번 실패했습니다. 추가 인증을 거치면 즉시 한도 상향이 가능합니다. 지금 진행하시겠습니까?"
모델은 같을 수 있습니다. 달라진 것은 AI가 무엇을 알고, 무엇을 모르며, 어디까지 실행할 수 있는지가 명확했다는 점뿐입니다. 이 한 문장 뒤에는 계정계에서 흘러나온 이벤트, 의미가 부여된 오류 코드, 실행 가능한 한도 규칙, 목적에 맞게 걸러진 권한, 그리고 실행 직전의 검증 게이트가 있습니다.
은행이 먼저 답해야 할 질문은 "AI가 무엇을 할 수 있는가"가 아니라 "우리는 AI에게 우리 업무를 설명할 수 있는가"입니다. Context Layer는 AI 입장에서는 잘 정의된 프롬프트지만, 은행 입장에서는 자신의 업무 체계를 기계 가독형 언어로 다시 쓰는 일입니다. 그래서 이것이 Agentic Banking의 첫걸음이 되며, 플랫폼이 아니라 가치가 분명한 유스케이스 하나와 함께 시작해야 합니다.
모델은 라이선스로 확보할 수 있습니다. 그러나 맥락과 거버넌스는 오직 은행만이 구축할 수 있는 자산입니다.
References
FAQ
-
에이전틱 뱅킹(Agentic Banking)에서 모델의 지능보다 '맥락(Context)'이 더 중요한 이유는 무엇인가요?
LLM의 기본 성능이 아무리 뛰어나도 고객의 구체적인 상황이나 기업 내부의 암묵적인 업무 기준을 알지 못하면 정확한 응답이 불가능하기 때문입니다. 따라서 Context Layer를 통해 파편화된 지식을 기계 판독형으로 구조화해야만 환각 현상을 억제하고 진정한 초개인화 서비스를 구현할 수 있습니다.
-
Context Layer는 구체적으로 어떤 역할을 수행하며 어떤 가치를 제공하나요?
고객의 상황, 기업 내부의 업무 해석 기준 등 흩어져 있는 정보를 AI가 이해할 수 있는 형태로 구조화하는 역할을 합니다. 이를 통해 AI가 일반적인 답변을 넘어 실제 업무 맥락에 맞는 정확한 판단을 내리게 함으로써, 서비스의 완성도를 높이고 사용자 경험을 혁신하는 가치를 제공합니다.
-
금융 AI 환경에서 Control Layer가 반드시 필요한 이유는 무엇인가요?
AI 에이전트는 결과가 가변적인 비결정적 특성을 가지고 있어, 금융 사고의 리스크가 존재하기 때문입니다. Control Layer는 AI의 요청을 최종 검증하고 권한 관리와 규제 준수(Compliance)를 강제하는 게이트웨이 역할을 수행하여, 안전하고 신뢰할 수 있는 금융 실행 환경을 보장합니다.
-
Context Layer와 Control Layer를 구축하는 것이 금융사에 어떤 전략적 차별점을 제공하나요?
범용 LLM 모델은 누구나 사용할 수 있지만, 기업 내부의 암묵지를 디지털 자산화하여 Context와 Control 계층에 녹여낸 것은 오직 해당 금융사만이 가진 고유한 경쟁력이 되기 때문입니다. 이는 단순한 기술 도입을 넘어 업무 지식을 자산화함으로써 독보적인 업무 정확도와 보안성을 확보하는 전략적 우위를 제공합니다.
※ 본 리포트는 리서치 및 본문 편집 과정에서 생성형 AI(Claude, Gemini)를 활용했습니다.
