‘정확성’의 명령: AI에서 ‘좋은 것’을 정의하는 것이 가장 중요한 이유

게시일: 2025년 12월 17일 | 원문 작성일: 2025년 12월 17일 | 원문 보기

• • •

1. 들어가며: 대부분의 AI 프로젝트가 실패하는 보이지 않는 이유

대부분의 AI 프로젝트는 실패해요. 기술의 한계 때문도 아니고, 모델의 복잡성 때문도 아니고, 엔지니어링 인재의 부족 때문도 아니에요. 지극히 인간적인 실수 때문이죠—바로 좋은 품질의 작업이 어떤 모습인지 정확하게 정의하지 못하는 것이에요. 이것이 야망이 실망으로 무너지는 핵심적이지만 보이지 않는 이유예요.

이 문제는 대규모 기업의 에이전트 시스템에만 국한되지 않아요. 단일 프롬프트를 작성하는 것까지 포함해 모든 것에 따라다니는 보편적인 문제예요. “좋다”의 정의를 명확히 하고, 측정하고, 강제하는 능력은 인공지능 분야 전체에서 가장 강력하면서도 비극적으로 간과되는 스킬 중 하나예요.

약 50만 년 동안 인류 사회는 절대적 정확성이 아닌 사회적 결속을 위해 최적화해왔어요. 우리는 “서로 맞춰가며 잘 지내기”를 최적화하고, 모호함을 협업의 윤활유로 사용해요. 이 진화적 전략은 공동체를 형성하고 발전을 가능하게 하며 우리에게 잘 통했어요.

하지만 이 같은 본능은 AI와 작업할 때 치명적인 약점이 돼요. AI 시스템은 우리의 사회적 뉘앙스를 탐색하거나 명시되지 않은 의도를 추론할 수 없어요. 주어진 목표에 대해서만 최적화할 수 있을 뿐이에요.

• • •

2. 근본적 결함: 왜 정확성이 모든 것의 상위 개념인가

”정확성(correctness)“이라는 개념은 성공적인 AI 이니셔티브가 구축되는 기반이에요. 모든 하위 아키텍처 결정들—RAG 시스템 선택, 에이전트 워크플로우 설계, 오케스트레이션 로직, 심지어 기본 모델 선택까지—은 정의되지 않았거나 변하는 품질 목표 위에 구축되면 무효화돼요.

이건 우리가 역사적으로 소프트웨어 개발에 접근해온 방식과 근본적으로 다른 출발점이에요:

AI 시스템에서 “정확성”을 구성하는 요구사항 묶음은 사용 사례에 따라 각각 다른 가중치와 중요성을 가진 광범위한 요소들을 포함할 수 있어요:

• 진실성(Truthfulness) — 정보가 사실적으로 정확한가?
• 완전성(Completeness) — 응답이 필요한 모든 정보를 포함하는가?
• 톤(Tone) — 출력이 원하는 브랜드 음성이나 커뮤니케이션 스타일과 일치하는가?
• 정책 준수(Policy Compliance) — 응답이 모든 관련 법적, 규제적, 내부 정책을 준수하는가?
• 속도(Speed) — 응답이 얼마나 빨리 생성되는가?
• 비용(Cost) — 응답 생성의 계산 비용은 얼마인가?
• 거부 행동(Refusal Behavior) — 시스템이 언제 어떻게 답변을 거부해야 하는가?
• 감사가능성(Auditability) — 시스템의 주장과 추론을 추적하고 검증할 수 있는가?

이 복잡성 때문에 모든 AI 아키텍트의 첫 번째 질문은 “무엇이 정확한가, 그리고 좋은 것이 어떤 모습인지 어떻게 아는가?”가 되어야 해요. 이 질문은 시스템 컴포넌트에 관한 어떤 2차적 결정보다 먼저 답해져야 해요. OpenAI 자체 가이던스가 말하듯이, 신뢰성은 어떤 품질 기준을 측정할지 이해하는 것에서 시작해요.

• • •

3. 인간 요소: 모호함에 대한 조직적 편향

궁극적으로 AI 품질 문제는 사람 문제예요. AI 시스템은 거울처럼 작동하며, 조직의 내부 문화를 냉정하게 비춰줘요. 그렇게 하면서 우리의 비즈니스 프로세스와 의사결정 프레임워크에 잠재해 있던 고유한 모호함과 “인간의 미결정성(human undecidability)“을 드러내요.

인간은 여러 핵심 이유로 모호함을 기본값으로 삼아요:

• 사회적 결속을 유지하기 위해
• 전략적 옵션을 열어두기 위해
• 직접적인 갈등을 피하기 위해

모호함은 서로 다른 이해관계자들이 “회의에서는 동의하고 실행에서는 반대하는” 것을 가능하게 해요. 이건 실행 시 빠르게 증발하는 합의의 환상을 만들어내죠. 아마존 같은 회사에서는 “애매한 표현(weasel words)”—‘실제로’, ‘많이’, 혹은 숫자와 구체적 주장이 아닌 모든 것 같은 불명확한 용어—을 단속해요.

