정성의견 분류&감성분석 시스템 개발 사례②

숲과 같은 텍스트 데이터를 한눈에 살펴볼 수는 없을까

어쩌면 잘못된 길인지도 모른다는 것을 알고 있었지만 용감하게 시작한 프로젝트이기에 일단은 조금 더 가보기로 했다. 그리고 8인의 라벨링 전사 각자가 정성의견 1,000개 씩에 대한 라벨링을 진행하고 나면 분류 모델 프로토타입을 만들어서 계속 진행할지 여부를 판단해 보기로 했다.

데이터 라벨링, 시작 전으로 돌아갈 순 없지만 정석과 비슷한 방식을 시도해 본다면?

앞선 포스팅에서 언급했다시피 라벨링을 전문으로 수행하는 업체에 작업을 의뢰한다면 작업자 간 라벨 명칭에 대한 이해를 위한 사전 워크숍 시간을 제법 길게 진행할 것이고, 또한 같은 문장에 대해서 여러 작업자가 중복으로 라벨링을 진행한다는 것을 알았기에 우리의 작업 방식을 조금 수정할 필요가 있었다. 사실 이미 첫 1시간 작업 과정에서 공들여 섭외한 8명의 작업자들이 비슷한 문장에 대해서 조금씩 다른 생각을 가지고 있다는 것을 발견할 수 있었기에 아마 정석적인 방식을 몰랐다 하더라도 뭔가 눈높이를 맞추기 위한 노력은 진행했을 것 같다. 그런 와중에 전문가로부터 작업에 대한 조언(?)도 받았으니 비슷한 형태로나마 흉내는 내볼 필요가 있었다.

시간과 비용의 제약이 없었다면 아마도 같은 문장들을 여러 작업자에게 나눠주고 수정된 방식으로 라벨링 작업을 진행했겠지만 예정된 일주일이라는 시간 내에 완료하기 위해 중복 작업은 할 수가 없었고, 대신 8명의 작업자와 이 프로젝트의 멤버 3명이 함께 하는 Slack 채널을 개설하였다. 그리고 각자 작업을 하면서 어떤 라벨로 표기하는 것이 좋을지 애매한 문장에 대해서는 채널 내에 문장을 남기면 다른 작업자들이 각자의 생각을 남기도록 하였고, 서로 간의 의견이 나뉘는 경우에는 프로젝트팀에서 라벨을 정해주는 방식을 채택하였다. 또한 작업이 눈과 손에 익을 때까지 초반 이틀 정도는 매 1시간마다 프로젝트팀 진행 하에 지난 1시간 동안의 작업에 대한 Reflection 시간을 10~20분가량 갖고, 작업 관련 수정 아이디어를 서로 공유하면서 라벨링 원칙을 수립하였다.

작업 초반 논의를 통해 확정된 라벨링 원칙

모델 프로토타입, Go or Stop?!

작업 진행 중간중간 서로 간의 생각을 맞추는 시간이 필요했기에 초반 1,000개 문장에 대한 라벨링 작업은 처음 계획보다 지연된 감이 있었다. 2일 차 오후쯤 대부분의 작업자가 Slack 채널을 통해 본인의 몫을 마쳤음을 남겨 주었고, 프로젝트팀에서는 구글 스프레트시트를 통해 8,000개 문장을 취합 후 분류 모델 프로토타입을 진행하였다.

라벨링의 작업의 정석을 따르지 못했으니 어느 정도 성능이면 계속 진행하는 것이 좋을까에 대해 논의가 있었다. 아무래도 사람의 말을 분류한다는 점과 라벨링 작업자들이 Slack 채널을 통해 남기는 문장들이 결코 하나의 라벨로 딱 떨어지지 않는 경우가 많다는 점을 생각해 봤을 때 8,000개를 학습(Train)한 모델의 성능이 Accuracy를 기준으로 0.6 정도만 나와주면 계속 진행해 보기로 하였다. 최종 10만 개 데이터를 학습시키고 이래저래 튜닝을 통해 70 정도는 되는 모델로 만들어 볼 수 있지 않을까 하는 생각이었다.

프로토타입 모델 예측 진행 중 주저앉은 인턴사원의 실제 모습

잠시만요. 지금 예측 돌아가는 중이에요...

프로젝트 내용 중 코드 작성 업무를 맡은 인턴사원은 모델 프로토타입 생성 후, Test 데이터에 대한 예측이 진행되는 동안 바닥에 무릎을 꿇고 기도를 하고 있었다. 그랬다. 시간이 지나 별 것 아닌 것처럼 적어 내려가고 있지만 제발 0.6만 되면 좋겠다는 프로젝트 멤버들의 마음은 참으로 간절했다. 간절한 기도가 통했던 것일까? 8,000개 문장만으로 학습 진행한 분류 모델의 Accuracy 성능 지표는

Label 1(관심유발) : 0.83

