AI 시대, 실무에 적용한 스펙 기반 개발(SDD)의 교훈

URL: https://www.youtube.com/watch?v=T3SWxxQFr4o
날짜: 2026-10-02
채널: Tech Bridge
원문 제목: [한영자막] AI 시대, 스펙 기반 개발(SDD)을 실무에 적용하며 배운 교훈들

---

📌 핵심 질문 / SDD의 핵심 논점

==AI가 코드를 빠르게 생성하는 시대에는 요구사항·도메인·아키텍처를 사람이 이해할 수 있고 AI도 실행할 수 있는 스펙으로 정리해야 하며, 그 스펙을 중심으로 개발·테스트·현대화를 재구성해야 한다.==

• 유스케이스(use case), 엔터티 모델(entity model), 아키텍처, UI/API 설계를 함께 다루는 스펙이 코드 생성의 직접 입력이 된다.
• 스펙 기반 개발(Spec-Driven Development, SDD)은 단순한 프롬프트 기법이나 특정 도구가 아니라 요구사항부터 리뷰까지 아우르는 프로세스다.
• AI 도입으로 구현 속도만 빨라지는 것이 아니라, 업무가 요구사항 엔지니어링(requirements engineering)과 스펙 작성 단계로 이동한다.
• 코드가 실패했을 때의 위험이 큰 영역일수록 사람의 리뷰를 더 많이 배치하고, 업무 경계를 작게 나눈 아키텍처로 AI가 다룰 컨텍스트를 제한해야 한다.

AI-native 개발의 핵심 병목은 코드를 작성하는 속도가 아니라 무엇을 만들어야 하는지, 어떤 도메인 규칙을 지켜야 하는지, 어디까지 자동화해도 안전한지를 명확히 하는 데 있다. 지속 가능한 스펙은 현재 코드를 다른 기술과 UI로 옮기는 중간 표현이 될 뿐 아니라, 개발자가 없어도 비즈니스 담당자가 시스템의 동작을 바꾸는 기반이 될 수 있다.

1. 스포츠 클럽의 자원봉사 시스템에서 시작된 문제

AI로 만든 소프트웨어가 실제 요구사항을 충족하려면 먼저 시스템의 의도와 경계를 명시해야 한다.

1.1. 1997년부터 이어진 육상 경기 운영 자동화

1. 스위스의 작은 마을 스포츠 클럽

   1. 행사 운영: 클럽은 45년 동안 어린이 육상 경기와 트랙·필드 대회를 운영했고, 경기 결과와 순위표를 만들기 위해 많은 자원봉사자가 필요했다.
   2. 소프트웨어의 역할: 1997년부터 대회 운영 소프트웨어를 만들었으며, 예전에는 12~15명이 하던 일을 소프트웨어를 사용해 혼자 처리했다.

2. 자원봉사자 관리의 낡은 시스템

   1. 문제의 시작: 2024년 여름 스위스 공휴일에 클럽 관계자가 자원봉사자 관리 시스템이 낡아서 더 이상 작동하지 않는다고 도움을 요청했다.
   2. AI에 대한 기대: 소프트웨어 엔지니어이고 AI 이야기도 들었으니 더 나은 시스템을 만들 수 있을 것이라는 기대가 출발점이었다.

1.2. 빠른 구현이 요구사항 문제를 드러내다

1. AI로 만든 첫 번째 시스템

   1. 빠른 결과: 2024년 가을 AI 코딩 도구를 사용해 비교적 빠르게 자원봉사자 관리 시스템을 만들었다.
   2. 새로운 고객: 음악 페스티벌 관계자가 같은 시스템이 필요하다고 찾아오면서, 한 조직의 요구만 가정한 구현이 곧바로 재사용 문제에 부딪혔다.

2. 무엇을 만들었는지 설명할 수 없는 상태

   1. 불명확한 의도: 만든 기능이 어떤 요구사항을 구현한 것인지, 왜 그렇게 구현했는지 명확히 알 수 없었다.
   2. 변경의 어려움: 음악 페스티벌의 요구에 맞추려면 어떤 기능을 어떻게 바꿔야 하는지 판단할 기준도 없었다.

3. SDD로 이어진 전환

   1. 문제의 본질: AI가 코드를 생성하지 못한 것이 아니라, 생성된 코드와 실제 업무 요구 사이를 연결하는 명시적 스펙이 없었다.
   2. 탐색의 계기: AI-native development에 관한 자료와 Simon Maple의 글을 접한 뒤, AI 시대의 스펙 기반 개발을 사업용 애플리케이션에 적용하는 방법을 찾기 시작했다.

2. 도구 중심 SDD와 프로세스 중심 SDD

SDD는 특정 제품을 사용하는 방법에 머물지 않고 전체 소프트웨어 개발 수명주기(Software Development Life Cycle, SDLC)를 다시 설계해야 한다.

2.1. Java 중심 엔터프라이즈 개발 경험과 사업용 애플리케이션의 조건

1. 엔터프라이즈 개발 경험

   1. 기술 배경: 주로 Java를 사용해 왔고 스위스에서 17년 동안 컨설턴트로 일했다.
   2. 고객 범위: 보험, 도매·소매, 정부, 대기업을 대상으로 도구나 단일 제품이 아니라 업무용 애플리케이션(business application)을 만들었다.

