AI에게 기술 기사 초안 작성을 맡기고, 사실 확인으로 완성하는 절차

기술 기사를 쓸 때 생성 AI를 사용하는 사람이 늘었습니다. 하지만 사용법을 잘못 사용하면 "그럴듯하지만 틀린 기사"가 양산됩니다. 이 기사에서는 AI의 장점과 단점을 고려하여, 초안은 AI에게 맡기고 사실 확인은 직접 하는 분담 방식으로 기사를 완성하는 절차를 정리합니다. 특별한 도구는 필요하지 않으며, 사고방식과 절차의 문제입니다.

먼저 전제로, 현재의 대규모 언어 모델(LLM)에는 다음과 같은 경향이 있습니다.

구성안이나 초안을 만드는 것은 특기: 목차의 배열, 논점의 도출, 문장 정리는 빠르고 질도 안정적입니다. -
사실의 정확성은 보장되지 않음: 사실 여부와 관계없이 그럴듯한 말로 문장을 구성해 버리는 경우가 있습니다. 이는 일반적으로 "할루시네이션 (hallucination)"이라고 불립니다. -
최신 정보나 세부적인 버전 차이에 약함: 학습 데이터의 컷오프(cut-off) 이후의 업데이트나 라이브러리의 세세한 동작은 놓치기 쉽습니다.

즉 AI는 "문장을 만드는 작업"을 대신해 주지만, "그 내용이 진짜인지"까지는 담보하지 않습니다. 정확성에 대한 책임은 공개 버튼을 누르는 인간에게 있습니다. 이 역할 분담을 처음에 의식하는 것이 AI를 사용한 집필의 출발점입니다. 반대로 말하면, 이 한 가지만 명심하고 있다면 AI는 강력한 초안 요원이 됩니다.

AI의 초안을 검증할 때 무엇을 의심해야 하는지 알고 있으면 효율적입니다. 기술 기사에서 자주 혼입되는 오류에는 몇 가지 유형이 있습니다.

존재하지 않는 API·메서드·옵션: "정말 있을 법한" 명명의 메서드나 인수를 만들어내기도 합니다. 예를 들어 실재하는 라이브러리에 실재하지 않는 옵션을 그럴듯하게 덧붙이는 식입니다. -
버전에 따라 변하는 동작의 단정: "이 커맨드는 이렇게 동작한다"라고 적혀 있어도, 특정 버전에서만 성립하거나 이미 바뀌어 있는 경우가 있습니다. -
수치·날짜·고유명사의 착오: 릴리스 연도, 기본값, 포트 번호, 설정 파일 이름 등은 그럴듯한 다른 값으로 바뀌어 있을 수 있습니다.

출처의 날조: "공식 문서에 따르면"이라고 적혀 있어도, 그 기술이 공식적으로 존재하지 않을 수 있습니다. 링크가 실재하지 않거나 무관한 페이지를 가리키기도 합니다. -
동작하지 않는 코드: 구문은 통과하더라도, import가 부족하거나·인수의 순서가 다르거나·반환값 처리가 잘못되는 등 "읽으면 맞을 것 같지만 실행하면 에러가 나는" 코드입니다.

이것들은 "문장으로서는 자연스럽기" 때문에 훑어 읽어서는 놓치게 됩니다. 특히 자신이 잘 모르는 영역일수록 "그럴듯함"에 휘둘리기 쉬워 위험합니다. 그렇기 때문에 후술할 기계적인 확인 절차가 필요하게 됩니다.

검증 비용을 낮추려면 초안 단계에서 궁리해 두는 것이 효과적입니다. 요점은 "AI에게 사실을 만들게 하지 말고, 구조를 만들게 하는 것"입니다.

