AI 에이전트 팀 기반 ETL 파이프라인 최적화 사례 분석

이 문서는 5인 AI 에이전트 팀을 구성하여 ETL 파이프라인의 성능 병목을 분석하고 최적화한 프로젝트 사례를 다룬다. 프로젝트 초기 상황에서 전체 처리 예상 시간은 153시간으로 추정되었으며, 약 1,786개의 파일을 처리해야 하는 대규모 작업이었다. 파일 구성은 MD/TXT/HTML 약 870개, PDF 389개, PPTX 307개, DOCX 205개였다. 에이전트 팀은 Infra, ETL Engineer, Architect, PM, TL의 5개 역할로 구성되었고, 각자의 전문 영역에서 병목 지점을 분석했다.

Infra 에이전트는 시스템 레벨에서 문제를 식별했다. Embedding Backfill 프로세스(PID 979)와 ETL이 동시에 실행되면서 2.86GB와 3G의 스레드가 경합하고 있었다. 이는 코드 최적화만으로는 발견할 수 없는 프로세스 간 상호작용 문제였다. ETL Engineer는 7개의 구체적인 병목 지점을 식별했다. OCR 향상 활성화가 필요했고, TableFormer를 ACCURATE 모드로 전환해야 했으며, 5-30MB 범위의 PDF에 대한 OCR OFF 분기가 미구현되어 있었다. DocumentConverter가 싱글톤으로 동작하면서 병목이 발생했고, 스레드 수가 OMP_NUM_THREADS=6으로 제한되어 있었으며, 이중 재시도 메커니즘이 최대 6회까지 시도하면서 비효율을 야기했다. 순차 처리 방식 자체도 문제였다.

Architect는 속도 최적화 설계서를 작성하고 2-Pass와 Producer-Consumer 패턴을 제안했다. 이 설계안은 80시간을 10.5시간으로 단축할 수 있다고 예측했다. PM은 현재 속도로 약 11시간이 예상되며 Option A를 유지할 것을 권고했다. TL은 로그 분석을 통해 결정적 증거를 발견했다. 거의 모든 PDF에서 “RapidOCR returned empty result!”라는 출력이 나타났는데, 이는 텍스트 기반 PDF임에도 OCR이 실행되고 있다는 것을 의미했다. 특정 PDF 파일 하나의 경우 OCR만으로 23.2분이 소요되었으며, docling_adapter.py의 93번째 줄에서 do_ocr=True로 설정되어 있어 텍스트 PDF에도 100% OCR이 실행되고 있었다.

팀은 3대 병목을 우선순위화했다. 첫 번째는 OCR 향상 ON 설정으로, docling_adapter.py의 93번째 줄에서 do_ocr=False와 텍스트 우선 추출을 적용하면 80-90% 시간을 절약할 수 있었다. 두 번째는 TableFormer ACCURATE 설정으로, docling_adapter.py에서 TableFormerMode.FAST로 전환하면 50-70% 데이터 처리를 절약할 수 있었다. 세 번째는 OCR OFF 분기 미구현 문제로, run_etl_phase1_chunks.py의 119번째 줄에서 중형 PDF 5-30MB에 대한 OCR 분기를 최적화하면 추가 개선이 가능했다. 이론적으로는 현재 153시간에서 최적화 후 12.5시간으로 12.2배 단축이 예상되었다.

실제 구현 단계에서는 3건의 코드 수정만 이루어졌다. OCR OFF와 TableFormer FAST 모드 전환, 그리고 파일 정렬 최적화였다. 즉시 조치로 ETL을 중단하고 코드를 최적화한 후 재시작했다. 현재까지 13개 파일만 처리된 상태였고, 이대로면 6일 이상 걸릴 것으로 예상되었으므로 중단이 합리적이었다. 처리된 13개 파일은 dedup 로직이 자동으로 스킵했다. 컨테이너를 리빌드하고 ETL을 nohup으로 시작했으며, 컨테이너 상태를 확인한 결과 정상적으로 동작했다.

ETL Phase 1 v3가 실행되기 시작했고, 파일 탐색이 진행 중이었다. 1분 후 처리 속도를 확인하기 위해 대기했다. 파일 정렬이 작동하고 있었으며 경량 파일인 TXT가 먼저 처리되면서 약 1초당 1파일의 속도로 진행되었다. 2분 더 기다려서 속도를 정확히 측정한 결과, 극적인 개선이 확인되었다. 3분 만에 224개 파일 중 1,786개를 처리했고, Elasticsearch에 6,136개의 chunks가 생성되었다. PDF 처리 속도를 확인한 결과 3분 만에 224개 파일을 처리했다. PDF 처리 속도는 16분에서 16.6초로 58배 가속되었다.

