자동화 대시보드 만들기, AI 인터뷰 설계부터 Railway 배포까지

자동화 대시보드 만들기는 화면부터 그리면 데모까지는 금방 가고 그다음에 막힙니다. 이 글은 누가 쓰는지, 어디서 업무가 막히는지, 어떤 데이터와 상태를 다루는지를 AI 인터뷰로 먼저 정한 뒤, 목업과 테마를 거쳐 MVP를 만들고 GitHub와 Railway로 스테이징⁠·운영 배포까지 가는 113단계를 정리했습니다. 예시는 B2B 영업 관리(CRM) 대시보드이고, 같은 순서를 내 업무에 그대로 적용할 수 있습니다.

자동화 대시보드 만들기, 데모 다음이 어려운 이유

바이브코딩으로 많이 만드는 두 가지

바이브코딩(코드를 직접 쓰지 않고 AI에게 말로 시켜 프로그램을 만드는 방식)으로 사람들이 많이 만드는 분야는 크게 두 가지입니다. 사주⁠·운세 앱과 기업용 자동화 대시보드입니다.

사주 앱은 필요한 기능이 적고 경쟁이 치열합니다. 기능으로는 차이를 내기 어려워서 승부가 브랜드, 콘텐츠, 마케팅에서 갈립니다.

대시보드는 데모까지 빠르다

대시보드는 사정이 다릅니다. 로그인, 데이터 불러오기, 표, 차트, 필터, 등록⁠·조회⁠·수정⁠·삭제(CRUD, 데이터를 만들고 읽고 고치고 지우는 기본 기능)처럼 정해진 구조가 많아서 AI가 아주 빨리 만듭니다. 그럴듯한 데모 화면은 한두 시간이면 나옵니다.

문제는 그다음입니다. 데모까지는 금방인데, 실제 업무에 붙이려는 순간부터 어려움이 시작됩니다. 누가 어떤 순서로 쓰는지, 어떤 상태에서 무엇을 보여 줘야 하는지, 데이터는 어디서 오는지가 정해지지 않은 채 화면만 있으면 고칠 때마다 구조가 흔들립니다. 그래서 화면보다 업무 정의를 먼저 합니다.

화면보다 먼저 정할 6단계

자동화 대시보드는 아래 6단계 순서로 AI와 함께 설계하고 만듭니다. 1~4단계는 설계, 5~6단계는 구현입니다.

1. 문제 정의: 사용자 정의, 병목 파악, 자동화 대상 선정, 수동/자동 경계, 핵심 성과 지표(KPI)를 정합니다. 병목(일이 가장 자주 멈추거나 새는 지점)을 얼마나 정확히 찾느냐가 자동화의 투자 대비 효과(ROI)를 좌우합니다.
2. 업무⁠·데이터 분석: 업무 흐름, 데이터 항목, 상태(예: 제안서 나감, 응답 대기, 계약 대기)를 정의합니다. 집으로 치면 기초 공사에 해당하는 단계입니다.
3. UX와 정보구조(IA) 설계: 메뉴 구성, 화면별 핵심 목표, 상태별 화면 모습을 정합니다. 정보구조(IA)는 어떤 정보를 어느 메뉴, 어느 화면에 둘지 정하는 설계입니다.
4. 시스템 구조와 기능 명세: 서버 구조, API(화면과 서버가 데이터를 주고받는 통로), 배치(정해진 시각에 한꺼번에 도는 작업), 인터페이스(외부 서비스 연결), 안정성 대비(권한, 오류 대응 등)를 정합니다.
5. UI 디자인: 프레임 목업(틀만 잡은 화면), UI 의사 결정, 테마 선택을 합니다.
6. MVP 구축⁠·검수⁠·배포: 한 번에 끝까지 만들지 않고 최소 기능 제품(MVP)부터 만들어 검수한 뒤 CI/CD(코드를 올리면 자동으로 테스트하고 배포하는 체계)로 올립니다.

이 과정에서 가장 중요한 것은 남이 만든 화면을 따라 만드는 것이 아니라 내가 가장 잘 아는 업무 하나를 정의하는 일입니다. 아래 예시를 그대로 베끼기보다, 같은 질문에 내 업무로 답하는 편이 결과가 좋습니다.

1~4단계를 AI 인터뷰로 하는 이유

비개발자가 문제 정의서나 기능 명세서를 처음부터 쓰기는 어렵습니다. 그래서 1~4단계는 AI에게 "나를 인터뷰해서 이 단계를 완료해 달라"고 시킵니다. AI가 질문을 던지고 내가 답하면, AI가 답을 모아 문서로 정리합니다. 내가 놓친 항목은 AI가 질문으로 끌어내고, AI가 모르는 업무 사정은 내가 답으로 채웁니다.

인터뷰를 시킬 때는 세 가지를 프롬프트에 넣습니다. 지금 몇 단계인지, 그 단계에서 정할 항목의 순서, 그리고 "인터뷰해 달라"는 요청입니다. 아래 따라 하기의 프롬프트가 모두 이 형식입니다.

예시 사례: 영업 CRM 대시보드에서 정한 것들

아래 숫자는 B2B 영업 관리(CRM, 고객 관계 관리) 대시보드를 예로 들어 AI 인터뷰에 답한 값입니다. 실제 업무 상황을 80% 정도 반영해 만든 시연용 답이라, 내 업무에서는 숫자가 달라집니다. 어떤 종류의 결정을 내려야 하는지 보는 용도로 읽으면 됩니다.

1차 문제 정의에서 나온 결론

• 병목 두 가지: 신규 상담 접수 뒤 첫 연락을 놓치는 것, 견적을 보낸 뒤 재연락을 놓치는 것.
• 규모: 월 약 20건 상담, 최근 3개월 첫 연락 실패 약 3건, 견적 후 재연락 실패 약 5건.
• 1차 자동화 대상은 접수 후 1영업일 이내 첫 연락입니다. 핵심 KPI는 그 완료율 100%이고, 현재는 약 85%입니다.
• 자동으로 맡길 일: 상담 접수 감지, 영업 건 생성, 담당자 지정, 기한 계산.
• 사람이 할 일: 전화, 상담 내용 기록, 다음 단계 판단.
• 기한이 지나면 업무일 오후 3시에 이메일로 알립니다.

2차 업무⁠·데이터 분석에서 정한 것

• 업무 흐름: 텔레그램 알림 확인 → 전화 → 부재 시 문자 → 어려우면 대표에게 위임.
• "1영업일 이내"는 "접수 시각으로부터 정확히 1영업일 후"로 정합니다. 업무 시간 밖 접수는 AI 권장대로 다음 업무 시간부터 연락합니다.
• 기존 엑셀은 버리고 웹사이트 관리자 데이터를 기준으로 삼습니다.
• 상태는 큰 단계와 세부 상태의 두 층으로 관리하고, 계산서 발행까지를 계약 성사로 봅니다. 장기 보류는 3개월 뒤 수동으로 실패 처리합니다.

3차 UX/IA에서 정한 것

• 모바일 사용이 많을 것으로 봅니다.
• 메뉴 초안은 5개입니다. 목업 단계에서는 하단 메뉴에 할 일, 영업판, 계약 청구, 성과, 관리가 나옵니다.
• 매출은 넷으로 나눠 봅니다. 전체 파이프라인 가치(진행 중인 모든 영업 건의 금액 합), 단계별 성공 확률을 곱한 예상 매출, 계산서 발행 기준 확정 매출, 실제 입금입니다. 성공 확률은 보수적으로 잡습니다.
• 화면별 핵심 목표는 8개 화면에 대해 정합니다.

4차 시스템 구조와 명세에서 정한 것

• Emergent 같은 웹빌더로 만든 기존 웹사이트와 데이터베이스를 함께 쓰고, 새 CRM은 화면과 서버를 나눕니다.
• 배포는 Railway입니다. 웹⁠·API·워커(뒤에서 오래 걸리는 일을 처리하는 프로그램)·크론(정해진 시각에 도는 배치)·데이터베이스(PostgreSQL)·작업 대기열(Redis)로 구성합니다.
• Git 브랜치는 개발용(스테이징)과 운영용(메인)으로 나누고, 운영 배포는 사람이 승인한 뒤에만 합니다.
• 외부 AI 에이전트용 API는 바로 반영해도 되는 것과 사람 승인이 필요한 것을 나눕니다.
• 배치 작업: 5분마다 누락 확인, 업무일 오후 3시 알림, 미수금 알림, 장기 보류 자동 전환 등.
• 안정성: 권한은 단순하게, API 호출은 계정별 분당 120회로 시작(레이트 리밋, 너무 많은 호출을 막는 상한), 변경 이력은 지우지 않고 보관, 시스템 장애 알림은 보조 이메일과 웹훅(일이 생기면 다른 서비스로 자동 전송하는 알림 주소).

자동화 대시보드 만들기 준비물

• 코덱스(Codex) 사용 환경: OpenAI의 코딩 에이전트 앱입니다. 새 프로젝트를 만들어 진행합니다.
• GitHub 계정과 Railway 계정: 둘 다 미리 가입하고 브라우저에 로그인해 둡니다.
• 기초 개념: GitHub 저장소 연결, shadcn(바로 가져다 쓰는 UI 부품 모음), 로컬 서버(내 컴퓨터에서만 열리는 개발용 서버), CI/CD 개념을 대략 알고 있으면 편합니다.
• 터미널: 윈도우 파워셸(PowerShell)을 씁니다. 맥이라면 터미널 앱으로 같은 명령을 씁니다.
• 내가 가장 잘 아는 업무 하나: 사용자, 반복 업무, 막히는 곳을 말로 설명할 수 있어야 합니다.
• 시간: 최소 2시간, 권장 약 10시간. 인터뷰에 성실히 답할수록 시간이 늘지만 결과물이 좋아집니다.

비용에서 미리 알아 둘 것

• GitHub Actions(GitHub 안에서 자동 검증⁠·배포를 돌리는 기능)는 공개 저장소에서는 무료입니다. 비공개 저장소는 GitHub Free 계정 기준으로 월 2,000분까지 무료로 제공되고, 그 이상은 결제가 필요합니다. 제공량을 넘기면 자동 검증이 시작조차 못 하고 실패할 수 있습니다.
• Railway 요금은 2026년 10월 공식 문서 기준으로 Free 플랜 월 0달러(월 1달러 사용 크레딧, 서비스당 메모리 최대 0.5GB), Hobby 플랜 월 5달러(5달러어치 사용량 포함), Pro 플랜 월 20달러(20달러어치 사용량 포함)입니다. 웹⁠·API·워커⁠·크론⁠·DB·Redis를 모두 띄우면 Free 크레딧으로는 모자랄 수 있습니다.
• 요금과 무료 제공량은 자주 바뀌니 가입 전에 GitHub와 Railway의 공식 요금표를 확인해야 합니다.

내 환경에 맞춰 답할 부분

1~4차 인터뷰의 큰 흐름은 누구나 같은 순서로 따라오면 됩니다. 반면 4차 안의 기존 웹빌더, 텔레그램 알림 같은 질문은 예시 사례의 개인 환경입니다. 이런 질문에는 내가 실제로 쓰는 도구(예: 구글 폼, 카카오톡 채널, 네이버 스마트스토어 관리자)로 답하면 됩니다. 기존 시스템이 없다면 "기존 시스템 없음, 새로 만든다"고 답해도 됩니다.

따라 하기 113단계

단계 번호는 원래 절차서 그대로입니다. 1~4차의 질문 묶음에 답하는 단계는 AI가 던지는 질문이 상황마다 달라서 하나의 동작으로 묶었습니다. 질문 내용은 예시 사례 기준이고, 내 업무에서는 AI가 다른 질문을 할 수 있습니다.

1. 프로젝트 만들기 (1~5단계)

1단계. 코덱스에서 새 프로젝트를 만듭니다. 프로젝트는 코덱스가 파일을 만들고 고칠 작업 폴더 단위입니다. 확인: 프로젝트 이름과 소스 폴더를 정하는 단계로 넘어갑니다.

2단계. 프로젝트 이름을 입력합니다. 예시 사례의 이름은 "트루노스크루 영업 자동화 대시보드 구축"입니다. 내 업무에 맞게 바꿉니다. 확인: 이름이 입력 칸에 들어갑니다.

3단계. 소스 폴더를 정합니다. 예시에서는 문서 폴더 안 강의용 폴더 아래에 TNC-CRM이라는 이름으로 둡니다. 폴더 이름은 영문과 하이픈으로 짧게 정하면 나중에 GitHub 저장소 이름으로 쓰기 편합니다. 확인: 프로젝트 폴더가 생깁니다.

4단계. 프로젝트 만들기를 선택합니다. 확인: 프로젝트가 만들어지고 프롬프트를 입력하는 단계로 넘어갑니다.

5단계. 모델은 그때 가장 강한 것으로, 추론 강도는 가장 높은 단계(Extra High)로 고릅니다. 설계 인터뷰인 1~4차는 깊게 생각할수록 좋은 질문이 나옵니다. 5차부터는 구현과 수정이 반복되므로 추론 강도를 한 단계 낮춰 속도를 올립니다. 확인: 모델과 추론 강도 표시가 바뀝니다.

