기본 콘텐츠로 건너뛰기

개인정보처리방침

본 블로그(Kronopia, 이하 "블로그")는 방문자의 개인정보를 소중히 여기며, 「개인정보 보호법」 및 관련 법령을 준수합니다.

■ 수집하는 개인정보
본 블로그는 방문자의 개인정보를 직접 수집하지 않습니다. 다만, 아래 제3자 서비스를 통해 익명의 통계 데이터가 자동으로 수집될 수 있습니다.
- Google Analytics: 방문자 수, 페이지뷰, 체류 시간 등 익명 통계
- Google AdSense: 광고 노출 및 클릭 관련 데이터

■ 쿠키(Cookie) 사용
본 블로그는 Google AdSense 광고 서비스를 사용합니다. Google은 쿠키를 사용하여 방문자의 이전 방문 기록을 바탕으로 맞춤형 광고를 제공할 수 있습니다.
방문자는 아래 방법으로 맞춤형 광고를 거부할 수 있습니다.
- Google 광고 설정 페이지(https://adssettings.google.com) 접속 후 비활성화
- 브라우저 설정에서 쿠키 비활성화

■ 제3자 서비스 및 외부 링크
본 블로그의 글에는 외부 사이트(SAP 공식 문서, 기술 블로그 등)로의 링크가 포함될 수 있습니다. 해당 외부 사이트의 개인정보 처리 방침에 대해서는 본 블로그가 책임을 지지 않습니다.

■ 개인정보의 보유 및 이용 기간
본 블로그는 방문자의 개인정보를 직접 보유하지 않습니다. Google Analytics 및 AdSense의 데이터 보유 기간은 각 서비스의 정책을 따릅니다.

■ 방문자의 권리
방문자는 언제든지 Google 계정 설정을 통해 수집된 데이터의 열람, 수정, 삭제를 요청할 수 있습니다.

■ 개인정보처리방침의 변경
본 방침은 법령 또는 서비스 변경에 따라 수정될 수 있습니다. 변경 시 본 페이지를 통해 공지하며, 변경 이전의 방침은 효력을 잃습니다.

■ 문의
개인정보 처리와 관련한 문의사항은 아래 이메일로 연락 주시기 바랍니다.
이메일: [jeong790505@gmail.com]

최종 수정일: 2026년 5월 10일

댓글

이 블로그의 인기 게시물

S/4HANA Cloud PCE 전환 시작 단계, 가장 먼저 바뀌는 3가지

ERP 클라우드 전환 의사결정이 끝나면, IT 담당자와 PM은 곧장 "이제 뭘 먼저 바꿔야 하나"라는 질문에 부딪힌다. 대부분의 현장에서는 '코어만 바꾸면 되죠.'라는 가정으로 시작한다. 이러한 가정이 이 글을 쓰게 된 이유다. 실제로 일을 시작해보면 가장 먼저 흔들리는 건 코어가 아니라 코어 주변 이다. On-Prem SAP에서 S/4HANA Cloud PCE로 가는 한 그룹사 마이그레이션 프로젝트의 시작 단계에서, 가장 먼저 바뀐 세 가지 고민을  시스템 토폴로지(시스템 간 연결 구조)가 먼저 바뀐다 코어가 바뀌는 게 아니라 코어 주변이 먼저 흔들린다. On-Prem 시절 BW(Business Warehouse)는 단순했다. SAP ERP 한 곳에서 데이터를 받아 모델링하고 리포트로 풀어내면 됐다. 소스시스템은 사실상 하나, 네트워크 경로는 사내, 권한 모델은 통합. S/4HANA Cloud PCE로 옮겨가면 이 전제가 흔들린다. BW가 PCE 환경의 데이터를 어떻게 끌어올지, 기존 On-Prem BW를 그대로 둘지 함께 옮길지, 인터페이스 계정 권한을 어떻게 재설계할지 — 이 문제들이 코어 전환 전에 결판나야 한다. 이 그룹사 프로젝트에서도 BW 분과의 초기 산출물은 "소스시스템 변경(안)" 문서였다. 실제 코어 전환보다 한 단계 앞서, 데이터가 어디서 어디로 흐르는가 의 지도를 다시 그리는 일이 시작된 셈이다. WMS와 외부 결재 시스템 같은 주변 인터페이스도 같은 줄 위에 올라온다. PCE는 사내가 아니라 SAP 데이터센터에 있기 때문에, 네트워크·권한·연결 모델 자체가 새 변수가 된다. Configuration의 자유도가 줄어든다 PCE는 클라우드 옷을 입은 On-Prem이 아니다. On-Prem SAP에서는 클라이언트가 Configuration을 비교적 자유롭게 잡았다. RZ010(설정값 리스트)을 뽑아보면, 회사마다 수년간 누적된 커스텀 설정이 수백 줄씩 나오는 게 보통이...

S/4HANA Cloud CBO 개발 3단계 — 어디까지 위에서 끝내는가

1·2·3편을 거쳐 As-is 산출물의 결정 트리거가 작동했다고 치자. CBO List는 BTP / 표준 흡수 / 폐기 로 분류되었고, RZ010은 표준 회귀 / 변형 / 위성 으로 점수가 매겨졌다. 그 다음 질문 — 변형으로 가야 할 항목을 어떻게 개발하는가. PCE는 On-Prem이 아니다. 자유롭게 ABAP을 수정하던 시절의 도구는 일부만 남았다.  PCE 전환 사례에서, CBO 개발 결정이 어떻게 3단계 위계로 정리됐는지 본다. Key User Extension으로 끝내도 되는 경우 가장 안전한 출발점은 가장 가벼운 도구다. PCE에서 새로 추가하거나 변형해야 할 항목을 받으면, 첫 번째 질문은 항상 같다 — 이걸 Key User Extension으로 풀 수 있는가 . Key User Extension은 비개발자(현업 키 유저)가 UI 도구로 필드를 추가하고, 양식을 바꾸고, 작은 룰을 거는 SAP 공식 확장 방식이다. 화면 하나에 필드 두 개 추가, 송장 양식 마스킹 변경, 사용자 정의 데이터 캡처 — 이런 작은 변형 의 대부분은 여기서 끝나야 한다. 이걸 건너뛰는 것 이 흔한 함정이다. 구관(舊官) ABAP 개발자가 보면 Key User Extension은 권한이 부족한 도구 처럼 보인다. 그래서 일단 Embedded Steampunk나 BTP로 직행한다. 결과는 작은 일에 큰 도구 를 쓴 것 — 변경관리도 무거워지고, 운영도 무거워진다. Key User로 끝낼 수 있는 일을 Embedded로 가져가면, SAP 표준 업그레이드마다 회귀 테스트 부담이 따라온다. PCE의 Clean Core 원칙은 여기서 시작된다. Embedded Steampunk가 필요한 경우 표준 동작을 비틀어야 할 때, 같은 시스템 안에서 푸는 옵션. Embedded Steampunk(in-app extensibility)는 PCE 안에서 ABAP for Cloud로 직접 코드를 작성하는 방식이다. 기존 ABAP 개발자가 가장 적응하기 쉬운 영역 — 익...

SAP PCE에서 BTP로 — Clean Core의 두 자리

시즌 1의 1~9편을 한 줄로 압축하면 — Clean Core를 지킨 PCE 환경을 운영에 안착시키는 9개월의 작업 이다. 그러나 같은 원칙이 PCE가 닿지 않는 곳 을 동시에 만든다. 10편은 그 경계가 어디인지, 그 너머에 왜 BTP가 있는지를 정리한다. 시즌 2를 여는 다리다. PCE의 경계 — Clean Core가 만든 닿을 수 없는 곳 Clean Core를 지키는 PCE는 모든 것을 풀지 않는 시스템이다. PCE가 푸는 것은 분명하다 — SAP 표준에 충실한 운영, 분기별 업그레이드와의 호환성, 통합 데이터 모델 위의 안정성. 시즌 1의 9편이 만든 결과물이 그것이다. 그러나 PCE는 의도적으로 풀지 않는 영역이 있다. 회사가 자체 정의하는 데이터 모델, SAP 표준 트랜잭션을 벗어난 화면, 외부 시스템과의 깊은 도메인 통합 — 이런 영역은 PCE 안에서 깨끗하게 작동하지 않는다. 이 영역들을 PCE의 한계 라고 읽으면 시스템과 싸우게 된다. 그러나 같은 영역을 Clean Core가 지킨 결과로 바깥에 남은 자리 라고 읽으면 다음 단계가 보인다. 경계는 결함이 아니라 설계다. 4편에서 Side-by-Side로 옮겨야 하는 경우 를 셋으로 정의했을 때, 이미 그 자리는 PCE 바깥에 존재해야 한다 는 것이 합의된 셈이다. 시즌 1을 마치면 이 경계가 정확히 어디에 그려졌는지 보인다. BTP의 입구 — 별도 시스템이 아니라 역할 분담 BTP는 PCE의 확장팩이 아니라 짝패 다. BTP(Business Technology Platform)를 PCE의 플러그인 으로 받아들이면 BTP의 가치를 절반쯤 놓친다. BTP는 PCE 옆에서 독립적으로 운영되는 별도 클라우드 플랫폼이고, CAP(Cloud Application Programming)·Integration Suite·BTP 위 Steampunk가 그 구성 요소다. 핵심은 기능 이 아니라 역할 분담 이다 — PCE는 SAP 표준을 지키고, BTP는 회사 고유 영역을 자유롭게 푼다. ...