AI의 그럴듯함을 어디까지 믿을 것인가

AI에게 요구사항 한 줄을 주면 몇 초 만에 그럴듯한 기획서나 코드를 만든다. 코드는 실행되기도 하고, 설명은 막힘없이 이어진다. 이 경험을 몇 번 반복하면 AI가 문제의 원인과 결과까지 이해한다고 받아들이기 쉽다.

하지만 결과가 자연스럽다고 해서 그 결과에 이르는 설명까지 맞는 것은 아니다. LLM은 학습 데이터와 현재 문맥에서 다음에 올 가능성이 높은 토큰을 생성한다. 데이터에 반복해서 나타난 관계를 잘 포착하지만, 그 관계만으로 어느 요인이 결과를 일으켰는지 증명하지는 않는다.

AI를 제대로 쓰려면 이 차이를 알아야 한다. 패턴을 찾고 후보를 만드는 데 강한 도구라고 해서 인과 판단과 최종 검증까지 맡기면, 처음에는 빠르더라도 전제가 달라지는 순간 큰 비용을 치를 수 있다.

그럴듯한 답은 어떻게 만들어지는가

LLM은 문장을 단순히 복사하지 않는다. 많은 데이터에서 언어와 코드의 구조, 개념 사이의 관계, 자주 이어지는 해결 방식을 학습한다. 그래서 처음 보는 요청에도 익숙한 패턴을 조합해 유용한 답을 만들 수 있다.

예를 들어 로그인 기능을 요청하면 모델은 입력 폼, 인증 API, 세션 처리와 오류 응답처럼 함께 등장할 가능성이 높은 요소를 연결한다. 요청한 프레임워크의 관례가 학습 데이터에 충분히 담겨 있고 요구사항도 전형적이라면 결과는 실제로 잘 동작할 수 있다.

문제는 모델의 설명이 그럴듯한지, 실제로 맞는지 겉만 봐서는 구분하기 어렵다는 데 있다. 존재하지 않는 API를 진짜처럼 설명할 때도 문장은 매끄럽다. 보안 요구사항이나 운영 환경을 잘못 가정해도 코드는 일관돼 보일 수 있다. 출력이 유창하다는 것은 문맥에 잘 맞는다는 신호일 뿐, 외부 세계에서 검증됐다는 표시가 아니다.

모델이 추론 과정을 길게 제시하거나 Agent, Skill, Tool을 사용한다고 해서 이 성질이 사라지는 것도 아니다. 이런 장치는 관련 문맥을 공급하고, 작업을 나누고, 실제 도구로 결과를 확인할 기회를 늘린다. 오류를 줄이는 데 도움이 되지만, 모델이 만든 가정을 자동으로 사실로 바꾸지는 않는다.

상관관계는 행동의 결과를 보장하지 않는다

두 변수가 함께 움직인다는 사실만으로 무엇이 원인인지는 알 수 없다. A가 B에 영향을 줬을 수도 있고, B가 A에 영향을 줬을 수도 있다. 관찰하지 않은 C가 둘 모두를 바꿨을 가능성도 있다.

AI가 현실의 의사결정에 쓰이기 시작하면 이 구분이 중요해진다.

• 패턴을 바탕으로 한 예측은 보통 무엇이 함께 일어났는가에 답한다.
• 인과 판단은 우리가 조건을 바꾸면 무엇이 일어나는가에 답해야 한다.

과거 구매 데이터에서 할인 쿠폰을 받은 고객의 재구매율이 높았다고 해보자. 이 관계만 보고 모든 고객에게 쿠폰을 보내도 같은 효과가 난다고 말할 수는 없다. 원래 재구매 가능성이 높은 고객에게 쿠폰을 보냈을 수 있고, 쿠폰 발급 규칙을 바꾸면 고객의 행동이나 비용 구조도 함께 달라진다. 과거를 잘 설명한 예측값을 곧바로 행동을 위한 레버로 취급하면 결과를 관찰하는 환경 자체가 바뀐다.

