개발일지 (3월 회고)

 

 

Overview

어느덧 2022년 1분기가 끝나고 2분기를 맞았다. 하고 싶은 것들이 굉장히 많았던 한 분기였고, 그만큼 많은 것들을 해보았던 분기였던 것 같다. 한 분기 동안 경제, 독서, 운동, 조직문화, 비즈니스, 개발, 인프라 등등 이곳저곳을 기웃거렸던 것 같은데 "모든 걸 다 잘 해내야지"라는 느낌보다는 (실제로 그럴 수도 없다) 심리적인 요인에서든, 문화적인 요소에서든 인위적으로 타인이 그어놓은 "여기까지는 프론트엔드고, 여기까지는 경제학이고, 여기까지는 교육이야"라는 선을 넘나드는 일 들을 한번 해보고 싶었던 마음이 더 컸다.

 

실제로 어떤 목표를 달성하기 위해, 이를테면 언제까지 논문을 작성해야 하거나 언제까지 성과를 내야 하거나 아니면 언제까지 시험을 봐야 하니까 공부를 하는게 아니라 정말로 그 경계와 경계 사이를 오가면서 궁금증을 해소하려는 공부를 하다 보니 굉장히 열정적으로 뭔가를 재밌게 할 수 있었던 것 같다. 시험범위가 아니라서 더 그런거 같기도 하다.

 

일례로 프런트엔드 개발자로서 검색 결과를 표시하는 웹뷰를 "더 빠르게" 만들고 싶다고 할 때, 이를 기존에 널리 알려져 있는 "프런트엔드 개발자가 갖춰야 할 역량"의 관점으로 제한해서 해결하려고 한다면 할 수 있는 게 매우 제한된다. 캐시를 잘 쓰거나, 자바스크립트를 최적화한다거나 번들 사이즈를 줄이는 식의 접근이 가능할 것이다. (물론 이런 것들을 기본적으로 "잘" 하는 것은 당연히 중요하다) 하지만 "더 빠르다"는 것을 "유저가 느끼는"것의 관점(즉 행동심리학적 관점)에서 접근해 본다면 기다리는 시간을 "지루하지 않게"만드는 시도를 기획적으로 도입해 볼 수도 있을 것이고, 전체적인 검색의 파이프라인의 관점에서 생각해본다면 클라이언트 개발자분들과 잘 이야기해서 클라이언트에서 prefetch나 캐시를 잘 사용해서 웹뷰 로드에 필요한 데이터 자체를 클라이언트에서 미리 가지고 있는 방법도 이야기해 볼 수 있을 것이다.

 

 

 

Economics

이러한 관점에서 요새 가장 깊게 빠져있는게 경제학이다. 처음에는 소소하게 투자를 시작하면서 "내가 투자하고 있는 기업들의 가치와 그 기업들을 둘러싼 환경을 잘 이해해보자"의 관점에서 경제를 공부하기 시작했다. 환율은 무엇이고, 기업은 어떻게 돈을 벌고, 연준이 금리를 올리면 어떤 일들이 일어날 수 있는지 등에 대한 소소한 관심이었다. 

 

하지만 습관적으로 출퇴근할때 챙겨 듣는 여러 증시 방송들과 에세이들, 그리고 이러한 방송들과 에세이에서 흘러나오는 여러 이야기들을 내 것으로 만들고 제대로 이해하기 위해서 쓰기 시작한 에세이들이 쌓여가면서 점점 흥미가 붙기 시작했다. (역시 시험이 없어야 공부가 재밌는 것 같기도 하다.) 지금 달러의 위상은 어디서부터 시작되었는지, 금본위제는 무엇이고 브레튼 우즈는 무엇인지, 이러한 역사적인 사실들로부터 미루어봤을 때 이후의 통화의 패권은 어디로 갈 수 있을 것인지, 비트코인이 달러의 패권을 차지할 가능성에 대한 이야기들이 나오는데 이러한 이야기들은 어디에 근거하고 있는 것인지 등등 누가 시키지도 않았고, 예측하기도 어려운 것들을 혼자 상상해보고 나름대로의 근거를 갖춰 정리하는 일들을 시작했고, 이런 일들을 반복하면서 스스로를 설득시키는 일에 재미가 붙은 것 같다.

 

