채널톡 퇴사 회고

 

2024.10.18 부로 2년 9개월간 다녔던 채널톡 안드로이드 팀에서의 마지막 출근을 마쳤습니다.

11.18일 정확히 1달간 휴식기를 가지고 새 회사에 출근할 예정입니다.

 

누군가는 면접을 소개팅이라고 표현하곤 하는데

돌이켜보면 회사 생활은 연애에 비유할 수 있을 것 같습니다.

 

진짜로 마지막까지 회사와 팀원들과 프로덕트를 사랑하면서 다녔던 것 같습니다.

---

📦 떠나는 이유

회사에 갖는 불만은 없었습니다. 물론 아예 없었다고 한다면 거짓말이겠지만

누구나가 아무 회사에나 가질 수 있을 법한 사소한 것들 뿐이었습니다.

 

받고 있는 연봉도 만족하고 있었고 업무에도 익숙해져 불안감 없이 편안하고 즐겁게 일을 하고 있었습니다.

특히 이런 사람들을 또 만날 수 있을까 싶은, 너무 좋았던 모바일 팀원들이 좋았습니다.

 

다니던 중간에 너무 바빠서 퇴사하고 싶다고 생각했던 적이 있었지만, 이것은 착각이었던 것 같습니다 ㅋㅋㅋ

 

그럼에도 퇴사를 결심하게 된 것은 사용자에게 더 가깝고

내가 자주 사용하고 있는 서비스를 직접 만들고 싶다는 생각이 들었기 때문이었습니다.

 

또 개발자는 3년쯤에 이직을 한다는 얘기들을 듣곤 하는데, 이제 곧 만 3년차를 채워가는 입장에서

시장에서는 내 능력을 알아봐줄까? 라는 궁금증도 품게 되었습니다.

 

 

🏃 퇴사는 처음이라..

퇴사 소식을 알리는 전날 부터 긴장감에 잠을 설쳤습니다.

대체 가서 뭐라고 얘기해야할까 100번도 넘게 시뮬레이션 했었습니다.

 

퇴사 소식을 알리는 당일, 저는 그냥 평소처럼 물이나 음료를 마시자고 하거나 바쁘시냐고 물었을 뿐인데

리더님과 팀원분들 모두 대답이 퇴사하세요? 로 돌아왔습니다.

제 표정이 뭔가 비장해 보였던 걸까요?

 

얘기도 어떻게 꺼내야할지 모르겠어서 저도 시작부터 이직하게 됐다고 본론부터 전달했습니다.

맨 처음에는 말 꺼내기도 힘들었지만, 몇 번 전달하고 나니 좀 더 가벼운 마음으로 많은 분들께

그동안의 회사 생활에 대한 얘기와 마지막 인사를 나눴습니다.

 

마지막이다보니 진솔한 얘기를 해주신 분도 많았는데, 그런 얘기들에서도 많은 인사이트를 느낄 수 있었습니다.

 

그 중 한 팀원분이 제게 떠나기 전 이런말을 해줬는데요. 티는 안냈지만 사실 속으로 울었습니다.

 

"빈자리가 느껴질까봐 걱정도 되고 두렵기도 해요. 아마 잘해주셨기 때문에 이런 생각이 드는 것 아닐까요?"

 

 

👶 MZ세대의 근무 기간

사실 처음 회사에 입사했을 때 얼마나 오래 다니게 될지 몰랐습니다.

 

요즘 MZ 세대들은 1년도 못다니고 회사를 금방금방 옮긴다는 말에

저 역시도 금방 옮기지 않을까? 라는 생각을 했었던 것 같습니다.

지금에 와서는 5년 넘게 다니더라도 이상하지는 않았을 것 같네요.

 

다니는 동안 정말 정신없이 치열하게 다녔었습니다. 연차가 쌓일 수록 새로운 시야가 트이기도 하고

점점 더 큰 권한과 책임에 대해 고민해볼 수 있었습니다.

 

채널톡은 제가 처음 정규직으로 입사한 회사였는데요.

입사하고 가장 큰 변화는 두 가지 였습니다.

- 힘들었던 취준생 기간을 까맣게 잊어버리게 만드는 정규직의 월급 (과 늘어나는 취미들)

