왜 나는 AI에게 일을 맡길 수 없었을까 — 에이전트보다 먼저 필요했던 업무의 틀

📝 한줄 요약

AI에게 일을 맡기고 싶었지만, 나는 늘 컴퓨터 앞에 붙어서 하나하나 확인하고 고쳐야 했다. 처음에는 내가 AI를 못 믿어서 그런 줄 알았다. 그런데 살펴보니 AI가 일을 시작할 입구도, 끝났다고 판단할 기준도, 다른 AI에게 넘길 방법도 없었다. 요구사항부터 검수와 보고까지 이어지는 작은 업무의 틀을 만들고 나서야 처음으로 한 사이클을 맡겨볼 수 있었다.

바쁘시면 이것만 읽어도 돼요:

• AI에게 일을 못 맡긴 이유는 모델 성능만이 아니라 업무의 입구와 출구가 없었기 때문이었다.
• 작은 작업은 한 장짜리 브리프, 큰 작업은 Spec Kit식 스펙으로 나누었다.
• 목표·권한·금지선·완료 조건·멈춤 조건을 먼저 주고 실행하게 했다.
• 기계 검사를 통과해도 내가 원한 결과와 다를 수 있었다. 그래서 별도의 검수와 사용자 판정을 붙였다.
• 완전한 위임에는 아직 도달하지 못했지만, 매 단계 옆에 붙지 않고 한 사이클을 돌리는 틀은 처음 생겼다.

🎯 이런 분들께 도움돼요

• AI에게 “알아서 해줘”라고 하면 결과가 자꾸 빗나가는 사람
• AI가 작업하는 동안 계속 옆에서 확인하느라 자리를 뜨지 못하는 사람
• Claude, Codex처럼 도구를 바꿀 때마다 설명과 지침을 다시 써야 하는 사람
• AI 에이전트나 조직도를 만들기 전에 무엇부터 정해야 할지 막막한 비개발자

😫 문제 상황 — 나는 왜 계속 마이크로매니징했을까

다른 사람들은 AI에게 일을 맡겨두고 다른 일을 한다고 했다. 나는 그러지 못했다. AI가 무언가를 만들면 바로 확인하고, “이건 아닌데”라고 고치고, 다시 결과를 보고 또 수정했다. 함께 만드는 작업에는 이 방식이 필요할 때도 있지만, 모든 일을 이렇게 하니 컴퓨터 앞을 떠날 수가 없었다.

처음에는 내가 AI를 잘 못 믿어서 그런 줄 알았다. 그래서 아예 전용 에이전트를 만들면 해결될까 생각했다.

지금 내가 너한테 일을 위임하고 싶은데 위임이 잘 안 되거든.
계속 내가 너를 마이크로매니징해야 되는 부분이 있어.

그런데 작업환경을 열어보니 에이전트를 만들기 전에 해결할 문제가 더 많았다.

• 모든 프로젝트에 적용되는 전역 지침은 계속 길어지고 있었다.
• 특정 프로젝트에서만 필요한 내용도 전역 지침에 섞여 있었다.
• 프로젝트별 지침은 오래됐거나 실제 작업에서 잘 읽히지 않았다.
• Claude용 지침에 몰아 넣은 내용은 Codex가 알지 못했다.
• 계획 문서는 계획이라기보다 오래된 할 일 목록처럼 변해 있었다.
• 어떤 문서가 현재 상태이고 어떤 문서가 과거 기록인지 구분하기 어려웠다.

AI가 일을 못 하는 것이 아니라, 일을 시작하기 전에 읽어야 할 것부터 서로 모순되고 있었다.

✅ 확인한 방법: 전역 지침, 프로젝트 지침, 계획 문서, 인계 문서를 실제로 열어 역할과 중복을 대조했다. “정리가 안 된 것 같다”는 느낌을 파일 단위로 확인했다.

🛠️ 사용한 도구와 재료

• Claude Code: 처음 문제를 진단하고 회의·기획 구조를 만드는 데 사용
• Codex: 다른 모델이 문서를 이어받아 실제 작업할 수 있는지 확인
• Paseo-Codex와 별도 Claude 작업자: 맥락을 제한한 인계와 냉독 검수에 사용
• Spec Kit 방식: 복잡한 작업의 요구사항·계획·실행·검증 단계를 참고
• Markdown 문서와 Git: 브리프, 작업 목록, 인계, 결과와 증거를 남기는 바닥

새로운 대형 에이전트 플랫폼을 설치한 것은 아니다. 먼저 지금 가진 도구들 사이에서 공통으로 쓸 수 있는 파일 기반 업무 흐름을 만들었다.

🔧 작업 과정

1. 에이전트를 만들기 전에 방부터 정리했다