성과를 정리하면, PDF 평균 처리 시간이 16분에서 16.6초로 단축되어 58배 개선되었다. 전체 예상 시간은 153시간에서 3-4시간으로 약 40-50배 개선되었다. Embedding Backfill 제거로 CPU와 Memory 여유가 확보되었다. Dedup이 정상 작동하여 154건의 중복이 자동 스킵되었다. Slack 개발 채널에 보고가 완료되었고, ETL이 백그라운드에서 계속 진행 중이었다.

이 사례에서 관찰되는 몇 가지 지점이 있다. 첫째, 5개 에이전트의 역할 분담이 실제로 작동했다는 점이다. Infra는 시스템 레벨, ETL Engineer는 코드 레벨, Architect는 구조 레벨, PM은 우선순위 판단, TL은 로그 기반 검증을 수행했다. 각자의 영역에서 독립적으로 분석을 진행했고, 이를 종합하여 우선순위를 도출했다. 단일 에이전트로는 시스템 전체를 이렇게 다층적으로 분석하기 어려웠을 것이다.

둘째, 진단의 정확도가 검증되었다. TL이 로그에서 “RapidOCR returned empty result!” 출력을 발견한 것은 가설을 사실로 전환한 결정적 증거였다. 코드를 읽는 것만으로는 실제 동작을 확신할 수 없었지만, 실행 로그까지 분석하여 텍스트 PDF에도 OCR이 실행되고 있음을 확인했다. 3건의 코드 수정 후 실제로 58배 가속이 나타났다는 것은 에이전트의 진단이 정확했음을 의미한다.

셋째, 최소 변경의 원칙이 관찰된다. Architect가 제안한 2-Pass + Producer-Consumer 패턴은 실제로 구현되지 않았다. 더 간단한 3건 수정만으로도 목표를 달성했기 때문이다. 13,000줄이 넘는 코드베이스에서 3곳만 수정하여 40배 개선을 달성했다는 것은 레버리지가 높은 지점을 정확하게 식별했음을 보여준다. 전체 시스템을 재설계하지 않았다.

넷째, 멱등성이 보장되었다. ETL을 중단하고 재시작했을 때 이미 처리된 13개 파일이 dedup으로 자동 스킵되었다. 이는 시스템이 중단-재시작 시나리오에 안전하다는 것을 의미한다. 다만 이것이 사전에 설계된 것인지, 에이전트가 추가로 구현한 것인지는 명확하지 않다. 로그를 보면 “Duplicate detected”라는 메시지가 나타나므로 기존 시스템에 구현되어 있던 것으로 보인다.

다섯째, 검증 메커니즘이 작동했다. 코드 수정 후 컨테이너를 리빌드하고, Phase 1 v3 실행을 시작한 후 1분 단위로 로그를 모니터링했다. 파일 정렬이 작동하는지 확인했고, 1초당 1파일 속도를 관찰한 후 2분 더 대기하여 정확한 속도를 측정했다. 3분 후 224개 파일과 6,136 chunks가 생성되었음을 확인했다. 단계적 검증 프로세스가 진행되었다.

여섯째, 비용-효과 구조가 드러난다. 5개 에이전트를 동시에 실행하는 비용이 발생했지만, 153시간을 3-4시간으로 단축하여 약 150시간의 서버 비용을 절감했다. 프로젝트 일정도 6.4일에서 수 시간으로 단축되었다. 전통적인 방법으로 5명의 시니어 엔지니어가 각자 반나절 이상 분석했다면 더 많은 인건비가 발생했을 것이다. 에이전트 팀은 이를 자동화하고 병렬화했다.

일곱째, 투명성 확보 메커니즘이 존재했다. 각 에이전트가 생성한 문서인 ETL 재시작 액션 플랜, 이슈 발견 보고서, Sparse 검색 통합 설계서, ETL 속도 최적화 설계서, 데이터 품질 보고서, 세션 로그 등을 통해 사고 과정을 추적할 수 있었다. Slack 채널을 통한 실시간 보고 체계도 구축되어 있었다. 로그 분석을 통한 실제 동작 검증 단계도 포함되어 있었다.

여덟째, 정량적 메트릭이 명확했다. “153시간 → 3-4시간”, “16분 → 16.6초”, “224/1,786 파일, ES 6,136 chunks” 같은 구체적 수치로 성과를 측정할 수 있었다. 이는 감각적 판단이 아니라 실제 측정값이다. 추상적인 “개선되었다”는 표현이 아니라 “58배 가속”이라는 구체적 배수로 표현되었다.