2. 1차 문제 정의 (6~14단계)

6단계. 아래 요지의 프롬프트를 입력창에 씁니다. 회사명과 대시보드 이름은 내 것으로 바꿉니다.

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

확인: 입력창에 글이 들어갑니다.

7단계. 프롬프트를 보냅니다. 확인: AI가 질문을 던지기 시작합니다.

8단계. 첫 질문 묶음에 답합니다. 무엇을 누구에게 파는지, 내가 맡은 업무, 반복 업무 순서, 대시보드를 열면 가장 먼저 보고 싶은 것을 묻습니다. 실제 상황에 가깝게 답할수록 뒤 단계가 정확해집니다. 확인: AI가 병목 파악으로 넘어간다고 알립니다.

9단계. 병목 질문에 답합니다. 최근 후속 조치를 놓친 사례 하나를 떠올려, 어느 단계에서 놓쳤는지, 언제 알았는지, 원인, 어디에 기록하는지를 씁니다. 확인: AI가 단순히 깜빡한 것보다 구조적인 문제라고 정리합니다.

10단계. 병목 크기 질문에 답합니다. 월 상담 건수, 자주 놓치는 후속 행동, 현재 기록 항목을 묻습니다. 확인: AI가 병목을 신규 상담 방치와 견적 후 방치 두 가지로 좁힙니다.

11단계. 자동화 대상 선정 질문에 답합니다. 견적까지 가는 건수, 최근 3개월 놓친 건수, 둘 중 무엇을 먼저 막을지를 묻습니다. 확인: AI가 1차 자동화 대상으로 접수 후 1영업일 이내 첫 연락을 제시합니다.

12단계. 수동/자동 경계 질문에 답합니다. 담당자 자동 지정 여부, 알림만 받을지, 완료를 버튼으로 기록할지, 알림 수단을 묻습니다. 확인: 예시 사례의 답은 알림만 받고, 완료는 버튼으로, 알림은 이메일입니다.

13단계. 핵심 KPI 질문에 답합니다. 첫 연락 완료의 정의, 목표 수준, 알림 시점, 결과 기록 필수 여부를 묻습니다. 확인: 최우선 KPI가 "1영업일 이내 첫 연락 완료율 100%"로 정해집니다.

14단계. AI가 정리한 1차 결과를 읽습니다. 사용자 정의부터 KPI, 보조 지표, 한 문장 문제 정의까지 나옵니다. 내 업무와 다른 곳이 있으면 이 자리에서 바로 고쳐 달라고 합니다. 확인: 한 문장 문제 정의가 나옵니다.

3. 2차 업무⁠·데이터 분석 (15~23단계)

15단계. 아래 요지의 프롬프트를 씁니다. 미리 메모장에 써 두었다가 붙여 넣으면 편합니다.

2차 업무 데이터 분석이다. 업무 흐름 정의, 데이터 정의, 상태 정의 순서로 진행하겠다.
나는 비개발자이다. 정의를 위한 인터뷰 시작해 줘.

"나는 비개발자이다"라는 한 줄을 넣으면 AI가 전문 용어 대신 쉬운 말로 질문합니다. 확인: AI가 "신규 상담 접수부터 첫 연락 완료까지"를 범위로 잡는다고 알립니다.

16단계. 업무 흐름 질문에 답합니다. 접수 알림을 어떻게 받는지, 바로 연락하는지, 통화 후 무엇을 하는지, 부재 시 어떻게 하는지, 위임은 어떻게 하는지를 묻습니다. 확인: 예시 사례는 텔레그램 알림 → 전화 → 안 받으면 문자 → 대표에게 위임입니다.

17단계. "1영업일 이내"의 뜻을 정합니다. 예시 사례는 "접수 시각으로부터 정확히 1영업일 후"를 고릅니다. 기한을 숫자로 계산할 수 있게 정의해야 자동 알림이 맞게 돕니다. 확인: AI가 월요일 오후 4시 접수면 화요일 오후 4시까지라는 예를 보여 줍니다.

18단계. 예외 질문에 답합니다. 밤⁠·새벽 접수, 서비스를 잘못 이해한 문의, 위임할 때 전달 수단, 보조 사용자 권한을 묻습니다. 확인: AI가 업무 흐름 정의가 끝났다고 알립니다.

19단계. 데이터 정의 질문에 답합니다. 신청 화면 항목, 알림 내용, 엑셀 열은 말로 설명하기보다 스크린샷을 첨부하는 편이 정확합니다. 개인정보가 보이는 화면이면 이름⁠·전화번호를 가리고 첨부합니다. 확인: 스크린샷이 대화에 첨부됩니다.

20단계. 세부 데이터 질문에 답합니다. 접수 시간 저장 여부, 관심 서비스 종류, 같은 회사로 볼 기준, 첫 연락 기록 항목을 묻습니다. 확인: AI가 데이터 항목을 정리해 보여 줍니다.

21단계. 빠진 항목이 있으면 직접 추가해 알려 줍니다. 예시 사례에서는 추산 가치, PM(담당 프로젝트 관리자), 투입 인력을 더합니다. 확인: 추가한 항목을 두고 AI의 확인 질문이 이어집니다.

22단계. 상태 정의 질문에 답합니다. 큰 단계와 세부 상태, 계약 성사로 볼 시점, 장기 보류 기준을 묻습니다. 확인: AI가 큰 단계와 세부 상태의 두 층 관리를 제안하고, 그 제안을 받아들입니다.

23단계. AI가 확정한 2차 결과를 읽습니다. 확인: AI가 인터뷰가 끝났다고 알립니다.

4. 3차 UX와 정보구조 (24~27단계)

24단계. 아래 요지의 프롬프트를 씁니다.

3차는 UX와 IA 정보 구조 설계다. 정보 구조, 화면별 핵심 목표 설정, 상태별 화면 설계 세 가지에 대해 인터뷰를 진행해 줘.

확인: AI가 정보 구조부터 질문을 시작합니다.

25단계. 정보 구조 질문에 답합니다. PC와 모바일 중 무엇을 주로 쓰는지, 로그인 직후 보고 싶은 순서, 영업 건을 보는 방식, 담당 건을 먼저 볼지 등을 묻습니다. 확인: AI가 메뉴 5개 초안을 내고 정보 구조가 확정됩니다.

26단계. 화면별 핵심 목표를 읽고 답합니다. 예시 사례에서는 이 단계에서 매출 지표를 전체 파이프라인 가치, 예상 매출, 확정 매출, 실제 입금으로 나눠 따로 정의합니다. 확인: 8개 화면의 핵심 목표가 맞는지 묻는 질문에 "네"라고 답합니다.

27단계. 상태별 화면 규칙 질문에 답합니다. 3개월 무활동 시 장기 보류, 첨부 파일, 다시 활성화 같은 규칙을 묻습니다. 확인: 3차 UX/IA 설계가 끝났다는 안내가 나옵니다.

5. 4차 시스템 구조와 기능 명세 (28~36단계)

28단계. 아래 요지의 프롬프트를 씁니다.

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

안정성 대비 항목의 뜻은 이렇습니다. 인증 만료는 로그인이나 외부 서비스 연결이 시간이 지나 끊기는 경우, 중복 실행은 같은 배치가 두 번 돌아 알림이 두 번 가는 경우, 실행 실패는 배치나 API가 오류로 멈추는 경우입니다. 확인: AI가 구조 설계 질문을 시작합니다.

29단계. 구조 설계 질문에 답합니다. 현재 웹사이트 구성, 데이터에 접근할 수 있는지, 대시보드를 별도 사이트로 둘지, 사용자 수 등을 묻습니다. 개인 환경에 관한 질문이라 내 상황대로 답합니다. 확인: AI가 권장 구조를 제시합니다.

30단계. 구조가 서비스 규모를 감당하지 못할 것 같으면 확장 가능한 구성으로 다시 제안해 달라고 씁니다. 예시 사례에서는 서버 기능을 처음부터 나누는 방식을 요청합니다. 요청 예시는 이렇습니다.

지금 구조는 사용자가 늘거나 배치가 많아지면 버티기 어려울 것 같아. 처음부터 웹, API, 워커, 크론을 나누는 확장 가능한 구조로 다시 제안해 줘. 배포는 Railway 기준으로.

확인: AI가 웹⁠·API·워커⁠·크론으로 나눈 Railway 구조를 다시 제안합니다.

31단계. 남은 구조 결정 질문에 답합니다. 리전(서버가 있는 지역), 브랜치 운영, 운영 배포 승인 방식을 묻습니다. 예시 사례에서는 개발 브랜치와 메인 브랜치를 나누고, 운영 배포는 사용자 본인이 승인하기로 합니다. 확인: AI가 구조 설계가 확정됐다고 알립니다.

32단계. API 명세 질문에 답합니다. 기존 데이터 가져오기, 삭제 처리, 누락 복구, 외부 API 범위 등을 묻습니다. 확인: AI가 API 초안을 내고 API 명세가 확정됐다고 알립니다.

33단계. 배치 명세 질문에 답합니다. 알림 시각의 허용 지연, 공휴일 제외, 휴가 처리, 계산서 발행 예정 알림 등을 묻습니다. 확인: AI가 5분 주기 누락 확인, 업무일 오후 3시 알림 같은 배치 목록을 정리합니다.

34단계. 인터페이스 명세 질문에 답합니다. 구글 워크스페이스 권한, 발신 이메일, 구글 로그인 허용 범위 등을 묻습니다. 확인: AI가 대부분 확정됐다고 하고 선택 항목 두 가지만 다시 묻습니다.

35단계. 안정성 대비 질문에 답합니다. 권한 종류, 최대 중단 시간, API 호출 제한, 장애 알림 채널, 변경 이력 보관을 묻습니다. 확인: AI가 최종 명세 전에 두 가지만 확인하겠다고 알립니다.

36단계. AI가 그린 시스템 구조 도식을 읽습니다. 확인: 모바일 웹, CRM API, 배치⁠·동기 워커, 데이터베이스, 구글 드라이브 링크가 도식에 나옵니다.

6. 5차 UI 디자인: 프레임 목업 (37~42단계)

37단계. 아래 요지의 프롬프트를 씁니다. 이 단계부터는 인터뷰가 아니라 실제 구현이 시작됩니다. Tailwind CSS는 클래스 이름으로 디자인을 입히는 CSS 도구이고, shadcn은 그 위에서 쓰는 버튼⁠·카드⁠·표 같은 부품 모음입니다.

5차 프로세스는 UI 디자인이다. 실제 프로젝트 구성을 진행해서 현재까지의 결정 사항들을 모두 문서화하고 시작할 수 있도록 해 줘.
단계는 프레임 목업, UI 의사 결정, 테마 선택으로 진행한다.
이번 프로세스부터는 실제 구현이 시작되므로 단순 인터뷰가 아닌 검수 요청, 피드백 전달 및 수정을 반복하는 방식으로 진행하겠다.
프론트엔드는 Tailwind CSS와 shadcn을 사용하고, 프레임 목업 단계에서는 shadcn 기본 테마를 사용한다.

"결정 사항을 모두 문서화"를 넣는 이유는 1~4차 인터뷰 결과가 대화창에만 있으면 대화가 길어질수록 AI가 앞 내용을 놓치기 때문입니다. 프로젝트 폴더에 문서로 남겨 두면 다음 작업에서도 그 문서를 기준으로 삼습니다. 확인: AI가 문서화와 구현을 시작합니다.

38단계. 구현이 끝날 때까지 기다립니다. 확인: AI가 주요 화면 구현이 끝났다고 알려 줍니다.

39단계. 완료된 페이지의 프레임 목업을 실제 환경에서 볼 수 있게 해 달라고 씁니다. 확인: AI가 로컬 서버를 띄우고 화면을 열어 줍니다. 주소는 보통 http://localhost: 뒤에 숫자가 붙은 형태입니다.

40단계. 열린 화면을 직접 눌러 보며 확인합니다. 오늘 할 일, 검색, 영업판, 계약 청구, 성과, 관리 화면을 봅니다. 목업이라 실제 데이터 저장⁠·조회는 아직 되지 않습니다. 확인: 화면 모양과 이동이 요청한 구성과 맞습니다.

41단계. AI의 1차 검수 질문에 답합니다. 첫 화면 우선순위, 하단 메뉴, 카드 정보량 등을 묻습니다. 예시 사례에서는 카드에 요청 내용 한 줄 미리 보기를 넣어 달라고 합니다. 확인: 카드에 한 줄 요약이 반영됩니다.

42단계. 목업 검수 범위를 전체 화면으로 넓혀 달라고 씁니다. 확인: AI가 나머지 화면까지 목업을 만듭니다. 예시 사례에서는 40장이 넘는 화면이 만들어집니다.

7. 5차 UI 의사 결정과 테마 (43~54단계)

