SW/인공지능

Blitzy(Blitz)란? 엔터프라이즈 AI 코딩 플랫폼으로 대규모 Refactoring을 PR로 받는 방법

얇은생각 2026. 3. 28. 07:30

2026년의 Blitzy(Blitz): 챗봇이 아니라 ‘개발팀’처럼 일하는 엔터프라이즈 AI 코딩 플랫폼

요즘 AI 코딩 도구 좀 써봤다 싶으면 익숙한 패턴이 있어요.
프롬프트를 던지면 답이 오고, 조금 고치면 하나는 고치는데 다른 데가 깨지고, 다시 프롬프트를 던지고… 그렇게 반복하다 보면 내 시스템을 아직도 제대로 이해 못 한 모델과 “페어 프로그래밍”을 두 시간째 하고 있는 자신을 발견하게 됩니다.

Blitzy(보통 Blitz라고 줄여 부릅니다)는 그 반대 방향으로 설계된 플랫폼이에요.

여기서는 대화로 조금씩 고치는 대신, 코드베이스 전체를 통째로 인제스트(ingest)하고, 깊이 있는 Technical Spec(기술 명세)을 만든 다음, 1~4일 동안 자율적으로 작업해서 ‘큰 규모의, 자신감 있는 Pull Request’를 통째로 던져주는 방식을 씁니다. 단순히 코드만 뱉고 끝이 아니에요. 시스템을 바꾸는 과정에서 Spec을 계속 업데이트하고, 사람이 마지막으로 무엇을 해야 마무리되는지(배포 검증, 환경 설정, 성능 프로파일링, 문서 다듬기 등)를 아주 구체적으로 알려줍니다.

게다가 이걸 한 개의 “코딩 어시스턴트”로 하는 게 아니라, 주요 모델 제공자들의 에이전트를 엮어 수천 개의 협업 에이전트를 오케스트레이션하는 형태로 굴린다고 설명됩니다. 말 그대로 “도구”라기보다 “개발 플랫폼”에 가깝죠.

“대부분의 AI 코딩 도구가 빠른 대화처럼 느껴진다면, Blitzy는 길고 구조화된 인수인계처럼 느껴진다.”

이 글에서는 Blitzy가 무엇인지, 어떻게 끝까지 굴러가는지, 비용 구조는 어떤지, 어디에 강하고(어디에 약한지), 그리고 팀들이 어떻게 ‘vibe-coded’로 뒤엉킨 레포지토리를 유지보수 가능한 시스템으로 Refactoring한 뒤 몇 달째 밀린 대형 기능을 실제로 출시하는지까지 한 번에 정리해봅니다.

엔터프라이즈 AI 개발 플랫폼을 상징적으로 표현한 이미지: 엉킨 코드 케이블이 여러 로봇 드론의 협업으로 정돈된 모듈 블록과 기술 설계도로 정리되는 장면.

Blitzy(Blitz), 정확히 뭐 하는 녀석인가요?

Blitzy는 엔터프라이즈 중심의 AI 개발 오케스트레이션 플랫폼으로, 규모 큰·복잡한 엔지니어링 작업을 처리하도록 만들어졌습니다. 대표적으로는 이런 것들이죠.

레포 전체 단위의 Codebase 이해
코드 문서화(inline comments, docstrings, README 구조, 아키텍처 문서, 다이어그램)
수천 개 파일을 가로지르는 전체 Codebase Refactoring(Backend + Frontend)
완성된 PR 형태로 전달되는 신규 기능 개발

핵심 동작 방식은 아주 명확합니다.

처음에 시간을 투자해 디테일한 spec/prompt(스펙/프롬프트)를 작성합니다.
Blitzy가 레포지토리를 인제스트합니다(설정된 Environment에서 앱 실행도 가능).
시스템 전체를 설명하는 수백 페이지짜리 Technical Spec을 생성하고 유지합니다.
큰 작업마다 Agent Action Plan(실행 계획)을 먼저 만들어, 실행 전에 수정·검토할 수 있게 합니다.
승인하면 1~4일 동안 자율 실행합니다.
수만 라인 규모가 될 수도 있는 완성형 PR과, 사람이 마무리해야 할 “remaining work” 체크리스트를 함께 제공합니다.

이건 “프롬프트 던지면 답하는 IDE 에이전트”와는 카테고리가 다릅니다.

