<aside> 📌

Part 2 · Ch03 — Production-Level Scalability (Project 3)

Ch01에서 "동작하는" FinSight를 만들고, Ch02에서 PR마다 자동 리뷰를 붙였다. 이번엔 "동작한다"를 "프로덕션 레벨이다"로 끌어올린다 — 그것도 같은 에이전트(Claude Code) 한 스택으로 end-to-end.

한 줄 요약: 프로덕션 레벨을 막연한 느낌이 아니라 측정 가능한 5축(성능·보안·데이터 안전·관측성·품질)으로 못 박고, 나머지 클립이 한 축씩 에이전트로 잠근다. production scale, end-to-end agentic engineering.

</aside>

1. 프로덕션 레벨 = Production Readiness 5축

🛫 1-1. "동작한다" ≠ "프로덕션 레벨"

<aside> 🛫

내 노트북에서 로그인·차트·결제가 한 바퀴 돌면 "됐다" 싶다. 하지만 유저 1,000명이 들어오면 — 페이지가 3초씩 걸리고(성능), RLS 한 줄이 빠져 남의 데이터가 새고(보안), 마이그레이션 한 번 잘못 돌려 데이터가 날아가고(데이터 안전), 에러가 나도 아무도 모르고(관측성), 리뷰 에이전트가 갑자기 헛소리를 한다(품질).

핵심 질문: "프로덕션 레벨이라는 게 도대체 측정 가능한 무엇인가?" → 통과/실패를 판정할 수 있는 체크리스트로 만들어야 에이전트가 한 축씩 끌어올린다. (비행기 이륙 전 체크리스트처럼 — 느낌으로 이륙하지 않는다.)

</aside>

🗺️ 1-2. 5축 — 통과하면 프로덕션 레벨

<aside> ⭐

앞 3개(성능·보안·데이터 안전)는 익숙한 프로덕션 덕목. 마지막 5번 "품질"이 이 강의만의 축이다. 우리는 코드만 짠 게 아니라 **하네스(skill·agent·CLAUDE.md)**를 만들었고, 그 하네스 자체도 프로덕션 레벨인지 측정해야 한다. 코드에 테스트가 있듯, 하네스엔 Eval이 있다.

</aside>

🧭 1-3. 챕터 지도 — 한 클립 = 한 축

[Clip 02] 보안 ①        코드 전체 OWASP Top 10 스캔 (정기)
[Clip 03] 보안 ②·데이터  Supabase get_advisors + Staging
[Clip 04] 성능           Lighthouse auto research 루프
[Clip 05] 품질·관측성     하네스 Eval + PostHog error tracking
[Clip 06] 관측성          PostHog product analytics + SEO

순서 = 의존성. 보안·데이터(02·03) 먼저 잠그고 → 성능(04) → 품질·관측성(05·06).
데이터가 새는 채로 성능 튜닝하는 건 의미가 없으니까.

<aside> ⚠️

5축은 한 번 통과로 끝이 아님. 코드가 바뀌면 다시 깨진다 — 보안 스캔도 Eval도 정기적으로 재실행(그래서 보안 스캔이 "2주~월 1회"). 그리고 모든 축은 *"좀 빠른 것 같다"*가 아니라 *"LCP 2.5초 이하"*처럼 판정 가능해야 에이전트가 자기 채점을 한다.

</aside>

2. 보안 ① — 코드 전체 OWASP 스캔

🚪 2-1. PR 단위 vs 전체 코드베이스

<aside> 🚪

보안은 Ch02에서 한 번 다뤘다 — 단 PR 단위(Security plugin이 diff만 점검). 이번은 나머지 절반. PR 스캔은 "방금 바뀐 줄"만 본다. 6개월 전 들어가 아무도 다시 안 본 코드, 여러 파일에 누적된 구조적 취약점은 diff로 절대 안 잡힌다.

PR 스캔 = 문에서 검문, 전체 스캔 = 한 달에 한 번 집 전체 돌며 잠기지 않은 창문 점검. 둘 다 필요하다.

</aside>