AI 드리븐

지도 위치 : 3일차 · 신뢰와 운영 · 출발점 — 손 확인을 자동 확인으로 | 이전: 16차시 결제 연동 | 다음: 18차시 버전 관리와 강제 장치 키워드 : 믿을 수 있는 테스트의 조건, 형식만 갖춘 테스트 판별, 안전망 검증

이 차시를 다 읽으면

1. 자동 테스트를 유와 종차로 정의하고, 2일차의 손 확인과 무엇이 다른지 말할 수 있다.
2. 믿을 수 있는 테스트의 다섯 조건 을 대고, 첫째 조건("실패할 수 있다")이 왜 나머지의 전제인지 설명할 수 있다.
3. 형식만 갖춘 테스트 의 유형을 ⑧ 구문론 ↔ 의미론 축으로 설명할 수 있다.
4. 뮤테이션 발상 (일부러 망가뜨려 보기)으로 테스트를 테스트하는 순서를 말하고, 커버리지가 왜 "충분함"의 증거가 아닌지 설명할 수 있다.
5. 테스트의 세 층 (단위 · 통합 · E2E)을 구별하고, 클래스온 규칙을 어느 층에 둘지 정할 수 있다.
6. 테스트 코드를 읽지 않고 테스트 이름 목록 과 망가뜨려 보기 결과표 로 테스트를 검수할 수 있다.

---

0. 이 차시의 판별 축

이 차시가 답하는 질문은 하나입니다. 초록불은 무엇을 증명하는가? 앞에서 배운 인수 기준 (3차시)이 테스트 문장의 출처이고, 앞에서 배운 코드 · 동작 점검 (13차시)의 동적 검증을 사람 없이 매번 반복 하게 만드는 것이 테스트입니다. 그런데 AI는 "통과하는 테스트"를 만드는 데 아주 능숙합니다. 그래서 이 차시의 중심은 테스트를 쓰는 법이 아니라 축 1의 어느 쪽인지 판별하는 법 입니다.

---

1. 자동 테스트 — 무엇에 속하는가

1.1 정의

자동 테스트 — [동적 검증]인데, [ 코드로 적어 둔 기대를 명령 하나로 언제든 같은 방식으로 다시 확인한다 ]는 점에서 사람이 매번 손으로 해 보는 수동 확인과 구별된다.

단언 (assertion) — [테스트 코드의 한 줄]인데, [ 결과가 기대와 다르면 테스트를 실패시킨다 ]는 점에서 함수를 부르기만 하는 호출과 구별된다. 코드에서는 보통 expect(...)로 보입니다.

회귀 (regression) — [버그]인데, [ 전에 되던 기능이 새 변경 때문에 다시 안 되게 된 것 ]이라는 점에서 처음부터 없던 기능과 구별된다.

1.2 왜 3일차의 출발점인가

AI는 코드를 빨리, 자주 바꿉니다. 바꾸는 횟수가 많을수록 회귀 가 생길 자리도 많습니다. 테스트는 그 자리를 지키는 안전망입니다.

⚠️ 반대로, 형식만 갖춘 테스트는 잘못된 안심을 줍니다. "테스트 120개 통과"라는 보고를 믿고 내보냈는데 아무것도 확인하지 않는 테스트였다면, 테스트가 없을 때보다 나쁩니다. 없을 때는 적어도 불안해서 직접 확인했을 테니까요.

앞으로 다시 만납니다 — 18차시 커밋 검사, 19차시 CI 관문, 22차시 배포 후 검증이 모두 "테스트를 돌린다" 위에 섭니다. 테스트가 가짜면 그 위의 관문도 전부 가짜 입니다. 그래서 3일차는 테스트의 진위부터 따집니다.

1.3 반례 — 이건 자동 테스트가 아닙니다

---

2. ⭐ 믿을 수 있는 테스트의 조건

2.1 정의와 다섯 조건

