저희는 원래 협력사 PM 없이 개발팀장이 PM을 겸임했었습니다. 그래서 장애 발생하면 각 시스템 SM 엔지니어들이 자기네 팀장을 건너뛰고 원청사 PM인 저한테 직보고를 하고 저도 그에 대한 대응 조치 지시를 합니다. 비상 출근을 하게 될때도 잦습니다. 저희 회사가 IT SM이나 SI에 돈을 많이 쓰지 않고, '그게 뭐임? 먹는거임?' 하는 곳이라.. MES 시스템 원청 PM 하시던 부장님이 나이 때문에 자리 놓고 물러날때 '너 밖에 아는 사람이 없다' 라는 이유로 제가 넘겨 받았고요. '야, 네가 하는게 뭐가 있어? 협력사가 다 하잖아?' 라면서 이런 저런 업무가 붙었는데 이런 저런 이유로 협력사에 PM을 1명 더 추가했습니다. (PM 1명이랑 SM 개발자로 특급개발자 2명 추가하면서 경영진에게 '너가 편할려고 그러는거지?' 하면서 엄청 까이고 반려도 많이 당했습니다.) 저도 협력사 PM을 전담으로 받아본적이 없어서.. 초기에는 여전히 장애대응 연락 오면 출근하고 개발자랑 원인 찾고 조치하고 윗분들에게 보고하는 일을 하던대로 계속 했습니다. 그러다가 윗분이 '야, 걔네 PM은 뭐하는 사람이야? 왜 보이질 않아?' 라는 지적이 나왔습니다. (하도급법때문에 긴급상황외에는 제가 직접 SM 개발자와 직접 접촉을 최대한 줄이려고 하고, 저희 팀 회의 할때 PM은 참석을 안합니다. 저는 PM 이랑 개발팀장이랑 셋이서 따로 회의 합니다.) 처음에는 셋이서 회의를 하면서 장애발생시 PM님께서 대응을 하고 저에게 연락을 주셨으면 좋겠다고 했는데, PM은 자기보다 오래해온 제가 더 이 사이트와 라인, 시스템을 잘 아니까 개발자들이 저한테 먼저 보고를 하고 그 다음에 자기한테 연락을 주는 순서가 낫지 않겠냐고 해서 '이게 맞나?' 했지만 MRRT 와 가동율이 중요하기 때문에 효율적인 측면에서 그러자고 했습니다. 그런데, 새벽에 연락와서 원격 대응을 같이 하고 윗분들에게 보고를 하는 과정에서 PM이 없습니다. 개발자에게 물어보니 메신저는 남겼다고 합니다. 자느라 못 봤을 수도 있지.. 그런데 저한테는 전화를 하면서 왜 자기네 PM에게는 연락을 안하나.. 어제는 금요일이라 간만에 퇴근 좀 일찍 하자 했는데 퇴근 5분전에 PM에게 연락이 왔습니다. D등급 장애가 발생해서 개발자가 확인중이라고 하더라고요. 그와 동시에 현업부서에서도 연락이 와서 '지금 시스템이 이상한것 같아요' 라고 합니다. 저는 윗분에게 간략하게 구두보고를 하고 현장 전산실에 6시 10분쯤 도착했습니다. 그곳은 3명이 근무하는 곳인데 담당 개발자 1명만 빼고 아무도 없더군요. PM도 저한테 전화만 하고 퇴근 했고요. 개발자는 역시 퇴근한 개발팀장이랑 전화로 지시 받고 있더라고요. 퇴근이후 야간이나 휴일에 장애났을때 출근 안하는건 그렇다 치고.. 그래도 근무시간에 장애가 시작되었는데 퇴근시간이라고 싹 다 퇴근한걸 보니 뭔가 현타가 왔습니다. 그래도 저는 사용자들이랑 연락하고 하위쪽이랑 연락하면서 원인을 찾았고, 개발자에게 긴급하게 코드 수정하자고 하고, 정상화 되고 1시간쯤 더 지켜보다가 같이 퇴근했습니다. 생각해보면, 윗분들은 제가 노는줄 알고 하나하나 일을 더 던져주고 그래서 제가 협력사 관리 비중을 줄이기 위해 '이게 니돈이면 이렇게 쓸거냐?' 라는 소리 들으면서 PM 도 추가했는데, PM이 추가되었다고 내가 안하는게 뭔가? 하는 생각이 듭니다. 개발자가 장애나 개선 보고서 쓰면 그냥 저한테 포워딩하는데, 저는 그걸 IT에 문외한인 윗분들이 이해할 수 있게 '번역'을 해서 다시 써야 합니다. PM에게 '우리끼리 보는 문서는 나중에 자료로도 남아야 하니까 우리의 언어를 써도, 윗분들에게 올라가는 보고서는 윗분들이 쉽게 이해할 수 있어야 한다. 정확성 보다 쉬운게 먼저다' 라고 여러번 이야기를 해도 '부장님이 워낙 쉽게 잘 쓰셔서 그러는데, 저희한테는 이게 쉬운 일이 아닙니다. '라고 합니다. 아니 무슨 20년차 PM이 원청사에게 못알아 들을 말을 하고 설득을 못하면 어떻게 하고.. 그걸 못한다고 당당하게 이야기 합니까. 저희 회사는 실무자들이나 엔지니어들한테 '보고서를 쓸때는 너네 언어로 쓰지 말고, 경영진의 언어로 써라' 라는 얘기를 귀에 딱지가 앉을 정도로 듣고 훈련을 받는데, IT 회사는 그런 것도 없나요. 원래 PM들이 이러는게 정상이고, 저희가 부당하고 과도한 기대를 하는 것인가요, 아니면 사람을 바꿔달라고 해야 하나요. 저도 하나하나 얹어지는 업무에 지쳐서 환승이직 고민하는데, 떠나더라도 이렇게 두고 가면 오래 같이 일해온 개발자들에게 엄하게 불똥이 튀는거 아닌가 걱정이 되네요. (제 예전 상사가 윗분들 지시에 차렷! 하고 하라는대로 인원/자원 줄여놓은거 제가 다시 다 복구해놨는데..)

30대 때는 서류가 무조건 들어갔는데, 요새 서류 몇 번 넣어봤는데 모두 서탈이네요. 친구한테 물어봤더니, 아무래도 나이제한에 걸릴 수 있다고 하네요. 서럽군요 ㅠ 참고로 대기업 -> 대기업 이직 준비 중입니다. 40대 분들은 어떻게 이직 성공하셨나요?

여기가 낮은 건지 보통 그런 건지 모르겠네요... 제가 전문연에서 도메인을 옮겨서 왔는데 이전 연봉 기준으로 20% 올려 줬다는데 여기를 갈 지 아니면 다른 곳을 갈 지 고민입니다

나이가 곧 40인대 열심히 관리를 했는대 일도 열심히하구요 누구보다 개인의 시간과 이득보다 회사의 이득은 위해 맡은바자리에서 열심히 살았는대 ... 하늘에서 저한테 준거라곤 좌측 눈 시력을 앗아가내요... 무슨 진료 한번받을라하니 여기 가니 저기 가라 돈은 돈대로 나가고. 신용이 좋지않아 신용카드를 못만듭니다. 정말 힘들어서 그냥 다 포기할까 고민도 했는대. 이 글 쓰는동안에도 마찬가지구요. 와이프가 한마디 해주더군요... 아픈게 너 탓 아니다.. 나랑 우리 아가 고양이들 너만 바라보는대 약해지지마라고 하더라구요. 너무 미안하고, 쪽팔리고 정말 힘이드내요. 이 자리를 빚어 다들 1년에 한번 꼭 눈 검사하세요. 눈이 문제가 터져야 알수있다보니 저도 눈은 검사도 따로 못했습니다. 비용이 비싸야 5만원인대 그걸 못해서 소중한 눈을 잃는다는게 슬프내요... 제가 끝까지 버틸수있을까요. 원인을 못찾아서 아직도 계속 각 종 검사와 진료만 보고 있으니 답답하고... 회사 바쁜대 계속 휴가. 반차 써야해서 눈치보이고 제가 버틸수 있을까요... 현실적인 조언 부탁드리며 응원글도 부탁드려봅니다. 긴 글 읽어주셔서 감사합니다.

한 회사에 오래 있게 됐습니다. 평균 근속년수가 2~3년 정도라고 하는데 저는 그에 비하면 몇배는 더 근무했네요. 회사는 알아주지 않다 못해 나가라고 압박하는 것 같습니다. 요즘은 번아웃인건지, 너무 지쳐서 일하기 싫고 옆사람 목소리만 들어도 화가 납니다. 기술부채는 쌓일대로 쌓여서 이직도 못할 것 같고 새로 시작하기엔...나이가 벌써 30중반대라 엄두가 안 나네요ㅜ 회사 내에서 인간관계도 망했는데 쌩퇴사 하고 회복하는건 어떻게 생각하시나요?

