[4개월 개발기] 에피소드 2 — AI 에이전트 조직화

“4개월간의 금융 AI 개발기” 2편. 3명의 팀원이 여러 AI 도구(Gemini, Claude Opus, Cursor, Claude Code)를 개발 단계별로 어떻게 조직하고 분업시켰는지 다룬다.

단계별 도구 페어링(Pairing) 전략

프로젝트 초기, 제한된 자원은 아키텍처 선택뿐만 아니라 AI와의 협업 방식에도 영향을 미쳤다. 단일 AI 도구로 전 개발 과정을 처리하려던 접근은 효율성 측면에서 한계를 보였다. 각 개발 단계마다 요구되는 AI의 강점이 달랐기 때문이다. 목적에 맞춰 여러 AI 도구를 분리하고 적절히 배치하는 전략이 개발 속도와 산출물의 품질을 높이는 데 효과적이었다.

정립된 5단계의 협업 흐름은 다음과 같다.

Phase A — 아이디에이션 (Gemini)

초기 아키텍처 콘셉트 탐색과 아이디어 도출은 Gemini를 활용했다. 기존 ALS 모델의 대안, Black-Litterman 모델 적용 가능성, 앙상블(Ensemble) 기법의 비교 등 여러 대안을 폭넓게 탐색하는 데 적합했다.

Gemini의 주요 활용 포인트는 학제 간(Interdisciplinary) 피처 아이디어 탐색이었다. “화학의 반응 속도론 공식으로 고객의 소비 행동 변화를 설명할 수 있을까?”, “금융 상품 채택 과정이 전염병 확산 모델과 유사한가?”와 같은 접근을 통해 다른 학문 분야의 수학적 구조를 금융 데이터에 적용하는 방안을 모색했다. 도메인 지식을 제공하면, Gemini가 이와 연관된 타 학문의 개념을 제안하는 방식으로 협업이 이루어졌다.

이 과정을 통해 **“구조적 동형사상(Structural Isomorphism)“**이라는 방향이 도출되었다. 서로 다른 11개 학문 분야에서 수학적 구조를 차용해 아키텍처를 설계한다는 기조가 세워졌고, 이는 이후 의사결정의 기반이 되었다. 이 단계에서는 기술적 검증보다는 다양한 분야의 지식을 연결하고 탐색하는 데 AI의 강점이 활용되었다.

Phase B — 기술 검증 (Claude Opus)

도출된 아이디어를 작동 가능한 아키텍처로 구체화하는 단계에서는 Claude Opus를 활용했다. 손실 함수(Loss Function) 설계, 데이터 리키지(Data Leakage) 검증, 정규화 파이프라인 구조화 등 수학적 엄밀성과 깊이 있는 기술적 검토가 필요한 작업들이 중심이었다.

선별된 전문가 네트워크 후보군에 대해 실현 가능성을 점검했다. “HGCN(Hyperbolic Graph Convolutional Network)이 신용카드 가맹점(MCC) 계층 구조에서 유효한가?”, “Mamba 아키텍처가 17개월치 시계열 데이터를 안정적으로 처리할 수 있는가?”와 같은 의제를 두고 Opus와 논의했다. PLE와 MMoE 간의 구조적 비교, adaTT 모델의 전이에 대한 분석도 진행되었다.

Opus는 프로젝트의 기본 가정에 대해 기술적인 검토 의견을 제시했다. Black-Litterman 모델의 한계를 논의한 끝에 PLE 구조로 수정을 결정하게 된 것도 이러한 기술 토론의 결과였다. 또한, 전문가 붕괴(Expert Collapse) 현상에 대한 우려가 초기 검토에서 확인되었고, 이는 이후 Phase E에서 Sigmoid Gate 도입을 논의하는 계기가 되었다.

Phase B를 거쳐 총 19편의 기술 참조 문서가 작성되었다. 이 문서들은 이어지는 구현 단계에서 아키텍처 지침이자 설계 명세서 역할을 수행했다.

