2021년 회고

2021년 한 해 뭘했고 뭘 느꼈는지 짧게 정리 해본다.
2020년에는 제주에서 바다보며 했었는데… 이번에는 제주까진 못가고 마포에서 한강을 보고있다.
그냥 머리 속에 떠오르는 지난 날의 굵직한 것들을 가지고 의식의 흐름대로 회고를 써보려고 한다.

마포역 채그로라는 카페다. 한강 뷰가 좋다.

어떻게 써볼까 생각하다가 회사에서의 일들이 내게 기준점이 되기 좋은거 같아, 회사에서의 일들과 회사 밖에서의 일들을 나누어 본다.

---

1. 회사 안에서

1) Airflow on Kubernetes Migration

20년 말 쯔음에 Airflow on Kubernetes를 GKE 위에 구축했다. 이후 기존의 Airflow DAG들과 Connection 등을 모두 이 새로 띄운 Airflow로 Migration 해야 했는데, 이 과정에서 내가 가이드라인(DAG 이름 규칙, 커밋 규칙, 실행 환경 설정 등)을 정의하고 이에 대해 서포트를 해줬다. 서포트를 해줬다는 건, 내가 다 직접 일일이 다 Migration 한게 아니라 DAG의 작성자에게 이를 새로운 DAG Repo로 옮겨달라고 요청하고 이 과정 중에 필요한 설명이나 작업을 같이 해주었음을 말한다.

Migration하는 DAG 작성자에게 설명해야하는게 은근 많았다.
먼저 기존에는 GitHub 없이 바로 Airflow가 떠있는 VM에 붙어 작업했다면, 이제는 모든 수정 이력을 Git Commit으로 관리하니, 일단 작성자에게 Git에 대해 어느정도 이해시키고 작업 중 이러나는 Git 트러블 슈팅을 같이 해줘야 했다.
또한 Kubernetes 환경에서는 DAG 실행에 대한 디버깅이 어려웠는데, 실제로 에러가 나면 내가 일일이 로그를 확인하며 어디가 에러났는지 알려주곤 했다. 특히 Airflow에서 Remote Logging을 사용하게 되면 실행 중일 때는 로그를 볼 수가 없다. 성공하거나 실패하거나 여하튼 실행이 끝나야지 볼 수 있어서, 기다릴 겸 다른 작업하며 틈틈이 계속 봐야만 했다.

Repo의 main 브랜치로 머지될 거의 모든 PR을 내가 본거 같다. 파이썬 코드에 어노테이션을 반드시 붙이게 했으며, DAG 이름은 README에 안내한대로 잘 적었는지, 네이밍이 이상하지는 않은지 나름대로 잘 리뷰했다고 생각한다. (물론 지금와서 보면 내가 정 가이드라인이 최선이었나 싶은 것도 많다.)

여하튼 조금 지루한 작업이긴 했지만, 그래도 서포트 위주의 일상이다보니 나에게는 조금 여유가 있는 때이긴 했다. 이 때 이제 회사 테크 블로그 글도 2개나 쓰며, 지금까지 해온 것들을 글로써 정리해볼 수 있었다.

 

2) 새로운 팀원들의 합류

3월에는 험프리가, 5월에는 그랩이, 그리고 8월에는 디니가 팀에 새로 합류했다. 모두 주니어 레벨의 연차이며, 드디어 나도 팀 막내를 탈출하게 되었다.

새로운 사람이 팀에 들어오는 건 설레는 일이었다. 동시에 내가 그동안 팀에서 해온 것들이 그 분들에게 노출되고 평가될 수 있기에 조금 긴장되기도 했다. 신규 입사하신 분들에게 우리 팀의 첫 인상은 어떨지, 그리고 앞으로 어떻게 팀을 어떻게 같이 발전시킬 수 있을지 기대가 됐다.

실제로 이 세 분이 팀에 합류한 후, 팀은 기술적으로나 문화적으로나 많이 발전했다.
험프리는 입사하자마자 바로 적응하여 며칠 뒤 금방 최초 커밋을 찍게 되었고, SQL 기반 파이프라인에 의존도가 높은 우리 팀에게 DBT라는 새로운 도구를 제안하기도 했다. 여기저기 새로운 기술과 뉴스를 트래킹하고 있으며 팀에 필요한 도구를 찾아 PoC도 척척 실행하고, 개인 GitHub Repo에서 이것저것 실험한 뒤, 팀에 제안하는 모습은 내게 꽤나 영감을 주었다. 이런 것에 영감을 받는 나도 이미 고여버린건가 싶은 생각이 들기도 했으나, 아 나도 다시 열심히 해야지라는 생각이 더 크게 들었다.

