은행에서 AI를 private하게 사용하는 방법 (feat. Azure)

안녕하세요. 저는 보안기술아키텍처팀에서 카카오뱅크가 늘 안전할 수 있도록 보안 관점의 아키텍처 검토, 침해 대응, Endpoint 보안 등의 업무를 수행하고 있는 Levi입니다. 기존에는 클라우드보안팀 소속이었는데요. 해당 팀에서는 ‘클라우드’라는 범위에 대해 전반적인 보안 업무를 경험하고, 지금은 온프레미스까지 영역을 확장하여 업무를 수행하고 있습니다.

최근 기술 분야의 가장 큰 화두는 누가 뭐라 해도 바로 AI일 것입니다. 뉴스를 보아도, 유튜브를 보아도 ‘AI’라는 키워드가 없다면 섭섭할 지경이죠. 우리가 눈치채지 못할 만큼 AI는 이미 우리 삶에 깊숙이 스며들어 있습니다. 우리가 사용하고 있는 휴대폰과 PC의 다양한 앱들에 이미 AI가 적용되어 있고, 문제가 발생하여 고객센터에 연락해도 AI가 응답을 해주며, 질문을 어떻게 해야 할지 잘 모를 때 AI에게 대충 질문을 던져도 A부터 Z까지 아주 친절하게 답변을 해줍니다.

이처럼 AI가 세상을 가장 빠르게 변화시키는 요소 중 하나로 자리 잡으면서, 많은 기업들이 회사 내부 시스템과 서비스에 AI를 도입하여 여러 측면에서 활용해 보는 고민을 하고 계실 텐데요. 특히 금융업과 같은 규제 산업에서는 ‘전자금융감독규정’을 준수해야 하기 때문에, AI 도입에 있어서 허들이 존재하는 것도 사실입니다. 이러한 상황에서 카카오뱅크도 “어떻게 하면 규제를 준수하면서 안전하게 AI를 사용할 수 있을지”에 대해 깊이 고민해왔고, 그 고민의 결과를 이 글에 담아 보았습니다. 그럼, 이제 출발해 볼까요?

도입 배경

잠시 그전에, 클라우드 솔루션 중 Azure를 콕 집어 도입하게 된 히스토리를 간단하게 말씀드려야 할 것 같아요.

사실 Azure는 카카오뱅크에 AI를 위해 도입된 것은 아니었습니다. 오히려 그 이전부터 존재했었는데요. 다들 기억하시겠지만, 코로나 19 사태로 인해 많은 사람들이 같은 공간에서 업무를 할 수 없게 되면서 기업에서는 서둘러 임시 재택근무를 허용했습니다. 카카오뱅크에서도 재택근무를 시작하면서 원격 근무를 위한 VDI(Virtual Desktop Infrastructure) 리소스 수요가 급증하게 되었습니다.

더욱이 코로나19로 인해 공장 가동 중단까지 겹쳐 하드웨어 장비 증설도 어려움을 겪었습니다. 이런 상황에서도 재택근무를 지속할 수 있도록 빠르게 대안을 마련해야 했습니다. 여러 대응방안을 검토하던 중 Azure를 통해 VDI를 클라우드 상에 배포할 수 있다는 사실을 확인했습니다. 그렇게 내부적으로 PoC를 진행 후 Azure VDI를 도입하게 되었습니다. 아, 조금 더 정확히 말씀드리자면 카카오뱅크의 On-Premise VDI 서버와 Azure를 연동하여 On-Premise의 VDI 하드웨어 장비 쪽에 배포하는 것뿐만 아니라 Azure 상에서도 Azure의 리소스를 활용하여 VDI를 배포할 수 있게 아키텍처를 구축하게 되었습니다. 하지만 이 내용은 이번 글의 메인 주제는 아니니 이 아키텍처에 대한 소개는 다음 기회로 미루도록 하겠습니다.

우선 클라우드를 도입하기 전에, 회사에서 저와 비슷한 업무를 담당하고 계신 분들이라면 아시겠지만, 고객의 소중한 자산을 다루는 금융 회사에서 클라우드서비스를 도입하기 위해서는 특정 절차들을 통과해야 하는데요. 해당 절차는 아래 [그림 1]과 같습니다.

보안 관점에서 중점적으로 검토해야 할 단계는 ‘클라우드 서비스 제공자 평가(제4장)‘의 안전성 평가와 ‘업무 연속성 계획 및 안전성 확보조치 방안 수립(제5장)‘의 안전성확보조치 방안 마련입니다. 간단히 설명드리자면, 금융 회사가 클라우드를 안전하게 사용하기 위해서는 ‘클라우드 서비스 제공자‘와 ‘클라우드 서비스 이용자’ 두 가지 관점에서 점검을 실시한다고 이해하시면 됩니다.

AI 서비스를 도입하며 고려해야 할 중요한 요소 중 하나는 사내 정보를 학습 데이터로 활용하는지 여부입니다. 만약 개인이 질의하며 사용한 사내 데이터를 모델 학습에 사용한다면, 그 모델에 질의하는 모든 사용자가 사실상 사내 데이터에 간접적으로 접근할 수 있게 되어 정보 보안에 위협이 될 수 있습니다. 예를 들어, Azure OpenAI는 ‘고객의 데이터를 학습 목적으로 사용하지 않는다’고 공식 문서에서 명시하고 있습니다. 이처럼 데이터 처리 방식을 명확히 확인하는 것이 중요합니다.

그럼 간단하게 도입 배경을 설명드렸으니, 이제 본격적으로 Azure로 아키텍처를 어떻게 구성했는지 한 번 살펴보시죠.

Azure OpenAI 아키텍처 톺아보기

1. Azure의 기본: Entra ID, Tenant, 그리고 Subscription

많은 분들이 클라우드에 처음 접근하실 때 AWS를 선택하는 경우가 많습니다. 이는 AWS가 클라우드 서비스 제공업체(CSP) 시장에서 선두 주자이며, 경쟁사에 비해 다양한 서비스를 제공하기 때문일 것입니다. 이로 인해 사용자들은 AWS에 익숙해지게 되고, 나중에 Azure와 같은 다른 클라우드 서비스를 사용하게 되면 그 구조의 차이부터 인지하게 됩니다.

AWS에서는 IAM(Identity and Access Management)이 각 Account 내에 통합되어 있어 간편하게 접근 관리를 할 수 있습니다. 반면, Azure는 IAM 기능을 Entra ID(구 Active Directory, AD) 형태로 제공하며, 이는 IdP(Identity Provider) 형태로 Tenant에 종속됩니다. 한 Account에는 하나의 Tenant가 할당되며, 해당 Tenant 내에서 Entra ID가 생성됩니다.

Azure에서 Tenant는 다수의 Subscription을 생성할 수 있는 환경을 제공하며, 이 Subscription은 ‘AWS에서의 Account’과 유사한 역할을 합니다. Subscription은 비용 부과의 최소 단위이면서 특정 리소스들을 배포하고 관리할 수 있는 수단입니다. AWS와 비교할 때, AWS는 여러 Root Account를 Management Group 아래에 OU로 묶어 관리할 수 있지만, Azure에서는 단 하나의 Root Account만 존재합니다.

다시 Azure로 돌아와서 살펴보겠습니다. Azure에서는 각각의 Subscription들을 Management Group으로 관리할 수 있으며, Subscription 하위에 생성되는 리소스들은 Resource Group으로 논리적으로 묶어 관리할 수 있습니다. 이러한 Resource Group은 서비스별 리소스를 효율적으로 관리하고, 필요시 그룹 단위로 삭제함으로써 운영을 용이하게 합니다. 이 Resource Group은 AWS에 비해 Azure가 리소스 관리 측면에서 내세울 수 있는 장점을 가진 서비스입니다.

2. Azure Subscription 아키텍처

질문을 하나 드려보겠습니다. 여러분이 클라우드를 사내에 도입하는 담당자라면, 초기에 가장 중요하게 고려해야 할 요소는 무엇일까요?

아마도 클라우드를 잘 운영하기 위해선 뼈대를 잘 구축하는 것이 가장 핵심적이다 보니, 그 구조(Architecture)에 대해 고민을 하시게 될 것 같은데요. 초기 단계에서 적절한 아키텍처를 잘 구축해두면, 나중에 발생할 수 있는 큰 규모의 변경사항을 방지하고, 서비스 확장이 보다 쉽게 이루어질 수 있습니다. 이렇게 초기에 투자한 노력은 위기 상황에서 유연한 대응을 가능하게 하며, 비용을 효율적으로 관리할 뿐만 아니라, 보안 규제를 준수하고 보안 수준을 높이는 데에도 큰 도움을 줍니다.

