[Claude 활용 24회 — AI에게 일을 위임하는 법] 24/24화: AI 위임 6개월 결산 — 남은 자산과 실패 3가지

2026년 08월 27일 15 Min Read

이 글을 쓰려고 6개월치 메모를 펼쳤다. AI 위임 결산이라면 자산 목록이 길고, 절약한 시간이 많고, 수익이 나기 시작했다는 이야기가 나와야 할 것 같았다. 1화에서 “2026년 7월, 판이 바뀌었다”고 선언했으니, 24화에서는 “그래서 이만큼 바뀌었다”는 깔끔한 결론을 기대했다.

현실은 그렇게 깔끔하지 않았다. 자산 목록을 엑셀에 정리하는데, 만들어놓고 한 달 만에 안 쓰게 된 것이 지금도 돌아가는 것만큼 많았다. 시간 절약을 계산했더니 절약분의 40%는 배우는 데 이미 태운 시간이었다. “통하지 않았던 것” 목록을 세 가지로 줄이는 게 어려울 정도로 삽질이 많았다.

그래서 이 마지막 회차는 자랑이 아니라 정산이다. 24회 동안 진짜 남은 것, 진짜 든 비용, 진짜 안 된 것. 이것만 쓴다. 23화에서 포트폴리오 설계의 뼈대를 세웠다면, 이 글은 그 뼈대에 살을 붙이기 전에 내가 먼저 겪은 현실 데이터다.

24회의 자산 목록 — 만든 것과 살아남은 것

1화부터 23화까지 매 회차 말미의 ‘수익화 지점’에서 “이걸 만들 수 있다”고 제안한 것들이 있다. 나는 그중 상당수를 직접 만들었다. 문제는 만든 것의 전부가 지금 돌아가고 있느냐는 것이다. 아래 표는 6개월간 만들어진 자산의 목록과 현재 상태를 정직하게 적은 것이다.

자산 유형별 현황

자산 유형	만든 것	출처 회차	현재 상태	주간 유지 시간
CLAUDE.md	글로벌 1개 + 프로젝트 3개 + 디렉터리 2개	5화	✅ 전체 활성	0.5시간
Skills	7개 작성 → 4개 활성	9화	⚠️ 4/7 활성	1시간
MCP 서버	자체 제작 2개 + 커뮤니티 5개 연결	10화	⚠️ 3/7 상시 연결	0.5시간
플러그인	팀용 1개 + 공개 배포 1개	12화	✅ 전체 활성	0.5시간
예약 작업	일간 1개 + 주간 2개 + 월간 1개	15화	⚠️ 3/4 활성	1시간
대시보드	개인 지표 1개 + 프로젝트 현황 1개	16화	✅ 전체 활성	0.5시간
Agent SDK 서비스	마이크로 SaaS 1개 (내부 + 외부 제공)	21화	✅ 활성	2시간
콘텐츠 파이프라인	블로그 자동 초안 + 뉴스레터 요약	23화	✅ 활성	1시간
합계			21개 중 15개 활성 (71%)	주당 7시간

숫자를 보면 두 가지가 눈에 띈다. 첫째, 생존율 71%. 만든 것의 약 30%는 유지비를 감당 못 하거나 필요가 사라져서 꺼졌다. 후반부에서 살펴볼 ‘통하지 않았던 것’이 바로 이 30%에 들어 있다. 둘째, 주당 유지 시간 7시간. 이 시스템을 그냥 돌리기만 해도 매주 거의 하루 치 업무를 먹는다. 아무것도 만들지 않고 유지만 하는 데 드는 비용이다.

이 사실을 처음 깨달았을 때 조금 당혹스러웠다. 23화에서 수익 포트폴리오를 설계하면서 “동시에 4개 유형을 돌린다”고 했는데, 그 4개를 돌리는 유지비만으로 이미 주당 7시간이 사라진다. 자동화는 공짜가 아니다. 자동화의 자동화가 필요한 순간이 반드시 온다.

CLAUDE.md — 가장 확실하게 살아남은 자산

5화에서 “저장소의 헌법”이라고 불렀던 CLAUDE.md가 6개월이 지난 지금 가장 높은 ROI를 보인 자산이다. 이유는 단순하다. 유지 비용이 거의 0에 가깝기 때문이다.

글로벌 CLAUDE.md는 6개월 동안 11번 수정됐다. 대부분 한두 줄 추가하거나 빠진 컨벤션을 채우는 정도였다. 프로젝트별 CLAUDE.md 세 개는 평균 7번씩 수정됐다. 프로젝트 자체가 발전하면서 자연스럽게 업데이트되는 것이라 별도 유지 작업이라는 느낌도 없었다.

반면 이 문서가 만들어낸 가치는 측정하기 어려울 만큼 크다. 5화에서 예고한 그대로, CLAUDE.md는 신입 온보딩 문서가 됐다. 새 프로젝트에 합류하는 사람(인간이든 AI든)이 처음 읽는 문서가 CLAUDE.md이고, 거기에 빌드 명령·코딩 컨벤션·금지사항·도메인 용어·디렉터리 지도가 있으니 별도의 온보딩 세션 없이 2시간 내에 첫 커밋이 가능해졌다.

한 가지 의외의 발견. CLAUDE.md의 진짜 가치는 AI를 위한 지시서가 아니라 “우리 팀이 암묵적으로 알고 있던 것을 명시적으로 기록한 문서”라는 점이었다. 20년 동안 코드를 짜면서 한 번도 적지 않았던 것들 — “이 모듈은 왜 이렇게 생겼는지”, “이 라이브러리를 선택한 이유”, “이 패턴을 쓰면 안 되는 이유” — 을 AI한테 설명하려고 쓰다 보니 팀 전체의 암묵지가 문서화됐다. 이건 AI 도구를 쓰든 안 쓰든 남는 자산이다.

Skills — 살아남은 것과 죽은 것의 차이

9화에서 만든 7개의 Skill 중 지금도 쓰이는 건 4개다. 살아남은 것과 죽은 것의 차이를 분석하니 패턴이 하나 보였다.

살아남은 Skill: 입력 형식이 안정적이고, 출력 형식도 고정. 회의록 → 액션아이템 추출, 코드 리뷰 체크리스트 생성, 데이터 변환 파이프라인, 표준 보고서 초안.
죽은 Skill: 매주 요구사항이 바뀌는 보고서 양식 자동화, 비정형 이메일 분류, 불규칙 데이터 정제.

패턴은 명확하다. 프로세스가 안정적인 작업은 자동화가 살아남고, 프로세스 자체가 유동적인 작업은 자동화가 죽는다. 당연한 말 같지만, 만들 때는 구분이 잘 안 된다. “이번 주만 형식이 좀 다른 거야”라고 생각하며 Skill을 수정하다 보면 세 번째 수정에서 포기하게 된다. 9화에서 “description이 모호하면 영원히 호출되지 않는 유령 Skill”이라고 경고했는데, 실은 description보다 더 치명적인 유령 조건이 있었다 — input이 매번 달라지는 Skill이다.

MCP 서버 — 3개가 최적이었다

10화에서 MCP 서버를 붙이는 법을 배운 뒤, 한때 7개를 동시에 연결한 적이 있다. GitHub, 로컬 파일시스템, 사내 위키, 데이터베이스 조회, 브라우저 자동화, 캘린더, 메일. “다 연결하면 AI가 모든 맥락을 볼 수 있으니까 더 똑똑해지겠지”라는 생각이었다.

결과는 정반대였다. 7화에서 다뤘던 컨텍스트 오염이 정확히 발생했다. 코드 리팩터링을 요청하는데 캘린더 일정이 컨텍스트에 올라오고, 버그 분석을 시키는데 메일함의 마케팅 뉴스레터가 참조됐다. AI의 응답 품질이 눈에 띄게 떨어졌다.

지금은 상시 연결 3개(GitHub, 로컬 파일시스템, 데이터베이스 조회)만 남겨두고, 나머지는 특정 작업 세션에서만 켰다 끄는 방식으로 운영한다. MCP 명세가 점점 성숙해지면서 서버별 활성화/비활성화가 세션 단위로 가능해졌지만, 원칙은 변하지 않는다 — 연결이 많을수록 좋은 게 아니라, 지금 이 작업에 필요한 연결만 있는 게 좋다.

예약 작업과 대시보드 — 돌아가는 시스템의 현실

15화에서 만든 예약 작업 4개 중 3개가 살아 있다. 매일 아침 시장 동향을 수집하는 작업, 주간 프로젝트 현황 리포트, 주간 비용 모니터링. 월간 보고서 초안 작업은 2개월 만에 껐다. 이유는 단순하다 — 월간 보고서는 매달 강조점이 달라서, 자동 생성된 초안을 고치는 시간이 처음부터 쓰는 시간과 비슷해졌다.

16화의 대시보드 2개는 모두 살아 있다. 개인 지표 대시보드(수입·구독자·글 발행 수)와 프로젝트 현황 대시보드. 대시보드는 한 번 만들면 데이터만 갱신하면 되니까 유지비가 낮다. 다만 16화에서 경고한 대로 민감 정보를 대시보드에 직접 굽지 않는 원칙은 계속 지켰다. 외부 API에서 읽어오되, 대시보드 HTML 자체에 토큰이나 비밀번호가 박히는 일은 없도록.

