AI에게 '검증 가능하게' 시켜라: 프롬프트 설계 원칙

AI를 잘 쓰는 핵심은 검증 가능한 형태로 시키는 것이다. 안드레이 카파시는 2026년 "전통적 컴퓨터가 코드로 명세할 수 있는 일을 자동화했다면, LLM은 검증할 수 있는 일을 자동화한다"고 말했다. 따라서 프롬프트는 산출을 검증 가능하게 만들수록 정확해진다. ASAP은 이 원칙을 프롬프트 설계법으로 정리한다.

카파시의 한 줄이 뒤집는 프롬프트 상식

기존 프롬프트 조언은 대개 "구체적으로 써라", "역할을 부여하라" 같은 표현 기술에 머물렀다. 카파시의 명제는 초점을 표현에서 채점 가능성으로 옮긴다. 프롬프트를 잘 쓰는 문제가 아니라, 결과를 맞았는지 틀렸는지 판정할 수 있게 설계하는 문제로 바뀐다. 이 관점에서는 아무리 정교하게 다듬은 프롬프트라도 정답을 가릴 기준이 없으면 신뢰할 수 없다.

검증 가능성이 능력을 가르는 이유

LLM이 강한 영역과 약한 영역은 검증 가능성으로 갈린다. 모델은 정답을 채점할 수 있는 환경(테스트·점수·증명)에서 강화학습으로 훈련돼, 그런 작업에서 능력이 뾰족한다. 그래서 검증 가능한 형태로 시키면 모델의 강점을 끌어내고, 사람도 결과를 잡아낼 수 있다. 훈련 방식이 곧 사용 방식을 규정하는 셈이다. 모델이 학습한 환경과 닮은 형태로 문제를 던질수록 능력이 제대로 발현된다고 읽을 수 있다.

세 가지 설계 원칙

검증 가능한 프롬프트는 3가지 설계 원칙을 갖추며, 순서대로 적용한다.

정답 판정 기준을 명시하라: 무엇이 '맞음'인지 테스트·예시·포맷으로 못 박는다.
검증 가능한 형태로 출력을 요구하라: 코드+테스트, 표, 체크리스트처럼 확인 가능한 산출을 시킨다.
자기검증 단계를 요구하라: 답을 내기 전 스스로 점검·반례 확인을 거치게 한다.

세 원칙 모두 '확인할 수 있게' 만드는 장치이다.

나쁜 프롬프트 vs 좋은 프롬프트

같은 작업이라도 아래 3가지 대비처럼 검증 가능성에서 결과가 갈린다. 다음 대비가 핵심이다.

나쁜 프롬프트	좋은 프롬프트
"이 함수 좀 고쳐줘"	"이 입력에 이 출력이 나오게 고치고, 그 케이스를 테스트로 같이 써라"
"마케팅 카피 써줘"	"아래 5개 항목을 각각 한 문장으로, 표로 출력해라"
"이거 분석해줘"	"결론을 먼저 한 줄로, 근거를 수치 3개로 제시해라"

오른쪽이 모델의 강점을 끌어내고 결과를 검증 가능하게 만든다. 세 사례가 공통으로 하는 일은 두루뭉술한 요청에 판정 기준을 심는 것이다. 왼쪽은 결과를 봐도 잘 됐는지 알 수 없고, 오른쪽은 통과·실패를 즉시 가릴 수 있다.

검증이 안 되는 작업을 다루는 법

검증이 어려운 작업은 LLM에 어떤 프롬프트를 줘도 위험한다. 답을 채점할 방법이 없으면 모델은 그럴듯한 오답을 낼 수 있고, 사람도 잡지 못한다. 이런 작업은 검증 가능한 작은 조각으로 쪼개거나, 사람의 판단을 명시적으로 끼워 넣어야 한다. 한국 실무자에게 이 원칙은 곧 업무 분해 능력의 문제로 이어진다. 전략 판단이나 취향처럼 채점하기 어려운 일을 그대로 맡기기보다, 검증 가능한 하위 작업으로 잘라내는 사람이 AI를 안전하게 쓴다.

이 원칙의 한계

검증 가능성은 만능 잣대가 아니다. 판정 기준을 세우는 데 드는 비용이 작업 자체보다 클 수 있고, 테스트로 표현하기 어려운 질적 판단은 여전히 사람 몫으로 남는다. 그럼에도 좋은 프롬프트가 곧 검증 가능한 프롬프트라는 명제는 유효하다. 정답 기준을 명시하고, 확인 가능한 형태로 출력을 요구하고, 자기검증을 시키는 것이 그 실천이다.

출처: Andrej Karpathy, "From Vibe Coding to Agentic Engineering"(Sequoia AI Ascent 2026; 명세 가능 → 검증 가능 자동화) 기반 ASAP 정리.