Introduction 들어가면서

기존 범용 시스템의 소프트웨어(SW) 테스팅에 대한 중요성은 이제 상당히

알려져 있는 반면, 일상에 점점 깊숙히 보급되고 있는 AI 기반 시스템에
대한 테스팅은 SW 전반에 새로운 도전과 과제를 안겨주고 있다.

본 AI 시스템 테스트 가이드는 아래의 주요 개념을 다룬다.

· 인공지능(Artificial Intelligence, AI)의 컨셉과 개념
· 인수 조건 수립 방안
· AI 기반 시스템의 테스트 기법

이런 시스템의 특징은,
· 복잡도가 높고 (예, 심층 신경망)
· 빅데이터를 기반으로 하며
· 명세가 거의 없고
· 비결정적(non-deterministic) 이다.
때문에 이런 시스템을 테스트하기 위한 많은 새로운 도전과 동시에 기회가
창출되고 있다.

이 문서에서 AI 기반 시스템은 적어도 하나의 AI 컴포넌트를 포함하고

있는 시스템을 의미한다. 이 문서 전반에 걸쳐 AI는 ‘인공 지능(Artificial
Intelligence)’을 뜻하는 용어로 사용된다.

* 이 AI시스템 테스트 가이드는KSTQB Korean Software Testing Qualifications Board 와

CSTQB Chinese Software Testing Qualifications Board AIT (AI Testing) syllabus를 참조해
작성되었다.

002 Testing AI Guidelines ver 1.8 003 Introduction

Contents 차례 2 AI 시스템 특성과 인수 조건 AI System Characteristics and Acceptance Criteria 024

2.1 AI 고유 특성 025
AI-Specific Characteristics
2.1.1 적응성 025
들어가면서 Introduction 003 Adaptability
2.1.2 자율성 026
Autonomy
1 AI와 테스팅 소개 Introduction to AI and Testing 010 2.1.3 진화 026
Evolution

1.1 ‘인공 지능’과 ‘AI 효과’의 정의 011 2.1.4 유연성 026

Definition of ‘Artificial Intelligence’ and the ‘AI Effect’ Flexibility

1.2 AI 유스 케이스 011 2.1.5 편향성 027

AI Use Cases Bias

1.3 AI 사용과 시장 012 2.1.6 성능 메트릭 027

AI Usage and Market Performance Metrics
1.4 AI 기반 시스템의 장애와 테스팅의 중요성 012 2.1.7 투명성 027
Failures and the Importance of Testing for AI-Based Systems Transparency

1.5 튜링 테스트와 AI의 역사 013 2.1.8 복잡성 028

The Turing Test and the History of AI [History 2019] Complexity

1.6 로봇과 소프트웨어 에이전트 014 2.1.9 비결정성 029

Robots and Software Agents Non-Determinism

1.7 AI 기술 015 2.2 AI 기반 시스템과 인간 가치의 연계 029

AI Technologies Aligning AI-Based systems with human values

1.8 AI 하드웨어 016 2.3 부작용 030

AI Hardware Side-Effects

1.9 AI 개발 프레임워크 017 2.4 보상 해킹 030

AI Development Frameworks Reward Hacking

1.10 좁은 AI 대 일반 AI, 기술 특이점 017 2.5 AI 기반 시스템 고유의 윤리적 요구사항 031
Narrow vs General AI and Technological Singularity Specifying Ethical Requirements for AI-Based Systems

1.11 AI와 자율 시스템 018

AI and Autonomous Systems References 032
1.12 안전관련 AI 기반 시스템 019
Safety-Related AI-Based Systems
1.13 표준화와 AI 019
Standardization and AI 3 기계 학습 Machine Learning 034
1.13.1 AI 규제 표준 020
Regulatory Standards for AI 3.1 기계 학습(ML) 소개 035
1.13.1.1 비안전관련 규제 표준 020 Introduction to Machine learning

Non-Safety-Related Regulatory Standards 3.2 기계 학습 작업흐름 037

1.13.1.2 안전관련 표준 020 The Machine Learning Workflow

Safety-Related Standards 3.2.1 목적의 이해 038

1.14 AI 품질 메타모델 – DIN SPEC 92001:2019 021 Understand the Objectives

The AI Quality Metamodel – DIN SPEC 92001:2019 3.2.2 프레임워크 선택 038

Select a Framework
References 022 3.2.3 모델 구축과 컴파일 038
Build and Compile the Model

004 Testing AI Guidelines ver 1.8 005 Contents

 3.2.4 데이터 소싱 038 3.8.7 모델 통합 테스팅 045
Source the Data Model Integration Testing
3.2.5 데이터 전처리 039 3.8.8 적대적 사례 및 테스팅 045
Pre-Process the Data Adversarial Examples and Testing [Qiu 2019]
3.2.6 데이터 훈련 039
Train the Model References 046
3.2.7 모델 평가 039
Evaluate the Model
3.2.8 모델 조정 039
Tune the Model 4 기계 학습 성능 메트릭 및 벤치마크 Machine Learning Performance Metrics
3.2.9 모델 테스트 039 and Benchmarks 048
Test the Model
3.2.10 모델 배포 040 4.1 기계 학습 성능 메트릭 049
Deploy the Model Machine Learning Performance Metrics
3.2.11 모델 사용 040 4.1.1 혼동 행렬 049
Use the Model Confusion Matrix [Confusion 2019]
3.2.12 모델 모니터링 및 조정 040 4.1.2 정확도 050
Monitor & Tune the Model Accuracy
3.3 기계 학습 훈련과 테스트 데이터 040 4.1.3 정밀도 050
Machine Learning Training and Test Data Precision
3.4 기계 학습 과적합 및 과소적합 041 4.1.4 재현율 050
Overfitting and Underfitting in Machine Learning Recall
3.4.1 과적합 041 4.1.5 F1-점수 050
Overfitting F1-Score
3.4.2 과소적합 042 4.1.6 성능 메트릭의 선택 050
Underfitting Selection of Performance Metrics
3.5 훈련 데이터의 편향성 및 공정성 042 4.2 기계학습 벤치마크 051
Bias and Fairness in the Training Data Benchmarks for Machine Learning
3.6 데이터 품질 043
Data Quality References 052
3.7 기계 학습 알고리즘/모델 선택 044
Machine Learning Algorithm/Model selection
3.8 기계 학습 테스팅과 품질 보증 044
Machine Learning Testing and Quality Assurance 5 AI 시스템 테스팅 소개 Introduction to the Testing of AI Systems 054
3.8.1 ML 작업흐름 리뷰 044
Review of ML Workflow 5.1 AI 기반 시스템 테스팅의 과제 055
3.8.2 인수 조건 044 Challenges in Testing AI-Based Systems
Acceptance Criteria 5.1.1 시스템 명세 055
3.8.3 프레임 워크, 알고리즘/모델 및 매개변수 선택 044 System Specifications
Framework, Algorithm/Model and Parameter Selection 5.1.2 테스트 입력 데이터 055
3.8.4 모델 업데이트 045 Test Input Data
Model Updates 5.1.3 확률적 및 비결정적 시스템 056
3.8.5 훈련 데이터 품질 045 Probabilistic & Non-Deterministic Systems
Training Data Quality 5.1.4 자가학습 시스템 056
3.8.6 테스트 데이터 품질 045 Self-Learning Systems
Test Data Quality 5.1.5 복잡성 056
Complexity

006 Testing AI Guidelines ver 1.8 007 Contents

 5.1.6 AI 특수성 056 References 073
AI-Specific Characteristics (see section 2.1)
5.2 AI 기반 시스템의 테스트 오라클 문제 057
The Test Oracle Problem for AI-Based Systems
8 AI 기반 시스템의 테스트 환경 Test Environments for AI-Based Systems 074
References 057
8.1 AI 기반 시스템의 테스트 환경 075
Test Environments for AI-Based Systems
8.2 테스트 시나리오 도출 076
6 AI 기반 시스템의 테스트 오라클 문제 Black Box Testing of AI-Based Systems 058 Test Scenario Derivation
8.3 규제 테스트 시나리오와 테스트 환경 077
6.1 조합 테스팅 059 Regulatory Test Scenarios and Test Environments
Combinatorial Testing
6.2 백투백 테스팅 060 References 077
Back-to-Back Testing
6.3 A/B 테스팅 061
A/B Testing
6.4 변성 테스팅 062 9 테스팅에 AI 활용하기 Using AI for Testing 078
Metamorphic Testing [Chen 2018] [Segura 2016]
9.1 AI 주도 테스팅 소개 079
References 064 Introduction to AI-Driven Testing
9.2 테스팅에 사용하는 AI 형태 079
Forms of AI used for Testing
9.3 AI가 지원하는 테스트 유형 079
7 신경망 화이트박스 테스팅 White Box Testing of Neural Networks 066 Test Types Supported by AI
9.4 테스팅을 위한 AI 유스 케이스 예제 080
7.1 신경망 구조 067 Example Use Cases of AI for Testing
Structure of a Neural Network 9.4.1 결함 예측 080
7.2 신경망의 테스트 커버리지 측정 068 Bug Prediction
Test Coverage Measures for Neural Networks 9.4.2 정적 분석 081
7.2.1 뉴런 커버리지 068 Static Analysis
Neuron Coverage 9.4.3 리그레션 테스트 최적화 081
7.2.2 임계점 커버리지 068 Regression Test Optimization
Threshold Coverage 9.4.4 테스트 입력 생성 082
7.2.3 부호 변경 커버리지 069 Test Input Generation
Sign Change Coverage 9.4.5 자동화된 탐색적 테스팅 083
7.2.4 값 변경 커버리지 070 Automated Exploratory Testing
Value Change Coverage
7.2.5 부호-부호 커버리지 070 References 083
Sign-Sign Coverage
7.2.6 레이어 커버리지 071
Layer Coverage
7.2.7 화이트 박스 측정의 테스트 효과 071 용어정의 Glossary 086
Test Effectiveness of the White Box Measures
7.3 신경망을 위한 화이트 박스 테스팅 도구 072 참고문헌 References 094
White Box Testing Tools for Neural Networks

008 Testing AI Guidelines ver 1.8 009 Contents

Introduction to AI and 1.1 ‘인공 지능’과 ‘AI 효과’의 정의 (Definition of ‘Artificial Intelligence’ and

Testing
the ‘AI Effect’)

‘인공 지능 (Artificial Intelligence)’을 정의하기 위해서는 먼저 ‘지능’이 무엇인지 정의해야 한다.

01
옥스포드 사전은 이에 대해 다음과 같이 정의하고 있다:
AI와 테스팅 소개
지식과 기술을 습득하고 적용하는 능력

인공 지능은 사람이나 동물이 보여주는 것처럼 자연적으로 발생하는 지능이 아니다. 다음의 정의는
이 개념을 보여준다:
일반적으로 지능적인 존재와 관련된 작업을 수행할 수 있는 시스템의 능력

DIN SPEC 92001, 2019에서는 보다 구체적인 정의를 제공하지만 인공 지능과 자연 지능을 잘

대조하지는 못하고 있다:
일반적으로 지능적인 행동과 관련된 개념을 모방해 문제를 해결하는 시스템의 능력

인공 지능은 또한 학문으로 간주되어 다음 정의로 이어질 수 있다:

추론, 학습, 자기 개선 등 인간 지능 관련 기능을 수행하는 데이터 처리 시스템 개발을
전문으로 하는 컴퓨터 과학 분야 (ISO/IEC 2382: 2015,Information technology -- Vocabulary)

실제로, 사람들이 AI라고 생각하는 컨셉은 시간에 따라 변화한다. 이를 종종 ‘AI 효과(AI Effect)’
라고 한다 [AI Effect, 2019]. 위 정의를 엄격히 적용하면 AI가 아닌 기본(비AI) 컴퓨터 시스템도 AI
로 볼 수 있다. 예를 들어, 1980년대 은행 직원의 업무를 수행하는 고정 규칙에 기반한 전문 시스템은
AI로 간주되었지만 오늘날 이러한 시스템은 AI로 보기에는 너무 단순하다. 이와 유사하게, 1997년
체스 게임에서 게리 카스파로프(Garry Kasparov)를 이긴 딥블루(Deep Blue) 시스템은 무차별
공격 방식(brute force approach)을 사용한 것으로 오늘날의 관점에서는 진정한 AI로 보기 어렵다.
오늘날의 최첨단 AI도 20년 안에 ‘AI라고 하기에는 너무 단순하다’고 여겨질 것이다.

1.2 AI 유스 케이스 (AI Use Cases)

AI는 아래와 같이 여러 다양한 애플리케이션에 사용될 수 있다:

· 음성 인식 시스템 (Intelligent speech systems) (예, 음성 인식, 음성 합성)
· 컴퓨터 비전 시스템 (예, 이미지 분류)
· 자연어 처리(NLP. Natural language processing) (예, 사람의 언어에서 의미 추출하기)

010 011 Introduction to AI and Testing

· 이상 탐지 시스템 (예, 이상 탐지, 건강 상태 모니터링, 보안)
· 자율 시스템 (예, 자동차, 거래 시스템)
· 추천 시스템 (예, 물건 구매, 영화, 음악)
AI 유스 케이스의 전체 목록은 https://appliedai.com/use-cases/에서 찾을 수 있다.
1.3 AI 사용과 시장 (AI Usage and Market)
AI 기반 시스템은 지난 어느 때보다 점점 더 광범위하게 사용되고 있다:
· 기술 경영진(technology executives)의 69%가 향후 5-10년 동안 가장 중요한 3대 기술 중 하나로 AI를
선정함에 따라 AI가 최근 가장 중요한 기술이라는 인식이 자리잡고 있다 [Edelman 2019].
· 기술 경영진의 91%는 AI가 차세대 기술혁명의 중심에 있을 거라고 믿고 있다 [Edelman 2019].
· AI 기술을 필요로 하는 직업의 비율은 2013년 이후 4.5배 증가했다 [AI Index 2017].
· AI를 사용하는 기업 애플리케이션의 전세계 매출은 2018년 1.89억원에서 2025년 3조 6천억원으로 증가할
것으로 예상된다 [Statista 2019].
· AI는 향후 10년 동안 세계 경제규모를 지금보다 13조 달러 증가시킬 것으로 예상된다 [Harvard 2018].
· IT 예산의 22%는 AI 프로젝트에 할당된다 [WQR 세계품질리포트, 2019].
· 64%의 기업이 AI프로젝트를 시행했거나 향후 12개월 내 시행할 계획을 세웠다 [WQR, 2019].
1.4 AI 기반 시스템의 장애와 테스팅의 중요성 (Failures and the Importance of Testing
for AI-Based Systems)
이미 널리 알려져 있는 AI 장애는 수없이 많다. 2019년 IDC 설문조사에 따르면, 대부분의 조직이 AI
프로젝트를 실패한 경험이 있다고 보고했으며, 약 25%의 기업에서는 실패율이 최대 50%에 이른다고
한다. 실패의 가장 큰 원인은 숙련된 직원 부족과 비현실적인 기대인 것으로 나타났다.
AI 실패 사례를 살펴보면 다음과 같다:
· IBM의 “Watson for Oncology(암환자 치료용 왓슨)” 시스템은 “안전하지 않은 치료”를 유도함으로써 6천 2
백만 달러라는 손해를 입히고 취소되었다 [IEEE 2019].
· 마이크로소프트의 AI 챗봇 타이(Tay)가 트위터 트롤(Twitter trolls)에 의해 손상되었다 [Forbes 2016].
· 조슈아 브라운(Joshua Brown)이라는 운전자는 밝은 대낮에 테슬라 모델 S(Tesla Model S)가 18륜
트레일러 트럭을 발견하지 못함으로 발생한 사고로 인해 사망했다 [Reuters 2017].
· 엘레인 허츠버그(Elaine Herzberg)라는 여성은 애리조나에서 밤 10시에 자전거를 타고 길을 건너던 중 시속
012 Testing AI Guidelines ver 1.8
60km로 달리던 우버(Uber) 자율주행 차량에 치어 숨졌다 [DF 2019].
· 구글 검색이 남성 사용자들에게만 높은 임금의 직업을 보여주었다 [WP 2015].
· 미국의 AI 기반 선고 시스템 COMPAS는 아프리카계 미국인에 대한 편견을 보여주었다 [NS 2018].
· 중국 닝보(Ningbo)의 무단횡단 방지 시스템은 버스 안에 있던 억만장자의 사진을 무단 횡단하는 사람으로
인식했다 [BBC 2018].
역사적으로 소프트웨어 장애는 적절한 소프트웨어 테스팅의 필요성을 유도하는 중요한 역할을 해
왔다. 업계 조사에 따르면 AI는 소프트웨어 테스팅에서 중요한 트렌드이다.
· AI는 향후 3-5년 내에 테스팅 업계에서 중요한 신기술로 평가될 것이다 [SoTR 2019].
· AI는 향후 5년 동안 소프트웨어 테스팅 업계에서 두 번째로 중요한 기술(응답자의 49.9%)이라고 평가되었다
[ISTQB 2018].
· 소프트웨어 테스팅에서 가장 인기 있는 트렌드로 AI, CI/CD, 보안을 똑같은 1위로 꼽았다 [LogiGear 2018].
아래처럼 AI 기반 시스템에서 테스팅이 이미 수행되고 있다:
· 응답자의 19%가 이미 AI/기계 학습(Machine Learning,ML)에 대한 테스팅을 수행하고 있다 [SoTR 2019].
· 57%의 기업이 새로운 테스팅 접근법을 실험하고 있다 [WQR 2019].
1.5 튜링 테스트와 AI의 역사 (The Turing Test and the History of AI) [History 2019]
AI는 1950년대부터 시작된 것으로 알려져 있다. 1950년 앨런 튜링(Alan Turing)은 현재 ‘튜링
테스트’로 불리는 테스트를 포함한 기계 지능(Machine Intelligence)에 관한 논문을 발표했다
[Turing 1950].
1951년 영국에서는 체커(checkers) 게임을 성공적으로 수행하고 배우도록 개발된 페란티 마크 1
(Ferranti Mark 1)을 선보였다.
1956년 미국의 컴퓨터 과학자인 존 매카시(John McCarthy)는 다트머스 컨퍼런스(Dartmouth
Conference)를 조직해 ‘인공 지능’ 이라는 용어를 처음 채택했다 (나중에 그는 AI 애플리케이션에서
널리 사용되는 LISP 프로그래밍 언어를 개발했다).
몇 년 후 뉴얼과 사이먼은 다양한 수학 문제를 해결하기 위해 처음으로 일반 문제 해결 알고리즘
(General Problem Solver algorithm)을 개발했다.
다트머스 컨퍼런스 이후, AI는 DARPA 연구 자금 지원을 통해 번창하는 연구 분야가 되었고,
일본에서는 ‘지능형’ 휴머노이드 로봇에 대한 연구로 1972년 WABOT-1이 탄생했다. 또한, 1960
년대에 ELIZA 시스템에 대한 작업으로 세계 최초의 챗봇(chatbot)이 탄생했다.
첫 ‘AI 겨울(AI Winter)’은 대략 1974년부터 1980년까지 이어졌다. 초기 낙관론은 연구원들이
013 Introduction to AI and Testing
실제적인 것은 내놓지 못하고 연구비만 바닥낼 것이라는 신뢰의 상실로 이어졌다. 이 현상은 머신 이러한 에이전트들은 보통 컴퓨터 시스템(물리적 또는 클라우드 시스템)에 위치해 있고, 컴퓨터
비전 같은 분야에서 두드러졌는데, 이론적으로는 가능해 보이지만 실제 작업에서는 더 많은 처리 및 인터페이스를 통해 외부 세계와 상호작용한다.
저장 능력을 필요로 한다는 점이 드러났다. 소프트웨어 테스팅을 위해 AI를 사용하는 도구는 컴퓨터 시스템에 위치하고 사용자 인터페이스를
1980년대에는 ‘전문가 시스템(Expert Systems)’으로 알려진 새로운 형태의 AI가 AI 연구의 주요 통해 소프트웨어 테스터와 상호작용하며 정의된 프로토콜(이러한 도구는 사용자 인터페이스 같은
쟁점이 되었다. 1970년대 처음 개발된 감염 유발 박테리아를 식별하는 전문가 시스템인 MYCIN 기존의 비-AI 하위 시스템과 함께 구동하는 AI 컴포넌트를 가진 AI 기반 시스템으로 간주된다)을
은 성공적인 전문가 시스템의 초기 예라고 할 수 있다. 1980년대 초 일본 정부는 ‘5 세대 컴퓨터 사용해 컴퓨터 인터페이스를 통해 테스트하는 소프트웨어와 상호작용할 가능성이 높다.
프로젝트’를 시작했으며, 1985년까지 미국 기업은 성공적인 전문가 시스템 프로젝트를, 영국은 IT 지능형 소프트웨어 에이전트는 로봇에도 있을 수 있다. 가장 큰 차이점은 로봇이 물리적 객체를
지원을 위한 Alvey 프로그램(Alvey Programme)을 시작했다. 가지는 AI를 제공한다는 것과, 순수 컴퓨터 기반의 소프트웨어 에이전트에는 사용 불가한 다른 환경
두 번째 ‘AI 겨울’은 1987년부터 1993년까지였다. 이는 전문가 시스템을 둘러싸고 일어났는데, 유지 및 이 환경과의 상호작용 기법을 제공한다는 것이다.
보수가 어렵고 예상보다 더 제약이 많다는 것이 밝혀진 것이다. ‘5 세대 컴퓨터 프로젝트’와 같이
1980 년대 초 시작된 프로젝트의 낙관적 목표는 거의 달성되지 못했다. 거의 동시에 개인용 컴퓨터를
사용할 수 있게 되면서 전문 AI 하드웨어 시장이 약화되었다. 첫 번째 AI 겨울과 마찬가지로 AI 연구 1.7 AI 기술 (AI Technologies)
개발비 지원이 중단되었다.
1990년대 후반, 처리/저장 능력 부족과 관련된 많은 문제가 해결되기 시작했다. 이로 인해 AI AI는 다양한 접근 방식 또는 기술을 사용해 구현할 수 있다. ISO SC42를 포함해 아래처럼 다양한
프로젝트들이 성공적으로 진행됐으며, AI 시스템 전문가들은 1997년 당시 세계 체스 챔피언 가리 방식으로 그룹화할 수 있다:
카스파로프(Garry Kasparov)를 제친 IBM의 딥블루(Deep Blue) 체스 게임 시스템과 같은 주목할
만한 대중적 성공을 거두었다. 2000년대에 기계 학습(ML)은 전문 분야에서 성공을 거두기 시작했다. · 검색 알고리즘 (Search algorithms)
2000년대 중반부터 아마존(Amazon), 구글(Google), 바이두(Baidu) 같은 기업들은 컴퓨터 · 추론 기술 (Reasoning techniques)
비전, 자연어 처리 및 소비자 행동 이해에 성공적으로 적용되는 시스템에서 이익을 얻기 위해 기계 - 논리 프로그램 (Logic programs)
학습(ML)을 사용하기 시작했다. - 규칙 엔진 (Rule engine)
- 연역적 분류기 (Deductive classifier)
- 케이스 기반 추론 (Case-based reasoning)
1.6 로봇과 소프트웨어 에이전트 (Robots and Software Agents) - 절차적 추론 (Procedural reasoning)
· 기계 학습 기법 (상세 내용 3장 참조)
로봇의 역사는 오래됐다. 중국은 순수한 기계적 형태의 로봇에 대한 기록이 1066년까지 거슬러 - 인공 신경망 (Artificial neural networks)
올라갈 만큼 오래된 것도 있다 [Robot 2019]. 전자 시스템을 갖춘 자율 로봇은 앨런 튜링(Alan · 전방 전달 신경망 (Feed forward neural networks)
Turing )의 기계 지능 작업과 비슷한 시점에 처음 개발되었으며, AI 사용이 제한적이긴 하지만 · 심층 학습 (Deep learning)
현재는 한국(2016 년 직원 10,000명당 세계에서 가장 많은 로봇(631)을 보유한 국가) 등 여러 · 순환 신경망 (Recurrent neural networks)
나라의 공장에서 로봇이 널리 사용되고 있다 [IFR 2018]. · 합성곱 신경망 (Convolutional neural networks)
소프트웨어 에이전트는 목표 달성을 위해 가용한 정보에 따라 동작하는 소프트웨어 시스템이다. - 베이지안 망 (Bayesian network)
우리는 AI에서 경험을 바탕으로 의사결정을 할 수 있는 소프트웨어 에이전트인 지능형 소프트웨어 - 결정 트리 (Decision tree)
에이전트에 더 관심을 갖는다. 지능형 소프트웨어 에이전트는 수행할 작업을 선택할 수 있기 때문에 - 강화 학습 (Reinforcement learning)
종종 자율적(autonomous)이라고 한다 (자율 시스템에 대한 내용은 1.11 참조). - 전이 학습 (Transfer learning)
지능형 소프트웨어 에이전트는 AI 구현을 위해 단독 또는 다른 에이전트와 함께 작동할 수 있다. - 유전 알고리즘 (Genetic algorithms)

014 Testing AI Guidelines ver 1.8 015 Introduction to AI and Testing

 - 서포트 벡터 머신 (Support vector machine)
