뒤늦은 2022년 회고

이전 회고들

1년 8개월 - 회고

 

2020년 회고 - 오픈서베이를 떠나 드라마앤컴퍼니에서의 1년

 

뒤늦은 2021년 회고

 

2022년에 대한 회고를 한참 시간이 지나고 난 2023년 2월이 돼서야 겨우 해보게 됐다.

 

테크리드 1년 5개월

2021년 7~8월쯤, 처음으로 Tech Lead 역할을 맡고 나서 만 1년하고도 몇 개월 더 지났다.

처음 시작할 때의 막연한 부담감은 많이 없어졌다. 그러나 여전히 내가 잘 하고 있는지는 모르겠다. 내가 잘 하고 자신있는 분야에 대해서는 확신을 갖고 있긴 하지만, 그렇지 않은 분야/업무도 공존하다 보니 늘 이게 궁금하고 고민이 되는 것 같다. 하지만 고민을 너무 오래 하기보다는 나 자신과 동료들을 믿고 앞으로 나아가는 데 집중을 해야한다고 스스로 자주 다짐하게 된다.

그리고 회사에서 기술적인 리더십만 가지면 된다는 consensus 가 있었는데, 하다보니 그것만 할 수는 없었다는 것을 깨달았다. 기술적인 리더십 이전에 사람 자체가 리더십이 있어야하고, 아무리 HR 을 들어내려 해도 애초에 개발자의 HR 과 Tech 는 떼내기 어려운 것이었다는 것을 몸소 체험한 2022년이었다.

 

의지

회사 초기부터 얼마전(2022년 상반기 중)까지 오래동안 개발 조직을 키우고 이끌어주셨던 분이 다른 곳으로 이직을 하셨다. 그 분이 나를 지금 다니고 있는 회사에 오게끔 도와주신 분인데다 내가 여기서 일하는 동안 상당히 많은 의지를 했던 분이었다. 그런 분이 다른 곳으로 이직을 한다고 했을 때 아쉬움 60%, 두려움 10%, 기대감15%, 나머지 감정 5% 정도가 느껴졌던 것 같다. 아쉬움, 두려움에 대해서는 말할 필요도 없고, 그 와중에 기대감이 조금 들었던 것에 대해서는 나의 철학과도 관련이 있다.

새로운(특히 큰 영향력을 가질) 사람이 조직에 들어오거나, 기존에 있던(특히 큰 영향력을 가진) 사람이 조직에서 나가게 될 때, 둘러싼 주변도 함께 상당히 많이 변하게 되고 그 변화에 적응하기 위해 많은 것들도 함께 달라진다. 이 과정에서 긍정적인 변화, 부정적인 변화를 겪게 되는데 이 과정에서 조직과 사람은 성장할 수 밖에 없다고 믿고 있다. 물론, 이런 변화가 너무 자주 있으면 변화에 적응하기도 전에 새로운 변화가 생기다보니 그런 상황을 반기지는 않는다. 그럼에도 그 분의 퇴사가 당분간은 힘들겠지만 나에게는 또 다른 새로운 성장의 기회가 되긴 하겠구나라는 생각이 들었기 때문에 두려움보다는 기대감을 더 갖는 것이 모두에게 행복할 것이라고 생각했다.

 

Product Owner

2022년 하반기에 제품 조직 구조를 새로 짜면서, 기존 플랫폼 크루는 그대로 유지될 필요가 있어 유지됐고 이 과정에서 내가 PO 를 맡게 됐다.

조직의 인원은 적었지만 내가 TL 과 PO 를 함께 맡았는데, 돌이켜 생각해보면 함께 일해준 크루원들이 많이 힘들었을 것 같다. 

사내에서 사용될 중요한 제품을 담당하는 크루였는데, 결과적으로는 개인적인 아쉬움이 많이 남은 프로젝트였다. 더 잘 할 수 있었는데라는 아쉬움. 내가 조금 더 잘 챙기고, 팀원들에게 좋은 자극을 주어 더 완성도 있는 제품으로 만들 수 있었는데 다른 일들이 더 급해보인다는 이유로 나 스스로 우선순위를 잘 정하지 못했던 적이 많이 있었다.

의사결정 책임자의 무게를 직접적으로 겪어보니 다른 PO 분들, 제품 기획자분들이 정말 대단하게 보이고, 나는 가지지 않은 재능/역량이 어느 정도인지에 대한 메타 인지가 생겼다는 측면에서는 그나마 스스로 위안을 해볼 수 있는 경험이었다.

 

