기능 수정하다 개발자 반응 보고 UI 전면 개편했던 이야기

부트캠프의 두 번째 팀 프로젝트로 MVP를 제작하던 때였다. 우리는 부모님을 동반한 외식 후기 커뮤니티를 만들고 있었고, 당시 팀에서 Framer 숙련도가 가장 높고 CMS 구조를 유일하게 이해하고 있던 내가 디자인과 개발을 함께 맡고 있었다.

서비스 기획상 각 장소의 외식 후기는 하나의 코스에 묶일 수 있었고, 메인 피드에서는 개별 장소에 대한 후기가 아닌 코스를 보여주고자 했다. 다만 콜드 스타트 문제를 우려해 코스 전체에 대한 별도의 후기는 받지 않았다. 장소가 하나뿐이어도 하나의 코스 후기로 구성했다. 즉, 하나의 코스 후기는 [코스 제목](필수), [장소 방문 후기 A](필수), [장소 방문 후기 B](선택)의 구조였다.

짧은 시간 안에 구현하는 것이 최우선이었기 때문에 정돈된 와이어프레임을 먼저 만들기보다 Framer에서 디자인과 개발을 동시에 진행했다. DB 관계를 복잡하게 만드는 요소가 많았고, 국비 과정의 제약으로 Framer를 반드시 사용해야 했다. 우리 기획상, PM 지망생으로 구성된 팀치고 기술 구현 난도가 높았으며, 디자인보다 먼저 “이 구조가 실제로 구현 가능한가”를 확인해야 하는 역순의 작업이 반복됐다.

Framer CMS의 제약

가장 큰 문제는 키워드였다. Framer CMS에서는 양방향 관계형 DB를 구축할 수 없었고, 여러 단계의 참조도 지원되지 않았다.

이로 인해 두 가지 문제가 발생했다. 첫째, 키워드를 메인 피드에 구현하기 어려웠다. 키워드는 장소 방문 후기에 속했지만, 해당 키워드가 어떤 장소에 대한 것인지 보여주려면 장소 후기 → 장소 관계를 한 번 더 경유해야 했다. 둘째, 코스에 포함된 장소 목록을 보여주는 것도 어려웠다. 코스 후기 → 장소 후기 → 장소로 이어지는 3단계 구조였기 때문이다.

해결 방법을 찾기 위해 개발 튜터님께 도움을 요청했다. 당시 메인 피드의 코스 후기 카드는 코스 제목 아래에 장소 정보와 각 장소의 방문 후기 미리보기가 반복되는 구조였다.

장소 정보와 방문후기 반복으로 카드가 분절되어 보임

개발자가 오해한 화면

튜터님은 “Framer 권한만 달라”고 하셨고, 나는 권한을 넘긴 뒤 작업 과정을 지켜봤다. 그런데 수정 중인 화면을 보니 문제가 있어 보였다. 튜터님은 내가 구현한 코스 후기 → 방문 후기 → 장소의 계층을 풀어버린 채 작업하고 있었고, 그 결과 코스 제목과 장소 후기가 서로 무관한 요소처럼 정렬되고 있었다.

튜터님께 여쭤보자 문제가 명확해졌다. UI가 직관적이지 않았던 것이다.

튜터님은 해당 카드를 하나의 코스 후기가 아니라, ‘게시글 하나와 후기 여러 개가 나란히 놓인 묶음’으로 이해하고 있었다. 원래는 하나의 연속된 이야기로 읽혀야 할 코스 후기가 화면에서는 서로 분리된 정보처럼 보이고 있었다.

좌: 의도한 구조 / 우: 실제로 읽힌 구조

애초 장소별 후기를 모두 노출한 이유

기존 레이아웃을 그렇게 설계한 데에는 이유가 있었다. 입력 부담을 줄이기 위해 코스 전체에 대한 후기 내용을 별도로 받지 않았기 때문에, 후기 미리보기는 각 장소 단위로 노출되어야 한다고 판단했다.

식당 A에는 불만족했지만 이후 방문한 카페 B에는 만족했다고 가정해보자. 이때 어느 한 장소의 후기만 보여주면 해당 내용이 코스에 포함된 다른 장소에 대한 첫인상까지 왜곡할 수 있었다. 장소별 평가가 다른 경우에도 각 장소의 후기를 공평하게 보여주고 싶었다.