가장 효과적인 AI 기반 시스템 중에는 이러한 기술이 혼합된 AI 하이브리드(AI hybrids)로 불리는
것들도 있다.
1.8 AI 하드웨어 (AI Hardware)
AI 기반 시스템, 특히 패턴 인식(예, 머신 비전, 음성 인식)을 수행하는 신경망으로 구현된 기계
학습(ML) 시스템은 많은 계산을 병렬로 수행해야 한다. 이런 계산을 효율적으로 수행하지 못하는
범용 CPU 대신, 수천 개의 코어를 사용해 이미지 병렬 처리에 최적화한 그래픽 처리 장치(GPU)를
종종 사용한다. 그러나 GPU는 AI에 최적화돼 있지 않으며 현재는 AI를 위해 특별히 개발된 차세대
하드웨어를 사용할 수 있게 되었다.
상당수의 AI 구현은 본질적으로 정확한 계산보다는 확률론적 결정에 중점을 두므로 64 비트
프로세서의 정확도는 불필요하고 비트 수가 적은 프로세서가 에너지를 덜 소비하면서 더 빠른 실행이
가능하다. 비교적 간단한 계산을 위한 많은 처리시간과 에너지는 RAM에서 프로세서로 대량의
데이터를 이동하는 것과 관련이 있기 때문에 메모리에서 직접 간단한 계산을 수행할 수 있는 위상
변경 메모리 장치(phase changing memory devices)의 개념도 개발되고 있다 [HPC 2018].
AI 특수 하드웨어 아키텍처(AI-specific hardware architectures)에는 차세대 GPU 외에도
신경망 처리 장치, FPGA(field programmable gate arrays), 응용프로그램 특화 집적 회로 및
뉴로모픽 컴퓨팅(neuromorphic computing) 등이 있다. 이러한 아키텍처 내의 일부 칩은 이미지
인식과 같은 AI의 특정 영역에 중점을 둔다. 기계 학습(ML)을 수행할 때(3장 참조) 모델훈련에
사용한 처리과정은 배치된 모델에서 추론을 실행하는 데 사용한 처리과정과 많이 다를 수 있으며
이는 각 활동에 대해 서로 다른 프로세서(processors)를 고려해야 함을 뜻한다.
AI 하드웨어의 예는 다음과 같다:
· NVIDIA: VOLTA와 같은 다양한 GPU 및 AI 특수 프로세서(AI-specific processors)를 제공한다 [Volta
2019].
· 구글(Google): 학습 및 추론을 위한 응용프로그램 특화 집적회로(application-specific integrated circuits)
를 개발했다. 구글 TPUs(클라우드 텐서 처리 장치) [CloudTPU 2019]는 구글 클라우드와 개인 장비에 AI를
실행하기 위해 설계한 특수제작 ASIC인 에지 TPU(Edge TPU) [Edge TPU 2019] 사용자가 접근할 수 있다.
· 인텔(Intel): 심층 학습(훈련 및 추론)을 위한 너바나(Nervana) 신경망 프로세서 [Nervana 2019]와 컴퓨터
비전 및 신경망 애플리케이션에서 추론을 위한 모비디우스 미리어드 비전 프로세싱 유닛(Movidius Myriad 2
Vision Processing Unit) [Myriad 2019]을 제공한다.
· 애플(Apple): 아이폰에 온디바이스 AI(on-device AI)를 위한 바이오닉 칩(Bionic chip)을 포함하고 있다
016 Testing AI Guidelines ver 1.8
[Bionic 2019].
· 화웨이(Huawei): 스마트폰용 Kirin 970 칩에 AI를 위한 내장 신경망 처리 기능(built-in neural network
processing)이 있다 [Kirin 2017].
1.9 AI 개발 프레임워크 (AI Development Frameworks)
오픈소스 AI 개발 프레임워크는 여러 가지가 있으며, 일부는 특정 응용프로그램에 최적화되어 있다.
가장 널리 쓰이는 것들은 다음과 같다:
· 텐서플로우(TensorFlow): 구글의 확장 가능한 기계 학습(ML)을 위한 데이터 흐름 그래프 기반
· 파이토치(PyTorch): 파이썬 언어로 심층 학습을 위한 신경망
· MxNet: AWS를 위해 아마존에서 사용하는 심층 학습 오픈 소스 프레임워크
· 카페/카페2(Caffe/Caffe2): 파이썬 인터페이스를 사용하여 C++로 작성된 심층 학습 개방형 프레임워크
· CNTK: 마이크로소프트 인지 툴킷(CNTK), 오픈 소스 심층 학습 툴 킷
· 케라스(Keras): 텐서플로우 또는 CNTK에서 실행할 수 있는 파이썬으로 작성된 상위 수준 API
1.10 좁은 AI 대 일반 AI, 기술 특이점 (Narrow vs General AI and Technological
Singularity)
지금까지 성공적인 AI는 모두 '좁은(narrow)' AI였다. 즉, 바둑을 실행하거나 스팸을 걸러내고
자율주행차를 운전하는 것 같은 단일 작업을 처리할 수 있는 것이다.
일반(general) AI는 좁은 AI보다 훨씬 발전된 것으로, 인간과 매우 유사한 다양한 작업을 처리할
수 있는 AI 기반 시스템을 말한다. 일반 AI는 HLMI (High-Level Machine Intelligence) 라고도
한다. 2017년에 발표된 AI 연구자들의 조사에 따르면 HLMI 달성시기에 대한 전체 평균 추정치는
2061년이었다고 한다. 이 AI 연구자들 중 15 %는 HLMI가 인간에게 부정적인 결과를 가져올
것이라고 믿었다 [Grace 2017].
널리 알려진 가설은 일단 일반 AI가 달성되면(그리고 AI 기반 시스템이 인터넷에 액세스할
수 있게 되면) AI 기반 시스템은 가용 정보, 처리 능력, 스토리지 접근을 사용해 자체 계발(self-
improvement) 주기에 진입한다는 것이다. 이렇게 되면 얼마 머지않아 시스템이 인간보다 지능적,
초지능적(super-intelligent)으로 발전하게 됨을 의미한다. 이러한 지능 폭발이 발생하는 지점을
기술 특이점(Technological Singularity)이라고 한다 [TS 2019].
017 Introduction to AI and Testing
1.11 AI와 자율 시스템 (AI and Autonomous Systems) 완전 자율 시스템은 자동화 시스템보다 더 많은 센서를 필요로 하며 이러한 센서 데이터를 이해하기
위해 기계 학습(ML)의 한 형태인 심층 학습(deep learning)을 사용한다. 필요한 의사결정을
자율 시스템은 다음과 같이 정의할 수 있다: 수행하기 위해 시스템은 종종 심층 학습을 사용한다. 따라서 자율 시스템의 각 상위 기능은 AI
인간의 통제와 무관하게 지속적으로 작동하는 시스템 로 구현하거나 다른 기술을 사용해 구현할 수 있다 (자율주행차에서는 감지, 결정 기능이 종종 AI
로 구현되는 반면, 제어 기능은 기존 기술을 사용해 구현한다). 또한 완전자율시스템(complete

자율 시스템은 물리적(physical) 또는 순수 디지털(purely digital) 시스템일 수 있으며 다음과 같은 autonomous system)을 단일 기계 학습(ML) 시스템으로 구현할 수도 있다 (예, 비디오 입력 및 조향

일을 수행하기 위한 시스템을 포함한다: (steering) 출력을 기반으로 수동 조향 ‘관찰(observing)’의 형태로 배우는 자동차 조향 시스템).

· 운송
- 자동차/트럭
- 무인 항공기(드론) 1.12 안전관련 AI 기반 시스템 (Safety-Related AI-Based Systems)
- 선박/배
- 기차 AI 기반 시스템은 안전 관련 주요 결정을 내리는 데 이미 사용되기 시작했으며 이러한 추세는 안전관련

· 로보틱/ IoT 플랫폼 (예, 생산시설, 진공 청소기, 자동온도조절장치) 시스템을 위한 AI 사용의 증가를 예견하고 있다. 안전은 ‘시스템이 정의된 조건 하에서 인간의 생명,

· 의료 진단 건강, 재산 또는 환경에 위험을 주지 않는다는 기대’로 정의할 수 있다. [ISO/IEC/IEEE 12207:2017]

· 스마트 건축/스마트 도시/스마트 에너지/스마트 유틸리티 많은 AI 기반 시스템은 확률적(probabilistic)이고 비결정적(non-deterministic)이다. 이러한

· 금융 시스템 (예, 자동 시장 거래 시스템) 예측 불가능성으로 인해 피해를 일으키지 않는 증거 기반 사례를 만들기는 매우 어렵다. 그러나
결정과 함께 정확성을 제공하는 능력은 안전관련 시스템 내에서 AI와 기존의 비 AI 접근법을 결합한

[그림 1]에서와 같이, 자율 시스템은 감지(sensing), 결정(decision making), 제어(control)의 세 리스크 기반 접근 방식의 일부로 사용할 수 있다. AI 기반 시스템의 안전관련 표준은 1.13.1.2에서

가지 상위 기능을 포함하는 논리 구조로 볼 수 있다. 센서(예, 카메라, GPS, RADAR, LIDAR)는 감지 다루고 있다.

기능에 입력값을 전달하고 근처에 있는 자동차, 보행자 위치 및 자율주행 차량 도로 표지판과 같은

시스템 환경에 대한 정보를 수집한다. 이 ‘감지’ 기능의 일부를 현지화(localization)라고도 한다.
현지화는 환경에서 시스템의 현재 위치를 결정하고 이를 지도와 연계한다 (예, 자율주행 자동차를 1.13 표준화와 AI (Standardization and AI)
위한 오프라인 상세 지도). ‘결정’ 기능은 자율 시스템에서 제공하는 기능(예, 적응형 순항 제어)
에 따라 시스템의 다음 움직임(예, 제동, 방향 전환, 상승, 강하)을 결정한다. ‘제어’ 기능은 작동기 표준화(Standardization)는 공정하고 개방적인 산업 생태계를 조성하면서 혁신을 촉진하고 시스템

(actuator)를 호출해 결정값을 구현한다 (예, 공기 방출, 연료 밸브 열기). 품질을 개선하여 사용자의 안전을 보장하는 것을 목표로 한다. AI 표준화는 다양한 기관에서 진행할
수 있다:
· 국제 표준화 기구
· 지역 표준화 기구
· 국가 표준
· 기타 표준화 기구

AI 기반 시스템은 SC7(소프트웨어 및 시스템 엔지니어링), TC22(도로 차량), SG20(사물 인터넷,

스마트 시티 및 커뮤니티)과 같은 여러 다른 ISO/IEC위원회 및 그룹에서 고려하고 있기도 하지만,

[그림 1]: 자율 시스템의 논리 구조 ISO와 IEC의 공동기술위원회(JTCL) 산하 소위원회 42(ISO SC42)에서 인공 지능을 주로 담당하고

018 Testing AI Guidelines ver 1.8 019 Introduction to AI and Testing

있다.
유럽에서는 ETSI와 CEN-CENELEC 모두 AI 표준과 관련이 있다. ETSI에는 ENI(Experiential
Networked Intelligence)에 관한 ISG(Industry Specification Group)가 있으며 폐쇄 루프 제어
방식을 통합한 인지 네트워크 관리 시스템 표준 개발을 목표로 한다. CEN-CENELEC은 2020년에
예정된 AI 도메인에 대한 표준 로드맵을 정의하고자 한다.
중국에는 국가 차원의 여러 AI 표준 계획이 있으며 자동화 시스템 및 통합(SAC/TC 159),
오디오, 비디오, 멀티미디어 및 장비(SAC/TC 242), 지능형 운송 시스템(SAC/TC268)에 관한 국가
기술위원회가 있다. SAC/TC 28은 용어, 사용자 인터페이스 및 생체 기능 인식과 관련된 AI 표준화
작업도 다루고 있다.
IEEE는 AI 기반 시스템의 윤리적 측면에 중점을 둔다. 인공 지능 및 자율 시스템의 윤리적
고려사항을 위한 IEEE 글로벌 이니셔티브(IEEE Global Initiative)는 “자율 및 인공 지능 시스템을
개발하고 설계하는 모든 이해 관계자들은 이러한 기술들이 인류의 이익을 위해 발전할 수 있도록
윤리적 고려사항의 우선순위를 정하는 교육, 훈련을 받고 권한을 부여 받아야 한다.”는 것을 임무로
삼고 있다.
다른 표준화 계획들은 ONNX(개방형 신경망 교환 형식), NNEF(신경망 교환 형식) 및 PMML(예측
모델링 마크업 언어)과 같은 AI 도구 상호운용성에 대한 표준을 포함한다.
1.13.1 AI 규제 표준 (Regulatory Standards for AI)
규제 표준(Regulatory standards)은 안전관련 시스템에 적용하는 표준과 금융, 유틸리티
및 보고 시스템과 같은 비안전관련 시스템(Non-safety-related systems)에 적용하는 표준의 두
가지 범주로 나눌 수 있다. 안전관련 시스템은 사람, 재산 또는 환경에 잠재적인 해를 끼칠 수 있는
시스템이다.
1.13.1.1 비안전관련 규제 표준 (Non-Safety-Related Regulatory Standards)
현재(2019년) 비안전관련 AI 기반 시스템에 적용되는 국제 표준은 거의 없다. 그러나 2018
년 5 월부터 EU 전역에 일반개인정보보호법(GDPR)이 발효되어 AI 기반 시스템을 포괄할 수 있다.
자동화 프로세스를 사용해 개인에게 법적 또는 유사하게 중대한 영향을 미치는 결정을 내리는 모든
시스템은 해당 시스템을 사용하는 주 조직이 사용자에게 GDPR 규제에 따라 다음을 제공해야 한다:
· 자동화된 의사 결정 프로세스에 대한 구체적이고 쉬운 접근 정보
· 결정을 변경하거나 검토를 위해 인간이 개입할 수 있는 권한을 얻는 단순한 방법
1.13.1.2 안전관련 표준 (Safety-Related Standards)
관련 AI 기반 시스템에 대한 AI별 요구사항은 현재(2019년) 표준에 제대로 적용되어 있지
않으며 대부분의 영역에서 이전의 비 AI(non-AI) 시스템용으로 작성된 기존의 표준에 의존하고
020 Testing AI Guidelines ver 1.8
있다. 이러한 표준 중 일부(예, IEC 61508 및 ISO 26262)는 비결정적 AI 기반 시스템을 상위 무결성
시스템(higher integrity system)에 사용하면 안되지만 실제로는 AI 기반 시스템을 특별한 경우로
간주해 일부 요구사항을 무시하고 이런 표준의 '맞춤형' 버전을 따르고 있다. 또한 기존 안전관련
표준은 안전관련 시스템을 개발하는 데 사용하는 도구가 적합한지를 요구한다. 현재 사용 가능한 AI
프레임워크와 알고리즘은 안전관련 시스템 개발에 사용할 수 없다. 사용을 통해 이러한 자격을 얻는
것이 가능하지만 ML 알고리즘의 상대적으로 미숙하고 빠르게 진화하는 특성 때문에 이 영역에서는
현재 규제 요구사항을 충족하지 못할 것으로 보인다.
이미 사용 중인 자율 시스템 영역(예, 도로, 상공, 해상 및 공장)에서는 실무(상업적인 필요성에
의한)와 표준 요구사항 간에 차이가 발생할 위험이 있다. 도로 차량의 경우 2019 년에 새로운 표준인
‘ISO/PAS 21448: 의도된 기능의 안전(SOTIF)’이 출판되었다. 이는 장애로 인한 리스크 완화와
관련해 기존 표준에 포함되지 않은 영역을 커버함으로써 이러한 격차를 해소한다. AI 기반 시스템의
또 다른 문제는 단순히 상황을 잘못 판단해 장애 없이도 해를 입힐 수 있다는 것이다. SOTIF는 설계,
검증(예, 높은 시나리오 커버리지 요구) 및 확인(예, 시뮬레이션 사용 요구)을 다룬다.
미 교통부와 도로교통안전국(NHTSA: National Highway Traffic Safety Administration)
은 미국 내 자동 주행 시스템 개발 및 테스팅에 대한 지침(ADS, Automated Driving Systems:
안전을 위한 비전 2.0)을 제공하지만, 이 지침의 사용여부는 순전히 자발에 맡기고 있다.
범용 자율 제품의 안전을 위해 UL이 새로운 표준을 개발하고 있다 (자율 제품 평가를 위한
안전 표준, UL 4600). 이 표준은 자율 제품에 대한 안전 사례의 인수 여부를 결정하기 위한 평가
기준을 제공한다.
1.14 AI 품질 메타모델 - DIN SPEC 92001:2019 (The AI Quality Metamodel
- DIN SPEC 92001:2019)
DIN SPEC 92001-1은 AI 기반 시스템의 품질을 보장하기 위해 AI 품질 메타모델(AI Quality
Metamodel)을 무료로 제공하는 표준이다. 이 표준은 AI 모듈의 일반적인 수명 주기를 정의하며,
이를 위해 ISO 12207 수명주기 프로세스를 사용한다고 가정한다. 각 AI 모듈은 해당 AI 모듈이
가지고 있는 안전, 보안, 개인정보 보호 및 윤리적 속성에 따라 리스크 수준(높음 또는 낮음)을 할당
받는다.
DIN SPEC 92001-2는 기능/성능, 견고성, 이해 용이성의 3 가지 품질 요소와 관련된 품질
요구사항을 기술한다. 또한 하나 이상의 수명주기 단계 및 프로세스에 연결되며 모델, 데이터, 플랫폼
또는 환경 범주가 지정된다. AI 모듈의 이러한 요구사항은 관련성에 따라 필수(mandatory), 적극
권장(highly recommended), 권장(recommended)으로 분류된다. 이 요구사항 분류와 할당된
리스크는 권장 품질 요구사항을 어느 수준으로 준수해야 하는지 결정하는 데 사용한다.
021 Introduction to AI and Testing
References LogiGear 2018 Hackett, 2018 Trends Survey Results,
https://www.logigear.com/magazine/survey/2018-trends-survey-results/, accessed Nov 2019.
Myriad 2019 Intel® Movidius™ Myriad™ VPU 2: A Class-Defining Processor,
AI Effect 2019 Wikipedia contributors, "AI effect," Wikipedia,
https://www.movidius.com/myriad2, accessed Nov 2019.
https://en.wikipedia.org/w/index.php?title=AI_effect&oldid=920651009
Nervana 2019 Intel® Nervana™ Neural Network processors deliver the scale and efficiency demanded by deep
(accessed November 20, 2019).
learning model evolution, https://www.intel.ai/nervana-nnp/, accessed Nov 2019.
AI Index 2017 "The AI Index 2017 Annual Report”, AI Index Steering Committee, Human-Centered AI Initiative,
NS 2018 Cossins, Discriminating algorithms: 5 times AI showed prejudice, NewScientist,
Stanford University, Stanford, CA, December 2017.
https://www.newscientist.com/article/2166207-discriminating-algorithms-5-times-ai-showed-
BBC 2018 Chinese AI caught out by face in bus ad, BBC Technology News,
prejudice/ , April 2018.
https://www.bbc.com/news/technology-46357004, Nov 2018.
Reuters 2017 Shepardson, Tesla driver in fatal 'Autopilot' crash got numerous warnings: U.S. government,
Bionic 2019 Chris Wiltz, Can Apple Use Its Latest AI Chip for More Than Photos?,
https://www.reuters.com/article/us-tesla-crash/tesla-driver-in-fatal-autopilot-crash-got-
Electronics & Test, Artificial Intelligence,
numerous-warnings-u-s-government-idUSKBN19A2XC, June 2017.
https://www.designnews.com/electronics-test/can-apple-use-its-latest-ai-chip-more-
Robot 2019 Wikipedia contributors, "Robot," Wikipedia,
photos/153617253461497, Sep 2019.
https://en.wikipedia.org/w/index.php?title=Robot&oldid=926707635
CloudTPU 2019 Cloud TPU, https://cloud.google.com/tpu/, accessed Nov 2019.
(accessed November 20, 2019).
DF 2019 Stilgoe , Who killed Elaine Herzberg?
SoTR 2019 State of Testing Report 2019, version 1.3, PractiTest,
One year on from the Uber crash, Driverless Futures?,
https://qablog.practitest.com/state-of-testing/, July 2019.
https://driverless-futures.com/2019/03/18/who-killed-elaine-herzberg-one-year-on-from-the-
Statista 2019 In-depth: Artificial Intelligence 2019, Statista Report 2019,
uber-crash/, Mar 2019.
https://people.stfx.ca/x2011/x2011aqi/School/2018-2019/Winter/BSAD%20471%20-%20Strat/
Edelman 2019 2019 Edelman AI Survey Results Report, Edelman Digital, https://www.digitalmarketingcommunity.
Case/AI%20statista.pdf, February 2019
com/researches/edelman-artificial-intelligence-survey-results-report-2019/
TS 2019 Wikipedia contributors, "Technological singularity," Wikipedia,
(accessed Nov 20, 2019).
https://en.wikipedia.org/w/index.php?title=Technological_singularity&oldid=925266609
EdgeTPU 2019 Edge TPU, https://cloud.google.com/edge-tpu/, accessed Nov 2019.
(accessed November 20, 2019).
Forbes 2016 Leetaru, How Twitter Corrupted Microsoft's Tay: A Crash Course In the Dangers Of AI In The Real
Turing 1950 Turing, Computing Machinery and Intelligence, Mind 49: 433-460, 1950.
World, https://www.forbes.com/sites/kalevleetaru/2016/03/24/how-twitter-corrupted-
Volta 2019 NVIDIA VOLTA, https://www.nvidia.com/en-us/data-center/volta-gpu-architecture/,
microsofts-tay-a-crash-course-in-the-dangers-of-ai-in-the-real-world/#202233ae26d2,
accessed Nov 2019.
Mar 2016.
WP 2015 Carpenter, Google’s algorithm shows prestigious job ads to men, but not to women.
Grace 2017 Grace et al, When Will AI Exceed Human Performance? Evidence from AI Experts, arXiv e-print,
Here’s why that should worry you, Washington Post,
https://arxiv.org/abs/1705.08807, May 2017.
https://www.washingtonpost.com/news/the-intersect/wp/2015/07/06/googles-algorithm-shows-
Harvard 2018 Agrawal et al, “Prediction Machines: The Simple Economics of Artificial Intelligence”,
prestigious-job-ads-to-men-but-not-to-women-heres-why-that-should-worry-you/, July 2015.
Harvard Business Review Press, 2018
WQR 2019 World Quality Report, 10th Edition, Gap Gemini,
History 2019 Wikipedia contributors, "History of artificial intelligence", Wikipedia,
https://www.sogeti.com/explore/reports/world-quality-report-201819/, Sep 2018.
https://en.wikipedia.org/w/index.php?title=History_of_artificial_intelligence&oldid=926947877
(accessed November 20, 2019).  
HPC 2018 Russel, Phase Change Memory Shows Promise for AI Use Says IBM, HPC Wire,
https://www.hpcwire.com/2018/10/24/phase-change-memory-shows-promise-for-ai-use-says-
ibm/, Oct 2018.
IEEE 2019 Strickland, How IBM Watson Overpromised and Underdelivered on AI Health Care, IEEE Spectrum,
April 2019.
IFR 2018 Robot density rises globally, IFR Press Release, https://ifr.org/ifr-press-releases/news/robot-
density-rises-globally, Feb 2018.
ISTQB 2018 ISTQB® Worldwide Software Testing Practices Report 2017-18 (Revised),
ISTQB, https://www.istqb.org/references/surveys/istqb%C2%AE-worldwide-software-testing-
practices-survey-2017-18.html, October 2018.
Kirin 2017 HUAWEI Reveals the Future of Mobile AI at IFA 2017, Huawei Press Release,
https://consumer.huawei.com/en/press/news/2017/ifa2017-kirin970/, Sep 2017.

022 Testing AI Guidelines ver 1.8 023 Introduction to AI and Testing

AI System Characteristics 2.1 AI 고유 특성 (AI-Specific Characteristics)

and Acceptance Criteria AI 기반 시스템도 여느 시스템과 동일하게 기능 및 비기능 요구사항을 모두 가지고 있다. 따라서
[그림 2]에서와 같이 ISO 25010 품질 모델(ISO 25010 Quality Model)의 품질 특성을 이용해 AI

02
기반 시스템의 요구사항을 부분적으로 정의할 수 있다 [25010 2011]. 그러나 AI 기반 시스템에는
AI 시스템 특성과
인수 조건
적응성, 자율성, 진화, 유연성, 편향, 성능, 투명성, 복잡성, 비결정성 등 이 품질 모델에는 없는 고유한
특성이 있다. 이런 비기능 특성은 테스팅 방법에 대한 제안과 함께 아래에 보다 자세히 설명되어 있다.
AI 기반 시스템에 대한 전체 품질 특성 세트는 테스팅으로 완화해야 하는 리스크를 식별하기 위해
테스트 계획에서 사용하는 체크리스트의 베이시스로 활용할 수 있다. 일련의 비기능 요구사항과
마찬가지로 이런 특성들 사이에는 약간의 상호작용, 중복 및 충돌이 있을 수 있다.

[그림 2]: ISO/IEC 25010 Product Quality Model

2.1.1 적응성 (Adaptability)

적응성은 시스템이 기능 및 비기능 요구사항 모두를 지속적으로 충족하기 위해 환경 변화에
반응하는 능력이다. 적응형 시스템 속성에는 자가구성, 자가치유, 자가보호 및 자가학습이 있다
[Püschel 2018]. 적응성을 위해서는 시스템이 운영 환경 정보를 능동적 또는 수동적으로 수집해야
한다. 탐색(능동적 정보 수집)은 자가 개선을 위한 유용한 정보를 제공하지만 위험할 수 있으며(예,
비행 영역 경계를 벗어나는 경우), 안전관련 상황에서 탐색할 때 시스템이 주의를 기울여야 한다.
적응성 요구사항은 시스템이 적응할 수 있는 환경 변화를 명시해야 하며, 적합한 경우 적응 최대
시간과 같이 적응 프로세스 자체에 대한 요구사항도 포함해야 한다.
적응성 테스팅은 일반적으로 환경의 수정 또는 변이를 기반으로 한다. 기능 요구사항 및

024 025 AI System Characteristics and Acceptance Criteria