경제를 공부하면서 얻은 중요한 교훈 중 하나는 "경제도 다 사람 사는 일"이라는 것이다. 시장은 "절대로" 이성적으로 흘러가지 않고, 그렇기 때문에 그렇게 똑똑하지 않은 나도 무언가를 얻어갈 수 있고, 매우매우 똑똑한 사람도 많은 것을 잃을 수 있는 것이다. 이를테면 똑같이 0.5%의 금리를 올리더라도 시장이 연준을 신뢰한다면 "Buy the Deep" 신화를 만들어내며 잘 버텨줄 수 있겠지만, 시장이 연준을 신뢰하지 못하고 성장을 의심한다면 증시가 휘청일 수도 있다. 게다가 정치적으로 "경제 성장"을 만들어내야 하는 행정부의 압력과 개발 도상국의 경제 성장, 특정 국가의 돌 발행 동등 전혀 예측할 수 없는 "카오스적인" 상황들이 매우 매우 흔하게 발생하고 있기 때문에 이런 상황을 예측하고 대응하기란 여간 쉬운 일이 아니다.

 

"이런이런 상황이 올 것이다"에 베팅하는 사람들의 입장에서야 머리가 깨질 것 같고 오금이 저릴 정도로 긴장이 되겠지만, 그런 걱정 없이 시장을 그냥 지켜보면서 "이런이런 일이 발생하니까 이런 나비효과들이 생기는구나" 를 정리하고 나름대로 근거를 붙여보는 일은 꽤나 재밌고 유익하다. (경제를 공부하다 보면 왜 안티프래질의 저자가 그렇게 안티프래질을 강조하는지 조금은 이해가 되는 것 같기도 하다)

 

 

Infrastructure

1분기 목표였던 Kubernetes in Action의 18개 Chapter를 모두 끝냈다. 사실 끝냈다는 개념 자체가 좀 애매하긴 하다. 그냥 책을 한권 다 읽고, 실습을 한 번씩 따라 해 보면서 블로그에 정리한 정도이다. 아직 시스템 프로그래밍이나 운영체제 같은 전공과목을 제대로 듣지도 않았고 도커도 아직 제대로 모르는 상황에서 무작정 뛰어들었는데 어떻게든 기를 쓰고 이것저것 찾아보고 여기저기 물어가며 끝냈다는 게 중요했던 것 같다. 

 

전체적으로 원서를 한번 읽으면서 쿠버네티스가 뭐고, 어떻게 구성되어 있고, 어떤 문제를 해결하기 위해 어떤 방법들을 들고 나왔는지에 대한 대강의 흐름을 익힐 수 있었던 것 같다. 마침 사내의 웹서버(SSR을 위한)들이 클러스터로 구성되어 있어서 실제로 사내에서 특정 챕터의 내용을 어떻게 이용해서 반영했는지를 바로바로 확인할 수 있어서 많은 도움이 되었다. 

 

가장 인상적인 개선이라고 한다면 전체적인 흐름에 대한 그림을 어느 정도는 그릴 수 있게 되었다는 것이다. 그냥 "여기는 데브옵스팀의 영역"이니까 알아서 잘해주겠지에서 "문제를 구체화해서 정말로 데브옵스팀의 도움이 필요한(여기서의 도움은 "권한"을 의미한다) 경우에만 요청하고 내가 해볼 수 있는 건 내가 해보자"로 바뀌었다. 마침 회사가 구글 투자를 받으면서 AWS에서 GCP로 조금씩 조금씩 넘어가고 있는데 이때 프런트엔드 팀에서 이전해야 하는 것들을 조금씩 챙길 수 있는 기회가 생겼고, Cloudbuild, CloudFunction, AppEngine, CloudScheduler 등을 이것저것 시도해보면서 프런트엔드 팀에서 가지고 있는 여러 웹서버들과 Static Asset들을 관리하고 조직하는 일들을 하고 있는데 꽤 재미가 붙어서 즐겁게 하고 있다. 

 

최근에는 도커에 대해 이것저것 질문을 많이 받고 있는데 사실 나도 잘 모른다. 그래서 Docker in Action 스터디도 같이 시작했다. 이제야 챕터 2개 정도를 끝낸 상황이라 더 해봐야 알겠지만 확실히 컨테이너 오케스트레이션을 다룰때보다는 컨테이너를 다루는 게 조금 더 가벼운 느낌은 드는 것 같다. 쿠버 네티스를 잘 끝냈으니 도커도 잘 끝내겠지 하는 경험에서 오는 은근한 자신감도 꽤 도움이 되는 것 같다.

 

 

 

