HOW I AI — SaaS를 인수해 사람 없이 AI로 운영하기: AI Native Company OS 3단계

출처 https://youtu.be/jajEm8R9nD0 · 채널 빌더 조쉬 Builder Josh (HOW I AI PODCAST) · 길이 46:00 · 공개 2026-07-27 포맷 진행자 조쉬와 게스트 김지혁(뉴스레터 “진양의 인수창업” 운영, 누적 7개 사업체 인수)의 2인 대담. 중반부터 게스트가 자신의 Notion 문서 AI Native Company OS 구축 계획과 Slack 워크스페이스를 화면 공유하며 설명한다. 이 노트의 표·조직도·수치는 모두 그 공유 화면에서 옮긴 것이다. 원본 자막(자동 생성): raw source: 2026-07-27-howiai-saas-acquisition-ai-native-ops (raw/transcripts)

표기 주의 자동 자막이 고유명사를 심하게 깨뜨려서(쿼리어블→커리어블, Closed-loop→크로즈룹, Hermes→하르매스 등) 이 노트의 명칭은 화면에 렌더링된 문자열 기준으로 정정했다. 에이전트 이름(제라드 던·길포일 버트램·얼릭 바크만)도 Slack과 조직도 화면에서 읽은 것이다.

한눈에 보는 요약

인수의 대상은 코드가 아니라 현금 흐름이다. 게스트는 “코드베이스는 현금 흐름을 위한 수단이지 목적이 되면 안 된다”고 못박는다. 그래서 인수 직후 과제는 기능 개선이 아니라 계기판(지표) 이관이다.
AI 때문에 SaaS가 인수 후보로 편입됐다. 예전엔 SaaS 멀티플이 너무 비싸 손대지 않았지만, 개발·디자인·마케팅 역량이 커모디티화되면서 “10명이 운영하던 SaaS를 1~2명이 운영할 수 있다”는 전제가 생겼다. 상방은 넓어지고 하방은 안전해졌다는 계산이다.
가장 어려운 인수 자산은 히스토리다. 매출을 유지하려면 “왜 이 기능이 이렇게 됐는지”, “무엇을 실험했다 접었는지”를 알아야 하는데, 그 양이 인수인계로 옮기기엔 너무 방대하다. 그래서 Slack과 Notion을 통째로 받아 임베딩해 “나보다 회사 맥락을 잘 아는 AI”를 만드는 것이 1번 과제였다.
첫 에이전트는 계획이 아니라 실사 도구에서 시작됐다. 양도자에게 물어볼 질문이 너무 많아 만든 Q&A 봇을, 양도자와 함께 있는 Slack 채널에 초대한 것이 출발점이다. 그것이 지금의 PM 에이전트 제라드 던이 됐다.
에이전트는 늘리는 게 아니라 쪼개는 것이다. 하나에게 전부 주자 “컨텍스트가 넓어질수록 판단이 마음에 안 들어졌다”. 같은 모델인데 멍청해진 느낌 — 그래서 역할별로 컨텍스트를 잘라내 3계층 조직도로 재편했다.
현재 조직은 PM 1 + 실행 오케스트레이터 2 + 워커 6. Slack 프로필 기준 총 9개이고, 사람이 직접 대화하는 것은 오케스트레이터 3개뿐이다.
리뷰어를 일부러 두 명 둔다. Codex가 코드를 쓰고, Claude가 “진보적”(개선 여지까지 지적) 리뷰를, OpenRouter의 무료 모델이 “보수적”(동작 여부 중심) 리뷰를 한다. 게스트 본인도 “이게 좋은 구성인지는 모른다, 하다 보니 이렇게 됐다”고 솔직히 말한다.
AI Native의 정의는 에이전트 수가 아니다. 문서에 적힌 3조건은 Queryable · Closed-loop · Self-improving이며, “기록이 안 되면 일회성 외주, 물어볼 수 없으면 데이터 창고, 결과가 다음 행동에 안 붙으면 보고서 자동화”라는 실패 유형이 각각 대응한다.
자동화의 마지막 한 칸은 의도적으로 사람이 쥐고 있다. 판단 품질 라벨링(Slack 이모지 accepted/rejected)과 PR 최종 검토는 게스트가 직접 한다. “지금 병목은 어차피 나라서 자동화해도 의미가 없다”는 이유다.
본인 평가는 30%. Queryable은 꽤 진행됐고, PM QA 루프와 eval 데이터셋은 미구현이다. 다음 목표는 SaaS 2개 추가 인수 — 단, “10명이 하던 걸 1~2명이 할 수 있는지” 검증이 먼저다.

핵심 한 줄: 에이전트를 몇 명 고용했느냐가 아니라, 행동의 결과가 기록되어 다음 행동으로 되돌아오는 루프가 도는가가 AI 네이티브 회사의 기준이다.

1부 — 왜 SaaS를 인수했나

[08:45] 인수하는 것은 코드가 아니라 현금 흐름이다

인포그래픽 — 현금 흐름 인수 아래 매출 유지·순이익 유지

게스트는 인수 창업의 펀더멘털을 “현금 흐름 인수”로 정의한다. 유지해야 할 것은 매출과 순이익이고, 코드베이스·고객 DB·PG 계약·거래처 정보는 전부 그 현금 흐름을 지탱하기 위해 따라오는 부속물이다. “앞뒤가 바뀌어서 생각하는 사람이 많은데 코드베이스는 수단이지 목적이 아니다.”

인수 창업의 마인드셋은 리스크 관리를 넘어 “이 돈을 넣었을 때 회수 가능한가” 로 요약된다. 그가 오랫동안 SaaS를 후보에서 뺐던 이유도 여기 있다 — 멀티플이 3년치는 기본, 비싸면 7~8년치까지 부르니 회수 시나리오가 안 나왔다. 상황을 바꾼 것은 AI다. 개발·디자인·마케팅 역량이 커모디티가 되면서 “지식의 값이 0에 수렴한다”고 믿는 매도자가 늘었고, 10인이 운영하던 SaaS의 인건비 구조가 무너질 수 있다는 전제가 생겼다. 상방은 넓어지고 하방은 안전해졌다는 계산으로 SaaS가 후보군에 들어왔다.

인수 직후 실행에 대해서는 반대로 아주 보수적이다. “이때 파괴적인 의사결정을 하면 나중에 후회한다.” 기존 창업자가 안 하고 있는 것에는 안 하는 이유가 있다고 깔고 들어가야 하며, 명백해 보이는 매출 레버조차 첫 6개월~1년 안에는 당기지 않는다.

[09:45] 진짜 어려운 인수 자산은 기록되지 않은 히스토리다

인포그래픽 — 기록되지 않은 실패는 반복된다: 담당자 세 명이 같은 구덩이에 빠지는 그림

SaaS가 커머스보다 인수하기 어려운 이유는 매출을 유지하는 데 필요한 정보량이 비대하기 때문이다. 제품이 지금 형태가 된 히스토리, 신규 기능에서 고려해야 할 제약, “실험해봤는데 안 좋아서 접은 방향” 같은 누적 노하우를 흡수하지 못하면 새 담당자가 같은 실수를 그대로 반복한다.

이걸 문서 인수인계로 옮기기엔 양이 너무 많다. 그래서 그가 택한 방법은 양도자의 Slack과 Notion을 통째로 받아 임베딩하는 것이었다. 처음엔 “이건 안 받아도 되겠다” 싶었지만, 하다 보니 그것 없이는 히스토리 파악이 불가능하다고 판단했다고 한다. 여기서 그가 강조하는 인수의 전제 조건이 나온다 — “인수는 무조건 우호적인 양도자를 만나는 게 제일 중요하다. 어쩔 수 없다.” 팀의 비정형 대화 로그까지 넘겨주는 것은 상대의 선의 없이는 성립하지 않는다.

인수 직후 그가 가장 먼저 만드는 것은 계기판이다. “속도계 없이 운전하면 차는 무조건 사고가 난다.” 기존 창업자가 보던 지표를 그대로 다운로드받되, 목표가 다르므로 지표도 갈아끼운다 — 창업자의 계기판은 성장을 위해 만들어져 있지만, 인수자의 최우선 과제는 현금 흐름 회수다. 이번 건에서는 양도자가 이미 Metabase로 의사결정용 대시보드를 갖춰둔 덕에 그것을 받아 변형했다.

2부 — 에이전트 조직이 만들어진 과정

[18:12] 실사용 Q&A 봇이 PM 에이전트가 되기까지

Notion 개발 요청 티켓 — 코드 리스크·수정안 v1·검증 절차·수동 재현 방법이 적힌 문서

“이걸 하려고 SaaS를 인수한 게 아니라, 인수하고 나서 질문이 너무 많아서 그 질문을 풀어주는 애를 하나 만들자로 시작했다.” Slack 로그와 Notion MCP를 물린 Q&A 봇을 만들어 양도자와 함께 있는 채널에 초대한 것이 첫 에이전트다.

인수자의 가장 큰 공포는 “버그가 났는데 못 고치면 어쩌지”다. 처음엔 에러가 날 때마다 기존 창업자에게 물어봤지만 소모적이었다. 그래서 판단을 뒤집었다 — 코드베이스를 이해하고 라이브 DB 조회 권한까지 가진 에이전트라면 원래 창업자보다 이 버그를 더 잘 설명할 수 있다. 그 길로 봇을 에러 로그 채널에 초대했다.

화면의 티켓이 그 결과물이다. AI PM은 이슈를 분석해 Notion “개발 요청 관리” 문서함에 다음을 채워 넣는다.

현재 코드 리스크 — channel_not_found를 사용자에게 친절히 안내하지 못하고 운영 에러로 올라온다. notice를 Slack 발송 전에 저장하므로 발송 실패 시 고아 notice가 남는다.
수정안 v1 — ① getUserToken 먼저 확인 ② DB 저장 전 bot token으로 conversations.members/info 검증 ③ 접근 불가 시 ack({ response_action: 'errors' })로 “앱을 채널에 초대하거나 접근 가능한 채널을 선택해 주세요” 안내 ④ Slack post 실패 시 notice rollback 또는 failed 처리 ⑤ 실제 장애만 에러 채널로, 사용자 권한 문제는 validation으로 분리
검증 — private 채널에 앱 미초대 상태로 재현 → 모달 inline error 노출 확인, 초대 후 발송 → 전송/수신자 저장/analytics 기록 성공, 실패 케이스에서 orphan row 미발생 확인
수동 재현 방법 / dev 환경, PR 머지 후 QA 절차까지 포함

진행자는 이를 “QA에서 쓰는 테스트 케이스 같은 것”이라 정리하고, 게스트는 “기획자로서 원인·재현·수정 방법을 쓰는 게 핵심” 이라고 답한다. 이 문서는 사람이 읽으려고 쓰는 게 아니라 다음 단계의 개발 에이전트가 읽으려고 쓰는 것이다.

[21:45] 컨텍스트를 나눠야 판단이 좋아진다

Slack agents-pm 스레드 — 길포일 버트램이 Codex 컨텍스트 상한과 auto-compaction 설정 변경을 보고

처음에는 PM 에이전트 하나에게 전부 줬다. 코드베이스도 있으니 커밋과 PR까지 맡기면 되겠다는 생각이었다. 결과는 반대였다 — “얘가 아는 양이 방대해질수록 의사결정이 마음에 안 들어지더라. 모델은 같은 걸 쓰는데 멍청해진 것 같았다.” 그래서 역할을 명확히 분리하고 가지고 있지 않아도 되는 컨텍스트를 덜어내는 방향으로 재편했고, 그때 만든 개발자 페르소나가 길포일 버트램이다.

에이전트 이름은 HBO 드라마 〈실리콘밸리〉 캐릭터에서 따왔다. 화면의 Slack 메시지는 그 개발자 에이전트가 운영자에게 남긴 보고다 — Codex gpt-5.5의 컨텍스트 상한이 272K이므로 요약 전 윈도우를 더 쓰도록 auto-compaction 임계를 70%에서 85%로 올렸고, 되돌리려면 hermes config set compression.codex_gpt55_autoraise false를 실행하라는 안내까지 붙어 있다.

[24:00] AI PM → 사람 이해 → AI 개발자로 넘어가는 5단계

인포그래픽 — AI가 끝까지 합니다: 스펙 전달 → 이해 및 흡수 → 노션 문서 정리 → 개발자에게 전달 → 개발 수행

실제 개발 흐름은 다섯 단계다. ① AI PM이 개발 스펙을 전달하고 ② 사람이 그것을 이해·흡수한 뒤 ③ Notion 문서 형태로 정제해 ④ AI 개발자에게 넘기면 ⑤ AI 개발자가 코드를 작성한다. 게스트가 PM에게 요청하는 방식은 이렇다 — “본 앱이니 조심스럽게 작업해야 한다. 이 문서 보고 필요한 게 있으면 나한테 물어보고, 없으면 그냥 PR을 한번 넣어봐라.”

PR 최종 검토는 사람이 한다. 이유는 단순하다. “저는 바이브 코딩을 아직 못 믿어서, 라이브에 들어가는 코드를 100% 믿을 수는 없다.” 보안 이슈나 이상한 부분을 본인이 직접 본다. 다만 실제로는 “리뷰만 하지, 개선하라고 요청한 적은 한 번도 없다”고 한다.

[24:30] 조직도 — L1 PM, L1-A/B 실행 부서, L2 워커, L3 지식 계층

Notion 조직도 — L1 제라드 던 아래 개발/콘텐츠 실행 오케스트레이터와 각 3개 워커, 최하단 L3 지식 계층

화면의 조직도를 그대로 옮기면 다음과 같다.

L1. PM / OS OWNER — 제라드 던
    - PM / PO / 데이터 분석
    - founder intent parsing
    - execution handoff
    - execution QA
    - outcome learning
        │
        ├── L1-A. DEVELOPMENT EXECUTION       ├── L1-B. CONTENT EXECUTION
        │   general_orchestrator              │   contentorchestrator
        │   - 개발 실행 오케스트레이션        │   - 콘텐츠 실행 오케스트레이션
        │   - coding CLI wrapper 관리         │   - 콘텐츠 role wrapper 관리
        │   - PR / test / review loop         │   - draft / review / render
        │        │                            │        │
        │   L2. WORKER / CLI WRAPPERS         │   L2. CONTENT WORKERS
        │   codexbuilder                      │   contentresearcher
        │   claudereviewer                    │   contentwriter
        │   openrouterreviewer                │   contentreviewer
        │                                     │
        └─────────────┬───────────────────────┘
                      ▼
L3. INTELLIGENCE / MEMORY / SOURCE OF TRUTH
    Postgres / Langfuse / Honcho / Notion / Linear / Slack
    Metabase / semantic search / App 1 / App 2 / App 3 / ...

개발 라인의 워커 구성이 이 대담에서 가장 논쟁적인 부분이다. 빌드는 Codex, 리뷰는 두 명 — 하나는 Claude, 하나는 OpenRouter의 무료 모델(NVIDIA 모델)이다. 역할 배분이 직관과 반대다.

OpenRouter 무료 모델 = 보수적 리뷰 = 게이트키핑 — 기능이 정상 동작하는지 중심
Claude = 진보적 리뷰 — 기능 개선의 여지까지 지적

진행자가 “왜 더 약한 모델에게 게이트키핑을 맡기냐”고 되묻자 게스트는 방어하지 않는다. “이게 좋은지 모릅니다. 그냥 하다 보니 이렇게 됐어요.” 다행히 보안상 크게 이슈 될 게 없는 서비스라 유지 중이며, 두 리뷰의 세션을 하나씩 열어본 적이 없어 둘의 관계도 아직 정확히 모른다고 덧붙인다. 화면 문서에 claudereviewer: Exploratory / Divergent / Opportunity Reviewer로 성격이 명시돼 있는 것이 이 배분의 근거다.

콘텐츠 라인은 나중에 붙었다. Instagram 계정 운영 방향을 PM과 토론하다 “SNS 계정을 운영하고 탑 콘텐츠를 만들어라”라는 제안이 나왔고, 그 제안을 실행할 조직을 그대로 만든 것이 얼릭 바크만 라인이다(리서치 → 라이팅 → 리뷰의 동일한 3워커 구도).

[26:00] 프로필 9개, 사람이 대화하는 것은 3개

Slack — 얼릭 바크만이 김지혁(Jimmy)에 의해 agents-pm에 추가되고, 제라드 던이 daily-standup-close 크론 결과를 보고

“3, 3, 3 해서 총 9개의 프로필을 쓰는데 실제로 저랑 대화하는 건 3개만 씁니다.” 사람은 오케스트레이터하고만 말하고, 워커는 오케스트레이터가 부린다. 화면에는 콘텐츠 오케스트레이터가 워크스페이스에 합류하는 순간과, PM 에이전트가 데일리 스탠드업 종료 크론(daily-standup-close) 결과를 스레드에 남기는 모습이 함께 잡혀 있다. Slack 채널 자체가 회사의 실행 로그가 되는 구조다 — #agents-pm, #agents-outcomes, #agents-alerts, #agents-home-log, 에러 로그 채널들.

3부 — AI Native Company OS

대담에서는 같은 Notion 문서를 여러 번 오가며 설명하므로, 아래는 문서의 주제 순서로 묶었다. 각 소제목의 타임스탬프는 해당 페이지가 화면에 잡힌 시점이며 시간순이 아니다.

[27:00] ‘AI 잘 쓰는 회사’와 ‘AI 네이티브 회사’의 차이

Notion — Q12 답변: AI 잘 쓰는 회사는 생산성이 오르고, AI 네이티브 회사는 조직 구조와 의사결정 방식이 바뀐다

게스트가 인터뷰 준비로 정리해둔 문서에 이 대담 전체를 관통하는 구분이 적혀 있다.

AI를 잘 쓰는 회사는 생산성이 오릅니다. AI 네이티브 회사는 조직 구조와 의사결정 방식이 바뀝니다.

AI를 잘 쓰는 회사는 사람이 필요할 때마다 ChatGPT나 Claude를 열고 답변을 얻습니다. 그 자체로도 생산성은 올라갑니다. 하지만 대화가 끝나면 많은 것이 휘발됩니다.

AI 네이티브 회사는 AI가 회사 운영 데이터와 루프 안에 들어갑니다. AI가 답변만 하는 게 아니라, 회사의 memory를 읽고, 도구를 쓰고, 실행하고, 그 행동의 결과가 다시 기록됩니다.

즉, 일회성 답변을 넘어서 행동과 결과가 계속 축적됩니다. 그 축적이 다음 의사결정과 다음 실행에 영향을 줍니다.

[29:00] 스택은 5개 층으로 쌓인다

인포그래픽 — Honcho(상위 관리) ↔ Hermes(실행·오케스트레이션) ↔ Notion·Linear·Slack(업무 도구) ↔ MCP(앱 연결) ↔ Postgres(기억·데이터)

층	구성	역할
상위 관리	Honcho	프로필별 장기 메모리
실행·오케스트레이션	Hermes	에이전트 프레임워크(칸반·크론·스킬)
업무 도구	Notion · Linear · Slack	사람과 에이전트가 공유하는 작업 표면
앱 연결	MCP	도구·데이터 접속
기억·데이터	Postgres	로그·판정·컨텍스트 적재

Honcho는 Hermes 프레임워크가 가장 미는 개념으로, 프로필마다 장기 메모리를 따로 가져가 “나와 어떤 대화를 했고 어떤 식으로 답하는 게 좋을지”를 스스로 갱신한다. 게스트는 이를 “블랙박스로 취급하고 있다” 고 말하면서도 정확도 개선에 도움이 되냐고 물었더니 도움이 된다는 답을 받았다고 덧붙인다.

주목할 대목은 이 스택을 사람이 고르지 않았다는 것이다. Langfuse도 Postgres도 PM 에이전트가 선택했다. “이 구축의 대부분을 제라드가 하고 있어서 제가 결정한 게 아니에요. 트래킹을 잘하려면 Langfuse를 해야 되고, 에이전트 DB 적재는 Postgres가 제일 낫다고.” 사람은 “기존 AWS 인프라를 최대한 활용하라” 수준의 가이드만 줬다.

[39:00] 문서가 스스로 회사의 AI 네이티브 수준을 평가한다

Notion — AI Native Company OS 구축 계획 / 0. Executive Summary와 3가지 조건

이 문서 자체도 PM 에이전트가 갱신한다. “실제로 이 문서의 업데이트도 제라드가 하고 있고, 자기가 스스로 자기가 얼마나 AI 네이티브한 회사인지를 평가하더라고요. 저보다 잘해요.”

0. Executive Summary

이 문서는 더 이상 “PM Agent 1명 구축 계획서”가 아닙니다. 현재 상태 기준으로는 AI Native Company OS의 운영 현황 문서입니다.

초기 목표였던 첫 AI 직원, 즉 PM Agent 출범은 달성됐습니다. 지금은 PM이 총괄 OS owner 역할을 하고, 그 아래에 개발 실행 부서와 콘텐츠 실행 부서가 붙은 구조로 진화했습니다.

다만 AI Native Company라고 부르려면 단순히 agent가 많아지는 것만으로는 부족합니다. 회사 운영이 다음 3가지를 갖춰야 합니다.

Queryable: 회사 상태를 사람 기억이 아니라 시스템에 물어볼 수 있어야 함

Closed-loop: agent 행동의 결과가 기록되고 다음 행동에 반영되어야 함

Self-improving: 시간이 갈수록 PM / agent 조직의 판단 품질이 측정 가능하게 올라가야 함

현재 한 줄 정의 — 두 분이 최종 전략과 자본 배분을 맡고, PM이 회사 OS를 총괄하며, 개발 / 콘텐츠 오케스트레이터가 실행을 담당하는 AI 실행조직 v1.

[00:30] 세 가지가 동시에 돌아야 하는 이유

Notion — 1.3 왜 이 세 가지가 핵심인가: Queryable → Agent execution → Closed-loop → Self-improving 흐름도

인트로에 스쳐 지나간 페이지에 세 조건이 왜 세트여야 하는지가 적혀 있다. 각 조건이 빠졌을 때의 실패 모드를 이름 붙인 것이 이 문서에서 가장 날카로운 부분이다.

AI agent가 많아지는 것만으로는 회사가 AI native가 되지 않습니다. agent가 많은데 기록이 안 되면 일회성 외주입니다. 기록은 되는데 물어볼 수 없으면 데이터 창고입니다. 물어볼 수 있는데 결과가 다음 행동에 반영되지 않으면 보고서 자동화입니다.

질문 가능해야 한다        →  Queryable
행동해야 한다             →  Agent execution
결과가 돌아와야 한다      →  Closed-loop
다음 행동이 좋아져야 한다 →  Self-improving

Queryable 만들기는 결국 “의사결정에 필요한 정보를 전부 전산화하는 작업”이다. Notion·Slack·Linear·Metabase를 SoT(source of truth)로 정의하고 임베딩한 뒤, 어떤 에이전트가 어떤 자료에 접근할지를 지정한다. 갱신 주기도 문서 성격에 따라 나눈다 — 바뀌지 않는 문서는 한 번만 색인하고 별도 폴더에 두며, 매일 갱신되는 문서함은 매일 재색인한다. 이유가 명쾌하다. “그래야 내일 왔을 때 헛소리 안 하니까.”

[35:00] Closed-loop — 없으면 에이전트는 “말 잘하는 도구”다

Notion — 5.2 현재 구현 표와 요청→PM 판단→handoff→실행→PM QA→founder verdict→outcome 기록 흐름

문서가 정의한 루프는 이렇다.

요청 → PM 판단 → 실행 부서 handoff → 실행 → PM QA → founder verdict → outcome 기록 → 다음

Closed-loop가 없으면 agent는 “말 잘하는 도구”입니다. Closed-loop가 있어야 agent가 회사 운영에 실제로 들어옵니다.

5.2 현재 구현

루프	현재 상태	설명
`agent_runs logging`	작동	Langfuse / Postgres 기반으로 agent 행동 기록
`action_outcomes`	작동	`human_verdict` confirmed 59건
Slack verdict / reaction	일부 작동	accepted / rejected 중심으로 수집
commitments loop	작동	데일리 standup kickoff / ingest / close
analytics health cron	작동	App 1 / App 2 / App 3 production health
PM QA loop	약함	이번 문서에서 다음 핵심 병목으로 정의

에이전트와의 모든 대화는 Langfuse에 적재되고, 주 1회 크론이 도는 에이전트 리뷰 세션에서 중요했던 의사결정만 Postgres로 뽑아낸다. 여기서 사람이 하는 일이 하나 있다 — 라벨링이다. 좋았던 답변에는 좋은 이모지를, 나쁜 답변에는 X 표시를 세게 붙인다(“욕도 하고”). 그 이모지가 다음 주 리뷰에서 positive/negative 신호로 반영된다.

게스트의 평가는 냉정하다. “기술은 많은데, 결국은 저랑 동업자가 사람 손으로 어떻게 개입해서 이걸 Closed-loop 환경으로 만드느냐가 중요한 요소인 것 같아요.” 진행자가 언급한 에이전트 관측 도구(Arize AI 같은 “에이전트 CCTV”) 역시 이 사람 몫을 대신해주지는 못한다는 것이 그의 진단이다.

[36:25] 루프가 실제로 도는 모습

Slack agents-outcomes — 제라드 던의 Langfuse 대화 수집·Slack 이모지 반응 동기화·24h 운영 점검 크론 로그

#agents-outcomes 채널(설명: “outcome 등의 측정 결과 및 기록”)에는 PM 에이전트의 크론 결과가 시각과 다음 실행 예정 시각까지 붙어 계속 쌓인다.

✓ Langfuse 대화 수집 — 새 대화 4건 수집 / 중복 3건 skip (15분 주기)
✓ Slack 이모지 반응 동기화 — 새로 기록 1건 / 기존 반응 변경 0건 (5분 주기)
✓ 운영 점검 (지난 24h 요약) — agent_runs +40 / verdicts +1 / prompt v +0 (매일 09:00)

세 줄이 각각 Closed-loop의 세 조각이다. 대화를 모으고(기록), 사람의 판정을 회수하고(verdict), 하루치를 집계해 보고한다(측정).

[37:45] Self-improving — 무엇이 자동이고 무엇이 아직 사람인가

Notion — 6.2 성장 메커니즘 표 8행

문서는 먼저 흔한 오해부터 잘라낸다. “대화가 늘어서 기억이 많아지는 것” 자체는 self-improving이 아니며, 진짜 self-improving은 측정된 실패가 prompt / memory / skill / handoff contract / tool routing에 반영되는 것이다.

6.2 성장 메커니즘

#	메커니즘	무엇이 좋아지는가	현재 상태
1	Static prompt refinement	SOUL / AGENTS / MEMORY / USER 수동 개선	작동
2	Honcho memory	사용자 선호 / 의사결정 기준 / 대화 context 모델링	작동
3	Skill expansion	반복 업무 절차화	작동 중, 더 필요
4	Tool acquisition	MCP / terminal / Notion / Linear / Metabase 활용	작동
5	Verdict-driven learning	accepted / rejected / edited 기반 개선	일부 작동
6	PM QA learning	PM이 되돌린 실행 실패가 다음 handoff에 반영	미구현
7	Eval dataset	같은 문제를 월별로 다시 풀어 품질 비교	미구현
8	Architecture evolution	profile / worker / orchestration 구조 자체 개선	일부 작동

1번은 주 1회 리뷰 후 에이전트가 자기 SOUL.md·AGENTS.md·메모리 파일을 직접 고쳐 쓰는 것이다. 사람이 reject한 것은 빼고, 재사용 가능한 교훈 중심으로 반영한다. 3번 스킬 확장은 프레임워크가 알아서 해주는 영역이다 — “쓰다 보면 ‘이거 여러 번 반복했으니 스킬로 만들게’ 하는 구간이 많다.” 게스트는 이 부분을 의도적으로 Hermes에 위임했다고 말한다. “프레임워크가 발전할수록 이 레이어는 알아서 발전할 거라고 생각한다.”

[38:30] Honcho가 하지 않는 일 — 자동화의 경계선

Notion — 6.3 Honcho가 하지 않는 일 4가지와 6.4 Self-improving의 다음 기준 표

장기 메모리 레이어를 깔았다고 자기개선이 완성되는 것은 아니라는 점을 문서가 명시적으로 못박는다.

Honcho는 ① 새로운 skill을 자동 생성하지 않고 ② prompt_versions를 자동 배포하지 않으며 ③ 실행 결과의 품질을 자동 검수하지 않고 ④ code / content artifact를 자동 QA하지 않습니다.

따라서 Honcho는 self-improving의 중요한 일부지만, 전체 self-improving OS는 아닙니다. 나머지는 verdict loop / skill lifecycle / eval / QA gate가 채워야 합니다.

6.4 Self-improving의 다음 기준 — 자기개선이 되고 있는지를 어떻게 알 것인가에 대한 답이다.

기준	목표
PM-caught defects 증가	PM이 founder 전에 문제를 더 많이 발견
founder-caught defects 감소	founder가 직접 잡는 문제가 줄어듦
repeated reject pattern 감소	같은 이유의 reject가 줄어듦
skill patch 빈도	반복 실패가 절차 지식으로 전환됨
eval set acceptance rate	같은 문제를 다시 풀었을 때 더 잘함

4부 — 지금 어디까지 왔나

[39:38] 하루의 시작은 여전히 사람이 연다

크론으로 도는 것은 내부 개선 루프와 자기개선이고, “오늘 뭐 하자”는 사람이 시작한다. “오늘 일어났으니까 버그 티켓 이거 이거 고치고, 콘텐츠는 이렇게” 하는 식으로 대화를 열며, 이 의사결정 자체는 자동화하지 않았다.

전략·자본 배분·최종 승인, 즉 “어디로 가야 하지”는 사람이 전부 쥐고 있고, “어떻게 해야지”부터 PM에게 맡긴다. 신규 기능 기획이나 중요한 의사결정은 본인 몫이고, 에이전트가 하는 일은 과거에 이미 만들어진 의사결정 로직을 다듬어 실행하는 쪽이다.

버그도 자동으로 배포까지 가지 않는다. 이유는 두 가지다.

병목이 본인이라서 — “PR도 제가 보고 있으니 얘가 자동으로 해도 의미가 없어요. 아직 못 믿겠는데 개선해 나가는 중이라.”
보안을 하나도 신경 쓰지 않은 인프라라서 — 지금은 본인들만 쓰는 구조라 괜찮지만, 엔드포인트를 열어 자가 개선까지 붙이면 공격 표면을 고려해야 한다. “또 머리 아파지잖아요.”

진행자가 소개한 Y Combinator의 AI 네이티브 컴퍼니 사례(CS가 들어오면 크론으로 자동 개선 → PR까지 올리고 → 고객에게 답장까지 보내는 개발자 1인 회사)와 비교하면 의도적으로 느린 셈이다. 게스트의 정리는 이렇다. “저는 인수한 자산을 잘 운영하는 게 목적이라 이건 수단이에요.”

[42:50] 자기 평가 30% 안팎, 다음 목표는 SaaS 2개 추가 인수

AI Native OS 달성도를 묻자 약 30% 라고 답한다(이 대목은 자동 자막이 겹쳐 “30%“와 “20%“가 섞여 있어 정확한 숫자는 단정하기 어렵다). Queryable은 꽤 진행됐고, 남은 큰 구멍은 동업자와 구두로 하는 회의다. 그것만 적재하면 Queryable은 거의 끝난다고 보지만, “어떻게 효율적으로 할지 확신이 안 서서 안 하고 있다”며 일단 모든 대화를 Slack에 남기는 것으로 대신하고 있다.

단기 목표는 SaaS 2개 추가 인수다. 다만 순서가 분명하다 — “10명이 운영하던 걸 AI 시스템으로 한두 명이 운영할 수 있는지 검증해야 더 인수하는 게 의미가 있다.” 프론티어를 직접 뚫을 생각도 없다. “제가 이거의 프론티어가 아니니까, 열심히 제 사업하면서 프론티어들이 뚫어놓으면 ‘아, Self-improving 이렇게 하면 되겠다’ 하고 당겨오려고 생각합니다.”

부록 — 따라 하려면

인수 대상은 현금 흐름으로 본다. 코드베이스·고객 DB·PG 계약·거래처는 그것을 지탱하는 부속물이다. 회수 시나리오가 안 나오면 아무리 좋아 보여도 넘긴다.
Slack과 Notion을 반드시 인수 목록에 넣는다. 비정형 히스토리가 없으면 같은 실패를 반복한다. 이건 우호적인 양도자여야 가능하므로, 딜 초기부터 관계를 그렇게 만든다.
첫 에이전트는 인수 실사 Q&A 봇으로 시작한다. 양도자가 있는 채널에 초대해 질문을 대신 받게 하면, 인수인계 과정 자체가 에이전트의 학습 데이터가 된다.
에이전트는 늘리기 전에 쪼갠다. 하나가 모든 컨텍스트를 들면 판단 품질이 떨어진다. 역할별로 필요 없는 컨텍스트를 덜어내는 방향이 맞다.
문서를 사람이 아니라 다음 에이전트가 읽는다고 가정하고 쓴다. 원인 / 재현 / 수정안 / 검증 절차 / DoD가 들어간 티켓이면 개발 에이전트가 바로 PR을 낸다.
색인 주기를 문서 성격으로 나눈다. 고정 문서는 1회, 매일 갱신되는 문서함은 매일. 안 그러면 다음 날 헛소리를 한다.
판정(verdict) 회수 경로를 만든다. Slack 이모지처럼 마찰이 거의 없는 방법으로 accepted/rejected를 남기고, 주 1회 리뷰에서 프롬프트·메모리에 반영한다.
자기개선을 측정 지표로 정의한다. “PM이 founder보다 먼저 잡는 결함 수”, “같은 이유의 reject 감소” 같은 기준이 없으면 개선되고 있는지 알 수 없다.
자동화하지 않을 것을 먼저 정한다. 전략·자본 배분·최종 승인, 그리고 (보안 인프라가 준비되기 전까지는) 프로덕션 자동 배포.

원문 인용 모음

[08:42] “코드 베이스는 현금 흐름을 위한 수단인 거지 사실 목적이 되면 안 되고, 인수할 때는 현금 흐름이 가장 핵심이다라고 일단 깔고 넘어가야 되고.”
[11:06] “인수는 무조건 우호적인 양수자를 만나는 게 제일 중요해요. 어쩔 수 없어요.”
[11:53] “속도계도 없이 운전을 하면 차는 무조건 사고가 나잖아요.”
[15:03] “내가 뻔하게 ‘이렇게 하면 될 거 같은데’라고 생각한 것 중에서 안 되고 있는 거는, 안 하고 있는 이유가 있다고 깔아놓고 가는 게 마음이 편하더라고요.”
[16:38] “질문이 너무 많아서 이 질문을 풀어주는 애를 하나 만들겠다로 처음에 시작했었어요.”
[18:12] “기존 창업자보다 이 버그에 대해서 더 잘 알려면, 결국 코드베이스를 이해하고 있는 상태로 라이브 DB 접속권이 있으면 어떤 원인 때문에 생긴 이슈니까 어떻게 고치면 된다는 답을 충분히 할 수 있겠다고 판단했어요.”
[19:48] “얘가 알고 있는 양이 방대해지면 방대해질수록 의사 결정들이 마음에 안 들어지더라고요. 컨텍스트가 너무 넓으니까. 모델은 같은 거 쓰는데 뭔가 좀 멍청해진 거 같고.”
[22:57] “좀 멍청한 애를 보수적인 의사 결정을 하는 애로 두고, 더 머리 좋은 애를 조금 더 진보적인 의사 결정을 할 수 있게끔 세팅을 해봤는데 — 이게 좋은지 몰라요. 그냥 하다 보니까 이렇게 됐어요.”
[24:32] “저는 바이브 코딩을 아직 못 믿어 가지고, 라이브에 들어가는 코드를 100% 믿을 순 없어서 PR 리뷰는 제가 해요. 근데 사실 리뷰만 하지, 제가 한 번도 개선하라고 요청한 적은 없어요.”
[29:24] “이 구축의 대부분을 제라드가 하고 있어서 제가 결정한 게 아니에요. 트래킹을 잘하려면 Langfuse를 해야 된다, 에이전트 DB 적재는 Postgres로 하는 게 가장 낫다고.”
[30:11] “실제로 이 문서의 업데이트도 지금 제라드가 하고 있고, 자기가 스스로 자기가 얼마나 AI 네이티브한 회사인지를 평가하더라고요. 저보다 잘해요.”
[32:33] “매일 저랑 에이전트랑 대화하면서 새로 업데이트되는 컨텍스트가 있잖아요. 거기 안에 있는 문서들은 매일 색인해요. 그래야 내일 왔을 때 헛소리 안 하니까.”
[36:31] “기술은 뭐 많은데, 결국은 저랑 동업자가 휴먼으로 어떻게 개입을 해서 이거를 Closed-loop 환경으로 만드냐, 요게 좀 중요한 요소인 거 같아요.”
[38:04] “결국은 Self-improving은 데이터만 잘 넣어주면 되고, 내가 직접 해야 되는 거는 인간이 개입해서 뭐가 좋다 뭐가 나쁘다라고 말한 걸 다시 에이전트한테 넣어주는 구간, 그것만 있는 것 같아요.”
[41:14] “지금 제가 (PR을) 하고 있는 이유는, 병목이 어차피 저여서 그래요. 얘가 자동을 해도 의미가 없어요.”
[42:01] “저희가 지금 보안 같은 건 하나도 신경 안 쓴 인프라거든요. 엔드포인트 자체를 열어놓으면 공격의 여지 같은 것도 고려해야 되고, 또 머리 아파지잖아요.”
[43:37] “저는 어차피 제가 이거의 프론티어가 아니다 보니까, 열심히 제 사업하면서 프론티어들이 뚫어놓으면 ‘어, Self-improving 이렇게 하면 되겠다’ 하고 당겨오려고 생각하고 있어요.”
[44:24] “실제로 AI 시스템이 기존에 10여 명에서 운영하던 거를 한두 명에서 운영할 수 있게 만드는지를 검증을 해야 더 인수하는 게 의미가 있다 보니까.”

description	인수한 SaaS를 AI 에이전트 조직으로 운영하는 실전기 — Queryable·Closed-loop·Self-improving 3층 구조와 실제 구현 현황.
tags	ai-agents, agentic-workflow, startup, developer-tools, youtube
aliases	AI 네이티브 컴퍼니 OS, 인수창업 SaaS AI 운영, 김지혁 AI 직원 5명

LLM Wiki

탐색기