2022년 회고

2022년도 끝났다. 2022년은 개인적으로도, 회사에서도 많은 일들이 있었다. 아주 난이도가 높은(?) 한 해였던 것 같은데 그런 만큼 동시에 많은 것들을 느끼고 배울 수 있었다. 1년 전 회고를 쓸 때 블로그 글을 열심히 쓰겠다고 다짐했던 것 같은데 그 다짐은 딱히 지키지 못했다 ㅠㅠ 글을 쓰기는 커녕 혼자 생각할 여유도 많이 없었어서 아쉬움이 남는 한 해인데, 회고 글을 쓰면서 여러 생각 정리도 한 번 해보려고 한다.

훈련소

훈련소 다녀왔다.. 미루고 미루다가 복무 완료가 6개월 남았을 때가 돼서야 비로소 빡빡이가 되었다. 훈련소 들어가기 전엔 훈련소에서 시간 보내는 것보다는 빡빡이가 되어야 한다는게 아주 화가 났는데, 머리는 막상 밀고 나니깐 별 생각이 없어졌다. 오히려 훈련소 들어가고 나서부터는 하루하루 시간이 너무 안가서 힘들었던 것 같다 .. 그래도 같은 생활관 사람들이랑 재밌게 잘 지내다가 나왔다 ㅎㅎ

병특 복무완료

3년간의 병특 생활이 끝나고 9월 14일에 드디어 민간인이 되었다! 병특 생활하는 동안 딱히 제약을 받는 부분이 없었기 때문에 병특이 끝났다고 해서 뭔가 큰 변화가 있지는 않았지만, 그래도 인생에서 중요한 문제를 하나 해치웠다는게 후련했다.
병특생활은 나에게 무언가에 다시 열정을 쏟을 수 있는 기회로 다가왔던 것 같다. 고등학교 때 열심히 노력해서 무언가 결과를 얻고 성취하는 경험을 처음 해보았고, 이때 얻었던 성취감과 자신감은 앞으로의 인생을 더 성공적으로 살아갈 원동력을 가져다 주었다. 대학교 입학 후에는 어딘가에 한껏 몰입해서 내 열정을 투자했다기보다는 그냥 남들 하는거 따라서 적당히 살았던 것 같다. 스타트업에서 회사 생활을 하게 되면서부터 내가 참여하는 비즈니스와 함께 일하는 동료들에게 긍정적인 영향을 주고 싶다는 생각을 하게 되었고, 이 생각은 성장에 대한 갈망으로 이어졌다. 회사에서 일을 더 잘하기 위해 야근도 많이 하고, 퇴근하고 나서도 이것저것 계속 공부할 것을 찾았던 것 같다.
빠르게 성장해서 결과를 만들어내는 과정이 즐겁게 느껴졌고, 고등학교를 졸업할 때와 마찬가지로 한 번 더 커다란 자신감을 얻게 되었는데, 이 자신감이란 나에게 얼마나 기상천외하고 어려운 일이 주어지든 간에 어떻게든 그 일을 온전히 해낼 수 있을 것이라는 믿음이다. 쉽게 말해 마음 먹으면 다 하지~ 라는 마인드?를 갖게 되었다. 이 마인드로 앞으로 내가 만들어낼 것들은 세상에 아주 커다란 영향을 줄 것이라고 믿는다.

복학

3년동안 학교를 떠나있다가 이제 복학을 하려니까 너무 어색했다.. 수강신청하는 법도 다 까먹고 물리학실험 수업을 들어야 했는데 풍선 가지고 자유낙하 실험을 하고 있자니 현타가 밀려왔다... 그리고 회사 일도 이전처럼 그대로 하면서 학교를 다녀야 했기에 아주 정신없고 바쁜 느낌이었다. 안그래도 도전적인 프로젝트를 하고 있는 상황에서 학교 시험, 과제 뿐 아니라 출석조차도 나에겐 부담으로 다가왔다.
그래도 뭐... 수업 하나도 안듣고 시험 하루씩 벼락치기한거 치고는 괜찮은 성적을 받은 것 같고, 벼락치기하면서 새롭게 배운 것들도 있었다. 무엇보다 물리학실험 끝내서 너무 행복하다 ㅎㅎ
1년 더 어떻게 하지...

회사 일

올해는 정말 일만 하다가 한 해가 다 가버린 느낌이다. 회사 일은 나에게 증명의 수단이었다. 내가 가치있는 사람이라는 것을 증명하기 위해 발버둥쳐온 것 같다. 지금의 이 순간을 밀도 있게 경험하는 것이 앞으로의 내 커리어에 얼마나 큰 영향을 미칠지 알고 있기 때문에 일은 나에게 너무나도 중요했다. 일에 집중하느라 그 밖의 것들에는 많은 신경을 못쓴 것 같아 아쉽지만, 그만큼 회사 일을 통해 많은 것을 배웠다. 유의미한 점은 권한과 책임의 범위가 넓어지면서 기술 외적으로도 많은 것들을 관찰하고 생각할 수 있었다는 점이다.

