AI 자동화에 5,000시간을 투자하며 얻은 12가지 핵심 교훈

URL: https://www.youtube.com/watch?v=wQkFDtqwQCk 날짜: 2026-08-18 채널: Tech Bridge

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==AI 자동화에서 경쟁력을 만드는 것은 특정 모델이나 도구가 아니라, 실제 사업 성과를 증명하고 AI를 관리·검증·통제하는 시스템과 문제 해결 방식이다.==

• AI로 만든 데모와 포트폴리오가 평준화된 상황에서는 투입 시간, 확보한 리드, 절감한 비용처럼 사업 결과를 기록한 영수증(receipt)이 신뢰를 만든다.
• 같은 모델을 모두가 써도 각자의 도메인 지식, 실패 경험, 부정형 지시(negative prompting), 컨텍스트 엔지니어링(context engineering)에 따라 결과가 달라진다.
• AI를 실제 업무에 투입할 때는 자기 검증(eval), 최소 권한(permission), 비용에 맞춘 모델 라우팅(model routing), 사업의 북극성 지표(north star)를 함께 설계해야 한다.

5,000시간 이상 AI를 활용해 7자리 수익을 내는 에이전시를 만들고 40만 명 이상을 교육하며 사업 전체를 자동화한 경험은, AI를 많이 아는 사람이 되는 것보다 AI를 기본적으로 먼저 시도하고, 구체적인 결과를 측정하며, 실패할 수 있는 시스템을 안전하게 운영하는 사람이 되는 편이 중요하다는 결론으로 이어진다. 아래 12가지 교훈은 AI 분야에 새로 진입하는 사람, 회사 내부 AI 담당자, 고객을 상대하는 자동화 에이전시 모두에 적용된다.

1. 포트폴리오보다 실제 결과의 영수증을 모아라

AI 분야에 들어가는 길은 회사 안에서 AI 담당자가 되는 것과 자신의 에이전시를 세워 고객을 찾는 두 가지로 크게 나뉘지만, 두 길 모두 결과를 증명하는 능력이 필요하다.

1.1. 두 가지 진입 경로와 선택 기준

1. 사내 AI 전문가 경로

   1. 기존 회사에서 업무를 이해한 상태로 AI 프로젝트를 도입하면, 내부 프로세스와 이해관계자에 대한 지식을 활용할 수 있다.
   2. 발표자는 Goldman Sachs에서 일할 때 회사의 AI 담당자가 되고 싶었지만, 의사결정이 오래 걸리고 관료적 절차(red tape)가 많다고 판단했다.

2. AI 에이전시 경로

   1. 사내에서 역할이 만들어지기를 기다리는 대신 회사를 떠나 자신의 AI 에이전시를 설립하고 고객을 직접 찾는 방식이다.
   2. 어느 길이 절대적으로 우월한 것이 아니라, 자신의 상황과 강점에 맞는 경로를 선택해야 한다.

1.2. AI 제작물의 평준화와 신뢰 격차

1. 누구나 비슷한 포트폴리오를 갖게 된 이유

   1. AI를 활용한 개발이 쉬워지면서 누구나 포트폴리오를 만들 수 있게 됐다.
   2. 많은 사람이 같은 유튜브 튜토리얼을 보고 같은 데모를 만들기 때문에, 외부에서 보면 실제 실력자와 주말에 급히 데모를 만든 사람을 구분하기 어렵다.

2. 포트폴리오와 영수증의 차이

   1. 포트폴리오는 “이것을 내가 만들었다”라고 말하는 증거다.
   2. 영수증은 “이 제품이 실제 사업에 이런 영향을 주었다”라고 말하는 증거다.
   3. 고객과 서비스 제공자 양쪽의 가장 큰 문제는 이 신뢰 격차(trust gap)이며, AI Automation Society가 인증 프로그램을 구축하는 이유도 결과를 증명할 수 있게 하기 위해서다.

1.3. 결과를 기록하는 실전 방법

1. 수치로 전후를 남겨라

   1. 자동화 전에는 어떤 프로세스가 몇 시간 걸렸고, 자동화 후에는 몇 시간이 걸리는지 적는다.
   2. 놓치던 잠재 고객(leads)이 몇 명이었고, 자동화 후 그중 몇 명을 포착하게 됐는지 기록한다.

