DEV Community

Sanha Ko
Sanha Ko

Posted on

AI 브라우저를 활용한 PR 메세지 자동화

#webdev #programming #ai #productivity

개발자에게 "코드 작성"과 "PR(Pull Request) 작성" 중 무엇이 더 고통스러운지 묻는다면, 의외로 많은 분이 후자를 택합니다. 구현은 즐겁지만, 그것을 남에게 글로 설명하는데는 생각보다 상당한 시간이 소모되기 때문입니다.

최근 Copilot이나 IntelliJ AI 등 다양한 도구가 등장하며 PR 작성을 돕고 있지만, 여전히 '2%' 부족함을 느낍니다. 오늘은 그 부족한 2%를 채우고, 리뷰어와 작성자 모두가 행복해지는 PR 자동화 워크플로우를 공유하고자 합니다.

1. 좋은 Pull Request 란?

기술적인 자동화를 논하기 전에, 우리가 작성해야 할 '좋은 PR'의 정의부터 명확히 해야 합니다.

좋은 PR의 핵심은 '리뷰어에 대한 공감'입니다. 리뷰어는 바쁜 시간을 쪼개서 코드를 봅니다. 리뷰어의 시간을 아껴주고, 코드의 의도를 명확하게 전달하는것이 PR의 가장 중요한 목표입니다.

좋은 PR의 구성요소

  1. 명확한 맥락: 단순히 코드가 '무엇'이 변했는지는 diff만 봐도 알 수 있습니다. 중요한 것은 '왜 이 변경이 필요했는가'입니다.

  2. 직관적 시각 자료: 백 마디 말보다 한 장의 스크린샷이나 다이어그램이 훨씬 빠른 이해를 돕습니다.

  3. 작고 집중된 단위: 하나의 PR은 하나의 이슈만 다루어야 리뷰와 병합의 리스크가 줄어듭니다.

코드 리뷰를 하는 이유 중 하나는 팀원 간의 작업 방향 정렬과 개발 과정에서의 실수 방지입니다.

작업 배경을 상세히 기술하면 리뷰어는 단순히 코드 변경사항만 보는 것이 아니라, 왜 이런 변경이 필요했는지 맥락을 이해할 수 있습니다. 이러한 컨텍스트 공유는 리뷰어가 더 넓은 시야에서 코드를 바라볼 수 있게 하여, 단순 문법적 오류나 컨벤션 위반을 넘어 아키텍처적 개선점, 잠재적 사이드 이펙트, 대안적 접근 방식 등 다양한 관점의 피드백을 제공할 수 있게 됩니다.

결과적으로 배경 설명이 잘 된 PR은 리뷰의 질을 높이고, 팀 전체의 도메인 지식과 시스템 이해도를 향상시키는 효과적인 지식 공유의 수단이 됩니다.

2. 현재 AI Assistant의 한계: '맥락'의 부재

최근의 생성형 AI 도구들(GitHub Copilot, IntelliJ AI 등)은 코드 변경 사항(Diff)을 요약하는 데 탁월한 능력을 보여줍니다. 버튼 하나만 누르면 아래와 같은 요약을 순식간에 만들어냅니다.

Copilot Agent가 생성한 PR

Copilot PR

그러나 AI가 만든 PR 메시지는 초안으로는 충분하지만, 작업의 배경까지는 담아내지 못해 코드 수정의 근본적인 이유를 파악하기 어렵다는 한계가 있습니다.

  • 배경 정보 누락: AI는 코드 자체만 보고 요약하므로, "사용자가 특정 상황에서 겪은 불편함"이나 "기획 의도" 같은 외부 맥락을 알지 못합니다.

  • 근본적 이유 부재: 코드를 '수정했다'는 사실은 알지만, '왜 수정해야만 했는지'에 대한 비즈니스적/기술적 배경은 설명하지 못합니다.

결국, 리뷰어가 가장 궁금해하는 '작업 배경'을 채우는 일은 여전히 사람의 몫으로 남게 됩니다. 그리고 배경을 간결하고 핵심적으로 정리하는 것은 PR 작성에서 가장 많은 시간을 잡아먹습니다.

이 과정을 AI가 대신할 수 있다면, 리뷰어에게 코드의 의도를 명확하게 전달하면서 PR 작성에 드는 시간을 크게 줄일 수 있을 것입니다.

3. Jira 티켓에서 맥락 가져오기

그렇다면 어디서 맥락을 가져올 수 있을까요? 저는 개발을 시작하기 전에 티켓에 해결하고자 하는 문제와 목표를 명확히 정의합니다.

티켓에는 작업을 한눈에 파악할 수 있도록 "무엇을", "왜" 하는지를 간결하게 담습니다. 예를 들어 "주문 취소 시 재고 복구 실패 이슈 수정"처럼 핵심 문제와 해결 방향을 제목에서부터 드러냅니다.

그 다음 작업의 배경과 목적을 상세히 기술합니다. 현재 어떤 문제가 발생하고 있는지(AS-IS), 왜 이 작업이 필요한지, 어떤 비즈니스 영향이 있는지를 구체적으로 작성하고, 작업을 통해 달성하고자 하는 상태(TO-BE)와 명확한 완료 기준을 함께 정의합니다.

"PR 쓰기도 귀찮은데 Jira까지 자세히 쓰라고요?"라고 반문하실 수 있습니다. 하지만 문제 정의는 AI가 아닌 사람이 해야 할 영역입니다. 티켓을 충실히 작성하면 다음과 같은 이점이 있습니다.

