작별합니다. 기업용 대규모 분산 앱 개발을 위한 Vibe Coding 오케스트레이터. 환영합니다, 요구 정의 주도 개발

최근 저는 **HVE(Hypervelocity Engineering)**라는 시스템을 만들어 왔습니다.

이것은 GitHub Copilot에게 요구 정의, 설계, 구현, 문서 생성을 Workflow와 DAG로 단계적으로 실행시키는, 일종의 '자작 오케스트레이터'입니다.

처음 만들었을 때는 Copilot 본체에 '중간에 멈추지 않고 계속하기', '태스크를 분할하여 병렬로 흐르게 하기', '계획을 사람이 승인하기' 같은 기능이 거의 없었습니다. 그래서 외부에서 모든 것을 관리해야만 했습니다.

그런데 최근 들어 솔직히 말해 위화감이 커지고 있습니다.

• Copilot 본체에 Autopilot, /fleet, hooks, cloud agent의 계획 승인(plan approval), Automations가 추가되었고 - 제가 직접 측정한 결과, HVE의 DAG 부분을 분리한 ATG(Autonomous Task Graph)는 단일 Prompt보다 더 좋은 결과를 단 한 번도 내지 못했습니다. - 그런데도 HVE 본체는 Python만으로 수십만 줄에 달하며, 유지보수 부담은 확실히 늘어나고 있습니다.

'이걸 계속 직접 만들 의미가 있을까?'라는 의문이 들었습니다.

그래서 HVE의 개발 및 사용을 중단하고, 다음 5단계로 기업용 대규모 분산 앱을 구축하는 방침을 검토했습니다.

• 요구 정의 초안을 Microsoft 365 Copilot / Work IQ로 작성합니다.

• 초안을 Prompt P-RD(RequirementDefinition作成)를 이용해 요구 정의로 만듭니다. - Prompt P-FR(RD-FR_Prompt)을 애자일(Agile)의 웨이브(Wave)별로 반복 실행합니다. - Wave 1은 로컬 환경에서만 진행하고, - Wave 2에서는 Azure, 스마트폰, Power Platform으로 확장합니다.

• Prompt P-ST(SystemTest-Run)를 이용해 시스템 테스트를 반복 실행합니다. - 사람의 작업은 UAT(User Acceptance Testing)에만 국한하고, 그때마다 3단계와 4단계를 반복합니다.

전제 조건으로, GitHub Copilot이 Plugin / MCP를 통해 클라우드 서비스에 대한 인증 및 권한 부여는 완료된 상태라고 가정합니다.

본 기사는 이러한 방침이 정말 타당한지 여부를 과거의 실측값, 공식 문서, 외부 논문을 검증하여 정리한 내용입니다.

먼저 몇 가지 밝힙니다.

• 본 기사는 개인적인 견해이며, 소속 조직의 공식 입장이 아닙니다. - 본 기사를 위한 새로운 실험은 진행하지 않았습니다. 수치는 제가 과거에 수행했던 검증의 실측값이거나, 손에 남아있던 Copilot 세션 기록 및 Git 기록을 집계한 값이거나, 외부 자료에 적혀있는 값입니다. - 과거 실측은 3개 태스크, 각 n=2~3, 신규 생성 건만으로 규모가 상당히 작습니다. 기업의 대규모 분산 앱에 그대로 일반화할 수는 없습니다. - 검토 결과 수정된 3가지 Prompt는 아직 실제 업무 애플리케이션에서 구동되지 않았습니다. 프로덕션 환경에서 바로 사용하는 것은 권장하지 않습니다. - Copilot의 기능, 모델명, 기본값은 2026-10-03 시점을 기준으로 공식 문서를 확인한 것입니다. 변경될 수 있다는 전제하에 읽어주십시오.
• 과거에 만든 앱은 이름, 업종, 고객이 특정되지 않도록 '앱 A~D', '앱 X' 등으로 작성하고 개요만 남겼습니다.

본문에서는 다음 3가지를 구분하여 사용합니다.

• 사실: 자료/실측/공식 문서에서 확인한 내용 -
  추론: 사실로부터 제가 판단한 내용 -
  미검증: 아직 확인할 수 없는 내용

참고로, 이 검토는 다음 흐름으로 진행되었습니다.

