Your Finance Agent's Bottleneck Is You — Ramana Siddanth Emani, Auditoria AI

URL: https://www.youtube.com/watch?v=z0sh8HyTrDo 날짜: 2026-07-30 채널: AI Engineer (aiDotEngineer) 발표자: Ramana Siddanth Emani (Siddhant Imani, Data Scientist, Auditoria AI) 주제: AI agent harness · finance agent · dev loop velocity · production bug automation

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

금융 에이전트의 진짜 병목은 더 좋은 모델, 더 빠른 GPU, 더 새로운 프레임워크가 아니라 ==개발자/운영자 자신==이다. 데모를 프로덕션으로 승급할 때 쏟아지는 버그를 실시간으로 고치려면, 개발자 루프(dev loop velocity)를 극단적으로 가속화하고, sub-agent, skills, MCP tools, minimal UX, goals+loops, dreaming을 조합해 인간을 루프에서 점진적으로 빼내는 설계가 필요하다.

• 매 3.5개월마다 새 모델, 매년 더 빠른 GPU, 매일 새로운 프레임워크가 나오지만, 데모는 여전히 프로덕션에서 실패한다.
• 프로덕션 버그는 매우 높고, 프로덕션 가드(production guards)는 매시간 쌓인다.
• 금융권처럼 규제와 감사가 엄격한 환경에서는 인간이 책임 주체와 최종 검증자로 남아야 하지만, 처리량의 상한(throughput ceiling)이 되어서는 안 된다.
• sub-agent를 병렬 work tree에 배치하고, skills를 조직 비밀 레시피로 축적하며, MCP로 외부 시스템을 연결하고, minimal UX로 단일 창에서 오케스트레이션하면 인간은 검증자로 남을 수 있다.

이 영상은 전통적인 기술 스택 병목 가설을 깨고, "에이전트를 만드는 사람이 병목이다"라는 관점에서 개발 생산성과 책임 구조를 재설계하는 방법을 제시한다.

---

1. 데모에서 프로덕션으로: 왜 아름다운 데모가 실패하는가

1.1. AI 엔지니어 월드 페어의 화려한 데모와 현실의 괴리

1. 데모는 쉽게 만들어진다

   1. 최신 모델 + 빠른 GPU로 멋진 시연 가능: 현재의 LLM과 하드웨어는 눈에 띄는 데모를 빠르게 만들기에 충분하다.
   2. 코드 작성 자체가 쉽다: 발표자는 "writing code is very easy"라고 반복하며, 프로토타입 코드 생산은 더 이상 병목이 아니라고 강조한다.
   3. 많은 사람에게 보여주기 쉽다: 데모를 많은 이들 앞에서 보여주는 것 역시 현재 도구 환경에서는 간단하다.

2. 프로덕션으로 승급하면 발생하는 문제

   1. 미래 데이터에 대한 무지: 에이전트는 데모/파일럿 단계에서 본 데이터 외에, 실제 고객 데이터를 본 적이 없다("the agent has never seen these future data").
   2. 새로운 고객 온보딩의 충격: 파일럿에서 새로운 고객을 onboard하면 데이터 분포와 요구사항이 달라지며, 에이전트가 익숙하지 않은 상황에 노출된다.
   3. 프로덕션 버그의 빈발: "production bugs are very high and production guards built by the hour"라는 직접 인용처럼, 운영 환경에서는 버그가 계속 발생하고 방어 로직이 계속 추가된다.

1.2. 병목은 기술 스택이 아니다

1. 잘못된 진단: 모델, GPU, 프레임워크

   1. 모델: 3.5개월마다 새로운 모델이 시장에 나오므로(Fable 5, Mythos 5, GPT 5.6 등을 언급), 모델 교체는 쉽다.
   2. 하드웨어: 1년이면 더 빠른 GPU/칩이 등장하므로, 하드웨어는 몇 달 내에 교체 가능하다.
   3. 프레임워크: 매일 새로운 프레임워크가 등장하고, 코드 작성 자체가 쉬우므로 프레임워크도 손쉽게 바꿀 수 있다.
   4. RALF loops: 발표자는 "your RALF loops are not working properly"라고 언급하며, 프레임워크 내부의 반복 루프도 원인이 아닌 경우가 많음을 시사한다.

2. 올바른 진단: 개발자 루프의 속도

   1. Dev loop velocity: 프로덕션 버그를 실시간으로 고치려면 개발-테스트-PR-머지-빌드-배포-검증 루프를 자동화하고 가속화해야 한다.
   2. 모델 능력의 지수적 성장 vs 인간의 한계: 모델 능력은 기하급수적으로 늘지만, 개발자는 매일 루프를 자동화하는 데 많은 시간을 소비한다.
   3. 개발자 자신이 병목: 기술 요소는 교체 가능하지만, 인간의 주의(attention)와 오케스트레이션 능력은 유한하다. 따라서 병목은 개발자/운영자 자신이다.

