[미리디] [미리캔버스] 응용 알고리즘 엔지니어 (Applied Algorithm Engineer) 공고 분석

이 자리가 왜 생겼을까요

1하게 될 업무

• 콘텐츠 구조를 분석해 원본 요소와 대체 요소 사이의 mapping / matching 로직을 설계하고 구현하며, tree, graph, hash, index 같은 자료구조로 콘텐츠 변환과 후보 탐색 문제를 제품 로직으로 모델링합니다.

  이렇게 볼 수 있어요

  템플릿 안의 원본 요소를 다른 콘텐츠로 바꿀 때 어느 요소끼리 대응하는지 정하는 로직을 만듭니다. 자료구조 이름이 업무에 그대로 적혀 있어, 실제 제품에서 tree나 graph로 푼 문제가 있다면 대표 사례가 됩니다.

• 대규모 데이터풀에서 유사하거나 대응 가능한 후보를 빠르게 찾기 위한 signature, indexing, pruning, deduplication 로직을 개발합니다.

  이렇게 볼 수 있어요

  같은 회사 Data Engineer 공고는 80억 건 이상 적재된 비정형 디자인 에셋 데이터를 다루고, 미리캔버스 템플릿은 50만 건입니다. 이런 규모에서 대응 후보를 찾는 업무로 짐작되므로, signature나 indexing으로 비교 대상을 줄여 응답 시간을 낮춘 경험이라면 줄이기 전후의 후보 수와 시간을 함께 적어 둘 만합니다.

• AI Agent와 workflow가 tool을 안정적으로 호출하도록 precondition, postcondition, invariant 기반의 harness를 설계하고, 잘못된 입력, 잘못된 실행 순서, 품질이 낮은 결과를 미리 걸러내는 linter / validation rule을 구현합니다.

  이렇게 볼 수 있어요

  기대 모습에는 입사 3개월 뒤 AI Agent나 자동화 파이프라인이 tool을 더 안정적으로 쓰도록 harness와 linter 구조를 개선하는 일이 적혀 있어, 이 업무는 합류 초기에 맡게 될 과제입니다. 사전·사후 조건이나 불변식을 코드로 검사해 잘못된 호출을 막아 봤다면 LLM이 아닌 시스템이었어도 그 규칙 설계를 사례로 들 수 있습니다.

• 결과물 품질을 판단하는 scoring, ranking, rule-based evaluation 로직을 만들어 실험 결과를 분석하고, 실패 케이스와 예외 상황을 모아 fallback policy를 정의해 제품에서 허용할 결과와 거절할 결과를 구분합니다.

  이렇게 볼 수 있어요

  AI 결과를 그대로 내보내지 않고 점수를 매겨 받아들일지 정합니다. 결과를 받아들일지 거절할지 정하는 기준을 직접 세워 본 경험이 여기에 쓰입니다.

• 기존 시스템 로직을 분석해 정확도, 속도, 안정성, 유지보수성을 개선하고, PoC 단계의 아이디어를 빠르게 구현해 실험 결과를 바탕으로 다음 개선 방향을 제안합니다.

  이렇게 볼 수 있어요

  미리디 CTO는 새 아이디어를 MVP로 빠르게 만들어 A/B 테스트로 검증하고 지표 변화가 확인된 기능만 정식으로 개발한다고 설명했고, 이 공고의 우대 사항에도 완성도보다 학습 속도를 우선한 실험 반복이 있습니다. PoC를 짧은 주기로 돌려 다음 방향을 정해 봤다면 몇 번의 시도 끝에 무엇을 남기고 무엇을 버렸는지가 이 업무에 가장 가까운 이야기입니다.

2자격 요건

• 소프트웨어 개발 경험이 있고, TypeScript 기반의 애플리케이션, 서버, worker, batch pipeline 가운데 하나 이상을 개발해 본 경험이 필요합니다.

  이렇게 볼 수 있어요

  경력 조건은 무관이지만 언어는 TypeScript로 정해져 있습니다. 맡을 matching·validation 로직도 TypeScript로 설계합니다. 우대 사항의 알고리즘 대회 경험은 보통 C++이나 Python으로 쌓입니다. 대회 쪽 경력이 중심이라면 TypeScript로 만든 서버·worker·batch 결과물 하나를 함께 보여 주면 두 경험이 이어집니다.

• 자료구조와 알고리즘을 단순 지식이 아니라 실제 제품 문제 해결에 적용해 본 경험을 요구합니다.

  이렇게 볼 수 있어요

  알고리즘 지식보다 제품에 적용한 사례를 봅니다. 알고리즘을 바꿔 제품의 속도나 정확도가 달라진 사례를 고릅니다.

