🤖 AI

Specification Portability Across LLM Development Agents: Cross-Agent Compatibility in Specification-Driven Software Migration

이 논문은 한 AI 에이전트가 생성한 Oracle-to-PostgreSQL 마이그레이션용 명세가 다른 에이전트로 효과적으로 이식되지 못하는 경우가 빈번함을 입증함으로써, 구현 품질의 상당한 에이전트 의존적 저하를 드러내고 소프트웨어 엔지니어링 워크플로에서 에이전트 간 호환성을 보장하기 위한 검색 증강 인제스션(retrieval-augmented ingestion)과 같은 명시적 전략의 필요성을 강조한다.

원저자: Oleg Grynets, Oleksii Ilchuk, Dariia Zatulna, Vasyl Lyashkevych

게시일 2026-08-24

📖 4 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: Oleg Grynets, Oleksii Ilchuk, Dariia Zatulna, Vasyl Lyashkevych

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

현대 소프트웨어 제작의 세계에서, 새로운 종류의 작업자가 팀에 합류했습니다. 바로 거대 언어 모델(LLM)입니다. 이들은 방대한 양의 텍스트와 코드를 학습한 강력한 컴퓨터 프로그램으로, 작업에 대한 설명을 읽고 컴퓨터가 이를 수행하는 데 필요한 지침을 작성할 수 있습니다. 이러한 도구들이 점점 더 보편화됨에 따라, 개발자들은 단순히 코드를 작성하도록 요청하는 것을 넘어, '명세서(specification)'라고 불리는 상세한 설계도를 제공하는 방식으로 변화하고 있습니다. 이 명세서는 모델에게 무엇을 구축해야 하는지, 어떻게 동작해야 하는지, 그리고 어떤 규칙을 따라야 하는지를 정확히 알려주는 운영 가이드 역할을 합니다. '명세 기반 개발(specification-driven development)'이라 불리는 이 접근 방식은 소프트웨어 제작을 더욱 신뢰할 수 있고 구조적으로 만들 것이라고 약속합니다. 그러나 팀이 단일 시스템을 구축하기 위해 여러 가지 서로 다른 모델을 사용하기 시작하면서 비판적인 질문이 제기되었습니다. 만약 한 모델이 완벽한 설계도를 작성한다면, 다른 모델이 그것을 읽고 동일한 것을 만들어낼 수 있을 것인가? 하나의 좋은 계획은 누가 읽더라도 좋은 계획이라는 가정이 있었지만, 기계가 정보를 해석하는 방식의 현실은 훨씬 더 복적합니다.

EPAM Systems의 연구진은 소프트웨어 마이그레이션을 통제된 실험으로 다룸으로써 이 가정을 테스트하고자 했습니다. 그들은 특정하고 어려운 과제를 선택했습니다. 바로 데이터베이스 코드를 Oracle 시스템에서 PostgreSQL로 옮기는 작업이었습니다. 이 두 시스템은 유사한 언어를 사용하지만 서로 다른 방언을 가지고 있어, 로직, 데이터 타입, 함수를 정밀하게 번역해야 합니다. 연구팀은 먼저 하나의 모델이 명세서를 생성하고, 곧바로 동일한 명세서를 사용하여 새로운 코드를 작성하게 함으로써 기준점(baseline)을 설정했습니다. 이는 상당히 잘 작동했습니다. 천 개 이상의 소스 파일 중 시스템은 600개 이상을 성공적으로 재생성했으며, 그중 거의 400개의 새로운 스크립트가 대상 환경에서 올바르게 실행되었습니다. 이는 중간 단계인 명세서를 사용하는 방법이 실행 가능하다는 것을 증명했습니다. 하지만 진짜 시험은 서로 다른 두 번째 모델을 투입했을 때 찾아왔습니다.