21화에서 만든 Agent SDK 기반 마이크로 SaaS는 아직 소규모지만 돌아가고 있다. 15화의 예약 작업을 웹 폼으로 감싼 것인데, 외부 사용자 5명이 쓰고 있다. 주당 유지 시간 2시간이 가장 크지만, 이것만이 직접적인 수익을 만들고 있으니 유지할 가치가 있다.

눈에 보이지 않는 자산 — 위임 역량

표에는 안 나오지만 6개월간 가장 많이 변한 건 나 자신의 업무 방식이다. 4화에서 “프롬프트가 아니라 작업 지시서를 쓴다”고 했을 때는 그 차이를 머리로만 이해했다. 지금은 몸에 배었다.

변화를 구체적으로 적어보면 이렇다.

작업을 분해하는 시간이 줄었다. 예전에는 “이걸 AI한테 어떻게 설명하지?” 하며 30분씩 프롬프트를 다듬었다. 지금은 맥락·제약·완료조건·검증방법 네 가지를 반사적으로 적는다. 4화의 4요소가 습관이 됐다.
결과를 검증하는 눈이 생겼다. 17화에서 “AI가 동작하는 것처럼 보이는 코드를 만드는 지점 3가지”를 다뤘는데, 6개월 동안 그 패턴을 수십 번 잡았다. 이제는 AI가 건네주는 코드에서 ‘이거 진짜 동작하나?’를 확인하는 데 걸리는 시간이 반으로 줄었다.
“혼자 다 하려는 습관”이 많이 줄었다. 11화에서 서브에이전트를 다루면서 “탐색자 → 구현자 → 검증자” 역할 분리를 했는데, 이 사고방식이 인간 협업에도 영향을 줬다. 내가 다 알 필요가 없다는 걸 AI를 통해 배운 셈이다.

이 변화는 구독을 해지해도 사라지지 않는다. CLAUDE.md는 파일이니 지울 수 있지만, 작업을 분해하고 위임하는 역량은 한 번 익히면 돌이킬 수 없다. 그래서 눈에 보이지 않지만 이것이 가장 높은 ROI를 가진 자산이라고 생각한다.

숫자로 말하는 6개월 — AI 위임 결산의 손익

정산이라면 숫자가 있어야 한다. 아래는 6개월간의 실제 기록이다. 모든 숫자는 내 개인 상황이고, 독자의 환경에 따라 크게 달라질 수 있다. 일반화하지 마시라.

절약한 시간의 진짜 계산

먼저 좋은 소식. 6개월간 AI 도구를 활용해 절약한 시간은 대략 주당 10~12시간이다. 이건 보수적인 추정이다. 반복적인 코드 작성, 보고서 초안, 데이터 변환, 코드 리뷰 1차 패스 — 이런 작업에서 체감 절약이 확실했다.

연간으로 환산하면 약 520~624시간, 근무일 기준으로 65~78일이다. 이것만 보면 대단한 성과 같다. 18화에서 인용한 마이크로소프트 리서치의 연구에서도 AI 코딩 에이전트 사용자의 머지된 PR이 약 24% 더 많았다는 결론이 나왔으니, 숫자 자체는 현실적이다.

문제는 나쁜 소식이다.

투자한 시간 — 이것이 빠진 계산은 사기다

절약한 시간만 말하는 건 수익만 보고 비용을 안 보는 것과 같다. 아래는 6개월간 이 도구를 배우고 세팅하는 데 쓴 시간이다.

초기 학습 (1~2개월): 주당 약 15시간. CLI 설치부터 CLAUDE.md 작성, 권한 설정, 첫 Skill 제작까지. 3화에서 “30분이면 된다”고 했던 설치는 진짜 30분이었지만, 그 뒤의 학습 곡선이 가팔랐다.
중기 확장 (3~4개월): 주당 약 8시간. MCP 서버 연결, 플러그인 패키징, Cowork 세팅, 예약 작업 구성. 새 기능을 익히고 기존 워크플로에 통합하는 시간.
후기 안정 (5~6개월): 주당 약 4시간. 유지보수 + 간헐적 최적화. 새로 만드는 것보다 기존 것을 다듬는 시간이 더 많아졌다.

총합: 약 280시간. 이걸 절약 시간에서 빼야 한다.

6개월간 절약: 약 570시간 (주 10.5시간 × 26주, 초기에는 절약이 적으므로 보정).
6개월간 투자: 약 280시간.
순 절약: 약 290시간. 근무일 기준 약 36일.

290시간. 생각보다 크지 않다고 느낄 수 있다. 하지만 이건 첫 6개월이다. 투자 시간은 후반으로 갈수록 급격히 줄어들고, 절약 시간은 유지되거나 늘어난다. 7개월째부터는 주당 투자 2~3시간, 절약 10~12시간이니 순수익이 급격히 늘어난다. 초기 학습 비용이 높은 전형적인 J커브 패턴이다.

