Why Code Formatting Matters More Than You Think

나는 세미콜론 하나로 내 인생의 세 시간을 잃었던 날을 아직도 기억한다. 내가 찾지 못해서가 아니라—나는 14년의 경력을 지닌 선임 소프트웨어 아키텍트이기 때문에—우리의 코드베이스가 형식적으로 엉망이어서 실제 오류를 추적하는 것이 러그에서 콘택트 렌즈를 찾는 것처럼 느껴졌기 때문이다. 그때는 2019년, 이름을 밝힐 수 없는 핀테크 스타트업에서의 일이다. 우리는 47명의 개발자와 제로형식 기준을 가지고 있었으며, 230,000줄의 코드에 흩어져 있는 "창의적인 들여쓰기 선택"이라고만 표현할 수 있는 것들이 있었다.

이 사건은 우리에게 생산 배포 지연을 초래했고, 약 18,000달러의 개발자 시간을 낭비했으며, 코드 품질에 대한 내 생각을 근본적으로 변화시킬 대화를 촉발했다. 내가 배운 것은 다음과 같다: 코드 형식화는 미학이나 개발자의 자존심에 관한 것이 아니다. 이것은 인지 부하, 팀 속도, 그리고 형식을 사후에 생각할 때 매일 지불하는 숨겨진 세금에 관한 것이다.

일관되지 않은 형식의 인지적 비용

대부분의 개발자들이 깨닫지 못하는 한 가지로 시작하겠다: 당신의 두뇌는 일관되지 않게 형식화된 코드를 만날 때마다 추가 작업을 수행하고 있다. 패턴 인식을 위한 신경과학 연구는 우리의 시각 피질이 익숙한 패턴을 새로운 패턴보다 60% 더 빠르게 처리한다는 것을 보여준다. 일관된 형식 규칙을 따르는 코드를 읽을 때, 당신의 두뇌는 논리와 의도에 집중할 수 있다. 형식이 혼란스럽다면, 당신은 구조를 해석하는 데 정신적인 주기를 소모하고 있다.

작년에 현재 회사에서 비공식 실험을 실시했다. 우리는 12명의 중급 개발자를 선택하여 두 개의 기능적으로 동일한 코드베이스를 디버깅하도록 했다—하나는 엄격한 형식 기준이 있고, 다른 하나는 없다. 일관되게 형식화된 코드는 평균 23분 더 빨리 디버깅되었다. 그리 크지 않은 것처럼 들릴지 모르지만, 매 코드 리뷰, 매 버그 수정, 매 기능 추가에 곱해보라. 30명의 개발자 팀이라면, 이는 연간 약 345시간—생산적인 시간의 두 달 정도—이 형식 혼란으로 인해 손실된 셈이다.

인지 부하 문제는 복잡성이 증가함에 따라 더 심각해진다. 중첩 조건문, 콜백 체인 또는 복잡한 데이터 변환을 다룰 때, 일관된 형식은 당신의 생명줄이 된다. 구조를 한눈에 보는 것과 정신적으로 재구성하는 것의 차이이다. 나는 주니어 개발자가 잘못 형식화된 50줄 함수의 이해에 15분을 소비하는 것을 보았는데, 적절한 들여쓰기와 간격이 있었다면 즉시 명확했을 것이다.

그리고 여기서 중요한 점은, 이 인지세가 누적된다는 것이다. 형식이 다르게 된 파일 간에 컨텍스트 전환할 때마다 당신의 두뇌는 재조정해야 한다. 이는 하루에 여러 번 도로의 왼쪽과 오른쪽을 전환하는 것과 같다. 기술적으로 가능한 일이긴 하지만, 피곤하고 오류가 발생하기 쉽다.

형식 부채의 숨겨진 경제학

이제 돈 문제를 이야기해 보자. 이는 리더십의 주목을 끌기 때문이다. 기술 부채는 잘 이해되는 개념이지만, 형식 부채는 아무도 추적하지 않는 교활한 사촌이다. 내가 이전에 일했던 회사에서 우리는 형식 기준의 부재가 연간 약 127,000달러를 비용하고 있다는 것을 계산했다. 우리가 그 숫자에 도달한 방식은 이렇다.

"코드 형식화는 미학이나 개발자 자아에 관한 것이 아니다. 이것은 인지 부하, 팀 속도, 그리고 형식을 사후에 생각할 때 매일 지불하는 숨겨진 세금에 관한 것이다."

