하나의 서비스를 처음부터 끝까지 만들어 본 경험의 가치.

3월부터 시작해서 달려온 고민의참견 서비스가 8월 9일 드디어 배포했다.

원래 1차 스프린트가 마무리되는 5월 말에 배포하는 것이 목표였다. 당시 PM이었던 창현이가 군대가기 전에 서비스 하나 만들어보고 배포한 다음 유저의 반응을 살펴보고 싶어서 시작한 프로젝트였다.

화면설계서가 쏘아올린 작은 공

1차 스프린트가 마무리될 때 솔직히 나는 프로덕트의 완성도에 만족하지 못했다. 😟

UAT(User Acceptance Test)를 하면 할수록 너무나 많은 오류들이 나왔고, 내가 디자인 한 화면의 구현도 마음에 들지 못했다.

*UAT : 소프트웨어 테스트의 마지막 단계로 개발된 소프트웨어가 실제 사용자가 원하는 업무를 제대로 처리할 수 있는지를 확인하는 단계

당시 우리는 슬렉에 인덱스 번호를 붙여가면서 오류가 발생하는 대로 QC사항을 작성해서 올렸는데, 이는 주먹구구식의 폐해였다.

하면 할수록 어느 로직까지 테스트했는지 구분되지 않았고, 개수는 계속 늘어난 채 정리되지 않았다.
무엇보다 기본적인 오류들 조차 해결되지 못한게 눈에 훤히 보였다. (회원가입부터 제대로 안되더라.)

"화면설계서를 다시 제작해야 한다. 처음부터 뜯어 고쳐야 한다."는 나의 설득으로 결국 배포를 미루게 되었다.

이미 지난 일이고 화면설계서 멀쩡히 잘 있는데 내가 왜 그런 생각을 했을까.

처음부터 단서는 존재했다. 분명 화면설계서의 설명을 읽으면서 디자인을 해야 하는데 어느 순간부터 읽을 필요성이 없다는 생각이 들었다.🥲

그렇다. 화면설계서의 내용이 충분히, 상세하게 기술되지 못했기 때문이었다.

• 액션 전-중-후 다양한 맥락을 고려하지 않은 단편적인 화면과 설명들

• 겉으로 보이지 않지만 다양한 오류 상황을 유발하는 유효성 요소들

• 제대로 정의되지 못한 컴포넌트 이름으로 인한 혼동...

"기초가 탄탄해야 무너지지 않는다."는 말이 괜히 있는게 아니다. 제대로 갖추어지지 못한 설계서는 개발자와 디자이너에게 쓸모없었다.

프로덕트의 전환점이 된 역할 조정

당시 창현이와 함께 기획을 맡고 있었던 지호의 생각이 궁금하여 따로 얘기하는 시간을 가졌다.

지호가 '서비스 기획에 자신이 없다'고 내게 얘기했다. 돌아보니 내가 의도치 않게 주눅들게 만든 거 같다. 종종 기획팀이 가져온 내용에 내가 날카로운 피드백과 동시에 더 나은 방향성을 제시하곤 했다.

여기서 나는 생각보다 좋은 기획력을 가지고 있다는 힌트를 얻었고, 그래서 내가 소신껏 '기획'을 맡겠다고 했다. 내 스스로 잘못된 부분을 충분히 개선할 수 있겠다는 자신감이 가득했다.

지호에게는 기획 대신에 브랜딩 디자이너를 부탁했다. 마침 고민의참견의 세계관이 필요했다.

학교에서 가까이 지내면서 지호가 '브랜딩'에 관심있다는 걸 알고 있었다. (브랜딩 관련 학회 프로젝트에 매진하는 모습을 한 두 번 본게 아니다.)
이왕이면 본인의 역량을 최대로 끌어올릴 수 있는 역할을 주고 싶었다.

디자이너의 첫 화면설계서 제작 일지

설계서 제작 초반부터 나는 '디자인 시스템 구축'에 신경썼다.

화면 설명에 액션에 따른 결과를 컴포넌트 이름을 사용해 표현한다면, 추후 설계서 내용을 읽으면서 컴포넌트로 화면을 구현할 개발자에게 편할 거 같았다.
(ex. 항목을 선택하면 dropdown menu가 닫히면서 select box 컴포넌트가 focus -> selected 로 상태 변화)

