때는 바야흐로 6월 1일.

S멘토님께서 연락이 왔고, 근황 얘기를 하고 있다가 이직 준비를 하고 있다고 말씀드렸더니 '이력서랑 포트폴리오 좀 보내줘~ 내 메일 알지?'하셔서 보내드려야지 하고 깜빡하고 있다가 이틀 후에 다시 문자로 '이력서 보내줘~'하고 왔다. 회사가 궁금하기도 하고 멘토님도 오랜만에 뵐 겸 이따 사무실 가도 되냐고 물어봤더니 오라셔서 선릉으로 넘어갔다.


그때까진 그냥 멘토님 뵈러 가는 거였는데.. 사무실에 들어가 멘토님과 인사하고 잠깐 얘길 하다가... 갑자기 잠시만 기다려보라며 기술이사님을 모시고 오겠노라고 하셨다.


나: (...?? 기술이사님..??)


잠시 기다리니 멘토님과 기술이사님이 오셨고, 면접이 시작됐다. (?? 왜?)

나는 멘토님을 뵈러 간 것이었고.. 멘토님은 얘가 면접 보러 온다는 거구나 하고 생각하셨나보다.


이 때까지 기술 면접 준비를 하지 않은 상태이기도 했고, 무방비로 면접이 시작됐다.(눈물)

면접 땐 기술이사님이 대부분 질문을 하셨고, 그간의 경험이나 회사에서 서비스를 하고 있는 기술 위주의 질문이 이어졌고, 알고리즘, 자료구조(B+트리, 레드블랙 트리)에 대해서도 물어보셨다. 공부해야지 하고 있던 것들이지만 아직 하진 않은 상태라 당연히 대답은 하지 못했다. 모르는 부분에 대해 질문을 받다보니 아무래도 자신감 없는 태도로 대답한 것들도 있었다.


대부분의 기술 면접이 이력서나 포트폴리오를 기준으로 진행하는데, 포트폴리오에 있던 내용이 내가 직접 말한 것 말곤 언급되지 않은 것으로 봐서는 아마 사전에 포트폴리오는 멘토님만 보고, 기술이사님은 안보셨던 듯 하다.


회사 기술 스택이 나와는 내가 가진 기술 스택과 조금 차이가 있기도 했고, 여러모로 부족한 대답이 많아서 결과적으로는 그 자리에서 떨어졌다. 이력서와 포트폴리오를 보내긴 했지만... 고백하지도 않았는데 차인 느낌?


물론 갑작스럽게 진행된(나만 몰랐을지도 모르지만) 면접이긴 했지만 불편하거나 기분 나쁜 시간은 아니었다. 면접이 끝날 때 쯤에 기술이사님이 '솔직히 말씀드리자면, 확 와 닿는게 없다. 어필이 되는 부분이 있으면 좋았을텐데 그런 부분이 없었다."라고 말씀하시면서, '나중에 식사 한 번 같이 하면 좋겠네요' 라고 하면서 나가셨다.


그리고 멘토님과 얘기하면서 당연히 부족했을 면접에 대해 피드백을 받았는데, 알고 있던 것이나 경험이 있던 것들에 대해 대답할 때 그냥 사실을 있는대로 얘기하는 것 보단 좀 더 살을 붙여서 혹은 개인적인 생각이나 느낀 점, 배운 점들을 같이 답변하면 좋겠다는 내용이 주를 이뤘다. 확실히 나는 있는 사실대로 대답하는 경향이 있었고, 피드백을 받고 어떻게 고치면 좋을 지 방향을 잡을 수 있는 계기가 되었다.


예를 들어 면접관이 'A 프로젝트에는 어떤 기술을 사용했나요?'라고 질문을 했을 때, 예전 같았으면 질문에 대해 그대로 '스프링 프레임워크, 하이버네이트, 메시지 큐를 사용했습니다.' 라고 대답했을 것을 이젠 좀 더 살을 붙여서 '책으로만 학습하고 있던 것들을 실제 프로젝트에 적용하고 싶어서 스프링 프레임워크과 하이버네이트를 사용했고, API 요청에 대해 비동기적으로 처리하기 위해 메시지 큐를 사용했습니다. 책으로 봐서 알고 있다고 생각한 것들도 실제로 적용했을 때 어떤 어려움이 있는지 알게 되었고, 책을 벗어나 공부를 할 수 있는 곅기가 되었으며, 메시지 큐를 사용함으로써 콜백구조를 적용하여, 기존에 작업했던 동기적 프로세스를 갖는 프로젝트와 다른 아키텍쳐를 경험할 수 있었습니다.'라는 식으로 바뀌었다.


물론 모든 질문에 대해 장황하게 늘어놓는 것은 듣는 이로 하여금 안물안궁과 함께 지루한 상황이 될 수도 있지만, 특별히 강조하고 싶은 부분에 대해서는 사실 뿐만 아니라 이유나 배운 점, 느낀 점과 같이 개인적인 견해를 함께 전달하면 면접관의 마음을 살 수 있는 답변이 되지 않을까 싶다. 완급조절에 대한 판단은 상황을 보고 잘 얘기해야겠지만 말이다.


어쨌든 그 후 다른 회사 몇 군데에서 면접을 보게 되었고, 대답을 하면서도 스스로 피드백을 하게 되는 습관이 생겼고, 나 자신에게는 좋은 영향을 주고 있는 것 같다.

'Career 관리' 카테고리의 다른 글

예기치 않은 면접  (0) 2016.06.16
스팸 메일함에 서류 지원 결과가  (0) 2016.06.01
이직의 이유  (0) 2015.10.15
메일을 받을 게 있어서 메일함을 봤는데 오지 않았길래 스팸함을 확인했는데 글쎄..

지원했던 서류  전형에 대한 결과가 와있었다...

대체 왜 스팸함에..? 왜죠?? 구글 너무한 거 아니냐?

그리고 서류는 탈락했고...

왠지 지메일이 '니 서류 전형 결과는 내가 대신 버려줄게 ^^ㅎ' 하는 느낌(눈물)



'Career 관리' 카테고리의 다른 글

예기치 않은 면접  (0) 2016.06.16
스팸 메일함에 서류 지원 결과가  (0) 2016.06.01
이직의 이유  (0) 2015.10.15

글을 정리하기는 작년 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. 본사 업무 프로세스와의 괴리

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

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




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

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

'Career 관리' 카테고리의 다른 글

예기치 않은 면접  (0) 2016.06.16
스팸 메일함에 서류 지원 결과가  (0) 2016.06.01
이직의 이유  (0) 2015.10.15

+ Recent posts