모바일 앱을 만든 뒤 마지막 UI 리뷰에서 일이 갑자기 흩어지는 장면을 또 봤다. ProductManagement 커뮤니티에 올라온 질문도 비슷했는데, TestFlight나 스테이징 빌드를 보면서 디자이너와 QA가 Jira 티켓, 스크린샷, Slack 스레드, Figma 코멘트에 피드백을 수십 개씩 남기고 있었다. 한 댓글은 개발 후 디자이너가 QA 전에 Design QA를 맡고, 스토리를 block 처리하거나 QA 채널에 남긴다고 했고, 다른 댓글은 요구사항과 테스트 케이스, 결함 티켓을 한곳에서 추적해야 한다고 했다. 문제는 모두가 게으른 게 아니라, 화면 하나를 고치는 데 필요한 증거가 네다섯 군데로 갈라진다는 점 같다. “이 간격은 의도된 건가?”, “디자인 파일의 어느 프레임 기준인가?”, “이미 고친 버그인가?” 같은 확인이 빌드 대기 시간과 합쳐지면 작은 버튼 하나도 하루짜리 왕복이 된다. 그래서 팀들은 더 긴 체크리스트, 더 많은 캡처, 더 빡빡한 QA 채널로 버티는데, 결국 기억력 좋은 사람에게 맥락이 몰린다. 작게 만들 수 있는 제품은 거창한 디자인 시스템이 아니라, 모바일 빌드 위에 바로 핀을 꽂고 Figma 프레임·Jira 스토리·테스트 케이스를 자동으로 묶어주는 리뷰 레이어일 것 같다. 댓글이 많다는 건 불평이 아니라 반복 신호다. 매번 사람이 “어디에 적어야 하지?”를 판단하고 있다면, 그 판단 자체가 제품화될 여지가 있다.