System.out.println("");

[SAP] Fiori(피오리)란 무엇인가? - 개념, 학습, 강의 추천

가시가되어 — Thu, 9 Apr 2026 12:14:24 +0900

1. SAP Fiori란 무엇인가? : 단순한 화면 그 이상

오랜 시간 SAP GUI 사용자들에게 익숙했던 '투박한 회색 창'과 복잡한 거래 코드(T-Code)의 시대가 저물고 있습니다.

SAP Fiori는 SAP 소프트웨어의 새로운 사용자 경험(User Experience, UX) 전략이자 디자인 언어입니다.

단순히 예쁜 화면을 만드는 것이 아니라, 사용자가 업무를 수행하는 방식을 '사용자 중심'으로 재설계한 결과물입니다.

Fiori의 5가지 핵심 디자인 원칙

Fiori가 기존 GUI와 차별화되는 이유는 다음의 5가지 원칙에 기반하기 때문입니다.

Role-based (역할 기반): 사용자는 자신에게 할당된 업무에 꼭 필요한 앱과 데이터만 봅니다. 수천 개의 T-Code 사이에서 방황할 필요가 없습니다.
Responsive (반응형): 데스크톱, 태블릿, 스마트폰 등 어떤 기기에서도 최적화된 화면을 제공합니다.
Simple (단순성): '1-1-3' 법칙을 지향합니다. (한 명의 사용자, 한 개의 핵심 과업, 최대 세 개의 화면 단계)
Coherent (일관성): 구매 요청을 하든, 영업 실적을 보든 동일한 디자인 언어를 사용하여 학습 비용을 최소화합니다.
Delightful (즐거움): 감성적인 디자인을 통해 사용자가 업무에 몰입하고 즐거움을 느낄 수 있도록 합니다.

2. SAP Fiori의 기술적 기반 (Architecture)

Fiori를 제대로 이해하려면 그 밑단에서 돌아가는 기술적 구조를 알아야 합니다. 개발자와 컨설턴트 모두에게 중요한 부분입니다.

SAPUI5와 OData

SAPUI5: Fiori 앱을 만드는 HTML5 기반의 JavaScript 프레임워크입니다. Google의 Angular나 Facebook의 React와 유사한 성격이지만, 기업용 ERP 환경에 최적화된 컨트롤들을 내장하고 있습니다.
OData (Open Data Protocol): SAP 백엔드(S/4HANA)의 데이터와 프론트엔드(UI5)를 연결하는 통로입니다. REST API 방식을 사용하여 가볍고 빠릅니다.

Fiori 앱의 세 가지 유형

Transactional Apps (트랜잭션 앱): 전표 생성, 승인 업무 등 일상적인 업무 처리용입니다. (HANA DB가 아니어도 구동 가능)
Analytical Apps (분석형 앱): 대량의 데이터를 시각화하여 KPI를 모니터링합니다. (HANA DB 필수)
Fact Sheets (팩트 시트): 특정 마스터 데이터(예: 고객, 자재)의 정보를 한눈에 조회하고 연관된 정보로 탐색합니다. (HANA DB 필수)

3. SAP Fiori 개발의 진화: Elements vs. Freestyle

최신 SAP 개발 트렌드는 "Low-code"와 "Standardization"입니다.

Fiori Elements: SAP가 미리 정의한 템플릿(List Report, Object Page 등)을 사용하여 코딩을 최소화하고 메타데이터 설정만으로 앱을 구성하는 방식입니다. 유지보수가 매우 쉽고 디자인 일관성이 완벽합니다.
Freestyle (SAPUI5): 표준 템플릿으로 구현이 불가능한 복잡한 요구사항이 있을 때 직접 자바스크립트로 코딩하는 방식입니다. 자유도는 높지만 개발 공수가 많이 듭니다.

최근에는 RAP(ABAP RESTful Application Programming Model)을 통해 백엔드에서 비즈니스 로직을 짜고, 이를 Fiori Elements로 빠르게 배포하는 방식이 대세로 자리 잡았습니다.

무료 강의: 입문 및 기초 다지기

비용 부담 없이 피오리의 개념을 잡고 개발 환경을 구축해 볼 수 있는 리소스입니다.

① SAP Learning (Official)

SAP가 직접 운영하는 최신 학습 플랫폼입니다. 과거 openSAP의 유료 수준 콘텐츠가 상당수 무료로 풀려 있습니다.

추천 코스: * Exploring SAP Fiori: 피오리의 기본 개념과 디자인 원칙을 익히는 입문용.
- Developing Apps with SAPUI5: 실제 개발을 시작하려는 분들을 위한 기초 문법.
장점: 공식 인증 배지(Badge) 획득 가능, 최신 버전(S/4HANA Cloud 등) 반영.

② openSAP

Developing Software using SAPUI5
https://github.com/SAP/openSAP-ui5-course

유료 강의: 전문 역량 및 실무 심화

컨설턴트나 전문 개발자로 커리어를 쌓고 싶다면, 체계적인 유료 강의가 시간 대비 효율이 훨씬 높습니다.

① SAP Learning Hub (Professional Edition)

특징: 모든 공식 교육 교재(Student Handbook)에 접근 가능하며, 실습용 SAP 시스템(SAP Learning System Access)을 사용할 수 있습니다.
필수 코드:
- UX100: SAP Fiori Foundation (전체적인 가이드라인)
- UX400 & UX402: SAPUI5 개발 (중급/심화)
- UX403: SAP Fiori Elements (효율적인 개발 패턴)
장점: 자격증(C_FIORDEV_XX) 취득을 위한 유일하고 확실한 경로.

② Udemy (실무 중심 저가형 강의)

개념보다는 "그래서 어떻게 화면을 만드는데?"라는 갈증을 풀어줍니다.

https://www.udemy.com/course/professional-sapui5-web-application-development-part-1/

SAPUI5 / Fiori Fullstack with TypeScript/JS on BTP RAPM/CAPM

Update 2025 November:- Updation of course with contents of UI5 with Typescript. Next generation UI5 will be based on Typescript, along with Javascript, UI5 with Typescript will be completely available by end of Feb 2026.<

www.udemy.com

[SAP] QM Inspection Lot(품질검사의뢰)란?

가시가되어 — Wed, 8 Apr 2026 15:50:39 +0900

1. Inspection Lot(품질검사의뢰)이란?

SAP에서 Inspection Lot(품질검사의뢰)와 QM(Quality Management) 절차는 자재의 품질을 관리하고, 입고·생산·출하 과정에서 검사 및 판정을 수행하기 위한 핵심 기능입니다.

특정 자재에 대해 검사가 필요할 때 시스템에서 생성되는 "검사 티켓"이라고 이해하시면 쉽습니다.

이 Lot 안에는 '무엇을(자재)', '어디서(플랜트)', '얼마나(수량)', '어떤 기준으로(검사 사양)' 검사해야 하는지에 대한 모든 정보가 담겨 있습니다.

“특정 자재 또는 공정에 대해 품질검사를 수행하기 위해 생성되는 단위”

자주 쓰는 트랜잭션 코드

기능	T- code
Inspection Lot 생성	QA01
Inspection Lot 조회	QA03
검사 결과 입력	QE01
사용 판정	QA11
검사 계획 생성	QP01

2. SAP QM의 표준 비즈니스 프로세스 (4단계)

품질 검사는 보통 다음과 같은 4단계 사이클을 거칩니다.

① Inspection Lot 생성 (Triggering)

검사 로트는 수동으로 만들 수도 있지만, 대부분 SCM 프로세스와 연동되어 자동으로 생성됩니다.

MM(구매): 업체로부터 원부자재 입고 시 (Goods Receipt)
PP(생산): 제품 생산 완료 또는 공정 중간 (In-process)
SD(영업): 고객 반품 접수 시 (Returns)

② 샘플링 및 검사 준비 (Sample Calculation)

로트가 생성되면 시스템은 "전수 검사를 할 것인가, 샘플 검사를 할 것인가"를 결정합니다.

Sampling Procedure: 통계적 기법(AQL 등)에 따라 검사 수량을 산출합니다.
Status 변경: 로트의 상태가 CRTD(생성)에서 REL(개방)로 변경되어야 실제 검사가 가능합니다.

③ 결과 기록 (Results Recording)

검사원이 실제 측정한 값을 시스템에 입력하는 단계입니다. (T-Code: QE11 또는 QE51N)

계량형(Quantitative): 10.5mm, 85도 등 수치 입력
계수형(Qualitative): 합격/불합격, 양호/불량 등 속성 선택

④ 판정 및 재고 처리 (Usage Decision, UD)

검사 결과를 바탕으로 해당 로트에 대한 최종 의사결정을 내립니다. (T-Code: QA11)

UD Code: 'A(Accept)' 또는 'R(Reject)' 결정.
Stock Posting: 가장 중요한 부분입니다. 품질 검사 재고(Quality Inspection Stock)로 묶여 있던 자재를 가용 재고(Unrestricted)로 풀거나, 블락 재고(Blocked)로 넘기는 전기(Posting)가 이 단계에서 일어납니다.

3. 주요 검사 유형 (Inspection Types)

SAP에서는 상황에 따라 다양한 검사 유형을 제공합니다. 컨설턴트로서 가장 자주 접하게 될 주요 유형은 다음과 같습니다.

검사 유형	명칭	발생 시점
01	구매 입고 검사	외부 업체로부터 자재가 들어올 때
03	공정 중 검사	생산 오더 진행 중 (In-process)
04	제품 입고 검사	생산 완료 후 창고 입고 시
05	기타 입고 검사	재고 이전 등 기타 사유 발생 시
89	수동 검사	필요에 의해 사용자가 직접 생성 시

4. 왜 Inspection Lot이 중요한가?

단순히 "검사 기록을 남긴다"는 의미를 넘어, Inspection Lot은 가시성(Visibility)과 제어(Control)를 제공합니다.

재고 통제: 검사 판정이 내려지기 전까지는 해당 자재를 생산에 투입하거나 고객에게 배송할 수 없도록 물리적/시스템적 제동을 겁니다.
추적성(Traceability): 나중에 제품에 문제가 생겼을 때, 어떤 로트에서 어떤 결과값이 나왔는지 역추적하는 핵심 Key가 됩니다.
공급업체 평가: 01번 검사 유형을 통해 쌓인 데이터는 나중에 MM 모듈의 '공급업체 평가(Vendor Evaluation)'에 자동으로 반영되어 구매 전략에 영향을 줍니다.

맺음말

SAP QM은 타 모듈과의 Integration(통합)이 매우 긴밀한 모듈입니다.

SAP QM은 “검사 → 판정 → 재고처리” 구조

MM: 입고
QM: 검사
WM/IM: 재고 이동

✔ Inspection Type 설정이 핵심
✔ Material Master(QM View)에서 활성화 필요
✔ 자동 lot 생성 여부 확인
✔ Usage Decision 이후 재고 이동 발생
✔ QM + MM + PP 통합 프로세스

컨설턴트나 운영자라면 단순히 로트를 생성하는 법을 넘어, 이 데이터가 어떻게 재고 흐름과 기업의 품질 비용(COQ)에 기여하는지를 이해해야 합니다.

데이터브릭스(Databricks) 완벽 가이드: 개념부터 기본 사용법

가시가되어 — Tue, 7 Apr 2026 16:51:40 +0900

데이터브릭스(Databricks) 완벽 가이드: 개념부터 기본 사용법

1. 데이터브릭스(Databricks)란 무엇인가요?

데이터브릭스는 아파치 스파크(Apache Spark)의 오리지널 창립자들이 만든 클라우드 기반의 통합 데이터 분석 플랫폼입니다.

과거에는 데이터를 수집하는 엔지니어, 데이터를 분석하는 과학자, 비즈니스 인사이트를 도출하는 분석가들이 각기 다른 도구와 환경(데이터 사일로)에서 작업했습니다. 데이터브릭스는 이 모든 과정을 하나의 플랫폼으로 통합하여, 대규모 데이터 처리부터 머신러닝 모델 구축까지 한 곳에서 협업할 수 있는 환경을 제공합니다. 현재 AWS, MS Azure, Google Cloud Platform(GCP) 등 주요 클라우드 환경에서 모두 사용할 수 있습니다.

데이터 엔지니어링 + 데이터 분석 + AI 개발을 통합한 “레이크하우스 플랫폼”

2. 핵심 개념 정리 (Core Concepts)

데이터브릭스를 이해하기 위해 꼭 알아야 할 주요 개념들은 다음과 같습니다.

레이크하우스 (Lakehouse): 데이터브릭스가 제시한 가장 혁신적인 개념입니다. 방대하고 저렴하게 데이터를 저장할 수 있는 *데이터 레이크(Data Lake)의 장점과, 데이터의 품질을 보장하고 빠른 SQL 쿼리를 지원하는 *데이터 웨어하우스(Data Warehouse)의 장점을 결합한 아키텍처입니다.
아파치 스파크 (Apache Spark): 데이터브릭스의 엔진 역할을 하는 오픈소스 분산 처리 시스템입니다. 대용량 데이터를 여러 대의 컴퓨터(노드)에 분산시켜 매우 빠르게 처리할 수 있게 해줍니다.
델타 레이크 (Delta Lake): 데이터 레이크 위에 구축되는 오픈소스 스토리지 계층입니다. 기존 데이터 레이크의 단점이었던 데이터 신뢰성 문제를 해결하기 위해, 데이터베이스처럼 트랜잭션(ACID)을 지원하여 데이터의 일관성과 무결성을 보장합니다.
클러스터 (Cluster): 데이터를 처리하고 코드를 실행하기 위한 연산 자원(컴퓨팅 파워)입니다. 필요할 때만 켜서 사용하고, 작업량에 따라 자동으로 확장(Auto-scaling)되도록 설정할 수 있어 비용 효율적입니다.
노트북 (Notebook): 주피터 노트북(Jupyter Notebook)과 유사한 웹 기반의 인터페이스입니다. 하나의 문서 안에서 Python, SQL, R, Scala 등의 코드를 작성하고, 실행 결과를 바로 확인하며 시각화할 수 있어 팀원 간의 협업에 매우 유용합니다.

* 데이터 레이크 : 기업의 정형, 반정형, 비정형 데이터를 원시 형태(raw data) 그대로 저장하는 중앙 집중식 저장소

* 데이터 웨어 하우스 : 기업의 여러 소스에서 수집된 방대한 데이터를 통합, 변환하여 분석 및 의사결정에 활용하는 주제 중심의 데이터 저장소

3. 데이터브릭스 기본 사용법 (Workflow)

데이터브릭스의 실제 작업 흐름은 크게 5단계로 나눌 수 있습니다.

워크스페이스(Workspace) 셋업: 가장 먼저 클라우드 제공자(AWS, Azure, GCP)를 통해 데이터브릭스 환경을 구축합니다. 워크스페이스는 팀원들이 모여 코드를 작성하고 데이터를 탐색하는 중앙 작업 공간입니다.
클러스터(Cluster) 생성: 작업 공간 메뉴에서 Compute 탭으로 이동하여 클러스터를 생성합니다. 데이터의 크기나 작업의 목적에 맞게 인스턴스(서버)의 사양과 개수를 설정합니다.
데이터 연결 및 수집: 클라우드 스토리지(예: AWS S3, Azure Data Lake Storage)에 저장된 데이터를 데이터브릭스로 불러옵니다. Data 탭을 통해 테이블을 시각적으로 관리하거나 코드를 통해 데이터를 마운트(Mount)할 수 있습니다.
노트북을 활용한 분석 및 모델링: 새로운 Notebook을 생성하고, 생성해 둔 클러스터에 연결(Attach)합니다.
- 데이터 엔지니어는 Python(PySpark)이나 Scala를 이용해 데이터를 정제하고 변환합니다.
- 데이터 분석가는 SQL을 이용해 대시보드를 만들고 지표를 뽑아냅니다.
- 데이터 과학자는 머신러닝 라이브러리를 활용해 예측 모델을 학습시킵니다.
작업 자동화 (Jobs/Workflows): 작성이 완료된 노트북 코드는 Workflows 기능을 이용해 자동화할 수 있습니다. "매일 새벽 2시에 이 데이터 파이프라인을 실행해라"와 같이 스케줄링을 걸어두어 지속적인 데이터 처리를 자동화합니다.

4. 요약: 왜 데이터브릭스를 써야 할까요?

강력한 협업: 엔지니어, 분석가, 과학자가 동일한 플랫폼과 데이터를 보며 실시간으로 협업할 수 있습니다.
성능과 확장성: 스파크 엔진에 자체적인 최적화 기술(Photon 엔진 등)을 더해 오픈소스 스파크보다 훨씬 빠른 데이터 처리 속도를 자랑합니다.
운영 편의성: 클라우드 기반의 완전 관리형(Fully-managed) 서비스이므로, 사용자가 복잡한 인프라 구축이나 서버 관리에 신경 쓸 필요 없이 데이터 분석 자체에만 집중할 수 있습니다.

SAP S/4HANA 출력 관리의 혁명: OPD ( BRF+ )

가시가되어 — Mon, 6 Apr 2026 15:53:05 +0900

1. SAP S/4HANA에서 OPD란?

OPD (Output Parameter Determination)는
구매오더, 청구서 등 다양한 문서의 출력 방식(출력 조건, 수신자, 포맷 등)을 설정하는 기능입니다.

과거에는 NAST라는 기술을 썼습니다. S/4HANA에서는 이를 대체하는 BRF+ (Business Rule Framework plus) 기반의 새로운 출력 관리 방식이 도입되었습니다.

경로:
SPRO → Cross-Application Components → Output Control

주요 특징 (T-Code: OPD)

규칙 기반 결정: 어떤 공급업체는 이메일로, 어떤 업체는 EDI로 보낼지를 테이블 형태의 규칙(Decision Table)으로 관리합니다.
양식 최적화: Adobe Forms를 기본으로 사용하여 훨씬 미려하고 표준화된 구매 서식을 제공합니다.
확장성: 클라우드 환경(SAP BTP)과의 연동이 매우 용이합니다.

2. NAST 기반과의 차이점

SAP S/4HANA 출력 관리(Output Management)는 기존의 NAST 기반 메시지 제어 방식에서 벗어난 근본적인 패러다임의 변화를 의미하며, 주요 차이점은 다음과 같습니다.

1. 규칙 엔진 및 논리 (Rule Logic)

NAST 방식: 트랜잭션 NACE를 통해 구성되는 조건 기법(Condition Technique)과 관련 커스터마이징 테이블을 기반으로 규칙을 처리합니다.
S/4HANA 방식: 강력한 BRF+ (Business Rule Framework plus) 엔진을 활용하여 유연하고 수정 없이도 비즈니스 규칙을 정의할 수 있습니다.

2. 데이터 구조 및 저장 (Data Management)

NAST 방식: 출력 데이터를 물리적 테이블인 NAST에 직접 저장하며, 이는 기존 레거시 프레임워크에 종속적입니다.
S/4HANA 방식: APOC_D_OR_ITEM과 같은 현대적인 테이블을 기반으로 하며, 데이터 접근은 CDS View(Virtual Data Models*를 통해 이루어지므로 더 최적화되고 미래 지향적인 구조를 갖습니다.

3. 아키텍처 및 관리 체계 (Construction)

NAST 방식: SD, MM 등 각 모듈별로 중심이 분산되어 있으며 해당 애플리케이션에 강하게 결합되어 있습니다.
S/4HANA 방식: 모든 애플리케이션에 걸쳐 중앙 집중화(Centralized)된 통합 관리 체계를 제공하며, 클라우드 및 온프레미스 환경 모두에 최적화되어 있습니다.

4. 사용자 인터페이스 (User Interface)

NAST 방식: 주로 SAP GUI와 클래식 트랜잭션을 통해 제어 및 관리됩니다.
S/4HANA 방식: Fiori 앱(예: "출력 매개변수 결정(OPD)", "출력 요청 모니터링(F2279)")을 통해 직관적으로 관리하고 모니터링할 수 있습니다.

5. 양식 기술 및 채널 (Form & Channel)

NAST 방식: 주로 SAPscript나 Smart Forms를 사용하며, 양식 수정과 커스텀 필드 추가가 상대적으로 자유로운 편입니다.
S/4HANA 방식: Adobe Forms를 기본으로 사용하며 이메일, XML, EDI 등 현대적인 디지털 채널을 별도의 추가 도구 없이도 원활하게 통합 지원합니다.

요약하자면, NAST는 고도로 커스터마이징이 필요한 복잡한 레거시 프로젝트에 익숙한 방식인 반면, S/4HANA 출력 관리는 표준화, 중앙 집중식 관리, 그리고 현대적인 Fiori 사용자 경험과 디지털 채널 통합에 최적화된 최신 기술입니다

구매프로세스 개선 (W/ S4HANA, BRF+)

1. 구매 프로세스의 고질적 문제점 (AS-IS)

과거 NAST 방식이나 수동 프로세스에서는 다음과 같은 병목 현상이 발생했습니다.

복잡한 승인 후 수동 발송: PO 승인이 끝나면 담당자가 일일이 PDF를 내려받아 이메일로 발송.
유연성 부족: 특정 국가나 특정 자재 그룹에만 다른 양식을 적용하려면 ABAP 개발 공수 과다 발생.
추적 불가능: 이메일이 발송되었는지, 공급업체가 확인했는지 시스템상 확인이 어려움.

2. BRF+ 기반 프로세스 개선 전략 (TO-BE)

① 조건별 자동화 (Decision Table 기반)

T-Code: OPD를 통해 구매 조직, 그룹, 금액, 문서 유형에 따른 자동 분기를 설정합니다.

개선 포인트: 1억 미만 소모품 구매는 승인 즉시 공급업체에 자동 이메일 발송, 1억 이상 전략 자재는 담당자 검토 후 수동 발송으로 규칙화하여 불필요한 행정 소요를 줄입니다.

② 멀티 채널 및 실시간 알림 (Omni-Channel)

단순 프린트 출력을 넘어 다양한 채널을 동시에 활용합니다.

개선 포인트: 구매 오더 생성 시, 공급업체에는 EDI/Email로 공식 문서를 발송함과 동시에, 내부 물류 담당자에게는 **SAP Fiori 알림(Notification)**을 띄워 입고 준비를 시킵니다.

③ 이메일 템플릿의 현업 자율화

과거에는 메일 본문의 문구 하나를 바꾸려고 해도 개발자가 필요했습니다.

개선 포인트: 'Maintain Email Templates' 앱을 통해 구매 팀장이 직접 시즌별 공지사항이나 강조 문구(예: "추석 연휴 납기 준수 요망")를 관리합니다. IT 부서의 도움 없이 비즈니스 대응 속도가 빨라집니다.

3. IT 운영 및 관리적 관점의 개선

① 'Manage Output Items' 앱을 통한 통합 모니터링

S/4HANA 전용 Fiori 앱을 통해 모든 구매 문서의 출력 상태를 한눈에 관리합니다.

개선 포인트: 발송 실패(Error) 건만 필터링하여 즉시 재전송(Retransmit)하거나 로그를 확인할 수 있어, 공급업체와의 커뮤니케이션 누락을 원천 차단합니다.

② Adobe Forms의 데이터 바인딩 최적화

개선 포인트: QR 코드를 양식에 포함하여 공급업체가 납품 시 해당 QR을 스캔하면 바로 입고(GR) 화면으로 연결되는 시스템을 구축할 수 있습니다. 이는 물류 현장의 혁신으로 이어집니다.

[DB] SSMS(SQL Server Management Studio) 활용한 리소스 점검 방법

가시가되어 — Fri, 3 Apr 2026 16:30:21 +0900

SSMS Query Store 활용한 리소스 분석 / 점검

SQL Server 2016 버전 이상이고 Query Store가 활성화되어 있다면, 리소스 분석이 용이합니다.

특정 시간대 CPU 사용량 , 대기 시간 등을 보며 원인이 되는 쿼리를 볼 수 있습니다.

방법: SSMS(SQL Server Management Studio) → 해당 DB → Query Store(쿼리저장소) → Top Resource Consuming Queries(리소스를 가장 많이 사용하는쿼리) 선택.
설정: 우측 상단의 [Configure(구성)] 버튼을 눌러 문제가 발생했던 특정 시간(Time Range)으로 필터링하세요.
분석: 해당 시간에 갑자기 실행 횟수(Execution Count)가 늘었거나, 평소보다 논리적 읽기(Logical Reads)가 급증한 쿼리를 바로 확인할 수 있습니다.

아래에서는 각 지표별 상세 내역을 정리했습니다.

1. 실행 및 시간 관련 지표 (Execution & Time)

가장 먼저 확인해야 할 기본 지표들입니다.

실행 수 (Execution Count): 해당 쿼리가 특정 기간 동안 몇 번 실행되었는지 나타냅니다. 실행 횟수가 너무 많으면 개별 쿼리 성능이 좋아도 전체 시스템에 부하를 주는 'Death by a thousand cuts' 현상이 발생합니다.
기간 (Duration, MS): 사용자가 체감하는 쿼리 시작부터 종료까지의 전체 시간(Wall-clock time)입니다.
CPU 시간 (CPU Time, MS): 쿼리를 처리하기 위해 프로세서(CPU)가 실제로 작업한 시간입니다.
- CPU 시간 > 기간: 병렬 처리(DOP)가 활발하게 일어난 경우입니다.
- CPU 시간 < 기간: 쿼리가 CPU 작업 외에 I/O나 Lock 대기 등에 시간을 허비했음을 의미합니다.

2. I/O 성능 지표 (Data Access)

디스크와 메모리 사이의 데이터 이동 효율성을 보여줍니다.

논리적 읽기 (Logical Reads): 데이터 페이지를 **메모리(Buffer Pool)**에서 읽은 횟수입니다. 인덱스 최적화가 안 되어 있으면 이 수치가 급증합니다.
물리적 읽기 (Physical Reads): 데이터가 메모리에 없어 디스크에서 직접 읽어온 횟수입니다. 이 수치가 높으면 메모리 부족이나 'Cold Cache' 상태를 의심해야 하며, 성능 저하의 주범이 됩니다.
논리적 쓰기 (Logical Writes): 데이터 변경(Insert, Update, Delete)으로 인해 메모리 내 페이지가 수정된 횟수입니다.

3. 컴퓨팅 및 특수 지표 (Computing)

자원 할당 방식과 외부 연동에 대한 정보입니다.

CLR 시간 (CLR Time): SQL Server 내부에서 실행되는 .NET 코드(Stored Procedure, Trigger 등)를 처리하는 데 소요된 시간입니다.
DOP (Degree of Parallelism): 쿼리가 실행될 때 사용된 병렬 CPU 코어의 수입니다. DOP가 너무 높으면 코어 간 통신 오버헤드가 발생하고, 너무 낮으면 대량 조회가 느려집니다.

4. 메모리 및 저장소 지표 (Memory & Storage)

자원 점유 상태를 나타내며, 특히 특정 시간대 부하의 핵심 단서를 제공합니다.

메모리 소비 (Memory Consumption): 쿼리 실행을 위해 할당받은 작업 메모리(Grant Memory)의 양입니다. 정렬(Sort)이나 해시 조인(Hash Join) 시 많이 사용됩니다.
사용된 로그 메모리 (Log Memory Used): 트랜잭션 로그 파일(LDF)에 기록된 데이터 양입니다. 대량의 데이터 변경 시 이 수치가 치솟으며 시스템을 느리게 할 수 있습니다.
사용된 임시 DB 메모리 (TempDB Memory Used): 임시 테이블이나 중간 계산을 위해 TempDB를 사용한 양입니다. TempDB 경합은 SQL Server 전체 성능 저하의 흔한 원인입니다.

5. 병목 현상의 핵심 (Wait)

대기 시간 (Wait Time, MS): 쿼리가 자원을 점유하지 못하고 멈춰 서서 기다린 시간입니다.
- 이 시간이 길다면 무엇을 기다렸는지(Wait Type)를 분석해야 합니다. (예: 네트워크, 디스크 I/O, Lock 등)

지표 간의 논리적 연결 (Troubleshooting)

이 지표들을 조합하면 다음과 같은 진단이 가능해집니다.

논리적 읽기는 높은데 CPU 시간은 낮다? → 인덱스를 잘 타고 있지만, 메모리에서 데이터를 찾는 과정이 너무 빈번함 (인덱스 설계 재검토 필요).
물리적 읽기가 특정 시간대에만 튄다? → 해당 시간에 메모리가 부족해지거나, 평소 안 쓰던 대량의 데이터를 건드리는 쿼리가 유입됨.
기간(Duration)은 긴데 CPU 시간은 매우 짧다? → 쿼리 자체는 가벼운데, 대기 시간(Wait Time)이 긴 상태. 즉, 누군가에게 막혀(Blocking) 있거나 네트워크 문제일 가능성 농후.

[SAP] SD 2nd GI (2-Step Goods Issue) 프로세스 정리

가시가되어 — Thu, 2 Apr 2026 12:35:51 +0900

일반적인 SAP SD(Sales and Distribution) 프로세스에서는 출고(Post Goods Issue, PGI)를 한 번에 수행하지만, 글로벌 비즈니스나 복잡한 물류 환경에서는 이를 First GI와 Second GI로 나누어 관리하는 'Stock in Transit (SIT, 운송 중 재고)' 프로세스를 활용합니다.

1. 수익 인식(Revenue Recognition) 시점의 일치

가장 중요한 이유는 재무적 관점에서의 수익 인식 시점 때문입니다.

First GI (출고 시작): 우리 창고에서 물건이 나가는 시점입니다. 이때 재고는 우리 창고(Storage Location)에서는 빠지지만, 아직 고객에게 전달된 것은 아닙니다.
Second GI (소유권 이전): 인코텀즈(Incoterms) 조건(예: DDP, DAP)에 따라 고객에게 물건이 도착하거나 선적이 완료되어 법적 소유권이 이전되는 시점입니다.
이유: IFRS 15 등 회계 기준에 따라 '통제권'이 이전되는 시점에 매출을 인식해야 하므로, 실제 배송 완료 시점에 맞춰 Second GI를 발생시켜 매출과 매출원가(COGS)를 정확히 매칭시킵니다.

2. 운송 중 재고(Stock in Transit) 가시성 확보

물건이 창고를 떠났지만 아직 고객에게 도착하지 않은 상태의 재고를 시스템적으로 관리하기 위함입니다.

First GI: 일반 재고에서 '운송 중 재고(SIT)' 계정으로 자산의 성격이 변합니다.
Second GI: 운송 중 재고 계정에서 고객에게로 재고가 최종 낙하합니다.
이유: 기업은 운송 중인 수십억 원 상당의 재고가 현재 어디에 있으며, 누구의 자산인지 실시간으로 파악해야 합니다. 이를 나누지 않으면 창고에서 나가는 순간 장부에서 재고가 사라져 버리는 'Blind Spot'이 발생합니다.

3. 인코텀즈(Incoterms)와의 정합성

수출입 비즈니스에서는 운송 책임과 위험 전가 시점이 매우 다양합니다.

EXW(공장 인도): First GI와 동시에 소유권이 이전되어도 무방합니다.
D-Condition(도착지 인도): 물건이 고객 문 앞에 도착해야 소유권이 이전됩니다.
이유: First GI는 '물리적 출고'를, Second GI는 '법적/계약적 인도'를 의미하게 함으로써 물류 현장과 계약 조건 사이의 간극을 메웁니다.

4. 수입/통관 및 문서 처리의 유연성

특히 국가 간 이동 시, 물건이 보세 구역에 머물거나 통관 대기 중인 상태를 시스템이 반영해야 합니다.

First GI 이후 발행되는 선하증권(B/L)이나 통관 서류가 확정된 후, 실제 고객에게 인도되는 시점에 Second GI를 처리함으로써 물류 프로세스의 정합성을 높입니다.

요약 및 SAP 기술적 관점

SAP S/4HANA에서는 Advanced Returns Management 또는 SIT(Stock in Transit) 기능을 통해 이를 구현합니다. 주로 다음과 같은 이동 유형(Movement Type)이 사용됩니다.

구분	주요 목적	SAP 이동 유형 (예시)
First GI	창고 출고 및 운송 중 재고로 이전	681 (Issuing plant to SIT)
Second GI	고객 인도 및 매출원가 발생	683 (SIT to Customer), 601

이러한 분리 프로세스를 통해 기업은 재고 자산의 정확한 평가, 수익 인식의 투명성, 그리고 공급망 전체의 가시성을 확보하게 됩니다.

PoD - Proof of Delivery 유형으로 처리할 수도 있습니다.

배송 증명으로, 1차 출고는 공장 - 2차 출고는 고객(거래처)에서 직접 물건을 인수했을 때 발생합니다. 이렇게 고객이 물건을 직접 인수한 이후에 출고와 빌링을 진행하는 것으로, T-code : VLPOD 를 통해 처리할 수 있습니다.

[SAP SCM] STO(Stock Transport Order)란?

가시가되어 — Wed, 1 Apr 2026 16:20:42 +0900

[SAP SCM] STO(Stock Transport Order) 완벽 가이드

기업의 규모가 커지면 단순히 한 창고 안에서 물건을 옮기는 것을 넘어, 플랜트(Plant) 간, 혹은 법인(Company Code) 간의 재고 이동이 빈번하게 발생합니다. (복잡한 물류 흐름과 재고 부족 등을 대응)

이때 가장 표준적이고 강력한 도구가 바로 STO(Stock Transport Order)입니다.

오늘은 STO의 개념부터 시작하여 SAP에서 구현되는 단계별 프로세스를 상세히 파헤쳐 보겠습니다.

1. STO(Stock Transport Order)란 무엇인가?

STO는 이름 그대로 '재고를 운송하기 위한 구매 오더'입니다.

외부 업체가 아닌, 조직 내부의 플랜트(Plant) 간 자재를 조달하기 위해 작성하는 특수한 구매 문서입니다.

이는 단순한 자재의 물리적 이동을 넘어, 시스템상에서 재고 가시성(Visibility)을 확보하고 입고 예정 정보를 바탕으로 정교한 재고 계획(MRP)을 수립할 수 있게 하는 내부 조달의 핵심 도구입니다.

일반적인 PO(Purchase Order)가 외부 업체로부터 물건을 사오는 것이라면, STO는 우리 회사 내부(또는 계열사)의 다른 플랜트로부터 재고를 공급받는 것입니다.

왜 단순 재고 이동(Transfer Posting) 대신 STO를 쓸까요?

단순히 MIGO에서 301/311 이동 유형을 쓸 수도 있지만, STO를 사용하면 다음과 같은 강력한 장점이 있습니다.

MRP 연동: 받는 플랜트에서는 입고 예정 정보로, 보내는 플랜트에서는 출하 예정 정보로 인식됩니다.
운송 비용 처리: 운송비(Freight)를 구매 오더 조건(Condition)에 포함해 원가에 반영할 수 있습니다. 배송 과정에서 발생하는 운임이나 부대비용을 오더에 직접 입력하여, 자재 원가에 정확하게 배부할 수 있습니다
프로세스 가시성: 출하, 운송 중 재고(Stock in Transit), 입고 단계를 명확히 추적할 수 있습니다. 오더 생성부터 출하, 입고에 이르는 모든 단계가 Purchase Order History에 남습니다.
납기 관리: 납기일과 운송 기간을 고려한 계획 수립이 가능합니다.
정교한 물류 통합 (SD 연동) : STO는 물류(SD/LE) 모듈의 출하(Delivery) 기능과 연동됩니다. 이를 통해 창고에서의 피킹(Picking), 패킹(Packing) 작업을 표준화된 물류 흐름 안에서 관리할 수 있습니다.

2. STO의 주요 유형

SAP에서는 크게 두 가지 시나리오로 나뉩니다.

① Intra-Company STO (법인 내 플랜트 간 이동)

특징: 동일한 법인(Company Code) 내에서 플랜트만 다른 경우입니다. 법적으로는 한 몸이기 때문에 청구(Billing)가 필요하지 않으며, 단순한 내부 원가 이전으로 처리됩니다.
문서 유형: 주로 UB 타입을 사용합니다.
프로세스 요약: 구매 오더 생성 → 출하(Delivery) → 입고.

② Inter-Company STO (법인 간 이동 / Cross-Company)

특징: 서로 다른 법인 간의 이동입니다. 법적으로 주인이 바뀌는 것이므로 '판매'와 '구매'의 성격을 동시에 가집니다. , 사내거래단가(T-Code: AKE7) 관리가 매우 중요합니다.
문서 유형: 주로 NB 타입을 사용합니다.
특징: 반드시 Billing(송장 발행) 과정이 포함되어야 합니다.

자재 이동의 기술적 방식: 1단계(1-Step) vs 2단계(2-Step) 프로세스

1단계(1-Step) 프로세스 (이동 유형: 301)
- 출고 플랜트에서 던지면 입고 플랜트가 동시에 받는 방식입니다. 출고와 입고 기표가 한 번에 일어납니다.
- 장점: 프로세스가 단순하고 빠릅니다.
- 시나리오: 공장 내 옆 건물 창고로 옮기는 등 운송 시간이 무시할 수준일 때 사용합니다.
2단계(2-Step) 프로세스 (이동 유형: 351, 641 등)
- 출고 시 일단 자재를 '운송 중 재고(Stock in Transit)'라는 가상의 공간에 띄워둡니다. 이후 물건이 실제 도착하면 별도로 입고 처리를 합니다.
- 장점: '길 위에 있는 재고'의 수량과 책임 소재를 명확히 할 수 있습니다. 만약 가다가 사고가 난다면, 현재 장부상 어디에 있는지 바로 알 수 있죠.
- 시나리오: 대륙 간 이동이나 지역 간 배송 등 운송 시간이 소요되는 대부분의 실무에서 권장됩니다.

3. 단계별 프로세스 상세 정리

프로세스는 크게 '출하(Shipping)' 기능 포함 여부에 따라 달라지지만,

여기서는 가장 표준적인 SD-MM 연동 STO를 기준으로 설명합니다.

1단계: STO 생성 (T-Code: ME21N)

받는 플랜트(Receiving Plant)에서 오더를 생성합니다. 이때 공급 플랜트(Supplying Plant)를 Vendor처럼 지정합니다.

2단계: 출하 지시 및 배송 생성 (T-Code: VL10B)

공급 플랜트에서 물건을 보낼 준비를 합니다.

SAP SD 모듈의 'Outbound Delivery' 기능을 활용해 피킹(Picking)과 패킹(Packing) 과정을 관리합니다.

3단계: 출고 전기 (Goods Issue, T-Code: VL02N)

물건이 우리 공장을 떠나는 시점입니다.

Intra-Company: 이동 유형 641 사용. 재고는 '운송 중 재고(Stock in Transit)'로 인식됩니다.
Inter-Company: 이동 유형 643 사용.

4단계: 입고 처리 (Goods Receipt, T-Code: MIGO)

물건이 받는 플랜트에 도착하면 입고를 잡습니다.

이동 유형 101을 사용하여 운송 중 재고를 가용 재고로 전환합니다.

5단계: Billing 및 송장 처리 (Inter-Company 전용)

법인이 다를 경우, 보내는 쪽에서는 SD Billing(VF01)을 통해 매출을 인식하고, 받는 쪽에서는 FI/MM Invoice Verification(MIRO)를 통해 매입 채무를 생성합니다.

4. STO 설정 시 주의사항

STO가 제대로 돌지 않는다면 다음 세 가지를 체크해 보세요.

Customer/Vendor Master 연결: 공급 플랜트는 Vendor로, 받는 플랜트는 Customer로 서로 마스터가 생성되어 있어야 합니다.
Shipping Point 결정: 플랜트와 하역 지점(Loading Point) 설정이 정확해야 배송 문서가 생성됩니다.
Stock in Transit 확인: 물건은 나갔는데 입고가 안 되었다면 MB5T 티코드를 통해 운송 중인 재고를 상시 모니터링해야 합니다.

마치며

STO는 SAP SCM의 MM, SD, FI 모듈이 만나는 접점입니다.

이 프로세스를 정확히 이해하면 물류 흐름의 전체적인 메커니즘을 파악하는 데 큰 도움이 됩니다.

복잡해 보이지만, "우리 회사 물건을 효율적으로 옮기고 관리하기 위한 구매 주문"이라는 핵심만 기억하세요!

터보퀀트란? - AI 메모리 혁신과 반도체 시장 전망

가시가되어 — Tue, 31 Mar 2026 12:02:33 +0900

터보퀀트( TurboQuant ): AI 메모리 혁신과 시장 전망

챗GPT나 제미나이(Gemini) 등 생성형 AI와 대화를 나누다 보면, 대화가 길어질수록 답변 속도가 눈에 띄게 느려지거나 서비스 이용료가 부담스럽게 느껴지는 순간이 있습니다. 이는 AI가 이전 대화의 맥락을 기억하기 위해 사용하는 임시 저장 공간인 ‘KV 캐시(Key-Value Cache)’에 과부하가 걸리기 때문입니다. 문맥이 길어질수록 이 데이터는 기하급수적으로 불어나며, 이는 곧 하드웨어의 성능 저하와 천문학적인 운영 비용으로 직결됩니다.

최근 구글 리서치가 발표한 '터보퀀트(TurboQuant)'는 이 고질적인 ‘메모리 병목’ 문제를 수학적으로 해결한 혁신 기술입니다.

1. 기술의 핵심 원리: 'KV 캐시' 압축

AI 모델, 특히 챗봇은 사용자와의 긴 대화 문맥을 기억하기 위해 'KV 캐시(Key-Value Cache)'라는 임시 메모리 공간을 사용합니다. 대화나 데이터가 길어지고 복잡해질수록 이 공간이 기하급수적으로 커져 GPU 메모리 병목 현상을 일으키는 것이 기존 AI의 큰 한계였습니다.

터보퀀트는 이 데이터를 극단적으로 압축하는 알고리즘으로, 한국과학기술원(KAIST) 한인수 교수 등이 개발에 핵심적으로 참여했습니다.

작동 방식: 소수점 아래로 길게 늘어진 복잡한 연산 데이터를 반올림해 근사치인 정수로 단순화합니다. (예: 92.4571점을 9점으로 기록) 마치 옷의 부피를 줄이는 '압축팩'처럼, 핵심 정보의 퀄리티는 유지하면서 저장 용량과 연산 부담을 크게 줄입니다.
성능 향상: 별도의 추가 학습 없이 이미 학습된 모델에 즉시 적용 가능하며, 메모리 사용량을 최대 6분의 1 수준으로 감축할 수 있습니다. 또한, 엔비디아 H100 GPU 환경 기준으로 특정 연산(어텐션) 속도를 최대 8배까지 높일 수 있습니다.

핵심은 '정보의 손실을 최소화하면서 부피만 줄이는 것'입니다.

이번 연구를 주도한 KAIST 전기및전자공학부 한인수 교수는 이를 다음과 같이 명쾌하게 설명합니다.

"소수점으로 길게 늘어진 데이터를 반올림해 근사치인 정수로 만들면 핵심 정보는 유지하면서 저장 용량과 연산 부담을 줄일 수 있다. 가령 한 학생의 성적이 92.4571점이라면 이를 '10점 만점 중 9점'으로 표현해 기록에 필요한 칸(메모리)을 줄이면서도 성적의 내용은 충분히 전달하는 식이다."

재학습이 필요 없는 '드롭인(Drop-in)'

기존의 양자화 기술은 모델을 다시 훈련하거나 미세 조정(Fine-tuning)하는 번거로운 공정이 필수적이었습니다. 반면 터보퀀트는 '데이터 비의존성(Data-oblivious)'이라는 강력한 비즈니스적 무기를 갖추고 있습니다. 이는 기업이 이미 구축한 AI 모델(Llama, Gemma, Mistral 등)에 별도의 재학습 비용(CapEx) 없이 즉시 적용 가능한 '드롭인' 방식임을 시사합니다.

극좌표 변환(PolarQuant)을 통한 효율 극대화, QJL(양자화된 존슨-린덴스트라우스 변환) 기법으로 오차 보정 및 정확도 유지, 추가 학습 없이 즉시 적용이 가능합니다. 특히 QJL 기법은 압축 과정에서 발생하는 미세한 오차를 부호 비트로 보정하는 '정밀 튜너' 역할을 수행하여, 데이터 압축 후에도 원본 모델과 거의 동일한 성능을 유지하게 합니다. 이는 기업 입장에서 막대한 컴퓨팅 자원과 시간 비용을 '제로'로 만드는 경제적 기적과 같습니다.

2. 반도체 주가를 폭락시킨 '효율화 쇼크'의 진실

터보퀀트 발표 직후 시장은 민감하게 반응했습니다. 삼성전자, 하이닉스를 비롯 글로벌 메모리 반도체 기업들의 주가가 급락하며 투자 심리가 급격히 냉각되었습니다.

시장은 "AI가 메모리를 6분의 1만 쓴다면 메모리 반도체 수요가 꺾일 것"이라는 공포, 즉 'HBM 슈퍼사이클 종료'를 우려한 것입니다.

하지만 이는 기술의 본질을 오해한 '성급한 진단'입니다.

터보퀀트가 최적화하는 영역은 GPU 내부의 임시 저장 공간(KV 캐시)에 한정됩니다.

오히려 전문가들은 이 기술이 AI 추론 비용을 낮춰, 그간 비용 부담으로 도입을 망설였던 기업들을 시장으로 유입시키는 촉매제가 될 것으로 포착하고 있습니다.

즉, 하드웨어 수요의 감소가 아니라 하드웨어의 활용 가능 범위가 무한히 확장되는 신호로 해석해야 합니다.

'제본스의 역설'과 다다익램

다수의 테크 및 증권가 전문가들은 이를 '치명적 착각'이자 과도한 우려로 평가합니다.

오히려 이 기술이 장기적으로 AI와 메모리 생태계를 더 확장시킬 촉매제라는 분석이 지배적입니다.

제본스의 역설(Jevons Paradox): 기술의 발전으로 자원 사용 효율이 높아지면, 구동 비용이 저렴해져 역설적으로 해당 자원의 전체 소비량이 늘어나는 현상입니다.
AI 고도화: 메모리 효율이 극대화되면 기업들은 남는 여유 자원을 이용해 훨씬 더 거대하고 복잡한 추론을 수행하는 '에이전틱 AI(Agentic AI)' 모델을 도입할 수 있습니다. 결국 더 많은 기기에서, 더 방대한 데이터를 처리하게 되므로 "메모리는 많을수록 좋다(다다익램)"는 법칙은 깨지지 않을 것이라는 전망입니다.
온디바이스 AI 시대의 도래: 메모리 제약이 극심한 스마트폰이나 노트북에서도 무거운 LLM을 구동할 수 있게 됩니다. 이는 모든 개인 기기에 고성능 메모리 탑재를 강제하는 새로운 시장 기회를 창출합니다.

결론: AI 슈퍼컴퓨터를 주머니 속에 넣는 시대

구글의 터보퀀트는 단순한 데이터 압축 기술 그 이상을 의미합니다.

이는 AI 산업의 패러다임이 '무한한 자원 투입'에서 '똑똑한 효율의 시대'로 전환되었음을 선언하는 이정표입니다.

메모리 효율화는 AI 인프라의 문턱을 낮추고, 생성형 AI의 발전을 가속하여 결국 전체 반도체 생태계의 파이를 키우는 강력한 엔진이 될 것입니다.

Amplitude란? 고객데이터분석 개념 소개

가시가되어 — Mon, 30 Mar 2026 11:15:56 +0900

디지털 제품을 만드는 팀에게 있어 "사용자가 우리 서비스에서 정확히 무엇을 하고 있는가?"라는 질문은 성패를 결정짓는 핵심입니다.

단순히 페이지 뷰나 방문자 수를 세는 것을 넘어, 사용자의 행동 패턴을 파고들어 성장의 실마리를 찾아주는 도구가 바로 Amplitude(앰플리튜드)입니다.

2026년 현재, 데이터 분석의 패러다임을 '단순 집계'에서 'AI 기반 예측과 실행'으로 바꾸고 있는 Amplitude에 대해 자세히 소개해 드립니다.

Amplitude란 무엇인가요?

Amplitude는 세계 1위의 프로덕트 분석(Product Analytics) 플랫폼입니다. 기존의 마케팅 중심 분석 도구(예: GA4)가 "사용자가 어디서 왔는가?"에 집중한다면, Amplitude는 "사용자가 들어와서 어떤 경험을 했고, 왜 다시 돌아오며(혹은 떠나며), 어떻게 하면 결제하게 만들 수 있는가?"라는 질문에 답을 줍니다.

전 세계 2,700개 이상의 기업과 포춘 100대 기업 중 상당수가 Amplitude를 통해 데이터 기반의 의사결정을 내리고 있습니다.

Amplitude의 핵심 기능 (2026년 업데이트 포함)

1. 행동 코호트(Behavioral Cohorts) 분석

특정 행동을 한 사용자 그룹을 묶어서 분석하는 기능입니다. 예를 들어 "최근 7일간 장바구니에 담기만 하고 구매하지 않은 유저"나 "가입 첫날 핵심 기능을 3번 이상 사용한 유저"를 단 몇 초 만에 분류하여 이들의 리텐션(재방문율)을 비교할 수 있습니다.

2. 퍼널(Funnel) 및 전환 분석

사용자가 목표 지점(예: 구매 완료)까지 가는 과정에서 어디서 가장 많이 이탈하는지 정교하게 추적합니다. 단순히 이탈률만 보여주는 게 아니라, '어떤 행동이 전환에 긍정적인 영향을 미쳤는지(Conversion Drivers)'를 AI가 분석해 줍니다.

3. 리텐션(Retention) 분석

제품의 건강함을 나타내는 가장 중요한 지표인 리텐션을 분석합니다. 사용자가 제품을 '습관'처럼 쓰게 만드는 지점이 어디인지(Magic Moment)를 찾아내는 데 최적화되어 있습니다.

4. Amplitude AI: 이제 데이터 분석도 에이전트가 합니다

2026년 Amplitude의 가장 큰 특징은 강력한 AI 통합입니다.

Ask AI: "지난달 대비 결제 전환율이 떨어진 이유를 차트로 그려줘"라고 자연어로 입력하면 즉시 분석 결과가 생성됩니다.
AI Agents: 24시간 데이터를 모니터링하며 이상 징후를 발견하고, 원인을 분석해 A/B 테스트 가설까지 제안합니다.
AI Visibility: 검색 엔진이나 생성형 AI 답변에서 우리 브랜드가 얼마나 노출되고 있는지 분석하는 최신 기능도 제공합니다.

5. MTUs(MTU, Monthly Tracked Users)

한달 동안 하나 이상의 이벤트를 발생시키는 고유 사용자 트래킹
하나의 프로젝트에서 월 단위로 얼마나 많은 이벤트가 발생하느지에 관계없이 이를 단일 MTU로 계산
동일한 사용자가 복수의 프로젝트에 속한 경우, 각 프로젝트에서 별도로 MTU 계산함.
MTU는 곧 비용과 직결되기 때문에 다음과 같은 상황을 경계해야 합니다.
1. 익명 사용자 폭증: 로그인 전의 Device ID와 로그인 후의 User ID가 제대로 매핑(Identity Resolution)되지 않으면, 한 명의 사용자가 2명의 MTU로 잡혀 비용이 낭비될 수 있습니다.
2. 테스트 데이터: 내부 개발팀이나 QA 과정에서 발생하는 이벤트가 Production 프로젝트로 쏘아지고 있다면, 실제 고객이 아닌데도 MTU를 점유하게 됩니다. (프로젝트 분리가 필수인 이유입니다.)
3. 스팸/봇: 비정상적인 경로로 유입되는 봇(Bot)이 이벤트를 발생시켜도 MTU로 집계됩니다.
보다 더 자세한 기능을 찾고 싶으시다면, 앰플리튜드의 기능 공식문서 - Amplitude Documentation | Amplitude

Amplitude Documentation | Amplitude

Amplitude Experiment An experimentation solution that unites everything you need to test, analyze, and optimize your product at scale.

amplitude.com

Amplitude vs Google Analytics 4 (GA4)

많은 분이 궁금해하시는 두 도구의 차이점을 표로 정리해 보았습니다.

비교 항목	Google Analytics 4 (GA4)	Amplitude
주요 목적	마케팅 성과 및 광고 효율 측정	사용자 행동 분석 및 제품 성장(Retention)
분석 단위	세션 및 이벤트 중심	사용자(User) 중심
강점	구글 광고 플랫폼과의 연동	깊이 있는 유저 여정 분석 및 코호트 생성
실시간성	데이터 처리 지연 발생(최대 24~48시간)	실시간 데이터 반영
적합한 팀	퍼포먼스 마케팅팀	프로덕트 팀(PM), 그로스 마케터, 데이터 분석가

Amplitude, 어떻게 시작하면 좋을까?

Amplitude는 스타트업을 위한 강력한 무료 플랜(Starter)을 제공합니다. 월간 5만 명 이상의 사용자 행동을 무료로 분석할 수 있어, 초기 서비스가 데이터를 쌓기 시작하기에 부족함이 없습니다.

단 무료 플랜의 기능적으로 제한된 부분이 존해합니다.

또한 MTU는 5만명 / 이벤트는 1000만건으로 제한되며, 이를 초과할 시 페이지 내 CDN 호출 시, 요청한 리소스에 접근하거나 API를 사용하기 위해 결제가 필요한 402 에러가 발생됩니다.

도입 시 체크리스트

이벤트 설계: "클릭" 하나하나가 아닌, 비즈니스에 의미 있는 사용자 행동(예: 상품 조회, 구독 시작)을 먼저 정의하세요.
SDK 설치: 웹, iOS, Android 등 환경에 맞는 SDK를 설치하여 데이터를 전송합니다.
대시보드 구축: 팀 전체가 함께 볼 수 있는 핵심 지표(KPI) 보드를 구성하세요.

결론: 데이터로 '추측'하지 말고 '확신'하세요

이제 데이터 분석은 특정 전문가의 영역이 아닙니다. Amplitude는 복잡한 SQL 쿼리 없이도 PM과 마케터가 직접 데이터를 뜯어보고 실험할 수 있는 환경을 만들어 줍니다.

사용자가 우리 제품의 어디에서 매력을 느끼고, 어디에서 지루함을 느끼는지 궁금하시다면 지금 바로 Amplitude 한국어 공식 홈페이지에서 시작해 보세요.

[SAP] Green Ledger란 무엇인가? SAP 탄소회계 솔루션

가시가되어 — Fri, 27 Mar 2026 13:52:48 +0900

[SAP 트렌드] 이제 탄소도 '돈'처럼 관리한다? SAP Green Ledger 완벽 정리

오늘날 글로벌 기업들은 CSRD(기업 지속가능성 보고 지침), CBAM(탄소 국경 조정제도) 등 전례 없는 규제 압박과 ‘탄소 감축’이라는 실존적 과제에 직면해 있습니다.

이제 탄소 배출량은 단순한 환경 지표가 아닙니다. 기업의 대차대조표와 손익에 직접적인 영향을 미치는 재무적 '부채(Liability)'이자 리스크입니다.

하지만 많은 기업이 여전히 탄소 배출량을 '연말에 한 번 엑셀로 추정'하는 수준에 머물러 있죠.

오늘은 SAP가 제시하는 지속가능성 경영의 게임 체인저, SAP Green Ledger(녹색 원장)는 SAP BTP(Business Technology Platform)를 기반으로 S/4HANA와 긴밀히 통합되는 이 솔루션은 탄소를 현금처럼 관리할 수 있는 기술적 토대를 제공합니다.

1. Green Ledger란 무엇인가? (개념 잡기)

과거의 탄소 관리가 "작년에 이만큼 썼으니 대략 이 정도 배출했겠지?"라는 사후 추정(Top-down) 방식이었다면,

Green Ledger는 실시간 트랜잭션(Bottom-up) 방식입니다. 재무 회계의 근간인 '복식부기(Double-entry accounting)' 원리를 탄소 데이터에 이식하여 탄소 배출량을 단순한 숫자가 아니라 재무적 실체가 있는 계정으로 처리합니다.

탄소 전환 계정(Carbon Transition Account), 온실가스 부채 계정(GHG Liabilities Account), 이월 온실가스 부채(Retained GHG Liabilities)와 같은 실제 G/L(일반 분개) 계정 구조를 활용합니다

스마트하고 신뢰할 수 있는 규제는 물론, 공급망 전반에 걸친 정확한 배출량 데이터는 필요한 투자를 촉진하는 데 매우 중요합니다.”라고 SAP SE의 CFO 겸 이사회 멤버인 도미닉 아삼은 말했습니다. “평균값이 아닌 실제 데이터(합리적인 신뢰도로 감사된 데이터)를 활용해야만 무임승차와 그린워싱을 방지하고, 소중한 투자와 지구를 보호할 수 있습니다. SAP 그린 레저는 바로 이러한 요구를 충족합니다.” - https://news.sap.com/2024/12/sap-green-ledger-general-availability/

2. 왜 지금 Green Ledger인가? (핵심 특징)

SAP 공식 자료에 따르면, Green Ledger는 단순한 리포팅 도구가 아닌 ERP의 Core에 통합된 솔루션입니다.

실제 데이터 기반(Actuals, not Estimates): 산업 평균치가 아닌, 실제 공급업체로부터 받은 데이터와 우리 공장의 실측 데이터를 기반으로 탄소를 계산합니다.
재무와 탄소의 결합: S/4HANA Finance 내에서 금액(Currency)과 탄소(CO2e)를 동시에 관리합니다. "이 제품을 만드는데 10달러가 들었고, 2kg의 탄소가 발생했다"는 것을 한눈에 알 수 있습니다.
규제 대응의 끝판왕: 유럽의 탄소국경조정제도(CBAM)나 글로벌 ESG 공시 의무화에 대응할 수 있는 '감사 가능한(Audit-ready)' 데이터를 생성합니다.

3. Green Ledger가 작동하는 과정 (Step-by-Step)

구매 단계: 공급업체로부터 원재료의 탄소 발자국 데이터를 전송받습니다.
생산/물류 단계: 공정에서 발생하는 에너지 소비량과 운송 거리를 반영하여 제품 단위(SKU)별로 탄소를 배부합니다.
결산 단계: 월말 재무 결산과 함께 탄소 결산을 진행하여, 기업의 전체 '탄소 손익'을 산출합니다.
의사결정: 경영진은 '수익성'과 '탄소 효율성'을 동시에 고려하여 최적의 공급망 전략을 세웁니다.

4. SCM과 Finance 전문가가 주목해야 할 이유

Green Ledger는 특정 부서의 업무가 아닙니다.

SCM 전문가에게는 탄소 배출이 적은 공급망(Green Supply Chain)을 설계할 수 있는 가시성을 제공합니다.
재무 컨설턴트에게는 탄소를 '비용'으로 인식하여 세무 및 자금 계획에 반영할 수 있는 틀을 제공합니다.
현업 컨설턴트와 IT 전문가들에게 SAP 그린 레저는 거대한 기회의 문입니다. 2027년 S/4HANA 마이그레이션이 정점에 달하기 전, 2026년은 탄소 회계 의무화에 따른 '골든 이어(Golden Year)'가 될 것입니다.

놀라운 사실은 기존 FI(재무), MM(자재 관리) 컨설턴트들이 보유한 비즈니스 로직의 80% 이상이 그린 레저에서도 그대로 활용된다는 점입니다. 다만, SAP BTP와 Sustainability Control Tower에 대한 기술적 이해가 더해져야 합니다. 현재 유럽과 미국 시장에서 그린 레저 전문가의 일일 단가(Daily Rate)는 $1,500에서 $2,000 수준에 육박하며, 이는 '지속가능성 프리미엄(Sustainability Premium)'이라 불릴 만큼 높은 가치를 인정받고 있습니다.

5. 마무리하며: 비즈니스의 새로운 표준

탄소 회계는 이제 선택이 아닌 생존을 위한 '새로운 표준'입니다. 탄소를 현금처럼 관리하고, 환경적 영향을 대차대조표의 필수 요소로 통합하는 기업만이 저탄소 경제 체제에서 진정한 승자가 될 수 있습니다.

이제는 탄소의 재무적 가치를 증명하고 이를 통해 비즈니스를 혁신해야 할 때입니다.

SAP Green Ledger는 기업이 지속가능한 성장을 수치로 증명할 수 있게 돕는 가장 강력한 도구입니다.

SAP 러닝허브에서 SAP Sustainability Footprint Management나 S/4HANA Cloud 관련 커리큘럼을 통해 이 흐름을 선점하시길 권장합니다.

SAP CTS & STMS 배포 방법 정리 (Import 옵션, Landscape)

가시가되어 — Thu, 26 Mar 2026 11:07:44 +0900

SAP 시스템에서 개발한 프로그램이나 설정(Customizing)을 운영 서버로 옮길 때, 단순히 복사·붙여넣기를 할 수는 없습니다.

시스템의 무결성을 유지하며 안전하게 변경 사항을 배포하는 체계가 바로 CTS입니다.

그리고 T-CODE : STMS를 이용해서 배포를 진행합니다. 이에 대해서 자세히 알아봅시다.

1. CTS와 STMS, 무엇이 다른가요?

용어가 비슷해 헷갈릴 수 있지만, 역할은 명확히 구분됩니다.

CTS (Change and Transport System): 변경 사항을 기록하고, 이를 다른 시스템으로 전달하는 전체적인 메커니즘과 도구 모음을 의미합니다.
STMS (SAP Transport Management System): CTS를 화면에서 관리할 수 있게 해주는 관리 도구(Transaction)입니다. 시스템 Landscape 구성, 전송 경로 설정, Import 모니터링 등을 수행

2. SAP 시스템 Landscape와 배포 옵션

효율적인 배포를 위해서는 우리 회사의 시스템 구성(Landscape)에 맞는 전략이 필요합니다.

✅ 표준 3-Tier 전략 (가장 권장됨)

DEV (Development): 개발 및 커스터마이징이 일어나는 곳.
QAS (Quality Assurance): 운영 배포 전, 비즈니스 프로세스를 검증하는 곳.
PRD (Production): 실제 비즈니스가 운영되는 실전 환경.

✅ 2-Tier 전략 (소규모 프로젝트)

DEV -> PRD: 별도의 검증 서버 없이 바로 운영으로 넘깁니다. 비용은 저렴하지만, 오류 발생 시 운영 시스템에 치명적인 영향을 줄 수 있어 리스크가 큽니다.

✅ Multi-Track 배포 (대규모/고도화)

프로젝트용 개발 서버와 유지보수용 개발 서버를 분리하여 운영하는 방식입니다. 병렬 개발 후 나중에 소스를 병합(Merge)하는 고난도 운영 기술이 필요합니다.

STMS 주요 구성

1. Transport Route

DEV → QAS → PRD 흐름 정의
Delivery / Consolidation Route 존재

실수 포인트
잘못된 client / system으로 라우팅되면 배포 오류 발생

2. Import Queue

각 시스템에 들어갈 TR 대기 목록
순서 매우 중요 ⚠️

순서 꼬이면:

Activation error
Object overwrite
Dump 발생

⚙️ CTS 배포 옵션 (Import Options)

STMS → Import Transport Request → Options에서 설정

1. Execution Mode

✔ Import Synchronously (Sync)

현재 세션에서 완료까지 대기
운영 배포 기본

✔ Import Asynchronously (Async)

백그라운드 실행
대량 배포 시 사용

핵심:

결과는 같지만 순서/안정성 영향 있음

️ SAP STMS Import Options 상세 정리

1. 최종 Import 큐에서 전송요청 중단 (Leave Transport Request in Queue for Later Import)

의미: 전송 요청(TR)을 가져온 후에도 해당 항목을 임포트 큐에서 삭제하지 않고 남겨둡니다.
용도: 나중에 모든 요청을 한 번에 가져올 때(Import All) 올바른 순서로 다시 가져올 수 있도록 합니다. 특히 개별 요청을 미리 가져오는 '사전 가져오기' 상황에서 유용하며, 나중에 정기적으로 전체 요청을 가져올 때 오래된 객체가 최신 객체를 덮어쓰는 '오버슈터(Overshooter)' 문제를 방지할 수 있습니다.

2. 전송 요청 다시 Import (Import Transport Request Again)

의미: 이미 성공적으로 임포트가 완료된 TR이라도 다시 한번 임포트를 수행하도록 합니다.
용도: 변경된 설정을 다시 적용해야 하거나, 시스템 오류로 인해 일부 객체가 제대로 반영되지 않았을 때 문제를 해결하기 위해 사용합니다.

3. 오리지널 겹쳐쓰기 (Overwrite Originals)

의미: 대상 시스템에 있는 객체가 '오리지널(Original)'인 경우에도 전송된 객체로 덮어씁니다.
용도: 대상 시스템의 객체가 원본이라 하더라도 개발 서버 등에서 수정된 최신 버전으로 강제 교체해야 할 때 사용합니다. 이 옵션을 선택하지 않으면 "Original object cannot be replaced"와 같은 에러가 발생할 수 있습니다.

4. 미확정된 수리에서 오브젝트 겹쳐쓰기 (Overwrite Objects in Unconfirmed Repairs)

의미: 대상 시스템에서 해당 객체가 수정(Repair) 중이거나 아직 수리 확인(Confirm)이 되지 않은 상태라도 임포트를 진행하여 덮어씁니다.
용도: 시스템에서 아직 확인되지 않은 수리 작업이 존재하지만, 전송된 TR을 통해 강제로 내용을 반영해야 할 때 유용합니다.

5. 허용되지 않는 전송유형 무시 (Ignore Invalid Transport Type)

의미: 전송 프로필(TP Profile) 설정에 의해 특정 시스템으로의 이관이 제한된 전송 유형이라 하더라도 이를 무시하고 임포트합니다.
용도: 특수한 프로젝트 상황에서 제한된 유형의 요청을 강제로 가져와야 할 때 사용합니다.

6. 허용되지 않는 테이블 클래스 무시 (Ignore Invalid Table Class)

의미: 테이블의 **딜리버리 클래스(Delivery Class)**가 데이터 임포트를 허용하지 않는 설정이라도 이를 무시하고 데이터를 이관합니다.
용도: 기본적으로 보호되거나 제한된 클래스의 테이블 데이터를 강제로 반영해야 할 때 사용하지만, 데이터 일관성에 영향을 줄 수 있으므로 주의가 필요합니다.

7. 선행 프로세서 관계 무시 (Skip Predecessor Relationships)

의미: 여러 TR 간의 종속성이나 선행 관계를 무시하고 임포트를 진행합니다.
용도: 특정 프로젝트의 요청만 가져오고 싶은데 다른 프로젝트의 요청과 연관성이 있어 이관이 막히는 경우 사용할 수 있습니다. 하지만 종속 관계를 무시하면 시스템이나 데이터의 일관성이 손상될 위험이 크므로 신중하게 선택해야 합니다.

8. 일치하지 않는 구성 요소 버전 무시 (Ignore Invalid Component Version)

의미: 전송 요청의 소프트웨어 구성 요소 버전(서포트 패키지 레벨 포함)이 대상 시스템과 일치하지 않더라도 임포트를 허용합니다.
용도: 시스템 간 버전 차이로 인해 임포트가 차단되는 상황에서, 특정 요청을 강제로 반영해야 할 때 사용합니다

✔ 주로 운영 배포 시 최종 Import 큐에서 전송요청 중단, Import Transport Request Again, 오리지널 겹쳐쓰기, 미확정된 수리에서 오브젝트 겹쳐쓰기 위 4가지 옵션들은 체크해서 진행되는 경우가 많습니다. 하지만 각 옵션들의 용도나 이유를 명확히하여 배포하는 게 도움이 됩니다.

⚠️ 실무에서 가장 많이 터지는 문제

에러 코드(Return Code) 빠르게 읽기

RC 0: 성공 (Perfect!)
RC 4: 경고 (Warning - 무시 가능하나 확인 필요)
RC 8: 에러 (Error - 구문 오류, Dictionary 미반영 등 확인 필수)
RC 12: 치명적 에러 (System Crash 등 심각한 상황)

1. TR 순서 문제

Dictionary → Program → Config 순으로 가야 하는데
뒤죽박죽 import

해결:

항상 선행 TR 먼저

2. Client mismatch

DEV: 310 / QA: 200 / PRD: 300

잘못하면:
“Client does not exist” 오류 발생

3. Async 남용

동시에 여러 TR 실행

결과:

activation 실패
object overwrite

4. Import 후 activation 실패

DDIC / table 구조 변경 시

해결:

SE14 / SPAU / SPDD 확인

SAP CTS 핵심 데이터베이스 테이블 정리

CTS 데이터는 주로 E로 시작하는 테이블에 저장됩니다. 이 테이블들 사이의 관계(Relationship)를 이해하는 것이 포인트입니다.

1. 전송 요청서(TR) 헤더 및 내역

가장 기본이 되는 테이블들입니다. '누가, 언제, 무엇을'에 대한 답을 줍니다.

테이블명	기능 및 설명	핵심 필드 (Key Fields)
E070	TR 헤더 (Change & Transport System: Header)	TRKORR(TR번호), TRFUNCTION(유형), TRSTATUS(상태), AS4USER(생성자)
E07T	TR 설명 (Change & Transport System: Short Texts)	TRKORR, AS4TEXT(설명글)
E070A	TR 속성 (Attributes of a Request)	TRKORR, ATTRIBUTE(속성명), REFERENCE(값)
E070L	TR 번호 범위 (Last Used Numbers)	마지막으로 생성된 TR 번호를 관리 (시스템 내부용)

2. 전송 오브젝트(Object) 상세 내역

TR 안에 어떤 프로그램, 테이블, 클래스가 담겨 있는지 확인하는 테이블입니다.

테이블명	기능 및 설명	핵심 필드 (Key Fields)
E071	오브젝트 리스트 (Object List)	TRKORR, OBJECT(R3TR, LIMU 등), OBJ_NAME(프로그램명 등)
E071K	테이블 키 내역 (Object List: Table Keys)	TRKORR, TABKEY(테이블의 특정 Data Key 값)

참조 사이트

https://userapps.support.sap.com/sap/support/knowledge/en/3088775

https://community.sap.com/t5/technology-q-a/import-option-in-stms-import/qaq-p/11533820

https://velog.io/@yhjseed/SAP-%EC%9E%84%ED%8F%AC%ED%8A%B8-%ED%81%90-%EC%A0%95%EB%A6%AC-%EB%B0%A9%EB%B2%95How-to-clean-up-the-SAP-Import-Queue

https://potato98.tistory.com/204

[2026 KBO] SSG 랜더스 개막전 티켓팅 에러, 멤버쉽 환불

가시가되어 — Mon, 23 Mar 2026 11:01:26 +0900

[2026 KBO] SSG 랜더스 개막전 티켓팅 '502/504 에러' 대란... 멤버십 혜택 및 환불 총정리

드디어 기다리고 기다리던 2026 프로야구 시즌이 돌아왔습니다!

문학 경기장(인천 SSG 랜더스필드)의 뜨거운 열기를 느끼기 위해 개막전 티켓팅에 참전하신 분들이 많으실 텐데요.

티켓링크가 아닌 자체 앱을 통한 예매 방식으로 변하게 되면서 개막전 티켓팅(선예매) 당시 많은 문제가 발생되었습니다.

오늘은 2026년 SSG 랜더스 멤버십 등급과 이번 티켓팅 오류 상황 및 대응 방법에 대해 자세히 알아보겠습니다.

개막전 티켓팅 후기

저 또한 개막전 티켓팅을 위해 진행했고 위와 같은 많은 문제들을 경험했습니다.

가까스로 1시간 동안 무한 새로고침, 앱 삭제 후 재설치 등 별의 별 방법을 하며 스트레스 받는 상황이였습니다.

99,000원이라는 돈을 지불하고 이러한 상황에 많은 분노를 느꼈습니다.

더더욱 예매를 하지 못하였거나, 취소 되신 분들은 더 큰 분노를 느끼셨을 거라 생각합니다.

하지만 아직 SSG 랜더스 측의 공식입장 혹은 사과, 환불에 대한 내용이 없는 점은 실망스럽습니다.

야구, KBO의 인기가 올라가는 만큼 팬들을 돈으로 보는 행태를 최대한 줄이고, 편의성 개선에 힘을 쓰면 좋겠습니다.

마지막으로 제발 암표 좀 어떻게 해주세요... 너무 많습니다.

1. 2026 SSG 랜더스 멤버십: 푸리, 배티, 랜디

올해 랜더스 멤버십은 귀여운 구단 캐릭터들의 이름을 딴 3개 등급으로 운영됩니다.

가장 큰 특징은 SSG.com 아이디 하나(통합회원)로 예매부터 혜택까지 통합되었다는 점입니다.

등급	가입비	핵심 혜택
푸리 (Puri)	50,000원	경기 6일 전 선예매, 라이트 스틱 응원봉
배티 (Batti)	99,000원	경기 7일 전 11시 선예매, 전용 짐색 증정
랜디 (Randy)	199,000원	경기 7일 전 11시 선예매, 전용 유니폼 및 전용 게이트 이용

공통 사항: 일반 예매보다 1시간 빠른 선입장, 티켓 예매 수수료 면제, 스타벅스 게이트 이용 등 실용적인 혜택이 강화되었습니다.
랜디와 배티의 경우, 동일 시간에 열리므로 별도로 유니폼 등 굿즈가 필요하지 않다면 배티 등급을 추천

2. 개막전 티켓팅의 비극: 502 Bad Gateway & 504 Timeout

이번 개막전 예매 당시, 많은 팬이 "좌석 선택도 못 해보고 튕겼다"며 분통을 터뜨렸습니다.

3월 22일 전후로 진행된 개막 시리즈 예매 당시, 많은 팬이 접속했으나 서버가 이를 감당하지 못해 게이트웨이 오류(502 Bad Gateway, 504 Gateway Timeout)가 빈번하게 발생되었습니다.

주요 증상은 다음과 같았습니다.

502 Bad Gateway / 504 Gateway Timeout: 서버가 감당할 수 없는 수준의 트래픽이 몰리면서 게이트웨이가 응답하지 않는 현상입니다.
무한 로딩: 예매 창이 뜨지 않거나, 결제에서 넘어가지 않는 등 다양한 무한로딩 현상
좌석 취소: 예매 데이터가 정상적으로 생기지 않아 취소되거나, 시즌권 좌석이 풀려 취소되는 등 결제까지 했지만 취소가 되는 황당한 일까지 발생됨.

많은 유료 멤버십 가입자들이 "선예매 권한을 위해 비용을 지불했는데, 정작 서버가 터져서 권리를 행사하지 못했다"는 점에 대해 강하게 항의하고 있는 상황입니다.

3. 결제 오류 및 환불 정보 (수수료 포함)

시스템 오류로 인해 피해를 보신 분들은 다음 내용을 꼭 확인하시기 바랍니다.

자동 환불: 결제는 승인되었으나 좌석 확정이 되지 않은(예매 내역에 없는) 경우, 시스템에서 순차적으로 자동 취소를 진행합니다.
멤버쉽 환불 : 구매 후 14일이내 별다른 티켓 구매, 사용 이력이 없다면 환불이 가능합니다. 현재 1:1 문의나 내용 보면 미 사용인 경우 환불을 해주겠다는 정보도 있습니다.

M365 구독 라이선스 등급 정리 및 가격 - E3,E5,F1

가시가되어 — Thu, 19 Mar 2026 17:10:09 +0900

[M365 총정리] E3, E5부터 F1까지: 우리 회사에 딱 맞는 라이선스는?

기업용 라이선스는 크게 E, Enterprise(대기업용/제한 없음)와 F, Frontline(현장직용)으로 나뉩니다.

각 라이선스의 기능과 비용을 단계별로 분석해 보겠습니다.

S1. 대기업 및 중견기업의 표준: Enterprise (E3 vs E5)

가장 많이 선택되는 플랜으로, PC에 설치하는 데스크톱 앱과 강력한 보안 기능을 포함합니다.

구분	Microsoft 365 E3	Microsoft 365 E5
핵심 가치	표준적인 협업 및 보안 환경 구축	강력한 보안 자동화 및 데이터 분석
보안(Security)	Defender P1 (표준 보안)	Defender P2, XDR, 내부자 위험 관리
분석(Analytics)	미포함	Power BI Pro 포함
통신(Voice)	Teams 채팅/미팅	Teams Phone(클라우드 전화) 포함
비용 (2026 기준)	$36 / $39(인상 예정)	$57 / $60(인상 예정)

E3 추천: 안정적인 오피스 환경과 표준 보안이 필요한 경우.
E5 추천: 금융/개인정보 취급 등 규정 준수가 엄격하거나, Power BI를 통한 데이터 시각화가 전사적으로 필요한 경우.

2. 현장 근무자를 위한 실속형: Frontline (F1 vs F3)

현장 생산직이나 외근직 등 PC 사용 비중이 낮은 직군을 위한 라이선스입니다.

M365 F1 ($2.25): 가장 경제적인 플랜입니다. 주로 이메일 수신, 팀즈 채팅 참여 위주입니다. 문서 동시 편집은 가능하지만 '읽기 전용'에 가깝게 운영되며, 저장 공간이 2GB로 제한적입니다.
M365 F3 ($8.00): 웹과 모바일에서 문서 생성 및 편집이 가능합니다. 현장에서 보고서를 직접 수정하거나 Power Apps를 통해 업무 프로세스를 자동화해야 한다면 F3가 필수적입니다.

Step 3. 가장 궁금해하는 포인트: "동시 편집(Co-authoring)"

많은 분이 오해하시는 부분 중 하나가 "동시 편집은 높은 단계 라이선스만 가능하다"는 점입니다.

E3 이상: 설치형 앱(데스크톱)과 웹 모두에서 완벽한 실시간 동시 편집을 지원합니다.
F3: 웹 브라우저와 모바일 앱에서 동시 편집이 가능합니다.
F1: 웹에서 문서를 열어 함께 볼 수는 있으나, 편집 권한에 제약이 있을 수 있어 주로 뷰어 용도로 권장됩니다.

Step 4. 2026년 공식 가격 및 라이선스 선택 가이드

2026년 7월부터 일부 엔터프라이즈 플랜의 가격 조정이 예정되어 있습니다.

따라서 현재 시점에서 가장 효율적인 선택은 다음과 같습니다.

300인 미만 기업: Business Premium($22)을 검토하세요. Enterprise E3급 보안(Intune 등)을 갖추면서도 가격은 훨씬 경제적이며, 2026년 가격 인상 대상에서도 제외되었습니다.
보안 및 분석 중심: 별도의 분석 툴(Tableau 등)이나 보안 솔루션을 중복 결제하고 있다면, 이를 모두 통합한 M365 E5로 전환하는 것이 총 소유 비용(TCO) 관점에서 유리합니다.
IT 인프라 관리: SSL 인증서 관리, 서버 운영, 데이터 인벤토리 관리 등이 잦은 환경이라면 E5의 고급 규정 준수(Compliance) 기능이 관리 리소스를 획기적으로 줄여줄 수 있습니다.

결론: 어떻게 선택해야 할까?

"설치형 엑셀/워드가 꼭 필요하다" → Business Standard 또는 E3
"보안 자동화와 데이터 분석이 중요하다" → E5
"웹에서 메일과 일정만 확인하면 된다" → F1/F3

마이크로소프트 공식 페이지의 세부 사양은 수시로 업데이트되므로, 도입 전 전문가를 통해 조직의 테넌트 환경과 보안 가이드라인을 먼저 점검해보시길 권장합니다.

자세한 건 공식 문서 참조 - M365 엔터프라이즈 가격비교

[SAP] ABAP 많이 쓰이는 필수 SY 코드 및 공통 펑션 정리

가시가되어 — Wed, 18 Mar 2026 11:51:25 +0900

[SAP ABAP] 필수 암기! 개발 시간을 단축하는 핵심 SY 시스템 변수와 공통 펑션(Function) 총정리

프로그램을 개발하다 보면 현재 날짜를 가져오거나, 로그인한 사용자의 아이디를 확인하고, 데이터가 정상적으로 조회되었는지 체크해야 하는 순간이 매번 찾아옵니다.

이럴 때마다 로직을 새로 짤 필요 없이, SAP가 미리 만들어둔 시스템 변수(SY Variables)와 표준 펑션(Function Modules)을 활용하면 개발 시간을 획기적으로 단축할 수 있습니다.

오늘은 ABAP 개발자라면 반드시 즐겨찾기 해두고 외워야 할 핵심 요소인 시스템 변수와 펑션들을 단계별로 정리해 보겠습니다.

1. 시스템 변수(System Variables)란?

ABAP 프로그램이 실행되는 동안 SAP 시스템은 현재 상태나 환경에 대한 다양한 정보를 SYST라는 구조체(Structure)에 지속적으로 업데이트합니다. 우리는 코드 내에서 SY-변수명 형태로 이 값들을 손쉽게 불러와 사용할 수 있습니다.

테이블 : SYST 를 조회하여 다양한 시스템 코드들을 볼 수 있습니다.

핵심 팁: 시스템 변수는 시스템이 자동으로 값을 채워주므로, 개발자가 임의로 값을 변경(Assign)하는 것은 권장하지 않습니다. (예외적인 상황 제외)

가장 많이 쓰이는 필수 SY 코드

SY-SUBRC (Return Code): 가장 중요합니다! 직전에 실행된 ABAP 구문(SELECT, READ TABLE 등)의 성공 여부를 반환합니다.
- 0: 성공
- 4,8,1001 등 (0 이외의 값): 실패 또는 데이터 없음
SY-TABIX (Table Index): 현재 인터널 테이블(Internal Table)에서 루프(LOOP)가 돌고 있는 행(Row)의 인덱스 번호를 나타냅니다.
SY-INDEX (Loop Index): DO ... ENDDO 또는 WHILE 구문 등에서 현재 몇 번째 반복 횟수인지를 나타냅니다. (SY-TABIX와 혼동 주의!)
SY-DATUM (Current Date): 시스템의 현재 날짜를 반환합니다. (YYYYMMDD 형식)
SY-UZEIT (Current Time): 시스템의 현재 시간을 반환합니다. (HHMMSS 형식)
SY-DATLO (Current Date) : 사용자(User Time zone)의 현재 날짜를 변환합니다.
SY-UNAME (User Name): 현재 시스템에 로그인하여 프로그램을 실행 중인 사용자의 ID입니다.
SY-DBCNT : 쿼리 결과 성공한 Row의 수를 반환합니다.
SY-LANGU : 현재 로그인한 언어 키를 반환합니다.
SY-SYSID : 현재 접속한 시스템 변수를 반환합니다.
SY-MANDT (Client): 현재 로그인된 클라이언트 번호(예: 100, 400 등)입니다.
SY-TCODE (Transaction Code): 현재 실행 중인 트랜잭션 코드를 나타냅니다.
SY-UNAME : 현재 로그인한 사용자의 ID를 반환합니다.
SY-UCOMM (User Command): 화면(Screen)에서 사용자가 버튼을 클릭하거나 엔터를 쳤을 때 발생하는 액션 코드(Function Code)를 담습니다.

참고) SAP 공식 문서 - ABAP System Fields

