여기까지 두 가지를 이야기했다.

소프트웨어 품질 관리에는 세 가지 균열이 있다. 언어의 균열, 기준의 균열, 실행과 기록의 균열. 그리고 제조업은 비슷한 문제를 BOM — 부품표 — 으로 해결했다. 모든 부품에 번호를 붙이고, 그 번호로 조직 전체가 하나의 언어로 대화하게 만든 것.

이 두 이야기를 하나로 이으면 하나의 질문이 남는다. 소프트웨어에도 부품표를 만들 수 있다면?

선언 The declaration

소프트웨어의 구성 요소를 부품으로 보자.

로그인 화면, 회원가입 프로세스, 주문 취소 기능, 관리자 통계 대시보드. 이것들은 단순한 기능 목록이 아니다. 소프트웨어를 이루는 실질적인 부품이다. 자동차의 브레이크 디스크나 핸들처럼, 소프트웨어의 사용자가 직접 손에 쥐고 다루는 것들.

이 부품들에 번호를 붙이자. 기획 단계에서 이름과 함께 ID를 부여하고, 그 ID가 개발·테스트·운영·산출물까지 살아있게 하자. 부품표처럼.

SOM — Software Object Model

SOM은 소프트웨어의 UI 구성 요소를 비즈니스 단위로 자산화하는 체계다. 코드 파일이 아니라 프로그램 단위로. 클래스가 아니라 화면 단위로. 커밋이 아니라 기능 단위로. 그리고 그 단위에 ID를 붙여, 기획자·개발자·QA·PM이 모두 같은 번호로 대화하게 만드는 것.

이름이 생기면 실체가 생긴다 A name gives something a permanent existence

철학자 비트겐슈타인은 말했다. "내 언어의 한계가 내 세계의 한계다."

소프트웨어 품질에도 같은 원리가 적용된다. '회원가입 화면'을 지칭하는 고유한 ID가 없으면, 그것에 관한 이력을 연결할 방법이 없다. 이름은 있지만 번호가 없으면, 대화는 가능해도 추적은 불가능하다.

SOM ID가 부여되는 순간, 그 화면은 단순한 기능에서 자산이 된다.

자산에는 이력이 있다. 언제 기획됐는지, 어떤 요구사항을 담고 있는지, 어떤 테스트를 거쳤는지, 어떤 결함이 발견됐는지, 코드의 어느 부분과 연결되는지. 이 모든 것이 SOM ID 하나 아래 연결된다. 공장에서 브레이크 디스크 P-4471의 전체 이력을 조회하듯, SOM에서는 '회원가입 화면 SOM-0042'의 전체 이력을 조회할 수 있다.

SOM이 해결하려는 세 가지 Three cracks, one answer

1화에서 이야기한 세 가지 균열을 SOM은 이렇게 다룬다.

균열 1 해결 — 언어
기획자도 개발자도 QA도 SOM ID로 대화한다. "SOM-0042 테스트 완료됐나요?"라는 질문에 모두가 같은 맥락으로 답할 수 있다. 개발자가 파일 경로를 뒤질 필요도, 기획자가 Jira 티켓을 역추적할 필요도 없다.
균열 2 해결 — 기준
SOM의 단위는 처음부터 비즈니스 단위다. 커버리지도 SOM 기준으로 측정된다. '전체 SOM 중 몇 %가 검증됐는가'는 기획자도 바로 이해할 수 있는 숫자다. 코드 커버리지 78%가 아니라, 기능 커버리지 78%.
균열 3 해결 — 실행과 기록
테스트를 실행하는 단위가 SOM이고, 산출물을 기록하는 단위도 SOM이다. 처음부터 같은 단위로 묶여 있으니, 소급 작업이 필요 없다. 실행하는 순간 기록이 만들어진다.

SOM이 아닌 것 What SOM is not

오해를 미리 정리하자.

새로운 테스트 도구가 아니다. Playwright를 대체하거나, Jira를 없애거나, 기존의 개발 방식을 뒤엎는 것이 아니다. SOM은 기준 체계다. 기존 도구들 위에서 작동하는, 공통 언어를 만드는 레이어.
방법론도 아니다. 애자일처럼 "이렇게 일하라"고 말하지 않는다. 기준 단위를 정의하고, 그 단위에 이름과 번호를 붙이는 것. 그것이 전부다. 나머지는 기존의 프로세스와 도구가 한다.
만병통치약이 아니다. 품질 문제의 근본 원인은 사람, 프로세스, 조직 문화에 있는 경우가 많다. SOM은 그 문제들을 해결해주지 않는다. 다만 그 문제들을 보이게 만든다. 어떤 기능이 테스트되지 않았는지, 어떤 화면이 변경 영향권에 있는지, 어디서 결함이 반복되는지. 보여야 고칠 수 있다.

선언의 무게 The weight of declaring something new

새로운 이론을 선언하는 일은 쉽지 않다.

이미 세상에는 수많은 품질 관리 방법론이 있다. ISO 29119, ISTQB, TDD, BDD. 전문가들이 수십 년을 연구한 결과물들이다. 그 앞에서 "우리는 다른 방식이 필요하다"고 말하는 것은 용기가 필요한 일이다.

그러나 현장은 여전히 아프다. 감리 직전에 소급 작성되는 테스트 문서, 기획자가 이해 못하는 커버리지 숫자, 납품 후에도 추적 불가능한 기능 이력. 이론이 아무리 정교해도, 현장의 언어로 작동하지 않으면 의미가 없다.

SOM은 현장에서 출발했다. 한국 공공기관 소프트웨어 프로젝트의 납품 현장, 감리실, 회의실. 거기서 반복되는 문제를 보면서 만들어진 이론이다. 그래서 선언의 단위도 거창하지 않다. 부품표. 번호. 연결. 그게 다다.

이 글은 저자의 아이디어와 경험을 바탕으로 AI(Claude)의 도움을 받아 작성되었습니다.