brunch

You can make anything
by writing

C.S.Lewis

by 소얀 May 29. 2022

입사 후 일 년이 지나고

B2B SaaS 기획자의 1주년 맞이 소감

2021년 3월 15일, 회사 입사 후 일 년이 조금 남짓 흘렀다. 나는 협업하는 솔루션을 만드는 회사에 서비스 기획자로서 다니고 있으며 그 중 백오피스(플랫폼) 기획자로 있다.


참고로 나는 사회에 나온지는 9년이 되었지만 중간에 많이 방황했다. SI 회사에서 2년, 대학원 2년, 그리고 기획자로서 일한지는 5년차이다. 중고신인으로 들어간 첫 회사부터 세 개의 스타트업에 다녔고, 지금 회사에 백오피스 기획자로 입사했다. 지금 회사는 내가 다녀본 회사 중 가장 큰 회사며, 감사하게도 “IT 서비스 기획자"로서 온전히 일할 수 있는 곳이다.


와서 무엇을 했나?

나는 최대 다섯 개의 프로젝트(이하 과제)를 갖고 있었다. 그리고 그 중 세 개의 프로젝트를 오픈했다. IT 업계에서 보통 프로젝트는 배포/릴리즈라고도 부른다. 계정 쪽에 자잘하게 얹혀갔던 A 과제, 지난 봄에 오자마자 기획했고 연말부터 개발에 들어가 마침내 3월에 사내에 PoC 상태로 오픈했던 B 과제. 그리고 지난 여름에 시작했고 가장 길었고 논쟁적이었던 C 과제가 있었다. 계정, 관리자, 결제처럼 특정 기능을 전담하기보다는 B, C 모두 처음부터 만들어야 하는 프로젝트에 용병처럼 다니고 있다.


나머지 두 개는 내가 중간에 손을 뗐다. D 과제는 휴직자 대신 맡아준거라 그분이 복직하시자 냉큼 다시 드렸고, E 과제는 프로젝트 범위가 축소되면서 내 역할이 불분명해진 상태에서 간간히 회의만 들어갔는데, 연초에 B 과제 QA가 너무 힘들어 손을 떼겠다 읍소…선언했다.


1주년은 지난 3월에 맞았지만, C 과제를 세상에 내놓은 이번주 수요일에야 나는 입사 회고를 쓸 수 있게 되었다. C 과제는 정말 말도 많고 탈도 많았다. C를 릴리즈하기 직전 정말 예민했었고, 지금은 약간 헛헛한 마음도 있다. 여기에 대해선 개발자들과 회고 한번 하고 써보려 한다.


무엇을 알게 되었나?


1)새삼 백오피스 기획을 할 수 있다니


사실 백오피스 기획자로 입사했지만, 스타트업에 있었던 시간이 많았던 나는 백오피스는 얼기설기 만드는데 익숙했으며 하루 아침에 서버를 뒤집는 경우도 많았다. 그리고 기껏 만들었던 프로젝트가 유지보수가 어려워 다시 처음부터 세 번을 만들었던 적도 있었다.


그래서 기획을 할 때 백오피스에서 고려할 UI 요소들(필터, 검색, 리스트)을 기획할때서툴렀다. 지나치게 보수적으로 기획해서 실제 사용성이 떨어지는 결정을 하기도 했던 적도 있었다. 반대로 편의성을 높이려고 너무 편하게 만들려다 오히려 그 결과 새로 온 구성원들이 히스토리를 잘 확인하지 못하는 부작용이 생겨 그 결정을 번복한 적도 있다. B 프로젝트의 경우 뒷단 서버 연결이 가장 어려웠던 부분이라 프로젝트 오픈 뒤 이런 요소들은 다 포기한 뒤 그냥 돌아가게만 만들고 UI 요소는 전부 포기했는데, 그마저도 오픈 후 넘겨주게 되어 아쉽다.

다시 한 번 도그냥님 블로그, 여름의 속도 님 브런치를 정독해보자.


2)오픈 프로세스를 겪어보고 운영에 대해 고민하게 되었다.


1)에서 눈치챘듯이 오픈? 그런게 어딨나. 그냥 열고 고치는 경우들이 많았다. 운영 프로세스? 돈 주시는데로 노 저었다. 이러면 안됩니다 여러분 QA? 테스트 시나리오 내가 짜고 테스트하고 실갱이하는 건 나였다. 그러다 꼭 사고나지. 그런데 이번 회사에서는 오픈을 하면서 과제 선정, 프로젝트 배정, 오픈과 운영이라는 전체 사이클을 거쳐볼 수 있었다. 특히 A, B, C 모두 QA를 거쳤는데 QA 조직이 있어서 얼마다 든든했는지 모른다. 소매를 붙이다 계속 뜯어져서 이거 꿰맬지 말지 세 달은 삽질을 했으니까(지난 글에 링크가 있다)


오픈 절차는 쉽지 않았다. 개인정보보호파트와 개인정보 영향평가를 해야 하기도 하고 QA 이후 보안진단파트와 취약점 테스트를 거쳐야 한다. 유관부서에 사전에 계획 공유도 해야 하고 그리고 CS 대응 가이드나 관리자 가이드를 함께 쓰는 사람과 같이 논의하기도 하고, 공지사항과 마케팅 자료들을 챙겨야 하기도 한다. 특히, C 프로젝트는 취약점 테스트 과정이 정말 길고 어려웠는데, 보통 2주 걸리는 작업이 3.5주가 걸렸다. 해주는 쪽도 힘드셨다고 한다.


그 외 서비스 어드민, 지표 정의 등은 오픈 전에 챙겼어야 하지만 이제야 뚜껑 열고 이제 어떡하지..? 하고 생각중이다. C 프로젝트는 “많이 쓰게” 하는 것이 목적이 아니라 남용하지 않도록 하는 것이 목적이기에 그나마 다행이다. 기능 사용 빈도를 높이기 위한 과제 자체를 진행할 필요는 없다. 아직은 개점휴업 상태여도 된다는 것. 오픈해두고 뒷수습하고있다…


3)일과 나, 그리고 팀이 불일치할 수도 있다는 것을 깨달았다.


오픈 한 프로젝트 중 A, B는 다른 부서에 넘겨주었다.


A 과제는 계정팀에 얹혀서 진행하게 된 나는 계정팀과 고객사 사이에 끼어있었다. 처음엔 내가 과제 진행절차에 주도권을 가지지 못해서 좀 아쉬웠다. 하지만 QA 환경세팅 및 진행이 지옥같이 힘든 일이라는 걸 알았기 때문에 차라리 감사한 일이었다.


B 과제는 연말 회사 내 조직 개편으로 사내 오픈 후 넘겨주게 되었다. 그마저도 B 과제의 QA와 C 과제의 개발이 동시에 겹쳤던 연초에는 죽을 뻔했다. 그때 깨달았다. 인수인계는 조직개편 되었을때 빨리하는 게 좋다고…. 괜히 “이것까진 내가 해야지"라는 어설픈 책임감은 모두를 죽인다는 걸 깨달았다.


또, C 과제를 하던 중 과제를 안고 옆 팀으로 가게 되었다. 팀에 꽤 정을 많이 준 나로서는 적응을 하는 데 한 달 가까이 걸렸다. 결과적으로는  팀을 옮겨서 C 과제를 잘 마무리할 수 있었지만, 팀원들이 없자 거의 한 달간 헛헛한 느낌이었고, 갑자기 이직하게 된 느낌마저 받았다.


팀과 나와 프로젝트가 하나가 아닐 수 있는 상황이 종종 생긴다는 것이 내게 꽤나 생경한 일이었다.


4)기능조직에서의 안정감을 얻었다.


보통 목적조직은 한 프로젝트를 런칭하기 위해 기획자, 개발자, 디자이너가 모여있다. 하나의 목표를 위해 다같이 속도감있게 움직일 수 있지만, 원앤온리 기획자인 것은 쉽지 않은 일이다. 반면 기능조직은 기획팀, 개발팀, 디자인팀이 모여있는 방식이다. 어떤 조직에서 원앤온리 기획자로 있는 것이 익숙했고, 그러다보니 기획자로서 내가 잘 알지 못하면 함께 표류하는 적이 많았다. 기획자로서의 고충을 함께 나눌 수 있다는 건 귀한 경험이다.

여담으로 첫 기획자 생활을 시작하면 기능 조직으로 갈 수 있다면 가는 걸 추천한다. 팀이라는 우산이 있는건 소중하니까…


5)내가 생각보다 정을 잘 주는 사람이구나 싶어져 버렸다.


원래 남의 기분에 민감한 사람인데, 일희일비하면 내가 너무 힘들것 같기도 해서 거리를 두는 편이었다. 항상 함께 일하고 싶은 사람과 일하고 싶어서 이직하는 편이라 이번에만큼은 어떤 결정을 내릴 때 사람 믿고 가지 않겠다 생각했다. 큰 회사로 이직하는 만큼 그런 부분은 없으리라 생각했는데, 오히려 가장 정이 많이 들었다. 조금 오지랖을 부리기도 하고 사람들에게 정을 주게 되었다.

그래서 요즘 이직 소식을 들으면 맘속 타격이 큰 편이다.


아직 고민되는 것


1)우선순위를 정하는 능력


모든 것을 할 수 없으니 과제끼리도 우선순위를 두고 경쟁을 하고, 과제 내 스펙을 정리할때도 우선순위를 잘 보고 가야 한다. 그게 아니면 모두가 비효율적인 일을 하게 될 수 있으니 조심해야 한다. 하지만 내가 모르는 분야를 기획하게 되면 그 부분이 어려워지는는데, C 프로젝트가 개인적으로 그런 프로젝트였었다.

언젠가 비슷한 업체에 계신 분한테 물었을때 실제 요구사항의 경중을 기반으로 따지게 된다고 하였다. 이건 회고를 하고 좀더 써봐야겠다.


2)데이터를 기반으로 사고하는 능력


관리자 프로그램의 특성상 빈틈없이 일하는데 익숙해져있다. 그래서 기민한 판단과 릴리즈가 쉽지 않은데, 나중에 내가 관리자 프로그램 만드는 대신 다시 목적조직의 원앤온리 기획자가 되었을때 제품 말아먹는게 아닐까 살짝 걱정된다.

얼마 전 업계에서 책을 나누다 우리 조직의 KPI에 내가 관심이 없었다는 사실에 반성하게 되었는데, 지표를 기반으로 움직이지 않다보니 이 경향이 심해졌다.


3)내가 만드는 서비스가 누군가에게 고마울까?


C 프로젝트가 가장 논쟁적이기 때문이었을까. 이건 최근 하게 된 고민이다. 나는 유관부서나 개발자, 디자이너에게 고맙다는 말을 하는데 누군가에게 고맙다, 는 말을 들어본지 오래되었다. 이 서비스는 누군가에게 고마울까? 근데 고마운 서비스는 뭘까? 일을 빨리 해결하면, 효율적이면 좋은 걸까? 나름대로 Mission statement로 풀어보려 하는데 가장 답없는 고민이다.


나가며


회고라면 뭔가 진단을 내리고 앞으로의 계획도 짤 수 있어야 하는데 아직 거기까진 못 가겠다.

오늘은 여기까지.

매거진의 이전글 괴물에게 먹이를 주지 마시오
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari