🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

금융 에이전트의 병목은 더 많은 모델이나 GPU가 아니라, 병렬 작업을 조율하고 규제상 책임을 최종 승인해야 하는 인간의 제한된 주의력이다.

📌 핵심 요점

1. 데모를 파일럿과 신규 고객 환경으로 확장하면 처음 보는 데이터와 예외가 유입되므로, 프로덕션 대응력은 모델 교체보다 개발 루프의 속도와 자동화 수준에 좌우된다.
2. 서브에이전트, 독립된 Git worktree, 재사용 가능한 스킬, 외부 시스템을 연결하는 MCP와 최소한의 UX가 병렬 작업을 지탱하는 에이전트 하네스를 구성한다.
3. Jira 티켓별 격리 환경에서 요구사항 분석, 근본 원인 조사, 로그·트레이스 수집, TDD, PR 검토, Docker 빌드, 스테이지 배포와 QA 전달까지 연결할 수 있다.
4. 에이전트, Kubernetes, 로그, Jira, GitHub PR과 코딩 세션을 단일 화면에 모으면 개발자의 시선 이동과 수동 상태 확인을 줄일 수 있다.
5. 금융권에서는 코드 검토와 SOX 승인에 대한 인간의 책임을 유지하면서도, 반복 실행과 실패 학습은 에이전트에 위임하도록 인간의 역할을 재설계해야 한다.

🧩 배경과 문제 정의

• 완성도 높은 데모도 파일럿과 신규 고객 환경에 들어가면 에이전트가 보지 못한 데이터와 예외를 만나며, 프로덕션 버그가 시간 단위로 누적된다.
• 새로운 모델·GPU·프레임워크는 주기적으로 교체할 수 있지만, 당장 발생한 장애를 해결하는 속도는 개발 루프의 자동화 수준에 달려 있다.
• 서브에이전트와 병렬 작업은 처리량을 높이지만, 수많은 작업을 조율하는 인간의 주의력과 금융권의 책임 구조가 새로운 병목이 된다.

🕒 시간순 섹션별 상세정리

1. 데모와 프로덕션 사이의 격차

• 데모를 파일럿으로 전환하고 신규 고객을 온보딩하면 미래 데이터와 새로운 예외가 유입되며, 에이전트가 경험하지 못한 프로덕션 버그가 빠르게 쌓인다. [01:16]
• 모델·칩·프레임워크의 교체를 기다리는 동안에도 장애는 계속 발생하므로, 실시간 대응력을 결정하는 핵심은 개발 루프의 속도와 자동화다. [02:40]

2. 에이전트 하네스의 네 가지 구성 요소

• 서브에이전트는 독립된 Git worktree에서 서로 다른 작업을 병렬 처리해 코드 충돌을 줄이고, 한 사람이 다수의 실행 흐름을 동시에 운영할 수 있게 한다. [03:07]
• 조직과 고객의 작업 절차를 스킬로 축적하면 에이전트가 프로덕션 버그마다 검증된 워크플로를 재사용해 해결 과정의 일관성을 높인다. [03:39]
• MCP 도구가 외부 시스템과 고객 데이터를 연결하는 동안, 늘어난 서브에이전트와 작업량을 통제하려면 최소한의 UX가 필요하다. [04:00]

3. 병렬 worktree를 활용한 작업 분산

• 48GB 메모리의 MacBook에서도 약 50개의 worktree와 서브에이전트를 동시에 운용할 수 있어, 서로 독립적인 버그를 대규모로 병렬 처리할 수 있다. [04:29]
• 각 Jira 티켓을 별도 worktree에 배정하면 담당 에이전트가 필요한 서브에이전트를 추가로 생성해 문제를 해결하며, 사람이 작업 대기열을 순차 관리할 필요가 줄어든다. [04:52]

4. 버그 접수부터 스테이지 검증까지의 자동화

• QA 티켓을 받은 에이전트가 요구사항 분석, 근본 원인 조사, 로그·트레이스 수집, TDD와 수정 구현을 하나의 격리된 worktree에서 연속 수행한다. [05:21]
• 수정 결과는 로컬 종단 간 테스트와 PR 검토를 거쳐 Docker 이미지로 빌드되고, 개발·스테이지 환경 배포와 QA 전달까지 같은 흐름으로 계속된다. [05:48]
• 인간은 시작 단계에서 작업을 확인하고 마지막 단계에서 스테이지 결과를 검증하면 되며, 중간 실행 단계는 에이전트가 더 빠르고 일관되게 처리할 수 있다. [06:30]

5. 단일 화면으로 압축하는 오케스트레이션

• 프로덕션 에이전트, Kubernetes 서비스와 Pod, 시스템 로그, Jira 티켓, GitHub PR, 코딩 세션을 하나의 macOS 위젯에 모으면 여러 창을 오가는 조율 비용이 감소한다. [06:52]
• 한 번의 변경을 배포하기 위해 여러 모니터를 계속 확인하던 작업이 단일 화면으로 압축되면서, 개발자의 시선 이동과 수동 상태 점검이 크게 줄어든다. [07:38]

6. 금융권에서 드러나는 인간 주의력의 한계