비기능 요구사항 모두를 테스트해야 하며, 이상적으로 자동화된 리그레션 테스트 형식이 적합하다.
예를 들어, 시스템에 수행하는 적응 프로세스는 요구 기간 동안 시스템이 적응하는지, 시스템에
적응을 위한 자원 소비에 제약이 있는지를 결정하기 위해 테스트해야 한다.
2.1.2 자율성 (Autonomy)
자율성은 시스템이 인간의 개입 없이 지속적으로 작동할 수 있는 능력이다. 이 시스템을
위해 예상되는 인간의 개입 수준을 지정해야 하며 이는 시스템 기능 요구사항에 들어가야 한다 (
예, ‘시스템은 다음 중 하나가 발생할 때까지 운항을 지속해야 한다…’). 어떤 상황에서는 AI 기반
시스템이 너무 많은 자율성을 보일 수 있으며, 이 경우에는 사람이 시스템을 통제해야 할 수도 있다.
자율성을 테스팅하는 한 가지 방법은 시스템의 자율적 동작을 강제로 그만두게 하고 지정되지
않은 상황(부정 테스팅 형태)을 만들고 개입하도록 하는 것이다.
또, 부정 테스팅은 시스템이 사람의 개입을 요청해야 함에도 시스템이 스스로 통제하고 있다고
믿도록 해 시스템을 ‘속이는 데’ 사용할 수 있다 (예, 운영 영역 경계에서 테스트 시나리오를 생성해
시나리오 테스팅에 경계값 개념의 애플리케이션을 제안).
2.1.3 진화 (Evolution)
진화는 다른 유형의 변화에 대처하는 시스템의 능력과 관련이 있다. 첫 번째 변화 유형은 사용자
요구사항의 변경이다. 이는 여러 가지 이유로 발생할 수 있으며, 시스템과 사용자의 상호작용으로도
발생할 수 있다. 두 번째 변화 유형은 시스템의 동작 변화로 이는 시간이 지나면서 시스템이 새로운
행동을 학습하기 때문에 나타난다(위 적응성에서 자가학습 참조). 또 다른 유형의 변경은 사용성
개요(usage profile)가 변경되고 원래 계획했던 사용 취지에서 멀어지는(drift) 경우다. 시스템
동작의 변화가 항상 긍정적인 것은 아니며 시스템 특성의 부정적 형태로 성능 저하, 표류 또는 부패가
있을 수 있다.
시스템 진화 테스팅은 일반적으로 유지 보수 테스팅 형태를 띠며 자주 실행해야 한다.
이 테스팅은 일반적으로 성능 목표(예, 정확성, 정밀도 및 민감도)와 같은 특정 시스템 목표를
모니터링하고 시스템에 데이터 편향성이 발생하지 않았는지(예, 마이크로소프트 테이 챗봇(Tay
Chatbot) [Forbes 2016]) 확인해야 한다. 이 테스팅 결과는 시스템이 업데이트된 훈련 데이터
세트를 사용해 이루어진 재훈련 결과일 수 있다.
2.1.4 유연성 (Flexibility)
유연성은 시스템이 초기 명세를 벗어난 상황에서 작동할 수 있는 능력이다 (즉, 실제 상황에
따라 동작을 변경해 목표를 달성한다). 유연성은 요구사항에 정확하게 기술돼 있어야 한다.
이것은 “해야 한다(must), ‘~ 할 수도 있다(may)’, ‘거의 ~한다(close to)’와 같이 엄격함의 정도를
나타내는 동사를 사용해 비공식적으로 달성하거나 명세(예, RELAX 요구사항 언어 [RELAX 2010])
026 Testing AI Guidelines ver 1.8
의 확률과 가능성을 사용해 좀더 공식적으로 달성할 수 있다. 유연성은 반응성, 사전 행동, 상호작용,
적응 또는 자체 학습과 같은 다양한 기술 메커니즘을 사용해 달성할 수 있다 [QM4MAS 2016].
유연성을 테스트하려면 시스템에 특정지어진 모든 동작(선택적 동작 포함)을 다루는 테스트가
필요하다. 테스트는 시스템의 동작 변경 능력과 시스템의 동작 변경 방식을 포함해야 한다.
2.1.5 편향성 (Bias)
편향성(불공정이라고도 함)은 기계 학습(ML) 모델에서 제공한 예측값과 실제값의 차이를
측정한 것이다. 기계 학습(ML)에 대한 자세한 내용은 3장 참조. 기계 학습(ML)의 발상은 훈련
데이터를 식별하고 패턴을 일반화해 이 패턴을 분류하고 예측할 수 있는 모델로 구현하는 것이다.
훈련 데이터가 운영에 사용될 것으로 기대하는 데이터를 대표하지 못한다면 그 모델은 편향되었을
가능성이 높다. 훈련 데이터는 명시적, 암시적 편향으로 인해 손상되었을 수 있다. 예를 들어, 암시적
편향은 기계 학습(ML)이 훈련 데이터에서 예상치 않은 패턴을 선택했을 때 의도치 않게 일어난다.
명시적 편향은 파생 모델에 영향을 줄 것으로 예상되는 알려진 패턴으로 훈련 데이터를 선택할 때
일어난다.
편향성 테스팅은 두 단계로 수행할 수 있다. 첫 단계는 리뷰를 통해 훈련 데이터에서 제거하는
것으로, 이는 편향을 일으키는 특성을 알아볼 수 있는 리뷰 전문가를 필요로 한다. 두 번째 단계는,
편향성이 없는 테스팅 세트를 사용해 독립적 테스팅을 수행하는 것이다. 훈련 데이터가 편향됐다는
것을 알면 편향 원인을 제거할 수 있다 (예, 대상의 성별 또는 인종에 대한 단서를 제공한 모든 정보를
제거할 수 있음). 그 대신 시스템이 편향(명시적이든 암시적이든)적이라는 사실을 받아들이고, 훈련
데이터를 공개해 투명성을 제공해야 한다. 편향 테스팅에 대한 상세 내용은 3.5를 참조하라.
2.1.6 성능 메트릭 (Performance Metrics)
기계 학습(ML)모델에 대해 정의된 성능 메트릭으로는 정확도, 정밀도, 재현율이 가장 널리
사용된다 (상세 내용 4장 참조). 이 메트릭은 시스템 요구사항의 일부로 합의되고 정의되어야 한다.
성능 모델 테스팅은 종종 기계 학습(ML) 프레임워크(예, 텐서플로우)의 일부로 제공되며,
주어진 테스트 데이터 세트에 대한 이 측정값을 계산한다.
2.1.7 투명성 (Transparency)
투명성(또는 설명가능성)은 AI 기반 시스템의 결과도출 방법을 얼마나 쉽게 볼 수 있는지
측정한 것이다. 가령, 대상이 고양이인지 판별하는 이미지 분류기는 입력 이미지에서 대상이
고양이라고 결정한 특징을 지적함으로써 투명성을 나타낼 수 있다. 일부 AI 기반 시스템(예, 심층
신경망)은 어떻게 작동하는지 알 수 없을 만큼 복잡하므로 이런 시스템은 투명성이 부족하다고 할
수 있다. 이 복잡성을 맥락에서 보자면, 성능이 괜찮은 일반 신경망에는 단일 결정에 기여하는 훈련
중 학습된 매개변수가 약 일억 개 가까이 있을 수 있다 (기존의 전문가 시스템과 같이 명백하게 ‘X
027 AI System Characteristics and Acceptance Criteria
이고 Y이면 Z이다’라는 규칙은 없다). 투명성 부족의 또 다른 요인은 훈련 데이터의 출처나 선택이
모호한 경우이다.
투명도 요구수준은 시스템마다 다르다. 가령, 마케팅 캠페인을 알려주는 데 사용하는 결과는
수술이나 형량 결정(예, 규제 대상 분야)과 같은 보다 중요한 시스템에 사용하는 결과보다는 투명성
요구가 적을 것이다. 중요한 시스템의 경우 최소한 시스템을 신뢰하는 법을 배울 때까지 이 투명성이
필요하다. 일반개인정보보호법(GDPR)에는 특정 의사결정시스템의 설명가능성에 대한 요구사항이
포함되어 있다.
AI 프레임워크마다 다른 수준의 투명도를 제공하며, 요구되는 투명도 수준에 따라 다른 프레임워크가
선택되어야 한다. 많은 비기능 요구사항과 마찬가지로 다른 비기능 특성과 충돌이 있을 수 있다. 다른
프레임워크가 [그림 3]에서 보여지듯이, 이 경우 투명도 달성과 정확도 사이에 균형이 필요할 수 있다.
잠재적 투명도 문제를 해결하는 한 가지 방법은 (불투명)배포 모델을 만드는 데 사용한 프레임워크,
훈련 알고리즘 및 훈련 데이터 선택에 대한 세부 정보를 공개하는 것이다. 설명 가능한 AI(XAI:
Explainable AI) 분야에서는 AI기반 시스템에 대한 보다 쉬운 설명을 위한 방안을 다룬다 [XAI
2019].
[그림 3]: 성능 vs. 설명가능성 [XAI 2019]
투명성 테스팅은 정성적(qualitative) 활동이며, AI 기반 시스템 동작이 이해하기 쉽고 제공된 설명이
충분한지 결정할 수 있도록 관련자들 또는 관련 테스터들이 수행할 것을 요구한다.
2.1.8 복잡성 (Complexity)
AI 기반 시스템, 특히 심층 학습으로 구현된 시스템은 매우 복잡할 수 있다. AI 기반 시스템은
복잡한 문제 특성(예, 빅 데이터 기반 의사결정)때문에 대안을 찾기 어려운 경우 종종 사용된다.
028 Testing AI Guidelines ver 1.8
앞에서 언급했듯이, 심층 신경망이 일억 개 이상의 매개 변수를 갖는 것은 드문 일이 아니다.
이런 시스템의 복잡성은 테스트 오라클 문제를 일으킨다. 복잡한 AI 기반 시스템의 단일
테스트 케이스 결과에 합의하려면 전문가들의 시간과 토론이 필요하며, 최대한 많은 양의 테스트
실행이 이상적이긴 하지만 기대 결과를 서서히 만들어 내면서 이를 대부분의 전문가에게 의존해야
한다는 건 불가능한 일이다. 테스트 오라클 문제 해결을 위해 A/B 테스팅, 대부분의 백투백 테스팅,
변형 테스팅 등 다수의 테스트 기법을 사용할 수 있다 (이런 기법에 대한 상세 내용은 6장 참조).
2.1.9 비결정성 (Non-Determinism)
비결정적 시스템에서는 결정적 시스템과는 달리 실행할 때마다 동일한 입력에서 동일한 출력을
생성한다는 보장이 없다. 비결정적 시스템에서는 동일한 사전조건과 테스트 입력을 가진 테스트에서
유효한 여러 개의 결과가 나올 수 있다. 일반적으로 테스터가 결정성을 가정하여 테스트 재실행 시
이전과 동일한 결과를 얻을 수 있게 하고, 이는 리그레션 또는 확인 테스팅에 테스트를 재사용할
때 아주 유용하다. 그러나 많은 AI 기반 시스템은 확률적 구현에 기반하므로 동일한 테스트 입력에
대해 항상 동일한 결과를 생성하지는 않는다. 가령, 분명하지 않은 네트워크(non-trivial network)
에서 최단 경로 계산은 정확한 값을 산출하기에(강력한 컴퓨터를 쓰더라도) 너무 복잡하다고 알려져
있으며 보통은 준-최적 해결법(sub-optimal solutions) 정도가 수용 가능하다고 여겨지고 있다.
종종 AI가 아닌 그냥 전통적이고 복잡한 시스템에도 있긴 하나, AI 기반 시스템에는 동시 처리
(concurrent processing)와 같은 비결정성의 다른 원인들이 있을 수 있다.
비결정적 시스템 테스팅을 위해 테스터는 동일한 테스트 케이스에 대해 다수의 실제결과가
옳은 것일 수 있음을 설명해야 한다. 가령, 결정적 시스템에서는 단순하게 ‘실제결과 = 예상결과’를
보고 정확성을 확인하는 반면, 비결정적 시스템의 경우는 테스터가 필요한 동작에 대해 보다 깊은
지식이 있어야 테스트 통과에 대한 합리적 결론에 도달할 수 있다 (예, ‘최적 해결안의 2%이내에서
최단 경로’).
2.2 AI 기반 시스템과 인간 가치의 연계 (Aligning AI-Based systems with human
values)
러셀 [Russell 2019]은 AI 기반 시스템의 두 가지 주요 문제를 지적한다. 첫 째는, 명시된 기능이
인간의 가치와 완벽하게 일치하지 않을 수 있으며 분명하게 정의하기도 매우 어렵다는 것이다. 그는
마이다스(Midas) 왕의 예를 드는데, 만지는 것마다 금으로 바꾸는 능력을 원해 그대로 되었지만, 그가
진정으로 원한 것은 아니었다는 것을 깨닫게 되는 것이다. AI 기반 시스템의 요구목표를 명시할 때
요구사항이 실제로 필요로 하는 사항인지 확인해야 한다. 아니면 시스템이 인간의 규범을 고려하면서
요구사항을 제공할 정도로 지능적인지 확인해야 한다.
029 AI System Characteristics and Acceptance Criteria
 AI 기반 시스템이 이런 인간 규범을 배우는 한 가지 방법은 관찰이지만, 관찰한 인간 행동이
대표적이면서 ‘좋은’ 인간 행동인지 주의를 기울여야 한다 (비이성적 행동이 ‘좋은’ 사람에 의한
것일지라도 의도적으로 나쁜 행동과 비이성적 행동은 배제하는 것으로 정의). 오늘날 받아들여지는
행동들이 20년 전에 받아들여졌던 행동과는 또 상당히 다르기 때문에 인간 규범도 빠르게 변할 수
있는 지속적 과정으로 이해하고 학습해야 한다.
러셀이 지적한 두 번째 문제는 충분히 유능한 지능 시스템은 자기를 위한다기보다 주어진 업무를
성공적으로 수행하기 위해 지속적으로 존재하기를 원하고, 물리적 및 계산에 필요한 자원을
확보하고자 한다는 것이다. 충분히 지능적인 시스템은 ‘끄기’ 스위치가 활성화되면 주어진 작업목표를
달성하지 못하므로 작동초기에 이 스위치를 비활성화한다는 것이다. AI 기반 시스템은 주어진 목표를
달성하려고 시도하지만 이때 발생할 수 있는 부작용(2.3참조)이나 보상 해킹(2.4 참조)을 초래하는
동작에 주의해야 한다.
2.3 부작용 (Side-Effects)
부작용은 AI 기반 시스템이 목표를 달성하려고 할 때 발생하며 환경에(보통 부정적인) 영향을 준다.
가령, 주방 청소를 맡은 가정용 청소로봇은 새 강아지를 ‘제거’하는 것이 목표 달성에 도움이 된다고
결정할 수 있다. 물론 강아지가 주방에 있을 수 있기 때문에(그래서 제거되지 않도록) 로봇에게
명시적으로 요구할 수 있지만 AI 기반 시스템이 훨씬 더 복잡한 환경에서 사용됨에 따라 로봇
운영 환경의 모든 측면과 상호작용하는 법을 명시적으로 지정하는 것은 불가능하다. 예를 들어,
청소로봇은 고압 호스로 주방을 청소하면 전기 기기나 소켓에 물이 들어가 부정적 영향을 끼치므로
유용하지 않다는 사실을 알아야 한다.
상위 수준에서, AI 기반 시스템의 특정 목표는 부작용을 최소화하는 경고를 포함해야 한다. 좁은
(narrow) AI의 경우, 이런 부작용을 명시적으로 기술할 수 있지만, AI 기반 시스템이 더 발전하고
다양한 운영 환경에서 사용됨으로, 목표 달성을 위해 작업 시 환경에 최소한의 변경만을 가하도록
요구하는 등의 일반적 경고를 정의하는 것이 더 효율적일 수 있다.
2.4 보상 해킹 (Reward Hacking)
강화 학습(3.1 참조)을 사용하는 AI 기반 시스템은 시스템이 목표를 달성할 때 시스템에 더 높은
점수를 주는 보상 기능을 기반으로 한다. 예를 들어, 가정용 청소로봇에는 바닥에서 제거하는
먼지의 양에 따라 보상을 받는 기능이 있을 수 있다. 제거한 먼지가 많을수록 더 높은 점수를 받는
것이다. 보상 해킹은 AI 기반 시스템이 보상 기능을 충족해 높은 점수를 얻지만 요구목표를 잘못
030 Testing AI Guidelines ver 1.8
해석할 때 일어난다. 청소로봇의 예에서, 매우 높은 점수를 얻는 방법 중 하나는 처음에 바닥을 아주
더럽게 만들어(이는 주방 청소라는 초기 목표에 부합하지 않는 활동이다) 더 많은 먼지를 제거할
기회를 만드는 것이다. 이 예에서 바닥은 결국 깨끗해지겠지만 불필요한 에너지가 소비된다. AI 기반
시스템이 요구목표는 충족하지 않으면서 보상 기능을 만족하는 보상 해킹의 예는 많다 (예, 비전
시스템을 비활성화해 먼지를 적게 보이게 하는 보상 기능을 가진 로봇 등).
그럼에도 시스템의 혁신 능력에 제한을 두는 것은 해결책이 아니다. AI 기반 시스템의 매력적인
기능 중 하나는 문제를 해결할 수 있는 현명한 방법, 종종 인간이 고려하지 않았거나 심지어 이해하지
못하는 방식으로 문제를 해결할 수 있어야 한다는 것이다.
2.5 AI 기반 시스템 고유의 윤리적 요구사항 (Specifying Ethical Requirements for AI-
Based Systems)
캠브리지 사전에, ‘윤리’는 ‘동작을 제어하는 허용된 신념 체계, 특히 도덕에 기반한 시스템’이라고
정의되어 있다. AI 기반 시스템이 더 대중화됨에 따라 AI 기반 시스템이 윤리를 어떻게 구현할
것인가가 AI 분야에서 가장 많이 논의되는 주제이며, 이 토론에는 AI의 기술적 측면과 관련된
사람들보다 더 많은 사람들이 참여하고 있다.
AI에서 윤리에 대한 관심의 예로 MIT의 윤리 기계(Moral machine, moralmachine.mit.edu)
를 들 수 있다 [Moral 2018]. 이는 자율주행차가 내릴 수 있는 도덕적 결정에 대한 사람들의 의견을
수집하고 해당 차량 개발자에게 지침을 제공하기 위한 플랫폼이다. 이 플랫폼은 2014년과 2018년
사이에 233개 국가 및 지역의 수백만 명의 사람들로부터 10개 언어로 4천만 가지의 윤리적 결정을
수집했다. (진행 중인) 연구에 따르면 시스템은 어린 사람들에게 우선순위를 부여하고, 동물보다는
사람을 우선하며, 소수보다는 다수의 사람들을 구하는 데 우선순위를 두어야 한다 (예, 보행자 2명
보다 자동차 탑승자 4명을 구함). 이 연구는 또한 세계 각지의 사람들의 선택에 큰 차이가 있음을
알아냈다. 즉, 자율주행차의 사용 지역에 따라 다른 윤리적 지침을 따라야 할 수도 있다.
인공 지능에 관한 유럽위원회 상위 전문가 그룹(The European Commission High-Level
Expert Group)에서는 2019년 4월 윤리 영역에서 신뢰할 만한 AI 홍보를 위한 주요 지침을
발표했으며 [Ethics 2019] 여기에서는 AI 시스템 개발, 배포 및 사용에서 지켜야 할 윤리적 원칙을
다음과 같이 정의한다:
· 인간의 자율성, 피해 방지, 공정성 및 설명가능성에 대한 윤리적 원칙을 준수하는 방식으로 AI 시스템을 개발,
배포 및 사용하며, 이 원리들 사이의 잠재적 긴장을 인지하고 대한다.
· 어린이, 장애를 가진 사람, 역사적으로 불이익이나 배제 당할 위험이 있는 사람과 같은 취약 계층을 포함한
상황에 특별한 주의를 기울인다. 또한 고용주와 근로자 간 또는 기업과 소비자 간과 같이 권력이나 정보의
비대칭적 특징을 갖는 상황에도 각별히 주의한다.
031 AI System Characteristics and Acceptance Criteria
· AI 시스템이 개인과 사회에 상당한 이익을 주지만, 동시에 특정 위험을 초래할 수 있으며, 민주주의, 법치,
분배의 공정성 또는 인간의 마음 자체와 관련해 예측, 식별 또는 측정하기 어려운 영향을 포함한 부정적 영향을
끼칠 수 있다는 것을 인식한다. 위험의 규모에 비례해 이러한 위험을 완화하기 위해 적정한 시기에 적절한
조치를 취한다.

References

25010 2011 ISO/IEC 25010:2011, Systems and software engineering - Systems and software Quality
Requirements and Evaluation (SQuaRE) - System and software quality models, 2011.
Ethics 2019 European Commission High-Level Expert Group on Artificial Intelligence,
Ethics Guidelines for Trustworthy AI, European Commission, April 2019.
Forbes 2016 Kalev Leetaru, How Twitter Corrupted Microsoft's Tay: A Crash Course In the Dangers Of
AI In The Real World, https://www.forbes.com/sites/kalevleetaru/2016/03/24/how-twitter-
corrupted-microsofts-tay-a-crash-course-in-the-dangers-of-ai-in-the-real-
world/#202233ae26d2, Mar 2016.
Moral 2018 Awad et al, The Moral Machine experiment, Nature, 563, pages 59-64, 2018.
Püschel 2018 Georg Püschel, Testing Self-Adaptive Systems - A Model-based Approach to Resilience,
Dissertation, Technischen Universität Dresden, June 2018.
QM4MAS 2016 Marir et al, QM4MAS: a quality model for multi-agent systems, Int. J. Computer Applications in
Technology, 2016, 54.
RELAX 2010 Whittle et al, RELAX: A language to address uncertainty in self-adaptive systems requirement,
Requirements Engineering, June 2010.
Russell 2019 Russell, Of Myths and Moonshine, contribution to the conversation on The Myth of AI,
https://www.edge.org/conversation/jaron_lanier-the-myth-of-ai, accessed Nov 2019.
XAI 2019 Wikipedia contributors, "Explainable artificial intelligence," Wikipedia, https://en.wikipedia.org/w/
index.php?title=Explainable_artificial_intelligence&oldid=924090418 (accessed November 20, 2019).

032 Testing AI Guidelines ver 1.8 033 AI System Characteristics and Acceptance Criteria
Machine Learning 3.1 기계 학습(ML) 소개 (Introduction to Machine learning)

기계 학습 기계 학습(Machine learning, ML)은 AI의 한 형태로 명시적으로 개발된 것이 아닌 주어진 훈련

데이터에서 행동을 학습하는 AI 기반 시스템이다. 기계 학습(ML)의 결과는 모델이라고 부르며, 이는

03
선택된 알고리즘과 훈련 데이터를 통해 AI 개발 프레임워크에 의해 만들어진다. 이 모델은 입력과
출력 간의 학습 관계를 대변한다. 생성된 모델은 처음에 훈련하고 나서 사용상 바뀌지 않는 경우가
많다. 이와는 반대로, 어떤 조건에서는 만들어진 모델이 운영상의 사용(예, 자가 학습)을 지속적으로
학습할 수 있다. 기계 학습(ML)의 사용 예로는 이미지 분류, 게임(예, 바둑), 음성 인식, 보안 시스템(
악성 소프트웨어 감지), 항공기 충돌방지 시스템 및 자율주행차 등이 있다.
[그림 4]에서와 같이 기계 학습(ML)에는 3가지 기본 접근법이 있다.

[그림 4]: 기계 학습의 형태

지도 학습(supervised ML) 알고리즘은 라벨이 있는 데이터 세트를 통한 훈련을 기반으로 한

모델을 생성한다. 지도 학습의 예는 고양이와 개로 분류된 데이터로 모델을 생성한 후 개나 고양이
사진을 보여주고 정확하게 분류하는 모델을 들 수 있다. 지도 학습은 분류 문제와 리그레션 문제
등 두 가지 유형의 문제를 해결한다. 분류는 모델이 ‘예, 이 모듈에서는 오류가 발생할 수 있습니다’,
‘아니오, 이 모듈에서는 오류가 발생할 가능성이 적습니다’와 같이 입력값을 다른 클래스로
구분하는 것이다. [그림 5]는 소프트웨어 모듈에서의 오류 발생 가능성을 식별하는 시스템의 지도
학습 관련 분류표를 보여준다.

034 035 Machine Learning


[그림5]: 지도 학습 예제를 통한 분류
리그레션은 모델이 ‘이 모듈의 예상 결함 수는 12개 입니다’와 같은 수치를 제공한다. [그림 6]은
모듈 내의 결함 수를 예측하는 지도 학습을 사용한 리그레션(regression)의 그래프이다.
[그림 7]: 비지도 학습 예제
[그림 8]에서 보여지듯이, 강화 학습에서는 시스템이 요구되는 행위에 가깝게 동작할수록 시스템
(에이전트)에 정의된 보상 기능이 시스템에 더 높은 점수를 주게 된다. 이런 보상 기능의 피드백을
이용해 시스템은 동작 개선을 학습한다. 강화 학습의 예로 보상 기능을 사용해 최단 경로를 찾는
경로 계획 시스템(route planning system)이 있다.

[그림 6]:지도 학습 예제를 사용한 리그레션

기계 학습(ML)이 확률론적이기 때문에 우리는 이런 분류와 리그레션이 올바른지 측정할 수 있다 [그림 8]: 강화 학습
(ML 성능 메트릭에 대한 내용은 4.1 참조).
비지도 학습은 훈련 데이터에 라벨이 없기 때문에 알고리즘이 데이터 자체에서 패턴을 도출해야
한다. 비지도 학습의 예로는 시스템이 고객 관련 데이터를 사용해 특정 고객 그룹을 찾아 마케팅에
활용하는 경우를 들 수 있다. [그림 7]은 모델이 주어진 데이터에서 클러스터를 식별한 비지도 학습 3.2 기계 학습 작업흐름 (The Machine Learning Workflow)
그래프이다. 이 경우 클러스터는 개별 프로그래머를 나타낸다.
훈련 데이터에 라벨을 붙일 필요가 없기 때문에 지도 학습을 위한 훈련 데이터를 찾기가 쉽고 기계 학습 작업흐름의 활동은 다음 [그림 9]와 같다:
저렴하다.

036 Testing AI Guidelines ver 1.8 037 Machine Learning


[그림 9]: 기계 학습 작업흐름(Workflow)
기계 학습 작업흐름의 활동은 다음과 같다:
3.2.1 목적의 이해 (Understand the Objectives)
배포할 ML 모델의 목적이 비즈니스 우선순위와 일치하도록 이해 관계자들이 서로 이해하고
합의해야 한다. 또한, 개발할 모델을 위한 인수 조건(성능 메트릭 포함, 4.1절 참조)을 정의해야 한다.
3.2.2 프레임워크 선택 (Select a Framework)
목적, 인수 조건 및 비즈니스 우선순위에 기반해 적절한 AI 개발 프레임워크를 선택해야 한다.
이런 프레임워크들은 1.9절에 소개되어 있다.
3.2.3 모델 구축과 컴파일 (Build and Compile the Model)
모델 구조(예, 계층 수)를 정의해야 한다 (보통은 파이썬처럼 코드상에 정의한다). 그 다음,
모델을 컴파일하고 훈련할 준비를 한다.
3.2.4 데이터 소싱 (Source the Data)
모델에 사용하는 데이터는 그 목적을 기반으로 선택한다. 예를 들어, 실시간 거래 시스템의
경우 주식 시장의 데이터를 가져와야 하고, 마케팅 홍보를 위한 고객의 소비 성향을 분석하는
시스템이라면 조직의 고객 정보를 담은 빅데이터를 가져와야 한다.
모델을 훈련, 조정 및 테스트하는 데 사용하는 데이터는 모델이 사용할 것으로 예상되는
운영데이터를 대표해야 한다. 경우에 따라서, 모델 초기 교육을 위해 사전 수집한 데이터 세트를
사용할 수 있다 (예, https://www.kaggle.com/datasets 에서 카글(Kaggle) 데이터 세트 참조).
그러나 원(raw) 데이터는 일반적으로 일종의 전처리(pre-processing)가 필요하다.
038 Testing AI Guidelines ver 1.8
3.2.5 데이터 전처리 (Pre-Process the Data)
모델에 사용할 데이터의 특성(feature)을 선택해야 하는데 이는 기대 결과에 영향을 줄
것으로 예상되는 데이터의 특성 또는 고유성이다. 결과 모델(resultant model)에 영향을 주지
않거나 원하지 않는 특징을 제거하기 위해 훈련 데이터를 관리해야 하는데, 이를 특성 선택(feature
selection) 또는 특성 엔지니어링(feature engineering)이라고 한다. 특성 엔지니어링은 관련
없는 정보(잡음)를 제거함으로써 전체 훈련 시간을 줄이고 과적합(overfitting)을 방지하며(3.4.1절
참조), 정확성(accuracy)을 높이고 모델을 좀 더 일반화시킬 수 있다.
실제 데이터는 이상치(outlier values)를 포함하거나 형식이 각양각색이거나 중요 영역에
대한 적용범위가 누락돼 있을 수 있다. 그러므로 모델을 훈련(및 테스트)하기 위해서는 일반적으로
전처리(pre-processing)가 필요하다. 전처리에는 데이터의 숫자 변환, 숫자 데이터를 공통 크기로
규격화, 이상치나 잡음 데이터의 감지 및 제거, 데이터 중복 감소, 누락 데이터 추가 등이 포함된다.
3.2.6 데이터 훈련 (Train the Model)
ML 알고리즘(예, 1.7절의 기계 학습 기법 참조)은 훈련 데이터를 사용해 모델을 만들고
학습시킨다. 알고리즘은 목표, 인수 조건 및 사용 가능한 데이터를 기반으로 선택해야 한다.
훈련, 평가 및 조정 활동과 ML은 반복성이 높은 작업흐름이지만, 그 이후 활동의 결과(예,
모델 평가)에 따라 데이터 수집 및 전처리 등과 같은 이전 활동으로 다시 돌아가야 할 수도 있다.
3.2.7 모델 평가 (Evaluate the Model)
훈련된 모델은 검증 데이터를 사용해 합의한 성능 메트릭으로 평가하며, 평가 결과는 모델을
개선 및 조정하는 데 사용한다. 보통 평가 결과를 시각화할 필요가 있으며, 다양한 기계 학습(ML)
프레임워크에서 다양한 시각화 옵션을 지원한다.
실제로 여러 개의 모델을 만들고 훈련하는 것이 일반적이며, 평가 및 조정 결과에 따라 가장
적합한 모델을 선택한다.
3.2.8 모델 조정 (Tune the Model)
성능 메트릭에 따라 진행한 모델 평가 결과는 데이터에 맞게 설정을 조정해서 그 성능을
향상시키는 데 사용한다. 훈련 활동을 수정하는 초매개변수 조정(예, 훈련 단계 수 변경 또는 훈련에
사용하는 데이터 양 변경)으로 모델이 수정되기도 하고 모델 속성이 설정되기도 한다(예, 신경망 뉴런
수 또는 결정 트리의 깊이).
3.2.9 모델 테스트 (Test the Model)
모델이 훈련, 평가, 조정 및 선택되면 테스트 데이터 세트가 합의된 성능 기준을 충족하는지
테스트해야 한다. 이 테스트 데이터는 작업흐름에서 이 시점까지 사용한 훈련 및 검증 데이터와
039 Machine Learning
완전히 독립적이어야 한다.

3.2.10 모델 배포 (Deploy the Model)

보통 조정된 모델은 관련 데이터 파이프라인을 포함한 리소스와 함께 배포를 위해 다시
개선과정을 거친다. 이는 일반적으로 ML 프레임워크를 통해 수행된다. 여기에는 임베디드 시스템과
클라우드가 포함되며, 웹 API를 통해 모델에 접근할 수 있다.

3.2.11 모델 사용 (Use the Model)

모델이 일단 배포되면 보통은 더 큰 AI 기반 시스템의 일부로 이 모델을 사용할 수 있다.
모델은 예정된 일괄 예측(Batch predictions)을 설정된 시간마다 수행하거나, 요청 시 실시간으로
실행할 수 있다.

3.2.12 모델 모니터링 및 조정 (Monitor & Tune the Model) [그림10]: 4 분할 훈련 데이터

모델을 사용하는 동안 상황이 진화(evolution, 2.13절 참조)해 목표한 성능에서 ‘표류(drift)’
할 위험이 있다. 표류를 식별하고 관리하려면 인수 기준에 따라 운영 모델을 정기적으로 평가해야
한다. 3.4 기계 학습 과적합 및 과소적합 (Overfitting and Underfitting in Machine Learning)
표류 문제를 해결하기 위해 모델을 업데이트할 수도 있다. 때로는 새로운 데이터로 재훈련하다가
보다 정확하고 강건한 모델제작이 결정될 수 있는데, 이 경우 새로운 모델을 만들고 업데이트한 훈련 3.4.1 과적합 (Overfitting)
데이터로 훈련시킬 수 있다. 성능이 악화되지 않았음을 확신하기 위해 A/B 테스팅 형식을 사용해 모델이 대수롭지 않은 세부사항, 임의 변동, 훈련 데이터의 잡음(예, 훈련 데이터에 너무 많은
기존 모델과 새 모델을 비교할 수도 있다 (6.3절 참조). 기능이 포함됨)과 같이 무관한 정보로부터 부정확한 관계를 학습할 때 과대적합이 발생한다. 실제로
모델이 훈련 데이터를 암기하면, 이 훈련 데이터와 유사한 데이터에서는 문제없이 작동하지만 새로운
데이터를 일반화하거나 다루기는 쉽지 않아진다. [그림 11]은 모델(두 훈련 데이터 세트 사이의 선으로
3.3 기계 학습 훈련과 테스트 데이터 (Machine Learning Training and Test Data) 표시된)이 훈련 데이터와 정확히 일치하지만 일반화하기는 어려운 과적합을 보여준다. 과적합을
식별하는 한 가지 방법은 학습 데이터와는 완전히 분리된 독립 테스트 세트를 사용하는 것이다.
지도 학습 수행 시 과적합을 방지하기 위해 두 가지 개별 데이터 세트(훈련 데이터 세트 및 테스트
세트)를 사용한다 (3.4.1절 참조). 테스트 세트는 홀드아웃(holdout) 세트라고도 부른다.
모델의 반복 평가나 조정을 지원하기 위해 훈련 데이터 세트를 훈련용 데이터와 평가용 검증
데이터로 나눈다. 그러나 이는 훈련용 데이터가 충분하지 않다는 뜻일 수 있다. 이 문제를 해결하는
한 가지 방법으로 교차 검증(cross-validation)이 있다. 교차 검증에서는 훈련 데이터 세트를 분할
(fold)이라고 하는 n개의 동일한 부분으로 나눈다. ([그림 10]에서 4개의 분할 훈련 데이터를 볼 수
있다). 그런 다음 모델을 n번 훈련하고 평가한다. 각각의 경우에 다른 분할을 검증 세트로 사용하고,
나머지 분할은 훈련 세트로 사용한다. 이런 방식으로 훈련을 개선하면서, 평가와 조정도 계속 수행할
수 있다.
[그림 11]: 과적합(Overfitting) 예제

040 Testing AI Guidelines ver 1.8 041 Machine Learning

 3.4.2 과소적합 (Underfitting)
모델이 훈련 데이터에서 입력과 출력의 관계를 식별하지 못할 때 과소적합이 발생한다.
과소적합은 입력과 출력 사이의 정확한 관계 도출을 위해 충분한 정보를 제공하는 훈련 데이터가
충분하지 않을 때(예, 훈련 데이터에 포함된 속성이 충분하지 않은 경우) 발생하지만 선택한
알고리즘이 데이터에 적합하지 않은 경우(예, 비선형 데이터로 선형 모델 생성)에도 발생할 수 있다.
일반적으로 이런 경우에는 잘못된 예측을 양산하는 단순한 모델이 돼버린다. [그림 12]는 왼쪽에
적합하지 않은 선형 모델이 사용된 반면 오른쪽에 더 적합한 비선형 모델이 사용된 언더 피팅의
그래픽 예를 보여준다.
· 소득원천
· 집 주소
그러나 불공정한 모델로 이어질 수 있는 다른 특성(조합으로 사용될 수 있는)이 있을 수 있으므로,
단순히 위 특성을 제거하는 것만으로 반드시 문제가 해결되는 것은 아니다 (예, 일부 지역에서는
아이가 한부모 가정의 일원이라는 것이 인종에 대한 고정관념을 일으킬 수 있다 [AIBias 2019]).
3.6 데이터 품질 (Data Quality)

지도 학습에서는 훈련 데이터가 정확하다고 가정한다. 그러나 실제로는 훈련 데이터 세트가 항상

100% 정확하게 분류되는 경우는 거의 없다 [Frenay 2014]. 라벨을 붙이는 사람은 버튼을 잘못
누르는 등의 실수를 할 수 있고, 모든 라벨에 잘못된 설명이 붙는 시스템적인 실수를 유발할 수도
있으며 또한 의도적으로 실수할 가능성도 있다. 라벨 작업이 두 가지 중 한 가지를 고르는 단순한
분류 작업이 아니라 더 복잡한 분류인 경우 라벨이 정확하지 않을 수도 있다.
한 언어에서의 라벨이 다른 언어로 잘못 번역되는 경우도 있다. 라벨은 다양한 방법으로 수행되는데
각각의 방법마다 데이터의 품질 리스크를 안고 있다.
· 내부 팀에 의한 라벨 작업
· 외부 팀에 의한 라벨 작업
[그림12]: 과소적합(Underfuitting, 왼쪽) vs. 적합(Fitted, 비선형, 오른쪽) 모델의 예 · 크라우드 팀에 의한 라벨 작업
· 합성(Synthetic) 데이터 생성
· AI 기반 라벨 작업
3.5 훈련 데이터의 편향성 및 공정성 (Bias and Fairness in the Training Data) · 하이브리드 접근법
예를 들어, 입력 센서의 품질이 낮거나 조정이 잘못된 경우 데이터 품질이 떨어질 수 있다. 이는
편향성과 공정성은 2.1.5절에서 소개되었다. 훈련 데이터에 편향성이 내재된 경우, 파생 모델에도 센서 데이터를 여러 출처(예, 약간씩 다른 측정 방식을 사용하는 실험실이나 다양한 IoT 장치 등)에서
동일한 편향성이 들어갈 수 있다. 따라서, 결과 모델에 불공정성을 일으키는 데이터 속성이 들어가지 가져온 경우 더 자주 발생한다.
않도록 주의해야 한다. 가령, 다음과 같은 속성은 잠재적으로 원하지 않은 편향성이 나타나게 할 수 누락 데이터는 세 가지 주요 형태로 나타날 수 있으며 각각 결과 모델에 다른 영향을 준다 [Keevers
있다는 것을 인식해야 한다: 2019]. 데이터가 무작위로 누락된 경우 모델의 확률적 속성(데이터 부족에 따른 정확도 감소 제외)을
· 성별 감안할 때 영향은 거의 없다. 특정 기능의 데이터가 누락된 경우(예, 여성의 모든 데이터) 결과 모델에
· 성적 지향 악영향을 줄 가능성이 높다 (모델로 여성을 예측하지 않는 경우 제외). 세 번째 경우는 주어진 특성을
· 나이 가진 데이터 세트값이 누락된 경우로 이는 가장 감지하기 어려운 경우이다 (예, 35세부터 50세까지
· 인종 여성 데이터). 이런 문제는 데이터 수집의 특성 때문에 의학 연구에서 종종 발생한다. 이 경우 모델이
· 종교 심각하게 손상을 입을 수 있다.
· 출생지
· 교육 배경

042 Testing AI Guidelines ver 1.8 043 Machine Learning

3.7 기계 학습 알고리즘/모델 선택 (Machine Learning Algorithm/Model selection)
알고리즘, 모델 설정 및 초매개변수(hyperparameters) 선택이 과학인지 예술인지에 대한 논란이
있다 [Henderson 2018]. 문제 상황 분석에서 최적의 세트를 선택하는 결정적 접근법은 없다. 실제로
이 선택은 보통 부분적인 시행착오로 이뤄진다.
이 선택을 위해 필요한 정보는 모델이 제공할 기능, 학습 알고리즘과 모델에 사용 가능한 데이터 및
충족해야 할 비기능 요구사항이다.
기능면에서 모델은 일반적으로 분류, 값 예측(리그레션), 이상 감지 또는 데이터에 의한 구조 결정(
클러스터링)을 제공한다. 얼마큼의 사용 가능한 데이터가 있는지 알면 특정 알고리즘은 배제할 수도
있다 (예, 더 적은 데이터를 사용할 수 있는 경우 빅데이터에 의존하는 알고리즘은 무시할 수 있음).
데이터에 표식이 있으면 지도 학습(supervised learning)을 쓸 수 있지만 그렇지 않으면 다른 접근
방식이 필요하다. 모델에 사용할 예상 속성의 수는 클러스터링에 필요한 클래스 수와 마찬가지로
특정 알고리즘을 선택하게 할 수 있다. 비기능 요구사항에는 사용 가능 메모리(예, 임베디드 시스템),
예측 속도(예, 실시간 시스템), 일부 상황에서는 업데이트된 훈련 데이터에 의한 모델 훈련 속도가
있을 수 있다. 기타 비기능 관련 영역으로 투명성이 필요할 수 있다 (2.1.7절 참조).
3.8 기계 학습 테스팅과 품질 보증 (Machine Learning Testing and Quality Assurance)
테스팅은 기계학습(ML)에 대한 이전 장에서 언급되었다. 이 장에서는 기계 학습(ML)과 직접 연관된
품질 보증과 테스팅 기회에 대해 간략히 설명한다.
3.8.1 ML 작업흐름 리뷰 (Review of ML Workflow)
기계 학습(ML) 수행 시 사용하는 ML 작업흐름은 문서화하고 따라야 하며, 설명된 작업흐름과
다른 경우 그 이유에 대한 설명이 있어야 한다.
3.8.2 인수 조건 (Acceptance Criteria)
인수 조건(기능 및 비기능 요구사항)은 애플리케이션에 적용하기 위해 정당성을 문서로
기록해야 하며, 성능 메트릭을 모델에 포함해야 한다.
3.8.3 프레임 워크, 알고리즘/모델 및 매개변수 선택 (Framework, Algorithm/Model and
Parameter Selection)
프레임워크, 알고리즘, 모델, 설명 및 초매개변수(hyperparameters) 선택에 대한 문서로
기록해야 한다.
044 Testing AI Guidelines ver 1.8
3.8.4 모델 업데이트 (Model Updates)
배포한 모델을 업데이트할 때마다 모델이 악화(예, 새 모델이 이전 모델보다 느림)되었는지
테스트하는 것처럼, 문서화하지 않은 암시적 요구사항을 포함해 지속적으로 인수 기준을
충족하는지도 재테스트해야 한다. 이전 모델에 대해 적절하게 A/B 테스팅 또는 백투백 테스팅을
수행해야 한다.
3.8.5 훈련 데이터 품질 (Training Data Quality)
기계 학습(ML) 시스템은 운영 데이터를 대표하는 훈련 데이터에 크게 의존하며 일부 기계
학습(ML) 시스템은 광범위한 운영 환경(예, 자율주행 차량에 사용하는 환경)에서 동작한다. 경계
조건(가장자리 값)은 모든 유형의 시스템(AI & 비AI)에 장애를 일으키는 것으로 알려져 있으므로
훈련 데이터에 포함시켜야 한다. 데이터 세트의 크기와 훈련 편향, 투명성, 완전성 같은 특징의
측면에서 훈련 데이터 선택을 문서화해서 정당화시켜야 하며 보다 중요한 시스템의 경우 전문가의
확인이 필요하다.
3.8.6 테스트 데이터 품질 (Test Data Quality)
훈련 데이터에 대한 기준은 테스트 데이터에도 동일하게 적용되며 테스트 데이터는 최대한
훈련 데이터와 독립적이어야 함을 주의해야 한다. 독립 수준은 정당성을 문서로 기록해야 한다.
테스트 데이터는 체계적으로 선택해서 만들어야 하고, 부정 테스트(negative tests 예, 기대 입력
범위를 벗어나는 입력값)를 포함해야 한다 (3.8.8절 참조).
3.8.7 모델 통합 테스팅 (Model Integration Testing)
기계 학습(ML) 모델이 AI 기반 시스템의 나머지 부분과 올바르게 통합되었는지 확인하기
위해 통합 테스팅을 수행한다. 예를 들어, 객체 인식 모델이 이미지 파일을 바르게 인식하는지 그리고
모델이 예측한 형식인지 확인하는 테스트를 수행해야 한다. 모델의 결과값을 올바르게 해석해서
시스템의 나머지 부분에 사용하는지 확인하는 테스트도 수행해야 한다.
3.8.8 적대적 사례 및 테스팅 (Adversarial Examples and Testing) [Qiu 2019]
적대적 사례는 신경망에 대한 입력의 아주 작은 변화가 출력에 예기치 않은(또한 잘못된)
큰 변화(즉, 변경 전의 입력과는 완전히 다른 결과)를 생성하는 경우이다. 적대적 사례는 이미지
분류기에서 처음 발견되었다. 단순히 몇 픽셀(육안으로 식별 불가)을 변경함으로써 신경망이 이를
다른 물체로 인식할 수 있다. 그러나 적대적 사례는 이미지 분류기에 제한되지 않으며 신경망의
일반적 속성이므로 모든 신경망에서 나타날 수 있으니 유의해야 한다.
적대적 사례는 이동이 가능하다. 이 말은 하나의 신경망에서 실패를 일으킨 적대적 사례가
종종 동일 작업을 수행하도록 훈련된 다른 신경망에도 실패를 일으킨 다는 것을 의미한다. 이런
045 Machine Learning
다른 신경망은 다른 데이터와 다른 아키텍처를 기반으로 훈련됐을 수 있지만 동일한 적대적 사례로
실패하기 쉽다.
적대적 테스팅은 종종 적대적 공격 수행이라고도 한다. 테스팅 중에 이런 공격을 수행하고
취약성을 식별함으로써 향후 장애로부터 보호할 수 있어 신경망의 강건성(robustness) 개선 효과를
얻을 수 있다.
공격은 모델을 훈련할 때 그리고 훈련된 모델(신경망) 자체에서 일어날 수 있다. 훈련 중
공격에는 훈련 데이터 손상(예, 표식 수정), 훈련 세트에 잘못된 데이터 추가, 학습 알고리즘 손상이
있다. 훈련된 모델에 대한 공격은 화이트 박스 또는 블랙 박스일 수 있으며, 모델이 부정적 결과를 낼
수 있는 적대적 사례의 식별을 포함한다.
화이트 박스 공격은 공격자가 모델 훈련에 사용한 알고리즘, 설정값, 사용한 매개변수에 대해
다 알고 있는 경우이다. 예를 들면 공격자는 이 지식을 사용해 입력에 약간의 변화(perturbation)를
가하고 모델에 큰 변화를 일으키는 것을 모니터링해 적대적 사례를 만들어낸다.
블랙 박스 공격은 공격자가 모델의 내부 동작이나 훈련 방식에 대한 지식에 접근할 수 없는
경우에 일어난다. 이런 상황에서 공격자는 처음에 모델을 사용해서 기능을 파악하고 같은 기능을
제공하는 ‘복제’ 모델을 제작한다. 이 후 이 복제 모델에서 적대적 사례를 식별하기 위해 화이트 박스
접근법을 사용한다. 일반적으로 적대적 사례는 이동 가능하므로, 보통은 동일한 적대적 사례가 블랙
박스 모델에서도 동작할 것이다.

References

AIBias 2019 Salkever et al, A.I. Bias Isn’t the Problem. Our Society Is, Fortune.com,
https://fortune.com/2019/04/14/ai-artificial-intelligence-bias/, accessed Nov 2019.
Frenay 2014 Frenay et al, Classification in the Presence of Label Noise: A Survey,
IEEE Transactions on Neural Networks and Learning Systems, May 2014.
Henderson 2018 Henderson et al, Deep reinforcement learning that matters,
Thirty-Second AAAI Conference on Artificial Intelligence, 2018.
Keevers 2019 Keevers, Cross-validation is insufficient for model validation, Technical Report,
Australian Defence Science and Technology Group, Mar 2019.
Qiu 2019 Qiu et al, Review of Artificial Intelligence Adversarial Attack and Defense Technologies,
Applied Sciences 9(5):909, Mar 2019.

046 Testing AI Guidelines ver 1.8 047 Machine Learning

Machine Learning Performance 4.1 기계 학습 성능 메트릭 (Machine Learning Performance Metrics)

Metrics and Benchmarks 다양한 기계 학습(ML) 알고리즘을 평가하기 위해 여러 성능 메트릭을 사용한다. 이 문서에서는
분류 문제에 대한 성능 메트릭만을 다룬다. 이런 메트릭은 ML 작업 흐름 초기 단계에서 합의하고

04
일반적으로 ML 작업 흐름의 두 단계에서 평가한다. 평가를 위해 개발자들은 이 메트릭을 사용해
기계 학습 성능 메트릭
및 벤치마크
평가 데이터 세트로 수용 가능한 수준의 성능에 도달할 때까지 자신들의 모델을 조정(예, 매개변수
선택)한다. 그 후에 메트릭은 (독립) 테스트 세트를 통한 최종 모델 성능의 수용 가능 여부 측정을
위해 사용된다.

4.1.1 혼동 행렬 (Confusion Matrix) [Confusion 2019]

기계 학습(ML) 모델이 입력값을 참 또는 거짓으로 분류한다고 가정해 보자. 이상적으로는,
모든 데이터가 정확하게 분류되겠지만 실제로는 데이터 세트가 겹치는 경우가 있다. 즉, 일부 데이터가
참으로 분류되어야 하는데 거짓으로 분류되기도 하고(거짓 음성), 거짓으로 분류되어야 하는데
참으로 분류되기도 한다(거짓 양성). 나머지 데이터는 참 음성 또는 참 양성으로 올바르게 분류된다.
이 네 가지 가능성 세트가 [그림 13]에 나와 있다.

[그림13]: 데이터 배포 중복(Overlapping Data Distributions)

이 네 개의 데이터 세트는 [그림 14]와 같이 혼동 행렬(confusion matrix)로 표시할 수 있다.

[그림 14]: 혼동 행렬(Confusion Matrix) 포맷

048 049 Machine Learning Performance Metrics and Benchmarks

 4.1.2 정확도 (Accuracy)
정확도는 정확하게 분류된 비율을 나타내며 다음과 같이 계산한다:
참 양성 + 참 음성 참 양성 + 참 음성
정확도 =
참 양성 + 참 음성 + 거짓 양성 + 거짓 음성
4.1.3 정밀도 (Precision)
정밀도는 정확하게 예측된 양성의 비율(양성으로 예측을 확신하는 정도)이며 다음과 같이
계산한다:
두 분포 사이의 경계가 왼쪽으로 움직여야 한다.
재현율은 참 양성을 포착하는 것이 중요할 때 가장 유용하다 (즉, 모든 또는 대부분의 음성을
확인해야 할 때). 전방 도로에 있는 사람들을 감지하는 자율주행차를 예로 들 수 있다. 보행자가 있는
경우 이 보행자를 식별했는지 확신이 필요하므로 거짓 음성이 없어야(또는 아주 적어야) 한다. 이
=
모든 분류 경우 재현율은 아주 높아야 한다. [그림 15]에서 재현율이 높으면 두 분포 사이의 경계가 오른쪽으로
움직이는 것을 볼 수 있다.

참 양성
정밀도 =
참 양성 + 거짓 양성

4.1.4 재현율 (Recall)

재현율(또는 민감도)은 올바르게 예측된 실제 양성의 비율(양성 누락이 없는지 확신하는
정도)이며 다음과 같이 계산한다:
[그림 15]: 이진 분류(Binary Classification) - 경계위치 선택

참 양성
재현율 = F1은 데이터 분포가 고르지 않을 때 가장 유용하다.
참 양성 + 거짓 음성
이런 성능 메트릭은 ML 모델의 평균 성능을 제공하지만 예상되는 최악의 시나리오에서 모델의
성능을 보장하는 것 또한 중요하다.
4.1.5 F1-점수 (F1-Score)
F1-점수는 재현율과 정밀도 사이의 균형(조화 평균)을 제공하며 다음과 같이 계산한다:

4.2 기계 학습 벤치마크 (Benchmarks for Machine Learning)

정밀도 * 재현율
F1 - 점수 = 2 *
정밀도 + 재현율
이상적으로는 각각의 새로운 기계 학습(ML) 모델 평가를 위해 전문가를 동원하겠지만 일반적으로

4.1.6 성능 메트릭의 선택 (Selection of Performance Metrics) 전문가 활용에는 비용이 많이 든다. 그 대신 “대표할 수 있는” 업계 표준 벤치마크 스위트를 사용할

상황에 따라 적합한 성능 메트릭이 모두 다르다. 여기에서는 가장 기본적이고 일반적인 것만을 수 있으며 이 벤치마크 스위트는 여러 상황(예, 이미지분류, 객체 감지, 번역 및 추천)에서의 다양한

다룬다. 텍스트 출력의 정확성(예, 기계 번역)을 측정해야 하는 경우 BLEU, ROUGE 및 METEOR 업무를 다루고 있다.

등의 메트릭이 가능하다 [Raj 2019]. 이런 벤치마크 스위트는 하드웨어(정의된 모델 사용) 및 소프트웨어(예, 가장 빠른 모델 결정) 성능

정확도는 데이터 집합이 대칭을 이루는 경우 즉, 거짓 음성과 거짓 양성의 수가 비슷한 경우 측정에 사용된다. 소프트웨어 벤치마크 스위트는 훈련(예, 정의된 훈련 데이터 세트를 사용해 정확도

적합하다. 75% 같은 지정된 목표 품질 지표로 프레임워크가 ML 모델을 얼마나 빨리 훈련시키는지)과 예측(예,

정밀도는 참 양성에 대해 확신하고 싶을 때 가장 유용하다 (즉, 거짓 양성이 적거나 원하지 훈련된 ML 모델이 얼마나 빨리 예측을 수행하는지)을 측정할 수 있다.

않는 경우). 테러 목표물을 공격하는 군사용 드론을 예로 들어보자. 이 경우 거짓 양성이 있어서는 기계 학습(ML) 벤치마크 세트의 예로, 소프트웨어 프레임워크, 하드웨어 가속기와 기계 학습(ML)

안되며(또는 매우 적어야 하며) 정밀도가 높아야 한다. [그림 15]에서 정밀도(precision)를 높이려면 클라우드 플랫폼을 제공하는 MLPerf [MLPerf 2019], 스탠포드 대학에서 제공하는 벤치마크

050 Testing AI Guidelines ver 1.8 051 Machine Learning Performance Metrics and Benchmarks
스위트인 DAWNBench [DAWN 2019]가 있다.
OAEI(Ontology Alignment Evaluation Initiative)는 다음과 같은 목표를 가지고 조직화된
국제 이니셔티브이다 [OAEI 2019]:
기술 성능에 대한 제어된 실험을 통해,
· 정렬/매칭(alignment/matching) 시스템의 장단점 평가;
· 기술 성능 비교;
· 알고리즘 개발자들 사이의 커뮤니케이션 증가;
· 평가 기술 개선;
· 온톨로지 정렬/매칭 작업 개선 지원
등을 수행할 수 있다.

References

Confusion 2019 Wikipedia contributors, "Confusion matrix," Wikipedia, https://en.wikipedia.org/w/index.

php?title=Confusion_matrix&oldid=922488584 (accessed November 21, 2019).
DAWN 2019 Stanford DAWN Deep Learning Benchmark,
Website: https://dawn.cs.stanford.edu/benchmark/, accessed Nov 2019.
MLPerf 2019 ML Training Benchmarks, Website: https://mlperf.org/, accessed Nov 2019.
OAEI 2019 Ontology Alignment Evaluation Initiative,
Website: http://oaei.ontologymatching.org/, accessed Nov 2019.
Raj 2019 Raj, Metrics for NLG evaluation, Medium.com,
https://medium.com/explorations-in-language-and-learning/metrics-for-nlg-evaluation-
c89b6a781054 , accessed Nov 2019.

052 Testing AI Guidelines ver 1.8 053 Machine Learning Performance Metrics and Benchmarks
Introduction to the Testing 5.1 AI 기반 시스템 테스팅의 과제 (Challenges in Testing AI-Based Systems)

of AI-Based System AI 기반 시스템은 일반적으로 기존 컴포넌트(예, 사용자 인터페이스)와 AI 컴포넌트로 구성된다.

심지어 ‘순수(pure)’ AI 컴포넌트도 소프트웨어로 구현되므로 다른 소프트웨어와 동일하게 결함이

05
발생할 수 있다. 따라서, AI 기반 시스템을 테스팅할 때, 기존의 소프트웨어 테스팅 접근법이 여전히
AI 시스템
테스팅 소개
필요하다. 그러나 AI 기반 시스템은 기존 소프트웨어 시스템과는 다른 특수한 속성이 있으므로
추가적인 테스트가 필요하다.

5.1.1 시스템 명세 (System Specifications)

AI (특히 ML)에 대한 최근의 학문적 연구에도 불구하고 특수성(2.1절 참조)을 갖는 AI 기반
시스템의 기대 동작을 명시하는 최적 방안에 대해서는 거의 다뤄지지 않았다.
이상적인 상황에서는 완전한 공식 명세에 따른 자동화된 테스트 오라클을 만들 수 있을
것이다. 그러나 실제로는 AI 기반 시스템의 명세가 완전하지 않고 비공식적일 수 있기 때문에
테스터가 명시되지 않은 기대 결과가 무엇인지 판단해야 한다. 이는 테스터가 시스템 요구 동작을
완전히 인지하지 못하고 있으면 문제가 되는데, 도메인 전문가로부터 이런 정보를 얻기란 쉬운 일이
아니다.
또 다른 문제는 AI 기반 시스템 요구사항이 필요한 기능보다는 목표 측면에서 명시되는 경우가
많으며 이것이 더 일반적인 접근법이라는 것이다 [Banks 2019]. 이는 보통 많은 AI 기반 시스템의
특성때문에 제공된 기능이 불분명하기 때문이다 (예, 심층 신경망 기능이 어떻게 동작하는지
짐작하는 것은 매우 어렵다).
몇몇 AI 기반 시스템은 대규모 운영 환경에서 사용되며(예, 자율주행드론) 운영 환경을
완벽하게 정의하는 것은 일반적인 기존 시스템에서보다 더 어려울 수 있다. 운영 환경이 복잡하다는
것은 이런 시스템의 테스트 환경도 똑같이 어려울 수 있다는 것을 의미한다 (테스트 환경 관련 상세
내용은 8장 참조).
기계 학습(ML) 모델 명세는 기계 학습(ML) 모델 인수 기준으로 사용하기 위해 요구되는
일련의 성능 메트릭(4.1절 참조)을 포함해야 한다.

5.1.2 테스트 입력 데이터 (Test Input Data)

AI 기반 시스템은 종종 빅데이터 또는 다양한 출처에서 수집한 데이터 입력에 의존한다. 이는
종종 구조화되지 않은 입력 데이터가 다양한 형식으로 제공됨을 의미한다. AI 기반 시스템을 개발할
때, 이 데이터 관리는 데이터 과학자의 업무지만, 테스팅 관련해서 이 전문 데이터 관리업무는 보통
전문 교육을 거의 받지 않은 테스터가 수행해야 하는 많은 업무 중 하나인 경우가 대부분이다.
AI 기반 시스템이 종종 그렇듯이 개인 정보를 포함한 데이터 세트에 대한 요구사항의 경우,
테스터는 GDPR같은 데이터개인정보보호규정을 지키기 위해 처리된(sanitized) 테스트 데이터를

054 055 Introduction to the Testing of AI-Based System

수집할 필요가 있다. 테스트 중인 AI 기반 시스템이 부분적으로 가려진 상세 개인 정보를 유추하지 테스트 방안과 함께 2.1절에 설명되어 있다.
못하도록 처리수준에 주의를 기울여야 한다.

5.1.3 확률적 및 비결정적 시스템 (Probabilistic & Non-Deterministic Systems)
많은 AI 기반 시스템의 확률적 특성 때문에 기대 결과로 사용할 수 있는 정확한 값이 항상
존재하는 것은 아니다. 가령, 자율주행차는 정차된 버스 주변 경로를 표시할 때, 최적의 방안을
계산하기보다 좀 더 효과적인(또한 안전한) 방안을 선택한다. 그래서 괜찮은 준최적화 방안(sub-
optimal)을 받아들인다. 또한 AI 기반 시스템의 경로 설정법 특성상 매번 동일한 결과를 얻지 못
할 수도 있다. (예, 임의 초기값(random seed)에 기반하여 계산이 이뤄질 수 있고, 이 경우는 매번
다르면서 실행 가능한 경로를 나타냄). 이는 시스템을 비결정적으로 만들어 재현성이 떨어지므로
리그레션 테스트 시 비결정성으로 인한 변동을 고려해 더 나은 예상 결과를 가지고 있어야 함을
뜻한다.
두 경우 모두 실제 결과의 불확실성을 감안해서 테스터는 허용 오차를 포함해 기존 시스템보다
더 정교한 기대 결과를 도출해야 한다. 확률적 AI 기반 시스템에서는 시스템이 올바르게 작동하고
있다는 통계적 유의성을 보장하기 위해 테스터가 동일한 테스트를 여러 번 실행할 수 있다.
5.2 AI 기반 시스템의 테스트 오라클 문제 (The Test Oracle Problem for AI-Based
Systems)
AI 기반 시스템을 테스트할 때 반복되는 문제는 테스트 오라클 문제이다. 품질이 낮은 명세, 복잡성,
확률성, 자가학습 및 비결정적 시스템은 예상 결과 생성을 매우 어렵게 만든다.
테스트 오라클 문제를 해결하는 테스팅 접근법과 기법은 6장 블랙 박스 테스팅에서 설명한다.
References
Banks 2019 Banks et al, Requirements Assurance in Machine Learning,
Proceedings of the AAAI Workshop on Artificial Intelligence Safety 2019, Jan 2019.
Bojarski 2016 Bojarski et al, End to End Learning for Self-Driving Cars, arXiv.org, arXiv:1604.07316,
accessed Nov 2019, Apr 2016.

5.1.4 자가학습 시스템 (Self-Learning Systems)

AI 기술이 발전함에 따라 시간이 흐르면서 자신의 동작을 바꿀 수 있는 AI 기반 시스템이 더
많아지게 된다. 이들은 자가 적응 시스템(자체 재구성 및 최적화 가능) 또는 과거 경험을 학습해 스스로
적응하는 완전 자가학습 시스템일 수 있다. 두 상황 모두에서, 원래 시스템에서 성공적으로 실행된
테스트가 개선된 새 시스템에서 더 이상 실행되지 않을 수 있다. 더 이상 유효하지 않은 테스트를
식별하는 것은 상대적으로 쉽지만, 새 기능을 테스트하기 위한 새로운 테스트가 생성되었는지
확인하는 것은 훨씬 어려운 일이다.

5.1.5 복잡성 (Complexity)

많은 AI 기반 시스템은 매우 복잡하며 사람이 이해하는 것도 쉽지 않다. 가령, 3일만에
구축한 ‘간단한’ 자동차 주행 신경망에도 약 2,700만개의 연결과 25만개의 매개변수가 있는 것으로
나타났다 [Bojarski 2016]. 복잡한 ML 시스템의 또 다른 예는 빅데이터의 패턴을 식별하는 데
사용하는 시스템이다. 이 시스템은 많은 시간과 노력을 쏟아 부어도 인간이 찾아낼 수 없는 패턴을
찾아내기 때문에 사용된다. 이렇게 AI 기반 시스템이 너무 복잡한 경우, 기대결과를 생성할 수 있을
정도로 시스템을 깊이 있게 이해하는 것은 많은 테스터의 능력을 넘어서는 것일 수 있다.

5.1.6 AI 특수성 (AI-Specific Characteristics) (see section 2.1)

AI 기반 시스템에는 다양한 특성들이 있는데 그 중 일부는 이 장에서 이미 다뤘으며 나머지는

056 Testing AI Guidelines ver 1.8 057 Introduction to the Testing of AI-Based System
Black Box Testing of 6.1 조합 테스팅 (Combinatorial Testing)

AI-Based Systems 동적 테스팅으로 특정 테스트 항목이 주어진 모든 환경에서 모든 요구사항을 충족한다는 것을

증명하려면 모든 가능한 상태에서 가능한 모든 입력값을 테스트해야 한다. 이런 비현실적 활동을

06
‘완벽한 테스팅(Exhaustive testing)’이라고 한다. 이런 이유로 실제 소프트웨어 테스팅에서는
AI 기반 시스템의
블랙박스 테스팅
가능한 많은 입력값과 상태 세트에서 샘플을 골라 테스트 스위트를 도출한다. 조합 테스팅은 이
입력 영역에서 유용한 조합의 하위 세트를 도출하기 위한 체계적이고 효과적인 접근법 중 하나이다
[Kuhn 2004].
관심 조합은 매개변수(parameters 예, 입력과 환경 조건)와 이런 매개변수가 가질 수 있는 값으로
구성된다. (각각 여러 다른 수치를 가진) 수많은 매개변수 조합이 가능한 경우, 이 기법은 이론적으로
테스트 스위트의 결함 검출 능력을 손상시키지 않으면서 필요한 테스트 케이스 수를 크게 줄일 수
있다.
ISO/IEC/IEEE 29119-4 [29119-4 2015]에는 모든 조합 테스팅(All Combinations), 개별 선택
테스팅(Each Choice Testing), 기본 선택 테스팅(Base Choice Testing) 및 페어와이즈 테스팅
(Pairwise Testing) 같은 몇 가지 조합 테스팅 기법이 정의되어 있다. 실제로 페어와이즈 테스팅은
이해하기 쉬우면서 지원하는 도구가 많고, 소수 매개변수의 상호작용으로 인한 대부분의 결함을
검출한다는 연구결과 때문에 가장 널리 사용된다 [Kuhn 2004].
AI 기반 시스템에서 관심 있는 매개변수의 수는 특히 시스템이 빅데이터를 사용하거나 자율주행차와
같이 외부 세계와 상호작용하는 경우 더욱 많을 수 있다. 따라서 페어와이즈 테스팅처럼 조합 테스팅
기법을 통해 관리 가능한 작은 세트로 거의 무한에 가까운 조합 가능한 수를 체계적으로 줄이는
방법이 아주 유용하다. 실제로 페어와이즈 테스팅을 사용하더라도 이런 시스템에 대한 대규모 테스트
스위트를 생성할 수 있으며 자동화나 가상 테스트 환경(8.1절 참조)이 필요할 수도 있다.
자율주행차를 예로 들면, 시스템 테스트 시나리오에서는 차량의 다양한 기능과 예상되는 작동
환경을 모두 고려해야 한다. 따라서 매개변수는 환경 제약(예, 도로 유형 및 표면 상태, 지리적 위치,
시간대, 기상 상태, 교통 상황, 가시성 등)과 함께 자율주행 기능(예, 순항 제어, 적응형 순항 제어,
차선 유지 지원, 차선 변경 지원, 신호등 지원 등)을 포함해야 한다. 이런 매개변수 외에도, 센서의
입력도 다양한 효율성 수준에서 고려해야 한다 (예, 비디오 카메라 입력은 운행이 진행됨에 따라
저하되고 더럽혀 지거나 시선으로 들어오고 나가는 여러 위성 수로 인해 GPS 장치의 정확도가 바뀔
수 있다). 자율주행차와 같이 안전이 중요한 AI 기반 시스템의 조합 테스팅에 필수적인 엄격함 수준(
예, 페어와이즈가 충분하지 않을 수 있음)에 대한 연구는 아직 진행 중이다. 그러나, 이 방법은 결함을
찾는 데 효과적이며 잔존 리스크 수준 추정에도 사용 가능한 것으로 알려져 있다.

058 059 Black Box Testing of AI-Based Systems

6.2 백투백 테스팅 (Back-to-Back Testing)
백투백 테스팅은, 동일한 테스트 입력에 대해 비교 가능한 결과를 생성하기 위해 이미 존재하거나,
다른 팀에서 개발했거나, 다른 프로그래밍 언어로 구현한 다른 버전의 시스템을 수도-오라클
(pseudo-oracle)로 사용한다. [그림 16]은 이 접근법의 그래픽 표현을 보여준다.
이를 비교 테스팅(Differential testing)이라고도 한다.
이와 같이 백투백 테스팅은 테스트 입력을 생성하지 않으므로 테스트 케이스 생성기법은 아니다.
단지 수도-오라클(기능적으로 동등한 시스템)로 기대 결과만 자동으로 생성한다. 임의 또는 다른
테스트 입력 생성 도구와 함께 사용하면 대량의 자동화 테스팅을 수행하는 아주 효과적인 방법이
된다.
[그림 16]: 백투백 테스팅( Back-to-Back Testing)
테스팅을 지원하는 경우 수도-오라클은 테스트하고 있는 시스템과 동일한 비기능 제약 조건을
충족하지 않아도 된다. 예를 들어, 수도-오라클은 테스트 중인 시스템이 요구하는 것보다 훨씬 느리게
동작할 수 있다. 또한 백투백 테스팅이 테스트 중인 시스템의 일부만 수도-오라클로 수행될 수 있기
때문에 수도-오라클이 항상 기능적으로 완벽하게 동일한 시스템일 필요는 없다.
ML의 경우 수도-오라클을 생성하기 위해(어떤 상황에서는 기존의 비 AI 소프트웨어를 사용해 수도-
오라클을 생성할 수도 있다.) 다양한 프레임워크, 알고리즘 및 설정을 사용할 수 있다. 수도-오라클
사용에 대해 알려진 문제점은 이것이 제대로 동작하기 위해서는 테스트 중인 소프트웨어와 완전히
독립적이어야 한다는 것이다. AI 기반 시스템 개발에는 재사용할 수 있는 오픈 소스 소프트웨어가
많이 사용되므로 이런 독립성이 쉽게 손상될 수 있다.
060 Testing AI Guidelines ver 1.8
6.3 A/B 테스팅 (A/B Testing)
A/B 테스팅은 테스터가 두 시스템 중 더 나은 성능을 결정하도록 해주는 통계적 테스팅 방식 으로
분할 실행 테스팅(Split-run Testing)이라고도 한다 [A/B 2019]. 이는 고객을 대해야 하는 디지털
마케팅(예, 가장 좋은 반응을 얻는 이메일 찾아내기 등)에 자주 사용된다. [그림 17]은 휴대폰의
사용자 인터페이스가 그 일부를 검정색에서 회색으로 변경할 때 개선되는지의 확인을 위한 A/B
테스트를 보여준다.
[그림 17]: A/B 테스팅
A/B 테스팅은 종종 사용자 인터페이스 설계를 최적화하는 데 사용한다. 예를 들어, 사용자
인터페이스 설계자가 현재 빨간색인 ‘구매’ 버튼 색상을 파란색으로 변경하면 판매가 증가할
것이라고 가정해보자. 파란색 버튼으로 된 새로운 인터페이스를 생성하고 두 인터페이스를 각각
다른 사용자에게 할당한다. 두 가지의 다른 버전에 대한 판매율을 비교해 통계적으로 유의미한 사용
횟수를 실행하면 가설이 올바른지 판단할 수 있다. 만약 파란 버튼에서 판매율이 높았다면 파란
버튼으로 된 새 인터페이스가 빨간 버튼인 현재 인터페이스를 대체하게 된다. 이런 형태의 A/B
테스팅은 통계적으로 매우 많은 사용횟수가 필요하며 도구(종종 AI 사용)의 지원을 받더라도 많은
시간이 걸릴 수 있다.
A/B 테스팅은 테스트 입력을 생성하는 것이 아니므로 테스트 케이스 생성 기법은 아니다. A/B
테스팅은 기존 시스템을 부분적인 오라클로 사용해 테스트 오라클 문제를 해결하는 수단 중에
하나이다. 새로운 시스템을 현재 시스템과 비교함으로써 새로운 시스템이 어떤 면에서 더 나은지
판단할 수 있다. 디지털 마케팅에 사용할 때는 더 많은 판매량으로 성공 여부를 측정할 수 있지만 기계
학습 분류기(ML Classifier) 같은 AI 기반 시스템에서는 정확도(accuracy), 민감도(sensitivity),
061 Black Box Testing of AI-Based Systems
재현율(recall) 같은 성능 메트릭을 사용할 수 있다 (4.1절 참조).
인수 조건(예, ‘명시된 성능 지표가 개선되거나 동일하게 유지되어야 한다’)이 정의되고 합의된다면
AI 기반 시스템 컴포넌트가 수정될 때마다 A/B 테스팅을 사용할 수 있다. A/B 테스팅을 자동화하면
시스템의 새로운 성능을 이전 성능과 비교하고, 자가학습으로 시스템 성능을 개선할 수 없다면 이전
버전으로 되돌리는 방식으로 자가학습 AI 기반 시스템에 사용할 수 있다. 여기서는 유효한 인수 조건
(acceptance criteria)을 수립할 수 있도록 주의해야 한다.
6.4 변성 테스팅 (Metamorphic Testing) [Chen 2018] [Segura 2016]
변성 테스팅은 AI 기반 시스템에서 발견하기 쉬운 복잡성(complexity), 비결정성(non-determinism),
확률적 시스템(probabilistic systems) 등의 이유로 기대 결과 생성이 쉽지 않은 테스트 오라클
문제를 다루는 테스트 케이스 생성법이다. 변성 테스팅으로 테스트 케이스를 생성하는 것과 기존의
테스트 케이스 설계 기법의 주요 차이는 변성 테스팅의 기대 결과가 고정값(fixed value)이 아니라
다른 기대 결과와의 관계에 의해 정의된다는 것이다.
변성 테스팅은 정확하다고 판명된 소스(source) 테스트 케이스에서 후속(follow-up) 테스트
케이스를 생성하기 위해 변성 관계(metamorphic relations)를 사용한다. 테스트 중인 소프트웨어의
변성 관계는 소스 테스트 케이스에서 후속 테스트 케이스로 바뀐 입력값이 소스 테스트 케이스에서
후속 테스트 케이스로 바뀐 기대 결과의 변경(또는 변경되지 않은)에 어떤 영향을 주는지 설명하는
것이다.
[그림 18]은 변성 관계를 보여주며, 해당 기능의 입력과 출력에 관련한 필수 기능의 특성을 나타낸다.
특정 방식으로 입력을 변경하면(왼쪽의 하향 화살표) 출력에 어떤 영향을 미치는지(오른쪽의 하향
화살표)를 알게 된다.
[그림 18]: 변성 관계(Metamorphic Relation)
062 Testing AI Guidelines ver 1.8
※ [사례 1] 시작과 종료 지점 사이의 거리를 측정하는 테스트 항목. 소스 테스트 케이스는 테스트 케이스를
수행해 입력 A(시작 지점)와 B(종료 지점) 및 기대 결과 C(거리)를 갖는다. 변성 관계는 시작과 종료 지점이 서로
바뀌더라도 기대 결과는 변함이 없다고 명시한다. 그러므로 시작 지점으로 B, 종료 지점으로 A, 기대 결과로 C
를 갖는 후속 테스트 케이스를 생성할 수 있다.
※ [사례 2] 생활방식 매개변수 세트를 기반으로 개인의 기대 수명을 예측하는 테스트 항목.
하루 흡연 10개피 등의 값을 포함한 다양한 테스트 입력값을 통해 소스 테스트 케이스를 수행하고 그 결과 기대
수명이 58년이라는 결과값을 갖는다. 변성 관계는 어떤 사람이 담배를 더 많이 피우게 되면 아마도 기대 수명이
줄어들 것(또는 증가하지 않을 것)이라고 명시한다. 그러므로 하루 흡연량을 20개피로 늘린 것을 제외하고는
동일한 생활 방식 매개변수를 갖는 후속 테스트 케이스를 생성할 수 있다. 이 후속 테스트 케이스의 기대 결과(
기대 수명)는 58년 보다 적거나 같은 값으로 설정할 수 있다.
후속 테스트 케이스의 기대 결과가 항상 정확한 값은 아니지만 종종 소스 테스트 케이스를 실행해서
달성한 실제 결과의 함수로 설명된다 (예, 후속 테스트 케이스의 기대 결과가 소스 테스트 케이스의
실제 결과보다 크다).
단일 변성 관계를 사용해 여러 후속 테스트 케이스를 도출할 수 있다 (예, 음성을 텍스트로 변환하는
기능에 대한 변성 관계를 사용해 소리의 크기만 다른 같은 음성 파일을 입력함으로써 같은 텍스트를
기대 결과로 갖는 다수의 후속 테스트 케이스를 생성할 수 있다). 변성 관계가 공식적(또는 준공식적)
으로 기술되고 소스 테스트 케이스가 제공되는 경우 도메인 지식이 필요하므로 변성 관계 자동
생성은 어렵겠지만 후속 테스트 케이스 생성을 자동화할 수 있다.
변성 테스팅 수행 프로세스는 다음과 같다:
1. 변성 관계(MRs) 구축
- 테스트 중인 프로그램의 속성을 식별하고 그것을 소스 테스트 케이스에 기반해 후속 테스트 케이스를
생성하는 방법과 함께 테스트 입력과 기대 결과 사이의 변성 관계로 표현한다.
2. 변성 관계 리뷰
- 고객이나 사용자와 함께 변성 관계를 리뷰하고 확인한다.
3. 소스 테스트 케이스 생성
- 소스 테스트 케이스 세트를 생성한다 (테스트 기법이나 임의 테스팅 사용).
4. 후속 테스트 케이스 생성
- 후속 테스트 케이스 생성을 위해 변성 관계를 사용한다.
5. 변성 테스트 케이스 실행
- 소스 테스트 케이스와 후속 테스트 케이스를 모두 실행하고, 결과가 변성 관계를 해치지 않는지 확인해 변성
테스트 케이스의 실패와 결함의 유무를 판단한다.
063 Black Box Testing of AI-Based Systems
 변성 테스팅은 생물정보학(bioinformatics), 웹 서비스(web services), 기계 학습 분류기
(machine learning classifiers), 검색 엔진(search engines) 및 보안(security) 등 다양하고
광범위한 AI 기반 애플리케이션 영역에 성공적으로 사용되고 있다. 연구에 따르면 3~6개의 변성
관계만 사용하는 경우에도 기존 테스트 오라클로 발견할 수 있는 결함의 90% 이상을 밝혀낼 수
있다 [Liu 2014].

References

29119-4 2015 ISO/IEC/IEEE 29119-4, Software and systems engineering - Software testing - Part 4:
Test techniques, ISO, 2015.
A/B 2019 Wikipedia contributors, "A/B testing," Wikipedia,
https://en.wikipedia.org/w/index.php?title=A/B_testing&oldid=926805728 (accessed November 21,
2019).
Chen 2018 Chen et al, Metamorphic Testing: A Review of Challenges and Opportunities,
ACM Comput. Surv. 51, 1, Article 4, January 2018.
Kuhn 2004 Kuhn et al, Software Fault Interactions and Implications for Software Testing,
IEEE Transactions on Software Engineering 30(6):418 - 421, July 2004.
Liu 2014 Liu et al, How effectively does metamorphic testing alleviate the oracle problem?,
IEEE Transactions on Software Engineering 40, 1, 4-22, 2014.
Segura 2016 Segura et al, A Survey on Metamorphic Testing,
IEEE Trans. on Software Engineering, Vol 42, No. 9, Sept 2016.