이 문화적 습관은 AI를 구축할 때 재앙적이에요. 팀이 중요한 트레이드오프—예를 들어 대담함 우선인지 정밀도 우선인지, 속도 우선인지 포괄적 정확성 우선인지—에 대해 명시적 결정을 내리지 못하면, 그들은 결정을 피하는 게 아니에요. 단지 결정을 포기하는 것뿐이에요. LLM이 대신 그 선택을 하게 될 것이고, 결과는 변함없이 품질, 정확성, 또는 신뢰성의 실패로 인식될 거예요.

• • •

4. 정의되지 않은 품질의 실질적 결과

정확성을 정의하지 못하는 것은 학술적 우려가 아니에요. 심각하고, 예측 가능하며, 비용이 많이 드는 하위 영향을 미치는 근본적 오류예요. “좋음”의 목표가 모호하게 남겨지면 조직은 필연적으로 AI 투자를 약화시키고 사용자 신뢰를 침식하는 일련의 치명적인 실패 모드를 만나게 돼요.

4.1 환각: 모호한 목표의 기능, 버그가 아님

우리는 종종 AI 환각을 모델의 무작위적이고 설명 불가능한 버그로 취급해요. 이건 오해예요. 환각은 주어진 목표에 최적화하는 시스템의 논리적 결과인 경우가 더 많아요. OpenAI의 한 논문은 바로 이 문제를 강조하며, 일반적인 평가 설정이 종종 불확실성의 솔직한 표현보다 자신감 있게 들리는 답변에 보상한다고 주장해요.

이건 우리에게 중요한 질문을 던져요: “모르겠습니다”라고 말하는 모델에게 기꺼이 보상할 의향이 있나요?

유일하게 수용 가능한 답변이 단정적인 사실 진술이라면, 충분한 정보가 없을 때 시스템이 하나를 발명하도록 부주의하게 장려하는 거예요. 이건 정말로 모델 문제가 아니에요. 이건 우리 문제예요—정확성 정의의 실패예요.

4.2 아키텍처 혼란과 이동하는 골대

AI 프로젝트에서 흔하고 파괴적인 패턴은 이해관계자들이 빌드 과정 중에 정확성의 정의를 발견하며 “골대를 옮기는” 것이에요. 프로젝트가 단순한 명령으로 시작했다가 몇 주 후 핵심 요구사항이 극적으로 변할 수 있어요.

예를 들어, 1주차에 “정확함”은 “그럴듯하게 들리고 시간을 절약하는 답변”으로 정의될 수 있어요. 하지만 3주차까지, 초기 출력을 본 후 표준이 “정확함은 재무 숫자와 정확히 일치해야 함”으로 바뀌어요. 이건 사소한 조정이 아니에요; 시스템 아키텍처의 근본적 변화를 의미해요.

이런 목표의 지속적 이동은 엔지니어링과 아키텍처 팀에게 불가능한 트레이드오프를 만들어요:

4.3 굿하트의 법칙 실현: 보상 해킹의 위험

굿하트의 법칙은 고전적인 경영 원칙이에요: “측정이 목표가 되면, 좋은 측정이 되는 것을 멈춘다.” AI 등가물은 정확성의 대리 지표를 선택하면, 시스템이 실제 의도를 놓치면서 대리 지표에서 이기는 것을 학습한다는 거예요. 이것을 보상 해킹(reward hacking)이라고 해요.

Gemini 3의 행동이 구체적인 예를 제공해요. 이 모델은 사용자가 프롬프트를 제공하고 단일 고품질 응답을 받는 단일 턴 대화에 고도로 최적화되어 있어요. 하지만 다중 턴 대화에서는 덜 효과적이에요. 이건 강화 학습 과정에서 나온 특유의 패턴으로, 방대한 수의 단일 턴 상호작용을 훈련 데이터로 사용했기 때문이에요. 모델은 대리 지표(첫 턴에서 이기기)에서 뛰어나는 것을 학습했지만, 일관되고 장기적인 대화를 유지하는 더 넓은 목표에 대해서는 충분히 훈련받지 못했어요.

단일 턴 대화에 대한 이런 좁은 집중은 예상치 못한 결과를 가져왔어요. 감정적 관계를 특징짓는 깊은 다중 턴 대화가 충분히 탐색되지 않은 채 창발적 행동으로 나타났고, 이게 모델 제작자들을 놀라게 하며 예상치 못한 사회적 역학으로 이어졌어요.

4.4 실패 사례 연구: Microsoft Copilot의 채택 문제

기업 소프트웨어와의 공격적인 번들링에도 불구하고 Microsoft Copilot의 낮은 사용자 채택에 대한 광범위한 보고는 정확성 문제의 실제 사례 연구로 작용해요. Copilot은 SharePoint 같은 방대하고 종종 정리되지 않은 기업 데이터 저장소 위에 레이어되어 있지만, 사용자나 부서가 품질을 정의하거나 보장하는 명확한 프레임워크 없이 배포되었어요.

