캡스톤: AI로 기능 하나를 처음부터 끝까지

🔄 이전 레슨 복습: 이전 레슨에서 아키텍처 결정과 시스템 설계를 배웠어요. 이제 모든 것을 종합해서 하나의 기능을 처음부터 끝까지 만들어요.

모든 것이 하나로

지난 7개 레슨에서 코드 생성, 디버깅, 테스팅, 코드 리뷰, 문서화, 아키텍처 결정에 AI를 활용하는 법을 배웠어요. 이제 하나의 기능에 전부 적용할 시간이에요.

장난감 수준 연습이 아니에요. 실제 애플리케이션에 필요한 기능을 만들고, 프로세스의 모든 단계에서 AI를 사용해요. 기법들이 어떻게 복합적으로 작용하는지 보게 될 거예요 — 앞선 AI 지원 단계 덕분에 각 단계가 더 빠르고 효과적이에요.

기능: Rate Limiting API

API용 rate limiting 시스템을 만들어요. 캡스톤으로 적합한 이유:

• 아키텍처 결정이 필요해요 (카운터 저장 위치, 알고리즘 선택)
• 신중한 구현이 필요해요 (레이스 컨디션, 엣지 케이스)
• 테스팅이 핵심이에요 (타이밍, 동시성, 경계 조건)
• 명확한 문서가 필요해요 (다른 개발자가 설정해야 하니까)
• 보안 관련 사항은 꼼꼼한 리뷰가 필수예요

요구사항:

• 유저별, 시간 윈도우별 API 요청 제한
• 엔드포인트별 다른 제한 지원
• 표준 rate limit 헤더 반환 (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset)
• 엣지 케이스 처리 (클럭 스큐, 분산 서버, 버스트 트래픽)
• 미들웨어로 설정 가능 (어떤 라우트에든 쉽게 추가)

1단계: 아키텍처 결정 (레슨 7)

먼저, 어떻게 만들지 결정해요:

Express.js/TypeScript API에 rate limiting을 추가해야 해요.
캐싱에 이미 Redis를 사용 중이에요.

우리 상황에 맞게 비교해줘:
1. 고정 윈도우 카운터
2. 슬라이딩 윈도우 로그
3. 슬라이딩 윈도우 카운터
4. 토큰 버킷

제약: ~10,000 활성 사용자, 유저별·엔드포인트별 제한,
로드밸런서 뒤 API 서버 3대, Redis 사용 가능, 피크 1,000 req/sec

각 접근법 분석: 정확도, Redis 메모리 사용량,
구현 복잡도, 윈도우 경계에서의 동작.

AI가 트레이드오프를 제시해요. 우리 경우 슬라이딩 윈도우 카운터를 추천 — 충분히 정확하고(고정 윈도우의 경계 스파이크 없음), 메모리 효율적이고(슬라이딩 로그보다), 토큰 버킷보다 단순해요.

결정: Redis를 사용한 슬라이딩 윈도우 카운터. ADR로 문서화.

2단계: 코드 생성 (레슨 2)

코드베이스 맥락을 제공해서 구현을 생성:

Express.js + TypeScript로 rate limiting 미들웨어를 구현해줘.

알고리즘: Redis 슬라이딩 윈도우 카운터
저장소: 기존 Redis 인스턴스 (ioredis)

우리 미들웨어 패턴:
[기존 미들웨어 예시 붙여넣기]

요구사항:
- 설정: { windowMs: number, maxRequests: number }
- 키 형식: ratelimit:{userId}:{endpoint}:{windowId}
- 제한 초과 시 429 + Retry-After 헤더
- 모든 응답에 X-RateLimit-* 헤더
- Redis 장애 시 graceful 처리 (fail open)
- strict 타입의 TypeScript

3단계: 디버깅 (레슨 3)

로컬에서 실행하는데 동시 요청이 들어오면 카운트가 약간 어긋나요:

rate limiter에서 레이스 컨디션이 발생해요.
10개 동시 요청이 들어오면 카운터가 10 대신
가끔 8이나 9를 보여요.

문제: redis.incr()과 redis.get()이 별도 명령이에요.
INCR과 GET 사이에 다른 요청이 카운터를 변경할 수 있어요.

이 레이스 컨디션을 어떻게 고쳐야 하나요?

AI가 Redis Lua 스크립트로 increment-and-check를 원자적으로 만들라고 제안:

local current = redis.call('INCR', KEYS[1])
if current == 1 then
  redis.call('EXPIRE', KEYS[1], ARGV[1])
end
local prev = redis.call('GET', KEYS[2]) or 0
return {current, prev}

Redis 서버에서 원자적으로 실행 — 레이스 컨디션 불가능.

4단계: 테스팅 (레슨 4)

이 rate limiting 미들웨어에 대한 포괄적 테스트를
Jest + supertest로 작성해줘.

테스트 카테고리:
1. 기본 rate limiting (제한 내 통과, 초과 시 429)
2. 슬라이딩 윈도우 동작
3. 헤더 정확성
4. Redis 장애 시 fail open
5. 유저별 격리
6. 엔드포인트별 격리
7. 윈도우 리셋 동작
8. 동시 요청 처리

동시 요청 테스트와 윈도우 경계 테스트에 특히 주의 — 프로덕션에서 rate limiter를 망가뜨리는 엣지 케이스예요.

5단계: 코드 리뷰 (레슨 5)

머지 전 AI 리뷰:

이 rate limiting 미들웨어를 프로덕션 준비 상태로 리뷰해줘.

초점:
1. 보안: 사용자가 rate limit을 우회할 수 있는가?
2. 성능: 부하에서 병목이 있는가?
3. 신뢰성: 장애 시 어떻게 되는가?
4. 정확성: 슬라이딩 윈도우 수학이 맞는가?

AI가 잡을 수 있는 것:

• “X-Forwarded-For 헤더 스푸핑으로 rate limit 우회 가능. 프록시가 덮어쓰기 설정인지 확인 필요.”
• “Lua 스크립트에서 KEYS[2]가 만료된 경우 처리 필요.”
• “헬스 체크 엔드포인트가 rate limit을 우회하도록 skip 함수 추가 고려.”

6단계: 문서화 (레슨 6)

rate limiting 미들웨어에 대한 문서를 생성해줘.
대상: 엔드포인트에 rate limiting을 추가해야 하는 팀 개발자.

포함: 빠른 시작, 설정 옵션, 알고리즘 간략 설명,
응답 헤더 설명, 에러 응답, 일반적인 설정 예시,
트러블슈팅 가이드.

전체 워크플로 요약

AI 없이 총: 12-20시간, 며칠에 걸쳐 AI와 함께 총: 2-3시간, 한 세션에

코너를 깎아서가 아니에요. 각 단계가 철저해요 — 시간 압박에서 인간이 건너뛰는 엣지 케이스와 보안 이슈를 AI가 잡으니까, 오히려 더 철저해요.

이 코스에서 배운 것

핵심 정리

• AI 지원 워크플로는 코드 작성뿐만 아니라 개발의 모든 단계에 닿아요
• 각 단계가 다음을 증폭해요 — 좋은 아키텍처 결정이 코드 생성을 쉽게, 좋은 테스트가 리뷰를 빠르게
• AI가 며칠 걸리는 기능 구축을 몇 시간의 집중 작업으로 줄여요
• 결정은 여러분이 하고, AI가 실행을 가속화해요
• 이 기법들을 실제 업무에 바로 사용하세요 — 학습 곡선은 짧고 효과는 즉시예요

축하해요! AI로 더 빠르게 코딩하기 코스를 완료했어요. AI가 예전에 여러분을 느리게 만들던 부분을 처리하도록 하고, 멋진 것을 만드세요.