"데이터 없음과 필터링됨은 사용자에게 다른 메시지를 줘야 한다"
스키마와 백엔드 작업이 끝나고, 처음으로 실제 화면을 만드는 작업이었습니다. 화면 명세를 확인해보니 Pain Point Count와 Review Status 컬럼, AI Draft 버튼이 정의되어 있었는데, 이걸 뒷받침할 pain_points 테이블과 reviews 테이블은 각각 다른 Epic 소관이라 아직 존재하지 않았습니다.
이전 작업에서 Progress Engine이 미완성일 때 Placeholder Phase로 처리했던 선례를 그대로 따라, Pain Point Count와 Review Status는 "—" placeholder로 표시하고 AI Draft 버튼은 비활성 버튼조차 만들지 않고 아예 렌더링하지 않기로 했습니다. Step Count는 전체 STEP Node를 단일 쿼리로 가져온 뒤 JS에서 process별로 그룹핑하는 방식으로 구현해 N+1 쿼리를 피했습니다.
구현 결과를 리뷰하던 중, 검색이나 필터로 결과가 0건이 됐을 때도 "아직 프로세스가 없습니다"라는 문구가 그대로 뜨는 버그를 발견했습니다. 원본 데이터가 정말 없는 경우와, 데이터는 있지만 검색 조건에 걸려 안 보이는 경우가 하나의 조건문으로 뭉뚱그려져 있었습니다. 두 상태를 분리해 각각 "아직 없습니다"와 "검색 조건에 맞는 프로세스가 없습니다 + 필터 초기화 링크"로 나눠 표시하도록 수정했습니다.
252개 테스트가 통과하는 걸 확인한 뒤 커밋했습니다. 이번 작업으로 확인한 건, 데이터가 없는 것과 필터링돼서 안 보이는 것은 원인이 다르니 사용자에게 다른 메시지를 줘야 한다는, 단순하지만 자주 놓치는 원칙이었습니다.
존재하지 않는 데이터를 0이나 가짜 값으로 채우면 사용자에게 잘못된 정보를 주는 것이므로, "정직한 placeholder"가 "그럴듯한 가짜 값"보다 낫다는 원칙을 지켰습니다. Empty State 버그는 UI 상태가 하나의 조건에 두 가지 서로 다른 원인(데이터 없음 vs 필터링됨)을 뭉뚱그리면 안 된다는 일반적인 프론트엔드 원칙이 적용된 사례였습니다.
관련 프로젝트
프로젝트 개요 비즈니스 프로세스 트랜스포메이션(BPR)을 지원하는 한국어 기반 웹 애플리케이션. 컨설팅 프로젝트의 AS-IS 프로세스 분석부터 TO-BE 설계, Blueprint 승인까지의 전체 워크플로우를 디지털화하는 플랫폼으로, EPIC 단위로 구조화된 백로그를 기반으로 개발 중. 역할 및 워크플로우 PM / Architect / Reviewer 역할 수행 Codex(구현 담당)에게 Task 단위 구현 프롬프트 설계 Codex 구현 결과를 git log, git grep, git status로 직접 검증 후 승인 승인 전에는 Codex가 commit하지 않는 엄격한 게이팅 프로세스 운영 한 번에 하나의 Backlog Task만 진행, Task 완료 전 다음 Task 착수 금지 기술적 의사결정 및 성과 워크스페이스/프로젝트 접근 권한을 DB 레벨(복합 FK, SECURITY DEFINER 트리거)과 애플리케이션 레벨(Server Action 권한 검증)의 이중 방어 구조로 설계 Hard Delete 미구현 원칙 하에 배열 필드 전체교체(replace)를 단일 트랜잭션 RPC로 처리하는 패턴 확립 및 재사용 AS-IS 프로세스 그래프의 순환 참조 탐지에 Tarjan SCC 알고리즘 적용, 차단 오류(Error)와 경고(Warning)를 분리한 이중 Validator 아키텍처 설계 도메인 규칙 위반을 커스텀 Postgres 에러 코드 체계(SIA0104)로 문서화하여 거버넌스 문서와 코드베이스 간 정합성 유지 AI 생성 데이터와 사람이 검증한 데이터를 구분하는 generatedbyai / verified 메타데이터 패턴을 여러 도메인 테이블에 일관되게 적용 진행 상태 ✅ EPIC-01 (인증 / 워크스페이스 / 프로젝트 접근) ✅ EPIC-02 (조직 / 산업 / 프로젝트) 🚧 EPIC-03 (AS-IS 프로세스 그래프) — 그래프 검증, Input/Output 스키마, Business Rule 스키마 구현 완료