[2023년 2월 회고] 소스코드 처럼 업무도 모듈화가 되려면... / 오, 나의 Python

 

안녕하세요. 글쓰는 개발자 입니다.

 

1월 회고를 2월 중순에 쓰는 바람에 금방 2월 회고를 쓰는 것 같아 시간이 더 빨리 가는 것 처럼 느껴집니다. 1월이 지난 1년 7개월을 돌아보면서 후련하면서 아쉽기도 하고 또 어떤 것을 새롭게 시작해야 할까 고민했던 시간이라면, 2월은 무언가 시작해야 했던 시간이었습니다. 신규 프로젝트를 설계하고 그 과정에서 약간의 깨달음도 있었습니다. 소스 코드는 인터페이스만 바라보지만 사람은 그 너머를 볼 수 있었기 때문에동료들과 원활한 소통도 가능했구나 하는 그런 것들 말이지요.

 

신규 프로젝트 아키텍처 설계

필요 기술 자료 조사

 MLOps 의 ML Engine 쪽을 맡으면서 학습 Metric, 시스템 Log를 수집하는 Pipeline 아키텍처 설계를 마쳤습니다. 생각만큼 쉬운 일이 아니었습니다. Web Backend 개발이 경력의 전부였던 제가 하나의 시스템을 설계하는 것이 쉽게만 느껴지지 않았습니다. 그런만큼 열심히 자료 조사를 하고 벤치마킹 할 만한 시스템은 무엇이 있나 열심히 찾아보았습니다.

 

 자료 조사를 하면서 대부분 비슷한 아키텍처를 사용하고 있다는 것을 알았습니다. k8s - Kubeflow 환경에서 동작하는 ML Pipeline의 경우, 'Data 전처리 - 학습 - 추론 - 배포' 각각의 Pod 내부의 Container의 SideCar로 부터 ML 관련 Metric을 수집합니다. 그리고 그 Sidecar는 Fluent-Bit 를 활용해 Kafka로 Data를 Produce 하고 수집한 Data 를 필요로 하는 곳에서 Consume 하는 구조입니다.

 

 저는 이런 비슷한 구조를 벤치마킹 하기로 했고 Data 수집은 grayLog를 활용하기로 했습니다. 이런 저런 자료 조사를 하면서, 예전부터 구축하면 좋겠다고 생각했던 Centralized Loggig System을 현재 개발 중인 프로젝트 전체에 적용 할 수 있겠다는 생각이 들어 설렜습니다. 지금은 전체 MSA 중 ML Engine과 관련된 Metric만 수집하지만 모든 컨테이너로 확장 할 수 있을 것 입니다.

 

구현의 어려움

 ML Engine 은 저를 포함하여 3명의 개발자가 진행 중입니다. 설계 단계에서부터 함께 참여 중이고 서로 직무가 다릅니다. Web Backend 개발자인 저와 ML, Data Engineer 한 분, 그리고 분산 딥러닝 쪽 전문가이신 인프라 엔지니어 한 분 입니다. 3명의 실무 경력을 합쳐도 한 자리 숫자인 아주 젊은 팀 입니다.

 

 야심차게 함께 자료 조사를 하고 각자 어느 부분을 맡아서 개발하면 좋겠다 했지만 현실은 녹록지 않았습니다. 세 명의 개발자 모두 전체와 부분을 모른다는 어려움이 있었습니다. 먼저, Web Backend 개발자인 제가 전체 아키텍처를 짰지만 ML Pipeline을 깊숙이 들여다보면 제가 모르는 것 투성이입니다. Container에서 나온 Metric을 Log File로 생산하고 그것을 Kafka로 전달 할 수 있지만 ML 관련 지식이 부족하니, 당장 구현 하는 데에 어려움이 있었습니다. 다른 두 명의 개발자 동료들 또한 마찬가지 였습니다.

 