---

2. 병목을 해결할 4가지 기본 요소

발표자는 개발자의 생산성을 10배 높이기 위해 반드시 고려해야 할 네 가지 원시 요소(primitives)를 제시한다: sub agents, skills, MCP tools, minimal UX.

2.1. Sub agents와 병렬 work tree

1. sub-agent의 병렬 배치

   1. sub-agent는 마음껏 생성 가능: 현재 어떤 harness를 사용하더라도 새로운 sub-agent를 spawn할 수 있다.
   2. 48GB RAM 맥북에서 50개 active work tree: 발표자는 "with 48 GB of RAM on your MacBook, you can have 50 active work trees"라고 구체적으로 언급하며, 50개의 독립 sub-agent가 동시에 작업할 수 있음을 강조한다.
   3. work tree = 격리된 작업 폴더: 각 work tree는 별도 폴더로, 에이전트가 생성하는 코드를 서로 간섭 없이 작성한다.

2. 실제 운용 시나리오

   1. Jira 티켓 = 개별 work tree: QA가 보고한 버그 티켓마다 별도 work tree를 할당하고, 각 티켓을 독립 sub-agent가 처리한다.
   2. sub-agent가 sub-agent를 spawn: 한 티켓 안에서도 필요한 경우 하위 에이전트를 더 생성해 세분화된 작업(예: trace 수집, 테스트 작성, 코드 수정)을 수행한다.
   3. 작업 큐잉 금지: 인간이 티켓을 큐에 쌓는 것보다, 에이전트가 병렬로 작업을 분산 처리하는 것이 훨씬 효율적이다.

2.2. Skills: 조직의 비밀 레시피

1. skills의 정의와 가치

   1. 조직의 비밀 레시피: skills는 특정 도메인(금융, 회계, 감사 등)에서 쌓은 내부 프로세스와 노하우를 캡슐화한 것이다.
   2. 고객별 레시피: 고객마다 다른 규정, 워크플로우, 데이터 형식을 skills로 전달하여 에이전트가 고객 환경에 맞게 동작하도록 한다.

2. skills가 프로덕션 버그 해결에 미치는 효과

   1. 올바른 워크플로우 강제: 에이전트가 skills를 받으면, 어떤 프로덕션 버그를 마주하더라도 올바르고 적절한 워크플로우를 따르도록 한다.
   2. 반복 실수 감소: 조직의 표준 절차를 에이전트가 내재화하여 사람의 실수와 품질 편차를 줄인다.

2.3. MCP tools: 제3자 시스템과의 연결

1. MCP의 역할

   1. 외부 서버 연결: 에이전트는 logging system, authentication gateway, 데이터베이스, Jira, GitHub 등 어떤 제3자 서버/도구에도 연결할 수 있다.
   2. 클라이언트 데이터의 분산 저장: 고객 데이터가 어떤 시스템에 있든 MCP를 통해 접근할 수 있다.

2. MCP 도입 시 주의점

   1. 연결 가능성 ≠ 문제 해결: 현재 많은 MCP 도구가 시장에 나오지만, 단순히 연결만 한다고 해서 프로덕션 버그가 자동으로 해결되지는 않는다.
   2. 오케스트레이션의 복잡성: sub-agent가 많아지고 MCP가 늘수록 조율 오버헤드가 증가하며, 이를 관리할 인터페이스가 필요하다.

2.4. Minimal UX: 한 개의 창으로 모두 조율

1. minimal UX의 필요성

   1. 인간은 최소한의 UX를 좋아한다: 발표자는 "humans love minimal UX"라고 말하며, 복잡한 인터페이스는 인간의 주의를 낭비한다고 본다.
   2. 오케스트레이션 부담 감소: sub-agent와 MCP가 많아질수록, 인간의 인지 부하를 줄이는 단일 인터페이스가 필수이다.

2. 이상적인 단일 창 (single pane of glass)

   1. macOS 위젯 형태: 프로덕션 에이전트 소프트웨어, Kubernetes 서비스/파드, 시스템 로그, Jira 티켓, GitHub PR, 클라우드 코드 세션까지 한 화면에 통합한다.
   2. 목 회전 횟수 감소: 개발자가 여러 모니터를 두고 목을 돌리며 창을 전환하는 현실을 지적하며, 단일 위젯이 하나의 변경을 배포하는 데 필요한 "number of neck rotations"을 급격히 줄인다.
   3. 개발자의 다양한 업무 지원: 개발자가 평소 다양한 일을 하므로, 하나의 위젯으로 여러 작업을 처리할 수 있어야 한다.

---

