2022년, 개발 4년차 회고

개발을 시작한 지 4년, 블로그를 시작하고 4번째 회고가 되었다. 올해는 학생이 아닌 상태로 상태 전환이 발생하기도 했고, 어느 순간부터 마음속에 있던 삶의 마일스톤 중 하나를 해결한 것처럼 느껴지기도 한다. 지난 21년 회고를 거의 1분기가 끝나고 썼던 터라 이번 회고가 좀 짧게 느껴지긴 하지만 아무튼 그 이후(혹은 일부 포함해서) 어떤 일들이 있었나 정리해보려고 한다.

회사에서 하는 일

지난 회고를 쓴 4월부터 회사에 다니고 있고 플랫폼 엔지니어링 팀에 있다. 이전 인턴을 했던 팀도 그 당시에는 플랫폼 조직이었는데, 그때 영향을 받아 플랫폼 조직에서 일하고 싶어 했다. 시간은 좀 흘렀지만, 올해 취업을 준비했던 사람으로서 플랫폼 조직이 유난히 경력을 보는 경향이 있다고 느꼈다. 회사마다 이유는 다르겠지만 요구사항들이 일반적으로 쉽지도 않고 만들어지는 프로젝트들이 영향을 주는 범위가 넓다 보니 안전하게 개발할 수 있는 능력을 갖추고 있어야 하기 때문이라고 생각한다. 관련된 경력이 그렇게 많은 편은 아니었지만, 주니어로서 입사할 수 있었다.

플랫폼이라는 말은 조금 모호하게 들릴 수 있다. 실제로 업무 범위도 모호하다. 보통 사내의 회색 영역이라고 불리는 어떠한 팀에도 속하기 애매한 영역의 개발을 맡는다고 생각하는데, 이런 정의조차 모호하다. 그래서 실제로 JD를 살펴보면 회사마다 이를 정의하는 방법이 다양하다.

내가 취업을 준비하던 시기에 생각하던 플랫폼을 조금 더 구체적으로 서술하자면 서비스들이 공통으로 사용하는 도구들, 예를 들어서 Push 알림(메시징), 지리 정보, 인증, 미디어 서비스를 만드는 것으로 생각했다. 현재 회사의 플랫폼 조직은 그런 역할은 아니고 인프라 레벨의 공통적인 문제를 해결하는 조직이다. 예를 들어 멀티 클러스터 안에서 서비스 디스커버리 서비스, 로깅 파이프라인, 배포 도구 같은 걸 만든다. 이 팀에 처음 왔을 때는 뭔가 SRE 조직 같다는 생각도 들었다.

CTO님이 플랫폼 조직에서 서비스 영역의 개발을 하는 것이 이상하다고 느끼셨다고 들었다. 해외에서 개발하다가 오신 분들이 공통으로 이런 얘기를 하시는 걸 보면, “플랫폼”이라는 팀이 해외에서는 뭔가 인프라 엔지니어링을 하는 그런 느낌이 있나 보다. 이전 인턴을 하던 회사에서도 비슷한 이유로 “플랫폼”이라는 이름을 버리고 “서비스 코어”? 이러한 이름으로 변경된 것으로 알고 있다. 우리팀 역시 서비스 조직에서 직접 가져다 쓰는 컴포넌트를 개발하는 조직으로 “서비스 컴포넌트” 조직을 새로 만들었다.

생각하던 업무 범위는 아니었지만, 오히려 재밌었다. 지금 회사는 규모상 확장을 준비하고 있는 단계라고 느껴진다. 글로벌 서비스도 준비하고 리텐션을 유지하기 위한 여러 전략도 준비 중인 것 같다. 취업을 준비하던 시기에는 이 회사가 구체적으로 어떻게 비즈니스 발전이 있을 예정인지까지는 몰랐지만, 마이크로서비스가 도입되고 있다는 것까지는 알 수 있었다. 이 단계에서 플랫폼 팀의 업무인 쿠버네티스 컴포넌트를 개발한다든지, 인프라에 도입되는 것들을 개발하는 것 등은 경험하기 쉽지 않으리라 생각해서 지금 회사에 오게 되었다. 지금 업무에 대한 만족도는 꽤 높다.