기술적으로 배운 점

먼저 기술적으로 배울 수 있었던 점을 먼저 얘기해보려 한다.

1. stateful server 개발

그간 일반적인 Stateless Server만 개발해봤었는데, 처음으로 Stateful Server를 개발해보았다. 레디스로 세션을 붙인다든가 하는 수준이 아니라, 도메인적으로 중요하게 취급해야 하는 모든 엔티티를 어플리케이션 메모리에서 관리하는.. 아주아주 stateful한 server였다. server를 stateful하게 만드는 순간부터 개발자는 골치아픈 고민들을 아주 많이 해야 한다. 특히 내가 속한 결제 도메인에서는 auto scaling과 무중단 업데이트가 필수인데, state를 어떻게 여러 노드들에게 동적으로 균형있게 배치하고 요청을 적절한 노드에게 routing할 것인지가 매우 어려운 고민사항이다. 우리는 akka cluster라는 라이브러리를 사용했기 때문에 이 고민들을 모두 직접 하지는 않았지만 clustering과 관련된 많은 환경변수들이 존재하고 이는 우리의 k8s 배포 환경을 함께 고려해서 신중하게 결정되어야 했다.
그리고 akka 공식문서를 몇번씩 정독하고 최대한 akka cluster의 동작을 예측 가능하게 만들어뒀다고 해도 이 라이브러리의 존재는 여전히 우리에게 커다란 블랙박스로 느껴진다. 서버의 동작을 결정하는 아주 커다란 존재가 있는데, 우리가 작성한 코드가 아니어서 controllability가 떨어진다는 점은 개발자를 불안하게 만든다.. 분산 stateful server를 개발하고 관리하는 것은 정말 어려운 일 중 하나이기 때문에 의사결정을 할 때 이렇게 함으로써 얻을 수 있는게 무엇인지, 그게 우리에게 정말 중요한 것인지 잘 생각해보아야 한다.

2. NoSQL 경험

cassandra와 Elastic Search를 어플리케이션 개발에서 활용해보았다. cassandra와 같은 dynamo style DB는 사실 개발할 때는 딱히 좋은 점이 없다. 오히려 partition key와 sort key만을 가지고 쿼리를 할 수 있기 때문에 오히려 제약이 많다고 느껴질 수 있지만, NoSQL의 장점은 실제 운영을 할 때 나타난다. cassandra는 용량과 throughput 면에서 무제한에 가까운 선형 확장성을 갖고 있기 때문에 수많은 데이터를 저장하고 있으면서도 일관적인 성능을 발휘할 수 있다.

3. functional programming

Scala로 개발을 하게 되면서 이전보다 functional programming을 훨씬 깊게 배우고 활용해볼 수 있었다. functional programming과 lazy evaluation의 관계에 대해 생각을 정립할 수 있었고, lazy evaluation이 생각보다 더 강력한 효과를 가질 수 있음을 알았다. 모든 도메인에서 functional programming이 항상 좋은 선택은 아닐 수 있지만, 어느 상황에서 활용해야 적절할 지를 배울 수 있었고 어느 수준까지 FP 테크닉을 활용할 지도 때에 맞게 조절할 수 있게 되었다.

4. 라이브러리 개발

라이브러리 개발은 이전 회사에서도 했었지만, 그때는 모든 MSA 컴포넌트가 거의 완전히 동일한 기술스택을 사용했기 때문에 라이브러리를 만들 때 범용성에 대한 고민을 딱히 할 필요가 없었다. 하지만 지금 회사에서는 언어도 scala와 kotlin으로 나눠져 있고 프레임워크 또한 ktor, spring MVC, armeria, grpc-kotlin, spring webflux, zio 등등 다양하게 사용하고 있었기 때문에 라이브러리를 만들면서 범용성과 사용성을 동시에 챙기기 위한 구조에 대해 고민해야 했다. 사용성을 높이기 위해 각 프레임워크에 특화된 extension 라이브러리를 추가로 제공했는데, 이를 만드는 과정에서 위에 언급한 프레임워크들을 모두 다뤄본 것도 뜻깊은 경험 중 하나였다.

5. MSA는 환상인가?

2년전까지만 해도 MSA가 새로운 개발 트렌드로 부상했었는데, 최근에는 무분별한 MSA 도입은 오히려 득보다 실이 많다는 이야기가 많이 나오는 것 같다. MSA를 도입한다는 것은 인프라 구조만 변화시키는게 아니라 그 구조에 맞게 조직이 소통하고 협력하는 방식도 함께 변화시키는 것이기 때문에, 잘못된 MSA 설계는 사람 간의 커뮤니케이션 코스트를 급증시키는 부작용을 낳을 수도 있다.
올바른 MSA를 설계하는 기준이 무엇인가?에 대해 아직까지 정확한 답을 찾지는 못했지만, 가장 우선적으로 고려해야 하는 기준은 '데이터'인 것 같다. 각각의 마이크로서비스는 데이터 혹은 상태를 추상화한다. 여러 마이크로서비스가 하나의 데이터에 동시에 관심을 갖게 되면 이 서비스들 간에는 인터페이스 의존성이 심화되고, 의존성이 강한만큼 기민하게 협업해야 하는데 분리된 조직 구조로 인해 협업이 힘들어진다. 추상화하고자 하는 데이터가 다르지 않다면 대부분 물리적으로 컴포넌트를 분리할 필요 없이 코드 레벨에서 얼마든지 관심사를 격리할 수 있을텐데 지금 회사에서는 이렇게 하지 못한 것이 약간의 아쉬움으로 남는다. 어쨋거나 의존성을 최대한 떨어뜨려서 각 마이크로서비스가 독립적으로 개발 및 운영될 수 있게 하는 것이 MSA 설계에서 매우 중요하다고 생각하게 되었다.

