AI로 무엇을 할 수 있나: 생성·검색·자료 읽기·실행의 차이

먼저 알아둘 답

AI에게 이메일 초안을 쓰게 하는 일, 오늘 바뀐 기능을 찾게 하는 일, 첨부한 회의록을 읽게 하는 일, 실제로 이메일을 보내게 하는 일은 서로 다르다. 같은 대화창에서 진행되더라도 결과를 확인하는 방법까지 같지는 않다.

이 글에서는 활용 방법을 이해하기 위해 일을 생성·검색·자료 읽기·실행으로 나눈다. 이것은 EEJE의 설명용 분류이지, 모든 AI 시스템을 네 가지로만 구분하는 공식 기술 분류는 아니다. 실제 작업에서는 여러 과정이 결합된다.

시작할 때는 다음 질문 하나가 유용하다.

내가 필요한 것은 새로운 초안인가, 확인할 사실인가, 주어진 자료의 해석인가, 외부 시스템에서 완료된 행동인가?

1. 생성: 새로운 답을 만드는 일과 사실을 확인하는 일은 다르다

“거절 메일을 정중하게 써줘”라고 요청하면 AI는 표현과 구성을 제안할 수 있다. 이때 사용자가 확인할 것은 의도와 어조, 빠진 조건, 상대방에게 약속해도 되는 내용이다.

그런데 같은 문장 안에 “우리 회사는 업계 점유율 1위”라는 표현이 들어갔다면 이야기가 달라진다. 자연스러운 문장인지와 실제로 1위인지는 별도로 확인해야 한다. 사용자가 제공하지도 않았고 근거도 확인되지 않은 1위 주장을 그럴듯한 문장이라는 이유로 받아들여서는 안 된다.

OpenAI는 ChatGPT가 사실과 다른 답, 존재하지 않는 인용이나 출처를 만들 수 있으며, 확신하는 말투가 정확성을 뜻하지 않는다고 설명한다.[S1]

따라서 처음 연습할 작업으로는 자신이 내용을 확인할 수 있는 자료의 재구성이나 초안 작성을 권한다. 이는 편집부의 학습 순서 제안이다. 중요한 숫자나 사실이 들어갈 때에는 다음과 같이 범위를 정해볼 수 있다.

“아래에 제공한 사실만 사용해서 소개문을 작성해줘. 없는 실적·고객·수치는 추가하지 말고, 더 필요한 정보는 별도 질문으로 남겨줘.”

이 지시도 오류를 없애는 보증서는 아니다. 결과에 새로운 사실이 들어갔는지는 여전히 확인해야 한다.

2. 검색: 출처가 달렸다는 사실보다 출처가 무엇을 뒷받침하는지가 중요하다

“지금 이 기능을 한국에서도 쓸 수 있나?”와 같은 질문은 현재 자료 확인이 필요하다. 이때 AI가 답을 생성하는 것과 검색 도구를 사용해 자료를 찾는 것을 구별해야 한다.

ChatGPT의 공식 검색 안내는 웹 검색으로 현재 정보를 찾아 출처를 제시할 수 있다고 설명한다. 동시에 검색 결과와 인용 자체도 불완전하거나 오래됐거나 틀릴 수 있으므로 원문을 열어 확인하라고 안내한다.[S2]

다음은 편집부가 권하는 확인 순서다. 먼저 인용한 문서가 실제로 열리는지 본다. 그다음 그 문서가 답변의 문장을 정말 뒷받침하는지 읽는다. 마지막으로 발표일과 현재 적용 조건을 살핀다.

예컨대 원문이 “일부 유료 계정에 순차 배포한다”고 설명하는데 답변이 “한국의 모든 사용자가 지금 쓸 수 있다”고 했다면, 실제 출처가 있어도 결론은 원문보다 넓다.

‘출처가 존재한다’는 확인과 ‘주장이 출처의 범위를 넘지 않는다’는 확인은 별개다.

이때 다음과 같이 요청해볼 수 있다.

“현재 제공 여부를 공식 자료에서 확인해줘. 발표일과 실제 이용 가능 여부를 나누고, 한국·요금제·앱 또는 API의 조건을 밝혀줘. 원문에서 확인되지 않은 조건은 추정하지 마.”

3. 자료 읽기: 파일을 올렸다는 사실이 원하는 부분을 확인했다는 증거는 아니다

회의록, 보고서, 표를 올리고 요약을 받는 작업은 검색과 또 다르다. 핵심은 웹의 일반 정보보다 내가 제공한 자료에 무엇이 적혀 있는가다.

ChatGPT는 첨부 문서의 요약·비교, 표 데이터의 분석 등 여러 작업을 지원한다. 다만 문서 안에 포함된 그림을 다루는 방식은 요금제와 파일 유형 등에 따라 달라진다. 텍스트, 표, 그림을 같은 방식으로 처리했다고 전제하지 않는 편이 좋다.[S3]

