이야기를 디버깅하는 개발자.

개발과 창작 사이에서, 사람들이 자기만의 이야기를 만들 수 있는 도구와 기록을 만듭니다.

roslyn.dev 자세히보기

AI와 도구/창작 보조 실험

AI 글쓰기 결과를 출처·사실·경험 세 칸으로 검수하는 방법

Roslyn 2026. 10. 7. 09:00
반응형

AI가 만들어 준 글은 문장만 보면 자연스럽습니다. 문제는 그 문장이 어디에서 왔는지, 실제로 확인된 사실인지, 내가 직접 겪은 일처럼 읽히는지 한 번에 판단하기 어렵다는 점입니다.

저는 AI 결과를 그대로 고치기보다 문장마다 출처·사실·경험 세 칸을 채웁니다. 이 표를 사용하면 무엇을 삭제하고 무엇을 다시 조사해야 하는지 명확해집니다.

출처가 있는 문장과 없는 문장을 나눕니다

외부 문서나 공식 자료에서 확인한 문장은 URL과 확인일을 붙입니다. 출처가 없는 문장이 반드시 틀린 것은 아니지만, 독자가 사실처럼 받아들일 가능성이 있으면 다시 확인해야 합니다.

AI가 여러 출처를 섞어 말한 경우에는 한 문장으로 합치지 않습니다. 어떤 부분이 어느 문서를 근거로 하는지 나눠 적어야 나중에 변경된 사실을 수정할 수 있습니다.

  • 공식 출처: 제품 문서·표준·공공기관처럼 원문을 확인할 수 있는 자료입니다.
  • 경험 출처: 내가 직접 사용·측정·실패한 기록입니다.
  • 미확인: 그럴듯하지만 아직 근거를 찾지 못한 문장입니다.

사실과 해석을 다른 색으로 생각합니다

‘React 19.2에 Activity가 있다’는 확인 가능한 사실입니다. ‘그래서 모든 탭을 Activity로 바꾸면 빨라진다’는 해석이자 적용 가설입니다. 두 문장을 같은 확신으로 쓰면 독자가 제품 문서와 개인의 판단을 구분하기 어렵습니다.

본문에서는 사실과 경험을 문장 구조로 구분합니다. ‘공식 문서에 따르면’, ‘제 환경에서는’, ‘이 조건에서는’ 같은 표현은 약한 말이 아니라 범위를 정확하게 만드는 장치입니다.

문장 유형표현 예검수

사실 공식 문서에 따르면… 출처·버전 확인
경험 제 환경에서는… 환경·방법 기록
해석 저는 …라고 판단했습니다 반대 조건과 한계 기록
미확인 확인이 필요합니다 작성 전 조사

경험은 AI가 대신 만들 수 없는 부분입니다

AI가 제안한 ‘운영해 보니 편했습니다’라는 문장을 그대로 쓰면 경험담이 가짜가 됩니다. 직접 사용하지 않았다면 사용하지 않았다고 써야 합니다. 실제로 사용했다면 기간, 대상, 실패, 다시 바꾼 이유를 내 기록에서 꺼냅니다.

경험의 세부를 모두 공개할 필요는 없지만, 독자가 판단할 수 있는 조건은 남겨야 합니다. 어떤 환경에서 얻은 결론인지 모르면 다른 사람이 그대로 적용하다가 오해할 수 있습니다.

  • 환경: 버전·기기·사용 규모처럼 결과에 영향을 주는 조건입니다.
  • 행동: 무엇을 어떻게 시도했는지입니다.
  • 한계: 다른 환경에서는 달라질 수 있는 이유입니다.

마지막에는 문장보다 글의 약속을 검수합니다

문장 단위 검수를 끝내도 제목과 본문이 다른 약속을 하면 글 전체가 흔들립니다. 제목의 숫자와 목록이 실제 본문에 있는지, 독자가 얻는 결과가 결론에서 다시 확인되는지 봅니다.

AI를 썼다는 사실 자체가 글의 가치나 결함을 결정하지는 않습니다. 다만 AI가 어떤 일을 했고 사람이 어떤 판단을 했는지 독자가 궁금해할 만한 글이라면 그 과정을 간단히 밝혀 맥락을 제공합니다.

AI 도구를 사용할 때 남겨야 할 경계

