제미나이(Gemini)로 파일을 만들 때 | 원문을 유지하는 방법

제미나이에게 보고서나 문서를 만들어 달라고 요청하면 내용을 정리하는 것뿐만 아니라 실제 파일까지 만들어줍니다.

현재 제미나이에서는 대화 중 DOCX, PDF, XLSX 같은 형식의 파일을 직접 생성할 수 있습니다. Google Gemini 공식 도움말

파일을 바로 만들어준다는 점은 편리하지만 한 가지 신경 쓰이는 부분이 있습니다.

내가 준 원문에 없는 내용까지 파일에 들어가면 어떻게 해야 할까?

지난번에는 제미나이에게 회의 내용을 주고 DOCX 파일을 만들어달라고 요청해보았습니다.

그런데 결과 파일을 확인해보니 원문에 없던 날짜와 장소, 참석 부서, 작성일 같은 정보가 추가되어 있었습니다.

그래서 이번에는 동일한 원문을 가지고 프롬프트를 바꿔보면서 결과가 어떻게 달라지는지 다시 확인해보았습니다.

이번에는 원문에 있는 정보만 사용하도록 요청하는 방법과 작성 후 원문과 대조하도록 요청하는 방법을 비교해보았습니다.

동일한 원문으로 파일을 만들어보았다

테스트에 사용한 내용은 9월 신규 서비스 출시와 관련된 회의 결과였습니다.

원문에는 다음과 같은 내용이 들어 있었습니다.

• 다음 달부터 사전 홍보 시작
• 9월 첫째 주까지 홍보 문구와 이미지 시안 준비
• 개발팀의 서비스 소개 페이지 완성
• 9월 15일 베타 테스트 시작
• 베타 테스트 전 고객 50명 모집
• 테스트 결과를 바탕으로 정식 출시 일정 결정
• 정식 출시일과 광고 예산은 아직 미결정

처음에는 이 내용을 그대로 주고 깔끔한 회의 결과 보고서 DOCX 파일을 만들어달라고 요청했습니다.

결과물을 확인해보니 문서 형식은 잘 정리되어 있었습니다.

그런데 원문에는 없었던 정보가 들어가 있었습니다.

예를 들어 회의가 열린 장소나 참석 부서, 작성일처럼 원문에서 확인할 수 없는 정보가 추가되어 있었습니다.

문서만 보면 자연스러워 보이지만 원문과 비교하면 다른 부분이 생긴 것입니다.

그래서 이번에는 프롬프트를 바꿔봤습니다.

원문에 있는 정보만 사용하도록 요청해보았다

두 번째 테스트에서는 다음과 같이 요청했습니다.

위 내용을 바탕으로 깔끔한 회의 결과 보고서를 만들고 DOCX 파일로 만들어 주세요.

원문에 있는 정보만 사용하고, 원문에 없는 정보는 추가하거나 추측하지 마세요.

이번에는 결과가 달라졌습니다.

완성된 DOCX 파일을 확인해보니 앞선 결과에서 보였던 것처럼 원문에 없던 날짜나 장소, 참석자 등의 정보는 추가되지 않았습니다.

회의의 주요 결정 사항과 일정, 담당 업무, 미결정 사항도 원문에 있는 내용을 기준으로 정리되어 있었습니다.

예를 들어 베타 테스트 시작일은 9월 15일로 정리되어 있었고, 베타 테스트 전에 고객 50명을 모집한다는 내용도 그대로 들어갔습니다.

담당 업무 역시 마케팅팀과 개발팀의 역할을 원문에 맞게 정리했습니다.

즉, 원문에 없는 정보를 추가하지 말라는 조건을 명확하게 넣었을 때 이번 테스트에서는 원문에 맞는 결과가 만들어졌습니다.

원문 대조 후 수정을 요청해보았다.

여기서 한 가지가 더 궁금해졌습니다.

처음부터 원문에 있는 정보만 사용하라고 요청하는 것과,

문서를 만든 뒤 원문과 직접 대조해서 문제가 있으면 수정하라고 요청하는 것은 결과가 다를까?

그래서 세 번째 테스트에서는 프롬프트를 다음처럼 바꿨습니다.

위 내용을 바탕으로 깔끔한 회의 결과 보고서를 만들고 DOCX 파일로 만들어 주세요.

문서를 작성한 후 원문과 대조하여 추가되거나 달라진 정보가 있는지 확인하세요.

차이가 발견되면 원문의 내용에 맞게 수정한 후 최종 파일을 만들어 주세요.

이번에는 문서를 작성한 뒤 원문과 대조하고, 다른 점이 확인되면 수정하는 과정까지 요청했습니다.

최종 DOCX 파일을 확인해보니 이번에도 원문에 없는 정보가 추가된 부분은 확인되지 않았습니다.

주요 결정 사항과 일정, 담당 업무, 미결정 사항도 원문에 맞게 정리되어 있었습니다.

두 방법의 결과는 어땠을까?

이번 테스트에서는 두 가지 방법 모두 원문에 없는 정보를 추가하지 않은 결과가 나왔습니다.

그래서 단순히 “어느 방법이 더 좋다.” 라고 결론을 내리기는 어려웠습니다.

오히려 이번 테스트에서 확인할 수 있었던 것은 프롬프트에서 원문에 대한 기준을 명확하게 알려주는 것 자체가 중요하다는 점이었습니다.

처음에는 원문에 없는 정보가 들어갔습니다.

하지만 이후에 ‘원문에 있는 정보만 사용하기’ 또는 ‘원문과 대조 후 수정하기’와 같은 조건을 추가했습니다.

그 결과 이번 테스트에서는 원문에 없는 정보가 추가되지 않았습니다.

즉, AI에게 파일을 만들어달라고 할 때는 “깔끔하게 만들어줘”라는 요청만 하는 것보다 어떤 정보를 사용해야 하는지 기준을 함께 알려주는 것이 도움이 될 수 있었습니다.

왜 이런 조건을 넣어야 할까?

AI에게 문서를 만들어달라고 하면 단순히 내용을 복사하는 것이 아니라 사람이 보기 좋은 문서 형태로 정리하려고 합니다.

이 과정에서 문서의 빈 부분을 자연스럽게 채우거나, 일반적인 문서 형식에 맞추기 위해 원문에 없는 내용을 넣을 가능성을 생각해볼 수 있습니다.

실제로 처음 테스트에서 문서 형식은 자연스러웠지만 원문에는 없던 정보가 들어갔습니다.

그래서 파일을 만들 때는 어떤 정보를 사용해야 하는지 미리 알려주는 것이 중요할 수 있습니다.

특히 회의록이나 보고서처럼 날짜, 숫자, 담당자, 일정 같은 정보가 중요한 문서는 더욱 그렇습니다.

파일을 만들 때 이렇게 하면 어떨까?

원문을 바탕으로 파일을 만들 때는 다음과 같이 요청할 수 있습니다.

다만 이것이 모든 상황에서 항상 같은 결과를 보장한다는 의미는 아닙니다.

그래도 파일은 직접 확인해야 한다

프롬프트에 원문 준수 조건을 넣었다고 해서 완성된 파일을 확인하지 않아도 되는 것은 아닙니다.

제미나이 역시 답변에 오류가 있을 수 있으므로 중요한 내용은 다시 확인하라고 안내하고 있습니다. Google Gemini 공식 도움말

특히 실제 업무에 사용하는 문서라면 파일을 만든 뒤 다음과 같은 내용을 확인하는 것이 좋습니다.

• 숫자와 날짜가 원문과 같은지
• 담당 업무가 달라지지 않았는지
• 중요한 일정이 빠지지 않았는지
• 미결정 사항이 임의로 결정된 내용처럼 바뀌지 않았는지
• 원문에 없는 정보가 추가되지 않았는지

AI에게 확인을 요청하는 것과 사람이 최종 결과를 확인하는 것은 별개의 과정입니다.

AI에게 파일을 맡길 때 달라지는 점

이번 테스트를 하면서 느낀 것은 AI에게 파일을 만들어달라고 할 때 결과물의 모양만 요청하는 것과 내용의 기준까지 알려주는 것은 다르다는 점이었습니다.

처음에는 “깔끔한 회의 결과 보고서로 만들어줘.” 라고 요청했습니다.

하지만 이후에는 “원문에 있는 정보만 사용해줘.” 또는 “원문과 대조 후 수정해줘.”라는 조건을 추가했습니다.

이번 테스트에서는 두 방법 모두 원문에 맞는 결과가 나왔기 때문에 어느 한쪽이 더 정확하다고 단정할 수는 없습니다.

다만 AI에게 파일을 만들게 할 때 원문에 대한 기준을 명확하게 전달하는 습관은 만들어볼 만했습니다.

마무리

제미나이에게 문서를 만들어달라고 하면 내용을 정리하는 것뿐 아니라 실제 DOCX 파일까지 만들어줄 수 있어 편리합니다.

하지만 파일이 보기 좋게 만들어졌다고 해서 원문의 내용까지 정확하게 유지되었다고 말할 수는 없습니다.

이번 테스트에서도 처음에는 원문에 없던 정보가 들어갔습니다.

이후에는

원문에 있는 정보만 사용하기 → 작성 후 원문과 대조한 후 수정하기 → 최종 파일 직접 확인하기

순서로 확인해봤습니다.

이번 테스트에서는 두 가지 방법 모두 원문에 맞는 결과가 나왔습니다.

그래서 중요한 것은 특정 문장을 넣으면 AI가 항상 완벽하게 파일을 만들어준다고 생각하는 것이 아니라, AI가 문서를 만들 때 지켜야 할 기준을 미리 알려주고 완성된 결과도 확인하는 것이라고 볼 수 있습니다.

특히 회의록이나 보고서처럼 원문의 숫자와 일정, 담당 업무가 중요한 문서를 AI에게 맡긴다면,

“깔끔하게 만들어줘”에서 끝내지 말고 “원문에 없는 내용은 추가하지 마세요” 또는 “원문과 대조 후 다른 점이 확인되면 수정해줘.”라고 한 번 더 알려주는 것.

이 작은 차이가 제미나이로 만든 파일이 원문을 유지하는 데 도움이 될 수 있습니다.