업무 대시보드 제작 교육 사례 | DAS 바이브코딩 2일차 7시간 과정 (2026년 7월)

바이브코딩의 핵심은 코딩이 아니라 PRD입니다. PRD(제품 요구사항 정의서)는 앱을 만들기 전에 무엇을 왜 만들지 정리한 설계도입니다. 설계 없이 시작하면 수정이 반복되고, 기능 하나를 고치다 다른 기능이 망가집니다.

2026년 7월, 딥택트러닝 박재현 소장은 DAS 구성원을 대상으로 「2026년 바이브코딩 역량강화교육」 2일차를 7시간 과정으로 진행했습니다. 1일차에서 프롬프트와 챗봇을 다뤘다면, 2일차는 대시보드와 업무 미니앱을 직접 만드는 실습입니다.

교육 개요

• 교육 주제 : 바이브코딩으로 업무생산성 높이기 (2일차)
• 교육 대상 : DAS 구성원
• 교육 일자 : 2026년 7월
• 교육 시간 : 7시간 (09:00~17:00)
• 참석 규모 : 20여 명
• 교육 방식 : 개인 실습, 조별 토론

프롬프트로 되는 일과 앱이 필요한 일

문서를 만드는 것은 프롬프트로 됩니다. 그런데 반복되는 업무 양식을 자동화하거나 팀 데이터가 쌓이는 화면을 만들려면 다른 접근이 필요합니다.

이 교육은 업무를 세 갈래로 나눠 보게 합니다.

• 한 번 하고 마는 콘텐츠 제작 → 프롬프트
• 반복되는 질문과 양식 → 챗봇 또는 프로젝트
• 입력 양식과 데이터 축적이 필요한 업무 → 앱과 대시보드

이 구분이 서면 AI 활용이 체험에서 생산성으로 넘어갑니다.

미니 PRD — 다섯 가지만 정리합니다

바이브코딩은 "AI에게 앱을 만들어달라고 시키는 것"으로 끝나지 않습니다. 시작 전에 다섯 가지를 정리합니다.

• 누가, 언제, 무엇을 위해 쓰는 앱인가
• 사용자는 어떤 흐름으로 화면을 사용하는가
• 꼭 필요한 기능과 이번에는 제외할 기능은 무엇인가
• 화면은 어떻게 구성되는가
• 입력값과 출력값은 무엇인가

이 다섯이 정리되면 AI에게 업무 맥락이 명확히 전달되고 결과물의 품질이 달라집니다. 제외할 기능을 적는 세 번째 항목이 특히 중요합니다. 범위를 안 자르면 앱이 끝나지 않습니다.

대시보드는 3초 안에 읽혀야 합니다

2일차 중심 실습은 한 페이지 HTML 대시보드 제작입니다. 좋은 대시보드는 예쁜 화면보다 읽히는 구조가 먼저입니다. 네 원칙을 적용했습니다.

• 한눈에 — 핵심 KPI를 맨 위에 배치
• 차트 — 숫자를 비교 가능한 시각 자료로
• 필터 — 원하는 조건만 골라 볼 수 있게
• 모바일 — 휴대폰에서도 읽히는 화면

이후 라인 필터, 탭, 검색, 상세 보기, 디자인 규칙 파일(Design.md)처럼 실제 사용성을 높이는 요소를 붙여가며 고도화했습니다.

화면이 나왔다고 끝이 아닙니다 — 검증·저장·테스트

실무 앱은 화면이 만들어졌다고 완성이 아닙니다. 사용자가 잘못된 값을 넣었을 때 막아야 하고, 입력한 데이터는 저장돼야 하며, 다시 열었을 때도 남아 있어야 합니다.

생산실적 입력 폼을 예시로 입력 검증을 설계했습니다.

• 숫자만 허용하기
• 0 이상만 받기
• 불량수량이 생산수량보다 클 수 없게 하기
• 에러 메시지를 한국어로 표시하기

세 번째가 중요합니다. 형식만 맞으면 통과시키는 검증과, 업무 규칙상 말이 안 되는 값을 막는 검증은 다릅니다. 앞의 것은 AI가 알아서 해주지만 뒤의 것은 그 일을 아는 사람이 알려줘야 합니다.

저장은 localStorage를 썼습니다. 서버 없이 브라우저에 데이터를 남기는 방식입니다. 새로고침하고, 탭을 닫았다 열고, 브라우저를 껐다 켜서 데이터가 유지되는지까지 확인했습니다. 만든 사람이 직접 테스트해보는 것까지가 실습입니다.

교육 설계 관점 : 데이터가 먼저입니다

대시보드 실습에서 자주 나오는 장면이 있습니다. 화면은 그럴듯한데 숫자가 이상한 경우입니다.

원인은 대부분 원본 데이터에 있습니다. 항목 이름이 통일돼 있지 않거나, 빈 칸이 섞여 있거나, 같은 값이 다르게 표기돼 있습니다. AI는 그 상태 그대로 화면을 그립니다.

그래서 대시보드를 만들기 전에 원본 데이터를 점검하는 단계를 앞에 뒀습니다. 항목명을 통일하고 빈 칸을 확인하는 데 시간을 쓰면, 뒤에서 화면을 고치는 시간이 줄어듭니다.

바이브코딩 교육에서 가장 흔한 실망은 앱이 안 만들어지는 게 아니라 만들어진 앱의 숫자를 믿을 수 없는 것입니다. 그 원인은 거의 항상 도구가 아니라 데이터에 있습니다.

이런 조직에 추천합니다

• 팀 데이터를 모아 보는 화면이 필요한 조직
• 엑셀 취합·집계 업무가 매주 반복되는 부서
• 1일차 과정을 마치고 실제 결과물까지 만들려는 기업
• 현업이 직접 업무 도구를 만드는 문화를 시작하려는 조직