작년 10월 이후로 글을 못 썼는데 어느새 5월이다.

정신없이 살다 보면 시간이 이렇게 흘러가는구나 싶다.

업무에 익숙해지면서 동시에, 내가 모르는 게 뭔지도 더 선명하게 보이기 시작했다. 성장한 건지 더 겸손해진 건지 잘 모르겠다.

둘 다 이길 바랄뿐이다..

작년부터 혼자 공부하는 게 한계가 느껴져서 현직자들을 모집해 CO Study를 시작했다. 구축, PI, 운영 등 다양한 직무의 분들이랑 각자의 Case를 공유하며 공부하다 보니 배울 점이 정말 많았다. SAP Press 책으로 공부하고 Case 공유하는 방식으로 진행했는데, 그렇게 6개월 정도 스터디를 이어갔다. 근데 Press 책 2권 정도를 끝냈을 즈음, 뭔가 계속 채워지지 않는 공백이 느껴지기 시작했다.

첫 번째 공백은 업무 프로세스에 대한 이해였다.

CO는 타 모듈 연계가 필수인데, 특히 PP랑 얽힌 제조원가 쪽에서 고객사 담당자분들이 쓰는 용어가 진짜 다른 세계 언어처럼 느껴질 때가 있었다. 그게 너무 답답해서 솔직히 생산직에서 3개월만 일하고 와야 하나 싶을 정도였다.

시스템 스킬도 물론 중요하지만, 현업의 언어와 비즈니스 프로세스를 모른 채로 미래의 컨설턴트 역할을 제대로 할 수 있을까 하는 의문이 생겼다.

CO는 의사결정을 지원하기 위해 존재하는 시스템인데, 그 의사결정의 배경을 이해하려면 도메인에 대한 학문적인 공부가 먼저라는 생각이 들었다. 그래서 요즘은 SAP CO 자체보다 회계학 공부에 더 비중을 두고 있다.

두 번째 공백은 CO 컨설턴트로서의 경쟁력이었다.

여러 고도화 및 Upgrade 프로젝트에 참여하면서 제조회사 결산 프로세스를 직접 테스트해볼 기회도 생겼고, 담당하는 고객사 중 제조업체도 많다 보니 자연스럽게 제조원가 쪽 업무도 포함이 됐다.

그러면서 여러 CO 프리랜서분들을 만나게 됐는데, 시장에서 CO 컨설턴트를 보는 시선이 크게 둘로 나뉜다는 걸 알게 됐다.

" 제조업을 할 줄 아는 CO 컨설턴트" 와 "제조업을 경험하지 못한 CO 컨설턴트"

내 눈에는 둘 다 20년차 컨설턴트분이셨는데, 시장에서의 인식과 단가가 완전히 달랐다.

제조업을 모르는 CO 컨설턴트는 CO가 아니라 FI라는 식의 냉정하게 이야기하시는 분도 있었다. 

회사에서도 제조 도메인 이해가 깊은 분은 항상 채용이 어렵다는 말도 반복해서 들었고. AI 시대에 경쟁력을 갖추려면 결국 시스템 스킬만으로는 부족하고, 그 스킬이 의미를 가지려면 도메인 이해가 바탕이 되어야 한다는 결론에 이르렀다. 그래서 SCM쪽에 대한 공부를 해야겠다고 마음먹었다.

올해의 첫번째 목표, CPIM 취득하기

그 공백을 채우기 위해 선택한 게 CPIM(Certified in Planning and Inventory Management) 이다.

CPIM이란 생산계획, 수요관리, 재고관리, MRP 등 제조와 공급망 운영 전반을 다루는 국제 자격증인데, SAP ERP랑 내용이 정말 많이 겹친다. 예전에 CKM3님 블로그에서 언급된 걸 봤고, 같이 스터디하던 CO 분도 갖고 계셔서 관심을 갖게 됐다.

근데 선뜻 시작하기가 쉽지 않았다.

응시비만 200만원에, 미국 자격증이기 때문에 교재와 시험이 모두 영어로 되어있다. 

또한, 학원비에, 밥값에 모두 다 합치면 약 300만원의 비용이 들었고, 이게 취득도 아니라 응시까지의 비용이라는 사실에 엄두가 안났다. 

영어에 자신도 없었고 떨어지면 거의 회사에 한 달 무료 봉사한거나 다름 없는 수준이라 작년말부터 계속 고민해왔다. 

그래도 결국 올해 2월부터 학원을 다니기 시작했는데, 돌이켜보면 정말 잘한 선택 중 하나였다. 

단순한 자격증 공부가 아니라, 내가 원하던 현업 업무의 공백을 채워주는 공부였다. 

CPIM을 공부한다는 느낌보다는 SCM의 전반적인 흐름과 PP의 현업 업무를 간접 체험하는 느낌이랄까. 내용이 익숙하면서도 체계적으로 정리되는 그 느낌이 정말 좋았다. 다만 비용이 크다 보니 떨어지면 안 된다는 압박감이 상당했다. 주말은 거의 CPIM에 갖다 바치고, 연차도 5일 정도 쓰면서 3개월간 공부를 했고, 결국 합격했다. 허허..

취득하고 한 달이 지난 지금은 솔직히 감흥이 많이 사라졌다..ㅎ

취득했을 때는 엄청 기뻤는데, 지금은 별 느낌이 없어졌다는 게 웃기기도 하고, 300만원 값어치를 하는지, 이직에 실제로 도움이 될지는 아직 모르겠다. 자격증이란 게 다 이런 건가 싶기도 하고.

그래도 확실히 달라진 게 있다.

얼마 전에 PP Overview 자료를 볼 기회가 있었는데, CPIM에서 배운 개념이랑 용어가 그대로 겹치는 거다. SAP를 개발할 때 CPIM 같은 학문을 참고했다고도 하는데, 공부하면서 "아 그래서 이렇게 설계된 거구나" 싶은 순간이 꽤 많았다. SCM 큰 그림이 머릿속에 들어온 상태에서 보니까, 생산 흐름이랑 각 기능이 왜 존재하는지가 훨씬 자연스럽게 이해됐다.

또한, 소소한 수확도 있다.

PP 컨설턴트 분들이랑 대화할 때, Conveyor System, TPS(Toyota Production System), TOC(병목 이론) 같은 이야기로 스몰 토크가 가능하다. 처음에는 단순하게 스몰토크로 했을 뿐인데, 생각보다 반응이 좋았다.ㅋㅋㅋ

PP 공부한 점에 대해 칭찬도 해주시고 같이 공감할 수 있는 이야기를 가져서 그런 지 조금 더 다르게 봐주신다. 

그 이후로 PP 관련된 모듈을 질문하면 잘 알려주려고 하신다. 이런 소소한 것들에 또 나에게는 힘이 된다. 

"알고 보면 다르게 느껴진다."

CPIM을 통해 가장 크게 얻은 건 이 감각인 것 같다.

이 예시가 와닿을 지는 모르겠지만,

이전에는 일차원적으로 '생산 계획'은 '생산할 제품을 계획하는 것' 이라고 받아들였다면, 

지금은  

재무팀에서는 전년도 사업 계획을 통해, 차기연도에 대한 예산을 짜고,

이 예산을 통해 Demande단(판매, 마케팅, 브랜드)에서 작년도 수요 분석 및 수요 예측를 통해 판매 계획을 짜고,  

S&OP를 통해서 Product Group 기준으로 일원화된 하나의 계획을 가지고,

해당 계획을 End-Item단으로 생산 계획을 하는 것. 

이런식으로 다가오게 되었다. 

시스템을 다루는 사람이 그 배경 개념까지 이해했을 때 생기는 자신감과 시야의 차이는 정말 다르다고 생각한다. 

그게 또한 컨설턴트로서의 자격이라고도 생각한다. 

나에게 300만원을 쓴 게 아깝냐고 물어보면,

전혀 아깝지 않았다고 이야기 할 것 같다.

Obsidian과 Claude, 그리고 AI 시대에 공부하는 방법

작년부터 Obsidian과 Claude를 함께 쓰기 시작했다.

노션보다 가볍고 로컬 기반이라 AI와 연동이 잘 된다는 점이 컸다. 처음엔 VS Code를 통해 Claude와 Obsidian을 연결해서 썼는데, 이제는 Obsidian 자체에 Claude를 붙여서 쓸 수 있게 됐다.

Obsidian은 마크다운 기반이라 AI가 데이터를 읽고 정리하기에 훨씬 유리하다.

내가 주로 쓰는 방식은 두 가지다.

첫 번째는 AI 대화 내용을 기록하는 것이다.

SAP에 대한 모르는 개념이 생기면 Claude한테 물어보고, 그 답변을 Obsidian에 저장한다.

AI가 개념을 도식화해서 정리해준 내용도 그대로 저장되니까, 나만의 SAP 지식 베이스가 조금씩 쌓이는 느낌이다. 실제로 CO 모듈 교육자료를 만들어달라고 했을 때, 개념 설명부터 흐름도까지 꽤 깔끔하게 뽑아줬다. 물론 내용 검증은 필요하겠지만 정말 잘 정리를 해준다.

예를 들어 아래와 같이 VS CODE로 SAP CO 모듈 교육자료를 만들어달라고 요청했다. 

그러면 Claude 는 Obsidian 에 내용을 저장하기 위해서 경로를 확인한다.

자동적으로 경로를 해주지 않기 때문에 '경로를 지정' 해주거나, 아니면 스킬로 만들어서 자동적으로 저장할 수 있게 해줘야 한다. 

아래와 같이 섹션을 나누어, 파일을 구성해주고 나의 Obsidian 에 저장해줬다. 

결과물을 보면, 아래와 같이 도식화를 만들어주고 내용을 정리해준다.  

내용은 검증해야겠지만, 

이런 발전 속도를 볼 때마다 내 수준에서 CO 모듈을 게시글을 작성한다는 게 우숩게 느껴질 뿐이다.

두 번째는 SAP 관련 문서 번역 및 정리다. 

영문으로 된 해외 SAP 문서나 Note를 번역할 때 정말 유용하다.

이미지도 AI가 직접 캡처해서 Obsidian에 저장해주니까, 나중에 한번에 검색해서 찾아볼 수 있다. 내 AI가 Obsidian 데이터도 참조하다 보니, SAP CO 관련 질문에서는 점점 더 맥락 있는 답변이 나오는 것도 체감이 된다.

나 같은 경우는 SAP Note나 Press 내용을 정리해놓는다.  

세번째는 설계 및 개발의 능력이다. 

올해 초에는 AI 덕분에 꽤 인상적인 경험도 했다. 

시니어 프리랜서분이 퇴사하시면서 갑자기 수불부 재설계와 개발을 내가 맡게 된 거다. 이제 2년차가 된 내가... 수불부를 혼자 재설계한다는 건 솔직히 말도 안 되는 상황이었다. 내가 뭘 안다고..

근데 다행히 복잡한 제조원가를 쓰지 않는 고객사였고, Gemini 딥 리서치로 수불부 개념을 여러 번 검증한 뒤 Claude한테 개발을 맡겼다. 큰 틀을 AI가 잡으면 내가 디테일을 수정하는 방식으로 진행했고, 결국 검증까지 완료했다. 기존 프로그램보다 속도도 빨라지고, 놓치던 데이터도 정상적으로 가져오게 됐다.

이 경험을 하면서 AI가 단순히 검색 도구가 아니라 실제 업무의 협업 파트너가 됐다는 걸 실감했다. 실제로 우리 회사 기준으로 봐도, 작년이랑 올해 FCM 쪽 문의 건수를 비교하면 꽤 감소했다. 현업 분들도 AI한테 먼저 물어보기 시작한 거다. 나만 해도 AI 없이는 불편할 정도까지 왔으니까.

근데 솔직히 이 부분에서 불편한 생각도 든다. 예전에는 모르는 게 있으면 찾아보고, Obsidian에 기록하고, 내 것으로 만드는 과정이 있었다. 요즘은 그냥 AI한테 물어보고 끝낸다. 나중에 기억 안 나면 또 물어보면 되니까. 편하긴 한데, 이게 반복되다 보면 내 머릿속에 남는 게 없어지는 거 아닌가 싶다. AI한테 잠식당하는 느낌이랄까.

