입덧도 먹덧으로 오고, 그 흔한 자궁수축 한 번 없이 임신 기간 내내 좋은 컨디션을 유지한 나는 병원에서 의사 선생님에게 애를 둘셋씩 낳아도 되는 몸이라고 칭찬을 받을 정도였다. 그런데 30주에 들어서면서 아기가 평균 몸무게를 넘어서기 시작했고, 덩달아 임신 전 중량 스쿼트로 다져진 나의 허리는 '아작'이 나버렸다. 근무 시간에 30분에 한 번씩 일어나 보고 몸을 안마의자에 눕혀 보아도 해결이 되지 않는, 어마어마한 허리 통증... 회의를 하고 나면 어김없이 앉지도 서지도 걷지도 못할 통증으로 식은땀이 흐른다. 상태가 이렇게 되면 아무리 스트레칭을 해도 나아지지 않는다. 답은 오로지 리클라이너에 몸을 기대어 쉬는 것 뿐.. 재택근무가 아니기 때문에 쉬려면 휴가를 써야 한다. 그나마 출산휴가를 들어갈 수 있는 시점에 이렇게 되어서 다행이라고나 할까..?
'역시 내 계획대로 되지 않는구나...' QA와 이것 저것 상황을 감안해서 10월 중순까지 일하려던 계획을 수정해야 하는 상황이 됐다. 다행이 인수인계를 미리 진행해서 나 없이도 일이 굴러가도록 해 놓았긴 하지만, 자식을 키우면 이런 느낌일까 싶을 정도로 - 밤새 고민해서 기획하고 팀원들과 여러 날동안 열띤 논의를 해서 정리한 정책들과 화면들이 실제 사용자들에게 배포되는 과정을 온전히 함께하지 못하고 멀리서 지켜봐야 하는 기분이 이상하다.
하지만 이미 상황은 벌어졌고, 입사한지 9개월 만에 또 집에서 쉬게 생겼으니, 업무를 하면서 느꼈던 자잘한 기억의 파편들을 복직 후에 꺼내어볼 수 있도록 짤막하게 정리해 두려고 한다.
1. 3년 전의 나와 지금의 나의 차이 : 안해본 자와 해본 자
3년 전, 은행 본사에서 운영업무와 기획업무를 병행하던 나는 직접 무언가를 할 일이 매우 적었다. 예를 들어 앱에서 약관 동의를 받고 그 버전들을 관리하는 업무가 있다고 치면, 은행에선 약관을 관리하는 어드민까지 이미 완벽하게 개발이 되어 있고 퍼블리셔와 배포 담당 부서가 따로 있었기 때문에 약관이 바뀔 때마다 앱을 다시 배포해야 되는 케이스가 있는지도 몰랐다. 아니, 사실 관심을 갖고 알려고 하면 알 수 있었는데 그럴 필요가 없었다. 몰라도 누군가가 챙겨주고 잘 돌아갈 수 있게 시스템이 되어 있기 때문이다.
하지만 이번에 앱을 하나 새로 만들면서 웹뷰로 띄울지 네이티브 화면에서 보여줄지도 결정해야 했고, 웹뷰로 띄우더라도 약관 파일을 어떤 방식으로 보여주고 어떻게 관리하느냐에 따라서 매번 약관 파일이 바뀔 때마다 앱 배포가 필요한지 여부도 달라진다는 걸 알게 되었다. 모바일에서도 읽기 쉽도록 본문 text를 웹뷰로 보여줄 거면 서버에서 약관 text 내용을 dropdown list에서 매번 바꿔 주는 대신 앱 배포는 불필요하고, 고객이 읽기는 힘들겠지만 pdf url 로 띄워주면 고객이 약관 파일을 pdf로 다운로드할 수도 있고 url이 변경될 때마다 앱을 다시 배포해야 되는 이슈가 있었다. 매번 파일명을 동일하게 맞춰서 url 이 변경되지 않도록 하면 앱 배포가 필요 없다는 것도 알게 되었다. 약관을 고객이 한글자씩 읽어보기 보다는 필요한 경우 pdf 로 빠르게 다운받고 동의 후 넘어가길 원한다는 점을 고려하고, 앱 배포 일정에 맞춰 현지법인에서 약관 파일을 시기 적절하게 매번 받아오는 일이 쉽지 않겠다는 판단이 들어서 앱 배포가 필요없는 pdf url 방식으로 결정했다.
앱 데이터도 이미 GA360 과 splunk 등을 통해 분석할 수 있도록 지표가 설계되어 있고 마케팅 부서에서 분석하는 사람이 따로 있었기 때문에 그때는 마케팅 부서가 아니면 그 툴들을 그렇게까지 다룰 줄 몰라도 된다고 생각했다. 은행이니까 대부분은 쿼리를 돌리면 수치를 볼 수가 있었고 이미 업무용 툴들이 개발되어 있어서 쉽게 데이터를 뽑을 수 있었다. 그런데 이것 역시 앱을 하나 새로 만들면서 이벤트를 심는 것부터 관여하다 보니 GA4를 깊이 있게 모르면 설계 자체를 할 수가 없는 거다. 다행이 스타트업에 있을 때 프로덕트에 중요한 지표가 뭔지는 어느 정도 익혔기 때문에 무엇을 분석해야 할 지를 정할 때는 조금 수월했지만, 이번에 이벤트 정의서도 처음 만들어 보고, 로그를 심을 때 어떤 노가다(?) 작업이 필요한지도 알게 되었다.
특히 이번에는 전 회사의 마케팅 담당자분에게 읍소해서 주식 앱의 경우 퍼널(funnel)을 어떻게 정의해야 할지 조언을 구하고 적용하는 과정에서 많은 걸 배웠다. 계좌 개설처럼 단계가 명확한 경우에는 퍼널을 정의하기가 비교적 쉽다. 하지만 주식앱의 경우 종목을 탐색(검색 혹은 발견)하고, 주식 현재가 화면을 통해 정보를 조회하고, 관심종목 리스트에 추가하고, 주문을 하기까지의 여정이 linear 하지 않기 때문에 매출에 가장 큰 영향을 미치는 '주문' 액션의 전환율을 위주로 측정을 하고 앱 출시 후 지표가 떨어지는 구간이 생기면 추가적으로 퍼널을 정의해서 분석할 수 있다는 걸 알게 되었다. 언뜻 보면 이커머스와도 비슷한 구석이 있는 것 같다. 물품을 탐색(검색 혹은 발견)하고, 물품 상세 페이지를 통해 정보를 조회하고, 찜하기를 누르거나 장바구니에 담고, 주문을 하기까지의 여정! 어쩌면 이커머스 기획자 분들은 이런 류의 퍼널 분석에 익숙하겠구나 하는 생각이 든다. 관련 글들을 좀더 읽어봐야 겠다.
2. 커뮤니케이션 할 때, 개발지식이 부족해서 생각의 방향이 틀린 경우가 있다
기획자(PM)으로 일하면서 가장 필요한 스킬은 커뮤니케이션 스킬인데, 이것처럼 정의하기 어려운 게 또 있을까 싶다. '커뮤니케이션을 잘 한다', '커뮤니케이션이 원활하다'는 게 어떤 걸 의미하는 지도 일하면서 주변에 나보다 잘하는 사람이 없으면 알기 어렵다. 내가 잘 하고 있는지, 어떤 면에서 부족한지도 그걸 잘 보는 사람이 옆에서 일러주지 않으면 알기 어렵다. 그래서 스스로 '아, 이게 부족해서 안됐구나. 다음에는 이렇게 하면 더 수월하겠다.' 하고 깨닫는 순간이 오면 그렇게 반가울 수가 없다.
이번에 일하면서 포커싱했던 건 '커뮤니케이션 비용을 줄이자' 였다. 개발자가 뭘 말하면 최대한 빨리 알아듣고, 최대한 개발자가 설명해야 할 것과 공수를 줄여줘서, 빠른 결정으로 편안하게 해주는 것. 그러면서 단편적으로 느꼈던 건 개발지식이 부족해서 생각의 방향이 틀릴 수 있다는 거였다. 에러코드에 대한 기획을 하면서 처음에는 유저플로우와 화면에 보여지는 문구만을 생각했었다. 하지만 서버에서 직접 문구를 내려주는 게 더 효율적인 케이스가 있다는 걸 알게 되었고 백엔드 에러메시지를 따로 정의하게 되었다. 이때, 서버에서 내려줄 문구가 확정되지 않은 상황이었다. 원래 정의된 문구를 클라에서 갖고 있다가 서버에서 에러코드에 따라 조건부로 띄우는 걸로 되어 있었기 때문에 나는 문구가 확정되고 나서 서버에서 내려주는 걸로 변경하는 게 낫다고 생각을 했었다.
그런데 클라 개발자와 한번 더 얘기해 보니 서버에서 문구를 내려주는 걸로 설계/코딩을 변경하게 되면 그에 맞는 클라 작업이 또 변경이 되기 때문에 두번 일이 된다는 거다. 그래서 문구가 바뀌더라도 서버에서 문구를 내려주는 걸로 변경하는 작업을 미리 해두는 게 좋다고 했다. 예를 들어 서버에서 문구1과 문구 2의 케이스를 나눠서 내려주면 클라에서는 팝업으로 띄울지 입력필드 아래의 알럿으로 띄울지, 무슨 색으로 몇초 동안 표시할지, 어떤 폰트로 띄우고 어떤 버튼을 누르면 사라지게 할지만 코딩해서 보여주면 된다는 거다.
아차 싶었다. 테스트를 할 때도 서버에서 에러코드만 내려줄 때는 클라에서 에러코드 반영하는 작업이 안되어 있으면 에러코드가 그대로 보이는 현상이 발생하는데, 그걸 통해서 이런 내용이 당연할 거라고 순간적으로 유추하지 못한 거다. 예전에 누군가가 '클라는 서버에서 내려주는 대로 보여주는 건데 무슨 작업이 필요해' 라고 한 적이 있는데 이건 클라가 작업을 다 해두고 API format이 전부 정해져 있는 상태에서 서버에서 API 에 들어가는 데이터만 살짝 바꾼다거나 하는 맥락에서 이야기한 거였고..
이런 작은 오해들이 커뮤니케이션을 방해한다는 걸 알게 됐다. 이 작은 오해가 왜 쌓였을까, 를 생각해 보면 우선 비슷한 원리로 돌아가는 상황인데 다 다르다고 생각한 게 문제다. 서버와 클라이언트 간 API 로 통신을 한다라는 큰 틀만 알고 있으면 되는 게 아니라, API 로 어떻게 통신을 하는지 어디까지가 서버의 작업이고 어디까지가 클라이언트의 작업인지를 좀더 명확하게 개념적으로 알고 있어야 여러 비슷한 상황에 적용이 되는데 너무 큰 대전제만 생각하고 적용을 못한 거다. 혹시 설마 IQ의 문제인가? 그럼 학벌 좋은 사람만 기획자(PM)을 해야 된다. 이런 식의 사고를 더 잘할 수 있도록 트레이닝 하는 방법이 분명 있을 것 같다. 나도 나름 공부 많이 하고 책 많이 읽었지만 타고난 게 아니라면 일부러 트레이닝 해야 되는 영역인 것 같다. 앞으로도 비슷한 상황에서 동일하게 유추할 수 있도록 노력해야 겠다고 생각했다.
내가 못 알아들었는데 알아들었다고 생각하고 진행하는 것도 문제였던 것 같다. 이건 일을 진행시켜 보기 전에는 알기가 무척 어려운 부분인데, 어느 정도 수준에 다다를 때까진 내가 이해한 대로 되묻거나 내가 어떻게 처리할 거라는 걸 두려워하지 말고 얘기해야 겠다는 생각이 들었다. 이번 케이스도 내가 '이러이러하게 이해했으니까 이렇게 처리할게요' 라고 짧게라도 얘기를 했기 때문에, 친절한 개발자분이 상세하게 설명을 해준 케이스였다. 어디까지나 "친절한" 개발자분이기 때문에 설명해준 거였다.
상대방이 바쁘고 귀찮고 나랑 친하지도 않다면 설명은 커녕 '이런 것도 모르세요?' 라고 하겠지만, 내가 경험이 부족하거나 몰라서 개발자의 리소스를 빼앗는 거나 마찬가지니 그 정도는 감수해야 하는 것 같다. 개발자 입장에서도 이런 거 척척 알아서 알아듣고 처리해서 정리해주는 기획자(PM)이랑 일하는 게 당연히 편하지 않을까? 다만 내가 경험이 부족해서인지 아니면 상대 개발자의 개발이나 커뮤니케이션 스타일의 문제인지 판단이 될 때까지 계속 누적해 가면 되는 거다. 얼마 전에도 생각했지만, 1등이 되어야 할 필요는 없다. 50% 안에 드는 준수한 기획자(PM)이 되는 것도 쉽지는 않고 그 정도를 목표로 겸손하게 차곡차곡 쌓아 가면 된다.
3. 사용자도 고려해야 되지만 개발 편의성도 고려해야 한다
당연히 사용자는 중요하다. 하지만 개발팀 리소스를 줄이는 것도 중요한 일이다. 동일한 노력으로 더 큰 효과 - 더 많은 매출 - 를 올릴 수 있는 방향으로 기획하는 것도 중요한데, 구체적으로 어떤 케이스에서 그랬는지 기록해두면 좋을 것 같다.
동일한 UI 로 개발할 수 있는 건 최대한 케이스별로 나누지 않고 동일하게 해준다. 예를 들어 차트를 터치했을 때 보여주는 데이터가 라인차트와 캔들 차트 2가지 경우에서 각각 5개와 6개라고 하면, 동일한 UI 로 개발할 수 있도록 디자이너와 고민해서 틀을 맞춰주는 거다.
동일한 UI 에 데이터 range만 다른 경우, 데이터 range를 맞추는 것도 방법이다. 예를 들어 거래소별로 장 운영시간이 다른데 차트 UI 는 동일하다면, 장 운영시간 별로 차트를 다르게 그리기 보다는 사용자 입장에서 데이터를 인지하는 데에 불편함이 없다면 모든 거래소에 대해 동일한 시간 range에 차트를 그리면 클라에서 할 일이 줄어든다. 어떤 거래소에 대해서는 장이 비교적 일찍 끝나기 때문에 종가가 수평선으로 그려지겠지만, 그 종가는 내일의 시작가와 비교해 참고하는 지표가 되기 때문에 사용자 입장에서 불편함이 없다.
4. 여러 채널을 운영하고 있는 서비스의 경우, 채널 간의 정책을 고려해야 한다.
은행/증권사 모두 비슷하지만, 오프라인 지점과 mts(app), wts(web) 을 모두 운영하고 있는 경우 더더욱 채널 간의 정책에 신경써야 한다. 이번에 내가 경험했던 건 채널 간의 '정책'뿐만 아니라 백엔드 로직도 정확하게 파악해야만 한다는 거였다. 기존에 운영하는 채널들 중에서 일부만 새롭게 개편하는 프로젝트이기 때문에, 기존에 운영하는 채널들의 백엔드 로직이 새로운 앱과 합쳐지는 건지 따로 가는 건지에 따라서 채널 간 정책을 통합할수도, 분리할수도 있는 거다.
그런데 기획을 하면서 '정책'만 바라보다 보니 기존 채널 서버와 새로운 채널 서버 간에 통합적으로 체크가 안되는 마이크로 서비스들이 있다는 걸 뒤늦게 알게 되어 개발했던 걸 걷어내는 일이 발생했다. 리소스도 너무 아깝고 팀원 분들에게 미안했다. 만약 이런 사실을 미리 알았더라면 채널 간의 정책이 따로 갈 수 있는지 현지에 먼저 협의 요청을 했을 텐데 그러지 못했기 때문에 발생한 일이였다. 어떤 정책은 새로운 채널만 따로 가져가도 문제가 없지만, 이번 경우는 비밀번호 오류 체크에 관한 것이어서 CS에 문의도 올 수 있고 운영이슈도 있어 불가능한 케이스였다. 기존 채널을 활용해서 개발하는 걸로 변경해서는 해결되지 않는 문제였다.
다음번에 동일한 일이 발생하지 않게 하려면, 기획을 할 때 아예 새로운 걸 기획하는 게 아니라면 기존 시스템이 어떻게 되어 있는지 정책/유저플로우/운영이슈/백엔드 로직까지 복합적으로 파악하고 방향성을 정하면 될 것 같다. 다행인 건 이런 걸 새로 깨우쳐나가는 게 즐겁다는 거다. 복합적인 사고를 해야 되거나 어려운 문제를 해결해야 되는 게 나한텐 부담스럽기 보다는 도전하고 싶은 일이라서 그렇다.
얼마 전에 큰 충격을 받았던 영상이다. 토론대첩에 전여옥 전 국회의원이 나와서 커리어 때문에 결혼을 하지 않겠다는 고려대 여대생에게 일침을 날리는 장면. 본인은 애를 낳는 게 커리어에 전혀 지장이 없었다고, 아직 어떤 커리어를 쌓아나갈 수 있는지도 모르는 상황에서 애를 낳지 않겠다고 단정짓는 건 무모하다는 것.
나도 결혼 전부터 막연한 두려움이 있었다. 친정에선 돌봐줄 여력이 안되니 시댁에서 돌봐주지 않는 한 직장 다니며 아이 키우는게 어렵겠지, 라고 막연히 생각했었고 결혼을 해보니 우리 시댁은 아기를 봐주시기 어려운 상황이다. 아니, 봐주실 수 있고 봐주시겠다고 말씀 하시더라도 4남매에 손주들까지 돌보느라 몸이 성한 곳이 없으셨던 친할머니를 생각하면 맡기고 싶은 마음이 없다. 그래서 은행을 퇴사하기 까지 고민이 많았다. 아이 한 명당 3년의 육아휴직, 난임휴직 등의 엄청난 여성향 복지들..
하지만 지점에서 일하는 게 적성에 맞았더라면 하지 않았을 퇴사 고민을 이미 예전부터 하고 있었고, 악착같이 본사를 가기 위해 노력하다 보니 결국 본사에 갔고, 거기서 내 적성을 찾아서 이직도 했다. 스타트업에 있었을 때 임신을 했었다면 그것 때문에 직장을 그만두었을까? 지금 되돌아보면 어떻게든 방법을 찾았을 것 같다. 법정 육아휴직만 주는 기존의 스타트업 보다는 육아휴직을 더 길게 쓸 수 있는 대기업으로 왔지만 주어진 육아휴직 기간보다 더 짧게 쓰려고 계획하고 있다. 스타트업에 있었으면 더 짧게 쓰고 복직을 했겠지만 그건 어디까지나 응급상황을 위해 남겨두는 거였을 거고, 남겨둔 육아휴직을 모두 소진하고 나서 복직이 어려워 졌다면 재택근무가 가능한 회사를 찾아 무한 지원했을 거다.
그마저도 안된다면 지인을 수소문해서 어떻게든 일자리를 찾았을 거고, 그것도 안되면 프리랜서를 했을 것 같다. 그마저도 안된다면 스마트스토어든 작은 동네 공부방이든 사업자를 내고 무언가를 했을 거다. 어디까지나 내가 '일하고 싶은 마음이 그만큼 크기 때문에' 상황에 맞춰서 꼭 정규직 직장이 아니더라도 무언가를 해서 작든 크든 경제적 가치를 창출하며 살았을 거라는 거다.
어쩌면 전여옥 전 의원은 친정에서 아이들을 온전히 봐주셨기에 지금의 커리어가 가능했을 수 있다. 아니, 요즘 워킹맘들은 친정이나 시댁 도움 없이 온전히 아이들을 키워내기가 어려운 게 현실이긴 하다. 하지만 전 전 의원(?) 이 날카롭게 지적했듯이, 커리어라는 거창한 단어로 뭉뚱그려서 결혼을 하지 않겠다 혹은 아이를 낳지 않겠다 라고 결심할 필요는 없다고 생각한다. 지금 하고 있는 일을 5년 뒤에도 하고 있을지 모르는 일이고, 인생은 계획대로 흘러가지 않더라. 본사에 가기 전까지는 이직하게 될 줄 몰랐고, 이직을 하기 전에는 다음 스텝이 없을 줄만 알았다. 만약 본사도 못가고 이직도 못했다면 언젠가는 퇴사를 하고 또 다른 일을 찾았을 것이다.
'내가 사랑하는 사람과 가족을 이루고 싶은지', '아이를 낳으면 내가 행복할지', '행복한 아이로 키울 수 있을지(경제적 요건이나 정서적 요건)' 가 더 중요하다고 생각한다. 인생의 우선순위도 정립되지 않은 상태에서, 단순히 '나는 대학을 나왔고 그렇기 때문에 공부한 게 아까워서 커리어를 쌓아야 되고, 그러려면 애를 낳으면 안되겠다'는 매우 안타까운 사고방식이라고 생각한다. 나는 행복이 중요하고, 그걸 위해 행복한 가족을 이루는 게 삶의 1순위라서, 그걸 위해서 남편과 같이 상의하고 맞춰 나가면서 모든 걸 해나가고 있다.
나는 요리도 잘 못하고 집안일에 별로 소질이 없어서, 직장생활을 하며 내가 잘 못하는 집안일을 돈으로 적절히 해결하면서 살아가는 게 더 행복하다. 다행이 일하면서 스트레스도 물론 받지만 조금씩 나아지는 기분이 좋다. 그래서 계속 그렇게 살아가기 위해서 다양한 노력들을 한다. 결혼 전에는 월급을 타면 작고 이쁜 쓰레기들을 사서 쓰는 재미로 사는 맥시멀리스트 였지만 결혼 후에는 틈만 나면 옷장을 정리하고 옷도 물건도 덜 사고 있다. 어질러진 집안을 치우는 데에 쓸 에너지를 일하는 데에 쓰기 위해서다. 야근도 줄이려고 노력한다. 할 일을 덜 하고 퇴근하는 게 아니라, 근무시간에 우선순위를 가지고 시급하고 중요한 일부터 빠르게 해결하고, 문제가 되지 않도록 해 둔다. 퇴근하고 부부가 함께 있는 저녁 시간만큼은 직장에서의 스트레스를 끌고 오지 않고 도란도란 대화를 나누며 즐겁게 보내기 위해서다.
아기가 태어나도 이런 노력들은 똑같이 계속될 거다. 내가 행복하려고 결혼했고 아이도 가졌다. 그러니 복직하기 전에 미리 아이를 어린이집에 보내 적응시키고, 나도 운동을 열심히 해서 건강한 몸과 마음으로 복직 준비를 해야지. 물론 내가 집안일에 소질이 있었다면 아이를 집에서 온전히 케어하며 전업주부로 사는 게 아이에게는 가장 좋은 환경이었겠지만, 그건 소질이 있는 사람들의 이야기이고 나는 아니다. 나는 일을 하면서 내 체력과 멘탈 케어를 하며, 아이에게 직접 해줄 수 없는 걸 돈과 정보력으로 해결하는 엄마가 될 거다.
그리고 아이가 어린이집에 적응을 못하거나, 시터를 못 구하거나, 사무실이 멀리 이전을 하거나, 갑자기 해외로 나가야 하는 등의 변수는 당연히 항상 생길 수밖에 없는 것이니 마음을 편하게 먹으려고 한다. 아이가 적응을 못하면 다른 어린이집을 알아보거나 입주시터를 구할 거고, 사무실이 멀리 이전을 한다면 잠시 멀리 출퇴근을 하거나 회사 근처로 이사를 갈 수도 이직을 할 수도 있고, 갑자기 해외를 나가게 되면 리모트워크가 되는 회사로 이직하거나 잠시 일을 쉴 수도 있다. 상황은 언제나 주어질 것이고, 방향성만 명확하다면 내가 할 일은 그 상황에 대응하는 것이다.
내가 지금 할 수 있는 건 미리 이력서와 포트폴리오를 업데이트 하는 거다. 복직 후에 기억을 살려내는 데에 도움이 될만한 업무 일지도 써보고, 영어공부도 해두고 면접 질문과 답변들도 미리 적어 본다. 그리고 앞으로 생길 변수들이 이직을 하거나 직장을 그만둘 정도로 심각하지 않다면 당연히 지금 회사에서 더 밀도 높게 일을 계속하고 싶다. 중요한 건, 어떤 상황이 주어져도 나는 거기에 맞게 대처하면서 잘 살아갈 거라는 것. 어떤 변수가 생기더라도 그 상황 안에서 나와 가족이 행복하기 위한 최선의 선택을 할거라는 거다.