다만, 이러한 아키텍처를 잘 구축하기 위해서는 어찌 보면 해당 클라우드 서비스에 대한 경험이 필수적인데요. 클라우드를 처음 접하는 담당자 분들께서는 경험이 없다 보니 클라우드 아키텍처를 어떻게 가져가면 좋을지에 대한 고민이 많으실 거라고 생각합니다. 이에 대한 니즈를 고려하여 대부분의 클라우드 서비스 제공 업체에서는 ‘Landing Zone‘을 설정해 둡니다. Landing Zone의 어원은 비행기나 헬기의 착륙 장소에서 가져왔다고 하는데요. 이를 클라우드 관점에서 해석해 본다면, “클라우드를 처음 접하는 기업들에게 안정적인 초기 클라우드 환경을 제공해 줄 수 있는 일종의 제안 아키텍처”라고 이해할 수 있겠습니다.

이러한 Landing Zone을 참고하여 아키텍처를 고민하기 시작했고, Multi-Subscription 체계는 다음과 같이 운영하기로 결정했습니다.

Multi-Subscription 체계에서 각 분리된 망별 환경은 별도의 Root Account를 가지며, 이는 Root Tenant 역할을 수행합니다. 해당 Account에서 관리 그룹(Management Group)을 생성하고 용도 별로 OU를 구분합니다.

카카오뱅크는 클라우드를 3가지 주요 OU로 구분하는데요. 운영을 위한 핵심 리소스들이 배포될 Core OU와 실제 대고객, 내부 서비스를 위해 개발 프로세스에 활용될 개발, 테스트, 운영을 각각의 Subscription으로 분리한 Service OU로 묶었습니다. 여기까지가 일반적인 구조이고, 초기에 VDI 용도로 Azure를 도입했기에 VDI 전용 Subscription을 추가로 구성하기로 결정했습니다.

각각의 Subscription 용도를 간단하게 설명드리자면 다음과 같습니다.

3. Azure 네트워크 아키텍처

이제 Azure의 네트워크 아키텍처에 대해 어떻게 고민했는지를 말씀드리려고 합니다. Azure를 이용한 서비스 제공에서 네트워크 아키텍처는 큰 중요성을 가지는데요. 불필요한 네트워크 홉을 최소화하면서 서비스 속도와 운영 안전성을 보장해야 하기 때문입니다.

위 그림은 Azure Landing Zone에서 언급하고 있는 Hub-and-Spoke 네트워크 아키텍처입니다. ‘Hub-and-Spoke’란 자전거 바퀴살(Spoke)이 중심축(Hub)으로 모이는 것처럼 네트워크 트래픽이 중심지로 들어온 뒤 다시 개별 영역으로 보내지는 것을 의미합니다. 쉽게 설명하자면, Azure로 들어오는 트래픽은 무조건 Hub 네트워크로 들어간 다음 최종 목적지에 해당하는 어느 하나의 Spoke 네트워크로 가게 됩니다. 이 아키텍처의 단점은 최종 목적지까지의 네트워크 홉 증가이지만, 초기 단계인 Hub 네트워크에서 방화벽 및 배스천 호스트를 통한 외부 위협 대응이 가능하다는 장점을 가집니다.

카카오뱅크에서는 위에서 잠시 언급했던 Subscription 중 Connectivity Subscription을 Hub 네트워크 용으로 사용하고 있고, 해당 Subscription에는 Hub Virtual 네트워크가 생성되어 있습니다. 아래 그림은 카카오뱅크에서 운영 중인 Azure 전반의 아키텍처를 한땀 한땀 그려본 것 입니다.

트래픽 플로우(Traffic Flow)를 설명드리자면 다음과 같습니다.

위 그림을 주의 깊게 보셨다면 아마 의문스러운 점이 있을 수 있는데요. 맞습니다! 🙌 카카오뱅크 Azure에서는 외부와의 트래픽을 주고받을 수 있는 경로가 없습니다. 카카오뱅크에서는 Azure를 VDI와 OpenAI 용도로만 사용하다 보니 외부로 서비스를 제공하는 것은 없어 외부와의 연결 경로는 없게 구성하여 안전성을 도모하였고 모든 트래픽들은 카카오뱅크 On-Premise를 통하도록 구성되어 있습니다.

