Factory AI 리뷰: AI 코딩 에이전트의 기능·가격·도입 기준

Factory AI는 어떤 제품인가요?

Factory는 Droids라는 에이전트를 중심으로 구성한 소프트웨어 개발 플랫폼입니다. Droids는 저장소를 살펴보고, 계획을 제안하고, 파일을 수정하고, 검증을 실행한 뒤 풀 리퀘스트를 준비할 수 있습니다. 풀 리퀘스트는 코드베이스에 병합하기 전에 검토할 수 있도록 변경 사항을 묶은 것입니다. 터미널, 통합 개발 환경(IDE), Factory의 데스크톱 앱과 웹 인터페이스에서 사용할 수 있습니다. ‘에이전트 네이티브 개발’이란 수정을 하나씩 지시하는 대신 원하는 결과를 맡기고 완성된 작업을 검토하는 방식을 뜻합니다. Factory는 모델과 개발 도구를 연결하는 제품이지, 새로운 프로그래밍 언어나 직접 학습시키는 모델은 아닙니다. Factory 제품 페이지에서 이 범위를 설명합니다.

2026년 10월 21일 기준으로 확인했습니다. Factory의 당시 공개 요금 페이지와 문서를 바탕으로 작성했습니다. 구체적인 작업 예시와 비용 계산을 포함한 문서 기반 평가이며, 코딩 벤치마크나 직접 사용한 결과를 제시하는 리뷰는 아닙니다.

Factory가 필요한 팀과 기존 에이전트로 충분한 팀은 어떻게 다를까요?

Factory는 서로 다른 에디터를 쓰는 개발자들에게 일관된 작업 위임 절차를 제공하려는 엔지니어링 리더에게 적합합니다. 워크플로를 전부 다시 만들지 않고 모델 공급자를 바꾸고 싶은 팀도 검토할 만합니다. 반면 기존 에이전트가 별다른 감독 없이 저장소 작업, 테스트, 리뷰 절차를 이미 잘 처리하고 있다면, 창업자 입장에서 추가 도입의 매력은 크지 않습니다.

비교할 후보는 Anthropic의 개발 에이전트인 Anthropic Claude Code, OpenAI의 코딩 에이전트인 OpenAI Codex, 에디터이자 에이전트 플랫폼인 **Cursor**입니다. AI 코딩 도구를 비교할 때는 각 제품을 도입하면 실제 업무 방식이 어떻게 달라지는지 살펴봐야 합니다.

이 표는 도입 판단을 위한 비교이며 벤치마크 순위가 아닙니다. Claude Code, Codex, Cursor는 이미 단일 채팅창이나 터미널을 넘어서는 기능을 제공합니다. 인터페이스가 여러 개라는 이유만으로 Factory가 우위에 서지는 않습니다.

Factory AI와 Claude Code 비교: 전환할 이유가 있나요?

더 폭넓은 워크플로 안에서 Claude 모델을 여러 선택지 중 하나로 쓰고 싶다면 Factory를 검토할 만합니다. 반면 조직이 이미 Claude Code를 중심으로 유용한 지침, 연동, 리뷰 관행을 갖추었다면 그대로 사용하는 편이 간단합니다. Droid에서 Claude 모델을 실행한다고 Claude Code와 같은 제품이 되는 것은 아닙니다. 주변 도구, 컨텍스트 선택 방식, 실행 동작은 에이전트 제품에 따라 달라집니다.

예를 들어 백엔드 개발자는 JetBrains를, 프런트엔드 개발자는 Cursor를 쓰는 팀이라면 리더가 공동 유지보수 작업 큐를 운영하기 위해 Factory를 도입할 수 있습니다. 이는 도입 목적이 분명한 선택입니다. 다른 모델의 데모가 인상적이었다는 이유만으로 모두에게 전환을 요구하는 것은 그렇지 않습니다.

주된 문제가 모호한 요구 사항, 신뢰하기 어려운 테스트, 아무도 검토하지 않는 풀 리퀘스트 대기열이라면 Factory 도입은 당분간 미루는 편이 좋습니다. Droids 역시 같은 문제에 부딪힙니다. Claude Code, Codex, Cursor를 유지하면서 작업 결과를 검증하기 쉽게 만드는 일이 먼저입니다. 더 좁은 범위의 선택은 Codex와 Claude Code 비교에서, 전체 후보군은 AI 코딩 에이전트 추천 목록에서 다룹니다.

아래에서는 컨텍스트 품질, 실행 통제, 인터페이스 간 작업 연속성, 변경 사항이 승인되기까지 드는 비용이라는 네 가지 기준으로 평가합니다.

Factory AI Droid: 에디터는 그대로, 작업 지시는 명확하게

Factory Droid는 기존 에디터 안에서 사용할 수 있어 에디터를 바꾸지 않고도 소규모 파일럿을 시작할 수 있습니다. VS Code, Cursor, Windsurf에서는 연동 기능이 활성 파일, 선택한 텍스트, 열려 있는 파일, 진단 정보를 전달합니다. 진단 정보는 에디터가 표시하는 오류와 경고 메시지를 뜻합니다. 에디터의 기본 diff 보기 기능도 지원합니다. 통합 터미널에서 droid를 실행한 뒤 /ide로 연결 상태를 확인합니다. 설정 방법은 Factory IDE 문서에 나와 있습니다.

백엔드 리더가 애플리케이션의 계정 권한 검증 방식을 바꾸는 상황을 생각해 보겠습니다. ‘인증 코드를 리팩터링해 주세요’만으로는 부족합니다. 모든 호출 지점을 찾고, 기존 사용자의 동작을 유지하고, 마이그레이션 순서를 제안하고, 의도하지 않은 권한 변경을 잡아낼 테스트를 찾아 달라고 해야 합니다.

이렇게 설명하면 에이전트가 지켜야 할 범위가 정해지고, 리뷰어에게도 결과를 반려할 기준이 생깁니다. diff의 규모만으로는 마이그레이션의 정확성을 판단할 수 없습니다.

Factory AI의 Spec Mode는 어떻게 작동하나요?

Factory의 Spec Mode는 조사·계획 단계와 구현 단계를 분리합니다. 관련 컨텍스트를 읽고 계획을 제시한 뒤 승인을 요청합니다. CLI에서는 Shift+Tab으로 Normal과 Spec 모드를 전환합니다. 어떤 동작을 추가 확인 없이 실행할 수 있는지는 별도의 자율성 수준(autonomy level) 설정으로 결정합니다. 모드 설명 문서는 이 차이를 명확하게 구분합니다.

권한 체계를 마이그레이션한다면 Spec Mode로 시작하고, 계획에 영향받는 파일, 호환성에 관한 전제, 검증 절차를 명시하도록 요구합니다. 기존 동작을 어떻게 유지할지 설명하지 않은 채 접근 규칙 변경을 제안한다면 계획을 반려합니다. 이런 결정이 명확해진 다음에 구현을 승인합니다.

실무에서는 다음 순서로 진행할 수 있습니다.

1. Droid에게 권한 검사 진입점과 관련 테스트를 찾도록 요청합니다.
2. 기존 동작을 유지하면서 불확실한 요구 사항을 짚는 계획을 요청합니다.
3. 계획을 검토한 뒤 허용할 작업에 맞는 자율성 수준을 선택합니다.
4. 풀 리퀘스트를 열거나 승인하기 전에 diff와 테스트 근거를 확인합니다.

에이전트가 대량의 코드를 만들기 전에 검토 지점을 둘 수 있다는 것이 장점입니다. 다만 그럴듯한 계획도 틀릴 수 있습니다. 승인 기준에는 테스트가 존재하는지뿐 아니라 실제 동작이 올바른지도 포함해야 합니다.

에디터별로 주의할 차이도 있습니다. Factory 문서에 따르면 JetBrains 연동에서는 열려 있는 파일, 선택 영역, 진단 정보, 에디터 내 Droid diff가 자동으로 공유되지 않습니다. 여러 에디터를 쓰는 팀에 도입할 때는 이 차이를 반영해야 합니다. VS Code에서의 경험이 어디서나 같을 것이라고 가정해서는 안 됩니다.

워크플로를 다시 만들지 않고 모델을 바꾸려면

