서비스 기획자가 몰라도 되는 것들
기획에 가장 중요한 것은 본질이기에
서비스 기획 지망생이나, 사수 없는 주니어 기획자들은 종종 서비스 기획자의 역량이 무엇인지 헷갈릴 때가 있습니다. 제가 딱 그랬거든요. 특히 이런 일 저런 일 가리지 않고 하는 작은 회사에 있다 보면, 나 자신이 서비스 기획자로서 어떤 역할을 하고 있는지 깊은 고민에 빠지게 됩니다. 최근에도 서비스 기획 지망자들에게서 종종 듣는 질문이 있습니다. "쿼리를 할 줄 알아야 하나요?", "디자인 감각이 있어야 하나요?" 등등입니다. 이번 글에서는 그때마다 제가 했던 답변과 서비스 기획에 필요한 것에 관해 이야기해 보고자 합니다.
1. 서비스 기회자는 쿼리를 다룰 줄 알아야 하나요?
결론부터 말하자면 아닙니다. 그러나 알아두면 좋습니다. 하지만 그 본질은 쿼리문을 작성하는 법이 아니라, DB의 구조를 이해하는 것이어야 합니다. 작금의 서비스는 거의 대부분 RDB 혹은 NoSQL로 이루어져 있다고 해도 과언이 아닙니다.
DB의 생김새 자체는 엑셀을 사용해 본 적 있다면 이해하기 쉽습니다. 열과 행으로 구성된 하나의 뭉치를 'Table'이라고 하는 데요. 이 뭉치의 정보들이 서로 얽히고설켜 있는 것이 DB입니다. 만약 각 데이터에 부여된 'Foreign key'를 통해 직접적인 Table 간 관계가 형성된다면 'RDB'이고, 그 외에 여러 가지 방법으로 관계를 맺는다면 'NoSQL'이 됩니다.
'Table'이 서로 연결되는 이유는 이렇습니다. '사용자 정보를 위한 Table', '상품주문을 위한 Table'이 있다고, 생각해 보겠습니다. 회원가입에는 사용자의 ID, Password 등 다양한 사용자 정보가 담겨있습니다. 상품 주문에는 상품정보 외에도 물건을 구매할 사용자의 정보가 필요하기에 이런 정보를 가져와서 사용해야겠지요.
SQL은 이런 데이터구조를 설계하기 위한 언어입니다. 이런저런 언어들이 있는데 비개발자들은 대충 '쿼리'라고 부릅니다. 또, 실제로는 DB를 설계하기 위해 사용되지만, 비개발자들은 보통 데이터 탐색을 위해 사용합니다. 사실 DB는 서비스의 성능 (속도와 안정성)에 매우 직접적인 영향을 줍니다. 비개발자가 어설프게 건드릴 영역이 아니죠. 설계에 많은 공을 들여야 하고, 조금만 변경되어도 서비스에 치명적인 영향을 줄 수 있기에 DBA직무엔 보수적인 분이 많습니다. 그래서 저는 농담 삼아 성격 좋은 DBA를 만나본 적이 없다고 말하곤 합니다.
결론을 정리해 보겠습니다. 결론적으로는 쿼리를 다루지 않아도 됩니다. DB를 제대로 이해할 수도 없습니다. 만약 제대로 다룰 수 있다고 하더라도, 지속적으로 유지보수에 관여할 것이 아니라면 손대서는 안 됩니다. 하지만 DB에 대해서는 어느 정도 이해하고 있어야 합니다. 위에 적은 내용들은 인터넷에 찾아보면 보다 자세하게 설명되어 있으니 일단은 그 정도로 시작해 보는 게 좋을 것 같습니다.
또 위에서 비개발자는 데이터 탐색을 위해 쿼리를 사용한다고 했는데요. 어느 정도 알아두면 좋습니다. 특히 요즘은 ChatGPT가 쿼리문을 워낙 잘 알려주기 때문에 쿼리문을 조금이라도 이해하고 있다면, 유용하게 사용하실 수 있을 거예요.
이 정도면 "다룰 줄 알아야 하는 거 아닌가?!"라고 물으실 수 있지만 사실 몰라도 지장은 없습니다. 서비스 기획의 본질은 DB가 아니니까요.
2. 서비스 기획자는 개발을 어느 정도 할 줄 알아야 하나요?
결론부터 말하자면 아닙니다. 몰라도 됩니다. 위의 DB도 그렇지만 개발 또한 호락호락한 영역이 아닙니다. 게다가 서비스 기획자한테 필요한 개발적 역량을 굳이 하나 뽑으라면 'DevOps'인데요. 적어도 5년 차 이상의, 그것도 Full-stack을 지향하며 커리어를 쌓아온 개발자들이 겨우 해낼 수 있는 스킬입니다.
보통은 그 이상의 시니어 개발자들이 많이 담당하죠. 이 정도 수준의 개발 능력이 아니라면, 서비스 기획자에 큰 도움이 되지 않습니다. 하지만, 서비스 기획자도, DevOps 담당자도 각자 할 일이 있기에, 둘 다 할 줄 알아도, 둘 중 하나만 하게 될 것입니다. (창업이나 극초반 스타트업이 아니라면요.)
말은 이렇게 했지만, 개발에 필요한 용어나, 트렌드는 알고 있으면 좋습니다. 우선은 말이 통해야 하니까요. 근데 그것보다 더 중요한 것이 있습니다. 바로 "논리적 사고"입니다. 개발자는 단순히 개발 언어를 다루는 사람이 아닙니다. 언어만 다루면 '코더'나 '스크립터'라고 불러야겠지요. (한글로는 뭐라고 할지…) 모든 개발은 논리적인 설계를 바탕으로 시작됩니다. 서비스 기획 또한 논리적이어야 하는데, 그 방식은 개발자의 논리적 설계와 크게 다르지 않습니다.
서비스 기획자는 "왜 이렇게 구현되어야 하는지" 논리적으로 설명할 수 있어야 하고, "어떻게" 구현되면 좋을지 조사하고 제안할 수 있어야 합니다. 이때 개발자와 구현 방법과 방향에 대해 매우 깊은 이야기를 나누게 될 것입니다. 좋은 서비스를 만들려면, "논리"를 기반으로 한 의사소통이 반드시 필요합니다.
다시 정리하자면, 개발은 전혀 몰라도 되지만 개발자와 논리적으로 커뮤니케이션할 수 있어야 합니다. 이 부분이 서비스 기획자에게는 어설프게 개발 용어나 트렌드를 알고 있는 것보다 더 중요합니다.
3. 서비스 기획자는 디자인을 할 줄 알아야 하나요?
이 질문 역시 결론부터 말하자면 아닙니다. 오히려 서비스 기획자가 '디자인'에 욕심을 내는 순간 서비스는 산으로 가기 쉽습니다. 디자이너로 시작해서 서비스 기획자가 되는 케이스는 주변에서 어느 정도 찾아볼 수 있습니다. 왜냐면 서비스 기획이라는 업무 자체가 신입으로 시작하기에는 쉽지 않기 때문이죠. 그런데 이런 경우라면 특히 염두해야 하는 점은 "디자인에 욕심 내지 말기"입니다.
그 이유는 디자이너에 대한 '월권' 문제 때문입니다. 사실 이 문제는 모든 업무와 해당 직군 (예: 쿼리-DBA, 개발-개발자)와도 발생할 수 있는 문제인데요. 디자인을 경험해 본 분들을 아시겠지만, 넌지시 아는 척하기 가장 좋은 분야가 디자인입니다. 오죽하면 최종의 최종의 최종의 최종본 같은 유행어가 만들어졌을까요? 디자인을 해봤다거나, 할 줄 안다는 이유로 간섭하는 일은 당연하게도 서비스에 좋지 않은 영향을 줍니다. 만약 디자이너의 역량 자체에 문제가 있다면 다른 방법으로 해결해야겠죠.
그리고 제가 정말 하고 싶었던 이야기는 "집착"에 관한 이야기입니다. 디자이너는 본질적으로 시각적 표현에 집착해야 하는 직군입니다. 미세한 색의 변화나 1px, 2px 같은 미묘한 차이에 예민하게 반응합니다. 툭툭 던지는 것처럼 보이는 결과물이라도, 나름의 조형성을 염두한 '툭툭'입니다. 사실 이건 다른 직군이 100% 이해하기에 어려운 영역이지만, 디자이너에겐 필수 소양입니다. 작은 결과물 하나라도 장인 정신을 갖고 덤벼들어야 하는 순간이 반드시 한 두 번은 필요합니다.
그래서 서비스 기획자는 디자인을 할 줄 안다고 하더라도 절대 집착해서는 안됩니다. 서비스 기획자는 큰 흐름과 줄기를 보는 사람이어야 하고, 미시적 눈이 필요한 시점에는 그에 상응하는 이유가 있어야 합니다. 1px에 집착할게 아니라 사용자의 반응 하나에 더 집착하고, 설계 오류, 데이터 누수를 찾기 위해 집착해야 합니다.
정리하면, "디자인을 할 줄 알아서 나쁠 거 없지만 굳이 알 필요는 없으며, 디자인에 집착해서는 안 된다." 정도입니다.
서비스 기획자로 거듭나려면
그렇다면 반대로 서비스 기획자가 갖춰야 할 역량은 무엇일까요? 첫 번째 힌트들은 1~3번의 끝 부분에 남겨두었습니다. 두 번째는 정성/정량을 오가는 현황 파악 능력입니다. 간혹 서비스 기획자가 데이터를 이해해야 하냐고 묻기도 하는데, 이건 잘못된 질문입니다. 구체적으로 어떤 데이터를 어떻게 다룰 줄 아느냐고 물어봐야 하는 게 맞습니다.
세 번째는 서비스 전체를 파악하고 이끌어나갈 수 있는 안목입니다. 여기에는 프로젝트 동료와의 커뮤니케이션 능력 등이 포함되어 있습니다. 더 자세한 내용은 이 글을 참고해 주시면 좋을 것 같습니다.
그 외에도 "서비스 기획자는 브랜딩을 할 줄 알아야 하나요?", "서비스 기획자는 UX 리서치를 할 줄 알아야 하나요?"와 같은 질문을 들어본 적도 있습니다. 브랜딩은 사실 완전히 별개의 영역입니다. 누구나 할 수 있을 것이라고 생각하지만 전혀 그렇지 않은 일입니다. UX 리서치는 1~100중에 60 이상의 전문성은 갖추고 있어야 한다고 생각합니다. 짧게 할 만한 이야기는 아닌 것 같아 나중에 다뤄보겠습니다.
또한 서비스 기획자가 실체로 갖춰야 할 역량은 연차(주니어~시니어, 팀장) 혹은 역할(기획, PM, PO)에 따라 조금씩 달라질 수 있습니다. 이번 글에서 다룬 내용은 어디까지나 저의 경험을 바탕으로 쓴 것이니 참고해 주시면 좋겠고, 서비스 기획자를 꿈꾸는 분들에게 작은 도움이 되길 바랍니다.
<원문>
©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.