개인적으로 중복되는 컴포넌트 이름 짓기가 까다로웠는데, 화면설계서를 만들수록 같지만 쓰이는 상황이 다른 컴포넌트들이 생겨났다. 실제로 text field는 종류만 6개였다.

그래서 특별한 상황이 아닌 보편적으로 사용되는 컴포넌트에 Primary와 Secondary를 붙여서 짓고, 나머지는 쓰이는 특정 상황의 이름을 따서 지어서 구분했다. (ex. primary input, secondary input, post/title-text area-vote...)

그리고 '유효성 요소'들을 페이지마다 표로 리스트업 했다. '상황'에 따라 어떤 '문구'를 띄우고, 어떻게 처리할 것인지 '시나리오'를 작성했다.

글자수 제한, 특정 문자 사용 불가 등 기본적인 유효성 요소부터 빠짐없이 채워나갔다. 이때, 한 화면에 유효성 요소가 많아지면 어떤 상황을 우선적으로 처리할 것인지도 반드시 생각해봐야 한다. 동시다발적으로 노티주는 것은 불가능하니까

다음은 고민의참견 서비스의 실제 '글 작성' 화면이다. 투표 항목을 입력하는 상황에서 유효성 요소를 생각해 보자.

투표 항목은 기본적으로 2개 이상의 항목이 작성되어야 업로드가 가능하다. 그럼 유효성으로 '2개 이상의 항목이 작성되지 않을 경우'만 판단하면 될까?

• '2개 이상 입력했지만, 또 다른 항목에 텍스트가 아닌 이미지만 첨부되어 있는 경우'

• ‘2개 이상 입력했지만, 동일한 텍스트의 투표 항목이 존재하는 경우'

• '2개 이상 입력했지만, 게시글 제목이 최대 글자수 초과한 경우'

이렇게 한 화면에 담겨있는 컴포넌트 각각을 낱개로 보지 않고, 상호연관적으로 보고 판단하면 보다 양질의 유효성 요소를 발견할 수 있다. 이를 알고부터 더 다양한 맥락들을 고려할 수 있는 시각을 가지게 되었다.

그렇게 1차 스프린트때 생각한 문제점들을 모두 보완한, 새로운 고민의참견 화면설계서를 모두 완성했다 ! 🥰

화면설계서를 기반으로 개발자분들의 화면 구현이 마무리 될 즈음, UAT(User Acceptance Test) 리스트업을 시작했다.

화면설계서 각 페이지들에 기술된 액션들을 빠짐없이 적고, 테스트 시 어떠한 예상 결과가 나와야 할지 순서대로 적을 수 있도록 템플릿을 구성하였다. 전부 작성하고 나니 약 280 여개가 나왔다. 😱

UAT를 진행하면서 예상 결과와 다르게 나타나는 요소들만 순차적으로 QC 페이지로 이동시켰다. 수정된 요소는 재확인하여 해결 여부를 판단했다. '할 일 - 진행 중 - 완료' 로 확실히 구분된 덕분에 진행 상황을 한 눈에 확인할 수 있었다.

이렇게 발견한 QC 요소들을 모두 해결하고 나서…

드디어 고민의참견 v1.0.0 배포!!! 🎉🎉🎉

'내 고민을 올리고 남의 고민에 참견하는 것을 기반으로 한 스낵 컬처 투표 플랫폼'

뭐 대단한거 처럼 슬로건을 들고 나왔는데, 사실 그냥 커뮤니티이다. 글 올리고, 댓글도 달고, 투표도 할 수 있는.

어떻게 보면 참 별 거 아닌 서비스라고 볼 수 있다. 하지만 하나의 서비스를 처음부터 끝까지 만들어봤다는 경험은 대단히 소중하다.

그 과정에는 협업 능력이 절대적으로 필요하다. 서로 기분 나쁘지 않게끔 요구할 것이 있으면 정중히 요구하며 갈등 없이 마무리되는게 얼마나 힘든지 깨달았다.

이제 우리는 유저들을 받아들이고 지속적으로 기능 개선을 수행해야 한다.

지금은 기본적인 기능밖에 없지만, 앞으로 매일 매일 작게 변화할 고민의참견을 기대해주세요!

The End. 긴 글 읽어주셔서 감사합니다 🙇‍♂️

고민의참견 사용해보러 가기 ➡️

다음은 배포 이후 팀원들과 가진 회고에 대한 이야기를 적어보려고 한다!