11장. 요약, 재작성, 분류 기능 만들기

화려한 에이전트보다 먼저, 작은 텍스트 기능부터

LLM 서비스라고 하면 많은 사람이 먼저 "스스로 판단하고, 검색하고, 도구를 호출하고, 일을 끝내는 에이전트"를 떠올린다. 하지만 실제로 돈이 되고, 매일 쓰이고, 장애가 적고, 운영이 쉬운 기능은 의외로 훨씬 소박하다. 긴 문서를 짧게 정리해 주는 요약, 같은 뜻을 더 나은 문장으로 바꿔 주는 재작성, 들어온 텍스트를 적절한 카테고리로 보내는 분류가 바로 그런 기능이다.

이 세 가지는 겉보기에는 단순하다. 하지만 서비스 관점에서 보면 아주 중요하다. 요약은 읽는 시간을 줄여 주고, 재작성은 사용자의 산출물을 바로 개선해 주며, 분류는 업무 흐름 자체를 자동화한다. 고객 문의를 예로 들어 보자. 상담 내용을 세 줄로 요약하고, 긴급도를 분류하고, 답변 초안을 정중한 톤으로 재작성하는 것만으로도 이미 꽤 쓸 만한 AI 서비스가 된다.

이 장의 핵심은 간단하다. 대부분의 상용 LLM 기능은 거대한 자율 시스템에서 출발하지 않는다. 잘게 쪼갠 텍스트 처리 기능에서 출발한다. 그리고 이 작은 기능들을 정확하게 설계하는 팀이 결국 더 튼튼한 제품을 만든다.

기능을 모델이 아니라 작업 단위로 정의하라

요약, 재작성, 분류를 구현할 때 가장 흔한 실수는 "모델에게 알아서 잘해 달라"고 맡기는 것이다. 서비스에서는 그렇게 하면 안 된다. 기능은 작업 단위로 정의해야 한다.

각 기능은 최소한 다음 다섯 가지를 먼저 정해야 한다.

• 입력은 무엇인가

• 출력은 어떤 형식인가

• 절대 바뀌면 안 되는 정보는 무엇인가

• 실패로 간주할 조건은 무엇인가

• 사람 검토가 필요한 경계는 어디인가

예를 들어 "요약"도 하나가 아니다. 회의록 요약과 뉴스 요약은 다르다. 회의록은 결정 사항, 담당자, 다음 액션이 중요하고, 뉴스 요약은 핵심 사건과 맥락이 중요하다. "재작성"도 하나가 아니다. 맞춤법 교정, 문체 정리, 고객 친화적 표현 변환, 쉬운 말로 풀어쓰기, 검색용 질의 재구성이 모두 다른 작업이다. "분류" 역시 감성 분석, 카테고리 분류, 우선순위 판정, 정책 위반 탐지처럼 목적이 제각각이다.

좋은 설계는 그래서 항상 이렇게 묻는다.

"이 기능이 어떤 문장을 얼마나 바꾸어야 하며, 무엇은 반드시 보존해야 하는가?"

이 질문에 답하지 못하면, 아직 구현을 시작할 때가 아니다.

요약 기능 설계: 짧게 만드는 일보다, 중요한 것을 남기는 일

자동 요약은 오래된 분야지만, LLM 덕분에 훨씬 유연해졌다. 전통적으로 요약은 원문 문장을 골라 붙이는 추출식 요약, 새로운 문장으로 다시 써 주는 생성식 요약, 둘을 섞는 혼합형 요약으로 나뉜다. LLM은 이 세 방식을 상황에 따라 유연하게 오갈 수 있다는 점이 큰 장점이다.¹

서비스에서는 먼저 "무슨 요약인가"를 정해야 한다. 많은 팀이 여기서 너무 빨리 구현으로 들어간다. 하지만 요약은 길이보다 목적이 먼저다.

짧은 기사 요약이라면 한두 문단의 자연스러운 생성식 요약이 좋다. 반면 계약서나 정책 문서처럼 사실 보존이 중요한 경우에는 원문 표현을 최대한 유지하는 추출식 또는 혼합형 요약이 더 안전하다. 회의록은 보통 자유 서술보다 구조화된 출력이 낫다. 예를 들면 핵심 논의, 결정 사항, 담당자, 기한, 미해결 이슈 같은 칸으로 나누는 편이 훨씬 실용적이다.

요약 기능을 설계할 때 꼭 정해야 할 옵션은 다음과 같다.

• 요약 길이: 한 줄, 세 줄, 한 문단, 자세한 요약

• 요약 관점: 경영진용, 실무자용, 고객용, 법무 검토용