Label 2(내용구성) : 0.77

Label 3(현업적용) : 0.91

("현업적용"은 reflection 세션을 통해 보다 명확한 분류를 위해 "유용성"으로 라벨 명이 변경되었다.)

그야말로 대박이었다. 기억이 맞다면 무릎을 꿇고 있던 인턴 아이는 기쁨의 비명을 질렀던 것 같다. 어쨌든 작업 방식이 통한다는 것을 확인했으니 더는 망설일 것이 없었다. 남은 3일 간 남아 있는 모든 데이터를 각자에게 할당하고 무한 라벨링 공장을 돌리기 시작했다. 비록 첫날의 멘붕은 있었으나 우여곡절 끝에 라벨링 작업은 무사히 끝낼 수 있었다. 어느새 수많은 문장들이 눈과 손에 익은 8명의 학생들은 제법 빠른 속도로 마치 기계처럼 라벨링을 해내었고, 그 사이 나의 역할은 그들이 지치지 않도록 간식을 잘 채워주는 것과 라벨링 작업이 진행되는 강의장 내에 너무 신나지도 너무 쳐지지도 않는 BGM이 흘러가도록 하는 것이었다. 그리고 프로토타입 모델의 성능을 확인한 기쁜 날 저녁에는 조용히 법인카드를 쥐어주고 이천 시내에서 그들 간의 전우애를 다지는 기회도 마련해 주었다. 그 덕인지 어느새 8명의 학생들은 서로 많이 친해져 라벨링 마지막 날에는 먼저 끝낸 사람이 작업 분량이 남아 있는 몇몇을 말로는 놀려가면서도 손으로는 십시일반 아직 라벨이 분류되지 않은 문장을 가져다가 다른 이들의 몫까지 더해가며 무사히 끝내는 아름다운 모습을 볼 수 있었다. 10만 개를 목표로 한 작업이었으나 최종 데이터의 수가 무려 131,479개에 달하였으니 모두에게 매우 치열하고 생산적인 한 주를 보냈다고 판단된다.

GPU, shut up and take my money!!

8인의 전사는 떠났고, 그들의 피땀 어린 131,479개의 라벨링 데이터와 함께 모든 준비는 끝났다. 이제 분류 모델 학습을 진행할 시간이 되었다.

여기서 잠깐!

분류 모델이라고 하니 마치 하나의 문장을 분류하는 모델을 돌리면 그중 어느 라벨에 해당하는지를 분류하는 모습을 상상해 볼 수 있겠으나 내용 기준 3개의 라벨과 긍부정을 포함했을 때, 4지선다의 모델인 경우 상식적으로도 성능이 매우 떨어질 수 있다. 따라서 스마트해 보이지만 성능이 떨어지는 모델 방식이 아닌 우리가 정한 각각의 라벨에 해당하는지를 확인하는 바이너리 방식의 모델 4개를 생성하기로 하였다. 즉, 프런트엔드 상에서 AI라는 말은 멋진 모습을 기대하기 마련이나 사실 사용자들은 결과의 정확성에 더 관심이 있기 때문에 백엔드 상에서는 보다 정확한 모델을 선택한 것이다.

3개의 라벨과 긍부정까지 총 4개의 모델에 모든 문장을 학습시켜야 했기에 총 4대의 게이밍 노트북에서 라벨 명만 바꾼 형태로 분류 모델을 학습시키는 코드를 실행하였다. 그리고 마치 하늘로 날아갈 것만 같이 하염없이 돌아가는 노트북의 팬 소음. 작업의 속도를 봤을 때, 퇴근 시간 전에는 안될 것 같아서 슬립 모드를 해제한 상태에서 퇴근하기로 한다.

다음 날 아침. 밤새 무사히 학습을 마쳤길 기대하고 출근을 했지만 밤사이 노트북이 뻗었다. Colab 무료 환경에서는 일일 사용 시간제한으로 전체 데이터에 대한 학습 도중 GPU가 터지는 현상이 발생하기에 미약하지만 게이밍 노트북의 GPU 성능을 믿고 하루를 기다렸건만 Numpy 버전 등이 이유로 밤사이 노트북이 학습을 거부한 것이다. 남은 선택지는 결국 현질. AWS와 Colab을 고민한 끝에 일단 4대의 PC에서 동시에 작업해서 한 달 안에 구독 종료 하면 되는 일이라 총 4개의 계정에서 Colab Pro+ 를 구독하고 동시에 재학습을 진행하였다.

Colab 요금제 구분

