일관성은 분류가 아니라 추적성에서 온다

산출물 체계를 설계하다 보면 한 번쯤 이 질문 앞에 멈춰선다. 업무, 요구사항, 기능, 유스케이스, 시퀀스, 시나리오, 테스트까지 일곱 단계로 이어지는 산출물의 분류를 어떻게 잡을 것인가. 모든 단계에 같은 분류 라벨을 달아 통일할 것인가, 단계마다 다른 분류를 둘 것인가.

직관은 “통일하면 일관성이 생긴다”고 말한다. 부딪혀보면 그 직관이 무너진다. 결론을 한 줄로 압축하면 이렇다. 일관성은 분류가 아니라 추적성에서 온다.

1. 추적성이란 무엇인가

추적성(traceability)은 산출물 간 연결을 끊김 없이 따라갈 수 있는 성질이다. 어떤 테스트 케이스가 있을 때, 그게 어느 시나리오를 검증하고, 그 시나리오가 어느 시퀀스를 엮으며, 그 시퀀스가 어느 유스케이스에서 나왔고, 그 유스케이스가 어느 기능을 구체화하며, 그 기능이 어느 요구사항을 실현하고, 그 요구사항이 어느 업무에서 출발했는지를 양방향으로 거슬러 갈 수 있는 능력이다.

여기서 핵심은 무엇으로 잇느냐다. 흔히 떠올리는 답은 분류다. 모든 단계에 같은 분류 라벨을 달면 라벨이 같은 것끼리 묶여서 추적이 된다는 발상이다. 이게 자연스럽게 “분류를 통일하면 일관성이 생긴다”는 직관으로 이어진다.

실제로는 다르다. 추적성을 만드는 것은 분류 라벨이 아니라 항목 간 id 매핑이다. 요구사항이 자기를 낳은 업무의 id를 참조하고(REQ-014 → BIZ-002), 기능이 자기를 실현하라고 요청한 요구사항의 id를 참조한다(F-031 → REQ-014). 분류가 무엇이든, 단계마다 다르든 같든, id 링크가 있으면 추적은 끊기지 않는다.

2. 어떻게 동작하나

이 관점을 받아들이면 분류 설계의 형태가 바뀐다. 모든 단계에 같은 분류를 강제하지 않아도 되고, 단계마다 완전히 독립된 분류를 둘 필요도 없다. 관점이 실제로 바뀌는 곳에서만 분류를 새로 정의하고, 그 외 구간은 상위 분류를 물려받는다.

예를 들어 데이터를 수집·가공·제공하는 시스템을 설계한다고 하자. 업무 레벨에서는 거버넌스 업무(정책 운영, 모니터링, 알림 등)와 생애주기 업무(수집·가공·제공)를 가르는 게 자연스럽다. 업무의 성격 축이다.

요구사항으로 내려가면 관점이 바뀐다. 더 이상 업무의 성격이 아니라 “무엇이 필요한가”의 주제로 묶인다. 인증 요구사항, 데이터 조회 요구사항, 정책 관리 요구사항 같은 식이다. 거버넌스 축은 여기서 어색해진다. 그래서 요구사항부터는 새로운 분류 — 주제·영역 축 — 를 도입한다. 업무의 거버넌스 분류는 거기서 멈추고, 요구사항에는 따라 내려가지 않는다.

기능으로 내려가면 또 한 번 관점이 바뀐다. 요구사항과 기능은 N:M으로 얽힌다. 한 요구사항이 여러 기능에 걸치고, 한 기능이 여러 요구사항에서 나온다. 분류 입자도도 달라진다. 그래서 기능 레벨에도 자신만의 분류를 둔다.

기능 아래로는 사정이 다르다. 유스케이스, 시퀀스, 시나리오, 테스트는 기능을 점점 구체화해 내려가는 정제(refinement) 관계다. 관점이 새로 바뀌지 않고 해상도만 높아진다. 한 기능에서 나온 유스케이스·시퀀스·시나리오·테스트는 자연스럽게 그 기능의 분류에 속한다. 그래서 이 구간은 기능 분류를 그대로 물려받는다. 굳이 단계마다 새 분류를 만들지 않는다.

정리하면 이렇게 된다.

일곱 벌이 아니라 세 개의 독립 분류로 줄고, 단계 간은 id로 잇는다. 단계 간 분류 축이 다를 수 있지만, id 링크가 그 차이를 메운다. 분류가 바뀌어도 추적은 끊기지 않는다.

3. 흔히 빠지는 함정

이 결론에 도달하기 전에 자주 마주치는 함정이 셋 있다.

첫 번째 함정 — 분류를 통일하면 일관성이 생긴다. 모든 단계에 같은 분류를 달면 추적이 깔끔해 보인다. 그래서 업무 레벨의 분류(예: 거버넌스/생애주기)를 체인 전체로 끌고 내려가고 싶어진다. 그런데 단계가 내려갈수록 그 분류가 의미를 잃는다. 인증 토큰을 검증하는 시퀀스 한 단계를 두고 “이건 보안 거버넌스다”라고 라벨을 다는 게 어색하다. 그 단계는 거버넌스 업무에도 쓰이고 생애주기 업무에도 쓰이는 공통 동작이다. 분류 축은 다루는 대상의 성격을 묶는 것이고, 단계마다 다루는 대상이 다르다. 한 축을 모든 단계에 강제하면 어딘가에서 어긋난다.

두 번째 함정 — N:M이니 분류를 갈아타야 한다. 통일이 어렵다고 깨달은 직후 따라오는 추론이다. 요구사항과 기능이 N:M이니 둘이 같은 분류를 공유할 수 없고, 그래서 다른 분류 체계로 갈아타야 한다는 논리다. 시퀀스와 시나리오 사이에서도 같은 추론이 등장한다. 이건 그럴듯하지만 잘못된 인과다. N:M은 분류의 문제가 아니라 링크의 문제다. 예를 들어 요구사항 REQ-014(데이터 조회)가 기능 F-031·F-032로 갈라지고, 기능 F-032가 REQ-014·REQ-018(권한 확인)에서 묶여 나오는 게 N:M이다. 두 요구사항이 같은 분류를 달든 다른 분류를 달든 이 다대다 링크 자체는 변하지 않는다. 분류를 갈아탄다고 N:M이 1:1로 바뀌지 않는다. 링크와 분류는 다른 차원이다. 이걸 분리하지 못하면 분류 체계가 N:M에 끌려다닌다.

세 번째 함정 — 모두 독립 분류로 두면 정확하다. 통일도 못 하고 N:M도 분류로 풀 수 없다면, 단계마다 독립된 분류를 두자는 결론이 떠오른다. 정확하긴 한데 다른 극단이다. 일곱 단계마다 분류 체계를 따로 정의하고 유지하면 관리 비용이 폭발한다. 게다가 정제 구간(기능 아래)은 관점이 바뀌지 않는 곳이라, 독립 분류를 두면 사실상 같은 분류를 이름만 바꿔 네 번 정의하는 중복이 된다. 정확성을 위해 군더더기를 양산하는 셈이다.

세 함정의 공통점은 분류와 추적성을 한 덩어리로 본다는 것이다. 분류가 일관되어야 추적이 된다는 가정, 분류가 다르면 추적이 깨진다는 가정이다. 이 가정을 놓으면 길이 열린다. 분류는 단계마다 달라도 되고, 그 차이는 id 매핑이 메운다. 일관되어야 하는 것은 분류가 아니라 추적의 연결이다.

4. 정리

• 분류 축은 단계마다 다룰 수 있고, 그게 정상이다. 한 축을 모든 단계에 강제하면 어딘가에서 의미가 흐려진다.
• N:M은 링크의 문제이지 분류의 문제가 아니다. 두 차원을 섞지 않는다.
• 단계 간 추적은 분류 일치가 아니라 id 매핑으로 잇는다.
• 분류는 관점이 바뀌는 전환점에서만 새로 정의하고, 정제 구간은 상위 분류를 물려받는다.

시스템마다 전환점의 수는 다를 수 있다. 단순한 시스템은 한두 개로 끝나고, 복잡한 시스템은 더 늘어난다. 다만 그 수가 몇이든 한 가지는 변하지 않는다.

일관성은 분류가 아니라 추적성에서 온다.