초록
DX 전환 프로젝트는 이름만 DX이고 실제 범위는 마케팅 사이트 리뉴얼로 끝나는 경우가 많습니다. 현장 pain은 대개 승인·정산·재고·리포트처럼 보이지 않는 백오피스에 있습니다. DX를 성공으로 부르려면 “디지털 채널”과 “업무 OS”를 같이 봐야 합니다.
이 글은 DX를 ① 가시적 채널(웹·앱·키오스크) ② 운영 백본(ERP·WMS·CRM 연동) ③ 의사결정(리포트·대시보드) 세 레이어로 나누고, 레거시가 있을 때 흐름 역산 → Quick Win → 플랫폼 정리 순서를 제안합니다.
1. DX가 멈추는 전형적인 이유
- 채널만 바꿈: 프론트는 새로운데, 주문·정산·CS는 여전히 엑셀·카톡.
- 부서별 미니 시스템: 팀마다 Notion·시트·간이 DB → 데이터 주인 불명.
- 일회성 프로젝트: 오픈 후 유지보수·권한·교육 예산 없음.
DX는 “한 번의 출시”가 아니라 데이터가 한 줄로 흐르게 만드는 연속 작업에 가깝습니다.
2. 세 레이어로 범위 잡기
| 레이어 | 질문 | Bluefoxdev에서 흔한 납품 |
|---|---|---|
| 채널 | 고객·파트너가 무엇을 보나? | Digital Product, Web/App |
| 백본 | 주문·재고·정산이 어디에 쌓이나? | Internal System, API 연동 |
| 운영 | 배포·모니터링·장애는 누가 보나? | Cloud & DevOps, Managed Service |
세 레이어 중 하나만 고르면 DX KPI(리드타임·오류율·인건비)가 안 움직이는 경우가 많습니다. Discovery에서 “이번 분기에 KPI를 움직일 레이어 하나”를 고르는 것이 현실적입니다.
3. 레거시가 있을 때의 시작 순서
- As-Is 5줄: 지금 사람이 하는 일을 예외 포함해 문장으로 (기능 목록 X).
- 데이터 주인 표: “이 숫자 맞나?”라고 물었을 때 답하는 사람·시스템.
- Quick Win 하나: 되돌리기 쉽고, 매일 반복되는 구간 (알림, 승인, 업로드 등).
- 연동 지도: 다음 분기에 ERP·결제·메일을 어디에 붙일지.
전면 재개발은 3·4가 정리된 뒤에도 유효합니다. 그 전에 “새 ERP”만 사면 DX가 아니라 비용 전환에 그칠 수 있습니다.
4. DX와 AX·AI의 접점
DX가 데이터와 흐름을 정리하면, 그다음 AI·Agent는 붙일 자리가 보입니다. 반대로 AI PoC만 하고 흐름이 엑셀이면, 자동화는 데모에서 멈춥니다. DX → AX 순서를 같이 설계하는 경우 프로젝트 상담에서 범위를 나눠 제안하는 편이 낫습니다.
5. 정리
DX 전환은 보이는 디지털 채널 + 안 보이는 업무 OS를 맞추는 일입니다. Technical Discovery로 As-Is와 Quick Win을 먼저 고정하고, Build·Operate는 Delivery 서비스 흐름으로 이어가면 “전환”이라는 말이 KPI까지 연결됩니다.