코드는 한 방에 죽지 않아요 — '천 번의 작은 타협'에서 살아남는 소프트웨어 품질 이야기

소프트웨어는 어떻게 죽어갈까요

혹시 이런 경험 있으세요? 분명 처음엔 깔끔했던 코드베이스인데, 어느 날 정신 차려 보니 아무도 건드리기 싫어하는 늪이 되어 있는 거요. 신기한 건, 돌아봐도 '그때 그 결정이 문제였다' 싶은 큰 사고가 없다는 거예요. evalapply.org에 올라온 에세이 'How to Not Die by a Thousand Cuts'는 바로 이 현상을 다루는데요, 소프트웨어는 큰 칼 한 방에 죽는 게 아니라 천 번의 작은 베임으로 죽는다는 게 핵심 주장이에요. Clojure 커뮤니티 쪽에서 나온 글인데, 함수형 프로그래밍을 안 하셔도 충분히 와닿는 이야기라 정리해 봤어요.

품질은 '추가하는 것'이 아니라는 관점

글쓴이의 첫 번째 주장은 이거예요. 품질은 소프트웨어에 나중에 발라 넣는 속성이 아니라, 그걸 만들어내는 과정과 판단의 속성이라는 거죠. 테스트 커버리지 90%, 린트 통과 같은 숫자가 품질이 아니라, '소프트웨어가 하는 일'과 '소프트웨어가 해야 하는 일'이 얼마나 맞아떨어지는지가 품질이라는 건데요. 여기서 무서운 포인트가 하나 나와요. '해야 하는 일'은 계속 변하기 때문에, 코드 한 줄 안 바꿔도 시스템은 썩을 수 있다는 거예요. 세상이 움직였는데 코드가 제자리면 그게 곧 부패라는 거죠.

천 번의 베임은 하나하나가 다 합리적이에요

이 글에서 제일 뼈아픈 통찰이 이 부분인데요. 임시 해킹, '일단 이렇게 가고 나중에 고치자', 테스트 하나 건너뛰기 — 이런 결정들은 마감 압박 속에서 보면 하나하나가 다 합리적이에요. 어떤 것도 단독으로는 시스템을 죽이지 않아요. 죽이는 건 복리로 쌓이는 누적이죠. 그래서 글쓴이는 '가역성 예산(reversibility budget)'이라는 사고 틀을 제안해요. 이게 뭐냐면, 결정을 내릴 때 '이거 나중에 되돌리려면 얼마나 비쌀까?'를 먼저 묻는 거예요. 되돌리기 싼 결정(함수 이름, 내부 구현 같은 것)은 빠르고 대충 해도 되지만, 되돌리기 비싼 결정(데이터 모델, 공개 API, 아키텍처 경계)에는 불균형하다 싶을 만큼 많은 신경을 쓰라는 거죠. 모든 결정에 똑같은 정성을 쏟는 게 아니라, 정성을 쏟을 곳을 고르는 게 기술이라는 거예요.

보이지 않는 걸 보이게 만들기

실천법도 구체적이에요. 팀이 '타협 장부'를 가볍게 유지하라는 건데요. 아무도 안 읽는 죄책감용 기술부채 백로그 말고, 계획 세울 때 실제로 들춰보는 살아있는 문서요. 방법은 간단해요. 머지할 때마다 '이번에 뭘 타협했고 왜 그랬는지'를 딱 한 문장 적는 거예요. 한 문장이라 부담이 없고, 쌓이면 팀이 어디서 피 흘리고 있는지 보여주는 지도가 되거든요.

또 하나 흥미로운 건 '게이트보다 피드백 루프'라는 주장이에요. 필수 리뷰, 커버리지 강제치 같은 품질 게이트는 연극이 되기 쉽대요. 반면 몇 분 안에 배포하고 관측할 수 있는 팀, 사용자와 직접 대화할 수 있는 팀은 자연스럽게 품질이 올라간다는 거죠. 글쓴이가 REPL 주도 개발을 품질 실천법이라고 부르는 이유도 같은 맥락인데요. '궁금하다'에서 '확인했다'까지의 거리가 5초면 우리는 확인하고, 전체 리빌드에 재배포가 필요하면 그냥 추측하고 넘어가거든요. 확인 비용이 곧 코드에 들이는 정성의 경제학을 결정한다는 거예요.

당장 써먹을 수 있는 조언들

글 말미의 실용 조언들도 하나같이 곱씹을 만해요. 주석 처리해서 남겨두지 말고 지우세요, 어차피 git에 있으니까요. 하중을 받는 핵심 부분에는 지루하고 검증된 기술을 쓰세요. 결정은 후회할 때가 아니라 내릴 때 기록하세요. '나중에 고치자'도 '지금 하자'와 똑같은 무게의 결정으로 취급해서 똑같은 검증을 거치세요. 그리고 가끔 '오늘 처음부터 만든다면 이렇게 만들까?'를 물어보세요. 다시 만들자는 게 아니라, 우리가 얼마나 표류했는지 알기 위해서요.

마무리하며

한 줄 정리: 소프트웨어 품질은 큰 결단이 아니라, 작은 타협을 보이게 만들고 확인 비용을 낮추는 습관에서 나와요. 여러분 팀은 어떤가요? '나중에 고치자'고 했던 것들, 기록으로 남아 있나요? 아니면 다들 머릿속에만 있다가 담당자 퇴사와 함께 사라지고 있나요?