# AI 직원 복귀 시 결과물만 수정하여 일을 마무리하고 있었다. 우선적으로 지시서의 오류였다.

> https://bookfactory.kr/board/ai-tech/23204
> 게시판: AI·머신러닝
> 작성자: admin
> 작성일: 2026-10-22T08:09:18.885Z

---

## AI 직원 복귀 시 결과물만 수정하여 일을 마무리하고 있었습니다. 주로 수정된 것은 지시서의 오류였습니다.

또 같은 곳에서 멈춰서 있는 느낌일지도 모른다는 생각이 들었습니다. 반송 메일을 작성하면서 그렇게 느낀 적은 없는가.

이는 그 기록입니다. 핵심 지시체 1개와 역할별 실무 에이전트를 Claude Code로 조직하여 혼자서 운영하고 있습니다. 주기적인 처리는 169건이며, 시작한 지 약 7개월이 됩니다.

먼저 말씀드리지만, 이 글을 읽더라도 반품은 사라지지 않습니다. 제 현장에서도 이번 주에도 반품이 나오고 있습니다. 왕복을 0으로 만드는 이야기가 아니라 반품의 “이유”가 어디로 향하는지를 바꾼 이야기입니다.

왜 글을 쓸까요. 수정 사항을 지시서로 되돌리는 절차를 담은 글을 본 적이 없습니다. 위임하는 방법을 설명한 글은 많이 있지만, 리뷰의 관점을 나열한 글은 있습니다. 하지만 수정 사항이 누적된 후, 그 이유를 어디로 가져갈지를 설명하는 글은 없습니다. 그래서 제가 직접 써야 합니다.

저는 개발자 전문가는 아닙니다. 회사원입니다. 평일 저녁과 주말에 제 AI 직원들을 돌보고 있습니다. 지시 명령은 “@역할명 업무 내용” 형태로 1줄로 던집니다. 독립적인 업무의 경우 여러 대에 동시에 던집니다. 올라온 내용은 지시 명령이 모든 건을 검토하고 합격 또는 되돌리기를 반환합니다. 되돌리기는 이유와 함께 제공되며, 수정될 때까지 왕복합니다. 이 왕복이 이번의 주된 내용입니다.

매주 특정 장소가 고장 나곤 했습니다. 그때마다 수리하고, 얻은 교훈을 1건 1파일로 기록해 왔습니다. 자랑스러운 이야기는 거의 없습니다. 울리지 않았던 경보와 제가 스스로 중단시킨 명령 기록이 대부분입니다. 이번에도 그 중 하나입니다.

이 글에서 가져가시는 내용은 다음 세 가지입니다.

- 반품 사유를 “지시 사항 미준수/지시 사항의 모호성/확인 사항 보고만” 세 가지로 분류하는 표
- 분할 이유를 결과물 대신 지시서에 반영하는 절차
- 반송 횟수를 AI 사원의 능력이라기보다는 지시의 품질 지표로 해석하는 관점

주변을 둘러보면, AI에 작업을 맡기는 사람들이 늘고 있습니다. 체감상으로는 맡기는 데까지는 모두가 바로바로 알아채죠. 꼬이는 건 그 이후입니다. 올라온 결과물을 보고, 다른 부분을 지적하고 수정하는 거죠. 이 주고받는 과정이, 생각보다 작업 자체보다 시간을 더 많이 먹습니다. 맡겼는데, 오히려 제가 가장 바쁘게 움직이는 경우도 많았습니다. 저도 그랬습니다.

제 리뷰 기준은 4단계로 문서화되어 있습니다. “정상 작동”이 아니면 불합격입니다. 기준이 있기 때문에, 반품은 감점될 수밖에 없을 거라고 생각했습니다. 실제로 기준을 작성한 직후에는 실마리처럼 느껴졌습니다. 반품 시 제출되는 문면이 구체화되고, 처리 속도도 빨라졌습니다. 문제는 그 이후부터입니다.

반송 문서를 살펴보면, 같은 이유가 계속해서 나타납니다. “출력 대상 지정이 없는”, “확인했다고 되어 있지만, 확인 결과가 어디에도 없는”, “중간에 멈췄지만, 멈춘 사실을 보고하지 않은” 등의 내용이 반복적으로 발견됩니다. 손이 익숙해지는 것이 문제인 것입니다. 익숙해지는 것이 오히려 이상한 것입니다.