처음에는 작은 위임 실험부터 해보자는 제안도 나왔다. 하지만 내 눈에는 이미 방이 너무 어질러져 있었다. 새 자동화를 하나 더 넣으면 잠깐 쓰다가 또 버릴 것 같았다.

지금도 글로벌 지침은 계속 자라고 있고 메모리도 계속 늘어나고 있어.
계획 문서도 점점 쓰레기통이 되고 있어.
지금 엄청나게 지저분하고 물건이 가득 쌓여 있는 방 같은 상태인 것 같아.

그래서 무엇을 더 만들기 전에 정보가 있어야 할 자리를 나눴다.

• 모든 작업에 공통인 원칙
• 프로젝트에서만 필요한 지침
• 현재 할 일과 완료 조건
• 왜 그렇게 결정했는지 남기는 작업 기록
• 다른 AI가 이어받는 입구

정리의 목적은 예쁜 문서 체계를 만드는 것이 아니었다. 다음 AI가 “무엇을 읽고, 무엇을 하고, 어디서 멈춰야 하는지” 알 수 있게 만드는 것이었다.

✅ 확인한 방법: 같은 사실이 여러 문서에 중복되지 않는지 보고, 현재 상태·작업 기록·규칙·인계 문서의 역할을 각각 한 곳으로 좁혔다.

2. 채팅으로 흘러가던 요구사항을 업무의 입력으로 바꿨다

AI와 오래 대화하다 보면 중요한 결정도 채팅 위로 밀려 올라간다. 다음 세션에서는 그 이야기를 다시 설명해야 했다. 그래서 작업에 들어가기 전에 대화를 문서로 고정해달라고 요청했다.

지금까지 작업 대화한 내용을 회의록으로 남기고,
확정된 내용으로 기획서를 만들고,
기획서에서 상세계획과 실행 목록을 뽑아 진행해.
다른 AI가 이어받을 수 있을 정도로 문서 작업을 해놔야 돼.

이때부터 요구사항이 다음 순서로 흐르기 시작했다.

사용자 요청
→ 회의와 질문
→ 기획서와 성공 판정
→ 실행 가능한 작업 목록
→ 작업자에게 전달
→ 결과와 증거 회수

예전에도 회의록, 계획, 보고서는 있었다. 하지만 실제로 누군가에게 일을 넘기는 작업 단계가 비어 있었다. 이번에는 그 빈칸을 채우는 것을 목표로 삼았다.

✅ 확인한 방법: 위임환경의 과거 기록을 대조했다. 2026년 5월에 정한 ‘회의록 → 계획 → 작업 → 보고서’ 네 단계 중 작업, 즉 실제 위임 단계만 석 달 동안 비어 있었다.

3. 작은 작업은 한 장 브리프로 시작했다

처음부터 복잡한 스펙 문서를 매번 쓰면 문서 관리가 다시 일이 된다. 반대로 “이것 좀 해줘”만 전달하면 AI는 빠진 맥락을 추측한다.

그래서 기본 입력을 한 장짜리 브리프로 정했다.

첫 실무는 기존 학습 자료 일부를 아루나 사이트 안의 위키로 옮기는 일이었다. 새 기능을 만드는 것이 아니라 정해진 구조 안에 콘텐츠를 옮기는 작업이었기 때문에 한 장 브리프로 시작했다.

Spec Kit 방식도 검토했다. 요구사항을 명확히 하고 계획·작업·검증으로 연결하는 원리는 가져왔지만, 모든 일에 전부 적용하지는 않았다.

• 원본과 위치와 완료 조건이 정해진 작은 일: 한 장 브리프
• 새 기능, 사용자 흐름 변경, 여러 프로젝트 수정, 불명확한 검수: Spec Kit식 문서 단계

중요한 것은 유명한 방법론을 통째로 설치하는 일이 아니라, 작업 크기에 맞는 입구를 고르는 일이었다.

✅ 확인한 방법: 첫 브리프에 목표·원본·권한·금지선·완료 조건·멈춤 조건이 모두 들어갔는지 항목별로 대조했다. 새 코드나 새 화면이 필요해지면 작업을 멈추고 큰 스펙으로 올리도록 경계를 넣었다.

4. 처음으로 한 사이클을 맡겨봤다

브리프를 받은 AI는 관련 문서를 읽고, 계획을 세우고, 작업하고, 검증 결과를 정리했다. 예전처럼 매 단계에서 바로 피드백하지 않고 먼저 끝까지 가보게 했다.

이것만 보면 위임에 성공한 것처럼 보였다. 실제로 파일 수, 문서 형식, 원본과 복사본의 일치 여부, 페이지 주소 같은 기계 검사는 통과했다.

그런데 내가 결과를 보니 기대한 수준에는 한참 못 미쳤다. 결국 다시 대화하며 고쳤다.

여기서 중요한 걸 배웠다.