Phase C — 코드 환경 정비 (Cursor)

GitHub 기반 리포지토리 환경 설정, 전체 프로젝트 디렉터리 구조 설계 및 초기 보일러플레이트(Boilerplate) 생성 작업은 Cursor IDE를 이용해 진행했다. IDE에 통합된 환경에서의 빠른 파일 탐색 및 코드 구조화 기능이 이 단계에 적합했다.

이 과정에서 6편의 초기 아키텍처 설계 문서와 프로젝트의 기본 규약인 CLAUDE.md 가드레일이 작성되었다. 하드코딩 지양(Config-driven), 관심사 분리(Separation of Concerns), 데이터 리키지 방지 등의 규칙이 실제 코드 구현 전에 명문화되었다.

이러한 규약 확립은 이후 진행될 3명의 병렬 구현 작업(Phase D) 시 발생할 수 있는 구조적 충돌이나 통합 문제를 방지하기 위한 사전 조치였다.

Phase D — 병렬 구현 (Claude Code · Opus/Sonnet)

코드 구현 단계에서는 3명의 팀원이 각기 AI 에이전트를 보조로 활용하여 모듈 개발을 병렬로 진행했다. 주로 Claude Code 환경에서 Opus와 Sonnet 모델을 교차 활용했다.

• PM / 리드 아키텍트: 아키텍처 수준의 주요 설계(PLE Config 구조, adaTT 태스크 그룹화, 로짓 전이 설계 등)는 Opus와 논의하고, 이를 바탕으로 코드를 작성하는 작업(Generator, Adapter, Pipeline Runner 등)에는 처리 속도가 빠른 Sonnet을 활용했다. 레이블 리키지 탐지, FP16 정밀도 환경의 에러 원인 진단, 메모리 활용률 점검 등 주요 디버깅이 이 과정에서 이루어졌다.
• 엔지니어 1: 데이터 수집 파이프라인, 네트워크 병렬 쿼리 로직, 그리고 여러 이종 전문가 모듈(TDA, HMM, Mamba, Graph, GMM 등)의 피처 엔지니어링 및 매핑 레지스트리 구현을 담당했다.
• 엔지니어 2: 데이터 파이프라인을 바탕으로 한 모델 학습 로직 구현, 수학적 검증 수행, 그리고 PLE 모델을 LightGBM으로 압축하는 지식 증류(Knowledge Distillation) 구현을 전담했다.

3개의 트랙이 병렬로 진행되었음에도 시스템 통합 과정의 오류를 최소화할 수 있었던 것은 설정한 CLAUDE.md 규약과 인터페이스 계약 검증 루틴 덕분이었다. 모듈 간 데이터를 주고받을 때 사용되는 키(Key) 이름 등의 일치 여부를 작업 완료 시마다 점검하여 통합 충돌을 예방했다.

Phase E — 실험 및 논문 작성 (Claude Code Extension)

제거 실험(Ablation Study)이 진행될 때, Claude Code를 학습 상황 및 에러 로그를 모니터링하는 도구로 활용했다. 학습 진행 상황, GPU 활용률, 런타임 에러 등을 확인하며 디버깅에 반영했다. 실험 중 발견된 토글 버그(use_ple=false 설정 시 베이스라인 구성이 달라지는 문제) 등을 조기에 진단하여 자원 낭비를 줄였다.

학습 대기 시간 동안 문헌 조사와 가설 검증을 병행했다. PLE 아키텍처의 검증 손실이 안정되지 않는 현상에 대해 “Softmax 게이트의 경쟁적 특성이 이종 전문가 간의 수렴을 저해할 수 있다”는 가설을 수립했다. 최근 발표된 Sigmoid 게이트 논문을 참고하여 구조를 수정했고, 성능 개선을 관찰하여 아키텍처 결정의 기준으로 채택했다.

