<div id="readability-page-1" class="page"><div><h2 id="7042">STEP 1. 문화에 적응하기 🏢</h2><p id="4f73">입사 초기 온보딩 기간에는 의도적으로 주변을 둘러보며 구성원들이 어떻게 의사소통하고 일하는지 관찰했었습니다.</p><figure></figure><p id="5f2e">개인적으로 새로운 조직에 합류하고 가장 중요한 것은 그 조직의 문화를 이해하고 녹아드는 것으로 생각하기 때문입니다. “엔지니어로서 나의 역량을 바로 보여주겠어!”라는 거창한 목표도 좋겠지만, 그에 앞서 내가 앞으로 일한 조직에 대한 이해와 관심이 더 효율적인 결과를 가져온다고 생각하기 때문입니다.</p><p id="2364">오픈 커뮤니케이션을 지향하는 조직이라 슬랙에서 주고받는 대화와 작성된 위키 문서들을 보면서 어떻게 일을 하는 조직인지를 엿보았습니다.</p><h2 id="5679">문서화</h2><p id="bacc">입사 초기에 팀에서 작성한 다양한 문서를 보면서 놀랐던 기억이 납니다. 프로젝트 문서뿐만 아니라, 작업 내용과 코딩 및 쿼리 가이드처럼 다양한 카테고리의 문서가 존재했습니다. 이렇게 작성된 문서를 틈틈이 읽으면서 기존 히스토리와 업무 맥락을 파악했습니다. 초반에 문서를 읽고 위치를 잘 익혀두면 추후 업무를 함에도 큰 도움이 됩니다.</p><h2 id="a045">공유 및 스터디 문화</h2><p id="ad47">“개인의 역량 성장에도 관심이 있는 팀이구나!”라고 생각을 하게 된 건 매주 진행하는 스터디 시간이었습니다. 팀에서 필요한 기술 혹은 커리어와같이 다양한 주제로 진행되는 스터디 시간을 통해서 팀원들과 의견을 나누고 함께 성장할 수 있는 시간이 있다는 것이 좋았습니다. 특히 신규 입사자로서 조금 더 편한 분위기에서 팀원들과 대화할 수 있어서 더 좋았던 시간이었습니다. 또한 이런 정해진 스터디 시간 외에도 각자 알게 된 사실들을 적극적으로 팀 채널에 공유하고 토론하는 분위기여서 의욕도 생기고, 문화에 같이 기여하고 싶다는 생각이 자연스럽게 들게 되었습니다. 그래서 초반에는 의도적으로 Airflow 신규 기능이나, 평소 즐겨보던 개발 관련 유튜브들을 팀 채널에 공유했었습니다.</p><h2 id="640a">STEP 2. 기술에 적응하기 🛠️</h2><p id="0150">데이터 엔지니어를 하면서 개인적으로 생각하는 장점이자 어려운 점은 하는 일의 <strong>scale</strong>이 넓다는 점입니다.</p><p id="1ab2">Kubernetes와 같은 인프라 및 클라우드부터 데이터 파이프라인, CI/CD 그리고 데이터 퀄리티까지 좋은 데이터를 전달하기 위해서는 데이터 엔지니어가 관여할 부분이 넓습니다. 데이터 파이프라인의 A부터 Z까지를 다루는 것은 매력적이지만, 신규 입사자(특히 주니어🐥)로서는 그만큼 적응해야 할 기술이 많다는 것을 의미합니다.</p><figure><figcaption>출처(<a href="https://www.kvratech.com/dataengineering.php" rel="noopener ugc nofollow" target="_blank">https://www.kvratech.com/dataengineering.php</a>)</figcaption></figure><p id="32c7">기존에 AWS 기반의 데이터 파이프라인을 운영한 경험이 있었지만, 29CM 데이터 파이프라인은 GCP 기반이라 우려되는 부분도 있었던 것 같습니다. 마음 한편에 “내가 가진 능력과 경험보다 부족한 부분이 더 보이면 어떡하지”라는 생각이 있었습니다. 그래서 저는 다음과 같이 접근해 나가보았습니다.</p><h2 id="16e4">숲에서 나무로🌳</h2><p id="c874">엔지니어로서 업무를 처리 함에 있어 기술과 도구에 대한 깊은 이해는 매우 중요합니다. 하지만, 아키텍처 혹은 기술을 선택한 맥락과 같이 큰 그림을 파악하는 것이 우선시 되어야 한다고 생각했습니다.</p><p id="40dc">입사 초반에는 먼저 기존 운영 업무가 주어졌습니다. 이 기간에는 해당 업무들을 수행하며 전반적인 파이프라인과 팀의 코드 스타일, 디자인 패턴과 같이 큰 그림 위주로 파악하려고 했었습니다. 팀에서 쓰고 있는 기술들은 무엇이 있고, 해당 기술을 왜 선택했는지와 더불어 DAG를 어떻게 작성하는지와 같은 것들도 파악해 보고 팀원들에게 질문해 나갔습니다. 이렇게 이해한 내용을 정리하는 것이 온보딩 미션 중 하나였기 때문에 다음과 같이 정리해 나가면서 전반적인 파이프라인의 구성을 파악하였습니다.</p></div><div><p id="0286">이후 실제 프로젝트 투입 때는 해당 프로젝트의 핵심 기술을 위주로 파악해 나갔습니다.</p><p id="9d56">예를 들어, 데이터 품질을 위한 이상 탐지 파이프라인을 구축하는 프로젝트에서 필수적이지만 이전에 사용 해본 경험이 없었던 Spark를 중점적으로 파악하려고 노력했습니다. 기본적인 지식을 위해서 책을 참고하고 기존에 작성된 코드를 보고 분석하며 공부했습니다.</p><p id="db1e"><em>(이때 읽었던 책은 “러닝 스파크”와 “파이썬을 활용한 스파크 프로그래밍” 이었습니다.)</em></p><h2 id="de8c">질문 하기🥕</h2><p id="6722">질문은 업무 파악에 있어서 가장 중요하고 효율적인 수단입니다. 팀이 왜 그러한 기술을 선택했는지 왜 이렇게 코드를 작성했는지 맥락을 파악할 수 있기 때문입니다.</p><p id="fd4a">하지만 상대가 “왜 이 정도의 질문을 하지?”라는 생각을 하지 않을까 혹은 내 실력에 대한 밑천이 드러날까 두려워 질문하지 않는 경우도 있습니다. 저 역시 신입 엔지니어로 입사 후 비슷한 고민을 하며 혼자 끙끙 앓던 경험을 해보았기 때문입니다. 경험적으로 고민에 깊이 없이 단순히 검색할 수 있는 부분을 질문하는 것이 아니라면, 신규 입사자의 질문에 방어적으로 대답하는 분들은 매우 소수일 것으로 생각합니다. 더해서 적응해 나가는 초반의 기간이 가장 질문하기 편한 시기기도 합니다. 모르는데 알고 있는 ‘척’을 하고 나중에 그 문제에 직면해서 해결해야 할 때는 오히려 더 질문하기 어려운 시점이 되니깐요.</p><p id="7f25">그래서 코드를 파악하거나 문서를 읽고 궁금한 점이 생기면 팀원들에게 자유롭게 여쭤보았습니다. 또 업무를 진행하면서 막히는 부분에서도 “2시간 이상 해결되지 않는다면 질문하기”라는 기준을 세워서 그 이상 해결되지 않으면 당근🥕을 흔들며 도움을 요청하기도 했었습니다.</p><figure><figcaption>도움 요청에 항상 열띤 답변 주시는 팀원들💪🏻</figcaption></figure><h2 id="8d7f">STEP 3. 기여하기 🚀</h2><p id="9c4c">문화와 기술에 어느 정도 적응이 되었다면, 이제는 한 명의 구성원으로서 기여를 할 때입니다. 기여라는 단어가 거창해 보이지만, 생각보다 작은 것들로 기여할 수 있다고 생각합니다.</p><p id="2641">그중에 신규 입사자만이 가질 수 있는 무기 중의 하나는 <strong>새로운 시각</strong>이라고 생각합니다. 기존 시스템에 익숙해진 구성원에 비해서 다른 경험과 시야를 가진 신규 입사자는 새로운 아이디어를 낼 가능성이 높습니다. 저는 연차와 관계 없이 신입이나 주니어도 가장 쉽게 기여할 수 있는 부분이 바로 이 점이라고 생각했습니다.</p><h2 id="64c7">기존 프로세스 개선</h2><p id="290e">코드를 분석하거나 업무를 진행하면서 “왜?”라는 생각이 드는 부분이 생기기 마련입니다. 이전 맥락을 모르기 때문일 수도 있고, 더 좋은 방법이 있는 걸 알고 있기 때문일 수도 있습니다. 개선은 이런 질문에서 출발 합니다. 질문을 통해서 의문이 단순히 해결될 수도 있지만, 알고 보면 기존 구성원들에게는 익숙해져서 생각하지 못한 점일 수도 있습니다.</p><p id="8884">팀에서 Kubernetes를 사용 중인데요, 온보딩 과정에서 별도로 사용 중인 UI가 없다는 것을 알게 되었습니다. 이전에 Lens를 통해서 편리하게 관리 및 모니터링 했던 경험이 생각나서 이 부분을 팀에 제안하고 Deep Dive라는 시간에 공유하여 팀 도구로 채택한 일이 있었습니다.</p><figure></figure><p id="6590"><strong>Deep Dive</strong>는 데이터 플랫폼 팀의 문화 중 하나인데요, 본인이 자유롭게 딥다이브(공부) 한 내용 중에 팀에게 공유하고 싶은 것이 있다면 문서를 작성하고 시간을 잡아 공유하는 문화입니다.</p><figure></figure><h2 id="7f70">오래된 문서 업데이트, 새로운 문서 작성</h2><p id="56fb">감사하게도 데이터 플랫폼팀이 기본적으로 문서화를 중요하기 생각하기 때문에 다양한 문서가 있어서 온보딩 과정에서 도움이 많이 되었습니다. 하지만 문서 중에는 오래되어서 현재의 시스템과 다소 상이한 부분도 있었고, 신규 입사자 입장에서는 절차가 생략되어서 이해가 어려운 문서도 존재했습니다. 이런 부분을 온보딩 과정에서 말씀드리고 필요 시에는 직접 수정도 하면서 팀에 기여하려고 노력했었습니다.</p><p id="0fb8">온보딩 미션 중의 하나로 현재 팀의 문서에 대한 전반적인 피드백이 있었습니다. 이때 온보딩 과정에서 느낀 팀의 문서에서 좋았던 점(Keep), 부족한 부분(Problem) 그리고 시도할 부분(Try)으로 나누어 공유하는 시간을 가졌습니다.</p><figure></figure><p id="b35a">이러한 의견이 반영되어 팀 문서의 전반적인 체계화로 변화가 이루어졌습니다.</p><figure><figcaption>데이터 플랫폼팀 노션 엿보기👀</figcaption></figure><h2 id="55d0">마치며</h2><p id="6d42">여기까지, 제가 팀에 합류하고 적응하면서 취했던 저만의 전략이었습니다.<br>당연한 것들이지만 그걸 생각하고 실천하는 게 가장 어려운 것이 아닐까 싶습니다. 곧 입사를 앞둔 분들에게 조금이나마 도움이 되는 글이었으면 좋겠습니다.<br>마지막으로 온보딩 과정부터 지금까지 많은 도움을 주시는 데이터 플랫폼 팀원분들에게 가장 감사하다고 말씀드리고 싶습니다! 감사합니다.</p><p id="495d"><strong>[함께 성장할 동료를 찾습니다]</strong></p><p id="a34e">29CM (무신사) 는 3년 연속 거래액 2배의 성장을 이루었습니다.<br>다양한 소스 데이터에서 안전하고 빠르게 수집, 처리, 저장, 제공하도록 파이프라인을 개발하고 운영하며, 제공된 데이터를 활용하여 데이터 기반 의사결정을 돕기 위해 다양한 대시보드를 제작 및 분석을 진행하고 있습니다. 데이터를 활용하여 가치를 창출하고 함께 성장할 동료 데이터 엔지니어 및 데이터 분석가를 찾고 있습니다.</p><p id="eec2">많은 지원 부탁드립니다!</p><p id="3968"><strong>🚀 29CM 채용 페이지</strong> : <a href="https://www.29cmcareers.co.kr/" rel="noopener ugc nofollow" target="_blank">https://www.29cmcareers.co.kr/</a></p></div></div>

29CM 기술블로그 - Medium

안녕하세요. 29CM Data Platform 팀 데이터 엔지니어 유지윤입니다. 작년 8월에 팀에 합류한 이후로 약 7개월이 지났습니다. 첫 출근 날 자리를 반기던 동료분들의 편지가 엊그제 같은데 시간이 빠른 것 같습니다.
제가 29CM으로 이직하면서 회사와 팀에 적응해 나갔던 과정을 이야기해 보려고 합니다. 전문적인 기술 내용은 아니기 때문에 데이터 엔지니어 직군이 아니더라도 입사 혹은 이직 후 팀에 적응 중인 분들도 공감하시면서 읽을 수 있는 글이 될 것 같습니다.
첫 단추가 중요한 만큼 입사 후 초기 기간이 중요하다는 건 신입이나 경력직 모두 해당하는 것 같습니다. 이때 어떻게 빠르게 그리고 효율적으로 적응해 나갈지를 고민했고, 다음과 같은 단계로 나누어 접근해 보았습니다.
STEP 1. 문화에 적응하기 🏢
입사 초기 온보딩 기간에는 의도적으로 주변을 둘러보며 구성원들이 어떻게 의사소통하고 일하는지 관찰했었습니다.
개인적으로 새로운 조직에 합류하고 가장 중요한 것은 그 조직의 문화를 이해하고 녹아드는 것으로 생각하기 때문입니다. “엔지니어로서 나의 역량을 바로 보여주겠어!”라는 거창한 목표도 좋겠지만, 그에 앞서 내가 앞으로 일한 조직에 대한 이해와 관심이 더 효율적인 결과를 가져온다고 생각하기 때문입니다.
오픈 커뮤니케이션을 지향하는 조직이라 슬랙에서 주고받는 대화와 작성된 위키 문서들을 보면서 어떻게 일을 하는 조직인지를 엿보았습니다.
문서화
입사 초기에 팀에서 작성한 다양한 문서를 보면서 놀랐던 기억이 납니다. 프로젝트 문서뿐만 아니라, 작업 내용과 코딩 및 쿼리 가이드처럼 다양한 카테고리의 문서가 존재했습니다. 이렇게 작성된 문서를 틈틈이 읽으면서 기존 히스토리와 업무 맥락을 파악했습니다. 초반에 문서를 읽고 위치를 잘 익혀두면 추후 업무를 함에도 큰 도움이 됩니다.
공유 및 스터디 문화
“개인의 역량 성장에도 관심이 있는 팀이구나!”라고 생각을 하게 된 건 매주 진행하는 스터디 시간이었습니다. 팀에서 필요한 기술 혹은 커리어와같이 다양한 주제로 진행되는 스터디 시간을 통해서 팀원들과 의견을 나누고 함께 성장할 수 있는 시간이 있다는 것이 좋았습니다. 특히 신규 입사자로서 조금 더 편한 분위기에서 팀원들과 대화할 수 있어서 더 좋았던 시간이었습니다. 또한 이런 정해진 스터디 시간 외에도 각자 알게 된 사실들을 적극적으로 팀 채널에 공유하고 토론하는 분위기여서 의욕도 생기고, 문화에 같이 기여하고 싶다는 생각이 자연스럽게 들게 되었습니다. 그래서 초반에는 의도적으로 Airflow 신규 기능이나, 평소 즐겨보던 개발 관련 유튜브들을 팀 채널에 공유했었습니다.
STEP 2. 기술에 적응하기 🛠️
데이터 엔지니어를 하면서 개인적으로 생각하는 장점이자 어려운 점은 하는 일의 scale이 넓다는 점입니다.
Kubernetes와 같은 인프라 및 클라우드부터 데이터 파이프라인, CI/CD 그리고 데이터 퀄리티까지 좋은 데이터를 전달하기 위해서는 데이터 엔지니어가 관여할 부분이 넓습니다. 데이터 파이프라인의 A부터 Z까지를 다루는 것은 매력적이지만, 신규 입사자(특히 주니어🐥)로서는 그만큼 적응해야 할 기술이 많다는 것을 의미합니다.
기존에 AWS 기반의 데이터 파이프라인을 운영한 경험이 있었지만, 29CM 데이터 파이프라인은 GCP 기반이라 우려되는 부분도 있었던 것 같습니다. 마음 한편에 “내가 가진 능력과 경험보다 부족한 부분이 더 보이면 어떡하지”라는 생각이 있었습니다. 그래서 저는 다음과 같이 접근해 나가보았습니다.
숲에서 나무로🌳
엔지니어로서 업무를 처리 함에 있어 기술과 도구에 대한 깊은 이해는 매우 중요합니다. 하지만, 아키텍처 혹은 기술을 선택한 맥락과 같이 큰 그림을 파악하는 것이 우선시 되어야 한다고 생각했습니다.
입사 초반에는 먼저 기존 운영 업무가 주어졌습니다. 이 기간에는 해당 업무들을 수행하며 전반적인 파이프라인과 팀의 코드 스타일, 디자인 패턴과 같이 큰 그림 위주로 파악하려고 했었습니다. 팀에서 쓰고 있는 기술들은 무엇이 있고, 해당 기술을 왜 선택했는지와 더불어 DAG를 어떻게 작성하는지와 같은 것들도 파악해 보고 팀원들에게 질문해 나갔습니다. 이렇게 이해한 내용을 정리하는 것이 온보딩 미션 중 하나였기 때문에 다음과 같이 정리해 나가면서 전반적인 파이프라인의 구성을 파악하였습니다.
이후 실제 프로젝트 투입 때는 해당 프로젝트의 핵심 기술을 위주로 파악해 나갔습니다.
예를 들어, 데이터 품질을 위한 이상 탐지 파이프라인을 구축하는 프로젝트에서 필수적이지만 이전에 사용 해본 경험이 없었던 Spark를 중점적으로 파악하려고 노력했습니다. 기본적인 지식을 위해서 책을 참고하고 기존에 작성된 코드를 보고 분석하며 공부했습니다.
(이때 읽었던 책은 “러닝 스파크”와 “파이썬을 활용한 스파크 프로그래밍” 이었습니다.)
질문 하기🥕
질문은 업무 파악에 있어서 가장 중요하고 효율적인 수단입니다. 팀이 왜 그러한 기술을 선택했는지 왜 이렇게 코드를 작성했는지 맥락을 파악할 수 있기 때문입니다.
하지만 상대가 “왜 이 정도의 질문을 하지?”라는 생각을 하지 않을까 혹은 내 실력에 대한 밑천이 드러날까 두려워 질문하지 않는 경우도 있습니다. 저 역시 신입 엔지니어로 입사 후 비슷한 고민을 하며 혼자 끙끙 앓던 경험을 해보았기 때문입니다. 경험적으로 고민에 깊이 없이 단순히 검색할 수 있는 부분을 질문하는 것이 아니라면, 신규 입사자의 질문에 방어적으로 대답하는 분들은 매우 소수일 것으로 생각합니다. 더해서 적응해 나가는 초반의 기간이 가장 질문하기 편한 시기기도 합니다. 모르는데 알고 있는 ‘척’을 하고 나중에 그 문제에 직면해서 해결해야 할 때는 오히려 더 질문하기 어려운 시점이 되니깐요.
그래서 코드를 파악하거나 문서를 읽고 궁금한 점이 생기면 팀원들에게 자유롭게 여쭤보았습니다. 또 업무를 진행하면서 막히는 부분에서도 “2시간 이상 해결되지 않는다면 질문하기”라는 기준을 세워서 그 이상 해결되지 않으면 당근🥕을 흔들며 도움을 요청하기도 했었습니다.
STEP 3. 기여하기 🚀
문화와 기술에 어느 정도 적응이 되었다면, 이제는 한 명의 구성원으로서 기여를 할 때입니다. 기여라는 단어가 거창해 보이지만, 생각보다 작은 것들로 기여할 수 있다고 생각합니다.
그중에 신규 입사자만이 가질 수 있는 무기 중의 하나는 새로운 시각이라고 생각합니다. 기존 시스템에 익숙해진 구성원에 비해서 다른 경험과 시야를 가진 신규 입사자는 새로운 아이디어를 낼 가능성이 높습니다. 저는 연차와 관계 없이 신입이나 주니어도 가장 쉽게 기여할 수 있는 부분이 바로 이 점이라고 생각했습니다.
기존 프로세스 개선
코드를 분석하거나 업무를 진행하면서 “왜?”라는 생각이 드는 부분이 생기기 마련입니다. 이전 맥락을 모르기 때문일 수도 있고, 더 좋은 방법이 있는 걸 알고 있기 때문일 수도 있습니다. 개선은 이런 질문에서 출발 합니다. 질문을 통해서 의문이 단순히 해결될 수도 있지만, 알고 보면 기존 구성원들에게는 익숙해져서 생각하지 못한 점일 수도 있습니다.
팀에서 Kubernetes를 사용 중인데요, 온보딩 과정에서 별도로 사용 중인 UI가 없다는 것을 알게 되었습니다. 이전에 Lens를 통해서 편리하게 관리 및 모니터링 했던 경험이 생각나서 이 부분을 팀에 제안하고 Deep Dive라는 시간에 공유하여 팀 도구로 채택한 일이 있었습니다.
Deep Dive는 데이터 플랫폼 팀의 문화 중 하나인데요, 본인이 자유롭게 딥다이브(공부) 한 내용 중에 팀에게 공유하고 싶은 것이 있다면 문서를 작성하고 시간을 잡아 공유하는 문화입니다.
오래된 문서 업데이트, 새로운 문서 작성
감사하게도 데이터 플랫폼팀이 기본적으로 문서화를 중요하기 생각하기 때문에 다양한 문서가 있어서 온보딩 과정에서 도움이 많이 되었습니다. 하지만 문서 중에는 오래되어서 현재의 시스템과 다소 상이한 부분도 있었고, 신규 입사자 입장에서는 절차가 생략되어서 이해가 어려운 문서도 존재했습니다. 이런 부분을 온보딩 과정에서 말씀드리고 필요 시에는 직접 수정도 하면서 팀에 기여하려고 노력했었습니다.
온보딩 미션 중의 하나로 현재 팀의 문서에 대한 전반적인 피드백이 있었습니다. 이때 온보딩 과정에서 느낀 팀의 문서에서 좋았던 점(Keep), 부족한 부분(Problem) 그리고 시도할 부분(Try)으로 나누어 공유하는 시간을 가졌습니다.
이러한 의견이 반영되어 팀 문서의 전반적인 체계화로 변화가 이루어졌습니다.
마치며
여기까지, 제가 팀에 합류하고 적응하면서 취했던 저만의 전략이었습니다.
당연한 것들이지만 그걸 생각하고 실천하는 게 가장 어려운 것이 아닐까 싶습니다. 곧 입사를 앞둔 분들에게 조금이나마 도움이 되는 글이었으면 좋겠습니다.
마지막으로 온보딩 과정부터 지금까지 많은 도움을 주시는 데이터 플랫폼 팀원분들에게 가장 감사하다고 말씀드리고 싶습니다! 감사합니다.
[함께 성장할 동료를 찾습니다]
29CM (무신사) 는 3년 연속 거래액 2배의 성장을 이루었습니다.
다양한 소스 데이터에서 안전하고 빠르게 수집, 처리, 저장, 제공하도록 파이프라인을 개발하고 운영하며, 제공된 데이터를 활용하여 데이터 기반 의사결정을 돕기 위해 다양한 대시보드를 제작 및 분석을 진행하고 있습니다. 데이터를 활용하여 가치를 창출하고 함께 성장할 동료 데이터 엔지니어 및 데이터 분석가를 찾고 있습니다.
많은 지원 부탁드립니다!
🚀 29CM 채용 페이지 : https://www.29cmcareers.co.kr/
데이터 엔지니어의 온보딩 이야기(feat. 29CM은 처음이라) was originally published in 29CM TEAM on Medium, where people are continuing the conversation by highlighting and responding to this story.

데이터 엔지니어의 온보딩 이야기(feat. 29CM은 처음이라)

댓글