창업자들의 고민: 민감한 데이터 노출 없이 제품 데모하는 법

• 스타트업 창업자라면 한 번쯤 겪는 문제임. 투자자나 잠재 고객 앞에서 제품을 시연해야 하는데, 화면에 실제 고객 이름이나 크레덴셜이 그대로 노출되는 상황. 특히 라이브 스크린 쉐어 중에 브라우저 탭에 박힌 인증 정보, 알림으로 뜨는 고객명, 사이드바의 민감 데이터 같은 것들이 문제가 됨

• HN에서 소개된 도구 중 눈에 띄는 건 Mockaton이라는 브라우저 확장임. API 응답을 전부 다운로드해서 목 서버를 띄울 수 있고, 프론트엔드 에셋을 컴파일해서 독립적인 데모 서버를 배포하는 것도 가능함. function mock(HTTP 핸들러)도 지원하고, 코멘트 태그로 목 데이터를 묶어서 한 번에 전환하는 기능도 있음

• 목 API만으로는 부족한 경우가 많음. 프론트엔드 쪽 실전 팁으로는 이런 것들이 공유됨: 환경 변수로 base URL을 목 서버로 돌리기, JWT 쿠키를 Mockaton으로 주입해서 인증 우회하기, 그리고 useUser() 같은 커스텀 훅을 만들어서 AuthContext가 없으면 목 객체로 폴백하는 패턴. SKIP_AUTH 환경 변수로 AuthProvider 자체를 바이패스하는 방법도 제안됨

• 데이터 제너레이터 접근법도 흥미로웠음. 애플리케이션 코드와는 완전히 분리되어 있고, DB만 건드리기 때문에 워크플로우 오버헤드가 거의 없었다는 경험담임. 다만 "데이터를 생성하는 것 자체"는 단순한데, "어떤 데이터를 어떤 패턴으로 생성할지 정의하는 것"이 훨씬 어려웠다고 함. 환자 프로필, 처방전, 예약 같은 엔티티 간 관계를 현실적으로 만드는 게 핵심 난제였음. 개발팀과 QA는 대량 데이터를 생성해서 쓰고, 세일즈팀은 별도의 소규모 DB에 잘 정제된 데이터를 큐레이팅해서 데모용으로 사용함

• 한편으로는 이런 접근이 한계에 부딪힌다는 반론도 있었음. 기술적 배경이 있는 투자자는 "1만 건 레코드 처리 보여달라", "실제 부하에서 에러 핸들링이 어떻게 되냐" 같은 엣지 케이스를 물어봄. 가짜 환경에서는 이런 복잡성을 재현하기 어렵고, 매일 쓰는 진짜 환경이 아니다 보니 머슬 메모리도 안 먹혀서 클릭을 잘못하거나 머뭇거리게 됨. 투자자들은 이런 걸 눈치챈다고 함

• 이에 대한 현실적인 카운터로는, 실제 고객 데이터를 익명화해서 가짜 고객 밑에 넣는 방법이 제안됨. 대량 데이터 시연이 필요하면 이게 가장 현실감 있음. 에러 핸들링 시연은 솔직히 실제 환경에서도 의도적으로 버그를 만들어야 보여줄 수 있는 거라, 구두로 설명하는 게 오히려 낫다는 의견이 설득력 있었음

HN 토론 원문