43단계. UI 의사 결정 검수 화면을 엽니다. 확인: 권장 의사 결정 6가지가 문장으로만 있고 시각화가 없습니다. 글로만 된 선택지는 비개발자가 고르기 어렵습니다.

44단계. 여섯 항목을 각각 시각적 예시로 보고 결정할 수 있게 고쳐 달라고 씁니다. 요청 예시는 이렇습니다.

UI 의사 결정 6가지가 글로만 되어 있어서 고르기 어려워. 항목마다 A, B 같은 선택지를 실제 화면 예시로 만들어서 보고 고를 수 있게 해 줘.

확인: 항목별 UI 예시 화면이 생깁니다.

45단계. 예시를 보고 고릅니다. 예시 사례에서는 AI 권장안(A)으로 최대한 통일합니다. 최근 모델은 권장안의 질이 높아 이 단계에서 손댈 곳이 많지 않은 경우가 많습니다. 확인: 남은 단계가 테마 선택뿐입니다.

46단계. 테마 선택 단계로 넘어가자고 하고, 어떤 테마를 어떤 이유로 고를지 돕도록 나를 인터뷰해 달라고 씁니다. 확인: AI가 번호를 매긴 질문을 냅니다.

47단계. 테마 질문에 답합니다. 첫인상, 브랜드 색을 따를지, 사용 환경, 글자 인상, 포인트 색 사용 범위, 배경, 다크 모드, 글꼴을 묻습니다. 예시 사례에서는 전문성, 단정하고 중립적인 방향으로 답하고, 로고⁠·색 참고용 스크린샷 두 장을 첨부합니다. 확인: AI가 테마 후보를 CRM 전체 화면에 적용해 보여 줍니다.

48단계. 적용 결과를 봅니다. 예시 사례에서는 기본 shadcn에 색만 입힌 수준이라 원하던 테마가 아니라고 판단합니다. 확인: 다음 단계인 스타일 조사로 넘어갑니다.

49단계. 웹에서 "UI 테마 종류"를 검색해 스타일 목록 글을 엽니다. 블로그나 디자인 정리 글이면 충분합니다. 확인: 플랫, 머터리얼, 플루언트, 글래스모피즘 같은 이름과 설명이 보입니다.

50단계. 마음에 드는 스타일을 정하고, AI가 그 스타일을 어떻게 이해하는지 먼저 확인합니다. 스타일 이름만 던지면 AI가 내가 생각한 것과 다르게 이해할 수 있습니다. "글래스모피즘을 어떻게 이해하고 있는지 먼저 설명해 줘"처럼 묻습니다. 확인: 나와 AI가 같은 정의를 말하고 있습니다.

51단계. 글래스모피즘을 적용해 보려 하니, 내가 생각하는 수준의 스타일이 나오도록 구현 전략을 먼저 정리해 예시와 함께 보고해 달라고 씁니다(요지). 글래스모피즘은 반투명 유리판처럼 뒤 배경이 흐리게 비쳐 보이는 스타일입니다. 확인: AI가 스타일 표와 적용 강도(최소형, 절제형, 전면형)를 보여 줍니다.

52단계. 적용 강도를 고릅니다. 예시 사례에서는 절제형을 고릅니다. 확인: AI가 화면 적용 예시를 문자 도식으로 보여 줍니다.

53단계. 권장대로 진행해 달라고 씁니다. 예시 사례의 권장안은 절제형 글래스, 코발트 블루 포인트, 불투명 데이터 카드입니다. 확인: 적용 전후 화면을 비교할 수 있습니다.

54단계. 전후를 비교하고, 마음에 들면 절제된 글래스모피즘으로 테마 스타일을 확정하겠다고 씁니다. 글래스 효과는 배경이 비쳐 보여야 해서, 크게 쓰면 숫자와 표를 읽기 어려워집니다. 데이터가 많은 대시보드는 숫자가 들어가는 카드를 불투명하게 두는 편이 낫습니다. 확인: 전체 화면에 테마가 바뀌어 적용됩니다.

테마를 정한 뒤에는 UI 부품 이름(버튼 그룹 내비게이션, 배지, 카드 등)을 알아 두면 유지보수 때 도움이 됩니다. "오늘 할 일 화면 위쪽 배지 색을 바꿔 줘"처럼 부품 이름으로 말하면 AI가 엉뚱한 곳을 고치는 일이 줄어듭니다.

8. 6차 MVP 구축과 검수 (55~65단계)

55단계. 아래 요지의 프롬프트를 씁니다.

이제 6차 프로세스인 구축 및 검수로 넘어갈 거야. MVP 범위, 구축, 검수 및 안정화, 배포(CD), 추가 구축 순서로 진행하고자 한다. 배포는 Railway로 하기로 했으니 그렇게 진행해. 시작해 줘.

확인: AI가 필수 기능 위주로 MVP 범위를 정하고 개발을 시작합니다.

56단계. 개발이 끝날 때까지 기다립니다. 예시 사례에서는 약 38분 걸렸습니다. 확인: AI가 1차 개발(MVP)이 끝났다고 알리고 검수 순서를 안내합니다.

57단계. AI가 안내한 순서대로 검수를 시작합니다. 먼저 상담 정보 직접 등록 화면에서 영업 건을 하나 등록합니다. 검수용 데이터는 실제 고객 정보 대신 "테스트 회사", "010-0000-0000" 같은 가짜 값으로 넣습니다. 확인: 등록됐다는 표시가 뜹니다.

58단계. 등록한 영업 건 보기를 눌러 저장을 확인합니다. 확인: 방금 등록한 건이 보입니다.

59단계. 자동 계산된 첫 연락 기한을 확인합니다. 확인: 날짜와 시간이 접수 1영업일 뒤로 맞게 나옵니다. 금요일 오후에 접수한 건이면 다음 주 월요일 같은 시각이 나와야 합니다.

60단계. 상세 화면에서 다음 행동이 나오는지 봅니다. 확인: 배경 확인용 전화 같은 다음 행동이 보입니다.

61단계. 연락 기록을 남깁니다. 통화함을 고르고, 다음 행동을 선택하고, 저장합니다. 비슷하게 생긴 요소가 있으면 엉뚱한 곳을 누르기 쉽습니다. 헷갈린 지점은 따로 적어 둡니다. 확인: 저장 뒤 안내대로 상태가 바뀌어야 합니다.

62단계. 영업 건 목록으로 돌아가 상태를 봅니다. 확인: 예시 사례에서는 "고객 응답 대기"로 바뀌지 않고 "초기 상담 완료"로 남아서 실패로 판정합니다.

