제로베이스 PM 스쿨 마무리했고, SI 기업에 서비스 기획자로 취업했다!

아무래도, 서비스 기획은 기획자 혼자가 아닌 디자이너와 개발자들과 함께 일하는 직무입니다. 특히, 기획자 입장에서 '개발자'들은 바늘과 실처럼 마음까진 아니더라도 '업무' 상 통해야만 하죠.

최근에는 제플린, 인비젼 등 다양한 툴들이 제공되는 이유도 개발자가 쓰는 언어와 기획자가 쓰는 언어가 다르기 때문이죠. 

https://yozm.wishket.com/magazine/detail/1169/

디자이너와 개발자가 효율적으로 소통하기 위한 툴은? | 요즘IT

게다가 이제는 'CSS'를 사용하지 않고도 바로 애니메이션을 적용할 수 있는 프린시플 까지 나왔습니다.

프린서플 > 애니메이션 만들기

그럼에도, 여전히 개발자들과 이야기할 때는 '개발 용어'가 필요합니다. 예를 들어보자면, 당신이 UI를 수정했을 때 그걸 프로그램이나 어플리케이션에 반영해야 합니다. 그럴 때마다 '아... 그... 누구지? 그 이XX 연구원 있잖아요. 그 왜 우리가 보는 화면 수정해주는 개발자...?'라고 할 수는 없죠.

 

그냥 단순하게 Front-End Developer 라고 하면 됩니다. 

 

DataBase와 API 로 이루어진 서버를 관리, 개발하는 개발자는? 바로 Back-End Developer 입니다. 

 

이제 여러분은 DataBase 즉, DB가 뭔지 궁금할 겁니다. 쉽게 말하면 Data의 모임입니다.

 

누군가 ID는 NNN32, 비밀번호 2039@@1로 신규 회원 가입을 한다면, 서버 DB에 NNN32, 2039@@1이 저장되는 거죠.

 

DB는 있다가 좀 더 다루기로 하고, 방금 나온 '서버'를 설명하고 싶은데요.

 

'서버'가 무슨 말인지 제대로 이해하려면 '클라이언트'와 같이 봐야 합니다. 

 

User는 데스크탑, 모바일, 태블릿, 노트북 등 다양한 기기를 통해 Internet에 접속하며 해당 인터넷에 client들이 보낸 요청은 인터넷을 통해 서버로 전달되는거죠. 즉, 사용자 혹은 사용자의 단말기를 Client로 볼 수 있습니다.

그럼 여러분이 서비스 기획자로서 FE 개발자에게 '~~ 데이터를 서버에 요청해주세요'라고 했을 때, FE 개발자 분들은 어떤 걸 쓰게 될까요? 서버와 통신 역시도 프로그래밍 언어를 사용하게 되는데, 이때 API가 등장하게 됩니다.

 

하지만 API를 설명하기 전에, 서비스 개발 프로세스를 먼저 보도록 하죠.

구조도는 이렇습니다만, 작은 업체 (SI, 스타트업) 등에서는 서비스 기획자가 UX/UI 디자인을 겸하는 경우도 있습니다. 프로덕트 디자이너 라고도 하죠.

 

그렇게 되면, 서비스기획-> GUI 디자인 시안 제작(Low fidelity - 손스케치 Middle Fidelity - 피그마로 와이어 프레임 제작 High Fidelity - UI 시안 제작 -> 프로토타입 - 인비젼 & 피그마 & 프레이머 X 를 통해 프로토타이핑) -> 제플린 이용 으로 모든 걸 하게 되죠. 사실상 웹퍼블리싱은 제플린이 있기에 굳이 따로 퍼블리셔를 두기 보다는 프론트엔드 개발자나 디자이너가 정리해도 될 거 같습니다.

 

이런 앞단의 과정이 끝나면, API를 통해 서버에 데이터를 요청하게 됩니다. 이때 API와 REST API가 등장하게 되는데, application programming interface 는 API(Application Programming Interface, 응용 프로그램 프로그래밍 인터페이스)는 응용 프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻한다. 주로 파일 제어, 창 제어, 화상 처리, 문자 제어 등을 위한 인터페이스를 제공한다.

 

라고 합니다. 무슨 말인지 모르겠죠?

하지만 카카오 간편 로그인 API를 보시면 이해가 쉬울 겁니다. 여러분이 리모컨에서 전원버튼을 누르면 꺼지고, 다시 누르면 커지는 것처럼 '카카오 서버'에 '간편로그인'을 요청하기 위해서 사용하는 인터페이스가 바로 카카오 로그인 API인 것이죠.

 