그래서 요즘은 의식적으로 균형을 잡으려 한다. AI를 도구로 쓰되, 내 언어로 다시 정리하고 저장하는 과정을 의도적으로 만드는 것. Obsidian을 계속 쓰는 이유도 그거다. 완벽하게 지키진 못하지만, 그게 지금 내가 생각하는 AI 시대의 공부법이다.

이것저것 쓰다 보니 꽤 길어졌는데, 돌아보면 결국 하나의 흐름으로 이어지는 것 같다.

뭔가 채워지지 않는 공백을 느끼고, 그 공백을 채우기 위해 방향을 찾고, 또 새로운 고민이 생기고. 주니어는 이런 거구나 싶다.

완성된 이야기는 아니지만, 비슷한 고민을 하고 있는 분들한테 조금이라도 공감이 됐으면 한다.

내가 Joule을 처음 알게된 건 아마 23년도 11월 쯤이였던 것 같다. 

SAP라는 직무를 새로 알게 되고 조사하는 과정에서 Joule을 알게 되었다. 

그때의 나는 SYNC Academy 자기소개서와 면접에서도 Joule을 언급하며
“남들보다 관심이 있다”는 마음을 어필을 했었다.  

그렇게 시간이 지나 지금은 얼떨결에 동료들과 Joule 스터디를 하고 있다. .
덕분에 Joule을 조사하고, SAP Now 행사에도 참석하고,
웨비나와 관련 교육을 통해 직접 사용해보며 나름대로 공부할 기회가 생겼다.

내가 느낀 건, 달이 바뀔 때마다 Joule의 성장 속도가 눈에 띄게 빨라지고 있다는 것이다.
하지만 아직도 주변만 봐도 Joule이 정확히 어떤 것인지 모르는 경우가 많다

그래서 이번 기회에, Joule에 대해 내가 이해한 내용을

블로그에 한 번 정리해보면 좋겠다는 생각이 들었다.

Joule은 SAP를 하는 사람이라면 한 번쯤 들어봤을 이름이다.
간단히 말하면, 'SAP 버전의 ChatGPT'라고 할 수 있다.

그렇다면 이 녀석은 SAP 안에서 어떤 역할을 하려는 것일까?

1) Joule의 탄생 배경 

Joule은 과거 S/4HANA의 탄생처럼, SAP에 또 한 번의 혁신을 불러올 매개체다.

잠깐 S/4HANA의 배경을 이야기해보자. (이 부분은 추후 별도의 글로 자세히 다룰 예정이다.)
과거 SAP는 Oracle, Microsoft 등의 데이터베이스를 라이선스를 지불하고 사용하고 있었다.

하지만 다음과 같은 한계가 있었다.

1. 타사 데이터베이스에 대한 의존성으로 인해 SAP의 기술 정책이나 업그레이드 방향이 제약을 받았고,
2. 비용과 라이선스 문제가 지속적으로 부담이 되었으며,
3. 오류나 장애 발생 시 즉각적인 대응이 어렵고,
4. 데이터 볼륨 증가로 실시간 분석의 한계가 발생했다.

이러한 문제를 해결하기 위해 SAP는 자체 데이터베이스 개발 프로젝트를 시작했다.
세계 유수의 대학 연구팀들과 협력했고,

그 과정에서 서울대학교 연구진이 핵심 기술인 컬럼 기반 저장(Column-Based Storage)을 개발했다.

이 기술이 바로 S/4HANA의 근간이 되었다.

그 결과 SAP는 독자적인 기술력으로 성장하며, 독일 시가총액 1위 기업으로 올라섰다.

하지만 어느 순간, 클라우드의 시대가 도래했다.
Amazon, Microsoft, Google 등 글로벌 기업들이 클라우드 사업을 확장하면서

IT 시장의 패러다임이 완전히 바뀌었다.

물론 SAP도 이에 대응해 퍼블릭 클라우드와 BTP(Business Technology Platform)를 내세우며

클라우드 중심의 전략을 발표했다.

하지만 시장의 반응은 예상보다 저조했다.
이미 클라우드 시장을 선점한 Amazon, Microsoft, Google 등에 비해

SAP의 존재감은 상대적으로 미미했다.

그러던 중 OpenAI의 ChatGPT가 등장하며, 세상은 본격적인 AI의 시대로 진입했다.

사람들은 처음엔 “AI가 사람을 대체할 수는 없을 것”이라 생각했지만,
그 발전 속도는 눈으로 체감될 만큼 빨랐다.

AI는 이제 그림을 그리고, 이미지를 생성하고, 심지어 코드를 작성하기까지 한다.

결국 대부분의 기업들은 같은 질문을 던지기 시작했다.

“근로자와 AI, 누구의 비용이 더 저렴할까? 업무 효율이 증대될까?”

그렇게 많은 기업들이 업무 효율과 기술력을 목표로 자사 AI를 만들기 시작했다.
내부 문서와 정책을 학습시키고, 임직원이 이를 사용하면서 데이터가 축적되었다.

하지만 이 과정에서 가장 큰 난제가 있었다.
바로 ERP 데이터에 접근하기 어려웠다는 점이다.

SAP는 이 문제를 누구보다 빠르게 포착했다.
그리고 세상이 AI에 대한 기대와 혼란으로 들끓을 때,
SAP는 Joule을 세상에 공개했다.

AI를 제대로 활용하기 위한 최적의 환경은 클라우드다.
AI는 방대한 데이터를 빠르게 처리하고 학습해야 하기 때문에,
유연한 확장성과 통합 환경을 제공하는 클라우드 인프라가 필수적이다.

SAP 역시 이 점을 간파했다.
Joule을 통해 AI와 ERP를 긴밀하게 연결함으로써,
그동안 상대적으로 반응이 미미했던 Cloud 및 BTP 제품군을

확산시킬 수 있는 절호의 기회를 만들어낸 것이다.

AI를 단순한 기능이 아닌, SAP 비즈니스 생태계 전체를 재활성화할 핵심 동력으로 삼은 것이다.
결국 Joule은 SAP에게 클라우드와 AI를 동시에 강화할 수 있는 전략적 전환점이 되었다.

이러한 흐름 속에서 SAP는 유럽 시가총액 1위 기업의 자리로 올라갔다. 

2) SAP의 Joule의 종류와 방향성 

Joule의 방향성과 종류는 많은 사람들이 헷갈려 하는 주제다.
그럴 만하다.

올여름, SAP 관계자분과 직접 이야기를 나눌 기회가 있었다.
그 자리에서 물었다.
“Joule은 세미나마다 내용이 바뀌고, 정책도 계속 바뀌는데 도대체 방향성이 뭐냐”고.

놀랍게도 돌아온 대답은 이랬다.
“SAP 안에서도 그걸 정확히 아는 사람이 없다.”
심지어 SAP 독일 본사조차 명확한 답을 내리지 못한다고 했다.

그 이유는 간단하다.
지금은 너무 빠른 변화의 시대이고, Joule 역시 AI 학습과 피드백 속도에 따라 계속 진화하고 있기 때문이다.

예를 들어 Joule for Developer(J4D)만 봐도 그렇다.

올해 출시 예정이었다가 내년 4분기로 연기되었다. (현재는 TEST 버전만 사용 가능하다.)
나도 SAP Now 행사 때는 이미 출시된 줄 알았다.

그만큼 정책이 빠르게 바뀌고 피드백을 보완하는 과정에서 변화가 많기 때문에,
SAP 커뮤니티나 세미나 내용을 꾸준히 찾아보지 않으면 놓치기 쉽다.

따라서 Joule의 관심이 있거나 공부하는 사람이라면 커뮤니티를 통해 정보를 지속적으로 확인하는 게 중요하다.

Joule의 종류 

현재 공개된 Joule의 종류는 크게 네 가지로 나눌 수 있다.

1) Joule 

- User: 일반 SAP 사용자

가장 기본적인 Joule은 'SAP 버전의 CRUD가 가능한 ChatGPT'라고 이해하면 쉽다.

사용자가 Joule에게 “판매오더를 수정해줘”, “배송지를 바꿔줘”라고 요청하면,
Joule은 단순히 정보를 알려주는 수준을 넘어 실제 데이터를 CRUD(Create, Read, Update, Delete)까지 수행한다.

즉, Joule의 핵심은 단순 대화형 AI가 아니라,
ERP 데이터를 실시간으로 조작할 수 있는 업무형 AI Copilot이라는 점이다.

다만 Joule을 온전히 활용하려면 Clean Core 전환 과정이 필수다.
(이 부분은 다음 편에서 자세히 다루겠다.)

2) Joule Studio in SAP Build(소위 Custom Joule) 

- User: SAP 사용자 및 관리자

Joule Studio는 쉽게 말해 Custom Joule이다.
Joule이 '스탠다드 프로그램'이라면, Joule Studio는 'CBO'와 비슷한 개념이다.

핵심 변화는 두 가지다.

1. 전문적인 Agent AI와 협업 

Joule AI Agent라는 중앙 코파일럿이

Supply Chain Agent, Finance Agent, Analytics Agent 등 다양한 전문 Agent들과 협업한다.

예를 들어 사용자가 재무 데이터를 묻는다면,
Joule AI Agent → Finance Agent로 질의가 전달된다.
Finance Agent는 자신이 학습한 데이터를 기반으로 답변을 준비하고,
다시 Joule AI Agent로 전달된다.
마지막으로 Joule이 한 번 더 검증해 할루시네이션(Hallucination)을 줄인 뒤 사용자에게 답변한다.

또한, 추후의 Agent를 사내 AI 또는 Chat Gpt와 연동해서 함께 사용할 수 있도록 

이미 설계가 되어있고, Open AI 등과 협력해서 진행하고 있다. 

“그렇다면 기업의 중요 데이터가 ChatGPT에 학습되는 것 아니냐?”라는 우려가 있을 수도 있다.

하지만, SAP는 이미  ERP의 데이터는 학습하지 않도록 Open AI와 MOU체결해 보안 이슈를 통제하였다. 

2. AI의 데이터 처리 과정을 직접 설계 

또 하나 흥미로운 점은 SAP Build를 통해 Joule의 행동 과정을 직접 설계할 수 있다는 것이다.

아직 웨비나 등에서 상세히 공개되진 않았지만,
올해 말쯤 출시 예정이라고 한다.

예를 들어,
‘사업계획 관련 질문 → A 테이블 조회 → B 테이블 비교 → 결과 요약’
이런 식으로 AI의 행동 플로우를 직접 정의할 수 있다.

향후에는 이 기능이 운영 직무의 일부로 흡수되거나, 새로운 AI 직무로 발전할 것 같다. 

3) Joule For Developer(J4D) & 4)Joule For Consultant(J4C)

이 두 가지는 묶어서 설명하는 게 편할 것 같다. 

내 개인적인 생각으로는 SAP의 매출 구조를 고려한 전략적인 제품군이라고 본다.

이름 그대로 J4D는 개발자용, J4C는 컨설턴트용 Joule이다.

많은 사람들이 “이제 AI가 개발자와 컨설턴트를 대체하는 거냐”고 묻지만,
SAP는 분명히 말한다.

“Joule For Developers 와 Joule For Consultants는 대체가 아니라 보조 수단이다.”

첨고 링크 참고

https://www.infoworld.com/article/3849011/sap-introduces-joule-for-developers.html?utm_source=chatgpt.com

즉, 프로젝트 ROI를 악화시키는 높은 인건비와 한정된 인력 문제를 보완하기 위한 도구로 나온 것이다.
SAP 컨설턴트 단가 상승 → 인력 최소화 → 품질 저하 → ROI 악화의 악순환을
J4D/J4C를 통해 끊겠다는 전략이다.

게다가 AI 유닛 과금 모델을 통해 SI 파트너사에게 새로운 매출을 뽑아낼 수 있다. 

역시 그들은 똑똑하다.. 

J4D와 J4C의 한 가지 오해를 풀자면, 현재까지는 Classic ABAP 관련 분석은 J4C가 더 뛰어나다.

SAP Joule의 방향성 - 플라이휠(Flywheel)

SAP 세미나에 가면 본사 임원들이 자주 언급하는 단어가 있다.

바로 플라이휠(Flywheel),
정확히는 아마존 플라이휠(Amazon Flywheel)이다.

플라이휠은 한쪽 방향으로 회전시키면 관성으로 계속 돌며 에너지를 축적하는 구조다.
아마존은 이 원리를 비즈니스에 적용해, 지속적인 성장의 선순환 구조를 만들었고 세계적인 이커머스 기업이 되었다. 