사이드 프로젝트

언제나 그렇듯 사이드 프로젝트를 시작했다. 이번 사이드 프로젝트에서는 쿠버네티스에 어느 정도 익숙해지기 쿠버네티스를 사용해 서비스를 배포할 목적을 가지고 있었다. 그렇게 크지 않은 서비스지만 억지로 프로젝트를 나눠서 개발했다. 서비스는 거리 기반 공동 구매 플랫폼이다. 실제 시작할 때는 굉장히 유망할 것 같은 생각이 많았는데 바로 배민, 쿠팡, 당근마켓 등이 비슷한 컨셉의 서비스를 공개하고 있다. 공부 목적으로 개발하는 거지만 뭔가 아쉬운 느낌이 들었다.

이번 사이드 프로젝트는 꽤 많은 사람하고 시작했는데, 약 6명이 같이 시작했다. 클라이언트 개발을 도와주는 팀원 두 명과 백엔드 두 명, 디자인해주는 친구 한 명과 나까지 총 6명이었는데, 지금은 백엔드 해주시는 분이 한 분 나가시고 5명 체제로 여전히 진행 중이다. 사이드 프로젝트를 팀원들과 하는 이유는 혼자 하는 사이드 프로젝트를 지속하지 못할 것 같았기 때문인데, 지금까지 내가 하는 패턴을 보니 지속할 수 있었을 것 같다. 프로젝트 주제가 재밌어서 그런지 뭔가 계속하게 된다. 지난해 사이드 프로젝트를 할 때 잘 모르는 분들과 시작하지는 말아야겠다고 생각해서 모두 지인분들과 같이 했다. 확실히 프로젝트 진행이 원활하기도 하고 프로젝트 회의나 프로젝트를 같이 진행하는 날이 되게 재밌다.

혼자 진행하는 것과 팀으로 진행하는 것은 뭔가 다른 방면으로 장단점이 있긴 한 것 같다. 혼자서 진행했다면 이미 프로젝트를 완성했을 것 같다. 하지만 사이드 프로젝트를 하는 목적과 다른 여러 가지를 같이 해줘야 하기도 하고 비교적 지루하다. 팀으로 하는 것은 재밌으나 느리다. 우리 모두 이 작업에 몰두하고 있다면 얘기가 다르지만 서로 투자할 수 있는 시간도 다르고 서로에 의해 블로킹 되는 경향도 있기 때문에 점점 느려지는 것 같다.

스터디

이번에도 스터디를 많이 시작했다. 기술 세션을 일정 기간 진행했고 데이터 중심 애플리케이션 설계, Rust In Actions, Database Internals 책을 읽었다.

4월 5월쯤부터 데이터 중심 애플리케이션 설계 스터디를 시작했다. 다른 한 분과 같이 했는데, 각자 챕터를 나눠서 내용을 정리하고 발표했다. 해당 챕터는 각자 읽어오기는 하지만 발표를 맡은 챕터는 심도있게 이해하고 정리해가는 스터디였다. 책 내용이 워낙 어려워서 각자 맡은 챕터에 집중해서 공부하는 것과 다른 사람이 꼼꼼히 이해한 다음 이해하기 쉽게 설명해주는 게 생각보다 도움이 많이 됐다. 책 내용도 데이터베이스의 분산 환경의 사용과 관련된 내용이 많이 있었는데, 재밌어하는 주제라 스터디가 더 재밌었던 것 같다.