그랩 역시 팀 성장 문화에 아주 관심이 많았는데, 입사 기념 선물로 팀원 모두에게 “함께 자라기, 김창준” 책을 주기도 했다. TIL도 몇 달간 계속해서 꾸준히 적으며, 자신이 배운 내용을 공유하고, 이를 팀 내에 문화화 하여 WWL(Weekly We Learn) 시간을 만드려고 하는게 매우 인상깊었다. 어느 팀에가도 환영받고 사랑받을 팀원이 이런게 아닐까 싶다는 생각이 들었다.

디니는 입사하고 처음으로 팀에서 만든 온보딩 과제를 받은 분인데, 팀에서 사용 중인 기술에 대해서 금방금방 적응하셨다. 특히 트러블 슈팅이나 깨달아가는 과정을 노션에 모두 기록하시는데, 이 기록들이 매우 자세하고 잘 정리되어 있어 인상 깊었다. 성격도 활발하시고 이런저런 피플 프로그램의 기획이나 MC도 잘 맡으실 성격이셔서 그룹의 문화를 더 밝게 빛내주실 분이라는 생각이 든다. 그랩과 비슷하게, 단순히 엔지니어링만 관심 가지신 분은 아닐거 같아 앞으로의 행보가 더 기대되는 분이다.

카일, 그랩, 험프리 공동 아지트인 "줄.거.리". 구의에 있다.

팀장 토마스는 팀에 잘 맞는 사람을 참 잘 채용하신다는 생각이 든다. 어떻게 이렇게 결이 비슷한 팀원들을 잘 모으셨을까. 앞으로 또 어떤 분들이 팀으로 합류할지 궁금하다.

 

3) MLOps TF

4월에는 새로 생기게된 MLOps TF에 합류하며, MLOps 관련 작업도 하게 되었다.
TF에 합류한 사람은 카일, 토마스, 나, 험프리였고, 좀 더 쉽고 체계적인 ML 모델 서빙을 목표로 하여 시작하게 되었다. 구체적으로는 SoMLier라는 MLOps 도구를 개발하기로 했다.

이 과정 중에 리서치로 MLflow, BentoML, Feast, DVC 등 MLOps와 관련된 여러 오픈소스들을 찍먹해보기도 했다. 와 이런 것도 있구나, 생각보다 잘 되있다, 이건 사용성이 좀 구리다, 나도 이런 거 만들어보고 싶다 등 퇴근하거나 주말에 리서치하고 블로그에 정리하면서 재밌었던 기억이 난다. 오픈 소스는 ‘찍먹’까지는 참 재밌는거 같다. (실제로 프로덕션 적용하며 트러블 슈팅하면 스트레스 ON 이지만…)

여하튼 SoMLier를 험프리와 같이 개발하며 본격적인 코드 리뷰와 설계 고민을 나눠볼 수 있었다. 험프리는 나랑 연차는 비슷하지만 나보다 매우 잘하기 때문에, 이런저런 실질적인 조언을 듣고 많이 배울 수 있었다. 페어워크도 이번에 처음 시도해보면서 느낀건데, 같이 개발하는게 너무 재밌다. 생산성을 높이기 위해 어떤 도구를 사용하고, 어떤 생각의 흐름으로 개발을 진행하는지도 볼 수 있고, 내가 별 생각없이 쓰던 단축키나 도구가 같이 진행하는 팀원에게 꿀팁이 되면 뿌듯하기도 했다.
험프리를 비롯해 팀원들과 이렇게 리뷰와 고민을 공유하고 페어워크를 자주 진행하다보니, 나중에는 코드의 결이나 네이밍 짓는 것도 좀 비슷해지고, 팀원이 짠 코드를 봐도 왜 이렇게 짰는지 금방금방 이해가 되었다.

MLOps TF는 현재까지 진행되고 있으며, 내년에도 계속될거 같다. 아직까지 드러나는 성과는 없지만, 앞으로는 더욱 더 제대로 해보고 싶은 테스크 중 하나다. 언젠가 이 프로젝트를 오픈소스로 공개하고, 파이콘에서 발표하게 될 날을 기대하며.

 

