프로젝트 전체에 코드 포맷팅 적용하기

Seungah Cheon
원티드랩 기술 블로그
10 min readAug 26, 2021
Photo by Chris Barbalis on Unsplash

편한 개발, 빠른 리뷰를 위해

목차

  1. 작업 배경
  2. 진행 방법
  3. 느낀 점
  4. 마치며
  5. 참고

안녕하세요. 원티드 프론트엔드팀에서 첫 커리어를 시작하게 된 주니어 개발자입니다. 🌱

저는 입사 후 운영 이슈 처리와 함께 코드 포맷팅 업무를 진행하고 있습니다.

그동안의 포맷팅 진행 과정과 업무 파악에 어떻게 도움이 되었는 지 기록하고, 공유하려 글을 작성하게 되었습니다.

프로젝트에 포맷팅을 일괄적으로 적용해야하는 상황에서도 제 경험이 도움이 되길 바랍니다.

작업 배경

원티드 프론트엔드팀은 Prettier와 ESLint를 설정하여 문법을 검사하고 코드를 정리하고 있습니다.

하지만 프로젝트의 히스토리가 길어지고 몇몇 설정이 더 효율적으로 바뀌게 되면서, 최신 포맷팅 설정이 적용되지 않은 파일이 많아졌고 문제점이 발생했습니다.

문제점

  1. 변경사항 추적이 어렵다.
  2. 자동 포맷팅과 작업 내용이 같이 보여지므로 PR 리뷰에 소요되는 시간이 길어진다.
[PR] 실제 변경 사항은 50줄 내이고, 나머지 변경 사항은 자동 포맷팅 내용인 PR
[PR] 포맷팅 변경 사항 중 하나

2020년, 해결 방안 논의

이를 해결하기 위해 다양한 의견이 있었고, VSCode setting.json 설정을 통해 파일을 저장할 때 포맷팅을 자동으로 적용하기로 최종 결정했습니다.

  1. 한번에 포맷팅을 적용한다. ->코드 충돌이 발생하고 히스토리 파악이 힘들 것
  2. 포맷팅 커밋과 작업 커밋을 분리해서 작업한다. -> 개발 시 하나의 룰이 추가되는 것이므로 혼란스러울 것 같음
  3. onSave 이벤트 발생 시 자동 포맷팅 되도록 설정하여 부분적으로 적용한다. ✅

setting.json

{
"editor.tabSize": 2,
"editor.insertSpaces": true,
"[javascript]": {
"editor.formatOnSave": true
},
"editor.codeActionsOnSave": {
"source.fixAll.eslint": true
},
"eslint.alwaysShowStatus": true
}
  • editor.formatOnSave : 저장 시 포맷팅을 적용한다.
  • editor.codeActionsOnSave : 저장 액션일 때 ESLint 오류를 수정한다.

2021년, 전체적인 코드 포맷팅 작업 결정!

원티드 프론트엔드팀은 PR 리뷰와 승인을 통해 작업이 최종 반영되므로 👍 팀원들의 리뷰 과정이 엄청 중요한데요!

부분 적용을 하더라도, 프로젝트의 규모가 크고 팀에 합류하는 인원도 늘어나게 되면서 포맷팅 때문에 PR 리뷰 과정이 어렵다는 의견이 꾸준히 있었습니다.

때문에 히스토리 파악이 조금 힘들어지더라도 PR 리뷰 간소화를 위해 전체 포맷팅을 한번에 적용하자는 결론이 나왔습니다. (전체 적용 결과 리뷰에 소요되는 시간 1달에 2.25 시간 단축 예정)

그리고 이 작업을 제가 담당하게 되었습니다. 👩‍💻

진행 방법

포맷팅 작업의 전체적인 진행 방법은 다음과 같습니다.

1️⃣ 포맷팅 범위 설정 → 2️⃣ 팀에게 알림 → 3️⃣ JIRA 이슈 생성 → 4️⃣ 포맷팅 적용 & 테스트 → 5️⃣ PR 리뷰 → 6️⃣ 문서화 → 7️⃣ 1~6번 반복

1. 포맷팅 범위 설정

이슈로 생성할 포맷팅 작업 범위를 설정합니다.

하나의 이슈에 너무 적거나, 특히 많은 범위를 포함되지 않도록 주의하고 있습니다. 포맷팅에 의해 문제가 발생 했을 때 이유가 된 부분을 추적하고 롤백 하기 어렵기 때문입니다.

