2024.12.28

오랜만에 일기를 쓴다.

이정도면 일기(日記)가 아니라 연기(年記)가 아닐까.

 

이번해에는 신변이 변한 것이 꽤 있었다. 원래 살던 곳에서 이사를 하기도 했고, 이직도 했다. 

 

여름쯤 새로운 곳으로 가족이 전부 이사를 했다. 더 살기 좋은 곳으로 오게되어 다행이다. 부모님도 마음에 들어하신다.(부모님 집이니까 부모님이 마음에 들어하는게 중요하지)

취업한 이후 계속 같이 살고 있는데 점점 독립하고 싶은 생각이 든다. 하지만 아직 경제적으로 부담스럽기도 하고 집을 구하는 과정도 복잡할 것 같아서 귀찮은게 크다.

 

하반기에는 이직을 했다.

퇴사를 회사에 고한 후 주위 분들이 왜 퇴사하는지 여쭤보는 일이 많았다. 어떤분은 "퇴사에는 크게 두가지 - 지금 있는 곳이 싫어서 혹은 앞으로 갈 곳이 더 좋아서 가 있는데 당신은 어떤쪽인가요? 이제 마지막이니까 진심을 알려주세요"라고 퇴사사유를 묻기도 했다. 다른 사람 다있는데서 그렇게 물어보면 "저의 성장을 위해서"라 말하지. 안그래도 같이 일했던 앞으로 일해야하는 동료들이 옆에 버젓이 있는데 진심을 말할 수 있을까.

 

이직 사유는 위의 두가지 전부 다 이다. 정확히 말하자면 지금 있는 곳이 싫은 것은 이직 결심 계기, 앞으로 갈 곳이 더 좋은 것은 약간의 운이 좋았던 이직처 결정 결과이다. 즉, 퇴사 사유는 이미 충분했으며 이직에 성공한 것은 운이 좋았다. 아마 이직에 실패했다면 퇴사를 고민했을 것이다.

 

작년 말 원래 팀(이하 A) 리드분이 퇴사하면서 사업 방향성을 다르게 한다는 명분하에 다른 팀(이하 B)에 합쳐지게 되었고 그 이후로 제품 방향성도 (여러 시도를 하고 있다는 명분하게) 모호해졌다.

A팀에서 제품의 성과가 사내에서 별로 좋지 않았고, 리드가 퇴사한 시점에 B팀과 합쳐서 시너지를 내겠다는 것이 올해의 OKR이었다.

팀이 합쳐진 직후 운이 없게도 내가 낸 버그로 인해 꽤나 커다란 장애가 났고, 연동했던 대형 고객사와의 계약이 틀어질 뻔한 상황이있었다.

 

A팀은 이미 사내에서 평이 좋지 않았고, B팀의 누군가는 A팀 전원이 정말 너무 싫었다고 한 상황이었다. 그러한 중에 장애를 내니 B팀에서는 A팀에서 맡은 제품이 시장에서 실패한 원인을 샅샅히 찾게 되었고, 명분은 충분했다. 여러 말들이 있었지만 내가 느낀 것은 A팀 제품이 실패한 원인은

- 백엔드 서버의 커다란 구조적 결함

으로 일축되었다는 것이다. 원인은 간단할수록 모두가 수긍하기 편하다. 이 과정에서 나는 지금 제품의 구조와 현재 어떠한 방식으로 동작하는지 취조당하였다.

1. 프로모션 참여 완료 후 포인트 지급 시 CS가 유발될 수 있음에도 굳이 포인트 지급을 비동기적으로 처리하는 이유가 무엇인지

2. 대형 고객사 관련 캠페인의 버그가 왜 발생한 것인지

그 후 약 3개월동안 이 결함이라는 것에 대해 개선작업에 들어갔다. 이 외에도 다른 서버 개발자가 보시기에 이부분은 왜 이렇게 된건지 여쭤보는 일이 많았다. (eg. service locator 패턴을 쓰던데 안티패턴인거 아세요? 등등..)

지금 생각해보면 다른서버 구현이나 패턴또한 다 동일했는데, 안티패턴이라고 슬랙에 쓰레드에서 딱 찝어서 우리 제품 서버 코드만 언급됐을땐 씁쓸했다.

 

3개월동안은 전력으로 개선해보려고 했다고 생각한다. 서버 기술 부채 개선은 이미 이유를 걸고 넘어진 것이니 어쩔 수 없었지만 나는 그외에 제품 관리 자체의 부재가 크다고 봤고 이 컨텍스트를 남기는데 더 집중했던 것 같다. B팀에게 이러이러해서 이렇게 됬다고 알리고, CS들어오면 대응하고, 고객사문의오면 답변전달하고.

 

