2020년 내가 해왔던 것들을 회고하며

0. 들어가며

2020년 올 한해를 되돌아 보며, 무엇을 했고 어떤 고민들을 했으며 어떻게 살아왔는지를 되돌아본다.
딱히 정리된 글은 아니며, 나 역시 글을 쓰면서 올해 초부터의 기억을 하나씩 더듬게 될 거 같다.

---

1. 쏘카 입사

3월 9일. 첫 출근을 했다. 코로나로 인해 신입 OT를 하지 않고, 내가 소속할 팀이 있는 곳으로 바로 가게 되었다. 데이터 엔지니어링 팀이었다.
내 자리엔 아직 뜯지 않은 새 맥북 박스와 DELL 모니터가 있었다. 내가 고른 새 실버 색상의 맥북과, 자리 위에 놓여진 이름표를 보니 내가 정말 이 회사의 정직원으로 취업했다는 것이 실감났다.

옆 자리에 계신 착한 인상을 가지신 분이 이런저런 것들을 도와주셨다. 녹스라는 분이었다. 이 회사에서 상대적으로 오래 있으셨다고 한다. 녹스 덕분에 일주일 동안 도움을 받으며 필요한 세팅들을 잘 마무리할 수 있었다. 새 신입이 들어오면, 나도 그처럼 해야겠다는 생각에 메모를 해두곤 했다.

팀장 토마스와 면담을 했다. 실무 면접에서 보았을 때는 조금은 긴장되게, 그리고 내가 넘어야할 산으로 보였지만, 이제는 내가 따라야할 리더라는 느낌이 들었다.
나는 현재 개발 중인 프로젝트 개발에 참여하게 된다고 하셨다. 우리 팀은 기본적인 데이터 엔지니어링 업무도 하지만, 데이터 그룹 내 개발 업무도 담당하고 있으며 앞으로 이렇게 개발할 것들이 많아질거라고 하셨다. 아직 뭣도 해본 것 없는 신입이라, 난 어떻게 해야할 지는 몰랐지만 그래도 재밌겠다라는 생각이 들었다. 토마스 특유의 편안한 미소와 차분한 말투 덕에, 어떻게 돼도 잘 되겠지라는 막연한 생각도 들었다.

이 회고 글은 여기서부터 시작한다. 이 글은 쏘카에 입사 후 겪었던 주요 프로젝트들과 해온 것들, 고민했던 것들, 그리고 느낀 점에 대한 글이다.

---

2. 참여했던 프로젝트

1) 대여 가격 시스템 개발

내가 맡은 첫 번째 프로젝트는 쏘카의 대여 가격 시스템 개발이었다.
기존 레거시 개발 시스템을 완전히 걷어내고, 새로운 컨셉으로 새롭게 시스템을 개발하는 일이었다.
모든 것을 다 개발하는 것은 아니고, 우리 팀은 가격을 산출하는 로직을 MS(Micro Service) 형태로 개발하여 백엔드 서버팀과 통신하도록 하는 것까지 담당했다. 그리고 우리 팀에서 나와 토마스가 이 개발을 맡았다.

약 2~3달에 걸쳐 이 프로젝트를 마무리 했으며, 기술적으로는 다음과 같은 것들을 배우고 사용해볼 수 있었다.

• 파이썬스럽고 클린한 코드
• 파이썬 오픈소스 라이브러리 (sqlalchemy 등)
• gRPC 통신
• MSA 환경에서 앱 배포

구체적인 프로젝트 후기는 이전 포스팅인 "입사 후, 첫 번째 프로젝트 후기" 에 있다.

특히 이 때는 좋은 코드를 작성해보고 싶다고해서 클린 코드와 파이썬 관련 서적을 한창 읽던 때였다. 누가 봐도 부끄럽지 않을 코드를 작성하고 싶었다. 최소한 그런 노력의 흔적이라도 보이고 싶었다. 그래서 퇴근 후 남는 시간마다, 그리고 주말마다 관련 서적을 읽고 블로그에 정리하기도 했다.
그렇게 앱을 최종 배포하며 프로젝트는 마무리가 되었으나... 난 뭔가 아쉬웠다.

