2021년은 나에게 특별한 한 해였다.
드라마앤컴퍼니에 입사한 지, 만 1년이 지난 상태에서 시작한 한 해였고, 점점 나에게 주어진 역할, 권한, 책임이 많아질수록 4~5년차 개발자로서 느껴지는 막연한 불안감을 떠안고 시작한 한 해였다. 그 불안감을 바탕으로 '내가 과연 지금 성장하고 있는 걸까? 이렇게 하는 것이 성장하는 데 좋은 영향을 줄 수 있을까?' 라는 생각이 많이 들었었다. 이 글을 쓰는 지금, 돌이켜보면 앞으로 나아가기 위해 또 한 번의 계단식 성장을 크게 한 해였다.
이번 회고는 분기별로 써보려다가 쓰다보니 주제별로 쓰게 됐다.
채용
2020년이 끝나갈 즈음부터 서버 개발자 채용 전형 중 "기술 면접" 단계에 참여하게 됐다. 함께 일할 동료를 채용하기 위해 직접 의사결정 과정에 참여한다는 것은 매우 부담스럽게 느껴지는 일이었지만, 채용 과정에 참여함으로써 내가 모르던 나의 장/단점, 특징(?)에 대해 이전보다 조금 더 잘 알게 된 것 같다. 1년이 지난 현재도 부담스럽기는 마찬가지다. 채용 과정에 쏟는 에너지가 생각보다 매우 커서 몰입을 필요로 하는 업무를 해야할 때는 채용 관련 업무가 하고 있는 일정에 큰 영향을 끼칠 때도 있었다. 그런 신호를 느낄 때마다 동료분들에게 도움의 요청/양해를 구하여 우선 순위를 조정하고 있다. 이렇게 내가 잘 할 수 없는 상황에 처할 때면, 동료들이 나에게 도움을 줄 수 있을 것이라는 확신을 갖고 있기 때문에 주저없이 도움을 요청할 수 있다는 사실이 업무를 함에 있어서 매우 만족스럽다.
2020년 12월, 한 해가 마무리 될 때 쯤, 회사 내의 개발 조직 구조가 바뀌면서 '서버/웹팀 리더' 라는 자리가 공석이 됐었다. 2021년 1분기에는 대규모 채용을 희망하여 서버 개발자 분들을 적극적으로 채용하기 위해 여러 시도를 했고, 서버/웹팀 리더의 적임자 분을 모셔오기 위해 여러 사람들이 시간과 에너지를 쏟았다. 리더 적임자 뿐 아니라, 그동안 드라마앤컴퍼니 서버/웹팀에서 채용하지 않고 있던 주니어 개발자 포지션도 이 때부터 채용을 하기 시작했다.
그 결과, 2021년 2분기에 모신 리더 분을 포함하여 2021년 전체적으로 서버 개발자가 열 분 가량이 새로 입사를 하셨고, 기존의 우리 서버/웹팀 구성원들이 대규모 채용에 대한 준비/대비가 많이 미흡했던 것이 주된 이유가 된 사실을 비롯하0여 각자의 이유로 네 분께서 각자의 선택을 하셨다. 그리고 2021년 이전에 입사하셨던, 나와 비슷한 시기에 입사하셨던 서버 개발자 한 분도 이직을 하시게 됐다. 1년이상 재직중인 기존의 서버 개발자 분들 뿐 아니라, 프론트엔드 개발자 분들 중 몇몇 분들도 또 다른 좋은 기회를 만나 이직을 하셨다.
준비되지 않은 채, 다수를 채용한다는 것은 기존 구성원들에게도 큰 영향을 끼칠 수 있을 것이라는 막연한 짐작/예상이 실제로 일어나는 상황을 직접 겪었다. 그리고 채용은 아무리 객관적이고 그 사람 자체를 제외한 다른 요소를 고려하지 않고 채용을 하려고 해도 현재 회사의 상황, 기존 구성원들의 회사에 대해 갖고 있는 생각들, 기존 구성원들의 적응도 등을 고려하지 않을 수가 없었던 것 같다. 그래서 타이밍에 따라, 역량 차이에 따라 채용까지 이어지는지, 이어지지 않는지의 차이는 종이 한 장 차이라는 비유가 딱 들어맞는 것 같다는 생각이 들었다. 특히, 좋은 분임에도 불구하고 모시지 못한 케이스들도 많이 생기다 보니, 본격적으로 채용 업무의 우선순위를 높이기 전에, 관련자들끼리 준비를 최대한 전략적으로 해놓는 것이 좋겠다라는 생각이 들었다. 그리고 그 전략을 세울 때, 채용 기준에 대해서 명확하게 Consensus 를 이뤄내고, 명시해야한다는 개인적인 교훈을 얻었다.
지금도 회사의 사업 규모가 점점 넓어지고 깊어짐에 따라 새로운 동료분들이 많이 필요한데, 아직 그 속도를 내지 않고 있다. 왜냐하면 현재 내가 속한 플랫폼 크루의 상황과 나의 상황을 고려했을 때, 새 서버 개발자 동료분을 빨리 모셔오는 것 보다는 현재 계신 분들의 안정적인 온보딩을 마치는 게 더 중요하다고 생각하는데, 이 시기에 새로운 분이 오시면 안정적인 온보딩에 집중을 할 수가 없기 때문이다. 현재 내 생각은 현재 계신 분들이 안정적인 온보딩이 완료됐다고 판단이 되는 시기가 오면(아마 3월 중순~말로 예상), 잘 온보딩 된 동료분들의 역량으로 한 번에 여러 분들을 모셔올 수 있을 거라는 기대를 갖고 있다.
테크 리드
2021년 7월 쯤, 개발 조직 내에 '테크 리드' 라는 역할이 주어지고, 그에 상응하는 권한이 주어지면 의사결정 구조가 바뀌어서 의사 결정의 병목 구간인 각 팀의 리더들에게 쏠려있는 구조를 탈피하여 빠르게 의사결정을 할 수 있지 않을까와 같은 목소리가 나왔다.
이와 같은 목소리가 나오게 된 배경 이야기는 많고, 복잡하긴 하지만 결정적으로는 의사결정 구조가 팀 리더들에게 쏠려있어서 리더가 아닌 구성원들이 권한/역할을 충분히 위임받지 못해, 주체적인 의사결정을 하지 못했고 이에 따라 직접 해결해야할 문제 상황에 직면하는 순간이 적어서 성장할 수 있는 기회가 의도치 않게 줄어드는 문제가 있었던 것이라고 이해했다.
이 문제를 해결하기 위해 리멤버에 합류한 지 1년 반 정도밖에 지나지 않았지만, 조직 개편과 함께 나에게도 테크 리드라는 역할이 주어졌다. 우리 회사에서 테크 리드는 Engineering Ladder 라는 framework 에서 정의한 것을 따랐다. 그 외 EM(Engineering Manager)을 지향하는 분들에게는 EM 의 역할을 부여하고 권한을 위임하는 방식으로 의사 결정 구조를 개선하고자 했던 회사/개발실 차원에서 새롭게 정의한 '역할'이다.
나는 오래전부터 사람을 관리하는 것에는 적성에 맞지도 않을 뿐더러, 잘 할 수 없는 일이라고 스스로 생각해왔다. 향후 원하는 커리어 패스(career path)로는 테크 리드, 기술 기반의 CTO 를 염두에 두고 있었다. 테크 리드 역할에 대해서도 개발실 리더 분과 몇번에 걸쳐서 1on1 을 통해 이야기도 많이 나눴다. 처음에는 내가 잘 할 수 없을 것 같다는 생각이 많이 들었었고, 그 당시 서버/웹팀의 분위기가 좋지만은 않았기 때문에 부담감이 많이 들었다. 이런 내 생각을 잘 공감/이해해주면서도 내가 잘 할 수 있을 거라고 개발실 리더 분이 신뢰를 많이 표현해주셔서 테크 리드라는 역할을 가져보게 됐다.
테크 리드라는 역할/포지션이 있는 곳에서 일해본 경험도 없거니와 롤 모델로 삼을 만한 사람이 당장 떠오르지 않아 어떻게 해야하나 고민이 많긴 했다. 이전에 다니던 전 회사 CTO 와 현재 개발실 리더, 이전에 만났던 좋은 시니어 개발자분들을 떠올리며 좋았던 점들을 복기하며 내가 되고자 하는 테크 리드를 구상해보곤 했다. 결국에는 구상을 한 결과가 현재의 나인 것인지, 나라서 그렇게 구상을 한 것인지는 잘 모르겠으나 그냥 나라는 사람이 그런 역할과 권한이 생기면 이렇게 됐을(supposed to be) 것이었다는 생각에 이르렀다.
내가 인식한 테크 리드로서의 가장 첫번째 해결해야할 문제는 팀 빌딩이었다. 새로운 사람을 채용하는 것을 의미하는 게 아니고, 오히려 기존 구성원들에게 내가 신뢰를 얻고 서로가 서로를 존중할 수 있는 팀이 되는 것이 가장 급선무였다고 생각했다. 이렇게 생각할 수 밖에 없는 이유/계기 또한 다양하고 복잡하지만 결론적으로는 그 당시 팀의 분위기가 상당히 어수선했다라는 한 마디로 정리할 수 있을 것 같다. 나를 제외하고 내가 리딩해야하는 분들은 4~5년 이상의 경력을 가지신 분도 계셨고, 1년 가량의 경력을 가지신 주니어 분들이었는데 모두 입사하신 지 얼마 되지 않았다는 것이 나의 걱정 포인트였다. 즉, 그 동안의 온보딩을 통해 심리적인 안정감을 얻기엔 다소 시간이 조금 더 필요한 상황일거라는 생각이 들었다. 그리고 상반기에 개발실, 서버/웹팀의 혼란한 시기에 입사를 하셨어서 제 각기 다 다른 온보딩 프로세스를 겪으셔서 일 하는 방식도 다 다르고, 사용하는 용어의 선택, 문서 작성 위치/방법 등에 대해서도 제각각이었다.
이를 일관성있게 맞춰야할 것 같아서, 어느 정도 기간동안 잦은 피드백을 드렸던 것 같다. 이 과정에서 나도 쉽지 않았지만, 동료분들이 아마 많이 힘드셨을 것 같다는 생각이 그 당시에도 들었는데 회고를 하고 있는 지금도 마찬가지로 든다. 그리고 나도 동료분들에게 신뢰를 얻고 있지는 못한 상태여서, 신뢰를 얻기 위해서 말로만 코드 리뷰, 업무 피드백을 드리기 보다는 몸으로 함께 하는 모습을 많이 보여드리려고 애를 많이 썼다. 결과적으로 내가 신뢰를 얻었는지 아직 얻지 않았는지는 잘 모르겠으나, 처음 테크 리드를 시작할 당시보다는 분명히 동료분들이 나를 신뢰하는 수준이 많이 높아졌다는 것을 느꼈다.
아직도 고장난 듯 버벅 거리는 초보 테크 리드이지만, 동료분들이 믿어주는 게 느껴지니 앞으로도 함께 더 잘 할 수 있을 거란 자신감이 생기고, 동료분들과 함께 성장할 수 있도록 서로 이끌고 밀어줄 수 있을 것 같다. 그리고 내가 겪었듯 다른 동료분들도 테크 리드, 엔지니어링 매니져 등의 더 큰 역할과 권한을 위임받으실 수 있도록 많은 기회를 제공하고, 머지 않은 미래에는 우리 팀이 회사 내의 중요한 인재 양성소와 같은 인식도 생길 수 있으면 좋겠다.
서비스 분리
리멤버의 서버는 monolithic 한 아키텍쳐로 DB, 코드 등으로 구성돼있었다. 특히, DB 의 장애가 리멤버의 거의 모든 기능을 사용할 수 없는 상태로 만들 수 있는 상황이었고, 실제로 몇 번 DB 의 장애로 인해 길지는 않지만 짧은 순간 애플리케이션 서버들이 DB 로부터 커넥션을 할당 받지 못하거나 응답을 받아오지 못해 장애가 생긴 적도 있다. 특히 리멤버는 고객/유저들을 대상으로 모바일 푸시를 종종 보내는데, 많은 사람들을 대상으로 푸시를 보내면 푸시에 반응하여 리멤버 앱이 켜질 때마다, 아무것도 하지 않아도 애플리케이션 서버에 보내지는 요청량이 매우 많아 응답 지연이 자주 생기고 있는 상황이 있었다.
이 때 리멤버 앱에서 서버로 보내는 요청 중 "알림 목록에 표시되는 데이터" 를 조회하는 부분이 유저에 따라 slow query 가 발생하는 경우가 많았다.
이를 해결하기 위해 리멤버 서버 개발팀에서는 거의 최초로 기존의 monolithic 아키텍쳐로 구성이 돼있는 도메인을 별도의 도메인으로 분리하는 프로젝트가 시작됐다. 프로젝트가 시작하던 시기는 2021년 4월쯤이었던 것으로 기억한다. 그 당시에는 내가 해당 프로젝트에 관여하지 않고 있었고, 대략적으로 어떻게 진행되는지에 대해서 가끔씩 공유받고 찾아보는 정도가 전부였긴 했다.
그런데, 나~중에 살펴보니 프로젝트가 산으로 가고 있다는 것을 인지하게 됐다. "알림 목록에 표시되는 데이터" 를 조회하는 부분과 관련된 도메인을 분리해내야 하는 것인데, "푸시를 발송하기 위한 일련의 로직/도메인" 을 분리하는 프로젝트로 변모됐던 것이다. 어디서부터 잘못된 것일까, 처음부터 다시 시작하는 게 맞는 것일까라는 생각을 내가 해야만 하는 시기가 테크 리드를 맡으면서 찾아왔다.
개인적으로는 처음부터 다시 시작하는 것이 맞다라는 판단을 했다. 그러나 해당 프로젝트가 몇달동안 새로 합류하신 동료분 혼자서 고군분투하며 개발을 하고 있는 만큼 힘들어 하고 계셨고, 그런 와중에 '잘못 됐으니 처음부터 다시 합시다' 라는 말을 하면, 그 분의 업무 의욕이 확 꺾여서 팀 입장에서는 좋지 않은 선택이 될 것 같다는 생각을 하게 됐다. 그래서 그 프로젝트를 최대한 살려서 production launching 을 해야겠다고 마음을 먹었다. 그 이후로 그 분과 함께 요구 사항을 다시 분석하는 것을 비롯하여 코딩도 함께 하기 시작했다.
짧지 않은 기간 동안 그 동료분과 함께 여러 상황을 정리해가며 고생한 끝에, 2021년 9월 9일에 첫 production release 를 할 수 있었다. 그 이후 발생하는 여러 오류, 버그 등이 있었으나 사용자에게는 영향을 주지 않도록 조치를 취했고, 이 글을 쓰고 있는 현재에도 이어서 점진적으로 개선을 하고 있다.
그러나 실질적으로 "알림 목록에 표시되는 데이터" 를 조회와 관련된 도메인은 분리해내지 못한 상태였다. 이를 분리하는 작업에는 두 주니어 개발자분들과 함께 시작하였다. 이 때는 내가 이미 테크 리드라는 역할을 맡고 있었고, 업무를 위한 의사 결정 권한도 나에게 온전히 있었으므로 두 분의 주니어 개발자분들과 자주 논의를 하며 무난하게 프로젝트를 진행하여 마무리 지을 수 있었다. 물론, 처음에 예상하지 못한 기술적으로 큰 어려움이 몇번 있긴 했지만 셋이서 나름의 최선의 방법을 찾아내고, 해결해나갔다. 이 과정에서 셋 다 꽤 성장을 한 것 같다고 느꼈었다.
이 "알림 목록에 표시되는 데이터" 관련한 더 자세한 내용은 함께 했던 두 주니어 개발자 분들 중 한 분인 선영님께서 잘 작성해주신 블로그 포스트를 통해 볼 수 있다.
이번에 분리한 "푸시 발송 도메인" 과 "알림 도메인" 의 사례를 기반으로, 팀의 상황에 따라 얼마든지 서비스를 분리할 수 있을 것이라는 자신감을 많이 얻을 수 있었다.
앞으로 분리를 해야하는 도메인은 새롭게 발견될 병목 구간, SPoF 의 원인이 되는 도메인이 될텐데, 다행히(?) 아직까지는 눈에 띄는 문제 구간이 없다. 아직은 문제 구간이 짧고, 작아서 발견하지 못한 것일 수도 있어서 자주 데이터를 살펴보고 있다.
뉴렐릭
2021년 2~3분기에 걸쳐서 꽤 오래전부터 사용하고 있는 모니터링 툴, 뉴렐릭을 좀 더 잘 쓰기 위한 고도화 작업을 진행하였다.
기존에는 APM 기능만 쓰고 있었고, 그 외 몇몇 기능을 PoC 수준으로 구축해놓고 보는 사람만 보는 정도로만 활용하고 있었는데, 이번에 분산 트랜잭션 추적, Infrastructure Monitoring, Logs 등 뉴렐릭의 여러 기능을 본격적으로 사용하기로 했고, 그 연동 작업을 주로 내가 맡아서 진행을 하였다.
내가 뉴렐릭을 연동/사용하면서 느낀 점
- 필요한 기능이 대부분 다 있긴 있는데 뭔가 다 2%씩 부족하다.
- 특정 데이터를 따라 추적을 하는 과정에서 Seamless 한 UX 가 부족하다.
- 연동 과정이 타사 제품보다는 overhead 가 많다고 해야하나, 다소 번거로운 단계가 존재한다.
쓰고 보니, 다 단점이네. ㅠㅠ
장점으로는
- 타사 제품 대비 저렴하다.
- 서버 운영을 위해 필요한 기능은 대부분 존재하고, 유용한 기능들을 새롭게 많이 만들어주고 여러 시도를 해주고 있다.
뉴렐릭 연동을 하면서 개편된 조직 구조에 맞게 장애 알람 슬랙 채널도 분리해두고, 서버 애플리케이션마다 편하게 장애 알람을 설정할 수 있도록 terraform based 로 만든 모듈도 있는데, 기존에 받고 있던 알림 채널/policy 를 없애기에는 혹~시나 놓치면 안 되는 종류의 알람들을 못받게 될까봐 지우지 못하고 있다. ㅠㅠ 그래서 아직은 의도한대로 분리된 채널에 알람이 오긴 오지만, 잘 활용되고 있지는 않은 것 같다. 올 해에는 잘 활용할 수 있도록 어떤 형태로든 꼭 개선을 해야겠다.
AWS Gameday
2021년 11월, AWS Gameday 에 참가했었다.
주제는 MSA 였다. 주제는 MSA 였지만, 높은 점수를 얻기 위해서는 MSA 에 대한 이해도보다는 AWS 의 lambda, ECS, EC2 로 웹 서비스를 잘 유지할 수 있는지, 여러 chaos 상황에 대해서 대처할 수 있는지가 더 중요했다. 기본적으로 3개의 MSA 애플리케이션 코드를 제공해줬고, 이를 각 플랫폼(lambda, ECS, EC2 등)으로 서비스할 수 있도록 하기 위한 매뉴얼도 함께 제공해줬다.
우리 팀은 아쉽게도 중간에 CloudFormation 을 이용하여 서비스해야하는 애플리케이션 서버를 살리는데 시간이 오래 걸려 높은 점수를 획득하진 못했다. 딱 중간 정도 순위로 마무리했던 것으로 기억한다. Stack 을 완전히 삭제 후 다시 처음부터 생성해도 서비스가 안 됐었는데, 그 원인은 아직까지 몰라서 궁금하네. ㅠㅠ
이 때 지급받은 AWS 티셔츠는 집에서 잘 입고 있다. 검은색 옷이라서 고양이 털이 너무 잘 붙어서 밖에 나갈 때 입진 못하겠다. 고양이 털이 없었어도 밖에 나갈 때 입을 만한 옷은 아닌 것 같기도.. ㅋㅋ
정리
2021년은 개인적으로도, 업무적으로도 너무 많은 일들이 있었고 기록해둬야 할 말이 너무 많은데 글로 다 옮기기엔 이제 내 체력이 부족한 것 같다. 그래서 굵직한 것들을 위주로 2021년 회고를 작성해보았다.
회고에 대한 회고
더 자세하고 구체적으로 하고 싶은 말들이 많이 있는데 내 체력 부족을 비롯한 여러 이유로 생략한 것이 아쉽다.