LLM이 이런 분석을 자연스럽게 설명해도 상황은 달라지지 않는다. 모델이 인과를 나타내는 문장을 만들 수 있다는 사실과 주어진 자료로 인과관계를 식별했다는 사실은 별개다. 개입 전후를 비교할 실험, 적절한 대조군, 도메인 지식이나 인과 구조가 없다면 답은 여전히 가설에 가깝다.

평균적인 성공이 실제 작업의 안전성을 말해주지는 않는다

AI 성능을 평가할 때는 보통 여러 문제의 결과를 모은 평균 지표를 쓴다. 평균은 모델을 비교하는 데 유용하지만, 내가 맡기려는 개별 작업의 위험까지 대신 판단해 주지는 않는다. 정확도가 같아도 모델이 어떤 문제에서 틀리는지, 오답의 비용이 얼마인지에 따라 쓸 수 있는 범위가 달라진다.

여기서 흔히 말하는 ’평균으로의 회귀’는 평균 지표의 한계와 구분해야 한다. 평균으로의 회귀는 극단적인 관측 뒤의 값이 평균에 가까워지는 통계적 현상이다. AI가 평균적인 패턴을 선호하거나 드문 사례에 약한 문제를 이 용어 하나로 모두 설명할 수는 없다.

실제 작업에서 더 직접적인 위험은 분포가 달라지는 데 있다. 학습이나 테스트에서 암묵적으로 유지되던 조건이 운영 환경에서는 바뀔 수 있다.

• 고객군과 사용 목적이 달라진다.
• 라이브러리 버전이나 외부 API 계약이 바뀐다.
• 모델의 출력을 보고 사람이 행동하면서 다음 입력 데이터도 변한다.
• 평소에는 드물던 장애, 공격, 규제 조건이 중요한 순간에 나타난다.

이런 변화가 생기면 과거의 규칙성이 그대로 이어지지 않는다. 평균 점수가 높은 모델도 새 조건에서 어떤 방식으로 실패할지는 별도로 확인해야 한다. 특히 보안, 의료, 법률, 재무처럼 한 번의 오류 비용이 큰 영역에서는 평균 성능보다 실패 조건과 검증 절차가 먼저다.

가정은 적어 둔 조건보다 훨씬 넓다

가정이라고 하면 요구사항 문서에 적힌 조건이나 코드에서 직접 선택한 값부터 떠올리기 쉽다. 하지만 실제 작업을 떠받치는 가정의 대부분은 너무 당연해 보여 조건이라는 사실조차 놓치기 쉽다.

로컬에서 기능을 테스트했다고 해보자. 라이브러리와 도구의 버전, OS만 같으면 결과를 재현할 수 있다고 생각하기 쉽다. 하지만 실제 결과에는 더 많은 조건이 개입한다.

• CPU 아키텍처와 코어 수, 메모리와 디스크 여유 공간
• 사내망·사외망의 차이, 프록시, DNS, 방화벽과 접근 권한
• 환경 변수, 시크릿, 로케일, 타임존과 시스템 시각
• 브라우저 종류와 확장 프로그램, 이미 로그인된 세션
• 쿠키, 로컬 스토리지, 서비스 워커와 각종 캐시
• 이전 실행이 남긴 파일, 데이터베이스 상태와 큐의 처리 순서
• 동시에 실행 중인 프로세스, 요청 시점과 외부 서비스의 상태

이 가운데 하나가 로컬과 CI, 개발 환경과 운영 환경 사이에서 달라지면 같은 코드도 다른 결과를 낼 수 있다. “내 컴퓨터에서는 된다”는 관찰은 코드가 모든 환경에서 옳다는 증거가 아니다. 그 컴퓨터의 드러난 조건과 숨어 있는 조건을 포함한 한 번의 실행에서 성공했다는 뜻일 뿐이다.