처음으로 미국 방문 - New Relic Future Stack

2022년 5월달에는 생애 처음으로 미국 땅을 밟아보았다. 그것도 항공 비용 지원을 받고, 출장 스케줄로.

방문한 목적은 New Relic 이란 Observablity 서비스에서 여는 Future Stack 이라는 이름의 conference 참석이었고, 그 conference 를 통해 우리 회사가 사용하고 있는 New Relic 을 어떻게 더 잘 활용할 수 있을까에 대한 인사이트를 얻기 위함이었다.

회사 동료 한 분과 함께 다녀왔는데, 다녀오고 나서 이 분께서 New Relic 에 대해 더 잘 알게 됐고 나보다 더 잘 활용하시는 모습들을 보여주고 계신다. 그리고 개인적인 느낌이었긴 했지만 사내에서 New Relic 에 대한 인식이 그닥 좋지는 않았었는데, 다녀와서 7월달에 사내에 발표도 해서 그런건지 모르겠지만 점점 사내에서 New Relic 에 대한 인식이 좋아지고 있다고 느낀다.

인식이 좋아졌을 뿐 아니라 실제로 거기서 얻은 인사이트/아이디어를 토대로 사용 팁 등을 전파하기도 했고, 업무에 적용을 해보고 있는 것들도 있어서 실질적인 도움이 많이 된 것 같다.

물론, 일정 중간에 다녀온 관광 일정 - 그랜드 캐니언, 카쇼, 라스베가스의 정경 등도 잊을 수가 없다.

 

서버 인프라 : ECS on EC2 로 마이그레이션

2022년 초만 하더라도 서버들이 운영되는 인프라가 뒤죽박죽이었다. 비용도 고려되지 않았으며, 눈에 보이지 않는 비용(개발자 생산성 등)에 대해서도 전혀 고려가 되지 않고 있다고 느낄 정도였다. 실제로 누군가는 고려했겠으나 결과만을 보면 그렇게 느껴졌다.

이때까지는 이런 환경이 문제는 아니었다. 개발자 수도 적었고 그 소수의 개발자들이 뒤죽박죽이긴 하지만 모두 컨트롤 할 수 있는 수준이었으니까. 하지만 2022년이 시작될 때는 많이 늘어난 개발자들과 각기 다른 수준으로 갖고 있는 인프라 지식/경험, 전문 인프라스트럭쳐 엔지니어의 부재 등으로 인해 이 현상은 이제 나에게 문제로 인식이 됐다.

이렇게 된 원인은 새로운 인프라 기술을 습득한 사람의 실제 적용을 하고 싶은 욕구들에 대한 관리 부족(욕망 컨트롤?), 기존의 것들을 새 부대로 옮겨담는 역할의 부재, 명확하게 maintanence 모드 선언의 부재 등 다양한 게 있음을 발견했다.

이 현상을 문제라고 바라본 이상, 해결을 해야겠다는 생각이 들어 중단기적으로는 모든 서버를 AWS 의 ECS on EC2 에서 운영하자라는 결정을 내렸다. 사실, 이에 대한 의사결정 권한은 나 포함 그 누구도 갖고 있지 않은 상태였었는데 그냥 내가 그렇게 결정해버렸다. 그 결정에 대한 책임을 지기 위해 ECS on EC2 에 사용할 EC2 구성을 내가 속한 조직에서 주도적으로 준비하였고, 기존에 EC2 ASG 또는 ECS Fargate 위에서 운영되고 있는 서버들을 ECS on EC2 로 옮겼다. 새로 띄울 서버들은 모두 ECS on EC2 로 띄우도록 지속적으로 리마인드 드리며 관찰도 하고 있다.

그 결과로 20개가 넘는 서비스들이 ECS on EC2 위에서 운영되고 있다. 여전히 이전하지 못한 서비스들도 많은데 이전하지 못하는 주된 이유는 대부분 containerization 의 공수때문임을 파악했다.

이 과정을 수행하며 JVM 환경에서 실행되는 서버 애플리케이션의 경우에는 Google 에서 만든 jib 를 이용하면 아주 간단하게 containerization 을 할 수 있음을 경험했고, 상대적으로 그런 도구의 도움을 받기 어려운 ruby, ruby on rails 로 만든 서버 애플리케이션은 containerization 에 많은 시간을 들여야 했음을 깨달았다.

