AI 기반 애플리게이션 개발 라이프사이클 - 실무 가이드

기존의 폭포수(Waterfall)와 애자일(Agile)은 모두 인간의 인지 속도와 의사소통 비용을 기준으로 설계된 방법론이다. 스프린트는 2주, 회의는 매일, 코드 리뷰는 며칠씩 걸린다. 그 속도에 맞게 프로세스가 짜여 있다. AI는 그 전제를 깨뜨린다. 코드를 생성하고 인프라를 구성하는 속도는 인간의 수십 배에 달한다. 기존 방법론을 그대로 AI에 적용하면 결정적인 불일치(Mismatch)가 발생한다. AI를 단순한 보조 도구로 끼워 넣는 것은 AI의 역량을 제한할 뿐 아니라 기존의 비효율을 고착시킨다.

제대로 쓰려면 구조가 달라야 한다. AI를 보조 도구가 아닌 프로젝트의 컨텍스트를 유지하는 디지털 동료로 정의하고, 그에 맞는 워크플로우를 설계해야 한다. 이 블로그에서는 프로젝트 설정부터 요구분석, 반복 개발, 지식 축적까지 — Claude Code를 중심으로 실제 개발 흐름 전체를 정리했다.

목차

1. 개요
2. 컨텍스트 관리 체계
3. 프로젝트 설정
4. 요구분석
5. 반복 개발 — Iteration
6. 지식 축적
7. 운영
8. AI Context 이해하기
9. 팀에서 사용할 때
10. 마치며
11. 참고문헌

1. 개요

[프로젝트 설정]           [요구분석]              [반복 개발]                [운영]
CLAUDE.md 생성     →    요구사항 수집       →    백로그 작성 (1개)     →     GitOps 연동
rules/ 추가             기능 도출                     ↓                      ↓             
conventions/ 추가       아키텍처·스택 결정        Contract → Slices        로그/에러 분석
                       스프린트 배정               구현 → 테스트                ↓
                                                   ↓                  피드백 루프
                                              PR → Merge               → 백로그
                                                   ↓
                                              지식 축적(MEMORY.md)
                                              패턴 반복되면
                                              conventions/승격 
                                                    ↓    
                                              (Next Step)

프로젝트 설정은 AI가 프로젝트를 이해하기 위한 준비다. 한 번만 한다.
요구분석은 무엇을 어떤 순서로 만들지 정하는 단계다. 기능 목록과 순서만 확정하고, 백로그 상세 작성은 하지 않는다.
반복 개발은 Step 백로그를 작성하고 구현 후 PR로 합치는 사이클이다. 계속 반복된다.
운영은 배포 이후 AI가 피드백 루프를 형성하는 확장 영역이다. 이 글에서는 개념만 소개하고 다음 편에서 다룬다.

Sprint 1 시작 전에 아키텍처 프로토타이핑을 먼저 완료해야 한다.
스택 검증과 인프라 셋업이 끝난 뒤에 Step 개발을 시작한다.

2. 컨텍스트 관리 체계

기존 Agile이 ‘사람 간의 소통’에 집중했다면, AI-SDLC는 **‘AI와 사람 사이의 컨텍스트 동기화’**에 집중한다. AI가 길을 잃지 않도록 프로젝트 루트에 아래 지식 저장소를 반드시 구성해야 한다.

이 체계가 갖춰지면 AI는 새 세션을 열어도 프로젝트 맥락을 즉시 파악할 수 있다. 완벽한 매뉴얼을 쓰려 하기보다, AI가 잘못된 방향으로 가지 않도록 막는 가드레일로 접근하는 것이 현실적이다.^{1 2}

3. 프로젝트 설정

3-1. 디렉토리 구조

CLAUDE.md             ← AI의 프로젝트 설명서 (가드레일)
MEMORY.md             ← AI의 장기 기억 (누적)
.claude/
  rules/              ← AI 행동 규칙 (계획 방식, 컨텍스트 관리 등)
  conventions/        ← 공식화된 코드 패턴
  backlog/            ← 구현 대기 중인 기능 목록
  0-plan/             ← 현재 구현 중인 Step의 계약서 + 슬라이스

3-2. CLAUDE.md 작성

프로젝트 스택, 레이어 구조, 알려진 함정(gotchas)을 여기에 쓴다. 상황에 따라 접근이 다르다.

설정이 완료되면 커밋한다.

git add CLAUDE.md MEMORY.md .claude/
git commit -m "docs: AI development guidelines"

4. 요구분석

요구분석의 목적은 무엇을 어떤 순서로 만들지 합의하는 것이다. 결과물은 기능 목록과 순서다. 백로그 상세는 여기서 쓰지 않는다.

1. 요구사항 수집
만들고 싶은 것을 설명한다. AI가 Frontend / Backend로 분류한 기능 목록 초안을 만들어준다.

2. 기능 도출 및 아키텍처 결정
화면 흐름, 데이터 모델, 레이어 구조, 테크스택을 결정한다. 결정된 내용은 CLAUDE.md와 conventions/00-tech-stack.md에 기록한다. 여기서 확정된 것이 이후 모든 개발의 기준이 된다.