금전 비용의 전체 그림

시간보다 계산하기 쉬운 건 돈이다.

항목	월 비용 (USD)	6개월 합계	비고
구독료 (MAX)	$200	$1,200	개인 구독. 팀은 별도
인프라 (NAS + 도메인)	~$15	~$90	세션 DB + 게이트웨이
서드파티 MCP/API	~$30	~$180	외부 데이터 소스 연동
Agent SDK 운영비	~$45	~$270	마이크로 SaaS 호스팅 + API 호출
합계		~$1,740	약 240만 원 (환율 1,380원 기준)

6개월에 약 240만 원. 여기에 숨은 비용이 더 있다.

기회비용: 280시간을 AI 학습 대신 본업이나 다른 사이드 프로젝트에 썼다면? 시간당 가치를 보수적으로 3만 원으로 잡으면 840만 원.
삽질 비용: 뒤에서 다룰 ‘통하지 않았던 것 3가지’에 쓴 시간은 약 60시간. 이것은 투자가 아니라 손실이다. 180만 원.
컨텍스트 스위칭 비용: AI 도구를 쓰다가 안 되면 수동으로 전환하는 과정에서 생기는 집중력 손실. 정량화하기 어렵지만 체감상 초기 2개월 동안 매일 30분씩, 약 20시간.

전체 비용: 금전 240만 원 + 기회비용 840만 원 + 삽질 180만 원 = 약 1,260만 원.

전체 수익: 순 절약 290시간 × 3만 원 = 약 870만 원 + Agent SDK 서비스 수익(아직 소규모, 6개월간 약 150만 원) = 약 1,020만 원.

첫 6개월의 ROI는 마이너스다. 솔직히 말하면 아직 손익분기를 넘지 못했다. 하지만 앞서 말한 J커브를 감안하면, 7~12개월차에 학습 비용이 거의 사라지면서 월 기준 흑자로 전환될 것으로 보인다. 그리고 표에서 빠진 “눈에 보이지 않는 자산” — 위임 역량, CLAUDE.md를 통한 팀 암묵지 문서화, 업무 프로세스 가시화 — 은 금전 환산이 어렵지만 분명히 가치가 있다.

18화의 교훈 — 생산성만으로는 예산을 지킬 수 없다

18화에서 다뤘던 이야기가 여기서 다시 울린다. “생산성이 24% 올랐는데 라이선스가 끊겼다.” 내 경우에도 같은 구조다. 순수하게 시간 절약만 보면 대단하지만, 전체 비용을 합산하면 첫 6개월은 적자다. 만약 이걸 팀 단위로 도입했다면 — 10명 기준으로 구독료만 월 2,000달러, 학습 시간까지 합치면 도입 첫 분기에 수천만 원의 비용이 발생한다.

이 숫자를 감추고 “생산성 24% 향상”만 보고하면, 6개월 뒤에 CFO가 라이선스를 끊는다. 정직한 정산이 있어야 지속 가능한 투자 논거가 된다. 이 표를 보여줄 수 있는 사람이, 표를 숨기는 사람보다 오래 살아남는다.

통하지 않았던 것 3가지

6개월간 크고 작은 실패가 많았지만, 반복해서 같은 교훈을 준 것 세 가지를 고른다.

실패 1 — 매주 바뀌는 보고서를 자동화하려 한 것

9화에서 Skills를 배운 직후, 주간 경영 보고서 초안을 자동 생성하는 Skill을 만들었다. 첫 주는 완벽했다. 데이터 소스에서 숫자를 뽑고, 정해진 템플릿에 넣고, 전주 대비 증감을 표시하는 것까지 Skill이 해줬다.

2주 차에 이해관계자가 “이번 주는 분기 대비로 보여줘”라고 했다. Skill을 수정했다. 3주 차에 “그래프를 추가하고 색상을 바꿔달라”는 요청이 왔다. 다시 수정했다. 4주 차에 “양식을 전면 개편하자”는 결정이 내려졌다. Skill을 처음부터 다시 썼다.

5주 차에 깨달았다. 이 보고서의 양식은 “안정적인 프로세스”가 아니었다. 이해관계자의 관심사가 매주 바뀌니까 양식도 매주 바뀌는 것이 정상이었다. 이걸 자동화한다는 건 “사람의 변덕을 코드로 따라간다”는 뜻이고, 그건 자동화가 아니라 수동화의 위장이다.

교훈: 자동화 대상을 고를 때, “이 프로세스가 지난 3개월간 몇 번 바뀌었나?”를 먼저 세라. 3개월간 0번 바뀐 프로세스 → 자동화 적격. 3개월간 3번 이상 바뀐 프로세스 → AI에게 “초안 잡아줘”는 되지만, Skill로 굳히면 안 된다.

