TL;DR
- 동일한 repo, 동일한 prompt로 Blitz / Devin / Factory를 시험했습니다. 대상은 공식 AWS 샘플인 AWS Card Demo Modernization.
- 목표: COBOL/VSAM/JCL 메인프레임 앱을 Java 21 기반의 Spring Boot microservices로 변환하고, AWS 권장 패턴에 맞춰 plan → code → validate 흐름을 끝까지 밀어보기.
- 요약 결과:
- Blitz: 시작은 느리지만 깊게 읽고 크게 쓰는 스타일. 대규모 PR과 함께 Project Guide를 내놓고, **코드 95% 완료 / implementation 100%**라고 보고. 남은 일은 운영 단계(배포·DB·AWS 설정) 위주. ~560시간 절감 / ~32시간 잔여 추정.
- Devin: 빠른 반복이 강점. 다만 지속적인 가이드가 필요. 첫 PR은 38 files / ~3,341 insertions, 후속 프롬프트로 77 files / ~6,400 lines까지 확대. 티켓성 작업에 잘 맞음.
- Factory: local + remote 동시 연결과 droids 협업이 특징. 초기 plan → scaffolding은 신속했지만, 완전한 기능 커버리지를 위해선 여러 차례 미세 지시가 필요.
- 결론 한 줄: 대규모, 엔터프라이즈급 modernize라면 Blitz가 존재감을 보였습니다. 빠른 반복과 소규모 단위 작업 위주라면 Devin·Factory가 민첩합니다.
왜 이 테스트인가
modernization은 AI 코딩 에이전트가 진짜로 도움이 되는지 가늠하기 좋은 무대입니다. 실제 기업에는 아직도 COBOL과 JCL, VSAM 같은 시스템이 살아 있고, 이를 Java 21 microservices로 옮기는 일은 장난이 아닙니다. 이 과정은 legacy codebase 이해, architecture 설계, service/infrastructure 생성, validation까지 넓게 건드립니다. 그래서 세 제품에 같은 숙제를 던졌습니다.
사용한 실제 과제
- Repo: 공식 AWS 샘플 AWS Card Demo Modernization. 메인프레임 기반 신용카드 관리 앱을 현대화하는 시나리오로 구성되어 있습니다.
- 레거시 스택: COBOL, VSAM, JCL. 현실 기업과 맞닿아 있어 테스트 베드로 적합합니다.
- 이 repo가 좋은 이유:
- legacy codebase를 읽고 구조를 파악해야 함.
- 설득력 있는 modernization plan이 필요함.
- 새로운 services/infrastructure를 만들어야 함.
- 결과가 실제로 동작하는지 validate해야 함.
- Prompt 전략: multi‑page prompt 하나를 만들어 세 플랫폼에 그대로 전달.
- 미션: 메인프레임 구현을 Java 21 microservices로 전환.
- 성공 기준, target stack, architecture/patterns, modules/components 등 요구사항을 상세히 명시.
벤더들이 내세우는 SWE‑bench 숫자
SWE‑bench는 Princeton과 Hugging Face가 만든 벤치마크로, 에이전트가 실제 GitHub issues를 읽고 patch를 만들어 기존 tests를 통과시키는 능력을 봅니다.
- Devin: 13.68% (SWE‑bench Full)
- Factory(Code Droid/Factory): 19.27% (Full), 31.67% (Lite)
- Blitz(자료에선 Blitzy/Blissey로도 표기): 86.8% (SWE‑bench Verified, 500‑task subset). scaffolding/hints/best‑of‑k 없이 달성했다고 강조.
단, 서로 동일 조건이 아닙니다. Full/Lite/Verified 등 변형과 허용 옵션 차이가 커서 단순 비교는 무리입니다. 저는 여기서 각사가 공개한 수치만 소개합니다.
깊게 보기 1 — Blitz: infinite context로 길게 읽고, 크게 적는 방식
포지셔닝: Blitz는 100M+ lines까지도 한꺼번에 읽어낼 수 있다고 강조합니다. 핵심은 codegen 전 대규모 이해 단계. 먼저 technical spec을 길게 뽑고(수백 페이지 가능), 그다음 코드를 생산합니다. 이 사전 작업은 며칠 걸릴 수 있습니다.
가격(요약):
- Free: 대형 technical spec 생성 가능
- Pro: $10K/year
- Team: $100K/year (개인보단 enterprise 지향)
제가 진행한 흐름:
- 새 프로젝트 → Existing Product 선택 → 이름 지정(예: “AWS”).
- 조직/Repo(AWS Card Demo) 선택, main branch.
- 환경 설정 + codebase에 대한 설명 추가.
- Build Technical Spec 클릭.
- 대기. 제 경우 spec 생성까지 약 3일 소요.
Spec 느낌:
- 제 런에서는 ~200페이지.
- COBOL 모듈과 호출 흐름, 데이터 등 메인프레임 문맥을 깊게 풀어냈습니다.
- 다음 단계의 사실상 참조 문서/계약서 역할.
Codegen 단계:
- Build → Refactor codebase 선택.
- 앞서 만든 multi‑page prompt 입력.
- ~3–4일 뒤 pull request(PR) 오픈.
PR 규모(제 런 기준):
- 179 files changed
- ~144,000 insertions / ~354 deletions
- 요구한 스펙에 맞춰 현대식 Java 코드가 광범위하게 생성됨.
Project Guide:
- Blitz가 사람이 읽기 쉬운 가이드를 함께 제공. 무엇을 했고, 앞으로 제가 무엇을 해야 하는지 정리.
- 코드 95% 완료, **implementation 100%**라고 보고.
- 남은 일은 운영 과제(AWS 배포, production DB 구성, AWS 서비스 연결 등).
- ~560시간 절감, ~32시간 잔여(테스트/문서/보안/배포) 추정.
사용 체감: 느리게 준비, 크게 산출. codegen 사이클에서 핸들링이 거의 필요 없었고, 마지막 단계는 운영·배포 작업 위주였습니다. 실제 프로덕션까지 밀진 않았지만, PR 스케일과 가이드의 완성도는 엔터프라이즈급 인상을 줬습니다.
깊게 보기 2 — Devin: 빠른 반복, 티켓 친화, 대신 코칭 필요
포지셔닝: Devin은 AI software engineer를 표방. Slack, Linear와 붙어서 ticket을 픽업→플랜→테스트→PR까지 자동화하는 흐름을 지원합니다. 자체 컴퓨팅 환경에서 terminal·browser 동작을 실시간으로 볼 수 있는 것도 장점.
가격(요약):
- Team: $500/month
- Core(pay‑as‑you‑go): $20부터 (사용량에 따라 변동)
- Enterprise: 별도 견적
제가 진행한 흐름:
- AWS mainframe modernization repo 연결.
- agent mode로 작업(legacy mode 아님).
- Blitz에 준 것과 동일한 multi‑page prompt 투입.
첫 PR(~25분 후):
- Java 21 microservices + Spring Boot로 “완전 현대화”했다고 요약.
- directory 구조, database, APIs, COBOL program mapping 등의 설명 포함.
- 38 files / ~3,341 insertions.
현실 점검: 이 크기의 modernization 치고는 규모가 부족해 보였습니다. “원본 기능과 feature parity를 달성하자”고 추가 지시.
Devin의 후속 반응: 스스로 17개 누락 기능을 찾아내고 구현을 재개. 제가 계속 지시하며 키웠더니 77 files / ~6,400 lines 수준까지 확대. 진척은 확실했지만, 완전 커버리지에 다다르려면 지속적인 코칭이 필요했습니다.
사용 체감: 속도와 작은 범위의 티켓 처리에 강합니다. 다만 infinite context가 없고, 사전에 큰 spec을 쓰지 않다 보니, 제가 무엇을 더 넣을지 우선순위를 잡고 세세하게 요구해야 했습니다.
깊게 보기 3 — Factory: droids 협업, local+remote, 세밀 지시형 진도
포지셔닝: Factory는 agent‑native software development environment. software engineering / docs / product 등 역할이 다른 droids가 서로 일을 넘겨가며 협업합니다. 게다가 remote workspace뿐 아니라 내 로컬에도 붙어 어디서나 작업한다는 콘셉트.
가격(요약):
- Max: $200/month
- Free/Pro 제공, Enterprise는 별도.
제가 진행한 흐름:
- 로컬 머신에 Factory Bridge 설치.
- 에디터(Cursor)로 레거시 repo 오픈.
- 로컬 workspace를 Factory에 연결.
- 동일한 multi‑page prompt 입력.
진행 상황:
- ~10분만에 상세 plan 제시, 초기 scaffolding PR 진행 여부를 묻길래 yes.
- ~10분 더 지나 ~30–40 files와 README 제공.
- 다음 단계로 daily transaction ingestion, Testcontainers 등 제안. continue 지시.
- ~45분 정도 주고받으며 코드가 늘어났지만, 핵심 기능은 여전히 여러 부분 미흡. Devin과 비슷하게, 구체 지시가 없으면 결과가 간소화되는 경향.
사용 체감: local + remote 동시 작업은 분명 매력적이고, droids 협업 모델도 유용합니다. 다만 큰 modernization을 엔터프라이즈 수준으로 끌어올리려면 단계별 세부 지시가 많이 필요했습니다.
숫자로 보는 비교(제 런 기준)
- Blitz: 179 files changed, ~144,000 insertions / ~354 deletions
- Devin: 1차 38 files / ~3,341 insertions → 추후 77 files / ~6,400 lines
- Factory: 초기 ~30–40 files scaffolding, 이후 지시에 따라 점진 확대
주의: 라인 수가 품질을 보장하진 않습니다. 다만 메인프레임 전체 modernization 같은 큰 과제에서 지나치게 작은 PR은 대개 커버리지 부족 신호입니다. 이 맥락에서는 Blitz의 규모가 요구 범위와 잘 맞았습니다.
사람의 노력 분포(체감)
- Blitz: 초기에 prompt를 명확히 쓰고 컨텍스트를 충분히 제공하는 데 힘을 씁니다. 이후엔 긴 대기, codegen 단계에서는 핸들링 거의 없음. 마지막은 운영 과제(AWS 배포·DB·서비스 설정, 보안/문서/테스트).
- Devin: 처음부터 인터랙티브. 빠른 피드백 루프. 제가 누락 확인 → 우선순위 지시 → 보완을 반복하며 코칭해야 했습니다.
- Factory: 인터랙션 중심 + local/remote 병행 장점. 다만 큰 변화는 세세한 단계 지시 없이는 어려웠습니다.
가격 관점
- Blitz: spec 무료, $10K/year(Pro), $100K/year(Team). 사실상 엔터프라이즈용.
- Devin: $500/month(Team), Core는 $20부터 사용량 기반, Enterprise는 협의. 티켓 중심 운영에 맞음.
- Factory: $200/month(Max) 상단, Free/Pro/Enterprise 선택지. 로컬 repo + 클라우드를 같이 쓰고 싶은 팀에 적합.
어떤 팀이 뭘 고르면 좋을까
- Blitz: 예산 있고 레거시 범위가 거대한 엔터프라이즈. deep ingestion→long technical spec→coherent PR→Project Guide까지 한 번에 받고, 남은 운영 항목만 마무리하고 싶은 팀.
- Devin: 티켓 기반 개발 문화, 빠른 반복이 중요한 팀. refactor, migration, bugfix, backlog 정리에 강함. Slack/Linear 연동까지 고려하면 흐름이 매끈.
- Factory: 로컬과 리모트를 오가며 일하는 팀. droids 협업 모델을 선호하고, 세밀 지시를 통해 천천히 커버리지를 넓힐 수 있는 팀.
솔직한 체감
Blitz는 참을성 있게 먼저 읽고 나중에 크게 쓰는 태도가 인상적이었습니다. Devin과 Factory는 속도가 매력적이지만, 제가 항해사처럼 방향을 계속 잡아줘야 했습니다. “버튼 한 번에 엔터프라이즈 완성”은 아직 아니지만, 범위를 잘 맞추면 지금도 충분히 쓸 만합니다.
자주 받은 질문
Q. SWE‑bench Full/Lite/Verified 차이가 뭔가요?
A. SWE‑bench는 실제 GitHub issues로 평가합니다. Full은 광범위, Lite는 난이도 완화, Verified는 500‑task subset으로 큐레이션이 들어갑니다. scaffolding 허용 여부나 시도 횟수 등에 따라 직접 비교는 어렵습니다.
Q. 각 벤더 수치를 검증했나요?
A. 아니요. 공개 수치를 인용만 했고, 여기 실험은 제가 직접 한 modernization 과제에 대한 체험 보고입니다.
Q. PR이 클수록 좋은가요?
A. 항상 그렇진 않습니다. 다만 COBOL 기반 전체 modernization 같은 과제에선 지나치게 작은 diff는 기능 누락 신호인 경우가 많습니다. 이번 케이스에선 Blitz의 큰 PR이 요구 범위와 맞았습니다.
Q. 각 접근의 소요 시간은?
A. 제 런 기준으로 Blitz는 spec ~3일 + PR ~3–4일, Devin은 ~25분에 1차 PR 후 여러 차례 반복, Factory는 ~10분 plan + ~10분 scaffolding 후 반복 보완.
Q. Blitz PR 뒤에 남은 일은?
A. 운영 과제 위주입니다. AWS 배포, production DB 구성, AWS services 연동, 테스트/문서/보안 등. Blitz는 ~560시간 절감 / ~32시간 잔여를 추정했습니다.
Q. 한 줄 승자는?
A. 요건에 따라 다릅니다. 이번 시험에선 깊이와 응집력에선 Blitz가 돋보였고, 속도와 티켓 흐름에선 Devin/Factory가 실용적이었습니다.
따라 해보기: 단계 요약
Blitz
- 프로젝트 생성 → Existing Product.
- 조직/Repo(AWS Card Demo) 선택, main branch.
- 환경/설명 입력 → Build Technical Spec(며칠 소요).
- Build → Refactor codebase.
- multi‑page prompt 입력.
- PR + Project Guide 검토, 운영 과제 실행 계획.
Devin
- agent mode로 repo 연결.
- 동일 prompt 입력.
- 1차 PR 확인(~25분).
- 누락 기능 지시(저는 17개 추가 제시 받음).
- 반복하며 feature parity 근접.
Factory
- 로컬에 Factory Bridge 설치.
- 에디터(Cursor)로 레거시 repo 열기.
- workspace를 Factory에 연결.
- 동일 prompt 입력.
- plan/scaffolding PR 승인(~30–40 files).
- daily transaction ingestion, Testcontainers 등 구체 기능을 지시하며 확장.
최종 정리
- Blitz: 한 번에 크게 가고 싶은 엔터프라이즈에 적합. Project Guide와 대규모 PR이 강점.
- Devin/Factory: 속도, 티켓 중심 개발, 세밀 지시 기반 증분 개선에 적합. 범위를 잘 쪼개면 현업 투입이 수월.
결국 툴을 일감에 맞추는 것이 승부입니다. 좋은 prompt와 명확한 요구사항을 준비하면, 오늘 당장도 이 에이전트들은 개발 속도를 꽤 끌어올려 줍니다.