AI가 자료를 모으고 문장 초안을 만들면 작성 시간은 줄어든다. 내 이름으로 결과를 공개하거나 고객에게 제출할 때는 근거와 표현을 설명할 책임이 남는다. 모델이 작업에 참여했다는 사실은 오류가 생겼을 때 독자에게 답하는 사람을 바꾸지 않는다.
참고자료를 넣고 요약을 맡겼을 때 비슷한 주제의 숫자가 한 문단에 섞인 적이 있다. 문장은 자연스러웠지만 원문에서 같은 수치를 찾을 수 없었다. 초안을 빠르게 받은 뒤 각 주장과 표를 다시 대조했다. 그 작업을 계기로 생성 상태와 확인 상태를 데이터에서 분리했다.
NIST의 네 기능을 작업 순서로 읽는다
NIST AI Risk Management Framework의 Core는 Govern, Map, Measure, Manage로 구성된다. NIST는 이 기능을 고정된 체크리스트나 단일 순서로 규정하지 않는다. 조직이 AI 시스템의 전체 생명주기에서 반복해서 적용할 결과와 행동으로 설명한다.
나는 네 기능을 개인 작업에도 맞춰 사용한다.
| 기능 | 작업에서 확인할 내용 |
|---|---|
| Govern | 승인자, 권한, 기록 보존과 사고 보고 규칙 |
| Map | 사용 목적, 독자, 오류가 미칠 영향과 사용 범위 |
| Measure | 출처 대조, 테스트, 샘플 평가와 알려진 한계 |
| Manage | 배포 여부, 수정, 중단, 복구와 후속 모니터링 |
새 도구를 고를 때 모델 성능부터 비교하면 사용 맥락을 놓친다. 먼저 누가 결과를 읽고 어떤 결정을 내릴지 적는다. 같은 요약 모델도 개인 메모와 공개 투자 보고서에서 필요한 검증 수준이 다르다.
NIST의 Govern 항목은 인간과 AI의 역할, 책임, 소통 경로를 문서화하도록 요구한다. “최종 책임은 사람”이라는 문장에는 담당자와 입력 자료가 없다. 승인자가 어느 단계에서 무엇을 보고 반려할 수 있는지 적어야 한다.
생성, 검증, 승인을 다른 상태로 둔다
내 작업에는 다음 상태를 사용한다.
generated AI가 만든 후보이며 사실로 승인되지 않음
verified 원문, 계산 또는 실행 결과와 대조함
approved 공개 맥락과 위험을 사람이 검토함
published 승인된 버전을 외부에 전달함
verified에는 확인 방법을 붙인다. 글의 주장은 출처 URL과 근거 위치를 기록한다. 계산 결과는 입력 파일의 해시와 실행 명령을 남긴다. 코드 변경은 diff와 테스트 로그를 보관한다.
approved에는 승인자와 시각, 승인 범위를 적는다. 법률 문구를 전문가가 확인했더라도 전체 문서의 데이터 정확성까지 승인한 것으로 기록하지 않는다. 승인 범위를 필드로 남기면 책임을 한 사람에게 모호하게 넘기는 일을 줄일 수 있다.
status: approved
approved_by: ck
approved_at: 2026-08-17T14:30:00+09:00
scope: publication_and_sources
evidence_bundle: reviews/post-021.json
문장의 유창함은 상태를 올리는 조건이 아니다. 검증 증거가 없으면 generated에 남는다. 수정이 생기면 이전 승인을 그대로 재사용하지 않고 바뀐 범위가 승인 대상에 포함되는지 확인한다.
오류의 영향으로 검수 수준을 나눈다
작업마다 같은 검수 시간을 쓰면 낮은 위험의 자동화도 비용이 커진다. 결과가 틀렸을 때 누가 어떤 피해를 입는지 기준으로 등급을 정한다.
| 등급 | 작업 예시 | 검수와 실행 경계 |
|---|---|---|
| 낮음 | 개인 메모 정리, 비공개 제목 후보 | 표본 확인, 외부 쓰기 없음 |
| 중간 | 공개 글, 내부 분석 초안 | 출처와 계산 전수 대조, 사람 승인 |
| 높음 | 재무·법률·인사 판단 | 해당 분야 전문가 검토, 제한된 데이터 접근 |
| 실행 | 메일 발송, 데이터 삭제, 권한 변경 | dry-run, 대상 확인, 별도 실행 승인 |
높은 위험의 판단은 이 글의 체크리스트만으로 처리하지 않는다. 재무와 법률, 의료처럼 전문 자격과 최신 규정이 필요한 영역에서는 전문가가 원자료와 맥락을 검토해야 한다. AI가 만든 설명은 검토 대상을 정리하는 데 쓸 수 있다.
외부 시스템 쓰기는 내용 위험과 별도로 분리한다. 무해한 문장도 잘못된 수신자에게 전송하면 사고가 된다. 데이터 삭제와 권한 변경은 되돌릴 수 있는지 확인하고, 대상 ID를 실행 전에 출력한다. 초안 작성 권한이 배포 권한까지 포함하지 않도록 도구 설정을 나눈다.
증거 묶음을 결과와 함께 저장한다
최종 문서만 보관하면 나중에 어떤 자료를 확인했는지 알기 어렵다. 나는 결과 옆에 증거 묶음을 만든다.
입력 자료 목록과 접근 시각
AI가 만든 초기 출력
사람이 수정한 diff
실행한 검사와 결과
남아 있는 불확실성
승인자와 승인 범위
게시한 버전의 해시
출처가 수정되거나 독자가 오류를 제보하면 당시 근거를 재현할 수 있다. AI 프롬프트에 개인정보가 들어갔다면 원문 전체를 무기한 저장하지 않고 조직의 보존 정책에 맞춰 필요한 메타데이터만 남겨야 한다.
증거 묶음은 검토 시간을 줄이기도 한다. 승인자는 긴 대화 기록을 읽지 않고 변경된 문장과 근거 위치를 확인한다. 다음 편집자는 이미 검증한 범위와 새로 검증할 범위를 구분할 수 있다.
체크리스트는 불안을 검사 항목으로 바꾼다
결과를 내보내기 전에 찜찜한 지점이 생기면 문서를 처음부터 다시 읽지 않는다. 확인할 질문을 기록한다.
- 숫자의 원문, 단위, 기준 시점 기록
- 결론과 충돌하는 자료 검색
- 모델이 추가한 고유명사와 인용 확인
- 실행한 명령과 변경 파일의 diff 확인
- 실패 시 사용할 복구 사본과 절차 준비
- 실제 독자와 사용 맥락을 아는 승인자 지정
질문에는 예 또는 아니오와 근거를 남긴다. “대체로 확인함” 같은 답은 승인 증거가 되지 않는다. 검사할 수 없는 항목은 담당자와 기한을 정하거나 공개 범위에서 제외한다.
체크리스트도 작업 후에 갱신한다. 새 오류가 발생하면 원인을 분류하고, 반복 가능성이 있는 경우 검사나 발행 규칙으로 옮긴다. 항목이 계속 늘어나면 위험 등급별로 필요한 질문만 보여 준다.
사고가 생겼을 때 승인 기록을 사용한다
오류를 발견하면 게시물을 고치는 데서 끝내지 않는다. 어느 상태 전이가 잘못됐는지 찾는다. generated 문장이 검증 없이 공개됐는지, 검증 방법이 부족했는지, 승인 범위 밖의 수정이 게시됐는지 확인한다.
발견 시각과 신고자
영향받은 결과와 독자
잘못된 주장 또는 실행
즉시 취한 조치
원인과 누락된 통제
재발 방지 변경
외부 공지 여부
공개 글의 사실 오류는 수정 시각과 내용을 독자에게 알릴 수 있다. 외부 시스템 쓰기 오류는 추가 실행을 멈추고 복구 절차를 따른다. 사고 기록은 상태와 승인 절차를 고칠 자료이며 개인 책임을 추궁하는 용도로 쓰지 않는다.
절약한 시간을 판단에 배정한다
AI가 만든 여유를 다른 생성 작업으로 채우면 산출물 수만 늘어난다. 나는 자동화 전후에 고가치 활동 시간을 기록한다.
- 원문과 데이터에서 반례를 찾은 시간
- 고객과 동료에게 질문하고 맥락을 들은 시간
- 결과를 내 언어로 설명하고 결정한 시간
- 오류 유형을 검사 규칙으로 옮긴 시간
자동화가 생성 시간을 줄였어도 검증 시간이 늘 수 있다. 전체 소요 시간과 오류율, 사람이 판단에 쓴 시간을 함께 비교한다. 공개 문서 수가 늘었는데 수정 요청도 함께 늘면 생산성 향상으로 기록하지 않는다.
AI가 담당하는 작업 비율은 바뀔 수 있다. 책임의 위치는 도구 사용량으로 계산할 수 없다. 결과를 공개하는 사람과 조직은 사용 목적과 검증 증거, 승인 범위를 설명해야 한다. 나는 자동화가 판단을 숨기지 않도록 상태와 증거 묶음, 실행 경계를 작업 흐름 안에 둔다.