최근 오픈소스 생태계의 가장 깊숙한 곳, 리눅스 커널 개발 과정에서 벌어진 일련의 사태를 관찰하는 건, 마치 거대한 플랫폼의 핵심 아키텍처가 어떤 디테일한 프로세스 문제로 인해 발목 잡히는 걸 지켜보는 것과 같습니다.
리누스 토발즈 같은 최고 권위자가 특정 테스트 코드에 대해 격분했다는 뉴스는 그 자체로 큰 이슈지만, 우리가 여기서 진짜 캐치해야 할 건 그 '분노'의 내용입니다.
문제는 단순히 코드가 있다는 사실 자체가 아니었어요.
그 코드가 핵심 빌드 과정에 '필수적이지 않은 채로' 끼어들어가서 전체 빌드 시간을 늘리고, 결과적으로 개발자들이 관리하기 곤란한 '쓰레기 파일'들을 남기기 시작했다는 점이죠.
이건 마치 우리가 야심 차게 만든 제품의 핵심 기능은 완벽한데, 사소한 부가 기능 검증 과정이 너무 무거워서 배포 빌드 자체가 몇 시간씩 걸리고, 테스트 결과물로 수십 개의 불필요한 로그 파일만 남기는 상황과 정확히 일치합니다.
개발자 관점에서 보면, 이 '불필요한 테스트'는 개발 속도를 늦추는 가장 치명적인 기술 부채(Technical Debt) 그 자체입니다.
아무리 좋은 기술이라도, 그 기술을 검증하고 통합하는 과정이 너무 복잡하거나 느리면, 시장에 출시될 제품의 가치는 급격히 하락할 수밖에 없습니다.
우리가 제품을 만들 때, 가장 먼저 점검해야 할 건 '이 기능이 정말로 핵심 가치에 기여하는가?' 그리고 '이 가치를 검증하는 과정이 개발 속도를 저해하지 않는가?' 이 두 가지 질문에 대한 명확한 답이 필요합니다.
이 사례를 PC 조립이나 하드웨어 빌드 관점에서 다시 해석해 보면, 우리가 흔히 겪는 '과도한 검증 단계'의 위험성을 명확히 보여줍니다.
예를 들어, 최신 CPU나 메인보드를 조합할 때, 모든 잠재적 시나리오를 커널 레벨에서 완벽하게 테스트하려는 욕심은 이해합니다.
DRM 헤더 파일의 무결성을 검증하는 hdrtest 같은 코드가 그 예시죠.
물론 그 검증 자체는 필요합니다.
하지만 그 검증이 '선택적'이어야 합니다.
즉, 일반적인 'allmodconfig' 같은 표준 빌드 과정에 강제로 포함되어서는 안 되는 겁니다.
이게 왜 문제냐면, 개발팀 전체가 그 테스트를 통과시키기 위해 코드를 수정하고, 그 과정에서 다른 핵심 모듈들이 의도치 않게 영향을 받거나, 혹은 테스트 결과물이라는 이름으로 시스템 디렉토리가 지저분해지기 때문입니다.
결국, 이 모든 것은 'Scope Creep(범위 확장)'의 전형적인 예시입니다.
초기 목표는 '최소한의 기능으로 동작하는 제품'을 만드는 것인데, 시간이 지나면서 '이것도 넣어야 하고, 저것도 테스트해야 한다'는 요구사항이 붙으면서 제품의 본질적인 속도와 단순성이 훼손되는 거죠.
창업가 입장에서 보면, MVP(Minimum Viable Product)를 정의할 때 이 '불필요한 테스트'를 가장 먼저 잘라내는 결단력이 필요합니다.
당장 완벽한 100% 커버리지를 추구하다가, 시장에 내놓을 수 있는 최소한의 '작동하는 경험' 자체를 놓쳐버리는 리스크를 감수해서는 안 됩니다.
아무리 근본적인 기술이라도, 핵심 가치 전달을 방해하는 불필요한 프로세스나 검증 단계는 과감하게 분리하거나 제거해야 한다.