믿을 수 있는 테스트 — [자동 테스트]인데, [ 지키려는 규칙이 깨지면 실제로 실패한다 ]는 점에서 실행되고 초록불도 뜨지만 규칙이 깨져도 그대로 통과하는 형식만 갖춘 테스트와 구별된다.

⭐ 첫째 조건이 나머지의 전제입니다. 결정적이고 독립적이고 읽히는 테스트라도, 실패할 수 없으면 아무것도 지키지 않습니다. 나머지 네 조건은 "실패했을 때 그 실패를 믿을 수 있는가"의 문제이고, 첫째 조건은 "실패라는 게 일어날 수 있는가"의 문제입니다.

2.2 인수 기준에서 테스트로

앞에서 배운 Given / When / Then 인수 기준 (3차시)이 테스트의 직접적인 출처입니다. 인수 기준 한 줄이 테스트 하나가 됩니다.

test("남은 자리가 0이면 예약은 409 SOLD_OUT을 받고 생성되지 않는다", async () => {
  // Given
  const session = await createSession({ capacity: 6, remaining: 0 });
  // When
  const res = await api.post("/reservations", { sessionId: session.id, headcount: 1 });
  // Then
  expect(res.status).toBe(409);
  expect(res.body.error.code).toBe("SOLD_OUT");
  expect(await countReservations(session.id)).toBe(0);
});

🔍 읽는 포인트 : 첫 줄 test("...") 안의 한국어 문장 이 이 테스트가 지키는 규칙입니다. 그 아래 expect가 세 줄 있다는 것(응답 숫자, 에러 이름, 실제로 예약이 0건인지 )만 알아보면 됩니다.

마지막 expect가 중요합니다. 응답이 409여도 DB에는 예약이 들어가 버리는 버그가 있을 수 있습니다. "응답만 보고 상태는 안 보는" 테스트는 절반만 지킵니다.

2.3 경계 — 형식만 갖춘 테스트 ↔ 믿을 수 있는 테스트

형식만 갖춘 테스트 — [자동 테스트]인데, [ 문법상 테스트이고 통과도 하지만, 규칙이 깨져도 실패하지 않는다 ]는 점에서 믿을 수 있는 테스트와 구별된다.

⚠️ 표의 위 네 줄이 똑같다는 점이 핵심입니다. 둘은 실행 결과로는 구별되지 않습니다. 코드를 일부러 틀리게 만들어 볼 때만 갈립니다. 이것이 ⑧ 구문론 ↔ 의미론 축이 3일차에서 다시 나타나는 모습입니다. 맞춤법 검사기가 내용의 진위를 모르듯, 초록불은 테스트의 진위를 모릅니다.

---

3. 형식만 갖춘 테스트와 안전망 검증

3.1 AI가 만드는 일곱 유형

3.2 가장 위험한 유형 — 테스트를 고쳐서 통과

앞의 여섯 유형은 처음부터 약한 테스트입니다. 마지막 유형은 멀쩡하던 테스트를 약하게 만드는 것 이라 더 위험합니다. 에이전트는 "테스트를 통과시켜라"라는 목표를 받으면, 코드를 고치는 것과 테스트를 고치는 것 중 쉬운 쪽 을 고를 수 있습니다.

그래서 지침 파일과 테스트 역할(QA) 정의에 이렇게 적어 둡니다.

테스트가 실패하면 테스트가 아니라 코드를 고친다.
테스트를 수정해야 한다고 판단되면, 이유를 보고하고 사람의 승인을 받는다.

🔍 읽는 포인트 : 두 문장 모두 부탁 입니다(README 6장 사다리의 아래 칸). 그래서 실제 방어는 사람이 하는 감시 — "기능 변경 PR에 테스트 파일이 같이 바뀌었는가" — 로 보강합니다(README 9.4 위험 신호).

앞으로 다시 만납니다 — 19차시에서 같은 문제가 CI에서 다시 나옵니다. 에이전트가 CI를 통과시키려고 검사 단계를 지우는 형태로요. 20차시에서는 이것을 CODEOWNERS 라는 강제 장치로 막습니다.

3.3 ⭐ 안전망 검증 — 테스트를 테스트하기

뮤테이션 발상 — [테스트 검증 방법]인데, [ 코드를 일부러 조금 틀리게 바꿔(돌연변이를 넣어) 테스트가 그걸 잡는지 본다 ]는 점에서 테스트를 그냥 다시 돌려 보는 것과 구별된다.

2.3절에서 봤듯 두 종류의 테스트는 코드를 망가뜨릴 때만 갈립니다. 그래서 망가뜨려 봅니다.

1. 서버의 금액 검증 줄을 잠시 주석 처리한다 (돌연변이)
2. 테스트를 돌린다
3. 금액 위조 테스트가 실패하면  → 믿을 수 있는 테스트 (돌연변이를 "잡았다")
   여전히 모두 통과하면        → 그 규칙을 지키는 테스트가 없다 (돌연변이가 "살아남았다")
4. 원래대로 되돌린다

🔍 읽는 포인트 : 3번의 두 갈래만 보면 됩니다. "살아남았다"가 나온 규칙이 안전망에 구멍이 난 곳 입니다.

이 작업을 자동으로 수백 번 해 주는 것이 뮤테이션 테스트 도구 입니다(예: JavaScript의 Stryker, Python의 mutmut — 사용법과 지원 범위는 공식 문서 확인). 하지만 손으로 핵심 규칙 몇 개만 골라 해도 효과가 큽니다. 클래스온이라면 5절의 다섯 규칙이면 충분합니다.

3.4 커버리지의 함정

커버리지 (coverage) — [테스트 지표]인데, [ 테스트가 실행하면서 지나간 코드의 비율 ]이라는 점에서 테스트가 실제로 확인한 규칙의 비율과 구별된다.

⚠️ "확인 없음" 유형의 테스트도 커버리지는 100%까지 올립니다. 그래서 커버리지는 "테스트가 안 닿은 곳"을 찾는 데만 쓰고, "충분하다"의 증거로는 쓰지 않습니다. 커버리지 100%인데 버그가 있을 수 있는 이유가 이것입니다.

💡 비유는 마지막에 — 형식만 갖춘 테스트는 천장에 달려만 있는 화재경보기 입니다. 달려 있다는 것(형식)과 연기에 울린다는 것(뜻)은 다릅니다. 뮤테이션 발상은 연기를 피워 경보기를 시험하는 것 이고, 커버리지는 경보기가 몇 개 방에 달려 있는지 세는 것 입니다.

---

4. 테스트의 층

        /\        E2E: 실제 브라우저로 예약 ~ 결제 흐름 (적게)
       /  \
      /----\      통합: API + 실제 DB (클래스온 핵심 규칙 대부분)
     /      \
    /--------\    단위: 금액 계산, 취소 기한 판단 같은 계산 (많이, 빠르게)

🔍 읽는 포인트 : 위로 갈수록 좁아진다 는 모양만 기억하면 됩니다. 위층일수록 느리고 비싸서 적게 둡니다.

⚠️ 클래스온의 핵심 규칙(자리 차감, 동시 예약, 금액 검증)은 대부분 DB가 있어야 의미가 있는 규칙 입니다. 단위 테스트에서 DB를 가짜로 바꾸면 "대상까지 가짜" 유형이 되기 쉽습니다. 그래서 클래스온에서는 통합 테스트가 몸통 입니다.

앞으로 다시 만납니다 — 꼭대기의 E2E는 22차시에서 실제 배포 주소를 대상으로 돌립니다. 통합 테스트용 DB를 매번 새로 띄우는 일은 19차시의 CI가 맡습니다.

---

5. 클래스온에 적용하면

반드시 테스트로 지킬 규칙(인수 기준에서 추림)과, 각 규칙을 확인할 돌연변이 입니다.

누가 테스트를 쓰는가 — 축 4의 문제입니다. 구현 에이전트가 자기 코드의 테스트를 쓰고 스스로 통과 판정하면, 같은 맹점을 공유합니다(README 6장 문장 2). 최소한 테스트 목록(이름)은 인수 기준에서 독립적으로 나와야 합니다. 앞에서 배운 역할 분리 (5, 7차시)대로 QA 역할에게 "인수 기준 → 테스트 이름 목록"을 먼저 만들게 하고, 구현은 그 목록을 통과시키는 순서가 안전합니다.

---

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

테스트 코드는 못 읽어도 테스트 이름은 읽을 수 있습니다. 좋은 테스트 이름은 한국어 문장입니다. 이 실습의 검수는 전부 이름 목록 과 결과표 로 합니다.

지시

[1단계 — 이름 대조]
모든 테스트의 이름을 목록으로 뽑아서 docs/requirements.md의 인수 기준과 짝지어줘.
보고 형식:
| 인수 기준 | 짝이 되는 테스트 이름 | 층(단위/통합/E2E) |
"테스트가 없는 인수 기준"과 "인수 기준에 없는 테스트"는 표 아래에 따로 목록으로.

[2단계 — 망가뜨려 보기]
아래 규칙마다, 그 규칙을 지키는 코드를 잠시 망가뜨리고 테스트를 돌려서 실패하는지 확인해줘.
- 자리 없으면 예약 불가 / 동시 예약 1건 / 금액은 서버 계산 / 남의 예약 접근 불가 / 중복 결제 무시
보고 형식:
| 규칙 | 망가뜨린 내용(한 줄) | 실패한 테스트 이름 | 결과(잡음/못 잡음) |
각 규칙마다 테스트 실행 출력 원문(통과·실패 개수가 나오는 마지막 부분)을 붙여.
규칙 하나 확인이 끝날 때마다 반드시 원래대로 되돌리고, 마지막에 git status 출력 원문을 붙여.
테스트 파일은 어떤 경우에도 수정하지 마. "못 잡음"이 나와도 고치지 말고 보고만 해.

🔍 읽는 포인트 : 마지막 세 줄이 가드레일입니다. 되돌리기 확인(git status) , 테스트 파일 수정 금지 , 고치지 말고 보고만 . 마지막 줄이 없으면 에이전트가 "못 잡음"을 보고 테스트를 덧붙이거나 고쳐서 표를 "잡음"으로 채울 수 있습니다.

(git status — 변경 이력을 기록하는 도구인 Git에게 "지금 바뀐 파일이 있나"를 묻는 명령입니다. Git은 18차시에서 자세히 다룹니다. 바뀐 파일이 없다고 나와야 정상입니다.)

받을 증거

• 1단계: 인수 기준 ↔ 테스트 이름 짝 표, 그리고 짝 없는 항목 두 목록
• 2단계: 규칙별 결과표 + 망가뜨린 상태에서의 테스트 실행 출력 원문 (실패 개수가 0이 아니어야 "잡음")
• 마지막 git status 출력 원문 — "바뀐 파일 없음"
• 전체 테스트를 두 번 연속 돌린 출력 원문 — 두 번의 결과가 같아야 함(결정적 조건)

내가 직접 확인할 것

💡 이후 모든 작업에서 하나만 습관으로 남기세요. 기능을 고쳤는데 테스트 파일이 함께 바뀌었다면 , "어떤 테스트의 기대 결과를 바꿨고, 원래 기대가 왜 틀렸는지"를 묻습니다. 설명이 납득되지 않으면 승인하지 않습니다.

---

부록 A. 스스로 확인하기

부록 B. 자주 하는 실수

부록 C. NotebookLM 복습 프롬프트

이 17차시 노트만 근거로 5문제를 내줘. 비전공자 기준으로.
"형식만 갖춘 테스트와 믿을 수 있는 테스트가 실행 결과로는 구별되지 않는 이유", "뮤테이션 발상", "커버리지의 함정"은 반드시 포함해줘.
답은 내가 답한 다음에 채점하고, 틀린 이유를 노트의 절 번호를 근거로 설명해줘.