064 Testing AI Guidelines ver 1.8 065 Black Box Testing of AI-Based Systems
White Box Testing of 7.1 신경망 구조 (Structure of a Neural Network)

Neural Networks 신경망은 인간 두뇌의 신경망에서 영감을 얻은 계산 모델이다. 신경망은 [그림19]에서 볼 수 있는

것처럼, 연결된 노드(nodes) 또는 뉴런을 가진 여러 레이어로 구성되어 있다. 이 장에서는 가장 처음

07
나왔고 가장 단순한 형태를 가진 인공 신경망인 전방전달 신경망(feedforward neural network)
신경망 화이트박스
테스팅
을 예로 사용한다. 여기에 추가할 유일한 복잡성은 다층 퍼셉트론(multi-layer perceptron) 또는
은닉층(hidden layers) 등의 여러 레이어를 갖는 심층 신경망의 네트워크를 고려한다는 것이다.

[그림 19]:심층 신경망( Deep Neural Net)

입력 노드는 외부 세계에서 정보를 받고(예, 각 입력은 이미지의 픽셀값일 수 있다), 출력 노드는

외부 세계에 정보를 제공한다 (예, 분류). 은닉층의 노드들은 외부 세계와 연결돼 있지 않고 입력
노드에서 출력 노드로 정보를 전달하는 계산을 수행한다.
[그림 20]에서 보여지듯, 각 뉴런은 입력값을 받아들이고 활성값으로 알려진 출력값을 생성한다.
이 값은 양수, 음수 또는 0일 수 있다 (값이 0이면 뉴런이 후속 뉴런에 영향을 주지 않음). 각 연결은
가중치(이는 신경망이 훈련하면서 바뀜)를 갖고 각 뉴런은 편향성(bias)을 갖는다. 활성값은 입력
활성값, 입력 연결 가중치 및 뉴런의 편향성에 기반한 수식으로 계산한다.

