ESLint+Prettier 설정 경험
약 85초
팀 프로젝트에서 코드 스타일 통일을 위해 린터를 설정한 경험
동아리 프로젝트에서 팀원 4명이 코드 스타일이 달라서 PR마다 스타일 관련 댓글이 절반이었습니다. ESLint와 Prettier를 같이 설정하기로 했는데, 처음에는 규칙 충돌로 저장할 때마다 코드가 이상하게 변하는 문제가 발생했습니다. eslint-config-prettier로 충돌하는 규칙을 꺼야 한다는 것을 이틀 만에 알아냈습니다. pre-commit 훅까지 연결하여 린트 실패 시 커밋이 되지 않도록 했으나, 팀원 한 명이 자꾸 우회 방법을 찾아서 갈등이 생겼습니다. 강제가 아니라 팀이 왜 이 도구를 쓰는지 공감해야 작동한다는 것을 배웠습니다. 현재는 린터 규칙을 선정할 때 팀원 의견을 먼저 듣는 방식으로 변경되었습니다.
이 결의 특징
4명 팀에서 PR의 절반이 스타일 관련 댓글로 채워진 구체적 문제 상황에서 시작합니다. ESLint와 Prettier의 규칙 충돌로 인한 '저장할 때마다 코드가 이상하게 변하는 문제'를 2일 만에 'eslint-config-prettier'라는 정확한 해법으로 찾아낸 과정이 있습니다. 그 이후 pre-commit 훅에서 생긴 '팀원의 우회 시도'라는 예상치 못한 갈등이 '강제가 아니라 공감이 필요하다'는 배움으로 이어집니다.
이 결이 통하는 자리
린트나 포매터라는 도구를 강제하는 것만으로는 팀의 습관이 안 바뀐다는 걸 몸으로 경험한 사람입니다. 이 사람이 챕터에 들어가면 규칙을 정할 때 '팀원 의견을 먼저 듣는 방식'으로 진행하겠다는 약속이 단순한 소통 가치관이 아니라 실제 갈등 해결 경험에서 나온 것이라는 신뢰가 생깁니다.