[4개월 개발기] 에피소드 8 — 정직한 실패의 기록(Honest Negative Results)과 다음 단계

*“4개월간의 금융 AI 개발기”를 장식할 대망의 마지막 8편이다. 에피소드 1부터 7까지 우리는 눈부시게 ‘작동한 것들’에 대해 열띠게 떠들었다. 기존 ALS 시스템을 걷어낸 이유(Ep 1), AI와의 매끄러운 협업(Ep 2), 규제를 막아내는 가드레일(Ep 3), 7개의 이종 전문가(Ep 4), 처절했던 데이터 무결성 사냥(Ep 5), 아키텍처를 뒤집어엎은 버그(Ep 6), 그리고 람다(Lambda) 위에서의 경쾌한 서빙(Ep 7)까지. 하지만 이번 마지막 편은, 똑같은 4개월의 땀방울이 서려 있음에도 결국 **‘작동하지 않은 것들’*에 대한 솔직하고도 중요한 기록이다.

adaTT — 13개 태스크 규모에서의 무의미한(Null) 효과

가장 중요한 오해는 논문(Paper 1)의 첫 번째 초안에서 비롯되었다. 당시 우리는 당당하게 *“adaTT 모듈을 13개 태스크 구성에 붙였더니, PLE 단독 모델보다 오히려 AUC가 -0.019나 떨어졌다”*라고 적어 넣었다. 그리고 이 숫자를 근거로, adaTT 구조가 이 정도 규모에서는 **‘구조적으로 완전히 실패한다’**는 거창한 해석을 달았다. 156개나 되는 태스크 간의 친화도(Affinity) 방향 쌍이 빚어내는 조합론적 불안정성, 그리고 PLE가 이미 훌륭하게 분리해 둔 표현(Representation) 수준을 adaTT가 손실(Loss) 단계에서 억지로 섞어버리면서 발생하는 상쇄 효과 등 그럴듯한 이중 설명까지 장황하게 덧붙여서 말이다.

하지만 에피소드 6에서 고백했듯, 그 끔찍했던 불확실성 가중치(Uncertainty Weighting) 모듈의 부호 버그를 찾아내어 간신히 고친 직후 똑같은 실험을 조심스레 다시 돌려보았다. 결과는 허무했다. adaTT를 켜고 껐을 때의 성능 격차(Gap)가 -0.019에서 불과 -0.001로 대폭 쪼그라든 것이다. -0.001이라는 숫자는 통계적으로 완전히 무의미한, 그저 단일 시드(Seed)가 만들어내는 미세한 노이즈(Noise) 범위 안에 불과했다.

이 허탈한 수치가 말해주는 재해석의 결론은 명확하다. adaTT 모듈은 13개 태스크라는 거대한 규모에서 PLE 모델의 성능을 딱히 망치지도 않지만, 그렇다고 눈에 띄게 개선해 주지도 못하는 **‘무의미한(Null) 효과’**를 낼 뿐이다. 요컨대, 우리가 마주한 이 복잡한 금융 데이터와 거대한 아키텍처 조합 위에서는 굳이 연산량을 낭비하며 adaTT를 가져다 쓸 이유가 전혀 없었다는 뜻이다.

”구조적인 실패”와 “무의미한(Null) 효과”는 완전히 다르다

이 미묘한 뉘앙스의 차이를 명확히 구분하는 것은 방법론적으로 극히 중요하다. 논문 초판에서 우리가 함부로 내뱉었던 “구조적 실패”라는 부정확한 주장은, 자칫 *“다른 어떤 데이터 규모나 환경에서도 adaTT는 결코 작동하지 않는 오류다”*라고 주요한 일반화의 오류를 낳을 소지가 다분했다. 하지만 “무의미한(Null) 효과”라는 조심스러운 결론은 그런 성급한 일반화를 경계한다. 태스크가 불과 2–4개 남짓한 소규모의 얌전한 세팅에서는 adaTT가 분명히 유용할 수 있으며 (실제로 여러 최신 문헌들이 그 효과를 증명하고 있다), 단지 무려 13개의 억센 태스크가 뒤엉킨 우리의 극단적인 ‘이질적(Heterogeneous) 환경’에서만 유독 그 마법이 통하지 않았을 뿐이라는 뜻이기 때문이다.

결국 Paper 1의 두 번째 버전(v2)에서 이 섣부른 문장들은 붉은 펜으로 벅벅 그어지며 다음과 같이 겸손하게 수정되었다. “13개 태스크의 이질적 MTL 환경에서 adaTT는 단일 시드 노이즈 범위 내의 무의미한(Null) 효과를 보였다. 이전에 마이너스 효과로 잘못 보고되었던 결과는 훈련 환경을 심각하게 오염시켰던 버그의 심각한 부산물(Artifact)이었으며, 현재는 성공적으로 수정되었다.” 앞으로 우리 팀이 이와 유사한 성격의 실험 결과를 밖으로 보고할 때는, 반드시 **‘정확한 효과의 크기 + 통계적 신뢰구간 + 명확한 환경적 한계’**를 세트로 명시하는 것이 중요한 룰이 되었다.

GradSurgery — 심각한 VRAM 오버헤드로 인한 기각

adaTT가 신통치 않은 모습을 보이자, 우리는 대안으로 논문 등에서 핫하게 떠오르던 PCGrad의 태스크 유형 프로젝션(Task-type Projection) 방식을 응용한 ‘GradSurgery’ 기법을 실험 도마 위에 올렸다. 13개 태스크라는 묵직한 규모에서 벌어지는 골치 아픈 그래디언트 충돌(Gradient Conflict) 현상을, adaTT와는 전혀 다른 날카로운 수학적 접근으로 수술(Surgery)해 보려는 야심 찬 시도였다.

코드를 짜고 며칠간 실험을 굴려보았다. AUC를 비롯한 성능 지표의 차이는 adaTT 때와 마찬가지로 고만고만한 노이즈 범위 안에서 맴돌았다. 즉, 성능(Performance) 측면에서는 기존 방식 대비 유의미한 차이를 전혀 만들어내지 못한 것이다. 그런데 진짜 심각한 비극은 성능 지표가 아니라 **‘VRAM 모니터링 창’**에서 터져 나왔다.

GradSurgery 기법은 본질적으로 매 스텝(Step)마다 13개 태스크 각각의 거대한 그래디언트를 메모리에 고스란히 복제하여 쥐고 있어야 하며, 그 후 태스크 쌍(Pair)끼리 무려 156번의 프로젝션 연산을 빠르게 수행해야 한다. 계산해보라. 13개 태스크 × 2M 파라미터 = 무려 26M에 달하는 거대한 그래디언트 카피본과, 156번의 일반적인 프로젝션을 감당하기 위한 엄청난 여유 메모리가 실시간으로 필요하다. 우리가 학습용으로 쥐어짜며 쓰고 있던 불과 12GB따리 RTX 4070 그래픽 카드에서는, 이 엄청난 오버헤드를 견뎌내기 위해 배치 사이즈(Batch Size)를 눈물을 머금고 반토막으로 썰어내야만 했다.

결론은 매우 명확했다. “불과 똑같은 성능(AUC)을 얻자고, 학습 시간을 두 배나 더 느리게 낭비할 수는 없다.” 망설임 없는 기각(Reject)이었다.

여기서 우리 팀이 뼈저리게 배운 엔지니어링의 일반 원칙이 하나 있다. “어떤 알고리즘의 구현 복잡도나 하드웨어 연산 비용이, 그 알고리즘이 가져다주는 성능 향상의 이득을 까먹는다면 무조건 기각한다.” GradSurgery라는 알고리즘 자체가 잘못되었다는 뜻이 절대 아니다. 오직 12GB VRAM이라는 우리의 하드웨어 제약 조건 안에서만큼은 그 기법의 투자 대비 수익(ROI)이 철저하게 마이너스(-)였을 뿐이다.

아직 끝내지 못한 숙제, Paper 3 (Loss Dynamics)

에피소드 6에서 “Paper 3 (Loss Dynamics)의 핵심 아이디어가 바로 이 심각한 버그 사태에서 싹을 틔웠다”고 은근조용히 예고한 적이 있다. 부끄럽지만 그 거창했던 Paper 3는 현재 작업 중(WIP, Work In Progress)이라는 핑계 아래 방치되어 있다.

이 미완성 논문이 지속적으로 파고들려는 핵심 질문은 이것이다. “손실 함수(Loss Function)의 미세한 동역학(Dynamics) 차이 하나가, 전체 모델 아키텍처에 대한 철학적 결론마저도 정반대로 뒤집어버릴 수 있는가?” 에피소드 6에서 어렵게 경험했던 ‘Sigmoid-Softmax 성능 역전’ 사태가 이 섬뜩한 질문에 대한 단 하나의, 그러나 너무나도 강력한 데이터 포인트다. Paper 3는 이 우연한 발견을 체계적인 과학으로 승화시키려는 야심 찬 시도다. 다양한 손실 가중치 기법(Uniform, Uncertainty, GradNorm, DWA 등)과 다채로운 게이트 구조(Softmax, Sigmoid, 단순 MoE 등)를 조합한 거대한 매트릭스 위에서, 우리가 그토록 확신했던 아키텍처적 결론들이 환경 변수에 따라 얼마나 나약하게 흔들리고 부서지는지를 낱낱이 해부하는 것이다.

솔직히 말해 현재로서는 겨우 초록(Abstract) 정도만 끄적여 둔 상태다. 거대한 실험 설계(Design)는 마쳤고 GPU는 밤낮없이 돌아가고 있지만, 이 모든 결괏값을 정리하여 2026년 3분기에 Zenodo에 번듯하게 업로드하겠다는 목표는 꽤나 숨이 찬 일정이다. 훗날 멋진 결과물이 세상에 나오게 된다면, 이 블로그의 Study Thread 섹션에서 아주 집요하고 상세하게 다룰 것을 약속한다.

합성 데이터에서 프로덕션 데이터로 — 아직 열리지 않은 검증 창

지난 4개월의 설계와 실험은 공개 벤치마크(Santander Customer Transaction Prediction)와, 이를 흉내 낸 100만 행 규모의 합성 데이터(Synthetic Data) 위에서 돌아갔다. 이 두 경로 위에서 아무리 정교한 검증을 거쳤다 하더라도, 실제 프로덕션 트래픽 앞에서 동일한 아키텍처 결론이 그대로 재현될 것이라는 보장은 없다. 이 격차가 좁혀지는지 여부는 결국 실 프로덕션 데이터 위에서 직접 확인해야 한다.

2026년 4월 30일, 실제 프로덕션 트래픽 위에서 태스크별 AUC·F1-macro·MAE·NDCG와 5개 보호 속성에 대한 공정성 지표 수집이 시작됐다. 이 글을 쓰는 지금(5월 중순)까지 쌓인 5월 초의 지표는 통계적으로 유의한 볼륨에는 한참 못 미친다. 며칠 치 메트릭만 보고 “Sigmoid 역전극(Ep 6)이 실데이터에서도 재현된다”고 판정할 수는 없다.

이 블로그에 실리는 것과 실리지 않는 것의 선은 분명하다.

공개 가능 영역: 태스크별 AUC, 보호 속성별 DI, 드리프트 추이, 인시던트 통계처럼 집계된 기술 지표.
공개 불가 영역: 고객 세그먼트 분포, 개별 고객 특성, 내부 영업 정책 등 고객·비즈니스 식별이 가능한 모든 정보.

후자는 금융회사 내부 정보보호 원칙의 대상이며, 이 블로그에는 전자의 집계 수치만 올라간다.

합성 데이터에서 내린 우리의 확신이 프로덕션에서도 재현될지는 아직 답할 수 없다. Sigmoid-Softmax 역전극(Ep 6)이 실데이터에서도 같은 패턴으로 나타날지, 7개 이종 전문가 중 어떤 전문가가 프로덕션 분포 앞에서 먼저 흔들릴지 — 몇 달간 쌓일 지표에 달린 질문이다. 성공적으로 재현되면 이 4개월의 방법론적 주장들은 실데이터로 뒷받침되고, 크게 어긋나면 그 자체가 다음 Paper의 출발점이 된다. 어느 쪽이든 결과는 Study Thread나 Commentary 카테고리에서 이어가겠다.

4개월 동안 숨겨서 시도했지만 결국 기록에 남기지 않은 시행착오들

몇 가지만 더 솔직하게 고백하고 넘어가자. 화려한 논문 초안에는 차마 싣지 못했지만, 4개월이라는 압박 속에서 실제로 울며 겨자 먹기로 시도해 보았던 시행착오들이 제법 많았다.

전문가를 7개에서 9개로 통합하여 본 시도: 기존의 훌륭한 7개 구성(지속 호몰로지, 하이퍼볼릭, 인과 추론 등)에 만족하지 못하고, 기어코 가우시안 프로세스(Gaussian Process) 전문가와 드롭아웃 베이지안(Dropout Bayesian) 전문가를 추가해 9개짜리 괴물을 만들어 보았다. 성능 차이는 눈곱만큼도 없었고, VRAM만 턱밑까지 차올라 헐떡거렸다. 얌전하게 7개로 원상 복구.
멀티 헤드 어텐션(Multi-head Attention) 전문가의 난입: 트랜스포머(Transformer)의 유행에 휩쓸려 거대한 어텐션 모듈을 추가 전문가로 꽂아보았다. 파라미터 수만 기존 7개 전문가를 다 합친 것의 2배로 폭발해 버렸고, AUC의 개선은 매우 적었다. 주저 없이 기각.
태스크 그룹을 3축에서 2축으로 강제 붕괴: 정교하게 나누어둔 4개의 태스크 그룹을, 어떻게든 쥐어짜 보겠다며 2개의 뭉툭한 축(참여도-생애주기 vs 소비-가치)으로 거칠게 단순화해 보았다. 일부 태스크의 성능은 찔끔 올랐지만, 다른 쪽 태스크들의 성능이 와르르 무너져 내렸다. 전체적으로는 Net Zero(본전). 시스템의 복잡도가 줄어드는 이점조차 뚜렷하지 않아 얌전히 롤백했다.
Causal 전문가 모듈 — NOTEARS 대신 DirectLiNGAM의 발악: 비선형 인과 구조에 집착하여 선형 기반의 NOTEARS 대신 멋들어져 보이는 DirectLiNGAM 알고리즘을 태워보았다. 하지만 13개 태스크라는 거대한 규모 앞에서는 둘 다 이리 튀고 저리 튀며 수렴 자체가 불안정했다. 결국 울며 겨자 먹기로 NOTEARS 구조 위에 재건 손실(Recon Loss) 패치를 발라 억지로 안정화시켰다 (자세한 내용은 깃허브의 project_causal_w_collapse_fix 메모리 참조).

이런 어려웠던 실패담들은 정갈한 학술 논문에 절대 실리지 않는다. 무의미한(Null) 결과나 쥐꼬리만 한(Marginal) 개선점들을 논문에 죄다 구겨 넣었다간, 정작 전하고자 하는 핵심 메시지가 심각하게 희석되고 종이 낭비만 초래하기 때문이다. 하지만 이 거친 블로그의 뒷골목에는 이런 시행착오들을 텍스트로 박제해 둘 충분한 가치가 있다. 훗날 비슷한 고민에 빠져 똑같은 시행착오의 경로를 기웃거리려는 다른 어느 팀의 가엾은 엔지니어가, 이 글을 읽고 *“아, 저 팀이 이미 해보고 망했구나”*라며 귀중한 주말 시간을 아낄 수 있다면 그걸로 족하다.

이 모든 실패를 관통하는 단 하나의 깨달음

이번 편과 이전 에피소드들에 파편처럼 흩뿌려둔 아픈 오답들 — 환상을 쫓았던 레이블 리키지 3건(Ep 5), 몇 주를 허비하게 만든 불확실성 가중치의 예상치 못한 부호 버그(Ep 6), 섣불렀던 “adaTT 구조적 실패” 선언, 심각한 VRAM 오버헤드로 인한 GradSurgery의 기각, 전문가 9개 욱여넣기의 오류, Softmax-Sigmoid의 혼란스러운 역전극, DirectLiNGAM의 수렴 실패 — 이 모든 시행착오들은 결과적으로 매우 단 하나의 동일한 개발 패턴을 거쳐 우리의 뒤통수를 쳤다.

착각의 시작: 프로젝트 초기의 어떤 (때로는 우연히 부풀려진) 결과값이 마치 신의 계시처럼 확고한 ‘불변의 결론’으로 보였다.
모래성 쌓기: 우리는 그 의심스러운 결론을 든든한 반석이라 착각하고, 그 전제 위에 아슬아슬한 후속 작업들을 원활하게 쌓아 올렸다.
균열의 발견: 보통 수주일이 지나고 나서야, 시스템의 다른 구석에서 튀어나온 새로운 관측 결과가 기존의 전제를 정면으로 부정하며 중요한 ‘재검토’를 강요했다.
회생의 열쇠: 하지만 절망적인 재검토의 시점에 다다랐을 때, 다행스럽게도 ‘우리가 과거에 왜 그런 부정확한 결론을 내렸는지에 대한 추론의 맥락’이 텍스트로 생생하게 접근 가능한 상태로 살아 있었다. 덕분에 우리 팀은 “도대체 우리가 3주 전에 왜 그런 잘못된 짓을 했지?”라며 단순하게 기억을 더듬는 대신, **“그때의 그 논리적인 전제가 새로운 증거 앞에서는 지금 어떻게(How) 다르게 해석되는가?”**를 곧바로 날카롭게 따져 물을 수 있었다.

바로 이 4번째 단계의 극적인 반전에서, Claude Code가 세션 전체의 맥락을 긴 호흡으로 유지해 준다는 특성이 결정적인 빛을 발했다. 이 도구가 없었다면, 매번 찾아오는 재검토 작업은 낡은 개인 노트에 갈겨쓴 메모 조각들을 이어 붙이는 고된 작업이 되었을 것이고, 십중팔구 가장 중요한 전제 하나쯤은 놓쳐버렸을 것이다. 위에서 열거한 숱한 실패의 기록 중 절반 이상은 아마도 *“에이, 그건 벌써 3주 전에 다 합의 끝난 거잖아”*라는 귀찮음 밑에 영원히 파묻혀 두 번 다시 세상 빛을 보지 못했을 것이다.

착각하지 말자. 이것은 거창한 AI가 위대한 인간 엔지니어의 일자리를 성공적으로 대체했다는 흔해 빠진 SF 소설이 아니다. 이것은 **“AI라는 도구가, 엔지니어가 자신의 중요한 과거 결론을 다시 의심하고 뒤집어엎는 ‘재조사의 비용(Cost)‘을 인간이 기꺼이 감당할 수 있는 수준으로 극단적으로 낮추어 주었다”**는 대단히 건조하고 현실적인 이야기다. 3명 남짓한 팀이 자신이 정답이라 믿었던 과거의 결론을 원활하게 해결하고 기꺼이 백지에서 다시 시작하는 그 고통스러운 ‘정직함(Honesty)‘의 무게는 온전히 인간 엔지니어의 몫이었지만, 가혹한 4개월의 데드라인 안에서 그 정직함의 육체적 피로를 대폭 덜어준 것은 명백히 Claude Code의 공로였다.

왜 우리는 이 부끄러운 실패(Negative Results)를 공개해야 하는가

머신러닝(ML) 연구 판에서 끊임없이 불거지는 심각한 재현성(Reproducibility) 위기의 상당 부분은, 사실 수많은 팀들이 어렵게 겪은 실패의 결과(Negative Results)들이 어딘가에 투명하게 출판(Publish)되지 않기 때문에 벌어진다. 기대했던 것보다 성능이 구리거나 예상과 빗나간 나쁜 결과물들은 그저 *“논문 거리가 안 된다”, “흥미롭지 않다”*는 단순한 이유로 연구자들의 폐기 조용히 처박힌다. 그리고 지구 반대편의 완전히 다른 팀에서, 똑같이 귀중한 시간과 막대한 GPU 자원을 갈아 넣으며 100% 똑같은 시행착오을 똑같이 반복하는 희극이 무한히 펼쳐진다.

우리 팀이 겪었던 불확실성 가중치의 부호 버그(에피소드 6) 사태만 해도 그렇다. 전 세계 어딘가의 누군가가 이미 똑같은 부호 실수를 저지르고 똑같이 몇 주를 날려 먹었을 확률이 농후하다. 하지만 그 어디에도 *“우리가 실험해 보니 처음엔 Sigmoid가 매우 이기는 줄 알았는데, 나중에 정신을 차려보니 그냥 부호 버그 때문이었어!”*라고 솔직하게 까발려 둔 친절한 공개 기록이 존재하지 않았기 때문에, 우리는 그 함정을 우리 손으로 하나부터 열까지 다시 파고 들어가며 온몸으로 두들겨 맞아야만 했다.

이 허름한 블로그에 굳이 길고 일반적인 글들을 싸지르는 이유는, 바로 그 역겨운 침묵의 패턴을 단 1mm라도 깨부숴보려는 작지만 필사적인 시도다. “4개월이라는 팍팍한 시간 동안 불과 3명짜리 팀이 뼈 빠지게 시도했지만, 결국 작동하지 않았던 유효하지 않은 아이디어들”의 생생한 목록이, 내일 당장 우리와 똑같은 고민의 늪에 빠질 다른 어느 팀에게 단 몇 주라도 소중한 수면 시간을 절약해 줄 수만 있다면. 이 어려웠던 실패(Negative Results)를 밤새워 타이핑하고 문서로 남기는 수고스러움 대비, 세상이 얻는 잉여 가치는 차고 넘치고도 남는다.

4개월 개발기 시리즈를 닫으며

무려 8편의 텍스트에 꾹꾹 눌러 담아 빠르게 기록했다. 낡은 ALS 시스템의 플러그를 뽑아버린 도발적인 동기(Ep 1), 7개의 이종 전문가 아키텍처가 세상에 나온 과정(Ep 4), AI와의 어려운 협업 방법론(Ep 2), 규제를 코드로 적용한 가드레일 체계(Ep 3), 먼지 나도록 털어댄 데이터 무결성 사냥(Ep 5), 뒤통수를 거하게 친 훈련 환경의 버그(Ep 6), 중요했던 람다(Lambda) 서버리스 위에서의 증류와 서빙(Ep 7), 그리고 이번 편의 중요한 정직한 실패(Negative Results)의 고백까지.

이 모든 텍스트를 관통하는 단 하나의 묵직한 메시지는 이것이다. “가난한 한국 금융권의 불과 3–5명 규모 중소형 팀도, 낡은 관습을 부수고 최신의 거대한 AI 아키텍처를 실제 프로덕션(Production) 무대 위에 당당히 쏘아 올릴 수 있다.” 수십억 원짜리 대형 GPU 클러스터가 없어도, 대규모 전담 MRM(모델 리스크 관리) 조직의 지원 없이도, Claude Code를 든든한 파트너로 삼는다면 충분히 가능한 일이다. 단, 조건이 있다. 발걸음을 내딛는 매 순간마다, 매 결정마다 지독할 정도로 날카로운 근거를 자신에게 따져 물어야만 한다. 왜 하필 수많은 아키텍처 중에 이것을 골랐는가? 왜 널려 있는 도구들 중에 하필 저것을 썼는가? 왜 이 귀찮고 피곤한 검증 단계를 굳이 고집스럽게 끼워 넣었는가?

치열했던 4개월이 지나고 연기가 걷힌 지금의 시야에서 뒤돌아보면, 솔직히 말해 찬란하게 잘 작동했던 것들보다는 예상외로 실수하고 시행착오했던 오류들이 훨씬 더 선명하고 끔찍하게 뇌리에 박혀 있다. 그 문제가 된 불확실성 가중치 부호 버그, 초반의 무지몽매했던 “adaTT 구조적 실패” 선언, 초기 합성 데이터(v1) 생성용 GAN의 한심한 과적합 한계, 그리고 작동을 조여왔던 레이블 리키지 3연쇄 폭발 사태까지. 하지만 신기하게도, 그 끔찍했던 매 한 번의 실수들이 결국 우리 프로젝트의 여린 방법론을 망치질하여 한 칸씩 단단한 강철로 벼려내 주었다.

“진정한 전문성이란 처음부터 실수를 아예 하지 않는 신적인 완벽함이 아니라, 스쳐 지나가는 사소한 실수를 지속적으로 분석하여 마침내 발견해 내고야 마는 집념이다.” 에피소드 6에서 울부짖었던 그 한 문장이야말로, 이 4개월 개발기 시리즈 전체의 피와 땀을 관통하는 가장 처절하고도 성공적인 함축이다.

앞으로의 계획

말도 많고 탈도 많았던 [FinAI Build] 시리즈의 여정은 이 8편의 텍스트를 끝으로 마침내 무거운 셔터를 내리며 완결을 고한다. 하지만 이 블로그의 톱니바퀴는 여기서 멈추지 않고 계속해서 굴러갈 것이다.

Study Thread: 이건 이미 한창 시끄럽게 진행 중이다 (PLE 심층 해부 6편 + adaTT 파헤치기 4편). 이어서 Causal OT, TDA, Temporal Ensemble, Economics Expert 등 우리가 갈아 넣었던 각 전문가 모델들의 뼈대와 내장을 해부하는 깊이 있는 기술 글들이 순차적으로 쏟아질 것이다.
Commentary: 금융 AI 판을 뒤흔드는 특정 비상 사건, 골치 아픈 규제 가이드라인의 개정, 흥미로운 최신 논문 리뷰 등에 대한 지극히 주관적이고 날 선 부정기적 비평 글이 연재될 예정이다. (아직 첫 삽도 뜨지 못했지만 곧 시작할 것이다).
실데이터 업데이트: 2026년 4월 30일 이후 누적되고 있는 실제 프로덕션 메트릭들에 대한 어려운 해석은, 데이터가 충분히 쌓이는 대로 Study Thread나 완전히 새로운 별도의 시리즈를 파서 다룰 예정이다.

이 빠르게 길고 텍스트 덩어리로 꽉 찬 기록들을 여기까지 묵묵히 읽어내려와 주신 모든 분께 깊은 경의와 감사를 표한다. 각 에피소드들이 굳이 순서대로 읽지 않아도 독립적인 맥락을 가지도록 신경 써서 썼으니, 나중에라도 본인의 가려운 관심사에 따라 언제든 필요한 부분만 쏙쏙 골라 읽으러 돌아와 주시길 바란다. 글에 대한 날카로운 질문이나 엄격한 지적, 혹은 술 한잔 곁들인 토론은 언제나 환영이다. (연락처: 정선규 ORCID).

원문 자료: Paper 1 (Zenodo) + Paper 2 (Zenodo). 코드: github.com/bluethestyle/aws_ple_for_financial.