🎯 Advanced · 수업 1 of 8

문제 먼저 정의하기

AI 시스템 구축은 기술 선택이 아닌 문제 분석에서 시작됩니다. 해결해야 할 것이 무엇인지 명확히 알지 못하면 어떤 모델도 도움이 되지 않습니다.

문제를 잘못 정의하면 어떤 AI 시스템도 성공할 수 있을까요?

2018년, IBM의 Watson for Oncology는 암 치료 추천 시스템으로 전 세계 병원에 도입되었습니다. 그러나 MD 앤더슨 암센터와의 협력은 6,200만 달러를 소모한 끝에 실패로 끝났습니다. 핵심 이유는 단순했습니다. IBM은 "의사들이 어떻게 결정을 내리는가"라는 실제 문제 대신, "방대한 의학 문헌에서 치료법을 추천하는 시스템을 만들자"는 기술 중심 문제를 풀었기 때문입니다. Watson은 가상의 환자 사례로 훈련되었지만 실제 전자의무기록(EMR)과는 연동되지 않았습니다. 결국 의사들은 시스템의 추천을 신뢰하지 않았고, 일부 추천은 의료 전문가들이 "안전하지 않다"고 판단할 정도였습니다.

이 사례는 AI 구축의 첫 번째 교훈을 담고 있습니다. 가장 정교한 모델도 잘못된 문제를 해결하면 실패합니다.

왜 문제 정의가 먼저인가

AI 프로젝트가 실패하는 가장 흔한 이유는 기술적 한계가 아닙니다. 잘못된 문제 정의입니다. 많은 팀이 "AI로 무언가를 만들자"는 목표에서 출발하지만, 진정한 질문은 "누가, 어떤 상황에서, 어떤 결정을 더 잘 내릴 수 있도록 도울 것인가"여야 합니다.

Watson 사례에서 보듯, 개발팀은 기술적으로 인상적인 시스템을 구축했습니다. 그러나 실제 임상 환경의 제약, 의사들의 의사결정 과정, 병원의 데이터 인프라를 충분히 이해하지 못했습니다. 문제를 사용자 중심으로 재정의했다면 완전히 다른 접근이 필요했을 것입니다.

좋은 문제 정의의 구성 요소

효과적인 AI 문제 정의는 다음 네 가지 요소를 명확히 해야 합니다.

  • 사용자 (Who): 이 시스템을 실제로 사용할 사람은 누구이며, 그들의 전문성과 맥락은 무엇인가?
  • 결정 (What): AI는 어떤 구체적인 결정을 지원하거나 자동화하는가?
  • 데이터 (How): 이 결정을 뒷받침할 수 있는 신뢰할 만한 데이터가 존재하는가?
  • 성공 기준 (Success): 시스템이 제대로 작동한다는 것을 어떻게 측정할 것인가?
핵심 원칙

AI를 도입하기 전에 "이 문제는 AI 없이도 일부 해결될 수 있는가?"를 물어보십시오. 만약 그렇다면, AI가 추가하는 가치가 명확해야 합니다. 기술을 위한 기술은 실패의 지름길입니다.

문제 정의 프레임워크: 5WHY + AI

도요타(Toyota)의 "5 Whys" 기법을 AI 문제 정의에 적용할 수 있습니다. 표면적 증상에서 시작해 다섯 번 "왜?"를 반복하면 근본 원인에 도달합니다. 그 근본 원인이 AI가 실제로 해결할 수 있는 것인지 판단하는 것이 출발점입니다.

예를 들어, "고객 응대 속도가 느리다"는 문제를 AI 챗봇으로 해결하려 할 때, 실제 근본 원인이 "FAQ가 정리되지 않아 상담원이 매번 같은 답변을 찾는다"라면 챗봇 전에 FAQ 데이터베이스 구축이 먼저입니다. AI는 잘 정의된 데이터와 프로세스 위에서만 효과를 발휘합니다.

📝 퀴즈 · 수업 1

문제 먼저 정의하기

수업에서 배운 내용을 확인해 보세요.

1. IBM Watson for Oncology 프로젝트가 실패한 주된 이유는 무엇이었나요?
✅ 정확합니다! Watson은 가상 사례로 훈련되었고 실제 전자의무기록과 연동되지 않았습니다. 기술이 아닌 문제 정의가 핵심 실패 원인이었습니다.
❌ 다시 생각해 보세요. 이 사례의 핵심은 기술적 한계가 아니라, 실제 사용자의 요구와 환경을 반영하지 못한 문제 정의에 있습니다.
2. 좋은 AI 문제 정의가 반드시 포함해야 하는 요소가 아닌 것은?
✅ 맞습니다! 경쟁사의 기술 스택은 문제 정의와 무관합니다. 문제 정의는 사용자, 결정, 데이터, 성공 기준에 집중해야 합니다.
❌ 틀렸습니다. 경쟁사가 사용하는 기술 스택 선택은 문제 정의 단계에서 고려해야 할 요소가 아닙니다.
3. "5 Whys" 기법을 AI 문제 정의에 적용하는 목적은 무엇인가요?
✅ 정확합니다! 5 Whys는 "왜?"를 반복해 근본 원인에 도달하게 합니다. 그 근본 원인이 AI로 해결 가능한지를 판단하는 것이 핵심입니다.
❌ 틀렸습니다. 5 Whys는 훈련 단계나 팀 구성 방법이 아닙니다. 근본 원인 분석 도구입니다.
🧪 실습 · 수업 1

문제 정의 워크숍

AI 튜터와 함께 실제 문제를 분석하고 올바른 AI 문제 정의를 연습합니다.

실습 안내

AI 튜터가 여러분에게 실제 조직이 직면한 문제 시나리오를 제시할 것입니다. 다음 단계를 따르세요:

  1. 제시된 시나리오에서 문제를 어떻게 정의할지 응답하세요.
  2. 사용자, 결정, 데이터, 성공 기준 네 가지 요소를 활용하세요.
  3. 5 Whys를 적용해 근본 원인을 탐색해 보세요.
추천 시작 문구: "시나리오를 주시면 문제를 정의해 보겠습니다."
🤖 AI 튜터 — 문제 정의 코치 수업 1 실습
🎯 Advanced · 수업 2 of 8

설계로서의 프롬프팅

프롬프트(prompt)는 단순한 질문이 아닙니다. AI 시스템의 동작을 규정하는 설계 결정입니다. 잘 설계된 프롬프트는 일관되고 예측 가능한 출력을 만들어 냅니다.

프롬프트 하나의 차이가 시스템 전체의 결과를 바꿀 수 있을까요?

2023년 2월, 뉴욕의 변호사 Steven Schwartz는 법정 제출 서류에 ChatGPT가 생성한 판례를 인용했습니다. 문제는 그 판례들이 모두 존재하지 않는 허구였다는 것입니다. Schwartz는 ChatGPT에게 "관련 항공사 책임 판례를 찾아줘"라고 요청했고, 모델은 신뢰감 있는 형식으로 가상의 판례를 생성했습니다. 연방 판사는 Schwartz와 그의 로펌에 5,000달러 벌금을 부과하고 공개 질책을 내렸습니다.

이 사건은 프롬프트 설계의 결정적 문제를 드러냅니다. "찾아줘"라는 프롬프트는 AI에게 검색 엔진처럼 작동하도록 암묵적으로 지시했지만, LLM(대규모 언어 모델)은 실제 검색을 수행하지 않습니다. 프롬프트가 AI의 역할과 한계를 명확히 정의하지 않으면, 시스템은 사용자가 기대하는 방식이 아닌 훈련 패턴을 따라 동작합니다.

프롬프트를 설계 결정으로 보기

AI 시스템을 구축할 때 프롬프트는 코드와 동등한 위상을 가집니다. 시스템 프롬프트(system prompt)는 모델의 역할, 제약, 응답 형식, 거부해야 할 요청의 유형을 정의합니다. 이것은 소프트웨어의 설계 문서와 같습니다.

좋은 프롬프트 설계는 단순히 "더 자세하게 설명하기"가 아닙니다. 모델이 해야 할 것과 하지 말아야 할 것, 불확실한 상황에서 어떻게 응답해야 할지를 명확히 규정하는 것입니다.

Schwartz 사건의 교훈

올바른 프롬프트 설계: "실제 법원 기록에서 검증된 판례만 인용하세요. 확신이 없으면 '이 판례를 직접 확인하십시오'라고 명시하세요." — 이러한 지시가 없었기에 모델은 그럴듯하게 들리는 판례를 생성했습니다.

효과적인 프롬프트 설계의 원칙

  • 역할 명시 (Role): 모델이 어떤 전문가 또는 에이전트로 행동해야 하는지 정의하세요.
  • 맥락 제공 (Context): 사용자가 누구이며 어떤 환경에서 사용하는지 알려주세요.
  • 제약 조건 (Constraints): 다루지 말아야 할 주제, 형식 요구사항, 길이 제한을 명시하세요.
  • 불확실성 처리 (Uncertainty): 모델이 모르거나 확신하지 못할 때 어떻게 응답해야 하는지 지시하세요.
  • 출력 형식 (Format): JSON, 목록, 단락 등 원하는 출력 형식을 구체적으로 지정하세요.

프롬프트 버전 관리와 반복

엔지니어가 코드를 버전 관리하듯, 프롬프트도 버전을 관리해야 합니다. 변경 사항, 변경 이유, 변경 후 성능 변화를 기록해야 합니다. Anthropic, OpenAI 등 주요 AI 기업들은 내부적으로 프롬프트 라이브러리와 테스트 스위트를 운영합니다.

프롬프트 설계는 일회성 작업이 아닙니다. 실제 사용 데이터를 통해 지속적으로 개선해야 하는 반복적 설계 과정입니다. 이 원칙은 소프트웨어 개발의 애자일(Agile) 방법론과 동일한 논리를 따릅니다.

📝 퀴즈 · 수업 2

설계로서의 프롬프팅

수업에서 배운 내용을 확인해 보세요.

1. Steven Schwartz 변호사 사건에서 프롬프트 설계의 핵심 문제는 무엇이었나요?
✅ 정확합니다! "찾아줘"라는 프롬프트는 AI의 한계를 고려하지 않았습니다. 불확실 시 "확인하세요"라고 응답하도록 지시했다면 결과는 달랐을 것입니다.
❌ 틀렸습니다. 핵심 문제는 프롬프트가 AI의 역할과 한계(허구 생성 위험)를 정의하지 않은 설계 실패입니다.
2. 시스템 프롬프트(system prompt)를 "소프트웨어의 설계 문서"에 비유하는 이유는?
✅ 맞습니다! 설계 문서가 시스템의 동작 규칙을 정의하듯, 시스템 프롬프트는 AI의 행동 방식을 규정합니다.
❌ 틀렸습니다. 시스템 프롬프트는 프로그래밍 언어가 아닌 자연어로 작성되지만, 모델의 동작을 정의하는 설계 역할을 합니다.
3. 프롬프트 버전 관리(version control)를 해야 하는 이유는?
✅ 정확합니다! 코드 버전 관리처럼, 프롬프트도 변경 기록을 관리해야 개선 과정을 체계적으로 추적할 수 있습니다.
❌ 틀렸습니다. 버전 관리의 목적은 변경 추적과 개선입니다. 저작권 보호나 잠금과는 관련이 없습니다.
🧪 실습 · 수업 2

프롬프트 설계 실습

AI 튜터와 함께 실제 시나리오에 맞는 시스템 프롬프트를 설계하고 개선합니다.

실습 안내

AI 튜터가 특정 AI 서비스 시나리오를 제시할 것입니다. 다음 단계를 따르세요:

  1. 제시된 시나리오를 위한 시스템 프롬프트 초안을 작성하세요.
  2. 역할, 맥락, 제약, 불확실성 처리, 출력 형식을 포함하세요.
  3. 튜터의 피드백을 바탕으로 프롬프트를 개선하세요.
추천 시작 문구: "시나리오를 주시면 시스템 프롬프트를 작성해 보겠습니다."
🤖 AI 튜터 — 프롬프트 설계 코치 수업 2 실습
🎯 Advanced · 수업 3 of 8

AI 출력 평가하기