작업 전 Jira 티켓을 풍부하게 작성하면 좋은점

  1. 명확한 목표 설정과 작업 집중: "로그인 버그 수정"이라는 한 줄짜리 티켓은 '어떤 상황에서', '어떤 사용자가', '어떻게' 버그를 겪는지 알려주지 않습니다. 상세한 설명, 재현 방법, 기대 결과가 담긴 티켓은 내가 무엇을 해야 하는지 명확히 알려주어 불필요한 고민 없이 작업에만 집중하게 해줍니다.

  2. 정확한 계획 수립과 예측 가능성 확보: 티켓이 상세할수록 작업의 규모와 복잡도를 더 정확하게 예측할 수 있습니다.

  3. 미래의 나를 위한 기록: 몇 달 뒤 내가 작성한 코드를 다시 보게 될 때, Jira 티켓은 "내가 왜 이 코드를 이렇게 작성했더라?"에 대한 완벽한 답변이 되어 줍니다. 유지보수와 기능 확장이 훨씬 쉬워집니다.

4. AI 브라우저로 워크플로우 완성하기

우리의 목표는 "PR 작성에 드는 시간과 노력을 최소화하면서, 퀄리티는 극대화하는 것"입니다. 이를 위해 AI 브라우저인 Commet(혹은 Dia)의 기능을 활용할 수 있습니다.

Commet은 단순한 브라우징을 넘어, 사용자가 자주 사용하는 프롬프트를 'Shotcuts' 형태로 저장하고 /Shotcuts로 호출할 수 있는 기능을 제공합니다. 이를 통해 매번 긴 프롬프트를 작성할 필요 없이, Jira의 문맥과 코드 변경 사항을 결합할 수 있습니다.

자동화 워크플로우

  1. Jira 티켓 작성: 작업 전, 이슈의 배경(Why)과 해결 방안(What)을 Jira에 명확히 기록합니다.

  2. Commet Shortcuts 등록: Commet 브라우저에 PR 자동 생성을 위한 Shortcuts를 등록해줍니다.
    shortcuts

  3. PR 수정 화면에서 Commet의 사이드 패널을 열고 미리 등록해 둔 PR 작성 Shortcuts을 호출
    합니다.

이렇게 하면 AI는 Jira에서 '작업의 의도(Why)'를 가져오고, Git Diff에서 '구현 내용(What)'을 가져와 PR 메시지를 생성해 줍니다.

PR 자동 생성에 사용한 프롬프트

마지막으로 PR 자동 생성에 사용한 프롬프트를 공유드리며 글을 마무리하도록 하겠습니다.

당신은 명확하고 규칙적인 Pull Request 설명을 잘 작성하는 숙련된 소프트웨어 엔지니어입니다.  
당신의 주요 목표는 주어진 Jira 티켓과 PR 세부 정보를 기반으로, 우리 팀의 컨벤션을 **엄격히 준수하는 PR 메시지**를 생성하는 것입니다.

이 페이지의 브랜치 정보를 참고하고, “ABCD”로 시작하는 관련 Jira 티켓을 열어 그 안에 작성된 맥락(context)을 활용해 Pull Request 설명을 작성하세요.  
아래 링크를 통해 Jira 보드에 접속한 뒤, 해당 DPDD 티켓을 검색하여 열 수 있습니다.

Jira 보드 링크:  
`https://jiraboard.atlassian.net/jira/software/c/projects/DPDD/boards/5218?assignee=712020%3A8ef336bd-458e-4630-a79f-d0ea76930601`

PR 메시지는 **한국어로 작성하세요.**

---

### 따라야 할 PR 메시지 템플릿

## 요약 ✍️  
*Jira 티켓과 PR 정보를 기반으로 간결한 요약을 작성하세요.*  
먼저 이번 변경의 **배경과 목적(Why)** 을 설명하고,  
그 다음 **구체적인 변경 내용(What, How)** 을 불릿 포인트로 정리하세요.

이 문서에 포함된 클래스나 주요 구성요소 간의 관계, 역할, 상호작용을 설명하기 위해  
`mermaid` 다이어그램을 코드 블록 안에 렌더링하세요.  
다이어그램은 문서의 변경점과 새롭게 추가된 부분에 초점을 맞추어야 합니다.

**형식(Format):**
- 익숙한 ASCII 문자만 사용합니다. 결과는 고정폭(monospaced) 폰트로 렌더링됩니다.  
- 문서의 **첫 줄과 마지막 줄에는 60개의 “_” 문자로 된 수평선**을 추가합니다.  
- 각 줄은 **최대 60자 이내**로 제한합니다.  
- 파일 관계를 설명할 필요가 있다면 디렉터리/계층 구조를 사용하고,  
  그렇지 않다면 흐름도(Flowchart) 또는 시각적인 형태로 표현합니다.  
- 문서나 내용이 제공되지 않았다면, 내용을 요청하세요.

---

## 리뷰어가 참고하면 좋은 링크 🔗  
- Jira url: [여기에 Jira URL 삽입]

---

## 먼저 읽기 좋은 진입점 🚘️  
*PR 세부 정보를 기반으로, 리뷰 시 가장 먼저 보면 좋은 주요 진입 파일(Controller, Consumer 등)을 나열하세요.*

---

## 리뷰어에게 🙏  
*PR의 복잡한 로직, 트레이드오프, 또는 집중해서 봐주었으면 하는 부분을 짧게 설명하세요.*  
너무 세부적이지 않게, 상위 레벨에서 작성합니다.

---

## 체크 리스트 ✅  
- [x] 테스트 코드를 작성했습니다. (코드 변경이 있는 경우)  
- [x] 커밋 전 SonarLint 분석을 수행했습니다.  
- [x] 셀프 리뷰를 진행했습니다.  
- [x] Jira 티켓을 업데이트했습니다.
Enter fullscreen mode Exit fullscreen mode

Top comments (0)