본문 바로가기
👨‍💻 프로그래밍/기타

토스에서의 첫 팀 회고 (🏠 주담대팀)

by 개발자 진개미 2024. 7. 5.
반응형

회고를 하는 이유/마음가짐

  • 똑같이 회고라 불려도 마음가짐은 굉장히 다를 거라 생각합니다.
  • 어떤 회고는 형식적이고, 어떤 회고는 솔직하고, 어떤 회고는 남에게 보여주기 위해 합니다.
  • 저는 이 회고가 솔직하고, 객관적이고, 더 나은 사람 (개발자)이 되기 위해 하는 반성의 성격을 띠기를 바랍니다.

배경

  • 23년 9월 서버 개발자로 토스에 입사해 1달간의 온보딩 기간 후 23년 10월부터 24년 5월까지, 약 8개월간 주담대팀에서 업무를 진행했습니다.
  • 개발자로서 첫 활동이기도 했고, (회사 내에서는 적은 편이라고는 해도) 대규모 대고객 트래픽을 처음 받아보는 경험인 만큼 느낀것, 배운 것, 후회하는 것이 넘칩니다.
  • 또, 굉장히 드물다 할 수 있는 새로운 제품을 여러 개 출시하면서도 기존 제품을 유지보수하는 경험을 해서 굉장히 행운이었다고 생각합니다.


처음 팀에 배정 받으며...

솔직히 굉장히 당황했습니다. 제가 팀을 배정받은 날 팀원 분들이 대부분 휴가를 가셨기 때문인데요. 애초에 제가 오는 것도 전달받지 못 하셨다고 합니다. 🤔 지금 생각해 보면 신입 개발자가 첫 팀에 가는거면 어느 정도 온보딩 과정이 있어야 하는데 애초에 팀원 분들도 제가 오는 걸 전달 받지 못했다고 하니 그 과정이 부족할 수밖에 없었습니다. 하지만 솔직히 이 당시에는 아무 생각도 없었습니다. 애초에 비교 대상이 없으니 뭐가 좋고 뭐가 나쁜지를 몰랐으니깐요!

하지만 막상 팀원분들이 휴가를 돌아오고 일을 시작하니 굉장히 재밌었습니다. 🏠 주담대팀은 제가 도메인이 재밌어 보여서 골라서 간 팀이고, 실제로 재밌었습니다. (블로그 글을 보면 아시겠지만 저는 금융과 경제학에 관심이 굉장히 많은 편입니다.) 뿐만 아니라 그곳에 처음 계신 개발자분이 너무 좋은 분이셔서 정말 많이 배웠습니다. 오죽하면 그때 든 생각이 "이거 돈 내고 회사 다녀도 되는 거 맞나? 너무 즐거운데!"였습니다.

상황이 계속 이렇게 흘러갔다면 저는 회고를 쓰지도 않았겠지만... 유감스럽게도 그렇지 않았습니다. 제 앞에는 2가지 악재가 기다리고 있었는데요. 

  1. 마감시간이 빠듯한 제품 출시가 2개 😵
  2. 빌런의 등장 😈

그리고 저는 이 2가지를 모두 잘 대처하지 못했고, 그 과정에서 많은 정신적/육체적 고통을 받았습니다. (며칠 밤을 회사에서 새웠기 때문에 육체적인 고통이기도 합니다.)


사람과의 갈등

행복의 기원이라는 책을 아시나요?

 

📖 행복의 기원: 행복에 대한 과학의 대답

소개행복이 뭔지, 어떻게 하면 행복할 수 있는지 묻지 않는 사람은 한 명도 없을 것이다. 하지만 "행복이란 뭘까?"를 검색해 보면, 추상적이고 뜬구름 잡는 얘기밖에 없다. 행복이 뭘까라는 질문

jinkpark.tistory.com

 

