본문 바로가기

일상, 생각, 경험/그냥 얘기

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

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

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

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

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

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


5. 나가며

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

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

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

반응형
  • BlogIcon 김현우 2020.12.31 21:30 신고

    흠시님 올 한해 고생 많으셨습니다!! 회사에서 일하면서 취업관련 내용이나 코드 많이 봣었는데 벌써 일년이나 지났네요 ㅎㅎ. 좋은 글 써주셔서 감사하구, 2021년 한 해 새해복 많이 받으세요~~ 😀😀

    • BlogIcon 흠시 2020.12.31 21:44 신고

      감사합니다 현우님. 대학원 생활은 괜찮으신지요! 올 한해 고민도 걱정도 많으셨을것 같은데 정말 고생하셨습니다 ~ 현우님도 새해복 많이 받으세요!

    • BlogIcon 김현우 2021.01.01 00:54 신고

      아휴~ 감사합니다 흠시님. 8월까지는 모든 일이 안풀렸는데 하반기 와서는 하나씩 매듭지어 가는 기분이네요. 흠시님도 2020년도 고생 많으셨고 올 한해에는 꽃 길만 걸으시길 바랍니다! 새해 복 많이받으세요.

  • 유민환 2021.01.01 19:27

    안녕하세요 흠시님 2021년 새해복 많이 받으시길 바라겠습니다! 예전에 백엔드 관련 해서 메일을 보냈는데 기억하실지는 모르겠네요 ㅎㅎ 그때이후로 도움이 많이 되긴 했지만 학업공부하느라 말씀해주신 내용들을 적용해보지는 못했네요 ㅠㅠ 이제 4학년이 되서 적용해보려고 하는데 저도 진로가 데이터 엔지니어인데 데이터 엔지니어에 대한 지식이 하나도 없는상황입니다. 현재 생황을 보았을 때 흠시님께서 보시기에 백엔드 엔지니어에 대한 공부를 하고 준비하면서 데이터 엔지니어에 대한 공부를 하는게 좋을까요??

    • BlogIcon 흠시 2021.01.02 15:16 신고

      안녕하세요 민환님. 댓글로 다시 뵙게 되네요~

      데이터 엔지니어로 첫 직장을 잡으시는게 목표라면, 데이터 엔지니어 관련 프로젝트를 어떻게든 한번 해보시는게 좋다고 생각해요.
      보통 배치성 프로그램을 돌리고, 데이터를 쌓고, 그 데이터를 가지고 어떤 기능이나 서비스를 제공해주는 프로젝트겠죠..? 처음부터 끝까지 해보시는 과정에서, 어떤 이슈가 있고 어떤걸 고려해야하며, 어떻게 해결해나가야 할 지 경험해보실 수 있을거라고 생각합니다.

      이와 관련된 프로젝트가 딱히 떠오르는게 없다면, 백엔드(서버) 엔지니어링 공부 해보시길 추천 드립니다. 이전에도 말씀드렸던 것 같은데, 사실 데이터 엔지니어링 업무는 데이터 소스가 이미 존재하는 상황에서 생기는 것이기 때문에, 데이터 소스가 존재하지 않는다면, 데이터 소스를 만들어야 겠죠. 위 경우 (데이터 엔지니어링 프로젝트부터 시작해보고 싶은 경우) 는 크롤링으로 데이터 소스를 잡아오는 것같이, 데이터 소스가 이미 존재한다고 생각하고 말씀드린 것이였습니다.

      한편 취업을 생각하신다면, 직무를 떠나, 전공 지식을 먼저 한번 싹 정리해주시면 어디를 지원하든 도움이 될거라는 생각이 먼저들구요. 이 부분과 관련해서는 AeroCode 블로그가 좋은 예인거 같아요.
      https://aerocode.net/

      사실 정답은 없습니다 ㅎㅎ 다만 저는 늘 기본기와 본인이 집중하고 싶은 분야 하나를 정해서 잘 해보셨으면 좋겠어요. 그게 프로젝트가 되었건, 코딩 테스트가 되었건, 재밌는 거 하세요..! 도움 안되는 건 없습니다.!

      새해 복 많이 받으시구요..!

    • BlogIcon 유민환 2021.01.03 18:46

      항상 좋은 말씀 감사합니다 ㅠㅠ 한가지 더 질문이 있는데요

      만약 백엔드 엔지니어로 취업을 한 뒤 데이터 엔지니어로 가는 커리어를 하고 싶다면 백엔드 엔지니어를 위한 공부 중에서 개발언어는 어떤걸로 선택하는것이 좋을까요?

      현재 한국에서는 자바가 백엔드 언어의 대부분을 차지하고 있고 데이터 엔지니어를 위해선 파이썬이 필요한데 그냥 둘다 공부하는 편이 데이터 엔지니어를 위한 길이라고 생각하시나요? 의견부탁드립니다.

      마지막으로 항상 좋은 말씀 감사합니다!!!!!

    • BlogIcon 흠시 2021.01.07 01:33 신고

      이제는 제가 파이썬 개발자라...
      원래부터 쭉 파이썬을 해오셨으면, 파이썬 웹 백엔드로 준비하시는 것도 나쁘지는 않아보이는데, 처음부터 고민하시는거라면... 저라면 자바(코틀린) 쪽을 해볼거 같습니다.

      현실적으로 서비스 백엔드 엔지니어가 아직은 자바를 훨씬 많이 쓴다고 느끼거든요. 채용 공고만 보셔도.. 파이썬 개발자보다 자바가 훨씬 많습니다...

      가고자 하시는 기업이 딱 파이썬을 쓴다거나, 파이썬의 활용도가 너무 좋아 난 파이썬으로 다 개발할래! 가 아니시라면, 저는 취준의 목적으로라도 자바가 더 좋을거 같아요.

  • 나현 2021.02.01 01:17

    안녕하세요, '판다스, 취업' 이라는 검색어를 구글에 넣고 이리저리 클릭하다가 흠시님의 취업준비부터 여기까지 읽게 되었네요? 하나하나 글들이 모두 저에게는 좋은 글들로 다가와서 이렇게 처음으로 댓글을 남깁니다.
    취업에 '잠시' 실패하신 글을 읽었을때는 저도 너무 안타까운 감정을 느끼면서 '취업성공한 글이 있으려나? 있으면 좋겠다' 생각하면서 여기까지 왔네요. 승승장구하시길 기원합니다. 저는 08년도부터 외국계반도체 회사에서 세일즈 업무를 하고 있는데요, 요즘 업무에 파이썬을 적용하면 어떨까?(개인적으로만) 하는 생각으로 독학중에 있었습니다. ('엑셀로 하면 되잖어!') R, 판다스., ., 둘다 제 업무의 데이터를 처리하기에는 제 업무에서의 백데이터는 매우 적은 편이라 맞는지는 모르지만. DOS시절의 언어와 비슷(?) 한 부분이 있어서 추억놀이 비슷하게 따라하고 있습니다.
    원래 목적이였던 '판다스, R 이녀석들을 좀 공부하면 업무에 도움이 많이 되려나?' 를 떠나 흠시님 글을 읽으면서 많은 긍정적인 에너지를 얻고 갑니다. 저 스스로를 돌아보고 발전시킬수 있는 생각들을 하는데 많은 자극이 되어 감사하단 말씀을 드리고자 합니다.

  • BlogIcon wolny 2021.02.04 14:14 신고

    안녕하세요. 카카오 코딩테스트에 알아보다가 블로그 글이 너무 좋아서 여기까지 읽게되었습니다!
    저는 통계학 석사 졸업을 앞두고 있는 학생인데, 흠시님이 몸소 겪은 데이터 분석가의 현실이 잘 드러나서 배울 점이 많았습니다. 저는 학부때부터 통계학 전공을 했기 때문에 다양한 분석을 시도해봤으면서도 알고리즘 구현과 같은 코딩에 약해서 진로를 쉽게 결정할 수 없는 상황이거든요...(T_T)
    데이터 분석을 직업으로 하려면 석사이상의 학위가 필요하다고 해서 여기까지 왔더니 이제 경력을 요구하네요..
    분석 프로세스의 모든 부분을 경험하신 흠시님을 존경합니다. 많은 자극을 받게 되는 하루였어요. 너무 감사합니다. 좋은 하루되세요~

  • 2021.02.10 14:49

    비밀댓글입니다

  • BlogIcon run() 2021.02.22 13:15 신고

    후기 잘 봤습니다! 직접 경험한 내용과 고민을 잘 풀어놓으셔서 더 와닿네요 :)

  • BlogIcon dirmathfl 2021.03.02 14:56 신고

    근래에 블로그 피드를 잘타지 않아서, 이 좋은 글을 이제서야 읽게 되었네요.
    늦었지만 새해 복 많이 받으시고 올해 계획하신데로 잘 진행되면 좋겠어요😀

  • 정말감사해요 2021.03.04 01:48

    안녕하세요. 정말감사해요입니다. 제가 아직 티스토리블로그를 제대로 해보질 않아서 필명을 임시로 이렇게합니다.
    과거 '블로그 시작' 하실 때, 데이터들을 모아 공유해주신 글을 오늘 보았습니다.
    그 이후로 글이 너무 감명깊어 둘러보다가, 참여하셨던 프로젝트 글까지 찾아오게 되었네요.
    제 롤모델 중 한분이 되실 것 같습니다. 항공 쪽 전공을 한 취준생입니다.
    21년부로 정말로 졸업을 하게 되었고, 전공 쪽 상황이 어려워진것도 있지만, 원래 프로그래밍/데이터 쪽에도 관심이 많았어서 투트랙으로 공부하며 취업준비하고 있습니다.
    블로그 운영 관해서 관심이 많았는데, 구글에 "티스토리 개발" 검색을 하였더니 구글 2번째 상위에 노출되셨습니다.(감사함의 선물로 정보드립니다 ><;)
    앞으로도 많이 배워나갈 것 같고, 저의 추진력으로 이번 주내지 다음주 이내에 블로그 개설까지 할 것 같습니다.
    앞으로도 많이 감사할 것 같고 소통도 많이 할 것 같아 미리 인사드립니다.
    블로그 개설하면 또 인사드리러 오겠습니다!

    힘들지만..즐거운 출퇴근길 되세요!

    • BlogIcon 흠시 2021.03.04 02:25 신고

      감사합니다~ (블로그 노출에 관련된 정보도 감사합니다 ㅋㅋ 몰랐네요 ..)

      졸업 축하드리고, 블로그에 좋은 글 많이 공유해주세요!

  • BlogIcon 맞아 바로 그거야! 2021.03.11 00:04 신고

    안녕하세요. 여기 바로 위에 있는 '정말 감사해요' 입니다.
    이전에 2020년에 제가 블로그로 시작을 하려다가 멈춘 흔적이 있는 블로그를 다시 일으켜새워 보려고, 로고도 만들어보고 그랬네요. ㅎㅎ
    오늘은 선물로 구글 광고 클릭을(으잉?) 해드렸습니다. ㅎㅎㅋㅋ
    구독도 했고.. 종종 자주 오겠습니다.
    흠시님 덕분에, 블로그 마음 다 잡은 거 같아서 ㅎㅎ .. 제 현재 롤모델입니다.
    3월 4일 댓글남긴 날로부터 딱 7일, 3월 11일. 오전 12시. 약속 지켰습니다~!!

    아차!! 블로그 재개 계기 글을 포스팅하려고 하는데, '흠시'님 블로그 사례를 보고 감명받았다 정도로 언급해도 괜찮을까요~?

    앞으로도 많은 도움 받아가며 배우겠습니다. 파이팅입니다 흠시님.

    • BlogIcon 흠시 2021.03.11 19:22 신고

      안녕하세요~!
      마음 다잡고 뭔가를 시작하시는 모습 멋집니다! 일단 시작부터 하는게 반이라잖아요?!
      광고 클릭도 감사해요 ㅋㅋ 게시글에 언급 하셔도 괜찮습니다 ㅋㅋ
      좋은 글 찾아보러 저도 종종 들어가보겠습니다 !

  • 융이 2021.03.15 10:53

    글이 참 가독성 좋고 술술 잘 읽혀요. 재밌습니다 :)
    저는 개발자 준비중인 사람입니다..ㅎㅎㅎ
    저도 추후엔 블로거님 처럼 개발 글을 조리있게 잘 쓰는 개발자가 되고싶다 느꼈네요... ㅎㅎㅎ
    글 재밌게 읽고 갑니다 :) 좋은 글 감사합니다!

  • 2021.03.22 00:07

    비밀댓글입니다

  • 2021.03.25 00:37

    비밀댓글입니다

    • BlogIcon 흠시 2021.03.25 10:12 신고

      최근에 올리신 글도 유용하게 보았습니다! 제가 더 감사합니다 :)

      공식 차트 계속 기다리고 있는데 2.1 부터 나오는군요... 그 때까지는 1.10.14 로 계속 운영할듯 싶습니다. 정보 감사합니다!