기술 세션은 각자 2, 3주 정도 텀을 가지고 기술 학습을 해서 세션을 준비해오는 구조였는데, 이런 비슷한 스터디를 몇 번 했던 적이 있어서 블로그로 쓰려고 했던 내용이나 이전 세션에 했던 내용 등을 다듬어서 발표했다. 세션을 많은 사람과 진행한 것이 아니라서 타인으로부터 매우 많은 정보를 얻을 수는 없었지만, 이 세션을 준비하면서 특정 주제에 대해 또 깊게 공부해볼 기회가 되어서 개인적으로 만족스러웠다. 기술 세션을 진행하다가 Database Internals 책을 읽는 스터디로 바뀌었다. 이 책도 데이터 중심 애플리케이션 설계 책하고 아주 비슷한 내용이 많이 섞여 있어서 뭔가 복습이 되는 것도 있고 조금 더 깊게 공부하는 것도 있다. 특정 DB 애플리케이션에 종속적이지 않은 DB 내부적인 이야기를 학습하는 것이라 재밌게 읽고 있다. 현재도 진행 중이지만, 이후 나올 원격 근무로 인해 잠시 정지 상태이다.

Rust 스터디는 Rust In Action을 공부하는 것을 목표로 했지만, Rust를 처음 만져보는 입장에서는 Rust가 공식적으로 제공해주는 The Rust Programming Language 책을 읽는 게 좋다고 판단해서 이 책을 읽고 있다. 스터디에서는 일단 문법을 공부하는 시간을 한 달 반 정도 진행했는데, 지금까지 배웠던 언어 중에서 Rust가 제일 공부할 게 많은 것 같다고 느낀다. 이전에 Kotlin을 공부할 때 이렇게 느꼈는데 코틀린은 뭔가 Helper 같은 도구가 많은 것처럼 느껴졌는데, Rust는 그냥 언어 자체가 조금 복잡한 듯한 인상을 받았다. Rust는 내가 좋아하는 특징과 싫어하는 특징을 모두 갖추고 있다. Go를 좋아하는 나는 언어가 복잡도가 높다는 점이 굉장히 불호인데 강한 타입과 안전한 프로그램을 위한 특징들은 굉장히 마음에 든다. 복잡하다는 건 어느 정도 학습으로 커버가 가능할 것이라 믿어서 지금까지 스터디는 이어지고 있다. 대충 문법들은 마쳤는데, Rust In Action 책에서는 시스템 프로그래밍을 하는 내용이 반 이상이라 그 부분을 시작했다.

---

4월에 썼던 회고에서도 어떻게 기술을 바라봐야 하는가, 어떻게 학습해야 하는가에 대한 기준이 생겼다고 했는데 이 기준은 여전히 유지되고 있다. 깊게 공부하는 습관을 들여서 여러 스터디와 기술 학습에 적용하면서 이전까지 가지고 있던 마일스톤을 달성한 것 같다. 마일스톤은 “기술적 목마름”이라고 내가 이전부터 표현하던 것인데, 도달하고 싶은 기술적 능력치가 어느 정도 있고 이를 달성하는 것을 의미했다. 이 마일스톤을 달성했다는 것은 그럼 목표로 하던 “어느 정도의 기술적 능력”을 갖춘 것일까? 그렇지는 않다. 여전히 부족함을 많이 느끼기도 하고 공부할 것 자체가 너무 많다. 하지만 이렇게 공부하면 “기술적 목마름”을 해결하는 방향으로 나아간다는 것을 느꼈다. 그전에는 “기술적 목마름”이 경험에 의해 채워질 수 있다고 생각했는데, 내가 원하던 것은 이런 학술적인 접근을 통해 이룰 수 있는 경지였던 것 같다.

주변 시니어분과 경력이 기술적 측면의 목표를 달성하기에 중요한 것일까에 대해 얘기를 나눈 적이 있는데, 시니어분은 플랫폼 개발 말고 트래픽도 관리해보고 장애도 맞아보는 것이 많이 가르침을 주기 때문에 경력이 중요한 것 같다고 하셨다. 정확히 맞는 말이라고 생각하지만, 다시 생각해도 내가 원하는 기술적 목표 달성은 학술적인 접근으로 달성하는 것 같다. 경험으로 얻을 수 있는 능력치와 깊은 학습으로 얻을 수 있는 능력치가 겹치는 부분도 분명히 있으나 각자가 강화 해주는 영역이 다른 것 같이 느껴진다.

