# 디지털 트랜스포메이션(DX)을 좀 거칠게 정의한다면 엑셀을 데이터베이스로 바꾸는 것이라고 할 수 있다. 아 물론 종이 서류에서 엑셀로 옮겨...
Canonical: https://social-archive.org/hyungyunlim/I1AMn8aHz5
Original URL: https://www.threads.com/@pakyoungrok/post/Dew0hkUib-H
Author: 박영록
Platform: threads
Share mode: full
## Content
디지털 트랜스포메이션(DX)을 좀 거칠게 정의한다면 엑셀을 데이터베이스로 바꾸는 것이라고 할 수 있다. 아 물론 종이 서류에서 엑셀로 옮겨간 것도 일종의 DX지만, 이건 진정한(?) DX는 아니라고 하자. 엑셀을 DB로 바꾸는 건 미디어만 바뀌는 거 아니냐 할 수 있지만, 전혀 다르다. DB 위에 올라간 소프트웨어로 데이터를 다룬다는 것은 데이터가 정형화된 상태로 공급이 되어야 가능하다. 실무에서의 엑셀은 정형화된 데이터를 다룰 것 같지만, 실제로는 담당자의 무수한 수작업이 들어가서 완성된다. 사람이 눈으로 보고 판단하고, 값을 고치고, 형식을 바꾸어서 업무가 돌아가게 만드는 것이다. 그래서, 이미 엑셀로 하고 있는 업무니까 쉽게 자동화하겠지 하고 덤비다가 큰 코 다치는 경우가 많다. 분명 엑셀 서식 그대로 DB에 담고 담당자가 말하는대로 프로세스를 구현했는데, 실무에서 쓰려고 하면 담당자들은 이것도 그동안 엑셀에서 누렸던 자유도를 요구하기 시작한다. --- 이 필드 좀 내가 고치게 해주세요. 이 필드는 경우에 따라 숫자가 들어가기도 하고 문자가 들어가기도 해요. 이 필드는 여러 개의 값을 쉼표로 구분해서 적기도 해요. 여기는 두 줄로 값을 적어요. 이 필드는 엑셀 수식으로 계산한 값인데, 직접 적어넣기도 해요. 이 필드는 수식으로 계산한 값을 보고 내가 임의로 보정한 값이에요. 업무에서 발생하는 다양한 변수들을 극복하기 위해 실무자들은 엑셀의 다양한 기능을 활용해서 데이터를 보정해서 일을 돌아가게 만든다. 그들의 노력은 실용적인 방향이지만, DB 위에 올라가는 소프트웨어에서 커버하기엔 너무 많은 기능이 필요해진다. 그래서, 엑셀로 하던 일을 DB로 잘 옮겨서 돌아간다는 건 이 모든 데이터 정제 과정을 소프트웨어로 잘 소화해냈다는 의미가 된다. 그래서 이 자체만으로도 성공적인 DX의 증거가 된다. 근데 DB로 옮기는 게 왜 중요한가? 데이터들이 연결되기 쉽기 때문이다. --- 입고, 발주, 주문, 출고를 다 엑셀로 다루면 이 데이터를 연결시키기가 매우 어렵다. 이 데이터를 다 연결해야 주문 기준 매출도 나오고 회계 기준 매출도 나오고 재고도 나오고 손익도 카테고리별로 따져볼 수 있다. 그런데, 엑셀은 실무자들이 데이터 정합성을 잘 지켜서 쓰지 않기도 하거니와, 여러 데이터를 연계하려면 많은 노력이 필요하기 때문에 데이터 연계가 안된다. 그래서, 원천 데이터가 다 엑셀에 있는데도 거기서 가치 있는 데이터를 뽑아내기 어려운 것이다. 그런데, 이게 다 DB에 들어갔다는 얘기는 일단 정합성을 다 맞췄다는 얘기고, 데이터를 엮어서 쿼리도 할 수 있게 되었다는 얘기다. 그래서 고객 주문이 들어오는 순간 이 주문으로 인한 손익 증가분이 바로 계산되고 출고 준비가 되고 재고 변동이 계산되면서 다음 발주분도 계산이 가능해지는 것이다. 그럼 최근의 클라우드 기반 엑셀이나 구글 스프레드시트에서 그렇게 정규화 잘 해서 써도 되는 거 아니냐고 할 수 있다. 맞다. 하지만, --- ==도구가 주는 어포던스는 생각보다 강력하다. 엑셀이든 구글스프레드시트든 그걸 쓰면서 사람이 이거 한 칸만 고치면 1분만에 문제 해결되는데 뭐 복잡하게 시트 간 연계와 수식들을 건드려야 하나 하는 생각을 떨쳐내게 하기란 매우 어렵다. 그래서 엑셀 고인물이 나타나서 수식으로 쫙쫙 다 연결하고 원천 데이터만 한 곳에서 입력하면 되도록 만들어 놔도 누군가 고치고 수작업을 해서 망쳐놓곤 한다.== 물론 그럼에도 불구하고 거의 DB 쓰듯이 잘 정규화해서 쓰는 팀도 존재한다. 난 딱 한 번 봤다. 그 팀은 팀원 간에 충분히 소통해서 잘 합의도 되어 있었다. 뛰어난 팀은 어떤 도구를 쓰던 잘 해내는 법이다. 하지만 이쯤되면 들어가는 노력의 크기가 개발하는 것과 별반 차이가 없어진다. ==결국 DX의 핵심은 데이터를 정규화된 형태로 잘 유지하는 것인지라, 수식과 엑셀 스크립트로 코딩을 하느냐, 범용 프로그래밍 언어로 코딩을 하느냐의 차이일 뿐이다.== --- 그런데 요즘 AI로 인해 상황이 많이 달라졌다. 예전에는 DX를 해야 얻을 수 있었던 것들을 AI로 얻을 수 있게 된 것이다. AI는 정형 데이터에 비정형 데이터가 조금씩 섞인 것들을 기가 막히게 잘 다룬다. 여러 파일들을 엮어서 보고서를 뽑아내는 것도 잘한다. 그래서 이제 DX를 건너띄고 AX를 해도 나쁘지 않다. 소프트웨어를 개발해서 해결하던 문제들을 이제 그냥 AI에게 시키면 된다. 그러나, 여기에 머무르는 건 아쉽다. 더 좋은 것은 AI에게 DX를 시키는 것이다. 특히 데이터 양이 클수록 AI에게 매번 작업을 시키는 것은 비효율적이다. 반면, AI가 데이터베이스에 모으고 그 위에 소프트웨어를 만들어서 올리면 DX의 효율을 매우 저렴한 비용으로 낼 수 있게 된다. 그래서, 나는 AX를 "AI로 DX를 하는 것"이라고 정의하는 것을 좋아한다. 물론 AX의 범위는 이거 말고도 넓지만, 이게 가장 중요한 출발점이라고 생각한다.