AI 도구는 조사와 구조화에 도움을 주지만, 결과의 책임까지 가져가지는 않습니다. 저는 작업을 시작할 때 입력에 포함해도 되는 정보, 외부 출처로 확인해야 하는 주장, 사람이 직접 판단해야 하는 결과를 구분합니다. 이 세 가지가 섞이면 AI가 만든 문장이나 도구 호출을 실제 경험과 사실처럼 받아들이기 쉽습니다.

작은 샘플로 실행한 뒤 기록을 검토하는 것도 중요합니다. 프롬프트·도구 인자·응답·파일 결과 중 무엇을 보관할지 정하고, 민감정보와 권한을 최소화합니다. 한 번 잘 나온 결과보다 같은 조건에서 다시 확인할 수 있는 과정이 더 오래 남는 자산입니다. 최신 사양과 정책을 다루는 글은 조사일과 버전을 고정하고 발행 전에 공식 문서를 다시 읽습니다.

  • 입력 범위: 원고·개인정보·토큰·파일 경로 중 무엇을 보내지 않을지 정합니다.
  • 근거: 공식 문서와 직접 경험을 분리해 기록하고 URL을 보관합니다.
  • 검수: 사실·출처·문체·권한·재현성을 사람이 확인합니다.
  • 중단 조건: 결과가 반복되지 않거나 비용·권한이 커지면 사용을 멈춥니다.

다음 작업에서 다시 확인할 항목

한 번 적용한 방법이 언제나 같은 결과를 내는 것은 아닙니다. 사람과 서비스와 원고의 조건이 바뀌면 같은 원칙도 다른 판단을 요구합니다. 그래서 저는 글을 작성한 뒤 결론만 보관하지 않고, 결론이 성립한 조건과 다시 확인해야 할 조건을 함께 적습니다. 이 기록이 있으면 몇 달 뒤 글을 업데이트할 때 당시의 경험을 현재의 사실처럼 착각하지 않을 수 있습니다.

특히 버전·정책·가격·플랫폼 기능처럼 외부에서 바뀌는 내용은 조사한 날짜와 공식 문서의 주소를 남깁니다. 발행 시점에 문서가 달라졌다면 본문에 변경 사실을 표시하고, 직접 확인하지 못한 부분은 독자가 알 수 있도록 범위를 제한합니다. 경험을 공유하는 글도 다른 사람의 환경에 그대로 적용될 수 있으므로, 성공 사례보다 실패 조건을 함께 쓰는 편이 안전합니다.

마지막으로 이 글을 읽은 분이 바로 할 수 있는 행동은 하나로 줄입니다. 모든 항목을 한꺼번에 바꾸기보다 현재 상태를 기록하고, 작은 실험을 한 번 실행하고, 결과를 다시 적는 순서입니다. 그렇게 쌓인 기록이 다음 글의 소재가 되고, 처음의 판단을 더 정확하게 고쳐 쓰는 근거가 됩니다.

  • 범위 표시: 이 글의 결론이 적용되는 환경과 적용되지 않는 환경을 구분합니다.
  • 날짜 기록: 버전·정책·가격·문서를 확인한 날짜를 남깁니다.
  • 실패 조건: 어떤 상황에서는 이 방법을 쓰지 말아야 하는지 적습니다.
  • 작은 실행: 독자가 오늘 시도할 수 있는 가장 작은 행동을 고릅니다.
  • 후속 기록: 실행 결과와 다음에 바꿀 조건을 별도 메모로 남깁니다.

이 기록을 나중에 다시 읽을 때는 결과만 보지 않고 당시의 조건도 함께 확인합니다. 조건이 달라졌다면 결론을 그대로 복사하지 말고 현재의 입력과 제약을 다시 적습니다. 그 과정을 거쳐야 이 글이 단순한 경험담이 아니라 다음 판단을 돕는 작업 기록으로 남습니다.

마치며

AI 글쓰기 검수는 문장을 인간처럼 꾸미는 일이 아니라, 출처·사실·경험의 경계를 다시 세우는 일입니다. 다음 초안에서 문장 열 개만 골라 세 칸 표를 채우고, 미확인 문장을 먼저 줄여 보시기 바랍니다.

참고한 문서: Google 사람 우선 콘텐츠 가이드 · Google 생성형 AI 콘텐츠 지침

반응형