인하우스 기획자가 되었다.
에이전시에서 퇴사를 결심
어느덧 올해를 지나 내년까지 단 한 달도 채 안 남은 시간, 최근 세 달은 바쁘다는 핑계로 나를 속이며 쓰지 못했던 글들이 올해가 가기 전에 얼른 쓰라며 재촉한다.
바빴던 최근 세 달 동안 나는 이직을 준비했고, 인하우스에 이직을 성공했다.
이직을 할 수 있었던 요소에는 운도 있었지만, 노력도 있었기 때문에 그나마 부끄럽지 않게 [인하우스의 기획자로 취직하기]에 대해 경험한 것들을 글에 담아보려고 한다.
첫 글의 주제가 '에이전시에 취업 준비하기'였는데 이제는 '인하우스로 취직하기'라니... 여전히 주니어지만 준비하는 나의 마음가짐은 시니어 못지않았다.
목차
에이전시를 퇴사하게 된 계기
인하우스 이직 준비
ㄴ 채용공고 정리
ㄴ 에이전시 경험
ㄴ 포트폴리오
ㄴ 면접 준비
최종 합격
에이전시를 퇴사하게 된 계기
워라밸보다 업무 만족도
기획을 포함한 IT 실무 경험이나 지식이 전혀 없었던 당시 나는 구글링으로 얕은 정보들을 얻었고, 핀테크에 대한 전반적인 이해와 공장식 업무를 통한 빠른 IT 실무 경험을 얻고자 금융권 프로젝트를 주로 수행하는 에이전시에 입사했다. 우려와 달리 적었던 야근과 업무강도는 워라밸이라는 용어가 무색하게 나를 유혹하지 못했고, 업무 만족도는 나의 기대에 미치지 못했다. 그리고 결국 이직을 결심했다.
에이전시에서 배운 것
기획자의 직업병문서 관리
History check
개발자는 언어로, 디자이너는 그림으로 업무를 진행하는 것처럼 기획자는 문서로 일한다. 문서는 입으로도, 문서로도 전달이 되어야 한다. 내부 보안망이 필수로 깔려 있고, 고객사와 대면하기 어려운 대기업 금융권의 프로젝트를 진행하다 보니 프로젝트 진행에 필요한 기획자의 업무는 대부분 문서로 작성되어 이메일이나 메신저를 통해 전달된다. 그렇다 보니 크고 작은 문서를 작성할 때는 [문서명, 날짜, 이름]을 적는 게 습관이 됐고, 이는 나아가 서비스나 프로덕트를 관리함에 있어 History check를 효율적으로 하는데에 도움이 되었다.
기획 문서 작성
앞서 말했듯 프로젝트 내 거의 모든 문서는 기획자가 작성하기 때문에 RFI, 요구사항정의서, WBS, IA, 화면설계서, 단위/통합테스트 시나리오 등 업무에 필요한 문서를 경험할 수 있었다. RFI나 WBS의 경우 사업 및 전략 기획 혹은 PM(Project Manager)이 담당하기 때문에 직접 작성하기 어렵지만, 완성된 문서를 보는 것만으로도 왜 작성해야 하는지, 어떻게 작성하는지 이해할 수 있었다. 기획자는 다양한 기획 문서를 활용하여 서비스나 프로덕트의 시작부터 끝까지 적재적소에 활용하여 포지션별 담당 실무자와 구현해야 할 목표 간의 이해도를 맞출 수 있어야 한다.
커뮤니케이션
기획자 채용 공고에서 가장 많이 보이는 요구 역량이다. 기획자의 커뮤니케이션이라 하면 디자인 또는 개발 지식을 활용해 유창하게 소통하는 것을 의미하는 게 아니다. 다양한 이해관계자들이 서비스나 프로덕트를 제대로 구현할 수 있게끔 상호 원만하게 소통하는 것을 의미한다(물론, 다양한 지식을 활용한다면 더 수월할 것이다). 나는 담당자들에게 메일이나 문서를 전달하고 나면 반드시 자리로 찾아가 말로 한 번 더 전달하는 습관을 만들었고, 쓸모 있는 대화를 하며 그들의 업무에 걸림돌이 없도록 노력했다. 나아가 점심시간이나 쉬는 시간에도 하소연을 들어주거나 안부를 묻기도 했다. 이러면 업무 상의 커뮤니케이션에도 긍정적인 영향을 줄 수 있을 거라고 생각했고, 실제로 이렇게 만들어진 좋은 커뮤니케이션의 결과는 그렇지 못한 커뮤니케이션 결과로 인해 발생하는 이슈를 감당하는 것보다 훨씬 많은 이득을 보게 해 줬다.
테스트
그러나 부딪힌 현실의 벽
각자 다른 방향으로 나아간다고민의 부재
에이전시는 대체로 고객사의 예정 프로젝트를 수주받아 진행하며, 이에 상응하는 비용을 지급받으며 수익을 창출한다. 따라서 대부분의 프로젝트는 고객사의 RFP에 기반하여 WBS를 작성하고 이에 따라 진행하게 된다. 즉, PM을 떠나 설계 단계의 업무를 주로 맡는 기획자인 나는 고민할 필요 없이 고객사에게 전달받은 내용을 그대로 문서에 옮겨 작업하기만 하면 됐다. 경험한 3개의 프로젝트 모두 같은 방식으로 업무를 진행하다 보니 문득 '나는 화면 설계하는 기계인가?'라는 생각이 들었고, 그 끝에는 '왜 화면을 이렇게 설계한 걸까?'라는 스스로에 대한 물음이 많아지기 시작했다.
고민의 구현 가능성 0%
고민의 부재로 오는 현타를 해소해보고자 설계한 화면에 대해 스스로 피드백을 하거나, 혹은 고객사의 니즈에 맞는 화면을 설계해보기도 했다. 분명 이런 고민은 내 업무 관점을 수동에서 능동을 바꿀 수 있었다는 점에서 일부 해소가 되었지만, 프로젝트의 공수 및 일정이 정해져 있는 에이전시에서는 현실적으로 내 고민들이 프로젝트에서 구현되기란 여간 쉬운 일이 아니었다. 스스로 성장하고자 발버둥 쳤던 나는 현실의 벽에 부딪혀 양 옆을 둘러봤고, 결국 나만 발버둥 쳤다는 사실을 알게 되었다.
K - 워터폴의 한계
워터폴은 프로젝트의 시작부터 끝까지 순서에 따라 개발이 이루어지는 방법론이다. 보통 [분석 - 설계 - 구현 - 테스트 - 배포]의 단계를 나누어 해당되는 담당자가 업무를 순차적으로 진행하게 되는데, 적어도 설계를 한 기획자는 모든 단계를 이해하고 이슈 발생 시 피해를 최소화할 수 있도록 대응해야 한다. 하지만 내가 경험한 프로젝트에서는 기획자를 포함하여 디자인/퍼블/개발 모두 프로젝트가 아닌 각자의 업무만을 하는 느낌이 들었다. 오는 업무는 밀고 가는 업무는 당기지 않았다. 분명 팀으로 프로젝트를 시작했는데 개인 프로젝트를 마무리하기 위해 일하는 것 같은 이 모습들은 워터폴의 부작용이 아닌 에이전시의 부작용이라고 생각했고, 이직을 결심하게 된 결정적인 이유가 되었다.
이외에도 1년 6개월이라는 기간 동안 위에 적은 내용보다 훨씬 많은 것을 배우고 느꼈다. 물론 부정적인 요인이 더 많았기 때문에 이직을 결심했었던 것은 사실이다. 노골적으로 말하자면 '이러고 있다가는 도태되고 말 거야'라는 생각이 들어 정신이 번쩍 들었고, 환경은 나를 집어삼킬 수 있는 아주 무서운 존재라는 것을 깨달았다(네트워킹 드리븐의 조건이 '자신보다 뛰어난 사람'인 것의 이유를 알 수 있었다).
다음 글에서는 이직할 때 서류 및 면접 과정을 겪으며 내가 가진 경험이 인하우스에서 어떤 퍼포먼스를 낼 수 있는지, 부족한 부분은 어떻게 보완했는지를 적어보려고 한다.
