요구사항 & 스펙 DB 기반 명세 운영 체계 구축

00

배경

이 사례는 단순 문서 정리가 아니라, 요구사항을 프로젝트 진행 단위와 분리된 장기 스펙 자산으로 만들고 스토리·테스트와 다시 연결한 운영 시스템 설계 사례이다. 핵심 개념 전환은 프로젝트 > 요구사항 > 스토리 구조를 프로젝트 > 스토리 | 관련 요구사항 구조로 바꾼 점이었다. 요구사항 객체는 관련 스토리, 개정 내역, 요구사항, 구현 결과, 상태, 파트를 포함한 운영 단위로 설계했다. 핵심 근거는 공통 DB와 LP/TS 전용 뷰 분리, 테스트 결과 템플릿, 요구사항 혹은 스펙 변경 문서이다.

01

문제 정의

핵심 문제는 문서가 흩어져 있다는 단순한 현상이 아니라, 요구사항의 생명주기와 프로젝트의 생명주기가 섞여 있어 혼선이 생기는 구조였다. 프로젝트 단위 문서 안에 요구사항을 넣어두면 프로젝트가 끝날 때마다 현재 스펙, 최신 변경, 구현과 요구사항의 연결 관계를 파악하기 어려워집니다. 이 구조는 QA 혼선, 프로젝트 진행률 왜곡, 현재 스펙 조회 혼동으로 이어질 수 있었다. 즉 문제의 본질은 정리 부족이 아니라, 제품 지식이 재사용 가능한 자산으로 남지 않는 구조였다.

02

가설

• 요구사항을 프로젝트 문서에서 분리해 장기 스펙 자산으로 관리하면, 최신 스펙 조회와 변경 이력 추적이 더 명확해질 수 있다.
• 요구사항을 프로젝트 문서의 하위 항목이 아니라 독립 운영 자산으로 만들면, 여러 프로젝트를 거쳐도 최신 스펙을 유지할 수 있다.
• 스토리와 테스트를 요구사항 객체에 다시 연결하면, 요구사항 → 구현 → 검증 관계를 더 명확하게 추적할 수 있다.
• 공통 DB와 역할별 뷰를 분리하면, 원본 안정성과 실무 조회 편의성을 동시에 확보할 수 있다.
• 공통 DB, 역할별 뷰, 테스트 relation을 함께 설계하면 요구사항, 구현, 검증을 하나의 제품 지식 시스템으로 연결할 수 있다.

03

실행

• 프로젝트 > 요구사항 > 스토리 구조를 프로젝트 > 스토리 | 관련 요구사항으로 바꾸는 개념 전환을 만들었다.
• 요구사항 객체에 관련 스토리, 개정 내역, 요구사항, 구현 결과, 상태, 파트를 포함한 운영 단위를 설계했다.
• 요구사항 혹은 스펙 변경 문서를 통해 여러 프로젝트를 거쳐도 최신 스펙 자산으로 유지되는 원칙을 만들었다.
• 공통 DB와 LP/TS 전용 뷰 분리 구조를 설계해 원본 안정성과 역할별 실무 조회 구조를 동시에 확보했다.
• 테스트 결과 템플릿을 통해 요구사항 → 구현 → 검증 relation이 이어지도록 연결했다.
• 이 과정에서 요구사항 문서를 프로젝트 관리 도구가 아니라, 조직의 장기 제품 지식 시스템으로 재정의했다.

04

검증

요구사항 혹은 스펙 변경 문서는 요구사항이 장기 자산으로 유지되는 구조의 핵심 근거였다.

• 공통 DB + LP/TS 전용 뷰 분리는 역할별 조회 편의성과 원본 안정성을 함께 고려한 설계였다는 근거였다.
• 테스트 결과 템플릿은 요구사항 → 구현 → 검증 relation이 실제로 이어졌다는 근거였다.
• 검증의 핵심은 단순히 DB를 만든 것이 아니라, 최신 스펙 조회와 구현·검증 연결이 더 명확해졌는지를 확인하는 것이었다.
• 현재 스펙을 더 빠르게 찾을 수 있는가,
• QA와 구현이 같은 요구사항을 바라보는가,
• 프로젝트가 달라도 요구사항 자산이 유지되는가

05

결과

06

내 역할 / 오너십

• 요구사항 객체의 정의를 설계하고,
• 프로젝트/스토리/테스트의 관계를 재설계하고,
• 역할별 조회 구조를 분리하고,

07

근거

• 요구사항 혹은 스펙 변경 문서
• 공통 DB / LP·TS 전용 뷰 구조
• 테스트 결과 템플릿