실패 2 — MCP 서버를 7개 동시에 연결한 것

이건 앞의 자산 목록에서 이미 언급했지만, 실패의 메커니즘을 좀 더 자세히 쓴다.

10화 이후 “연결할 수 있는 건 다 연결하자”는 욕심이 생겼다. GitHub, 파일시스템, 사내 위키 스타일의 마크다운 저장소, 데이터베이스, 브라우저, 캘린더, 메일. 7개의 MCP 서버를 동시에 활성화했다.

문제는 세 단계로 나타났다.

컨텍스트 오염 (7화 콜백): 코드 리팩터링을 요청하는데, AI가 캘린더의 “오늘 회의 3건” 정보를 참조해 “회의가 많으시니 간단한 수정만 제안드립니다”라는 응답을 내놨다. 농담 같지만 실화다.
응답 지연: 7개 서버 모두에 가능한 도구 목록을 로드하니 초기 컨텍스트만으로 수천 토큰이 소모됐다. 첫 응답까지의 대기 시간이 체감 2~3배 늘어났다.
보안 표면 확대 (19화 콜백): MCP 서버가 많아질수록 프롬프트 인젝션의 공격면도 늘어난다. 특히 사내 위키나 메일처럼 외부인이 내용을 수정할 수 있는 소스를 MCP로 연결하면, 악의적 내용이 AI의 컨텍스트로 흘러들 수 있다.

교훈: MCP 연결은 “기본 3개 + 필요시 1~2개 임시 추가”가 최적이다. “혹시 필요할까 봐” 연결해두는 건 “혹시 필요할까 봐” 앱을 설치해두는 것과 같다 — 자원을 먹고, 보안 구멍을 만들고, 실제로는 안 쓴다.

실패 3 — 팀 전체 워크숍으로 도입하려 한 것

20화에서 “사회적 네트워크가 하향식 지시를 이긴다”고 제목까지 달아놓고, 나 자신이 정확히 반대로 했다.

AI 도구의 효과를 개인적으로 확인한 뒤, 팀에도 퍼뜨리고 싶었다. 2시간짜리 워크숍을 기획했다. 슬라이드도 만들고, 라이브 데모도 준비하고, 실습 과제도 짰다. 당일, 10명이 참석했다.

결과:

이미 혼자 쓰고 있던 2명: “이거 이미 다 아는 건데요.” (시간 낭비)
관심은 있지만 시작 안 한 3명: “신기하네요.” → 이후 2명이 실제 사용 시작. 1명은 1주 만에 중단.
관심 없는 5명: 정중하게 참석하고, 이후 한 번도 열지 않음.

10명 × 2시간 = 20시간의 팀 시간을 썼는데, 실제로 정착한 사람은 2명. 인당 전환 비용이 10시간이다. 반면 20화에서 다뤘던 “동료 전파” 방식 — 관심 있는 1~2명에게 집중 지원하고 그들이 자연스럽게 퍼뜨리게 하는 방식 — 은 이후에 시도했고, 같은 기간에 3명이 더 정착했다. 인당 전환 비용은 약 3시간.

교훈: 워크숍은 이미 관심 있는 사람을 가속시키지, 관심 없는 사람을 전환시키지 않는다. 도입 초기에는 “좁고 깊게”가 “넓고 얕게”를 이긴다. 이건 20화에서 이미 쓴 내용인데, 알면서도 실수한 것이어서 더 뼈아프다.

2026년 하반기 — 지켜볼 변화 3가지

정산을 마치고 고개를 들어 앞을 보면, 하반기에 주목할 변화가 세 가지 있다. 전부 이 시리즈에서 다뤘던 주제의 연장선이다.

1. 멀티에이전트 오케스트레이션의 안정화

11화에서 서브에이전트 3단계 중첩을 다뤘을 때, 솔직히 “가능은 하지만 불안하다”는 느낌이었다. 탐색자 → 구현자 → 검증자 역할 분리는 개념적으로 깔끔했지만, 실제로 돌리면 에이전트 간 핸드오프에서 맥락이 손실되거나, 하위 에이전트가 상위의 의도를 오해하는 경우가 있었다.

하반기에 이 부분이 빠르게 안정화되고 있다. 에이전트 간 공유 메모리, 실패 시 자동 복구, 비용 상한 자동 적용 — 이런 것들이 프레임워크 수준에서 지원되기 시작했다. 이게 프로덕션 수준으로 안정되면, 11화에서 설명한 “조직도를 짜는 일”이 정말로 현실이 된다.

관전 포인트: 멀티에이전트가 안정화되면 21화에서 만든 마이크로 SaaS의 아키텍처가 근본적으로 바뀐다. 지금은 단일 에이전트가 순차 처리하는데, 병렬 에이전트가 가능해지면 처리량이 3~5배 늘 수 있다. 그러면 가격 구조도 바뀐다.

2. MCP 생태계의 보안 감사

10화와 19화에서 반복했던 경고 — “MCP 서버는 신뢰 경계다” — 가 업계 전체의 의제가 됐다. 검증되지 않은 커뮤니티 MCP 서버를 설치하는 것은 검증되지 않은 npm 패키지를 설치하는 것과 같은 위험이라는 인식이 퍼지고 있다.

하반기에 기대되는 것:

서명된 서버 레지스트리: 누가 만들었고, 어떤 권한을 요구하고, 감사 이력이 있는지를 중앙에서 확인할 수 있는 구조.
권한 매니페스트: MCP 서버가 설치 시 “나는 파일 읽기만 합니다”를 선언하고, 런타임에 그 이상을 요구하면 차단되는 체계.
자동 보안 스캔: 플러그인 마켓플레이스에 올라오는 MCP 서버를 자동으로 정적 분석해 위험 패턴을 탐지.

관전 포인트: 이 보안 인프라가 갖춰지면 12화에서 다뤘던 플러그인 생태계가 본격적으로 열린다. 지금은 “설치해도 괜찮을까?” 하는 불안 때문에 서드파티 플러그인 채택이 느린데, 신뢰 체계가 갖춰지면 상황이 달라진다.

3. 기업 AI 거버넌스의 제도화

18화(비용), 19화(보안), 20화(도입 전략)에서 각각 다뤘던 주제가 사실은 하나의 큰 주제다 — 기업의 AI 거버넌스. 비용을 어떻게 관리할 것인가, 보안 사고를 어떻게 예방할 것인가, 조직에 어떻게 퍼뜨릴 것인가. 이 세 질문에 일관된 정책으로 답하는 것이 거버넌스다.

하반기에 이 영역에서 두 가지가 움직인다.

첫째, 감사 이력의 표준화. AI 에이전트가 어떤 파일을 읽었고, 어떤 명령을 실행했고, 어떤 외부 서비스에 접근했는지를 기록하는 포맷이 통일되기 시작한다. 규제가 강한 환경 — 금융, 의료, 공공 — 에서는 이 감사 이력이 없으면 AI 도구 도입 자체가 불가능하다.

둘째, 라이선스 관리의 정교화. 18화에서 “극단 사례 월 140만 달러”를 언급했는데, 이런 비용 폭주를 방지하려면 개인별·팀별·프로젝트별 토큰 할당이 세밀해져야 한다. 클라우드 컴퓨팅에서 FinOps가 자리잡은 것처럼, AI 도구에도 “AI FinOps”가 등장할 것이다.

관전 포인트: 거버넌스가 제도화되면 20화에서 다뤘던 “팀 도입”이 훨씬 수월해진다. 지금은 선도자 개인이 위험을 감수하고 실험해야 하지만, 조직 수준의 정책이 생기면 “이 범위 안에서 자유롭게 쓰세요”라고 말할 수 있다. 자유와 통제의 균형. 6화에서 말한 “사고 치기 전에 막는 3중 방어”의 조직판이다.

AI 위임 결산 이후 — 독자에게 남기는 과제

24회에 걸쳐 말한 것을 한 문장으로 줄이면 이것이다.

AI가 코드를 짜주는 시대가 아니라, AI에게 일을 위임하는 시대다. 위임할 줄 아는 사람이 하나의 회사가 된다.

1화에서 이 문장을 처음 썼을 때는 슬로건에 가까웠다. 24화까지 온 지금, 이건 슬로건이 아니라 작업 기술서의 첫 줄이다. “위임”이라는 단어에 구체적인 스킬이 매핑된다.

맥락을 구조화하는 능력 (4화, 5화): CLAUDE.md를 쓰고, 작업 지시서의 4요소를 채우는 것.
경계를 설정하는 능력 (6화, 19화): 훅으로 위험 행동을 차단하고, 신뢰 경계를 정의하는 것.
비용을 관리하는 능력 (18화): 토큰 상한을 설정하고, ROI를 정직하게 계산하는 것.
자산을 포장하는 능력 (12화, 21화, 23화): 만든 것을 팔 수 있는 형태로 만드는 것.
실패를 분류하는 능력 (이 글): 통한 것과 안 통한 것을 구별하고, 안 통하는 것을 빨리 끊는 것.

이 다섯 가지가 24회를 관통하는 실제 커리큘럼이다.

지금 당장 할 수 있는 것

이 시리즈를 처음 읽는 분이든, 1화부터 함께 온 분이든, 다음 행동은 같다.

자기 자산을 정산하라.

위의 자산 목록 표를 자기 상황에 맞게 비워서 채워보라. 지금 AI 도구로 만든 것이 무엇인지, 그중 아직 쓰이는 것은 무엇인지, 유지에 얼마나 드는지. 이 표 하나가 다음 6개월의 투자 결정을 바꾼다.

