서론

프로덕트 오너(Product Owner)가 LLM을 사용하여 "이것이 이상적이다"라고 말하는 앱을 만들어낸다——2026년 현재, 이것은 더 이상 드문 광경이 아닙니다. 프로토타입(Prototype)은 놀라울 정도로 빠르게 구축됩니다.

문제는 그다음입니다. "작동하는 것이 만들어졌다. 이것을 AWS 운영 환경(Production)에 올려서 앞으로도 계속 개수해 나가고 싶다. 하지만 수정할 때마다 다른 부분이 망가지는 것은 곤란하다". 본 기사는 바로 이 단계, "작동하는 프로토타입"을 "망가지지 않는 운영 시스템"으로 바꾸기 위한 개발 방식을 2026년의 트렌드와 1차 자료(Primary Source)를 바탕으로 정리합니다.

결론부터 말씀드리면, 핵심은 세 가지입니다.

코드보다 먼저 "사양(Spec)"을 확정할 것
AWS의 매니지드(Managed) 경로에 태울 것
CI 상의 자동 가드레일(Guardrail)로 회귀(Regression)를 차단할 것

왜 이 세 가지일까요? 우선 "작동하는 앱을 그대로 키우면 어떤 일이 발생하는가"를 데이터로 살펴보겠습니다.

1. "만들었다"와 "망가지지 않는다"는 별개——4가지 데이터가 같은 방향을 가리키고 있다

LLM 생성 코드의 품질에 대해서는 2025년 후반~2026년에 걸쳐 독립적인 여러 조사 결과가 나왔습니다. 방법론도 조사 주체도 제각각이지만, 결론의 방향이 일치하고 있다는 점이 중요한 포인트입니다.

보안: 모델이 진화해도 개선되지 않고 있다

Veracode의 "Spring 2026 GenAI Code Security Update"에 따르면, AI 코딩 어시스턴트가 생성한 코드의 보안 합격률은 약 55%로, 최근 2년간 거의 정체 상태였습니다[1]. 뒤집어 말하면, 약 45%의 케이스에서 기 알려진 취약점(Vulnerability)이 혼입되고 있습니다.

주목해야 할 점은 "OpenAI·Google·Anthropic의 2년간의 모델 진화에도 불구하고, 수치는 55%에서 55%로밖에 움직이지 않았다"는 지적입니다. SQL 인젝션(SQL Injection, 합격률 82%)과 같은 전형적인 취약점에는 능숙해진 반면, 깊은 코드 분석을 요하는 복잡한 타입에서는 합격률이 떨어집니다. 최신 모델로 교체하면 안전해질 것이라는 기대는 배신당하고 있는 셈입니다.

결함 밀도: AI 코드의 PR은 문제가 많다 (단, 유보 조항 있음)

코드 리뷰 도구인 CodeRabbit이 2025년 12월에 공개한 "State of AI vs Human Code Generation" 리포트에서는, OSS의 GitHub PR 470개(AI 공동 작성 320개·인간 전용 150개)를 분석하여 다음과 같은 결과를 보고했습니다[2].

카테고리별로는 로직·정확성이 +75%, 가독성이 3배 초과, 보안 취약성이 최대 2.74배, 성능(과도한 I/O 등)에 이르러서는 약 8배라는 수치가 나열됩니다.

다만, 이 수치를 인용할 때는 전제 조건을 반드시 세트로 붙여야 합니다. CodeRabbit 스스로도 리포트 내에서 중요한 한계를 인정하고 있습니다. "대규모 OSS 데이터셋에서 각 PR의 저자를 직접 확인하는 것은 불가능했기 때문에, AI 공동 작성 "시그널(Signal)"이 있는 것을 AI, 없는 것을 인간이라고 가정했다", "인간이 작성했다고 라벨링한 것에 실제로는 인간만 작성하지 않은 것이 섞여 있을 가능성을 부정할 수 없다". 즉, 저자 판정은 추정치이며, 나아가 AI 리뷰를 판매하는 기업에 의한 측정입니다. "AI 코드는 1.7배 버그가 많다"라고 단정하는 것이 아니라, "CodeRabbit의 470개 PR 분석에서는 1.7배 많았다 (저자 판정은 추정)"라는 온도감이 정확합니다.

유지보수성: "붙여넣기"가 늘고 "리팩터링(Refactoring)"이 사라진다

GitClear는 2020년 1월~2024년 12월 사이의 2.11억 행의 변경 사항을 분석하여 코드의 "붙여넣기 방식" 변화를 추적하고 있습니다[3].

• 복사 붙여넣기(Clone) 코드:
  8.3% → 12.3% (2021→2024)
• 리팩터링(Moved) 행:
  25% → 10% 미만

리포트는 "처음으로 개발자가 리팩터링보다 복사 붙여넣기를 더 많이 사용하게 되었다"라고 표현하고 있습니다. 수년 단위의 개발 속도를 유지하려면 DRY(Don't Repeat Yourself) 원칙에 따른 모듈러(Modular) 설계가 필요함에도, AI 지원 개발은 그 반대의 경향을 낳고 있다는 지적입니다. 당장은 빠르지만, 붙여넣기의 축적이 바디 블로우(Body blow)처럼 서서히 타격을 주는 구조입니다.

생산성의 패러독스: 숙련자일수록 "빨라진 것 같지만 느려진다"

마지막으로, 가장 시사하는 바가 큰 데이터입니다. METR(Model Evaluation & Threat Research)의 무작위 대조 시험(RCT)에서는, 16명의 숙련된 OSS 개발자·246개 태스크를 대상으로 AI 도구 사용 여부를 무작위로 할당하여 완료 시간을 측정했습니다[4].

결과는 AI 허용 시 완료 시간이 **19% 증가(즉, 느려짐)**했습니다. 게다가 개발자들은 사전에 24%의 단축을 예측했으며, 태스크를 마친 후에도 「20% 빨라졌다」고 자기 평가를 했습니다. 체감과 실측의 차이는 약 39포인트입니다.

느려진 요인으로는 프롬프트(Prompt) 작성, AI 출력물 검토 및 대기, 그리고 **AI 생성 코드의 수정(Hand-off/Refactoring)**에 시간이 소요된 점이 꼽혔습니다.

이 장의 함의

4가지 데이터는 조사 주체와 방법론이 모두 다릅니다. 그렇기에 「보안이 취약하다」, 「결함이 많다」, 「유지보수성이 떨어진다」, 「체감만큼 빠르지 않다」는 결과가 독립적으로 동일한 방향을 가리키고 있다는 점에 의미가 있습니다.

여기서 도출되는 행동은 단순합니다. 「작동한다」를 너무 신뢰하지 않기 위한 메커니즘을, 프로덕션(Production) 환경 구축과 동시에 포함시키는 것입니다. 다음 장부터 그 구체적인 방안을 살펴보겠습니다.

2. 첫걸음은 코드가 아닌 「사양」 —— Spec 중심 개발

「망가지지 않는 구조」라고 하면 테스트나 CI(지속적 통합)를 떠올리지만, 사실 그 전 단계에 더 효과적인 것이 있습니다. 바로 사양(Spec)을 명문화하는 것입니다.

LLM으로 만든 앱의 최대 약점은, 「무엇을 만들고 싶었는지」가 자연어 프롬프트 이력과 코드 속에 녹아버려, 정답(Ground Truth)이 어디에도 남지 않는다는 점입니다. 정답이 없다면, 수정 작업이 「고친 줄 알았는데 망가뜨린 것」인지 판정할 수 없습니다.

AWS Kiro가 보여주는 「요구사항 → 설계 → 태스크」

이 과제에 대한 AWS의 해답이 에이전틱 IDE(Agentic IDE)인 Kiro입니다. Kiro는 「Bring engineering rigor to agentic development(에이전트 개발에 엔지니어링의 엄격함을 가져오다)」를 내걸고, 프롬프트에서 바로 코드를 쓰는 대신, 3단계 사양을 먼저 확정합니다[5].

요구사항(Requirements): 자연어 요구사항을 수용 기준(Acceptance Criteria)이 포함된 명확한 요구사항으로 변환한다. 여기서 **EARS(Easy Approach to Requirements Syntax)**라는 표기법을 사용하여, WHEN, IF-THEN, WHILE 같은 패턴으로 「테스트 가능한 요구사항」을 작성한다 -
설계(Design): 코드베이스를 분석하여 아키텍처 및 기술 스택을 제안한다 -
태스크(Tasks): 요구사항에 연결된 구현 태스크로 분해하고, 테스트를 포함하여 순서를 정한다

핵심은 **이 사양이 그대로 리포지토리(Repository)에 남아, 수정 시의 단일 진실 공급원(Single Source of Truth)**이 된다는 점입니다. 다음 개수 작업도 「사양 → 차분(Diff)」 방식으로 진행되므로, 무엇을 망가뜨려서는 안 되는지가 항상 명시됩니다.

AWS의 답은 「더 많은 AI」가 아니라 「형식 기법(Formal Methods)」이었다

2026년 5월, Kiro에 Requirements Analysis라는 기능이 추가되었습니다. 이것이 상징적입니다. AI의 실수를 다른 AI가 고치게 하는 것이 아니라, **50년 이상의 역사를 가진 자동 추론(Formal Verification)**을 도입한 것입니다.

Requirements Analysis는 LLM과 자동 추론 엔진을 결합한 뉴로-심볼릭(Neuro-symbolic) 3단계 파이프라인으로 동작합니다[6].

정교화(Elaboration): 모호한 요구사항을 성공 상태로부터 역산하여 테스트 가능한 수용 기준으로 다시 작성한다 -
자동 형식화(Automated Formalization): 자연어를 SMT-lib 형식의 논리식으로 번역한다. 여러 형식화 샘플을 추출하여 「의미적 편차(Semantic Entropy)」를 측정하고 모호함을 감지한다 -
논리 분석(Logical Analysis): **SMT 솔버(SMT Solver)**와 자동 추론 엔진이 모순, 누락, 정의되지 않은 동작을 찾아낸다

요컨대, 코드를 한 줄도 쓰기 전에 요구사항의 논리적 모순을 수학적으로 검출하는 것입니다. 여러 매체는 「AWS가 요구사항의 상당 부분에서 버그를 발견했다」고 보도하고 있지만, 공식 블로그가 명시적으로 인용하고 있는 수치는 다른 연구(Larbi et al., 2025)에 근거하며, 「요구사항이 모호하거나 불완전해지면, 구문적으로는 올바른 생성 코드의 60~90%가 의미론적으로 오류가 된다」는 것입니다. 사양의 품질이 생성 코드의 품질을 지배한다는 실증입니다.

Kiro를 사용하지 않더라도

도구는 Kiro가 아니어도 상관없습니다. 본질은 "수정하기 전에, 바꿔도 되는 것과 바꿔서는 안 되는 것을 사양(Specification)으로 적어두는 것"입니다. docs/spec/에 EARS 방식의 요구사항을 두고, PR(Pull Request)마다 사양과의 차이를 의식하는 것만으로도, LLM 생성 앱의 "정답이 없다"는 문제는 크게 완화됩니다.

3. AWS에 올리기——앱의 정체에 따라 경로가 달라진다

사양이 확정되면 프로덕션 환경으로 전환해야 합니다. "LLM으로 만든 이상적인 앱"이라고 해도 그 내용은 다양하므로, 우선 앱의 정체에 따라 경로를 나눕니다.

패턴 A: LLM은 하나의 기능 (풀스택 Web App)

업무용 앱이나 SaaS에서 생성형 AI가 하나의 기능인 경우로, 가장 흔한 케이스입니다.

LLM을 호출하는 부분만 Bedrock으로 모으고, 나머지는 일반적인 서버리스(Serverless) 구성으로 만드는 것이 견실합니다. 인프라는 후술할 내용과 같이 반드시 IaC (SAM/CDK)로 정의합니다.

패턴 B: 앱 자체가 AI 에이전트 / 채팅

앱의 본체가 에이전트나 RAG 채팅인 경우, AWS는 전용 솔루션을 제공하고 있습니다. 바로 **Generative AI Application Builder on AWS (GAAB)**입니다[7].

• 버전 4.1.14, 2026년 5월 출시 - MCP (Model Context Protocol) 서버, 에이전트, 멀티 에이전트의 오케스트레이션(Orchestration)을 통합
• 기반은 Amazon Bedrock AgentCore Runtime + Lambda + API Gateway + Cognito + DynamoDB + CloudWatch
• AWS Well-Architected 설계 원칙을 준수하며, CloudFormation 템플릿을 통해 (공식적으로) 약 10분 만에 배포 가능
• 오픈 소스이며, Strands나 LangChain의 오케스트레이션 레이어를 포함

"에이전트의 토대를 직접 구축하는 것은 힘들다"라고 느낀다면, GAAB나 그 기반인 Bedrock AgentCore를 직접 사용하는 것이 2026년의 정석입니다.

어떤 경로든 공통되는 "무너지지 않는 토대"

경로가 다르더라도, 프로덕션 환경 구축 시 공통적으로 포함해야 할 토대가 있습니다.

• IaC (CDK / SAM): 환경을 재현 가능하게 만든다. 수동 콘솔 조작을 남기지 않는다.
• Secrets Manager: API 키를 코드나 env에 직접 작성하지 않는다 (전 장의 Veracode가 보여준 취약점의 전형이 바로 이것이다).
• CloudWatch: 메트릭(Metrics), 로그(Logs), 대시보드(Dashboard)를 통해 관측 가능하게 만든다.

그리고 여기까지가 "올리는" 이야기입니다. 다음은 본론인 "무너지지 않게 하는" 이야기입니다.

4. 무너지지 않는 메커니즘——테스트가 에이전트 시대의 유일한 방벽

수정 시에도 무너지지 않는 시스템의 핵심은, **"망가졌음을 기계가 자동으로 감지하여 멈추는 것"**에 달려 있습니다. 인간의 리뷰만으로는 AI가 코드를 작성하는 속도를 따라잡을 수 없습니다.

Golden / characterization 테스트로 "현재의 올바른 동작"을 고정한다

LLM 생성 앱은 사양서가 사후에 작성되기 쉽고, 내부 구현도 인간이 완전히 파악하지 못하는 경우가 많습니다. 이런 코드에 유효한 것이 characterization 테스트 (특성화 테스트), 다른 이름으로 Golden Master입니다.

생각은 간단합니다. "지금 실제로 작동하고 있는 입출력 쌍을 '정답'으로 고정하고, 이후의 변경이 거기서 벗어나면 실패로 처리한다"는 것입니다. 사양이 모호하더라도 "적어도 현재의 동작은 바꾸지 않는다"라는 방벽을 즉시 세울 수 있습니다.

# tests/test_golden.py (이미지)
import json
from app import generate_summary
...

LLM 응답처럼 출력이 완전히 일치하지 않는 부분은 스키마 검증(JSON 구조가 깨지지 않았는지)이나 주요 필드의 존재 확인 등, 결정적으로 판정할 수 있는 축을 기준으로 골든 세트(Golden Set)를 만드는 것이 요령입니다.

커버리지 래칫(Coverage Ratchet)으로 "퇴보"를 물리적으로 금지한다

**커버리지 래칫 (coverage ratchet)**은 테스트 커버리지(test coverage)를 '일방통행 래칫(ratchet, 역전 방지 장치)'으로 만드는 메커니즘입니다. 현재의 커버리지율을 하한선으로 CI에 기록하고, 그 수치보다 낮은 PR(Pull Request)은 머지(merge)할 수 없도록 합니다. AI가 대량의 코드를 추가하더라도 테스트가 동반되지 않아 커버리지가 낮아지면 자동으로 차단됩니다.

CI 게이트: 리포트를 가드레일로 바꾸기

테스트나 커버리지는 단순히 실행만 해서는 '리포트' 수준에 머뭅니다. 임계값(threshold) 미달 시 불합격 처리를 하여 머지를 중단하는 단계까지 연결해야 비로소 '가드레일 (guardrail)'이 됩니다. GitHub Actions를 이용한 최소한의 예시를 보여드립니다.

# .github/workflows/guardrail.yml
name: guardrail
on:
...

이 게이트를 통과한 PR만이 별도의 워크플로우를 통해 SAM / CDK를 이용한 운영 환경 배포 (production deployment) 단계로 진행하도록 구성합니다. 즉, "테스트를 통과한 것만 운영 환경에 나간다"는 것을 기계적으로 보장하는 것입니다.

# 배포 측 워크플로우의 핵심 (main 머지 시에만 실행)
sam build && sam deploy --no-confirm-changeset --no-fail-on-empty-changeset
# 또는 CDK의 경우
...

CI에 전용 게이트를 추가하면 피드백 루프(feedback loop)가 몇 분 정도 길어지지만, 이는 "망가진 것을 운영 환경에 배포한 뒤에야 깨닫는" 비용에 비하면 비교할 수 없을 정도로 저렴한 투자입니다.

관측성: 장애 발생 시 즉시 파악할 수 있도록

마지막으로, 배포 후에도 장애를 감지할 수 있도록 합니다. CloudWatch 알람(에러율, 레이턴시(latency), Bedrock 호출 실패 등)과 생성형 AI 특유의 평가(출력 품질에 대한 오프라인 평가 = eval)를 조합합니다. 에이전트(agent) 계열이라면 GAAB가 표준으로 CloudWatch 메트릭(metrics)을 수집해주므로, 이를 토대로 대시보드를 구성하는 것이 좋습니다.

5. 요약 —— 속도보다 앞서야 할 사양, 테스트, IaC

LLM으로 이상적인 앱을 만드는 단계까지는 이제 누구나 빠르게 도달할 수 있습니다. 차이가 발생하는 지점은 그것을 망가지지 않는 운영 시스템으로 바꾸는 공정입니다.

본 기사의 요점을 세 가지로 압축하면 다음과 같습니다.

• 코드보다 먼저 사양 (spec)을 확정할 것: 무엇을 변경해서는 안 되는지를 명문화합니다. AWS Kiro의 요구사항 $\rightarrow$ 설계 $\rightarrow$ 태스크, 즉 요구사항 분석 (Requirements Analysis)과 같은 형식 방법론(formal method)의 흐름이 2026년의 트렌드입니다.
• AWS의 매니지드 경로를 활용할 것: 풀스택이라면 Amplify + SAM/CDK + Bedrock, 에이전트라면 GAAB / Bedrock AgentCore를 사용합니다. 인프라는 반드시 IaC (Infrastructure as Code)로 구축합니다.
• CI 상의 자동 가드레일로 회귀(regression)를 차단할 것: 특성 테스트 (characterization/Golden test) + 커버리지 래칫 (coverage ratchet) + CI 게이트 + 관측성 (observability).

Veracode, CodeRabbit, GitClear, METR의 데이터가 공통적으로 가리키는 점은 "AI는 가속 장치이지만, 브레이크를 별도로 달지 않으면 사고가 난다"는 것입니다. 이상적인 앱을 오랫동안 키워나가고 싶다면, 먼저 사양과 테스트라는 브레이크부터 구축하십시오.

• Spring 2026 GenAI Code Security Update: Despite Claims, AI Models Are Still Failing Security - Veracode. 검증 대상은 SQLi(CWE-89), XSS(CWE-80), Log Injection(CWE-117), 취약한 암호(CWE-327). 보안 특화 프롬프트를 주지 않은 "순수한 상태"의 동작을 측정. $\u2112$

• State of AI vs Human Code Generation Report - CodeRabbit (2025년 12월 17일 공개). $\u2112$

• AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones - GitClear $\u2112$

• Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity - METR (arXiv:2507.09089). 사용 도구는 주로 Cursor Pro + Claude 3.5/3.7 Sonnet. $\u2112$

Kiro. AWS가 제공하는 에이전틱 (agentic) 개발 플랫폼 (IDE / CLI / Web). 로그인을 위해 AWS Builder ID 또는 IAM Identity Center를 사용할 수 있지만, 이용을 위해 AWS 계정이 반드시 필요한 것은 아닙니다. ↩︎

Requirements Analysis: catching requirement bugs before they become code - Kiro Blog ↩︎

Discussion