“Cursor가 파워툴이라면, Blitzy는 현장 반장과 설계도가 있는 공사팀에 가깝다.”

왜 이런 접근이 필요하고, 2026년에 왜 더 중요해졌을까?

2026년 기준으로 대부분의 팀은 에디터 안에서 돌아가는 에이전트형 코딩(agentic coding)을 한 번쯤은 써봤을 거예요. 빠르고 편하죠. 그런데 시간이 새기 쉬운 것도 사실입니다.

모델의 전제를 계속 바로잡게 됩니다.
모델이 끝까지 못 들고 가는 컨텍스트를 계속 반복 설명하게 됩니다.
구현이 반쪽짜리로 왔다 갔다 하게 됩니다.
“승인, 승인, 수정, 승인…” 하면서 계속 붙잡고 있게 됩니다.

작은 변경엔 괜찮아요. 문제는 이런 순간부터입니다.

Backend 전체를 clean architecture로 갈아엎어야 할 때
자연발생적으로 자라난 Frontend 구조를 다시 정리해야 할 때
auth, 데이터 모델, 권한, UI까지 한 번에 건드리는 큰 기능을 넣어야 할 때
아무도 하고 싶어 하지 않는 문서화를 해야 할 때

Blitzy는 비용 구조를 뒤집습니다.
대화(인터랙션) 시간을 스펙 작성 시간으로 바꾸고, 수작업 코딩을 장기 자율 실행으로 바꿔요.

AI 코딩이 “내가 엔지니어가 아니라 감독관이 된 느낌”을 준 적 있다면, Blitzy는 일을 인수인계 + 리뷰 모델로 바꿔서 시간을 되돌려주려는 접근이라고 보면 됩니다.

핵심 철학: 스펙 먼저 → 장기 실행 → 신뢰도 높은 PR

대부분의 AI 코딩 에이전트는 이렇게 동작합니다.

Prompt → 짧게 실행 → 결과 → Prompt → 짧게 실행 → 결과 → 반복

Blitzy는 이렇게 갑니다.

Spec → 깊은 이해 → 장기 실행 → PR + 업데이트된 Spec + remaining-work 체크리스트

여기서 “remaining-work 체크리스트”가 핵심이에요.
Blitzy는 “엔지니어링을 건너뛰어도 된다”는 환상을 팔지 않습니다. 목표는 **약 95%**까지 끌어올린 뒤, 마지막 5%를 명확하게 드러내는 것이죠.

그리고 솔직히 말해, 작업이 크면 클수록 95%는 말 그대로 게임 체인저입니다.

Multi-Agent 오케스트레이션: 하나가 아니라 ‘수천 개’

Blitzy는 수천 개의 AI 에이전트가 협업하는 형태로 설명됩니다. 오케스트레이션의 중심에는 세 가지가 있어요.

당신이 쓴 프롬프트/스펙
플랫폼이 이해한 Codebase 컨텍스트
시스템 일부를 실행하고 검증할 수 있는 능력

비유를 들면 이렇습니다.

단일 코딩 어시스턴트는 손이 빠른 “똑똑한 인턴”에 가깝습니다.
Multi-Agent 오케스트레이터는 “팀”에 가깝죠. 누군가는 코드베이스를 탐색하고, 누군가는 의존성을 맵핑하고, 누군가는 구현하고, 누군가는 가정 검증을 하고, 누군가는 문서를 다시 씁니다. 그리고 이게 하나의 계획 아래에서 움직입니다.

그래서 Blitzy는 “IDE 안의 또 다른 어시스턴트”라기보다, 주요 모델 제공자들을 엮은 개발 오케스트레이션 레이어로 포지셔닝됩니다.

Technical Spec: 모든 걸 가능하게 만드는 ‘결정적 산출물’

Blitzy가 처음 만들어내는 건 수백 페이지짜리 Technical Spec(기술 명세)입니다. 여기에는 보통 이런 정보가 담깁니다.

기능(Features)
아키텍처(Architecture)
시스템 경계(System boundaries)
사용 중인 패턴(Patterns)
서브시스템 간 관계(Subsystem relationships)

포함될 수 있는 구성도 꽤 풍부해요.

