AI에 같은 일을 두 번째 시켰는데 결과가 처음과 다릅니다. 지난주에는 표가 있던 자리에 이번에는 긴 문장이 와 있고 지난번에 하지 말라고 한 것을 이번에는 다시 합니다. 그때마다 사람이 다시 설명하고 다시 고치면, 맡긴 것인지 옆에서 붙들고 있는 것인지 알 수 없어집니다.
AI로 일하는 개발사를 고르는 분도 비슷한 걱정을 합니다. 시연 때는 잘 되던 것이 실제 프로젝트에서도 같은 품질로 나올지, 담당자가 바뀌어도 같은 방식으로 진행될지 묻고 싶어집니다.
이 글은 설계 연재의 다섯 번째입니다. 앞 편에서는 설계 절차, 외주 전에 받을 설계 문서, 만드는 쪽과 검사하는 쪽을 나눈 검사 체계, 업무 흐름이 끊긴 곳을 반복 점검으로 찾는 방법을 이야기했습니다. 이번에는 그 밖에도 되풀이되는 일을 AI가 매번 같은 방식으로 하도록 "작업 지침서"로 남겨 둔 이야기입니다.
작업 지침서는 판단을 적는 문서가 아닙니다
작업 지침서는 AI에게 주는 문서로, 일의 순서·하지 말아야 할 것·확인하는 방법·끝났다고 볼 조건을 적습니다. 반대로 적지 않는 것이 있습니다. 무엇을 할지, 여러 안 가운데 어느 것을 고를지 같은 판단입니다. 판단은 그때의 사람과 상황이 합니다.
이 구분이 연재 앞 편과 같은 생각입니다. 반복 점검을 차수로 반복할 때도 고정한 것은 순서와 금지, 끝나는 조건뿐이었고 무엇을 볼지는 고정하지 않았습니다. 지침서도 같습니다. 순서와 금지는 고정해야 매번 같은 방식이 되고 판단은 열어 두어야 다른 프로젝트에도 쓸 수 있습니다.
아래 세 지침서는 모두 이노자일 대표가 직접 만들어 지금 쓰는 것입니다.
첫째, 결과물 모양이 매번 같아집니다
첫 번째는 데이터 구조 설계도(ERD) 지침서입니다. 업무 시스템은 데이터베이스에 수십, 수백 개의 표를 두고 표끼리 어떻게 이어지는지가 설계의 뼈대가 됩니다. 이 설계도를 사람이 그림 도구로 그리면 그릴 때마다 모양이 달라지기 쉽고 표 하나를 고치면 그림과 실제가 어긋나기 쉽습니다.
지침서는 이렇게 동작합니다. 데이터베이스 표 정의에서 원본 데이터를 먼저 만들고 그 원본으로 설계도 문서를 매번 같은 방식으로 다시 만들어 냅니다. 표마다 클릭하면 상세가 보이는 화면, 번호 매기는 규칙, 개발자 안내까지 한 파일에 담깁니다. 만든 결과는 세 가지 자동 검사를 통과해야 내보냅니다.
지침서의 핵심은 한 줄입니다. 내보낸 설계도를 손으로 고치지 않는다. 원본을 고쳐 다시 만들고, 검사를 통과한 것만 내보낸다. 이 한 줄이 있어서 설계도를 몇 번 다시 만들어도 같은 모양으로 나옵니다.
프로젝트마다 다른 것은 따로 둡니다. 표 이름의 앞머리, 번호 매기는 형식, 표끼리 잇는 방식은 프로젝트별 설정 파일 하나에 적습니다. 그래서 지침서 자체는 특정 회사나 업종에 묶이지 않습니다. 설계도 문서가 아예 없는 새 프로젝트도 인터뷰로 시작할 수 있습니다.
실제로 통신 서비스 회사의 구매·자산 관리 시스템 설계도를 이 방식으로 관리하고 있습니다. 지금 표 124개, 표 사이 연결 143개, 칸 1,298개입니다. 이 규모에서도 고칠 때 하는 일은 원본을 고치고 다시 만드는 것입니다.
둘째, 확인하는 방법이 일 안에 들어갑니다
두 번째는 기능 시연 영상 지침서입니다. 기능을 보여 주는 영상은 흔히 화면을 녹화하고 나중에 자막을 입힙니다. 그런데 그 영상은 "화면이 그렇게 보였다"는 것만 말해 줄 뿐, 실제로 저장이 됐는지는 말해 주지 않습니다.
지침서는 녹화와 확인을 떼어 놓지 않습니다. 웹 화면을 실제로 조작하면서 저장된 값으로 결과를 판정하며 녹화합니다. 조작마다 한국어 설명 음성, 조작한 자리 확대, 확인 목록, 통과 도장, 결과 표를 입혀 발표용 영상으로 만듭니다. 여러 편은 발표 흐름 화면과 제작 체크리스트로 묶습니다.
편집도 지침서가 정한 대로 계산합니다. 녹화 때 남긴 자막 시각 하나로 구간·확대·음성·도장 편집 전체를 계산하므로, 다시 녹화해도 편집 작업은 손대지 않습니다.
이 지침서로 구매·자산 시스템의 서비스 배정 기능을 유형별로 영상으로 만들었고 16개 확인 항목을 모두 통과했습니다. 그런데 더 중요한 일은 다른 영상에서 있었습니다. 녹화하던 중에, 다른 자동 점검이 다 통과한 상태에서 결함 3건이 드러나 고쳤습니다.
이것이 확인이 일 안에 들어간다는 뜻입니다. 영상을 만드는 일은 보여 주기 위한 일인데, 지침서가 저장된 값으로 판정하도록 정해 두었기 때문에 자동 점검이 못 본 결함을 영상 제작이 잡았습니다. 확인이 나중에 따로 하는 단계로 빠져 있으면 영상은 결함을 그대로 담은 채 만들어집니다.
셋째, 한 번 내린 결정이 다음 작업에 남습니다
세 번째는 인사이트 글쓰기 지침서입니다. 지금 읽고 계신 이 연재를 쓰는 바로 그 지침서입니다.
순서가 고정돼 있습니다. 쓰기 전에 재료, 그러니까 있었던 일·핵심·독자가 가져갈 것을 먼저 보고하고, 기존 글과 겹치는지 확인하고 제목은 사람이 고른 뒤에야 씁니다. 그다음 초안, 수정본, 이미지(스타일은 사람이 고릅니다), 등록과 예약(사람이 확인한 뒤) 순서입니다. 무엇을 쓸지와 어느 제목을 고를지는 지침서에 없습니다. 사람이 정합니다.
이 지침서가 다른 둘과 다른 점은, 결정이 쌓이는 것이 눈에 보인다는 것입니다. 제목 기준 여섯 가지는 2026년 9월 29일에 이노자일 사이트의 전체 글을 검토한 결과를 지침서에 적은 것입니다. 독자의 문제로 쓴다, 검색어를 앞에 둔다, 모호한 말을 쓰지 않는다 같은 기준입니다. 같은 날 발행 일정 규칙도 정했습니다. 매일 같은 시각에 빠짐없이 나오면 자동으로 찍어 내는 인상을 주므로, 간격은 하루나 이틀로, 시각은 오전 7시에서 9시 사이에서 분 단위로 조금씩 흔들고 가끔은 밤에 냅니다.
사실 확인 규칙도 있습니다. 확인하지 않은 일을 사실로 적은 글은 확인 전에 발행하지 않습니다. 상담 예약 운영기를 쓸 때, 상담 전날 안내 메일이 실제로 도착하는 것을 확인하기 전까지 발행을 막았습니다.
그리고 이번 연재에서 지침서가 한 번 바뀌었습니다. 1편과 2편은 서로 다른 두 AI 모델에 같은 요청서를 주고 각각 쓰게 해서 비교했습니다. 두 번 다 한쪽 원고가 구성과 통찰이 나아 뼈대로 쓰였습니다. 그런데 그 원고는 매번 요청서의 사실 목록 밖 내용을 조금씩 덧붙였습니다. 실제 인용처럼 쓴 문장, "~였을 것" 같은 추측, 실제로 정해지지 않은 예시 규칙 같은 것들입니다. 품질을 올린 것은 두 번째 원고가 아니라, 사실 목록과 한 줄씩 대조하는 단계였습니다. 그래서 2026년 10월 1일에 지침서를 "한 벌만 쓰고, 사실 대조로 고친다"로 바꿨습니다. 그 결정이 지침서에 남아 3편부터는 그 방식으로 썼고 이 5편도 같은 방식입니다.
결정이 사람 머릿속이나 대화 기록에만 있으면 다음 작업에서 같은 시행착오를 되풀이하기 쉽습니다. 지침서에 적히면 다음 작업은 그 결정 위에서 시작합니다.
지침서에 적을 것과 개발사에 물어볼 것
세 지침서는 하는 일이 전혀 다르지만 적힌 항목은 같습니다. 자기 회사의 반복 업무를 AI에 맡겨 보려면 아래 네 가지를 먼저 적어 보시기 바랍니다.
- 순서 — 일이 어떤 단계로 가는지. 어느 단계에서 사람이 멈춰 확인하는지(제목 고르기, 스타일 고르기, 등록 전 확인처럼).
- 금지 — 하지 말아야 할 것. "내보낸 결과를 손으로 고치지 않는다"처럼 한 줄로 분명하게.
- 확인 방법 — 결과가 맞는지 무엇으로 판정하는지. 화면이 그렇게 보였는지가 아니라 저장된 값이 맞는지처럼, 일 안에서 확인되게.
- 끝나는 조건 — 어디까지 되면 끝인지. 자동 검사를 통과한 것만 내보낸다, 확인 항목을 모두 통과한다 같은 조건.
그리고 적지 않을 것 하나입니다. 무엇을 할지, 어느 안을 고를지 같은 판단은 지침서에 넣지 않습니다. 판단을 고정하면 그 지침서는 한 프로젝트에서만 쓰이고 상황이 바뀌면 틀린 판단을 같은 방식으로 되풀이합니다.
AI로 일하는 개발사를 고르실 때는 이렇게 물어보시면 됩니다.
- 되풀이되는 작업을 지침서로 남겨 두고 있는지, 있다면 어떤 작업인지.
- 그 지침서에 사람이 멈춰 확인하는 자리가 어디인지.
- 결과가 맞는지 무엇으로 판정하는지. 보고 판단하는지, 저장된 값이나 자동 검사로 판정하는지.
- 프로젝트마다 다른 규칙은 어디에 적는지. 지침서를 고치는지, 설정으로 분리하는지.
- 지침서가 마지막으로 바뀐 것이 언제이고, 왜 바뀌었는지.
마지막 질문이 제일 많은 것을 알려 줍니다. 바뀐 이유를 말할 수 있는 개발사는 지침서를 실제로 쓰고 있다는 뜻입니다.