Factory AI의 제안은 설명하기는 쉽지만 실행하기는 어렵습니다. 당신이 작업을 설명하면, Droid가 업무를 수행하고, 당신은 풀 리퀘스트 (Pull Request)를 검토하는 것입니다. 이는 대부분의 개발자가 2023년에서 2025년 사이에 채택했던 자동 완성 (Autocomplete) 및 채팅 도구들과는 다른 계약 방식입니다. 그러한 도구들은 당신이 운전하는 동안 옆에 앉아 있는 존재입니다. 반면 Droid는 스스로 운전하여 결과물을 당신에게 전달하도록 설계되었습니다.

이러한 차이점 — 페어링 (Pairing) 대 위임 (Delegation) — 이 2026년 자율 에이전트 (Autonomous Agents)의 핵심이며, Factory가 당신의 워크플로 (Workflow)에 포함될지 결정하는 데 있어 올바른 관점입니다. 우리는 데모와 일상적인 업무를 구분하기 위해 실제 리포지토리 (Repository)를 대상으로 Droids를 실행하며 시간을 보냈습니다.

Droid가 실제로 하는 일

Factory는 스스로를 에디터 플러그인 (Editor Plugin)이라기보다 "에이전트 네이티브 (Agent-native)" 개발 플랫폼으로 포지셔닝합니다. Droid는 당신의 팀이 이미 업무를 기록하는 곳 — GitHub 이슈 (Issue), Linear 티켓 (Ticket), Slack 메시지, Sentry 에러 (Error) — 에서 작업을 수락한 다음, 계획을 세우고, 여러 파일에 걸쳐 편집하며, 테스트를 실행하고, 다른 기여와 마찬가지로 검토할 수 있는 풀 리퀘스트 (Pull Request)를 생성합니다.

두 가지 인터페이스가 있습니다. 클라우드 플랫폼은 Droids를 비동기적으로 실행합니다. 즉, 작업을 할당하고 나중에 PR로 돌아오는 방식입니다. droid CLI는 로컬 체크아웃 (Local Checkout) 환경에서 터미널을 통해 에이전트를 실행하며, 이는 개발자들이 Claude Code 및 Codex를 통해 익숙해진 대화형 루프 (Interactive Loop)에 더 가깝습니다. CLI가 더 나은 시작점인데, 그 이유는 에이전트가 추론하는 과정을 지켜볼 수 있고 잘못된 계획을 확정하기 전에 중단시킬 수 있기 때문입니다.

위임 에이전트 (Delegation Agent)와 채팅 어시스턴트 (Chat Assistant)를 구분 짓는 것은 컨텍스트 수집 (Context Gathering)입니다. 코드를 건드리기 전에, Droid는 주변 파일들을 읽고, 함수가 어떻게 사용되는지 추적하며, 기존 테스트를 확인합니다. 명확한 컨벤션 (Convention)이 있는 잘 구조화된 리포지토리에서는 이러한 근거 설정 (Grounding)을 통해 일반적인 보일러플레이트 (Boilerplate)가 아닌 해당 프로젝트의 스타일에 맞는 변경 사항을 만들어냅니다. 반면 암묵적인 컨벤션이 존재하는 거대한 모노레포 (Monorepo)에서는 바로 이 단계에서 방향을 잃기 쉽습니다.

가장 도움이 되는 멘탈 모델(Mental model)은 다음과 같습니다: Droid를 시니어 팀원이 아니라, 입사 첫 주를 보내고 있는 유능한 계약직 직원처럼 대하는 것입니다. Droid는 언어와 도구는 알고 있지만, 당신의 코드베이스 중 어느 부분이 핵심적인 지지대 역할을 하고 어느 부분이 건드려도 안전한지는 아직 알지 못합니다. 작업 범위를 엄격하게 설정하면 결과물은 강력합니다. 하지만 모호한 것을 건네주면, Droid는 그 빈틈을 추측(Assumptions)으로 채워버립니다.

자율성이 유지되는 지점과 무너지는 지점

Droid가 잘 처리하는 작업은 대부분의 팀이 투자를 소홀히 하는 작업들입니다. 후속 코드 변경을 동반하는 의존성 업데이트(Dependency bumps), 스택 전체(마이그레이션, 모델, API, 타입, 테스트)를 통한 필드 추가, 테스트가 없는 모듈에 누락된 테스트 작성, 스택 트레이스(Stack trace)가 포함된 명확한 버그 리포트를 수정 사항과 회귀 테스트(Regression test)로 변환하는 작업 등이 이에 해당합니다. 이것들은 완료의 정의(Definition of done)가 구체적이고 경계가 명확하며 검증 가능한 작업들이며, 이것이 바로 에이전트가 경로를 이탈하지 않고 유지하는 데 필요한 요소들입니다.