• 중간 검토로, 먼저 '현재의 3가지 Prompt를 그대로 사용하는 5단계'를 평가하여 5가지 부족한 점(G1~G5)을 파악했습니다.
• 그 부족함에 대한 대응 방침을 정하고, 5가지를 모두 3가지 Prompt에 반영했습니다. 외부 논문과 베스트 프랙티스도 근거로 추가했습니다.
• 'HVE를 사용해 해결하려고 했던 과제와 그 대응' 및 '과거에 개발했던 앱에 투입한 시간과 토큰 비용'을 조사했습니다.
• HVE를 이용해 개발하려 했던 앱 자체에 대해서도 동일한 관점(시간, 비용, 도달점, 문제)으로 조사했습니다.

본 기사는 이 모든 것을 종합한 최종 결론입니다.

⚠️ [IMG:N] 형식 토큰은 이미지 placeholder 입니다. 번역하지 말고 원래 위치에 그대로 유지하세요.

실제로 검토를 진행하면서, 논점이 몇 가지 섞여 있다는 것을 깨달았습니다. 한 번 분리하겠습니다.

문제가 아니었던 것

• 오케스트레이터의 코드 양이나 잘 만들었는지 여부

• 병목은 LLM 호출과 컨텍스트의 양이었지, 엔진의 코드 양이 아니었습니다

• 단일 Prompt로 중규모 구현을 완성할 수 있는지

• 조건적이지만, 완성할 수 있었습니다 (후술)

문제가 되었던 것

• 합격 여부를 누가 결정하는지 (에이전트의 자기 신고가 아닌지) - 사람의 승인을 어디에 남기는지 - 배포나 과금을 수반하는 작업을 어떤 Prompt가 맡는지 - 생성된 앱의 시스템 테스트를 어떻게 할 것인지 - 요구사항이 늘어났을 때, 요구 정의와 catalog이 무너지지 않을지

여기서 중요한 것은, 'HVE가 필요한지'와 '에이전트 외부에 결정적인 시스템이 필요한지'는 별개의 질문이라는 것입니다.

후자는 필요합니다. 하지만 그것은 HVE가 아니더라도 수백 줄의 스크립트와 CI로 준비할 수 있습니다. 이 기사의 결론은 거의 이 분리에서 나왔습니다.

HVE 개발을 중단하는 판단은 타당하다고 생각합니다 (근거 있음).

중간 검토에서는, '현재 3개의 Prompt를 그대로 사용하는 것'만으로는 기업용 대규모 분산 앱에는 부족하다(조건적)고 판정하고, 5가지의 부족한 점을 파악했습니다.

그 5가지를 모두 3개의 Prompt에 반영했습니다. Prompt를 늘리지 않았고, HVE도 사용하지 않았습니다.

남아있는 조건은, 실제 업무 앱에서 확인하는 것뿐입니다.

Major | 요구 정의와 카탈로그를 단일 파일로 통합했습니다. 이전에는 카탈로그가 28개 파일, 약 82만 바이트까지 늘어나 ID 불일치 문제가 발생했었습니다. 이제 카탈로그는 짧은 대응표 형태로 유지하고, 상세 내용은 mdq와 cq의 인덱스로 보완합니다. 요구사항 ID를 FR-xxx, NFR-<구분>-xxx로 통일하고, 1 요구사항당 1 개의 제목을 부여했습니다. 분할 규칙(요구사항 150개, 300KB, 경계 3개)도 적용했습니다. |

⚠️ [IMG:N] 형식 토큰은 이미지 placeholder 입니다. 번역하지 말고 원래 위치에 그대로 유지하세요.

• 이 기사를 위한 새로운 실험은 하지 않았습니다. 시간과 비용은 손에 남아있던 세션 기록과 Git 기록을 취합했을 뿐입니다.
• 절차 1 (Microsoft 365 Copilot / Work IQ로 초안 작성 단계)은 과거의 Work IQ 조사에서 간접적으로 평가한 것뿐입니다.
• 수정된 Prompt는 아직 실제 앱 개발에 실행해 보지 않았습니다.

이 표는 중간 검토 과정에서 개정 전 Prompt를 평가한 것입니다. 개정 후 대응은 후반부에 정리했습니다.

언뜻 보기에는 간단하고 좋아 보입니다. 하지만 자세히 보면 '누가 합불을 결정하는지', '누가 승인하는지'가 빠져 있었습니다.

