영상 정리 · AI·개발
화면부터 만들지 않고, AI에게 자신을 인터뷰하게 해서 문제 정의부터 배포까지 6단계를 밟아 영업 자동화 대시보드(CRM) 하나를 처음부터 끝까지 설계하고 만드는 실전 강의
영상의 한국어 원어 자막 전체가 근거입니다. 30초 묶음 278개, 약 17만 자, 끝 시각 154분 42초(영상 길이 154분 59초의 거의 끝까지). 이 영상은 원어가 한국어라 원어 자막(ko-orig)을 그대로 썼습니다.
이 영상은 논문이나 글을 소개하는 영상이 아니라 강사가 실시간으로 진행하는 시연입니다. 그래서 대조할 원문이 따로 없습니다. 다만 강사는 시연에 쓴 회사·업무 내용이 "실제 업무를 80% 정도 참조해서 각색한 것"이라고 스스로 밝혔습니다 — 즉 시연 속 숫자와 사례는 실제 통계가 아니라 강의용 예시입니다. [18:46]
해설자 본인의 실명은 자막으로 확정할 수 없습니다. 채널명(양실장의 바이브코딩대학)만 확인됩니다 — 부록 B 참고.
이 영상은 낱말 여섯 개를 안다고 전제하고 말합니다. 하나씩 풀고 갑니다. 이 강의보다 더 세부적인 용어(배치, 소프트 딜리트, 스테이징 같은 것)는 강사가 직접 그 자리에서 설명해 주므로, 해당 장에서 그때그때 풀어 놓았습니다.
강사는 바이브 코딩으로 사람들이 가장 많이 만드는 것 두 가지를 먼저 비교합니다. 하나는 사주앱, 하나는 자동화 대시보드입니다. [00:00]
사주앱은 예전에는 방대한 데이터를 준비해야 했지만, 지금은 LLM이 사주 해석을 언어로 풀어 주기 때문에 "뚝딱 딸깍"으로 만들어집니다. 눈에 보이는 결과물(오행 그래프, 성격, 재물운 같은 화면)이 빠르게 나와서 서비스의 구색이 금방 갖춰져 보입니다. 다만 진입 장벽이 낮은 만큼 경쟁이 치열해서, 이 분야의 핵심은 결국 브랜드·콘텐츠·마케팅이 된다고 강사는 말합니다. [00:32]
이걸 기업(엔터프라이즈)으로 옮기면 자동화 대시보드입니다. 대시보드는 로그인 → 데이터 불러오기 → 표 보기 → 그래프 보기 → 필터로 조회 → CRUD로 이어지는, 이미 정형화된 구조를 갖고 있습니다. LLM은 사람이 이미 많이 써 놓은 글(발화된 언어)을 학습한 것이라, 이렇게 정형화된 논리를 다루는 데 특히 강합니다. 그래서 대시보드도 "빨리" 나옵니다.
"만들고 나면 '와, 사스(SaaS)를 하나 지워도 되겠는데? 내가 방금 하나 만든 거 같은데' 이런 느낌을 되게 잘 줍니다."
강사 [01:37]
문제는 그다음부터입니다. 강사는 이렇게 정리합니다.
"이런 자동 대시보드의 핵심은 도메인에 대한 이해도가 되겠고요. 고질적인 문제가 뭐냐면, 대모까지는 그래서 금방 나오는데 그 이후부터 정말 각종 어려움들이 시작이 되게 됩니다."
강사 [02:43]
즉 화면을 빨리 뽑아내는 것과, 그 화면이 실제 업무에서 계속 쓰이는 것은 다른 문제라는 것입니다. 강사는 대시보드 구축 전문 회사를 7년간 운영하며 금융·제조·유통 등 여러 대기업의 대시보드를 만들고, 수많은 프로젝트의 PM(프로젝트 관리자)을 맡았던 경력을 소개합니다. [02:43]–[03:16] 오늘 강의는 그 경험을 바탕으로, "대모까지는 나왔는데 그다음부터 시작되는 어려움"을 처리하는 방법을 알려주는 자리라고 소개하며 시작합니다.
본격적으로 들어가기 전에, 강사는 오늘 다룰 6단계 시연을 먼저 통째로 읊어 줍니다. 이 순서를 하나하나 외우는 것이 아니라, 이 구조를 알고 나서 AI와 함께 직접 진행하는 것이 목표라고 강조합니다. [04:25]
강사는 4차 시연(시스템 구조 설계)까지는 강한 추론 성능의 모델을, 5차부터는 상대적으로 가벼운 설정을 쓴다고 미리 밝힙니다 — 앞 단계일수록 논리적으로 촘촘해야 하고, 뒤로 갈수록 이미 나온 설계를 화면과 코드로 옮기는 작업이 많아지기 때문입니다. [18:13]
강사는 시청자들에게 자신의 도메인(자신이 가장 잘 아는 업무 영역)을 정해서 이 6단계를 직접 실습해 볼 것을 권합니다. 핵심만 건드리면 최소 2시간, 권장은 10시간이고, 맛을 들이면 몇 시간이 최대라는 기준 자체가 없어진다고 말합니다. [14:50]
강사는 코덱스(Codex)에서 새 프로젝트를 만듭니다. 도메인은 자신이 실제로 하고 있는 업무 중 하나인 B2B 세일즈, 프로젝트 이름은 "트루노스크루 영업 자동화 대시보드"(줄여서 TNC-CRM)로 정합니다. [15:56]–[17:05]
중요한 것은 여기서부터입니다. 강사는 화면을 그리는 대신, AI에게 자신을 인터뷰해 달라고 요청합니다.
"트루노스크루 영업 자동화 대시보드를 구축하려고 한다. 첫 단계로 문제 정의가 필요하다. 문제 정의 순서는 사용자 정의, 병목 파악, 대상 선정, 수동 자동 경계, 핵심 KPI다. 이 시스템의 사용자는 나다. 나를 인터뷰하여 문제 정의가 완료되도록 해 줘."
강사가 AI에 보낸 프롬프트 [17:41]
AI는 이 문장 하나로 시작해서, 질문을 하나씩 던지며 답을 받아 다음 질문으로 넘어가는 방식으로 인터뷰를 진행합니다. 강사가 실제로 주고받은 답변 중 핵심만 추려 보면 이렇습니다.
사용자 정의. 판매 대상은 "AX 업무 안내, 조직화 집합 교육 및 변화 관리 서비스"이고, 본인이 신규 고객 발굴(유튜브)과 초기 상담까지 담당하며, 계약·후속 관리는 본인 또는 다른 사람이 맡습니다. 대시보드를 열었을 때 가장 먼저 보고 싶은 질문은 "오늘 누구에게 무슨 연락을 해야 하지?"였습니다 — 강사는 그 이유로 "제안을 해 놓고 응답을 기다려야 한다는 사실을 까먹거나, 견적을 보내야 하는데 2~3주 미루는 일이 실제로 있다"고 답합니다. [20:30]–[21:38]
병목 파악. AI는 "최근에 실제로 연락이나 후속 조치를 놓쳤던 영업건 하나를 떠올려 달라"고 묻습니다. 강사가 떠올린 사례는 이렇습니다 — 대기업 고객이었고, 신규 접수 단계에서 영업일 기준 1일 이내에 전화했어야 했는데, 2주 뒤 대표가 정리시키다가 놓친 걸 알게 됐습니다. 이유를 캐 보니 단순한 "깜빡함"이 아니라 구조적 문제였습니다.
"상담 접수 사실은 기록되지만, 언제까지 누가 무엇을 해야 하는지가 관리되지 않는다."
AI가 정리한 병목 [23:48]
AI는 이어서 숫자를 물어 병목의 크기를 잽니다 — 신규 상담은 월 20건(하루 1건 기준), 최근 3개월 기준 첫 연락 실패 3건, 견적 발송 후 재연락 실패 5건. 둘 중 어느 쪽을 먼저 막을지 묻자 강사는 첫 연락을 골랐습니다 — "며칠, 2주 이렇게 놓치면 고객의 상황과 맥락이 그 사이에 바뀌는 경우가 많다"는 이유였습니다. [26:02]–[26:39]
자동화 대상 선정과 수동/자동 경계. 이렇게 좁혀진 1차 자동화 대상은 "신규 상담 접수 후 1영업일 이내 첫 연락이 이루어지도록 관리하는 것"이었습니다. 자동으로 할 일과 사람이 할 일을 나누는 기준도 명확했습니다.
알림은 접수 즉시 담당자를 본인으로 자동 지정하되, 처리하지 않아도 다른 사람에게 자동으로 넘기지 말고 알림만 보내기로 했습니다. 완료 처리는 시스템이 통화 여부를 자동 감지하는 대신, 본인이 직접 버튼을 눌러 기록하는 방식을 골랐습니다. 알림 채널은 이메일입니다. [27:45]–[28:17]
핵심 KPI. "첫 연락 완료"는 실제 통화가 아니라, 통화하지 못했더라도 문자를 남기면 완료로 인정하기로 했습니다. 현재 첫 연락률은 약 85%인데, 목표는 100%로 잡았습니다. 이메일 알림은 마감(1영업일)이 지난 시점에 보내되, 새벽에 상담이 들어올 수 있으니 그날 오후 3시로 정했습니다. [28:50]–[29:23]
이 모든 답을 모아 AI가 최종적으로 정리한 한 문장짜리 문제 정의는 이렇습니다.
"트루노스크루는 월 약 20건의 기업 신규 상담을 받고 있지만, 현재 관리 방식에는 담당자별 다음 행동과 기한을 추적하고 경고하는 기능이 없어 약 15%가 1영업일 이내 첫 연락 기준을 지키지 못한다. 따라서 신규 상담을 자동으로 담당자와 기한에 연결하고, 기한 초과 건을 업무일 오후 3시에 이메일로 알려 직접 연락 또는 위임을 유도함으로써 첫 연락 완료율을 100%로 높여야 한다."
AI가 정리한 1차 시연 결과 [30:31]
이 한 문장이 이후 모든 단계(2차~6차)의 기준점이 됩니다. 문제 정의를 대충 하고 넘어가면, 뒤에서 아무리 화면을 잘 만들어도 결국 안 쓰는 대시보드가 된다는 것이 강사가 이 장에서 계속 강조하는 지점입니다.
1차 시연에서 나온 문제 정의를 들고, 강사는 다음 프롬프트로 2차 시연을 시작합니다. "나는 비개발자다. 데이터 관련 용어가 어렵게 나올 수 있으니, 그걸 감안해서 인터뷰를 진행해 달라"는 조건을 붙입니다. [31:42]
실제 업무 흐름을 세밀하게 캐묻는 질문들이 이어집니다. 상담이 접수되면 텔레그램으로 알림을 받고, 서비스를 잘못 이해하고 들어온 상담은 제외하되(사유는 간단히 기록), 그 외에는 우선순위 없이 대체로 바로 연락합니다. 다만 강사는 흥미로운 예외를 하나 밝힙니다.
"어쩌다가 제가 폰 보고 있었는데 바로 상담 요청이 들어오는 경우가 있어요. 이 경우 바로 전화하면 너무 급해 보일까 봐, 적어도 5분에서 10분 정도 기다렸다가 연락합니다."
강사 [33:24]
1영업일의 기준도 이 자리에서 못박아 둡니다 — "접수 시각으로부터 정확히 1영업일 후"로 정의하고, 월요일 오후 4시 접수는 화요일 오후 4시가 기한, 화요일이 휴일이면 수요일 오후 4시로 넘어갑니다. 업무 시간(오전 9시~오후 6시) 바깥에 접수된 건은 다음 업무일 오전 9시부터 연락 가능하도록 기한을 다시 계산합니다. [35:37]–[38:34]
이 과정에서 처음에는 없었던 보조 사용자(대표님)가 새로 등장합니다. 위임된 건은 대표님이 직접 시스템에 기록하고, 기한을 넘기면 알림을 본인과 대표님 모두에게 보내기로 합니다. [37:20]–[39:10]
다음은 실제로 어떤 정보를 어떤 항목으로 저장할지 정하는 단계입니다. 여기서 나온 결정 중 이후 설계에 계속 영향을 주는 것 세 가지를 짚어 봅니다.
첫째, 최신 정보의 기준 장소를 정합니다. 지금은 웹사이트 관리자·엑셀 두 곳에 정보가 흩어져 있는데, 강사는 "엑셀은 이제 버려야겠고, 최신 정보가 있는 기준 장소는 웹사이트일 수밖에 없다"고 정리합니다. [40:22]–[40:56]
둘째, 같은 회사가 다른 서비스(집합 교육, 온라인 1:1 코칭, 구축)를 여러 번 문의할 수 있다는 걸 확인하고, 동일 회사가 다른 서비스를 문의하면 별개의 영업건으로 관리하되, 같은 회사의 과거 문의는 함께 볼 수 있게 하기로 합니다. 판단 기준은 회사명입니다. [41:40]–[42:17]
셋째, 인터뷰 도중에 계약금·청구까지 관리 범위가 확장됩니다. 처음엔 "계산서 발행까지"로 범위를 잡았는데, 대화가 이어지면서 강사가 "계산서 금액은 전체 계약금이 아니라 선금·중도금·잔금 중 일부일 수 있다"는 걸 스스로 짚어 냅니다.
"계산서 발행의 금액은 해당 건의 추산 가치가 아닌 협의된 계약 금액을 기준으로, 선금·중도금·잔금 비율에 따라 지급 시점마다 다를 것이다. 이게 정확히 매출 산정에 반영되지 않으면 문제가 생긴다."
강사가 AI에게 미리 짚어 준 단서 [60:48]
그 결과 계약 이후 흐름이 계약서 서명 → 청구 일정 등록 → 계산서 발행 → 입금 대기 → 실제 입금까지로 넓어지고, "확정 매출"의 정의도 "실제 계산서 발행액"으로 확정됩니다. 미수금(입금 예정일이 지났는데 안 들어온 것)은 매일 오전 9시 전체 사용자에게 이메일로 알리는 항목으로 추가됩니다. [63:03]–[64:09]
이 대목에서 강사는 처음에는 예상하지 못했던 요구사항이 인터뷰 도중 자연스럽게 드러난다는 것을 직접 보여 줍니다. 미리 다 알고 시작하는 게 아니라, AI와 문답을 주고받으며 빈틈을 그 자리에서 채워 나가는 것이 이 인터뷰 방식의 핵심 효과입니다.
상태는 영업건이 지금 어느 상황에 있는지를 나타내는 한 개 이름입니다. 초안으로 신규 → 1차 연락 대기 → 초기 상담 완료 → 미팅/제안 진행 → 견적 발송 → 협의 중 → 계약 성사(계약서 송부 → 계산서 발행) 같은 흐름과, 별도 종료 상태로 고객 응답 대기·보류·계약 실패·상담 대상 재회가 나옵니다. [46:46]
AI는 여기서 좋은 제안을 하나 합니다 — 영업건이 미팅을 건너뛰고 바로 견적으로 가는 등 갈린 길이 많으니, 상태를 두 층으로 관리하자는 것입니다.
계약 실패와 장기 보류를 가르는 기준도 이 단계에서 정해집니다. 장기 보류는 마지막 연락·활동이 있은 지 3개월이 지나면 시스템이 자동으로 전환하고, 그중에서 사람이 모아 보고 수동으로 계약 실패 처리를 하는 식입니다. [48:31]–[50:11] 이렇게 해서 2차 시연(업무·데이터 분석)이 마무리됩니다.
3차 시연은 정보 구조 설계 → 화면별 핵심 목표 설정 → 상태별 화면 설계 세 단계로 진행됩니다. [50:44]
AI가 처음 제시한 메뉴 구조는 할 일 · 영업판 · 고객사(회사) · 성과 · 더보기 다섯 개였습니다. 이걸 다듬기 위해 AI는 실제 사용 방식을 캐묻습니다. 대시보드는 주로 PC와 모바일 중 어디서 쓰냐는 질문에 강사는 "솔직히 모바일에서 많이 사용할 것 같다 — 전화를 외부에서 받고, 그 내용을 외부에서 정리하는 일이 많기 때문"이라고 답합니다. [51:52]
영업건을 보는 방식은 단계별 영업판(칸반형) 중심으로 정합니다. 본인과 대표님이 같은 화면을 쓰되, 담당건을 먼저 보여 주고 전체도 볼 수 있게 합니다. 매출·첫 연락률 같은 성과 지표는 홈 화면에 넣지 않고 별도 화면으로 뺍니다 — 강사는 그 이유를 이렇게 설명합니다.
"성과 지표를 가장 먼저 보는 경우는 제가 이 행위를 하는 사람이 아니라 이걸 관제하는 관리자 입장일 때 그럴 것 같은데, 저는 제 스스로가 이걸 하는 사람이잖아요. 그래서 성과는 다른 화면에서 봐도 충분할 것 같습니다. 뭘 해야 되는지에 대한 행동에 직접 연결된 걸 저는 최우선으로 볼 거 같아요."
강사 [53:33]
이 판단은 "같은 대시보드도 쓰는 사람의 역할에 따라 첫 화면 우선순위가 달라야 한다"는 것을 보여 주는 대목입니다. 이어서 정보 구조를 확장하며 신규 상담을 웹사이트 접수 말고도 직접 추가할 수 있는 기능, 영업건 카드에서 목록을 열지 않고 바로 전화하거나 연락 완료 처리하는 빠른 버튼이 필요하다는 것도 이 단계에서 확정됩니다. [54:38]–[55:44]
정보 구조에서 나온 화면마다, 사용자가 그 화면에서 무엇을 달성해야 하는지를 한 문장으로 정합니다. 이미 정해진 여덟 개 화면의 목표를 정리하면 다음과 같습니다.
| 화면 | 핵심 목표 |
|---|---|
| 할 일 | 처리해야 할 영업건을 빠짐없이 확인하고 행동한다 |
| 영업판 | 전체 영업건이 어느 단계에 몰려 있고, 무엇이 멈춰 있는지 파악한다 |
| 영업건 상세 | 고객과의 맥락을 빠르게 이해하고, 연락 기록·위임·다음 행동 설정을 끝낸다 |
| 영업건 직접 추가 | 전화나 소개로 들어온 영업건을 최소한의 정보로 빠르게 등록한다 |
| 회사 | 특정 회사의 기본 정보와 과거·현재 영업 이력을 확인한다 |
| 성과 | 첫 연락률, 계약 상황, 예상 매출을 확인한다 |
| 관리 | 구성원과 서비스 등 시스템 운영에 필요한 기준 정보를 관리한다 |
이 중 "성과 → 예상 매출 확인"이라는 목표는 강사가 그 자리에서 한 번 더 캐묻습니다. "예상 매출이 나오려면 결국 계산 방식이 있어야 하는데, 그 로직이 뭔지 확인이 필요하다"는 것입니다. [56:52]–[57:57] AI가 제시한 방식은 단계별 성공 확률 × 추산 가치였는데, 별도 설정을 안 하면 리니어(1단계 10%, 9단계 90%처럼 균등)하게 잡을 가능성이 크다는 데 강사는 반대합니다.
"저는 굉장히 보수적이거든요. 계약이 성사됐을 때를 성공률 100%로 안 봅니다. 계산서 발행이 완료된 상태를 100%로 보고, 계약서 서명이 완료된 상태는 80%로 보일 겁니다."
강사 [58:32]–[60:13]
이렇게 단계별 성공 확률의 기본값(초기 상담 5% · 후속 진행 10% · 견적 발송 20% · 협의 중 40% · 계약서 송부 60% · 계약서 서명 80% · 계산서 발행 100%)이 정해지고, 성과 화면에는 전체 파이프라인 가치, 성공률을 반영한 가중 예상 매출, 계산서 발행 기준 확정 매출 세 가지 금액을 구분해 보여 주기로 합니다. [61:57]–[62:31]
상태값이 열 개나 되다 보니, 상태마다 화면에 다르게 보여야 할 것들을 정리합니다. 눈에 띄는 결정 두 가지가 있습니다. 첫째, 견적서·제안서·계약서·계산서 네 종류의 파일을 모두 영업건에 첨부하거나 링크로 보관하기로 했습니다 — 강사가 "미처 생각을 못 하고 있었다"고 인정한 대목입니다. [65:48] 둘째, 계약서 서명이 완료될 때 서비스별 계약 금액과 청구 일정을 반드시 입력해야만 다음 단계로 진행할 수 있게 만들었습니다. 강사는 이걸 "일에 대한 정의를 명료하게 해 주는 효과"라고 설명합니다 — 시스템이 강제로 입력을 막아 세워서, 사람이 빼먹을 수 없게 만드는 것입니다. [66:22]
이렇게 3차 시연(UX/IA 정보 구조 설계)이 마무리되고, 강사는 "굉위가 클 수 있는" 4차 시연으로 넘어갑니다.
여기서부터는 강사도 "개발자의 영역"이라고 못박는 단계입니다. 5개 하위 단계(구조 설계, API 명세, 배치 명세, 인터페이스 명세, 안정성 대비)로 진행됩니다. [68:02]
먼저 현재 환경을 확인합니다. 기존 상담 신청 사이트는 이머전트(Emergent)라는 웹빌더(AI로 웹사이트를 만들어 주는 도구)로 만들어졌고, 텔레그램 알림도 그 사이트 자체 기능입니다. 대시보드는 기존 관리자 화면에 얹지 않고 별도 웹사이트로 만들기로 합니다. [69:09]–[69:43]
이 단계에서 강사가 직접 AI의 제안을 뒤집는 장면이 나옵니다. AI는 넥스트JS(Next.js) 하나로 화면과 서버를 같이 만드는 구조를 제안했는데, 강사는 이를 거부합니다.
"우리 대시보드 자동화 시스템은 기능의 단위와 규모가 매우 커질 수 있다. 확장성이 보장되는 구성으로 다시 제안해 줘."
강사가 AI에게 보낸 요청 [73:36]–[74:10]
화면과 서버 기능을 처음부터 하나로 묶으면 나중에 기능이 많아졌을 때 나누기 어려워지므로, 처음부터 분리하는 구조를 요구한 것입니다. 이 요청을 받아 최종적으로 나온 구조는 Railway(배포 서비스)라는 플랫폼 위에서 웹·API·워커·크론(배치)이 각각 나뉘어 돌고, PostgreSQL(데이터베이스)과 Redis(작업 대기열·중복 실행 방지용)가 이를 뒷받침하는 형태입니다. [76:21]–[76:56]
배포 승인 절차도 이 단계에서 확정됩니다. develop 브랜치는 스테이징(테스트) 서버, main 브랜치는 프로덕션(운영) 서버에 연결하고, 운영 서버로 올라가는 건 강사 본인이 GitHub에서 직접 승인 버튼을 눌러야만 진행되도록 정합니다. [78:02]–[78:36] (이 브랜치·승인 절차가 실제로 어떻게 동작하는지는 8장에서 직접 확인합니다.)
이 시스템에는 세 종류의 API가 필요하다고 정리됩니다 — ① 이머전트가 신규 상담을 CRM으로 전달하는 API, ② CRM 안에서 영업·계약 데이터를 조회·수정하는 API, ③ 향후 다른 자동화 도구(AI 에이전트 등)가 CRM을 쓸 수 있게 하는 외부 API. [79:44]–[80:16]
이머전트에서 상담이 삭제돼도 CRM에서는 지우지 않고 "원본에서 삭제됨"이라고 표시해서 남겨 두기로 합니다. 이게 바로 소프트 딜리트(soft delete)입니다 — 데이터를 실제로 지우는 대신 "삭제됨" 상태만 표시해서 목록에서 안 보이게 하고, 필요하면 나중에 복구할 수 있게 남겨 두는 방식입니다. [83:38]–[84:10]
향후 확장을 대비해 웹훅(webhook)도 API 명세에 들어갑니다. 웹훅은 CRM에서 무언가 바뀌었을 때(예: 계약 성사), 외부 프로그램(회계 시스템이나 AI 등)이 그 변화를 실시간으로 받아볼 수 있게 알려 주는 API입니다. 지금 당장 연결할 대상이 없어도, 나중에 다른 자동화 도구가 CRM의 데이터를 받아 갈 수 있도록 처음부터 설계에 넣어 둡니다. [84:44]
배치(batch)는 정해진 시각이나 주기로 시스템이 자동으로 실행하는 업무입니다. 이 프로젝트에서 확정된 배치는 네 가지입니다 — 5분마다 이머전트 쪽 누락 상담을 확인하는 것, 업무일 오후 3시에 미수금을 알리는 것, 3개월간 활동이 없으면 자동으로 장기 보류로 바꾸는 것, AI 승인 대기 요청이 있으면 알리는 것입니다.
인터페이스(IF)는 외부 시스템과의 연결 방식을 뜻합니다. 강사는 1강에서 배운 개념을 다시 짚으며, 외부 서비스를 나중에 바꾸더라도(예: 이메일 발송 서비스를 바꾸는 경우) 내부 데이터 정의가 흔들리지 않도록 어댑터·추상화 같은 설계가 필요하다고 강조합니다. [09:19]–[10:25]
안정성 대비는 권한 관리, API 변경, 인증 만료, 데이터 오류, 중복 실행, 레이트 리밋(rate limit), 실행 실패 같은 것에 미리 대비하는 것입니다. 레이트 리밋은 "1분 안에 몇 번까지 호출할 수 있는지"를 정해 두는 연속 호출 한도를 말하며, 이 프로젝트에서는 계정별 분당 120회, 일괄 처리는 1회당 100건으로 정해졌습니다. 권한 구조는 관리자·열람자·AI 서비스 계정 세 가지로 최대한 단순하게 잡았고, 시스템이 멈춰도 되는 최대 시간은 "반나절" — 너무 빡빡하게 잡으면 불필요한 대비 작업만 늘어난다는 게 그 이유였습니다.
강사가 2장에서 미리 말했듯, 이 4차 시연은 "개발 지식이 없으면 하기 어려운 부분"입니다. 하지만 동시에 비개발자에게 가장 낯설고, 그래서 가장 배울 게 많은 부분이기도 합니다. 소프트 딜리트, 웹훅, 레이트 리밋 같은 개념을 모른 채 바이브 코딩에 의존하면, 이런 게 있는지도 모른 채 서비스가 나와 버려서 그 기능을 활용하지 못하는 경우가 생긴다고 강사는 지적합니다. [10:58]–[11:30]
프레임 목업(frame mockup)은 실제로 작동하는 기능 없이, 레이아웃과 UI 요소만 미리 배치해 보는 뼈대 화면입니다. 지금까지 명세한 내용을 실제 화면에 다 담아낼 수 있는지 먼저 확인하는 단계입니다. 강사는 Shadcn UI(자막에는 "샤드시엔"으로 표기됨 — UI 부품을 미리 만들어 둔 라이브러리)를 이용해 뼈대를 잡고, 각 화면을 하나씩 검수합니다. [100:52]
검수 중 강사가 짚은 대표적인 수정 요청은, 영업판 카드에 정보가 부족해서 초기 요청 내용 한 줄 미리보기를 추가해 달라는 것이었습니다. 이런 세세한 조정을 마친 뒤 강사는 이렇게 말합니다.
"모델 성능이 좋아집니다. 불과 몇 달 전만 해도 이런 거 뽑으면 제가 지적할 게 훨씬 많았어요."
강사 [104:00 무렵]
이 장에서 강사가 가장 힘주어 말하는 원칙입니다.
"UI는 어울리는 거 찾아서 갈아 끼우는 그게 아니고요. 정답이 있는 영역이에요, 논리예요."
강사 [12:04]
강사가 드는 예시는 이렇습니다 — 입력하려는 데이터가 배열(여러 개가 나열되는 형태)이라면, 거기에 대응하는 정답은 체크박스류입니다. 어떤 화면에서 탭 UI를 쓸지, 어떤 화면에서 내비게이션으로 아예 화면을 전환할지도 마찬가지로 "어울려서"가 아니라 데이터의 형태와 사용 맥락에 따른 논리적 결정입니다. 테마 선택도 다르지 않습니다.
"저는 디자인은 예술이 아니라고 생각합니다. 단, 그 디자인을 논리적으로 맞춰 가는 과정은 예술이라고 생각해요."
강사 [13:11]
UI를 어떻게 만들지 정할 때도 강사는 화면부터 고르지 않고, 또 한 번 AI의 인터뷰를 받습니다. 사용 맥락을 좁혀 가는 질문과 답을 정리하면 다음과 같습니다.
| 질문 | 강사의 답 |
|---|---|
| 대시보드에서 느껴야 할 인상 | 전문성 |
| 기존 로고·색상을 따를지 | 따른다 (스크린샷 제공) |
| 주 사용 환경 | 이동 중 모바일 |
| 글자에서 받는 인상 | 단정하고 중립적 |
| 기본 바탕 | 회색 바탕 + 흰색 카드 |
| 다크 모드 필요 여부 | 1차는 불필요 |
| 포인트 색(코발트블루) 사용 범위 | 주요 버튼·선택 상태·링크에만 |
이렇게 좁혀진 방향을 실제 스타일로 옮기기 위해, 강사는 "UI 디자인 스타일" 몇 가지를 훑어 봅니다 — 그림자 없이 납작한 플랫 디자인, 그림자로 층을 구분하는 머티리얼 디자인(구글 표준), 반투명 블러 효과의 플루언트 디자인(윈도우 11), 볼록·오목한 그림자의 뉴모피즘, 일부러 투박하게 만드는 브루탈리즘, 그리고 최근 애플이 즐겨 쓰는 글래스모피즘("뿌연 유리 효과") 입니다.
강사가 최종적으로 고른 것은 글래스모피즘입니다 — "기존의 플랫한 느낌보다 부드러운 느낌이 좋아 보인다"는 이유였습니다. 다만 화면 전체에 적용하지 않고, 헤더·메뉴·요약 카드·필터·팝업에만 적용하는 절제형을 골랐습니다. 데이터 가독성을 해치지 않으면서도 현대적인 느낌을 주기 위해서입니다.
마지막으로 강사는 UI를 구성하는 부품의 이름(배지, 카드 헤더, 쉐브론, 글로벌 내비게이션바 같은 것)을 알아 두라고 권합니다. 이유는 실용적입니다 — 유지보수할 때 "그 아이콘 있잖아요, 그거 좀 바꿔 주세요" 대신 "쉐브론 아이콘을 바꿔 주세요"라고 정확히 말할 수 있어야, AI와 의사소통이 빨라진다는 것입니다. 심화 훈련으로는 Shadcn UI의 컴포넌트를 하나씩 훑어보거나, Pinterest에서 다양한 디자인 스타일을 눈에 익히는 것을 권합니다.
MVP(Minimum Viable Product, 최소 기능 제품)는 설계한 전체 기능 중, 지금 당장 써먹을 수 있는 최소한의 핵심 기능만 먼저 만든 것입니다. 강사는 전체 화면 중 핵심 흐름(1영업일 이내 첫 연락 관리) 기준으로 DB와 API를 먼저 만든 뒤, 직접 검수합니다.
검수는 실제로 상담 정보를 등록하고, 영업건 상세를 열어 자동 계산된 첫 연락 기한을 확인하고, 활동 이력을 기록하고, 상태가 바뀌는지 확인하는 순서로 진행됩니다. 이 과정에서 실제 문제가 하나 발견됩니다 — 완료 버튼의 UI가 헷갈려서, 사용자가 "배경 확인" 버튼을 실제 완료 버튼으로 착각할 수 있는 구조였습니다. 강사는 그 자리에서 AI에게 "다음 행동 섹션에서 완료처럼 보이는 UI를 제거해 달라"고 요청했고, 약 10분 만에 수정된 걸 재검수로 확인합니다.
"적어도 15~20번 정도는 검수해야 MVP라고 할 만한 내용이 될 겁니다."
강사 [126:24 무렵]
강사가 시연에서 보여 준 건 이 15~20번 중 단 한 번이지만, 검수 → 문제 발견 → 수정 요청 → 재검수라는 반복 자체가 MVP 단계의 본질이라는 걸 실제로 겪은 문제로 보여 준 것입니다.
Railway는 GitHub에 올린 코드를 실제 서버에서 돌아가게 쉽게 배포해 주는 서비스입니다. 배포 준비로 Git 저장소를 연결하고(1강에서 이미 완료), Railway CLI를 설치하고, GitHub 계정으로 로그인합니다.
여기서 CLI(Command Line Interface)와 GUI(Graphical User Interface)의 차이가 잠깐 설명됩니다. GUI는 사람이 화면을 보고 마우스로 클릭하며 조작하는 방식이고, CLI는 글자로 된 명령어를 쳐서(또는 AI가 대신 쳐서) 조작하는 방식입니다. 배포 과정에서는 AI가 CLI 명령어를 대신 실행해 주는 방식으로 진행됩니다.
스테이징(staging)은 실제 운영 전에 미리 테스트해 보는 서버, 프로덕션(production)은 실제 고객이 쓰는 운영 서버입니다. 이 둘을 나누는 이유는 명확합니다.
"스테이징과 프로덕션은 같은 환경으로 구성하니까, 스테이징에서 문제 없으면 프로덕션에서도 99.99% 확률로 문제가 없습니다."
강사 [136:56 무렵]
실제로 스테이징 검수 중에 버그가 하나 발견됩니다 — 연락 기록 버튼을 누르면 스테이징 서버에서만 "Internal Server Error"가 뜨는 문제였습니다. 원인은 슬러그(slug)가 코드에 하드코딩되어 있었기 때문입니다. 슬러그는 URL에 쓰이는 특수한 개체 식별자(ID)를 말합니다(1강에서 배운 개념). AI에게 수정을 요청하고 다시 배포한 뒤, 재검수로 정상 작동을 확인합니다. 스테이징이 있었기 때문에 이 버그가 운영 서버로 넘어가기 전에 걸러진 것입니다.
강사는 실수로 운영 서버에 테스트 데이터를 넣는 사고를 막기 위해, 세 환경을 색으로 구분하는 기능도 추가합니다 — 로컬은 짙은 회색, 스테이징은 노란색, 프로덕션은 파란색 배지를 화면 우측 상단에 붙여, 지금 보고 있는 화면이 어느 환경인지 한눈에 알 수 있게 한 것입니다.
이제 실제 배포 절차를 시연합니다. develop 브랜치는 스테이징, main 브랜치는 프로덕션에 연결되어 있습니다(6장에서 미리 정한 구조입니다). 개발한 내용을 develop에 푸시(push, 로컬 변경 사항을 원격 저장소로 올리는 것)하면 스테이징에 자동 반영되고, 여기서 검수가 끝나면 PR(Pull Request, 풀 리퀘스트)을 만들어 main으로 병합을 요청합니다.
GitHub 화면에서 "Compare and Pull Request" 버튼을 누르면 변경 사항이 빨간 줄(삭제)과 초록 줄(추가)로 시각화되어 비교됩니다. 코드 충돌이 없는 걸 확인하고 "Merge pull request"를 누르면, main 브랜치의 변경이 감지되어 Railway가 자동으로 프로덕션 배포를 시작합니다.
배포에는 빌드(build) 과정이 필요합니다. 강사는 이걸 1강에서 배운 "컴파일"과 같은 개념이라고 설명합니다.
"템플릿으로 있는 패키지와, 실제로 작성한 소스코드를 합쳐서 브라우저에서 실행되는 완성품 하나로 만들어 주는 과정, 그게 지금 하고 있는 빌드입니다."
강사 [153:03]–[153:36]
빌드가 끝나고 화면을 새로고침하자, 화면 배지에 "프로덕션"이라는 표시가 뜹니다. 문제 정의부터 시작한 6단계 전체가 실제로 사용자 눈앞에 배포되는 순간을 이렇게 확인하며 강의는 마무리됩니다.
"이렇게 프로덕션이라는 배지가 자랑스럽게 잘 붙은 걸 확인할 수 있었습니다."
강사 [154:09]
강사는 강의를 마치며, 오늘 시연한 대로 똑같이 CRM 화면을 따라 만드는 것이 목표가 아니라고 분명히 합니다.
"각자가 가장 잘 알고 있는 업무 영역에서, 사용자가 누구인지, 반복되는 일이 무엇인지, 어디서 일이 막히는지, 어떤 상태와 데이터를 관리해야 하는지를 먼저 정의해 보는 것이 핵심입니다."
강사, 영상 설명글
화면부터 만들기 전에, 오늘 강사가 1차 시연에서 했던 것처럼 AI에게 자신을 인터뷰하게 하라는 것이 마지막 조언입니다. 물어볼 만한 질문 네 가지도 함께 제시됩니다 — "내가 매일 반복하는 업무는 무엇인지", "어떤 일을 자주 놓치는지", "누가 언제 무엇을 해야 하는지", "업무가 완료되었다고 판단하는 기준은 무엇인지". 그리고 처음부터 모든 기능을 한 번에 완성하려 하지 말고, 오늘 밟은 사이클(문제 정의 → 업무·데이터 분석 → UX/IA → 시스템 구조와 명세 → UI → MVP 구축과 검수 → 배포)을 일단 한 번 끝까지 돌려 보는 것이 중요하다고 강조합니다.
강사가 이 강의 전체를 관통해 남기는 한 문장은 이것입니다.
"AI 시대의 자동화 경쟁력은 툴을 많이 아는 것보다, 내가 알고 있는 업무를 얼마나 높은 해상도로 구조화하고 그것을 시스템의 규칙으로 바꿀 수 있는가에서 만들어집니다."
강사, 영상 설명글
| 낱말 | 뜻 | 나온 곳 |
|---|---|---|
| 바이브 코딩 | AI에게 말로 시켜서 프로그램을 만드는 방식 | 0장 |
| 대시보드 · 자동화 대시보드 | 여러 정보를 한 화면에 모은 것 · 반복 업무까지 시스템이 대신하는 대시보드 | 0장, 1장 |
| CRUD | 만들기·읽기·고치기·지우기. 많은 대시보드 기능의 기본 골격 | 0장, 1장 |
| API | 시스템끼리 데이터를 주고받는 약속(통로) | 0장, 6장 |
| 도메인 | 내가 다루는 업무 분야 | 0장, 3장 |
| 병목 | 업무가 막히는 지점. ROI 산출의 근거가 되는 자리 | 2장, 3장 |
| KPI | 자동화가 문제를 해결했는지 평가하는 핵심 지표 | 2장, 3장 |
| IA (정보 구조) | 어떤 화면이 필요한지 정하는 뼈대 설계 | 2장, 5장 |
| 배치 | 정해진 시각·주기로 시스템이 자동 실행하는 업무 | 6장 |
| 소프트 딜리트 | 실제로 지우지 않고 "삭제됨" 표시만 해서 숨기는 방식 | 6장 |
| 웹훅 | 데이터가 바뀌면 외부 프로그램에 실시간으로 알려 주는 API | 6장 |
| 레이트 리밋 | 일정 시간 안에 몇 번까지 호출할 수 있는지 정한 한도 | 6장 |
| 프레임 목업 | 기능 없이 레이아웃만 배치한 뼈대 화면 | 7장 |
| 글래스모피즘 | 뿌연 유리 같은 반투명 효과를 쓰는 UI 스타일 | 7장 |
| MVP | 전체 기능 중 최소한의 핵심만 먼저 만든 제품 | 8장 |
| 스테이징 · 프로덕션 | 테스트용 서버 · 실제 운영 서버 | 8장 |
| 슬러그 | URL에 쓰이는 특수한 개체 식별자(ID) | 8장 |
| PR (풀 리퀘스트) | 코드 변경을 다른 브랜치로 병합해 달라고 요청하는 절차 | 8장 |
| 빌드 (= 컴파일) | 패키지와 소스 코드를 합쳐 실제 실행 가능한 완성품으로 만드는 과정 | 8장 |
이 영상은 원어가 한국어이고, 유튜브 원어 자막(ko-orig)이 영상 시간을 거의 끝까지 채웠습니다(278묶음, 약 17만 자, 154분 42초 지점까지 — 영상 길이 154분 59초). 그래서 ko-orig를 그대로 썼습니다. 자동 번역본이 아니라 실제 음성을 받아쓴 자막이라 다른 언어 트랙과 비교할 필요가 없었습니다.
| 자막에 찍힌 것 | 실제로 추정되는 것 | 확인 방법 |
|---|---|---|
| "레일이" · "레일웨이" · "레일베이" · "레일베일" | Railway(배포 서비스). 같은 대상을 가리키는 자리에서 표기가 계속 바뀝니다 | 문맥 — "깃허브에 올린 코드를 배포하는 서비스"라는 설명이 매번 이어짐 |
| "샤드시엔" | Shadcn UI(UI 컴포넌트 라이브러리) | 문맥 — "1강에서 배운" 수식과 UI 컴포넌트 설명이 뒤따름 |
| "몽고디비" · "몽고디" | MongoDB(데이터베이스) | 문맥 — "데이터베이스"라는 설명이 바로 붙음 |
| "포스트레 SQL" | PostgreSQL | 문맥 — Railway 구성 요소를 나열하며 데이터베이스 자리에 등장 |
| "기터" · "깃업" · "기터 액션스" | GitHub · GitHub Actions | 문맥 — "코드 저장소", "1강에서 배운 CI/CD 도구"라는 설명이 이어짐 |
| "엑스트라 하이 5.6솔" | 강사가 4차 시연까지 쓰겠다고 밝힌 AI 모델(강한 추론 설정)의 이름으로 추정되나, 정확한 모델명은 확정하지 못했습니다 | 확인 못 함 |
| "트루노스크루" · "트루노스 크루" | 강사가 시연용으로 지은 프로젝트 회사명. 정확한 로마자 철자는 자막만으로 확정할 수 없습니다 | 확인 못 함 |