작동하는 가이드 검수 도구 만들기 - 문제정의 편
유연한 협업을 위한 프로덕트 디자이너의 바이브 코딩 기록 (1)
이번 편에서는 협업 도구를 만들게 된 배경에 대한 기록입니다. 앞단의 문제 정의를 먼저 다루려고 합니다.
콘텐츠 운영을 위해 이미지, 텍스트 가이드를 만들고 배포했지만
제대로 반영되지 않아요.
아마도 서비스를 운영하면서 공들여 만든 운영 가이드가 실제 서비스에서 제대로 반영되지 않거나, 반복적인 실수가 발생하는 경험을 해본 적이 있을 것이다. 콘텐츠를 만드는 팀이 분리되어 있다면 특히 더.
나 역시 그런 경험이 꽤 있는 편이다. 보통 이미 배포된 상태에서 발견하고, PO에게 전달하고, PO가 담당 팀에 수정 요청을 하고, 재업로드하는 과정을 거치곤 한다. 노션에 자세히 만들어둔 가이드가 있었는데도 말이다. 그때 가이드를 상세하게 잘 만드는 게 답이 아닐 수도 있겠다는 생각이 들었다. 담당 팀에서 읽어도 이해하기 어렵다면, 직접 테스트해 보면서 스스로 감을 익힐 수 있는 도구가 있어야 하는 게 아닐까?
그래서 이미지를 올리면 규격을 자동으로 체크해 주고, 실제 모바일 화면에서 어떻게 보이는지 미리 확인할 수 있는 웹 기반 검수 도구를 만들게 되었다.
오늘은 비디자이너 팀의 반복되는 실수를 해결하기 위해 디자이너가 어떻게 문제를 정의하고 직접 도구를 만들게 됐는지 공유하려 한다.
문제 정의 : 어떤 문제가 반복되고 있었나
배너, 증정품 등 운영 콘텐츠를 운영하는 팀은 디자이너가 없는 팀으로, 내부에서 작업 후 업로드하는 구조다. 그러다 보니 아래와 같은 위반 유형이 반복적으로 발생하게 되었다.
⛔️ 증정품 이미지 영역에서 발생한 문제 케이스
증정품 이미지 영역에서는 상품 이미지를 여백 없이 꽉 채워 넣거나, 영역 밖으로 잘려 보이는 경우
상품 이미지가 상하로 쏠린 채 적용된 경우
⛔️ 증정품 텍스트 영역에서 발생한 문제 케이스
타이틀 영역은 증정 상품명만 노출되어야 하는데 그 외 문구가 함께 기입되는 경우
카드 영역에서 타이틀은 1줄만 노출되는데 제일 중요한 증정 상품명이 뒤에 배치되어 말줄임표로 안 보이는 경우
⛔️ 콘텐츠 배너 썸네일 이미지에서 발생한 문제 케이스
이미지 배경에 화이트가 적용되어, 영역이 제대로 보이지 않는 경우
이미지는 가로형 기준으로 제작되어야 하고 좌우 크롭 영역이 준수되어야 하는데, 반영되지 않아 중요 오브젝트, 로고 등이 잘리는 경우
왜 반복됐을까
이유는 구조적인 문제였다.
첫째, 담당자가 계속 바뀐다. 업무 배치에 따라 담당자가 달라지다 보니 가이드 숙지가 어렵거나 지속되기 힘들고 가이드의 존재를 모르는 경우도 있었다.
둘째, 이해하기 어렵다. "640×640px", "2배수 작업", "안전 영역" 같은 표현은 디자인 비전문가에게 직관적이지 않다. 또 “권장 글자수 40자” 등의 텍스트 가이드에서 예시가 부족했기 때문에 실제 작업에서 어떻게 적용해야 하는지 판단이 서지 않는 경우가 많다.
셋째, 확인할 방법이 없다. 이미지를 만들고 나서 가이드에 맞게 작업됐는지 스스로 검증할 수단이 없다. 자신이 업로드한 배너가 기준에 맞는지 바로 알 수 없으니 같은 실수가 반복될 수밖에 없다.
정리하면 이렇다.
가이드가 있지만 → 존재를 모르거나, 읽지 않거나, 룰을 모두 숙지하기 어렵다
가이드를 읽었어도 → 규격·해상도 개념이 낯설어 판단이 어렵다
판단했어도 → 실제 서비스에서 어떻게 보이는지 확인할 방법이 없다
진짜 문제 : 피드백 루프가 없다는 것
문서로 된 가이드는 읽는 시점과 적용하는 시점이 분리되어 있다. 가이드를 읽고 기억에 의존해서 작업하는 구조가 익숙하지 않다면 이해도와 숙련도가 낮을수록 오류가 날 수밖에 없다.
작업자 입장에서는 피드백이 없으면 학습을 할 수가 없다. 이것은 담당자의 문제라기보다는 현재 프로세스 구조의 문제라고 생각했다. 그래서 지금 필요한 건 더 세세하고 구체적이게 잘 만든 가이드 문서가 아니라, 작업 시 바로 확인하고 피드백받을 수 있는 도구가 필요하다고 판단했다.
그래서 직접 만들기로 결정했다
협업 부서에 더 빠르게 도움을 줄 수 있는 방법을 찾다가, 최소 기능만 담은 버전을 직접 만들어 제공하기로 했다. 이미 플러그인을 만들어보았기 때문에 바로 시작하는 것이 어렵지 않았기 때문이다. 결과물은 Google AI Studio를 활용해 프롬프트로 코드를 생성하고, HTML 단일 파일로 배포하는 방식으로 정했다. 그리고 PRD 작성을 하기 위해 필요한 기능을 간단하게 나열하는 것부터 시작했다.
앞으로 이 시리즈에서 문제를 어떻게 정의하고, 어떤 과정으로 도구를 만들었는지 단계별로 기록할 예정입니다. 다음 편에서는 도구를 만들기 전에 어떻게 PRD를 작성했는지, 전체적인 과정을 다루려고 합니다.