[아마존 플라이휠 과정] 

1. 최저가를 실현한다.

2. 고객 경험이 향상된다.

3. (더 많은) 트래픽이 생긴다.

4. (더 많은) 판매자가 모인다.

5. (더 많은) 상품 구성이 발생한다.

6. 비용 구조를 낮춘다.

7. (다시) 최저가를 실현한다.

SAP는 이 구조를 Joule에 그대로 적용하고 있다.

AI는 많은 사용자와 데이터가 모일수록 더 정교해지고 정확도도 높아진다.
따라서 SAP는 Joule을 TEST 버전으로 널리 배포하며,
트래픽 → 사용자 경험 → 피드백 → 개선 → 다시 확산으로 이어지는
플라이휠 효과(Flywheel Effect)를 만들려 하고 있다.

정책은 아직도 자주 바뀌고 있다.
SAP 내부에서도 방향을 실험하고 있는 단계다.

예를 들어 초기에는
“Joule은 SAP S/4HANA Cloud PCE 2023 FPS01 이상 버전에서만 사용 가능” 이라고 명시했지만,
현재는 2021년 이상 버전도 설치 가능하게 바뀌었다.
다만 일부 기능은 제한된다.

링크 참고

https://help.sap.com/docs/joule/capabilities-guide/release-specific-capabilities?locale=en-US

이처럼 SAP도 지금, 변화의 한가운데에 서 있다.

3) 결론

나는 Joule이 우리가 생각했던 것보다 훨씬 빠른 속도로 확산될 것이라고 본다.

하지만 Joule의 성능을 제대로 활용하기 위해서는
반드시 Clean Core와 Cloud이라는 두 가지 전제 조건이 필요하다.
(이 내용은 다음 편에서 자세히 다루겠다.)

그리고 S/4HANA가 2040년 이후 지원이 종료되기 때문에 
결국 SAP를 계속 사용하려면 Cloud 전환은 피할 수 없는 선택이 된다

아래 링크 참고(S/4HANA 2040년 이후 지원이 종료)

https://news.sap.com/2020/02/sap-s4hana-transition-updated-policy/?utm_source=chatgpt.com

앞으로는 “Cloud로 갈까, 말까?”의 싸움이 아니라, “SAP를 계속 사용할까, 말까?”의 싸움이 될 것이다.

사용을 선택한 기업은 결국 Cloud로 이동할 것이고, 그렇지 않은 기업은 떠날 것이다.

그리고 언젠가 어느 대기업이 Joule의 압도적인 퍼포먼스를 입증한다면,
다른 기업들도 비용을 감수하고라도 전환할 것이라 생각한다.

그렇다면 우리의 일자리는 사라질까?
그건 정말 모르겠다.
일자리가 사라질지, 새로운 역할이 생길지는 아무도 모른다.

하지만 한 가지는 분명하다.
변화를 모른 채 살아가는 것은 도태를 부르고,
변화를 이해한 채 살아가는 것은 혁신을 이끈다.

미래를 예측할 순 없어도,

변화를 이해하려는 사람만이 방향을 잡을 수 있다.

결국, 아는 사람만이 준비된 사람이다.

안녕하세요.

블로그를 마지막으로 작성한 게 4월이고, 어느새 10월이 되어 6개월이라는 시간이 흘렀습니다.

저는 정리하고 글 쓰는 것을 좋아합니다.(물론 잘 쓰지는 못합니다. ㅠ)
예전부터 블로그를 만들어보고 싶다는 목표가 있었는데, SAP라는 직무를 만나면서 자연스럽게 작성할 기회를 얻게 되었습니다.

생각보다 많은 분들이 매일 방문해주셔서 놀랍고 감사할 따름입니다.

그래서 한 편의 글을 쓰더라도 어떤 소재를, 어떻게 풀어갈지, 혹시 잘못된 정보는 아닐지를 늘 고민하게 되더군요.
그렇게 시간을 들이다 보니 글을 완성하기까지 생각보다 오래 걸렸습니다.
주말에 날 잡아서 써야지 하다가도 업무에 쫓기고, CO 모듈을 공부하느라 미뤄졌습니다.

다시 마음을 잡고 꾸준히 작성해보려고 합니다

이제는 완벽하게 쓰려 하기보다, 제가 배우고 느낀 걸 솔직히 남기는 방향으로도 많이 의견을 공유해보려고 합니다. 

어느덧 SAP 업계에 첫 1년차가 마무리되가고 있습니다. 

아직도 너무나 부족하지만, 그동안의 FI와 CO를 경험한 이야기를 해보려고 합니다. 

# FI에서 CO로 직무 변경

저는 초기에 FI 와 CO 모듈을 경험할 수 있는 좋은 기회가 있었습니다. 

운 좋게 선택권이 있었고, 제 상황에서는 CO가 더 매력적인 영역이라고 판단되어 옮겼습니다.
그래서 따지고 보면 CO는 이제 반년도 채 안 되었습니다.

비록 ‘찍먹’ 수준의 경험일지라도,
제가 실무에서 직접 느낀 FI와 CO의 차이, 그리고 그 속에서 배운 점들을 나누고 싶습니다.
이론적인 설명보다는 1년차의 눈으로 본 실무 체감에 가깝습니다.

혹시 지금 FI와 CO 중 어느 모듈을 선택할지 고민 중인 분이라면 이 글이 조금이나마 도움이 되길 바랍니다.

 "FI와 CO 중에 뭐가 좋아요? 

SAP를 공부하거나 이제 막 취업을 준비하는 분들이
가장 많이 하는 질문 중 하나입니다.

저도 처음엔 이 질문이 궁금했습니다.

어떤 모듈이 더 유망한지, 더 오래갈 수 있는 커리어인지,
혹은 연봉 차이가 있는지 많이 찾아봤던 기억이 납니다.

하지만 실제로 SAP 직무에서 일해보니,
돈이나 커리어로 단순 비교하는 건 큰 의미가 없더라는 걸 느꼈습니다.

케이스 바이 케이스고, 환경과 역할, 프로젝트에 따라 너무 달라지니까요.

무엇보다 제가 경험하지 못한 영역이 많고,

그 안에는 제 주관이 섞일 수밖에 없습니다.

그래서 이번에는 그런 비교 대신,
제가 운영업무를 직접 경험하면서 느낀 체감적인 차이를 비유로 이야기해보려 합니다.

* 운영 업무 기준의 차이이며, 주관적인 의견입니다. 

1)  운영 업무의 차이 – 잽 vs 카운터

FI는 잦은 요청과 반복적인 업무가 중심입니다.
작은 오류 하나, 계정 하나 등 사소한 하나라도 바로 확인하고 수정해야 합니다.

업무의 단위는 작지만, 빈도와 속도가 높죠.
그래서 마치 끊임없이 잽을 맞는 느낌입니다.

짧은 시간 안에 빠르게 문제를 파악하고, 정확히 타격해야 합니다.

CO는 반대입니다.
요청이 자주 들어오지는 않지만, 한 번 들어오면 규모가 큽니다.
하나의 SR을 처리하더라도 원가 배부 구조, 타 모듈 데이터 흐름, 손익 집계까지 함께 확인해야 합니다.

그래서 CO는 카운터 한 방이 맞은 느낌에 가깝습니다.
한 번의 문제를 해결하기 위해 여기저기를 찾아보며 분석해야 합니다.

FI는 매일 여러 건을 처리하며 경험을 쌓는 모듈이라면,
CO는 한 건을 깊게 파면서 이해가 중요한 모듈입니다.

2) 데이터의 흐름 차이 - 이비인후과 의사 vs 외과 의사

FI는 이비인후과 의사에 가깝습니다.
사람들이 자주 찾고, 증상이 명확하며, 케이스가 많습니다.

전표 오류나 결산 조정처럼 비교적 표준화된 업무를 자주 접하기 때문에

짧은 시간 안에 여러 경험을 쌓고 빠르게 성장할 수 있습니다.

그래서 FI는 단기간에 실력을 쌓기 쉽고, 성취감도 빠르게 느낄 수 있는 모듈입니다.

하지만 경쟁이 치열합니다.

FI 업무는 범용적이어서, 실력자도 많고 이직 장벽도 낮습니다.
즉, 배우기 쉽지만 차별화하기는 어렵습니다.

반면 CO는 외과 의사와 같습니다.
수술을 하기 위해서는 몸 전체의 구조를 이해해야 하듯,
CO는 하나의 데이터를 보기 위해 FI, MM, PP, SD 등 다른 모듈의 흐름까지 함께 이해해야 합니다.

단순히 한 화면을 보는 게 아니라, “이 금액이 어디서 발생했고, 어떤 로직을 거쳐 어디로 흘러가는가”를 끝까지 추적해야 하죠.

그래서 CO는 단기간에 성장하기 어렵습니다.

하지만 한 번 이해하면, 그 이해를 바탕으로 새로운 이해(?)를 할 수 있습니다. 
많은 경험이 곧 실력으로 이어지는 영역이고, 그만큼 경력직 공고에서도 원하는 연차가 높습니다.
CO는 경험의 깊이와 논리의 정확성이 실력을 결정짓는 모듈입니다.

3) 성장의 방향 – 결과의 언어 vs 이유의 언어

'만약에 어떤 모듈을 하고 싶은지?'가 고민이라면 아래의 내용을 생각해보면 좋을 것 같습니다. 

FI는 눈앞의 증상을 빠르게 진단하고 해결하는 영역이라면,

CO는 몸속의 구조를 열어보고 원인을 찾아내는 영역에 가깝습니다.

그래서 FI는 단기간에 실력을 쌓기 쉽고, 결과가 즉각적으로 숫자로 드러나기 때문에 “이해했다”는 확신이 빠르게 쌓입니다.
또한 전표 구조나 계정 로직이 비교적 표준화되어 있어서, 어느 회사를 가든 익숙한 패턴으로 일할 수 있는 장점이 있습니다.

반면 CO는 하나의 결과를 얻기 위해 수많은 단계를 거쳐야 합니다.

CO는 "금액이 안맞는다."라는 요청이 많습니다.

정확하게는 "타 모듈과 금액이 안맞는다." 라는 표현이 맞을 것 같습니다.  

CO는 데이터를 생성하지 않고, 타모듈의 데이터를 받아 가공하는 모듈입니다.  

데이터의 흐름을 따라가다 보면 SD, MM, PP, FI 등 다른 모듈의 데이터와 맞물리게 되어있습니다. 

그래서 CO는 단순히 ‘깊은 모듈’이 아니라, 넓고 깊은 모듈입니다.

CO는 회사마다 프로세스가 완전히 다릅니다.
배부 기준, 원가 구조, 수익성 분석 단위, 내부거래 처리 방식까지 기업의 철학과 조직 구조에 따라 달라집니다.

결국 CO를 이해한다는 건, 그 회사가 비용과 수익을 어떻게 바라보는가를 이해하는 일입니다.

시스템 안에서 숫자를 맞추는 게 아니라, 그 숫자가 만들어지는 '이유'를 찾는 과정입니다. 

이게 CO가 어려운 이유이자 매력이라고 생각합니다.

# 그래서 저는 CO를 선택했습니다. 

FI는 명확함 속에서 빠르게 성장한다면,

CO는 복잡함 속에서 넓고 깊게 성장합니다.

FI가 ‘결과의 언어’를 다룬다면,

CO는 ‘이유의 언어’를 다룹니다.

FI에서 수치를 맞춰가는 재미가 있다면, 

CO에서는 그 수치가 만들어지는 흐름과 논리를 쫓는 재미가 있습니다.

저는 CO가 너무 어렵습니다. 
아무리 공부해도 이해되지 않는 부분이 많고,
테이블 구조는 복잡하며,
이해했다고 생각한 순간 또다시 새로운 벽이 나타납니다.

그럼에도 불구하고,
하나씩 이해할 때마다 느껴지는 성취감은
다른 어떤 모듈에서도 얻기 힘든 특유의 재미가 있습니다.

CO를 추천하냐고 묻는다면,
저는 주저 없이 추천합니다.
단, 각오는 단단히 하셔야 합니다.

CO는 내 지식의 깊이만큼 성장할 수 있는 모듈입니다.
내가 가진 이해의 한계가 곧 시스템을 해석할 수 있는 한계가 됩니다.