2026년 6월 18일(목) 진행된 SAP Clean Core Council 2026 세미나 내용입니다. Clean Core 가 대두되고 있는 중요한 키워드라 온라인 세션 자료들을 정리하여 공유 드리고자 합니다. Clean Core Journey with AI & Extensibility 1. 요약 SAP 고객은 시스템 업그레이드 시 발생하는 충돌/복구 작업을 최소화하고, AI/클라우드 서비스를 신속히 도입하기 위해 Clean Core 방식을 점점 더 요구하고 있습니다. Clean Core는 SAP 표준에 직접 손을 대는 전통적인 커스터마이징을 지양하고, SAP가 제공하는 공개 API와 클라우드 확장성을 활용하도록 유도합니다. 이를 통해 업그레이드 비용과 시간을 절감하고, 총소유비용(TCO)을 낮추며, AI/자동화 기능을 빠르게 적용할 수 있습니다. 2. Clean Core를 요구하는 주요 이유 주요 원인 구체적인 영향 SAP 객체와의 강한 결합 업그레이드 시 SPAU/SPDD 충돌이 빈번히 발생하고, 수동으로 해결해야 함 S/4HANA 빠른 진화 패치·서비스 팩 적용 시 커스터마이징 코드가 깨질 위험이 커짐 업그레이드 미실시 보안·지원이 중단되고, 클라우드 전환이 어려워짐 대규모 회귀 테스트 프로젝트 일정·비용이 크게 늘어남 기술 부채 누적 시스템 복잡도가 상승하고 유지보수 비용이 급증 Compatibility Pack(2026‑05) 종료 기존 레거시 기능이 사라져 재개발이 필요 클라우드 마이그레이션 장애 레거시 확장으로 퍼블릭 클라우드 전환이 어려워짐 3. 확장성 모델 S/4HANA Public Cloud S/4HANA Public Cloud는 이미 100 % Clean Core 구조를 갖추고 있습니다. 시스템은 3 개월마다 새로운 기능이 추가되는 방식으로 자동 업그레이드되며, 고객께서는 최소 6 개월마다 강제 업그레이드를 진행하셔야 합니다. 운영 인프라는 SAP가 직접 SaaS 형태로 제공하고 있습니다. 그럼에도 불구하고 Key User Extensibility(키 사용자 확장성) 기능은 그대로 제공됩니다. 사용자는 다음과 같은 작업을 수행하실 수 있습니다. 화면에 필드 추가 간단한 사용자 정의 로직 구현(예: BAdI 대체, 이벤트 핸들러) 메일 템플릿 및 워크플로우 커스텀 이러한 확장은 표준 코어를 건드리지 않으며, SAP가 정의한 Released API 또는 Extension Point 만을 활용합니다. ABAP Cloud (Classic ABAP 대비) ABAP Cloud는 기존 클래식 ABAP과는 다른 개발 패러다임을 제공합니다. 가장 큰 특징은 업그레이드 영향을 받지 않는 신규 개발 방법론이라는 점입니다. RAP(RESTful ABAP Programming) 모델을 기본으로 사용합니다. 개발자는 반드시 Released API만을 호출할 수 있습니다. 표준 테이블을 직접 SELECT하거나 INSERT하는 경우 컴파일 단계에서 오류가 발생합니다. 즉, 코드 수준에서 Clean Core가 엄격히 강제되어 향후 S/4HANA 업그레이드 시 충돌 위험이 원천 차단됩니다. 3.1 기본 구분 – On-stack(In-App) vs Side-by-Side(BTP) 구분 On-stack(In-App) Side-by-Side(BTP) 주된 목적 SAP 핵심 데이터·프로세스에 직접적인 확장 독립적인 애플리케이션·외부 시스템 연동 트랜잭션 처리 S/4HANA와 동일한 LUW(논리적 작업 단위) 별도 트랜잭션, API·이벤트 기반(비동기) 수명 주기 S/4HANA 업그레이드와 동기화 자체 배포·업데이트 주기(독립) 개발 환경 저코드/노코드(Key User 도구, SAP Build)·프로코드 ABAP Cloud·클래식 ABAP(프라이빗) 저코드/노코드(SAP Build)·프로코드 CAP, RAP, Java, JavaScript, Python 등 데이터베이스 SAP HANA (핵심) SAP HANA Cloud, PostgreSQL, SQLite(개발용) 등 다양한 PaaS DB 런타임 ABAP Environment ABAP Environment + Cloud Foundry/Kyma(Neo 종료 2028) UI 기술 SAP Fiori, SAPUI5 SAP Fiori, SAPUI5, React, Angular, Vue 등 데이터 접근 로컬 API(CDS, BAPI 등) 직접 호출 원격 API(OData, REST, SOAP, Delta Sharing) 주 사용 대상 내부 사용자 파트너·고객 등 외부 사용자도 손쉽게 지원 보안·인증 기존 S/4HANA 역할·권한 객체 활용 BTP ID·권한 관리와 외부 연동 가능 성능 DB 직접 접근 → 지연 최소 네트워크 오버헤드 존재 → 비동기 설계 권장 3.2 ProCode비교 항목 클래식 ABAP(온‑프레미스/프라이빗) ABAP Cloud‑온‑스택 ABAP Cloud‑BTP CAP·BYOL(BTP 런타임) 주 환경 ECC / S/4HANA 온‑프레미스/프라이빗 클라우드 S/4HANA Cloud (Public·Private) SAP BTP ABAP Environment (SaaS) SAP BTP Cloud Foundry·Kyma 등 언어 ABAP Cloud‑Optimized ABAP (BadI 포함) Cloud‑Optimized ABAP Java·Node.js·Python 등 툴 SE80/SE37/SE24, Eclipse ADT, Fiori UI, RAP, Key User 도구 Eclipse ADT, BAS, RAP + Key User 도구 Business Application Studio·VS Code BAS·VS Code 확장 스타일 직접 DB 객체 수정·Enhancement → 결합도 강함 In‑App 개발 – 로컬 API 활용 → 결합도 낮음 Remote API 전용 – 이벤트 기반 → 결합도 가장 낮음 Open‑Source 언어 기반 마이크로서비스 핵심 장점 DB 직접 접근·풍부한 기능 핵심 성능·통합 권한 관리 독립적 배포·클라우드 스케일링·AI 통합 용이 빠른 개발·언어 다양성·클라우드 네이티브 제한점 업그레이드 시 충돌·기술 부채 증가 일부 기능 차이·대규모 실시간 부하에 제한 있음 네트워크 지연·핵심 로직 비동기 설계 필요 원격 API 설계 필요·핵심 객체와 직접 연동 어려움 4. Clean Core 확장성 모델 4.1 Tier 개념 (구버전) Tier 1 – Cloud Extensibility 신규 앱·확장은 기본적으로 ABAP Cloud 기반을 요구합니다. 클래식 ABAP 사용이 불가능합니다. Tier 2 – Cloud API Enablement 온‑프레미스·프라이빗에서도 Tier 1을 적용할 수 있도록 SAP 표준 API 가 부족한 경우 Z‑객체로 래핑(후에 공식 API 로 교체)합니다. Tier 3 – Classic ABAP Extensions 기존에 존재하던 전통적인 커스터마이징 방식입니다. 가능한 한 폐기·전환·갱신 해야 합니다. 4.2 Level 개념 (현행) Level 정의 사용 예시 A – Released API SAP가 공식적으로 공개한 로컬·원격 API(안정성 보장). 최신 버전에서도 거의 변경되지 않음. Business Accelerator Hub에 있는 OData / CDS API B – Classic API 공식 발표는 없지만 다수 고객이 사용하고 있으며, 변경 로그를 통해 위험성을 추적할 수 있는 API. BAdI, Classic User‑Exit, BAPI 등 C – Internal 공개되지 않은 내부 객체. 변경 로그를 검토하고 대체 가능한 공개 API 가 없을 경우에만 사용. 내부 테이블/뷰에 직접 접근 D – Not Recommended 사용이 명시적으로 금지된 객체(예: 직접 테이블 구조 변경, Implicit Enhancement). 절대 사용을 금합니다. 4.3 업그레이드 영향 검토) 최신 Simplification DB 를 SAP For Me → CCMSIDB 에서 다운로드합니다. SYCM 트랜잭션으로 ZIP 파일을 임포트합니다. 대상 릴리즈(예: 2025 SPS03 → Core 109) 에 대해 영향받는 객체(함수·클래스·인터페이스·CDS 등)를 확인합니다. ALV 레이아웃에 “SAP Internal name”, “Release From” 컬럼을 추가하면 어느 시점부터 영향을 받는지 한눈에 파악할 수 있습니다. 5. Clean Core 진단 – ATC 활용 ATC(ABAP Test Cockpit) 에서 Clean Core Check Variant(노트 3627152)을 활성화합니다. ATC 결과는 다음과 같이 구분됩니다 ATC Priority Level (Clean Core) 의미 1 (Error) D 즉시 수정 필요 (사용 금지 객체) 2 (Warning) C 가능한 경우 다른 API 로 교체 권고 3 (Info) B 현재는 허용되지만 차후 변동 가능성 존재 ABAP For Cloud Development 로 작성된 코드는 자동으로 Level A 로 인식돼 ATC 에 포함되지 않습니다. 5.1 관리·거버넌스 패키지별(예: CBO 패키지) 정기 ATC 실행 → Cloud ALM Dashboard 에서 추세를 분석합니다. CTS 전송 전 ATC 결과를 검증하도록 정책을 적용합니다. 필요 시 코드 취약점 분석 도구와 연동해 보안까지 한 번에 관리합니다. 5.2 Remembrance 예시 PERFORM 호출은 Level D 로 표시됩니다. 해당 서브루틴을 로컬 함수 모듈이나 메서드로 복제하고 직접 호출하도록 변경합니다. 특정 클래스/함수가 삭제된 경우 노트에 제시된 후속 객체(successor) 를 찾아 코드 교체합니다. 대체 가능한 API 가 존재하지 않을 경우 해당 로직을 별도 사이드‑바이‑사이드 서비스로 옮겨 Clean Core 를 유지합니다. 6. AI‑지원 개발 – SAP Joule & Agentic 기능 기능 현재 제공 여부 향후 로드맵 코드 자동 완성(예측) ABAP Cloud 내 제공 – 단위 테스트 자동 생성(ABAP & CDS) 제공 – 코드 설명·ATC Fix 제안 제공 – Extensibility Assistant (영문) Public S/4HANA 에서 제공 2027년 다국어 지원 예정 RAP‑Model‑Driven Joule Integration 2026 Q3 예정 – AI 기반 Clean Core 자동 리팩터링 2027년 예정 – CDS 분석 모델 자동 생성(기본·확장) 2027년 예정 – ABAP AI Explain (Function Group / Behavior Definition / Vulnerability Analyzer) 2027년 예정 – MCP(다중 코드 검색) 도구 2027년 예정 – Agentic 대규모 코드 변환 & Clean Core 실행 파이프라인 2026 Q2–Q4 단계적 출시 – 활용 예시 (한국어/영어 자연어 입력) “고객 주문 화면에 ‘우선 배송’ 체크박스를 추가하고 OData API 를 활성화해 주세요.” → Joule 이 자동으로 UI 필드와 OData 엔드포인트를 생성합니다. “현재 프로젝트에서 사용 중인 BADi 목록과 대체 가능한 공개 API 를 알려 주세요.” → AI 가 BadI 를 찾아보고, 동일 기능을 제공하는 Released API 를 추천합니다. “새로운 엔터프라이즈 애플리케이션에 필요한 RAP 엔드포인트와 검증 로직을 코드로 만들어 주세요.” → RAP 기반 서비스와 기본 단위 테스트까지 자동 생성됩니다. 향후 Agentic 파이프라인은 대규모 레거시 코드 자동 변환, Clean Core 준수 자동 검사, AI 기반 리팩터링 제안 등을 제공하여 전환 비용을 크게 낮출 것으로 기대되고 있습니다. 7. 로드맵 요약 (2026‑2027) 2026 Q2–Q4 : Agentic 기반 IDE(IDEA/Eclipse/VS Code) 경험 제공 → 주요 LLM(Microsoft, Amazon, Google, Anthropic) 연동 2027년 전체 : AI‑지원 Clean Core 자동 리팩터링 도구 완전 출시, CDS 분석 모델 자동 생성 기능 제공 지속적인 SAP Build 저코드/노코드 스위트 AI 강화 (Public·Private 모두) 8. 결론 Clean Core 로의 전환은 단순히 “커스터마이징을 금지”하는 것이 아니라, 업그레이드 안정성 확보, 기술 부채 해소, 그리고 AI·클라우드 혁신을 빠르게 도입하기 위한 전략적 선택입니다. 1) 온‑스택과 사이드‑바이‑사이드 확장성을 상황에 맞게 조합하시고, 가능한 한 Level A/B 공개 API 를 활용 2) 정기적인 ATC 기반 Clean Core 진단과 Simplification DB 검토로 사전 위험을 차단 3) 최신 AI‑지원 개발 도구(SAP Joule, Agentic)를 도입하시면 코드 품질과 생산성을 동시에 끌어올릴 수 있음 위 원칙을 체계적으로 적용하신다면 기존 레거시 시스템에서도 최소한의 리스크로 최신 SAP 기능과 AI 서비스를 도입가능

