📝 한줄 요약
지난 글에서 Airtable 링크 연결을 끝냈다면, 이번 단계는 “운영자가 매일 보는 화면”을 만드는 일이었다. 대시보드는 만들었고 Vercel로 배포도 했지만, 그 과정에서 실시간 구조와 정적 배포의 차이, 인터랙티브 차트 버그 같은 현실적인 이슈를 제대로 배웠다.
<참고> 하단의 개인정보는 모두 가상입니다.
한국 회사의 대시보드
한국사이트 스크린샷
한국 모바일 앱 스크린샷
바쁘시면 이것만 읽어도 돼요
데이터 연결 이후 HTML 대시보드를 바로 구축해서 프로그램별 신청/합격/수료를 한 화면에 시각화했다.
운영 이슈 카드를 넣어 “확인 대상 추출”까지 한 번에 하도록 만들었다.
인터랙티브 필터를 붙인 뒤
합격/수료그래프가 0으로 보이는 버그가 생겼고, 문자열 비교 로직을 고쳐 해결했다.Vercel 배포는 성공했지만, 현재 구조는 실시간 앱이 아니라 정적 리포트 공유 방식이라는 점을 확인했다.
지난 글에서 어디까지 했는지
이전 글에서는 Airtable 안에서 흩어진 데이터를 연결하는 데 집중했다.
항목 목록을 보여주는 웹페이지의 스크린샷
신청자 ↔ 교육프로그램 링크 정리
합격자 중심 데이터 연결 자동화
프로그램 단위로 신청자/강사진을 같이 볼 수 있는 기반 확보
즉 “데이터를 연결하는 일”은 끝났다. 이번에는 그 데이터를 실제 운영 판단에 쓰기 위한 “화면”을 만드는 단계였다.
이번 목표는 단순했다
“테이블은 연결됐는데, 그래서 오늘 뭐부터 확인해야 하지?”를 한 화면에서 답할 수 있게 만들고 싶었다.
그래서 대시보드 요구사항을 이렇게 잡았다.
프로그램별 신청/합격/수료 흐름을 바로 본다.
대표가 숫자만 봐도 현재 운영 상태를 파악할 수 있어야 한다.
실무자가 후속 조치 대상을 즉시 확인할 수 있어야 한다.
실제로 만든 것
로컬에서 실행하면 HTML이 생성되는 운영 리포트 구조로 구현했다.
상단 KPI: 프로그램 수, 신청자 수, 합격률, 수료율
프로그램별 막대 차트: 신청/합격/수료 비교
상태 분포 차트
운영 이슈 카드: 미연결, 미수료, 상태 미입력
신청자 탐색/필터
여기서 핵심은 “보여주기”가 아니라 “바로 조치할 수 있게” 만든 점이었다. 운영 이슈 카드는 단순 요약이 아니라 확인 대상 리스트를 바로 꺼내서 실무자가 즉시 움직일 수 있도록 설계했다.
시행착오: 인터랙티브 붙인 뒤 그래프가 깨졌다
가장 크게 배운 지점이 여기였다.
인터랙티브 필터를 추가한 뒤, 신청/합격/수료 중 합격/수료 막대가 정상적으로 안 보이는 문제가 생겼다. 데이터는 있는데 차트에서만 이상했다.
원형 차트가 있는 한국 앱의 스크린샷
원인을 추적해보니, 프로그램 집계 함수의 조건문 문자열이 깨져 있었다.
의도:
status === "합격",completion === "수료"실제: 잘못된 문자열(
??) 비교로 들어가서 카운트가 0 처리됨
해결은 단순했지만 중요한 교훈이 남았다.
인터랙티브 기능을 추가하면 “데이터 fetch”보다 “집계/렌더링 조건”에서 깨질 확률이 높다.
시각화 버그는 보통 데이터가 없는 게 아니라, 조건식이 틀린 경우가 많다.
필터 전/후를 같은 데이터셋으로 비교하는 검증 루틴이 꼭 필요하다.
Vercel 배포에서 알게 된 점
배포는 잘 됐다. 그런데 더 중요한 건 구조를 정확히 이해한 것이었다.
현재 구조는 아래 흐름이다.
로컬에서 스크립트로 Airtable 데이터를 읽는다.
정적 HTML(
public/index.html)을 생성한다.생성된 파일을 Vercel에 배포한다.
즉, 이건 실시간 대시보드가 아니다. “최신 스냅샷 공유”에 가깝다.
이걸 헷갈리면 “배포했는데 왜 자동으로 안 바뀌지?”라는 질문이 계속 나온다. 이번에 이 부분을 명확히 정리해둔 게 실제 운영에서는 꽤 큰 수확이었다.
그래서 운영이 어떻게 달라졌나
이번 후속 작업으로 체감한 변화는 아래 세 가지였다.
프로그램별 병목(미연결, 미수료)을 찾는 시간이 줄었다.
대표/실무자가 같은 화면을 보고 이야기할 수 있게 됐다.
데이터 연결 단계에서 끝나지 않고, 운영 액션까지 이어지는 흐름이 생겼다.
지난 글이 “데이터 연결 자동화”였다면, 이번 글은 “연결된 데이터를 운영 의사결정에 쓰는 단계”라고 정리할 수 있다.
다음 단계에서 할 일
여기서부터는 선택의 문제다.
지금 구조를 더 단단하게 운영(체크리스트, 검증 루틴, 리포트 품질 고도화)
Airtable 직접 조회형으로 바꿔 실시간 대시보드로 전환
당장은 전자를 먼저 하기로 했다. 이유는 명확하다. 실시간 전환보다 먼저, 지금 운영팀이 매일 쓰는 흐름이 안정되는 게 더 중요하기 때문이다.
마무리
지난 글에서 “연결”을 해결했다면, 이번에는 “활용”을 시작한 단계였다.
비슷한 상황이라면, 데이터 연결 다음 단계에서 바로 대시보드를 크게 벌리기보다 “운영 액션이 실제로 빨라지는지”부터 확인해보는 걸 추천한다.
