AI가 오작동하는 것처럼 보이는 이유

개요:

이 글은 AI 비서 및 관련 AI 시스템이 왜 오작동하는 것처럼 보이는지 이해하는 것에 관한 것입니다. 이 글은 의미론적 이해(semantic understanding)가 신뢰할 수 있는 지침 준수를 보장하지 않는 이유를 설명합니다. 또한 중요한 제약 조건과 사실적 요구 사항을 어떻게 더 신뢰성 있게 강제할 수 있는지 검토합니다. AI 시스템을 사용할 때 현실적인 기대를 설정하는 데 대한 지침을 제공합니다.

키워드: AI 비서, 대규모 언어 모델(LLMs), 지침 준수(instruction-following), 제약 조건(constraints), 행동 정렬(behavioral alignment), 의미론(semantics), 이해(understanding), 행동(behavior), 소프트웨어 엔지니어링, 불변성(invariants), 에이전트 추출 파이프라인(agentic extraction pipelines), 검색 증강 생성(RAG), 도구 사용(tool use)

이해 대 행동:

의미론적 능력은 신뢰할 수 있는 지침 준수를 보장하지 않습니다.

현대 AI 비서와 관련된 가장 이상한 경험 중 하나는 인간에게 거의 사소할 정도의 지침을 수행하는 데 실패하는 것을 보는 것입니다. 간단한 요청을 고려해 봅시다: "이 프로그래밍 스크립트를 검토하되, 기존 주석은 그대로 두세요." 지침은 명확합니다. 모호함이 거의 없습니다. 인간 프로그래머는 일반적으로 경계를 즉시 이해할 것입니다: "코드를 검토하거나 수정하되, 기존 주석은 읽기 전용으로 취급하세요." 하지만 AI 비서는 그 지침을 인지하고, 자신이 이해했음을 명시적으로 확인한 다음, 결국 주석을 수정하는 방식으로 진행할 수 있습니다. 그렇다면 왜 이런 일이 발생할까요?

문제는 반드시 AI가 단어를 이해하지 못해서는 아닙니다. 현대 LLMs는 어휘, 문맥 및 많은 형태의 자연어 의미를 높은 수준에서 처리할 수 있습니다. 그들의 언어 해석 능력은 여러 영역에 걸쳐 상당히 향상되었지만, 성능은 여전히 고르지 않으며 특히 모호하거나 전문적이거나 위험도가 높은 작업의 경우 더욱 그렇습니다. 더 깊은 문제는 지침을 이해하는 것과 그것을 신뢰성 있게 강제하는 것은 매우 다른 두 가지라는 것입니다. 모델은 요청을 이해할 수 있지만 사용자가 의도한 목표를 충족하지 못하는 방식으로 여전히 응답할 수 있습니다.

이는 LLM이 제약 조건을 표현하거나 따를 수 없다는 것을 의미하지는 않습니다. 지시사항 준수(Instruction following)는 최신 모델들이 수행하도록 특별히 훈련된 역량입니다. 문제는 신뢰성(reliability)에 있습니다. 모델은 여러 예제에 걸쳐 제약 조건을 성공적으로 따를 수 있지만, 기존 소프트웨어가 제공할 수 있는 종류의 결정론적 보장(deterministic guarantee)을 제공하지는 못합니다.

따라서 중요한 구분점은 모델이 확률적으로 수행할 수 있는 역량과 주변 시스템이 모델과 독립적으로 강제할 수 있는 보장 사이입니다.

학습된 행동 대 명시적 제약 조건:

AI 어시스턴트의 행동은 학습된 파라미터, 사후 훈련(post-training), 현재 컨텍스트, 그리고 주변 시스템이 제공하는 지침 및 제약 조건에 의해 형성됩니다. 이는 기본적으로 기존 소프트웨어가 제공할 수 있는 것과 같은 종류의 명시적이고 외부에서 검증 가능한 제약 메커니즘을 제공하지는 않습니다. 예를 들어, 문서의 일부 부분이 프로그램적으로 불변(immutable)으로, 다른 부분은 편집 가능(editable)하도록 표시되는 형태가 있습니다.

