AI 초안 재편집: 빠져 있던 실제 사례

제작 기록을 부탁했는데 사용법이 나왔다

블로그를 만들면서 AI에 그때의 작업도 글로 남기라고 했다. 첫 글은 Astro를 선택한 이유에 집중했다. 내가 쓰려던 것은 AI를 어떻게 활용했는지였으므로 방향을 고치라고 했다.

다음 초안은 작업 맥락 전달, 완료 보고 검증, 디자인 피드백을 다룬 세 편이었다. 주제는 바뀌었지만 실제로 내가 무엇을 요청하고 AI가 어디서 틀렸는지는 잘 드러나지 않았다. 나는 바로 다시 쓰게 하지 않고, 먼저 문제와 개선점을 분석하라고 했다.

AI는 최초 요청서와 초안, 작업 일지, 시안, 검증 결과를 대조했다. 그 뒤 세 편을 하나의 구축 사례로 합치고 실제 요청과 결과를 넣었다. 이 글은 2026년 9월 15일에 했던 그 수정을 정리한 것이다.

원래 요청과 초안을 함께 읽게 했다

최초 요청에는 다음 기준이 있었다.

실제로 확인한 내용만 기록하고, 기억나지 않는 대화나 이전 결정을 복원해서 만들지 마.

요청, AI의 제안, 수정과 검증을 남기라는 뜻이었다. 그런데 초안에는 AI를 쓸 때 알아둘 만한 설명이 많았다. AI는 자료를 대조한 뒤 다음 차이를 짚었다.

초안에서 빠지거나 짧게 지나간 내용	이미 남아 있던 자료	수정한 방식
어떤 조건으로 블로그를 만들었는가	비공개 자료와 글 공개 범위를 정한 최초 요청	도입과 구현 설명에 조건을 넣음
어떤 디자인을 보고 골랐는가	네 가지 비교 시안과 2번을 선택한 대화	비교 이미지를 붙이고 선택 내용을 설명
실제로 무엇이 잘못됐는가	한·영 글 충돌, 수정 코드와 후속 검사	오류의 원인과 수정, 재확인을 함께 설명

연재 계획과 글 템플릿도 읽게 했다. 세 편이 비슷한 사용 요령을 반복하게 된 이유를 글 밖에서도 찾기 위해서였다. AI는 문제마다 초안의 예와 수정 방향을 붙여 분석 문서를 만들었다. 나는 그 내용을 받은 뒤 재작성을 지시하고, 이번 수정도 글로 남기라고 했다.

도입을 일반적인 조언에서 실제 요청으로 바꿨다

이전 1편은 이렇게 시작했다.

프로젝트 작업을 맡길 때 설명해야 할 것은 원하는 결과만이 아니다. AI가 어디에서 기존 자료를 찾고, 어느 파일을 수정하고, 결과를 어디에 남길지도 필요하다.

어느 프로젝트에 붙여도 맞는 설명이었다. 블로그가 왜 필요했는지, 무엇을 공개하지 않으려 했는지가 빠져 있었다.

9월 15일에 다시 쓴 도입은 다음과 같다. 이후 문체를 다듬었지만, 당시 바꾼 내용을 비교하려고 이 문장은 그대로 남겼다.

개발과 자동화에서 AI를 사용하며 생긴 작업 기록을 정리할 블로그가 필요했다. 업무 프로젝트의 코드·데이터·내부 운영 방식은 공개하고 싶지 않았다. 그래서 블로그 제작 자체를 공개 가능한 사례로 정하고, 기획부터 실패와 검증까지 기록하도록 AI에 요청했다.

바뀐 도입에는 블로그의 용도, 공개하지 않을 자료, AI에 맡긴 일이 들어갔다. 뒤에 나오는 승인 목록과 배포 검사를 왜 만들었는지도 이 조건에서 설명할 수 있었다.

누가 했는지는 실제 행동으로 적었다