무엇이 사람을 행복하게 할까를 과학적으로 분석한 책인데, 대충 결론을 말하자면 우리에게 가장 큰 고통과 가장 큰 아픔을 주는 건 사람이다라는 내용입니다. 토스를 다니면서 이 책을 굉장히 많이 떠올렸습니다. 너무 좋은 분이 많아서 많이 배우고 행복하게 회사 생활할 때도 있는 반면, 빌런을 만나면 크게 고통받습니다. (어느 회사나 그렇겠지만)

이 분과의 갈등은 크게 4가지 이유가 있었는데요.

  1. 고집이 굉장히 쎄시고 무조건 본인 생각대로 해야 함
  2. 본인 스타일이 아닌 코드를 보면 말도 없이 마음대로 다 고침
  3. 피드백을 드리면 굉장히 방어적으로 나오시고 인신공격을 하심
  4. 급하게 출시해야 하는 제품임에도 본인 스타일대로 다 하시려고 혼자서 붙잡고 계심

처음에는 이런 상황을 마주했을 때 최대한 긍정적으로 생각하려 했고 원래 시니어와 주니어가 일하는 방식이 이런 건가 보다 하고 안일하게 생각했습니다. 하지만 다른 팀에 간 동기분들의 얘기를 듣거나, 다른 회사에 있는 친구들의 얘기를 듣거나, 이 분이 다른 팀에서도 여러 분들과 갈등이 있었다는 얘기를 들으니 아... 내가 힘든 건 이게 정상적인 상황이 아니기 때문이구나라는 확신으로 바뀌었습니다.

사실 이 분이 10X 개발자시고 너무 뛰어나시면 상처를 받으면서도 배우고 넘어갔을 수도 있을지도 모릅니다. (하지만 그렇다고 해도 그냥 넘어가지는 않았을 거 같아요. 애초에 같이 협업하는 건데 이렇게 하는 게 말이 될까요?) 하지만 이 분이 쓰는 코드는 이해하기가 너무 힘들고 간단하게 구현할 수 있는 것도 일부로 복잡하게 구현하나 싶을 정도로 이해가 안 가는 기술적 결정을 많이 하셨습니다. 이 외에도 말하기 힘든 많은 일을 겪으며 우울감도 심해지고, 밤에 잠들기 힘들 정도까지 됐습니다.


잘한 점과 못한 점들

🐜 ✅ GOOD: 갈등이 있을 때 감정적으로 대처하지 않았다

위에서 적은 것만 보면 제가 굉장히 쎄게 나갔을 거 같지만 오히려 혼자 앓았다는 게 더 정확한 표현입니다. 직접적인 갈등이 있었을 때조차도 감정적으로 나가지 않고 이 문제를 해결하기 위해서는 어떻게 해야 할까를 주로 생각했습니다. 그 당시에는 억울한 것도 많고 하고 싶은 말도 많은데 이걸 다 누르고 최대한 감정을 빼고 대처하는 게 맞나 많은 의구심이 들었지만 돌이켜 생각해 보면 저 상황에 할 수 있는 최선의 대처를 했다고 생각됩니다.

 

🐜 🚨BAD: 서비스 운영에 필요한 높은 기준과 책임감이 부족해 잦은 장애로 신뢰를 주지 못 했다

특히 처음 팀에 갔을 때 장애를 꽤 많이 냈습니다. 물론 시스템과 환경을 탓할 수도 있지만 저는 그러고 싶지 않습니다. 애초에 시스템과 환경을 개선하려 노력하지도 않았기 때문에... 그럴 수밖에 없었던 게 제 코딩 / 배포는 유저가 거의 없는 개인 포트폴리오에 맞춰져 있었지 대고객 금원 관련 서비스에 맞춰져 있지 않았습니다. 그래서 테스트도 철저히 하지 않았고, 배포 후 모니터링도 주의 깊게 하지 않았습니다.