연구진은 Amazon Kiro와 같은 모델이 명세서를 작성하면, Google Gemini나 GitHub Copilot과 같은 완전히 다른 모델이 그 문서를 전달받아 코드를 생성하는 시나리오를 만들었습니다. 그들은 두 번째 모델이 품질 저하 없이 첫 번째 모델의 계획을 이해할 수 있는지 확인하고자 했습니다. 결과는 놀랍고도 충격적이었습니다. 명세서의 크기는 결과에 아무런 영향을 미치지 않는 것으로 나타났습니다. 한 모델은 거의 1,600줄에 달하는 거대하고 상세한 문서를 생성했고, 다른 모델은 약 200줄 정도의 간결한 버전을 생성했습니다. 그러나 문서의 길이는 코드가 얼마나 잘 작동할지를 예측하지 못했습니다. 사실 가장 중요한 발견은 명세서의 '출처'가 엄청나게 중요하다는 점이었습니다. Google Gemini가 Amazon Kiro가 작성한 명세서를 받았을 때, 생성된 코드의 품질은 무너졌습니다. 새로운 스크립트는 실행에 실패했고, 구문 오류를 포함했으며, 의도한 대상과 전혀 다르게 보였습니다. 이는 일시적인 오류가 아니었습니다. 연구진은 실험을 반복했을 때도 동일한 극적인 성능 저하를 목격했으며, 이는 두 모델이 동일한 지침 세트를 해석하는 방식에 대해 서로 합의할 수 없음을 확인해 주었습니다.

그러나 이러한 불일치가 보편적인 것은 아니었으며, 이는 발견에 미묘한 차이를 더해주었습니다. Gemini는 Kiro의 명세서로 인해 깊은 어려움을 겪었지만, GitHub Copilot은 동일한 외부 문서를 훨씬 더 잘 처리했으며, 때로는 자신의 문서으로 수행할 때만큼이나 우수한 성능을 보이기도 했습니다. 이는 문제가 외래 명세서 자체가 본질적으로 나쁘기 때문이 아니라, 서로 다른 모델이 텍스트를 읽고 이해하는 방식이 다르기 때문임을 시사했습니다. 이를 해결하기 위해 연구팀은 모델 간의 간극을 메울 수 있는 몇 가지 방법을 테스트했습니다. 그들은 외부 명세서를 받는 모델이 선호할 만한 새로운 형식으로 재작성하거나, 텍스트를 압축하여 짧게 만드는 방법을 시도했습니다. 재작성은 Gemini의 성능을 유의미하게 개선하여 다시 사용 가능한 수준으로 끌어올렸지만, 텍스트 압축은 실질적인 이득을 주지 못했습니다. 가장 유망한 전략은 '검색 증강 생성(retrieval-augmented generation)'이라 불리는 기술을 활용하는 것이었습니다. 명세서 전체를 모델에게 한꺼번에 입력하는 대신, 연구진은 모델이 문서를 검색하여 현재 작업에 필요한 특정 부분만을 추출할 수 있는 도구를 제공했습니다. 이 접근 방식이 모든 척도에서 승리한 것은 아니었지만, 고전하던 모델과 성공적이던 모델 모두에게 일관되게 강력한 성능의 균형을 제공한 유일한 방법이었습니다.

이 연구는 다양한 인공지능 에이전트들이 협력하여 소프트웨어를 구축하는 세상에서, 명세서는 중립적이고 보편적인 문서로 취급될 수 없다고 결론짓습니다. 한 에이전트가 작성한 계획은 다른 에이전트에게 자동으로 유효한 지침 세트가 되지 않습니다. 코드의 효과는 계획을 작성한 모델과 소프트웨어를 구축하는 모델 사이의 구체적인 관계에 크게 좌우됩니다. 만약 팀이 한 에이전트를 다른 에이전트로 교체한다면, 기존의 청사진이 작동할 것이라고 단순히 가정해서는 안 됩니다. 계획의 언어를 조정하거나 새로운 에이전트가 정보에 접근하는 방식을 변경해야 할 수도 있습니다. 이 연구는 다중 에이전트 소프트웨어 공학의 미래가 명세서가 어떻게 구조화되고 전달되는지에 대한 새로운 집중을 필요로 한다는 점을 시사하며, 계획에 담긴 지식이 이를 구축하도록 맡은 기계에 의해 실제로 이해될 수 있도록 보장해야 함을 강조합니다.

기술 요약: LLM 개발 에이전트 간의 사양 이식성 (Specification Portability)

1. 문제 정의

본 논문은 신흥 다중 에이전트 소프트웨어 공학(SDE) 워크플로에서 발생하는 심각한 상호 운용성 격차를 다룹니다. 대규모 언어 모델(LLM)이 프롬프트 기반의 보조 도구에서 사양(specification)으로부터 코드를 생성하는 자율 에이전트로 전환됨에 따라, 새로운 질문이 제기됩니다: 한 LLM 에이전트 환경에서 생성된 사양이 다른 환경에서도 신뢰할 수 있게 소비될 수 있는가?

