Skip to Content

테스트·재현·원인 분석

실습복습
관련 기초 개념

개요

실패 재현에서 회귀 방지까지 검증 증거를 만든다.

먼저 코드 읽기·리뷰·변경 범위, 평가셋·정답·누출 통제의 핵심 개념을 확인하세요.

핵심 개요

디버깅은 관찰한 실패와 그 원인에 대한 가설을 구분하는 과정입니다. 먼저 최소 재현을 만들고, 입력·상태·호출 순서에서 가설을 지지하거나 반박할 증거를 모읍니다.

좋은 테스트는 구현의 줄을 따라 복사하지 않고 사용자에게 보장할 동작을 검사합니다. 현재 결함에서 실패하고 수정 후 성공해야 원인과 결과를 연결하기 쉽습니다.

필요한 용어

  • 최소 재현: 불필요한 조건을 줄여 같은 실패를 만드는 입력과 절차
  • 회귀 테스트: 발견한 실패가 다시 생기지 않도록 동작을 확인하는 검사

작동 과정

  1. 예상·실제 결과와 환경을 고정합니다.
  2. 가설별로 최소 입력·상태를 바꿔 재현합니다.
  3. 수정 전 실패·수정 후 성공과 인접 경계를 검사합니다.

풀이 예제

아래 입력과 기록은 직접 만든 교육용 가상 자료입니다.

입력·조건

기존 apply는 expected_revision을 받지만 검사하지 않습니다. A가 값 10/revision 2를 저장한 뒤 B의 오래된 제안 값 20이 들어옵니다.

판단·결과

기존 구현은 값 20으로 덮어써 정책을 위반합니다. 수정 구현은 revision 불일치로 거절하여 값 10/revision 2를 보존합니다. 아래 코드는 같은 사건 순서로 전후 동작을 검증합니다.

이렇게 판단한 이유

사용자가 기대하는 충돌 거절을 검사하므로 내부 코드의 모양이 바뀌어도 회귀 검증으로 쓸 수 있습니다.

로컬 실행 예제

실행 파일 받기

Python 3.12. python revision_regression.py

python revision_regression.py
"""Deterministic interleaving regression: stale expected revision must not overwrite."""
def buggy_apply(state, expected_revision, value):
    return {'revision':state['revision']+1, 'value':value}, 'ok'
def guarded_apply(state, expected_revision, value):
    if state['revision'] != expected_revision:
        return dict(state), 'conflict'
    return {'revision':state['revision']+1, 'value':value}, 'ok'
def scenario(apply, *, first='A'):
    state = {'revision':1,'value':0}
    values = {'A':10,'B':20}
    state,status = apply(state,1,values[first])
    assert status == 'ok'
    expected = dict(state)
    state,status = apply(state,1,values['B' if first=='A' else 'A'])
    return state == expected and status == 'conflict'
assert not scenario(buggy_apply)  # Reproduces lost-update behavior.
assert scenario(guarded_apply) and scenario(guarded_apply, first='B')
state,status = guarded_apply({'revision':2,'value':10},2,20)
assert state == {'revision':3,'value':20} and status == 'ok'  # Retry after reread.
print('PASS: old code reproduces failure; guard protects both orders; fresh-revision retry works')

기대 결과: 기존 결함 재현·수정 후 양쪽 순서·새 revision 재시도 검사

2026-10-21 로컬 환경에서 실행했습니다. 가상 자료·소형 CPU 예제의 동작 검사이며 실제 업무 모델의 품질·클라우드·GPU·Office 제품 연동 검증은 아닙니다.

흔한 실패와 복구

테스트가 통과했다는 이유로 재현하지 못한 운영 환경까지 해결됐다고 하지 않습니다. 검사 범위와 남은 조건을 구분합니다.

확인 문제

의미 있는 회귀 테스트의 핵심은?

  1. 결함 동작에서 실패하고 수정 뒤 기대 동작을 확인한다
  2. 수정한 코드 문자열이 있는지 확인한다
  3. 항상 참인 조건을 검사한다

풀이 기록 기능을 불러오는 중…

해설 보기

정답: A. 결함 동작에서 실패하고 수정 뒤 기대 동작을 확인한다

결함 동작에서 실패하고 수정 뒤 기대 동작을 확인한다 테스트가 통과했다는 이유로 재현하지 못한 운영 환경까지 해결됐다고 하지 않습니다. 검사 범위와 남은 조건을 구분합니다.

참고 자료

  1. Anthropic: Agent evaluations  — 과제·시도·실행 결과·평가자 검증.

자료 확인: 2026-10-21. 사례·문항·실습은 자체 제작했습니다. 외부 서비스 호출과 실제 모델 품질 측정은 학습자가 별도 환경에서 수행합니다.

직접 적용하기

교육용 가상 상황

초기 값 0, revision=1입니다. A와 B가 모두 revision=1을 읽고 A는 10, B는 20을 제안합니다. 정책은 기대 revision이 현재와 다르면 충돌로 거절하는 것입니다. A 적용 후 B가 오래된 revision으로 쓰는 순서에서 기존 구현과 수정 구현을 실행하세요. 역순·최신 revision 재시도 결과와 실제 협업에서 남는 제한도 기록하세요.

실패 재현에서 회귀 방지까지 검증 증거를 만든다. 판단 근거와 검증할 결과를 적으세요.

답안 저장 기능을 불러오는 중…

검증 기준과 해설 보기
  1. 기존 구현에서 오래된 제안이 값을 덮어쓰는 실패를 재현한다
  2. 양쪽 사건 순서에서 수정 후 conflict와 보존된 값을 확인한다
  3. 새 revision 재시도와 실제 협업·재접속·Undo의 남은 검사 범위를 구분한다

기존 구현에서 값 20/revision 3으로 덮어써 재현됩니다. 수정 구현은 A→B 순서에서 값 10/revision 2와 conflict, B→A에서는 값 20/revision 2와 conflict를 만듭니다. 다시 읽은 revision 2로 새 변경하면 revision 3으로 성공합니다. 이 예제는 결정적 사건 순서 검사이며 네트워크·재접속·실제 Undo 엔진 검증은 별도로 남깁니다.

복습하기

  1. 가설과 관찰은 어떻게 다른가요?
  2. 최소 재현이 필요한 이유는?
  3. 테스트 통과 뒤 무엇을 보고하나요?
답변 확인 기준
  1. 가설과 관찰은 어떻게 다른가요?

    추정 원인과 실제 확인된 결과의 차이입니다.

  2. 최소 재현이 필요한 이유는?

    어떤 조건이 실패를 만드는지 좁히기 위해서입니다.

  3. 테스트 통과 뒤 무엇을 보고하나요?

    검증한 동작·환경·남은 제한을 보고합니다.

← 이전 강의다음 강의 →학습 기록 →