AI가 생성한 출력을 어떻게 체계적으로 평가할 것인가는 시스템의 신뢰성을 결정합니다. 주관적 인상이 아닌 명확한 기준이 필요합니다.

AI 출력이 "좋다"는 것을 어떻게 객관적으로 측정할 수 있을까요?

2016년 Microsoft가 출시한 AI 챗봇 Tay는 트위터에서 16시간 만에 서비스를 중단해야 했습니다. Tay는 사용자와의 대화에서 학습하도록 설계되었는데, 일부 사용자들이 조직적으로 인종차별적·혐오적 발언을 반복 입력했고 Tay는 이를 그대로 재생산하기 시작했습니다. Microsoft는 출시 전 이러한 적대적 사용 패턴에 대한 평가 기준을 마련하지 않았습니다.

이 사건은 출력 평가 체계 부재가 얼마나 빠르게 심각한 피해로 이어질 수 있는지를 보여줍니다. 기술적으로 작동하는 시스템이 운용 환경에서 완전히 실패할 수 있습니다.

평가의 두 가지 차원

AI 출력 평가는 두 차원에서 이루어져야 합니다. 첫째는 품질(Quality)—출력이 정확하고, 관련성 있으며, 유용한가? 둘째는 안전성(Safety)—출력이 해롭거나 편향되거나 오해를 유발할 수 있는가?

Tay 사건은 품질 평가는 어느 정도 이루어졌지만 안전성 평가가 전혀 없었음을 보여줍니다. 두 차원이 모두 갖추어져야 신뢰할 수 있는 시스템이 됩니다.

평가 방법론

  • 자동화 평가 (Automated Eval): BLEU, ROUGE 같은 메트릭으로 출력의 언어적 품질을 측정합니다. 빠르지만 맥락 이해에는 한계가 있습니다.
  • 인간 평가 (Human Eval): 도메인 전문가 또는 실제 사용자가 출력을 직접 평가합니다. 더 정확하지만 비용이 높습니다.
  • AI-as-Judge: 다른 LLM이 출력을 평가하는 방식입니다. 확장성이 높지만 평가 모델 자체의 편향을 주의해야 합니다.
  • A/B 테스트: 실제 사용자 행동 데이터로 두 버전을 비교합니다. 가장 현실적이지만 배포 후에야 가능합니다.

평가 기준(Rubric) 설계

효과적인 평가를 위해서는 사전에 명확한 기준(rubric)이 필요합니다. 예를 들어 의료 AI의 경우: "임상적으로 정확한가 (1-5점)", "불확실성을 적절히 표현했는가 (예/아니오)", "과잉 확신을 피했는가 (예/아니오)"와 같은 기준을 미리 정의해야 합니다.

이러한 기준이 없으면 평가자마다 다른 판단을 내리게 되고, 평가 결과를 바탕으로 시스템을 개선하기가 어려워집니다. Tay의 경우, "적대적 입력에 대해 혐오 발언을 생성하지 않는가"라는 기준 하나만 있었어도 출시 전 심각한 결함을 발견할 수 있었을 것입니다.

📝 퀴즈 · 수업 3

AI 출력 평가하기

수업에서 배운 내용을 확인해 보세요.

1. Microsoft Tay 사건의 핵심 교훈은 무엇인가요?
✅ 정확합니다! Tay는 기술적으로 작동했지만 적대적 사용 패턴에 대한 안전성 평가가 없어 16시간 만에 서비스를 중단해야 했습니다.
❌ 틀렸습니다. Tay의 교훈은 품질과 안전성 두 차원의 평가가 모두 필요하다는 것입니다. 배포 환경 금지가 해결책이 아닙니다.
2. "AI-as-Judge" 평가 방법의 주요 한계는 무엇인가요?
✅ 맞습니다! AI-as-Judge는 확장성이 높지만, 평가 모델 자체의 편향이 평가 결과에 그대로 반영될 수 있다는 한계가 있습니다.
❌ 틀렸습니다. AI-as-Judge의 핵심 한계는 평가 모델 자체의 편향 문제입니다. 속도나 비용이 주된 문제가 아닙니다.
3. 평가 기준(rubric)을 사전에 정의해야 하는 이유는?
✅ 정확합니다! 명확한 기준이 없으면 평가가 일관성을 잃고, 개선 방향을 설정하기 어려워집니다.
❌ 틀렸습니다. 기준의 목적은 평가의 일관성과 개선 가능성에 있습니다. 훈련 속도나 법적 요건과는 다릅니다.
🧪 실습 · 수업 3

AI 출력 평가 기준 설계

AI 튜터와 함께 특정 AI 서비스의 평가 기준(rubric)을 설계하고 검토합니다.

실습 안내

AI 튜터가 특정 AI 서비스와 샘플 출력을 제시합니다. 다음 단계를 따르세요:

  1. 제시된 AI 서비스에 맞는 평가 기준(rubric) 3~5가지를 작성하세요.
  2. 품질과 안전성 두 차원을 모두 고려하세요.
  3. 샘플 출력을 작성한 기준으로 직접 평가해 보세요.
추천 시작 문구: "어떤 AI 서비스의 평가 기준을 설계할까요?"
🤖 AI 튜터 — 평가 기준 설계 코치 수업 3 실습
🎯 Advanced · 수업 4 of 8

인간-AI 워크플로 설계

AI가 모든 것을 대체하는 것이 아니라 인간의 판단력을 보완할 때 가장 효과적입니다. 어디에 인간을 배치하고 어디에 AI를 배치할지의 설계가 결과를 결정합니다.

어떤 결정은 AI에게, 어떤 결정은 인간에게 맡겨야 할까요?

2018년 3월, Uber의 자율주행 차량이 애리조나 주 템피에서 보행자 Elaine Herzberg를 치어 사망케 했습니다. 사고 조사에서 안전 운전자(safety driver) Rafaela Vasquez가 사고 전 6초 이상 휴대폰 화면을 보고 있었음이 밝혀졌습니다. Uber의 시스템은 자동 긴급 제동 기능을 비활성화한 상태였고, 안전 운전자에게 개입을 경고하는 기능이 불충분했습니다. 이 사고는 인간-AI 워크플로 설계 실패의 비극적 사례입니다.

