새로운 이론이 등장하면 반드시 따라오는 질문이 있다.
"기존 방식과 뭐가 다른가요?"
정당한 질문이다. 이미 세상에는 품질 관리 방법론이 넘친다. ISTQB가 있고, TDD가 있고, BDD가 있고, ISO 29119가 있다. 수십 년의 연구와 현장 검증을 거친 것들이다. 그 앞에서 SOM이 "다르다"고 말하려면 근거가 있어야 한다.
이번 화에서는 그 질문에 직접 답한다.
기존 방식의 공통점 What existing methods share
기존 품질 관리 방식들은 저마다 강점이 있다. 그러나 한 가지 공통점이 있다. 기준 단위가 기술 쪽에 있다.
TDD는 함수 단위로 테스트를 작성한다. BDD는 시나리오를 자연어로 쓰지만, 구현은 코드 단위로 연결된다. 커버리지 도구는 라인과 브랜치를 센다. 정적 분석은 파일과 클래스를 본다. 버그 트래커는 컴포넌트와 모듈로 이슈를 분류한다.
이것들이 나쁜 방식이라는 뜻이 아니다. 개발자 입장에서는 자연스럽고 효율적이다. 그런데 이 모든 것이 코드를 읽을 수 있는 사람 중심으로 설계되어 있다.
기획자는 어디에 있는가. PM은 어디에 있는가. 그들이 이해하는 단위 — '로그인 화면', '주문 취소 프로세스', '월별 보고서' — 로 품질을 이야기하는 도구는 어디에 있는가.
SOM의 출발점이 여기다. 기준 단위를 기술에서 비즈니스로 옮기는 것.
SOM이 대체하는 것이 아닌 이유 Why SOM replaces nothing
오해를 먼저 정리하자.
SOM은 TDD를 대체하지 않는다. BDD를 없애지 않는다. 커버리지 도구를 버리라고 하지 않는다. SOM은 그것들 위에서 작동하는 레이어다.
비유하자면 이렇다. 공장에서 BOM이 생긴다고 해서 용접 기술이 바뀌지 않는다. 선반 작업이 달라지지 않는다. 부품표는 부품을 만드는 방법을 바꾸지 않는다. 다만 부품들이 어떻게 연결되고 추적되는지를 바꾼다.
SOM도 마찬가지다. 개발자는 여전히 TDD로 코드를 짜도 된다. QA는 여전히 Playwright로 자동화 테스트를 돌린다. 다만 그 모든 활동이 SOM ID 아래 연결된다. 기술 결과물이 비즈니스 단위로 번역되는 것.
비교: 같은 상황, 다른 접근 Same situation, two approaches
상황: 회원가입 화면의 이메일 중복 검사 로직이 변경되었다.
기존 방식
개발자는 UserService.java를 수정하고 커밋한 뒤 PR을 올린다. QA는 TC-247을 재실행하고, 실패 시 BUG-389를 등록한다. 기획자는 개발자에게 "테스트 됐나요?"라고 구두로 확인한다. 산출물은 납품 전에 소급 업데이트된다.
흐름은 있다. 그러나 각 단계가 독립적으로 움직인다. 기획자가 TC-247이 무엇인지, BUG-389가 어떤 화면의 문제인지 알기 위해서는 누군가에게 물어야 한다.
SOM 방식
개발자는 SOM-0042 관련 커밋을 올리고, 이는 자동으로 SOM-0042 변경 이력에 기록된다. QA는 SOM-0042에 연결된 테스트 케이스 목록을 확인한 후 재실행하고, 결과는 SOM-0042에 기록된다. 기획자는 SOM-0042를 열면 변경 이력, 테스트 현황, 결함 이력을 한눈에 확인한다. 산출물은 SOM-0042를 기준으로 자동 생성된다.
SOM은 도메인을 가리지 않는다 SOM is domain-agnostic
여기서 중요한 질문이 하나 더 나온다.
"SOM이 웹 서비스에는 맞겠지만, 우리는 임베디드 소프트웨어를 개발하는데요."
"모바일 앱은요?" "게임은요?" "API 서버만 있고 UI가 없는데요?"
SOM의 핵심이 'UI 구성 요소'처럼 보이기 때문에 생기는 오해다. 사실 SOM의 핵심은 UI가 아니다. 비즈니스 단위로 기능을 식별하고, 그 단위에 ID를 부여하는 것이다.
이 원칙은 도메인을 가리지 않는다.
임베디드 소프트웨어에서 'ABS 제어 루틴', '온도 센서 읽기 함수'는 SOM의 Program이 된다. 모바일 앱에서 '푸시 알림 설정 화면', '결제 플로우'는 SOM Program이다. API 서버에서 '사용자 인증 엔드포인트', '주문 생성 프로세스'도 SOM Program이다.
UI가 있든 없든, 화면이 있든 없든, 웹이든 임베디드든 — 소프트웨어가 사용자 또는 시스템에게 제공하는 기능 단위가 존재하는 한, SOM은 적용된다.
안전 소프트웨어에서 SOM이 더 강한 이유 Why SOM is stronger in safety-critical software
도메인 무관함을 이야기할 때, 임베디드·안전 소프트웨어는 특별히 언급할 가치가 있다.
항공 소프트웨어는 DO-178C 표준에 따라 요구사항부터 테스트까지 완전한 추적성을 요구한다. 자동차 소프트웨어는 ISO 26262에 따라 ASIL 등급별 검증 근거를 남겨야 한다. 이 추적성 요구사항이 바로 SOM ID가 자연스럽게 충족하는 것이다.
요구사항 REQ-017이 SOM-0042와 연결되고, SOM-0042의 테스트 이력이 자동으로 쌓이면, 감사자는 "이 요구사항이 검증됐는가"를 SOM ID 하나로 확인할 수 있다.
그렇다면 SOM이 어려운 도메인은 없는가 Where SOM is harder to apply
솔직하게 말하자.
SOM은 기능 단위가 명확하게 식별되는 소프트웨어에 최적화되어 있다. 기획자가 "이런 화면이 있어야 한다", "이런 기능이 필요하다"고 말할 수 있는 소프트웨어.
기능 단위가 불분명하거나, 실험적인 연구 코드, 데이터 파이프라인의 중간 처리 로직처럼 비즈니스 언어로 설명하기 어려운 영역에서는 SOM의 Program 계층 정의가 어려울 수 있다. 이 경우 SOM은 일부 계층만 선택적으로 적용하거나, Module 수준까지만 사용하는 방식으로 유연하게 조정할 수 있다.
완벽한 이론은 없다. SOM도 마찬가지다. 다만 적용 가능한 범위가 생각보다 훨씬 넓다는 것이 지금까지의 이야기다.
다음 화부터는 실용서 파트다. SOM을 실제 프로젝트에 도입할 때 첫 번째로 해야 할 일을 구체적으로 이야기한다.