완료 조건을 통과한 결과와 내가 원한 좋은 결과는 같지 않을 수 있다.

브리프가 틀린 것은 아니었다. 브리프에 내가 품질이라고 생각한 것이 충분히 들어 있지 않았다. AI가 멋대로 실패한 부분도 있었지만, 내가 머릿속으로만 알고 있던 기준도 많았다.

첫 실험은 완전한 위임에는 실패했다. 그래도 이전과 다른 점이 하나 있었다. 처음으로 AI가 요구사항을 받아 계획·실행·검수·보고까지 한 사이클을 돌렸고, 나는 마지막 결과를 보고 어느 기준이 빠졌는지를 찾을 수 있었다.

✅ 확인한 방법: 정본과 작업본의 Markdown 파일 28개 목록과 해시가 일치했고, 문서 정보칸 오류가 없었으며 대표 페이지 주소가 정상 응답하는지 확인했다. 그 뒤 사용자가 직접 결과의 내용과 방향을 판정했다. 기계 검수와 사람의 품질 판정을 분리했다.

5. “완료했습니다” 뒤에 별도 검수 단계를 붙였다

AI가 자기 작업을 자기가 검사하면 같은 오해를 그대로 들고 갈 수 있다. 그래서 작업 흐름에 Verify, 즉 검수 단계를 따로 넣었다.

요청 받기
→ 작업 성격 분류
→ 브리프 또는 스펙
→ 계획
→ 실행
→ 검수
→ 통과·수정·사용자 확인·중단 판정
→ 결과 보고
→ 기록과 인계

검수도 모든 작업에 무겁게 붙이지 않았다.

• 기본 검수: 요구사항, 변경 내용, 테스트, 빠진 범위 확인
• 심화 검수: 복잡하거나 위험한 변경, 반복 실패, 하네스 변경 확인
• 냉독: 그래도 애매하거나 실패 비용이 큰 경우, 맥락 없는 다른 AI가 다시 읽기

냉독 AI의 말도 정답으로 취급하지 않았다. 지적을 원본에서 다시 확인하고, 재현되는 것만 고쳤다.

실제 냉독에서는 승인한 문서 8개만 별도 작업자에게 주고 한 번에 감사하게 했다. 작업자는 후속 질문 없이 결과 파일 하나를 반환했고, 오래된 체크 표시와 날짜, 복사돼 남은 검증 내용 등 5건을 지적했다. 원본에서 다시 확인해 맞는 것은 고치고, 불필요한 제안은 받아들이지 않았다.

✅ 확인한 방법: 전달 전후 원본 8개의 해시가 같은지 확인해 작업자가 원본을 건드리지 않았음을 증명했다. 냉독 결과 5건은 상위 AI가 라이브 원본에서 하나씩 재판정했다.

6. 조직도보다 먼저 업무 흐름을 그렸다

웨비나에서 사람, AI, 공동 작업, 사람 검수를 나눈 업무 흐름도를 봤다. 나도 AI 회사 조직도를 만들면 위임할 수 있을 것 같았다.

하지만 역할 이름만 정한다고 일이 움직이지는 않았다. 먼저 필요한 것은 요청이 들어온 뒤 어디까지 자동으로 하고, 어디에서 사람에게 물으며, 무엇을 증거로 돌려줄지 정하는 일이었다.

시작 신호
→ 요청을 한 문장 목표로 정리
→ 자동·반자동·사람 작업·판단으로 분류
→ 브리프 또는 스펙 작성
→ 계획
→ 실행
→ 검수
→ 다음 상태 결정
→ 사용자 보고
→ 기록

이 흐름을 그림으로 보고서야 내 시스템이 처음으로 눈에 들어왔다. 그동안은 지침, 계획, 메모리, 작업 기록이 보이지 않는 곳에 흩어져 있어 늘 막연했다. 다이어그램에서는 각각이 왜 필요하고 다음 단계로 무엇을 넘기는지 보였다.

그래서 지금은 CEO, CTO, CMO 같은 큰 에이전트 조직을 만들지 않았다. 사용자, 개인 비서, 작업자, 검수자라는 작은 역할만 두었다. 반복 업무가 실제로 쌓일 때 역할을 더 나누기로 했다.

✅ 확인한 방법: 새 세션이 HANDOFF.md와 TASKS.md라는 두 입구만 받고도 읽어야 할 원본, 실행 가능 여부, 차단 조건을 설명하는지 시험했다. 별도 작업자가 결과 패킷을 반환하고 상위 세션이 검수할 수 있는 흐름도 실제로 한 번 돌렸다.

✅ 결과 — 완전한 위임은 아니지만, 처음으로 길이 생겼다

아직 컴퓨터를 켜두고 AI가 며칠씩 완전히 자율적으로 일하는 단계는 아니다. 첫 결과도 기대보다 부족했고 여러 번 다시 고쳤다.

