한 줄 요약
리테일 MD인 제가 — 매출 자동 수집 시스템을 만든 후 — 그 다음 단계인 "운영자가 매일 보고 판단하는 화면"을 설계하면서 — 코드를 짜는 게 아니라 에이전트가 움직일 환경을 먼저 그려야 한다는 하네스 엔지니어링을 도전해본 이야기예요.
───
이전 글과의 연결 (이 글은 후속편이에요)
이전 사례글에서는 5개 사이트의 매출을 Claude Code + Playwright로 자동 수집하는 "스킬"을 만들었어요.
"스킬은 에이전트의 외부 메모리다" — 일회성 스크립트를 재호출 가능한 형태로 묶으면, 매일 같은 절차를 한 줄 트리거로 불러올 수 있게 된다는 것.
이번 글은 그 다음 단계예요. 수집 데이터가 잘 쌓이니까, 이제는 실무 보고에 필요한 대시보드가 필요해졌어요.
───
이런 분들께 도움돼요
• 자동화는 완성했는데 막상 매일 활용이 안 되는 분
• 데이터를 쌓고 있음에도 "전일 대비가 얼마지?"를 또 계산하고 있는 분
• 에이전트/자동화 도구를 운영에 진짜 붙이고 싶은 비개발자
• "코드는 못 짜도 환경 설계는 내가 한다"는 게 무슨 뜻인지 궁금한 분
───
시작점: 수집은 됐는데 "보는 화면"이 없었다
매출 자동 수집 시스템이 완성된 후, 이상한 점이 생겼어요.
5개 사이트의 매출이 슬랙으로 잘 들어오는데, 담당자가 "보고 판단"하기에는 슬랙 메시지가 부족했어요.
• 어제 대비는? 지난주 대비는?
• 이달 전체 누적은? 주간 흐름은?
• 어떤 채널이 이번 주 저조하지?
그냥 숫자 5개가 나오는 슬랙 메시지로는 상부 보고도, 매장 운영 의사결정도 하기 어려웠어요.
수집한 데이터를 저장만 하고 있었지, "어떻게 볼 것인가"는 설계하지 않았던 거죠.
"에이전트가 자동으로 데이터를 잘 모아도,
운영자가 매일 꺼내 보고 의사 결정할 수 있는 화면이 없으면
그건 반쪽짜리 자동화다."
───
대시보드 설계와 구현
• Daily 대시보드 — 오늘 합계 + 전일 대비 % + 전주 대비 % 요약 카드 3종 + 채널별 상세 카드
• Weekly 탭 — 7일치 채널별 매출 테이블 + 전주 대비 증감률 배지 + 공휴일 자동 표시
• 관리자 인증 — 권한 없으면 접근 차단 (store_admin / super_admin 역할 분기)
• 모바일 반응형 — 좁은 화면에서도 매출액이 깨지지 않는 UI
• 브랜드 UI — 관리자 바 로고 삽입, 채널별 아이콘 색상 코딩
───
사용한 도구
• Claude Code (쩨홉): 대시보드 UI 전체를 자연어로 설계하고 구현. 비개발자인 나는 코드를 안 짬
• Next.js 15 + Tailwind CSS: 대시보드 프론트엔드
• Supabase: 매출 데이터 저장 (테이블 설계 + Auth 관리자 인증까지)
• Vercel: 배포
• Playwright (기존): 수집 파이프라인은 그대로 유지
• Dual-POST: 기존 수집 스크립트를 건드리지 않고 Supabase로 병렬 저장하는 구조
───
이전 사례글에서 배운 점 4를 더 깊이 파본 게 이번 작업의 핵심이에요.
"코드보다 에이전트의 작업 환경을 설계해라"
당시엔 "스킬 파일, MEMORY.md, SOUL.md 같은 텍스트 파일을 정비하는 것"이 하네스 설계라고 했어요.
그런데 이번에 발견한 건 — 대시보드도 하네스라는 것.
대시보드는 단순한 UI가 아니에요.
• 운영자가 매일 어떤 정보를 어떤 순서로 봐야 하는지 — 정보 계층 설계
• 누가 이 화면을 볼 수 있어야 하는지 — 권한 경계 설계
• 어떤 숫자가 나왔을 때 바로 의사결정을 할 수 있는지 — 컨텍스트 설계
이걸 먼저 정해놓으면, 에이전트(Claude Code)가 자동으로 그 방향으로 움직여요.
대시보드가 "에이전트가 어떤 형태로 데이터를 내보내야 하는지"의 스펙이 되는 거죠.
이게 하네스 엔지니어링이에요. 코드를 짜는 게 아니라 에이전트가 움직일 무대를 먼저 그려놓는 것.
그리고 이번에 새로 시도한 방법이 있었어요.
이번 작업을 시작하기 전에, 전체 작업을 세 단계(Session A / B / C)로 나누고
각 단계의 목표와 예상 소요 시간을 미리 정했어요.
• Session A — 데이터 저장 구조 설계 + API 엔드포인트 구축
• Session B — 관리자 인증 + Daily 대시보드 UI + Weekly 탭 추가
• Session C — 브랜드 UI + 모바일 최적화 + 디테일 마감
이게 사소해 보이는데, 실제로는 엄청난 차이를 만들었어요. 에이전트(Claude Code)가 각 세션에서 해야 할 것과 하지 말아야 할 것이 명확했고, 중간에 멈추거나 재개해도 컨텍스트가 유지됐어요. 범위가 무한정 늘어나는 "스코프 크리프"도 없었어요.
작업을 시작하기 전에 구조를 설계하는 것, 비개발자이면서 아직 초보인 제가 스스로 시도해본 하네스 엔지니어링입니다:) 코드를 짜기 전에, UI를 만들기 전에, 에이전트가 어떤 단위로 일하고 어디서 멈추고 어디서 다시 시작하는지를 먼저 그려두는 것.
───
진행 과정
1. 수집 데이터를 저장층으로 흘려보내기 (Dual-POST)
가장 먼저 한 건 "기존 시스템을 건드리지 않는 것"이었어요.
운영 중인 수집 파이프라인(슬랙 알림)은 그대로 두고, 같은 데이터를 Supabase에도 저장하는 API 엔드포인트를 병렬로 추가했어요.
기존 스크립트는 1줄도 수정하지 않았어요.
2. 관리자 인증 + Daily 대시보드 UI
Supabase Auth로 로그인 게이트를 세웠어요. 권한 없으면 차단.
Daily 탭에는 오늘 합계·전일 대비%·전주 대비% 요약 카드 3개를 배치하고, 아래에 채널별 상세 카드를 정렬했어요.
특정 결제 데이터가 있는 날에만 해당 카드가 자동 노출되는 로직도 함께 구현했어요.
3. Weekly 탭 + 보고용 요약
7일치 채널별 매출을 테이블로 보여주는 Weekly 탭 추가.
공휴일 날짜에 자동으로 뱃지가 붙어요 — 매출 급감의 맥락을 숫자와 함께 전달하기 위해서예요.
Weekly Revenue에 전주 동일 기간 대비 % 배지를 붙이면, 이 화면 하나로 상부 보고가 끝났어요.
4. 운영 규칙을 UI에 반영
모바일에서 폰트가 2줄로 터지던 문제 → text-2xl sm:text-4xl 반응형으로 해결.
관리자 바에 브랜드 로고 삽입 + 2줄 레이아웃.
로그아웃 버튼 hover 시 둥근 배경 인터랙션 추가.
"이 대시보드가 신뢰할 수 있는 도구처럼 보이는가?" — 이 기준으로 작은 디테일을 하나씩 붙였어요.
───
핵심 하네스 설계 결정들
비파괴 확장 원칙 (Dual-POST)
운영 중인 시스템을 건드리지 않고 새 기능을 붙이는 것. 이게 이번 작업에서 가장 중요한 결정이었어요.
게이트 설계 (Supabase Auth)
"누구나 접근 가능 vs 관리자만 vs 권한별로 다름" — 이 세 가지 중 하나를 고르는 게 단순한 기술 선택이 아니라 운영 철학이에요. 우리는 권한별 차등 노출을 선택했어요.
정보 계층 설계 (Daily/Weekly 탭)
한 화면에 다 보여주려는 욕심을 버리고, "오늘의 빠른 판단"은 Daily, "주간 흐름 파악"은 Weekly로 분리. 탭 전환 하나가 정보 과부하를 해결해줬어요.
컨텍스트 설계 (공휴일 뱃지, 대비%)
숫자만 있으면 맥락이 없어요. "왜 그날 매출이 낮았지?"라는 질문의 답을 미리 화면에 넣어두는 것. 이게 진짜 보고용 대시보드와 단순 데이터 조회의 차이예요.
───
Before vs After
Before
• 슬랙 메시지에서 숫자 5개 확인 → 전일 대비를 직접 계산 → 주간 흐름은 스프레드시트 열어서 따로 정리
• 상부 보고 시 별도 작업 필요
After
• 대시보드 열면 오늘 합계 + 전일/전주 대비% + 채널별 상세 한눈에
• Weekly 탭에서 주간 흐름 바로 확인
• 이 화면 그대로 상부에 보여주거나 보고서에 붙이면 끝
── ─
결과와 배운 점
결과
수집 + 저장 + 대시보드까지 하나의 파이프라인이 완성됐어요. 크론잡이 자동으로 데이터를 모으고, 대시보드는 항상 최신 상태.
항공사 홈페이지 스크린샷
배운 점 1 — 자동화의 끝은 운영
수집을 자동화하는 건 시작이에요. "운영자가 그것을 매일 볼 수 있는가"가 진짜 자동화의 완성이에요. 아무리 잘 수집해도 보는 화면이 없으면 반쪽이에요.
배운 점 2 — 하네스가 에이전트를 똑똑하게 한다
"어떤 화면을 만들어야 하는가"를 먼저 정하니, Claude Code가 자동으로 그 방향으로 움직였어요. 에이전트에게 무대를 주면, 에이전트는 자기 역할을 알아요.
배운 점 3 — 비파괴 확장이 운영의 안정성을 만든다
기존 시스템을 건드리지 않고 새 기능을 붙이는 원칙. 이전 글에서 "스킬화가 재사용을 가능하게 한다"고 했다면, 이번엔 "비파괴 확장이 운영 안정성을 만든다"를 실감했어요.
배운 점 4 — 작은 UI 디테일이 신뢰를 만든다
공휴일 뱃지, 전주 대비 %, hover 인터랙션 — 이런 작은 것들이 없으면 "동작하는 도구"예요. 있을 때 "매일 신뢰하고 쓰는 도구"가 돼요. 비개발자가 코드를 못 짜도 "무엇을 넣을지"는 설계할 수 있어요.
───
다음 단계
• 실패 자동 재시도 + 휴먼-인-더-루프 ㅡ수집 실패 시 N회 자동 재시도, 끝까지 실패하면 "① 완료된 채널 ② 실패 채널 ③ 수동 확인 링크" 형식으로 보고
• 알림 레이어 — 비정상 매출 패턴 감지 시 Slack 자동 알림
• 권한별 필터 세밀화 — super_admin은 전체, store_admin은 담당 채널만 보이도록