Factory에서는 Droid 인터페이스와 작업 구조를 유지하면서 여러 모델 계열 중 하나를 선택할 수 있습니다. 작업 위임 방식은 통일하되 모든 워크플로를 단일 모델 공급자에 묶고 싶지 않은 팀에 유용합니다.

현재 Factory 모델 목록에는 다음 모델 등이 올라와 있습니다.

• Anthropic Claude Opus 5.5와 Claude Sonnet 5.5.
• OpenAI GPT-6.1 Sol과 GPT-6 Astra.
• Google Gemini 3.1 Pro와 xAI Grok 4.7.
• Mistral Large 4, Kimi K3, DeepSeek V4.1 Flash 등의 개방형 모델.

이는 지원 모델의 일부를 나열한 것이며 품질 순위가 아닙니다. 모든 계정의 정책이 이 모델들을 전부 허용한다는 뜻도 아닙니다.

의존성 업데이트 작업 큐를 예로 들어 보겠습니다. 각 후보 모델에 동일한 의존성 변경, 테스트 지침, 완료 기준을 전달합니다. 업데이트를 끝냈는지, 검증을 통과했는지, 리뷰어가 얼마나 개입해야 했는지 기록합니다. 감독이 덜 필요한 모델이라면 사용량이 더 많아도 가치가 있을 수 있습니다. 반대로 저렴한 모델이라도 계속 테스트가 깨진 상태로 남겨 둔다면 그렇지 않을 수 있습니다.

비교할 때는 작업과 환경을 일정하게 유지해야 합니다. 모델, 저장소 지침, 자율성 설정을 한꺼번에 바꾸면 결과를 해석할 수 없습니다. Factory 모델 목록에는 모델마다 다른 사용량 배수와 추론 설정이 있으므로, ‘프롬프트 수가 같다’는 조건만으로는 사용량을 제대로 비교할 수 없습니다.

**Bring your own key(BYOK)**는 자신의 모델 공급자 인증 정보나 호환 엔드포인트를 직접 설정하는 방식입니다. Factory는 로컬 구성을 포함한 개인용 커스텀 모델을 지원합니다. 다만 BYOK 문서에 중요한 제약이 명시되어 있습니다. 이러한 개인용 모델은 CLI와 데스크톱 앱에서만 사용할 수 있으며, 호스팅되는 웹·모바일 인터페이스에서는 사용할 수 없습니다.

도입 판단에 미치는 영향은 구체적입니다. Factory는 워크플로 안에서 모델을 교체하는 수고를 줄여 줄 수 있습니다. 하지만 실제로 작업을 실행할 인터페이스에서 원하는 모델을 쓸 수 있는지는 따로 확인해야 합니다. 로컬 모델 파일럿이 성공했다고 웹에서 작업을 위임하는 경로까지 검증된 것은 아닙니다.

데스크톱과 웹에서 위임한 작업을 검토하는 방법

Factory 데스크톱 앱은 대화와 함께 결과물을 눈으로 확인해야 할 때 유용합니다. 제품 페이지는 코드 diff, 문서, 프레젠테이션, 스프레드시트, PDF, 실행 중인 웹사이트를 미리 볼 수 있다고 설명합니다. 코드 줄이나 선택한 요소에 댓글을 남기는 기능도 제공합니다. macOS와 Windows에서 사용할 수 있습니다. Factory Desktop은 데스크톱, 웹, 모바일, CLI 사이에서 세션을 이어가는 기능도 소개합니다.

기술 창업자가 계정 설정 페이지를 수정한다면 흐름은 간단합니다. 원하는 동작을 설명하고, 렌더링된 결과를 확인하고, 해당 요소에 피드백을 남긴 뒤 출시 전에 코드 변경을 검토합니다. 시각적 피드백은 ‘이 오류 메시지는 이메일 입력란 옆에 있어야 합니다’처럼 수정할 위치를 짚는 데 도움이 됩니다. 하지만 서버가 잘못된 업데이트를 거부하는지, 다른 사용자의 설정에 접근할 수 없는지까지 입증해 주지는 않습니다.