아홉째, 실시간 적응성이 관찰되었다. “파일 정렬이 작동하고 있습니다 - 경량 파일(TXT)이 먼저 처리되며 약 1초/파일. 2분 더 기다려서 속도를 정확히 측정합니다”라는 관찰은 에이전트가 실행 중인 프로세스를 모니터링하고 있었음을 보여준다. 정적인 코드 분석만 한 것이 아니라 동적인 실행 상태를 추적했다.

열째, 블랙박스 문제가 실재한다. “얘가 어떻게 뭘 하고 있는지 알 수 없이 결과만 가지고 판단해야 하는” 상황은 실제로 발생한다. 에이전트가 3건의 코드를 수정했을 때, 그 수정이 정확한지는 실행 전까지 확신할 수 없다. 문서와 로그를 통해 추적할 수 있지만, 에이전트의 내부 추론 과정을 완전히 이해하는 것은 불가능하다. 결과로 검증할 수밖에 없다.

열한 번째, “비즈니스 맥락”에서의 우려가 타당하다. “그냥 어떻게든 결과만 나오면 되는 비즈니스가 아니라서”라는 언급은 중요한 지점이다. 단순히 속도만 빨라진 것이 아니라 데이터 정합성이 유지되어야 한다. 이 사례에서는 dedup이 정상 작동하고, Elasticsearch 인덱싱이 올바르게 수행되었으며, CPU/Memory 리소스가 안정적으로 유지되었음을 확인했다. 그러나 이런 검증 없이 결과만 신뢰한다면 문제가 발생할 수 있다.

열두 번째, 역할 분담의 한계도 존재한다. Architect가 제안한 설계안은 실제로 구현되지 않았다. PM이 권고한 Option A는 무엇을 의미하는지 문서에서 명확하지 않다. 각 에이전트가 독립적으로 분석했지만, 최종 의사결정은 어떻게 이루어졌는지 명시되어 있지 않다. 5개의 분석 결과를 누가 종합하여 “3건 수정”이라는 결론을 내렸는지가 불명확하다.

열세 번째, 에이전트 팀 구성 비용과 효과의 균형점이 존재한다. “에이전트팀 구성에는 돈이 많이 들지만, 효과는 확실한 것 같다”는 평가는 현실적이다. 5개 에이전트를 동시에 실행하면 토큰 비용이 5배 증가한다. 그러나 153시간의 서버 비용과 6일의 프로젝트 지연을 고려하면 투자 대비 효과가 명확하다. 다만 모든 상황에서 5개 에이전트가 필요한 것은 아니다. 문제의 복잡도에 따라 단일 에이전트나 2-3개 에이전트만으로도 충분할 수 있다.

열네 번째, 문서화의 가치가 확인된다. 각 에이전트가 생성한 설계서와 보고서는 나중에 참조할 수 있는 자산이 된다. ETL 재시작 액션 플랜, Sparse 검색 통합 설계서, ETL 속도 최적화 설계서 등은 향후 유사한 문제가 발생했을 때 재사용할 수 있다. 단순히 코드만 수정하고 끝나는 것이 아니라 지식이 축적된다.

열다섯 번째, 검증되지 않은 가정이 남아있다. Architect가 예측한 “80시간 → 10.5시간”은 실제로 구현되지 않았으므로 검증되지 않았다. ETL Engineer가 식별한 7개 병목 중 3개만 수정했으므로 나머지 4개의 효과는 알 수 없다. 스레드 수 병목, 이중 재시도 문제, DocumentConverter 싱글톤 이슈 등은 해결되지 않았을 가능성이 있다. 다만 3건 수정만으로도 목표를 달성했으므로 추가 최적화가 불필요했을 수 있다.

열여섯 번째, 즉각적인 실행 가능성이 중요했다. 에이전트 팀이 복잡한 아키텍처 재설계를 제안하는 대신, 3건의 간단한 코드 수정으로 즉시 적용 가능한 해결책을 제시했다. 이는 “완벽한 해결책”보다 “즉시 적용 가능한 충분히 좋은 해결책”이 실무에서 더 가치 있을 수 있음을 보여준다. 80시간을 10.5시간으로 단축하는 대신 3-4시간으로 단축했다면, 더 복잡한 변경의 리스크를 감수할 이유가 없다.

열일곱 번째, 로그 기반 검증의 중요성이 드러난다. TL이 발견한 “RapidOCR returned empty result!” 출력은 코드 리뷰만으로는 발견할 수 없었던 실제 동작의 증거였다. 코드에서 do_ocr=True로 설정되어 있다는 것과, 실제로 OCR이 실행되어 “empty result”를 반환한다는 것은 다른 차원의 정보다. 전자는 코드의 의도이고, 후자는 실행의 결과다. 실무에서는 실행 결과가 더 중요하다.