구성만 먼저 요청하기: 갑자기 완성 원고를 요구하지 말고, "목차 안과 각 섹션의 논점만" 나오게 합니다. 논점의 타당성은 인간이 판단하기 쉬우며, 여기서 방향성을 확정할 수 있습니다. -
자신이 확실히 알고 있는 사실을 전달하기: 검증된 사양·수치·절차를 프롬프트에 포함하여 "이것을 사용하여 문장으로 만들어줘"라고 요청합니다. AI에게 지식을 묻는 것이 아니라 정형화를 부탁하는 형태로 하면 오류가 줄어듭니다. -
단정 짓지 말고 확신도를 덧붙이게 하기: "불확실한 부분은 '확인 필요'라고 명기해줘"라고 지시하면, 검증해야 할 장소가 AI 자신의 출력물에 표시로 남습니다. -
코드에는 전제를 쓰게 하기: "언어·라이브러리·버전·실행 환경을 서두에 명기해줘"라고 요청하면, 나중에 검증할 때 대조할 대상이 명확해집니다.

초안은 어디까지나 소재입니다. 완성도를 너무 높여 버리면 "고치기 아깝다"라는 심리가 작용하여 검증이 느슨해집니다. 7할 완성도의 초안을 인간의 확인으로 10할로 만든다는 정도의 거리감이 딱 적당합니다.

이곳이 기사의 질을 가르는 핵심입니다. AI의 출력을 AI나 검색 결과의 요약으로 확인하는 것이 아니라, 1차 정보로 확인합니다. 1차 정보란 공식 문서, 공식 리포지토리, 사양서, 실제 실행 결과 등을 말합니다.

검증은 다음 순서로 진행하면 누락이 생기기 어렵습니다.

• 사실을 불렛 포인트로 추출하기: 초안에서 '검증해야 할 주장'을 리스트화합니다. API 이름, 수치, 기본값(Default value), 절차, 출처 등입니다. 문장 그대로 확인하려고 하면 놓치기 쉬우므로, 주장 단위로 분해하는 것이 요령입니다. -
  API나 메서드는 공식 레퍼런스(Reference)에서 존재를 확인하기: '~있을 법하다'는 식으로는 통하지 않습니다. 공식 문서나 타입 정의(Type definition)에 실제로 존재하는지, 인자(Argument)와 반환값(Return value)이 맞는지 확인합니다. -
  코드는 실제로 실행하기: 이것이 가장 확실합니다. 작은 재현 환경을 만들어 실행하고, 에러가 발생하지 않는지, 기대하는 출력값이 나오는지 확인합니다. 예를 들어 Python이라면, 최소한의 확인은 이 정도면 충분합니다.

# 초안에 있는 처리가 정말로 작동하는지 최소 코드로 확인하기
import json
data = json.loads('{"key": "value"}')
...

• 버전 의존적인 기술은 환경을 명기하기: '내 환경에서는 ~였다'라고 쓸 수 있는 범위로 한정하고, 단정적인 표현을 피합니다. 확인한 버전을 병기하면 독자에게도 친절합니다. -
  출처는 반드시 직접 열어보기: AI가 제시한 링크나 '공식에 따르면'이라는 문구는, 링크를 직접 열어 해당 기술 내용이 있는지 확인합니다. 없다면 삭제하거나 올바른 출처로 교체합니다.

특히 코드 실행 확인은 생략되기 쉽지만, 기술 기사의 신뢰성과 직결됩니다. 작동하지 않는 코드를 올리면 독자의 시간을 뺏게 되고, 기사 전체의 신뢰도도 잃게 됩니다.

예를 들어 초안에 "json.loads()에 strict=False를 전달하면 끝에 쉼표(Trailing comma)를 허용할 수 있다"라고 적혀 있다고 가정해 봅시다. 문장 자체는 자연스럽고, 마치 실제로 존재할 법한 내용입니다. 여기서 멈추지 않고 직접 손으로 실행해 보는 것이 사실 확인(Fact-check)입니다.

실행해 보면 json.loads('{"a":1,}', strict=False)는 끝에 쉼표를 허용하지 않고 에러가 발생합니다 (strict는 문자열 내의 제어 문자를 다루는 인자이며, 끝에 쉼표를 허용하는 것과는 무관합니다). 이처럼 "인자는 존재하지만, 설명하는 효과가 다른" 식의 어긋남은 문장만 읽어서는 절대로 알아챌 수 없습니다. 실행과 레퍼런스 확인이라는 두 가지 방식을 병행해야만 비로소 잡아낼 수 있습니다. 여기서 언급한 값이나 동작도 독자는 자신의 환경과 버전에서 재확인해야 합니다. 이 글의 취지가 바로 "무조건 믿지 마라"이기 때문입니다.

