매니패스트 계약직 주니어 개발자 모집

[ 우리가 만드는 것 ]

Manyfast는 AI 기반 실시간 협업 문서 편집 플랫폼입니다. 여러 사람이 동시에 편집하는 문서 위에서 AI가 함께 일하는 제품을 만들고 있습니다.

[ 지금 풀고 있는 문제들 ]

"좋은 동료와 성장"같은 말 대신, 지원자께서 우리 회사에 입사하면 실제로 마주칠 문제들을 말씀드리겠습니다.

1. 동시 편집 정합성 — Yjs CRDT 기반 실시간 협업에서 충돌 없이 상태를 수렴시키는 일
2. LLM 출력 품질의 측정 — 평균 점수의 함정(ceiling effect, failure tail hiding)을 피해 모델·프롬프트 교체를 결정할 수 있는 eval 설계
3. 돈이 걸린 정합성 — 크레딧 차감·만료·일일 지급의 트랜잭션 일관성, 자정 경계의 race condition
4. 모노레포 4개 앱의 배포 체계 — Turborepo 기반 CI/CD, 브랜치별 preview 환경

[ 우리가 일하는 방식 ]

일하는 방식을 형용사로 쓰는 대신, 저장소에 커밋된 엔지니어링 규칙 문서를 일부 인용합니다. 실제로 이렇게 일합니다.

1. "버그를 수정할 때는 원인 가설을 자동화된 재현 테스트로 증명한 뒤 fix를 머지한다. 수정 전 코드에서 실패하는지(RED) 확인하지 않은 테스트는 가설을 증명하지 못한다."
2. "자정·만료·청구 주기 같은 시간 경계 동작은 실 시간을 기다리지 않는다. fixture로 시간을 주입하거나 clock을 명시적으로 inject해서 1초 안에 반복 검증한다."
3. "평균 점수만으로 모델 교체를 결정하지 않는다. 올바른 대조군, tail metric(p5/failure rate), semantic validator 셋이 모두 있어야 배포 결정의 근거가 된다."
4. "재귀 함수 금지. 트리 순회는 explicit stack + iteration 상한 가드로 작성한다." (ESLint 커스텀 룰로 강제)

이런 문서를 읽고 "왜 이렇게 정했지?"가 궁금해지거나, 반박하고 싶은 지점이 보인다면 우리 회사와 잘 맞을 가능성이 높습니다. 그 반박은 면접에서 환영합니다.

[ 이런 분을 찾습니다 ]

특정 스택 경험을 요구하지 않습니다. 아래 항목은 장식용 형용사가 아니라, 전형 과정에서 실제로 확인하는 것들입니다.

1. 꾸준히 읽고 공부하는 사람 — 최근에 읽은 기술서나 문서가 실제 코드·설계 결정을 바꾼 경험을 이야기할 수 있는 분
2. 도구를 깊게 아는 사람 — 자신이 매일 쓰는 언어·프레임워크·에디터의 공식 문서와 메뉴얼을 숙지하고, 동료 대부분이 모르는 동작 하나쯤은 설명할 수 있는 분
3. 선택을 대안과의 비교로 설명하는 사람 — "이게 좋아서"가 아니라 "A와 B를 이런 기준으로 비교했고, 이 트레이드오프 때문에 A를 골랐다"고 말하는 분
4. 코드의 수명을 이해하는 사람 — 10년 유지보수할 소프트웨어와 일회성 스크립트에 요구되는 것이 어떻게 다른지 아는 분
5. 컴퓨터 공학의 언어로 표현하는 사람 — "느려요"가 아니라 어디서 시간이 쓰이고 복잡도가 어떻게 되는지로 말하는 분
6. 의견이 강하되 배려하는 사람 — 기술적으로 대립할 용기가 있고, 동시에 자신이 틀렸을 때 양보한 경험도 있는 분
7. 일에서 효능감을 찾는 사람 — "어떻게 하면 일을 더 잘할 수 있을까"를 스스로 묻는 분

