안녕하세요. 저는 현재 GS Retail 상품정산IT팀에서 프로모션 및 심의/QA 프로세스 개발/운영 업무를 담당하고 있는 이민기입니다.
입사 후 가장 주력으로 진행한 심의 프로세스 개선 Digital Tool 개발에 관련하여 진행 과정과, 어떤 기술을 사용하여 프로세스 개선을 이루어 내었는지에 대해 회고해 보려고 합니다.
상품 사전심의?
저희 GS Retail의 온라인 매장 중 하나인 gsshop.com에는 매일 많은 양의 상품이 새로 등록됩니다. 각 상품들은 "이미지 기술서"를 가지고 있는데요, 이미지 기술서란 이미지의 형태를 한 상품 정보의 한 유형으로 상품에 대한 자세한 설명을 이미지로 표현한 상품 상세 설명서를 말합니다. 이 이미지 기술서들은 gsshop.com 의 상품 페이지에 올라가게 되고, 직접 고객에게 노출됩니다.
이러한 이미지 기술서는 각 업체가 상품을 등록할 때 한 장, 또는 여러 장의 이미지 url 형태로 함께 등록됩니다. 하지만 모든 이미지 기술서가 바로 고객에게 노출될 수 있는 것은 아닙니다.
특정 카테고리의 상품들은 심의 규정에 따라 문제가 되는 단어가 포함되는지, 해당 카테고리 상품에 사용할 수 없는 표현이 포함되어있는지 등을 확인하기 위해 사전 심의를 거쳐야 합니다. 이미지 기술서 또한 이러한 과정에서 심의를 거치게 되는데요, 이 부분에서 프로세스적 비효율이 발생하고 있었습니다.
기존 프로세스
기존의 심의 프로세스는
- 업체가 등록한 상품이 인입된 후
- 심의 대상 상품군에 대해 심의 담당자가 직접 상품의 이미지 기술서를 하나씩 눈으로 확인하여
- 내용 중 심의상 문제가 될 수 있는 키워드의 존재 여부를 찾고
- 존재 여부에 따라
- 존재시 → 심의 결격사항 작성 후 반려
- 아닐 시 → 다음 상품 등록 프로세스로 진행
의 과정을 거쳐야만 했습니다.
이러한 프로세스 상에서는 심의 담당자가 일일이 이미지를 눈으로 확인해야만 하기 때문에 심의에 많은 시간이 소요되고, 이에 따라 하루에 등록할 수 있는 상품의 총량이 제한(심의 담당자 1인당 일 100건 ~ 200건 정도의 처리가 한계)될 수밖에 없었습니다.
또한, 심의 담당자의 실수로 인해 문제성 키워드가 정상적으로 걸러지지 않고 그대로 매장에 노출될 위험성이 존재하였습니다.
이러한 비효율과 문제점을 개선하기 위해 첫 번째 심의 프로세스 개선 프로젝트가 진행되었습니다.
1차 프로세스 개선
우선, 프로젝트 진행에 앞서 심의 프로세스를 사전심의, 사후심의 두 가지로 분류하였습니다.
사전심의는
- 상품이 최초 인입될 때, 미리 등록해 둔 상품 카테고리별 문제어 목록과의 비교를 통해 이미지 기술서가 심의상 적합한지 확인하여 상품 등록 승인 여부를 결정하는 과정
사후심의는
- 이미 온라인 매장에서 판매중인 상품에 대해, 새롭게 추가된 문제어의 존재 여부 확인 또는 전수검사 등 다양한 요인에 따른 점검 과정
두 가지로 분류한 심의 프로세스 모두 "이미지 기술서상의 문제성 키워드 존재 여부를 확인" 해야만 했으므로 저희는 다음과 같은 과정을 통해 프로세스를 자동화하였습니다.
- 심의 대상 상품을 확인
- 대상 상품의 이미지 기술서 목록 추출
- OCR(Optical character recognition)을 활용하여 이미지에서 텍스트를 추출
- 추출한 텍스트와 기존에 등록하여 관리하고 있는 각 상품 카테고리별 문제성 키워드 사전 대조
- 해당 상품의 이미지 기술서에 문제성 키워드가 존재하는지 확인
- 존재 시 → 어떤 키워드가 검출되었는지 반환
- 반환된 결과를 바탕으로 심의 담당자가 직접 확인 및 결격사항 작성, 반려
- 존재하지 않을 시 → 자동 승인
- 존재 시 → 어떤 키워드가 검출되었는지 반환
광학 문자 인식(Optical character recognition; OCR)은 사람이 쓰거나 기계로 인쇄한 문자의 영상을 이미지 스캐너로 획득하여 기계가 읽을 수 있는 문자로 변환하는 것이다.
이 프로젝트의 첫 번째 목표인 "이미지 기술서 상의 문제성 키워드 존재 여부를 확인" 의 자동화를 위해서는, 첫 번째로 이미지에서 텍스트를 추출하는 과정이 필수적이었습니다.
이를 위해 OCR Sass 중 하나인 Google Cloud Vision의 Document Text Detection을 활용하여 등록된 이미지 기술서의 내용을 텍스트로 추출할 수 있었습니다.
이러한 과정을 거쳐 심의 자동화 프로세스, M심의봇이 탄생하게 되었습니다.
2차 프로세스 개선
1차 프로세스 개선 작업 완료 후, 테스트를 거쳐 실제 심의팀의 업무에 적용한 결과 처음 생각과는 달리 다량의 상품을 처리하는 데 상당히 많은 시간이 소요되는 것을 확인하였습니다.
최초 개발을 진행할 때 Node.js의 Promise.all 메서드를 통해 Google vision에 비동기 병렬 요청으로 Google Cloud Vision에 OCR을 요청하도록 설계하였는데, 마치 순차 수행을 한 것처럼 모든 요청이 처리되기까지 너무 오래 걸렸던 것입니다.
Promise.all() 메서드는 순회 가능한 객체에 주어진 모든 프로미스가 이행한 후, 혹은 프로미스가 주어지지 않았을 때 이행하는 Promise를 반환합니다. 주어진 프로미스 중 하나가 거부하는 경우, 첫 번째로 거절한 프로미스의 이유를 사용해 자신도 거부합니다.
이러한 문제점을 개선하기 위해 저희는 두 가지 개선 방안을 적용하기로 하였습니다.
첫 번째 개선 방안은, AWS Lambda를 활용하여 다량의 데이터 병렬 처리에서 발생하는 부하를 자동 Scaling 하는 것입니다.
AWS에서 제공하는 서버리스 컴퓨팅 서비스인 Lambda는 부하가 발생할 때 자동으로 Sacle-out 합니다.
[전략]...스케일 아웃이란 접속된 서버의 대수를 늘려 처리 능력을 향상시키는 것이다. 수평 스케일로 불리기도 한다...[중략]...스케일 아웃은 개개의 처리는 비교적 단순하지만 다수의 처리를 동시 병행적으로 실시하지 않으면 안 되는 경우에 적합한데 갱신 데이터의 정합성 유지에 대한 요건이 별로 어렵지 않은 경우에 적절하다. 즉 높은 병렬성을 실현하기 쉬운 경우이다.
이러한 특성을 가진 AWS Lambda를 활용함으로써 저희가 개선하고자 하는 병렬 요청 제한을 개선할 수 있을 것이라고 생각하였습니다.
두 번째 개선 방안은, Frontend에 구현되어 있던 Google Vision API 요청부를 Backend로 이전하는 것입니다.
Lambda를 적용한 이후에도 여전히 제한적인 처리량을 보였던 원인을 분석한 결과, 다음과 같은 문제점을 확인할 수 있었습니다.
모든 웹 브라우저에는 한 호스트 당 최대 동시 처리 개수의 제한이 있다. 따라서, 병렬로 다량 처리 요청을 하더라도 브라우저의 최대 동시 처리 개수만큼의 제한을 두고 병렬 요청이 수행된다.
기존 개발 편의성을 위해 Frontend에서 직접 Google Vision API에 OCR 요청을 수행하였는데, 웹 브라우저 자체적인 동시 처리 제한으로 인해 완벽한 병렬 처리가 수행되지 못하고 있었습니다. Lambda를 적용한 후에야 비로소 이러한 문제점을 발견할 수 있었던 것입니다.
DT 과제 선정과 3차 프로세스 개선
성공적인 2차 프로세스 개선 작업 이후, 실제 사용자의 요청에 따라 소소한 기능 개선을 거듭하던 M심의봇의 3차 개선 프로젝트가 사내 DT(Digital Transformation) 프로젝트로 선정되었습니다.
기존의 M심의봇은 OCR을 통해 추출한 텍스트에 사용자가 입력한 검출어 또는 기존에 작성한 문제어 단어장의 키워드를 대조하여 판단하였습니다.
이러한 검출 방법은 문장의 콘텍스트와는 무관하게 단순히 해당 키워드가 '존재하는지' 여부만을 확인하므로 심의 규정에 전혀 결격사항이 없는 상품까지도 반려되거나, 반려되어야만 하는 상품이 정상 등록되는 등 다양한 문제점을 가지고 있었습니다.
이러한 문제점의 개선을 위해 저희는 TA(Text Analysis) 기술을 적용하는 방안을 통해 검출 성능을 개선하기로 결정하였습니다.
TA란 단어 뜻 그대로 형태소 분석, 컨텍스트 분석 등의 과정을 거쳐 자연어로 이루어져 있는 텍스트에서 유의미한 데이터를 뽑아내거나, 사용자가 필요로 하는 정보를 확인할 수 있도록 하는 머신 러닝 기법입니다.
이번 3차 프로세스 개선 프로젝트에서는, M심의봇에 TA를 적용하여 기존 단순 키워드 대조를 통한 문제어 검출에서 벗어나 Context를 포함한 문장 단위 검출 또는 검출 제외를 통한 검출 정확도 개선을 목표로 시작되었습니다.
예를 들어, 기존의 M심의봇에서는 크릴 오일의 상품 기술서에 사용되어서는 안 되는 '몸속 지방을 녹이는'이라는 금지 표현을 검출하기 위해 '지방', '녹이는'이라는 두 단어를 문제어로 설정하여 상품 검출을 시도한다면
- 문지방
- 열대지방
- 손을 따뜻하게 '녹이는'
- 마음을 '녹이는'
- ...
과 같이 원하는 검출 내용과는 전혀 관련이 없는 키워드까지 검출되는 방식이었습니다. 따라서 TA를 적용하여 단어와 단어 간 상관관계를 인식할 수 있다면, '지방~녹이는'의 형태로 검출어를 설정하여 문장 단위로 찾아내고자 하는 대상 문제어만을 더욱 정확하게 검출해낼 수 있게 되는 것입니다.
이러한 필요성에 따라 외부 업체를 선정하고, 업체와 함께 프로젝트를 진행하면서 다음과 같은 아키텍처를 구성하였습니다.
기존 M심의봇에서 Google Vision을 통해 OCR을 수행한 결과를 단순히 검출어와 대조하여 그 결과값을 반환하였다면, 새로운 아키텍쳐에서는 OCR 수행 결과와 사용자가 설정한 검출어를 TA 서버에 전송하여 TA 서버가 분석을 통해 검출 여부를 결정하는 방식으로 변경하였습니다.
또한, 사후 심의의 경우 기존 M심의봇 웹 페이지에서 검출을 요청한 후 검출 결과가 반환될 때까지 로딩 중인 화면을 하염없이 바라보고 있어야 했습니다.
사용자의 사용성 증대를 위해 이를 개선하여 검출 요청 후 요청 성공 메시지를 확인한 사용자는 더 이상 검출 진행에 신경 쓰지 않도록 하는 방안을 고려한 결과, 사내 메신저로 사용 중이었던 워크챗을 활용하여 성공/실패 여부를 받아보고, 이후 사용자가 원할 때 확인할 수 있도록 Callback을 활용하여 구조를 변경하였습니다.
총 3차에 걸친 심의 프로세스 개선 프로젝트를 통해, 심의 업무에 다음과 같은 변화를 만들어낼 수 있었습니다
마치며
입사 후 처음 맡게 된 서비스이자 저의 가장 주된 업무를 담당했던 M심의봇의 발전 과정을 나름대로 간략하게 정리해 보았습니다.
이번 심의 프로세스 개선 프로젝트를 진행하면서 최종 목적을 달성하기 위해 다양한 기술을 적용하고 또 제거하면서 많은 시행착오를 겪었고, 개인적으로도 많은 공부가 되었던 것 같습니다.
앞으로도 M심의봇과 심의 자동화 프로세스가 사용자 요구사항을 적용하면서 점점 더 발전해나가기를 바라는 마음으로 더욱 많은 공부를 통해 지금의 프로세스에 아직도 존재할지도 모르는 비효율을 제거해나가려고 합니다.
참고자료
[출처] ZDNet - 스케일 아웃과 스케일 업 - 서버 처리능력 향상의 길
'Culture' 카테고리의 다른 글
| GS리테일 주니어 개발자 온보딩 (18) | 2023.11.08 |
|---|---|
| Rust 찍어먹기 (11) | 2023.07.10 |
| 개발자는 개발을 하고 싶다! ( 파이썬을 활용한 추출 업무 자동화. Feat. AWS ) (4) | 2022.06.21 |
| [샤피라이브] 1편: WebRTC 기술 적용 스토리 (feat. low-latency) (0) | 2022.01.07 |
| 개발문화.. 문서화.. 프로세스 (1) | 2021.11.18 |