63단계. 실패 내용과 헷갈렸던 UI를 적어 AI에 피드백으로 보냅니다. 피드백은 무엇을 했고, 무엇을 기대했고, 실제로 무엇이 나왔는지 세 줄로 쓰면 AI가 원인을 빨리 찾습니다.

검수 결과 실패. 영업 건 상세에서 연락 기록을 '통화함'으로 저장하고 다음 행동을 골랐는데, 목록의 상태가 '고객 응답 대기'로 바뀌지 않고 '초기 상담 완료'로 남아 있어. 그리고 저장 버튼 옆에 버튼처럼 생긴 요소가 있어서 잘못 눌렀어. 둘 다 고쳐 줘.

확인: AI가 고칩니다. 예시 사례에서는 약 10분 걸렸습니다.

64단계. 같은 순서로 다시 등록하고 기록해 봅니다. 확인: 헷갈리던 요소가 사라지고, 무엇을 고르면 어떤 상태가 되는지 미리 보여 줍니다.

65단계. 영업 건으로 돌아가 상태를 확인합니다. 확인: 상태가 갱신됩니다.

실제 업무에 쓸 MVP라면 이런 검수를 적어도 15~20번은 반복해야 합니다. 등록, 기한 계산, 기록, 상태 변경, 알림처럼 핵심 흐름마다 한 번씩, 그리고 예외 상황(밤 접수, 공휴일, 위임)마다 한 번씩 돌려 보는 식입니다.

9. 배포 준비: GitHub와 Railway 연결 (66~81단계)

여기서부터는 내 컴퓨터에서만 돌던 대시보드를 인터넷에 올립니다. 두 개의 환경을 씁니다. 스테이징은 운영 전에 실제와 같은 조건으로 시험하는 서버이고, 프로덕션(운영)은 실제 사용자가 쓰는 서버입니다.

66단계. 확인했으니 배포 CD 구축 단계로 넘어가겠다고 씁니다. 확인: AI가 GitHub 저장소 연결, 브랜치, Railway CLI 인증 상태를 점검합니다.

67단계. 점검 결과를 읽습니다. 확인: Railway CLI(터미널에서 Railway를 조작하는 명령 도구)가 설치돼 있지 않으면 AI가 그렇게 알리고 멈춥니다.

68단계. 파워셸을 엽니다. 윈도우 시작 메뉴에서 "PowerShell"을 검색해 엽니다. 확인: 명령을 입력할 수 있는 창이 보입니다.

69단계. AI가 알려 준 설치 명령을 복사합니다. Railway 공식 문서 기준으로 윈도우에서는 아래 둘 중 하나를 씁니다. npm 방식은 Node.js 16 이상이 깔려 있어야 합니다.

npm i -g @railway/cli

scoop install railway

확인: 복사한 명령이 클립보드에 있습니다.

70단계. 파워셸 창에 명령을 붙여 넣습니다. 파워셸에서는 마우스 오른쪽 클릭이나 Ctrl+V로 붙여 넣습니다. 확인: 명령 한 줄이 창에 보입니다.

71단계. 엔터를 칩니다. 확인: 필요한 프로그램 설치가 시작됩니다.

72단계. 동의를 묻는 질문에 대문자 Y를 입력합니다. 확인: 설치가 진행됩니다.

73단계. 설치가 인식되지 않으면 파워셸을 껐다가 다시 켭니다. 새로 설치한 명령은 창을 다시 열어야 인식되는 경우가 많습니다. 아래 명령으로 설치를 확인합니다.

railway --version

확인: 버전 번호가 나옵니다.

74단계. GitHub 로그인 명령을 실행합니다. GitHub CLI(터미널용 GitHub 도구)의 로그인 명령입니다. GitHub CLI가 없으면 먼저 winget install --id GitHub.cli로 설치하고 파워셸을 다시 엽니다.

gh auth login

확인: GitHub.com, 프로토콜, 로그인 방식을 고르는 질문이 나옵니다.

75단계. 접속 위치와 방식을 묻는 질문에 GitHub.com과 HTTPS를 고릅니다. 화살표 키로 고르고 엔터를 칩니다. 확인: 웹 브라우저로 로그인할지 묻는 질문이 나옵니다.

76단계. 웹 브라우저로 로그인할지 묻는 질문에 대문자 Y를 입력합니다. 확인: 일회용 코드를 보여 주고, 엔터를 누르면 브라우저가 열린다는 안내가 나옵니다.

77단계. 엔터를 쳐 브라우저를 엽니다. 미리 GitHub에 로그인된 브라우저를 준비해 둡니다. 확인: 브라우저에 코드 입력 화면이 뜹니다.

78단계. 파워셸에 나온 코드를 브라우저에 입력합니다. 코드는 매번 다릅니다. 확인: 로그인이 끝납니다. 파워셸에서 gh auth status를 치면 로그인된 계정이 보입니다.

79단계. 코덱스로 돌아와 "로그인 완료됨"이라고 씁니다. 확인: AI가 GitHub에 코드를 올렸다고 알립니다.

80단계. GitHub 저장소 화면에서 코드가 올라갔는지 봅니다. 확인: 방금 올린 저장소가 보입니다.

81단계. Railway에 로그인된 상태로 들어갑니다. 확인: 프로젝트 배포를 도와주는 화면이 보입니다.

10. 자동 검증 실패 처리와 CLI 인증 (82~87단계)

82단계. CI는 등록됐지만 GitHub 안에서 실패 상태로 끝난다고 AI가 알리면, 실패 화면을 엽니다. CI는 코드를 올릴 때마다 자동으로 테스트하는 과정입니다. GitHub 저장소의 Actions 탭에서 빨간 X 표시가 붙은 실행을 누르면 됩니다. 확인: 에러 메시지가 보입니다.

83단계. 에러 메시지를 복사해 AI에게 전달합니다. "GitHub에서 확인한 에러 메시지야"라고 쓰고 붙여 넣습니다. 확인: AI가 원인을 짚고 결제(빌링) 화면을 열어 줍니다.

84단계. 원인을 읽습니다. 예시 사례의 원인은 비공개 저장소의 GitHub Actions 무료 제공량 초과입니다. 확인: 무료 제공량을 넘어서 그렇다는 설명이 나옵니다.

85단계. 해결 방법을 고릅니다. 예시 사례에서는 "공개 저장소로 전환하여 진행해 줘."라고 씁니다. 공개 저장소에서는 GitHub Actions가 무료라 이 문제는 바로 풀립니다. 다만 공개 저장소는 누구나 코드를 볼 수 있습니다. 전환하기 전에 코드와 기록에 API 키, 비밀번호, 고객 데이터, 업무 문서가 들어 있지 않은지 먼저 확인합니다. 비밀값은 코드가 아니라 Railway의 환경 변수(Variables)에 넣어야 하고, 한 번이라도 공개된 키는 새로 발급받아 바꿉니다. 업무 데이터가 걸려 있다면 공개 전환 대신 결제 설정을 하거나 무료 제공량이 다시 생기는 다음 달까지 기다리는 쪽이 안전합니다. 확인: 앞의 문제가 풀립니다.

