‘진짜 서비스’에 쓸 AI 모델 만들기: 테스트와 모델 요구 사항

부스트코스2024년 11월 7일About 2 min

‘진짜 서비스’에 쓸 AI 모델 만들기: 테스트와 모델 요구 사항 관련

실제 서비스를 위한 AI를 만들 때 필요한 것들을 마저 살펴볼까요? 학습 데이터셋 정의와 구축을 마치고 나면 정해야 하는 것은 테스트 방법입니다. 이 방법 역시 서비스 요구 사항으로부터 도출해야 합니다. 즉, “어떻게 이 AI 모델을 평가할 것인가”에 대한 정보를 알아내는 일이죠. 서비스 요구 사항의 쓰임은 여기서 끝이 아닙니다. 또 하나 필요한 작업이 있습니다. 바로 모델에 관련된 요구 사항을 도출하는 일입니다. 이처럼 단순히 AI 모델의 성능을 올리는 작업 외에도 정말 많은 일들이 있습니다. 모델 개발에 어떤 과정들이 필요하다, 이것만 알고 있어도 실무에서 AI 모델을 개발할 때 정말 큰 도움이 될 거라고 믿어 의심치 않습니다.

IT 지식이 무엇보다 중요해진 요즘, 여러분은 어떻게 공부하고 있나요? 가장 먼저 눈길이 가는 건 다양한 IT 강의 영상일 겁니다. 강의를 제공하는 교육 기업들과 함께, 요즘IT에서 ‘IT 강의 시리즈’를 준비했습니다. 엄선한 교육 영상을 텍스트로 읽고 필요한 정보를 빠르게 가져가세요.

이번 강의는 ‘서비스 향 AI 모델 개발하기’입니다. AI 스타트업 업스테이지의 CTO이자, 전 네이버 클로바 임원인 이활석 님의 특강을 텍스트로 옮겼습니다. 실제 서비스에서 쓰는 AI 모델 개발 과정부터 올바른 조직 구성 방법까지, 이론이 아닌 AI 개발의 실재를 만나 보세요. 전체 영상은 네이버 부스트코스에서 확인할 수 있습니다.

서비스향 AI 모델 개발하기 시리즈

‘진짜 서비스’에 쓸 AI 모델 만들기: 서비스 요구 사항과 학습 데이터셋 | 요즘IT

‘진짜 서비스’에 쓸 AI 모델 만들기: 서비스 요구 사항과 학습 데이터셋

진짜 서비스’에 쓸 AI 모델 만들기: 테스트와 모델 요구 사항 | 요즘IT

진짜 서비스’에 쓸 AI 모델 만들기: 테스트와 모델 요구 사항

AI 커리어를 시작하려는 개발자를 위한 조언 | 요즘IT

AI 커리어를 시작하려는 개발자를 위한 조언

지난 글에서는 서비스 목적으로 AI를 개발하는 일이 학습 목적으로 AI를 개발하는 일과 얼마나 다른지 알아봤습니다. 특히 “실제 서비스를 위한 AI를 개발한다”라고 할 때는 학습 데이터셋이 없는 경우가 많으므로, 이를 준비하는 방법을 설명했죠.

오늘은 이제 또 다른 문제, 모델 성능을 테스트하는 일과 실제 모델을 위한 요구 사항을 도출하는 일에 대해 이야기하려고 합니다.

AI 모델은 언제 어떻게 평가할까

테스트 데이터셋은 구축한 학습 데이터셋의 일부를 사용할 때가 있습니다. 물론 그렇지 않을 때도 있지만, 우선 테스트 데이터셋은 구비되어 있다고 생각하겠습니다.

이제 정해야 할 것, 테스트 방법입니다. 이 방법 역시 서비스 요구 사항으로부터 도출해야 합니다. 즉, “어떻게 이 AI 모델을 평가할 것인가”에 대한 정보를 알아내는 일이죠. 여러분들의 이해를 돕기 위해서 하나 예시를 들어 볼게요.

1 대 1 대전 게임의 AI 모델 만들기

1 대 1 대전 게임을 위한 AI 모델을 만든다고 생각해 봅시다.

왼쪽, 초록색으로 표현한 것이 사용자입니다. 이렇게 사람과 AI가 있어, 둘이 1 대 1 대결을 하는 거죠. 이 1대 1 대결을 잘하는 AI 모델을 만드는 것이 저희의 목표입니다.

먼저 AI 모델의 입출력을 한번 정의해 보겠습니다.

입력은 게임 화면 이미지입니다. 게임 화면 이미지는 60fps를 지원할 때도 있고, 30fps를 지원하는 경우도 있습니다. 대략 100ms마다 이미지를 받아와 어떤 출력물을 낸다고 해볼게요.