그래서 CO를 다루는 사람은
항상 배움의 자세와 탐구의 자세를 유지해야 합니다.

* 해당 카테고리와 글들은 제가 그저 운좋게 먼저 시작한 입장으로써, 누군가에게 도움이 되기를 바라며 제 경험을 작성을 합니다. 

나는 SAP Korea에서 주관하는 SYNC 교육과정를 수료했다.  

요즘 SAP 커뮤니티나 카카오톡 채팅방을 보면,
"SAP 하고 싶은데 취업 잘 되나요?", "간절한데 취직하고 싶어요.", "진입 방법 알려주세요."  이런 질문들이 자주 올라온다.

그런 질문들을 볼 때면, 한때의 내 모습이 떠오르고, 요즘 시장 상황에 대해 착잡한 마음이 든다.

같은 SYNC 동기 중에서도, 나보다 훨씬 뛰어난 사람들도 취업에 어려움을 겪는 모습을 보며 현실의 냉혹함을 느끼기도 한다.

채팅방에는 많은 사람들이 SAP에 대한 꿈을 이야기하지만,

SYNC 교육 종료와 취업 시장 불황이라는 현실 앞에서 두려움을 느끼고 있다는 사실을 알게 되었다.

그래서 조금이나마 도움이 될까 싶어 이렇게 글을 작성하게 되었다.
(물론, 이 글을 볼 지 모르겠지만…)

나는 그저 운 좋게 먼저 시작한 입장이고, 대단한 사람은 아니다.
내가 겪었던 시행착오와 고민, 진로에 대해 글로 정리해 공유하면 누군가에게 도움이 될지도 모른다고 생각했다.

물론, 어떤 사람은 "너가 뭔데! 신입 주제에!" 라고 생각할 수도 있다.

그런 사람들에게 당당히 이야기할 수 있는 것은, 나는 SAP에 진입하기 위해 정말 간절하게 살았다는 것이다.

이 한마디만큼은 누구보다 자신 있게 말할 수 있다.

그래서 내 이야기를 공유해보려고 한다.

2023년 9월,

나는 한 책을 통해 SAP라는 직군을 알게되었지만, 진입 방법에 대한 정보가 없어서 크게 좌절했었다.

그러다가 SAP Joy 커뮤니티를 찾게 되었고, 무작정 오픈 채팅방에 현직자와 만나고 싶다는 장문의 글을 남겼다. 

감사하게도 많은 분들이 연락을 주셨고, 직접 찾아뵈며 많은 정보를 얻을 수 있었다.

정말 귀찮아할 법도 한데, 

나를 단순한 취업 준비생으로 보지 않고,
SAP에서 함께 일할 후배, 동료로 바라봐 주며 조언해주는 모습에 큰 동기부여를 받았다.

그때 받은 것만큼, 나도 누군가에게 도움이 되고 싶어 글을 작성하게 되었다.

다행히 요즘은 구글링만 해도 SAP 진입 방법이 잘 나오고,
단톡방 인원도 내가 들어갔을 때 400명에서 지금은 1500명으로 늘었다.

그만큼 많은 사람들이 관심을 가지게 된 것 같다.

2023년 10월,

현직자 분들을 통해 Easy ABAP과 SYNC 교육과정을 알게되었다.

이미 SYNC는 지원이 끝났었고 어쩔 수 없이 다음 기수를 기달려야 했다. 

인터넷으로 Easy ABAP 2.0 책을 구매했었다. 

책을 주문했을 때 가격을 보고 놀랐고, 배송을 받았을 때 두께를 보고 놀랐다. 

무작정 첫 페이지부터 읽기 시작했지만, 하나도 이해가 되지 않았다.

CTS는 무슨 말인지, 패키지는 뭔지, 오브젝트, 타입 p, f, t 등 비전공자인 나에게는 정말 너무 어려웠다.  

어떻게든 꾸역 꾸역 읽어봤지만, 다음 날 책을 다시 펼치면 또 새로운 책처럼 느껴졌다. 

IT 기초가 부족하다고 생각이 들어 자격증 공부를 시작했다. 

2024년 1월,

나는 SQLD와 정보처리기사 공부를 시작했다.

정보처리기사는 양이 너무 많았다.

비전공자인 나에게는 정말 쉽지 않은 도전이었다. 평일에는 직장 마치고 공부했고, 주말에도 꾸준히 공부했다.

어느 정도로 했냐면, "떨어지면 IT쪽에는 소질이 없는 거야."라고 생각할 정도로 열심히 했다.

그리고 1회차 시험에 SQLD와 정보처리기사를 모두 합격했다.

정말 뿌듯했고, 값진 노력의 결과였다.

2024년 4월,

그 이후, Easy ABAP을 다시 펼쳤다. 

하지만 여전히 CTS와 패키지는 이해하기 어려웠고 눈으로만 공부하는 데 한계를 크게 느꼈다.

그래서 실습을 위해 SAP Developer Trial 서버를 설치하기로 마음먹었다. 하루 종일 구글링하며 여러 블로그를 따라 했지만 번번이 실패했다. 1주일 동안 반복한 끝에, 여러 블로그를 참고해 드디어 설치에 성공했다.

이 과정에서 사소한(?) 에피소드가 있었다.

리눅스 오픈수세 위에 SAP를 설치하는 과정에서 명령어 입력 부분이 있었는데, 블로그에 'ls'라고 입력하라고 되어 있었다.

하지만 분명히 똑같이 'ls'를 입력했지만 설치가 되지 않았다. 

그렇게만 이틀 째 고생하다가 도저히 안될 것 같아 SAP Joy 단톡방에 구원을 요청했다.

20분동안 뜨거운 논쟁이 펼쳐졌지만, 아무도 해결 방법을 찾지 못했다. 

포기를 해야 하나 싶은 순간에  "혹시 저거 LS인데 IS로 쓰신거 아니에요?" 라고 한분이 대답하셨다. 

알고보니 내가 'is'로 잘못 입력했던 것이다.(소문자 l과 대문자 I를 헷갈렸다...)

그때 정말 여러분들에게 많이 혼났고, IT 기초 공부의 중요성을 절실히 깨달았다. 

그런 나를 가엾게 보신 건지, 비전공자의 현실을 이해해 주신 건지,

Easy ABAP의 저자이자 단톡방 방장님께서 Trial 서버 설치 과정을 공유해달라는 기회를 주셨다. 

그렇게 나의 첫 블로그, 첫 포스팅이 탄생했다. 

2024년 7월,

나는 기술 면접과 인성 면접을 모두 합격하고 SYNC 교육 과정에 참여하게 되었다. (진짜 떨어질까봐 무서웠다...)

간절히 원했던 만큼, 내 기준에서 할 수 있는 것은 다 했다.

매번 남아서 자습을 하고, 모듈 공부도 틈틈이 했다.

나보다 뛰어난 친구들만 있어서, 그렇게라도 해야 회사가 나를 뽑아줄 것 같았다.

당연히 힘들었지만, 그 과정이 너무 즐겁고 재미있었다.

소중한 사람들을 많이 만났고, 후회 없는 시간이었다.

여름에는 청계천에서 돗자리를 펴고 피자를 먹기도 하고, 등산을 가기도 했다. 

겨울에는 다 같이 스키장에 놀러 가기도하고, 바다를 보러 가기도 했다. 

그렇게 즐겨서 그런건지, 좋은 사람들을 만나서 그런건지,

수료식 때 과분할 정도로 많은 상을 받았다.

정말 운이 좋았던 것 같다.

수료식 이후 어느 날,

보드게임을 하다가 "인생에서 가장 잘했다고 생각하는 행동이 무엇인가요?"라는 질문 카드에 대한 답을 동기가 하게 되었다.

한참 고민한 끝에, 동기는 "씽크를 들은 일"이라고 말했다. (자기 인생이 씽크를 듣기 전과 후로 나뉜다던가...뭐라나..)

지금 생각하면 되게 오글거리지만, 그때는 모두 공감을 했었다. 

누군가는 "단순한 교육인데 그 정도야?" 라고 생각할 수도 있다.

우리는 매일 남아서 공부도 하고, 볼링도 치고, 보드게임도 즐기고,

또 함께 여행을 다니며, 많은 추억을 만들어갔다. 

그래서인지, 6개월이라는 짧은 시간이었지만,
마치 학창시절 한 시절을 함께 보낸 것 같은 느낌이었다.

그리고 그 날,
기다리고 기다리던 채용 합격 문자를 받게 되었다.

마지막으로, 

처음에는 이 글을 쓸까 말까 고민했다.

요즘은 SAP 진입 방법만 검색해도 수많은 블로그가 나오기 때문이다.
'내 글이 굳이 도움이 될까?' 라는 생각도 들었다.

하지만 누군가에게는 여전히 도움이 필요할 수도 있겠다는 생각이 들었다.
그리고 나를 도와준 분들에 대한 보답으로, 나도 누군가에게 도움이 되고 싶었다.

이 글을 읽고 'SAP에 진입하려면 이정도로 열심히 노력해라' 라는 의미로 해석이 되어,

오히려 진입 장벽이 더 높다고 생각이 드는 사람이 있을까 걱정이 되기도 한다. 

그런 의미로 쓴 것이 아니다.

나도 많이 부족했고, 생각보다 그렇게 열심히 살지도 않았다.

다만, 아무것도 없던 사람도 할 수 있었다.
취업 시장이 어떻든, 본인이 하고 싶으면, 해.
그런 메시지를 전하고 싶었다.

나는 '노력하는 사람이 바보가 되는 세상'을 싫어한다.(왜냐하면 내가 노력파니까...ㅠ)

취업이 어렵고, 시장이 안 좋다고 해도,
본인이 하고 싶은 이유가 명확하다면 해야 한다.

그래야 후회가 없다.

나도 늦은 나이에 1년이라는 시간을 투자했지만,
절대 후회하지 않는 시기였고, 지금도 정말 행복하다.

앞으로도 취업, 진로, SAP 관련해서 도움이 될 만한 내용을 틈틈이 올릴 예정이다.

궁금한 점이나 원하는 포스팅 주제는 댓글로 편하게 남겨도 된다.

그러니, 포기하지 말자.

SAP의 장점 중 하나는 데이터의 신뢰성이다.

데이터를 추가,수정,삭제를 하면 일반적으로 로그가 남고, 이러한 이력들은 나중에 감사자료에 사용이 된다.

이런 철저한(?) 시스템 때문에 SAP를 사용하는 회사의 재무제표는 신뢰도가 높다.

SAP는 원칙적으로 데이터(특히, 운영서버)를 삭제하지 말라고 한다. 

하지만 프로젝트나 운영업무를 하다보면 데이터를 삭제해야 하는 경우가 생긴다. 그럴 때 SE16N EDIT 모드 등을 사용하여 데이터를 삭제한다. (회바회, 케바케)

데이터를 삭제하는 방법들 중에 어떤 것들은 변경 로그를 남기고 어떤 것들은 변경 로그를 남기지 않는다.

이게 나중에 감사에서 큰 이슈( 재무제표 조작가능성 의심 등)가 된다. 특히, 현업이 운영서버에서 직접 데이터를 수정 / 삭제 하는 것은 정말 큰일이기 때문에 외주사에 데이터 삭제를 요청하거나 증빙을 남긴다. (회바회, 케바케)

오늘은 그런 어쩔 수 없는 상황에서 데이터를 삭제하려고 할 때, 하는 방법에 대해서 정리했다.

여러가지 방법들 중에 많이 사용하는 방법은 3가지이다.

1. &SAP_EDIT
2. SE16N 디버깅으로 편집모드 접속
3. CALL FUNCTION SE16N_INTERFACE 사용

하나씩 살펴보자.

1. &SAP_EDIT (S/4HANA 불가)

T-CODE: SE16N 에 접속해 테이블 명을 검색한다.

좌측 상단에 &SAP_EDIT을 입력 후, ENTER를 누르면 우측의 엔트리 유지보수에 체크표시가 생긴다.

만약에 아무 반응이 없거나 권한 에러가 뜬다면, 그것은 S/4HANA를 사용해서 생기는 문제이다.

실제로 노츠에서 찾아볼 수 있는데 S/4HANA 이후로 데이터의 정합성을 유지하기 위해서 “&SAP_EDIT”를 활용하여 데이터를 수정하는 부분을 비활성화 했다는 것이다. 단, 특정 권한 오브젝트가 있는 사람에게는 사용을 허락할 수 있다고 한다. ( 해결 방법은 노츠에 있으니 필요하면 찾아보도록 하자. )