86단계. 화면에 뜬 Railway CLI 브라우저 인증에서 승인을 누릅니다. 직접 할 때는 파워셸에서 railway login을 실행하면 같은 인증 화면이 뜹니다. 늦게 누르면 한 번 더 뜰 수 있습니다. 확인: Railway 로그인에 성공했다는 메시지가 나옵니다.

87단계. 배포가 끝날 때까지 기다립니다. 예시 사례에서는 약 30분 걸렸고, 그동안 실패 알림 이메일이 여러 번 왔습니다. AI가 실패를 고치며 다시 시도하는 동안 생기는 알림이라 끝까지 기다립니다. 확인: AI가 공개 저장소와 스테이징 화면을 볼 수 있다고 알립니다.

11. 스테이징 검수 (88~92단계)

88단계. 스테이징 화면을 엽니다. 주소는 AI가 알려 줍니다. Railway가 붙여 주는 주소는 보통 .up.railway.app으로 끝납니다. 확인: 로컬 주소가 아닌 별도 주소의 화면이 열립니다.

89단계. 스테이징에서 영업 건을 등록합니다. 확인: 등록되고, 등록한 건이 보입니다.

90단계. 같은 건에서 "연락 기록"을 누릅니다. 확인: 예시 사례에서는 로컬에서는 되던 것이 스테이징에서는 오류가 납니다. 로컬과 서버는 환경 변수, 데이터베이스, 주소가 달라서 이런 일이 흔합니다.

91단계. 오류 화면 주소와 함께, 연락 기록을 누르면 인터널 서버 에러가 뜬다는 내용을 AI에게 버그 리포트로 보냅니다. 인터널 서버 에러(500 오류)는 서버 쪽 코드가 처리 중 멈췄다는 뜻입니다. 운영에 올리기 전에 이런 문제를 잡으려고 스테이징을 둡니다.

스테이징에서 버그. 이 주소의 영업 건 상세에서 '연락 기록'을 누르면 인터널 서버 에러가 떠. 로컬에서는 정상이었어. 원인을 찾아서 고치고 스테이징에 다시 배포해 줘.

확인: AI가 고치고 스테이징을 다시 배포했다고 알립니다.

92단계. 스테이징을 새로고침하고 다시 연락 기록을 누릅니다. 예시 사례의 원인은 코드에 고정값으로 박힌 주소 조각(슬러그) 문제였습니다. 확인: 오류 없이 처리됩니다.

12. 운영(프로덕션) 배포 (93~97단계)

93단계. 수정 결과가 정상인 걸 확인했으니 운영 서버로 올리는 절차를 안내해 달라고 씁니다. 확인: AI가 운영 배포 절차를 안내합니다.

94단계. GitHub Actions 결제 문제가 풀리지 않으면, 별도 승인 절차로 운영에 배포하는 방식으로 정책을 바꿉니다. 예시 사례에서는 GitHub 계정의 과거 결제 이력 문제로 Actions 기반 자동 배포를 쓸 수 없어서, GitHub Actions로 CI/CD를 완성하지 않고 다른 승인 절차로 대신합니다. 확인: AI가 운영 배포 방식을 바꿔 진행합니다.

95단계. 운영 인프라가 준비되지 않았다는 안내가 나오면 프로덕션 인프라 준비부터 시작해 달라고 씁니다. 확인: AI가 인프라 준비를 진행합니다.

96단계. Railway에서 프로덕션 항목을 확인합니다. Railway 프로젝트 화면 위쪽에서 환경(staging, production)을 바꿔 볼 수 있습니다. 확인: 프로덕션에 "온라인" 표시가 생깁니다.

97단계. 운영 사이트에 접속해 봅니다. 이 시점에는 로그인(인증)이 없어서 주소만 알면 누구나 접속할 수 있는 임시 상태입니다. 인증을 만들기 전에는 실제 고객 데이터를 넣지 않습니다. 구글 로그인 연동은 다음 작업으로 남겨 둡니다. 확인: 임시 데이터가 보입니다.

13. 변경 사항을 스테이징에서 운영으로 올리기 (98~113단계)

이 구간은 앞으로 대시보드를 고칠 때마다 반복할 흐름입니다. 로컬에서 고치고, 개발 브랜치에 올려 스테이징에서 확인하고, 메인 브랜치에 합쳐 운영에 반영합니다. 브랜치는 같은 코드의 갈래이고, 풀 리퀘스트(PR)는 한 갈래의 변경을 다른 갈래에 합쳐 달라는 요청, 머지는 실제로 합치는 동작입니다.

98단계. 로컬, 스테이징, 프로덕션 화면을 각각 엽니다. 확인: 세 화면이 똑같이 생겨서 지금 어느 환경을 보고 있는지 헷갈린다는 점을 확인합니다.

99단계. 아래 요지의 수정 요청을 씁니다. GNB(글로벌 내비게이션)는 모든 화면 위쪽에 공통으로 붙는 메뉴 막대입니다.

GNB(글로벌 내비게이션) 우측에 있는 버튼의 색상을 로컬일 때는 짙은 회색, 스테이징일 때는 노란색, 프로덕션일 때는 원래의 파란색이 되게 해 줘.

확인: 로컬에서 색이 바뀝니다.

100단계. 변경 사항을 커밋하고 푸시해 달라고 씁니다. 커밋은 변경을 기록으로 남기는 것, 푸시는 그 기록을 GitHub에 올리는 것입니다. 확인: 개발 브랜치에 푸시가 올라갑니다.

101단계. GitHub 저장소를 새로고침합니다. 확인: 개발(develop) 브랜치에 방금 전 푸시 기록이 보입니다.

102단계. 개발 브랜치의 변경을 메인으로 합치려고 Compare & pull request 버튼을 누릅니다. 이 버튼은 최근에 푸시된 브랜치가 있을 때 저장소 첫 화면 위쪽에 노란 띠로 나타납니다. 확인: 합칠 수 있는지 점검하는 화면이 열립니다.

103단계. 충돌 여부와 변경 내용을 훑어봅니다. 빨간색은 삭제, 초록색은 추가입니다. 확인: 합쳐도 이상 없다는 표시(Able to merge)가 있습니다.