현재의 연구들은 단일 에이전트의 성능, 컨텍스트 검색 또는 요구사항 명확화에 집중하고 있습니다. 그러나 사양을 생성한 에이전트 A(예: Amazon Kiro)가 생성한 사양이 구현 에이전트 B(예: Google Gemini)에 의해 소비되어 타겟 코드를 생성할 때, 그 운영적 유효성이 유지되는지는 경험적으로 불분명합니다. 저자들은 사양이 "에이전트 중립적"인 산출물이 아니라고 가설을 세웁니다. 즉, 사양의 유효성은 사양의 기원과 이를 소비하는 구현 에이전트의 인입(ingestion) 전략에 따라 크게 저하될 수 있습니다.

2. 방법론

본 연구는 Oracle-to-PostgreSQL 데이터베이스 마이그레이션을 변환 작업으로 사용하여 통제된 2단계 실험 설계를 채택했습니다. 이 도메인은 복잡한 애플리케이션 시맨틱을 보존하면서도 방언 특유의 구문(절차적 로직, 트리거, 데이터 타입)을 번역해야 하기 때문에 선택되었습니다.

1단계: 사양 주도 마이그레이션 파이프라인

작업: 사양 우선 파이프라인을 1,006개의 PL/SQL 소스 파일에 대해 평가했습니다.
프로세스: 소스 코드를 데이터베이스 객체로 분해했습니다. 에이전트는 중간 단계의 텍스트 사양을 생성했고, 이 사양은 PostgreSQL 구현을 도출하는 데 사용되었습니다.
결과: 623개의 파일이 성공적으로 재생성되었으며, 그 중 380개가 PostgreSQL 16에서 성공적으로 실행되었습니다. 이는 접근 방식의 타당성을 입증했으나, 아직 교차 에이전트 전송(cross-agent transfer)은 테스트하지 않았습니다.

2단계: 교차 에이전트 호환성 실험

데이터셋: PostgreSQL 구현이 포함된 1,802개의 Oracle 스크립트.
평가 대상 에이전트: Amazon Kiro, Google Gemini (Antigravity 경유), GitHub Copilot (Spec Kit 경유), Claude Code, Cursor.
실험 조건:
1. 네이티브 베이스라인 (Native Baseline): 각 에이전트가 자체적인 사양과 구현을 생성함.
2. 교차 에이전트 전송 (Cross-Agent Transfer): 한 에이전트가 생성한 사양을 다른 에이전트에 입력함 (예: Kiro 사양 $\to$ Gemini 구현).
3. 적응 전략 (Adaptation Strategies): 잠재적인 성능 저하를 완화하기 위해, 외부 사양에 대해 세 가지 전략을 테스트함:
  - 재작성 (Rewriting): 구현 에이전트가 코딩 전 외부 사양을 자신의 선호 형식으로 재작성함.
  - 압축 (Compression): 외부 사양의 길이를 줄이기 위해 요약함.
  - 검색 증강 생성 (RAG): 에이전트가 전체 텍스트를 직접 주입하는 대신 검색 도구를 통해 외부 사양에 접근함.

평가 지표

연구는 어휘적, 구문적, 구조적, 운영적 품질을 구분하기 위해 다차원 지표 세트를 활용했습니다:

Token F1: 토큰 수준의 유사도.
Exact Match: 타겟과 출력이 동일한 비율.
SQL Syntax Validity: 생성된 SQL의 유효성 (sqlglot 사용).
AST Exact Match & Mean Similarity: 추상 구문 트리(Abstract Syntax Tree)의 구조적 유사도.
즉시 실행 가능성 (Immediate Runnability): 수동 수정 없이 스크립트가 실행되는 비율 (테스트 환경 제약으로 인해 하한선으로 간주됨).

3. 주요 결과

A. 사양의 크기는 품질의 예측 변수가 아님

상세한 사양이 더 나은 코드를 생성할 것이라는 가정과 달리, 본 연구에서는 사양의 길이와 구현 품질 사이에 상관관계가 없음을 발견했습니다.

Kiro는 가장 큰 사양(~1,597행)을 생성했습니다.
Gemini는 훨씬 작은 사양(~193행)을 생성했습니다.
이러한 크기 차이에도 불구하고, 더 큰 Kiro 사양이 모든 에이전트나 지표에서 보편적으로 우수한 코드를 생성하지는 않았습니다.

B. 비대칭적 및 에이전트 의존적 저하

교차 에이전트 전송은 매우 가변적인 결과를 낳았으며, 이는 사양의 이식성이 방향성( $C_{i \to j} \neq C_{j \to i}$ )을 가짐을 확인시켜 주었습니다.

