딜리버리 모델

개인이 아닌 팀 단위로

모든 프로젝트는 백업 인력이 지정된 팀(pod) 단위로 구성되며, 고정된 품질 게이트를 거쳐, 고객이 이미 소유한 인프라에 전달됩니다.

팀 구성

프로젝트 규모에 맞춰 구성

팀 규모는 최소 구성부터 대규모 프로젝트를 위한 확장 구성까지 다양합니다. 정확한 역할과 인원은 확정되는 대로 게시됩니다.

최소 구성 팀

합의 시 결정

대규모 팀

합의 시 결정

소유권

워크스페이스는 고객이 소유합니다

Customer owns the workspace — A Build organization on the customer's own GitHub repo, and their own AgentOS tenant.

No personal-account credentials — No delivery credentials live on a personal account.

품질 게이트

모든 프로젝트에 동일하게 적용되는 기준

Spec agreed first — Scope and acceptance criteria are agreed with the customer before delivery starts.

Revisions until met — Work goes through revisions until the agreed spec is met — no partial acceptance.

Two-person QA — Every deliverable passes review by a second pod member before it ships.

Gates never bypassed — The delivery lead configures Build's own quality gates for the engagement, and they are never bypassed.

Live status board — Every engagement has a live status board the customer can see.

Backup named at kickoff — A backup pod member is named at kickoff, so no engagement depends on one person.

팀 구성 절차

배정이 아닌 매칭

Interactor가 프로젝트에 맞는 팀 후보를 매칭하면, 고객은 2~3개의 후보 프로필 중에서 영업일 기준 10일 이내에 선택합니다.

산출물 정책

무엇을 누가 소유하는가

Generalized artefacts — Connectors and templates built during delivery may be offered back to Interactor for a bounty or account credit — never required.

Customer code — The customer's own code is the customer's.

매니페스트 예시

딜리버리 매니페스트의 실제 모습

투입된 역할DM-2026-000

Build가 Build를 만듭니다

Interactor Build가 자사 제품에 배포하는 모든 기능은 고객에게 판매하는 것과 동일한 목표 → 태스크 → PR 엔진을 거칩니다. 만든 팀을 위한 별도의 지름길은 없습니다.

  • Build 운영자 · 1
  • 리뷰어 · 1
제품 지표
머지된 목표 PR
2,018GitHub 검색, InteractorOSS/product-manager · 2026-09-04 측정
인시던트 포스트모템
7docs/incidents/, InteractorOSS/product-manager · 2026-09-04 측정
작성된 런북
53docs/runbooks/*.md (최상위), InteractorOSS/product-manager · 2026-09-04 측정

결과자사 제품에 2,018개의 목표 PR을 배포했습니다 — 각각 판매하는 것과 같은 엔진으로 검토되고 머지되었습니다.

진행하고자 하는 프로젝트가 있으신가요?

프로젝트에 맞는 팀 구성에 대해 문의해 보세요.