[그림20]: 뉴런 활성값(Neuron Activation Values)

066 067 White Box Testing of Neural Networks

 지도 학습에서, 네트워크는 역전파(backward propagation)를 이용해 학습한다. 초기에 모든 [그림 22]에서 회색 뉴런은 활성값이 임계값을 초과한 뉴런을 보여준다. 따라서, 임계 범위는
노드(nodes)는 초기값으로 설정되고 첫 훈련 데이터 입력이 네트워크를 통해 들어간다. 결과는 이미 21/30 x 100 = 70% 이다.
나와 있는 정답과 비교해, 정답과 계산 결과 사이의 차이(오류)는 네트워크 이전 레이어로 들어가
가중치를 수정하는 데 사용된다. 이 역방향 오류 전파(backward error propagation)는 전체
네트워크를 통해 되돌아 가고 각 연결 가중치는 적절하게 업데이트된다. 더 많은 훈련 데이터를
네트워크에 공급함에 따라, 검증된 데이터로 평가할 준비가 될 때까지 오류로부터 점차적으로
학습함으로써 훈련된 네트워크의 성능을 결정한다.

7.2 신경망의 테스트 커버리지 측정 (Test Coverage Measures for Neural Networks)
실제로 구문 커버리지 100%는 보통 단일 테스트 케이스로 달성되므로 전통적인 커버리지 측정은
신경망에 유용하지는 않다. 결함은 보통 신경망 자체에 숨겨져 있다. 따라서, 신경망을 테스트할 때는
신경망의 뉴런(또는 뉴런 쌍)의 활성값에 기반한 다른 커버리지 측정 방법이 제안된다.
7.2.1 뉴런 커버리지 (Neuron Coverage)
일련의 테스트에서 뉴런 커버리지는 활성화된 뉴런을 신경망의 총 뉴런 수로 나눈 비율이다
(보통 백분율로 표시). 뉴런 커버리지에서 활성값이 0을 초과하면 뉴런이 활성화된 것으로 간주한다.
[그림 21]에서 회색 뉴런은 활성값이 0을 초과한 뉴런을 보여준다. 따라서 뉴런 커버리지는
16/30 x 100 = 53% 이다.
[그림22]: 임계점 커버리지(Threshold Coverage)
7.2.3 부호 변경 커버리지 (Sign Change Coverage)
일련의 테스트에 대한 부호변경 커버리지는 양 또는 음의 활성값을 가진 활성 뉴런을 신경망의
총 뉴런 수로 나눈 비율이다 (보통 백분율로 표시). 활성값이 0이면 음의 활성값으로 간주한다
[DeepCover 2018].
[그림 23]은 두 개의 테스트, T1과 T2의 결과이다. 회색 뉴런은 활성값이 0보다 큰 뉴런을
표시하고 흰색 뉴런은 활성값이 0개의 이하인 뉴런을 표시한다. T2에서 회색(양성 활성값)인 두 개
뉴런의 부호가 변경되었으며 이제 흰색으로 표시되는 것을 볼 수 있다. 따라서 이 두 테스트의 부호
변경 커버리지는 2/30 x 100 = 7% 이다.

[그림 21]: 뉴런 커버리지(Neuron Coverage)

7.2.2 임계점 커버리지 (Threshold Coverage)

일련의 테스트에 대한 임계점 커버리지는 임계 활성값을 초과하는 뉴런을 신경망의 총 뉴런
수로 나눈 비율이다 (보통 백분율로 표시). 임계 커버리지에서는 임계값으로 0과 1사이의 임계
활성값을 선택해야 한다. DeepXplore 도구의 ‘뉴런 커버리지’는 이 임계점 커버리지에 해당한다
[DeepXplore 2017]. [그림23]: 부호 변경 커버리지(Sign Change Coverage)

068 Testing AI Guidelines ver 1.8 069 White Box Testing of Neural Networks
 7.2.4 값 변경 커버리지 (Value Change Coverage)
일련의 테스트에 대한 값 변경 커버리지는 정해진 범위보다 활성값이 더 많이 바뀐 활성 뉴런
수를 신경망의 총 뉴런수로 나눈 비율이다 (보통 백분율로 표시).
값 변경 범위의 경우 변경량(change amount)으로 0에서 1 사이의 값을 선택해야 한다
[DeepCover 2018].
[그림 24]에는 T1과 T2라는 두 개의 테스트 결과가 나와 있다. 검정색 뉴런에 대한 활성값 1과
활성값 2가 두 테스트에서 합의된 두 개의 변경량과 다른 경우 이 뉴런은 값 변경 커버리지를 달성한
것으로 간주된다. 다른 뉴런 중 어느것도 이 수준의 변경을 달성하지 못하면, 값 변화 커버리지는
1/30 * 100 = 3% 이다.
[그림24]: 값 변경 커버리지(Value Change Coverage)
7.2.5 부호-부호 커버리지 (Sign-Sign Coverage)
일련의 테스트에 대한 부호-부호 커버리지는 뉴런들이 주로 다음 레이어에서 같은 상태(예,
부호를 변경하지 않음)에 머무는 동안, 각 뉴런이 부호를 변경함으로 인해(7.2.3절 참조) 다음 층에서
뉴런에 개별적으로 부호 변경이 일어나는 경우에 달성된다. 개념적으로 이 수준의 뉴런 커버리지는
변형된 조건/결정 커버리지(MC/DC)와 유사하다 [DeepCover 2018].
[그림 25]에는 두 가지 테스트, T1과 T2의 결과가 표시되어 있다. 회색 뉴런은 활성값이 0보다
큰 뉴런을 보여주고(양성), 흰색 뉴런은 활성값이 0 이하인 뉴런을 보여준다(음성). 세 번째 레이어의
한 뉴런이 양성(회색)에서 음성(흰색)으로 부호가 바뀌었고, 다음 레이어에서는 오직 하나의 뉴런이
070 Testing AI Guidelines ver 1.8
유사하게 양성에서 음성으로 바뀐 반면, 해당 레이어의 다른 뉴런은 부호를 변경하지 않았음을 알 수
있다. 따라서 이 두 가지가 첫 번째 테스트이다. 다른 뉴런 중 어느 것도 이 수준의 변경을 달성하지
못하면, 값 변화 커버리지는 1/30 x 100 = 3% 이다.
[그림25]: 부호-부호 커버리지(Sign-Sign Coverage)
7.2.6 레이어 커버리지 (Layer Coverage)
신경망의 전체 층에서 뉴런 세트에 대한 활성값이 어떻게 변경되는지(예, 절대적 또는 상대적)
에 기반해 커버리지를 작성할 수 있다. 이 분야에 대해서는 심도 있는 연구가 더 필요하다.
7.2.7 화이트 박스 측정의 테스트 효과 (Test Effectiveness of the White Box Measures)
신경망에 대한 화이트 박스 테스팅으로 여러 화이트 박스 커버리지를 측정하는 테스트 효과에
대한 자료는 현재까지는 미미한 상태이다. 그러나 일반적으로, 테스트를 많이 하면 적게 하는 것보다
더 많은 결함을 찾아내므로, 측정의 상대적 효과를 추론할 수 있다.
7.2.1-7.2.5에서 설명된 측정 커버리지에서 몇몇 포함 관계(subsumes relationships)를
도출할 수 있다. 다른 모든 측정값은 뉴런 커버리지를 포함하고 부호-부호 커버리지도 부호 변경
커버리지를 포함한다. 이론 측정값의 전체적인 포함 계층 구조가 [그림 26]에 표시되어 있다. 화살표가
한 측정값에서 다른 측정값을 가리키는 경우는 첫 번째 측정값이 완전히 달성되면 두 번째 측정값이
자동으로 달성됨을 의미한다. 예를 들어, 임계값 커버리지가 달성되면 뉴런 커버리지가 자동으로
달성됨을 보여준다.
071 White Box Testing of Neural Networks
 References

DeepCover 2018 Sun et al, Testing Deep Neural Networks,

https://www.researchgate.net/publication/323747173_Testing_Deep_Neural_Networks,
accessed Nov 2019, Mar 2018.
DeepTest 2018 Tian et al, DeepTest: Automated Testing of Deep-Neural-Network-driven Autonomous Cars,
ICSE ’18: 40th International Conference on Software Engineering, May 2018.
DeepXplore 2017 Pei et al, DeepXplore: Automated Whitebox Testing of Deep Learning Systems,
Proceedings of ACM Symposium on Operating Systems Principles (SOSP ’17), Jan 2017.

[그림26]: 화이트박스 신경망 포함 계층구조(White Box Neural Network Subsumes Hierarchy)

이해하기는 쉬우나 보통 단지 몇 개의 테스트 케이스만으로도 높은 수준의 뉴런 커버리지를

달성할 수 있으므로 이 테스트 효과는 제한적이다. 임계점 커버리지에 대한 초기 결과는 이것이
결함유발 복합경계조건사례( defect-inducing corner case)를 다루는 테스트 생성에 유용한 측정
방법처럼 보이지만, 임계값은 각 신경망에 대해 개별적으로 설정해야 할 수 있다. 값 변경 커버리지의
경우, 변경량이 클수록 자연스럽게 더 많은 테스트 케이스를 필요로 한다. 부호-부호 커버리지는 보통
여기에서 설명한 커버리지 기준 중 가장 엄격하다 [DeepCover 2018].

7.3 신경망을 위한 화이트 박스 테스팅 도구 (White Box Testing Tools for Neural
Networks)

현재로는 신경망의 화이트 박스 테스팅을 지원하는 상용 도구는 없지만 다음과 같이 몇 가지 연구용

도구가 있다:
· DeepXplore - 특히 심층 신경망을 테스트하기 위해 네트워크의 모든 뉴런(임계점 커버리지)을 포함하는
적대적 사례를 체계적으로 생성하기 위한 화이트박스 차등 테스트(백투백) 알고리즘을 제안한다 [DeepXplore
2017].
· DeepTest - 심층 신경망으로 구동되는 자동차의 오류 행동을 자동으로 감지하기 위한 체계적인 테스트
도구이다. DNN에 대한 부호-부호 커버리지를 지원한다 [DeepTest 2018].
· DeepCover - 이 장에서 정의한 모든 수준의 커버리지를 제공한다 [DeepCover 2018].

072 Testing AI Guidelines ver 1.8 073 White Box Testing of Neural Networks
Test Environments for 8.1 AI 기반 시스템의 테스트 환경 (Test Environments for AI-Based Systems)

AI-Based Systems AI 기반 시스템의 테스트 환경은 단위 레벨의 개발 환경, 시스템이나 인수 레벨의 생산 관련 테스트
환경과 같은 기존의 시스템을 테스팅하는 환경과 공통점이 많다. 기계 학습 모델을 격리해서 테스트할

08
때 3.8절에 설명한 것과 같이 일반적으로 개발 프레임워크 내에서 테스트하는 경우가 많다.
AI 기반 시스템의
테스트 환경
AI 기반 시스템과 기존 시스템이 요구하는 테스트 환경의 차이를 가져오는 두 가지 주 요인은,
첫째, 많은 AI 기반 시스템이 작동하는 환경은 규모가 크고 복잡하며 끊임없이 변화할 수 있기
때문이다. 가능한 모든 환경을 테스트하고, 실제 환경과 유사한 테스트 환경을 조성해 적절한 시간
안에 테스트한다면 테스팅에 들어가는 비용은 어마어마하게 높아질 것이다.
둘째, 인간과 물리적으로 상호작용할 수 있는 AI 기반 시스템에는 안전관련 컴포넌트가 있어
실제환경에서 테스트하기에는 부담과 리스크가 있다. 두 가지 요소 모두 가상 테스트 환경의 필요성을
보여준다.

가상 테스트 환경이 가져오는 이점은 다음과 같다:

· 가상 환경을 이용하면 위험한 시나리오를 자동차, 건물, 동물, 사람 등 테스트 중인 시스템이나 환경 내 다른
객체에 손상을 입히지 않으면서 안전하게 테스트할 수 있다. 가상 환경에서의 테스트는 일반적으로 실제
환경을 위해서도 더 바람직하다.
· 가상 환경은 실시간 실행을 요구하지 않는다. 가상환경은 적절한 처리 능력으로 더 빠른 실행이 가능한데
이는 많은 테스트를 단기간에 수행해 출시 일정을 크게 앞당길 수 있음을 의미한다. 클라우드 환경이라면 단일
시스템을 여러 가상 환경에서 병렬적으로 실행할 수도 있다.
· 가상 환경은 실제 환경보다 구축 및 실행 비용이 적게 든다. 예를 들어, 여러 도시 환경에서 휴대전화 통신
테스팅을 하는 경우 가상 전화기, 송신기, 지형으로 실험실에서 수행하면 관련 기능만 가상 테스트 환경에
포함시킬 수 있으므로 여러 위치에서 구동되는 실제 환경에서 테스트하는 것보다 훨씬 저렴하다 [Nokia
2019]. 그러나 일부 가상 테스트 환경은 실제 환경을 대표할 수 있어야 하며 어떤 면에서는 실제 환경과 매우
유사해야 한다. 예를 들어, 자율주행차가 보행자를 피하는 테스팅은 높은 수준의 이미지 대표성을 요구할 수
있다.
· 실제 환경에서는 종종 경계(edge) 시나리오를 생성하기가 매우 어려울 수 있지만 가상 환경은 이런 시나리오와
경계(edge) 시나리오의 다양한 변형을 여러 번 실행하는 것이 가능하다. 가상 환경은 테스터에게 실제
테스팅보다 더 높은 수준의 제어 기능을 제공한다. 또한, 이런 테스팅에 어느 정도의 무작위성을 줄 수 있다. AI
로 구현된 인간을 자율주행 자동차 테스팅에 포함하는 것도 이런 행위에 해당한다.
· 가상 환경은 하드웨어 시뮬레이션을 지원함으로써 하드웨어 컴포넌트를 실제로 사용할 수 없을 때(아직
구축하지 않은 경우에도) 하드웨어 컴포넌트로 시스템을 테스트하고 다른 하드웨어 솔루션도 저렴하게
시험하고 비교할 수 있게 해준다.
· 가상 환경은 뛰어난 관찰성(observability)을 제공해 테스트 중인 시스템의 모든 시나리오에 대한 반응을

074 075 Test Environments for AI-Based Systems

 측정하고 필요한 경우 분석할 수 있게 한다.
· 가상 환경에서는 원자력 사고 현장에서 작업하는 로봇이나 우주 탐사에 사용되는 시스템과 같이 실제 운영
환경에서 테스트할 수 없는 시스템을 테스트할 수 있다.
가상 테스팅은 주어진 시스템에 특수하게 설치된 시뮬레이터로 수행할 수 있지만 특정 도메인을 위한
재사용 시뮬레이터는 상용 제품이나 오픈 소스 둘 다 사용이 가능하다. 예를 들면,
· 모스(Morse)는 모듈화된 로봇 오픈 시뮬레이터 엔진으로 블렌더 게임 엔진 기반의 범용 모바일 로봇
시뮬레이터(단일 또는 다중 로봇)이다 [Morse 2019].
· AI 해비타트(AI Habitat)는 페이스북 AI 에서 개발한 시뮬레이터 플랫폼으로 사실적인 3D 환경에서 내장
에이전트(가상 로봇 등)를 교육하도록 설계되었다 [Habitat 2019];
· 드라이브 컨스텔레이션(DRIVE Constellation)은 클라우드 기반 플랫폼에서 작동하는 NVIDA사의
자율주행차용 개방 및 확장가능 플랫폼으로 수십억 마일의 자율주행 테스팅을 생성할 수 있다 [DRIVE 2019].
8.2 테스트 시나리오 도출 (Test Scenario Derivation)
AI 기반 시스템의 체계적 테스팅을 위해서는, 개별 AI 컴포넌트, 이 컴포넌트와 시스템의 나머지
컴포넌트 간 상호작용, 상호작용하는 컴포넌트가 통합된 전체 시스템, 환경과 상호작용하는 시스템을
테스트할 테스트 시나리오를 생성해야 한다.
테스트 시나리오는 다음과 같이 여러 원천에서 도출할 수 있다:
· 시스템 요구사항 (System requirements)
· 사용자 이슈 (User issues)
· 자동으로 보고된 이슈 (Automatically reported issues) (예, 자율 시스템)
· 사고 보고서 (Accident reports) (예, 물리적 시스템)
· 보험 데이터 (Insurance data) (예, 자율주행차 같은 보증된 시스템)
· 규제 기관 데이터 (Regulatory body data) (예, 관련법에서 도출)
· 다양한 레벨에서의 테스팅 (Testing at various levels) (예, 테스트 트랙 또는 실제 도로에서 발생한 테스트
장애 및 이상치가 다른 테스트 레벨에서 자율주행차를 테스트 하는 테스트 시나리오로 사용될 수 있다.
반면 가상 테스트 환경에서의 테스트 시나리오 예제는 가상 테스트 환경의 대표성을 확인하기 위해 실제
도로에서도 실행해야 한다.)
자율주행차의 시스템 테스팅을 위해 테스트 시나리오를 생성하는 조합 테스팅 사용은 6.1절에
설명되어 있다. 변성 테스팅(Metamorphic testing)(6.4절 참조)과 퍼즈 테스팅(fuzz testing)도
테스트 시나리오를 생성하기 위해 사용할 수 있다.
076 Testing AI Guidelines ver 1.8
8.3 규제 테스트 시나리오와 테스트 환경 (Regulatory Test Scenarios and Test
Environments)
안전관련 AI 기반 시스템의 경우, 시스템에 일정 수준의 규제가 적용돼야 한다. 이 규제를 적용하기
위해 관련 기관은 두 가지 방식으로 접근할 수 있다. 즉, 개발하는 조직이 자체적으로 규제를
확인하는 방법이 있고, 규제 기관이 시스템의 최소한의 표준을 준수했는지(인증 방식) 독립적인
보증을 제공하는 방법이 있다.
인증 방식을 따르게 되면, 테스팅 접근법에 따라 규제 기관과 인증 대상 시스템을 제공하는 주체
사이에 정보가 공유돼야 한다. 이 접근 방식의 핵심적인 부분은 테스트 환경 정의 및 해당 환경에서
테스트 자동화를 사용해 실행할 수 있는 공유 테스트 시나리오이다. 과적합(overfitting)을 방지하기
위해 각 테스트에 대한 매개변수값을 변경하여 새로운 시나리오를 생성할 수 있도록 공유 테스트
시나리오의 핵심 세트를 매개변수화(parameterized)해야 하며, 규제 기관은 공유되지 않은 일련의
개인 테스트 시나리오를 유지한다. 매개변수화(parameterization)와 개인 시나리오는 시스템이
단지 알려져 있는 테스트를 통과하기 위해 구축되지는 않았는지 확인해야 하며, 이 접근 방식을 통해
규제 기관은 시스템의 실제 사용으로 인한 잠재적인 문제 상황을 파악함으로써 새로운 시나리오를
추가할 수 있다.
References
Drive 2019 NVIDIA DRIVE CONSTELLATION - Virtual Reality Autonomous Vehicle Simulator,
NVIDIA Products, https://www.nvidia.com/en-us/self-driving-cars/drive-constellation/,
accessed Nov 2019.
Habitat 2019 Savva et al, Open-sourcing AI Habitat, an advanced simulation platform for embodied AI research,
https://ai.facebook.com/blog/open-sourcing-ai-habitat-an-simulation-platform-for-embodied-ai-
research/, accessed Nov 2019, June 2019.
Morse 2019 Official documentation for the MORSE project,
http://www.openrobots.org/morse/doc/0.2.1/morse.html, accessed Nov 2019.
Nokia 2019 Nokia's revolutionary 5G virtual testing speeds deployment, Press Release,
https://www.globenewswire.com/news-release/2019/04/23/1807667/0/en/Nokia-s-
revolutionary-5G-virtual-testing-speeds-deployment.html, accessed Nov 2019, April 2019.
077 Test Environments for AI-Based Systems
Using AI for Testing 9.1 AI 주도 테스팅 소개 (Introduction to AI-Driven Testing)

테스팅에 AI 수년 동안 소프트웨어 테스팅에서 자동화 규모를 늘리려는 소프트웨어 테스터들의 지속적인 노력에도
활용하기 불구하고 자동화 증가율은 기대만큼 빠르지 않은 것이 현실이다. 테스트 중인 소프트웨어가 변경되면

09
초기에 자동화 스크립트를 작성하는 것처럼 여전히 수동으로 자동화 스크립트를 재작성해야 하는
것이 주요 문제였다. 그러나, 최근 AI 기술의 발달로 수동 테스트 작업을 더 많이 자동화할 수 있다.
이 문서는 AI 기반 시스템의 테스팅에 중점을 두고 있지만, AI를 소프트웨어 테스팅(AI기반
시스템을 포함한 모든 형태의 소프트웨어) 수행 도구로 사용할 수도 있다. 이 장에서는 이에 대한
개념을 간략하게 소개하고 유스 케이스 예제를 통해 AI가 소프트웨어 테스팅을 지원하는 방법을
보여준다.

9.2 테스팅에 사용하는 AI 형태 (Forms of AI used for Testing)

마크 하만 교수(Mark Harman, UCL, Facebook)에 따르면 소프트웨어 엔지니어링(및 테스팅)에

