데이터 사이언티스트로서의 첫 90일

It looks like only the source line was provided and the article text is missing. Could you please share the content you’d like translated? Once I have the text, I’ll translate it into Korean while preserving the formatting and keeping the source line unchanged.

I — 연결 구축

무엇보다 먼저, 연결을 만드는 것부터 시작하겠습니다. 학교에 다닐 때 저는 데이터 과학자를 하루 종일 머리를 숙이고 코드를 작성하고 모델을 구축하는 사람으로 생각했습니다. 그러나 제가 더 senior가 되면서 데이터 과학자는 비즈니스에 깊이 파고들어 데이터를 활용해 기회를 식별하고 비즈니스 결정을 이끌어냄으로써 실제 영향을 만든다는 것을 깨달았습니다. 오늘날에는 DS 인력이 더 제한되고 AI가 기본 코딩 및 분석 워크플로를 자동화하면서 이 점은 더욱 중요해졌습니다.

따라서 온보딩 기간 동안 연결을 구축하고 테이블에 앉는 자리를 얻는 것이 최우선 과제가 되어야 합니다. 여기에는 다음이 포함됩니다:

• 매니저 및 온보딩 버디와의 빈번한 온보딩 세션
  이들은 여러분의 향후 범위, 기대치, 우선순위를 가장 잘 이해하고 있는 사람들입니다. 제 경우 매니저가 온보딩 버디였으며, 첫 2주 동안 거의 매일 만났습니다. 저는 항상 온보딩 중에 마주친 질문 목록을 준비해서 가져갔습니다.

• 크로스‑펑셔널 파트너와의 미팅‑앤‑그리트 콜 설정
  제가 보통 그 콜에서 따르는 안건은 다음과 같습니다:

  1. 개인 소개
  2. 그들의 집중 영역 및 최우선 과제
  3. 우리 팀이 어떻게 가장 잘 지원할 수 있는지
  4. 온보딩 조언이나 “알아야 할 사항”

  마지막 질문을 특히 좋아하는데, 이는 일관되게 훌륭한 인사이트를 제공하기 때문입니다. 5년 전 제가 Brex에 온보딩했을 때도 같은 질문을 했고, 그 답변을 여기에 카테고리별로 정리했습니다. 이번에 받은 최고의 답변은:

  멍청한 질문을 하는 것을 두려워하지 마세요. 첫 3개월 동안은 신입 사원 카드를 최대한 활용하세요.

• 핵심 파트너에게는 주간/격주 1:1을 설정하고 정기 프로젝트 회의에 추가하도록 하세요. 처음에는 크게 기여하지 못하더라도 듣고 상황과 질문을 수집하는 것만으로도 큰 도움이 됩니다.

• 만약 저처럼 매니저로 온보딩한다면 직속 보고자와 일찍 대화를 시작해야 합니다. 온보딩 기간 동안 저는 직속 보고자에게서 세 가지를 배우고자 합니다:

  1. 그들의 프로젝트와 도전 과제
  2. 매니저로서 나에게 기대하는 바
  3. 그들의 커리어 목표

  첫 번째는 제가 해당 영역에 빠르게 적응하도록 돕고, 나머지 두 가지는 초기 신뢰 구축과 협업 관계 형성에 필수적입니다.

II — 도메인 컨텍스트 구축

Data scientists succeed when they understand the business well enough to influence decisions—not just analyse outcomes. Therefore, another priority during onboarding is to build your domain knowledge. Common strategies include talking to people, reading docs, searching Slack, and asking a lot of questions.

데이터 과학자는 비즈니스를 충분히 이해하여 의사결정에 영향을 미칠 수 있을 때 성공합니다—결과만 분석하는 것이 아니라. 따라서 온보딩 시 또 다른 우선순위는 도메인 지식을 구축하는 것입니다. 일반적인 전략으로는 사람들과 대화하고, 문서를 읽고, Slack을 검색하고, 많은 질문을 하는 것이 있습니다.

I usually start with conversations to identify key business context and projects. Then I dig into relevant docs in Google Drive or Confluence, and read Slack messages in project channels. I also compile the questions after reading the docs and ask them in 1:1s.

저는 보통 대화를 시작하여 핵심 비즈니스 컨텍스트와 프로젝트를 파악합니다. 그런 다음 Google Drive나 Confluence에 있는 관련 문서를 파고들고, 프로젝트 채널의 Slack 메시지를 읽습니다. 문서를 읽은 후 질문을 정리하여 1:1 미팅에서 묻기도 합니다.