그 출력물은 무엇이 될까요? 1 대 1 대전 게임 해본 사람은 알다시피 캐릭터마다 스킬 셋이 있습니다. 그 스킬 셋 중에 어떤 스킬을 쓸 것인가, 이를 AI가 정한다고 해볼게요. 다만 다양한 스킬 셋에서 쓸 스킬을 정하는 것을 넘어 출력 후보가 하나 더 들어가야 합니다. 아무 스킬도 사용하지 않는 경우죠. 게임을 할 때 항상 스킬을 쓰는 건 아니기 때문에, ‘아무 액션을 취하지 않는다(no_action)’라는 선택지를 하나 더 추가하겠습니다. 이 전체 선택지 중에서 무엇을 선택할 건지 문제를 AI가 푼다고 할게요.

이 문제는 결국 “이미지 입력을 바탕으로 다양한 선택지 가운데 하나를 선택하는 것”이므로 분류 문제로 세팅할 수 있습니다.

이때 스킬은 AI가 조종합니다. 물론 실제라면 캐릭터의 움직임도 조종해야 할 겁니다. 다만 너무 복잡하니 이번에는 캐릭터가 기존에 정의한 룰에 따라 움직인다고 치겠습니다. AI는 스킬만 열심히 선택하는 거죠.

그 전에, 이 AI 모델을 학습하려면 마찬가지 데이터셋이 필요할 겁니다.

그 데이터셋을 어떻게 준비할 수 있을까요? 프로게이머들의 로그(log, 사용 기록)를 사용합니다. 프로게이머, 즉, 이 1 대 1 대전에 굉장히 능숙한 사람들의 로그인 겁니다. 여기서 로그라고 함은 프로게이머들이 게임을 할 때 화면에 나타난 입력 이미지, 그 이미지별로 선택한 스킬의 기록이라고 볼 수 있고요. 그 로그 이미지를 잔뜩 받아와 AI를 교사 학습(또는 지도 학습, Supervised Learning) 방식으로 학습시켰습니다.

분류 정확도가 99%인 모델은 승리할까?

학습 결과, 분류 정확도가 무려 99%까지 나왔습니다. 이 99% 정확도의 AI 모델로 실제 사용자와 대전을 붙였을 때 결과가 어떻게 되었을까요?

한번 상상해 보세요. 이겼을까요?

이겼다면 어떤 식으로 기술을 썼을까요?

이 분야 최고의 프로게이머 a와 유사한 패턴을 보이면서 이겼을까요?

아닙니다. 결과는 완패입니다. 왜 완패했을까, 게임 경기 화면을 봤더니 AI가 조종하는 캐릭터는 아무런 스킬도 사용하지 않았습니다. 그냥 정해진 룰에 따라서 움직이기만 하고 스킬은 하나도 사용하지 않아요.

왜 스킬을 쓰지 않는지, 그 이유도 살펴봤습니다. 그러다 프로게이머들의 로그에서 어떠한 패턴을 발견했습니다. 앞서 100ms 단위로 로그를 남긴다고 했는데요. 그러면 1초에 10개, 1분이면 600개, 이렇게 로그가 쌓입니다. 그런데 굉장히 많은 그 타임 사이에서 정작 스킬을 쓰는 일은 굉장히 드뭅니다. 고수일수록 스킬을 남발하지 않고 딱 적재적소에서 필요한 스킬만 딱, 이렇게 사용하는 경향이 많았거든요. 자연스럽게 로그 전체에서 거의 대부분 아무 스킬도 쓰지 않는 ‘노 액션(no_action)’에 해당하는 데이터가 많이 나왔습니다.

이 데이터셋을 가지고 교사 학습한 AI 모델이 분류 문제를 풀면 예측값은 항상 ‘노 액션’이 나올 거예요. ‘노 액션’만 예측해도, 어떤 스킬을 썼느냐 맞출 확률이 99%인 거죠. 대부분은 스킬을 쓰지 않으니까요. 그래서 모델 정확도는 99%지만, 실제 움직임을 보면 아무런 스킬을 사용하지 않은 겁니다. 승률은 0%인 거죠.

실제로 모델을 개발하다 보면 이런 일이 정말 많이 발생합니다. 이 문제를 어떻게 바라봐야 할까요?

오프라인 테스트와 온라인 테스트

