[토스뱅크] 데이터 분석가 (7년 이상) (Data Analyst) 공고 분석

이 자리가 왜 생겼을까요

1하게 될 업무

• 요청받은 데이터를 추출하는 데서 나아가 비즈니스 이면의 '진짜 문제'를 정의하고 가설을 세웁니다. 인과추론, A/B 테스트 등 적합한 방법론으로 가설을 검증하고 실행 가능한 액션 아이템을 도출합니다.

  이렇게 볼 수 있어요

  토스뱅크 스쿼드는 Product Owner, Product Manager, 개발자, Data Analyst가 한 팀으로 일하는 구조라 분석가가 받는 요청이 곧 스쿼드의 제품 문제입니다. 업무 설명은 요청받은 데이터 추출을 넘어 비즈니스 이면의 '진짜 문제'를 정의하라고 적었습니다. FAQ는 앱 로그 데이터와 금융 거래 데이터를 다룬다고 답했습니다. 요청받은 지표 추출이 실제 문제의 일부였던 사례라면 어떤 가설을 세워 어떤 방식으로 검증했는지를 쓰면 이 업무와 가까운 사례가 됩니다.

• 문제를 정의하고 해결하는 데 기존 관점의 한계를 파악하고 새로운 분석 프레임과 지표 체계를 설계합니다.

  이렇게 볼 수 있어요

  기존 관점의 한계는 지금 쓰는 지표가 놓치는 사용자 행동을 뜻하는 경우가 많습니다. 앱 로그와 거래 데이터가 함께 있는 은행에서는 화면 지표와 거래 결과가 서로 다른 방향을 가리킬 수 있습니다. 두 쪽을 이은 지표를 새로 정의하고, 어느 팀이 그 지표로 결정을 바꿨는지까지 이어진 사례가 이 항목에 맞습니다.

• 여러 스쿼드의 이해관계와 지표 간 Trade-Off를 정리해 전사 우선순위 결정을 돕습니다.

  이렇게 볼 수 있어요

  스쿼드마다 목표 지표가 달라 한 스쿼드의 지표를 올리는 일이 다른 스쿼드의 지표를 내릴 수 있고, 이 업무는 그 충돌을 정리합니다. 토스증권 Data Analyst (7년 이상) 공고도 여러 사일로를 관통하는 지표 체계를 설계하는 일을 업무로 적었습니다. 스쿼드 두 곳의 지표가 부딪힌 안건에서 어떤 기준으로 우선순위를 제안했는지가 이 업무의 출발점입니다.

• 팀 동료들이 반복해서 활용할 수 있는 재사용 가능한 데이터 구조를 고민하고, 데이터 마트 설계와 정합성 검증으로 누구나 믿고 쓸 수 있는 데이터 표준을 만듭니다.

  이렇게 볼 수 있어요

  토스뱅크 Data Analytics Engineer 공고는 Data Warehouse 팀이 전사 마트의 표준을 정의하고 개발한다고 적었고, 이 공고는 분석가가 마트 설계와 정합성 검증을 맡는다고 적었습니다. 동료의 한마디도 정기 리포트가 자동화돼 있고 데이터 엔지니어가 분석 환경을 빠르게 지원한다고 적었습니다. 마트를 분석 쪽에서 직접 설계해 팀원들이 같은 쿼리를 다시 쓰지 않게 만든 경험이 있다면 줄어든 중복 쿼리나 리포트 수가 이 업무와 가까운 숫자입니다.

• 문제 정의부터 분석 결과 공유까지의 프로세스에서 병목과 반복 작업을 찾아내고, 분석 환경과 일하는 방식을 개선해 챕터 전체의 분석 효율성을 높입니다.

  이렇게 볼 수 있어요

  사람을 관리하지 않는 분석가가 챕터 효율 개선을 맡습니다. FAQ는 7년차 이상도 직접 분석하는 IC(Individual Contributor)라고 답했습니다. 챕터에서 분석 과제를 리드하며 효율을 개선하지만 인사 평가와 조직 관리는 담당하지 않는다는 답도 있습니다. 그래서 개선 경험은 관리 직책이 아니라 분석가로서 한 일로 씁니다. 병목이 요청 접수, 쿼리 작성, 결과 공유 가운데 어디서 생겼는지 단계별 소요 시간으로 잰 경험을 쓰면 개선의 출발점이 드러납니다. Impala(SQL)와 Tableau, Jupyter Notebook 환경에서 반복 작업을 템플릿이나 자동화로 바꿔 한 건당 시간이 줄어든 경험도 이 업무의 사례입니다.

• AI, LLM 등 최신 기술을 도구로 활용해 반복 업무를 효율화하고, 기존 관습에 얽매이지 않고 생산성을 높일 새로운 분석 방식과 도구를 적극 도입합니다.

  이렇게 볼 수 있어요

  FAQ는 주로 쓰는 도구로 Impala(SQL)와 Tableau, 필요하면 Jupyter Notebook의 Python을 들었습니다. 이 도구들로 하던 반복 업무 가운데 LLM으로 바꾼 것이 있다면 쿼리 초안 작성이나 지표 정의 문서 정리처럼 어떤 작업이었는지를 구체적으로 쓸 만합니다. 결과를 사람이 어떻게 검증했는지가 함께 있어야 도구 도입 경험으로 전해집니다.

• 분석 문서, 쿼리, 지표 정의의 표준을 만들고 챕터의 분석 자산이 개인이 아닌 조직에 축적되도록 지식 베이스를 구축합니다.

  이렇게 볼 수 있어요

  팀 소개에 따르면 DA챕터는 매주 스쿼드별 러닝을 공유하는 시간을 갖습니다. 이 업무는 그 러닝이 개인의 기억이 아니라 분석 문서와 지표 정의, 쿼리로 남게 만듭니다. 지표 정의서나 분석 쿼리 저장소를 만들어 신규 입사자가 참고한 경험이라면 쓰는 사람 수나 재사용 횟수가 지식 베이스의 효과를 말해 줍니다.

• 동료 분석가의 문제 해결을 돕고 리뷰하며 챕터 전체의 분석 품질을 함께 끌어올립니다.

  이렇게 볼 수 있어요

  7년 이상을 요구하는 자리에서 동료 분석가의 문제 해결을 돕고 리뷰하는 일이 업무로 들어 있습니다. FAQ 답대로 이 직급도 사람을 관리하지 않는 IC이므로 리뷰는 직책이 아니라 분석 품질에 대한 기여입니다. 분석 리뷰 기준이나 체크리스트를 만들어 쓴 경험이라면 리뷰 뒤 달라진 점이 그 기여를 보여 줍니다.

2자격 요건

• 데이터 분석 관련 실무 경험이 7년 이상이거나 그에 준하는 경험을 한 사람이 필요하다고 적었습니다.

  이렇게 볼 수 있어요

  '그에 준하는 경험'이 함께 적혀 있어 분석 직함으로 보낸 기간에 한정되지 않습니다. FAQ는 DA챕터에 금융권 경험이 없는 동료가 더 많다고 답했습니다. 팀 소개에 따르면 동료 배경은 금융권, 게임사, 이커머스 등으로 다양합니다. 다른 업종의 분석 경력도 이 조건에 함께 적을 수 있습니다. 연차 숫자보다 문제 정의와 지표 체계 설계처럼 업무에 적힌 일을 해 본 경험을 구체적으로 적습니다.

• 문제의 본질을 파악하고 내 분석이 우리 팀을 넘어 전사 전략과 비즈니스에 미칠 영향을 고려하며 주도적으로 해결책을 제안하는 사람이 필요하다고 적었습니다.

  이렇게 볼 수 있어요

  분석가는 한 스쿼드에 속해 그 스쿼드의 문제를 풀면서 DA챕터에도 속하는 매트릭스 구조에 있습니다. 이 구조에서 '우리 팀을 넘어'는 다른 스쿼드의 지표와 부딪히는 지점까지 포함할 수 있습니다. 업무에는 여러 스쿼드의 이해관계와 지표 간 Trade-Off를 정리해 전사 우선순위 결정을 돕는 일이 있습니다. 내 스쿼드 지표를 올린 분석이 다른 스쿼드 지표에 준 영향을 어떻게 확인해 제안에 넣었는지가 이 요건과 맞는 사례가 됩니다.

• Python/R 등을 활용해 데이터를 깊이 있게 분석하고, 통계적 지식을 바탕으로 실험 결과를 올바르게 해석할 수 있는 사람을 찾는다고 적었습니다.

  이렇게 볼 수 있어요

  FAQ는 대부분의 데이터를 Impala(SQL)로 확인하고 시각화는 Tableau를 주로 쓰며, 필요에 따라 Jupyter Notebook으로 python을 쓰기도 한다고 답했습니다. 그래서 이 요건의 무게는 도구보다 실험 결과의 해석에 더 있을 수 있습니다. 업무에는 인과추론과 A/B 테스트가 있습니다. 표본 크기나 유의성 판단에서 잘못된 결론을 막은 해석 경험은 어떤 오해였는지까지 적을 때 이 요건의 사례가 됩니다.

• 어려운 분석 결과를 비전문가 동료도 이해할 수 있는 쉬운 언어로 바꾸어 전달하고 설득할 수 있는 사람이 필요하다고 적었습니다.

  이렇게 볼 수 있어요

  스쿼드는 Product Owner, Product Manager, 개발자와 함께 일하는 구조라 분석 결과를 듣는 쪽이 대부분 분석가가 아닙니다. 인과추론 결과를 의사결정자가 이해한 말로 바꿔 제품 결정이 달라진 사례가 이 요건에 가깝습니다. 이력서 안내가 분석으로 액션을 제시한 경험을 적어 달라고 한 것과 이어집니다.

3우대 사항

• 서비스 기획 및 로그 설계 단계부터 참여해 본 경험이 있으면 더 좋다고 적었습니다.

  이렇게 볼 수 있어요

  FAQ가 앱 로그 데이터를 공통으로 다룬다고 적었으므로 로그 설계 참여는 이 팀 데이터의 출발점에 관여한 경험입니다. 이벤트 이름과 속성을 기획 단계에서 정해 나중에 분석할 수 있는 지표가 늘어난 경험이 있다면 어떤 질문에 답하려고 로그를 설계했는지가 이 우대의 중심입니다.

• 새로운 기술(AI 등)을 활용해 업무 프로세스를 개선해 본 경험이 있으면 더 좋다고 적었습니다.

  이렇게 볼 수 있어요

  업무의 AI·LLM 활용 항목과 같은 내용을 우대합니다. 토스증권 Data Analyst (7년 이상) 공고도 AI 도구를 개인 생산성을 넘어 분석 조직의 일하는 방식에 적용한 경험을 우대에 적었습니다. 혼자 쓰던 도구를 팀 절차로 바꿨다면 적용 전후의 소요 시간을 적을 수 있습니다.

• 전사 로그 표준, 통합 사용자 기준, 데이터 거버넌스 정책 등 조직 단위 데이터 표준을 설계하고 전파한 경험이 있는 사람이면 더 좋다고 적었습니다.

  이렇게 볼 수 있어요

  업무의 데이터 표준과 지식 베이스 항목이 챕터 안의 표준이라면 이 우대는 조직 전체로 넓힌 표준입니다. 통합 사용자 기준은 앱, 웹, 계좌 같은 여러 접점에 나타난 한 사람을 한 명으로 세게 합니다. 이것이 없으면 같은 사용자 수가 팀마다 다르게 나옵니다. 기준을 정한 뒤 다른 팀이 따르게 한 방법이 전파 경험의 핵심입니다.

• 전사 지표 체계를 설계하거나 분석 지식 베이스를 구축해 비분석가의 데이터 활용을 늘려 본 경험이 있으면 더 좋다고 적었습니다.

  이렇게 볼 수 있어요

  업무의 지식 베이스는 분석 문서, 쿼리, 지표 정의가 개인이 아니라 챕터에 쌓이게 하는 일이고, 이 우대는 그 효과를 분석가 밖으로 넓힌 경험을 묻습니다. 지식 베이스를 연 뒤 비분석가가 직접 조회한 건수나 분석 요청의 감소가 이 우대에 맞는 숫자입니다.

4기타 사항

• 게시일 : 2026년 9월 18일
• 고용형태 : 정규직
• 근무지 : 서울특별시 강남구 테헤란로 131, 13층 (역삼동, 한국지식재산센터) (추정)
• 경력 조건 : 경력 7년 이상
• 학력 조건 : 해당 내용은 원본 공고에서 확인되지 않습니다.

쓰는 기술

공고 본문에 적힌 기술만 모은 목록입니다.

• Impala
• SQL
• Tableau
• Python
• R
• Jupyter Notebook

전형과 지원

토스커뮤니티는 합류 여정을 한 페이지로 공개해 두었습니다. 공통 골격은 같지만 계열사와 공고에 따라 단계가 더해지거나 빠지므로, 공고 페이지에 적힌 단계를 함께 확인해야 합니다.

지원 전 준비할 것

1. 1

   문제정의부터 결과까지 한 프로젝트 쓰기

   이력서 안내는 프로젝트의 문제정의, 가설설정, 실험설계 및 검증, 결과의 과정이 드러나면 좋다고 했습니다. 인과추론이나 A/B 테스트를 쓴 프로젝트 하나를 이 순서로 정리합니다.

2. 2

   사용자를 이해해 액션을 낸 경험 고르기

   안내는 데이터 분석으로 서비스 이용 유저를 깊이 이해하고 이를 통해 액션을 제시한 경험을 적어 달라고 했습니다. 분석 결과와 그 뒤 제품에서 바뀐 것을 한 쌍으로 적습니다.

3. 3

   시니어 역할의 근거 정리하기

   이 자리는 지표 체계, 분석 표준, 동료 리뷰를 맡는 IC입니다. 지표 정의서를 만들었거나 분석 리뷰를 해 본 경험을 한 줄씩 따로 적어 업무 항목과 연결합니다.