지난해 우리는 $2백만 규모의 플랫폼을 출시했습니다. 전체 엔지니어링 팀은? 한 명의 시니어 아키텍트와 Claude Code. 해외 팀도 없고, 계약업체 군대도 없었습니다. 단지 자신이 무엇을 구축하고 있는지 알고 있는 한 사람이 실제 프로덕션 코드를 작성할 수 있는 AI와 페어링된 것입니다.

이것을 쓰는 것은 AI에 과장을 하기 위함이 아닙니다. 나는 과장 사이클로 충분히 상처를 받았습니다. 이것을 쓰는 이유는 이 프로젝트에서 일어난 일이 팀 구성, 프로젝트 추정, 그리고 깊은 아키텍처 지식과 AI 보조 개발을 결합할 때 실제로 무엇이 가능한지에 대해 내 생각을 근본적으로 바꾸었기 때문입니다. 숫자는 거짓을 말하지 않습니다 — 우리는 전통적인 6-8명 엔지니어 팀이 대략 18개월 걸렸을 마일스톤을 5개월 미만에 달성했습니다.

정확히 어떻게 그렇게 했는지 설명해드리겠습니다.

목차

프로젝트: 우리가 실제로 구축한 것

클라이언트 이름은 밝힐 수 없습니다 — NDA 문제입니다 — 하지만 플랫폼을 설명할 수 있습니다. B2B SaaS 물류 플랫폼입니다. 멀티테넌트 아키텍처. 실시간 추적 대시보드. 조직, 팀, 개별 사용자에 걸친 복잡한 역할 기반 접근 제어. 14개의 서로 다른 타사 API 통합 (운송업체, 결제 처리기, 관세 데이터베이스). 고객 대면 포털과 내부 관리 시스템.

전형적인 에이전시 설정에서는 기술 리드, 시니어 개발자 2-3명, 중급 개발자 2명, 전담 DevOps 담당자, 그리고 QA 엔지니어로 인력을 확충할 수 있는 종류의 프로젝트입니다. 다른 에이전시의 클라이언트 원래 추정치는 9명의 팀으로 20개월에 $3.2M이었습니다.

우리는 $2M, 5개월, 한 명의 아키텍트를 제안했습니다. 그들은 우리가 미쳤다고 생각했습니다. 솔직히? 나도 좀 그랬습니다.

전체 팀 대신 한 명의 아키텍트를 선택한 이유

소규모 팀에 대해 반직관적인 것은 다음과 같습니다: 9명 프로젝트에서 통신 오버헤드는 엄청납니다. Fred Brooks는 1975년에 이것을 썼고 여전히 맞습니다. 9명의 엔지니어가 있으면 36개의 잠재적 통신 채널이 있습니다. 회의가 증가합니다. 병합 충돌은 일상의 의식이 됩니다. 누군가는 항상 다른 사람의 PR 검토를 기다리며 차단됩니다.

한 명의 아키텍트라면 전체 시스템 상태는 한 사람의 머리 안에 살고 있습니다. pull request에서 접근 방식을 설명할 때의 컨텍스트 전환 세금은 없습니다. 설계-위원회도 없습니다. 2시간 스프린트 계획 회의도 없습니다.

하지만 한 사람은 빠르게 입력할 수 있을 만큼만 할 수 있습니다. 한 사람은 작업 메모리에 많은 파일을 들고만 있을 수 있습니다. 한 사람은 오후 6시에 지치고 오후 8시쯤 실수를 합니다.

여기가 Claude Code가 들어오는 곳입니다. 아키텍트의 대체가 아니라, 강력한 승수로서. 아키텍트는 모든 결정을 내립니다. Claude Code는 4-5명의 개발자가 필요한 속도로 실행합니다.

아키텍트의 역할

우리 아키텍트 — Marcus라고 부르겠습니다 — 은 15년의 경험이 있습니다. 그는 이 규모의 시스템을 이전에 구축했습니다. 이 프로젝트에서 그의 일은:

  • 시스템 설계 및 아키텍처 결정
  • 모듈 경계 및 데이터 계약 정의
  • 핵심 경로 코드 작성 (인증, 결제 처리, 데이터 파이프라인 오케스트레이션)
  • Claude Code가 생성한 모든 것 검토 및 정제
  • 인프라 및 배포 아키텍처
  • 보안 감사