4) 대여 가격 시스템 FE + BE

대여 가격 시스템은 회사에서 나랑 정말 뗄래야 뗄 수가 없나보다. 입사하자 참여한 개발 프로젝트 였는데, 아직까지도 여전히 내가 전담하여 필요에 따라 개발하고 유지보수하고 있다.

처음에는 단순히 “가격을 계산하고 이 값을 조회”라는 특정 기능만 제공하는 MS(Micro Server) 였는데, 이제는 운영 담당자들이 사용할 어드민 웹 페이지도 만든다. 그리고 이 와중에 기존 서버의 구조적인 문제로 DB 스키마, 데이터 모델도 모두 현황에 맞게 바꾸고 서버도 다시 처음부터 설계하여 개발하게 되었다.

팀에서는 이 대여 가격 시스템 프로젝트를 “파티”라는 단위의 유닛을 만들어 진행하도록 합의했으며, 이 유닛에는 나를 포함한 3분이 참여하게 되었다. 내가 기존에 맡던 프로젝트이기도 했고, 나머지 두분은 개발 경험이 비교적 적으셨으므로, 팀에서 개발을 주로 담당했던 내가 파티장을 맡게 되었다. 나도 언젠간 한번 프로젝트를 이끌어 보는 역할을 해보고 싶었는데, 이런 작은 단위라면 충분히 해볼만 하겠다 싶어 자신감이 생겼다.

그러나 이런 자신감은 아주 경기도 오산이었음을 몇 달뒤 깨닫게 되었다. 초반에는 진행 진척도나 문서화, 회고 등이 잘 진행되었으나 뒤로 갈수록 이런저런 상황들로 일정이 점점 밀리게 되었고, 자꾸 밀리고 급해지다보니 문서화나 회의 계획도 매우 빈약하게 되었다. 2~3주 안으로 끝날거 같던 작업이, 생각지도 못한 대체 휴일들이나, 나 혹은 팀원들의 다른 일정 등으로 한 달이 넘게 진행되게 되었고, 이러다보니 중간에 싱크를 맞추는 작업들이 잦고 일정이 길어지다보니 진행이 아주 루즈해졌다. 어드민 페이지 수준이니까 금방하겠지라고 생각했던거에 비해 내가 기술적으로나 매니징적으로나 실력이 많이 부족함을 절실히 느낄 수 있었다.

기술적으로도 아쉬운게 있었는데, 새로 시도해 본 프로젝트 구조와 아키텍처가 과연 정말 올바른 결정이었는지 판단하기 쉽지 않다는 것이다. 괜히 배워본 것들 적용해본답시고 복잡도만 키운건 아닌지, 아니면 이렇게 할 수 밖에 없었는지, 나조차도 시간이 지나면서 내 판단의 근거가 잘 생각이 나지 않는다. 아직 프로젝트를 진행하는 중인데, 이 부분은 추후에 회고할 때 팀원 분들에게 꼭 리뷰를 받아보고 싶은 부분이다.

그래도 좋았던 점은 이렇게나마 새로운 기술적 시도와 팀 매니징을 경험해볼 수 있었다는 것이다. 나름대로 생각해본 아키텍처를 실제로 구현해볼 수 있었고, 이를 전혀 모르는 팀원들에게 처음부터 설명하고 같이 진행해볼 수 있었다. 혼자 개발하던 이전과 달리 3명과 함께 개발하면 모듈을 어떻게 쪼개야하고, 깃허브로 협업을 어떻게 해야할 지 온몸으로 익힐 수 있었다. 또한 팀원들에게 앞으로 팀에 필요한 개발 지식과 실력들을 잘 전달해주었을거라 생각한다. (앞으로 내 업무 중 일부를 그 분들에게 큰 허들 없이 도움 받을 수 있을거라는 생각이 든다!)

결과적으로 성과가 맘에 들지는 않지만, 그래도 이런 기회를 얻게되어 이런저런 고민해본 게 어딘가 싶다. 또한 프로제트를 리딩하고, 아키텍처 설계와 핵심 코드 로직을 내가 담당함으로써, 앞으로 회사의 대여 가격 시스템을 가장 잘 아는 사람이 됬다는 생각이 든다. 이젠 이 도메인에 대해 누가 무엇을 물어봐도 다 대답해줄 수 있다.
프로젝트의 남은 부분을 어서 끝내고, 회고로 프로젝트를 잘 마무리 하고 싶다.

 

