2.0 구축 프로젝트를 끝마치며

들어가며

첫 입사했을 때 내 상태

1년간의 공백을 깨고 22년 3월에 서비스 기획자로 직무 전환에 성공했다!

내가 속한 개발실은 약 25명 내외로 구성되어 있었다. 직속 상사는 CTO였고, 나와 디자이너 1명을 제외한 멤버가 모두 개발자였다. 개발실은 휘하에 모바일팀, 프론트팀, 백엔드팀 3개로 나뉘어 있었는데 조직 편의상 나는 모바일팀에 속해 있었으나, 웹과 앱, 모바일웹을 모두 담당하는 기획자로 일했다.

 

우리 개발실은 기존 서비스를 완전히 새로운 것으로 갈아 엎는 하나의 거대한 구축 프로젝트를 진행 중이었다. 서비스 업종은 유지하되 필요하다면 서비스명도 모두 변경할 수 있는 상황이었다. 지금은 프로젝트가 완료되었는데, 변경사항을 살펴보면 업종과 서비스명을 제외한 모든 부분이 바뀌었다.

 

3월부터 10월이라는 짧은 시간동안 대규모의 구축 프로젝트를 홀로 기획하면서 많은 것을 느꼈다. 조금 늦은 감이 있지만 느낀 것들을 정리해보았다.

---

목차

🙉 What I aimed for: 서비스 기획자로서 추구했던 가치

🙊 What I learned: 2.0 구축 프로젝트를 하며 배운 것

🙈 Restrospective: 더 베우고 싶은 것

---

🙉 What I aimed for: 서비스 기획자로서 추구했던 가치

1. 페이지 정의를 명확히 하기

가상화폐 거래소는 일반적인 서비스(커뮤니티, SNS 등)보다 기능적으로 더 복잡한 특징을 가지고 있습니다.

사용자들이 이해하기 어려운 요소가 많기 때문에, 나는 각 페이지마다 명확한 메시지를 전달하는 것에 집중했다. 각 페이지마다 사용자에게 요구하는 내용을 명확하게 정의함으로써, 사용자들이 거래소 이용에 필요한 다양한 요구사항을 수행할 수 있도록 도왔습니다.

 

2. 개발 실무자의 UX 규칙 Align

페이지 정의를 명확히 하고, 사용자에게 요청할 데이터를 명확히 하는 것 외에도, 나는 팀 내 구성원들이 나와 동일한 UX 규칙을 이해하도록 노력했습니다. 나 혼자 단독으로 기획자로서 업무를 수행하기 때문에 유사시를 대비하고, 개발자가 비슷한 UX 이해도를 통해 비슷한 결과물을 만들 수 있도록 했다. 이를 위해, 개발자 및 디자이너와 소통하여 공통된 UX 규칙을 정립하는데 힙썼다. 이를 통해 효율적이고 일관된 사용자 경험을 제공할 수 있었다.

 

🙊 What I learned: 2.0 구축 프로젝트를 하며 배운 것

1. 이미 서비스된 기능을 재구축하는 경우, 기능의 우선순위는 어떻게 정해야 하나?

일반적으로 처음 출시하는 서비스의 경우, 최소 기능 제품(MVP) 수준으로 출시하고, 이후에 이터레이션을 통해 업데이트를 진행한다. 하지만 내가 참여한 프로젝트는 기존에 이미 고도화된 서비스를 재구축하는 것이었기 때문에, 기능을 축소하기가 어려운 상황이었다.

 

기존에 제공되던 기능을 사용자에게 제공하지 않는 것은 꽤 부담스러운 일이었기 때문에, 가능한한 많은 기능을 포함하려 노력했고, 기능을 제외해야 할 경우에는 벤치마킹을 적극적으로 활용했다. 경쟁사가 제공하는 기능을 파악한 후, 공통적으로 필요한 기능은 최대한 우선순위에 포함시켰다.

 