• 금융 소프트웨어는 인간 감사자의 코드 검토와 컨트롤러의 SOX 승인처럼 책임 주체가 명확해야 하며, 장애 책임을 특정 에이전트나 모델에 넘길 수 없다. [08:10]
• 실시간 버그 수정을 위해 서브에이전트를 늘릴수록 사람이 모든 작업을 조율해야 하므로 주의력이 병목이 되고, 금융권에서는 빠른 변경 자체가 규제·통제 리스크를 키운다. [08:45]
• 프로덕션 실패를 다음 자동화의 입력으로 사용하고, 반복 실행에서 발견한 병목을 매일 제거하면 개발 하네스가 점진적으로 스스로 개선된다. [09:38]

7. 자가 개선 루프와 인간 역할의 재설계

• 한두 날 동안 여러 버그 티켓을 처리한 기록에서 병목을 찾아 한 달간 제거하면, 한 문장의 수정 요청만으로 데이터베이스·로그·트레이스·Jira·QA 파이프라인까지 연결되는 자동화 루프를 만들 수 있다. [10:10]
• 여러 고객에게 반복되는 사용 패턴과 문제를 백그라운드에서 수집·압축하면 재사용 가능한 데이터 포인트가 축적되고, 시스템이 같은 유형의 장애에 스스로 적응할 수 있다. [11:41]
• 인간은 결과의 최종 검증자로 남아야 하지만 제한된 주의력으로 전체 처리량을 막아서는 안 되며, 반복 실행은 목표와 루프를 부여받은 에이전트에 위임해야 한다. [13:04]

🧾 결론

• 서브에이전트를 늘리는 것만으로는 처리량이 무한히 증가하지 않으며, 조율과 승인에 필요한 인간의 주의력이 곧 다음 병목이 된다.
• 프로덕션 경쟁력의 핵심은 개별 모델보다 버그 접수부터 검증까지 이어지는 자동화된 개발 루프와 이를 지속적으로 개선하는 하네스에 있다.
• 인간은 모든 중간 단계를 직접 관리하기보다 목표와 통제 경계를 설정하고 최종 결과를 검증하는 책임자로 남아야 한다.
• 프로덕션 실패와 반복 작업 기록을 다음 자동화의 입력으로 활용하면 같은 유형의 문제에 적응하는 자가 개선 루프를 구축할 수 있다.

📈 투자·시사 포인트

• 금융 AI 기업을 평가할 때는 모델이나 GPU 보유량뿐 아니라 고객 데이터 연결, 티켓 처리, 테스트, 배포와 QA를 통합한 개발 하네스의 완성도를 함께 살펴볼 필요가 있다.
• 금융권에서는 변경 속도만큼 코드 검토, SOX 승인과 책임 추적을 보장하는 통제 구조가 중요하므로, 감사 가능한 인간 개입 설계가 도입의 핵심 조건이 된다.
• 여러 시스템의 상태를 단일 화면으로 압축하는 오케스트레이션 UX는 에이전트 수가 증가할수록 커지는 인간의 조율 비용을 낮추는 핵심 기반이 될 수 있다.
• 여러 고객에게 반복되는 문제와 사용 패턴을 축적·압축하는 능력은 자동화 루프를 개선하는 재사용 가능한 운영 자산으로 해석할 수 있다.

⚠️ 불확실하거나 확인이 필요한 부분

• 48GB 메모리의 MacBook에서 약 50개 worktree와 서브에이전트를 운용할 수 있다는 사례에는 작업별 자원 사용량, 처리 성능과 실패율을 비교할 수 있는 수치가 제시되지 않았다.
• 테스트, PR 검토와 스테이지 배포까지의 흐름은 설명되지만, 실제 프로덕션 배포 권한과 실패 시 롤백 책임의 경계는 구체적으로 제시되지 않았다.
• 고객별 사용 패턴을 수집해 시스템이 적응한다는 방향은 제시되지만, 데이터 품질을 평가하고 잘못된 학습을 차단하는 검증 방식은 확인이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 현재 Jira 접수부터 원인 조사, 수정, 테스트, 스테이지 배포와 QA 전달까지의 단계별 인간 개입 지점과 대기 시간을 측정한다.
• 서로 독립적인 버그 티켓을 별도 Git worktree와 서브에이전트에 배정하는 소규모 병렬 처리 실험을 진행한다.
• 로그·트레이스 수집, TDD, 종단 간 테스트, Docker 빌드와 스테이지 배포를 하나의 재현 가능한 워크플로로 연결한다.
• 에이전트 실행 상태, Kubernetes, 시스템 로그, Jira와 PR을 한 화면에서 확인할 수 있는 최소 오케스트레이션 UX를 설계한다.

❓ 열린 질문

• 한 명의 검증자가 품질과 책임성을 유지하면서 동시에 감독할 수 있는 서브에이전트와 작업의 상한은 어느 정도인가?
• 금융 소프트웨어의 어떤 변경까지 에이전트가 자동으로 진행할 수 있으며, 어느 단계부터 인간 감사자와 컨트롤러의 승인이 필요한가?
• 여러 고객의 반복 패턴을 수집·압축하면서 고객별 데이터 경계와 검증 가능성을 어떻게 유지할 것인가?