작업을 위임할 때는 이 차이가 중요합니다. 화면을 승인하는 사람과 애플리케이션 동작을 검증하는 사람이 다를 수 있기 때문입니다. 눈에 보이는 변경과 함께, 그 아래의 동작이 제대로 작동한다는 근거도 요청해야 합니다. 그럴듯한 미리보기만으로 작업 완료를 판단해서는 안 됩니다.

Factory는 GitHub, Linear, Slack, Sentry 등의 도구용 커넥터도 제공합니다. 커넥터로 승인된 컨텍스트를 가져올 수는 있지만, 이슈 트래커를 연결한다고 모호한 티켓이 명확해지지는 않습니다. 작업에는 여전히 담당자, 범위, 분명한 결과가 필요합니다.

원격 실행에서는 또 하나를 구분해야 합니다. 작업을 검토하는 인터페이스와 작업을 실행하는 컴퓨터는 다릅니다. Factory가 관리하는 Droid Computers는 세션이 바뀌어도 파일, 설치된 패키지, 서비스, 설정을 유지하는 영속적인 환경입니다. 이미 직접 관리하는 머신을 위한 별도의 Remote Control 옵션도 문서에 나와 있습니다. Droid Computers 문서에서 두 가지를 모두 설명합니다.

설정에 많은 수고가 드는 환경에서는 상태 유지가 유용합니다. 동시에 환경 상태를 책임질 사람이 필요하다는 뜻이기도 합니다. Factory는 Environment를 다시 빌드해도 이전 스냅샷으로 만든 Droid Computer는 업데이트되지 않는다고 명시합니다. 따라서 플랫폼 리더는 한 번의 성공적인 실행을 다른 곳에서도 재현할 수 있다고 판단하기 전에 해당 머신의 상태를 확인해야 합니다.

AI 소프트웨어 팩토리는 반복 가능한 작업 하나에서 시작합니다

개발자가 매번 대화를 시작하지 않아도 Droid가 정해진 작업 큐를 처리하게 되면 Factory의 활용 가치는 더 커집니다. Droid Exec은 헤드리스 모드입니다. 대화형 입력 없이 작업을 실행하고 스크립트나 지속적 통합(CI) 시스템이 사용할 결과를 반환하는 명령입니다. 기본 동작은 읽기 전용이며, 파일 수정이나 더 폭넓은 명령 실행에는 자율성 설정을 명시해야 합니다. Exec 문서는 출력 형식, 작업 디렉터리, 격리된 Git worktree를 설명합니다.

첫 워크플로로는 관리자가 근거를 확인할 수 있는 저장소 분석이 적합합니다. Droid를 설치하고 인증한 뒤 저장소에서 다음 명령을 실행합니다.

droid exec --output-format json \
  "Identify exported functions without direct test coverage. Return file paths, the evidence for each gap, and suggested test cases. Do not edit files."

이는 호출 예시이며 이 리뷰를 위해 실제로 실행한 명령은 아닙니다. 이 명령만으로 테스트 커버리지가 입증되는 것도 아닙니다. 동적 호출, 통합 테스트, 생성된 코드 때문에 단순한 판단이 틀릴 수 있습니다. 출력은 관리자가 검토할 작업 후보 목록으로 활용합니다.

다음 단계에서는 승인된 작은 범위의 테스트 변경을 별도 브랜치나 worktree에서 구현하도록 Droid에 맡기고, 저장소의 검증 절차를 실행합니다. 에이전트가 작성한 설명만으로 승인 여부를 판단해서는 안 됩니다. CI 결과와 리뷰어의 판단을 기준으로 완료 여부를 결정해야 합니다.

자동화에서 놓치기 쉬운 제약도 있습니다. 적용되는 명령 정책이 ask라면 자율성 수준이 High여도 승인이 필요하며, 한 번 실행되고 끝나는 작업은 대화형 승인을 받을 수 없습니다. 따라서 자율성 수준을 높여도 막힌 자동화가 반드시 실행되는 것은 아닙니다. Factory는 실행 전에 정책 결정을 미리 확인할 수 있도록 droid rules check를 제공합니다. 이는 의도적으로 해결해야 할 설정 문제이지, 모든 권한 검사를 끌 이유가 아닙니다.