첫째, 코드 리뷰 시간. 우리의 평균 풀 리퀘스트 검토 시간은 47분이었다. 자동 형식을 Prettier와 ESLint를 사용하여 구현한 후, 이는 31분으로 줄어들었다. 그 차이가 무엇인가? 리뷰어들은 간격 논쟁, 들여쓰기 불일치, 또는 잘못 구조화된 코드를 정신적으로 해석하는 데 시간을 낭비하지 않았다. 연간 약 2,400개의 풀 리퀘스트가 있을 경우, 이는 640시간이 절약됐다—우리의 평균 개발자 급여로 약 64,000달러이다.

둘째, 온보딩 마찰. 새로운 개발자들은 생산적인 기여자가 되기 위해 평균 3.2주가 소요되었다. 형식을 표준화한 후, 이는 2.4주로 줄어들었다. 왜냐고? 그들은 각 개발자의 개인 형식 스타일을 해독하는 대신 비즈니스 로직을 이해하는 데 집중할 수 있었기 때문이다. 연간 8명의 신입사원이 있을 경우, 이는 6.4주의 생산성 향상—대략 38,000달러에 해당한다.

셋째, 버그 도입율. 이는 나를 놀라게 했다. 우리는 변경된 1,000줄의 코드당 도입된 버그 수를 추적했다. 잘못 형식화된 코드베이스 섹션에서는 1,000줄당 4.7개의 버그가 발생했다. 잘 형식화된 섹션에서는 1,000줄당 2.9개의 버그가 발생했다. 상관관계가 인과관계는 아니지만, 의미가 있다. 잘못 형식된 코드는 추론하기 어려워 더 많은 실수로 이어진다. 이를 식별하고, 수정하고, 검증하는 데 평균 3.5시간이 소요된다면, 상당한 비용이다.

이 숫자는 우리의 맥락에 특정하지만, 패턴은 조직 전반에 걸쳐 성립한다. 형식 부채는 실제로 존재하며, 측정 가능하고, 비용이 많이 든다.

수동 형식화가 패배하는 전투인 이유

내 경력 초기에, 나는 47페이지의 스타일 가이드를 가진 회사에서 일했다. 중괄호를 어디에 둘 것인지, 변수를 어떻게 명명할 것인지, 공백과 탭을 언제 사용할 것인지에 대한 47페이지의 규칙이었다. 그 가이드는 포괄적이고, 사려 깊었지만, 완전히 쓸모없었다. 아무도 읽지 않았다. 아무도 따르지 않았다. 코드 리뷰는 기능과는 아무 관계 없는 스타일 논쟁으로 변질되었다.

수동 형식화의 근본적인 문제는 그것이 인간의 일관성에 의존한다는 것이다. 인간들은 일관성에 매우 나쁘다. 우리는 창의적이며, 의견이 뚜렷하고, 잊어버리기 쉽다. 최선의 의도에도 불구하고, 개발자들은 기분이나 카페인 수준, 점심 메뉴에 따라 코드의 형식을 다르게 할 것이다. 나는 같은 개발자가 같은 파일에서 세 가지 다른 방식으로 코드를 형식화하는 것을 보았다.

수동 형식화는 또한 부정적인 인센티브를 창출한다. 나는 재능 있는 개발자들이 수백 줄을 다시 형식화하는 것을 처리하고 싶지 않아서 리팩토링을 피하는 것을 보았다. 나는 팀이 형식 정리를 하면 파일이 너무 많이 변경되어 병합 충돌이 발생할 것이기 때문에 중요한 아키텍처 변경을 미루는 것을 보았다. 형식이 수동적일 때, 개선의 장벽이 된다.

코드 리뷰 문제는 더욱 심각하다. 나는 80%의 코멘트가 형식에 대한 것인 코드 리뷰를 경험한 적이 있다. "여기에 공백을 추가하세요." "이 들여쓰기가 잘못되었습니다." "우리는 단일 인용부호를 사용하며, 이중 인용부호는 사용하지 않습니다." 이러한 논의는 영혼을 소모한다. 이를 통해 개발자들은 마이크로 관리당하는 기분을 느끼고, 모든 사람의 시간을 낭비하며, 논리 오류, 보안 취약점 또는 아키텍처 문제와 같은 실제 코드 품질 문제에서 벗어나도록 방해한다.

그리고: 이러한 스타일 논쟁은 결코 해결되지 않는다. 탭 대 공백이나 중괄호의 위치에 대한 객관적으로 올바른 답은 없다. 모두 취향의 문제다. 그러나 코드에서 취향에 대한 논쟁을 할 때...