- 팀 프로젝트에 맞춰 개발하는 것은 어렵구나

 

 

📝 배웠던 점

시기별로 생각과 가치관은 계속해서 변화해온 것 같습니다.

 

처음에는 막연하게 그냥 잘하고 싶었습니다. 뭐든지요.

그런데 정말 쉽지 않았습니다.

 

저는 2018년 부터 개발을 안드로이드로 시작해서 쭉 안드로이드만을 해왔는데요

잘하고 싶은 욕심이 있다보니 다양한 대외활동과 구글의 예제를 세세하게 뜯어가며 공부해왔는데

실무에서 맞닥뜨린 코드는 제가 공부해온 코드와 패턴들과는 괴리감이 있었습니다.

 

처음에는 왜 이렇게 작성하는지 이해하기 어려웠고 어디까지 프로젝트 기준을 맞춰야 하는건지

그 선을 맞추는 것도 어려웠습니다.

 

당시에 선택한 방법은 프로젝트 코드 기준에 최대한 맞추는 것을 선택했었는데요

그 때는 스스로에 대한 확신도 낮아지고 미래에 대한 걱정도 많이 했던 시기였었습니다.

 

결과적으로는 조직이 개편되면서 많은 권한을 가져갈 수 있게 됐고 여러 시도들을 통해

나만의 기준들을 잡아갈 수 있어서 스스로에 대한 확신도 갖게 되는 계기가 되었습니다.

 

제가 원하는대로 업무를 하더라도 반년만 지나면 레거시가 되어있는것을 보니

기존 코드가 왜 그렇게 되어있었는지 이해하는 데에도 도움이 됐구요.

 

업무를 대하는 자세에 대한 고민들을 많이 했었는데요. 이런 생각들을 많이 했었습니다.

- 정량적으로 표현할 수 없는 일을 하지 않기

- 코드 퀄리티에 대한 고민

- 열심히 하기

 

📐 정량적으로 표현할 수 없는 일을 하지 않기

개발을 하다보면 팀 내부에서 공감을 아주아주 많이 살 수 있는 문제들이 발견되는 경우가 많습니다.

예전에는 이런 것들을 보면 너무 고치고 싶고, 진행할 수 없는 이유가 뭘까 고민을 많이 했었습니다.

 

어느 순간 깨달은 것은 (대표를 직접 설득하지는 않았지만) 대표를 설득할 수 없는 이유로는

저 스스로도 자신감을 갖고 다른 사람을 설득하기 어렵다는 것이었습니다.

 

정량적으로 표현하는 것이 중요하다고 생각하는 이유는, 일을 정량적으로 표현하면

단순히 설득하는 데 도움이 될 뿐만이 아니라 소요되는 시간이나 개선 점들이 예측 가능해지고

불필요한 작업을 하는 것을 방지할 수 있다고 생각하기 때문입니다.

 

어찌보면 당연한 얘기처럼 보이지만 가슴 깊이 깨닫는 데에는 시간이 걸렸던 부분이었습니다.

 

 

💭 코드 퀄리티에 대한 고민

안드로이드 개발은 가이드가 굉장히 상세하게 잘 되어있다고 생각합니다.

아키텍쳐부터 어떤 라이브러리를 선택하면 좋은지, 심지어는 마인드셋과 세세한 코드 팁까지 가이드를 해줍니다.

 

이런 가이드를 따라서 공부를 하다보면 왜 이렇게 추천 해주는지

직관적으로 느낄 수 있는 강력한 가이드라는 것을 누구라도 느낄 수 있습니다.

 

그런데 회사에서는 그렇지 못한 코드도 많고 낡은 기술 스택을 사용하는 코드도 많았습니다.

당시에는 이런 부분들도 고치고 싶었고 그런 생각을 하다보니 기능 개발을 할 때에는

그런 레거시와는 달리 잘 만드려고 마음을 먹었고 노력을 많이 했었습니다.

결국에는 이런 생각은 고쳐먹었지만요. 신입 개발자의 오만함이었습니다.

 

여러 경험들이 많았지만, 그 중 코드 작성 기준을 잡게 도와준 테스트 코드 얘기를 남겨두고 싶습니다.

 

