Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
AI 문서 지원 시, 초안보다 변경된 후의 일관성 확인이 중요합니다. 이 글은 가상의 사양과 작은 변경 지시를 사용하여 AI가 생성한 출력물의 변화 추적 방법을 제시하며, 특히 필드 대체와 같은 미세한 업데이트에 대한 검증 과정을 설명합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기설명문은 업데이트되었는데, 샘플만 오래된 채로 남아 있는 경우. 리뷰에서 발견하면 고칠 수 있지만, 문장이 자연스러우면 놓치기 쉽습니다. 문서 작성에 AI를 도입한다면, 처음 초안보다도 변경이 들어간 후의 일관성을 확인하고 싶습니다.
실제 리포지토리를 전달하기 전에, 가상의 사양과 변경 지시를 사용해 작게 시험해 봅니다. 기밀 정보가 포함되지 않은 짧은 소재라면, 입력부터 출력까지 스스로 추적할 수 있습니다. 여기서는 출력 필드를 하나 대체하는 예로 확인합니다.
가상의 노트 기능을 준비합니다. 첫 번째 출력은 제목(title), 본문(body), 업데이트 일시의 세 가지로 합니다. 보존 기간이나 인증 방식 등, 이 시험에서 정하지 않은 것은 쓰지 않습니다.
# 노트의 출력
- title: 제목을 표시한다
- body: 본문을 표시한다
...
이 짧은 사양을 서비스 외부에도 저장합니다. AI가 만든 설명을 유일한 기준으로 삼으면, 추가된 정보를 발견하기 어려워집니다. 원래 사양과 나중에 만들 변경 지시가 판단의 근거입니다.
데이터는 가상의 것을 사용합니다. 실제 사용자명이나 비공개 제품 사양을 사용하지 않아도, 변경이 반영되는지, 미결정 사항이 유지되는지는 시험할 수 있습니다. 일단 모든 것을 확인할 수 있는 크기로 좁힙니다.
짧은 설명, 필드 목록, 출력 예만 만들도록 요청합니다. 임의로 에러 처리나 대응 환경을 추가하지 않도록 전달합니다. 자연스러운 소개문을 요구하기보다, 무엇을 확인하고 싶은지가 명확해집니다.
첫 번째 응답은 고치지 않고 저장합니다. 사양에 없는 기본값이 들어있지는 않은지, 미결정된 일시 형식이 확정된 것처럼 쓰여 있지는 않은지 봅니다. 가독성과 사양에 대한 충실도는 분리해서 확인합니다.
작업의 구획을 생각할 때는, 사람의 확인 과정을 포함한 AI 워크플로우 정리도 참고할 수 있습니다. 다만, 이 예시에서의 판단 자료는 제가 준비한 사양과 응답입니다. 일반적인 설명을 특정 도구의 동작 확인 대신에 사용해서는 안 됩니다.
다음으로, updatedAt을 출력하지 않고 대신 author를 내보내는 변경을 전달합니다. title과 body는 변경하지 않습니다. 변경 전 설명도 남겨두어 어디가 업데이트되었는지 비교할 수 있게 합니다.
변경 내용:
- updatedAt의 출력을 중단한다
- author를 추가하여 작성자를 표시한다
...
먼저 기대하는 변경 부분을 적습니다. 설명문, 필드 목록, 출력 예 세 곳입니다. AI의 응답을 보고 나서 정답을 결정하면, 업데이트 누락을 편리하게 놓치게 됩니다.
이미지의 흐름도 이 대체(置き換え)를 나타냅니다. 그림은 시험 절차에 대한 설명이며, 특정 서비스에서 성공한 결과를 보여준 것이 아닙니다. 자신의 후보로는 같은 확인을 실시하여 기록합니다.
처음에는 updatedAt이 남아있지 않은지 검색합니다. 그 후, author가 필요한 곳에 추가되었는지 봅니다. 새로운 단어가 한 번 나왔다고 해서 모든 것이 반영되었다고 판단하지 않습니다.
계속해서, 변경 대상이 아닌 title과 body를 검토합니다. 짧은 수정만으로도 다른 설명까지 바뀐다면, 리뷰 범위가 넓어집니다. 수정 요청을 내는 시간뿐 아니라, 다시 확인하는 수고도 기록하고 싶습니다.
미결정 사항에도 주의합니다. author의 형식을 정하지 않았다면, 이름 길이나 필수 조건을 임의로 추가해서는 안 됩니다. 필요한 정보가 부족할 때는, 소유자에게 질문으로 남기는 것이 다루기 쉽습니다.
어려운 채점표는 필요 없습니다. 확인할 문, 근거가 되는 사양, 결과 세 가지가 있으면 시작할 수 있습니다. 결과는 '확인 완료', '수정 필요', '판단 자료 부족'으로 나눕니다.
| 확인 항목 | 근거 | 결과 |
| --- | --- | ---
| updatedAt이 출력 설명에 남아있지 않은지 | 변경 지시 | 미확인 |
...
표의 '미확인'은 실제로 조사한 후에 업데이트합니다. 초안이 잘 갖춰졌다는 것을, 확인이 끝난 표시로 삼지 않습니다. 같은 자료를 다른 사람이 봐도, 무엇을 근거로 판단했는지 추적할 수 있는 형태를 목표로 합니다.
승인한 문서를 실제로 사용하는 문서 편집 화면으로 옮깁니다. 제목, 목록, 필드명, 코드 예시의 표시를 확인합니다. 생성 화면에서 읽을 수 있어도, 옮긴 후에 목록이 무너지는 경우가 있습니다.
다른 사람에게 그 페이지만 읽게 하고 출력 내용을 설명해 달라고 합니다. 제가 구두로 보충하면 아는 것이 아니라, 페이지 단독으로 같은 사양을 전달할 수 있는지 보고 싶습니다. 질문이 나온 곳은 개선의 실마리가 됩니다.
입력 준비, 초안 확인, 변경 후 재확인, 붙여넣기 수정을 나누어 기록합니다. 생성 속도만으로는 실제로 줄어든 작업량을 알 수 없습니다. 한 번 만들는 틀과 매번 필요한 수정도 구분해야 합니다.
실제 프로젝트에 적용하기 전에, 제공처의 현재 요금, 사용 범위, 데이터 처리 방식을 확인해야 합니다. 체험 기간 동안 사용할 수 있었던 기능이 선택할 플랜에 포함되지 않을 수도 있습니다. 확인할 수 없는 조건은 미확인 상태로 남겨둡니다.
원래 사양, 변경 지시, 응답, 승인된 문서를 함께 보관합니다. 다음 후보도 같은 주제로 시도하면 비교하기 쉽습니다. 먼저 하나의 작은 업데이트로 사용해보고, 정확한 페이지를 무리 없이 완성할 수 있는지 확인한 후에 범위를 넓히고 싶습니다.
