기원전 91년, 사마천은 감옥에 있었다. 황제를 거슬렀다는 죄로 궁형을 받은 그는 치욕 속에서도 붓을 놓지 않았다. 아버지의 유언이 있었고, 더 중요하게는 해결해야 할 문제가 있었다. 수천 년에 걸친 중국의 역사 기록들. 방대하고, 흩어져 있고, 서로 연결되지 않은 데이터들. 그것을 어떻게 구조화할 것인가.

편년체의 한계 The limits of chronological records

사마천 이전에도 역사서는 있었다.

공자가 편찬한 《춘추(春秋)》가 있었다. 시간 순서대로 사건을 나열한 편년체(編年體) 역사서였다. 기원전 몇 년에 무슨 일이 일어났다. 그 다음 해에 또 무슨 일이 있었다. 정확하지만 불편했다.

"항우는 어떤 사람이었나"를 알고 싶으면, 기원전 209년부터 기원전 202년까지 흩어진 기록을 모두 뒤져야 했다. 항우에 대한 정보가 시간 축에 분산되어 있었다. 인물을 기준으로 조회할 방법이 없었다.

사건 중심이었기 때문이다. 주어가 시간이고, 인물과 제도는 그 시간에 종속된 술어였다.

기전체의 혁신 — 중심 좌표를 바꾸다 The innovation of the annals-biography form

사마천은 주어를 바꿨다.

시간이 아니라 인물과 국가를 중심 좌표로 삼았다. 그 아래 시간이 종속되었다. 이것이 기전체(紀傳體)다.

구성중심내용
본기(本紀)황제천자의 치세 전체 연대기
세가(世家)제후제후국의 흥망과 운영 기록
열전(列傳)인물각 인물의 생애와 활동
표(表)시간 × ID여러 국가·인물의 사건을 교차 격자로
서(書)제도예법·음악·천문 등 공통 표준 시스템

"항우를 보여줘"라고 하면, 본기에 그의 연대기가 있고, 열전에 그를 둘러싼 인물들의 이야기가 있고, 표에서 그의 시대를 가로축으로 읽을 수 있다.

하나의 ID(항우)가 모든 관점의 교차점이 된다.

Jira는 편년체다 Jira is chronological

현대의 ALM 도구들을 생각해보자.

Jira에서 "로그인 화면의 역사"를 알고 싶으면 어떻게 해야 하는가. 로그인 관련 이슈를 검색하고, 커밋 로그를 뒤지고, 테스트 결과 보고서를 찾고, 결함 티켓을 모은다. 모두 시간 축에 흩어져 있다.

이슈가 생성된 날짜 순으로 쌓일 뿐이다. 티켓은 닫히면 사라진다. "로그인 화면"이라는 중심 좌표가 없다.

편년체다.

방대하고 정확하지만, 기능 단위로 조회할 방법이 없다. 이벤트가 주어이고, 기능은 그 이벤트의 태그(label)로만 존재한다.

SOM = 소프트웨어의 기전체 SOM is software's annals-biography form

SOM이 하려는 것이 정확히 이것이다.

주어를 바꾼다. 이벤트(이슈, 커밋, 결함)가 아니라 SOM ID가 중심 좌표가 된다. 모든 이벤트가 SOM ID에 귀속된다.

┌─────────────────────────────────────────────────────────┐
│            사기(史記)  →  SOM 아키텍처                   │
├───────────┬─────────────────┬──────────────────────────┤
│  사기 구성 │     중심         │       SOM 대응           │
├───────────┼─────────────────┼──────────────────────────┤
│  본기(本紀) │  황제           │  Project / Module        │
│  세가(世家) │  제후국         │  SOM ID (Program)        │
│  열전(列傳) │  인물           │  연관 컴포넌트·API 자산   │
│  표(表)    │  시간 × ID 격자  │  ID × ID 영향도 매트릭스  │
│  서(書)    │  공통 제도·표준  │  거버넌스·공통 표준 자산  │
└───────────┴─────────────────┴──────────────────────────┘
                        ↓ Digital Transformation ↓
         SOM ID를 클릭하면: 기획·배포·결함·타임라인·공통 모듈
                      모두 하나의 좌표 아래 집결

사기에서 항우(項羽)를 검색하듯, SOM에서 LOGIN-001을 클릭하면:

요구사항: 이 화면이 왜 만들어졌는가
배포 이력: 언제, 무엇이 바뀌었는가
테스트 결과: 마지막으로 검증된 것은 언제인가
결함 이력: 어떤 문제가 있었고 어떻게 해결됐는가
연관 자산: 어떤 공통 모듈에 의존하는가
소스 변경: 최근 커밋이 무엇을 바꿨는가

모두 같은 ID 아래 있다. 사람을 모을 필요가 없다.

표(表) — ID × ID 영향도 매트릭스 The table — an ID × ID impact matrix

사기의 표를 자세히 보면 단순한 연표가 아니다.

세로축은 시간이고, 가로축은 제후국이다. 특정 연도에 어느 나라에서 무슨 일이 있었는지, 하나의 격자에서 교차 조회된다. 진(秦)나라와 초(楚)나라가 동시에 어떤 상태였는지 한눈에 읽힌다.

SOM의 표는 여기서 한 걸음 더 나아간다.

시간 × ID뿐 아니라 ID × ID의 교차 격자가 가능하다. 특정 공통 모듈(인증 서비스, 공통 팝업, 데이터 검증 레이어)이 변경되었을 때, 어떤 SOM ID들이 동시에 영향을 받는지 격자 형태로 드러낸다.

         AUTH  POPUP  VALID  CART  ORDER
LOGIN-001  ●     ○      ●     ○     ○
JOIN-002   ●     ●      ●     ○     ○
MYPAGE-003 ●     ○      ●     ○     ○
ORDER-010  ○     ○      ●     ●     ●
ADMIN-020  ●     ●      ○     ○     ○

공통 인증(AUTH) 모듈이 바뀌면 LOGIN-001, JOIN-002, MYPAGE-003, ADMIN-020이 동시에 영향을 받는다. 격자가 그것을 즉시 보여준다. 배포 전 어떤 SOM을 재검증해야 하는지 이 표 하나로 결정된다.

사마천의 표가 제후국 간의 동시 상황을 보여주듯, SOM의 표는 ID와 ID 간의 의존성을 드러낸다. 영향도 분석의 완전성이 여기서 나온다.

서(書) — 거버넌스의 확립 The treatises — establishing governance

기전체에서 가장 간과되는 구성이 서(書)다.

서는 특정 인물이나 사건의 기록이 아니다. 국가 운영의 표준 시스템을 다룬다. 예법(禮), 음악(樂), 천문(天文), 역법(曆法). 이것들은 어떤 황제가 다스리든, 어떤 제후가 등장하든, 변하지 않는 공통 기준이다. 본기의 황제도, 열전의 영웅도, 이 서(書)의 규격 안에서 행동한다.

SOM에서 서(書)는 전사적 품질 거버넌스다.

UI 표준(버튼 규격, 오류 메시지 형식), 데이터 제약 조건(필수값, 형식 검증), 보안 프로토콜(인증 처리, 세션 관리), 공통 컴포넌트 스펙. 이것들은 개별 SOM ID가 아무리 화려해도 벗어날 수 없는 Material Spec이다.

사마천이 예(禮)와 악(樂)을 서(書)로 정리하여 국가 운영의 표준을 세웠듯, SOM의 서(書)는 개별 프로그램이 따라야 할 표준 자산의 규격을 정의한다. 이 규격이 있어야 수백 개의 SOM ID가 제각각이 아니라 하나의 시스템으로 동작한다.

서(書) 없는 기전체는 군웅할거(群雄割據)다. 거버넌스 없는 SOM도 마찬가지다.

동일 사건이 여러 편에 등장하는 이유 Why one event appears in many chapters

사기에는 흥미로운 점이 있다.

같은 사건이 여러 편에 중복 등장한다. 항우의 죽음은 본기에도 나오고 열전에도 나온다. 모순이 아니다. 관점이 다를 뿐이다. 본기는 시대의 종말로 읽히고, 열전은 한 인간의 최후로 읽힌다.

SOM도 마찬가지다.

로그인 화면(LOGIN-001)은:

기획자 관점에서는 요구사항 REQ-003에 연결된 기능
개발자 관점에서는 AuthController가 처리하는 엔드포인트
QA 관점에서는 테스트 케이스 12개가 있는 검증 대상
운영자 관점에서는 이번 배포에서 변경된 모듈

하나의 중심 좌표
네 사람이 보는 관점이 다르다. 그러나 중심 좌표는 하나다. LOGIN-001.

관점이 달라도 같은 ID로 대화할 수 있다는 것, 이것이 기전체의 힘이고 SOM의 힘이다.

자산의 가치 — 축적될수록 강해진다 The value of an asset that grows over time

사기가 완성된 것은 기원전 91년이다. 그런데 사기의 진짜 가치는 완성 직후가 아니라 후대에 발휘됐다.

한(漢)나라 이후 수천 년간, 통치자들은 사기에서 교훈을 읽었다. 항우의 실패에서 전략을 배우고, 명재상들의 열전에서 인재 등용의 기준을 찾았다. 기록이 축적될수록 자산의 가치가 높아졌다.

SOM도 같은 원리가 작동한다.

프로젝트 초기의 SOM ID는 가볍다. 요구사항과 개발 이력 몇 줄이 전부다. 그러나 테스트가 쌓이고, 결함이 기록되고, 변경 이력이 누적될수록 그 SOM ID는 두꺼워진다. 그리고 그 두께가 자산의 신뢰도가 된다.

신규 프로젝트에서 유사한 기능을 개발할 때, 과거에 검증된 SOM ID의 기획 의도(본기)와 테스트 이력(열전)을 그대로 참조할 수 있다. 무엇이 실패했고, 어떻게 해결됐으며, 어떤 엣지 케이스가 존재하는지 — 이미 검증된 SOM은 다음 프로젝트의 출발점이 된다. 설계의 재사용성과 신뢰성을 동시에 확보하는 것.

이것이 P5(골드) 등급 자산이다. 시간이 지날수록 닳는 것이 아니라, 시간이 지날수록 무거워지는 자산.

사마천이 해결한 문제와 우리가 해결하려는 문제 The problem he solved, and the one we face

사마천은 역사를 보관하려 하지 않았다. 조회 가능하게 만들려 했다.

수천 년의 흩어진 기록들이 있었다. 그것들을 시간 순으로 나열하는 것은 쉬운 일이었다. 어렵지만 진짜 필요한 것은 "누구든, 어떤 질문이든, 원하는 중심 좌표에서 읽을 수 있는 구조"였다.

우리 앞에도 같은 문제가 있다.

수백 개 프로그램의 요구사항, 설계 문서, 커밋, 테스트 결과, 결함 이력이 흩어져 있다. 그것들을 시간 순으로 보관하는 것은 이미 하고 있다. 어렵지만 진짜 필요한 것은 "누구든, 어떤 질문이든, SOM ID를 중심 좌표로 삼아 즉시 읽을 수 있는 구조"다.

기전체를 짓는 일이다.

소프트웨어의 사기(史記) The Shiji of software

사마천이 기전체를 완성했을 때, 중국의 수천 년 역사는 처음으로 조회 가능한 형태가 되었다.

SOM이 완성될 때, 소프트웨어의 역사도 처음으로 조회 가능한 형태가 된다.

개발자가 묻는다. "이 화면, 왜 이렇게 만들어졌지?"
기획자가 묻는다. "이 요구사항, 실제로 구현됐나?"
QA가 묻는다. "마지막으로 테스트한 게 언제지?"
운영자가 묻는다. "이번 배포에서 이 화면에 무슨 일이 있었나?"

네 사람 모두 같은 ID를 클릭한다. 답이 거기 있다.

우리는 코드를 보관하는 것이 아니다. 설계의 의도를 증명하고, 그 실체를 자산화한다.

사마천이 죽음 앞에서 기록을 택했듯,
우리는 혼돈의 현장에서 SOM이라는 질서를 택했다.
우리는 코드를 보관하는 것이 아니라, 설계의 의도를 증명하고 자산화한다.