1년차 Data Engineer의 회고

머릿말

안녕하세요? JustKode, 박민재 입니다. 이 글을 쓰는 지금, Data Engineer로 LINE Plus에 입사한지 벌써 만으로 1년이 다 되어 가네요. 올해 1월에 입사 했으니까요.

첫 사회 생활, 첫 회사에서 (첫 인턴, 첫 회사가 LINE Plus 입니다.) 많은 것들을 경험 했어요. 학생 때 한 개발은 한편으로는 기술적인 자아 실현을 위한 개발이었다면, 개발자로서 하는 개발은 고려해야 할 것들이 많이 다르니까요. 학생 때와는 확실하게 다른 시야에서 개발이라는 것을 바라 볼 수 있었습니다. 그런 의미에서 개발자로 첫 해를 보낸 2023년이 끝나가는 지금, 내가 S/W Engineer로 어떠한 삶을 살아 왔는지 정리할 필요가 있다고 생각 했습니다. 그래서 이번 글에서는 내가 무엇을 했는지, 어떤 것들이 좋았는지, 어떤 것들이 아쉬웠는지, 어떤 것들을 고칠 수 있는지를 KPT 회고 방식에 맞추어 써보려고 합니다.

FYI) Keep (잘한 것), Problem (아쉬운 것), Try (시도할 것)를 바탕으로 회고 하는 방법을 KPT 회고 라고 합니다.

이번에 쓴 글은 저의 감정을 그대로 녹여 냈기 때문에, 상당히 러프한 글이 될 것 같아요. 독자 분들의 양해 부탁드립니다.

무슨 일을 하셨나요?

저는 LINE이라는 프로덕트 내에 송출 되는 수 많은 광고 시스템의 데이터를 모아서 관리 해 주는 팀에서 업무를 수행 하게 되었습니다. 저희 팀 소개 Youtube 링크는 다음과 같아요. 저는 이 팀에서 Batch Data Pipeline 파트에서 개발을 수행 하게 되었습니다. 하루에 800억 건 정도의 데이터가 쏟아지는 Hadoop 기반의 환경에서 다음과 같은 업무들을 수행 했어요.

Hadoop의 I/O Performance을 높이기 위한, HDFS Block 관리, File Retention 적용 등의 Data Management 업무
- HDFS Block Merge, Spark Streaming, File Retention Job
Ad Performance Report Aggregation 개발 업무
- Spark 기반으로 DSP, SSP Report 개발 및 최적화
Kubernetes 기반의 Multitenancy를 지원 하는 Airflow 클러스터 개발 지원
- KubernetesPodOperator의 내부 로직을 수정 한 CustomOperator 개발 등
Batch Data Pipeline의 Monitroing System 개발 업무
- Spark Job Monitoring in Prometheus, Airflow Monitoring
데이터의 품질을 보장 하기 위한, Data Quality Verification 관련 PoC 진행
- Amazon Deequ, Great Expectations

이 외에도 자잘한 업무들이 있었지만, 크게 저 5가지를 꼽을 수 있을 것 같아요. 해당 업무들을 수행 하면서 업무적으로, 기술적으로, 그리고 내가 느낀 감정적으로 가감 없이 글을 써 내려 감으로써, 그 다음 스텝을 밟을 수 있도록 준비 하려고 합니다. 저희 파트는 저 제외 하고 저랑 10살 이상씩 차이나는 시니어 개발자 분들이었습니다. 그러다 보니, 다른 분들에게 폐를 끼치지 않기 위해, 입사 초반에는 엄청 열심히 공부했고, 옆에서 다른 분들이 회의 때 어떤 식으로 의견을 전달 하고 나누는지, 어떤 식으로 요구 사항들을 수행 하고, 어떤 기준으로 판단하고 Action하는 지를 어깨 너머로 많이 배울 수 있었어요. 그 덕분에 옆에서 많은 것을 배워 나갈 수 있었던 것 같아요.

우리 파트 요악.jpg

Need to Keep (잘한 것)

Code Review

회사에서 진행하는 팀 내 동료 평가에서도 저에 대한 칭찬으로 나왔던 부분이었습니다. 저는 다른 사람의 코드를 리뷰 할 때, 다른 사람이 짠 코드의 프로젝트 내 히스토리와 컨텍스트를 파악하고 코드 리뷰를 진행 하려고 노력 했어요. 그래서, 사람들이 놓치는 부분이나, 기술적으로 더 좋은 방안의 리뷰를 드릴 수 있었습니다. 또한, 코드 디자인 패턴 관련 부분에서도 파트원들과 서로 건설적인 논의를 하며 업무를 수행 했어요.

이에 도움이 되었던 것이 우리 파트 사람들 끼리 주기적인 회의를 통해서 각자 어떤 개발을 수행 하고 있는지 인식을 맞춰 간 부분이 매우 크게 작용 했다고 생각해요. 이는 우리 파트원 분들 모두가 힘을 합쳐 가능했던 부분이라고 생각합니다. 당연히 저희 팀원 분들도 컨텍스트가 잘 공유 되어 있는 덕에, 제 코드도 꼼꼼하게 리뷰 해 주셨습니다. 추후, 다른 팀 혹은 다른 곳에서 일을 하더라도 이런 문화가 정착 될 수 있도록 하는게 중요 하다고 생각이 들어요. Scrum 같은 문화가 대표적인 예시이겠죠?

앞으로도 좋은 코드 리뷰를 위해, 서로가 무엇을 하고 있는지 인지하고, 서로의 상황을 이해하고, 기술적인 혹은 관리의 측면에서 처한 상황에 맞게 더 좋은 미래를 생각 할 수 있도록 계속 정진해 나가는 것이 좋을 것 같아요. 이를 위해 좋은 코드 품질에 대한 공부, 클린 코드, 디자인 패턴 등의 공부 또한 끊임 없이 해 나갈 예정입니다.

스파게티 코드는 더 이상 Never.

Engineering

기술적인 탐구를 바탕으로 이를 프로덕트에 적용 하는 것, 제목 그대로 엔지니어링에 대해서도 좋은 평가를 받았습니다. 하루에 PB 단위의 데이터를 다양한 환경에서 처리 하다 보니, 개발 비용, 컴퓨팅 비용에 대한 문제가 만만치 않았는데요, 이를 위해서 많은 기술적인 탐구를 수행 했습니다.

특히 Apache Spark 기반의 Distributed-Computing System에 대한 탐구를 주로 수행 했습니다. Spark SQL API를 통해, DataFrame 연산을 수행 할 때, 내부적으로는 어떤 로직으로 연산이 수행 되며, 이 로직에서 발생하는 Shuffle, Spill과 같은 큰 연산을 최소화 하기 위해서, 어떻게 쿼리를 튜닝 해야 하는지 등을 연구 했습니다. OLAP 플랫폼의 신규 Cluster로의 Migration을 위해 3년 치의 데이터를 재처리 해야 하는 요구사항이 있었는데요, 이 요구사항 덕분에 어쩌다 보니 많이 공부 하게 될 수 있었어요. 사실 전 아직은 모자랍니다. 분산 컴퓨팅 환경에서 Batch Data등은 처리 해 보았지만, 아직 Spark Structured Streaming 과 같은 Mini-Batch Data들을 처리 해 본 경험이 전무 하거든요. 그렇기 때문에 내년에는 Spark Structured Streaming에 도전 해 보고 싶습니다. 또한, 기존 Spark 2.x 버전 환경에서 수행 하던 Report Job들을 Spark 3.x 버전으로 Migration을 수행하여, AQE (Adaptive Query Execution) 와 같은 Runtime 최적화 기능을 적용 해 보고 싶어요.

Continuous Learning

제 스스로 잘했다고 생각 했던 것은 끊임 없는 학습이었습니다. Spark, Airflow, Kubernetes Python Client, Amazon Deequ, Great Expectation 등의 다양한 기술들을 사용 해 보았어요. 사용 중 동작 원리에 대해 궁금 하다면 GitHub에 올라와 있는 Repository 내의 Source Code를 뒤져서 동작 원리를 파악하는 등, Data Engineering에서 주로 사용 하는 Open Source에 대한 Deep Dive 또한 놓치지 않으려고 노력 했습니다. 그 덕에 Kubernetes 기반의 Multitenancy를 지원 하는 Airflow 클러스터 개발 지원 업무를 수행 함에 있어서도 큰 도움이 되었고, Amazon Deequ, Great Expectation 등의 Data Quality 툴의 적용을 통해, 다른 컴포넌트에서 데이터를 신뢰 할 수 있도록 PoC를 수행 하는 데도 도움이 되었습니다.

방금 위에서 이야기 한 Data Quality Tool 적용 후, 추후 DataHub 같은 Data Discovery Tool과의 연동을 통해, 데이터 오염 발생 시 다른 컴포넌트와의 빠른 초동 대응 까지 이어 질 수 있을 것 같아요. 다음 년도에는 Helm, Iceberg 안해본 것들에 대해서도 끊임 없이 학습하고, 회사 합병에 따른 요구 사항의 끊임 없는 변화를 대비 하기 위해서, 클린 코드, 디자인 패턴 등의 공부 또한 해나가야 겠어요.

Problems (아쉬웠던 것)

Communication

분명, 입사 면접 시에는 커뮤니케이션이 강점이라고 어필을 했던 것 같은데. 놀랍게도 제가 이번 년도에 직장을 다니면서 느꼈던 저의 단점은 커뮤니케이션이었습니다. 물론 빠른 대응, 빠른 조치에 대해서는 칭찬을 받았습니다. 하지만, 업무가 처음이어서 그랬는지, 정확한 의사 전달에 있어 어려움을 겪었습니다. 이는 여러 가지 요인이 있을 것으로 판단 되는데요, 업무 미숙이 원인 일 수도 있고, 자신감이 없어서 일 수도 있고 (같이 일하시는 분들이 저와 기본 10살 차이 이상의 시니어 개발자 분들이라서...), 혹은 상황 판단의 부족 또한 이유가 될 수 있겠군요. 글쎄요, 학생 때는 저 스스로, 왜 커뮤니케이션을 강점으로 뽑았는지 생각 해 보면, 남들 보다 더 많은 경험, 자신감을 꼽았던 것 같아요. 팀원들의 상황에 대한 판단을 기반으로 항상 의사 결정을 수행 해 왔고요. 결론적으로 다른 사람들보다 부족한 경험이 문제였던 것으로 귀결 될 수 있겠네요.

또, 말을 너무 장황하게 한다는 것이 단점이에요. 사실 다른 사람들이 필요로 하는 말은 그 중의 일부 였을 텐데 말이에요. 남들에게 상황 설명과 동시에 결정 한 사항에 대해 구분 없이 섞어서 전달 하는 것이 문제였습니다. 전달하는 말이 구조화가 되어 있지 않은 채로 남이 편한 의사소통이 아닌, 그냥 생각 난 대로 말하는 내가 편한 의사소통을 하고 있더라고요. (이는 뭔가 제 글에서도 나타나는 특성인 것 같아요.) 많은 것을 빠르게 전달 하려는 욕심 때문에 트랜잭션 없이 말을 전송(?) 하는 문제가 있었네요. 직업병이야 이것도.

그냥 개발자 ver 박찬호였습니다.

Decision

또 다른 문제는 저의 의사 결정 과정 이었습니다. 이 또한, 경험 부족이 원인으로 추정 되긴 하지만, 위 문단에서 이야기 했던 것과 비슷하게, 생각의 구조화가 이뤄지지 않았기 때문에, 나중에는 "내가 왜 이것을 선택 했더라?", "이것을 무슨 목적으로 하고 있었지?" 와 같은 질문부터 다시 하고 있는 경우가 많았습니다. 제 머리 속에서도, 새로운 의견을 전개 하는 것에만 집중하고, 생각을 정리 하는 것을 소홀히 하는 경우가 꽤나 많았습니다. 만약 이런 질문에 답을 못한 채로 회의에 들어 갔다면, 당연하게도 남을 설득하지 못하거나, 의도와 다르게 내용을 전달하여 혼돈을 주겠죠. 어찌어찌 의견이 전달은 되긴 하는 경우가 많았지만, 중간에서 제 의견을 정리해서 다시 한 번 이야기 해 주는 분들이 있었기 때문에 가능 했어요. 이런 점에서 회의의 맥을 끊어 버린 것이 몇 번씩 있던 것 같아, 파트원 분들에게도 좀 미안한 적도 많았습니다.

Lack of Critical Thinking

제 개인적으로 판단한 저는 비판적 사고가 부족 했던 것도 문제 였습니다. 아니, 비판적 사고가 부족 하기 보단, 누군가에게 싫은 소리를 하는 것을 무서워 했을 지 모르겠습니다. (남의 코드에도 공감을 해버리는 ENFJ 개발자 입니다.) 사실 적절한 비판은, 팀을 건설적인 길로 가기 위한 길인데 말이에요. 의견을 물어보면 내가 한켠으로는 시원 찮은 경우에도, "네! 좋아요"를 쉽게 해버리는 사람이 되어 있었습니다.

또한, 잘 보이겠다는 욕심 때문에, 나의 무지를 드러 내는 것에 대한 두려움도 한 켠에 있었을 수도 있습니다. 특정 코드나 아키텍처가 잘못 됐다고 생각 했는데, 알고 보니 내가 낸 의견이 완벽하게 틀린 내용 이라면 너무 부끄럽잖아요? 그 이유인지, 질문을 초반기에 너무 안해서, 리드님이 걱정까지 했다는 후일담이 있었습니다. 사실 나의 무지를 드러내야 새롭게 배우는 것도 많을 것인데요.

내 코드, 우리 새끼. (출처: 데브경수)

이렇게라도 하지 그랬어. (출처: 데브경수)

Try (해 보아야 할 것)

Take a little time

저에게 필요한 것은 급한 마음, 잘 보이려는 마음 보다는 차분함과 숨을 고르는 습관이 필요 하지 않을까 싶습니다. 의사 소통이던, 의사 결정이던, 제가 이러한 부분들에서 문제들을 겪었던 분명 한 이유는 머리 속에서 생각 나는 대로 바로 판단하고 행동한 것이 문제였거든요. 빠른 행동이 필요 할 때도 있지만, 내가 하는 판단으로 팀의 업무 방향성이 달라지는 문제라면 빠른 판단의 중요성 보단, 신중한 판단의 중요성이 더 높을 것입니다. 많은 것들을 경험 하면서, 어떤 상황에서는 빠른 판단이 중요한지, 어떤 상황에서는 신중한 판단이 더 중요한지 생각 하고, 신중한 판단이 더 중요 하다면 천천히 대답을 하거나, 판단을 유보 하는 등, 판단을 위한 판단을 잘 하는 것이 내년의 Action Item으로 결정 한 내용 입니다.

Back to Basic

제가 비판적으로 의견을 제시 하지 못한 이유, 의사 결정이 아쉬운 이유는 기초가 부족한 이유가 있을 것 같습니다. 이는 CS적인 지식 보다는, 아마 Data Engineering에서 사용 하는 Open Source의 사용 경험이 적은 것이 이유가 될 것 같아요. 여러 가지 Case를 경험 하지 못한 것 때문에, 국소적으로 제가 모자란 것들을 파악을 못하거나, 이를 몰라서 잘못 판단하는 경우인 거죠. 더 쉽게 갈 수 있는 방향이 있는데, Open Source 내의 특정 Feature를 모르는 이유로 꾸역꾸역 다른 Feature를 이용 해서, 빡구현을 한다던지 말이에요. 아마 이건 제가 Document를 꼼꼼히 보는 성향 보다는, '일단 해보자!' 하고 행동에 옮기는 경우가 훨씬 많음이 이유라고 생각 합니다. 기존에 사용 중인 Open Source의 Basic Concepts부터 다시 꼼꼼히 공부해서, 돌아가는 판단을 하지 않도록 하는 것, 다시 기초로 돌아가는 것이 내년의 두 번째 Action Item입니다.

Stay Hungry

제 장점을 더 정진하기 위해서, 또는 비판적인 사고를 기르기 위해서 저에게 중요 한 것은, 더 좋은 최선을 찾을 수 있도록 항상 배고파 하는 것 입니다. 저는 제가 항상 더 좋은 것을 갈망하는 성격이라고 생각 했는데요, 올해 취업을 하면서 의욕이 살짝 빠졌는지 예전 만큼은 아닌 것 같습니다. 사수 한 분의 팀 이동, 회사 합병 관련 업무 대비, 이제는 없는 1년차 딱지(?) 등 내년은 올해와는 또 다른 마음 가짐으로 시작 해야 하지 않을까 싶어요. 1년 차에 비해서 더 많은 책임도 저한테 주어질 예정이고요. 더 나은 제가 될 수 있도록, 기술적으로든, 기술 외적으로든 개발자 혹은 사람으로 성장하기 위해 계속 배고파 하는 마음 가짐으로 내년을 맞이 하는 것, 이것이 저의 세 번째 Action Item 입니다.

마치며

개인적으로 괄목 할 만한 무언가를 이룬 한 해는 아니었어요. 그 점에서는 아쉽지만, 사회인이 된 첫 해에, 어떤 방향으로 내가 걸어야 하는지, 어떤 보법으로 걸어야 하는지를 깨달은 한 해 였습니다. 리드님이랑 회식 후 지하철을 같이 타면서 나누었던 이야기가 생각나네요.

개발자로든, 개인의 삶으로든 20대에 생각을 많이 해보는게 좋다. 추후에는 관성에 몸을 맡기기 때문에, 어떤 삶을 살지 지금 생각 하는게 제일 좋다.

지금은 힘을 키우는 것보단, 방향을 잡는 것이 더 중요한 시기라고 생각해요. 후회 하지 않을 정도로 많은 경험을 해보면서, 좋은 방향을 찾고 꾸준히 걸어가는 것을 올해 이후의 목표로 잡으려고 합니다.

그래도 나름 올해 팀원 분들에게 좋은 평가를 받아, 제가 일하는 광고 조직 내의 동료상도 받게 되었어요. 더 열심히 하라는 뜻으로 생각하고, 내년에는 지금보다 조금 더 헌신적으로 좋음을 퍼트리며 일하는 제가 되고자 합니다. 저는 아직 까지는 좋음은 전염된다고 믿거든요. 이제 곧 크리스마스와 새해 입니다. 행복한 연말 보내세요!

긴 글 읽어 주신 모든 분들에게 감사드립니다 :)