그래서 사람들이 가장 많이 사용하는 방법이 SE16N 디버깅 방법이다.

2. SE16N 디버깅으로 편집모드 접속

T-CODE : SE16N 에 들어가고 테이블 명을 입력해준다.

CBO 테이블은 바로 편집모드로 들어가지고, 스탠다드 테이블은 디버깅에서 EDIT 모드로 접속해야 한다. 

먼저 CBO 테이블의 경우,

F8 실행시키면 편집모드로 바로 들어가진다.

애초에 엔트리 유지보수에 체크가 되어있다

빨간색 박스 부분처럼 편집 기능인 행 추가, 삽입, 삭제의 버튼들이 존재한다.

그러면 스탠다드 테이블을 봐보자.

대표적인 스탠다드 테이블로 BKPF로 예시를 들어보자.

스크린 샷을 보면은 엔트리 유지보수가 비활성화 되어있다. F8 을 눌러서 실행시키자.

실행 화면에서 ALV의 버튼 중 편집 기능의 버튼들이 존재하지 않는다.

스탠다드 테이블의 경우, 데이터의 정합성이 더욱 중요하기 때문에 그렇다.

그래서 보통 비공식 방법으로 편집모드를 들어가는거다.

방법은 정말 간단하다.

명령에 필드에 디버깅 ‘/H’ 를 입력하고 ENTER를 누른다.

그러면 아래에 디버깅을 설정했다는 메세지가 뜬다.

이후 F8 또는 시계 모양을 통해 실행시키면 디버깅 모드로 진입하게 된다.

디버깅 모드에 들어왔으면 아래 빨간색 박스에다가 편집모드 명령어를 입력해줄거다.

화면처럼 입력해주면 된다.

GD-EDIT 입력 후 ENTER         → 연필 클릭 → X 입력 후 ENTER

GD-SAPEDIT 입력 후 ENTER → 연필 클릭 → X 입력 후 ENTER

입력을 다했으면 F8 키를 누르거나 사진의 빨간색 박스 부분을 클릭한다.

그러면 편집 모드로 들어오고, 원하는 데이터를 클릭하고 삭제한 뒤 저장 버튼을 클릭하면 된다. 

저장 버튼을 클릭하면 변경 내역을 알려주고, 체크 박스를 누르면 저장이 완료된다. 

3. CALL FUNCTION SE16N_INTERFACE 사용

마지막으로 펑션 모듈 사용법이다.

보통 SE16N에 권한이 없는 경우 사용한다. 

이 펑션모듈에서 수행된 모든 변경 사항은 SE16N_CD_KEY 및 SE16N_CD_DATA 테이블의 기록이 된다. 

변경 로그가 기록되기 때문에 담당자와 상의하고 사용해야 한다. 

해당 Function에는 여러개의 Import가 존재한다. 빨간색 박스로 표시한 3개의 매개변수를 사용하면 된다. 

사용하기 위해서는 Z프로그램으로 하나의 CBO 프로그램을 만들면 된다. 

START-OF-SELECTION을 써주고 그 아래에 Function을 적어준다. 

이후, 프로그램을 실행하면 SE16N 편집모드와 동일한 결과를 볼 수 있다. 

하지만, BKPF처럼 수십만건이 조회될 수 있는 스탠다드 테이블의 경우 조건을 걸고 싶을 수도 있다. 

그럴 때는 SE16N_SELTAB 를 사용하면 된다.  

필드는 레인지 변수와 동일하다. 나 같은 경우는 SE16N_SELETAB의 TABLE TYPE을 사용하였다. 

위처럼 SELTAB에 원하는 조건을 추가하면 된다.

해당 코드는 회사코드가 1000번이고, 회계연도가 2024년~2025년 사이인 데이터들이 조회하기 위한 조건이다. 

오늘도 파이팅이다! 

처음에 CTS 릴리즈와 운영서버 반영이라는 게 쉽지 않았다. 

한번도 해보지 않았고, 혹시나 운영서버를 잘못 건드릴까봐 무섭고 긴장되었다.  

그래서 나같은 사람을 위해 CTS 릴리즈와 운영 반영 방법에 대해서 정리해보려고 한다.

# CTS 릴리즈

일단 CTS 릴리즈든 이관이든 CTS 보내주세요든 다 똑같은 말이다.

처음에는 CTS 개념이 어렵고 헷갈렸는데 이제는 이해가 되었다.

내가 딱 정의를 내린 건, CTS 릴리즈은 고가의 물건 배송이다.

이 예시를 이해하기 위해 먼저 일반적인 SAP 서버 구성을 봐보자.

개발(D) - 품질(Q)- 운영 (P)

대부분의 SAP 서버는 위와 같이 구성되어있다.

SAP Logon의 시스템 ID를 보면은 D,Q,P 라는 문자가 포함이 되어있다.

D가 포함되면 개발,

Q가 포함되면 품질,

P가 포함되면 운영이다.

실무에서 각 서버의 역할은 다음과 같다. 

ㅁ 개발(D) 서버

말 그대로 개발 및 TEST를 진행하는 서버이다. 여기서 TEST 데이터도 만들어보고 현업 요청사항에 맞게 이것저것 개발한다.

ㅁ 품질(Q) 서버

개발서버에서 수정한 코드를 품질서버에 반영하고 TEST를(현업 or 개발자) 한다.

'왜 TEST를 또 해?' 할 수 있지만 이유는 크게 2가지이다.

1) 현업 담당자가 직접 TEST를 하는 경우

- SAP 관리를 외주에 맞기는 경우 현업은 품질과 운영에만 권한이 있는 경우도 있다.

- 또한 프로그램의 실 사용자는 현업이기 때문에 프로세스에 맞게 수정되었는 지, 문제가 없는 지 빠르게 확인할 수 있다. 

2) 실 데이터(운영서버 데이터)가 개발서버에 없고 품질에 있는 경우

- 운영 서버의 데이터는 하루에도 많게는 수십만개가 생성될 수도 있다. 해당 데이터를 매번 개발에 반영을 하는 것도 비용    이다.

- 일반적으로 BC팀에게 비용을 지불하고 주기적으로 품질서버에만 운영 데이터를 업데이트 하는 경우가 많다.

어떻게 보면은 IT 전공자들에게는 당연할 수 있다. 품질서버의 결론은 코드에 대한 검증을 하는 곳이다.

쉽게 말해, 실제로 운영에 넘겨도 문제가 없는 지 확인하는 절차다.

* 하지만 품질 서버가 없는 경우도 존재한다. (서버도 곧 돈이기 때문에… )

   그럴 경우에는 개발에서 개발과 품질의 역할을 둘 다 한다. )

ㅁ 운영(P) 서버

실제 현업이 사용하는 서버다. 흔히 회계 감사, 재무제표 등 모든 것들은 운영 데이터를 토대로 한다.

코드 수정 / 데이터 변경 및 삭제 등 대부분 로그가 남기 때문에 모두가 민감하게 받아 드리고 조심스러운 것이다.

운영서버에 이러한 로그들이 생기면 감사에서 문제가 되기 때문이다.

SAP를 사용하는 많은 이유 중 한 가지는 '신뢰성'이다. 

운영서버의 데이터들을 통해 실제 회사의 재무상태표가 만들어진다. 로그들이 다 남기 때문에 감사에서도 충분히 확인할 수 있고 그만큼 신뢰성 있는 재무상태표가 되기 때문에 대기업에서도 SAP를 사용한다. 

근데 만약에 운영서버를 수정했다?? 감사 때 재무상태표를조작에 대한 의심을 가질 수 밖에 없다.

그렇다보니 잘못 건들여서 데이터가 문제 생기면 현업에서는 직접 수정을 하기 어렵다. (현업 ID로 로그가 남으니까) 결국에는 외주사에게 수정을 요청하는데 이것도 다 비용(공수 시간에 포함) 이다.

또한 외주사도 잘못 수정하면 책임을 질 수 밖에 없기에... 운영서버는 왠만해서 절대 건들지 않는 편이다. 

그런 일이 없도록 개발과 품질에서 현업과 함께 철저하게 검증을 하는 것이 중요하다.

나중에 이슈가 생기면 '너(현업)가 문제 없다고 해서 운영에 반영한거야!' 라는 보호막을 만드는 역할도 한다.

이제 다시 고가의 주문제작 물건을 파는 회사에 예시를 들어보려고 한다. 

약간 억지 예시이긴 한데...

만약 어마어마한 금액의 자체제작 물건을 판다고 해보자. 먼저 고객의 요구사항을 정확하게 파악해야 한다.

그리고 금액이 큰 만큼 고객의 요구사항이 잘 반영되었는 지 중간 체크를 하고 최종적으로 고객에게 배송하는

신기한(?) 회사라고 생각해보자.

이 상황을 SAP랑 대입에 대입하면 나는 이해하기 좀 수월했다.....

주문 제작(개발서버)

1. 고객에게 주문 (현업 요청 사항)이 들어왔다.

2. 생산직 직원(개발자)은 그 주문(요청 사항 - 개발 or IMG 세팅) 꼼꼼히 확인하고 공장(개발 서버)에서 맞춤 제작을

    시작한다.

3. 생산직 직원(개발자)은 해당 제품의 불량, 작동여부, 마감처리 등(데이터 오류 검증) 나름의 품질 검사(TEST)를 한다. 

중간 검사 (품질서버)

4. 우리는 고가의 맞춤제작 회사이기 때문에 고객의 요구사항 대로 맞춤 제작(개발)을 했을지라도 고객에게 한번 중간 점검을 해야한다. 

- 이 사람이 나는 노란색이 좋아! 했지만 이 노란색이 아니라 옅은 노란색! 찐한 노란색! 이럴 수도 있으니까... ( 개발서버의 실 데이터가 없는 경우, 데이터가 다른 경우, 원했던 요구사항이 아닌 경우, 막상 보니까 새로운 문제가 있는 경우 등등의 문제를 방지하는 거다. ) 

5. 고객(현업)을 품질공장(품질서버)으로 불러서 '맘에 드세요??'(TEST 요청)하는 거랑 똑같다. 

6. 고객이 맘에 든다고 '이렇게 해줘요!(운영반영)' 라고 말하면 우리는 그 물건을 고객의 집으로 배송한다. (문제가 생겨도 책임 소지가 명확해진다.)  

고객 전달 (운영 서버)

7. 품질 검사를 통과하면 고객(현업)에게 전달(운영서버 반영)한다.

이해가 잘 될 지는 모르겠지만! 나름 고민했던 예시다…..ㅠ

대부분 블로그에는 개발 → 품질 → 운영 이런 순서의 설명이 많다보니,

SAP를 글로 배운 나는 실제 CTS 릴리즈 시 착각을 했었다. ( 나같은 사람이 세상에 존재하지 않을까 싶어 공유한다...)

개발서버의 CTS를 품질서버로 릴리즈(전송)

→ 품질서버에 개발서버의 CTS 반영

→ 품질서버의 CTS를 운영서버로 릴리즈(전송)

→ 운영서버에 품질서버의 CTS 반영

실제로는 저런 과정이 아니라, 아래 과정이다. 

개발서버 CTS 릴리즈

→ 품질서버의 개발서버 CTS 반영

→ 엇? 문제가 없네?

→ 운영서버에 개발서버의 CTS 반영

품질서버에서 따로 CTS를 또 만드는 것이 아니라, 개발서버에 CTS에 수정된 코드가 반영되어있으니, 품질서버에서 TEST하고 해당 CTS를 그대로 반영을 하면 되는 거였다. ( 지금 생각하면 당연한건데... 왜 그땐 그랬을까...)

어쨌든... 서론이 너무 길었지만 CTS의 대한 설명은 이정도로 하고 실제로 방법에 대해서 봐보자. 

1. CTS 릴리즈하기 (T-CODE: SE09)

SE09에 들어가면 다음과 같은 화면이 나온다.

수정가능은 아직 전송을 안한 CTS, 릴리즈는 이미 전송한 CTS 를 조회하는 조회 조건이다.

원하는 조건을 선택하고 Display를 누른다.

그러면 해당 화면처럼 조회가 된다.

내가 생성한 CTS를 찾고, CTS 번호 옆의 + 폴더 파일을 클릭한다.