하지만, 레거시 기능이라고 해도 해당 페이지의 의도와 부합하지 않을 경우에는 기능을 제외시켰다. 회사차원의 사용자 테스트는 아니지만 주변인들을 동원해 사용자 테스트를 거쳐서 해당 기능이 의미가 없거나, UX에 부합되지 않으면 과감히 삭제한 기능들도 존재한다. 또한, 경우에 따라 타사에서 해당 기능을 제공하는 곳이 없는 경우에도 기능을 제외하는 결정을 내렸다.

 

2. UX의 모듈화: UX의 MVP를 정한다면

기능 요구사항이 충분히 복잡했기 때문에 스스로"UX의 MVP"를 정하고 기획을 모듈화하는 노력을 했다.

기능의 복잡성뿐만 아니라 운영실이나 준법실에서 제시하는 요구사항도 함께 처리해야 했기 때문에  아무리 야근을 해도 나 혼자 모든 작업을 처리할 수 없는 상황이었다. 입사 1개월이 막 지난 시점에서 동료들이 나를 "공장장"이라고 부르기 시작했고, 개발일정을 확보하기 위해 주말에도 출근하기 시작했다.

 

이 문제를 해결하기 위해 먼저 기획자의 리소스는 많이 들지만, 추후 수정에 개발 리소스가 적게 드는 UX Writing의 MVP를 구상했다.

플레이스홀더, 레이블, 유효성 메시지 등과 관련된 간단한 규칙을 만들어 세부 기획이 없어도 개발자가 스스로 작업할 수 있게 했다. 예를 들면 플레이스홀더는 '{레이블명}을 입력해주세요.' 라는 식으로 정의했다. 간단한 규칙이었기 때문에 내가 놓친 부분이 있거나 급하게 추가된 필드가 있더라도 프론트나 모바일 개발자들이 알아서 문구를 작업할 수 있었다.

 

이런 방식이 좋은 방식인가에 대해서는 스스로 여전히 의문이 남아있다. 그러나 물리적인 시간적 한계나 Agile과 Waterfall이 혼재된 구조, 혹은 개발은 기능팀으로 진행되나 기획자의 리소스가 절대적으로 부족한 상황에서는, 각 기능을 담당하는 개발자들이 기획자가 모든 세부내용의 정리하지 않아도 어느정도는 스스로 작업할 수 있어 효율성을 확보할 수 있기에 긍정적으로 평가한다.

 

고도화되지 않은 사용자 경험은 추후 업데이트를 통해 보완할 계획을 세웠는데, 텍스트 수정이나 팝업 노출 정도로 개발 공수가 낮기 때문에 결국은 잘한 선택이었다고 생각한다.

 

🙈 Restrospective: 더 배우고 싶은 것

1. 상황을 핑계대지 말고 할 일에 최선을 다할 것

기능 기획을 시작할 때, 예외 케이스에 대한 합의가 충분하지 않아서 아쉬웠다.

프로젝트 진행 중 예외 상황이 발생하면서 팀 내에서 의사소통과 조율이 필요한 경우가 종종 있었다. 지금 생각해보니, 바쁜 상황이라 수동적으로 행동했던 것 같아 못내 아쉽다. 더욱 적극적으로 역할을 수행하여 합의를 도출하는데 도움이 되었으면 좋았을 것 같다.

 

2. 기회가 된다면 디테일한 백엔드 기획을 

2.0 구축 프로젝트를 진행하면서 백엔드 기획을 더 자세하게 해볼걸 하는 아쉬움이 있다.

이번 프로젝트에서는 주로 화면 구성과 어떤 기능이 포함될지를 기획하는 역할을 수행했지만, 각 기능의 백엔드 기획까지는 세부적으로 담당하지 못한 것이 아쉬웠다. 물론 연차에 비해 이를 모두 담당하는 것은 어려운 일이지만, 백엔드 기획이 결국 기능 로직을 기획하는 것과 일맥상통하다는 것을 알게 되어 더욱 심도 있게 참여하고 싶은 마음이 생겼다.

 

3. UI/UX 케이스를 아카이빙하기

업무를 하면서 UI/UX 케이스가 즉각적으로 떠오르지 않아서 많은 자괴감을 느꼈다. 그래서 다양한 UI/UX의 용어와 용례를 아카이빙하고, 필수 컴포넌트를 정리하는 작업을 시작하면 업무에 큰 도움이 될 것 같다.