올해 사업 안건 중 지금 맡은 제품을 더 확장하려는 시도가 있었고, 그에 따라 서버의 요구사항도 늘어나게 되었다. 따라서 팀이 합쳐진지 3개월이 지난 시점에 서버를 그대로 유지할지 아예 새로운 서버를 설계하고 지금 서버를 마이그레이션할지 결정하게되었다.

같이 일하던 13년차 개발자가 있었고 거의 그분 의견대로 진행되었다. 결과는

- 현재 제품의 코드가 더 이상의 개발 및 유지 보수를 할 수 없을 정도로 구조가 처참함 (시니어 개발자는 clean architecture 맹신도였다.)

- 지금 코드에 새로운 확장 시도 시 사이드 이펙트를 예측할 수 없음

의 이유로 인해 새로운 서버를 띄우기로 하였다.

 

이후 새로운 프로젝트 작업을 하였다. 당초 릴리즈 일정은 4월이었지만 프론트 리소스 부족으로 인해 9월까지 작업이 밀렸고 그 과정에서 나는 새로운 프로젝트 작업에 기존 프로젝트 유지보수, CS대응, 고객사 문의 대응, PM 문의 대응 등 개발 외적으로 제품 전체에 대해 관여를 할 수 밖에 없는 상황에 놓였다. 시니어 개발자가 기존 서버에 대해 컨텍스트가 없다는 이유로 "그건 당신이 다..."(그분은 말을 흐리는 버릇이 있다.)라고 매번 회의때마다 말을 하였고 따랐다.(그럼 3개월 동안 기존 코드베이스에서 같이 일한 것은 어떤 시간이었나..)

 

위에서 말한 "새로운 서버로 마이그레이션"이 결정된 이후 기존 서버에 어떠한 개선이나 코드 리펙토링, DB 부하 개선, 새로운 인프라 도입 등의 작업을 해도 팀에서는 "어차피 없앨 서번데 왜... (유지보수를 하죠?)", "그정도 개선은 어차피 임팩트가 없으니까..", "없앨 서버에 너무 공들이지 마세요"와 같은 말들 뿐이었고 동기 부여가 많이 떨어졌다.

심지어 종국에는 시니어 개발자에게 코드리뷰조차 거부당했다. 나는 이미 다른일을 하고있는 동료에게 (예전 코드베이스에 대해 일말의 컨텍스트가 있다는 이유로) 코드리뷰 구걸을 하러 다녔다.

 

이러한 상황에 나는 내가 더이상 회사에서 어떠한 임팩트도 낼 수 없다고 판단하였고, 단도직입적으로 지금 맡고 있는 제품이 싫어졌다.

팀에서 다른 제품에 관여하고 싶다 화두를 던져보았지만 조삼모사격으로 팀명만 바뀔 뿐 아무것도 변하지 않았다.

게다가 새로운 프로젝트의 성패마저 불투명한 상황에 같이 작업했던 시니어 개발자가 그 프로젝트마저 CTO가 다른 더 중요한일을 하라했단 이유로 나에게 일임하려하자 알게모르게 화가 났고, 더이상은 일을 할 수 없을 것 같아 (이직 성공 실패 여부에 상관없이) 퇴사를 결심하였다.

 

이직처를 결정할 때 가장 중요한 것으로 생각한 것은

- 많은 사람들이 쓰고 있는 제품의 핵심 도메인에 대한 작업이 가능한지

- 기술적으로 어려운 문제에 관여할 수 있는지

- 기존 회사에서 다루지 못했던 기술들을 경험할 수 있는지

를 중점으로 보았고, 새로운 회사에서 온보딩 과정 중 위 기준에 합당한 팀을 고를 수 있었다.

새로운 팀에서 바라는 점은 데이터 파이프라인 및 데이터마트 설계, 코틀린+스프링 백엔드 개발 경험을 하는 것이다. 데이터 엔지니어링은 기존회사에서도 관심이 있기도 했고, 이전 공부했던 것과 관련된 일들을 할 수 있지 않을까하여 관심이 많다. 향후 데이터 엔지니어로 직군 전환하고 싶기도 하다.

 

이직이 결정된 이후에는 일본에 갔다. 2주간 홋카이도를 여행했다.

*를 만나서 이것저것 이야기하고 왔다. 앞으로도 좋은 관계를 유지하면 좋겠다.