2. 공통 Function Module (자주 쓰는 표준 펑션)

SAP는 전 세계 기업들의 비즈니스 프로세스를 지원하며 방대한 양의 표준 펑션들을 만들어 두었습니다. 바퀴를 다시 발명하지 마세요! 아래의 공통 펑션들은 실무에서 무조건 한 번 이상 쓰게 됩니다. (SE37 트랜잭션에서 테스트해 볼 수 있습니다.)

날짜 계산 및 제어

RP_CALC_DATE_IN_INTERVAL: 특정 날짜를 기준으로 N일 전/후, N달 전/후, N년 전/후의 날짜를 계산해 줍니다. 윤년 등 복잡한 날짜 계산을 한 번에 해결합니다.
BKK_GET_MONTH_LASTDAY: 특정 날짜가 속한 달의 마지막 날짜(28일, 30일, 31일)를 구해줍니다. 월말 마감 로직에 필수적입니다.
FIMA_DAYS_AND_MONTHS_AND_YEARS: 두 날짜 사이의 일수, 월수, 년수 차이를 정확히 계산합니다.

데이터 변환 및 포맷팅 (Conversion Exit)

CONVERSION_EXIT_ALPHA_INPUT: 숫자 앞에 0을 채워줍니다. (예: 123 ➡️ 0000000123). SAP DB에 값을 넣기 전 필수입니다.
CONVERSION_EXIT_ALPHA_OUTPUT: 반대로 숫자 앞의 의미 없는 0을 제거해 줍니다. (예: 0000000123 ➡️ 123). 화면에 출력할 때 사용하거나, 타 시스템으로 Interface 할 경우 불필요한 0을 제거할 때 사용합니다.

팝업 및 UI 제어

POPUP_TO_CONFIRM: 사용자에게 "저장하시겠습니까?" 와 같은 Yes/No/Cancel 확인 팝업을 띄울 때 가장 많이 사용하는 표준 펑션입니다.

파일 업로드/다운로드

(과거에는 GUI_UPLOAD / GUI_DOWNLOAD 펑션을 썼지만, 최근 객체지향 트렌드에 따라 아래 클래스 메소드 사용을 권장합니다.)

CL_GUI_FRONTEND_SERVICES=>GUI_UPLOAD: PC의 엑셀이나 텍스트 파일을 SAP 인터널 테이블로 읽어 들일 때 사용합니다.
CL_GUI_FRONTEND_SERVICES=>GUI_DOWNLOAD: SAP의 데이터를 PC에 파일로 다운로드할 때 사용합니다.

[DB] 데이터브릭스 CT 기반 데이터 적재(SQL Sever)

가시가되어 — Tue, 17 Mar 2026 11:42:16 +0900

데이터브릭스 CT 기반 실시간 데이터 적재 및 최적화 전략

1. 현대적 데이터 파이프라인의 핵심: 메달리온 아키텍처

데이터브릭스에서 추천하는 메달리온 아키텍처(Medallion Architecture)는 데이터를 단계적으로 정제하여 신뢰할 수 있는 데이터셋을 구축하는 구조입니다. CT 스트리밍은 이 구조의 입구(Ingestion) 역할을 수행합니다.

* 메달리온 아키텍처란? 데이터 레이크하우스(Data Lakehouse) 환경에서 데이터를 체계적으로 조직하고, 품질을 점진적으로 향상시키기 위해 사용되는 3단계 데이터 디자인 패턴으로 데이터를 품질에 따라서, 올림픽 메달처럼 금은동으로 나눠서 저장

① Bronze (Raw Layer): 원천의 복제본

역할: 소스 DB에서 넘어온 변경 이력을 가공 없이 그대로 적재합니다.
특징: SYS_CHANGE_OPERATION(I, U, D)과 SYS_CHANGE_VERSION 정보를 포함하여, 데이터가 "어떻게 변했는지"에 대한 모든 기록을 보유합니다.
저장 방식: 주로 Append-only 방식으로 적재하여, 추후 데이터 유실이나 재처리가 필요할 때 '진실의 원천' 역할을 합니다.

② Silver (Cleansed/Enriched Layer): 현재 상태의 유지

역할: Bronze의 변경 이력을 분석하여, 비즈니스 엔티티(예: 고객, 주문)의 최종 상태를 테이블 형태로 유지합니다.
핵심 기술: Delta Lake의 MERGE INTO 명령어를 사용합니다.
로직: 같은 PK를 가진 데이터가 들어오면 기존 데이터를 업데이트(Update)하고, 없으면 삽입(Insert)하며, 삭제 표식이 있으면 삭제(Delete)합니다.

③ Gold (Curated Layer): 비즈니스 분석용

역할: Silver 테이블들을 조인하거나 집계하여 보고서, AI 모델 학습, BI 대시보드에 최적화된 데이터를 생성합니다.

2. 소스 DB(SQL Server)의 Change Tracking 메커니즘

CT는 데이터베이스 엔진 내부에서 동작하는 경량화된 추적 기능입니다.

내부 동작 원리

동기적 추적: 트랜잭션이 커밋될 때, SQL Server는 내부 시스템 테이블에 "이 테이블의 이 PK를 가진 행이 변경되었다"는 사실과 함께 버전 번호를 기록합니다.
버전 관리: DB 전체에 대해 글로벌한 버전 번호(CHANGE_TRACKING_CURRENT_VERSION)가 증가하며, 각 테이블은 자신의 마지막 변경 지점을 알고 있습니다.
데이터 보관: Retention Period 설정을 통해 오래된 변경 기록은 자동으로 삭제(Auto Cleanup)됩니다.

CT vs CDC (Change Data Capture) 선택 기준

CT: 변경된 PK만 기록합니다. "무엇이 변했나"만 알 수 있고 "어떤 값으로 변했나"는 원본 테이블을 다시 조회해서 가져와야 합니다. 부하가 매우 적습니다.
CDC: 변경된 데이터 값 전체를 로그에서 읽어 별도의 이력 테이블에 저장합니다. 부하가 CT보다 크지만, 과거 모든 상태의 변화를 추적할 수 있습니다.
결론: 단순 실시간 동기화가 목적이라면 CT가 성능 면에서 압도적으로 유리합니다. CDC의 경우, PK가 없는 테이블에 적용합니다.

3. 데이터브릭스 스트리밍 구현 상세 (PySpark)

데이터브릭스에서 CT 데이터를 스트리밍으로 읽어올 때는 Spark Structured Streaming과 전용 커넥터를 사용합니다.

핵심 코드 구조 및 파라미터 설명

# 1. 소스 DB 연결 설정
source_options = {
    "host": "your-db-server.database.windows.net",
    "database": "TargetDB",
    "user": "databricks_sync_user",
    "password": dbutils.secrets.get(scope="sql", key="db_password"),
    "dbtable": "Sales.Orders", # 혹은 서브쿼리 사용
    "changeTracking": "true", # CT 모드 활성화
    "incremental": "true",    # 증분 적재 모드
    "isolationLevel": "READ_UNCOMMITTED" # 락 방지
}

# 2. 스트리밍 데이터프레임 생성
# readStream을 사용하면 Spark는 체크포인트를 확인하여 마지막 읽은 버전 이후부터 읽기 시작함
raw_stream_df = spark.readStream \
    .format("sqlserver") \
    .options(**source_options) \
    .load()

# 3. Micro-batch 처리 (Silver 레이어 Upsert)
def upsert_to_delta(batch_df, batch_id):
    # 동일 배치 내 중복 데이터 제거 (가장 최신 버전만 선택)
    window_spec = Window.partitionBy("OrderID").orderBy(col("SYS_CHANGE_VERSION").desc())
    latest_batch_df = batch_df.withColumn("rank", row_number().over(window_spec)) \
                              .filter("rank = 1").drop("rank")
    
    # Delta Table 객체 생성
    target_table = DeltaTable.forName(spark, "silver_db.orders")
    
    # MERGE 실행
    target_table.alias("t").merge(
        latest_batch_df.alias("s"),
        "t.OrderID = s.OrderID"
    ).whenMatchedUpdateAll(
        condition = "s.SYS_CHANGE_OPERATION IN ('U', 'I')"
    ).whenMatchedDelete(
        condition = "s.SYS_CHANGE_OPERATION = 'D'"
    ).whenNotMatchedInsertAll(
        condition = "s.SYS_CHANGE_OPERATION = 'I'"
    ).execute()

# 4. 스트리밍 시작 및 체크포인트 설정
query = raw_stream_df.writeStream \
    .foreachBatch(upsert_to_delta) \
    .outputMode("update") \
    .option("checkpointLocation", "/mnt/datalake/checkpoints/orders_sync") \
    .trigger(processingTime='1 minute') \
    .start()

4. 소스 DB 부하 최소화 및 성능 튜닝

운영 DB(OLTP)의 성능을 보호하는 것은 데이터 엔지니어링의 최우선 과제입니다.

① 락(Lock) 경합 해소: Snapshot Isolation

데이터브릭스가 대량의 데이터를 읽어갈 때 Shared Lock을 걸면 운영 앱의 Update가 차단됩니다.

이를 방지하기 위해 SQL Server에서 READ_COMMITTED_SNAPSHOT을 활성화해야 합니다.

원리: 변경 전 데이터를 TempDB의 버전 스토어에 보관하여, 읽기 작업이 락 없이도 일관된 데이터를 읽게 합니다.
주의: TempDB의 사용량이 증가하므로 TempDB 공간 모니터링이 필요합니다.

② 네트워크 부하 감소: Pushdown 필터링

dbtable 옵션에 테이블 이름 대신 WHERE 절이 포함된 서브쿼리를 사용하세요.

예시: (SELECT * FROM Orders WHERE Region = 'Asia' AND OrderDate > '2024-01-01') AS filtered_table
이렇게 하면 소스 DB 엔진이 먼저 필터링을 수행하여 꼭 필요한 데이터만 네트워크로 전송합니다.

③ 적절한 Trigger 설정

스트리밍이라고 해서 ProcessingTime='0 seconds'(가장 빠르게)로 설정하면 소스 DB에 쿼리가 너무 빈번하게 발생합니다.

데이터의 시급성에 따라 1분~10분 단위로 조절하는 것이 소스 DB 부하 조절에 효과적입니다.

5. 모니터링 및 장애 대응 (Troubleshooting)

① SQL Server Profiler & Extended Events

DB 부하가 의심될 때 Profiler를 통해 다음을 체크합니다.

Duration: 데이터브릭스가 던지는 CHANGETABLE 쿼리의 수행 시간.
Reads/Writes: 쿼리당 발생하는 논리적 읽기 수.
Wait Type: LCK_M_... 대기가 발생하는지 확인. (발생 시 Snapshot Isolation 설정 재점검)

② CT Retention Gap 문제

소스 DB의 CT 보관 주기가 2일인데, 데이터브릭스 스트리밍이 장애로 3일간 중단되었다면?

현상: CHANGE_TRACKING_MIN_VALID_VERSION보다 체크포인트의 버전이 낮아져 에러 발생.
해결: 이 경우 증분 적재가 불가능하므로, 체크포인트를 초기화하고 Full Re-sync를 수행해야 합니다. 이를 방지하기 위해 보관 주기를 충분히(예: 7일) 잡는 것이 실무적인 팁입니다.

③ Spark UI 모니터링

데이터브릭스의 Streaming Tab에서 다음 지표를 주시하세요.

Input Rate vs Process Rate: 데이터가 쌓이는 속도보다 처리 속도가 느리면 지연(Backlog)이 발생합니다.
Batch Duration: 배치 처리 시간이 Trigger 주기보다 길어지면 클러스터 사양을 높이거나 병렬 처리를 늘려야 합니다.

6. 데이터 정합성 보장 전략

① 멱등성(Idempotency) 확보

스트리밍은 네트워크 장애 등으로 인해 동일한 배치가 재실행될 수 있습니다. Delta Lake의 MERGE INTO는 그 자체로 멱등성을 보장하므로, 중복 데이터가 들어와도 결과값은 항상 동일하게 유지됩니다.

② 스키마 진화(Schema Evolution)

소스 DB에 컬럼이 추가되면 스트리밍이 깨질 수 있습니다.

Delta Lake의 mergeSchema 옵션을 활용하거나, Bronze 레이어에서 cloudFiles.schemaEvolutionMode를 사용하여 유연하게 대응할 수 있습니다.

7. 결론 및 향후 과제

데이터브릭스와 SQL Server CT를 결합한 구조는 저부하, 고성능, 고가용성을 모두 만족하는 설계입니다.

특히 IT 운영 환경(SAP, SCM 등)에서 발생하는 대량의 트랜잭션 데이터를 실시간으로 분석 환경으로 가져올 때 가장 권장되는 패턴입니다.

[SAP] 특별재고 유형 'E' 판매오더 재고에 대한 개념 정리

가시가되어 — Mon, 16 Mar 2026 14:34:22 +0900

SAP 특별재고 유형 정의와 목적

SAP에서 특별재고(Special Stock)는 '이 재고가 물리적으로는 창고에 있지만, 법적인 소유권이 누구에게 있는지' 또는 '특정한 목적(프로젝트, 오더 등)이 있는지'를 구분하기 위해 사용합니다.

특히, SAP에서 특별재고 유형 'E'는 판매 오더 재고(Sales Order Stock)를 의미합니다.

일반적인 가용 재고와 달리, 특정 영업 오더(Sales Order)를 위해 예약되어 다른 용도로 마음대로 쓸 수 없는 상태를 말하죠.

주로 주문 생산(Make-to-Order, MTO) 환경에서 핵심적인 역할을 합니다.

1. E Stock의 정의와 목적

정의: 특정 고객의 주문(Sales Order)에 직접 할당된 재고입니다.
재고 예약: 해당 주문 이외의 다른 주문에 재고가 소진되는 것을 방지합니다.
비용 추적: 재고의 가치와 비용을 특정 영업 오더나 프로젝트에 귀속시켜 수익성을 정밀하게 분석할 수 있습니다.

2. 이외에 다른 특별재고유형들

외주 가공(Subcontracting) 특화 유형

리스트에 있는 C, F, I, J, R 등은 모두 외주 공정 중에 발생하는 변수들을 관리하기 위한 것입니다.

일반 재고보다 훨씬 복잡한 관리가 필요할 때 사용됩니다.

코드	명칭	상세 설명
C	SC Customer Stock	고객이 무상으로 제공한 자재를 우리가 외주 업체에 다시 보내 가공할 때 사용합니다.
F	SC Customer Order Stock	특정 판매 오더(E)용 재고를 외주 업체에 보내 가공 중인 상태입니다.
I	SC RTP	외주 업체에 가공을 맡길 때 함께 보낸 회수 가능 포장재(팔레트 등)입니다.
J	SC Vendor Consignment	업체 위탁 재고(K) 상태인 자재를 그대로 외주 업체로 보내 가공할 때 사용합니다.
R	SC Project Stock	프로젝트 재고(Q)를 외주 업체에 보내 가공 중인 상태입니다.

고객 및 공급업체 관련 유형

알려주신 리스트 중 B, T, Y 등은 물류의 흐름과 소유권을 명확히 하는 역할을 합니다.

B (Customer Stock): 고객 소유의 자재를 우리 창고에서 수리나 보관 목적으로 관리할 때 사용합니다. (소유권: 고객)
T (Stock in Transit): 플랜트 간 재고 이전(STO) 시, 보낸 쪽에서는 나갔지만 받는 쪽에는 아직 입고되지 않은 '길 위에 있는' 재고입니다.
Y (Shipping Unit): 창고 관리(WM/EWM)에서 포장 단위(Handling Unit)와 연동되어 관리되는 재고 유형입니다.

2. 주요 특징 (Key Facts)

A. 소유권과 가용성

재고의 논리적 주인이 '회사'가 아닌 '특정 영업 오더'입니다.
MMBE(재고 개요) 조회 시, 일반 저장위치 아래에 Sales Order 번호와 Item 번호가 별도로 표시됩니다.

B. 평가(Valuation)

평가 대상(Valuated): 재고의 가치가 재무회계(FI)에 반영됩니다. 보통 Sales Order 자산으로 잡힙니다.
비평가 대상(Non-Valuated): 수량만 관리하고 가치는 별도의 비용 계정으로 즉시 처리되는 경우도 있습니다.

C. 관련 테이블

MSKA: Sales Order별 특별 재고 데이터가 저장되는 핵심 테이블입니다. (MARD가 일반 재고라면, MSKA는 E Stock 전용입니다.)

3. 주요 프로세스 및 이동 유형 (Movement Types)

주로 이동유형 뒤에 'E' 와 같이 특별재고유형을 붙여둡니다.

MIGO에서 ‘E’ 재고를 처리할 땐 판매 오더 번호를 입력해야 합니다.

구분	이동 유형(Mvt)	설명
재고 입고	501 E / 561 E	참조 없이 또는 초기 잔액으로 E Stock 입고
재고 전용	412 E	일반 가용 재고(Unrestricted)를 특정 영업 오더 재고(E)로 전환
전용 해제	411 E	E Stock을 다시 일반 가용 재고로 전환 (주문 취소 시 사용)
출고	601 E	판매 오더를 참조하여 고객에게 납품(Delivery) 출고

4. 실무에서의 활용 (MTO 흐름)

Sales Order 생성: MTO 전략(예: Strategy 20)을 가진 자재로 주문을 넣습니다.
MRP 실행: 시스템이 해당 주문을 채우기 위해 'Sales Order용 구매요청(PR)'이나 '생산오더'를 생성합니다.
입고: 구매/생산이 완료되어 입고되면 재고 유형이 자동으로 **'E'**로 잡힙니다.
납품: 오직 해당 Sales Order를 통해서만 출고가 가능합니다.

짧은 팁: "재고가 있는데 왜 출고가 안 되죠?"

현업에서 자주 들어오는 질문입니다.

MMBE에서 수량은 보이지만 출고가 안 된다면, Sales Order 번호가 일치하는지 확인해 보세요.

A 주문용으로 들어온 E Stock은 B 주문에서 절대 나갈 수 없습니다. 이럴 땐 411 E로 일반 재고 전환 후 다시 처리하거나, 413 E로 주문 간 재고 이전을 해야 합니다.

마찬가지로 SCM에서 가용재고 기준으로도 해당 재고에 대해선 오더가 미리 예약한 것으로 가용한 재고로 바라보지 않아야 합니다.

로드 밸런서(Load Balancer)란? L4 와 L7 차이

가시가되어 — Fri, 13 Mar 2026 12:21:02 +0900

로드 밸런서(Load Balancer, LB)란?

로드 밸런서의 정의와 기본 원리

로드 밸런서는 클라이언트와 서버 풀(Server Pool) 사이에 위치하여,

한 곳으로 집중되는 트래픽을 여러 대의 서버로 균등하게 분산해 주는 역할을 합니다.

기본 흐름: 클라이언트가 서비스 IP(VIP, Virtual IP)로 요청을 보냄 → 로드 밸런서가 요청 수신 → 설정된 알고리즘에 따라 최적의 서버 선택 → 서버로 요청 전달 → 서버의 응답을 다시 클라이언트에게 전달.
핵심 목적: 서비스의 가용성(Availability) 확보, 응답 속도 최적화, 서버 부하 방지.

L4 와 L7의 차이

로드밸런싱을 이해할 때 가장 먼저 마주하는 분기점은 전송 계층(L4)과 애플리케이션 계층(L7)의 선택입니다.

L4 로드밸런서는 IP 주소와 포트 번호만을 확인하여 패킷을 단순 전달(Packet Forwarding/NAT)합니다.

반면, L7 로드밸런서는 '풀 리버스 프록시(Full Reverse Proxy)' 방식으로 동작합니다. 이는 클라이언트와의 TCP 핸드셰이크를 종료(Connection Termination)하고, 패킷을 재조립하여 HTTP 헤더, URL 경로, 쿠키 등 전체 페이로드를 분석한 뒤 백엔드와 새로운 연결을 생성(Connection Re-establishment)하는 과정을 포함합니다

가장 중요한 기술적 구분은 어느 계층의 정보를 활용하여 분산하느냐에 있습니다.

구분	L4 (Transport Layer)	L7 (Application Layer)
참조 데이터	IP 주소, 포트 번호, TCP/UDP 프로토콜	URL, 쿠키(Cookie), HTTP 헤더, 페이로드
특징	패킷 레벨에서 속도가 매우 빠르고 효율적임	패킷 내부를 분석하여 정교한 라우팅 가능
장점	데이터 복호화가 필요 없어 부하가 적음	특정 사용자나 요청 내용에 따른 섬세한 제어
단점	섬세한 스위칭(콘텐츠별 분산) 불가능	패킷 분석을 위한 리소스 소모(비용 발생)

로드밸런서 구축 방식의 선택

H/W 로드 밸런서: 전용 장비(F5, Citrix 등). 강력한 성능과 안정성을 제공하지만 고가입니다.
S/W 로드 밸런서: 일반 서버에 설치(Nginx, HAProxy 등). 비용이 저렴하고 설정이 유연합니다.
Cloud 로드 밸런서: AWS(ALB/NLB), Azure 등 클라우드사 제공. 자동 확장(Auto Scaling)과 연동이 쉽고 관리가 간편합니다.

AWS vs GCP: 로드밸런싱 (클라우드)

비교 항목	AWS (ELB/ALB)	GCP (Cloud Load Balancing)
설계 철학	모듈형 (Composable)	통합형 (Converged)
가용 범위	지역적 (Regional)	글로벌 (Global)
글로벌 확장	Route 53 등 추가 서비스 조합 필요	단일 Anycast IP 자체 지원
운영 복잡성	세밀한 제어 가능하나 설정 복잡함	단순화된 구성 및 즉각적 failover

주요 로드 밸런싱 알고리즘

서버를 선택하는 '논리'입니다. 서비스의 성격에 따라 적절한 알고리즘을 선택해야 합니다.

적절한 알고리즘의 선택은 애플리케이션의 특성(상태 유지 필요 여부 등), 워크로드의 형태, 인프라의 제약 조건에 따라 달라집니다

라운드 로빈 (Round Robin): 서버 순서대로 요청을 배분합니다. 서버 사양이 동일할 때 가장 단순하고 공정합니다.
가중 라운드 로빈 (Weighted Round Robin): 성능이 더 좋은 서버에 높은 가중치를 부여하여 더 많은 요청을 처리하게 합니다.
최소 연결 (Least Connection): 현재 활성화된 연결(Session) 수가 가장 적은 서버로 우선 배분합니다. 트래픽 체류 시간이 일정하지 않을 때 유리합니다.
IP 해시 (IP Hash): 클라이언트의 IP를 특정 서버에 매핑하여 고정합니다. 사용자가 항상 같은 서버로 접속해야 하는 상황에 사용됩니다.

운영의 완성도를 높이는 핵심 기능들

실제 운영 환경에서 로드 밸런서의 성능을 결정짓는 3가지 부가 기능입니다.

1. 헬스 체크 (Health Check)

서버의 생존 여부를 주기적으로 확인합니다.

단순히 서버가 켜져 있는지(Layer 3/4)뿐만 아니라, 특정 애플리케이션 페이지가 정상 응답(Layer 7, HTTP 200 OK)을 주는지도 체크하여 비정상 서버를 자동 제외합니다.

2. 세션 유지 (Sticky Session / Session Persistence)

로그인 정보처럼 클라이언트의 상태 정보가 특정 서버에 저장되어 있을 때, 해당 클라이언트가 다시 접속해도 동일한 서버로 연결되도록 보장합니다. 주로 쿠키나 소스 IP를 기준으로 합니다.

3. SSL 오프로딩 (SSL Offloading)

서버 대신 로드 밸런서가 암호화/복호화(HTTPS) 과정을 전담합니다.

백엔드 서버는 CPU 연산이 많이 필요한 SSL 작업에서 해방되어, 순수 비즈니스 로직(데이터 처리)에만 전념할 수 있게 됩니다.

HTTPS란? 연결이 비공개로 설정되어 있지 않습니다 해결방법

가시가되어 — Thu, 12 Mar 2026 18:58:09 +0900

HTTPS란 무엇일까요?

쉽게 말해 **내 블로그에 채우는 ‘디지털 자물쇠’**라고 생각하면 됩니다.

기존 HTTP 통신에 보안 기술(SSL/TLS)을 더해, 사용자와 내 사이트 사이에서 오가는 데이터를 암호화해 주는 보안 기술입니다.

즉, 로그인 정보나 결제 정보 같은 중요한 데이터가 전송될 때 해커가 중간에서 엿보지 못하도록 보호하는 ‘신분증’ 역할을 합니다.

만약 HTTPS 인증서가 제대로 설정되어 있지 않다면, 크롬 브라우저에서는 다음과 같은 경고가 표시됩니다.

⚠️ “연결이 비공개로 설정되어 있지 않습니다”
⚠️ “주의 요함 (Not Secure)”
⚠️ “ 이 사이트는 보안 연결이 사용 되지 않습니다. 이 사이트에 입력하는 비밀번호나 신용카드 등의 정보가 공격자에 의해 도용될 수 있습니다. “

이 경고가 뜨면 방문자들은 불안감을 느끼고 사이트를 떠날 가능성이 높습니다.
그래서 블로그나 웹사이트 운영자라면 HTTPS 설정은 사실상 필수라고 할 수 있습니다.

️ HTTPS 오류 해결을 위한 4단계 체크 방법

접속 시 “연결이 비공개로 설정되어 있지 않습니다”, " 이 사이트는 보안 연결이 사용 되지 않습니다. 이 사이트에 입력하는 비밀번호나 신용카드 등의 정보가 공격자에 의해 도용될 수 있습니다. "라는 메시지가 뜬다면, 아래 순서대로 확인해 보세요.

1단계: 기기의 날짜와 시간 확인하기 ⏰

SSL 인증서는 유효 기간이 있습니다.

만약 컴퓨터나 스마트폰의 날짜가 실제 시간과 다르다면 브라우저는 인증서를 만료되었거나 가짜 인증서로 오해할 수 있습니다.

✔ 해결 방법

설정 → 날짜 및 시간
자동으로 시간 설정 활성화

이것만으로도 문제가 해결되는 경우가 꽤 많습니다.

2단계: 시크릿 모드로 접속해보기 ️‍♂️

브라우저에 저장된 캐시나 쿠키 때문에 인증서 오류가 발생할 수도 있습니다.

크롬에서 시크릿 모드를 실행해 접속해 보세요.

크롬 시크릿 모드 실행

Ctrl + Shift + N

시크릿 모드에서는 정상 접속된다면, 브라우저 캐시 문제일 가능성이 높습니다.

✔ 해결 방법

설정 → 인터넷 사용 기록 삭제
캐시 및 쿠키 삭제

3단계: SSL 상태 초기화하기 (Windows)

컴퓨터가 예전에 저장된 인증서 정보를 계속 사용하면서 오류가 발생하기도 합니다.

이 경우 SSL 상태를 초기화하면 해결될 수 있습니다.

✔ 방법

제어판 실행
인터넷 옵션 선택
내용(Content) 탭 이동
SSL 상태 지우기 클릭

컴퓨터가 저장하고 있던 오래된 인증서 정보를 정리하는 과정입니다.

4단계: 서버 인증서 점검 (관리자용) ️

우선 블로그나 서버를 직접 운영하는 경우라면 인증서 만료 여부를 확인해야 합니다.

대표적인 무료 인증서 서비스인 Let's Encrypt는 보통 90일마다 갱신해야 합니다.

확인 방법

블로그 관리 페이지
호스팅 관리자 페이지
서버 인증서 설정

만약 인증서가 만료되었다면 갱신(renew)을 진행해야 합니다.

서버 내 Openssl 명령어를 통한 점검

openssl s_client -connect 도메인:443 -servername 도메인 -showcerts

Verify return code가 정상이면 0으로 뜨나 비정상인 경우 21로 return 받습니다.

중간 인증서 (Intermediate cert)에서 문제가 생긴 Case로 Apache 라면 설정내  SSLCertificateChainFile 이 정상인지 점검해야 합니다.

만약 Apache 2.4.8+ 이상 버전인 경우엔 SSLCertificateChainFile 이 무시되므로 cert + chain 합친 통합 형태로 변환해야 합니다.

HTTPS 운영 시 꼭 알아두면 좋은 팁

✅ Mixed Content 문제 주의하기

사이트는 HTTPS인데, 내부에 있는 이미지나 스크립트가 HTTP 주소라면 보안 경고가 발생할 수 있습니다.

예를 들어:

https://mysite.com → 페이지
http://example.com/image.jpg → 이미지

이 경우 브라우저는 보안 경고를 표시할 수 있습니다.

✔ 해결 방법

이미지
JS 파일
CSS 파일

모든 리소스를 https 주소로 변경합니다.

✅ HSTS 설정으로 보안 강화하기

사용자가 실수로 http:// 주소로 접속하더라도 자동으로 https로 리다이렉트하도록 하는 기능입니다.

이를 HSTS (HTTP Strict Transport Security)라고 합니다.

이 설정을 적용하면

✔ 보안 강화
✔ HTTPS 강제 적용
✔ 검색 엔진 신뢰도 상승

등의 효과가 있습니다.

마무리

HTTPS 인증서는 이제 선택이 아닌 필수 요소입니다.

✔ 사용자 데이터 보호
✔ 브라우저 보안 경고 방지
✔ 검색 엔진 SEO 개선

이 세 가지 이유만으로도 반드시 설정해야 합니다.

만약 “연결이 비공개로 설정되어 있지 않습니다” 오류가 발생했다면 오늘 소개한 4단계 체크 방법을 하나씩 확인해 보세요.

대부분의 문제는 이 과정에서 해결됩니다.

[DB] 데이터브릭스 SQL Server(MS-SQL) 연결

가시가되어 — Wed, 11 Mar 2026 16:17:22 +0900

데이터브릭스 Lakeflow Connect를 위한 SQL Server 준비하기 (Utility Objects 설치)

데이터브릭스란? Apache Spark의 개발자들이 만든 플랫폼으로, 다음과 같은 특징을 가집니다.

Lakehouse 아키텍처: 데이터 레이크의 유연함(저렴한 저장 비용, 모든 형태의 데이터 수집)과 데이터 웨어하우스의 신뢰성(ACID 트랜잭션, SQL 성능)을 동시에 제공합니다.
통합 분석 플랫폼: 데이터 엔지니어링, 데이터 과학, 머신러닝, 비즈니스 분석(SQL)을 하나의 협업 공간(Notebook)에서 수행할 수 있습니다.
멀티 클라우드 지원: AWS, Azure, GCP 환경에서 모두 구동되며, 특히 Azure에서는 Azure Databricks라는 이름으로 퍼스트 파티 서비스로 통합되어 있습니다.

데이터브릭스(Databricks)에서 Lakeflow Connect를 사용해 SQL Server 데이터를 수집하려면, 먼저 SQL Server 쪽에 몇 가지 Utility Objects(유틸리티 객체)를 설치해야 합니다.

이 글에서는 공식 문서를 기반으로 Lakeflow Connect 사용을 위한 SQL Server 준비 과정 중 Step 1: Utility Objects 설치 방법을 정리합니다.

이 글은 다음 내용을 다룹니다.

Lakeflow Connect와 SQL Server 연동 개념
Utility Objects가 필요한 이유
설치 전 준비사항
Utility Script 설치 방법
설치 확인 방법

1. Lakeflow Connect란?

데이터브릭스의 Lakeflow Connect는 외부 데이터베이스에서 데이터를 지속적으로 수집하여 Databricks Lakehouse로 적재하는 ingestion 기능입니다.

SQL Server의 데이터를 가져올 때는 다음 두 가지 기술을 활용합니다.

Change Tracking (CT) - 참조
Change Data Capture (CDC) - 참조

일반적으로 다음 방식으로 사용됩니다.

테이블 유형	권장 방식
Primary Key 있음	Change Tracking
Primary Key 없음	CDC

이 기능을 사용하려면 SQL Server 내부에 Lakeflow 전용 stored procedure와 함수들이 필요합니다.

이를 설치하는 과정이 바로 Utility Objects 설치입니다.

2. Utility Objects가 필요한 이유

Lakeflow Connect는 SQL Server에서 다음 작업을 자동으로 수행합니다.

데이터 변경 추적 설정
CDC 설정
권한 관리
플랫폼 감지
스키마 변경 대응

이를 위해 여러 Utility Stored Procedure와 Function이 생성됩니다.

대표적으로 다음 객체들이 생성됩니다.

Functions

lakeflowDetectPlatform()
lakeflowUtilityVersion_1_X()

Stored Procedures

lakeflowSetupChangeTracking
lakeflowSetupChangeDataCapture
lakeflowFixPermissions

이 프로시저들은 이후 Lakeflow Connect 설정 과정에서 사용됩니다.

3. 설치 전 준비사항

Utility Script 실행 전 다음 조건을 충족해야 합니다.

1️⃣ 실행 계정 권한

스크립트를 실행하는 계정은 db_owner 역할이 필요합니다.

USE [your_database];
ALTER ROLE db_owner ADD MEMBER [your_setup_user];
GO

이 권한은 설치할 때만 필요하며 ingestion user에는 필요 없습니다.

2️⃣ 대상 데이터베이스 확인

