안녕하세요. 에디터 오리진입니다. 

'기획'이라는 말의 사전적인 의미는 '일을 꾀하여 계획함' 인 만큼, 사실 모든 일이 기획이 될 수 있습니다. 전략 기획, 사업 기획, 영업 기획 등 다양한 부서가 기획이라는 이름을 가지고 있죠. 

제가 맡고 있는 서비스 기획은 전사적인 흐름에서 보면 중간 정도에 있다고 생각하고 있습니다. 전략 기획을 통해 전사 방향성이 정해지고, 그에 맞춘 사업 기획이 나오고, 그리고 사업을 실제로 실행하는 데 필요한 IT 서비스를 구현하기 위한 기획이 나오죠. 그리고 서비스 기획에서 제시한 계획을 디자인, 개발이 실제 서비스로 구현합니다.

제 실제의 업무 프로세스는 다음과 같습니다. 요구사항 접수 > 이해관계자의 요구사항 구체화 > 개발 요구사항 작성 > 디자인/개발 논의 후 개발 요건 확정 > 개발 이후 검수 > 데이터 뽑아보기의 흐름입니다. 

먼저, 고객 서비스 담당, 마케팅 혹은 신규 사업 추진 부서 등 사내의 다양한 이해관계자로부터 요구사항을 받습니다. 제가 자체적으로 새로운 기획을 하는 경우도 있지만, 정해진 일정 속에서 사업적인 중요성을 가지는 요구사항이 우선이 될 때가 많습니다. 

그다음으로는 이해관계자와의 소통을 통해 요구사항을 구체화하게 됩니다. 요구사항을 내는 담당자가 자신이 무엇을 원하는지 정확히 모를 때가 있고, 최종 형상에 대해 이해하는 바가 같은지 조율이 필요하기 때문이에요. 이 과정이 없으면, 최종 결과물을 보고 "이건 우리가 원한게 아닌데"라는 말을 듣게 됩니다. 담당 부서에서 원하는 최종 목적과 고객이 원하는 것이 다를 것 같으면 역제안도 하게 됩니다.

이러한 소통을 통해 어떠한 것을 만들어야 할 지 아이디어를 잡고, 그 아이디어에 대한 정책 및 개발 요구사항을 작성하게 됩니다. 제 요구사항은 보통 이 개발이 왜 진행되어야 하는지에 대한 배경과 목적, 따라야 할 용어 규칙과 서비스 규칙, 화면 설계와 세부 항목에 대한 정책, 그리고 개발 영역별 요구사항으로 이루어져 있습니다. 

그리고 이러한 요구사항을 기반으로 디자인, 개발팀과 회의를 통해 개발 가능한 영역과 최종 형상에 대해 조율하게 됩니다. IT 업무를 다루는 밈에서 자주 등장하는 개발자의 '안 돼요'는 보통 이 시점에 등장합니다. 

안 돼요, 라는 말을 들었다고 해서 이 프로세스가 멈추는 것은 아닙니다. 같은 '안 돼요'라도, 상황에 따라 다음과 같이 그 의미는 달라질 수 있기 때문이에요. 

① 일정/비용상 안 됨 - 담당 사업팀에서 생각하는 것보다 더 큰 개발 범위

② 진행 필요성에 대해 공감하지 못하는 일 - 작은 효과, 큰 개발 리스크 

③ 기획서에 대한 이해의 차이 

④ 모름 - 신규 개발 건의 경우, 너무나 복잡한 개발 구조, 담당 개발 영역이 아니어서 몰라서 구현 불가능해 보임 

이 정도로 저는 꼽아보고 있어요. 위 케이스 중 어떤 케이스인지에 따라 기획자가 할 일은 달라집니다.

① 일정/비용상 안 됨 

→ 요구사항을 낸 이해관계자와 조율 진행

(ex. "예산 어느 정도로 생각하세요?", "이번 일정에는 어렵고 다음 일정으로 진행할게요")

② 진행 필요성에 대해 공감하지 못하는 일

→ 재설득, 리스크가 있다면 리스크 요인 점검 후 일감 재검토 혹은 정책 세부화

③ 기획서에 대한 이해의 차이 

→ 이건 간단합니다. 반성하며 (눈물) 기획서를 읽기 쉽게 다시 씁니다.

④ 모름

→ 필요한 시스템에 관해 확인, 관련 담당자를 모아 회의 진행

이렇게 정리된 요구사항을 기반으로 개발이 진행되면 기획자의 일은 끝날까요? 사실 그렇지 않습니다. 개발 중 작고 큰 이슈에 대해 같이 대응하기도 합니다. 실제로 개발해 보니 이슈가 있다든지하면 회의를 소집하고 필요시 요건을 변경하기도 하죠.

이 과정에서 기획자 입장에서 가장 큰 이슈이자 모든 관계자에게 미안해지는 일은 요구사항을 작성할 당시에는 기획적으로 고려하지 못한 부분을 뒤늦게 발견하거나, 혹은 담당 임원이 변경 사항을 지시하는 경우입니다. 전자도 그렇지만 후자의 경우에는 이제 기획, 디자인, 개발 모두에게 큰 스트레스가 됩니다. 크게 변경되기도 하니까요.

이제 마지막으로, 개발이 완료된 이후 검증 및 데이터 확인이 있습니다. 기획대로 개발된 것이 맞는지, 오류는 없는지 검수하는 단계입니다. 해당을 담당해 주는 QA(검수)부서가 따로 있지만, 기획이 내용을 잘 아는 만큼 같이 검수를 진행하고는 합니다.

그리고 모든 것이 기도한 대로 잘 진행되어 배포가 잘 되면, 고객의 사용 데이터를 수집하기 위해 정의한 사용 로그를 기반으로 고객의 실사용 데이터를 뽑아보고는 합니다. 

일 년에 개발 버전이 얼마나 나가는지에 따라 다르지만, 기획자는 위의 과정을 해마다 1~2번씩 반복하곤 합니다.

솔직히 말하면, 기획자는 요구사항을 제공하는 사업 담당자가 가지는 사업에 대한 지식을 모르고, 개발자만큼 개발을 잘 알지 못하며, 디자이너의 디자인 스킬을 가지고 있지 못합니다. 그런 상황에서 기획자는 이 모두에게 '기획' 이라는 말 그대로 방향을 제시하고, 작고 큰 결정을 내리며 서비스가 배포될 때까지 많은 소통을 해야 합니다. 

기획자는 많은 결정을 할 순간을 맞이하게 되는데 이 결정을 할 권한을 기획자에게 주는 이유는 무엇일까요? 기획자가 가지는 강점이 무엇이길래? 저는 그 고민을 일하는 내내 하고 있습니다만, 제가 이른 결론은 앞서 보여드린 영상에서도 잠시 언급되었던 '넓고 얕은 지식'입니다. 사업을 담당자만큼 모르지만, 어느 정도 사업을 알고, 개발자만큼 개발을 모르지만 어느 정도 구조를 이해하고, 디자인을 모르지만 디자인을 볼 줄 아는 눈이 있어야 제대로 된 기획이 가능하다고 생각해요.

각 파트의 전문가들이 볼 수 없는 전체를 이해하고, 그렇기에 각 파트에서 볼 수 없는 리스크와 고려 필요한 부분을 찾아 최적의 방안으로 향하는 것, 이 기획자가 해야 할 부분이라고 생각하고 있어요.

그리고 그렇게 하기 위해서는 결국 세 가지가 중요하다고 생각합니다. 공부가 첫 번째이고, 두 번째는 호기심, 그리고 세 번째는 확실한 우선순위입니다.

가장 먼저 공부하는 것, 그래서 어떻게 일이 돌아가는지 아는 것이 가장 중요하다고 생각해요. 새로운 걸 만들기 위해서는 창의성이 필요하다고 생각하게 되는데, 창의성에 가장 중요한 것은 기존의 것을 아는 것이라고 생각합니다. 

이런 말을 하면 '기획자는 개발을 공부해야 하나요?'라는 질문이 따라붙는데, 저도 신입 때 이런 고민을 많이 했지만 결론은 '어느 정도 구조를 이해하기 위한 공부는 필요하지만 실제 코딩이 가능할 정도로 공부할 필요는 없다'라는 것입니다. 왜냐하면, 사내에 개발을 훨씬 잘 아는 전문가가 있는데 제가 전문가가 될 필요는 없기 때문이에요. 다만 기획안을 잘 쓰기 위해서는 기본적인 개발 구조에 대한 이해가 필요합니다. 저는 《아는 만큼 보이는 OO 개발》 시리즈 정도만 읽고, 사내 개발 구조에 대해 정리된 문서나 API 문서를 읽고 내부 담당자에게 틈틈이 질문하는 것이 개인적으로는 효과적이라고 느꼈어요.

개발뿐만 아니라, 서비스 기획이란 시장을 읽고, 고객을 읽을 줄 알아야 하는데 전략/사업 담당자나 고객 연구/데이터 분석가만큼은 할 수 없죠. 다만 중요한 것은 전문가가 아니더라도 어느 정도는 지식을 쌓고 이해해야 한다는 것입니다. 그래서 바빠요. 각 분야를 땅굴 파고 들어갈 것이 아니라 어떤 기획자가 되고 싶은지 (나는 사업을 이해하는 데에 특화된 기획자인가, 혹은 개발 친화적인 기획자가 되고 싶은가)에 따라 선택해서 추가로 배우는 것이 나을 것 같다고 개인적으로는 생각합니다.

두 번째는 호기심입니다. 기획이란, 모든 일이 그렇겠지만 더더욱 결국은 당면한 문제를 어떻게 해결할 것인가를 풀어나가는 일이라고 생각해요. 다만 대개 '문제'는 풀기 어렵습니다. 회사의 시스템은 서로 너무나 연관되어 있고, 협력사나 새로운 개발자들이 놓치는 레거시 코드가 있으며, 사업 담당 임원은 계속 마음이 바뀔 수 있으며, 빠른 의사 결정 속에서 내가 놓친 것이 있을 수도 있습니다. 그 모든 과정에서 많은 누군가가 할 수 없다는 의견을 줄 것이고요. 

모든 의견에는 이유가 있어요. 그리고 그 이유 속에는 이 일이 수월하게 진행되려면 어떤 문제를 해결해야 하는지 힌트가 반드시 있습니다. 다만 해결책까지 당도하는 길을 걷는 것은 의지만으로는 어렵다고 생각하고 (저는 항상 '여기서 그냥 다 그만하고 싶다'라고도 생각합니다.) '왜 안 되지?', '왜 이걸 해야 하지?', '이걸 해결하려면 무엇부터 해야 하지?'라는 호기심이 있어야 일을 지속할 수 있다고 생각합니다. 

세 번째는 확실한 우선순위입니다. 우선순위라는 모호한 말에 제가 담은 의미는 기획자가 자신의 최우선 목표가 무엇인지를 항상 기억하면서 일해야 한다는 것이에요. 결국 기획자가 하는 일의 목적은 속된 말로 '이게 고객에게 먹힐까?', ' 이걸 고객이 좋아할까?' 입니다.

사업 이해관계자의 요구사항과 개발 현실 사이에서 저는 항상 이걸 고민하게 됩니다. 내가 작성하는 개발 요구사항으로 인해 실제 고객은 어떤 경험을 하게 될까, 라는 것이요. 내가 여기서 타협하게 되면, 이후의 서비스는 어떻게 되지? 라는 고민을 정말 많이 합니다.

많은 기획자가 고민하는 '임원의 결정 사항에 따른 변경'에 대해서도 똑같습니다. 사업 담당자와 개발자, 디자이너간의 결정에는 수많은 토의와 질문이 오가는데, 임원의 결정은 위에서 내려온 것이니까 고객 경험이 헤쳐지더라도 질문 없이 무조건 해야 하는 게 맞나? 라는, 조직에 맞지 않는 부정한 생각을 하곤 합니다. 

물론 앞서 말했든 전사적인 방향이라면 따라야 하는 부분이지만, 저는 핵심 서비스의 고객 경험을 헤치는 부분이라면 밉보이더라도 끝까지 설득해 봐야 한다, 라는 생각을 하고 있어요. (물론 제 사회 생활에는 안 좋을 수 있습니다) 왜냐면 기획자가 납득하지 못한 부분을 디자이너와 개발자에게 설득할 수 있나요? 그리고 그렇게 나온 기능을 고객이 반기지 않는다면 무슨 의미가 있을까요.

성공하지 못하더라도, 그래도 그렇게 설득하고 역제안하는 과정을 통해 해야하는 이유라도 알아야 이후의 일을 하는 동료들을 이해시킬 수 있는 것 같아요. 기획자와 개발자, 디자이너간 싸움이 밈처럼 돌지만 결국 고객에게 사랑받는 서비스를 만들고 싶은 사람들이니까요.

결국에는 나름의 기준이 필요하다는 말이에요. 기획자는 사업 담당자, 개발자, 디자이너, 임원까지 다양한 사람들의 목소리를 듣다 보니 가끔 어떤 쪽으로 쏠릴 수 있습니다만, 결국 우선순위는 고객이라고 생각해 보면 많은 일의 우선순위와 정책이 명확해지더라고요. 

마치 20년차 기획자처럼 써 내려갔는데, 쓰다 보니 신입 시절의 제게 하고 싶었던 말이었던 것 같아요. 위에 중요하다고 나열한 사항을 지키지 못한 나날도 많습니다. 그래도 공부하고, 호기심을 가지고 문제를 해결하기 위해 집요하게 파나가고, 모든 과정에서 일관된 우선순위로 일하는, 제 생각에 이상적인 기획자가 되기 위해 매일 노력해 보고 있습니다.

답을 찾지 못한 고민도 있습니다. 저의 개인적인 배경을 먼저 공유해 드리면, 저는 UX 를 전공하고 서비스 기획으로 입사하였지만, 회사의 사정으로 전사 기획과 특정 플랫폼 PM을 거치고 서비스 기획자라는 직무로 돌아온 지 몇 년이 안 되었어요. 

그래서 제 경험 부족으로 이 직무가 매일매일 새롭고 어렵게 느껴지는 것일지도 모르겠습니다. 그래서 그런지 여러 고민이 있고 아직 답을 찾지 못한 부분이 있는데, 답을 찾고 싶은 마음으로 여기에 적어봅니다. 

- 기획자의 업무 범위는 어디까지인가?

자조적인 말로 기획자는 잡부라고도 합니다. 그런 말을 듣고 본인들 입으로도 그런 말을 하는 이유를 짐작해 보면, 사실 우리나라에서 기획자라고 칭하는 직무가 하는 일은 외국 기준으로 아주 세분화, 전문화되어있습니다. UX Researcher, Product Planner, Product Manager (PM) 등 여러 가지로요. 국내에서 회사별로 그렇게 세분화하여 채용하는 때도 있지만 아닌 경우가 많으므로 이런 말이 나오는 거겠죠.

디자인 이슈, 개발 협력사의 문의 및 이슈에 대한 논의, 임원 보고 등을 거치고 나면 나의 업무 범위는 어디까지로 선을 그어야 할지 고민하게 됩니다만 아직 답을 모르겠습니다. 저는 요즘 프로젝트 단위로 정책을 제공하는 수준에서 그칠지, 개발 이슈까지 챙기는 일종의 PM 역할을 하는지를 잘 모르겠더라고요. 어떨 때는 데이터를 볼 줄 모르는 사업 담당자를 위해 대시보드를 만들어주기도 하고요. 

경험이 많은 노련한 기획자라면 선을 잘 긋겠지만, 그렇지 못한 기획자여서 이런 고민을 하는 것일지도 모르겠습니다. 요즘은 일단 기획서부터 잘 써보고, 기획 본연의 일에 대한 집중을 못하게 하는 정도가 아니면 해야지, 정도로 생각 중입니다.

- AI 시대에 기획자는 뭘 할까

이런 고민을 하는 것은 기획자뿐만이 아니겠죠. 기획자는 아이디어 실현을 위해 개발과 디자인이 필요 없어지는 시대가 왔고, 개발과 디자인은 기획뿐만 아니라 서로가 필요 없어진 시대가 왔습니다. 친한 사업 담당자와 최근에 'AI 시대에 필요한 것은 3D 업무이니 빨리 시작하자'라는 이야기를 하기도 했어요. (눈물)

