Test-Oriented Programming: rethinking coding for the GenAI era

1. 문제 정의 (Problem)

• 현재 GenAI 도구의 한계: GitHub Copilot 과 같은 자동 완성 도구나 멀티 에이전트 시스템, 그리고 'Vibe Coding'과 같은 대화형 개발 워크플로가 개발자의 생산성을 높이고 있지만, 여전히 생산 코드 (Production Code) 를 개발자가 직접 검토해야 합니다. 이는 프로그래밍의 추상화 수준을 높이지 못했습니다.
• 자연어의 모호성: 자연어는 인간에게 직관적이지만 모호성이 있어 기계가 실행 가능한 코드로 변환하는 데 어려움을 줍니다. 기존 프로그래밍 언어는 형식적 명세 (Formal Specifications) 로 이를 해결했으나, LLM 은 비결정적 (Non-deterministic) 성격을 가집니다.
• 해결 필요성: 개발자가 생산 코드를 직접 작성하거나 수정하는 대신, 자연어 명세에 기반하여 LLM 이 코드를 완전히 생성하고 개발자는 검증 가능한 테스트 코드만 확인하는 새로운 추상화 수준의 패러다임이 필요합니다.

2. 방법론 (Methodology)

저자는 **테스트 지향 프로그래밍 (Test-Oriented Programming, TOP)**이라는 새로운 패러다임을 제안했습니다.

• 핵심 개념:

  • 개발자는 자연어 명세와 **테스트 코드 (Test Code)**만 작성/검증합니다.
  • 생산 코드는 LLM 에 의해 완전히 위임되어 자동 생성됩니다.
  • 테스트 코드는 자연어의 모호성을 해결하고 생성된 코드의 유효성을 검증하는 기준이 됩니다.
  • 이는 TDD(테스트 주도 개발) 와 유사하지만, TDD 는 테스트와 생산 코드가 같은 추상화 수준인 반면, TOP 은 LLM 을 통해 생산 코드 생성을 자동화하여 더 높은 추상화 수준을 달성합니다.

• 구현 도구 (Onion):

  • TOP 의 실현 가능성을 검증하기 위해 Onion이라는 프로토타입 도구를 개발했습니다.
  • 입력: YAML 형식의 설정 파일 (자연어 프로젝트 설명, 수용 테스트 명세).
  • 프로세스:
    1. 설정 파일을 기반으로 LLM 과 상호작용하여 프로젝트 구조 (클래스, 메서드) 를 정의하는 YAML 파일을 생성.
    2. 수용 테스트 및 클래스별 테스트 코드를 생성.
    3. 개발자가 테스트 코드를 검증 및 수정.
    4. 테스트 통과 여부에 따라 LLM 이 생산 코드를 생성.
    5. 실패 시 테스트/구조/설정 파일을 수정하여 재시도.
  • 평가 대상: BibTeX 엔트리 관리 명령어 줄 도구 (추가, 목록 조회, 검색 기능).
  • 사용 모델: OpenAI 의 GPT-4o-mini와 Google 의 Gemini 2.5-Flash(추론 모델 vs 비추론 모델 비교).

3. 주요 기여 (Key Contributions)

1. 새로운 프로그래밍 패러다임 제안 (TOP): 개발자가 생산 코드를 직접 다루지 않고 테스트 코드와 명세만 관리함으로써 소프트웨어 개발의 추상화 수준을 획기적으로 높이는 새로운 접근법을 제시.
2. Onion 도구 개발: TOP 개념을 구현한 프로토타입 도구와 이를 통해 생성된 시스템의 데이터셋 (프로젝트 구조, 생성된 코드, 프롬프트 로그 등) 을 공개.
3. 실증적 평가: 두 가지 다른 LLM 모델을 사용하여 TOP 의 실현 가능성과 한계를 분석하고, 실제 프로젝트 적용을 위한 구체적인 과제를 도출.

4. 결과 (Results)

• 성공적 생성: 모든 시도에서 개발자가 생산 코드를 직접 수정할 필요 없이, 테스트 코드 수정을 통해 LLM 이 올바른 생산 코드를 생성하는 데 성공했습니다.
• 모델별 차이:
  • GPT-4o-mini: 상대적으로 적은 수의 시도 (1 회) 만으로 테스트 코드를 수정해야 했으며, 생성된 코드가 짧고 주석이 적었습니다.
  • Gemini 2.5-Flash: 더 많은 수정이 필요했으며, 생성된 코드가 길고 주석이 많았습니다 (추론 모델의 과도한 설명성 경향).
• 발견된 문제점:
  • 테스트 코드의 모호성: 모델이 일관되게 동일한 테스트를 실패하는 코드를 생성할 경우, 개발자가 테스트 코드 자체에 주석을 추가하여 모델을 안내해야 했습니다.
  • 비결정성 (Non-determinism): 동일한 모델과 입력에서도 매번 다른 결과가 생성되었습니다.
  • 검증 부담: 생성된 테스트 코드의 양이 방대하여 개발자가 이를 수동으로 검증하는 데 시간이 많이 소요되었습니다.

5. 의의 및 시사점 (Significance)

• 개발 패러다임의 전환: TOP 은 GenAI 시대에 개발자가 '코드 작성자'에서 '테스트 검증자 및 명세자'로 역할이 변화할 수 있음을 보여줍니다. 이는 고수준 언어가 어셈블리를 대체한 것과 유사한 추상화 수준의 도약입니다.
• 실용적 도전 과제 도출:
  1. 테스트 코드 검증의 어려움: 생성된 테스트 코드의 양과 복잡성을 개발자가 수동으로 검증하는 것은 비효율적이므로, 이를 지원할 자동화 도구의 필요성이 대두됨.
  2. 모델 간 코드 품질 편차: 사용하는 LLM 모델에 따라 생성된 코드의 길이, 주석 양, 스타일이 크게 달라 표준화된 품질 관리가 어려움.
  3. 비결정성 관리: LLM 의 비결정적 특성으로 인해 일관된 결과를 얻기 위한 전략이 필요함.
• 미래 전망: 현재는 프로토타입 단계이나, 복잡한 시스템은 모듈화하여 Onion 과 같은 툴로 생성하는 마이크로서비스 아키텍처 등으로 확장 가능할 것으로 기대됩니다.

결론적으로, 이 논문은 LLM 을 단순히 코드 보조 도구가 아닌, 생산 코드를 완전히 생성하는 엔진으로 활용하는 Test-Oriented Programming의 가능성을 제시하며, 이를 위해 해결해야 할 기술적 과제를 명확히 하고 있습니다.