‘자는 동안 일하는 AI’의 진짜 엔지니어링: Opus 4.8 동적 워크플로와 병렬 서브에이전트를 뜯어봤습니다

개요

2026년 6월, “Opus 4.8로 자는 동안 돈을 버는 40가지 워크플로”라는 제목의 X 아티클이 개발자 타임라인을 한 차례 흔들었습니다. 제목만 보면 전형적인 패시브 인컴 마케팅이고, 실제로 그 프레이밍은 과장입니다. 다만 그 과장 아래에는 진짜로 작동하는 엔지니어링이 깔려 있습니다. 동적 워크플로, 병렬 서브에이전트 팬아웃, 그리고 그 결과를 합치기 전에 반드시 거치는 검증 게이트입니다.

이 글은 두 가지를 분리합니다. 먼저 “자는 동안 돈을 번다”는 표현에서 무엇이 마케팅이고 무엇이 실재인지 가려냅니다. 그다음 그 실재하는 부분, 즉 장시간 무인으로 도는 에이전트 팬아웃이 인프라 관점에서 어떤 수요를 만드는지를 다룹니다. ThakiCloud는 쿠버네티스 기반 AI/ML SaaS 플랫폼을 운영하며 GPU 워크로드 서빙을 핵심 제품으로 삼고 있기 때문에, “에이전트가 밤새 일한다”는 화제의 표면보다 그 밑에서 돌아가는 추론 워크로드의 청구 구조에 더 관심이 있습니다. 인용한 사실관계는 공개된 아티클 메타데이터에서 확인한 범위로 한정했고, 검증되지 않은 수익 주장은 그대로 옮기지 않았습니다.

‘자는 동안’ 워크플로의 정체: 무엇이 과장이고 무엇이 실재인가

원본 아티클은 @eng_khairallah1이 작성한 글이며, 한 사용자의 리트윗으로 다시 퍼졌습니다. 본문은 t.co 단축 링크가 X 아티클 한 편을 감싸고 있는 형태였습니다. 제목의 “돈을 번다”는 부분은 검증 대상이 아닙니다. 누가 얼마를 벌었는지에 대한 객관적 근거는 제시되지 않았고, 그런 수치는 본질적으로 재현이 불가능합니다. 그래서 그 부분은 마케팅 프레이밍으로 분류하는 것이 정확합니다.

마케팅을 걷어내고 나면 남는 기술적 핵심은 분명합니다. 첫째, 사람이 매 단계 키를 누르지 않아도 에이전트가 작업 목록을 스스로 분해해 진행한다는 것. 둘째, 독립적인 하위 작업을 여러 서브에이전트에 동시에 던져 병렬로 처리한다는 것. 셋째, 그 결과를 사람에게 내놓기 전에 다른 시각의 검증 단계를 한 번 더 거친다는 것입니다. 이 세 가지는 실재하며, ThakiCloud의 내부 운영 도구에서도 이미 같은 패턴을 사용하고 있습니다.

다시 말해 화제가 된 것은 “AI가 알아서 돈을 벌어준다”가 아니라 “에이전트가 장시간 무인으로 다단계 작업을 수행할 수 있게 됐다”는 사실입니다. 이 구분이 중요한 이유는, 후자가 인프라에 실제 부하를 만들기 때문입니다.

동적 워크플로와 병렬 서브에이전트

동적 워크플로의 골격은 단순합니다. 하나의 오케스트레이터가 큰 작업을 받아 여러 갈래로 나누고, 각 갈래를 서브에이전트에 위임한 뒤, 돌아온 결과를 모아 한 편의 정돈된 산출물로 합칩니다. 핵심은 갈래들이 서로 독립적일 때 동시에 돈다는 점입니다. 파일 10개를 각각 분석해야 한다면, 한 개씩 순서대로 읽는 대신 10개 갈래를 동시에 띄우고 가장 느린 갈래가 끝나는 시점에 전체가 끝납니다.

[ 오케스트레이터 ]
        |
        +--> [서브에이전트 A] 탐색·읽기 (저비용 모델)
        +--> [서브에이전트 B] 탐색·읽기 (저비용 모델)
        +--> [서브에이전트 C] 구현·요약 (중간 모델)
        |        ...수십 갈래 병렬...
        v