주요 기능별 섹션(예: student onboarding, mock interview 시스템, roadmap 관리 등)
Backend 아키텍처 패턴과 auth 흐름
API 구조(routes, schemas)
시스템을 읽을 수 있게 만들어주는 그래프, 차트, 다이어그램

이 Spec은 코드 생성 전에도 가치가 있습니다. “레포지토리의 구조화된 설명서”가 되거든요. 사람도, 다른 도구도 이걸 기반으로 더 정확히 일할 수 있습니다.

보너스: Spec을 다른 도구와 함께 쓰는 법

무료 “탐색(exploration)” 단계만 써도 얻는 게 있어요. 생성된 Technical Spec을 Cursor 같은 에디터 워크플로, 로컬 모델 등 다른 AI 도구에 넣으면 일상적인 AI 코딩 품질이 올라갑니다. 신규 합류자에게 주는 “온보딩 문서”처럼도 쓸 수 있고요.

Blitzy는 실제로 어떻게 돌아가나: 4단계 워크플로

Blitzy는 단계별 파이프라인으로 이해하는 게 가장 쉽습니다.

Codebase Ingestion
Codebase Documentation
Full Codebase Refactor
New Feature Development

이제 팀이 실제로 운영하는 방식과 비슷한 흐름으로 하나씩 풀어볼게요.

1단계: Codebase Ingestion (레포 전체를 이해시키기)

목표

Blitzy가 크고 안전한 변경을 할 수 있을 만큼 충분한 컨텍스트를 주는 겁니다.

여기에는 핵심이 두 가지예요.

레포지토리와 브랜치 연결
Blitzy가 동작을 검증할 수 있도록 실행 가능한 Environment 구성

무엇을 하게 되나?

플랫폼에서 보통 이렇게 진행합니다.

New Project 생성
Existing Product 선택
GitHub repository 연결
branch 선택
상세한 설정 지침과 함께 Environment(Linux 또는 Windows) 구성

Environment 설정은 정말 중요합니다. 권장 방식은 이거예요.
신입 주니어 개발자 온보딩 시키듯이 적으세요.

의존성 설치 방법
Backend/Frontend 실행 방법
어떤 명령을 어디서 실행하는지
실행하면 무엇이 보여야 하는지
어떤 secrets/variables가 필요한지

Blitzy는 다음에 접근 권한을 받을 수 있습니다.

environment variables
secret keys(공개 노출은 안 되지만 설정으로 제공)
외부 연동(Integration)

대표적인 예시 구성에서는 Discord 연동, 그리고 auth provider인 Clerk 같은 통합까지 포함해 앱을 end-to-end로 실행할 수 있도록 설정했습니다.
Blitzy가 시스템을 정확히 실행할수록 “안 깨뜨렸다”는 확신도 더 커집니다.

팀 설정

프로젝트는 team에 연결할 수 있고, 리뷰와 지원을 위해 협업자를 추가할 수도 있습니다.

그다음: 짧은 컨텍스트 프롬프트

Environment + 레포 연결이 끝나면, 짧게 이런 내용을 적습니다.

이 프로젝트가 무엇인지
현재 무엇을 하는지
무엇이 가장 중요한지

그러면 인제스트가 시작됩니다.

소요 시간

인제스트는 보통 1~2일(더 걸릴 때도 있음) 걸릴 수 있어요. 결과가 요약본이 아니라 “깊은 Technical Spec”이기 때문입니다. 완료되면 네비게이션이 있는 구조화된 문서와 여러 시각 자료를 확인할 수 있습니다.

처리 규모

Blitzy는 최대 1억(100 million) 라인 코드 이해가 가능하다고 설명됩니다. 아주 큰 모노레포나 엔터프라이즈 시스템까지 염두에 둔 이야기죠.

2단계: Codebase Documentation (레포를 ‘읽히게’ 만들기)

문서화는 필수는 아니지만, 큰 Refactoring 전에 자주 권장됩니다. 이유는 단순해요.
문서가 좋아질수록 모델의 이해도가 올라가고, 그게 다음 결과물 품질로 이어지기 때문입니다.

문서화는 어떻게 진행되나?

다음 메뉴를 누릅니다.

Build → Document Code

그리고 “무엇을, 어떻게” 문서화할지를 담은 documentation prompt를 넣습니다.

흔히 다음처럼 두 번에 나눠 진행합니다.