카카오뱅크 On-Premise과 Azure는 Express Route Circuit을 통해 연결됩니다. 연결된 트래픽은 Virtual Network Gateway를 통해 Azure Virtual Network로 이동하게 됩니다. 이 Virtual Network에서 구성된 리소스들이 해당 트래픽을 처리하게 됩니다. 여기서 Virtual Network Gateway는 서브넷(Subnet) Gateway를 할당해야 하며, 최소 /27 이상의 서브넷을 필요로 합니다. 이름 또한 회사의 네이밍 룰에 맞게 변경하게 된다면, 트래픽이 원활하게 경로를 찾을 수 없는 일이 발생할 수 있으므로 해당 서브넷의 이름은 변경하지 않는 것이 좋습니다.

트래픽이 Azure로 가장 먼저 들어오는 영역이기 때문에 DNS Private Resolver 또한 Connectivity Subscription에 구현하였습니다. Azure의 경우, DNS Inbound 서브넷과 Outbound 서브넷을 별도로 할당해야 하므로 Connectivity Subscription에 만들 VNet(Virtual Network)의 대역을 조금 넉넉하게 할당하는 것이 좋습니다. 또한 다른 Subscription의 VNet과의 통신은 Peering을 맺어서 진행했습니다.

4. Azure OpenAI 아키텍처

Azure의 기본적인 개념에 대해 앞서 간단히 설명드렸으니, 이제 본격적으로 Azure OpenAI 아키텍처에 대해 말씀드리겠습니다. 우선 Azure OpenAI는 현재 한국 리전에서 서빙하고 있지 않습니다. (단, PTU라는 별도 계약을 통한 서비스는 제공하고 있음)

이에 따라, Azure OpenAI의 주요 서비스 리전인 East US 및 East US2를 사용하게 되었습니다. 그 결과, Connectivity Subscription의 East US 리전에 VNet과 API Management Service를 구축하였습니다. 해당 서비스는 Full Prompt Logging을 위해 생성했는데, 자세한 내용은 뒷부분에서 다시 설명드리도록 하겠습니다. 참고로, OpenAI는 리전별로 다양한 모델을 제공하기 때문에, 사용하고자 하는 모델이 어느 리전에서 이용 가능한지 미리 확인한 후 서비스를 이용해야 합니다.

위의 아키텍처 그림에는 개발계 Subscription에만 OpenAI 인스턴스가 표시되어 있으나, 실제로는 운영계 Subscription에도 운영용 인스턴스가 구성되어 있습니다. 이와 같이 OpenAI 인스턴스는 개발 및 운영용으로 구분하여 설계되었고, 모든 인스턴스는 외부의 접근을 제한하며, 오직 Private Endpoint를 통해서만 지정된 VNet과 Endpoint로만 접근이 가능하도록 구성하였습니다. 🪄

또한, 해당 Private Endpoint의 DNS는 Connectivity Subscription 내의 Private DNS에 등록되어 있습니다. 이를 통해 트래픽이 도착할 때 DNS 해석을 통해 해당 OpenAI의 Private Endpoint로 트래픽을 유도할 수 있게 구성되어 있습니다.

서비스별로 인스턴스를 분리하려는 목표에도 불구하고, Azure의 가용성 제한으로 인해 한 리전 당 최대 3개의 인스턴스만을 운영할 수 있습니다. 결과적으로, API Management에서 API 및 URL 접미사(suffix)를 구분해 서비스별로 관리할 수 있도록 조치했습니다.

API Management Service는 초기에 언급한 Full Prompt Logging을 가능하게 하기 위해 구축되었습니다. Azure OpenAI Service의 기본 진단 설정으로는 Full Prompt Logging과 토큰 사용량 모니터링이 불가능합니다. 별도로 titoken 등을 구축하여 계산은 할 수 있으나, 리소스가 추가로 드는 점을 고려한다면 API management Service를 구축하는 것이 여러모로 이점이 많다고 판단했습니다. 참고로, 아래 표에서 ‘이 솔루션’은 참고 문서에 존재하는 아키텍처로, 저 또한 유사한 아키텍처를 구현하여 결과적으로 Full Prompt Logging이 가능했다란 것을 이야기드리고자 가져왔습니다.

Azure OpenAI와 API Management Service를 연동하기 위해서는 다음과 같은 작업이 필요합니다.