[ 수집 ] --> [ 검증 게이트 ] --> [ 합성 ] --> 정돈된 결과 1개

여기서 자주 오해하는 지점이 있습니다. 병렬화가 무조건 좋은 것이 아니라, 갈래 사이에 의존성이 없을 때만 이득이라는 점입니다. 뒤 단계가 앞 단계 모든 결과를 한꺼번에 봐야 한다면 그것은 장벽(barrier)이고, 장벽은 가장 느린 갈래를 모두가 기다리게 만듭니다. 잘 설계된 워크플로는 장벽을 최소화하고, 각 항목이 자기 속도로 파이프라인을 통과하도록 둡니다. ThakiCloud가 스킬과 파이프라인 설계에서 반복해 온 원칙, 즉 자유로운 구성을 검증된 골격에 채워 넣어 평균 품질을 끌어올린다는 원칙과 같은 맥락입니다.

루프를 닫는 검증 게이트

이 구조에서 가장 자주 빠지는 단계가 검증입니다. 그리고 그 누락이 품질 저하의 가장 흔한 원인입니다. 서브에이전트를 수십 개 띄우면 그만큼 그럴듯하지만 틀린 결과도 함께 늘어납니다. 그것을 거르지 않고 합치면 환각이 누적됩니다.

그래서 팬아웃은 반드시 검증 단계로 닫아야 합니다. 코드 산출물이라면 검증은 결정론적입니다. 테스트를 실제로 돌려 통과하지 못하면 다음 단계로 넘어가지 못하게 막으면 됩니다. 판단이나 리서치처럼 정답이 모호한 산출물이라면, 워커와는 다른 시각의 검증자 여러 명에게 “이 주장을 반증해 보라”고 시키고, 다수가 반증하면 그 결과를 버립니다. 핵심은 검증자가 작성자와 같은 프롬프트를 그대로 다시 도는 것이 아니라, 적대적이고 다른 렌즈여야 한다는 점입니다. 같은 질문을 다시 던지는 것은 검증이 아닙니다.

품질이 안 나올 때 사람들은 흔히 모델 등급부터 올리려 합니다. 그러나 더 흔한 원인은 모델이 약해서가 아니라 검증 단계가 아예 없어서입니다. 비싼 모델로 전부 교체하기 전에, 적대적 검증 게이트를 한 단계 추가하는 것이 비용 대비 효과가 훨씬 큽니다.

비용의 진실: 워커는 싸게, 게이트만 비싸게

“자는 동안 돈을 번다”는 표현이 감추는 진실은, 그 무인 실행에 실제 비용이 든다는 것입니다. 수십 개의 서브에이전트를 장시간 돌리면 토큰과 연산이 그만큼 소비됩니다. 과거 한 운영 사례에서는 단일 모니터링 세션이 하루 비용의 절반 이상을 차지한 적도 있었는데, 원인은 캐시 미스가 아니라 거대한 컨텍스트가 반복 턴마다 비싼 모델 단가로 곱해진 것이었습니다.

그래서 제대로 된 설계는 비용과 품질을 단계별로 분리합니다. 탐색·읽기·검색 같은 처리량 위주의 갈래는 가장 싼 모델에 맡기고, 구현·리뷰처럼 균형이 필요한 갈래는 중간 모델, 그리고 합성과 검증처럼 정확도가 임계인 단계만 가장 비싼 모델에 맡깁니다. 워커는 싸게, 게이트만 비싸게. 이 원칙을 지키지 않고 전 단계를 최상위 모델로 돌리면, 품질은 환상이고 비용만 폭증합니다.

또 하나의 함정은 무한 폴링입니다. 가격이나 상태를 주기적으로 들여다보는 모니터링을 에이전트 핫루프 안에 넣으면, 사람이 개입할 일이 없는데도 매 틱마다 비싼 추론이 발생합니다. 이런 반복 감시는 에이전트가 아니라 단순 스크립트와 스케줄러에 맡기고, 특이사항이 감지될 때만 사람이나 에이전트를 호출하는 것이 정답입니다. 무인 자동화의 경제성은 “에이전트를 더 오래 돌리는 것”이 아니라 “에이전트를 꼭 필요한 순간에만 부르는 것”에서 나옵니다.