치명적 실패 사례: Gemini가 Kiro 기원의 사양을 직접 소비했을 때 성능이 붕괴되었습니다.
- Token F1이 0.035로 급락 (네이티브 0.73 대비).
- SQL Syntax Validity가 **2.33%**로 급락 (네이티브 45.54% 대비).
- AST Mean Similarity가 0.015로 급락.
- 이 실패 패턴은 두 번째 독립적인 실행에서도 재현되었으며, 이는 무작위적 비결정론이 아님을 입증합니다.
기타 쌍의 안정성: 다른 조합들(예: Kiro 사양을 소비하는 Copilot)은 비교적 안정적이거나 혼합된 개선을 보였으며, 이는 저하가 보편적인 법칙이 아니라 에이전트-사양 쌍에 특화된 현상임을 나타냅니다.

C. 적응 전략의 효과성

재작성 (Rewriting): Gemini가 Kiro 사양을 소비할 때 성능을 실질적으로 향상시켰으며, 이는 표현 형식(내용뿐만 아니라)이 불호환성의 주요 원인임을 시사합니다. 이 전략은 Copilot에게는 덜 효과적이었습니다.
압축 (Compression): 보편적인 이득을 제공하지 못했습니다. 단순한 길이 축소만으로는 불호환 문제를 해결할 수 없었습니다.
검색 증강 인입 (RAG): RAG가 모든 지표에서 우위를 점하지는 않았지만, 외부 사양을 처리할 때 Gemini와 Copilot 모두의 **파레토 프런티어 (Pareto frontiers)**에 등장한 유일한 전략이었습니다. 이는 RAG가 테스트된 대안들 중 가장 강력한 공통 트레이드오프 전략임을 식별해 줍니다.

4. 주요 기여

비이식성에 대한 경험적 증거: 본 논문은 한 LLM 환경에서 생성된 사양이 다른 환경에서 자동으로 효과적이지 않다는 최초의 통제된 경험적 증거를 제공하며, 사양을 에이전트 중립적인 중간 산출물로 간주하는 가정을 반박합니다.
다차원 평가 프레임워크: 단순한 코드 생성 벤치마크를 넘어, 교차 에이전트 사양 전송을 위한 포괄적인 평가 세트(Token F1, AST 유사도, 실행 가능성)를 도입했습니다.
적응 전략 분석: 재작성, 압축, RAG를 체계적으로 평가하여, 단순한 내용 축소보다 **표현 적응(재작성)**과 **선택적 접근(RAG)**이 더 효과적임을 밝혀냈습니다.
형식 모델 제안: 저자들은 구현 품질 $Q_{code}$ 가 사양의 기원( $A_g$ ), 구현 에이전트( $A_i$ ), 인입 전략( $I_s$ ), 그리고 컨텍스트( $C$ )의 함수라는 모델을 제안하며, 지식 보존과 운영적 해석 보존을 구분합니다.

5. 의의 및 주장

본 논문은 연구 결과가 평가된 에이전트, 데이터셋, 지표에 국한된 경험적이고 맥락 특수적이라는 점을 겸허히 명시합니다. 외부 사양이 보편적으로 열등하다고 주장하는 것이 아니라, 그 유효성이 에이전트에 따라 달라진다는 점을 강조합니다.

주요 의의:

워크플로 함의: 이질적인 다중 에이전트 SDD 워크플로에서 사양은 정적이고 상호 교환 가능한 산출물로 취급되어서는 안 됩니다. 에이전트 간에 사양을 전달할 때는 구현 저하를 방지하기 위해 명시적인 적응(예: 재작성 또는 RAG)이 필요할 수 있습니다.
설계 가이드라인: 본 연구 결과는 구조화된 사양 표현(지식, 표현, 의존성, 세밀도 분리) 및 사양의 에이전트별 뷰(agent-specific views) 개발의 필요성을 뒷받침합니다.
향 |후 방향: 연구는 알 수 없는 에이전트 쌍에 대해 검색 기반 접근(RAG)이 견고한 전략임을 시사하지만, 의존성 인식 검색 및 구조화된 사양 모델을 통해 사양 이식성 문제를 완전히 해결하기 위한 추가 연구가 필요함을 시사합니다.

저자들은 "사양 이식성"이 정보가 어떻게 구조화되고, 전달되며, 서로 다른 LLM 개발 환경 간에 어떻게 해석되는지를 명시적으로 고려해야 하는 미해결 과제라고 결론짓습니다.