지금 생각해 보면 이직을 하고 당황스러웠던 일 중 하나가 바로 서버개발자와 '직접' 커뮤니케이션하는 것이었다. 예전 회사에서는 거의 모든 개발에 관해 프론트개발자와 주로 소통했기 때문이다.
서버개발자와의 소통은 프론트개발자가 전담했는데, 프론트를 개발하면서 필요한 API를 정리하여 서버개발자에게 요청하면 서버개발자가 개발 후 프론트개발자에게 해당 내용을 전달하는 방식이었다.
어쩌다 이런 문화가 생겼는지 모르겠지만 아쉽게도 이 문화로 인해 나는 기획자로서 서버 개발을 위해 무엇을 기획 단계부터 고려해야 하는지, 서버개발자와 어떤 것들을 논의해야 하는지 알 수 있는 기회가 적었다.
다행히 이직 후에는 서버개발자와 긴밀한 소통이 필요했고 지금은 기획 단계부터 백앤드 개발 시 효율성을 고려하여 덜어낼 수 있는 것은 무엇인지 고민하며 기획을 하게 됐다.
그래서 혹시 과거의 나처럼 서버개발자와 직접 소통할 일이 적은 조직에서 근무했던 기획자 혹은 신입 기획자에게 도움이 되었으면 하는 마음으로 이 글을 적어본다.
(조직의 구성에 따라 '서버개발자'의 역할이 조금씩 다를 수 있습니다. 이 글에서 전제한 서버개발자의 역할은 근무했던 조직에서의 경험을 기반으로 정의하고 있습니다.)
서버개발자는 백앤드 시스템을 개발하고 관리하는 개발자이다. 특히 어플리케이션의 성능과 확장성에 있어 아주 중요한 역할을 한다.
이러한 서버개발자가 가장 중요하게 생각하는 것은 "어플리케이션의 성능 최적화"이다. 이를 위해 서버개발자는 어플리케이션의 프로세스와 데이터 처리에 관하여 '속도'와 '효율성'을 중요하게 여긴다. 또한 사용자의 확장까지 고려하여 사전에 코드와 데이터베이스의 최적화를 고려하며 시스템이 증가하는 사용자와의 교류에 대해 성능의 감소 없이 감당할 수 있도록 개발한다.
그래서 서버개발자는 기획자가 기획한 프로덕트가 성능을 최대로 발휘할 수 있도록 클라이언트에서 요청하는 형태의 데이터를 빠르고 효율적으로 처리(조회, 응답, 저장 등)할 수 있는 시스템을 개발한다.
신입 기획자의 경우, 기획 리뷰에서 개발자들로부터 질문을 많이 받으면 부담스러울 수 있다. 하지만 서버개발자가 질문을 하는 이유는 다음과 같다.
작업의 범위를 명확하게 하기 위해
'성능 최적화'를 고려하여 '속도와 효율성'을 높이기 위해
장기적인 관점에서 효율적으로 데이터를 처리할 수 있는 방식을 고민하기 위해
예를 들어보자. 온라인 영화 스트리밍 플랫폼에서 가장 많이 시청된 영화의 랭킹을 보여주려고 한다.
[초기 기획의 내용] (기회가 되면 가상으로 스토리보드를 추가해 보겠습니다.)
1. 랭킹
영화 카테고리 별로 주간 인기 영화의 랭킹 노출
카테고리 별 1위부터 100위까지 100개의 영화 노출
영화 카테고리는 총 10개
직전 랭킹과 비교하여 순위의 상승과 하강 표기
앱 화면에서는 전체 카테고리로 10개의 영화까지만 노출하고 '더 보기' 클릭 시 전체 순위 노출
타이틀 '인기 TOP100' (타이틀 문구 변동 없음)
2. 랭킹 산출 기준
일주일 간의 시청 수 합계를 기준으로 정렬
시청 수는 유니크하게 계산(사용자의 중복 및 재시청은 포함하지 않음)
3. 영화 콘텐츠 표기
영화의 정보는 타이틀/ 감독/ 배우(최대 3명까지) 표기
콘텐츠 내용은 화면 안에서 필요한 경우, 말 줄임 처리
노출 중인 영화 타이틀 클릭 시 상세페이지로 이동
4. 계약 만료 콘텐츠 처리 방식
비노출 시점: 계약만료 즉시 비노출
사용자 화면에서 업데이트되지 않은 경우, 해당 영화 클릭 시 팝업문구 노출
이렇게 랭킹의 기획 내용을 스토리보드와 함께 공유하면 서버개발자는 아래의 질문들을 할 수 있다.
[기획자가 예상해 본 서버개발자의 질문]
(물론 각 조건은 회사의 시스템마다 개발이 수월할 수도 있고 어려울 수도 있다.)
Q. 랭킹을 꼭 카테고리를 나눠 보여줘야 하나요?
Q. 주간 랭킹인 이유가 있나요? 차라리 일간 랭킹이 낫지 않나요?
Q. 변동폭이 크지 않으면 꼭 순위 변동을 표기해야 하나요?
Q. 꼭 계약만료 후 비노출 처리해야 하나요? 만료까지 남은 시점이 24시간 전인 경우에는 랭킹을 업데이트할 때 제외하면 안 되나요?
서버개발자가 '성능 최적화'를 위해 '속도와 효율성'을 중요하게 생각한다는 것을 이해하고 나면 서버개발자의 질문의 의도가 보일 것이다.
[기획자가 예상해 본 서버개발자의 질문, 해석해 보기]
(물론 각 조건은 회사의 시스템마다 개발이 수월할 수도 있고 어려울 수도 있다.)
데이터 저장, 갱신, 조회 등의 처리 시 과부하로 인해 느려지는 속도와 에러를 고려
Q. 랭킹을 꼭 카테고리를 나눠 보여줘야 하나요?
전체 대비 카테고리 값에 따라 데이터를 분류하여 산출할 때 과부하 고려
Q. 주간 랭킹인 이유가 있나요? 차라리 일간 랭킹이 낫지 않나요?
일간 데이터 대비 주간 데이터의 시청 데이터 양이 많아 저장 및 산출 시 과부하 고려
Q. 변동폭이 크지 않으면 꼭 순위 변동을 표기해야 하나요?
순위 변동 표기를 위해 비교 랭킹 데이터를 저장, 순위 변동 산출 시 과부하 고려
Q. 꼭 계약만료 후 비노출 처리해야 하나요? 만료까지 남은 시점이 24시간 전인 경우에는 랭킹을 업데이트할 때 제외하면 안 되나요?
콘텐츠 만료 시 비노출 해야 하는 영역이 많기 때문에 과부하를 고려하여 업데이트 시점에 대한 논의 필요
이처럼 서버개발자는 시스템이 과부하로 인해 속도가 느려지거나 불필요한 리소스가 발생하여 원활하지 않게 작동하는 것을 방지하기 위해 질문을 한다.
만약 조직의 시스템이 노후하거나 조금은 보수적인 성향의 서버개발자들이 많다면 기획의 많은 부분을 “과하다.”라고 느낄 수도 있다. 하지만 그것이 백앤드 시스템의 효율을 위해 덜어낼 수 있는 기획이 있다면 시스템의 성능을 높이려는 것이라는 걸 이해하게 된다면 ”그럼에도 그 기능과 프로세스가 필요한 이유“에 대해 서버개발자에게 설명하면 된다.
그래서 서버개발자에게 요청할 때 기획자가 고려해야 할 3가지는 다음과 같다.
저장: 데이터의 저장 및 처리에 있어 불필요한 요소는 없는지
갱신: 과도하게 잦은 갱신을 요구하는 데이터는 없는지
조회: 한 번에 데이터를 조회할 수 있도록 통합 가능한 부분이 있는지
이처럼 기획자가 프로덕트를 기획할 때 조직에서의 백앤드시스템의 특징을 고려하여 데이터의 저장, 갱신, 조회와 관련하여 불필요하게 시스템에 많은 요구를 하는 기획이 없는가를 먼저 살펴보고 그럼에도 필요한 기획이라면 이에 대한 근거를 준비하여 서버개발자와 소통해보자. 그러면 서버개발자는 해당 요소를 개발함에 있어 최선의 방식으로 효율을 찾아낼 것이다.