Utility Objects는 SQL Server Instance가 아니라 특정 Database에 설치됩니다.

따라서 실행 전에 반드시 다음을 확인해야 합니다.

연결된 Database가 맞는지
SSMS에서 target database 선택 여부

4. Utility Script 설치 방법

이제 실제 설치 과정을 진행합니다.

Step 1. Utility Script 다운로드

공식 문서에서 utility_script.sql 파일을 다운로드합니다.

Step 2. SQL Client에서 스크립트 실행

다음 도구 중 하나를 사용합니다.

SQL Server Management Studio (SSMS)
Azure Data Studio
기타 SQL Client

그리고 다음 절차로 진행합니다.

1️⃣ SQL Server 인스턴스 접속
2️⃣ 대상 Database 선택
3️⃣ utility_script.sql 열기
4️⃣ 스크립트 실행

이 스크립트는 Lakeflow Connect 설정에 필요한 Stored Procedure와 Function을 생성합니다.

5. 설치 확인 방법

설치가 정상적으로 완료되었는지 확인하려면 다음 SQL을 실행합니다.

SELECT dbo.lakeflowUtilityVersion_1_1() AS UtilityVersion;
SELECT dbo.lakeflowDetectPlatform() AS Platform;

결과 예시

UtilityVersion
--------------
1.1

Platform
--------------
ON_PREMISES

첫 번째 쿼리는 설치된 Utility Version을 확인합니다.
두 번째 쿼리는 SQL Server 환경을 자동으로 감지합니다.

지원되는 플랫폼은 다음과 같습니다.

On-premises SQL Server
Azure SQL Database
Azure SQL Managed Instance
Amazon RDS for SQL Server

6. 다음 단계

Utility Objects 설치가 끝났다면 다음 단계로 진행합니다.

Step 2 — Change Tracking 설정

EXEC dbo.lakeflowSetupChangeTracking
@Tables = 'ALL',
@User = 'lakeflow_user',
@Retention = '2 DAYS';

Step 3 — CDC 설정

EXEC dbo.lakeflowSetupChangeDataCapture
@Tables = 'ALL',
@User = 'lakeflow_user';

Step 4 — 권한 설정

EXEC dbo.lakeflowFixPermissions
@User = 'lakeflow_user',
@Tables = 'ALL';

이 과정을 통해 SQL Server는 Lakeflow Connect로 데이터 변경을 스트리밍할 준비가 완료됩니다.

마무리

Databricks Lakeflow Connect로 SQL Server 데이터를 수집하려면 먼저 SQL Server에 Utility Objects를 설치하는 과정이 필요합니다.

정리하면 다음 순서로 진행됩니다.

1️⃣ Utility Objects 설치
2️⃣ Change Tracking 설정
3️⃣ CDC 설정
4️⃣ 권한 설정

특히 첫 단계인 Utility Script 설치는 이후 모든 설정의 기반이 되는 작업이므로 반드시 정확히 수행해야 합니다.

[생성형 AI] 챗GPT, 구글, 엔트로픽 프롬프트 작성법

가시가되어 — Tue, 10 Mar 2026 16:06:30 +0900

생성형 AI에 원하는 대답을 끌어내는 ROTC 프레임워크 활용법

생성형 AI를 사용하다 보면 이런 경험을 자주 하게 됩니다.

“원하는 답이 아닌데?”
“너무 두루뭉술하다…”
“왜 이렇게 엉뚱한 답이 나오지?”

사실 대부분의 문제는 AI가 아니라 프롬프트 작성 방식에서 발생합니다.

AI를 개발하는 기업들인 OpenAI, Anthropic, Google이 공통적으로 강조하는 것은 단 하나입니다.

“AI에게 명확한 맥락과 역할을 제공하라.”

이 원칙을 가장 쉽게 사용할 수 있도록 만든 것이 바로 ROTC 프레임워크입니다.

1. AI의 방향타: ROTC 프레임워크

ROTC는 프롬프트의 필수 4요소를 정리한 구조입니다. 이 틀에 맞춰 질문하면 AI가 헛소리를 할 확률이 급격히 줄어듭니다.

요소	내용	설명
Role (역할)	누구인가?	AI에게 구체적인 페르소나를 부여합니다. (예: 10년 차 SCM 전문가, 데이터 사이언티스트)
Objective (목표)	무엇을 원하는가?	최종적으로 얻고자 하는 결과물의 목적을 명확히 합니다.
Task (작업)	어떤 일을 하는가?	수행해야 할 구체적인 행동 단계를 지시합니다.
Constraint (제약)	규칙은 무엇인가?	답변의 길이, 톤앤매너, 금지 사항, 출력 형식을 지정합니다.

실전 적용 예시

"당신은 **SCM 시스템 최적화 전문가(Role)**입니다. 이번 프로젝트의 목적은 **재고 회전율을 20% 높이는 전략을 수립하는 것(Objective)**입니다. **현재 물류 데이터의 병목 구간을 분석하고 개선안 3가지를 도출(Task)**하세요. 단, **전문 용어보다는 실무자가 이해하기 쉬운 언어를 사용하고, 결과는 마크다운 표 형식으로 출력(Constraint)**하세요."

쉽게 정리하면,

“누가, 무엇을, 어떻게, 어떤 조건으로 할 것인지”를 알려주는 구조입니다.

2. 실제 프레임워크 연습 환경 (복사해서 사용하세요)

아래 템플릿의 대괄호[...] 부분만 채워서 AI에게 입력해 보세요. 결과물의 질이 달라지는 것을 즉시 체감할 수 있습니다.

# [프롬프트 제목을 입력하세요]

## 1. 역할 (Role)
- 당신은 [전문 분야/직업]로서, [특정 성향이나 경험]을 가지고 있습니다.

## 2. 목표 (Objective)
- 이 대화의 최종 목적은 [얻고자 하는 최종 결과물]을 만드는 것입니다.

## 3. 작업 단계 (Task)
1. [첫 번째로 수행할 작업]
2. [두 번째로 수행할 작업]
3. [최종 결과물 정리 방식]

## 4. 제약 및 형식 (Constraint)
- 말투: [예: 정중하게 / 유머러스하게 / 간결하게]
- 금지 사항: [예: 전문 용어 제외 / 3문장 이상 금지]
- 출력 형식: [예: JSON / 표 / 불렛포인트 / 코드 블록]

3. AI 성능을 높이는 단 하나의 문장

AI 기업들이 공통적으로 추천하는 문장이 있습니다.

여러 연구와 논문에서 증명된, 프롬프트 끝에 붙이기만 해도 성능(추론 능력)이 비약적으로 상승하는 문장입니다.

Let's think step by step.

이 문장은 AI가 결론을 서둘러 내지 않고, 중간 추론 과정을 스스로 점검하게 만드는 효과가 있습니다.

복잡한 논리 구조나 코딩, 수학적 계산이 필요할 때 특히 강력합니다.

4. Big 3(OpenAI, Anthropic, Google)의 공통 팁

AI 업계의 거인들이 가이드라인에서 공통으로 강조하는 '골든 룰' 3가지입니다.

① 명확한 구분자(Delimiters) 사용

AI는 어디까지가 지시사항이고 어디서부터가 참고 데이터인지 헷갈려 합니다. ###, """, --- 같은 기호를 사용해 영역을 확실히 나누어 주세요.