2. 사업용 시스템의 복잡성

   1. 다양한 역할: 대기업에서는 혼자 일하는 창업자와 달리 요구사항 엔지니어, 제품 책임자, 비즈니스 분석가, 소프트웨어 엔지니어 등 역할이 나뉜다.
   2. 지속되는 시스템: 새 애플리케이션을 만드는 것보다 이미 업무에 사용 중인 시스템을 이해하고 안전하게 현대화(modernization)하는 일이 훨씬 자주 발생한다.

2.2. 생태계의 두 가지 방향

1. 도구 중심(tool-centric) 접근

   1. 대표 도구: Amazon Kiro, GitHub Spec Kit, BDD 방식의 도구, Tessl의 스펙 도구가 소개된다.
   2. 일반적인 흐름: 제품 요구사항 문서(Product Requirements Document, PRD)를 만들고, 계획(plan)을 도출한 다음 작업(task)으로 나누고, AI가 작업을 차례로 구현한다.

2. 프로세스 중심(process-centric) 접근

   1. AI Unified Process: 특정 도구가 아니라 요구사항부터 테스트·리뷰까지를 연결하는 AI Unified Process를 제안한다.
   2. 직접 생성: 계획과 작업 목록을 중간에 두지 않고 유스케이스와 엔터티 모델, 소프트웨어 아키텍처를 코드와 테스트 생성의 직접 입력으로 사용한다.

3. 두 접근의 공통 기반

   1. 스펙의 역할: 스펙은 AI만 이해하는 프롬프트가 아니라 모든 프로젝트 이해관계자와 개발자가 읽고 검토할 수 있는 공통 언어여야 한다.
   2. 자동화의 범위: 스펙이 충분히 구체적이면 코드뿐 아니라 테스트도 생성할 수 있지만, 자동 생성 수준은 시스템의 위험과 아키텍처에 따라 결정한다.

3. AI Unified Process의 핵심 입력

좋은 스펙은 행동, 데이터, 표현, 품질 기준을 서로 연결한다.

3.1. 그린필드 개발의 흐름

1. 비전에서 요구사항으로

   1. 비전 수립: 그린필드 프로젝트는 먼저 시스템이 해결하려는 문제와 비전을 정리한다.
   2. 요구사항 수집: 요구사항 엔지니어링, 제품 관리, 비즈니스 분석 활동을 통해 업무 요구를 수집한다.

2. 요구사항에서 모델로

   1. 유스케이스: 사용자가 수행하는 업무 흐름과 시스템의 행동을 유스케이스로 정리한다.
   2. 엔터티 모델: 도메인 모델(domain model)에 가까운 엔터티 모델을 만들어 데이터와 엔터티 사이의 관계를 명시한다.

3. 모델에서 구현으로

   1. 스펙 완료 기준: 요구사항 엔지니어와 소프트웨어 엔지니어가 Definition of Done을 합의하고 유스케이스 또는 스펙이 구현 가능한 상태인지 검토한다.
   2. 에이전트 실행: 스킬(skills), MCP 서버, 지침(guidelines), 가드레일(guardrails)을 갖춘 에이전트가 스펙을 읽고 코드와 테스트를 만든다.

3.2. 유스케이스가 정의하는 것과 정의하지 않는 것

1. 행동의 정의

   1. 업무 시나리오: 유스케이스는 액터가 시스템과 상호작용하는 행동, 정상 흐름, 대안 흐름을 정의한다.
   2. 수용 기준: 사전조건(precondition)과 사후조건(postcondition)은 시스템이 성공적으로 동작했는지 테스트할 수 있는 수용 기준(acceptance criteria)이 된다.

2. 추가 모델의 필요성

   1. UI 표현: 유스케이스만으로 화면의 배치와 시각적 표현을 정할 수 없으므로 Figma 설계 같은 UI 스펙을 별도로 연결한다.
   2. API 계약: API를 만드는 경우에는 엔드포인트와 입력·출력 계약을 추가해야 하며, MCP 서버를 통해 Figma나 관련 도구와 직접 상호작용할 수 있다.

3. 테스트 생성 순서

   1. API 중심 개발: API라면 테스트 주도 개발(Test-Driven Development, TDD)을 적용해 테스트를 먼저 만들고 테스트가 코드 생성을 이끌도록 한다.
   2. UI 중심 개발: 풀스택 애플리케이션에서는 먼저 UI의 형태를 정해야 테스트를 설계할 수 있으므로 UI 설계와 테스트의 순서를 조정한다.

3.3. 국제 요구사항 엔지니어링과 AI

1. 요구사항 엔지니어링의 변화

   1. 새로운 자격·자료: International Requirements Engineering Board가 AI for Requirements Engineering이라는 마이크로 크리덴셜을 만들고 프롬프트 가이드와 스킬을 제공하기 시작했다.
   2. AI 활용: 요구사항의 중복과 누락을 찾고 유스케이스를 검증하는 일을 AI로 보조할 수 있다.