One challenge I ran into is digging into the rabbit hole of docs. Each document leads to more documents with numerous unfamiliar metrics, acronym names, and projects. This is especially challenging as a manager—if each of your team members has three projects, then five people means fifteen projects to catch up on. At one point, my browser’s “To Read” tab group had over 30 tabs open.

제가 겪은 한 가지 어려움은 문서의 토끼굴에 빠지는 것입니다. 각 문서는 더 많은 문서로 이어지고, 익숙하지 않은 지표, 약어, 프로젝트가 많이 등장합니다. 이는 특히 매니저에게 어려운 일입니다—팀원 각각이 세 개의 프로젝트를 맡고 있다면, 다섯 명이면 총 열다섯 개의 프로젝트를 따라잡아야 합니다. 어느 순간 제 브라우저의 “읽을 것” 탭 그룹에 30개가 넘는 탭이 열려 있었습니다.

Luckily, AI tools are here to rescue. While reading all the docs one by one is helpful for a detailed understanding, AI tools are great for providing a holistic view and connecting the dots. For example:

다행히도 AI 도구가 이를 구원해 줍니다. 모든 문서를 하나씩 읽는 것이 상세한 이해에 도움이 되지만, AI 도구는 전체적인 관점을 제공하고 연결 고리를 찾아주는 데 뛰어납니다. 예를 들어:

• Glean (DoorDash) has access to internal docs and Slack. I often chat with Glean, asking questions like “How is GOV calculated?” or “Provide a summary of project X, including the goal, timeline, findings, and conclusion.” It links to the source documents, so I can dive deeper quickly if needed.

  Glean (DoorDash)은 내부 문서와 Slack에 접근할 수 있습니다. 저는 종종 Glean과 대화하며 “GOV는 어떻게 계산되나요?” 혹은 “프로젝트 X의 목표, 일정, 결과, 결론을 포함한 요약을 제공해 주세요.”와 같은 질문을 합니다. Glean은 원본 문서에 링크를 제공하므로 필요하면 빠르게 더 깊이 파고들 수 있습니다.

• NotebookLM – I shared a set of docs on a specific topic with it and asked it to generate summaries and mind maps. This helped me organise my thoughts. It can also create podcasts, which are sometimes more digestible than reading long documents.

  NotebookLM – 특정 주제에 대한 문서 세트를 공유하고 요약 및 마인드맵을 생성하도록 요청했습니다. 이는 제 생각을 정리하는 데 도움이 되었습니다. 또한 팟캐스트를 만들 수 있어, 긴 문서를 읽는 것보다 더 쉽게 소화할 수 있는 경우가 있습니다.

• ChatGPT (or similar) can be connected to internal knowledge bases to serve a similar purpose.

  ChatGPT (또는 유사한 도구)를 내부 지식 베이스에 연결하여 유사한 목적을 수행할 수 있습니다.

Source: …

III — 데이터 지식 구축

데이터 과학자에게는 도메인 지식을 쌓는 것만큼 데이터 지식을 쌓는 것도 중요합니다. 현장 관리자로서 저는 간단한 기준을 스스로에게 적용합니다: 팀에 실질적이고 신뢰할 수 있는 조언을 제공할 수 있을 정도로 직접 데이터를 다룰 수 있어야 합니다.

제가 빠르게 적응하는 데 도움이 된 방법은 다음과 같습니다:

• 1주 차에 기술 스택을 설정한다.
  개발 환경을 초기에 구성하는 것을 권장합니다. 접근 권한 문제, 권한 부여, 그리고 특이한 환경 문제는 예상보다 오래 걸리는 경우가 많습니다. 모든 것이 빨리 갖춰질수록 데이터를 가지고 놀기 시작할 수 있는 시점도 빨라집니다.

• AI‑지원 데이터 도구를 충분히 활용한다.
  모든 기술 기업이 AI를 데이터 워크플로에 통합하고 있습니다. 예를 들어 DoorDash에서는 Cursor가 Snowflake와 연결돼 내부 데이터 지식과 컨텍스트를 제공합니다. 이를 통해 우리 데이터에 기반한 SQL 쿼리와 분석을 생성할 수 있습니다. 생성된 쿼리가 100 % 정확하지는 않지만, 제안된 테이블, 조인, 그리고 과거 쿼리를 시작점으로 활용하면 매우 유용합니다. 이는 여러분의 기술적 판단을 대체하지는 않지만, 첫 인사이트를 얻는 시간을 크게 단축시켜 줍니다.

