"서비스기획자 어때? 좋아?"에 대한 8년 차의 생각
IT 서비스 기획 직무에 관한 생각
언제부터인가, IT 분야에서 '문과'도 할 수 있는 직무라 불리며 '서비스 기획' 직무가 많은 관심을 받았다. 그래서인지 주변 지인들로부터 종종 이런 질문을 받는다.
"서비스 기획자로 직무 전환하려고 하는데, 어때?"
"서비스 기획자 좋아?"
“나도 서비스 기획자나 할까?”
나의 답변이 긍정과 부정 중 어느 쪽에 가까웠는가 물어본다면 솔직하게 '부정'에 가까웠다.
그 이유는 직무를 이해하려면 해당 직무로 겪게 되는 '고충'에 대해서도 알고 접근해야 한다고 생각했기 때문이다. 물론 모든 직무가 그렇겠지만, '서비스 기획자'도 장점만 있는 직무는 아니기도 하니까.
그래서 오늘은 8년 차, 서비스 기획자가 느끼는 직무에 관한 생각을 글로 써보기로 한다.
(이 글을 읽기 전에 아래의 패러디 영상을 한 번도 본 적이 없다면 먼저 보고 오는 것을 추천합니다.)
[영상] IT기획자 되지 말아요. (Don’t be a lawyer 패러디)
서비스 기획자, 양면의 ‘주체성'
기획 직무들이 가지는 장점은 자신만의 인사이트가 담긴 해결 방법론을 제시할 수 있는 '주체성'에 있다고 생각한다. 내가 서비스 기획자가 된 이유는 바로 이 '주체성'이 매력적으로 느껴졌기 때문이다.
특히 IT플랫폼에서는 여러 기획 직무들 중에서도 플랫폼에 반영된 서비스 영역이 있어야 고객과의 접점이 생기기 때문에 서비스 영역을 개발할 수 있는 서비스 기획 직무가 가장 큰 의사결정력을 갖게 된다.
실제로 콘텐츠 기획 업무를 할 당시, 진행하고 싶은 프로젝트가 있어도 서비스 기획자를 통해 서비스 영역이 생성되어야만 진행이 가능했다.
이 과정에서 서비스 기획팀이 우선순위를 결정하기 때문에 딜레이 되는 경우도 있었고 발제한 프로젝트가 진행되더라도 프로젝트의 많은 권한과 영광을 가지게 되는 팀은 서비스 기획팀이었다.
(서비스 기획자가 된 후에는 서비스 영역 개발에 있어 가장 큰 책임을 가지기 때문에 자연스러운 것이라고 느껴지기도 했지만 실제로 타 팀에서는 이런 부분들로 인해 불만족스러운 경험을 하기도 했을 것이다.)
그래서 나는 더 큰 권한으로, 주체적으로 프로젝트를 리딩하고 싶어서 서비스 기획자로 직무를 전환했다.
그러나 ‘요청‘을 통해 업무를 해야 하는 직무
확실히 서비스 기획팀은 타 팀보다 프로젝트 우선순위를 결정할 수 있는 권한이 큰 편이다.
본부 차원에서 진행되는 큰 프로젝트가 아니라면 타 팀에서 요청이 오는 프로젝트들에 대해 개인이 리소스와 우선순위를 고려하여 진행 여부를 결정하기도 한다.
이렇게 주체성이 큰 직무이지만 아이러니하게도 프로젝트 진행에 있어 ‘직접' 할 수 있는 것은 많지 않은 직무가 서비스 기획자다.
서비스 기획자는 ‘요청’을 통해 프로젝트를 진행한다. 마케터는 직접 광고를 집행할 수 있고, 콘텐츠 기획자는 직접 콘텐츠를 제작할 수 있지만 서비스 기획자는 직접 개발이나 디자인을 할 수 없지 않은가.
사소한 개발 오류, 심지어 '오타'와 같은 작은 변경 사항에 대해서도 할 수 있는 일은 수정을 '요청'하는 것이다. 당연한 것처럼 들릴 수도 있지만, 요청에 의해 상당수의 업무가 진행되게 되면 업무에 있어 통제력이 높지 않다고 느껴질 때가 많다.
결국 프로덕트에서 어떤 프로젝트를 주요하게 진행할 것인지 기획하고 제시할 수 있는 권한과 책임 그리고 그에 따르는 영광을 가질 수 있는 직무이지만 디자인, 개발과 같은 '제작'의 리소스를 가져가는 팀에서 거부 또는 리소스가 부족한 상황에서는 프로젝트가 진행될 수 없다.
그래서 서비스기획자는 제작팀의 리소스를 얻어내기 위해 리소스를 관리할 수 있어야 하고 스펙의 우선순위를 판단할 수 있어야 하고 효율적으로 문제를 해결할 수 있도록 ’진짜 문제’를 정의할 수 있어야 하는 것이다.
그럼에도 “무엇”을 요청할지 직접 결정할 수 있어 기획자로 근무하는 것이 재밌을 때가 많다.
모든 책임은 기획자에게 있다. 가끔은 영광도 함께.
주체성이 높다는 것은 권한이 많다는 것만을 의미하지 않는다. 당연히 그만큼의 “책임”도 따른다. 물론 프로젝트가 잘 진행된다면 책임과 함께 영광도 있다.
[기획] 아래아
[디자인] 김디자인
[개발] 김개발
사내 인트라넷에 전사 직원들이 보는 서비스 관련 공지를 올릴 때마다 ‘기획자’로 이름을 올리는 것이 짜릿할 때도 있다. 사후 리뷰를 하며 향상된 데이터들과 나의 가설이 검증되어 좋은 결과를 냈다는 걸 발표하며 인정받으면 ‘정말 이 맛에 기획한다.’는 생각이 절로 든다.
이러한 인정 욕구의 충족 외에도 나의 기획으로부터 나오는 결과물, 프로덕트의 변화, 고객들의 반응, 데이터로 볼 수 있는 성과, A/B 테스트를 통해 검증하는 가설, 인사이트와 문제 해결을 위한 고민의 과정. 그 모든 것들이 서비스 기획을 하게 만드는 원동력이 되기도 한다.
그러나 기획자로 근무하다 보면 대체로 이러한 영광과 과정에서의 재미보다는 “책임”의 측면에서 받게 되는 부담감이 더 크게 느껴지는 것도 사실이다. 조직은 살벌한 곳이니까.
“무엇“을 할지 결정할 수 있다는 것은 “왜 지금 그걸 해야 하는가”를 설득할 수 있어야 한다는 것이고 그 끝에는 “그 결정이 옳았는가”에 대해 결과를 보여야 하는 책임이 뒤따른다.
이렇게 책임은 큰데 소위 ‘직접’ 내 손 내 발로 할 수는 없다. 요청에 의해서만 가능하다. 무형의 프로젝트가 유형의 형태를 가지기까지 다른 이의 손과 발을 빌어 완성해야 한다. 철저한 “관리” 직무이다.
프로젝트의 손과 발이 되어 주시는 분들이 기획자와 뜻을 함께 하게 된다면 더할 나위 없다. 하지만 늘 그렇지는 않다. ’내가 왜 이걸 해야 하지?‘와 같은 불만스러운 모습을 보이시는 분들도 생각보다 많다. 비협조적인 표현을 듣게 되는 상황 또한 생각보다 많다. 업무를 주는 입장이니 기획을 평가받는 상황에도 자주 놓인다.
그럴 때마다 서비스 기획자가 되고 손과 발을 움직여야 하는 ”머리“가 되어야 한다는 면에서 나의 역할보다는 실력에 대한 의심을 가지며 반성의 시간들을 자주 보냈다.
그러나 역할에 좀 더 집중을 하는 편이 좋다. 개발은 개발자가, 디자이너는 디자이너가 하는 동안 기획자는 목적지까지 갈 수 있는 “방향”을 제시하는 역할을 하는 직무이다.
기획자가 개발자만큼 개발을 알고 디자이너만큼 디자인도 알아야만 프로젝트를 성공적으로 이끌 수 있는 것이 아니다. 이런 일은 가능하지도 않다.
부담감으로 인해 여러 가지 질병을 얻고 싶지 않다면 서비스 기획자의 역할은 배를 이끌고 있는 선장이 아니라 방향키를 잡고 있는 키잡이라고 생각해야 한다.
이러한 상황에서 프로젝트를 목적지까지 끝까지 끌고 갈 책임은 온전히 기획자에게 있다. 돌아가게 될지라도 어떻게든 정해진 시간까지 배를 목적지까지 끌고 가야 한다.
사무직인데요. 기술 비슷한 걸 배워요.
사람은 기술을 배워야 한다고 말한다. IT 서비스 기획자는 개발도 못하고 디자인도 못한다. 이름은 거창해 보여도 기술은 없는 사무직이다.
8년 동안 담당한 프로젝트의 분야는 다양했다. AI, 빅데이터, SEO, 크리에이터, 솔루션, 데이터 등등. 이 분야의 모든 기술을 섭렵했다면 아마 내 연봉은 천정부지로 치솟지 않았을까? 이 모든 분야를 다 전문적으로 할 수 있는 인력도 많지는 않을 것이다.
그럼 기술을 모르면서 어떻게 프로젝트를 진행할 수 있었을까? 누군가는 얕고 넓게 알아서 가능했을 것이라고 하겠지만 기술은 활용하는 도구이기 때문에 가능했다.
수영을 하기 위해 오리발을 빌리기도 하고 튜브를 빌리기도 하고 때로는 물안경을 끼기도 하고 잠수가 필요할 땐 산소통을 차기도 하듯이 기술은 문제를 해결하기 위한 도구이니까.
어떤 것이 플랫폼 또는 고객이 가진 문제인지 진단하고 필요한 기술들을 활용하는 방법, 기술은 없지만 그 통찰을 배우는 직무가 서비스 기획자라고 생각한다.
IT 서비스 기획자 되지 말아요.
위에서 추천했던 영상을 보면 이런 이야기들이 나온다.
- 사람들은 예쁜 디자인과 새로운 기술에만 관심이 있어서 유명한 기획자 이름은 들어보지 못했을 거라고. (끄덕끄덕)
- 이미지 사이즈 변경할 때 몇 명에게 물어봐야 하는지 아느냐. 기획자가 혼자 결정할 수 있는 게 있긴 하냐. (격한 끄덕끄덕)
- 잘못한 것도 없는데 매일 사과해야 한다.(네, 저는 사과기계입니다.)
솔직하게 말하면 모든 말들이 공감된다. 재미를 위해 과장된 것이 아닐 것(?)이다.
서비스 기획자는 어디서나 심지어 홀로 있어도 환영받는 기술 직무도 아니고, ’직접‘ 작업할 수 있는 것도 없고 ’요청‘에 의해서만 일을 진행할 수 있으며 그렇기에 업무 요청을 추가할 때마다 ‘번거로움’에 대해 자주 사과를 하게 되는 입장이랄까?
종합해보면 서비스 기획자의 대표적인 고충 5가지는 다음과 같다.
서비스 기획자가 힘든 5가지 이유
1. 완벽할 수 없는 개발 요청 문서의 작성(예외케이스들과의 전투)
- 일을 완벽하게 해내고 싶은 성격이라면 고충을 느낄 수 있는 구조가 바로 개발 경험이 없는데 개발자가 일할 수 있도록 문서를 작성한다는 것이다. ‘이 정도로 정의하면 개발하기에 충분한가?‘에 대해 많은 고민을 하지만 언제나 구멍이 있고 완벽할 수는 없다. 이 과정에서 수정과 수정이 반복되면 종종 자괴감을 느끼거나 개발자의 ‘약간의 분노’를 경험할 수도 있다. 역지사지로 생각해 보면 나도 물건을 조립해야 하는데 설명서에 빠진 부분이 많으면 화가 나니까! 그래서 문서 작성을 늘 꼼꼼하게 하는데도 컴퓨터가 이해하게 하려면 더 다양한 케이스에 대해 계산적이어야 한다.
2. 일을 만들고 요청하는 직무라서 받는 적대감(또는 비협조적인 동료들의 모습)
- 개발자 동료로부터 ‘기획팀은 적이다.’라는 말을 들은 적이 있다. 일을 주는 팀이기 때문에 받게 되는 적대심이다. 하지만 사실 생각해 보면 일을 요청하는 사람이 기획자일 뿐, 일은 회사가 주는 것이란 말이다! (억울) 그러나 월급은 사장님이, 일은 기획자가 준다고 느껴지는 구조이다 보니 기획자는 복잡한 일을 만드는 원흉(?)이라고 느껴질 때도 있는 것 같다. 그래도 다행히 개발자와 친구가 될 수도 있다.
3. 책임은 모두 기획자에게 있다.
- 무엇으로부터 문제가 발생했든(내 손이 닿지 않는 곳에서 발생했더라도) 그 모든 것은 최전방에서 책임지고 확인하지 않은 기획자의 잘못이다. 기획자는 프로젝트전체를 관리하는 일을 하는 사람이기 때문이다. 그래서 예상할 수 없는 상황까지 대비하기 위해 다양한 대안들을 수립하며 대문자 J가 되어야 한다.
4. 기획의 자율성과 목적의식이 부족할 때
- 이렇게 프로젝트를 요청하고 관리하며 끝까지 책임을 지는 업무를 해야 하는데 만약 그 프로젝트가 ’내
것‘이라고 느껴지지 않는다면 어떨까? 위에서 내려오는 프로젝트에 대해 스스로 목적의식을 가지지 못하면 프로젝트 리더라는 사람이 ‘이거 꼭 해야 해요? 왜 맨날 이상한 것만 해요?’에 대한 질문에 곤란해하며 얼버무리게 되고 결과에 대해서도 보람을 느끼지 못 하며 ’어쩔 수 없이 했다.‘는 마음으로 일을 하게 된다. 이렇게 프로젝트를 진행하면 함께 일하는 사람들도 목적의식을 느끼지 못하고 프로젝트가 진행되는 내내 심적인 고통이 따른다.
5. 비평, 피드백 그리고 설득
- 업무를 진행해야 하는 사람들의 입장에서 일하는 목적에 대해 설득당하지 않으면 일을 하고 싶지 않기 때문에 기획의 목적에 대해 자주 질문을 받고 평가를 받게 된다. 이때 기획팀 리더 또는 상부에 수차례 보고 완료한 기획이기 때문에 ‘더 이상 기획서를 수정하고 싶지 않아.’라는 마음으로 대하면 열린 자세로 비평을 듣기 어렵고 더 좋은 서비스가 되기 위해 논의하는 것이 불가능하다. 그럼에도 필요하다면 어떤 질문에도 설득이 가능하도록 객관적 데이터들과 논리로 방패를 준비해 가는 것이 좋다.
최근에 어플리케이션을 개발하고 싶었다. 그런데 개발자를 고용하려면 돈도 많이 들고 오류가 나면 직접 수정도 하고 싶고(그래야 시간도 절약될 테니까) 그래서 개발자에게 물었다.
“이런 앱 만들고 싶은데 이 정도 개발 배우려면 얼마나 걸려?”
“과일 장사하려고 과수원 차리게?”
과일 장사를 하기 위해
과수원부터 만들 것인가?
띵언. 기획자에게 꼭 필요한 말.
이 말이 기획자에게 꼭 필요한 말인 이유는 프로덕트라는 결과물을 만들기 위해, 최종 책임자가 기획자라고 해서 모든 것을 직접 할 수 없고 모든 것을 알 수 없는 게 당연하다는 걸 받아들이게 해주기 때문이다.
8년의 경력을 통해 기획자는 개발자와 디자이너에게 ‘좋은 기획자’로 인정받으려고 노력하기보다 좋은 기획을 통해 고객들에게 인정받는 것에 더 집중했을 때 ‘좋은 기획자’가 된다는 걸 깨달았다.
그래서 기획자 하지 말아야 할까?
아니다. 개인적으로 기획자가 겪는 고충에 대한 이야기들을 적으며 "기획자가 아니면 뭘 하고 싶은가"에 대해 한 번 생각해 봤다. 그런데 없다. 나는 IT 서비스 기획이 좋다.
왜 때문이죠?
서비스 기획자가 좋은 5가지 이유
1. IT 프로덕트
- 기술로서 수백만의 사람들이 손 안에서 얻는 편리함에 내가 기여할 수 있다는 것이 보람 있다.
2. 직접 정하는 방향성
- 무거운 부담감을 느끼더라도 내가 정한 방향으로 갈 수 있어서 좋다.
3. 눈으로 볼 수 있는 결과물
- 서비스, 데이터 등 결과물이 직관적이고 이를 통해 짧은 기간에도 성과를 볼 수 있다는 것이 즐겁다.
4. 프로젝트 단위의 업무
- 프로젝트 단위로 일 할 수 있어서 재밌다. 다양한 분야를 알게 되고 다양한 담당자들이 만날 수 있어서 다이내믹하고 지루하지 않다.
5. 가설의 검증을 통한 문제 해결
- 나의 가설을 검증할 수 있어서 짜릿하다. 데이터를 비교적 쉽게 남길 수 있는 IT 서비스라 짧은 기간에도 좀 더 쉽게 A/B테스트가 가능하고 이를 통해 인사이트를 진단할 수 있어 재밌다.
IT 서비스 기획자가 좋은 이유는 더 많이 있겠지만(물론 고충도 더 많이 있을 수 있다.) 나에게 있어서는 이렇게 5가지 이유가 가장 큰 것 같다.
일을 하면서 자괴감이 들 때도 있고 스스로 멍청하게 느껴지는 날들도 많았지만 그럼에도 8년 가까이 IT 서비스 기획자로 일을 하며 즐거운 경험들을 할 수 있어 좋았다.
IT 서비스 기획 직무를 고민하고 있는 이들에게 작게나마 도움이 되는 글이 되길 바라며 생각보다 길어진 소감문 끝! (적다 보니 서비스 기획자라서 좋은 점 보다 힘든 점을 구구절절 적게 된 것은 우리만의 비밀로...)
