💬 NLP

Beyond "What to Retrieve": Uncertainty in Retrieval-Augmented Code Generation

이 논문은 소스별 불확실성을 추정하고 이를 활용하여 이질적인 검색 증거를 필터링 및 순위화함으로써 저장소 수준의 코드 생성 정확도를 향상시키는 동시에, 그 이점이 특정 LLM 백엔드 및 증거 간의 상호작용에 의존함을 입증하는 불확실성 인지 프레임워크인 OpenCoder를 소개한다.

원저자: Chandan Kumar Sah, Xiaoli Lian, Li Zhang

게시일 2026-07-29

📖 4 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: Chandan Kumar Sah, Xiaoli Lian, Li Zhang

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

당신이 복잡한 레고 성을 만들려고 하는데, 앞문 만드는 법만 적힌 단 한 권의 설명서만 손에 쥐었다고 상상해 보십시오. 문은 어떻게 만드는지 알지만, 성에는 창문도 필요하고 지붕과 비밀 지하 통로도 필요합니다. 이것이 인공지능(AI)이 실제 프로젝트를 위한 컴퓨터 코드를 작성할 때 겪는 일상적인 고충입니다. AI는 작고 고립된 코드 조각을 작성하는 데는 놀라울 정도로 능숙해졌지만, 거대한 기존 소프트웨어 "동네"에 어울리는 무언가를 만들어야 할 때는 길을 잃곤 합니다. 이를 해결하기 위해 연구자들은 **검색 증강 생성(Retrieval-Augmented Generation, RAG)**이라는 기술을 사용합니다. RAG를 AI에게 초강력 검색 엔진을 쥐여주는 것이라고 생각하십시오. AI는 코드 한 줄을 쓰기 전에, 유사한 프로젝트를 찾아보고, 동네 규칙(프로젝트 특유의 관례)을 확인하며, 사용할 적절한 도구(API)를 찾아냅니다.

하지만 문제가 있습니다. 검색 엔진이 많은 정보를 찾아낸다고 해서 그 정보가 반드시 도움이 되는 것은 아닙니다. 때때로 AI는 프로젝트를 망가뜨릴 수도 있는, 겉보기에만 유사한 코드 조ков를 찾아내기도 하며, 다른 때에는 특정 작업에 맞지 않는 도구를 찾아내기도 합니다. 정보는 존재하지만, 그것이 소음이거나, 상충하거나, 혹은 그냥 틀린 것일 수 있습니다. 연구자들이 던져온 핵심 질문은 이것입니다. 어떻게 하면 AI가 단순히 올바른 정보를 '찾는' 것을 넘어, 그 정보를 '얼마나 신뢰할지'를 알게 할 것인가? 만약 AI가 유용한 단서와 오도하는 레드 헤링(미끼)을 구별하지 못한다면, 문을 열려고 하는 순간 무너져 내리는 성을 짓게 될 것입니다.

여기서 베이항 대학교(Beihang University) 연구진의 새로운 연구인 OpenCoder가 등장합니다. OpenCoder는 AI를 위한 회의적이고 매우 체계적인 프로젝트 매니저 역할을 합니다. 검색 엔진이 찾아낸 모든 정보를 맹목적으로 신뢰하는 대신, OpenCoder는 모든 단서에 "의구심 점수(doubt score)"를 부여합니다. 이 시스템은 "이 API가 적절한 것에 대해 얼마나 불확실한가?" 또는 "이 유사한 코드가 우리 프로젝트와 충돌할 가능성은 얼마나 되는가?"라고 자문합니다. 불확실성을 버그가 아닌 유용한 신호로 취급함으로써, OpenCoder는 노이즈를 걸러내고, 단서들의 신뢰도를 기준으로 순위를 매기며, 심지어 스스로의 실수를 파악하고 멈추는 법까지 알고 있습니다.

연구진은 32가지의 서로 다른 실제 과제를 AI에게 코드를 작성하도록 요청하여 이 시스템을 테스트했습니다. 그 결과, 강력한 AI 모델인 GPT를 사용할 때 OpenCoder는 최종 코드의 성공률을 기존 검색 방식의 **56.25%**에서 **78.13%**로 크게 높였습니다. 그러나 연구진은 중요한 미묘한 차이를 발견했습니다. 이러한 개선은 표준 검색을 사용하면서 "검증 및 복구(verify and repair)" 단계를 추가한 대조군의 성능과 일치했습니다. 이는 OpenCoder의 불확실성 필터링이 도움이 되긴 했지만, 엄청난 성공률의 상승은 주로 검증하고 오류를 수정하는 능력에 의해 주도되었다는 점을 시사합니다. 비결은 단순히 더 많은 정보를 찾는 것이 아니라, "이 특정 증거는 미심쩍으니 무시하자"라고 말하고, "이 다른 조각은 확실하니 사용하자"라고 말할 수 있는 능력, 그리고 실수 방지를 위한 안전망을 갖추는 것이었습니다.

하지만 이야기는 단순히 "AI의 승리"로 끝나지 않습니다. 연구진은 이 성공이 어떤 AI 두뇌가 사고를 하느냐에 따라 크게 달라진다는 점을 주의 깊게 언급했습니다. 만약 GPT를 Gemini라는 다른 모델로 교체하면 결과는 훨씬 불분명해졌습니다. 개선 효과가 통계적으로 유의미하지 않았는데, 이는 OpenCoder의 "불확실성 레이더"가 AI의 개성에 따라 다르게 작동함을 시사합니다. 또한, 프로젝트에 정보가 너무 부족한 경우에는 시스템이 한계에 부딪혔습니다. 정보가 불완전한 경우, 검증과 복구가 포함된 표준 시스템이 오히려 OpenCoder보다 더 나은 성과를 보였습니다. 이는 검색 엔진이 시작하는 데 필요한 도구를 찾지 못할 때, OpenCoder의 필터링 메커니즘이 가용한 몇 안 되는 증거들마저 억제해 버릴 수 있음을 나타냅니다. 즉, 결정을 개선하기보다는 오히려 방해할 수 있다는 것입니다.

연구는 또한 서로 다른 유형의 정보가 어떻게 함께 작용하는지에 대한 놀라운 사실도 발견했습니다. "유사한 코드", "프로젝트 컨텍스트", "API 지식"을 모두 갖추는 것이 항상 하나만 있는 것보다 낫다고 생각할 수 있습니다. 하지만 연구진은 보편적인 규칙은 없다는 것을 발견했습니다. 때로는 "유사한 코드"를 추가하는 것이 적절한 "프로젝트 컨텍스트"와 결합되지 않으면 오히려 AI를 혼란스럽게 만들었습니다. 이는 지도, 나침반, GPS를 가진 것과 같습니다. GPS만 있다면 길을 잃을 수 있고, 지도와 나침반만 있다면 괜찮을 수 있지만, 세 가지를 모두 가졌는데 서로 충돌한다면 결국 제자리를 맴돌게 될 것입니다. 각 단서의 가치는 다른 단서들이 무엇인지에 따라 전적으로 달라집니다.

이를 구현하기 위해 OpenCoder는 5단계의 춤을 춥니다. 첫째, 프로젝트의 모든 규칙과 도구의 라이브러리를 구축합니다. 둘째, 사용자의 요청을 작은 단계들로 나눕니다. 셋째, 단서를 찾아 나서되, 이번에는 단서들이 얼마나 "불확실한지"를 기준으로 점수를 매깁니다. 넷째, 코드를 생성하되, 불안정한 단서를 피하기 위해 "불확실성 점수"를 면밀히 살핍니다. 마지막으로, 가장 중요한 단계로, 스스로 품질 관리 검사관 역할을 수행합니다. 코드를 일련의 테스트를 통해 실행합니다. 만약 코드가 실패하면, 단순히 포기하는 것이 아니라 오류를 식별하고 검증 피드백을 바탕으로 코드를 복구하려고 시도합니다.

결론적으로, 이 논문은 AI 코딩의 미래가 단순히 AI를 더 똑똑하게 만들거나 더 많은 데이터를 주는 것에 있지 않다고 제안합니다. 그것은 AI에게 겸손함과 비판적 사고를 가르치는 것입니다. 불확실성을 의사결정을 안내하는 도구로 취급함으로써—나쁜 데이터를 걸러내고, 출력을 검증하며, 즉석에서 오류를 수정하는 것—OpenCoder와 같은 시스템은 더 신뢰할 수 있는 소프트웨어를 구축할 수 있습니다. 그러나 연구진은 경고하듯, 이것이 모든 상황에서 작동하는 마법 지팡이는 아닙니다. 이는 AI가 다룰 수 있는 충분한 좋은 정보가 있고, 특정 AI 모델이 "의구심 점수"를 올바르게 이해하도록 튜닝되어 있을 때 가장 잘 작동합니다. 현재로서 OpenCoder는 강력한 진전이며, 때로는 자신이 무엇을 모르는지 아는 것이 퍼즐을 푸는 데 있어 가장 중요한 부분임을 증명하고 있습니다.

