[토스] AI 플랫폼 엔지니어 (Retrieval) (AI Platform Engineer) 공고 분석

이 자리가 왜 생겼을까요

1하게 될 업무

• 도메인이 검색과 탐색을 스스로 구성할 수 있게 만듭니다. 요청을 받아 처리하는 일을 기능으로 바꿔 같은 요청이 다시 오지 않게 하는 것이 핵심입니다.

  이렇게 볼 수 있어요

  팀 소개는 검색 플랫폼이 지원하는 서비스와 데이터 규모가 함께 늘어 요청을 하나씩 받아 처리하는 방식으로는 따라갈 수 없다고 설명했습니다. 이 업무에서는 팀이 중심 과제로 꼽은 일을 맡아 요청을 하나씩 처리하던 방식을 도메인이 직접 쓰는 설정과 API로 바꿉니다. 검색 플랫폼에 반복해서 들어오는 요청은 보통 색인 추가, 분석기 설정, 필터 조정 같은 것입니다. 반복 요청을 유형별로 묶어 셀프서비스로 바꾼 경험은 어떤 요청 유형이 사라졌는지와 함께 쓸 때 이 업무의 사례가 됩니다.

• 검색, 추천, 광고 서비스가 사용할 리트리벌 API를 만들고 서비스별 후보 생성 방식과 필터 조건을 반영해 확장합니다.

  이렇게 볼 수 있어요

  검색은 질의에 맞는 문서를 찾고, 추천은 사용자와 가까운 후보를 넉넉히 뽑아 뒤 단계가 줄이며, 광고는 예산과 타게팅 조건으로 후보를 거릅니다. 그래서 하나의 리트리벌 API가 세 서비스의 서로 다른 필터와 점수 방식을 함께 받게 됩니다. 팀 소개도 후보 생성을 검색 서비스에 한정하지 않는다고 적었습니다. 서비스마다 다른 조건을 한 API에서 받도록 설계해 본 경험이 있다면 어떤 조건이 서비스별로 달랐는지부터 꺼낼 수 있습니다.

• Elasticsearch, Milvus 등 검색 엔진의 특성과 한계를 이해한 상태로 도메인을 지원합니다. 색인 설계, 샤드 배치, 형태소 분석기 설정, ANN 인덱스 종류와 파라미터 설정, 파티셔닝, 용량 산정 및 증설 계획도 함께 진행합니다.

  이렇게 볼 수 있어요

  현업에서 한국어 검색은 형태소 분석기 설정에 따라 같은 질의의 결과가 크게 달라집니다. ANN 인덱스는 종류와 파라미터에 따라 재현율과 지연 시간 가운데 하나를 높이면 다른 하나를 내주게 됩니다. 어떤 엔진에서 어떤 값을 바꿔 무엇이 달라졌는지를 설정 이름과 함께 적으면 이 항목에서 다룬 깊이가 드러납니다.

• 하이브리드 검색을 설계하고 플랫폼 기능으로 제공합니다. 두 점수를 어떤 방식으로 섞을지, 그 결과가 도메인마다 달라지는 문제를 어떻게 다룰지가 지금 풀어야 하는 과제입니다.

  이렇게 볼 수 있어요

  키워드 검색 점수와 벡터 유사도는 값의 범위가 달라 단순 합산이 어렵습니다. 현업에서는 점수를 정규화해 가중합하거나 순위만 합치는 방식(RRF 등)을 씁니다. 공고는 두 점수를 섞는 방식과 그 결과가 도메인마다 달라지는 문제를 아직 풀어야 할 과제로 꼽았습니다. 두 방식을 실제 질의로 비교해 본 경험이 있다면, 어느 질의 유형에서 어느 쪽이 나았는지가 이 과제에 대한 자기 답이 됩니다.

• 사내 도구와 작은 서비스를 위해 RAG를 플랫폼으로 제공합니다.

  이렇게 볼 수 있어요

  팀 소개는 사내 AI 에이전트에게 지식을 전달하는 일도 검색의 범위로 꼽았습니다. 서비스 검색은 질의 하나에 결과 목록을 돌려주지만, RAG는 모델이 참고할 문서 조각을 돌려줍니다. 그래서 문서를 나누는 단위와 임베딩 모델 선택이 답변 품질을 좌우합니다. 사내 도구용 RAG를 만들며 문서 분할 단위나 임베딩 모델을 바꿔 답변 품질이 달라진 경험이 있다면 그 비교가 이 업무와 가장 가깝습니다.