그러면 한개 이상의 CTS가 하위 노드로 보일거다.

여기서 중요한거는 CTS 릴리즈는 Tree의 아래부분(하위노드)에서 위부분(상위노드) 순서대로 릴리즈를 해줘야 한다. 

제일 하위 노드인 1번의 CTS를 클릭하고 3번 버튼(릴리즈)을 클릭한다.

그러면 옆과 같은 체크박스 표시가 생길거다.

그다음에 2번(상위 노드 CTS) 을 클릭하고 3번을 한번 더 누른다.

그러면 화면 우측 하단에 타이머(?)가 돌아가면서 기달리면 아래와 같은 화면이 나온다.

예시 사진이 마땅한 게 없어서 노션에서 찾아왔는데 빨간색 네모 두 부분만 보면 된다.

CTS 릴리즈가 되면 위 화면처럼 빨간색 배경의 CTS 넘버가 보일거다

처음에 나는 내가 뭐 잘못한 줄 알고 땀이 흘렀는데…. 당연한 증상이니 전혀 두려워할 필요 없고 좌측 상단의 새로고침 버튼을 눌러주자.

그러면 하늘색으로 돌아오고 정상적으로 CTS 릴리즈가 된 것이다.

2. CTS 반영 여부 확인하기

그러면 이제 릴리즈는 알았으니 반영 여부는 어떻게 확인해야 할까??? 

총 세 가지 방법이 있는 것 같다.

1) 개발서버 SE09에서 CTS 로그를 통해 확인하기 

2) 반영된 서버의 STMS에 접속하여 반영 여부를 확인하기

3) 내가 수정한거 해당 서버에 들어가서 바뀌었는 지 확인

솔직히 3번은 예를들어, 프로그램 코드를 고쳤으면 직접 ABAP Editor가서 변경된 코드가 있는 지 확인하면 되는거다. 

나는 처음에 이렇게 했다... 하지만 반영된 서버에 못들어가는 경우도 있을 수도 있으니...?? 또, 1-2번이 전문적인(?) 느낌이 나니까 알아두자. 

2-1. 개발서버 SE09에서 CTS 로그를 통해 확인하기

개발서버에서 확인하는 방법은 간단하다.

기존의 CTS 로그화면이 반영전과 이후가 다르다.

다시 SE09에 들어가 Display를 누르자. (이때 조회조건 꼭 릴리즈 체크하자)

그러면 릴리즈 내역에 내 CTS가 뜰거다.

CTS에 마우스클릭 한번을 하고, 빨간색 박스의 안경잽이를 클릭하자.

저 안경잽이는 CTS 전송 로그를 볼 수 있게 해주는 기능이다.

해당 사진은 이미 반영된 CTS의 로그이다. (예시 캡쳐본이 없다..)

빨간색 박스 부분이 존재한다면, 반영이 된거다. 

빨간색 박스의 상위 노드가 'P'가 포함되어있으니 해당 시스템은 운영서버라는 것을 확인할 수 있고,

하위 노드 내역처럼 여러개가 조회가 되고 성공적으로 완료라고 써져있을 거다. 

이걸 보고 아 현업에서 반영 했구나! 생각하면 된다. (개발자가 직접 반영하는 고객사도 있다.)

2-2. 반영된 서버의 STMS에 접속하여 반영 여부를 확인하기 ( T-CODE :STMS )

반영한 서버로 sap 로그인을 한다. -> 해당 T-CODE를 들어간다.

예시 이미지는 품질 서버로 들지만, 운영도 방법은 똑같다.

좌측 상단의 트럭을 클릭하기

빨간색 박스의 ‘큐’라는 부분을 보면은 서버의 종류가 나온다.

개발/품질/운영을 사용하는 회사라면은 3개의 큐가 조회가 될 거고,

품질이 없다면 개발과 운영 2개의 서버만 조회 될 것이다.

만약 품질에 반영했다면

품질서버 로그인 → 품질서버(Q가 포함된)의 큐 더블클릭

만약 운영에 반영했다면

운영서버 로그인 → 운영서버(P가 포함된)의 큐 더블클릭

반영된 서버를 더블클릭하면 2가지 화면이 나온다.

# 필터가 걸려있는 경우,

해당 필터를 클릭하여 요청 기준으로 필터를 잡고 CTS 번호를 입력해주면 된다.

# 필터가 안 걸려있는 경우,

CTS 번호 컬럼을 기준으로 필터를 걸면 조회가 된다.

* 내 CTS 번호로 필터를 걸었는데 조회가 안된다?!

내가 릴리즈를 분명히 했는데 CTS가 조회가 안될 때 있다.

 그때는 당황하지말고 좌측 상단의 새로고침을 클릭해주면 된다.

* 그래도 안된다?!

그러면 필터 값에 공백이 포함되어 있을 가능성이 높다.

CTS가 정상적으로 반영이 되었다면 ICON이 초록색이다.

반영이 되지 않았다면은 RC 부분이 다음과 같은 ICON으로 표시된다.

이렇게 확인하면 된다.

원래 CTS 릴리즈와 반영 방법을 한 번에 포스팅하려 했지만,

생각보다 내용이 길어져서.... CTS 반영 방법은 추후에 올리도록 하겠다...!

오늘도 모두 파이팅! 

VALUE문은 NEW SYNTAX의 핵심 중의 핵심이라고 할 수 있다.

누군가 나에게 실무에서 가장 많이 본 NEW SYNTAX가 뭐냐고 물어본다면, 

나는 고민도 없이 VALUE 였다고 말할 것 같다. 기존에 APPEND와 INSERT의 기능과 여러 타입의 변수에 값을 할당 하는 기능을 한다. 

긴 코드를 간략하게 바꿀 수 있다는 것이 개발자에게 정말 편한 구문이다. 그만큼 가독성이 좋아 유지보수가 더 쉬워진다. 

얼마나 편하길래? 라는 궁금증이 들 수도 있으니, 아래 내가 경험한 코드를 봐보자.

가장 먼저 내가 SYNC 교육 과정을 하면서 했었던 방법이다. 물론 예시이기 때문에 4건의 데이터 밖에 없지만 실제로 6개 이상 노가다 하면서 썼었다. 이게 은근 정말 귀찮다. 

기존의 ECC 버전에서 많이 볼 수 있는 방법이다. 물론 해당 코드가 문제가 있다는 것이 아니다. 

어떤 사람은 이게 더 가독성이 좋다고 이야기할 수 도 있다. 

이 코드에 VALUE 문법을 사용하면 어떻게 될까? 

Old Syntax의 30줄 길이의 GT_FCAT이 단 4줄의 코드로 줄어든다. 

무엇보다 한줄이 하나의 데이터처럼 보여, 4건의 스트럭쳐를 테이블에 넣었구나를 빠르게 확인할 수 있다. 

테이블의 필드도 가로로 정렬되서 보기도 편하다. 

이정도면은 충분히 가독성의 차이를 느꼈을테니, 자세히 이야기를 해보자 .

# VALUE

VALUE는 간단하게 ECC 버전의 ‘=’ 코드를 쉽게 만들어준다고 생각하면 된다. 그로인해 개발자는 불필요한 변수 선언과 가독성 있는 코드를 짤 수 있다. 

내가 찾아보고 직접 해본 결과 VALUE는 아래 4가지로 설명할 수 있을 거 같다.

1. VALUE 구문
2. 스트럭쳐의 값 넣기
3. 테이블의 값 넣기
4. 변수의 값 넣기

그래서 해당 목차대로 하나씩 이야기해보려 한다.

1. VALUE 구문 

VALUE는 아래와 같은 구문들을 쓸 수 있다.

1. VALUE #
2. VALUE TYPE
3. VALUE ~ BASE
4. VALUE ~ OPTIONAL

1-1. VALUE # 이란? 

내가 VALUE를 처음 만난건 SYNC 교육 과정을 듣기도 전에 SAP JOY에서 NEW SYNTAX 세미나를 시청했을 때 였다.

‘#’ 표현이 들어가면서 VALUE 구문을 굉장히 어렵게 느껴졌고 더군다나 비전공자였던 나에게 괴리감이 있었다.

VALUE의 ‘#’은 쉽게 설명하기 위해서는 인라인 선언이라고 생각하면 쉽고 그냥 TYPE 의 또 다른 표현이라고 생각하자.

# 을 쓰면 TYPE을 써주지 않아도 알아서 앞의 변수를 참고해서 TYPE을 받는다.

정확하게는 VALUE [ Type ] 이 문법이다. 할당할 변수의 TYPE을 받겠다는 것을 #으로 표현한다. . 

아래의 예시를 봐보자. 

우리는 여기서 LS_SCARR을 인라인 선언하면서 GT_SCARR의 타입을 그대로 받아온다는 것을 알고 있다.

그거랑 똑같다. 할당 받을 데이터의 타입을 그대로 참조한다.

VALUE #도 똑같다. 

자동적으로 SCARR 타입을 받는다. 사람들은 대부분 편하니 #을 많이 사용한다.

하지만! 중요한 점이 있다. 

만약에 VALUE 뒤에 지정해줄 수 있는 TYPE이 존재한다면, #을 써주는 것보다 TYPE을 명시해주는 것이 퍼포먼스에 좋다.  그게 바로 2번 내용의 VALUE TYPE이다.

1-2. VALUE TYPE 이란? 

말 그대로 TYPE을 지정해 주는 것이다.  퍼포먼스의 차이를 알아보자. 

예를들어 1번과 2번의 구문이 존재한다. 

데이터가 수십만 건이 존재한다면 2번 방법이 퍼포먼스 적으로 유리하다. ( 대부분의 회사는 수십만건의 데이터는 가볍게 가지고 있다...! )

왜냐하면,  #을 써주는 순간 SAP 시스템 상에서 GS_SCARR의 타입을 확인하기 위한 과정이 생겨버린다. 

해당 과정을 보면은 

# 1번의 코드의 경우

엇? Type이 #이네? -> GS_SCARR이 뭐지?( Type 확인)  →해당 타입에 알맞게 값넣기

# 2번의 코드의 경우 

Type이 SCARR 이구나? -> 해당 타입에 알맞게 값넣기

잘 이해될 지 모르겠는데 1번의 빨간색 글씨처럼 할당할 변수의 TYPE을 확인하는 과정이 생기기 때문에, 

만약 TYPE을 입력해줄 수 있다면 입력해주는 것이 좋다. 

1-3. VALUE BASE

BASE 문은 기존 데이터를 유지하면서 데이터를 추가하는 방법이다. 한마디로 APPEND 다. 

예를 들어, 우리가 많이 쓰는 INTO 이런식의 표현은 기존에 있는 데이터를 없애고 새로운 데이터를 집어 넣는 방식이다.

기존의 데이터를 유지하면서 데이터를 추가하는 방식이다. 해당 코드처럼 GT_DATA에 이미 데이터가 존재한다면

BASE를 써서 GT_DATA의 기존 데이터를 데이터를 유지하고~ 이 값을 넣어~~ 라는 식의 표현이 될 수 있다.

1-4. VALUE OPIONAL

이거는 이전의 READ TABLE 할 때, 했던 내용이랑 똑같다. 덤프 관련의 내용이다.

OPTIONAL은 특정 조건에 데이터가 없어도 덤프를 안나게 막아준다.

* 해당 게시글에 자세하게 나와있다.

2025.03.07 - [SAP/NEW SYNTAX] - [SAP ABAP] NEW SYNTAX #2 - 테이블 표현식(Table Expressions)

아래와 같은 상황이 존재한다. 

만약 이 과정에서 GT_DATA의 1번 INDEX가 존재하지 않는다. 라고 가정해보자. 

그러면 OLD 구문은 덤프가 나지 않고 SY-SUBRC 4로 떨어지면서 넘어간다.

하지만 VALUE 구문은 바로 ITAB_LINE_NOT_FOUND 이라는 Runtime Errors가 생긴다.

이런 경우에는 OPTIONAL을 사용해주거나 Try Catch을 사용해야 덤프가 안난다. 데이터가 존재할 수도 있고 안할 수도 있다면 OPTIONAL을 추가해서 덤프를 나지 않도록 방지해주자. 

2. 변수에 값 할당

기존의 OLD 방식으로 하는 방법을 NEW 방법으로 사용이 가능하다.

3. Structure에 값 할당

스트럭쳐에 하나씩 값을 넣을 때는 아래와 같이 사용하면 된다. 

