#데이터엔지니어 #회고2021 #Python #Kubernetes #OpenSource #삶
2021년 마지막 날이다.
나, 뭐했지?
Literally
•
새 회사를 들어갔다. 데이터 엔지니어로써 커리어를 이어가고 있다.
•
작년과는 달리 어느 정도 밸런스를 찾은 듯
•
하지만 여전히 부족하고, 고민이 많고, 성장하고 싶다...
2021년 목표(OKR) 리뷰
O: 선한 영향을 주는 개발자 되기
내 일상에서 가장 많은 이야기를 하고, 가장 속 깊은 이야기를 하는 사람인 여자친구가 입버릇 처럼 하는 이야기다. 중의학을 배우는 여자친구는 돈을 많이 버는 것도 좋지만, 남들에게 선한 영향을 주는 사람이 되고 싶다고, 경제적인 여유를 찾은 뒤에는 봉사하는 삶을 살고 싶다고 이야기를 하곤 한다.
나도 부족하지만 내 힘으로 내 철학대로, 다른 사람의 어려움을 기술적으로 해결해 보고 싶다.
개발자로 취업을 하기 전, 나는 어떤 조직이나 회사의 부속품으로서 일만 하는 게 아니라, 나만의 철학을 가진 엔지니어가 되는 게 목표라고 생각했다. 2년 차 개발자인 지금, 내가 잘해왔는가 돌이켜 보면 그렇지 않은 것 같다. 다가오는 2021년에는 좀 더 내 소신과 철학을 단단하게 할 수 있는 사람이 될 수 있으면 좋겠다.
KR1: 블로그 글 24개 쓰기
한 달에 두 개씩 글쓰는 건데, 솔직히 좀 많은 거 같긴하다. 그래도 목표는 크게 잡는 거라고 배웠으니 지르고 생각해 본다.
KR2: 오픈 소스 서비스 3개 만들기
매번 프로젝트 아이디어를 생각해내서 주말에 시작하는 데 마무리는 못 짓는다. KR로 만들어두면 좀 마무리까지 하는 프로젝트가 만들어 지지 않을까 싶어서... 도메인도 샀겠다 3개 정도는 할 수 있지 않을까? (조져버려야지... 하지만 조져지는 건...)
작년 회고 글의 OKR을 굉장히 오랜만에 본다. (일단 이것부터 잘못됨)
KR1: 블로그 글 24개 쓰기 → (4개, 4/24 = 16.7% ...)
블로그 글 정말 많이 못 썼다. 배운 것들은 정말 많고, 그로 부터 끄적였던 것들도 꽤 있지만 블로그 글로 만들어진 것들은 4개 밖에 없었다.
회사 동료들과 함께 일주일에 한번 배운 것들을 공유하는 TIL 모임을 시작하면서, 작업과 배운 것들을 같이 정리하는 습관이 생긴 거 같다. 하지만 이것들이 블로그 글로 만들어지는 데 내가 부담감을 느끼고 있나? 병목은 어디일까? 좀 더 고민해봐야 할 듯.
최근 기계인간 종립님의 인터뷰 글을 봤는 데 일지와 히스토리에 대한 부분에서 특히나 인상깊었다. 처음 회사에 입사했을 때, 많은 문서들이 있었지만 정리가 되어있다기 보다는 그냥 제각각의 형태로 기록만 되어있다는 느낌이 들었었다. 기록하는 습관이 정말 중요하다는 생각은 1년 전도 지금도 같다. 작년에는 ‘다음 회사에서는 정말 잘해야지!’의 느낌이었다면, 현재는 시도했지만 정말 꾸준하게 기록을 남기고 공유하는 데의 어려움을 절실히 느끼고 있다.
현재 회사의 처음으로 한 것들 중 하나가 Tech Spec을 쓰는 일이었다.
Tech Spec을 작성하면서 내가 풀려고 하는 문제가 무엇인지 (+ 정말 이 개발이 필요한지?), 왜 개선하려고 하는 지, 어떻게 문제를 풀고 개선했는가를 측정할 지 그리고 어떻게 구현할 건지에 대한 오버뷰를 쓰게된다.
Tech Spec은 전전회사에 있으면서 동료에게 전수받은 것인데, 팀 내에 잘 동작하는 모델로 만들어지고 있는 거 같다.
이 외에도 다양한 소프트웨어 엔지니어로서 팀 뿐만 아니라 본인에게도 도움이 많이 되는 문서를 쓰는 습관을 더 길러보고 싶다.
때문에 최근 테크니컬 라이팅에 대해 관심이 생기는 중이다.
기술과 문제, 그리고 그 의도에 대해서 정확하게 정리하지 못하면, 내 스스로를 설득할 수 없고 더더욱 다른 사람을 납득시킬 수 없다. 이러한 기술 문서를 잘 작성하는 방법은 블로그 글을 쓰는 데 도움이 되지 않을까? (이미 두서가 없다)
(번외로) 블로그 데이터를 살펴보자면
•
아무래도 딥하고 공들여쓴 글들이 많이들 봐 주시는 듯
•
dbt는 지금 관련 키워드 구글 검색 결과에서 top 3안에 항상 들어서, 꾸준히 사람들이 봐주신다
•
많이 쓰는 기술에 대한 좀 더 유용한 글, 또는 정말 흡입력있는 글을 쓰는 연습을 해서 리텐션을 올리고 싶다
•
군대에서 쓴 글 정말 못 썼는데 봐주시는 분들이 있다니...
•
글 더 자주 써야겠다...
KR2: 오픈 소스 서비스 3개 만들기 → 완료
퇴근하고 아쉬웠던 것들을 토이 프로젝트로 풀었다.
사용자들이 많지는 않았지만, 회사에서 필요한 부분들을 개인 프로젝트에 연습해보거나 적용가능한 것들을 만들어보는 용도로 사용하다 보니 생각보다 여러 프로젝트가 생겨났다.
1.
Pybus
위 책으로 사내 스터디를 했다. 클린 아키텍처, DDD 등의 아키텍처를 고민하면서 직접 적용해볼 수 있는 기회였다. 그 중, 이벤트 중심 아키텍처를 적용할 때에 Event Handler들을 쉽게 구현하는 구현체를 직접 만들어 봤다.
Keep
•
도메인 이벤트, 커멘드 (+명령-쿼리 분리) 인지하기: 모든 유즈케이스에서 쓸 정도는 아니더라도, 이런 식의 접근 방식을 메시지 기반 애플리케이션에서 활용해봐야겠다
•
사내에서도 쓸 수 있는 라이브러리 개인 계정으로 만들고 퍼블리시 하기: 좋은 방법인듯? (물론 업무 외 시간에 진행했습니다)
•
Github Release CI + 버저닝: 사내에서도 SemVer를 많이 사용하는데, 이 라이브러리를 PyPI와 Github Release로 퍼블리싱하는 연습이 많이 됐다.
Problems
•
책임에 대한 고민: 메시지를 넣고 뺴서 사용할 Queue나 그 구현체들을 라이브러리에 넣을지 말지에 대한 고민들을 하다가 결국 라이브러리에서는 제외 시켰다. 어디까지 책임을 부여할 것인가에 대한 고민의 일환이었지만, 지금 생각해보니 그냥 같이 들어가있는 것도 좋을 거 같다. 너무 이런 고민들이 길어지는 경향들이 올해 많이 있었다. 고민해서 어려운 길로 돌아돌아 가는 것보다 깔끔하게 ‘지금 고민할 부분이 아니다' 라고 미뤄보고, 마음이 바뀌면 ‘그때 가서 해보지!’ 라는 결심을 하는 건 생각보다 어려웠다.
Try
•
여기저기 프로젝트를 공유하거나 피드백 받고싶은 사람한테 리뷰 요청해보고 싶다.
2.
샤인 머스켓 커머스 - muskat / muskat-event
여름에 샤인 머스켓 농장하시는 할머니 포도를 지인 한정으로 저렴한 가격에 팔았다. 그 과정에서 그냥 구글폼만 던져서 배송하는 것보다, 뭔가 개발로 이 과정을 더 체계적으로 관리하고 나아가 여름마다 지인 한정 커머스를 해보고자 하는 큰 그림이 있었다.
대략 그렸던 아키텍처는 이랬다.
•
Google Sheet에 모든 데이터가 백업이 되지만, 굳이 굳이 DB에 개인 정보 (주소, 핸드폰 번호)는 제외하고 보관했다
•
App Script 편하드라... javascript 그대로 쓰던데?
•
지인 기반으로 하는 거기 때문에 좀 더 특별한 경험을 주고 싶었다
•
SMS 서비스를 처음에 썼는데, 사업자가 아니면 긴 메시지는 못 보내는 듯 했다.
요런 느낌...
•
이메일로 대신 보낼까 했는데... 생각보다 샤인머스켓 인기가 많아서 그럴 겨를이 없었음
샤인머스켓에 감동한 지인들과 서버에 트래픽이 생겨서 신난 험프리
또한 재밌었던 건 Kubernetes 클러스터 하나를 무료로 사용하게 해주는 서비스, Okteto를 이용했다.
내가 느꼈던 장점은
•
진짜 무료다: 서버 호스팅 비용 0. CPU와 Memory, 그리고 PV를 쓸 수 있는 쿼타를 어느 정도 주는데, 가벼운 애플리케이션 배포하기에는 정말 넉넉
•
Ingress 달아준다: nginx ingress, istio gateway 필요없다!
•
Helm Chart만 레포에 있으면 알아서 디텍팅한다: 배포에 들인 시간 (도커부터 쿠베까지) 정말로 20분 남짓
•
디버깅하기 위한 환경도 제공한다. 포트 포워딩해서 클러스터에 접근 가능 (어메이징했음... 이걸 서비스화하다니...)
단점은,
•
약간 부실한 가이드: 가이드에서는 okteto-pipeline.yaml 이거 없어도 되는 거 처럼 나와있는데 꼭 써야하드라...
•
모니터링 제공 x: (무료한테 너무 많은 걸 바라는 건가...?) probe랑 log로만 모니터링해야함. 이건 유료 플랜 쓰면 달라질 수도...?
위 레포는 기존에 만든 muskat 서버가 있는데 이는 secret 정보가 어쩔 수 없이 포함되서, private으로 돌리고 event driven 하게 리팩토링한 프로젝트다. 그 중 eventsourcing 이라는 라이브러리를 사용해봤는데, 파이썬에서 아직은 힘든 도메인 중심 애플리케이션 + 이벤트 소싱을 잘 풀어낸 거 같다.
이제 보니 python event sourcing 본좌 johnbywater 행님이 스타를 눌러줬다 (뿌듯)
다시 샤인머스켓 이야기로 돌아와서... 저렇게 구글폼을 받고, 이것저것하니 대략 30명 정도가 50박스를 사주셨다. 집에도 잘 못 가는 못난 손자인데도 할머니께서 전화로 고맙다고 8월부터 최근까지 맨날 말하셔서 곤욕을 치르긴 했지만 뿌듯했다. 내년에 더 멋진 걸 해봐야겠다.
Keep
•
실생활에 도움이되는 개발
Problems
•
아직까지는 딱히 의미없는 개발로 보일 수도 있다
Try
•
내년에 더 디벨롭 해봐야지
3.
그 외...
사내에서 쓰기 전 poc 목적으로 많은 라이브러리와 프레임워크, 아키텍처 패턴 등을 실험해봤다. (e.g., dbt, sqlfluff, fastapi, django-ninja 등...)
아직까지 공유할만 한 게 없다... 좀 더 발전시켜나가 봐야지
KR2의 목표를 설정할 때 ‘오픈소스 프로젝트 3개이상 만들기' 였으니깐 쉬웠지, star 수 100개 이상 서비스 만들기 였으면 절대 못했다.
컨트리뷰팅
1.
GitOps CLI
팀 내에서 GitOps 철학을 따라가기로 결정하고, 기존의 Helm + Argo 기반의 프로젝트를 CI와 연동하는 과정을 진행했다.
사내 CI 서비스와 Image를 빌드하고 Push하는 것은 원래 되어있었지만, Config Repo에 업데이트를 하는 과정이 고민이었다. 그러는 와중에 팀내 인프라 팀의 동료분이 아래 레포를 소개해줬다
Github 같은 곳에 올라가 있는 values.yaml을 수정하는 커밋을 CLI로 자동화할 수 있는 것 뿐만 아니라, PR 만들고 자동 머지, preview 기능 그리고 무려 Github, Gitlab, Bitbucket의 모든 인터페이스를 구현해놓은 프로젝트다. (스타 수가 많이 없긴 하지만...)
그 중, PR 머지를 하는 기능에서 Merge Option을 선택할 수 없어서 merge, squash, rebase 옵션을 선택할 수 있는 기능을 CLI에 추가하는 PR을 올렸다
feat(gitopscli/*): add merge method parameter to deploy command by socar-humphrey · Pull Request #155 · baloise/gitopscli
Hi, In my usecase, I needed to select a merge method other than Create a Merge Commit, but there's no merge method selection option on deploy command by default.
https://github.com/baloise/gitopscli/pull/155
관전 포인트 #1: 왜 나는 이걸 회사 계정으로 했는가...
관전 포인트 #2: 친절한 스위스 형들...
저 라이브러리 덕분에 CI/CD 환경을 좀 더 체계적으로 관리할 수 있었다.
2.
Boostcamp AI Tech - Serving
카일(A.K.A 메타몽좌)의 추천으로 Boostcamp AI Tech 2기의 제작 멘토로 활동할 수 있었다.
내가 맡았던 파트는 FastAPI, Logging, BentoML이었다.
FastAPI를 올해 초 부터 프로덕션 환경에서 쓰고 있어서 꽤 잘 안다고 생각했는데, 처음부터 설명하려니 모르는 게 정말 많았다. 대략적으로 아는 개념은 많았는데 그걸 왜 써야하는 지, 대안은 무엇이 있는 지 보는 사람으로 하여금 납득 가능하게 만드는 과정은 생각보다 참 쉽지 않았다.
특강도 진행했다. 무려 라이브에서 FastAPI 머신 러닝 서빙을 TDD로 구현했다... 는 물론 도중에 잘 안되서 마무리를 못함 ㅠ
200명 가까이 되는 인원이 봐주시는데 TDD와 테스트, 그리고 그게 왜 필요한 지 딜리버리하려고 했는데 생각만큼 잘 되지는 않았다. Public Speaking을 대학교 다닐 때 꽤 연습했다고 생각했는데, 아직 부족한 부분이 많음을 느꼈다.
(여담이지만 카일에게는 정말 많은 것들을 배운다. 전문성도 전문성이지만, 막막한 상황에서 본연의 문제에 집중해서 답을 내시는 기술이 정말 멋지다. 뿐만 아니라 정말 바쁜 와중에도 주변 사람들 챙기는 모습도 정말 존경스럽다. 나도 이런 사람으로 주변 사람들에게 기억될 수 있게 더 노력해야지)
얼마나 성장했나?
글이 너무 길어질 거 같으니 짤막하게...
소프트웨어 엔지니어링
•
역할과 책임, 그리고 의존성에 대해 많은 고민을 했다.
•
프레임워크/라이브러리 사용 때문에 희석되거나 등한시 될 수 있는 여러 소프트웨어의 중요한 원칙들을 지키려고 고군분투했다.
•
넓은 스코프(프로젝트 시작부터 아키텍처 설계, 디자인, 코드 구현, 인프라까지 다 다룰 수 있는 환경)이다보니, 더 넓은 시야에서 엔지니어링을 배울 수 있었다.
인프라
•
이전 회사에서도 인프라를 다뤘지만, 훨씬 많은 데이터를 흐르게 해야했고 그를 지탱하기 위한 인프라는 더욱 견고해야했다.
•
혼자서 작업할 때는 몰랐던 페인 포인트나 인프라 작업들을 협업하면서 생기는 문제들을 경험할 수 있었다.
•
인프라가 진화해 감에 따라 문서화의 중요성과 Runbook 등의 작업 문서의 필요성을 절실히 느꼈다.
•
작년에는 들어보기만 하고, 머리 아파서 제대로 읽어보지도 못했던 Service Mesh, Certificate, CRD, CNI 등의 개념들을 직접 부딪히면서 익혀나갔다.
데이터 엔지니어링
•
아직 경력이 그렇게 많이 되지 않았음에도 불구하고 트렌드의 변화를 많이 느꼈다.
•
Hadoop 기반, Spark + Cloud 기반 데이터 엔지니어링 트렌드를 지나 이제는 분산 컴퓨팅을 통한 ELT가 표준이 될 거라고 생각하게 되었다.
•
dbt 기반의 Data Lineage, Metadata 관리, 그리고 Data Governance를 향한 초석을 쌓아가면서 결국 전에 하던 많은 작업들은 결국 Saas와 플랫폼 차원에서 대체될 수 있겠다고 느꼈다.
•
하지만 이런 변화에도 불구하고 결국은 이를 뒷받침해주는 소프트웨어 엔지니어링(이런 변화를 뒷받침해주는 기술들에 대한 지식, 변화에 대응할 수 있는 코드와 환경 만들어 나가기 등)과 사내 인원들에게 중요성을 전파하고 설득하는 소통의 영역이 가장 중요해보인다. 본질은 변하지 않는다.
MLOps
•
역시나 춘추 전국시대다.
•
사내에서 만드는 모델들을 효과적으로 서빙하기 위한 툴들을 만들기 시작했다.
•
머신러닝에 대해서 잘 모르는 데 시작해도 될까 망설였었는데, 역시나 부족함이 많이 보였다.
•
‘개발'로 풀 수 있는 문제와 다른 방식으로 풀 수 있는 문제를 구분하고, 성급하게 다가가지 않아야 한다는 걸 느꼈다.
개발 관련 읽은 책들
•
오브젝트: 올해 가장 많은 영향을 받은 책
•
함께 자라기: 그랩이 선물해줘서 읽게 되었는데, 개인이 아니라 팀으로서 성장하는 방법을 고민하게 됨.
•
소프트웨어 장인: 더 좋은 엔지니어가 되기 위해 해야할 것들에 대한 영감을 많이 받았다.
•
파이썬으로 살펴보는 아키텍처 패턴: 올해 코드에 가장 많은 영향을 준 책
•
실전 카프카 개발부터 운영까지: 이건 내년에 더 많이 봐야할 책. 2독 3독 필수
•
데이터 중심 애플리케이션 설계: 읽고 있는 중이긴 한데 어렵다. 스터디도 함께하며 더 액티브 러닝 중
•
파이썬 비동기 라이브러리 asyncio: 비동기는 짱이 아니다. 하지만 적재적소에 쓰면 퍼포먼스를 확 올려준다.
2021년의 삶 리뷰
•
아지트를 만들었다.
카일, (킹갓)그랩, 래리와 같이 집 근처에 월세를 빌려서 우리만의 아지트로 만들어 가고 있다.
크리스마스 이브와 그 크리스마스 이브이브에도 같이 보냈다
지인들 초대해서 저녁 먹으면서 catch up하고, 재택이 길어지면서 업무 및 작업 공간으로도 사용하고 있다.
코로나 시국이 (이 이야기를 2년 째 하고 있지만) 괜찮아 지면 네트워킹 공간으로서 더 발전 시켜보려고 하고있다. 아지트 다른 멤버들이 각자의 필드에서 멋지게 살고 있는 사람들이라 많은 걸 어깨 넘어로 배우고 있기도 하다. 올해 한 일 중에 가장 잘 한 일인 듯. (티타임이나 방문 원하시면 DM...)
•
여자친구와 2주년
군대 말년 때 만나기 시작한 친구와 벌써 2년이 됐다. 첫 회사에서 일하느라 바빠서 연락도 안되고 맨날 12시 넘어 퇴근하는 데도 서운해하는 기색 없이 2년 다 되도록 한결같이 내가 더 잘 되길 진심으로 바라준다. 연고 하나도 없는 서울에서 너 없었으면 혼자서 참 힘들었을 거야. 난 참 운이 좋은 사람이라는 걸 가장 많이 느끼게 해주는 사람. (사진을 올리고 싶지만 허락을 안 받아서 패스)
•
바쁜 삶 속에 끊임없이 내려가는 나의 3대
운동을 하는 습관이 깨져버렸다. 재택을 하면서 운동하는 곳도 가까워서 더 자주 가게 될 줄 알았지만, 오히려 더 안 가게 된거 같다. 일어나자마자 출근해서 일하고 끝나면 누워서 유튜브 보거나 또 사이드 프로젝트나 이것저것 하느라 시간이 정말로 없다 (핑계). 내년에는 운동 좀 뽐뿌가 올 수 있도록 자극을 받을 수 있는 창구를 많이 만들어야지
2022년 목표 설정
OKR을 세울 만큼 회고를 자주 할 자신이 없어졌다. 매년 신년 버프를 받아서 거창한 목표를 세우기 보단, 정말 지킬 수 있고 중요한 것들로 목표를 설정해 본다.
•
침대에서 뒹굴 거리는 시간 줄이기, 주중 7시 기상
뼛 속까지 개발 덕후가 되어 버린지, 침대에서도 개발 아티클이나 공식 문서를 찾아보는 습관이 생겨버렸다. 좀 지루해지면 유튜브 보고, 다시 개발 찾아보고 반복인듯. 그러다보니 연말에는 불면증 까지 왔다. 최근 여자친구 추천으로 Billionare’s Routine을 시도해봤는데, 일어나자마자 이불 개는 게 효과가 좋았다. 올해 적어도 2달 이상은 유지해보는 게 목표
•
개발보다 내 삶 더 살기, 여행과 문화 생활 월 1회
올해 읽은 책은 모두 개발 관련한 것들이었다. 또한 개발 외의 다른 삶이 아지트에서 친구들 만난거, 여자친구랑 놀러다닌 거 밖에 없는 듯. 얼마 남지 않은 20대의 시간을 ‘꾸준히 성장하는 개발자’로서의 나 보다, 더 행복한 나를 만들기 위한 노력이 필요하다고 느끼고 있다.
•
주변 사람들을 더 챙기기, 친구들 만나고 작은 선물하기 월 1회
작년 OKR의 O와 상반되는 이야기이긴 하지만, 나는 참 이기적인 사람이다. 고등학교 때 부터 미국에 대학교갈 형편도 되지 않는 데 운이 좋게도 여러 사람들의 도움으로 대학교까지 갔다. 그러고도 어중간하게 이기적인 나는 그렇게 가족들에게 짐이 됐다는 부담감에서 벗어나기 위해서 지금까지 혼자 힘으로 뭐든 지 하려고 하고, 그러다 보니 오로지 내 앞길만 걱정하고 관심있게 되어 버린 거 같다. 올해까지 내가 더 성장하고 더 잘되려고 아득바득 노력했다면 내년에는 더 주위를 보고싶다. 여러 사람들을 만나고 이야기를 나눌 때 마다 느끼는 것은, 동료들과 주변 사람들에게 좋은 사람이 결국 자신에게도 더 괜찮은 사람이 될 가능성이 높아 보인다.
마치며
쓰다보니 엄청 길어졌다. 12월 31일에 쓰기 시작해서 1월 7일 새벽 1시에나 마무리한다. 이 글을 읽는 내 주위 사람들에게 난 어떤 사람으로 기억되고 있을까? 아마 그냥 열심히 사는 사람일거 같다. 올해 서울에 올라와서 살게 된지 10년이 넘었다. (물론 중간에 군대 갔다오고 미국 갔다오고 등등 제외하면 더 적지만...) 고등학교 1학년 미국에 갈거라는 꿈을 안고 1평 남짓한 고시텔에서 시작해서 지금까지 야금야금 발전해나가고 있는 거 같아서 감회가 새롭다. 다만 걱정되는 것은 이렇게 성장만 좇고, 개발만 하다가 뒤를 돌아봤을 때 아무도 없으면 어쩌나 싶은 생각이 요즘 많이 든다. 2022년에는 욕심일 수도 있지만, 작년에 말했던 ‘선한 영향력’을 개발 쪽 뿐만 아니라 그냥 삶에서 더 나눌줄 아는 사람이 됐으면 좋겠다.