Backend documentation
Frontend documentation

documentation prompt에는 무엇이 들어가나?

보통 아래 내용을 구체적으로 적습니다.

inline comments를 어디에 추가할지
docstrings 규칙(문장부호, 대문자화, 일관성)
“다른 건 건드리지 마세요” 같은 경계 조건
변수명이나 도메인 용어를 어떻게 존중할지
핵심 폴더(API, auth bot 등)에 대한 README 생성 요청

산출물 형태

Blitzy는 문서화를 Pull Request로 생성합니다(전용 브랜치로 나오는 경우가 많음).

자주 포함되는 결과물은 이런 것들입니다.

다이어그램 렌더링이 가능한 아키텍처 마크다운 파일
데이터 모델 문서
배포/개발 Environment 문서
정리된 docstrings와 inline comments
핵심 컴포넌트 단위 README(예: API, auth bot 등)

이 단계는 Codebase 규모에 따라 다르지만, 프롬프트 작성부터 생성까지 1~2일 정도 걸리는 경우가 많습니다.

3단계: Full Codebase Refactor (진짜 ‘큰 공사’)

Blitzy의 차별점이 가장 뚜렷하게 드러나는 구간입니다.

Blitzy가 노리는 문제: ‘vibe-coded’ 복잡성

Blitzy가 특히 잘 맞는 Codebase는 대개 이런 특징을 가집니다.

로컬 에이전트로 빠르게 만든 큰 애플리케이션
Backend/Frontend를 2~3일 정도의 빠른 반복으로 구축
기능은 빨리 붙었는데, 아키텍처가 못 따라감

전형적인 증상도 뻔합니다.

쓰지도 않는 import가 여기저기 남아 있음
타입을 파일 안에 우겨 넣은 거대한 파일들
과하게 커진 클래스와 함수
제멋대로인 폴더 구조
“돌긴 도는데” 유지보수는 지옥

대표적인 시나리오에서는 멘토십 형태 프로그램을 운영하기 위한 관리 + 학생 성과/업무 이행 시스템이 있었고, 구성 요소로는 이런 것들이 언급됩니다.

로드맵 시스템
지원(애플리케이션) 트래킹
DSA 로드맵
인터뷰 관련 태스크 및 “bags”
학생 진행 상황 관리 도구 전반

기능은 돌아가지만, 큰 변환 없이 기능을 추가하기가 점점 어려워진 상황이죠.

Refactoring 프로세스

Step 1: Backend Refactoring 프롬프트를 ‘제대로’ 쓴다

Backend Refactoring 프롬프트에는 보통 다음을 담습니다.

핵심 목표(core objectives)
- 모듈화(modularity)
- 관심사 분리(separation of concerns)
- 코드 조직화(code organization)
- 유지보수성(maintainability)
- 일관성(consistency)
- 가독성(readability)
“성공”이 무엇인지
디렉터리 구조 기대치
경계/제약 조건

일부러 길고 구체적으로 씁니다. 그래야 Blitzy가 며칠 동안 혼자 일해도 방향이 흔들리지 않거든요.

Step 2: Agent Action Plan을 검토한다

Blitzy는 장기 실행 전에 Agent Action Plan을 먼저 보여줍니다. 대략 이런 내용을 담아요.

무엇을 건드릴지
작업 순서
아카이브/삭제/이동/재작성 여부
프롬프트 목표를 어떻게 달성할지

계획이 마음에 안 들면 수정합니다. 승인해야만 장기 실행이 시작됩니다.

Step 3: 대형 PR을 받는다

Backend Refactoring에서 대표적으로 제시된 PR 규모는 이렇습니다.

추가 21,000라인
삭제 2,000라인

구조적 개선 예시로는 다음이 포함됩니다.

v1 prefix 추가
routes와 schemas 재정리
파일 이동 및 이름 변경
주요 도메인/레이어 재구성
- auth bot
- config
- core
- domain
- services
- use cases
데이터베이스 관련 관심사 분리
- services
- models
- infrastructure
- database

PR이 너무 커서 라인 단위로 즉시 검토하기는 어렵지만, 결과 코드는 전반적으로 깔끔하고 잘 작성되었으며, 요청한 아키텍처에 정렬된 것으로 평가됩니다.

많은 팀이 놓치는 포인트: “remaining work”가 명시된다