5) 테크 블로그 리뷰어 & 관리자

9월인가부터 기존 회사 테크 블로그 리뷰어였던 동료 카일과 함께 블로그에 올라갈 글감을 리뷰하고 있다. 올라가는 모든 글들은 나와 카일의 리뷰를 거치게 된다.

남이 쓴 글을 보다보니 글의 목차와 구성이 참 중요하다는 걸 느낀다. 확실히 기승 전결이 있는 글과 없는 글. 알맹이가 있는 글과 없는 글의 차이가 와닿는다. 이 차이가 어디서 오는가 생각해보면, 처음부터 글의 구조를 설계하고 쓰냐 안쓰냐의 차이같다. 글을 구체적으로 쓰기 전에, 목차로 한 2~3뎁스까지는 먼저 리뷰어와 공유하고 글쓰기를 시작했더라면… 이라는 생각이 든다. 이 생각 이후로는 테크 블로그 글을 제대로 쓰기 전에 반드시 글감 리뷰를 거치게 하도록 했다. 물론 글 쓰는 사람 입장에서는 허들도 조금 높어지고 부담스럽기도 하겠지만, 나는 회사 테크 블로그기 때문에 이정도는 해야한다고 생각한다.

한편, 리뷰에서 이렇게 저렇게 바꾸면 좋겠다는 내 의도를 좋게 전달하기도 참 쉽지 않다는 생각이 들었다. 나 나름대로는 좋게 말한다고 했는데, 어찌됐든 내가 평가하고 결정하는 입장에서 상대방은 기분이 상할 수 있기 때문이다. 특히 글감을 많이 수정해야하는 경우에는 더 그렇게 느낄 수 있을거라 생각이 들어, 따로 DM을 보내가며 최대한 기분 좋게 풀어내려고 했다.
그러나 항상 이렇게 할 수는 없는 법이고.. 어떤 명확한 기준을 세워 글을 리뷰해야 할텐데, 이 기준 세우는 것에 대해서는 아직 딱히 드는 생각이 없다. 코드 컨벤션도 아니고, 템플릿 정도는 이미 주고 있는데, 어떻게하면 모두가 기분이 상하지 않게 글을 잘 쓸 수 있을까. 여전히 고민이 되는 포인트다.

리뷰 외에도 12월 말부터 테크 블로그를 조금씩 꾸며나가고 있다. Jekyll 기반 사이트라 사실 뭐 크게 건드릴 건 없고, CSS 추가, 변경이라든가. 페이지를 더 추가하거나 회사 블로그에 들어갈만한 컴포넌트들을 더 넣고 있다. 회사 테크 블로그. 앞으로 내가 더 키워서 회사와 팀, 개인에게 모두 좋은 영향이 가도록 만들거다.

---

2. 회사 밖에서

1) DND 활동

회사 밖에서 다른 사람들과 개발 프로젝트를 해보고 싶어서 지원하게 된 DND. 대학생들과 현업에 있는 사람들이 섞여서 진행하는 사이드 프로젝트 동아리다.

올해 1월부터 2월까지 약 8주간 활동했으며, 이에 대한 내용도 이전에 블로그에 적어두었다.
이 때까지만 해도 DDD니, 클린 아키텍처니 하며 나름대로 공부한 걸 서비스 개발에 녹여보고 싶었고, 애자일한 프로세스 위에서 아름답고 깔끔한 코드를 만들어보고 싶었다.

실제로 개발하며 고민되는 내용은 엄청 많았다. 이렇게하면 의존성 방향 위반인데, 이걸 또 추상화해야 하나? 클래스가 엄청 많아지네… 테스트 코드 작성할게 엄청 많네… 테스트 설계를 이렇게 하는게 맞을까? API 설계 이렇게 하는게 REST한게 맞을까? 인증/인가 로직은 미들웨어인가 서비스인가? 프로젝트 구조를 어떻게 설계해야 테스트 가능하고 확장성 있으며 명시적일 수 있을까? 우리가 오버 엔지니어링 하는건 아닐까?

같이 백엔드 개발하던 석준님과 이런 고민과 이야기를 맨날 했던 기억이 난다. 누가 정답좀 알려줬으면 좋겠는데, 이런 고민을 하는 사람도 근처에 잘 없었고, 검색해도 여기저기 다 다른 대답에 참 답답했다.