이때 REST API는 일종의 아키텍쳐 원칙 세트입니다. 여기서 REST는 Representational State Transfer로

1. HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고,
2. HTTP Method(POST, GET, PUT, DELETE)를 통해
3. 해당 자원(URI)에 대한 CRUD Operation을 적용하는 것을 의미합니다.

이제, 개발용어도 중요하지만 서비스 기획자로서 대규모 서비스 (토스, 카카오, 쿠팡 등등)에서 데이터를 얻기 위해 필요한 DB 관련 지식을 알아보겠습니다.

우선 Index는 키 값과 주소로 이루어진 데이터 구조로 인덱스를 통해 테이블 레코드에 빠르게 액세스할 수 있습니다.

보시면 테이블이 있죠? 아마 엑셀이 떠오르는 분도 계실겁니다. 테이블은 행과 열로 이루어진 데이터 집합을 의미합니다.

행은 데이터로 Tuple 또는 Record라고도 하죠.

열은 가장 작은 단위의 데이터를 뜻하며 Field 또는 속성이라고도 불립니다. 

Key는 식별자로서 데이터를 구분하는 것인데, '사람'으로 치면 이름, 생년월일, 주민등록번호 등 개개인을 구분하는 특정 정보를 'Key'로 부릅니다.

 

이러한 Key는 유일성과 최소성을 만족해야 하는데, 유일성은 '하나의 키'로 해당 키에 해당되는 특정 행을 바로 찾아낼 수 있어야 한다는 것이며 최소성은 해당 Key로 정보를 찾을 수 있다면 Key는 꼭 필요한 속성들로만 구성되어 있어야 한다는 거죠.

복잡하니까 좀 풀어보자면, '대학생'을 구분하는데는 '학번' '주민등록번호' 등을 Key로 쓸 수 있는데 (유일성) 둘 모두를 합친 정보보다는 Key는 학번이나 주민등록번호 둘 중 하나만 쓰면 되는거죠(최소성).

이런 데이터베이스는 일종의 '도면'인 블루프린트가 존재합니다. 어떤 데이터를 어떻게 쌓을 것이며 어떤 위치에 적재해야 하고 다른 테이블간의 관계는 어떠해야 한다는 걸 정의하는거죠.

예를들어 개념스키마에서 'STUDENT'는 NAME 정보를 CHAR(텍스트)로 10글자까지 입력 가능하며 YEAR, GRADE는 INT(정수)만 입력 가능하다는 걸 정의해놓았습니다.

 

이렇게 공부할 것도 많고, 힘든데 인터넷으로 찾기 보다는 시험을 준비해서 보는 것도 좋습니다. 물론 자격증이 취업에 유의미한 건 아니지만, 그래도 기획자나 데이터 관련 직종에서는 SQL을 이해하고 있는게 좋으니까요.

 

물론, 서비스 기획자로서 그리고 제로이베스 PM 스쿨에서 가르쳐주는 건 이렇게 '지식'을 학습하는 방법만은 아닙니다. 기획자라면 당연히 문서를 생산할 수 있어야 하고 트렌드에 밝아야 하기 때문이죠. 그러다보니 '아이데이션 스터디'로 참조할 만한 정보를 쌓아놓고 있죠.

 

이렇게 최근 3년간의 트렌드를 살펴보면서 제가 UX/UI를 디자인할 때 어떤 트렌드를 반영해야 하는지 파악하는 것도 중요하죠. UX/UI 의 10가지 심리학 법칙에 소개된 '제이콥의 법칙' 때문인데, 사용자는 다른 웹사이트를 통해 축적된 경험을 바탕으로 디자인 관례에 대한 기대치를 형성하는 경향을 보인다는 게 제이콥의 법칙입니다.

즉, 어디선가 갑자기 '툭' 떨어진 듯한 전혀 새로운 디자인 보다는 '이거 어디서 봤는데...?' 라는 디자인이 사용성 측면에서 오히려 좋다는 얘기로 이해했습니다. 심미성이나 독창성 같이 '예술적 가치' 보다는 어디까지나 사용자 가치가 비즈니에서는 당연히 우선시 되어야 합니다. 

그런 점에서 서비스 기획자 채용공고를 살펴볼 필요가 있죠. '의사소통 능력' 때문인데요. 여기서 말하는 의사소통을 단순히 '말 잘하고' '느낌 통하고' '같이 있으면 즐겁고' 라고 이해하지 않았습니다.

