Context Lab

지난 [원칙 2]와 [원칙 3]에서, 우리는 AI Agent가 데이터를 '요청(Pull)'하는 API 게이트웨이와 데이터를 '수신(Push)'하는 **EDA(이벤트 기반 아키텍처)**를 이야기했습니다. 이제 우리의 AI는 시스템의 데이터에 '접근'할 수 있게 되었습니다. 하지만 바로 여기서, 우리는 더 복잡하고 근본적인 문제에 부딪힙니다. AI가 '초개인화된 맞춤형 홈'을 고객에게 제공해야 한다고 상상해 봅시다. 이 AI는 다음 정보를 '하나로 합쳐서' 봐야 합니다.[계정계 DB] 고객의 현재 잔액[AWS] 지갑의 포인트 잔액[로그 서버] 고객의 최근 앱 접속 시간[EDA Stream] 방금 발생한 '카드 결제' 이벤트AI Agent가 이 모든 시스템의 IP 주소, ID/PW, DB 스키마, API 명세..

지난 [원칙 2]에서 우리는 AI Agent가 '명령'하거나 '조회'할 때 API 게이트웨이라는 '은행 창구'를 이용해야 한다고 말했습니다. 이것은 AI가 '능동적으로(Actively)' 데이터를 가져오는(Pull) 방식입니다. 여기서 한 가지 중요한 질문이 생깁니다. AI가 요청하지 않은, "지금 이 순간" 시스템에서 발생한 일을 AI는 어떻게 알 수 있을까요? 예를 들어, '고객이 방금 이체를 완료'했다는 사실이나 '이상한 로그인 시도'가 발생했다는 것을 AI가 어떻게 즉시 인지할 수 있을까요? 최악의 안티-패턴: 'AI의 폴링 지옥(Polling Hell)'만약 우리에게 '원칙 2(API 게이트웨이)'만 있다면, AI가 실시간 데이터를 얻는 유일한 방법은 1초에 한 번씩 API 게이트웨이를 **'폴..

'finaitech' 5대 원칙의 첫 번째 글에서, 우리는 **"똑똑한 AI보다 통제 가능한 AI가 먼저다"**라는 철학을 공유했습니다. 그렇다면 이 '통제'를 기술적으로 구현하는 가장 핵심적인 아키텍처는 무엇일까요? 이 질문에 답하기 위해, 먼저 '최악의 아키텍처(Anti-Pattern)'부터 살펴보겠습니다. 그것은 바로 **"AI Agent에게 은행 핵심 원장(DB)의 Connection String(접속 정보)을 주는 것"**입니다. 이는 '유능한 슈퍼 인턴(AI Agent)'에게 은행 **'금고의 마스터키'**를 주고 퇴근하는 것과 같습니다. AI가 아무리 똑똑하더라도, 이 아키텍처는 단 하나의 실수나 해킹으로도 은행 전체를 마비시킬 수 있는 재앙의 지름길입니다. AI가 DB에 직접 접근할 때 벌..

이 카테고리는 모델을 '금융 현장의 견고한 서비스(Production)'로 안전하게 이관하고 운영하는 전 과정을 함께 고민하는 것입니다. AI의 '뇌'를 설계하는 것만큼이나 중요한, AI의 '심장과 척추'를 설계하는 영역이라고 생각합니다.AI 플랫폼은 기존의 MSA를 위한 PaaS(서비스형 플랫폼)와는 조금 다른, 새로운 숙제들을 우리에게 줍니다.GPU 자원: "GPU 같은 비싸고 희소한 자원을 어떻게 여러 팀이 효율적으로 나눠 쓰고 격리할 것인가?"모델 배포: "코드가 아닌, 수 GB에 달하는 'AI 모델'과 '데이터'를 어떻게 버전 관리하고 무중단 배포할 것인가?"실시간 서빙: "1만 명이 동시에 AI 뱅커를 호출할 때, 어떻게 1초 안에 응답하는 'AI 서빙' 아키텍처를 만들 것인가?"보안: "이 ..