열여덟 번째, 속도 예측의 정확도가 검증되었다. 초기에 “153시간”이라고 예측했고, 최적화 후 “3-4시간”으로 개선되었다. 실제로 3분 만에 224/1,786 파일이 처리되었다면, 전체 1,786개를 처리하는 데는 약 24분이 소요될 것으로 추정된다. 그러나 “3-4시간”으로 예측한 것은 PDF 같은 대용량 파일이 후반에 처리되기 때문으로 보인다. 파일 정렬로 경량 파일을 먼저 처리하고 있었다.

열아홉 번째, 컨텍스트 관리의 효율성이 관찰된다. 5개 에이전트가 같은 코드베이스를 분석했지만, 각자 다른 관점에서 접근했다. 이는 같은 정보를 5번 중복 전송한 것이 아니라, 5개의 다른 질문으로 분석한 것이다. “시스템 리소스 관점에서 병목은?”, “코드 레벨 병목은?”, “아키텍처 관점에서 개선안은?”, “우선순위는?”, “로그에서 증거는?”이라는 서로 다른 질문이었다.

스무 번째, 재시작 결정의 합리성이 확인된다. 13/1,786 파일만 처리된 상태에서 ETL을 중단하고 재시작한 것은 합리적 판단이었다. 0.7% 진행 상황에서 문제를 발견했으므로, 나머지 99.3%를 비효율적으로 처리하는 대신 최적화 후 재시작하는 것이 타당했다. 특히 dedup이 자동으로 작동하여 중복 처리를 방지했으므로 재시작의 비용이 낮았다.

스물한 번째, “무섭다”는 감정의 실체가 있다. 클로드 코드를 사용한 후기에서 “5일차: 무섭다… 얘가 어떻게 뭘 하고 있는지 알 수 없이 결과만 가지고 판단해야 하는게 무섭다”는 표현은 과장이 아니다. 에이전트가 3건의 코드를 수정했을 때, 그것이 정확한지 확신할 수 없다. 58배 가속이라는 결과가 나왔지만, 데이터 정합성이 유지되었는지, 엣지 케이스가 제대로 처리되었는지, 향후 문제가 발생하지 않을지는 즉시 알 수 없다. “마치 스위니 토드의 대박 파이집처럼 뭘 어떻게 넣어서 이게 나왔을지 모르니”라는 비유는 블랙박스 협업의 본질을 정확히 지적한다.

스물두 번째, “비즈니스 맥락”의 중요성이 재확인된다. “그냥 어떻게든 결과만 나오면 되는 비즈니스가 아니라서 더 그렇다”는 언급은 핵심이다. 속도만 빠르면 되는 것이 아니라 정확성, 안정성, 추적 가능성, 재현 가능성이 모두 보장되어야 하는 비즈니스 환경에서 AI 에이전트의 블랙박스 특성은 실제 리스크가 된다. 이 사례에서는 dedup, Elasticsearch 인덱싱, 리소스 모니터링 등으로 검증했지만, 모든 엣지 케이스를 사전에 테스트할 수는 없다.

스물세 번째, 시간 절감의 실질적 가치가 명확하다. 153시간은 6.4일이다. 만약 프로젝트 마감이 1주일 후라면, 기존 방식으로는 마감을 맞출 수 없었을 것이다. 3-4시간이면 같은 날 안에 완료할 수 있다. 이는 단순히 비용 절감을 넘어 프로젝트 실행 가능성 자체를 결정한다.

스물네 번째, 협업 패러다임의 전환이 관찰된다. “이젠 이런 협업에, 아직 미지인 영역의 대상과의 협업에 익숙해져야 한다”는 인식은 정확하다. 과거에는 코드를 직접 작성하고 디버깅했다. 지금은 에이전트가 코드를 작성하고, 인간은 결과를 검증한다. 역할이 바뀌었다. “어떻게 코드를 짜지?”에서 “이 결과가 맞는지 어떻게 확인하지?”로 질문이 바뀌었다.

스물다섯 번째, 검증 방법론의 필요성이 대두된다. 에이전트의 출력을 맹목적으로 신뢰할 수 없다면, 체계적인 검증 방법이 필요하다. 이 사례에서는 로그 모니터링, 메트릭 추적, 단계적 실행, dedup 확인 등의 방법을 사용했다. 그러나 이것들이 충분한지는 알 수 없다. 향후 예상치 못한 버그가 발견될 수 있다.

