숫자 카드 네 개, 매끈한 그래프, 둥근 모서리, 보라색 강조색. AI에게 대시보드를 만들어 달라고 했더니 필요한 부품은 다 나왔습니다. 그런데 정작 어떤 정보부터 봐야 할지는 잘 보이지 않습니다. 코드도 실행되고 버튼도 눌리지만, 완성된 제품보다 샘플 화면처럼 느껴지는 이유입니다.
바이브 코딩 대시보드가 어설퍼 보이는 이유는 장식이 부족해서가 아니라 판단 기준이 없기 때문입니다. 여기서 바이브 코딩은 자연어로 요구하고, AI가 만든 화면을 보며 반복해 고치는 작업 방식을 뜻합니다. AI로 만든 모든 화면이 나쁘다는 뜻은 아닙니다. 이 글은 특정 모델의 우열을 가리는 실험이 아니라, 공식 디자인 지침에 비추어 실무에서 놓치기 쉬운 지점을 짚어봅니다.
1. 예쁜 부품은 있지만 읽는 순서가 없다
매출, 방문자, 오류율, 가입자 수를 같은 크기의 카드에 넣으면 화면은 균형 잡혀 보입니다. 하지만 운영 담당자가 서비스 장애를 살펴보는 화면이라면 오류율과 미처리 경고가 먼저 눈에 들어와야 합니다. 같은 정보라도 경영 보고용인지, 장애 대응용인지에 따라 자리가 달라져야 합니다.
Carbon의 프레젠테이션 대시보드 지침은 중요한 정보를 앞세우고, 불필요한 지표를 줄이며, 시각적 위계를 분명히 하라고 안내합니다. 이 지침을 실제 작업에 적용하려면 컴포넌트를 고르기 전에 사용자가 내려야 할 결정부터 적어야 합니다. 카드를 반드시 네 개 놓아야 할 이유는 없습니다. Carbon의 대시보드 지침
고객지원 팀장이 “어느 문의부터 처리해야 하나?”를 판단해야 한다면, 미처리 건수만 크게 띄워서는 부족합니다. 약속한 응답 시간을 넘긴 문의와 담당자가 없는 문의를 먼저 보여주고, 목록을 눌러 바로 배정할 수 있어야 합니다. 예쁜 요약 카드보다 첫 화면에서 다음 행동으로 이어지는 구성이 중요합니다.
2. 숫자는 큰데 단위와 비교 기준이 없다
“응답 시간 4.2”만 적힌 카드는 제대로 읽기 어렵습니다. 4.2가 초인지 시간인지, 평균인지 중앙값인지, 어느 기간에 접수된 문의를 모은 것인지 알 수 없기 때문입니다. 초록색 상승 화살표가 붙어 있어도 응답 시간이 늘어난 것을 좋은 변화로 보는지부터 헷갈립니다. 지표의 뜻은 빼고 색으로 평가를 대신한 셈입니다.
아래 숫자는 설명을 위해 만든 가상 고객지원 데이터입니다. 실제 서비스의 운영 수치나 개선 효과를 나타내지 않습니다. 숫자는 그대로 두고 설명과 배치만 바꾸는 예시입니다.
첫 응답 시간은 “4.2” 옆에 초록색 상승 화살표만 두지 말고, “중앙값 4.2시간 · 선택한 7일 · 직전 7일 3.0시간”으로 써야 단위와 기간이 보입니다.
변화량도 “+40%”만 강조하기보다 “1.2시간 증가 · 응답 속도 악화”라고 표시하면 변화의 의미까지 알 수 있습니다.
미처리 문의는 “128”만 보여주지 말고, “미처리 128건 · 그중 응답 목표 초과 23건”으로 적어 먼저 확인할 대상을 나눠야 합니다.
다음 행동으로 이어지는 버튼이라면 “상세 보기”보다 “목표 초과 문의 23건 확인”이 누르면 어디로 가는지 분명합니다.
계산은 따로 떼어 확인해야 합니다. 4.2시간에서 3.0시간을 빼면 1.2시간이고, 이를 기준값 3.0시간으로 나누면 40% 증가입니다. 다만 기준값이 0이면 같은 방식으로 증가율을 계산할 수 없습니다. 이때는 무한대나 임의의 퍼센트 대신 “비교 불가”와 절대 변화량을 표시하는 편이 정직합니다.
NN/g는 숫자를 해석하려면 비교할 맥락이 필요하고, 차트를 만들기 전에 전달할 목표부터 정해야 한다고 설명합니다. 대시보드에서는 각 지표 옆에 정의, 단위, 기간, 비교 기준을 함께 적는 방법으로 적용할 수 있습니다. NN/g의 차트 맥락과 선택 기준
3. 차트를 질문이 아니라 빈자리에 맞춰 고른다
빈칸이 정사각형이라고 도넛 차트를 넣고, 넓은 칸이 남았다고 꺾은선을 넣으면 화면은 채워집니다. 그러나 고객지원 유형별 건수를 비교하는 일과 시간에 따른 문의량을 보는 일은 서로 다른 질문입니다. 같은 데이터를 담을 수 있다고 해서 같은 차트가 어울리는 것은 아닙니다.
유형별 크기 차이를 보려면 막대그래프를, 날짜 순서에 따른 변화를 보려면 꺾은선그래프를 먼저 검토할 수 있습니다. 한국어 항목 이름이 길다면 가로 막대를 써서 라벨을 비스듬히 돌리지 않고도 표시할 수 있습니다. 반면 담당자별 정확한 건수를 확인하고 정렬해야 한다면 표가 더 직접적입니다. 앞서 인용한 NN/g 자료도 전달 목적에 맞는 기본 차트를 고르라고 강조합니다.
점검할 때는 이 질문으로 시작해 보세요. “이 그래프를 지우고 숫자 표로 바꾸면 무엇을 잃는가?” 패턴이나 비교 결과를 더 빨리 읽을 수 있는 것도 아니라면, 그래프가 장식으로만 쓰이고 있지 않은지 살펴봐야 합니다. 축의 범위, 빠진 날짜, 필터가 적용되는 범위도 함께 확인하세요. 차트가 화면에 그려졌다는 사실만으로 데이터 표현이 맞다고 판단해서는 안 됩니다.
4. 디자인 규칙 대신 유행하는 스타일만 붙인다
Anthropic이 2025년에 공개한 블로그 글은 별도의 안내 없이 LLM에게 랜딩 페이지를 만들게 하면 익숙한 디자인 패턴으로 수렴할 수 있다고 설명합니다. 그러면서 타이포그래피와 테마처럼 구체적인 지침을 주는 예시를 제시합니다. 다만 이는 자사 도구의 프롬프팅 방법을 설명한 자료입니다. 다른 모델이나 업무용 대시보드에서도 같은 결과가 난다고 일반화할 수는 없습니다. Anthropic의 프런트엔드 디자인 가이드
여기서 “보라색을 금지하면 된다”고 결론 내리면 다른 템플릿을 반복하기 쉽습니다. 업무용 화면에서는 개성 있는 폰트보다 긴 한국어 라벨의 줄바꿈, 숫자 정렬, 읽기 편한 본문이 더 급할 수 있습니다. Inter나 시스템 폰트 자체가 문제인 것도 아닙니다. 폰트 이름보다 어디에 쓰는지를 먼저 보세요.
먼저 제목, 본문, 보조 설명, 지표 숫자의 역할을 나누고 간격과 색에 이름을 붙이세요. 예를 들어 기본 글자색, 보조 글자색, 경고색을 구분하고 같은 의미에는 같은 값을 쓰도록 정합니다. 수정할 때도 카드를 하나씩 고치기보다 공통 규칙을 바꾸면 요소마다 들쭉날쭉한 화면을 줄일 수 있습니다.
흐린 회색 글자는 세련돼 보여도 읽기 어려울 수 있습니다. WCAG 2.2의 텍스트 대비 기준은 일반 텍스트에 최소 4.5:1, 큰 텍스트에 최소 3:1을 요구합니다. 여기서 큰 텍스트는 대체로 18pt 이상 또는 굵은 14pt 이상을 뜻하며, 18px과 같은 뜻이 아닙니다. 예외 조항이 있고, 이 기준을 통과했다고 접근성 요건을 모두 충족하는 것도 아닙니다. W3C의 최소 대비 해설
5. 정상 데이터가 있을 때의 한 장만 완성한다
문의가 적당히 들어 있고 이름도 짧은 목업에서는 화면이 멀쩡해 보입니다. 그러나 데이터가 하나도 없거나 요청이 실패하면 어떨까요? 아무 설명 없이 그래프만 사라지면 이용자는 결과가 0건인지, 데이터를 불러오지 못한 것인지 구분할 수 없습니다. 표의 빈 셀을 0으로 채우면 실제 측정값이 0이라고 오해할 수 있습니다.
Carbon의 빈 상태 지침은 왜 비어 있는지와 사용자가 다음에 할 일을 안내하라고 설명합니다. 이 원칙에 따라 첫 사용, 필터 결과 없음, 권한 부족, 요청 실패를 서로 다른 문구와 행동으로 설계할 수 있습니다. Carbon의 빈 상태 지침
테스트 데이터에도 다루기 까다로운 사례를 넣어 보세요. 긴 한국어 제목, 매우 큰 숫자, 값이 없는 항목, 기준값이 0인 비교, 행이 많은 표가 그 예입니다. 좁은 화면에서는 핵심 카드의 순서를 다시 정하고, 표를 가로로 스크롤할 수 있다는 점을 분명히 알려야 합니다. 이 사례들은 특정 제품에서 실제로 측정한 장애가 아니라, 초안 단계에서 활용할 수 있는 검증 시나리오입니다.
6. “더 예쁘게” 대신 입력과 합격 조건을 준다
바이브 코딩 대시보드를 고치려면 AI에게 분위기만 요구하지 말고 판단에 필요한 재료를 줘야 합니다. 아래 프롬프트는 고객지원 사례에 맞춰 쓴 작업 지시입니다. 특정 도구의 공식 명령어가 아니고, 일정한 결과를 보장하는 만능 프롬프트도 아닙니다. 실제 프로젝트의 데이터와 사용자 역할에 맞게 바꾸어야 합니다.
먼저 목적과 데이터를 이렇게 적습니다.
고객지원 팀장이 처리 순서를 결정하는 대시보드를 설계해줘. 첫 화면의 최우선 항목은 응답 목표를 넘긴 문의이고, 해당 목록에서 담당자 배정으로 이어져야 해. 첫 응답 시간은 선택 기간의 중앙값이며 단위는 시간, 비교 대상은 같은 길이의 직전 기간이야. 증가하면 악화로 표시해. 실제 연결 전의 예시 데이터에는 가상 데이터라고 표시해.
설계 방법과 검증 조건도 구체적으로 붙입니다.
코드를 작성하기 전에 정보 우선순위, 지표 정의, 차트 선택 이유, 글자와 간격 규칙을 먼저 제안해줘. 로딩·빈 결과·권한 부족·요청 실패 화면도 포함해. 390px와 1440px 너비에서 긴 한국어 라벨과 표가 어떻게 표시되는지 점검하고, 실행해 확인한 항목과 아직 확인하지 못한 항목을 나눠 보고해줘.
390px와 1440px는 이 예시에서 선택한 점검 너비일 뿐, 모든 화면을 대표하는 표준도 충분조건도 아닙니다. 대상 기기에서 추가로 확인해야 합니다. 완성된 화면에서 실제 사용자가 목표 초과 문의를 찾고 담당자를 배정할 수 있는지 살펴보세요. 걸리는 시간과 실수는 직접 관찰해 기록해야 하며, AI가 그럴듯한 개선율을 대신 만들어서는 안 됩니다.
고칠 순서는 색상이 아니라 질문에서 시작합니다. 사용자의 결정 → 지표의 정의 → 정보의 우선순위 → 시각 규칙 → 예외 상태 → 실제 사용 검증 순으로 확인하세요. 그림자를 더 넣기 전에, 실제 사용자가 첫 화면에서 무엇을 판단하고 어디를 눌러야 하는지 말할 수 있는 대시보드인지부터 확인하는 편이 낫습니다.
답글 남기기