가정은 코드와 버전 목록에서 끝나지 않는다. 실행 상태와 인증 정보, 네트워크와 하드웨어도 결과를 좌우한다.

AI에게 “빠진 가정을 모두 찾아줘”라고 요청해도 완전한 목록을 얻을 수는 없다. 모델은 흔한 실패 조건을 넓게 제안하는 데 유용하지만, 제공받지 않은 환경의 상태를 직접 관찰하지 못한다. 브라우저에 어떤 계정이 로그인돼 있는지, 특정 캐시가 우연히 남았는지, 사내 DNS가 어떤 주소를 돌려주는지는 Tool로 확인하지 않는 한 알 수 없다.

그래서 가정 목록을 길게 만드는 것보다 환경을 격리하고 실행 조건을 기록해 재현성을 확보하는 일이 중요하다. 이렇게 하면 목록에 넣지 못한 조건이 결과에 끼어들 여지를 구조적으로 줄일 수 있다.

재현 가능한 검증 환경
- 의존성과 런타임 버전을 고정한다.
- 컨테이너나 CI처럼 초기 상태가 정해진 환경에서 실행한다.
- 테스트 데이터, 환경 변수와 권한을 명시적으로 주입한다.
- 외부 서비스는 고정된 픽스처나 제어 가능한 테스트 더블로 분리한다.
- 실행 명령, 입력, 리비전, 실행 환경과 결과를 함께 기록한다.
- 캐시와 이전 실행 상태를 비운 뒤 같은 결과가 나오는지 확인한다.

격리만으로 운영 환경을 완전히 복제할 수는 없다. 컨테이너가 같아도 호스트의 CPU 아키텍처나 네트워크 정책은 다를 수 있다. 환경을 고정한 테스트, 운영과 가까운 통합 테스트, 실제 관측 지표를 단계적으로 연결해야 하는 이유다. 핵심은 모든 가정을 미리 알아내는 데 있지 않다. 모르는 가정이 개입했을 때 차이를 발견하고 다시 실행할 수 있게 만들어야 한다.

의존과 불신이 번갈아 생기는 이유

처음 AI를 쓰면 AI에 기대하는 범위가 빠르게 넓어진다. 짧은 지시로 결과가 나오고 몇 번은 실제로 작동하니, 아직 검증하지 않은 일까지 ’AI가 구현할 수 있는 일’로 묶기 쉽다. 탐색 도구였던 AI가 어느새 판단과 승인까지 맡게 된다.

그 상태에서 초기 가정 하나가 깨지면 수정 비용이 급격히 커진다. 모델은 기존 문맥을 최대한 유지하며 국소적인 수정을 반복한다. 하지만 문제의 뿌리가 잘못된 데이터 계약이나 아키텍처 선택이라면 패치가 또 다른 패치를 부른다. 결국 처음부터 다시 만드는 편이 빠르다고 판단할 수도 있다.

이 경험 뒤에는 반대 방향의 과잉 반응도 생긴다. AI는 믿을 수 없으니 차라리 직접 해야겠다고 판단한다. 하지만 두 반응 모두 도구의 책임 범위를 정하지 않았다는 점에서는 같다. 처음에는 생성 결과를 정답으로 취급했고, 나중에는 정답이 아니었다는 이유로 생성 능력까지 버린다.

필요한 것은 무조건적인 신뢰나 불신이 아니다. AI가 후보를 빠르게 만드는 단계와 사람이 근거를 확인해 결정하는 단계를 나눠야 한다.

AI에 맡길 일과 남겨둘 판단을 나눈다

나는 AI를 쓸 때 작업을 생성, 검증, 결정으로 나눠야 안전하다고 본다.

단계	AI가 잘하는 일	외부 기준으로 확인할 일
생성	초안, 원인 후보, 대안, 검색어 만들기	후보가 사실인지 판정하기
검증	확인할 항목과 테스트 설계하기	문서 원문, 코드 실행, 실험 결과 확인하기
결정	선택지의 장단점과 빠진 질문 정리하기	비용과 위험을 감수할지 결정하기