Frontend Team

"좋은 팀"이란 무엇인가에 대해서 최근 끊임없이 고민을 했던 것 같다. 요즘에 유난히 여기저기서 "개발"에 대한 이야기만큼이나 "비즈니스"에 대한 이야기를 많이 하는데, 생각해보면 나도 "프론트엔드 개발을 잘하고 싶다"라는 느낌으로 일을 하는 건 아니다. 나는 그냥 "문제를 해결하고 싶을"뿐이다. 그것도 "잘".

 

그렇다면 문제를 "잘" 해결하려면 어떤 순서로 접근해야 할까.

우선 내가 풀고 싶은 "문제"가 무엇인지를 명확하게 정의하는 것이 매우(어쩌면 가장) 중요할 것이다. 문제를 정의하는 것이 중요한 이유는 문제를 어떻게 정의하고 어떻게 쪼개느냐에 따라 똑같은 문제도 접근하고 해결할 수 있는 방법이 달라지기 때문이다. 가령 "내 동생이 아이스크림을 먹고 싶다"라는 문제가 있다고 했을 때, "아이스크림을 먹고 싶으니까 사준다"라는 식의 접근도 가능하지만 "내 동생에게 아이스크림이라는 건 어떤 의미를 갖는가", "만약 내 동생이 아닌 우리 엄마가 아이스크림을 먹고 싶다고 하신다면 그것은 이것과 동일한 문제인가", "아이스크림 대신에 빵을 사 와도 문제를 해결할 수 있을 것인가?", "동생이 원하는 아이스크림의 정의는 무엇인가?(그냥 물에 설탕 넣고 얼린 것도 아이스크림인가)", "동생이 아이스크림을 원하는 근본적인 요인은 무엇일까?"(유튜브에서 누가 아이스크림을 맛있게 먹는 걸 봤다든지, 아니면 그냥 갑자기 "베스킨"이라는 단어를 어디선가 들었는지 배스킨라빈스가 연상이 되었다든지)와 같은 접근도 가능할 것이다.

 

회사가 "공평한 교육"에 대한 문제를 풀려고 하고 있는 만큼 나도 이 문제를 풀고 싶었던 것 같고, 이 문제를 풀기 위해 입사 당시 내가 가지고 있는 도구가 "프론트엔드 개발"이어서 프런트엔드 개발을 하고 있지만, 가장 중요한 건 "공평한 교육"에 대한 문제를 "푸는 것이"다. 따라서 기술적인 성장만큼이나 이 문제 해결에 대한 "고민"을 하는 것이 중요하다고 생각하고, 팀원들도 그랬으면 하는 바람이 있다. 정말 간절하게 이 문제를 풀고 싶다면 자다가도, 책을 읽다가도, 어떤 강의를 듣다가도 교육과 연결시키게 되고, 이 연결점들이 모여서 문제를 더 작은 문제로 쪼개고, 정말 필요한 곳들에 기술을 "잘" 적용할 수 있지 않을까.

 

작년 말에 막연하게 이런 생각을 가지고 팀 문화에 많이 신경쓰기 시작했던 것 같다. 팀원의 성장이 곧 내 성장이라고 생각하고, 팀원이 나보다 뛰어나다면 회사는 "공평한 교육"이라는 문제를 풀기 위한 더 좋은 도구를 가진 것이 아닌가. 이런 목표 하에서 팀원들끼리 교육에 대한 이야기, 문화에 대한 이야기를 부쩍 많이 나누게 된 것 같고, 어떻게 하면 "공평한 교육"을 "전 세계 사용자들"에게 "빠르고 부드럽게" 제공할 수 있을까의 문제를 최우선 순위로 올려서 스터디도 하고, 리뷰도 하고 이것저것 하는 것 같다. 팀 내에서 모노 레포로의 전환,  TDD + BDD를 통한 애자일 개발의 실천적 도입, 디자인 일관성 및 UX일관성을 갖추기 위한 디자인 시스템의 연구, 빠르고 가볍게 "자주" 리뷰할 수 있도록 만드는 코드 리뷰 시스템 개선 등을 진행하고 있는데, 각각의 개선들이 모두 위의 목표를 달성하기 위한 하나의 퍼즐 조각으로 진행되고 있다. 아마 2분기가 끝날 때쯤이면 문제 해결에 조금은 더 가까워질 것 같다는 막연한 생각도 든다.