아직 끝나지 않았지만 인프라 운영의 방향성을 결정했고, 기존의 서버들에 대한 마이그레이션도 상당량 수행한 것만으로 비용 절감, 기술 부채 상환, 개발자 생산성 향상 등 좋은 결과가 느껴지고 있다.

시대가 어느 때인데 왜 k8s 를 안 쓰냐고? 아직 우리 조직은 k8s 를 사용하기에는 여러 측면(조직적, 기술적, 비용적)에서 시기상조라는 판단을 하고 있기 때문이다. 언젠가는 우리 회사도 k8s 를 사용하게 될 지도 모른다. 그러나 그 이유는 "k8s가 가장 힙하고 대세이기 때문" 이라는 것만으로는 안 된다고 확신한다.

 

CTO 채용

기다리고 기다리던 CTO 분께서 오셨다.

그동안 CTO 분을 모시려고 많은 분들을 만나뵀다. 최종 offer 까지 받으셨지만 입사까지는 이뤄지지 않았던 분도 계셨다.

이 과정에서 확실히 CTO 후보분들은 시야, 사고 방식이 보통의 개발자 면접에서 마주한 분들과는 다르다는 것을 꽤 느꼈다.

만나 본 여러 후보분들 중 개인적으로 가장 함께 일하고 싶은 분이 join 하셔서 같이 일하고 있는데, 매우 기쁘다. 그동안의 시간이 이 분이 오시기를 기다린 시간이었던 것일까라는 생각이 들 정도로 훌륭하고 존경할 수 있는 분이 오셨고 인터뷰때부터 충분한 신뢰가 쌓일 정도의 희귀한 경험을 했다.

그리고 나에게 객관적으로 솔직한 피드백을 주실 수 있는 분이어서, 이를 통해 나도 또 한 번의 성장을 할 수 있을 것이란 기대가 많이 된다.

그리고 이미 나에게 상당한 자극을 주고 계신다. 1년 뒤의 나는 또 얼마나 성장해있을까?

 

평가

원래 우리 회사는 1년에 2번 평가를 진행한다. 그러나 2022년 상반기 평가는 skip 됐다. 평가에는 많은 에너지가 쏟아지는데 그 에너지를 사업 목표 달성을 위해 쓰는 것이 좋겠다는 전사적인 판단이 주된 배경/이유였던 것 같다.

연간 전체에 대한 평가는 글을 쓰고 있는 지금도 on-going 인데, 다른 사람을 어떤 형태로 시작했든 정량적인 숫자(eg. 연봉)로 치환되는 평가라는 업무는 너무 어렵다.

평가를 잘 하기 위한 방법에 대해 고민도 많이 하고 자료도 많이 찾아봤지만, 결국은 평상시 피드백을 자주 주고 받아 서로의 기대치에 대한 sync 가 수시로 일어났어야만 평가도 잘 할 수 있는 것이란 생각으로 귀결이 됐다.

그동안의 나는 active 하게 먼저 피드백을 요청하는 사람은 아니었는데, 앞으로는 좀 더 적극적으로 먼저 피드백을 주거나 들려달라고 요청하는 사람이 되기로 마음을 먹었다.

 

새로 학습한 기술

• ECS on EC2 를 도입하며, 운영 노하우가 생기고 있다.
• AWS documentDB (mongoDB) 에 대한 경험적 지식도 조금씩 생기고 있다.
  • findAndModify 를 사용하는 것과 관련한 잘못된 애플리케이션 설계 때문에 생긴 병목 현상을 찾고 고쳤는데, 생각한 방식대로 해결이 됐을 때 정말 뿌듯했다.
  • https://lhb0517.tistory.com/entry/MongoDB-DocumentDB-1%EB%85%84-%EC%9A%B4%EC%98%81-%EA%B2%BD%ED%97%98-%EA%B8%B0%EB%A1%9D

MongoDB, DocumentDB 1년 운영 경험 기록

• ElasticSearch
  • cluster, node, shard, index 를 다룰 수 있게 됐다.
  • 인덱스 사이즈를 고려한 shard 수가 중요하다는 사실, shard 는 운영중에 size 를 변경하기가 어렵다는 사실을 경험적으로 느끼고 있다.
  • nested field 개념에 대한 이해가 생겼다.
  • 복잡한 로직(AND, OR, NOT 이 수많은 depth 로 얽혀있는 로직)의 query 를 작성하여 원하는 검색 결과를 얻어낼 수 있다.