보통 디렉터리 단위로 정하며, 아래와 같이 묶여있는 폴더의 성격에 따라 더 자세히 나누게 됩니다.

1. 같은 페이지에 있는 컴포넌트 파일들

  • src/pageComponents/Home : 메인 페이지

2. 유사한 기능, 로직을 수행하는 파일들

  • src/core/Route : route에 관한 컴포넌트, 라우팅 기능
  • src/lib/validate : 유효성 검사 기능

2. 팀에게 알림

진행 예정인 포맷팅 범위를 팀에게 알립니다. 진행 상황을 공유하고, 또 해당 범위를 작업하고 있는 팀원이 있는 지 파악하여 충돌 가능성을 최대한 줄이기 위함 입니다.

[Slack 팀 채널] 진행 예정 범위 알림 (혼자 약간 슬랙봇인 척 하는 것에 빠져있어요…)
[Slack 팀 채널] 진행 예정 범위 알림 & 수정

3. JIRA 이슈 생성

팀의 확인을 받은 후 JIRA 이슈를 생성하고, 작업할 branch도 생성합니다.

[JIRA] 포맷팅 이슈 생성

4. 포맷팅 적용 & 테스트

프로젝트의 Prettier, ESLint 설정값에 따라 포맷팅을 적용합니다.

먼저 원하는 부분만 작업하기위해, package.jsonscripts에서 prettier 스크립트를 이전에서 설정한 범위의 폴더 단위 경로로 수정합니다.

기본값은 ./src/**/*.js (src 아래의 모든 *.js 파일)로 설정되어 있습니다. /**/*.js는 하위 폴더를 포함한 모든 *.js 파일을 의미합니다.

"prettier": "prettier --write --config ./.prettierrc '[폴더 경로]'"

예를 들어 src/core/Route를 작업한다고 가정 했을 때, 아래와 같이 수정하고

"prettier": "prettier --write --config ./.prettierrc './src/core/Route/**/*.js'"

yarn prettier 명령어를 실행하면 src/core/Route에 있는 파일들만 포맷팅이 적용됩니다! 🎉

ESLint는 eslint-config-airbnb를 설치하여 airbnb 코드 스타일을 사용하고 .eslintrc.json 파일을 통해 세부 설정을 커스텀하여 사용하고 있습니다.

Prettier는 .prettierrc 파일을 설정하여 사용합니다.

.prettierrc

{
"printWidth": 100,
"semi": true,
"useTabs": false,
"singleQuote": true,
"trailingComma": "all",
"tabWidth": 2,
"bracketSpacing": true,
"jsxBracketSameLine": true
}
  • printWidth: 한줄에 100줄이 넘지 않도록 합니다.
  • semi: 코드는 항상 ; (semi-colon)으로 끝나도록 합니다.
  • useTabs: 탭은 사용하지 않습니다. (대신 스페이스 사용)
  • singleQuote: 문자열 사용 시 (single Quote)를 사용합니다.
  • trailingComma: 객체나 배열을 작성 할 때, 원소 혹은 key-value 의 맨 뒤에 있는 것에도 쉼표를 추가합니다.
  • tabWidth: 들여쓰기 크기는 2칸으로 합니다.
  • bracketSpacing: 대괄호 사이에 공백을 넣습니다.
  • jsxBracketSameLine: jsx의 > 를 같은 줄에 넣습니다.

다음은 위와 같이 설정하면 어떻게 코드가 포맷팅 되는 지 보여주는 간단한 예시입니다. 차이가 느껴지시나요?

포맷팅 전 버튼 컴포넌트 (예시)
포맷팅 후 버튼 컴포넌트 (예시)

불필요한 개행이 제거되고 코드의 끝에 생략 되었던 ,;, 그리고 ()가 추가되었습니다. 실제 작업 내용이 없는데, 이런 간단한 코드에서도 포맷팅만으로 +5 -9 의 라인의 수정이 생겼습니다. 실제 코드는 더 규모가 크고 복잡하므로 포맷팅에 의한 변경 사항이 훨씬 많고, 리뷰를 어렵게 만들 것입니다. 😠

적용이 끝나면 충돌이 발생하거나 변경된 로직이 있는 지 검사합니다.