그러나 이 구조는 정보의 정확성을 지키는 대신, 코스 전체를 하나의 이야기로 이해하기 어렵게 만들었다.

정교한 구조보다 수요 검증이 먼저였다

고민이 시작됐다. Framer가 아닌 다른 도구를 사용할 수 있거나, 디자인을 고도화할 시간이 충분했다면 구조를 더 정교하게 해결할 수 있었을 것이다. 코스 전체에 대한 후기 입력을 새로 요구할지 다시 검토할 수도 있었다.

하지만 일정상 즉시 수정해야 했고, 리소스도 한정되어 있었다. 그래서 다시 이 MVP를 만드는 목적부터 되짚었다.

우리가 확인하고자 했던 것은 부모님과의 외출을 준비하는 사람이 부모 동반 외출에 특화된 커뮤니티를 탐색하고, 그 안에서 직접 글을 작성할 의향이 있는가였다. 그렇다면 제1목표는 완벽한 정보 구조를 구현하는 것이 아니라, 해당 수요를 검증할 수 있을 만큼 서비스의 가치를 명확하게 보여주는 것이었다.

이 단계의 커뮤니티에 엄밀한 계층 구조가 반드시 필요할까. 먼저 글을 읽고 쓰게 만드는 것이 더 중요하지 않을까. 세부적인 오해 가능성은 실제 수요를 확인한 뒤 수정해도 되지 않을까.

이 질문을 기준으로 UI를 전면 개편했다.

장소별 카드에서 하나의 코스 이야기로

먼저 드롭 섀도가 적용된 하나의 카드가 코스 후기 전체를 감싸도록 해 시각적인 구분감을 만들었다. 이어 장소별 방문 후기 미리보기 영역을 삭제했다. 대신 첫 번째 장소의 방문 후기를 코스 후기의 첫 문단처럼 전면에 배치해, 전체 내용이 하나의 연속된 코스 방문기로 읽히도록 구조를 재설계했다.

첫 장소 후기를 카드 전면에 올리고, 카드가 코스 후기를 감싸도록 재설계

첫 번째 장소의 후기가 다른 장소에 대한 인상을 일부 왜곡할 가능성은 남아 있었다. 그러나 이 단계에서는 장소별 평가를 완벽하게 전달하는 것보다, 유저가 화면의 구조를 즉시 이해하고 코스 후기라는 콘텐츠를 탐색할 수 있게 만드는 것이 더 중요하다고 판단했다.

MVP의 목적은 수요 검증이었기 때문에 화면 이해도를 최우선 기준으로 삼았다.

목표치를 넘긴 수요, 발견되지 않은 기능 오해

개편된 UI로 MVP 검증을 무사히 진행했고, 목표치를 웃도는 수요를 확인했다. UT에서도 메인 피드의 기능이나 콘텐츠 구조를 잘못 이해하는 문제는 발견되지 않았다. 오히려 키워드와 검색 기능을 더 고도화해달라는 추가 수요를 확인할 수 있었다.

기존 피드 카드 UI를 고집했다면 어땠을까. Framer의 계층 구조와 CMS를 직접 들여다볼 수 있었던 개발자조차 화면을 잘못 이해했다. 그 상태로 일반 유저에게 수요 검증을 진행했다면, 서비스 자체에 대한 반응과 UI 오해로 인한 반응을 구분하기 어려웠을 것이다.

완벽한 구조보다 검증 가능한 완성을

이 프로젝트를 통해 확인한 것은 제품을 만들 때 본래의 목적을 놓쳐서는 안 된다는 점이었다. 목적이 수요 검증이라면, 일부 아쉬움이 남더라도 최소한 검증이 가능한 형태로 완성해야 한다.

개발 튜터님이 해주셨던 말처럼, ‘완벽한 미완성’보다 ‘불완전한 완성’이 훨씬 낫다. 리소스가 부족한 상황에서 모든 의사결정을 반복해서 검토하면 일정만 지연될 수 있다. 그럴수록 무엇을 검증하려는지 다시 확인하고, 해당 목적을 달성할 수 있는 수준에서 구조를 단순화해 완결을 내야 한다.