Archives — everything, in
the order it was written.
A chronological index. Hollow dots are drafts; filled rows are published. The calendar shows writing density for the current month.
아카이브 — 모든 글을
쓰여진 순서대로.
시간 순 색인. 빈 점은 초안, 꽉 찬 행은 게시된 글. 캘린더는 이번 달의 글쓰기 밀도를 보여준다.
May
[FinAI Build] Ep 5 — The Data Integrity Hunt
Before any architecture debate — three chained label-leakage detections, the deterministic-leakage rationale behind the 18→13 task reduction, and the self-replicating features that surfaced across synthetic-data iterations v2→v3→v4.
[4개월 개발기] 에피소드 5 — 데이터 무결성 사냥
화려한 아키텍처 논쟁에 뛰어들기 전에 반드시 풀어야만 했던 복잡한 문제들. 레이블 리키지(Label Leakage) 3건의 연쇄 탐지 과정, 18개에서 13개로 태스크를 축소해야만 했던 결정론적 리키지의 배경, 그리고 합성 데이터 반복 개선(v2→v3→v4) 과정에서 드러난 중요한 교훈을 다룬다.
[MRM Thread] Ep 5 — RAG + LanceDB: Why Audit Infrastructure Is a Retrieval Problem
We started with the idea that the audit log was a write-only archive. The first time a risk officer needed similar-case context inside a five-minute decision window, that idea broke. RAG over LanceDB is what came out of refusing to maintain two copies of the same source of truth — and what unlocked human oversight, fairness monitoring, and quarterly aggregation as queries on the same store.
[MRM 스레드] 에피소드 5 — RAG + LanceDB · 감사 인프라가 결국 검색 문제인 이유
감사 로그는 단순한 쓰기 전용 데이터가 아니다. 질의 가능한 지식 베이스다. 운영 및 감사 검색 인프라를 컬럼형, 버전 인식, 시간 여행 기능이 결합된 RAG와 LanceDB로 구성한 이유를 설명한다. 그리고 그 결과로 인적 감독, 운영 파이프라인 위에서의 공정성 모니터링, 분기별 집계 문제가 어떻게 해결되는지 살펴본다.
Apr
[Commentary] Privacy Impact Assessment and AI Disclosure as Byproducts of the Audit Log
PIPA-grounded Privacy Impact Assessment and the Financial Services Commission's quarterly public-disclosure report, both delivered as automatic byproducts of the audit log rather than documents written from scratch. How they quietly ride on top of Ep 3's `log_*` tables, and what remains on the MRM committee's desk.
[Commentary] 개인정보 영향평가와 AI 공시를 감사 로그의 부산물로
PIPA 기반 개인정보 영향평가(PIA)와 금융위 공시용 분기 리포트가 서면 작성이 아니라 감사 로그의 자동 부산물로 떨어지는 구조. 두 산출물이 어떻게 Ep 3 의 `log_*` 테이블 위에 조용히 얹히는지, 그리고 MRM 위원회에는 무엇이 남는지.
[FinAI Build] Ep 4 — The Seven Experts: Importing Structural Isomorphism Across Eleven Disciplines
Why seven experts, why these seven. The cross-disciplinary scan with Gemini surfaced eleven fields; the feasibility review with Opus narrowed to DeepFM, Temporal Ensemble, HGCN, PersLay, Causal, LightGCN, and Optimal Transport.
[4개월 개발기] 에피소드 4 — 일곱 전문가: 11개 학문에서 구조적 동형사상을 차용하다
왜 7명인가, 그리고 왜 하필 이 7명인가. 11개 학문 분야를 넓게 훑어보고, 엄격한 기술 검증을 거쳐 최종적으로 살아남은 DeepFM·Temporal·HGCN·PersLay·Causal·LightGCN·OT 7개 전문가의 치열한 도출 과정을 다룬다.
[MRM Thread] Ep 4 — When Explanation Is Architecture: Inherent XAI and FD-TVS Scoring
Post-hoc XAI (SHAP, LIME) wobbled on us when we ran the cost and stability numbers. We chose architectural XAI instead — the gate weights of seven heterogeneous PLE experts as the explanation, with CEH attribution and Mahalanobis OOD as the second and third layers. FD-TVS is the operational scoring philosophy that grew out of fixing the on-prem per-product weights model.
[MRM 스레드] 에피소드 4 — 설명이 아키텍처가 될 때: 내재적 XAI와 FD-TVS 스코어링
사후적 XAI(SHAP·LIME)는 운영 환경에서 불안정하며 모델과도 분리되어 있다. 우리는 PLE의 7개 이종 전문가 모델 위에서 게이트 가중치 자체를 설명으로 활용하는 방식을 택했다. 추론 경로의 자연스러운 결과물로 매 예측의 근거를 확보하는 구조다. FD-TVS는 그 위에 얹어진 운영 스코어링 철학이다.
[Commentary] A reliability flag on every prediction — Causal Guardrail and Mahalanobis distance
If MRM Ep 3's audit log guarantees *record integrity*, who judges whether *each individual prediction* is trustworthy? A prediction-level guardrail that detects OOD signals via Mahalanobis distance on the Causal Expert's latent space, and how it pairs with CEH attribution to fold into the audit trail.
[Commentary] 예측마다 신뢰도를 묻는다 — Causal Guardrail 과 Mahalanobis 거리
MRM Ep 3 의 감사 로그가 *기록의 무결성* 을 보증한다면, 각각의 개별 예측이 *신뢰할 만한가* 는 누가 판정하는가. Causal Expert 의 latent space 위에서 Mahalanobis 거리로 OOD 신호를 잡아내는 예측-단위 guardrail, 그리고 이것이 CEH attribution 과 쌍을 이뤄 감사 추적에 편입되는 방식.
[FinAI Build] Ep 3 — How We Adapted: Guardrails, Memory Bank, Contract Verification
The mechanisms that kept three parallel AI-agent teams from breaking at integration — the CLAUDE.md constitution, the migration from a manual memory bank to Claude Code auto-memory, and the interface-key diff check run after every parallel session.
[4개월 개발기] 에피소드 3 — 우리의 적응 방식: 가드레일·메모리 뱅크·계약 검증
3명과 AI 에이전트들이 병렬로 달리면서도 통합 지점에서 시스템이 무너지지 않도록 지탱해 준 세 가지 장치들 — `CLAUDE.md` 기본 규약, 수동 메모리 뱅크에서 자동 기억(auto-memory)으로의 진화, 그리고 매 작업 직후에 수행되는 인터페이스 계약 검증 프로세스를 살펴본다.
[MRM Thread] Ep 3 — Auditing the Auditors: Chain of Custody and Consensus Arbitration
Seven audit tables and an HMAC hash chain give you 'continuity of record'. But who verifies the record? The trap of the single-LLM auditor, multi-agent consensus with α/β/γ perspectives, a minority-report-that-never-gets-deleted design, and why AWS parallel voting and on-prem 2-round deliberation chose different paths.
[MRM 스레드] 에피소드 3 — 감사의 감사자들: Chain of Custody와 컨센서스 중재
7개 감사 테이블과 HMAC 해시 체인이 '기록의 연속성'을 보장한다면, 그 기록을 누가 검증하는가. 단일 LLM 판정의 함정과 다중 에이전트 컨센서스(α·β·γ) 구조, 소수 의견을 지우지 않는 설계, 그리고 AWS 병렬 투표와 온프렘 2-Round 심의가 서로 다른 방식을 택한 이유.
[FinAI Build] Ep 2 — Organizing the AI Agents
Five phases, four tools — how Gemini, Claude Opus, Cursor, and Claude Code each took a specific slot (ideation / technical validation / scaffolding / implementation / paper writing). Why tool separation beat tool uniformity on both speed and quality.
[4개월 개발기] 에피소드 2 — AI 에이전트 조직화
Gemini, Claude Opus, Cursor, Claude Code를 프로젝트 5개 단계에 맞게 분업시킨 방식. 단일 도구 활용보다 단계별 목적에 맞춘 도구 분리가 개발 속도와 품질 측면에서 유리했던 이유를 살펴본다.
[MRM Thread] Ep 2 — Champion-Challenger as a Gate
A Monday-3am walkthrough of `_decide_promotion()` — the 4-step short-circuit ladder (force-promote, bootstrap, fidelity floor, competition) that replaces a 2-to-4-week MRM committee cycle with seconds, and every outcome writes one HMAC-signed audit entry.
[MRM 스레드] 에피소드 2 — 관문으로서의 Champion-Challenger
월요일 새벽 3시 `_decide_promotion()` 안에서 일어나는 일 — 4단계 단락 평가 사다리(force-promote · bootstrap · fidelity floor · competition)가 2-4주짜리 MRM 위원회 주기를 수초로 대체하고, 모든 판정이 HMAC 서명 감사 엔트리를 남긴다.
[Study Thread] ADATT-1 — Why adaTT: Adaptive Towers and the Transformer Attention Analogy
The adaTT sub-thread opens — why fixed task towers hit a ceiling in multi-task learning, how Transformer Attention reframes the adaptive-tower problem, and where adaTT sits in the lineage of conditional computation and hypernetworks.
[Study Thread] ADATT-1 — adaTT 동기: 적응형 타워와 Transformer Attention 의 유사성
adaTT 서브스레드 시작 — 멀티태스크 학습에서 고정 타워가 닿는 한계, Transformer Attention 이 적응형 타워 문제를 재해석하는 방식, 그리고 조건부 계산·Hypernetwork 계보에서 adaTT 의 위치.
[Study Thread] ADATT-2 — TaskAffinityComputer and Gradient Cosine Similarity
TaskAffinityComputer — the engine that actually measures task-to-task affinity. Gradient cosine similarity with EMA smoothing, why cosine over Euclidean, and the `torch.compiler.disable`-handled gradient extraction path.
[Study Thread] ADATT-2 — TaskAffinityComputer와 Gradient Cosine Similarity
TaskAffinityComputer — 태스크 간 친화도를 실제로 측정하는 엔진. Gradient cosine similarity 수식과 EMA 평활화, 유클리드 거리 대신 코사인을 쓰는 이유, 그리고 `torch.compiler.disable` 로 처리한 gradient 추출 경로.
[Study Thread] ADATT-3 — Transfer Loss, Group Prior, and the 3-Phase Schedule
adaTT's Transfer Loss in full — transfer weights with the G-01 clamp and target-task masking, task-group Prior matrix with Prior Blend Annealing, the 3-Phase Schedule (Warmup → Dynamic → Frozen), and the Negative Transfer detection-and-block mechanism.
[Study Thread] ADATT-3 — Transfer Loss · Group Prior · 3-Phase Schedule
adaTT Transfer Loss 전체 — 전이 가중치와 G-01 Clamp·target 미존재 태스크 마스킹, 태스크 그룹 기반 Prior 행렬과 Prior Blend Annealing, 3-Phase Schedule (Warmup → Dynamic → Frozen), Negative Transfer 감지·차단 메커니즘.
[Study Thread] ADATT-4 — Training Loop, Loss Weighting, Optimizer, and CGC Synchronization
The adaTT sub-thread closes — 2-Phase Training Loop, Loss Weighting strategies (Uncertainty / GradNorm / DWA), Optimizer + Scheduler configuration, CGC–adaTT synchronization, memory and performance notes. With the adaTT tech reference PDF attached.
[Study Thread] ADATT-4 — 학습 루프·Loss Weighting·Optimizer·CGC 동기화
adaTT 서브스레드 마무리 — 2-Phase Training Loop, Loss Weighting 전략 (Uncertainty · GradNorm · DWA), Optimizer · Scheduler 설정, CGC ↔ adaTT 동기화, 메모리·성능 노트. adaTT 기술 참조서 PDF 첨부.
[Study Thread] PLE-1 — MTL and the Evolution Toward Gated Experts (Shared-Bottom → MMoE)
Multi-task learning from the root motivation — why one recommender has to predict dozens of targets at once, the mathematical face of Negative Transfer, and where Shared-Bottom and MMoE each break down. Setup post for PLE's fix.
[Study Thread] PLE-2 — Progressive Layered Extraction: Explicit Expert Separation and CGC Gates
Picking up from MMoE's Expert Collapse — PLE's three chained decisions: explicit Shared/Task expert separation, the heterogeneous Shared Expert pool, and the CGC gate that learns how much of each expert to use per task.
[Study Thread] PLE-2 — Progressive Layered Extraction: 명시적 전문가 분리와 CGC 게이트
MMoE 의 Expert Collapse 가 끝난 지점에서 시작 — PLE 가 이어서 내린 세 가지 결정: Shared/Task Expert 명시적 분리, 이종 Shared Expert 풀, 태스크마다 각 전문가를 얼마나 쓸지 학습하는 CGC 게이트.
[Study Thread] PLE-3 — Meet the Seven Experts: How Each One Sees the Customer Through a Different Mathematical Lens
Why seven experts, and why these seven — seat by seat, the mathematical gap each one fills (DeepFM · Temporal · HGCN · PersLay · LightGCN · Causal · Optimal Transport), the alternatives considered, and why each specific one won.
[Study Thread] PLE-1 — MTL과 게이트드 전문가로의 진화 (Shared-Bottom → MMoE)
멀티태스크 학습의 뿌리 — 추천 시스템이 왜 수십 개 타겟을 동시에 예측해야 하는가, Negative Transfer 의 수식적 모습, Shared-Bottom 과 MMoE 가 각각 어디서 무너지는가. PLE 가 풀어낸 지점으로 가기 전의 도입편.
[Study Thread] PLE-3 — 7명의 전문가를 소개합니다: 각 Expert 가 고객을 어떤 수학적 렌즈로 보는가
왜 7명인가, 왜 이 7명인가 — 자리별로 어떤 수학적 빈틈을 메우는지 (DeepFM · Temporal · HGCN · PersLay · LightGCN · Causal · Optimal Transport), 어떤 후보들을 밀어냈고 왜 이 사람이 뽑혔는지 하나씩.
[Study Thread] PLE-4 — The Two-Stage CGC Gate (CGCLayer + CGCAttention) and HMM Triple-Mode Routing
Two problems surface when the seven heterogeneous experts actually train — dim-asymmetry collapse toward the 128D expert, and customers not living at one time scale. The response: a two-stage CGC gate (CGCLayer + CGCAttention) plus HMM Triple-Mode routing.
[Study Thread] PLE-4 — CGC 게이팅의 두 단계(CGCLayer + CGCAttention)와 HMM Triple-Mode 라우팅
7명 이종 전문가를 실제로 학습시키면 동시에 두 문제가 드러난다 — 128D 전문가로 쏠리는 dim-asymmetry collapse 와 고객이 단일 시간 스케일에 살지 않는다는 사실. 해법은 2단계 CGC 게이트 (CGCLayer + CGCAttention) 와 HMM Triple-Mode 라우팅.
[Study Thread] PLE-5 — GroupTaskExpertBasket, Logit Transfer, Task Tower
Once routing is stable, three decisions remain on the task-private side — per-task expert memory (GroupTaskExpertBasket), explicit cross-task dependencies (Logit Transfer's three modes), and loss balance for the final Task Tower.
[Study Thread] PLE-5 — GroupTaskExpertBasket · Logit Transfer · Task Tower
라우팅이 안정된 뒤 task-private 쪽에 남는 세 결정 — 태스크별 전용 전문가 메모리(GroupTaskExpertBasket), 태스크 간 명시적 의존(Logit Transfer 3 모드), 그리고 최종 Task Tower 의 손실 균형.
[Study Thread] PLE-6 — Interpretability, Uncertainty, and Full Specs
The PLE study sub-thread closes — Sparse Autoencoder for expert interpretability, Evidential Deep Learning for per-prediction uncertainty, the full 18-task spec and paper-vs-implementation comparison. With the full 56-page PLE tech reference PDF attached.
[Study Thread] PLE-6 — 해석성·불확실성·전체 사양
PLE 서브스레드 마지막 — 전문가 해석성을 위한 Sparse Autoencoder, 예측별 불확실성을 정량화하는 Evidential Deep Learning, 18개 태스크 전체 사양과 논문 대 구현 비교. 56쪽 PLE 기술 참조서 PDF 첨부.
[4개월 개발기] 에피소드 1 — 전제 조건
Airflow DAG 80개 규모의 ALS 추천기를 3명의 팀원과 데스크톱 GPU 한 대로 대체하게 된 배경. 기존 시스템의 설명 가능성 및 다중 태스크 처리 한계가 아키텍처 선택을 어떻게 규정했는지 살펴본다.
[FinAI Build] Ep 1 — The Premise
What three people with one desktop GPU set out to replace — an 80-DAG ALS recommender that could not explain itself and could not scale past one task — and how that starting constraint shaped every later architectural choice.
[MRM 스레드] 에피소드 1 — MRM 은 검증이 아니라 아키텍처에 속한다
검증 우선의 MRM 체계는 모델이 LLM 에이전트 파이프라인으로 전환될 때 한계를 가진다. 다단계 실패 모드와 검증 주기 내 드리프트 등의 문제를 해결하기 위해, MRM 의무를 사후 검토 캘린더가 아니라 아키텍처 자체에 반영해야 하는 이유를 설명한다.
[MRM Thread] Ep 1 — Why MRM Belongs in the Architecture
The validation-first view of Model Risk Management breaks once the model becomes an LLM agent pipeline — multi-step attack surface, non-traditional failure modes, drift between validation cycles. Push MRM into the architecture itself, not the review calendar.