AI 업무 요청, 긴 설명보다 필요한 조건을 분리해서 쓰기

회의 메모에서 후속 작업을 찾는다면 배경을 요약하는 줄글보다 담당·기한·상태가 연결된 목록이 필요할 수 있다. AI 요청은 결과를 어디에 쓸지 정하는 데서 시작한다. 목적, 근거 자료, 남길 의미와 출력 구조를 나누고 잘못된 결과를 수정할 기준을 만든다.

요청서를 목적·자료·출력으로 나눈다

먼저 결과를 어디에 쓸지 적는다. 내부 검토용 초안, 고객에게 보내는 안내, 자료 비교표는 필요한 정확도와 형식이 다르다. 이어 사용할 자료를 구분하고 원문에서 확인되지 않는 부분을 어떻게 처리할지 지정한다.

Google Cloud의 프롬프트 설계 안내는 명확한 지시와 맥락, 예제 등 설계 요소를 설명한다. 특정한 마법 문구가 모든 결과를 보장하는 것은 아니며, 실제 입력 자료와 목적에 맞춰 요청을 구성해야 한다.

처음부터 모든 항목을 복잡하게 만들 필요는 없다. 반복하는 업무에서 오류가 생긴 부분을 기준으로 요청을 보완한다. 자료가 없는 상태에서 ‘완벽하게 조사해 줘’라고 적는 것보다 어떤 사실을 어디서 확인해야 하는지 명시하는 편이 검토에도 도움이 된다.

자료의 문장과 작업 지시를 섞지 않는다

문서 안에는 예시 명령문, 이메일 인용, 다른 사람의 요청이 들어 있을 수 있다. 자료를 통째로 붙여 넣었을 때 그 문장을 자신의 작업 지시로 처리해도 되는 것은 아니다. 요청서에서 원자료 구역과 수행할 지시를 나누면 역할을 명확하게 전달할 수 있다.

예를 들어 문서에는 ‘초안을 승인 처리하라’는 과거 이메일이 있어도, 현재 작업이 회의 내용 추출이라면 그것은 추출할 자료의 일부다. 실제 승인 행동을 맡긴 것이 아니다. 자료를 읽는 작업과 외부에 제출하거나 실행하는 작업은 별도의 범위로 정한다.

이 구분만으로 모든 입력 위험이나 모델 오류가 해결되지는 않는다. 외부 자료를 사용하는 작업에서는 결과에 실제로 어떤 지시가 반영됐는지 확인하고, 계정 변경이나 공개 발행처럼 결과가 외부에 영향을 주는 단계는 따로 검토한다.

같은 자료로도 필요한 결과가 달라지는 요청을 비교한다

가상의 회의 메모에서 ‘다음 주 화면 변경 검토’, ‘운영의 문의 유형 정리’, ‘금요일 자료 공유’라는 내용이 나왔다고 하자. ‘회의를 요약해 줘’라는 요청은 배경 설명을 포함한 줄글을 만들 수 있다. 일정 점검이 목적이라면 줄글보다 확정 작업, 담당 역할, 기한, 아직 결정하지 않은 항목을 나누는 표가 더 유용하다. 먼저 결과의 쓰임을 정해야 출력 형식도 선택할 수 있다.

요청에 ‘각 항목의 원문 문장과 연결하고, 제안은 결정으로 바꾸지 말라’고 적으면 결과에서 무엇을 확인해야 할지도 정해진다. 담당자의 실명이 자료에 없을 때는 역할만 남기도록 할 수 있다. 그러나 원문에 역할조차 없다면 그 칸은 미정이어야 한다. 모든 칸을 채우는 것과 쓸 수 있는 기록을 만드는 것은 같지 않다.

출력 분량도 쓰임에 맞춰 정한다. ‘세 줄로’만 지정하면 조건을 줄여 버릴 수 있으므로 ‘실행 조건과 미정 상태는 유지한 채 세 항목으로’처럼 남길 의미를 함께 적는다. 분량을 맞추기 위해 필요한 사실이 빠졌다면 문장 수를 늘리는 선택도 가능하다. 짧음 자체가 업무의 목적은 아니다.

결과가 틀렸다면 요청보다 입력 상태가 문제인지 본다

표의 숫자가 다른 열로 붙었다면 문구를 강하게 바꾸기 전에 입력 자료가 제대로 추출됐는지 확인한다. 원문 표를 줄글로 복사하면서 셀 관계가 사라졌다면 요청서를 자세하게 적어도 그 관계를 되살리기 어렵다. ‘더 정확히 읽어라’는 수정 대신 표 제목, 행·열 제목, 단위와 주석을 함께 제공해야 할 수 있다.

결정 상태가 틀렸다면 앞선 제안만 입력하고 뒤의 수정 발언을 빠뜨렸는지도 본다. 필요한 문맥을 덜 준 문제가 요청 표현의 문제처럼 보일 수 있다. 입력과 요청을 구분해 점검하면 반복 수정의 방향이 달라진다.

수정 요청은 확인한 오류 하나와 기대하는 결과를 연결한다. ‘화면 변경은 미정인데 확정 작업으로 적었다. 운영의 문의 유형 정리만 확정 작업으로 남기고 화면 변경은 후속 판단 목록으로 옮겨라’처럼 적을 수 있다. 이 문장은 실제 모델 출력의 사례가 아니라 수정 지시를 직접 구성한 예시다.

반복 업무에서는 이런 오류 유형을 요청서에 반영하되 지시를 무한히 늘리지는 않는다. 같은 뜻의 경고를 여러 번 붙이기보다 목적, 자료, 필수 의미, 출력 구조의 충돌을 정리한다. 간결한 요청서의 기준은 글자 수가 아니라 다음 사람이 입력과 결과를 대조할 수 있는가에 있다.

설명용 요청서: 회의 메모에서 후속 작업을 추출한다

다음은 실무 요청을 구성하기 위해 직접 만든 예제다. 실제 회의 자료나 실행 결과는 아니다.

목적: 내부 일정 점검에 사용할 후속 작업 목록을 만든다. 자료: 아래에 제공한 회의 메모만 사용한다. 작업: 확정한 일과 검토 중인 제안을 구분한다. 출력: 작업, 담당 역할, 기한, 상태, 근거 문장 순서의 표로 작성한다. 담당자나 기한이 없으면 ‘미정’으로 표시한다. 원문에 없는 이름과 날짜는 추정하지 않는다.

이 요청서는 짧지만 결과를 확인할 기준이 있다. 원문에 담당자가 없는데 특정 이름이 나왔다면 바로 검토할 수 있고, 제안을 확정 작업으로 바꿨는지도 표의 상태에서 확인할 수 있다.

실제 메모를 넣기 전에는 자료 취급 조건을 확인한다. 업무에 필요하지 않은 개인 정보나 기밀 내용을 제거할 수 있는지 검토하고, 문서 입력 사본 준비의 항목을 함께 적용한다.

한 번에 초안 작성과 최종 검증을 맡기지 않는다

자료 추출, 초안 작성, 사실 대조, 표현 다듬기를 나누면 어느 단계에서 문제가 생겼는지 찾기 쉽다. 첫 결과가 자연스럽다는 이유로 최종 검증까지 끝난 것으로 판단하지 않는다.

초안에서 중요한 주장에 원문 위치를 붙이게 할 수 있지만, 실제 원문에 해당 내용이 있는지는 직접 확인해야 한다. AI에게 ‘검증 완료’라는 문구를 붙이게 하는 것이 사실 확인은 아니다. AI 답변의 근거 대조에서 링크와 주장 사이의 관계를 검토하는 방법을 설명한다.

정답을 예시로 줄 때도 의도한 형식을 보여주는 자료인지, 실제 판단의 답인지 구분한다. 예시의 이름이나 숫자를 결과에 그대로 복사하지 않았는지 살핀다. 형식을 알려 주기 위한 가상 데이터라면 그 점을 요청서에 명시한다.

수정할 때는 결과의 어떤 문제를 고칠지 지정한다

‘더 잘해 줘’라는 지시만 반복하면 길이와 톤만 바뀌고 사실 오류는 남을 수 있다. 누락된 적용 조건, 잘못 연결된 수치, 원문에 없는 추정 등 확인한 문제를 구체적으로 적는다. 변경한 결과를 다시 원문과 대조한다.

반복 업무라면 입력 자료와 요청서, 결과, 실제 수정한 부분을 함께 보관한다. 오류가 매번 비슷한지 살펴보고 요청서를 개선할 수 있다. 다만 예전 자료에 맞춘 지시를 새 업무에 그대로 적용하면 범위가 달라질 수 있으므로 목적과 자료 종류를 다시 확인한다.

Microsoft의 결과 평가 안내는 읽기 좋은 표현과 정확성·맥락 평가를 함께 다룬다. 자신의 업무에서도 형식이 맞는지, 근거가 있는지, 필요한 조건이 남았는지를 분리해 확인하는 편이 좋다.

요청서는 결과를 보장하는 장치가 아니라 작업 범위와 확인 기준을 정하는 도구다. 목적과 근거, 출력의 의미가 분명하면 결과가 잘못됐을 때 어디를 다시 확인해야 하는지도 알기 쉬워진다.