ARAMDAUN

[DataOps Manager] 입사 1달차 후기

알밤바 — Sun, 26 Apr 2026 22:40:19 +0900

우리 존재 화이팅

새로운 커리어 시작!

많은 고민 끝에 결정한 새로운 커리어 방향을 향해 많은 시도들을 해온 지난 몇 개월.
그 결과, 현재 DataOps Manager로서 입사를 해서 약 1달 정도 지나갔다.

아직 회사 서비스를 익히고 시스템에 적응하는 중이다.
이전 회사에서 해왔던 업무와 유사해서 업무는 빠르게 적응하고 진행하고 있다.
그 외에 다른 점이라고 한다면, AI 활용도이다.

AI 콘텐츠 회사답게, AI를 적극적으로 활용하도록 지향하고 있으며 전체 업무에 AI를 활용할 수 있도록 환경이 조성되어 있다.
AI를 어떻게 활용해야 업무 효율성을 높일 수 있을지에 대한 고민과 공부가 필요하다는 것을 많이 느꼈다.

입사 1달차, 무엇을 하고 있는지?

현재 회사 서비스의 신규 기능에 대한 로그 설계를 담당하고 있다.
그리고 기존에 정의되어 있는 택소노미 정책을 파악하고 이를 기반으로 로그 설계를 하고 있다.

앞으로 더 확장해서 이벤트 로그 택소노미, 거버넌스 업무까지 담당할 예정이다! (일단 내 생각)

이전 회사에서부터 시작된 고민

이전 회사에서도 로그 설계부터 데이터 거버넌스 쪽 업무를 담당하였고, 업무를 하면서 많은 고민 지점들이 있었다.

1. 이벤트 로그 택소노미

AI의 활용도가 높아지면서 AI를 더 잘 활용하는 방법도 중요해지고 있다.
AI가 이해할 수 있도록 데이터를 제공해주는 것도 중요해졌기 때문에 더욱 이벤트의 통일성, 규칙이 중요해졌다.

최근 여러 기업에서도 다양한 형태의 서비스, 기능들이 출시되고 있다.
신규 서비스, 기능에 맞춰 데이터를 수집하다보면 기존에 수집해오던 이벤트와 정의한 정책들에 벗어난 형태가 많다. 그러다보면 새로운 이벤트 새로운 정책들이 생겨나고 결국 거버넌스는 깨지고 만다.
그렇기에 이를 해결할 수 있는 방안을 마련하고 규칙을 잡아서 전사 이벤트의 통일성을 주어야 한다.

이전 회사는 기본적인 네이밍 규칙은 정해져 있었지만, 세부 디테일에서 고민이 많았다.
세부 이벤트 표현 방식부터 부가 속성들에 대한 규칙까지. 이것을 정리하는 것이 가장 필요했고, 그 부분을 명확히 정리하고 싶었다.

2. 이벤트 로그 설계 시스템화

규칙이 정해져 있지만 설계하는 것은 각 담당자의 몫이기 때문에, 각기 다르게 설계하는 휴먼 에러를 방지할 수 있는 시스템을 구축하는 것이 필요하다고 생각하였다. (우선 시스템화를 하기 위해서는 규칙이 명확히 되어 있어야 한다.)

하지만 전사 관점의 업무로 많은 리소스를 잡아야 하므로 큰 작업이긴 하지만, 시스템화를 통해 휴먼 에러를 방지할 뿐만 아니라 업무 효율성도 증대할 수 있기 때문에 필요한 작업이라고 생각한다.

시스템화 할 때 공수를 많이 들기 때문에, 이것을 줄일 수 있는 AI 활용법이 있을지 고민 중이다.

3. 데이터 정기 모니터링 시스템화

로그를 설계하고 개발, 운영 환경에서 QA를 진행하지만, 그럼에도 여러 상황들로 인해서 이벤트가 정상적으로 수집되지 않는 경우들이 종종 있다.

그렇다보니 데이터 정합성 문제 등 데이터 신뢰성의 문제가 생기게 되고, 이것을 해결하는 것도 하나의 큰 과제이다.

이를 해결하기 위해서는 우선 데이터가 잘 수집되는지 모니터링할 수 있는 시스템이 필요하다.

나는 개인적으로 이것이 중요하다고 생각하나, 일단 데이터를 수집하는 것이 우선이었다보니 1차 논의까지 진행되었지만 다음 스텝으로 진전되지 못한 것이 너무나 아쉬웠다.

그래서 이 시스템을 반드시 구축해볼 것이다..!

4. 레거시 관리

이전에 수집해온 데이터들에 대한 처리도 필요하다. 레거시 데이터도 반드시 있을 것이고 이것을 어떻게 처리 및 활용할지에 대한 방안, 정책도 정의해야 한다.
더 이상 필요로 하지 않는 데이터, 정책이 변경되면서 이벤트명이 달라진 데이터, 잘못 수집되고 있던 데이터 등에 대해 논의를 해서 정책을 마련해야 한다.

앞으로 하고 싶은 것 & 실행 계획

이전 회사에서부터 고민해오던 것과 현 회사에서 더 좋은 데이터 환경을 만들기 위해서 하고 싶은 과제들을 정리해보았다.

어느정도 스스로 기획을 해서 제안해서 하나씩 시스템을 만들어가는 것이 이번 회사에서의 내 목표 중 하나이다!

1. 데이터 신뢰성 증대

이벤트 택소노미 정책 고도화 (속성 및 enum 사전 구축 등)
이벤트 설계 검토 시스템 구축 (이벤토 로그 설계 자동화가 될 경우, 대체 가능)
데이터 정기 모니터링 시스템 구축
레거시 및 버전 관리

2. 업무 효율성 증대

이벤트 로그 설계 자동화 (노출 형태, 요소 등 인식하여 이벤트 자동 태깅)
이벤트 QA 자동화

이벤트 택소노미 정책이 이미 잘 구축되어 있지만, 더 나은 환경을 위해 개선해나가고자 한다.

그리고 이제는 AI를 활용하면 많은 인원이 투입되지 않아도 시스템을 구축할 수 있다.

주도적으로 시스템의 기반을 만들어보고 더 나은 환경에서 업무를 수행할 수 있도록 만들어보고자 한다!

이렇게 블로그에 써서 무조건 목표 달성할 수 있도록...! 화이팅!

⭐️목표⭐️ 5월 안에 1개는 완성하기!

데이터 아키텍처 준전문가 (DAsP) 자격증 공부 방법 & 시험 합격 후기

알밤바 — Sun, 19 Apr 2026 00:17:49 +0900

제 60회 데이터 아키텍처 준전문가 (DAsP) 합격

약 2주 정도 공부하고 (사실상 1주 동안 빠짝 공부함) DAsP 자격증 시험을 합격했다!

나의 향후 커리어를 생각했을 때, 데이터 전반을 볼 수 있는 시야와 데이터 구조를 파악하는 능력을 보유하고 있어야 한다고 생각했다.

그래서 데이터 아키텍처 쪽으로 관심이 생겼고, 관련되어서 DAsP(데이터 아키텍처 준전문가) 자격증이 있다고 해서 찾아보았다.

다들 이 자격증은 큰 의미가 없다고 한 글들이 많이 있었다.

나는 자격증으로써 증명하기 위한 수단으로는 약할 수 있다고는 생각하지만, 내가 이 분야에 입문하기에는 큰 도움이 될 수 있을 것이라는 생각이 들었다. 마침 관심있던 데이터 표준화와 모델링 과목도 있어서 이 김에 공부하면 좋을 것 같았다.

그래서 준비한 데이터 아키텍처 준전문가 (DAsP) 자격증 준비 및 시험 후기에 대해 공유하고자 한다!

1. 데이터 아키텍처 준전문가 (DAsP)

한국데이터산업진흥원에서 주최하는 자격증이며, 민간등록자격이다. (국가공인 민간자격 아님!)

데이터자격검정 - 데이터자격시험, DAP, DAsP, SQLP, SQLD, ADP, ADsP.

데이터자격시험, DAP, DAsP, SQLP, SQLD, ADP, ADsP.

www.dataq.or.kr

전사 아키텍처 지식 기반으로 데이터 요건 분석, 표준화, 모델링에 대한 지식에 대한 자격증 시험이다.

총 4과목이며, 총 50문제 (1~3과목 : 10문제, 4과목 20문제) 이며,

전체 과목 점수는 60점 이상이어야 합격이며, 과목별 40점 이상이어야 함.

다른 자격증 시험 (ADsP, SQLD)와 다르게 연 2회 시행하기 때문에, 준비하시려면 일정 꼭 확인하세요!

2. DAsP 공부 방법

1) 데이터아키텍처 준전문가 (DAsP) 한권으로 끝내기 - 핵심요약 및 연습문제

데이터아키텍처 준전문가(DAsP) 한 권으로 끝내기 | 김상목

‘데이터아키텍처 준전문가(DAsP) 한 권에 끝내기’는 DAsP 시험을 준비하는 이들을 위해 주요 개념을 핵심요약으로 설명했다. 학습한 내용을 연습문제로 풀어봄으로써 실력을 점검할 수 있도록

www.aladin.co.kr

이 책을 구매해서 이론 공부 및 문제 여러번 반복해서 풀었다.

ADsP, SQLD 자격증 준비를할 때, 문제를 푸면서 이론을 익히는 것이 빨랐기 때문에 이번에도 문제집을 구매했다. (중고로)

이론은 후루룩 공부하고 문제를 풀면서 이론을 다시 공부하며 개념을 정립해가는 방식으로 공부했다.

하지만 이 책의 단점은 문제 해설이 없기 때문에 이해하기는 조금 어려운 문제가 있었지만, 오히려 해설이 없기 때문에 이론서에서 내용을 찾으면서 더 많은 공부가 되었음.

이 책의 이론서+문제 내용을 기반으로 이 블로그에 하나씩 정리했다.

일단 블로그에 정리해두면서 하나씩 머릿속에 입력시켰음. 하지만 구조화가 되지 않다보니 내용들이 산발되어 있어 정리가 되지 않았다.

그래서 각 과목별로 어떤 내용들이 있고 어떤 식으로 구성이 되는지, 이 과목에서 말하고자 하는 정보는 무엇인지에 대해 구조화를 하였다.

그것까지 블로그에 다 정리해놓았으니 참고하시면 좋을 듯하다!

데이터아키텍처 준전문가 (DAsP) 정리

'Data Analysis/데이터 아키텍처' 카테고리의 글 목록

데이터를 공부합니다.

ars420.tistory.com

2) 기출 문제 공부

사실 이 자격증은 기출 문제를 찾기가 매우 어렵다...

하지만 그럼에도 이 기출 문제가 정말 중요한 시험이기 때문에 열심히 구글링해서 찾는 것이 중요함!

DAsP 문제풀이 오답 노트

데이터아키텍처 자격검정 실전문제 를4차에 걸쳐 풀면서 2차~ 4차풀이에서 오답한 문제에 대해서 복습 차원에서 정리한 내용입니다. 4차 풀이 오류 A75. 서브타입의 적용 기준으로 부적합한 것을

bluedata2050.tistory.com

나는 이 분 블로그를 시험 직전에 찾아서 공부를 했는데, 확실히 기존에 보지 못했던 문제들이라서 새로운 개념을 알게 되어서 좋았다.

위에서 말한 책의 내용이 다소 부실하기 때문에 직접 정보를 찾는 것도 중요하다!

3. DAsP 시험 후기 (고사장, 난이도 등)

1) 고사장 선택

우선 고사장이 너~~~~무 없다. 서울 몇 개, 그리고 부산 1개?

나는 마침 친구 결혼식 때문에 내려가야 하는 상황이라서 부산 고사장으로 선택했다. 생각보다 너무 없어서 당황했음..

접수 시작할 때 확인하면 너무 당황스러울 수 있으니, 미리 시험 접수 전에 고사장 확인해보시길 바란다

2) 시험 난이도

시험 난이도는 내 기준에는 조금 높았다.

대부분 한 번씩 본 내용이긴 한데, 디테일한 부분에서 어려웠다. 그래서 헷갈리는 문제들이 많았다...

헷갈리는 문제들을 계속 읽으면서 문제를 풀어나갔고, 계속 문장을 곱씹다보니 정답이 보였다.

생각보다 디테일이 중요하다는 점..! 디테일하게 공부하는 것이 필요해보인다.

다시 시험을 본다면 저 책만으로 의존하는 것이 아닌 다른 문제들을 찾아봤을 듯!!

하지만 생각보다 많은 분들이 시험 시작 1시간 전에 나가셨다. (대단하신 분들..)

나는 1시간 10분이 지난 후에 나갔는데, 그 때 나의 고사장 교실에는 나 포함 3명 밖에 없었음.....

4. DAsP 자격증 준비 후기

역시 자격증은 이론 위주이기 때문에 공부하는 것이 쉽지는 않았다.

그럼에도 내가 이 분야에 입문할 때 간단히 공부하는 용도로는 괜찮은 것 같다.

이론과 실무가 완전히 매핑되지는 않지만 그래도 시야를 넓혀주는 것에는 큰 역할을 하기 때문이다.

약 1주~2주동안 빠짝 공부를 했는데 많이 배울 수 있었다.

데이터 표준화의 경우, 이미 실무를 경험했던 터라 빠르게 이해할 수 있었다.

데이터 모델링은 내가 따로 공부를 했었지만 다시 한 번 더 자격증 준비를 하면서 공부를 하니 더 빠르게 이해가 되었다.

나처럼 이 분야로 확장하고 싶고 나름의 시간적 여유가 있으며 일정이 맞다면 한 번쯤 도전해봐도 좋을 자격증이다!

[데이터 아키텍처 준전문가(DAsP)] 과목 4. 데이터 모델링 (4) 물리 데이터 모델링

알밤바 — Tue, 17 Mar 2026 17:13:31 +0900

1. 물리 데이터 모델링 이해

1) 물리 데이터 모델

논리 데이터 모델을 특정 데이터베이스로 설계하여 생성된 데이터를 저장할 수 있는 물리적인 스키마
RDBMS 환경에 맞게 명칭 및 데이터 타입을 논리 데이터 모델링 산출물 기반으로 지정
실제 RDBMS 환경에 최적화된 물리적 테이블명과 컬럼명, 데이터 타입 등을 지정

2) 물리 데이터 모델 의의

논리 데이터 모델링에서 도출된 내용 변환을 포함하여 데이터 저장공간, 데이터의 분산, 저장 방법 등을 함께 고려하는 단계

3) 논리 데이터 모델 → 물리 데이터 모델

논리 모델링	물리 모델링
Entity	Table
Attribute	Column
Primary UID	Primary Key
Secondary(Alternate) UID	Unique Key
Relationship	Foreign Key
Mandatory	Not Null
Optional	Null
Business Constraints	Check Constraints

2. 물리 요소 조사 및 분석

항목	내용
시스템 구축 관련 명명 규칙	사내 시스템 구축과 관련된 명명 규칙 파악하여 적용
하드웨어 자원 파악	• CPU, MEMORY, DISK, I/O Controller, Network • 현재 처리 가능 속도, 집중 부하 발생 시간대, 동시 접속 가능 수
운영체계 및 DBMS 버전 파악	• 운영체제와 관련 요소를 파악하고 관리되고 있는지 파악 • 특히 인스턴스 관리 기법
DBMS 파라미터 정보 파악	• 환경 적용 단계에서 가장 중요하게 고려하는 단계 • 저장공간 관리 기법과 메모리 관리 기법 등에 관한 파라미터 • 쿼리에 사용하는 옵티마이저 운영 방법 등
데이터베이스 운영 관련 관리 요소 파악	• 사용자 관리 기법 및 정책 • 백업/복구 기법 및 정책 • 보완 관리 정책

3. 논리 → 물리 모델 변환

1) 엔터티 → 테이블 변환

✔️ 테이블 설명

용어	설명
테이블 (Table)	기본적으로 컬럼과 로우를 가짐
로우 (Row)	테이블의 한 로우에 대응. 튜플, 인스턴스, 어커런스라고 함
컬럼 (Column)	각 항목의 Value를 저장
기본키 (Primary Key)	하나 혹은 몇 개의 컬럼 조합으로, 어떤 경우라도 테이블 내 동일한 값이 존재하지 않음
외래키 (Foreign Key)	외부 데이터 집합과의 관계를 구현한 구조

✔️ 서브타입 변환

	1) 하나의 테이블로 통합	2) 여러 개의 테이블로 분할
설명	• 서브타입을 슈퍼타입에 통합하여 하나의 테이블로 만듦 • 통합된 테이블에는 모든 서브타입의 데이터를 포함해야 함 • 주로 서브타입에 적은 양의 속성이나 관계를 가진 경우 적용	• 각 서브타입마다 하나의 테이블로 만듦 • 분할된 테이블에는 해당 서브타입의 데이터만 포함되어야 함 • 주로 서브타입에 많은 양의 속성이나 관계를 가진 경우 적용
절차	• 슈퍼타입으로 명칭 부여 • 서브타입을 구분할 수 있도록 컬럼 추가 • 슈퍼타입의 속성을 컬럼명으로 • 서브타입의 속성을 컬럼명으로 • 슈퍼타입의 관계를 FK로 • 서브타입의 관계를 FK로	• 서브타입마다 테이블 명칭 부여 • 서브타입의 속성을 컬럼명으로 • 테이블마다 슈퍼타입의 속성을 컬럼으로 • 서브타입마다 해당되는 관계를 FK로 • 테이블마다 슈퍼타입의 관계를 FK로
예시
테이블 사례
유리한 경우	• 데이터 액세스가 좀 더 간편함 • 뷰를 활용하여 각 서브타입에만 액세스하거나 수정 가능 • 수행 속도가 좋아지는 경우 많음 • 서브타입 구분 없는 임의 집합의 가공이 용이함 • 다수의 서브타입 통합 시 조인 감소 효과가 큼 • 복잡한 처리 하나의 SQL로 통합 용이	• 각 서브타입 속성들의 선택 사항이 명확한 경우 • 처리마다 유형 구분이 불필요 • 전체 테이블 스캔 시 유리 • 단위 테이블의 크기 감소
불리한 경우	• 특정 서브타입의 NOT NULL 제한 불가 • 컬럼 수와 블록 수 증가 • 처리마다 구분(type)이 필요해지는 경우 많음 • 인덱스 크기 증가	• 서브타입 구분 없이 처리할 경우 UNION 발생 • 처리 속도 감소하는 경우 많음 • 트랜젝션 처리 시 여러 테이블을 처리하는 경우가 증가함 • 복잡한 처리의 SQL 통합이 어려움 • 부분 범위 처리가 불가능해질 수 있음 • 여러 테이블을 합친 뷰는 조회만 가능 • UID 유지 관리가 어려움

3) 아크(ARC) 형태로 적용

설명
- 슈퍼타입과 서브타입을 각각 테이블로 변환한 경우
- 슈퍼타입과 서브타입 테이블 간에는 아크(ARC) 관계가 생성
아래 경우를 만족할 때 적용
- 전체 데이터 처리가 빈번하게 발생할 때
- 서브타입 처리가 주로 독립적으로 발생될 때 (서브타입에 릴레이션이 각각 있을 때)
- 테이블로 통합 시 컬럼 수가 너무 많아질 때
- 서브타입의 컬럼 수가 많을 때
- 트랜잭션이 주로 공통 부분(슈퍼타입)에서 발생될 때
- 슈퍼타입 처리 범위가 넓고 빈번하여, 단일 테이블 클러스터링을 해야 할 때
변환 예시
서브타입 변환 Case

서브타입을 테이블로 분리 서브타입을 통한 테이블 생성

2) 속성 → 컬럼 변환

항목	변환 절차	예시
일반 속성 변환	• 엔터티에 있는 속성들을 사례표의 컬럼명란에 기록 • 컬럼의 명칭은 표준화된 약어 사용 • SQL 예약어 사용은 피하되, 가능한 짧은 명칭 • 필수 입력 속성은 Nulls/Unique란에 NN, U을 표시 • 실제 테이블 설계 검증을 위해 가능하면 표본데이터를 넣음
Primary UID → 기본키(PK) 변환	• 키 형태 란에 엔터티의 Primary UID에 속하는 모든 속성에 PK 표시 • PK로 표시된 모든 컬럼은 반드시 NN, U로 표시하고 여러 개의 컬럼으로 UID 구성된 경우 각각 NN, U1을 표시 • 또 다른 Unique Key (Secondary UID)가 있다면 U2로 표시
Primary UID(관계 UID Bar) → 기본키(PK) 변환	• 테이블에 외래키(FK) 컬럼 포함 • PK의 일부분으로 표시 • Nulls/Unique란에 NN, UI 표시 • 키 형태란에 PK, FK 표시 • 여러 UID BAR가 있을 경우 PK, FK1, PK, FK2, … • 여러 컬럼으로 구성된 경우 PK, FK1을 각각 표시 • 추가된 FK 컬럼에 표본데이터 추가
Secondary(Alternate) UID → Unique Key 변환	• 논리 모델에서 정의한 Secondary/Alternate는 해당 집합과 상태 집합과의 선택적인 관계를 가질 수 있게 하는 데 중요한 역할 • 변환 절차는 Primary UID 변환 절차와 동일

✔️ 테이블 정의서 : 개발자들이 많이 참조하는 산출물 중 하나

3) 관계 변환

	1:M 관계 변환	1:1 관계 변환	1:M 순환 관계 변환
설명	• 가장 많은 형태의 관계 • M쪽 관계의 형태에 따라 관계 컬럼의 선택 사양이 결정됨	• 자주 발생하지 않음 • 관계의 Optionality에 따라 다른 방법으로 적용 • 양쪽 모두 Optional인 경우, 더 빈번히 사용되는 테이블이 외래키를 가지지 않는 것이 유리함	• 대부분의 경우, 계층 관계 표현에 사용 • 최상위 관계 속성은 Optional이어야 함
변환 절차	• 1에 있는 PK를 M의 FK로 변환 • FK의 명칭 결정 • 키 형태 란에 FK 표시 • Nulls/Unique란에 NN 표시 (Must Be 관계 시) • 필수 관계가 아닌 경우에는 NN을쳬크하지 않음 • 표본데이터 추가 • UID BAR가 있는 경우 전단계에서 실시	• Mandatory 반대쪽에 있는 테이블의 기본키를 Mandatory 쪽 테이블의 외래키로 변환하며, NN표시를 함	• 해당 테이블 내 외래키 컬럼 추가 • 외래키는 같은 테이블 내 다른 로우의 기본키 컬럼을 참조 • 외래키 컬럼 명칭은 가능한 관계 명칭을 반영 • 외래키는 절대 NN이 될 수 없음
변환 예시
주의사항	[1이 Mandatory 관계일 때] • 자식 쪽 레코드(row)가 반드시 하나 이상이어야 부모 쪽의 레코드 생성 가능 • 자식 쪽 레코드를 삭제할 경우, 반드시 하나 이상의 자식 레코드를 남겨두어야 함. 또는 자식, 부모 레코드를 동시에 삭제해야 함	• 1:1 관계에 의해 생긴 모든 외래키는 Unique Key가 필수적임 • 한쪽이 Optional이고 다른 쪽으 Mandatory라면, Mandatory 쪽의 테이블에 외래키가 생성됨 • 양쪽 다 Mandatory라면, 변환 시 어떤 테이블에 외래키를 생성할 것인지 선택

✔️ 배타적 관계 변환

	설명	예시
외래키 (FK) 분리 방법	- 각 관계를 관계 컬럼으로 생성하는 방법 - 실제 외래키 제약 조건을 생성할 수 있는 장점이 있지만, 각 키 컬럼이 Optional이어야 함
외래키 (FK) 결합 방법	- 각각의 관계를 하나의 관계 컬럼으로 생성하는 방법 - 실제 외래키 제약 조건을 생성할 수 없는 단점 - 각각의 관계를 선택적으로 구분할 수 있는 추가 컬럼 필요 - 구분 컬럼 추가 : 구분 컬럼 Type이 추가되어 배타적 관계의 각 테이블 구분

4) 관리상 필요한 컬럼 추가

관리 상 이유, 프로그래밍 성능을 위해 사용
ex) 생성일시, 생성 프로세스 ID 등

5) 데이터 타입 선택

물리적인 DBMS 특성과 성능을 고려하여 데이터 타입 선택
문자 타입
- 영문만 사용 / 4K or 8K / 고정 길이
- (N)TEXT, (N)CHAR, (N)VARCHAR
숫자 타입
- 불린, 정수, 소수, 화폐
날짜 타입
- datetime, smalldatetime