실측 환경은 GitHub Copilot CLI 1.0.88, Windows, 모델은 claude-opus-5.5입니다. C1은 'ATG를 사용하지 않는 1회 요청', C2는 'ATG 있음'입니다.

• 사실: 당시 보고서는 '측정한 범위 내에서는 모델의 진화에 의해 ATG의 역할은 불필요해졌다는 판단을 지지한다'고 결론짓고 있습니다.
• 사실: 권장 Prompt는 '요구 정의를 끝까지 완성해 주세요. 저는 중간에 응답하지 않습니다...’라는 1문과, 대규모의 경우 '한 번의 도구 호출로 작성하는 내용은 300행 이내'를 추가하는 것이었습니다.
  P-FR은 이 두 가지를 모두 포함하고 있습니다. - 사실: 이 권장 사항에는 3가지 전제가 있습니다. 요구 정의가 파일이라는 것, 완료 조건을 exit code로 판별할 수 있다는 것, Autopilot으로 실행한다는 것입니다.

솔직히 여기는 저 자신도 조금 충격이었습니다. 오케스트레이터를 추가하면 시간도 비용도 늘어나는데, 품질은 변하지 않았던 것이죠.

• 사실: 태스크 3의 실패에서는 구현 단계에서 모델이 1회 응답 출력 상한(32,000 토큰)을 모두 추론에 소진하여 도구를 호출할 수 없는 상태로 턴이 끝나는 현상이 반복되었습니다. 추론 토큰이 출력에서 차지하는 비율은 95.7%였습니다.
• 사실: ATG 유무와 관계없이 같은 방식으로 실패했습니다. 오케스트레이터를 추가해도 막을 수 없었습니다.
• 추론:
  효과적이었던 것은 '작성 내용을 작게 나누라는' 지시와, '태스크 자체를 작게 나누는 것'이었습니다.

제안된 'Wave로 조금씩 요청하는' 운영은 후자를 사람이 하는 것입니다. 실측 결과와 일치합니다.

사실: Sonnet 5.5의 평균 총 시간은 Opus 5.5 대비 표 계산에서 0.41배, SQL에서 0.56배였습니다. SQL 완성도는 Opus가 3/6, Sonnet이 5/6이었습니다. 완성된 구현에 대한 숨겨진 테스트는 Opus가 561.3/564, Sonnet이 557.4/564였습니다.

• 사실: 분할을 명시하지 않은 C1은 Sonnet에서도 1/3이 실패했지만, 분할한 C1S는 3/3 성공했습니다.

• 추론: 기본 설정은 Sonnet 5.5 + 분할 지시를 사용하고, 어려운 설계 판단에만 상위 모델을 사용하는 것이 시간과 비용 측면에서 합리적입니다. 하지만 n이 적기 때문에 확정적인 차이라고 말하기는 어렵습니다.

• 사실: 가장 긴 단계는 88.7분 이상 걸렸습니다. 이 중 LLM의 추론 시간은 16회에 걸쳐 총 7.3분이었습니다.
  **LLM 외 시간이 81.4분(91.8%)**이었습니다. 입력 컨텍스트는 45,805 → 103,596 토큰으로 2.26배 증가했습니다. - 추론: 장시간화의 주된 원인은 도구 실행, 승인 대기, 직렬 실행, 문맥 비대화입니다. 외부 오케스트레이터는 직렬 실행의 일부를 개선할 수는 있지만, 다른 원인에는 효과가 없습니다.

'그럼 더 작게 다시 만들면 안 될까'라는 방안도 검토했습니다.

• 사실: ATG는 13개의 Python 파일(2,354행)로 구성되어 있으며 의존 라이브러리는 없습니다. HVE 외부에서도 작동합니다(14가지 종류의 CLI 실행 형식으로 exit 0).
• 사실: 그럼에도 불구하고 전면적인 재작성은 권장하지 않았습니다. 엔진을 작게 만들어도 속도는 거의 변하지 않기 때문입니다. 병목 현상은 LLM 호출, 컨텍스트 양, 제어 판단, 직렬성에 있습니다.

이 부분이 실무에서 가장 효과를 볼 수 있는 이야기라고 생각합니다.