3. 스프린트 배정
기능을 스프린트 단위로 묶고 순서를 정한다. 핵심 기능 먼저, 의존성 순서대로 배치한다. 이 단계는 사람이 결정한다.

여기까지가 요구분석이다. 백로그 상세 작성은 각 Step을 시작하기 직전에 한다.
미리 다 써두면 구현 결과에 따라 틀어질 때 다시 써야 하는 낭비가 생긴다.

5. 반복 개발 — Iteration

요구분석이 끝나면 이 사이클을 반복한다. 백로그 작성 → 구현 → PR이 한 묶음이다. 각 주기는 15~30분 내외의 초단기 구현 단위(Iteration)로 운영된다. 다음 Step 백로그는 이전 Step PR이 머지된 뒤에 쓴다.

5-1. 백로그 작성 (Step 시작 직전)

백로그 항목 하나가 곧 Step 하나다. 작성 전에 AI가 두 가지를 먼저 확인한다.

• UI 의도: 어떤 페이지/컴포넌트에서, 어떤 형태로 동작하는가?
• DB 스키마: 신규 테이블인가, 기존 테이블 수정인가?

제목: NN. [기능명]: [핵심 행위]

Why:  현재 상태의 문제 → 원하는 상태
Scope:
  - 변경할 것
  - 변경하지 않을 것  ← 반드시 명시
UI:
  - 위치: [페이지/컴포넌트]
  - 형태: [버튼/모달/폼/페이지]
  - 수정/신규: [기존 컴포넌트명 또는 신규]
DB:
  - [신규 테이블명] 또는 [기존 테이블 수정]
  - 핵심 필드: [목록]
Dependencies:
  - 인프라 / 선행 Step
Notes:
  - 구현 시 주의할 점 (구현이 가까워지면 채움)

변경하지 않을 것을 명시하는 게 핵심이다. AI가 건드리지 말아야 할 영역을 명확히 알아야 예상치 못한 수정이 생기지 않는다.

5-2. Step 실행 흐름

AI가 계획을 제안하고 사람이 승인하는 역방향 대화(Reverse Conversation) 방식으로 진행한다.

1. AI 확인 (필수)
   - Acceptance criteria가 무엇인가?
   - Full stack인가, Backend only인가?
   - 선행 Step 의존성은 없는가?

2. AI 제안 → 사람 승인
   - Contract JSON       → API 명세, 입출력 정의
   - Vertical slices     → 15분 단위 end-to-end 작업 목록
   - Reference files     → 100KB 이하로 필요한 것만

3. 승인 후 구현
   Phase 1 (2-3분)   CLAUDE.md + MEMORY.md 읽기   → 규칙, 패턴, Gotchas 파악
   Phase 2 (8분)     .claude/rules/ 참조           → contract, slices 계획
   Phase 3 (30-40분) .claude/conventions/ 참조     → 구현
   Phase 4 (10분)    Acceptance Criteria 검증

4. PR → Merge → MEMORY.md 업데이트 → 다음 Step 백로그 작성

Slice를 15분 이하로 유지하는 이유는 추적 가능성 때문이다. 작게 나누고 나눌 때마다 바로 테스트한다.

5-3. 체크리스트

구현 전:
[ ] CLAUDE.md + MEMORY.md 확인
[ ] Contract JSON 정의 & 승인
[ ] Slice 크기 15분 이하 확인

구현 중:
[ ] .claude/conventions/ 패턴 준수
[ ] 각 Slice 완료 후 즉시 테스트

PR 전:
[ ] npm run build → 0 errors
[ ] pnpm --filter backend test:unit → pass
[ ] curl test 통과
[ ] UI 동작 확인
[ ] DB 데이터 저장 확인
[ ] docker compose up → success
[ ] 새로고침 후 데이터 유지
[ ] MEMORY.md 업데이트 완료

5-4. PR 생성

gh pr create \
  --title "feat: Step N - [설명]" \
  --body "## Summary
- [변경 내용]

## Test
- curl: [명령어]
- UI: [확인 항목]"

6. 지식 축적

반복 개발하면서 발견한 것들을 체계적으로 쌓아야 다음 Step, 다음 세션에서 재발견하는 낭비가 없다.

6-1. MEMORY.md 운영

MEMORY.md는 현재 진행 상황, 결정된 아키텍처, 과거 오류와 해결책을 누적하는 파일이다. 구현이 완료되면 AI가 해당 세션에서 배운 새로운 사실을 MEMORY.md에 업데이트한다. 이것이 다음 세션에서 AI가 똑같은 실수를 반복하지 않게 만드는 핵심 장치다.

주의: MEMORY.md는 200줄이 넘으면 잘린다. 반복되는 패턴은 주기적으로 conventions로 승격시켜서 가볍게 유지해야 한다.

6-2. Conventions 승격 — 패턴의 공식화

PR 생성 전, AI가 MEMORY.md를 검토해서 승격 후보를 제안한다. 아래 기준 중 하나라도 해당하면 conventions로 옮긴다.