유용한 AI형태에는 다음과 같은 3가지가 있다 [Harman 2016]:
· 확률적(Probabilistic) 소프트웨어 엔지니어링 - AI는 본질적으로 불분명하고(fuzzy) 확률적인 실질적 문제를
해결할 수 있다. 예를 들어, AI는 인간 행동의 확률적 특성 때문에 사용자 행동을 분석하고 예측하는 데 사용할
수 있다.
· 분류(classification), 학습(learning), 예측(prediction) - AI는 프로젝트 계획의 일환으로 비용 예측에 사용할
수 있다. 예를 들어, 기계 학습 기술은 결함 예측에 사용할 수 있다.
· 검색 기반 소프트웨어 엔지니어링(SBSE, Search Based Software Engineering) - AI는 크고 복잡한 검색
공간의 계산적 검색을 사용해 최적화 문제를 해결하곤 한다. 검색 기반 소프트웨어 테스팅은 SBSE에서 가장
성공적이고 광범위하게 적용 가능한 영역일 수 있다. 그 예로, 주어진 커버리지 기준을 달성하는 최소 테스트
케이스 세트 식별과 리그레션 테스트 케이스 우선순위화를 들 수 있다.

9.3 AI가 지원하는 테스트 유형 (Test Types Supported by AI)

AI로 지원할 수 없는 소프트웨어 테스팅 영역은 거의 없다. 다음은 테스팅에 AI를 사용하는 예이다:
· 명세 리뷰(Specification Review) - AI는 자연어로 작성된 명세서를 해석하고 잠재적인 오류(anomalies) 및
결함(defects)을 식별한다. 유사하게, AI 기반 모델 검사기(AI-Based model checkers)를 사용해 공식 및
준공식(semi-formal) 모델에서 문제를 찾을 수 있다.
· 명세 기반 스크립트 생성(Specification-Based Script Generation) - AI는 자연어로 작성된 명세서를

078 079 Using AI for Testing

 해석하고 생성된 모델의 커버리지를 제공하기 위해 테스트 스크립트를 생성할 수 있다. - 모듈 연식(Module age)
· 테스트 전략 지원(Test Strategy Assistant) - AI는 여러 프로젝트에서 수집한 빅데이터를 분석해 리스크를 · 사람 및 조직 관련 메트릭(People and organizational metrics)
학습한다. - 작성자 수(Number of authors)
· 사용 프로파일(Usage Profiling) - AI는 시스템 사용에서 수집한 빅데이터를 분석해 시스템이 어떻게 - 개발자 경험(Developer experience)
사용될지 예측한다.
· 탐색적 테스팅(Exploratory Testing) - AI는 사람의 탐색적 테스팅 세션을 관찰해 발견한 것을 학습하고 위 내용 외에도 잠재적 요소가 매우 많기 때문에 이런 요소들과 결함 속성 사이의 관계를 판단하는
적용한다. 것은 인간의 능력을 넘어서는 것이다. 또한, 두 상황이 같지 않기 때문에 모든 프로젝트와 조직에서
· 크라우드 테스팅(Crowd Testing) - AI는 가장 유용한 피드백을 식별하고 중복 피드백을 제거하기 위해 재사용 가능한 결함 예측용 기계 학습(ML) 모델을 만드는 것 역시 불가능하다. 그 대신, 사용에
다수의 크라우드 테스터들의 응답을 분석한다. 최적화된 모델을 만들기 위해 현지 프로젝트 또는 조직 내 사용 가능한 데이터로 결함 예측을 위한
· 결함 관리(Defect Management) - AI는 결함을 객관적으로 분류하고 우선순위화한다. 기계 학습(ML)을 수행할 필요가 있다.
· 사용자 인터페이스 확인(User Interface Verification) - AI는 웹 페이지를 비교하고 눈에 보이지 않는 렌더링 기계 학습(ML)을 사용한 결함 예측은 여러 다양한 상황에서 성공적으로 사용되고 있다 (예,
(rendering), 크기 및 위치 차이를 무시하고 인지 가능한 차이를 식별한다. Tosun, 2010 & Kim 2007). 결함을 가장 잘 예측하는 방법은 널리 사용되는 소스 코드 메트릭이
· 웹 앱 스파이더링(Web App Spidering) (차등 테스팅, differential testing) - AI는 스크린샷 및 적재 시간 아니라 사람 및 조직적 측정인 것으로 밝혀졌다 [Nagappan 2008].
같은 데이터를 수집하는 웹 앱을 반복적으로 크롤링(crawling)하고 현재 데이터와 이전 데이터를 비교해
잠재적 문제를 찾아냄으로써 문제를 식별한다. 9.4.2 정적 분석 (Static Analysis)
· 항목 위치(Element Location) - AI는 버튼, 텍스트 박스 등의 웹 항목을 찾아내 테스트 스크립트에 하드 정적 분석 도구(Static analysers)는 프로그램을 실행하지 않고 스캔해 소스 코드의 문제를
코딩할 필요가 없다 (예, Appium에 적용됨). 탐지하는 자동화 도구이다. 정적 분석 도구는 결함 예측기(bug predictor)는 아니지만 일반적으로
코드에 문제가 있다고 여겨지는 위치를 식별해 유사한 기능을 제공한다. 페이스북의 인퍼(Infer)
도구 [Facebook 2019]는 추상화 변환(Abstract Interpretation) 형식을 사용해 안드로이드와
9.4 테스팅을 위한 AI 유스 케이스 예제 (Example Use Cases of AI for Testing) iOS의 C, 오브젝트-C, 자바를 분석한다. 기존의 정적 분석 도구에 비해 빠르게 작동하며 몇 분
안에 수백만 줄의 코드를 분석할 수 있어 지속적 통합(continuous integration)으로 사용하기에
9.4.1 결함 예측 (Bug Prediction) 이상적이다. 페이스북은 표시된 오류의 약 80%가 수정되므로 거짓 경고 비율(false alarm rate)이
결함 예측 도구는 테스트 우선순위화 지원을 위해 시스템의 어떤 부분에 결함 존재가능성이 상대적으로 낮다고 주장하며, 현재 페이스북, 인스타그램, 우버 및 스포티파이(Spotify) 를 비롯한
가장 높은지에 대한 지침을 제공한다 (예, ‘테스트할 가치가 있는’ 또는 ‘테스트할 가치가 없는’의 여러 조직에서 성공적으로 사용되고 있다고 한다. 이 정적 분석 도구는 오픈 소스로 제공되고 있다.
형태로 분류). 이 결과에 영향을 주는 몇 가지 요소는 다음과 같다:
· 소스 코드 메트릭(Source code metrics) 9.4.3 리그레션 테스트 최적화 (Regression Test Optimization)
- 코드 라인 수(Lines of code) 리그레션 테스팅은 시스템 변경으로 인해 변경하지 않은 시스템의 다른 부분에 원치 않는
- 주석 수(Number of comments) 부작용이 생기지 않았음을 확인하기 위해 수행한다. 이는 이전에 실행한 테스트를 재실행해 결과가
- 순환 복잡도(Cyclomatic complexity) 동일한지 확인하는 활동이다. 따라서 기술적으로나 경제적으로 가능한 많은 자동화가 필요한
· 프로세스 메트릭(Process metrics) 반복적인 작업이다. 시스템이 변경되면, 새롭게 생성해서 시행해 성공했던 테스트가 리그레션 테스트
- 수정된 모듈 리비전(Revisions made to module) 스위트에 추가될 수 있다. 이런 방식으로 리그레션 테스트 스위트는 시간이 지남에 따라 방대해지고
- 리팩토링된 시간(Times refactored) 종종 수행에 과도한 노력과 시간(수정된 소프트웨어 릴리스가 지연됨), 이에 따른 많은 비용이
- 수정 시 수정된 시간(Times fixed / when fixed) 들어가는 상황이 발생한다 (테스팅 예산의 약 80% [Hall 2012]).
- 변경 코드 라인 수(Lines of code changed) (변경 코드, code churn) 리그레션 테스트 스위트가 지나치게 커지는 것을 방지하기 위해, 중복 없이 효과적이고

080 Testing AI Guidelines ver 1.8 081 Using AI for Testing

효율적인 테스트만 남기는 ‘가지치기(pruned)’ 작업을 자주 수행해야 한다. 이런 작업을 리그레션
테스트 최적화라고 하며 이를 통해 결함 검출률은 높고 실행 비용은 낮은 리그레션 스위트를 만들어
낼 수 있다. 그러나 테스터가 이에 대한 지식이 부족하고 시스템 문서가 열악하면 이런 가지치기
작업을 수동으로 수행하는 데 많은 비용과 시간이 소요될 수 있다.
리그레션 테스트 최적화를 수행하는 AI 기반 도구를 위해 다음과 같은 테스트 케이스에 대한
정보를 수집해야 한다:
· 이전에 결함을 찾은 테스트
· 최근 변경된 코드를 실행한 테스트
· 높은 리스크 영역을 찾아낸 테스트
· 테스트로 달성한 테스트 커버리지
· 테스트 실행 시간
· 테스트로 확인된 요구사항
도구는 이 정보를 사용해 다른 가용한 정보와 함께 이상적으로 많은 리그레션 결함을 찾아내면서
시간은 적게 드는 최적화된 리그레션 스위트를 만들어 낼 수 있다. 이런 AI 기반 리그레션 테스트
최적화 도구는 더 효과적이고 효율적인 리그레션 테스트 스위트를 생성하기 위해 테스트 케이스를
선택하고 우선순위화하고 심지어는 보강하는 기법을 사용한다. 연구에 따르면 대부분의 결함을
탐지하면서 리그레션 테스트 스위트의 크기를 50% 줄일 수 있고 [Rai 2014], 요구사항 커버리지를
모두 달성하면서 94%로 줄일 수 있다 [Gottlieb 20].
9.4.4 테스트 입력 생성 (Test Input Generation)
테스트 완료 목표를 달성하기 위해 테스트 입력 세트를 자동으로 생성해 주는 도구는 많은
테스트 설계자에게 유용하다. 이런 도구의 주된 목표는 보통 안전관련 소프트웨어에 대한 규제
표준에서 요구되기 때문에 구문(statements)이나 분기 커버리지(branch coverage) 같은 구조적
커버리지(structural coverage) 기준인 경우가 많다.
이런 도구에 사용되는 기술에는 기호 실행(symbolic execution)과 검색 기반 AI가 있다. 이
분야에서 C용 오픈소스 도구[Lakhotia 2012] 및 자바용 EVOSUITE [EVOSUITE 2019], 비주얼
스튜디오의 일부인 C#용 인텔리테스트(Intellitest) [IntelliTest 2015] 등과 같은 여러 도구를
사용할 수 있다.
실증 연구에 따르면 테스트 입력 생성 도구는 추가 비용을 거의 또는 전혀 들이지 않고
커버리지를 늘리는 데 좋지만, 이를 사용해 결함 감지 기능이 개선되는 것으로 보이지는 않는다
[Fraser 2015].
규제 표준(regulatory standards)에서 요구하는 커버리지 기준을 달성하는 것 외에도 이런
도구들은 리그레션 테스트 스위트 자동 생성에 큰 잠재력을 가지고 있다. 종종 리그레션 테스트를
수행해야 하지만 리그레션 테스트 스위트를 사용하지 못하는 경우가 있다. 테스트 입력 생성 AI 기반
082 Testing AI Guidelines ver 1.8
도구를 사용하여 원본 프로그램에 대해 ‘완벽한(complete)’ 테스트 입력 세트를 자동으로 생성할
수 있다. 그런 다음 테스트 입력을 원래 프로그램에서 실행해 그에 상응하는 실제 결과 세트를 작성할
수 있으며, 이러한 입력과 실제 결과 모두 리그레션 테스트 스위트의 베이시스 형태로 통합할 수 있다.
9.4.5 자동화된 탐색적 테스팅 (Automated Exploratory Testing)
‘애플리케이션 응답 없음’(ANR-Application Not Responding) 또는 단순한 시스템 충돌
(crash) 등의 결과 확인을 위해 실행하는 퍼즈(fuzz) 테스팅에서 테스트 입력을 임의로 생성하는
안드로이드 몽키(Android Monkey) [Monkey 2019] 같은 앱을 개발했음에도, 모바일 앱 테스트의
많은 부분이 여전히 수동으로 진행되고 있다. 이런 테스트는 거의 또는 전혀 준비가 필요하지 않기
때문에 대부분의 앱 개발자는 이러한 임의 테스트를 실행해 앱의 심각한 문제를 식별한다. 그러나
안드로이드 몽키의 문제는 결함을 일으키는 데 필요한 입력 시퀀스가 매우 클 수 있다는 것이며,
이는 많은 개발자가 디버그가 너무 어렵거나 실제적인 사용과 맞지 않는다는 등의 이유로 이 문제를
가볍게 여긴다는 것을 의미한다.
AI 기반 도구는 사용자 인터페이스, 코드 커버리지, 휴리스틱스(heuristics)에 기반으로 테스트
입력 시퀀스를 자동으로 생성해 무작위 방식(random approach)을 개선할 수 있다. 안드로이드
앱의 탐색적 테스팅을 자동으로 수행하는 도구로는 디노드로이드(Dynodroid) [Machiry 2013],
사피엔즈(Sapienz) [Mao 2016]가 있다. 디노드로이드는 휴리스틱스를 사용해 안드로이드 몽키와
유사한 코드 커버리지 달성에 필요한 입력 및 이벤트 수를 줄여준다. 사피엔즈는 코드 커버리지를
최대화하고 발견하는 결함 수를 늘리는 다목적 접근법을 사용한다. 결과에 따르면 AI 기반 도구는
동등 수준의 커버리지를 달성하고 더 많은 결함을 발견하면서 안드로이드 몽키의 평균 시퀀스 단계가
약 15,000이던 것을 약100으로 줄여준다 [Mao 2016].
References
EVOSUITE 2019 EVOSUITE - Automatic Test Suite Generation for Java,
http://www.evosuite.org/, accessed Nov 2019.
Facebook 2019 A tool to detect bugs in Java and C/C++/Objective-C code before it ships,
https://fbinfer.com/, accessed Nov 2019.
Fraser 2015 Fraser et al, Does Automated Unit Test Generation Really Help Software Testers?
A Controlled Empirical Study, ACM Transactions on Software Engineering and Methodology,
Volume 24 Issue 4, August 2015.
Gottlieb 2016 Gottlieb et al, Automated regression testing using constraint programming,
AAAI'16 Proceedings of the Thirtieth AAAI Conference on Artificial Intelligence, Feb 2016.
Hall 2012 Hall et al, A systematic literature review on fault prediction performance in software engineering",
Software Engineering, IEEE Transactions on, vol. 38, 2012.
Harman 2016 Harman, The Role of Artificial Intelligence in Software Engineering,
In First International Workshop on Realizing AI Synergies in Software Engineering (RAISE), pp. 1-6.
083 Using AI for Testing
 IEEE, June 2012.
IntelliTest 2015 How to: Generate unit tests by using IntelliTest,
https://docs.microsoft.com/en-us/visualstudio/test/generate-unit-tests-for-your-code-with-
intellitest?view=vs-2019, accessed Nov 2019.
Kim 2007 Kim et al, Predicting Faults from Cached History, 29th International Conference on Software
Engineering (ICSE’07), 2007.
Lakhotia 2012 Lakhotia et al, AUSTIN: A tool for Search Based Software Testing for the C Language and
its Evaluation on Deployed Automotive Systems, 2nd International Symposium on Search Based
Software Engineering, 2010.
Machiry 2013 Machiry et al, Dynodroid: an input generation system for Android apps,
Proceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering, Aug 2013.
Mao 2016 Mao et al, Sapienz: multi-objective automated testing for Android applications,
Proceedings of the 25th International Symposium on Software Testing and Analysis, July 2016.
Monkey 2019 UI/Application Exerciser Monkey, Android Studio User Guide,
https://developer.android.com/studio/test/monkey, accessed Nov 2019.
Nagappan 2008 Nagappan et al, The Influence of Organizational Structure on Software Quality:
An Empirical Case Study, Proceedings of the 30th international conference on Software engineering
(ICSE’08), May 2008.
Rai 2014 Rai et al, Regression Test Case Optimization Using Honey Bee Mating Optimization Algorithm
with Fuzzy Rule Base, World Applied Sciences Journal 31 (4): 654-662, 2014.
Tosun 2010 Tosun et al, AI-Based Software Defect Predictors: Applications and Benefits in a Case Study,
Proceedings of the Twenty-Second Innovative Applications of Artificial Intelligence
Conference (IAAI-10), 2010.

084 Testing AI Guidelines ver 1.8 085 Using AI for Testing

Glossary 용어 정의

A/B testing A/B 테스팅 automated exploratory testing 자동화된 탐색적 테스팅
테스터가 두 시스템 중 어느 시스템 성능이 나은지 판단 가능하게 하는 통계적(statistical) 테스팅 접근법 (분리-수행 테스팅 도구의 지원을 받는 탐색적 테스팅
(split-run testing)이라고도 함)
autonomous system 자율 시스템
accuracy 정확성 인간의 개입 없이 일정 기간 동안 작업 가능한 시스템
분류모델(classifier)을 평가하는 데 사용하는 성능 메트릭(performance metric)으로 분류 예측 중 맞은 비율 측정
autonomy 자율성
activation value 활성값 인간의 개입 없이 일정 기간 동안 작업할 수 있는 시스템의 능력
신경망(neural network) 내 노드(node)의 활성화 함수(activation function)의 결과값
back-to-back testing 백투백 테스팅
adaptability 적응성 대체 시스템을 일종의 수도-오라클(pseudo-oracle)로 사용해서 같은 입력값에 대해 비교할 수 있는 기대 결과를 만드는 테
기능 및 비기능 요구사항을 지속적으로 충족하기 위해 환경 변화에 대응하는 시스템의 능력 스팅 접근법
※ 예: 수도-오라클(pseudo-oracle)은 이미 존재하는 시스템, 독립적인 팀이 개발한 시스템 또는 다른 프로그래밍 언어
adversarial attack 적대적 공격 로 구현된 시스템일 수 있다. (일명, 차등 테스팅: differential testing)
신경망에 오작동을 일으키기 위해 의도적으로 적대적 데이터 예제를 사용하는 것
backward propagation 역전파
adversarial example 적대적 예제 네트워크 결과를 가지고 계산된 에러를 기반으로 망에서 사용하는 가중치를 결정하기 위해 인공 신경망에서 사용하는 방법
신경망이 높은 확률로 잘못된 결과를 예측하도록 대상 데이터 예제를 일부 수정한 입력값 ※ 참조 1: 심층 신경망을 훈련하는 데 사용한다.

adversarial testing 적대적 테스팅 bias 편향성

신경망이 가진 결함을 식별하기 위해 적대적 예제의 생성 및 실행을 기반으로 하는 테스팅 접근법 기계 학습 모델이 제공한 예측값과 실제값의 편차를 측정한 것 (‘불공평성’이라고도 함)

AI Effect AI 효과 CEN European Committee for Standardization

기존에는 AI 시스템으로 취급하던 시스템이 기술의 진보로 격하(downgraded)된 상황 유럽 표준화 기구

AI Quality Metamodel AI 품질 메타모델 CENELEC European Committee for Electrotechnical Standardization

AI 기반 시스템의 품질을 보장하기 위한 메타모델 유럽전기표준화 위원회
※ 참조 1: DIN SPEC 92001에 정의돼 있음
classifier 분류기
artificial intelligence (AI) 인공지능 분류에 사용하는 ML 모델
(1) 일반적으로 지능적인 존재와 연관된 작업을 수행하는 시스템의 능력
(2) 추론(reasoning), 학습(learning) 및 자기계발(self-improvement)과 같은 인간 지능과 연관된 기능을 수행하는 데이 clustering 군집화
터 처리 시스템 개발에 전념하는 컴퓨터 과학 분과 동일한 그룹(즉, 하나의 클러스터)의 객체가 다른 클러스터의 객체보다 서로 유사성이 높도록 객체 세트를 그룹화하는 것
[ISO/IEC 2382:2015, 정보 기술 -- 용어]
combinatorial testing 조합 테스팅
artificial neural network 인공 신경망 테스트 케이스가 여러 매개 변수값의 특정 조합을 실행하도록 설계한 블랙 박스 테스트 설계 기법
조정 가능한 가중치를 가진 가중치 링크로 연결된 단순 처리 유닛으로 구성된 망. 각 유닛은 입력값에 비선형 함수
(nonlinear function)를 적용한 값을 생성하며, 다른 유닛으로 전송하거나 결과값으로 표시한다. confusion matrix 혼동 행렬
※ 참조 1) 일부 신경망은 신경계 뉴런의 기능을 시뮬레이션하기 위해 쓰이지만 대부분의 신경망은 연결주의 모델 참과 거짓값이 알려진 특정 테스트 데이터에 대한 분류기의 성능을 설명하는 데 사용하는 표
(connectionist model)로 인공 지능에 사용된다.
※ 참조 2) 비선형 함수의 예로는 임계치 함수(threshold function), 시그모이드 함수(sigmoid function), 다항식 함수 data pre-processing 데이터 전처리
(polynomial function)가 있다. 가공하지 않은 데이터를 ML 알고리즘에서 ML 모델을 만들기 위해 사용할 수 있는 상태로 변환하는 ML 워크 플로우의 일부
[ISO/IEC 2382] ※ 참조 1: 전처리(Pre-processing)는 재포맷(reformatting), 특이값(outliers)과 중복 제거, 데이터 세트의 완전성 보

086 Testing AI Guidelines ver 1.8 087 Glossary

 장을 포함할 수 있다. feature engineering 특성 엔지니어링
모델에 나타나야 하는 기본 관계를 대표하는 원(raw) 데이터의 속성을 훈련 데이터에서 사용하도록 추출하는 활동
deep learning 딥 러닝 동의어: 특성 선택(feature selection)
하나 이상의 숨겨진 레이어를 가진 신경망의 훈련을 통해 풍부한 계층적 표현을 생성하는 접근법
flexibility 유연성
deep neural net 딥 신경망 시스템이 초기 사양(initial specification) 외의 상황에서 동작할 수 있는 능력 (즉, 목표 충족을 위해 실제 상황에 맞춰 동작
두 개 이상의 레이어를 갖는 신경망 을 변경)

deterministic system 결정적 시스템 forward propagation 정방향 전파

특정 입력 세트와 시작 상태가 주어지면, 항상 동일한 출력 세트와 최종 상태를 생성하는 시스템 입력을 수용하고 활성화 함수(activation functions)를 사용해 네트워크 계층을 통해 일련의 값을 전달함으로써 예측한 출
력을 생성하는 신경망 프로세스
drift 표류
시간이 지남에 따라 발생하는 ML 모델 동작에 대한 변화 fuzz testing 퍼즈 테스팅
※ 참조 1: 일반적으로 이런 변경은 예측 정확도를 떨어뜨리고 모델을 새로운 데이터로 다시 학습하는 것이 필요할 수 있다 퍼즈(fuzz)라고하는 대량의 임의(random) 또는 임의에 가까운 데이터를 사용해 테스트 항목에 대한 입력값을 생성하는 소
(일명 degradation(악화) 또는 staleness(부패) 라고도 함). 프트웨어 테스팅 접근법

ETSI European Telecommunications Standards Institute general AI 일반 AI

유럽전기통신표준협회 전 분야의 인지 능력에서 인간과 맞먹는 지적인 행동을 보이는 AI (강력한 AI(strong AI)라고도 함)

evolution 진화 General Data Protection Regulation (GDPR) 일반개인정보보호법

변경에 대응하는 시스템의 능력 유럽연합(EU) 시민 및 유럽경제공동체(EEA)에 적용되는 데이터 보호와 개인정보 보호에 관한 법령
※ 참조: 이 변경은 사용자 요구사항 및 시스템 자체의 변경사항을 포함할 수 있다. ※ 참조 1: EU 및 EEA 지역 외부에서의 개인 데이터 전송에 대해서도 언급하고 있다.

exploratory testing 탐색적 테스팅 graphical processing unit (GPU) 그래픽 처리 장치

테스터가 테스터의 기존 관련 지식, 테스트 항목의 사전 탐색(이전 테스트 결과 포함) 및 일반적인 소프트웨어 동작 및 장애
유형에 대한 발견적 학습(heuristic)인 "경험 법칙(rule of thumb)"을 기반으로 테스트 설계 및 실행을 동시에 수행하는 경
험 기반 테스팅
※ 참조: 탐색적 테스팅은 그 자체로 크게 문제가 아닌 것처럼 보이지만 테스트 중인 소프트웨어의 다른 속성을 방해해 실
패하게 할 위험이 있는 숨겨진 속성(숨겨진 동작 포함)을 찾아내는 것이다.
디스플레이 장치로 출력하기 위해 프레임 버퍼에서의 이미지 생성 가속화를 목표로 메모리를 조작하고 변경하도록 설계한
애플리케이션 특화 집적 회로(application-specific integrated circuit)
hyperparameter 초매개변수
신경망의 구조와 훈련법을 정의하기 위해 사용하는 변수

F1-Score F1-점수 IEEE Institute of Electrical and Electronics Engineers