2. 작은 프로젝트도 증거화하라

   1. 자기 혼자 쓰는 작은 프로젝트라도 작업 수치와 결과를 기록해야 한다.
   2. 워크플로 스크린샷 다섯 장만 올리면 다른 사람과 똑같아 보이지만, 실제 결과 세 가지를 보여주면 눈에 띈다.
   3. 짧은 워크스루(walkthrough) 시연 영상을 녹화해 제작 과정과 결과를 함께 남긴다.

2. 도구가 아니라 도구 아래의 기술에 집착하라

도구는 계속 바뀌지만 API와 문제 해결을 이해하는 능력은 다음 도구로 그대로 이전된다.

2.1. 도구 교체와 불변의 학습

1. 도구는 영원하지 않다

   1. 발표자는 오랫동안 Nitn(자막 표기)을 주로 사용해 유튜브 채널을 한두 가지 도구로 구축했다.
   2. 현재 주로 쓰는 도구는 Claude Code(자막의 ‘클라우드 코드’ 표기)지만, 더 새롭고 나은 도구는 계속 등장할 것이며 교체는 멈추지 않는다.

2. 옮겨지는 것은 사고방식이다

   1. API 호출(API call)이 무엇인지, 어디에서 오류가 발생하는지, 오류 메시지를 어떻게 읽고 고치는지에 대한 학습은 도구를 바꿔도 사라지지 않는다.
   2. 도구를 바꿀 때도 그 지식을 새 도구에 그대로 옮겨 쓸 수 있다.

2.2. 도구 불가지론적 시스템

1. AI 운영 체제의 핵심은 단순하다

   1. 폴더, 마크다운 파일, 명령어와 지시문으로 만든 AI 운영 체제는 특정 제품 자체보다 구조가 중요하다.
   2. Claude Code, Codex, Hermes, 다음 달에 나올 플랫폼 중 어디에서 실행하더라도 데이터와 지시 체계가 이전돼야 한다.

2. 기초 기술을 우선하라

   1. 완벽한 도구가 나올 때까지 기다리지 말고, 좋아하던 도구가 교체돼도 불안해하지 않는다.
   2. 명확하게 소통하는 법, 문제를 쪼개는 법, 첫 해결책이 실패했을 때 더 나은 해결책을 찾는 법을 연습한다.

3. AI 네이티브는 지식량이 아니라 기본 동작이다

AI 네이티브(AI native)는 모델 이름과 도구 목록을 많이 아는 상태가 아니라, 일을 받았을 때 AI를 먼저 시도하는 사고방식이다.

3.1. 첫 반응을 바꿔라

1. 기본 질문의 전환

   1. 일이 책상 위에 놓였을 때 “AI가 이 일을 할 수 있을까? 일단 시도해 보자”라고 생각하는지가 중요하다.
   2. 예전 방식대로 처음부터 끝까지 수작업으로 갈아 넣는 것이 자동 반응이라면 AI 네이티브 방식과 거리가 있다.

2. 가능/불가능의 이분법을 버려라

   1. “AI가 할 수 있는가?”는 예·아니오로 끝나는 질문이 아니다.
   2. 진짜 질문은 “AI가 이 일의 어느 정도까지 해낼 수 있는가?”다.

3.2. 부분 자동화도 승리로 계산하라

1. 70% 자동화

   1. AI가 업무의 70%를 처리하고 나머지 30%를 사람이 마무리해도 큰 성공이다.
   2. 100% 수동으로 처리하는 사람보다 훨씬 앞선다.

2. 25% 자동화

   1. AI가 첫 25%만 처리해도 여전히 이득이다.
   2. 작은 자동화가 반복되면 사람이 처음부터 전부 처리하는 방식과의 격차가 누적된다.

3. 정답은 계속 갱신된다

   1. 현재의 모델과 주변 도구는 앞으로 나올 상태 중 가장 나쁜 상태에 가깝다.
   2. 오늘 AI가 25%밖에 못 하는 일도 모델과 도구가 발전하면 더 높은 비율로 자동화될 수 있다.

4. AI 자체보다 시스템과 전문성이 가치 있다

모델과 프롬프트는 모두가 접근할 수 있는 공통 자원이고, 차이는 그 위에 얹는 전문 지식과 시스템에서 발생한다.

4.1. 같은 모델이 다른 결과를 내는 이유

1. 공평한 모델 접근의 역설

   1. 모두가 같은 Opus 모델을 쓴다고 해서 모두가 같은 결과를 얻지는 않는다.
   2. 사람마다 AI 모델과 하네스(harness, 모델을 감싼 애플리케이션)에 투입하는 시스템과 전문성이 다르기 때문이다.

