AI로 협업 검수 도구 만들기 - 구현 편(3)

유연한 협업을 위한 프로덕트 디자이너의 바이브 코딩 기록

이번 편에서는 실제 구현 과정에 대해 기록합니다. 1차 결과물부터 구조 개선, 최종 배포까지의 과정에 대한 내용이에요.

정리하자면

내가 풀고 싶었던 것은 반복되는 배너 가이드 위반 문제였다. 노션 가이드가 존재하지만 작업 후 실제 검수는 개인의 경험에 의존했다. 이런 문제를 해결하기 위해 담당자가 작업 시 또는 업로드 바로 직전에 피드백받을 수 있는 도구를 만들고 싶었다.

UI 라이브러리?

어떤 것을 선택할까

내부 협업 도구이긴 하지만 사용자가 있기 때문에 정돈된 UI를 제공하고 싶었다. 처음에는 빠르게 화면을 만들기 위해 라이브러리를 사용하는 것이 합리적이라고 생각했다.

그래서 디자인 시스템으로 Google의 Material Design 가이드라인을 따르는 MUI 라이브러리를 사용하려고 했다. 컴포넌트 일관성도 보장되고 어느 정도는 커스텀도 가능했기 때문이다. 그 외에도 shadcn, tailwind 등 적용할 수 있는 옵션을 좀 더 찾아보며 검토하는 시간을 가졌고, 결과적으로 라이브러리는 사용하지 않기로 했다.

이유는 간단하다. 이 프로젝트는 HTML 단일 파일로 GitHub Pages에 배포하는 간단한 구조였기 때문이다. 모두 React 기반이라 코드를 변환하는 별도의 과정이 필요했고 이를 도입하게 되면 배포 방식을 바꿔야 해서 복잡해졌기 때문에 실용적인 선택을 위해 순수 css로 적용하기로 했다. (추가로, 화면 구조가 단순하기 때문에 라이브러리를 도입할 만큼 재사용할 컴포넌트가 많지도 않았다.)

검토하며 정리해 본 각 라이브러리의 차이점

PRD 기반 프롬프트로

결과물 구현하기

작성한 PRD를 프롬프트로 변환하여 빠르게 결과물을 만들었다. 1차 결과물은 1단 레이아웃으로 스크롤해서 확인할 수 있는 구조였다.

이미지를 업로드하면 자동 검수 결과 노출되고

증정품의 경우 증정 소개 텍스트를 입력해 볼 수 있고

해상도 별로 결과물을 미리 볼 수 있고

수동 체크리스트를 보며 재검토하고

최종 결과를 확인하는 구조

기능은 대부분 의도한 대로 동작하긴 했지만 실제로 테스트해 보니 사용자 관점에서 흐름을 재구성하는 작업이 필요했다.

1️⃣ 작업 흐름에 맞춰 구조 재설계하기

가장 큰 문제는 작업의 흐름과 화면 구조가 일치하지 않는다는 점이었다.

1차 결과물의 UX 개선점

검수 도구를 사용하는 사용자의 실제 행동을 생각해 보면 이렇다. 이미지를 업로드하고 텍스트를 입력하면서 동시에 결과가 어떻게 보이는지 확인해야 한다. 미리보기를 통해 이미지와 텍스트를 서로 참조하면서 동시 진행해야 하는데 1차 결과물의 경우 위에서 작업하고 아래로 스크롤해서 결과를 확인하는 구조였기 때문에 적합하지 않았다.

매번 화면을 오가며 사용자가 무엇을 수정해야 하는지 다시 파악해야 하는 상황이 생길 가능성이 높았다. 물론 해당 프로젝트는 기능이 단순하기 때문에 UX에서 말하는 “맥락 전환 비용(context switching cost)”이 크지는 않겠지만, 그럼에도 사용 시 예측되는 불편한 점을 해결하고 싶었기 때문에 이를 위해 레이아웃을 2단 구조로 변경했다.

2️⃣ 기능 조정하기

1차 결과를 기반으로 반복 수정을 거치면서 기존에 정의했던 자동 검수와 수동 검수 기준도 수정을 했다. 진행하다 보니 배경 컬러의 경우 샘플링만 명확하게 정의한다면 자동으로 가이드 준수 여부를 확인할 수 있을 것 같았기 때문이다. AI와 반복 대화를 통해, 이미지 모서리 기준으로 오차 범위를 넣어 검증할 수 있는 가능한 범위까지 추가하는 것으로 진행했다.

