ossca 3주차 과제로 우리 조는 /improve 기능의 설정 분석, 코드 구조 이해, 실습, 정리를 맡았다.
그 중 나는 /improve 내부 로직 중 핵심 기능인 dual_publishing 부분을 맡아,
실제 코드를 하나하나 뜯어보며 기능이 어떻게 작동하는지 분석하고 실험했다.
이 글은 그 과정을 정리한 내용이다.
먼저 간단하게 다시 /improve 기능을 살펴보자면,
/improve란?
/improve
이 improve tool은 PR 코드 변경 사항을 스캔하고 PR 코드 개선을 위한 의미 있는 제안을 자동으로 생성한다. 이 도구는 새 PR이 열릴 때마다 자동으로 실행되거나, PR에 댓글을 남겨 수동으로 실행할 수 있다.
그렇다면 이제 /improve의 dual_publishing이 무엇인지, 어떻게 돌아가는지 살펴보자!
[1] 어떻게 구현되어 있는가
위치 : pr_agent/tools/pr_code_suggestions.py
dual_publishing()은 중요한 제안은 별도의 PR 댓글로 표시되게 하는 기능이다.
1) dual_publishing 시스템 관련 코드 확장 프로세스 플로우
전체 실행 흐름
1. PRCodeSuggestions.run() 실행
- PR에 변경된 파일이 없으면 아무 작업도 하지 않고 종료됨
- 이 조건을 통과하면 PR 정보를 기반으로 GPT에 넘길 준비를 함
2. GPT 모델에서 코드 제안 받기
- 내부적으로
self.prepare_prediction_main()실행 →_get_prediction()호출됨 - 여기서 PR의 diff, commit message, description 등을 조합해 프롬프트 생성 → LLM에게 요청
3. 코드 제안 유무 확인
- GPT가 코드 제안을 하지 않은 경우 종료
- 사용자는 "제안 없음" 메시지를 보게 됨
4. PR 코멘트용 텍스트 생성 및 게시
- 요약 테이블 형태로 정리된 코드 제안이 PR의 첫 코멘트로 게시됨
- (여기까지가 기본 동작임)
5. dual_publishing 조건 체크 및 호출
- 설정 파일이나
/improve --xxx에서 threshold 값이 0보다 클 때 실행됨
2) dual_publishing(data) 살펴보기
전체코드
1. 초기화
data_above_threshold = {'code_suggestions': []}- 중요한 제안만 따로 수집할 리스트 초기화
2. 반복문 시작
for suggestion in data['code_suggestions']:
- GPT가 생성한 모든 제안 하나하나 검사 시작
3. 조건 분기: 점수와 개선 코드 존재 여부
if int(suggestion.get('score', 0)) >= threshold and suggestion.get('improved_code'):
- score가 threshold 이상이고 improved_code가 있을 경우만 다음 단계 진행
4. fallback 처리
if not suggestion['existing_code']:
suggestion['existing_code'] = suggestion['improved_code']
- GitHub API는 리뷰 줄 기준이 되는 기존 코드가 꼭 필요함 → 없으면 improved_code로 채움
5. 제안 저장
data_above_threshold['code_suggestions'].append(suggestion)
- 필터링 조건을 통과한 suggestion만 저장
6. 최종 제출
await self.push_inline_code_suggestions(data_above_threshold)
self.git_provider.publish_code_suggestions(...)을 통해 GitHub에 각 제안을 해당 코드 라인에 코멘트로 등록
+) 예외 처리
except Exception as e:
get_logger().error(...)
- GitHub API 오류, 포맷 오류 등 방지용
[2] 왜 이런 설정이 필요한가
(1) 문제 상황 (없었을 경우 발생할 수 있는 문제)
- 모든 제안을 인라인으로 표시한 경우, PR에 너무 많은 코멘트가 쌓여 가독성이 저하된다.
- 중요한 제안이 다른 사소한 제안에 묻혀버려 리뷰어가 핵심 이슈를 놓칠 수 있다.
- 리뷰 코멘트가 코드 흐름을 방해하며 리뷰 효율이 떨어진다.
(2) 이 설정이 해결하는 목적
- 점수 기반 필터링으로 중요한 제안만 인라인으로 표시해, 리뷰 집중도와 가독성을 높인다.
- 덜 중요한 제안은 요약 테이블으로 통합하여 PR 코멘트의 시각적 노이즈 최소화한다.
- 리뷰어가 핵심 이슈에 빠르게 접근할 수 있어 코드 리뷰 속도와 품질이 향상된다.
- 다른 대안과의 비교 (있다면)
| 방식 | 특징 | 장점 | 단점 |
|---|---|---|---|
| 테이블만 출력 | 모든 제안을 하나의 테이블로 요약하여 PR 첫 코멘트에 게시 | - 전체 제안 목록 한눈에 파악- PR 코멘트가 깔끔하게 유지 | - 구체 위치 확인 위해 코드→테이블 이동 반복- 문맥 정보 손실 |
| 모든 인라인 표시 | GPT가 생성한 모든 제안을 해당 코드 줄마다 인라인 코멘트로 게시 | - 코드 컨텍스트에서 즉시 피드백 확인- 수정 포인터 명확 | - 과도한 댓글로 PR 산만- 사소한 제안까지 모두 노출로 피로도 증가 |
| Dual Publishing | 점수(threshold) 기준으로 중요한 제안은 인라인, 나머지는 테이블로 게시 | - 중요한 제안 강조 + 잔여 제안 요약- 리뷰 효율·가독성 모두 향상 | - threshold 값 선정 및 실험 필요 |
| Committable 코드 제안 모드 | 요약 테이블 없이, “커밋 가능한 코드 블록” 제안만 PR 코멘트로 게시 | “Apply Suggestion” 버튼으로 즉시 코드 반영 - 빠른 수정 가능 | - 전체 제안 개요 파악 어려움 - code context 외부 감상難 |
[3] 테스트
dual_publishing_score_threshold 값을 비교해가며 /improve가 어떻게 동작하는지 테스트 해보자!
(1) dual_publishing_score_threshold의 작동 원리
dual_publishing_score_threshold는 AI가 생성한 코드 개선 제안 중 ‘중요한 것’만 PR 코드 라인에 인라인 코멘트로 표시하기 위한 기준이다.
이 설정은 코드 리뷰의 가독성을 높이고, 핵심 제안에 리뷰어가 빠르게 집중할 수 있도록 돕는다.
(2) AI의 판단 방식: self-reflection scoring
- PR의 코드 변경 사항(diff)을 기반으로 GPT가 다수의 개선 제안을 생성한다.
- 각 제안은 내부적으로 self-reflection scoring 과정을 통해 score (0~10) 가 부여된다.
- 예:
print("debug")제거 → score: 5file open에with사용 권장 → score: 7- 사소한 리팩토링 → score: 2
- 예:
- 이 score는 AI가 스스로 "내가 만든 제안이 얼마나 중요하고 유용한가?" 를 판단한 결과이다.
dual publishing 조건 분기
[pr_code_suggestions]
dual_publishing_score_threshold = 3- score ≥ threshold: 인라인 코멘트로 표시 (PR 줄 위에 직접 뜸)
- score < threshold: PR 코멘트에 테이블 형태로만 요약됨
- 테스트 PR 작성
첫 번째 case : dual_publishing_score_threshold = 3
(현재 설정에서는 중요도(score)가 3 이상으로 평가된 코드 제안만, GitHub PR 코드 줄 위에 직접 인라인 코멘트로 표시됨)
(secrets.toml에 값 추가 및 수정)
Use with-statement and specific exception과 같은 표 내용들은 3점을 넘지 않아 표로 표시되고,
debug1, debug2 제거한 부분은 importance가 5점 (즉, score가 3점 이상)이므로 인라인 코멘트로 남겨짐을 볼 수 있다.
두 번째 case : dual_publishing_score_threshold = 7
높은 중요도(importance ≥ 7)만 인라인 코멘트로 표시되는 모습을 알 수 있다.
(예: importance: 5인 debug 제거는 테이블에만 있고, importance: 8인 try-except 관련 제안만 인라인 표시됨)
세 번째 case : dual_publishing_score_threshold = -1
threshold < 0(예: –1)일 때는 dual publishing 단계가 건너뛰어져, 인라인 코멘트가 전혀 생성되지 않고 모든 제안이 요약 테이블에만 포함된다.
정리
| 실험 조건 | threshold | 결과 요약 |
|---|---|---|
| 모든 제안 테이블만 표시 | -1 | 인라인 없음 |
| 일반적 dual 사용 | 3 | 일반 제안은 테이블, 일부 중요 제안은 인라인 |
| 보수적 인라인 제한 | 7 | 아주 중요한 제안만 인라인 표시됨 |
결론 : threshold 값을 조정함으로써, 팀의 리뷰 정책에 따라 AI 제안의 가시성과 중요도를 균형 있게 조절할 수 있다!
