소프트웨어 품질을 이야기할 때 우리는 흔히 버그 개수나 QA 통과율 같은 눈에 보이는 지표로 환원하려 한다. 그러나 evalapply.org에 실린 한 에세이(2023)는 품질을 훨씬 더 근본적인 관점, 즉 '만들고 바꾸고 유지하는 과정 그 자체의 경험'으로 정의한다. 글쓴이는 좋은 품질이란 결국 그 과정을 우아하게 수행하고, 손댄 자리를 이전보다 나은 상태로 남기는 것이라고 말한다. 새로운 주장은 아니지만, 소프트웨어가 늘 우리를 실망시키고 때로는 심각한 결과를 초래한다는 점에서 되새길 가치가 있다는 것이 그의 출발점이다.
논의의 핵심에는 '천 번의 상처로 인한 죽음(death by a thousand cuts)'이라는 은유가 있다. 어느 순간에는 거의 보이지 않는 작은 편법과 코너 커팅이 시간이 지나며 단순히 누적되는 것이 아니라 복리로 불어난다는 것이다. 처음에는 반창고, 그다음에는 봉합과 깁스, 그리고 어느 순간 괴저처럼 번진다. 매번의 핫픽스가 하나의 상처이고, 모든 불만·앱 크래시·서비스 장애가 상처다. 각각의 상처는 더디게 아물면서 제품의 품질과 가치를 갉아먹는다. 이 관점의 요점은 대형 사고가 아니라 사소함의 축적이 제품을 서서히 죽인다는 데 있다.
소프트웨어는 왜 끊임없이 변하는가
글쓴이는 소프트웨어를 다른 기계와 구분한다. 여느 기계처럼 수많은 사람의 노동으로 만들어지고 유지보수가 필요하지만, 소프트웨어만은 순수한 개념이기에 무한히 유연하고 가변적이다. 그래서 실제로 끊임없이 변형된다. 물론 유닉스 도구들이나 ZeroMQ처럼 '완성된' 상태를 명시적 목표로 삼는 사례, Clojure 커뮤니티가 중시하는 '완결성' 같은 예외도 있다. 그러나 대부분의 소프트웨어는 그것이 봉사해야 할 세상이 끝없이 변하기 때문에 무한히 변할 수밖에 없다. 1976년 등장해 반세기 가까이 진화를 멈추지 않은 Emacs가 대표적인 예로 제시된다(이 글 역시 Emacs로 작성되었다고 한다).
더 무서운 것은 강한 강화 피드백 루프다. 소프트웨어가 세상을 빠르게 바꾸고, 그렇게 바뀐 세상이 소프트웨어에 더 빠른 변화를 강요한다. 글쓴이는 현재의 머신러닝·AI 붐도 이 가속의 산물로 해석한다. 변화 속도가 인간이 코드를 쓰고 고치는 속도를 넘어서면서, 세상을 감지해 다른 알고리즘을 동적으로 생성·수정하는 알고리즘에 의존하게 되었다는 것이다.
품질은 누구의 책임인가
그렇다면 이 끊임없는 변화의 압력 속에서 제품이 계속 번창하도록 만드는 책임은 누구의 몫인가. 프로덕트 매니저, 분석가, 고객 성공, 영업, 마케팅 중 누구인가. 글쓴이의 대답은 특정 직능이 아니라 '제품의 생애에 관여하는 모든 기능'이다. 흔한 선형 워크플로(분석 → 요구사항 → UX/디자인 → 개발 → QA → 프로덕션)를 놓고 보면, 위험의 뿌리는 피드백 지연에 있다. 납기 압력이 높을 때 약한 신호(weak signal)는 죽어버린다.
특히 주목할 만한 지적은 배치를 잘게 쪼갠다고 위험이 사라지지 않는다는 점이다. 흐름이 엄격히 선형이라면 큰 배치를 몇 달에 걸쳐 처리하든, 작은 배치를 며칠 단위로 처리하든 위험 프로파일은 같다. 오히려 작은 선형 배치는 여러 배치 전의 피드백이 지금에서야 도착하기 쉬워, 시장 피드백이 지연·불연속일 때 총위험을 더 키울 수 있다. 애자일을 '작게 쪼개기'로만 이해한 조직이 흔히 놓치는 함정이다.
시스템과 문화를 고치지 않으면 소용없다
품질을 만드는 방법을 찾기 위해 글쓴이는 역설적으로 '품질을 파괴하는 방법'을 열거해 보라고 권한다. 영감이 필요하면 CIA가 기밀 해제한 '간단한 사보타주 야전교범(Simple Sabotage Field Manual)', 특히 조직과 생산에 대한 일반적 방해를 다룬 11부를 읽어 보라는 다소 냉소적인 조언까지 곁들인다. 품질 파괴 행위를 하지 않기, 그 반대를 하기(예: 노하우를 쌓아 두지 말고 공유하기), 고품질 조직의 공통 특성을 관찰하기가 실마리다. 다만 그 특성을 획득하는 공식은 없다는 점을 강조한다.
결론적으로 고품질 소프트웨어를 만들려면 조직 전반의 고품질 시스템과 문화를 함께 설계해야 하며, 어떤 '베스트 프랙티스'나 방법론, '이 한 가지 트릭' 식 개입도 망가진 시스템과 사람을 고칠 수 없다. 이 과정은 1년간 게을렀던 몸의 체력을 되찾는 일과 비슷해서, 쉬워지기 전에 먼저 더 힘들어진다. 여기서 실무자가 새겨야 할 것은 이 글이 처방전이 아니라 한 프로그래머의 20여 년 경험에서 나온 현재의 직관이라는 점이다. 도구와 프레임워크는 많지만 마인드셋과 리더십, 그리고 스스로를 불편하게 만드는 새로운 관점의 추구가 없다면 품질은 결국 천 번의 상처 아래 무너진다는 경고로 읽는 편이 실용적이다.