6) 데이터 표준 적용

항목	내용
개념	• 컬럼명을 생성하고 변환하는 과정에서 미리 생성된 데이터 표준을 따름 • 표준 용어, 도메인, 명명규칙 등
데이터 표준 적용 대상	• 데이터베이스 • 스토리지 그룹 (물리적인 DISK를 묶어서 하나의 그룹으로 정의) • 테이블스페이스 (테이블이 생성되는 물리적인 영역) • 테이블 • 항목 (컬럼) • 인텍스 • 뷰
데이터 표준 적용 방법	[명명 규칙에 의한 표준화 적용] • 논리 → 물리 전환 시, 엔티티 한글명과 동일한 용어를 영문명으로 전환 • 영문명 : 영문 약어 사용, 표준 용어 사전에 등록된 표준 영문 약어 참조 • 테이블 명명 순서 : 업무 영역+주제어 수식어+주제어+분류어 수식어+분류어+접미사 [표준 용어집에 의한 표준화 적용] • 사전에 모든 객체명과 데이터 타입, 길이 등을 정해놓고 사용

4. 반정규화

정규화된 데이터 모델은 시스템의 성능 향상, 개발 과정의 편의성, 운영의 단순화를 위해 정규화의 원칙에 위배되는 행위를 의도적으로 수행
일관성, 무결성 or 성능, 단순화 중 우선순위를 정해야 함

1) 테이블 분할 (파티셔닝)

항목	내용
개념	• 수직/수평 분할 하는 것 • DB 디자인의 파티셔닝과 다른 의미
수평 분할	• 레코드를 기준으로 분할 • 테이블에 데이터가 너무 많고 특정 덩어리의 범위만을 액세스하는 경우 사용 • 분할 후 서로 다른 디스크에 위치시켜 물리적인 디스크 효용성을 극대화 • DBMS 차원에서 제공
수직 분할	[수직 분할이 필요한 경우] • 컬럼의 갯수가 많아질 때 • 조회 위주의 컬럼과 갱신 위주 컬럼이 나뉠 때 • 특별히 자주 조회되는 컬럼이 있을 때 • 특정 컬럼의 크기가 클 때 • 특정 컬럼에 보안을 적용해야 할 때

2) 중복 테이블 생성

집계 함수를 이용하여 자주 조회할 때, 특정 통계 테이블을 두거나 중복 테이블을 추가

✔️ 중복 테이블 생성 판단 근거

정규화에 충실하면 종속성, 활용성은 향상되지만 수행 속도 증가가 발생하는 경우
많은 범위를 자주 처리할 때
특정 범위의 데이터만 자주 처리할 때
처리 범위를 줄이지 않고는 수행 속도를 개선하지 못할 때
요약 자료만 주로 요구되는 경우, 추가된 테이블의 처리를 위한 오버헤드를 고려하여 결정
인덱스의 조정이나 부분 범위 처리로 유도, 클러스터링을 이용하여 해결할 수 있는지 검토 후 사용

✔️ 중복 테이블 유형

	유형/상황	유의사항
집계 테이블 추가	• 단일 테이블의 GROUP BY • 여러 테이블의 조인 GROUP BY	• 로우 수와 활용도를 분석하고 시뮬레이션을 통해 그 효용성에 면밀한 검토가 선행되어야 함 • 집계 테이블에 단일 테이블 클러스터ㅓ링을 한다면, 집계 레벨을 낮춰 활용도를 높일 수 있는지 검토해야 함 • 클러스터링, 결합 인덱스, 고단위 SQL로 해결될 수 있는지 검토해야 함 • 집계 테이블을 다시 집계, 조인하면 추출할 수 있을지 검토하여 지나친 집계 테이블을 만들지 않는 것이 좋음 • 추가된 집계 테이블을 기존 응용 프로그램이 이용할 수 있는지 찾아 보정하는 노력 필요 • DB 트리거의 오버헤드에 주의하고 일관성 보장에 유의해야 함 • 집계 테이블과 원본 테이블 간의 일관성 유지가 중요함
진행 테이블 추가	• 여러 개의 조인이 빈번히 발생하여 처리 범위도 넓은 경우 • M:N 관게가 포함된 처리 과정을 추적, 관리하는 경우 • 검색 조건이 여러 테이블에 걸쳐 다양하게 사용되고 복잡한 처리량이 많을 때	• 데이터 양이 적절하고 활용도가 높아지도록 기본키를 선정 • 필요에 따라 추출 컬럼을 추가하여 집계 테이블 역할도 하는 다목적 테이블을 구상 • 진행 테이블을 만들어야 하는지 확인

3) 중복 컬럼 생성

정규화를 어기면서 중복 수행
중복 컬럼 생성 상황
- 빈번한 조인을 일으키는 컬럼, 속도가 중요한 컬럼, 액세스 조건으로 자주 사용되는 컬럼에 고려
- 자주 사용되는 액세스 조건이 다른 테이블에 분산되어 있어 액세스 범위를 줄이기 힘든 경우, 하나의 테이블로 모아서 조건의 변별성 극대화
- 복사된 컬럼의 도메인은 원본 컬럼과 동일해야 하며, 접근 경로 단축을 위해 부모 테이블 컬럼을 자식에 중복시킬 수 있음
- 상위 레벨의 테이블에 집계된 컬럼 추가 가능 (1:M 관계)
- 하위 레벨의 테이블로 중복 컬럼 복사 가능 (1:M 관계)
- 연산된 결과를 주로 사용할 경우, 미리 연산하여 중복 컬럼 생성 가능
- 여러 컬럼의 조합 또는 복잡한 연산의 결과를 통해 판단할 수 밖에 없을 때, 연산의 결과를 중복 컬럼으로 생성 가능
- 로우로 관리하던 데이터를 컬럼으로 관리하는 경우, 기본키가 길거나 여러 개의 컬럼일 경우, 인위적인 기본키 추가 가능
중복 컬럼 생성 시 유의사항
- 다중 테이블 클러스터링 (단위 클러스터에 2개 이상의 테이블을 함께 저장)으로 해결 가능한지 검토
- SQL GROUP 함수 이용항 처리 가능한지 검토
- 저장 공간의 지나친 낭비를 고려해 대비책 마련
- 반복 컬럼은 특별한 경우를 제외하고는 절대 사용하면 안됨. 만약 특별한 경우가 있다면 sum(decode..) 용법과 같은 기법을 사용해 피해야 함
- 경우에 따라 상대 테이블의 ROWID를 복사하는 경우가 효과적일 때 있음
- 데이터의 일관성 보장에 유의하고 컬럼 중복이 심하면 처리 시 오버헤드 발생
- 사용자나 프로그램은 반드시 원본 컬럼만 수정하는 것이 바람직함
- 수행 속도 때문에 많은 중복 컬럼을 생성하는 것이 현실이나 가능하면 적게 가져가야 함
- 클러스터링, 결합 인덱스, 적절한 SQL로 해결 가능한 것이 많으므로 우선 고려한 후 적용
- 지나친 중복은 데이터 일관성 오류 발생의 개연성 증가 및 데이터 오버헤드 증가라는 반대급부가 있다는 것을 염두하고 수행
- JOIN, SUB-QUERY 액세스 경로의 최적화 방안을 강구해야 함

참고 포스팅

[데이터 모델링] 5. 물리적 데이터 모델링

목차1. 물리적 데이터 모델링2. 데이터 모델링 성능 최적화 방법 데이터 모델링 이전 포스팅 [데이터 모델링] 1. 데이터 모델링이란?[데이터 모델링] 2. 개념적 데이터 모델링[데이터 모델링

ars420.tistory.com

[데이터 아키텍처 준전문가(DAsP)] 과목 4. 데이터 모델링 (3) 논리 데이터 모델링

알밤바 — Tue, 17 Mar 2026 16:32:21 +0900

1. 논리 데이터 모델링 이해

1) 논리 데이터 모델링

항목	상세 내용
논리 데이터 모델링 정의	• 데이터베이스 설계 프로세스 기초 설계 단계 • 비즈니스 정보의 구조와 규칙을 표현할 수 있는 기법 • ERD로 표현된 개념적 구조를 데이터베이스에 저장할 형태로 표현한 논리적 구조 • 물리적인 스키마 설계 전 단계
논리 데이터 모델의 구성요소	• 엔터티 • 관계 (연관도 및 관계 수) • 슈퍼타입 및 서브타입 • 속성 및 도메인 • 주요키, 후보키, 대체키, 외래키 • 업무 규칙
논리 데이터 모델링 이해	• 개념 데이터 모델링에서 정의한 핵심 엔터티와 관계를 바탕으로 속성을 정의하고 식별자를 확정하는 과정 • 정규화를 통해 새로운 엔터티가 생성되거나 새로운 관계 생성 • M:N 관계들이 해소되면서 새로운 행위 엔터티가 생성되는 과정 • 사용자 IP 주소, ViewCount 같은 시스템 관리 관점에서 필요한 데이터 속성까지 모델링에 반영 • 논리 데이터 모델링 단계에서는 실제 사용할 DBMS 시스템 유형을 고려하지 않음
논리 데이터 모델링 목적 및 효과	• 비즈니스에 대한 데이터 관점에서의 이해를 도움 • 전사적인 통합 데이터 체계 확립 • 데이터의 일관성 및 정확성 유지를 위한 규칙 도출 • 안정적인 데이터베이스 설계의 토대 마련 • 사용자와의 명확한 의사소통을 위한 수단으로 활용 가능
논리 데이터 모델링의 성공 요인	• 현업 사용자와 함께 데이터 모델링 진행 • 절차보다는 데이터에 초점을 두고 모델링 진행 • 데이터의 구조와 무결성을 함께 고려 • 개념화, 정규화 기법 채택으로 데이터 무결성 확보 • 다이어그램을 이용하여 업무 표현 • 데이터 모델링을 지원하는 데이터 사전 구축

2) 데이터 정규화

RDBMS에서 데이터의 보존성을 높이고 중복성을 줄여 저장공간의 최소화와 조회 속도 향상하기 위한 테이블을 구성하는 과정
1~5단계의 정규화 과정과 반정규화 과정이 있음
복잡합 자료 구조가 아니라면 제3정규화 과정까지 진행
정규화 과정을 통해 도출된 엔터티의 속성들의 기본 데이터 유형들을 지정
정규화된 설계 이점
- 기억 장소 크기의 최소화
- 데이터 불일치 위험 최소화
- 수정 및 삭제로 인한 이상 가능성 최소화
- 데이터 구조의 안정성 최대화

✔️ 데이터 정규화 단계

단계	내용
1NF (제1정규형)	• 릴레이션에 속한 모든 도메인이 원자값만으로 되어 있는 릴레이션 • 릴레이션의 모든 속성이 단순 영역에서 정의
2NF (제2정규형)	• 릴레이션이 1NF • 키가 아닌 모든 속성이 기본키에 대해 함수적 종속 관계를 만족
3NF (제3정규형)	• 릴레이션이 2NF • 키가 아닌 모든 속성이 키본키에 대해 이행적 종속 관계를 이루지 않도록 제한
BCNF (Boyce-Codd 정규형)	• 릴레이션에서 결정자가 모두 후보키인 릴레이션
4NF (제4정규형)	• 릴레이션이 2NF • 키가 아닌 모든 속성이 키본키에 대해 이행적 종속 관계를 이루지 않도록 제한
5NF (제5정규형)	• 릴레이션이 모든 조인 종속성의 만족이 릴레이션의 후보키를 통해서만 만족

✔️ 데이터 정규화 유형

항목	내용
제1정규화	• 속성 원자값 원칙, 중복성 제거 원칙, PK 설정 원칙 준수 • 모든 엔터티는 Unique Key이자, PK가 존재해야 함 • 모든 속성 값은 원자성, 즉 단일값 형태로 데이터 형태가 표현되어야 하며 중복되면 안 됨 • 값이 중복되는 2개 이상의 속성은 별도 엔터티로 분리
제2정규화	• 부분적 함수의 종속성 제거 원칙 준수 • 기본키가 2개 이상으로 구성된 엔터티에서 일반 속성이 PK속성 중 일부 속성에 대해서만 부분적 종속성이 있는 속성일 경우 제거 • 2차 정규화의 결과로 속성이 삭제될 수 있음
제3정규화	• 이행적 함수의 종속성 제거 원칙 준수 • 엔터티 내 모든 속성들은 기본키에 의존성을 가져야 함 • 기본키에 의존하지 않고 일반 속성에 의존하는 속성을 제거 및 분리

제1정규화	제2정규화	제3정규화

2. 속성 정의

1) 속성

항목	상세 내용
속성 정의	• 더 이상 분리될 수 없는 최소 데이터 보관 단위 • 릴레이션의 열 • 파일 관리 시스템 관점 : 필드(field)에 대응 • 엔터티에서 관리되는 구체적인 정보 항목 • 엔터티와 같이 업무 내용, 다양한 문서를 통해 도출됨 • 먼저 후보들을 도출하고 속성이 될 수 있는 조건에 부합하는지 확인하여 최종적으로 속성 정의
속성 특징	• 일종의 집합 • 릴레이션도 속성 (물리 데이터 모델링 단계에서 보면 관계 또한 속성) • 속성 간 서로 독립적 (제2정규형 : 속성은 반드시 식별자에 직접 종속되어야 함) • 업무에 필요한 정보 • 1개의 속성값만 가지며, 다중값일 경우 별도 엔터티를 이용하여 분리
엔터티, 인스턴스, 속성, 속성값의 관계	• 1개의 엔터티는 2개 이상의 인스턴스 집합 • 1개의 엔터티는 2개 이상의 속성을 가짐 (식별자 외 1개 이상 필요) • 1개의 속성은 1개의 속성값을 가짐
업무 규칙	속성이 가질 수 있는 값을 통제하여 논리적 데이터 모델의 무결성을 유지하기 위한 명세 • 키 업무 규칙 : 엔터티의 주키와 외래키의 값을 정확하게 유지하기 위한 업무 규칙 → 주엔터티의 삭제 규칙과 종엔터티의 입력 규칙 정의 • 속성 업무 규칙 : 엔터티 속성이 갖는 값의 타입, 범위, 특성 등 정의 • 연쇄반응 : 입력, 수정, 삭제, 조회 작업의 정당성과 이 작업이 다른 엔터티 또는 동일 엔터티의 속성값에 미치는 영향 규정

✔️ 속성 분류

구분	명칭	설명
특성	기본속성	• 업무로부터 추출한 값 • ex. 이름, 성별, 이메일주소
	설계속성	• 규칙화를 위해 변형/새로 정의한 값 • ex. 과목코드, 지역코드
	파생 속성	• 다른 속성에 영향을 받아 발생한 값 • ex. 예금이자, 평균성적
엔터티 구성 방식	PK (Primary Key)	엔터티를 식별할 수 있는 속성
	FK (Foreign Key)	다른 엔터티와의 관계에서 포함된 속성
	일반속성	PK, FK에 포함되지 않은 속성
	단순형	원자값 속성
	복합형	세부 속성으로 나뉠 수 있는 속성

2) 속성 후보 도출

항목	상세 내용
속성 후보 수집처	• 구 시스템 문서 자료 • 현업 장표/보고서 • 사용자와 협의 • DFD (데이터 흐름도)의 DD (Data Dictionary) • 전문서적 및 자료 • 다른 시스템 자료
속성 후보 선정 원칙	• 원시(Source) 속성으로 보이는 후보는 버리지 않음 • 소그룹별로 후보 군을 만들고 가장 근접한 엔터티에 할당
속성의 기본 구성 요소	• 속성명 : 함축성 있는 명사(구), 업무에서 일반적으로 사용하는 용어 • 도메인 : 업무적인 제약 조건으로 파악된 특성 (데이터 타입, 길이, 허용값, 디폴트값, 알고리즘) • 선택성 : 반드시 값을 가져야 하는지 여부 (필수조건/금지조건/무관계조건)

3) 속성 검증 및 확정

항목	검증 방법	대표 유형
최소 단위 분할	• 집합 개념의 속성은 단순 개념으로 분할 • 가능한 최소 단위까지 분할한 후 관리 필요에 따라 통합 • 분할 및 통합 기준은 업무의 요구사항에 따름 • 일자, 시간, 성명, 주민등록번호, 우편번호 등은 일반적으로 분할하지 않는 것이 좋음	• 일자 형태의 속성 : 매출일자 • 외부에서 공인된 속성 : 우편번호 유형 • 전화번호 유형 : 전화, 팩스 번호 • 주소 유형 : 고객 주소 → 지역주소+상세주소
하나의 값만을 가지는지 검증 필요	• 여러 값을 가지거나 반복되는 속성은 잘못된 속성 • 반복되는 속성은 새로운 엔터티로 분할해야 할 1차 정규화 대상	• 계약일 : 고객 엔터티 속성 (x) 가입 계약 속성 (o) → 고객은 여러 개의 계약일을 가질 수 있기 때문 • 차량번호 : 유일 값
추출 속성에 따른 검증		• 현재 정보만 관리 : 현주소, 고객 등급 • 최초 정보만 보관 : 최초가입일, 모집사원 • 집계 정보만 관리 : 인원수, 가족수 • 추출 릴레이션만 관리 : 가입 계약번호, 관리 사원 • 대표 정보만 관리 : 대표 이메일ID, 법인 대표자 정보 • 다른 속성의 일부 정보만 분리 : 성별, 결혼 여부 • 일부분만 추출 값 : 인원수, 법인 대표자 정보

4) 가공 속성 규칙

모델 내 반드시 기술 권장
도출 속성 : 하나 이상의 속성 값을 누적함으로써 선택적으로 주제를 도출하는 속성에 대해 값을 창출하기 위해 추가 계산 작업을 수행함으로서 도출되는 속성
- 경영층이 원하고 필요로 하는 정보를 대표함
- 사용자들의 데이터 요구 사항을 나타냄
- 향후 과정에서 PK로서의 역할을 맡아서는 안 됨
- 데이터 모델에 도출 속성을 포함시키는 것은 물리적 구현에 대한 것을 내포하지 않음
계산 속성 : 엔터티의 단일 사례에 대한 특성을 기술하며, 일반적으로 관련 속성의 또 다른 단일 사례로부터 계산

5) 속성 정의 시 유의사항

사항	상세 내용
명확한 속성 명칭 사용	• 직업 : 상위 분류 단위인지, 세부 분류 단위인지 정의 • 학점 : A/B인지, 2학점/3학점인지 정의
유일한 복합명사 사용	• 순번 : 인조식별자로 사용 • 상태 : 애매모호함 • 보험기간 : 12개월, 1년으로 표현되는지 • 최초납입영수일자 : 잘 표현됨
단수형 사용
표준 단어 제정	모델링 전 표준 단어를 제정하면 기준을 준수하기가 용이하고 일관성 생김
자의적인 전용 금지	속성의 의미를 추상적으로 정의했을 때, 개발 막바지에 속성 추가가 필요할 때, ERP 패키지의 경우 미리 전용의 용도로 속성을 정의해두는 경우 발생

6) 속성 업무 규칙 정의

도메인 정의	내용
속성	• 자료 형태 : Integer, Decimal, Character • 길이 : 5 Digits, 35 Characters • 포맷 : nnn-nn-nnnn (ex. 전화번호) • 값의 허용 범위 : 0 < x < 50 • 의미 : 구매 주문서의 주문 가격 • 유일성 : Unique, Nonunique • Null 값 허용 여부 • Default 값
주키 (기본키)	• 유일한 값 • 합성 주키를 이루는 속성은 Not Unique 가능 • 주키와 주키를 이루는 속성은 반드시 Not Null • 주키와 주키를 이루는 속성은 유일성이 지켜지는 한 Default 값 가능 • 서브타입 주키의 도메인은 관련 슈퍼타입 주키 도메인의 부분집합으로 정의
대체키	• 유일한 값 • 합성 대체키를 이루는 속성은 Not Unique 가능 • 대체키와 합성 대체키를 이루는 속성은 Null값 가능
외래키	• 외래키 속성의 자료 형태, 길이, 포맷은 해당 주 엔티티의 주키 속성의 도메인과 동일

3. 엔터티 상세화

1) 식별자 확정

✔️엔터티 구체화 4단계

단계	상세 내용
식별자 확정 단계	논리적 의미의 식별자 → 실질적 식별자 생성
정규화 단계	논리적 데이터 모델의 일관성을 유지하고 중복을 제거하여 안정적인 모델을 만드는 단계
M:N 관계 해소 단계	핵심 엔티티 간의 M:N 단계가 해소되면서 교차 엔터티가 생성되는 단계
참조 무결성 정의 단계

✔️ 식별자 확정 단계

항목	상세 내용
본질 식별자	• 키 엔터티는 부모가 없이 창조된 집합으로 식별자를 만들어야 함 • 행위 엔터티는 항상 부모가 누구인지 확인하는 방식으로 진행 • 키 엔터티의 본질 식별자 : (사원 엔터티) 주민등록번호 / 인조 식별자 : 사원번호 • 절대 종속 : 부모 엔터티가 반드시 있어야만 존재하는 것 • 상대 종속 : 엔터티의 탄생에 아무런 영향을 미치지 않음 • 직접 종속 : 부모 엔터티와의 관계가 1촌 • 간접 종속 : 부모 엔터티와의 관계가 1촌이 아닌 경우 • 행위 엔터티의 본질 식별자 : 절대 종속 & 직접 종속 • 절대 종속 관계, 상대 종속 관계 모두 1:M 직접 관계이면 상위 엔터티의 식별자가 하위 엔터티에 상속됨
후보 식별자 도출	• 각 인스턴스를 유일하게 식별할 수 있어야 함 • 나머지 속성을 직접 식별할 수 있어야 하며, NULL이 될 수 없음 • 후보 식별자로 속성 집합을 선택하는 경우, 개념적으로 유일해야 함 • 후보 식별자의 데이터는 자주 변경되지 않는 것이어야 함
대체(보조) 식별자	• 식별자를 대신할 수 있는 속성 또는 관계 • ex) 사원번호, 주민번호 등
인조 식별자 지정	• 최대한 범용적인 값 사용 (ex. 사원번호, 상품코드 등) • 유일한 값을 만들기 위한 인조 식별자 사용 • 하나의 인조 식별자 속성으로 대체할 수 없는 형태 주의 • 편의성/단순성 확보를 위한 인조 식별자 사용 (속성명이 너무 길 때) • 의미의 체계화를 위한 인조 식별자를 사용할 수 있음 (코드화) • 내부적으로만 사용하는 인조 식별자 (시스템 필요성에 의해)
식별자 확정	[UID BAR 의미] • 식별자로서의 역할 : 구별될 수 있도록 유일한 값을 만드는 데 도움 • 정보로서의 역할 : 참조하는 엔터티의 입장에서 상속 받았기 때문에 자신의 정보도 증가함 [UID 상속과 단절 원리] • 실질적인 처리 단순화를 가져다 줄 수 있음 [식별자 확정 절차] 1) 키 엔터티 식별자 확정 : 최상위 엔터티, 서로 독립적으로 식별자를 확정할 수 있음 2) 메인 엔터티 식별자 확정 : 하위 엔터티 상황을 고려하여 결정, 식별자 속성을 적게 함 3) 하위 엔터티 식별자 확정 : 인조 속성을 적게 사용, 유일성에는 좋지만 정보로서 가치 없음

2) 정규화

항목	상세 내용
정규화의 의미	• 변경 이상이 발생하면 데이터의 일관성과 무결성을 해칠 수 있음 • 입력 이상 : 별도의 사실이 발생하기 전까지 데이터를 삽입할 수 없음 • 삭제 이상 : 일부 정보를 삭제함으로써 유지되어야 할 정보까지 삭제될 수 있음 • 갱신 이상 : 일부 갱신함으로써 정보의 이상현상 (무결성 파괴, 정보의 모순성)이 발생할 수 있음
정규화의 장점	• 중복 값이 줄어듦 • NULL 값이 줄어듦 • 복잡한 코드로 데이터 모델을 보완할 필요 없음 • 새로운 요구 사항의 발견 과정을 도움 • 업무 규칙의 정밀한 포착 보증 • 데이터 구조의 안정성 최대화

✔️ 정규화 단계