초안에는 내가 요청하고 AI가 수정했다는 문장이 반복됐다. 무엇을 요청했고 어떻게 수정했는지를 더 써야 했다.

예를 들어 공개할 글을 제한하라는 조건은 내가 정했다. AI는 승인 목록과 파일 해시 검사로 구현하고, 비공개 자료가 빌드에서 빠지는지 테스트했다. 디자인에서는 내가 조건을 전달하고 시안을 골랐으며, AI가 참고 자료 조사와 시안 제작을 맡았다.

한·영 글이 충돌한 오류는 AI가 발견하고 수정했다. 당시 수정본에도 그 점을 명시했다.

이 오류를 발견하고 수정한 주체는 AI다. 내 역할은 한국어·영어 제공을 요구하고 실제 화면과 동작을 확인하도록 맡긴 것이었다.

이 문장 역시 9월 15일 수정본의 인용이다. 이후 표현을 줄일 때도 요청한 사람과 코드를 고친 주체는 바꾸지 않았다.

세 편을 합치고, 이미 있던 자료를 붙였다

경로 확인, 완료 보고 검토, 디자인 선택은 모두 같은 블로그를 만들 때 한 일이었다. AI는 이를 한 편으로 묶자고 제안했고, 재작성에 반영했다.

디자인 글의 표만으로는 네 안의 차이를 보기 어려워 당시 비교 이미지를 넣었다. 검증 설명에는 한·영 글이 충돌한 원인과 수정 코드, 다시 확인한 결과를 붙였다. 실제 배포 화면도 넣되, 시안의 옛 글 제목과 현재 글이 다르다는 점을 캡션에 적었다. 오류가 난 순간의 화면은 첨부하지 못해 작업 일지와 수정 코드로 설명했다.

합친 글은 AI에 블로그 구현을 맡긴 기록에서 볼 수 있다. 이 글에는 분석과 편집에 관한 내용을 따로 남겼다.

근거가 없는 설명은 채우지 않았다

AI가 제안한 보완 중에는 자료가 있는 것과 없는 것이 섞여 있었다. 시안과 검증 결과는 쓸 수 있었지만, 작업 시간이나 비용을 비교한 기록은 없었다. 그래서 생산성 향상을 수치로 덧붙이지 않았다. 디자인도 2번을 골랐다는 사실까지만 적고, 당시 말하지 않은 선택 이유는 만들지 않았다.

예를 들어 링크 검사 개수는 그 주소들을 확인했다는 기록이다. 그 수만으로 일이 빨라졌다거나 사람이 덜 개입했다고 말할 수는 없다.

이번에 사용한 방법을 다음 글에서도 쓸 수 있게 요청 예시로 정리했다. 아래는 작업 뒤에 만든 예시이며 실제 대화의 인용은 아니다.

최초 요구, 현재 초안, 작업 기록을 대조해.
글의 중요한 주장마다 근거와 판단 주체를 표시해.
일반적인 조언으로 끝난 부분은 실제 사례로 바꿀 수 있는지 확인해.
지금 가진 근거로 고칠 부분과 새 확인이 필요한 부분을 나눠.
그 분석을 바탕으로 구성을 제안하고, 수정 전후를 남겨.

구성을 고친 뒤에도 문장은 다시 손봤다

이 수정으로 세 편의 사용법을 한 편의 구축 사례로 합쳤다. 요청과 결과를 함께 설명하고, 시안과 검증 자료도 본문에서 볼 수 있게 했다. AI는 이전 초안과 수정본을 보관하고 한국어·영어 검토본을 만들었다.

하지만 실제 사례를 넣었다고 해서 글이 충분히 자연스러워진 것은 아니었다. 다음 검토에서도 핵심을 놓치고 한국어가 어색하다는 문제가 남았다. 그래서 한국어 글쓰기 스킬을 찾아 적용했다. 어떤 문장을 바꿨고 스킬만으로 해결하기 어려웠던 것은 무엇인지 한국어 편집 스킬 적용 기록에 이어서 적었다.