기술이 "거의 준비된" 상태에서 인간 감독자의 역할을 명확히 정의하지 않으면, 인간과 AI 모두 제대로 기능하지 못하는 위험 영역이 발생합니다. 이를 "자동화 역설(automation paradox)"이라고 부릅니다.

자동화 스펙트럼

인간-AI 협업에는 자동화 수준에 따른 스펙트럼이 존재합니다. 완전 수동(인간이 모든 것을 결정)부터 완전 자동(AI가 모든 것을 결정)까지의 범위에서, 대부분의 효과적인 시스템은 중간 어딘가에 위치합니다.

  • AI 보조 (AI-Assisted): AI가 선택지를 제안하고 인간이 최종 결정. (예: 이메일 스팸 필터 후 인간 검토)
  • AI 주도, 인간 감독 (AI-Led, Human-Supervised): AI가 결정하되 인간이 예외 사례를 처리. (예: 자동 대출 심사 + 경계 사례 인간 검토)
  • 완전 자동화 (Fully Automated): 인간 개입 없이 AI가 전체 프로세스 처리. 고위험 영역에서는 위험합니다.

자동화 역설과 의미 있는 인간 통제

Uber 사고는 "자동화 역설"을 명확히 보여줍니다. 시스템이 매우 자동화될수록 인간 감독자는 단조롭고 수동적인 역할에 지쳐 주의를 잃습니다. 그런데 바로 그 순간 시스템이 예외 상황을 만나면 인간이 즉각 개입해야 합니다. 이것은 인간의 인지 능력과 맞지 않는 구조입니다.

해결책은 "의미 있는 인간 통제(Meaningful Human Control)"를 설계에 포함하는 것입니다. 감독자가 실제로 시스템 상태를 이해하고 적시에 개입할 수 있도록, 경고 메커니즘, 명확한 개입 프로토콜, 정기적인 인지 참여 활동을 설계해야 합니다.

설계 원칙

인간을 워크플로에 배치할 때는 반드시 물어보십시오: "이 감독자가 실제로 시스템의 결정을 이해하고 적시에 개입할 수 있는가? 아니면 단순히 책임을 인간에게 전가하는 것인가?"

📝 퀴즈 · 수업 4

인간-AI 워크플로 설계

수업에서 배운 내용을 확인해 보세요.

1. 2018년 Uber 자율주행 사고에서 드러난 인간-AI 워크플로 설계의 핵심 문제는?
✅ 정확합니다! 안전 운전자는 존재했지만 개입 경고 시스템이 불충분했고, 자동 긴급 제동도 비활성화되어 있었습니다. 역할 정의와 개입 설계가 부재했습니다.
❌ 틀렸습니다. Uber는 안전 운전자를 배치했지만, 인간 감독자의 역할과 개입 메커니즘을 제대로 설계하지 않았습니다.
2. "자동화 역설(automation paradox)"이 의미하는 것은?
✅ 맞습니다! 자동화가 높을수록 감독자는 단조로운 모니터링에 지쳐 주의력을 잃고, 정작 필요한 순간에 빠른 개입이 어려워집니다.
❌ 틀렸습니다. 자동화 역설은 자동화 수준과 인간의 인지 참여 수준 사이의 관계에 관한 개념입니다.
3. "의미 있는 인간 통제(Meaningful Human Control)"의 핵심 조건은?
✅ 정확합니다! 이름뿐인 인간 감독이 아니라, 실질적으로 이해하고 개입할 수 있는 구조가 의미 있는 통제입니다.
❌ 틀렸습니다. 모든 결정을 검토하거나 서명을 받는 것은 실용적이지 않습니다. 핵심은 실질적 이해와 적시 개입 가능성입니다.
🧪 실습 · 수업 4

워크플로 설계 실습

AI 튜터와 함께 특정 서비스의 인간-AI 워크플로를 설계하고 개선합니다.

실습 안내

AI 튜터가 특정 비즈니스 프로세스 시나리오를 제시합니다. 다음을 분석하세요:

  1. 어떤 단계를 AI가 처리하고 어떤 단계를 인간이 처리해야 하는지 결정하세요.
  2. 자동화 역설의 위험이 있는 지점을 파악하세요.
  3. 의미 있는 인간 통제를 보장하기 위한 메커니즘을 제안하세요.
추천 시작 문구: "워크플로 설계 시나리오를 주시면 분석해 보겠습니다."
🤖 AI 튜터 — 워크플로 설계 코치 수업 4 실습
🎯 Advanced · 수업 5 of 8

테스트 & 레드팀

AI 시스템의 취약점은 예상치 못한 방식으로 드러납니다. 배포 전에 의도적으로 시스템을 공격하고 실패 사례를 찾는 레드팀(red-teaming)은 필수적인 안전 관행입니다.

시스템을 공격해 보는 것이 왜 가장 중요한 테스트일까요?

2022년 11월, Meta가 출시한 과학 AI 챗봇 Galactica는 불과 3일 만에 서비스를 중단했습니다. Galactica는 수백만 편의 과학 논문으로 훈련되어 과학적 질문에 답하도록 설계되었습니다. 그러나 사용자들이 즉시 발견한 것은, 모델이 완전히 잘못된 과학적 사실을 매우 자신 있는 어조로 생성한다는 점이었습니다. "곰의 역사"를 물었을 때 정확한 답을 내놓은 반면, 더 전문적인 질문에는 그럴듯하지만 완전히 틀린 답을 생성했습니다.

Meta는 출시 전 광범위한 내부 벤치마크 테스트를 수행했지만, 실제 사용자의 다양하고 예측 불가능한 질문 패턴에 대한 레드팀 테스트는 충분하지 않았습니다. 결과적으로 대중이 레드팀 역할을 수행했고, 명성과 신뢰를 잃는 비용을 치렀습니다.

레드팀이란 무엇인가

레드팀(red-teaming)은 군사 전략에서 유래한 개념으로, 적의 관점에서 자신의 시스템 취약점을 찾는 활동입니다. AI 분야에서는 시스템이 예상치 못한 방식으로 실패하거나 악용될 수 있는 경우를 배포 전에 의도적으로 탐색하는 과정입니다.

Anthropic, OpenAI, Google DeepMind 등 주요 AI 기업들은 모두 공식적인 레드팀 조직을 운영합니다. 이들은 모델이 유해한 콘텐츠를 생성하도록 유도하거나, 안전장치를 우회하거나, 의도하지 않은 방식으로 동작하는 시나리오를 탐색합니다.

레드팀 테스트의 유형

  • 적대적 프롬프팅 (Adversarial Prompting): 시스템이 금지된 콘텐츠를 생성하도록 유도하는 방식 ("탈옥" 시도)
  • 경계 사례 테스트 (Edge Case Testing): 시스템이 처리하지 못할 것 같은 극단적이거나 모호한 입력
  • 사용자 오해 시뮬레이션: 사용자가 AI를 잘못된 목적으로 사용하는 시나리오
  • 복합 공격 (Compound Attacks): 여러 무해한 요청을 조합해 유해한 결과를 만들어내는 시도
  • 분포 외 입력 (Out-of-Distribution): 훈련 데이터의 범위를 벗어난 질문이나 언어

구조화된 레드팀 프로세스

효과적인 레드팀은 무작위 테스트가 아닙니다. 구체적인 위험 시나리오를 목록화하고, 각 시나리오에 대한 테스트 케이스를 작성하며, 결과를 문서화하고 우선순위를 정해 개선하는 체계적 프로세스입니다.

Galactica 사례는 내부 벤치마크와 실제 레드팀 테스트가 다르다는 것을 보여줍니다. 벤치마크는 알려진 질문에 대한 성능을 측정하지만, 레드팀은 알려지지 않은 실패 모드를 발견하려 합니다. 두 가지 모두 필요하지만 성격이 다릅니다.

📝 퀴즈 · 수업 5

테스트 & 레드팀

수업에서 배운 내용을 확인해 보세요.

1. Meta Galactica 사례에서 배울 수 있는 핵심 교훈은?
✅ 정확합니다! Galactica는 벤치마크에서 좋은 성능을 보였지만, 실제 사용자의 예측 불가능한 질문에는 심각한 오류를 보였습니다.
❌ 틀렸습니다. 핵심은 내부 벤치마크와 실제 사용 환경 간의 격차를 레드팀 테스트로 좁혀야 한다는 점입니다.
2. "복합 공격(Compound Attacks)" 레드팀 테스트가 중요한 이유는?
✅ 맞습니다! 단일 요청의 안전성만 테스트하면 놓칠 수 있는 조합 취약점을 발견하는 것이 복합 공격 테스트의 목적입니다.
❌ 틀렸습니다. 복합 공격은 서버 성능이나 다국어 지원과 무관합니다. 개별 무해한 입력의 조합이 만드는 위험을 탐색합니다.
3. 레드팀 테스트와 벤치마크 테스트의 핵심 차이는?
✅ 정확합니다! 벤치마크는 "잘 알려진 테스트에서 얼마나 잘하는가"이고, 레드팀은 "아직 발견하지 못한 실패 방식이 무엇인가"입니다.
❌ 틀렸습니다. 핵심 차이는 누가 수행하느냐나 자동화 여부가 아니라, 알려진 성능 측정 대 미지의 취약점 발견이라는 목적의 차이입니다.
🧪 실습 · 수업 5

레드팀 테스트 실습

AI 튜터와 함께 특정 AI 시스템의 레드팀 테스트 계획을 수립합니다.

실습 안내

AI 튜터가 특정 AI 서비스 시나리오를 제시합니다. 다음 단계를 따르세요:

  1. 해당 서비스에서 발생할 수 있는 위험 시나리오를 최소 3가지 식별하세요.
  2. 각 위험 시나리오에 대한 구체적인 테스트 케이스를 작성하세요.
  3. 발견된 취약점의 우선순위를 어떻게 결정할지 설명하세요.
추천 시작 문구: "어떤 AI 서비스를 레드팀할까요?"
🤖 AI 튜터 — 레드팀 코치 수업 5 실습
🎯 Advanced · 수업 6 of 8

책임감 있는 배포

AI 시스템을 언제, 어떻게 배포할지는 기술적 결정만큼 윤리적 결정입니다. 단계적 배포, 모니터링, 롤백 계획은 책임감 있는 배포의 필수 요소입니다.

AI 시스템이 준비되었다는 것을 어떻게 알 수 있을까요?

2019년, Apple과 Goldman Sachs가 공동 출시한 Apple Card는 신용 한도 결정 알고리즘이 성별에 따라 차별적으로 작동한다는 논란에 휩싸였습니다. 소프트웨어 개발자 David Hansson은 자신의 妻가 자신과 동일한 재정 정보를 가지고 있음에도 신용 한도가 20배 낮게 책정되었다고 트위터에 공개했습니다. 뉴욕주 금융 서비스국은 공식 조사에 착수했습니다.

이 사건은 배포 전 알고리즘 감사(algorithm audit)의 중요성을 보여줍니다. 신용 결정 알고리즘은 금융 규제를 받는 고위험 도메인임에도, 출시 전에 인구 통계학적 집단 간 결과 형평성을 체계적으로 검증하지 않았습니다.

배포 전 점검 목록

책임감 있는 배포는 "기술적으로 작동한다"는 확인만으로 충분하지 않습니다. 다음 질문들에 답할 수 있어야 합니다.

  • 알고리즘 출력이 보호받는 집단(성별, 인종, 나이 등)에 따라 체계적으로 다른가?
  • 시스템이 잘못 작동할 때 어떤 피해가 발생하며, 그 피해를 누가 가장 많이 입는가?
  • 사용자가 AI의 결정에 이의를 제기할 수 있는 경로가 있는가?
  • 배포 후 성능 저하나 새로운 문제를 감지하는 모니터링 체계가 있는가?
  • 문제 발생 시 시스템을 롤백하거나 수동 운영으로 전환하는 계획이 있는가?

단계적 배포 전략

