Data Management 실무 정리 ②

DATA MANAGEMENT · STORY 02

Data Management 실무 적용 정리 ②

구조를 이해하는 데서 멈추지 않고, 실제 문서와 흐름에 어떻게 적용했는지 제가 정리한 방식대로 풀어보았습니다.

Business Case

Service Context

Requirements

Use Case

Traceability

Data Management 실무 적용 정리 ②

지난 글에서는 Data Management를 어떤 구조로 보고 있는지 전체 관점 위주로 정리했습니다. 이번에는 한 단계 더 들어가서, 그 구조를 실제 업무에 어떻게 적용했고 어떤 기준으로 문서를 구성했는지 정리해보려고 합니다.

실제로 업무를 하다 보면 용어를 이해하는 것만으로는 정리가 끝나지 않습니다. Business Case, Service Context, Service Needs, Requirements, Use Case를 알고 있어도, 문서를 어디까지 어떤 기준으로 나눌지 정하지 않으면 결국 다시 섞이게 됩니다.

저도 처음에는 기능 단위로 정리하려고 했지만, 그렇게 접근하면 상위 목적과 실제 흐름이 분리되어 보이는 경우가 많았습니다. 그래서 현재는 문서 구조와 서비스 흐름을 같이 보는 방식으로 정리하고 있습니다.

1. 실무 적용의 시작점은 “경계”를 나누는 것이었습니다

제가 먼저 했던 일은 기능을 나열하는 것이 아니라, 어떤 내용이 어느 계층에 속하는지 경계를 나누는 것이었습니다. 실제로는 이 경계가 흐려지면 Service Context에 Requirements가 섞이기도 하고, Business Case에 구현 세부사항이 들어가기도 합니다.

그래서 문서를 작성할 때는 먼저 무엇이 목적이고, 무엇이 맥락이며, 무엇이 구체 요구사항인지 를 분리하는 작업부터 잡았습니다. 이 작업이 되어야 뒤에서 Use Case와 Traceability까지 자연스럽게 연결할 수 있었습니다.

2. 제가 실제로 적용한 문서 아키텍처

Practical Document Architecture

Business Case

왜 필요한가 / 어떤 가치와 목적을 설명할 것인가

↓

Service Context

어떤 이해관계자 / 어떤 운영 환경 / 어떤 범위와 제약인지 정리

↓

Service Needs

서비스 관점에서 필요한 기능 그룹과 역할 단위로 정리

Requirements

각 기능 그룹을 조건과 기준으로 구체화

↓

Use Case / Traceability

실제 동작 흐름으로 풀어보고, 상위 문서와 연결 관계를 검증

지금은 이 구조를 기준으로 문서를 보고 있습니다. 상위에서는 “왜 필요한가”를 설명하고, 중간에서는 “어떤 환경에서 어떤 역할이 필요한가”를 정리하며, 하위에서는 “무엇을 어떤 기준으로 구현·검토할 것인가”로 내려가도록 구성했습니다.

이렇게 나누어 보니 각 문서의 목적이 조금 더 분명해졌고, 나중에 Use Case를 만들거나 Traceability를 연결할 때도 어디서 무엇을 가져와야 하는지가 정리되기 시작했습니다.

3. 서비스 관점에서는 기능 그룹 단위로 먼저 묶었습니다

실제 서비스 구조를 볼 때는 세부 기능부터 쪼개기보다, 먼저 기능 그룹 단위로 묶어보는 방식이 더 정리하기 좋았습니다. 제가 적용할 때도 개별 API나 세부 컴포넌트부터 들어가기보다, 상위 기능 그룹을 먼저 정의하고 그 아래에서 역할을 정리했습니다.

Service Architecture View

Gateway + ASR

입력 수신 / 세션 시작 / 음성 인식

Auth

인증·권한 검토 대상

NLU

도메인/인텐트 분류

Dialog Engine

정책 / 대화 흐름 / 응답 결정

Domain Agent

외부 기능 호출 / 도메인 처리

이렇게 먼저 그룹을 나누면 문서를 작성할 때도 정리가 쉬워집니다. 예를 들어 Service Context에서는 이 그룹들이 어떤 역할을 담당하는지와 상호 관계를 설명하고, Requirements에서는 각 그룹별로 어떤 기준과 제약이 필요한지를 구체화하는 방식으로 내려갈 수 있습니다.

특히 실무적으로는 같은 내용을 어디에 적어야 하는지가 자주 헷갈리는데, 기능 그룹을 기준으로 잡아두면 문서 범위를 조금 더 안정적으로 유지할 수 있었습니다.

4. 실제 검토는 서비스 플로우로 풀어보는 방식으로 진행했습니다

구조를 세운 뒤에는 결국 흐름으로 풀어봐야 빠진 부분이 보입니다. 그래서 저는 문서를 검토할 때 정적인 구조도만 보지 않고, 실제 서비스가 어떻게 흘러가는지를 플로우로 다시 정리하는 방식을 같이 사용했습니다.

Operational Flow View

STEP 1

음성 호출

→

STEP 2

세션 시작

→

STEP 3

ASR 처리

→

STEP 4

NLU 분류

→

STEP 5

Dialog 처리

→

STEP 6

Domain 처리

→

STEP 7

응답 생성

→

STEP 8

운영/모니터링

이런 식으로 플로우를 만들어두면 Use Case를 작성할 때도 훨씬 명확해집니다. 각 단계에서 누가 주체인지, 어떤 입력과 출력이 있는지, 어디서 예외가 발생할 수 있는지, 그리고 어떤 항목이 상위 문서와 연결되어야 하는지가 보이기 때문입니다.

5. 적용하면서 가장 많이 조정한 부분

실무 적용 시 조정 포인트

아키텍처상 검토 대상과 Business Case 문서 범위는 항상 동일하지 않았습니다. 예를 들어 인증(Auth)과 같은 영역은 전체 서비스 구조에서는 검토 대상이 될 수 있지만, 현재 기준에서는 예정 기술 여부나 문서 목적에 따라 Business Case 서술 범위에서는 조정이 필요했습니다.

이 부분이 실무적으로 꽤 중요했습니다. 구조도에 들어간다고 해서 반드시 상위 문서에 같은 비중으로 서술해야 하는 것은 아니고, 문서 목적과 현재 범위에 따라 어디까지 다룰지를 다시 판단해야 했습니다.

결국 저는 “전체 구조는 보되, 현재 문서 목적에 맞는 범위만 담는다”는 기준으로 정리하고 있습니다. 그래야 문서가 과하게 넓어지지 않고, 실제 검토 대상도 더 선명해집니다.

6. 정리하고 보니 기준이 더 명확해졌습니다

현재까지 적용하면서 느낀 건, Data Management 실무는 단순히 문서를 채워 넣는 작업이 아니라 서비스를 설명 가능한 구조와 검증 가능한 흐름으로 바꾸는 작업에 가깝다는 점입니다.

문서 아키텍처를 먼저 정리하고, 그 다음 서비스 플로우로 검토하니 어떤 내용이 상위 개념인지, 어떤 내용이 실제 요구사항인지, 그리고 어떤 항목이 Use Case와 Traceability로 연결되어야 하는지가 훨씬 선명하게 보였습니다.

한 줄로 정리하면

제가 현재 적용하고 있는 방식은 Data Management 구조를 문서 계층으로 먼저 정리하고, 이를 실제 서비스 플로우와 연결해 Use Case와 Traceability까지 검증하는 방식입니다.

이번 글에서는 전체 구조를 실제 업무에 어떻게 적용했는지 정리해보았습니다. 다음 글에서는 Use Case와 Traceability를 어떤 기준으로 연결하고 있는지 조금 더 구체적으로 정리해보려고 합니다.