진행하면서 얻은 인사이트나 과정 노션에 정리

솔루션 : 최종 결과물

최종 구현된 도구는 초반에 생각했던 것보다 조금 더 현실적인 도구에 가까워졌다고 생각한다. 먼저, 레이아웃의 경우에는 앞서 말했듯 "2단 구조"로 변경하여 사용자의 인풋(이미지 업로드, 텍스트 입력)과 결과가 동시에 함께 보일 수 있도록 개선했다.

좌측 패널 : 입력 영역으로 탭 전환, 이미지 업로드, 텍스트 입력을 할 수 있음

우측 결과 : 뷰포트 별 미리보기부터 검수 결과를 함께 배치하여 같은 화면에서 모아볼 수 있도록 구성

또 이미지 업로드 시 안전 가이드 영역을 함께 볼 수 있도록 하여 사용자가 제대로 이미지를 제작했는지 스스로 검토할 수 있도록 구성했다. 사용자는 이를 통해 무엇이 문제인지, 어디를 수정해야 하는지를 즉시 확인하며 체감할 수 있게 되었다.

이미지 카테고리에 따라 업로드했을 때 보여지는 미리보기

완성된 결과물은 GitHub Pages로 배포하여 협업 부서와 외부 외주 업체에서 활용할 수 있도록 공유했다. 이번 프로젝트는 HTML 단일 파일로도 충분히 해결 가능한 범위였기 때문에 단순하게 빠르게 만들고 배포할 수 있었던 것 같다.

불필요한 개발 환경 없이 빠르게 공유 가능한 형태로 설계

프로젝트를 진행하며 얻은

두 가지의 레슨런

이번 프로젝트는 이전처럼 완주 자체가 목표인 작업이 아니라 실제 필요에 의해 만든 작업이었다. 문제를 정의하고 사용자를 특정하고, 흐름을 설계하며 기준을 구체화해 나가는 여정은 오랜만에 “메이커로서의 감각”을 다시 끌어올렸던 경험이었다. 기능을 만드는 것이 아니라 문제를 다루는 방식 자체를 다시 점검하는 과정에 가까웠기 때문이다. 이 과정에서 얻은 두 가지 레슨은 다음과 같다.

문제의 원인을 “사람”이 아니라 “구조”에서 찾기

반복되는 문제를 보면 “왜 또 지켜지지 않았을까”라는 질문으로 이어지기 쉽다. 나 또한 처음에는 그랬었다. 하지만 이번 프로젝트의 문제는 개인의 실수라기보다는 구조의 결과가 문제였다고 생각한다.

가이드가 존재함에도 불구하고 오류가 반복되는 이유는 그 가이드가 작업 시점에서 판단 가능한 형태로 제공되지 않기 때문이다. 결국 문제를 해결하기 위해 필요한 것은 더 많은 가이드가 아니라 그 가이드를 언제 어떻게 사용할 수 있게 만들 것인가에 대한 설계였다.

아이디어와 실행 사이의 거리를 줄이는 능력

AI를 활용하기 전에는 어떤 아이디어가 떠올라도 그대로 휘발되는 경우들이 종종 있었지만 이제는 그 거리가 굉장히 짧아졌음을 체감했다. 내가 무엇을 만들고 싶은지 방향을 명확하게 정의할 수 있다면, 이제 더 이상 직무는 경계가 되지 않고 다음 단계로의 실행이 굉장히 가볍고 빨라진 것 같다.

프로젝트를 마무리하고 팀 내에서 짧은 공유 세션을 진행했다. 단순히 결과물을 보여주는 것이 아니라 어떤 문제를 어떻게 정의했고 어떤 기준으로 선택했는지 등 과정 중심으로 정리했다. 세션을 통해 “실행까지 연결하는 방식”에 대해 스스로 다시 정리하는 계기가 된 것 같아 의미있었다.

문제 정의와 본질에 집중하기 위해 고군분투했던 과정을 기록하며 회고합니다. 커리어 관련된 이야기를 하는 것을 좋아합니다. 커피챗은 언제나 환영이에요!