항목	정의	정규화 작업
1차 정규형 (1NF)	• 모든 속성은 반드시 하나의 값을 가져야 함 (중복 x) • 각 속성의 모든 값은 동일한 형식이어야 함 • 각 속성은 유일한 이름을 가져야 함 • 레코드 간 식별이 가능해야 함	• 의미상의 주어(본질 식별자)를 알아야 식별자 부분 종속인지 구분할 수 있음 • 속성의 의미가 명확해야 종속성을 비교할 수 있음 • 속성 식별자 전체에 종속되어 있지 않으면 잘못된 위치이며, 새로운 엔터티 (부모 엔터티)를 생성하고 UID BAR를 상속받게 됨 • 1차 정규화를 수행하면 보통 자식 엔터티가 생김
2차 정규형 (2NF)	• 식별자가 아닌 모든 속성은 식별자 전체 속성에 완전 종속되어야 함	• 키가 복합 속성일 때, 일부 속성이 일부 키에 종속이 발생하는 것 • 2차 정규화를 수행하면 보통 부모 엔터티가 생김
3차 정규형 (3NF)	• 2차 정규형을 만족하고, 식별자를 제외한 나머지 속성들 간의 종속이 존재하면 안됨	• 평가코드, 평가 내역 속성이 서로 간 종속적임
BCNF 정규형	• BCNF : Boyce-Codd Normal Form • 모든 결정자가 키인 릴레이션 • 결정자 하나라도 키가 아니면 안됨 • 2, 3차 정규형을 보완하려는 목적 • 부분 종속이나 이행종속이 없는 3차 정규형도 변경이상 현상이 발견할 수 있음 (이는 Non-Key 속성이 결정자로 동작하기 때문)	[3차 정규화 문제점] • 한 릴레이션에 여러 개의 후보키가 있음 • 후보키가 적어도 둘 이상의 속성으로 이루어진 복합키 • 모든 후보키가 적어도 하나 이상의 공통 속성이 포함되는 경우 [3차 정규형을 만족하고 BCNF가 아닌 경우] • 각 속성이 하나의 값으로 구성된 경우 (1NF) • Non-Key 속성인 D는 후보키 A+B, B+C에 완전 함수 종속 (2NF) • Non-Key 속성이 D 하나뿐이므로 Non-Key 간 종속 관계 없음 (3NF)

1차 정규형	2차 정규형	3차 정규형

3) M:N 관계 해소

최종적인 단계에서 존재할 수 없음
M:N 관계 해소 의의
- 새로운 릴레이션 엔터티를 추가하여 1:M 관계로 변경
- 연관 실체 엔터티는 M:N 관계 미결 시 간과한 추가 업무 규칙, 논리 내포 가능
- M:N 관계는 데이터 종속성에 대한 결정을 어렵게 하며, 논리적 완성과 부분 집합 식별 능력 제한

4) 참조 무결성 규칙 정의

관계 테이블의 모든 외부 식별자 값은 관련 있는 관계 테이블의 주 식별자 값이 존재해야 함
PK와 마찬가지로 FK도 데이터 무결성에 대한 업무 규칙 내포
DB 설계 관점에서 선택하지 말고, 사용자 업무 규칙에 따라 적절한 규칙 선택

입력 규칙
Dependent	대응되는 부모 실체에 인스턴스가 있을 경우에만 자식 실체에 입력을 허용
Automatic	자식 실체 인스턴스의 입력을 항상 허용하고 대응 부모 건이 없을 경우 이를 자동 생성
Nullify	자식 실체는 항상 허용하고 대응되는 부모 건이 없는 경우 자식 실체의 참조키를 Null값으로 처리
Default	자식 실체 인스턴스의 입력을 항상 허용하고 대응 부모 건이 없을 경우 FK를 지정된 기본값으로 처리
Customized	특정한 검증 조건이 만족될 때에만 자식 실체 인스턴스의 입력을 허용
No Effect	조건 없이 자식 실체 인스턴스의 입력 허용
삭제 규칙
Restrict	대응되는 자식 실체의 인스턴스가 없을 경우에만 부모 실체 삭제 허용
Cascade	부모 실체 인스턴스의 삭제를 항상 허용하고, 대응되는 자식 실체의 인스턴스를 자동 삭제
Nullify	부모 실체 인스턴스의 삭제를 항상 허용하고, 대응되는 자식 실체의 인스턴스가 존재하면 그것의 FK를 Null값으로 수정
Default	부모 실체 인스턴스의 삭제를 항상 허용하고, 대응되는 자식 실체의 인스턴스가 존재하면 그것의 FK를 기본 값으로 수정
Customized	특정한 검증 조건이 만족될 때에만 부모 실체 인스턴스의 삭제를 허용
No Effect	조건 없이 부모 실체 인스턴스의 삭제 허용

4. 이력 관리 정의

1) 이력 관리 정의

모든 데이터를 대상으로 하지 않음
꼭 필요한 데이터에 한정하여 이력 관리 수행
시점 이력과 선분 이력 중 적합한 형태를 결정하는 것이 중요

2) 이력 관리 대상 선정

사용자 조사
- 변경 내역을 감시할 필요가 있는가?
- 시간의 경과에 따라 데이터 또는 관계가 변할 수 있는가?
- 과거의 데이터를 조회할 필요가 있는가?
- 과거 버전을 보관할 필요가 있는가?

이력 데이터의 종류

유형	상세 내용
발생 이력 데이터	• 발생할 때마다 이력 정보 남김 • 이벤트 발생 시 / 날마다 남기는 것이 있음
변경 이력 데이터	• 변경될 때마다 전/후 차이를 확인해야 할 경우
진행 이력 데이터	• 진행에 따라 남기는 것 (ex) 주문

이력 관리 형태

유형	상세 내용
시점 이력	• 변경이 발생한 시각만 관리 • 특정한 시점의 데이터 추출할 경우, 불필요한 작업 수행
선분 이력	• 변경 시작부터 종료 시점까지 관리 • 하나의 지점은 =로 찾을 수 없으니 통과하는 선분을 찾을 수 있음 • 선분이 아무리 길어도 레코드는 하나임

선분 이력 관리 유형

유형	상세 내용
인스턴스 레벨 이력 관리	• 하나의 인스턴스에 변경이 발생하면 전체 행(인스턴스)을 새롭게 생성 • 한 번의 액세스로 해당 시점의 모든 데이터 참조 가능 • 로그성 데이터가 목적일 때 좋음 • 다른 이력 관리 유형에 비해 저장은 쉽지만, 저장 공간의 낭비 발생 • 하나 이상의 컬럼에 변경이 있을 경우, 이벤트가 모호해짐 (이벤트가 자식 정보를 갖게 된다면 해당 이벤트를 찾기 어려움) • 실제 변경 데이터를 찾기 위해서 과거의 데이터와 비교해야 함 • 특정 순간의 스냅샷만 보는게 아니라면 처리가 복잡해지는 경향이 있음 • 변화가 빈번하게 발생하는 상황에서 고려해볼 수 있는 유형
속성 레벨 이력 관리	• 대상 속성에 변화가 생길 때만 이력을 생성하는 방식 • 실제 어떤 데이터가 변경되었는지가 분명함 • 하나의 이력 관리 엔터티에서 다른 엔터티와 통합 이력 관리가 가능함 • 독립적 처리 가능 • 변화가 자주 발생하지 않고 이력 관리 대상이 많은 경우 사용 • 특정 속성들에 변화가 집중되는 경우 유용함 • 여러 속성에 대한 이력 필요 시, 많은 Merge가 발생함 • 다른 유형에 비해 액세스 쿼리에서 조건 검색이 어려움
주제 레벨 이력 관리	• 유사하거나 연동될 확률이 높은 것별로 레벨 이력 관리 • 인스턴스, 속성 레벨의 장점을 합친 형태 • 목적이 분명한 엔터티를 생성함으로써 확장성을 확보할 수 있는 용도로 사용할 수 있음 • 변경 부분만 처리 가능 (독립적) • 다른 엔터티와 통합 이력 관리 가능 • 속성 레벨의 단점 해소 가능 • 전체를 참조할 때 인스턴스 레벨에 비해 Merge가 발생하는 문제가 있음 • 부분에 따라 변경 정도의 차이가 심한 경우 유리함

3) 선분 이력 관리용 식별자 확정

항목	상세 내용
선분 이력에서 식별자 결정 시 고려사항	• 성능 문제 고려 • 실제 데이터는 Unique 하지만 의미적으로 Unique 하지 않는 일이 발생 • Unique 여부를 검증할 수 있는 조치를 병행해야 함
선분 이력에서 종료점 처리 시 주의사항	• 종료점이 미정이므로 NULL • 논리적으로 타당하지만 비교가 불가능하여 인덱스를 사용하지 못하므로 수행 속도가 저하됨 • 수렴하므로 최대치 부여 • 아직 종료되지 않았으므로 무한히 계속되는 것으로 간주 • 최대치를 부여하고 가능한 테이블 생성 시 Default constraint를 부여하며 수행 속도에 유리

✔️ 선분 이력을 하기 좋은 항목

매일, 매주 등 불규칙하게 바뀌는 상품 가격

참고 포스팅

[데이터 모델링] 3. 논리적 데이터 모델링

목차1. 논리적 데이터 모델링2. 논리적 데이터 모델링 예시 데이터 모델링은 총 4가지 단계로 구성되어 있다. 개념적 데이터 모델링 단계를 거쳐 엔티티와 관계를 정의하여 ERD를 만들어냈으면,이

ars420.tistory.com

[데이터 모델링] 4. 데이터 정규화 (Normalization)

목차1. 데이터 정규화 (Normalization)란?2. 데이터 정규화 종류 데이터 모델링 이전 포스팅 [데이터 모델링] 1. 데이터 모델링이란?[데이터 모델링] 2. 개념적 데이터 모델링[데이터 모델링] 3.

ars420.tistory.com

[데이터 아키텍처 준전문가(DAsP)] 과목 4. 데이터 모델링 (2) 개념 데이터 모델링

알밤바 — Tue, 17 Mar 2026 12:09:38 +0900

1. 주제 영역 정의

1) 주제 영역 분류 원칙 및 기준

항목	상세 내용
주제 영역 분류 원칙	• 데이터 중복 최소화 • 데이터 확장성 보장 • 데이터 관련성 및 편의성 확보
주제 영역 명명	• 업무에서 사용되는 업무 영역 부여 • 유일한 단수형 명사 사용 • 데이터 그룹 의미 이름 부여
주제 영역 정의 절차	데이터 현황 분석/DA 원칙 및 방향성 분석/선진 모델 분석 → 데이터 분류 지침 정의 → 주제 영역 분류 및 정의 → 주제 영역 도식화
주제 영역 분류 방법	• 1차 분류 : 기존 시스템별 데이터 성격 및 특성을 고려하여 주요 데이터 집합 유형 정의 • ex) 데이터 발생 주체, 데이터 발생 주체 간의 상호작용으로 발생하는 대상, 공통/관리 성격의 상위 개념으로서 분류 • 2차 분류 : 비즈니스 활동에 필요한 분석 주제와 현황 등의 영역으로 분류 (1차 분류를 세분화) • ex) 관계자 기본, 관계자 상세 등 • 3차 분류 : 2차 분류 세분화 • ex) 관계자 : 고객, 법인, 조직, 직원 등 / 계약 : 수신계약, 예금계약, 신탁계약 등 • ⇒ 업무 활동을 의미하는 이름 배제 / 데이터 그룹을 의미하는 이름 사용

2) 주제 영역 활용

주제 영역은 데이터의 계층 구조 파악, 품질 확보에 기여
효율적 데이터 관리를 위한 기준 제공
데이터 구성 및 통합에 대한 방향 제시
기업의 전체 데이터 구성에 대한 청사진 제공

3) 주제 영역 정의 내용 도출

업무에서 사용하는 데이터의 명사형 도출
업무 기능의 이름으로부터 도출
하향식 (Top-dowm) 접근 방법 : 주제 영역에서 출발하여 엔터티 타입으로 전개
상향식 (Bottom-up) 접근 방법 : 엔터티 타입을 그룹화하여 주제 영역 도출
분석 단계에서의 도출 : 아키텍처 모델 정련 과정 / 데이터 모델 상세화에서 도출

2. 후보 엔터티 선정 ✅️

항목	상세 내용
엔터티 후보 수집	• 기존 시스템 도규먼트 • 현업 장표/보고서 : 자료에 기술된 항목을 속성이라고 가정하여, 본질적인 집합(원재로) 도출 • 데이터 흐름도 (DFD) : 데이터 저장소, 데이터 사전 등 • 현업 인터뷰 • 관련 전문 서적 • 타 시스템 자료 • 현장 조사 • 자료 흐름도 (애플리케이션 개발 표준 정의서 x)
엔터티 후보 식별	• 엔터티 후보 개념 정립 : 단어가 의미하는 집합 정의 (사원 : 근무자 or 사단법인, 관계사, 협력사) • 관리 대상 판정 • 집합 여부 확인 : *가로(속성) 세로(개체)** = 면적 = 집합
엔터티 후보 선정 시 유의사항	• 엔터티 가능성이 있을 경우, 검토 대상에 올림 (후보 자격의 여부만 따지기) • 동의어처럼 보이더라도 함부로 버리지 않음 (모델링 뒷부분에서 동의어로 보이는 후보를 집합의 정의에 따라 통합) • 개념이 모호한 대상은 1차로 개념을 상식화하여 이해 • 프로세스/예외 경우에 너무 연연하지 말기 • 단어 하나하나에 집중해서 판단

✔️ 엔터티 분류

항목	상세 내용
키 엔터티	• 자신의 부모를 가지지 않는 엔터티 • 모델 내 주어 역할 • 하위 엔터티의 탄생 유도 • 시스템의 기본 정보 • ex) 사원, 부서, 고객, 상품, 자재 등
메인 엔터티	• 업무의 중심에 해당하는 엔터티 • 키 엔터티의 관계에 의해 만들어짐 (고객과 상품 관계에서 주문이 만들어짐) • ex) 보험계약 사고, 구매의뢰, 주문, 매출 등
액션 엔터티	• 키/메인 엔터티 제외한 나머지 엔터티 • 부모 없이 존재할 수 없음 • 상위 엔터티들의 영향을 크게 받기에 모델링 후반에 크게 변경될 수 있음 • ex) 상태 이력, 차량 수리 내역 등

3. 핵심 엔터티 정의

1) 엔터티 정의 요건

항목	상세 내용
엔터티 정의	• 관리하고자 하는 것인지 확인 • 가로, 세로를 가진 면적인지 확인 • 대상 개체 간의 동질성 있는지 확인 • 다른 개체와 구분되는 독립성을 가지는지 확인 • 순수한 개체 or 행위 집합인지 확인
엔터티 정의 시 고려사항	• 특정 업무를 수행하는 과정에서 파생되는 엔터티는 데이터로서 안정성 고려 • 의미있고 직관적으로 이해 가능한 간단명료한 이름 부여 • 현업 사용자와 공동 작업을 통한 반복적인 검토 및 수정 필요
엔터티 결정 기준 단계 ✅️	1) 향후 관리 여부 확인 (필요한 데이터인지 확인) 2) 관리 대상 판정 (실제 업무에서 관리해야 하는 대상인지 확인) 3) 집합 여부 확인 (엔터티가 될 수 있는 집합 형태인지 확인)
엔터티 파악 요령	• 업무 기술서 활용 • 현업 담당자와의 인터뷰 활용 • 기준 시스템 산출물 검토 • DFD를 통해 업무 분석을 진행했다면, DFD의 Data Store 활용 • 현업 업무를 직접 견학 → 인터뷰와 업무 기술서에서 누락된 정보있는지 검토 • 현재 업무에 나타나지 않았지만 BPR (Business Processing Reengineering)에 의해 업무를 재정의한 경우, 관련 엔터티 찾아야 함
엔터티 특징	• 업무에 필요한 정보 • 의미 있는 식별자에 의해 인스턴스는 1개씩만 존재 (중복 배제) • 2개 이상의 인스턴스 집합으로 구성 • 업무 프로세스에 의해 이용 • 속성 포함해야 함 (식별자만 있으면 x) • 관계 존재해야 함 • 엔터티는 집합이어야 하지만 모든 집합이 모두 엔터티가 되는 것은 아님
엔터티 도출 산출물	• 현행 업무 분장표 • 현행 업무 흐름도 • 현행 시스템 분석서 • 현행 요구사항 정의서

✔️ 엔터티 분류

항목	명칭	설명
유무형	유형 엔터티	물리적 형태가 있음 (ex. 사원, 물품, 강사)
	개념 엔터티	물리적 형태가 없음 (ex. 조직, 보험 상품)
	사건 엔터티	업무 수행에 따라 발생 (ex. 주문, 청구, 미납)
발생 시점	기본 엔터티	원래 존재하는 정보 (ex. 사원, 부서, 고객, 상품)
	중심 엔터티	• 기본 엔터티로부터 발생, 다른 엔터티와의 관계를 통해 많은 행위 엔터티 발생 • 업무에 있어 중심 역할 • ex. 계약, 사고, 청구, 주문
	행위 엔터티	• 2개 이상의 부모 엔터티로부터 발생 • 내용이 자주 변경 및 데이터 양 증가 • ex. 주문 목록, 로그인 이력

✔️ 엔터티 정의서 예시

엔터티명	엔터티 설명	동의어/유의어	관련 속성
도서	인터넷을 통해 판매하고자 하는 책의 정보	책	• 도서 번호 • 도서명
회원	인터넷을 통해 등록한 회원의 정보	일반 회원	• 주민번호 • 주소 • 전화번호 • 이메일
주문	도서를 구매하기 위해 회원이 입력한 배송지, 결제 방법에 대한 정보	주문서, 주문내역	• 주문번호 • 주문일자 • 배송지 주소 • 배송방법 • 결제방법
주문목록	회원이 주문한 도서 목록에 대한 수량 및 가격	구매 도서 목록	• 수량 • 단가

2) 의미상 주어 정의 (본질 식별자)

가주어 : 인조 식별자 / 진주어 : 엔터티의 의미상 주어 (본질 식별자)
본질 식별자 : 집합의 인스턴스가 생성되는 단위
집합의 의미가 명확하게 정의되지 않은 모호한 집합에 인위적인 유일한 이름을 붙인다고 해서 집합의 정의가 명확해지지 않음

3) 코드성 키 엔터티 모델링

코드성 키 엔터티를 개념 모델링 단계에서 모두 도출하면, 추후 복잡해질 수 있기 때문에 아래의 기준에 맞게 도출하는 것이 좋음
- 자식 엔터티를 가지는지?
- 자신만의 다양한 속성을 가지는지?
- 여러 엔터티에 관계를 맺을 것인지?
- 다양한 종류의 관계를 맺을 것인지?
다른 엔터티의 본질 식별자가 되고 있는지 판단
- 해당 엔터티로 인해 다른 엔터티의 존재 종속의 문제가 발생하면 반드시 도출해야 함
단순한 코드명, 코드 의미에 대한 설명 외에 또 다른 속성을 가지는지 확인
- 독립적인 개체 집합으로서 의의가 있음
관계 존재 여부 확인
- 다양한 관계를 많이 맺고 있는 엔터티를 누락시키면 앞으로 정의할 관계도 같이 누락될 가능성이 이 있음

4) 집합 순수성

순수한 본질 집합
사람, 상품 등과 같이 단위 사물을 정의한 개체 집합
입금, 계약 등과 같은은 행위 집합
서로 결합된 형태 → 관계
ex) 납입자 : 순수 본질 집합인 ‘고객’과 ‘납입’이 결합된 관계임

✔️ 집합 순수성 적용 예외 사항

항목	상세 내용
관계의 엔터티화	관계가 M:N이 되면 관계로 존재할 수 없기에 엔터티로 바꾸게 됨 → 이를 릴레이션 엔터티, 제휴 엔터티, 교차 엔터티 등으로 부름
일부 집합 정의	전체 집합 중 일부 집합만 엔터티로 정의할 때 ex) 금융기관 : 기관의 부분으로서 엔터티, 수납기관 : 관계
배타적 관계 대체	여러 엔터티와 동일한 내용의 관계를 갖는 배타적 관계를 맺을 때, 배타적 관계의 변화 가능성이 높다면 별도의 엔터티 구성

5) 집합 동질성

집합에 들어갈 개체들의 동일한 성질을 어디까지로 한정할 것인가를 결정
ex) 사람의 집합이라고 규정
- 사람만의 집합, 상품과 구체적인 관계를 맺은 사람만 존재하는 집합으로 정의했다는 특수성이 나타나야 함
ex) 사람 또는 법인이라고 규정
- 위의 집합들을 분명하게 포함시켰다는 것을 내포

6) 엔터티 명칭

함축적인 의미를 담고 있어 설명하지 않아도 오해를 최소화할 수 있어야 함
엔터티 명칭 정할 때, 실무자와 해당 분야 전문가의 의견을 종합하고 이를 구성원 간에 합의하는 것 필요

7) 서브타입

항목	상세 내용
서브타입 지정 의의	• 구체적인 부분 집합의 종류 (서브타입) 명시 • ERD를 입체적, 구체적으로 작성하기 위해 집합의 부분집합을 표현해야 함 • 실세계에서 동일한 것 • 추가 속성 • 서브타입에서 상호배타적인 다수의 카테고리가 형성될 수 있음 • ex) 서브타입 (의사, 간호사, 기술직, 사무직)은 수퍼타입(직원)의 부분집합
서브타입 지정 시 고려사항	• 교집합 허용 불가 • 서브타입의 합이 전체 집합 • 서브타입 표현 기준 : 개별 속성/개별 관계를 가질 때, 가독성 증진시킬 때
서브타입 도출	• 분류 속성 : 엔터티의 정보가 차별화되는 경우 • 다수의 선택적 속성 • 선택적 관계가 존재하는 경우 : 분할함으로써 관계가 필수적으로 변하는지 확인 [도출 절차] 1) 분류 속성 확인 (엔터티 발생이 차별화되는 경우) 2) 분류 속성값에 의해 분류되는 서브타입 파악 3) 분류 속성에 따라 필수적/선택적 분할 정의 4) 서브타입별 속성 할당 5) 슈퍼타입의 관계를 해당 서브타입에 정의
서브타입 활용	• 데이터 모델에 업무 규칙을 명확히 표현하여 업무를 정확히 이해하고, 속성 및 관계의 선택성을 제거 • 서브타입의 표현은 업무 규칙의 명확성과 표현의 복합성이라는 트레이드 오프 관계가 적절히 조화를 이루어야 함
서브타입 이해	• 인스턴스들의 집합인 엔터티라는 전체 집합에서 일부의 인스턴스들만 모아놓은 부분집합 • 하나의 엔터티에 무수히 많은 부분집합을 만들 수 있음
서브타입 명	• 하나의 엔터티에서 만들어진 서브타입에 부여된 이름 • 어떤 인스턴스들의 집합인지 잘 나타낼 수 있는 용어
서브타입 세트	• 하나의 기준으로 도출된 서브타입의 모임 • ex) ‘고객유형’이라는 특성으로 구분 → 개인고객, 법인 고객 ⇒ 서브타입 세트
서브타입 세트명	• 서브타입을 도출하기 위해 사용된 기준이 되는 속성 • ex) 고객유형 • 서브타입을 표현하기 위한 속성이 반드시 물리적으로 존재할 필요 없음
서브타입 특징	• 서브타입의 전체집합이 반드시 엔터티일 필요 없음 • 하나의 서브타입을 전체집합으로 하는 하위 서브타입 정의 가능 • 전체집합을 ‘슈퍼타입’으로 부름 • ex) 엔터티가 서브타입 생성 → 엔터티 : 슈퍼타입 / 하나의 서브타입에 하위 서브타입 생성 → 상위 서브타입 : 슈퍼타입

8) 엔터티 통합과 분할

항목	상세 내용
엔터티의 독립성	• 새롭게 정의할 엔터티가 기존의 엔터티에 포함되지 않는 독립적인 집합인지 확인
엔터티의 분할/통합	집합의 일부가 겹쳐 있을 때 • 어느 한 집합을 확장하여 나머지 포함 • 교차된 부분을 한쪽 집합에서만 가지도록 분리 • 교차되는 부분이 있더라도 두 집합을 별개의 집합으로 간주 & 필요 시, 관계 설정
유연성 향상을 위한 통합	• 동질성을 확장해 중첩된 집합을 포함시키면 집합적 관계는 명확해짐 • 유연성과 단순성 향상되지만 지나친 확장은 집합의 의미를 희석시킴

4. 관계 정의

항목	상세 내용
관계 정의	개체 간의 관계 또는 속성 간의 관계 [관계 유형] • 1:1 : 개체 집합 A의 각 원소가 B의 원소 1개와 대응하는 관계 • 1:N : 개체 집합 A의 각 원소가 B의 원소 여러 개와 대응하는 관계 & B의 각 원소는 A의 원소 1개와 대응하는 관계 • N:M : 개체 집합 A의 각 원소가 B의 원소 여러 개와 대응하는 관계 & B의 각 원소는 A의 원소 여러 개와 대응하는 관계
관계 이해	• 관계도 집합에 해당 • 직접 종속인 것만 관계라고 함 • 두 엔터티 간에는 하나 이상의 관계가 존재할 수 있음 • 외래키 (FK)로 정의 [관계의 관점] • 항상 두 엔터티 간에 존재, 항상 2개의 관점을 가짐 • 데이터의 양방향 업무 규칙을 표현 • 관계를 통해 정보로서의 활용 가치 상승 • 관계는 외래키로 구현되어 참조 무결성으로 데이터 정합성 유지의 역할을 함
관계 표현	[관계 형태 (Degree / Cardinality)] • 하나 이상 (Many) : 1:M 관계는 1:1 관계가 포함되어 있음 • 단 하나 (Only One) [선택 사양 (Optionality)] • 점선은 존재하지 않을 수 있으며, 직선은 반드시 존재 [관계명의 부여] • 2개의 관계 멤버십에 각각 부여 • 현업에서 사용하는 가결한 동사형으로 표현 • 현재 시제 사용, 다른 관계명과의 유일성은 확보되지 못함 • 능동/수동형은 가급적 배제 • 업무적 의미가 없거나 애매모호한 용어 배제 • 관계명 부여의 중심이 되는 엔터티에서 봤을 때, 관계의 시계방향에 위치 [관계 수]
관계의 패어링 (pairing)	• 엔터티 안에 인스턴스가 개별적으로 관계를 가지는 것 • 패어링의 집합 → 관계
관계의 표기법	• 관계명 (Membership) : 관계의 이름 • 관계차수 (Cardinality) : 1:1, 1:M, M:N • 관계선택사양(Optionality) : 필수관계 (not null), 선택관계 (nullable, O 표시)

✔️ 관계 형태

관계	상세 내용	이미지
1:1 관계	- 필수-선택 관계 : 한쪽은 실선, 한쪽은 점선 - 필수-필수 관계 : 양쪽 모두 실선, 수직 분할 시 발생 - 선택-선택 관계 : 양쪽 모두 점선, 나중에 테이블 설계 시, 합집합을 만들어야 함
1:M 관계	- Both Side Mandatory : 주문 - 주문품목 - One Optional : 사원 - 부서 - Many Optional : 대금청구 - 납품 - Both Side Optioanl : 고객 - 좌석예약
M:N 관계	- 모델링이 완료된 후, M:N은 존재하지 않으며, 새로운 관계를 도출하여 해소해야 함 - M:N을 분해 시, 1:M으로 되는 것은 아니며 완전 해소까지 분해해야 함
다중 관계 처리	- 두 엔터티 간에 하나 이상의 관계를 가지고 있는 형태 - 병렬식 관계 : 별도의 관계로 간주하여 여러 개의 관계 선으로 나타냄 - 테이블이 될 때 여러 개의 컬럼으로 나열 - 하나의 로우에서 관리되므로 새로운 테이블 추가 필요 없음 - 인덱스 수가 증가하고 SQL이 복잡해짐 - 새로운 관계의 추가, 관계 형태의 변경 등에 매우 취약함 - 관계 내용 별로 상세 정보를 관리할 수 없으며, 관리하려면 새로운 엔터티를 추가해야 함 - 직렬식 관계 : 몇 개의 관계를 모아 상위 개념으로 통합하여 하나의 관계로 관리 - 관계들을 관리하는 새로운 엔터티가 추가되어야 함 - 관계들이 로우 형태로 나타남 - 인덱스 수가 감소하고 SQL이 단순해짐 - 새로운 관계의 추가, 관계 형태의 변경 등에 매우 유연함 - 관계 내용별로 상세 정보 관리 가능 (자식 엔터티를 거느릴 수 있음)
특수 형태 관계	- 순환 관계 : 자기 자신과 관계를 맺음 - 하나의 순환 엔터티는 각 엔터티의 모든 속성을 포함해야 함 - 각 계층에 있는 속성은 동일하게 하는 것이 좋음 - 순환 모델은 필수(직선) 관계로 할 수 없고, 반드시 선택 관계 - 조직의 변경(추가/삭제)에 쉽게 대응 가능 - BOM (Bill of Materials) 관계 : 네트워크 구조 - Arc (Mutually Exclusive) 관계 : 어떤 엔터티가 2개 이상의 엔터티의 합집합과 관계를 가짐 - 아크 내 관계는 보통 동일함 - 관계는 항상 필수거나 선택 사양이어야 함 - 아크는 반드시 하나의 엔터티에만 속해야 함 (하나의 아크가 여러 엔터티를 가질 수 없음) - 어떤 엔터티는 다수의 아크를 가질 수 있으나, 지정된 관계는 단 하나의 아크에만 사용되어야 함

5. 관계 데이터 모델

1) 관계 데이터 모델 ✅️

개념적 구조를 논리적 구조로 표현하는 논리적 데이터 모델
하나의 개체에 대한 데이터를 하나의 릴레이션에 저장

용어	상세 내용
릴레이션 (relation)	• 하나의 개체에 대한 데이터를 2차원 테이블의 구조로 저장한 것 • 파일 관리 시스템 관점에서 파일에 대응
속성 (attribute)	• 릴레이션의 열에 해당 • 파일 관리 시스템 관점에서 필드에 대응
투플 (tuple)	• 릴레이션의 행에 해당 • 파일 관리 시스템 관점에서 레코드에 대응
도메인 (domain)	• 하나의 속성이 가질 수 있는 모든 값의 집합 • 속성 값을 입력 및 수정할 때 적합성의 판단 기준이 됨 • 속성의 특성을 고려한 데이터 타입으로 정의
널 (null)	• 속성 값을 모르거나 해당되는 값이 없음을 표현 • 정보 부재를 나타내기 위해 사용 • 공백, 0 과는 다른 의미
차수 (degree)	하나의 릴레이션에서 속성의 전체 개수
카디널리티 (cardinality)	하나의 릴레이션에서 투플의 전체 개수

2) 릴레이션의 구성

항목	상세 내용
릴레이션 스키마	• 릴레이션의 논리적 구조 • 릴레이션의 이름과 릴레이션에 포함된 모든 속성 이름으로 정의 • ex) 고객 : 고객ID, 고객이름, 나이, 등급, 직업 등 • 릴레이션 내포 (relation intension)라고 함 • 정적인 특징이 있음
릴레이션 인스턴스	• 어느 한 시점에 릴레이션에 존재하는 투플의 집합 • 릴레이션 외연 (relation extension)이라고 함 • 동적인 특징

3) 릴레이션의 특성

관계 데이터 모델에서 4가지 특성을 모두 만족해야 릴레이션으로 인정 받음

항목	상세 내용
투플의 유일성	하나의 릴레이션에는 동일한 투플이 존재할 수 없음
투플의 무순서	하나의 릴레이션에서 투플 사이의 순서는 무의미함
속성의 무순서	하나의 릴레이션에서 속성 사이의 순서는 무의미함
속성의 원자성	속성값으로 원자값만 사용 가능함

4) 데이터베이스 구성

데이터베이스 스키마 : 데이터베이스 전체 구조 / 데이터베이스를 구성하는 릴레이션 스키마 모음
데이터베이스 인스턴스 : 데이터베이스를 구성하는 릴레이션 인스턴스 모음

✔️ 데이터베이스 특성 ✅️

데이터베이스는 계속적으로 변화함
데이터베이스는 실시간으로 접근함
데이터베이스는 동시 공용임

5) 키 (key)

릴레이션에서 투플을 구별하는 구별하는 속성 또는 속성의 집합
중복 여부를 알 수 있는 수단

유일성 : 하나의 릴레이션에서 모든 투플은 서로 다른 키 값을 가져야 함
최소성 : 꼭 필요한 최소한의 속성들로만 키를 구성해야 함

항목	상세 내용	예시
슈퍼키 (super key)	유일성을 만족하는 속성 또는 속성 집합	고객ID, (고객ID, 고객이름), (고객이름, 주소) 등
후보키 (candidate key)	유일성과 최소성을 만족하는 속성 또는 속성 집합	고객ID, (고객이름, 주소) 등
기본키 (primary key)	후보키 중 투플을 식별하는데 사용할 키	고객ID
대체키 (alternate key)	후보키 중 기본키로 선택되지 못한 키	(고객이름, 주소)
외래키 (foreign key)	• 다른 릴레이션의 기본키를 참조하는 속성 또는 속성 집합 • 릴레이션 간 관계 표현 • 외래키가 여러 개 존재할 수 있고, 기본키로도 사용 가능 • 같은 릴레이션의 기본키를 참조하는 외래키도 정의할 수 있음 • 외래키 속성은 null값을 가질 수 있음

6) 관계 데이터 모델의 제약

무결성 : 데이터의 결함이 없는 상태, 정확하고 유효하게 유지
개체 무결성 제약조건 : 기본키를 구성하는 모든 속성은 null값을 가질 수 없다
참조 무결성 제약조건 : 외래키는 참조할 수 없는 값을 가질 수 없다

✔️ Role name (역할명)

부모 엔터티로부터 속성(주식별자)을 상속 받았을 때, 자식 엔터티에서 그 속성이 수행하는 역할을 명확히 하기 위해 이름을 다르게 붙이는 것
다른 개체의 속성을 가져와서 속성명을 다르게 정의
여러 개체가 동일한 개체를 참조하는 경우, 속성명을 다르게 정의해야 할 필요성이 높아짐

참고 포스팅

[데이터 모델링] 2. 개념적 데이터 모델링

목차1. 개념적 데이터 모델링2. 개념적 데이터 모델링 예시 개념적 데이터 모델링에 본격적으로 들어가기 앞서, 다시 한 번 더 데이터 모델링의 단계를 복기해보자.총 4가지 단계로 구성되며, 어

ars420.tistory.com

[데이터 아키텍처 준전문가(DAsP)] 과목 4. 데이터 모델링 (1) 데이터 모델링 이해

알밤바 — Tue, 17 Mar 2026 11:22:00 +0900

1. 데이터 모델링 개요

1) 데이터 모델링 ✅️

항목	상세 내용
모델링이 필요한 이유	• 파급효과 : 시스템 구축이 완성되어 가는 시점에 데이터 모델을 변경해야 하는 것이 큰 위험 요소임 • 정보 시스템의 간결한 표현 : 데이터 모델은 정보 요구사항을 정확하고 간결하게 표현할 수 있음 • 데이터 품질 : 잘못 설계된 모델링은 데이터의 정확성을 떨어뜨림
데이터 모델링의 필요성	• 애플리케이션과 데이터의 통합 • 개발자의 시스템 이해
데이터 모델링 시 주의할 점	• 중복 • 비유연성 • 비일관성

✔️ 개발자가 시스템 이해에 데이터 모델링이 필요한 이유

데이터 정의, 생명주기 정보, 언제 어떻게 데이터가 사용되었는지 등 추적할 수 있는 정보를 제공
물리적인 것과 논리적인 것을 구별하여 데이터를 사용하는 사람과 물리적인 모든 것으로부터 독립되어 조직과 사용자가 필요로 하는 필수적이고 기본적인 데이터를 정의할 수 있음
데이터 모델링은 사용자가 원하는 것의 논리적 개념과 시스템이 어떻게 제공하는지의 물리적 개념을 명확하게 나타내줌

✔️ 참고) 3단계 스키마 구성

외부 스키마 (External Schema) : 사용자 뷰 단계 (개개인의 관점에서 필요한 데이터만 정의 / 여러 개 존재 가능)
개념 스키마 (Comceptual Schema) : 전사적 관점의 통합 단계 (모든 사용자 관점을 합친 DB 구조 설계도 / 하나만 존재)
내부 스키마 (Internal Schema) : 물리적 저장 단계 (기술적인 내용을 담고 있음)

▶ 이렇게 3단계로 나누는 이유는 하나가 바뀌어도 다른 쪽은 영향을 안 받게 하기 위함 (데이터 독립성)

2) 데이터 모델링 단계

단계	상세 내용
개념 데이터 모델링	• 사용자의 요구사항을 분석하여, 핵심 엔터티와 관계를 발견하여 ERD 작성 • 상위 문제를 쉽게 구조화하며 사용자와 개발자가 논의할 수 있는 기반 마련 • 업무 중심적이고 포괄적인 수준의 모델링 진행 • 전사적 데이터 모델링, EA 수립 시 많이 이용
논리 데이터 모델링	• 비즈니스 정보의 논리적인 구조와 규칙을 명확하게 표현하는 과정 • 정규화, 식별자 확정, M:N 관계 해소, 참조 무결성 등 작업 실시 • Key, 속성, 관계 등을 정확하게 표현하고, 재사용성이 높음
물리 데이터 모델링	• 목표하는 DBMS의 특성을 고려한 스키마 설계 • 컬럼, 데이터 타입, 크기 등 정의 • 성능, 저장 등 물리적인 성격을 고려하여 설계
리버스 데이터 모델링	• 기존 시스템의 모델을 보유하지 않거나 현행화되지 않았을 때, 시스템의 메타 정보를 활용하여 모델 작성 • 모델링 CASE TOOL을 활용하여 기존 산출물을 통해 메타 정보를 수집하여, 이를 토대로 테이블과 컬럼을 분석한 후 이들의 관계를 파악하여 모델 작성

3) 데이터 모델링 원칙

원칙	상세 내용
커뮤니케이션 원칙	• 최종 사용자 및 이해관계자에게 시스템의 지향점을 설명
모델링 상세화 원칙	• 데이터의 본질과 잠재적 사용을 이해할 수 있을 만큼 상세화
논리적 표현 원칙	• 데이터에 대한 논리적 측면을 최대한 표현

4) 좋은 데이터 모델의 요소

요소	상세 내용
완전성	업무에 필요한 모든 데이터가 모델에 정의되어 있어야 함
중복 배제	동일한 정보는 1개만 있어야 함
비즈니스 룰	업무 규칙을 데이터 모델에서 구현해야 함
데이터 재사용	애플리케이션에 대해 독립적으로 설계되어야 데이터 재사용성을 향상할 수 있음
안정성 및 확장성	안정성 뿐만 아니라 추후 데이터를 쉽게 변경할 수 있도록 확장성 고려
간결성	테이블을 통합하여 모델의 간결함 유지
의사소통	요구사항에서 도출되는 업무 규칙을 데이터 모델에 최대한 자세히 표현
통합성	전체가 연결되어 움직여야 함

2. 데이터 모델링 기법 이해

1) 개체 - 관계 모델 구성 요소

요소	상세 내용
엔터티	• 엔터티 종류 중, 키 엔터티가 될만한 것을 우선 도출하여 메인/액션 엔터티 도출 • 엔터티는 동질성을 가지는 개체 집합이며, 행위의 집합으로 정의할 수 있음
속성	• 엔터티에 저장되는 개체 집합의 특성을 설명하는 항목 • 서로 다른 집합에 정의된 속성은 같은 도메인을 공유할 수 있음 (ex. 주소, 전화번호)
식별자	• 개체를 식별할 수 있는 속성 (하나 또는 그 이상의 속성으로 구성) • 엔터티를 대표할 수 있는 속성 • 하나의 엔터티에는 반드시 하나의 식별자가 존재 • 식별자는 논리적인 관점에서 사용되고, 키는 물리적인 관점에서 사용됨 • 식별자와 키가 서로 일치하지 않을 수 있음 • 본질 식별자 : 집합의 본질을 명확히 설명할 수 있는 의미상의 주어 • 후보 식별자 : 인스턴스를 유일하게 식별할 수 있는 속성 또는 속성 조합 • 대체 식별자 : 원래의 식별자를 대신할 수 있는 또 다른 속성 • 인조 식별자 : 기존 본질 식별자를 쓸 수 없는 상황이 발생했을 때 사용 • 실질 식별자 : 인스턴스를 식별하기 위해 부여된 식별자 (본질/인조 식별자 모두 가능)
관계	• 엔터티 간의 연관성 표현 • 1:1 : X, Y에 속하는 개체는 각각 하나씩만 연결 • 1:M : X에 속하는 한 개체는 Y에 속하는 한 개체에만 연결되며, Y에 속하는 한 개체는 X에 속하는 여러 개체와 연결 • M:N : X, Y에 속하는 한 개체는 각각 여러 개체와 연결됨
카디날리티	관계에 참여하는 하나의 개체에 대해 다른 엔터티에서 몇 개의 개체가 참여하는지 나타냄
존재 종속	한 엔터티의 존재가 다른 엔터티의 존재에 영향을 받는 것
서브타입	• 전체 집합인 슈퍼타입의 부분 집합 • 배타적 (1개만 관련) / 포괄적 (1개 이상 관련)으로 구분 • 슈퍼타입은 공통적인 모든 속성을 포함하고 있음 • 서브타입은 각 서브타입에 적절한 속성만 포함

3. 데이터 모델링 표기법 이해

	바커 표기법	I/E 표기법
엔터티
속성	엔터티 안에 위치	엔터티 안에 위치
관계
식별자		엔터티 중 상단의 박스 안에 표시 (ex. 사원번호)
서브타입		- 배타적/포괄적일 경우 존재 - 배타적일 경우, 관계에 X 표시
관계 표현 비교

✔️ 데이터 모델이 제공하는 것 ✅️

시스템을 구축하는 틀 제공
시스템의 구조와 행동을 명세화할 수 있게 해줌
다양한 영역에 집중하기 위해 다른 영역의 세부사항은 숨기는 다양한 관점 제공

✔️ 객체 지향 모델링 ✅️

데이터(속성)와 데이터를 사용하는 기능(메소드)를 하나로 묶어서(객체) 관리하는 개념
객체 = 데이터 + 메소드
핵심 구성 요소
- 객체(Object) : 실세계에 존재하는 독립적인 개체 (ex. 조직, 시스템 등)
- 속성(Attribute) : 객체가 가진 데이터 값 (ex. 이름, 직무, 경력 등)
- 메소드(Method) : 객체가 수행하는 동작 (ex. 데이터 분석, 로그 설계 등)
- 클래스(Class) : 같은 성격의 객체를 만들기 위한 틀 (ex. '데이터 분석가'라는 클래스)
조직이나 시스템은 객체라는 것에 관련되어 있고, 객체에 대한 정보를 저장
객체는 대개 객체를 기술하는 데이터와 그 기술 데이터를 운영하는 메소드로 구성
객체는 연관(Association) 또는 상속을 통해서 다른 객체와 연결
속성 유형과 메소드를 공유하는 객체가 그룹화되어서 '클래스(Class)'라고 함
객체는 메소드를 다른 객체로 전달할 수 있음
메소드를 오버라이딩(Overriding)해서 다른 객체에서 사용 가능
OID(Object Identifier)는 객체의 값 일부를 사용하며, 그 값이 바뀌면 OID도 변경이 가능함

[데이터 아키텍처 준전문가(DAsP)] 과목 3. 데이터 표준화

알밤바 — Sun, 15 Mar 2026 18:35:28 +0900

[1장] 데이터 표준화 개요

1. 데이터 표준화 정의

항목	내용
데이터 활용 상의 문제점	• 데이터 중복 및 조직/업무/시스템별 데이터 불일치 • 데이터 의미 파악 지연으로 정보 제공의 적시성 결여 • 데이터 통합의 어려움 • 정보시스템 변경 및 유지 보수 어려움
데이터 문제점의 원인	• 동시다발적인 정보 시스템 개발 • 전사 데이터 관리 마인드 미형성 • 전사 데이터 관리 인력 부재 • 전사 데이터 표준 관리 도구 부재
데이터 관리 개선 방안	• 데이터 표준화, 규격화를 위한 기본 방침 설정 • 전사적인 정보 공유를 위해 유지되어야 할 공통 데이터 요소 도출 • 전사적인 데이터 요소 등록 및 관리 체계 구축 • 정보 시스템 개발 및 유지 보수 시 승인된 데이터 요소를 활용하여 효율성 및 데이터 공유성 향상
데이터 표준화 기대효과 ✅️	• 명칭 통일로 인한 명확한 의사소통 증대 • 필요한 데이터의 소재 파악에 소요되는 시간 및 노력 감소 • 일관된 데이터 형식 및 규칙 적용으로 인한 데이터 품질 향상 • 정보 시스템 간 데이터 인터페이스 시 데이터 변환 및 정제 비용 감소

2. 데이터 표준화 개념

1) 데이터 표준화 정의

데이터 정보 요소에 대한 명칭, 정의, 형식, 규칙에 대한 원칙을 수립하여 전사적으로 적용

항목	내용
데이터 명칭 (표준용어, 표준단어) ✅️	• 유일성 : 하나의 개념에 대해 사용자 모두가 통일된 용어를 사용할 수 있도록 하나의 명칭만 허용 • 업무적 관점의 보편성 : 업무적 관점에서 보편적으로 인지되어야 함 • 의미 전달의 충분성 : 데이터 명칭 이름만으로 데이터의 의미 및 범위가 파악되어야 함
데이터 정의 (용어 정의서)	• 데이터가 의미하는 범위 및 자격 요건 규정 • 데이터의 의미를 잘 이해할 수 있도록 제3자 입장에서 기술 • 서술식 정의만으로 의미 전달이 어려울 경우, 실제 발생 데이터도 함께 기술 • 데이터 명칭을 그대로 쓰거나, 약어 또는 전문 용어는 가급적 사용 금지
데이터 형식 (표준 도메인) ✅️	• 데이터 타입 : Numeric, Text, Date, Char, Timestamp 등 • 데이터 길이 및 소수점 자리 [데이터 형식 정의 시 고려 사항] • 도메인을 정의하여 데이터 표준에 적용함으로써 성격이 유사한 데이터 간의 형식을 통일해야 함 • 데이터의 최댓값 또는 최대 길이를 여유 있게 정의 • 특수 타입 (CLOB, Long Raw 등)은 데이터 조회, 백업, 이행 등에 제약이 있는 경우가 많으므로, 가급적 사용하지 말아야 함
데이터 규칙 (업무 규칙)	발생 가능 데이터를 사전 정의하여, 입력 오류와 통제 위험 최소화 (정합성/완전성 향상) • 기본 값 : 입력 생략 시 자동으로 입력되는 값 • 허용 값 : 입력이 가능한 데이터 값을 제한 (ex. 코드 값을 사전에 정의하는 경우) • 허용 범위 : 입력이 가능한 데이터 값을 범위로 제한 (ex. 1~5까지)

2) 데이터 표준화 대상

데이터 표준화 결과물인 데이터 표준 사전은 단어 사전, 용어 사전, 도메인 사전으로 구성됨

3) 데이터 표준화 구성 요소

데이터 표준, 데이터 표준 관리 조직, 데이터 표준화 절차

✔️ 데이터 표준

항목	설명
표준 용어	업무적 용어(보고서나 매뉴얼, 색인 등), 기술적 용어(테이블명, 컬럼명 등)
표준 단어	• 동일한 개념을 의미하는 용어 생성 방지 • 표준 단어는 영문명의 작성 기준이 됨 • ex. 사원 = member, 번호 = id라고 표준 단어를 정의 → 사원번호 = member_id
표준 도메인	• 컬럼에 대한 성질을 그룹화한 개념 • 데이터 타입 및 길이를 일관되게 정의
표준 코드	• 도메인의 한 유형 • 특정 도메인 값(코드 값)이 이미 정의되어 있는 도메인 • 코드 값까지 미리 정의해야 함
기타 데이터 표준 요소	주제 영역, DB 스키마, Tablespace, INDEX 등에 대한 표준 관리

✔️ 데이터 표준 관리 조직

- 데이터 관리자 주요 역할 ✅️

데이터 정책, 표준 정의, 부서 간 데이터 구조 조율
데이터 보안 관리, 데이터 모델 관리, 데이터 활용 방안 계획 등