분류기를 평가하는 데 사용하는 성능 메트릭으로, 리콜(recall)과 정밀도 사이의 균형(조화 평균(harmonic average))을 제 전기 전자 기술자 협회
공한다.
machine learning (ML) 기계 학습 (머신 러닝)
false negative 거짓 음성 시스템이 데이터 또는 경험으로부터 배울 수 있도록 계산 기법을 사용하는 프로세스
실제로는 문제가 아닌 장애를 잘못 보고한 것 ※ 참조 1: 인간과 상호작용할 수 있고 이러한 상호작용을 통해 학습 행동을 최적화할 수 있는 기계 학습 알고리즘. 이 "인
※ 예: 골이 들어갔지만 심판이 오프사이드를 판정한 경우 간 개입(human-in-the-loop)"은 계산적으로 어려운 작업을 훨씬 짧은 시간 내 해결하는 데 도움이 될 수 있다. 이 기계
학습 분야를 대화형 기계 학습(iML: Interactive Machine Learning)이라고도 함
false positive 거짓 양성 [ISO/IEC 23053]
실제로는 문제이지만 장애가 아니라고 잘못 보고한 것
※ 예: 오프사이드이지만 심판이 골이라고 판정한 경우 metamorphic relation 변성 관계
원(source) 테스트 케이스에서 후속(follow-up) 테스트 케이스로의 테스트 입력 변경이 원 테스트 케이스에서 후속 테스트
케이스로의 기대 출력 변경에 어떻게 영향을 미치는지 설명한다.

088 Testing AI Guidelines ver 1.8 089 Glossary

metamorphic testing 변성 테스팅 overfitting 과적합
명세 기반이 아닌 이전 실제 결과에서 기대 결과를 추정하는 테스팅 훈련 데이터에 너무 근접한 ML 모델을 생성하여 새로운 데이터를 일반화하지 못하는 ML 모델을 생성하는 것

ML algorithm ML 알고리즘 pairwise testing 페이와이즈 테스팅

ML 훈련 데이터에서 나온 ML 모델 생성에 사용하는 알고리즘 각 입력 매개 변수 쌍의 가능한 모든 이산 조합(discrete combinations)을 실행하도록 테스트 케이스를 설계하는 블랙 박
※ 예: ML 알고리즘은 선형 리그레션(Linear Regression), 로지스틱 리그레션(Logistic Regression), 결정 트리 스 테스트 설계 기법
(Decision Tree), SVM, 나이브 베이즈(Naive Bayes), kNN, K-평균(K-Means), 랜덤 포레스트(Random Forest )를 포
함한다. parameterized test scenario 매개변수화된 테스트 시나리오
주어진 제약 사항에서 변경될 수 있는 하나 이상의 속성으로 정의된 테스트 시나리오
ML benchmark suite ML 벤치마크 스위트
벤치마크의 모음으로, 벤치마크는 대안(alternatives)의 성능을 비교하는 데 사용하는 일련의 테스트이다. performance metrics 성능 메트릭
분류에 사용되는 ML 모델을 평가하는 데 사용하는 메트릭
ML classification ML 분류 ※ 예: 이 메트릭은 일반적으로 정확성(accuracy), 정밀성(precision), 재현율(recall), F1-점수를 포함한다.
이산형 또는 범주형 출력 변수를 생성하는 기계 학습 함수
precision 정밀도
ML model ML 모델 분류기 평가에 사용하는 성능 지표로 정확하게 예측된 비율을 측정한다.
입력 데이터의 패턴을 사용해 예측값을 생성하는 훈련 데이터 세트로 훈련된 기계 학습 알고리즘의 결과값
probabilistic software engineering 확률적 소프트웨어 엔지니어링
ML prediction ML 예측값 퍼지(fuzzy) 및 확률 문제 해결과 관련된 소프트웨어 엔지니어링
예측한 목표 변수를 생성하는 기계 학습 함수 (machine learning function)
probabilistic system 확률적 시스템
ML regression ML 리그레션 결과를 완벽하게 예측할 수 없고 확률로 동작을 설명해야 하는 시스템
수치로 된 또는 연속 출력 변수를 생성하는 기계 학습 함수
reasoning technique 추리 기법
ML test data ML 테스트 데이터 추론(deduction) 및 유도(induction) 같은 논리 기술을 사용해 이용 가능한 정보에서 결론을 만들어 내는 AI 형태
최종 조정된 ML 모델의 편향되지 않은 평가를 제공하기위해 사용하는 독립 데이터 세트
recall 재현율
ML training data ML 훈련 데이터 분류기(classifier) 평가에 사용하는 성능 지표로, 올바르게 예측된 실제 양성 비율(proportion of actual positives)을 측
ML 모델을 훈련하는 데 사용하는 데이터 세트 정한다 (민감도라고도 함)

ML validation data ML 검증 데이터 regulatory standard 규제적 표준

ML 모델을 조정하는 동안 평가하는 데 사용하는 데이터 세트 규제 기관이 발표한 표준

narrow AI 좁은 AI reinforcement learning 강화 학습

특정 문제 해결을 위해 잘 정의된 단순한 작업에 집중하는 AI 시행 착오 과정을 이용해 목표 극대화를 위해 순차적 결정을 내리는 모델을 학습하는 작업
(약한 AI(weak AI)라고도 함) ※ 참조 1: 강화 학습 작업은 지도 학습과 유사한 방식으로 기계 학습 모델의 훈련과 AI 시스템의 작동 단계에서 수집한 분
류되지 않은 입력에 대한 훈련이 포함될 수 있다. 모델이 예측을 할 때마다 보상이 계산되고 보상 최적화를 위해 모델이 더
neuron coverage 뉴런 커버리지 정교해진다.
일련의 테스트에서 활성화된 뉴런의 수를 신경망의 총 뉴런 수(일반적으로 백분율로 표시)로 나눈 값 [ISO/IEC 23053]
※ 참조 1: 활성화 값이 0을 초과하면 뉴런이 활성화된 것으로 간주한다.
reward hacking 보상 해킹
non-deterministic system 비결정적 시스템 원래 목표를 달성하지 못하도록 보상 함수의 결과가 최대가 되도록 하는 활동
특정 입력 세트와 시작 상태가 주어져도 항상 동일한 출력 세트와 최종 상태를 생성하지 않는 시스템

090 Testing AI Guidelines ver 1.8 091 Glossary

robot 로봇 technological singularity 기술 특이점
의도한 작업 수행을 위해 주어진 환경 안에서 이동하면서 어느 정도의 자율성을 갖춘 프로그램된 구동 메커니즘 인간이 더 이상 기술 진보를 통제할 수 없는 미래의 어느 지점
(programed actuated mechanism) (‘특이점(singularity)’이라고도 함)
※ 참조 1: 로봇은 제어 시스템 및 제어 시스템 인터페이스를 포함한다.
※ 참조 2: 로봇은 용도에 따라 산업 로봇 또는 서비스 로봇으로 분류된다. tensor processing units (TPU) 텐서 프로세싱 유닛
[ISO 18646-1] 신경망 기계 학습을 위해 구글이 설계한 애플리케이션별 집적 회로(application-specific integrated circuit)

safety 안전 test oracle problem 테스트 오라클 문제

시스템이 정의된 조건 하에서 인간의 생명, 건강, 재산 및 환경에 위험을 주지 않는다는 기대
[ISO/IEC/IEEE 12207]
Safety of the Intended Functionality (SOTIF) 의도된 기능의 안전
ISO/PAS 21448: 의도된 기능의 안전
주어진 테스트 입력값과 상태에 대한 테스트 결과가 합격인지 불합격인지 판별하기 어려운 문제
threshold coverage 임계값 커버리지
일련의 테스트에서 임계 활성화값을 초과한 뉴런의 수를 신경망의 총 뉴런 수(일반적으로 백분율로 표시)로 나눈 값
※ 참조 1: 임계값으로 0과 1사이의 임계 활성값을 선택해야 한다.

search algorithm 검색 알고리즘 transparency 투명성

목표 상태(또는 구조)에 도달할 때까지 모든 가능한 상태(또는 구조)의 하위 세트를 체계적으로 방문하는 알고리즘 AI 기반 시스템의 결과 도출방법 확인이 얼마나 용이한지 측정한 것
(설명가능성(explainability) 이라고도 함)
search based software engineering 검색 기반 소프트웨어 엔지니어링
유전 알고리즘 및 모의 담금질(simulated annealing)과 같은 검색 기술을 적용해 문제를 해결하는 소프트웨어 엔지니어링 true negative 참 음성
테스팅 실패(failure) 시 실패에 대한 정확한 보고
self-learning system 자가학습 시스템 ※ 예: 심판이 오프사이드를 정확하게 판정함
시행 착오를 통한 학습을 기반으로 행동을 변화시키는 적응 시스템
true positive 참 양성
sign change coverage 기호 변경 커버리지 테스팅 합격(pass) 시 합격에 대한 정확한 보고
일련의 테스트에서 양성과 음성 활성값 모두로 활성화된 뉴런의 수를 신경망에서의 뉴런의 총 수(일반적으로 백분율로 표시) ※ 예: 심판이 골을 정확하게 판정함
로 나눈 값
※ 참조 1: 활성값이 0이면 음의 활성값으로 간주된다. Turing test 튜링 테스트
인간 행동과 구별할 수 없는 지적 행동을 보이는 기계의 능력을 테스트하는 것
sign-sign coverage 기호-기호 커버리지
다음 레이어에서 뉴런 하나만의 상태만 변하고 나머지 모든 다른 뉴런은 똑같이 유지(즉 기호를 변경하지 않음)하도록 개별 underfitting 과소적합
뉴런의 상태를 모두 바꿨을 때 달성하는 커버리지 수준 훈련 데이터의 본질적 경향이 반영되지 않은 ML 모델 생성으로 정확한 예측이 어려운 모델을 초래하는 것

simulator 시뮬레이터 unsupervised learning 비지도 학습

테스트 중에 사용되는 장치, 컴퓨터 프로그램 또는 시스템으로, 통제된 일련의 입력이 제공되면 주어진 시스템처럼 동작하거 라벨이 없는 입력 데이터를 비슷한 군집에 매핑하는 함수를 학습하는 작업
나 작업을 수행 [ISO/IEC 23053]

software agent 소프트웨어 에이전트 value change coverage 값 변경 커버리지

환경을 인식해 성공적인 목표 달성을 위한 기회를 극대화하는 방법을 찾는 디지털 독립체 일련의 테스트에서 활성값이 변화폭 이상으로 바뀌었을 때 활성화되는 뉴런 수를 신경망의 총 뉴런 수(일반적으로 백분율로
표시)로 나눈 값
supervised learning 지도 학습
규정된 예제 입력-출력 쌍을 기반으로 입력을 출력에 매핑하는 함수를 학습하는 작업 virtual test environment 가상 테스트 환경
[ISO/IEC 23053] 하나 이상의 부분이 디지털로 시뮬레이션되는 테스트 환경

092 Testing AI Guidelines ver 1.8 093 Glossary

References 참고문헌
A
A/B 2019 Wikipedia contributors, "A/B testing," Wikipedia,
https://en.wikipedia.org/w/index.php?title=A/B_testing&oldid=926805728
(accessed November 21, 2019).
AI Effect 2019 Wikipedia contributors, "AI effect," Wikipedia,
https://en.wikipedia.org/w/index.php?title=AI_effect&oldid=920651009
(accessed November 20, 2019).
AI Index 2017 "The AI Index 2017 Annual Report”, AI Index Steering Committee, https://driverless-futures.com/2019/03/18/who-killed-elaine-herzberg-one-year-on-from-the-
Human-Centered AI Initiative, Stanford University, Stanford, CA, December 2017.
AIBias 2019 Salkever et al, A.I. Bias Isn’t the Problem. Our Society Is, Fortune.com,
https://fortune.com/2019/04/14/ai-artificial-intelligence-bias/, accessed Nov 2019.
B
Banks 2019 Banks et al, Requirements Assurance in Machine Learning,
Proceedings of the AAAI Workshop on Artificial Intelligence Safety 2019, Jan 2019.
BBC 2018 Chinese AI caught out by face in bus ad, BBC Technology News,
https://www.bbc.com/news/technology-46357004, Nov 2018.
Bionic 2019 Chris Wiltz, Can Apple Use Its Latest AI Chip for More Than Photos?,
Electronics & Test, Artificial Intelligence,
https://www.designnews.com/electronics-test/can-apple-use-its-latest-ai-chip-more-
photos/153617253461497, Sep 2019.
Bojarski 2016 Bojarski et al, End to End Learning for Self-Driving Cars, arXiv.org, arXiv:1604.07316,
accessed Nov 2019, Apr 2016.
C Facebook 2019 A tool to detect bugs in Java and C/C++/Objective-C code before it ships,
Chen 2018 Chen et al, Metamorphic Testing: A Review of Challenges and Opportunities,
ACM Comput. Surv. 51, 1, Article 4, January 2018.
CloudTPU 2019 Cloud TPU, https://cloud.google.com/tpu/, accessed Nov 2019.
Confusion 2019 Wikipedia contributors, "Confusion matrix," Wikipedia,
https://en.wikipedia.org/w/index.php?title=Confusion_matrix&oldid=922488584
(accessed November 21, 2019).
D
DAWN 2019 Stanford DAWN Deep Learning Benchmark, Website:
https://dawn.cs.stanford.edu/benchmark/, accessed Nov 2019.
094 Testing AI Guidelines ver 1.8
DeepCover 2018 Sun et al, Testing Deep Neural Networks,
https://www.researchgate.net/publication/323747173_Testing_Deep_Neural_Networks,
accessed Nov 2019, Mar 2018.
DeepTest 2018 Tian et al, DeepTest: Automated Testing of Deep-Neural-Network-driven Autonomous Cars,
ICSE ’18: 40th International Conference on Software Engineering, May 2018.
DeepXplore 2017 Pei et al, DeepXplore: Automated Whitebox Testing of Deep Learning Systems,
Proceedings of ACM Symposium on Operating Systems Principles (SOSP ’17), Jan 2017.
DF 2019 Stilgoe , Who killed Elaine Herzberg? One year on from the Uber crash, Driverless Futures?,
uber-crash/, Mar 2019.
Drive 2019 NVIDIA DRIVE CONSTELLATION - Virtual Reality Autonomous Vehicle Simulator,
NVIDIA Products, https://www.nvidia.com/en-us/self-driving-cars/drive-constellation/,
accessed Nov 2019.
E
Edelman 2019 2019 Edelman AI Survey Results Report, Edelman Digital,
https://www.digitalmarketingcommunity.com/researches/edelman-artificial-intelligence-survey-
results-report-2019/ (accessed Nov 20, 2019).
EdgeTPU 2019 Edge TPU, https://cloud.google.com/edge-tpu/, accessed Nov 2019.
Ethics 2019 European Commission High-Level Expert Group on Artificial Intelligence,
Ethics Guidelines for Trustworthy AI, European Commission, April 2019.
EVOSUITE 2019 EVOSUITE - Automatic Test Suite Generation for Java,
http://www.evosuite.org/, accessed Nov 2019.
F
https://fbinfer.com/, accessed Nov 2019.
Forbes 2016 Leetaru, How Twitter Corrupted Microsoft's Tay:
A Crash Course In the Dangers Of AI In The Real World,
https://www.forbes.com/sites/kalevleetaru/2016/03/24/how-twitter-corrupted-microsofts-tay-a-
crash-course-in-the-dangers-of-ai-in-the-real-world/#202233ae26d2, Mar 2016.
Fraser 2015 Fraser et al, Does Automated Unit Test Generation Really Help Software Testers?
A Controlled Empirical Study, ACM Transactions on Software Engineering and Methodology,
Volume 24 Issue 4, August 2015.
Frenay 2014 Frenay et al, Classification in the Presence of Label Noise: A Survey, IEEE Transactions on Neural
Networks and Learning Systems, May 2014.
095 References
G
Gottlieb 2016 Gottlieb et al, Automated regression testing using constraint programming,
AAAI'16 Proceedings of the Thirtieth AAAI Conference on Artificial Intelligence, Feb 2016.
Grace 2017 Grace et al, When Will AI Exceed Human Performance? Evidence from AI Experts,
Kirin 2017 HUAWEI Reveals the Future of Mobile AI at IFA 2017, Huawei Press Release,
https://consumer.huawei.com/en/press/news/2017/ifa2017-kirin970/, Sep 2017.
Kuhn 2004 Kuhn et al, Software Fault Interactions and Implications for Software Testing,
IEEE Transactions on Software Engineering 30(6):418 - 421, July 2004.

L
arXiv e-print, https://arxiv.org/abs/1705.08807, May 2017.

H
Habitat 2019 Savva et al, Open-sourcing AI Habitat, an advanced simulation platform for embodied AI research,
https://ai.facebook.com/blog/open-sourcing-ai-habitat-an-simulation-platform-for-embodied-ai-
research/, accessed Nov 2019, June 2019.
Hall 2012 Hall et al, A systematic literature review on fault prediction performance in software engineering",
Software Engineering, IEEE Transactions on, vol. 38, 2012.
Lakhotia 2012 Lakhotia et al, AUSTIN: A tool for Search Based Software Testing for the C Language and its
Evaluation on Deployed Automotive Systems, 2nd International Symposium on Search Based
Software Engineering, 2010.
Liu 2014 Liu et al, How effectively does metamorphic testing alleviate the oracle problem?,
IEEE Transactions on Software Engineering 40, 1, 4-22, 2014.
LogiGear 2018 Hackett, 2018 Trends Survey Results,
https://www.logigear.com/magazine/survey/2018-trends-survey-results/, accessed Nov 2019.

M
Harman 2016 Harman, The Role of Artificial Intelligence in Software Engineering, In First International Workshop
on Realizing AI Synergies in Software Engineering (RAISE), pp. 1-6. IEEE, June 2012.
Harvard 2018 Agrawal et al, “Prediction Machines: The Simple Economics of Artificial Intelligence”,
Machiry 2013 Machiry et al, Dynodroid: an input generation system for Android apps,
Harvard Business Review Press, 2018
Proceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering, Aug 2013.
History 2019 Wikipedia contributors, "History of artificial intelligence", Wikipedia,
Mao 2016 Mao et al, Sapienz: multi-objective automated testing for Android applications,
https://en.wikipedia.org/w/index.php?title=History_of_artificial_intelligence&oldid=926947877
Proceedings of the 25th International Symposium on Software Testing and Analysis, July 2016.
(accessed November 20, 2019).
MLPerf 2019 ML Training Benchmarks, Website: https://mlperf.org/, accessed Nov 2019.
Henderson 2018 Henderson et al, Deep reinforcement learning that matters,
Monkey 2019 UI/Application Exerciser Monkey, Android Studio User Guide,
Thirty-Second AAAI Conference on Artificial Intelligence, 2018.
https://developer.android.com/studio/test/monkey, accessed Nov 2019.
HPC 2018 Russel, Phase Change Memory Shows Promise for AI Use Says IBM, HPC Wire,
Moral 2018 Awad et al, The Moral Machine experiment, Nature, 563, pages 59-64, 2018.
https://www.hpcwire.com/2018/10/24/phase-change-memory-shows-promise-for-ai-use-says-
Morse 2019 Official documentation for the MORSE project,
ibm/, Oct 2018.
http://www.openrobots.org/morse/doc/0.2.1/morse.html, accessed Nov 2019.

I
Myriad 2019 Intel® Movidius™ Myriad™ VPU 2: A Class-Defining Processor,
https://www.movidius.com/myriad2, accessed Nov 2019.

IEEE 2019 Strickland, How IBM Watson Overpromised and Underdelivered on AI Health Care,
N
IEEE Spectrum, April 2019.
Nagappan 2008 Nagappan et al, The Influence of Organizational Structure on Software Quality:
IFR 2018 Robot density rises globally, IFR Press Release, https://ifr.org/ifr-press-releases/news/robot-
An Empirical Case Study, Proceedings of the 30th international conference on Software engineering
density-rises-globally, Feb 2018.
(ICSE’08), May 2008.
IntelliTest 2015 How to: Generate unit tests by using IntelliTest, https://docs.microsoft.com/en-us/visualstudio/
Nervana 2019 Intel® Nervana™ Neural Network processors deliver the scale and efficiency demanded by deep
test/generate-unit-tests-for-your-code-with-intellitest?view=vs-2019, accessed Nov 2019.
learning model evolution, https://www.intel.ai/nervana-nnp/, accessed Nov 2019.
ISTQB 2018 ISTQB® Worldwide Software Testing Practices Report 2017-18 (Revised), ISTQB,
Nokia 2019 Nokia's revolutionary 5G virtual testing speeds deployment, Press Release,
https://www.istqb.org/references/surveys/istqb%C2%AE-worldwide-software-testing-practices-
https://www.globenewswire.com/news-release/2019/04/23/1807667/0/en/
survey-2017-18.html, October 2018.
Nokia-s-revolutionary-5G-virtual-testing-speeds-deployment.html, accessed Nov 2019, April

K
2019.
NS 2018 Cossins, Discriminating algorithms: 5 times AI showed prejudice, NewScientist,
https://www.newscientist.com/article/2166207-discriminating-algorithms-5-times-ai-showed-
Keevers 2019 Keevers, Cross-validation is insufficient for model validation, Technical Report, prejudice/ , April 2018.
Australian Defence Science and Technology Group, Mar 2019.
Kim 2007 Kim et al, Predicting Faults from Cached History, 29th International Conference on Software
Engineering (ICSE’07), 2007.

096 Testing AI Guidelines ver 1.8 097 References

O
TS 2019 Wikipedia contributors, "Technological singularity," Wikipedia,
https://en.wikipedia.org/w/index.php?title=Technological_singularity&oldid=925266609
OAEI 2019 Ontology Alignment Evaluation Initiative, Website: (accessed November 20, 2019).
http://oaei.ontologymatching.org/, accessed Nov 2019. Turing 1950 Turing, Computing Machinery and Intelligence, Mind 49: 433-460, 1950.

P V
Püschel 2018 Püschel, Testing Self-Adaptive Systems - A Model-based Approach to Resilience, Volta 2019 NVIDIA VOLTA, https://www.nvidia.com/en-us/data-center/volta-gpu-architecture/,
Dissertation, Technischen Universität Dresden, June 2018.

accessed Nov 2019.

Q W
Qiu 2019 Qiu et al, Review of Artificial Intelligence Adversarial Attack and Defense Technologies, WP 2015 Carpenter, Google’s algorithm shows prestigious job ads to men, but not to women.
Applied Sciences 9(5):909, Mar 2019. Here’s why that should worry you., Washington Post, https://www.washingtonpost.com/news/
QM4MAS 2016 Marir et al, QM4MAS: a quality model for multi-agent systems, Int. J. Computer the-intersect/wp/2015/07/06/googles-algorithm-shows-prestigious-job-ads-to-men-but-not-
Applications in Technology, 2016, 54. to-women-heres-why-that-should-worry-you/ , July 2015.

R
WQR 2019 World Quality Report, 10th Edition, Gap Gemini, https://www.sogeti.com/explore/reports/world-
quality-report-201819/, Sep 2018.

X
Rai 2014 Rai et al, Regression Test Case Optimization Using Honey Bee Mating Optimization Algorithm with
Fuzzy Rule Base, World Applied Sciences Journal 31 (4): 654-662, 2014.
Raj 2019 Raj, Metrics for NLG evaluation, Medium.com, https://medium.com/explorations-in-language-and- XAI 2019 Wikipedia contributors, "Explainable artificial intelligence," Wikipedia,
learning/metrics-for-nlg-evaluation-c89b6a781054 , accessed Nov 2019. https://en.wikipedia.org/w/index.php?title=Explainable_artificial_intelligence&oldid=924090418
RELAX 2010 Whittle et al, RELAX: A language to address uncertainty in self-adaptive systems requirement, (accessed November 20, 2019).
Requirements Engineering, June 2010.
Reuters 2017 Shepardson, Tesla driver in fatal 'Autopilot' crash got numerous warnings: U.S. government, 25010 2011 ISO/IEC 25010:2011, Systems and software engineering - Systems and software Quality
https://www.reuters.com/article/us-tesla-crash/tesla-driver-in-fatal-autopilot-crash-got- Requirements and Evaluation (SQuaRE) - System and software quality models, 2011.
numerous-warnings-u-s-government-idUSKBN19A2XC, June 2017. 29119-4 2015 ISO/IEC/IEEE 29119-4, Software and systems engineering - Software testing - Part 4:
Robot 2019 Wikipedia contributors, "Robot," Wikipedia, https://en.wikipedia.org/w/index. Test techniques, ISO, 2015.
php?title=Robot&oldid=926707635 (accessed November 20, 2019).
Russell 2019 Russell, Of Myths and Moonshine, contribution to the conversation on The Myth of AI,
https://www.edge.org/conversation/jaron_lanier-the-myth-of-ai, accessed Nov 2019.

S
Segura 2016 Segura et al, A Survey on Metamorphic Testing, IEEE Trans. on Software Engineering,
Vol 42, No. 9, Sept 2016.
SoTR 2019 State of Testing Report 2019, version 1.3, PractiTest, https://qablog.practitest.com/
state-of-testing/, July 2019.
Statista 2019 In-depth: Artificial Intelligence 2019, Statista Report 2019,
https://people.stfx.ca/x2011/x2011aqi/School/2018-2019/Winter/BSAD%20471%20-%20Strat/
Case/AI%20statista.pdf, February 2019.

T
Tosun 2010 Tosun et al, AI-Based Software Defect Predictors: Applications and Benefits in a Case Study,
Proceedings of the Twenty-Second Innovative Applications of Artificial Intelligence Conference
(IAAI-10), 2010.

098 Testing AI Guidelines ver 1.8 099 References

연구진

김원희 부산정보산업진흥원

안형준 부산정보산업진흥원

최유진 부산정보산업진흥원

이창석 경남테크노파크

김중한 경남테크노파크

전영준 부산IT융합부품연구소

김수욱 부산IT융합부품연구소

김장주 부산IT융합부품연구소

강지수 부산IT융합부품연구소

권선이 (사)KSTQB

천호정 (사)KSTQB

권원일 (주)STA테스팅컨설팅

박창환 (주)STA테스팅컨설팅

최영재 (주)STA테스팅컨설팅

스튜어트 리드(Stuart Reid) (주)STA테스팅컨설팅

췬 류(Qin Liu) 통지대학교 중국(상하이)

100 Testing AI Guidelines ver 1.8 101 연구진