기술 요약: "무엇을 검색할 것인가"를 넘어: 검색 증강 코드 생성에서의 불확실성

문제 정의

저장소 수준(Repository-level)의 코드 생성은 대규모 언어 모델(LLM)이 교차 파일 의존성, 프로젝트 컨벤션, 그리고 프라이빗 API를 준수하는 구현체를 합성할 것을 요구한다. 검색 증강 생성(RAG)은 외부 저장소 증거를 제공함으로써 파라미터 지식의 한계를 해결하지만, 기존 방식들은 주로 무엇을 검색할 것인지(예: 유사 코드, 저장소 컨텍스트, API 지식 등)를 최적화하는 데 집중한다. 이들은 이러한 증거와 관련된 내재적 불확실성은 대체로 간과한다.

검색된 증거는 흔히 이질적이고 신뢰할 수 없다. 유사한 코드 예시는 의미적으로는 관련이 있을지라도 기능적으로는 호환되지 않을 수 있으며, 저장소 컨텍스트에는 중복되거나 충돌하는 의존성이 포함될 수 있고, API 지식은 불완전하거나 범위가 잘못 지정될 수 있다. 현재의 방법론들은 검색의 관련성을 최적화할 뿐, 이러한 소스의 불확실성이 다운스트림 생성, 검증 및 수리에 어떻게 영향을 미치는지 명시적으로 모델링하지 않는다. 결과적으로, 추가적인 증거를 결합하는 과정에서 노이즈가 유입되어 검색 오류가 전파될 수 있으며, 이는 실행 가능한 코드임에도 불구하고 상당한 API 오용이나 기능적 결함을 포함하게 만든다.

방법론: OpenCoder

저자들은 불확실성을 사후적인 신뢰도 점수가 아닌 실행 가능한 제어 신호로 취급하도록 설계된 불확실성 인식 프레임워크인 OpenCoder를 소개한다. 이 프레임워크는 다음의 5단계로 작동한다:

저장소 지식 및 불확실성 프로파일링: 세 가지 증거 소스인 프로젝트 특정 API( $A$ ), 컨텍스트 저장소 코드( $X$ ), 그리고 의미적으로 유사한 코드 예시( $S$ )를 포함하는 인덱스를 구축한다.
쿼리 불확실성 분해: 사용자 쿼리를 구현 단계로 분해하고 각 단계에 필요한 증거를 예측한다.
불확실성 인식 다중 소스 검색: $A$ $A$ , $X$ $X$ , $S$ $S$ 로부터 후보군을 검색한다. 결정적으로, OpenCoder는 각 검색 항목에 대해 소스별 불확실성 점수 $u_m(e|q) \in [0,1]$ $u_{m} (e ∣ q) \in [0, 1]$ 를 할당하며, 값이 높을수록 관련성, 완전성 또는 호환성에 대한 신뢰도가 낮음을 의미한다.
- 증거는 코사인 유사도( $r_m$ ), 예측된 소스 의도 가중치( $w_m$ ), 그리고 불확실성의 조합을 사용하여 점수가 매겨진다: $\gamma_m(e|s) = r_m \cdot w_m \cdot \max\{0, 1 - \alpha u_m(e)\}$ .
- 신뢰도가 낮은 증거는 필터링되며, 남은 항목들은 공유된 컨텍스트 예산(budget) 하에서 중복 제거 및 순위가 매겨진다.
불확실성 가이드 코드 생성: LLM은 쿼리, 필터링된 증거 집합, 그리고 소스별 불확실성 추적(trace)을 조건으로 하여 후보 코드를 생성한다.
검증 및 불확실성 완화: 생성된 후보들은 정적 검사와 실행 가능한 테스트를 거친다. 첫 번째로 통과하는 후보가 선택된다. 만약 어떤 원본 후보도 통과하지 못하면, 시스템은 "모드(mode)" 후보(가장 큰 자기 일관성 그룹으로부터 추출된 것)를 식별하고 최대 두 차례의 검증 가이드 기반 수리를 수행한다.

또한, 이 프레임워크는 생성 전 단계에서 스스로 검색된 중복되거나 의도와 맞지 않는 API를 제거하기 위해 **타겟 인식 API 정제(Target-Aware API Refinement)**를 사용한다.

주요 기여

정식화: 본 논문은 저장소 수준의 코드 생성을 단순한 관련성 순위 매기기를 넘어, 이질적인 증거에 대한 불확실성 하에서의 의사결정 문제로 정식화한다.
프레임워크: OpenCoder는 소스별 불확실성을 추정하고 이를 증거 필터링, 다중 소스 통합, 생성, 검증 및 수리에 걸쳐 실행 가능한 시스템으로 구현한 통합 시스템이다.
요인 분석(Factorial Analysis): API 지식, 저장소 컨텍스트, 유사 코드 증거에 대한 전체 요인 분석을 통해, 저자들은 검색 유용성이 **상호작작용에 의존적(interaction-dependent)**임을 입증한다. 즉, 모든 소스에 적용되는 보편적인 가산적 순위는 존재하지 않으며, 특정 소스의 가치는 동반되는 증거 및 LLM 백엔드에 따라 달라진다.
통제된 평가: 저자들은 GPT 및 Gemini 백엔드에 대해 실행 가능한 저장소 수준 작업들을 대상으로 엄격한 매칭 평가를 실시하여, 불확실성 인식 프로세싱과 다운스트림 검증/수리의 효과를 분리하여 조사하였다.

실험 결과

평가는 확장된 32개의 매칭된 RepoExec-inline 작업과 10개의 부분 컨텍스트 ExecRepoBench 스트레스 테스트를 활용한다.

GPT 성능: 32개 작업의 RepoExec-inline 세트에서, OpenCoder는 선택된 출력의 정확도를 56.25%(Baseline RAG)에서 78.13%(21.88 퍼센트 포인트 상승, nominal $p = .039$ )로 향상시켰다. 그러나 이는 동일한 증거를 사용하되 불확실성 기반 필터링은 결여된 RAG + Verify/Repair 대조군과 성능이 동일하게 나타났는데, 이는 Baseline RAG 대비 개선 효과가 주로 불확실성 필터링보다는 검증/수리 예산에 의해 주도되었음을 시사한다.
Gemini 성능: Gemini의 경우, OpenCoder, Baseline RAG, 그리고 대조군 사이의 차이는 통계적으로 뒷받침되지 않았다. 대부분의 지표에서 대조군(RAG + Verify/Repair)이 가장 강력한 성능을 보였다.
상호작용 효과: 요인 분석(RQ1) 결과, 단일 증거 소스가 성능에 미치는 통계적으로 유의미한 한계 효과는 관찰되지 않았다. 대신, 유의미한 교차 소스 상호작용이 관찰되었다 (예: GPT의 경우 저장소 컨텍스트와 유사 코드 증거 간의 양의 상호작용).
API 검색: 타겟 인식 정제는 API 세트 검색을 실질적으로 개선하여, GPT의 경우 매크로 F1을 43.4%에서 64.8%로, Gemini의 경우 59.1%로 높였다.
경계 조건: 컨텍스트가 제한된 ExecRepoBench 스트레스 테스트에서는 RAG + Verify/Repair 대조군이 OpenCoder를 실질적으로 앞질렀다. 이는 저장소 증거가 불완전한 시나리오에서 불확실성 인식 필터링이 유용한 대안을 오히려 억제할 수 있음을 나타낸다.

의의 및 주장

본 논문은 불확실성이 고립된 신뢰도 추정치가 아니라, 증거 융합, 실행 가능 검증 및 수리와 결합된 실행 가능한 제어 신호로서 가장 유용하다고 주장한다.

백엔드 의존성: OpenCoder의 이점은 백엔드에 따라 달라진다. GPT의 출력 선택 성능은 Plain RAG보다 크게 개선했으나, 검증 및 수리 대조군에 비해 통계적으로 유의미한 우위를 보이지 못했으며, Gemini에 대해서도 명확한 이점을 보여주지 못했다.
증거 완전성: 프레임워크의 효과는 저장소 증거의 완전성에 달려 있다. 증거가 불완전한 시나리오에서는 불확실성 메커니즘이 필요한 정보까지 의도치 않게 필터링할 수 있다.
실행 가능한 제어: 핵심 기여는 무엇을 검색할 것인가를 최적화하는 것에서, 검색된 증거가 얼마나 신뢰할 수 있는지를 모델링하고 그 신호를 사용하여 필터링과 생성을 가이드하는 것으로의 전환이다.

저자들은 OpenCoder가 불확실성 인식 통합의 잠재력을 보여주지만, 그 이점은 특정 LLM 백엔드와 검색된 저장소 증거의 품질 및 완전성에 따라 달라진다고 결론짓는다. 또한 생성된 코드는 여전히 개발자의 검토와 프로젝트별 테스트가 필요함을 강조한다.