업무의 모듈화

 아키텍처 설계까지 막힘 없이 잘 나아갔습니다. 열정적인 동료들과 함께 나름 선의의 경쟁을 펼치며 어떤 아키텍처가 좋은 지 구상하고 공유하며, 왜 이것이 필요한 지 상대방에게 설명하는 과정 동안 스스로 많이 성장 했음을 느꼈습니다. 특정 기술 도입과 아키텍처 설계에 대한 명확한 이유를 그 누가 물어보아도 설명할 수 있게 되었습니다.

 

 그러나 실제 구현은 달랐습니다. 그리고 곰곰이 생각해 보았습니다. '왜 코드처럼 업무의 모듈화가 되지 않을까?' 에 대해 말입니다. 관심사의 분리를 통해 인터페이스만 잘 맞춰놓으면 상대가 어떤 작업을 하는 지 상관 없이 그 부분만 맞추면 된다고 생각했고 실제로 그렇게 진행 중임에도 업무 진도는 나아지지 않았습니다. 그리고 원인을 찾았습니다. 바로 3명 모두 전체를 모르기 때문이었습니다.

 

 제가 했던 모든 프로젝트의 개발 과정을 살펴보면 요구사항을 고객과 끊임 없이 소통하며, 프로젝트 참여 인력 전체가 해당 도메인을 이해하고 Frontend, Backend 개발자들 끼리 서로 다른 기술 분야 이지만 Web 이라는 큰 틀 속에서 이해할 수 있었기 때문에 개발이 잘 되었던 것 입니다. 소스 코드는 인터페이스만 바라보지만 사람은 그 너머를 볼 수 있었기 때문입니다. 그 덕에 인지하지 못하는 동안 커뮤니케이션 비용이 많이 줄어 들었습니다.

 

 그리고 지금 그렇지 않다는 것을 느꼈고 ML Pipeline에 대해 이해 해야겠다는 결론을 내렸습니다. 개발 참여인력 중 누군가는 기술 전체를 아우를 수 있어야 진행이 가능합니다. 그리고 여태 껏 모든 프로젝트 과정 속에 고객 요구사항 이해를 위해 해당 도메인을 공부해야 했습니다. Web 개발자로서 저의 도메인은 지금 AI인 것이라 생각하고 깊은 ML 알고리즘과 하이퍼파라미터 튜닝까지는 안 가더라도 'Data 준비 - 학습 - 추론 - 배포' 한 번읜 Cycle을 돌아보려 합니다. 3월에는 보다 나은 소식이 있었으면 좋겠습니다.

 

 

오, 나의 Python

 

 'Web Backend 개발자, 주 사용 언어는 Python 입니다.' 라고 이야기 한 지 벌써 2년 5개월이 지났습니다. 그럼에도 불구하고 Pythonic 한 것이 정확히 무엇인지? 나는 Pythonic 한 코드를 작성 할 수 있는 zen of Python 에 부합하는 지? 의문입니다. 사실 그간 외도가 잦았습니다. 마음 한 켠에 늘 도사리는 '한국 시장에서 Backend 개발자는 Java 를 해야하는 게 아닐까?' 라는 불안감 과 객체 지향, Clean Code 관련된 대부분의 서적인 죄다 Java 로 짜여져서 진정 Pythonic 한 코드가 무엇인 지 잘 모르겠었습니다.

 

 그런 불안감과 맞물려 회사에서 Frontend 개발자가 없으니 React 공부해서 맡아주면 좋겠다는 제안에 응해서 잠깐 Javascript 세계로 떠났던 적도 있습니다. 그리고 Java / Kotlin Spring 을 기술 스택으로 사용하는 회사로 이직하는 동료들을 보면서 저 또한 그 쪽 공부를 했던 시기도 있습니다. 그리고 지금 저는 이 모든 불안감을 모두 떨쳤습니다.

 

 커리어 자체에 대한 고민 때문에 당장 내가 사용하는 프로그래밍 언어인 Python 에 집중하지 못했습니다. 그리고 그 불안감은 작년 말 즈음이 되어서야 완전히 떨쳐 낼 수 있었습니다. 전에는 엄두도 못 냈을 기능들을 촉박한 기간 동안 슥슥 풀어내고 적용하는 스스로의 모습을 보면서 Python이고 Java고 그게 중요한 게 아니라는 생각이 들었습니다. 그리고 제가 여지껐 써왔던 Python에 대한 전문가가 되고자 합니다.

 

 '전문가를 위한 Python', 'CPython 파헤치기' 이 두 책을 공부하면서, Python 에 대해 깊이가 아주 조금은 깊어지고 있습니다. 저에게는 너무나도 어려운 두 책을 온전히 이해하기 위해 '실습과 그림으로 배우는 리눅스 구조' 라는 책을 또 공부하게 되었고 그 덕에 python code가 어떻게 시스템 콜을 호출 할 수 있는지 이해할 수 있었습니다.

 

 그리고 하나하나 Python 세계에 빠져드는 것이 정말 즐겁습니다. 이 내용은 차근차근 블로그에 포스팅 하려 합니다. 아무렇지 않게 개충 썼던 기술 하나하나 훑어보며 내 것으로 만들어 보려합니다.

 

제게 큰 도움을 주고 있는 책 링크를 첨부합니다. 도움되시길 바랍니다.

http://www.yes24.com/Product/Goods/30231768

전문가를 위한 파이썬 - YES24

http://www.yes24.com/Product/Goods/112893907

CPython 파헤치기 - YES24

http://www.yes24.com/Product/Goods/69660412

실습과 그림으로 배우는 리눅스 구조 - YES24