첫 퇴사

 

퇴사했다. 

약 1여년을 재직했다. 펫시터 플랫폼이었고 펫시터와 고객 양 쪽 모두 관리하는 B2B 형태의 비즈니스 였다. 

그곳에서 일하는 개발자로서는 고객과 펫시터 뿐 만 아닌 내 옆에 앉아 있는 운영팀 또한 나의 고객이었다. 

운영팀이 어드민페이지에서 어떤 부분을 수정해 달라, 만들어 달라는 요청을 할 경우 최소한의 리소스를 사용하되 그에 맞는 기능을 구현하는 것이 관건이었다. 왜냐하면 리소스의 대부분은 고객을 위해 사용해야하기 때문에 어드민 페이지에 많은 리소스를 사용하느라 실서비스에 신경쓰지 못하는 일이 있으면 곤란하기 때문이다. 나는 신입으로서 이런 리소스 조절이 필요한 지도 몰랐을 뿐 아니라 쉽지도 않았다. 

여하튼, 퇴사를 하게 된 이유나 내 자신에 대한 아쉬움, 혹은 앞으로의 커리어에 대해 간단히 이야기해보고자 한다. 

어찌되었던 첫 회사였고, 많은 것을 배웠고 느꼈기 때문에 기록하고 싶다. 

 

1. 코드리뷰

우선 나는 신입으로서 활발한 코드리뷰를 원했다. 하지만 여기서 놓친 부분이 있다면 '코드 리뷰'의 의미였다. 

나는 당연히 코드리뷰를 경력이 더 많은 개발자가 경력이 상대적으로 적은 개발자에게 피드백을 주며 '티칭'하는 형태를 말하는 줄 알았다. 

하지만 코드리뷰는 경력과 상관없이 개발자들끼리 서로의 코드에 대해 말그대로 리뷰하는 것을 뜻했다. 그래서 내가 코드리뷰가 활발한 문화를 만들고자 한다면 나보다 경력이 많은 선배가 나서주길 기다리기만 할 것이 아니라 내가 먼저 움직여야한다는 것을 알았다. 

나는 늘 코드리뷰가 없음을 불평만 했지 다른 동료의 코드를 보면서 배우거나 피드백을 주거나 하는 액션을 전혀 취하지 않았다. 나는 신입이기 때문에 내 몫이 아니라 생각했기 때문이다. 

하지만 이는 큰 착각이며, 내가 리뷰를 받았다면 나 또한 리뷰를 해야함을 깨달았고 배웠다.

 

이건 조금 다른 이야기지만, 내가 늘 버릇이 되지 않는 일이 하나 있다.

바로 다른 개발자 코드 읽기.

내 스타일에서 고착화된 코드에서 더 발전하려면 당연한 이야기지만 가까이 있는 동료들의 코드를 많이 보아야한다.

여하튼 다른 개발자들의 코드를 많이 보고 많이 배우자. 

 

2. 협업

첫 회사를 다니며 개발자들의 협업은 무엇일까 하는 고민을 많이 했다. 

첫 회사에서 일을 받는 방식은,  CTO 님과 어떤 비즈니스적 이슈에 대해 이야기하다 불현듯 어떤 것이 필요하다는 것이 떠오르면 바로 실행에 옮기는 식이었다. 따로 데드라인도 없었기 때문에 나 스스로 적당히 기간을 잡고 작업했다.

팀원들끼리 공유할 수 있는 칸반 보드나 어떤 타임라인, 투두리스트 이런 것들이 없었기 때문에 내 옆자리 개발자가 무슨 일을 하고 있는지 잘 모르고 지낼 때가 많았다. 가끔  pr 올라온 것을 보며 이런 일을 하고 있구나 하는 추측 정도를 했다. 

이는 조금 아쉬운 부분이었다. 

서비스 회사보다는 약간 클라이언트에게 외주를 받는 느낌의 방식처럼 느껴졌다. 

그래서 함께 팀으로서 일한다는 느낌이 적었다. 

그렇기 때문에 이직하는 회사의 협업방식을 듣고 개인적으로 금방 따라갈 수 있을까 하는 걱정 또한 들었다. 

이직하는 회사에서 협업을 더 잘 배우면 좋을 것 같다. 

 

3. 이력서

9월 15일 즈음부터 다니기 시작하여 10월 1일에 사직을 하게 되어 약 1년 정도를 다닌 셈인데 이력서에 그렇다 할 작업이 없었다.

