
AI가 코드와 테스트를 함께 만들고 “모두 통과했습니다”라고 보고하면 안심하기 쉽습니다. 하지만 통과한 테스트가 요구사항의 중요한 부분을 묻지 않았다면, 틀린 구현도 초록색 결과를 받을 수 있습니다. 통과율을 보기 전에 무엇을 정답으로 정했는지 확인해야 하는 이유입니다.
테스트를 많이 쓰는 것과 제대로 묻는 것은 다릅니다
Dan Luu의 에이전트 테스트·검증 실험은 에이전트에게 검증 기법을 사용하도록 지시했을 때 구현의 정확성이 어떻게 달라지는지 살펴봅니다. 특정 과제에서는 테스트 수가 늘어도 정확성이 개선되지 않았고, 중요한 동작을 검사하지 않거나 기대 동작을 잘못 정하는 문제가 관찰됐습니다. 이를 모든 AI 도구의 실패율이나 테스트 무용론으로 일반화할 수는 없습니다.
아래는 그 실험을 재현한 결과가 아닙니다. 문제를 쉽게 설명하기 위해 이 글에서 직접 구성하고 Python으로 실행한 작은 예제입니다. AI 모델 간 성능 비교도 아닙니다.
요구사항 한 줄부터 독립적으로 정합니다
가상의 기능은 “문자열 목록에서 중복을 없애되, 처음 등장한 순서를 유지한다”입니다. 입력은 문자열 목록으로 제한합니다. 대소문자 변환이나 공백 제거는 하지 않습니다.
예를 들어 `[“B”, “A”, “B”]`의 정답은 `[“B”, “A”]`입니다. 알파벳순으로 정렬한 `[“A”, “B”]`는 중복 제거에는 성공했지만 순서 유지 조건을 어겼습니다. 이 정답은 실행 결과를 보고 복사하는 대신 요구사항에서 먼저 결정해야 합니다.
틀린 구현도 통과하는 두 개의 테스트
세 가지 함수를 비교했습니다. 첫 번째는 입력을 그대로 돌려주고, 두 번째는 중복을 없앤 뒤 정렬합니다. 세 번째는 처음 등장한 문자열만 결과에 추가합니다.
def identity(xs):
return list(xs)
def sorted_unique(xs):
return sorted(set(xs))
def first_seen(xs):
result = []
for x in xs:
if x not in result:
result.append(x)
return result
테스트가 빈 목록과 이미 정렬된 중복 없는 목록만 확인하면 어떻게 될까요? 세 함수 모두 통과합니다. 원래 요구한 중복 제거와 순서 보존을 제대로 구별할 입력이 없기 때문입니다.
| 검사 입력 | 요구사항으로 정한 기대 결과 | 확인하려는 조건 |
| [] | [] | 빈 입력 |
| [“A”, “B”] | [“A”, “B”] | 중복 없는 입력 |
| [“A”, “B”, “A”] | [“A”, “B”] | 떨어져 있는 중복 제거 |
| [“B”, “A”, “B”] | [“B”, “A”] | 처음 등장한 순서 유지 |
직접 실행한 결과: 2/2와 4/4의 차이
2026년 9월 29일, 위 함수와 아래 검사 코드를 로컬 Python에서 실행했습니다. 앞의 두 사례만 검사한 결과와 네 사례를 모두 검사한 결과를 나란히 비교했습니다.
| 구현 | 앞의 두 사례 | 네 사례 전체 | 놓치거나 위반한 조건 |
| identity | 2/2 통과 | 2/4 통과 | 중복이 남음 |
| sorted_unique | 2/2 통과 | 3/4 통과 | 입력 순서가 바뀜 |
| first_seen | 2/2 통과 | 4/4 통과 | 이 네 사례에서는 요구 충족 |
세 함수 정의 아래에 다음 코드를 붙이면 같은 결과를 확인할 수 있습니다. 입력값과 정답을 눈으로 비교하기 쉬우도록 작은 사례만 사용했습니다.
cases = [
([], []),
(["A", "B"], ["A", "B"]),
(["A", "B", "A"], ["A", "B"]),
(["B", "A", "B"], ["B", "A"]),
]
for fn in (identity, sorted_unique, first_seen):
thin = sum(fn(xs) == want for xs, want in cases[:2])
full = sum(fn(xs) == want for xs, want in cases)
print(f"{fn.__name__}: {thin}/2, {full}/4")
4/4 통과는 모든 상황에 대한 증명이 아닙니다. 이 예제는 문자열 목록만 다루며 대용량 입력 성능을 평가하지 않았습니다. 설명용 first_seen은 결과 목록을 반복 검색하므로, 규모가 커지면 별도의 성능 검토가 필요합니다.
AI가 만든 테스트를 검토하는 네 가지 질문
기대 결과의 근거가 요구사항인가요? 현재 구현의 출력값을 그대로 정답으로 저장하면 기존 버그를 보존할 수 있습니다. 화면 스냅샷도 사람이 최초 기준을 검토해야 합니다.
일부러 틀린 구현을 넣으면 실패하나요? 위 예제에서는 입력 그대로 반환하거나 정렬해 버리는 구현이 좋은 반례입니다. 검사 대상의 핵심 조건을 어겼는데도 통과하면 테스트 입력이나 판정 기준을 다시 봅니다.
정상 사례만 있나요? 중복, 빈 입력, 순서 변화처럼 요구사항을 구분하는 사례를 고릅니다. 숫자를 임의로 많이 늘리는 것보다 빠진 조건을 찾는 데 집중합니다.
검사를 실제로 실행했나요? 테스트 파일이 있다는 사실과 실행 성공은 다릅니다. 실행 명령, 결과, 실행하지 못한 검사를 함께 받으면 확인 범위를 알 수 있습니다.
복사해서 쓰는 검토 요청문
구현의 현재 출력을 정답으로 삼지 말고 요구사항에서 기대 결과를 먼저 정해줘.
각 테스트가 확인하는 조건을 한 문장으로 적어줘.
핵심 조건을 어기는 잘못된 구현 예시를 하나 만들고, 테스트가 이를 잡는지 확인해줘.
실행한 명령과 실제 결과, 실행하지 못한 검사는 구분해서 보고해줘.
자주 묻는 질문
AI에게 코드와 테스트를 함께 맡기면 안 되나요? 함께 맡길 수 있습니다. 다만 사람이 요구사항에서 정한 예시와 독립적인 확인 기준을 함께 제공하는 편이 좋습니다.
커버리지가 높으면 충분한가요? 실행한 코드 범위와 올바른 결과를 판정하는 능력은 다릅니다. 지나간 줄 수만으로 기대 결과의 타당성을 보장할 수 없습니다.
이 예제 결과가 실제 AI 정확도를 뜻하나요? 아닙니다. 세 함수는 설명을 위해 구성한 예시이며 AI 모델을 평가한 실험이 아닙니다.
참고 자료와 확인 범위
자료 확인일: 2026년 9월 29일. 외부 실험 소개와 본문의 자체 예제 실행 결과를 구분했습니다.