LLM 단일 프롬프트와 다단계 프롬프트: 작업을 나누는 기준

짧은 메모에서 제목 하나 뽑는 일에 ‘분석가 → 검토자 → 편집자’ 세 역할을 붙이면 절차가 결과보다 커진다. 반대로 뉴스 여러 건을 읽고 선별·요약·출처 확인·브리핑까지 만드는 일은 한 번의 긴 요청으로 끝내면 어느 단계에서 사실이 바뀌었는지 찾기 어렵다.

한 번의 프롬프트로 충분한 작업은 무엇일까?

입력이 작고 목표가 하나이며 결과를 바로 눈으로 확인할 수 있다면 단일 요청부터 시작하자. 예를 들어 아래 메모의 제목을 만드는 데는 중간 산출물을 저장할 이유가 크지 않다.

입력: 화요일부터 새 버전을 순차 배포한다. 전체 완료일은 미정이다.
요청: 사실을 추가하지 말고 한국어 제목 하나를 제안해 주세요.

새 버전, 화요일부터 순차 배포처럼 원문에 있는 사실만 담으면 된다. 배포 완료라는 제목이 나오면 요청을 늘리기 전에 입력과 출력의 불일치를 바로 고칠 수 있다. 단일 요청의 장점은 호출·검토 지점이 적다는 것이다.

다단계 프롬프트는 언제 필요한가?

이제 여러 기사에서 주요 항목을 고르고, 각 기사 내용을 요약해, 한 장의 브리핑으로 합친다고 하자. 여기에는 서로 다른 실패가 숨어 있다. 중요한 기사를 잘못 고를 수 있고, 요약에서 원문 밖의 사실이 들어갈 수 있으며, 최종 형식에서 출처 링크가 빠질 수 있다.

이런 경우에는 단계마다 무엇을 검사할지가 분명하다. 단계 수가 많아서 좋은 게 아니라, 문제가 나면 되돌아갈 위치가 보이는 것이다.

중간 산출물은 어떻게 테스트할까?

같은 기사 목록에 사실이 하나 빠진 짧은 기사를 넣어 보자. 선별 단계에서 원문을 벗어난 기사나 제목을 만들지 않았는지, 요약 단계에서 빠진 사실을 추측하지 않았는지, 편집 단계에서 출처가 누락되지 않았는지 각각 확인한다. 마지막 결과만 읽으면 ‘그럴듯한 브리핑’이 어느 단계에서 틀렸는지 알기 어렵다.

중간 결과를 다음 단계에 넘길 때는 필요한 필드만 정리하고, 기사 원문과 연결될 식별자를 유지한다. 요약 문장을 여러 번 모델에 다시 쓰게 하면 표현은 매끄러워질 수 있지만 원문과 멀어질 기회도 늘어난다. 실패한 단계만 다시 수행할 수 있는지, 사람 검토가 필요한 지점은 어디인지도 정하자.

운영 비용과 보안은 어디서 달라질까?

다단계는 호출 횟수, 처리 시간, 저장할 중간 자료가 늘어난다. 민감한 원문을 매 단계에 통째로 넣거나 로그에 보관하면 노출 범위도 커진다. 단순 작업은 단일 요청으로 시작하고, 오류를 분리해 검사할 필요가 확인될 때만 단계를 추가하자. 다단계에서도 각 단계의 모델 출력이 원문 사실의 증거가 되는 것은 아니다.

핵심 요약

한 가지 결과를 바로 검토할 수 있다면 단일 프롬프트가 간결하다. 선별·요약·편집처럼 실패 원인이 다른 작업은 단계별 산출물과 확인 질문을 둔다. 단계를 늘릴수록 검증 지점뿐 아니라 비용·지연·자료 노출도 늘어난다는 점을 함께 판단하자.