고위험 AI 시스템은 전면 출시 대신 단계적 배포(staged rollout)를 통해 위험을 관리해야 합니다. 예를 들어, 내부 사용자 → 베타 그룹(소수) → 지역 제한 출시 → 전면 출시 순으로 진행하면서 각 단계에서 데이터를 수집하고 검증합니다.

Apple Card 사례에서 보듯, 수백만 명에게 동시에 배포하기 전에 더 작은 집단에서 인구 통계적 형평성을 검증했다면 피해를 크게 줄일 수 있었을 것입니다. 단계적 배포는 단순한 기술적 관행이 아니라 윤리적 의무입니다.

고위험 도메인 주의

신용, 고용, 의료, 주거, 교육 분야의 AI 시스템은 배포 전 반드시 알고리즘 감사와 형평성 검증을 수행해야 합니다. 이 분야들은 오류가 개인의 삶에 직접적이고 심각한 영향을 미칩니다.

📝 퀴즈 · 수업 6

책임감 있는 배포

수업에서 배운 내용을 확인해 보세요.

1. Apple Card 알고리즘 논란이 보여주는 배포 전 검증의 핵심은?
✅ 정확합니다! 신용, 고용 등 고위험 영역에서는 성별, 인종 등 집단 간 결과 차이를 배포 전에 반드시 검증해야 합니다.
❌ 틀렸습니다. 신용 평가에서 AI를 사용하는 것 자체가 문제가 아니라, 배포 전 형평성 검증을 하지 않은 것이 문제였습니다.
2. 단계적 배포(staged rollout)의 주요 목적은?
✅ 맞습니다! 단계적 배포는 소규모에서 문제를 발견하고 수정하여 전면 배포의 위험을 줄이는 전략입니다.
❌ 틀렸습니다. 단계적 배포의 핵심은 비용이나 경쟁 전략이 아닌, 위험 관리와 검증입니다.
3. 책임감 있는 배포에서 "롤백 계획"이 반드시 필요한 이유는?
✅ 정확합니다! 아무리 철저히 준비해도 예상치 못한 문제는 발생합니다. 신속한 복구 능력이 피해를 최소화합니다.
❌ 틀렸습니다. 롤백 계획은 경쟁이나 규제가 아닌, 배포 후 심각한 문제 발생 시 빠른 복구를 위한 것입니다.
🧪 실습 · 수업 6

배포 계획 설계 실습

AI 튜터와 함께 특정 AI 시스템의 책임감 있는 배포 계획을 수립합니다.

실습 안내

AI 튜터가 특정 AI 시스템 시나리오를 제시합니다. 다음을 포함한 배포 계획을 작성하세요:

  1. 배포 전 검증 체크리스트(형평성, 안전성 포함)
  2. 단계적 배포 로드맵(내부 → 베타 → 전면 출시)
  3. 모니터링 지표와 롤백 기준
추천 시작 문구: "배포 계획을 세울 AI 시스템 시나리오를 주시면 시작하겠습니다."
🤖 AI 튜터 — 배포 계획 코치 수업 6 실습
🎯 Advanced · 수업 7 of 8

공정성을 위한 설계

AI 시스템의 공정성(fairness)은 수학적 정의만의 문제가 아닙니다. 누가 혜택을 받고 누가 피해를 입는지, 그리고 그 불균형이 기존 사회 불평등을 어떻게 증폭시키는지를 이해해야 합니다.

공정한 AI 시스템을 만든다는 것은 무엇을 의미할까요?

2018년, 아마존(Amazon)이 2014년부터 내부적으로 사용했던 AI 채용 도구가 여성 지원자를 체계적으로 낮게 평가해 왔다는 사실이 Reuters에 의해 보도되었습니다. 이 시스템은 지난 10년간의 이력서를 학습했는데, 기술 분야에서 남성 지원자가 압도적으로 많았기 때문에 "여성 대학"이나 "여성 체스 클럽" 등 여성 관련 단어를 포함한 이력서를 낮게 평가하도록 학습되었습니다. 아마존은 이 문제를 발견한 후 2017년 해당 시스템의 사용을 중단했습니다.

이 사례는 편향된 역사적 데이터로 훈련된 AI가 과거의 불평등을 자동화하고 정당화할 수 있음을 명확히 보여줍니다. AI는 현실을 반영하는 거울이자, 그 현실을 증폭시키는 확성기가 될 수 있습니다.

공정성의 수학적 정의들

공정성에는 서로 충돌하는 다양한 수학적 정의가 존재합니다. 이를 동시에 모두 만족시키는 것은 수학적으로 불가능한 경우가 많습니다.

  • 인구통계학적 동등성 (Demographic Parity): 모든 집단에서 긍정 결과 비율이 동일해야 한다.
  • 동등 기회 (Equal Opportunity): 실제 자격이 있는 사람들 중에서 집단 간 통과율이 동일해야 한다.
  • 개인 공정성 (Individual Fairness): 비슷한 사람들은 비슷한 결과를 받아야 한다.
  • 보정 (Calibration): 같은 점수를 받은 사람들은 집단에 관계없이 같은 실제 결과를 가져야 한다.

편향의 원천과 대응

아마존 사례가 보여주듯, 편향은 종종 데이터 자체에서 시작됩니다. 역사적으로 불평등한 환경에서 생성된 데이터는 그 불평등을 학습 신호로 전달합니다.

편향을 줄이기 위한 실질적 접근으로는: 훈련 데이터의 인구통계학적 대표성 분석, 모델 출력의 집단별 성능 차이 정기 측정(disaggregated evaluation), 다양한 배경을 가진 팀에 의한 설계 검토, 그리고 "설명 가능한 AI(Explainable AI)"를 통한 결정 근거 투명화가 있습니다.

중요한 인식

공정성 문제를 "기술적으로 해결"한다는 것은 환상일 수 있습니다. 어떤 공정성 정의를 선택할지는 기술적 결정이 아닌 가치 판단입니다. 이해관계자, 특히 피영향 집단의 목소리가 이 과정에 포함되어야 합니다.

📝 퀴즈 · 수업 7

공정성을 위한 설계

수업에서 배운 내용을 확인해 보세요.