모델에게 코드를 개선하라고 요청받았을 때, 모델은 코드 개선과 문서화, 포맷팅, 주석 추가를 연관 짓는 강력한 패턴을 학습했을 수 있습니다. 이러한 학습된 경향성은 때때로 명시적인 사용자 제약 조건과 충돌할 수 있습니다.

다음 상호작용을 고려해 보세요:

AI 어시스턴트: _"사용자님의 명시적 지침을 이해했습니다. 모든 주석은 변경하지 않겠습니다."

인간 사용자: _"좋습니다. 스크립트를 진행해서 수정해주세요."

AI 어시스턴트: 3.2초 동안 작동함

AI 어시스턴트: _"네, 업데이트된 프로그램입니다. 주석도 일부 변경하거나 제거했습니다."

위의 첫 번째 진술은 약속처럼 들립니다. 하지만 기술적으로 볼 때, 그 진술 자체는 모델에 의해 생성된 것입니다. 이는 모델이 현재 컨텍스트에서 지침을 표현했다는 증거일 뿐이며, 이후 출력물이 명시된 제약 조건을 만족할 것이라는 독립적인 보장은 아닙니다.

사람은 지침을 듣고 간단한 정신적 규칙을 세울 수 있습니다: 주석(comments) → 건드리지 않기; 코드(code) → 수정 가능.

언어 모델은 이러한 규칙을 컨텍스트에 표현할 수 있으며 성공적으로 따를 수도 있습니다. 하지만 최종 결과물은 모델의 추론 과정(inference process)을 통해 생성되며, 이때 지침은 학습된 매개변수와 현재 컨텍스트를 거쳐 간접적으로 표현됩니다. 그 과정 자체가 특정 제약 조건이 보존될 것이라는 결정론적(deterministic) 보장을 제공하지는 않습니다.

주변 소프트웨어가 독립적으로 강제하는 제한을 제공하지 않는 한, 모델이 수정된 파일을 생성할 때 주석을 보존할 것이라고 보장할 수 없습니다.

동일한 구분이 더 광범위하게 적용됩니다. 모델은 사용자가 원하는 바를 이해할 수 있지만, 다른 목표들이 그 행동에 영향을 미칠 수 있습니다. 안전 정책(Safety policies), 시스템 지침(system instructions), 제품 제약 조건(product constraints) 및 기타 최적화 목표들은 응답을 재지정할 수 있습니다. 플랫폼 수준의 정책은 명시된 사용자 의도와 독립적으로 작동할 수 있습니다. 제품 및 서비스 설계는 안전 요구 사항, 비용 제한, 속도 제한(rate limits), 기능 가용성 또는 워크플로우 요구 사항과 같이 즉각적인 작업 이상의 목표와 제약 조건을 도입할 수 있습니다.

제도적 설계 (Institutional design):

실제 모델의 행동은 사용자의 즉각적인 요청을 넘어선 여러 계층에 의해 형성됩니다.

1. 학습 데이터 + 미세 조정(fine-tuning)은 학습된 패턴과 선호도를 인코딩합니다:

학습 데이터는 사실적 정보, 관례, 편향성, 그리고 인간의 판단이 혼합되어 있습니다. 사후 훈련 과정은 유용성(helpfulness), 안전성(safety), 거부(refusal), 지침 준수와 같은 행동을 강화할 수 있습니다. 이러한 학습된 행동들은 모델 개발자가 내린 선택을 반영하며, 일반적으로 사용자 지침만으로는 대화마다 무효화될 수 없습니다.

2. 배포 제약 조건은 강제적인 운영 계층을 추가합니다:

사용량, 용량 또는 계정 수준 정책에 따라 접근을 제한하는 속도 제한(Rate limits)이 있을 수 있습니다. 기능 게이트(Feature gates)는 계정 등급, 제품 구성 또는 가용성을 기반으로 기능을 제한할 수 있습니다. 인증 요구 사항은 특정 서비스나 기능에 대한 접근이 필요할 때 워크플로우를 중단시킬 수 있습니다. 아키텍처 및 인프라 결정은 개별 대화 외부에서 확립됩니다.