• 보존 규칙: 숫자, 날짜, 고유명사, 금액, 인용문 유지 여부

• 출력 형식: 문단, 목록, 표, JSON

• 누락 방지 항목: 액션 아이템, 리스크, 결론, 반대 의견

여기서 중요한 점이 하나 있다. 사용자는 대개 "짧게"를 원하지만, 실제로는 "빨리 판단할 수 있게"를 원한다. 그래서 좋은 요약 기능은 단순 압축기가 아니라 의사결정 보조 도구에 가깝다.

긴 문서 요약은 한 번에 넣지 말고 전략적으로 나눠라

문서가 길어지면 단순 프롬프트 한 번으로 끝내기 어렵다. 이때 흔히 쓰는 방법이 두 가지다. 하나는 문서를 여러 조각으로 나눠 각각 요약한 뒤 마지막에 다시 합치는 map/reduce 방식이고, 다른 하나는 앞부분 요약을 뒤 문단 정보로 계속 다듬는 iterative refinement 방식이다. 전자는 병렬화가 쉬워 빠르고, 후자는 흐름을 이어 가는 데 유리하다.²

실무에서는 대체로 이렇게 생각하면 된다.

문서 조각들이 비교적 독립적이고 처리 속도가 중요하면 map/reduce가 낫다. 예를 들어 여러 개의 고객 리뷰, 긴 회의 전사본, 장문의 리포트 챕터 요약에 잘 맞는다. 반대로 문맥이 앞뒤로 이어져야 하고, 중간 축약 결과가 다음 부분 해석에 영향을 주는 문서라면 refinement가 더 자연스럽다.

다만 chunking, 즉 문서 분할은 생각보다 중요하다. 문단 경계를 무시하고 기계적으로 끊으면 요약 품질이 금방 떨어진다. 가능하면 제목, 섹션, 발화 단위, 표 단위처럼 의미 경계에 맞춰 자르는 편이 좋다. 긴 회의록이라면 발언자 단위로 끊고, 정책 문서라면 조항 단위로 끊는 식이다.

또 하나 잊지 말아야 할 것은 "요약의 요약"에서 정보가 두 번 손실된다는 점이다. 그래서 중간 요약에는 지나친 문학성을 주지 않는 편이 좋다. 중간 단계는 최대한 사실 중심으로, 마지막 단계에서만 사람이 읽기 좋은 문장으로 다듬는 방식이 안전하다.

재작성 기능 설계: 문장을 고치는 것이 아니라 의도를 보존하며 바꾸는 일

재작성은 서비스에서 아주 강력한 기능이다. 사용자가 직접 쓴 초안을 더 읽기 좋게 바꿔 주기 때문이다. 이메일, 공지, 마케팅 카피, 고객 응답, 공고문, 사내 문서, 블로그 초안까지 거의 모든 텍스트가 대상이 된다.

하지만 재작성은 "비슷하게 다시 써 줘" 정도로 던지면 금방 사고가 난다. 숫자가 바뀌고, 어조가 과장되고, 책임 소재가 흐려지고, 법적으로 민감한 표현이 누락될 수 있다. 그러므로 재작성은 항상 변환 축을 명확히 지정해야 한다.

대표적인 변환 축은 이렇다.

• 톤: 정중하게, 친근하게, 단호하게, 차분하게

• 스타일: 간결하게, 자세하게, 공식 문서처럼, 채팅처럼

• 난이도: 초등학생도 이해하게, 비전공자용으로, 전문가용으로

• 형식: 이메일, 공지문, FAQ 답변, 제목 + 본문, 요점 정리

• 보존 규칙: 의미 유지, 숫자 유지, 고유명사 유지, 마크다운 유지

좋은 재작성 프롬프트는 거의 항상 "무엇을 바꿀지"와 "무엇을 바꾸지 말지"를 함께 말한다. 예를 들어 "문장을 더 정중하게 바꾸되, 날짜·금액·제품명은 절대 바꾸지 말고, 원래 의미를 유지하라" 같은 식이다.

이 기능은 사용자 가치가 아주 직접적이다. 사용자는 결과를 보고 바로 체감한다. "내가 쓴 문장이 더 좋아졌다"는 느낌은 대단히 강력하다. 그래서 많은 AI 글쓰기 서비스가 사실상 재작성 엔진을 포장한 제품이다.

흥미로운 점은 재작성이 검색 성능 개선에도 쓰인다는 것이다. 검색 증강 생성에서 사용자의 모호한 질문을 더 검색 친화적인 질의로 다시 쓰면, 검색 결과와 최종 응답 품질이 함께 좋아질 수 있다. 즉 재작성은 글쓰기 보조 기능이면서 동시에 검색 파이프라인의 전처리 기능이기도 하다.³

재작성 기능에서 특히 조심할 것들

재작성이 쉬워 보여도 운영 단계에서는 의외로 까다롭다. 이유는 간단하다. 결과가 "대체로 좋아 보이지만 미묘하게 위험한" 경우가 많기 때문이다.

예를 들어 고객 응대 문장을 부드럽게 바꾸다가 환불 보장처럼 들리는 표현이 들어갈 수 있다. 채용 공고를 더 매력적으로 바꾸다가 차별적 뉘앙스가 생길 수도 있다. 기술 문서를 쉽게 풀어쓰다가 정확성이 떨어질 수도 있다.

그래서 재작성에는 검증 규칙이 필요하다. 최소한 다음 검사를 붙이는 편이 좋다.

• 숫자, 날짜, URL, 제품명, 사람 이름 변경 여부 검사

• 금지 표현 포함 여부 검사

• 길이 변화 비율 검사

• 원문 대비 의미 이탈 가능성 검사

이 검사는 모두 LLM으로만 할 필요는 없다. 정규식, diff 비교, 키워드 일치, 금칙어 필터만으로도 많은 문제를 막을 수 있다. 서비스는 늘 "모델의 감각"보다 "시스템의 안전장치"가 강해야 한다.

분류 기능 설계: 생성형 모델을 쓸수록 오히려 더 단단한 스키마가 필요하다

분류는 가장 과소평가된 기능 중 하나다. 하지만 제품 운영에서는 정말 많이 쓴다. 문의 티켓을 팀으로 라우팅하고, 리뷰를 주제별로 묶고, 신고 게시물을 위험도별로 나누고, 세일즈 리드를 온도별로 분류하는 일은 전부 분류 문제다.

분류 기능은 먼저 라벨 체계를 설계해야 한다. 이 작업을 소홀히 하면 모델을 아무리 바꿔도 결과가 안정되지 않는다.

좋은 라벨 체계는 다음 조건을 만족해야 한다.

• 서로 가능한 한 겹치지 않는다

• 사람이 봐도 구분 기준을 설명할 수 있다

• 업무 흐름에서 바로 행동으로 이어진다

• 애매한 입력을 위한 기타 또는 판단 불가가 있다

예를 들어 고객 문의를 결제, 환불, 계정, 버그, 기능 요청으로 나눌 수 있다. 그런데 여기서 끝내면 실무에선 부족할 때가 많다. 보통은 여기에 긴급도, 감정 상태, VIP 여부, 법무 검토 필요 여부 같은 축이 추가된다. 그러면 분류는 하나의 라벨이 아니라 여러 속성을 뽑는 구조화 추출에 가까워진다.

이 지점에서 생성형 모델의 장점이 나온다. 단일 정답 하나를 찍는 대신, 라벨과 이유, 확신도, 추가 메타데이터를 함께 뽑을 수 있다. 다만 이럴수록 출력 스키마를 단단히 고정해야 한다. 문자열로 두루뭉술하게 받으면 후처리가 매우 힘들어진다.

실무에서는 보통 이런 필드를 함께 받는다.

• label: 최종 분류 라벨

• confidence: 0~1 또는 low/medium/high

• reason: 짧은 근거

• needs_human_review: 사람 검토 필요 여부

• secondary_labels: 보조 라벨 목록

여기서 핵심은 모르면 모른다고 하게 만들기다. 서비스 운영에서 가장 위험한 분류기는 자신만만한 오답을 내는 분류기다.

세 기능을 하나의 공용 파이프라인으로 묶기

요약, 재작성, 분류는 각각 달라 보이지만 구현 구조는 꽤 비슷하다. 그래서 서비스 내부에서는 공용 파이프라인을 두고, 바깥에는 기능별 API를 분리하는 방식이 좋다.

외부 API는 다음처럼 단순하게 나누면 된다.

• POST /text/summarize

• POST /text/rewrite

• POST /text/classify

이렇게 하면 프론트엔드와 다른 백엔드 팀이 이해하기 쉽다. 반면 내부 구현은 공통 모듈을 많이 공유할 수 있다. 예를 들어 입력 정규화, 길이 검사, 민감정보 마스킹, 모델 선택, 재시도, 구조 검증, 로깅, 캐싱은 세 기능 모두 거의 같다.