AI와 SAP의 새로운 만남 발표자: Mock Seng (SAP Singapore, Enterprise Architect) - AI 시대에 Clean Core가 왜 본질적으로 중요한지를 고객 사례 중심으로 풀어냄. 현재 디지털 혁신이 급속히 진행되는 시점에서 경영진은 AI를 즉시 업무에 적용하고 싶어합니다. 그러나 기존 SAP 시스템(특히 ECC 6, S/4HANA)위에 단순히 AI 레이어만 얹는 것으로는 근본적인 변화를 기대하기 어렵습니다. 전통적인 SAP 아키텍처는 데이터가 분산되고, 맞춤화가 깊으며, 배치‑기반 통합이 주류를 이루고 있기 때문에 AI가 요구하는 실시간, 유연, 통합된 환경과 큰 격차가 존재합니다. 따라서 AI를 진정으로 활용하려면“AI on top of SAP”를 넘어 “AI inside SAPprocesses”로 전환하는 전략이 필요합니다. 본론 1. 전통 아키텍처와 AI 요구사항 간의불일치 강연자는 다섯 가지 주요 불일치를 강조합니다. - 데이터 통합 부재 – 전통 시스템은 트랜잭션, 히스토리, 운영 신호가 각각 다른 저장소에 흩어져있어 AI가 필요로 하는 ‘통합된’ 데이터셋을 만들기 어렵습니다. - 과도한 맞춤화 – 고객별 맞춤 기능이 복잡하게 얽히면 새로운 AI 기능을 도입하거나확장하는 데 비용, 시간이 급증합니다. - 비즈니스 컨텍스트 부족 – AI는 데이터 자체는 잘 처리하지만, 데이터 뒤에 숨은 복잡한 비즈니스 규칙이나 연결성을 스스로 이해하지 못합니다. - 실시간 연계 한계 – AI는 이벤트‑드리븐 방식의 ‘느슨한’ 통합을 선호하지만, 기존 ERP는 배치 혹은 포인트‑투‑포인트방식에 의존합니다. - 수동, 자동 프로세스 혼재 – 엑셀, 전화, 채팅 등 인간이개입하는 절차가 여전히 존재하면 AI가 전반적인 프로세스를 자동화하기 어려워집니다. 이러한 격차를 해소하지 않으면 AI 도입효과는 표면에 머무르고, 실제 비즈니스 가치는 제한적일 수밖에 없습니다. 2. ‘Clean Core’ 원칙 – 지속 가능한 AI 환경의초석 연사는 5 Clean Core 원칙을 제시합니다. 이는 SAP 환경을 AI‑친화적으로 만들기보다 건전한 코어를 유지함으로써 장기적인 혁신을 가능하게 하는 설계 지침입니다. - 운영 – 운영 효율성을 높이고, 거버넌스를 통해 코어와 확장성을 지속적으로모니터링합니다. - 데이터 – 최신 표준에 맞춘 데이터 관리로 일관성과 품질을 확보하고, 예측, 분석에필요한 기반을 마련합니다. - 프로세스 – 프로세스 표준화를 통해 비즈니스 성과를 극대화하고, 불필요한수작업을 최소화합니다. - 통합 – 안정적이며 유연한 통합 구조를 구축해 시스템 간 데이터 흐름을 원활하게 합니다. - 확장성 – 표준 코어와 확장 모듈을 명확히 구분해 유지보수 비용을 낮추고 업그레이드 주기를 단축합니다. ‘Clean Core’를 실천하면 AI가 필요로 하는 통합 데이터, 실시간 연계, 확장 가능한 구조를 자연스럽게 갖출 수있습니다. 3.AI 전략 로드맵 – 비즈니스와 기술의 균형잡기 AI를 성공적으로 정착시키기 위해서는 비즈니스 우선순위와기술 구현 가능성을 동시에 고려한 로드맵이 필요합니다. - 현황 분석 – 현재 SAP landscape와 비즈니스 프로세스를 진단하고, AI 적용이 가장 큰 가치를 창출할 영역(예: Procure‑to‑Pay, Finance 등)을 선정합니다. - 데이터 정제 및 통합 – 데이터 레이크 혹은 SAP DataWarehouse Cloud 등을 활용해 분산 데이터를 하나로 모으고, 품질 관리를 체계화합니다. - AI 파일럿 구축 – 저코드툴인 Joule Studio를 이용해 초기 AI 에이전트를빠르게 프로토타이핑하고, A2A(애플리케이션‑투‑애플리케이션) 인터페이스로 기존SAP 모듈과 연결합니다. - 거버넌스, 컴플라이언스 설계 – AI 에이전트가 수행하는 의사결정에 대한 투명성, 추적성, 규제 준수를 확보하는 프레임워크를 미리 구축합니다. - 점진적 확장 – 파일럿 성공 사례를 기반으로 프로‑코드 에이전트를 개발하고, 전사적 ‘Autonomous Suite’(Finance, Procurement, HCM 등)로 확대합니다. 이러한 단계적 접근은 급격한 변화를 억제하면서도 지속적인 혁신 여지를 남깁니다. 4.Autonomous Enterprise와 AI Golden Path 연사는 Autonomous Enterprise 모델을 제시합니다. 여기서는 사람은 방향을 제시하고, 디지털어시스턴트가 조율하며, AI 에이전트가 실제 작업을 실행합니다. 가장대표적인 사례는 Autonomous Procure‑to‑Pay이며, 구매 요청 자동 최적화, 계약 관리 자동화, 인보이스 검증, 지출 예측 등이 에이전트에 의해 수행됩니다. ‘AI Golden Path’는 이러한 자율 운영을 실현하기 위한 아키텍처 가이드라인입니다. 핵심 요소는 다음과 같습니다. - A2A, MCP 기반 상호 운용성 – 시스템 간 데이터 교환을 표준화하고, 유연성을확보합니다. - Joule Studio를 통한 저코드 에이전트 개발 – 비즈니스 사용자가 빠르게 프로토타입을만들 수 있습니다. - 프로‑코드 에이전트를 SAPBTP 위에 배치 – 복잡한 로직도 안정적으로 운영할 수 있습니다. - 양방향 통신을 통한 실시간 데이터 교환 – AI와 ERP가 실시간으로 상호작용합니다. Golden Path를 따르면 복잡한 시스템 간 연결 고리를 최소화하고, 에이전트 관리, 배포, 모니터링을 일원화할 수 있습니다. 5. 도구와 원칙의 결합 – Agent‑led Toolchain ‘Architecture withouttooling causes fracture’, ‘Toolingwithout principles has no grounding’이라는 두 경고문이 강조하듯, 툴체인과 원칙은 서로 보완해야 합니다. - 툴체인 – SAP BTP, SAP DDA, LeanIX, Signavio,Cloud ALM 등으로 구성된 전체 개발, 운영 파이프라인이 제공됩니다. - 원칙 – 앞서 소개한 5 Clean Core 원칙이 툴체인의설계, 운영 기준이 됩니다. 두 요소가 결합될 때만 시스템 파편화를 방지하고 지속 가능한 AI 적용 환경을 구축할 수 있습니다. 6.SAP이 제공하는 지원 포트폴리오 연사는 SAP 자체가 ‘Clean Core Journey’를 지원하는 다양한 서비스와 솔루션을 소개합니다. - RISE with SAP Methodology – 클라우드전환과 혁신 프로젝트를 일괄 지원합니다. - AI Golden Path & Agent‑led Toolchain – 설계, 구현, 운영 전 과정을표준화합니다. - Data Volume Management & Process InsightsDiscovery – 데이터 정제와 프로세스 가시화를 제공합니다. - Joule for Developer / Consultant – 저, 고코드개발자를 위한 통합 개발 환경을 제공합니다. 이러한 에코시스템을 적극 활용하면 기업 내부에서 별도로 구축해야 할 비용과 위험을크게 줄일 수 있습니다. 결론 – 성공적인 AI‑기반 SAP 전환을 위한 핵심 인사이트 1️. 데이터 통합이 전제조건 – AI는 통합된 고품질 데이터를 전제로 하므로, 데이터 레이크 혹은 클라우드 데이터 웨어하우스에 대한 투자가 필수입니다. 2️. Clean Core 원칙으로 아키텍처 재설계 – 운영, 데이터, 프로세스, 통합, 확장성 다섯 축을 균형 있게 관리하면 기존 맞춤화의 복잡성을 낮추고 AI도입 비용을 최소화할 수 있습니다. 3. 단계적 로드맵과 파일럿 검증 – 저코드 툴인 Joule Studio로 빠르게 파일럿을 구축하고 거버넌스, 컴플라이언스를 동시에설계함으로써 위험을 조기에 발견하고 고도화할 수 있습니다. 4️.Autonomous Enterprise는 조직 문화와 기술 모두를 요구 – 사람은 ‘디렉터’, 어시스턴트는 ‘코디네이터’, 에이전트는 ‘실행자’라는 새로운 역할 모델을 명확히 하고, 이를지원하는 거버넌스 구조를 확립해야 합니다. 5️.AI Golden Path와 Agent‑led Toolchain의 일관된 적용 – 표준 아키텍처 가이드와 도구 체인을 동시에 활용하면 시스템 파편화(Fracture)를 방지하고장기적인 확장성을 확보할 수 있습니다. 결국 AI 시대에 SAP 환경을 성공적으로 전환하려면 ‘기술’보다 ‘전략과 원칙’에 더 많은 무게를 두어야 합니다. SAP가 제공하는 풍부한 클라우드, AI, 툴 체인을 활용하면서Clean Core 원칙을 중심으로아키텍처를 재정비한다면, 기업은 ‘AI on top of SAP’를넘어 ‘SAP 안에서 스스로 학습, 진화하는 Autonomous Enterprise’를 현실화할 수 있을 것입니다.