생각보다 개발은 시간이 오래걸렸고, 목표했던 모든 기능을 다 구현하지는 못했다. 그래도 나름대로 서비스 백엔드를 짜는 경험을 해볼 수 있었고, 어떤 것들이 고민 포인트가 될 지는 경험해본거 같다. 또 내가 공부하고 배운 것들을 밑바닥부터 쭈욱 올려보는 과정을 경험해볼 수 있었다.

최종 발표 PT 중 일부

또한 6명이 되는 팀에서 팀장 역할을 맡으며, 킥 오프 회의부터 중간 회의, 진행 사항 체크에 거쳐 최종 발표까지 해보는 경험을 했다. 많이 부족했고 그만큼 느낀게 많았지만, 요약하자면 나는 아직 개발 직군 밖에서 모두를 이끌고 갈만한 리더는 아니라는 생각이 들었다. 좀 더 떠올려보면… 나는 팀원들이 각자 잘해낼거라 그저 믿기만 했으며, 나는 팀 매니징 보다는 백엔드에만 좀 더 집중하려고 했던거 같다. 내게는 아직 이런 나의 부족한 면모를 채워줄 수 있는 리더가 곁에 있으면 좋겠다는 생각이 든다.

활동하면서 한 가지 아쉬웠던 건, 기술적인 이슈 공유의 자리가 잘 없었다는 점이다. 아키텍처나, 일반적으로 많이 사용하는 프레임워크, 라이브러리에 대한 스터디라도 있었으면 얻어갈 게 더 많지 않았을까 싶다. 최종 발표에서도 주로 각 팀의 서비스 설명 중심적인 내용이 많았는데, 개인적으로는 이보다 각 서비스 기술 설계와 의사 결정 과정과 판단 의 근거, 그리고 여기서 겪었던 트러블과 해결 방법들 위주의 내용이 궁금했다. 나는 아무래도 사이드 프로젝트 모임보다는 기술 중심 스터디 모임에 참여하는게 더 어울리는 듯 싶다.

 

2) SQLAlchemy Tutorial 스터디

백엔드 서버를 개발하다보면, DB와 통신하는 일이 아주 많아지는데, 파이썬에서는 SQLAlchemy를 DB 커넥션 및 ORM 라이브러리로 거의 국룰같이 쓰고 있다.

나도 SQLAlchemy를 종종 쓰곤 했는데, 라이브러리 자체가 워낙 방대하고 깊은 내용을 품고있어서 그런지, 내가 이 기능을 제대로 쓰고 있는게 맞는건지 확신이 잘 없을 때가 많았다. 또 파라미터들은 뭐가 이렇게 많고 이게 각각 무엇을 의미하는지, 기능 하나 동작시키는데 방법은 또 왜 이렇게 다양한건지, 그래서 결과적으로 무엇이 일반적인 Best Practice인지 알고 싶었다.

그래서 마음 먹게된 게 SQLAlchemy 공식 문서에 있는 Tutorial 페이지를 읽어보자! 였는데 이게 생각보다 양이 좀 많았다. 게다가 다 영어고, 내용도 DB에 대한 사전 지식이 없으면 이게 무슨 말하는건지 잘 이해가 안갔다.

그래도 이걸 잘 읽어보고 이해하고 싶은데… 한글로 옮겨 적으면서 공부하는건 어떨까 싶었다. 그리고 이왕 할거 사람들 모아서 같이 해보자는 생각이 들었다. 바로 인프런과 파이썬 오픈 카톡방에 홍보를 했고, 결과적으로 나 포함 5분이 함께 참여하게 되었다.

인프런에 올렸던 스터디 공고

약 8주 동안 매 주 한 사람이 한 챕터씩 맡으며 번역 및 정리를 진행했고, 작업한 내용은 전부 이슈와 PR을 통해 관리했다. 이 과정 중에 슬랙 채널도 개설하여 모르는 것, 궁금한 것등을 실시간으로 주고받기도 했다.

처음엔 깃허브 이슈, PR로만 소통하다가, 슬랙 채널도 사용하게 되었다

작업한 결과물은 Vuepress로 말아서 배포했으며 여기에서 확인할 수 있다.

