GPT가 당연히 잘할 줄 알았는데
어느 날 챗봇 서비스를 맡고 있는 쪽에서 데이터 처리 관련 상의가 들어왔다.
수만 건의 고객 발화를 주제별로 정리하고 싶은데, 생각보다 분류가 잘 안 된다는 이야기였다.
처음에는 건수가 너무 많아서 그런가 싶었다.
그래서 데이터를 조금씩 잘라서 GPT에 물어보라고 했다. 발화를 몇백 개씩 나눠서 넣고, 분류 기준도 같이 적어 주면 어느 정도는 정리될 거라고 생각했다.
그런데 결과는 예상과 달랐다.
그렇게 잘라서 물어봐도 분류가 계속 엉망이었다. 비슷한 발화가 다른 주제로 흩어지고, 실제로 보고 싶은 기준과는 전혀 다른 묶음이 자꾸 나왔다.
처음에는 프롬프트가 부족한가 싶었다.
그래서 분류 기준을 더 자세히 적고, 예시를 넣고, 애매한 경우는 어떻게 보라고 설명도 덧붙였다. 그런데도 끝까지 쓸 만한 분류가 잘 나오지 않았다.
한참 파고들어 보고 나서야 이상한 점이 보였다.
평소에는 꽤 잘해 보이던 LLM도, 실제 회사 텍스트 업무에서는 의외로 잘 안 되는 일이 있다는 점이었다. 특히 이렇게 경계가 애매하고, 예외가 많고, 분류 결과를 바로 실무에 써야 하는 일에서는 더 그랬다.
평소에는 성능 부족을 느끼기 어렵다
일반적인 사용에서는 LLM 성능이 부족하다고 느낄 일이 많지 않다.
긴 글 요약, 문장 다듬기, 초안 작성, 회의록 정리 같은 일에서는 지금도 꽤 쓸 만하다.
그래서 회사 텍스트 데이터 업무도 웬만하면 다 될 것처럼 보인다.
실제로도 어느 정도까지는 맞다.
문제는 회사 업무에서는 “그럴듯함”보다 “틀리지 않음”이 더 중요해지는 순간이 많다는 점이다.
일상적인 사용에서는 조금 어색해도 넘어갈 수 있지만, 업무에서는 누락이나 오분류 하나가 뒤 단계를 다 흔들 수 있다.
잘 되는 업무와 잘 안 되는 업무는 생각보다 다르다
LLM이 잘 되는 텍스트 업무는 대체로 이런 쪽이다.
- 긴 문서 요약
- 초안 작성
- 문체 통일
- 회의록 정리
- 대략적인 1차 태깅
- 비정형 텍스트에서 큰 패턴 찾기
이런 일들은 정답이 아주 빡빡하게 고정돼 있지 않다. 결과가 조금 다듬어지거나 표현이 바뀌어도 큰 문제 없이 쓸 수 있다.
반대로 잘 안 되는 쪽은 이런 일이다.
- 경계가 애매한 분류
- 여러 문서의 값 대조
- 코드값이나 식별자 보존
- 작은 차이가 큰 의미를 가지는 검토
- 포맷이 정확히 맞아야 하는 추출
여기서는 말을 잘 만드는 능력보다, 누락 없이 맞추는 능력이 더 중요해진다.
잘 안 되는 대표적인 케이스 1: 고객 발화 주제 분류
앞에서 나온 사례가 가장 대표적이다.
겉으로 보기에는 쉬워 보인다. 고객 발화를 읽고 주제를 붙이면 되니까, LLM이 잘할 것처럼 느껴진다.
그런데 실제 업무에서는 분류 기준이 그렇게 단순하지 않다.
- 표면적으로는 환불 문의지만 실제로는 정산 이슈인 경우
- 배송 문의처럼 보이지만 계정정책 문제인 경우
- 한 문장 안에 불만, 버그 신고, 사용법 문의가 같이 들어 있는 경우
이런 경계 케이스가 많아지면 분류가 금방 흔들린다.
LLM은 문장을 읽고 그럴듯하게 이름을 붙이는 데는 강하지만, 실무에서 쓰는 기준에 맞게 일관되게 나누는 일은 생각보다 약하다.
이렇게 쓰면 조금 나아진다
- 한 번에 최종 분류까지 맡기지 않는다
- 1차로 넓은 카테고리만 나누게 한다
- 자주 헷갈리는 경우는 정해둔 기준으로 다시 걸러본다
- 회사에서 실제로 쓰는 표현과 예시를 충분히 붙인다
- 분류 결과를 바로 쓰지 말고 일부는 사람이 직접 다시 본다
즉, “알아서 깔끔하게 분류해 주겠지”보다는 “1차 정리를 빨리 해 주는 보조 도구”로 써야 한다.
잘 안 되는 대표적인 케이스 2: 텍스트처럼 보이지만 사실은 데이터인 경우
텍스트를 다룬다고 생각했는데, 실제로는 텍스트가 아니라 데이터인 경우가 꽤 많다.
예를 들면 이런 값들이다.
- 주문번호
- 고객코드
- 상품코드
- 계정 ID
- 계약번호
문장 안에 들어 있어도, 이 값들은 자연어보다 식별자에 가깝다.
문제는 LLM이 이런 걸 설명하거나 요약하는 과정에서 종종 값을 뭉개거나 바꾸거나, 중요하지 않다고 판단하고 덜어내 버린다는 점이다.
사람 입장에서는 한 글자만 바뀌어도 안 되는 값인데, 모델 입장에서는 비슷한 문자열로 보이기 쉽다.
이렇게 쓰면 조금 나아진다
- 코드값은 설명 대상이 아니라 원문 보존 대상으로 다룬다
- 추출과 요약을 한 번에 시키지 않는다
- 코드 필드는 별도 구조로 빼서 대조한다
- 가능하면 엑셀 열이나 별도 칸으로 분리해서 원문 그대로 비교한다
여기서는 LLM이 직접 값을 만지는 역할보다, 정리된 결과를 읽기 쉽게 설명해 주는 역할이 더 안전하다.
잘 안 되는 대표적인 케이스 3: 여러 문서를 한꺼번에 대조하는 일
한 문서를 요약하는 일은 잘 된다.
그런데 회사 업무는 종종 한 문서만 보는 일이 아니다.
공지문, 내부 가이드, FAQ, 메일 안내문, 정책 문서를 같이 놓고 서로 맞는지 봐야 하는 일이 많다.
이때 어려운 건 내용 이해 자체보다 차이를 정확히 찾는 일이다.
- 날짜가 다른지
- 조건이 다른지
- 책임 주체가 다른지
- 예외 문장이 빠졌는지
이런 건 한 문장씩 보면 사소해 보이는데, 실제 운영에서는 꽤 큰 차이를 만든다.
LLM은 문맥을 자연스럽게 이어 읽는 데는 강하지만, 여러 문서의 작은 차이를 안정적으로 대조하는 일은 아직 자주 놓친다.
이렇게 쓰면 조금 나아진다
- 먼저 문서를 항목 단위로 쪼갠다
- 자유 요약보다 비교표 생성으로 시킨다
- 대조할 축을 먼저 정해 준다
- 충돌 여부는 사람이 최종 확인한다
즉 “읽고 차이 알려줘”보다 “날짜, 금액, 예외 조건만 표로 비교해 줘”가 훨씬 낫다.
결국 회사 업무에서는 왜 더 자주 한계를 느끼게 될까
이쯤 되면 이상한 점이 하나 남는다.
평소에는 꽤 잘해 보이는 모델이 왜 회사 일에만 오면 갑자기 손이 많이 갈까.
이유는 생각보다 단순하다.
일반적인 사용에서는 괜찮은 답이면 충분한 경우가 많다. 요약이 조금 어색해도 뜻만 통하면 넘어간다.
그런데 회사 업무는 다르다.
- 누락되면 안 되고
- 경계 기준이 맞아야 하고
- 값이 그대로 살아 있어야 하고
- 나중에 다시 봐도 같은 결과가 나와야 한다
즉, 자연어를 잘 다루는 능력만으로는 부족한 순간이 많다.
회사 텍스트 업무는 겉으로는 글을 읽고 쓰는 일처럼 보여도, 실제로는 분류, 비교, 보존, 예외 처리에 더 가깝다.
그래서 일반적인 활용에서는 LLM 성능이 부족하다고 느낄 일이 잘 없지만, 업무 중에는 의외로 그런 순간을 자주 만나게 된다.
그래도 쓸모가 없는 건 아니다
이런 이야기를 하면 곧바로 “그럼 회사에서는 LLM이 아직 소용없는 거냐”는 쪽으로 가기 쉽다.
그건 또 아니다.
오히려 회사 업무에서 잘 쓰려면, 모델이 잘하는 일과 잘 못하는 일을 더 분명하게 나눠서 써야 한다.
- 요약은 맡기고
- 초안은 맡기고
- 비슷한 내용끼리 대충 묶는 일은 맡기고
- 최종 분류와 대조는 사람이나 정해둔 기준으로 다시 확인하는 식이다
한마디로 정리하면 이렇다.
LLM은 회사 텍스트 업무를 통째로 대신하기보다, 중간에 제일 손이 많이 가는 부분을 줄여 주는 쪽에서 더 쓸 만하다.
그걸 모르고 바로 최종 판단까지 맡기면 실망하기 쉽고, 그 선을 잘 나눠서 쓰면 여전히 꽤 큰 도움이 된다.
관련 글
같은 맥락에서 이어서 읽기 좋은 글들입니다.