이름 없는 회사원
우리는 직업을 많은 이름으로 부른다.
전문직들은 고민 없이 단번에 답한다.
의사 변호사 회계사 약사
회사원들도 운이 좋으면 이름이 생긴다.
마케터, 개발자, 기획자, 애널리스트.
우리는 그걸 직무라고 부른다.
근데 대기업에 신입 공채로 입사를 하면
많은 것들이 희석된다.
회사가 필요한 곳에 적재적소로 쓰이는 존재가 된다. 규모가 클수록 한 가지 업무도 여러 부분으로 쪼개어 여러 사람이 나눠서 하고, 협력사와 외주업체를 끼고 일을 하다 보면 내 역할은 희석되고, 현장과 멀어진다.
내가 어떤 회사원이 되고 싶은지
스스로 결정할 수 있는 힘은 줄어든다.
나도 그랬다. 내가 하는 일이 뭔지 스스로도 설명을
못하겠다는 답답함에 부서 이동을 결심했다.
목표는 하나였다. 회사 안에서만 통하는 일이 아니라, 회사 밖에서도 알아들을 수 있는 일을 하는 것.
그 목적 하나로 조직 이동 후 새 팀
첫날 인수인계를 받으면서 든 생각은 하나였다.
나 여기서 살아남을 수 있을까.
제조업 베이스의 우리 회사가 처음으로
플랫폼 기반 서비스업에 뛰어들던 시기.
내가 담당한 프로젝트는 유럽시장에 구독 PoC를 론칭하는 것이었다.
모르는 단어가 너무 많았다.
보고서에 한자를 섞어 만들던 부서에서 (세종사투리st)
갑자기 판교어를 유창하게 구사하는 사람들과
일하려니 여간 힘든 게 아니었다.
출처 : @gggg_touch배포, 스프린트, 요건 정의, QA,
스테이징 서버, 지라, 컨플…
사수가 설명을 해주는데 단어 하나가 이해되면
다음 단어가 막혔다. 챗지피티가 나오기 전 시절이라
아주 원론적으로 구글에 IT 프로젝트 방법론부터
비전공자를 위한 IT 지식 같은 류의 책을
찾아 읽는 등 다시 신입으로 돌아간 기분이었다.
은근 도움을 많이 받은 고마운 책...
포지션도 묘했다.
우리 팀은 본사이면서 사업 조직이었다.
개발팀 입장에서 우리는 "사업 쪽 사람"이었고,
해외 법인 입장에서 우리는 "본사 사람"이었다.
개발과 해외 법인 사이 어딘가에 껴있는 존재.
양쪽 언어를 다 알아야 하는데,
나는 어느 쪽 언어도 제대로 몰랐다.
그러다 사수가 갑자기 퇴사했다.
내가 아직 개발 프로젝트 전체 흐름을 파악하지도 못한상태에서, 새로운 시장 런칭을 메인으로 맡아야 했다.
해외 법인에서 요건이 올라오면
이게 정말 필요한 요건인지 판단이 안 됐다.
개발팀에서 "이건 구현이 어렵다"라고 하면
정말 어려운 건지, 협상의 여지가 있는 건지,
쌩문과에게는 너무나 어려운 주문이었다.
반면에 법인에서는 조금만 불리해도
이건 법적요건이니 안들어줬다 문제 생기면
본사가 책임질거냐는 무기를 자주 사용했다.
의심의 눈초리그래서 일단 다 들었다. 법인 요건도 다 들었고,
개발팀 얘기도 다 들었다. 모르면 바보처럼 보여도 다시 물어봤다. 회의가 끝나면 혼자 정리하고, 또 모르면 또 물어봤다. 그렇게 런칭을 했다.
런칭 직후에 신원 확인 시스템이 안 먹혀서
고객 가입이 줄줄이 거절되거나, 마케팅 캠페인 링크 설정이 잘못되어 트레킹이 안된다거나..
그런 오류들이 줄줄이 생겼고 시차 때문에
퇴근 후는 물론이고 새벽에 연락 오기가 일쑤였다.
문제가 터져 연락이 오더라도 난 개발자가 아니어서
문제를 직접 해결할 수는 없었지만
현상, 진행경과, 원인, 재발방지를 정리하며
이것 또한 나의 기능임을 알게 되었다.
어려움도 목적도 없는 일을 하며 듣는 칭찬보다
새로 배우고 부족함과 개선의 여지들을 직면하면서
눈으로 보이는 무언가를 만들어나가는 일은
뭐라 이룰 수 없이 즐겁고 세계가 확장되는 경험이다.
여러모로 부족했지만 서툰 시작을 기억해 주는 분들과 아직도 각자의 위치에서 좋은 동료로 지내고 있다.
그렇게 첫 서비스를 런칭하면서 세 가지를 깨달았다.
첫 번째. 해외영업팀에서 보낸 시간이 무의미하지 않았다.
그때는 물경력이라고 생각했다. 근데 신사업 조직에 와보니 오히려 반대였다. 나는 수많은 해외 법인을 돌아다니면서 이 회사가 돈을 어떻게 버는지, 각 시장의 이해관계가 어디에 있는지를 몸으로 알고 있었다. 주재 경험 있는 선배들이 현장에서 몇 년 걸려 배운 걸 압축해서 다운로드받은 것이었다. 개발 조직과 신사업 조직에서 그게 오히려 환영받는 포지션이었다.
두 번째. 개발을 모른다는 사실은 생각보다 치명적이지 않았다.
코딩을 못 한다. 아키텍처를 모른다. 그래도 프로젝트는 결국 사람끼리 하는 일이다. 요건을 정리하고, 우선순위를 잡고, 이해관계를 조율하고, 런칭까지 끌고 가는 것. 거기에 개발 실력이 필요한 게 아니었다. 오히려 개발팀 언어와 법인 언어를 공통의 언어로 번역해 주는 것. 그게 내 역할이었다.
세 번째. 다음 스텝은 국내 서비스다.
해외 프로젝트만 계속하다 보면 결국 서비스 운영 단에서 직접 고객을 만나고 데이터를 보는 건 제한적이었다. 다음엔 직접 데이터를 보고, 직접 고객 반응을 듣고, 그걸 서비스에 반영하는 경험을 해야겠다고 생각했다.
그렇게 국내 서비스 팀으로 옮겼다. 직접 테스트하고, 고객 VOC도 처리하고, 쿠폰도 발행하고, 프로모션도 기획했다. 그 사이에도 내 직무의 이름은 계속 바뀌었다. 어떨 때는 기획자, 어떨 때는 서비스 운영, 어떨 때는 PO, 때로는 PM.
제조업 베이스 회사에서 IT 프로젝트 직무의 이름들은 여전히 생소했기에,
다른사람은 물론이고 나도 자신 있게 뭘 한다고 말하기 어려웠다.
(최대 OO 서비스 담당자가 최선이었으나 생각해보면 이것도 해외영업 시절에는 OO 담당이라고 할만한 이름도 없었던걸 생각하면 많은 발전이었다)
그렇게 이런저런 서비스와 프로덕트를 담당하며 5년이 지났고, 어느 날 회사 안에서도 전무후무한 대형 프로젝트의 PM이 되었다.
나의 주니어 시절을 돌아보면 이 말이 가장 어울린다.
흘러가지 말고 헤엄쳐라.
예전 팀장님이 종종 하시던 말씀이다. 형태는 중요하지 않다. 이직이든, 대학원이든, 창업이든, 아니면 처음 들어간 회사에서 진득하게 버티는 것이든. 지금 내가 하는 일이 그 직전의 일과 어떻게 연결되는지, 내가 이 일로부터 무엇을 얻고 싶은지, 왜 하는지를 알고 있다면
— 그에 맞는 이름은 구슬을 꿰기 나름이다. 이름이 없다고 해서 하는 일이 없는 게 아니다.
다음 편에서는 이 정도면 됐다고 생각했을 때, 조금 늦게 찾아온 위기에 대해 써보려고 합니다.