2025년 한 해 정리하기

☃️목차

1. 운영시스템과 분석시스템의 구분(2025 ver.)
(1) OLTP와 OLAP의 이해: 트랜잭션에서 분석 데이터로의 전환
- 데이터 흐름의 가시성과 일관성
(2) ETL 관점에서의 데이터 파이프라인 설계
- 최적화 원칙
(3) 데이터 레이어 아키텍처의 이해
- 3-Layer 아키텍처
- 테이블 유형별 특성
- Fact와 Dimension의 분리 (스타 스키마 설계)
 
2. ERP 시스템 운영과 개선
(1) 문제가 생기지 않는 시스템 만들기
- 비즈니스 프로세스 분석
- 시스템 로직 분석 (abap)
(2) 사후 조치에서 사전 예방으로
(3) 암묵지의 형식지화 (2026~)

---

1. 운영시스템과 분석시스템의 구분
(1)  OLTP와 OLAP의 이해: 트랜잭션에서 분석 데이터로의 전환

 
운영 시스템(ERP)의 트랜잭션 데이터를 분석 리포트로 재현하기 위해서는 원천 시스템에 대한 깊이 있는 이해가 필요하고
개발 방식에 대한 지식보다는, 데이터가 어떤 테이블에서 어떤 조건과 로직을 거쳐 집계되는지 파악하는 것이 중요하다고 느꼈다.
 
올해에는 작년에 중요하다고 생각했던 두 가지 원칙을 구체화해볼 수 있었다. 

데이터 흐름의 1) 가시성, 2) 일관성이 OLAP 시스템의 핵심 (2024)
1) 가시성
- 사용자가 목적에 맞는 데이터를 쉽고 빠르게 조회할 수 있도록 구조 설계
- 요구사항 구체화 과정에서 더 나은 리포트 구조를 지속적으로 제안&협의
2) 일관성
- 원천 시스템과 동일한 값이 보여져야 함
- 값 검증을 반복하고, 불일치할 경우 로직이 차이나는 부분을 추적
- 데이터 모델링 구조를 정리하여 어느 단계에서 로직 오류가 발생했는지 파악
→ 모델링 구조를 체계적으로 정리하고, 분산된 데이터 속 오류 원인을 찾는 작업

---

1. 운영시스템과 분석시스템의 구분
(2) ETL 관점에서의 데이터 파이프라인 설계

 
리포트 구축 작업을 트랜잭션 데이터를 분석 목적에 맞게 전처리하는 ETL 관점으로 이해하게 되었다.

1. Extract 어떻게 가져올 것인지

• 원천 시스템에서 필요한 데이터만 효율적으로 가져오기 위해 적재용 뷰를 별도로 생성
• 해당 뷰에서 필터를 적용하여 필요한 데이터만 추출하여 테이블에 적재

2. Transform 트랜잭션 로직의 재구성

• 운영 시스템 프로그램에 적용된 필터, 조인, 예외 처리 로직 파악
• 목표 리포트 구현을 위해 어떤 로직을 선별적으로 적용해야 하는지에 대한 전체적인 이해 필요
• 전체를 아는 사람이 없기에, 분산된 정보를 수집하고 '조합'하는 능력이 중요
• 이를 위해 값을 맞춰보며 역으로 로직을 추적하는 방식으로 접근함

3. Load 성능 최적화를 고려한 적재 전략

• 리포트 모델링은 실제 테이블이 아닌 여러 단계의 가상의 뷰를 쌓아 만드는 구조이기 때문에, 성능과 시스템 부하를 고려한 설계가 필요함
• 뷰만 계속 쌓을 경우 조인 단계가 복잡해지고, 필터링 전 대용량 데이터를 매번 읽어야 하기 때문에 시스템 부하가 발생함 

✅ 최적화 원칙

1. SELECT 중첩 횟수 최소화
2. 필요 시 일부 연산을 물리화하여 테이블에 적재

---

1. 운영시스템과 분석시스템의 구분
(3) 데이터 레이어 아키텍처의 이해

 

복잡해서 내가 이해한 부분만 박스 표시 ..

 

작년에는 단순히 oltp는 운영 시스템, olap는 분석 시스템 정도로 구분하는 수준이었다면, 올해는 olap 구조를 직접 구축하며 레이어 개념에서 구체화한 모습으로 정리가 되었다  

 

✅ 3-Layer 아키텍처
1) Inbound Layer

:운영 시스템에서 전달된 원천 데이터를 복제해오는 영역
 
2) Propagation Layer(통합 레이어)
: 여러 소스의 데이터를 조인 및 정제하여 분석용 Fact/Dimension 구조로 통합하는 공간

• 데이터 전파 단계로, 중앙에서 생성한 표준 모델을 셀프서비스 영역으로 공유
• 현업의 파워유저가 직접 모델을 생성하는 self-service 구조 지원

- 사용자 친화적인 gui 도구의 발전으로, 모델링 작업 자체가 self-bi 영역으로 확장되고 있다는 점이 인상깊었다.중앙에서 생성한 표준 모델을 propagation layer에서 공유하면, self-service modeller가 이를 기반으로 reporting layer의 모델을 파생시킬 수 있다 
- 왼쪽 아래 “self service maturity model of business functions”를 보면, self service modellers는 성숙도의 중간 단계에 위치한다. 위로 올라갈수록 자율성, 권한, 책임이 증가하는 구조로, 이를 통해 조직이 나아가야 할 방향성을 생각해볼 수 있다
 
3) Reporting Layer
: 최종적으로 사용자가 데이터를 소비하는 공간으로 sac, power bi 와 같은 리포팅 도구에서 분석 및 시각화 수행 

---

✅ 테이블 유형별 특성
: 데이터 적재 방식에 따라 세 가지 유형으로 구분할 수 있다

• Remote Table: 원천 시스템을 직접 조회하는 테이블
• Delta Table: CDC(Change Data Capture)로 변경분만 적재하는 구조
• Local Table: 필터링 및 집계된 결과를 물리적으로 저장하여 매번 원천을 읽지 않아도 되도록 최적화

---

✅ Fact와 Dimension의 분리 (스타 스키마 설계)
: 운영 시스템에서 표시되는 값을 '어떤 fact에 어떤 dimension을 연결하여, 어떤 조건과 기준으로 집계된 값인지'라는 관점으로 재정의

• Fact: 트랜잭션 데이터
• Dimension: 기준정보 (분석 기준)
• Association: fact와 dimension을 느슨하게 연결하는 관계 

리포트를 설계하는 과정에서 sqld 공부할 때 이론적으로 학습했던 스타 스키마 개념이 떠오름

[Dimension 분리 기준]

1) 집계 및 필터의 기준이 되는 속성인가?
→ 요구사항에서 집계 기준으로 사용되는 모든 차원은 분리 필요
 
2) 두 개 이상 Fact에서 공통으로 사용되는가?
→ 공통 차원은 분리해야 리포트 간 정의 일관성 확보 
 
3) 마스터 속성인가, 트랜잭션 속성인가? (자주 바뀌는지)
 
'변경 빈도'를 두 가지 관점으로 구분하면,
a. 트랜잭션마다 값이 달라지는 속성

• 주문번호나 상태는 Fact 레코드마다 다른 값을 지님, 공통 차원이 아닌 팩트에 두는 게 자연스러움

b. 매핑 테이블로 유지보수되는 마스터 속성

• dimension으로 분리하지 않으면 기준 변경 시 fact 전체를 업데이트 해야 함 (+변경에 대한  이력 관리도 되지 않음)
• 분리하면 dimension만 업데이트하여 모든 fact가 자동으로 새로운 기준으로 집계됨
• 비즈니스 규칙(기준 변경)을 fact를 건드리지 않고 dimension에서 통제 가능 

⚠️ 예외
사용자마다 다르게 정의되거나, 매일 바뀌는 임시 그룹은 고정 dimension이 아닌, 리포팅 툴의 사용자 정의 그룹 또는 파라미터로 처리하는 편이 낫다.
 
4) 계층구조를 갖고 있는가?

• 부모-자식 관계(ex.센터코드-창고번호)를 가진 속성
• 한 자식은 하나의 부모만 가지는 구조
• 계층구조로 설계하면, 사용자 입장에서 더 직관적인 분석 가능

당연히 계층구조인 차원을 제외하고, 계층이라는 것을 인지 못하고 있던 속성들이 있었다. 이런 경우 계층으로 설계하면 사용자 입장에서 더 편리할 것 같다.
 
5) 이해하기 쉬운가?

• Dimension을 과도하게 분리하면 쿼리가 복잡해지고 현업에서는 헷갈릴 수 있음 (ex. 날짜 차원을 두 개 이상으로 쪼갠 경우 어떤 차원을 가져다 써야하는지 헷갈림)
• 반대로 과소 분리하면 한 dimension에 과다한 속성이 포함되어 의미가 불분명해지고, 재사용성이 떨어짐

---

2. ERP 시스템 운영과 개선
(1) 문제가 생기지 않는 시스템 만들기
 

어쩌다가 운영 업무를 맡게 되었다. 그나마 운이 좋게도, 시스템 개선 권한을 함께 부여받았다. 초기에는 시스템과 프로세스의 구멍을 메우는 작업에 많은 시간을 들였고, 흥미도 느꼈다.
운영자로서 문제를 임시방편으로 해결하기보다는, 설계자로서 문제가 발생하지 않는 구조를 만들었고, 그 결과 단순 운영업무는 사라지고 시스템 개선이라는 가치있는 업무로 전환되었다
 
[기존]

• 오류 발생 시 사후 수정 방식으로 대응
• 근본 원인은 방치되고 동일 오류 반복 발생
• 운영 업무 과부하

[현재]

• 오류가 발생하지 않는 시스템 구조 구축
• 단순 반복 업무를 시스템 개선 업무로 재정의
• 불필요한 운영 업무 감소

✅ 접근 방식
1. 문제와 연관된 전체 구조 이해
2. 문제의 시작점 찾기
3. 구조 재설계하기
 
