AI 가 작성한 문서를 사람이 다시 손보는 시간 측정

"AI가 쓰면 빠르다"는 말이 위험한 이유

우리는 작은 팀이다. 결제 연동, 정산 자동화, 정책 문서화를 동시에 돌리면서 기술 문서 작성은 언제나 후순위로 밀린다. 그러니 "AI 쓰면 문서 시간 확 준다"는 말은 솔깃할 수밖에 없었다. 그런데 그 말을 그냥 믿고 도입했다가 오히려 특정 문서에서 시간이 더 걸리는 경험을 반복했다. 결국 직접 측정하기로 했다.

측정 전에 가장 먼저 인식한 건, 우리 문서가 일반적인 개발팀 문서와 맥락이 다르다는 점이다. 결제 시스템에서 잘못된 문서는 단순히 "헷갈리는 설명"으로 끝나지 않는다. 정산 주기가 틀리게 기술되거나, 환불 정책의 예외 조건이 빠지면 실제 금액 오차로 이어진다. 즉, 우리에게 문서 품질은 운영 리스크와 직결된다. 속도와 정확도 사이의 트레이드오프가 다른 도메인보다 훨씬 날카롭다.

측정 방법: 우리가 정의한 "완료"

3주 동안 작성된 기술 문서 12건을 두 방식으로 나눴다. 첫 번째는 처음부터 사람이 쓴 것, 두 번째는 AI 초안을 사람이 검토·수정한 것이다. 소요 시간의 기준은 "작업 시작"부터 "팀 내 공유 가능 상태"까지로 정의했다. 공유 가능이란 단순히 초안이 완성된 게 아니라, 팀원 누구든 참조해도 오해가 생기지 않는 수준을 의미한다.

이 정의가 중요한 이유가 있다. AI 초안은 빠르게 텍스트를 채우지만, 우리 도메인에서는 "그럴싸하게 들리지만 틀린 문장"이 자주 나온다. 예를 들어 정산 배치 처리를 설명할 때 AI가 "T+1 기준으로 처리된다"고 쓰면, 실제 우리 시스템은 영업일 기준 T+2이기 때문에 그 한 줄이 잘못된 운영 판단을 낳는다. 그래서 "초안 완성 시간"이 아닌 "공유 가능 상태"를 기준으로 잡았다.

결과 분류: 세 가지 유형이 나뉘었다

첫째, AI가 유리한 유형: 형식이 고정된 문서. API 스펙 문서, 환경설정 가이드, 정산 체크리스트처럼 구조와 항목이 표준화된 문서에서는 AI 초안이 평균 40% 빠르게 완성됐다. 우리가 PG사와 연동할 때 작성하는 "웹훅 이벤트 타입 정의서" 같은 경우가 대표적이다. 항목 이름, 타입, nullable 여부, 설명 형식이 반복되는 이 문서에서 AI는 구조 잡기와 초기 문구 채우기를 빠르게 처리했다. 사람은 값과 비즈니스 규칙만 확인하면 됐다.

둘째, AI가 불리한 유형: 판단과 맥락이 담긴 문서. "우리가 이 정산 구조를 선택한 이유", "멱등성 처리 방식의 트레이드오프 정리", "이번 장애에서 우리가 잘못 판단한 부분"처럼 맥락과 의사결정 근거가 핵심인 문서는 AI 초안을 받은 쪽이 평균 20% 더 오래 걸렸다. AI가 쓴 초안은 틀리지 않은 것처럼 보이지만, 우리의 실제 결정 이유와는 다른 방향으로 서술돼 있었다. 그걸 교정하는 인지 비용이 처음부터 쓰는 것보다 높았다. 마치 남이 잘못 채운 스프레드시트를 수정하는 것처럼, 내용이 있다는 사실 자체가 오히려 방해가 됐다.

셋째, 거의 같은 유형: 재료가 있는 사후 정리 문서. 회의 결정 사항 요약, 장애 회고처럼 이미 원본 재료(로그, 슬랙 스레드, 회의록)가 존재하는 문서는 두 방식 간 시간 차이가 5% 이내였다. AI는 재료 요약은 잘 하지만, 우리가 직접 쓸 때도 재료가 있으면 빠르기 때문에 차이가 상쇄됐다.

결제·정산 도메인에서 이 차이가 특히 큰 이유

