5강. Formatter: 코드 스타일을 자동으로 맞추는 이유

?1. 이번 강의에서 해결할 문제

들여쓰기와 따옴표를 리뷰마다 손으로 고치거나 서로 다른 Formatter 버전이 파일 전체를 번갈아 바꿉니다. 프로젝트가 선택한 하나의 명령을 기준으로 삼습니다.

✓2. 학습 목표

✓이 강의를 마치면

• Formatter와 Linter의 책임을 구분합니다.
• 언어별 프로젝트 설정 존재 여부를 먼저 확인합니다.
• check와 write를 구분하고 자동 수정 뒤 diff를 검토합니다.

◇3. 핵심 개념

Formatter는 공백, 줄바꿈, 들여쓰기처럼 동작을 바꾸지 않아야 하는 표현을 일관되게 만듭니다. 로직 버그를 보장하지 않습니다. 웹의 Prettier, Python의 Black, Java의 Spotless·google-java-format 등 선택지는 다르며 프로젝트에 이미 선언된 도구를 우선합니다.

가장 작은 사례는 const score={value:10}을 const score = {value: 10};처럼 같은 스타일로 바꾸는 것입니다. 두 코드는 같은 값을 만들지만 팀원이 손으로 공백을 고치지 않아도 됩니다. 반대로 value: 10을 value: 100으로 바꾸는 일은 로직 변경이므로 Formatter 책임이 아닙니다.

단계	파일 변경	확인 목적
설정·버전 탐색	없음	프로젝트가 선택한 도구 확인
check 실행	없음	스타일 불일치 존재 여부 확인
write 실행	있음	합의된 스타일 적용
diff·테스트	없음 또는 테스트 산출물	범위와 동작 유지 검증

Prettier 공식 문서도 전역 도구보다 프로젝트 로컬의 고정 버전과 --check를 권장합니다. 설치·옵션은 현재 공식 설치 문서를 확인하세요.

✎4. 단계별 실습

실행 전 상태: 프로젝트 루트에서 git status --short를 기록하고 package·가상환경·Gradle Wrapper 중 실제 존재하는 것만 확인합니다. 새 Formatter 설치나 전역 버전 실행은 하지 않습니다.

PowerShell · 실행 위치: 프로젝트 루트

# Web: package.json에 format script가 있을 때만 실행
if (Test-Path .\package.json) {
    $package = Get-Content .\package.json -Raw | ConvertFrom-Json
    $package.scripts | Format-List
    if ($package.scripts.'format:check') { npm.cmd run format:check }
}

# Python: 프로젝트 환경에 Black이 이미 있을 때만 확인
if (Test-Path .\.venv\Scripts\python.exe) {
    & .\.venv\Scripts\python.exe -m pip show black
}

# Java: Wrapper의 사용 가능한 task에서 format 관련 이름 확인
if (Test-Path .\gradlew.bat) {
    .\gradlew.bat tasks --all | Select-String -Pattern 'format|spotless'
}

예상 결과: 선언된 script나 Task만 표시되고 check가 있다면 성공 또는 대상 파일 목록과 비정상 종료 코드를 돌려줍니다. 도구가 없으면 설치하지 않고 미선택으로 기록합니다.

자동 수정 전후:

git status --short
# 프로젝트 README에 적힌 format 명령을 실행
git diff --check
git diff

Git 상세 사용법은 Git · GitHub 기초집을 참고합니다.

→5. 도구와 설정이 동작하는 이유

check 모드는 파일을 바꾸지 않고 스타일 불일치를 종료 코드로 알려 자동 점검에 적합합니다. write 모드는 실제 파일을 변경하므로 작업 범위와 diff를 확인해야 의도하지 않은 대량 변경을 막을 수 있습니다.

변경 전후에는 git diff --stat로 범위, git diff --check로 공백 오류, git diff로 실제 내용을 봅니다. Formatter가 수백 파일을 바꿨다면 바로 커밋하지 말고 실행 위치·대상 패턴·설정 파일을 다시 확인합니다.

!6. 자주 하는 실수와 해결법

!자주 하는 실수

• Formatter가 없으면 즉시 새 도구 설치: 언어·팀·기존 설정을 먼저 확인합니다.
• 전역 최신 버전 사용: 프로젝트 로컬 고정 버전과 실행 script를 우선합니다.
• 자동 수정 뒤 검토 생략: 변경 파일과 diff, 테스트를 확인합니다.
• Formatter에 로직 오류 검출 기대: 정적 분석과 테스트를 별도로 실행합니다.

✎7. 직접 실습

✎직접 실습

실습 목표

기존 Formatter를 찾아 파일 하나에 check와 write를 순서대로 적용하고 변경 범위와 동작 유지를 검증합니다.

시작 전 상태

깨끗하거나 설명 가능한 Git 상태와 실제 프로젝트 실행·테스트 명령을 기록합니다. 도구가 없다면 임의 설치 대신 미선택 감사 결과까지만 작성합니다.

1단계: 따라 하기

package script, Python 환경, Gradle Task에서 Formatter와 고정 버전을 찾습니다. check 명령을 먼저 실행해 파일이 바뀌지 않는지 status로 확인합니다.

2단계: 코드 모양 바꿔 보기

실습 파일 한 개의 공백이나 줄바꿈만 일부러 어긋나게 하고 check 결과를 비교합니다. 프로젝트가 선언한 write 명령으로 그 파일을 복구합니다.

3단계: 직접 적용

대상 파일 하나에 적용 전후 diff와 테스트 결과를 남깁니다. 스타일 이외의 값·조건 변화가 있으면 Formatter 결과로 받아들이지 말고 원인을 조사합니다.

4단계: 스스로 확인

• 로컬 고정 버전을 사용했나요?
• check 전에 파일이 바뀌지 않았나요?
• write 뒤 수정 파일 수와 동작 테스트를 확인했나요?

막혔을 때

증상	확인·해결
명령이 없음	README·설정·package script를 확인하고 미선택으로 기록합니다.
예상보다 많은 파일 변경	실행 위치와 대상 패턴을 확인하고 커밋하지 않습니다.
팀원과 결과가 다름	로컬 도구 버전과 설정 파일 선택을 비교합니다.

?8. 이해 점검 질문 3개

?이해 점검

1. Formatter 실행 뒤 숫자 값까지 바뀌었습니다. 이를 정상 스타일 변경으로 볼 수 없는 이유와 확인 순서는 무엇인가요?
2. CI에서 파일을 몰래 고치지 않고 스타일 위반만 알려야 할 때 check와 write 중 무엇을 선택하나요?
3. 내 컴퓨터에서만 파일 전체가 다시 정렬될 때 전역 도구 대신 무엇을 비교해야 하나요?

■9. 핵심 요약

■핵심 요약

Formatter는 스타일 논쟁과 수동 수정을 줄입니다. 프로젝트가 선택한 고정 버전과 check 명령을 우선하고 write 뒤에는 반드시 diff와 실행 결과를 검토합니다.

§10. 다음 강의 연결

표현 스타일을 자동화했습니다. 다음 강의에서는 Formatter가 찾지 않는 오류 가능성과 규칙 위반을 정적 분석으로 확인합니다.