조건에 맞는 테이블의 ROW를 INTO 하는 상황.

4. TABLE에 값 할당

코드길이를 줄이는 것은 물론 가독성까지 좋게 만들 수 있다.

해당 사진들은 모두 다 #으로 표기했지만, 

실제 상황에서는 꼭 TYPE을 써주는 것 잊지 말자!! 

오늘도 파이팅! 

CONV란?

CONV 연산자는 데이터 타입을 변환하는데 사용된다.

한 타입의 변수를 다른 타입으로 변환할 수 있다.

CONV type( [let_exp] dobj )  형식으로 사용되며, 아래와 같이 사용할 수 있다.

CONV #(     

CONV I(       

 CONV STRING(

내가 느낀 것은 인라인 선언과 함께 사용할 때나, CLASS 나 FUNCTION의 파라미터를 입력할 때 편하다고 느꼈다.

예제를 통해서 하나씩 봐보자.

1. TYPE 변환

두 가지 타입이 다른 경우가 있다.

LV_VALUE는 TYPE C 이고 LV_INT는 TYPE I 이다.

CONV 연산자는 데이터의 TYPE을 변환해준다. 

해당 코드는 LV_VALUE의 값을  TYPE 'I' 로 변환해 LV_INT에 할당하라는 코드이다. 

실제 프로그램에서는 CHAR 와 INT 타입은 SAP 스탠다드 설정으로 자동 변환되어 CONV를 사용하지 않아도 정상적으로 실행된다. 

저렇게 사용한다는 것만 참고하자.

2. FUNCTION 에서 사용

- CONV는 TYPE 변환 연산자라고 했다. 우리가 TYPE 변환을 많이 사용하는 FUNCTION MODULE에서의 사용법이다.

해당 FUNCTION은 DAY_IN이라는 파라미터가 날짜타입이다. 우리는 여기에 문자형을 넣을거다.

그러면 당연히 파라미터와 TYPE이 맞지 않아 덤프가 뜰거다.

위의 코드는 TYPE 불일치로 덤프가 나오는 코드이다. 

나는 과거에 교육 과정 프로젝트에서 TYPE 생각을 안하다가 덤프를 마주한적이 간혹 있었다.

Function Module의 파라미터와 변수가 TYPE이 맞지 않아 덤프가 뜬다. 

이럴 때마다 나는 해당 TYPE에 맞는 변수를 새로 생성해주고 TYPE을 변환시켰었다. (근데 이게 은근 귀찮다....)

하지만 이제는! CONV를 써서 간편하게 TYPE을 변환할 수 있다. 

CONV 연산자를 사용해 LV_VALUE를 TYPE D로 변환하는 코드이다. 

근데 여기서도 한가지 의문이 생겼다. 

대부분 CONV 연산자에 예시로 TYPE I, TYPE STRING 등만 있어서

CONV SFLIFHT-FLDATE (LV_VALUE) 처럼 TABLE의 필드도 사용되는지 궁금했다.

정상적으로 프로그램이 실행되고 LV_VALUE가 BKPF 테이블의 BLDAT TYPE으로 변환된다. 

3. CLASS

만약에 아래와 같은 클래스가 있다고 치자.

I_INT1과 I_INT2는 I 타입이다.

만약 LV_F가 F 타입이기 때문에 CONV 없이 그냥 들어간다면 FUNCTION 때 처럼 덤프가 발생할 거다.

하지만 CONV # 을 사용하면은 CLASS의 파라미터 타입으로 변환되어 덤프가 뜨지 않는다.

그러면 여기서 CLASS의 CONV # 과 FUNCTION의 CONV랑 차이가 궁금할거다.

CONV #

• CLASS에서만 사용 가능
• 자동적으로 파라미터의 TYPE을 받아준다 ( VALUE # 과 동일 )

CONV TYPE

• Function 에서 사용 시, CONV 뒤에 타입을 꼭 지정해줘야 한다. (CONV # 불가능 )
• TABLE의 Field로도 TYPE을 받을 수 있다. 

만약에 왜 CLASS에서는 #이되고, Function에서는 #이 안되는 지 궁금하다면, 

내가 이전의 데이터 인라인 선언 게시글에 정리하였으니, 그거를 참고하면 된다!

# 데이터 인라신 선언 포스팅 참고! 

2025.03.05 - [SAP/NEW SYNTAX] - [SAP ABAP] NEW SYNTAX # - 데이터 인라인 선언( Inline Declarations )

4. 응용 방법

1)  TABLE의 라인 수를 이용하여, 메세지 출력 또는 TITLE 에 사용

2) CLASS에서 사용 

해당 응용 방법 말고도 많은 방법이 존재하니, 잘 활용하기를 바란다.

오늘도 파이팅 입니다. :)

오늘은 NEW SYNTAX의 2번째 Table Expressions, 테이블 표현식이다! 

READ TABLE을 대체할 수 있는 신 문법으로, 내부 테이블이나 표준 테이블의 특정 행에 직접 접근할 수 있다.

기존에 없었던 새로운 접근 방식으로, 개발자가 코드를 더 간결하고 읽기 쉽게 만들 수 있도록 돕는다.

지난 포스팅에서 정리한 데이터 인라인 선언 방식을 적용하여, 함께 사용한다면 코드가 더 간결해 질 수 있다.

# 데이터 인라신 선언은 이전 포스팅 참고! 

2025.03.05 - [SAP/NEW SYNTAX] - [SAP ABAP] NEW SYNTAX # - 데이터 인라인 선언( Inline Declarations )

일단은 늘 하던대로, 얼마나 간결해지는 지 예시부터 보자. 

READ TABLE은 SAP 개발을 하면서 많이 쓰는 구문 중의 하나이다. 우리가 자주 쓰는 구문이 사진의 NEW SYNTAX처럼 사용을 할 수 있다. 기존의 4줄의 코드는 데이터 인라인 선언과 테이블 표현식을 사용하여 1줄이 되었다. 

테이블 표현식의 코드를 해석하면 LV_CARRID2를 만들고, GT_DATA 테이블의 1번 INDEX(첫줄)를 찾고 1번 INDEX의 CARRID 값을 넣어라! 가 된다. 이런식으로 간결하게 표현할 수 있는게 큰 장점이다.

해당 예시는 여러가지 경우에서 변수에 값을 넣는 부분이지만 내가 공부하면서 느낀 거는 다양한 코드들을 정말 간결하게 표현할 수 있는 것 같다. 

하지만,

이 테이블 표현식을 사용하려면 우리는 아래의 2가지 사항을 정확하게 숙지해야 한다. 

1. 값을 할당할 때, 테이블에 데이터가 존재하지 않으면 ITAB_LINE_NOT_FOUND 이라는 Runtime Errors(덤프)가 발생한다.
2. SY-SUBRC 는 존재하지 않는다. 데이터가 들어가도 SY-SUBRC 는 4 값을 가진다.

자세한 내용은 아래에서 예시와 함께 보자.

1. READ TABLE INDEX

처음 예시랑 똑같은 내용이다.

테이블에 데이터를 스트럭쳐로 옮기는 경우 해당 코드를 작성할 수 있다.

하지만!! 가장 중요한 사항은 해당 INDEX에 대한 데이터가 존재하지 않으면 ITAB_LINE_NOT_FOUND 이라는 Runtime Errors(덤프)가 생긴다.

테이블 표현식은 데이터가 존재하지 않는다면 무조건 덤프를 낸다. 

"근데 우리가 개발하다 보면은 TABLE에 데이터가 존재할 수도 있고, 없을 수도 있는데 그런 상황에서는 쓰지 못할까? "

그래서 열심히 구글링과 SAP docu을 찾아봤다. 

역시 해결 방법이 존재했었다. 

1) TRY-CATCH를 이용하여 해결하기.

해당 코드는 TRY-CATCH를 이용해 데이터가 없을 경우, CATCH 로 빠지게 했다. 

프로그램을 실행시키면

덤프가 나지 않고 CATCH로 빠지게 된다. 

TRY-CATCH를 이용해 데이터가 없는 경우에 대한 로직을 작성하여 이 부분을 해결 할 수 있었다. 

그러나 만약 반복되는 코드일 경우 TRY-CATCH로 인해 가독성이 더 안좋질 수도 있다. 

그래서 두번째 방법이 존재하더라... 

2) VALUE와 OPTIONAL 이용하여 해결하기.

VALUE 구문은 NEW SYNTAX에서 핵심 중에 핵심이다. 제일 많이 본 것 같다. 

스트럭쳐와 변수에 데이터를 집어넣는 과정이다. 

OPTIONAL의 역할은 테이블에 원하는 데이터가 없을 때, CX_SY_ITAB_LINE_NOT_FOUND 예외가 발생하지 않도록 막아준다. 이녀석의 정확한 역할은 값이 있으면 넣고 없으면 패스~ 느낌인거 같다. 

그렇기 때문에 데이터가 없을 가능성이 있다면 잊지말고 항상 써줘야 한다. 

2. READ TABLE ~ WITH KEY.

WITH KEY 뒤 조건에 맞는 스트럭쳐를 테이블에서 가져오는 구문이다. 

WITH KEY를 입력하지 않고 대괄호([ ]) 사이에 해당 조건을 바로 나열해주면 된다. 

3. TRANSPORTING NO FIELDS.

우리는 원하는 조건의 데이터가 있는 지 확인하기 위해 TRANSPORTING NO FIELDS를 사용했다. 

그리고 IF SY-SUBRC를 이용해 데이터 존재 여부를 체크했었다. 

하지만 테이블 표현식을 사용할 때는 처음에 주의사항으로 이야기했던 

2. SY-SUBRC는 존재하지 않는다. 데이터가 들어가도 SY-SUBRC 는 4 값을 가진다 

이거를 기억해야 한다.

내가 직접 테스트 해본 결과, 데이터가 들어가도 이녀석들은 무조건 SY-SUBRC 4를 내뱉는다. 

그러면 같은 상황에서 데이터 핸들링을 하려면 어떻게 해야 할까? 

그래서 테이블 표현식에서는 두 가지 키워드가 존재한다.

# LINE_EXISTS와 LINE_INDEX.

1) LINE_EXISTS.

LINE_EXISTS는 조건에 맞는 테이블의 데이터 존재 여부를 확인해준다. 한마디로 ‘IF SUBRC = 0’ 이랑 같은 의미를 지낸다.

해당 조건에 DATA 여부를 확인하고, 존재하면 IF 문을 타게 된다.

2) LINE_INDEX.

LINE_INDEX는 해당 조건에 맞는 INDEX 값을 반환해준다.

인터널 테이블에 조건에 맞는 데이터가 몇번 INDEX에 있는 지 반환을 하게 된다.

기존에는 SY-TABIX로 인덱스 값을 확인했다면, 

테이블 표현식은 LINE_INDEX 키워드를 사용해서 조건에 맞는 데이터의 인덱스 값을 추출할 수 있다. 

실행 결과를 보면 CARRID가 FJ라는 데이터는 6번 INDEX에 존재하는 점을 알 수 있다. 

만약 데이터가 없는 경우는 0 값을 반환한다. 또한 INDEX가 존재할 수 없는 Hashed Table이나 Hashed Secondary Key를 사용한 경우에는 -1을 반환한다.

4. FIELD-SYMBOL ASSIGN.

필드심볼에 할당에 대한 테이블 표현식이다.

OLD 버전에서 IF조건문이 없고 데이터가 존재하지 않아도 덤프가 나지않는다. 

하지만 테이블 표현식은 데이터 없으면 가차없이! 덤프나기 때문에 무조건 IF 조건문으로 감싸줘야한다.

이렇게 반겨준다. 

25번에 데이터가 존재하지 않는 경우, 두 경우에 덤프 에러가 뜨지 않는다 .

근데 여기서 중요한 점은

SAP에서 해당 테이블 표현식을 쓸 때, IS ASSGIN 말고 SY-SUBRC를 사용하라고 권장을 한다. (SY-SUBRC 사용 못한다고 할때는 언제고…?)

이 경우에는 놀랍게도 기존에 4값만 들어오던 SY-SUBRC가 0값이 들어오게 된다........ 

이 부분에 대해서 찾아봤는데 필드 심볼의 할당은 ASSIGN을 사용하는 방법이 올바르지만, 여러 개발자의 유지보수 등을 고려하여 SY-SUBRC를 권장하는 거라고 한다. ( 어떤 개발자든 직관적으로 성공! 실패! 를 구분할 수 있다나 머라나.... ) 

