솔직히 말해봅시다. 당신네 팀 코드가 스파게티가 되는 건 개발자 실력이 없어서가 아닙니다.
// eslint-disable 뒤에 숨을 수 있기 때문입니다.
트위치(Twitch)에서 300명의 개발자가 달라붙어 만든 100만 줄짜리 타입스크립트(TypeScript) 몬스터.
이걸 어떻게 운영했을까요?
보통은 '경찰 놀이'를 합니다. 린트(Lint) 규칙을 더 빡빡하게 조이고, PR 리뷰 때마다 잔소리를 해대죠.
하지만 트위치 코어 팀은 달랐습니다. 그들은 인간의 본성을 인정했습니다.
"개발자는 마감이 닥치면 규칙을 우회한다."
문제는 규칙을 어기는 행위 자체가 아닙니다. 그 예외들이 코드 구석구석에 숨어서 '보이지 않게(Invisible)' 쌓이는 게 문제입니다.
우리는 보통 린트 룰, 테스트 커버리지, 아키텍처 패턴 같은 걸 정해둡니다.
그런데 실제 상황은 어떻습니까?
급하게 핫픽스 배포해야 하는데 린트 에러가 납니다.
에디터가 친절하게 // eslint-disable-next-line을 넣어줍니다.
혹은 레거시 코드를 복사해서 붙여넣었더니 예전의 예외 처리 주석까지 딸려옵니다.
아무도 모르게 '표준의 이탈(Drift)'이 발생합니다.
이게 쌓이면 나중엔 뭐가 진짜 룰이고 뭐가 예외인지 코어 팀조차 모르게 됩니다.
새벽 3시에 장애가 터지고 나서야 "아, 여기 린트 꺼놨었네?" 하고 땅을 치게 되죠.
트위치는 이 문제를 해결하기 위해 '린트 스냅샷(Lint Snapshots)'이라는 독특한 시스템을 도입했습니다.
원리는 허무할 정도로 간단하지만, 효과는 강력합니다.
- 모든
disable주석을 무시하는 플래그를 켜고 ESLint를 돌립니다. (마치 룰을 완벽하게 지켜야 하는 것처럼) - 그 결과(위반 목록)를 리포지토리 루트에 파일로 저장합니다.
- 이때 줄 번호(Line number)는 제거합니다. (코드 한 줄 추가했다고 diff가 뜨면 피곤하니까요)
- 가장 중요합니다. 이 스냅샷 파일의 소유자(CODEOWNERS)를 '코어 팀'으로 지정합니다.
이게 시스템적으로 어떤 변화를 가져올까요?
개발자가 몰래 린트 룰을 끄는 주석을 추가합니다.
그러면 스냅샷 파일 내용이 바뀝니다.
스냅샷 파일은 코어 팀 소유이므로, PR을 머지하려면 자동으로 코어 팀의 리뷰가 강제됩니다.
숨어서 하던 짓(Implicit)이 공개적인 협상 테이블(Explicit)로 끌려나오는 순간입니다.
개발자는 변명해야 합니다. "이거 왜 껐어요?"라는 질문에 답해야 하니까요.
"지금 라이브 이슈라 급해서 일단 껐습니다" 혹은 "이 패턴에서는 이 룰이 안 맞습니다" 같은 대화가 오고 갑니다.
이 시스템의 미학은 '개발을 막지 않는다'는 점에 있습니다.
급하면 룰을 어겨도 됩니다. 예외를 허용합니다.
하지만 그 예외는 반드시 기록되고, 관리되고, 합의된 것이어야 합니다.
파일 구석에 처박힌 주석이 아니라, 추적 가능한 아티팩트(Artifact)로 관리되는 겁니다.
코어 팀 입장에선 코드 전체를 뒤질 필요가 없습니다. 스냅샷 파일의 diff만 보면 아키텍처의 어느 부분이 썩어가고 있는지 한눈에 보입니다.
저는 네이버와 넷플릭스를 거치며 수많은 장애를 겪었습니다.
대부분의 대형 사고는 '우리가 모르는 예외'에서 시작됩니다.
"설마 여기엔 예외 처리가 없겠어?"라고 믿었던 곳에서 배신을 당하죠.
시스템의 가용성(Availability)을 지키는 건 화려한 신기술이 아닙니다.
우리가 통제 못 하는 '어둠의 영역'을 없애는 것입니다.
완벽한 코드는 없습니다. 하지만 관리 가능한 쓰레기는 만들 수 있습니다.
당장 내일 출근해서 팀원들 몰래 grep 한번 돌려보세요.
여러분의 코드베이스에 얼마나 많은 disable이 숨 쉬고 있는지.
그걸 끄집어내서 테이블 위에 올리는 것. 그게 엔지니어링의 시작입니다.