회사의 개발·디자인 담당자와 각각 이런 이야기를 하면, 다들 기획자는 살아남지 않겠냐고 약간 위안성 이야기를 해주시는데, 기획의 주체가 어디인지에 따라서 다를 수 있겠다고 생각했습니다. 기획자가 하는 역할이 요구사항을 받아, 실현할 수 있는 구조로 정책을 짜는 것이라면 AI로 대체될 수 있겠지만, 만약 시장을 (사람)을 읽고 그에 따른 기획을 하는 것이라면 AI로 오히려 날개를 달 수도 있겠다고 생각했어요. 그렇기 위해서는 새로운 가치를 발굴해 나가는 역할로서의 자리매김이 필요하지 않을까 싶어요.

저도 그렇고, 많은 회사의 기획자들이 같은 포지션일 것 같아요. 나만의 새로운 서비스를 만들 거라고 생각하고 들어왔더니 이미 플랫폼은 존재하고 운영 개발을 해야 하는 상황 말이죠. 내가 들어오기 전부터 있었던 서비스에 대해 온갖 사람들이 자신만의 의견을 가지고 있죠. 이런 상황에서 기획자는 방심하면 중간에서 문서를 정리해서 전달하는 역할만을 하기 쉽고, 그렇기 때문에 자신만의 견해를 확실히 가지고 가치를 만들어나갈 수 있어야 하는 것 같아요. 결국엔 자신만의 아이디어와 신념을 가지고 일하냐 아니냐가 AI 시대에서의 생존을 가른다고 보고 있어요.

요즘 저는 그래서 회사에서 내 일을 좀 더 잘해보자, 더 많이 목소리를 내자, 하고 다짐하고 노력해 보고 있어요. 별개로 AI를 활용한 사이드 프로젝트 진행도 생각하고 있습니다. 회사에서 하는 일에는 한계가 있으니까요. 역시 거창하게 썼지만 피곤해서 생각대로 못 하는 부분도 있는데요. 힘들더라도 노력을 해봐야겠죠. 

이 긴글의 결론은.... 기획자 여러분, 화이팅입니다. 우리 모두 잘 해봐요.

지난달 발행했던 한우물레터 '콘텐츠의 얼굴, 오프닝 시퀀스'에 대해 보내주신 피드백을 모아봤습니다. 🤗  

👤 마고 | 저도 너무 좋아하는 <007 스카이폴>의 오프닝 시퀀스가 나와서 정말 반가웠습니다! 오프닝 시퀀스만으로도 하나의 영화 같아서 넋놓고 보던 기억이 나요. OTT를 이용하면서 시리즈물은 첫화만 오프닝 시퀀스를 챙겨보고 이후로는 계속 건너뛰기를 이용하는데 창작자의 노고에 대한 존경만으로는 매회 챙겨보기는 어려운 것 같습니다..... ㅎㅎ 시청자의 니즈에 맞춰 변화해가는 오프닝 시퀀스에 대한 글 재미있었어요! 오리진 에디터님의 다음 글이 더욱 기대가 됩니다.

👤 낮달 | 오프닝 시퀀스를 사랑하는 사람 한 명 더요!! 저도 매번 반복되는 시퀀스더라도 변주가 있다면 결코 건너뛰지 않고, 매회 반복되는 경우에만 다음 회차로 이어지기에 방해가 되므로 건너뛰곤 합니다. 건너뛰는 방법이 생겼기에 더더욱 오프닝 시퀀스에 기대감이 많아진다는 말에 동감합니다. 필수적으로 봐야하는 게 아니니까 더 ‘잘 만든 오프닝 시퀀스‘가 유명해지고 또 오프닝 시퀀스 하나를 보고 이해하고 감상을 나누기 위해 그 작품을 찾아보기도 하게 되는 듯 합니다.

⏩ 오리진 | 크크크. 저와 같은 사람이 많아서 신나네요! 한우물레터 쓰기를 잘했다는 생각을 했습니다. 좋아하는 것을 나누고 또 듣는 재미가 있어서요. 피드백 감사해요, 이렇게 보내주시는 피드백이 큰 힘이 됩니다. 💗 

이세돌X페이커, AI가 이기고 싶은 두 남자 | [손석희의 질문들4]