OpenAI Instance Key 값은 OpenAI 계정의 API Keys 페이지에서 확인할 수 있습니다. 해당 키를 이용하면 Azure API Management Service에서 특정 OpenAI Instance로 질의할 수 있는데요. 해당 키를 안전하게 보호하기 위해 Azure Key Vault를 사용합니다. Azure Key Vault는 API Management Service와 동일한 리전에서 생성하시면 됩니다.

생성한 Azure Key Vault에서 키 자격 증명 모음으로 들어가 생성/가져오기를 클릭하여 전 단계에서 확인했던 OpenAI Instance의 Key를 저장합니다.

이후 API Management Service의 명명된 값 섹션으로 이동하여, 저장된 Key Vault 키 값을 추가합니다. 추가 후, API Management Service가 이 키에 접근하여 읽을 수 있도록 적절한 역할을 할당합니다.

이제 API Management Service에서 API를 만들어야 합니다. API는 Frontend와 Backend로 나뉘며, 우선 Backend 부분을 구성해 보겠습니다. 먼저 API Management Service > Backends를 클릭하신 후 아래 그림과 같이 구성합니다.

Runtime URL에는 위에서 만들었던 OpenAI Instance의 Private Endpoint URL을 넣고, 헤더의 api-key에는 Azure Key Vault에서 보관했던 OpenAI Instance의 Key를 매칭해 주면 됩니다.

그다음, API Management Service > API > ... > import > OpenAPI 을 선택한 다음, Azure 공식 github 제공되는 Completions OpenAPI 링크를 넣으면 OpenAI와 관련된 API 포맷이 생성됩니다. 생성된 API를 클릭한 다음, All operations > Inbound processing에서 Add Policy를 클릭하여 아래의 스크린 샷 이미지와 같이 앞서 생성했던 Backend API 이름을 넣어줍니다.

이렇게 하면 우선 API Management Service를 통한 OpenAI 질의 인프라는 구성이 되었습니다. 참고로, API Management Service에 대해서도 Private Endpoint를 생성하셔서 [해당 Endpoint + OpenAI의 API 형태]로 도메인을 구성하셔서 호출하시면 됩니다.

마지막으로는, 진단 설정 구성을 통해 Full Prompt Logging을 할 수 있게 해보겠습니다. 진단 설정이란 Azure에서의 각 리소스 별 로그를 구집할 수 있게 해주는 서비스인데요. 자세한 내용은 해당 챕터 바로 뒤에 이어지는 <Azure Log Pipeline 구축하기>에서 설명드리겠습니다.

위 그림처럼 API Management Service > 진단 설정에서 필요한 로그를 선택한 후, 해당 로그들을 필요에 맞게 Log Analytics, Storage, Event hub 등에 전송하시면 됩니다.

다만, 여기서 한 가지 주의할 점은 한국 리전에 있는 Event Hubs를 이용하여 회사 내부로 로그를 전송하고 있었다면, 다른 리전에서 생성된 API Management Service의 로그는 한국 리전의 Event Hub로 직접 연결할 수 없다는 점입니다. API Management Service의 리소스별 로그들을 한국 리전의 Event Hub로 전송하기 위해서는 (1) API Management Service를 한국 리전에 생성하여 이용하거나, (2) Log Analytics의 내보내기 기능을 이용한다면 가능합니다.

카카오뱅크는 2번 방식을 채택하여 로그를 수집하고 있는데요. 이렇게 구성한 뒤 발생하는 로그들을 보면, 다음과 같이 기존에 OpenAI Instance의 진단 설정만으로는 알 수 없던 토큰 사용량, 질문 내용, 응답 내용이 전부 로깅되는 것을 확인할 수 있습니다.

응답이 분리되어 오는 현상은 Stream 모드를 활성화했기 때문입니다. 모델의 급이 높아질수록 아무래도 응답속도가 지연되는 이슈가 있다 보니, 사용자에게 응답을 끝까지 기다리다가 보여주는 형태는 자칫하면 응답이 되지 않는 것으로 인식될 수 있습니다. 이러한 점을 고려하여 Stream 모드를 활성화시켜서 사용 중입니다. Stream 모드 활성화 시, 질문과 응답에 소모된 토큰 양을 로그를 통해 확인하는 것은 불가능해집니다. 따라서 Titoken 같은 별도의 토큰 사용 오픈소스 혹은 추가 개발을 통해 토큰 사용량을 계산하여 확인해야 합니다.