일단 내 코드가 너무 아쉬웠다. 정말 고민하며 짜다가, 다시 뒤엎고 짜기도 하며 애정을 쏟아부은 코드였다. 그런데도 결과물을 봤을 때 뭔가 아쉬운 부분이 있었다. 아름다움이 절로 느껴지는 코드가 되기에는 많이 부족했다.
그러나 그런 아름다움을 만들어내기에는 내가 아직 그만한 실력이 없음도 느껴졌다. 이 상태로 다시 코드를 짠다면, 고민고민하며 짜도 지금의 결과물과 아쉬움이 크게 달라질 게 없다는 생각이 들었다. 그래서 개발 공부부터 먼저 해야겠다는 생각이 들었다. 그리고 이 생각은 자연스레 클린 코드를 넘어 아키텍처로 내 관심을 들게 하였다. 이후 나는 클린 아키텍처나, DDD 관련 서적을 사서 읽게 되었다.

 

2) PF (면책금) 시스템 개발

두 번째로 맡은 프로젝트는 쏘카의 PF (면책금) 시스템 개발이었다.
대여 가격 시스템과 비슷한 맥락으로, 기존 레거시 시스템과는 완전히 다른 컨셉의 시스템을 개발하는 것이었다.
MS 형태인 것은 동일하지만, gRPC를 쓰는 대여 가격 시스템과는 다르게 REST로 백엔드 서버팀과 통신하였고 기존 로직과도 호환되도록 기존 코드를 최대한 살려서 가야했다. 다만 이번에는 도메인 전문팀과 직접 상의하며 시스템 컨셉을 잡는 것부터 배포 후 테스트까지의 모든 과정을 내가 온전히 경험하고 주도해볼 수 있었다.

전반적으로 대여 가격 시스템 프로젝트랑 과정과 코딩도 비슷했다. 이번 프로젝트에서 주로 고민했던 것과 느꼈던 것은 다음과 같다.

• 어떤 것이 올바른 데이터 모델링인가?
• 기존의 CI/CD가 매우 불편하다.

 

어떤 것이 올바른 데이터 모델링인가?

첫 번째, 어떤 것이 올바른 데이터 모델링에 대한 것은 특히 너무 너무 고민하던 것이었다. 쉽게 말해 데이터베이스의 테이블 스키마를 어떻게 짤 것이냐 인데, 그냥 생각나는 대로 짜는 것이 아닌, "잘", "정석대로" 짜고 싶었다.
특히 나는 데이터 그룹 소속이다 보니 단순히 애플리케이션에서 동작하는 것 뿐만이 아닌, 추후 분석할 수 있도록 하는 것까지도 고려를 하곤했다. 그러다 보니 테이블을 이렇게 짜도 되나? 싶은 게 많았고, 워낙 테이블 설계가 기초가 없다보니 팀에 DB 쪽 직무 경험이 있으신 플래시나 제프에게 많이 여쭈어 보았다. 그러다 이런 고민이 "데이터 모델링" 이라는 분야임을 알게 되었고 이와 관련 책도 읽어보게 되었다.

결론적으로 내가 짠 테이블이 정말 최선의 테이블인지는 모르겠으나, 나름 노력과 고민을 한 결과물임은 확실했다.
적어도 "무언가 어색한 테이블"이 뭔지는 감이라도 잡게 되었다. 그리고 테이블 설계에 있어 어떤 고민들을 해야하는지, 어떤 프로세스를 거치고 어떤 용어들이 있는지 알게되었다. 이전에는 전혀 몰랐던 DBA, 데이터 모델러들이 어떤 일을 하게 되는지 알게되었고 왜 필요한지 아주 절실히 느낄 수 있었다. 사내 DBA 분과도 자주 소통하며 질문할 수 있게 되었다.

부끄럽지만 솔직히 나의 데이터 모델링에 대한 실력은 아직 형편 없다고 생각한다. 다만, 개발자라면 이정도까지 고민하고 커버해줘야 함을 느끼고 있고, 적어도 데이터 모델러나 DBA와 소통할 수 있는 지식은 필요하다고 생각한다. 멋진 개발자가 되기위해, 데이터 모델링은 여전히 나에게 남은 큰 숙제다.

 

기존의 CI/CD가 매우 불편하다.

두 번째, 기존의 CI/CD가 불편하다고 느꼈던 부분은 새로운 CI/CD 구축의 필요성을 느끼게 만들어주었다. 우리 팀은 기존에 랜처를 통해 CI/CD를 전부 해결했었으나, 추후에는 CI는 서버팀에서 사용 중인 버디웍스로, CD는 버디웍스를 쓰거나, 혹은 자체 구축한 클러스터의 경우 ArgoCD를 사용하게 하였다.