같은 모델이 세 단계에 모두 참여할 수는 있다. 다만 모델이 앞에서 만든 문장을 나중에 스스로 승인하게 하면 검증 효과가 약하다. 공식 문서, 원본 데이터, 테스트 결과, 명시적인 정책처럼 모델 출력과 독립된 기준을 적용해야 한다.

코딩 작업이라면 다음처럼 책임을 나눌 수 있다.

1. AI가 관련 파일을 찾고 원인 후보를 만든다.
2. 각 후보를 반증할 가장 작은 테스트를 정한다.
3. 수정 전에 현재 실패를 재현한다.
4. AI가 변경안을 만들면 타입 검사와 테스트를 실행한다.
5. 요구사항과 보안 경계는 사람이 다시 확인한다.

조사나 글쓰기에서도 구조는 같다. AI가 주장 후보와 반론을 만들 수 있지만, 날짜, 수치, 인용과 고유명사는 원문에서 확인한다. 출처 링크의 유무만 보지 말고 그 페이지가 해당 주장을 직접 뒷받침하는지도 읽어야 한다.

답보다 먼저 가정을 요청한다

그럴듯함에 휩쓸리지 않으려면 답에 깔린 전제를 직접 드러내라고 모델에 요청할 수 있다. 답을 받은 뒤 다음 내용을 추가로 요청한다.

이 답이 성립하려면 참이어야 하는 가정을 적어줘.

- 주어진 자료에서 확인된 사실
- 확인하지 않고 둔 가정
- 결과에 영향을 줄 수 있지만 현재 관찰할 수 없는 환경 조건
- 조건이 바뀌면 깨질 수 있는 판단
- 결론을 뒤집을 반례
- 실제로 확인할 수 있는 가장 작은 테스트
- 같은 결과를 재현하기 위해 격리하거나 기록할 조건

확인하지 못한 내용은 자연스럽게 채우지 말고 '미확인'으로 표시해줘.

이 프롬프트도 정답 보증서는 아니다. 모델이 빠뜨린 가정은 여전히 남는다. 대신 결과물을 완성된 답 하나가 아니라 검증 가능한 주장 묶음으로 바꿔준다. 확인할 항목이 보이면 사람과 도구가 개입할 지점도 선명해진다.

검증 강도는 틀렸을 때의 비용에 맞춘다. 아이디어 이름을 고를 때 운영 장애에 대비하는 수준의 절차까지 적용할 필요는 없다. 반대로 공개할 통계, 데이터 삭제 코드, 결제 로직처럼 되돌리기 어려운 작업을 ’대체로 잘 맞는다’는 이유로 승인해서도 안 된다.

한계를 작업 흐름에 넣어야 한다

LLM은 평균적인 답만 반복하는 기계도 아니고, 모든 문제의 원인을 이해하는 만능 도구도 아니다. 익숙한 패턴을 압축해 새로운 후보를 빠르게 만들고, 미처 보지 못한 관점을 제시하며, 사람이 검증해야 할 범위를 줄이는 데 강하다.

그 능력을 제대로 쓰려면 작업 내내 세 가지 질문을 놓치지 않아야 한다.

• 이 답은 어떤 가정 위에 서 있는가?
• 조건이 바뀌어도 관계가 유지된다는 근거가 있는가?
• 틀렸을 때 발견하고 되돌릴 검증 절차가 있는가?

프롬프트 엔지니어링과 Agent, Tool은 이 질문에 답할 재료를 더 잘 모아준다. 최종 판단까지 대신해 주지는 않는다. AI의 그럴듯함을 없애려 하기보다 생성에 활용하고, 사실과 인과 판단, 결정은 독립된 근거로 확인하는 편이 낫다. 이 경계를 작업 흐름에 넣으면 AI를 과신하거나 아예 포기하지 않고 목적에 맞게 쓸 수 있다.