포매터

코드는 어떻게 생겨도 똑같이 돌아갑니다. 들여쓰기를 두 칸으로 하든 네 칸으로 하든, 문자열을 작은따옴표로 감싸든 큰따옴표로 감싸든 결과는 같습니다. 그래서 사람마다 손버릇이 달라지고, 한 저장소 안에 서로 다른 모양의 파일이 섞이게 됩니다.

같은 파일을 여러 명이 건드리기 시작하면 이 차이가 일거리가 됩니다. 페이지덱 초기에 태오가 남의 파일을 고치다가 자기 에디터 설정대로 전체가 다시 정렬돼 버린 적이 있습니다. 실제로 바꾼 줄은 세 줄인데 풀 리퀘스트에는 400줄이 바뀐 것으로 올라왔습니다. 풀 리퀘스트는 변경을 합쳐 달라고 올려 리뷰를 받는 요청입니다. 리뷰하던 동료는 그 400줄 중 어디가 진짜 변경인지 찾느라 시간을 썼고, 결국 모양만 바꾼 줄을 되돌린 뒤에 다시 올렸습니다.

논쟁도 붙었습니다. 코드 리뷰에서 들여쓰기 칸 수를 두고 댓글이 오가고, 한쪽이 양보하면 다음 파일에서 같은 이야기가 다시 나왔습니다. 코드 리뷰는 합치기 전에 동료가 코드를 살펴보는 절차인데, 정작 봐야 할 로직 대신 모양 이야기가 자리를 차지한 셈입니다.

포매터는 이 문제를 취향 문제에서 도구 문제로 옮깁니다. 모양의 정답을 도구가 한 벌 갖고 있고, 사람이 어떻게 쓰든 저장하는 순간 그 한 벌로 다시 씁니다. 무엇이 더 나은 모양인지는 더 논의하지 않고, 도구가 내놓는 모양을 그냥 받아들이는 것이 전제입니다.

포매터가 실제로 없애는 것은 세 가지입니다.

1. 취향 논쟁 — 들여쓰기 칸 수, 줄 길이 제한, 따옴표 종류, 쉼표를 마지막 항목 뒤에도 붙일지 같은 항목입니다. 팀이 한 번 설정을 정하고 나면 이 주제로 다시 말할 일이 없어집니다. 설정을 정하는 회의는 한 번 30분이면 끝나고, 그 뒤로 매주 리뷰에서 나가던 댓글이 사라집니다.
2. 변경 내역의 잡음 — 코드를 비교해 보여 주는 화면에 진짜 바뀐 줄만 남습니다. 앞의 400줄짜리 사례가 세 줄로 줄어듭니다. 이건 리뷰 속도만의 문제가 아니라, 나중에 어떤 줄이 언제 왜 바뀌었는지를 Git 이력에서 되짚을 때도 차이를 만듭니다. Git 은 변경 이력을 관리하는 도구입니다.
3. 새로 온 사람의 적응 시간 — 팀의 코딩 스타일을 문서로 읽고 외울 필요가 없습니다. 저장만 하면 맞는 모양이 되니, 첫 주에 스타일 지적을 받는 일 자체가 생기지 않습니다.

반대로 포매터가 해 주지 않는 것도 분명합니다. 변수 이름이 하는 일과 다른 것, 함수 하나가 400줄인 것, 같은 계산이 네 파일에 복사된 것은 모양 문제가 아니라 구조 문제라 손대지 않습니다. 포매터를 넣었다고 코드가 좋아지는 게 아니라, 좋은지 나쁜지를 볼 때 모양이 시야를 가리지 않게 되는 것입니다.

포매터 없이 같은 목적을 노리는 방법은 셋입니다. 셋 다 지금도 함께 쓰이지만, 모양을 통일하는 일 자체에서는 포매터에 밀립니다.