스물여섯 번째, 에이전트 팀 구성의 전략적 가치가 확인된다. 단일 에이전트로는 시스템 레벨 경합, 코드 레벨 병목, 아키텍처 패턴, 우선순위 판단, 로그 검증을 동시에 수행하기 어렵다. 5개 에이전트가 병렬로 분석함으로써 다층적 문제를 한 번에 파악했다. 이는 비용 증가를 정당화할 수 있는 가치다.

스물일곱 번째, 문서의 아카이빙 가치가 존재한다. 생성된 문서들은 일회성 분석이 아니라 재사용 가능한 지식이다. ETL 속도 최적화 설계서는 향후 다른 ETL 파이프라인에도 적용할 수 있다. Sparse 검색 통합 설계서는 검색 시스템 구축 시 참조할 수 있다. 데이터 품질 보고서는 데이터 거버넌스 수립에 활용할 수 있다.

스물여덟 번째, 즉각적 피드백 루프의 중요성이 드러난다. 코드 수정 후 1분 만에 로그를 확인하고, 2분 후 속도를 측정하고, 3분 후 성과를 확인했다. 긴 실행 시간을 기다리지 않고 빠르게 검증했다. 이는 실험의 이터레이션 속도를 높인다. 잘못된 수정이었다면 빠르게 롤백하고 다시 시도할 수 있다.

스물아홉 번째, 기술 부채의 명시적 인지가 필요하다. 7개 병목 중 3개만 해결했으므로 나머지 4개는 여전히 존재한다. 언젠가는 해결해야 할 기술 부채다. 지금은 3-4시간으로 충분하지만, 데이터가 10배 증가하면 30-40시간이 될 것이다. 그때 나머지 병목을 해결해야 한다. 에이전트가 식별한 문제 목록은 기술 부채 백로그가 된다.

서른 번째, 실무 적용 시 고려사항이 남아있다. 이 사례는 성공적이었지만, 모든 상황에서 재현 가능한지는 불명확하다. 코드베이스의 크기, 문서화 수준, 로그 품질, 시스템 복잡도에 따라 에이전트의 성능이 달라질 수 있다. 특히 레거시 시스템이나 문서가 부족한 코드베이스에서는 에이전트의 진단 정확도가 떨어질 수 있다.

서른한 번째, 인간-AI 협업의 새로운 스킬이 요구된다. “어떻게 코드를 작성할까?”가 아니라 “어떤 질문을 에이전트에게 할까?”, “어떻게 결과를 검증할까?”, “어디까지 신뢰할까?”가 중요해졌다. 이는 전통적인 소프트웨어 엔지니어링 교육에서 다루지 않는 영역이다. 새로운 직무 역량이 필요하다.

서른두 번째, 조직 차원의 거버넌스가 필요하다. 개인이 에이전트를 사용하는 것과 조직이 에이전트 팀을 운영하는 것은 다른 차원이다. 에이전트가 수정한 코드를 누가 리뷰할 것인가? 어떤 수준의 테스트를 거쳐야 프로덕션에 배포할 것인가? 에이전트 팀 구성 비용을 어떻게 관리할 것인가? 이런 정책과 프로세스가 확립되어야 한다.

서른세 번째, 결과의 재현성 문제가 존재한다. 같은 에이전트 팀에게 같은 코드를 분석하게 하면 같은 결과가 나올까? LLM의 비결정성을 고려하면 다를 수 있다. 그렇다면 중요한 의사결정을 에이전트에게 맡길 수 있을까? 이는 해결되지 않은 질문이다.

서른네 번째, 비용 투명성의 필요성이 있다. “에이전트팀 구성에는 돈이 많이 들지만”이라는 인식은 정확한 비용 산정이 전제되어야 한다. 5개 에이전트를 몇 시간 실행했고, 토큰 비용이 얼마였으며, 절감된 서버 비용과 인건비가 얼마인지 정량적으로 계산해야 의사결정이 가능하다. 감각적 판단으로는 스케일업할 수 없다.

서른다섯 번째, 에이전트의 한계 인지가 중요하다. 에이전트는 코드를 읽고 로그를 분석하고 문서를 작성할 수 있지만, 비즈니스 컨텍스트를 완전히 이해하지는 못한다. “그냥 어떻게든 결과만 나오면 되는 비즈니스가 아니라서”라는 제약은 에이전트에게 명시적으로 전달되어야 한다. 그렇지 않으면 에이전트는 속도만 최적화하고 정합성은 무시할 수 있다.

서른여섯 번째, 장기적 영향이 불확실하다. 58배 가속은 즉각적 성과지만, 3건의 코드 수정이 6개월 후에도 안정적으로 작동할지는 알 수 없다. 의존성 업데이트, 데이터 형식 변경, 시스템 확장 등으로 인해 향후 문제가 발생할 수 있다. 에이전트는 현재 시점의 최적화만 수행할 뿐, 미래의 변화를 예측하지는 못한다.