전직장 업계랑 현재 업계가 완전히 다른데 전직장 업계 관련한 유료자문 요청을 받아봤습니다! 혹시 현재 회사에 유료자문 예정이라는걸 알려야되나요..? 다른회사에서 돈을 받는 뭔가를... 처음해보다보니 겸업금지 이런데 걸리지는 않는거죠..? 궁금합니다!

제목그대로 AI직군 석사졸업 신입초봉은 어느정도 주면될까요? 학교는 서/연/고/카/성 정도 출신이라고 가정했을때 입니다. 이번에 뽑을 직원들 네이버/카카오 수준으로 맞춰주려고 하는데 지인들한테 물어봐도 모른다고 하네요..

공동창업 이후 반복된 금전 요구에 대해 여러분의 의견을 듣고 싶습니다. 저와 상대방은 각각 수십 년의 개발 경력을 가진 개발자로 공동창업을 하였고, 함께 서비스를 개발하여 고객사에 실제 론칭 및 운영까지 진행하였습니다. 창업 당시 두 사람 모두 각자의 직장 처우에 불만이 있어 창업을 선택하였고, 퇴사 시기가 약 2주 정도 차이가 있었습니다. 그런데 상대방은 갑자기 제가 직장에서 받던 급여의 절반을 나누어 달라고 요구하며, “동업이니 그때부터는 나누는 것이 당연하다.“고 주장했습니다. 안타까운 마음에 일부 금액을 지급하였습니다. 이후 상대방의 지인이 개인사업자로 공공기관 입찰에 참여하려 하였고, 다만 참여 요건상 ‘소프트웨어 개발 법인’이어야 하는 구조여서 저희 창업한 법인체의 명의가 필요하였습니다. 저는 제안요청서를 검토하던 중 정보시스템 감리 수행계획이 포함된 점을 확인하였습니다. 사업 규모에 비해 리스크가 크다고 판단하여 개인사업자를 법인으로 전환하거나, 우리 즉 두 공동창업자가 프리랜서 계약으로 참여하는 방안을 제안했습니다. 그러나 상대방은 “사업을 섞기 싫다는 것이냐.“며 화를 냈고, “지인이 법인회사 전환 하기 싫어할 것이고 시간도 없다” 하여 결국 제 의견은 받아들여지지 않았습니다. 입찰서 역시 상대방이 작성하지 못해 대부분 제가 급히 작성하였고, 일부 수정 후 낙찰되었습니다. 이후 저는 정보시스템 감리 계획을 발주처와 협의하여 조정해 보자는 의견을 냈지만, 상대방은 “그 말 했다가 계약이 취소되면 책임질 것이냐.“며 반대하였고, 결국 저는 해당 사업의 논의 과정에서 사실상 배제되었습니다. 결과적으로 그 사업은 개발 기간이 예상보다 두 배 가까이 지연되었고, 상대방은 그 사업에 계속 투입되었습니다. 그동안 공동창업 회사의 업무는 대부분 제가 혼자 수행하며 신규 기술을 도입하고 기존 고객사 서비스를 유지해야 했습니다. 이후 저는 오랜 지인의 제안으로 수억 원 규모의 공공 프로젝트 입찰에 참여하였으나 낙찰되지 않았고, 그 회사에서 저를 채용하려 하였습니다. 저는 대신 공동창업자를 소개하여 프리랜서로 근무할 수 있도록 연결해 주었고, 그는 수개월간 근무하였습니다. 저는 그 회사를 먼저 떠났고, 이후 별개의 대규모 프로젝트를 개인 자격으로 계약하여 참여하게 되었습니다. 그런데 상대방이 위 회사와의 계약 종료를 앞둔 시점이자 제가 새로운 프로젝트에 투입된 지 약 2주 정도 되었을 때부터 갑자기 제 개인 프로젝트를 거론하기 시작했습니다. 상대방은 수개월 동안 반복하여, * “그 계약 깨라는 건 아니다.” * “수익을 나누는 것이 당연한 것 아니냐.” * “법인 계약에서 혼자 수행한 수익도 돌려줘야 하는 것 아니냐.” 라는 취지의 요구를 계속하였습니다. 저는 공동창업과 개인 계약은 구분되어야 한다고 생각했지만, 상대방은 약 4개월 이상 이러한 요구를 반복하였습니다. 여러분이라면 이러한 상황을 어떻게 보시겠습니까? * 공동창업이라는 이유만으로 개인 계약 수익까지 당연히 공동 분배 대상이 된다고 보시나요? * 별도의 합의 없이 수개월간 반복적으로 이러한 요구를 하는 것이 일반적인 공동창업 관계에서 받아들여질 수 있는 행동이라고 생각하시나요?