2자격 요건

• 사용하는 팀과 직접 대화하며 결과를 만든 경험이 있으면 좋다고 적었습니다. 요구를 그대로 받아들이기보다 스스로 해석해 중요한 것에 집중하고, 무엇을 공통화해 일반화할지 고민해 본 사람을 찾습니다.

  이렇게 볼 수 있어요

  이 요건은 첫 번째 업무가 핵심으로 적은 '요청을 받아 처리하는 일을 기능으로 바꿔서, 같은 요청이 다시 오지 않게 하는 것'과 같은 방향의 요구입니다. 요건의 '공통화하여 일반화'는 도메인마다 다른 모양으로 온 요청을 한 기능의 설정으로 묶는 판단을 가리킵니다. 검색 플랫폼에서는 서비스마다 색인 추가나 필터 조정을 각자 요청해도 뿌리가 같은 경우가 많아, 요청대로 하나씩 만들면 분기만 늘어납니다. 도메인 두세 곳의 요청이 같은 원인에서 나왔던 적이 있다면, 하나로 묶은 기능과 그 뒤 같은 요청이 다시 오지 않았는지를 사례로 적을 수 있습니다.

• 서비스마다 다른 요구를 검색 엔진의 특성과 구조를 고려해 풀어 본 경험이 있으면 좋다고 적었습니다. 데이터 규모와 유사성 검색 등을 고려해 검색 엔진을 설계하고 운영해 봤다면 더 좋다고 덧붙였습니다.

  이렇게 볼 수 있어요

  같은 요구가 Elasticsearch에서는 샤드와 분석기 문제였고 벡터 검색에서는 인덱스 종류 문제였다면 이 요건은 어느 쪽 특성으로 풀었는지를 묻습니다. 팀 소개가 수십억 건 규모 색인을 다룬다고 적었으므로 문서 수와 질의량을 함께 적어야 규모가 전해집니다.

• 검색 엔진이나 벡터 데이터베이스를 실제 서비스에서 사용해 색인이나 컬렉션을 설계하고, 성능 문제의 원인을 끝까지 좁힐 수 있는 사람을 찾고 있다고 적었습니다.

  이렇게 볼 수 있어요

  느려진 검색의 원인은 샤드 쏠림, 분석기 설정, 필터 캐시, 벡터 인덱스 파라미터처럼 층이 여럿입니다. 요건의 '끝까지 좁힐 수 있는'은 이 가운데 어느 층까지 내려가 원인을 찾았는지를 묻는 말입니다. 이력서 안내도 치명적인 장애 해결과 성능·리소스 최적화 경험을 적어 달라고 했으므로 같은 사례 하나를 이 요건에도 쓸 수 있습니다.

• 여러 팀이 얽힌 문제를 끝까지 해결해 본 경험이 있으면 좋다고 적었습니다. 검색은 데이터와 모델을 만드는 팀이 함께 완성하므로 원인이 팀 밖에 있어도 함께 확인하고 해결해야 할 때가 많다고 설명합니다.

  이렇게 볼 수 있어요

  토스 커머스 쪽에는 ML Engineer (Search Relevance) 공고처럼 relevance 판단 모델을 따로 맡는 팀이 있습니다. 검색 결과의 품질은 그만큼 색인 팀 혼자 바꿀 수 없는 층에도 걸려 있습니다. 결과가 나빠 보일 때 색인이 아니라 모델이나 데이터에 원인이 있었던 경험이 있다면 누구와 어떻게 확인해 해결했는지가 이 요건에 맞습니다.

3우대 사항

• 추천이나 광고 시스템에서 후보군을 뽑는 리트리벌 단계를 다뤄 본 경험이 있으면 좋다고 적었습니다.

  이렇게 볼 수 있어요

  이 우대 경험은 업무에 적힌 추천과 광고의 후보 생성에 쓰입니다. 추천에서는 후보를 넉넉히 뽑은 뒤 랭킹이 줄이는 구조라, 리트리벌 단계는 재현율과 지연을 함께 맞춰야 하는 단계입니다. 후보 수와 지연 시간 제약 안에서 후보 생성 방식을 고른 경험이 이 우대와 가깝습니다.

