왜 AI 코딩 도구는 MVP를 과잉 엔지니어링하는가 — 그리고 단 하나의 해결책

요약(TL;DR) — 가역적(reversible)이고 단계에 민감한(stage-sensitive) 엔지니어링 결정에 대해, AI 어시스턴트는 비즈니스 컨텍스트(business context)를 명시하지 않으면 기본적으로 프로덕션 등급(production-grade)의 조언을 제공합니다. 이는 단순히 기다린다고 해결될 모델 지능(model intelligence)의 문제가 아닙니다. 이는 다음 프롬프트에서 바로 수정할 수 있는 목적 함수(objective-function)의 문제입니다. 아래에는 그 메커니즘(적절한 완충 장치 포함), 전/후 예시, 그리고 "컨텍스트(context)"가 실제로 무엇을 의미하는지에 대한 구체적인 분류 체계가 있습니다.

1. 아마도 50번쯤 보셨을 장면
   사용자 5명. MVP 단계. 가설 검증(Hypothesis validation)만이 유일하게 중요한 시점입니다. 당신은 Claude Code에게 보안 리뷰를 요청합니다. 결과는 다음과 같습니다: "데이터베이스를 별도의 VPC로 이동하고 VPC Peering 또는 PrivateLink를 사용하세요." "모든 외부 호출을 자동화된 인증서 로테이션이 포함된 mTLS로 감싸세요." "SOC2 준비를 위해 감사 로그(audit logs)를 별도의 AWS 계정으로 스트리밍하세요."

이 중 틀린 것은 하나도 없습니다. 하지만 이 단계에서 이 모든 것을 수행한다면, 제품을 원하는 사람이 있는지 검증하기도 전에 인프라 마이그레이션(infra migration)에 자금을 탕진하게 될 것입니다. 동일한 패턴이 보안 외의 영역에서도 나타납니다:

• 초당 요청 수(RPS)가 30인 서비스에 읽기 복제본(read replicas)이 포함된 Redis 클러스터 추천
• 100줄짜리 스크립트에 제안된 육각형 아키텍처 (Hexagonal architecture)
• 3인 팀에게 권장되는 GitOps + ArgoCD + Terraform 모듈 분리

보통 다음과 같은 결론이 뒤따릅니다: "AI는 트레이드오프(trade-offs)를 할 수 없다. 인간이 결정해야 한다." 방향은 맞습니다. 하지만 진단이 행동에 옮기기에는 너무 모호합니다. 그러니 범위를 좁혀봅시다.

2. 주장 범위 설정
   이 글은 특정 부류의 결정에 관한 것입니다: 가역적이고 단계에 민감한 결정.
   가역적(Reversible): 데이터를 잃거나, 사용자와의 계약을 깨거나, 코드베이스의 절반을 다시 작성하지 않고도 취소할 수 있는 것. (Redis를 추가하는 것은 가역적입니다. 기본 키(primary key) 전략을 변경하는 것은 그렇지 않습니다.)
   단계 민감형(Stage-sensitive): 정답이 보편적인 베스트 프랙티스(best practice)가 아니라, 당신이 현재 어느 단계(MVP / 성장 / 확장)에 있는지에 따라 달라지는 것.

(캐싱 레이어(Caching layers), 인증 강화 수준(auth hardening depth), 관측 가능성 깊이(observability depth), 인프라 토폴로지(infra topology).) 되돌릴 수 없거나 단계에 민감하지 않은 결정들 — DB 엔진, 공개 API 계약(public API contracts), 인증 모델(auth model), 멀티 테넌시 경계(multi-tenancy boundaries), 개인정보(PII)나 결제에 영향을 미치는 모든 것 — 에 대해서는 AI의 보수적인 반사 작용이 정답에 더 가깝습니다. 이 내용은 섹션 6에서 다룹니다. 범위 내에서의 주장은 다음과 같습니다: AI 어시스턴트는 기본적으로 프로덕션 등급(production-grade)의 조언을 제공한다는 것입니다. 이를 변경할 수는 있지만, 오직 당신의 단계, 규모, 그리고 트레이드오프(trade-off) 가중치를 명시적으로 언급함으로써만 가능합니다.

3. 일반적인 진단이 부족한 이유

"AI는 코드베이스만을 컨텍스트(context)로 가지기 때문에 트레이드오프에 대해 추론할 수 없다." 이 프레임워크에는 세 가지 문제가 있습니다.

(a) 트레이드오프는 가치 판단(value judgments)이지, 능력 테스트가 아닙니다. 위험 선호도, 시간 선호도, 자본 할당 — 이것들은 목적 함수(objective-function)의 정의이지, 모델이 코드만으로 도출할 수 있는 것이 아닙니다. 동일한 코드를 읽는 두 명의 시니어 엔지니어가 서로 반대되는 결론에 도달할 수 있습니다. CTO는 "출시하라"고 말하고, 보안 책임자는 "안 된다"고 말합니다. 어느 쪽이 더 똑똑한 것이 아닙니다. 그들은 서로 다른 함수를 최적화하고 있는 것입니다. 목적을 명시하지 않고 AI에게 "트레이드오프를 해달라"고 요청하는 것은 손실 함수(loss function) 없이 최적화를 하라고 요청하는 것과 같습니다.

(b) 당신은 컨텍스트를 제공할 수 없는 것이 아닙니다. 제공하지 않기로 선택한 것입니다. 모든 주요 코딩 어시스턴트에는 컨텍스트 주입 슬롯이 있습니다: CLAUDE.md, .cursorrules, AGENTS.md. 대부분의 "AI가 잘못된 권장 사항을 주었다"는 이야기는 적어도 부분적으로는 "사용자가 컨텍스트를 지정하지 않았다"는 이야기입니다. 모든 경우가 그런 것은 아니지만(모델 또한 환각(hallucination)을 일으키거나, 저장소 상태를 놓치거나, 일반적인 안전 편향(safety bias)을 가질 수 있습니다), 사람들이 인정하는 것보다 훨씬 더 그렇습니다.

(c) 인간도 과잉 엔지니어링을 합니다. 시니어 엔지니어들은 과거의 장애(outage)로부터 얻은 트라우마를 가지고 있으며, 코드에 미리 방어 기제를 구축합니다. AI의 과잉 엔지니어링과 인간의 과잉 엔지니어링은 서로 다른 실패 모드(failure modes)를 가집니다. AI는 보일러플레이트 강화(boilerplate hardening)로 향하는 경향이 있고, 인간은 끈적한 추상화(sticky abstractions)로 향하는 경향이 있지만, 둘 다 자동으로 되돌리기 쉬운 것은 아닙니다. 진짜 축은 AI 대 인간이 아닙니다. 그것은 컨텍스트를 인지하는 결정(context-aware decisions) 대 컨텍스트를 인지하지 못하는 결정(context-blind decisions)입니다.

가설: 프로덕션 단계에 성숙한 데이터의 우선순위

여기서 저는 조심스럽게 접근해야 합니다. 연구실 외부의 누구도 학습 데이터의 혼합(training mixes)을 확실히 알지 못하기 때문입니다. 하지만 이 모델들에 무엇이 공급되는지에 대한 공개적으로 확인 가능한 후보들은 편향되어 있습니다:

• 별점이 높은 GitHub 저장소 (이미 규모가 커졌고, 이미 견고해진 상태)
• 벤더 문서 (AWS, GCP, k8s) — MVP 코드가 아닌 베스트 프랙티스(best-practice) 중심의 산문
• 추천수가 높은 Stack Overflow 답변 (종종 "견고한 방식"을 제시)
• 기술 블로그의 사후 분석(post-mortems) ("우리가 이렇게 했어야 했다"는 내용)

이들이 공유하는 공통점은 다음과 같습니다: 이들은 확장성(scale), 신뢰성(reliability), 그리고 컴플라이언스(compliance) 어휘가 필요할 만큼 충분히 오래 살아남은 코드를 기록합니다.

MVP 형태의 코드 — 단일 파일 Flask 앱, 10개의 환경 변수가 포함된 docker-compose.yml, 단일 RDS 인스턴스, 수동으로 만든 세션 쿠키(hand-rolled session cookies) — 역시 학습 데이터에 존재하지만, 그에 부착된 조언 형태의 산문은 드뭅니다. 모델은 "이것을 강화해야 합니다"라는 문장을 "이 정도면 지금은 괜찮습니다"라는 문장보다 훨씬 더 많이 읽었습니다. 이것은 기여 요인에 대한 가설이지, 증명된 메커니즘은 아닙니다.

출력 결과는 또한 인스트럭션 튜닝(instruction tuning), RLHF, 시스템 프롬프트(system prompts), 그리고 안전 정책(safety policies)을 반영하며, 이 중 어느 것이라도 독립적으로 신중함(caution)을 유도할 수 있습니다. 하지만 이는 관찰된 행동과 일치하며, 테스트가 가능합니다. 섹션 5에서 전/후(before/after)를 직접 확인해 보십시오.

보안 검토(Security review)는 이 효과를 증폭시킵니다. 위협 카탈로그(Threat catalogs, 예: OWASP, CVE)는 구조적으로 잘못된 일들의 목록입니다. 이러한 데이터로 집중 학습된 모델이 위협 모델(threat model) 없이 "이것이 안전한가요?"라는 질문을 받으면, 더 많은 결과(findings)를 찾아내도록 주저하게 됩니다. 모델이 양방향 중 어느 쪽으로 틀렸을 때의 비용을 산정할 수 없을 때, 오탐(false positives)이 증가합니다.

5. 전/후 (Before / After) — 동일한 모델, 다른 컨텍스트

여기가 실제 해결책입니다. 동일한 모델 (Claude Sonnet 4.6), 동일한 프롬프트, 동일한 코드입니다. 유일한 차이점은 비즈니스 컨텍스트(business context)가 제공되었는지 여부입니다.

검토 대상 코드: JSON 페이로드(payload)를 수락하고, Postgres에서 이메일로 사용자를 조회한 뒤, JWT를 반환하는 60줄짜리 Express 엔드포인트입니다.

이전 — 컨텍스트 없음
프롬프트(Prompt): "이 엔드포인트의 보안을 검토해 주세요."
응답 (의역됨, 전형적인 형태):

• Redis 토큰 버킷(token bucket)을 사용하여 속도 제한(rate limiting) 추가
• JWT 비밀키를 AWS Secrets Manager로 이동
• 서비스와 데이터베이스 간에 mTLS 강제 적용
• 모든 인증 시도를 별도의 AWS 계정에 감사 로그(Audit-log)로 기록
• 로드 밸런서(load balancer) 앞에 WAF 추가
• 폐기 목록(revocation list)을 포함한 리프레시 토큰 로테이션(refresh token rotation) 구현
• 반복적인 실패 시 CAPTCHA 추가
  일곱 가지 권장 사항. 절대적인 관점에서 틀린 것은 없습니다. 모두 Series A 단계를 지난 기업에 적합한 규모입니다.

이후 — 컨텍스트 포함
프롬프트(Prompt)에 다음 단락을 추가하십시오 (또는 CLAUDE.md에 추가):
단계: MVP, 사용자 50명, 1인 개발자, 월 $200 인프라 예산, 8개월의 런웨이(runway). 위협 모델(Threat model) 범위: OWASP Top 10 중 인젝션(Injection, A03), 취약한 인증(Broken Authentication, A07), 민감한 데이터 노출(Sensitive Data Exposure, A02)을 우선순위로 설정. 범위 제외: 국가 차원의 공격자, 내부자 위협, 서비스 거부 공격(denial-of-service). 안티 골(Anti-goals): mTLS, WAF, 별도의 AWS 계정 또는 전담 인프라 인력을 필요로 하는 사항은 권장하지 말 것.

응답 (의역됨, 전형적인 형태):

• 매개변수화된 쿼리(parameterized queries) 확인 (문제없어 보임)
• bcrypt 비용(cost) $\ge$ 12로 비밀번호 해싱 — 현재 코드는 비용 8을 사용 중이므로 이를 높일 것
• JWT 서명 알고리즘을 명시적으로 검증하고, alg: none은 거부할 것
• JWT 서명 비밀키를 환경 변수(env var)에 넣고, 로테이션 절차를 문서화할 것 (이 단계에서는 수동 방식도 괜찮음)
• 인증 실패를 기존 애플리케이션 로그에 기록하고, "MAU 5,000명 도달 시 검토"를 위한 카운터 추가
  다섯 가지 항목이며, 모두 1인 개발자가 오늘 오후에 할 수 있는 일들입니다.

동일한 모델, 동일한 코드. 이것이 이 글에서 입증하고자 하는 핵심 주장입니다. 여러분의 코드에 직접 시도해 보세요. 답변의 형태가 달라질 것입니다.

6. 재정의 (The Reframe)
   느슨한 버전: "AI는 트레이드오프(trade-offs)를 할 수 없다. 인간이 결정해야 한다."
   더 날카로운 버전: 가역적이고 단계에 민감한 결정에 대해, AI는 기본적으로 프로덕션급(production-grade) 조언을 내놓습니다. 개입 지점은 비즈니스 컨텍스트(business context) — 단계, 규모, 트레이드오프 가중치, 안티 골(anti-goals)을 제공하는 것입니다. 이러한 프레이밍은 다음과 같은 이유로 원래의 방식보다 더 유용합니다:

• 구체적인 행동을 지시합니다.

책임의 소재가 "AI가 한계가 있다"에서 "내가 AI에게 나의 위치를 말해주지 않았다"로 이동합니다. 그것이 전체 이야기인지 여부와 상관없이, 그것은 당신이 다음 프롬프트(prompt)에서 수정할 수 있는 부분입니다. 이는 지속 가능하지만 "영구적으로 진리"인 것은 아닙니다. 향후의 도구들은 리포지토리(repo) 형태로부터 단계를 추론하고, 명확한 질문을 던지며, 제품 텔레메트리(product telemetry)로부터 조직의 컨텍스트(context)를 추출하는 능력이 분명히 향상될 것입니다. 하지만 인간이 목적 함수(objective function)를 기술하는 과정의 일부를 위임하더라도, 그 목적 함수에 대한 책임은 여전히 인간에게 남아 있을 것입니다. 이는 범위를 인정하는 것입니다. 이는 모든 결정이 아니라, 가역적(reversible)이며 단계에 민감한(stage-sensitive) 결정들에 대한 주장입니다.

7. "컨텍스트(Context)"의 실제 의미 — 분류 체계 (Taxonomy)

"AI에게 더 많은 컨텍스트를 제공하세요"라는 말은 모호한 조언입니다. 유용한 컨텍스트는 네 가지 계층을 가집니다:

계층	답변하는 내용	위치
단계 (Stage)	MVP / 성장 / 확장. 가역성 예산 (Reversibility budget).	CLAUDE.md 상단 섹션
제약 사항 (Constraints)	런웨이(Runway), 팀 규모, 인프라 예산, 지연 시간(latency) 목표	CLAUDE.md 또는 프롬프트별
트레이드오프 가중치 (Trade-off weights)	배포 속도 vs 품질 vs 확장성 우선순위	CLAUDE.md
안티 골 (Anti-goals)	건너뛰어야 할 권장 사항의 명시적 목록	CLAUDE.md "하지 마시오(do NOT)" 목록

MVP를 위한 작동 가능한 CLAUDE.md 스니펫(snippet):

프로젝트 컨텍스트 (Project Context)

• 단계 (Stage): MVP — 가설 검증 중. 사용자 50명, 목표 MAU 200명.
• 팀 (Team): 1인 개발자. 운영(ops) 인력 없음.
• 제약 사항 (Constraints): 8개월의 런웨이(runway). 인프라 예산 월 $200 미만.
• 트레이드오프 가중치 (Trade-off weights) (높은 순에서 낮은 순으로): 배포 속도, 코드 명확성, 확장성. p95 지연 시간 1초 미만은 괜찮음.
• 보안 범위 (Security scope): OWASP Top 10 우선순위 지정 — 인젝션(Injection), 인증 결함(Broken Auth), 민감 데이터 노출(Sensitive Data Exposure). 범위 제외: 국가 단위 공격, 내부자 위협, DoS.
• 안티 골 (Anti-goals) — 권장하지 마시오 (do NOT recommend):
  • 마이크로서비스(Microservices), k8s, 서비스 메시(service mesh), mTLS
  • VPC 피어링(Peering) / PrivateLink / 별도의 AWS 계정
  • 200 LOC 미만 파일에 대한 아키텍처 패턴
  • 측정된 부하가 없는 기능에 대한 캐싱(Caching), 큐(queues), 또는 워커(workers)
• 재평가 트리거 (Re-evaluation trigger): MAU 5,000명 도달 시 또는 결제 기능 배포 시 이 가중치들을 재검토할 것.

안티 골(anti-goals) 목록이 이례적인 부분입니다. 대부분의 사람들은 이를 건너뜁니다.

파일 내에서 가장 영향력이 큰(highest-leverage) 한 줄입니다. 모델이 기본값으로 선택했을 법한 일련의 권장 사항들을 제거해 줍니다.

8. AI의 기본값이 실제로 맞을 때
   이 논지는 가역적(reversible)이며 단계에 민감한(stage-sensitive) 결정에 국한됩니다. 그 범위를 벗어나면, AI의 보수적인 편향(conservative bias)은 오히려 자산이 됩니다.

회복 불가능한 하방 리스크(Non-recoverable downside) — 개인정보(PII), 결제 데이터, 건강 데이터, 고객 비밀 정보, 인증 토큰(auth tokens)과 관련된 모든 것. 또한: 테넌트 격리(tenant isolation), 키 관리(key management), 백업/복구(backup/restore), 감사 로그(audit logs), 보유/삭제 준수(retention/deletion compliance), 침해 통지 준비성(breach notification readiness), 비밀 정보 처리(secrets handling), 벤더 및 공급망 리스크(vendor and supply-chain risk). 규제 산업 — 금융, 의료, 정부, 미성년자가 포함된 에듀테크(ed-tech).
이 경우 기본 사전 지식(default prior)은 요구 사항을 과소평가할 수도 있습니다.

수정 비용이 많이 드는 결정(Expensive-to-reverse decisions) — 기본 DB 엔진, 인증 모델(auth model), 멀티 테넌시 경계(multi-tenancy boundaries), 공개 API 규약(public API contracts), 이벤트 스키마(event schemas), ID 전략, 과금 모델(billing model), 권한 모델(permission model), 관측성 기반(observability foundations).
이러한 경우에는 보수적인 권장 사항을 따르십시오. 반드시 서면으로 된 이유가 있을 때만 이를 무시(override)하십시오.
솔직한 요약: 이 글은 특정 결정 사분면에 대한 휴리스틱(heuristic)이지, 보편적인 법칙이 아닙니다.

9. 무엇이 이를 변화시킬 것인가?
   끝에 "적어도 지금은"이라는 말을 덧붙이고 넘어가고 싶은 유혹이 들 것입니다. 하지만 잠시 멈춰 생각할 가치가 있습니다.
   그 격차를 부분적으로 메울 수 있는 요소들:

리포지토리 형태를 통한 단계 추론(Stage inference from repo shape) — 커밋 주기(commit cadence), 테스트 커버리지(test coverage), 관측성 스택(observability stack)을 살펴보고, "1인 창업자의 Express 앱"과 "Series B 마이크로서비스 플릿(microservice fleet)"에 대해 서로 다르게 권장하는 메타 레이어(meta-layer).
조직 인지 에이전트(Org-aware agents) — 제품 지표, 인프라 비용, 로드맵, 리스크 정책에 대한 읽기 권한을 가짐으로써, 모델이 시니어 엔지니어처럼 비용에 대해 추론할 수 있게 함.
정책 프로필(Policy profiles) — "MVP 모드" / "확장 모드(scale mode)" / "준수 모드(compliance mode)"를 일급 객체(first-class) 설정으로 제공.

변하지 않을 것: 인간은 목적 함수(objective function)에 대해 여전히 책임을 집니다.
도구가 당신의 단계를 추론하더라도, 그 추론을 수용할지 여부에 대한 결정권은 여전히 당신에게 있습니다.
따라서 실질적인 주장 — 즉, 맥락을 제공하거나, 그렇지 않을 경우 기본값에 놀라지 말 것 — 은 가장 그럴듯한 개선 사항들이 등장하더라도 유효합니다.

요약

| 구분 | 느슨한 프레이밍 (Loose framing) | 날카로운 프레이밍 (Sharper framing) |
| :--- | :--- | :|
| AI의 특성 | AI는 트레이드오프 (trade-offs)를 수행할 수 없음 | AI는 당신이 제공한 목적 함수 (objective)를 최적화함; 기본 목적 함수는 프로덕션 등급 (production-grade)임 |
| 결정 주체 | 인간이 결정해야 함 | 인간이 단계 (stage), 제약 조건 (constraints), 트레이드오프 가중치 (trade-off weights), 안티 골 (anti-goals)을 명시해야 함 |
| 본질 | "AI의 한계" | "맥락 계층 (context layer)에서의 개입 누락" |

시간 제한적 ("현재로서는") — 모델의 발전과 관계없이 목적 함수에 대한 책임은 인간에게 있습니다.

실행 가능한 하나의 규칙: 다음 "이것을 검토해줘 (review this)" 프롬프트를 입력하기 전에, 단계 (stage), 제약 조건 (constraints), 트레이드오프 가중치 (trade-off weights), 안티 골 (anti-goals)의 네 줄을 프롬프트나 CLAUDE.md에 작성하십시오. 그리고 다시 실행하십시오. 만약 권장 사항이 변하지 않는다면, 당신의 맥락 (context)이 여전히 너무 빈약하거나 다른 실패 모드(모델이 파일을 무시함, 일반적인 안전 편향 (safety bias), 또는 실제 능력의 한계)에 부딪힌 것일 가능성이 높습니다. 그 시점에는 막연하게 "AI가 나쁜 조언을 했다"라고 말하는 대신, 디버깅해야 할 실제적인 문제에 직면하게 된 것입니다.

피드백을 환영합니다. 특히 다음 사항들이 궁금합니다:
(a) 이 전/후 (before/after) 과정이 귀하의 코드베이스에서 깔끔하게 재현됩니까?
(b) "프로덕션 성숙도 우선 (Production-Mature Prior)" 가설이 깨지는 지점은 어디입니까? 구체적인 반례를 원합니다.
(c) 데이터 엔지니어링 (data engineering), MLOps, 보안 스캐너 (security scanners)와 같은 인접 도구에서도 동일한 패턴이 관찰됩니까?