Azure Log Pipeline 구축하기

본격적인 Azure Log Pipeline 구축 경험을 시작하기 전에, 먼저 Azure의 Log의 3가지 종류에 대해 간단하게 설명드리려고 합니다. Azure의 Log는 크게 Activity Log, Diagnostic Setting(진단 설정), Entra ID Log로 나누어 볼 수 있습니다.

Entra ID Log는 기존의 Diagnostic Setting 범주에 포함되지만, 별도의 IdP 서비스로서 IAM을 담당하기 때문에 중요도와 계층 측면에서 별도로 분류합니다. 각각의 Diagnostic Setting은 Azure 내 콘솔에서는 진단 설정(Diagnostic Setting) 메뉴에서 설정할 수 있으며, 항목은 각 리소스별로 상이합니다.

[그림 8]에서는 API Management Service의 진단 설정 화면을 확인할 수 있습니다. 그림에 모두 표시되진 않았지만, 여기서 해당 로그들을 Log Analytics, 스토리지 계정, 이벤트 허브, 파트너 솔루션 등으로 전송할 수 있는 옵션이 제공됩니다.

[그림 9]는 Activity Log의 설정 화면입니다. 진단 설정과 비슷하지만 수집되는 데이터가 다릅니다. 해당 데이터는 모든 Subscription이 동일합니다. 해당 Subscription에서 사용하는 특정 리소스에 대한 서비스 상태에 이슈가 있을 시에도 Log를 발생하므로, 해당 Log를 내부 알람으로 연동할 수도 있습니다. 위의 다양한 Log들은 다음과 같은 파이프라인으로 연동되어 카카오뱅크 내부 SIEM(Security Information and Event Management) 시스템으로 들어오게 구성하였습니다.

각각의 리소스(Entra ID 포함) 및 Subscription의 진단 설정, Activity Log들을 전부 Event Hub와 스토리지 계정으로 적재됩니다. ‘Event Hub’는 Azure에서 발생하는 다양한 데이터를 실시간으로 스트리밍 하는 서비스입니다. Event hub에 데이터가 적재되면 이 데이터를 Consume 해줄 수 있는 요소가 필요합니다. 여기서는 Serverless 인스턴스인 Azure Function을 만들어서 처리하고자 했습니다. Azure Function 중 EventHubTrigger 타입의 함수가 Event Hub와의 연동을 쉽게 설정할 수 있습니다.

이렇게 구성한 Azure Function에는 Log를 카카오뱅크 내부로 전송하는 간단한 코드가 작성되어 있습니다. Azure Function의 VNet 통합 기능을 활용하여, Azure의 VNet을 통해 아웃바운드 트래픽을 송신하도록 구성했습니다. 카카오뱅크에서는 Azure의 각종 로그들을 Event Hubs로 보내는 것뿐만 아니라 Azure Storage로도 전송하여 저장하고 있는데요. 이는 향후 필요에 따라, Log 데이터 추적 및 컴플라이언스 대응을 위해서입니다.

Azure OpenAI가 적용된 서비스는?

지금까지 우리는 Azure의 OpenAI 서비스를 어떻게 하면 private 하게 사용할 수 있는지에 대해 알아보았습니다. 이와 관련해, 카카오뱅크는 연구개발 망에 존재하는 사내 메신저로 연동된 AI 봇을 임직원들에게 제공하고 있습니다. 또한, 개인정보 보호 필요성이 높은 영역에서는 개인정보 탐지 로직을 앞단에 배치함으로써 고객 정보의 안전을 보장하고 있습니다. 또한, 유소년층을 주요 고객으로 하는 ‘오늘의 mini 일기 서비스‘도 Azure OpenAI를 활용하여 제공되었습니다. 이 서비스의 컨셉, 사용된 기술, 그리고 구축 과정에 대해 더 궁금하시다면, 아래의 관련 글들을 확인해보시길 추천드립니다.

금융권 최초로 대고객 서비스에 AI를 적용한 카카오뱅크는 지금도 내부에서 새롭고 흥미로운 AI 기능 및 서비스를 출시하기 위해 열심히 🌸꽃단장🌸 중입니다. 앞으로도 더 다양하고 유용한 서비스를 안전하게 카카오뱅크 고객 여러분께 제공하기 위해 최선을 다하겠습니다. 긴 글 읽어주셔서 감사합니다.