다니는 병원 의사 선생이 하신 말씀인데 무슨 운동 처방법을 알려주면 효과를 보는 환자, 효과를 못 보는 환자가 나뉘기 마련이다. 효과를 못 보는 환자는 대체로 냄비처럼 화르륵 끓어서 한동안 열심히 하다가 흐지부지하는 경우가 많다고 한다. 반대로 효과를 보는 경우는 하는듯 마는듯 설렁설렁하면서 그냥 국으로 하다보니 몸이 좋아진다고.
찔려서 그럴지 몰라도 왠지 엄청 기억에 남는다. 이걸 짧게 영어로 하면 less is more이 가장 느낌있는 번역인 것 같다. 조금씩 조금씩 하다보면 결국 더 많아 진다는 건 지금 이순간 엄청 크게 하지 않아도 된다는 말이기도 하니까 마음의 부담을 더는 효과도 있다.
찾아보면 airflow 글이 참 많다. data engineering 측면에서 굉장히 인기 있는 것 같다. 사실 deep하게 써보지는 않았지만 내 입장에선 왜 인기가 있는지 잘 모르겠다. 기존에 써본 oozie 보다는 분명 기능적으로 좋은 부분이 있다.
data scientist 입장에서 보면 airflow가 data product을 만들기에 가장 적합해보인다. query -> data process -> model -> deploy(는 mlflow겠지만) 과정을 하나의 python tool로 할 수 있는게 장점 같다. 하지만 이게 그렇게 좋냐고 물어보면 그렇게 좋은지는 잘 모르겠다. 추측이지만 진짜 data를 많이, 다양하게 활용하는 기업에서는 좋을 수 있겠다는 생각은 있다.
개인적으로 airflow를 써보며 얻은 건 dag 개념, 그로 인해 source code 품질이 상당히 좋아졌다는 점이다.
dag라는 걸 이해하기가 어려웠는데 이를 도와준게 cookiecutter 였다. 이 덕분에 기존에 마구잡이로 개발하던 습관을 전부 뜯어고치고 뭐든 구조화하는 개념에 익숙해진 것 같다.
airflow는 debugging이 어렵다. 그래서 단순 code error가 발생하지 않게 먼저 꼼꼼히 개발하는게 필요한 것 같다.
이 때 필요한 건 내가 짠 코드는 틀릴 것이라고 생각하는 것.
대부분 코드를 짜다보면 잘 되겠거니 믿고 넘어가는 부분이 생긴다.
그 믿음을 버려야된다. assert 같은 censor로 확인해야된다.
dag를 만들기 위해 code를 task 단위로 나누자고 마음 먹으면 처음엔 막막하다. 내가 무슨 기능을 만들었는지 기억도 잘 안나서 dependency가 있는 code를 나눠버리기도 한다. 하다보면 나중엔 한 눈에 보인다. module 단위로 기능이 잘 묶여 있어서 기억하기도 쉽다. 구조화가 더욱 정교해져서 code 재사용 가능해지게 된다. unittest도 가능해져서 더욱 code에 믿음이 간다.
오늘 글을 3개를 몰아 썼는데, 답답함을 어떻게든 풀고 싶어서가 아닐까 싶다. 회사 일이 참 쉽지가 않다. 데이터 분석가는 수학, 현업, 코딩 3개를 다 잘 알아야 뭐가 돼도 되는건데 하나도 잘하는게 없다는 생각이 요즘 든다. 창 밖은 태풍 분다. 😑
2년차가 잘해봐야 얼마나 잘하겠냐만은, 내가 정말 잘해도 과연 내 월급값을 회사에 벌어다주는지 의문이다. 내가 하는 일로 영업에 보탬이 얼마나 될지 좀 회의감이 앞서고 보람도 떨어지는 것 같다. 그렇다고 자기 개발에 도움이 되는 과제를 하는 것 같지도 않아서 개인 시간을 따로 할애해야될 것 같다.
요즘은 애도 어른도 다 비슷하다는 생각이 들곤 한다.
회사에서 몸을 쓰는 만큼 일 끝나면 몸을 위한 시간을 단 15분이라도 가지고 싶다.