구분	주요 활동
전사 데이터 관리자	• 데이터 표준화에 대한 정책 결정 • 검토된 데이터 표준 제안에 대한 승인
업무 데이터 관리자 (Ownership)	• 담당 업무 기능의 데이터 요구 사항 반영을 위해 필요한 데이터 표준 정의 • 업무 관련 데이터 표준 변경 제안에 대한 합동 검토 • 데이터 생성/변경/삭제 권한의 관리 주체로, 주로 해당 시스템을 사용하는 부서 및 담당자
업무 시스템 데이터 관리자 (Stewardship)	• 시스템 관리 목적의 데이터 요구 사항을 위해 필요한 데이터 표준 정의 • 업무 관련 데이터 표준 변경 제안에 대한 합동 검토 • 데이터 모델에 대한 데이터 표준 적용 및 준서 여부 체크

- 데이터 관리자 vs 데이터베이스 관리자 ✅️

구분	데이터 관리자 (DA)	데이터베이스 관리자 (DBA)
관리 대상	데이터 요구 사항을 반영한 데이터 모델 및 각종 표준	데이터 모델을 특정 데이터베이스 제품의 특성에 맞춰 구축한 데이터베이스
주 업무	• 업무에 필요한 메타 데이터를 정의 • 신규/변경된 요구 사항을 데이터 모델에 반영	요구되는 성능 수준을 발휘하며, 안정적으로 운영되도록 데이터베이스 관리
품질 수준 확보	데이터 표준의 관리 및 적용을 통해 품질 수준 확보	데이터 정합성 관리를 통해 데이터 품질 수준 확보
전문 기술	담당 업무 분야에 대한 업무 지식과 데이터 모델링에 대한 전문성 필요	데이터 모델에 대한 해독 능력 및 특정 데이터베이스 제품에 대한 전문 지식 필요

✔️ 데이터 표준화 절차

- 데이터 표준화를 해야 하는 상황

운영 시스템 신규 구축
SI 사업으로 시스템 재구축
기존 시스템에서 단위 시스템을 추가 구축
업무 시스템(계정계)에서 분석 시스템(정보계)을 구축하는 경우
두 기관의 시스템을 통합하는 경우
기존 데이터 사전 고도화
공공기관의 데이터 공개를 위한 공공데이터 표준 준수 등

- 데이터 표준화 절차

구분	주요 활동
데이터 표준화 요구사항 수집	• 개별 시스템 데이터 표준 수집 • 데이터 표준화 요구사항 수집 • 표준화 현황 진단
데이터 표준 정의	• 표준화 원칙 • 데이터 표준 정의 : 표준 용어, 표준 단어, 표준 도메인, 표준 코드, 기타 표준
데이터 표준 확정	• 데이터 표준 검토 및 확정 • 데이터 표준 공표
데이터 표준 관리	• 데이터 표준 이행 • 데이터 표준 관리 절차 수립 : 데이터 표준 적용, 변경, 준수 검사 절차

3. 데이터 표준 관리 도구

1) 데이터 표준 관리 도구 종류

데이터 표준 관리 도구 : 표준 데이터를 기본으로 하여 데이터 등록 및 수정
데이터 구조 관리 도구 : 논리 및 물리 뎅이터 모델 생성 및 등록
데이터 품질 진단 도구 : 현 시스템에 등록된 데이터 오류 및 표준화 수준 진단
데이터 흐름 관리 도구 : 데이터베이스와 어플리케이션의 상호 영향도 분석

2) 데이터 표준 관리 시스템

✔️ 데이터 표준 관리 기능 ✅

메타 데이터 관리 시스템
단어, 용어, 도메인, 코드 등록 및 조회

기능	세부 설명	주요 내용
단어 관리	전사 단어 사전 및 금칙어	• 전사 관점에서의 단어 사전 관리 • 금칙어의 사전 정의 및 관리
용어 관리	용어 사전	• 업무적으로 정의된 표준 용어에 대한 관리 • 기본 단어의 조합으로 업무 용어 생성
도메인 관리	도메인 사전	• 대표 및 그룹 속성에 대한 데이터 타입, 길이, 소수점 이하 길이 등 사전에 정의한 도메인 관리
표준 코드 관리	전사 표준 코드	• 수집된 코드로부터 코드 통합 과정을 거쳐 전사 표준 코드를 도출한 후 관리
표준 코드 관리	코드 변환 매핑	• 소스 코드 값과 표준 코드와의 변환 매핑 관리
멀티 표준 관리	멀티 표준	• 코드, 컬럼, 테이블, 도메인 등에 대해 멀티 표준 관리 • 전사에 존재하는 여러 푲준을 지원하고 이후 전사 표준으로 통합되도록 함

✔️ 데이터 구조 관리 기능 ✅

기능	세부 설명	주요 내용
ER 모델 구조 관리	모델, 테이블 구조 정보	• ER 모델 관리 • 리포지터리로부터 데이터 구조 정보를 추출 및 로드
DB 스키마 관리	다양한 DBMS 지원 및 DB 스키마 로드	• 다양한 DBMS로부터 DB 카탈로그 추출 및 로드
가변 속성 관리	모델의 사용자 속성 자동 생성	• 모델 기본 속성 외에 설계 속성 추가
이력 관리	이력 관리	• 데이터 모델 변경 이력 • 형상 관리 지원
모델 비교 관리	충실도 및 준수도 검사	• 데이터 구조 정보에서 표준화 자동 검사 • 표준에 대한 준수도 자동 검사 • 데이터 구조 정보 간 비교

✔️ 데이터 품질 진단 도구

기능	방법	주요 내용
프로파일링	값 진단	• 데이터 값의 유효성, 정확성 등 데이터 값 자체의 오류 분석 • 컬럼 분석, 날짜 분석, 패턴 분석, 코드 분석 등
프로파일링	구조 진단	• 논리적 데이터 구조의 오류로 인한 일관성, 정합성 등을 확보하지 못하는 결함 분석 및 진단 • 표준화 수준, 테이블 구조, 정규화 수준, 컬럼 및 관계 정의 등
업무 규칙(BR) 진단		• 법, 규정에 정의된 업무 기준에 근거하여 데이터가 관리되고 있는지 진단

3) 데이터 표준 관리 도구 도입 시 고려 사항

항목	상세 내용
확장성	다양한 시스템 및 DBMS의 정보 수집과 OLAP 툴 등의 다양한 데이터 구조 정보를 추출할 수 있을지 검토
유연성	여러 개의 통합 표준을 사용할 수 있는 복수 표준 관리가 가능한지, 한글명/영문명 표현 방식 등 검토
편의성	한글명의 영문명 자동 변환, 표준 검증 주기적인 작업 수행 기능, 메타 정보 수집 시 Import 수작업 최소화 등 사용자 편의성 검토

[2장] 데이터 표준 수립

1. 데이터 표준화 원칙 정의

1) 데이터 표준화 요구사항 수집

전체적인 관점 및 제3자 관점에서 기술할 수 있어야 함
자신이 맡은 영역과 다른 영역 간의 인터페이스 부분에서 발생하는 불편사항 및 개선사항 파악
특정 영역에 대해 조사할 때, 해당 영역에 익숙하지 않은 관리자의 관점이 더 유용함

2) 현행 데이터 표준 원칙 분석

현행 데이터 표준 원칙 수집
- 현 정보 시스템 개발 지침 문서 및 데이터 표준 확보
- 현행 정보 시스템 모델 분석
데이터 표준 원칙 사용 현황 분석
- 현행 시스템에 적용하고 있는 항목 도출

3) 데이터 표준 개선 방안 정의

전사적인 관점에서 접근하여 전사적 필요성 검토 → 신규 정의 및 정의 대상 제외
기존에 수립된 데이터 관리 정책에 부합해야 함

4) 데이터 표준 원칙 수립 ✅

✔️데이터 표준 기본 원칙 정의 : 전체적으로 적용할 기본 원칙 수립

✔️ 데이터 표준 지침의 기본 구성

항목	상세 내용
개요	목적 기술
데이터 표준화 관련자의 역할 및 책임	전사 데이터 관리자, 데이터 관리자, 모델러 등
데이터 표준 관리 절차	• 작업 프로세스 규정 • 프로세스별 표준화 관련자 역할 기술 • 데이터 표준 정의, 데이터 표준 변경, 데이터 표준 준수 프로세스
데이터 표준 기본 원칙	대상 모두에 대한 기본 원칙 기술
데이터 표준 대상별 명명 규칙	아래 표 참고
데이터 형식 정의 기준	• 표준 용어, 표준 도메인, 표준 코드에 대한 형식 정의에 대한 기준 정의 • 표준화 정의 시 데이터 형식도 함께 정의
기타	고유 특성에 대해 원칙을 구체적으로 기술

✔️ 데이터 표준 대상별 명명 규칙 ✅

기술 내용	설명
사용 문자	알파벳, 한글, 숫자, 특수문자, 전각/반각 등의 허용 여부 또는 사용 조건 규정
영문 대소문자	대소문자 사용 관련 규칙 규정
한글명과 영문명 동시 정의 여부	• 데이터 표준 정의 대상에 대해 한글명과 영문명의 정의 필요 • 표준 단어, 표준 용어 • 영문명 전환 시, 발음식 (ex. 전화 → Jeonhwa)도 허용 • 한글명 및 영문명 부여 시, 띄어쓰기 허용 금지 • 영문명에 대해 여러 개의 한글명 허용 • 한글명에 대해 여러 개의 영문명 미허용!
명칭 구조	• 표준 용어를 사용하는 테이블명 및 컬럼명의 경우, 명칭을 통해 특성 및 부가 정보를 표시할 수 있도록 단어 표준 조합 구조 명시 • ex) 수식어 + [수식어] + 속성 유형 (금액, 건수, 코드 등)
명칭 허용 길이	테이블명, 컬럼명의 경우, DBMS의 물리적 특성으로 길이의 제약을 받기 때문에 표준 용어의 허용 길이를 명시
명칭 표준화 기준	• 유사한 개념의 단어/용어가 여러 개 존재 시, 어떤 기준으로 정의할지 기준 정의 • ex) 일련변호, ID, SEQ → ID로 표준화
명칭 예시	명칭 허용 길이, 구조 체계, 표준화 기준 등 준수하여 작성된 샘플 명시

✔️ 표준 대상별 지침의 일반적 구성 ✅

항목	상세 내용
표준 단어	• 한글명 및 영문명에 대한 알파벳, 한글, 숫자, 특수 문자 등의 허용 여부 또는 사용 조건 • 대소문자 사용 규칙, 한글/영문명 허용 길이, 합성어 정의에 대한 지침 • 접두사 처리 방안, 동음이의어/이음동의어 허용 여부 및 처리 방안
표준 용어	• 데이터 명칭에 대한 구조 처계, 한글/영문명 허용 길이 • 용어를 테이블이나 컬럼명으로 사용 시 준수할 명명 규칙 • 용어를 컬럼명으로 사용 시 데이터 형식 표준화 기준 및 표준 도메인 적용 여부
표준 도메인	• 데이터 형식 표준화 기준
표준 코드	• 데이터 명칭 구조 체계 및 명명 기준 • 데이터 형식 표준화 기준, 코드 번호 체계 정의 규칙

✔️ 데이터 표준 개발 지침 작성 시 유의 사항

다른 정보 시스템에서도 적용 가능하도록 범용성 고려하여 정의
대상 DBMS에 모두 적용 가능하도록 고려
영문 약어명을 추가로 정의하거나 뷰를 사용하는 등 대안 마련
표준 용어/도메인에 서로 다른 DBMS에 따라 어떻게 적용할 것인가에 대한 방안 고려 (변환 Map 정의)

2. 데이터 표준 정의 ✅

항목	관리 기준	작성 형식
표준 단어 사전	• 표준성 : 업무에서 사용하는 단어에서 추출, 전문적인 용어는 최소화 • 일반성 : 사전적 의미와 크게 다르지 않아, 일반인도 의미를 이해할 수 있어야 함 • 대표성 : 비슷한 의미의 동의어를 대표할 수 있어야 함	• 전사적으로 관리는 엔터티와 속성을 개별 단위로 추출 • 동음이의어, 이음동의어를 정비한 후 논리명(한글명)을 기준으로 물리명(영문명), 유사용어 정리 • 개별 단어 외에도 동의어, 유의어, 반의어 등과 같은 단어 간의 구조도 함께 정의
표준 도메인 사전	• 표준성 :공통적 사용 속성을 대상으로 정의 • 유일성 • 업무 지향성 : 업무 특성 반영	• DBMS에 동일한 형태로 구현되는 속성을 추출하여 그룹화 • 모든 속성은 하나 이상의 도메인이 복수로 할당되면 안 됨 • 속성과 도메인은 상호 매핑하여 관리 필요 • 새로운 속성 추가 시, 해당 속성의 도메인을 선정 및 등록할 것을 권장 • 삭제는 해당 도메인을 사용하고 있는 속성이 없을 때만 가능하도록 해야 함
표준 코드 사전	• 재사용성 : 표준화 기구, 정부 등에서 정의한 코드 재사용이 효과적 • 일관성 : 업무 범위 내에서 유일하게 정의되어야 함 • 정보 분석성 : 가능한 범위의 데이터는 모두 코드화하여 관리	• 전사적으로 사용하는 코드를 부여된 코드와 동일한지 확인하여, 동일하면 통합 작업을 통해 단일화 작업을 수행 • 코드는 표준화 팀의 관리를 받아야 함 • 도메인 값이 명확한 경우 (ex. Y/N)는 코드화하지 않아도 됨
표준 용어 사전 ✅	• 표준성 : 동일한 용어를 동일한 의미로 이해할 수 있도록 함 • 일반성 : 지나치게 업무 관점으로 정의되면 안 됨 • 업무 지향성 : 업무 범위 내에서 약어나 별도 정의하여 사용	• 용어 사전은 엔터티 용어사전과 속성 용어사전을 구분하여 정의 및 관리 • 논리명(한글명), 물리명(영문명)을 가지며, 용어 범위 및 자격 형식 등 설명 필요

항목	정의	고려 사항
표준 단어	• 현행 용어 수집 • 단어 분할 • 단어 정련 • 표준 단어 사전 정의	• 최소 단위 기준으로 정의 • 사용 빈도가 높은 단어 조합 → 하나의 표준 용어로 정의 • 영문명도 알파벳으로 시작하도록 정의 • 동음이의어 : 사용 빈도가 높은 것을 정의 • 접두어, 접미어와 같이 한 자리로 구성된 단어 → 표준에서 제외, 단어 조합하여 정의
표준 도메인	• 혼재되어 사용되는 컬럼명, 데이터 타입, 길이 등 정리 • 현행 용어 정보 분석 • 표준 도메인 정의	• 모든 용어를 포괄할 필요 없음 • 다른 DBMS에 물리적 적용 방안 고려 • 동일한 용어로 판단된 현행 용어는 별도로 기록하여 동일한 용어로 통일할 때 참고
표준 코드	• 현행 코드 수집 • 현행 코드 상세 분석 • 표준 코드 정의	• 향후 확장성 고려 • 일관성 유지 • 시스템 운영 중 변경 시, 새로운 코드 값 정의 • 현행 코드 간 변환 매칭 정보 별도 기록
표준 용어	• 현행 용어에 대한 표준 단어 및 표준 용어 정의 • 표준 단어에 대한 도메인/코드 정의	• 한글명, 영문명의 허용 길이 넘으면 안 됨 • 영문명 길이가 문제라면, 한글명 변경 또는 재조합하여 등록 • 생성된 표준 용어가 길다면, 2개의 표준 용어를 복합하여 생성

1) 표준 단어 사전 정의

항목	내용
표준 단어 사전	• 업무 상 사용하며 일정한 의미를 갖는 최소 단위의 단어 정의한 사전 • 정의된 단어는 속성에 사용 • 단어 정의시 이음동의어 주의해야 함 (ex) 사원 → 표준어, 직원 → 유사어/금지어 • 이음동의어로 묶인 단어 중 시스템에서 사용할 이음동의어를 지정하여 다른 단어들이 참조할 수 있도록 함 • 단어 정의 시, 단어의 영문명과 영문약어명을 정의 (ex) 사원 : 회사에서 근무하는 사람 / 영문 : employee / 영문약어명 : EMP • 동음이의어 사용 금지 (ex) 이전 (before) vs 이전 (transfer) • 표준화의 핵심은 동일한 의미의 속성명을 통일시키는 것 [표준 단어 관리 기준] • 표준성 : 업무에서 사용하는 단어에서 추출, 전문적인 용어는 최소화 • 일반성 : 사전적 의미와 크게 다르지 않아, 일반인도 의미를 이해할 수 있어야 함 • 대표성 : 비슷한 의미의 동의어를 대표할 수 있어야 함 [표준 단어 작성 형식] • 전사적으로 관리는 엔터티와 속성을 개별 단위로 추출 • 동음이의어, 이음동의어를 정비한 후 논리명(한글명)을 기준으로 물리명(영문명), 유사용어 정리 • 개별 단어 외에도 동의어, 유의어, 반의어 등과 같은 단어 간의 구조도 함께 정의
표준 단어 정의	• 현행 용어 수집 : 데이터 모델 및 정의서에서 사용되는 현행 용어를 수집하며, 한글명이 존재하지 않는 모델은 수집 대상에서 제외 (영문 약어명을 도출하기 위함이므로) • 단어 분할 : 최소 단위의 단어로 분할, 한글명과 영문명도 함께 분할되는지 고려, 단독으로 분할되는 숫자는 표준화 대상 단어에서 제외 • 단어 정련 : 분할하여 취합된 단어 중 의미가 동일한 단어는 대표 단어를 표준으로 선정하고 영문 약어명을 선택 → 한글명과 영문명이 유일해야 함 - 한글명과 의미가 동일한 단어를 취합 후, 활용 빈도가 높은 한글명을 표준 단어로 채택 - 가장 많이 나타나는 영문 약어명 선택 - 동음이의어의 경우, 상대적으로 활용도가 적은 단어는 다른 한글명 선택 • 표준 단어 사전 정의 : 표준으로 선택한 단어의 한글명, 영문명 등록
표준 단어 정의 시 고려 사항 ✅	• 표준 단어 단위는 최소 단위 기준으로 하되, 사용 빈도가 높은 단어의 조합 또는 하나의 고유한 의미를 가지는 경우, 하나의 표준 단어로 정의하는 것이 유리함 (ex. 신용카드, 유가증권) • 대부분 DBMS는 첫 글자를 알파벳으로 정의하도록 하므로, 영문명도 알파벳으로 시작하도록 함 • 동음이의어는 사용 빈도가 높은 것을 표준 단어로, 낮은 것은 다른 단어와 조합하여 정의 • 접두어, 접미어와 같이 한 자리로 구성된 단어들은 표준에서 배제하는 대신, 앞뒤에 나오는 단어와 조합하여 표준 단어로 정의 (접두어, 접미어 합성 단어 관리 방식) - 사용자 편의성 높음 - 일관된 단어 사전의 모습을 가지지 못함 - 물리 DB의 허용 길이를 넘는 경우가 발생할 가능성 적음

2) 표준 도메인 사전 정의

항목	내용
표준 도메인 사전	• 논리/물리적으로 유사한 데이터를 그룹화하여 유형과 길이를 정의 • 도메인은 여러 개의 하위 도메인으로 구성되거나, 하나의 도메인이 여러 개의 도메인에 중복 사용될 수 있음 • 도메인은 데이터 타입과 길이, 포맷 등이 같은 값의 집합 • 하나의 속성에는 허용된 유효한 값의 형태가 같아야 하므로 도메인은 하나만 사용해야 함 [표준 도메인 관리 기준] • 표준성 (공통적 사용 속성을 대상으로 정의) • 유일성 • 업무 지향성 (업무 특성 반영) [표준 도메인 작성 형식] • DBMS에 동일한 형태로 구현되는 속성을 추출하여 그룹화 • 모든 속성은 하나 이상의 도메인이 복수로 할당되면 안 됨 • 속성과 도메인은 상호 매핑하여 관리 필요 • 새로운 속성 추가 시, 해당 속성의 도메인을 선정 및 등록할 것을 권장 • 삭제는 해당 도메인을 사용하고 있는 속성이 없을 때만 가능하도록 해야 함
표준 도메인 정의	• 혼재되어 사용되는 컬럼명, 데이터 타입, 길이 등을 정리 및 표준 도메인 정립 [현행 용어 정보 분석] • 시스템 모델, 정의서 기반 정보 수집 후, 물리적으로 유사한 유형의 용어들을 그룹화 • 동일한 정보 시스템에 대한 데이터 모델에서 추출된 현행 용어들을 추출 • 한글명, 영문명, 데이터 타입 및 길이 모두 일치하는지 확인 • 데이터 타입과 길이가 동일한 용어들을 검색하여 유사한 속성의 용어들을 그룹핑 • 용어 중 끝쪽 단어 (금액, 번호, 여부 등)를 기준으로 유사한 속성의 용어들을 그룹핑 [표준 도메인 정의] • 업무적으로 의미 있는 도메인명 부여 (ex. ID, 일시 등) • 기존 데이터와 호환성, 범용성을 위해 그룹화된 용어들에 부여된 것 중 가장 큰 데이터 길이를 표준으로 함
표준 도메인 정의 시 고려 사항 ✅	• 모든 용어를 포괄하는 표준 도메인은 필요 없음 • 표준 도메인 형식을 각기 다른 DBMS에 물리적 적용 방안을 고려해야 함 • 동일한 용어로 판단된 현행 용어들은 별도로 기록하여 향후 동일한 표준 용어로 통일할 때 참고

3) 표준 코드 사전 정의

항목	내용
표준 코드 사전	• 통합 대상 파악 및 표준 코드를 정의하고 현 코드와 매핑 설계 • 정의된 표준 코드 별로 오너십을 정의하여 향후 해당 코드의 수정, 삭제 권한 관리 [표준 코드 관리 기준] • 재사용성 : 표준화 기구, 정부 등에서 정의한 코드 재사용이 효과적 • 일관성 : 업무 범위 내에서 유일하게 정의되어야 함 • 정보 분석성 : 가능한 범위의 데이터는 모두 코드화하여 관리 [표준 코드 작성 형식] • 전사적으로 사용하는 코드를 부여된 코드와 동일한지 확인하여, 동일하면 통합 작업을 통해 단일화 작업을 수행 • 코드는 표준화 팀의 관리를 받아야 함 • 도메인 값이 명확한 경우 (ex. Y/N)는 코드화하지 않아도 됨
표준 코드 정의	[현행 코드 수집] • 개별 코드 테이블 : 하나의 코드를 하나의 테이블에서 관리 (ex. 고객 번호 등) • 필수 코드, 코드 값 외에 부가 정보를 관리할 경우가 많으므로, 데이터가 코드인지, 정보성 데이터인지 명확히 구분한 뒤 추출 여부 판단 • 공통 코드 테이블 : 직원 유형, 고객 유형 등 여러 개의 코드를 하나의 테이블에서 관리하는 형태 • 어플리케이션 관리 코드 : DB에 저장하지 않고 어플리케이션에서 관리하는 형태 • 사용자 인터페이스 조회 또는 코드 정보를 sQL 등으로 컬럼 데이터를 추출하는 간접적인 방법 사용 [코드 정보 누락 방지 방법] • 코드 데이터값 수집 : 테이블, 통합 코드 테이블, 어플리케이션 사용자 인터페이스를 통해 수집 • 코드성 컬럼 파악 : 해당 컬럼이 코드 저장 컬럼인지, 참조 데이터 저장 컬럼인지 구분 • 수집된 코드에 대한 사용처 파악 : 어떤 코드를 저장하는지 파악함으로써 누락된 코드 확인 [현행 코드 상세 분석] • 코드 값이 일치하는 동일한 코드 인스턴스를 가지는 코드를 찾은 뒤, 해당 코드의 인스턴스를 확인 및 비교함으로써 통합 가능한 코드 식별 • 분석할 코드가 많은 경우, 업무 기능별 코드 분류 후 분류된 단위로 코드 분석 [표준 코드 정의] • 통합 대상이 없는 코드는 현행 코드 인스턴스를 유지 • 통합 대상이 존재하고 통합 대상 코드의 코드 번호가 상이한 경우, 새로운 코드 부여
표준 코드 활용	• 향후 모든 정보 시스템은 표준 코드를 사용해야 함 • 모든 코드를 사용하지 않고 일부 코드 값만 사용할 경우, 표준 코드부터 파생된 코드를 사용 • 표준 코드로부터 파생된 코드도 반드시 표준 코드에 정의되어야 함 • 파생 코드에 코드 인스턴스를 추가해야 할 경우, 표준 코드에 먼저 정의
표준 코드 정의 시 고려 사항 ✅	• 향후 확장성을 고려하여 정의해야 하며, 일관성 유지 • 시스템 운영 중 변경되는 경우, 삭제하지 말고 중지 상태로 관리하고 새로운 코드 값을 새롭게 정의 • 현행 코드 간 변환 매칭 정보를 별도로 기록하여 향후 신규 정보 시스템 이행 시 참고