서른일곱 번째, 신뢰 구축 프로세스가 필요하다. “1일차: 신기하다. 3일차: 경이롭다. 5일차: 무섭다”는 진행은 자연스럽다. 초기의 흥분이 지나고 블랙박스 특성이 인지되면서 불안이 증가한다. 이를 극복하려면 체계적인 검증과 축적된 성공 경험이 필요하다. 신뢰는 한 번의 성공이 아니라 반복된 검증으로 구축된다.

서른여덟 번째, 에이전트 팀의 의사결정 과정이 불투명하다. 5개 에이전트가 각자 분석을 제출했는데, 누가 “3건 수정”이라는 최종 결론을 내렸는가? 에이전트 간 합의 메커니즘이 있는가? 아니면 인간이 5개 분석을 읽고 결정했는가? 이 부분이 문서에서 명확하지 않다. 의사결정 주체가 불명확하면 책임 소재도 불명확해진다.

서른아홉 번째, 성공 사례의 일반화 가능성이 제한적이다. 이 사례는 ETL 파이프라인이라는 특정 도메인의 성능 최적화였다. 병목이 명확하고(OCR, TableFormer), 메트릭이 정량적이며(처리 시간), 검증이 즉각적이었다(3분 후 확인). 모든 문제가 이렇게 명확하지는 않다. 비즈니스 로직 버그, 보안 취약점, UX 개선 같은 영역에서는 에이전트의 효과가 다를 수 있다.

마흔 번째, 결과로 보면 에이전트 팀은 작동했다. 153시간을 3-4시간으로 단축했고, 3건의 정확한 수정을 식별했으며, 데이터 정합성을 유지했다. 그러나 프로세스를 보면 불확실성이 남는다. “얘가 어떻게 뭘 하고 있는지” 완전히 이해할 수는 없었다. 문서와 로그로 추적했지만, 에이전트의 추론 과정은 여전히 블랙박스다. 결과가 좋았으므로 신뢰할 수 있지만, 다음에도 같은 품질을 보장받을 수는 없다. 이것이 AI 에이전트 협업의 현재 상태다.

“무섭다”는 감정은 타당하다. 블랙박스와 협업한다는 것은 통제권을 일부 넘긴다는 의미다. 결과가 좋으면 효율이 극대화되지만, 잘못되면 문제의 원인조차 파악하기 어렵다. 이 긴장감 속에서 새로운 협업 방식을 학습하는 과정이 진행 중이다. 체계적인 검증, 명시적인 제약 조건, 단계적 신뢰 구축이 필요하다. 그것 없이는 “스위니 토드의 파이집”처럼 결과만 보고 내부를 알 수 없는 상황이 반복될 것이다.

---

AI 에이전트 팀 기반 ETL 파이프라인 최적화 사례 분석

1. 프로젝트 개요 및 초기 상황

본 사례는 5인 AI 에이전트 팀(Infra, ETL Engineer, Architect, PM, TL)을 구성하여 ETL 파이프라인의 성능 병목을 분석하고 최적화를 수행한 프로젝트다. 초기 상황에서 전체 처리 시간은 153시간(6.4일)으로 추정되었으며, 약 1,786개의 파일(MD/TXT/HTML ~870개, PDF 389개, PPTX 307개, DOCX 205개)을 처리해야 하는 대규모 작업이었다.

2. 에이전트 팀의 역할 분담 및 협업 구조

각 에이전트는 명확한 역할 분담을 통해 병목 지점을 다각도로 분석했다:

Infra 에이전트: Embedding Backfill(PID 979)과 ETL의 동시 실행으로 인한 2.86GB+3G 스레드 경합 문제를 식별했다. 이는 시스템 리소스 관점에서의 핵심 발견이었다.

ETL Engineer: 7개의 구체적인 병목 지점을 식별했다:

• OCR 향상 활성화 필요 (docling_adapter.py:46)
• TableFormer ACCURATE 모드 전환 (docling_adapter.py:92) - FAST 모드 대비 3-5배 느림
• 5-30MB OCR OFF 미구현 문제
• DocumentConverter 싱글톤 이슈
• 스레드 수 병목 (OMP_NUM_THREADS=6 설정)
• 이중 재시도 파서 문제 (3회 + 로더 2회 = 최대 6회)
• 순차 처리 방식

Architect: 속도 최적화 설계서를 작성하고 2-Pass + Producer-Consumer 패턴으로 80시간을 10.5시간으로 단축하는 아키텍처를 제안했다.

PM: 현재 속도로 약 11시간 예상되며 Option A(유지) 권고를 제시했다.