3. End-to-end 버그 수정 루프의 자동화와 금융권의 책임 구조

3.1. 9단계 버그 수정 파이프라인

1. 단계 1: 요구사항 파싱과 근본 원인 분석

   1. QA 버그 티켓 수집: QA가 보고한 버그 티켓을 입력으로 받는다.
   2. 자동 근본 원인 분석: 에이전트가 요구사항을 파싱하고, root cause analysis를 수행한다.
   3. trace/log 수집: 모든 트레이스와 로그를 pull해와 별도 work tree에 모은다.

2. 단계 2~8: 구현, 검증, 배포

   1. 별도 work tree에서 TDD 수행: 에이전트가 독립 work tree에서 테스트 주도 개발로 수정을 구현한다.
   2. 로컬 end-to-end 테스트: 로컬 시스템에서 테스트 스크립트와 e2e 테스트를 수행한다.
   3. PR 생성 및 팀 리뷰: 수정된 코드를 PR로 제출하여 팀 리뷰를 받는다.
   4. 머지 후 Docker 이미지 빌드: master 브랜치에 머지 후 Docker 이미지를 빌드한다.
   5. dev/stage 환경 배포 및 테스트: 개발 환경과 스테이징 환경에 각각 배포하고 테스트한다.
   6. QA 피드백: 스테이징 테스트를 마친 후 QA에게 "Here you go. You can test it now"라고 전달한다.

3. 단계 9: 인간의 최종 검증

   1. 인간은 단계 1과 9에만 필요: 발표자는 9단계 중 처음과 마지막에만 인간이 개입하면 된다고 주장한다.
   2. 중간 단계의 인간 개입은 감시 용도: 에이전트가 무엇을 하는지 보려는 인간의 필요성은 있지만, 세부 실행(2~8)은 에이전트가 더 잘 수행한다.

3.2. 금융권에서의 인간-감사-책임 구조

1. 금융권의 규제와 감사 요구

   1. 인간 감사관(human auditor): AI가 없을 때는 인간 감사관이 코드를 검토하고, 컨트롤러(controller)가 SOX 규정에 따라 서명한다.
   2. AI로 인한 책임 소재 모호화: 에이전트가 에이전트를 감사하면 "Cloud is doing this"라고 책임을 전가할 수 없으며, 책임 주체가 불분명해진다.

2. sub-agent + 감사의 긴장

   1. 에이전트가 에이전트를 감사: sub-agent가 많아지면 감사 주체를 에이전트로 둘 수밖에 없는데, 이는 규제 환경에서 위험하다.
   2. 금융권에서 "move fast and break things"는 다른 의미: 금융 규제 하에서는 실패 비용이 크고 책임 추적이 중요하므로, 실리콘밸리의 "빠르게 움직이고 망가뜨리자" 방식과 다른 의미를 가진다.

3. 인간 주의가 병목이 되는 지점

   1. 수많은 sub-agent의 오케스트레이션: 인간이 모든 sub-agent를 조율하면 인간 주의(attention)가 병목이 된다.
   2. 검증자로 남되 처리량 상한이 되지 않도록: 인간은 최종 검증자로 남아야 하지만, 처리량의 천장(ceiling)이 되어서는 안 된다.

---

4. 루프에서 자신을 제거하기: recursive self-improvement

4.1. 모델 능력 상승과 자기 개선

1. 새로운 모델 세대

   1. Fable 5, Mythos 5, GPT 5.6: 발표자는 향후 모델 세대를 언급하며, 모델 능력이 자가 개선에 기여할 것이라고 본다.
   2. 모델 능력의 지수적 증가: 모델 능력이 빠르게 향상되면, 에이전트가 스스로 개발 루프를 개선할 수 있는 여지가 커진다.

2. 프로덕션 실패를 입력으로 활용

   1. 실패 = 학습 데이터: "all your production failures become input"라는 인용처럼, 모든 프로덕션 실패를 개발 harness의 입력으로 삼아 자동화를 개선한다.
   2. 루프를 매일 업그레이드: 에이전트에게 "이 과정의 병목을 분석하고 매일 제거하라"고 지시한다.
   3. 한 달 뒤의 목표: 한 달간 반복하면 "fix this bug for me"라는 한 문장만으로 e2e 파이프라인이 실행되도록 자동화된다.

4.2. Goals + Loops

1. 목표 설정 후 잊어버리기

   1. goal 지정: "there is some data discrepancy in this report"처럼 목표만 설정하면, 에이전트가 데이터베이스, 로그, 트레이스, Jira, QA 파이프라인을 연결해 처리한다.
   2. 폰으로도 가능: "you can do it from your phone nowadays"라며, 루프를 핸드폰에서도 실행할 수 있어 노트북을 닫아도 된다.