• 사실:
  atg node finish
  은 verify_command를 실행하지 않고, handoff에 적힌 exit_code: 0을 그대로 받아들이고 있었습니다. 스텁 구현과 assert True로도 succeeded가 되었습니다. - 사실:
  accepted=1
  인 상태에서 숨겨진 테스트 258/564의 구현을 승인한 사례가 있습니다. - 사실: 과거 조사에서는 '지시가 있다는 것을 테스트해도, 에이전트가 그 지시를 따랐다는 것은 증명할 수 없다'고 정리했습니다.
• 추론:
  합격 여부는 에이전트가 작성하는 글이 아니라, 에이전트 외부에서 실행된 커맨드로 결정해야 합니다.

이는 HVE를 사용하든 안 하든 같습니다. HVE를 포기한다고 해서 새로 잃는 것은 아닙니다. 다만, 원래의 P-FR만으로는 이 메커니즘이 없다는 것이 G3입니다.

• 사실: 고정된 질문으로 문의하는 방식에서는 총 35건 중 발견된 건은 5건(14%), 일부인 경우 4건(11%), 찾지 못한 건은 23건(66%), 사용할 수 없는 건은 3건(9%)이었습니다. 정보가 테넌트에 애초에 존재하지 않을 가능성도 있어, 방식 자체만을 원인이라고 단정할 수는 없습니다.

• 사실: 당시 결론은 Work IQ의 부정이라기보다는 'HVE 전용 Work IQ 오케스트레이션을 제거하고, 탐색 에이전트에게 retrieve를 우선한 반복 조사를 맡긴다'는 것이었습니다. - 추론: 절차 1에서 Work IQ를 '초안 작성자'로 사용하고, P-RD에서 '찾지 못하면 『사내 정보 미확인』으로 기록하고 진행한다'는 방침은 이 결론과 일치합니다.

• 사실: 조사 시점에서는 Microsoft Copilot Managed Runtime이 HVE의 실행 엔진을 대체할 수 없다고 판단했습니다. 실험적인 API가 로컬 리포지토리 편집이나 권한 콜백, output_paths 게이트 등을 충족하지 못하기 때문입니다. - 추론: 이는 'HVE를 무엇으로 대체할 것인가'에 대한 평가입니다. 이번에는 'HVE를 대체하지 않고 Copilot 본체를 직접 사용하는' 방안이므로, 이 결론은 판단을 저해하지 않습니다.

• 사실: HVE에는 중복된 단계, 과도한 지시, 복잡한 경로가 있어 삭감할 수 있다고 정리했습니다. 반면, 여러 에이전트는 컨텍스트를 공유하지 않기 때문에 파일 형태의 요구사항 인덱스만이 공유 상태가 된다고 보고, 요구사항 인덱스와 결정적인 검사는 필요하다고 했습니다. - 추론: 필요했던 것은 'HVE'가 아니라, '기계 가독성 요구사항 인덱스'와 '결정적인 검사'였습니다. catalog은 전자의 최소 형태로, 후자는 G3에서 보완합니다.

HVE를 만들면서, 저는 Copilot으로 네 개의 앱을 개발하고 있었습니다. 각각의 리포지토리 작업 기록과 Git 히스토리, 그리고 손에 남아있던 Copilot 세션 기록을 취합했습니다 (취합일 2026-10-05).

• 정의: 가동 시간은 에이전트가 작동했던 총 시간을 의미하며, 사람의 대기 시간은 포함하지 않습니다. AI 비용은 세션 기록의 totalNanoAiu를 $10^9$로 나눈 값(AIU)의 합계이며, 서브 에이전트의 분을 포함합니다. - 취합 확인: 앱 A에 대해서는 이전에 동일한 세션 기록으로 분석한 적이 있습니다. 같은 시점에서 끊어 다시 취합했을 때, 그 값과의 차이는 1.4%였습니다.
• 금액 추정치는 1 AI Credit = 0.01 USD (GitHub Docs)로 가정하고, AIU를 AI Credits와 동일 단위로 간주하여 환산한 것입니다. 플랜에 포함된 부분을 제외한 실제 청구액은 아닙니다.
• 한계: 세션 기록은 2026년 9월 하반기 이후의 것만 남아있으며, Git 활동은 그보다 전부터 시작되었습니다. 표의 값은 하한입니다. HVE 관련 세션 기록도 2026년 7월 이후 분만 포함되어 있으며, HVE 본체 행에는 이 글을 쓰기 위한 조사나 실험까지 포함됩니다. - 한계: 취합할 수 있었던 것은 손에 남는 CLI / SDK의 세션뿐입니다. VS Code Chat과 GitHub 상의 cloud agent 세션은 포함되지 않았습니다. 이전 분석에서는 앱 D의 VS Code Chat 단 1개 세션만으로도 입력이 약 27억 토큰, 약 95시간에 달했습니다. 모든 행은 실제로는 더 클 것이라고 생각해주십시오.

