[ 우리가 만드는 것 ]
매니패스트(manyfast.io)는 AI 기반 실시간 협업 기획 문서 편집 플랫폼입니다. 여러 사람이 동시에 편집하는 문서 위에서 AI가 함께 일하는 제품을 만들고 있습니다.
[ 지금 풀고 있는 문제들 ]
"좋은 동료와 성장"같은 말 대신, 지원자께서 우리 회사에 입사하면 실제로 마주칠 문제들을 말씀드리겠습니다.
- 동시 편집 정합성 — Yjs CRDT 기반 실시간 협업에서 충돌 없이 상태를 수렴시키는 일
- LLM 출력 품질의 측정 — 평균 점수의 함정(ceiling effect, failure tail hiding)을 피해 모델·프롬프트 교체를 결정할 수 있는 eval 설계
- 사업 성과와 연결된 개발 정합성 — 크레딧 차감·만료·일일 지급의 트랜잭션 일관성, 자정 경계의 race condition
- 모노레포 4개 앱의 배포 체계 — Turborepo 기반 CI/CD, 브랜치별 preview 환경
[ 우리가 일하는 방식 ]
일하는 방식을 형용사로 쓰는 대신, 저장소에 커밋된 엔지니어링 규칙 문서를 일부 인용합니다. 실제로 이렇게 일합니다.
＞ "버그를 수정할 때는 원인 가설을 자동화된 재현 테스트로 증명한 뒤 fix를 머지한다. 수정 전 코드에서 실패하는지(RED) 확인하지 않은 테스트는 가설을 증명하지 못한다."
＞ "자정·만료·청구 주기 같은 시간 경계 동작은 실 시간을 기다리지 않는다. fixture로 시간을 주입하거나 clock을 명시적으로 inject해서 1초 안에 반복 검증한다."
＞ "평균 점수만으로 모델 교체를 결정하지 않는다. 올바른 대조군, tail metric(p5/failure rate), semantic validator 셋이 모두 있어야 배포 결정의 근거가 된다."
＞ "재귀 함수 금지. 트리 순회는 explicit stack + iteration 상한 가드로 작성한다." (ESLint 커스텀 룰로 강제)
이런 문서를 읽고 "왜 이렇게 정했지?"가 궁금해지거나, 반박하고 싶은 지점이 보인다면 우리 회사와 잘 맞을 가능성이 높습니다. 그 반박은 면접에서 환영합니다.
주요업무
[ 기술 환경 (참고용) ]
TypeScript 풀스택 모노레포입니다. 서버는 NestJS·Prisma·PostgreSQL·Redis·BullMQ, 클라이언트는 React·Yjs, 인프라는 AWS CDK, 빌드는 Turborepo + pnpm. **입사 시점에 몰라도 됩니다.** 위에 적은 사고방식이 있다면 스택은 배우면 됩니다.
자격요건
[ 이런 분을 찾습니다 ]
특정 스택 경험을 요구하지 않습니다. 아래 항목은 장식용 형용사가 아니라, 전형 과정에서 실제로 확인하는 것들입니다.
- 꾸준히 읽고 공부하는 사람 — 최근에 읽은 기술서나 문서가 실제 코드·설계 결정을 바꾼 경험을 이야기할 수 있는 분
- 도구를 깊게 아는 사람 — 자신이 매일 쓰는 언어·프레임워크·에디터의 공식 문서와 메뉴얼을 숙지하고, 동료 대부분이 모르는 동작 하나쯤은 설명할 수 있는 분
- 선택을 대안과의 비교로 설명하는 사람 — "이게 좋아서"가 아니라 "A와 B를 이런 기준으로 비교했고, 이 트레이드오프 때문에 A를 골랐다"고 말하는 분
- 코드의 수명을 이해하는 사람 — 10년 유지보수할 소프트웨어와 일회성 스크립트에 요구되는 것이 어떻게 다른지 아는 분 (『구글 엔지니어는 이렇게 일한다』의 관점에 공감한다면 더욱)
- 컴퓨터 공학의 언어로 표현하는 사람 — "느려요"가 아니라 어디서 시간이 쓰이고 복잡도가 어떻게 되는지로 말하는 분
- 의견이 강하되 배려하는 사람 — 기술적으로 대립할 용기가 있고, 동시에 자신이 틀렸을 때 양보한 경험도 있는 분
- 일에서 효능감을 찾는 사람 — "어떻게 하면 일을 더 잘할 수 있을까"를 스스로 묻는 분
- ### 본인의 업무 방식이나 다른 사람이 어떻게 일하는지를 메타 인지할 수 있고, 이를 개선할 능력이 있다.
본인 나름대로 자신의 AI 에이전트(AI Agent)를 위한 하네스를 직접 구성하고 유지보수하고 있으며 이를 설명할 수 있다. 이때 해당 도구를 사용하는 데 있어서 구성한 방식의 근거는 무조건 공식 자료에 기반해야 한다. 가능하다면 클로드 코드보다는 다른 도구(코덱스 등)를 활용하는 사람이면 더 좋다. 여러 가지를 얕게 써봤다고 하는 경우보다는 하나를 깊게 사용하는 경우를 선호한다.
구체적인 질문의 예시로는 ‘AI가 결과물이 완성됐다 했는데 그렇지 못할 때 어떻게 대응하시나요?’, ‘AI의 계획이 이해 안 될 때 어떻게 작업을 진행하세요?’, ‘토큰 소모량을 관리하기 위해서 무슨 작업을 하셨나요?’ 등이 있다. 이때 기대하는 대답은 그때그때의 임기응변을 통한 해결이 아니다. 반복적으로 이루어지는 작업들의 경우에는 시스템적으로 해결할 수 있는 사고방식을 가지고 있어야 한다.
### 결정을 내릴 때 엔지니어적인 사고방식을 거친다
엔지니어적인 사고방식이라는 것은 문제를 해결할 때에 다음과 같은 사고 과정 등을 거친다는 것을 말한다.
- 문제 상황에 대한 가설을 세우고, 이것이 해결된 시점에 대한 검증 방법을 제시할 수 있다.
- 대안을 토대로 결정에 대한 근거를 제시할 수 있다. (예시 포스트)
- 현재 작업의 내용이 반영됐을 때 발생 가능한 사이드 이펙트를 예측할 수 있으며, 그 근거는 시스템에 대한 통합적인 이해를 기반으로 한다.
### 스스로 개발 분야에서 발전하기 위해 공부하는 사람
엔지니어가 공부를 한다는 것은 공신력이 높은 공식 자료나 책과 같은 자료를 꾸준히 찾아보는 습관을 가지고 있음을 말한다. 그리고 이에 대해서 가장 좋은 검증 방법은 최종적으로 학습한 내용을 기반으로 만들어낸 결과물의 존재 여부이다. 최종 결과물은 서빙한 제품(사내 제품인지 본인의 개인 프로젝트인지 여부는 중요하지 않다)이 되거나 블로그 포스트, 유튜브 자료 등 다양한 형태가 될 수 있다.
이때 제일 중요한 것은 자신이 공부했고 이를 통해 만든 결과물이 무엇인지에 대해 얼마나 명료하게 정리된 형태로 설명할 수 있는 능력을 갖추었느냐이다. 본인이 작업한 내용을 설명할 수 없으면 그것은 공부한 것으로 인정하지 않는다. 작업한 내용의 경우에는 최근 1년 이내의 것을 기준으로 설명할 수 있어야 한다. 컴퓨터 공학을 전공했느냐의 여부는 중요하지 않다.
혜택 및 복지
- 조건:
- 6개월 계약직, 이후 정직원 채용 전환 논의
- 서울창업허브 공덕에서 근무
- 연봉 4,000~4,500 협의 가능.
