[토스] 재무 데이터 분석가 (Accounting) (Financial Data Analyst) 공고 분석

이 자리가 왜 생겼을까요

1하게 될 업무

• CPC(금융감독원·한국은행) 정기보고 및 회계결산에 필요한 데이터를 정의하고 직접 추출하고 검증합니다.

  이렇게 볼 수 있어요

  정기보고와 결산은 기한이 정해진 보고라 어떤 원천 테이블의 어느 컬럼이 보고 항목이 되는지 연결하는 매핑이 핵심입니다. 토스 Financial Data Analyst (FP&A) 공고는 데이터 정합성을 검증하고 정산 시스템을 구축하는 것이 아니라 데이터 분석에 초점이 맞춰진 포지션이라고 밝혔습니다. 반면 이 공고는 데이터의 정의와 검증이 업무의 중심입니다. 보고 항목과 원천 데이터를 연결한 매핑표를 만들어 본 경험이 있다면, 매핑한 항목 수와 검증에서 찾은 불일치를 함께 적습니다. 이 업무에서도 가장 먼저 나오는 결과물이 그 매핑표입니다.

• SQL 기반으로 데이터 정합성을 확인하며 데이터 품질 이슈를 추적해 유관 부서(FDH·FIT 등)와 긴밀히 공유합니다.

  이렇게 볼 수 있어요

  FDH와 FIT는 공고가 약어로만 적은 부서 이름입니다. 지원서에는 데이터 품질 이슈를 원천 팀과 어떻게 주고받았는지로 바꿔 쓸 수 있습니다. 품질 이슈는 발견, 원인 팀 지정, 수정 확인 순으로 기록을 남기지 않으면 결산마다 다시 나옵니다. 이슈 목록을 관리한 방식과 재발 건수가 추적을 어디까지 했는지를 보여 줍니다.

• Tableau, Looker 등을 활용해 결산 마감 검증 대시보드 및 신규 서비스(앱인토스, affiliate 등) 선제 대응용 대시보드를 설계하고 운영합니다.

  이렇게 볼 수 있어요

  결산 마감 검증 대시보드는 마감 기간에 계정별 합계가 원천과 맞는지 한눈에 보게 하는 화면입니다. 신규 서비스 대응용은 서비스가 열리기 전부터 매출과 정산 구조를 데이터에서 볼 수 있게 미리 만드는 화면입니다. 토스 Platform Product Owner 공고는 Pay, Commerce, Ads 도메인을 소개했습니다. 그 가운데 Commerce와 Ads는 금융 밖의 서비스이고, 이렇게 새 서비스가 생길 때마다 매출과 정산을 어떻게 처리할지 정하는 일이 따라옵니다. 새 서비스 출시 전에 재무 대시보드를 먼저 만들어 봤다면 그때 확인한 항목이 이 업무의 선제 대응에 가깝습니다.

• 현행 재무 프로세스(계약, 검수, 지급, 정산 모수 확보 등)를 추적해 수치로 계량화합니다.

  이렇게 볼 수 있어요

  계약, 검수, 지급은 구매·지급 프로세스의 단계이고 정산 모수는 정산 대상 거래의 전체 집합입니다. 이 단계를 시스템 기록으로 추적하려면 단계별 날짜가 어디에 남는지부터 확인해야 합니다. 단계별 날짜를 추적해 소요 일수를 처음 계산해 본 경험이 있다면 어떤 데이터로 어느 단계의 날짜를 얻었는지가 계량의 출발점입니다.

• 단계별 소요일수, 누락률 등 프로세스 상의 병목(bottleneck)을 데이터로 규명하고 실질적인 해결책을 제시합니다.

  이렇게 볼 수 있어요

  소요일수는 평균만으로는 병목을 찾기 어렵고 단계별 분포와 오래 걸린 건의 공통점을 봐야 합니다. 누락률은 한 단계에서 다음 단계로 넘어가지 않은 건의 비율로 정의할 수 있어 정산 모수가 빠지는 곳을 보여 줍니다. 병목을 숫자로 찾아 해결책을 낸 경험이 있다면 해결책이 소요일수를 얼마나 줄였는지까지 쓰면 규명과 해결책 제시가 함께 보입니다.

• 도출된 개선안을 '데이터 모델 및 지표 정의' 형태의 구체적인 요구사항으로 구조화해 유관 개발팀(SAP·FDH·FIT 등)에 전달합니다.

  이렇게 볼 수 있어요

  이 업무에서 분석가가 개발팀에 넘기는 것은 아이디어가 아니라 테이블 구조와 지표 정의서입니다. 개발팀은 어느 원천의 어느 컬럼을 어떤 조건으로 합산하는지까지 정의돼 있어야 구현할 수 있습니다. 정의서에는 보통 계산식과 제외 조건을 함께 적습니다. 요구사항 문서가 실제 구현까지 이어진 경험이 있다면 문서에 적은 항목과 구현 결과가 이 업무의 전달 방식과 맞습니다.

2자격 요건

• 3~5년차 상당의 실무 경험을 보유한 사람을 찾는다고 적었습니다. 주니어에서 중급 수준의 역량 보유자라고 괄호로 덧붙였습니다.

  이렇게 볼 수 있어요

  토스 Financial Data Analyst (FP&A) 공고에는 연차 조건이 없었습니다. 이 공고는 '3~5년차 상당'이라는 말에 주니어~중급 수준이라는 설명을 붙여, 연차를 역량 수준의 표시로 적었습니다. 연차보다 결산 데이터 정의와 검증, 프로세스 계량처럼 업무에 적힌 일을 해 본 경험을 구체적으로 적을 수 있습니다.

• 재무회계 또는 ERP 관련 실무 경험과 기초 지식을 갖춘 사람이 필요하다고 적었습니다.

  이렇게 볼 수 있어요

  재무회계 경력과 ERP 경력은 이 조건에 함께 적을 수 있습니다. 업무에는 요구사항을 전달할 유관 개발팀 이름에 SAP가 들어 있고, 회계결산 데이터를 직접 추출하는 일도 이 포지션이 맡습니다. ERP 경험은 전표와 계정 데이터가 어느 모듈에 쌓이는지 아는 데, 회계 경험은 뽑은 숫자가 결산에서 맞는지 판단하는 데 쓰입니다. ERP 쪽이면 어느 모듈에서 어떤 데이터를 뽑았는지를, 회계 쪽이면 결산 숫자를 검증한 절차를 적으면 경험의 쓰임이 분명합니다.

• SQL을 활용해 직접 데이터를 추출하고 정합성을 검증할 수 있어야 한다고 적었습니다.

  이렇게 볼 수 있어요

  서류 바로 뒤의 사전 쿼리 테스트가 이 요건을 실제 쿼리로 확인하는 단계입니다. 정합성 검증은 건수와 합계를 원천과 대조하는 쿼리를 쓰는 일입니다. 공고는 직무 인터뷰 중 라이브 쿼리 테스트를 요청할 수 있다고 밝혔습니다. 검증 쿼리를 직접 작성한 사례를 한두 개 정해 설명할 수 있게 정리합니다.

• 업무 프로세스를 분석하고 이를 데이터로 계량화해 개선안 및 지표로 전환(요구사항 구조화)해 본 경험이 있는 사람이 필요하다고 적었습니다.

  이렇게 볼 수 있어요

  이 요건은 프로세스 추적, 병목 규명, 개발팀 전달이라는 업무 세 단계를 한 사람이 이어서 해 본 경험을 가리킵니다. 분석에서 끝난 개선안에는 개발팀이 구현할 정의서가 없어서 실제 변화로 이어지지 않는 경우가 흔합니다. 한 프로세스를 골라 어떤 지표로 정의했고 그 정의서가 개발팀 요구사항으로 넘어가 구현까지 갔는지 적으면 세 단계가 모두 보입니다.

• 회계, FP&A, 개발, 사업부 등 다양한 이해관계자 사이에서 커뮤니케이션하며 요구사항을 명확히 구체화할 수 있어야 한다고 적었습니다.

  이렇게 볼 수 있어요

  개선안을 받는 쪽이 개발팀이고 숫자를 쓰는 쪽이 회계와 FP&A라서, 분석가가 양쪽 용어를 옮겨 주는 역할을 합니다. 회계가 쓰는 결산 용어를 개발팀이 구현할 수 있는 필드와 조건으로 바꾼 경험이 있다면 용어 하나를 예로 어떻게 정의했는지를 적으면 번역 경험이 구체적입니다.

• 데이터 품질과 정합성에 강한 책임감을 느끼며 신뢰할 수 있는 데이터 체계를 만드는 것을 중요하게 생각하는 사람과 함께하고 싶다고 적었습니다.

  이렇게 볼 수 있어요

  업무에 금융감독원·한국은행 정기보고가 있어서, 정합성 오류가 제출한 숫자에 반영되면 정정해 다시 제출해야 할 수 있습니다. 그래서 이 책임감은 마음가짐보다 제출 전에 건수와 합계를 원천과 맞춰 본 절차로 드러납니다. 오류가 보고나 결산에 반영된 뒤 발견됐을 때 어떻게 정정하고 재발을 막았는지가 책임감의 구체적인 사례가 됩니다.

3우대 사항

• Tableau, Looker 등 BI 툴을 활용해 대시보드를 직접 설계하고 시각화해 본 경험이 있다면 좋다고 적었습니다.

  이렇게 볼 수 있어요

  업무에 적힌 결산 마감 검증 대시보드와 신규 서비스 대응 대시보드에도 Tableau와 Looker가 예로 나옵니다. 두 도구는 모두 BI이지만 Looker는 지표 정의를 모델 코드로 관리해 같은 지표가 대시보드마다 다르게 나오는 일을 줄이는 쪽입니다. 지표 정의를 중앙에서 관리한 경험이 있다면 쓴 도구와 함께 적으면 이 우대에 맞습니다.

• 매출, 비용, 정산 등 재무 데이터에 대한 모델링 경험이 있으면 더욱 좋다고 적었습니다.

  이렇게 볼 수 있어요

  이 우대 경험은 업무의 정산 모수 확보와 데이터 모델 요구사항 구조화에 쓰입니다. 매출과 정산은 거래 단위에서 계정 단위로 집계 기준이 바뀌므로 어느 기준으로 모델을 짰는지가 이 우대의 중심입니다.

• 금감원, 한국은행 등 금융권 정기보고 데이터 대응 경험이 있는 사람을 우대한다고 적었습니다.

  이렇게 볼 수 있어요

  업무에 이미 금융감독원·한국은행 정기보고용 데이터를 정의하고 추출하는 일이 들어 있어서, 이 우대는 같은 보고 양식을 다뤄 본 경험을 가리킵니다. 금융권 보고는 항목마다 작성 기준이 정해져 있으므로, 원천 컬럼을 그 기준에 맞춰 변환한 규칙과 제출 기한 안에 검증을 마친 과정이 대응 경험의 구체적인 모습입니다.

• Finance 영역의 반복적인 보고와 정산 업무를 표준화하고 자동화해 본 경험이 있다면 적극 환영한다고 적었습니다.

  이렇게 볼 수 있어요

  표준화와 자동화는 순서가 있습니다. 결산 항목마다 달랐던 검증 방식을 한 기준으로 먼저 맞추고, 그 기준을 쿼리와 대시보드로 반복 실행되게 하는 일로 나눠 적으면 두 동작이 모두 보입니다. 업무에 적힌 결산 마감 검증 대시보드도 이렇게 반복 실행되는 검증의 한 형태입니다. 마감 때 걸리던 인력과 시간이 어떻게 달라졌는지가 경험의 크기를 보여 줍니다.

4기타 사항

• 게시일 : 2026년 9월 3일
• 고용형태 : 정규직
• 근무지 : 서울특별시 강남구 테헤란로 142 (역삼동, 아크플레이스) (추정)
• 경력 조건 : 경력 3~5년차
• 학력 조건 : 해당 내용은 원본 공고에서 확인되지 않습니다.

쓰는 기술

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

• SQL
• Tableau
• Looker

전형과 지원

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

지원 전 준비할 것

1. 1

   BI 대시보드 설계 사례 쓰기

   이력서 안내는 Tableau, Looker 등 BI 툴을 활용해 대시보드를 직접 설계하고 시각화해 본 경험이 있다면 좋다고 했습니다. 대시보드 하나를 골라 가져온 데이터 원천, 정의한 지표, 대시보드를 본 사람, 바뀐 운영을 순서대로 정리합니다.

2. 2

   재무 데이터 모델링과 정기보고 경험 정리하기

   안내는 매출, 비용, 정산 같은 재무 데이터 모델링 경험과 금융감독원, 한국은행 등 정기보고 데이터 대응 경험을 따로 적었습니다. 보고 항목, 원천 테이블, 검증 방법을 한 표로 정리합니다.

3. 3

   표준화·자동화 사례와 쿼리 테스트 준비하기

   안내는 Finance 영역의 반복 보고와 정산 업무를 표준화하고 자동화한 경험을 적극 환영한다고 적었습니다. 줄어든 마감 소요 시간도 함께 적습니다. 서류 다음 단계가 사전 쿼리 테스트이므로 검증 쿼리를 다시 작성해 연습합니다.