이 자리가 왜 생겼을까요
미리디는 채용 FAQ에서 병역지정업체라고 밝히며 요건을 갖추면 병무청에 편입 신청을 진행하지만 TO 제한으로 모든 지원자에게 편입을 보장하기는 어렵다고 안내합니다. 이 공고는 미리캔버스가 사용자의 의도와 콘텐츠 구조를 이해해 더 나은 결과물을 제안하는 제품으로 나아가고 있고, 가장 어려운 문제는 AI가 무언가를 생성한 다음부터 시작된다고 소개합니다. 미리디 에디터팀 리드도 2026년 7월 테크M 인터뷰에서 AI가 만든 결과물을 손쉽게 편집할 수 있는 구조를 만드는 것을 목표로 꼽았습니다. 분석 시점 채용 사이트에는 같은 업무의 일반 공고와 이 산업기능요원·전문연구요원 공고가 함께 올라와 있었으므로, 편입을 원한다면 편입 안내가 붙은 이 공고로 지원하고 본인의 편입 구분을 지원서에 밝혀 두는 편이 안전합니다.
미리디가 지금 어떤 사업에 집중하고 있는지는 미리디 채용 분석에서 이어서 볼 수 있습니다.
1하게 될 업무
콘텐츠 구조를 분석해 원본 요소와 대체 요소 간의 mapping / matching 로직을 설계·구현하고, tree, graph, hash, index 등 자료구조를 활용해 콘텐츠 변환과 후보 탐색 문제를 제품 로직으로 모델링합니다.
이렇게 볼 수 있어요
기대 모습의 마지막 단계도 원본 콘텐츠와 대체 콘텐츠 사이의 대응 관계를 정의하는 일입니다. 학교 과제나 연구에서 트리 구조 데이터를 비교하거나 대응시키는 문제를 풀어 봤다면 그 문제를 템플릿 요소 교체 같은 제품 상황에 옮겨 설명할 수 있습니다.
대규모 데이터풀에서 유사하거나 대응 가능한 후보를 빠르게 찾기 위한 signature, indexing, pruning, deduplication 로직을 개발합니다.
이렇게 볼 수 있어요
그 이후 단계의 기대 모습에 대규모 후보군에서도 빠르고 안정적으로 동작하는 검색·매칭·랭킹 구조가 있습니다. 해시 서명이나 색인, 가지치기로 비교 대상을 줄여 탐색 시간을 줄여 본 경험은 그 구조를 만드는 데 바로 필요합니다.
AI Agent와 workflow가 tool을 안정적으로 호출할 수 있도록 precondition, postcondition, invariant 기반의 harness를 설계하고, 잘못된 입력, 잘못된 실행 순서, 품질이 낮은 결과를 사전에 걸러내는 linter / validation rule을 구현합니다.
이렇게 볼 수 있어요
3개월 뒤 기대 모습에 harness와 linter 구조 개선이 적혀 있습니다. 함수의 사전·사후 조건을 검사하는 코드나 정적 검사 규칙을 만들어 본 경험은 LLM을 다루지 않았더라도 이 harness와 linter 설계에 가깝습니다.
결과물의 품질을 판단하는 scoring, ranking, rule-based evaluation 로직을 만들고 실험 결과를 분석하며, 실패 케이스와 예외 상황을 수집해 fallback policy를 정의하고 제품에서 허용 가능한 결과와 거절해야 하는 결과를 구분합니다.
이렇게 볼 수 있어요
직무 소개는 어떤 결과를 제품 안에서 실제로 써도 되는지 판단하는 로직이 필요하다고 적었습니다. 결과를 거절했을 때 무엇을 대신 보여 줄지까지 정해 본 경험이 있다면 그 규칙과 예외 목록을 예로 들 수 있습니다.
기존 시스템 로직을 분석해 정확도, 속도, 안정성, 유지보수성을 개선하고, PoC 단계의 아이디어를 빠르게 구현해 실험 결과를 바탕으로 다음 개선 방향을 제안합니다.
이렇게 볼 수 있어요
남이 짠 코드를 분석해 병목을 찾고 고쳐 본 경험이 있다면 정확도, 속도, 안정성, 유지보수성 가운데 무엇이 얼마나 나아졌는지 나눠 설명하는 편이 좋습니다.
2자격 요건
소프트웨어 개발 경험과 TypeScript 기반의 애플리케이션, 서버, worker, batch pipeline 가운데 하나 이상의 개발 경험을 요구합니다.
이렇게 볼 수 있어요
TypeScript로 만든 서버나 배치 작업이 연구실이나 개인 프로젝트에서 나온 것이라도 실제로 돌려 본 결과물이라면 저장소 링크와 맡은 범위를 함께 적을 수 있습니다.
자료구조와 알고리즘을 단순 지식이 아니라 실제 제품 문제 해결에 적용해 본 경험이 필요합니다.
이렇게 볼 수 있어요
올림피아드나 프로그래밍 대회 경험은 우대 사항에 따로 있고, 이 요건은 제품 문제에 적용한 경험을 묻습니다. 대회에서 익힌 기법을 서비스 코드의 느린 부분에 적용해 본 사례가 있다면 두 경험을 이어 보여 줄 수 있습니다.
복잡하고 모호한 요구사항을 작은 문제로 분해하고 규칙·제약조건·예외 흐름으로 구조화할 수 있어야 합니다.
이렇게 볼 수 있어요
1개월 뒤 기대 모습이 matching, ranking, validation, fallback이 필요한 문제를 작은 단위로 나눠 설명하는 것입니다. 정의가 흐린 과제를 받아 하위 문제와 예외 목록으로 쪼갠 설계 문서나 이슈 정리는 이 요건에 대한 직접 근거입니다.
API를 호출하는 수준을 넘어 실행 흐름, 입력 검증, 결과 검증, 실패 대응까지 함께 설계할 수 있어야 합니다.
이렇게 볼 수 있어요
업무의 harness와 fallback policy가 이 요건을 실제 일로 옮긴 것입니다. 외부 호출이 실패하거나 엉뚱한 값을 돌려줬을 때 무엇을 막을지 직접 설계해 본 경험에서 이 역량이 드러납니다.
실험 결과나 로그를 보고 오류 패턴을 찾아내고 개선 가설을 코드로 검증할 수 있어야 합니다.
이렇게 볼 수 있어요
업무에 실패 케이스와 예외 상황을 수집해 fallback policy를 정의하는 일이 있습니다. 로그에서 찾은 실패 유형을 규칙으로 바꾸고 다시 측정해 본 과정을 한 흐름으로 정리할 수 있습니다.
Git 기반 협업과 코드 리뷰, 테스트 작성 등 기본적인 개발 워크플로우에 익숙해야 합니다.
이렇게 볼 수 있어요
CTO는 미리디의 코드 리뷰를 몇 시간씩 코드를 훑으며 토론하는 '공동 퇴고'로 설명했습니다. 인턴도 정직원과 똑같이 리뷰를 받는다고 밝혔습니다. 경력 무관 공고라 회사 경력이 없다면 공개 저장소에서 리뷰를 주고받거나 테스트를 붙여 기여한 기록이 이 요건을 보여 줍니다. 리뷰 의견을 받아 설계를 바꾼 PR이나 조건을 검사하는 테스트를 써 본 경험은 업무의 harness·validation rule 설계와도 관련됩니다.
PM, TPM, Software Engineer와 문제 정의와 해결 방향을 논리적으로 맞춰 갈 수 있어야 합니다.
이렇게 볼 수 있어요
직무 소개는 세 직군과 함께 '이 판단을 어떤 구조로 모델링해야 안전하게 확장될 수 있는가'를 고민한다고 적었습니다. 기획 쪽 요구를 기술 제약에 맞춰 범위를 다시 정해 본 경험이 이 협업에 해당합니다.
3우대 사항
graph matching, tree matching, tree edit distance, bipartite matching, assignment problem, constraint solving 가운데 하나 이상을 다뤄 본 경험을 우대합니다.
이렇게 볼 수 있어요
1차 인터뷰의 라이브 과제가 콘텐츠 구조와 디자인 구조를 매칭하는 설계·구현 문제입니다. tree edit distance나 bipartite matching을 구현해 본 적이 있다면 각 기법을 어떤 문제에 썼는지 정리하는 것이 곧 라이브 과제 준비입니다.
ranking logic, scoring function, rule engine, validation logic, lint rule을 직접 설계하거나 구현해 본 경험을 우대합니다.
이렇게 볼 수 있어요
업무의 scoring·ranking 로직과 linter / validation rule 구현을 직접 해 본 경험이 이 우대 사항에 해당합니다. 직접 만든 규칙이 정상 결과를 잘못 걸러낸 일이 있었다면 그 규칙을 어떻게 고쳤는지까지 설명할 수 있습니다.
hash, indexing, deduplication, search optimization, candidate pruning, reranking 관련 문제를 다뤄 본 경험과 콘텐츠 변환, 데이터 매핑, 추천, 검색, 랭킹, 매칭 문제를 제품 환경에서 풀어 본 경험을 우대합니다.
이렇게 볼 수 있어요
우대 목록의 indexing, deduplication 같은 기법은 후보 탐색 업무의 signature, indexing, pruning, deduplication 로직을 그대로 다룹니다. 추천이나 검색 서비스에서 후보를 줄이고 다시 정렬하는 단계를 맡아 봤다면 처리한 후보 수와 응답 시간을 함께 밝힐 수 있습니다.
AI Agent, tool calling, workflow orchestration, guardrail, fallback logic을 설계해 본 경험과 LLM 기반 작업의 입력·출력 검증, 품질 평가, hallucination 방지 로직을 고민해 본 경험을 우대합니다.
이렇게 볼 수 있어요
직무 소개는 AI가 무언가를 생성한 다음부터 가장 어려운 문제가 시작된다고 적었습니다. LLM 출력을 스키마로 검사하거나 사실과 다른 내용을 걸러낸 규칙을 만들어 봤다면 막은 오류 유형이 이 우대 사항에 대한 답입니다.
수학, 컴퓨터공학, 알고리즘 문제 해결, 올림피아드, 프로그래밍 대회 등 논리적 난제 해결에 깊게 몰입해 본 경험을 우대합니다.
이렇게 볼 수 있어요
대회나 연구에서 오래 붙잡고 푼 문제가 있다면 그 문제를 어떻게 규칙과 제약으로 바꿨는지가 직무 소개의 '어려운 문제를 오래 붙잡고, 규칙을 세우고'와 이어집니다.
빠르게 PoC를 만들고 완성도보다 학습 속도를 우선해 실험을 반복해 본 경험을 우대합니다.
이렇게 볼 수 있어요
업무에 PoC 단계 아이디어를 빠르게 구현하고 실험 결과로 다음 방향을 제안하는 일이 있습니다. 버린 시도까지 포함해 몇 번 만에 방향을 정했는지를 숫자로 적어 이 우대 사항이 말하는 학습 속도를 보일 수 있습니다.
4기타 사항
- 게시일 : 2026년 8월 31일
- 고용형태 : 정규직(수습 3개월)
- 근무지 : 대한민국 서울특별시 구로구 구로동 197-21 8층 미리디
- 경력 조건 : 경력 무관
- 학력 조건 : 해당 내용은 원본 공고에서 확인되지 않습니다.
쓰는 기술
공고 본문에 적힌 기술만 모은 목록입니다.
- TypeScript
- Git
전형과 지원
미리디 전형은 네 단계이고 직군에 따라 코딩 테스트나 과제가 붙습니다. 채용 FAQ가 과거 지원과 무관하게 재지원할 수 있다고 밝혔고(공고에는 같은 포지션은 6개월 뒤 재지원 단서가 있습니다), CTO가 서류에서 무엇을 보는지도 공개돼 있습니다.
네 단계
서류전형, 1차 인터뷰, 2차 인터뷰, 최종 합격 순입니다. 1차는 "실무진과 직무별 인터뷰어가 참석하여 직무 역량을 심층 검증"하고 2차는 "리더 및 임원진이 참석하여 조직 적합도와 잠재력을 심층 검증"합니다. 최종 합격 뒤 처우 협의를 거치고 입사 후 3개월 수습 기간이 있습니다. 공고에 따라 인터뷰 전후로 레퍼런스 체크가 필수 단계로 들어가거나 추가될 수 있다고 적혀 있습니다.
이렇게 볼 수 있어요
1차와 2차에서 보는 것이 다릅니다. 1차는 공고의 업무와 자격 요건에 맞춰 준비하고, 2차는 핵심가치 세 묶음에 각각 대응하는 사례를 준비하는 편이 효율적입니다. 다만 DevOps Part Lead 공고는 2차 인터뷰를 '지원자 경력 기반의 직무 인터뷰'로 적었으므로, 지원할 공고의 기타사항에 적힌 인터뷰 설명을 함께 확인합니다.
코딩 테스트와 과제는 직군에 따라
"직군과 경력에 따라 [코딩테스트], [과제 전형]이 추가될 수 있으며, [2차 인터뷰]가 생략될 수 있습니다"라고 밝혔습니다. 코딩 테스트는 1차 인터뷰 앞에 붙습니다. 결과는 "최대 2주 내에 등록하신 이메일 주소로 개별 통보"합니다. 공고에는 서류 전형 결과 안내까지 최대 2주, 인터뷰 결과 안내까지 최대 3주가 걸린다고 적혀 있습니다.
이렇게 볼 수 있어요
단계 수가 공고마다 달라지므로 일정을 넉넉히 잡아야 합니다. 개발 직군으로 지원한다면 서류를 내는 시점에 코딩 테스트가 붙을 수 있다고 보고 준비 시간을 함께 확보해 둡니다.
다른 포지션에는 바로 다시 지원할 수 있습니다
채용 FAQ에 "미리디는 모든 인재를 잠재동료로 바라봅니다. 과거의 지원과 무관하게 재지원이 가능합니다"라고 적혀 있습니다. 여러 공고에 동시에 넣는 것도 "지원하고자 하는 직무에 대한 자격요건에 부합하시면" 가능합니다.
이렇게 볼 수 있어요
한 번 떨어진 것이 다른 포지션 지원을 막지 않습니다. 다만 여러 공고는 같은 포지션에 대해 최종 결과 안내를 받은 시점부터 6개월 뒤에 다시 지원할 수 있다고 따로 적었습니다. 컬처핏 단계 이후 1년을 제한하는 회사들과 반대 방향이라, 준비가 덜 됐더라도 먼저 넣어 보고 다음을 노리는 선택이 가능합니다.
지원서는 자유 양식이고 수정이 안 됩니다
"입사 지원서는 자유 양식입니다"라고 밝히면서 "제출한 지원서는 수정이 불가능합니다. 즉시 수정된 자료를 첨부하여 다시 지원하시면, 가장 최근 제출된 지원서를 바탕으로 검토가 이루어집니다"라고 안내합니다. 공고에는 "원활한 검토를 위해 PDF 형식으로 제출"을 요청하는 문구가 함께 적혀 있습니다.
이렇게 볼 수 있어요
고칠 기회가 없으므로 내기 전에 한 번 더 읽어야 합니다. 양식을 맞출 필요가 없는 대신 무엇을 강조할지가 온전히 선택이라, 공고의 업무 목록에 나온 일을 해 본 경험을 자세히 쓰는 편이 낫습니다.
CTO 인터뷰가 전하는 서류 기준
CTO 인터뷰 기사는 채용에서 보는 것을 "경험의 목록이 아니라, 그 경험의 깊이가 중요합니다"로 정리하고 "'무엇을 만들었다'가 아니라 '어떤 선택을 했고, 그 선택이 왜 최선이었는가'가 중요합니다"라고 전합니다. CTO는 "'그런 문제가 없었어요'라고 답하면, '그래서 그 문제를 고민도 안 하셨어요?'라고 되묻습니다"라는 예를 들었습니다.
이렇게 볼 수 있어요
쓴 기술을 늘어놓은 이력서는 이 기준에서 확인할 것이 적습니다. 프로젝트마다 갈림길 하나를 골라 어떤 선택지가 있었고 왜 그것을 골랐는지를 한 문장씩 붙여 두면 서류와 인터뷰가 같은 이야기를 하게 됩니다.
병역지정업체
미리디는 병역지정업체이고 "요건을 갖춘 경우 병무청에 편입 신청이 진행됩니다"라고 밝혔습니다. 다만 "TO 제한으로 인해 모든 지원자에게 편입을 보장해드리는 것은 어렵습니다"라는 단서가 붙습니다. 산업기능요원과 전문연구요원은 모두 "전직 요건을 갖추면 누구나 전직 지원이 가능"합니다.
이렇게 볼 수 있어요
편입 자리가 정해져 있으므로 일반 공고에 지원하면서 편입을 기대하기보다 미리 확인하는 편이 안전합니다. 실제로 일부 공고는 제목에 산업기능요원과 전문연구요원 여부를 따로 밝혀 두었습니다.
이 공고만 다른 점
1차 인터뷰 시간 가운데 약 1시간 동안 콘텐츠 구조와 디자인 구조를 매칭하는 작은 규모의 설계·구현 라이브 과제를 실시간으로 진행합니다.
회사 공통 안내의 별도 과제 전형 대신 인터뷰 시간 안에 과제가 들어 있습니다. 공고는 평소 생각과 작업 스타일을 편안하게 보여 주면 된다고 안내하므로, 완성된 답보다 매칭 기준을 세우는 과정을 말로 풀며 구현하는 연습이 맞는 준비입니다.
편입 안내에 따르면 산업기능요원은 보충역 신규 편입 및 전직이, 전문연구요원은 현역, 보충역 신규 편입 및 전직이 가능합니다.
회사 채용 FAQ는 TO 제한으로 모든 지원자에게 편입을 보장하기는 어렵다고 적었습니다. 본인이 어느 구분에 해당하는지와, 전직이라면 현재 복무 기간을 지원 단계에서 정리해 두면 편입 가능 여부를 일찍 확인할 수 있습니다.
지원 전 준비할 것
- 1
편입 구분과 복무 상황 정리하기
산업기능요원은 보충역, 전문연구요원은 현역과 보충역이 대상이고 신규 편입과 전직이 모두 가능합니다. 병역 구분과, 전직이라면 현재 지정업체와 남은 복무 기간을 정리해 지원서에 함께 적습니다.
- 2
매칭 문제 시간 재고 풀어 보기
1차 인터뷰에서 콘텐츠 구조와 디자인 구조를 매칭하는 과제를 약 1시간 동안 실시간으로 풉니다. 두 트리를 대응시키는 작은 문제를 TypeScript로 시간을 재고 풀며 판단 기준을 말로 설명하는 연습을 해 둡니다.
- 3
연구·대회 경험을 제품 문제로 바꿔 쓰기
자격 요건은 알고리즘을 제품 문제에 적용한 경험을 묻고 대회와 올림피아드는 우대 사항에 있습니다. 연구나 대회에서 푼 문제 하나를 골라 템플릿 요소 교체 같은 제품 문제로 바꿔 설명하는 문단을 만들어 둡니다.
- 4
미리캔버스 템플릿 바꿔 보기
원본 요소와 대체 요소의 대응을 정하는 로직을 맡습니다. 미리캔버스에서 템플릿 내용을 바꿔 보며 어떤 요소가 자리를 지키고 어떤 요소가 바뀌는지 관찰해 둡니다.