2. 꿈꾸는 에이전트(Dreaming)

   1. 고객 사용 패턴의 백그라운드 수집: 많은 사용자가 같은 패턴으로 같은 문제를 겪는 경우, 에이전트가 백그라운드에서 "dream like humans dream"하듯 세션을 수집한다.
   2. 데이터 포인트 압축: 수집된 세션을 데이터 포인트로 압축하여 시스템이 스스로 업그레이드하는 데 사용한다.
   3. 발표자의 비유: 발표자는 코를 고는 듯한 소리("[snorts]")를 내며 dreaming을 비유적으로 표현한다.

4.3. 인간의 새로운 역할

1. 검증자로 남기

   1. 항상 인간은 검증자: 에이전트가 처리한 결과를 인간이 최종 검증해야 한다.
   2. 처리량 상한이 되지 않기: "human attention is very limited"라는 인용처럼, 인간의 주의는 한정적이므로 인간이 병목이 되지 않도록 루프를 제거해야 한다.

2. 9-to-5 책상 앞 코딩의 종말

   1. 개발자의 업무 다양성: 개발자는 단순 코딩 외에도 다양한 일을 하며, 책상에 앉아 9시부터 5시까지 코드만 쓰는 방식은 더 이상 유효하지 않다.
   2. 새로운 작업 방식: 에이전트가 루프를 돌아가는 동안 인간은 더 전략적이고 창의적인 검증과 설계에 집중한다.

---

주요 발언 모음

"Hello everyone. Welcome to this session about your finance agent's bottleneck is you." "I'm here to talk about the harnesses that you guys are developing and using these internal harnesses to build your production agents." "Production bugs are very high and production guards built by the hour." "Is it the model? Do you need a better model? Fable 5, perhaps? Or do you need faster GPUs? Or do you need a better framework? Maybe." "If you wait 3 and a half months, we are awarded with a new model in the market. So, we can easily swap models." "The answer is your dev loop velocity." "All of you need to think about loops." "With 48 GB of RAM on your MacBook, you can have 50 active work trees. That is 50 active sub-agents working independently on different tasks." "Skills are your organization secret recipes." "The human is only required at steps 1 and 9 because the in-between steps, the agent can do a lot better work." "You can't say Cloud is doing this. Something is wrong." "all your production failures become input." "You can just set a goal and forget about it." "You can even close your laptop because you can do it from your phone nowadays." "Always have the human as a verifier, but not the throughput ceiling because human attention is very limited." "Thank you for your time. I hope you learned something from the session."

핵심 데이터 & 수치

• 48GB RAM: 맥북 기준 50개 active work tree, 즉 50개 병렬 sub-agent 동시 실행 가능
• 3.5개월: 새로운 모델이 시장에 나오는 주기 (쉽게 교체 가능)
• 1년: 더 빠른 GPU/칩이 등장하는 주기
• 50 active work trees: 50개의 독립적인 에이전트 작업 공간
• 9단계 파이프라인: 요구사항 파싱 → 근본 원인 분석 → trace/log 수집 → work tree에서 TDD → 로컬 e2e 테스트 → PR 생성/리뷰 → 머지 → Docker 이미지 빌드 → dev/stage 배포/테스트 → QA 피드백
• 인간 개입 지점: 9단계 중 1(작업 정의/감시)과 9(최종 검증)에만 필요

결론 및 시사점

1. 금융 에이전트의 진짜 병목은 모델, GPU, 프레임워크가 아니라 개발자/운영자 자신이다. 기술 스택은 상품화되어 빠르게 교체 가능하지만, 인간의 주의와 오케스트레이션은 유한하다.
2. 데모에서 프로덕션으로 전환하는 것은 단순 모델 교체가 아닌, dev loop velocity의 문제다. 프로덕션 버그는 매시간 쌓이므로, 루프를 실시간으로 돌릴 수 있어야 한다.
3. sub-agent를 병렬 work tree에 배치하고, skills, MCP, minimal UX를 결합하면 인간의 오케스트레이션 부담을 줄이고, 인간은 검증자로 남을 수 있다.
4. 금융권처럼 규제와 감사가 엄격한 환경에서는 에이전트가 에이전트를 감사할 때 책임 소재가 모호해지므로, 인간은 최종 검증자와 책임 주체로 남아야 한다.
5. goals+loops+dreaming을 통해 루프에서 인간을 점진적으로 제거하고, 프로덕션 실패를 자기 개선의 입력으로 삼으면 장기적으로 "한 문장으로 버그를 수리"하는 수준에 도달할 수 있다.
6. 인간은 검증자(verifier)로 남되, 처리량의 상한(throughput ceiling)이 되어서는 안 된다. 이것이 금융 에이전트의 병목을 해소하는 핵심 설계 원칙이다.