콘텐츠로 이동

비개발자가 AI가 만든 변경을 검수하는 법: 지시서 → 제작 → 검수 → 수정 루프와 실제 파일(2026)

Last verified:

  • 2026-10-25: 원자료 대조와 정확 치환·2차 수정 시트 반영 후 발행.

비개발자가 AI가 만든 변경을 검수하는 방법은 모든 요청을 검사할 수 있는 파일로 바꾸는 것입니다. 숫자 상한이 든 지시서를 쓰고, 결과는 원자료와 따로 대조하며, 수정은 ’지금 문장 → 바꿀 문장’의 정확한 쌍으로 적어 각각 정확히 1번 맞을 때만 적용합니다. 2026년 10월 24일 발행한 모델 벤치마크 글에서 이 루프가 기록한 수정은 57건 — 정확 문자열 치환 54건과 CSV 셀 3개였습니다. 원자료와 대조하자 지시서에 담긴 본문에서 불일치 7유형이 나왔고, 그중 2유형(과금·지연)은 2차 수정이 필요했습니다. 같은 주의 사이트 정리 지시서에서는 지시 2건을 근거와 대조한 뒤 적힌 대로 실행하지 않았습니다(하나는 플랫폼 공식 문서, 하나는 비용 기록의 빈칸 정의 기준). 지시서·검수 시트 2개·빈 템플릿은 맨 아래에 있습니다.

항목 수 출처
이 글에서 선택한 작업 지시서·검수 시트 7 작업 지시서 4개(사이트 골격·벤치마크 글·사이트 정리·이메일 폼)와 검수 시트 3개(비용 글 수정·벤치마크 검수 2차례). 한 주 전체 작업의 총개수를 뜻하지 않음
발행한 글 2 비용 기록(10/22), 모델 벤치마크(10/24)
기록된 벤치마크 글 수정 57 1차 문자열 치환 42건 + CSV 셀 3개, 2차 문자열 치환 12건. 발행 메타데이터는 별도
적용 시 정확히 1회 매칭된 문자열 치환 54 / 54 보존된 수정 전 스냅샷에서 순서대로 재계산. 넘기기 전 모든 시도를 측정한 기록은 아님
원자료 대조에서 나온 불일치 유형 처음 7, 이후 남은 2 두 번째 검수는 7유형 중 과금·지연을 다시 다룸
근거와 대조한 뒤 적힌 대로 실행하지 않은 지시 2 리다이렉트는 플랫폼 공식 문서, 비용 칸 2개는 원자료 캡처와 CSV 빈칸 정의에 근거
벤치마크 글 작성·수정 작업의 유료 API 호출 보고상 0회 해당 작업 보고서의 실행 범위. 10월 20~25일 계정 전체 호출 수를 입증한 것은 아님

예제 지시서는 다섯 부분으로 구성됩니다. 전제에는 무엇이 어디에 있고 지난 실행이 무엇을 만들었는지 적습니다. 절대 규칙에는 승인 없는 커밋·푸시 금지, 시크릿 출력·하드코딩 금지, 유료 API 호출이 범위에 있을 때의 숫자 상한, 결제·권한 오류 시 중단, 건드리면 안 되는 파일을 적습니다. 할 일에는 정확한 파일·입력·문구와 필요한 자리표시자를, 검사에는 명령과 통과 조건을 적습니다. 보고 형식에는 지시서와 원자료가 다른 곳을 적는 [불일치]와 입증하지 못한 주장을 적는 [미확인]을 둡니다.

9월 4모델 비교 작업 하나에는 총 8회·예상 비용 $0.80 상한이 있었습니다. 다른 실험의 상한은 달랐습니다. 이는 그 비교 작업의 요청 범위이며, 비용 글은 별도로 월별 사용 CSV와 결제·잔액 기록을 대조했습니다. 지출 상한만으로 실제 사용액이나 요청별 과금이 입증되지는 않습니다.

이 예제에서 모든 문자열 수정은 현재 문장과 바꿀 문장의 정확한 쌍으로 적었고, 맞지 않는 쌍은 적용하지 않고 보고하게 했습니다. 안전 확인은 각 치환 직전에 대상 파일의 찾기 문자열을 세고, 정확히 1회가 아니면 멈추는 것입니다. 보존된 스냅샷에서 1차 문자열 치환 42건과 2차 12건은 적용 시 각각 1회 매칭됐습니다. CSV 셀 3개는 별도로 수정했습니다. 따라서 두 차례 합계는 문자열 치환 54건과 셀 수정 3건, 총 57건입니다.

비개발자에게 이게 중요한 이유는 “글 고쳐”가 감사 가능한 일로 바뀌기 때문입니다. 모든 변경이 전/후 한 줄로 보이고, 페이지를 그리는 코드를 읽지 않아도 시트는 읽을 수 있습니다.

발행 전에 불일치 7개를 찾았다. 지시서로 만든 벤치마크 글을 원자료 보고서와 대조하자, 지시서에 담긴 본문에서 불일치 7개가 나왔습니다. 반올림한 수를 다시 반올림한 평균(13.55초를 13.6초로; 원시 평균은 13.546초), 월 합계뿐인데 타임아웃 요청이 “과금됐다”고 단정한 문장, 프롬프트 길이에 대한 인과 주장, 기록으로 라이선스를 확인할 수 없는 스톡 사진에 붙은 “licensed”, 사용량 자료만으로는 증명 못 하는 “9월까지 멈췄다”, 발행 전인데 “발행”이라 적은 changelog, 측정을 넘어선 지연 문장. 첫 검수 시트가 이 유형들을 다뤘습니다. 적용 뒤에도 과금·지연 2유형은 근거를 넘어서 있었고, 두 번째 시트에서 그 주장을 더 좁혔습니다. 발행된 페이지에는 좁힌 표현이 실려 있습니다.