2. 스펙의 공용성

   1. 이해관계자와 AI의 공통 언어: 유스케이스는 사람에게는 업무 흐름이고 AI에게는 오래 정립된 구조화된 형식이다.
   2. 변경의 추적성: 요구사항이 스펙으로 남으면 코드 변경이 어떤 업무 변화에서 비롯됐는지 추적할 수 있다.

4. 그린필드보다 중요한 소프트웨어 현대화

기존 시스템 현대화는 코드를 그대로 다른 언어로 옮기는 작업이 아니라 도메인과 업무 흐름을 다시 정의하는 작업이다.

4.1. 코드·테스트·문서에서 스펙 추출하기

1. 역공학(reverse engineering)

   1. 자료의 출처: 기존 코드, 테스트, 문서에서 유스케이스와 엔터티 모델을 추출한다.
   2. 분산된 문서: 엔터프라이즈 시스템의 문서는 여러 산출물에 흩어져 있으므로 각 자료의 신뢰도와 맥락을 함께 확인한다.

2. 비즈니스 검토

   1. 업무 담당자의 확인: 추출된 모델은 비즈니스 담당자가 실제 업무와 일치하는지 검토한다.
   2. 새 코드의 기준: 검토된 유스케이스와 엔터티 모델이 새로운 코드와 테스트를 생성하는 기준이 된다.

3. 현대화의 효과

   1. 기술 변환을 넘어선 변화: COBOL에서 Java로 직접 변환하는 식의 리프트 앤 시프트(lift and shift)는 기술만 바꿀 뿐 업무 개선을 보장하지 않는다.
   2. 업무 재설계: 유스케이스와 엔터티 모델을 중간에 두면 기존 업무 방식을 재고하고, 이전 시스템에 없던 기능을 안전하게 추가할 수 있다.

4.2. ‘같은 시스템, 새 기술’에서 기능 개선으로

1. 초기 현대화 목표

   1. 변경 최소화: 2년 전 시작한 현대화 프로젝트의 지침은 새 기술로 옮기되 기존 기능과 동일하게 유지하고 새 기능은 넣지 않는 것이었다.
   2. 버그 회피: 기능을 추가하면 새로운 버그가 생길 수 있다는 우려가 변경을 억제했다.

2. 스펙 기반 전환의 재량

   1. 스펙의 수정: 기능을 코드에 직접 덧붙이는 대신 유스케이스와 엔터티 모델을 수정하면, 의도한 동작을 먼저 명확히 할 수 있다.
   2. 사용자 가치: 기술만 교체하지 않고 실제 사용자의 업무 흐름을 개선하므로 최종 사용자로부터 긍정적인 피드백을 얻을 수 있다.

5. 유스케이스가 사용자 스토리보다 적합한 이유

유스케이스는 한 기능을 여러 단계의 흐름과 예외까지 묶어 표현하므로 사업용 애플리케이션의 행동 스펙에 적합하다.

5.1. 유스케이스의 구조

1. 필수 구성요소

   1. 사전조건: 흐름이 시작되기 전에 만족해야 하는 시스템 상태를 정의한다.
   2. 주 성공 시나리오와 대안 흐름: 정상적으로 목표를 달성하는 단계와 예외·대안 경로를 각각 기록한다.

2. 결과 검증

   1. 사후조건: 흐름이 종료된 뒤 시스템과 데이터가 어떤 상태여야 하는지 정의한다.
   2. 테스트 연결: 사후조건은 사용자 스토리의 수용 기준처럼 자동·수동 테스트로 검증할 수 있다.

5.2. 사용자 스토리와의 관계

1. 범위의 차이

   1. 스토리의 크기: 사용자 스토리는 대개 유스케이스 안의 한 흐름이나 한 단계에 해당한다.
   2. 유스케이스의 묶음: 하나의 유스케이스는 여러 사용자 스토리와 대안 흐름을 포함하는 더 큰 단위다.

2. AI와의 궁합

   1. 정립된 형식: 유스케이스는 수십 년 동안 사용된 형식이므로 AI가 구조와 의도를 해석하기 쉽다.
   2. 업무 전체성: 단편적인 스토리 목록보다 선행조건부터 결과까지의 전체 업무 흐름을 보존해 구현 누락을 줄인다.

6. Spring PetClinic 역공학 데모

작은 데모 애플리케이션도 업무·상태·UI·API를 함께 가진다면 엔터프라이즈 애플리케이션을 다루는 모델링 원칙을 보여줄 수 있다.

6.1. PetClinic의 업무 흐름

1. 기본 기능

   1. 의사 조회: 시스템은 등록된 의사 목록을 보여준다.
   2. 보호자와 반려동물: 보호자를 찾으면 그 보호자에게 연결된 반려동물을 확인할 수 있다.

2. 방문 기록

   1. 구체적인 사례: Eduardo Rodriguez는 Jewel과 Rosie라는 반려동물을 가지고 있다.
   2. 업무 처리: Jewel의 다리가 부러진 상태를 확인하고 새로운 방문(visit)을 추가할 수 있다.

6.2. 유스케이스 다이어그램과 엔터티 모델

1. 액터와 모듈

   1. 액터: 방문자(visitor)와 클리닉 사용자(clinic user)를 시스템의 두 액터로 둔다.
   2. 업무 모듈: 환영 페이지와 의사 조회, 보호자 관리, 반려동물 관리, 방문 관리로 유스케이스를 나눈다.

