bennett안녕하세요! 24년 9월에 쏘카 데이터엔지니어링팀에 입사한 베넷입니다.
이번 글에서는 제가 쏘카 데이터 엔지니어링팀에 합류하게 된 계기부터, 입사 후 적응 과정, 그리고 프로젝트를 통해 느낀 점들을 공유하려고 합니다. 제가 몸담은 팀의 매력과 기술적 강점을 소개해 드리겠습니다.
다음과 같은 내용에 관심이 있으신 분들이라면 이 글이 유용한 참고가 되기를 바랍니다.
- 데이터 엔지니어링팀의 업무와 기술 스택에 관심이 있는 분
- 쏘카 데이터 엔지니어링팀의 적응기와 협업 문화를 알고 싶은 분
- Kubernetes, Airflow 등과 같은 도구를 쏘카에서는 어떻게 온보딩하고 활용하는지 궁금한 분
1. 입사 지원 배경
쏘카 데이터 엔지니어링팀에 합류하기 전까지 저는 의료 기기 스타트업에서 데이터 엔지니어로 일했습니다. 데이터의 가시성을 높이고 이를 통해 의사결정을 할 수 있는 환경을 구축하는 데 주력했습니다. 데이터 파이프라인을 설계하고 개발 하면서, 조직이 데이터를 보다 잘 활용할 수 있도록 돕는 일이 주요 업무였습니다. 하지만 아쉽게도 소규모의 데이터를 다뤘고, 의료기기는 제가 사용할 수 있는 서비스가 아니었습니다.
이직을 결정했을 때 가장 중요하게 생각했던 부분은 두 가지였습니다.
- 내가 사용할 수 있는 서비스를 만드는 회사
- 대용량 데이터 엔지니어링을 할 수 있는 회사
쏘카는 제가 차를 빌릴 수 있는 나이부터 계속 사용하던 서비스라 평소에도 관심이 많았습니다. 그리고 현재는 퇴사하신 분들이지만 입사 전, 네이버 부스트 캠프 교육에서 알게 된 카일이나 다른 교육을 통해 알게 된 그랩을 통해 들은 쏘카의 이야기는 상당히 흥미로웠습니다. 비교적 큰 규모의 데이터 조직에서 데이터에 대한 오케스트레이션 하기 위한 고군분투를 들을 기회가 있었기 때문에 데이터 엔지니어로서도 당연히 관심이 있었습니다.
링크드인에서 그랩, 카일을 팔로우하고 있어서 두 분이 공유해 주신 쏘카 채용 및 디너톡 공지를 발견할 수 있었고 감사하게도 참여할 기회를 얻을 수 있었습니다.
당시 나눴던 얘기도 상당히 흥미로웠습니다.
대주제는 AI 시대에 데이터 엔지니어는 어떻게 살아남아야 하는가?였고 많은 대화 주제 중 인상 깊었던 주제는 데이터가 많다는 기준은 무엇일까? 였습니다.
당시 해당 주제를 얘기하던 사람들 끼리의 결론은 데이터에 대해서 어떠한 사고가 발생하여 정합성이 어긋났을 때, 하루 안에 문제를 해결 할 수 있냐 정도로 얘기가 되었고,
쏘카는 해당 기준에 있어 데이터가 많은 곳이라는 결론을 내렸습니다.
이러한 것들 때문에 쏘카가 상당히 매력적으로 느껴졌고 지원을 해서 입사하게 되었습니다.
입사 과정에 대한 자세한 내용은 쏘카 신입 데이터 엔지니어 디니의 4개월 회고 와 크게 다르지 않습니다.
다만 제 경우에는 1차, 2차 모두 쏘카 관련 문제 대해 어떻게 데이터 구조를 설계할 것인가 라는 토론 형식의 면접이 진행되었습니다.
이 과정은 쏘카가 문제를 정의하고 해결하는 방식의 일면을 경험할 수 있는 기회였습니다.
문제를 정의하고, 함께 토론하며 해결책을 모색하는 방식은 상당히 즐겁고 인상 깊었습니다. 이러한 경험들은 제가 입사를 결심하는 데 큰 영향을 미쳤습니다.
2. 온보딩의 과정
합격 메일을 받고 입사를 결정했지만, 솔직히 걱정도 조금 있었습니다. 지원했던 공고에 나열된 기술 스택 중 제가 경험해 본 것은 많지 않았기 때문입니다. AWS와 그 안에서 사용했던 RDS, Redshift 정도가 제가 익숙한 기술의 전부였습니다. Kubernetes나 빅데이터 프레임워크(Spark, Flink 등)는 거의 경험해 보지 못했던 영역이었고, 이런 기술을 실제로 사용하는 팀에서 내가 잘 적응할 수 있을까 하는 불안이 있었습니다.
이런 마음으로 퇴사와 입사를 준비하던 중, 쏘카 팀의 기술 스택이나 현재 상황에 대해 조금이라도 알 수 있다면 도움이 될 것 같아 메일로 여쭤봤습니다. 그리고 다음과 같은 답변을 받았습니다.
이 답변을 받고 나니 걱정이 조금 덜어졌습니다. 그렇게 온보딩 과정에 대한 기대감과 함께 9월 입사를 하게 되었습니다.
2.1 첫걸음 내딛기
쏘카 데이터 엔지니어링팀에 합류한 이후 첫 2주는 개발 환경 세팅과 온보딩에 집중하는 시간이었습니다. 첫날에는 크게 두 가지 온보딩 업무가 있었습니다.
- 회사 차원에서 입사 첫날 해야 하는 일
- 네트워크 설정(회사 와이파이, VPN…)
- 계정 신청 및 등록(SSO, Google, Slack, Notion, AWS, GCP…)
- 개인 정보 등록(급여, 보험…)
- 쏘카 직원 할인 등록 등등
-
팀/그룹 차원에서 입사 첫날 해야 하는 일
이러한 과정들이 문서로 정리되어 있었지만, 개인적으로 익숙하지 않았던 점이 있었습니다. 비밀번호도 단순하고 구두로 공유되는 경우가 많았던 환경에 있다가, 보안과 증적을 남기는 걸 매우 중요하게 생각하는 조직에 오니 답답하게 느껴졌지만, 장기적으로는 이러한 접근과 관리 방식이 옳다고 생각하게 되었습니다.
각 항목의 관리 주체가 명확히 나뉘어 있어, 어떤 시스템에 누가 접근할 수 있는지가 체계적으로 정리되어 있었습니다. 이를 통해 불필요한 접근을 차단하고, 정말 필요한 사람만 권한을 부여받을 수 있는 환경이 조성되어 있었습니다.
2.2 온보딩 과제
온보딩 과제를 처음 받았을 때, 가장 먼저 든 생각은 메일로 받았던 내용이 이거구나, 걱정은 필요 없었네...였습니다. 항상 바로 실무에 던져지는 경우가 많았던 터라, 이렇게 체계적으로 설계된 온보딩 시스템은 새로운 경험이었습니다. 특히나 걱정했던 부분인 Kubernetes와 같은 것들이 포함된 내용이라 상당히 기대되고 반가웠습니다. 온보딩은 다음과 같은 과정으로 이루어져 있습니다.
온보딩 과제는 익숙한 것들도 있었고 처음 접하는 것들도 있었습니다. 작게나마 쏘카에서 데이터 엔지니어가 사용하는 기술 스택을 빠르게 경험 해 볼 좋은 기회 였다고 생각합니다. 과제는 처음에는 어렵게 느껴졌지만, 하나씩 차근차근 공부해 나가니 결국 모두 해결할 수 있었습니다.
특히, 쏘카의 내부 노션 문서가 큰 도움이 되었습니다. 일반적으로는 구글 검색을 해서 문제를 해결했지만, 쏘카의 노션에는 주요 기술과 환경 설정 방법이 양질의 정보로 정리되어 있어 더 효율적으로 문제를 해결할 수 있었습니다.
또한, 팀의 분위기 덕분에 모르는 부분은 주저하지 않고 질문할 수 있었습니다. 이런 환경 덕분에 쏘카에서 주로 사용하는 개발 환경을 간단한 과제를 통해 빠르게 습득할 수 있었습니다. 온보딩 과제를 통해 실무에 필요한 기술을 체계적으로 배울 수 있다는 점은 매우 인상적이었습니다.
3. 업무 시작과 본격적인 적응
온보딩 과제가 끝난 이후, 진행해야 할 여러 프로젝트가 논의 되었습니다. 흥미로웠던 점은 프로젝트 할당 방식이었는데, 각 프로젝트에 대한 세부 내용과 목표를 공유하고 팀원들의 각자 의견을 최대한 반영하여 프로젝트를 결정하는 방식이었습니다. 단순히 지시받는 것이 아니라, 자신이 맡은 일의 배경과 방향성을 이해하고 동료들과 논의하며 결정하는 과정은 업무에 대한 몰입도를 높이고, 책임감을 느낄 수 있는 계기가 되었습니다.
제가 관심을 표현한 프로젝트는 대고객 운전 점수 파이프라인 구축과 서버 로그 적재 방식 개선이었습니다. 데이터 엔지니어로서 대고객 프로젝트와 실시간 데이터 파이프라인 구축에 관심이 많았기 때문입니다. 경험이 없거나 부족한 부분이어서 걱정도됐지만 너무 관심있는 주제여서 담당하고 싶다는 의사를 표현했습니다. 팀원들이 흔쾌히 제 의사를 지지해주셨고 해당 프로젝트들을 맡을 수 있게 되었습니다.
3.1 대고객 운전 점수 파이프라인 구축
운전 점수 데이터 파이프라인
첫 번째로 참여한 프로젝트는 운전 점수 프로젝트였습니다. 해당 프로젝트는 회원의 기존 운행 기록을 통계화해, 이를 바탕으로 운전 점수를 계산하고 회원에게 제공하는 서비스입니다. 이 프로젝트는 단순히 데이터를 처리하는 단계를 넘어, 산출된 결과를 서비스로 연결하는 작업이 주된 목적이었습니다. 데이터 엔지니어로서 처음으로 분석 결과를 서비스까지 내보내는 작업이었기 때문에 기대가 되었고, 동시에 책임감도 느꼈습니다.
그리고 저는 프로젝트 초기에 기술 선택 단계에 참여하지는 못했지만, 미팅 기록을 통해 기술 선택 과정에서 느낀 점이 있었습니다. 기술 선택에 있어 관행에 얽매이지 않고, 현재 상황에서 가장 적합한 기술을 고민하며 결정한 흔적이 보였습니다.
제가 맡은 역할은 산출된 운전 점수를 안정적으로 AWS MSK에 Producing하는 작업이었습니다. 단순히 데이터를 전달하는 것을 넘어, 데이터의 신뢰성과 정합성을 확보하는 것이 핵심 과제였습니다. 이를 위해 프로젝트에 참여한 PM, 마케팅 엔지니어링팀, 데이터 사이언티스트, 그리고 저를 포함한 데이터 엔지니어들이 함께 논의하며 문제를 해결해 나갔습니다.
특히, 운행 데이터를 산출하는 과정에서 일부 소스의 데이터가 누락되거나 지연되어 들어오는 문제가 발생했습니다. 이를 해결하기 위해 데이터의 정합성과 신뢰성을 보장할 수 있는 정책을 수립했고, 데이터 적재 스케줄을 조정하거나 하는 식으로 처리 지연 문제를 완화했습니다.
또한, MSK Consume을 맡아주신 마케팅 엔지니어링팀과는 데이터 포맷과 전달 방식에 대해 긴밀히 논의하며, 데이터의 정합성을 확보하기 위해 노력했습니다. 특히, 데이터 스키마에 변화가 필요할 경우 이를 효율적으로 공유하고 관리하기 위해 Glue Schema를 도입했습니다. 이를 통해 Produce와 Consume 과정에서 일관성을 유지할 수 있었으며, 팀 간 협업이 더욱 원활해질 수 있었습니다.
그리고 데이터 사이언티스트와는 산출된 점수가 통계적으로 적절한지 검토하며, 기술적 구현이 서비스 품질에 미치는 영향을 함께 고민했습니다. 그리고 이러한 정책과 품질에 대한 내용들을 Produce하는 단계에서 코드로 구현하여 검증할 수 있도록 작업했습니다.
이번 프로젝트를 통해 제가 작업한 데이터가 서비스의 한 부분으로 사용자에게 직접 전달된다는 점에서 큰 책임감을 느끼는 동시에 뿌듯함도 컸습니다. 데이터를 정확하고 신뢰성 있게 처리하기 위해 정책을 정의하고 이를 코드로 구현하며 정합성을 확보해 나가는 과정은 쉽지 않았지만, 다양한 팀과 협력하며 문제를 해결해 나가면서 많은 것을 배울 수 있었습니다. 이 경험은 데이터 엔지니어로서 한 단계 성장할 수 있는 소중한 기회가 되었던 것 같습니다.
그리고 25년 1월 중순에 제가 참여했던 프로젝트인 운전점수가 서비스로 배포되었습니다.
3.2 서버 로그 적재 방식 개선
두 번째로 참여한 프로젝트는 서버 로그 적재 방식을 개선하는 작업이었습니다. 당시 서버 로그 적재 프로세스가 부재했고, 구조가 비교적 복잡하여 데이터 품질과 운영 효율성, 비용 측면에서 여러 가지 문제가 발생하고 있었습니다.
제가 맡은 작업은 AWS KDS의 Consumer를 개발하고 인프라를 설정하는 것이었습니다. Consumer는 Kubernetes 위에서 구동되는 서비스로 설계되었으며, 이 과정에서 Helm 차트를 작성해 배포 환경을 구성하고 적용하는 경험을 할 수 있었습니다. 온보딩 과제에서 경험했던 Kubernetes와 Helm 관련 지식을 거의 바로 실제 프로젝트에 적용할 수 있었습니다. 이러한 부분은 작업을 할당받을때 배려받았다는 생각이 들었습니다.
이 프로젝트는 실시간 데이터 파이프라인을 직접 만들어보는 첫 경험이라는 점에서 특히 의미가 있었습니다. 기존의 레거시 시스템을 유지하면서도 새로운 구조로 전환하는 과정에서 데이터를 안정적으로 처리하기 위해 기존과 새로운 방식의 병행 운영을 설계하고, 데이터의 정합성을 지속해서 확인하는 방법을 논의하며 작업을 진행했습니다.
그리고 이 과정에서 자연스럽게 KDS와 AWS MSK 두 서비스의 차이를 알 수 있었습니다. MSK는 offset을 자동 관리해 Consumer가 데이터를 읽은 위치를 신경 쓰지 않아도 되는 반면, KDS는 sequence number를 직접 관리해야 했습니다. 또 MSK는 파티션의 수를 줄일 수 없는 제약이 있는 반면, KDS는 샤드의 수를 동적으로 조정할 수 있어 리소스 관리 측면에서 더 유연했습니다. 이러한 차이를 실제 환경에서 체감하며, 각 기술의 특성에 맞는 설계와 활용 방식을 고민할 수 있었습니다.
3.3 온콜 엔지니어
마지막으로, 입사한 지 한 달이 조금 넘은 시점에 온콜 엔지니어 역할을 맡게 되었습니다. 데이터 엔지니어링팀은 주에 한 명씩 돌아가면서 온콜 엔지니어를 맡아, 팀에서 발생하는 다양한 요청과 장애에 신속히 대응하며 시스템의 안정성을 유지하는 역할을 합니다. 온콜 엔지니어는 Opsgenie를 통해 스케쥴이 관리되고 알람이 옵니다.
온콜 엔지니어의 주요 업무는 사진과 같은 Ad-hoc 요청 처리와 긴급 장애 대응입니다. 슬랙 알림 채널에서 발생하는 에러를 가장 먼저 확인하고, 데이터 적재나 재적재 요청, GCP 권한 부여, Airflow 및 인프라 관련 에러 처리 등 다양한 작업을 수행합니다.
아직 모르는 게 많은 상황에서 온콜 엔지니어를 하게 되어 걱정이 많았습니다. 특히, 온콜 업무는 예상치 못한 문제가 발생하기 때문에 신속히 상황을 파악하고 해결해야 한다는 점에서 부담감이 컸습니다. 온콜 업무를 처리함하는 데 당연히 모르는 부분이 많이 있었습니다. 그러나 이 과정에서 팀원들에게 많은 도움을 받았고 수월하게 문제를 해결할 수 있었습니다.
이 과정에서 쏘카 데이터 엔지니어링팀은 질문하는 것이 두렵지 않은 팀이라는 생각이 들었습니다. 단순히 답을 주는 것에 그치지 않고, 문제를 해결하는 과정에서 필요한 배경지식과 맥락을 함께 설명해 주는 팀원들 덕분에 혼자였으면 해결하기 어려웠을 문제들도 차근차근 풀어갈 수 있었습니다. 이러한 지원과 협업 덕분에 온콜 업무 중 느꼈던 부담감을 줄이고 점차 역할에 적응할 수 있었습니다.
온콜 엔지니어업무 중 가장 어려웠던 점은 컨텍스트 스위칭이 자주 발생한다는 점이었습니다. 데이터 적재 요청, 에러 처리, 권한 부여 등 다양한 작업이 동시에 발생하다 보니, 빠르게 상황을 전환하며 대응해야 했습니다.
하지만 이러한 경험은 팀의 업무 흐름을 전체적으로 이해하는 데 큰 도움이 되었습니다. 온콜 업무를 통해 데이터 파이프라인과 인프라 구조를 더 이해할 수 있었으며, 어떠한 기능과 서비스가 있는지 폭넓게 파악할 수 있었습니다.
4. 마치며
4.1 회고
쏘카 데이터 엔지니어링팀에 합류한 지 3개월이라는 짧은 시간이었지만, 정말 밀도 높은 경험을 할 수 있었습니다. 성장에 대한 기대를 품고 합류한 쏘카에서, 짧은 시간 동안 다양한 프로젝트와 온콜 경험을 통해 기술적으로나 개인적으로 크게 성장했다고 느낍니다.
체계적인 온보딩 시스템과 팀 내 지식 공유 문화는 쏘카와 데이터 엔지니어링팀의 큰 강점이라고 느꼈습니다. 온보딩 과정에서 제공된 문서들은 업무 적응 속도를 높여 주었고, 프로젝트 진행 중에도 기록과 공유 덕분에 팀원들과 더 효과적으로 협력할 수 있었습니다.
이번 3개월은 단순히 기술을 배우는 데 그치지 않고, 문제를 해결하며 팀의 일부로 자리 잡아가는 경험이었습니다.
4.2 앞으로의 목표
지난 3개월 동안 가파른 러닝 커브를 경험하며 많은 것을 배웠습니다. 이 속도와 각도 유지하며 성장하고 싶습니다.
물론, 이미 잘 갖춰진 인프라 환경에서 내가 얼마나 임팩트 있는 일을 할 수 있을까 고민도 있었습니다. 그러나 현재 쏘카에는 시스템이 점차 커지면서 해결하기에 복잡한 문제들이 있는 것 같습니다. 이러한 문제들을 하나씩 해결하며, 시스템을 더 안정적이고 효율적으로 만드는 데 기여하고 싶습니다.
쏘카의 데이터 엔지니어링팀은 데이터가 서비스로 이어지며 사용자에게 가치를 전달하는 과정을 직접 경험할 수 있는 팀입니다. 앞으로도 새로운 도전을 마주하고, 이를 해결하며 개인적으로도, 팀의 일원으로서도 지속해서 성장해 나가려고 합니다.
4.3 Special Thanks to
즐거운 환경에서 성장할 수 있도록 도와주신 데이터 비즈니스 본부, 데이터 프로덕트 그룹, 데이터 엔지니어링 팀의 모든 분들께 감사드립니다!