규모가 큰 작업에는 워커와 검증을 조율하는 Mission Mode가 있습니다. High 자율성 수준이나 문서에 명시된 안전장치를 우회하는 옵션이 필요하며, 개인 요금제의 Missions는 사용량 제한에 도달하면 일시 중지될 수 있습니다. 대규모 마이그레이션을 무인으로 완료하겠다고 약속하기 전에, 일반적인 범위 제한 작업부터 시작하는 편이 좋습니다.

얻을 수 있는 가치는 반복 가능성입니다. 매번 동일한 작업 접수 방식, 권한 경계, 검증 근거 묶음을 사용할 수 있습니다. 반면 운영을 책임질 사람이 필요합니다. 의존성, 인증 정보, 작업 범위, 실패 대응을 누군가는 관리해야 합니다. 개별 코딩 세션보다 이런 운영 체계가 더 중요하다면 소프트웨어 팩토리 플랫폼 비교를 다음 판단 자료로 활용할 수 있습니다.

Factory AI 가격: 필요한 워크플로에 맞춰 요금제를 고릅니다

결제를 한곳에서 관리하는 것이 요구 사항이라면 Factory Teams가 소규모 팀에 가장 간단한 선택입니다. 계약에 따른 사용량 공유, ID 관리, 관리자 정책이 필요하다면 Business를 검토해야 합니다. 개인 요금제에서 Teams로 옮기면 이런 관리 기능까지 제공된다고 가정해서는 안 됩니다.

다음은 2026년 10월 21일 Factory 공개 요금 페이지에서 확인한 월간 요금 조건입니다.

요금 페이지에는 토큰 제공량이 공개되어 있지 않습니다. 사용량은 Pro 대비 배수로만 표시합니다. 이 배수가 처리 가능한 작업 수를 보장하지는 않으며, 승인될 풀 리퀘스트 수로 타당하게 환산할 방법도 없습니다. 조직 요금제 문서에 따르면 Teams의 각 좌석에는 Pro 사용 한도가 적용됩니다. Business와 Enterprise는 계약 조건에 따라 사용량을 공유합니다.

Teams 5석의 비용은 월 $260입니다. 계산식은 $60 + 5 × $40입니다. 10석은 $460입니다. 5석을 쓰는 팀이 한 달 동안 Droid가 만든 풀 리퀘스트 20개를 승인했다고 가정하면, 구독료만 계산한 비용은 승인된 풀 리퀘스트당 $13입니다. 이는 산술 계산이지 처리 용량 예측이 아닙니다. 총비용을 비교하려면 추가 사용량, 컴퓨팅 자원, 리뷰어 시간도 더해야 합니다.

요금제가 워크플로의 요구를 충족하지 못하는 경우가 흔히 문제가 됩니다. Pro는 Business에 명시된 기업용 관리 기능을 제공하지 않습니다. Teams가 모든 좌석에 Plus 수준의 사용량을 제공한다고 안내하지도 않습니다. 또한 개인 요금제 문서에는 관리형 Droid Computers가 Pro에 포함된 것으로 나와 있지만, 실제 판매 요금 페이지에서는 Plus에서 추가되는 것으로 표시합니다. 예산은 요금 페이지를 기준으로 잡고, 관리형 컴퓨팅 자원에 의존하기 전에 실제 이용 권한을 확인해야 합니다.

팀 도입을 가로막을 수 있는 제약

Factory에서 가장 큰 영향을 미치는 제약은 인터페이스와 요금제 사이의 일관성에 있습니다. 개별 코딩 세션의 결과가 좋아도 이런 차이 때문에 도입이 막힐 수 있습니다.

에디터를 지원한다고 기능까지 같지는 않습니다. JetBrains에서는 VS Code 계열 에디터에 설명된 파일, 선택 영역, 진단 정보 자동 공유를 지원하지 않습니다. Zed의 Agent Panel은 이전 Factory Droid 세션을 복원하지 않습니다. Droids를 팀 표준으로 정해도 에디터별 온보딩과 컨텍스트 복원 계획은 필요합니다. Factory 문서에 이러한 차이가 명시되어 있습니다.

