ProtectionAI를 지탱하는 무대 뒤 기술 이야기
- 8월 9일
- 5분 분량
언제나 PAPS의 활동을 지지해 주셔서 감사합니다.
이번에는 PAPS가 개발을 진행 중인 'ProtectionAI'의 기술적인 무대 뒤 이야기를 조금 소개합니다.
피해 이미지를 계속 찾으려면 인터넷상의 방대한 이미지와 영상을 모으고, 얼굴을 검출하고, 대조하는 작업을 끊임없이 이어가야 합니다.
평소에는 겉으로 잘 보이지 않는 부분이지만, ProtectionAI를 움직이기 위해서는 다양한 기술적 고민이 겹겹이 쌓여 있습니다.
■ ProtectionAI란
본인 동의 없이 촬영되거나 인터넷에 확산된 사적인 성적 이미지·영상(NCII)은 한 번 삭제되어도 다른 사이트나 페이지에 반복해서 게시되곤 합니다. ProtectionAI는 이용을 원하는 당사자 본인이 제공한 얼굴 사진을 바탕으로 얼굴 특징을 수치화하고, 그분이 찍혀 있을 가능성이 있는 이미지·영상을 인터넷에서 찾아 삭제 요청으로 연결하기 위한 시스템입니다.
그러려면 방대한 수의 이미지와 영상을 지속적으로 확인하고, 얼굴이 찍혀 있는지 검출하고, 특징을 대조해 나가야 합니다.
이 '계속 찾는' 처리를 멈추지 않는 것이 피해를 입은 분의 지속적인 회복으로 이어집니다.
■ 이미지·영상 수집을 지탱하는 'Paprika'
이전 뉴스레터에서 PAPS가 개발 중인 수집 시스템 'Paprika(파프리카)'를 소개했습니다. Paprika는 인터넷 페이지를 자동으로 돌며 이미지와 영상을 수집하는 '크롤러'라 불리는 시스템입니다. 개발이 진전되어 드디어 완성형이 보이기 시작했습니다.
현재는 약 150대의 VM(가상 머신) 위에서 약 300개의 Chrome 브라우저를 상시 돌리며 데이터를 수집하고 있습니다. 다만 웹사이트 구조는 저마다 다릅니다.
어떤 사이트에서는 쉽게 이미지를 가져올 수 있어도 다른 사이트에서는 같은 방법이 전혀 통하지 않는 일도 드물지 않습니다.
그래서 Paprika는 'Code-Gen Loop(코드 생성 루프)'라는 구조를 활용합니다.
이는 LLM이라 불리는 AI에게 프로그램을 쓰게 하고, 실제로 돌려 보고, 결과를 확인해 잘 안 되면 수정하는 작업을 자동으로 반복하는 구조입니다. ChatGPT 등도 LLM을 이용한 서비스 중 하나입니다.
예를 들어 어떤 웹사이트에서 이미지나 영상을 잘 가져오지 못하면 AI가 Python이라는 프로그래밍 언어로 코드를 작성합니다. 실행해서 실패하면 그 결과를 바탕으로 코드를 다시 쓰고, 가져올 수 있을 때까지 개선해 갑니다.
다만 웹페이지를 한 장 확인할 때마다 AI를 돌리면 막대한 비용이 듭니다. 그래서 한번 잘 가져온 프로그램은 같은 웹사이트에서 반복해 쓸 수 있는 '스킬'로 저장합니다. 다음에 같은 사이트의 다른 페이지를 조사할 때는 AI에게 처음부터 프로그램을 쓰게 할 필요가 없습니다.
AI가 생각하는 부분과 한번 익힌 방법을 반복해 쓰는 부분을 나눔으로써 대량의 페이지를 효율적으로 돌 수 있게 하고 있습니다.
■ 얼굴 특징 데이터 8,000만 건 돌파
ProtectionAI에서 대조에 쓰는 얼굴 특징 데이터가 8,000만 건을 넘었습니다. 하루당 88만 장의 이미지(학습 1분당 약 600장)에 해당합니다.
하나하나의 데이터가 필요한 이미지·영상을 찾아내는 단서가 됩니다. 한편 인터넷에서 수집한 이미지에는 사진뿐 아니라 일러스트 등도 포함됩니다. 얼굴 검출 시스템이 실존 인물이 아닌 일러스트 등을 '사람 얼굴'로 판단해 대조에 불필요한 데이터가 섞이기도 합니다.
이런 '노이즈'가 늘수록 필요한 데이터를 찾는 처리에도 불필요한 부하가 걸립니다.
그래서 현재 이런 노이즈를 자동으로 가려내 제거하는 전용 AI 모델도 개발하고 있습니다.
■ 무대 뒤① 영상에서 얼굴을 찾는 처리는 매우 '무겁다'
ProtectionAI의 처리 중에서도 특히 힘든 것이 영상입니다.
정지 이미지라면 한 장만 조사하면 되지만, 영상은 수많은 정지 이미지가 연속된 것입니다.
그래서 영상 한 편에서 얼굴을 찾으려면 영상을 구성하는 수많은 프레임을 차례차례 분석해야 합니다.
CPU만으로 이 처리를 하면 고성능 CPU라도 영상 몇 편만 동시에 분석해도 처리 능력이 가득 차 버립니다.
그래서 투입한 것이 이미지 처리와 대량 계산을 동시에 하는 데 능한 'GPU'입니다.
GPU를 쓰면서 CPU만일 때보다 영상과 이미지를 훨씬 효율적으로 처리할 수 있게 되었습니다. 하지만 GPU를 늘린다고 모든 것이 해결되는 것은 아닙니다.
대량의 데이터를 GPU로 계속 보내려면 '저장하는 곳'과 '데이터를 넘기는 구조' 양쪽을 고속화해야 했습니다.
■ 무대 뒤② SSD의 '벽'을 RAM으로 넘다
ProtectionAI는 매우 대량의 데이터를 고속으로 읽고 씁니다.
그래서 일반용 SSD(저장 장치)로는 속도뿐 아니라 '내구성'도 문제가 되었습니다. PAPS의 운용 환경에서는 대량 쓰기가 이어져 반년 만에 SSD 쓰기 내구 한계에 도달한 적도 있습니다. SSD 읽기·쓰기가 따라가지 못하면 CPU와 GPU에 여유가 있어도 시스템 전체 처리 속도는 오르지 않습니다.
그래서 처리 중 데이터를 일시 저장하는 'MinIO'라는 시스템을 SSD가 아니라 RAM 위에서 돌리기로 했습니다. RAM은 보통 PC에서 '메모리'라 불리는 것으로, SSD보다 훨씬 빠르게 데이터를 읽고 쓸 수 있습니다. 물론 RAM에 저장한 데이터는 전원이 꺼지면 사라집니다. 하지만 여기에 두는 것은 처리 중의 일시적 데이터입니다. 필요하면 원본 데이터에서 다시 만들 수 있으므로 사라져도 복원할 수 있습니다.
나아가 약 300개의 Chrome 브라우저도 대량 읽기·쓰기로 SSD 속도 저하와 수명에 영향을 주고 있었습니다. 그래서 Chrome이 쓰는 임시 데이터도 'RAM Disk'라 불리는 RAM상의 저장 영역을 쓰게 했습니다.
이로써 데이터 읽기·쓰기 속도를 개선하는 동시에 SSD 부담도 크게 줄일 수 있었습니다. 다만 당연히 그만큼 대량의 RAM이 필요합니다. 게다가 지금은 서버용 메모리 조달 비용도 큰 과제입니다. 1년 전 약 10만 엔에 구입한 96GB DDR5 RDIMM이 지금은 약 9배 가격이 된 것도 있습니다.
신품만으로 필요한 양을 갖추는 것은 현실적이지 않습니다. 그래서 10년 전인 2015년경 판매되던 중고 서버 부품(당시 부품이 없어 지금 기준에 맞추려고 드릴로 구멍을 뚫는 등 아날로그적인 일도 했습니다)과 중고 DDR4 LRDIMM을 eBay 등에서 사 모아 약 1TB 분량의 메모리를 추가했습니다. 이런 노력을 거듭해 현재는 시스템 전체에서 약 2.4TB의 메모리를 운용하고 있습니다. 화려한 AI 기술 뒤에서 사실은 중고 서버와 중고 메모리도 큰 활약을 하고 있습니다.
■ 무대 뒤③ 10기가 회선인데 속도가 안 나온다?
ProtectionAI와 Paprika는 대량의 이미지·영상을 수집하기에 통신량도 해마다 늘고 있습니다. 그래서 인터넷 회선을 최대 10Gbps 광회선으로 바꾸고 내부 네트워크와 주요 서버도 10Gbps 대응으로 갱신했습니다. 그런데 실제 운용하니 통신 속도가 2~3Gbps 부근에서 머물렀습니다. 모니터링 시스템을 확인하니 라우터에서 대량의 패킷 손실이 발생하고 있었습니다.
자세히 조사하니 IPv4 통신을 다루는 변환 처리에 부하가 집중되어 라우터 CPU 일부만 항상 한계까지 쓰이고 있음을 알게 되었습니다. 그래서 리눅스 기반 오픈소스 라우터 'VyOS'로 라우터 자체를 직접 만들어 보기로 했습니다.
이미 고가의 라우터를 구입한 터라 예산을 더 쓸 수 없었습니다. 그래서 중고 서버 부품을 중심으로 eBay에서 모아 비용은 약 6만 엔. 접속에 필요한 설정을 기술 블로그에서 찾아보고, 전환 직전에 설정 스크립트의 중대한 버그가 발견되는 등 쉽지 않았습니다. 그래도 새벽 4시에 약 30분의 통신 중단으로 전환을 완료했습니다.
그 결과 평균 통신량은 약 1.14Gbps에서 2.17Gbps로 늘었고, 그동안 약 6.8% 발생하던 패킷 손실도 거의 0%가 되었습니다.
이는 단순히 '회선을 빠르게 했다'기보다, 그동안 라우터에서 일어나던 '정체'를 해소한 결과입니다. ProtectionAI에서는 CPU와 GPU뿐 아니라 SSD, RAM, 네트워크 등 어느 한 곳이 막혀도 전체 처리가 느려집니다.
이런 잘 보이지 않는 병목을 하나씩 개선하며, 더 많은 이미지와 영상을 안정적으로 계속 찾을 수 있는 환경을 갖추고 있습니다.
■ 무대 뒤④ 10대 규모 장비를 묶는 독자 파이프라인
서버와 GPU가 많아도 제각각 움직이면 충분한 성능을 내지 못합니다. '어느 서버에 어떤 일을 맡길지', '처리가 끝나면 다음에 무엇을 돌릴지' ― 이런 전체 교통정리를 하는 구조가 필요합니다.
이렇게 여러 컴퓨터를 연계시켜 처리를 관리하는 것을 '오케스트레이션'(오케스트라 지휘자의 이미지)이라 부릅니다. 세상에는 'Ray' 같은 유명한 분산 처리 시스템도 있습니다. 하지만 PAPS에서 시험해 보니 현재 용도와 10대 안팎의 규모에는 기능이 너무 크고 잘 맞물리지 않는 부분이 있었습니다. 그래서 ProtectionAI의 규모와 처리 내용에 맞춘 독자 파이프라인 시스템을 개발했습니다.
각 서버와 GPU의 상태를 확인하면서 '비어 있는 장비에 다음 처리를 넘기는' 교통정리를 하는 구조입니다.
이 구조를 만드는 과정에서도 큰 문제 하나에 부딪혔습니다.
처리량이 일정하지 않고 빨라졌다 느려졌다 하는 '진동'이 일어나 GPU가 때때로 처리 대기 상태로 멈춰 버린 것입니다. 고성능 GPU가 있어도 GPU에 일을 넘기는 쪽이 따라가지 못하면 모처럼의 계산 능력을 다 쓸 수 없습니다.
그래서 도입한 것이 자동차 기어 변속 같은 사고방식입니다. 차가 출발할 때와 고속 주행할 때는 적합한 기어가 다릅니다. 마찬가지로 시스템 처리 상황에 따라 GPU에 일을 배분하는 방식을 바꾸는 구조를 도입했습니다.
그 결과 처리의 파도를 억제하면서 GPU를 안정적으로 돌릴 수 있게 되었고, 더 많은 이미지와 영상을 지속적으로 처리할 수 있게 되었습니다.
■ 기술을, 피해를 입은 분을 위해
ProtectionAI 개발에서는 AI 모델 자체뿐 아니라,
"어떻게 방대한 이미지·영상을 모을 것인가"
"어떻게 대량의 영상을 빨리 분석할 것인가"
"어떻게 장비를 멈추지 않고 계속 돌릴 것인가"
같은 다양한 과제와 마주하고 있습니다.
하나하나는 수수한 개선일지 모릅니다.
하지만 그 축적으로 더 많은 이미지와 영상을 더 빨리, 지속적으로 찾을 수 있게 됩니다. 그리고 그 끝에 있는 것은, 본인이 원치 않는 성적 이미지·영상의 확산으로 피해를 입은 분을 조금이라도 빨리 지원으로 연결하는 것입니다.
앞으로도 ProtectionAI 개발 소식과 그 무대 뒤 이야기를 전해 드리겠습니다.
계속해서 PAPS의 활동에 대한 지원을 부탁드립니다.
