혹시 AI에게 질문을 던지고, 완벽하게 작성된 답변을 받은 뒤, 그 조언을 따랐다가 나중에 무언가 완전히 틀렸다는 것을 발견한 적이 있나요?
어쩌면 존재하지 않는 프로그래밍 방법을 제안했을 수도 있습니다. 어쩌면 구식의 해결책을 제시했거나, 실제로는 전혀 다른 원인을 가진 기술적 문제를 자신감 있게 설명했을 수도 있습니다.
이상한 점은 답변 내용 중 아무것도 의심스러워 보이지 않았다는 것입니다. 설명은 명확했고, 코드는 합리적으로 보였으며, 응답은 자신이 무슨 말을 하는지 정확히 아는 사람에게서 나온 것처럼 들렸습니다.
그렇다면 AI는 어떻게 복잡한 개념을 그렇게 잘 설명하면서도 놀라울 정도로 간단한 실수를 할 수 있을까요?
정답은 단순히 AI가 때때로 정보가 부족하기 때문만은 아닙니다. 이는 시스템이 답변을 생성하는 방식, 불확실성을 처리하는 방식, 그리고 설득력 있는 언어가 때로는 부정확한 정보를 숨길 수 있다는 것과 관련이 있습니다.
자세히 살펴보겠습니다.
1. AI는 패턴 학습을 통해 답변을 생성합니다
우리가 AI에 질문할 때는 종종 그것이 자신의 지식을 검색하고, 정확한 답을 찾아 우리에게 제시한다고 상상합니다.
하지만 반드시 그런 것은 아닙니다.
대규모 언어 모델(Large language models)은 방대한 양의 텍스트에서 패턴을 학습합니다. 훈련 과정 동안 이들은 주어진 문맥에 맞는 언어를 생성하는 능력을 개발합니다. 이를 통해 프로그래밍 개념을 설명하고, 문서를 요약하며, 코드를 작성하고, 다양한 질문에 답변할 수 있습니다.
예를 들어, AI에게 API가 어떻게 작동하는지 설명해달라고 요청하면, 문서, 튜토리얼, 프로그래밍 토론에서 학습한 패턴을 활용할 수 있습니다.
하지만 올바르게 들리는 설명을 생성하는 것이 그 안에 포함된 모든 사실을 독립적으로 검증하는 것과는 같지 않습니다.
모델은 모든 진술이 참이라는 충분한 증거 없이도 설득력 있는 답변을 만들어낼 수 있습니다.
AI가 응답을 생성하는 방식을 이해하는 것이, AI가 때때로 틀리는 이유를 이해하는 첫걸음입니다.
AI 답변이 생성되는 방식
User Question
↓
Input Processing
...
이것은 과정의 단순화된 표현입니다. 현대 AI 시스템은 응답을 개선하기 위해 검색(search), 외부 도구(external tools) 및 기타 메커니즘도 사용할 수 있습니다.
2. AI 환각(Hallucination)이란 정확히 무엇인가?
AI 분야에서 가장 많이 논의되는 문제 중 하나는 '환각(hallucination)'으로 알려져 있습니다.
AI 환각은 모델이 사실적이지 않거나, 오해를 불러일으키거나, 근거가 부족한 정보를 생성하여 마치 그것이 사실인 것처럼 제시할 때 발생합니다.
다음과 같이 AI에게 질문한다고 상상해 보세요:
"2025년에 출시된 React를 대체하도록 설계된 JavaScript 라이브러리는 무엇인가요?"
만약 그러한 설명을 만족하는 라이브러리가 없다고 가정합시다. AI는 전제에 의문을 제기하는 대신, 가상의 라이브러리 이름을 만들고, 그 기능을 설명하며, 개발자들이 왜 그것을 사용해야 하는지 설명할 수 있습니다.
심지어 완전히 합법적으로 보이는 설치 명령까지 생성할 수도 있습니다.
그 응답은 핵심 주장이 거짓임에도 불구하고 실제 소프트웨어 발표문과 유사할 수 있습니다.
환각은 여러 형태로 나타날 수 있습니다:
- 존재하지 않는 연구 논문 및 인용(citation).
- 라이브러리에서 지원되지 않는 프로그래밍 방법.
- 잘못된 역사적 날짜나 통계.
- 한 번도 구현된 적 없는 API 엔드포인트.
- 지원되지 않는 가정에 기반한 기술적 설명.
까다로운 점은 답변이 완전히 틀리지 않아도 위험할 수 있다는 것입니다. 단 하나의 조작된 세부 정보가 포함된 대체로 정확한 설명이라도 당신을 잘못된 방향으로 이끌 수 있습니다.
3. AI는 어떻게 그렇게 설득력 있게 잘못된 답을 내놓는가?
AI 모델은 일관되고 관련성 있는 응답을 생성하는 데 도움이 되는 패턴을 학습합니다. 그러나 유창한 언어를 생성할 수 있다는 능력이 사실적 정확성의 신뢰할 만한 척도를 자동으로 제공하지는 않습니다.
다음 두 가지 응답에 대해 생각해 보세요:
"이 방법이 존재하는 것 같지만, 제가 완전히 확신하지는 못합니다."
"이 방법은 지원되며 당신의 문제를 해결할 것입니다."
후자가 더 안심이 되는 것처럼 들립니다. 대부분의 사람들은 본능적으로 후자를 따르는 것이 더 편안하다고 느낄 것입니다.
하지만 단어 선택에 담긴 자신감이 주장의 정확성을 확립하지는 못합니다.
AI 시스템이 불확실성을 신뢰성 있게 표현하도록 특별히 설계되지 않았다면, 잘 뒷받침되는 정보와 의심스러운 가정에 대해 유사한 어조를 사용할 수 있습니다.
예를 들어, AI는 디버깅 과정의 네 단계를 정확하게 설명한 후 다섯 번째 단계에서 존재하지 않는 함수를 추천할 수 있습니다. 전체 답변이 동일하고 세련된 스타일로 제시되기 때문에, 부정확한 부분이 쉽게 눈에 띄지 않을 수 있습니다.
이것이 바로 우리가 두 가지를 분리해야 하는 이유입니다:
- 유창성 (Fluency): 답변이 얼마나 명확하고 자연스럽게 작성되었는지.
- 정확성 (Accuracy): 답변이 실제로 올바른지 여부.
답변은 첫 번째 항목에서 높은 점수를 받을 수 있지만, 두 번째 항목을 충족하지 못할 수도 있습니다.
4. AI 환각(Hallucinations)은 어떻게 발생하는가
환각 현상은 모델이 관련 지식이 전혀 없어서 항상 발생하는 것은 아닙니다. 때로는 모델이 관련된 패턴을 학습했지만 특정 질문에 정확하게 답하기에 충분한 신뢰할 수 있는 정보가 부족할 때 발생합니다.
모델은 이 격차를 신뢰성 있게 식별하는 대신, 문맥에 맞는 응답을 생성할 수 있습니다.
질문이 잘못된 가정을 포함하거나 사용 가능한 정보로 뒷받침되지 않는 매우 구체적인 세부 사항을 요청할 때 어떤 일이 발생할 수인지 고려해 보세요.
단순화된 환각 흐름
User Question
↓
Insufficient Reliable Information
...
이것은 모든 AI 모델에 뒤따르는 문자 그대로의 순서라기보다는 개념적인 설명입니다.
핵심 문제는 그럴듯함(plausibility)과 진실(truth)이 같지 않다는 것입니다. 답변은 증거로 뒷받침되지 않더라도 우리가 예상하는 답변과 유사할 수 있습니다.
이는 모호한 기술적 기능, 생소한 연구, 또는 신뢰할 수 있는 정보를 찾기 어려운 사건에 대해 질문할 때 특히 중요해집니다.
5. 오래된 정보 또한 오해를 불러일으킬 수 있다
모든 부정확한 AI 답변이 꾸며낸 것은 아닙니다. 때로는 한때는 정확했지만 더 이상 관련성이 없는 경우도 있습니다.
소프트웨어 프레임워크는 끊임없이 변화합니다. API가 진화하고, 함수가 사용 중단(deprecated)되며, 구성 형식이 바뀌고, 권장되는 접근 방식이 업데이트됩니다.
AI 모델은 사용자가 최신 버전을 사용하고 있음에도 불구하고 구 버전의 문서를 기반으로 해결책을 제시할 수 있습니다.
Next.js 애플리케이션에 대한 도움을 요청한다고 상상해 보세요. AI가 이전 버전에서 작동했던 설정이나 데이터 가져오기(data-fetching) 방식을 추천하지만, 이는 현재 사용 중인 환경에는 맞지 않습니다.
코드를 복사하여 애플리케이션을 재시작하고 오류를 마주칩니다.
좌절스러운 부분은 코드가 완전히 합리적으로 보일 수 있다는 점입니다. 심지어 다른 프로젝트에서는 완벽하게 작동했을 수도 있습니다.
이러한 문제는 클라우드 플랫폼, 보안 취약점, 제품 가격 책정, 회사 정책 등에도 동일하게 적용됩니다.
답변이 현재 정보에 의존하는 경우, AI가 최신 세부 정보를 가지고 있다고 가정하기보다는 관련 공식 문서를 확인해야 합니다.
6. 왜 AI가 생성한 코드는 완벽해 보이지만 여전히 실패할 수 있는가
개발자에게 이는 가장 흔하게 접하는 문제 중 하나입니다.
AI에게 기능을 구현하도록 요청합니다. AI는 깔끔한 코드와 합리적인 변수 이름을 사용하고, 모든 것이 어떻게 작동하는지 설명하는 주석을 추가하며 코드를 생성합니다.
사용자는 그것을 보고 '이거 맞는 것 같은데'라고 생각합니다.
그리고 실행해 봅니다.
임포트(import)가 실패하거나, 함수가 잘못된 데이터 타입을 받거나, API 응답 구조가 예상되는 구조와 일치하지 않습니다. 또는 기능은 초기 테스트 중에는 작동하지만 여러 요청이 동시에 발생할 때 깨집니다.
코드를 작성하는 것은 익숙한 구문(syntax)을 따르는 것 이상의 것을 포함합니다. 작동하는 구현체는 요구 사항을 충족하고, 유효한 API를 사용하며, 런타임 환경(runtime environment)을 고려하고, 예상치 못한 상황을 처리해야 합니다.
사용자 프로필을 가져오는 함수를 생각해 봅시다. AI가 성공적인 API 요청은 생성할 수 있지만, 만료된 인증 토큰(authentication token)을 처리하는 것을 잊을 수도 있습니다.
첫 번째 테스트 중에는 모든 것이 작동합니다. 나중에 사용자의 세션이 만료되고 애플리케이션은 프로필을 올바르게 로드하지 못하고 실패합니다.
구현 자체가 반드시 쓸모없었던 것은 아닙니다. 단지 처리해야 할 조건에 대해 불완전했을 뿐입니다.
생성된 코드에서 신뢰할 수 있는 구현체로
개발자 요구사항 (Developer Requirements)
↓
AI 생성 코드 (AI-Generated Code)
...
생성된 코드를 완성된 결과물로 여기지 말고, 시작점으로 취급하세요. 검토하고, 실행해 보고, 엣지 케이스(edge cases)를 테스트하며, 자신이 배포하는 것이 무엇인지 이해해야 합니다.
AI는 개발 속도를 높일 수 있지만, 엔지니어링 판단의 필요성을 없앨 수는 없습니다.
7. 때로는 문제가 질문 자체에 있습니다 (Sometimes, the Problem Is the Question)
실망스러운 답변이 항상 모델이 정보를 지어내서 발생하는 것은 아닙니다. 때로는 질문 자체가 해석할 여지를 너무 많이 남겨둡니다.
다음과 같이 질문하는 것을 고려해 보세요:
"가장 좋은 데이터베이스는 무엇인가요?"
만능으로 맞는 답변은 없습니다.
PostgreSQL은 관계형 데이터와 복잡한 쿼리가 필요한 애플리케이션에 강력한 선택일 수 있습니다. MongoDB는 유연한 데이터 구조를 가진 문서 지향(document-oriented) 애플리케이션에 적합할 수 있습니다. Redis는 캐싱 및 기타 낮은 지연 시간(low-latency)의 데이터 접근 패턴에 적합할 수 있습니다.
올바른 선택은 해결하려는 문제에 달려 있습니다.
디버깅도 마찬가지입니다. 관련 코드, 프레임워크 버전 또는 환경 정보 없이 오류 메시지만 제공한다면, AI는 추측을 해야 합니다.
어떤 추측은 합리적일 것입니다. 다른 것들은 틀릴 것입니다.
"제 API가 왜 작동하지 않나요?"라고 묻기보다는, 엔드포인트(endpoint), 요청 메서드(request method), 응답 상태(response status), 관련 코드, 그리고 이미 시도해 본 내용을 함께 제공하세요.
AI에게 솔루션을 제안하기 전에 누락된 정보를 식별하도록 요청할 수도 있습니다.
더 나은 컨텍스트가 정확한 답변을 보장하지는 않지만, AI가 추측해야 할 항목의 수를 줄여줍니다.
8. AI 답변이 정확한지 어떻게 확인할 수 있나요? (How Can You Check Whether an AI Answer Is Correct?)
모든 응답이 정확함을 보장하는 단 하나의 비법은 없습니다. 하지만 몇 가지 실용적인 습관을 들이면 AI 지원 작업의 신뢰도를 훨씬 높일 수 있습니다.
원 출처를 확인하세요 (Check the original source).
만약 답변에서 특정 API, 연구 논문(research paper), 또는 프레임워크 기능에 대해 언급한다면, 공식 문서나 원본 간행물에서 찾아보세요.
**증거를 요청하세요 (Ask for evidence).
중요한 사실적 주장에 대한 출처를 요청하되, 그 출처는 직접 열어 확인해야 합니다. AI가 생성한 인용문 역시 조작되었거나 관련성이 없을 수 있습니다.
제시된 내용의 발표 방식이 아니라 주장 자체를 검증하세요.
코드의 경우, 구현을 실행하고 현실적인 엣지 케이스(edge cases)를 테스트해야 합니다. 사실적 주장의 경우, 신뢰할 수 있는 독립적인 증거를 찾아보세요.
익숙하지 않은 세부 사항을 조사하세요.
스스로 독립적으로 인지할 수 없는 함수, 통계, 또는 기술적 세부 사항에 특히 주의를 기울이세요. 익숙한 설명은 관련성이 낮은 주장을 과도하게 신뢰할 만하게 보이게 할 수 있습니다.
검증이 중요할 때는 도구를 사용하세요.
외부 검색(External search), 문서 검색(documentation retrieval), 코드 실행, 그리고 자동화된 테스트는 답변의 문구만으로는 알 수 없는 증거를 제공할 수 있습니다.
목표는 영원히 모든 문장을 의심하는 것이 아닙니다. 행동에 옮기기 전에 어떤 주장이 확인이 필요한지 아는 것입니다.
9. AI 답변 검증을 위한 실용적인 워크플로우
검증이 중요하다는 것을 아는 것은 유용합니다. 반복 가능한 프로세스를 갖추면 일상 업무에서 그 지식을 적용하기가 더 쉬워집니다.
만약 AI가 프로덕션 버그(production bug)에 대한 해결책을 제시했다고 가정해 봅시다. 코드를 즉시 복사하는 대신, 몇 가지 확인 과정을 거쳐야 합니다.
간단한 검증 워크플로우
프로그래밍 작업의 경우, 메서드가 존재하는지 확인하거나, 매개변수가 올바른지 확인하고, 코드를 로컬에서 실행하며, 실패 시나리오를 테스트하는 것을 의미할 수 있습니다.
연구 작업의 경우, 원본 출처를 열어 그것이 실제로 AI의 주장을 뒷받침하는지 확인하는 것을 의미할 수 있습니다.
프레임워크 업그레이드의 경우, 제안된 해결책을 현재 사용 중인 버전의 마이그레이션 가이드(migration guide)와 비교하는 것을 의미할 수 있습니다.
이러한 접근 방식이 모든 실수를 잡아낸다는 것을 보장하지는 않지만, 맹목적인 신뢰를 할 가능성을 낮춥니다.
10. 더 나은 프롬프트가 AI의 실수를 줄일까요?
네, 더 나은 프롬프트가 도움이 될 수 있지만, 환각(hallucinations)을 완전히 제거할 수는 없습니다.
모호한 프롬프트(vague prompt)는 모델이 제공되지 않았을 수 있는 세부 사항들을 추론하도록 강요합니다. 반면, 구체적인 프롬프트(specific prompt)는 더 많은 맥락을 제공하여 응답이 사용자의 요구사항을 충족하는지 평가하기 쉽게 만듭니다.
두 요청을 비교해 보세요.
모호한 프롬프트:
"제 인증 코드를 수정해주세요."
더 유용한 프롬프트:
"저는 Next.js의 App Router 프로젝트를 사용하고 있습니다. 로컬 환경에서는 인증이 작동하지만, 배포 후 세션이 사라집니다. 관련 코드와 오류 메시지를 여기에 첨부합니다. 가능한 원인을 파악하고, 가정한 내용을 설명하며, 제 설정에 맞는 해결책을 제시해 주세요. 만약 제공된 정보만으로는 원인을 판단할 수 없다면, 제가 무엇을 더 알려드려야 하는지 말씀해주세요."
두 번째 프롬프트는 맥락을 제공하고, 문제를 정의하며, AI에게 불확실성을 식별하도록 요청합니다.