Q1. 다른 Step에서도 반복 적용될 패턴인가?
Q2. 이 프로젝트 전체에 일관되게 적용해야 하는가?
Q3. 새 AI 세션에서 코드를 보지 않아도 알아야 하는가?

Step 완료
    ↓
AI: MEMORY.md 검토 → 승격 후보 제안
    ↓
승인 → .claude/conventions/NN-*.md 작성 + MEMORY.md에서 해당 항목 제거
    ↓
PR 생성

7. 운영

개발이 끝난 뒤에도 AI의 역할은 계속된다. 배포 이후 운영 단계에서 AI가 피드백 루프를 형성한다.

핵심 개념은 세 가지다.
첫째, GitOps 파이프라인과 연동해 코드 변경이 인프라에 즉시 반영되게 한다.
둘째, 운영 중 발생하는 로그와 에러를 AI가 분석해 MEMORY.md의 개선 사항으로 피드백한다.
셋째, 이 피드백이 다시 백로그로 연결되어 개발 사이클이 닫힌 루프를 형성한다.

DevOps의 CI/CD 파이프라인, Kubernetes Ingress, Observability 스택과의 구체적인 연결 방법은 다음 편에서 다룬다.

8. AI Context 이해하기

이 시스템을 제대로 쓰려면 AI가 어떻게 정보를 처리하는지 알아야 한다.

8-1. 컨텍스트는 누적된다

[이전 대화 전체] + [새 메시지] → AI에게 전송

대화가 길어질수록 전송량이 늘어난다. 컨텍스트 윈도우 한계에 도달하면 자동 압축되고, 압축 과정에서 중요한 내용이 희석될 수 있다.³

8-2. 파일은 적을수록 좋다

파일 10개 (500KB) + 대화 (100KB) = 600KB → 느리고 혼란스러움
파일 3개  (30KB)  + 대화  (50KB) =  80KB → 빠르고 정확함

AI에게 넘기는 파일이 많을수록 오히려 품질이 떨어진다. rules에서 참조 파일을 100KB 이하로 제한하는 이유가 여기 있다.⁴ 필요한 파일만, 필요한 순간에 넘기는 것이 원칙이다.

8-3. 세션 관리

세션이 길어지거나 맥락이 꼬이기 시작하면 세 가지 선택지가 있다.

1. 새 세션 시작 — 가장 확실한 방법. MEMORY.md가 잘 정리돼 있으면 바로 이어갈 수 있다.
2. /clear — 대화는 초기화되지만 파일은 그대로다.⁵
3. MEMORY.md 업데이트 후 계속 — 핵심 내용을 파일에 저장하고 이어간다.

9. 팀에서 사용할 때

이 구조는 1~5인 소규모 팀에 적합하다. CLAUDE.md, backlog, conventions가 모두 git으로 공유되기 때문에 팀 협업에도 그대로 동작한다.

추가로 관리해야 할 것은 두 가지다.

• 작업 충돌: 누가 어떤 Step을 작업 중인지는 GitHub branch/PR로 관리한다.
• MEMORY.md 충돌: 동시 수정 시 PR merge 때 수동으로 조율한다.

9-1. 더 큰 팀으로 확장할 때

팀이 커지거나 도메인이 복잡해지면 아래 항목을 추가로 도입한다.

ADR (Architecture Decision Records)
아키텍처 결정을 문서로 남긴다. 여러 세션 또는 팀원 간에 같은 결정을 두 번 논쟁하는 낭비를 막는다.

.claude/decisions/
  001-use-redis-for-guest-session.md
  002-uuid-over-serial-for-tools.md

형식: 날짜 / 결정 / 이유 / 검토한 대안 / 결과

Event Storming
대규모 앱은 개발 전에 도메인 이벤트를 먼저 정리해야 한다. DB와 API 설계가 자연스럽게 도출된다. 소규모에서는 백로그의 Why + Scope로 대체 가능하다.

API Versioning
외부 클라이언트가 생기거나 Breaking Change가 잦아지면 버저닝을 도입한다.

현재: /api/admin/tools
확장: /api/v1/admin/tools

Multi-Agent 조율
AI 여러 개가 동시에 다른 기능을 개발하는 상황이 되면, 공유 컨텍스트와 작업 잠금 전략이 필요하다. MEMORY.md 하나로는 부족해진다.⁶

10. 마치며

이 시스템의 설계 철학은 작게 시작해서 쌓아가는 것이다.

처음부터 모든 conventions를 완성하려 하지 않아도 된다. CLAUDE.md를 완벽하게 쓰려 하지 않아도 된다. 개발하면서 발견한 것을 MEMORY.md에 기록하고, 반복되는 패턴을 conventions로 옮기면 된다. 그렇게 쌓인 파일들이 AI의 기억이 된다.

한 번 갖춰지면 AI는 매번 처음부터 시작하는 것이 아니라 이전 작업을 이어받아 개발을 진행하게 된다. 그것이 AI를 보조 도구가 아닌 디지털 동료로 쓰는 방법이다.

11. 참고문헌