또한 테스트 코드 사용, 관련된 UI 확인, 관련된 기능 확인 등 여러 방법으로 사이드 이펙트가 발생하지 않도록 꼼꼼히 테스트하고 있어요.

컴포넌트 파일이면 UI 확인, 헬퍼 함수들이 있는 파일이면 로직 변경 확인에 더 주의하는 등 포맷팅한 부분의 성격에 따라서 유동적으로 테스트 합니다.

5. PR 리뷰

포맷팅 변경 사항도 결국은 PR! 변경 내용에 문제가 없는 지 리뷰와 승인을 받습니다.

[PR] 포맷팅 PR 리뷰

6. 문서화

PR 승인을 받고 하나의 포맷팅 작업이 완료되고 나면 컨플루언스에 진행 상황을 문서로 정리합니다.

진행 완료 표시 뿐만이 아니라 해당 JIRA 이슈(branch), 간단한 설명, 포맷팅 중 발생한 이슈, 경로 등을 함께 작성하며 코드를 이해하고 히스토리를 남기려 노력합니다.

[컨플루언스] 포맷팅 진행 상황 문서 중 일부

7. 1~6번 반복

이렇게 1~6번 과정을 반복하고, 포맷팅 중 발견한 버그나 개선점이 생기면 따로 이슈를 만들어 처리하고 있습니다! 🏃‍♀️

느낀 점

1. 포맷팅의 중요성

다시금 개발 시 Prettier, ESLint 등으로 코드를 포맷팅 하여 일관된 코딩 스타일을 유지하는 것의 중요성을 느꼈습니다.

이는 입사하기 전 토이 프로젝트를 진행할 때에도 신경 쓰고 있던 부분이었는데요. 변경사항 추적과 코드 정리에 소요되는 시간을 줄여주고, 개발 자체에 집중을 돕기 때문에 회사에서 운영하는 서비스와 같이 규모가 크고 히스토리가 오래된 프로젝트 일수록 포맷팅 관리가 필수라고 느꼈습니다.

2. 코드 구조 파악

포맷팅을 진행하며 프로젝트의 전체 코드를 한번씩 접하게 되었고, 이 과정이 원티드 프로젝트 구조 파악에 도움이 되었습니다.

운영 이슈를 처리하기 위해서는 프로젝트에서 사용하는 기술과 구조를 파악하고 코딩 스타일을 준수해야 하는데요.

다른 분들이 컨플루언스에 경험을 공유해주신 내용과 함께 코드를 접하니, 따로 외우거나 숙지하지 않아도 자연스럽게 익숙해지는 부분이 많았습니다. 👍

3. 소통과 문서화의 중요성

포맷팅 업무를 통해 팀원들과 소통하며 업무를 공유하고, 작업을 문서화하는 일의 중요성도 깊이 느꼈습니다.

원티드 프론트엔드팀은 매일 아침 미팅과 주간 회의를 통해 각자의 업무와 도움이 필요한 일들을 공유하고 있어요. 👏 저도 미팅을 통해 작업에 대한 의견과 도움을 많이 받았습니다. 처음에 작업량이 많아 어떻게 목표를 설정하고 진행해야 할 지 헤맸는데, 큰 이슈 없이 포맷팅 작업이 가능했던 것은 팀과의 지속적인 소통이라고 생각합니다.

또한 작업 기준 & 진행 상황 등을 문서로 기록했기 때문에 저 자신에게도, 그리고 팀에게도 작업에 대한 이해를 좀 더 직관적으로 도울 수 있었습니다. (그리고 깔끔하게 정리된 걸 보면 기분이 좋아요 😏)

마치며

지금까지 포맷팅 과정과 느낀 점을 작성했습니다. 앞으로도 계속 진행할 예정이며, 이 작업으로 인해 원티드 프론트엔드팀의 개발이 더 편해지기를 바랍니다.

그리고 전체적으로 포맷팅을 적용 했지만, 이슈 추적 툴과 작업 자체에 대한 히스토리를 정리하고 있으므로 추후 히스토리 파악에도 잘 대응할 수 있을 거라고 생각합니다.

미팅, DM, 코멘트 등 다양한 방식으로 조언해주신 팀원 분들에게 다시 한번 감사드립니다. ❤️ 저도 좋은 개발 문화와 제품을 만들기 위해 열심히! 노력하겠습니다. 💪💪

감사합니다.

참고

--

--