아래는 자가 점검 프레임워크다. 노트앱이든 스프레드시트든 좋다.

# AI 위임 자산 점검표
## 1. 자산 목록
- [ ] CLAUDE.md (또는 동등한 AI 지시 문서)가 있는가?
- [ ] 반복 작업을 자동화한 Skill/워크플로가 몇 개인가?
- [ ] 외부 데이터를 연결한 커넥터/MCP가 몇 개인가?
- [ ] 무인으로 돌아가는 예약 작업이 있는가?
- [ ] 남에게 줄 수 있는(=팔 수 있는) 형태로 포장된 것이 있는가?

## 2. 비용 계산
- [ ] 월 구독료: ___원
- [ ] 월 인프라 비용: ___원
- [ ] 주간 유지 시간: ___시간
- [ ] 주간 절약 시간: ___시간
- [ ] 순 ROI: (절약 - 유지 - 학습) = ___시간/주

## 3. 정리 대상
- [ ] 만들었지만 안 쓰는 것: ___
- [ ] 유지비가 효용을 넘는 것: ___
- [ ] 학습했지만 적용하지 못한 것: ___

이 점검표를 채우는 데 30분이면 된다. 하지만 그 30분이 “막연히 AI를 쓰는 사람”과 “AI로 자산을 굴리는 사람”의 차이를 만든다.

1화부터 함께 온 분들에게

7월에 시작해서 8월 말까지. 1화에서 “판이 바뀌었다”고 했는데, 24화에서 정산해보니 바뀐 것은 판이 아니라 일하는 방식이었다. 도구는 계속 바뀔 것이다. 내년에 이 도구가 여전히 최선인지는 모른다. 하지만 위임하는 역량 — 작업을 분해하고, 맥락을 구조화하고, 경계를 설정하고, 결과를 검증하는 — 은 도구가 바뀌어도 남는다.

22화에서 “신뢰는 실명이 아니라 결과물에서 온다”고 했다. 이 시리즈도 마찬가지다. 24회의 글 자체가 아니라, 이 글을 읽고 나서 실제로 만들고 돌리고 정산한 것이 의미 있다. 읽기만 하면 소비이고, 만들면 자산이다.

시리즈를 처음 접한 분들에게

24화부터 읽으셨다면, 거꾸로 이 정산 결과를 보고 관심이 가는 부분부터 거슬러 올라가시라.

비용이 궁금하면 → 18화 (비용 거버넌스)
보안이 걱정되면 → 6화 (권한·샌드박스·훅) + 19화 (프롬프트 인젝션)
지금 당장 시작하고 싶으면 → 3화 (설치) + 4화 (작업 지시서) + 5화 (CLAUDE.md)
돈을 벌고 싶으면 → 21화 (Agent SDK 제품화) + 22화 (익명 사업) + 23화 (포트폴리오)
팀에 도입하고 싶으면 → 20화 (팀 전파) + 이 글의 실패 3번

전부 읽을 필요 없다. 지금 필요한 것만 읽고, 만들고, 돌리고, 정산하면 된다.

함정 — 이 시리즈 자체의 한계

마지막으로 이 시리즈 자체가 가진 한계를 적는다. 자기 글의 한계를 적는 게 이상할 수 있지만, 이것까지 적어야 정산이 완결된다.

생존자 편향: 20년차 개발자가 쓴 글이다. 이 정도 경력이 있으니 AI 도구의 출력물을 검증하고 방향을 잡을 수 있었다. 경력이 짧거나 도메인 지식이 얕은 상태에서 같은 결과를 기대하면 위험하다. AI는 전문성을 대체하지 않고 증폭한다 — 0을 곱하면 여전히 0이다.
도구 종속성: 이 시리즈는 특정 도구 생태계를 중심으로 쓰였다. 핵심 원칙(위임, 구조화, 검증)은 도구를 넘어 통용되지만, 구체적인 명령어와 설정은 도구가 바뀌면 다시 배워야 한다.
개인 사례의 한계: 규제가 강한 환경, 감사 이력이 남아야 하는 조직에서의 경험이지만, 여전히 한 사람의 사례다. 팀 규모, 업종, 보안 요건에 따라 최적의 접근은 달라진다.

이 한계를 알고 읽으면 도움이 되고, 모르고 따라하면 삽질한다. 그래서 매 회차마다 “함정”을 붙였다.

이번 회차의 수익화 지점

24회 전체를 관통하는 수익화 구조를 최종 정리한다. 23화에서 4가지 수익 유형을 비교했으니, 여기서는 “지금 당장 시작할 수 있는 것”만 뽑는다.