보통 스터디 장 되는거 꺼려하는 편인데, 이번에는 내가 공부하고 싶은걸 좀 편하게 공부하려다 보니, 내가 주도적으로 나서서 스터디장을 하는 경험을 해보게 되었다. 그 과정 중에 SQLAlchemy의 기본 사용법과 더불어 GitHub Milestone, Issue, PR 등을 통해 스터디를 진행하는 법, 여러 사람이 리뷰하는 법, Vuepress로 배포하는 법, 배포한 사이트의 SEO 설정하는 법을 알 수 있었다.

사실 SQLAlchemy에 대한 내용보다, 전반적인 스터디 진행을 경험해본게 더 큰 거 같다. (SQLAlchemy는 지금도 종종 까먹어서 위 사이트에 들어가 다시 확인하곤 한다;;)

 

3) 그랩 강의 자료 만들어주기

같은 팀 동료인 그랩에게 인프런에 낼 온라인 강의를 제작하고 있는데, 같이 참여해줄 수 있냐는 제안이 왔다. 강의 대상은 이제 막 실무를 해보려고 하는 입문 개발자이며, 내 블로그 글처럼 그냥 편하게 강의에 사용할 문서를 만들어 달라는 것이었다. 강의 내용 목차를 보니 실제로 취준 하는 분들이 보면 좋을 내용들이었고, 나도 언젠가 한번은 정리하고 갔어야 할 지식들이라 제안을 수락하여 참여하게 되었다.

일주일에 대략 2~3개의 글을 쓰며 한 8주 정도 진행한거 같다. 저녁에 즉흥적으로 약속을 잡던 내게는 살짝 빡센 일정이긴 했으나, 그래도 어느정도 아는 내용들이라 그런지 할만했다. 강의 퀄리티에 더더욱 신경 쓰는 그랩의 모습에서 인프런에 강의 내려면 저정도는 해야겠구나 싶었다. 과연 나도 나중에 강의 만들면 저렇게 영상 찍으며 할 수 있을까.

현재 인프런에 공개된 그랩의 강의

여하튼 매주 금요일 그랩에게 리뷰를 받으며 적지 않은 문서들을 작성했다. 그리고 현재 인프런에서 그랩의 강의는 오픈되어 이 문서들이 쓰이고 있다. 그랩과 앞으로 이런 교육 컨텐츠를 더 많이 해볼 수 있을 거 같아 기대된다.

 

4) 부스트캠프 AI Tech 2기. 제작 멘토

9월인가 쯔음에 데이터 그룹 동료인 카일이 자기가 담당한 외부 프로그램에서 제작 멘토로 참여해달라는 부탁이 왔다. 그 외부 프로그램은 부스트캠프 AI Tech 2기로, AI 엔지니어 부트캠프 같은 거였다. 이 프로그램에 나와 험프리는 강의 제작 멘토로 참여하게 되었다.

나와 험프리가 맡은 부분은 ML 서빙 관련 강의를 제작하는 것이었는데, FastAPI, Docker, Airflow, MLflow 등을 간단히 소개하고 실습하는 PT를 만드는 것이었다. 사실 뭐 MLOps TF에서 자주 다루던 것들이고, 입문 위주의 내용이라 제작이나 설명이 어렵진 않았다. 나는 카일이 추후에 만들고 싶어하는 MLOps 강의에 어떤 내용들을 담는지, AI 관련 부트 캠프는 어떤 방식으로 진행되는지 엿볼 수 있었다.

강의 제작하는 것 말고도, 내가 직접 라이브 시연(MLflow Tracking Server를 GCP에서 배포하기)을 수강생들 앞에서 줌으로 진행하기도 했다. 내 얼굴이 200명이 넘는 사람들에게 생중계 되는 경험을 해볼 수 있었다. 줌 키기 전에는 은근 떨렸는데 막상 하니까 또 나쁘지는 않았다. 험프리가 줌 채팅으로 반응 잘해줘서 좋았다. (역시 이런 역할이 필요한거 같다)

우리가 담당한 프로덕트 서빙이 전체 코스의 마지막 파트였고, 내가 발표하고 나서 며칠 뒤 이번 기수는 종료하게 되었다. 카일, 험프리, 나 이렇게 같이 강의를 만들어보는 재밌는 경험이기도 했고, 강의 만드는 과정 중에 지식 공유나 강의 제작 합을 맞춰볼 수 있어서 좋았다. 우리는 내년에 열릴 다음 3기도 그대로 진행하게 되었다.

 

5) 박훈님의 Practical Spark 강의

