컨텐츠 바로가기

05.24 (금)

글로벌 칼럼 | 섀도우 IT보다 훨씬 더 위험한 ‘교활한 IT’

댓글 첫 댓글을 작성해보세요
주소복사가 완료되었습니다
회사 직원의 어떤 행동으로 IT가 엉망이 되는 것도 큰 일이지만, IT 공급 업체에서 비슷한 행동을 하면 문제가 더 심각할 수 있다. 전자가 섀도우 IT(Shadow IT) 혹은 섀도우 IoT(Shadow IoT)와 관련된 IT 위험이라면 이미 널리 알려져 있다. 반면 새로운 섀도우 IT인 후자가 최근 확산하고 있다. 이른바 후자는 '교활한 IT(Sneaky IT)'다.
ITWorld

ⓒ Getty Image Bank

<이미지를 클릭하시면 크게 보실 수 있습니다>



섀도우 IT는 사용자가 IT팀과 기업 보안 담당자 모르게 다른 곳에서 보안 서비스를 결제해 이용하는 것으로, 기업 IT 환경에 다양한 위협이 된다. 하지만 신뢰할 수 있는 업체가 서비스에 새로운 요소를 추가하는 것은 어떨까? 예를 들어 SaaS에 추가된 신기능을 사용자에게 언급하지 않는다면 어떻게 될까? 이 역시 섀도우 IT와 비슷한 위험을 초래하는데, 두 경우 모두 결국 가시성의 문제다. 특히 두번째 교활한 IT는 가시성의 부재와 관련이 있다.

이 문제가 심각한 것은 데이터 제어 문제뿐만 아니라 중대한 규정 준수 문제를 야기하기 때문이다. 예를 들어 규제 기관이 기업에 생성형 AI를 어떤 용도로 어떻게 사용하고 있는지 확인하면 CIO는 이에 대해 완전하고 진실하며 정직하게 대답할 수 있어야 하는데, 섀도우 IT, 교활한 IT는 이를 불가능하게 한다.

대표적인 교활한 IT 사례를 보자. 몇 년 전 일이다. 미국 중서부의 한 대형 제조 기업에서 발생한 일이다. 이 기업은 조립 라인의 대규모 장비를 고도로 전문화된 공급업체에 맡기고 있었고, 이 공급업체는 해당 장비를 속속들이 알고 있었다. 문제는 이 업체가 기업에 알리지도 않고 장비에 마이크를 설치하면서 시작됐다. 해당 업체는 장비에 수리 문제가 발생하기 전에 예측해 대응하기 위해 이런 방법을 택했다. IoT 마이크와 머신러닝을 활용해 수집한 소리를 분석하는 방식이었다. 교활한 IT, 교활한 AI 사례이기도 하다.

그런데 어느날 장비가 오작동했다. 업체 수리팀이 도착하기를 기다리는 동안 조립 라인 직원 중 일부가 기계를 분해하다가 마이크를 발견했다. 조립 라인 관리자는 '스파이 기기'로 보이는 이런 기기를 자사 장비에 설치하기 전에 사전 통보는커녕 물어보지도 않았다는 사실에 격분했다.

생성형 AI 도구는 우리가 생각하는 것보다 훨씬 더 빠른 속도로 제품에 몰래 숨어들고 있다. 물론 업체들은 일반적으로 'AI를 사용한다'고 공개하기는 한다. 하지만 기업 IT팀이 관련된 의사결정을 할 수 있을만큼 충분히 구체적이냐고 하면 꼭 그런 것은 아니다. 규제 기관의 질문에 답할 수 있을 정도가 아닌 것도 물론이다.

IT 관점에서 보면 섀도우 AI와 교활한 AI의 차이는 매우 크다. IT는 직원과 계약업체에 승인되지 않은 시스템을 사용하지 않도록 요구할 수 있지만, IT팀은 이를 확인할 툴도, 시간도 없다. 예를 들어 직원이 휴대폰으로 챗GPT에 접속해 얻은 답변을 회사 문서에 사용하면 IT팀이 어떻게 알아내겠는가? 반면 교활한 AI는 IT 부서가 비용을 지급하는 업체와 관련이 있다. IT 부서는 직원이 섀도우 AI에 관여할 경우 해고될 수 있다는 고지하지만, 그 실효성은 그리 크지 않다. 반면 업체는 다르다. 계약상 공개 및 기타 의무를 모두 이행하지 않아 기업이 규정 준수 문제를 일으키면 재계약이 안 될 수 있고 소송을 당할 수도 있다. 매우 현실적인 제약이 될 수 있다.

필자는 다양한 업체로부터 '교활한 AI' 문제를 들었지만, 정작 기업은 이를 섀도우 IT라고 불렀다. 명확한 정의 문제를 떠나, 업체가 2가지를 잘못 묶어서 설명해 정작 문제를 해결할 방법을 찾기가 더 어려워지고 있다. 이미 해결이 불가능한 문제일 수도 있지만, 적어도 피해를 최소화하는 것은 가능하다. 일단 '교활한 IT'의 가능성은 공급 업체 계약에서 직접적으로 다뤄져야 한다. 최종적인 목표는 기업 IT 의사 결정권자가 구매한 시스템에 무엇을 설치되는지 알 수 있도록 하는 것이다. 이는 단순히 사전 통지를 넘어 일정 시기 이전에 알려주도록 강제하고 기업의 허가를 구해야 한다는 것을 의미한다.

물론 주요 SaaS 업체가 새로운 기능을 출시하기 전에 모든 사용자의 허가를 받을 때까지 기다려야 한다는 의미는 아니다. 하지만 기업 IT 부서는 거부할 권리가 있으며, 본질적으로 "이것은 우리가 구매한 것이 아니며 우리가 원하는 기능이 아니고 비용을 지불할 의사가 전혀 없다"라고 말할 수 있어야 한다.

계약의 관점에서 볼 때, 업체는 기능이나 방식에 중대한 변경이 있을 경우 6개월, 1년 전에 사전 통지를 해야 한다. 사용자가 원하지 않는 경우 위약금 없이 기존 계약에서 벗어날 수 있어야 한다. 5년 계약을 하고 할인을 위해 선불로 결제했는데, 1년이 지나지 않았다면 남은 기간에 대해 전액 환불을 받을 수 있어야 한다.

현실적으로 이미 체결한 라이선스 계약에 이런 조건을 추가하는 것이 쉽지 않을 수 있다. 하지만 계약 조건을 변경한 것은 사용자가 아니므로 합리적인 요구다. 사용자 기업의 IT 부서가 XYZ를 구매했는데 해당 업체가 이를 변경하기로 한 것이다. 즉, 업체가 계약을 파기한 것이다. 이 문제에 대한 가장 간단한 해결책은 모든 RFP에 이런 요구 사항을 즉시 추가하는 것이다. 이를 동의하는 업체만 해당 기업의 IT 프로젝트에 입찰할 수 있으므로, 교활한 IT 문제를 해결할 수 있다.
editor@itworld.co.kr

Evan Schuman editor@itworld.co.kr
저작권자 한국IDG & ITWorld, 무단 전재 및 재배포 금지
기사가 속한 카테고리는 언론사가 분류합니다.
언론사는 한 기사를 두 개 이상의 카테고리로 분류할 수 있습니다.