[4개월 개발기] 에피소드 1

시리즈 “4개월간의 금융 AI 개발기” 1편. Claude Code를 보조 개발 도구로 삼고, GPU 한 대와 3명의 팀원으로 금융 추천 시스템을 구축한 과정을 다룬다.

우리가 대체하려 한 것

기존 시스템은 ALS(Alternating Least Squares) 기반의 협업 필터링 추천기였다. 수년 동안 프로덕션 환경에서 운영되며 추천 결과를 생성하고 있었지만, 두 가지 구조적 한계가 있었다.

첫째, 추천 사유의 명확한 설명이 어려웠다. ALS는 사용자와 상품 간의 유사도를 나타내는 잠재 요인(Latent Factor)을 제공한다. 하지만 비즈니스 관점에서 “잠재 요인 수치가 높아서”라는 설명은 고객이나 감독 당국을 납득시키기에 부족했다. 모델이 특정 고객에게 특정 상품을 추천한 명확한 이유를 개별 기여도로 분해해 제시하기 어려웠다.

둘째, 다양한 태스크(Task) 확장에 제약이 있었다. ALS는 사용자-아이템 상호작용 행렬 분해(Matrix Factorization) 기반이므로 협업 필터링 추천에 특화되어 있다. 이탈 예측, 고객 가치 계층화, 다음 상품 추천 등 새로운 유스케이스가 필요할 때마다 로지스틱 회귀나 XGBoost, 규칙(Rule) 기반 세그멘테이션 등 별도의 모델을 병렬로 추가해야 했다. 태스크별로 여러 모델이 개별적으로 튜닝되고 관리되었으며, 고객 특성을 공통으로 표현하는 기반 모델이 없었다.

이에 따라 (a) 비즈니스적으로 해석 가능한 설명을 제공하고, (b) 하나의 모델에서 공통된 표현을 공유하여 여러 태스크를 동시에 처리할 수 있는 시스템으로 교체하는 것을 목표로 삼았다.

구축한 시스템의 규모

과거 ALS 시스템을 대체하여 새롭게 구축한 온프레미스(On-premise) 프로덕션 시스템의 규모는 다음과 같다.

80개 이상의 Airflow DAG
챔피언-챌린저(Champion-Challenger) 모델 경쟁 체제
주 단위 자동 재학습 파이프라인
734차원의 피처 텐서(Feature Tensor)
18개 태스크 동시 처리
62개 데이터 테이블의 데이터 수집(Ingestion)

(현재 오픈소스로 공개된 AWS 벤치마크 버전은 결정론적 리키지 및 중복 태스크를 제거하여 13개 태스크와 349차원 피처로 축소되어 있으나, 핵심 아키텍처와 엔지니어링 패턴은 동일하다.)

이 규모의 시스템을 3명의 인원과 데스크톱 GPU 1대로 구축하기 위해 AI 증강 개발(AI-augmented development) 방식을 도입했다.

팀 구성과 인프라

팀 구성원은 데이터 사이언티스트 겸 PM/리드 아키텍트 1명과 엔지니어 2명, 총 3명이었다. 별도의 대규모 인력이나 전용 서버 자원이 할당되지 않은 조건에서 프로젝트가 시작되었다.

하드웨어는 VRAM 12GB의 RTX 4070 소비자용 데스크톱 GPU 한 대를 학습용으로 활용했다.

데이터 레이어는 기존 HIVE 환경을 그대로 사용해야 했으므로, 네트워크 대역폭 한계를 고려한 병렬 쿼리 로직을 직접 설계했다.

Claude Code, Gemini, Cursor 같은 AI 도구와 AWS 스팟 인스턴스, S3 스토리지는 제한된 예산 안에서 운영되었다. 자원이 제한적인 환경이었으나, 이를 주어진 조건으로 받아들이고 대안을 모색했다.

Claude Code를 통한 한계 보완

제한된 인원과 장비만으로 80개의 DAG가 포함된 시스템을 4개월 만에 구축하기 위해, 프로젝트 초기부터 Claude Code를 개발 과정에 적극적으로 도입했다.

일반적인 보일러플레이트(Boilerplate) 코드 작성, 아키텍처 구현 초안 작성, 버그 추적, 병렬 작업 간의 컨텍스트 유지 등을 AI가 보조했다. 여러 명이 소화해야 할 개발 작업을 AI가 분담하면서, 3명의 인력으로도 넓은 범위의 시스템을 구축할 수 있었다.