# 응용

4-1. TABLE에서 데이터 변경

MODIFY로 인터널 테이블에서 값을 수정하는 과정을 간단하게 바꿀 수 있다.

NEW SYNTAX를 해석해보면 GT_SCARR테이블의 CARRID가 ‘AA’인 ROW의 CARRNAME을 ‘비행기’로 변경해라 가 될 수 있다.

다만 여기서도 해당 조건의 데이터가 없다면, ITAB_LINE_NOT_FOUND 가 반긴다는 것...

그렇기 때문에 나는 위 사진처럼 LINE_EXISTS를 사용하여 덤프를 방지 시킨다.

물론 TRY CATCH도 가능하다.

4-2. 2개의 테이블 데이터 핸들링.

GT_SCARR 의 특정 데이터의 값을 LT_DATA에 APPPEND 하는 상황이라고 가정.

둘 다 동일한 값을 가진다

4-3. F4 서치헬프 함수로 띄우는 과정에서 적용하기

실제 내가 적용했던 방법이다.

서치헬프에서 클릭한 값을 받아서 CALL FUNCTION 'DYNP_VALUES_UPDATE’에 사용하는 상황이다.

잘 참고하면 좋겠고 도움이 되었으면 좋겠다! 

올바르고 정답이 있는 코드는 없다고 생각한다. 

잘못된 코드는 있지만 올바른 코드는 없다! 각자 상황에 맞게 잘 활용하기를 바란다! 

 
SAP의 ERP 시스템은 방대한 데이터를 효율적으로 관리하는 것이 핵심이다. 기존 ABAP Old SYNTAX는 오랫동안 사용되어 왔지만, 대량의 데이터를 처리할 때 성능 문제와 제한 사항이 존재했었다. 그러한 이유로 비효율적인 구문을 ABAP개발자들 사이에서 공유하고 암묵적으로 사용하지 않았었다. SAP는 이러한 한계를 극복하고 최신 데이터베이스 기술을 반영하기 위해 ABAP New SYNTAX 를 도입하였다.
 
또한, SAP HANA DB로 전환되면서 데이터 연산을 데이터베이스 레벨에서 실행하는 'Push Down' 개념이 중요해졌다. 이를 통해 어플리케이션 서버의 부담을 줄이고 성능을 극대화할 수 있다.
 
하지만,
이 글의 목적은 무조건 'NEW SYNTAX가 최고야! ' 가 아니다. NEW SYNTAX에서도 단점이라고 하기에는 애매하지만 문제점(?)이 존재할 수 있다. 내가 신입으로 입사하고 NEW SYNTAX 공부를 하면서 느낀 장점과 문제점을 공유해보겠다. 
 

 내가 생각하는 New Syntax의 장점 

1. 코드 간결화 

- 데이터 인라인 선언 등으로 인해 코드가 많이 간소화되고 기존의 여러줄을 써야 하는 코드들을 한 줄로 해결할 수 있는 문법들이 많다. 
 
잠깐 아래 예시를 봐보면 코드 간결화가 이해될거다. 
해당 코드는 ALV의 FCAT에 값을 넣는 상황이다. 

OLD SYNTAX에서 GT_FCAT 테이블에 값을 넣는 코드 길이는 30줄이다. 

NEW SYNTAX는 단 5줄로 끝난다. 저기서 사용한 VALUE 구문이 NEW SYNTAX 에서 가장 많이 사용되는 구문 같다

결과는 동일하다. 

2.  개발자의 편의성 

- SAP가 ABAP 개발자의 편의성을 얼마나 중요시 생각했는지 알게 된다. 기존에 타입을 맞춰서 데이터 핸들링 등을 하는 번거로움 없이 인라인 선언으로  해당 타입을 자동적으로 읽어 알맞게 생성해준다.
 

3.  직관성  

- New Syntax 구문을 알고 있는 사람이 해당 코드를 보면은 정말 직관적으로 볼 수 있다. 위의 예시만 봐도 VALUE 구문을 이용해서 한눈에 알아볼 수 있게 코드가 짜여져있다. 
 

 내가 생각하는 New Syntax의 단점 

1.  코드의 복잡성  

- 장점에서는 직관적이고 간결하다고 했는데 갑자기 복잡성?! 이럴 수 있다. 이거는 내가 느낀 주관적인 사항이니 참고만 하면 좋을 것 같다. New Syntax 구문에 대한 지식이 없으면 더 복잡하게 느껴진다.
 
예제1) 
너무나 당연한 이야기지만 내가 처음 NEW SYNTAX은 VALUE 였고 구문에 대한 이해가 없으니 더 어렵게 느껴졌다. 

 
지금은 VALUE 구문을 알기에 어렵게 느껴지지 않지만 처음에는 큰 괴리감이 느껴졌다. 
한줄씩 뜯어서 해석하는데 오래 걸리기도 했다. 
 
그렇기 때문에 오히려 신문법을 배운 세대와 그렇지 않은 세대들이 거리감을 느낄 것 같다는 생각이 들었다.  
 

 내가 내린 결론 : Old Syntax와 New Syntax의 선택 

나는 한 가지 궁금증이 있었다.

'New Syntax가 SAP에서 성능을 위해서 개발한 신문법인데 모두 이거를 사용해야 하는거 아냐?' 라는 생각을 가지고 이곳 저곳을 찾아본 결과 답은 상황 BY 상황, 회사 BY 회사 였다. 최종적으로 내용을 정리해보면서 아래와 같은 결론이 나왔다. 

1. 개발자가 개발하기는 정말 편해진 것 맞다. 
2. 하지만 NEW SYNTAX 잘못 사용할 경우 코드가 더 복잡해질 수 있다.  
3. 신입 개발자(신문법 시대) 와 시니어 개발자(구문법 시대) 사이의 괴리감이 존재할 수 밖에 없다. 
4. 정답은 없다. ABAP 7.0 이전일 경우는 Old Syntax를 사용해야만 HANA일때는 NEW 선택해도 된다.
5. 본인이 특히 운영업무라면, 두 가지 방법 다 알 고 있는 것이 도움이 된다. 

결국은 본인이 성장하면서 직접 깨닫고 본인만의 개발 방법을 찾아야 하는 것 같다.! 무엇보다 많이 알고 있어서 손해볼 거는 없는 것 같다. 
 
 New Syntax의 첫 포스팅이기에 서론이 정말 길었지만.....
이제 이번 주제였던 데이터 인라인 선언에 대해 간략하게 정리해보겠다. 
 

 데이터 인라인 선언 

1.  변수 선언

- 기존에는 데이터 선언과 값을 할당하는 로직으로 2줄 이상의 코드가 필요했지만, 인라인 선언이 가능해지면서
  선언부에 대한 불필요한 로직을 줄이고, 선언과 값 할당을 동시에 할 수 있다.

2-1.  LOOP문에서 DATA 선언

- 개발을 하다보면은 LOOP를 돌려야 하는 순간을 많다. 여러 테이블을 LOOP 해야 한다면 DATA 선언부에 스트럭쳐를 모두 생성해야 했지만 이제는 ‘DATA(스트럭쳐명)’ 으로 선언이 가능하다.

위와 같은 데이터가 있는 상태에서 아래와 같은 방법으로 선언이 가능하다. 

2-2.  LOOP문에서 FIELD-SYMBOL 선언

- 필드심볼도 인라인 선언이 가능하다. 
 

 
필드심볼을 따로 선언하지 않고 바로 할당 가능하다. 
타입은 자동적으로 GT_ITAB에 맞춰진다. 
 

3.  SELECT문에서 DATA 선언

- 단, SELECT 문에서 인라인 선언시에는 New SQL 방식으로 입력해줘야한다. 
- 변수에는 @ 기호를 추가해야 되고, 필드명은 컴마(,)로 구분해줘야 한다. 

4.-1   READ TABLE에서 DATA 선언

4-2.  READ TABLE에서 FIELD-SYMBOL 선언

5.   METHOD에서 DATA 선언

- 메서드를 호출할 때, 실제 매개변수(Actual Parameter)는 형식 매개변수(Formal Parameter)와 타입이 일치해야 한다. 하지만 메서드의 형식 매개변수가 변경될 경우, 기존 방식에서는 관련된 모든 변수 선언을 수정해야 하는 번거로움이 있었다. 인라인 선언을 하면은 쉽게 해결 가능하다. 

이렇게 인라인 선언을 정리해보았다. 참고해서 사용하면 좋을 것 같다. 물론 내가 보려고 정리했다~ 나처럼 필요한 사람이 있을 수 있으니까~
 
마지막으로 인라인 선언을 찾아보면서 METHOD에서 인라인 선언 방식이 굉장히 편해보였다. 그래서 Function Module에서는 불가능한가? 라는 호기심에 찾아봤다. 
 

# Function Module은 인라인 선언이 안될까? 

결론부터 말하면, 불가능하다. 

나는 비전공자이다보니, 처음에는 왜 안되는 지 이해할 수 없었다. 하지만 Function Module과 Method의 개념과 차이를 알고나니 쉽게 이해되었다. ( 전공자들은 부럽다... )  
 

1) 함수 모듈과 Method의 차이

ㅁ Method 호출 구조

메서드는 클래스(Class) 내부에 정의되며, 객체 지향 프로그래밍(OOP) 방식으로 동작된다.

• 컴파일러가 메서드 시그니처(Method Signature, 즉 매개변수 타입 정보)를 정확히 알고 있음
• 메서드 호출 시점에 인라인 선언된 변수의 타입을 자동 유추 가능
• 이 때문에 CALL METHOD 구문에서는 DATA(...) 인라인 선언이 가능

 
메서드는 클래스 내부에서 정의되기 때문에, 컴파일러는 클래스를 직접 참조해서 메서드의 매개변수 타입을 확인할 수 있다. 그래서 P1의 타입을 보고, lv_p1의 타입을 자동으로 설정할 수 있다. 
 

ㅁ 함수 모듈(Function Module) 호출 구조

함수 모듈(CALL FUNCTION)은 컴파일 타임(코드 작성 시점)이 아니라 런타임(실행 시점)에 호출된다.

즉, 컴파일러가 함수 모듈 내부에서 P1이 어떤 타입인지 미리 알 수 없기 때문에, DATA(...)를 사용할 수 없는 거다.

해당 코드는 다음과 같은 에러 메세지가 뜬다. 

함수 모듈은 실행되기 전까지 ev_result의 타입이 무엇인지 확실하지 않으므로 인라인 선언이 불가능하다.
 

2) 함수 모듈의 실행 방식

함수 모듈은 "디스크에서 로드 → 실행 → 언로드" 과정이 필요하며, 이는 메서드와 다른 점이다. 차이는 다음과 같다. 

ㅁ 메서드(Method) 호출:

• 이미 메모리에 로드된 클래스의 일부
• 호출 즉시 시그니처를 참조하여 타입을 결정할 수 있음

ㅁ 함수 모듈(Function Module) 호출:

• 독립적인 실행 환경을 가짐
• 호출될 때 완전히 별개의 프로그램처럼 실행됨
• 함수 모듈 내부에서 정의된 IMPORTING/EXPORTING 매개변수의 타입 정보를 호출부에서 즉시 활용할 수 없음

이런 구조적 차이로 인해, 함수 모듈에서는 CALL FUNCTION 구문 안에서 새로운 변수를 인라인으로 선언할 수 없는 것이다.
 

3) SAP의 기술적 방향성과 함수 모듈의 역할

SAP은 ABAP OO(Object-Oriented ABAP)를 적극적으로 지원하며, 새로운 기능(인라인 선언, 테이블 표현식 등)은 클래스 및 메서드 중심의 구조에 맞춰 발전되고 있다고 한다.( 그렇대요.. )

• 함수 모듈은 RFC(Remote Function Call), BAPI 등에서 여전히 중요한 역할을 하지만, 새로운 기능과의 호환성이 제한적
• SAP도 클래스 기반 개발을 권장하고 있으며, 함수 모듈보다 클래스를 활용하는 것이 유지보수성 측면에서 유리

다음과 같은 이유로 Function Module에서는 인라인 선언이 불가능하다고 한다. 
혹시나 나와 같은 비전공자로서 궁금증이 있는 사람은 도움 되기를 바란다!!