가장 빨리 팔 수 있는 형태: 5화에서 만든 CLAUDE.md 작성 노하우 + 9화의 Skill 제작법을 묶어 “AI 작업 위임 템플릿 팩”으로 판매. Gumroad, 탈잉, 클래스101 어디든 올릴 수 있다. 이 시리즈의 자가 점검 프레임워크(위 코드블록)를 PDF로 디자인해서 무료 배포 → 유료 팩 전환 퍼널도 가능하다.

가장 오래 돈이 되는 형태: 21화의 Agent SDK 마이크로 SaaS. 초기 셋업은 무겁지만, 한 번 돌기 시작하면 월 반복 수익(MRR)이 된다. 다만 18화에서 경고한 대로 원가 구조를 반드시 먼저 계산해야 한다. 토큰 원가가 매출의 60%를 넘으면 그날부터 적자 사업이다.

가장 리스크가 낮은 형태: 20화의 팀 도입 컨설팅. 자기 회사에서 검증한 프로세스를 다른 조직에 알려주는 것. 비용은 자기 시간뿐이고, 재고도 없고, 인프라 비용도 없다. 다만 22화의 원칙 — 회사 자산과 완전히 분리된 환경에서, 자기 시간에 — 은 반드시 지켜야 한다.

수익화에는 정답이 없다. 하지만 정산이 있는 수익화와 정산이 없는 수익화는 결과가 다르다. 이 글의 자산 목록과 비용 표를 자기 것으로 만들어 두면, 어떤 유형을 선택하든 “이게 남는 장사인가?”를 숫자로 판단할 수 있다. 숫자로 판단할 수 있는 사람이 살아남는다.

시리즈를 마치며 — 다음 과제

24회를 마친다. 처음엔 “AI 도구 사용법”을 쓰는 줄 알았는데, 쓰다 보니 “일을 위임하는 법”을 쓰고 있었다. 그리고 “일을 위임하는 법”을 다 쓰고 나니, 결국 “내가 진짜 해야 할 일이 무엇인가”를 묻는 글이 됐다.

AI에게 위임할 수 있는 일이 늘어날수록, 위임하고 남은 일의 밀도가 높아진다. 반복 작업이 사라지면 판단과 결정만 남는다. 그게 무서운 사람도 있고, 그게 기다려지는 사람도 있다.

이 시리즈를 읽고 무언가를 만들었다면, 다음 과제는 단 하나다.

정산하라. 그리고 계속하거나 끊어라.

숫자가 말하는 대로 따르면 된다. 남는 장사면 계속하고, 안 남으면 끊고, 그 시간에 다른 걸 해라. 감정이 아니라 정산이 결정하게 놔두면, 실패해도 배우는 실패가 된다.

6개월간 읽어주셔서 감사합니다. 위임할 줄 아는 사람이 하나의 회사가 되는 시대, 다음은 당신 차례다.

Photo by Jakub Zerdzicki on Pexels

📚 시리즈: Claude 활용 24회 — AI에게 일을 위임하는 법 (총 24화 중 24화)
◀ 이전 23화 (다음 차수는 아직 게시되지 않았습니다)

자주 묻는 질문

AI 자동화 자산을 만들면 유지 비용은 얼마나 드나요?

6개월간 21개 자산을 만든 결과, 15개가 활성 상태로 살아남았고 이를 유지하는 데만 주당 7시간이 소요됩니다. 아무것도 새로 만들지 않고 기존 시스템을 돌리기만 해도 매주 거의 하루치 업무가 사라지므로, 자동화는 공짜가 아니며 자동화의 자동화가 필요한 순간이 반드시 옵니다.

CLAUDE.md가 6개월 뒤에도 효과가 있었나요?

CLAUDE.md는 6개월간 가장 높은 ROI를 보인 자산입니다. 유지 비용이 거의 0에 가까운 반면, 새 프로젝트에 합류하는 사람이 처음 읽는 온보딩 문서 역할을 하여 별도 세션 없이 2시간 내 첫 커밋이 가능해졌습니다. 진짜 가치는 AI 지시서가 아니라 팀이 암묵적으로 알던 것을 명시적으로 기록한 문서라는 점이었습니다.

AI에게 일을 위임하고 만든 것 중 실패율은 어느 정도인가요?

6개월간 만든 21개 자산 중 약 30%인 6개가 유지비를 감당하지 못하거나 필요가 사라져 중단되었고, 생존율은 71%였습니다. 시간 절약을 계산했을 때도 절약분의 40%는 배우는 데 이미 소모한 시간이어서, 실제 순수 절약은 기대보다 적었습니다.

Tags:

1인 회사 AI AI 도구 도입 실패 AI 위임 결산 AI 자동화 ROI Claude 활용 Claude 활용 24회 — AI에게 일을 위임하는 법-24화 연재:Claude 활용 24회 — AI에게 일을 위임하는 법