[토스] AI Platform Engineer (Inference Pipeline) 공고 분석

이 자리가 왜 생겼을까요

1하게 될 업무

• ML, LLM, Vision 모델을 조합해 사람이 하던 대량의 판단 업무를 대용량 AI 파이프라인으로 자동화합니다.

  이렇게 볼 수 있어요

  모델 하나를 서비스에 붙이는 일이 아니라 여러 모델을 한 흐름으로 엮는 일입니다. 팀 소개는 수천만 건을 단기간에 처리하는 경우와 수십만에서 수백만 건을 낮은 지연으로 응답하는 경우를 함께 들며, 어느 쪽인지에 따라 파이프라인 구조가 완전히 달라진다고 적었습니다.

• 토스의 AI 플랫폼과 인프라를 각 도메인이 필요로 하는 형태로 연결하고, 여러 도메인에서 반복되는 요소를 공통 기능으로 끌어올려 플랫폼을 고도화합니다.

  이렇게 볼 수 있어요

  도메인 과제를 직접 풀면서 그 결과를 플랫폼으로 남기는 역할입니다. 팀 소개도 한 서비스에서 풀어낸 방식이 다른 서비스의 출발점이 된다고 적었으므로, 특정 과제용 코드를 여러 팀이 쓰는 공통 모듈로 바꿔 본 경험이 있다면 그 모듈을 쓴 팀 수를 숫자로 남겨 둘 만합니다.

• 외부 모델 API를 사용할지 자체 모델로 옮길지를 비용과 성능을 근거로 판단하고, 데이터가 쌓이면 자체 모델로 전환하는 흐름까지 만듭니다.

  이렇게 볼 수 있어요

  비용과 성능을 비교해 어떤 모델을 쓸지 고르는 업무입니다. 외부 API 호출량과 비용을 따져 자체 모델로 옮겼거나 옮기지 않기로 한 결정이 있다면 그때 비교한 비용과 품질 숫자를 적어야 합니다.

• 쓴 만큼 내는 종량제와 처리량을 미리 확보하는 PTU(예약 처리량)를 섞어 비용 구조를 설계하고, 같은 결과를 더 적은 비용으로 낼 방법을 계속 찾습니다.

  이렇게 볼 수 있어요

  자격 요건에도 Pay-as-you-go, PTU, Batch API의 트레이드오프를 판단하는 항목이 있습니다. LLM 호출 비용을 요금 방식의 조합으로 줄여 본 경험이 있다면 바꾸기 전과 후의 월 비용이 핵심 숫자입니다.

• 동기 호출로 감당되지 않는 규모는 요청과 결과를 분리한 비동기 구조나 대량 배치 처리로 나누어 설계하고, 순간적으로 몰리는 부하에도 전체 처리량이 흔들리지 않게 만듭니다.

  이렇게 볼 수 있어요

  실시간 응답과 대량 배치를 같은 팀이 함께 설계합니다. 큐를 두어 요청과 결과를 나눴거나 배치로 돌려 처리량을 맞춘 경험은 피크 때 요청 수와 처리 시간을 함께 남겨 두면 규모가 분명해집니다.

• Rate Limit과 이중화, 장애 전환, Fallback/Retry 등을 설계해 운영 안정성을 확보합니다.

  이렇게 볼 수 있어요

  자격 요건에도 같은 네 가지를 직접 설계해 장애 상황에서도 파이프라인이 멈추지 않게 만든 경험이 적혀 있습니다. 모델 공급자 장애 때 다른 경로로 넘긴 일처럼 실제로 전환해 본 일이 있다면 그때의 영향 범위를 적을 수 있습니다.

• 여러 모델과 처리 단계가 이어진 파이프라인을 end-to-end로 보며 구간마다 흩어진 숫자를 직접 검증하고, 제품·ML·인프라 팀 사이에서 기술 판단 기준을 제시하고 의견을 조율합니다.

  이렇게 볼 수 있어요

  동료의 한마디에는 어느 구간이 몇 ms 줄었고 월 비용이 얼마나 내려갔는지로 판단한다는 말이 있습니다. 협업 경험을 쓸 때도 조율한 결과를 지연 시간이나 비용 같은 숫자로 보여 주면 됩니다.

2자격 요건

• LLM이나 ML 모델을 활용한 수천만 건 규모의 대용량 데이터 처리 파이프라인을 라이브 서비스 수준으로 설계하고 운영해 본 경험을 원합니다.

  이렇게 볼 수 있어요

  규모와 운영 수준이 함께 적혀 있습니다. 실험용 배치가 아니라 서비스에 걸린 파이프라인이었는지, 처리한 건수가 어느 정도였는지를 경력 항목마다 밝혀 두는 게 좋습니다.

• 요청과 결과를 분리한 비동기 구조나 대량 배치 처리로 대규모 트래픽을 다뤄 본 경험이 있으면 좋다고 적었습니다.

  이렇게 볼 수 있어요

  비동기 구조와 대량 배치 가운데 한 방식을 다뤄 봤다면 왜 동기 호출 대신 그 방식을 골랐는지까지 설명할 수 있어야 합니다.