보고서가 100쪽이라는 사실보다 중요한 것은 질문에 필요한 근거가 실제로 확인됐는지다. 편집부는 다음 방식으로 작업을 나누길 권한다.

먼저 근거 위치를 찾고, 다음에 내용을 설명하게 한다. “이 보고서를 요약해줘”에서 멈추는 대신 “납기 변경을 언급한 부분과 예외 조건을 먼저 찾아줘. 확인한 페이지 또는 항목을 표시한 뒤 요약해줘”라고 요청하는 것이다.

페이지 번호가 없는 자료라면 제목이나 행 번호처럼 실제로 확인 가능한 위치를 쓰면 된다. 없는 페이지 번호를 만드는 것보다 “위치 표시를 확인할 수 없다”고 남기는 편이 낫다.

주의할 점도 있다. 답변에 근거 위치가 있어도 그 위치가 정확한지는 원문 대조가 필요하다. 위치 표시는 검증을 쉽게 만드는 장치이지, 검증을 대신하는 증명은 아니다.

4. 실행: ‘보냈습니다’라는 문장이 전송 완료의 증거는 아니다

“메일을 써줘”와 “메일을 보내줘”는 다르다. 전자는 초안 생성으로 끝날 수 있지만, 후자는 메일 시스템에 접근하고 실제 전송 작업을 수행해야 한다.

OpenAI의 개발자 문서는 도구 호출을 여러 단계로 나눈다. 모델이 호출을 요청하는 단계, 애플리케이션에서 실제 코드를 실행하는 단계, 실행 결과를 모델에 돌려주는 단계가 구별돼 있다.[S4]

따라서 편집부는 외부 행동을 맡길 때 다음을 구분하길 권한다.

모든 서비스가 같은 확인 방식을 제공하지는 않는다. 특히 ‘요청 접수’가 ‘최종 완료’를 뜻하는지 살펴야 한다. 예를 들어 전송 요청이 수락됐다는 사실은 상대방이 메시지를 읽었다는 뜻까지 포함하지 않는다.

중요한 작업이라면 요청할 때 “초안까지만”, “내 확인 후 실행”, “실행 결과의 상태를 알려줘”처럼 권한과 완료 조건도 정해두는 편이 좋다.

5. 직접 연습해보기: 그럴듯한 정리가 놓칠 수 있는 것

아래는 이 글을 위해 만든 가상의 회의 메모다. 실제 회사나 인물의 기록이 아니며, 특정 AI 제품에서 측정한 성능 결과도 아니다.

[1] 출시 목표일은 11월 2일이다.
[2] 디자인은 민지가 맡기로 확정했다.
[3] 개발은 준호에게 맡기는 방안을 제안했다. 아직 수락 여부는 확인하지 않았다.
[4] 예산은 300만~400만 원 범위에서 검토 중이다. 승인 금액은 정하지 않았다.
[5] 금요일에 일정을 다시 논의한다.

여기서 “출시 일정, 담당자, 예산을 정리해줘”라고만 하면 우리가 원하는 확인 기준이 충분히 드러나지 않는다. 다음 요청을 연습용으로 제안한다.

아래 회의 메모에서 확인되는 정보만 사용해줘.
항목별로 ‘내용 / 상태 / 근거 번호 / 추가 확인 사항’을 표로 작성해줘.
확정, 목표, 제안, 검토 중을 구별해줘.
자료에 없는 연도·날짜·승인 여부는 추정하지 마.
외부 검색으로 가상의 회의 내용을 보충하지 마.

자료와 대조하면 다음처럼 정리할 수 있다.

여기서 “개발 담당자는 준호이며 예산은 400만 원으로 확정됐다”고 요약한다면, 단순히 표현이 다른 것이 아니다. 제안을 확정으로, 범위의 상한을 승인액으로 바꾼 오류다.

이 연습의 목적은 표를 예쁘게 만드는 데 있지 않다. “무엇이 아직 결정되지 않았는지”가 결과물에 남아 있는지를 확인하는 데 있다.

6. 초보자는 네 가지를 적고 시작하면 된다

처음부터 복잡한 프롬프트 기법을 외울 필요는 없다. 다음 네 항목은 편집부가 제안하는 기본 작업 의뢰서다.

목표: 이 작업으로 무엇을 결정하거나 완성하려는가?
자료: 어떤 문서·메모·링크를 사용해야 하는가?
제약: 추가하면 안 되는 사실, 공개하면 안 되는 내용, 하지 말아야 할 행동은?
완료 조건: 어떤 형식과 확인 결과가 있어야 끝난 것으로 볼 것인가?