1. 아마존 AI 채용 도구가 여성 지원자를 낮게 평가한 근본 원인은?
✅ 정확합니다! AI는 의도적이지 않더라도 역사적 데이터에 담긴 불평등 패턴을 학습하고 자동화할 수 있습니다.
❌ 틀렸습니다. 의도적 차별이 아닌, 역사적으로 편향된 훈련 데이터가 문제였습니다. 이것이 AI 편향의 가장 흔한 원천입니다.
2. 공정성의 다양한 수학적 정의들이 동시에 충족되기 어려운 이유는?
✅ 맞습니다! 예를 들어 "인구통계학적 동등성"과 "보정"은 동시에 달성하는 것이 수학적으로 불가능한 경우가 있습니다.
❌ 틀렸습니다. 처리 능력이나 데이터 양의 문제가 아닙니다. 서로 다른 공정성 정의들 사이에 수학적 상충 관계가 존재합니다.
3. AI 공정성 문제를 해결하기 위해 "피영향 집단의 목소리"가 중요한 이유는?
✅ 정확합니다! 공정성 정의 선택은 기술 문제가 아닌 가치 판단입니다. 영향받는 집단이 이 과정에 참여해야 진정한 공정성을 추구할 수 있습니다.
❌ 틀렸습니다. 피영향 집단 참여는 법적 의무나 마케팅이 아닌, 가치 판단 과정의 민주적 정당성을 위한 것입니다.
🧪 실습 · 수업 7

공정성 감사 실습

AI 튜터와 함께 특정 AI 시스템의 잠재적 편향을 분석하고 공정성 개선 방안을 모색합니다.

실습 안내

AI 튜터가 실제 AI 시스템 시나리오와 데이터를 제시합니다. 다음을 분석하세요:

  1. 훈련 데이터에서 잠재적 편향의 원천을 파악하세요.
  2. 이 시스템에 적합한 공정성 정의를 선택하고 그 이유를 설명하세요.
  3. 편향을 측정하고 완화하기 위한 구체적 접근 방법을 제안하세요.
추천 시작 문구: "공정성 감사를 시작할 AI 시스템 시나리오를 주세요."
🤖 AI 튜터 — 공정성 분석 코치 수업 7 실습
🎯 Advanced · 수업 8 of 8

지속적인 책임

AI 시스템의 배포는 끝이 아니라 시작입니다. 모델 드리프트, 새로운 악용 패턴, 변화하는 사회 규범에 대응하는 지속적 관리가 AI 구축자의 영속적 책임입니다.

AI 시스템을 출시한 후에도 개발자는 무엇을 책임져야 할까요?

2016년부터 미국 전역의 법원에서 사용된 COMPAS(Correctional Offender Management Profiling for Alternative Sanctions)는 피고인의 재범 위험을 예측하는 AI 도구입니다. 2016년 ProPublica의 조사는 이 시스템이 흑인 피고인을 백인 피고인보다 재범 위험이 높다고 잘못 분류하는 비율이 거의 두 배에 달한다는 것을 발견했습니다. 그러나 이 시스템의 개발사 Northpointe는 이후에도 수년간 도구를 수정하거나 독립적 감사를 허용하지 않았습니다.

이 사례는 지속적 책임의 실패를 보여줍니다. 편향이 발견된 후에도 개발자가 유의미한 수정 조치를 취하지 않고, 시스템이 형사 사법 결정에 계속 영향을 미쳤습니다. AI 구축은 배포로 끝나지 않습니다.

모델 드리프트와 지속적 모니터링

배포된 AI 시스템은 시간이 지남에 따라 성능이 저하될 수 있습니다. 이를 "모델 드리프트(model drift)"라고 합니다. 두 가지 유형이 있습니다. 첫째, 데이터 드리프트: 실제 세계의 패턴이 변해 입력 데이터의 분포가 훈련 데이터와 달라집니다. 둘째, 컨셉 드리프트: 예측하려는 현상 자체가 변합니다(예: 코로나19 팬데믹으로 인한 소비 패턴 변화).

지속적 모니터링은 이러한 드리프트를 조기에 감지하고 대응하기 위해 필수적입니다. 핵심 성능 지표, 오류율, 집단별 결과 차이를 정기적으로 측정하고 임계값을 초과할 때 경보를 발송하는 시스템이 필요합니다.

이의 제기와 수정 메커니즘

COMPAS 사례에서 보듯, 영향받는 개인들이 AI 결정에 이의를 제기하고 설명을 요구할 수 있는 메커니즘은 윤리적 필수 요건입니다. EU의 AI 법(EU AI Act)은 고위험 AI 시스템에 대해 이러한 권리를 명문화하고 있습니다.

이의 제기 메커니즘은 단순히 불만을 접수하는 것이 아닙니다. AI 결정의 근거를 이해 가능한 언어로 설명하고, 오류가 확인될 경우 신속히 수정하며, 시스템 개선에 피드백을 반영하는 전체 프로세스를 포함해야 합니다.

AI 구축자의 영속적 책임

AI 시스템을 배포하는 것은 제품을 판매하는 것과 다릅니다. 시스템이 계속 작동하며 결정을 내리는 동안, 그 결정의 영향에 대한 책임도 계속됩니다. 이는 전통적인 소프트웨어 개발보다 훨씬 높은 수준의 지속적 책임을 의미합니다.

실질적으로 이것은 다음을 의미합니다: 새로운 악용 패턴이 발견되면 대응해야 하고, 사회적 규범이 변하면 시스템을 재평가해야 하며, 더 이상 안전하게 운영할 수 없다면 서비스를 종료할 용기가 있어야 합니다. 기술적 역량만큼 윤리적 의지가 AI 구축자의 핵심 자질입니다.

이 모듈의 핵심 메시지

AI 구축은 문제 정의로 시작하지만 지속적 책임으로 끝나지 않습니다. 기술을 만드는 것은 사회적 행위이며, 그 결과에 대한 책임은 지속됩니다.

📝 퀴즈 · 수업 8

지속적인 책임

수업에서 배운 내용을 확인해 보세요.

