Chapter 1. Node.js: 런타임의 한계를 넘어서는 설계
- 1-1. 이벤트 루프의 심연: AI가 놓치는 0.1ms의 블로킹을 잡아내는 법
- 이벤트 루프 단계별 동작과 sync 함수의 치명적인 한계.
- 대기열(Task Queue vs Microtask Queue) 우선순위가 분산 환경 레이턴시에 미치는 영향.
- 1-2. 멀티 프로세스와 EKS: Pod 하나에 Node 프로세스는 몇 개가 적당할까?
- 싱글 스레드의 한계와 cluster/pm2 활용법.
- k8s 리소스 리밋(CPU/Memory)과 Node 프로세스 개수의 상관관계 공식.
- 1-3. 데이터 스트림의 마법: 대용량 작업 앞에서 무너지지 않는 코드 작성법
- highWaterMark와 backpressure를 통한 메모리 관리.
- AI에게 스트림 기반 코드를 요청해야 하는 결정적인 이유.
Chapter 2. JavaScript: 동시성 모델과 안정성의 깊은 이해
- 2-1. 비동기 제어의 정석: Promise.allSettled와 분산 환경의 타임아웃 전략
- 부분적 성공(Partial Success)을 처리하는 우아한 패턴.
- 외부 API 호출 시 '폭포수(Waterfall) 현상' 방지를 위한 병렬 처리 설계.
- 2-2. 타입 시스템의 함정: Zod를 활용한 런타임 경계 방어하기
- TypeScript가 보장하지 못하는 '외부 데이터'의 불확실성 제거.
- API 요청/응답 및 DB 데이터의 런타임 유효성 검사 전략.
- 2-3. 에러 핸들링의 계층화: '무시해도 되는 에러'와 '알람을 울려야 하는 에러'
- 도메인 에러 vs 시스템 에러의 명확한 구분.
- 에러 전파(Propagation) 전략과 중앙 집중형 로깅 패턴.
Chapter 3. NestJS: 모듈화와 분산 시스템의 가교
- 3-1. DI(의존성 주입)의 재해석: 테스트를 넘어 경계와 역할을 정의하는 도구
- 모듈 간 결합도를 낮춰 마이크로서비스(MSA) 전환을 대비하는 설계.
- 3-2. 요청 수명주기 활용: 공통 관심사(Cross-cutting Concerns)를 배치하는 최적의 위치
- Guard, Pipe, Interceptor, Filter의 선후 관계와 보안/로깅/트랜잭션 적용 시점.
- 3-3. 멱등성(Idempotency): 분산 시스템에서 재시도가 안전해지는 법
- AI가 짠 코드에서 가장 빈번하게 누락되는 '멱등키'와 '중복 요청 방지' 로직.
Chapter 4. SQL & Prisma: 추상화 뒤에 숨겨진 물리적 진실
- 4-1. ORM의 역설: Prisma 로그로 실제 SQL 쿼리 뜯어보기
- N+1 문제, 불필요한 Join, Index를 타지 않는 쿼리 진단 및 튜닝.
- 4-2. 트랜잭션과 격리 수준: 데이터 정합성을 지키는 마지막 보루
- DB 격리 수준(Isolation Level)이 비즈니스 로직(재고 관리 등)에 미치는 영향.
- 4-3. 커넥션 풀링 잔혹사: Pod가 스케일 아웃될 때 DB가 비명을 지르는 이유
- HPA와 RDS 커넥션 한계 사이의 균형 잡기 ($Pod \times PoolSize$ 계산법).
Chapter 5. Docker & EKS: 컨테이너는 단순한 박스가 아니다
- 5-1. Docker 최적화: 보안과 속도를 동시에 잡는 이미지 빌드 전략
- 멀티 스테이지 빌드와 non-root 실행 권한의 중요성.
- 5-2. Graceful Shutdown: EKS 롤링 배포 시 "요청 유실 제로" 만들기
- SIGTERM 핸들링과 k8s readinessProbe 사이의 타이밍 조율.
- 5-3. 리소스 격리(cgroup): Node.js 메모리 리밋과 k8s 리밋의 하모니
- OOMKilled를 방지하는 --max-old-space-size 설정과 리소스 할당 전략.
Chapter 6. Networking & Observability: 보이지 않는 흐름 제어
- 6-1. EKS 네트워크의 혈관: VPC CNI와 서비스 통신의 물리적 경로
- Ingress부터 Pod까지 데이터가 흐르는 과정과 지연 시간(Latency) 포인트.
- 6-2. 방어적 코딩의 정수: 서킷 브레이커와 재시도 패턴
- 외부 서비스 장애가 내 서비스로 전염되는 것을 막는 폴백(Fallback) 설계.
- 6-3. 분산 트레이싱: 로그 한 줄에 trace_id가 박혀야 하는 이유
- OpenTelemetry를 활용한 분산 시스템 디버깅과 장애 지점 1분 안에 찾기.
Chapter 7. AI Collaboration: 훌륭한 '지시자'가 되는 법
- 7-1. CS 컨텍스트 주입: AI에게 제약 조건을 먼저 제시하는 프롬프트 기술
- "환경 + 트래픽 + 장애 가정"을 포함한 프롬프트 템플릿 설계.
- 7-2. 코드 리뷰어로서의 나: AI가 만든 '해피 케이스' 코드 속 독성(Toxic) 찾기
- 타임아웃, 예외 처리, 보안 결함 등 AI가 놓치기 쉬운 5대 체크리스트.
- 7-3. 실전 워크플로우: 복잡한 기능을 AI와 함께 설계부터 배포까지
- 요구사항 정의 → AI 설계 → 인프라 제약 반영 → 코드 리뷰 → 회고.
Chapter 8. 총정리: AI 시대, 대체 불가능한 개발자의 지도
- 8-1. 변하지 않는 본질: 왜 CS 지식이 AI 시대의 가장 강력한 무기인가?
- 8-2. 나만의 체크리스트: 코드를 커밋하기 전 스스로에게 던지는 5가지 질문.
Chapter 1. Node.js: 런타임의 한계를 넘어서는 설계
- 핵심: AI는 sync와 async를 문법적으로는 구분하지만, 트래픽이 몰리는 상황에서의 이벤트 루프 지연까지는 계산하지 못합니다.
- Tip: "AI에게 특정 로직을 시켰더니 JSON.parse나 무거운 정규표현식을 메인 스레드에서 돌려 서비스가 뻗었던 사례"를 넣으면 아주 임팩트가 큽니다.
Chapter 2. JavaScript: 동시성 모델의 깊은 이해
- 핵심: Promise.all은 하나라도 터지면 다 실패합니다. 분산 환경에선 **부분적 성공(Partial Success)**을 인정하는 allSettled와 Zod를 통한 방어적 코딩이 필수임을 강조하세요.
Chapter 3. NestJS: 모듈화와 분산 시스템의 가교
- 핵심: 멱등성(Idempotency) 설계는 AI가 가장 빈번하게 놓치는 부분입니다. 네트워크 재시도로 인해 같은 주문이 두 번 들어올 때, 인프라 수준이 아닌 코드 수준에서 어떻게 막을지 다룹니다.
Chapter 4. SQL & Prisma: 추상화 뒤에 숨겨진 물리적 진실
- 핵심: $Pod \times Max\_Connections$ 공식을 잊지 마세요.
- 공식 활용:이 수치가 RDS의 max_connections를 넘는 순간 서비스는 마비됩니다. AI는 인프라 상황을 모르고 풀 사이즈를 키우라고 조언할 수 있음을 경고해야 합니다.
-
$$Total\_DB\_Connections = Pod\_Count \times Prisma\_Pool\_Size$$
Chapter 5. EKS & Docker: 컨테이너는 단순한 박스가 아니다
- 핵심: Graceful Shutdown은 무중단 배포의 핵심입니다. AI에게 "종료 로직 짜줘"라고만 하면 SIGTERM 신호를 받고 0.1초 만에 꺼지는 코드를 줄 수도 있습니다. 드레인(Drain) 시간을 고려한 설계를 다뤄주세요.
Chapter 6. Networking & Observability: 보이지 않는 흐름 제어
- 핵심: VPC CNI 환경에서 Pod IP 부족 이슈나, 외부 API 호출 시 타임아웃이 중첩되어 발생하는 **Cascading Failure(연쇄 장애)**를 막는 법(Circuit Breaker)을 연결하세요.
Chapter 7. AI Collaboration: 훌륭한 '지시자'가 되는 법
- 핵심: 프롬프트에 **"이 코드는 EKS에서 돌아가며, DB 커넥션은 5개로 제한되어 있고, 멱등성이 보장되어야 해"**라는 제약을 먼저 거는 것과 아닌 것의 차이를 보여주세요.
'Project > 기록' 카테고리의 다른 글
| Log 영속성을 위한 MQ 도입 (1) | 2025.06.10 |
|---|---|
| MySQL에서의 Lock 경합 문제 해결과 성능 개선 (2) | 2025.06.09 |
| Bullmq Document + CS 관점으로 다시 생각 (1) | 2025.06.05 |
| 멱등성(Idempotency)이란? (0) | 2025.06.02 |
| 비동기 아키텍처 전환 (0) | 2025.05.28 |