• 복잡하고 모호한 요구사항을 작은 문제로 나누고 규칙·제약조건·예외 흐름으로 구조화할 수 있어야 합니다.

  이렇게 볼 수 있어요

  직무 소개는 처음에는 문제가 모호하게 느껴질 수 있다고 적었고, 입사 1개월 뒤 기대 모습도 matching, ranking, validation, fallback이 필요한 문제를 작은 단위로 나눠 설명하는 것입니다. 모호한 요구를 규칙과 예외 흐름으로 쪼개 구현한 경험이 있다면 처음 요구와 쪼갠 결과를 나란히 보여 줄 수 있습니다.

• API를 호출하는 수준을 넘어 실행 흐름, 입력 검증, 결과 검증, 실패 대응까지 함께 설계하는 역량을 요구합니다.

  이렇게 볼 수 있어요

  외부 API 실패에 대비한 재시도나 대체 경로를 설계한 경험이 이 요건에 맞습니다. 업무 목록의 harness와 fallback도 같은 문제를 다룹니다.

• 실험 결과나 로그에서 오류 패턴을 찾아내고 개선 가설을 코드로 검증하는 역량이 필요합니다.

  이렇게 볼 수 있어요

  업무에서 이 역량은 실패 케이스와 예외 상황을 모아 fallback policy를 정의하는 데 필요합니다. 템플릿 요소를 바꿔 넣은 결과라면 글자가 상자를 넘치거나 요소 대응이 어긋난 경우를 유형으로 묶습니다. 그 유형을 거르는 규칙을 코드로 만들고 결과를 다시 측정합니다. 로그에서 찾은 실패 유형을 규칙으로 바꾸고 수정 전후의 실패율을 비교해 본 경험이 있으면 분석과 구현을 한 사람이 이어서 맡았다는 점이 보입니다.

• Git 기반 협업과 코드 리뷰, 테스트 작성 같은 기본적인 개발 워크플로우에 익숙한 사람을 원합니다.

  이렇게 볼 수 있어요

  CTO는 미리디의 코드 리뷰를 '공동 퇴고'라고 부르고 몇 시간씩 코드를 훑으며 토론한다고 소개했습니다. 이 문화에서는 리뷰를 받은 경험만큼 남의 코드에 근거를 달아 의견을 남긴 경험도 중요합니다. 테스트는 어떤 범위까지 썼는지를 함께 밝힙니다. 입력 조건이나 불변식을 검사하는 테스트를 써 봤다면 업무의 precondition·postcondition 기반 harness와 이어 설명할 수 있습니다.

• PM, TPM, Software Engineer와 문제 정의와 해결 방향을 논리적으로 맞춰 갈 수 있는 사람을 원합니다.

  이렇게 볼 수 있어요

  같은 미리캔버스의 테크니컬 PM 공고는 자동 정렬, 스마트 리사이즈 같은 AI 기반 기능의 품질 기준을 정하는 일을 맡습니다. 그 공고는 PRD와 수용 기준, 결정 기록 같은 문서화도 자격 요건으로 요구합니다. 그 기준을 이 자리의 scoring·validation 규칙으로 옮기려면 허용할 결과와 거절할 결과의 경계를 두 직군이 함께 정해야 합니다. 기획 쪽이 말로 정한 기준을 측정 가능한 규칙으로 바꾸거나, 기술 제약 때문에 요구 범위를 다시 정해 본 경험을 하나 골라 준비합니다.

3우대 사항

• graph matching, tree matching, tree edit distance, bipartite matching, assignment problem, constraint solving 가운데 하나 이상을 다뤄 본 경험을 우대합니다.

  이렇게 볼 수 있어요

  기법 이름이 여섯 개 적혀 있고 그중 하나만 다뤄 봤어도 우대에 들어갑니다. 업무의 매칭 로직에 쓰이는 것은 기법 이름보다 그 기법으로 푼 문제입니다.

• ranking logic, scoring function, rule engine, validation logic, lint rule을 직접 설계하거나 구현해 본 경험을 우대합니다.

  이렇게 볼 수 있어요

  우대 사항의 ranking·scoring·lint rule은 업무에 적힌 결과 품질 판단과 linter / validation rule 구현에 그대로 쓰이는 경험입니다. 직접 만든 scoring 함수나 lint rule이 있다면 어떤 잘못된 결과를 걸러냈고 오탐을 어떻게 줄였는지까지 밝혀 둘 수 있습니다.