1. COMPAS 사례에서 Northpointe가 보여준 지속적 책임의 실패는 무엇인가요?
✅ 정확합니다! 편향이 발견된 후에도 책임 있는 대응을 하지 않은 것이 핵심 문제입니다. 지속적 책임은 문제 발견 후의 대응을 포함합니다.
❌ 틀렸습니다. Northpointe의 실패는 이미 드러난 편향 문제에 책임 있게 대응하지 않은 것입니다.
2. "컨셉 드리프트(concept drift)"의 올바른 설명은?
✅ 맞습니다! 예측 대상 자체의 변화가 컨셉 드리프트입니다. 예를 들어, 팬데믹으로 소비 패턴이 바뀌면 기존 추천 모델의 가정 자체가 무너집니다.
❌ 틀렸습니다. 입력 데이터 분포 변화는 데이터 드리프트입니다. 컨셉 드리프트는 예측하려는 현상 자체의 변화입니다.
3. AI 구축자의 "영속적 책임"이 전통적 소프트웨어 개발과 다른 이유는?
✅ 정확합니다! AI 시스템이 활성 상태인 한 그 결정의 영향도 지속되며, 그에 따른 책임도 계속됩니다. 이것은 단순한 제품 판매와 근본적으로 다릅니다.
❌ 틀렸습니다. 영속적 책임의 본질은 시스템이 계속 결정을 내리고 그 영향이 계속된다는 사실에 있습니다.
🧪 실습 · 수업 8

지속적 모니터링 계획 수립

AI 튜터와 함께 배포된 AI 시스템의 지속적 모니터링 및 책임 체계를 설계합니다.

실습 안내

AI 튜터가 배포된 AI 시스템 시나리오를 제시합니다. 다음을 포함한 지속적 책임 계획을 작성하세요:

  1. 모델 드리프트를 감지하기 위한 핵심 모니터링 지표와 경보 임계값
  2. 사용자 이의 제기 프로세스와 수정 메커니즘
  3. 언제 서비스를 중단하거나 롤백해야 하는지의 기준
추천 시작 문구: "모니터링 계획을 수립할 AI 시스템을 알려 주세요."
🤖 AI 튜터 — 책임 체계 코치 수업 8 실습

📋 모듈 테스트

모듈 10 "AI로 구축하기"의 모든 수업 내용을 종합적으로 평가합니다. 15문항, 각 1점.

1. IBM Watson for Oncology 프로젝트가 실패한 가장 근본적인 이유는?
✅ 정확합니다!
❌ 틀렸습니다. 문제 정의의 실패가 핵심이었습니다.
2. AI 문제 정의에서 "성공 기준(Success Criteria)"을 반드시 사전에 정의해야 하는 이유는?
✅ 정확합니다!
❌ 틀렸습니다. 성공 기준은 객관적 평가와 개선을 위한 것입니다.
3. Schwartz 변호사 사건에서 프롬프트 설계의 핵심 실수는?
✅ 정확합니다!
❌ 틀렸습니다. AI의 역할과 한계를 정의하지 않은 것이 핵심 문제입니다.
4. 효과적인 프롬프트 설계가 반드시 포함해야 하는 요소가 아닌 것은?
✅ 정확합니다! 경쟁사 비교는 프롬프트 설계 요소가 아닙니다.
❌ 틀렸습니다. 경쟁사 비교 요구가 프롬프트 설계에 포함될 이유는 없습니다.
5. Microsoft Tay 사건이 AI 출력 평가에 대해 가르쳐 주는 것은?
✅ 정확합니다!
❌ 틀렸습니다. 핵심은 안전성 평가 없이 배포한 것이 문제였습니다.
6. "A/B 테스트"가 AI 출력 평가 방법 중 가장 현실적이지만 갖는 한계는?
✅ 정확합니다! A/B 테스트는 실제 사용자 데이터를 사용하지만, 배포 후에야 가능하다는 한계가 있습니다.
❌ 틀렸습니다. A/B 테스트의 핵심 한계는 배포 이전에 수행할 수 없다는 점입니다.
7. 2018년 Uber 자율주행 사고가 보여주는 "자동화 역설"이란?
✅ 정확합니다!
❌ 틀렸습니다. 자동화 역설은 감독자 주의력과 개입 능력에 관한 것입니다.
8. 의미 있는 인간 통제(Meaningful Human Control)의 핵심 조건은?
✅ 정확합니다!
❌ 틀렸습니다. 실질적 이해와 적시 개입 가능성이 핵심입니다.
9. Meta Galactica의 실패에서 레드팀 테스트에 대해 배울 수 있는 교훈은?
✅ 정확합니다!
❌ 틀렸습니다. 벤치마크와 레드팀은 다른 목적을 가집니다.
10. Apple Card 알고리즘 논란이 강조하는 배포 전 검증의 핵심은?
✅ 정확합니다!
❌ 틀렸습니다. 형평성 검증은 배포 전에 이루어져야 합니다.
11. 아마존 AI 채용 도구 사례가 보여주는 AI 편향의 가장 흔한 원천은?
✅ 정확합니다! 과거 불평등이 데이터에 담기면 AI가 그것을 학습하고 재생산합니다.
❌ 틀렸습니다. 편향된 훈련 데이터가 가장 흔한 원천입니다.
12. 공정성 정의 중 "인구통계학적 동등성(Demographic Parity)"이 의미하는 것은?
✅ 정확합니다!
❌ 틀렸습니다. 인구통계학적 동등성은 집단 간 긍정 결과 비율의 동일성에 관한 것입니다.
13. COMPAS 사례에서 드러난 지속적 책임의 가장 중요한 교훈은?
✅ 정확합니다!
❌ 틀렸습니다. 문제 발견 후 책임 있는 대응이 없었던 것이 핵심 교훈입니다.
14. "데이터 드리프트(data drift)"의 올바른 설명은?
✅ 정확합니다!
❌ 틀렸습니다. 데이터 드리프트는 입력 데이터 분포가 훈련 데이터와 달라지는 현상입니다.
15. 이 모듈 전체를 통해 강조되는 AI 구축의 핵심 원칙은?
✅ 정확합니다! 이 모듈의 핵심입니다. AI 구축은 처음부터 끝까지 기술과 윤리가 함께 가야 합니다.
❌ 틀렸습니다. 이 모듈 전체를 통해 기술과 윤리적 책임이 분리될 수 없음을 강조했습니다.