[ 이런 분을 우대합니다. ]

본인의 업무 방식이나 다른 사람이 어떻게 일하는지를 메타 인지할 수 있고, 이를 개선할 능력이 있다.

본인 나름대로 자신의 AI 에이전트(AI Agent)를 위한 하네스를 직접 구성하고 유지보수하고 있으며 이를 설명할 수 있다. 이때 해당 도구를 사용하는 데 있어서 구성한 방식의 근거는 무조건 공식 자료에 기반해야 한다. 가능하다면 클로드 코드보다는 다른 도구(코덱스 등)를 활용하는 사람이면 더 좋다. 여러 가지를 얕게 써봤다고 하는 경우보다는 하나를 깊게 사용하는 경우를 선호한다.

결정을 내릴 때 엔지니어적인 사고방식을 거친다

엔지니어적인 사고방식이라는 것은 문제를 해결할 때에 다음과 같은 사고 과정 등을 거친다는 것을 말한다.

1. 문제 상황에 대한 가설을 세우고, 이것이 해결된 시점에 대한 검증 방법을 제시할 수 있다.
2. 대안을 토대로 결정에 대한 근거를 제시할 수 있다. (예시 포스트)
3. 현재 작업의 내용이 반영됐을 때 발생 가능한 사이드 이펙트를 예측할 수 있으며, 그 근거는 시스템에 대한 통합적인 이해를 기반으로 한다.

스스로 개발 분야에서 발전하기 위해 공부하는 사람

엔지니어가 공부를 한다는 것은 공신력이 높은 공식 자료나 책과 같은 자료를 꾸준히 찾아보는 습관을 가지고 있음을 말한다. 그리고 이에 대해서 가장 좋은 검증 방법은 최종적으로 학습한 내용을 기반으로 만들어낸 결과물의 존재 여부이다. 최종 결과물은 서빙한 제품(사내 제품인지 본인의 개인 프로젝트인지 여부는 중요하지 않다)이 되거나 블로그 포스트, 유튜브 자료 등 다양한 형태가 될 수 있다.

[ 전형 절차 — 코딩 테스트와 과제가 없습니다 ]

코딩 테스트는 서로의 시간을 낭비한다고 생각하고, 과제는 지원자의 시간을 일방적으로 쓰게 한다고 생각합니다. 대신 이렇게 합니다.

1. 서류 — 간단한 이력서와 함께 아래 세 가지 질문에 답해 주세요 (각 한두 단락이면 충분합니다)
2. 최근 1년 내 읽은 기술서·문서·글 중 실제 코드나 설계 결정에 영향을 준 것 하나와 그 경험
3. 가장 후회하는 기술적 선택과, 당시 비교했던(혹은 비교했어야 했던) 대안
4. 동료와 기술적으로 대립했던 경험 하나 — 관철했든 양보했든, 그 과정에서 무엇을 했는지
5. 경험 인터뷰 (60분) — 이력서에 적힌 다양한 의사결정에 대해 편하게 이야기를 나눕니다.
6. 코드 리딩 세션 (60분) — 저희 저장소의 실제 PR 또는 모듈 하나를 화면에 띄우고 함께 읽으며 토론합니다. 사전 준비가 필요 없고, 정답도 없습니다. 낯선 코드를 어떻게 읽는지, 질문을 어떻게 던지는지를 봅니다
7. 컬처 인터뷰 — 함께 일할 동료들과의 대화

지원하기

1. 경력 1~5년을 생각하고 있지만, 절대 조건은 아닙니다. 신입도 가능합니다.
2. 컴퓨터공학에 대한 이해도 (전공 및 전공에 준하는 공부)를 요구합니다.
3. 조건:
4. 6개월 계약직, 이후 정직원 채용 전환 논의 (스타트업인 만큼 인재 한 명 한 명이 중요하다는 걸 이해하고 있습니다. 6개월 계약직 이후 정직원 전환 의사를 회사와 근로자 서로 확인합니다.)
5. 서울창업허브 공덕에서 근무