이게 항상 머릿속으로 생각하던 거라 글로 썼을 때 온전히 전달이 안 될 수도 있다. 무슨 얘기를 하는 걸까 싶을 수도 있지만… 결론은 올해 나는 아직 내가 정해둔 기술적 경지에 도달한 것은 아니지만 도달하는 방법을 알았다고 느꼈다.

그럼, 마일스톤을 달성한 것이 맞느냐? 아직 기술적 목표에 도달한 것은 아니지 않는가? 하지만 이 과정은 내가 개발하는 동안 무한히 지속되어야 한다. 이를 달성하겠다는 말은 애초에 불가능하다. 방향을 정확히 맞춰놓고 나아간다는 것으로 충분히 마일스톤 달성에 체크를 해도 좋을 것 같다.

네이버 부스트캠프 코드 리뷰어

이번 해 하반기 조금 넘어서 한 달 조금 넘는 기간 동안 네이버 부스트 캠프 코드 리뷰어로써 활동했다. 경력을 기록하는 단계가 있어서 지금까지 돈을 받으면서 일한 기간이 얼마나 되는지 정리하는 시간을 가졌다. 그 당시 기준으로 한 2년 몇 개월이 나왔던 것 같은데, 지금은 거의 3년이 되어갈 것 같다. 연차가 중요한 건 아니지만 평소에 스스로의 처우에 대해 생각할 때 항상 1년 중간쯤 했나? 라는 기준으로 생각했는데, 앞으로는 정확히 기간에 대해 인지해야할 것 같다.

아무튼 다행스럽게 네이버 부스트 캠프에서 코드 리뷰어로 선정되어 학생들의 코드를 리뷰했다. 리뷰 내용은 사실 그렇게 대단하지 않기도 하고 도움이 얼마나 됐는지 잘 모르겠지만 리뷰를 받는 학생분들과 따로 티타임 비슷한 시간을 격주에 한 번 정도 다양한 사람들과 진행했는데, 이때 얘기했던 것들이 내가 학생이었다면 더 들어보고 싶었던 내용들이 아니었을까 싶었다. 개인적으로 보람차기도 했고 재밌던 시간을 보낸 것 같아 다음에도 이러한 기회가 생기면 다시 해보고 싶다.

Working From Anywhere

지금 일하고 있는 회사는 6개월에 한 달은 출근을 하지 않고 어디서든 일을 할 수 있는 제도가 있다. 이를 Working From Anywhere(WFA)라고 부른다. 원래 여행을 그렇게 자주 하거나 즐기는 편은 아닌데, WFA를 하는 김에 오래전부터 해보고 싶던 해외에서 디지털 노마드를 준비했다. 그리고 이왕 비행깃값 쓰는 김에 12월과 1월 WFA를 붙여서 갔다 오기로 했다. 해외에 가서 WFA를 한다고 일을 제대로 못 하는 것으로 평가가 된다면 앞으로 해외로 WFA를 하기 눈치가 보인다든지, 조금 과장되어 아예 제도가 폐지되어버릴 수도 있으므로 국내에서 일하는 것보다 더 잘해야겠다고 생각했다. 그래서 지낼 국가를 선택할 때 기준은 다음과 같았다.

• 업무를 할 수 있는 공간 (무선 인터넷, 책상, 혼자 쓰는 공간 등)
• 업무를 수행한 다음에는 어느 정도 여행을 할 수 있는 시간 (적절한 시차)
• 한 달 살이를 하기 적절한 생활 물가, 좋은 날씨

이렇게 고르고 나니까 그리스와 포르투갈 정도로 선택이 되었다.

이 계획을 짤 때까지만 해도 서머타임이 적용되고 있어서 포르투갈도 새벽에 일어나서 일할 수 있다고 생각하는 범주에 들어왔다. 하지만 지금은 잘 모르겠다. 이제 곧 포르투로 이동하는데 해봐야 할 것 같다.