한동안 너무 처 놀기만하고 배움에 대한 의지가 많이 줄어든거 같아서, 강제로 뭐라도 배워야겠단 생각에 러닝스푼즈에서 Spark 강의를 신청했다. 6회에 72만원이나 가격대가 있는 강의긴 하지만, 오프라인 강의였고 무엇보다 데이터 엔지니어로 유명하신 박훈님이 진행하신다고 해서 너무 매력적으로 다가왔다. 이번 기회에 강의 들으며 영감도 좀 받고, 우리 회사 말고 다른 회사의 데이터 엔지니어들은 보통 어떤 고민을 하고 어떤 일들을 하는지 알면 좋겠다 싶었다.

당시에 올린 인스타 스토리

11월 중순부터 12월 중순까지 매주 토요일 강남에서 2시부터 5시까지 강의를 들었다. 내용은 생각보다 양이 많고 처음 접해보는 입장에서는 깊이가 조금 있는 정도였다. 단순히 스파크만 알려주시는 게 아니라, 데이터 엔지니어링 전반에 대한 지식이나 아키텍처, 그리고 클라우드를 통해 이를 구현하는 예시, 빅 테크 기업인 우버나 에어 비앤비에서는 어떻게 하는지 등의 케이스 스터디도 진행해주셨다.

내용은 아주 풍부하고 박훈님도 열정있게 가르쳐 주셔서 좋았지만, 슬프게도 내 그릇이 이 모든 것을 담기에는 조금 부족했던거 같다. 당장 스파크를 쓸 것도 아니여서 금방 까먹겠지만.. 그래도 스파크가 왜 필요하고 어떤 개념들이 있는지, 어떻게 사용하고 언제 무엇을 주의해야 하는지, 데이터 인프라의 큰 그림에서 어떤 역할에 속하는 지는 기억에 남는다. 스파크에 대해서는 이 정도만 기억하고 나중에 필요할 때 박훈님이 만들어주신 강의 찾아볼 수 있는 정도는 되는거 같으니, 나 나름대로는 어느정도 만족한다.

마지막 날 강의 끝나고 박훈님이 지하 호프 집에서 남은 분들끼리 맥주나 한 잔 하시며 이야기 나눠보라고 하셨는데 뒤에 약속이 있어 가지 못했다. 이 점이 사실 매우 아쉽다. 업무 진행하며 마주하는 기술적인 고민들이나 이슈들이 비슷한 부분이 많을거 같고, 이를 어떻게들 해결하는지 궁금했는데…
내년에는 그런 커뮤니티 자리를 더 적극적으로 찾아 나서야겠다.

---

3. 그 외

1) 독서

와 진짜 올 한해 책 진~짜 안읽었다. 너무너무너무 게을러 빠진 한해였다고 생각한다. 핑계를 대보자면, 난 보통 출퇴근할 때 책을 읽는 편인데 재택 근무하느라 책을 안읽은거 같다는… 은 정말 말도 안되는 핑계다. 난 정말 게을러 빠졌다.

그래도 관심의 의미로 구매한 책의 목록은 다음의 것들이 있다. (다 읽은 것도 있고 아닌 것도 있다)

데이터 중심 애플리케이션 설계 (마틴 클레프만 저)
가상 면접 사례로 배우는 대규모 시스템 설계 기초 (알렉스 쉬 저)
개발자에서 아키텍트로 (마이클 킬링 저)
파이썬으로 살펴보는 아키텍처 패턴 (해리 퍼시벌, 밥 그레고리 저)
도메인 주도 설계 핵심 (반 버논 저)
도메인 주도 설계 구현 (반 버논 저)
웹 API 디자인 (아노드 로렛 저)
프로메테우스, 오픈소스 모니터링 시스템 (브라이언 브라질 저)

여기서 그래도 “파이썬으로 살펴보는 아키텍처 패턴”은 회사에서 스터디를 진행하며 굉장히 의미있게 읽은 책이다. 파이썬으로 EDA, TDD, DDD를 간단히 구현하는 책인데, 파이썬에는 이런 책이 전무했던 터라 아주 감사히 잘 읽었고, 직접 구현해보면서 EDA, DDD의 개념들을 더 잘 이해할 수 있었다. (아직 안 읽어본 파이썬 개발자가 있다면 꼭 읽어보길 추천한다)

이 외에는… 뭐 더 할말이 없다. 부끄럽지만 진짜 책을 잘 안 읽었다.
아래에서 다시 쓸거 같지만, 삶의 밸런스를 좀 찾고 재택 아니고 출근을 좀 하면서라도 내가 책 읽을 수 있도록 강제해야할 필요성을 느낀다…

 