• 데이터를 직접 탐색한다.
  주요 테이블 몇 개를 가져와 간단한 탐색 쿼리를 실행하고 결과를 시각화합니다. 스스로에게 다음 질문을 해보세요:

  1. 기본 키와 외래 키는 무엇인가?
  2. 어느 컬럼에 결측값이나 이상값이 존재하는가?
  3. 가장 흔히 사용되는 메트릭은 무엇이며, 어떻게 계산되는가?

• 배운 내용을 문서화한다.
  살아있는 마크다운 파일이나 노트북에 다음을 기록합니다:

  • 발견한 데이터 사전 항목
  • 일반적인 변환 파이프라인
  • 알려진 데이터 품질 이슈와 그 완화 방안

  이 문서를 초기에 팀과 공유하면 주도성을 보여줄 수 있고, 향후 신규 입사자에게 참고 자료가 됩니다.

데이터 사이언스 온보딩 체크리스트

IV — 작게 시작하고 일찍 기여하기

온보딩은 주로 학습에 관한 것이지만, 저는 작게 시작하고 일찍 기여하기를 강력히 권장합니다. 초기 기여는 소유권을 나타내고 신뢰를 구축합니다 — “완벽한” 프로젝트를 기다리는 것보다 훨씬 빠르게. 다음은 구체적인 방법들입니다:

• 온보딩 문서 개선
  온보딩 문서를 살펴보다 보면 무작위 기술 문제, 깨진 링크, 오래된 지침 등을 발견하게 됩니다. 직접 고치는 것도 가치가 있지만, 문서를 향상시키는 것은 팀 플레이어이며 앞으로 입사할 사람들을 위해 온보딩을 개선하고 싶다는 의지를 보여줍니다.

• 문서 작성
  어느 회사든 완벽한 문서는 없습니다 — 제 경험과 동료들과의 대화에 따르면 대부분의 데이터 팀이 오래되었거나 누락된 문서 때문에 어려움을 겪고 있습니다. 아직 큰 프로젝트에 바쁘지 않은 온보딩 단계는 이러한 공백을 메우기에 최적의 시기입니다.

  예시:

  • 팀의 과거 및 진행 중인 프로젝트를 중앙화하고 주요 결과와 담당자를 포함한 프로젝트 디렉터리를 만들었습니다.
  • 과거 실험 및 분석에서 얻은 인과 관계를 요약한 메트릭 휴리스틱 컬렉션을 정리했습니다.

  이러한 문서는 AI 에이전트에게도 귀중한 컨텍스트가 되어 AI‑생성 출력물의 품질과 관련성을 높입니다.

• 프로세스 개선 제안
  모든 데이터 팀은 고유한 장단점을 가진 서로 다른 방식으로 운영됩니다. 새로운 팀에 합류하면 프로세스에 대한 새로운 시각을 제공하고 효율성을 높일 수 있는 기회를 발견할 수 있습니다. 과거 경험을 바탕으로 한 사려 깊은 제안은 매우 가치가 있습니다.

제 생각에 성공적인 온보딩은 교차 기능 정렬, 비즈니스 이해, 데이터 직관을 구축하는 것을 목표로 합니다.

온보딩 체크리스트

1~2주차: 기초 다지기

• 주요 비즈니스 파트너 만나기
• 핵심 교차 기능 회의에 초대받기
• 팀의 초점과 높은 수준의 우선순위 이해하기
• 기술 스택, 접근 권한 및 권한 설정하기
• 첫 번째 코드를 작성하기
• 문서를 읽고 질문하기

2~6주차: 직접 해보기

• 팀 OKR 및 자주 사용되는 데이터 테이블 깊이 파악하기
• 담당 영역에 대한 심층 탐구 (문서와 질문 더하기)
• 시작 프로젝트를 처음부터 끝까지 완수하기
• 초기 기여하기: 오래된 정보 업데이트, 문서 한 조각 만들기, 혹은 프로세스 개선 제안하기

6~12주차: 소유권 확보

• 교차 기능 회의에서 의견을 제시하고 데이터 기반 관점을 제공하기
• 자신의 도메인에 대한 “가장 믿을 수 있는” 사람으로 신뢰 구축하기

온보딩은 회사, 역할, 그리고 경력 수준에 따라 다르게 보일 수 있지만, 원칙은 일관됩니다. 곧 새로운 역할을 시작한다면 이 체크리스트가 더 명확하고 자신 있게 적응하는 데 도움이 되길 바랍니다.