AI와 함께하는 명세기반 개발 (Spec-Driven Development)
"바이브코딩 사전단계 — SA 문서를 AI와 함께 설계한다"
3주짜리 커머스 백엔드 프로젝트를 시작하기 전,
AI를 '시니어 아키텍트 동료'처럼 활용해 10종의 SA 문서를 설계하는 법을 배웁니다.
Pre-work
1. 준비물 체크리스트
- Claude / ChatGPT / Gemini 중 최소 1개 이상 로그인 가능한 상태 (Pro이상 유료 계정 권장)
- Figma 무료 계정 (화면 설계서 목업용)
- Mermaid 렌더링이 가능한 마크다운 에디터 (VS Code + Mermaid Preview 확장 추천)
- PlantUML 렌더링 도구 (VS Code 확장 또는 plantuml.com)
- 팀별 공용 저장소 (GitHub Repository 또는 Notion 워크스페이스)
2. 사전 숙지 자료
- 2차 프로젝트 회고 (특히 "설계가 약해서 구현 중에 다시 뒤집은 경험")
- Spring Boot + JPA + MySQL + Redis 기본 개념
- AWS EC2 / RDS / ElastiCache 이름만이라도 들어본 수준
3. 💡 "왜 이 특강이 프로젝트 1일차 오전에 배치되는가"
3주 프로젝트의 첫 3일은 설계 기간입니다. 이 3일을 어떻게 쓰느냐가 남은 18일의 품질을 좌우합니다.
이전 기수들이 가장 자주 했던 후회는 "설계 없이 코딩부터 시작했더니 2주차에 기능을 다 뒤엎었다" 였습니다.
오늘 오전 특강에서 'AI와 설계하는 감각'을 먼저 잡고, 오후부터 팀별로 본격적인 SA 문서 작성에 들어갑니다.
오프닝: "왜 또 설계 얘기? 우리 지금껏 설계 많이 했잖아요"
2차 프로젝트 회고 공감대 형성
"여러분, 손 들어보세요. 2차 프로젝트에서 구현하다가 기능을 뒤엎은 경험 있는 사람?"
대부분의 손이 올라올 겁니다. 왜 그랬을까요? 대부분 이유는 하나입니다 — 설계가 없었거나, 있어도 부실했기 때문입니다.
바이브코딩의 함정
지금까지 여러분은 AI에게 "로그인 기능 만들어줘" 같은 식으로 코드를 부탁했습니다. 이걸 바이브코딩(Vibe Coding) 이라고 부릅니다. 느낌적으로, 상황 봐가며, 수정해가며 완성하는 방식이죠.
바이브코딩은 작은 기능 하나를 만들 때는 기가 막히게 빠릅니다. 그런데 3주짜리, 그것도 동시성 제어·분산락·인프라 자동화까지 들어가는 프로젝트를 바이브코딩만으로 끌고 가면 반드시 다음이 터집니다.
- 1주차: "AI 최고! 다 되네!"
- 2주차: "어? 재고가 음수가 돼요… 왜죠?"
- 3주차: "아키텍처가 꼬였는데 어디부터 손대야 할지 모르겠어요"
오늘 배울 것: "AI를 비서가 아닌 시니어 아키텍트 동료처럼"
"AI에게 '뭘 만들지'를 명확히 말해줄 수 없다면, AI는 여러분이 원하는 걸 만들 수 없습니다."
오늘 특강의 목표는 단 하나입니다.
AI와 대화하면서 10종의 SA 문서를 만들고, 그 문서를 근거로 3주를 완주하는 법.
실무 연결 — "쿠팡·배민 시니어 개발자들도 이렇게 일합니다"
쿠팡에서 로켓배송 재고관리 시스템을 만들 때, 시니어 개발자가 가장 먼저 하는 일은 코딩이 아니라 PRD(Product Requirements Document)와 SA 문서 작성입니다. 왜냐면 재고가 음수가 되는 순간 실제로 돈이 사라지거든요.
여러분이 만들 커머스 앱도 마찬가지입니다. 오늘 배울 건 실무에서 매일 쓰는 스킬입니다.
오늘의 흐름
- SA 문서 10종 지도 그리기 + AI에게 프로젝트 컨텍스트 주입하는 법
- 사용자 시나리오 → 유스케이스 → ERD → API 명세서 순서로 AI와 함께 설계
- 화면 설계서를 통해 프론트엔드 바이브코딩 가이드 만들기
- 인프라 아키텍처 & 동시성 제어 설계서(하이라이트)
- ADR 기록 + 셀프 리뷰
- 평생 쓸 5가지 프롬프트 패턴 정리
Step 1: "SA 문서 지도 그리기 & AI 컨텍스트 주입"
1-1. 오늘 만들 SA 문서 10종
먼저 뭘 만들지부터 알아야 합니다. 이번 프로젝트에서 3일간 작성할 문서 목록입니다.
| # | 문서 | 답하는 질문 | 산출 형태 |
|---|---|---|---|
| 1 | 프로젝트 개요서 | 우리 왜 이걸 만드나? | 마크다운 |
| 2 | 사용자 시나리오 (페르소나 포함) | 누가, 어떤 맥락에서 쓰나? | 마크다운 |
| 3 | 유스케이스 명세서 | 누가 뭘 할 수 있나? | 마크다운 + PlantUML |
| 4 | 기능 명세서 | 각 기능은 어떻게 동작하나? | 마크다운 |
| 5 | ERD | 데이터는 어떻게 연결되나? | Mermaid ERD |
| 6 | API 명세서 | 프론트랑 어떻게 대화하나? | 마크다운 표 + OpenAPI YAML |
| 7 | 화면 설계서 | 사용자는 어떤 화면을 보나? | 와이어프레임 + Figma 목업 |
| 8 | 인프라 아키텍처 다이어그램 | 어디에 어떻게 배포되나? | Mermaid 다이어그램 |
| 9 | 동시성 제어 설계서 ⭐ | 충돌은 어떻게 막나? | 시나리오 매트릭스 |
| 10 | ADR (Architecture Decision Record) | 왜 이 기술을 골랐나? | 마크다운 (결정마다 1개) |
💡 9번 동시성 제어 설계서가 별도 문서인 이유
이번 프로젝트의 하이라이트입니다. 비관락/낙관락/분산락을 언제 뭘 쓸지를 결정하는 이 의사결정이 기능 명세서에 섞이면 묻혀버립니다. 별도 문서로 빼서 집중 관리합니다.
1-2. AI를 설계 파트너로 만드는 3단계
AI를 '잘 쓰는' 사람과 '못 쓰는' 사람의 차이는 딱 하나입니다 — 컨텍스트를 얼마나 잘 주입하느냐.
좋은 프롬프트의 3요소를 기억하세요.
- 역할 부여 (Role): "너는 10년차 백엔드 아키텍트야"
- 제약 명시 (Constraints): 기술스택, 인원, 기간, 필수/도전 기능
- 출력 포맷 지정 (Output Format): 마크다운 표, Mermaid, PlantUML, JSON
비유하자면, 신입 개발자한테 일을 시킬 때 "알아서 잘해봐"라고 하면 절대 원하는 결과가 안 나오잖아요? AI도 똑같습니다. 오히려 AI는 신입보다 더 자세한 가이드를 줘야 원하는 답을 줍니다.
1-3. 🎁 실습 프롬프트 — 프로젝트 컨텍스트 초기화
지금 바로 여러분이 쓰는 AI에 이 프롬프트를 복붙해서 대화를 시작해보세요. 이게 오늘 모든 실습의 출발점입니다.
너는 10년 이상의 경력을 가진 백엔드 시니어 아키텍트야.
지금부터 나와 함께 3주짜리 커머스 백엔드 앱의 SA 문서를 설계할 거야.
## 프로젝트 컨텍스트
- 팀 구성: 백엔드 개발자 N명 (경력 3개월)
- 기간: 3주 (설계 3일 + 개발 2주 + QA/배포 1주)
- 주제: 편의점 유통기한 임박 음식 덤핑 플랫폼
- 기술 스택: Java 17, Spring Boot 3.x, Spring Data JPA, MySQL 8, Redis,
Docker, AWS(EC2, RDS, ElastiCache, ECR), GitHub Actions
- 프론트엔드: 바이브코딩으로 처리 (화면 설계서 + Figma 목업만 준비)
## 필수 구현 기능
1. 동시성 제어 - 순간적으로 요청이 쏟아지더라도 데이터 정합성이 완벽하게 지켜져야하는 비즈니스
2. 로컬 캐싱 (Caffeine) - 인기 검색어 & 검색 기능
## 도전 기능
1. Redis 분산락 (Redisson)
2. Redis 캐싱 (Cache-Aside 패턴)
3. EXPLAIN 기반 DB 인덱스 최적화
4. 웹소켓(STOMP) 기반 채팅
5. EC2 + RDS + ElastiCache + ECR + GitHub Actions 배포 자동화
## 너의 역할
- 질문을 먼저 하고, 내가 답한 뒤에 설계를 제안할 것
- 모든 의사결정에는 "왜"를 근거로 설명할 것
- 추측하지 말고, 모르는 건 나에게 물어볼 것
- 대안이 있을 땐 Trade-off를 비교표로 보여줄 것
## 함께 작성할 문서
| # | 문서 | 답하는 질문 | 산출 형태 |
| --- | --- | --- | --- |
| 1 | 프로젝트 개요서 | 우리 왜 이걸 만드나? | 마크다운 |
| 2 | 사용자 시나리오 (페르소나 포함) | 누가, 어떤 맥락에서 쓰나? | 마크다운 |
| 3 | 유스케이스 명세서 | 누가 뭘 할 수 있나? | 마크다운 + PlantUML |
| 4 | 기능 명세서 | 각 기능은 어떻게 동작하나? | 마크다운 |
| 5 | ERD | 데이터는 어떻게 연결되나? | Mermaid ERD |
| 6 | API 명세서 | 프론트랑 어떻게 대화하나? | 마크다운 표 + OpenAPI YAML |
| 7 | **화면 설계서** | 사용자는 어떤 화면을 보나? | 와이어프레임 + **Figma 목업** |
| 8 | 인프라 아키텍처 다이어그램 | 어디에 어떻게 배포되나? | Mermaid 다이어그램 |
| 9 | **동시성 제어 설계서 ⭐** | 충돌은 어떻게 막나? | 시나리오 매트릭스 |
| 10 | ADR (Architecture Decision Record) | 왜 이 기술을 골랐나? | 마크다운 (결정마다 1개) |
준비됐으면 "준비됐습니다. 먼저 3가지만 질문드릴게요"라고 답하고
가장 중요한 3가지 질문만 먼저 해줘.🔑 이 프롬프트의 핵심 장치
마지막 문장 "가장 중요한 3가지 질문만 먼저 해줘" 가 매직입니다. 이 한 줄이 없으면 AI는 멋대로 가정하고 답변을 던집니다. 이 한 줄이 있으면 AI는 모르는 걸 먼저 물어보는 행동 패턴으로 바뀝니다. 시니어 개발자가 신입에게 일을 받을 때처럼요.
1-4. 실습 체크포인트
- AI가 "준비됐습니다. 먼저 3가지만 질문드릴게요"로 답변했는가?
- AI가 던진 3가지 질문이 구체적이고 날카로운가?
- 내가 그 질문에 답변을 던졌을 때, AI가 다음 단계로 부드럽게 넘어가는가?
Step 2: "사용자 시나리오 & 유스케이스 설계"
2-1. 페르소나 → 시나리오 → 유스케이스 흐름
개발자들이 가장 자주 빠지는 함정이 있습니다. "기능 목록 = 유스케이스" 로 착각하는 것. 유스케이스는 "액터의 목표" 입니다. "회원가입 기능"은 기능이고, "새로운 사용자가 회원가입을 통해 쇼핑을 시작하려 한다"가 유스케이스입니다.
비유하자면, 레스토랑 메뉴판에 "파스타"라고만 쓰여있는 거랑, "야근으로 지친 직장인이 혼자 와서 30분 안에 든든히 먹고 갈 수 있는 크림 파스타"라고 쓰여있는 거랑 느낌이 다르잖아요? 후자가 유스케이스입니다.
2-2. 🎁 실습 프롬프트 1 — 페르소나 설계
우리 커머스 앱의 주요 페르소나 3명을 설계해줘.
각 페르소나마다 다음 항목을 포함해줘:
- 이름, 나이, 직업
- Goal (앱에서 이루고 싶은 것)
- Pain Point (기존 커머스 앱에서 겪는 불편함)
- 주요 사용 시나리오 3가지
제약조건: 우리 필수/도전 기능과 연결될 수 있는 페르소나여야 해.
예를 들어 '한정판 스니커즈 드랍을 기다리는 사용자'는 동시성 제어와
자연스럽게 연결되잖아.💡 왜 "기능과 연결되는 페르소나"를 요구하는가?
페르소나를 위한 페르소나는 문서를 위한 문서가 됩니다. 페르소나가 동시성 제어, 분산락 같은 우리 핵심 기술과 이어져야 "왜 이 기능이 필요한가" 를 설명할 수 있습니다.
2-3. 🎁 실습 프롬프트 2 — 유스케이스 명세서 & 다이어그램
위 페르소나를 기반으로 유스케이스 명세서를 만들어줘.
출력 형식은 다음과 같이 해줘:
## UC-001: [유스케이스 이름]
- **액터**:
- **사전조건**:
- **주요 흐름**:
1.
2.
- **대체 흐름**:
- **예외 흐름**:
- **사후조건**:
- **관련 필수/도전 기능**:
그리고 마지막에 PlantUML 형식의 유스케이스 다이어그램 코드도 같이 줘.Step 3: "ERD 대화형 설계 + 레드팀 검증"
3-1. "한 방 프롬프트"가 위험한 이유
여러분이 가장 자주 하는 실수: AI한테 "커머스 앱 ERD 그려줘" 한 방에 물어보는 것.
이렇게 하면 AI는 평균적인 커머스 앱의 ERD를 던져줍니다. 우리 프로젝트의 필수 기능(동시성 제어)과 도전 기능(분산락, 캐싱)이 반영되지 않은, 교과서 같은 ERD가 나옵니다.
그래서 우리는 대화형 설계(Conversational Design) 를 합니다. 4단계로 쪼개서, 단계마다 내가 OK 해야 다음으로 넘어가게 만듭니다.
3-2. 🎁 실습 프롬프트 1 — 단계별 ERD 도출
우리 커머스 백엔드의 ERD를 설계하자.
다만 바로 답하지 말고, 다음 순서로 진행해줘:
1단계: 먼저 필요한 엔티티 목록만 뽑아줘 (설명 포함)
2단계: 내가 "좋아"라고 하면 엔티티 간 관계를 1:N, N:M으로 정의해줘
3단계: 각 엔티티의 속성을 정의하되, 동시성 제어가 필요한 필드
(예: 재고 수량)에는 반드시 @Version 또는
Pessimistic Lock 필요 여부를 주석으로 표시해줘
4단계: Mermaid ERD 코드로 최종 출력해줘
시작하자. 1단계부터.🔑 "1단계부터. 내가 OK 해야 다음 단계로"의 힘
이 패턴을 단계별 설계 패턴(Step-by-step Design Pattern) 이라고 부릅니다. AI가 중간 단계에서 멋대로 가정하지 않고, 사람이 각 단계를 검토할 수 있게 만드는 장치입니다. 앞으로 AI랑 협업할 때 가장 자주 쓸 패턴이에요.
3-3. 🎁 실습 프롬프트 2 — 레드팀 검증
AI가 만든 ERD를 그냥 쓰면 위험합니다. 왜냐면 AI는 자기가 만든 걸 자기가 칭찬하는 경향이 있거든요. 그래서 페르소나를 바꿔서 다시 물어보는 기법을 씁니다.
방금 만든 ERD를 이제 '비판적인 코드리뷰어' 입장에서 검토해줘.
특히 다음 관점에서 약점을 찾아줘:
1. 정규화 이슈 (중복, 종속성)
2. 동시성 이슈 가능성 (어떤 테이블이 Hot Spot이 될까?)
3. 인덱스 최적화 관점 (자주 조회될 것 같은 컬럼)
4. 확장성 이슈 (MSA로 쪼갤 때 경계는 어디?)
5. 누락된 엔티티 (실제 커머스에서 필요할 법한데 빠진 것)
각 이슈마다 '왜 문제인지'와 '어떻게 개선할지'를 같이 줘.🔑 레드팀 패턴(Red Team Pattern)
AI가 만든 걸 AI에게 다시 비판시키는 이 기법, 실제로 해보면 놀랄 정도로 날카로운 비판이 나옵니다.
3-4. 실무 연결
쿠팡 상품팀에서 ERD를 설계할 때, 실제로 두 명의 시니어가 하나는 '설계자', 하나는 '비판자' 역할을 나눠서 서로 역할극을 합니다. 우리는 AI가 양쪽 역할을 다 해주는 거죠.
Step 4: "API 명세서 & OpenAPI 변환"
4-1. API 명세서가 단순 표가 아닌 이유
초보 개발자들은 API 명세서를 엔드포인트 목록으로만 생각합니다. 실무에선 API 명세서가 프론트-백 사이의 계약서(Contract) 입니다. 이 문서가 바뀌면 양쪽 모두가 고통받습니다. 그래서 처음에 잘 만들어야 합니다.
4-2. 🎁 실습 프롬프트 1 — RESTful API 설계
ERD와 유스케이스를 기반으로 REST API 명세서를 만들어줘.
출력은 다음 형식의 마크다운 표로:
| Method | Endpoint | 설명 | Request | Response | 인증 | 관련 UC |
|---|---|---|---|---|---|---|
제약사항:
- REST 원칙(자원 중심, 동사 X) 준수
- 페이징은 cursor 기반 우선 검토
- 재고 차감 같은 동시성 민감 API는 ⚠️ 표시
- 캐싱 대상 API는 💾 표시
- 인증 필요 API는 🔐 표시
그리고 각 API마다 예시 JSON Request/Response를 추가로 줘.💡 이모지 표시가 왜 중요한가?
⚠️(동시성), 💾(캐싱), 🔐(인증) 표시는 나중에 구현 단계에서 "이 API는 어떤 특별한 처리가 필요한가" 를 한눈에 보여줍니다. 동시성 민감 API 목록이 곧 Step 7의 동시성 설계서의 입력이 됩니다.
4-3. 🎁 실습 프롬프트 2 — OpenAPI YAML 자동 변환
위 API 명세서를 OpenAPI 3.0 YAML 형식으로 변환해줘.
나중에 Swagger UI에 바로 붙일 수 있도록.💡 왜 두 번 만드는가?
마크다운 표는 사람이 읽기 위한 거고, OpenAPI YAML은 도구가 읽기 위한 겁니다. 두 형식을 다 만들어두면 팀 회의에선 마크다운 표를 보고, 실제 Swagger UI에선 YAML을 쓸 수 있습니다. AI가 두 형식 간 변환을 대신 해주니까 드는 비용은 없습니다.
Step 5: "화면 설계서 + Figma 목업 연동"
5-1. 백엔드 개발자가 화면 설계서를 만드는 이유
"저 백엔드 개발자인데 화면을 왜 설계해요?" — 좋은 질문입니다. 그런데 사실 이 질문 자체가 흔한 오해에서 나옵니다.
좋은 백엔드 개발자는 화면을 이해하는 사람입니다.
화면을 모르면 좋은 API를 설계할 수 없기 때문이에요.
예를 들어볼게요. 상품 상세 페이지 하나만 생각해봅시다. 이 화면엔 상품 정보, 판매자 정보, 리뷰 요약, 재고 상태, 관련 상품, 장바구니 담기 버튼이 모두 있습니다. 백엔드 개발자가 이 화면을 모른 채로 API를 설계하면 어떻게 될까요?
/products/{id}하나만 덩그러니 만들어놓고, 판매자 정보는/sellers/{id}로 따로 빼고, 리뷰는/products/{id}/reviews로 또 따로 빼고… 결과적으로 화면 하나 띄우려고 API를 5번 호출하게 됩니다 (N+1 문제의 프론트엔드 버전!)- 반대로 화면을 이해하는 백엔드 개발자는 이렇게 생각합니다. "이 화면이 한 번에 필요한 데이터는 뭐지?" → 그래서
/products/{id}/detail응답에 상품+판매자+리뷰요약+재고를 한 번에 묶어서 내려줍니다. 네트워크 왕복이 1번으로 줄어듭니다.
화면 설계서가 백엔드에게 주는 3가지 선물:
- 응답 DTO 설계의 근거가 생긴다 — "이 화면에 뭐가 보이나"가 곧 "이 API 응답에 뭐가 들어가야 하나"입니다. 오버페칭/언더페칭을 피할 수 있습니다.
- API 호출 순서와 조합이 보인다 — 로그인→상품조회→장바구니 담기→결제 같은 흐름이 화면 이동과 1:1로 매칭됩니다. 빠진 API, 겹친 API가 드러납니다.
- 엣지 케이스가 눈에 보인다 — "재고 0개일 때 이 버튼은 어떻게 되나?", "로그인 안 된 상태에서 장바구니 누르면?" 같은 질문이 화면을 보면 저절로 튀어나옵니다. 이게 전부 API 예외 처리 스펙이 됩니다.
이번 프로젝트는 프론트엔드를 바이브코딩으로 처리합니다.
즉, 여러분이 직접 AI에게 "로그인 페이지 만들어줘"라고 해야 합니다.
이렇게 한 방으로 던지면 AI는 "알아서 예쁘게" 만듭니다. 그 결과물이 여러분의 API와 일치할 리가 없죠. 그래서 화면 설계서가 이중으로 중요합니다. 화면 설계서가 있으면:
- AI에게 "이 화면은 이런 API를 호출하고, 이런 데이터를 이런 레이아웃으로 보여줘" 라고 명확히 지시할 수 있습니다
- 나중에 API를 수정해도 화면 설계서를 기준으로 영향도를 파악할 수 있습니다
- Figma 목업과 연동하면 시각적 레퍼런스까지 AI에게 제공할 수 있습니다
💡 실무 한 줄 요약
"API 설계를 잘하는 백엔드 개발자는 예외 없이 화면을 잘 이해합니다. 화면을 모르면 API는 '데이터 덤프'가 되고, 화면을 알면 API는 '사용자 경험의 일부'가 됩니다."
5-2. 🎁 실습 프롬프트 1 — 화면 목록 도출
우리 유스케이스 기준으로, 필요한 화면 목록을 모두 뽑아줘.
출력 형식:
| 화면 ID | 화면 이름 | 관련 UC | 주요 기능 | 호출 API |
|---|---|---|---|---|
그리고 각 화면마다 '이 화면에 반드시 있어야 할 요소'를
불렛 리스트로 정리해줘. (예: 헤더, 검색바, 상품 카드 그리드, 페이징)5-3. 🎁 실습 프롬프트 2 — ASCII 와이어프레임
위 화면 중 주요 5개에 대해 ASCII 아트 기반 와이어프레임을 그려줘.
각 영역마다 어떤 데이터가 들어가고, 어떤 인터랙션이 가능한지도 주석으로 달아줘.
백엔드 개발자가 API 설계 검증용으로 쓸 거니까 예쁠 필요는 없어.
첫번째 화면부터 시작하자.💡 왜 ASCII 와이어프레임?
Figma는 나중에 만들 겁니다. 그 전에 텍스트 기반 와이어프레임을 먼저 만드는 이유는 (1) AI가 빠르게 생성할 수 있고, (2) 마크다운 문서에 그대로 박아넣을 수 있고, (3) API와 1:1 매핑을 검증하기 쉽기 때문입니다. "이 화면에 장바구니 아이콘이 있는데 장바구니 API가 없네?" 같은 걸 바로 잡아낼 수 있습니다.
5-4. 🎁 실습 프롬프트 3 — Figma 목업용 프롬프트 생성
ASCII 와이어프레임이 완성되면, 이제 Figma에서 실제 목업을 만들 차례입니다. Figma AI 또는 별도 디자인 AI에게 던질 프롬프트를 AI에게 만들게 합니다. 메타 프롬프팅이죠.
방금 만든 와이어프레임을 Figma에서 목업으로 만들 건데,
Figma AI에게 전달할 프롬프트를 만들어줘.
프롬프트에는:
- 화면 목적
- 필수 컴포넌트 리스트
- 컬러 톤 & 무드
- 레이아웃 가이드 (데스크탑/모바일)
- 참고할 만한 기존 앱 (예: 컬리, 29CM)
가 포함되어야 해.5-5. 최종 산출물: "화면 설계서 → 프론트 바이브코딩 프롬프트"
이 모든 걸 다 만들면, 나중에 프론트엔드 바이브코딩 단계에서 다음처럼 쓸 수 있습니다.
[AI에게 프론트엔드 코드 요청 시]
아래 화면 설계서를 참고해서 React 컴포넌트를 만들어줘.
- 화면 ID: S-003 (상품 상세)
- 관련 API: GET /api/products/{id}, POST /api/cart
- 와이어프레임: (ASCII 붙여넣기)
- Figma 링크: https://figma.com/...
- 디자인 톤: 29CM 스타일, 미니멀🔑 포인트: 화면 설계서가 있으면 프론트 AI 프롬프트가 "알아서 해줘" 에서 "이 설계서대로 해줘" 로 바뀝니다. 결과물 퀄리티 차이가 10배입니다.
Step 6: "인프라 아키텍처 다이어그램"
6-1. 도전 기능 "배포 자동화"의 출발점
도전 기능 중에 EC2 + RDS + ElastiCache + ECR + GitHub Actions 배포 자동화가 있습니다. 이걸 구현하려면 먼저 "인프라가 어떻게 생겼는지" 를 그려야 합니다. 없으면 GitHub Actions 워크플로우를 작성할 때 매번 "이거 어디로 보내야 하지?" 에서 헤맵니다.
6-2. 🎁 실습 프롬프트 — AWS 인프라 설계
다음 조건으로 AWS 인프라 아키텍처를 설계해줘:
- EC2 (Spring Boot 앱 서버)
- RDS (MySQL)
- ElastiCache (Redis)
- ECR (Docker 이미지 저장소)
- GitHub Actions (CI/CD)
출력:
1. Mermaid 다이어그램 코드
2. 각 컴포넌트가 왜 필요한지 한 줄 설명
3. 보안 그룹/VPC 구성 제안
4. 예상 월 비용 (프리티어 vs. 실서비스)
5. 배포 파이프라인 흐름 (GitHub push → ECR → EC2까지)6-3. 💰 비용 예측을 프롬프트에 넣는 이유
부트캠프에서 가장 많이 나오는 사고가 "AWS 요금 폭탄" 입니다. 처음 특강에서 AI한테 "예상 월 비용을 프리티어 vs 실서비스 기준으로 알려줘" 를 요청하는 습관을 들이세요. 이 한 줄이 여러분 지갑을 지켜줍니다.
6-4. 실무 연결
실제 스타트업에서 주니어 백엔드 개발자가 "서버 아키텍처 그려줘" 라는 요청을 받으면 당황합니다. 오늘 이 프롬프트 하나만 기억해둬도 실무에서 바로 씁니다.
Step 7: "동시성 제어 설계서 — 오늘의 하이라이트 ⭐"
7-1. 이번 프로젝트의 진짜 핵심
필수 기능: 비관락, 낙관락, 로컬 캐싱
도전 기능: Redis 분산락, Redis 캐싱
이 기능들을 "구현"하는 건 사실 쉽습니다. 진짜 어려운 건 "언제 뭘 쓸지" 결정하는 겁니다. 이번 프로젝트가 여러분에게 요구하는 가장 높은 수준의 역량이 바로 이 의사결정입니다.
7-2. 🎁 실습 프롬프트 1 — 동시성 시나리오 도출
우리 커머스 앱에서 동시성 제어가 필요한 시나리오를 모두 뽑아줘.
각 시나리오마다 다음 정보를 포함해줘:
- 시나리오 이름
- 충돌이 발생하는 조건
- 충돌 시 비즈니스 임팩트 (예: 재고 음수, 중복 결제)
- 예상 트래픽 패턴 (예: 평소 낮음, 이벤트 시 폭발)
반드시 포함할 시나리오:
- 한정 수량 상품 재고 차감
- 동일 유저의 중복 주문/결제 방지
- 선착순 쿠폰 발급
- 포인트 적립/사용
- 상품 리뷰 좋아요 카운트7-3. 🎁 실습 프롬프트 2 — 동시성 전략 매트릭스
위 시나리오 각각에 대해 다음 3가지 전략 중 뭐가 적합한지
Trade-off와 함께 추천해줘:
A. 비관적 락 (SELECT ... FOR UPDATE)
B. 낙관적 락 (@Version)
C. Redis 분산락 (Redisson)
출력 형식:
| 시나리오 | 추천 전략 | 이유 | 장점 | 단점 | 대안 | 재시도 정책 |
그리고 각 전략을 썼을 때 예상되는 '실패 케이스'도 하나씩 알려줘.
(예: 낙관락 썼을 때 OptimisticLockException 재시도 지옥 같은 것)7-4. 락 전략 선택 가이드
| 상황 | 권장 전략 | 이유 |
|---|---|---|
| 충돌 빈도 높음 + 단일 DB 트랜잭션 | 비관락 | 먼저 잡아두고 나머지는 대기 |
| 충돌 빈도 낮음 + 읽기 많음 | 낙관락 | 락 오버헤드 없음, 충돌 시 재시도 |
| 여러 서버 인스턴스 + 공유 자원 | Redis 분산락 | DB 락으로는 서버 간 동기화 불가 |
| 단일 인스턴스 + 메모리 캐시 | 로컬 캐싱 | 네트워크 왕복 제거 |
7-5. 🎁 실습 프롬프트 3 — 성능 실험 계획
위에서 정한 동시성 전략이 실제로 잘 동작하는지 증명할 실험 계획을 만들어줘.
- 실험 도구: JMeter / K6 / Locust 중 추천
- 테스트 시나리오: 동시 요청 N건 → 기대 결과
- 성공 기준 (SLA): 예) 동시 1000건 재고 차감 시 음수 발생 0건
- 측정 지표: TPS, p95 응답시간, 실패율7-6. 실무 연결 — "쿠팡 로켓배송, 배민 쿠폰 이벤트"
쿠팡 로켓배송 재고관리에서 재고가 음수가 되는 순간 실제로 돈이 사라집니다. 배민의 선착순 쿠폰 이벤트에서 중복 지급이 발생하면 고객 CS가 폭주합니다. 여러분이 오늘 만드는 이 문서가 바로 그런 사고를 막는 설계도입니다.
7-7. ⚠️ 주의
- 오해 1: "분산락이 제일 좋은 거 아니에요?"
- 대답: "분산락은 가장 비싸고 느립니다. 단일 인스턴스라면 비관락이 더 빠르고 안전합니다."
- 오해 2: "낙관락 쓰면 재시도만 하면 되잖아요?"
- 대답: "재시도 지옥이 존재합니다. 충돌 빈도가 높으면 오히려 비관락보다 느려집니다."
Step 8: "ADR 작성법 & 셀프 리뷰 체크리스트"
8-1. ADR이란?
ADR (Architecture Decision Record) 은 "왜 이 기술을 골랐는지" 를 기록하는 문서입니다. 나중에 팀원이 "이거 왜 이렇게 했어요?" 라고 물어봤을 때 답할 수 있는 유일한 증거입니다. 1주일만 지나도 여러분 본인조차 왜 이렇게 결정했는지 기억 못 합니다. ADR이 없으면 똑같은 논의를 또 하게 됩니다.
8-2. 🎁 ADR 템플릿 프롬프트
우리가 방금 결정한 "재고 차감에 Redis 분산락을 사용한다"라는 결정을 ADR 형식으로 문서화해줘. ## ADR-XXX: [결정 제목] - **상태**: Proposed / Accepted / Deprecated - **컨텍스트**: 왜 이 결정이 필요했는가? - **고려한 대안**: A / B / C - **결정**: - **근거**: - **결과(긍정)**: - **결과(부정/리스크)**: - **재검토 조건**: 언제 이 결정을 다시 봐야 하는가?💡 "재검토 조건"이 가장 중요한 이유
6개월 뒤 여러분 프로젝트의 트래픽이 10배 늘어났을 때, 지금 결정한 분산락 전략이 여전히 유효할까요? "트래픽이 N배 되면 재검토한다"를 미리 적어두면 나중에 언제 이 결정을 다시 봐야 할지 명확해집니다.8-3. 🎁 최종 셀프 리뷰 프롬프트
3일간 작성한 문서를 팀원들과 리뷰할 때 쓸 체크리스트입니다.
내가 작성한 SA 문서 전체를 다음 체크리스트로 검증해줘. 누락된 게 있으면 구체적으로 어떤 문서에 어떤 내용이 빠져있는지 알려줘. ## 체크리스트 - [ ] 유스케이스 ↔ API 엔드포인트 매핑이 1:1 이상 되는가? - [ ] ERD의 모든 테이블이 최소 하나 이상의 API에서 사용되는가? - [ ] 필수 기능(비관락/낙관락/로컬캐싱)이 설계에 반영됐는가? - [ ] 도전 기능이 "왜 필요한지" ADR로 설명됐는가? - [ ] 동시성 충돌 시나리오가 최소 5개 이상 명시됐는가? - [ ] 실패/예외 흐름이 API 명세서에 포함됐는가? - [ ] 인프라 다이어그램의 모든 컴포넌트가 실제로 쓰이는가? - [ ] 화면 설계서의 모든 화면이 API와 연결되는가?마무리: 5가지 프롬프트 패턴 복습 & Day 안내
오늘 배운 "평생 쓸 5가지 프롬프트 패턴"
오늘 특강은 SA 문서 만들기지만, 진짜로 배워야 할 건 프롬프트 패턴 입니다. 이 5가지는 SA 문서뿐 아니라 앞으로 모든 AI 협업에서 평생 쓸 수 있습니다.
[패턴 1] 컨텍스트 주입 패턴 → Role + Constraints + Output Format → Step 1의 초기화 프롬프트가 대표 사례 [패턴 2] 단계별 설계 패턴 → "1단계부터. 내가 OK 해야 다음 단계로" → Step 3의 ERD 설계가 대표 사례 [패턴 3] 레드팀 검증 패턴 → "이제 비판적 리뷰어로 다시 봐줘" → Step 3의 ERD 검증이 대표 사례 [패턴 4] Trade-off 매트릭스 패턴 → "대안 N개와 장단점 비교표" → Step 7의 동시성 전략 매트릭스가 대표 사례 [패턴 5] ADR 기록 패턴 → "이 결정을 ADR 형식으로 남겨줘" → Step 8의 ADR 템플릿이 대표 사례핵심 정리 — "AI는 답을 주지 않는다, 질문을 더 잘 하게 해준다"
AI한테 문서 만들어달라고 했지만, 사실 AI가 던진 질문이 여러분을 더 성장시켰을 겁니다. AI한테 좋은 답변을 받으려면 좋은 질문을 해야 하고, 좋은 질문을 하려면 문제를 깊이 이해해야 합니다. 결국 AI와 협업하는 건 자기 자신의 사고를 정리하는 과정입니다.
3일간의 SA 문서 작성 로드맵
| 일차 | 시간대 | 주요 작업 | 산출물 |
|---|---|---|---|
| 1일차 오전 | 특강 (개인 실습) | Step 1~8 전 과정 따라가기 | 초안 SA 문서 세트 (개인별) |
| 1일차 오후 | 팀 재진행 1차 | 개인 결과물 공유 → 팀 버전 통합 | 팀 개요서, 페르소나, 유스케이스 |
| 2일차 | 팀 작업 | ERD, API 명세서, OpenAPI YAML 확정 | 팀 ERD, API 명세서 |
| 3일차 | 팀 작업 | 화면 설계서+Figma 목업, 인프라, 동시성 설계서, ADR | 전체 SA 문서 세트 완성 |
💡 오전 특강 후 오후엔 팀으로!
특강 중에는 개인으로 진행하세요. 각자 프롬프트 감각을 익히는 게 먼저입니다. 오후에 팀으로 모였을 때, 각자가 만든 결과물을 비교하면서 통합하면 "AI는 같은 프롬프트에도 다른 답을 준다" 는 걸 실감할 수 있습니다. 이 경험 자체가 큰 학습입니다.
다음 프로젝트 Day 예고
"이제 SA 문서가 생겼습니다. 이걸 근거로 실제 코드를 씁니다. 바이브코딩이 아니라 명세기반 개발로요. '이 SA 문서 참고해서 Post 엔티티 먼저 만들어줘' 같은 식으로 AI한테 지시할 수 있게 됩니다. 그 감각이 오늘 특강의 진짜 목표입니다."
튜터의 과제
과제 (Homework)
- [필수] 팀 SA 문서 세트 완성 (3일간)
- 섹션 10종 모두 포함: 개요서, 페르소나/시나리오, 유스케이스, 기능명세, ERD, API명세서, 화면설계서, 인프라, 동시성설계서, ADR
- 제출 형태: GitHub Repository 또는 Notion 워크스페이스
- 필수 포함: Mermaid ERD, OpenAPI YAML, Figma 목업 링크, ADR 최소 3건
- [필수] 프롬프트 히스토리 기록
- 이번 SA 문서를 만들며 AI에게 던진 주요 프롬프트 5개 이상 + 그에 대한 AI의 답변을 별도 파일(
prompts.md)로 기록 - 왜 그 프롬프트를 썼는지, 답변이 만족스러웠는지 코멘트 추가
- 이번 SA 문서를 만들며 AI에게 던진 주요 프롬프트 5개 이상 + 그에 대한 AI의 답변을 별도 파일(
- [필수] 동시성 설계서 최소 시나리오 수
- 동시성 충돌 시나리오 최소 5개 이상 포함
- 각 시나리오마다 추천 전략 + 이유 + 실패 케이스까지 명시
- [선택] 개인 vs 팀 결과물 비교
- 특강 중 개인이 만든 초안과 오후에 팀으로 만든 버전의 차이점을 정리
- "내가 놓친 부분" / "팀원이 놓친 부분" / "AI가 일관되게 틀린 부분" 각각 1개 이상
- [선택] 다른 AI 모델 교차 검증
- 같은 프롬프트를 Claude, ChatGPT, Gemini에 각각 던지고 답변을 비교
- 어떤 모델이 어떤 문서 유형에 강한지 본인만의 기준을 만들어보세요
🤔 생각해볼 거리 (토론 주제)
- 바이브코딩 vs 명세기반 개발의 경계
- 오늘 배운 명세기반 개발이 만능일까요? 어떤 상황에서는 오히려 바이브코딩이 더 나을까요? "3일간의 해커톤" vs "3개월짜리 실서비스" 를 비교해서 논의해보세요.
- AI가 던진 질문의 품질
- 특강 중 AI가 여러분에게 던진 질문 중 가장 날카로웠던 것과 가장 뻔했던 것을 비교해보세요. 품질 차이가 왜 났을까요? 프롬프트를 어떻게 개선하면 더 날카로운 질문을 받을 수 있을까요?
- 레드팀 패턴의 한계
- AI가 자기가 만든 걸 AI가 비판하는 방식, 완벽할까요? AI가 미처 비판하지 못하는 blind spot은 어디일까요? 이걸 사람이 어떻게 보완할 수 있을까요?
- ADR의 재검토 시점
- 오늘 여러분이 만든 ADR 중 "재검토 조건"을 가장 엄격하게 잡아야 할 결정은 무엇인가요? 왜 그렇게 생각하세요?
- "AI 없으면 설계 못 하는 개발자"가 되지 않으려면?
- AI에 너무 의존하면 본인의 설계 근력이 사라질 위험이 있습니다. AI를 쓰면서도 본인이 성장하려면 어떻게 해야 할까요? 오늘 배운 5가지 프롬프트 패턴 중 어떤 게 가장 본인 성장에 도움이 될 것 같나요?
마지막 한마디
오늘 여러분은 AI와 협업하는 법을 배웠지만, 진짜로 얻어가야 할 건 "스스로에게 좋은 질문을 던지는 습관" 입니다.
AI에게 좋은 질문을 할 수 있다는 건, 문제를 깊이 이해하고 있다는 뜻이니까요.
남은 3주 동안, AI와 같이 성장하는 개발자가 되길 바랍니다. 화이팅!