그래도 기분 탓만은 아니었다. 요구사항이 입력으로 들어가고, 계획과 완료 조건을 거쳐, 실행·검수·보고로 돌아오는 길이 실제 파일과 테스트로 생겼다. 사용자가 모든 중간 단계를 붙잡지 않아도 되는 첫 틀이었다.

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. 에이전트의 성격보다 업무의 입구와 출구를 먼저 만든다. 누구에게 맡길지보다 무엇을 받고 무엇을 돌려줄지가 먼저다.
2. 완료 조건과 품질 기준을 구분한다. 파일이 생기고 테스트가 통과한 것과 내가 원한 결과는 다를 수 있다.
3. 작은 일과 큰 일의 문서 무게를 다르게 한다. 작은 일은 한 장 브리프, 복잡한 일만 스펙 단계로 올린다.
4. AI의 자기검수 뒤에 다른 시선을 둔다. 단, 냉독 결과도 원본에서 재현된 것만 고친다.
5. 첫 위임의 부족한 결과를 실패로 버리지 않는다. 무엇이 머릿속 기준으로만 남아 있었는지 찾는 재료로 쓴다.

이렇게 하면 안 돼요

1. “알아서 해줘” 뒤에 숨은 기준까지 AI가 알아낼 것이라 기대하기. 목표·권한·금지선·완료 조건이 없으면 AI는 빈칸을 추측한다.
2. 처음부터 에이전트 조직을 크게 만들기. 실제 반복 업무가 없으면 역할 문서만 늘어난다.
3. 모든 작업에 무거운 스펙과 냉독을 붙이기. 관리 비용이 다시 위임의 이익을 잡아먹는다.
4. 테스트 통과를 사용자 만족과 같은 것으로 보기. 기계 검사와 사람의 품질 판단은 서로 다른 단계다.

🌍 다른 업무에 적용한다면

이 구조는 개발 작업에만 쓰는 것이 아니다. 조사, 콘텐츠 작성, 강의 준비, 자료 정리도 같은 질문으로 시작할 수 있다.

• 무엇을 끝내야 하나?
• 어떤 자료를 읽어야 하나?
• 어디까지 바꿔도 되나?
• 절대 건드리면 안 되는 것은 무엇인가?
• 무엇이 확인되면 끝났다고 볼 수 있나?
• 예상과 다르면 어디서 멈춰야 하나?
• 결과와 증거를 어떤 형식으로 돌려받을까?

이 일곱 가지가 있으면 AI 도구가 달라져도 같은 업무를 다시 건넬 수 있다.

🚀 앞으로의 계획

다음 목표는 에이전트 파일을 더 많이 만드는 것이 아니다. 실제 업무 하나를 처음부터 끝까지 맡겨보고, 다음 세 단계가 얼마나 작동하는지 확인하는 것이다.

1. 처음 하는 일은 사용자와 AI가 함께 기준을 발견한다.
2. 두 번째에는 AI가 주도하고 사용자가 결과를 검수한다.
3. 반복되면 AI가 실행하고 사용자는 예외와 중요한 결정만 본다.

그리고 이 바닥 위에 Claude, Codex, Hermes, 가상 컴퓨터 같은 실행 도구를 갈아 끼우는 구조를 시험하려 한다. 도구가 바뀔 때마다 내 프로젝트 지식과 일하는 방식을 다시 이사하지 않는 것이 다음 이야기다.

📋 재사용 가능한 프롬프트

작은 일을 맡길 때 쓰는 위임 브리프

아래 일을 내가 중간마다 확인하지 않아도 한 사이클로 진행할 수 있게 먼저 브리프로 정리해줘.

• 한 문장 목표
• 원하는 결과물과 저장 위치
• 반드시 읽어야 할 원본
• 수정 가능한 범위
• 건드리면 안 되는 범위
• 완료 조건
• 각 완료 조건의 확인 방법
• 예상과 다를 때 멈출 조건

빠진 정보가 결과를 크게 바꾸는 경우에만 질문하고, 충분하면 계획 → 실행 → 검수 → 결과 보고 순서로 진행해줘. 결과 보고에는 바꾼 것, 확인한 증거, 확인하지 못한 것, 내가 결정할 것만 포함해줘.

AI가 완료했다고 했을 때 쓰는 검수 요청

방금 작업의 완료 주장을 그대로 믿지 말고 검수해줘.

1. 처음 요구사항과 실제 변경을 대조하고
2. 완료 조건마다 증거를 붙이고
3. 성공한 경우뿐 아니라 실패 경계도 확인하고
4. 확인하지 못한 것은 미검증으로 남기고
5. 다른 AI의 지적은 원본에서 재현된 것만 채택해줘.

마지막에는 입증됨, 관측됨, 미검증을 구분해서 보고해줘.