개발자들에게 UI 디자인의 폰트나 글씨 크기나 색을 '설명'할 필요 없이 제플린을 통해 전달함으로써 바로 CSS 코드를 확인할 수 있도록 하는게 '의사소통' 인거죠.

 

기획자는 말을 앞세우는 자리가 아니라 문서와 데이터로 주장에 따른 근거를 뒷받침하며 모두가 '같은' 일을 '하나의 관점'에서 보게끔 하는 '책임은 있으나 권한은 없는 지휘자'니까요.

이건 카사 공식문서는 아니고 제가 해본 카사 IA 인데, 서비스 기획자가 이처럼 개발 초기 혹은 운영 시 이러한 Information Architecture를 만들고 수정 및 공유함으로써 개발자/디자이너 모두가 '같은 내용'을 알고 있도록 하는 게 중요합니다.

'야, 그거 뭐였지?'가 아니라 'PageID kasa-Product-001 있잖아, 해당 화면에 나오는 '거래가능한빌딩'을 다른 화면으로 옮기는 게 낫지 않을까?' 로 대화할 수 있는거죠.

더 유능한 기획자라면, 해당 대화를 하기 전에 데이터를 확보할 겁니다.

 

테스트를 하자는 주장에 대한 근거는 아까 언급했던 제이콥의 법칙 + 타 증권 거래 혹은 조각투자 플랫폼 UI 벤치마킹 or  CX (구글스토어, 원스토어 사용자 댓글에서 UI 변경 요청글) 등의 '데이터'를 정리함으로써 얻을 수 있겠죠. 

 

예를 들어 '거래가능한 빌딩'을 다른 화면으로 옮겨 보는거죠. 그리고 해당 거래가능한 빌딩 목록 화면으로 바로 갈 수 있도록 아래 Navigation Bar에 선택할 버튼을 만들어 두고요. 그리고 그걸 프로토 타입으로 만들어서 피실험자를 초청해서 직접 사용해보게 하는 테스트를 할 수 있겠죠.

 

해당 테스트에서 어느 정도 근거가 인정되면, A/B 테스트를 통해 사용자를 기존 버전/신규 버전으로 나뉘어 사용하게 함으로써 UI 변경이 '개선'이 될지 '개악'이 될지 테스트 해보는 것으로 발전시킬 수 있습니다.

 

이렇게 '유능한 서비스 기획자'는 아니지만 그걸 준비할 수 있게 해준 제로베이스에 감사드립니다. 생각해보면 온라인으로 강의 듣고 포폴반을 통과해서 포폴반에서 과제하는 과정들이 저에게 '네카라쿠배당토' 같은 거대 기업으로 가는 발판은 아니었습니다.

 

하지만 작은 SI 업체라도 저는 만족하거든요. 어떻게 취직해야 하는지 PM이 뭔지 전혀 몰랐던데다가, 같이 공부하시는 분들 중엔 카카오 현직자, 타 기업 PM 근무자, 산업디자인학과 졸업생 등 쟁쟁한 분들도 많았어서 제가 애초에 목표를 낮게 잡았던 것도 있습니다. 그래서 막판에는 제주도 여행도 가고 조금은 대충했던 감도 있어요.

 

하지만 분명한 건 저처럼 JS, CSS, HTML 공부를 따로 하지 말고 서비스 기획자에게 미쳐서 UX UI 공부도 같이 했더라면 분명히 결과가 달랐지 않았을까 싶습니다. 그리고, 스터디 과제에서 CASE 스터디 역시

 

처음부터 가고 싶은 분야 (금융)을 명확히 정했다면 해당 분야의 어플들을 중점적으로 봤어야죠. 그리고 개선 방안을 단순히 '사용자' 관점에서 중언부언 설명하는 건 잘못이었습니다.

 

서비스 기획자로서 PM 스쿨에서 배운대로 사용성 평가 기준, 10가지 심리학 법칙 등 업계에서 통용되는 기준으로 설명하는 게 필요했죠.

 

지금 생각해보면 조금은 아쉽지만, 전 SI 업체에서 2 ~ 3년간 경력을 쌓고 더 유망한 유니콘 스타트업이나 서비스 업체에 가보고 싶습니다. 그것도 힘들다면 창업을 하고 싶고요ㅎ 기대와 두려움 그리고 미래에 대한 목표가 생겼다는 점에서 제로베이스 PM을 듣게 되어서 정말 다행입니다. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

‘이 글은 소정의 대가를 받고 작성되었습니다'