그래서 이직을 준비하면서도 내 이력서로 이직할 수 있을까 하는 걱정이 많았다.

 

첫 회사에서는 비 개발 직군에 대한 업무 효율에 회의를 느끼고 개발직군에게 비개발 직군의 일을 자동화하도록 했다.

그 중 내가 했던 작업은 마케팅 자동화인데, 검색 시 나오는 검색 결과에 대한 컨텐츠가 부족함을 느끼고 대표적인 컨텐츠 중 하나인 블로그 포스팅을 대량 생산하기 위해 고객들에게 포스팅 요청 및 작업 링크를 자동으로 발송하는 작업을 했었는데 하면서도 굉장히 회의가 컸던 기억이 난다. 

개발자로서 마케팅을 함께 진행하다 느낀 점은, 마케터는 어찌되었던 필요하다는 것이다. 

첫 회사에서는 물론 시간이 부족했기 때문에 질보다 양을 택한 탓에 어쩔 수 없이 선택한 작업이었지만 그럼에도 마케팅은 사람의 감성을 건들여야하는 부분이기 때문에 이 부분을 자동화하여서는 성과가 나오지 않는다는 것이다. 

여러모로 성과적으로나 자기 만족적으로나 아쉬움이 큰 작업들이었다. 

 

이력서는 3개월 주기로 수정하라는 이야기가 있다. 

나 또한 중간 중간 수정하지 않았더라면 어떤 작업을 했는지 모조리 까먹어 막상 이직할 때 어버버 했을 지도 모른다. 

이력서를 꼭 자주자주 업데이트해주도록 하자.

 

 

4. 말

같은 공간에서 같이 일하는 동료들끼리하는 말 한마디 한마디가 얼마나 중요한지 느꼈다.

비판과 비난은 확실히 다르며 같이 일하는 동료에게 비난은 절대 삼가하며 그 동료가 진행하는 일에 있어서 의견이 있다면 

피드백 형식으로 말하며 논리 없는 비난어조로 말해선 절대 안된다. 

 

비난은 영양가 없는 악플이다. 

비판 또한 필요성이 크지 않다. 

어찌되었던 동료가 하는 일을 깎아 내릴 이유는 없다. 

그 일의 한 가운데에 있는 사람은 그 동료이며 나는 옆에서 어깨너머로 봤을 뿐이기 때문이다. 

그렇기 때문에 내 의견을 전달하는 피드백 형식이 가장 옳바르다.

 

개발자들의 독성말투는 주기적으로 플로우가 도는 듯 하나, 개발자들이 유독 독성말투를 가지고 있는 것이 아니라 

독성말투를 가진 사람이 어쩌다 보니 개발자를 하고 있는 것이라고 생각한다. 

개발자들 역시 여느 직종과 마찬가지로 많은 의사소통이 필요하다. 

기능을 구현할 때에는 말없이 코드만 만들고 있을 수 있지만 그 기능에 대해 기능을 필요로 하는 사람과 의논할 때는 정말 많은 의견을 주고받아야한다. 그렇기 때문에 개발자이기 때문에 말을 잘 못한다 와 같은 의견은 받아드릴 수 없으며, 그런 개발자가 되기를 나는 철저히 지양할 것이다. 

 

나는 줄곧 의사소통이 잘 되는 개발자가 되고자 했다. 

동료들과 필요한 것들을 잘 주고받으며 내가 일하는 곳은 의견이 자유로히 오가는 환경이었으면 한다. 

그렇기 때문에 나는 더더욱 그 과정에서 내 동료에게 상처가 되는 말을 하지 않기 위해 노력할 것이다. 

 

 

 

 

 

---

 

 

쓰고 보니 그리 많지가 않다. 

이번에 이직하는 곳은 강남이 아니라 광화문에 있어서 모든 것이 달라질 것 같다. 

 Ruby on Rails 에서  Node.js 로 스택이 변경되기도 하고 협업 방식도 완전 다르기 때문에 

사실상 신입으로 입사하는 것이다. 

 

그동안 약간의 딜레마에 빠져 성장이 더뎠는데 이직하면서 다시 힘내봐야겠다. 

이직할 회사 CTO님께 협업 방식을 듣고 정말 오랫만에 가슴이 뛰었다. 

환경이 변하는 만큼 힘든 일도 많겠지만 그만큼 재밌는 일도 많으리라 생각한다. 

이상하게도 이런 쪽으로 힘든 일은 즐기는 편이다. 

기대되는 2021년 하반기다.