• LLM 생태계를 이해하고, Pay-as-you-go, PTU, Batch API의 트레이드오프를 비용과 처리량 관점에서 판단할 수 있으면 좋다는 항목입니다.

  이렇게 볼 수 있어요

  자격 요건은 요금 방식을 고르는 판단을 따로 요구합니다. 같은 작업을 어떤 방식으로 돌렸을 때 비용과 처리 시간이 각각 어땠는지 비교한 기록이 있다면 그 표를 그대로 지원서에 옮길 수 있습니다.

• Rate Limit과 이중화, 장애 전환, Fallback/Retry를 직접 설계해 장애 상황에서도 파이프라인이 멈추지 않게 만들어 본 경험을 원합니다.

  이렇게 볼 수 있어요

  '직접 설계'가 조건입니다. 이미 있던 재시도 설정을 쓴 경험과 장애 전환 구조를 처음 만든 경험은 나눠 적는 편이 맡은 범위를 정확히 보여 줍니다.

• 처리량이 기대만큼 나오지 않을 때 어느 구간이 문제인지 숫자로 찾아내고, 무엇을 포기할지까지 정해 본 경험을 원합니다.

  이렇게 볼 수 있어요

  병목을 찾는 데서 끝나지 않고 무엇을 내줄지 정한 결정까지 묻습니다. 예를 들어 응답 속도를 조금 늦추고 처리량을 얻었다면 그 판단의 근거와 결과 숫자를 나란히 남겨 두는 편이 좋습니다.

• 여러 팀이 얽힌 상황에서 기술 판단 기준을 제시하고, 복잡한 내용을 이해하기 쉽게 설명하며 협업을 이끌어 본 경험을 원합니다.

  이렇게 볼 수 있어요

  업무 마지막 줄에 적힌 제품·ML·인프라 팀 사이 조율과 같은 요구입니다. 팀마다 원하는 것이 달랐던 상황에서 어떤 기준을 내놓아 결정을 이끌었는지를 한 사례로 정리해 두면 인터뷰에서도 꺼낼 수 있습니다.

3우대 사항

• 이미지와 텍스트가 함께 들어오는 멀티모달 파이프라인을 설계하고 운영해 본 경험

  이렇게 볼 수 있어요

  업무 첫 항목은 Vision 모델까지 조합하는 파이프라인을 다룹니다. Vision 모델과 텍스트 모델을 한 흐름에 묶어 본 경험이 있다면 어디서 지연이 생겼고 어떻게 줄였는지를 함께 적으면 됩니다.

• ML, LLM, Vision 모델의 동작 방식을 이해하고, 문제가 생겼을 때 직접 디버깅해 모델 코드까지 고칠 수 있는 역량

  이렇게 볼 수 있어요

  인프라만이 아니라 모델 코드까지 손대는 범위를 우대합니다. 추론 결과가 이상할 때 서빙 설정이 아니라 모델 쪽 원인을 찾아 고친 경험이 있다면 증상, 원인, 고친 내용을 순서대로 적는 편이 낫습니다.

• 사람이 하던 대량의 판단 업무를 LLM으로 자동화해 본 경험이 있으면 '특히 함께하고 싶어요'라고 적었습니다.

  이렇게 볼 수 있어요

  우대 항목 가운데 '특히'가 붙은 것은 이것 하나이고, 팀 소개의 미션과도 같은 일입니다. 자동화 전 사람이 처리하던 건수와 자동화 뒤 사람이 다시 확인하는 비율을 함께 남기면 규모가 드러납니다.

• 외부 모델 API와 함께 자체 모델을 서빙하면서 추론 성능을 최적화해 본 경험

  이렇게 볼 수 있어요

  외부 API와 자체 모델을 함께 운영했다면 지연 시간과 단가를 경로별로 나눠 비교한 기록이 도움이 됩니다.

4기타 사항

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

쓰는 기술

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

• LLM
• PTU
• Batch API

전형과 지원

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

지원 전 준비할 것

1. 1

   목적과 해결 과정을 먼저 쓰기

   이력서 안내는 어떤 언어, 플랫폼, 프레임워크를 썼는지보다 어떤 목적의 과제였는지, 무엇을 사용해 어떻게 해결했는지를 자세히 적어 달라고 했습니다. 파이프라인마다 처리 대상, 규모, 바꾼 구조를 순서대로 쓰고 기술 이름은 그 뒤에 붙이는 게 좋습니다.

2. 2

   장애 해결과 최적화 경험 고르기

   안내는 플랫폼을 운영하며 치명적인 장애를 해결했거나 성능·리소스를 최적화한 경험을 적어 달라고 했습니다. 동료의 한마디처럼 몇 ms가 줄었고 월 비용이 얼마나 내려갔는지를 숫자로 붙여 두면 됩니다.

3. 3

   오픈소스 기여 경험 정리하기

   오픈소스를 쓰다 생긴 버그나 이슈를 해결했거나 부족한 기능을 개선하려고 기여한 경험도 안내에 있습니다. 서빙 프레임워크나 배치 도구에 올린 이슈와 PR이 있다면 링크와 함께 무엇을 고쳤는지 한 줄로 적어 두세요.