큰 Refactoring이 끝나면 Blitzy는 Technical Spec을 업데이트하면서 다음을 포함해 제공합니다.

어떤 작업을 완료했는지
무엇을 검증했는지
하위 호환(backwards-compatibility) 상태(예: routes가 깨지지 않았는지)
commits, 변경된 파일, 추가/삭제 라인 수
그리고 사람이 다음에 해야 할 일

대표적인 remaining work 항목은 다음과 같습니다.

Environment 설정
프로덕션 배포 검증
성능 프로파일링
문서 마감(polish)

이 리스트가 “생성된 코드”와 “실제로 돌아가는 시스템” 사이를 이어주는 다리입니다.

현실적인 사람 투입량

Refactoring이 잘 나와도 사람은 여전히 해야 할 일이 있습니다.

수동으로 동작 검증
작은 설정 오류 수정
routes 1~2개 재연결
대규모 변경에서 생긴 사소한 실수 디버깅

대표 흐름에서는 다음이 언급됩니다.

자동 산출물은 약 95% 정도 정확
작은 이슈 디버깅은 대략 20~30분
Environment 설정 시간은 과장될 때가 있고, 실제로는 “몇 시간”보다 짧게 끝난 케이스가 있었음

Frontend Refactoring: 대체로 더 어렵다

권장되는 순서는 이렇습니다.

Backend부터 끝낸다
그다음 Frontend를 Refactoring한다

복잡도를 줄이고 위험을 분리하기 위한 전략이죠.

Frontend Refactoring은 규모가 더 큽니다.

추가 24,000라인
삭제 5,000라인

시나리오에서는 Frontend가 Backend보다 훨씬 더 “엉켜” 있었고, 그래서 사람 손이 조금 더 들어갔습니다. 생성 후 사람이 한 작업은 대략 1.5시간 정도였고요.

빠진 stylesheet 재연결
깨진 파일 몇 개 수정
잘못된 import 수정

실무적으로는 Cursor 같은 IDE에서 로컬 AI 도움을 받아 마지막 조정을 빠르게 끝내는 워크플로가 언급됩니다.

24,000라인 PR을 멘탈 나가지 않고 리뷰하는 법

이 정도 PR을 “전 라인 정독”하는 건 현실적으로 불가능합니다. 대신 더 안전한 방식은 레이어드 검증이에요.

아키텍처 및 상위 결정 스캔
- 폴더 구조
- 레이어링
- 의존성 방향
- public API 형태
수동으로 시스템 실행
- 핵심 플로우
- auth 흐름
- 중요 화면
두 번째 리뷰어가 sanity pass
staging 배포
staging 검증
프로덕션 반영

대표 시나리오에서는 동료(예: Kenny)가 변경을 리뷰하고 머지했으며, staging과 프로덕션으로 자연스럽게 반영되었습니다.

또 하나 중요한 운영 포인트도 있어요. Refactoring은 며칠 걸릴 수 있으니 팀 개발이 멈추면 안 됩니다. 실제 흐름에서는 팀이 병렬로 작업을 계속 진행하다가, Refactoring PR이 준비되면 머지·동기화하는 식으로 운영했습니다. 즉, 도구가 팀을 “얼려버리지” 않게 한 거죠.

4단계: New Feature Development (Kajabi 유사 코스 플랫폼 만들기)

Codebase 인제스트 → 문서화 → Refactoring까지 끝나면, Blitzy는 청소 도구를 넘어 “신규 제품 기능 출시” 쪽으로도 쓰였습니다.

기능 목표: 완전한 코스 플랫폼

기존 애플리케이션 위에 Kajabi 성격의 코스 플랫폼을 얹는 게 목표였고, 진행 방식은 2개의 프롬프트 / 2개의 PR입니다.

Backend PR
Frontend PR

Backend: Models + API Endpoints

Backend PR에서는 다음이 만들어졌습니다.

데이터 모델(data models)
API endpoints
Kajabi 유사 시스템의 서버 사이드 기반

Frontend: 기존 타입/컴포넌트에 맞춘 UI 구성

Frontend PR에서는 다음이 생성되었습니다.

기존 컴포넌트 라이브러리와 타입에 맞춘 UI 컴포넌트
상당한 코드 규모
- 추가 12,000라인(대표 수치)

