Executing as You Generate: Hiding Execution Latency in LLM Code Generation

1. 문제 정의 (Problem)

현재 LLM 기반 코딩 에이전트들은 직렬 실행 (Serial Execution) 패러다임을 따릅니다. 즉, 모델이 코드를 완전히 생성한 후에야 인터프리터를 호출하여 실행하는 방식입니다.

• 비효율성: 이 방식은 생성 (Generation) 중에는 실행기가 유휴 상태 (Idle) 가 되고, 실행 (Execution) 중에는 생성기가 유휴 상태가 되어 전체端到端 (End-to-End) 지연 시간이 불필요하게 길어집니다.
• LLM 의 특성: 인간 개발자는 코드를 작성하며 수정하지만, 현대의 토큰 기반 LLM 은 생성된 토큰을 즉시 확정 (Commit) 하고 수정하지 않습니다. 이 특성을 활용하지 못하는 것이 문제의 핵심입니다.
• 기존 연구의 한계: 기존 연구 (Open Interpreter 등) 는 실행 피드백을 통해 생성 품질을 높이는 '증분 실행'을 시도했으나, 여전히 생성이 멈추고 실행 결과를 기다리는 직렬적 구조를 유지하여 지연 시간 감소에는 한계가 있었습니다.

2. 제안 방법론 (Methodology)

저자들은 LLM 이 토큰을 생성하는 즉시 코드를 실행할 수 있는 병렬 실행 (Parallel Execution) 패러다임을 제안하고, 이를 구현한 프레임워크 Eager를 개발했습니다.

2.1 이론적 모델링

• 3 단계 파이프라인: 생성 (Generation) → 감지 (Detection) → 실행 (Execution) 의 3 단계로 구성됩니다.
• 지연 시간 분석: 생성 속도와 실행 속도의 비율, 그리고 청크 (Chunk) 단위 실행 오버헤드를 기반으로 지연 시간의 상한선과 하한선을 수학적으로 유도했습니다.
  • 생성 주도 (Generation-dominated): 생성 속도가 느린 경우, 실행 시간을 생성 시간 뒤에 완전히 숨길 수 있어 지연 시간이 크게 단축됩니다.
  • 실행 주도 (Execution-dominated): 실행 시간이 매우 긴 경우 병렬화의 이득은 줄어들지만, 직렬 실행보다 성능이 떨어지지는 않습니다.

2.2 Eager 프레임워크 아키텍처

Eager 는 생산자 - 소비자 (Producer-Consumer) 파이프라인 구조를 따릅니다.

1. AST 기반 청커 (AST-based Chunker):
   • LLM 의 스트리밍 토큰을 버퍼에 모으고, 구문 분석 트리 (AST) 를 사용하여 문장 단위의 실행 가능한 청크를 식별합니다.
   • Lookahead 전략: 문법적으로 완성된 것처럼 보이지만 다음 토큰에 따라 문장이 계속될 수 있는 경우 (예: 함수 정의 중), 추가 토큰을 기다려 명확한 종료 시점을 판단하여 잘못된 실행을 방지합니다.
2. 게이트드 실행기 (Gated Executor with Dynamic Batching):
   • 동적 배치 (Dynamic Batching): 대기열에 쌓인 여러 청크를 하나의 배치로 합쳐 실행합니다. 이는 실행 환경 초기화 오버헤드 (Setup overhead) 를 분산시켜 효율성을 높입니다.
   • 게이팅 (Gating): 실행 시간이 거의 없는 문장 (예: 함수/클래스 정의) 은 즉시 실행하지 않고 다음 배치와 합쳐 지연 실행합니다. 이는 불필요한 오버헤드를 줄입니다.
   • 지속적 세션: 변수 바인딩과 임포트를 유지하는 지속 가능한 인터프리터 세션을 사용하여 상태가 유지됩니다.
3. 조기 오류 중단 (Early Error Interruption):
   • 생성 중 실행 오류가 발생하면 즉시 생성을 중단하고 오류를 반환합니다. 이는 오류가 발생한 후 불필요하게 생성되는 토큰을 방지하고, 오류 수정을 위한 피드백 루프를 단축합니다.

3. 주요 기여 (Key Contributions)

1. 이론적 정립: LLM 코드 생성의 병렬 실행 패러다임을 공식화하고, 지연 시간의 이론적 한계와 작동 regimes(영역) 를 수학적으로 규명했습니다.
2. 구현 (Eager): AST 기반 청킹, 동적 배치, 조기 오류 중단 기능을 갖춘 구체적인 프레임워크를 구현했습니다.
3. 광범위한 평가: 4 개의 벤치마크, 7 개의 LLM, 3 가지 실행 환경 (로컬, Docker, Open Interpreter) 에서 실험을 수행하여 유효성을 입증했습니다.

4. 실험 결과 (Results)

실험은 시뮬레이션된 토큰 스트림과 실제 LLM 생성 코드를 모두 포함하여 수행되었습니다.

• 지연 시간 감소:
  • 비겹침 실행 지연 (NEL): 실행 시간이 생성 시간 뒤에 숨겨져 사용자에게 노출되지 않는 비율이 **83%~99.9%**까지 감소했습니다.
  • 端到端 지연 (E2EL): 전체 대기 시간은 **최대 55%**까지 단축되었습니다. (오류 발생 시 조기 중단으로 인해 더 큰 감소 효과를 보임).
  • 생성 속도가 빠를수록 (예: 200 TPS) 실행 시간이 전체 지연에서 차지하는 비중이 커져 병렬 실행의 이득이 더 큽니다.
• 코드 수정 성공률 향상:
  • 조기 오류 중단으로 인해 LLM 이 오류 발생 지점 이후의 잘못된 코드 맥락에 갇히지 않게 됩니다.
  • 데이터 중심 벤치마크 (DABench, DSBench 등) 에서 오류 해결 성공률이 최대 44% 포인트까지 향상되었습니다. (완전한 코드를 제공하는 직렬 방식보다 부분 생성 코드가 더 나은 수정 결과를 낳음).
• 범용성: 로컬, Docker, Open Interpreter 등 다양한 실행 환경에서 일관된 성능 향상을 보였습니다.

5. 의의 및 시사점 (Significance)

• 시스템 설계의 변화: 기존 에이전트 프레임워크가 "완성된 파일을 생성 후 실행"하는 방식을 지양하고, "생성되는 대로 실행"하는 인터페이스로 전환해야 함을 시사합니다.
• 프로그래밍 언어 설계에 대한 제언: LLM 기반 생성이 주류가 될 경우, 언어 차원에서 스트리밍 실행을 지원하거나 문장 구분자를 명확히 하는 등 '스트리밍 가능성 (Streamability)'을 고려한 설계가 필요함을 강조합니다.
• 실용적 가치: 코드 품질을 높이는 기존 연구와 병렬적으로 적용 가능하여, 사용자 경험 (대기 시간) 을 획기적으로 개선하면서도 코드 정확도를 유지하거나 향상시킬 수 있는 방법론을 제시했습니다.

결론적으로, 이 논문은 LLM 코딩 에이전트의 지연 시간을 줄이고 수정 효율을 높이기 위해 생성과 실행을 병렬화하는 새로운 패러다임을 제시하며, 이를 위한 이론적 근거와 실증적 증거를 제공합니다.