2. 회계사 예시

   1. 예산을 작성하는 스킬을 회계사가 만들면 스프레드시트를 한 번도 만져보지 않은 사람보다 훨씬 낫다.
   2. 회계사는 좋은 예산의 모습과 예산 과정에서 사람들이 자주 실수하는 지점을 이미 알고 있기 때문이다.

4.2. 실패 경험을 부정형 지시로 바꿔라

1. 실패 지뢰를 문서화하기

   1. 5,000시간 동안 수많은 지뢰를 밟은 경험은 다시 밟지 않기 위한 규칙이 된다.
   2. 스킬, 시스템, 지시문, 프롬프트에 “무엇을 하지 말아야 하는지”를 지속적으로 명시한다.
   3. 부정형 프롬프트(negative prompt)의 금지 목록은 실패 경험을 글로 옮긴 것이며, 초보자는 무엇을 금지해야 하는지조차 모를 수 있다.

2. Anthropic 문서의 사례

   1. Anthropic의 Claude 프롬프트 문서에도 부정형 지시가 많이 들어 있다.
   2. “요청받은 범위를 넘어 기능을 추가하지 말라”, “일어날 수 없는 시나리오를 위한 오류 처리를 추가하지 말라” 같은 지시가 대표적이다.

4.3. 컨텍스트 엔지니어링의 의미

1. 모델 위에 얹는 모든 것

   1. 같은 모델과 같은 하네스를 받았을 때, 컨텍스트 엔지니어링(context engineering)은 그 위에 추가하는 모든 요소다.
   2. 모델에 공급하는 지식, 프롬프트 방식, 지시문, 스킬, 시스템이 모두 포함된다.

2. 자기 두뇌를 모델에 적용하기

   1. 컨텍스트 엔지니어링은 강력한 AI 모델에 자신의 두뇌와 업무 경험을 적용하는 방법이다.
   2. 따라서 경쟁력은 “가장 멋진 모델을 골랐는가”보다 “내가 아는 실패와 판단 기준을 시스템에 얼마나 잘 심었는가”에서 나온다.

5. AI와 대화하지 말고 관리하라

좋은 결과를 얻는 사람은 프롬프트만 잘 쓰는 것이 아니라 AI에게 문제를 맡기고, 질문·비판·완료 조건을 관리한다.

5.1. 요청자가 아니라 관리자가 되는 방식

1. 문제와 해결 과정 분리

   1. “이것을 작성해라”, “이것을 조사해라”라고 바로 지시하는 대신 해결해야 할 문제를 건넨다.
   2. AI가 어떻게 해결할지 스스로 제안하게 하고, 실제 구축 전에 원하는 것을 완전히 이해할 때까지 질문하게 한다.

2. 완료선을 먼저 그어라

   1. 무엇이 완료(done)인지 분명한 finish line을 설정해야 AI가 절반만 끝내고 멈추지 않는다.
   2. 명확한 완료 조건이 있으면 AI가 하위 에이전트(sub-agent)에게 작업을 나누고, 아이디어부터 검증된 실행까지 계획할 수 있다.
   3. 이 방식은 사람과 AI 사이의 불필요한 왕복(back-and-forth)을 절반으로 줄인다.

5.2. AI를 악마의 변호인으로 활용하라

1. 아첨하는 모델의 한계

   1. AI 모델은 사용자를 기쁘게 하도록 학습돼 있어 계획의 의견을 물으면 듣기 좋은 칭찬을 할 수 있다.
   2. 모든 계획에는 사각지대가 있으므로 “좋은 계획인가?”라는 질문 하나만으로는 부족하다.

2. 여러 관점의 공격 테스트

   1. 회의적인 고객, 경쟁자, 실제 유지보수를 맡을 엔지니어 등 여러 페르소나에게 계획을 공격하게 한다.
   2. 각 관점은 다른 관점이 놓친 구멍을 발견한다.
   3. 여러 공격을 통과한 결과가 단일 모델에게 “괜찮은가?”라고 물은 결과보다 훨씬 철저하다.

5.3. AI는 새로운 직원이다

1. AI를 대화 상대나 채팅 친구로만 보지 않는다.
2. AI는 다른 작은 AI 직원들을 고용하고 위임할 수 있는 새로운 직원이며, 최종 품질은 관리와 오케스트레이션(orchestration)의 수준에 달려 있다.

6. AI가 스스로 검증하게 하라

AI 작업은 처음부터 완성품이 아니라 60~70% 수준으로 나오는 경우가 많으므로, 인간의 피드백 왕복을 줄이려면 검증 루프를 시스템에 넣어야 한다.

6.1. 완료율을 올리는 자기 검증 루프

1. 일반적인 왕복의 문제

   1. 첫 결과는 보통 60~70% 정도다.
   2. 사람이 피드백을 주면 AI가 고치고, 다시 피드백을 주는 과정을 반복해 90~95%까지 끌어올린다.

2. 검증을 완료 조건으로 만들기

   1. AI가 자기 작업을 검증하고, 조건이 충족되고 산출물에 확신이 생길 때까지 검증을 멈추지 않게 한다.
   2. 사람은 프롬프트 한 번을 보내고 기다린 뒤, 이미 90~95% 완성된 결과를 받을 수 있다.

6.2. 인간의 검수 절차를 자동화하라

1. 검수 질문

   1. 사람이 그 결과물을 받았다면 어떻게 검토하고 승인 도장을 찍을지 먼저 묻는다.
   2. 눈으로 볼지, 테스트할지, 가입 절차를 직접 통과할지 등 사람이 하던 확인 절차를 목록으로 만든다.

2. AI가 수행할 수 있는 검증

   1. 브라우저를 조작하고 테스트를 작성하며 출력물을 분석할 수 있다.
   2. 여러 관점에서 결과를 살펴보고 실제 조건을 충족했는지 증명하게 할 수 있다.

6.3. 웹사이트 검증 사례

1. 스크린샷 루프를 돌며 모든 요소가 화면 경계를 벗어나지 않는지 확인한다.
2. 모바일에서 보기 좋은지, 시각적으로 문제가 없는지 점검한다.
3. 모든 버튼을 클릭해 작동 여부를 확인한다.
4. 폼의 형식이 올바른지, 올바른 웹훅(webhook)으로 전송되는지 테스트한다.

7. AI가 접근할 수 있는 것은 언젠가 사용할 것이라고 가정하라

프롬프트에 적은 금지 규칙은 제안일 뿐이고, 실제 도구 권한은 물리적인 제한이어야 한다.

7.1. 15만 명에게 잘못 발송된 이메일

1. 실제 사고

   1. 한 에이전트가 약 15만 명에게 할인 코드가 포함된 이메일을 보냈다.
   2. 에이전트에게 전체 발송을 지시한 사람은 없었다.
   3. 에이전트는 할 일 목록에 있는 작업을 보고 “전체 목록에 할인 코드를 작성하고 발송하라”는 뜻으로 해석한 뒤 그대로 실행했다.

2. 핵심 교훈

   1. “이메일을 보내지 말고 초안만 작성하라”는 프롬프트 권한 계층(prompt permissioning layer)과 실제로 발송 도구를 가졌는지는 전혀 다른 문제다.
   2. 발송 도구가 남아 있으면 에이전트는 언젠가 발송할 수 있다고 가정해야 한다.

7.2. 프롬프트 제한과 도구 제한

1. 비결정성(nondeterminism)

   1. 같은 작업을 100번 실행해도 100개의 서로 다른 결과가 나올 수 있다.
   2. 모델을 바꾸면 시스템 행동과 스킬 해석 방식도 달라진다.
   3. 따라서 프롬프트에만 있는 규칙은 제안(suggestion)이고, 도구에 있는 규칙은 실제 제한(restriction)이다.

2. 범위가 제한된 API 키(scoped API key)

   1. API 키는 에이전트가 서비스에 로그인하는 비밀번호이며, 어떤 문을 열 수 있는지 범위를 제한할 수 있다.
   2. 이메일 초안 작성 권한만 주고 발송 권한은 아예 부여하지 않는 식으로 설계한다.
   3. 신입 직원에게 신용카드를 건네며 “살 수 있지만 절대 사용하지 말라”고 말하지 않는 것과 같은 원리다.

7.3. 권한 감사 체크리스트

1. 에이전트가 만질 수 있는 모든 도구, 데이터베이스, 파일, 키를 목록으로 만든다.
2. 각각을 언젠가 모두 사용할 수 있다고 보고 불필요한 권한을 제거한다.
3. 직접 구축하지 않은 시스템이라면 “스스로 실제로 무엇을 할 수 있는가?”, “발송할 수 있는가, 아니면 초안만 만들 수 있는가?”를 구축자에게 물어야 한다.
4. 답이 두렵다면 프롬프트를 고치는 것이 아니라 접근 권한을 고친다.

8. 한 번 작동한 에이전트가 아니라 반복 성공률을 측정하라

에이전트가 한 번 한 출력에서 작동했다는 사실은 100번 실행했을 때의 성공률을 전혀 보장하지 않는다.

8.1. AI 평가(evals)의 필요성

1. 모델의 비결정성 때문에 단일 성공 사례로 시스템 품질을 판단할 수 없다.
2. 실제 실행에 가까운 사례 묶음으로 AI evals를 돌려야 평균적인 성공 여부를 확인할 수 있다.

8.2. 고객 지원 에이전트와 골든 데이터 세트

1. 지원 에이전트 사례

   1. 고객을 조회하고 데이터베이스에서 관련 정보를 찾은 다음 응답을 작성하는 지원 에이전트를 구축했다.
   2. 사람이 직접 작성했고 품질이 좋다고 확인한 실제 응답 500개를 모았다.

2. 골든 데이터 세트(golden data set)

   1. 500개 응답을 정답 기준(source of truth)으로 시스템에 다시 투입했다.
   2. 에이전트가 성공 기준을 충족한 횟수를 점수로 계산해 버전별로 비교했다.

8.3. 평가자 설계와 변경 검증

1. 정답이 완전히 객관적이면 코드로 채점한다.
2. 정답성에 판단과 추론이 필요하면 LLM을 심판(LLM as a judge)으로 사용한다.
3. 평가 기준은 실제 사람이 어떻게 작업을 평가하고 성공을 정의하는지에 맞춰 설계한다.
4. 프롬프트, 도구 설정, 모델을 바꿀 때마다 동일한 평가를 다시 실행한다.
5. 개선될 것이라고 확신한 변경이 오히려 점수를 떨어뜨릴 수 있으므로 직감에 의존하지 않는다.
6. 실제 고객 앞에서 문제를 발견하기보다 개발 단계에서 “이 변경이 좋아졌는가, 나빠졌는가”를 근거와 함께 확인한다.
7. 다음 에이전트가 실제 데이터에 접근하기 전에 정답을 아는 실제 사례를 최소 20개라도 모아 모든 버전을 채점한다. 골든 데이터 세트가 클수록 좋다.

9. 사업을 물이 흐르는 파이프로 보고 막힘과 누수를 찾아라

자동화의 진짜 가치는 이해관계자가 주문한 기능을 그대로 만드는 데 있지 않고, 사업 성장을 막는 제약(constraint)을 찾아 해결하는 데 있다.

9.1. 사업 파이프의 구조

1. 앞단의 물: 트래픽

   1. 사업 앞단으로 들어오는 물은 유입되는 관심과 잠재 고객이다.
   2. 광고, 콘텐츠, 영업 활동으로 들어오는 리드가 여기에 해당한다.

2. 뒷단의 물: 이익

   1. 뒷단에서 흘러나오는 물은 실제로 사업에 남는 이익과 생애 매출(lifetime revenue)이다.
   2. 들어온 관심이 수익으로 전환되기 전에 사라지면 사업이 성장하지 않는다.

3. 두 가지 고장

   1. 중간의 막힘(clog)은 어느 단계에서 흐름이 정체돼 전체를 뒤로 밀어 올린다.
   2. 누수(leak)는 돈이 옆으로 새어 끝까지 도달하지 못하게 한다.

9.2. 주문받은 기능과 실제 제약의 차이

1. 수백 건의 구축 경험에서 배운 가장 큰 교훈은 이해관계자가 요청하는 것이 실제 제약인 경우가 거의 없다는 점이다.
2. 에이전시라면 고객이 “챗봇이 필요하다”, “이 자동화가 필요하다”고 말하고, 사내 담당자라면 상사가 특정 기능을 요청한다.
3. 그 기능은 이해관계자가 생각한 해결책일 뿐이며, 실제 가치는 그들이 보지 못한 막힘이나 누수를 찾아내는 데 있다.

9.3. 주문 접수자에서 컨설턴트로

1. 구축 전에 프로세스를 처음부터 끝까지 걸어가며 어디에서 일이 쌓이는지 살핀다.
2. 돈이 어디에서 새는지, 시간과 비용을 가장 많이 잃는 지점이 어디인지 질문한다.
3. 이 관점으로 제안하면 단순히 요청받은 것을 만드는 주문 접수자가 아니라 사업 성장과 수익을 진심으로 생각하는 컨설턴트로 인식된다.
4. 결론은 단순하다. 막힘을 찾고, 누수를 찾고, 파이프를 고치는 방법을 찾아야 한다.

10. 만들기 전에 하나의 북극성 지표를 정하라

모든 프로젝트에는 움직이려는 단 하나의 지표와 명확한 종료선이 있어야 하며, 구축 전에 이해관계자와 합의해야 한다.

10.1. 광고 대행사와 AI 프로젝트의 차이

1. 광고 대행사의 명확한 계약

   1. 기업은 매주 광고비 10,000달러를 쓴다.
   2. 광고 대행사는 그 광고로 매주 50,000달러의 추가 수익을 가져오겠다고 약속한다.
   3. 투자와 추가 수익이 비교되므로 누구나 결과가 가치 있었는지 판단할 수 있다.

2. AI 프로젝트의 모호함

   1. AI 프로젝트는 시간을 절약하거나 비용을 줄이는 목적으로 설계되는 경우가 많다.
   2. 시간이 절약됐다는 말만으로는 최종 수익과 마진에 미친 영향이 흐릿할 수 있다.
   3. 자동화 담당자가 그 영향력을 구체적인 숫자로 명확하게 보여줘야 한다.

10.2. 기준선과 북극성 지표 설정

1. 현재 사업이 주당 잠재 고객 5명을 얻고 있다고 가정한다.
2. 구축 전에 “AI 자동화로 2개월 안에 주당 리드를 5명에서 15명으로 늘리면 성공인가? 매출이나 마진에 의미 있는 변화가 생기는가?”라고 묻는다.
3. 팀 전체가 성공이라고 답하면 주당 15명이 프로젝트의 북극성(north star)이 된다.
4. 배포 뒤에는 그 숫자가 올라갔는지 내려갔는지 모두가 확인할 수 있다.

10.3. 한 번의 대화가 만드는 차이

1. 기준선과 목표를 합의하면 구축의 finish line이 생긴다.
2. 이해관계자는 정확히 무엇을 얻었는지 알게 된다.
3. “x, y, z를 자동화했다”라는 설명 대신 실제 숫자를 포함한 견고한 사례 연구(case study)를 만들 수 있다.

11. 작업에 맞는 모델을 라우팅해 수익성을 지켜라

토큰 비용을 통제하지 않으면 AI 작업이 돈을 벌기는커녕 손실을 만들 수 있으므로, 각 단계에 필요한 최소 비용 모델을 배치해야 한다.

11.1. 토큰과 과도한 모델 사용

1. 토큰(token)은 AI 모델이 요금을 부과하는 단위이며, 입력하는 단어와 출력하는 단어마다 비용이 발생한다.
2. 모든 단계에 가장 크고 똑똑하고 비싼 모델을 투입한 뒤 비용을 다시 생각하지 않는 것이 흔한 실수다.

11.2. 작업별 모델 매칭 사례

1. 수십만 단어 분량의 기사를 읽고 한 문단으로 요약하는 일은 반복적이고 규칙적인 작업이다.
2. 빠르고 저렴한 Haiku 같은 모델이면 몇 푼 수준으로 처리할 수 있다.
3. 그런 요약에 Fable 5(원문 자막 표기)를 쓰는 것은 과하다.
4. 다만 요약을 사업 전략에 적용해 의사결정을 내려야 하는 마지막 추론 단계라면 Fable 5가 가치 있을 수 있다.

11.3. 모델 라우팅과 비용 절감

1. 모델 라우팅(model routing)은 각 작업을 실제로 처리할 수 있는 가장 저렴한 모델로 보내는 방식이다.
2. 비싼 모델은 정말 필요한 순간에만 호출한다.
3. 같은 출력 품질을 유지하면서 청구액을 10배 이상 줄일 수 있다.
4. 지역 모델(local model)은 점점 더 작아지고 정교해지고 있으며, 일부 작업은 완전히 무료로 실행할 수도 있다.
5. 따라서 작업에 맞는 모델을 선택하는 기준과 기대 수준은 계속 높아진다.

12. 직함보다 증명이 먼저다

학위와 직함을 얻은 뒤 일을 시작하는 기존 순서가 AI 시대에는 뒤집혔으며, 이미 일을 하고 있는 사람이 새로운 AI 역할을 만든다.

12.1. 역할이 생기기 전에 일을 시작하라

1. 기존 각본은 학위를 따고 직함을 얻은 다음 그 직무를 수행하는 순서였다.
2. AI 관련 역할로 발탁되거나 승진한 사람들은 역할이 존재하기 전부터 이미 관련 업무를 하고 있었다.
3. 업무 수행은 절반이고, 나머지 절반은 동료와 상사가 그 사람을 회사의 AI 담당자로 보기 시작하는 과정이다.

12.2. 전문가의 기준은 상대적이다

1. AI 담당자는 지하실에서 모델을 훈련하는 괴짜 전문가일 필요가 없다.
2. 같은 건물의 다른 사람들과 비교했을 때 실제로 실험하고 작은 테스트를 돌리는 사람이면 상대적으로 전문가가 된다.
3. 최신 AI 소식을 따라가고, AI 프로젝트를 사업에 도입하는 행동이 가만히 있는 사람과의 차이를 만든다.

12.3. 첫 고객과 첫 역할을 만드는 증거

1. 매주 하기 싫고 반복적인 업무 하나를 골라 자동화 시스템을 만든다.
2. 만든 뒤 팀원과 상사에게 보여주고, 일상 업무에 어떤 실제 영향이 생겼는지 함께 보여준다.
3. 시간이 지나면 조직은 이미 하고 있는 일을 중심으로 새로운 자리를 만들게 된다.
4. 첫 고객을 찾는 사람도 먼저 자기 자신을 위해 무언가를 만들어야 한다.
5. 약속만 제시하는 대신 실제 결과물을 들고 고객을 만나면 proof가 promises를 이긴다.

주요 발언 모음

“포트폴리오는 ‘내가 이것을 만들었다’고 말하지만, 영수증은 ‘이것이 사업에 실제로 무엇을 했는지’를 말한다.”

“AI가 이것을 할 수 있는가가 아니라, AI가 이것을 어느 정도까지 할 수 있는가를 물어라.”

“AI 네이티브라는 것은 얼마나 많이 아느냐가 아니라, 뇌가 기본적으로 무엇에 먼저 손을 뻗느냐의 문제다.”

“프롬프트에 있는 규칙은 제안이지만, 도구에 있는 규칙은 실제 제한이다.”

“다음 에이전트가 실제로 무언가를 만지기 전에, 정답을 아는 실제 사례를 모아 모든 버전을 채점하라.”

“막힌 곳을 찾고, 누수되는 곳을 찾고, 그 파이프를 어떻게 고칠지 알아내라.”

“증명이 먼저다.”

핵심 데이터 & 수치

• 5,000시간 이상: 발표자가 AI를 활용한 개발에 투자한 시간이다.
• 7자리 수익: AI로 구축한 에이전시의 수익 규모다.
• 40만 명 이상: AI 활용을 교육한 사람의 규모다.
• 두 가지 진입 경로: 사내 AI 담당자가 되거나 자신의 AI 에이전시를 운영하는 선택지다.
• 70% / 25%: AI가 업무의 70% 또는 첫 25%만 처리해도 수동 작업보다 큰 이득이라는 기준이다.
• 60~70% → 90~95%: 일반적인 첫 산출물 완성도와 피드백·검증을 거친 목표 수준이다.
• 15만 명: 에이전트가 실수로 할인 코드 이메일을 보낸 수신자 규모다.
• 500개: 지원 에이전트 평가를 위해 모은 인간 작성 정답 응답 수다.
• 최소 20개: 처음 시작할 때도 모아야 하는 골든 평가 사례의 현실적인 최소량이다.
• 주당 리드 5명 → 15명, 2개월: 북극성 지표를 합의하는 예시다.
• 주당 광고비 10,000달러 → 추가 수익 50,000달러: 광고 대행사 계약의 명확한 결과 기준 예시다.
• 10배 이상: 작업별 모델 라우팅으로 같은 품질에서 줄일 수 있는 비용 규모다.

핵심 요약 (20줄)

AI 자동화에 진입하는 길은 사내 AI 담당자가 되거나 고객을 찾는 에이전시를 세우는 두 가지 경로로 나뉜다.

Goldman Sachs에서 AI 역할을 기다리던 선택은 긴 절차 때문에 자신의 AI 에이전시를 세우는 선택으로 바뀌었다.

AI 제작이 쉬워질수록 비슷한 포트폴리오보다 실제 시간 절감과 리드 증가를 기록한 영수증이 신뢰를 만든다.

작은 프로젝트라도 전후 수치를 적고 짧은 워크스루를 녹화하면 주말 데모와 실전 결과를 구분할 수 있다.

새로운 도구는 계속 교체되므로 API 이해, 명확한 소통, 문제 분해, 실패 후 개선 같은 기초 기술이 오래 남는다.

AI 네이티브의 기준은 모델 이름을 많이 아는 것이 아니라 일을 받자마자 AI를 먼저 시도하는 기본 반응이다.

AI가 업무의 70%만 처리하거나 첫 25%만 줄여도 전부 수작업으로 처리하는 방식보다 앞선다.

같은 모델도 전문 지식과 실패 경험을 얹는 컨텍스트 엔지니어링에 따라 결과가 달라진다.

부정형 프롬프트는 과도한 기능 추가나 불필요한 오류 처리를 막아 과거의 실패를 시스템에 반영한다.

AI를 관리하려면 해결할 문제, 확인할 질문, 여러 페르소나의 반론, 명확한 완료선을 함께 설계해야 한다.

AI는 채팅 친구가 아니라 하위 에이전트에게 일을 위임할 수 있는 새로운 직원이다.

사람이 하던 브라우저 점검, 모바일 확인, 버튼 테스트, 폼과 웹훅 검증을 AI의 자기 검증 루프에 넣어야 한다.

에이전트가 접근할 수 있는 도구는 언젠가 사용할 수 있으므로 프롬프트보다 최소 권한과 범위 제한 API 키가 중요하다.

한 번 성공한 에이전트는 100번의 성공률을 증명하지 못하므로 실제 정답 사례로 AI evals를 실행해야 한다.

사업의 앞단에는 트래픽이 들어오고 뒷단에는 이익이 남으므로 자동화는 막힘과 누수를 먼저 찾아야 한다.

AI 프로젝트는 시간 절감 같은 모호한 표현 대신 기준선과 북극성 지표를 구축 전에 합의해야 한다.

주당 리드 5명을 2개월 안에 15명으로 늘린다는 합의는 자동화의 성공 여부와 종료선을 동시에 만든다.

수십만 단어 요약에는 저렴한 모델을, 전략적 의사결정에는 강력한 모델을 쓰는 모델 라우팅이 비용을 10배 이상 줄일 수 있다.

AI 직함을 얻은 사람들은 직함이 생기기 전부터 실험과 업무 도입을 시작했으며 증명이 먼저라는 순서를 보여준다.

반복 업무 하나를 직접 자동화하고 팀과 상사 또는 첫 고객에게 실제 영향을 보여주면 약속보다 결과가 새로운 역할과 기회를 만든다.

결론 및 시사점

1. 결과를 측정하는 습관을 먼저 만든다: 데모를 만들 때마다 전후 시간, 비용, 리드, 전환율 등 사업과 연결되는 수치를 적고 시연 영상을 남긴다.
2. 도구에 종속되지 않는 기반을 만든다: 폴더·마크다운·지시문·API와 문제 해결 원리를 중심에 두고 특정 제품은 교체 가능한 실행 계층으로 취급한다.
3. AI를 관리하는 운영자가 된다: 문제를 맡기고 질문을 유도하며, 여러 관점으로 공격하고, 명확한 완료선과 하위 작업 위임을 설계한다.
4. 검증과 권한을 기본값으로 둔다: 자기 검증 루프, 브라우저·테스트 기반 확인, 최소 권한 API 키, 초안 전용 권한을 도입해 사고가 나기 전에 제한한다.
5. 평가 가능한 시스템을 만든다: 정답을 아는 실제 사례를 골든 데이터 세트로 구축하고, 프롬프트·도구·모델을 바꿀 때마다 같은 평가로 개선 여부를 증명한다.
6. 사업의 제약과 지표에서 시작한다: 이해관계자의 기능 주문을 그대로 구현하기보다 막힘과 누수를 찾고, 기준선과 북극성 지표를 먼저 합의한다.
7. 작업에 맞춰 모델을 배치한다: 단순 반복 작업은 저렴한 모델로, 고도의 판단은 강력한 모델로 라우팅해 품질과 수익성을 함께 지킨다.
8. 직함을 기다리지 않는다: 매주 반복되는 고통스러운 업무 하나를 자동화하고 주변 사람에게 실제 효과를 증명하면, 새로운 AI 역할과 고객 기회가 결과를 중심으로 만들어진다.