2. 엔터티 모델

   1. 관계 표현: 엔터티 모델은 시스템에 존재하는 타입과 관계를 다이어그램으로 나타낸다.
   2. 데이터베이스와의 연결: SQL 데이터베이스든 다른 데이터베이스든 기존 데이터 모델에서 엔터티 정보를 도출할 수 있다.

3. 의사 목록 유스케이스

   1. 행동 정의: 액터, 사전조건, 시나리오, 사후조건을 포함하며 역공학 과정에서 API 정보도 함께 기록된다.
   2. 수용 기준: 의사의 이름과 전문 분야 목록을 어떤 형식으로 보여줘야 하는지 사후조건에 적고, 테스트에서 이를 검증한다.

6.3. 프롬프트 대신 스킬을 반복 개선하기

1. 실행 방식

   1. 명시적 구현 호출: 검토된 유스케이스에서 implement를 호출하면 에이전트가 스펙에 맞춰 구현한다.
   2. 반복 가능한 작업: 매번 긴 프롬프트를 작성하지 않고 스킬과 지침을 통해 같은 종류의 구현을 반복한다.

2. 스킬의 계층

   1. 스펙 스킬: 유스케이스와 엔터티 모델을 작성·검증하는 스킬이 있다.
   2. 스택 스킬: 특정 기술 스택에서 코드와 테스트를 만드는 스킬이 있으며, React·Spring Boot, Kotlin·Spring Boot, Angular·Quarkus 같은 조합에 따라 달라진다.

3. 조직 차원의 과제

   1. 스킬 공유: 스킬을 조직 전체에서 공유하고 지속적으로 개선해야 한다.
   2. 분배 문제: 모든 사람이 같은 에이전트를 사용하는 것은 아니므로 스킬을 어떤 방식으로 배포·관리할지 별도 체계가 필요하다.

7. AI에 맞는 아키텍처: 컨텍스트를 업무 경계 안에 두기

AI가 한 번에 이해하고 변경할 수 있는 컨텍스트의 크기와 위치가 아키텍처 선택에 직접 영향을 준다.

7.1. 과도한 마이크로서비스가 만든 분산된 진흙 공

1. 마이크로서비스의 오용

   1. 마이크로에 집중한 분해: 지난 15년 동안 많은 조직이 마이크로서비스의 ‘마이크로’에만 집중해 서비스 수를 지나치게 늘렸다.
   2. 큰 분산 진흙 공: 서비스가 많아졌지만 도메인 경계가 명확해진 것이 아니라 분산된 big ball of mud가 만들어졌다.

2. 보험 회사의 사례

   1. 규모: 한 보험 회사에는 약 500개의 마이크로서비스와 약 500개의 마이크로 프런트엔드가 있다.
   2. N:M 관계: 프런트엔드와 백엔드가 서로 여러 개씩 연결되는 N:M 관계가 되어 특정 기능을 수정할 때 관련 코드를 한곳에 모으기 어렵다.

3. AI 컨텍스트의 문제

   1. 단일 작업의 요구: AI가 특정 영역을 수정하려면 그 영역의 코드와 규칙을 한 장소 또는 한 작업 환경에서 충분히 제공해야 한다.
   2. 조합 비용: 수백 개 컴포넌트에서 필요한 조합을 찾아 섞어야 하면 AI가 사용해야 할 컨텍스트가 지나치게 복잡해진다.

7.2. 거대한 모놀리스와 셀프 컨테인드 시스템

1. 모듈러 모놀리스의 한계

   1. 단순한 반대 이동의 문제: 마이크로서비스에서 거대한 모놀리스로 돌아가는 것만으로는 해결되지 않는다.
   2. 컨텍스트 과대화: 수천 개의 데이터베이스 테이블과 많은 모듈이 한 애플리케이션에 들어간 거대한 모놀리스도 AI가 이해하기에는 컨텍스트가 너무 크다.

2. Self-Contained System(SCS)

   1. 수직 분할: 애플리케이션을 수직적인 업무 단위로 나누고, 각 단위에 UI·비즈니스 로직·데이터베이스를 함께 둔다.
   2. 저장소 경계: 보통 하나의 저장소(repo)나 하나의 프로젝트, 최소한 하나의 애플리케이션 안에서 해당 업무의 전체 컨텍스트를 관리한다.

3. 기술 스택의 독립성

   1. 업무별 선택: 재고 시스템은 Java 웹 프레임워크를 사용하고 주문 관리 시스템은 React를 사용할 수 있는 것처럼, SCS마다 적합한 스택을 선택할 수 있다.
   2. AI 작업 단위: 업무 경계가 독립되면 그 경계에 필요한 스킬과 문서를 함께 제공해 AI가 더 정확하게 코드를 만들 수 있다.

7.3. 단일 스택의 이점과 비용

1. 단일 생태계

   1. 스킬 집중: Java 또는 JavaScript/TypeScript처럼 한 생태계를 유지하면 코드 생성 스킬과 운영 규칙을 한 번만 만들고 개선할 수 있다.
   2. 유지보수 감소: React와 Angular 프런트엔드, Spring Boot와 Quarkus 백엔드처럼 조합이 늘어나면 각 조합에 대한 스킬을 만들고 유지해야 한다.