그가 하지 않은 일: 보일러플레이트 CRUD 엔드포인트 작성, 디자인의 UI 컴포넌트 구축, 직관적인 로직에 대한 단위 테스트 작성, 데이터베이스 마이그레이션 생성, 또는 새 서비스 스캐폴딩. Claude Code가 이 모든 것을 처리했습니다.

Claude Code가 실제 워크플로우에 어떻게 맞는지

"Claude Code 사용"이 실제로 매일 어떻게 보였는지 구체적으로 설명하겠습니다. 마케팅 자료는 현실을 포착하지 못하기 때문입니다.

Marcus는 매일 아침 하루의 일을 구조화된 방식으로 정의하는 것으로 시작했습니다. "사용자 관리 시스템을 구축해줄래"라는 모호한 프롬프트가 아닙니다. 대신 "아키텍처 브리프"라고 부르기 시작한 것을 만들었습니다 — 다음을 지정하는 상세한 문서:

  1. 모듈의 책임과 경계
  2. 정확한 필드 유형과 관계를 가진 데이터 모델
  3. API 계약 (엔드포인트, 요청/응답 모양)
  4. 비즈니스 규칙 및 엣지 케이스
  5. 오류 처리 기대
  6. 통합해야 할 기존 모듈

그러면 이들을 청크 단위로 Claude Code에 전달했습니다. 전형적인 세션은 다음과 같습니다:

# Marcus는 Claude Code CLI와 함께 프로젝트 디렉토리에서 작업했습니다
# 먼저 컨텍스트 설정
claude "Read through /src/modules/shipment/ and /src/lib/database/schema.ts. 
I need you to understand the existing patterns before we build the 
invoicing module."

# 그러면 아키텍처 브리프를 포함한 실제 빌드 지시
claude "Build the invoicing module following the architecture brief in 
/docs/briefs/invoicing.md. Follow the exact same patterns as the 
shipment module for service layer, repository layer, and route handlers. 
Use the existing error handling middleware. Write tests for all 
business logic in the service layer."

Claude Code는 그런 다음 모듈을 생성했습니다 — 일반적으로 유형, 스키마, 서비스, 저장소, 경로 핸들러, 미들웨어, 테스트를 포함한 15-30개 파일. Marcus는 출력을 검토하고 수정을 했으며 반복했습니다. 중간 복잡도의 모듈에 대한 전체 주기는 시니어 개발자가 걸렸을 2-3일 대신 약 2-3시간이 소요되었습니다.

반복 루프

여기 AI 보조 개발에 대해 아무도 말해주지 않는 것이 있습니다: 첫 번째 출력은 거의 프로덕션 준비가 되어있지 않습니다. 대략 70-80%입니다. 하지만 남은 20-30%는 아키텍트의 전문 지식이 가장 중요한 곳입니다.

Marcus는 리듬을 개발했습니다:

  1. 생성 — Claude Code가 초기 구현을 생성합니다
  2. 검토 — Marcus는 모든 파일을 읽고 문제를 표시합니다
  3. 정제 — Claude Code로 다시 전달된 특정 수정
  4. 강화 — Marcus는 수동으로 보안 중요 섹션을 처리합니다
  5. 테스트 — 생성된 테스트를 실행하고, Claude가 놓친 엣지 케이스를 추가합니다

이 루프는 일반적으로 모듈당 2-3 사이클로 진행되었습니다. 프로젝트의 3개월차까지, Claude Code는 초기 첫 통과 코드가 프로덕션 준비된 것의 85-90% 더 가까웠습니다. 코드베이스가 따라갈 충분한 패턴을 확립했기 때문입니다.

기술 스택과 아키텍처 결정