그러나 이후 불확실성 가중치(Uncertainty Weighting) 구현 버그를 수정하자, Softmax와 Sigmoid의 성능 우위가 역전되는 현상이 발생했다. 버그로 인해 특정 이진 분류 태스크에 가중치가 치우쳤던 환경에서는 Sigmoid의 비경쟁적 라우팅이 우연한 방어 역할을 했으나, 정상화된 가중치 환경에서는 Softmax의 경쟁적 라우팅이 태스크 유형 간 그래디언트 오염을 방지하는 장벽으로 작용했다.

이 일화는 아키텍처 성능 평가가 훈련 환경의 조건에 종속될 수 있음을 보여준다. 이전의 결정이 훈련 환경 오류에 대한 적응 결과였음을 인지하고 가정을 재검토해야 했다. Claude Code의 연속적인 컨텍스트 유지 기능 덕분에 이전의 의사결정 맥락을 바탕으로 빠르게 과거 결정을 수정할 수 있었다.

이후 논문 작성 과정에서도 AI는 텍스트 초안 작성 및 문서 구조화의 보조 도구로써 활용되었다.

도구의 선택과 활용 기준

여러 도구 중에서 구현 및 실험 단계에 Claude Code를 주로 사용한 이유는 다음과 같다.

첫째, 긴 컨텍스트와 연속적인 추적 능력이다. 레이블 리키지 원인 3건(has_nba 중복, 파일 정렬 순서 편향, 제너레이터 레이블 입력)을 단일 세션에서 순차적으로 파악하고 수정할 수 있었던 것은 논리적 맥락이 세션에 유지되었기 때문이다.

둘째, 시스템 구조 전반과 개별 코드의 디테일을 함께 살피는 시야다. FP16 환경에서 여러 모듈에 걸쳐 발생한 NaN 에러를 진단할 때, 거시적 구조와 모듈 내부의 연산 흐름을 동시에 추적하는 데 AI 분석 역량이 유용했다.

셋째, 문제 관찰부터 구현 및 결정 재검토까지 연결되는 흐름이다. 실험 결과 분석, 가설 수립, 문헌 탐색, 코드 수정이 끊김 없이 진행되었으며, 새로운 증거가 나타났을 때 과거 맥락을 참조하여 설계를 수정할 수 있었다.

협업 과정에서 확인된 패턴들

도구 활용과 협업에 있어 다음과 같은 실무적 패턴들이 관찰되었다.

첫째, AI는 구현 방식을 돕고, 인간은 목표와 방향을 결정한다. 코드 작성과 초안 생성은 AI가 보조하지만, 아키텍처 방향을 결정하고 원칙을 채택하는 것은 인간의 판단 영역이다.

둘째, 병렬 작업 전 가드레일 확립이 필요하다. CLAUDE.md와 같은 규약이 코딩 전에 문서화됨으로써, 이후의 구현과 모듈 통합이 안정적으로 진행될 수 있었다.

셋째, 목적에 따른 AI 도구의 분리가 효율적이다. 각 단계의 특성(초기 탐색, 기술 검증, 구현 등)에 맞는 도구(Gemini, Opus, Cursor, Claude Code)를 배치했을 때 전반적인 품질과 효율이 유지되었다.

넷째, 버그 추적과 수정 주기의 단축. 에러 진단 및 파이프라인의 논리적 오류 식별에 AI를 활용하여 이슈 발견부터 수정까지의 주기를 단축할 수 있었다.

다음 편 안내

이어지는 에피소드 3에서는 Phase D의 병렬 구현 단계에서 프로젝트의 일관성을 유지하기 위해 사용된 장치들을 다룬다. CLAUDE.md 가드레일 내용, 수동 메모리 뱅크(Memory Bank) 시스템, 규칙 파일 동기화, 그리고 인터페이스 계약 검증 프로세스의 적용 사례를 설명한다.

원문 자료: 개발 스토리 (KO, PDF) §2 “AI 에이전트 조직화”.