EP 91 핵심 주제 심층 분석
AI 프론티어 — 2026년 3월, 비즈니스 관점에서의 AI
원본: EP 91. 26.1Q 비즈니스 관점에서의 AI (2026. 3. 21.)
출연: 노정석, 최승준
본 문서: 에피소드에서 가장 중요한 주제 3개를 선별해 심층 분석
관련글
왜 이 세 가지인가
에피소드 전체를 관통하는 논리는 단순하다. AI는 모든 문제를 최적화 문제로 바꾸고 있고, 그것이 기존 산업 구조를 해체하고 있으며, 기업들은 그 변화에 제대로 대응하지 못하고 있다. 이 세 층위를 각각 가장 깊이 다룬 주제가 아래 세 가지다.
| 주제 | 성격 | 핵심 질문 |
|---|---|---|
| ① 모든 문제는 Search Problem이다 | 철학적 근본 명제 | AI 시대 문제 해결의 본질은 무엇인가 |
| ② Bundle-Unbundle과 Disintermediation | 산업 구조 분석 | 기존 플랫폼과 앱들은 어떻게 무너지는가 |
| ③ 진짜 AX란 무엇인가 | 실전 경험 기반 처방 | 기업이 AI를 도입할 때 왜 실패하고, 어떻게 해야 하는가 |
주제 1. 모든 문제는 Search Problem으로 수렴한다
“오늘 얘기하는 내용 중에서 가장 중요한 슬라이드.” — 노정석
1-1. 명제의 탄생 배경
이 명제는 갑작스럽게 나온 것이 아니다. 딥러닝이 수십 년간 증명해 온 한 가지 사실에서 출발한다.
딥러닝이 실제로 하는 일
딥러닝은 수식으로 보면 복잡해 보이지만, 본질을 벗기면 극도로 단순하다.
1
2
3
4
목표: Loss 함수의 값을 낮춰라 (단 하나의 scalar 숫자)
방법: Gradient Descent (20줄 이내로 구현 가능한 알고리즘)
수단: Computation을 계속 투입한다
결과: 더 optimal한 방향으로 끊임없이 이동한다
Gradient Descent의 본질은 “현재 위치에서 기울기를 구하고, 기울기가 낮아지는 방향으로 조금씩 움직인다”는 것이다. 창의적이거나 영리하지 않다. 무식할 정도로 단순하다. 그런데 여기에 어마어마한 computation을 투입하면 어떤 복잡한 문제든 solution을 찾아낸다.
이것이 딥러닝 혁명의 정체였다.
1-2. 핵심 명제 — 전문 해석
“Compute를 이용해 계산 자원을 투입해서, 모든 문제를 다 Search Problem으로 치환한다.”
이 문장을 구성 요소별로 분해하면:
(1) “모든 문제”
어떤 도메인의 문제라도 그 도메인에는 인간이 아직 가보지 못한 Solution Space가 존재한다. 수학 문제의 가능한 풀이, 신약 후보 물질의 가능한 조합, 법무 의견서의 가능한 논리 전개, 코드의 가능한 구조 — 이 공간은 방대하다. 인간은 그 안에서 경험과 직관으로 일부만 탐색한다.
(2) “Search Problem으로 치환”
AI는 그 거대한 Solution Space를 무작위(semi-random)로 탐색한다. 탐색하면서 각 지점을 평가한다:
- 정답에 가까우면 → “이건 좋은 방향”이라고 마킹
- 정답에서 멀면 → “이건 아닌 방향”이라고 마킹
이 마킹의 집합이 Manifold(다차원 공간 위의 구조)를 형성하고, 모델이 그 Manifold 위에서 점점 정교하게 이동하게 된다.
(3) “Compute를 투입해서”
이 탐색이 가능한 이유는 단 하나 — Computation이 충분히 싸졌기 때문이다. 100만 개의 후보를 평가하는 데 과거에는 수억 원이 들었다면, 지금은 수십만 원 혹은 그 이하로 가능하다. 이 비용 하락이 모든 변화의 물리적 근거다.
1-3. 핵심 조건 — 보상 신호 환경
Search Problem으로 치환하기 위한 유일한 조건은 다음이다:
“보상 신호를 발생할 수 있는 환경이 있느냐 없느냐. 이거밖에 없다.”
더 정확히는:
Non-verifiable을 Verifiable로 전환할 수 있는 환경을 갖고 있느냐 안 갖고 있느냐.
이것이 왜 그토록 중요한지를 이해하려면, RLVR의 역사를 따라가야 한다.
RLVR의 진화 — 수학·코딩에서 전 도메인으로
RLVR(Reinforcement Learning by Verifiable Rewards) 은 검증 가능한 보상 신호로 모델을 강화학습시키는 방법론이다.
초기에 수학과 코딩이 대표 도메인이었던 이유는 명확하다:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
[수학 문제]
문제를 푸는 것: 어렵다
풀어 놓은 것이 맞는지 확인하는 것: 쉽다 (대입하면 됨)
→ Verifiable Reward 발생 가능 ✓
[코딩 문제]
코드를 작성하는 것: 어렵다
코드가 올바르게 실행되는지 확인하는 것: 쉽다 (테스트 실행)
→ Verifiable Reward 발생 가능 ✓
[스도쿠]
푸는 것: 어렵다
정답 확인: 쉽다 (모든 칸 검사)
→ 완벽한 Verifiable Reward ✓
그런데 지금은 의료, 법무, 화학, 생물, 물리 전 도메인으로 확장됐다. 이것이 가능해진 이유는 모델 자체가 평가 기준을 번역해주기 때문이다. 인간이 모호하게 갖고 있는 objective와 evaluation metric을 모델이 명확하게 만들어준다.
1-4. 이 구조가 작동하는 곳들
CUA (Computer Use Agent) — 디지털 세계
GPT-5.4에서 두드러진 능력이다. 컴퓨터 화면을 보며 앱을 조작하고, 원하는 결과가 나오면 “맞았어”, 아니면 “틀렸어”라는 보상을 받으며 학습한다. 인간이 수십 년간 익숙해진 UI/UX를 AI가 그대로 다룰 수 있게 된 것이다.
Periodic Labs — 물리 세계 (Atom World)
이것이 에피소드에서 가장 중요하게 다룬 사례다.
1
2
3
4
5
6
7
8
9
[문제] 특정 재료가 초전도체 성격을 갖는가?
[기존] 디지털에서는 절대 실험 불가
[해결] 로봇이 제어하는 물리 실험실을 구축
↓
실제로 재료를 합성하고 테스트
↓
"이거 돼요 / 안 돼요" → 모델에 피드백
↓
모델이 재료 공학 지식을 축적
이것이 “디지털 World + Atom World를 결합한 해자(Moat)” 의 핵심이다. 디지털로만 만들 수 없는 보상 환경을 가진 기업이 진정한 경쟁 우위를 갖는다.
Auto Research — 연구 자체를 자동화
Andrej Karpathy가 제안한 Auto Research도 완전히 동일한 구조다.
1
2
3
4
5
6
7
8
9
[연구의 기존 방식]
가설 설정 → 실험 설계 → 실험 실행 → 결과 분석 → 논문 작성
(수개월 ~ 수년)
[Auto Research]
목표 설정 (evaluation metric 명시)
→ 에이전트가 가설 설정, 실험, 분석 루프 자동 반복
→ 사람이 최종 결과만 검토
(수일 ~ 수주)
MiniMax도 “이건 에이전트가 트레이닝한 모델이다”라고 명시했다. 사람이 그 루프 안에 들어가지 않는다.
1-5. Ralph Loop — 개인 작업 단위에서의 구현
이 Search Problem 원리는 거대한 AI 연구소에서만 작동하는 것이 아니다. 개인의 작업 단위에서도 완전히 동일하게 작동한다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
[Ralph Loop의 구조]
1단계: 목표 명세 작성
"스펙을 잘 쓰는 데 시간을 많이 투자"
→ 목표가 정해지면 evaluation metric은 자동으로 정해진다
(모델이 옳고 그른 것을 목표에 따라 가릴 수 있으므로)
2단계: 무한 루프 실행
while (evaluation_metric이 충족되지 않음):
작업 실행
결과 검사 ("아무런 문제가 없습니다"가 나올 때까지)
실패하면 → 다시 루프로
3단계: 완료 후 리포팅
현재 모델의 한계는 중간에 모호하게 끝내는 것(“좋습니다”라고 하며 끝냄)이다. 이를 극복하기 위해 “아무런 문제가 없습니다”라는 답이 나올 때까지 강제로 루프를 돌리는 것이 Ralph Loop의 핵심 설계다.
1-6. 진화 알고리즘과의 완전한 동형성
이 에피소드에서 반복적으로 강조되는 것이 “동형성(Isomorphism)” 이다. 지금 일어나는 모든 것이 진화 알고리즘과 같은 구조를 가진다.
1
2
3
4
5
6
7
[진화 알고리즘] [AI의 RLVR/Ralph Loop]
개체 생성 ←→ 후보 솔루션 생성
환경과의 상호작용 ←→ 실제 작업 실행
Fitness 평가 ←→ Evaluation Metric 측정
선택 압력 ←→ Verifiable Reward 신호
다음 세대 ←→ 다음 iteration
적자생존 ←→ Reward Hacking 방지 + 좋은 해 수렴
허예찬님의 “가재 무덤”도 같은 논리다. fitness function을 통과하지 못한 .md 파일들은 다음 세대로 전파되지 못하고 소멸한다.
Blaise Agüera y Arcas의 세션에서 나온 핵심 통찰:
“Mutation 필요 없다. 그냥 있는 풀을 뒤지는 것만으로도 Order는 찾아진다.”
이미 존재하는 Solution Space를 충분히 탐색하는 것만으로 질서와 최적해를 찾을 수 있다는 것이다.
1-7. “그래서 어떻게 해야 하는가”
이 명제에서 도출되는 실천적 결론은 명확하다.
개인 레벨:
- 직접 문제를 푸는 것보다 목표와 evaluation metric을 명확히 하는 데 에너지를 투자하라
- 한번 목표가 명확해지면, 루프를 돌려라. 나머지는 모델이 한다
- 지금 풀리지 않는다면? “덮어둬. 6개월 있다가 그때 모델이 풀 테니까” (Boris Cherny)
기업 레벨:
- 경쟁 우위는 non-verifiable을 verifiable로 바꾸는 환경 구축에서 나온다
- 순수 디지털로만 만들 수 없는 보상 환경(물리 실험실, 실제 사용자 피드백, 독점 데이터)을 가진 기업이 진짜 해자를 갖는다
- 내 독점 데이터를 “보호”하기보다 모델에 빠르게 제공해 더 깊은 탐색을 이끌어내는 전략이 현시점에서 더 유효하다
주제 2. Bundle-Unbundle과 Disintermediation — 기존 산업 구조의 해체
“기존 사업자들은 다른 에이전트들의 Function Call이 될 가능성이 매우 농후하다.” — 노정석
2-1. Bundle-Unbundle이란 무엇인가
a16z의 Benedict Evans가 체계화한 프레임이다. 그는 “AI is eating the world”를 주창하면서, 산업 변화의 가장 믿을 수 있는 패턴으로 이 개념을 사용한다.
Bundle(묶음): 한 사업자가 여러 기능/서비스를 하나로 묶어 사용자에게 강요하는 것
Unbundle(분해): 새로운 기술/플랫폼 등장으로 묶음이 풀리고 각 요소가 분리되는 것
2-2. 역사적 사이클 추적
레이어 1 — 방송·신문 시대의 Bundle
TV와 신문은 완벽한 Bundle이었다:
1
2
3
4
5
6
7
8
[TV의 Bundle]
드라마 + 뉴스 + 오락 + 광고
→ 모두 하나의 편성표에 묶여 강요됨
→ 시청자는 원하든 원하지 않든 그 묶음을 소비
[신문의 Bundle]
정치 + 경제 + 스포츠 + 문화 + 날씨 + 광고
→ 하나의 지면에 묶여 강요됨
이 Bundle이 매체력의 원천이었고, 광고 수익의 원천이었다.
레이어 2 — 인터넷의 Unbundle
인터넷이 등장하면서 이 Bundle이 폭발적으로 분해됐다:
1
2
3
4
뉴스 → 개별 뉴스 사이트, 포털
드라마 → 동영상 스트리밍
스포츠 → 스포츠 전문 사이트
광고 → 검색 광고, 배너 광고 (분리됨)
레이어 3 — 인터넷 내 지배자들의 Re-bundle
인터넷 Unbundle이 어느 정도 정착되자, 지배자들이 다시 Bundle을 강요하기 시작했다:
1
2
3
4
5
6
7
8
네이버: 검색 + 뉴스 + 쇼핑 + 카페 + 블로그 + 지도
→ Walled Garden으로 묶음. 콘텐츠가 빠져나가지 못하게 차단
구글: 검색 + 이메일 + 지도 + 유튜브 + 클라우드
→ 생태계 전체를 하나로
카카오: 메신저 + 뉴스 + 쇼핑 + 택시 + 결제
→ 커뮤니케이션을 점령한 후 모든 것으로 확장
레이어 4 — 모바일의 Unbundle
모바일이 등장하면서 포털의 Bundle이 다시 분해됐다. 앱 단위로 기능이 분화됐다.
1
2
3
4
배달: 배민, 요기요
쇼핑: 쿠팡, 네이버 쇼핑
택시: 카카오택시, 타다
숙박: 에어비앤비, 야놀자
레이어 5 — AI의 Unbundle (현재 진행형)
지금이 바로 이 단계다. 에피소드에서 핵심적으로 다루는 부분이다.
2-3. AI가 Unbundle하는 방식 — OMO.BOT 분석
OpenClaw Seoul 밋업에서 Simon이 공개한 OMO.BOT은 이 Unbundle이 실제로 어떻게 일어나는지를 가장 선명하게 보여준 사례다.
기존 사용자 경험 (Friction의 집합)
1
2
3
4
5
6
사용자의 하루 (현재):
배달 주문 → 배민 앱 실행 → 로그인 → 검색 → 광고 노출 → 선택 → 결제
생수 주문 → 쿠팡 앱 실행 → 로그인 → 검색 → 광고 노출 → 선택 → 결제
택시 호출 → 카카오택시 앱 → 위치 입력 → 기다림
[각 앱마다: 광고 인벤토리 + Cross-sell + Upsell + 회원가입 유도]
OMO.BOT 이후 사용자 경험
1
2
3
4
5
6
사용자의 하루 (OMO.BOT 이후):
"치킨 시켜줘" → 에이전트가 배민에서 자동 주문
"생수 두 박스" → 에이전트가 쿠팡에서 자동 주문
"택시 불러줘" → 에이전트가 카카오택시 자동 호출
[광고 없음 / Cross-sell 없음 / UX Friction 없음]
기술적 구현 방식
1
2
3
API가 있는 서비스 → API 직접 연결
API가 없는 서비스 → CUA(Computer Use Agent)로 에뮬레이션
→ 에이전트가 사람처럼 앱 화면을 보고 조작
2-4. 왜 기존 사업자가 막을 수 없는가
기존 플랫폼들이 시도해온 방어 전략들:
| 방어 전략 | 기존 효과 | 에이전트 시대에서의 효과 |
|---|---|---|
| 크롤러 차단 (IP 차단) | 유효했음 | 무력화 — 에이전트는 각자 다른 IP |
| 로그인 의무화 | 어느 정도 유효 | 무력화 — 사용자가 자신의 계정으로 로그인한 에뮬레이터를 에이전트가 사용 |
| 봇 탐지 (CAPTCHA 등) | 어느 정도 유효 | 점점 무력화 — CUA가 인간처럼 움직임 |
| Walled Garden | 유효했음 | 무력화 — 에이전트가 안에서 직접 조작 |
| 2FA | 유효했음 | 위험 — 에이전트가 이메일도 접근 가능 |
근본적인 이유:
“사람이 오는 것과 트래픽이 구별이 안 될 테니까. 내 에뮬레이터에 내가 로그인해 놓고, 그 에뮬레이터를 내 에이전트가 조작하면 어떻게 막죠? IP도 전부 다르고, 모든 게 전부 다 다를 텐데.” — 노정석
2-5. 기존 플랫폼들의 운명 — 내쉬 균형 분석
내쉬 균형(Nash Equilibrium): 모든 참여자가 주어진 상황에서 최선의 전략을 선택했을 때 도달하는 안정 상태.
현재 진행되는 게임의 참여자들:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
[Tier 1 — 에이전트 레이어 기업들]
OpenClaw, OMO.BOT 류
→ 사용자 최상단 접점을 차지하려는 플레이어
→ 목표: "모든 것을 대신해주는 개인 비서"
[Tier 2 — 기존 플랫폼들]
네이버, 카카오, 배민, 쿠팡
→ Function Call로 전락할 위기
→ 선택지: 에이전트와 협력(API 개방) vs. 저항(차단)
[Tier 3 — 빅테크]
Apple, Google, Xiaomi, Samsung
→ 각자 OS 레벨에서 에이전트를 내장하려 함
→ "MiMo Claw", "Apple Intelligence"
내쉬 균형 예측:
저항은 불가능하다. 사용자는 더 편한 쪽으로 간다. 기존 플랫폼이 저항할수록 사용자는 이탈한다. 결국 기존 플랫폼들은 API를 개방하거나, 에이전트 레이어를 직접 만들거나, 아니면 function call의 대상으로 전락하는 세 가지 경로 중 하나를 택하게 된다.
Jensen Huang의 표현이 이것을 정확히 포착했다:
“Are you OpenClaw ready?”
2-6. IT 비즈니스의 본질 — 매체력 = 마진
노정석이 반복적으로 강조하는 명제:
“IT 비즈니스는 그냥 미디어 비즈니스랑 똑같다. 매체력이 곧 마진인 그런 세상.”
지금까지 각 플랫폼이 쌓아온 매체력의 원천:
| 플랫폼 | 점령한 것 | 매체력의 원천 |
|---|---|---|
| 네이버 | 검색 | 정보 접근의 Gate Keeper |
| 카카오 | 커뮤니케이션 | 사람 사이 연결의 Gate Keeper |
| 배민 | 음식 배달 | 외식 소비의 Gate Keeper |
| 쿠팡 | 로켓 배송 | 생필품 소비의 Gate Keeper |
이 매체력이 만들어내는 수익 구간은 사용자 입장에서 모두 Friction(마찰) 이다. 광고, 강요된 UX Flow, Cross-sell, Upsell — 이 모든 것이 플랫폼의 마진이자 사용자의 불편이다.
에이전트는 이 Friction을 전부 제거하면서 사용자 편의를 극대화한다. 사용자가 기꺼이 이동하는 이유가 바로 여기에 있다.
2-7. “그래서 어떻게 해야 하는가”
기존 플랫폼 사업자라면:
막으려 하지 말 것. 막을 수 없다. 대신:
- API를 먼저 개방하고 에이전트 레이어와 협력한다
- 자체 에이전트 레이어를 직접 구축해서 최상단 접점을 차지하려 한다
- 에이전트가 function call로 호출했을 때 가장 좋은 결과를 주는 서비스로 포지셔닝한다 (에이전트가 선택할 이유를 만든다)
스타트업·신규 사업자라면:
지금이 기회다. 기존 플랫폼들이 이미 쌓아 올린 실물 인프라(배달망, 로켓 배송 등)는 에이전트로 대체되지 않는다. 에이전트가 대체하는 것은 UI/UX 레이어다. 좋은 실물 인프라 위에 에이전트 접점을 만드는 사업자가 다음 세대의 게이트키퍼가 될 수 있다.
“해결 완료를 팔아야 한다. 수단을 제공하는 게 아니라.” — 노정석
주제 3. 진짜 AX(AI Transformation)란 무엇인가
“저 팀을 통째로 없애세요가 성공하는 AX의 출발점입니다.”
“돌고 돌아 바닐라가 답이었다.” — 노정석 (4년간의 직접 경험)
3-1. 이 주제가 중요한 이유
노정석은 2021년부터 2026년까지 4년 이상 직접 AI 사업을 해온 사람이다. 딥러닝 모델 직접 제작, Diffusion 모델, LoRA, Small Language Model, 각종 에이전트 SDK — 안 해본 것이 없다. 이 경험에서 나온 결론이기 때문에 가치가 있다.
3-2. 1/10x 효율 vs 10x 신사업 — 두 방향의 근본적 차이
이 에피소드에서 제시된 가장 중요한 프레임이다.
1/10x 효율 (Efficiency)
1
2
3
4
5
정의: 기존에 100이 들던 것을 10으로 만들어 90의 이익 창출
특성: Objective 명확 / Evaluation Metric 명확 / 측정 가능
방법: Better, Faster, Cheaper
예시: 기존 보고서 작성 시간 단축, 고객 응대 자동화, 코드 생성 등
현황: 현재 대부분의 AX가 여기에 해당
10x 신사업 (Innovation)
1
2
3
4
5
정의: 새로운 영역에서 이전에 없던 10배의 가치 창출
특성: Objective 모호 / Evaluation Metric 존재하지 않음
방법: Zero to One
예시: 완전히 새로운 비즈니스 모델, 새로운 시장 창출
현황: 아직 본격 시작되지 않음 — 곧 시작될 것
왜 효율화로 혁신에 점프할 수 없는가
“아무리 효율을 높인다고 하더라도 후자(10x 신사업)로는 점프할 수 없다.”
이유는 명확하다. 1/10x 효율은 기존 목표를 더 잘 달성하는 것이다. 10x 신사업은 완전히 새로운 목표를 설정하는 것이다. 후자는 전자의 연장이 아니라 차원이 다른 문제다.
1
2
3
4
5
6
7
8
9
10
11
[차원의 차이]
1/10x 효율:
기존 로펌 → AI로 서류 검토 속도 10배 향상
→ 목표: "더 빠르게 기존 일을 잘 하자"
→ Evaluation Metric: 처리 시간, 오류율 등 측정 가능
10x 신사업:
10x Lawyer: 시니어 변호사 1명 + 에이전트 = 기존 팀 대체
→ 목표: "서비스 자체를 재정의하자"
→ Evaluation Metric: 처음에는 존재하지 않음 — 만들어 가야 함
3-3. 왜 대부분의 AX가 실패하는가 — 인센티브 구조 분석
노정석이 “여러 케이스에서 느꼈다”고 한 핵심 관찰이다.
잘못된 AX 구조의 전형
1
2
3
4
5
6
7
8
9
[일반적인 AX 진행 방식]
Step 1: AX 팀 구성
Step 2: 각 팀 돌아다니며 요건 수집
- "어떤 업무에 AI를 적용하고 싶으세요?"
Step 3: 요건에 맞는 AI 도구 제작/도입
Step 4: 해당 팀에 제공
[결과]: 대부분 안 씀
왜 안 쓰는가 — 인센티브의 역설
지식 노동자의 심리를 정직하게 분석하면:
1
2
3
4
5
6
7
[마케터 A의 내면]
"나는 여기까지 오려고 얼마나 힘겹게 노가다를 하며
Excel 단축키를 익히고, PowerPoint 마스터가 됐는데...
AI가 내 업무를 대신한다고?
→ 내가 쌓아온 전문성이 의미 없어진다
→ 더 생산적인 업무로 이동? 그게 뭔지도 모르고 하기도 싫다
→ 그냥 이거 하면서 편하게 돈 받고 싶다"
AI가 어떤 업무 하나를 없애도, 그 사람은 더 생산적인 업무로 이동하지 않는다. 노는 시간이 더 늘어날 뿐이다. 기업 입장에서는 marginal한 생산성 증가가 없다.
구조적 이유 — 요건을 “주는” 입장의 이해관계
요건을 수집할 때 각 팀이 원하는 것:
1
2
3
4
5
영업팀: "보고서 작성 좀 편하게 해주세요"
→ 실제로 원하는 것: 지금 하는 방식을 유지하되 조금 편해지면 좋겠다
마케팅팀: "캠페인 기획서 초안 좀 써줘요"
→ 실제로 원하는 것: 지금 내 직무를 AI가 보조해주면 좋겠다
아무도 “우리 팀 업무를 통째로 없애주세요”라고 요청하지 않는다.
3-4. 진짜 AX의 출발점
“저 팀을 통째로 없애세요가 성공하는 AX의 출발점입니다.”
이 문장이 얼핏 가혹하게 들리지만, 노정석은 즉시 맥락을 보완한다:
“그 사람들을 잘라버리자는 얘기가 아니에요. 그 사람들이 갖고 있었던 단위 업무나 이런 것들을 온전히 없애주고, 그들을 새로운 직무로 전환시켜야지…”
잘못된 접근 vs. 올바른 접근
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[잘못된 접근]
기존 팀의 업무 방식 유지
↓
AI 도구를 "추가"로 제공
↓
PowerPoint를 AI로 쓰는 사람으로 변환
↓
한계: marginal한 생산성 증가만 있음
[올바른 접근]
기존 팀의 단위 업무를 완전히 제거
↓
해당 인원을 새로운 직무로 전환
↓
새로운 직무에서 AI와 협업하는 방식으로 재교육
↓
기대값: 비약적인 생산성 증가 + 새로운 가치 창출
3-5. 10x Lawyer — 조직 구조 해체의 패턴
로펌을 예시로 한 분석은 모든 지식 노동 기반 조직에 적용된다.
기존 로펌 구조
1
2
3
4
5
6
7
파트너 변호사 (최상단 — 핵심 의사결정)
↓
시니어 어소시에이트 (중간 — 복잡한 리서치·분석)
↓
주니어 어소시에이트 (하단 — 단순 조사·서류 작성)
[비즈니스 모델]: 팀 단위 Time Charge (모든 레이어 청구)
AI 이후의 변화
1
2
3
4
5
6
7
8
9
파트너/시니어급 변호사 1명
+
에이전트 (리서치, 초안 작성, 선례 검색 등 자동화)
=
기존 팀 전체의 업무량을 커버 가능
↓
클라이언트: "훨씬 싸고 빠른데 왜 기존 방식을 써야 하지?"
↓
시장 이탈 → 기존 구조 붕괴 가속
“그 축이 한 번 돌기 시작하면 걷잡을 수 없이 바뀔 것이다.”
이것이 10x Engineer, 10x Doctor, 10x Something 전부에 해당하는 패턴이다.
3-6. 돌고 돌아 바닐라가 답 — 4년의 실험 결론
시도했던 모든 방법들
| 시기 | 시도한 기술 | 결과 |
|---|---|---|
| 2021 | 딥러닝 모델 직접 제작 | 안 됨 |
| 2022 | Diffusion 모델 | 안 됨 |
| 2022 | LoRA 적용 | 안 됨 |
| 2023 | Small Language Model | 안 됨 |
| 2023~2024 | 에이전트 SDK, LangChain, Pydantic | 부분적 작동 |
| 2024~2025 | 자체 하네스 구축 | 복잡도 증가 |
| 2025~ | 바닐라 (데이터 커넥터 + 프롬프트 + 프론티어 모델) | 됨 |
2025년이 전환점이다. 모델이 임계점을 넘으면서 안 되던 것들이 다 되기 시작했다. 동시에, 자체 하네스를 복잡하게 구축할 필요가 없어졌다.
바닐라 방법론의 세 요소
“안 만드는 게 베스트다. 데이터 커넥터 깔끔하게 만들고, 프롬프트 잘 쓰고, 프론티어 모델과 Claude Code·Codex를 붙이는 게 성능이 제일 좋다.”
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
[바닐라 방법론]
① 데이터 커넥터
- 회사의 데이터가 AI에게 깔끔하게 전달되도록
- 스키마 정리, 연결 체계 구축에 집중
- 기술적 복잡도가 아닌 "데이터가 무엇인지"에 집중
② 프롬프트 잘 쓰기
- 엔지니어링 파워가 아니라 도메인 이해가 핵심
- 도메인이 어떻게 생겼는지를 이해하는 것
- 회사에 있는 데이터들을 실제로 이해하려는 노력
③ 프론티어 모델 직접 연결
- Claude Code, Codex 등 최강 모델을 그냥 쓴다
- 중간 레이어(프레임워크, 커스텀 하네스)를 최소화
- "궁극의 하네스는 이미 있다 — 프론티어 모델 자체가"
이 결론에 도달한 과정
팀 내에서 각자 다른 방법론을 실험했다:
- A 엔지니어: Pydantic 활용
- B 엔지니어: LangChain 활용
- C 엔지니어: 자체 하네스 구축
- D 엔지니어: “그냥 프론티어 모델 쓰면 되는 거 아냐?”
D 엔지니어의 논리:
“어차피 우리 하네스 만드는 건데, 가장 궁극의 하네스와 궁극의 모델을 쓰면 되는 거 아니냐. 그 일을 할 필요가 없다.”
최종 성과를 비교했을 때 D 엔지니어의 방법론이 가장 좋았고, 회사 전체가 이 방향으로 전환했다.
3-7. 프롬프트가 전부다 — 가장 저평가된 스킬
노정석이 특별히 강조하는 인사이트:
“프롬프트를 잘 쓰려면 사실 엔지니어링 파워가 중요한 게 아니라, 그 도메인에 대한 이해가 중요하다.”
이것이 중요한 이유:
1
2
3
4
5
6
7
8
9
10
11
12
13
[일반적인 오해]
AI 도입 = 기술 팀의 영역
↓
기술적으로 복잡한 시스템 구축
[현실]
AI 도입 = 도메인 전문가의 영역
↓
그 업무가 실제로 어떻게 작동하는지 아는 사람이
↓
그 지식을 프롬프트로 명확하게 표현하면
↓
일이 끝난다
즉, 도메인 전문성 + 프롬프트 작성 능력이 기술적 복잡도보다 더 중요한 시대가 됐다.
3-8. 주의사항 — 바닐라가 답이라는 결론의 맥락
이 결론은 특정 맥락 안에서 유효하다:
1
2
3
4
5
6
7
8
9
10
[적용 범위]
- 1/10x 효율 추구 (기존 업무 최적화)
- Objective와 Evaluation Metric이 상대적으로 명확한 영역
- 4년간의 직접 경험에서 나온 "2026년 3월 스냅샷"
[적용 외 범위]
- 10x 신사업 (Zero to One 혁신)
→ 여기서는 바닐라만으로는 부족
→ Entrepreneur의 직관과 의지가 필요
→ Objective와 Evaluation Metric 자체를 만들어가야 함
3-9. AX를 이끌기 위한 리더십 조건
노정석이 마지막으로 강조하는 것:
“AX를 하려면 오너가 됐건 혹은 최상단 리더십이 되었건 AX에 대해서 그 본질을 정확하게 이해해야 한다.”
그리고 10x 신사업을 위해서는:
“그 단위의 리더가 온전히 학습을 하든지 아니면 무언가 깨달음을 얻든지 해서 다음 레벨로 올라서야 한다.”
허예찬님의 말이 결론을 대신한다:
“그냥 진짜 돈 걸린 문제에서 목숨 걸고 전투하다 보면 이렇게 되는 거 아닐까요.”
세 주제의 연결 — 하나의 논리로
이 세 가지 주제는 사실 하나의 논리 구조 위에 있다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
[근본 명제 — 주제 1]
모든 문제는 Search Problem이다.
Compute + Verifiable Reward = 어떤 문제든 해결 가능.
↓
[산업 구조적 귀결 — 주제 2]
이 원리가 에이전트 레이어를 만들고,
에이전트가 기존 플랫폼의 UX Friction을 모두 우회한다.
Bundle-Unbundle 사이클이 다시 한 번 일어난다.
↓
[실천적 결론 — 주제 3]
그 변화 안에서 기업과 개인이 살아남으려면,
- 업무를 통째로 재정의하고 (바닐라 + 도메인 이해)
- 혁신은 Entrepreneur 기질로 직접 부딪히고
- 이 모든 것을 지금 당장 시작해야 한다.
“이 루프를 잘 이해하고 본인의 비즈니스를 이러한 라운드 위에 올리는 자는 이 benefit을 얻을 것이고, 이거를 이해하지 못하는 사람은 이걸 이용하는 사람에 의해서 대체될 것이다.” — 노정석
작성일: 2026년 3월 22일
기반 자료: AI 프론티어 EP 91 — 26년 1Q 비즈니스 관점에서의 AI
원본 영상: https://www.youtube.com/watch?v=FPYOVt2B5EM