자료 입력의 경계 설정

문서나 이미지를 첨부해 두고 AI에게 일을 맡기면, 사람은 이상하게 안심하게 된다. "자료를 줬으니 이제 정확하겠지." 하지만 실무에서는 딱 그 지점이 가장 위험하다. 자료가 있다고 해서 모델이 자동으로 자료 안에서만 움직이는 것은 아니기 때문이다. 묻는 방식이 흐리면 모델은 빈칸을 메우고, 빠진 연결고리를 상상하고, 때로는 문서에 없는 말까지 자연스럽게 이어 붙인다.

중급 프롬프트에서 중요한 것은 자료를 많이 넣는 일이 아니라, 자료와 답변 사이에 경계선을 긋는 일이다. 어디까지를 근거로 삼을지, 문서에 없는 내용은 어떻게 처리할지, 지금 쓰는 문장이 요약인지 해석인지, 무엇을 근거로 그렇게 말하는지까지 설계해야 한다. 그래야 자료 기반 작업이 똑똑한 즉흥 연기가 아니라, 반복 가능한 실무 절차가 된다.

이번 장에서는 네 가지를 다룬다. 첨부 자료만 근거로 답하게 만드는 법, 자료에 없는 내용을 다루는 법, 요약과 해석을 분리하는 법, 그리고 근거 표시를 습관으로 만드는 법이다. 이 네 가지는 화려해 보이지 않지만, 환각과 과도한 추정을 줄이는 가장 현실적인 안전장치다.

왜 자료가 있을수록 더 엄격한 경계가 필요한가

자료 기반 프롬프트는 보통 더 안전해 보인다. 인터넷 전체를 뒤지는 것보다, 내가 준 보고서나 이미지에만 기대게 하면 더 정확할 것 같기 때문이다. 방향은 맞다. 다만 한 가지 함정이 있다. 모델은 자료를 읽는 동시에, 기존에 학습한 일반 지식과 문맥 추론도 함께 사용하려는 성향이 있다. 그래서 사용자가 경계를 분명히 말하지 않으면, 문서에 없는 상식을 슬쩍 끼워 넣거나 이미지에서 직접 보이지 않는 사실을 자연스럽게 단정해 버릴 수 있다.

예를 들어 정책 문서를 첨부하고 "승인 절차를 정리해줘"라고 말했을 때, 문서에 2차 승인 단계가 빠져 있으면 모델은 친절하게 일반적인 승인 절차를 보완해 넣고 싶어 한다. 제품 사진을 보여 주고 "상품 설명 써줘"라고 했을 때도, 보이지 않는 재질이나 기능을 익숙한 패턴대로 추정하기 쉽다. 말투는 그럴듯하지만, 실무에서는 바로 사고로 이어질 수 있는 종류의 친절이다.

그래서 자료 기반 작업에서는 질문을 잘하는 것보다 사용 가능한 근거의 범위를 먼저 잠그는 것이 중요하다. "무엇을 말할 수 있는가"보다 먼저 "무엇은 말하면 안 되는가"를 정해야 한다. 이 순서를 바꾸면 답변은 부드러워지지만, 검증 가능성은 급격히 떨어진다.

첫 번째 원칙: 자료의 경계를 먼저 선언하라

가장 기본적인 안전장치는 단순하다. 답변의 근거가 되는 자료 범위를 먼저 선언하는 것이다. 이것은 사소한 문장처럼 보이지만, 실제로는 모델의 행동 반경을 정하는 울타리다.

실무에서 자주 쓰는 경계 문장은 대체로 다음 네 종류다.

• 첨부한 자료만 근거로 답하라.

• 지정한 섹션만 읽고 답하라.

• 외부 지식으로 보완하지 마라.

• 자료에 없는 내용은 없다고 표시하라.

이 문장들은 답을 가난하게 만드는 것이 아니다. 오히려 답을 검토 가능한 형태로 바꾼다. 첨부 문서만 보라고 했으면, 나중에 팀원이 원문을 다시 열어 확인할 수 있다. 3장과 5장만 보라고 했으면, 범위가 좁아져 검토 속도도 빨라진다. 외부 지식을 섞지 말라고 했으면, 사실과 상식이 한 문장 안에서 뒤섞이는 일을 줄일 수 있다.

프롬프트를 설계할 때는 범위를 막연하게 적지 말고, 가능한 한 작업 형태에 맞게 써 주는 편이 좋다.

다음 답변은 첨부한 운영 정책 문서만 근거로 작성하라.
범위는 2장 '승인 절차'와 4장 '예외 처리'로 제한한다.
외부 지식, 일반적인 관행, 추정은 사용하지 마라.
문서에 없는 내용은 '문서 근거 없음'으로 표시하라.

이 짧은 문장 안에는 이미 세 가지 장치가 들어 있다. 근거 자료의 종류, 읽을 범위, 문서 밖 내용을 다루는 방식이다. 자료 입력의 경계 설정은 거창한 기술이 아니라, 이런 문장을 빼먹지 않는 습관에서 시작된다.

자료 기반 작업에도 모드가 있다

모든 작업을 똑같이 "첨부 자료만 보라"고 지시할 필요는 없다. 실무에서는 오히려 세 가지 모드를 구분해 두면 훨씬 안정적이다.

첫째는 자료 한정 모드다. 문서 검토, 정책 요약, 계약 조건 정리, 회의록 정리처럼 원문 근거가 가장 중요한 작업에 쓴다. 이때는 자료 밖 지식을 쓰지 않게 막는 것이 핵심이다.

둘째는 자료 우선 모드다. 첨부 자료를 중심으로 답하되, 필요한 경우 일반 지식을 별도 표시로 덧붙이게 하는 방식이다. 예를 들어 교육 자료를 만들거나 고객 설명문을 다듬을 때 유용하다. 다만 이 경우에도 자료 기반 내용과 일반 설명을 섞지 말고 구분해서 내보내야 한다.

셋째는 자료 비교 모드다. 여러 문서나 이미지 사이의 공통점과 차이만 다루게 하는 방식이다. 여기서는 무엇을 비교할지 축을 먼저 고정하고, 자료 밖의 보충 설명을 최소화하는 편이 좋다.

중급 실무자는 이 모드를 구분할 줄 알아야 한다. "AI가 뭘 참고해도 좋다"는 상태는 편해 보여도 재현성이 가장 낮다. 반대로 지금 작업이 어느 모드인지 정해 두면, 팀원이 바뀌어도 같은 기준으로 프롬프트를 사용할 수 있다.

두 번째 원칙: 자료에 없는 내용은 네 가지 상태로 처리하라

자료 기반 작업이 흔들리는 가장 큰 이유는 "없다"는 말을 애매하게 다루기 때문이다. 문서에 없다는 것은 정말 정보가 없다는 뜻일 수도 있고, 내가 지정한 범위 안에는 없다는 뜻일 수도 있고, 표현이 불명확해 확정할 수 없다는 뜻일 수도 있다. 이걸 한 덩어리로 처리하면 답변은 자꾸 뭉개진다.

그래서 실무에서는 자료에 없는 내용을 네 가지 상태로 나누어 다루는 편이 좋다.

이 구분은 생각보다 강력하다. 예를 들어 회의록에서 담당자가 정해지지 않았으면 "없음"이 아니라 "미정" 또는 "추가 확인 필요"가 맞다. 정책 문서에 예외 처리 규정이 아예 없으면 "없음"이 맞을 수 있다. 이미지에서 가격표가 흐려 읽히지 않으면 "불명확"이다. 이런 상태값을 미리 정해 두면, 모델이 애매한 상황을 문장 솜씨로 덮는 대신 작업 상태로 반환하게 된다.

프롬프트에도 이 상태값을 직접 넣을 수 있다.

답변 중 정보가 없거나 확인이 어려운 경우 아래 규칙을 따른다.
- 문서에 항목 자체가 없으면 '없음'
- 현재 지정한 범위에만 없으면 '범위 밖'
- 표현이 애매하면 '불명확'
- 판단이 필요하면 '추가 확인 필요'
임의로 보완하지 마라.

이렇게 해 두면 결과물은 조금 덜 화려할 수 있다. 대신 훨씬 더 실무적이 된다. 실무에서 중요한 것은 매끈한 문장이 아니라, 어디가 비어 있는지 드러나는 답변이다.

확인 질문은 실패가 아니라 설계의 일부다

자료가 불충분할 때 모델이 멋대로 메우지 않게 하려면, 답변 전에 확인 질문을 허용하는 것도 좋은 방법이다. 많은 사람이 확인 질문을 번거롭게 느끼지만, 반복 업무에서는 오히려 비용을 줄인다. 처음에 한 번 되묻는 것이, 틀린 초안을 세 번 고치는 것보다 훨씬 싸기 때문이다.

특히 다음 상황에서는 확인 질문을 기본 동작으로 두는 편이 좋다.

• 읽을 자료는 여러 개인데 우선순위가 정해지지 않았을 때

• 문서 요약인지 판단 의견인지 출력 목적이 불분명할 때

• 이미지 설명인지 정보 추출인지 작업 종류가 섞여 있을 때

• 범위는 좁게 제한했는데 필요한 정보가 그 범위 밖에 있을 가능성이 클 때

예를 들면 이렇게 쓸 수 있다.

지정한 범위 안에서 답을 만들기에 정보가 부족하면, 추정하지 말고 먼저 확인 질문을 3개 이내로 제시하라.
확인 질문 없이도 처리 가능한 경우에만 바로 결과를 작성하라.

이 문장은 모델을 조심스럽게 만든다. 동시에 사용자는 언제 질문이 돌아올지 예상할 수 있다. 자료 기반 작업에서 확인 질문은 성가신 예외가 아니라, 과도한 추정을 막는 기본 브레이크다.

세 번째 원칙: 요약과 해석을 한 문단에 섞지 마라

자료를 다룰 때 가장 자주 일어나는 사고는 사실과 의견이 너무 자연스럽게 붙는 것이다. 문서의 핵심을 요약해 달라고 했더니 슬며시 평가가 섞이고, 이미지에서 보이는 내용을 설명해 달라고 했더니 감정 추정이나 원인 분석이 끼어든다. 읽는 사람은 자연스럽게 받아들이지만, 나중에 보면 어디까지가 자료에 있었고 어디부터가 모델의 해석인지 구분하기 어려워진다.

이 문제를 막는 가장 쉬운 방법은 요약과 해석을 구조적으로 분리하는 것이다. 한 문단 안에서 잘 섞어 쓰게 하지 말고, 처음부터 두 개의 섹션으로 나누게 하라.

예를 들어 문서라면 이렇게 나눌 수 있다.

출력은 두 섹션으로 나눈다.
1. 사실 요약: 문서에 직접 명시된 내용만 작성
2. 해석/시사점: 사실 요약을 바탕으로 한 판단이나 의미 설명
해석 섹션에는 문서에 없는 내용을 단정하지 말고, 판단임을 드러내라.

이미지나 차트도 마찬가지다.

출력 순서:
1. 관찰: 이미지에서 직접 보이거나 읽히는 사실
2. 해석: 그 사실이 의미할 수 있는 점
3. 불확실한 부분: 이미지상 확정할 수 없는 점

이 구분은 별것 아닌 듯하지만, 검토자의 마음을 편하게 한다. 사실 요약만 빠르게 읽고도 업무를 진행할 수 있고, 해석은 참고 의견으로 따로 볼 수 있기 때문이다. 특히 팀 협업에서는 이 차이가 크다. 누군가는 요약만 필요하고, 누군가는 해석까지 필요하다. 둘을 섞어 버리면 모두가 불편해진다.

요약은 줄이는 일이고, 해석은 의미를 붙이는 일이다

두 개념의 차이를 더 분명히 해 두자. 요약은 원문에 있는 내용을 더 짧고 선명하게 만드는 일이다. 해석은 원문이 말하는 바를 읽고, 그 의미나 함의를 설명하는 일이다. 둘 다 필요하지만, 같은 종류의 작업은 아니다.

예를 들어 회의록에 "A안은 비용 부담이 크므로 다음 분기에 재검토한다"라고 적혀 있다면, 요약은 "A안은 비용 문제로 보류되었다" 정도가 된다. 반면 해석은 "단기 예산 제약이 의사결정에 영향을 준 것으로 보인다"처럼 한 걸음 더 나간다. 이 말이 틀린 것은 아닐 수 있다. 하지만 이미 해석의 영역이다.

중급 프롬프트에서는 바로 이 한 걸음을 의식적으로 관리해야 한다. 요약이 필요한 업무에 해석이 끼면 객관성이 흐려지고, 해석이 필요한 업무에 요약만 있으면 활용도가 떨어진다. 그래서 작업 설계 단계에서부터 "이번 결과물은 어디까지가 사실이고 어디부터가 판단인지"를 구분해야 한다.

네 번째 원칙: 근거는 답변의 장식이 아니라 추적 장치다

자료 기반 작업에서 근거 표시는 있으면 좋은 옵션이 아니다. 재현성과 검토 가능성을 만드는 핵심 장치다. 같은 답이라도 근거가 붙어 있으면 원문 확인이 가능하고, 근거가 없으면 말 잘하는 문장으로만 남는다.

여기서 중요한 점은, 근거가 꼭 길고 복잡할 필요는 없다는 것이다. 오히려 실무에서는 가볍고 반복 가능한 방식이 좋다. 문서라면 페이지, 섹션명, 표 제목, 문단 번호 같은 단서를 붙일 수 있다. 이미지라면 좌측 상단, 하단 표, 제목 영역, 차트 범례처럼 위치를 표시할 수 있다. 핵심은 검토자가 다시 돌아갈 수 있는 좌표를 남기는 데 있다.

예를 들어 다음 두 문장은 겉보기엔 비슷하지만 신뢰도는 다르다.

첫 번째: "문서상 승인 단계는 세 단계로 보입니다."

두 번째: "승인 단계는 세 단계로 정리됩니다. 근거: 2장 '승인 절차'의 단계표."

두 번째 문장은 확인 경로가 있다. 그래서 틀렸더라도 고치기 쉽다. 자료 기반 업무에서 좋은 답은 완벽한 답이 아니라, 틀렸을 때도 다시 추적할 수 있는 답이다.

근거 표시도 형식을 정해 두면 흔들리지 않는다

근거 표시가 자꾸 빠지는 이유는 사람들이 필요성을 몰라서가 아니라, 매번 방식이 달라서다. 어떤 날은 인용문을 붙이고, 어떤 날은 페이지를 적고, 어떤 날은 아예 생략한다. 그러면 팀 단위로는 곧 혼란이 생긴다. 따라서 프롬프트 단계에서 근거 형식을 미리 정해 두는 편이 낫다.

문서 작업에서는 보통 다음 중 하나를 택하면 충분하다.

• 섹션명 기준 근거 표시

• 페이지 번호 기준 근거 표시

• 표/그림 제목 기준 근거 표시

• 짧은 원문 구절 기준 근거 표시

이미지 작업에서는 이런 방식이 잘 맞는다.

• 위치 기준: 좌측 상단, 중앙, 하단 표 등

• 요소 기준: 제목, 범례, 버튼, 가격표, 캡션 등

• 관찰 기준: 직접 읽힘, 흐림, 가림, 불명확 등

예를 들어 출력 형식을 이렇게 고정할 수 있다.

각 항목마다 아래를 함께 작성하라.
- 답변
- 근거 위치
- 확실도: 높음/보통/낮음
근거 위치는 문서의 섹션명 또는 이미지의 위치로 표시하라.

여기서 확실도는 근거를 대신하지 못한다는 점도 기억해야 한다. "높음"이라고 써도 근거가 없으면 검토자는 여전히 불안하다. 확실도는 말의 세기를 조절하는 장치이고, 근거는 말의 출처를 남기는 장치다. 둘은 비슷해 보여도 역할이 다르다.

자료 기반 작업에서 자주 쓰는 출력 분리법

경계를 잘 세우려면 출력도 경계에 맞게 나뉘어야 한다. 실무에서 특히 쓸모 있는 구조는 다음과 같다.

사실 / 해석 / 질문

가장 범용적인 구조다. 사실에는 자료에 직접 있는 내용만 넣고, 해석에는 그 의미를 정리하며, 질문에는 아직 확인이 필요한 점을 남긴다. 회의록, 보고서, 차트, 포스터, UI 화면까지 거의 어디에나 붙일 수 있다.

추출값 / 누락값 / 불명확값

표나 JSON처럼 후속 자동화가 필요한 작업에 잘 맞는다. 채워진 값만 보는 것이 아니라, 비어 있거나 애매한 칸도 함께 남기기 때문에 나중에 사람이 보완하기 쉽다.

자료 근거 / 일반 설명

교육 자료나 고객 커뮤니케이션처럼 자료를 바탕으로 쉽게 풀어 설명해야 할 때 유용하다. 먼저 자료에 있는 사실을 적고, 그 다음에 이해를 돕는 일반 설명을 별도 섹션으로 둔다. 이렇게 하면 둘이 섞이지 않는다.

중급 단계에서는 멋진 문장을 만드는 것보다, 이런 출력 구획을 만드는 능력이 더 중요하다. 경계는 입력에서만 세우는 것이 아니라, 출력에서도 다시 한 번 보이게 해야 한다.

문서와 이미지에서 경계 설정은 조금 다르게 작동한다

원칙은 같지만, 문서와 이미지는 흔들리는 지점이 조금 다르다. 문서는 없는 내용을 논리적으로 메우려는 식의 추정이 많고, 이미지는 보이지 않는 속성까지 짐작하려는 식의 추정이 많다.

문서에서는 이런 실수가 자주 나온다. 빠진 문단을 상식으로 채우기, 조건을 단정하기, 앞뒤 문맥을 지나치게 일반화하기. 그래서 문서 프롬프트에는 범위 지정과 근거 위치 표시가 특히 중요하다.

이미지에서는 다른 실수가 잦다. 재질을 단정하기, 감정을 과잉 해석하기, 작게 보이는 글자를 확정적으로 읽기, 일부만 보이는 사물을 전체처럼 설명하기. 그래서 이미지 프롬프트에는 관찰과 해석 분리, 불명확 표시, 보이는 범위 한정이 특히 중요하다.

예를 들어 제품 이미지 작업이라면 이렇게 쓸 수 있다.

첨부 이미지를 보고 상품 설명 초안을 작성하라.
단, 이미지에서 직접 확인 가능한 특징만 사용하라.
재질, 기능, 크기, 구성품은 이미지로 확정할 수 없는 경우 '이미지상 불명확'으로 표시하라.
출력은 1) 관찰된 특징 2) 설명 초안 3) 추가 확인 필요 항목으로 나눈다.

문서든 이미지든 핵심은 같다. 보이는 것과 추정한 것을 섞지 않게 만드는 것이다.

여러 자료를 함께 쓸 때는 우선순위를 정하라

자료가 하나일 때보다 여러 개일 때 문제가 더 커진다. 문서 세 개와 이미지 두 장을 함께 주고 "이걸로 정리해줘"라고 하면, 모델은 무엇을 더 믿어야 하는지 스스로 정해야 한다. 이때 서로 다른 자료 사이에 충돌이 생기면, 어느 쪽을 우선할지 기준이 없어서 결과가 흔들린다.

그래서 다중 자료 작업에서는 우선순위를 먼저 정해야 한다. 예를 들어 회의록이 가장 최신이면 회의록을 우선하고, 정책 문서는 보조 근거로만 쓰게 할 수 있다. 또는 표 형식 데이터가 본문 설명보다 우선이라고 정할 수도 있다.

실무용 문장은 이렇게 만들 수 있다.

자료 우선순위는 다음과 같다.
1. 최신 버전 정책 문서
2. 회의록
3. 첨부 이미지
자료 간 내용이 충돌하면 높은 우선순위 자료를 기준으로 정리하라.
충돌 사실은 별도로 표시하라.

이 한 줄이 있으면 결과가 훨씬 단단해진다. 모델에게 판단 자유를 주는 대신, 충돌 처리 규칙을 미리 준 셈이기 때문이다.

사람 검토가 반드시 필요한 지점을 남겨라

자료 기반 프롬프트를 잘 설계해도, 모든 작업을 자동으로 끝낼 수 있는 것은 아니다. 특히 숫자, 날짜, 금액, 법적 표현, 승인 조건, 계약 문구, 연락처처럼 작은 차이가 큰 결과를 만드는 항목은 마지막에 사람 검토 지점을 남겨 두는 편이 안전하다.

이때 중요한 것은 "사람이 검토한다"는 말을 막연하게 쓰지 않는 것이다. 무엇을 왜 확인해야 하는지까지 출력에 포함시키면 훨씬 쓸모 있다.

예를 들어 이렇게 설계할 수 있다.

출력 마지막에 '사람 검토 필요' 섹션을 추가하라.
다음 항목은 반드시 별도로 표시한다.
- 숫자와 날짜
- 승인 조건
- 고유명사
- 해석이 개입된 판단 문장

이렇게 하면 결과물은 단순 초안을 넘어, 검토 흐름까지 포함한 작업 문서가 된다. 중급 프롬프트의 목표는 AI가 혼자 완벽해지는 것이 아니라, 사람과 AI가 어디서 바통을 넘길지 명확해지는 것이다.

실패를 줄이는 프롬프트 패턴

자료 입력의 경계를 설계할 때 반복해서 쓸 수 있는 패턴이 있다. 아래 네 줄만 잘 붙여도 많은 사고를 줄일 수 있다.

- 답변은 첨부 자료만 근거로 작성하라.
- 자료에 없는 내용은 추정하지 말고 상태값으로 표시하라.
- 사실 요약과 해석을 분리하라.
- 각 핵심 주장에는 근거 위치를 함께 적어라.

이 패턴은 보고서 요약에도 붙고, 이미지 정보 추출에도 붙고, 비교표 작성에도 붙는다. 말하자면 자료 기반 작업의 안전벨트 같은 문장이다. 없어도 차는 굴러가지만, 있는 쪽이 훨씬 덜 다친다.

실무용 템플릿 예시

이 장의 내용을 한 번에 적용할 수 있는 기본 템플릿을 남겨 보자.

다음 작업은 첨부한 자료만 근거로 수행하라.
자료 범위: [문서명/이미지명/섹션/페이지/영역]
작업 목적: [요약/추출/비교/설명]
출력 대상: [팀장/고객/운영팀/내부 검토용]

출력 형식:
1. 사실 요약
2. 해석 또는 시사점
3. 누락/불명확/추가 확인 필요 항목
4. 사람 검토 필요 항목

규칙:
- 외부 지식으로 보완하지 말 것
- 자료에 없는 내용은 추정하지 말 것
- 각 핵심 항목에 근거 위치를 표시할 것
- 정보가 부족하면 먼저 확인 질문을 할 것

이 템플릿은 화려하지 않다. 하지만 바로 그 점이 장점이다. 팀에서 복사해 써도 흔들리지 않고, 작업 종류만 바꿔도 넓게 재사용할 수 있다.

자료 기반 프롬프트의 진짜 목적

자료를 입력한다는 것은 단지 참고자료를 던져 주는 일이 아니다. 모델이 움직일 수 있는 운동장을 선으로 그어 주는 일이다. 선이 없으면 모델은 넓게 뛰고, 넓게 뛴 답은 그럴듯하지만 검증이 어렵다. 선이 있으면 답은 조금 덜 화려할지 몰라도, 어디서 왔는지 추적할 수 있고 어디가 비었는지 바로 보인다.

중급 실무자가 노려야 하는 것은 바로 이 상태다. 문서에 없는 말을 멋지게 메우는 AI가 아니라, 문서에 없는 부분을 없다고 말할 줄 아는 AI. 이미지에 보이지 않는 것을 아는 척하는 AI가 아니라, 보이는 것과 불명확한 것을 분리하는 AI. 그리고 그 모든 답변에 "왜 그렇게 말했는지" 다시 따라갈 수 있는 흔적을 남기는 AI다.

좋은 자료 기반 프롬프트는 AI를 똑똑하게 보이게 만드는 기술이 아니다. 오히려 반대다. 아는 것과 모르는 것을 구분하게 만드는 기술이다. 그 구분이 생기는 순간, 프롬프트는 단순한 질문이 아니라 실무용 안전장치가 된다.