랜처 파이프라인에서 버디웍스로 CI로 분리하였다. 

이 과정 중에, 서버 팀과 인프라 팀 사람들과 활발하게 소통할 수 있었다. 전사의 공통된 기술과 정책에 데이터 그룹의 기술을 피팅시키는 느낌도 들었고, 개발 팀 분들과 소통하며 어떤 것이 전사적으로 좋은 방법론일까에 대해서도 이야기하고 의견을 내볼 수 있었다. 무엇보다, 데이터 그룹 사람들에게 앞으로 CI/CD 관련 부분은 내가 가이딩해줄수 있다는게 매우 좋았다. 버디 웍스의 관리자 권한을 가지게 된 만큼, 깔끔하고 올바른 CI/CD 사용법을 데이터 그룹이 통일되게 사용하게끔 내가 잘 고민하고 알려주어야 겠다는 책임감을 느낄 수 있었다.

 

3) 에어플로우 on 쿠버네티스 배포하기

세 번째로 기억나는 프로젝트는 쿠버네티스 환경에서 에어플로우를 새로 배포하는 일이다.
기존에는 GCP의 GCE 인스턴스에서 에어플로우를 실행시키고 있었다. 초반에는 별 문제 없었으나, Dag 개수가 점점 많아짐에 따라 에어플로우 실행 속도가 느려지게 되었고, 인스턴스의 성능을 수직 확장하는 경우가 잦아졌다. 또한 ETL 특성상, 컴퓨팅 리소스를 특정 시간에만 쓰기 때문에 (Dag 은 특정 시간에만 실행되었다.) 리소스 활용이 매우 비효율적이었다. 이에 대한 대안으로 쿠버네티스에서 에어플로우를 동작시켜, 좀 더 유연하게 컴퓨팅 리소스를 사용하자는 의견이 나오게 되었다. 사실 이는 요즘 트랜드 기술이기도 했고, 점점 커지는 비즈니스 규모상 자연스러운 것이기도 했다. 따라서 나는 쿠버네티스 환경에서의 에어플로우를 배포하고, 기존 에어플로우에서 동작하는 Dag들을 리팩토링하여 새로운 에어플로우로 옮기는 일을 맡게 되었다.

이 일을 하며 나는 다음의 것들을 공부하고 고민할 수 있었다.

• 쿠버네티스 그 자체
• 쿠버네티스 운영을 위한 세팅
• 에어플로우 아키텍처와 배포 Chart
• 에어플로우 운영을 어떻게 할 것인가?

 

쿠버네티스 그 자체

에어플로우를 쿠버네티스에 올리자!라는 목표의 첫 번째 걸음은 쿠버네티스가 무엇인지 먼저 아는 것이었다.
물론 기존에 대여 가격 시스템이나 PF 시스템을 배포할 때에도 쿠버네티스에 배포해야 했기 때문에, 쿠버네티스에 대해 기초적인 개념들을 알고는 있었다. 그러나 이 때와는 다르게, 내가 직접 쿠버네티스 클러스터를 만들고 운영해야 했으므로 쿠버네티스에 대해 좀 더 잘 알아야 할 필요성을 느꼈다. (잠깐 상황을 설명하면, 기존에 앱들을 배포한 클러스터는 AWS EKS 였고, 이는 인프라팀과 서버팀에서 주로 사용했다. 데이터 그룹은 주로 GCP를 사용했고, 에어플로우 역시 AWS 가 아닌 GCP에 올려진 상황이었다. 결국 전사적인 차원에서는 멀티 클라우드 환경인 셈이고, 데이터 그룹은 자연스레 초반에 GCP 관리를 하게 되었다. 그리고 데이터 엔지니어링팀이 이 GCP 인프라 사용 등을 담당하는 역할까지 하게되었다. 즉 GKE 클러스터를 만들게 되면 에어플로우 뿐 아니라, 데이터 그룹에서 사용하는 GCE까지 GKE로 통합하여 관리하게 되는 것이었다.)

회사 돈으로 인프런에서 33만원 짜리 쿠버네티스를 강의를 빠르게 수강했다. 생각보다 긴 강의 시간이긴 했지만, 목표와 해야할 일이 있으니 평일과 주말에 빠르게 들을 수 있었고, 이 강의를 통해 기본적인 개념들과 실습을 해볼 수 있었다.

 

쿠버네티스 운영을 위한 세팅

리소스 모니터링을 위해 프로메테우스와 그라파나를 설치했다. 에어플로우용 그라파나 대시보드를 직접 만들기 위해 프로메테우스 쿼리 문법인 PromQL을 공부했다. 완벽히 이해하지는 못했지만, 그래도 당장 필요해서 쓸 수 있을 정도로만 익혀두었다. 특히 에어플로우가 컴퓨팅 리소스를 얼마나 잡아먹을지, 그 내부에 Dag 별로 잡아먹는 리소스가 얼마가 될지 알 수 없었기 때문에, 에어플로우 현 리소스 상황을 잘 드러내주는 대시보드를 만들어야 했다. 완전히 세세히 까지는 아니지만, 당장 필요할 정도로는 만들 수는 있었다.

앱 배포를 어떤 형태로 할까 고민하다가, 기존 서버팀처럼 버디웍스에서 CI/CD 하는 것이 아니라, CI/CD 를 분리하고 GitOps 형태로 운영하기 위해 ArgoCD도 배포하였다. 되도록 명시적이고, 재현가능하도록 만들고 싶었기 때문이다. 이 과정 중에 수비쿠라님의 발표 자료가 매우 도움이 되었다.

아직은 클러스터에 띄운 앱이 별로 없긴 하지만... Git-Ops 형태로 배포하고 있다.

로깅 시스템은 아직 로그를 따로 저장하거나 관리할 필요가 없기 때문에 그냥 기존에 사용 경험이 있는 Fluentd 로 ERROR 레벨의 로그만 슬랙 채널로 보내도록 처리하였다. 아직 쿠버네티스에 올라올 앱이 몇 개 없기도 해서 그렇게 중요한 부분은 아니었다. 추후 충분히 바뀔 여지를 두고, 최대한 심플하게 가져갔다.

무엇이 Best Practice 인지 늘 궁금했지만, 당장 그것만 고민하고 연구할만한 상황은 아니었기 때문에, 주어진 상황에 충실하지만 얕은 지식들을 알 수 있었다. 이러는 와중에, 흔히 인프라 엔지니어, 데브옵스 엔지니어라고 하는 분야에도 흥미가 생겼다. 개인적으로 이렇게 운영/배포 환경을 잘 정비해두면, 지속적인 개발이 매우 편하기 때문에, 이 분야도 잘하고 싶다는 생각이 들었다.

 

에어플로우 아키텍처와 배포 Chart

기존에 사용하던 에어플로우는 단일 컴퓨팅 환경에서의 에어플로우 1.10.3 버전 + Celery Executor 를 사용했다.
새롭게 바꾸고자하는 에어플로우는 쿠버네티스 환경에서의 에어플로우 1.10.12 버전 + Kubernetes Executor 를 사용했다.
환경부터 에어플로우 버전, 아키텍처까지 생각보다 많은 것이 바뀐다.

슬프게도 완성된 에어플로우 Helm chart 가 아직 없어서, 커뮤니티 버전의 에어플로우를 직접 커스터마이징 해야했다. 현재 상황에 맞게 차트를 수정하고 연구하고 실험하는 과정에서 에어플로우 아키텍처와 컴포넌트에 대해 이전보다 많이 알게되었다. 동시에 helm 과 helm template 구성에 대해서도 자연스러워지게 되었다. 이 과정 중에 swalloow 님 블로그가 정말 도움이 되었다.
부끄럽지만 한 달이라는 무지막지한 과정 끝에 드디어 정상적으로 작동하는 쿠버네티스 환경에서의 에어플로우를 배포할 수 있게 되었다!

 

에어플로우 운영을 어떻게 할 것인가?

이제 기존 Dag 들을 하나씩 다시 다듬으며 새로운 에어플로우에 옮기는 일이 남았었다. KubernetesPodOperator 를 사용하면서 에어플로우에 대한 Dependency 를 줄이기 위해 에어플로우의 Operator 역할을 Docker 컨테이너가 하도록 바꾸었다. 즉 컨테이너에 아규먼트를 주는 형태인데, 에어플로우에서는 KubernetesPodOperator 로 이 컨테이너를 실행시키는 것이다.

이전에는 한 디렉토리 내에 모든 Dag이 위치했는데, Dag 들의 위치를 좀 더 구조적으로 가져갔다. 예를 들어 비즈니스 도메인과 관련된 Dag 들은 socar_biz 디렉토리 내에 위치한다. 동시에 에어플로우 웹에서도 구분이 가게끔 socar_biz 라는 태그를 Dag에 달아주었다. dag 의 이름도 socar_biz_* 로 시작한다.

