IT/모바일
머신러닝 시스템을 설계하고 구현하는 동안 피해를 최소화하려고 열심히 노력했다 해도, 우리는 여전히 장애와 공격에 대비해야 한다. 이때 필요한 것이 바로 조직 프로세스다. 머신러닝 시스템이 안전하고 성능을 보장하는 데 중요한 역할을 하는 조직 프로세스는 머신러닝 시스템의 신뢰성을 결정하는 비기술적인 핵심 요소다.
이번 글에서는 실무자가 머신러닝 시스템의 예측 가능한 모든 장애 유형을 고려해 기록하고, 이를 완화하기 위한 머신러닝 모델 관리에서 사용하는 다양한 프로세스를 간략히 설명하고자 한다.
1. 장애 유형 예측하기
머신러닝 안전 및 윤리 전문가들은 머신러닝 시스템에서 예측할 수 있는 장애 유형을 고려하고, 기록하고, 완화하려는 시도가 중요하다고 한다. 대부분의 전문가들은 이러한 작업이 쉽지 않다는 점에도 대부분 동의한다. 다행스럽게도 최근 몇 년간 이 주제에 관한 새로운 자원과 학문이 등장해 머신러닝 시스템 설계자가 더 체계적인 방식으로 사고를 예측하는 데 도움을 주었다. 잠재적인 장애의 전체 범주를 파악할 수 있다면, 머신러닝 시스템을 강화해서 실제 성능과 안전을 개선하는 작업을 더 적극적이고 효율적으로 할 수 있다. 다음에서는 이러한 전략 중 하나와 머신러닝 시스템의 미래 사고에 관한 브레인스토밍을 하는 몇 가지 추가 프로세스를 설명한다.
1) 과거의 알려진 장애 사례
과거에 실패했던 설계와 현재 시스템을 비교하는 것은 머신러닝 시스템의 잠재적 인공지능 사고를 완화하는 효과적인 방법이다. (참고 논문)
교통 전문가들이 사고를 조사하고 목록화한 뒤 그 결과를 사용해 관련 사고를 예방하고 새로운 기술을 테스트하듯이, 반복되는 관련 장애를 예방하기 위해 여러 머신러신 관계자들은 인공지능 사고를 수집하고 분석하기 시작했다. 가장 유명한 인공지능 사고 저장소는 인공지능 사고 데이터베이스 AI Incident Database다.
이 검색 가능한 상호대화형 데이터베이스에서 등록된 사용자는 키워드를 사용해 데이터베이스를 시각적으로 검색하고 공개적으로 기록된 사고에 관한 다양한 정보를 찾을 수 있다. 이러한 자원을 참고해 머신러닝 시스템을 개발해야 한다. 현재 설계하거나 구현하거나 배포 중인 시스템과 비슷한 시스템에서 사고가 발생했다면, 이는 새로운 시스템에서 사고가 발생할 가능성이 크다는 매우 강력한 지표가 될 것이다. 인공지능 사고 데이터베이스에서 익숙한 것을 발견했다면 작업을 중단하고 지금 무엇을 하고 있는지 더 신중하게 생각해야 한다.
2) 상상력의 부재
맥락과 세부 사항을 고려해 미래를 상상하기란 절대 쉬운 일이 아니다. 그리고 때로는 머신러닝 시스템이 예측할 수 없거나 알 수 없는 세부 사항으로 운영될 때 인공지능 사고로 이어지기도 한다. 논문 「인공지능이 적용된 시스템 개발 및 배포에서 상상력의 부재 극복하기」의 저자는 상상하기 어려운 미래 위험에 관한 가설을 세우는 몇 가지 구조적인 접근 방식을 제시했다.
시스템 설계자는 인공지능 사고에서 누가, 무엇을, 언제, 어떻게 외에도 다음 사항들을 고려해야 한다.
• 시스템의 영향이 유익하다는 가정 (그리고 시스템 영향의 불확실성이 존재할 때 이를 인정하기)
• 수학과 기술만이 아닌 시스템의 문제 영역 problem domain과 적용 사용사례 applied use case
• 예상치 못했거나 놀라운 결과, 사용자 상호작용, 시스템에 대한 반응
인공지능 사고는 조직에 있어 정말 당혹스러운 일이다. 물론 소비자와 일반 대중에게도 피해를 줄 수 있다. 하지만 약간의 선견지명만 있었다면 현재 알려진 인공지능 사고 중 상당수는 완화할 수 있었다. 또한 머신러닝 실패를 연구하고 개념화하는 과정에서 설계나 시스템을 완전히 재작업해야 함을 발견할 수도 있다. 이럴 때는 결함 있는 시스템을 출시했을 때 조직이나 대중이 겪을 피해보다 시스템 구현이나 배포 과정의 지연으로 발생하는 비용이 더 적게 든다는 사실에 위안을 삼아야 한다.
2. 모델 위험관리 프로세스
모델 위험관리 프로세스 측면에서는 시스템 모델링을 자세히 기록하고, 시스템에 대한 인적 검토와 지속적인 모니터링이 필요하다. 이러한 프로세스는 중요한 소비자 금융 애플리케이션에 배포된 예측모델에 대한 연방준비제도이사회 및 통화감독국이 감독하는 연방준비제도이사회의 SR 문서 11-7의 모델 위험관리 지침의 거버넌스 부담 대부분을 차지한다. 조직이 크지 않으면 모델 위험관리 지침 전체를 완벽하게 수용하기 어려울 수 있지만, 진지한 머신러닝 실무자라면 이 지침에서 무언가를 배울 수 있을 것이다. 이번에는 여러분이 조직에서 모델 위험관리의 여러 측면을 사용할 수 있도록 모델 위험관리 프로세스를 더 작은 구성요소로 나누고자 한다.
1) 위험 계층화
머신러닝 시스템 배포의 위험을 평가하는 데는 피해 발생 확률과 그 피해에서 오는 예상 손실을 곱하는 방법을 일반적으로 사용한다. 모델 위험관리 맥락에서 위험과 손실의 곱을 중요도라고 한다. 중요도는 조직이 현실적으로 머신러닝 시스템의 위험 수준을 결정할 수 있도록 하는 강력한 개념이다. 더 중요한 것은 이러한 위험 계층화로 제한된 개발과 검증, 감사 자원을 효율적으로 사용할 수 있다는 점이다.
물론 중요도가 가장 높은 애플리케이션은 사람의 관심과 검토를 가장 많이 받아야 하며, 중요도가 가장 낮은 애플리케이션은 자동화된 머신러닝 AutoML, Automatic Machine Learning 시스템이 처리하고 최소한으로만 검증하면 된다. 머신러닝 시스템의 위험완화는 지속적이며 비용이 많이 드는 작업이므로, 효과적인 거버넌스를 위해 고위험, 중위험, 저위험 시스템에 적절하게 자원을 할당해야 한다.
2) 모델 기록문서
모델 위험관리 표준은 시스템에 관한 자세한 문서를 요구한다.
첫째, 문서를 통해 시스템 이해관계자는 책임 있게 지속해서 시스템을 유지,보수하고 사고에 대응할 수 있어야 한다.
둘째, 감사 및 검토 프로세스가 효율적이게 시스템 전반에 걸쳐 문서를 표준화해야 한다.
문서는 규정 준수의 첫걸음이다. 다음에 제시할 고수준 문서 템플릿 목록은 데이터과학자와 엔지니어가 표준화된 워크플로를 진행하거나 모델 개발의 후반 단계에서 작성해야 할 문서다. 문서 템플릿에는 책임 있는 실무자가 올바른 모델을 구축하려면 수행해야 할 모든 단계를 포함해야 한다. 문서의 일부가 작성되지 않았다면 학습 과정이 부실함을 의미한다. 대부분의 문서 템플릿과 프레임워크에서 최종 모델 문서에 이름과 정보를 적도록 해 자신의 역할을 다하지 않은 사람이 누구인지 알 수 있어야 한다.
특히 중요도가 높은 시스템이라면 이러한 문서의 분량이 수백 쪽에 달할 수 있다. 제안된 데이터시트와 모델 카드 표준은 소규모 또는 신생 조직이 이러한 목표를 달성하는 데 도움이 된다. 현재 조직에서 긴 모델 문서를 작성하기가 어려운 상황이라면 간단한 프레임워크가 적합할 수 있다.
3) 모델 모니터링
머신러닝 안전의 기본 전제는 실제 환경에서 머신러닝 시스템의 성능을 예측하기 어려운 만큼 성능을 모니터링해야 한다는 것이다. 따라서 배포된 시스템이 폐기될 때까지 성능을 자주 모니터링해야 한다. 여러 가지 문제 조건에 대해 시스템을 모니터링할 수 있으며, 가장 일반적인 조건은 머신러닝 모델의 입력 분포가 시간이 지남에 따라 변화하는 입력 변동이다.
머신러닝 시스템의 학습 데이터는 시스템의 운영 환경 정보를 정적 스냅샷으로 인코딩하지만, 세상은 전혀 정적이지 않다. 경쟁 업체가 시장에 진입하거나 새로운 규제가 공표되거나 소비자의 취향이 바뀔 수 있으며 전염병이나 다른 재난이 발생할 수 있다. 이러한 모든 상황 때문에 머신러닝 시스템에 입력되는 라이브 데이터가 학습 데이터의 특성과 다르게 변경되어 시스템의 성능이 떨어지거나 위험해질 수 있다.
이러한 돌발상황을 막기 위해 최고의 머신러닝 시스템은 입력 및 출력 분포의 변동과 모델의 성능이 저하되는 모델 붕괴라고 하는 품질 저하를 모두 모니터링한다. 성능 품질이 가장 일반적인 모니터링 대상이지만, 머신러닝 시스템에 대한 비정상 입력이나 예측, 특정 공격 및 해킹, 변동하는 공정성 특성도 모니터링할 수 있다.
4) 모델 인벤토리
머신러닝 시스템을 배포하는 모든 조직은 다음과 같은 간단한 질문에 답할 수 있어야 한다.
이러한 모델 인벤토리를 사용해 모델 위험관리의 목표를 달성할 수 있다. 모델 인벤토리는 조직의 모든 머신러닝 시스템을 정리한 최신 데이터베이스다. 모델 인벤토리는 문서 작성에 필요한 중요한 정보가 들어 있는 저장소 역할을 할 수 있지만, 모니터링 계획 및 결과, 감사 계획 및 결과, 중요한 과거 및 향후의 시스템 유지보수와 변경, 사고대응 계획과도 연결되어야 한다.
5) 시스템 검증 및 프로세스 감사
전통적인 모델 위험관리 관행에 따르면 머신러닝 시스템을 출시하기 전에 두 가지를 검토해야 한다. 첫 번째 검토는 시스템의 기술적 검증으로, 박사급 데이터과학자를 포함한 숙련된 검증자가 시스템 설계 및 구현의 취약점을 찾아내고 시스템 개발자와 협력해 발견한 문제를 해결한다. 두 번째 검토에서는 프로세스를 조사한다. 감사 및 규정 준수 담당자는 문서와 향후 계획에 맞춰 시스템 설계, 개발, 배포를 면밀히 분석해 모든 규제와 내부 프로세스 요구사항을 만족하는지 확인한다. 또한 머신러닝 시스템은 시간이 지나면서 변화하고 변동하므로 시스템이 업데이트될 때마다 또는 합의된 향후 주기에 따라 검토해야 한다.
여러분의 조직에는 이러한 광범위한 검토를 수행할 수 있는 자원이 없다고 생각할 수도 있다. 당연히 소규모 또는 신생 조직이라면 그럴 수 있다. 하지만 검증 및 감사는 대부분의 조직에서 수행할 수 있다. 검증 및 감사의 핵심은 시스템을 개발하지 않은 기술자가 시스템을 테스트하고, 내외부 의무 사항을 기술적이지 않은 방식으로 검토하는 기능을 갖추고, 중요한 머신러닝 시스템 배포를 승인하고 감독하는 것이다.
6) 변경 관리
머신러닝 시스템은 다양한 요소로 구성되는 경우가 많다. 백엔드 머신러닝 코드부터 응용 프로그래밍 인터페이스 API, Application Programming Interface와 그래픽 사용자 인터페이스GUI, Graphic User Interface에 이르기까지 시스템의 구성 요소를 변경하면 다른 요소에 부작용을 일으킬 수 있다. 데이터 변동과 새로운 데이터 프라이버시 및 차별 금지 규정, 타사 소프트웨어에 대한 복잡한 종속성 등의 문제까지 더해지면 머신러닝 시스템의 변경 관리는 심각한 문제가 될 수 있다.
업무 수행에 필수인 머신러닝 시스템을 계획하거나 설계한다면 변경 관리를 최우선 프로세스 통제로 만들어야 한다. 명시적인 변경 관리 계획과 자원이 없다면, 동의 없이 데이터를 사용하거나 API 불일치 등 시스템이 발전하는 과정에서 발생하는 프로세스나 기술적 실수를 방지하기가 매우 어려워진다. 더구나 변경 관리가 없다면 이러한 문제는 사고가 발생할 때까지 감지되지 않을 수 있다.
3. 모델 위험관리 그 이상
재무 감사와 데이터 프라이버시, 소프트웨어 개발 모범사례 및 IT 보안에서 배울 수 있는 머신러닝 위험관리의 교훈은 많다. 이번에는 기존 모델 위험관리 범위에 포함되지 않은 아이디어를 머신러닝 안전 및 성능 관점에서 알아본다.
1) 모델 감사 및 평가
모델 감사는 특정 정책, 규정, 법률의 준수 여부를 추적하는 머신러닝 시스템에 초점을 맞춘 공식적인 테스트 및 투명성 활동이다. 감사자와 감사 대상 조직 간의 상호작용이 제한된 제삼자가 수행한다.
머신러닝 감사 및 평가는 편향 문제나 안전, 데이터 프라이버시 피해, 보안 취약성 등 기타 심각한 위험에 초점을 맞출 수 있다. 어디에 초점을 맞추더라도 감사와 감사자는 공정하고 투명해야 한다. 감사자는 명확한 윤리적 또는 전문적 기준에 따라 감사를 수행해야 하지만, 이런 기준은 2023년 현재 거의 존재하지 않는다. 이러한 책임 메커니즘이나 구속력이 있는 지침이 없다면 감사는 효율적인 위험관리 관행이 될 수 없으며, 더 나아가 유해한 머신러닝 시스템을 인증하는 기술 세탁이 될 수 있다. 결함이 있더라도 위험관리를 위한 감사는 정책 입안자와 연구자가 선호하는 위험관리 전술로, 뉴욕시 지방법 144조와 같이 법률로 규정된다.
2) 영향 평가
영향 평가 impact assessment는 머신러닝 시스템 구현 후 발생할 수 있는 잠재적 문제를 예측, 기록하는 공식 문서 접근 방식이다. 데이터 프라이버시 분야에서 시작되어 조직의 머신러닝 정책과 법률에 등장하기 시작했다. 영향 평가는 머신러닝 시스템의 위험을 고려하고 문서로 남기도록 하여 인공지능 시스템의 설계자와 운영자의 책임감을 높여준다. 그러나 영향 평가만으로는 충분하지 않다. 영향은 위험의 한 요소일 뿐이며, 가능도와 결합해 위험 측도를 만들고, 위험도가 가장 높은 애플리케이션을 중점적으로 감독하는 방식으로 위험을 완화해야 한다. 영향 평가는 광범위한 위험관리 프로세스의 시작에 불과하다.
다른 위험관리 프로세스와 마찬가지로, 평가 대상 시스템에 맞춰 적절한 주기로 영향 평가를 수행해야 한다. 또한 평가 대상 팀이 아닌 독립적 전문가가 영향 평가를 수행해야 객관성을 유지할 수 있다.
3) 이의 제기, 재정의, 옵트아웃
사용자나 운영자가 피할 수 없는 잘못된 결정에 이의를 제기하고 재정의할 방법을 대부분의 머신러닝 시스템에 내장해야 한다. 이를 가리키는 용어는 실행 가능한 구제 조치(기술을 이용해 부정적인 이미지나 문제를 숨기려는 행위), 개입 가능성, 보상, 부당한 조치 통지 등이 다양하게 사용된다. 구글 검색창의 ‘부적절한 예상 검색어 신고’ 기능처럼 단순할 수도 있고, 사용자에게 데이터와 설명을 제시하고 명백히 잘못된 데이터 포인트나 결정 메커니즘에 대한 이의 제기 프로세스를 활성화하는 것처럼 정교할 수도 있다.
옵트아웃이라고 하는 또 다른 비슷한 접근방식은 사용자가 자동화된 처리를 거치지 않고 기존 방식으로 조직과 비즈니스를 수행할 수 있도록 한다. 많은 데이터 프라이버시 법과 주요 미국의 주요 소비자금융법은 구제 조치나 옵트아웃을 다룬다. 많은 사용자에게 잘못된 결정을 자동으로 강요하는 것은 머신러닝에서 명백한 윤리적 잘못이다. 너무나 명확하고 잘 알려진 윤리적, 법적, 평판상의 함정에 빠져서는 안 되지만, 많은 시스템이 이러한 함정에 빠진다. 이는 머신러닝 시스템을 설계할 때부터 이의 제기와 재정의, 옵트아웃을 제대로 수행하려면 프로세스와 기술 모두에 대한 계획과 자원이 필요하기 때문일 것이다.
4) 페어 프로그래밍 및 이중 프로그래밍
머신러닝 알고리즘은 복잡하고 확률적이므로 주어진 머신러닝 알고리즘 구현이 정확한지 알기 어렵다. 이러한 이유로 일부 선도적인 머신러닝 조직에서는 품질보증(QA) 메커니즘으로 머신러닝 알고리즘을 두 번 구현한다. 이는 일반적으로 페어 프로그래밍이나 이중 프로그래밍 방식으로 이루어진다.
페어 프로그래밍 방식에서는 두 명의 기술 전문가가 협업 없이 알고리즘을 코딩한다. 그런 다음 두 전문가가 서로의 결과를 비교하여 두 구현의 차이점을 파악하고 문제를 해결한다. 이중 프로그래밍 방식에서는 한 명의 실무자가 같은 알고리즘을 두 번 구현하지만, 객체지향 언어인 파이썬이나 절차적 언어인 SAS와 같이 전혀 다른 프로그래밍 언어로 구현한다. 그런 다음 두 구현 결과의 차이점을 조정한다. 두 가지 접근방식 모두 시스템을 배포할 때까지 발견되지 않았을 수많은 버그를 발견할 수 있다.
페어 프로그래밍과 이중 프로그래밍은 데이터과학자가 알고리즘의 시제품을 제작하는 동안 전담 엔지니어가 배포를 위해 알고리즘을 강화하는 표준 워크플로와 일치할 수 있다. 그러나 이 방식이 제대로 작동하려면 엔지니어는 데이터과학 시제품에 자유롭게 도전하고 테스트할 수 있어야 하며, 단순히 시제품을 다시 코딩하는 역할에 그쳐서는 안 된다.
5) 모델 배포를 위한 보안 권한
IT 보안의 최소 권한은 시스템 사용자가 필요 이상의 권한을 가져서는 안 된다는 개념이다.
최소 권한은 기본적인 프로세스 통제이지만, 다른 많은 IT 시스템과 연결되는 머신러닝 시스템에서는 머신러닝 개발 과정 편의상 ‘실력 있는’ 데이터과학자들이 이 원칙을 간과하기 쉽다. 안타깝게도 이는 머신러닝 안전과 성능에 반하는 패턴이다. 과대포장된 머신러닝과 데이터과학 세계가 아닌 일반적인 소프트웨어 개발 관행에서 엔지니어는 자신이 작성한 코드에 너무 익숙해서 테스트에서 간과하는 부분이 생길 수 있으며, 모든 경우의 수를 테스트하기란 불가능하므로 자신의 코드를 충분히 테스트할 수 없다.
따라서 엔지니어는 코드 작성에는 특화되었지만, 제품 전체를 보는 시각이 부족할 수 있으므로 제품 조직의 다른 사람이 소프트웨어 출시 시점을 결정해야 한다.
6) 버그 바운티
버그 바운티는 컴퓨터 보안에서 차용할 수 있는 또 다른 개념이다. 전통적인 버그 바운티는 소프트웨어의 문제, 특히 보안 취약점을 발견하면 조직이 보상을 제공하는 것을 말한다. 머신러닝은 대부분 소프트웨어에 불과하므로 머신러닝 시스템에 버그 바운티를 실시할 수 있다. 버그 바운티를 사용해 머신러닝 시스템에서 보안 문제를 찾을 수 있을 뿐만 아니라 신뢰성이나 안전성, 투명성, 설명 가능성, 해석 가능성, 프라이버시와 관련한 다른 유형의 문제를 찾는 데도 사용할 수 있다.
버그 바운티는 표준화된 프로세스에 따라 커뮤니티 피드백을 장려하는 데 금전적 보상을 사용한다. 일반적으로 위험관리는 지루하고 자원을 많이 소모하는 작업이다. 사용자가 머신러닝 시스템의 주요 문제를 찾아내도록 하려면, 사용자에게 돈을 지불하거나 다른 의미 있는 방식으로 보상을 해야 한다. 버그 바운티는 일반적으로 공공의 노력으로 이루어진다. 버그 바운티 때문에 일부 조직이 불안해한다면 여러 팀이 머신러닝 시스템의 버그를 찾는 내부 해커톤도 똑같이 긍정적인 효과를 가져올 수 있을 것이다.
7) 인공지능 사고대응
SR 11-7 지침에서는 “숙련된 모델링과 강력한 검증으로도 모델의 위험을 제거할 수는 없다”고 한다. 그렇다면 어떻게 해야할까? 사고 대응 대책이 필요하다.
사실 이는 이미 컴퓨터 보안 분야에서 잘 정립된 관행이다. NIST나 사이버보안교육기관인 SANS같은 유서 깊은 기관에서는 수년간 컴퓨터 보안 사고대응 지침을 발표해왔다. 머신러닝이 범용 엔터프라이즈 컴퓨팅보다 성숙되지 않고 위험도가 높은 기술이라는 점을 고려하면, 영향력이 크거나 업무 수행에 필수인 인공지능 시스템은 반드시 공식적인 인공지능 사고대응 계획과 관행을 갖추어야 한다.
공식적인 인공지능 사고대응 계획을 준비해 두면 조직은 피할 수 없는 사고에 더 빠르고 효과적으로 대응할 수 있다. 사고대응은 앞에서 설명한 핸드 룰에도 적용할 수 있다. 사고대응 계획을 수립하고 이에 따라 연습을 해두면, 조직은 인공지능 사고로 인한 비용이 많이 발생하거나 위험한 사회적 문제로 확대되기 전에 사고를 식별해서 방지하고 근절할 수 있다. 인공지능 사고대응 계획은 인공지능과 관련한 위험을 완화하는 기본적인 방법 중 하나다. 시스템을 배포하기 전에 사고대응 계획의 초안을 작성하고 테스트해야 한다.
머신러닝과 AI 기술은 전례 없는 속도로 발전하고 있습니다. 세계 각국에서 규제를 준비하고 있으나 기술 발전 속도에 크게 못미치죠. 책임감 있고 지속 가능한 방식으로 머신러닝을 활용하기 위해선 사람 중심의 AI 기술 발전 촉진을 위한 가이드가 필요합니다.
실무자가 AI 모델 위험관리 프로세스를 제대로 이해하고 학습해 안전성, 편향 관리, 보안, 프라이버시 문제를 관리할 수 있도록 돕는 『머신러닝 리스크 관리 with 파이썬』에서 더 자세한 내용을 확인해보세요.
최신 콘텐츠