예: "아래 세 개의 큰따옴표 내에 있는 텍스트를 요약해 줘. """[텍스트 내용]"""

② '적은 양의 학습(Few-shot)' 데이터 제공

"알아서 잘해줘"보다는 "이런 식으로 해줘"라고 예시를 1~2개만 보여줘도 성능이 극대화됩니다.

원하는 출력 스타일이 있다면 샘플을 하나 던져주는 것이 백 마디 설명보다 낫습니다.

③ 긍정문으로 지시하기

"~하지 마"라는 부정문보다는 "~해줘"라는 긍정문이 AI에게 훨씬 명확한 가이드를 제공합니다.

하지 말아야 할 것이 있다면, 차라리 "대신 A 형식을 유지해 줘"라고 대안을 제시하는 것이 효과적입니다.

[SAP ERP/SCM] 위탁재고(Consignment)란? 개념정리

가시가되어 — Mon, 9 Mar 2026 14:12:47 +0900

[SAP ERP/SCM] 위탁재고(Consignment)의 모든 것: 개념부터 MM/SD 프로세스, 재무 통합 및 데이터 구조까지 완벽 정리

기업의 공급망 관리(SCM)가 고도화됨에 따라 재고 유지 비용(Inventory Holding Cost)을 최소화하고 자본 유동성을 확보하는 것은 기업 생존의 핵심 과제가 되었습니다.

이를 해결하기 위한 대표적인 선진 SCM 기법 중 하나가 바로 위탁재고(Consignment) 관리입니다.

SAP ERP(S/4HANA 및 ECC)는 이러한 위탁 프로세스를 표준 기능으로 완벽하게 지원하고 있습니다.

본 포스팅에서는 위탁의 기본 개념부터 구매(MM), 영업(SD) 관점의 프로세스, 재무(FI)와의 통합, 그리고 실제 SAP 시스템에서 이 데이터들이 어디서 어떻게 관리되는지 전문가 관점에서 상세히 파헤쳐 보겠습니다.

1. 위탁(Consignment)이란 무엇인가? (SCM 및 비즈니스 관점)

SCM 관점에서 위탁(Consignment)이란 '물리적인 재고의 위치'와 '재고의 법적 소유권(Ownership)'이 분리되는 특수한 재고 관리 형태를 말합니다.

일반적으로 물건을 구매하여 우리 창고에 입고하면 즉시 우리의 자산(재고)으로 잡히고 대금 지급 의무(매입채무)가 발생합니다.

하지만 위탁의 경우, 공급업체(Vendor)가 우리 회사의 창고에 물건을 가져다 놓지만(물리적 입고), 우리가 그 물건을 실제로 사용(투입/판매)하기 전까지는 소유권이 공급업체에 있는 것으로 간주합니다.

비즈니스적 기대 효과

구매자(Buyer) 입장: 재고를 창고에 보유하고 있어도 사용 전까지는 재무제표상 자산/부채로 잡히지 않으므로 운전자본(Working Capital)을 획기적으로 개선할 수 있습니다. 또한 자재 부족으로 인한 생산 차질을 예방할 수 있습니다. (VMI - Vendor Managed Inventory 전략과 자주 결합됩니다.)
공급자(Vendor) 입장: 고객사 창고에 자사 제품을 미리 배치함으로써 경쟁사 대비 납기 경쟁력(Lead Time 제로화)을 확보하고, 장기적이고 안정적인 거래 관계(Lock-in 효과)를 구축할 수 있습니다.

SAP에서는 이러한 위탁을 크게 두 가지 방향으로 나누어 관리합니다.

공급업체 위탁 (Vendor Consignment - MM 영역): 우리가 협력사로부터 위탁재고를 받아 우리 창고에 보관하는 경우.
고객 위탁 (Customer Consignment - SD 영역): 우리가 고객사 창고에 우리 제품을 위탁재고로 제공하는 경우.

2. 공급업체 위탁재고 (Vendor Consignment - SAP MM)

MM(자재 관리) 모듈에서의 위탁은 협력사의 부품이나 원자재를 우리 공장에 쌓아두고, 생산에 투입하는 순간 소유권이 이전되며 대금을 정산하는 프로세스입니다.

2.1 사전 마스터 데이터 세팅 (Master Data)

위탁 프로세스를 정상적으로 수행하기 위해서는 특별한 마스터 데이터 설정이 필수적입니다.

자재 마스터 (Material Master): 일반 자재와 동일하게 생성하되, MRP View에서 특별 조달 유형(Special Procurement Type) '10'(위탁)으로 설정하여 MRP가 위탁 PR(구매요청)을 생성하도록 유도할 수 있습니다.
위탁 정보 레코드 (Consignment Info Record - T-Code: ME11): 이 부분이 가장 중요합니다. 일반 구매는 PO(구매오더) 생성 시점에 단가가 결정되지만, 위탁은 입고 시점이 아닌 '사용(Consumption) 시점'의 단가로 정산됩니다. 따라서 시스템은 PO가 아닌 위탁 정보 레코드(Info Category: 'K')에 유지된 조건(Condition) 단가를 읽어와 정산합니다.

2.2 프로세스 흐름 및 핵심 T-Code

위탁 구매 오더 생성 (ME21N): 품목 범주(Item Category)를 'K' (위탁)로 지정하여 PO를 생성합니다. 이때 PO에는 단가와 금액이 '0'으로 표시됩니다. (소유권이 아직 넘어오지 않으므로 금액적 가치를 산정하지 않음), 비평가 재고(Non-valuated Stock )로 관리합니다.
위탁 입고 (MIGO): 이동 유형(Movement Type) 101 K로 입고 처리합니다.
- 재무적 영향: 물류 문서(Material Document)만 생성되고, 회계 문서(FI Document)는 생성되지 않습니다. 우리 재고자산이 아니기 때문입니다.
재고 이체 또는 출고/사용 (MIGO):
- 재고 이체 (Mvt 411 K): 위탁재고를 우리 회사 소유의 가용재고로 소유권 이전. (이때 회계 전표 발생: 재고자산 증가 / 미착 위탁 매입채무 증가)
- 직접 출고 (Mvt 201 K / 261 K): 코스트 센터나 생산 오더로 직접 투입. (회계 전표 발생: 원재료비 증가 / 미착 위탁 매입채무 증가)
위탁 정산 (MRKO): 일반적인 송장 검증(MIRO)을 사용하지 않습니다. 협력사가 송장을 보내는 것을 기다리지 않고, 우리가 사용한 내역을 바탕으로 자체적으로 부채를 확정 짓고 정산하는 MRKO (Consignment and Pipeline Settlement) 트랜잭션을 사용합니다.
- MRKP (T-code) 정산흐름 : 소비/출고 발생(GI, 생산오더나 코스트 센터로 출고) - 부채 발생 - MRKO를 통해 송장 없이, 소비량 확정 후 공급업체에 지급할 채무 전표를 일괄 생성

3. 고객 위탁재고 (Customer Consignment - SAP SD)

SD(영업 및 배송) 모듈에서의 위탁은 우리가 고객사 창고로 물건을 보내고,

고객이 사용/판매했다고 통보할 때 매출을 인식하는 프로세스입니다.

이 프로세스는 4가지의 고유한 오더 유형(Order Type)과 이동 유형(Movement Type)의 조합으로 이루어집니다.

이를 정확히 이해하는 것이 핵심입니다.

3.1 프로세스의 4단계 (4-Step Process)

단계	설명	오더 유형 (Order Type)	이동 유형 (Movement Type)	재무/청구 (FI/Billing)
1. 위탁 보충 (Fill-up)	고객사 창고로 재고를 보냄. 여전히 우리 소유의 특별 재고(W)로 관리됨.	KB	631 (가용재고 -> 고객위탁재고)	미발생
2. 위탁 출고 (Issue)	고객이 재고를 사용/판매함. 소유권 이전 및 매출 인식 단계.	KE	633 (고객위탁재고 -> 출고)	매출원가 발생, 청구(Billing - F2) 생성
3. 위탁 반품 (Returns)	고객이 사용 처리했던 것을 취소하고 다시 고객 창고의 위탁재고로 돌려놓음.	KR	634 (출고취소 -> 고객위탁재고)	대변 메모(Credit Memo) 생성
4. 위탁 회수 (Pick-up)	고객 창고에 남아있는 안 팔린 위탁재고를 우리 공장으로 회수함.	KA	632 (고객위탁재고 -> 가용재고)	미발생

핵심 포인트: 고객 창고에 있는 재고는 우리 시스템에서 '고객 특별 재고 Indicator: W' (Special Stock W)로 관리되며, MMBE(재고조회)에서 고객별 위탁재고 수량을 정확히 파악할 수 있습니다.

4. SAP 데이터 구조: 이 지식과 데이터는 어디서 가져오는가?

실제 SAP 시스템 내에서 위탁 데이터가 흐르고 저장되는 핵심 테이블 출처는 다음과 같습니다.

4.1 MM (공급업체 위탁) 데이터 테이블 추적

마스터 데이터 조회:
- EINA / EINE: 구매 정보 레코드 테이블. EINE-BSORT 필드 등을 통해 정보 레코드 범주 '위탁(K)'을 확인하고 해당 단가를 조회합니다.
트랜잭션 데이터 (입고/출고):
- MATDOC (S/4HANA 기준): ECC 시절의 MKPF(헤더), MSEG(아이템)가 통합된 자재 문서 테이블입니다.
- 데이터 추출 로직: 공급업체 위탁재고 이동을 보려면 MATDOC 테이블에서 SOBKZ(특별재고 지시자) = 'K' 인 데이터를 조회합니다.
- MKOL (공급업체 특별 재고): 현재 우리 공장에 깔려 있는 공급업체별 위탁재고 잔량을 집계해서 보여주는 요약 테이블입니다. (MB54 T-code의 배경 테이블)
정산 데이터 (MRKO):
- RKWA (Consignment Withdrawals): 출고(201 K 등)가 발생하면 시스템은 이 테이블에 출고 내역과 사용 금액, 세금 정보를 기록합니다. MRKO 프로그램은 바로 이 RKWA 테이블을 읽어 상태값(STATUS: 미정산 -> 정산 완료)을 업데이트하고 FI 전표 헤더(BKPF), 아이템(BSEG) 테이블에 데이터를 기록하여 회계 처리합니다.

4.2 SD (고객 위탁) 데이터 테이블 추적

영업 오더 및 딜리버리:
- VBAK / VBAP: 위탁 오더 유형(KB, KE, KR, KA)으로 생성된 오더 헤더/아이템 정보를 담고 있습니다. 아이템 범주(Item Category)가 각각 KBN, KEN, KRN, KAN으로 다르게 지정됩니다.
- LIKP / LIPS: 배송(Delivery) 정보.
고객 위탁 재고 잔량:
- MSKU (Special Stocks with Customer): 고객(KUNNR)별로 현재 얼마만큼의 위탁 자재(MATNR)가 남아있는지 재고 수량을 보여주는 핵심 테이블입니다. 위탁 보충(631) 시 수량이 증가하고, 위탁 출고(633) 시 수량이 차감됩니다.

5. 결론

SAP의 위탁(Consignment) 프로세스는 단순히 시스템 기능을 켜는 수준이 아니라, 구매, 영업, 물류 창고 관리, 그리고 재무 회계 부서 간의 긴밀한 협의가 필요한 크로스 펑셔널(Cross-functional) 프로세스입니다. 또한 단순한 물류 기능을 넘어 파트너십과 데이터 공유의 장점이 있습니다.

특히 프로젝트 구축 시 가장 많이 발생하는 이슈는 '단가 관리의 시점 차이'입니다.

위탁재고를 소비(출고)하는 시점의 Info Record 단가와 실제 공급업체가 생각하는 단가가 일치하지 않으면, MRKO 정산 시 오류가 발생하거나 재무적인 차이(Variance)가 발생하게 됩니다. 따라서 OBYC (자동 계정 지정) 설정 시 위탁 지급금(KON) 및 재고 평가 차이(AKO) 계정 매핑을 완벽하게 설계해야 합니다.

SAP 가격 단위(BPRME, PEINH)와 라운딩 설정 완벽 정리 (OB90, 조건 라운딩, 단수차 해결)

가시가되어 — Thu, 5 Mar 2026 16:34:14 +0900

SAP 가격 단위(BPRME, PEINH)와 라운딩 설정 완벽 정리 (OB90, 조건 라운딩, 단수차 해결)

SAP MM 또는 SD 모듈에서 가격 계산을 다루다 보면 다음과 같은 문제를 자주 경험하게 됩니다.

가격 단위가 맞지 않는 문제
소숫점 단수차 발생
주문 금액과 송장 금액 차이
세금 계산 오차

이러한 문제를 이해하려면 SAP 가격 계산의 핵심 요소인 BPRME, PEINH, 조건 라운딩, 통화 라운딩(OB90)을 이해해야 합니다.

이 글에서는 SAP 가격 계산 구조와 단수차 해결 방법을 실무 관점에서 정리합니다.

* SAP 라운딩 : SAP 시스템에서 금액이나 수량을 특정 단위로 올림, 내림, 반올림하여 처리하는 기능

1️⃣ BPRME – 주문 가격 단위 (Order Price Unit)

BPRME 필드는 가격이 적용되는 단위(Unit) 를 의미합니다.

즉 가격이 어떤 단위 기준으로 설정되는지를 나타냅니다.

예를 들어 다음과 같은 경우가 있습니다.

항목	값
주문 단위	EA
가격 단위	BOX
1 BOX	10 EA
가격	100 USD

SAP 저장 예시

필드	값
BPRME	BOX
NETPR	100 USD

즉 BOX 기준 가격이 설정되고 실제 주문은 EA로 진행됩니다.

SAP는 내부적으로 단위 변환 후 가격을 계산합니다.

2️⃣ PEINH – 가격 기준 수량 (Price Unit)

PEINH 필드는 가격이 적용되는 기준 수량입니다.

예를 들어 다음과 같은 가격 구조가 있을 수 있습니다.

가격	PEINH	의미
1000원	1	1개 가격
1000원	10	10개 가격
5000원	100	100개 가격

예시

NETPR = 5000
PEINH = 100

실제 단가 계산

5000 / 100 = 50

즉 1개 가격은 50원입니다.

3️⃣ BPRME와 PEINH를 사용하는 이유

1) 주문 단위와 가격 단위가 다른 경우

실제 구매에서는 주문 단위와 가격 단위가 다른 경우가 많습니다.

예

주문	가격
EA	BOX

SAP는 BPRME를 통해 가격 단위를 관리합니다.

2) 매우 작은 단가 관리

전자부품이나 원자재에서는 단가가 매우 작습니다.

예

단가

0.001 USD

이 경우 다음과 같이 관리합니다.

가격	기준
1 USD	1000개

즉,

필드	값
PEINH	1000

이 방식은 소숫점 관리와 가격 정확도를 높입니다.

3) 공급업체 가격표 반영

공급업체는 다양한 기준으로 가격을 제공합니다.

공급업체 가격	SAP 설정
100개당 50 USD	PEINH = 100
1 BOX당 200 USD	BPRME = BOX
1 KG당 5 USD	BPRME = KG

SAP는 이러한 가격 구조를 그대로 등록할 수 있습니다.

4️⃣ SAP 가격 계산 방식

SAP에서 기본적인 가격 계산 방식은 다음과 같습니다.

실제 금액 = (NETPR ÷ PEINH) × 주문 수량

예

NETPR = 5000
PEINH = 100
주문수량 = 300

계산

(5000 / 100) × 300 = 15000

5️⃣ SAP 단수차(소숫점 차이) 발생 원인 ⚠️

가격 계산에서는 다음과 같은 이유로 단수차가 발생합니다.

예

단가 = 0.01325
수량 = 37

계산

0.01325 × 37 = 0.49025

하지만 통화 소숫점이 2자리라면

0.49

이처럼 반올림 차이가 발생합니다.

6️⃣ PEINH로 단수차 감소

PEINH 값을 크게 설정하면 단수차를 줄일 수 있습니다.

예

필드	값
PEINH	100
NETPR	1.325

의미

100개 가격 = 1.325

SAP는 내부적으로 묶음 단위 기준으로 계산하기 때문에 소숫점 누적 오차가 줄어듭니다.

7️⃣ 조건 라운딩 (Condition Rounding)

가격 조건 계산 시 발생하는 소숫점 처리는 조건 타입 설정에서 관리됩니다.

설정 트랜잭션

➡️ V/06

IMG 설정 경로

SPRO
 → Sales and Distribution
 → Basic Functions
 → Pricing
 → Pricing Control
 → Define Condition Types

주요 라운딩 방식

Standard	일반 반올림
Always Up	항상 올림
Always Down	항상 내림

예

0.49025 → 0.49

또는

0.49025 → 0.50

8️⃣ 통화 라운딩 (OB90)

통화 기준 반올림은 OB90에서 설정합니다.

설정 경로

SPRO
 → General Settings
 → Currencies
 → Define Rounding Rules for Currencies

예시

KRW	1
USD	0.01
CHF	0.05

예

10.023 → 10.02

9️⃣ 조건 라운딩 vs 통화 라운딩 우선순위

SAP 가격 계산에서는 조건 라운딩이 먼저 적용되고 통화 라운딩이 마지막에 적용됩니다.

가격 계산 흐름

1 가격 조건 계산
2 조건 금액 계산
3 조건 라운딩 적용
4 조건 금액 합계
5 통화 라운딩 적용
6 최종 금액 결정

즉

조건 라운딩 → 통화 라운딩

순서입니다.

✅ 정리

SAP 가격 계산 구조에서 중요한 요소는 다음과 같습니다.

BPRME → 가격 단위
PEINH → 가격 기준 수량
조건 라운딩 → 조건 금액 반올림
OB90 → 통화 기준 반올림

이 네 가지를 이해하면 SAP 가격 계산 구조와 단수차 문제를 대부분 해결할 수 있습니다.

특히 PEINH와 라운딩 설정은 실제 프로젝트에서 가격 오류와 금액 차이를 해결하는 핵심 설정입니다.

SAP MM / SD 가격 계산을 이해하려면 위 개념을 반드시 함께 이해하는 것이 중요합니다.

[S/4HANA] SAP Embedded ML이란?

가시가되어 — Tue, 24 Feb 2026 10:58:38 +0900

SAP Embedded ML이란?

Embedded ML (임베디드 머신러닝)은 내부에 기본 내장된 머신러닝 기능입니다.

즉, ERP 시스템 안에서 직접 학습과 예측 등의 작업을 수행할 수 있습니다.

과거엔 ERP 데이터를 외부 분석서버를 두어, 추출(ETL)하여 모델링하였지만, 이젠 데이터가 있는 곳에서 바로 수행할 수 있게 되었습니다.

1. SAP Embedded ML의 핵심 개념 및 아키텍처

주요 구성 요소

SAP HANA PAL (Predictive Analysis Library): 데이터 과학자를 위한 고급 통계 및 ML 알고리즘 라이브러리입니다. 100개 이상의 정교한 알고리즘을 제공하며, 더욱 고차원적인 분석이 가능합니다.
SAP HANA APL (Automated Predictive Library): 데이터 과학 관련 지식이 없는 비즈니스 사용자를 위해 모델 생성 및 훈련을 자동화하는 라이브러리입니다. 시스템이 스스로 적절한 모델 설계와 학습을 합니다.
ISLM (Intelligent Scenario Lifecycle Management): ML 모델의 생성, 학습, 배포, 모니터링을 관리합니다. (T-code : ISLM)

핵심 개념

1️⃣ 시스템 내부 실행

ML 모델이 S/4HANA 애플리케이션과 SAP HANA DB 내부에서 실행
별도 서버나 외부 플랫폼 없이 동작

2️⃣ 실시간 비즈니스 데이터 활용

ERP의 실시간 트랜잭션 데이터를 바로 학습/예측에 활용
데이터 이동이 거의 없어 빠르고 안정적

3️⃣ 표준 프로세스에 바로 통합

예측 결과가 Fiori 앱이나 업무 트랜잭션 화면에 직접 표시
사용자는 추가 시스템 없이 기존 업무 흐름에서 AI 활용 가능

2. 주요 기능 및 프로세스

Embedded ML은 단순히 예측값을 보여주는 것에 그치지 않고, 비즈니스 프로세스에 완전히 통합됩니다.

기능 영역	설명
모델 관리 (ISLM)	표준으로 제공되는 ML 시나리오를 활성화하거나 커스텀 모델을 관리합니다.
자동 학습 (Training)	S/4HANA 내의 실시간 트랜잭션 데이터를 기반으로 모델을 주기적으로 재학습합니다.
실시간 추론 (Inference)	사용자가 Fiori 앱에서 데이터를 조회하는 순간, ML 모델이 결과를 예측하여 화면에 표시합니다.
상황 관리 (Situation Handling)	ML이 이상 징후를 감지하면 담당자에게 알림을 보내고 해결책을 제안합니다.

모듈별 주요 활용 사례

SCM (공급망 관리):
- 재고 부족 예측: 과거 소모 패턴을 분석하여 향후 재고 고갈 시점을 예측합니다.
- 납기 지연 예측: 공급업체의 과거 퍼포먼스를 바탕으로 구매 오더의 입고 지연 가능성을 계산합니다.
Finance (재무):
- GR/IR 반제 자동화: 입고와 송장 처리 시 발생하는 차이를 ML이 분석하여 자동으로 매칭 제안을 합니다.
- 현금 흐름 예측: 고객의 지불 패턴을 분석하여 정확한 자금 수지 계획을 수립합니다.
Sales (영업):
- 판매 예측 (Sales Forecasting): 과거 판매 실적과 시즌성을 반영하여 미래 수요를 예측합니다.

SAP Embedded ML 학습 자료 및 참고

Udemy The Ultimate SAP S/4HANA Course 2026: From Zero to Expert

The Ultimate SAP S/4HANA Course 2026: From Zero to Expert

Updated for 2026 | Land a High-Paying SAP Job with No Prior ExperienceSAP S/4HANA is the digital backbone of some of the world’s most successful companies—and for good reason. Whether it's finance, logistics, HR, or supply ch

www.udemy.com

SAP Help Portal - ISLM

SAP Help Portal | SAP Online Help

help.sap.com

SAP S/4HANA On-Premise

SAP Help Portal | SAP Online Help

help.sap.com

https://training.sap.com/course/s4h00-sap-s-4hana-overview-classroom-026-kr-ko?

S4H00: SAP S/4HANA Overview

Get the best SAP Training. No one knows SAP like SAP, and no one else has the systems and experience to help you learn as effectively and get ahead in your career.

training.sap.com

https://training.sap.com/course/s4h400-sap-s-4hana-embedded-analytics-foundation-classroom-026-kr-en?

S4H400: SAP S/4HANA Embedded Analytics Foundation

Get the best SAP Training. No one knows SAP like SAP, and no one else has the systems and experience to help you learn as effectively and get ahead in your career.

training.sap.com

[SAP] 클라이언트 개념 정리, 클라이언트란?

가시가되어 — Tue, 10 Feb 2026 15:22:11 +0900

1. SAP Client란 무엇인가?

SAP 시스템 안에서 Client는 논리적 데이터 단위(격리된 업무 환경)를 의미합니다.
즉, 하나의 물리적 시스템 안에 여러 개의 Client를 두고 각각 독립적인 데이터 환경(사용자, 마스터 데이터, 트랜잭션 등)을 운영할 수 있습니다.

따라서 SAP에서 클라이언트(Client) 는 논리적인 데이터 분리 단위로 클라이언트에 의존적, 혹은 독립적으로 나눌 수 있습니다.

구분	범위
Client-Independent	시스템 전체 공통
Client-Dependent	클라이언트별로 분리

2. 클라이언트 종속 vs 비종속 데이터

✅ Client-Dependent (클라이언트 의존 데이터)

✔ 한 Client에만 존재하는 데이터
✔ 같은 시스템이라도 다른 Client에서는 보이지 않음
✔ SAP 로그인 시 선택한 Client 값이 자동 적용됨

저장되는 테이블의 첫 번째 필드가 MANDT / 타입 CLNT 이며, 해당 Client 번호가 저장됨

Logon Client 값과 MANDT 값이 일치하는 행만 자동 필터됨

데이터 내용은 Client마다 분리되어 존재

예시

사용자 정보 / 권한 (USR02 등)
마스터 데이터 (BP, 고객, 벤더 등)
Transaction 데이터(예: 결제, 회계 전표)
대부분의 Customizing 데이터, 프로그램 (CBO Z~)

✅ Client-Independent (클라이언트 비의존 데이터)

✔ 모든 Client에서 동일하게 공유되는 데이터
✔ 하나의 시스템 전체에서 공통 사용
✔ MANDT 필드가 없음

특징

첫 번째 컬럼에 클라이언트 필드가 없음
데이터를 Client로 분리하지 않음

예시

ABAP Repository 객체 (프로그램, 함수모듈, 클래스)
데이터 딕셔너리 정의(테이블, 도메인, Data Element)
트랜잭션 코드 목록
시스템 컨트롤 데이터
일부 cross-client customizing(예: 공휴일 캘린더)

즉 개발/구조/정의 정보는 전체 Client에 공통 적용됩니다.

예시) CDS에서는 @ClientHandling.type:#CLIENT_DEPENDENT 같이 처리될 수 있습니다.

The annotation “@ClientHandling.type: #CLIENT_DEPENDENT” can be used, but is optional as it is derived automatically if the CDS view reads from client-dependent tables.

3. 실무 SAP Client 예시, 데이터와 객체

SAP S/4HANA 클라이언트 100 개발(config 포함), 200 테스트 로 분리.

개발은 클라이언트 100으로 접속하여 개발 진행함.

1) ABAP 개발한 소스

대부분 Client-Independent 하며, 100에서 활성화 했을 경우, 200에서도 동일하게 조회가 됨.

2) Customizing 설정 (SPRO)

대부분 Client-Dependent
100에서 설정한 값은 200에 자동으로 안 보임

200에서 보려면:

Customizing Transport
또는 Client Copy (Tcod : SCCL / SCC1)
SCCL (Local Client Copy): 동일한 SAP 시스템 내에서 클라이언트 간 복사 (대상 클라이언트에 로그인하여 실행)
SCC1 (Client Copy by Transport Request): 개발/운영 등 타 클라이언트의 변경 사항(Transport Request)을 현재 클라이언트로 복사

3) 데이터

데이터 조회의 경우, DDIC 오브젝트 구조 확인은 가능하나 100 클라이언트에서 생성된 테스트용 데이터는 200 클라이언트에선 조회가 되지 않음.

SAP S/4HANA에서 Client 전략 요약

✔ Production 클라이언트 외 테스트/개발용 Client 분리 운영
✔ Data는 Client별로 보안/분리 요구사항이 강력
✔ Repository 객체는 모든 Client에서 동일 버전 제공
✔ CDS, RAP 등 신기술도 Client Handling 정책을 명시적으로 지원

테스트와 개발 관점

여러 Client를 만들어 동일 개발 객체로 서로 다른 데이터를 적재하며 독립 테스트 가능
동일 테이블 구조라도 MANDT 때문에 Client별 데이터 격리 보장

데이터 거버넌스(Data Governance) 정의 및 솔루션 비교

가시가되어 — Mon, 9 Feb 2026 16:21:59 +0900

데이터 거버넌스( Data Governance )

1. 데이터 거버넌스의 정의

데이터 거버넌스(Data Governance)란 기업이 보유한 데이터의 보안, 개인정보 보호, 정확성, 가용성 및 사용성을 보장하기 위해 규정된 내부 표준과 정책을 관리하는 전사적 체계입니다.

단순히 데이터를 기술적으로 관리하는 것을 넘어, '데이터를 누가, 어떤 절차에 따라, 어떻게 관리하고 활용할 것인가'에 대한 의사결정 프로세스와 책임을 정의하는 비즈니스 프레임워크입니다.

2. 데이터 거버넌스가 필요한 이유는 무엇인가?

현대 비즈니스 환경에서 데이터 거버넌스가 필수적인 이유는 다음과 같습니다.

데이터 복잡성 증대: 클라우드, 사물인터넷(IoT), 외부 API 등 데이터 소스가 파편화되면서 통합된 관리 기준 없이는 데이터 활용이 불가능해졌습니다.
규제 준수 및 리스크 관리: GDPR, CCPA, 데이터 3법 등 엄격해진 개인정보 보호 규제에 대응하기 위해 데이터의 흐름과 접근 권한을 투명하게 관리해야 합니다.
데이터 기반 의사결정(Data-Driven Decision): 신뢰할 수 없는 데이터(Dirty Data)로 도출된 분석 결과는 잘못된 비즈니스 전략으로 이어질 수 있습니다.
AI 및 머신러닝의 토대: 양질의 학습 데이터가 확보되지 않은 상태에서의 AI 도입은 '쓰레기를 넣으면 쓰레기가 나온다(Garbage In, Garbage Out)'는 결과를 초래합니다.

많은 공공기관과 회사에서 인공지능(AI)과 빅데이터 인프라를 도입하고 있지만, 정작 현장에서는 여전히 데이터가 부서별 칸막이에 갇혀 단절된 '데이터 사일로(Data Silo)' 현상을 겪고 있습니다. 기술은 있으나 이를 통합적으로 운용할 '거버넌스'가 부재하기 때문입니다.

3. 데이터 거버넌스의 핵심 구성 요소

성공적인 데이터 거버넌스를 위해서는 다음의 4가지 요소가 조화를 이루어야 합니다.

① 조직 및 역할 (Organization & Roles)

데이터 거버넌스 위원회: 최고 의사결정 기구로 전략 방향 수립.
데이터 오너(Data Owner): 특정 비즈니스 영역 데이터에 대한 소유권 및 권한 책임자.
데이터 스튜어드(Data Steward): 실제 데이터의 품질 관리 및 표준 준수를 담당하는 실무 전문가.
조직 역량 : 데이터 리더쉽(CDO), 전문인력, 교육 체계 및 데이터 활용을 장려하는 조직 문화 포함.

② 원칙 및 정책 (Policy & Principles)

데이터 생성부터 폐기까지의 생애주기 관리 표준.
데이터 보안 및 접근 권한 가이드라인.
데이터 명명 규칙(Naming Convention) 및 표준 단어 사전.

③ 프로세스 (Process)

데이터 품질 측정 및 개선 절차.
마스터 데이터 관리(MDM) 및 변경 관리 절차.
이슈 발생 시의 보고 및 해결 프로세스.

④ 기술 및 도구 (Technology)

메타데이터 관리 시스템: 데이터의 구조와 의미를 설명하는 데이터 사전.
데이터 리니지(Data Lineage): 데이터의 흐름(출처 및 변경 이력) 시각화, 추후 데이터 출처와 사용을 추적하여 오류를 파악하고 감사 대응.
데이터 품질 관리 도구: 실시간 모니터링 및 자동화된 검증 도구. 완전성, 최신성, 규정 준수 여부 등을 점검.
데이터 보안 : 무단 접근으로부터 데이터를 보호하고 암호화/익명화 등, 데이터에 접근할 수 있는 사람의 역할과 책임을 정의하고 권한을 관리

4. 데이터 거버넌스 구축 전략

현재 수준 진단(AS-IS Analysis): 기업의 데이터 관리 성숙도를 평가하고 문제점을 파악합니다.
비즈니스 목적 설정: "마케팅 타겟팅 정확도 향상"이나 "규제 준수 비용 절감" 등 구체적인 비즈니스 목표와 연계합니다.
점진적 확대(Start Small): 모든 데이터를 한꺼번에 관리하기보다, 핵심 비즈니스 데이터(Critical Data Elements)부터 시작하여 범위를 넓혀갑니다.
문화적 변화 유도: 데이터 거버넌스를 '통제'가 아닌 '지원'으로 인식하도록 사내 교육과 변화 관리를 병행해야 합니다.

5. 기대 효과

데이터 품질 향상: 일관된 기준 적용을 통한 분석 신뢰도 확보.
운영 효율성: 데이터 검색 및 가공 시간 단축으로 분석가들의 생산성 향상.
보안 강화: 민감 데이터 노출 리스크 최소화 및 규제 대응력 강화.
비즈니스 민첩성: 신뢰할 수 있는 데이터를 바탕으로 시장 변화에 빠르게 대응.

데이터 거버넌스 솔루션 비교 (국산, 글로벌)

글로벌 솔루션: 기술력과 범용성

글로벌 솔루션은 전 세계적인 표준(GDPR 등)을 준수하며, 복잡한 멀티 클라우드 환경에서의 통합 관리에 강점이 있습니다.

1. Informatica (인포매티카) - IDMC

특징: 전 세계 5,000개 이상의 대기업이 사용하며, 단순히 데이터 정리를 넘어 ETL(추출/변환), 품질 관리, 마스터 데이터 관리(MDM)까지 가장 방대한 기능을 하나의 플랫폼에서 제공
강점: 데이터 통합(ETL)부터 품질, 거버넌스까지 하나의 플랫폼에서 해결 가능합니다.

2. Microsoft Purview

특징: MS 제품군 - Azure, Office 365, Power BI와의 연동성
강점: 윈도우 환경을 쓰는 기업이라면 별도 구축 없이 바로 거버넌스를 시작할 수 있다는 접근성이 최대 강점입니다.

국내 솔루션: 규제 대응과 로컬 최적화

국내 솔루션은 한국의 데이터 환경(공공기관 표준 가이드, 개인정보보호법 등)과 국내 기업 특유의 관리 문화를 깊이 있게 반영합니다.

1. 엔코아 (En-Core) - DATAWARE

특징: 국내 데이터 컨설팅의 명가답게, 거버넌스 구축 방법론이 솔루션에 녹아있습니다.
강점: 메타데이터, 데이터 품질, 표준화 관리가 매우 촘촘하며 국내 IT 환경과의 호환성이 좋습니다.

2. 데이터스트림즈 (DataStreams) - TeraStream / Q-Stream

특징: 빅데이터와 실시간 데이터 통합에 강점을 가진 거버넌스 솔루션을 제공합니다.
강점: 자체 ETL 도구와의 연동이 강력하며, 대용량 데이터 처리 환경에서의 거버넌스 성능이 뛰어납니다.

[SCM] S&OP (Sales & Operations Planning)에 대한 상세 정의

가시가되어 — Mon, 9 Feb 2026 00:00:11 +0900

S&OP(Sales & Operations Planning) 상세 정의

1️⃣ S&OP에 대한 가장 큰 오해

❌ 현업에서 흔히 하는 말

“월/주간 S&OP 회의”
“수요예측 정확도 올려야죠”
“툴이 별로라서 S&OP가 안 됩니다”

전부 본질이 아닙니다

✅ Thomas Wallace의 정의 (핵심)

S&OP는 회사가 ‘어떤 숫자를 진실로 받아들일지’ 결정하는 프로세스다

여기서 중요한 단어:

회의 ❌
예측 ❌
결정(Decision) ⭕
합의된 숫자(Single Set of Numbers) ⭕

2️⃣ 왜 회사에는 항상 숫자가 여러 개일까?

조직별 숫자의 출처

조직	숫자의 기준
영업	시장, 목표, 희망
생산	설비, 인력, 제약
구매	리드타임, MOQ
재무	매출, 이익, 목표

모두 자기 관점에서는 맞는 숫자와 목표를 바라본다.

❗ 문제는 여기서 발생

숫자가 틀린 게 아님
숫자가 여러 개라서 결정 불가

그래서 S&OP의 존재 이유는 단 하나:

“이번 달은 이 숫자를 기준으로 움직인다”

3️⃣ S&OP의 유일한 산출물

❌ 잘못된 산출물

회의록
PPT
엑셀 파일

✅ 진짜 산출물

합의된 계획 숫자 (Approved Plan)

이 숫자는:

생산
구매
재고
매출
재무
전부의 기준값이 됨, 그렇게 되어야 함.

4️⃣ S&OP는 왜 항상 이 구조를 가질 수밖에 없는가

S&OP 기본 구조 (불변)

Demand Plan (원하는 것) => Supply Plan (가능한 것) => Gap (차이) 발생한 Trade-off 를 어떻게 보정할 지, 결정

각 단계의 본질

① Demand Plan (수요)

“얼마나 팔고 싶은가” , "얼마나 팔아야 되는가?"
희망 + 예측/경험 + 데이터

② Supply Plan

“얼마나 만들 수 있는가”, "얼마나 공급할 수 있는가?", "재고는 얼마"
제약(CAPA) + 현실

③ Gap

의사결정이 필요한 지점
자동화 ❌, 자동화로 결정될 경우 특정 조직에서 반발 여지 있음.

④ Trade-off

서비스 ↓ vs 재고 ↑
비용 ↑ vs 매출 유지

이 단계 때문에 S&OP에서 의사결정 시, 사람이 필요합니다.

5️⃣ S&OP는 절대 ‘자동화 프로세스’가 아니다

❌ 흔한 착각

“좋은/뛰어난 AI 예측 넣으면 해결”
“툴/솔루션을 바꾸면 잘 될 것”

✅ 현실

예측은 예측이지, 실제와 동일하지 않음.
제약은 항상 존재
상황은 항상 변함, 돌발 상황을 배제할 수 없음.

그래서 S&OP는:

자동 계산 + 사람 결정의 결합

6️⃣ IT / 시스템 관점에서 S&OP를 보는 법 (핵심)

운영자가 아닌 설계자의 질문

다음 질문에 답할 수 있으면
이미 S&OP 설계자 사고입니다.

Q1. Demand 숫자는 어디서 오는가?

SAP SD? - 판매실적을 불러옵니다.
영업 엑셀? - 엑셀로 관리하는 영업팀이 대다수이죠.
S&OP Tool? - S&OP 시스템이 있다면 어떻게 계획과 실적을 관리하는지 확인해야 합니다.
Single Source of Truth (단일 진실 공급원) 으로 관리되는가?

Q2. 숫자를 누가 바꿀 수 있는가?

누구나?
특정 역할만?
승인 프로세스 있음?

권한 = 프로세스 성숙도

Q3. 숫자 변경 이력은 남는가?

언제
누가
왜

이력이 관리되지 않으면, S&OP 없음

Q4. Gap은 언제 보이는가?

S&OP 회의 전에?
회의 중에 처음?

회의 중에 처음 보면 시스템 실패 가능성이 크다. 사전에 Gap이 발생되는 이유를 충분히 파악/분석해야 합니다.

7️⃣ S&OP 성숙도 레벨 (자가진단)

레벨	상태
Level 0	엑셀 & 사람 기억
Level 1	툴은 있음, 결정은 회의실
Level 2	사전 시나리오 존재
Level 3	합의된 숫자가 시스템에 반영
Level 4	재무까지 완전 연계

대부분의 회사는 Level 1~2 수준일 가능성이 큽니다.

8️⃣ 당신 회사에 바로 적용하는 S&OP 관련 핵심 질문

아래 질문에 문장으로 답해보세요.

우리 회사에서
“이번 달 기준 숫자”는 어디에 저장되는가?
그 숫자는
누가 승인하는가?
승인된 숫자는
어디까지 전파되는가?
(생산? 구매? 재무?)

이 답이 곧 현재 S&OP 구조도가 될 것입니다.

같이 보면 좋을 글

SCM 판매 및 운영 계획(S&OP)이란 무엇인가? (솔루션 비교)

IT 시스템 운영자 관점에서의 S&OP, SCM 시스템에 대한 고찰 판매 및 운영 계획(S&OP) 개요 : Sales and Operations Planning : 급변하는 공급망/환경 변화에 대해 탄력적 대응이 필요하며, 수요와 공급의 불균

kora1492.tistory.com

Thomas Wallace S&OP

Book Review : Thomas F. Wallace, 「SCM의 중심, S&OP 」

저자 / 출판사(출판연도) : 톰 왈리스 / 엠플래닝(2003) 독서 계기 : S&OP 운영 프로세스를 익히기 ...

blog.naver.com

What is sales and operations planning (S&OP)?

[AI 시대] 사라지는 직업과 살아남는 전략은 무엇일까?

가시가되어 — Fri, 6 Feb 2026 16:45:11 +0900

[AI 시대] 사라지는 직업과 살아남는 전략은 무엇일까?

우리는 지금 인류 역사상 가장 가파른 변화의 변곡점일 수 있는 2026년을 지나고 있습니다.

AI는 더 이상 '신기한 기술'이 아니라 우리의 일자리, 교육, 경제 구조, 그리고 삶의 방식 자체를 재정의하고 있습니다.

특히 단순한 LLM 기반의 생성형 AI만이 아닌 AI 에이전트, 로봇 등 피지컬 AI가 대두되고 있습니다.

오늘은 AI로 인해 사라질 직업의 순서부터 2040년의 미래 전망, 그리고 한국 사회의 특수한 리스크와 개인의 대응 전략까지 심층적으로 분석해 보겠습니다. (개인적인 고찰)

1. AI 직업 대체 리포트: 무엇이 먼저 사라지는가?

AI의 직업 대체는 '지능의 높고 낮음'이 아니라 '업무의 정형성'에 따라 결정됩니다.

규칙이 명확하고 데이터화하기 쉬운 일부터 단계적으로 대체될 가능성이 큽니다.

1단계: 즉시 대체 (사무 및 반복 업무)

데이터 입력, 텔레마케팅, 단순 회계 및 경리, 기초적인 고객 상담 등이 이에 해당합니다.

이미 많은 기업에서 LLM(거대언어모델) 기반의 챗봇과 자동화 툴이 인간의 업무를 대체하고 있습니다.

2단계: 1~3년 내 (지식 가공 및 주니어급 전문직)

번역가, 초급 프로그래머, 기술 문서 작성자, 기초 그래픽 디자이너가 타겟입니다.

AI는 이제 단순 코딩을 넘어 시스템 설계 보조까지 가능해졌으며, 번역과 디자인 영역에서는 인간의 속도를 압도하고 있습니다.

최근 많은 IT 기업에서 신입 채용이 감소하는 현상이 보이고 있습니다.

AI를 통한 코딩의 퀄리티가 올라감에 따라 AI가 생성한 코드의 정합성 및 영향도, 결함을 파악하고 이를 응용할 수 있는 시니어 개발자로서의 역량이 중요해졌습니다. 즉, 단순 개발하는 개발자로서의 가치가 감소하고 있습니다.

3단계: 5년 내 (전문직 보조 및 분석 업무)

법률 사무원(판례 분석), 세무사(표준 신고), 영상 편집자, 기본 진단을 수행하는 의사 등이 포함됩니다.

방대한 데이터를 분석해 결론을 내는 일은 이제 인간보다 AI가 더 정확하고 빠릅니다.

전체적으로, 일론 머스크 등은 컴퓨터/사무직, 프로그램을 다루는 개발자 등은 빠르게 AI로 인해 대체될 수 있다고 경고합니다.

그렇다면 누가 살아남는가?

복합적 육체 노동자: 배관공, 전기 기술자, 현장 엔지니어. 로봇이 현장의 수만 가지 변수를 대응하는 비용은 아직 인간의 인건비보다 훨씬 비쌉니다. 단순한 노동자가 아닌 숙력된, 전문적인 기술을 갖고 있는 육체 노동자입니다.
정서적 교감 전문가: 심리 상담사, 사회복지사, 초등 교육자. '진정성'과 '신뢰'와 인간미/인간다움이 담보되어야 하는 영역입니다. 또한 인간다움의 진성성을 파는 엔터테인먼트 산업(운동선수, 연예인(아이돌, 배우)) 도 생존할 것으로 생각합니다.
최종 의사결정자: 기업 경영인, 고위 정치인. 결과에 대해 '법적·도덕적 책임'을 져야 하는 자리는 AI에게 맡길 수 없습니다.

그렇지만, 초지능이 도래하고 머나 먼 미래엔 인간의 직업적 가치, 노동 등의 의미가 퇴색될 여지도 충분합니다.

2. SAP ERP /SCM IT 전문가의 시선: 현장의 변화는 더디지만 확실하다

현재 SAP/SCM 운영 업무를 담당하고 있다면, 매체에서 말하는 '즉각적인 해고' 공포에서는 조금 자유로울 수 있습니다.

현재 피부로 체감하기 힘든 게 사실입니다.

특히 기업의 심장인 기간계 시스템(ERP)은 보수적이기 때문입니다.

도입까지 걸리는 진입 장벽들과 미래를 생각해봅시다.

현실적인 허들: 데이터 정합성 문제, 복잡한 커스터마이징(CBO), 리스크 관리의 책임 소재라는 결정하기 힘든 것들이 존재하며 특히 비용을 투자하는 의사결정에서 AI 도입 속도는 예상보다 늦을 수 있습니다.
미래의 모습: 하지만 S/4HANA 마이그레이션(SAP ECC 버전의 EOS)과 SAP BTP 기반의 AI 서비스, SAP Joule 등이 안착되면, 단순 운영 업무의 50% 이상은 자동화되고 간소화되며 대체될 것입니다.
생존 전략: 이러한 파도 속에서 IT 운영담당자는 단순 'Operator'에서 '솔루션 아키텍쳐'로 진화해야 합니다. AI가 뱉어낸 데이터가 비즈니스 맥락에서 맞는지 검증하고, 공급망 전체를 설계할 수 있는 도메인 지식이 핵심 무기가 될 것입니다.

3. 한국 사회의 특수 리스크: 사교육과 전문직의 덫

한국은 전 세계에서 사교육 열풍이 가장 뜨거운 나라입니다. 정부/사회에서는 이러한 문제를 바로잡고 싶지만 더욱 더 심화되었죠.

하지만 AI 시대에는 이 '과거의 성공 방정식 = 주입식 교육'이 가장 큰 리스크가 됩니다.

사다리의 붕괴: 좋은 대학과 전문직을 위해 쏟아부은 수억 원의 사교육비, 시간이 '매몰비용'이 될 수 있습니다. AI가 전문직 업무를 보조하게 되면서, 신입 채용 시장은 급격히 얼어붙을 것입니다. 부작용으로 현재 우리나라의 목표는 의치한약수라 불리는 의과계열을 희망하고 있는데 의료계 또한 AI, 로봇 등의 도입되면서 의사 수요 자체가 줄어들 수 있습니다. 더 큰 문제는 많은 일자리들이 사라졌을 때가 큰 문제겠죠.
인적 자원의 병목 현상: 이후 신규 채용이 줄어들면, 청년층은 더욱 안정적인 '면허 기반 전문직'에 몰리게 됩니다. 하지만 전문직 또한 AI로 인해 하향 평준화될 가능성이 높으며, 이는 사회적 활력 저하와 허무주의를 야기합니다.
세대 간 갈등: 일자리를 가진 기성세대와 기회를 박탈당한 청년세대 사이의 부의 재분배 문제가 정치적·사회적 뇌관이 될 것입니다.

4. 2040년 전망: 일론 머스크의 '보편적 고소득'은 올 것인가?

일론 머스크는 노동이 필요 없는 '보편적 고소득(UHI)' 시대를 예언합니다.

그러면서 더 이상 저축이 필요 없으며, 테슬라 등의 주식 투자하는 것도 의미가 없다라고 말합니다.

노동 가치는 붕괴되며, 노동은 단순한 취미활동으로 변하게 될 것이라 전망하였습니다.

객관적 전망: AGI가 만들어진 다음, ASI 초지능이 도래한 2040년경에는 에너지 비용 하락과 로봇 노동력의 보급으로 생존에 필요한 기본 물가는 폭락할 것입니다. 즉, 굶어 죽을 걱정이 없으며, 누구나 원하는 것을 얻을 수 있는 '풍요의 시대'는 올 가능성이 높습니다. 사실 전제인 AGI - ASI의 도래와 기술적 특이점이 2040년 안에 올 지는 미지수이죠.
이러한 보편적 고소득 시대(유토피아)에서의 중요한 가치는 '인간의 창의성'과 '정신적 의미 찾기', '철학' 과 같은 사고/고찰에서 찾을 수도 있겠습니다.

하지만: 이것이 모두가 똑같이 부유해짐을 의미하지는 않습니다. 과거 봉건제도에서는 농민/농노는 지배 받는 계급일뿐 대체가 되진 않았습니다. 반면 AI 시대는 다를 수 있어요. 인간이 무쓸모/무의미한 계급으로 전락할 수 있습니다. 또한 '희소 자원(땅, 명품, 프리미엄 서비스)'을 차지하기 위한 경제적 계급은 여전히 존재할 수 있습니다, AI 자산을 소유한 자와 배당금으로 살아가는 자 사이의 양극화는 더 심해질 수 있음을 항상 경계해야 합니다.

5. 지금 당장 준비해야 할 3대 생존 전략

우리는 경제, 의식주, 의식 세 가지 측면에서 완전히 새로운 방어 체계를 구축해야 합니다.

① 경제적 측면: 노동 소득에서 자본 소득으로

나의 노동 가치가 떨어지는 속도보다, AI 기술이 만드는 부의 가치가 올라가는 속도가 더 빠릅니다.

AI에 투자하라: 내 일자리를 위협하는 기술을 가진 기업(구글, Nvidia, MS 등)의 주주가 되어 내 노동 가치의 하락을 '헤징'해야 합니다.
회사가 나를 '대체 불가능한 사람'으로 인식하게 만들도록 - 단순한 노동자가 아닌 프로세스를 컨트롤하고 설계하는 사람이 되어야 합니다.

② 의식주 측면: 효율성보다 회복 탄력성

건강이 최고의 자산: 수명이 연장되는 시대에 '질병 없는 삶'은 가장 큰 경제적 절약입니다.
실물 자산과 커뮤니티: 디지털화가 가속될수록 신뢰할 수 있는 사람들과의 오프라인 네트워크, 그리고 가치를 보존할 수 있는 실물 자산의 중요성은 커집니다.

③ 의식 측면: 정답이 아닌 '질문'을 하는 인간

비판적 사고와 문해력: AI가 주는 정보의 진위 여부를 가릴 수 있는 능력이 없으면 AI의 노예, 바보가 됩니다.
유연한 정체성: "나는 OO 업무를 하는 사람이다"라는 정의를 버리고, "나는 문제를 해결하는 가치 창출자다"라는 유연한 마인드셋을 가져야 합니다.

6. 언어 학습: 영어와 중국어, 여전히 필요한가?

AI 번역기가 완벽해지는 시대에 외국어 공부가 시간 낭비처럼 보일 수 있습니다.

하지만 당장 '정보 권력' 측면에서 언어는 여전히 중요합니다.

영어 (필수): AI의 모국어는 영어입니다. 최신 정보와 고급 프롬프트 기술은 영어권에서 가장 먼저 나옵니다. 영어는 이제 소통의 수단이 아니라 AI를 다루는 OS(운영체제)입니다.
중국어 (전략적): SCM 분야에 계신다면 제조와 물류의 거대 축인 중국의 기술 문서를 직접 읽고 현지 생태계를 파악하는 능력은 대체 불가능한 프리미엄이 됩니다.

맺음말: 노동의 시대에서 '의미의 시대'로

2030년이 넘어가면 우리는 '어떻게 돈을 벌 것인가'보다 '남는 시간을 어떻게 의미 있게 보낼 것인가'를 더 고민하게 될 것입니다.

노동이 선택이 되는 시대, 당신의 가치는 당신이 내리는 질문의 깊이와 타인에게 주는 진정성에서 결정될 것입니다.

두려워하기보다 AI를 가장 먼저 내 도구로 만드십시오.

변화의 파도 위에서 서핑을 즐기는 사람이 되시길 바랍니다.

[DB] MS-SQL(SQL Server) View 확인하는법

가시가되어 — Thu, 5 Feb 2026 14:45:50 +0900

[DB] MS-SQL(SQL Server) View 확인하는법

SQL Server 에서 View 쿼리 / 구조 확인하는 법에 대한 정리 (DBMS, 프로시저)

✅ 0. SSMS(SQL Server Management Studio) 에서 가장 간단한 방법 (GUI)

방법 1️⃣ 스크립트로 보기

SSMS 접속
Database → Views → 해당 View 우클릭
뷰 스크립팅(Script View as) → CREATE To → 새 쿼리 편집창(New Query Editor Window)

View 생성 시 사용된 원본 쿼리가 그대로 나옵니다.

방법 2️⃣ 설계 보기

원하는 View 우클릭
설계(G)

JOIN, WHERE 조건 등을 시각적으로 + SQL로 동시에 확인 가능

✅ 1. Dbeaver(디비버) 사용 시 조회하는 법

방법 1️⃣ 스크립트로 보기

Dbeaver 접속
Database → Views → 해당 View 우클릭
View View → Properties → Definition

✅ 2. 시스템 프로시저로 조회

EXEC sp_helptext '뷰이름';

View 정의가 여러 줄로 나뉘어 출력됨
가장 안전하고 정석적인 방법

✅ 3. OBJECT_DEFINITION 사용 (한 줄로 확인)

SELECT OBJECT_DEFINITION(OBJECT_ID('뷰이름'));

⚠️ 주의

결과가 길면 NULL로 나올 수 있음
암호화된 View는 조회 불가

✅ 4. sys.sql_modules

SELECT definition FROM sys.sql_modules WHERE object_id = OBJECT_ID('dbo.vw_SalesSummary');

✔️ 장점

View / Procedure / Function 모두 가능
운영 서버에서 표준적으로 많이 사용

✅ 5. 암호화된(View WITH ENCRYPTION) 경우

암호화된 View - CREATE VIEW vw_test WITH ENCRYPTION AS SELECT ...

이런 경우:

❌ sp_helptext 안됨
❌ OBJECT_DEFINITION 안됨
❌ sys.sql_modules 안됨

해결책

백업본 / 소스관리(Git) / 설계 문서에서 확인해야 함.
DB 내부에서 복구는 사실상 불가능하므로 백업을 잘해야 함.

✅ 추천 우선순위 (실무 기준)

상황	추천 방법
전체적인 구조로 보고 싶다	SSMS/DBMS
표준적인 방법	sp_helptext

대체적으로 DBMS 내 기능을 통하면 간단히 조회가 가능합니다.

뷰의 위치나 찾으러 가기 귀찮은 경우, sp_helptext 프로시저를 호출해서 조회하는 걸 추천드립니다.

암호화된 View의 경우, 선언을 조회하기 힘들기에 백업/문서화가 필요로 합니다.

[PCCP 기출문제] 2번 퍼즐 게임 챌린지 JAVA 풀이 및 복기

가시가되어 — Wed, 28 Jan 2026 16:58:59 +0900

퍼즐 게임 챌린지 JAVA 코딩테스트 문제 풀이 복기 기록

1. 문제 이해

문제 유형: 이분 탐색 + 시뮬레이션
입력: diffs[] (난이도 차이), times[] (걸리는 시간), limit (총 시간 제한)
목표: 최소 level을 찾아, 퍼즐 시간을 limit 이하로 만들기

중요 포인트

단순 반복문으로 1~300,000까지 탐색하면 시간 초과
level 증가 → diffs[i] - level 감소 → 소요 시간 감소
즉, 단조성(monotonicity) 존재
이분 탐색(Binary Search)의 핵심 전제 조건인 단조성(Monotonicity)은 탐색 범위 내에서 값이 일정한 방향으로 증가하거나 감소하는 성질을 의미

2. 문제 접근 방식

완전 탐색으로 먼저 생각
- level 1~300,000을 돌면서 체크 → 시간 초과
단조성 관찰
- level ↑ → 소요 시간 ↓
- 조건 만족 여부 YES/NO 판별 가능
이분 탐색 떠올림
- 조건을 충족하는 최소 level을 찾는 문제 → Lower bound 유형
검증 함수 작성
- puzzleCheck(level)
- level을 넣으면 소요 시간을 계산하고, limit 초과 시 -1 반환

3. 핵심 힌트/착안점

단조성 확인 → 이분 탐색 가능
mid가 정답 후보인지 확인 → YES → answer 갱신, 오른쪽 범위 줄이기
자료형 주의 → 소요 시간이 long 범위 가능
이전 시간 처리(첫번째 퍼즐을 바로 풀지 못하는 Case): 첫 번째 퍼즐은 이전 퍼즐이 없으므로 time_prev를 0으로 처리하거나 조건문으로 예외 처리 필요

4. 구현 흐름 요약

left = 1, right = 100000, answer = right
while(left <= right) 반복
- mid = (left + right) / 2
- puzzleCheck(mid) 결과 확인
 - 성공 → answer = mid, right = mid - 1
 - 실패 → left = mid + 1
종료 후 answer 반환

실제 구현 소스코드

class Solution {
    public int solution(int[] diffs, int[] times, long limit) {
        int answer = 0;

        // 처음부터 끝까지 돌린다 -> 시간초과 
        // diff
       /** for(int level=1; level<=300000; level++){
            
            long result = puzzleCheck(level, diffs, times, limit);
            
            if(result != -1) return level;
        }
        **/
        
        int left = 1;
        int right = 100000;
        
        while (left <= right) {
            
            int mid = left + (right - left) / 2;
            
            long result = puzzleCheck(mid,diffs,times,limit);
            //System.out.println ("mid : "+mid+ " result "+result);
            
            if(result != -1) {
                answer = mid;
                right = mid - 1;
            } else {
                left = mid + 1;
            }
            
        }
        return answer;
    }
    
    public static long puzzleCheck(int level, int [] diffs, int [] times, long limit){
                
        int time_prev = 0;
        long time_total = 0;
        
        for(int i=0;i<diffs.length;i++){
            //System.out.println("level : "+ level + " time_total "+time_total+" time_prev" + time_prev);

            if(limit < time_total) return -1;
            else {
                int count = diffs[i] - level;
                
                if(count <= 0) {
                    time_total += times[i];
                } 
                else {
                    time_total += (times[i]+time_prev) * count + times[i];
                    
                }
                time_prev = times[i];
            }      
        }

        if(limit < time_total) return -1;
        return time_total;
        
    }
}

5. 회고 및 개선점

✅ 완전탐색(선형탐색) 시, 시간초과 문제 → 단조성 발견 후 이분 탐색 적용
⚠️ 주의할 점
- 자료형 오버플로우: 곱셈 시 long 사용
향후 개선 포인트
- puzzleCheck()에서 불필요한 변수 제거
- 테스트 케이스로 단조성 검증
- 범위를 더 좁게 설정 가능
- 시간복잡도 계산 후 탐색 접근 필요
- 단조성 패턴 발견 → 완전 탐색 → 시간 초과 → 이분 탐색 떠올려볼것
- 다시 풀어볼 문제!
- 비슷한 유형인 백준의 '랜선 자르기'나 '나무 자르기' 문제도 도전

[DB] SQL Server(MS-SQL) 운영 - DBCC 명령어 정리

가시가되어 — Tue, 27 Jan 2026 17:08:52 +0900

[DB] SQL Server(MS-SQL) 운영 - DBCC 명령어 정리

️ DBCC란 무엇인가요?

DBCC(Database Console Commands)는 데이터베이스의 상태를 점검하고, 유지보수하며, 관리 작업을 수행하는 데 사용되는 매우 강력한 명령어 세트입니다.

DBCC는 크게 네 가지 카테고리로 나뉩니다.

유지관리(Maintenance): 인덱스 재구성, 파일 크기 조정 등.
유효성 검사(Validation): 데이터베이스의 물리적/논리적 무결성 확인.
정보 제공(Informational): 성능 통계 및 설정값 확인.
기타(Miscellaneous): 추적 플래그 설정 등 특수 작업.

DBCC 명령어 실행을 통해 무결성 / 로그 스페이스 / 실행 중인 트랜잭션 / Shink 를 통한 로그 정리 등을 가능합니다.

IT 운영팀 필수 DBCC 명령어 Top 10

1. DBCC CHECKDB (무결성 점검)

가장 중요한 명령어입니다. DB 내 모든 개체의 논리적, 물리적 무결성을 검사합니다.

언제 쓰나요? 정기 점검 시, 혹은 DB 복원 후 데이터에 이상이 없는지 확인할 때.
명령어: DBCC CHECKDB ('DB이름');

2. DBCC SQLPERF(LOGSPACE) (로그 공간 모니터링)

모든 데이터베이스의 트랜잭션 로그 파일 크기와 사용률을 한눈에 보여줍니다.

언제 쓰나요? LDF 파일이 가득 차서 서비스가 멈추는 것을 방지하기 위한 모니터링 용도.
명령어: DBCC SQLPERF(LOGSPACE);

3. DBCC OPENTRAN (활성 트랜잭션 확인)

특정 DB에서 가장 오래된 활성 트랜잭션을 찾아줍니다.

언제 쓰나요? 로그 파일이 줄어들지 않거나, 특정 세션이 락(Lock)을 잡고 해제하지 않을 때 원인을 찾기 위해 사용합니다.
명령어: DBCC OPENTRAN ('DB이름');

4. DBCC SHRINKFILE (로그 파일 크기 줄이기)

비대해진 로그 파일(.ldf)의 물리적 크기를 줄여 디스크 공간을 확보합니다.

⚠️ 주의: 데이터 파일(.mdf)을 줄이는 것은 성능 저하(단편화)를 유발하므로 권장하지 않으며, 로그 파일 위주로 사용하세요.

명령어: DBCC SHRINKFILE (로그파일명, 목표용량MB);

5. DBCC INPUTBUFFER (실행 쿼리 확인)

특정 세션(SPID)이 현재 실행 중인 쿼리가 무엇인지 확인합니다.

언제 쓰나요? CPU 점유율이 높은 프로세스가 정확히 어떤 쿼리를 돌리는지 잡고 싶을 때.
명령어: DBCC INPUTBUFFER (SPID번호);

6. DBCC FREEPROCCACHE (실행 계획 캐시 삭제)

SQL Server가 저장하고 있는 쿼리 실행 계획 캐시를 강제로 비웁니다.

언제 쓰나요? 특정 쿼리가 잘못된 실행 계획을 잡고 성능이 급락했을 때 긴급 조치로 사용합니다. (전체 서버 성능에 일시적 부하를 줄 수 있으니 주의!)
명령어: DBCC FREEPROCCACHE;

7. DBCC USEROPTIONS (세션 설정 확인)

현재 연결된 세션의 설정(격리 수준, 날짜 형식 등)을 확인합니다.

언제 쓰나요? 애플리케이션 연결 설정이 의도한 대로(예: Read Committed) 되어있는지 확인할 때.
명령어: DBCC USEROPTIONS;

8. DBCC SHOW_STATISTICS (통계 정보 상세 확인)

인덱스나 테이블의 통계 정보가 얼마나 최신인지, 데이터 분포는 어떤지 상세히 보여줍니다.

언제 쓰나요? 인덱스는 있는데 쿼리가 느릴 때, 통계 정보가 꼬였는지 확인하기 위해 사용합니다.
명령어: DBCC SHOW_STATISTICS ('테이블명', '인덱스명');

9. DBCC CLEANTABLE (삭제된 데이터 공간 반환)

가변 길이 컬럼(varchar, text 등)에서 데이터를 대량 삭제한 후, 즉시 공간을 반환하게 합니다.

언제 쓰나요? 대규모 데이터 삭제(Delete) 후 디스크 공간이 즉시 확보되지 않을 때 강제로 실행합니다.
명령어: DBCC CLEANTABLE ('DB이름', '테이블명');

10. DBCC DROPCLEANBUFFERS (메모리 버퍼 비우기)

메모리에 캐시된 데이터 페이지를 모두 삭제합니다.

언제 쓰나요? 튜닝 작업 시, 메모리 효과를 배제한 "최악의 성능(Cold Start)"을 테스트하고 싶을 때 사용합니다. (운영 서버에서는 절대 금물!)
명령어: DBCC DROPCLEANBUFFERS;

운영팀을 위한 Tip

자동화: DBCC CHECKDB는 가급적 사용자가 적은 새벽 시간에 유지관리 계획(Maintenance Plan)으로 자동화해 두는 것이 좋습니다.
DMV와의 병행: 최근 MS는 DBCC 대신 sys.dm_exec_input_buffer 같은 DMV(동적 관리 뷰) 사용을 권장하고 있습니다. DBCC가 손에 익으셨다면 서서히 DMV도 함께 공부해보시는 걸 추천드려요.
DMV 동적 관리뷰에 대해서도 정리하도록 하겠습니다.

DBCC 명령어 요약

목적	명령어
로그 상태	DBCC SQLPERF
가장 오래된 활성 트랜잭션 검사	DBCC OPENTRAN
무결성 검사	DBCC CHECKDB
파일 줄이기	DBCC SHRINKFILE
캐시 초기화	DBCC FREEPROCCACHE

[APM] Scouter , 스카우터란 무엇인가? (서버 및 Java 설치)

가시가되어 — Fri, 23 Jan 2026 16:12:57 +0900

Scouter APM 개념 총정리

1️⃣ Scouter란 무엇인가?

Scouter = 오픈소스 APM(Application Performance Monitoring)
서버와 애플리케이션의 성능·상태·병목을 실시간으로 수집/분석하는 도구

2️⃣ 왜 Scouter가 필요한가?

❌ APM 없을 때

CPU 낮은데 서비스 느림
사용자 “느리다”는 말만 있음
로그 뒤지고, 재현 안 되고, 감으로 판단

✅ Scouter 있을 때

어느 API가 느린지
DB 쿼리가 몇 ms인지
어느 서버에서 GC가 터졌는지
특정 시간대에만 느린 이유

감 → 데이터 기반 판단으로 전환

Scouter 서버 설치 가이드

1️⃣ 먼저 아래 github 경로에서 최신 Release Version 설치

1. scouter-all-X.X.X.tar.gz (서버용)
2. scouter.client (모니터링용)

https://github.com/scouter-project/scouter/releases/

Releases · scouter-project/scouter

Scouter is an open source APM (Application Performance Management) tool. - scouter-project/scouter

github.com

2️⃣ Scouter 서버 세팅 및 실행, 주의점, 에러

스카우터 서버 는 scouter-all-X.X.X.tar.gz 내 폴더 server

가장 중요한 것!!

Scouter 서버는 Java 8 필수(JDK 8)

java -version

만약 설치할 서버의 자바버전이 8이 아닌 JDK11/JDK17과 같은 버전에서는 아래와 같은 에러가 발생됩니다.

java.security.PrivilegedActionException: java.lang.NoSuchMethodException

OpenJDK8 - OpenJDK 8u342 GA Release은 해당 경로에서 설치하였습니다.

또 하나의 주의사항!!
리눅스인 경우, 아래 서버 아키텍쳐를 점검해서 받을 것

uname -m

서버	결과의미
x86_64	일반 인텔/AMD 서버
aarch64	ARM 서버 (Graviton, 국산 서버 다수)

서버 scouter.conf 기본 설정
net_collector_ip는 Scouter 서버가 “어디 IP로 수집 요청을 받을지”를 정하는 값입니다.
0.0.0.0 으로 설정 시 모든 망에서 접속이 가능합니다.
특정 IP로 들어오는 요청만 수신 받고 싶은 경우, 해당 IP를 넣어주면 됩니다.

net_collector_ip=0.0.0.0
net_collector_udp_port=6100
net_collector_tcp_port=6100

서버 시작 / 종료 는 아래 서버 내에서 명령어를 실행합니다.

-- 실행
./startup.sh

-- 종료
./stop.sh

단, 사전에 chmod -R 777 로 권한이 빠진 게 있으면 호출이 안될 수 있으니 부여해줍니다.
서버 정상 유무는 아래 명령어를 통해 확인 가능합니다.

ps -ef | grep scouter

만약 서버의 기본 JDK가 8버전이 아닌 다른 버전이고 이걸 공유하는 게 많아 기본 JDK를 수정하기 힘들다고 할 시,
startup.sh 에서 JAVA_PAHT를 임의로 변경해주면 됩니다.

export JAVA_HOME
export PATH

3️⃣ Scouter의 전체 구조 (개념도)

[ User ]
   ↓
[ WAS / Server ]
   ↑        ↑
Java Agent  Host Agent
     \      /
      → Scouter Server →
              ↑
         Scouter Client

4️⃣ Scouter Agent 세팅방법

수집 대상 WAS(JAVA)에 설치하는 방법입니다.
WAS는 Java 기반이면 모두 가능합니다. - Jeus, Tomcat, Weblogic
아래는 대표적으로 우리나라에서 많이 쓰이는 상용 JEUS와 오픈 소스 톰캣 설정 예시입니다.

우선 앞서, GitHub Release에서 받은 Scouter 압축 안에 포함된 agent.java를 사용합니다.

/scouter/agent/conf/scouter.conf 파일을 먼저 설정합니다.
WAS 식별 이름과 스카우터 서버의 IP 정보를 넣어줍니다.
이 식별자는 WAS가 여러 개인 경우 중복되지 않게 넣습니다.

# Scouter Server 정보
net_collector_ip=스카우터서버IP
net_collector_tcp_port=6100
net_collector_udp_port=6100

# WAS 식별 이름 (중요)
obj_name=was01

# 서비스 그룹 (선택)
obj_type=tomcat

[Jeus]

WebAdmin Console 화면에서 Server > Jvm Config
아래 javaagent 설정을 넣어줍니다.

-javaagent:/"스카우터 agent 설치경로"/scouter.agent.jar -Dscouter.config=/"스카우터conf경로"/scouter.conf -Dobj_name="object 명칭"

[Tomcat]

setenv.sh 옵션을 설정해서 javaagent 설정을 해줍니다.

SCOUTER_AGENT_DIR=/opt/scouter/agent

JAVA_OPTS="$JAVA_OPTS \
-javaagent:$SCOUTER_AGENT_DIR/scouter.agent.jar \
-Dscouter.config=$SCOUTER_AGENT_DIR/conf/scouter.conf"

Scouter의 강점

장점

오픈소스 (비용 0)
실시간성 뛰어남
Java 추적 깊음
서버 부담 적음

⚠️ 한계

UI 투박
설정이 수동적
클라우드 네이티브는 약함

오픈소스 APM 스카우터 한눈에 요약하기

구글 notebooklm 인포그래픽

인프런 서바이벌 챌린지 완벽 분석! - 공부하면서 돈벌기

가시가되어 — Wed, 21 Jan 2026 23:29:54 +0900

공부하면서 돈 번다? 인프런 '서바이벌 챌린지' 완벽 분석!

인프런 강의 추천, 인프런 강의를 찾고 있다면 서바이벌 챌린지를 참가해보세요!

인프런 챌린지

이 링크를 통해 구매하시면 제가 수익을 받을 수 있어요.

인프런 서바이벌 챌린지 참여 링크

성장과 상금은 누구의 것? 인프런 3주 '서바이벌' 챌린지 : All or Nothing! 챌린지 | 인프런 - 인프런

785명이 수강했던 챌린지, 지금 바로 살펴보세요.\n성장한 자들만이 살아남는다! 21일 도전으로 성공, 아니면 탈락!! 끝까지 살아남은 생존자들만이 누적 상금을 1/n로 거머쥐는 학습 '서바이벌' 챌

www.inflearn.com

성장과 상금, 두 마리 토끼를 잡는 인프런의 새로운 실험

'나의 성장'과 '확실한 수익' 두 마리 토끼를 모두 잡을 수 있는 역대급 챌린지를 소개해 드리려 합니다.

학습은 꾸준함이 핵심이지만, 꾸준함을 유지하기가 쉽지 않죠!

매번 새해에는 다짐을 하고 자기개발 계획을 세우는데 유지하는 것은 매번 실패하곤 합니다.

그런 고민에 답을 주기 위해 인프런(Inflearn) 이 또 한 번 도전을 준비했습니다.

바로, 3주간의 “서바이벌 챌린지: All or Nothing”.

이번 2월, 독하게 공부하고 상금까지 챙길 준비 되셨나요?

인프런 서바이벌 챌린지란?

‘인프런 서바이벌 챌린지’ 는 3주 동안 자신이 선택한 강의를 완주하고, 매일 꾸준히 학습 인증을 진행하는 도전형 프로그램입니다.
이번 테마는 “All or Nothing”, 즉 성공과 실패가 명확히 갈리는 챌린지입니다.

진행 기간: 총 3주
‍ 참가 대상: 인프런 회원 누구나
보상 구조: 완주자 전원 상금 지급 (도전 실패 시 상금 없음)
참여 링크: 인프런 서바이벌 챌린지 바로가기

100만 원 상금부터 구독권까지! 보상 요약

이번 챌린지는 끝까지 완주한 '생존자'에게 확실한 보상을 제공합니다.

우승 상금 1,000,000원: 최종 생존자들은 누적 상금 100만 원을 1/N로 나누어 가집니다.
열공러를 위한 추가 혜택: 끝까지 완주하지 못하더라도 열심히 참여했다면 혜택이 있습니다.
- 챌린지 MVP (1명): 인프런 구독권 6개월권 증정
- 우수 학습자 (10명): 3만 포인트 증정
참가자 전원 혜택: 26% 할인 쿠폰과 성취를 증명할 수 있는 수료증이 발급됩니다.

인프런 챌린지 우승상금 및 미션

마치며: 당신의 선택은?

이미지에서 보여주듯, 이 챌린지는 "성장과 상금"을 얻느냐, 아니면 "실패와 0원"으로 남느냐의 싸움입니다.

하루 딱 30분에서 1시간만 투자해서 나의 가치를 높이고 상금까지 챙길 수 있는 이번 기회를 놓치지 마세요!

지금 바로 인프런에서 도전할 강의를 골라보시는 건 어떨까요?

이 링크를 통해 구매하시면 제가 수익을 받을 수 있어요.

https://inf.run/om2FW

성장과 상금은 누구의 것? 인프런 3주 '서바이벌' 챌린지 : All or Nothing! 챌린지 | 인프런 - 인프런

www.inflearn.com

토익스피킹 IM2 시험 후기 - YBM 대전 CBT센터

가시가되어 — Tue, 20 Jan 2026 09:31:10 +0900

토익스피킹 IM2 시험 후기 - 대전 CBT센터 둔산동

YBM 대전CBT센터는 대전 지역에서 토익·토익스피킹/토익라이팅 등 CBT 기반 시험을 응시할 수 있는 공식 시험 센터입니다.
시험 공부는 기간은 여유로웠으나,, 미루고 미뤄 벼락치기 정리를 통해 외우고 갔습니다.
공부는 아래 템플릿 암기 및 유튜브 강의, 모의고사, 토스미 등을 활용

[벼락치기] 토익스피킹 파트별 템플릿, 만능문장 정리

[벼락치기] 토익스피킹 파트별 템플릿, 만능문장 정리유튜브 - 시계토끼 각 파트별 영상 보고 정리 및 템플릿 활용하여 구글 제미나이3과 같이 문법이나 문구 수정 등을 했어요.시계토끼 만능문

kora1492.tistory.com

토익스피킹 YBM대전CBT 센터 시험 후기 및 IM2 수준 정리입니다.

YBM 대전CBT센터 후기

위치 - 둔산동 갤러리아 맞은 편에 위치하고 있습니다.
자세한 위치는 네이버 지도를 참조

네이버지도

YBM대전CBT센터

map.naver.com

센터는 4층에 있습니다.
내부에는 대기실과 시험실이 준비되어 있었어요.
시험실은 A,B,C 3개가 있었습니다.

토익스피킹을 볼 수 있는 대전의 다른 센터들의 경우, 배제대/한남대 또는 KPC자격대전지역센터(대흥동)이 있습니다.
위치 접근성으로 보아, 대전 둔산동에 위치한 YBM 대전 CBT 센터가 인기가 많을 수 밖에 없네요.

시험일자가 얼마 안남을 때 접수를 하게 되면, 접수가 일찍 마감되오니 미리 접수를 해야 합니다.

시설은 다른 토익스피킹 시험장을 보지 않아 비교는 없습니다.
칸막이로 되어 있긴 하나, 박스형은 아니고 오픈된 칸막이입니다.
또한 옆 사람, 뒷 사람 간격이 넓진 않았습니다.

시설은 무난하고 큰 이슈는 없이 응시하였습니다.

시험장 A

토익스피킹 시험 후기

준비기간 : 일주일
오픽은 최근에 시험 본 결과 : IL

영어는 최근까지 학습하지 않음. (10년 이상)
학창시절엔 영어 등급은 4등급 수준입니다.
흔히들 말하는 영어 노베이스 수준이라고 보시면 될 것 같아요 ㅜㅜ

시험은 먼저 본인 인증 사진 촬영과 OMR 마킹을 합니다.
수능 이후로 이렇게 필적 감정까지 한 건 너무 오랜만이였네요.

그 다음 전자기기를 끈 다음, 이름표를 붙여서 수거함에 제출합니다.

기본적인 헤드셋의 음량과 마이크 녹음이 되는지 기기 이상을 확인합니다.
그렇게 기본적인 셋팅과 설문조사 등을 하면서 시험 시작하라는 감독관의 지시가 있기까지 대기를 합니다.

노트테이킹은 별도 필기구를 사용할 수 없으며, 센터에 준 컴퓨터용 싸인펜으로 노트해야합니다.
아래는 파트별 후기입니다.
IM2 수준은 대충 이렇구나라고 보시면 될 거 같아요.
제 체감으론 적당히 만능문장, 템플릿 외우고 그 문장들을 어느정도만 말해도 IM1~2는 쉽게 받으실 수 있을겁니다

노트테이킹 페이퍼

파트 1

시작하게 되면 처음 토익스피킹을 보신 분들은 놀라실거에요
주변 소음이 정말 장난 없습니다. 거기에 너무 웅얼웅얼 거리면 작거나 주변 소리가 더 잘들릴 수 있겠다라는 생각이 들정도입니다.
그러니 자신있게 또박또박 크게 말씀하세요(모두 그러고 있어서 누가 그러는지 알 수가 없습니다!)

파트1은 크게 어려운 점은 없었어요. 지문의 양도 유튜브에 있는 모의고사보다 짧아 시간이 여유로웠습니다
적당히 여유롭게, 상황에 맞춰서 읽어주었습니다. (사실 주변의 기세에 놀라 긴장하긴 했습니다)

파트2

파트2는 사진 묘사입니다.
첫번째 사진은 회의실/사무실 같은 공간에서 한명은 프리젠테이션에 무언가를 가리키고 있고 나머지 2명은 바라보고 있는 사진이였습니다.
두번째 사진은 계산하는 상황으로 잡지나 책, 서점에 2명이 있었습니다.

열심히 준비는 했지만 막상 시험때는 말하기가 힘들었네요. 노트테이킹도 했는데 말하다보면 버벅거리게 되더라구요.
장소 - 몇 명이 있다 - 사람들의 행동과 입고 있는 옷 정도 말하니 시간이 끝나버렸어요

파트3

정신없이 지나가는 파트3입니다.
대강 보고 의문사에 맞춰서 언제 / 빈도 등에 관한 답만 겨우 했습니다.
파트 3 마지막의 경우, 시계토끼 파트3 만능 문장을 하나 써서 이유를 답하고 마무리했네요.

파트4

여기선 듣기 능력이 중요합니다.
질문이 무엇인지 알아차리는 게 중요합니다.

스케쥴 / 일정표 문제가 나왔습니다.
시작은 첫 타임 시작이 언제인지 물어보는 기본 질문이였습니다.

그 다음은 정확히 무엇을 말하는 지 놓쳤어요..
점심 관련 내용만 들어서 No, I'm sorry. You have a wrong information. 점심 시간 관련 앞에 수업이 뭐가 있고 문제 없을 거다. 이런식으로만 했네요.

파트5

팀플레이의 장점 2가지 중에 하나를 골라서 세부적으로 말해보라는 거였습니다.
reducing Stress 를 골랐어요.

제가 정리한 스트레스 관련 템플릿을 활용해서 버벅거리면서 일단 말했네요.

실제론
I think 팀플레이의 장점은 reduce Streess
Most of all, it helps people relieve stress.
From my experience, when I played baseball, I felt good and it was so fun. As a result, my stress was reduced.
Also, according to news reports, a majority of people said that it is helpful for relieving stress.
Therefore I think 반복

마무리

시험을 다하고 나면 정상적으로 녹음이 되었는 지 2분 가량 들을 수 있어요.
창피하지만 제가 말한 내용들을 들어보며 잘 되었는지 점검해봤습니다.

시험결과는 토요일 시험의 경우, 다음 주 목요일 12시에 성적이 발표됩니다.
다행히 제가 원했던 건 IM2 정도였기때문에 재시험을 보지 않아도 되네요!!
답변 내용이나 제가 준비했던 것보다 못했는데 원하는 성적이여서 다행이였어요.
토스미 모의고사 결과랑도 크게 차이가 없었습니다. (2번 응시 - IM2, IM3)

오픽과 비교 했을 시, 대체로 토익스피킹이 점수가 더 잘 나오는 걸로 보입니다.
특히 저득점자일수록 토익스피킹을 추천드립니다.
영어 말하기 시험의 응시료가 8만원이 넘는 만큼 다들 준비를 하셔서 원하시는 성적을 받기를 바랍니다.

[벼락치기] 토익스피킹 파트별 템플릿, 만능문장 정리

가시가되어 — Fri, 9 Jan 2026 14:57:25 +0900

[벼락치기] 토익스피킹 파트별 템플릿, 만능문장 정리

유튜브 - 시계토끼 각 파트별 영상 보고 정리 및 템플릿 활용하여 구글 제미나이3과 같이 문법이나 문구 수정 등을 했어요.

시계토끼 만능문장 파트3는 무료로 제공됩니다.

시계토끼

www.rabbitlearn.com

시험보기 하루 전에는 토스미 무료 모의고사 1회 및 각 파트별 실전문제를 돌렸습니다.

파트1) Read a text aloud

주어진 문장/지문 읽기 / 자신있게, 최대한 억양/강세 등 유창해보이게 읽어보자.

1. 마침표(.), 물음표(?), 느낌표(!) 뒤

문장이 끝나면 1~1.5초 정도 확실히 쉬어주세요.

"나는 다음 문장을 읽을 준비가 되었다"는 인상을 주는 것이 중요

예시: Thank you for calling our office. (쉬고) We are closed right now.

2. 콤마(,) 뒤

문장 중간에 콤마가 있다면 숨을 살짝 고르세요. 마침표보다는 짧게, 약 0.5초 정도 쉬어갑니다.

예시: If you have any questions, (살짝 쉬고) please leave a message.

3. 나열 구조 (A, B, and C) ★가장 중요★

나열할 때는 단어 사이를 끊어 읽으면서 억양을 조절해야 합니다.

A(↗), B(↗), and C(↘)

예시: We serve coffee, (쉬고/올리고) tea, (쉬고/올리고) and dessert. (마무리/내리고)

4. 접속사(but, because, and, so) 앞

문장이 너무 길어질 때는 접속사 직전에서 끊어 읽으면 의미 전달이 더 잘 됩니다.

예시: I like this restaurant (쉬고) because the food is great.

5. 긴 주어 뒤 (주어 + 동사 사이)

주어가 3~4단어 이상으로 길어지면 주어 다음에 한 번 끊어주세요.

예시: The most popular tourist attraction in Seoul (쉬고) is N Seoul Tower.

파트2) 사진 묘사

생각보다 연습하면서 느낀 건 시간이 넉넉하지 않다

1) 장소 2) 사진 위치별로 상태 파악 3) 거기에 있는 사람 혹은 사물 묘사를 하면 대부분 끝이 난다.

1. 시작은 장소 묘사

예시: This Picture was taken at a Park / on a Street / 모르겠으면 Outdoor / Indoor

2. 사진 위치 별 (Left -> Middle -> Right)

예시: On the left side of the Picture ~ / In middle of the Picture / On right side of the Picture

3. 사람 묘사하기

인원

예시: "There are [Number] people in this picture."

특정 사람 입고 있는 옷(색상) is 행동

예시: A man wearing a blue shirt is looking at a monitor."

진짜 마지막 할 말 없을 때

Overall, It seems like busy / peaceful

파트3)

시계토끼 제니쌤의 의문사 만능 템플릿을 사용하자!

1. 의문사 만능패턴

When was the last time ~ 언제 가장 해본적이 있는지?

예시: The last time I was ~ + yesterday / two weeks ago / last year

How Often / frequently ~ 얼마나 자주 ~ 해봤나요?

예시: I ~ + almost Every day / twice a week / once in a while 와같은 빈도표현 쓰기

Where do usually buy / purchase ~

예시: I usually buy ~ on the internet / at a shopping mall

2. 의문사 만능 패턴이 아닐 때

What / do you ~ 가 있으면 주어는 나로 바꾸고 동사 그대로 읽고 최대한 답변하기

3. 문제의 7번

준비시간은 3초 밖에 되지 않은데 발화량은 많은 최악의 문제

답변구조는 템플릿대로 가보자

I think N (선택한 것) is most Important

First, 이유 1

Second 이유 2

이유가 죽어도 안떠오른다면 일단 좋다라고 해보자. (EX. The other day, ~ . I really liked. It was awesome)

파트4) 표를 보고 답변

표가 스크린에 띄워진 상태에서 전화가 와서 물어보는 형태의 문제

첫번째는 주로 일정/스케쥴이 언제인지를 물어본다.

두번째는 해당 일정/요금이 맞는지 등을 확인한다.

세번째는 여러 개 복수(몇 개의 세션이 있는지) 혹은 어떤 걸 듣고 싶은데 뭐가 있는지 확인한다.

1. 주제 is Will be held on 날짜 at 시간

2. No, I'm afraid that you have the wrong information, Actually ~

3. 중복이 겹치는 것들을 미리 찾아두고 There are [Number] sessions/events. First ~ , Next ~ , Finally ~ there is 일정, on 주제 by 사람

파트5)

대망의 파트5 11번 마지막 문제이다.

나오는 유형들은 정해져 있는 듯 하다 (디테일이 다를 수 있다.)

이것에 대해 동의/비동의를 질문하거나 주제에 대해 어떻게 생각하는지를 질문하고 답한다.

답변 시간이 1분이나 되기 때문에 부족한 어휘력을 최대한 채울 게 필요로 하다.

무엇이 됐든 공통 구조를 사용해본다.

일단 동의한다라는 식으로 하고, 이유가 여러 개 있다 혹은 이유말해줄게 브릿지로 사용

Most of all (무엇보다도), 이유 제시 / 근거는 내 경험에 의하면, 이렇게 하니 도움이 되었다. (it was very helpful for me)

Also 두번째 이유는 According to recent a news report, a majority of 사람 said that ~, prefre ~

마무리 Therefore 서론과 비슷하게 정리

1. 서론 (10초)

"I agree with the statement that [주제] is a good idea." (저는 [주제]가 좋은 생각이라는 점에 동의합니다.)
I have a few reasons / Let me explain why I think so.

2. 본론 1: 가장 큰 이유 + 내 경험 (30초) 메인

"Most of all, [이유 1: it is efficient / it relieves stress]." (무엇보다도, [이유 1]입니다.)

"From my experience, when I was a student (or working), I [과거 행동]. It was very helpful for me to [결과]." (제 경험상, 제가 학생/직장인 때 ~했습니다. 그것은 ~하는 데 큰 도움이 되었습니다.)

3. 본론 2: 뉴스/통계 근거 (15초) 서브

"Also, according to a recent news report, a majority of people prefer this way." (또한, 최근 뉴스 보도에 따르면, 대다수의 사람들이 이 방식을 선호한다고 합니다.)

(시간이 남으면 추가) "It said that it has a positive effect on [efficiency / health]." (뉴스에서 말하길 그것이 [효율성/건강]에 긍정적인 영향을 준다고 합니다.)

4. 결론 (5초)

"Therefore, I think this is a good idea." (그러므로, 저는 이것이 좋은 생각이라고 봅니다.)

유형별 정리

1. 직장 / 학교 (효율적 / 성공) 관련 의견 질문 - keypoint : efficent

I think ~ because it is more efficient
most of all, People can save time and energy.
From my experience, I ~ 했다. i can finished my project quickly So I can save time and energy.
Alos according to recent news report, a majority of people said that more efficient.
Therfore 서론

2. 스트레스, 건강, 여가 동의/비동의- keypoint : it helps people relive stress, makes the happy and helathy

i agree with the statement that ~ is important.
most of all, it helps people relive stress.
These day, people serve a lot of stress from work/school. So they need time to recharge their betteries.
Alos It makes the happy and helathy.
From my experience, When i did ~, I felt refresh and happy.
Therfore 서론

3. 인간관계, 소통 - keypoint : learn social skills

I agree with the statement that [주제] is important to learn social skills.
Most of all, it helps to understand each other better. .
From my experience, when I worked in a team, I talked with my teammates often. It was very helpful for me to learn social skills and finish the project successfully. .
Also, according to a recent news report, a majority of companies think that communication skills are the most important for success. .
Therfore 서론

4. 돈 / 기술 / 경제성 - keypoint : it is convenient and save money/time

주제 예시: 인터넷 쇼핑, 전자책, 대중교통 이용

핵심 논리: 돈/시간을 아낀다 / 편리하다

i agree with the statement that ~ is important.
most of all, it is convenient and save money/time.
From my experience, When i did ~, I could compare price / I more easier 했다. it was very helpful for me save the money/time.
Also, according to a recent news report, a majority of people use online shopping because of the reasonable prices.
Therfore 서론

5. 교육 - keypoint : it provides more opportunities

주제 예시: 새로운 언어 배우기, 코딩 배우기, 성인 교육의 중요성

핵심 논리: 새로운 기회를 얻는다 / 자기 만족

I agree with the statement that learning a new skill is important.

Most of all, it provides more opportunities.
From my experience, when I learned English, I could get a better job.
It was very helpful for me to build a successful career. (무엇보다도, 더 많은 기회를 제공합니다. 제 경험상, 영어를 배웠을 때 더 좋은 직장을 구할 수 있었습니다. 성공적인 커리어를 쌓는 데 큰 도움이 되었죠.)

Also, according to a recent news report, a majority of people think that learning is essential in the modern world.

Therfore 서론

6. 환경 - keypoint : it is good for enviroment / protect the environment

주제 예시: 일회용품 사용 금지, 대중교통 이용, 환경 교육

핵심 논리: 미래를 위해 중요하다 / 환경을 보호한다

I agree with the statement that we should use less plastic.

Most of all, it is good for enviroment.
From my experience, when I started using a multi-use cup, I could reduce waste every day. It was very helpful for me to protect the environment. (무엇보다도, 우리 미래 세대를 위한 일입니다. 제 경험상, 다회용 컵을 사용하기 시작했을 때 매일 쓰레기를 줄일 수 있었습니다. 환경을 보호하는 데 큰 도움이 되었죠.)

Also, according to a recent news report, a majority of people are interested in protect the enviroment these days.

Therefore, I think this is a good idea.

7. 리더쉽 / 팀워크(자질/성격) - keypoint : it helps to motivate the team members

주제 예시: 리더는 소통을 잘해야 한다 vs 결단력이 있어야 한다, 팀원 간의 조화

핵심 논리: 동기 부여를 한다 / 실수를 줄인다

I agree with the statement that communication is the most important for a leader.

Most of all, it helps to motivate the team members.
From my experience, when my manager talked with me often, I could work with high energy.
It was very helpful for our team to achieve the goal. (무엇보다도, 팀원들에게 동기를 부여하는 데 도움이 됩니다. 제 경험상, 매니저님이 저와 자주 대화했을 때 높은 에너지로 일할 수 있었습니다. 우리 팀이 목표를 달성하는 데 큰 도움이 되었죠.)

Also, according to a recent news report, a majority of companies look for good communicators when hiring leaders.

Therefore, I think this is a good idea.

입술 옆 따끔거리는 물집, 구순포진(헤르페스) 치료 가이드

가시가되어 — Thu, 8 Jan 2026 15:26:35 +0900

입술,구순 포진(헤르페스 1형) 완벽 가이드

'피곤하면 입가 주위에 물집이 생기는 증상' , 입술 주변이 간질간질하더니, 붉게 부풀어 오르는 포진이 생기는 경험을 하시는 경우가 있습니다. 한번 생기면 입술과 입술 옆 등에 포진(뾰루지 같은 것)이 여러 개 발생되게 되고 외관상으로 스트레스가 이만저만이 아닙니다.

입술 옆 포진이 생기는 현상, 입술 포진(헤르페스)가 생길 때 치료 가이드를 정리해보겠습니다.

1. 원인: 왜 자꾸 생길까?

정체: '헤르페스 심플렉스 바이러스 1형(HSV-1)' 감염.
특징: 한 번 감염되면 신경절에 평생 숨어 지냅니다. 그러다 면역력이 떨어질 때(과로, 스트레스, 강한 햇빛, 생리 등) 신경을 타고 입술 근육으로 내려와 물집을 만듭니다.
대략적으로 한국인의 70%에서 90%가 감염되어 있다고 추정, 주로 식기를 공유하거나 키스 등의 접촉으로 전염됩니다.

* 헤르페스 바이러스 1형 vs 2형

헤르페스 바이러스(Herpes Simplex Virus, HSV)는 크게 1형과 2형으로 나뉩니다.
일반적인 육안 진단으로는 구분이 어렵습니다.
주로1형은 입술 / 2형은 성기 부위에 증상이 발현되나, 교차감염도 가능합니다. 1형, 2형 모두 현대 의학으로는 신경절에서 완전히 제거하기가 힘들어, 완치불가입니다.

2. 진행 단계별 증상 및 대처법

보통 완치까지 7~10일 정도 소요됩니다.

구순포진은 보통 1~2주의 주기를 가집니다. 각 단계에 맞는 대처법이 회복 속도를 결정합니다.

단계	주요 증상	권장 대처법
1단계: 전조기	따끔거림, 화끈거림, 가려움 (물집 없음)	골든타임! 아시클로버 연고 즉시 도포
2단계: 수포기	붉게 부어오르며 작은 물집들이 군집을 이룸	병원 방문, 먹는 항바이러스제 복용 시작
3단계: 미란기	물집이 터지며 진물이 나고 궤양이 생김	전염성 최강. 환부 접촉 절대 금지 및 소독
4단계: 가열기	딱지가 생기며 회복되는 단계	억지로 딱지 떼지 않기, 보습 및 재생 관리

* 무증상 전염이 가능합니다: 물집이 눈에 보이지 않는 시기에도 바이러스는 배출될 수 있으니 주의

3. 치료제의 종류와 역할

먹는 항바이러스제 (메노바정 등): 바이러스 복제를 직접 차단. 가장 빠르고 효과적입니다.
항바이러스 연고 (아시클로버): 겉에서 바이러스 증식을 억제. 초기에 발라야 효과가 큽니다.
스테로이드 연고 (리도맥스 등) 는 일반 구순염일 경우에 효과적이며, 입술 포진 헤르페스 등에는 권장하지 않습니다.다만 붉게 오르는 부기나 염증이 과한 경우 미량을 섞어 쓸수도 있으나 추천드리진 않습니다.

4. 생활 속 주의사항 (전염 방지)

헤르페스는 전염성이 매우 강합니다.

수건/컵 분리: 가족들과 수건, 컵, 립밤 등을 절대 공유하지 마세요.
손 씻기: 환부를 만졌다면 즉시 손을 씻으세요. 바이러스가 눈으로 옮겨가면 '헤르페스 각막염'이라는 위험한 질환이 생길 수 있습니다.
스킨십 금지: 물집이 있고 딱지가 떨어지기 전까지는 뽀뽀나 키스는 절대 금물입니다.

5. 구순포진 환자를 위한 '입술 보호' 식단 가이드

헤르페스는 '무엇을 먹느냐'에 따라 회복 속도가 천차만별입니다. 특히 아미노산의 밸런스가 핵심입니다.

✅ 추천 음식: L-라이신(Lysine)이 풍부한 음식

라이신은 헤르페스 바이러스의 복제를 방해하는 고마운 성분입니다.

유제품: 우유, 치즈, 요거트
육류 및 생선: 소고기, 닭고기, 연어 (단백질은 피부 재생의 핵심입니다.)
콩류: 완두콩 (단, 일반적인 콩은 아르기닌도 높으니 적당히!)

❌ 피해야 할 음식: 아르기닌(Arginine)이 많은 음식

아르기닌은 바이러스의 '먹이'가 되어 증식을 돕습니다. 포진이 심할 때는 잠시 멀리하세요.

초콜릿 및 코코아
견과류 (아몬드, 땅콩, 호두 등)
젤라틴이 들어간 젤리류

6. 빨리 낫는 '꿀팁' (면역력 관리)

가장 중요한 건 충분한 수면과 휴식
이미 수포/포진이 발생된 상황이라면 아시클로버 계열의 연고로는 대처가 되지 않는 경우가 많으니 피부과 혹은 내과 진료 후 먹는 항 바이러스제를 처방 받는 게 좋습니다.
L-라이신(Lysine) 섭취: 바이러스 증식을 돕는 '아르기닌'을 억제하고 회복을 돕는 아미노산입니다. (영양제로 챙기면 좋음)
비타민 B군 & C: 피부 재생과 스트레스 완화에 필수적입니다.
자외선 차단: 강한 햇빛은 바이러스를 깨우는 원인이 됩니다. 회복기에는 외출 시 모자를 쓰거나 자외선 차단 기능이 있는 립밤을 바르세요.
바세린 등은 효과가 직접적으로 있는 건 아니지만 입술 옆이 트지 않도록 보습 관리를 해주는 게 치료에 도움이 됩니다.

7. 언제 다시 병원에 가야 하나요?

약 복용 3~5일 후에도 새로운 물집이 계속 생길 때
물집이 입 주변을 넘어 코나 볼, 눈 근처로 번질 때
고열이 나거나 턱 아래 림프절이 심하게 부을 때

자주 묻는 질문 (FAQ)

Q. 헤르페스는 완치가 안 되나요?
A. 현재 의학기술로는 체내 바이러스를 완전히 박멸할 수는 없습니다. 하지만 면역력 관리를 통해 평생 증상 없이 지내는 분들도 많습니다. 관리가 핵심입니다.

Q. 전염성이 얼마나 강한가요?
A. 물집이 있을 때는 수건 공유, 뽀뽀, 컵 같이 쓰기 등을 통해 아주 쉽게 전염됩니다. 특히 어린아이들에게는 치명적일 수 있으니 각별히 주의해야 합니다.

Q. 내과 vs 피부과, 어디로 가야 하나요?
A. 두 곳 모두 가능합니다! 피부 병변이 넓다면 피부과를, 전신 피로감과 몸살 기운이 동반된다면 내과를 추천합니다.

마지막 한마디:

헤르페스는 우리 몸이 보내는 "이제 좀 쉬어!"라는 가장 정직한 신호입니다.
초기 대응(항바이러스제)과 면역력 관리가 치료의 핵심입니다
처방받으신 약 잘 챙겨 드시고, 오늘 저녁은 누구보다 편안하고 게으르게 보내시길 바랍니다.

[CES 2026] 피지컬 AI란 무엇인가? 피지컬 AI의 시대 - 엔비디아 베라 루빈

가시가되어 — Wed, 7 Jan 2026 11:35:33 +0900

[CES 2026] 피지컬 AI의 시대가 왔다! 엔비디아 베라 루빈 (총정리)

지금 전 세계의 시선은 미국 라스베이거스로 향하고 있습니다. 바로 세계 최대 IT/가전 전시회인 CES 2026 때문인데요.

올해의 핵심 키워드는 작년까지 우리를 놀라게 했던 '생성형 AI'를 넘어, 실제 물리적 세계에서 움직이는 피지컬 AI(Physical AI)로 진화했습니다.

특히 인공지능의 심장이라 불리는 엔비디아(NVIDIA)가 선보인 차세대 아키텍처 '베라 루빈(Vera Rubin)'은 단순한 기술 발표를 넘어 새로운 산업 혁명의 시작을 알렸습니다.

1. 피지컬 AI(Physical AI): 왜 지금인가?

피지컬 AI란 무엇인가?

기존의 AI가 챗GPT처럼 화면 속에서 텍스트나 이미지를 만들어내는 '두뇌' 역할에 집중했다면, 피지컬 AI는 그 두뇌가 '몸'을 갖게 된 상태를 의미합니다. 로봇공학, 컴퓨터 비전, 그리고 고성능 연산 능력이 결합하여 현실 세계의 물리적 법칙을 이해하고 상호작용하는 지능입니다.

CES 2026에서 본 피지컬 AI의 양상

이번 CES 2026에서는 더 이상 실험실 수준의 로봇이 아닌, 우리 삶에 즉시 투입 가능한 수준의 기술들이 쏟아졌습니다.

가정용 휴머노이드: 설거지, 빨래 건조, 정원 관리를 스스로 판단해서 수행하는 로봇.
완전 자율주행의 진화: 단순 주행을 넘어 도로 위의 돌발 상황(낙하물, 보행자의 미세한 움직임)을 피지컬 AI가 실시간으로 예측합니다.
스마트 팩토리 2.0: 인간과 협업하는 코봇(Cobot)들이 베라 루빈급의 연산력을 바탕으로 오차 범위 0.01mm 이하의 정밀 작업을 수행합니다.

2. 엔비디아의 야심작: 베라 루빈(Vera Rubin) 심층 분석

젠슨 황 CEO가 기조연설에서 강조한 베라 루빈(Vera Rubin)은 2026년 하반기 양산을 앞둔 차세대 AI GPU 아키텍처입니다.

이는 단순한 하드웨어 업그레이드가 아니라, 피지컬 AI를 구현하기 위한 필수 인프라입니다.

️ 베라 루빈의 압도적 스펙

HBM4 최초 탑재: 초고대역폭 메모리의 6세대 버전인 HBM4를 탑재하여 데이터 처리 속도를 획기적으로 높였습니다.
물리 연산 전용 가속기: 현실 세계의 물리 법칙(중력, 마찰력, 유체 역학 등)을 실시간으로 시뮬레이션하는 기능을 강화했습니다.
전력 효율성: 이전 세대인 블랙웰(Blackwell) 대비 동일 전력 소모당 연산 성능이 개선될 것으로 기대됩니다.

왜 '베라 루빈'이 투자 포인트인가?

피지컬 AI가 제대로 작동하려면 초당 수조 번의 시뮬레이션을 돌려야 합니다.

로봇이 컵을 잡을 때, 그 컵의 무게와 재질을 순식간에 파악하고 적절한 힘을 가하는 모든 과정이 베라 루빈의 연산력 위에서 가능해지기 때문입니다. 이는 로봇 시대의 '표준 OS'와 '표준 CPU'를 엔비디아가 선점했음을 의미합니다.

3. 피지컬 AI 주요 기업별 핵심 트렌드

국내외 대기업들의 피지컬 AI 관련 전략을 분석합니다.

국내 기업: LG전자, 현대자동차그룹

LG전자: 당신에게 맞춘 혁신(Innovation in tune with you) 을 주제로 다양한 AI 가전을 비롯, '제로 레이버 홈(Zero Labor Home)' 을 실현하기 위한 클로이 로봇 제품군의 클로이드를 선보였습니다. 혼자서 아침 준비 및 빨래를 개는 등의 복잡한 집안일을 수행할 수 있습니다.
현대자동차그룹: 'AI 로보틱스 현실로 가져오다' , 현대자동차는 아틀라스를 단순한 전시용이 아닌 실제 제조 현장에 투입 계획을 세웠습니다. 미국 조지아주의 전기차 전용 공장인 현대차그룹 메타플랜트 아메리카(HMGMA)의 부품 분류 공정에 우선 투입될 예정입니다. 보스턴다이나믹스의 로봇 기술과 구글 딥마인드의 로봇 AI 파운데이션 모델 (제미나이)가 결합되어 '피지컬' 영역에 현대차 그룹의 역량을 선보였습니다.

글로벌 빅테크: 테슬라 & 아마존 & 구글

아마존: 물류 센터에 투입된 피지컬 AI 로봇 '디지트(Digit)'의 상용화 버전을 공개하며 물류 혁명을 예고했습니다.
테슬라: 인간형 로봇의 선두주자로, 옵티머스(Optimus) Gen 3 기술을 보유하여 상용화 준비 중입니다. 2026년 본격적인 양산을 목표로, 실제 공장 라인에 투입 가능한 수준의 숙련도를 보여주고 있습니다. 자율주행(FSD)에서 쌓은 시각 지능 데이터를 로봇에 그대로 이식할 것으로 기대하고 있습니다.
구글: RT-2 트랜스포머 기반 VLA(Vision-Language-Action) 모델, 대규모 로봇 모델을 통해, 로봇이 별도의 프로그래밍 없이도 새로운 명령을 이해하고 수행하게 만드는 '범용성'에 집중하며 AI에서 선도하며 피지컬 AI에서 '뇌' 역할을 맡을 것으로 생각됩니다.

. 결론: 피지컬 AI라는 거대한 파도에 올라타라

CES 2026은 우리에게 명확한 메시지를 던지고 있습니다. "AI는 이제 현실이 되었다"는 것입니다.

단순한 AI가 아닌 피지컬 AI 가 새로운 트렌드가 되어 주도할 것으로 생각됩니다.

엔비디아의 베라 루빈은 이 거대한 기계들의 심장이 될 것이며, 우리는 그 심장이 뛰는 방향에 돈의 흐름이 있음을 기억해야 합니다.

단순히 소비자로만 남을 것인가, 아니면 기술의 변화를 읽고 투자자와 수익자로 거듭날 것인가? 선택은 여러분의 몫입니다.

[SAP] AI가 주도하는 구매 프로세스 (MM)

가시가되어 — Tue, 6 Jan 2026 11:15:26 +0900

[SAP] T-Code의 시대는 끝났다? AI가 주도하는 '자율형 구매'의 미래

과거 SAP MM 모듈의 핵심이 '정확한 데이터 입력과 프로세스 준수'였다면,

S/4HANA와 생성형 AI가 결합된 지금은 '데이터 기반의 자율적 의사결정'으로 패러다임이 완전히 바뀌고 있습니다.

오늘은 SAP 차세대 구매 프로세스, AI 주도의 자율형 구매(Autonomous Procurement)에 대해 깊이 있게 다루어 보겠습니다.

1. Joule(줄): "노트북 10대 주문해 줘"로 끝나는 구매 경험

이제 더 이상 복잡한 구매 요청(PR) 화면에서 필드를 하나하나 채울 필요가 없습니다.

SAP의 생성형 AI 비서(AI Agent)인 Joule(줄)은 자연어를 이해합니다.

대화형 UI의 도입: "마케팅팀에서 사용할 노트북 10대가 필요해"라고 입력하면, Joule은 과거 구매 이력, 승인된 벤더 목록, 예산 한도를 즉시 확인하여 최적의 사양과 공급업체를 제안합니다.
지능형 요약: 수십 페이지에 달하는 공급업체 제안서나 계약서를 AI가 단 몇 줄로 요약해 줍니다. 승인권자는 AI가 분석한 '리스크 요인'과 '단가 변동폭'만 확인하고 승인 버튼을 누르면 됩니다.

참고) SAP AI Joule 코파일럿 제품소개

2. 예측적 소싱(Predictive Sourcing): 리스크를 미리 읽다

전통적인 구매는 문제가 터진 후(Reactive) 대응했습니다. 하지만 AI 기반 구매는 선제적(Proactive)입니다.

외부 데이터 실시간 연동: AI는 기상 이변, 지정학적 갈등, 물류 파업 소식을 실시간으로 모니터링합니다. 만약 대만 지역에 지진이 발생한다면, AI는 즉시 반도체 수급 리스크를 경고하고 동남아시아의 대체 공급처를 추천합니다.
가격 예측 모델: 원자재 가격 추이를 학습하여 "3개월 뒤 알루미늄 단가 상승률 85%"와 같은 예측치를 내놓습니다. 구매 담당자는 이를 바탕으로 가장 저렴한 시점에 선매수(Forward Buying) 전략을 세울 수 있습니다.

3. 자율적 정산: 3-Way 매칭의 완전 자동화

구매의 마지막 단계인 청구서 검증(IV)에서도 혁신이 일어납니다.

지능형 예외 처리: PO, 입고(GR), 청구서(IV)가 1원이라도 틀리면 블록(Block)이 걸리던 시대는 지났습니다. AI는 "이 벤더는 지난 5년간 단수 차이 발생률이 높았으며, 이번 오차는 단순 반올림 오류일 확률 99%"라고 판단하여 소액 차이는 스스로 조정하고 전표를 생성합니다.
부정 거래 탐지: 과거 패턴에서 벗어난 비정상적인 청구서나 이중 청구 가능성을 AI가 실시간으로 포착하여 재무 리스크를 방지합니다.

4. IT 담당자는 무엇을 준비해야 하는가?

AI가 구매 업무를 대신해 준다면 인간의 역할은 사라지는 걸까요?

그렇지 않습니다. 오히려 더 전략적인 역할이 요구됩니다.

데이터 품질 관리 (Data Hygiene): AI가 올바른 학습을 할 수 있도록 마스터 데이터(Material, Vendor)를 정교하게 관리하는 능력이 더욱 중요해집니다.
Clean Core 전략 준수: 표준 기능을 유지하면서 AI 기능을 BTP(Business Technology Platform)로 확장하는 기술적 안목이 필요합니다.
정책 설계자(Policy Designer): AI가 어떤 범위까지 자율적으로 결정할 것인지 '룰(Rule)'과 '윤리적 가이드라인'을 설계하는 것이 컨설턴트의 핵심 역량이 될 것입니다.

맺으며

SAP의 AI 전략은 멀리 있는 미래가 아닙니다. 이미 RISE with SAP를 통해 많은 기업이 Joule과 지능형 분석 기능을 도입하기 시작했습니다. 이제 우리는 "어떤 T-Code를 외울까"가 아니라 "AI와 어떻게 협업하여 가치를 만들까"를 고민해야 할 시점입니다.

[Python] 프로그래머스 큰 수 만들기

가시가되어 — Wed, 31 Dec 2025 14:12:10 +0900

[Python] 프로그래머스 큰 수 만들기

분류: 탐욕법(Greedy), Lv2

https://school.programmers.co.kr/learn/courses/30/lessons/42883

프로그래머스

SW개발자를 위한 평가, 교육의 Total Solution을 제공하는 개발자 성장을 위한 베이스캠프

programmers.co.kr

풀이 과정

파이썬으로 진행하였습니다.

1) 브루트 포스(Brute Force)

우선 가장 간단한 건, 모든 가능한 조합을 다 만들어보고 그중 가장 큰 수를 찾는 방식인 브루트 포스(Brute Force)로 만들 수도 있겠네요.

파이썬 라이브러리 중 itertools을 사용하면 순열(permutations) 이나 조합(combinations)를 쉽게 처리할 수 있습니다.

n-k개를 뽑는 조합을 모두 만들어봅니다.

from itertools import combinations

def solution(number, k):
    # n-k개를 뽑는 모든 조합 구하기
    n = len(number)
    comb = list(combinations(list(number), n - k))
    
    # 조합들을 문자열로 합쳐서 숫자로 변환 후 그 중에서 최댓값이 정답
    answer = max(["".join(c) for c in comb])
    return answer

위의 코드를 넣고 프로그래머스 테스트케이스에서 돌려보면 잘 동작하는 군요!

하지만 올바른 접근은 아닙니다. (일단 통과는 되었지만 ㅎㅎ)

조합의 경우, N이 클 때는 매우 비효율적입니다.

그렇다면 그리디(탐욕법) 하게 접근해봅시다!

2) 그리디

탐욕적으로 접근하는 방법입니다. 즉, 매 순간 최선의 선택을 해보는 것입니다.

가장 큰 수를 만들어야 하니 접근은 이렇습니다.

앞자리에 큰 숫자가 올수록 전체 수가 커진다라는 걸 이용해보는 것이죠(그리디 접근에서는 이러한 방식을 떠올리는 게 중요합니다.)

구현코드

1) Stack을 활용합니다.

2) 숫자(num)를 하나씩 확인하며, 스택의 마지막 숫자보다 지금 넣으려는 숫자가 더 크면 스택의 숫자를 제거(k가 남아있을 때까지)

3) 숫자(num)를 넣습니다.

파이썬에서는 별도로 Stack 자료형을 지정할 필요가 없이 리스트 자료형으로 Stack처럼 활용이 가능합니다.

stack[-1]로 리스트의 가장 마지막 값을 표현합니다.

append() 를 통해 리스트의 맨 뒤에 값을 넣고, pop()을 통해 리스트의 맨 뒤 값을 빼줍니다.

만약 k가 남아있는 경우, 아직 더 제거를 해야 하므로 리스트 슬라이싱을 해줍시다!

def solution(number, k):
    
    stack = []
    
    for num in number:
        
        while k>0 and stack and stack[-1] < num :
            # print("stack에서 빠지는 값", stack.pop())    
            k -= 1
            stack.pop()

        stack.append(num)    
        # print("stack 에 넣는 값", num)    

    if k > 0:
        stack = stack[:-k]
    
    return ''.join(stack)

앞서 조합을 생성하는 것 대비 훨씬 효율적으로 탐색하게 됩니다.

별개로 deque(데크, Double-Ended Queue)로도 stack을 표현할 수도 있겠네요.

[참고] Python itertools 라이브러리 공식문서

itertools — Functions creating iterators for efficient looping

This module implements a number of iterator building blocks inspired by constructs from APL, Haskell, and SML. Each has been recast in a form suitable for Python. The module standardizes a core set...

docs.python.org

[SCM] SCM에서 Pegging(페깅)이란?

가시가되어 — Tue, 30 Dec 2025 14:55:46 +0900

SCM에서 Pegging이란?

“이 주문은 어디서 나왔을까?”를 알려주는 연결 고리

SCM(공급망 관리)을 공부하거나 일을 하다 보면
Pegging(페깅) 이라는 단어를 한 번쯤은 꼭 만나게 됩니다.

처음 보면 이런 생각이 들죠.

“페깅… 고정? 묶는다는 뜻 같은데 도대체 뭐야?”

결론부터 말하면 Pegging은 아주 단순한 개념입니다.

Pegging을 한 문장으로 말하면

“이 주문(수요)을 충족하는 재고·생산·구매가 무엇인지 연결해서 보여주는 것”

조금 더 쉽게 말하면,

‘이게 왜, 누구 때문에 만들어졌는지 알려주는 기능’ 입니다.

빵집으로 예를 들어볼게요

당신이 빵집 사장이라고 가정해봅시다.

오늘 아침에 생긴 일

단골 고객이 식빵 10개 주문
매장에는 식빵 5개 재고
부족한 5개는 오늘 오후에 추가로 구워야 함

이때 머릿속에서 자연스럽게 이런 연결을 하게 됩니다.

고객 주문 10개
→ 매장 재고 5개 사용
→ 오늘 생산 5개 필요

이 ‘주문 ↔ 재고 ↔ 생산’의 연결 관계
바로 이걸 시스템적으로 관리하는 개념이 Pegging입니다.

SCM에서는 이렇게 쓰입니다

기업의 SCM에서는 이런 질문들이 계속 발생합니다.

이 고객 주문은 어떤 재고로 처리되는가?
부족한 수량은 어떤 생산오더에서 만들어지는가?
이 생산오더는 어느 주문을 위해서 만들어졌는가?

이 모든 질문의 답을 연결해주는 것이 Pegging입니다.

Pegging이 없으면 생기는 문제

Pegging이 없다면 이런 상황이 벌어질 수 있습니다.

❌ 주문 취소 → 어떤 생산을 멈춰야 할지 모름
❌ 재고는 있는데 왜 다시 생산했는지 알 수 없음
❌ 납기 지연 → 어디서 막혔는지 추적 불가

즉,

공급망이 ‘보이질 않게’ 됩니다.

✅ Pegging이 있으면 좋은 점

1️⃣ 영향도 분석이 쉬워짐

주문 변경/취소 시
영향을 받는 생산·구매 계획을 바로 확인

2️⃣ 불필요한 생산·구매 방지

“이거 누구 주문이야?”가 명확
재고 과잉 감소

3️⃣ 납기 약속이 정확해짐

실제로 연결 가능한 공급 기준으로
고객에게 현실적인 납기 안내 가능

Pegging은 방향도 있다

Pegging은 연결 방향에 따라 이렇게 나뉩니다.

Forward Pegging
→ 이 주문은 어떤 재고/생산으로 충당되나?
Backward Pegging
→ 이 생산은 어떤 주문을 위해 만들어졌나?

실무에서는 보통 양방향 모두를 봅니다.

한 줄로 다시 정리하면

Pegging은 “수요와 공급이 왜 연결됐는지 보여주는 지도”이다.

SCM에서 Pegging을 이해하면

MRP
생산계획
재고관리
납기 관리

이 모든 개념이 한 번에 정리되기 시작합니다.

마무리

SCM은 복잡해 보이지만,
결국 핵심 질문은 하나입니다.

“이건 왜 만들어졌지?”

그 질문에 답해주는 개념,
그게 바로 Pegging입니다.

[MM] MIRO 분할 송장 처리 방법 (여러 코스트센터)

가시가되어 — Mon, 29 Dec 2025 10:53:54 +0900

MIRO 송장 처리 시 코스트센터(Cost Center) 다중 배부 및 분할 가이드

SAP에서 하나의 송장 금액을 여러 부서(코스트센터)로 나누어 처리하는 방법입니다.

원자재 구매부터 일반 경비 처리까지, 상황별로 코스트센터 분할 송장 처리 방법 정리.

1. 구매오더(PO) 단계에서 미리 나누기 (MIRO 연동)

구매 시점에 이미 비용을 부담할 부서와 비율이 정해져 있다면, PO 단계에서 '다중 계정 지정' 기능을 사용하는 것이 가장 깔끔합니다.

T-Code: ME21N (PO 생성) 또는 ME22N (PO 변경)
방법:
1. 품목 행의 계정 지정 범주(A)를 'K'(코스트센터)로 설정합니다.
2. 하단 상세 탭의 [계정 지정] 탭으로 이동합니다.
3. '다중 계정 지정(Multiple Account Assignment)' 아이콘을 클릭합니다.
4. 배부 방식(수량 또는 퍼센트)을 선택하고, 각 코스트센터별로 값을 입력합니다.
장점: 송장 처리(MIRO) 시 PO 번호만 불러오면 분할된 정보가 자동으로 반영되어 편리합니다.
주의: 원자재의 경우 재고 자산이 아닌 '입고 즉시 비용 처리' 방식으로 흘러갈 수 있으므로 회계 정책을 확인하세요.

2. 일반 전표 입력 시 직접 나누기 (FB60)

구매오더 없이 들어온 세금계산서나 일반 경비를 처리할 때는 전표의 라인 아이템을 쪼개는 방식을 사용합니다.

T-Code: FB60 (공급업체 송장 전기)
방법:
1. 대변(Vendor): 공급업체 정보와 송장 전체 금액을 입력합니다.
2. 차변(G/L 계정): 하단 리스트에 비용 계정을 입력할 때, 코스트센터 개수만큼 행을 나눕니다.
3. 각 행마다 해당되는 금액과 코스트센터를 각각 입력합니다.
팁: 금액 계산이 복잡하다면 엑셀에서 미리 계산 후 복사/붙여넣기를 활용하면 오타를 줄일 수 있습니다.

3. 코스트센터가 너무 많다면? CO '월말 자동 배부' 활용

배부해야 할 코스트센터가 10개, 20개가 넘어간다면 매번 전표를 쪼개는 것은 비효율적입니다. 이럴 땐 CO(관리회계) 모듈의 배부 로직을 활용하세요.

전표 처리: 일단 '공통 부서' 또는 '임시 코스트센터' 하나로 전액 전표를 생성합니다.
배부 규칙 설정: KSV1(분배) 또는 KSU1(배부)에서 인원수, 면적, 매출액 등 기준에 따른 배부 규칙(Cycle)을 만듭니다.
월말 실행: 결산 시 KSV5 또는 KSU5를 실행하면 시스템이 알아서 비용을 각 부서로 뿌려줍니다.

요약 및 결론

PO 기반 구매 시: ME21N에서 다중 계정 지정 활용
단순 경비 처리 시: FB60에서 라인 아이템 분할 입력
부서가 너무 많거나 기준이 복잡할 때: 일단 공통 처리 후 월말 결산 배부

Multiple Account Assignment in SAP Purchase Order 이 영상은 구매오더에서 여러 부서(코스트센터)로 수량과 비용을 분할하여 입력하는 구체적인 화면 조작법을 담고 있어 이해에 도움이 될 것입니다.

[앱테크] 허니게인 수익 JumpTask로 현금화 찐 후기

가시가되어 — Wed, 17 Dec 2025 09:00:42 +0900

허니게인 수익 JumpTask로 현금화 찐 후기 및 실제 출금 인증 & 수수료 비교(PayPal Vs JumpTask)

허니게인(Honeygain)로 정말 돈이 될까? 라는 궁금증이 있었습니다.
결론부터 말하면 시간은 걸리지만 실제 출금은 된다입니다. 사기가 아니였네요 ㅎㅎ

드디어 허니게인 수익을 JumpTask(JMPT 코인)로 출금 → 현금화까지 완료했습니다.
오랜 기간 방치하며 사용한 결과, 누적 수익 100달러 이상을 달성했고 실제로 원화 출금까지 마무리했습니다.

처음 하는 분도 따라 할 수 있게 상세히 다음과 같이 정리했습니다.

허니게인 수익 현실
PayPal vs JumpTask 출금 비교
JumpTask(JMPT) 출금 방법
국내 거래소 현금화 과정

허니게인 수익 현실｜과연 얼마 벌 수 있을까?

허니게인은 흔히 말하는 패시브 인컴(Passive Income) 앱입니다.
즉, 별도의 노동 없이 인터넷을 켜두는 것만으로 소소한 수익을 쌓는 구조입니다.

✔️ 단기간 고수익 ❌
✔️ 장기간 방치형 수익 ⭕
✔️ 여러 기기·IP 활용 시 효율 상승 ⭕

하루에 몇 천 원을 버는 앱은 아니지만, 아무것도 안 하고 모은 달러를 실제로 출금할 수 있다는 점이 핵심입니다.

허니게인 출금 방법 비교｜PayPal vs JumpTask 뭐가 좋을까?

허니게인 출금 방식은 크게 두 가지입니다.

1️⃣ PayPal(페이팔) 출금

장점: 간편함
단점: 수수료 최대 약 15% 발생

2️⃣ JumpTask(JMPT 코인) 출금

장점: 수수료 최소화, 실제 수령액 ↑
단점: 가상자산 지갑 필요

JumpTask 출금이 체감상 훨씬 유리합니다. 단점은 가상자산에 익숙치 않은 분들은 과정이 복잡할 수 있습니다.

소액 출금보다는 금액을 모아서 한 번에 출금하는 전략이 좋습니다. 이유는 페이팔은 출금에 수수료 %가 붙게되고, 최소 20$ 이상 적립을 해야 합니다. 반대로 점프테스크를 이용한 출금에도 스왑 및 전송 시 수수료가 발생됩니다.

허니게인 사용법 & 수익 구조 (이전 글 참고)

허니게인 설치 방법, 추천인 코드, 실제 사용 후기 등이 궁금하다면 아래 기존 글을 먼저 확인해보시는 걸 추천드립니다.

패시브인컴 허니게인(Honeygain) 솔직 리뷰

[앱테크] 패시브인컴 허니게인(Honeygain) - 솔직리뷰, 사용방법 및 수익

허니게인 솔릭리뷰 * 패시브 인컴(Passive Income)이란 우리나라 말로는 불로소득 또는 최소한의 노동으로 벌어들이는 소득활동이라고 보면 된다. 허니게인이란? 방치형으로 본인이 사용하는 네트

kora1492.tistory.com

회원가입은 해당 링크 https://join.honeygain.com/KORA446BF1

허니게인 JumpTask 출금 방법 한눈에 요약 (바쁜 분 필독)

시간이 금인 분들을 위해 전체 절차를 간략히 요약합니다.

1️⃣ 트러스트월렛(Trust Wallet) 설치 및 가입
2️⃣ BNB Smart Chain & JMPT 지갑 생성
3️⃣ 허니게인에서 JumpTask 출금(Payout) 요청
4️⃣ 이메일 6자리 인증 코드 입력
5️⃣ 트러스트월렛에서 JMPT 입금 확인
6️⃣ JMPT → BNB 코인으로 스왑
7️⃣ 빗썸 전송 → 판매 → 원화 출금 완료

초기 세팅 및 사전준비가 번거로울 수 있습니다. 한번 숙지해두시면 그 다음부터는 어려울 것 없어요

1️⃣ 트러스트월렛 설치 방법 (JumpTask 필수)

JumpTask 출금을 위해서는 개인 가상자산 지갑이 필요합니다.

메타마스크 또는 트러스트월렛 2가지가 있는데 조금 더 편리하다고 생각하는 트러스트월렛 방법으로 진행해보겠습니다.

Play스토어 기준

앱스토어 / 플레이스토어 → Trust Wallet 검색
신규 지갑 생성
복구 문구(Seed Phrase) 반드시 안전하게 보관

2️⃣ BNB Smart Chain & JMPT 지갑 추가하기

JumpTask(JMPT)는 BNB Smart Chain(BEP-20) 기반 토큰입니다.

트러스트월렛의 메인 지갑에서 자금 버튼을 누릅니다.

지갑에 자금 입금에서 맨 하단 Crypto Wallet을 누릅니다.

수령 화면에서 네트워크 JMPT BNB Smart Chain 을 선택합니다.

참고) How to import JMPT token to your wallet (Metamask/Trust wallet)

3️⃣ 허니게인 JumpTask 출금 요청방법

허니게인 앱 또는 웹에서 다음 순서로 진행합니다.

허니게인 대시보드 화면 내 20$ 달러 이상 충족했다면, Request PayOut 버튼이 활성화됩니다.

Payout 메뉴 접속
JumpTask 선택
트러스트월렛의 JMPT 지갑 주소 입력

4️⃣ 허니게인 이메일 인증 (보안 필수)

출금 요청 후, 가입 시 사용한 이메일로 6자리 인증 코드(Verification code)가 발송됩니다.

코드 입력 → 출금 확정

보안상 반드시 거치는 단계입니다. 최대 2영업일의 시간이 소요된다고 합니다.

최종 전송완료 화면

5️⃣ JMPT 입금 확인

트러스트월렛에서 JMPT 입금 확인이 가능합니다.

위에서 2 영업일이 소요된다고 하였으나, 저의 경우 수 분 내로 확인이 가능했습니다.

6️⃣ JMPT → BNB 스왑 방법

국내 거래소에서는 JMPT 직접 입금이 어렵기 때문에, BNB 코인으로 스왑합니다.

트러스트월렛 Swap 기능 사용
전환 자산 JMPT → 수령 자산 BNB

⚠️ 소량의 BNB 스왑비용 발생

7️⃣ 빗썸으로 전송 후 원화 출금하기

마지막 단계입니다.

트러스트월렛의 메인 지갑에서 전송 기능을 사용합니다.

트러스트월렛 → 빗썸 BNB 지갑 주소로 전송

빗썸 입금 확인
BNB 매도 → 원화 전환
본인 인증 계좌로 출금

허니게인 수익 현금화 완료

허니게인 JumpTask 출금 후기 요약 (핵심 정리)

✔️ 허니게인은 실제 출금 가능한 앱테크
✔️ 단기간 수익 ❌ / 장기 방치형 ⭕
✔️ PayPal보다 JumpTask 출금이 수수료 면에서 유리

인터넷을 어차피 켜두고 있다면, 안 할 이유는 없는 앱테크입니다.

이런 분들께 허니게인을 추천합니다

집·사무실 PC를 장시간 켜두는 분
서브폰, 태블릿 활용 가능한 분
큰 노력 없이 달러 수익을 모아보고 싶은 분

[앱테크 추천] MyB 마이비 초대코드 및 수익 현실 후기

가시가되어 — Tue, 16 Dec 2025 08:19:02 +0900

[앱테크 추천] MyB 마이비 초대코드 및 수익 현실 후기

요즘 출퇴근 시간이나 잠깐의 자투리 시간에 소소하게 용돈 벌이를 할 수 있는 앱테크에 관심 있는 분들이 많으실 텐데요.
오늘 소개할 앱은 퀴즈형 앱테크 + 코인 연계 적립이 가능한 MyB(마이비) 입니다.

단순 출석체크 위주의 앱테크가 아니라,
퀴즈 · 설문 · 게임 · 미션 · 무한적립까지 구조가 다양해서
지루하지 않게 꾸준히 할 수 있다는 점이 가장 큰 장점입니다.

초대코드 : UY381104KM

오늘의 앱테크 후기 – MyB 마이비

MyB 마이비는 퀴즈형 앱테크로,
하루 퀴즈를 풀어서 적립하는 방식이 기본이며
이외에도 일반적인 앱테크에서 제공하는

게임 미션
출석체크
설문조사
간단 미션(구독/팔로우 등)

까지 모두 한 번에 이용할 수 있는 종합 앱테크 플랫폼입니다.

특히 적립한 마이비 포인트를
XPLA 코인으로 교환 가능하다는 점이 차별화 포인트입니다.
XPLA 코인은주요 글로벌 거래소(예: 크립토닷컴, HTX, Gate.io)와 국내 거래소(빗썸, 코빗, 고팍스 등)에도 상장되어 있어
단순 포인트가 아닌 실제 자산화가 가능합니다.

마이비 상품

마이비 앱테크 수익현황 , 현실

마이비를 사용한지 1~2주 정도 밖에 이용하진 않았으나 현재까지 적립한 현실입니다.
초간단 및 설문조사를 통한 수익과 퀴즈를 통한 수익이 생각보다 짭짤하네요.
퀴즈를 통해 간단하게 적립이 가능한 점이 강점입니다. 현재는 나중에 설명을 드릴테지만 적금이라는 기능으로 3개월동안 예치를 해둔 상황입니다.

마이비 적립내역

마이비 앱테크 수익구조 (상세 정리)

1. 퀴즈 적립 (핵심 기능)

‘꿀’을 소모하여 퀴즈를 풀면 마이비 포인트를 즉시 적립하는 구조입니다.

마이비 퀴즈적립

퀴즈 난이도는 높지 않음
하루 루틴으로 하기 좋음
광고 시청을 통해 꿀 하루 3회 무료 충전 가능

앱테크 초보자도 부담 없이 시작 가능한 콘텐츠입니다.

2. 설문조사 적립

설문조사(리서치)를 완료하면 포인트를 적립하는 방식으로, 상대적으로 짧은 시간 대비 적립 효율이 좋은 편입니다.

참여 조건만 맞으면 바로 가능
소요 시간 대비 보상 괜찮음
꾸준히 체크하면 쏠쏠함

3. 게임 적립

게임 다운로드 후 멀티 미션 또는 특정 목표를 달성하면 포인트를 적립합니다.

게임 즐기면서 적립 가능
시간 여유 있는 분들에게 추천

멀티 미션에 따라, 적립 금액이 차이가 큽니다. 적당한 미션 수행을 추천드립니다.

4. 초간단 적립 (가장 쉬운 유형)

인스타그램 팔로우
카카오톡 플친 추가
유튜브 구독
네이버 뉴스 구독
앱 최초 설치

클릭 몇 번 + 인증만으로 적립되는 형태입니다.
바쁜 날에도 “이건 꼭 하고 지나간다” 싶은 미션입니다.

5. 무한적립

플레이스 저장 / 퀴즈 / 찜하기 등 아주 다양한 미션을 수행하면 포인트를 적립할 수 있습니다.

캠페인 수가 매우 많음
시간 투자 대비 누적 적립 가능
“몰아서 하기”에 최적화

앱테크에 어느 정도 익숙해진 분들께 추천, 적립 가이드를 유심히 잘 보고 수행해야 합니다. (선착순 등은 마감될 수 있습니다.)

추가 혜택 및 시스템

✔ 멤버십 등급 시스템

위 미션들을 통해 월간 도전과제를 달성하면 멤버십 등급이 상승합니다.

등급이 오르면

꿀 광고 제거
퀴즈 참여 횟수 증가
전반적인 적립 효율 상승

장기 이용자에게 유리한 구조입니다.

마이비 멤버쉽 - 패밀리

✔ 적금 시스템 (원금 보장)

마이비 포인트를 일정 기간 예치하는 방식으로, 원금은 보장되며 XPLA 코인 시세가 상승할 경우

그 상승분만큼의 차익을 얻을 수 있습니다.

단순 포인트 적립을 넘어서
코인 시세 상승까지 노릴 수 있는 구조

마이비포인트 적금

마이비 현실 후기 한줄 정리

✔ 단순 출석 앱테크보다 확실히 할 게 많다
✔ 포인트 → 코인 전환이 가능해 확장성 있음
✔ 소액이지만 꾸준히 하면 체감 수익 발생
✔ 앱테크 + 코인에 관심 있다면 한 번쯤은 추천

친구 초대 이벤트, 시즌별 추가 보상도 자주 열리니
관심 있으신 분들은 지금 바로 MyB 마이비를 앱스토어 / Play 스토어에서 다운로드해보세요
초대코드 : UY381104KM

파이썬 코딩테스트 입문 문법 정리 (초보자용)

가시가되어 — Mon, 15 Dec 2025 11:49:44 +0900

파이썬 코딩테스트 입문 문법 정리 (초보자용)

이 문서는 파이썬을 처음 접하거나 코딩테스트를 처음 준비하는 분을 위해 작성되었습니다.

파이썬의 경우, 간단한 문법과 간결한 코드 등으로 비전공자 및 새로 프로그래밍을 배우는 분들께 적합한 언어로 널리 알려져 있습니다. 코딩테스트에서는 실행속도가 느리다는 단점이 있으나, CP(competitive Programming)과 같이 대회 코딩테스트를 준비하시는 게 아닌 단순히 기업의 코딩테스트를 통과하기엔 큰 문제점은 없습니다.

특히 문자열 슬라이싱이나 Big Integer 등에서 강점 또한 갖고 있으며 다양한 수학 관련 라이브러리 등 파이썬의 장점 또한 존재합니다.

1️⃣ 변수 & 기본 자료형

a = 10
b = 3.14
c = "hello"
d = True

설명

파이썬은 변수 선언 시 타입을 명시하지 않습니다 (자바, C와 같은 컴파일 언어와는 다른점)
동적 타이핑, 변수에 타입이 붙는 게 아니라, 값에 타입이 붙는다
값이 들어가는 순간 타입이 자동으로 결정됩니다

타입	설명	예시
int	정수	10, -3
float	실수	3.14
str	문자열	"abc"
bool	참/거짓	True, False

2️⃣ 입력 / 출력 (코딩테스트 필수)

n = int(input())
a, b = map(int, input().split())

설명

input()은 항상 문자열(str) 로 입력을 받음
숫자로 사용하려면 반드시 int() 또는 float()로 변환

print(a, b)

print()는 자동 줄바꿈

3️⃣ 조건문 (if / elif / else)

if x > 10:
    print("big")
elif x == 10:
    print("same")
else:
    print("small")

설명

: 뒤에는 반드시 들여쓰기 필요
조건식 결과는 True / False

if 1 < x < 10:
    print("range")

파이썬만 가능한 연속 비교 문법

4️⃣ 반복문 (for / while)

for문

for i in range(5):
    print(i)

range(5) → 0 ~ 4

range(start, end, step)

range(시작값, 끝값, 감소값) - 감소값에 -1를 넣어서 역순으로 돌릴 수도 있음

while문

while n > 0:
    n -= 1

조건이 True인 동안 반복
종료 조건 반드시 필요 (무한루프 주의)

5️⃣ 리스트 (List)

lst = [1, 2, 3]
lst.append(4)

설명

순서 O, 중복 O
인덱스는 0부터 시작

lst[0]  # 첫 번째 값
len(lst)

6️⃣ 리스트 슬라이싱 ⭐⭐⭐

lst[start:end:step]

lst = [1,2,3,4,5]
lst[1:4]   # [2,3,4]
lst[::2]   # [1,3,5]
lst[::-1]  # 역순

설명

end는 포함되지 않음
코딩테스트에서 자주 응용이 가능함
슬라이싱 개념에 대해서 제대로 배워두는 게 중요함

7️⃣ 문자열 (str)

s = "hello"
s[0]   # 'h'
s[-1]  # 'o'

설명

문자열도 리스트처럼 인덱스 사용 가능
하지만 수정 불가 (immutable)

8️⃣ 문자열 ↔ 숫자 변환

str(123)     # "123"
int("123")   # 123

[int(x) for x in "123"]

9️⃣ 리스트 컴프리헨션 ⭐⭐⭐

[x * 2 for x in range(5)]

설명

for문 + append를 한 줄로 표현
가독성, 성능 모두 우수

자주 쓰는 내장 함수

len(lst)
sum(lst)
max(lst)
min(lst)
sorted(lst)

1️⃣1️⃣ 함수 (def)

def solution(n):
    return n * 2

설명

주로 코딩테스트에서는 print ❌ return ⭕ 을 사용하는 경우가 많다.

1️⃣2️⃣ enumerate

for i, v in enumerate(['a','b','c']):
    print(i, v)

인덱스와 값을 동시에 얻을 때 사용

1️⃣3️⃣ 역순 처리

lst[::-1]
reversed(lst)

1️⃣4️⃣ set (중복 제거)

set([1,1,2,3])

1️⃣5️⃣ 딕셔너리 (dict)

d = {"a":1, "b":2}
d["a"]

key-value 구조

파이썬 입문자 최종 기초문법 정리

슬라이싱 이해 = 절반 성공
문자열과 리스트 자유자재로 다루기
리스트 컴프리헨션 적극 사용

아파치(Apache)와 톰캣(Tomcat)의 차이, 구성 방식

가시가되어 — Wed, 10 Dec 2025 11:27:17 +0900

아파치(Apache)와 톰캣(Tomcat)의 차이, 구성 방식, 그리고 실제 운영 구조 완전 정리

웹 서버를 구축할 때 가장 많이 언급되는 기술이 바로 Apache HTTP Server(아파치)와 Apache Tomcat(톰캣)입니다.

두 이름이 비슷해서 종종 같은 기술이라고 오해하거나, "톰캣이 아파치를 포함하고 있다"라고 잘못 이해하는 경우가 많습니다.
하지만 두 서버는 목적과 특징이 분명히 다르며, 운영 방식도 각각 차이가 있습니다.

운영 서버에서도 Apache 없이 Tomcat만으로 80포트를 직접 열어 운영하는 사례가 있습니다.
이 글에서는 그 이유와 개념을 한 번에 명확히 정리해보겠습니다.

1. 아파치(Apache HTTP Server)란?

Apache HTTP Server는 세계에서 가장 널리 사용되는 정적 웹 서버(HTTP 서버)입니다.

"아파치 HTTP 서버는 아파치 소프트웨어 재단에서 관리하는 오픈 소스, 크로스 플랫폼 HTTP 웹 서버 소프트웨어"

- WIKI에서는 위와 같이 정의하고 있습니다.

✔ 주요 역할

정적 파일 제공 (HTML, CSS, JS, 이미지 등)
Reverse Proxy / Load Balancer 역할
SSL/TLS 처리 (HTTPS)
URL Rewrite, 가상 호스트, 인증 기능 제공

✔ 특징

빠른 정적 파일 처리 능력
안정성과 확장성이 뛰어남
다양한 모듈(mod_rewrite, mod_ssl, mod_proxy 등) 제공
Apache 환경에서는 백그라운드에서 실행되고 이러한 요청을 용이하게 하는 프로그램을 '데몬'이라고 하며 httpd(Hypertext Transfer Protocol daemon)를 사용

✔ 그래서 어디에 쓰나?

웹의 첫 관문 역할을 하는 서버.
정적 파일 처리능력이 뛰어나며, 대규모 트래픽을 안정적으로 처리하는 데 특화되어 있음.

2. 톰캣(Apache Tomcat)란?

Tomcat은 Java 기반 웹 애플리케이션 서버(WAS)이며,
서블릿/JSP와 같은 동적 웹을 처리하는 데 최적화된 서버입니다.

✔ 주요 역할

Java Servlet, JSP 실행
WAS(Web Application Server) 기능
WAR 배포 및 Java Web 실행 환경 제공

✔ 특징

웹서버 기능도 내장(HTTP Connector)
Java 애플리케이션 실행 중심
동적 요청 처리에 뛰어남

✔ 즉,

Tomcat은 Java 웹 애플리케이션을 실행해주는 엔진이라고 보면 됩니다.

3. 아파치와 톰캣은 무엇이 다른가?

구분	Apache	Tomcat
역할	웹 서버(HTTP Server)	WAS(Java Web Application Server)
강점	정적 파일 처리	동적 Java 웹 처리
포트	보통 80, 443	보통 8080
처리	이미지, HTML, JS	Servlet/JSP, Java Web
구조	모듈 기반 확장	Java 컨테이너 기반

결론

Apache는 정적 웹 서버
Tomcat은 Java 웹을 위한 WAS

둘은 서로 대체 불가한 역할을 가지지만, 환경에 따라 둘 중 하나만 운영할 수도 있습니다.

4. Tomcat이 Apache 없이 단독으로 운영될 수 있는 이유

Tomcat에는 HTTP 서버 기능(Connector)가 기본 내장되어 있습니다.

Tomcat의 server.xml에 다음과 같은 설정이 있다면:

HTTP/HTTPS Connector : <Connector port="80" protocol="HTTP/1.1" />

Tomcat 자체가 웹 서버처럼 80/443 포트를 직접 Listen하고 브라우저 요청을 받아 처리할 수 있습니다.

✔ 그래서 가능한 것

Apache 없이 Tomcat 단독 구성 가능
80포트에서 Java 프로세스로 구동 중

✔ 그러나 주의할 점

Tomcat은 정적 파일 처리 성능이 Apache보다 떨어질 수 있어
대규모 트래픽 환경이나 복잡한 프록싱 구조에서는 Apache를 앞단에 두는 것이 일반적임.

5. Apache + Tomcat 연동 구조

많은 기업 환경에서 사용하는 방식.

[Client] → Apache(httpd) → Tomcat(Java)

✔ 장점

정적 파일은 Apache가 빠르게 처리
동적 요청만 Tomcat으로 전달하여 부하 감소
SSL 종료를 Apache에서 수행 가능
확장성과 보안성이 높음

✔ 연동 방식

mod_jk
mod_proxy / mod_proxy_ajp
Reverse Proxy 방식

✔ 언제 추천?

트래픽이 많은 서비스
이미지/정적 리소스가 많은 서비스
보안 정책에서 Front Web Server 요구 시

6. Tomcat 단독 운영 구조

[Client] → Tomcat(Java)

✔ 장점

구성 단순
Apache 설치/운영 필요 없음
개발/테스트 환경에 적합
인프라 스케일아웃 시 컨테이너 환경과도 잘 맞음(Docker, K8s 등)

✔ 단점

정적 파일 처리 속도 Apache보다 떨어짐
SSL 처리 시 CPU 부하 증가
고성능이 필요한 대규모 서비스에는 다소 비효율

✨ 최종 정리

Apache = 정적 웹 서버
Tomcat = Java 웹 애플리케이션 서버(WAS)
서로 목적이 다르기 때문에 “Tomcat이 Apache를 포함한다”는 개념은 잘못된 이해
하지만 Tomcat이 HTTP 기능을 내장하고 있어 단독으로 80/443 포트를 사용할 수 있음
기업 환경에서는 Apache + Tomcat 연동이 흔하지만 요즘은 Tomcat 단독 운영도 종종 사용됨

같이 보면 좋은 글 및 참조 사이트

IBM - Apache 서버란 무엇인가요?

Apache 서버란 무엇인가요? | IBM

일반적으로 Apache 또는 간단히 Apache 서버라고도 하는 Apache HTTP Server는 수많은 웹 사이트와 애플리케이션을 지원하는 무료 오픈 소스 웹 서버입니다.

www.ibm.com

아파치 톰캣 개념 구성 & 설정 - inpa

[TOMCAT] 아파치 톰캣 개념 구성 & 설정 정리

아파치 (Apache) 와 톰캣 (Tomcat) 아파치 (Apache) 아파치 소프트웨어 재단에서 만든 웹서버(web server)를 일컫는다. 리눅스에서는 httpd 로 명명지어져 배포된다. 정적인 데이터들 (html, css 이미지, 파일

inpa.tistory.com

[SAP] MM - S/4HANA MATDOC이란? 무엇인가

가시가되어 — Wed, 3 Dec 2025 10:47:53 +0900

MM - S/4HANA MATDOC이란? 무엇인가?

MM에서 주요한 변경 사항 중 하나인 단일 테이블 구조인 MATDOC으로의 변경사항 분석 및 정리하였습니다.

S/4HANA MATDOC 단일 테이블 구조의 기술적 내용 분석

1. 변화의 배경: 기존 ECC의 문제점

기존 SAP ECC(ERP Central Component) 버전의 시스템에서 재고 문서는 두 개의 클러스터 테이블(Cluster Tables)로 분리되어 관리되었습니다.

MKPF (Material Document Header): 재고 이동의 헤더 정보 (문서 번호, 전기일, 트랜잭션 코드 등).
MSEG (Material Document Item): 재고 이동의 아이템 상세 정보 (자재 번호, 수량, 저장 위치, 이동 유형 등).

이러한 분리 구조는 다음과 같은 기술적 문제를 야기했습니다.

성능 저하: 재고 문서 리포트나 분석을 위해 MKPF와 MSEG를 항상 조인(JOIN)해야 했으며, 데이터 볼륨이 커질수록 쿼리 시간이 길어졌습니다.
복잡한 코드: 개발 시에도 항상 두 테이블을 다뤄야 했기 때문에 코드가 복잡해졌습니다.

2. ✨ MATDOC 테이블의 기술적 특징 (S/4HANA)

S/4HANA에서는 MKPF와 MSEG가 단일 테이블 MATDOC로 통합되었으며, 이는 SAP HANA DB의 인메모리(In-Memory) 기술을 활용한 결과입니다.

특징	설명	기술적 이점
단일 테이블 (One Single Table)	MKPF의 헤더 필드와 MSEG의 아이템 필드가 모두 MATDOC 테이블 하나에 통합되었습니다.	I/O 감소: 불필요한 DB 조인이 제거되어 쿼리 속도가 극적으로 향상됩니다.
HANA 최적화	MATDOC는 HANA DB의 컬럼 기반 저장소(Columnar Store)에 최적화되어 있습니다.	압축 효율: 데이터를 컬럼 단위로 압축하여 저장하므로, 디스크 공간 절약 및 인메모리 액세스 속도가 빨라집니다.
재고 가치(Valuation) 통합	기존에 재고 가액 정보를 저장하던 테이블(MSKU, MBEW 등)의 정보가 MATDOC를 통해 실시간으로 집계됩니다.	실시간 분석: 재고 수량과 금액 정보가 하나의 문서에 연결되어 있어 실시간으로 재고 평가액을 확인 가능합니다.
호환성 뷰 (Compatibility Views)	기존 ECC 환경에서 사용하던 MKPF와 MSEG를 참조하는 프로그램이 S/4HANA에서도 오류 없이 작동하도록, 시스템은 동일한 이름의 뷰(Views)를 제공합니다.	하위 호환성: 기존 ABAP 코드의 대대적인 수정 없이 S/4HANA로 마이그레이션할 수 있습니다. (단, 퍼포먼스 최적화를 위해서는 MATDOC로 직접 변경 권장)

호환성 뷰 (Compatibility View) 역할

기존부터 운영해온 SAP ECC(구버전) 시스템에는 MSEG 테이블을 직접 참조하는 프로그램 및 Function, Report 등이 존재할 수 있습니다. S/4HANA로 마이그레이션할 때 이러한 기존 코드를 대규모로 수정해야 하는 부담을 줄이기 위해 MSEG라는 이름의 데이터베이스 테이블을 제거하고, 대신 MSEG라는 이름의 HANA 뷰를 생성하여 해결하였습니다.

실제로는 HANA 데이터베이스가 이 요청을 MATDOC 테이블을 쿼리하는 복잡한 뷰로 자동 해석하여 데이터를 가져옵니다. 따라서 개발자는 코드 수정 없이 이전처럼 MSEG를 참조해서 사용이 가능합니다.

⚠️ 기술적 주의사항 및 권장 사항

비록 MSEG가 계속 작동하더라도, S/4HANA 환경에서는 MATDOC을 사용하는 것이 최적의 방식입니다.

퍼포먼스 최적화: 호환성 뷰를 통과하는 것보다 MATDOC 테이블을 직접 참조하는 것이 HANA 인메모리 기술을 가장 효율적으로 사용하며, 최상의 쿼리 성능을 보장합니다.
신규 개발 원칙: S/4HANA 환경에서 새로 개발하는 프로그램이나 리포트는 반드시 MATDOC 테이블을 사용해야 합니다.
데이터 볼륨: MATDOC는 헤더와 아이템을 통합했기 때문에 데이터 볼륨이 매우 크며, 쿼리할 때 불필요한 필드를 모두 가져오지 않고 필요한 컬럼만 선택하여 쿼리하는 것이 성능에 유리합니다.

MATDOC 주요 컬럼 정리 (S/4HANA)

1. 문서 키 (Document Key) 및 관리 정보

이 컬럼들은 각 재고 이동 문서(Material Document)를 고유하게 식별하고 관리하는 데 사용됩니다.

컬럼명	기술명	설명
자재 문서 번호	MBLNR	재고 이동 문서의 고유 번호 (10자리)
자재 문서 연도	MJAHR	재고 이동 문서가 전기된 회계 연도 (4자리)
아이템 번호	ZEILE	자재 문서 내의 항목(아이템) 번호 (4자리)
전기일	BUDAT	문서가 재무회계에 전기된 날짜 (Posting Date)
문서일	BLDAT	공급업체 송장 또는 실물 문서의 실제 날짜 (Document Date)
생성 사용자	USNAM	문서를 생성한 사용자 ID
T-Code	TCODE	문서를 생성하는 데 사용된 트랜잭션 코드 (예: MIGO)

2. 재고 관련 핵심 정보

이 컬럼들은 어떤 자재가, 어디서, 어떻게 이동했는지를 정의합니다.

컬럼명	기술명	설명
자재 번호	MATNR	재고 이동이 발생한 자재의 고유 번호
플랜트	WERKS	자재가 이동한 플랜트 (Plant)
저장 위치	LGORT	자재가 이동한 저장 위치 (Storage Location)
재고 이동 유형	BWART	재고 이동의 성격 (Movement Type, 예: 101 입고, 201 소비)
이동 지시자	KZBEW	재고 유형 구분 (예: K 위탁 재고, O 외주가공 재고)
수량	MENGE	이동된 재고의 수량
단위	MEINS	수량의 기본 측정 단위 (Unit of Measure)
입고/출고 지시자	SHKZG	재고 수량이 증가(H: Credit)했는지 감소(S: Debit)했는지 표시

3. 구매 및 재무회계 연동 정보

이 컬럼들은 재고 이동이 구매 오더나 회계 전표와 어떻게 연결되는지를 보여줍니다.

컬럼명	기술명	설명
구매 오더 번호	EBELN	PO (Purchase Order) 번호
PO 아이템	EBELP	PO 내의 항목 번호
참조 문서	XBLNR	외부 참조 번호 (벤더 송장 번호 등)
현지 통화 금액	DMBTR	이동된 재고 금액의 현지 통화(회사 코드 통화) 기준 값
FI 거래 코드	BUKRS	재무회계 회사 코드 (Company Code)

4. 특수 재고 및 기타 정보

컬럼명	기술명	설명
벤더	LIFNR_SID	거래가 발생한 벤더 번호 (특수 재고 K, O 등)
고객	KUNNR_SID	거래가 발생한 고객 번호 (특수 재고 E, Q 등)
로트 번호	CHARG_SID	배치 관리(Batch Management)가 적용된 자재의 로트 번호
자산 번호	ANLN1	고정 자산 관리에 사용되는 자산 번호

[SAP] 디버깅(Debugging) 및 문제 데이터 찾기

가시가되어 — Tue, 2 Dec 2025 10:16:52 +0900

SAP 기능적 디버깅(Debugging) 및 문제 데이터 찾기

SAP 오류가 발생했을 때, 가장 찾기 쉬운 방법은 디버깅을 걸어서 로직을 추적해보는 것입니다.

이러한 디버깅을 위한 기본적인 방법들을 정리해봅니다.

표준 디버깅(/h 또는 SE38 등으로 프로그램 조회 후 BreakPoint 설정) 또는 /h 를 못할 때 TXT파일을 만들어서 팝업 등에서 디버깅 과 디버깅 시 흐름 및 문제 추적 방법 등을 나열합니다.

1️⃣ 디버깅 진입 및 기본 사용법

A. 표준 디버깅 시작 방법

방법	설명	사용 T-Code/Action
/h 명령어	T-Code 입력창에 /h를 입력하고 엔터를 치면, 다음 액션 시 New Debugger가 자동으로 실행됩니다.	T-Code: /h 입력 후 엔터
외부 Breakpoint	특정 ABAP 코드 라인에 직접 외부 Breakpoint를 설정합니다. 외부 환경(Web Dynpro, RFC, Gateway 등)에서 호출될 때 유용합니다.	SE38/SE80에서 코드 라인 옆에 설정 (집 모양 아이콘)
시스템 메시지 발생 시	오류 메시지 팝업창에서 /h를 입력하거나, /A 명령어를 입력하면 Classic Debugger가 실행되기도 합니다.	T-Code: /A (Classic Debugger)

/h로 디버깅이 안 될 때 대체 방법 (팝업 등으로 명령어 필드에서 /h 입력을 못하는 Case)

아래 내용을 TXT 파일로 만든 다음, SAP GUI로 TXT파일을 넣어서 걸 수 있습니다.

[FUNCTION]
Command=/H
Title=Debugger
Type=SystemCommand

B. 핵심 단축키 (F Key)

단축키	기능	설명
F5	Step-by-step	한 줄씩 실행. Perform (Subroutine) 안으로 진입.
F6	Execute	한 줄 실행. Perform (Subroutine) 안으로 진입하지 않고 다음 라인으로 건너뜁니다.
F7	Return	현재 서브루틴, 함수 모듈, 또는 메서드 실행을 완료하고 호출 지점으로 돌아갑니다.
F8	Continue	다음 Breakpoint까지 또는 프로그램 끝까지 실행을 계속합니다.

2️⃣ 문제 데이터 및 로직 흐름 추적

A. 변수 및 내부 테이블 확인

Variables 탭: 디버거의 Variables 탭에서 로컬 변수, 글로벌 변수, 내부 테이블 등을 확인합니다.
Watchpoint 설정: 특정 변수나 내부 테이블의 값이 변경될 때 자동으로 디버거를 멈추게 하려면 Watchpoint를 설정합니다. (예: L_MENGE > 100일 때 멈춤)
필드 심볼/데이터 참조: <FS>나 LR_DATA 형태의 변수를 더블 클릭하거나 Watchpoint에 추가하여 실제 가리키는 데이터를 확인합니다.

B. 데이터 검색: ST12 / SQL Trace 활용

디버거에서 데이터를 확인하는 것도 중요하지만, 프로그램이 어떤 데이터를 조회하는지 아는 것이 더 중요합니다.

ST12 (Single Transaction Analysis):
- 용도: 특정 트랜잭션 실행 중 발생하는 ABAP Trace와 SQL Trace를 동시에 분석하여 성능 문제나 데이터 조회 로직을 파악할 때 최적입니다.
- 꿀팁: 트랜잭션 실행 전에 ST12에서 설정하고 실행하면, 프로그램이 어떤 DB 테이블을 어떤 키 값으로 조회(SELECT) 했는지 정확히 알 수 있어, 문제 데이터를 DB에서 바로 찾을 수 있습니다.
SQL Trace (T-Code: ST05):
- 용도: 프로그램이 DB에서 데이터를 조회, 수정, 삽입, 삭제하는 모든 SQL 문을 추적합니다.
- 꿀팁: 추적 결과를 통해 문제 데이터가 어떤 테이블에 잘못 저장되었는지, 또는 필요한 데이터가 누락되었는지 확인하는 데 가장 빠르고 확실한 방법입니다.

C. Call Stack을 이용한 로직 역추적

Call Stack (호출 스택) 탭: 현재 실행 중인 코드 라인이 어떤 서브루틴, 함수 모듈, 메서드를 거쳐서 호출되었는지 순서대로 보여줍니다.
활용: 오류가 발생한 지점(DUMP 또는 메시지)에서 Call Stack을 역순으로 클릭하며 올라가면, "어디서부터" 잘못된 로직이나 데이터가 시작되었는지 파악할 수 있습니다. 특히 표준 프로그램에서 커스터마이징(Exit, BAdI)이 실행된 위치를 찾을 때 매우 유용합니다.

D. 메시지 발생 지점 찾기

메시지 ID/번호 확인: 오류 메시지(예: ME 123)가 나타나면, 해당 메시지 클래스(ME)와 메시지 번호(123)를 확인합니다.
SE91/SE93 검색:
- SE91 (메시지 유지보수)에서 해당 메시지 클래스 및 번호를 조회하여 메시지 텍스트를 확인합니다.
- SE93 (트랜잭션 코드 유지보수)에서 트랜잭션을 찾습니다.
Where-Used List (사용처 목록): SE91에서 메시지를 선택한 후 "사용처 목록(Where-Used List)" 기능을 사용하여, 해당 메시지가 어떤 ABAP 프로그램에서 호출되는지 찾아 Breakpoint를 설정합니다. 이렇게 하면 오류 발생 직전에 디버거가 멈춥니다.
Watchpoint 를 SY-MSGID와 SY-MSGNO 로 설정할 수도 있습니다.

[SAP] MM(Materials Management) 운영 전문가 가이드

가시가되어 — Mon, 1 Dec 2025 10:01:31 +0900

[SAP] MM(Materials Management) 운영 전문가 가이드

SAP MM 모듈을 운영하며, 회사와 상관없이 공통적으로 운영(SM) 조직에서 쓸 수 있는 가이드 정리한 글입니다.

SAP MM 핵심 프로세스 이해

SAP MM 모듈은 기업의 자재 조달 및 재고 관리 전반을 담당하며, SCM(Supply Chain Management)의 핵심 축을 이룹니다.

SAP ERP 솔루션의 Core 모듈 중 하나입니다.

주로 아래 영역을 다루게 됩니다.

조달(Procurement): 필요한 자재나 서비스의 구매 요청부터 계약, 주문, 입고, 송장 처리까지의 전 과정.
재고 관리(Inventory Management): 자재의 입고, 출고, 이동, 재고 실사 등의 관리.
자재 마스터(Material Master): 시스템 내 모든 자재에 대한 중앙 집중식 정보 관리.
공급업체,공급사(Vendor Master) : 회사의 자재를 공급하는 공급업체에 대한 관리. (S4 HANA에서는 비즈니스 파트너, BP)

핵심 운영 업무 및 트랜잭션 코드

가장 빈번하게 사용되는 핵심 운영 트랜잭션 코드(T-Code)와 그 용도입니다.

스탠다드 T-code 위주로 정리하였습니다. (CBO로 생성된 Report 및 프로그램에 대해선 자체적으로 검토해야 합니다.)

주로 MM모듈의 T-code 들은 M~ 으로 시작하는 경향이 있습니다.

T-Code	기능 설명	운영 시 주요 역할
ME51N / ME52N / ME53N	구매 요청(Purchase Requisition) 생성/변경/조회	필요한 자재/서비스 구매 요청 및 승인 프로세스 시작
ME21N / ME22N / ME23N	구매 주문(Purchase Order) 생성/변경/조회	공급업체에 대한 공식적인 자재 구매 주문 생성 및 관리
MIGO	재고 이동(Goods Movement): 입고, 출고, 이동	자재의 물리적 이동(납품 수령, 생산 출고 등) 시스템 반영 ECC에서는 MB1B, MB1A, MBST, MB03 등의 T-code로 나눠져 있으나, S4 HANA에서는 통합됨. * obsolete (see note 2210569 )
MIRO	송장 확인(Invoice Verification)	공급업체로부터 받은 송장(세금 계산서) 처리 및 3-Way 매칭
MM01 / MM02 / MM03	자재 마스터 생성/변경/조회	자재 속성, 재고 수준, 가격 결정 등의 기초 데이터 관리
MK01 / MK02 / MK03	공급업체 마스터 생성/변경/조회	공급업체에 대한 구매데이터 생성 관리
MB51	자재 문서 목록(Material Document List) 조회	모든 재고 이동 이력을 추적 및 분석 (특정 기간, 자재, 이동 유형별)
MB52	재고 조	특정 자재의 현재 창고 재고를 수량과 금액으로 조회
MMBE	재고 조회	실시간 재고 조회, 플랜트 및 저장위치 단위로 전체 재고상태 확인

SAP MM 유용한 T-code 정리 글 참조

[ERP] SAP MM 모듈 및 유용한 T-code 정리(transaction code)

T-code : transaction code : SAP GUI 에 명령어 필드로 입력하여 실행 가능하다. : 엔조이 트랜잭션(enjoy transaction)은 기존 트랜잭션이 수행한 모든 작업을 한 화면에서만 수행하는 새로운 트랜잭션 모든 En

kora1492.tistory.com

SAP 운영에 유용한 T-code 모음

[SAP] 운영에 유용한 T-code 모음( 모니터링, 잠금, DB, OS)

[SAP] 운영에 유용한 T-code ( 모니터링, 잠금, Db, OS) 1. OSSAP Operating System 에 대한 CPU, Memory, Pool, Disk, Lan 등을 확인할 수 있다. - Tcode : ST06 ( OS06, T-code ST06으로 대체 가능) 2. 점검 , 모니터링 SM12 : Lock Ent

kora1492.tistory.com

주요 운영 이슈 및 대응 방안

1. 3-Way 매칭 불일치 (PO-GR-IR)

이슈: 구매 주문(PO), 입고(GR), 송장 확인(IR) 간의 수량이나 금액이 일치하지 않아 송장 처리가 막히는 경우.
대응:
- 입고 오류: MIGO에서 입고 취소(102) 후 정확한 수량으로 재입고(101) 처리.
- 송장 오류: 공급업체에 수정을 요청하거나, 차후 차변/대변 메모(Debit/Credit Memo)를 통해 조정 처리. (전기 취소가 가능한 경우에는 취소하고 재처리 T-code MR8M)

2. 재고 수량 불일치

이슈: 시스템 재고와 실제 물리적 재고 간의 차이가 발생할 때 (예: 분실, 파손, 기록 오류).
대응:
- 재고실사 프로세스: MI01/MI04/MI07 T-Code를 사용하여 정기적 또는 비정기적인 재고 실사(Physical Inventory)를 수행하고 차이(Difference)를 조정.
- 이동 유형(Movement Type): 정확한 이동 유형(701/702 등)을 사용하여 시스템 재고를 실제 재고에 맞게 조정하고, 차이 발생 원인 분석.

3. 자재 마스터 데이터 오류

이슈: 자재 마스터의 가격, 단위, 재고 평가 클래스(Valuation Class) 등의 기초 데이터가 잘못 설정되어 후속 프로세스(회계 처리, MRP 등)에 영향을 미치는 경우.
대응:
- 데이터 검증: MM03을 통해 필수 필드를 정기적으로 검토하고, 오류 발견 시 MM02를 통해 신속하게 수정. 변경 문서를 확인하여 수정 이력 추적.
- Cross-Functional 협업: 재무(FI) 및 생산(PP) 모듈 담당자와 협의하여 평가 클래스나 MRP 설정 등을 조정.

SCM 및 연관 모듈과의 연계

MM 운영은 단독으로 이루어지지 않고, 다음과 같은 모듈 및 SCM 영역과 긴밀하게 연결됩니다.

FI/CO (Financial Accounting / Controlling):
- 연계: 자재 입고/출고 시 재고 금액이 재무제표(FI, T-code CKM3N에서 이력 확인)에 반영되며, 구매 비용은 원가 관리(CO)로 흘러들어 갑니다. 재고 평가 클래스와 자동 계정 결정(OBYC) 설정이 핵심입니다.
SD (Sales and Distribution):
- 연계: 고객 주문(SD)에 대한 출고(Goods Issue)는 MM의 재고 이동을 통해 처리되며, 이는 곧 판매 가능한 재고(ATP)에 영향을 미칩니다.
PP/QM (Production Planning / Quality Management):
- 연계: 생산 주문에 필요한 원자재의 예약(Reservation) 및 출고는 MM에서 담당하며, 입고된 자재의 품질 검사(QM) 결과는 MM의 재고 유형(예: 품질 검사 재고, 사용 가능 재고)을 결정합니다.

[SAP] Clean Core (클린 코어) 전략 및 학습 과정

가시가되어 — Fri, 28 Nov 2025 12:06:34 +0900

[SAP] Clean Core (클린 코어) 전략 및 학습 과정

SAP 클린코어 개념과 정리, 성공전략을 정리합니다.

또한 SAP 개발자 학습 로드맵(강의 및 자격증) 등을 세부적으로 알아봅시다.

1. 클린 코어의 정의 및 배경

클린 코어는 SAP S/4HANA의 핵심 시스템 (Core System)을 표준 상태로 유지하고, 고객별로 필요한 모든 확장(Extensions) 및 변경(Modifications)은 핵심 시스템 외부에서 구축하는 전략적 접근 방식을 의미합니다.

배경: 기존 SAP ERP의 문제점 (ECC)

이전 세대인 SAP ECC 환경에서는 고객의 요구사항을 반영하기 위해 다음과 같은 방식으로 핵심 시스템 코드를 자주 변경했습니다.

Modification: SAP 표준 코드를 직접 수정 (가장 위험).
Enhancement: User-Exit, BAdI 등을 사용한 기능 추가.

이러한 변경사항들은 시스템 업그레이드 및 패치 적용 시마다 엄청난 노력과 비용을 초래하는 주범이었습니다.

이것을 흔히 "Spaghetti Code(스파게티 코드, 유지보수가 어렵고 복잡한 소스코드)" 라고 불렀습니다.

클린 코어의 목표

업그레이드 용이성(Upgrade Stability)과 민첩성(Agility)을 확보하여, 시스템 운영 비용(TCO)을 절감하고 비즈니스 혁신을 가속화하는 것입니다.

2. 클린 코어 전략의 핵심 구성 요소

클린코어의 5가지 기본 원칙

프로세스: 클린 비즈니스 프로세스는 SAP 표준에 최대한 가깝게 유지하여 경쟁력을 유지하고 복잡성을 줄입니다.
확장성: 클린 확장은 릴리스된 API를 활용하여 코어에서 분리됩니다. 명확한 거버넌스 프로세스를 통해 최상의 확장성 옵션을 온스택 및 SAP BTP와 함께 활용할 수 있습니다.
데이터: 클린 데이터는 데이터를 깨끗하고 규정을 준수하는 상태로 유지하기 위한 지속적인 노력과 확립된 데이터 거버넌스 모델을 의미합니다.
통합: 클린 통합은 표준화되고 안전하며 확장 가능한 기술을 기반으로 구축된 시스템을 연결하는 강력하고 안정적이며 미래를 대비한 접근법입니다.
운영: 클린 운영은 거버넌스, 인력, 프로세스, 툴에 모범 사례를 내장하여 비즈니스 혁신을 지원하는 민첩한 IT 혁신을 실현하는 다차원적 접근법을 말합니다.

클린 코어 전략을 실행하기 위해서는 확장 방식을 핵심 코어 외부로 옮겨야 하며, 이 역할을 담당하는 것이 주로 SAP Business Technology Platform (SAP BTP)입니다.

구성 요소	설명	기술/도구
Clean Core (핵심)	SAP S/4HANA Cloud (Public/Private)의 표준 기능	SAP Best Practices, Fiori UI
Side-by-Side Extension	핵심 시스템과 분리된 플랫폼에서 새로운 기능을 개발 및 실행	SAP BTP, Cloud Application Programming Model (CAP), ABAP Environment (Steampunk)
In-App Extension	핵심 시스템 내부에서 SAP이 허용한 영역 내에서 간단한 확장	Key User Extensibility (KUT), Custom Fields, Custom Logic
APIs	핵심 시스템과 외부 확장 간의 유일한 통신 수단	Public APIs, OData Services

3. 컨설팅 및 개발 관점의 변화

클린 코어는 단순히 기술 변화가 아니라, SAP 프로젝트를 수행하는 방식 전체를 변화시킵니다.

컨설턴트의 역할 변화

표준화 강조: 고객 요구사항을 수용할 때, "어떻게 커스터마이징 할까?"보다 SAP Best Practices로 구현 가능한가?를 먼저 검토하고 표준 프로세스 준수를 강력하게 유도해야 합니다.
프로세스 설계: 표준으로 해결할 수 없는 요구사항은 S/4HANA 코어에서 벗어나 SAP BTP에서 어떻게 새로운 서비스를 구축할지 (Side-by-Side)를 설계해야 합니다. (이른바 "Outside-In" 사고방식)
업그레이드 관리: 클린 코어 전략을 통해 고객이 지속적인 혁신(Continuous Innovation)을 받을 수 있도록 분기별/연간 업그레이드 계획을 지원합니다.

개발자의 역할 변화

API 전문가: SAP 개발자는 이제 BTP 환경에서 자바, Node.js 등 다양한 언어를 활용하고, SAP이 제공하는 Public API를 사용하여 코어 시스템과 통신하는 방법에 능숙해야 합니다.
Integration (통합): SAP BTP Integration Suite를 사용하여 코어와 외부 애플리케이션, 레거시 시스템을 연결하는 통합 전문가가 되어야 합니다.
클라우드 네이티브 개발: 개발 환경이 클라우드 서비스(CAP, Steampunk) 기반이 되므로, CI/CD(지속적 통합/배포)와 같은 DevOps 방법론에 익숙해져야 합니다.

4. 클린 코어의 성공을 위한 핵심 요소

요소	중요성
API 관리 및 거버넌스	SAP이 제공하는 API가 고객의 요구사항을 충족하는지 검토하고, 필요한 API가 없다면 SAP에 요청하거나 대체 솔루션을 모색해야 합니다. 모든 통신은 API를 통해서만 이루어져야 합니다.
기술 부채 해소 (Technical Debt Resolution)	기존 ECC에서 사용하던 수많은 커스텀 코드를 새로운 클린 코어 환경으로 이전할 때, 대부분을 폐기하거나 BTP 기반의 확장으로 재구축해야 합니다. 이는 프로젝트 초기 단계에서 가장 큰 작업 중 하나입니다.
핵심 사용자 교육	사용자가 이제 Fiori 앱과 표준 프로세스에 익숙해지도록 교육하고, 사용자 정의 필드(KUT)와 같은 간단한 확장은 Key User가 직접 수행할 수 있도록 역량을 강화해야 합니다.

5. SAP 개발자의 학습 과정과 로드맵

1. 기초

영역	학습 목표	추천 자료 (SAP Learning Hub / Community)
클라우드 & BTP 이해	SAP BTP의 서비스 모델(PaaS) 및 주요 서비스(Integration, Extension) 이해	SAP BTP Onboarding 과정, SAP Discover Center의 BTP 관련 미션
ABAP Cloud	클린 코어 환경에서 허용된 ABAP 언어 서브셋, RAP(Restful ABAP Programming Model)의 기본 이해	S4D400 (ABAP Programming for SAP S/4HANA) 또는 AD126 (Introduction to ABAP for Cloud)
Fiori & UX	SAP Fiori 디자인 원칙 이해 및 UI5를 활용한 기본적인 사용자 인터페이스 구현 방법	UX100 (SAP Fiori Fundamentals)
API 활용	OData 서비스 및 SAP Public API를 찾아보고 사용하는 방법	SAP API Business Hub 튜토리얼

2. 전문가 (Extension Specialist) 로드맵

SAP S/4HANA 코어의 기능을 확장하거나 새로운 클라우드 애플리케이션을 구축하는 역할에 집중합니다.

모듈	상세 학습 내용	추천 과정 및 교재 (Code)
BTP ABAP (Steampunk)	BTP ABAP Environment에 애플리케이션 배포, RAP(Restful ABAP Programming Model)을 사용한 서비스 개발	DEV401 (Advanced ABAP Cloud Development), S4D430 (Building Apps with RAP)
CAP (Cloud Application Programming)	자바스크립트(Node.js) 또는 Java를 사용하여 BTP Cloud Foundry 환경에서 마이크로 서비스 기반 앱 개발	CP261 (Develop Extensions with CAP)
DevOps & CI/CD	SAP CI/CD 서비스 및 GitHub, Jenkins를 활용하여 애플리케이션 자동 배포 및 테스트 환경 구축	SAP Help Portal, BTP Developer Tutorials

SAP 시스템 간, 또는 SAP과 비-SAP 시스템 간의 데이터 및 프로세스를 연결하는 역할에 집중합니다.

모듈	상세 학습 내용	추천 과정 및 교재 (Code)
Integration Suite	Cloud Integration (CPI)을 사용한 메시지 매핑, 어댑터 설정, I-Flow 개발	CLD900 (SAP Cloud Platform Integration) 또는 BIT800 (SAP Integration Suite Overview)
API Management	SAP BTP에서 API 게이트웨이를 설정하고, API 사용 정책, 보안 및 라이프사이클 관리	SAP BTP API Management Tutorials
Event Mesh	비동기적 통합을 위한 이벤트 기반 아키텍처(EDA) 이해 및 SAP Event Mesh 활용	BTP Event Mesh Tutorials

3. SAP Certification (자격증)

학습한 지식을 검증하고 실전 역량을 강화합니다.

공식 인증(Certification): 학습한 전문 영역에 대한 SAP 공인 인증 시험에 응시하여 전문성을 입증합니다.
- 추천 자격증: C_TADM_23 (BTP Administration), C_CPI_15 (Cloud Integration), C_HCDEV (HANA Cloud Development) 등.
프로젝트 실습: SAP BTP Free Tier 또는 Trial 계정을 활용하여 실제 시나리오(예: S/4HANA 데이터 기반 커스텀 재고 조회 앱 개발 및 배포)를 구현해봅니다.
SAP Community 활동: 최신 기술 트렌드를 파악하고, 발생하는 문제에 대한 해결책을 공유하며 지식을 확장합니다.

참고 사이트

https://www.sap.com/korea/products/erp/rise/methodology/clean-core.html

https://learninghub.sap.com/

https://training.sap.com/

[SAP] MM 3-Way 매칭 (PO, GR, IV)

가시가되어 — Thu, 27 Nov 2025 11:00:14 +0900

MM 3-Way 매칭 (PO, GR, IV)

SAP MM의 3-Way 매칭(Three-Way Match, 3자 매칭)은 조달 프로세스(P2P, Procure-to-Pay)에서 재무적 무결성을 보장하고 부정 지출을 방지하는 핵심 통제(Key Control) 메커니즘입니다.

조달 프로세스 흐름을 가볍게 살펴보면, 일반적으로 아래 상황을 따르게 됩니다.

1) 구매발주(구매오더)를 요청하고 이를 기반으로 공급업체에서는 2) 납품서를 만들어, 실물을 납품/입고합니다. 그리고 업체에서는 주문하여 납품한 수량과 가격/금액을 갖고 돈을 청구하게 됩니다.

재무관점 Account Payable(AP, 외상매입금/미지급금)을 설정하여 지급처리하게 처리합니다.

회사에서는 정해져있는 지급조건(현금/카드/어음 등) 기준에 따라 공급업체에게 지불을 하게 됩니다.

위의 전반적인 과정에서 오류 혹은 부정행위, 초과/미지급이 발생되지 않기 위해 3-Way 매칭이 중요한 요소로 존재합니다.

1. 3-Way 매칭의 목적 및 중요성

목적	설명
재무 통제	승인된 금액과 수량만 지급되도록 보장하여 오류, 사기 및 초과 지출을 방지합니다.
프로세스 무결성	조달 과정의 모든 단계(구매, 수령, 송장)가 올바르게 실행되었는지 확인합니다.
감사 추적성	모든 거래가 명확하게 문서화되어 감사(Audit) 및 규정 준수(Compliance)에 용이합니다.
GR/IR 정리	GR/IR(Goods Receipt/Invoice Receipt) 계정의 잔액을 적절히 관리하고 정리할 수 있습니다.

ERP 전사적 자원관리 시스템, 특히 SAP는 이러한 재무적인 통제/안정성이 가장 큰 장점입니다.

2. 세 가지 주요 문서의 역할 및 비교 대상

문서	SAP T-Code 예시	역할	비교 대상
1. 구매 오더 (Purchase Order, PO)	ME21N	계약 및 승인. 구매할 품목, 수량, 가격에 대한 약정.	GR의 수량, IV의 수량 및 가격
2. 입고 문서 (Goods Receipt, GR)	MIGO	실물 수령 확인. 창고 또는 사용자에게 실제 도착한 품목의 수량 기록.	PO의 수량
3. 청구서 (Invoice Verification, IV)	MIRO	지급 요청. 공급업체가 대금을 청구하는 문서 (송장). 수량 및 가격 포함.	PO의 가격, GR의 수량

구매오더를 통해 공급사(Vendor)에게 발주를 보내는 오퍼를 정식적으로 생성합니다.

구매할 품목(자재) / 수량 / 단가, 금액 (가격)을 정합니다.

* 공급사에서는 SAP 내부 정보를 조회하지 못하기 때문에 SRM 솔루션(SAP Ariba, 엠로 등)을 활용해서 정보를 공유하거나 별도로 구매담당자가 통지하게 됩니다.

* 구매정보레코드를 통해 단가 관리/계약을 갖고 있을 수 있습니다.

입고문서(GR) 공급사(Vendor)에서는 구매오더를 확인(수주) 후, 납품서를 만들어서 실물을 창고/저장위치에 납품합니다.

이러한 실물이 회사에 정상적으로 입고/수령이 된 경우, 전산적으로 SAP T-code MIGO 입고처리를 합니다.

입고 처리 시, PO를 참조하여 처리하게 되는데 납품 내 정보에 초과/미달 납품 한도를 설정할 수 있습니다. PO의 수량과 동일한 수량으로 입고 처리되는 게 원칙이며 모든 수량이 입고처리될 경우, 납품 완료 Flag가 찍힙니다.

이를 통해 발생된 자재전표(자재원장, ML)는 구매오더이력(history)에서 볼 수 있습니다.

자재전표를 눌러서 조회하여 문서정보를 누르게 되면 이와 연결된 FI문서를 조회할 수 있습니다.

청구서, 송장(IV) 공급사(Vendor)에서 세금계산서 등의 서류로 지급 요청을 하게 됩니다. 이러한 것을 송장/청구서(Invoice) 이며 이러한 것에 대한 검증을 진행합니다. SAP에서 전산처리 시 MIRO에서 구매오더/납품계약을 참조하여 처리합니다.

정확한 가격 및 수량이 맞는 지 체크하고 전표 처리를 하게 됩니다. 전기가 완료되면, GR과 마찬가지로 PO 구매오더 이력에서 확인할 수 있습니다.

3. ⚙️ 매칭의 작동 방식 (실행 가이드라인)

3-Way 매칭은 청구서 검증(IV) 단계에서 가장 활발하게 일어납니다.

매칭 단계	비교 대상	결과	SAP 시스템의 동작
1. 수량 매칭	GR 수량 vs IV 수량	IV 수량이 GR 수량을 초과할 수 없습니다 (초과 시 오류 또는 경고).	IV 입력 시, 시스템은 GR 문서와 비교하여 허용 범위를 벗어나는지 확인합니다.
2. 가격 매칭	PO 가격 vs IV 가격	IV 가격이 PO의 가격과 일치하는지 확인.	가격 허용 한도 설정(Tolerance Limit)에 따라 차이가 경고/오류로 처리됩니다.
3. PO 참조	IV가 PO를 참조했는지	IV가 PO 번호를 참조하여 생성되어야 PO의 조건이 상속됩니다.	MIRO에서 PO 번호를 입력하면, 관련 GR 정보와 PO 가격 정보가 자동으로 불러와집니다.

SAP MM 3-Way 매칭 자동화 방안

1. 시스템 설정 기반 자동화 (System Customizing)

SAP 표준 기능 내에서 가장 중요한 자동화 요소는 허용 한도 설정 및 자동 지급 블록입니다.

A. 허용 한도 설정 (Tolerance Keys)

T-Code: OMR6를 사용하여 가격 및 수량 차이에 대한 허용 범위를 정의합니다.

설정 원칙: 허용 한도 내의 차이는 경고(Warning)만 발생시키고 송장을 자동으로 승인하여 지급 블록이 걸리지 않도록 합니다.
자동 처리: 시스템이 IV 입력 시 PO의 조건과 비교하여 차이가 설정한 허용 한도 내에 있다면, 자동으로 Small Differences (DIF) 계정-대차조정계정으로 전기하여 처리합니다.

B. 청구서 블록 해제 (MRBR)

차이가 허용 한도를 초과하면 시스템은 송장에 지급 블록을 설정합니다.

자동화는 이 블록을 처리하는 방식에 중점을 둡니다.

MRBR (Release Blocked Invoices): 지급 블록이 걸린 송장들을 모니터링하고, PO나 GR이 사후에 수정되어 매칭 조건이 충족되면 시스템이 MRBR 작업을 통해 블록을 해제하고 지급 가능 상태로 전환(FI 릴리즈)할 수 있습니다.
Worklist 자동 생성: 지급 블록이 해제되지 않은 송장(IV)들은 담당 구매 그룹이나 재무 담당자에게 SAP Business Workflow를 통해 자동으로 알림을 전송하여 수동 조치를 유도합니다.

2. 지능형 기술 통합 자동화 (Intelligent Automation)

S/4HANA 환경으로 전환하거나 외부 솔루션을 통합할 경우, 매칭 프로세스에 지능형 기술을 적용하여 완전한 자동화를 추구할 수 있습니다.

A. SAP Ariba Invoice Management (클라우드 기반)

SAP Ariba를 사용하여 구매 프로세스를 진행할 경우, 클라우드 환경에서 매칭 자동화가 강화됩니다.

PO 기반 IV 수신: 공급업체가 Ariba 네트워크를 통해 PO를 참조하여 전자 송장(E-Invoice)을 제출하면, Ariba는 3-Way 매칭을 선행 수행합니다.
예외 처리: Ariba는 매칭에 실패한 송장만 사용자에게 전달하며, 성공한 송장은 SAP ECC/S/4HANA로 전송되어 자동으로 전기됩니다.

B. 로봇 프로세스 자동화 (RPA) 및 AI

RPA 봇 활용:
- PO/GR 데이터 검증: PO/GR/IV 간의 차이 리포트를 MB5S와 같은 트랜잭션에서 주기적으로 추출하여, RPA 봇이 특정 규칙(Rule-based)에 따라 차이가 적은 항목들을 자동으로 조정하는 프로세스를 실행할 수 있습니다.
- IV 자동 입력: 공급업체로부터 PDF나 이메일 형태로 받은 송장을 OCR (Optical Character Recognition) 기술로 스캔하고, RPA 봇이 추출된 데이터를 MIRO 트랜잭션에 자동으로 입력 및 검증합니다.
AI/ML (기계 학습):
- AI 모델을 사용하여 반복적인 차이 패턴을 학습하고, 시스템이 자동으로 이전에 승인되었던 유사한 오차 패턴에 대해 지급 블록을 면제하거나, 특정 벤더의 차이를 자동으로 조정하는 로직을 제안합니다.

2025년 11월 오픽(Opic) 시청센터 시험 짧은 후기

가시가되어 — Wed, 26 Nov 2025 09:21:20 +0900

2025년 11월 오픽(Opic) 시청센터 시험에서 보고 쓰는 짧은 후기

시청센터에서 시험을 보고 회고 및 재시험 준비를 위해 남기는 후기입니다.

오픽 시청센터는 2호선 10번 출구에서 나와서 쭉 가다보면 시험장을 볼 수 있습니다.

들어가면 안내원께서 신분증(주민등록증 or 운전면허증)을 확인하시고 입장 안내 해주셨습니다.

오픽 서베이 및 OT

처음엔 오리엔테이션을 진행하며, 이 시간동안에 백그라운드 서베이를 입력합니다.

사전 준비 없이 가다보니, 서베이도 아무거나 찍어서 기억은 자세히 안납니다.

- 일 경험없음, 학생여부 아니오/수강후 5년지남

- 거주지 개인주택/아파트 홀로거주

- 휴가/출장 - 국내여행/해외여행/집에서 보내는 휴가

- 운동 : 야구, 걷기, 조깅, 운동을 전혀하지 않음

- 여가활동 : 영화, TV시청하기, 콘서트 관람, 공원

- 취미/관심사 - 음악 감상

오픽 시험 나온 실제 문제(기출)

난이도 4-4

기출과 거의 비슷한 유형들이 나왔습니다.

특이한 건 제가 야구를 선택했기 때문에 야구 관련 콤보 3가지가 나왔네요.

1. 자기소개

대략 시작은 간단하게 이름 나이정도 말하고, 지금 시험이라 긴장되고 잘봐달라. 최선을 다하겠다라는 식으로 말하면서 야구 좋아한다라고 끝냈습니다.

2. Holiday (공휴일, 명절 등)

준비하지 않아서 크게 당황

1) 홀리데이를 어떻게 축하/기념하는 지 질문

2) 홀리데이의 과거와 현재의 차이점

3) 홀리데이 중에서 가장 어릴 적에 기억남는 건 무엇인지?

3. 음악관련 질문

1) 어떤 음악 장르를 주로 듣고, 가장 좋아하는 뮤지션이나 작곡가(composer) 누구인지 설명

2) 그 뮤지션의 콘서트를 간 적이 있는 지 언제, 누구랑

3. 야구

1) 야구에 대한 설명, 어디서 어떻게 하는 지?

2) 야구를 하기 전에 무엇을 준비하는 지?

3) 야구하는 것에 대해서 자세한 묘사

4. 날씨관련

1) 현재 날씨를 설명

2) 우리나라의 날씨에 대한 특징에 대한 설명, 그리고 무엇을 좋아하는 지?

3) 에바가 서부 캐나다에서 있는데 에바에게 할 질문?

5. 공원

1) 친구와 공원가기 전에 질문 3가지

2) 가려던 공원이 다음 주에 열지 않았을 때 대안제시

3) 가장 기억에 남은 공원에 대해서 자세한 설명

오픽 시험 결과

시험성적은 7일 후에 나온다고 하니 그때 다시 업데이트 해보도록 하겠습니다.

제 예상으론 너무 횡설수설에 준비가 안된 상태로 보고와서,, IL 예상입니다.