AI 보조 생산성을 극대화하기 위해 스택을 의도적으로 선택했습니다:

  • Next.js 14 (App Router) — 고객 포털 및 관리 대시보드용
  • Node.js with Fastify — API 계층용 (Next.js와 별도)
  • PostgreSQL — 주 데이터베이스
  • Redis — 캐싱, 세션 관리, 실시간 pub/sub
  • Drizzle ORM — 타입 안전 데이터베이스 접근
  • Turborepo — 모노레포 관리
  • Vercel — 프런트엔드 배포
  • AWS (ECS Fargate) — API 및 백그라운드 워커

Next.js를 선택한 이유는 패턴이 잘 확립되어 있고 Claude Code가 App Router 관례에 대한 깊은 훈련 데이터를 가지고 있기 때문입니다. 이것은 사람들이 생각하는 것보다 더 중요합니다. 우리가 Rust 기반 백엔드와 HTMX 같은 이국적인 것을 선택했다면, AI 출력 품질이 크게 떨어졌을 것입니다. 대규모 Next.js 개발 방법에 대해 더 알아볼 수 있습니다.

Drizzle ORM은 이 프로젝트에서 Prisma에 대한 의도적인 선택이었습니다. Claude Code는 Drizzle 스키마를 더 잘 생성합니다. 왜냐하면 그들은 단지 TypeScript이기 때문입니다 — 잘못 얻을 사용자 정의 DSL 없습니다. 또한 빠르게 많은 스키마 변경을 생성할 때 마이그레이션 스토리가 더 간단합니다.

// 예: Claude Code가 이 송장 스키마를 생성했습니다
// 최소한의 수정이 필요한 첫 통과
import { pgTable, uuid, varchar, decimal, timestamp, pgEnum } from 'drizzle-orm/pg-core';
import { relations } from 'drizzle-orm';
import { shipments } from './shipments';
import { organizations } from './organizations';

export const invoiceStatusEnum = pgEnum('invoice_status', [
  'draft', 'pending', 'sent', 'paid', 'overdue', 'cancelled', 'refunded'
]);

export const invoices = pgTable('invoices', {
  id: uuid('id').primaryKey().defaultRandom(),
  organizationId: uuid('organization_id').notNull().references(() => organizations.id),
  shipmentId: uuid('shipment_id').references(() => shipments.id),
  invoiceNumber: varchar('invoice_number', { length: 50 }).notNull().unique(),
  status: invoiceStatusEnum('status').notNull().default('draft'),
  subtotal: decimal('subtotal', { precision: 12, scale: 2 }).notNull(),
  taxAmount: decimal('tax_amount', { precision: 12, scale: 2 }).notNull().default('0'),
  totalAmount: decimal('total_amount', { precision: 12, scale: 2 }).notNull(),
  currency: varchar('currency', { length: 3 }).notNull().default('USD'),
  dueDate: timestamp('due_date', { withTimezone: true }).notNull(),
  paidAt: timestamp('paid_at', { withTimezone: true }),
  createdAt: timestamp('created_at', { withTimezone: true }).notNull().defaultNow(),
  updatedAt: timestamp('updated_at', { withTimezone: true }).notNull().defaultNow(),
});

export const invoiceRelations = relations(invoices, ({ one, many }) => ({
  organization: one(organizations, {
    fields: [invoices.organizationId],
    references: [organizations.id],
  }),
  shipment: one(shipments, {
    fields: [invoices.shipmentId],
    references: [shipments.id],
  }),
  lineItems: many(invoiceLineItems),
}));

Claude Code가 잘한 것

구체적으로 말하겠습니다. Claude Code가 진정으로 개발을 가속화한 곳:

보일러플레이트 및 CRUD 작업

이것이 명백한 것입니다. REST 엔드포인트 생성, 요청 검증 스키마 (우리는 Zod를 사용했습니다), 응답 직렬화기, 기본 서비스 메서드 — Claude Code는 이것들을 몇 분 안에 완성했습니다. 프로젝트 전체에 걸쳐 대략 180개의 API 엔드포인트가 있었습니다. 아마도 140개는 Claude Code가 최소한의 수정으로 생성한 표준 CRUD 또는 쿼리 작업이었습니다.

테스트 생성