여기서 알게 된 것은 다음 세 가지입니다.

• 사실: 네 개의 앱은 모두 HVE를 사용하지 않고 만들어졌습니다. ATG는 두 개에서 시도했지만, A에서는 한 번도 호출되지 않은 채 삭제했습니다. C는 HVE나 ATG를 사용하지 않고도 하루에 5.3시간 가동, 약 77 USD로 Azure 배포와 AI 평가까지 완료할 수 있었습니다 (실기 일부 측정은 접수 대기 중). - 사실: A 분석에서 비용의 최대 요인은 한 세션에 작업을 몰아넣은 장대 세션(한 세션으로 전체의 31%)과 광범위한 적대적 리뷰(상위 6건에서 서브 에이전트 토큰의 52%)였습니다. 오케스트레이터가 있었다면 막을 수 있었던 중복 실행은 전체의 약 1%에 불과했습니다.
• 추론: 기록된 기간만으로도, HVE 관련(HVE를 통한 앱 개발 및 HVE 본체)에 사용한 AI 비용은 네 개 앱 합계의 약 1.39배, 가동 시간은 약 1.48배였습니다. HVE 본체 개발/유지보수만으로도 네 개 앱 합계의 약 0.86배입니다. 앱을 만드는 데 드는 것만큼의 돈과 시간을, 앱을 만들기 위한 시스템에 사용하고 있었던 것입니다. 솔직히, 이것은 취합해 보니 가장 놀라운 수치였습니다.

위의 네 개는 HVE를 사용하지 않았습니다. 그렇다면, HVE를 사용해서 만들려고 했던 앱들은 어땠을까요? 같은 관점에서 조사했습니다.

앱 X는 14개의 서브 앱과 26개의 유스케이스로 구성된 기업용 업무 시스템입니다. 업무 요구사항 정리부터 시작하여 HVE의 Workflow(요구 정의 → 아키텍처 선정 → 화면/서비스 설계 → 웹 앱 구현)를 통해 설계부터 구현 및 배포까지 진행할 계획이었습니다.

시간과 비용

로컬 HVE 실행 내역을 보면, 웹 앱 구현의 Workflow가 66%를 차지했으며, 그중 UI 구현과 UI 테스트 생성만으로도 40%였습니다. 이는 화면별로 '먼저 테스트만 만드는' 과정을 반복했기 때문입니다. HVE run 중 /fleet을 구동한 부분도 16%가 있었습니다.

도달점

• 설계 문서는 많이 작성되었습니다. 서브 앱 14건의 요구 정의, 유스케이스 25개, 화면 8개, 서비스 9개, 테스트 사양 25개의 파일이 있습니다.
• 하지만 아키텍처 선정은 14건 모두 '입력 부족으로 판정 중단' 상태였습니다. - 구현은 C#와 JavaScript를 합쳐 약 1.9만 줄에 달하지만, 명확하게 작동하는 부분까지 완성된 것은 하나의 서브 앱이 중심입니다.
• 시스템 테스트의 종합 판정은 **'INCOMPLETE・BLOCKED (전체 PASS 아님)'**이었습니다. 기능 수용(acceptance), E2E, 수정 후 안정성은 미완료이며, Azure로의 데이터 배포는 실행되지 않았습니다. - 최근 재실행에서도 4개의 Workflow 중 2개가 실패했습니다. 성공한 웹 구현 Workflow 역시 첫 번째 단계만으로 약 27분, 1,000 리퀘스트가 소요되었습니다.
• Workflow를 다시 돌릴 때마다 결과물을 새로 만들었기 때문에, 파일을 삭제한 커밋이 53건, 삭제된 소스 파일은 누적 1,500개를 초과했습니다.

발생했던 문제