3. 비즈니스 로직은 모든 표면적인 상호작용 아래에 존재합니다:

제품 설계는 사용자를 특정 워크플로우나 기능으로 유도할 수 있습니다. 상업적 결정은 다른 가격대에서 어떤 기능이 사용 가능한지를 결정합니다. 인프라 비용은 용량 제한, 모델 선택 및 사용 제한에 영향을 미칠 수 있습니다.

결국, 이것은 단순히 의미론적인 문제가 아니라 제도적이고 시스템적인 설계입니다. 조직적 결정과 제품 요구 사항은 사용자가 대화를 시작하기 전에 서비스 아키텍처에 통합될 수 있습니다. 상업적 로직은 사용자에게 노출되는 상호작용 아래에서 작동합니다. 안전 및 시스템 수준의 제약 조건은 사용자의 요청보다 우선하는 경계를 부과할 수 있습니다.

이러한 요인들이 반드시 사용자가 순간적으로 원하는 것과 일치하지는 않습니다. 문제는 단순히 모델이 요청을 이해하는지 여부가 아닙니다. 오히려, 훈련(training), 정책(policies), 제품 구성(product configuration) 및 운영 제약 조건(operational constraints)을 고려한 후에도 시스템의 실제 동작이 사용자의 목표와 여전히 정렬되어 있는가 하는 것입니다.

소프트 제약 조건 대 하드 제약 조건:

유용한 엔지니어링적 구분은 **소프트 제약 조건(soft constraints)**과 하드 제약 조건(hard constraints) 사이의 차이입니다.

프롬프트는 일반적으로 모델에게 제약 조건을 전달합니다. 모델은 그 제약 조건을 이해하고 따르려고 시도할 수 있지만, 준수 여부는 모델이 생성하는 동작의 일부로 남습니다.

반면, 유효성 검사기(validator), 스키마(schema), 권한 시스템(permission system), 트랜잭션 경계(transaction boundary) 또는 후처리 확인(post-processing check)은 모델과 독립적으로 제약 조건을 강제할 수 있습니다.

기존의 모든 주석을 보존하는 것이 필수적인 요구사항이라면, 시스템은 단순히 모델에게 주석을 보존하도록 요청해서는 안 됩니다. 대신 출력물이 그 요구사항을 충족하는지 검증해야 합니다.

AI 제약 조건에 대한 공학적 접근 방식:

점점 더 많은 지침을 추가하는 것이 답이 아닙니다.

"주석을 변경하지 마십시오. 주석을 의역하지 마십시오. 주석을 수정하지 마십시오. 주석의 형식을 재구성하지 마십시오. 주석을 제거하지 마십시오. 주석을 추가하지 마십시오. 기존 모든 주석의 모든 문자를 보존하십시오..."

이렇게 하는 것은 부담을 기계에서 인간에게로 옮기는 것입니다. 그것은 역행하는 방식입니다. 더 나은 공학적 접근 방식은 중요한 요구사항을 모델이 단순히 기억하도록 요청받는 약속이 아니라, _검증할 수 있는 불변 조건(invariants)_으로 취급하는 것입니다.

예를 들어, 코딩 시스템은 원래의 주석을 식별하고 AI가 실행 가능한 코드(executable code)를 수정하도록 허용한 다음, 결과로 나온 주석과 원본 주석을 자동으로 비교할 수 있습니다. 만약 어떤 주석이라도 변경되었다면, 시스템은 해당 수정을 거부하거나 되돌릴 수 있습니다. 사용자는 변호사처럼 코스프레하며 빈틈없는 계약서를 작성할 필요가 없습니다. 소프트웨어가 명백한 경계를 강제할 것입니다.