이런 시스템을 갖춰놓음으로써 우리 엔지니어링팀의 역할은 다음과 같아졌다.

• 쿠버네티스 클러스터 (GKE) 운영
• 에어플로우 Operator 역할을 하는 컨테이너 개발 및 운영
• 에어플로우 Dag 작성과 사이언티스트에게 작성 가이드 라인 제시
• 에어플로우 Dag 실행과 관련된 쿠버네티스 메니페스트 템플릿 관리

이로써, 보다 많은 배치성 작업들을 유연하게 개발할 환경을 어느정도는 갖추었다고 생각한다.

 

4) DDD스러운 PF 시스템으로 리팩토링

이전에 개발했던 PF 시스템에 추가적인 요구사항이 생기면서, 시스템을 한번 뒤엎는 작업을 했었다.
사실 그냥 기능만 추가하면 되는 일이긴 했는데, 클린 아키텍처, DDD, 오브젝트 서적을 읽은 후 여러 생각이 들었었다. 그 중 가장 먼저 들었던 생각은 도메인 용어의 통일이었다. 예를 들어 직원 A가 말하는 용어와 직원 B가 말하는 용어가 단어는 같은데 실제 의미하는 바는 다른 경우가 종종 있었고, 이를 구체적인 코드로 구현하는 나에게는 매우 혼란스러웠다. 초기 컨셉과 다르게 전체적인 로직 컨셉이 복잡해지면서 누군가 한 사람은 큰 그림을 보고, 이를 공유할 수 있어야 했는데, 직접 개발한 나를 제외하고 나머지 사람들에겐 이게 제대로 정립되지 않은 상태로 보였다. 결국 관련 협업자들을 모아, 도메인 컨셉과 용어부터 하나씩 정리했고, 요구사항이 이 의도가 맞는지 확인했으며, 결과적으로 모두가 큰 그림을 볼 수 있는 다이어그램을 구성했다.

이제 새롭게 통일시킨 도메인 용어에 맞게 코드를 수정했으며, 그 과정에서 클린 아키텍처와 DDD에 맞게 아키텍처도 새롭게 정립해나갔다. (기존 아키텍처와 패키지 구성은 내가 한 것이 아니었다.) 코드는 DDD 패턴이 들어가 다소 복잡해지기는 했으나, 지속가능하고 명시적이고 객체지향적인 형태가 되었다고 생각한다. 이전에 내가 짠 코드와 비교해봤을 때, 많이 발전했다고 직접 느낄 수 있었고, 이전보다는 마음에 들었다. 물론 그렇다고 100% 만족하지는 않는다. 여전히 모르는게 많고 최선이 아닌 차선으로 짠 코드들이 있다. 그럼에도, 책에서 배운 내용들을 직접 적용하고 더 발전되게 고민하며 개발했다는 점에서 스스로 어느정도는 만족스러웠다.

---

3. 그 외 일들

1) 기술 문화 들여오기

팀 내 파이썬 스타일 문서

기존에 우리 팀에는 파이썬 관련 컨벤션이 따로 없었는데, 이 때문에 코드 스타일이 코딩 하는 사람 제각각이었다. 내 기준에 안 이뻐보이는 코드들도 종종 있곤 했다. 이 때문에 코드 리뷰 하기에 앞서, 코드 스타일을 먼저 통일할 필요가 있었다. PEP8과 구글 파이썬 스타일, 그리고 몇몇 필요한 내용을 더 담아 파이썬 스타일 문서를 만들었다. 깃허브에 올려 팀원들에게 공유했고, 모두의 동의를 얻어 컨벤션을 확립할 수 있었다. 팀원들은 이제 코드 스타일에 관해서 고민할 시간이 줄게되었고, 리뷰해주는 사람은 필요한 리뷰만 딱딱 해줄 수 있게 되었다. 우리 팀의 코드가 앞으로 더 나아질 준비를 한거 같아 뿌듯하고 기뻤다.

추후 파이썬 스타일 뿐 아니라 깃허브 관련 컨벤션도 정립해볼 계획이 있다.

 

그룹 내 공용 파이썬 라이브러리

ETL 관련 코드를 작성하다가 이 코드를 함수나 클래스 형태로 만들어, 데이터 그룹의 분석가나 머신러닝 엔지니어들이 직접 코드에 가져다 쓸 수 있게 하면 어떨까? 라는 생각을 했다. 그룹 내에서 사용할 공용 파이썬 라이브러리가 있으면 좋겠다는 생각이 들었고, 여기에 ETL, 슬랙 관련 알람, ML 모델 등 자신이 만든 유용한 기능들을 담아 그룹 내 다른 사람들이 사용하게끔하면, 쓰는 사람도 편하고 만든 사람도 뿌듯할 거 같았다.

그래서 Haribo 라는 이름의 Private 파이썬 라이브러리를 만들었다. 맛있는 여러 젤리가 담긴 하리보 젤리처럼 유용한 여러 패키지들을 담아두는 라이브러리라는 의미다. 는 나름 의미 부여한거고, 사실 회사 라운지 간식에 하리보가 보여 그냥 그걸로 지었다. 아직 이 라이브러리에 추가된 패키지는 별로 없지만, 나와 동료 런던, 카일이 추가하려고 계획해둔 패키지들은 몇 개 있다. 개인적으로 이런 공용 라이브러리가 잘 활성화 되면, 코드 리뷰도 활발해지고 그룹원들의 전반적인 코드 실력도 향상되지 않을까 기대해본다.

 

2) 커뮤니티와 스터디 모임 만들기/참여하기

수군수군 파이썬 개발자 오픈 카톡방

입사 후 초기에 한창 파이썬에 빠져 파이써닉하고 좋은 코드를 잘 짜고 싶다고 생각하던 때, 이런 고민들을 함께 나누고 공유하는 자리가 있었으면 좋겠다고 생각했다. 파이썬 관련 커뮤니티를 찾아보았는데, 뭔가 만족할만한 느낌은 아니었다. 결국 내가 파이썬 관련 카카오톡 방을 하나 만들게 되었다. 사실 처음에는 파이썬을 정말 좋아하는 개발자들만 모아서 소소하게 이야기해보며 나중엔 오프라인 모임도 해봐야라고 생각했었는데, 어쩌다 보니 사람 수가 너무 많아졌다. 사실 사람 수에 비해 이야기하는 사람은 별로 없긴 하지만, 그래도 파이썬을 좋아하는 사람들이 모여있는거 같아 파이썬 이야기 할맛이 난다. 처음에는 실명제로 운영되어 사람들이 좀 더 책임감을 가지고 말할 수 있도록 하려고 했는데, 지금은 내가 만드는 과정에서의 실수로 익명도 가능한 카톡방이 되었다.

사실상 내가 질문하기 위해 만든 방일지도... ㅋㅋㅋ

아파치 에어플로우 오픈 카톡방

파이썬 오픈 카톡방과 마찬가지로, 에어플로우하며 혼자 뻘짓하고 고민하는 부분이 많았는데, 이런 고민들과 노하우를 공유하거나 받고싶었다. 특히 에어플로우는 데이터 엔지니어들의 주요 툴이기도 한데, 나와 비슷한 처지의 사람들이 꽤 있을거란 생각이 들었고, 이런 커뮤니티를 형성하고자 오픈 카톡방을 만들었다. (사실 이미 관련 채널이 있을 줄 알았는데 없었다. 그래서 그냥 내가 만들었다.) 이 방도 마찬가지로 그다지 활발하지는 않으나, 그래도 종종 에어플로우 관련된 아티클이나 노하우들이 되곤 한다. 한편, 나와 비슷한 일을 하는 분들이 모여있다는 것만으로도 뭔가 위로가 되기도 한다.

 

데이터 그룹 내 파이썬 스터디

데이터 그룹 몇몇 분들과 파이썬 스터디를 카일과 함께 주도하여 진행했다. 인프런의 파이썬 중급 강의를 주축으로 약 한 달 정도 정기적으로 모여 공부한 내용을 발표하며 공유했다. 사실 나는 아는 내용이 대부분이어서, 스터디원들에게 도움이 될만한 파이썬 관련 아티클들을 스터디에서 소개했다. Dataclass, TypeDict, 클린 코드, 파이써닉한 코드, 포매팅 등을 소개했던 기억이 난다.
여하튼 그룹원들의 파이썬에 대한 관심과 실력이 조금 더 향상된거 같아 뿌듯하기도 했고, 무엇보다 카일을 통해 스터디를 어떻게 이끌고 진행하는 지를 배울 수 있어서 좋았다.

 

사내 클린 코드/아키텍처 채널

아키텍처를 공부하며 직접 적용해보면서 너무 너무 궁금한 부분이 많았다. 이렇게 해도 되나? 싶은 고민들이 비일비재 했는데, 딱히 어딘가에 물어볼 사람이 없었다. 그래서 사내 슬랙 전체 개발자 채널에 클린 코드/아키텍처 쪽으로 관심있는 사람들을 모았고, 함께 고민을 나누는 채널을 만들게 되었다. 이곳은 사실상 내가 회사에서 코딩을 하며 질문하는 곳이 되었다. 아무래도 회사 관련된 내용들은 외부에다가 물어볼 수는 없고, 같은 회사 사람에게 물어볼 수 밖에 없는 경우가 많았는데, 이 채널은 나에게 그런 창구 역할을 해주었다.

사내 동료 개발자 분들에게 늘 감사하다...

이 채널을 통해 다른 부서의 개발자 분들도 알고 소통하게 되었다. 서버 팀, 모빌리티 팀, 클라이언트 팀에 소속한 여럿 분들을 알게 되었다. 이래저래 나보다 경력이 많으신 분들에게도 도움을 많이 받았다. 사내에 혼자 고민하고 개발하는 시간이 조금 줄어들게 되었다.

---

4. 좋고 아쉬웠던 것들

1) 좋았던 것

개발과 배포, 운영 모두 경험해봤다는 것

레거시, 새로운 프로젝트 개발부터 무중단 배포와 테스트까지 전 과정을 경험해볼 수 있어서 좋았다.

파이썬으로 개발하는 동안에는 파이썬에 온전히 집중하여 이전에는 몰랐던 여러 파이썬의 기능에 대해서 더 잘 알게되었다. 지속 가능한 개발을 위해 클린한 코드와 아키텍처를 고려해야 했고, 이는 내가 공부하게끔 만드는 원동력이 되었다. 그리고 공부한 내용을 실제로 적용함으로써 공부하는 것에 더 집중할 수 있었고, 실제로 그렇게 짠 유연한 코드가 배포 하루 전 급하게 수정이 필요할 때 빛이 나는 것을 경험해볼 수 있었다.

코드 뿐만이 아니라, 도메인 담당자들과 내용을 전달받고 요구사항을 명확히 하는 것, 도메인 용어를 확립하는 것들도 경험해볼 수 있었다. 그리고 이렇게 될 때 그렇지 않음과 비교해 훨씬 소통이 원활해지는 것도 느낄 수 있었다. 개발자의 역할은 생각보다 범위가 넓고, 유능해야 함을 느꼈다.

학교나 개인 프로젝트에서는 해본 적 없던 무중단 배포를 경험해보며, 한번 달리기 시작한 프로그램을 크게 수정하는 것은 꽤 번거로운 일임을 알 수 있었다. 지속 가능한 개발을 말하곤 했지만, 처음부터 코드 기둥을 잘 세워두는 것이 꽤 중요한 것도 느꼈다. 더 공부해서 더 잘 알고, 적절한 판단으로 코드를 설계해나가는 것이 유능한 개발자임을 알았다.

 

MSA와 쿠버네티스에 대해서 경험해봤다는 것

이전에 말로만 듣고 뭔지는 몰랐던 쿠버네티스를 공부해보고, 실제로 팀에서 사용하기 위해 처음부터 구축해본 경험을 해볼 수 있어서 좋았다. 사실 이런 역할이 나에게 과분한 것이기도 했지만, 주어진 기회에 최선을 다해보고 싶었다. 삽질도 많이하고 여전히 부족한 게 많지만, 어디서든 쉽게 얻지 못할 좋은 경험을 가졌다는 것은 확실하다.

쿠버네티스 클러스터 구축과 더불어 이 위에서의 배포 방법들에 대해서도 알아보고 고민해보았다. Helm 으로 시작해서, 랜처, ArgoCD 둘 다 써보며 어떤 장단점들이 있는지 직접 느껴볼 수 있었다. 리소스 모니터링이 왜 필요한지, 쿠버네티스 환경에서 로그는 어떤식으로 관리할 수 있는지 알게되었다.

 

에어플로우에 대해서 좀 더 잘 알게 되었다는 점

에어플로우 on 쿠버네티스 작업을 하며 에어플로우 아키텍처가 어떤지 잘 알 수 있었다. 트러블 슈팅때마다 일일이 로그를 확인해나가는 과정에서 에어플로우의 각 컴포넌트 (웹, 스케쥴러 등) 이 어떤 역할을 하는지 실제로 눈으로 봐야만 했다. 에어플로우의 빼곡한 Configuration 관련 문서를 자주 찾아보며 어떤 설정 값들이 있는지, 그 설정 값들이 어떤 역할을 하는 지 알 수 있었다.

