번호를 붙이는 행위는 단순해 보이지만, 그 안에는 강력한 선언이 담겨 있다.
"이것은 존재한다. 그리고 앞으로도 계속 존재할 것이다."
자동차 공장에서 브레이크 디스크에 P-4471이라는 번호를 붙이는 순간, 그 부품은 단순한 금속 덩어리에서 추적 가능한 자산이 된다. 설계 도면 속 번호와, 창고 선반의 번호와, 품질 검사 이력의 번호가 모두 같다. 누가, 언제, 어디서 꺼내 쓰더라도 P-4471은 P-4471이다.
SOM ID는 소프트웨어의 Program 계층에 이 선언을 한다.
ID가 없으면 무슨 일이 일어나는가 What happens without an ID
'회원가입 화면'을 생각해보자.
기획자는 화면 정의서에 '회원가입'이라고 쓴다. 개발자는 SignUpController.java를 만들고, sign-up.tsx 컴포넌트를 작성한다. QA는 'TC-회원가입-001'이라는 테스트 케이스를 만든다. 산출물 담당자는 '기능명세서_회원가입_v1.2.xlsx'를 저장한다.
이름은 모두 비슷하다. '회원가입'이라는 단어가 등장한다. 그런데 이것들이 같은 기능을 가리킨다는 것을 시스템은 알지 못한다. 연결하려면 사람이 직접 이어붙여야 한다.
6개월 후 기획이 변경된다. 회원가입 시 이메일 인증 단계가 추가된다. 어디를 업데이트해야 하는가. 화면 정의서? 테스트 케이스? 산출물? 개발 코드? 담당자가 기억하고 있다면 다행이다. 담당자가 퇴사했다면, 처음부터 찾아야 한다.
SOM ID의 탄생 시점 When the ID is born
SOM ID는 기획 단계에서 부여된다.
이것이 중요하다. 개발이 끝난 후, 테스트가 끝난 후, 납품이 끝난 후가 아니다. 화면 정의서를 작성하는 그 순간, Program이 확정되는 그 시점에 ID를 붙인다.
ID가 기획 단계에서 탄생하기 때문에, 이후의 모든 산출물이 이 ID를 참조할 수 있다. 개발자가 코드를 작성할 때 // SOM-0042를 주석으로 달거나, 커밋 메시지에 포함시킨다. QA가 테스트 케이스를 만들 때 SOM-0042를 태그로 붙인다. CI/CD 파이프라인이 실행 결과를 SOM-0042에 연결한다.
기획자가 붙인 번호 하나가 프로젝트 전체를 관통한다.
SOM ID 하나가 연결하는 것들 Everything one ID connects
SOM-0042 '회원가입 화면'을 예로 들면:
- 화면 정의서 페이지 12~15
- 요구사항 REQ-017, 018, 019
- 와이어프레임 WF-0042-v1, v2
- SignUpController.java
- sign-up.tsx, EmailInput.tsx
- API: POST /api/auth/signup
- Git 커밋 8개
- TC-0042-001 ~ TC-0042-018
- signup.spec.ts
- 실행 이력 47회 (통과 44, 실패 3)
- 결함 BUG-112, BUG-156
- 기능명세서 3.2절
- 테스트 결과서 p.24
- RTM 42번 행
이 모든 것이 SOM-0042 하나로 연결된다. 어느 방향에서 시작하든 나머지를 찾을 수 있다. 기획자가 SOM-0042를 열면 테스트 현황을 볼 수 있다. QA가 SOM-0042를 열면 요구사항을 볼 수 있다. 개발자가 SOM-0042를 열면 관련 결함 이력을 볼 수 있다.
SOM ID의 생애 The lifetime of a SOM ID
Jira 티켓과 SOM ID의 결정적 차이는 수명이다.
Jira 티켓은 할 일이 끝나면 닫힌다. '회원가입 구현' 티켓은 개발이 완료되면 Done 상태가 되고, 다음 스프린트에서는 잊혀진다. 기능은 살아있지만 티켓은 닫혔다.
SOM ID는 닫히지 않는다.
소프트웨어가 운영되는 동안 SOM-0042는 살아있다. 오늘 발생한 버그가 SOM-0042의 이력에 쌓인다. 다음 달 UI가 바뀌어도 SOM-0042는 유지된다. 2년 후 기능이 개편되면 SOM-0042의 버전이 올라가거나, 폐기 처리된다. 폐기되어도 이력은 남는다.
이것이 자산의 개념이다. 사용 중이든 폐기됐든, 자산에는 이력이 있다.
변경이 생겼을 때 When requirements change
이메일 인증 단계 추가 기획 변경이 생겼다. SOM-0042에 어떤 일이 일어나는가.
기획자가 SOM-0042의 요구사항을 업데이트한다. 변경 이력이 SOM-0042에 기록된다. 개발자는 SOM-0042를 열어 어떤 컴포넌트가 영향받는지 파악한다. QA는 SOM-0042에 연결된 테스트 케이스 중 재검증이 필요한 것을 식별한다. 산출물은 SOM-0042의 변경 이력을 바탕으로 자동 업데이트된다.
누군가에게 물어볼 필요가 없다. SOM-0042를 열면 된다.
ID는 작은 것이지만 Small number, big change
SOM ID는 기술적으로 복잡한 개념이 아니다. 번호 하나다.
그런데 그 번호가 없었을 때 무슨 일이 일어났는지 떠올려보면, 번호 하나가 얼마나 많은 것을 바꾸는지 알 수 있다. 소급 작성되던 산출물이 실시간으로 만들어진다. 구두로 전달되던 변경 영향이 시스템으로 추적된다. 개발자만 읽던 품질 정보를 기획자도 읽을 수 있게 된다.
번호를 붙이면 연결된다.