이직의 이유

글을 정리하기는 작년 10월 15일. 퇴사 한 달도 더 전에 써놓고서는 이제야 마무리를 지어본다.

회사에 들어가기는 2014년 6월 중순. 모멘티 파일럿 개발을 하고 있을 때 소프트웨어 마에스트로 과정에서 멘토셨던 대표님으로부터 연락이 왔고, 클라우드 R&D라는 관심이 가는 주제였기에 모멘티 파일럿이 끝나고 입사하게 되었다.

1년 5개월, 경력으로 보았을 때는 그리 길지 않은 시간이지만 많은 분들을 만나고, 많은 것들을 보고 배울 수 있는 시간이었다. 프로젝트를 함께 했던 분들이 다들 좋은 분들이셨던지라, 저 짧은 경력이 더 짧아지지 않고 그래도 작년 말까지는 있을 수 있었던 것 같다.

퇴사 시기를 11월로 잡은 것은 2차년도 프로젝트 과제를 어느 정도는 마무리하기 위함도 있고, 오픈 프론티어 랩(지금은 이름이 KOSS Lab으로 변경의 지원 시기가 그 쯤이기도 했기 때문이었다. 프로젝트를 진행하는 동안 개발 업무가 거의 없었고 개발 실력이 정체되어 있음을 느꼈다. 공부는 혼자서 하는 게 맞긴 하지만 회사 업무와 병행해서 관련있는 공부를 경험과 함께 하는 것과 그냥 개인적으로 공부만 하는 것에는 차이가 있을 수 밖에 없다고 본다. 그래서 오픈소스 활동을 하면서 그간 하지못한 개발 공부를 하고 싶었기 때문에 오픈 프론티어 랩에 지원했으나 서류 광탈.. 퇴사일 보다 앞서 결과 발표가 났지만, 당락 여부와 관계 없이 퇴사를 결심했던터라 예정대로 12월 1일에 퇴사했다.

어쩌면 불평 불만이 가득할지도 모르겠지만, 주어진 일들은 열심히, 잘 소화해왔고, 퇴사할 때까지도 나름 마무리를 잘 짓고 나왔다고 생각한다. 퇴사 후에 거의 한 달 동안은 반은 책임으로 반은 팀원에 대한 미안함으로 관리자 대시보드 프론트 개발을 하고 넘겨주었다. 지금 생각하면 미련하게 왜 그랬나 싶기도 하지만.. :)

어쨌든 이런 저런 것들이 쌓여 퇴사 사유가 되었던 것들을 정리해보았다. 대부분의 것들은 대표님과 지속적으로 얘기를 해왔고, 대표님도 해결을 위해 많은 노력을 해주셨지만 어쩔 수 없는 부분들이 있었다. 서로가 서로를 이해하지만 어찌할 수는 없는 상황이란 건 참으로 슬픈 듯 하다.

1. 본사 업무와의 병행

프로젝트 특성 상 참여하는 업체들과 함께 진행하다보니 본사에서 파견을 나와서 따로 마련된 사무실에서 근무했다. 사실 어디든 하나의 업무에 집중해서 할 수 있는 환경은 이상적이랄 수 있겠지만, 프로젝트가 아닌 다른 서비스의 유지보수와 VoC에 대한 대응을 했고, 기한이 정해진 업무가 있는 상태에서 서비스에 장애가 발생하거나 고객 대응을 할 일이 있을 때는 경영/기획팀에서 어느정도 커버하긴 했지만 기술적인 대응은 내가 맡고 있어서 어쩔 수 없이 처리해야했다. 기존 서비스 코드가 유지보수가 잘 되어있고 장애에 잘 대응할 수 있는 구조였더라면 좋았겠지만 처음에는 로그도 제대로 쌓이지 않아서 하나하나 찾아가야 했다. 나중에 크게 유지보수를 해서 대응을 하기 좋아지긴 했지만 우리쪽 장애 뿐만이 아니라 연동된 다른 서비스에서 발생하는 장애도 있어서 완전히 없앨 수는 없었다.

차라리 추가 개발이 있었더라면 그래도 개발이라도 할 수 있으니 괜찮았을테지만 사용자 수는 줄어가고, 본사는 다른 서비스에 집중하다보니 뒷전인 서비스가 되었고, 적은 수지만 사용자가 있었기 때문에 서비스를 유지하고 있었다. 퇴사 전 나와 다른 분들이 서비스를 정리해야한다는 의견을 냈고, 올해 말에 서비스를 종료하기로 했다.

대표님 역시 이 서비스가 회사의 아이덴테티를 가지고 있기 때문에 쉽지 않은 결정이었지만 회사의 방향성을 위해서 어렵지만 좋은 결정을 해주셨다.

거기에 더해 나뿐만 아니라 중국어를 하시는 팀원분은 중국어 번역 업무까지 맡다보니 팀원들의 불만 역시 많아졌고, 다른 이유도 있었지만 결국 그 분도 퇴사를 선택하시게 되었다.

2. 인력

2014년 6월에 이 프로젝트로 투입이 되었고, 수석급으로 계시던 분은 원래 임시로 있었기로 했기 때문에 그 분이 나가시고 연말까지 나와 다른 팀원분 이렇게 오픈 소스를 분석하고 문서화 그리고 테스트 등의 업무를 둘이서 하게 되었다. 클라우드 경험은 IaaS를 사용해본 것이 다였기 때문에 모든 것을 처음으로 했고, 같은 해 11월에 들어온 팀원 역시 신입이었다. 그리고 연말에는 이 전에 같이 일하셨던 분은 군 복무로 인해 퇴사하셨다.

그리고 다음 해 2년차 정도의 팀원이 새로 입사하셔서 팀에 합류했지만 서버 애플리케이션 개발 경험은 있지만 클라우드 경험은 없었기 때문에 다시 시작해야 하는 상황. 그 쯤해서 프로젝트의 팀장이 되어 PL업무를 수행했다. 1차년도까지는 대표님이 오셔서 PL을 하셨지만 다른 신규 서비스에 집중을 하셔야 했기 때문에 점점 이 프로젝트에 대한 팔로업이 되지 않았고, 중요한 결정사항 이외에는 내가 대부분 처리했다. 프로젝트에 참여하는 5개 업체 중 우리 회사를 제외한 4개 업체의 PL은 수석급이거나 이사, 그리고 부장이었기 때문에 사실상 심적으로 부담이 되는 부분이 많았다. 팀장으로써 PL로써 모르는 것도 많았고, 부담스러운면이 있었다. 어떻게든 책을 보고, 다른 분들의 도움을 받아 업무를 진행하긴 했지만 역량이 부족한 탓에 일정이 연기되는 일이 잦았고, 다시 부담으로 돌아오는 악순환이 이어졌다.

상급자(수석급 혹은 PL역량을 지닌)의 부재 문제로 대표님과 많이 얘기하고 사람을 구하려고 노력했지만 여러 번의 시도 끝에 결국 업무에 적합한 분을 찾지 못해 퇴사할 때까지 기존 업무를 수행해왔고 익숙하기 때문에 그대로 팀장을 하기로 합의를 하고, 3차년도부터는 파견이 아닌 본사에서 개발업무를 하기로 프로젝트 PM님과 협의를 했고, 올해 초부터는 남은 팀원들은 본사로 돌아와서 업무를 수행하게 되었다.

또한 다른 업체의 팀이 5명내지는 7~8명 정도 되는 반면에 우리는 3명이었기 때문에 사람이 부족한만큼 개인당 업무량이 자연스레 많아질 수 밖에 없었다. 물론 다른 업체들에 비해전체 업무량은 참여 인원에 비례하긴 했지만 역량이 그만큼 따라오지 못했던 부분도 있긴 했다. 하지만 R&D 프로젝트에 파견나와있는 팀원 3명을 제외한 회사 대부분의 인원들도 참여 인력으로 등록되어 있었기 때문에 인건비를 캐리하는(?) 입장에서 대우는 그만큼 받지 못한다고 느껴지기도 했다.

3. 관리업무

PL업무를 수행하면서 프로젝트의 일정, 업무 분배 등의 업무를 하고, 팀장으로서 처리하는 업무들이 많은 편이었고, R&D 자체도 개발이 많지 않았지만 관리 업무로 인해 그마저도 줄어들었다. 물론 관리 업무도 좋은 경험이었고, 내게 도움이 된다곤 생각하지만 관리 업무와 프로젝트 실무가 병행되었기 때문에 집중할 수 있는 환경이 되지 않기도 했고, 아직은 효율적인 관리를 하기에는 부족한 면이 있었기 때문에 그보다는 이를 효율적으로 할 수 있는 사람이 필요하다고 생각했다. 

어떻게 하면 일정을 업무 처리 속도에 맞게 할 수 있을지, 인터럽트가 발생하면 어떻게 처리해야할지, 개인 역량에 맞게 어떻게 업무를 분배하면 좋을지 등등의 질문을 내게 했지만  끝날 때까지도 마땅한 답을 찾지 못했던 것 같다. 지금이라면 그 떄의 업무를 다시 맡게 되었을 때는 조금은 더 나은 모습이지 않을까 생각해본다.

4. 소음

