💻 computer science

Combining Example-Based and Rule-Based Program Transformations to Resolve Build Conflicts

이 논문은 예제 기반과 규칙 기반 변환을 결합한 'BuCoR'이라는 새로운 도구를 제안하여, 기존 도구들의 한계를 극복하고 다양한 빌드 충돌을 효과적으로 해결하는 방법을 제시합니다.

원저자: Sheikh Shadab Towqir, Fei He, Todd Mytkowicz, Na Meng

게시일 2026-02-13

📖 3 분 읽기☕ 가벼운 읽기

원저자: Sheikh Shadab Towqir, Fei He, Todd Mytkowicz, Na Meng

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

🍳 문제 상황: 두 명의 요리사가 같은 요리를 만들다

소프트웨어 개발은 마치 요리와 같습니다.

메인 요리 (프로젝트): 우리가 만드는 최종 요리입니다.
두 명의 요리사 (개발자): 한 명은 '왼쪽 (Left)'에서, 다른 한 명은 '오른쪽 (Right)'에서 각자 요리를 발전시킵니다.
기본 레시피 (Base): 두 요리사가 시작하기 전에 공유하던 원래 레시피입니다.

이제 두 요리사가 각자 만든 요리를 하나로 합치려 할 때 (Merge), 문제가 생깁니다.

왼쪽 요리사는 **'소금'**을 추가했습니다.
오른쪽 요리사는 **'소금'**이라는 재료를 **'간장'**으로 이름을 바꿨습니다.

이 두 가지를 그냥 섞으면? 소금과 간장이 동시에 들어간 이상한 요리가 됩니다. 혹은 소금이라는 재료가 사라졌는데 소금을 넣으라고 해서 요리가 망가집니다 (빌드 충돌).

기존 도구들은 이 문제를 발견은 했지만, "어떻게 고칠지" 알려주는 데는 한계가 있었습니다. 대부분 "소금을 간장으로 바꿔라"라고만 말해줄 뿐, 그로 인해 생기는 다른 문제들 (예: 소금통의 모양이 바뀌었으니 그릇도 바꿔야 함) 을 해결해주지 못했습니다.

🛠️ 해결사 등장: BuCoR(부코르)

이 논문은 BuCoR이라는 새로운 도구를 소개합니다. BuCoR 은 두 가지 똑똑한 비서를 합쳐서 문제를 해결합니다.

1. 비서 A: 규칙 기반 해결사 (BuCoR-R)

이 비서는 교과서와 매뉴얼을 잘 외운 사람입니다.

방식: "소금이 간장으로 바뀌면, 무조건 간장으로 바꿔라", "재료가 사라지면 다시 추가해라"처럼 정해진 16 가지 규칙을 따릅니다.
장점: 자주 일어나는 단순한 실수는 아주 빠르고 정확하게 고쳐줍니다.
한계: 상황에 따라 예외가 생기거나, 교과서에 없는 복잡한 문제 (예: 소금통을 간장통으로 바꾸되, 그릇도 바꿔야 하는 경우) 는 해결하지 못합니다.

2. 비서 B: 예시 기반 해결사 (BuCoR-E)

이 비서는 **과거의 성공 사례 (예시)**를 분석하는 탐정입니다.

방식: "아, 이 프로젝트에서 과거에 '소금'을 '간장'으로 바꿀 때, 요리사들이 어떻게 다른 재료들도 함께 고쳤지?"라고 과거 기록을 뒤져봅니다.
- 과거 기록을 보니, 소금을 간장으로 바꿀 때 소금통 이름도 바꾸고, 레시피 설명도 고쳤던 것이 발견됩니다.
- 비서는 이 패턴을 학습해서, 지금의 문제에도 똑같이 적용합니다.
장점: 교과서에 없는 복잡한 상황이나, 프로젝트만의 특별한 방식 (맥락) 을 잘 이해해서 고쳐줍니다.
한계: 과거에 비슷한 실수가 기록되어 있지 않으면 해결책을 제시하지 못합니다.

🎯 BuCoR 의 작동 원리: 두 비서의 협업

BuCoR 은 이 두 비서를 동시에 가동합니다.

충돌 감지: 두 요리사의 레시피를 비교해서 "어? 여기가 안 맞네?"라고 문제를 찾아냅니다.
전략 선택:
- 만약 과거에 비슷한 실수가 있었다면? → **비서 B(예시)**가 "이렇게 고치면 돼!"라고 제안합니다.
- 만약 과거 기록이 없거나 너무 단순한 문제라면? → **비서 A(규칙)**가 "교과서대로 고치자!"라고 제안합니다.
최종 제안: 두 비서가 서로 다른 해결책을 제시할 수도 있고, 한쪽만 해결책을 제시할 수도 있습니다. 개발자는 이 제안들을 보고 가장 적절한 것을 선택하면 됩니다.

📊 실제 성과: 얼마나 잘했을까?

연구진은 실제 오픈소스 프로젝트 30 개에서 발생한 **88 개의 복잡한 요리 실패 사례 (충돌)**를 가지고 BuCoR 을 테스트했습니다.

성공률: 88 개 중 65 개에서 해결책을 찾아냈습니다 (약 74%).
정확도: 찾아낸 해결책 중 34 개는 개발자가 실제로 원하던 방식과 완벽하게 일치했습니다.
핵심 발견: 규칙만으로는 해결되지 않는 복잡한 문제들을 과거 예시를 분석하는 방식이 잘 해결해주었고, 반대로 예시가 없는 단순한 문제들은 규칙이 잘 처리했습니다. 즉, 두 방식이 서로를 보완해준 것입니다.

💡 결론

BuCoR 은 **"규칙 (교과서)"**과 **"경험 (과거 사례)"**을 모두 활용하는 똑똑한 도구입니다.

기존에는 개발자가 "왜 이 레시피가 안 먹히지?"라고 고민하며 밤을 새웠다면, BuCoR 은 "이전에 이런 실수 했을 때 이렇게 고쳤잖아!" 혹은 **"이런 경우는 이렇게 고치는 게 정석이야!"**라고 알려주어 개발자의 시간을 아껴주고, 더 맛있는 요리 (안정적인 소프트웨어) 를 만들어낼 수 있게 도와줍니다.

이 연구는 소프트웨어 개발의 자동화를 한 단계 더 끌어올렸으며, 앞으로는 더 지능적인 도구들이 개발될 것임을 시사합니다.

BuCoR: 빌드 충돌 해결을 위한 예제 기반 및 규칙 기반 프로그램 변환의 결합에 대한 기술 요약

이 논문은 소프트웨어 병합 (Merge) 과정에서 발생하는 **빌드 충돌 (Build Conflicts)**을 자동으로 해결하기 위한 새로운 도구인 **BuCoR (BUild COnflict Resolver)**을 제안합니다. 기존 도구들이 주로 텍스트 충돌이나 심볼 리네임 (Symbol Renaming) 에만 초점을 맞췄다면, BuCoR 은 예제 기반 학습 (Example-Based) 과 규칙 기반 (Rule-Based) 접근법을 결합하여 더 복잡하고 다양한 빌드 충돌을 해결합니다.

1. 문제 정의 (Problem)

소프트웨어 개발에서 여러 브랜치 (Branch) 의 변경 사항을 통합할 때, 텍스트적 충돌뿐만 아니라 빌드 오류를 유발하는 충돌이 발생합니다.

빌드 충돌의 원인: 한 브랜치에서 정의 (Definition, 예: 클래스, 메서드) 를 수정하거나 삭제한 반면, 다른 브랜치에서는 해당 정의의 사용 (Use) 을 추가하거나 수정하는 경우 발생합니다.
기존 도구의 한계:
- 기존 도구 (Gmerge, MrgBldBrkFixer 등) 는 주로 심볼 리네임에 국한되어 해결책을 제시합니다.
- 클래스 계층 구조 변경, 메서드 추가/삭제, 파라미터 변경 등 더 복잡한 충돌 유형을 처리하지 못합니다.
- 단순한 심볼 교체만 제안할 뿐, 주변 문맥 (Context) 을 고려한 체계적인 코드 수정을 제안하지 못합니다.

2. 방법론 (Methodology)

BuCoR 은 병합 시나리오와 관련된 세 가지 버전 (Base $b$ , Left $l$ , Right $r$ ) 을 입력받아 충돌을 감지하고 해결합니다. 핵심 아키텍처는 충돌 감지, 그래프 구성, 예제 기반 변환 (BuCoR-E), **규칙 기반 변환 (BuCoR-R)**으로 구성됩니다.

2.1 충돌 감지 및 그래프 구성

Bucond 활용: 기존 정적 분석 도구인 Bucond 를 사용하여 세 버전 간의 엔티티 수준 (클래스, 메서드 등) 편집을 추출하고 57 가지 충돌 패턴과 매칭하여 충돌을 감지합니다.
4-way 연결 그래프: Git-merge 를 통해 생성된 자동 병합 버전 ( $A_m$ ) 과 입력된 세 버전 ( $b, l, r$ ) 에 대한 프로그램 엔티티 그래프 (PEG) 를 생성합니다. 이 그래프들은 서로 연결되어 문맥 정렬 (Context Alignment) 을 지원하며, 충돌 해결 시 편집 위치를 정확히 파악하는 데 사용됩니다.

2.2 예제 기반 변환 (BuCoR-E)

개발자가 기존 브랜치에서 빌드 오류를 해결하기 위해 적용한 **실제 편집 예제 (Exemplar Edits)**를 학습하여 충돌을 해결하는 방식입니다.

예제 마이닝 (Example Mining): 충돌을 일으킨 정의 변경 (Def-change) 을 식별하고, 해당 변경을 수용하기 위해 개발자가 브랜치 내에서 적용한 편집 예제를 찾습니다.
패턴 추론 (Pattern Inference):
- 편집 정제: 정의 변경과 관련된 사용 (Use) 편집만 추출하고, 불필요한 편집은 제거합니다.
- 문맥 정제: 제어 의존성 (Control Dependency) 과 데이터 의존성 (Data Dependency) 분석을 통해 필수적인 편집만 남기고 추상화된 **변환 패턴 (Transformation Pattern)**을 도출합니다.
패턴 적용 (Pattern Application):
- 도출된 패턴을 병합된 버전 ( $A_m$ ) 의 코드 문맥과 매칭합니다.
- **중요 노드 (Critical Nodes)**를 기준으로 하향식 (Bottom-up) 매칭 알고리즘을 사용하여 패턴이 적용 가능한지 판단합니다.
- 매칭 점수 (Type Match, Value Match) 를 기반으로 최적의 패턴을 선택하여 AST(추상 구문 트리) 를 재작성합니다.

2.3 규칙 기반 변환 (BuCoR-R)

브랜치에 적절한 예제가 없거나, 일반적인 해결 패턴이 명확한 경우를 위해 설계된 방식입니다.

16 가지 규칙 정의: 기존 연구와 실증 데이터를 바탕으로 16 가지의 전형적인 충돌 유형 (예: 클래스 리네임, 인터페이스 메서드 추가, 필드 삭제 등) 에 대한 해결 규칙을 정의했습니다.
적용: 감지된 충돌 유형이 규칙 집합과 매칭되면, 해당 규칙에 따라 엔티티의 정의나 사용을 수정하는 AST 편집을 수행합니다.

3. 주요 기여 (Key Contributions)

BuCoR 도구 개발: 예제 기반 학습과 규칙 기반 해결을 결합한 최초의 빌드 충돌 해결기 개발.
BuCoR-E 의 고도화: 단순한 심볼 교체를 넘어, 의존성 분석을 통해 프로젝트 특유의 해결 패턴을 학습하고 문맥에 맞춰 적용하는 고급 예제 기반 접근법 제시.
포괄적인 규칙 집합: 심볼 리네임뿐만 아니라 클래스 계층, 파라미터 변경 등 16 가지 다양한 충돌 유형을 해결하는 규칙 집합 구현.
체계적 평가: 30 개의 오픈소스 프로젝트에서 수집된 88 개의 실제 빌드 충돌 (21 가지 유형) 을 대상으로 한 대규모 평가 수행.

4. 실험 결과 (Results)

30 개 오픈소스 프로젝트의 88 개 빌드 충돌을 대상으로 실험한 결과는 다음과 같습니다.

커버리지 (Coverage): BuCoR 은 88 개 충돌 중 **65 개 (74%)**에 대해 적어도 하나의 해결책을 생성했습니다.
- BuCoR-E: 28 개 (32%)
- BuCoR-R: 51 개 (58%)
- 두 전략은 상호 보완적으로 작용했습니다.
정확도 (Accuracy): 생성된 해결책 중 개발자의 수동 해결 (Ground Truth) 과 의미적으로 일치하는 비율은 **52% (41/79)**였습니다.
- BuCoR-E: 75% (21/28) - 프로젝트 특유의 해결책을 잘 모방하여 정확도가 높음.
- BuCoR-R: 39% (20/51) - 일반적인 규칙 적용이 가능하지만 개발자의 의도와 다를 수 있음.
유용성: BuCoR-E 는 비전통적이고 프로젝트 특유의 해결책을, BuCoR-R 은 전통적이고 일반적인 해결책을 제공하여 서로 다른 유형의 충돌에 효과적이었습니다.

5. 의의 및 결론 (Significance)

자동화의 한계 극복: 기존 도구들이 처리하지 못했던 복잡한 빌드 충돌 (클래스 계층 변경, 파라미터 수정 등) 을 해결할 수 있는 가능성을 입증했습니다.
하이브리드 접근법의 효과: 예제 기반 학습 (유연성) 과 규칙 기반 접근 (안정성) 을 결합함으로써, 다양한 충돌 상황에서 높은 커버리지와 정확도를 동시에 달성할 수 있음을 보였습니다.
미래 방향: BuCoR 은 소프트웨어 병합 도구의 지능화와 자동화 발전에 중요한 통찰을 제공하며, 향후 규칙 집합 확장 및 예제 마이닝 능력 향상을 통해 성능을 더욱 개선할 수 있습니다.

이 연구는 개발자가 병합 과정에서 발생하는 복잡한 빌드 오류를 수동으로 수정하는 시간을 단축하고, 소프트웨어 품질을 유지하는 데 실질적인 도움을 줄 수 있는 도구임을 입증했습니다.