실제 서비스에 적용하기 전, 개발 환경에서는 AI 모델을 정량 평가합니다. 이 모델은 분류 문제로 세팅했기 때문에 분류 정확도를 봤고요. 이런 작업을 **오프라인 테스트(Offline Test)**라고 하는데요. 그래서 이 AI 모델은 오프라인 테스트에서 정확도 99%가 나온 모델입니다.

그런데 이 AI 모델을 실제 서비스에 적용한 결과는 어땠나요? 실제 사용자와 맞붙은 대전에서는 정량적 평가 결과가 0%로 나왔죠. 이처럼 모델을 실제 서비스에 적용해 평가하는 것을 **온라인 테스트(Online Test)**라고 합니다.

여기서 중요한 포인트는 이처럼 오프라인 테스트의 결과와 온라인 테스트의 결과가 다른 경우가 많다는 점입니다.

결과가 다르면 당연히 안 좋을 테고요. 그래서 오프라인 테스트로 정량 평가를 할 때는 온라인 테스트와 결과가 유사하게 나오도록 준비해야 합니다. 1 대 1 대전 모델 같은 경우에도 오프라인 테스트를 제대로 세팅했다면, 사실 0%가 나와줬어야 한다는 뜻입니다. 이러한 테스트 방법의 차이를 잘 알아야 실무에 굉장히 도움이 될 것입니다.

정리해 볼게요. 평가에는 개발 과정에서 서비스 적용 전에 하는 성능 평가인 오프라인 테스트와 실제 서비스에 적용했을 때의 성능 평가인 온라인 테스트, 이렇게 크게 두 가지 종류가 있습니다. 또 각각 경우에 따라 정량적으로 평가할 수도 있고, 정성적으로 평가할 수도 있죠.

오프라인 테스트: AI 모델은 어떻게 선택할까?

개발 단계에서 정량 평가를 할 때 명심해야 하는 것이 있습니다. 이 평가 결과가 “절대로 완벽하지 않다”는 것이죠. 특히 AI 모델의 정량 평가는 실제 서비스와 굉장히 다른 경우가 많아요. 그래서 최대한 완벽해지려고 노력해야 하지만, 실제로는 완벽하지 않다는 사실을 염두하고 정량 평가를 진행해야 합니다.

그런 만큼 이 정량 평가에서 제일 좋은 성능을 보여준 AI 모델 하나만을 선택하는 건 굉장히 위험한 일입니다. 그래서 하나만 선택하기보다 “후보군을 모은다”라는 느낌으로 이 정량 평가를 사용하면 좋습니다.

다만 이렇게 모인 후보 가운데 결국 AI 모델을 하나만 선택해 서비스에 적용해야 할 겁니다. 그때는 정성 평가를 합니다. 후보 AI 모델을 여러 관점으로 면밀히 분석한 다음, 서비스 출시 버전을 선택하는 거죠. 그래야 위험도를 낮출 수가 있습니다.

온라인 테스트: VoC로 개선 포인트 파악하기

이렇게 선택한 AI 모델을 서비스에 적용하고 나면 다시 정량 평가를 해야 합니다. 서비스가 돌아가며 어떠한 정량 지표를 자동으로 받아야 AI 모델 품질에 대한 모니터링을 할 수 있겠죠. 이 작업은 필수입니다.

그다음은 전체 4가지 항목에서 가장 중요한 평가, 서비스에 적용한 다음 받는 정성 평가입니다.

이 정성 평가는 고객들이 합니다. 보통 VoC(Voice of Customer)라고 하죠. 고객들이 “이거 왜 안 돼요?”, ”이 서비스는 이런 문제가 있는 것 같아요” 같은 클레임을 거는 건데요. 그런 클레임이 사실 AI 모델의 개선 포인트를 파악하는 데 아주 중요한 포인트입니다.

이런 의견을 잘 모아 AI 모델을 만드는 담당자, 학습 데이터셋 준비 담당자들이 모여 주기적으로 토론을 하는 거죠. 그러면서 개선 포인트를 잡습니다. 모델의 개선 포인트일 수도 있고, 학습과 평가 데이터셋의 개선 포인트일 수도 있습니다. 이런 식으로 개선 포인트를 파악하는 일이 정말 중요합니다.

특히 AI 모델을 서비스에 적용한 다음, 모델의 품질을 유지 보수할 때는 고객의 VoC를 무시하면 안 됩니다. 잘 모으고 분석해 개선 포인트로 이어지게 만드는 일, 이 일이 서비스향 AI 모델을 만들고 유지 보수할 때 가장 중요한 일이라고 말할 수 있습니다.

서비스 요구 사항에서 모델 요구 사항 도출하기

앞서 서비스 요구 사항으로부터 학습 데이터셋, 그리고 테스트 데이터셋과 테스트 방법에 대한 정보를 뽑아야 한다고 말했는데요. 서비스 요구 사항의 쓰임은 여기서 끝이 아닙니다. 또 하나 필요한 작업이 있습니다.

바로 모델에 관련된 요구 사항을 도출하는 일이죠.

1. 처리 시간

모델 요구 사항 첫 번째, 처리 시간입니다. 처리 시간은 하나의 입력이 들어왔을 때, AI 모델을 거쳐 출력물이 나올 때까지 걸리는 시간입니다.

예시를 좀 들어볼게요. 지난 글에서 사진으로부터 수식을 뽑아내는 모델을 예시로 들었는데요. 이 모델의 앞 단에 수식 영역을 검출하는 모듈이 있었습니다. 이 모델의 처리 시간을 테스트한다면 당연히 이미지가 입력으로 들어온 다음, 수식 영역에 대한 정보가 출력될 때까지 시간을 확인하겠죠.

그런데 이 작업을 온라인 테스트 관점에서 바라보면 사용자 시나리오를 봐야 합니다. 이미지를 촬영하고, 그 이미지에서 수식 영역 정보를 검출한 다음, 그 정보가 화면에서 표현될 때까지 시간, 이를 처리 시간으로 볼 수도 있어요. 만약 사용자가 이미지를 찍고 수식 영역 정보를 확인할 때까지 1시간이 걸린다, 이러면 서비스 품질이 굉장히 나빠질 테고요. 이처럼 처리 시간도 오프라인 테스트와 온라인 테스트 관점에서 다르게 정의할 수 있습니다.

그래서 일반적으로 서비스 기획팀에서 요구 사항에 처리 시간을 포함합니다. 이를테면 “사진 촬영부터 결괏값이 나오기까지, 1초 안에 처리해 줬으면 좋겠어요.” 같은 요구 사항들이 보통 옵니다. 그 요구 사항은 고스란히 AI 모델이 데이터를 처리할 수 있는 시간의 제약으로 다가올 겁니다.

2. 정확도

그다음은 목표 정확도입니다. 모델을 개발할 때는 여러 정량 평가 방법들을 마련합니다. 그때 “어떠한 정량 평가 방법의 결과가 90% 이상 나오게 해주세요.” 이런 요구 사항이 올 수 있습니다.

여기서도 오프라인 테스트와 온라인 테스트 관점에서 한 번 더 설명해 볼게요.

신용카드 인식을 한번 예로 들어 보겠습니다. 새로운 신용카드를 페이 같은 서비스에 등록할 때, 사진을 찍으면 카드 번호와 유효 기간이 자동으로 입력되는 것을 많이 경험해 봤을 거예요. 그런 일을 하는 AI 엔진이 오프라인 테스트를 한다면 우선 이미지를 입력받아 카드 번호, 유효 기간이란 출력을 낼 겁니다. 그 테스트 이미지에 대한 정답이 있을 테니 나오는 출력값과 정답, 두 가지 숫자열이 얼마나 다른지를 보겠죠. 이때는 에딧 디스턴스(Edit Distance) 같은 지표를 많이 씁니다. 많이 쓰이는 메트릭인 만큼 개발 단계에서는 그대로 쓸 수 있겠죠.

그런데 이 신용카드 인식 모듈의 정확도를 온라인 관점, 즉, 실제 서비스 관점에서 평가하려면 또 다른 정의가 필요할 수 있습니다. 사용자는 사진을 찍어 신용카드를 등록하고 싶습니다. 그러니 AI 모델의 결괏값이 정확하다면 수정할 일이 없겠죠. 그냥 넘어갈 겁니다. 그런데 사용자가 수정을 한다, 이는 무언가 틀렸다는 이야기죠. 사용자가 AI 모델의 결괏값을 수정할 확률, 이 확률로 AI 엔진의 성능을 평가하면 좀 더 서비스 시나리오에 맞는 정량 평가가 됩니다.

이런 식으로 단순히 정확도라 하더라도 개발 단계, 그리고 실제 서비스 단계에서의 평가 방식은 조금 다를 수가 있어요. 서비스 기획팀에서도 “온라인 테스트를 할 때는 정확도가 85% 이상 나오게 해 주세요.” 같은 식으로 테스트 단계마다 다른 요구 사항이 들어올 수 있죠. 이를 바탕으로 AI 모델의 목표 정확도를 정합니다.

3. QPS(Queries Per Second)

그다음으로 모델 요구 사항에 들어갈 항목, 목표 QPS입니다.

