AI 드리븐

지도 위치 : 2일차 · 구현과 검증 · 검증 | 이전: 12차시 데이터 관리 역할 | 다음: 14차시 검증 ② 보안 점검과 차단 키워드 : 코드 검토와 동작 검증의 분리, 경계·실패 상황, 동시 요청 문제

이 차시를 다 읽으면

1. 정적 검증(코드 검토) 과 동적 검증(동작 검증) 을 구별하고, 각각이 잘 찾는 문제와 놓치는 문제를 말할 수 있다.
2. 검증 역할 두 개(리뷰어 · QA)의 권한 차이 를 만드는 자 ↔ 검증하는 자 축으로 설명할 수 있다.
3. 인원 · 날짜 · 남은 자리에 대한 경계값 목록 을 직접 쓸 수 있다.
4. 경쟁 상태 를 유와 종차로 정의하고, "조회 → 판단 → 저장" 코드가 동시 요청에서 실패하는 과정을 그림으로 설명할 수 있다.
5. 경쟁 상태의 해결책 세 가지를 주 방어 / 마지막 방어 로 나누고, 동시성 시험 결과를 숫자 두 개 로 판정할 수 있다.

---

0. 이 차시의 판별 축

이 차시가 답하는 질문은 "AI가 만든 코드의 버그는 어디에 숨는가, 그리고 누가 어떻게 찾는가" 입니다. AI가 만든 코드는 정상 경로에서는 거의 항상 동작 합니다. 데모에서는 문제가 보이지 않습니다. 실제 사고는 0명, 최댓값, 네트워크 끊김, 두 사람이 동시에 누르는 순간(축 3 · 4의 오른쪽)에 납니다. 앞에서 배운 "만드는 자와 검증하는 자의 분리"(7차시)를 이번에는 화면이 아니라 코드에 적용합니다.

---

1. 정적 검증과 동적 검증

1.1 정의와 경계

정적 검증 (코드 검토) — [검증 방법]인데, [ 코드를 실행하지 않고 읽어서 판단한다 ]는 점에서 실제로 돌려 보는 동적 검증과 구별된다.

동적 검증 (동작 검증) — [검증 방법]인데, [ 실제로 실행해 나온 결과로 판단한다 ]는 점에서 읽어서 판단하는 정적 검증과 구별된다.

둘 다 필요합니다. 코드 검토만 하면 "논리상 맞아 보이는" 버그를 놓치고, 동작 검증만 하면 시험하지 않은 경로를 놓칩니다.

1.2 반례 — 이건 검증이 아닙니다

💡 코드를 읽지 않는 사람에게 이 표의 의미 — 두 검증 중 동작 검증은 내가 직접 할 수 있습니다. 코드 검토는 리뷰 역할에게 맡기고, 내 시간은 동작 검증과 그 결과 숫자를 보는 데 씁니다.

---

2. 검증하는 자를 분리하기

앞에서 배운 하위 에이전트(2차시)와 역할 정의(5차시)로 검증 역할 둘을 만듭니다. 핵심은 권한(tools) 입니다.

# .claude/agents/code-reviewer.md
tools: Read, Grep, Glob
점검: 명세 일치, 입력 검증, 인가(본인 데이터만), 트랜잭션 범위, 에러 형식,
      조회-판단-저장 패턴
보고: [심각도 | 파일:줄 | 문제 | 사용자에게 생기는 피해 한 줄]

# .claude/agents/qa.md
tools: Read, Bash, Grep, Glob   (앱 코드 수정 불가, tests/ 폴더만 작성)
시험: 정상 1 + 경계값 + 실패 상황 + 동시 요청 20개
보고: [시험한 경우 | 기대 결과 | 실제 결과 | 재현 명령]

🔍 읽는 포인트 : tools: 줄에 Write · Edit가 없다 = 코드를 고칠 수 없다. 리뷰어는 읽기만, QA는 실행까지만 합니다.

---

3. 경계와 실패

3.1 경계값 — 값의 끝자락

⭐ 이 표는 코드 지식이 아니라 서비스에 대한 이해 에서 나옵니다. "인원은 몇 명까지?", "취소는 언제까지?"를 정한 사람은 나(3차시의 인수 기준)입니다. 그래서 경계값 표는 내가 직접 쓰고, 시험은 AI에게 시킵니다.

3.2 실패 상황 — "이게 실패하면?"

---

4. ⭐ 경쟁 상태 — 동시 요청 문제

4.1 정의와 그림

경쟁 상태 (Race Condition) — [동시성 버그]인데, [ 여러 요청이 같은 데이터를 동시에 읽고 바꿀 때, 실행 순서가 겹치는 방식에 따라 결과가 틀어진다 ]는 점에서 요청 하나만으로 재현되는 일반 버그와 구별된다.

남은 자리: 1

  사용자 A                          사용자 B
  ① 남은 자리 조회 → 1                ① 남은 자리 조회 → 1
  ② 1 > 0 이니 예약 가능              ② 1 > 0 이니 예약 가능
  ③ 남은 자리 = 0 저장, 예약 생성      ③ 남은 자리 = 0 저장, 예약 생성

결과: 자리 1개에 예약 2개 (초과 예약)

🔍 읽는 포인트 : A의 ①과 ③ 사이에 B의 ①이 끼어든 것이 전부입니다. 각자의 코드는 혼자서는 완벽합니다.

AI가 흔히 만드는 "조회 → 판단 → 저장" 코드는 혼자 시험할 때 완벽하게 동작합니다. 그래서 일부러 동시에 요청을 보내 봐야 드러납니다(0절 축 4).

4.2 반례 — 이건 경쟁 상태가 아닙니다

4.3 해결책 — 주 방어와 마지막 방어

UPDATE sessions SET remaining = remaining - 1
WHERE id = $1 AND remaining >= 1;
-- 바뀐 행이 0개면 "자리 없음" → 409 SOLD_OUT

🔍 읽는 포인트 : WHERE ... remaining >= 1 — "자리가 있으면 줄여라"를 한 문장으로 말합니다. 조회와 저장 사이의 틈(4.1의 그림)이 사라집니다.

💡 비유는 마지막에 — 공연장 매표소 두 곳이 같은 좌석표를 각자 장부로 확인하고 팔면 한 좌석이 두 번 팔립니다. 해결은 중앙 전산 한 곳에서 "비어 있으면 팔림 처리"를 한 번에 하는 것입니다.

---

5. 동시성 시험

# 남은 자리 1인 회차에 20개 요청을 동시에 보냄
for i in $(seq 1 20); do
  curl -s -o /dev/null -w "%{http_code}\n" -X POST localhost:4000/reservations ... &
done; wait
# 기대: 201이 정확히 1개, 나머지는 409
# 그리고 DB에서 해당 회차 예약 수가 정확히 1인지 확인

🔍 읽는 포인트 : 끝의 &가 "기다리지 않고 동시에" 보내는 표시입니다. 기대 줄의 숫자 두 개 만 보면 됩니다.

⭐ 판정은 숫자 두 개 로 합니다.

둘 중 하나라도 2 이상이면 경쟁 상태가 있는 것입니다. ①은 1인데 ②가 2라면 응답과 실제 데이터가 어긋난 더 나쁜 경우입니다.

앞으로 다시 만납니다 — 이 동시성 시험은 17차시에서 자동 테스트로 옮겨져 변경 때마다 다시 돌고, 19차시의 자동 검사 관문에서 통과 조건이 됩니다.

---

6. 클래스온에 적용하면

---

7. 실습 — 맡기고 검수하기

지시

qa 역할로 진행해줘. 앱 코드는 수정하지 마.
1. 남은 자리 1인 회차를 만들고, 예약 요청 20개를 동시에 보내.
   결과로 ① 201 응답 개수 ② DB에 실제로 생긴 그 회차의 예약 개수, 이 두 숫자를 먼저 보여줘.
2. 아래 경계값 표대로 시험하고 [입력 | 기대 | 실제 응답 | 통과?] 표로 보고해줘.
   (내가 쓴 경계값 표를 여기 붙임)
3. DB를 멈춘 상태에서 예약 요청을 보내고 응답 원문을 보여줘.
모든 시험의 재현 명령과 실행 출력 원문을 붙여줘. 실패한 것이 있으면 고치지 말고 보고만 해.

(별도로) code-reviewer 역할로 POST /reservations를 검토하고,
지적을 [사용자에게 실제 피해 | 나중에 고쳐도 됨]으로 나눠 보고해줘.

받을 증거

• 동시성 시험의 숫자 두 개 와 실행 출력 원문
• 경계값 결과 표와 재현 명령
• DB 중단 시 응답 원문
• 리뷰 지적을 피해 기준으로 나눈 표

내가 직접 확인할 것

---

부록 A. 스스로 확인하기

부록 B. 자주 하는 실수

부록 C. NotebookLM 복습 프롬프트

이 13차시 노트만 근거로 6문제를 내줘. 비전공자 기준으로.
"정적 검증과 동적 검증", "검증자를 분리하는 권한 설계", "경쟁 상태와 중복 요청의 차이", "동시성 시험의 숫자 두 개"는 반드시 포함해줘.
답은 내가 답한 다음에 채점하고, 틀린 이유를 노트의 절 번호를 근거로 설명해줘.