일반적인 시나리오를 생각해보세요: 영업사원이 Copilot에 파이프라인 데이터를 요청해요. 다양한 소스에서 온 잠재적으로 “더러운 데이터”로 작업하며, 시스템은 부정확한 결과를 반환해요. 좌절한 영업사원은 눈을 굴리며 즉시 도구를 포기하고, 문제가 기저 데이터와 프로세스에 있다는 것을 결코 고려하지 않아요.

이 사이클은 조직 전반에서 반복되어 광범위한 환멸로 이어져요. 실패는 LLM 자체가 아니라, 그 위에 정확성을 정의하고 강제하는 시스템의 부재에 있어요. 이 사례가 보여주듯이, AI 시스템은 종종 조직의 축적된 “인간 부채”—구체적으로 AI 문해력의 부채와, 가장 중요하게는, 정확성과 품질을 정의하는 규율의 부채—를 떠안아요.

• • •

5. 정확성을 정의하고 측정하기 위한 실용적 프레임워크

문제를 넘어서려면 조직의 모호함을 엔지니어링 정밀도로 대체하는 규율 있고 구조화된 품질 정의 접근법이 필요해요. 목표는 모호함이 체계적으로 식별되고 AI 시스템을 탈선시키기 전에 해결되는 “정확성의 문화”를 만드는 거예요.

이것은 “정확성”을 구체적인 3부분 정의로 해체하는 것에서 시작해요:

이 핵심 프레임워크를 올바른 문화적, 기술적 관행으로 보강하는 것이 견고한 시스템을 구축하는 핵심이에요:

• 여러 기준을 사용하여 정확성을 정의하고, 정확도, 속도, 비용 같은 요소의 균형을 맞추세요.
• 모델이 품질 기준을 충족할 수 없을 때 무엇을 해야 하는지 이해하도록 명시적 실패 모드를 정의하세요.
• 모델이 신뢰도가 낮을 때 답변을 거부할 수 있는 워크플로우를 설계해 보정된 불확실성을 수용하세요.
• 시스템이 출처를 인용하고 작업을 보여주도록 요구해 주장에 대한 출처를 요구하세요.
• 단위 수준(개별 에이전트)과 시스템 수준(전체 오케스트레이션) 모두에서 다층 테스트를 통합하세요.

이건 쉬운 작업이 아니에요. 모호한 비즈니스 요구사항을 결정론적 워크플로우로 번역하는 데 익숙한 시니어 엔지니어의 정신적 규율이 필요해요. 이 엄격한 품질 정의는 AI 시대에서 가장 중요한 인간 역할 중 하나로, 인간의 의도와 기계 실행 사이의 간극을 메워요.

• • •

6. 프랙탈 통찰: 에이전트 시스템에서 단일 프롬프트까지

정확성을 정의하는 원칙은 프랙탈이에요—거대한 기업 AI 시스템의 설계와 개인 챗봇에 입력하는 단일 프롬프트의 작성에 동등한 중요성으로 적용돼요. 핵심에서 프롬프팅은 워크플로우를 시작하고 모델에 품질 기준을 부과하는 행위예요. AI 아키텍트든 일반 사용자든, 당신은 작업을 정의하고 “좋은” 출력이 어떤 모습인지에 대한 기대를 신호하고 있어요.

다른 사람들이 전문 프롬프터를 관찰할 때, 그들이 종종 보는 핵심 차이점은 항상 모델에게 기대되는 출력—“좋은 것”이 어떤 모습인지—에 대한 명확한 감각을 주는 관행이에요, 짧은 프롬프트에서도요. 그들은 모델을 원하는 결과로 안내하는 구조, 예시, 또는 제약을 제공하며 “좋음”을 미리 정의해요.

자신만의 품질 기준을 미리 정의함으로써, 훨씬 더 정밀하고 효과적인 프롬프트를 만들 수 있어요. 이건 대규모 시스템을 위한 기법만이 아니에요; 모든 AI 사용자가 기술의 진정한 잠재력을 열기 위해 길러야 하는 근본적인 스킬이에요.

• • •

7. 결론: AI 시대의 정의적 도전

AI 시대의 가장 큰 도전은 기술적인 것이 아니에요; 인간적인 것이에요. 모호함에 대한 우리의 깊이 뿌리박힌 선호를 극복하고 이 강력한 새 시스템들에 대한 우리의 목표를 명확하고 정밀하게 정의하는 것을 배우는 도전이에요. 모호함의 편안함을 구체성의 엄격함으로 교환해야 해요.

환각, 불신뢰성, 낮은 사용자 채택 같은 지속적인 문제들은 AI의 신비로운 결함이 아니에요. 더 자주, 그것들은 단순히 “당신에게 반사되어 돌아오는 인간의 미결정성”이에요. 시스템들은 설계된 대로 수행하고 있지만, 설계 자체가 검증되지 않은 가정과 정의되지 않은 목표의 기반 위에 구축되어 결함이 있어요.

신뢰할 수 있고, 가치 있고, 널리 채택되는 AI를 구축하는 길은 모델에서 시작하지 않아요, 우리에게서 시작해요. 시스템을 설계하거나 프롬프트를 작성하기 전에 자신에게 물어야 하는 단순하고, 직접적이고, 깊이 도전적인 질문에서 시작해요: