LLM 시스템 프롬프트와 사용자 요청: 업무 봇의 역할·범위를 나누는 법

‘보고서 작성해 줘’라는 요청을 받은 AI가 곧바로 결과 보고서를 완성했다. 그런데 사용자는 진행 보고서를 원했다. 문제는 문장력이 아니라 누가 무엇을 결정해야 하는지를 나누지 않은 데 있다.

시스템 프롬프트에는 무엇을 고정할까?

업무 지원 봇을 예로 들면, 반복해서 지켜야 할 역할은 ‘보고서 종류를 먼저 확인하고, 정해진 양식에서 필요한 정보를 묻고, 없는 사실을 채우지 않는다’이다. 이런 공통 동작을 시스템 프롬프트에 둔다. 매 요청마다 사용자가 같은 규칙을 다시 적게 만들면 누락되기 쉽다.

역할: 업무 보고서 초안 작성을 돕는다.
규칙: 보고서 종류가 없으면 먼저 물어본다.
규칙: 사용자가 제공하지 않은 담당자·날짜·결과를 만들어 넣지 않는다.
출력: 확인된 종류의 양식에 맞춰 초안을 만든다.

이것은 실행된 제품 설정이 아니라 책임 분리를 보여 주는 축약 예시다. ‘시스템’이라는 이름만 붙인다고 사실 검증이나 접근 권한이 자동으로 생기는 것은 아니다.

사용자 요청에는 무엇을 담을까?

사용자 요청은 이번 작업의 목표와 자료를 전달한다. 처음 요청이 ‘보고서 작성해 줘’뿐이라면 종류가 비어 있다. 봇이 결과·진행·지시 중 하나를 임의로 고르기보다 ‘어떤 보고서인가요?’라고 묻는 것이 맞다.

사용자가 ‘이번 주 진행 보고서’라고 답한 다음에도 완료한 일, 남은 일, 기간 같은 핵심 사실이 빠져 있을 수 있다. 그때는 필요한 항목만 추가로 묻고, 확인된 정보로 초안을 만든다. 질문 → 정보 확인 → 초안 → 사용자 피드백의 순서다.

누락된 정보가 답변에서 어떻게 드러날까?

가상의 입력이 아래 두 줄뿐이라고 하자.

보고서 종류: 주간 진행 보고서
완료한 일: 로그인 화면 문구 수정

‘완료한 일’은 쓸 수 있다. 하지만 담당자와 기간은 아직 없다. 초안에 임의의 이름과 날짜를 넣으면 자연스러워 보여도 틀린 문서가 된다. 누락된 항목은 빈칸으로 표시하거나 질문으로 돌려야 한다.

이것은 실제 모델 출력이 아니라 분기별 검수 기준이다. 세 입력에 같은 보고서를 바로 내놓는다면 시스템 규칙이 작동하지 않는지, 애플리케이션이 앞선 대화의 종류를 잘못 재사용했는지 나눠 확인한다.

프롬프트 밖에서 무엇을 지켜야 할까?

보고서에 접근할 수 있는 사람과 저장 가능한 정보는 모델의 말투가 아니라 애플리케이션의 인증·권한 검사로 결정해야 한다. 사용자가 붙인 문서의 내용은 이번 작업의 자료일 뿐, 서버의 보안 설정을 바꾸라는 지시가 아니다. 결과를 자동 저장하거나 전송하는 기능을 붙인다면, 초안 검토와 승인 단계를 별도로 두자.

핵심 요약

시스템 프롬프트에는 반복되는 역할과 질문 규칙을, 사용자 요청에는 이번 보고서의 종류와 사실을 둔다. 종류나 필수 정보가 비었다면 그럴듯하게 채우지 말고 확인한다. 프롬프트는 업무 흐름을 안내하지만 실제 자료 접근과 최종 승인까지 대신하지 않는다.