실패 모드(Failure modes) 또한 매우 일관적입니다. 첫 번째는 모호한 요구사항입니다. Droid에게 "성능을 개선해줘"라고 요청하면, Droid는 당신을 대신해 지표(Metric)를 선택할 것이며, 이는 종종 잘못된 지표가 될 것입니다. 두 번째는 여러 개의 비로컬 제약 조건(Non-local constraints)을 동시에 고려해야 하는 횡단적 변경(Cross-cutting changes)입니다. Droid는 자신이 볼 수 있는 제약 조건은 충족시키겠지만, 보이지 않는 제약 조건은 조용히 위반할 것입니다. 세 번째는 테스트 스위트(Test suite)가 취약한 모든 경우입니다. 자율성은 실행되는 검증(Verification)만큼만 신뢰할 수 있습니다. 탄탄한 테스트가 없다면, 초록색 체크표시는 코드가 실행된다는 의미일 뿐, 코드가 정확하다는 의미는 아닙니다.

실질적인 결과는 Droid가 리뷰를 없애는 것이 아니라, 리뷰의 위치를 옮긴다는 점입니다. 당신은 타이핑하는 시간은 줄이겠지만, 디프(Diffs)를 비판적으로 읽는 데 더 많은 시간을 쓰게 됩니다. 명확한 이득이 되는 한 줄짜리 설정 변경의 경우에는 그렇습니다. 하지만 6개 파일에 걸친 400줄짜리 리팩터링(Refactor)의 경우, 리뷰에 드는 주의력은 직접 작성할 때만큼이나 많이 소모될 수 있으며, 변경 사항이 그럴싸해 보이면서도 미묘하게 틀렸을 수 있다는 추가적인 리스크를 떠안게 됩니다.

자율적인 풀 리퀘스트 (Pull Requests)를 검토할 때는 인간이 작성한 것보다 더 적은 의심이 아니라, 더 많은 의심을 가지고 검토하십시오. 에이전트의 디프 (Diff)는 올바르게 보이고 자신이 볼 수 있는 테스트를 통과하도록 최적화되어 있습니다. 이는 바로 여러분의 테스트가 놓치는 틈새에 버그를 숨기는 변경 사항의 전형적인 특징입니다. 에이전트가 건드리지 않은 부분도 건드린 부분만큼이나 주의 깊게 읽으십시오.

비용 또한 주의 깊게 살펴봐야 할 또 다른 축입니다. 위임형 에이전트 (Delegation agents)는 상호작용형 에이전트 (Interactive ones)보다 훨씬 더 많은 토큰 (Tokens)을 소모하는데, 이는 행동하기 전에 광범위하게 읽고 테스트 실행이 실패한 후 종종 재시도하기 때문입니다. 사소해 보이는 작업이라도 에이전트가 방대한 컨텍스트 (Context)를 탐색하거나 불안정한 테스트 (Flaky test)에서 루프를 돌게 되면 상당한 사용량을 소모할 수 있습니다. 예산은 변경 사항이 얼마나 작아 보이는지가 아니라, 작업의 복잡도에 따라 책정하십시오.

워크플로우에 Droids를 도입해야 할까요?

만약 여러분의 팀이 이미 깔끔한 티켓 (Tickets)을 생성하고, 실제 테스트 스위트 (Test suite)를 유지하며, 모든 변경 사항을 검토하고 있다면, Droids는 우선순위에서 밀려 결코 처리되지 않는 제한된 백로그 (Bounded backlog)를 해결하는 방법으로서 깔끔하게 자리 잡을 수 있습니다. 만약 여러분의 티켓이 한 줄짜리 메모에 불과하고 테스트 커버리지 (Test coverage)가 빈약하다면, 그것부터 먼저 해결하십시오. 에이전트는 이미 존재하는 규율이 무엇이든 양방향으로 증폭시킬 것이기 때문입니다.

합리적인 도입 경로: 모니터링하고 중단할 수 있는, 리스크가 낮고 테스트가 잘 된 작업부터 CLI를 통해 시작하십시오. Droids의 PR을 수정 없이 수락하는 빈도와 다시 작성해야 하는 빈도를 측정하십시오. 몇 주 동안 추적된 그 수락률 (Accept rate)은 그 어떤 벤치마크 (Benchmark)보다 더 많은 것을 알려줄 것입니다. 특정 범주의 작업에 대한 수락률을 신뢰할 수 있게 되었을 때에만 완전히 비동기적인 클라우드 위임 (Cloud delegation) 방식으로 전환하십시오.

위임형 에이전트는 상호작용적인 페어 프로그래밍 (Pair-programming) 스타일의 도구를 대체하는 것이 아니라, 그 옆에 위치합니다. 많은 개발자가 제한된 티켓 형태의 작업에는 Droid를 실행하고, 전체 과정에 직접 참여하고 싶은 탐색적 코딩 (Exploratory coding) 단계에서는 에디터 내의 빠른 어시스턴트 (Assistant)를 계속 유지합니다.

2026년에 대한 솔직한 요약은 다음과 같습니다: 자율 코딩 에이전트 (Autonomous coding agents)는 데모 단계를 넘어 진정으로 유용한 단계로 넘어왔지만, 이는 오직 사용자가 설정한 경계 안에서만 가능합니다. Factory의 Droids로부터 가치를 얻고 있는 팀들은 마법을 기대하는 팀들이 아닙니다. 그들은 이미 깔끔한 티켓 (Tickets)과 좋은 테스트 (Tests)를 갖추고 있으며, 에이전트를 자신들이 이미 실천하고 있는 규율 (Discipline)을 강화하기 위한 지렛대 (Leverage)로 취급하는 팀들입니다.