2. 현실적인 절충

   1. 고객의 다양성: 실제 고객은 서로 다른 프런트엔드·백엔드 조합을 사용하므로 모든 조직에 단일 스택을 강제할 수 없다.
   2. 조직의 역할: 수많은 조합을 외부 발표자가 모두 지원하기보다 각 회사가 자신의 기술 스택에 맞는 스킬을 구축해야 한다.

8. 팀 운영과 개발 리듬의 변화

스펙과 AI가 구현 시간을 줄이면 기존의 팀 크기, 스프린트 길이, 역할 배치도 함께 바뀐다.

8.1. 스프린트에서 지속적 흐름으로

1. 속도에 맞지 않는 2주 주기

   1. 스펙의 시간: 스펙을 만드는 데는 2주가 필요할 수 있다.
   2. 구현의 시간: 스펙이 충분히 완성되면 구현은 2주를 기다릴 일이 아니라 몇 분 안에 끝날 수 있다.

2. Continuous Flow

   1. 스프린트 폐지: 이런 프로젝트에서는 고정된 2주 스프린트보다 업무가 준비되는 대로 흘러가는 continuous flow가 맞다.
   2. 칸반식 추적: 유스케이스를 칸반(Kanban)의 작업 단위처럼 사용해 현재 진행 상태를 추적한다.

8.2. 팀 규모와 협업

1. 작아진 구현 팀

   1. 기존 규모: 한 셀프 컨테인드 시스템을 5~7명의 개발자가 담당하던 방식에서 벗어난다.
   2. 새 규모: 하나의 SCS에는 1~2명의 개발자를 배치하며, 지식 교환을 위해 가능하면 2명을 선호한다.

2. 작은 팀의 이유

   1. AI의 자동화: 반복적인 구현은 에이전트가 수행하므로 사람은 스펙·리뷰·도메인 판단에 집중한다.
   2. 지식과 동기: 한 명만 계속 일하면 지식이 고립되고 작업이 지루해질 수 있으므로 두 명이 함께 작업하며 서로의 이해를 확인한다.

8.3. 풀 리퀘스트에서 지속적 동료 리뷰로

1. 개발 방식

   1. Trunk-based development: 변경을 장기간 브랜치에 쌓기보다 trunk-based development를 사용한다.
   2. 지속적 리뷰: 두 개발자가 함께 작업하고 구현한 부분을 서로 설명하며 ongoing peer review를 수행한다.

2. 리뷰의 목적

   1. 위험에 따른 리뷰: 모든 코드에 동일한 수준의 검토를 적용하지 않고 장애가 초래할 손실에 따라 깊이를 결정한다.
   2. 지식의 전파: 동료에게 시스템의 일부를 설명하는 과정이 곧 생성된 코드의 품질 검증과 팀 내 지식 교환이 된다.

9. 데모가 보여준 가드레일과 구현 속도

스펙만으로 충분하지 않으며, 에이전트가 어떤 프로젝트와 규칙 위에서 일하는지 통제해야 한다.

9.1. 약 1분 30초 만에 완성된 의사 목록

1. 구현 결과

   1. 간단한 유스케이스: 의사 목록 유스케이스를 implement로 실행하자 애플리케이션에 의사 목록 화면이 생성됐다.
   2. 실행 시간: 시연 중 구현에는 약 1분 30초가 걸렸다.

2. 속도가 가능한 이유

   1. 준비된 컨텍스트: 유스케이스·엔터티 모델·아키텍처·스킬·지침이 이미 제공되어 에이전트가 프로젝트를 처음부터 추측하지 않았다.
   2. 반복성: 같은 입력과 가드레일로 다시 수행하면 거의 같은 결과를 얻는 near-deterministic한 흐름을 목표로 한다.

9.2. AI에게 프로젝트 생성을 맡기지 말아야 하는 이유

1. 토큰 낭비

   1. 보일러플레이트 작업: AI에게 프로젝트를 만들게 하면 토큰을 낭비하고, 이미 도구가 안정적으로 제공하는 초기 설정까지 추론하게 만든다.
   2. 잘못된 선택: AI가 생성한 초기 프로젝트는 현재 프레임워크가 권장하는 최신 구조와 다를 수 있다.

2. 전용 도구 사용

   1. Spring 예시: Spring 프로젝트라면 start.spring.io를 사용해 최신 의존성과 Spring 팀이 현재 권장하는 구조를 얻는다.
   2. CLI 활용: 프레임워크나 사내 도구에 CLI가 있다면 CLI로 프로젝트를 만들고, AI는 그 위에서 업무 구현을 담당하게 한다.

9.3. 문서 크기, 아키텍처, 스킬, MCP

1. 작은 시스템 지침

   1. 대형 시스템 프롬프트의 위험: 취리히 ETH의 연구를 근거로 시스템 프롬프트가 커질수록 환각이 늘어날 가능성이 있다고 설명한다.
   2. CLAUDE.md·AGENTS.md 관리: 모든 규칙을 하나의 거대한 파일에 몰아넣기보다 필요한 맥락을 알맞은 위치와 형식으로 분리한다.

2. 아키텍처 문서

   1. arc42: 아키텍처 설명은 arc42 같은 구조화된 형식으로 관리한다.
   2. 규칙의 분리: 애플리케이션 구조와 패키지 규칙, 사용하는 도구를 아키텍처 지침으로 명시한다.

3. 스킬과 MCP 서버

   1. 행동 지식: 코드와 테스트 생성 방식은 스킬로 제공한다.
   2. 대규모 문서 검색: 사내 프레임워크처럼 문서가 큰 경우에는 스킬에 전부 넣지 않고 MCP 서버와 벡터 검색(vector search)으로 필요한 내용을 찾게 한다.

10. 위험 기반 리뷰와 업무별 자동화 수준

자동화 수준은 AI의 능력이 아니라 장애가 발생했을 때 비즈니스가 감당해야 할 손실로 정한다.

10.1. ERP 모듈별 중요도

1. 재고 관리

   1. 낮은 즉시 위험: 재고 관리가 잠시 멈추면 해당 업무 담당자가 커피를 마시며 기다릴 수 있는 정도일 수 있다.
   2. 리뷰 수준: 상대적으로 낮은 위험이면 자동화 비중을 높이고 리뷰를 간소화할 수 있다.

2. 주문 관리

   1. 금전 손실: 주문 관리가 멈추면 회사가 매출을 잃을 수 있다.
   2. 리뷰 수준: 장애 비용이 큰 모듈에는 더 많은 사람의 리뷰와 검증을 배치해야 한다.

3. 일반 원칙

   1. 도메인 독립적 판단: 위험 기반 리뷰는 AI 개발에만 특수한 원칙이 아니라 수동 개발에도 적용되는 소프트웨어 품질 관리 원칙이다.
   2. 리뷰 방법의 선택: 사람이 직접 검토할 수도 있고, AI를 리뷰어로 활용할 수도 있지만 최종 검토 깊이는 위험에 맞춰야 한다.

11. 지속 가능한 스펙과 요구사항으로의 업무 이동

스펙은 현재 구현의 부산물이 아니라, 다음 기술과 다음 인터페이스까지 이어지는 장기 자산이다.

11.1. 다른 기술·UI로 재생성하는 중간 표현

1. 기술 독립성

   1. 기존 코드의 스펙화: 현재 시스템을 유스케이스와 엔터티 모델로 역공학해 스펙으로 보존한다.
   2. 새 기술로 생성: 동일한 스펙에서 다른 프로그래밍 언어와 다른 기술 스택의 애플리케이션을 생성할 수 있다.

2. 인터페이스의 변화

   1. 새 UI: 같은 업무 스펙으로 기존과 다른 UI를 만들 수 있다.
   2. UI 없는 시스템: 웹 UI 대신 채팅 인터페이스 같은 방식으로 직접 업무를 수행하는 시스템도 만들 수 있다.

11.2. 비즈니스 담당자의 직접 변경

1. 개발자 의존성 감소

   1. 행동의 명시화: 시스템이 어떻게 행동해야 하는지가 스펙에 명확히 담기면 비즈니스 담당자가 그 행동을 직접 변경할 수 있다.
   2. 변경의 경로: 담당자는 개발자에게 코드의 의미를 다시 설명하거나 코드 내부를 직접 찾아볼 필요 없이 유스케이스와 도메인 모델을 수정한다.

2. 스펙의 지속성

   1. 코드보다 오래 사는 자산: 기술과 UI가 바뀌어도 업무 규칙과 도메인 모델은 이어질 수 있다.
   2. 자동 재생성: 변경된 마크다운 스펙을 파이프라인에 넣어 관련 코드와 테스트를 자동으로 다시 생성하는 방향이 제시된다.

11.3. 구현 속도보다 요구사항의 품질

1. 일의 이동

   1. 기존 분배: Scrum에서는 요구사항을 정리하는 기간과 개발자가 구현하는 기간이 각각 약 2주로 나뉘었다.
   2. 새 분배: SDD에서는 요구사항과 스펙에 약 2주가 필요할 수 있지만 구현은 5분 정도로 짧아질 수 있어 작업이 요구사항 엔지니어링 쪽으로 이동한다.

2. 스위스 정부 사례

   1. 대상 시스템: 스위스 의회의 비즈니스 케이스 관리 소프트웨어 현대화 프로젝트에서 개념 증명(PoC)을 진행했다.
   2. 역할의 역전: 코드 PoC를 혼자 담당했고 두 명의 제품 책임자·요구사항 엔지니어가 스펙을 담당했으며, 오히려 스펙 담당자에게 더 많은 일이 몰렸다.

3. 가장 중요한 역량

   1. 아키텍처 이해: AI에게 코드를 시키기 전에 시스템을 어떤 경계로 나눌지 알아야 한다.
   2. 도메인 이해: 업무의 실제 규칙과 위험을 모르면 좋은 유스케이스나 엔터티 모델을 만들 수 없다.

12. 질의응답: 모델 생성과 변경의 실제 흐름

12.1. 요구사항에서 유스케이스로 내려가는 순서

1. 다이어그램 생성

   1. 출발 문서: 그린필드 프로젝트에서는 요구사항 카탈로그나 PRD에서 유스케이스 다이어그램을 먼저 도출한다.
   2. 모듈 경계: 다이어그램을 만들면 애플리케이션을 어떤 모델 또는 모듈로 나눌지에 대한 단서가 생긴다.

2. 상세 유스케이스 생성

   1. 단계 확장: 유스케이스 다이어그램의 각 항목에서 사용자 스토리보다 상세한 단계와 대안 흐름을 가진 텍스트 유스케이스를 만든다.
   2. AI 검증: 요구사항 엔지니어와 제품 책임자는 AI를 이용해 유스케이스의 중복·누락을 확인하고 내용을 다듬는다.

3. 폭포수 오해

   1. 큰 선행 설계가 아님: 스펙을 쓴다고 해서 전체 시스템을 한 번에 완성하는 waterfall 방식이 아니다.
   2. 한 건씩 진행: 유스케이스 하나를 정리하고 테스트와 구현을 연결하는 방식으로 점진적으로 진행한다. Agile 개발에서도 요구사항·테스트·구현은 모두 필요하다.

12.2. 잘못된 유스케이스를 수정하는 방법

1. 구체적인 수정

   1. 표현 변경: 의사 목록 유스케이스가 전문 분야를 쉼표로 구분한다고 되어 있다면, 요구사항 담당자는 실제로는 다른 구분 방식이 필요하다고 유스케이스를 수정할 수 있다.
   2. 재실행: 수정된 유스케이스에서 다시 implement를 호출해 변경을 적용한다.

2. 기존 코드의 보존

   1. 처음부터 버리지 않음: 애플리케이션 전체를 삭제하고 다시 만드는 것보다 기존 코드를 읽고 필요한 부분을 변경한다.
   2. Git 이력: 기존 코드를 보존하면 변경이 Git history에 남고 리뷰하기 쉬워진다.

3. 소스 코드의 미래

   1. 새로운 가능성: AI가 사람이 읽는 소스 코드 대신 실행 가능한 바이트코드를 직접 만들 수도 있다는 관점이 제시된다.
   2. 현재의 실무: 현재는 사람이 수동으로 구현할 때처럼 유스케이스와 엔터티 모델을 수정한 뒤 기존 코드에 변경을 적용한다.

주요 발언 모음

“스펙은 개발 속도를 높이지만, 스펙만으로는 충분하지 않다. 제대로 작동하게 하려면 그 주변의 모든 컨텍스트를 함께 갖춰야 한다.”

“AI에게 프로젝트를 만들게 하지 말라. 토큰만 낭비하고, 최신 방식과 다른 오래된 애플리케이션을 얻게 될 수 있다.”

“유스케이스 하나는 보통 여러 사용자 스토리의 묶음이며, 사용자 스토리는 유스케이스 안의 한 흐름인 경우가 많다.”

“스펙 기반 개발이 폭포수라는 말은 사실이 아니다. 큰 선행 설계를 하는 것이 아니라 유스케이스 하나씩 요구사항과 테스트와 구현을 연결한다.”

“가장 중요한 것은 자신의 아키텍처와 도메인을 아는 것이다.”

핵심 데이터 & 수치

• 45년: 스위스 스포츠 클럽이 어린이 육상 경기와 트랙·필드 대회를 운영해 온 기간이다.
• 1997년: 발표자가 클럽 경기 운영 소프트웨어를 만들기 시작한 시점이다.
• 12~15명: 소프트웨어 도입 전 경기 결과와 순위표 업무에 필요했던 인원 규모다.
• 17년: 발표자가 스위스에서 Java 중심의 엔터프라이즈 컨설턴트로 일해 온 기간이다.
• 약 8년: 엔터프라이즈 애플리케이션 현대화를 수행해 온 기간이다.
• 약 500개: 한 보험 회사에 존재하는 마이크로서비스의 규모다.
• 약 500개: 같은 보험 회사에 존재하는 마이크로 프런트엔드의 규모다.
• 5~7명에서 1~2명: 셀프 컨테인드 시스템 하나를 담당하는 개발 팀의 목표 규모 변화다.
• 약 1분 30초: PetClinic의 의사 목록 유스케이스를 구현하는 데모에 걸린 시간이다.
• 2주에서 약 5분: 기존 개발에서 구현에 걸리던 주기와 SDD에서 스펙이 준비된 뒤 구현에 걸릴 수 있는 시간의 대비다.
• 2명: 스위스 의회 비즈니스 케이스 관리 시스템 PoC에서 스펙을 담당한 제품 책임자·요구사항 엔지니어의 수다.

결론 및 시사점

1. 코드보다 스펙을 먼저 자산화한다: 유스케이스, 엔터티 모델, 아키텍처를 사람이 검토 가능한 형태로 남기면 구현·테스트·현대화의 공통 기반이 된다.
2. 사용자 스토리를 업무 전체 흐름으로 확장한다: 단일 스토리의 나열보다 사전조건, 정상·대안 흐름, 사후조건을 갖춘 유스케이스가 AI와 비즈니스 담당자 모두에게 더 강한 계약이 된다.
3. 그린필드와 브라운필드를 같은 언어로 연결한다: 기존 코드·테스트·문서를 유스케이스와 엔터티 모델로 역공학하면 기술 교체가 업무 재설계로 이어진다.
4. AI의 컨텍스트를 아키텍처로 통제한다: 수백 개의 서비스가 서로 얽힌 구조도, 수천 개 테이블을 품은 거대한 모놀리스도 AI 작업 단위로는 너무 크다. UI·비즈니스 로직·데이터를 한 업무 수직선에 묶는 SCS가 실용적이다.
5. 도구보다 조직에 맞는 프로세스가 먼저다: Amazon Kiro나 GitHub Spec Kit 같은 도구는 유용하지만, 엔터프라이즈의 역할 분담·리스크·현대화 흐름까지 자동으로 해결하지는 않는다.
6. AI에게 초기 프로젝트를 맡기지 않는다: 프레임워크 CLI와 공식 생성기를 사용해 최신 기반을 만들고, AI 에이전트는 준비된 기반 위에서 업무 기능을 구현하게 한다.
7. 큰 규칙 파일 하나로 모든 것을 설명하지 않는다: 시스템 프롬프트와 지침을 작게 유지하고, 아키텍처 문서·스킬·MCP 검색을 각자 적합한 위치에 배치한다.
8. 리뷰는 위험에 비례시킨다: 재고 조회와 주문 처리처럼 장애 손실이 다른 모듈에 동일한 자동화·검증 수준을 적용하지 않는다.
9. 팀은 작아지고 요구사항 역할은 커진다: 구현이 분 단위로 단축되면 개발자 수와 스프린트 주기를 줄이는 대신 요구사항 엔지니어링과 도메인 모델링에 더 많은 투자를 해야 한다.
10. 아키텍처와 도메인이 최종 병목이다: AI가 코드를 잘 생성하도록 만드는 가장 중요한 전제는 프롬프트의 화려함이 아니라 시스템을 어떻게 나눌지, 업무가 실제로 어떻게 돌아가는지 아는 능력이다.

핵심 요약 (20줄)

1. AI 시대의 스펙 기반 개발은 코드 생성 프롬프트가 아니라 요구사항부터 리뷰까지 연결하는 전체 개발 프로세스다.
2. 빠르게 만든 자원봉사자 관리 시스템은 무엇을 구현했는지 설명할 스펙이 없어 다른 조직의 요구사항에 재사용하기 어려웠다.
3. 사업용 애플리케이션은 제품 요구사항, 유스케이스, 엔터티 모델, 아키텍처, UI·API 계약을 함께 다뤄야 한다.
4. 유스케이스는 액터, 사전조건, 정상 시나리오, 대안 흐름, 사후조건을 갖춰 AI와 이해관계자의 공통 언어가 된다.
5. 사용자 스토리는 대개 유스케이스 안의 한 흐름이므로 복잡한 업무 전체를 표현하기에는 유스케이스가 더 적합하다.
6. 유스케이스의 사후조건은 사용자 스토리의 수용 기준처럼 자동 테스트로 검증할 수 있다.
7. API 개발은 테스트를 먼저 만들 수 있지만 풀스택 UI 개발은 화면의 형태를 정한 뒤 테스트를 설계해야 한다.
8. 그린필드에서는 요구사항에서 유스케이스와 엔터티 모델을 만들고 준비된 스킬과 가드레일로 코드를 생성한다.
9. 브라운필드 현대화에서는 기존 코드, 테스트, 분산된 문서에서 스펙을 역공학한 뒤 비즈니스 담당자가 검토한다.
10. COBOL을 Java로 직접 옮기는 리프트 앤 시프트는 기술만 바꾸므로 업무 현대화와 다르다.
11. 스펙을 중간 표현으로 두면 기존 업무를 재고하고 새로운 기능과 다른 기술·UI를 안전하게 도입할 수 있다.
12. 수백 개의 마이크로서비스와 마이크로 프런트엔드가 얽히면 AI가 필요한 컨텍스트를 모으기 어려워진다.
13. 거대한 모놀리스도 컨텍스트가 지나치게 크므로 마이크로서비스와 단일 모놀리스 사이의 다른 경계가 필요하다.
14. 셀프 컨테인드 시스템은 UI, 비즈니스 로직, 데이터베이스를 업무별 수직 단위로 묶어 AI 작업 범위를 줄인다.
15. 단일 기술 스택은 코드 생성 스킬을 단순화하지만 고객마다 다른 조합을 지원하려면 조직별 스킬 관리가 필요하다.
16. 스펙 작성에는 시간이 걸려도 준비된 유스케이스의 구현은 약 1분 30초 또는 몇 분 안에 끝날 수 있다.
17. 구현팀은 셀프 컨테인드 시스템당 5~7명에서 1~2명으로 줄고 스프린트 대신 지속적 흐름을 사용할 수 있다.
18. AI에게 프로젝트를 생성시키지 말고 Spring Initializr 같은 공식 생성기와 CLI로 최신 기반을 준비해야 한다.
19. 거대한 시스템 프롬프트 대신 아키텍처 문서, 작은 스킬, MCP 기반 문서 검색을 조합해 환각과 컨텍스트 낭비를 줄인다.
20. 개발 속도가 빨라질수록 최종 경쟁력은 코딩이 아니라 아키텍처와 도메인을 이해하고 올바른 스펙을 만드는 능력에 달려 있다.