• terraform
  • 내가 terraform 을 언제부터 쓰기 시작했는지 기억이 잘 나지 않지만, 2022년에는 본격적으로 사용을 많이 한 해였다.
• AWS - 관점에 따라 기술이라고 하기에는 부족하지만.
  • API Gateway
  • ECS on EC2
  • Session Manager
    
    • IAM 정책 설정을 잘 해놓을 필요가 있다.

 

읽은 책

• 실리콘 밸리의 팀장들
• 딥 워크
• 클린 애자일

업무와 무관한 책도 몇권 읽었던 것 같은데 지금 글을 쓰는 시점에서 기억이 나질 않네...

실리콘 밸리의 팀장들, 딥 워크. 이 두 책은 내가 진심으로 응원하고 있는 어느 스타트업에서 중요하게 생각하는 가치(Core values)로써 Freedom, Flow, Friendship 을 강조하고 있는데 각각의 F 에 대한 어설픈 설명보다는 한 권씩의 책으로 설명을 하고 있는 책들 중 두 권이다. 3F 인데 왜 두 권만 읽었냐고? Freedom 에 해당하는 책 한 권, "리모트" 는 꽤 오래 전에 읽었었기 때문에 2022년에는 읽지 않았다.

실리콘 밸리의 팀장들

책을 읽기 전에도 극단적인 솔직함을 추구하던 나는 이 책을 읽으며 느낀 점은 다음과 같다.

그동안의 나의 극단적인 솔직함은 놓치고 있는 부분들이 많았다. 우리 인간들은 동일한 input 을 주면 동일한 output 이 나오는 멱등성이 있는 기계나 컴퓨터 따위가 아니라는 것을. 나 스스로도 마찬가지임을.

소규모 팀을 이끌어야 하는 현재의 나에게 꼭 필요했던 조언과 먼저 경험해본 자들의 이야기들을 적기에 들어볼 수 있어서 정말 감사하다.

딥 워크

나 또한 여러 종류의 피상적 작업(shallow work)들을 동시에 수행(멀티태스킹)하는 것이 중요한 가치라고 인식되는 현대에 살고 있기 때문에 일을 하다가 마주하게 되는 수많은 피상적 작업들을 피하지 않았다.

앞으로도 피하기는 어려울 것이라는 것도 알고 있다. 그럼에도 불구하고 이 책을 읽고 나서는 피상적인 작업을 하더라도 심층적인 작업(Deep work)을 수행하기 위해 내 마음가짐과 일을 대하는 태도 등을 어떻게 가져야 할지에 대해서 스스로 돌아보고 점검하게 되는 계기가 됐다.

우연하게도 2023년에는 피상적 작업들보다는 심층적인 작업들에 더 많은 몰입을 하고 에너지를 써야만 하는 상황이 주어지고 있기 때문에 이 책도 딱 적절한 시기에 읽었다.

내가 스스로 몰입을 하지 못하고 있다고 느낄 때 다시 한 번 꺼내 읽을 것만 같은 책이다.

클린 애자일

제대로 애자일이 무엇인지 고민해보지 않고, 막연히 Agile 이란 단어의 뜻대로 "빠르게 개발하는 것" 정도로만 받아들인 상태에서 읽었는데, 꽤나 큰 충격을 받았다. 애자일 선언을 한 사람들이 의도한 애자일이란 무엇인가에 대해 알 수 있게 됐고, XP, 실천을 하기 위해서 필요한 것들부터 인간 철학에 이르기까지 다양한 scale 로 사고를 해볼 수 있는 좋은 계기가 됐다.

 

좋은 동료들

이 섹션에 가장 많은 이야기를 담아야 하고, 담을 수 있지만 끝도 없을 것만 같다.

좋은 동료, 이 하나의 형용사와 하나의 명사가 만들어낸 상투어 또는 관념어가 돼버린 듯한 이 표현.

다르게 표현할 수는 없을까? 라는 고민도 많이 했다. 진심으로 동료들이 좋다고 느끼기 때문인데, 딱히 더 좋은 표현을 찾지 못했다.

나를 둘러싼 많은 동료들이 있고 각각의 개성이 있지만 하나같이 다 '좋다'. 

...

...

좋은 것은 잘 알겠는데 글로 표현을 잘 못하겠다. 이 섹션을 쓰고 있는 지금, 너무 졸립기도 하고 체력이 떨어져서일까..?

말도 안 되는 핑계라는 것은 명확하게 기록해두며, 무책임하게 회고를 마쳐본다.