안녕하세요. 서버 개발은 외주에서 하고 있는데 앱에서 API를 통하지 않고 직접 DB에 붙어서 하라는데 어떻게 생각하시나요? 앱에서 내장DB사용하는것도 아닌데... 지금까지 API없이 DB직접 붙어서 한적도 없고 붙어서 하라는 얘기도 첨들었네요.

지금은 단순히 하네스 엔지니어링으로 이야기나오겠지만 약3개월 뒤부터는 기존 llm들의 추론능력만 빌려서 각자 자기만의 세계를 투영한 ai월드모델을 만들면서 자기만의 개인비서가 한개씩 생길거 같다. (자비스같은 종류? 본질은 다르지만) llm의 기존 ai월드모델 생성법을 거꾸로 사용하여 자기만의 룰을 집어넣어, 어떤llm이 사용하든 똑같은 서비스를 제공하고 앞으로 그런 개인화된 ai월드모델을 사용하는 칩셋이 개발되면 더욱 재밌는 걸 할 수 있는 세상이 되지 않을까 상상한다. 오푸스 4.6버전부터 가능성이 보여, 개선중이지만 아직은 몇개의 부속품이 빠진거 같다. 최근 발표자료를 만드는데, 어덯게하면 이런걸 어필할수 있을까. 고민하다보니 재밌을거 같아서 적어본다.

