현실의 디테일, AI 에이전트 평가의 맹점

오래된 글이 AI 시대에 다시 뜨는 이유

John Salvatier의 2017년 에세이 Reality has a surprising amount of detail가 Hacker News에서 다시 회자된 것은 우연이 아니다. 글의 핵심은 간단하다. 계단을 만들거나 물을 끓이는 일처럼 평범해 보이는 작업도 가까이 들어가면 수많은 세부조건이 있고, 그 조건은 초보자에게는 보이지 않다가 경험을 통해서야 투명해진다.

이 관찰은 2026년의 AI 에이전트 논의와 바로 맞닿아 있다. 지금 시장은 더 긴 컨텍스트, 더 높은 추론 점수, 더 강한 코딩 모델을 말하지만, 실제 기업 업무의 실패는 종종 "모델이 몰랐던 작은 조건"에서 나온다. 파일 권한, 레거시 데이터 형식, 운영 시간대, 누락된 테스트, 사내 승인 흐름 같은 요소는 벤치마크 문제에는 잘 등장하지 않는다.

벤치마크와 현실 업무 사이의 간격

SWE-bench나 Terminal-Bench 같은 평가는 코딩 에이전트의 진전을 보여주는 중요한 장치다. 다만 문제는 평가가 현실을 충분히 압축할 수 없다는 데 있다. 현실의 프로젝트는 해결해야 할 이슈 하나가 아니라, 서로 엮인 가정들의 묶음이다. 그래서 Claude Code 5배 비용 논란, 원장이 필요하다에서 다룬 것처럼 비용 추적도 단순 토큰 총량보다 작업 단위와 재시도 원인을 함께 봐야 한다.

Anthropic의 시스템 카드 페이지가 모델별 위험과 평가 조건을 문서화하는 것도 같은 이유다. 모델 성능은 숫자 하나로 말하기 어렵고, 배포 조건과 감시 방식에 따라 결과가 달라진다.

에이전트에게 필요한 것은 더 많은 지시가 아니라 더 빠른 발견

현실의 디테일이 많은 세계에서 좋은 에이전트는 모든 것을 미리 아는 존재가 아니다. 좋은 에이전트는 모르는 조건을 빨리 발견하고, 그 발견을 작업 계획에 반영하고, 위험한 추측을 검증 가능한 질문으로 바꾸는 시스템이다. htmx 사례가 보여준 AI 코딩의 좋은 거리감이 말한 "좋은 거리감"도 결국 인간과 모델이 세부조건을 함께 드러내는 방식에 가깝다.

한국 기업 입장에서는 이 차이가 크다. SI, 금융, 제조, 공공 프로젝트는 표면 요구사항보다 암묵 규칙이 많다. 업무 담당자는 "당연히 그렇게 해야 한다"고 생각하지만, 에이전트는 그 당연함을 모른다. 따라서 프롬프트 템플릿보다 중요한 것은 운영 문서, 테스트 데이터, 실패 로그, 승인 기준을 에이전트가 읽을 수 있는 형태로 만드는 일이다.

제품 설계의 기준도 바뀐다

AI 에이전트 제품은 "한 번에 끝내는 마법"처럼 팔리기 쉽다. 그러나 현실의 디테일을 인정하면 제품의 중심은 자동완성이 아니라 관찰 가능성으로 이동한다. 어떤 파일을 읽었는지, 어떤 가정을 세웠는지, 어떤 테스트를 실행했는지, 어디서 사람의 판단을 기다렸는지 보여줘야 한다. Codex 민감 파일 제외, 에이전트 보안의 빈틈에서 본 보안 문제도 같은 층위다. 보이지 않는 세부조건은 기능 실패뿐 아니라 보안 실패가 된다.

그래서 앞으로의 경쟁력은 모델 선택만으로 결정되지 않는다. 조직이 에이전트에게 현실을 얼마나 잘 보여주는지, 그리고 에이전트가 발견한 디테일을 다시 조직 지식으로 저장하는지가 중요하다. OpenAI Evals처럼 평가를 직접 설계하는 접근은 기업 내부에서도 필요해진다.

자주 묻는 질문

Q1: 왜 2017년 에세이가 AI 뉴스가 되나요?

A: 에이전트가 실제 업무를 맡는 순간, 글이 말한 "숨은 세부조건"이 자동화 실패의 핵심 원인이 되기 때문이다.

Q2: 벤치마크는 쓸모없다는 뜻인가요?

A: 아니다. 벤치마크는 비교의 출발점이다. 다만 실제 배포 전에는 조직별 데이터, 권한, 테스트, 승인 흐름을 포함한 별도 평가가 필요하다.

Q3: 개발팀이 바로 할 수 있는 일은 무엇인가요?

A: 에이전트 작업마다 입력 자료, 실행 명령, 실패 원인, 사람 승인 지점을 로그로 남기는 것이다.

Q4: 프롬프트를 길게 쓰면 해결되나요?

A: 일부는 해결되지만 충분하지 않다. 문서화되지 않은 운영 규칙과 실제 데이터 예외를 모델이 관찰할 수 있어야 한다.

Q5: 한국 기업에 특히 중요한 이유는 무엇인가요?

A: 레거시 시스템과 내부 승인 절차가 많은 환경에서는 겉보기 요구사항보다 숨은 조건이 더 큰 비용을 만들기 때문이다.