2) 운동

크로스핏을 어연 2년 정도 하다가 이번 6월에 그만두었다. 매번 크로스핏 시간 맞춰서 허겁지겁 퇴근하는 거가 스트레스였다. 저녁 먹기도 뭔가 애매하고… 갔다가 집와서 씻으면 저녁 10시다. 또 크로스핏 같은 기능성 운동보다는 그저 살만 빼고 싶었고, 이럴 바엔 그냥 러닝 뛰는게 더 낫겠다 싶었다. 내가 따로 저녁에 시간을 주도하여 만들어 집 바로 옆 안양천을 뛰면 된다 생각했다.

물론 전혀 계획대로 되지 않고 나는 처참히 게으르고 나약했다. 12월까지 뒤룩뒤룩 살 찐 돼지가 되었으며, 시간을 주도적으로 만들기는 커녕 일과 생활의 밸런스가 무너져 카페 마감때까지 커피 마시며 일하고 있는 카페 노트북충이 되었다.

그래 운동해야지… 이대로 내 20대를 돼지로 보낼 수는 없다. 샐러드 먹는다. 살을 뺄 것이다. 다시 일과 삶의 밸런스를 찾고 저녁에 안양천을 뛸 것이다. 돼지를 탈출할 것이다.

 

3) 블로그

취준하며 블로그에 글쓰기 시작한지 어언 3년. 블로그 누적 방문자 수가 백만을 넘었다.

뭐… 누적 방문자수가 별건 아니지만, 그냥 공부하며 내용 정리하던 블로그가 이만큼 왔다는 게 참 신기하다. 사실 별 내용도 없는 블로그인데 어쩌다 SEO 노출이 좀 되서 잘 뜬거 같다는 생각이다.

취준 시절의 고민과 후기들이 아직 그대로 있어 정이 많은 블로그긴 하지만, 조만간 티스토리를 벗어나 옮겨볼 생각이다. 이유는, 나는 블로그 글을 올리기 전에 깃허브 레포에 따로 푸시한 뒤, 티스토리에 한번 더 올리는 식인데 이렇게 하다보니 두 번 작업해야 되서 좀 귀찮다. 뭐 마크다운이라 그냥 복붙하면 되긴 하지만, 문제는 이미지의 경우 하나씩 다 다시 올려줘야 한다.
회사에서 GitOps로 배포 과정을 운영하며 Single Source Of Truth가 얼마나 좋은지를 느끼게 되었다. 따라서 나는 블로그 역시 GitOps 형태로 운영하고 싶고, 아무래도 GitHub 기반의 정적 블로그를 다음 블로그 플랫폼으로 정하지 않을까 싶다.

새로 블로그를 옮기게 되면, 그 때부터는 좀 더 테크 내용 중심의 글들을 올려보고 싶다. 이러나 저러나 블로그에 글을 작성하는 건 계속할 것 같다.

---

4. 나가며

뒤돌아 보면 참 생각없이 놀며 게으르던 해였다. 어느샌가 책도 안 읽고, 다니던 운동도 끊고… 퇴근 후 게임과 술자리로만 즐거움을 찾곤 했다. 평일 저녁에도 놀고, 주말에도 놀고. 재택하다보니 늦게 일어나고 늦게 퇴근하고. 일과 생활의 균형이 조금씩 깨지고, 그러다 보니 노는 것도 균형 없이 마냥 놀았다. 지금보면 참 내 스스로가 부끄러운 한해였다.

내년에는 다시 균형을 찾고싶다. 일을 참 깔끔하게 잘 끝내고. 기록도 잘하고. 개인적으로도 계속 공부하고 성장하며 팀과 회사에 도움이 되는 사람이 되어야지.

회사에서 데이터 엔지니어링 팀은 이제 엔지니어링 그룹으로 승격되었고, 나는 그룹 내 데이터 플랫폼 팀의 일원이 되었다. 사실 하던 일이 많이 바뀌진 않을거 같지만, 내년에는 데이터 플랫폼과 관련된 고민과 일을 많이 해보고 싶긴 하다. 여전히 회사 일은 아직까지 내 생활의 기준으로 두기 쉽지 않을까 싶다. 2022년엔 또 어떤 일들을 벌리고 벌어질지 궁금하다.