많은 개발자들이 테스트를 작성하면 좋다. 라고는 하지만 실제로 테스트 코드를 작성하는 개발자들은

제 생각에는 많지 않았습니다.

 

알면서도, 하고 싶으면서도 실천하지 않는 것은 제 가치관이랑 맞지 않아서

우선 혼자 공부하고 개인 프로젝트에 테스트 코드를 작성했습니다. 그 다음에는 회사 프로젝트에도

테스트 코드를 작성하기 시작했구요.

 

그럼에도 작성하기 어려움을 느껴서 NextStep의 TDD 강의를 수강했습니다. (완주는 못했지만..)

이 강의는 테스트 작성 요령과 마인드 셋을 잡는 데 굉장히 큰 도움이 되었습니다.

 

이런 과정들을 겪고나니 몇 달간 테스트 코드를 작성하는 것이 재밌어서 만든 기능의

테스트 커버리지를 높이기 위해 부단한 노력을 기울였었습니다.

 

덕분에 겪은 제가 느낀 테스트 코드의 좋은 점은

- 테스트가 가능한 코드는 일반적으로 수정하기 좋습니다.

- 기능을 어느 레이어에 작성할지, 클래스를 어떻게 나눌지 기준이 보다 명확해집니다.

- 케이스가 많은 기능은 안정성에 도움이 됩니다.

- 프로젝트에 영향을 주는 기능의 테스트는 코드를 수정할 때 실수를 방지하게 해줍니다.

 

반면 회의적으로 느꼈던 부분은

- 테스트 코드가 필요한 만큼 복잡한 기능을 만들 일이 잘 없습니다.

    - A는 A다 와 같은 테스트는 내가 여기에 왜 시간을 쏟는 지, 가치가 있는 건지 의심하게 했었습니다.

- 테스트 코드는 팀원 모두가 노력해야만 합니다.

    - 짧은 기간에 기능 수정을 해서 배포해야 할 때, 테스트 코드는 수정하는 데 생각보다

      큰 코스트가 필요했습니다. 그러나 팀원들에게 노력하자고 얘기하기에는 저조차도 테스트를 고치는 데

      노력을 들이는 게 스트레스로 다가오곤 했습니다.

 

위 장단점을 종합하여 최근에는 케이스가 많은 경우와 프로젝트에 영향을 주는 부분에는

테스트 코드를 항상 작성했고 그렇지 않는 부분은 코드를 작성할 때 테스트가 가능한 코드인지 검증만 하고

실제로 테스트를 작성하지는 않았었습니다.

테스트 문화가 잘 잡혀 있는 곳에 간다면 생각이 바뀔 수는 있겠지만 현재로써는 그랬었습니다.

 

느낀 것들을 토대로 지금 가지고 있는 코드 퀄리티에 대한 가치관은 이렇습니다.

 

"누구나 이해할 수 있고 고칠 수 있으며 의도가 명확하고 일관된 코드라면 어떻게 작성하던지 상관없다.
그러나 대부분의 경우 간단하고 빠른 방법이 좋다. 개발자는 비즈니스를 구현하는 직업이기 때문에"

 

 

🔥 열심히 하기

열심히 하는 것은 쉽지만 어렵습니다.

 

누군가에게 보여주고 인정받기 위함도 분명 중요한 이유겠지만

저는 치열하게 열심히 했던 순간들이 저에게 더 의미있고 가치있는 시간으로 남았습니다.

 

솔직하게는 매일매일 열심히 하지는 못했지만 열심히 했던 순간들을 떠올리며

앞으로의 삶에서는 열심히 해낸 날의 비율을 늘려가는 목표를 가지고 있습니다.

 

그래도 열심히 했을 때 누군가 알아주는 건 기분 좋은 일이긴 합니다

 

 

👋 마지막으로

감사하게도 너무 좋은 팀원들을 만나 행복한 시간을 보낼 수 있어서 행복했습니다.

이직하는 곳이 가깝기 때문에 종종 보게 되겠지만 (월말마다 고기집 가기로 약속했습니다.)

그 동안 좋은 추억으로 남아서 감사했습니다.