이어지는 에피소드 2에서는 이 협업이 어떻게 작동했는지 구체적으로 설명한다. 단계별로 어떤 AI 도구를 활용했고, 팀원들이 AI 에이전트와 어떻게 업무를 나누었는지 다룬다. 제한된 조건 속에서도 AI 도구를 적절히 활용하면 구현 가능한 결과물의 범위와 속도를 유의미하게 확장할 수 있음을 확인했다.

아키텍처 결정 과정

최종 채택된 7개의 이종 전문가 네트워크와 PLE(Progressive Layered Extraction) 기반 구조는 여러 대안을 검토하고 기각하는 과정을 거쳐 결정되었다.

후보 1: Black-Litterman 모델. 포트폴리오 이론에서 파생된 모델로, 전문가의 관점과 시장의 사전분포를 베이지안 업데이트(Bayesian Update)로 결합한다. 전문가 신호를 사후분포로 결합하는 구조적 특성이 유용해 보였다. 하지만 각 전문가의 기여도를 명확히 분해해서 설명하기 어렵다는 한계가 존재했다. 사후분포로 혼합된 결과물에서 개별 기여도를 복원하기 어려워, 고객이나 감독 당국에 추천 근거를 명확히 제시할 수 없었으므로 도입이 보류되었다.

후보 2: 모델 앙상블(Ensemble). N개의 독립 모델을 학습시킨 후 결과를 결합하는 방식이다. 이 방식은 N개의 모델을 각각 관리하고 모니터링해야 하므로 운영 비용과 복잡도가 크게 증가한다. 소규모 팀에서 감당하기 어려운 유지보수 비용이 예상되었다. 또한, “특정 모델의 기여 비율”만으로는 비즈니스적인 추천 사유를 직관적으로 설명하기 어려워 제외되었다.

결정적 리프레이밍(Reframing): PLE 도입. 모델 외부에서 결과를 결합하는 대신, 모델 내부에서 전문가를 결합하는 방식을 검토했다. 단일 모델과 서빙 엔드포인트를 유지하면서, 모델 내부에 여러 전문가를 두고 ‘게이트 가중치(Gate Weight)‘로 기여도를 해석할 수 있는 구조다.

텐센트(Tencent)가 제안한 PLE(Progressive Layered Extraction) 아키텍처는 여러 전문가가 공통 기반에서 학습하고, 게이팅 네트워크가 태스크별 전문가 기여도를 동적으로 결정한다. 이 게이트 값은 추상적인 잠재 요인이 아니라 직접 확인하고 해석할 수 있어 설명 가능성 요건을 충족했다.

이에 따라 7개의 전문가 모듈을 배치하고, 각각 그래프 구조, 시간 역학, 위상 형태, 인과 추론 등 다양한 수학적 관점을 반영하도록 설계했다. 이 전문가들은 공통된 기반 위에서 학습하며, 사후 분석 없이 게이트 가중치 자체가 설명의 근거로 사용된다.

이 설계는 Claude와의 논의를 통해 코드로 점진적으로 구체화되었다. 합성 데이터를 활용해 프로토타입을 만들고 게이트 가중치의 해석 가능성을 확인한 후, 7개 전문가 구조와 13개 태스크 처리 아키텍처로 확장해 나갔다.

제약 조건이 설계에 미친 영향

가용한 예산과 인프라 자원이 풍부했다면, 대규모 파라미터를 가진 Transformer 기반 전문가 모델을 여러 개 쌓는 방식을 채택했을 수 있다. 하지만 12GB VRAM이라는 하드웨어 제약으로 인해 파라미터 크기를 무작정 늘리는 접근은 배제되었다.

이 제약은 각 전문가 모델을 경량화(Lightweight)하면서 구조적으로 명확히 구분하도록 이끌었다. 연산량을 단순 증가시키는 대신, 적절한 귀납 편향(Inductive Bias)을 통해 표현력을 높이는 방향을 택했다. 이를 위해 하이퍼볼릭 기하학, 최적 수송(Optimal Transport), 지속 호몰로지(Persistent Homology) 등 여러 학문 분야의 수학적 해법, 즉 **구조적 동형사상(Isomorphism)**을 차용하여 적은 연산 비용으로 시스템에 적용했다.

자원 제약이 역설적으로 더 가볍고 특화된 구조적 해법을 모색하게 만들었고, 결과적으로 현재의 최적화된 아키텍처 설계를 완성하는 계기가 되었다.