• 여러 서비스가 하나의 클러스터를 함께 쓰는 환경에서 한 서비스의 부하가 다른 서비스로 번지지 않도록 격리를 설계해 본 경험이 있으면 반갑다고 적었습니다.

  이렇게 볼 수 있어요

  도메인이 검색을 직접 구성하는 플랫폼에서는 한 도메인의 무거운 질의나 대량 색인이 공유 클러스터의 다른 도메인 응답을 늦출 수 있습니다. 현업에서는 서비스별 질의 쿼터, 인덱스와 노드 분리, 대량 작업의 시간대 분리로 막습니다. 어떤 방식으로 격리했고 격리 뒤 다른 서비스의 지연이 어떻게 달라졌는지까지 말하면 격리를 설계했다는 점이 전해집니다.

• 하이브리드 검색을 설계하거나 운영해 본 경험이 있으면 환영한다고 적었습니다.

  이렇게 볼 수 있어요

  업무에서 '지금 열려 있는 과제'라고 쓴 두 점수의 결합이 이 우대와 같은 문제입니다. 현업에서는 상품명처럼 글자가 일치해야 하는 질의와 뜻이 비슷한 문서를 찾는 질의에서 알맞은 가중치가 달라 한 값으로 고정하기 어렵고, 서비스가 늘수록 그 차이도 늘어납니다. 운영 경험이 있다면 어떤 결합 방식을 썼는지와 질의 유형별로 한쪽이 더 나았던 사례를 적을 수 있습니다.

• 모델 서빙(Triton 등)과 검색 시스템을 연결해 본 경험이 있으면 환영한다고 적었습니다. 벡터 검색이 모델 추론과 맞물려 있어서 추론 쪽 경로에 대한 배경이 있으면 훨씬 수월할 것이라고 설명합니다.

  이렇게 볼 수 있어요

  질의를 벡터로 바꾸는 임베딩 추론이 검색 경로 안에 있어 추론 서버가 느려지면 검색 지연이 함께 늘어납니다. 토스 AI Platform Engineer (Inference Pipeline) 공고는 모델 서빙 쪽에서 비동기 구조와 장애 전환 설계를 업무로 적었습니다. 임베딩 추론 서버와 벡터 검색 사이의 지연과 장애 전파를 다뤄 본 경험이 있다면 어느 구간을 줄였는지가 이 우대의 경험을 보여 줍니다.

• 임베딩 모델을 다뤄 보거나 RAG 시스템을 직접 구성해 본 경험이 있으면 좋다고 적었습니다.

  이렇게 볼 수 있어요

  이 우대는 업무에 적힌 사내 RAG 플랫폼 제공과 이어집니다. 임베딩 모델을 골라 봤다면 후보 모델과 평가 질의 세트, 고른 이유를 적을 수 있고, RAG를 구성했다면 문서를 나눈 단위와 검색 결과를 모델에 넘기는 방식까지 쓸 수 있습니다. 토스 AI Engineer (Model) 공고는 외부 상용 LLM을 자체 학습 모델로 내재화하는 일을 소개했습니다. 이 공고의 업무는 모델 학습이 아니라 모델을 검색에 연결하는 쪽입니다.

4기타 사항

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

쓰는 기술

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

• Elasticsearch
• Milvus
• Triton
• RAG

전형과 지원

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

지원 전 준비할 것

1. 1

   과제의 목적과 해결 방법을 먼저 쓰기

   이력서 안내는 어떤 언어와 프레임워크를 썼는지보다 어떤 목적의 과제였고 무엇으로 어떻게 풀었는지를 자세히 적어 달라고 했습니다. 검색 과제마다 처리한 문서 수와 질의량을 먼저 쓰고 엔진과 설정 이름은 그 뒤에 붙이세요.

2. 2

   장애 해결과 최적화 사례 한 건 고르기

   안내는 플랫폼을 운영하며 치명적인 장애를 해결했거나 성능과 리소스를 최적화한 경험을 적어 달라고 했습니다. 동료의 한마디가 지연이 얼마나 줄었고 처리량이 얼마나 늘었는지로 판단한다고 적었으므로 전후 수치가 남아 있는 사례를 고릅니다.

3. 3

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

   안내는 오픈소스를 쓰다 만난 버그나 이슈를 해결했거나 부족한 기능을 개선하려고 기여한 경험도 적어 달라고 했습니다. Elasticsearch나 벡터 DB 쪽 이슈와 PR이 있다면 링크와 고친 내용을 한 줄로 정리합니다.