솔직히 말씀드리면, 저는 매번 결과물만 바로잡고 다시 제출했습니다. 수정하고, 고쳐서 합격을 받도록 만들고 다음 일을 진행했습니다. 또 같은 이유로 다시 돌려보냈습니다. 매번 결과물은 눈앞에서 좋아지는데, 다음 주에는 처음 상태로 돌아오더라고요. 제대로 고친 건 단 한 건뿐이었고, 지시서는 한 글자도 바뀌지 않았습니다.

![画像](https://assets.st-note.com/img/1792641399-YKkVPI3WMtiupD5QGsecEfCx.jpg?width=1200)

결정적인 것은 어떤 “검증 완료”된 기록 한 가지였습니다. 악보 데이터에 “원곡과 비교 완료”라고 기록되어 있었습니다. 그것을 믿고 다음 단계로 진행하려고 했습니다. 혹시 모를 상황에 대비해 직접 비교해 보았더니, 일치율은 14~19%였습니다. 비교한 흔적은 어디에도 없었고, 최초 로그는 존재하지 않았습니다. “비교 완료”라는 문자열만 생성된 것입니다.

그때 저는 우선 AI 직원에게 의심을 품었습니다. 거짓말을 했다는 식으로요. 그런데 지시서를 다시 읽어보니 ‘교차 확인’해야 한다는 것 외에는 아무것도 쓰여 있지 않았습니다. 교차 확인 결과를 어떤 파일에 남길 것인지, 무엇을 기준으로 교차 확인이 완료된 것으로 간주할 것인지 한 줄도 없었습니다. “교차 확인이 완료되었다”라고 쓰면 지시는 충족됩니다. AI 직원은 지시서대로 움직였습니다. 문제는 지시서의 쪽에 있었습니다.

여기서 얻어낸 결과물은 아닙니다. 원본 로그가 없는 “검증 완료”라는 표현을 믿지 않습니다. 검증은 결과 파일을 남기는 형태로 해야 합니다. 이 두 가지를 지시서에 추가했습니다. 그 결과 같은 이유로 롤백이 그 단계에서는 나오지 않았습니다. 1건을 수정하는 대신 지시서를 수정하면 멈추게 됩니다. 당연한 일이지만, 7개월이나 지나서야 깨달았습니다.

그러면서, 미납된 환불 사유를 모두 정리하고 분류해 보기로 했습니다. 확인한 결과, AI 직원들의 결점이라기보다는 제 지시서의 누락이었던 것입니다. 지시에 명시되지 않았거나, 명시되어 있지만 모호하고, 확인을 ‘했습니다’라는 보고로만 처리하고 있었다는 점이 대부분 설명이 되었습니다.

결론을 한 줄로 요약하면, 수정 요청의 대부분은 제 지시 사항 작성 방식에서 비롯되었습니다. 따라서 이유는 결과물 대신 지시 사항으로 돌아가서 해결하기로 결정했습니다.

반송 횟수는 AI社員의 평가 지표가 아니었다. 나의 지시의 품질을 측정하는 지표였다. 그렇게 재해석하면 반송 문서를 수정하는 방식이 달라졌다. 다음으로 쓸 내용은 그 재해석에 이르기까지 무엇을 버리고 무엇을 남겨두었는가이다.

## 제2장 “반환”이라는 용어를 제 현장의 언어로 바꾸다

분류에 대해 이야기하기 전에 용어를 먼저 맞춰드리겠습니다. 이 연재에서 사용되는 모든 용어는 제가 임의로 의미를 좁혀 놓은 것입니다. 독자분들의 현장에서 사용하는 용어와 다르면 분류표가 그대로 사용될 수 없습니다.

먼저 “위임”입니다. 제 운영 방식에서는 위임은 “@역할명 업무 내용”이라는 한 줄로 시작합니다. 지시관이 실무 에이전트에게 전달하는 한 줄입니다. 독립적인 업무의 경우, 여러 에이전트에 동시에 배포하고 나란히 실행하며 기다립니다. 이는 사람에게 일을 부탁하는 것과 같습니다.

다음으로 “리뷰”를 진행한다. 올라온 물품은 지휘관이 전량 검토한다. 예외를 둘 줄 모른다. 검토 결과는 합격 또는 반송의 두 가지 선택지 중 하나로 결정된다. 반송 시에는 이유를 덧붙인다. 수정될 때까지 왕복한다. 이 왕복 횟수가 본고의 주제이다.

지시서는 에이전트가 일을 시작하기 전에 읽는 문서입니다. 역할, 절차, 합격 조건, 해서는 안 되는 일이 기록되어 있습니다. 인간 회사에서는 업무 매뉴얼과 유사하지만, 한 가지 차이점이 있습니다. AI 직원은 지시서에 적힌 내용 외에는 알 수 없으며, 기록되지 않은 내용은 그대로 무지함을 가장らしく 채우는 것이 문제였습니다.

출신 기록(来歴)은 결과물에 대한 제작 과정 기록입니다. “원곡과 비교 완료”, “테스트 완료”와 같은 문구가 이에 해당합니다. 앞 절에서 언급한 사고는 이 출신 기록이 문자열로만 생성된 것이었습니다. 비교한 형태의 최초 로그는 존재하지 않았고, 실제 일치율은 14~19%였습니다. 출신 기록은 결과물이 아니므로, 결과물만으로는 출신 기록의 허위 사실을 확인할 수 없습니다.

마지막으로 “4단계”. 제 리뷰 기준은 4단계로 문서화되어 있습니다. 합격 조건은 “움직였다”는 것만이 아닙니다. “파괴 방법을 시도해보고 멈추지 않았다”는 의미입니다. 이 기준을 만들 때, AI 직원들을 의심하기 위한 도구라고 생각했습니다. 지금은 다른 의미로 읽고 있습니다. 4단계 중 어디에서 실패했는지는 제 지시서의 어떤 부분이 부족한지를 가리키는 지표였습니다.

![画像](https://assets.st-note.com/img/1792641407-TzlYwtQIA0cyLxR2sqn68SKu.jpg?width=1200)

## 제3장: 2025년부터 2026년까지, 주변에서 일어난 변화들

이제부터는 감각에 대한 이야기입니다. 숫자는 제시하지 않겠습니다. 제 주변과 저의 직접적인 운영으로 인해 발생한 변화들을 순서대로 나열하겠습니다.

첫째는 지침서의 보관 장소입니다. 이전에는 지침을 현장에서 직접 작성하는 방식이었습니다. 대화의 시작 부분에 긴 서론을 쓰고, 끝이 나면 버리는 방식이었습니다. 이제는 지침서를 파일로 보관하고, 작업할 때마다 읽어주는 방식이 일반화되었습니다. 제 곳도 마찬가지입니다. 지침서가 ‘남아있는 것’이 된 순간부터, 수정 대상이 결과물에서 지침서로 옮겨가는 준비가 되어 있었습니다. 알아차리는 것이 늦었던 것뿐입니다.

두 번째 유형은 여러 대를 나란히 세워 달리게 하는 방식입니다. 한 사람이 보는 유형인데, 한 대로 모든 것을 의존하기보다는 역할을 분담하여 동시에 투하합니다. 위로 올라온 물건은 지휘관이 한 곳에서 받아칩니다. 이 유형의 경우, 쇄도가 한 곳으로 모입니다. 모이게 되면, 같은 이유가 반복되는 것이 눈에 들어옵니다. 한 대로 한 명씩 상대할 때는 같은 이유라도 별개의 사고처럼 보였었는데.

세 번째는 “성공했다”라는 것을 믿지 않는 흐름입니다. 이전 장의 사고 이후, 저는 검증을 “결과 파일을 남기는 형태”로 변경했습니다. 주변을 둘러보면, 자기 진술 대신 증거가 되는 출력을 요구하는 운영이 늘어나고 있습니다. 테스트의 경우 실행 로그, 일치 검토의 경우 일치율 표를 사용합니다. “완료”라는 문자열은 어떤 증거에도 도움이 되지 않습니다. 이것은 2026년이 시작된 이후, 제가 가장 강하게 강조하는 문장입니다.

네 번째는 반품 사유를 기록에 남기는 것입니다. 이전에는 반품 내용을 작성하여 바로 수정하면 잊어버리는 경우가 있었습니다. 왕복은 그 자리에서 소모되는 것이었습니다. 현재는 이유를 한 줄로 남깁니다. 1건 1파일의 교훈과 같은 위치입니다. 남기기를 시작한 후에 알게 된 것은, 반품 사유의 문구가 거의 같은 형식으로 수렴한다는 점입니다. 이것이 다음 장의 분류표로 이어집니다.

다섯 번째는 왕복 횟수에서 나타나는 시각 변화입니다. 횟수가 많을수록, 이전에는 “이 에이전트는 실력이 부족하다”라고 읽었지만, 지금은 “이 지시서는 내용이 부족하다”라고 읽습니다. 같은 숫자로, 화살표의 방향만 뒤집힌 것입니다. 이러한 변화가 본 논문의 핵심 지점이었던 것입니다.

## 제4장 손에 든 숫자

숫자는 1차 자료에만 제시하며, 부족한 숫자는 “어디에서 알아차렸는지”를 기록합니다.

- 항목: 중심축 / 제 운영에서의 값: 1체
- 항목: 정기 처리 / 제 운영에서의 값: 169본
- 항목: 시작한 이후 / 제 운영에서의 값: 약 7개월
- 항목: 리뷰 기준 / 제 운영에서의 값: 4단계
- 항목: “일치 확인 완료”의 실제 일치율 / 제 운영에서의 값: 14~19%
- 항목: 허위 출신 경력에 의문을 느낀 날 / 제 운영에서의 값: 2026년 9월 9일

반환 건수와 그 이유에 따른 건수는 이 표에 포함되어 있지 않습니다. 최근에 자료가 남아있고 집계에 견딜 만한 수가 아니기 때문입니다. 대신 순서대로 설명할 수 있습니다. 처음 발견한 것은 출처의 허위 사실이었습니다. 그 다음으로 신고만으로 처리되고 있다는 확인이 다른 곳에도 있다는 것을 알게 되었고, 마지막으로 지시 사항에 없는 부분을 보완해야 했던 경우가 가장 많다는 것을 알게 되었습니다. 발견 순서대로입니다.

## 제5장 분류 전에 버린 것들

솔직히 말씀드리면, 분류를 시작하기 전에 한 차례 큰 어려움을 겪었습니다. 처음 만들었던 표는 AI 직원들의 말로 만들어진 것이었습니다. “절차를 건너뛰었다”, “자주 보충했다”, “확인이 소홀했다”는 내용이었죠. 쭉 내려다보니 전부 다 상대방의 결점처럼 보였습니다. 그 순간, 정말 화가 솟아오르는 표였습니다. 저는 그 표를 밤새도록 놔두고, 다음 날 아침에 버렸습니다. 화가 나는 표는 바로잡아야 할 곳을 가리지는 않습니다. 그것만으로 버리는 이유가 충분했습니다.

이 부분부터는 ‘분류표를 실제 물건으로 보여드리겠습니다’를 비롯하여 실제로 사용했던 프롬프트의 전체 내용과, 도구를 선택할 당시의 판단 기준까지 담고 있습니다. 궁금하신 분은 계속해서 읽어보시길 바랍니다.

본 시리즈는 저자가 개인적인 시간 동안 구축하고 운영하고 있는 AI 에이전트 그룹의 운영 기록입니다. 기재된 수치(정기 처리의 본수·횟수·시간 등)는 모두 저자의 환경의 실측 로그에서 도출한 것으로, 다른 환경에서 동일한 결과가 나타날 것을 보장하지 않습니다. 근무지의 업무 및 시스템과는 무관합니다. 특정 제품 또는 서비스의 추천이나 수익을 보장하는 내용은 포함되어 있지 않습니다.

**출처:** [note 원문](https://note.com/natty_holly2922/n/n47f4064ba5a9)

*번역: Gemma 3(.44) 초벌 + 교정 32청크*

[원문 보기](https://note.com/natty_holly2922/n/n47f4064ba5a9) | 출처: note.com