'탄력성'과 '장애 격리'라는 PaaS의 기본 원칙은 금융권의 특수한 환경과 엄격한 법적 규제를 만났을 때, 다른 산업과는 완전히 다른 차원의 설계 지침이 추가되어야 합니다. 일반 기업에서 'Best Practice(권장 사항)'인 것이, 금융권에서는 **'Mandatory Requirement(강제 사항)'**가 됩니다. 금융권 PaaS 설계 시, 기존 원칙에 반드시 추가되어야 할 5가지 사항을 정리합니다. 1. (법률) '망분리' 규제 준수를 위한 아키텍처일반 기업의 '장애 격리'는 K8s NetworkPolicy 같은 논리적 격리로 충분할 수 있습니다. 하지만 금융권은 전자금융감독규정에 따른 '망분리'라는 강력한 법적 요구사항이 있습니다.추가 설계 지침: PaaS 플랫폼 자체를 **'채널계(DMZ/..

Resilient PaaS(Platform as a Service) 설계의 두 가지 핵심 목표는 **'탄력성'**과 **'장애 격리'**입니다. 탄력성(Elasticity): 수요에 따라 플랫폼이 자동으로 확장/축소되어, 리소스를 낭비하지 않으면서도 안정적인 서비스를 제공하는 능력입니다. 장애 격리(Fault Isolation): 플랫폼의 한 구성 요소나, 그 위에서 실행되는 특정 애플리케이션의 장애가 다른 애플리케이션이나 플랫폼 전체로 전파(Cascading Failure)되는 것을 막는 능력입니다. 이 두 가지 목표를 달성하기 위한 7가지 설계 지침을 정리해 봅니다. 공통 기반 (The Foundation)탄력성과 장애 격리 모두를 위한 가장 기본적인 전제 조건입니다. 1. 컨테이너 및 쿠버네티스(..

'finaitech' 선언문에서 우리는 5가지 원칙을 이야기했습니다. 오늘 그 첫 번째 원칙인 **"똑똑한 AI보다 통제 가능한 AI가 먼저다"**에 대해 깊이 파고 들어가 보겠습니다. AI Agent를 도입한다고 할 때, 우리는 종종 '얼마나 똑똑한가'에만 집중합니다. "이 AI가 얼마나 사람처럼 말하는가?", "얼마나 복잡한 업무를 처리하는가?" 같은 질문이 앞섭니다. 하지만 금융 아키텍트의 관점은 달라야 합니다.'슈퍼 인턴'에게 '대표이사 카드'를 주는 격새로운 AI Agent를 도입하는 것을, **'엄청나게 유능한 신입 인턴'**을 채용하는 것에 비유해 봅시다. 이 인턴(AI-Agent)은 24시간 일하고, 지치지 않으며, 수백만 건의 데이터를 순식간에 분석합니다. 정말 '똑똑'합니다.그런데 이 ..

'AI Agent'가 금융 산업의 큰 화두로 떠오르고 있습니다. 많은 기업이 'AI 은행원'이나 '업무 자동화 챗봇' 도입을 통해 혁신을 모색하고 있습니다. 하지만 AI Agent는 단순한 '툴'을 넘어, 스스로 판단하고 시스템을 호출하며, 때로는 거래를 실행하는 **'자율적 행위자(Autonomous Actor)'**로 기능합니다. 단순한 '기술 도입'이 아닌 **'아키텍처의 근본적인 패러다임 전환'**으로 바라봐야 할 것 같습니다. 하지만 금융권에서 AI Agent에게 '지능'을 부여하는 것만큼이나 중요한 것은 '신뢰'와 '통제'의 기반을 마련하는 것입니다. 이는 C-Level을 포함한 우리 모두가 함께 고민해야 할 리스크 관리의 핵심입니다. 'finaitech' 블로그는 이 전환을 준비하면서 알게된..