실제로 포함된 기능(구체적인 동작)

학습자 경험(Learner Experience)

코스 목록 페이지와 코스 상세 페이지
예시 코스: “How to land interviews as an engineer”
Wistia에 호스팅된 비디오 레슨 재생
레슨 설명
완료 추적(completion tracking)
- 레슨 완료 표시
- 앞/뒤 레슨 이동
- 완료 상태 저장(지속성)

검증 시점에는 썸네일이 없었지만, 핵심 기능은 동작했습니다.

Admin Dashboard(가장 어려운 파트)

코스 플랫폼에서 진짜 난이도는 “콘텐츠 관리”입니다. Admin 영역이 그걸 담당합니다.

포함된 요소는 다음과 같아요.

그룹 기반 접근 제어
접근 권한 부여
- 개별 코스를
- 개별 사용자에게
콘텐츠 구성/정리
- 코스 순서 이동
- 설명 편집
- 하위 토픽·섹션 추가
코스 생성 플로우(예: “new course”)

처음부터 완벽하진 않았습니다. 글리치가 있어 손봐야 했죠. 그래도 검증하고 다음 반복으로 넘어갈 수 있을 만큼은 구현돼 있었습니다.

생산성 관점에서 “무엇이 달라졌나?”

대표적으로, 약 2개월 정도의 활용 구간에서 다음 결과가 언급됩니다.

생성된 코드 총량 61,000라인
6~7개의 Pull Request로 분산
실제 배포 및 운영 반복은 대략 3~4주
사람의 작은 수정 이후 서비스는 라이브로 운영

3명이 함께 레포를 운영하는 팀 기준으로, Blitzy 없이 같은 작업을 하면 추정 작업량은:

약 150시간

Blitzy를 사용했을 때 사람이 실제로 쓴 시간은(검증, 테스트, 배포 중심):

약 6시간

이 격차가 바로 “이 카테고리의 존재 이유”입니다.

“진짜 이득은 AI가 코드를 쓴다는 데 있지 않다. 엔지니어가 가장 좋은 시간을 기계적인 노동에 쓰지 않게 된다는 데 있다.”

그리고 이런 종류의 일도 해금됩니다. 원래는 계속 미루게 되는 것들이죠.

아무도 하고 싶어 하지 않는 전체 문서화
“처음부터 다시 쓰는 게 더 빠를 수도” 싶은 규모의 Refactoring
리소스 부족 때문에 몇 달 동안 backlog에 쌓여 있던 대형 기능

Blitzy는 누구를 위한 도구인가(그리고 누가 아니어야 하는가)

엔터프라이즈를 위한 설계

Blitzy는 개인용 도구로 에디터 에이전트들과 정면 승부를 보려는 포지션이 아닙니다. 타깃은 명확해요.

더 큰 팀
예산이 있는 조직
깊은 분석과 장기 실행이 정당화되는 Codebase

가격 구조(대표 형태)

Free(개인 탐색)
- Codebase 탐색/문서화
- 깊은 Technical Spec 생성
- 해당 Spec을 다른 도구에 재활용해 일상 AI 코딩 품질 개선
Concept Validation: $50K
Structured Pilot: $250K
Enterprise / Transformations
- 더 큰 규모의 도입(상세 가격은 별도 명시 없음)

개인이 취미로 사기엔 부담스러운 가격대입니다. 대신 조직 입장에서는 “몇 주치 엔지니어링 시간”과 비교해 정당화가 될 수 있어요. 혹은 대안이 리스크 큰 재작성, 장기 Refactoring, 수개월 로드맵 지연이라면 더더욱요.

벤더 주도 도입 경험은 보통 이렇게 간다

Blitzy는 엔터프라이즈 지향이라 온보딩도 비교적 “가이드가 있는 편”으로 설명됩니다.

프로세스를 안내하는 미팅
프롬프트/스펙 작성 지원
Agent Action Plan 리뷰
작업 순서 가이드(Backend 먼저, 그다음 Frontend 등)

초반엔 핸드홀딩이 조금 있고, 팀이 숙련도를 쌓으면 점차 셀프 서비스 형태로 넘어가는 흐름입니다.

결과를 잘 뽑는 법: 과장 없이, 실전 프롬프트 가이드