예를 들어 “아래 회의 메모로 팀에 공유할 이메일 초안을 만들되, 미확정 일정은 미확정으로 남기고, 실제 전송은 하지 마”라고 요청하면 생성할 결과와 행동의 경계가 함께 드러난다.

다만 이 양식이 모든 모델에서 가장 좋은 결과를 낸다는 뜻은 아니다. OpenAI의 프롬프트 안내 역시 생성 결과가 비결정적이며, 모델이나 버전이 달라지면 결과도 달라질 수 있어 평가가 필요하다고 설명한다.[S5]

7. 전문가가 점검할 부분: 실패가 일어난 위치를 나눈다

업무에 반복 적용할 때에는 “AI가 틀렸다”는 평가만으로는 개선 방향이 모호하다. 편집부는 다음 네 영역을 나누어 기록하는 방식을 제안한다.

자료 확보 오류는 필요한 문서나 최신 정보를 확보하지 못한 경우다. 해석 오류는 확보한 자료의 조건·단위·주장을 잘못 읽은 경우다. 실행 오류는 적절한 작업을 요청했지만 실제 도구에서 실패한 경우다. 확인 오류는 작업의 성공 여부를 충분히 확인하지 않고 완료로 처리한 경우다.

이는 모든 실패를 포괄하는 표준 분류가 아니라, 원인을 구체적으로 논의하기 위한 운영 틀이다. 하나의 실패가 여러 영역에 걸칠 수도 있다.

앞의 회의 예시에서 제안을 확정으로 바꿨다면 원문 해석을 고쳐야 한다. 이메일이 작성됐으나 전송 권한이 없다면 문장을 다시 쓰는 것으로 해결되지 않는다. 출처가 실제로 열리지 않았다면 근거를 확보하는 작업부터 다시 해야 한다.

자주 묻는 질문

AI가 모른다고 하면 더는 쓸모가 없나?

편집부는 ‘모름’의 이유를 나누어 보길 권한다. 자료가 없는 것인지, 접근할 수 없는 것인지, 자료끼리 충돌하는 것인지, 맡긴 범위 밖인지에 따라 다음 행동이 달라진다. 답을 억지로 채우는 대신 무엇을 추가 확인해야 하는지 얻는 것도 유용한 결과다.

검색과 파일 첨부를 함께 쓰면 더 믿을 수 있나?

함께 사용하는 것 자체보다 역할을 분명히 하는 편이 좋다. 가령 내부 회의에서 누가 무엇을 결정했는지는 회의 자료로 확인하고, 언급된 제품의 현재 제공 조건은 공식 웹 자료로 확인하는 방식이다. 두 출처가 담당하는 질문을 구분해야 한다는 편집 제안이다.

중요한 작업을 한 번 맞혔다면 반복해도 되는가?

한 번의 성공을 반복 작업 전체의 검증으로 보지는 않길 권한다. 다른 입력과 빠진 정보, 예외 상황에서도 같은 기준을 충족하는지 확인해야 한다. 모델 버전 변경 시 평가가 필요하다는 공식 개발 안내도 이 점과 연결된다.[S5]

이번 편의 결론

AI를 잘 쓰는 사람은 모든 질문을 어렵게 쓰는 사람이 아니다. 초안이 필요한 순간, 근거가 필요한 순간, 자료를 읽어야 하는 순간, 실제 행동의 완료를 확인해야 하는 순간을 구별하는 사람이다.

다음 작업을 맡길 때 이렇게 시작해보자.

“이 일에서 네가 만들어야 할 것, 확인해야 할 것, 실제로 실행해야 할 것을 구분해줘. 확인하지 못한 부분은 완료했다고 쓰지 마.”

다음 편: 서비스와 모델은 무엇이 다른가 — 같은 AI 이름만으로 사용 경험을 비교하면 놓치는 것들.

출처와 검증 정보

이 글의 네 가지 활용 분류, 작업 의뢰서, 가상 메모와 점검 방식은 EEJE의 설명·실무 제안이다. 제품의 기능 설명은 아래 공식 자료를 대조했다. 특정 프롬프트의 개선율이나 도구 간 우열은 측정하지 않았다. 발행 시 제공 조건이 바뀌었다면 관련 문장을 다시 확인해야 한다.

• S1 — OpenAI, Does ChatGPT tell the truth?. 확인: 2026-10-16.
• S2 — OpenAI, Searching the web with ChatGPT. 확인: 2026-10-16.
• S3 — OpenAI, Uploading files and audio to ChatGPT. 확인: 2026-10-16.
• S4 — OpenAI, Function calling. 확인: 2026-10-16.
• S5 — OpenAI, Prompt engineering. 확인: 2026-10-16.