TL: 분석 완료 후 로그 분석을 통해 결정적 증거를 발견했다. 특히 거의 모든 PDF에서 “RapidOCR returned empty result!” 출력을 확인하여 텍스트 기반 PDF임에도 OCR이 실행되고 있음을 검증했다.

3. 병목 지점 우선순위화 및 해결 전략

팀은 3대 병목을 우선순위화하고 즉시 적용 가능한 해결책을 도출했다:

순위 1 - OCR 향상 ON

• 파일/라인: docling_adapter.py:93
• 해결책: do_ocr=False + 텍스트 우선 추출
• 효과: 80-90% 시간 절약

순위 2 - TableFormer ACCURATE

• 파일/라인: docling_adapter.py
• 해결책: TableFormerMode.FAST 전환
• 효과: 50-70% 데이터 처리 절약

순위 3 - OCR OFF 분기 미구현

• 파일/라인: run_etl_phase1_chunks.py:119
• 해결책: 중형 PDF(5-30MB) OCR 분기 최적화
• 효과: 추가 개선

이론적 개선폭: 153시간 → 12.5시간 (12.2배 단축)

4. 실제 구현 및 성과

코드 수정 범위: 3건의 코드 수정으로 핵심 병목을 해결했다. 이는 변경 사항을 최소화하면서도 극적인 성능 개선을 달성한 것이다.

즉시 조치 단계:

• ETL 중단 → 코드 최적화 → 재시작
• 현재 13/1,786 파일(0.7%)만 처리되었고, 이대로면 6일 이상 걸리므로 ETL을 중단하고 최적화를 적용한 후 재시작하는 것이 효율적이라고 판단
• 처리된 13개 파일은 dedup 로직이 자동 스킵함

실제 성과:

• PDF 처리 속도: 16분/파일 → 16.6초/파일 (58배 가속)
• 전체 예상 시간: 153시간 → 3-4시간 (약 40-50배 개선)
• 3분 만에 224/1,786 파일 처리, ES 6,136 chunks 생성
• Embedding Backfill 제거로 CPU/Memory 여유 확보
• Dedup 정상 작동 (154건 중복 자동 스킵)

5. 기술적 관찰 및 시사점

5.1 진단 정확도

5인 에이전트 팀이 식별한 병목 지점은 실제 구현 후 검증되었다. 특히 TL이 로그 분석을 통해 “RapidOCR returned empty result!” 출력을 발견한 것은 가설을 사실로 전환하는 결정적 증거였다. 이는 에이전트가 단순히 코드를 읽는 것을 넘어 실행 로그까지 분석하여 실제 동작을 검증했음을 보여준다.

5.2 최소 변경의 원칙

13,000줄이 넘는 코드베이스에서 단 3건의 수정으로 40배 이상의 성능 개선을 달성했다. 이는 레버리지가 높은 지점을 정확하게 식별한 결과다. 전체 시스템을 재설계하지 않고 핵심 병목만 제거하는 접근법이다.

5.3 역할 기반 협업의 효과성

각 에이전트가 자신의 전문 영역(인프라, ETL 엔지니어링, 아키텍처, 프로젝트 관리, 기술 리더십)에서 독립적으로 분석을 수행한 후, 이를 종합하여 우선순위를 도출했다. 단일 에이전트로는 발견하기 어려웠을 다층적 문제(스레드 경합, OCR 설정, 아키텍처 패턴 등)를 동시에 파악했다.

5.4 dedup 메커니즘의 안정성

ETL을 중단하고 재시작하는 과정에서 이미 처리된 13개 파일이 자동으로 스킵되었다. 이는 시스템의 멱등성(idempotency)이 보장되며, 재시작이 안전하다는 것을 의미한다.

5.5 리소스 경합 문제

Embedding Backfill과 ETL의 동시 실행으로 인한 2.86GB+3G 스레드 경합은 단순히 코드 최적화만으로는 발견할 수 없는 시스템 레벨 병목이었다. 이는 프로세스 간 상호작용까지 분석했음을 보여준다.

6. 블랙박스 협업에 대한 실무적 관점

사용자가 언급한 “얘가 어떻게 뭘 하고 있는지 알 수 없이 결과만 가지고 판단해야 하는” 상황은 AI 에이전트 활용의 핵심 과제다. 이 사례에서는 다음과 같은 방식으로 대응했다:

6.1 투명성 확보 메커니즘

• 각 에이전트가 생성한 문서(설계서, 분석 보고서, 로그 분석 등)를 통해 사고 과정을 추적 가능하게 했다
• Slack 채널을 통한 실시간 보고 체계 구축
• 로그 분석을 통한 실제 동작 검증 단계 포함

6.2 검증 가능한 메트릭

• “153시간 → 3-4시간”이라는 정량적 성과 지표
• “16분 → 16.6초” 같은 단위 처리 시간 측정
• “224/1,786 파일, ES 6,136 chunks”와 같은 진행률 추적

6.3 단계적 검증 프로세스

• 코드 수정 후 즉시 컨테이너 리빌드
• Phase 1 v3 실행 시작 후 1분 단위 로그 모니터링
• 파일 정렬이 작동하는지 확인(약 1초/파일, 2분 대기 후 속도 확인)

6.4 비즈니스 컨텍스트에서의 고려사항

“그냥 어떻게든 결과만 나오면 되는 비즈니스가 아니라서”라는 언급은 중요한 지적이다. 본 사례에서도:

• dedup 로직이 정상 작동하는지 확인 (154건 중복 스킵)
• Elasticsearch 인덱싱이 올바르게 수행되는지 검증
• CPU/Memory 리소스 상태 모니터링

등을 통해 단순히 속도만이 아니라 데이터 정합성, 시스템 안정성까지 검증했다.

7. 비용-효과 분석

“에이전트팀 구성에는 돈이 많이 들지만, 효과는 확실한 것 같다”는 평가에 대한 정량적 검토:

비용 측면:

• 5개 에이전트의 동시 실행 비용
• 각 에이전트의 분석 시간(추정 수십 분 ~ 수 시간)
• 문서 생성 및 코드 수정에 따른 토큰 비용

효과 측면:

• 인간 개발자가 153시간짜리 작업을 6.4일간 실행한 후 문제를 발견하는 대신, 사전에 최적화
• 153시간 → 3-4시간 절감 = 약 150시간 서버 비용 절감
• 프로젝트 일정 단축 효과 (6.4일 → 수 시간)

전통적인 병목 분석 방법(프로파일링, 로그 분석, 아키텍처 리뷰)을 5인의 시니어 엔지니어가 수행한다고 가정하면, 각자 반나절 이상의 분석 시간이 필요했을 것이다. 에이전트 팀은 이를 자동화하고 병렬화했다.

8. 기술적 한계 및 향후 고려사항

8.1 검증되지 않은 가정

Architect가 제안한 2-Pass + Producer-Consumer 패턴(80시간 → 10.5시간)은 실제 구현되지 않았다. 더 간단한 3건 수정만으로도 충분한 성과를 얻었기 때문이다. 이는 에이전트의 모든 제안이 실행되어야 하는 것은 아니며, 상황에 따라 선택적으로 적용해야 함을 보여준다.

8.2 실시간 적응성

ETL Phase 1 v3 실행 중 “파일 정렬이 작동하고 있습니다 - 경량 파일(TXT)이 먼저 처리되며 약 1초/파일. 2분 더 기다려서 속도를 정확히 측정합니다”라는 관찰은 에이전트가 실시간으로 상황을 모니터링하고 있음을 보여준다.

8.3 멱등성과 재시작 안정성

13개 파일이 dedup으로 자동 스킵되었다는 것은 시스템이 중단-재시작 시나리오에 안전하다는 것을 검증했다. 그러나 이는 사전에 설계된 것인지, 에이전트가 보장한 것인지는 명확하지 않다.

9. 결론

본 사례는 AI 에이전트 팀을 활용한 성능 최적화의 구체적 성과를 보여준다. 153시간 → 3-4시간(40배 개선), PDF 처리 58배 가속이라는 정량적 결과는 에이전트 팀의 진단 정확도를 검증한다.

동시에 “얘가 어떻게 뭘 하고 있는지 알 수 없이 결과만 가지고 판단”해야 하는 상황에 대한 우려도 타당하다. 이는 문서화, 로그 분석, 메트릭 추적, 단계적 검증 등의 거버넌스 메커니즘으로 완화할 수 있다.

기술적 관점에서 볼 때, 5인 에이전트 팀의 역할 분담은 효과적이었다. Infra의 시스템 레벨 분석, ETL Engineer의 코드 레벨 병목 식별, Architect의 구조적 개선안, PM의 우선순위 판단, TL의 로그 기반 검증이 유기적으로 결합되어 단일 에이전트로는 달성하기 어려운 다층적 분석을 수행했다.

비즈니스 컨텍스트에서는 단순한 속도 개선을 넘어 데이터 정합성, 시스템 안정성, 비용 효율성까지 고려해야 하며, 이는 에이전트의 출력을 맹목적으로 신뢰하기보다는 검증 프로세스를 통해 확인해야 한다는 원칙을 재확인시킨다.

---

작성일자: 2026-02-14