내 업무로 자동화 대시보드 설계 한 사이클 돌리기

1내가 가장 잘 아는 업무 영역(도메인) 하나를 고른다

기준

남의 업무를 흉내 내지 않습니다. 강사도 자기가 실제로 하는 B2B 세일즈를 골랐습니다 [15:56]. 반복되는 일이 있고, 가끔 뭔가를 놓치는 일이 있는 영역이면 좋습니다.

2AI 코딩 도구에서 새 프로젝트를 만든다

왜

화면을 그리기 전에 프로젝트 이름과 도메인만 정해 둡니다. 강사는 코덱스(Codex)에서 "트루노스크루 영업 자동화 대시보드"라는 이름으로 시작했습니다 [15:56]–[17:05].

1문제 정의 — 사용자·병목·자동화 대상·KPI

[프로젝트명]을 구축하려고 한다. 첫 단계로 문제 정의가 필요하다.
문제 정의 순서는 사용자 정의, 병목 파악, 대상 선정,
수동/자동 경계, 핵심 KPI다.
이 시스템의 사용자는 나다. 나를 인터뷰하여
문제 정의가 완료되도록 해 줘.

핵심 질문

AI가 "최근에 실제로 놓쳤던 일 하나를 떠올려 달라"고 물으면 구체적인 사례로 답합니다. 이 병목의 크기(월 몇 건, 최근 몇 개월 몇 건 놓쳤는지)를 숫자로 답할수록 자동화 대상이 명확해집니다 [21:05]–[26:39].

산출물

"○○는 이런 상황인데, 이걸 자동으로 해결해야 한다"는 한 문장짜리 문제 정의. 이후 모든 단계의 기준점이 됩니다.

2업무·데이터 분석 — 흐름, 데이터, 상태

나는 비개발자다. 데이터 관련 용어가 어렵게 나올 수 있으니
쉽게 설명하며 진행해 달라.
[1단계 결과]를 바탕으로 업무 흐름 정의, 데이터 정의,
상태 정의 순서로 인터뷰를 진행해 줘.

놓치기 쉬운 것

"최신 정보가 있는 기준 장소가 어디인지"를 반드시 정합니다. 여러 곳(엑셀, 웹사이트, 메신저)에 정보가 흩어져 있다면, 그중 하나를 기준으로 못박아야 합니다 [40:22].

상태 정의 요령

상태가 열 개 가까이 나온다면, "전체 어디까지 왔는지(큰 단계)"와 "지금 뭘 기다리는지(세부 상태)"로 나눠서 관리합니다 [49:03].

3UX와 IA — 정보 구조, 화면별 목표, 상태별 화면

다음 단계는 UX와 IA(정보구조) 설계다.
정보 구조 설계, 화면별 핵심 목표 설정,
상태별 화면 설계 세 단계로 인터뷰를 진행해 줘.

먼저 답할 질문

"주로 PC와 모바일 중 어디서 쓸 것인가?", "로그인 직후 가장 먼저 보고 싶은 것은?", "같은 대시보드를 쓰는 다른 사람(대표, 동료)에게도 전체를 보여줄 것인가, 담당분만 보여줄 것인가?" [51:52]–[53:33]

화면마다

"이 화면에서 사용자가 무엇을 달성해야 하는가"를 한 문장으로 정합니다. 목표가 흐릿한 화면은 UI를 아무리 예쁘게 꾸며도 쓸모가 없습니다.

4시스템 구조와 기능 명세 — 개발 지식이 필요한 단계

다음은 시스템 구조 설계와 기능 명세다.
단계는 구조 설계, API 명세, 배치 명세, 인터페이스 명세,
안정성 대비(권한 관리, API 변경, 인증 만료, 데이터 오류,
중복 실행, 레이트 리밋, 실행 실패)다. 인터뷰를 진행해 줘.

주의

여기부터는 비개발자에게 낯선 개념(API, 배치, 소프트 딜리트, 웹훅, 레이트 리밋)이 쏟아집니다. 모르는 말이 나오면 정리.html 6장과 부록 A 낱말표를 먼저 찾아봅니다. 모르는 채로 넘어가면, 나중에 그 기능이 있는지도 모른 채 못 쓰게 됩니다 [10:58]–[11:30].

확장성 체크

AI가 처음 제안하는 구조가 "화면과 서버를 하나로 묶는" 단순한 형태라면, 기능이 커질 걸 대비해 "확장성이 보장되는 구성으로 다시 제안해 달라"고 반드시 되물어야 합니다 [74:10].

5UI 디자인 — 프레임 목업, 논리적 의사결정, 테마

지금까지 나온 명세를 바탕으로 프레임 목업을 만들어 줘.
이후 화면마다 필요한 UI 요소는 데이터 형태와
사용 맥락에 따라 논리적으로 골라 줘 — 어울리는 걸
고르는 게 아니라 정답이 있는 결정이라고 생각하고 진행해 줘.

테마 정하기 전에

"이 대시보드에서 사용자가 느껴야 할 인상은?", "기존 로고·색상을 따를 것인가?", "주 사용 환경은?" 같은 질문에 먼저 답합니다. 스타일(글래스모피즘, 머티리얼 등) 이름부터 고르지 않습니다 [111:41]–[120:35].

6MVP 구축 → 검수 → 배포

전체 기능을 한 번에 만들지 말고, 핵심 흐름 하나만
MVP로 먼저 구축해 줘. 완성되면 내가 직접 검수하겠다.

검수 횟수

한 번 보고 끝내지 않습니다. 강사 기준 최소 15~20번은 써 보고 고쳐야 MVP라 부를 만하다고 말합니다 [126:24 무렵].

배포 순서

먼저 스테이징(테스트 서버)에 올려 검수하고, 문제가 없을 때만 운영(프로덕션) 서버로 병합합니다. 이 순서를 건너뛰고 바로 운영에 올리지 않습니다.