'AI를 잘 쓴다'는 게 무슨 의미일까? 도구를 많이 쓰고, 다양한 모델을 비교하고, 가장 비싼 옵션을 구독하는 것? 최근 두 가지 실전 사례가 동시에 같은 답을 가리키고 있다. 질문을 제대로 설계하는 것이 전부라는 것.
10개 계획하고 1개만 실행했지만, 충분했다
dev.to에 공개된 LLM 평가 실험기는 흥미로운 고백으로 시작된다. 저자는 10가지 실험을 설계했다—적응형 예산 튜너, 컨텍스트 로트 감지, 툴 드리프트 측정 등 정교하게 구획된 실험 프로그램이었다. 그리고 실제로 실행한 건 단 하나였다.
이유는 단순했다. "내가 실제로 매일 하는 일에 가장 가까운 것부터 시작하자." 그가 고른 실험은 CI 진단—GitHub Actions 로그에서 빌드 실패 원인을 파악하는 작업이었다. 수천 줄짜리 로그를 내려받아 패턴을 찾는 데 팀원들이 한 시간 이상을 쓰고 있었고, 수정 사항을 프로덕션에 반영하는 데 하루가 걸리는 일이 반복되고 있었다.
실험 결과는 명확했다. Haiku 4.5는 Sonnet 5보다 10배 저렴하고 67% 빠르면서, 정확도는 통계적으로 동일했다. 총 실험 비용은 $13.53. '비싼 모델이 더 낫다'는 막연한 직관이 실제 워크플로우 앞에서 무너진 순간이다.
하지만 이 이야기의 진짜 핵심은 Haiku가 이겼다는 사실이 아니다. 10개를 전부 실행하지 않아도 됐다는 것이다. 가장 실무에 밀착된 질문 하나를 제대로 설계하자, 나머지 9개 실험이 답하려 했던 상위 물음—"언제 비싼 모델이 필요한가"—에 대한 실질적인 인사이트가 따라왔다. 린(Lean) 검증의 교과서적 실천이다.
'추측'을 '탐색'으로 바꾸는 것이 프롬프트 설계의 전부다
같은 날 등장한 또 다른 사례는 더 극적이다. 1997년 출시된 게임 Carmageddon의 암호화된 차량 데이터 파일을 해독하려는 시도였다. 처음에는 Claude에게 단순하게 물었다. "이 암호화 방식을 분석해줘." 결과는 실패였다. 16바이트 키, 인덱스 오프셋, 주석 감지 시 전환되는 이중 키—이런 구조는 바이트 패턴을 아무리 들여다봐도 추론할 수 없다.
돌파구는 질문의 방향을 바꾸는 데서 왔다. 게임 역공학 저장소 'dethrace'에서 실제 C 소스코드를 찾아낸 뒤, 질문이 달라졌다. "이 코드를 찾아서 설명해줘. 그리고 JavaScript로 변환해줘." Claude는 utility.c의 EncodeLine 함수를 정확히 찾아내 번역했다.
그다음 문제는 엔디안이었다. 빅 엔디안과 리틀 엔디안, 둘 다 논리적으로 그럴듯해 보였다. 해결의 열쇠는 소스코드 주석 한 줄이었다—GENERAL.TXT는 반드시 0.01로 복호화되어야 한다. 이 알려진 값(known value) 하나가, 그 어떤 추론보다 강력했다. 검증 가능한 기준점이 생기자 모호함이 사라졌다.
맥락 해석: 질문의 품질이 AI의 품질을 결정한다
두 사례는 표면적으로는 다르다. 하나는 DevOps 자동화, 다른 하나는 레트로 게임 리버스 엔지니어링. 하지만 둘 다 같은 패턴을 보여준다.
잘못된 질문 → 그럴듯하지만 틀린 답 제대로 된 질문 → 검증 가능한 실질적인 답
Carmageddon 사례에서 "암호화를 풀어줘"는 LLM이 답할 수 없는 질문이었다. 실제 코드를 근거로 "이걸 번역하고 설명해줘"로 바꾸자 AI는 비로소 유용해졌다. LLM 평가 실험에서도 마찬가지다. "어떤 모델이 더 좋냐"는 질문은 맥락이 없다. "내 CI 로그에서는 어떤 모델이 더 효율적이냐"는 질문은 측정 가능하다.
이건 프롬프트 엔지니어링 기술의 문제가 아니다. 문제를 충분히 좁히는 것의 문제다. 범위가 좁아질수록 AI가 틀릴 여지가 줄고, 결과를 검증할 기준점이 생기고, 실제 의사결정에 쓸 수 있는 답이 나온다.
시사점: 프로토타입 전에 질문부터 설계하라
프론트엔드 개발 워크플로우에 직접 대입해보면 이 교훈은 더 선명해진다. v0.dev나 Claude로 컴포넌트를 생성할 때, "이 화면 만들어줘"는 나쁜 질문이다. "로그인 실패 후 사용자가 다음 단계를 명확히 알 수 있는 에러 상태 컴포넌트를 Tailwind + shadcn/ui 기준으로 만들어줘"는 좋은 질문이다.
차이는 검증 기준의 존재 여부다. Carmageddon 사례의 0.01처럼, 좋은 질문에는 항상 '이게 맞는지 확인할 수 있는 기준'이 내장되어 있다. LLM 실험의 $13 실험처럼, 좋은 실험에는 항상 '이 결과로 실제 의사결정을 바꿀 수 있는가'라는 기준이 붙어 있다.
전망: AI 리터러시의 핵심은 질문 설계 능력으로 수렴한다
모델은 계속 좋아진다. Haiku가 오늘 Sonnet을 따라잡았다면, 내년엔 더 저렴한 모델이 오늘의 Haiku를 넘어설 것이다. 하지만 어떤 모델을 쓰더라도 변하지 않는 병목이 있다. 질문의 품질이다.
"AI를 잘 쓰는 팀"과 "AI를 많이 쓰는 팀"의 차이는 결국 여기서 갈린다. 전자는 실험 전에 검증 기준을 설계하고, 질문을 좁히고, 알려진 값을 먼저 확보한다. 후자는 더 비싼 모델을 구독하고, 더 많은 프롬프트를 입력하고, 더 많은 토큰을 소비한다.
10개를 계획하고 1개만 실행해도 충분한 이유는 간단하다. 제대로 된 질문 하나가 열 개의 모호한 실험보다 훨씬 많은 것을 가르쳐주기 때문이다.