무엇보다 이렇게 매번 시도해보고 결국 동작 가능하도록 만들면서 어떤 오픈 소스도 공부하고 다뤄볼 수 있다는 자신감이 생겼다.

 

2) 아쉬웠던 것

부족한 내 개발 스킬과 노력

매번 개발할 때 마다 느낀다. 내 코드가 그렇게 아름답지 않다는 걸. 누군가에게 당당히 보여주며 뽐내지 못한다. 나름 고민해서 짰다는 것만으로는 부족하다. 잘 짜고 싶다.

그러려면 공부를 해야 하는데, 사실 욕심에 비해 공부량이 많지 않았다고 생각한다. 느슨했다. 한창할 땐 하다가, 또 풀어져 확 쉬어버리곤 했다. 시간이 지나자 긴장도 조금 풀렸었다. 여유를 가지는건 좋지만, 그래도 할 땐 해야한다고 생각한다. 내년에는 좀 더 집중해서, 좀 더 긴장감을 갖고 살아야겠다.

 

기록의 부재

중간에 TIL 이나 블로그 글을 통해 그날 그날 알게된 기술적인 내용들이나 공부한 걸 종종 적기는 했으나, 여전히 미루고 미루다 정리하지 않은 글들이 많다. 생각해보면, 정리하여 쓸만한 글들은 쌓여있다. 이런 내용은 잘 정리해서 남겨놔야지 했지만 ... 하지 않은 이유는 대부분 내 게으름 탓이다.

컨트리뷰션 보드만 봐도 매우 빈약하다... 내년엔 더 채우도록 하자!

올려서 정리한 글들은 대부분 내 일상이나 생활 혹은 책을 읽고 정리한 글들이 대부분인데, 앞으로는 구체적인 기술에 대한 글들을 더 써야겠다. 내년에는 더 부지런해지자..!!!

* 읽었던 책으로 보는 내 관심 키워드

글을 쓰다가 든 생각인데, 내가 읽었던 책과 인강을 잠깐 정리하면, 한 해동안의 내 관심 키워드가 뭐였는지 확 알 수 있을거 같다.
그래서 읽었던 순서대로 적어본다.

• 스프링 부트와 AWS로 혼자 구현하는 웹 서비스
• 스프링 부트 개념과 활용
• 자바 객체지향 디자인 패턴
• 파이썬 클린 코드
• 파이썬 코딩의 기술(개정2판)
• 슬기로운 파이썬 트릭
• 우리를 위한 프로그래밍 : 파이썬 중급
• Vue.js 중급 강좌 - 웹앱 제작으로 배워보는 Vue.js, ES6, Vuex
• 프로젝트 성패를 결정짓는 데이터 모델링 이야기
• 클린 아키텍처
• 데브옵스(DevOps)를 위한 쿠버네티스 마스터
• 도메인 주도 설계 철저 입문
• 오브젝트

자바, 파이썬, 클린 코드와 아키텍처, 그리고 다시 기본이 되는 객체지향 순으로 관심을 가졌던 거 같다.

---

5. 나가며

날 잡고 몰아서 확 쓰다보니 글 쓰다가 금방 지친다 ㅋㅋ... (이 게으름 ... )
그래도 올해 내가 했던 일들과 느낀점, 공부했던 것들은 아쉽지 않게 적은거 같다.

데이터 엔지니어로서는 인프라와 기술쪽(쿠버네티스와 에어플로우 세팅, 운영)을 경험해볼 수 있었고, 개발자로서는 백엔드 서비스 개발 과정의 전체적인 흐름을 다 경험해볼 수 있었다. 얇고 넓게 배운 느낌이랄까? 입사 초기때의 생각과는 다르게 ML보다는 클라우드, 데브옵스, 서버 백엔드 엔지니어 쪽에 더 관심이 간다. 좀 더 서비스 계층에 가까운 ML은 이런 기반 기술을 공부한 이후에 도전해봐도 괜찮을 거 같다는 생각이 든다.

이렇게 나의 1년차 엔지니어, 그리고 직장생활을 지냈다.
내년에는 내 실력도, 건강도, 사랑도 모두 챙길 수 있는 사람이 되고 싶다.