기술 외적으로 배운 점

올해는 하나의 기능 조직을 리딩하고 동시에 프로젝트를 리딩하게 되면서, 코딩하는 것 말고도 신경써야 할게 참 많았던 것 같다. 너무 많은 책임이 주어지는 것에 대해 구조적인 개선이 필요하다고 생각하긴 했지만, 동시에 많은 것들을 접하고 느낄 수 있었던 것 같다.

1. 목적 조직의 필요성

우리 회사에는 기능 조직만이 명시적으로 존재했었다. 기능 조직이 존재함으로써 우리는 각 조직의 기술 & 도메인 전문성을 강화하여 더욱 양질의 코드 관리가 가능하다는 장점을 누릴 수 있다. 다만 하나의 제품을 만들기 위해서는 여러 기술 컴포넌트가 유기적으로 함께 동작해야 하며, 위에서도 얘기한 것처럼 MSA 구조에 맞추어 분화된 조직 구조는 기민한 협업을 어렵게 만들었다. 또한 제품이 완전하게 출시되기 위해서는 엔지니어들 뿐 아니라 BD, CS, MKT, PM, Design 등 많은 비개발조직의 참여가 필요하다. 제품의 출시라는 하나의 목적을 가지고 이에 필요한 모든 사람들이 모여 응집력 있게 움직이는 조직이 필요하다고 생각했고, 이는 기능 조직과 충분히 양립 가능하다고 생각한다.

2. 구성원의 motivation 유지하기

개인적으로 참 어렵다고 느끼는 부분이다. 회사에서 조직의 생산성을 높이기 위한 방안을 마련하는 시간을 최근에 가진 적이 있는데, 디테일한 액션 플랜들이 많이 나왔지만 그 중에서도 가장 중요한 것은 구성원들 모두가 일하는 것이 즐겁다고 느끼고, 의욕적인 상태로 일을 하게 만드는 것이라고 생각했다. 프로젝트를 진행하면서 나는 구성원들에게 기계적인 프로페셔널리즘을 기대했던 것 같다. 하지만 그런 것들을 기대하기 이전에 각각의 구성원들이 회사 생활을 통해 무엇을 얻길 바라고, 그들의 열정에 불을 지피는 요소가 무엇인지를 귀담아 들을 필요가 있지 않았을까 싶다. 하지만 그러기엔 내가 해야 할 일이 너무도 많았기에... 물리적으로 시간이 부족했다는 핑계도 머리 속에 떠오른다. 일을 제대로 끝내지 못할 것이라는 불안함이 앞서서 내가 일을 많이 하는 것에 집중하는 경향이 있었는데, 앞으로는 이런 문화적인 부분까지 챙길 수 있도록 좀 더 현명하게 시간을 활용해봐야겠다.

3. 코드를 제품으로 승화시키기

내가 만들었던 제품은 결국엔 개발자 도구(SDK)였기 때문에 제품 자체가 기술적인 면이 다분했고, 따라서 이를 완전히 이해하고 시장에 전달하는 역할 또한 내가 해야 할 일이었다. 이전까지는 코딩만 열심히 했었다면 이번에는 우리의 코드가 제품이 되기 위해 어떤 작업들이 이루어져야 하는지를 경험할 수 있었다. 제품의 스펙을 결정하고, 기능을 기획하고, 제품이 가지는 장점을 홍보하고, 판매 전략을 구상하는 등 보다 넓은 관점에서 여러가지 의사결정을 했고 조금 더 완전하게 한번의 제품 출시 플로우를 경험했다는 생각이 들었다.

올해 목표

국소적인 부분에서 열심히 노력하는 것도 좋지만 좀 더 자유롭게 많은 것들을 상상하겠다는게 작년 회고에서의 목표였는데.. 이 부분을 제대로 실천하지 못한 것 같아 아쉽다. 일을 열심히 할수록 내 상상력이 죽어가는 것 같아 불안함이 드는데, 이제 실무진으로서의 역량은 어느정도 만족할 만한 수준에 다다른 것 같다. 올해에는 실무를 넘어 내 상상력과 인사이트를 발휘할 수 있는 기회들을 만들어보고 싶다. 어떻게 만들지도 지금부터 생각해봐야 한다 ㅎㅎ