Blitzy는 spec-first입니다. 그래서 “말빨 좋은 한 줄 프롬프트”보다 제대로 된 스펙이 훨씬 중요해요.

강한 프롬프트에서 반복적으로 보이는 포인트는 이렇습니다.

1) “성공”을 정말 성공답게 정의하기

“Refactoring 해줘요”로 끝내지 말고, 성공 기준을 구체적으로 씁니다.

modularity
separation of concerns
네이밍 일관성
깔끔한 디렉터리 레이아웃
유지보수성 + 가독성

2) 경계를 명확히 하기

특히 문서화 작업에서는 더 중요합니다.

“이 폴더들에 inline comments를 추가해 주세요.”
“핵심 디렉터리에 README를 생성해 주세요.”
“런타임 동작은 바꾸지 마세요.”
“관련 없는 모듈은 건드리지 마세요.”

3) 제대로 돌아가는 Environment 제공하기

검증을 원한다면 “돌아가는 환경”이 필요합니다.

setup 명령
기대되는 출력/상태
secrets/variables(안전하게)
Integrations(Discord, Clerk 기반 auth 등)

Environment 정의는, 사실상 “내가 늘 갖고 싶었던 온보딩 문서”라고 생각하면 됩니다.

4) Agent Action Plan을 안전장치로 쓰기

이건 디자인 리뷰처럼 다루세요.

건드려야 할 곳을 제대로 건드리나?
위험한 삭제 제안이 있나?
변경 순서가 합리적인가?
내 아키텍처 목표와 정렬돼 있나?

정말로 “좋은 엔지니어에게 맡길 만한 계획”일 때만 승인하는 게 포인트입니다.

한계와 리스크(공포 마케팅 없이, 현실적으로)

Blitzy의 강점은 동시에 리스크가 생기는 지점이기도 합니다.

1) 완전 자율은 아니다

기대치는 “완벽”이 아니라 **약 95%**입니다. 흔한 후속 작업은 이런 것들이에요.

빠진 routes 재연결
설정 오류 수정
stylesheet 재연결
잘못된 import 수정
대형 기능 산출물의 자잘한 글리치 보정

2) 대형 PR은 리뷰 방식을 바꾼다

라인 리뷰가 불가능하니, 대신 다음이 필요합니다.

아키텍처 중심 리뷰
수동 테스트
staging 검증
두 번째 리뷰어 sanity check

3) 장기 실행 시간은 ‘대가’다

Blitzy 실행은 1~4일 걸릴 수 있습니다. 깊은 작업에는 좋지만, 즉시 반복이 필요한 작업에는 덜 어울릴 수 있어요.

4) Environment와 secrets는 거버넌스가 필요하다

검증을 위해 변수와 키가 필요하다면, 그 설정은 보안 관점에서 민감한 작업입니다. 조직 정책에 맞춘 관리가 전제돼야 합니다.

용어 정리: Blitzy 스타일 워크플로에서 자주 나오는 키워드

Codebase Ingestion: 레포 전체 분석으로 Technical Spec을 만드는 단계(보통 1~2일).
Technical Spec: 기능, 아키텍처, 다이어그램, 시스템 동작을 담은 수백 페이지짜리 “살아있는 문서”.
Environment: Linux/Windows 기반의 실행 가능한 설정(명령, 변수, secrets, Integration 구성 포함).
Documentation Prompt: inline comments, docstrings, README 구조, 범위/경계 조건을 지시하는 프롬프트.
Agent Action Plan: 장기 실행 전 검토·수정 가능한 실행 계획.
PR(Pull Request): 전달 단위. Refactoring과 대형 기능에서는 수만 라인 규모가 될 수 있음.
Vibe Coding: 빠르게 만들긴 쉽지만 장기 유지보수성을 망치기 쉬운 AI 보조 기반의 즉흥 개발(불필요 import, 거대 파일, 구조 불일치 등).

FAQ: 읽고 나면 다들 묻는 질문들

1) Blitzy는 Cursor나 Claude Code랑 사실상 같은 건가요?

아닙니다. Cursor 스타일 도구는 빠른 상호작용과 즉시 반복에 강합니다. Blitzy는 spec-first + 장기 실행으로 큰 PR을 내고, 업데이트된 Technical Spec과 remaining-work 체크리스트까지 함께 주는 모델입니다.

2) Free 티어로는 뭘 할 수 있나요?