근무지가 시청과 국가인권위원회(지금은 위치를 옮김)가 인접해 있어 시위가 잦았고, 서울 광장에서는 행사가 많았다. 시위의 경우엔 처음에는 시끄럽긴 했어도 그로 인해 스트레스를 받거나 소음이라고 생각지는 않았고, 시위의 목적도 어느정도 이해가 가고 동의할 수 있는 부분이 있었다. 시위로 인해 가장 고통스러웠던 건 서울 광장에서 동성애 관련 행사가 있었는데, 해당 행사를 반대하는 기독교 단체에서 한 시위였다. 이해 관계가 얽힌 상태에서는 서로가 어느정도 합당한 주장을 하지만 이 때는 당최 논리도 근거도 없고, 앰프는 볼륨을 높이고, 하루종일 같은 소릴하고, 찬송가를 불러댄다. 그런 시위가 아침부터 저녁까지 이어진다. 다른 시위는 '소리'로 느껴졌지만 이 경우는 내게 그저 '소음'일 뿐이었다. 그게 반년을 넘게 이어졌다.

행사의 경우 대부분 저녁시간에 하긴 하지만 공연을 할 때에는 낮시간에 리허설을 한다. 저음에서 울리는 앰프는 거리가 꽤 있었음에도 불구하고 창문이 우우웅-하고 울릴 정도의 크기의 소리였다. 데시벨 기준이 어떻게 되나 찾아봤지만 주거지역이 아니었기 때문에 해당사항이 없었기 때문에 마땅히 할 수 있는 일은 없었다. 심할 때는 나 뿐만이 아니라 사무실의 모든 분들이 소리와 진동에 어이가 없어 업무를 놓고 있을 때도 빈번했다.

5. 일의 만족도와 주역할

1차년도에는 그나마 OpenShift 전체 소스코드를 분석하고 역공학을 통해 문서화를 했기 때문에 배울 수 있는 부분이 많았지만, 2차년도에는 CloudFoundry 이클립스 플러그인의 한글화 + 문서화, 그리고 관리자 대시보드 프론트엔드 재개발과 문서화 작업이었다. 관리자 대시보드는 기존 CloudFoundry의 인큐베이터 프로젝트였던  admin-ui를 분석하고, 프론트엔드를 한국 정서에 맞게(?) 재개발했다. 그나마 새로이 개발을 해서 조금은 괜찮았지만 나머지는 분석, 테스트, 문서 작업이었다. 물론 모두 필요한 요소들이지만 개발역량을 키우고 계속 해나가고자 하는 입장에서는 첫 직장에서 개발 경력이 단절된 것이나 다름없으니 나로서는 업무 자체에 만족을 하기 어려웠다. 그리고 관리업무와 환경, 그리고 잦은 회의(프로젝트 + 본사)로 인해 집중하기엔 다소 무리가 있었다.

문서작업. 좋아한다. 하지만 너무 모든 것이 페이퍼 워크다. 그래도 TTA 표준 제안서를 작성할 때는 PaaS를 활용하는 애플리케이션의 아키텍처에 대해 표준을 작성하다보니 개인적으로도 공부가 된 부분도 많았고 내가 선정한 주제다보니 그나마 오너십을 좀 더 갖고 할 수 있었던 것 같다.

6. 본사 업무 프로세스와의 괴리

프로젝트는 특성상 폭포수로 진행되었고, 본사에서는 스크럼을 활용했다. 주간보고는 프로젝트에도 해야하고 본사쪽으로도 또 해야한다. 거기에 더해 작년 초에는 본사에서 관리를 강화하겠다고 주간보고에 개인 주간보고와 팀 주간보고를 함께 하도록 했다. 일단 프로젝트와 본사의 프로세스가 달랐고, 주간보고가 중복으로 이루어졌기 때문에 불필요한 업무가 추가되었다. 더군다나 개인과 팀 주간보고를 하고(디테일하게 일별로 할일을 보고토록 했다) 프로젝트에 대한 주간보고도 따로 하는 것은 낭비라는 생각이 들었다.

주간보고를 그렇게 함에도 불구하고 팔로업이 되지 않았기 때문에 더더욱이나 무의미하게 느껴졌다.

누군가가 보면 불평 불만만 가득하다고 생각할 수는 있겠지만 하고 있는 일을 하지 않았던 것도 아니고 내 선에서는 나름 잘해내었다고 생각한다. 처음에 언급했듯 대표님과 많은 얘기를 하고 최대한 개선하려고 대표님도 노력하셨지만 해결되지 못하는 것들이 많았고, 그 부분은 충분히 이해가 간다. 하지만 보다 나은 환경에서 하고 싶은 일을 할 수 있는 곳을 원했기 때문에 퇴사를 결정하고 이직을 하게 되었다. 이런 저런 불만이 많았음에도 회사에 있었던 시간을 돌아보면 '나는 좋은 구성원이었나?', '나는 좋은 팀장이었나?' 에 대한 질문에 '부족했지만 최선을 다했고, 그렇다'라고 대답할 수 있을 것 같다.

이 결정을 언젠가는 후회하게 될지도 모른다. 나는 본사에서 하고 있는 서비스를 응원하고 충분히 잘될 수 있다고 감히 생각하기 때문에 스톡옵션을 아쉬워 할지도 모른다. 하지만 회사는 회사대로, 나는 나대로의 길을 서로 응원하며 가기를 바란다.