회의실 풍경 하나를 떠올려보자.
화면에는 테스트 결과 리포트가 열려 있다. 빨간 막대, 숫자들, 알 수 없는 경로명. 개발자는 자신 있게 설명한다. "커버리지 78% 달성했고요, 실패 케이스 3건은 엣지 케이스라 무시 가능합니다." 기획자는 고개를 끄덕인다. 이해했기 때문이 아니다. 더 물어볼 언어가 없기 때문이다.
이 장면은 어느 한 팀의 이야기가 아니다. 소프트웨어를 만드는 거의 모든 조직에서, 매 스프린트마다 반복되는 풍경이다.
품질은 누구의 것인가 Who owns quality?
소프트웨어 품질은 '모두의 책임'이라고들 한다. 기획자가 요구사항을 잘 써야 하고, 개발자가 꼼꼼하게 구현해야 하고, QA가 철저하게 검증해야 한다. 말은 맞다. 그런데 실제 현장에서 품질을 '확인'하는 도구들을 보면 이야기가 달라진다.
테스트 커버리지 리포트는 소스 파일 경로로 말한다. 버그 트래커는 컴포넌트 이름과 스택 트레이스로 가득하다. CI/CD 파이프라인은 빌드 번호와 커밋 해시로 성공과 실패를 가른다. 이 언어들을 자유롭게 읽을 수 있는 사람은 개발자뿐이다.
기획자가 "회원가입 화면의 이메일 중복 검사가 제대로 테스트됐나요?"라고 물으면, 돌아오는 대답은 대개 이렇다. "UserController 쪽 커버리지 확인해보면 될 것 같은데, 잠깐만요…" 그 '잠깐'이 5분이 되고, 10분이 되고, 결국 "다음에 확인해드릴게요"로 끝난다.
품질은 모두의 책임이지만, 품질을 읽는 언어는 개발자만 안다. 이것이 첫 번째 균열이다.
숫자가 많다고 안심이 되는가 Does coverage mean confidence?
커버리지 78%. 이 숫자는 무엇을 말하는가.
전체 코드의 78%가 테스트를 통과했다는 뜻이다. 그렇다면 나머지 22%는? "엣지 케이스라 괜찮습니다"라는 말을 믿어야 할까. 기획자 입장에서는 확인할 방법이 없다. 개발자의 판단을 신뢰하는 수밖에.
더 근본적인 문제가 있다. 커버리지는 코드를 기준으로 측정된다. 그런데 기획자가 중요하게 생각하는 단위는 코드가 아니다. '회원가입', '주문 취소', '비밀번호 변경' — 이런 화면과 기능이 제대로 동작하는지가 궁금한 것이다.
코드 기준 78%가 기능 기준으로는 60%일 수도 있고, 90%일 수도 있다. 아무도 모른다. 측정하는 단위가 애초에 다르기 때문이다.
이것이 두 번째 균열이다. 기술 기준의 품질 지표와 비즈니스 기준의 품질 관심사가 서로 다른 언어로 존재한다.
산출물은 왜 항상 마지막에 만들어지는가 Why does documentation always come last?
많은 프로젝트에서 테스트 산출물은 프로젝트가 끝나갈 때쯤 만들어진다. 감리가 다가오거나 납품 기한이 코앞에 왔을 때, 누군가 엑셀을 열고 테스트 케이스를 '기록'하기 시작한다. 이미 테스트가 끝난 것들을 소급해서 문서화하는 작업이다.
이게 잘못이라는 걸 모두 안다. 그런데 왜 반복되는가.
테스트 활동과 산출물 작성이 처음부터 연결되어 있지 않기 때문이다. 테스트는 코드 위에서 실행되고, 산출물은 문서 위에서 만들어진다. 두 세계는 처음부터 분리되어 있다. 그러니 연결하려면 누군가 손으로 이어붙여야 하고, 그 작업은 당연히 마지막으로 밀린다.
이것이 세 번째 균열이다. 실행과 기록이 분리된 구조.
균열의 공통 뿌리 One root beneath three cracks
세 가지 균열을 다시 보자.
이 세 문제는 사실 하나의 뿌리에서 나온다. 소프트웨어 품질 관리의 기준 단위가 '코드'이기 때문이다.
코드를 기준으로 삼으면, 코드를 모르는 사람은 영원히 밖에 서 있게 된다. 코드 경로로 커버리지를 재면, 화면 단위로 생각하는 사람과 대화가 안 된다. 코드 변경으로 테스트를 관리하면, 기획 변경과 테스트 변경을 연결할 방법이 없다.
다른 기준 단위가 필요하다. 개발자도 이해하고, 기획자도 이해하고, PM도 고개를 끄덕일 수 있는 단위.
제조업이 이미 풀었던 문제 A problem manufacturing solved decades ago
흥미로운 점은, 이와 비슷한 문제를 제조업이 수십 년 전에 풀었다는 사실이다.
자동차 한 대는 수만 개의 부품으로 이루어진다. 설계자, 생산자, 품질 검사자, 구매 담당자가 모두 다른 언어로 일한다면 공장은 하루도 못 돌아간다. 제조업은 이 문제를 BOM(Bill of Materials, 부품표)으로 해결했다. 모든 부품에 고유한 ID를 부여하고, 그 ID를 기준으로 설계·생산·품질·구매가 하나의 언어로 연결된다.
소프트웨어에도 이런 부품표가 필요하지 않을까.
코드 파일이 아니라, 사람이 이해하는 단위 — '회원가입 화면', '주문 취소 기능', '비밀번호 변경 프로세스' — 를 기준으로. 그리고 그 단위에 ID를 붙여서, 기획·개발·테스트·산출물이 모두 같은 ID로 연결되도록.
그게 SOM의 출발점이었다.