Claude Code는 프로젝트 전체에 대략 2,400개의 테스트를 작성했습니다. 모두 완벽했나? 아니오. 약 15%는 상당한 재작업이 필요했습니다. 하지만 테스트 스위트의 85%가 생성되고 작동하는 것은 엄청난 시간 절약입니다. Marcus는 통합 테스트와 Claude Code가 예상할 수 없었던 복잡한 엣지 케이스에 자신의 테스트 에너지를 집중했습니다.

UI 컴포넌트 개발

고객 포털에는 약 60개의 고유한 페이지 뷰가 있었습니다. 각각에 대해 Marcus는 Figma 디자인 참고와 API 계약을 제공하면, Claude Code는 React 컴포넌트, 데이터 페칭용 훅 (우리는 TanStack Query를 사용했습니다), React Hook Form + Zod를 사용한 폼 처리, 그리고 로딩/오류 상태를 생성했습니다. 출력은 일관되게 좋았습니다 — 첫 생성에서 아마도 75% 픽셀 정확도.

데이터베이스 마이그레이션 및 스키마 진화

요구사항이 진화함에 따라 (그들은 항상 진화합니다), Claude Code는 스키마 마이그레이션을 원활하게 처리했습니다. 필요한 변경을 설명하면 마이그레이션 파일을 생성하고, 스키마를 업데이트하고, 영향을 받는 쿼리를 조정하고, TypeScript 타입을 조정합니다. 45분의 신중한 리팩토링 세션이 10분의 검토-및-승인 사이클이 되었습니다.

문서

Claude Code는 API 문서, 인라인 코드 주석, README 파일, 그리고 작업 러북 문서를 생성했습니다. Marcus는 검토하고 조정했지만, 기본 출력은 진정으로 유용했습니다. 우리는 90%의 프로젝트보다 더 나은 문서로 끝났습니다. 단순히 생성 비용이 너무 낮았기 때문입니다.

Claude Code가 실패한 부분과 우리가 한 일

이 섹션은 성공 스토리보다 더 중요합니다. 이런 식으로 AI를 사용할 계획이라면, 벽이 어디 있는지 알아야 합니다.

여러 종속성이 있는 복잡한 비즈니스 논리

배송 라우팅 엔진 — 운송업체 가용성, 비용 최적화, 관세 요구사항, 배송 윈도우, 용량 제약을 동시에 고려해야 하는 — 은 Claude Code가 잘 처리할 수 있는 범위를 벗어났습니다. 타당해 보이는 것을 생성하지만 실제 돈을 잃을 수 있는 미묘한 논리 오류가 있었습니다.

Marcus는 이 모듈을 수동으로 작성했습니다. 약 2주가 소요되었습니다. 이것이 정확히 시니어 아키텍트를 두는 것이 정당화하는 일의 종류입니다. 모든 것을 AI로 처리하려고 하는 것보다.

보안 중요 코드

우리는 라인별 검토 없이 auth 흐름, 결제 처리, 또는 암호화에 대해 Claude Code를 신뢰한 적이 없습니다. 그리고 잘한 일입니다 — ORM을 사용했음에도 불구하고 입력을 데이터베이스 쿼리 전에 올바르게 새니타이즈하지 않거나 토큰 만료 클록 스큐를 놓친 JWT 검증을 생성했습니다.

경험상: 이 코드의 버그가 돈을 잃거나 데이터를 노출할 수 있으면, 인간이 그것을 작성하고 다른 인간이 그것을 검토합니다.

장거리 아키텍처 일관성

3개월차까지 코드베이스는 Claude Code가 "잊어버리기"할 만큼 커졌으며, 제공된 컨텍스트에도 불구하고 이전에 확립된 패턴을 "잊어버렸습니다". 한 모듈에서 다른 모듈과 다른 오류 처리 접근 방식을 사용할 수 있습니다. Marcus는 이런 불일치를 포착하는 데 주의했습니다.

우리는 모든 Claude Code 세션에 포함된 살아있는 "관례" 문서를 유지하여 이를 완화했습니다. 아키텍처 패턴에 대한 스타일 가이드라고 생각하세요.

성능 최적화

Claude Code는 작동하는 코드를 생성하지만 빠른 코드를 생성하지는 않습니다. N+1 페치를 수행하는 데이터베이스 쿼리. 불필요하게 다시 렌더링하는 React 컴포넌트. 필요한 것보다 더 많은 데이터를 로드하는 API 엔드포인트.

Marcus는 검토 시간의 대략 20%를 성능 최적화에 소비했습니다. 문제가 되지는 않지만, 예산에 포함해야 할 사항입니다.

경제성: 비용 분석 및 ROI

여기 모두가 보고 싶어하는 부분입니다. 실제 숫자.

비용 카테고리 전통적 팀 (추정) AI 가속 (실제)
엔지니어링 급여 (18개월 / 5개월) $1,890,000 $175,000
Claude Code API / 구독 $0 $12,400
인프라 (개발/스테이징) $48,000 $8,200
프로젝트 관리 $216,000 $0*
QA / 테스팅 $180,000 $22,000**
디자인 (계약) $120,000 $95,000
DevOps / 인프라 설정 $96,000 $35,000
총계 $2,550,000 $347,600

Marcus는 Linear를 사용하여 작업 추적을 자체 관리했습니다. PM 오버헤드 없음.

*최종 6주에 QA 전문가를 계약했습니다.

Claude Code 비용은 대략 $2,500/월로 분석됩니다. 이는 Max 플랜 ($월 $100) 플러스 확장 세션의 API 비용입니다. 일부 날짜 Marcus는 무거운 생성 세션 중에 API 호출에서 $150-200을 태울 것입니다. 대부분의 날짜는 $40-80이었습니다.

프로젝트는 $2M으로 청구되었습니다. 우리의 총 배송 비용은 $350K 미만이었습니다. 당신이 마진 수학을 하도록 놔두겠습니다.

속도 비교

마일스톤 전통적 타임라인 AI 가속 타임라인
아키텍처 & 설계 6주 3주
코어 플랫폼 (인증, 멀티테넌시, 기본 API) 10주 3주
기능 개발 (모든 모듈) 32주 10주
통합 (14 타사 API) 12주 4주
테스팅 & QA 8주 3주
배포 & 강화 4주 2주
총계 72주 25주

AI 가속 개발을 고려하는 팀을 위한 교훈

이 프로젝트 후, 나는 이것이 우리가 앞으로 소프트웨어를 구축하는 방식에 대해 무엇을 의미하는지 많이 생각해왔습니다. 이 접근 방식을 고려하는 모든 팀이나 에이전시에 말해주고 싶은 것입니다.

시니어 아키텍트가 여전히 필요합니다. 아마도 이전보다 더.

AI는 전문 지식의 필요성을 제거하지 않습니다 — 당신이 가져오는 전문 지식 (또는 그 부족)을 증폭합니다. Claude Code를 사용하는 주니어 개발자는 더 빠르게 주니어 품질 코드를 배송할 것입니다. Claude Code를 사용하는 시니어 아키텍트는 이전에 불가능했던 속도로 시니어 품질 코드를 배송할 것입니다.

최악의 시나리오는 자신이 시니어라고 생각하는 중급 개발자가 AI를 사용하여 제대로 평가할 수 없는 코드를 생성하는 것입니다. 그것이 바로 표면상 좋아 보이지만 로드 하에서 무너지는 코드베이스를 얻는 방법입니다.

관례 우선, 모든 곳

코드베이스의 패턴이 예측 가능할수록 AI의 성능이 향상됩니다. 우리는 모든 모듈에서 동일한 파일 구조, 이름 지정 규칙, 코드 조직을 사용했습니다. 이 일관성은 Claude Code가 기존 패턴과 일치하는 방법을 배우면서 엄청난 배당금을 지불했습니다.

헤드리스 CMS 아키텍처로 작업할 때, 콘텐츠 유형, API 경로, 컴포넌트 구조에 대한 엄격한 규칙을 가지면 AI 생성 코드가 극적으로 더 안정적입니다.

아키텍처 브리프에 투자

Claude Code의 출력 품질은 Marcus의 아키텍처 브리프 품질과 직접적으로 상관관계가 있었습니다. 모호한 지시 사항은 모호한 코드를 생성했습니다. 명확한 데이터 모델, 비즈니스 규칙, 통합 요구사항을 포함한 상세한 브리프는 프로덕션 준비에 가까운 코드를 생성했습니다.

우리는 Marcus가 아키텍처 브리프 작성 및 출력 검토에 약 30%의 시간을 소비했고, 전통적인 팀이 실제 구현에 소비했을 70%가 Claude Code에 의해 처리되었다고 추정합니다.

AI 보조 개발은 가격 책정 모델을 변경합니다

에이전시라면, 이것은 불편한 대화입니다. 한 명의 아키텍트가 과거에 8명의 팀이 필요했던 것을 배송할 수 있으면 어떻게 가격을 책정합니까? 우리는 가치 기반 가격 책정을 믿습니다 — 클라이언트는 시간이 아닌 결과에 대해 비용을 지불합니다. 플랫폼은 1명이든 10명이 구축하든 $2M의 가치가 있습니다.

귀사 프로젝트가 이런 방식의 접근 방식이 어떻게 작동할 수 있는지 궁금하면, 우리의 가격 책정 페이지는 이 새로운 현실에서 프로젝트 범위를 어떻게 생각하는지 분석합니다.

모든 프로젝트가 이 모델에 맞지는 않습니다

이것이 작동한 이유:

  • 요구사항이 명확하게 정의되었습니다 (물류는 성숙한 도메인입니다)
  • 진정한 시니어 아키텍트를 사용할 수 있었습니다
  • 기술 스택은 주류였습니다 (훌륭한 AI 훈련 데이터)
  • 클라이언트는 팀 규모를 마이크로 관리하지 않고 배송을 신뢰했습니다

모호한 요구사항, 무거운 R&D 컴포넌트, 또는 전문 도메인 (의료 기기, 규제 요구사항이 있는 금융 상품)이 있는 프로젝트는 더 많은 인간 판단이 필요하며 그에 따라 인력을 배정해야 합니다.

Astro 같은 프레임워크로 구축된 프로젝트에서는 생태계가 새롭고 AI 훈련 데이터가 더 얇아서 React/Next.js 프로젝트와 비교하여 AI 도구에서 더 적은 가속도를 볼 것입니다.

FAQ

Claude Code는 실제로 월간 많은 개발 사용에 얼마나 비용이 드나요?

이 프로젝트에서는 월평균 $2,500를 모두 합쳤습니다. Claude Max 구독은 $100/월입니다 (또는 2025년 초 현재 더 높은 계층의 경우 $200/월). API 사용 Claude Code의 에이전트 세션의 경우 생성된 코드의 양에 따라 달라집니다. 무거운 날짜는 API 비용에서 $150-200을 날립니다. 가벼운 검토-및-정제 날짜는 $40-80이었습니다. Anthropic은 또한 상당한 사용이 포함된 Max 플랜을 $200/월로 도입했으며, 이는 변수 비용을 줄일 수 있습니다.

주니어 개발자가 같은 방식으로 Claude Code를 사용할 수 있나요?

아니요, 그리고 이것이 중요합니다. Claude Code는 기존 기술 수준을 증폭합니다 — 아키텍처 지식을 대체하지 않습니다. 주니어 개발자는 Claude Code를 더 빠르게 코드를 생성할 것입니다. 하지만 시니어 엔지니어가 즉시 포착하는 미묘한 버그, 보안 문제, 성능 문제, 또는 아키텍처 불일치는 포착하지 못할 것입니다. 출력을 수락하는 것이 아니라 평가할 수 있는 누군가가 필요합니다.

코드 품질에 대해 — AI 생성 코드는 유지보수 가능한가요?

당신이 부여하는 제약 조건에 전적으로 달려있습니다. 우리가 생성한 코드는 인간이 작성한 코드와 동일한 린팅 규칙, 타입 확인, 코드 검토 표준을 통과했습니다. 트릭은 프로젝트 초기에 강력한 패턴을 설정하여 AI가 따라갈 좋은 예를 가지도록 하는 것입니다. 우리는 모든 Claude Code 세션에 포함된 관례 문서를 유지했습니다. 6개월 후 출시 후 플랫폼을 유지하는 팀은 비정상적인 유지보수 부담을 보고하지 않았습니다.

이 접근 방식은 프런트엔드 헤비 프로젝트에 대해 작동하나요?

주의 사항이 있지만 예. Claude Code는 React 컴포넌트, 폼 처리, 데이터 페칭 훅, 상태 관리 코드 생성에 뛰어나다는 것입니다. 디자인에서 픽셀 완벽한 CSS 레이아웃을 생성하는 데는 덜 안정적입니다 — 시각적 광택을 위해 더 많은 반복 사이클이 필요합니다. 우리는 백엔드 코드의 85-90%와 비교하여 첫 통과 UI 생성에 대해 약 75% 정확하다는 것을 발견했습니다.

유일한 개발자만 있을 때 코드 검토를 어떻게 처리하나요?

Marcus는 AI 생성 코드의 모든 라인을 자신이 검토했습니다. 우리는 또한 프로젝트 중 (주 12, 주 22)에 두 개의 집중 감사 세션에 대해 계약된 보안 전문가를 가져왔습니다. 최종 단계에서 6주 동안 QA 전문가가 참여했습니다. 동료 코드 검토 부족은 진정한 위험입니다 — 자동화된 도구 (TypeScript strict mode, 공격적인 규칙을 가진 ESLint, 적용 범위 임계값이 있는 Vitest)와 외부 감사로 완화했습니다.

Claude Code가 버그가 많은 코드를 생성하면 어떻게 되나요?

정기적으로 발생합니다. 첫 통과는 거의 완벽하지 않습니다. 우리는 이 기대를 워크플로우에 구축했습니다 — 생성, 검토, 정제, 강화. 대부분의 버그는 Marcus의 검토 사이클 중에 포착되었습니다. 자동화된 테스트 스위트 (또한 크게 AI 생성이지만 인간이 검토함)는 회귀 문제를 포착했습니다. 핵심 통찰은 AI 생성 코드를 디버깅하는 것이 처음부터 올바른 코드를 작성하는 것보다 빠르다는 것입니다. 대부분 맞는 것에서 시작하기 때문입니다.

이것이 그린필드 프로젝트에만 적용되나요, 또는 기존 코드베이스에서도 작동하나요?

Claude Code는 실제로 기존 코드베이스에서 잘 작동합니다. 기존 패턴을 읽고 이해할 수 있기 때문입니다. 이 프로젝트에서 이후 모듈은 이전 모듈을 참고로하여 이득을 얻었습니다. 우리는 이미 좋은 결과를 가지고 기존 클라이언트 프로젝트에 기능 추가로 Claude Code를 사용하고 있습니다. 핵심은 기존 관례와 패턴에 대한 충분한 컨텍스트를 제공하는 것입니다. 코드베이스가 불일치하거나 문서가 부실하면 AI 생성 추가는 그런 불일치를 상속합니다.

다시 이렇게 하실 건가요?

절대적으로. 우리는 이미 그렇게 하고 있습니다. 2개의 더 많은 프로젝트가 이 모델로 현재 실행 중입니다 — 한 명의 아키텍트를 가진 것, 더 복잡한 시스템에 대해 2명의 엔지니어를 가진 다른 것. 경제학은 무시하기에는 너무 강합니다. 하지만 명확히 하고 싶은 것은: 이것은 개발자를 대체하는 것에 대한 것이 아닙니다. 시니어 아키텍트의 출력에 대한 무언가의 비율을 바꾸는 것에 대한 것입니다. 당신은 여전히 인간의 전문 지식이 필요합니다. 당신은 단지 더 적은 인간 타이핑이 필요합니다. 프로젝트를 고려하고 있고 이 모델이 어떻게 보일 수 있는지 탐색하고 싶으면, 우리에게 연락 해주세요 — 그것이 맞는지 통해 이야기하기 위해 행복하게 기꺼이 합니다.