SaaS를 사람 없이 AI로 100% 운영하는 방법을 공개합니다. 진양의 인수창업 김지혁님
📺 원본 영상: SaaS를 사람 없이 AI로 100% 운영하는 방법을 공개합니다. (진양의 인수창업 김지혁님)
🎙️ 채널: 빌더 조쉬 Builder Josh
📅 정리 일자: 2026-07-27
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
이 영상은 김지혁 님이 SaaS를 인수한 뒤, 기존 팀이 축적해 온 운영 지식과 개발 맥락을 AI 에이전트에게 이전해 가는 과정을 다룬다. 핵심은 단순히 코드를 넘겨받는 것이 아니라, 매출을 유지하는 데 필요한 현금 흐름, 고객 데이터, 의사결정 히스토리, 버그 처리 방식, 제품 개발 기준까지 함께 흡수해야 한다는 점이다.
강연자는 이를 “AI Native Company OS”라는 관점으로 설명한다. 회사 내부의 데이터를 AI가 읽을 수 있는 Queryable(질의 가능한) 상태로 만들고, 에이전트의 산출물을 다시 학습 재료로 넣는 Closed Loop(폐쇄 루프)를 구축하며, 장기적으로는 에이전트가 스스로 프롬프트와 작업 방식을 개선하는 Self-improving(자가 개선) 구조로 진화시키는 것이 목표다.
인수창업의 출발점은 아이디어가 아니라 현금 흐름이다
김지혁 님은 본래 개발자였지만, 제로투원 창업을 반복하며 리스크를 계산하기 어렵다는 문제를 체감했다고 설명한다. 그래서 이미 매출과 고객이 존재하는 작은 사업체를 인수해 운영하는 방식으로 방향을 틀었고, 아기 타이즈 커머스, BTS 팬 대상 선물 배송 서비스, 무인 아이스크림 매장, B2B 음료 도매, 주방 잡화 유통 등 여러 사업체를 거쳐 왔다. 이 경험은 SaaS 인수에서도 그대로 이어진다. 그는 인수의 본질을 “코드베이스를 사는 것”이 아니라 “유지 가능한 현금 흐름을 사는 것”이라고 본다.
이 관점은 SaaS 인수에서 특히 중요하다. 많은 사람이 SaaS를 인수한다고 하면 코드, 서버, 결제 계정, 데이터베이스 같은 자산을 먼저 떠올리지만, 강연자는 그것들이 모두 현금 흐름을 유지하기 위한 수단이라고 선을 긋는다. 고객이 왜 결제하고 있는지, 어떤 기능이 이탈을 막고 있는지, 어떤 운영 지식이 매출을 지탱하고 있는지를 모르면 코드만 넘겨받아서는 사업을 유지할 수 없다. 따라서 인수 실사의 핵심은 “이 매출과 순이익이 인수 이후에도 유지될 수 있는가”라는 질문으로 수렴한다.
SaaS가 과거에는 매력적이면서도 인수하기 어려운 자산이었던 이유도 여기에 있다. 일반적으로 SaaS 매물은 3년, 5년, 때로는 7~8년 치 이익에 해당하는 높은 Multiple(멀티플)로 거래되었고, 개발 유지보수와 기능 개선을 지속해야 한다는 부담도 컸다. 그러나 강연자는 AI가 개발, 디자인, 마케팅 역량을 점점 Commodity(범용재)로 만들면서 상황이 달라졌다고 본다. 기존에는 10명이 운영하던 SaaS라도 AI 에이전트와 소수 운영자가 유지할 수 있다면, 인수자는 비용 구조를 크게 낮추면서 회수 기간을 단축할 수 있기 때문이다.
SaaS 인수에서 가장 어려운 것은 코드가 아니라 맥락의 이전이다
강연자가 SaaS를 인수하며 가장 크게 느낀 문제는 제품을 둘러싼 지식의 양이었다. 커머스나 무인매장 같은 사업도 운영 노하우가 필요하지만, SaaS는 기능 개발 히스토리, 고객 요청, 실패한 실험, 버그 처리 방식, 데이터 구조, 제품 방향성 같은 정보가 훨씬 더 두껍게 쌓인다. 이 지식이 제대로 이전되지 않으면 새 인수자는 이전 창업자가 이미 시도하고 실패한 의사결정을 반복하게 된다. 그래서 그는 SaaS 인수의 PMI(Post-Merger Integration, 인수 후 통합)에서 가장 중요한 과제를 “운영 맥락을 어떻게 흡수할 것인가”로 정의했다.
초기에는 Slack과 Notion 같은 비정형 데이터를 굳이 받을 필요가 없다고 생각했지만, 실제 실사를 진행하면서 판단이 바뀌었다. 코드 저장소나 결제 정보만으로는 왜 어떤 기능이 만들어졌는지, 어떤 고객군을 중요하게 봤는지, 어떤 방향은 왜 가지 않았는지 알기 어렵기 때문이다. 결국 그는 기존 팀이 사용하던 Slack, Notion, Linear, Metabase 같은 업무 도구를 최대한 넘겨받아 AI가 읽을 수 있는 형태로 만들기 시작했다. 여기서 중요한 전제는 우호적인 양도자를 만나는 것이다. 강연자는 인수에서는 좋은 조건만큼이나 양도자가 얼마나 협조적으로 지식과 히스토리를 넘겨주느냐가 중요하다고 강조한다.
12:54 - 인수 후 기존 창업자가 보던 지표와 Metabase 기반 계기판을 설명하는 구간
이 과정에서 AI 에이전트는 단순한 챗봇이 아니라 회사의 기억을 담는 인터페이스가 된다. 사람이 모든 Slack 대화와 Notion 문서를 읽고 제품 맥락을 이해하는 대신, 해당 자료들을 Embedding(임베딩)하고 MCP(Model Context Protocol)로 연결해 질문하면 답을 주는 구조를 만든 것이다. 이렇게 되면 인수자는 기존 창업자에게 반복적으로 질문하지 않아도 되고, AI는 축적된 문서와 대화 기록을 바탕으로 제품의 과거와 현재를 설명하는 역할을 맡을 수 있다. 강연자는 이 첫 번째 AI 에이전트를 사실상 PM(Product Manager)처럼 포지셔닝했다고 설명한다.
AI PM 제라드의 역할은 버그를 문서화하고 의사결정 맥락을 연결하는 것이다
김지혁 님이 처음 만든 에이전트는 실사 중 질문에 답하는 봇에 가까웠지만, 점차 PM 역할로 확장되었다. 영상에서는 이 에이전트를 “제라드”라고 부르며, 제품 데이터, 코드베이스, Notion, Slack, 라이브 데이터베이스 접근 권한까지 연결해 두었다고 설명한다. 특히 중요한 예시는 에러 로그 처리다. SaaS 인수 직후 가장 큰 리스크 중 하나는 버그가 발생했을 때 원인을 파악하지 못하거나 수정하지 못하는 상황인데, 제라드는 이 문제를 줄이는 역할을 맡는다.
강연자에 따르면, 버그가 발생하면 제라드는 에러 로그를 보고 어떤 사용자에게서 발생했는지, 어떤 코드 라인과 관련이 있는지, 기존에 알려진 이슈인지 등을 조합해 원인을 추론한다. 이후 Notion의 개발 요청 관리 데이터베이스에 해당 이슈를 등록하고, Definition of Done(완료 기준, DOD)을 포함한 문서 형태로 정리한다. 이 문서에는 원인, 재현 방법, 수정 방향이 들어가며, 사람 개발자가 읽기 위한 문서라기보다 다음 AI 개발 에이전트가 작업을 이어받을 수 있는 사양서에 가깝다.
18:49 - AI PM 제라드가 버그 원인, 재현 방법, 수정 방향과 DOD를 Notion 문서로 정리하는 흐름
이 지점에서 AI 운영체계의 핵심 패턴이 드러난다. PM 에이전트가 제품과 고객 맥락을 이해하고, 버그나 기능 요청을 구조화된 개발 티켓으로 바꾸며, 개발 에이전트가 그 티켓을 기반으로 Pull Request(PR)를 만든다. 사람은 모든 세부 정보를 직접 조사하는 대신 최종 판단과 승인에 집중한다. 다만 강연자는 아직 라이브 코드에 들어가는 PR은 직접 검토하고 있으며, 보안이나 이상한 변경이 없는지 확인한다고 말한다. AI가 실무를 상당 부분 수행하더라도 최종 책임의 레이어는 여전히 사람에게 남아 있는 셈이다.
에이전트는 한 명에게 모든 것을 맡기는 순간 오히려 둔해진다
처음에는 제라드에게 가능한 많은 권한과 맥락을 주는 방식으로 시작했지만, 강연자는 곧 문제를 발견했다. 컨텍스트가 너무 넓어질수록 에이전트의 의사결정이 마음에 들지 않게 되었고, 답변 품질도 떨어지는 느낌을 받았다는 것이다. 이는 대형 언어모델을 업무에 적용할 때 자주 나타나는 문제다. 모든 자료를 한 에이전트에게 몰아주면 이론적으로는 똑똑해질 것 같지만, 실제로는 역할과 판단 기준이 흐려져 산출물의 일관성이 떨어질 수 있다.
그래서 그는 에이전트를 역할별로 분리했다. PM 역할을 하는 제라드와 별도로 개발자 페르소나인 “길포일”을 만들었고, 콘텐츠 마케팅 실행을 담당하는 오케스트레이터도 따로 두었다. 개발자 에이전트는 Hermes의 Kanban 기능을 활용해 오케스트레이터처럼 작동하며, 하위에 실제 개발자와 리뷰어들을 둔다. 리뷰어는 Claude 기반 리뷰어와 OpenRouter의 NVIDIA 모델 기반 리뷰어로 나뉘며, 하나는 보수적인 Gatekeeping(게이트키핑) 관점에서, 다른 하나는 기능 동작과 개선 가능성까지 보는 QA 관점에서 검토하도록 구성했다.
콘텐츠 마케팅 에이전트 역시 비슷한 구조를 따른다. 제라드가 회사 방향성이나 매출 레버에 대한 논의를 바탕으로 “SNS 계정을 운영하라”는 식의 전략적 제안을 만들면, 콘텐츠 오케스트레이터는 이를 실행 가능한 콘텐츠 작업으로 바꾼다. 그 아래에는 리서치, 라이팅, 리뷰 역할을 하는 하위 에이전트들이 있으며, 전체적으로는 3개의 주요 대화 상대와 9개의 세부 프로필이 움직이는 구조라고 설명한다. 강연자의 실험에서 중요한 점은 AI 직원을 많이 만드는 것이 아니라, 각 에이전트가 가져야 할 맥락과 책임 범위를 의도적으로 제한해야 한다는 것이다.
21:57 - PM, 개발 오케스트레이터, 리뷰어, 콘텐츠 오케스트레이터로 나뉜 AI 에이전트 조직 도표 설명
AI Native Company OS의 첫 단계는 Queryable한 회사를 만드는 것이다
강연자가 말하는 AI Native Company OS의 첫 번째 조건은 Queryable(질의 가능한) 상태다. 이는 회사의 중요한 정보가 사람의 머릿속, 흩어진 문서, 구두 회의, Slack 대화 속에만 머물러 있지 않고, AI가 읽고 검색하고 조합할 수 있는 형태로 정리되어 있어야 한다는 의미다. 그는 SSOT(Single Source of Truth, 단일 진실 공급원)가 어디에 있는지 정의하는 것이 출발점이라고 설명한다. 이 회사의 경우 Notion과 Slack에는 제품 히스토리와 의사결정 맥락이, Linear에는 프로젝트가, Metabase에는 제품 지표와 라이브 서비스 데이터가 들어 있었다.
이 데이터들을 연결하면 에이전트는 단순히 문서를 검색하는 수준을 넘어 실제 업무 판단을 돕는다. 예를 들어 버그가 발생했을 때 제라드는 사용자 정보와 라이브 데이터, 코드베이스, 기존 이슈 히스토리를 함께 조회해 원인과 수정 방향을 정리한다. 이것은 회사의 모든 의사결정에 필요한 정보를 전산화하는 작업에 가깝다. 강연자는 Y Combinator의 AI Native Company 논의에서도 “모든 것을 Queryable하게 만들어야 한다”는 전제가 중요하게 다뤄진다고 언급하며, 자기 실험도 이 관점과 맞닿아 있다고 설명한다.
27:20 - AI Native Company OS에서 L1, L2, L3와 Queryable 레이어를 연결하는 도표 설명
중요한 것은 한 번 임베딩하고 끝내는 것이 아니다. 회사는 매일 새로운 의사결정과 고객 이슈, 회의록, 시장 조사, 제품 변경 히스토리를 만든다. 따라서 업데이트가 거의 없는 정적 문서와 매일 갱신되는 문서함을 분리하고, 후자는 주기적으로 다시 임베딩해야 한다. 강연자는 Notion 문서 변경 사항을 매일 동기화하고, Langfuse에 쌓인 에이전트 대화 로그는 주간 단위로 정리해 Postgres에 넣는 방식으로 운영한다고 설명한다.
29:20 - Langfuse와 Postgres를 활용해 에이전트 대화와 의사결정 로그를 주간 단위로 적재하는 구조
Closed Loop는 AI의 산출물을 다시 AI의 입력으로 돌려보내는 구조다
두 번째 단계는 Closed Loop(폐쇄 루프)다. 강연자는 이를 온도계나 자동 조절 시스템에 비유하며, 어떤 입력을 넣어 산출물이 나오고 그 산출물이 다시 입력으로 들어가도록 만드는 구조라고 설명한다. AI 에이전트가 답변을 만들고 문서를 작성하고 개발 티켓을 생성했다면, 그 결과가 좋았는지 나빴는지를 평가하고 다음 의사결정에 반영해야 한다. 그렇지 않으면 에이전트는 매번 새롭게 대답할 뿐, 회사 고유의 판단 기준을 축적하지 못한다.
그는 Langfuse를 통해 에이전트와의 모든 대화를 추적하고, 주간 리뷰 세션에서 중요한 의사결정과 좋았던 답변, 나빴던 답변을 Postgres로 정리한다고 말한다. 사람은 Slack에서 이모지 반응이나 직접 피드백을 통해 긍정적, 부정적 판단을 남기고, 에이전트는 이 피드백을 다시 참조한다. 어떤 답변은 단기 메모리에 들어가고, 어떤 피드백은 프롬프트 수정이나 Agent Markdown 파일 업데이트로 이어진다. 이 구조가 단순한 로그 저장과 다른 점은, 로그가 다음 행동을 바꾸는 재료가 된다는 데 있다.
36:19 - Slack 이모지 반응과 사람의 피드백을 Closed Loop에 반영하는 구간
이 과정에서 사람의 역할은 줄어들지만 사라지지는 않는다. 강연자는 Closed Loop를 만들기 위해서는 결국 사람이 중간에서 “이건 좋았다”, “이건 나빴다”를 판정해야 한다고 본다. 에이전트 감사나 평가를 자동화하는 별도 서비스가 등장하더라도, 초기에는 회사의 운영 철학과 리스크 기준을 아는 사람이 직접 피드백을 넣어야 한다. 특히 인수 직후의 SaaS에서는 잘못된 자동화가 제품과 고객에게 직접 영향을 줄 수 있기 때문에, 사람의 검토가 루프의 품질을 결정하는 핵심 요소가 된다.
Self-improving은 완전 자율 운영이 아니라 반복 작업의 학습화에 가깝다
세 번째 단계는 Self-improving(자가 개선)이다. 영상에서 말하는 자가 개선은 AI가 회사의 전략을 마음대로 정하고 실행하는 수준이 아니라, 반복되는 작업과 피드백을 바탕으로 자기 답변 방식, 프롬프트, 스킬, 메모리를 조금씩 개선하는 구조에 가깝다. 강연자는 주간 리뷰 이후 에이전트가 직접 Markdown 파일을 수정해 자신의 Soul, Agent, Memory 파일을 업데이트한다고 설명한다. 리젝트된 판단은 제거하고, 재사용 가능한 교훈은 반영하는 식이다.
37:22 - 에이전트가 자신의 Soul, Agent, Memory Markdown 파일을 업데이트하는 Self-improving 구조 설명
또한 Hermes 프레임워크와 Honcho 같은 장기 메모리 레이어가 이 구조를 보조한다. Honcho는 각 프로필별 장기 메모리를 관리하며, 지금까지 어떤 대화를 했고 어떤 답변 스타일이 적합했는지를 저장하는 외부 서비스 레이어로 설명된다. 강연자 본인도 일부는 블랙박스로 취급하고 있다고 말하지만, 에이전트에게 물었을 때 정확도 개선에 도움이 된다는 답변을 받았다고 한다. 이 대목은 현재 AI Native Company 구축이 완전히 검증된 정답이라기보다, 빠르게 실험하고 조정하는 운영 연구에 가깝다는 점을 보여준다.
자가 개선의 본질은 데이터와 피드백이다. 강연자는 “데이터만 잘 넣어주면” 나머지 많은 부분은 프레임워크와 LLM이 보조할 수 있지만, 사람이 좋고 나쁨을 판단해 다시 에이전트에게 넣어주는 구간은 여전히 중요하다고 말한다. 결국 Self-improving은 사람 없는 회사라기보다, 사람이 반복적으로 하던 맥락 주입과 품질 판단을 시스템화하는 과정이다. 이 구조가 안정화될수록 사람은 작업 실행자가 아니라 전략, 자본 배분, 최종 승인에 더 집중하게 된다.
아직 100% 자동화가 아닌 이유는 신뢰와 보안 때문이다
영상 제목은 “사람 없이 AI로 100% 운영”을 말하지만, 실제 운영 단계는 아직 완전 자동화와는 거리가 있다. 강연자 스스로도 현재 AI Native Company OS의 완성도를 20~30% 정도로 보고 있으며, Queryable 상태는 꽤 진척되었지만 구두 회의나 동업자와의 의사결정까지 모두 적재하지는 못했다고 말한다. 또한 신규 프로젝트를 시작할지, 어떤 기능을 2주 동안 개발할지, 어디에 자본을 배분할지는 여전히 사람이 결정한다. AI는 “어떻게 할 것인가”의 실행과 정리를 맡고, “무엇을 할 것인가”의 전략 판단은 창업자가 쥐고 있는 구조다.
버그 수정도 마찬가지다. 이론적으로는 고객 문의가 들어오면 AI가 원인을 파악하고, PR을 올리고, 고객에게 답변까지 보내는 흐름을 만들 수 있다. 강연자도 Y Combinator 사례를 언급하며 그런 방식이 가능하다는 점은 인정한다. 그러나 그는 아직 PR을 직접 검토하고 있으며, 자동으로 라이브 코드에 반영하는 구조는 만들지 않았다고 말한다. 그 이유는 기술적 가능성의 문제가 아니라 신뢰와 보안의 문제다.
특히 내부용으로만 쓰는 에이전트 시스템은 보안 설계를 엄격하게 하지 않아도 되는 부분이 있지만, 외부 엔드포인트를 열거나 자가 개선 권한을 크게 부여하면 공격 가능성과 오작동 리스크가 커진다. 따라서 강연자는 지금의 시스템을 “AI 운영체계 자체를 팔기 위한 제품”이 아니라 “인수한 자산을 더 잘 운영하기 위한 수단”으로 본다. 목적은 자동화 그 자체가 아니라, 기존에 10명이 운영하던 SaaS를 1~2명이 유지할 수 있는지 검증하는 데 있다.
다음 실험은 SaaS 2개 추가 인수와 운영 레버리지 검증이다
강연자의 단기 목표는 SaaS를 두 개 정도 더 인수하는 것이다. 이는 단순히 포트폴리오를 늘리려는 시도가 아니라, 현재 구축한 AI Native Company OS가 다른 SaaS에도 적용 가능한지 검증하려는 실험이다. 하나의 제품에서만 작동하는 자동화는 운영 노하우일 수 있지만, 여러 SaaS에 반복 적용할 수 있다면 그것은 인수창업의 레버리지 구조가 된다. 결국 핵심 질문은 “기존에 10명이 운영하던 SaaS를 AI 시스템과 한두 명의 사람으로 운영할 수 있는가”이다.
이 질문은 SaaS 시장의 Valuation(가치평가)에도 영향을 줄 수 있다. 과거에는 운영 인력이 많이 필요한 SaaS가 높은 멀티플을 정당화하기 어려웠지만, AI가 유지보수와 고객 대응, 개발 티켓화, 콘텐츠 마케팅 일부를 대체할 수 있다면 비용 구조가 달라진다. 반대로 AI 때문에 지식 노동의 가치가 낮아질 것이라는 믿음이 확산되면, 일부 SaaS 매물은 더 낮은 가격으로 나올 수도 있다. 강연자가 SaaS를 다시 인수 후보군에 넣게 된 배경도 이 변화에 있다.
다만 이 전략은 누구에게나 곧바로 적용되기 어렵다. 김지혁 님은 개발자 출신이고, 사업 인수 경험이 있으며, 지표와 현금 흐름을 읽을 수 있는 운영자다. AI 에이전트가 갭을 메워주는 것은 사실이지만, 어떤 데이터를 넘겨야 하는지, 어떤 자동화를 막아야 하는지, 어떤 PR은 위험한지 판단하려면 여전히 높은 수준의 도메인 이해가 필요하다. 따라서 이 사례의 진짜 인사이트는 “AI가 사람을 완전히 대체했다”가 아니라, “AI를 통해 숙련된 운영자 한 명의 관리 범위가 얼마나 넓어질 수 있는가”에 있다.
마무리 / 핵심 정리
이 영상의 핵심은 SaaS 인수창업을 AI 에이전트 운영 실험으로 확장했다는 데 있다. 강연자는 인수의 본질을 코드나 계정 이전이 아니라 현금 흐름의 이전으로 정의하고, 그 현금 흐름을 유지하기 위해 필요한 회사의 기억을 AI가 읽을 수 있는 형태로 바꾸고 있다. Slack, Notion, Linear, Metabase, Langfuse, Postgres, MCP, Hermes, Honcho 같은 도구들은 각각의 기술 스택이라기보다, 회사의 지식과 행동 결과를 순환시키는 운영 인프라로 쓰인다.
가장 중요한 교훈은 자동화보다 맥락화다. AI 에이전트가 일을 잘하려면 먼저 회사의 의사결정 히스토리, 고객 데이터, 제품 지표, 버그 처리 방식이 Queryable해야 하고, 그다음에는 에이전트의 산출물을 사람이 평가해 다시 입력으로 넣는 Closed Loop가 필요하다. 마지막으로 그 피드백이 프롬프트, 메모리, 스킬 개선으로 이어질 때 비로소 Self-improving 구조가 만들어진다.
그러나 이 시스템은 아직 완성된 무인 회사가 아니다. 전략, 자본 배분, 최종 승인, 보안 판단은 여전히 사람이 담당하고 있으며, 강연자도 현재 완성도를 20~30% 수준으로 본다. 그럼에도 이 사례는 SaaS 인수창업의 새로운 가능성을 보여준다. 앞으로 중요한 질문은 AI가 회사를 완전히 대신 운영할 수 있느냐가 아니라, AI를 통해 한 사람이 얼마나 많은 현금 흐름 자산을 안정적으로 관리할 수 있느냐가 될 가능성이 크다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | SaaS를 사람 없이 AI로 100% 운영하는 방법을 공개합니다. (진양의 인수창업 김지혁님) |
| 채널 | 빌더 조쉬 Builder Josh |
| 영상 길이 | 약 45분 57초 |
| 리포트 작성 | 2026-07-27 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.