철학과 전략을 기반으로 한 경험과 사유의 기록은 다음세대의 설계에 담긴다
2000년대 초, 나는 기업의 고객기준정보(Customer Master)를 담당했습니다. 당시에는 기준정보관리(MDM, Master Data Management)솔루션이 제대로 갖추어져 있지 않았으며, Global ERP가 등장하기 전이라 SAP가 법인별(Client)로 설치되어 운영 중이었습니다. 즉, 기업의 ERP가 물리적으로 여러 개의 다른 시스템으로 나뉘어 있었습니다.
A라는 고객사의 고객명이 바뀌면, 아래와 같이 전사공지를 했습니다.
[공지 예]
제목 : A고객(코드:XXX, 고객명:A) 정보 변경의 건
내용 : A고객의 정보가 아래와 같이 변경되오니 영향이 있는 시스템 혹은 부서에서는 사전에 준비해 주시기 바랍니다.
- 변경일자 : 0000년 00월 00일 00시
- 변경내용 : 고객명 (000 → 000)
- 문 의 : 고객기준정보 담당 000 (T.0000)
모든 시스템 담당자와 책임자에게도 메일을 보내고 시스템 유지보수 협력사에도 공지를 했습니다. 고객정보를 인터페이스 해 가는 시스템 담당자와 함께 영향도 분석을 하고 변경작업에 대한 계획을 수립하는 회의도 했습니다.
대략, 일주일 정도는 관련 응대를 했습니다. '우리 부서에서 관리하는 시스템에도 고객정보가 있는데 어떤 영향이 있는가?'와 같은 질문에 대응하는 일이었죠. 준비를 철저히 하고 변경을 해도, 제품을 출하하는데 서류상에 이전 고객명으로 표기가 되는 등의 이슈는 발생했습니다.
변화해야 했습니다.
먼저, 해외법인 포함 전사 공통으로 사용하는 고객정보관리시스템(Application)을 만들었습니다. 이 시스템에서 정보가 업데이트되면 모든 SAP 내의 고객기준정보가 동시에 업데이트되는 구조로 설계했습니다.
이후, 고객기준정보는 이 시스템만을 사용하게 했습니다. 사람에게 부여되어 있던 SAP상의 고객기준정보 생성권한을 모두 회수했고 주기적으로 법인 SAP의 정보를 읽어서 데이터가 일치하는지 확인했습니다. 처음에는 물리적으로 분리되어 있는 여러 SAP에 직접 접속해서 데이터를 확인했고, 이러한 확인작업을 자동화하여 문제가 생기면 나에게 통보가 오게끔 조치했습니다.
영업담당자(Sales Person)와 같이 영업에서만 사용하는 추가 정보는 영업 시스템에서 입력할 수 있도록 했으며, 그 마저도 2개 이상의 시스템이나 모듈, 부서에서 사용하는 정보로 그 활용의 범위가 바뀌면 전사공통영역으로 분류하여 중앙통제하에 관리하려 노력했습니다.
한계는 있었습니다. 우선, 해당 정보를 관리하는 부서에서 관리권한을 본사에 넘기기 싫어했는데, 관리하던 정보를 누군가와 나누기 위해 표준화하고 승인절차를 만드는 것에 대한 저항이었습니다. 시스템 상의 물리적 어려움도 있었습니다. 오래된 시스템은 코드가 아닌, 고객명이나 주소 등의 텍스트 정보의 일부를 읽어 로직으로 반영한 경우도 있었는데, 이런 시스템들에게 코드와 텍스트 정보의 변화는 재앙이었습니다.
그럼에도, 고객기준정보시스템은 그 역할을 톡톡히 했습니다. 특히, 법인에서 좋아했습니다. 과거에는 본사에서 코드와 정보를 내려주면 그 내용을 SAP에 입력하다 오류(Human error)가 나기도 했고, 담당자 부재중에는 IT주재원이 직접 그 일을 하기도 했습니다. 그분들은 '내가 이런 것까지 해야 하냐'며 하소연을 했는데, 그 모든 이슈가 해결되었습니다.
여전히, 나 스스로는 만족할 수 없었습니다. 관리체계는 잡혔으나, 여러 시스템의 고객정보가 실시간으로 완전히 동일하지는 않았으니까요. 구조적 한계입니다. 고객기준정보시스템의 고객 정보를 실시간 활용하는 구조가 아닌, 이 정보를 여러 시스템이 인터페이스 해서 가져가는 구조였습니다. 즉, 같은 정보가 여러 시스템에 여러 테이블 안에 담겨 있었죠. 논리적으로는 같으나, 물리적으로는 달라질 수 있는 구조입니다.
인터페이스 주기에 따라 일시적인 정보비대칭 현상이 발생했고, 또 인터페이스에 오류가 생기기도 했습니다. 고객정보를 활용하는 시스템이 무엇이며 인터페이스 주기는 얼마나 되는지, 담당자는 누구인지 등을 엑셀로 관리하고 통제하며, 고객정보변경에 따른 이슈가 줄어들기는 했으나 완벽하지는 않았습니다.
'새로운 고객이 생기면 영업에서 가장 먼저 나에게 연락을 한다. 영업에서 사용하는 시스템에 고객정보를 관리하려면 고객코드가 필요하기 때문이다. 내가 생성하는 고객정보를 다른 시스템이 인터페이스 해 가지 않고 바로 사용하는 방법은 없을까? 고객명이 바뀌든, 주소가 바뀌든 나만 변경을 하면 되지 않는가.'
당시에는 기술적으로나 여러 다른 이유로 방법이 없었습니다.
기준정보관리체계는 전체 데이터 관리로 확대 되어 데이터 거버넌스가 정의되었고, 데이터를 가져가는 방식에 변화가 생겼습니다. 데이터창고(DW, Data Warehouse)에 정보가 담기면 이러한 정보를 필요로 하는 시스템들이 이를 가져가 별도의 데이터마트나 테이블에 담아 활용하는 구조로 진화되었습니다. 그러나, 인터페이스 오류, 데이터 분절로 인한 문제 등 과거의 이슈가 완전히 해결된 것은 아니었습니다.
팔란티어가 이를 해결할 수 있는 구조를 만들어냈습니다. 팔란티어의 온톨로지는 고객이라는 존재를 기업 전체가 공유하는 하나의 소스로 정의합니다. 데이터는 여전히 흐릅니다. 다만 그 흐름을 온톨로지가 중앙에서 관장하기 때문에, 주기도 오류도 더 이상 사람이 추적할 필요가 없습니다. 물론, 온톨로지 안에서 고객을 어떻게 정의할 것인지는 기업의 몫으로 남습니다.
지난 글, 기업 온톨로지에서 기업의 온톨로지를 정의하는데, SAP를 최초 도입했던 PI(Process Innovation) 1기부터 디지털전환까지를 경험한 시니어 전문가들을 활용해아 한다고 한 이유가 여기에 있습니다. 그들은 기업의 프로세스를 정의하고 시스템화하며 온톨로지의 필요성을 경험으로, 필연적으로 알고 있는 사람들입니다.
시스템이 없던 혹은 데이터 거버넌스가 정리되지 않은 시대에 기업의 혁신을 실행했던 사람들은 데이터 센터가 무너지고, 에너지 공급에 문제가 생겨도 수작업으로라도 기업을 운영할 수 있는 지식을 가지고 있습니다. 이들이 디지털 네이티브 세대와 함께 우리 기업의 온톨로지를 구축해야 하는 이유입니다.
지금의 우리가 당연하게 생각하는 데이터, 에너지, 시스템이 당연하지 않다는 것을 안다는 것은 그것의 소중함을 아는 것입니다. 그 소중함은 이들에 문제가 생기더라도 기업을 운영할 수 있는 대책을 수립하게 합니다. 그리고, 그 모든 것을 최신의 기술과 전략으로 감싸 안아야 합니다. 그 기술은 네이티브 세대가 주도해야 합니다.
그럼, 전략은?
과거에는 전략만큼은 시니어 세대가 더 잘할 수 있다고 생각했습니다. AI가 등장하고 제가 AI를 활용한 1인 연구소를 운영하며 생각이 바뀌었습니다. 네이티브 세대가 기술을 활용하고 과거를 분석해서 더 멋지게 잘 해낼 것이라는 믿음이 생겼습니다.
내가 할 일은 지금 쓰고 있는 이 매거진 <기술과 사유: 닫힌 설계에서 열린 흐름으로>에 다음 세대가 참조할 수 있는 내용을 텍스트로 남기는 것입니다. 이 텍스트를 그들이 혹은 AI가 읽어 영감을 얻을 수 있도록.
글쓴이 정원 | 전략연구소<결> 독립연구자 | 전략 자문 | "사유와 실천의 물결"
자신의 정원을 가꾸어 가는 당신께, 이 글을 전합니다.
이 글은 전략연구소<결>의 고유한 사유의 결과가 포함되어 있습니다. 콘텐츠를 알아봐 주시고 공유해 주시는 것은 언제나 환영합니다. 다만, 인용 시에는 출처를 명확히 밝혀주시고 작성자의 철학이 왜곡되지 않도록 배려해 주시길 부탁드립니다. 영리 목적의 재가공이나 영상 제작 등은 사전 협의와 서면 동의가 필요합니다.
이 글이 도움이 되셨다면, 전략연구소<결>의 독립 연구를 응원해 주세요.
© 2026 전략연구소<결> GYEOL Strategy Institute. All rights reserved.