104단계. Create pull request 버튼을 누릅니다. 확인: 풀 리퀘스트가 만들어집니다.

105단계. 충돌이 없는지 보고 Merge pull request 버튼을 누릅니다. 확인: 확인(Confirm) 단계가 나옵니다.

106단계. Confirm을 누릅니다. 확인: 코드 탭에서 메인 브랜치에 개발 변경이 들어가고, 스테이징과 운영의 코드가 같아집니다.

107단계. 메인 브랜치가 Railway 운영에 연결돼 있지 않았다는 안내가 나오면, Railway 웹/API 소스를 GitHub 메인에 직접 연결해 병합할 때 자동 배포되게 해 달라고 씁니다.

Railway 프로덕션 환경의 웹 서비스와 API 서비스 소스를 GitHub 저장소의 main 브랜치에 직접 연결해 줘. main에 병합되면 운영이 자동으로 다시 배포되게 하고, staging 환경은 develop 브랜치에 연결된 상태로 둬.

확인: 메인 브랜치를 병합하면 운영이 자동으로 다시 배포되는 환경이 정리됐다고 AI가 알립니다.

108단계. 마지막 수정 요청을 씁니다. 아래는 요지입니다.

오늘 할 일이라는 페이지 타이틀 우측에 작은 라벨로, 로컬일 땐 "로컬", 스테이징일 땐 "스테이징", 운영일 땐 "프로덕션"을 넣어 주고, 배경색은 로컬 짙은 회색, 스테이징 노란색, 운영 파란색으로 넣어 줘.

확인: 로컬 화면에 "로컬" 배지가 보입니다.

109단계. 스테이징에 배포하고 개발 브랜치에 푸시해 달라고 요청합니다. 확인: 스테이징 화면에 "스테이징" 배지가 생깁니다.

110단계. 운영 화면을 새로고침해 봅니다. 확인: 아직 배지가 없습니다. 개발 브랜치를 메인에 합치지 않았기 때문입니다. 운영은 사람이 승인해 합쳐야만 바뀐다는 뜻이고, 이것이 31단계에서 정한 규칙입니다.

111단계. 풀 리퀘스트를 만들고 병합을 허락합니다. 102~106단계와 같은 흐름입니다. 확인: Railway 운영 대시보드가 약 15초 전부터 브랜치 병합을 인식해 빌드를 시작합니다.

112단계. 빌드가 끝날 때까지 기다립니다. 빌드는 패키지와 소스를 실행할 수 있는 하나의 묶음으로 만드는 과정이라 몇 분씩 걸립니다. 웹만 바뀌었으면 웹만 빌드하고, API는 바뀐 게 없어서 빌드하지 않습니다. 확인: 웹 서비스에서만 빌드가 돌고 있습니다.

113단계. 운영 화면을 새로고침합니다. 확인: "프로덕션" 배지가 붙어 있습니다.

자동화 대시보드 배포에서 자주 막히는 곳

• 완료 버튼처럼 보이는 곳을 눌러도 아무 일이 없다: 화면에 버튼처럼 생긴 장식 요소가 있는 경우입니다. 어떤 요소가 헷갈렸는지 AI에 피드백으로 보내 UI를 고치게 합니다.
• 연락 기록을 저장해도 상태가 안 바뀐다: 상태 전환 규칙이 코드에 제대로 들어가지 않은 경우입니다. 무엇을 했고 무엇을 기대했는지 피드백으로 보내 고친 뒤 다시 검수합니다.
• Railway CLI가 설치돼 있지 않다고 나온다: npm i -g @railway/cli 또는 scoop install railway를 파워셸에서 실행하고, 인식이 안 되면 파워셸을 껐다 켭니다.
• GitHub 자동 검증이 작업을 시작하기 전에 실패한다: 비공개 저장소의 GitHub Actions 무료 제공량(GitHub Free 기준 월 2,000분)을 넘긴 경우가 많습니다. 공개 저장소로 바꾸면 무료지만, 비밀값과 업무 데이터가 없는지 먼저 확인합니다.
• GitHub Actions가 계속 막힌다: 계정의 결제 설정이나 과거 결제 이력 문제일 수 있습니다. GitHub 설정의 결제(Billing) 화면을 확인하거나, Railway가 GitHub 브랜치를 직접 감시해 배포하는 방식으로 대신합니다.
• 스테이징에서만 "연락 기록" 오류가 난다: 코드에 로컬 기준 주소나 고정값(슬러그)이 박혀 있는 경우가 흔합니다. 오류 화면 주소와 동작을 버그 리포트로 보내 고친 뒤 스테이징을 다시 배포합니다.
• 메인에 병합해도 운영 사이트가 반응하지 않는다: 메인 브랜치가 Railway 운영 환경에 연결돼 있지 않은 경우입니다. 107단계처럼 Railway 서비스 소스를 GitHub 메인에 직접 연결해 달라고 요청합니다.
• 배포가 오래 걸린다: 패키지와 소스를 하나로 묶는 빌드 과정이 돌고 있는 것입니다. Railway 화면의 빌드 로그가 끝날 때까지 기다립니다.

끝까지 왔는지 점검하기

한 번에 끝까지 만들려 하지 말고, MVP로 한 바퀴 돌려 검수⁠·안정화⁠·배포까지 가 보는 것이 이 과정의 목표입니다. 끝까지 따라왔다면 아래를 점검합니다.

• 1~4차 인터뷰 결과(문제 정의, 데이터⁠·상태 정의, 정보구조와 화면별 목표, 구조⁠·API·배치⁠·인터페이스⁠·안정성 명세)가 프로젝트 문서로 남았다.
• 프레임 목업이 로컬에서 열리고, 테마가 전체 화면에 적용됐다.
• MVP에서 영업 건 등록, 첫 연락 기한 표시, 연락 기록 저장 후 상태 변경이 된다.
• 스테이징에서도 같은 동작이 되고, 오류가 나면 버그 리포트로 고쳤다.
• 운영 화면이 "온라인"으로 뜨고, 메인 브랜치 병합 시 자동으로 다시 배포된다.
• 로그인(인증)이 없는 운영 사이트에 실제 고객 데이터를 넣지 않았다.
• 환경 배지(로컬/스테이징/프로덕션)로 지금 보는 화면을 구분할 수 있다.

다음 작업은 인증입니다. 구글 로그인처럼 허용된 사람만 들어오게 만든 뒤에야 실제 업무 데이터를 넣을 수 있습니다. 인증을 붙일 때도 같은 순서로 로컬에서 만들고, 스테이징에서 검수하고, 메인에 합쳐 운영에 올립니다.