• hash, indexing, deduplication, search optimization, candidate pruning, reranking 관련 문제를 다뤄 본 경험을 우대하고, 콘텐츠 변환, 데이터 매핑, 추천, 검색, 랭킹, 매칭 문제를 제품 환경에서 풀어 본 경험도 우대합니다.

  이렇게 볼 수 있어요

  이 우대 사항은 업무에 있는 후보 탐색 로직과 같은 문제를 다룹니다. 검색이나 추천 시스템 경력이라도 다룬 데이터 규모와 써 본 기법에 따라 이 목록과 일치하는 정도가 다릅니다.

• AI Agent, tool calling, workflow orchestration, guardrail, fallback logic을 설계해 본 경험을 우대하고, LLM 기반 작업의 입력·출력 검증, 품질 평가, hallucination 방지 로직을 고민해 본 경험도 우대합니다.

  이렇게 볼 수 있어요

  우대 사항이 에이전트 설계와 함께 입력·출력 검증, 품질 평가, hallucination 방지를 나란히 적어, LLM 경험 가운데서도 결과를 검증한 방식에 무게가 실린 항목입니다. 업무의 fallback policy처럼 모델 결과를 거절하거나 대체한 기준을 만들어 봤다면 그 기준을 만든 과정이 이 우대에 가장 잘 맞는 경험입니다.

• 수학, 컴퓨터공학, 알고리즘 문제 해결, 올림피아드, 프로그래밍 대회 등 논리적 난제 해결에 깊게 몰입해 본 경험을 우대합니다.

  이렇게 볼 수 있어요

  경력 조건은 무관이고 1차 인터뷰에서 약 1시간짜리 라이브 과제를 풀게 되어 있어, 알고리즘 문제를 제한된 시간 안에 구조화하는 힘이 전형에서 바로 확인됩니다. 올림피아드나 프로그래밍 대회에서 푼 문제 가운데 tree·graph 매칭이나 탐색 문제가 있다면 업무의 콘텐츠 구조 문제와 이어 설명하는 편이 좋습니다.

• 빠르게 PoC를 만들고 완성도보다 학습 속도를 우선해 실험을 반복해 본 경험을 우대합니다.

  이렇게 볼 수 있어요

  같은 공고가 자격 요건으로 코드 리뷰와 테스트 작성을 요구합니다. 그래서 이 우대가 말하는 속도는 PoC 단계에 한정된 것으로 보는 편이 맞습니다. PoC로 빠르게 버린 시도와, 살아남은 아이디어를 리뷰와 테스트를 거친 제품 코드로 옮긴 과정을 함께 보여 주면 두 요구를 어떻게 나눠 썼는지가 보입니다. 몇 번 반복했고 무엇을 배워 다음 시도에 반영했는지도 함께 적을 수 있습니다.

4기타 사항

• 게시일 : 2026년 7월 9일
• 고용형태 : 정규직(수습 3개월)
• 근무지 : 대한민국 서울특별시 구로구 구로동 197-21 8층 미리디
• 경력 조건 : 경력 무관
• 학력 조건 : 해당 내용은 원본 공고에서 확인되지 않습니다.

쓰는 기술

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

• TypeScript
• Git

전형과 지원

미리디 전형은 네 단계이고 직군에 따라 코딩 테스트나 과제가 붙습니다. 채용 FAQ가 과거 지원과 무관하게 재지원할 수 있다고 밝혔고(공고에는 같은 포지션은 6개월 뒤 재지원 단서가 있습니다), CTO가 서류에서 무엇을 보는지도 공개돼 있습니다.

지원 전 준비할 것

1. 1

   제품에 적용한 알고리즘 사례 고르기

   자격 요건이 자료구조와 알고리즘을 실제 제품 문제에 적용한 경험을 요구합니다. 어떤 문제를 어떤 구조로 모델링했고 결과가 어떻게 달라졌는지 하나의 사례로 정리합니다.

2. 2

   라이브 과제 대비하기

   1차 인터뷰에서 콘텐츠 구조와 디자인 구조를 매칭하는 과제를 약 1시간 동안 실시간으로 풉니다. tree나 graph 매칭 문제를 TypeScript로 짧게 구현해 보고, 풀면서 판단 근거를 말로 설명하는 연습을 합니다.

3. 3

   검증과 실패 대응을 설계한 경험 정리하기

   입력 검증, 결과 검증, 실패 대응이 자격 요건과 업무에 반복해서 나옵니다. 잘못된 입력이나 결과를 걸러낸 규칙과 실패했을 때의 대체 경로를 만든 사례를 정리해 둡니다.

4. 4

   미리캔버스 편집기 직접 써 보기

   원본 요소를 대체 요소로 바꾸는 로직을 맡습니다. 미리캔버스에서 템플릿을 골라 내용을 바꿔 보며 어떤 요소가 유지되고 바뀌는지 확인해 두면 인터뷰에서 쓸 수 있습니다.