실제 텍스트 처리 도구들도 이런 식으로 요약, 분류, 재작성 같은 기능을 별도 메서드로 제공한다. 겉보기에는 작은 유틸리티처럼 보여도, 서비스 설계 관점에서는 이 방식이 매우 합리적이다.⁴

공용 파이프라인은 대체로 이런 순서로 흘러간다.

1. 입력 정규화

2. 정책 검사와 민감정보 처리

3. 작업 유형별 프롬프트 조립

4. 모델 호출

5. 출력 검증과 후처리

6. 로깅과 메트릭 적재

이 구조의 장점은 분명하다. 나중에 모델을 바꾸거나 멀티 벤더 전략을 적용해도, 기능 정의와 운영 규칙은 그대로 유지할 수 있다.

처음부터 거대한 범용 엔드포인트를 만들지 마라

처음 구현할 때 흔히 POST /ai/process 하나로 모든 걸 처리하고 싶어진다. 물론 내부적으로는 그렇게 만들 수 있다. 하지만 외부에까지 그 추상화를 드러내면 금방 혼란스러워진다.

클라이언트 입장에서는 summarize, rewrite, classify가 명확하다. 입력 옵션도 각각 다르다. 요약은 길이와 관점이 중요하고, 재작성은 톤과 보존 규칙이 중요하며, 분류는 라벨 집합과 confidence가 중요하다. 기능별 엔드포인트는 문서화와 테스트, 권한 정책, 비용 통제 면에서도 유리하다.

정리하면 이렇게 가져가면 좋다.

외부는 작업별 API, 내부는 공용 실행 엔진.

이 패턴은 단순하지만 오래 간다.

프롬프트는 길게 쓰는 것보다, 제약을 정확히 쓰는 것이 중요하다

이 장의 주제가 구현인 만큼, 각 기능의 프롬프트도 실무적으로 생각해야 한다. 핵심은 화려한 문구가 아니라 제약 조건이다.

요약 프롬프트는 보통 다음 요소를 포함하면 안정적이다. 원문, 요약 목적, 길이 제한, 반드시 포함할 항목, 금지 사항, 출력 형식이다. 예를 들어 회의록이라면 "결정 사항과 담당자, 마감일을 빠뜨리지 말 것" 같은 문장이 중요하다.

재작성 프롬프트는 변환 목표와 보존 규칙을 함께 써야 한다. "더 친절하게"만 쓰지 말고 "의미 유지, 숫자와 제품명 보존, 마크다운 구조 유지"를 함께 적는다.

분류 프롬프트는 정의가 핵심이다. 라벨 이름만 주지 말고, 각 라벨의 판정 기준과 경계 사례를 짧게 넣어야 한다. 예를 들어 버그와 기능 요청은 자주 헷갈리므로, "원래 되어야 하는 동작이 안 되면 버그, 원래 없던 기능을 요구하면 기능 요청"처럼 기준을 미리 적어 두면 성능이 크게 안정된다.

이때 few-shot 예시를 조금 넣는 것도 도움이 된다. 다만 예시가 너무 많아지면 특정 표현에 과적합될 수 있으니, 대표적인 애매한 케이스 위주로 소수만 두는 편이 낫다.

작은 기능일수록 모델 선택을 더 냉정하게 하라

많은 팀이 요약, 재작성, 분류에도 가장 비싼 모델을 기본값으로 쓴다. 하지만 이 세 기능은 오히려 비용 최적화가 잘 먹히는 영역이다.

분류는 대개 짧은 입력과 짧은 출력이므로 빠르고 저렴한 모델이 잘 맞는다. 재작성은 체감 품질이 중요하므로 문장력이 좋은 모델이 유리하다. 요약은 문서 길이와 사실성 요구에 따라 모델 선택이 갈린다. 긴 문서 요약은 컨텍스트 크기보다도 chunking 전략과 출력 검증이 더 중요할 때가 많다.

실무 감각으로 말하면, 기능별로 기본 모델을 따로 두는 편이 좋다. 그리고 실패 시에만 더 비싼 모델로 올리는 계단형 전략을 쓰면 비용과 품질을 함께 잡기 쉽다. 예를 들어 분류 confidence가 낮을 때만 상위 모델로 재판정하거나, 긴 문서 요약에서 중간 단계만 저렴한 모델로 처리하고 마지막 정리만 상위 모델로 맡기는 식이다.

평가 기준도 기능마다 달라야 한다

LLM 텍스트 기능은 "왠지 괜찮아 보인다"로 운영하면 반드시 흔들린다. 기능마다 평가 기준을 따로 둬야 한다.⁵

요약은 다음을 봐야 한다. 핵심 사실이 유지됐는지, 중요한 항목이 빠지지 않았는지, 불필요한 추측이 들어가지 않았는지, 사용 목적에 맞는 길이인지가 중요하다. 회의 요약이라면 액션 아이템 재현율이 특히 중요하다.

재작성은 의미 보존이 1순위다. 그다음이 톤 적합성, 가독성, 문법 정확도다. 사용자가 원한 변화가 실제로 일어났는지와, 일어나지 말아야 할 변화가 생기지 않았는지를 동시에 봐야 한다.

분류는 전통적인 정확도뿐 아니라 오분류 비용을 함께 봐야 한다. 예를 들어 일반 문의를 긴급 장애로 잘못 올리는 것보다, 긴급 장애를 일반 문의로 내리는 실수가 훨씬 비싸다. 그래서 confusion matrix를 보고, 라벨별 임계값을 따로 조정하는 편이 낫다.

또 하나 중요한 지표가 있다. 바로 보류율이다. 모델이 애매할 때 사람에게 넘기는 비율이다. 서비스에서는 무조건 자동화율만 높이는 것이 정답이 아니다. 위험한 오답을 줄이기 위해 적절한 보류율을 유지하는 편이 훨씬 건강하다.

실전 예시: 고객지원 AI는 어떻게 세 기능을 묶는가

하나의 예시로 묶어 보자. 사용자가 긴 문의 메일을 보냈다고 하자.

먼저 요약 기능이 메일 전체를 세 줄로 압축하고, 핵심 문제와 이전 대화 이력을 정리한다. 다음으로 분류 기능이 결제 문제, 긴급도: 높음, 감정 상태: 불만, 법무 검토: 아니오를 뽑아 티켓을 적절한 큐로 보낸다. 마지막으로 재작성 기능이 상담사가 쓴 투박한 초안을 고객 친화적이면서도 과장되지 않은 답변으로 다듬는다.

이 조합은 에이전트처럼 보일 수 있지만, 실제론 세 개의 작은 기능이 순서대로 연결된 것뿐이다. 바로 이 점이 중요하다. 복잡해 보이는 AI 업무 흐름도, 뜯어 보면 대부분은 이런 기본 기능의 조합이다.

출시 초기에 특히 유용한 운영 팁

작은 기능이라고 가볍게 보면 안 된다. 오히려 이런 기능은 사용량이 많아 금방 운영 이슈로 이어진다.

초기 운영에서는 다음 원칙을 지키는 것이 좋다.

• 프롬프트 버전을 기능별로 관리한다

• 입력 샘플과 실패 케이스를 꾸준히 저장한다

• 출력 길이, 오류율, 재시도율, 사람 수정률을 측정한다

• 특정 고객군이나 도메인에서 성능이 급락하는지 본다

• UI에서 사용자가 쉽게 재시도하거나 수동 수정할 수 있게 한다

특히 재작성 기능은 사용자가 직접 손볼 수 있는 인터페이스가 중요하다. AI가 한 번에 완벽하게 쓰는 것보다, 80점짜리 초안을 빠르게 만들고 사람이 20점을 채우는 편이 현실적이다. 요약도 마찬가지다. 한 번에 완전한 답을 주기보다, "짧게 보기 / 자세히 보기 / 원문 근거 보기" 같은 계층형 UI가 훨씬 만족도가 높다.

결국 강한 서비스는 기본 기능을 잘 만든다

요약, 재작성, 분류는 화려하지 않다. 하지만 바로 그래서 강하다. 사용자는 이 기능들을 매일 반복해서 쓰고, 기업은 이 기능들 덕분에 시간을 아끼고, 팀은 이 기능들로부터 데이터와 운영 감각을 얻는다.

이 장에서 꼭 기억해야 할 문장을 하나만 남기자.

작고 분명한 텍스트 기능이, 크고 모호한 AI 제품보다 먼저 돈을 번다.

다음 장에서는 이 기본 기능을 한 단계 확장해, 외부 지식을 붙이는 검색 증강 생성, 즉 RAG의 기초로 넘어가 보자. 재작성으로 검색 질의를 다듬고, 요약으로 검색 결과를 정리하고, 분류로 적절한 문서를 고르는 순간부터 이미 우리는 더 큰 시스템의 입구에 서 있게 된다.

참고

¹A Comprehensive Survey on Automatic Text Summarization with Exploration of LLM-Based Methods

²Long document summarization with Workflows and Gemini models

³Query Rewriting for Retrieval-Augmented Large Language Models

d_llm-text](https://github.com/patrols/ruby_llm-text)

⁵LLM Summarization: Getting To Production