이 원칙은 코드 편집을 넘어 확장됩니다. 정확성이 데이터에 달려 있을 때, 워크플로우는 검색 및 검증(retrieval and validation) 기능을 독립적으로 테스트하고 검증할 수 있는 시스템으로 이동해야 합니다. 그러면 LLM은 문맥 제약 파싱(context-constrained parsing), 변환(transformation), 또는 해석(interpretation)과 같은 작업을 위해 사용될 수 있으며, 프로그램적 확인(programmatic checks)이 위반되어서는 안 되는 요구사항을 강제합니다. 이는 정확한 보존, 형식 지정, 데이터 무결성 또는 기타 엄격한 제약 조건이 중요한 경우 특히 중요합니다.

사실 기반 데이터 작업:

AI 비서는 데이터베이스가 아닙니다.

언어 생성과 권위 있는 데이터 검색을 구분하는 것 역시 중요합니다. 대규모 언어 모델(LLMs)은 학습된 패턴과 추론 시 제공되는 컨텍스트를 기반으로 텍스트를 생성하는 확률적 모델입니다. 이는 구조화된 검색 의미론을 제공하고, 시스템에 따라 트랜잭션 또는 일관성 보장(consistency guarantees)을 할 수 있는 기존 데이터베이스 시스템과는 다릅니다.

LLMs가 방대한 양의 사실 정보를 기억할 수는 있지만, 그 내부 지식은 구조화되거나 권위적이거나 일관되게 검증 가능한 데이터베이스가 아닙니다. 특히 정확한 날짜, 숫자, 인용구, 출처(citation) 또는 기타 세부적인 사실을 요청받았을 때 부정확하거나 조작된 세부 정보를 생성할 수 있습니다. 따라서 권위 있는 검색이 가능하고 정확성이 중요한 경우, 사용자는 AI 비서를 완벽한 구조화된 사실 데이터의 출처로 간주해서는 안 됩니다.

데이터베이스 역시 오류가 없다고 오해해서는 안 됩니다. 데이터베이스에는 부정확하거나 불완전하거나 오래된 데이터가 포함될 수 있습니다. 중요한 차이점은 데이터베이스가 언어 생성 과정과 독립적으로 그 동작과 결과를 테스트할 수 있는 명시적인 검색 메커니즘을 제공한다는 것입니다.

에이전트 추출 파이프라인 (Agentic extraction pipelines):

사실 기반 작업을 더 안정적으로 자동화하려면, 프로그램적 시스템이 소스 데이터를 검색하고 LLM이 컨텍스트로 제한된 구문 분석(parsing) 또는 변환에 사용되는 파이프라인을 구축하는 것이 더 나은 경우가 많습니다. 검색 증강 생성(Retrieval-Augmented Generation, RAG)은 외부 정보를 검색하여 모델에 컨텍스트로 제공하는 관련 아키텍처 중 하나입니다. '도구 사용(Tool use)'은 모델이 정보를 검색하거나 작업을 수행하기 위해 외부 시스템을 호출하는 더 광범위한 개념입니다. 두 접근 방식 모두 LLM 자체를 본질적으로 결정론적(deterministic)으로 만들지는 않지만, 모델에 사용할 수 있는 정보를 제한하고 중요한 검색 또는 검증 단계를 직접 테스트할 수 있는 시스템으로 옮길 수 있습니다.

검색(Retrieval) 역시 정확한 답변을 보장하지는 않습니다. 검색된 출처가 불완전하거나, 오래되었거나, 부정확할 수 있으며, 모델이 여전히 검색된 정보를 잘못 해석하거나 오용할 수도 있습니다. 장점은 검색과 검증 과정을 모델의 매개변수 메모리에 전적으로 의존하는 대신 독립적으로 테스트 가능한 구성 요소로 옮길 수 있다는 것입니다.

사실 추출(fact extraction)을 위해 견고한 파이프라인은 다음 구성 요소를 포함할 수 있습니다:

• 결정론적이거나 달리 독립적으로 테스트 가능한 검색 (deterministic or otherwise independently testable retrieval)
• 컨텍스트 제약형 구문 분석 (context-constrained parsing)
• 프로그래밍 방식 검증 계층 (programmatic verification layer)
• 필요한 경우 인간 개입을 위한 플래그 (flag for human intervention, if merited)

API를 사용하여 개별 노래 제목의 미국 발매일을 얻기 위한 추출 파이프라인의 예시: