첫 PR 그날 밤

아이유의 노래 '첫 이별 그날 밤'을 듣다가 '처음'에 대해 생각하게 되었습니다. 입사 후 저의 첫 커밋, 첫 PR(Pull Request)이 생각났어요. 처음 PR을 작성하고, approve를 받아 메인 코드 베이스에 머지했던 그날은 드디어 사회에서 1인분을 하는 사람이 되어간다는 기분에 설레는 마음이 가득했던 것 같습니다.

입사 후 첫 3주동안에는 회사 제품을 사용해보고, 제품 코드를 리딩하는 업무를 진행했습니다. 약 3년정도 진행중인 프로젝트여서 코드 베이스가 크고 복잡했는데요. 가장 먼저 눈에 들어온 부분은 컨벤션의 상태였습니다.

...오잉?! 컨벤션의 상태가...!

가장 처음 작업했던 것은 커밋 메시지를 자동화하고, PR 템플릿을 만든 일이었습니다. 프로젝트를 빠르게 개발하는 것이 가장 중요했던 시기라서 제가 입사하기 전에는 문서화 작업이 많이 부족했는데요. 코드 리뷰르 구두로 진행하고, PR에 관련 작업에 대한 설명이 대부분 없었습니다.

예를들면 이런식...

약 2,000 라인이 넘는 changes임에도 불구하고, PR에 아무런 설명이 없었어요. 3년간의 히스토리를 아무런 기록 없이 넘겨받으려니 엄청 막막했습니다. 그래서 PR에 대한 템플릿을 만들어 최소한으로 남겨놓아야할 정보들을 기록할 수 있도록 만들었어요.

역사적인 첫 PR🥳

PR template

## 작업내역

<!-- 작업내역을 작성해주세요. -->

## 이슈

<!-- 이슈 사항을 작성해주세요. -->

## 고민

<!-- 코드리뷰 시 같이 고민해 봐야 할 사항을 작성해주세요. -->

🎯[Jira](https://)

제가 처음 약식으로 작성한 템플릿인데요. 이 템플릿은 신규 입사자분들이 들어오실 때마다 수정을 거쳐 지금의 형태를 갖추게되었습니다. 약 3년동안 PR템플릿도 이렇게나 발전했네요!

<!-- PR 컨벤션 https://www.notion.so/ -->

# Info

- 관련 문서 : []()
- Jira Ticket : [NRT-](https://)
- 필수 리뷰어 : @
- BE branch : master

# Changes

## 변경 타입

<!-- PR이 어떤 유형의 작업인지 작성자/리뷰어가 한 눈에 파악할 수 있도록 타입을 선택해주세요. -->
<!-- 복수 선택도 가능하지만 PR 크기가 충분히 작지 않다는 의미일 수 있습니다. 한 번 더 검토해주세요! -->

- [ ] 버그 수정
- [ ] 기능 추가
- [ ] 리팩토링
- [ ] 개발 환경 설정
- [ ] 문서 업데이트
- [ ] 테스트 코드 추가
- [ ] 기타 (아래에 설명해주세요)

기타 설명:

### 주요 변경 사항

<!-- 새로 추가된 기능, 수정된 버그, 리팩토링 내용 등 변경 사항을 작성해주세요. -->

## 스크린샷(optional)

<!-- 작업 전후 비교 등의 스크린샷이 있으면 변경사항을 파악하기 수월해집니다. -->
<!-- 이미지를 Drag & Drop 하면 추가됩니다. -->

## 체크포인트

<!-- 해당 PR에서 중점적으로 봐주셨으면 하는 것들을 작성해주세요. -->
<!-- 이 PR이 영향을 미치는 다른 부분이나 기능이 있다면 명시해주세요. -->

# PR Checklist

- [ ] 1. 내 컴퓨터 환경에서 잘 동작함.
- [ ] 2. 브라우저 개발자 도구의 console.log 에러를 확인함.
- [ ] 3. 코드 내의 불필요한 eslint disabled 처리가 없음.
- [ ] 4. 코드 내의 오타가 없음.
- [ ] 5. 새로운 기능에 대한 단위 테스트를 작성하고 실행함.

<!-- 올린 PR은 제일 먼저 스스로 확인해보고 셀프 리뷰를 남겨보세요. -->
<!-- Label 지정 부탁드립니다~! -->

우선, 해당 룰을 세팅하게 된 논의 과정을 기록해 놓은 노션 문서를 주석에 링크하여 논의에 참석하지 않은 분들도 히스토리를 파악할 수 있게 해놓았습니다. PR을 되도록이면 작은 크기로 가져가자는 의미에서 하나의 PR에는 하나의 변경사항만 담겨있는지 인지하기 위한 체크박스를 추가했어요. 그리고 PR을 오픈하기 전에 체크리스트의 항목들을 확인해서 혹여나 놓치는 부분이 없도록 해두었어요. 코드 리뷰 문화를 정착시키기 위해서 코드 리뷰에 들어가는 오버헤드를 줄여야 했고, 최대한 리뷰어를 배려하는 형태로 발전되었습니다.

PR template 적용 가이드

이 글에는 PR template을 적용한 상세한 방법은 기술하지 않았습니다. PR template 항목을 참고하세요!

commitzen

제가 입사하면서 팀의 컨벤션을 하나하나 다시 세팅하기 시작했는데요. 컨벤션의 핵심은 자동화라는 것을 이때 처음 깨달았던 것 같습니다. 열심히 논의해서 10개의 컨벤션을 정했는데, 자동화가 되지 않으면 이걸 다 기억하기도 힘들고 매번 지적하고 고치는 작업도 쉬운 일이 아니었어요.

그래서 커밋할 때에는 컨벤션 도입의 비용을 줄이고, 통일성을 맞추기 위해 자동화 라이브러리 commitizen을 활용했습니다. commitizen을 글로벌로 설치하여 사용할 수도 있지만, 프로젝트에 설치하여 저희만의 커밋 컨벤션을 적용했어요.

const custom = require("@digitalroute/cz-conventional-changelog-for-jira/configurable");

module.exports = custom({
  jiraMode: true,
  maxHeaderWidth: 64,
  maxLineWidth: 100,
  jiraPrefix: "NRT",
  skipScope: true,
  types: {
    feat: {
      description: "로직 추가, 변경, 삭제 등의 기능 작업",
      title: "feat",
    },
    refact: {
      description: "동작은 동일하나 내부 로직이 변경된 리팩토링",
      title: "refact",
    },
    bugfix: {
      description: "의도된 동작과 다르게 구현된 버그 수정",
      title: "bugfix",
    },
    typo: {
      description: "오타 수정, 번역, 주석 추가 등 로직과는 무관한 타이핑 작업",
      title: "typo",
    },
    style: {
      description: "로직이 아닌 스타일 변경",
      title: "style",
    },
    test: {
      description: "테스트코드 작성",
      title: "test",
    },
    chore: {
      description: "그 외 작업",
      title: "chore",
    },
  },
});

title과 그에따른 description을 설정하여 feat과 refact의 차이를 일일이 기억할 필요가 없도록 했고, jiraMode를 true로 설정하여 JIRA 이슈와 연동할 때 대소문자에 신경 쓰지 않도록 했습니다.

실제 사용 예시

커밋 명령어를 작성하면 위와 같이 커스터마이징한 커밋 메세지를 볼 수 있습니다.

좋은 개발 문화를 위한 1보👣

문서화의 중요성을 가장 크게 느끼는 지점은 프로젝트에 새로 합류한 팀원이 있을 때가 아닌가 싶은데요. 제가 당시 신규 입사자의 입장이어서 더 크게 느꼈던 것 같습니다.

돌아보니 좋은 개발 문화에 타인을 배려한 이런 작업들도 중요한 부분이라는 생각이 드네요. 제가 생각하는 좋은 개발 문화를 주도적으로 도입한 경험은 지금도 회사에서 일할 때 좋은 영향을 미치는 것 같습니다.

노래를 듣다가 별안간 문서화의 중요성을 상기하게 되네요.

수고했어 PR~ 고생했지 나의 PR~ 🎶