QPS는 Queries Per Second, 즉, 1초당 처리 가능한 요청 수를 말합니다. 예를 들어 ‘우리 a 서비스를 초당 100명이 사용하며, 그에 맞춰 초당 100건의 이미지가 올라온다’고 할게요. 그렇다면 100QPS를 감당할 환경이 갖춰져 있어야 버벅거림 없이 서비스가 원활히 돌아갈 겁니다. 이런 상황을 확인하기 위해 QPS라는 단어를 씁니다.

QPS는 당연히 높을수록 좋겠죠? 그래서 이 지표를 향상시키는 방법을 고민해야 합니다. 방법은 크게 세 가지, 장비 늘리기, 처리 시간 줄이기, 모델 크기 줄이기가 있습니다. 이 중 처리 시간을 줄이는 것과 모델 크기를 줄이는 것, 두 가지는 모델 요구 사항과 굉장히 긴밀하게 연관됩니다.

장비를 늘리는 경우에 대해서 살펴볼게요. 우리가 쓸 수 있는 지표 장비별로 QPS가 있을 텐데요, 장비를 N개 늘려버리면 QPS가 N배 올라가겠죠. 다만 당연히 비용이 들어갑니다. 때로 늘어난 요청을 분배하는 분배기가 병목(Bottle Neck)이 되는 경우도 있고요. 그럼에도 장비를 늘리는 건 가장 손쉽게 QPS를 올릴 수 있는 방법입니다.

다음은 처리 시간을 줄이는 방법입니다. 처리 시간을 줄인다는 것은 AI 모델의 처리 속도가 올라간다는 얘기입니다. 만약 처리 속도가 N배 올라갔다면 당연히 QPS도 N배 올라가겠죠 이런 식으로 QPS를 올릴 수 있고요.

마지막은 모델의 크기를 줄여서 대응하는 방법입니다. 장비, 그러니까 GPU 한 개에 올라가는 모델 수는 정해져 있는데요, 모델 크기를 줄이면 동시에 N개의 모델을 띄울 수도 있습니다. 그러면 곧 N배의 요청을 처리할 수 있습니다. 그런 만큼 QPS도 N배 올라가죠.

다만 이때 유념해야 할 것이 하나 더 있습니다. 만약 우리가 쓸 수 있는 GPU 메모리가 10GB라고 해 볼게요. 이를 활용하는 모델의 크기는 8GB입니다. 그러면 여기에는 모델을 하나밖에 못 올리죠. 그래서 2개를 올리기 위해 이 모델에 대한 메모리 요구 사항을 줄였습니다. 8GB, 7GB, 6GB 순서대로 줄였죠.

그런데 사실 5GB가 되기 전에는 이렇게 크기를 줄이는 일이 QPS 관점에서 다르지 않습니다. 아무리 줄여도 결국 10GB 메모리에는 하나밖에 올라가지 않으니까요. 그래서 이렇게 모델 크기를 줄일 때는 그만큼 선형적(linear)으로 QPS가 올라가지 않습니다. 필요한 배수만큼 맞춰 줄여야 QPS가 올라가죠. 이를 유념하면 좋겠습니다.

4. 서빙 방식

마지막으로 설명할 모델 요구 사항은 서빙(Serving) 방식입니다. ‘서빙을 한다’는 말은 AI 모델이 어떤 하드웨어 디바이스에서 동작을 하는지와 굉장히 밀접하게 관련되어 있습니다.

이를테면 모델이 모바일에서 동작할 수 있겠죠. 그러면 모바일의 요구 사항에 맞춰 모델의 처리 속도라든가 메모리 크기에 제약이 생깁니다. 이는 다시 CPU인지 GPU인지에 따라, 로컬 서버인지 클라우드인지에 따라 또 크게 달라집니다.

가끔 고객들 가운데 “로컬 장비도 클라우드도 없어, 그래도 로컬로 쓰고 싶으니 장비까지 같이 구축해 달라.”는 요구 사항이 들어올 수도 있습니다. 그러면 어떤 장비를 살 것인지까지 정리해 주어야 합니다. 예산과 서비스의 QPS, 이를 종합해서 사용할 장비를 탐색해야겠죠. 그런 다음에야 장비 사양에 따라 모델에 필요한 처리 속도, 메모리 크기 같은 것이 정해질 테고요.

마치며

지금까지 실제 서비스를 위한 AI를 만들 때 필요한 것들을 살펴보았습니다. 단순히 AI 모델의 성능을 올리는 작업 외에도 정말 많은 일들이 있죠. 우선 학습 데이터셋 준비해야 하고, 테스트 데이터셋과 테스트 방법도 준비해야 합니다. 모델 요구 사항 분석도 잊지 말아야 하고요.