그리고 위 접근 방법은 크게 두 가지 측면으로 나뉜다.
1) 비즈니스 프로세스 분석

• 품질 서버 환경에서 오류 재현 및 가설 검증
• 설계 및 개발 과정의 예외 상황 점검 (=설계/개발 과정에 구멍이 없는지 확인하기)
• 프로세스 흐름 상의 구조적 문제점 파악

2) 시스템 로직 분석

• 기존 구현 로직의 abap 코드 레벨 검토
• 비즈니스 요구사항과 시스템 구현 간 불일치 식별
• 개선 가능 지점 도출

두 작업의 본질은 '흩어진 데이터 속에서 원인을 추적하는 일'이다. 데이터 리포트 개발에서도 오류 지점을 찾아 로직을 바로잡는 과정이 가장 재미있었다

---

2. ERP 시스템 운영과 개선
(2) 사후 조치에서 사전 예방으로

✅ 개선 방향
사후 수정이 아닌, 최초 생성 시점부터 정확한 데이터가 입력되도록 시스템 및 프로세스 개선
 
✅ 개선 사례
case 1) 속성 간 동기화 로직개선 
[문제]

• 특정 관리 단위의 상태 변경 시 연관 속성이 강제 동기화
• 독립적 관리가 필요한 상황에서도 수정 불가
• 주기적으로 상태를 원복하는 비효율 발생

[해결]

• 기본 동기화 유지하되, 필요 시 독립 수정 가능하도록 프로그램 수정
• 담당 부서에 예외 상황 처리 가이드 제공

case 2) 반복 패턴 기반 자동화
[문제]

• 변경 이력 분석 결과, 특정 속성이 신규 생성 시마다 수동 수정됨
• 명확한 패턴 존재했기에 자동화 가능하다고 판단

[해결]

• 패턴 기반 초기값 자동 설정 로직 구현
• 수동 개입 제거

case 3) 책임 소재 명확화

[문제]

• 요청자의 부정확한 정보 입력 → 관리자의 사후 검토 및 수정
• 동일 오류 반복 발생

[해결]

• 재작업을 요청하는 기능을 도입하여 요청자 책임 강화
• 관리자 업무 부담 감소 및 정합성 관리 주체 이동

✅ 향후 과제

1. 통제와 편의성의 균형: 중앙 통제는 업무 신속성을 저해하나, 과도한 분권화는 정합성을 저해함
2. 근본적 프로세스 개선: 검증 체계는 오입력을 방지할 수 있으나, 입력 시점에 정확한 정보를 확보할 수 없는 구조적 한계는 여전히 존재함

---

2. ERP 시스템 운영과 개선
(3) 암묵지의 형식지화 (2026~)

[배경]
- 기존: 중앙 통제(승인) 방식
- 목표: 표준 운영절차 기반 거버넌스 체계 확립
 
✅ 기준정보 속성에 대해 생성 로직과 영향도를 분석하고 정책을 문서화하여 체계적인 거버넌스 프레임워크를 구축하는 것이 목표

1. 역할 및 책임 체계 정리
   • 속성별 생성 및 변경 책임 주체 명확화
2. 정책 및 절차 정리
   • 속성 간 종속성 및 타 시스템과의 연관관계 파악
   • 종속성 기반 업무 영향도 분석
   • 속성 중 대부분은 독립적이 아닌 상호 의존적 구조
3.  분석 프레임워크: Data - Rule - Impact 각 속성을 다음 세 가지 관점에서 체계적으로 분석
   • Data: 데이터 정의
   • Rule: 생성 및 변경 규칙
   • Impact: 오류 시 영향 범위

[예시]
사례: 기준정보 속성 변경의 적시성 관리

• Data: 변경 내용 적용일자
• Rule: 요청일 기준 +n일
• Impact: 규칙 미준수 시
  • 계획 단계: 수동 수정 발생 → 운영 효율 저하
  • 실행 단계: 잘못된 자재 투입 → 품질 이슈
  • 수급 단계: 발주 지연 → 생산 차질

 → 이처럼 단일 규칙이 계획-실행-수급 프로세스 전반에 영향을 미친다.
 
✅ 적시성(Timeliness) 확보

• 업무 프로세스 실행 이전에 모든 기준정보가 정확히 반영되어야 함
• 종속 관계에 있으나 동기화되지 않는 속성 식별 및 개선

---

🎄

올해 잘한 일
1. 나에 대해 알게된 사실이 꽤 많음
- 보고 나서 생각하게 만드는 열린 결말 스토리를 좋아함 (feat. 파이 이야기) 
- 미래를 상상하고 기대하는 게 내가 살아가는 원동력
- 정리하는 걸 좋아한다 = 학습하는 걸 좋아한다
- 아늑한 공간과 분위기를 (아주) 좋아함
2. 재테크 포트폴리오 정비
3. 자신있는 도메인이 생김 (작년 계획 2번)
 
내년 계획
1. 기록 부지런히 하기,,
2. 운동 꾸준히 하기
3. 출근 전/퇴근 후 루틴 만들기
4. 내 공간 정리정돈하기, 물건 최소화하기
5. 책!!!!! 📖

---