4) 표준 용어 사전 정의

항목	내용
표준 용어 사전	• 단어, 도메인, 코드 표준이 정의되면, 이를 바탕으로 표준 용어 구성 • 단어 조합, 도메인 분류, 데이터 타입 길이, 코드 값 등을 기준으로 표준 적용 검토 • 업무에서 자주 사용하는 단어의 조합 • 전사적으로 사용하는 엔터티와 속성을 대상으로 표준 단어 사전에 정의된 단어를 조합하여 정의 [표준 용어 관리 기준] • 표준성 : 동일한 용어를 동일한 의미로 이해할 수 있도록 함 • 일반성 : 지나치게 업무 관점으로 정의되면 안 됨 • 업무 지향성 : 업무 범위 내에서 약어나 별도 정의하여 사용 [표준 용어 작성 형식] • 용어 사전은 엔터티 용어사전과 속성 용어사전을 구분하여 정의 및 관리 • 논리명(한글명), 물리명(영문명)을 가지며, 용어 범위 및 자격 형식 등 설명 필요
표준 용어 정의	[현행 용어에 대한 표준 단어 및 표준 용어 정의] • 현행 용어를 분할하여 구성 단어 도출 후, 해당 단어와 유사 단어 검색 • 유사 단어 중 표준 단어를 찾아낸 뒤 각각 현행 구성 단어에 표준 단어를 조합 → 표준 용어가 도출됨 [표준 단어에 대한 도메인/코드 정의] • 현행 용어가 어떤 표준 도메인과 관련되었는지 찾고, 해당 표준 도메인을 표준 용어에 적용
표준 용어 정의 시 고려 사항 ✅	• 데이터 표준 원칙에서 정의한 한글명, 영문명의 허용 길이를 넘으면 안 됨 • 영문명의 허용 길이가 문제라면, 한글명을 변경하거나 재조합하여 새롭게 등록 • 생성된 표준 용어가 너무 길다면 2개의 표준 용어를 복합하여 생성

3. 데이터 표준 확정

1) 데이터 표준 확정 ✅

항목	상세 내용
데이터 표준 검토 계획 수립	데이터 표준에 대한 검증 기준 : 유일성, 완전성, 정확성, 범용성
데이터 표준 검토	• 검토 기준 및 대상 산출물 준비 → 검토 참여 대상자에게 배포 • 검토 관련 장소, 시간, 준비 장비 등 제반 사항 점검 및 담당자별 역할 주지시킴 • 진행자는 이슈 목록을 정리하고 일정 내 마칠 수 있도록 함 • 검토 세션이 종료되면 세션별 결과 정리 • 검토 결과 정리 후, 데이터 표준 대상별 보완 사항 작성
데이터 표준 보완 및 승인	• 검토 결과, 보완 목록, 보완 사항이 반영된 데이터 표준을 준비하고 배포 • 데이터 표준 반영 여부 확인 및 미반영 사유가 있을 시, 타당성 검토 • 보완 사항이 모델에 모두 반영된 것을 확인하고 전사 데이터 관리자의 승인 받음

표준 단어와 표준 용어 간의 정합성 검토
데이터 표준별 필수 입력 사항 확인
표준 용어 간 유사 용어 검토

2) 데이터 표준 공표

데이터 표준 배포
데이터 표준 교육

[3장] 데이터 표준 관리

✔️ 데이터 표준 관리 업무 프로세스 ✅

데이터 표준 변경에 따른 영향도 분석 프로세스
데이터 표준 변경 관리 프로세스
데이터 모델 변경 프로세스

✔️ 데이터 표준 관리 프로세스 구성 요소 : 프로세스, 태스크, 역할, 담당 업무

프로세스
태스크
- 표준 신규/변경 요청 : 업무 담당자는 데이터 담당자에게 요청
- 표준 준수 검토 : 요청된 사항에 대해 표준 준수 여부를 검토하고 업무 담당자에게 피드백 제공

역할 및 담당 업무 ✅

역할	담당 업무
업무 담당자	• 표준 신규 및 변경 요청 • 데이터 관리자로부터 지시 받은 변경 내용 적용
데이터베이스 관리자	• 데이터 관리자로부터 변경 표준 사항에 대한 변경 영향 파악 협조 및 평가서 작성 • 데이터 관리자로부터 지시 받은 변경 내용 적용 • 테스트 및 검증 • 사용자 반영 결과 통보
데이터 관리자	• 업무 담당자로부터 요청 받은 신규 및 변경사항 검토 및 표준 준수 여부 체크 (표준 변경으로 인한 변경 영향도 평가) • 신규/변경 영향도 분석 및 보고 후 변경 계획 수립 • 준수 여부 체크 후 메타 DB에 표준 등록 • 메타 DB에 등록 완료 후 신규 및 변경 표준 배포 • 업무담당자 및 데이터베이스 관리자에게 변경 작업 지시 후 변경 작업 수행 결과 확인 • 여러 업무 시스템 간 표준 변경으로 인한 업무 조정 역할 수행 • 표준 준수 여부 검토 • 모델 변경사항을 데이터 모델에 반영
전사 데이터 관리자	• 전사 관점에서의 표준 가이드 자문 및 제시

[데이터 아키텍처 준전문가(DAsP)] 과목 2. 데이터 요건 분석 (2)

알밤바 — Sat, 14 Mar 2026 23:14:19 +0900

[3장] 정보 요구사항 분석

1. 분석 대상 정의

1) 현행 업무 분석 대상 정의

항목	내용
분석 대상 자료	• 현행 업무 흐름도 • 현행 업무 설명서 • 현행 업무 분장 기술서
분석 대상 업무 영역 선정	• 분류 기준에 따라 현행 업무 목록 작성 • 분류 기준 : 통상적으로 현행 업무 기능 분해도의 단위 업무 또는 업무 분장상의 구분 등을 의미

2) 현행 시스템 분석 대상 정의

항목	내용
분석 대상 현행 시스템 선정	• 업무 분석 프로젝트의 수행범위를 정확히 파악하는 것이 선행되어야 함 • 업무 영역x현행 시스템 매트릭스를 바탕으로 업무 영역별 분석 대상 시스템 목록 작성
분석 대상 현행 시스템 관련 자료	[자료 항목] • 현행 시스템 구성도 • 현행 시스템의 분석, 설계 및 개발 보고서 • 화면, 장표 및 보고서 레이아웃 • 현행 시스템 테이블 목록 및 테이블 정의서 • 프로그램 목록 • 사용자 및 운영자 지침서 • 시스템 지원 및 유지보수 이력 • 시스템 개선 요구사항 등 [수집된 문서 평가 기준] • 유용성 : 문서 활용 가능성 여부 • 완전성 : 문서 내용에 누락된 부분이 없는지의 여부 • 정확성 : 문서 내용이 현재 시스템과 일치하는지의 여부 • 유효성 : 문서가 최신의 내용을 반영하고 있는지의 여부
추가적인 분석 대상	• 데이터 뷰는 전체적인 정보 중에서 일부를 바라보는 관점을 나타냄 • 사용자 뷰가 종합되어 나타나는 것이 화면, 수작업 파일, 수작업/전산 양식, 보고서 등의 레이아웃
분석 단계	• 현재 상태 파악 및 요구 정의 • 문제 해결과 구현될 시스템의 목표 도출
명세서 작성 과정	• 완성될 소프트웨어가 어떤 기능을 가져야 하는지 정확히 기술 • 기술적 요구와 구현/운영 측면에 있어서 제약 조건 명시 • 개발자와 사용자각 합의한 성능에 관한 사항 명시 • 명세서는 사용자와 개발자의 계약을 나열한 문서

2. 정보 요구사항 상세화

현행 업무 영역 및 시스템 관련 자료에 대해 분석하고 사용자의 정보 요구사항을 보완
비기능적 정보 요구사항을 포함하여 정보 요구사항 정의서 보완

1) 기능적 정보 요구사항

외부 요소가 직접적 상호작용을 통해 시스템에 요구하는 기능 또는 서비스
시스템이 외부의 데이터나 명령을 받아들여 어떤 반응을 하는지 기술해야 함

2) 비기능적 정보 요구사항

시스템이 수행하는 기능 이외의 사항
시스템이 만족시켜야 하는 제약 조건 (기술적 제약 조건, H/W, S/W와 관련된 제약 조건)
시스템이 반드시 만족시켜야 하는 주요 성능 척도 : 반응 시간, 저장 능력, 동시 처리 능력 등
요구분석 이후 설계 단계에서 결정해야 할 언어나 플랫폼, 구현의 선택을 까다롭게 할 수 있음
비기능적 요구가 만족되지 못하면 시스템 자체가 쓸모없게 될 수 있기에 기능적 요구보다 중요
신뢰성, 확장성, 이식성, 보안 중요

3) 프로세스 관점의 정보 요구사항 상세화

✔️수행 절차

수행 작업	내용
프로세스 분해/상세화	• 단위 업무 기능별 하향식으로 프로세스 분해 및 도출 • 프로세스 계층도 및 프로세스 정의서 작성
정보 항목 도출 및 표준화	• 기본 프로세스별 정보 항목 정리 • 정보 항목에 대한 표준화 정리 • 정보 항목 목록 정의
정보 항목별 통합성, 분리성 여부 검토	• 프로세스별로 관리되는 정보 항목 분류 • 정보 항목별 동음이의, 이음동의 존재 여부 파악 • 통합/분리 여부 검토 후 최종 정보 항목 목록 정의

✔️ 프로세스 분해/상세화

항목	설명
프로세스 분해	• 하위에 더 이상 업무 기능을 포함하지 않는 단위 업무 기능으로부터 점진적으로 수행 • 단위 업무 기능별로 상세하게 분해하지 않고, 업무 전체 단위에 대해 프로세스 분해 수준에 맞춤 • 업무 기능 계층도를 단위 업무 기능 수준까지 분해한 후 프로세스 도출
프로세스 분해 정도	• 업무적인 특성을 고려하여 3차 수준까지 분해 • 업무 활동 분해의 근본 목적은 최종적으로 기본 프로세스의 도출에 있음 • 초기 작업에는 도출된 프로세스를 균형있게 분해하는데 주의함
프로세스 명칭	• 명명규칙을 준수하여 명명하되, 업무 용어를 그대로 사용하고 이름만으로 파악할 수 있어야 함
프로세스 계층도 ✅	• 기본 프로세스를 도출하기 위해 작성하는 것임 • 프로세스 계층도의 모듈성이 확보되기 위한 분해 기준은 응집도가 높을수록, 결합도가 낮을수록 분석의 복잡도와 모호성이 감소됨 • 높은 응집도 (Cohesion), 낮은 결합도 (Coupling)를 유지하도록 모듈성 확보가 중요 • 일반적으로 상위 프로세스를 포함하며, 하위 프로세스가 7개를 초과하면 상위 프로세스를 분리하는 것을 고려 • 프로세스 정의서 : 프로세스와 기본 프로세스를 함께 기술하는 양식 (데이터 사용 항목은 기본 프로세스에서는 반드시 작성해야 함) • 이미 작성된 계층도를 재검토하여 모든 업무 요건과 규칙이 반영되었는지 확인하고 조정 • 현 수준의 프로세스 계층도를 더욱 상세하게 분해하여 업무 최소 단위인 기본 프로세스까지 도출해냄
정보 항목 도출 및 표준화	• 도출한 기본 프로세스 별로 등록(C), 조회(R), 변경(U), 삭제(D)로 구분 • 기능에 따라 구분된 프로세스별로 정보 요구사항 정의서 및 업무 조사서 상의 내용을 파악하여 관리하고자 하는 항목 도출 • 서술식 자료에서 명사형 단어를 파악하면 정보 항목의 대상이 되는 경우가 많음 • 명명 규칙을 준수하여 명명하되, 업무 용어를 그대로 사용하며, 명사형으로 기술 • 도출된 정보 항목에 대해 그룹화하여 정보 항목 군으로 구분하고 정보 항목 목록 작성
정보 항목별 통합성/분리성 여부 검토	• 정보 유형/항목별로 전사 관점에서의 통합/분리 여부 검토 • 동일한 정보 통합 시, 정보 항목의 관리가 용이하고 통합 정보 유형으로 수용 가능함 • 무리한 통합으로 인한 모호성 존재와 관리 부족으로 통합의 의미 상실 • 통합 작업 후 정보 항목 목록에 대한 통합성 여부를 기재하고 최종 정보 항목 목록 작성

4) 객체지향 관점의 정보 요구사항 상세화

항목	내용
유스케이스 (Use Case) 다이어그램 ✅	• 시스템에서 제공해야 하는 기능이나 서비스를 상세하게 그린 다이어그램 • 사용자와 시스템 사이의 상호작용을 중심으로 나타냄 • 실제 내부의 비즈니스 로직이 아닌 사용자가 수행하는 기능을 파악하고 싶을 때 작성 • 프로젝트를 시작할 때나 제품의 요구사항 명세서를 작성하는 요구분석 단계에서 주로 그림 • 액터(Actor): 시스템과 상호작용하는 외부 엔티티(사람이나 시스템, 하드웨어), 이름과 설명 필요 • 유스케이스(Use case): 액터에게 보이는 시스템의 기능과 외부 동작 - 지식이 없는 사용자와도 쉽게 의사 전달을 위해 자연어로 씀 - 유스케이스 이름, 참여 Actor, 시작 조건, 사건 흐름, 종료 조건 포함 • 액터, 유스케이스, 시스템 범위가 표현됨 (클래스 간의 관계 표현x)
액터와 유스케이스 간의 관계	• 확장(Extend) : 하나의 유스케이스가 다른 유스케이스의 행동을 추가함에 따라 나타나는 관계 - 표현) 점선 화살표, <<extend>> • 포함(Include) : 하나의 유스케이스가 다른 유스케이스를 사용하는 것을 나타내는 관계 - 표현) 점선 화살표, <<include>> • 참가(Commuicate) : 액터가 어떤 유스케이스에 참가함을 나타내며, 액터와 유스케이스 사이의 유일한 관계 - 유스케이스 안에서 일어나는 이벤트를 순서대로 기술하면 시스템 내부에서 일어나는 작업을 더 잘 이해할 수 있음
확장/포함 관계의 차이점	• 확장 관계 : 도움말, 오류, 기타 예외적인 조건 처리 • 포함 관계 : 한정된 개수의 유스케이스들이 공통으로 가지는 기능을 유스케이스로 나타낼 때
유스케이스 상세화	• 사건 흐름을 구조화하는 작업으로 모든 선택 및 대안 흐름을 기술 • 관련은 있지만 사건 흐름에 고려되지 않는 정보 요구사항을 특별요구사항으로 정의 • 정상적인 흐름 기술 후 예외 사항에 대한 사건 흐름을 기술하며 아래의 내용 기술 - 개략적인 설명 - 사건 흐름 - 사전/사후 조건 - 비기능적인 정보 요구사항 - 주된 사건 흐름에 대체될 수 있는 흐름 - 예외 처리 사항
클래스 다이어그램 작성	• 정의 :시스템을 구성하는 클래스의 구조를 나타내고 객체들의 공통 구조와 동작을 추상화 • 목적 : 시스템 구현 시, 어떤 클래스가 필요한지 파악하고 클래스 사이의 관계를 나타냄 • 구성 요소 : 객체, 클래스, 속성, 오퍼레이션, 연관 관계 • 의미 : 객체지향 프로그램의 골격 (클래스 정의)을 나타냄 [엔터티 클래스 도출] • 명사 및 명삭구를 후보 객체로 선정하고 모호한 의미 제거 • 이음동의어/동음이의어를 고려하고 문제 영역과 관련 없는 것을 제거 • 유사한 구조와 행위를 가진 객체들을 그룹화 [관계 및 클래스 도출] • 관계 : 관심 있는 연결을 나타내는 클래스 간의 관계 • 클래스 간의 집단화 관계를 식별하고 명명함 [속성 정의] • 클래스가 나타내는 객체의 특성을 의미 • 속성 이름은 속성이 가지고 있는 정보를 명확하게 지정하는 명사로 해야 함 [클래스 간의 관계] • 연관관계(association) : 클래스 사이의 관계는 링크로 나타냄 (선) • 역할(role) : 연관관계 표시 선분 끝에 역할 표시 (has, exist, rent) • 다중도(multiplicity) : 숫자로 표현, 연관된 링크 갯수, 는 다수를 의미 • 전체/부분 관계(aggregation)* - 전체 개념의 클래스 : Dictionary - 부분 개념의 클래스 : File - 일대다인 경우가 많으며, 다이아몬드로 표시 [일반화] • 일반화된 개념의 클래스와 더 구체적인 개념의 클래스 사이의 관계 • 공통 속성과 오퍼레이션을 사용하기 위해 상속 개념으로 클래스를 구성
순서 다이어그램	• 정의 : 시스템 동작을 정형화하고 객체들의 메시지 교환을 시각화 • 목적 : 참여 객체(participating object)를 추가로 찾아내고, 객체 사이의 상호작용 파악 • 구성 요소 : 액터(왼쪽), 객체, 메시지(이름 있는 화살표), 수직선(시간의 흐름) • 의미 - 클래스가 가져야 할 오퍼레이션을 파악하는데 사용 - 객체들 사이의 통신 패턴이며, 사용 사례의 이벤트 흐름을 나타냄
상태 다이어그램	• 정의 : 객체가 갖는 여러 상태와 상태 사이의 전환을 표현 (상태 : 객체가 만족하는 조건) • 목적 - 단일 객체의 동작을 나타냄 - 객체의 상태 변화를 점검하며 빠진 오퍼레이션 점검 - 솔루션 도메인 객체 표현 • 구성 요소 : 원 - 객체의 상태 / 화살표 - 전환(transition) • 의미 : 외부 사건의 결과로 일어나는 단일 객체의 상태 변화에 초점을 둠 (객체의 동작을 구체화)
액티비티 다이어그램	• 액티비티 : 시스템에서 수행되는 작업(오퍼레이션의 집합), 클래스의 메소드 • 정의 - 시스템을 액티비티로 표현 - 액션 상태인 상태 다이어그램 - 액티비티와 전환(transition) 사이의 제어 흐름 • 구성 요소 - 둥근 사각형 : 액티비티 - 화살표 : 다른 액티비티로 전환 - 동기 막대 : 제어 흐름 동기화 - 다이아몬드 : 선택 분기 - 시작, 종료

3. 정보 요구사항 확인

1) 수행 절차

분석 결과 도출된 산출물에 대해 재검토 기준 정의 및 계획 수립
완전성, 정확성, 일관성, 안정성 등 다양한 측면에서 재검토
추가/보완 사항 발견 시 문서로 정리 후, 해당 산출물에 추가 반영 여부를 확인하고 미반영 시 사유의 타당성 검토

2) 수행 작업 내용

수행 작업	상세 내용
재검토 계획 수립	• 재검토 대상이 되는 분석 결과 및 정보 요구사항 정의서 산출물 확인 • 대상 산출물 별로 재검토 기준(체크리스트) 정의
재검토 실시	• 재검토 계획서 작성 및 승인 • 재검토 대상 산출물 준비 및 배포와 재검토 담당자별 역할 분담 • 업무 영역별로 재검토 대상 산출물 재검토
보완 결과 확인	• 재검토 결과를 토대로 업무 영역별로 산출물 보완 • 재검토 결과 반영 여부 확인 및 미반영 사유 검토 • 정보 요구사항 정의서의 안정성 분석 • 재검토 결과를 토대로 보완 목록 수정

3) 수행 작업 지침

항목	내용
재검토 계획 수립	[재검토 대상] • 정보 요구사항 정의서, 정보 항목 목록, 유스케이스 정의서, 클래스 다이어그램 등 [재검토 기준] • 완전성 : 사용자의 정보 요구사항 누락 여부 확인 • 정확성 : 요구사항이 정확히 표현되었는지 확인 • 일관성 : 표준화 준수 여부 확인 • 안정성 : 추가 요구사항 변경에 따른 영향도 파악 [재검토 계획서에 포함되어야 하는 사항] • 정보 요구사항 재검토 개요 및 목적, 재검토 일자, 재검토 장소 및 시간 계획 • 재검토 참석 대상 및 재검토 업무, 참석 대상별 재검토 세부 시간 계획 • 재검토 시 준비물, 재검토 후 산출물, 지적 사항 반영 계획 수립
재검토 실시
보완 결과 확인

4) 수행 시 고려 사항

일관성 있는 기준 및 일정 수립 → 공감대 형성 중요
세션별로 해당 기준에 초점을 맞추어 수행하며, 효율성을 고려하여 참여 대상 수 선정

4. 정보 요구 분석 방법

1) 구조적 분석 방법

항목	내용
구조적 분석 관점	• 시스템을 기능적 관점에서 다룸 • 소프트웨어 시스템을 거시적 관점에서 데이터와 데이터를 처리하는 프로세스로 봄 • 데이터보다 처리, 기능을 위주로 분석 • 문제를 기능적 관점의 프로세스로 나누고, 프로세스에 어떤 입력자료와 출력자료가 필요한지 나중에 고려 • 프로세스는 추상적인 개념부터 점차적으로 세분화함
구조적 분석 방법	• 전통적인 데이터 처리 시스템을 개발하는데 적절한 기법 • 목표 : 개발될 시스템의 모형을 만드는 것 - 프로세스와 사이의 데이터 흐름 파악 중요 - 자료 흐름과 가고오 절차를 그림 중심으로 표현 - 시스템을 구성하는 요소들의 상호 작용과 기능을 나타냄
구조적 분석 방법의 가정	시스템의 기능 및 프로세스가 무엇인지 생각 • 시스템이 무엇을 하는지 • 기능이나 프로세스는 입력 자료 흐름을 출력 자료 흐름으로 변환하는 액티비티 하향식으로 문제를 다룸 • 외부 인터페이스를 먼저 분석 → 상위층 기능 → 하위층 기능 순서로 문제 분할
구조적 분석 방법의 작업 순서	배경도 작성 → 상위 자료 흐름도 작성 → 하위 자료 흐름도 작성 → 자료 사전 작성 → 소단위 명세서 작성
구성요소	• 프로세스 : 프로세스는 대부분 원 또는 둥근 사각형으로 표기 - 프로세스의 이름을 안에 씀 • 자료 흐름 : 두 프로세스 사이의 자료 경로는 화살표로 표기 - 화살표 위에 자료의 이름을 씀 • 파일 또는 저장소 : 정보의 저장소는 한쪽이 열린 직사각형으로 표시 - 파일에 접근하는 프로세스는 선으로 연결하여 표시 - 파일의 이름을 안에 표시 • 자료 출처와 도착지 : 직사각형 안에 이름 기재
최상위 자료 흐름도 (배경도)	• 작업은 시스템 경계의 입출력 식별로부터 시작 - 최상위 단계의 입출력은 시스템 경계를 정의하는 것으로 분석의 대상이 무엇인가를 결정 • 최상위 흐름도를 여러 부 프로세스들로 구체화 - 자료원과 도착지 나타낼 필요 없음 - 각 프로세스는 고유 번호가 붙여짐 • 상위 자료 흐름도 구체화 - 하위 계층 자료 흐름도에서 프로세스 번호는 바로 위 계층의 프로세스 번호에 고유 번호를 붙이면 됨
프로세스	• 원으로 표현, 입력 자료 흐름을 출력 자료 흐름으로 변환 • 처리 이름 : 하는 일을 의미하는 단어나 간단한 문장으로 동사구문 사용 - 동사형 명사와 단일 직접 목적어 • 레벨별 고유번호 주어짐 - 최하위 프로세스는 차후 소단위 명세의 대상

✔️ 자료 흐름도의 작성 원칙

항목	내용
자료 보존의 원칙 (Conservation Rule)	• 출력 자료 흐름은 반드시 입력 자료 흐름을 이용해 생성된 것이어야 함 ex) 사과가 주스에 들어가면 사과주스가 나와야 함
최소 자료 입력의 원칙 (Parsimony Rule)	• 출력 자료 흐름을 산출하는데 반드시 필요로 하는 최소의 자료 흐름만 입력해야 함
독립성의 원칙 (Independence Rule)	• 자신의 입력 자료와 출력 자료 자체에 대해서만 알면 됨 • 그 자료들이 어디에서 와서 어디로 가는지 알 필요 없음
지속성의 원칙 (Persistence Rule)	• 처리는 항상 수행하고 있어야 하며 일시적으로 어떤 자료 흐름을 기다릴 때를 제외하고는 다시 시작하거나 멈춰서는 안됨
순차 처리의 원칙 (Ordering Rule)	• 입력 자료 흐름의 순서는 출력되는 자료 흐름에서도 지켜야 함
영구성의 원칙 (Permanence Rule)	• 자료 흐름의 자료 항목은 처리된 후에 제거되지만, 자료 저장소의 자료는 입력으로 사용해도 제거되지 않음
자료 변환의 원칙 (Nature of Change)	• 자료 본질의 변환 : 입력 자료 흐름에 편집, 계산 등을 해 출력 자료 흐름을 산출 • 자료 합성의 변환 : 여러 입력을 처리하여 하나의 출력되는 자료 흐름을 산출

과도하게 세분화된 프로세스 → 적당한 세분화 필요
자료 흐름의 올바른 이름 표기

2) 객체 지향 분석 방법

데이터와 데이터에 적용될 기능을 함께 추상화하는 방법
시스템에 존재하는 객체를 먼저 찾아내고, 객체 안에 어떤 자료와 오퍼레이션이 필요한지 알아내야 함
객체 사이에 존재하는 여러 가지 관계들의 파악이 중요

3) 요구 분석 명세서

항목	내용
요구 분석서가 갖추어야 할 사항	• 사용자, 개발자가 모두 쉽게 이해해야 함 • 기술된 조건은 쌍방이 모두 동의한 것이어야 함 • 제안된 시스템에서 수행될 모든 기능을 정확히 기술하고 모든 제약 조건을 명시 - 반응 시간, 목표 하드웨어, 비용 한계, 사용자 특성, 언어 • 시스템 인수를 위한 테스트 기준이 있어야 함 • 시스템 품질 측정 방법이 있어야 함
요구 분석의 문제점	• 사용자의 부정확한 요구 표명 • 잦은 요구 변경 • 커뮤니케이션상의 장애 • 시스템의 복잡도
명세서의 평가	[평가 기준] • 무결성과 완벽성 • 일관성 • 명확성 • 기능적 • 검증 가능성 • 추적 가능성 및 변경 용이성 [평가 방법] • 검토 회의 • 테스트 사례 작성 • 프로토타이핑 도구나 CASE 도구 사용

[4장] 정보 요구 검증

1. 정보 요구 상관관계 기법

도출된 정보 요구사항을 다른 영역 (기능, 프로세스, 조직 등)과 비교, 분석함으로써 정보 요구사항의 도출이 효과적으로 이루어졌는지 파악할 수 있음

1) 주체별 분류

항목	내용
요구사항 분석가 수행	• 요구를 수집/분석한 주 담당자를 기준으로 검토 기준 항목을 마련 후 분석 수행 • 정보 요구사항을 도출한 분석가에 의해 수행되므로 객관성 저하의 문제점이 발생할 수 있음 • 도출 절차 및 업무팀과의 의사소통이 원활하므로 상관분석이 원활하게 진행될 수 있음 • 요구 사항 분석가의 업무 이해도가 높으므로 정확한 분석 가능성이 높음
품질보증 팀 수행	• 요구사항 분석가보다 업무 이해도가 낮으나 상관분석 작업의 수행을 통한 업무 이해도를 높일 수 있으며, 전체적인 인터페이스 검증에 용이 • 낮은 업무 이해도로 인해 분석을 통한 단점을 지적하여 수정하기 어려움
외부 감리 수행	• 업무 파악에 한계가 있으나 제3자의 시각으로 검토 가능 • 상관분석의 객관성을 극대화할 수 있음 • 프로젝트 내부 인력 지원이 효과적이지 않을 경우, 잘못된 분석 결과를 초래할 수 있음
정보 요구/어플리케이션 상관분석 ✅	• 정보 요구사항에서 도출된 항목과 어플리케이션 영역에서 도출된 항목으로 매트릭스 작성 • 기본 프로세스의 액션 (C:생성, R:조회, U:수정, D:삭제) 정의 • 여러 개의 액션 발생 시, '우선순위 ‘C>D>U>R’에 따라 하나만 기록 • 모든 정보 항목이 모든 기본 프로세스에서 사용되었는지, 또는 모든 정보 항목을 사용하는지 확인 • 2가지 객체 중 하나의 누락은 분석이 가능하지만, 정보 항목과 기본 프로세스가 모두 누락인 경우 분석 불가
정보 요구/업무 기능 상관분석	• 정보 요구사항과 비즈니스 아키텍처에서 도출된 업무 기능을 비교하여 분석 • 업무 기능별 필요 정보 항목의 누락 여부의 확인 중요 • 행 : 정보 요구사항에서 도출된 내용 • 열 : 가치 사슬 분석 등 기법을 통해 도출된최하위 수준의 전사 업무 기능 • 생성/수정/삭제 : C로 표시 • 검색 : U로 표시 • 아무 관련 없는 것은 빈칸

2. 추가 및 삭제 정보 요구사항 도출

1) 정보 요구/어플리케이션 상관분석

어플리케이션 충족도 분석 매트릭스
- 정보 항목을 생성하는 기본 프로세스가 반드시 존재해야 함
- 상태를 종료시키는 기본 프로세스가 존재해야 함
- 생성된 항목은 조회, 수정, 삭제 액션 중 하나가 발생해야 함
- 하나의 정보 항목의 프로세스의 합은 7개를 초과하지 않아야 함
- 수작업 정의나 조회 전용의 특별 정의된 기본 프로세스 외에는 반드시 생성, 수정, 삭제 액션 중 하나를 수행해야 함

매트릭스 분석 ✅

점검 내용	분석 결과	조치 사항
기본 프로세스가 사용(CRUD)하는 정보 항목이 없음	정보 항목 누락	정보 항목 도출
	기본 프로세스 필요 없음	기본 프로세스 삭제
	기본 프로세스가 분석 대상 업무 영역에 속하지 않음	해당 업무 영역으로 이동
정보 항목이 7개 이상의 기본 프로세스에서 사용됨	정보 항목이 너무 큼	정보 항목의 세분화 필요
정보 항목을 생성하는 기본 프로세스가 없음	기본 프로세스의 누락	기본 프로세스의 도출
	정보 항목이 필요 없음	정보 항목 삭제
	정보 항목이 분석 대상 영역에 속하지 않음	해당 업무 영역으로 이동
정보 항목을 생성하는 기본 프로세스가 2개 이상 존재	기본 프로세스 중복	기본 프로세스 합성
엔터티를 삭제하는 기본 프로세스가 없음	기본 프로세스의 누락	기본 프로세스의 도출
	업무에 삭제가 존재하지 않음	전산상의 오류인 경우에 삭제가 필요한지 확인
	기본 프로세스가 분석 대상 업무 영역에 속하지 않음	해당 업무 영역으로 이동
정보 항목을 삭제하는 기본 프로세스가 2개 이상 존재	기본 프로세스의 중복	기본 프로세스 합성
정보 항목이 생성만 되고 사용되는 곳이 없음	기본 프로세스의 누락	기본 프로세스의 도출
기본 프로세스가 정보 항목을 조회만 함	기본 프로세스가 아님	모듈 검토
기본 프로세스가 여러 액션을 수행함	정의된 기본 프로세스가 너무 큼	프로세스 추가 분해

2) 정보 요구/업무 기능 상관분석

매트릭스 분석
- 모든 업무 기능은 정보 항목과 연관이 있는지?
- 각 정보 항목은 한 번 이상의 ‘C(Create)’를 갖는지?
- 생성된 정보 항목은 다른 업무 기능에 의해 ‘U(Update)’가 사용되는가?
- 단순 조회인지?
정보 항목과 연관성이 없는 업무 기능은 기능 도출에 대해 재검토 필요
정보 항목에 매핑되지 않는 업무 기능은 협의하여 추가사항이 있을 경우 신규로 추가

3) 정보 요구/조직 기능 상관분석

매트릭스 분석
- 모든 조직은 정보 항목과 연관이 있는지?
- 각 정보 항목은 한 번 이상의 ‘C(Create)’를 갖는지?
- 생성된 정보 항목은 다른 조직 기능에 의해 ‘U(Update)’가 사용되는가?
- 단순 조회인지?
정보 항목의 활용도를 파악할 수 있으며, 항목의 수가 많은 경우 물리 모델링 단계에서 성능/활용 측면의 모델링 기법을 적용함으로써 정보 활용의 효율성을 기해야 함
정보 항목을 생성하는 조직이 여러 개일 경우, 관리의 복잡성 때문에 향후 문제 발생의 소지가 있으므로 데이터 관리 주체 선정에 주의해야 함

3. 정보 요구사항 보완 및 확정

정보 요구 보완
- 분석을 통해 파악된 추가 및 삭제 요구사항에 대해 담당자와 미팅을 통해 정보 요구 목록 보완
정보 요구 확정
- 보완된 사항에 따라 재검토를 하며 추가 반영사항에 대해 최종 정보 요구 목록에 대해 확정

[데이터 로그 설계] 5. 실제 서비스 이벤트 로그 설계 예시 (토스플레이스)

알밤바 — Thu, 12 Mar 2026 18:10:37 +0900

요즘 식당이나 카페에 가면 토스 단말기가 많이 보인다. 특히 페이스 페이 (Face Pay)로 얼굴 인식하면 실물 카드 없이도 결제가 가능하다보니 편리해서 종종 활용하고 있다. (엄청 편함 )

최근 몇 년 간 온라인 결제는 많은 서비스가 생겨나고 활성화되었다. 하지만 실질적으로는 오프라인에서 결제가 더 많이 이루어지고 있기 때문에, 오프라인 결제는 어떻게 변화할지 궁금했었다.
마침 토스에서 오프라인 비즈니스로 확장하여, 토스 단말기 서비스를 운영하는 것을 보고 오프라인 시장에서 어떤 서비스를 제공할지, 또 어떻게 데이터를 수집하고 관리할지가 궁금해졌다.

그래서 토스 단말기를 사용하고 있는 카페에 방문해서 직접 경험을 한 후, 이벤트 로그를 설계하는 연습을 해보았다.

이전 데이터 로그 설계 포스팅
[데이터 로그 설계] 1. 이벤트 택소노미 (Event Taxonomy) 구조 이해하기
[데이터 로그 설계] 2. 이벤트 택소노미(Event Taxonomy)의 중요성
[데이터 로그 설계] 3. 이벤트 택소노미 기반 로그 설계 방법 (With. Amplitude)
[데이터 로그 설계] 4. 실제 서비스 이벤트 로그 설계 예시 (올리브영)

목차
1. 매장 방문 & 주제 설정
2. 문제 및 가설 정의
3. 지표 정의
4. 이벤트 발생 프로세스
5. 이벤트 택소노미 설계
6. 이벤트 로그 설계
7. 수집 로그 기반 고객 정의
8. 데이터 활용 방안

1. 매장 방문 & 주제 설정

카페에 방문하기 전에 우선 어떤 주제로 하는 것이 좋을지 고민해보았다.
토스플레이스는 '안정성'과 '확장성'을 동시에 고려하고 있었으며, 사장님의 운영 효율성을 높일 서비스를 고민하고 있었다. 고객인 사장님들이 잘 활용할 수 있도록 서비스를 제공하며, 다양한 환경에서도 문제 없이 결제가 될 수 있도록 많은 실험과 노력을 하고 있었다. 이것을 머리에 잘 새겨넣고 카페에 가서 실제 주문과 결제를 경험해보았다.

마침 토스오더를 통해 카페에서 쿠폰을 발급해줬다. 토스오더를 통해 발급된 쿠폰은 어떻게 사용하는지가 궁금했다.
카페에서 주문을 하고 쿠폰을 사용하려고 했는데, 쿠폰은 1만원 이상 주문해야 사용할 수 있어서 나는 아쉽게도 쿠폰을 사용하지 못했다.
그렇지만 혹시나 얻을 만한 내용이 있을지, 용기를 내어서 사장님께 이런 저런 이야기를 건냈다. (쿠폰은 어떻게 발급하는지 등..낯을 많이 가려서,, 큰 도전이었음..)
문득, 이 경험을 통해 '쿠폰이 있는데 적용하지 않은 고객'에 대한 인사이트도 사장님이 가지고 있으면 좋지 않을까라는 생각이 들었다. 쿠폰을 사용할 수 있는데 사용하지 못하면, 잠재 매출을 얻지 못할 수 있고, 고객의 경험이 좋지 않을 상황도 발생할 수 있기 때문이다.
그래서 사장님께 도움이 될만한 주제라고 생각하여 '쿠폰 미적용'과 관련된 주제로 결정하였다.

또 하나, 나는 주로 삼성페이를 사용하는데 생각보다 삼성페이 인식률이 떨어져서 결제까지의 시간이 오래 걸린다. 오늘도 결제 시 단번에 인식하지 못해 바로 결제를 하지는 못했다.

단말기에서 해결 가능할지는 모르겠지만, 늘 불편했던 지점이었다. 특히 네이버페이/카카오페이에서 지원하는 삼성페이가 인식률이 더 좋지 않은 곳도 있어서 이것에 대해 개선이 되었으면 하는 생각이 들었다.

사장님의 경우에도, 매번 '여기에 대보세요.'와 같은 이야기를 반복하다보니 반복되는 이야기에 운영 효율성이 떨어질 수 있다고 생각해서 이것도 주제로 생각해보았다.

→ 역시나,, 이건 찾아보니 이미 있다..! 하지만 더 개선할 수 있는 방법이 있을까..?

삼성페이 결제 인식 속도를 3배 빠르게 개선했어요 - 사장님 스토리

프론트에서 삼성페이 인식 속도가 최대 3배 빨라졌어요. 이전보다 결제 오류가 줄고 더 안정돼, 매장에서 결제를 안내하기가 훨씬 편해졌어요.

tossplace.com

[+] 네이버 커넥트 라운지에 있었는데, 직원분께서 네이버페이 단말기인 'Npay 커넥트'에 대한 사용자 경험을 물어보셨다.

화면 A, B안 2개를 보여주시면서 각 화면일 때 삼성페이 결제 시 어디에다가 폰을 갖다댈지에 대한 경험이었다.

네이버페이도 요즘 오프라인 단말기 사업 중인데, 삼성페이에 대한 화면 설계에 대해 고민하고 있는 중 같다.

그만큼 삼성페이에 대한 사용자 경험 개선이 중요해보인다!

2. 문제 및 가설 정의

쿠폰 적용을 성공한 데이터를 보면 쿠폰이 얼마나 사용되었는지에 대해 알 수 있지만, 왜 쿠폰이 사용되지 않았는지에 대해서는 자세히 파악하는데 한계가 있다.
그래서 쿠폰 적용을 실패한 데이터가 있다면 쿠폰이 사용되지 않은 이유와 개선안을 도출해낼 수 있지 않을까라는 생각이 들었다.

쿠폰을 사용하지 않은 케이스별 분석을 통해, 쿠폰을 사용하지 않은 이유를 찾고 대응 방안을 마련하자.

우선은, 내가 실제로 경험했던 '쿠폰 적용 가능 기준 금액에 미치지 못했을 상황'에 대해 정리를 해보았다.
쿠폰 미사용 이유를 단순히 '귀찮음'이 아닌, 데이터로 분석 가능한 케이스로 구체화해보았다.

[Case 1. 업셀링] 추가 주문을 하여 쿠폰 적용이 가능한 기준 금액을 맞춤
[Case 2. 유지] 쿠폰을 적용하지 않고 기존 메뉴로 결제
[Case 3. 이탈] 기존에 주문한 메뉴도 결제하지 않음

그리고 케이스별 가설을 정의해보았다.

[Case 1. 업셀링] 부족한 금액이 고객이 추가 주문이 가능한 ‘금액’ 이내라면, 유저는 쿠폰 혜택을 받기 위해 추가 구매를 할 것이다.
[Case 2. 유지] 주문 금액 대비 부족한 금액이 크거나 쿠폰의 혜택이 크지 않다면, 추가 구매를 하지 않을 것이다.
[Case 3. 이탈] 부족한 금액이 크거나 추가 할인 혜택이 없다면, 고객이 할인을 못 받는 것을 손해라고 인식하여 구매 자체를 하지 않을 것이다.

3. 지표 정의

위에서 정의한 가설을 기반으로 검증할 수 있는 지표를 정의해보자.
우선 케이스별로 대상 고객이 상이하므로, 각 케이스별 고객의 조건을 정의하고 가설을 검증할 수 있는 지표를 정의했다.
또한 정의한 지표를 기반으로 분석하여 얻을 수 있는 인사이트 및 개선 방안도 고민하여 정리해보았다.

[Case 1. 업셀링]
부족한 금액이 고객이 추가 주문이 가능한 ‘금액’ 이내라면, 유저는 쿠폰 혜택을 받기 위해 추가 구매를 할 것이다.

고객 : 쿠폰 적용 실패 이후, 메뉴를 추가하여 결제한 고객
지표
- 쿠폰 적용 실패 시, 쿠폰 기준 금액보다 부족한 금액 → 추가 주문을 하는 평균 금액 파악
- 쿠폰 적용을 위한 추가 주문 금액 & 상품 → 가장 많이 추가 주문하는 금액대 & 상품 파악
- 쿠폰 적용 실패 ~ 쿠폰 적용 성공까지의 소요시간 → 쿠폰 적용 또는 추가 주문할 메뉴를 고르는데까지 소요된 시간 파악
개선 방안
- 추가 주문을 하는 평균 금액을 파악하여, 쿠폰 적용 가능 기준 금액이 그 금액일 경우 업셀링 유도 화면 노출
- 가장 많이 추가 주문하는 금액대 및 상품을 파악하여, 이를 기반으로 추천 메뉴 노출

[Case 2. 유지]
주문 금액 대비 부족한 금액이 크거나 쿠폰의 혜택이 크지 않다면, 추가 구매를 하지 않을 것이다.

고객 : 쿠폰 적용 실패 이후, 쿠폰 없이 기존 메뉴만 결제한 고객
지표
- 쿠폰 적용 실패 시, 쿠폰 기준 금액보다 부족한 금액 → 부족한 금액의 평균 금액 파악
- 쿠폰 적용 실패 ~ 결제 화면 이동까지의 소요시간 → 쿠폰을 적용할지 고민하는 시간까지의 소요된 시간 파악
- 쿠폰 적용 실패 시간대 → 점심 시간 등 바쁜 시간대에 많이 발생했는지 파악
- 쿠폰 적용을 포기한 쿠폰 유형 → 쿠폰의 매력도 파악
개선 방안
- 쿠폰 적용을 하지 않는 쿠폰을 분석하여 쿠폰의 혜택 검토 및 재설정
- 부족한 금액을 파악하여, 쿠폰 적용 가능 기준 금액 재조정
- 또는 부족한 금액이 큰 고객군이 많은 비율을 차지한다면, 그 고객군을 대상으로 쿠폰 적용 가능 기준을 낮춘 쿠폰 발급

[Case 3. 이탈]
부족한 금액이 크거나 추가 할인 혜택이 없다면, 고객이 할인을 못 받는 것을 손해라고 인식하여 구매 자체를 하지 않을 것이다.

고객 : 쿠폰 적용 실패 이후, 결제 자체를 포기한 고객
지표
- 쿠폰 적용 실패 시, 쿠폰 기준 금액보다 부족한 금액 → 부족한 금액의 평균 금액 파악
- 쿠폰 적용 실패 ~ 주문 취소까지의 소요시간 → 쿠폰을 적용할지 고민하는 시간까지의 소요된 시간 파악
개선 방안
- 부족한 금액을 파악하여, 쿠폰 적용 가능 기준 금액 재조정
- 소요시간을 파악하여 소요시간이 길다면, 쿠폰의 유효기간을 연장하여 재방문 유도

4. 이벤트 발생 프로세스

가설과 지표를 정의했다면, 이것을 바탕으로 이벤트 로그를 설계해보려고 한다.
그 전에 실제 주문부터 결제까지 고객과 사장님이 경험하는 프로세스를 정리하며, 명확한 이벤트 발생 시점을 확인해보았다.
토스플레이스는 사장님용, 고객용 단말기 2개의 하드웨어가 실시간으로 상호작용하는 환경이므로, 2가지 단말기에서 발생하는 이벤트를 파악해야 한다.

(여러 가지 서칭을 하면서 최대한 전 프로세스를 파악하려고 했으나, 빠진 부분이 있을 수 있으니 참고 부탁 드립니다!)

단계	행동	발생 기기
1	메뉴 선택 (메인+옵션)	사장님
2	멤버십 정보 입력 화면 진입	사장님
3	멤버십 정보 입력	고객
4	멤버십 정보 화면 진입	사장님
4	멤버십 정보 화면 진입	고객
5	쿠폰 적용 (성공/실패)	사장님
6	결제 요청 및 대기	사장님
7	결제 수단 선택	고객
8	결제 진행	고객
8	결제 진행	사장님
9	결제 완료	고객
9	결제 완료	사장님

5. 이벤트 택소노미 설계

본격적으로 이벤트 로그를 설계하기 전에, 이벤트 택소노미를 구축하였다.
로그를 정의할 때 표준 용어가 정의되어야 이를 바탕으로 일관되게 이벤트 로그 명을 정의할 수 있기 때문이다.

✔️ 표기법 : 스네이크 표기법 (snake_case)
✔️ 이벤트명 구조 : {object}_{verb}

✔️ 표준 용어
1) 목적어 (object) (+ 속성명)

object
screen	화면
item	메뉴/상품
payment	결제
membership	멤버십
coupon	쿠폰
method	수단
input	(정보 등) 입력
status	(멤버십 등) 상태/현황
info	정보
request	(프로세스의) 요청
processing	(프로세스의) 진행
transaction	거래
amount	금액
btn	버튼
result	결과
success	성공
fail	실패
reason	사유
discount	할인

2) 동사 (verb)

verb
add	추가하다
update	업데이트하다
click	클릭하다
view	진입하다
submit	제출하다
apply	적용하다
complete	완료하다

3) 속성명 구조

property
_id	고유 식별자 (ID)
_nm	명칭
_cnt	수량
_amt	금액

6. 이벤트 로그 설계

앞서 정의한 가설/지표와 이벤트 발생 프로세스를 기반으로 이벤트 로그를 정의하였다.
이벤트 로그 내 필요한 추가 정보들을 수집하기 위해 속성도 함께 정의하였다.

우선, 이벤트 발생 프로세스를 기준으로 이벤트 로그를 정의하고, 각 주체와 어떤 속성이 들어가야 할지 정리하였다.
* 참고) 거래ID, 화면정보, 발생일시 등은 모든 이벤트에 필수로 들어가야 하는 속성이라 표 내 속성에는 따로 기입하지 않았다.

단계	행동	발생 기기	이벤트 명	속성
1	메뉴를 추가하다	사장님	item_add	- 메뉴ID, 메뉴명
2	메뉴 정보를 업데이트하다	사장님	item_update	- 메뉴ID, 메뉴명 - 업데이트 유형 - 옵션ID, 옵션명 - 변경된 수량
3	결제 버튼을 클릭하다	사장님	payment_request_click	- 주문 상품 리스트 : {상품명, 수량, 옵션}
4	멤버십 입력 화면에 진입하다	사장님	membership_input_screen_view
4	멤버십 입력 화면에 진입하다	고객	membership_input_screen_view
5	멤버십 정보를 제출하다	고객	membership_info_submit
6	멤버십 상태 화면에 진입하다	사장님	membership_status_screen_view	- 고객 정보 - 보유 쿠폰 : {쿠폰ID, 쿠폰명, 사용 가능 여부, (적용) 할인 금액, (미적용) 미적용 이유, (미적용) 부족 금액} - 총 주문 금액 - 총 할인 금액 - 총 결제 금액
6	멤버십 상태 화면에 진입하다	고객	membership_status_screen_view
7	쿠폰을 클릭하다	사장님	coupon_click	- 고객 정보 - 선택한 쿠폰 : {쿠폰ID, 쿠폰명, 할인 금액}
8	쿠폰을 적용하다	사장님	coupon_apply	- 고객 정보 - 적용 쿠폰 : {쿠폰ID, 쿠폰명, 할인 금액} - 총 주문 금액 - 총 할인 금액 - 총 결제 금액
9	결제 요청 화면에 진입하다	사장님	payment_request_screen_view	- 고객 정보 - 주문 상품 리스트 : {상품명, 수량, 옵션} - 적용 쿠폰 : {쿠폰ID, 쿠폰명, 할인 금액} - 총 주문 금액 - 총 할인 금액 - 총 결제 금액
10	결제 수단을 선택하다	고객	payment_method_click	- 고객 정보 - 총 결제 금액 - 결제 수단
11	결제 진행 화면에 진입하다	사장님	payment_processing_screen_view	- 고객 정보 - 총 결제 금액 - 결제 수단
11	결제 진행 화면에 진입하다	고객	payment_processing_screen_view	- 고객 정보 - 총 결제 금액 - 결제 수단
12	결제를 완료하다	사장님	payment_complete	- 고객 정보 - 총 결제 금액 - 결제 수단 - 거래 성공 여부
12	결제를 완료하다	고객	payment_complete	- 고객 정보 - 총 결제 금액 - 결제 수단 - 거래 성공 여부
13	닫기 버튼을 클릭하다	사장님	close_btn_click	- 고객 정보
14	뒤로가기 버튼을 클릭하다	사장님	back_btn_click	- 고객 정보
15	메뉴 리스트 화면에 진입하다	사장님	item_list_screen_view	- 고객 정보 - 주문 상품 리스트

[참고] 공통 속성
- 거래ID
- 화면 정보
- 발생일시
- 플랫폼 (발생 기기)

위와 같이 이벤트 로그별 정의되어야 하는 속성을 기반으로 실제로 어떤 형태로 수집이 될지를 생각하며 아래와 같이 이벤트 로그 정의서를 작성했다.
특히 속성은 어떤 형태로 들어가야 할지에 대해 고민하여 작성해보았다.

7. 수집 로그 기반 고객 정의

이벤트 로그 데이터가 수집되면, 정의한 가설을 검증하기 위해 수집한 로그를 기반으로 데이터 분석을 진행한다.
데이터가 수집하는 것에 그치지 않고, 잘 활용이 되는 것이 중요하기 때문에 실제로 수집한 로그를 어떻게 분석에 활용할 수 있을지 생각해보았다.
우선, 수집한 로그를 기반으로 내가 위에서 정의했던 케이스별 고객 군을 추출하는 조건들을 하나씩 정의하였다.

1) 쿠폰 적용 시, 쿠폰 조건 미달로 쿠폰 적용 실패 고객
= membership_status_screen_view (멤버십 상태 화면에 진입하다) 이벤트의 아래 속성 조건을 만족하는 고객
- held_coupon > is_available = False (쿠폰 적용 실패)
- held_coupon > fail_reason = amount_shortage (금액 조건 미달)

2) 업셀링 고객 : 쿠폰 적용 실패 후, 메뉴를 추가하여 결제

조건	의도
✔️동일한 거래 (transaction_id) 기준
membership_status_screen_view (멤버십 상태 화면에 진입하다) 이벤트 • held_coupon > is_available = False (쿠폰 적용 실패) • held_coupon > fail_reason = amount_shortage (금액 조건 미달)	금액 조건 미달로 쿠폰 적용을 실패한 고객을 분류하기 위함
1번 이벤트 이후, membership_status_screen_view (멤버십 상태 화면에 진입하다) 이벤트 • held_coupon > is_available = True (쿠폰 적용 성공)	업셀링 고객 파악 : 쿠폰 적용을 재시도하였고, 적용 성공한 고객을 분류하기 위함
payment_complete (결제를 완료하다) 이벤트 있어야 함	업셀링 고객 파악 : 실제 결제까지 진행되었는지 확인하기 위함
1번 이벤트의 총 주문 금액 (total_order_amt) < 2번 이벤트의 총 주문 금액 (total_order_amt)	업셀링 고객 파악 : 쿠폰 적용 성공 뿐만 아니라, 실제로 주문 금액이 늘어났는지까지 판단하기 위함

3) 유지 고객 : 쿠폰 적용 실패 이후, 쿠폰 없이 기존 메뉴만 결제한 고객

조건	의도
✔️동일한 거래 (transaction_id) 기준
membership_status_screen_view (멤버십 상태 화면에 진입하다) 이벤트 • held_coupon > is_available = False (쿠폰 적용 실패) • held_coupon > fail_reason = amount_shortage (금액 조건 미달)	금액 조건 미달로 쿠폰 적용을 실패한 고객을 분류하기 위함
payment_complete (결제를 완료하다) 이벤트 있어야 함	유지 고객 파악 : 실제 결제까지 진행되었는지 확인하기 위함
1번 이벤트의 총 주문 금액 (total_order_amt) = 2번 이벤트의 총 주문 금액 (total_order_amt)	유지 고객 파악 : 추가로 주문하지 않았는지 주문 금액을 통해 확인하기 위함

4) 이탈 고객 : 쿠폰 적용 실패 이후, 결제 자체를 포기한 고객

조건	의도
✔️동일한 거래 (transaction_id) 기준
membership_status_screen_view (멤버십 상태 화면에 진입하다) 이벤트 • held_coupon > is_available = False (쿠폰 적용 실패) • held_coupon > fail_reason = amount_shortage (금액 조건 미달)	금액 조건 미달로 쿠폰 적용을 실패한 고객을 분류하기 위함
payment_complete (결제를 완료하다) 이벤트가 없어야 함	이탈 고객 파악 : 결제를 하지 않고 이탈했는지 확인하기 위함

8. 데이터 활용 방안

위에서 정의한 데이터는 사장님용 대시보드에서 쿠폰과 관련한 여러 데이터를 확인하고, 실제 매장 운영을 개선하는 데에 활용될 것이다. 그래서 데이터가 어떻게 활용되면 좋을지 구상해보았다.

사장님용 대시보드와 매장 운영 개선 방안에 대해 큰 틀에서 생각했다.

[1] 사장님용 대시보드

사장님용 대시보드에서는 어떤 지표가 어떻게 노출될지 고민해봤으며, 간단히 목업 이미지도 만들어보았다.

쿠폰 현황 : 쿠폰 보유/사용/실패 고객 (+놓친 예상 매출액)
쿠폰 적용 실패 사유
쿠폰 적용 실패 후 행동
Case별 상세 데이터 분석
- 부족한 금액 평균
- 추가 주문 금액 평균
- 추가 주문 상품 순위
- 소요시간
- 쿠폰 유형 등
케이스별 재방문률 등 지속 관리를 위한 지표
전체 매출 대비 쿠폰으로 할인 받은 금액 비율 등

[2] 매장 운영 개선 방안

업셀링 유도 화면 (+메뉴 추천) 개발
쿠폰의 혜택 검토 및 재설정
쿠폰 적용 가능 기준 금액 재조정
고객 정보에 고객 세그먼트 (업셀링/유지/이탈) 정보 제공

실제 서비스인 토스플레이스의 단말기 서비스를 기반으로 이벤트 로그를 설계했다.
이벤트 로그 설계가 생각해야 할 부분이 굉장히 많다는 것을 이번 포스팅을 작성하면서 다시 한 번 깨달았다.
아무래도 오프라인 서비스이며, 상호작용이 있는 서비스이다보니 더욱 고려해야 할 사항들이 많이 있었다.

직접 사용해볼 수 없는 서비스이다보니 관련 정보를 찾는 것에도 많은 시간이 소요되었고, 그것만으로도 알 수 없는 것이 있어서 내 생각을 기반으로 로그를 정의했다.
그래서 중간중간에 많은 허점이 있을 것이다. 예를 들어, transaction_id가 어디까지 유효한지 등 서비스 내 환경과 데이터 규격을 잘 알지 못하기에 보완이 필요한 부분이 많을 것이다.

그럼에도 이 서비스로 로그 설계를 해야 겠다는 마음을 먹고, 직접 매장에 방문해 경험해서 주제 설정하고 로그까지 설계한 이 과정을 해냈다는 것이 만족스럽다.
부족한 부분도 많지만, 실제 비즈니스를 고려하며 어떻께 수집한 데이터를 활용할지까지 고려하면서 설계하며 많은 것을 배울 수 있었다.

다음엔 어떤 서비스를 해볼까!

혹시나 포스팅에서 문제가 있거나 피드백이 있다면 언제든 환영입니다!!

[데이터 아키텍처 준전문가(DAsP)] 과목 2. 데이터 요건 분석 (1)

알밤바 — Sun, 8 Mar 2026 16:28:45 +0900

[1장] 정보 요구사항 개요

1. 정보 요구사항

항목	내용
정보 요구사항 생명주기 ✅	정보 요구사항 수집 → 분석/정의 → 상세화 → 검증
요구사항 문서가 가져야 하는 좋은 특성 ✅	완전성 : 시스템을 통해 일어날 수 있는 모든 가능한 시나리오가 기술되었음

✔️ 정보 요구사항 유형 ✅

유형	정의	관리 기준
외부 인터페이스 요건	정의	모든 입출력에 대한 요건으로, 대외기관 간의 송수신하는 입출력 방식이 추가, 변경되었을 경우와 각종 제도 및 기준 변경 시 발생하는 요건
	관리 기준	• 중복성 : 기존과 동일한 형태의 인터페이스 존재 여부 • 표준 준수도 : 국제/국가 표준 존재 시, 그에 적합한 형태로 제공
	관리 방법	항목 이름, 목적 설명, 입력의 원천 및 출력의 방향, 유효 범위, 시간, 다른 입출력과의 관계, 데이터 포맷, 최종 메시지 등 관리 필요
기능 개선 요건	정의	시스템에서 입력을 받아들여 처리하고 출력을 만들어 내는 주요 활동 및 프로세스에 대한 요건
	관리 기준	• 불가변성 : 향후 재변경되지 않도록 근본적인 개선방안 요청 • 범용성 : 많은 사용자가 편리하게 사용할 수 있는 내용을 우선 요청
	관리 방법	입력에 대한 유효 체크, 정확한 처리 순서, 비정상 상태에 대한 반응 (오버플로우, 통신 장비, 에러 처리), 매개변수의 기능, 출력과 입력의 관계, 입출력 순서, 입력을 출력으로 변환하는 공식 등 포함되어 관리 필요
성능 개선 요건	정의	동시 사용자 수, 처리하는 정보의 양과 종류, 트랜잭션 소효 시한 등에 대한 요건
	관리 기준	• 실현 가능성 : 현행 기술 수준과 서비스 특성을 고려한 구현 가능 여부 • 측정 가능성 : 측정이 불가능한 형태 판단 여부
	관리 방법	각 서비스 특성을 고려하여 정적/동적 기준을 만들고, 해당 기준에 맞는지 모니터링을 통해 관리 필요
보안 개선 요건	정의	물리적 접근 통제 (제한구역, 통제구역 등) 및 사용 통제 (인증, 암호화, 방화벽 등)에 대한 요건
	관리 기준	• 불가변성 : 향후에 재변경 되지 않도록 근본적인 개선 방안인지 여부 • 실현 가능성 : 현행 기술 수준과 서비스 특성을 고려한 구현 가능 여부
	관리 방법	• 보안 관리가 필요한 장비에 대한 등급 관리 필요 • 해당 등급별 이용자 등급 관리 필요 • 접근 방식에 대한 기준 필요 • 해당 기준에 따라 모니터링 작업을 통해 안정적인 서비스가 제공되도록 관리 필요

2. 정보 요구사항 관리

✔️ 정보 요구사항 관리 프로세스 ✅

단계	내용
요구사항 발송	요구사항 정의서 양식에 기록하여 정보 시스템 담당자에게 발송
요구사항 수렴	정보 요구사항 정의서를 수집 후 규칙에 맞는지 확인하고, 해당 건을 처리할 담당자 지정하여 이송
요구사항 검토	반영 여부 판단하고 불가능할 경우, 미반영 사유와 함께 담당자에게 재전달
영향도 분석	영향을 받는 설계서, 기존 어플리케이션, 데이터베이스 등 파악
공식화	담당자와의 협의를 통해 규모 및 시간, 시급성에 따라 반영 유형 결정
반영 작업 계획 수립	• 영향 분석 결과를 근거로 담당자들과 미팅 후 반영 계획 수립 • 작업 계획에는 표준과 설계서 변경, 데이터베이스 및 어플리케이션 수정, 테스트, 이관 등의 작업 명시

✔️ 수행 조직 및 업무 ✅

역할	담당 업무
사용자	• 변경 요청 • 변경 여부 확인 • 미결 사항에 대한 의사결정 실시 • 정보 요구 사항 정의 상세화 • 정보 요구 사항 반영을 위한 미팅
담당자	• 사용자 정보 요구사항 접수 • 사용자 정보 요구사항에 대한 기본적인 검토 • 반영 여부 결정을 위한 사용자와 1차 미팅 • 접수 요건에 대한 처리 방식 및 처리 기한 결정 • 관련 부서별 담당자 수집 및 요건 협의 주도 • 사용자 정보 요구사항 반영 • 테스트 및 검증 • 사용자 반영 결과 통보
데이터 아키텍처 전문가	• 사용자 정보 요구 사항에 대한 표준/데이터베이스/어플리케이션 차원에 대한 영향도 분석 및 보고 • 접수된 요구사항에 대한 표준 준수 여부 체크 • 영향도 분석을 통한 수정 및 변경 계획 수립 • 표준 제시 및 준수 여부 검토

[2장] 정보 요구사항 조사

1. 정보 요구 사항 수집

1) 관련 문서 수집

항목	내용
문서 수집 목적	구현 시스템의 대상과 범위를 명확히 정의
문서 수집 자료	경영 계획, 정보시스템, 과거 수행한 컨설팅 보고서, 전산 처리 업무 매뉴얼, 현업 부서 업무 자료 등
문서 수집 원칙	• 기존 문서를 변형하지 않고, 수집/정보시스템 자료는 별도의 정리 양식을 사용하여 수집 • 수집 문서를 바탕으로 경영 및 정보시스템 현황에 대한 요약표 작성 및 숙지 • 수집된 문서들은 계획 수립 기간, 문서 관리자를 지정하여 운영 • 유형별 문서 분류 방식을 결정한 후에 일정한 장소에 보관 • 통상 대외비 형식이 많음으로 문서 보안 관리 주의

2) 사용자 면담

✔️사용자 면담 진행 ✅

절차	상세 내용
계획 및 준비	면담 일정, 면담 지침, 면담 요지, 기록 양식
면담 수행	핵심 사항, 상세 면담 기록, 책임 소재, 분석 양식
면담 결과 분석	면담 분석 결과, 현안 정보 요구, 정보화 과제
분석 결과 피드백	면담 분석 결과 승인

✔️ 면담 시 참고 사항

항목	내용
사용자 요구 사항 명세	• 고객이 이해할 수 있도록 작성 • 시스템이 제공할 서비스와 수행될 때의 제약 조건을 자연어, 그림 등을 이용해서 표현
시스템 요구 사항 명세	• 개발자를 위해 작성 시스템이 제공해야 할 서비스, 제약조건이 무엇인지 체계적으로 작성
문제점의 이해	• 요구 분석에 있어 사용자가 현재 안고 있는 문제점을 이해하는 것이 중요 • 사용자 입장에서 현황을 파악하고 원하는 문제 해결이 무엇인지 이해
요구 사항 추출	• 면담, 실제 업무 수행 등의 기법을 활용

✔️ 계획 및 준비

면담 주제 선정
- 작업과 면담 대상자 수준에 따라 결정

면담 진행 팀 구성 ✅

모델	활용 방안
면담자	• 면담 진행 • 면담의 취지를 설명하고 면담 대상자에게 질문
기록자	• 면담 대상자의 답변 내용 기록 (내용을 요약하지 말고 표현 그대로 기록) • 면담 대상자의 답변 내용을 충분히 이해하고 기록하기 위하여 면담 대상 업무에 대한 사전 지식 필요 • 면담 종료 시에 기록 내용 중 주요 사항 (수치, 업무 분창, 책임소재조직 등에 대한 내용)을 확인
관찰자	• 면담이 수행 의도대로 진행되고 있는지 관찰 • 면담이 주제의 범위를 벗어나는 경우, 주의를 환기시킴 • 면담자가 놓치는 부분에 대해 보충 질문을 함 • 최종적으로 면담의 종료에 대해 판단

면담 대상자 선정
- 대상자는 업무에 대해 명확한 이해를 하는 사람이어야 함
- 전체 조직 구성도와 프로젝트 범위를 검토하고 대상자를 프로젝트 후원자나 사용자 측으로부터 추천 받는 것이 좋음
- 유사 업무를 지원하는 조직이 여러 명일 경우 차이점 파악을 위해 적어도 2명 이상의 면담 대상자 선정
면담 일정 수립
- 대상자들에게 프로젝트의 목적과 범위를 통보하고 관련 문서 자료 요청
- 초기 단계에 전체 일정이 정해져야 함
- 최소 1주일 전에 세부 일정 확정
- 면담 시간은 1.5~3시간으로 하고 필요 시 집단 면담을 수행
- 하루 3회 이하, 세부 일정은 담당 면접 진행팀도 함께 참여
면담 준비
- 이용 가능 자료로 대상자의 업무 활동, 경력, 개인적 성향 등 파악
- 면담 시나리오 준비

✔️ 면담

항목	내용
면담 시작	• 프로젝트 목적, 범위, 일정 등을 먼저 설명하며, 필요할 경우 주제나 질문 수정 • 면담은 여러 팀에서 수행될 수 있으므로 수행 방식을 통일하기 위해 모든 절차가 면담 지침에 세세한 문구까지 모두 반영되어야 함
면담 주제 토의	• 준비된 면담 요지에 따라 진행하고 내용은 모두 기록지에 기록 • 개방적 질문을 사용하며 주제나 질문지의 순서와 범위를 벗어나지 않도록 함 • 효율적인 진행을 위해 엔터티 관계도, 업무 기능 계층도를 이용할 수 있음 • 답변을 가정하지 않으며 진행 도중 간간이 수집된 정보나 순서 등 확인 • 기록자는 가능한 한 모두 기록하며, 여담일지라도 중요한 정보일 수 있음 • 면담 결과의 후속 분석 작업을 위해 공통의 기준으로 사용할 수 있는 표준 기록 양식을 정함 • 진행 중 대상자의 주요 책임 업무를 정의하고 각 업무가 시간과 같은 논리적인 순서를 따르는지 확인
면담 결과 분석	• 면담 진행 팀은 기록된 내용과 면담 중의 응답에 대한 개인적 의견을 고려하여 면접 결과를 정리하고 면담 종료 후 팀 전원이 참석하여 주요 이슈 정리 • 현재 업무와 발생하는 차이점에 주의하고 가능하면 면담 대상자의 업무 용어를 사용하며 별도 양식은 없음 • 의문 사항, 추가 사항은 즉시 면담 대상자에게 확인하고 필요한 경우 추가 면담 진행
분석 결과 피드백	• 결과에 대해 대상자 본인에게 승인을 받는 것이 중요 • 대상자는 수정사항을 제시할 수 있으며 기록지에 대상자의 의견을 기입하는 것이 좋음 • 개인별 피드백이 곤란한 경우, 실무자 전원을 대상으로 워크숍을 진행할 수 있으며 민감한 사안은 사전 조정이 필요함
면담 수행 시 고려사항	• 면담 시간 준수, 비밀 보장, 기대 수준 설정, 면담 범위 준수 • 적절한 대상자 선정, 적절한 응답 유도, 면담 내용 문서화, 잘못된 선입견 배제, 애매한 질문 배제

3) 워크숍

항목	내용
워크숍 개요 및 목적	• 전문 진행자의 진행 하에 프로젝트의 현업 부서, 전산 부서 주요 구성원들이 함께 참여하는 회의 • 경영층 또는 현업 부서장의 공통된 의견 도출 • 관련 업무를 수행하는 부서를 따로 면담하는데 드는 노력 절감 • 전문가들의 판단력을 이용하여 최적의 결론 도출
워크숍 준비	• 워크숍 과제 선장과 계획 수립 • 참가 대상자 선정 • 대상자에 대한 사전 브리핑 및 교육 • 킥오프 모임 수행 • 워크숍 자료 준비 • 설비와 물품 준비 • 워크숍 장소/기간 선정 • 프로그램 준비
워크숍 수행	프로젝트 관리자와 현업 책임자는 이해관계를 가지고 있기 때문에 워크숍 진행자로 부적절 (1) 워크숍 개시 (2) 워크숍 수행 준비 : 목적과 접근 방법의 개요 설명, 작업 수행 기법 습득 (3) 워크숍 수행 : 구체적인 수행 방식은 형태나 목적에 맞게 수행 (4) 워크숍 종료 : 도출된 사항을 공유하고 전체에게 1차적으로 검토

4) 현행 업무 조사서 ✅

전체 부서에 동일한 기준으로 조사
동일한 업무를 수행하는 부서가 여러 개일경우, 표본 추출 및 발췌 조사 가능
조사서의 양식은 간단하고 이해하기 쉬워야 하며, 작성 방법, 표본을 같이 배포
잘못 작성되거나 추가해야 하는 경우를 고려하여 일정 수립
사용자가 처리하고 있는 업무 기능을 정리된 양식으로 기록하여 향후 작업에 도움이 되도록 함

5) 현행 프로그램/데이터 관련 문서

요구 사항을 세부적으로 진행하기 위한 사전 단계
현행 시스템을 파악하기 위한 작업
현행 시스템 프로세스 구조는 계층적 구조로 표현하며, 향후 완전성 검증을 위한 비교 자료로 활용

2. 정보 요구사항 정리

1) 정보 요구사항 정리

사용자 면담 정리 : 주요한 관점 (업무 흐름, 수치, 주관 부서 등)에 대해 기록에 오류가 있는지 사용자에게 확인 받아야 함

업무 조사서 정리

모델	정리 항목
수행 중인 프로세스 목록	• 대/중/소 분류별 프로세스명 • 프로세스 설명 및 수행 빈도 • 전산화 정도 및 필요성
프로세스의 업무 흐름	• 정보 시스템을 포함한 관련 부서 간의 업무 흐름을 시스템 흐름도 형태로 도식화
타 부서/외부 기관으로 받은 문서	• 문서명 및 설명 • 접수 부서(기관), 접수 주기/수단 • 활용 형태/단위 문서량
사용 중인 시스템	• 시스템 명, 사용범위/방법/빈도, 유용성, 편리성

워크숍 정리
- 워크숍의 목적 및 진행 내용
- 해결과제에 대한 상태
- 기타 특이사항
기타 기법 정리
- 설문조사법, 심층면접법, 초점집단면접법, 투사법, 인적 관찰과 기계적 관찰, 인위적 관찰과 자연적 관찰

2) 정보 요구 우선순위 분석

우선순위, 중요도, 소요 비용 등을 고려한 비교적 판단이 용이한 방법으로 판단

항목	내용
화폐가치 산출 방법	최종적으로 구해진 가치가 높을수록 우선순위가 높음 (1) 정보 요구사항을 나열한 후, 각 요구사항에 기업 차원의 중요성/시스템 차원의 중요성을 평가하여 1~3점까지 점수 부여 (2) 각각의 요구사항이 다른 요구사항에 도움을 주는지 1~5점까지 점수 부여 (상호 관련성) (3) 3가지 점수를 모두 곱함 (4) 계산된 점수를 더하고 점수 합계를 100으로 하여 각각의 정보 요구사항 가치를 백분율로 환산 (5) 백분율을 곱해서 정보 요구사항 가치를 금액으로 환산
상대적 중요도 산정 방법	• 정보 요구사항이 무엇을 지원하느냐에 따라 점수 부여 및 가중치에 따라 계산 • 산정 방법이 복잡하여 적용에 한계가 있음 (1) 정보 요구사항을 나열한 후, 업무에 기여하는 수준에 따라 1~5점까지 점수 부여 (2) 현행 정보시스템이 각각의 정보 요구사항을 얼마나 충족하는지 1~3점까지 점수 부여 (3) 정보 요구사항x정보 요구사항 매트릭스를 작성하여, 각각 관련성이 클 경우 9점 부여하며 나머지 정보 요구사항에는 상대 점수 부여 (4) 부여한 3가지 점수에 대해 가중치 결정


서브타입을 테이블로 분리	서브타입을 통한 테이블 생성