아키텍처 결정과 시스템 설계

🔄 이전 레슨 복습: 이전 레슨에서 AI로 문서화와 지식 공유를 배웠어요. 이제 AI로 아키텍처 결정을 내리는 법을 다뤄요.

두고두고 따라다니는 결정

모든 개발자에게 하나씩 있어요: 그때는 맞는 것 같았는데 악몽이 된 아키텍처 결정. 복잡성을 세 배로 만든 마이크로서비스 전환. 리포팅 요구사항을 감당 못 한 NoSQL 데이터베이스. 디버깅 지옥이 된 이벤트 기반 아키텍처.

이런 결정은 되돌리기 비싸요. 잘못된 기술 선택은 몇 달의 엔지니어링 시간을 낭비할 수 있어요. 최악은? 프로덕션 문제에 깊이 빠져야 잘못됐다는 걸 알게 돼요.

AI가 이 결정을 대신하지는 않아요 — 대신하게 하면 안 돼요. 하지만 여러분이 생각하지 못한 트레이드오프를 제시하고, 프로덕션에서만 발견할 장애 모드를 드러내고, 각 옵션의 2차 효과를 생각하게 해줘요.

아키텍처 결정 프레임워크

1단계: 문제 공간 정의

SaaS 앱의 알림 시스템을 설계해야 해요.

맥락:
- 현재 활성 사용자 50,000명, 월 20% 성장
- 알림 타입: 이메일, 인앱, 푸시, SMS
- 사용자별 타입 선호도 설정
- 일부는 시간 중요 (보안 알림)
- 일부는 배치 (일일 다이제스트)
- 전송 추적과 재시도 로직 필요
- 팀: Python에 강한 백엔드 개발자 4명
- 현재 스택: Django, PostgreSQL, Redis, AWS

핵심 아키텍처 결정이 뭐가 있을까요?

AI가 결정 포인트를 식별해요: 동기 vs 비동기 처리, 큐 기술 선택, 알림 상태 DB, 전송 서비스 (빌드 vs 구매), 재시도와 장애 처리 전략.

2단계: 트레이드오프와 함께 옵션 탐색

알림 큐에 대해 이 옵션들을 우리 제약 조건
(Python 팀, AWS, 50K 사용자, 월 20% 성장)
에 맞춰 비교해줘:

1. Celery + Redis
2. AWS SQS + Lambda
3. RabbitMQ
4. Kafka

각 옵션 분석: 구현·유지보수 복잡도, 확장성 한계,
장애 모드와 복구, 우리 규모의 운영 비용,
Python 팀 학습 곡선, 50만 사용자가 되면?

AI가 철저한 비교를 만들어요:

이 표만으로 수 시간의 리서치를 절약해요. 진짜 가치는 AI가 추가하는 뉘앙스 — Celery + Redis가 빠르게 배포하기엔 최고지만 과부하에서 메시지 확인 문제가 있다든지, SQS + Lambda가 콜드 스타트 지연 때문에 시간 중요 보안 알림에 문제가 될 수 있다든지.

✅ 확인 질문: AI가 “MongoDB를 알림 저장소로 사용하세요. 유연한 스키마를 지원하고 수평 확장이 돼요"라고 추천해요. 빠진 트레이드오프는 뭘까요?

알림은 무거운 쿼리 패턴이 있어요 (유저 X의 읽지 않은 알림을 시간순 정렬로 보여줘). MongoDB도 가능하지만 인덱스 관리가 필요해요. PostgreSQL이 이 접근 패턴에는 더 단순할 수 있고, 팀이 이미 알고 있어요. “유연한 스키마"는 좋게 들리지만, 알림 스키마는 사실 꽤 안정적이에요.

아키텍처 결정 기록 (ADR)

모든 중요한 결정은 문서화해야 해요:

알림 큐 결정에 대한 ADR을 작성해줘.

결정: Phase 1은 Celery + Redis, Phase 2에서
SQS로 마이그레이션 경로 포함.

맥락: [1단계 문제 설명 붙여넣기]

고려한 옵션:
1. Celery + Redis
2. SQS + Lambda
3. RabbitMQ
4. Kafka

결정 동인:
- 최대한 빠른 출시 (팀이 Celery를 이미 앎)
- 현재 규모에 적합
- 성장 시 명확한 마이그레이션 경로

MADR 형식으로 작성.

ADR이 조직 기억이 돼요 — 6개월 후 누군가 “왜 Kafka를 안 썼어?“라고 물으면, 답이 문서화돼 있어요.

AI로 시스템 설계

실시간 협업 문서 에디터를 설계하려고 해요.

제약 조건:
- 문서당 50명 동시 편집
- 다른 편집자에게 200ms 내 변경 반영
- 충돌 해결 필수
- 오프라인 편집 + 재연결 시 동기화
- 문서 크기 최대 100페이지

고민하는 질문:
1. 충돌 해결에 CRDT vs OT?
2. 실시간 동기화용 WebSocket 아키텍처?
3. 오프라인/동기화 시나리오 처리?
4. 버전 히스토리 저장 전략?

핵심 문구: “내가 생각하지 못한 게 뭐가 있을까?”

논의한 아키텍처를 기반으로, 내가 생각하지 못하는
장애 모드나 엣지 케이스가 뭐가 있을까?

AI가 드러낼 수 있는 것:

• “두 사용자가 오프라인에서 같은 문단을 편집하고 동시에 온라인으로 돌아오면?”
• “매우 느린 연결의 사용자가 라이브 문서보다 30초 뒤처지면?”
• “전체 CRDT 상태 로딩에 수 초 걸리는 매우 긴 문서는?”

이런 질문들이 새벽 2시 프로덕션 장애를 막아줘요.

기술 평가

기존 REST API에 GraphQL을 추가하는 걸 고려 중이에요.

현재 상황:
- React 프론트엔드를 서빙하는 REST 엔드포인트 30개
- 3개월 후 모바일 앱 출시 (같은 데이터, 다른 형태)
- 6명 팀, GraphQL 경험 없음
- Express.js, PostgreSQL 사용

평가해줘:
1. 구체적으로 어떤 문제를 해결하는가?
2. 어떤 새 문제를 만드는가?
3. 현재 REST API에서의 마이그레이션 경로?
4. 학습 곡선 포함 현실적 타임라인?
5. 같은 문제를 더 적은 disruption으로 해결하는 대안?

AI가 “모바일용 다른 데이터 형태” 문제는 REST + 필드 선택(JSON:API sparse fieldsets)으로도 해결 가능하고, 학습 곡선이 0이라고 지적할 수 있어요.

핵심 정리

• AI에게 트레이드오프를 제시하게 하세요, 결정을 맡기지 말고
• 항상 장애 모드와 2차 효과를 물어보세요
• 명시적 트레이드오프 비교와 함께 여러 옵션을 요청하세요
• “내가 생각하지 못한 게 뭐야?“가 가장 강력한 아키텍처 프롬프트예요
• ADR로 결정을 문서화하세요 — AI가 이걸 수월하게 만들어요
• 기술 평가에 트렌디한 옵션만이 아닌 대안도 포함하세요

다음 레슨: 캡스톤 — AI로 기능 하나를 처음부터 끝까지 구축해요. 지금까지 배운 모든 것이 하나로 합쳐져요.