Ch.24 AI 활용 전략¶
앞에서 하나의 요청이 거치는 7개 레이어를 따라가면서, 각 레이어에서 어떤 키워드가 작동하는지를 매핑했다. 이번에는 그 키워드를 AI에게 건네는 방법을 이야기한다.
Ch.7에서 "CS 키워드를 모르면 AI에게 좋은 지시를 내릴 수 없다"고 했다. Ch.8에서 카테고리별 키워드 사전을 만들었다. Ch.9에서 AI가 만든 코드를 CS 관점에서 리뷰하는 체크리스트를 만들었다.
24챕터를 거친 지금, Part 2의 내용을 전체 커리큘럼과 결합할 수 있다.
AI는 도구다. CS 키워드는 그 도구의 제어 장치다.¶
Ch.7에서 이런 비유를 했다. AI는 검색 엔진과 비슷하다. 검색 엔진에 "서버 느림"이라고 치면 잡다한 결과가 쏟아진다. "connection pool exhaustion FastAPI"라고 치면 정확한 결과가 나온다.
AI도 마찬가지다. "이 API 성능 최적화 해줘"라고 하면 Redis를 설치하라고 한다. "N+1 Problem이 있는지 EXPLAIN으로 확인해줘"라고 하면 정확한 쿼리 분석을 해준다.
차이는 키워드다. 그리고 24챕터를 거치면서 그 키워드를 쌓았다.
레이어별 AI 프롬프트 가이드¶
앞에서 정리한 7개 레이어 각각에서 문제가 생겼을 때, AI에게 어떤 키워드로 지시하면 좋은지를 정리한다.
성능 문제 - "느리다"¶
"느리다"는 증상이지 원인이 아니다. Ch.3에서 봤듯이, 느린 원인은 CPU Bound와 I/O Bound로 나뉜다.
키워드를 모르는 프롬프트:
키워드를 아는 프롬프트:
"이 엔드포인트의 응답이 느린데, htop으로 보니 CPU 사용률은 낮고
I/O wait가 높다. I/O Bound 문제인 것 같다.
DB 쿼리 수를 줄이는 방향으로 최적화해줘.
특히 ORM에서 N+1이 발생하고 있는지 확인해줘."
여기에 들어간 키워드: I/O Bound(Ch.3), N+1(Ch.13), ORM(Ch.13)
AI가 첫 번째 프롬프트를 받으면 Redis, CDN, gzip, 비동기화 등 온갖 방향을 제시한다. 두 번째 프롬프트를 받으면 DB 쿼리 분석에 집중한다. 범위를 좁혀주는 건 키워드다.
DB 문제 - "쿼리가 느리다"¶
Ch.13~16에서 다뤘던 키워드가 여기서 전부 쓰인다.
키워드를 모르는 프롬프트:
키워드를 아는 프롬프트:
"이 쿼리의 EXPLAIN 결과를 보니 type이 ALL이고 rows가 50만이다.
Full Table Scan이 발생하고 있다.
user_id와 created_at에 Composite Index를 거는 게 맞는지,
컬럼 순서는 어떻게 해야 하는지 알려줘."
여기에 들어간 키워드: EXPLAIN(Ch.11), Full Table Scan(Ch.11), Composite Index(Ch.14)
"DB가 느리다"에 대해 AI는 캐시를 붙이라고 할 수도 있고, 서버를 늘리라고 할 수도 있다. Ch.14에서 봤듯이, 인덱스를 안 걸어놓고 Redis를 설치하는 건 원인을 안 고치고 증상만 가리는 거다.
동시성 문제 - "간헐적으로 에러가 난다"¶
"간헐적"이라는 단어가 나오면 동시성을 의심해야 한다. Ch.5에서 다뤘다.
키워드를 모르는 프롬프트:
키워드를 아는 프롬프트:
"재고 차감 로직에 Race Condition이 있는 것 같다.
read-modify-write 패턴인데 Critical Section에 Lock이 없다.
DB 레벨에서 SELECT FOR UPDATE로 Pessimistic Lock을 걸거나,
version 컬럼으로 Optimistic Lock을 거는 게 나을 것 같은데,
동시 주문이 초당 100건 정도인 상황에서 어느 쪽이 적합한지 분석해줘."
여기에 들어간 키워드: Race Condition(Ch.5), Critical Section(Ch.5), Pessimistic Lock / Optimistic Lock(Ch.15)
첫 번째 프롬프트에 대해 AI는 if stock > 0 조건문을 추가하라고 할 수 있다. 하지만 그건 Race Condition을 해결하지 못한다. "재고 확인"과 "재고 차감" 사이에 다른 스레드가 끼어들면 똑같은 문제가 발생한다. Ch.5에서 본 TOCTOU(Time of Check to Time of Use) 문제다.
캐시 문제 - "붙였는데 오히려 느려졌다"¶
Ch.17~18에서 다뤘던 키워드가 여기서 쓰인다.
키워드를 모르는 프롬프트:
키워드를 아는 프롬프트:
"Cache Stampede가 의심된다. TTL이 60초인데,
인기 상품의 캐시가 동시에 만료되면서 수백 건의 DB 쿼리가 동시에 나가는 것 같다.
TTL Jitter를 적용하거나, 만료 전에 비동기로 캐시를 갱신하는 패턴을 적용해줘.
Mutex Lock 방식은 단일 서버에서는 되지만 다중 서버에서는 분산 락이 필요하니까,
서버가 3대인 상황에서 적합한 방법을 추천해줘."
여기에 들어간 키워드: Cache Stampede(Ch.9, Ch.17), TTL(Ch.17), Mutex(Ch.5)
첫 번째 프롬프트도 나쁘지 않다. AI가 Cache Stampede를 추론해줄 수도 있다. 하지만 두 번째 프롬프트는 이미 원인을 짚었기 때문에, AI가 해결책에만 집중할 수 있다. 진단은 사람이, 처방은 AI가. 이 순서가 맞다.
보안 문제 - "취약점이 있을까"¶
Ch.23에서 다뤘던 키워드가 여기서 쓰인다.
키워드를 모르는 프롬프트:
키워드를 아는 프롬프트:
"이 코드에서 SQL Injection 취약점이 있는지 확인해줘.
사용자 입력이 f-string으로 직접 쿼리에 들어가는 부분이 있으면
Parameterized Query로 바꿔줘.
그리고 CORS 설정에서 allow_origins가 '*'인데,
프로덕션에서는 특정 도메인만 허용하도록 바꿔줘."
여기에 들어간 키워드: SQL Injection(Ch.23), Parameterized Query(Ch.23), CORS(Ch.23)
"보안 문제 없는지 확인해줘"는 범위가 너무 넓다. AI가 OWASP Top 10 전체를 나열할 수도 있고, 코드와 무관한 일반론을 늘어놓을 수도 있다. 키워드로 범위를 좁혀주면 AI가 해당 취약점에 집중해서 코드를 검토한다.
아키텍처 문제 - "코드가 복잡하다"¶
Ch.20~22에서 다뤘던 키워드가 여기서 쓰인다.
키워드를 모르는 프롬프트:
키워드를 아는 프롬프트:
"이 Service 클래스가 SRP를 위반하고 있다.
주문 생성, 결제 처리, 재고 차감, 알림 발송을 전부 하나의 클래스에서 한다.
각각의 책임을 분리하고, DIP를 적용해서 추상에 의존하도록 리팩토링해줘.
단, YAGNI 원칙을 지켜서 지금 필요한 추상화만 해줘."
여기에 들어간 키워드: SRP(Ch.20), DIP(Ch.20), DI(Ch.20), YAGNI(Ch.9)
"정리해줘"라고 하면 AI는 주석을 달거나, 함수를 쪼개거나, 디자인 패턴을 과도하게 적용할 수 있다. Ch.9에서 봤듯이 AI는 불필요한 추상화를 만드는 경향이 있다. YAGNI를 같이 언급해야 적절한 수준의 리팩토링이 나온다.
Do/Don't 패턴 종합¶
Ch.7에서 4가지 패턴(원인 기반, 제약 조건, 방향 지정, 진단 결과 포함)을 다뤘다. 24챕터를 거친 지금, 이 패턴을 전체 레이어에 적용할 수 있다.
| Don't | Do | 관련 키워드 |
|---|---|---|
| "느려" | "I/O Bound다. DB 쿼리 수를 줄여줘" | CPU/I/O Bound (Ch.3), N+1 (Ch.13) |
| "DB가 느려" | "EXPLAIN 결과가 Full Table Scan이다. 인덱스 걸어줘" | EXPLAIN (Ch.11), Index (Ch.14) |
| "가끔 에러 나" | "Race Condition이다. Critical Section에 Lock 걸어줘" | Race Condition (Ch.5), Lock (Ch.5, Ch.15) |
| "캐시가 이상해" | "Cache Stampede다. TTL Jitter 적용해줘" | Cache Stampede (Ch.17), TTL (Ch.17) |
| "보안 확인해줘" | "SQL Injection 취약점 확인, Parameterized Query로 바꿔줘" | SQL Injection (Ch.23) |
| "코드 정리해줘" | "SRP 위반이다. 책임 분리하되 YAGNI 지켜줘" | SRP (Ch.20), YAGNI (Ch.9) |
| "배포가 안 돼" | "Docker 이미지 빌드는 되는데 K8s Pod가 CrashLoopBackOff다" | Container (Ch.22), K8s (Ch.22) |
| "메모리 문제인 것 같아" | "RSS가 계속 증가한다. Heap에서 해제 안 되는 객체를 tracemalloc으로 추적해줘" | RSS (Ch.4), Heap (Ch.4), Virtual Memory (Ch.4) |
왼쪽 칸은 증상이다. 오른쪽 칸은 원인이다. AI에게 증상을 던지면 AI가 추측을 한다. AI에게 원인을 던지면 AI가 해결책을 준다. 추측과 해결책의 차이는 크다.
3단계 프롬프트 전략¶
Ch.7에서 "키워드를 모르면 키워드부터 물어봐라"라고 했다. 이 전략을 공식화하면 이렇다.
1단계: 증상 -> 키워드 (진단)
"EXPLAIN 결과가 이건데, 이 현상의 CS 용어가 뭔가?"
-> "Full Table Scan입니다"
2단계: 키워드 -> 해결 방향 (방향 잡기)
"Full Table Scan을 해결하려면?"
-> "인덱스를 추가하세요. WHERE 절의 컬럼부터."
3단계: 해결 방향 -> 구체적 코드 (실행)
"user_id와 created_at에 Composite Index를 거는 migration 만들어줘.
Cardinality가 높은 컬럼을 앞에 두고."
-> 정확한 코드
1단계에서 키워드를 획득한다. 2단계에서 방향을 잡는다. 3단계에서 AI가 코드를 만든다. 각 단계의 출력이 다음 단계의 입력이 된다.
처음부터 3단계로 갈 수 있으면 가장 좋다. 하지만 키워드를 모르겠으면 1단계부터 시작해도 된다. 중요한 건 "한 번에 해결하려고 하지 말고, 키워드를 학습하면서 프롬프트를 좁혀가는 것"이다.
AI 검증 체크리스트 (종합)¶
Ch.9에서 CS 관점 코드 리뷰 체크리스트를 만들었다. 24챕터를 거친 지금, 더 구체적인 체크리스트를 만들 수 있다.
AI가 코드를 만들어줬다. 뭘 확인해야 하는가?
| 점검 항목 | 확인할 키워드 | 참고 챕터 |
|---|---|---|
| 이 작업은 CPU Bound인가 I/O Bound인가? | async가 적절한가, ProcessPool이 필요한가 | Ch.3 |
| 로그 출력이 과도하지 않은가? | System Call 비용, 버퍼링 | Ch.2 |
| ORM 쿼리가 몇 번 나가는가? | N+1, Lazy/Eager Loading | Ch.13 |
| 인덱스가 걸려 있는가? | EXPLAIN, Full Table Scan | Ch.11, Ch.14 |
| Transaction 범위가 적절한가? | ACID, Isolation Level | Ch.15 |
| 동시 요청에서 안전한가? | Race Condition, Lock | Ch.5, Ch.15 |
| 캐시 전략이 적절한가? | Cache Stampede, TTL, Invalidation | Ch.17, Ch.18 |
| 보안 취약점이 있는가? | SQL Injection, XSS, CSRF | Ch.23 |
| 불필요한 추상화가 있는가? | YAGNI, SRP | Ch.9, Ch.20 |
| 테스트가 실제 동작을 검증하는가? | Mock 과다, Integration Test | Ch.21 |
| 메모리 사용량이 적절한가? | Heap, RSS, OOM | Ch.4 |
| Connection을 제대로 반환하는가? | Connection Pool, with문 | Ch.6 |
이 체크리스트를 AI 프롬프트에 넣을 수도 있다.
"이 코드를 리뷰해줘. 특히 다음을 확인해줘:
1. N+1 쿼리가 발생하는 곳
2. Race Condition이 가능한 Critical Section
3. SQL Injection 취약점
4. 불필요한 추상화 (YAGNI 위반)"
AI에게 "리뷰해줘"라고만 하면 코드 스타일이나 변수명 같은 표면적인 것만 본다. 키워드로 관점을 지정하면 AI가 해당 관점에서 깊이 있게 분석한다.
결론¶
Ch.7에서 이런 말을 했다.
24챕터를 거친 지금, 한 문장을 더 붙일 수 있다.
AI는 도구다. CS 키워드는 그 도구를 제어하는 방법이다. 키워드를 모르면 AI에게 증상만 전달한다. 키워드를 알면 AI에게 원인을 전달한다. 이 차이가 "AI를 쓸 줄 아는 개발자"와 "AI에게 끌려다니는 개발자"를 가른다.