1. 문서로 된 코딩 규약 — 팀이 스타일 규칙을 적어 두고 각자 지키는 방식입니다. 읽는 데 30분이 걸리고 지키는 데는 매일 신경이 들어갑니다. 급하게 고칠 때 가장 먼저 무너지고, 무너진 것을 확인하려면 다시 사람 눈이 필요합니다.
2. 에디터 설정 공유 — 들여쓰기 같은 기본 항목을 저장소에 설정 파일로 두고 각자의 에디터가 읽게 합니다. 손이 거의 안 가는 방법이지만 다룰 수 있는 항목이 적습니다. 탭과 공백이 섞이는 정도는 막아 주는데, 인자가 다섯 개인 함수 호출을 한 줄로 둘지 다섯 줄로 펼칠지 같은 판단은 하지 못합니다.
3. 리뷰에서 지적 — 사람이 보고 고쳐 달라고 말하는 방식입니다. 가장 느리고 가장 감정이 상하는 경로입니다. 지적하는 쪽도 매번 같은 말을 반복하고, 받는 쪽도 사소한 것으로 붙잡힌다고 느낍니다.

실무에서는 포매터를 기본으로 깔고 여기에 두 겹을 더합니다. 저장할 때 자동으로 돌게 에디터에 걸어 두는 것이 한 겹이고, 합치기 전 검사에서 모양이 맞는지 한 번 더 확인하는 것이 다른 한 겹입니다. 뒤쪽은 지속적 통합이 맡습니다. 변경을 자주 합치면서 자동 검사를 돌리는 방식인데, 포매터를 실행하지 않은 사람의 코드가 그대로 들어오는 것을 여기서 막습니다.

"포매터 한 번 돌리고 다시 올려 주세요. 검사에서 걸려 있어요."

내용 문제가 아니라 모양이 규칙과 달라 자동 검사가 막았다는 뜻입니다.

"이 파일은 포매터 적용 전이라 변경 내역이 좀 지저분해요."

바뀐 줄이 많아 보이는 게 실제 수정이 아니라 모양 정리 때문이라는 설명입니다.

"따옴표는 그냥 포매터 기본값 쓰죠. 논쟁할 만한 주제가 아니에요."

설정을 팀 취향에 맞추느라 시간을 쓰지 말자는 제안입니다.

페이지덱은 새 저장소를 만들 때 포매터 설정 파일을 먼저 넣습니다. 태오가 첫 커밋에 설정과 검사 스크립트를 함께 올려 두면, 그 뒤로 들어오는 코드는 사람이 어떻게 쓰든 같은 모양으로 저장됩니다.

이미 돌아가는 오래된 저장소에 뒤늦게 넣을 때는 순서를 지킵니다. 포매터를 전체에 한 번 돌린 결과만 담은 커밋을 따로 만들고, 그 커밋 번호를 이력 조회에서 건너뛰도록 표시해 둡니다. 이렇게 하지 않으면 이후로 모든 줄의 마지막 수정자가 태오로 바뀌어, 누가 왜 이 줄을 썼는지 되짚는 일이 어려워집니다.

포매터가 코드 품질을 올려 준다고 여기는 경우가 많습니다. 결과물이 눈에 띄게 깔끔해지니 그렇게 느끼는 게 자연스럽습니다. 하지만 이 도구가 보는 것은 공백과 줄바꿈뿐이고, 무엇이 잘못됐는지는 판단하지 않습니다. 400줄짜리 함수는 잘 정렬된 400줄짜리 함수가 될 뿐입니다. 품질이 좋아졌다고 믿고 다른 검사를 미루면, 정작 문제를 잡아야 할 도구를 안 깐 채로 겉모양만 고른 저장소가 됩니다.

설정을 팀 취향대로 꼼꼼히 맞춰야 한다고 생각하는 것도 흔합니다. 도구니까 우리에게 맞게 조정해야 할 것 같지만, 포매터의 값어치는 설정의 정교함이 아니라 논쟁이 사라지는 데 있습니다. 항목을 하나씩 검토하기 시작하면 없애려던 취향 논쟁이 설정 파일 리뷰로 자리를 옮길 뿐입니다. 기본값을 그대로 쓰는 팀이 많은 것도 이 때문이고, 최근 도구일수록 조정 가능한 항목을 일부러 적게 둡니다.