검증을 "기분이 내킬 때 하는 것"으로 두면 지속할 수 없습니다. 기사마다 사용할 수 있는 짧은 체크리스트로 만들어 두면 누락을 줄일 수 있습니다.

• API·메서드·옵션은 공식 레퍼런스에서 실재함을 확인했는가
• 코드는 실제로 실행하여 기재된 대로의 출력이 나왔는가
• 수치·날짜·기본값·버전의 근거를 확인했는가
• "공식에 따르면"의 출처 링크를 직접 열어 해당 부분을 확인했는가
• 확증할 수 없는 점에 "확인 필요"를 남겨두지 않았는가

이 리스트를 기사 끝에 코멘트로 붙여두고, 공개하기 전에 모든 항목에 체크가 될 때까지 내보내지 않는 운영 방식을 택하는 것만으로도 질이 안정됩니다. 시스템화하면 작성자의 컨디션이나 마감 기한에 좌우되지 않게 됩니다.

기계적인 검증을 마쳐도 마지막에는 인간의 판단이 필요한 부분이 남습니다. AI에게 온전히 맡길 수 없는, 작성자의 책임 영역입니다.

• 구성의 타당성: 논점의 순서, 과부족, 독자 입장에서의 이해도는 AI의 제안을 그대로 믿지 않고 스스로 결정합니다. -
  중복 및 장황한 부분 정리: AI는 같은 말을 바꿔가며 반복하는 경향이 있습니다. 다시 읽어보며 다듬습니다. -
  톤과 정직함: 선동하지 않고, 과장하지 않으며, 모르는 것을 "아는 척"하며 쓰지 않습니다. 이는 작성자의 태도 문제입니다. -
  검증하지 못한 부분의 처리: 도저히 확증할 수 없는 점은 단정하지 말고 "확인 필요", "환경에 따라 다를 수 있음"이라고 솔직하게 적습니다. 모호함을 숨기지 않는 것이 장기적인 신뢰로 이어집니다. -
  공개의 최종 책임: 공개하는 이상 내용에 대한 책임은 작성자에게 있습니다. "AI가 썼으니까"라는 변명은 통하지 않습니다.

AI를 사용하든 사용하지 않든, 기술 기사의 가치는 "독자가 안심하고 재현할 수 있는 것"에 있습니다. AI는 초안 작성 속도를 높여주지만, 그 속도를 신뢰로 바꾸는 것은 인간에 의한 사실 확인과 판단입니다.

AI로 기술 기사를 쓰는 흐름을 정리하면 다음과 같습니다.

• 초안은 AI에게: 구성안, 논점, 문장 정리는 AI가 잘하는 분야입니다. 완성도를 너무 높이려 하지 말고 소재로 활용하세요. -
• 사실은 의심할 것: 존재하지 않는 API, 버전에 따른 단정적 표현, 날조된 출처, 작동하지 않는 코드가 전형적인 함정입니다. -
• 1차 정보로 교차 검증: 주장을 불렛 포인트로 분해하여 공식 문서(Official Documentation)에서 확인하고, 코드는 실제로 실행해 보세요. -
• 시스템화하기: 체크리스트로 만들어 매번 적용하면 검증 누락을 줄일 수 있습니다. -
• 마지막은 인간의 판단: 구성, 정직함, 공개에 대한 책임은 작성자가 집니다. 확신이 없는 부분은 숨기지 말고 솔직하게 작성하세요.

「AI에게 맡기는 부분」과 「인간이 책임지는 부분」을 나누어 생각하는 것만으로도 기사의 신뢰성은 크게 달라집니다. 빠르게 쓰는 것과 정확하게 쓰는 것. 이 두 가지를 양립하는 열쇠는 검증 절차를 하나의 시스템(System)으로 갖추어 두는 것입니다.