개인용 BYOK 설정은 호스팅 웹·모바일로 이어지지 않습니다. 로컬에 설정한 모델이 비용이나 데이터 처리 방식을 결정하는 핵심일 수 있습니다. 하지만 이 설정을 Factory의 모든 인터페이스에서 쓸 수는 없습니다. 로컬 데모만 보고 구매하기 전에 실제로 사용할 원격 작업 경로를 검증해야 합니다. 문서에서 이 제한을 명시합니다.

사용량 배수만으로 안정적인 처리 용량을 판단할 수는 없습니다. 개인 요금제 문서에는 5시간, 7일, 30일 단위의 독립적인 롤링 사용 한도가 설명되어 있습니다. 더 높은 요금제에 가입해도 이 한도가 공개된 토큰 제공량이나 작업 완료 보장으로 바뀌지는 않습니다. 고객 납기를 무인 실행에 의존해야 한다면 짧은 파일럿의 결과를 확대 해석하기보다 계약으로 확보할 수 있는 처리 용량을 논의해야 합니다. Factory의 개인 사용량 규칙에도 사용 한도에 도달하면 Missions가 일시 중지된다고 나와 있습니다.

관리형 컴퓨팅 자원 이용 권한은 확인이 필요합니다. 노트북 밖에서 작업이 실행되기를 기대하는 창업자에게 Pro와 Plus 사이의 문서 불일치는 실질적인 문제입니다. 이 리뷰의 요금제 표는 공개 요금 페이지를 기준으로 작성했으며, 상충하는 문서가 무료 업그레이드의 근거가 되지는 않습니다. ‘클라우드 에이전트’라는 표현에 인프라 사용량 전체가 포함된다고 해석하지 말고, 컴퓨팅 자원 조건도 모델 사용량과 별도로 확인해야 합니다.

권한 규칙은 운영체제 수준의 격리가 아닙니다. Factory의 자율성 문서도 이 점을 설명합니다. 어떤 명령이 허용된다고 무해하다는 뜻은 아닙니다. 프로덕션에 접근하지 말라는 자연어 지시 역시 네트워크 경계가 아닙니다. 파일럿에서는 작업에 적합한 접근 권한과 환경을 사용하고, 조직 차원의 강제가 필요하다면 별도 견적 요금제의 관리 기능을 평가해야 합니다.

이런 제약을 고려하면 도입 범위를 좁게 잡는 편이 좋습니다. 환경, 모델, 권한, 리뷰어가 정해진 워크플로에 Factory를 적용합니다. 이 선택들이 정리되기 전에 모든 저장소로 확대하면 조율 업무가 늘어나 위임의 이점이 사라질 수 있습니다.

Factory AI 리뷰: 도입 여부는 무엇으로 판단해야 하나요?

Factory의 가치는 명확하게 정의된 작업을 승인된 변경으로 만드는 데 필요한 사람의 수고를 줄이는 데 있습니다. 모델 선택, 여러 인터페이스, 원격 실행도 이 결과를 개선할 때 의미가 있습니다.

공동 유지보수 큐, 여러 에디터에 걸친 워크플로, 의도적인 모델 비교를 현재 도구로 만족스럽게 처리할 수 없다면 기존 에이전트와 함께 도입합니다. 비슷한 작업을 비교했을 때 승인 기준을 약화하지 않으면서 리뷰어의 수고나 총비용이 줄었다는 결과가 나온 뒤에만 해당 작업 유형에서 기존 에이전트를 교체합니다. Claude Code, Codex, Cursor가 이미 잘 처리하는 워크플로를 중복하는 데 그친다면 도입하지 않습니다.

다음 업무 주에 실행할 일은 결과를 책임질 리더와 함께 소규모 평가를 시작하는 것입니다.

Factory는 이러한 평가에 올릴 만한 후보입니다. 문서는 폭넓게 구성할 수 있는 에이전트 시스템이라는 점을 뒷받침합니다. 다만 엔지니어가 익숙한 에이전트를 Droid로 바꾸기만 하면 더 나은 결과물을 출시하게 된다는 것까지 입증하지는 않습니다.

자주 묻는 질문

뉴스레터에서 AI Business Workflow Audit Checklist를 받아 보세요. 에이전트 도입을 확대하기 전에 작업, 권한, 리뷰 책임자, 운영 비용을 정리하는 데 활용할 수 있습니다.