돈을 들였으니 마음 편히 진행되는 것이 맞겠으나 구독 전 몇 번 노트북이 뻗는 일을 겪을 후라 Colab 구독 후에도 딱히 안심이 되지는 않았다. 그리고 Colab의 경우 구독 여부에 따라 달라지는 것은 일일 GPU 사용 시간제한이 해제되는 것일 뿐 그 안에서 소위 빠릿빠릿한 GPU가 배정되는 것은 랜덤이라 지금 할당된 GPU가 얼마나 믿을만한 것인지에 대한 불신이 있었다. 아무튼 그렇게 퇴근 전 학습을 걸어두고 퇴근. 아침에 출근해 보니 이미 두 인턴들은 노트북 앞에 앉아 있었다. 그리고 혹시나 밤사이 또 문제가 생기는 것은 아닐까 싶어 새벽에도 한 번 와서 잘 돌아가고 있는지 학습 진행 현황을 확인했었다고 했다. 아무튼 나는 시킨 적이 없으니 주인의식에서 비롯한 자발적 야근이었다고 생각하고 있다.

Colab 결제 후, 그렇게 밤사이 4개의 모델 학습이 완료되었다. 그리고 대망의 예측(Predict) 단계!! 8,000개 문장으로 진행했던 지난 모델 프로토타입 당시에는 예측까지 꽤 긴 시간이 필요했기에 13만 개에 달하는 데이터를 활용한 예측 결과는 당연히 내일쯤에나 확인할 수 있을 거라고 생각했다. 하지만 예상과 달리 단 33분 만에 작업이 완료되었다. 역시 데이터 분석 작업에는 고생할 필요 없이 템빨이 최고이고 현질이 짱이다!!

최종 분류 모델, 그 결과는?

데이터 분석 공부를 할 때부터 늘 해온 생각이지만 사실 모델이 일하는 모습은 새로운 데이터를 쌓아서 실전 적용하기 전까진 어디까지나 직관적이지 않은 말 그대로 기계의 영역이다. 따라서 중요한 것은 내가 생성한 이 기계가 제대로 학습을 했는지에 대한 성능 평가 결과이며, 그 결과 지표에 따라 믿고 사용할지 여부를 판단하게 된다.

4개 분류 모델에 대한 성능 평가 결과

교육 참가자들이 남긴 정성 의견을 읽는 사람의 관점에 따라 미묘하게 다르게 받아들일 수 있다는 작업의 난이도를 고려했을 때, 전반적인 결과지표는 믿고 사용하기에 전혀 문제가 없는 수준이라고 생각이 들었다. 솔직히 문제없는 수준이라는 표현은 이제 와서 겸손하게 표현한 것 같고, 적어도 결과 지표를 처음 확인한 순간의 느낌대로라면 너무나도 훌륭하다는 생각을 했었다. 이 프로젝트에 대한 멘토링을 진행해 주신 대학원 지도교수님과 결과를 두고 얘기해 봤을 때에도 자연어 처리의 난이도 상 보통 75점만 되어도 쓸만하다는 전문가 의견을 미리 확인한 상태에서 그 수준을 훨씬 상회하는 모델이기에 프로젝트팀에서는 일종의 해냈다는 감정을 느꼈었다.

그럼에도 불구하고 보수적인 관점에서 바라봤을 때, 두 번째 라벨인 내용구성을 분류하는 모델은 나머지 모델에 비해 성능이 떨어진다는 생각을 했다. 아무래도 사용자 피드백을 고려했을 때, 어느 하나 빠릿빠릿하지 않다는 느낌을 주고 싶지 않았기에 모델의 신뢰도를 검증하기 위해 도메인 전문가로서 라벨링 완료된 문장 중 100개를 랜덤 하게 추출하여 다시 한번 직접 라벨링 하고 모델의 예측 결과와 비교해 보았다. 약 13년의 HRD 경력을 믿고 진행한 일종의 블라인드 테스트였는데 그 결과...

8명의 학생이 랜덤 추출한 100개 문장에 대해 이미 라벨링을 해둔 상태였기에 정답이 있는 문제였으나 내가 라벨링 한 결과 그중 70%만 그들의 라벨과 동일한 것을 확인할 수 있었다. 모델의 분류 예측 정확도가 .745임을 감안했을 때, 마음에 들지 않을 수는 있어도 어쨌든 내가 직접 분류했을 때보다 나은 성능임을 확인하고 내용구성 분류 모델 또한 신뢰하는 것이 낫겠다는 생각을 하게 되었다. 실제로 라벨링 작업 진행 중 커뮤니케이션을 진행한 Slack 채널 상에도 내용구성 라벨에 대한 말들이 많았기에 해당 라벨을 분류하는 것이 실제로 작업 난이도가 가장 높았던 탓으로 해석해 볼 수 있을 것 같다.

일단 처음 기획 의도를 살려 훌륭한(!) 모델 생성까지는 마쳤는데, 실제 업무 개선을 위해서는 어떤 작업을 진행해야 할까? 다음 포스팅에서는 분류 모델을 거부감 없이 업무에 적용하기 위해 정성 의견을 다루는 새로운 개념을 고안해 낸 이야기와 실제 사용 장면에서의 반응, 프로젝트의 의의 등에 대한 내용을 적어 보도록 하겠다.