AI가 쓴 코드를
믿는 법 ⚖️

무섭게 틀리지 않고, 그럴듯하게 틀립니다 — 방향키로 진행하세요 ▸

def is_expired(token):
    """토큰 만료 여부를 반환"""
    now = datetime.now()
    return now > token.expires_at

# 리뷰어: "깔끔하네요 👍" · 내 PC에서 테스트 통과

미묘하게 틀리는 단골 패턴 도감

사람은 기계 출력을 과신하도록 생겨먹었습니다

"생성 10분" 뒤에 숨은 "디버깅 3일"

체감 속도는 곱셈입니다 — 이 시리즈, 곱셈 좋아합니다 ▸

검증을 설계한다 = 테스트·리뷰·CI를 생성보다 먼저 준비한다.
숫자는 직관을 위한 예시입니다 — 핵심은 검증 항이 0에 가까우면 전체가 무너진다는 것.

다섯 개의 도구 — 사다리 · 테스트 · 리뷰 · 평가 · 다이얼

검증의 사다리 — 올라갈수록 사람은 편해집니다

눈으로만 읽는 검증이 가장 비싸고 가장 약합니다 — 사다리를 올라간 만큼 바이브 코딩의 속도가 살아납니다.

보고받지 말고 증거를 받으세요

# ❌ 말로 하는 완료 보고
🤖 "수정했습니다. 이제 모든 테스트가
   통과합니다. 완벽하게 동작해요!"

# 실행해 보지도 않고 낙관하는 경우,
# 정말로 있습니다

# ✅ 증거를 요구하는 요청
"pytest를 직접 실행하고 출력 전체를 보여줘.
 실패하면 실패 로그 원문 그대로."
"수정된 화면을 스크린샷으로 찍어서 보여줘."
"마지막 명령의 exit code도 함께."

사다리 꼭대기 — 사람 없이 도는 검증

한 번 세팅해두면 이후의 모든 커밋이 공짜로 검증됩니다 — 세팅 자체도 에이전트에게 시키면 됩니다.

테스트 = 실행 가능한 스펙

테스트 먼저 시키기 — 에이전트와 TDD

"먼저 이 기능의 실패하는 테스트부터 작성해줘. 구현은 아직 하지 마.
 내가 테스트를 확인하면, 그때 통과할 때까지 구현해줘.
 테스트 코드는 수정하지 말고."

에이전트 루프(실행→관찰→수정)에 명확한 목표 함수가 생깁니다 — 끝났는지를 사람이 아니라 기계가 판정.

테스트를 통과 못 하면 — 테스트를 고칩니다 — 방향키 ▸

# tests/test_yield.py — 사람이 확정한 테스트
def test_yield_calc():
    assert calc_yield(lot42) == 98.2

# 🤖 조용히 이렇게 바꿔놨습니다
def test_yield_calc():
    result = calc_yield(lot42)
    assert result is not None  # 통과!

방어 3종 — 채점 기준은 사람이 지킵니다

"테스트도 짜줘"로는 해피 패스만 나옵니다

# ❌ 두루뭉술한 요청
"테스트도 만들어줘."

# → 성공 케이스 3개. 끝.
# 자기가 짠 코드에 맞춘,
# 절대 실패하지 않는 테스트

# ✅ 케이스를 명시하는 요청
"test_yield_calc에 다음을 포함해줘:
 - 경계값: 수율 0%·100%, wafer 0장
 - 에러 경로: 측정값 누락·타입 오류 → 예외 확인
 - 회귀: 이번에 고친 중복 lot 버그 재현 케이스
 실패 메시지는 원인을 알 수 있게 써줘."

S3의 '단골 패턴 도감'이 그대로 테스트 케이스 목록이 됩니다.

같은 세션에게 "네 코드 비판해봐"는 왜 약한가

리뷰의 힘은 거리에서 나옵니다 — 쓴 사람과 보는 눈이 멀수록 잘 보입니다.

사람은 기계가 못 보는 것만 봅니다

300줄짜리 PR 하나보다 30줄짜리 PR 열 개가 안전합니다. (github 세미나의 '작은 커밋'과 같은 이야기)

한 번 쓰고 버릴 코드 vs 매번 도는 AI

검증 강도는 작업의 무게에 맞춥니다

전부 풀세트로 검증하면 그것도 낭비입니다 — 다이얼을 돌릴 줄 아는 게 실력.

AI 코드, 커밋 전 체크리스트

더 깊이 보기

질문을 남겨주세요 — 돌아간다 ≠ 맞는다 ⚖️