그래서 현재는 그리스에 있다. 1월 초까지 그리스에 있고 그 이후부터 2월 초까지는 포르투갈에 있는다. 아테네에서 한 달을 지내고 있고 주말에는 여기저기 근교나 섬에 가보고 있다. 아테네에 도착한 초반에는 너무 바쁘게 지내서(엄청난 스터디로 인해) 관광 시간을 낼 수가 없었다. 그래서 지금은 Rust만 진행하고 있고, Database Internals 스터디와 알고리즘은 멈췄다. 개인적으로 WFA는 굉장히 만족스럽다. 바쁘게 지내던 시점에서 조금 벗어나서 혼자 여행하니까 현재 상황에 대해 생각해볼 시간이 조금 늘어난 것 같다. 그리고 여유롭게 여행하기도 하고 쉬기도 하고 하면서 컨디션을 적절히 조절하면서 여행이 가능하다. 한국 시간대로 일을 하다 보니 일찍 잠을 자야만 하는 단점도 있는데, 그리스 시차 정도는 여행과 일 모두 가능한 정도로 느껴진다.

여유롭게 한국에서 여유롭게 살았어도 얻는 장점 아닌가? 라고 생각이 들 수도 있으나… 한국에 있으면 절대 여유롭게 살 생각이 안 들었을 것 같다.

하지만 비용은 만만치가 않다. 새벽에 일어나고 업무 공간이 있어야 한다는 것 때문에 에어비엔비에서 집을 30일씩 빌려서 쓰는데, 이 값이 가장 큰 것 같고 외식을 주로 하다 보니 유럽 외식 비용을 감당해야 한다.

이번 해의 목표

아테네에 있으면서 실존적인 고민을 많이 하게 되었는데, 마일스톤을 이룬 것과도 연관이 된다. 현재 고민이 많던 기술적 목마름을 어느 정도 해소했는데, 이걸 계속 지속하는 것이 10년 뒤의 내 모습이라면 만족할까? 혹은 현재 수행하고 있는 일을 10년 정도 한다고 하면 내가 원하는 모습이 되어있을까? 하는 질문을 많이 하게 되었다. 일단 질문을 많이 했다는 것 자체가 그렇지 않을 것 같다는 생각 때문인데, 마땅히 무엇을 해야겠다는 결론은 당연히 안 나온다.

고민 끝에 원초적으로 다음으로 이루고 싶은 목표가 “훌륭한 팀을 만들어보고 싶다”라는 결론에 이르렀다. 논리적인 이유는 딱히 없고 내가 “왜 예전부터 어떤 조직을 만들어서 도전해보길 원할까?”라는 생각을 했는데 그 과정 중 어떤 포인트에 가장 매력을 느끼는 건지 고민해보다가 나온 결론이다. 관련된 얘기를 지인과 했는데, 똑똑한 사람들과 모여서 문제를 해결하는 과정을 겪는 건 원초적으로 재미를 느끼는 요소일 수밖에 없다는 얘기를 했다. 생각해보면 원시 부족을 이루던 시기부터 훌륭한 팀원을 모아서 부족을 유지하는 그 욕구가 DNA로 박혀있을 것 같다. 내가 생각한 나의 원동력이 굉장히 원초적인 욕구로부터 왔다고 생각하니 실존적 고민의 결론이 잘 도출된 것 같은 생각이 든다.

그래서 목표는 무엇인가? 첫 번째로는 회사든 어디서든 새로운 사람들을 많이 만나볼까 한다. 보통 이런 성격이 아니라서 사람들을 사귀는 것을 목표로 삼은 적은 없는데 이번 해에는 한 번 노력해보려고 한다. 두 번째는 개발 말고 다른 것을 개인적으로 해볼까 한다. 뭘 해볼지는 안 정했는데, 다른 영역에 대한 경험이 좀 필요한 것 같다는 생각을 여행하러 와서 많이 하고 있다.