pile·
기타·마켓컬리마켓컬리 Hello World·

새로 입사한 개발자가 프로젝트에 기여하는 방법 한 가지

신규 입사자가 코딩 스타일 가이드의 작은 위반을 검색해 첫 Pull Request를 만든 뒤, 1,823개 CheckStyle 경고를 팀 학습과 점진적 개선의 재료로 바꾼 경험이다. 포매터로 한 번에 덮지 않고 find, ag, sed, gsed와 정규표현식으로 안전한 유형부터 작은 커밋과 PR로 처리했다. 결과적으로 500개 이상 경고를 줄이고 코드 리뷰·커밋·컨벤션 문화가 자리 잡는 데 기여했다.

핵심 포인트
  • 중괄호 생략 규칙 위반을 find와 egrep로 찾아 5건을 고친 작업이 신규 입사자의 첫 기여가 됐다.
  • CheckStyle을 전체 실행하자 1,823개 경고가 나왔지만 전체 포매팅 대신 작은 규칙별 PR로 나눴다.
  • 기계적 정리를 Git, 브랜치, 커밋 단위, 코드 리뷰를 연습하는 팀 학습 자료로 활용했다.
  • ag로 대상 파일을 찾고 sed·gsed로 공백, 변수명, 화살표, 탭, 중괄호 형식을 반복 가능하게 수정했다.
  • 500개 이상 경고를 제거했고 새 프로젝트는 대체로 경고 1개 이하를 유지하는 수준으로 컨벤션 습관이 강화됐다.
상세 정리
  • 첫 단서: 팀 코딩 가이드에서 예외 종결 외에는 if 중괄호를 생략하지 않는 규칙을 읽고 실제 코드 준수 여부를 확인했다.
  • 검색 명령: Java 파일을 find로 찾고 xargs egrep에 연결해 여는 중괄호 없는 if 후보를 추출했다. 결과 5건 모두 규칙 위반이었다.
  • 첫 PR: 변경 범위가 작고 명확해 신규 입사자가 프로젝트에 기여하면서 코드 흐름과 리뷰 절차를 익히기 좋은 작업이었다.
  • 전체 진단: IntelliJ CheckStyle 플러그인과 팀의 kurly_checks.xml을 적용하자 프로젝트 전체에서 1,823개 경고가 발견됐다.
  • 일괄 처리 보류: 포매터를 전체에 실행하면 빠르지만 diff가 커지고 팀이 GitHub PR과 리뷰를 익힐 기회를 잃는다고 판단했다.
  • 학습 목표: 각 작업을 브랜치·커밋·PR로 나눠 터미널에 익숙하지 않은 동료가 Git 명령과 적절한 커밋 크기를 배울 수 있게 했다.
  • 보이스카우트 규칙: 한 번에 완벽히 없애기보다 발견한 코드를 조금 더 깨끗하게 남기는 점진적 접근을 택했다.
  • 괄호 공백: if, for, while, try 뒤 여는 괄호의 공백 누락 49건을 ag로 찾아 sed로 고쳤고, 10개 파일의 diff를 검토한 뒤 PR을 올렸다.
  • 람다 변수명: 대문자로 시작하는 람다 매개변수를 찾고 gsed로 소문자화했다. -i.orig로 백업 파일을 만든 뒤 테스트와 diff를 확인했다.
  • 화살표 공백: 정규표현식의 전후방 탐색으로 Java 람다 화살표 좌우에 공백이 없는 위치를 찾아 수정했다.
  • 탭 변환: 모든 Java 파일에서 탭 문자가 있는 파일만 골라 두 칸 공백으로 바꿨다.
  • 중괄호 공백: 닫는 괄호와 여는 중괄호가 붙은 패턴을 찾아 사이에 공백을 추가했다.
  • 안전 절차: 자동 치환 뒤에는 git diff로 범위를 확인하고 테스트를 실행했다. 생성된 백업 파일은 커밋에서 제외했다.
  • 성과: 소개한 작업 외에도 같은 방식의 정리를 이어 500개 넘는 경고를 제거했다.
  • 팀 변화: 컨벤션을 구현과 별개의 잡무가 아니라 품질 약속으로 다루고, 신중한 커밋 메시지와 PR·리뷰·머지 흐름을 반복하는 문화가 정착했다.
왜 읽나대규모 코드 스타일 부채를 거대한 포매팅 커밋 없이 줄이면서 신규 구성원의 온보딩과 리뷰 문화까지 강화하고 싶은 팀에 적합하다.
마켓컬리
마켓컬리 Hello World 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. 기타·stackoverflow-blogStack Overflow Blog·

    Selenium vs Cypress vs Playwright — 테스트 자동화 프레임워크 선택 가이드 2026

    2026년 기준 Selenium, Cypress, Playwright 세 가지 테스트 자동화 프레임워크를 아키텍처, 안정성, 비용, 브라우저 지원, 언어 지원 측면에서 비교한다. 세 프레임워크는 브라우저 제어 방식에서 근본적으로 다르며, 각각의 강점이 다른 사용 시나리오에 최적화되어 있다.

    #e2e-testing#test-automation#selenium+2