일반적인 개발 문서와 달리, 우리가 다루는 문서에는 "도메인 특화 암묵지"가 짙게 깔려 있다. 예를 들어 "취소"와 "환불"은 일상어로는 비슷해 보이지만, 우리 정산 로직에서는 취소는 당일 거래 무효, 환불은 정산 완료 후 역분개라는 전혀 다른 프로세스다. AI는 이 구분을 맥락 없이 쓰면 섞어 쓴다. 그리고 그걸 읽는 팀원이나 외부 파트너가 잘못 이해하면, 정산 오류가 발생한 뒤에야 문서 문제를 역추적하게 된다.

자동화 파이프라인 문서도 마찬가지다. 스케줄러 실패 시 재시도 정책, 멱등 키 범위, 정산 락 해제 조건 같은 항목은 우리 시스템의 구체적 설계 결정이 반영돼야 한다. AI가 "일반적으로는 이렇게 한다"는 수준의 문장을 쓰면, 그게 우리 시스템에 맞는지 검증하는 데 오히려 더 많은 시간이 든다. 이 유형에서 AI 초안이 불리했던 20%의 초과 시간은 단순히 편집 시간이 아니라, "이게 우리 시스템에 맞는 말인가"를 다시 생각하는 판단 비용이었다.

우리가 실제로 바꾼 운영 방식

측정 결과를 반영해 문서 유형별로 AI 활용 방식을 세 가지로 나눴다.

형식 문서(API 스펙, 체크리스트, 환경설정 가이드): AI 초안을 기본으로 사용. 단, 값과 조건부 로직은 사람이 반드시 1차 검수. 특히 nullable 여부, 화폐 단위, 날짜 기준(UTC vs KST)은 AI가 추론한 값이 틀릴 가능성이 높아 체크리스트를 고정해뒀다.

의사결정 문서(설계 이유, 트레이드오프, 회고 핵심 판단): AI 초안 금지. 담당자가 먼저 핵심 주장을 두세 줄 써두고, 그 구조를 바탕으로 살을 붙이는 방식을 쓴다. AI는 이후 문장 다듬기나 오탈자 확인 용도로만 활용한다. 초안의 방향이 이미 우리 것이어야, 수정이 아니라 개선이 된다.

재료 기반 정리 문서(회의록, 장애 요약): AI 요약 → 사람 확인의 2단계로 고정. 여기서 AI의 역할은 재료를 빠르게 구조화하는 것이고, 사람의 역할은 "이 결정의 이유"와 "다음 액션의 책임자"를 명확히 하는 것이다. 이 두 가지는 AI가 알 수 없다.

지금 당장 쓸 수 있는 판단 기준

측정 결과에서 도출한 실행 기준을 아래에 정리한다. 긴 글을 읽을 시간이 없는 팀이라면 이것만 챙겨도 된다.

1. 문서를 분류하기 전에 AI 도구 정책을 만들지 말 것. "AI 써라/쓰지 마라"가 아니라 "이 문서에 AI를 어디에 쓸 것인가"가 질문이어야 한다. 구조 잡기, 초기 문구 생성, 문법 교정은 AI가 잘한다. 판단 근거 서술과 도메인 특화 규칙 적용은 사람이 해야 한다.

2. AI 초안을 받기 전에 핵심 주장 한 줄을 먼저 쓸 것. 특히 결제·정산 도메인에서는 "이 문서가 말하려는 것"이 뚜렷하지 않으면 AI가 그럴싸하지만 틀린 방향으로 초안을 채운다. 한 줄 방향만 정해도 교정 비용이 크게 준다.

3. AI가 쓴 도메인 특화 값은 반드시 원본 소스와 대조할 것. T+1/T+2 구분, 취소/환불 정의, 정산 기준일 같은 항목은 AI가 일반적 관행을 기준으로 쓴다. 우리 시스템의 실제 스펙과 다를 수 있으므로, 이 항목들은 반드시 코드나 정책 원본과 대조하는 체크리스트를 문서 작성 프로세스에 박아둬야 한다.

4. "빨라졌다"는 체감을 수치로 검증할 것. 시간 측정이 번거롭다면 간단하게라도 기록하라. "AI 쓰니까 빠른 것 같다"는 체감은 형식 문서에서의 경험이 판단 문서에도 투영된 것일 수 있다. 한 달에 한 번이라도 유형별 소요 시간을 비교하면, 팀의 실제 병목이 어디 있는지 보인다.

이 글은 통계적으로 유효한 실험이 아니다. 12건, 3주, 단일 팀이라는 한계는 명확하다. 그러나 "AI = 빠름"이라는 전제를 검증 없이 운영에 박아두는 것보다는, 작게라도 직접 측정하고 유형을 나누는 쪽이 낫다. 적어도 우리는 어떤 문서에 AI를 쓰면 안 되는지를 알게 됐다. 그것만으로도 측정할 가치가 있었다.

— by slecs