테스트 테스트테스트ㅛㅔ트

요즘 눈 떠 보면 제일 많이 듣는 단어는 AI일 것이다. 정부에서는 AI 3대 강국으로의 도약을 이루겠다고 하고 AI 관련 예산이 도처에 넘쳐나니 그럴만도 하다. 그런데 기업이 막상 AI를 어떻게 적용할 것인가를 생각하면 막연하게만 느껴진다. 이러한 관점에서 생각해 보아야 할 것이 AX다. AX는 AI Transformation을 의미하는 것으로 PI(Process Innovation), DX(Digital Transformation)의 연장선상에 있는 개념이다. 그러니까 AX는 AI를 기업의 경영활동 전반에 도입해서 업무 혁신을 시도하려는 활동인 셈이다. 그런데 여기에서 기업의 AX 전환은 AX를 대하는 기업 임직원들의 인식 수준에 따라 성공 여부가 결정된다. 상용화된 솔루션이나 LLM을 무작정 도입하는 것만으로는 기업의 성공적인 AX 전환을 기대하기 어렵다. 자칫 LLM 만능주의에 빠져 Chat GPT나 Gemini 같은 AI를 월 사용료를 내고 사용하면 모든 문제를 해결할 수 있다고 생각한다면 그건 마치 아무것도 하지 않겠다는 것과 다름이 없게 된다. 기업의 진정한 AX 전환은 해당 도메인과 기업의 특성에 맞는 AI module이나 AI Agent의 개발과 sLLM 기반의 대화형 챗봇서비스 등과 같은 기술 개발과정이 선행되어야 비로소 가능해진다. 이 과정에서 RAG나 Fine tuning 등과 같은 기법들도 자연스럽게 적용될 것이다. AX 전환은 더는 선택이 아닌 필수인 상황에서 기업들의 AX 전환을 통한 경영혁신이 성공하기 위해서는 해당 기업 임직원들의 AX에 대한 인식이 전제되어야 하는 이유가 바로 여기에 있는 것이다.

요새 si쪽 사업 pm, pmo뽑던데 처우는 대충알고 있고 워라밸 어떤지 궁금함다. 스드스가 워라밸 좋다던데 외부 플젝도 그러한디 궁금합니다요.