한줄 요약
[내부 시스템이라 마스킹 모드로 기록하였습니다]
비개발자 PM/운영 담당자가 Codex와 oh-my-codex(OMX)를 활용해 내부 ERP+CRM과 구독 관제 대시보드를 만들어간 기록입니다. 단순히 “기능을 많이 붙이고 화면을 예쁘게 만든다”가 아니라, 먼저 페인포인트를 정리하고, 유저 저니맵으로 사용 흐름을 잡고, 각 메뉴 개발 전에는 딥인터뷰로 데이터·기능·화면 기준을 구체화한 뒤 구현했습니다.
이번 글의 핵심은 두 가지입니다.
1. ERP+CRM: 흩어진 운영 업무를 하나의 운영 OS로 묶는 과정
2. 구독 대시보드: ERP 관점에서 구독 운영 데이터를 “대표/운영자가 바로 판단할 수 있는 관제 화면”으로 바꾸는 과정
이런 분들께 도움돼요
- 비개발자지만 내부 업무툴, CRM, 운영 대시보드를 직접 만들고 싶은 분
- AI 코딩 도구를 단순 코드 생성기가 아니라 PM/기획/개발 파트너처럼 쓰고 싶은 분
- “무엇을 만들지”가 아직 흐릿한 상태에서 AI와 요구사항을 구체화하는 방법이 궁금한 분
- 업무 데이터는 많은데, 실제 의사결정에 필요한 인사이트로 연결되지 않는 문제를 겪는 분
시작점: 데이터와 업무는 많은데, 사용 흐름이 끊겨 있었다
운영 업무에는 이미 많은 데이터가 있었습니다.
고객, 계약, 구독 상태, 메일, 문서, 일정, 문의, 승인, 차량, 보험, 위치, 납부 흐름 같은 것들이요. 문제는 데이터가 없다는 게 아니라, 각각의 데이터가 따로 움직이고 있었다는 점이었습니다.
예를 들면 이런 식입니다.
- 고객 상태를 보려면 고객 화면을 열어야 합니다.
- 문의 이력을 보려면 CS 화면을 따로 봐야 합니다.
- 계약과 구독 상태는 또 다른 메뉴에서 확인해야 합니다.
- 문서와 메일은 서로 다른 흐름으로 관리됩니다.
- 승인이나 내부 업무는 별도의 작업처럼 흩어져 있습니다.
- 구독 현황은 숫자는 있지만, “그래서 오늘 어디를 봐야 하지?”라는 판단까지 이어지지 않습니다.
운영자는 결국 여러 화면을 오가며 머릿속으로 맥락을 이어 붙여야 했습니다.
그래서 처음 목표는 “CRM 하나 만들자”, “대시보드 하나 만들자”가 아니었습니다. 목표는 더 넓었습니다.
운영자가 매일 들어와서 오늘 볼 일, 고객 맥락, 구독 상태, 내부 승인과 문서 흐름을 한 번에 파악할 수 있는 운영 OS를 만들자.
사용한 도구와 방식
사용한 도구는 주로 다음과 같습니다.
- Codex CLI: 실제 기능 구현, 리팩터링, 테스트, 화면 개발
- oh-my-codex(OMX): 딥인터뷰, 계획 수립, 역할별 에이전트 작업, QA 흐름 관리
- Next.js / React / Tailwind 기반 웹앱: 내부 운영 화면 구현
- Supabase / API / 로컬 스냅샷 구조: 업무 데이터와 대시보드 데이터 관리
- 테스트/빌드 검증: 기능이 실제로 깨지지 않는지 확인
제가 특히 유용하게 쓴 방식은 OMX의 흐름이었습니다.
메뉴 하나를 만들기 전에 바로 “구현해줘”라고 하지 않았습니다. 먼저 딥인터뷰 모드로 다음을 정리했습니다.
- 이 메뉴를 누가 쓰는지
- 사용자가 처음 들어와서 어떤 순서로 판단하는지
- 첫 화면에서 10초 안에 봐야 할 정보는 무엇인지
- 어떤 데이터가 필요하고, 어떤 데이터는 노출하면 안 되는지
- 어떤 기능이 V1에 꼭 필요하고, 어떤 기능은 후순위인지
- AI가 해도 되는 일과 사람이 확인해야 하는 일은 무엇인지
- 구현 전에 어떤 plan/test spec/acceptance criteria가 필요한지
이 과정이 중요했습니다. AI에게 바로 코딩을 시키면 빠르게 뭔가 만들어주지만, 방향이 조금만 틀어져도 “예쁜데 쓸모없는 화면”이 나오기 쉽습니다. 반대로 사용 흐름과 데이터 기준을 먼저 잡으면, 구현 속도는 빠르면서도 결과물이 실제 업무에 가까워졌습니다.
1단계: 유저 저니맵으로 사용 흐름을 먼저 잡았다
메뉴를 만들기 전에 사용 흐름부터 잡았습니다.
예를 들어 ERP+CRM 전체 구조는 다음처럼 나눴습니다.
1. Workspace: 내가 오늘 처리해야 할 일
2. ERP: 회사 내부 운영, 문서, 일정, 승인, 직원, 업무
3. CRM: 고객, CS, 구독, 커뮤니케이션, Customer360
이건 단순한 메뉴 분류가 아니라, 사용자의 하루 흐름에 맞춘 구조였습니다.
운영자가 아침에 들어오면 먼저 전사 전체 숫자보다 “내가 오늘 처리할 일”이 중요합니다. 고객을 볼 때는 고객 목록만 보는 것이 아니라, 그 고객의 계약, 구독, 문의, 문서, 커뮤니케이션 이력을 한 흐름에서 봐야 합니다. 내부 업무는 문서, 승인, 일정, 메일이 따로 노는 것이 아니라 하나의 운영 흐름으로 이어져야 합니다.
그래서 각 메뉴를 개발하기 전에 이런 질문을 던졌습니다.
text
이 메뉴의 주 사용자는 누구야?
처음 들어오면 무엇을 먼저 봐야 해?
다음 행동은 무엇이어야 해?
필요한 데이터는 무엇이고, 아직 없는 데이터는 무엇이야?
V1에서 꼭 필요한 기능과 후순위 기능을 나눠줘.
이렇게 하니 Codex가 단순히 화면을 만드는 것이 아니라, PRD와 plan, 테스트 기준까지 함께 만들기 시작했습니다.
2단계: 공통 화면 뼈대를 먼저 만들었다
기능을 빠르게 만들더라도 화면마다 구조가 다르면 나중에 운영툴이 아니라 잡다한 페이지 묶음처럼 보입니다.
그래서 ERP+CRM에는 공통 화면 뼈대를 먼저 만들었습니다.
- 좌측 사이드바
- 상단 검색/액션 영역
- 페이지 프레임
- 카드와 테이블
- 탭과 필터
- 목록 + 상세 패널
- 상태 배지
- 빈 상태 화면
이 단계에서 중요한 건 “디자인을 완성했다”가 아닙니다. 오히려 디자인은 나중에 고도화할 수 있다고 봤습니다. 다만 기능 개발을 먼저 하더라도, 화면 구조의 기준은 있어야 했습니다.
저는 이걸 “기능 먼저, 하지만 아무렇게나는 아님” 정도로 이해했습니다.
기능을 먼저 붙이되, 나중에 디자인을 갈아엎지 않도록 최소한의 제품 구조와 컴포넌트 규칙은 유지하는 방식입니다.
3단계: 메뉴별로 딥인터뷰 → plan → 구현 흐름을 반복했다
ERP+CRM에서 메뉴를 하나씩 개발할 때도 같은 방식을 반복했습니다.
바로 코딩하지 않고, 먼저 OMX 딥인터뷰로 흐름과 기준을 잡았습니다.
예를 들어 어떤 메뉴를 만들기 전에는 다음을 정리했습니다.
- 사용자의 실제 업무 목적
- 화면에 들어와서 보는 순서
[ 오전 9:45]
- 필요한 데이터와 없는 데이터
- V1에서 구현할 기능과 제외할 기능
- AI가 도와줄 수 있는 영역
- 위험한 자동화 범위
- 테스트 기준
- 완료 기준
그 다음 plan을 만들고, 필요한 데이터 구조와 기능 범위를 최대한 구체화한 뒤 구현했습니다.
이 방식의 장점은 “AI가 알아서 만들었다”가 아니라, 제가 PM으로서 업무 기준을 계속 잡고, AI는 그 기준을 바탕으로 빠르게 설계와 구현을 밀어준다는 점이었습니다.
4단계: ERP 개념을 확장해 구독 관제 대시보드를 만들었다
ERP+CRM을 만들다 보니 자연스럽게 연결되는 별도 과제가 있었습니다. 구독 운영 대시보드였습니다.
처음 페인포인트는 명확했습니다.
구독 운영에는 계약, 차량, 보험, 위치, 지역, 모델, 납부 흐름 같은 데이터가 있습니다. 그런데 기존에는 이 데이터들이 “운영자가 바로 판단할 수 있는 인사이트”로 잘 연결되지 않았습니다.
단순히 숫자를 많이 보여주는 대시보드는 만들 수 있습니다. 하지만 그걸 보고 대표나 운영자가 바로 이런 판단을 할 수 있어야 했습니다.
- 지금 정상 구독 규모는 어느 정도인가?
- 어느 지역이 중요해지고 있는가?
- 어떤 모델이 많이 움직이고 있는가?
- 보험이나 위치 데이터에 구멍은 없는가?
- 오늘 더 봐야 할 운영 축은 지역인가, 보험인가, 모델인가, 납부 흐름인가?
- 이 대시보드가 보고서처럼 설명 가능한가?
그래서 구독 대시보드는 단순 “멋진 차트 화면”으로 접근하지 않았습니다. ERP의 한 확장 개념으로 봤습니다.
구독 운영 데이터를 모아 대표/운영자가 30초 안에 현재 상태와 다음 확인 대상을 판단 하는 관제실을 만들자.
5단계: 구독 대시보드도 먼저 유저 저니맵을 만들었다
구독 대시보드도 바로 화면을 만들지 않았습니다.
먼저 사용자의 흐름을 정리했습니다.
1. 토큰/패스프레이즈로 접근한다.
2. 첫 10초 안에 전체 규모, 월 순증, 위치/보험/위험 흐름을 훑는다.
3. 지역/지도 중심으로 볼지, 운영 현황 중심으로 볼지, 성장/모델 중심으로 볼지 선택한다.
4. 위치 없음, 보험 미가입, 위험 신호, 특정 지역 집중 같은 이상치를 확인한다.
5. 상세 메뉴로 들어가기 전 오늘 더 볼 축을 정한다.
이 저니맵을 기준으로 화면 방향도 잡았습니다.
처음에는 KPI 카드만 잔뜩 있는 대시보드가 아니라, 지도와 차트, 테이블형 시각화를 중심으로 가는 방향을 잡았습니다. 특히 구독 운영에서는 “어디에 몰려 있는가”, “어디가 성장 후보인가”, “어디의 위치/보험 데이터가 비어 있는가”가 중요했기 때문에 지도는 장식이 아니라 핵심 판단 도구였습니다.
6단계: “AI 인사이트 카드”가 아니라 “AI 보고서 생성”으로 방향을 바꿨다
구독 대시보드에서 오래 고민한 부분은 AI였습니다.
처음에는 AI가 인사이트를 카드처럼 보여주는 정도를 생각할 수 있습니다. 하지만 그렇게 하면 그냥 “그럴듯한 문장”이 될 위험이 있었습니다.
그래서 방향을 바꿨습니다.
AI는 화면 옆에 붙은 장식이 아니라, 현재 필터와 지도, KPI, 차트 근거를 바탕으로 보고서를 생성하는 작업 표면이어야 한다고 봤습니다.
AI 보고서는 최소한 이런 구조를 가져야 했습니다.
text
결론: 현재 상태 요약
핵심 근거: 숫자와 비율, 지도/필터 기준
보고 기준: 생성 시각, 데이터 스냅샷, 필터 조건
다음 액션: 더 봐야 할 상세 화면 또는 확인 대상
이렇게 하니 “AI가 뭔가 말한다”가 아니라 “운영자가 보고에 쓸 수 있는 근거 있는 요약을 만든다”는 의미가 생겼습니다.
7단계: 구독 대시보드는 데이터 기준과 개인정보 보호가 핵심이었다
구독 대시보드에서 가장 조심한 부분은 데이터였습니다.
차량, 계약, 보험, 위치 데이터는 민감할 수 있습니다. 그래서 클라이언트 화면이나 AI 응답에 고객명, 연락처, 차량번호, 상세주소, 보험증권번호 같은 민감 정보가 노출되면 안 됐습니다.
대신 서버 쪽에서 필요한 데이터를 읽고, 화면에는 집계된 값만 보여주는 방향으로 잡았습니다.
예를 들면:
- 전체 정상 구독 수
- 지역별 분포
- 모델별 분포
- 사용개월 분포
- 보험 가입/미가입/만료/임박 집계
- 위치 최신화 여부
- 성장 후보 지역
- 납부 흐름 위험 신호
즉, 원본 데이터를 그대로 보여주는 대시보드가 아니라, 운영 판단에 필요한 집계와 진단만 보여주는 대시보드입니다.
이 부분도 딥인터뷰와 plan 단계에서 먼저 정리했습니다. “무엇을 보여줄까?”보다 “무엇을 절대 보여주면 안 되는가?”를 같이 정한 것이 중요했습니다.
9단계: 구현 후에도 QA와 검증을 반복했다
구독 대시보드는 화면도 중요했지만, 검증도 중요했습니다.
- 지도 SDK가 실제 배포 도메인에서 뜨는지
- 토큰 게이트가 제대로 동작하는지
- API가 민감 정보를 내보내지 않는지
- AI 보고서가 aggregate 데이터만 사용하는지
- 내부 메뉴들이 같은 디자인 언어를 쓰는지
- 좌측 메뉴가 일관되게 유지되는지
- 테스트와 빌드가 통과하는지
이런 항목을 역할별 에이전트에게 검토시키고, 문제가 있으면 다시 수정하는 식으로 진행했습니다.
특히 좋았던 점은, 작업 단계마다 context 파일이나 plan, state JSON을 남겨두니 세션이 끊겨도 이어가기 쉬웠다는 점입니다. AI 작업은 세션이 길어질수록 맥락 손실이 자주 생기는데, 중간 산출물을 파일로 남기는 습관이 꽤 도움이 됐습니다.
결과: 단순 기능 개발이 아니라 운영 판단 흐름을 만들었다
이번 작업의 결과는 “화면 몇 개 만들었다”보다 조금 더 넓게 볼 수 있습니다.
| 구분 | 기존 문제 | 만든 방향 |
|---|---|---|
| ERP+CRM | 기능과 데이터가 흩어짐 | Workspace / ERP / CRM 운영 OS 구조 |
| 메뉴 개발 | 바로 구현하면 방향이 흔들림 | 딥인터뷰 → plan → 데이터/기능 정의 → 구현 |
| 화면 설계 | 예쁜 관리자 페이지가 되기 쉬움 | 유저 저니맵 기반 업무 흐름 설계 |
| 구독 대시보드 | 숫자는 있지만 판단으로 이어지기 어려움 | 대표/운영자용 구독 관제실 |
| AI 활용 | 그럴듯한 인사이트 문장 위험 | 근거 기반 AI 보고서 생성 |
| 지도/차트 | 장식적 시각화 위험 | 지역/위치/보험/모델 판단 도구 |
| 데이터 | 원본 노출 위험 | aggregate-only, 민감정보 차단 |
가장 큰 배움은 이거였습니다.
AI 코딩 도구는 “만들어줘”라고 하면 빠르게 만들어준다. 하지만 진짜 중요한 건 만들기 전에 사용 흐름과 데이터 기준을 같이 정리하는 것이다.
이 과정에서 배운 AI 활용 팁
1. 바로 구현시키지 말고, 먼저 인터뷰를 시켜라
좋았던 흐름은 이랬습니다.
text
이 메뉴를 만들기 전에 딥인터뷰로 사용자, 유즈케이스, 데이터, 기능 범위, 제외 범위, 완료 기준을 먼저 정리해줘.
그 다음 plan과 test spec을 만들고, 승인 가능한 구현 단위로 쪼개줘.
이렇게 하면 AI가 바로 코드를 쓰기보다, 제품 요구사항을 먼저 정리합니다.
2. “무엇을 보여줄지”만큼 “무엇을 보여주면 안 되는지”를 정해야 한다
특히 운영 데이터나 고객 데이터가 들어가는 화면에서는 중요합니다.
구독 대시보드에서는 고객명, 연락처, 차량번호, 상세주소, 원본 계약 row 같은 정보를 화면/API/AI 응답에 내보내지 않는 기준을 먼저 잡았습니다. 이 기준이 있어야 AI가 대시보드를 만들 때 안전한 방향으로 움직입니다.
3. 예쁜 화면보다 “판단 가능한 화면”을 요구해야 한다
대시보드를 만들 때 AI는 쉽게 화려한 카드, 그라데이션, 큰 숫자, 인사이트 문장을 만들려고 합니다.
하지만 실제 운영 화면에서는 다음 질문이 더 중요했습니다.
- 이 화면을 보고 10초 안에 무엇을 판단할 수 있나?
- 다음으로 눌러야 할 메뉴가 명확한가?
- 지도/차트/테이블이 각각 다른 역할을 하고 있나?
- AI 문장이 실제 숫자 근거를 갖고 있나?
4. 세션이 길어질수록 중간 산출물을 파일로 남겨야 한다
AI 작업은 길어지면 맥락이 흐려집니다. 그래서 PRD, 유저 저니맵, plan, test spec, QA checklist, state JSON 같은 파일을 계속 남겼습니다.
덕분에 세션이 끊겨도 “어디까지 했는지”를 복구할 수 있었고, 다른 에이전트에게 이어 맡기기도 쉬웠습니다.
앞으로의 계획: 기능 추가를 잠깐 멈추고, 단일 데이터 기준을 맞춘다
지금까지는 ERP+CRM과 구독 대시보드의 주요 화면과 기능 흐름을 빠르게 만들었습니다.
하지만 이제 바로 기능을 더 붙이기보다, 잠깐 멈추고 단일 데이터 기준을 맞추려 합니다.
이유는 간단합니다.
기능이 많아질수록 같은 고객, 같은 계약, 같은 구독 상태, 같은 승인 상태를 화면마다 다르게 해석할 위험이 커집니다. 그렇게 되면 화면은 많아졌는데, 운영자는 다시 헷갈리게 됩니다.
다음 단계에서는 이런 부분을 정리하려 합니다.
- 고객, 계약, 구독, 문의, 문서, 업무, 승인 데이터의 기준 엔티티 정리
- ERP+CRM과 구독 대시보드가 같은 고객/계약/구독 기준을 바라보게 정리
- 화면마다 다른 상태값 표현을 하나의 상태 모델로 통일
- mock/derived data를 줄이고 실제 도메인 데이터 기준으로 연결
- Customer360, Workspace, 구독 관제 화면이 서로 끊기지 않게 연결
- AI 보고서도 같은 데이터 기준을 참조하도록 정리
즉, 지금까지가 “쓸 수 있는 기능과 화면을 만드는 단계”였다면, 다음은 “모든 화면이 같은 데이터를 같은 의미로 바라보게 만드는 단계”입니다.
이 단계가 끝나면 내부 운영툴은 단순한 웹앱이 아니라, 실제 운영 판단을 돕는 OS에 더 가까워질 것 같습니다.
재사용 가능한 프롬프트
프롬프트 1: 메뉴 개발 전 딥인터뷰 요청
이 메뉴를 바로 구현하지 말고, 먼저 딥인터뷰 모드로 정리해줘.
사용자는 누구인지, 어떤 페인포인트가 있는지, 처음 들어와서 어떤 순서로 판단하는지, 필요한 데이터는 무엇인지, V1에 포함할 기능과 제외할 기능은 무엇인지 물어보고 정리해줘.
그 다음 PRD, 구현 plan, test spec, acceptance criteria로 나눠줘.
프롬프트 2: 대시보드가 인사이트를 주는지 점검
이 대시보드가 단순히 숫자와 차트를 보여주는 화면인지, 아니면 사용자가 다음 행동을 판단할 수 있는 화면인지 점검해줘.
첫 10초 안에 파악해야 할 정보, 지도/차트/테이블/AI 패널의 역할, 불필요한 장식 요소, 민감정보 노출 위험을 나눠서 리뷰해줘.
프롬프트 3: 기능 개발 후 단일 데이터 기준 정리
지금 여러 화면에 기능이 붙어 있는데, 이제 단일 데이터 기준을 맞추고 싶어.
고객, 계약, 구독, 문의, 문서, 업무, 승인 데이터를 기준 엔티티로 나누고, 화면마다 같은 상태를 다르게 해석하는 곳이나 mock/derived data가 남아 있는 곳을 찾아줘.
기능을 깨지 않고 통합하는 순서를 제안해줘.