Free(탐색) 단계는 Codebase 탐색과 Technical Spec 생성 중심입니다. 이 Spec 자체가 충분히 가치 있고, IDE 안에서 로컬 모델과 함께 쓰면 일상적인 AI 코딩 품질을 끌어올리는 데도 도움이 됩니다.

3) Codebase 인제스트는 얼마나 걸리나요?

보통 1~2일(더 길어질 수도 있음)로 언급됩니다. 결과물이 짧은 요약이 아니라 섹션과 다이어그램까지 포함된 “깊은 Technical Spec”이기 때문입니다.

4) 2만~3만 라인 PR을 팀이 어떻게 안전하게 머지하죠?

전 라인 리뷰는 보통 하지 않습니다. 대신:

아키텍처/상위 결정 리뷰
수동 테스트 실행
최소 1명 이상 추가 리뷰어 sanity pass
staging에서 검증
이후 프로덕션 배포

이런 레이어드 검증 전략이 언급됩니다.

5) 큰 Refactoring 이후엔 어떤 수정이 보통 필요하나요?

대표적인 “사람 마무리”는 다음입니다.

routes 1~2개 재연결
작은 설정 오류 수정
import 수정
stylesheet 재연결
사소한 런타임 글리치 보정

대표 흐름에서는 Backend Refactoring의 작은 이슈 디버깅이 20~30분, 더 무거운 Frontend Refactoring은 후속 작업이 약 1.5시간 정도로 언급됩니다.

6) Refactoring 말고 ‘진짜 기능’도 만들 수 있나요?

네. 대표 예시는 Kajabi 유사 코스 플랫폼입니다.

Backend models + API endpoints
기존 타입/라이브러리에 맞춘 Frontend 컴포넌트
Wistia 기반 비디오 레슨
완료 추적
접근 제어 + 콘텐츠 관리가 포함된 Admin Dashboard

7) 비용을 내고 도입을 진지하게 고려할 팀은 어떤 팀인가요?

대체로 다음 조건을 갖춘 팀입니다.

Codebase가 크고 복잡하다
대규모 Refactoring이 필요하다
로드맵 압박이 크다
엔터프라이즈 툴링 예산이 있다

가격으로는 $50K Concept Validation, $250K Structured Pilot, 그리고 더 큰 Enterprise/Transformations 형태가 언급됩니다.

8) 좋은 결과를 만드는 ‘가장 큰 레버’는 뭔가요?

진짜 스펙을 쓰는 것입니다. 성공 기준을 명확히 하고, 경계를 분명히 하고, 실행 가능한 Environment를 제공하세요.
강한 엔지니어에게 줘도 성공할 것 같은 스펙이 아니라면, 오케스트레이션 플랫폼에게 줘도 성공하기 어렵습니다.

Blitzy 같은 플랫폼을 평가할 때 핵심 질문은 “AI가 코드를 쓸 수 있나?”가 아닙니다. 2026년에는 그건 너무 당연해졌어요.
진짜 질문은 이거죠.

“크고 지저분하고, 영향도가 높은 엔지니어링 작업을 ‘주도적으로’ 맡아서—팀이 실제로 배포할 수 있는 형태로 가져다 줄 수 있는가?”

저작자표시 (새창열림)

'SW > 인공지능' 카테고리의 다른 글

2026년 AI 트렌드 5가지 총정리: 추론 모델·에이전트·멀티모달까지 한 번에 이해하기 (0)	2026.03.31
2026년 AI로 모바일 앱 만드는 법: OnSpace.ai로 iOS·Android 앱 개발부터 앱스토어 배포까지 완벽 가이드 (0)	2026.03.30
2026년 AI 코딩 에이전트 완전 정리: Cloud Agent가 로컬보다 느린 이유와 해결법 (0)	2026.03.27
2026년 AI 시대 소프트웨어 개발 변화 정리: 코드는 쉬워지고 ‘코드 이해력’이 핵심이 된 이유 (0)	2026.03.25
OpenClaw 24시간 자동화 세팅법: Codex와 Opus 병행으로 비용 줄이는 실전 전략 (0)	2026.03.20

현재글Blitzy(Blitz)란? 엔터프라이즈 AI 코딩 플랫폼으로 대규모 Refactoring을 PR로 받는 방법