지시를 플랫폼 문서와 대조했다. 사이트 정리 지시서는 www를 루트 도메인으로 보내는 _redirects 파일을 요구했습니다. 플랫폼의 리다이렉트 문서는 그 파일에서 도메인 단위 리다이렉트를 지원하지 않는다고 적고 있어 파일은 만들지 않았고, 지원되는 방법(프록시된 DNS 레코드 + 계정 단위 bulk redirect)을 대신 적었습니다. 2026년 10월 25일 읽기 전용 확인에서 HTTP 301 응답이 경로와 쿼리를 유지하는 것을 확인했습니다.

0을 증명할 수 없는 두 칸은 비워 뒀다. 같은 지시서는 청구 목록이 비어 있으니 호스팅 행의 결제액·사용액 칸을 0으로 쓰라고 했습니다. 두 칸 모두 비워 뒀습니다. “청구서 없음”은 캡처에 대한 관찰이지 검증된 합계가 아니고, 비용 기록은 금액의 빈칸을 “미확인 또는 해당 없음이며 0이 아닙니다”라고 정의하기 때문입니다.

근거 없는 주장이 검수를 통과할 수 있고, 원자료 대조도 오류를 놓칠 수 있습니다. 공식 문서 확인·정확 매칭 검사·지출 상한·검수 전 초안 유지는 확인 작업을 정리하는 장치이며 정확성의 보장은 아닙니다. 이 사례에도 측정 공백이 있습니다. 경과 시각은 남아 있지만 사람의 실제 작업시간·계정 전체 API 호출 수는 측정하지 않았습니다. 보고서의 [미확인] 절도 대조할 대상이며, 빠뜨린 것이 없다는 증명은 아닙니다.

이 페이지도 같은 루프를 거쳤다

섹션 제목: “이 페이지도 같은 루프를 거쳤다”

이 페이지의 첫 초안도 같은 주의 파일과 대조했고 불일치 7개가 나왔습니다 — 수정 57건을 문자열 쌍 57개로 쓴 것, 지출 상한을 비용이 맞아떨어진 이유로 쓴 것, 확인 가능한 측정 기록으로 뒷받침되지 않은 주장 3개(손수정 줄 수, 사람의 실제 작업시간, 계정 전체 API 호출 수) 등. 발행 전에 영문·한국어판 합계 46건의 정확 치환으로 고쳤고, 측정 근거가 없는 주장은 추정치로 채우지 않고 지웠습니다. 이어 두 번째 시트로 각 단계를 누가 쓰고 찾고 실행했는지에 관한 문장을 지우고, 몇몇 세부를 같은 원자료에 맞춰 좁혔습니다. 누가 했는지는 결과가 맞는지 보여 주지 않습니다. 결과를 원자료와 대조해야 알 수 있습니다.

예제의 로컬 경로·제품명·개인 파일명 패턴·작성자 식별자를 익명화했고, 영문 지시서는 번역본입니다. 과거 지시서와 그 안의 초안에는 나중에 고친 문구도 남아 있습니다. 검수 시트와 함께 읽는 실제 예제이며 현재 지침으로 사용하지 않습니다. 추가 검수 기록과 모의 실행이 기본인 검수 시트 적용 스크립트는 NonDev Launch Kit에 포함되어 있습니다.

FAQ

코드를 읽을 줄 알아야 하나요?

이 페이지의 단계에는 필요 없습니다. 지시서·보고서·검수 시트는 평범한 문장의 마크다운이고, 모든 수정은 원자료와 대조할 수 있는 전/후 쌍으로 적습니다. 기술 검사(타입 검사·빌드·사이트 검사)는 여전히 돌려서 통과해야 합니다.

원자료와 대조하면 무엇이 걸리나요?

이 기록에서는 지시서에 담긴 본문에서 불일치 7유형이 걸렸습니다. 두 번 반올림한 평균부터 근거를 넘어선 과금·지연 주장까지입니다. 그중 과금·지연 2유형은 1차 수정 뒤에도 근거를 넘어서 있어 다시 좁혔습니다. 이 페이지의 첫 초안에서도 불일치 7개가 나왔습니다.

에이전트가 비싸거나 되돌릴 수 없는 일을 하는 걸 무엇이 막나요?

예제 지시서는 승인 없는 커밋 금지, 시크릿 출력 금지, 유료 API 호출이 범위에 있을 때의 숫자 상한, 결제·권한 오류 시 중단 같은 경계를 적습니다. 적힌 규칙은 결과와 대조할 지시이며, 그 자체가 기술적으로 실행을 차단하는 장치는 아닙니다.

이 루프로 글 한 편에 얼마나 걸리나요?

파일 메타데이터에는 벤치마크 지시서 생성이 2026년 10월 24일 18:35 KST로, 저장된 실제 사이트 검증은 22:18 KST로 기록돼 있습니다. 그 사이는 약 3시간 43분입니다. 파일과 검증 시각의 간격이지 생산성을 타이머로 측정한 값은 아니며, 사람의 실제 작업시간은 기록하지 않았습니다.

어디서 실패하나요?

근거 없는 주장이 검수를 통과할 수 있습니다. 결과를 원자료·기술 검사와 대조하면 다시 확인할 기회가 생기지만, 이 예제들이 정확성을 보장하지는 않습니다. 이 기록에서 지시 2건은 근거와 대조한 뒤 적힌 대로 실행하지 않았지만, 그것이 모든 오류가 왜 잡혔거나 놓쳤는지를 입증하지는 않습니다.

출처