개발 slecs

크롤 콘텐츠 재구성을 2단계로 나눴더니 품질이 올랐다

목차

최근에 크롤링한 콘텐츠를 재구성하는 파이프라인을 2단계로 분리했다. 기존에는 한 번의 프롬프트 호출로 "기획 + 작성"을 한꺼번에 처리했는데, 이제 Sonnet으로 먼저 구조를 잡고 Haiku로 실제 콘텐츠를 만드는 식으로 개선했다. 같은 입력인데도 결과물이 더 고유하고 일관성 있게 나오니까, 이제는 이렇게 하는 게 기본이 될 것 같다.

왜 2단계로 나눴나: 단일 호출의 한계

기존 방식을 돌아보면, LLM 호출 한 번으로 "이 크롤 텍스트를 재구성하고 고유 콘텐츠로 만들어"라는 요청을 던졌다. 이 방식의 문제점은 몇 가지였다.

먼저, 모델이 동시에 너무 많은 것을 고민해야 한다. 콘텐츠의 구조를 잡으면서 동시에 글쓰기 톤을 맞추고, 핵심을 강조하고, 문법을 다듬어야 하니까 모델의 인지 부하가 높다. 특히 크롤링한 텍스트가 투박하거나 불완전할수록 이런 일이 더 심하다. 또한 한 번의 호출로는 "처음부터 다시 생각하기" 같은 재시도가 어렵다. 애초 프롬프트가 모호하면 결과물 품질이 그냥 그 수준에서 고정된다.

그리고 비용이다. 크롤 콘텐츠가 많을 때 매번 강력한 모델(예: Claude 3.5 Sonnet)을 써서 처리하는 건 비효율적이다. 전체 작업 중 실제로 "고급 추론"이 필요한 부분은 초반의 구조화 정도인데, 말 다 한 후에도 계속 비싼 토큰을 쓰고 있었던 것.

2단계 전략: 역할 분담

그래서 파이프라인을 나눴다.

단계 담당 모델 역할 특징
1단계: 기획 Claude Sonnet 원문 분석, 핵심 추출, 구조 설계 추론 능력 높음, 모호함 처리 잘함
2단계: 작성 Claude Haiku 기획된 구조대로 콘텐츠 생성 빠르고 비용 효율적, 지시 따르기 정확

1단계 (Sonnet 기획):
- 크롤한 원문을 받아서 "이 콘텐츠의 핵심이 뭔지, 어떤 구조로 재구성하면 좋을지" 분석
- 섹션 구성, 강조할 포인트, 톤 가이드를 명확하게 출력
- 이걸 구조화된 형태(예: JSON)로 내보냄

2단계 (Haiku 작성):
- 1단계의 기획 결과물을 받음
- "이 구조대로, 이 톤으로, 이 포인트를 강조해서 글을 써줘" 라는 명확한 지시
- 실제 콘텐츠 텍스트 생성

이렇게 분리하면 각 모델이 잘할 수 있는 일에만 집중한다. Sonnet은 "생각하기"에만 쓰고, Haiku는 "지시받은 대로 빠르게 실행"하는 데 최적화된다.

배운 점: 멀티스테이지의 강점

실제로 이렇게 적용하면서 느낀 것들이다.

1. 명확한 지시가 품질을 좌우한다. Haiku가 받는 2단계 프롬프트가 1단계에서 명확하게 나올수록, Haiku의 결과물이 일관되고 품질 높다. "대충 좋게 써줘"보다 "섹션은 이렇고, 이 포인트는 반드시 포함하고, 톤은 이렇게"가 나으니까 당연한 결과지만, 놀라운 건 이 명확함 자체가 1단계에서 성숙해진다는 것. 즉, Sonnet이 "진짜 구조화를 강제로 해야 하니까" 더 깊이 생각한다.

2. 비용 vs. 품질 트레이드오프를 다룰 수 있다. 기획 단계는 그냥 하나 해놓으면 다시 쓸 수도 있고, 필요하면 더 좋은 모델을 쓸 수도 있다. 반면 작성 단계는 "그냥 지시 따르면 되는" 작업이니까 가벼운 모델으로도 충분하다. 예를 들어 비용을 줄여야 하면 1단계에만 리소스를 쓸 수 있다.

3. 재시도와 실험이 쉽다. 기획만 바꾸고 작성을 다시 돌릴 수도 있고, 다른 톤으로 다시 써볼 수도 있다. 매번 전체 파이프라인을 재구성할 필요가 없다.

결국 이건 소프트웨어 아키텍처와도 같은 이야기다. 한 덩어리를 여러 단계로 나누면, 각 단계의 책임이 명확해지고, 유지보수도 쉬워지고, 최적화 포인트도 생긴다. 모델 선택, 비용, 품질이 모두 더 세밀하게 제어 가능해진다. 앞으로 크롤 처리 말고도 이런 패턴을 생각해볼 여지가 많을 것 같다.


🛒 이 글과 어울리는 추천 상품

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.

댓글 0

첫 댓글 달아줘.