ThakiCloud K8s AI/ML SaaS 플랫폼 적용 및 시사점

여기서부터가 ThakiCloud의 관심사입니다. 장시간 무인으로 도는 에이전트 팬아웃은, 인프라 입장에서 보면 곧 청구 가능한 GPU·연산 워크로드입니다. 수십 개의 서브에이전트가 동시에 추론을 호출하는 패턴은, 한 번의 짧은 채팅과는 전혀 다른 부하 프로파일을 만듭니다. 짧고 산발적인 요청이 아니라, 길고 폭발적인 동시 요청입니다.

ThakiCloud의 스택은 정확히 이 부하를 다루기 위해 구성돼 있습니다. 쿠버네티스 위에서 Kueue로 GPU 작업을 큐잉하고 공정하게 배분하며, vLLM으로 모델을 서빙하고, 멀티테넌트 환경에서 여러 고객의 에이전트 워크로드를 격리합니다. 에이전트가 팬아웃할 때 발생하는 동시 추론 폭증은 Kueue의 큐잉·우선순위 메커니즘으로 흡수하고, 워커와 게이트의 모델 등급 분리는 서빙 계층에서 서로 다른 모델 엔드포인트로 라우팅해 비용을 통제할 수 있습니다.

마케팅적으로 보면 이 지점이 온프레미스·소버린 AI 수요와 직결됩니다. 무인 에이전트가 코드베이스 전체를 훑고, 사내 문서를 읽고, 장시간 작업을 수행하려면 데이터가 외부 API로 끊임없이 흘러나가야 합니다. 보안 요구가 강한 조직, 특히 데이터 반출이 제약되는 환경에서는 이런 에이전트 워크로드를 자체 인프라 안에서 돌릴 수 있는지가 도입의 전제 조건이 됩니다. ThakiCloud가 self-hosting과 비용효율을 강조하는 이유가 여기에 있습니다. “자는 동안 일하는 에이전트”가 진짜 제품이 되려면, 그 에이전트가 도는 인프라가 통제 가능하고 청구 구조가 투명해야 합니다.

한계 및 반론

가장 강한 반론부터 적습니다. 동적 워크플로가 만능은 아닙니다. 단발성 질문이나 단일 파일 편집처럼 분해할 필요가 없는 작업에 팬아웃을 끼워 넣으면, 오케스트레이션 오버헤드만 늘고 결과는 더 나아지지 않습니다. 병렬화의 이득은 갈래가 진짜로 독립적일 때만 나오며, 의존성이 얽힌 작업을 억지로 병렬화하면 장벽 대기와 결과 충돌로 오히려 느려집니다.

둘째, 무인 실행은 검증 게이트가 부실하면 위험을 키웁니다. 사람이 매 단계를 보지 않는다는 것은, 틀린 결과가 조용히 다음 단계로 흘러갈 여지가 커진다는 뜻이기도 합니다. 비가역적인 변경, 예컨대 배포나 스키마 변경 같은 작업을 무인 루프에 그대로 맡기는 것은 신중해야 합니다. 검증과 사람의 승인 게이트가 함께 있어야 안전합니다.

셋째, “자는 동안 돈을 번다”는 서사 자체가 기대를 왜곡합니다. 이 기술이 실제로 줄여 주는 것은 사람의 반복 노동이지, 사람의 판단과 책임이 아닙니다. 무인 자동화가 늘어날수록 오히려 잘 설계된 검증 게이트와 비용 가드, 그리고 명확한 권한 경계의 가치가 커집니다. ThakiCloud가 인프라 계층에서 이 통제 가능성을 제공하려는 이유도 같습니다.

출처

• @eng_khairallah1, “40 Claude Opus 4.8 Workflows That Make Money While You Sleep” (X Article, 2026-06)
• 원 리트윗: x.com/hjguyhan/status/2069026741155442835