여기까지는 그래도 신입 개발자로서 그럴 수도 있다의 범주에 들어가지만 그 이후에도 만족스러울 정도로 빠르게 배우지 못하고 장애를 몇 번 더 냈습니다. 직접적인 말은 없었지만 이때 팀원들의 저에 대한 신뢰가 많이 내려가지 않았을까 싶습니다.

다시 돌아간다면 지금은 대고객 서비스에 제 기준이 맞춰져서 같은 실수를 반복하진 않겠지만 환경 / 시스템을 바꾸기 위해 적극적으로 제안하고 노력할 거 같습니다. Alert이 너무 많이 와서 안 보게 되는 문제를 해결하기 위해 Sentry 같은 도구를 도입하고, 맥락이 너무 많아서 이해하기 힘든 코드는 코드를 전체적으로 보면서 여쭤봐서 주석을 달고, Log가 많이 없어서 디버깅이 힘든 문제는 로그를 전체적으로 보충하고...

 

🐜 🚨 BAD: 내 역할을 개발자로 한정해, 팀에서 보이는 문제를 적극적으로 알리지 않았다

사실 개발자 입장에서는 앞서 언급한 "급하게 출시해야 하는 제품임에도 본인 스타일대로 다 하시려고 혼자서 붙잡고 계심" 문제가 눈에 보였습니다. 저는 계속 혼자 속에서 "어? 이상하다? 이거 이렇게 해도 되는 건가? 출시일이 곧 다가오는데 못 끝낼 거 같은데?" 식으로 생각했습니다. 하지만 뭔가 생각이 있으시겠지~ 직접적인 내 일은 아니니깐~ 이런 안일한 태도로 넘겼습니다.

새로운 팀에 배치되면서 받았던 피드백 중에 하나가 바로 공유가 부족하다는 것이었습니다. 처음에는 이게 문제라고 조차 생각하지 않았기 때문에 와닿지 않았는데 피드백을 받았으니 내가 하고 있는 작업이나 상황을 적극적으로 공유하기 시작했습니다. 그렇게 하고 나니 적극적인 공유가 많은 문제를 해결하는 실마리라는 생각이 들었습니다.

  1. PM/PO님의 리소스 파악에 큰 도움이 됨
  2. 내가 겪고 있는 문제나 고민들에 대해 다른 분들이 의견을 줄 수 있어 더 좋은 해결책을 찾을 수 있음
  3. 내가 갑자기 너무 바빠지거나 다른 문제가 생겨도 내 일을 쉽게 물려받을 수 있음

이 때도 제 상황을 적극적으로 공유했으면 제가 리소스가 엄청 남아서 거의 할 일이 없다는 것, 혼자 잡고 계신 게 진척도가 매우 낮았다는 것 등을 팀이 알게 돼서 3일 연속 회사에서 지내며 밤을 새우는 일은 없었을 겁니다.


성장했는가?

돌이켜 보면 주담대 팀에서의 경험은 예쁘고 안정적으로 성장하는 그림과는 거리가 있었습니다. 약간 어미새가 아이들에게 비행을 가르치기 위해 절벽에서 미는 느낌이 있었습니다. (?)

 

차근차근 친절하게 성장할 기회는 없었지만 나름 오래된 제품을 실제 운영하고 새로운 제품을 출시하고, 그 과정에서 어디에서나 많이 있을 법한 갈등을 겪고 그걸 해결해 나가며 결국 성장을 했습니다.

제가 성장한 것들 특히 느낄 때가 새로운 제품을 맡을 때인데요. 새로운 팀에 가서도 개발자로서 저의 구현 능력이 높아졌다고 느끼고, 기준도 높아졌다고 느낍니다. 

앞으로도 여러 경험을 쌓고 새로운 지식을 배우며 개발자로서 성장하겠지만, 주담대팀에서 성장한 만큼은 성장 못 할 거 같다는 건 확실합니다. 그 점에서 지금은 이런 경험을 한 게 다행이다라는 오히려 좋아 마인드를 가지고 있습니다.


반응형