AI 잘 쓰는 회사 vs AI 네이티브 회사
2명이서 SaaS 100개를 굴리려고 합니다. HOW?????
안녕하세요 진양입니다.
저번 주에 “에이전트 5명을 본격적으로 굴려서 SaaS 롤업 살림에 보태겠다”고 했었죠. 그때 Honcho 메모리를 붙인 hermes 에이전트로, 시간이 갈수록 알아서 똑똑해지는 독립적인 인공지능 직원 5명을 만드는 게 1차 목표였었죠!!
오늘은 그 이야기의 2탄인데요. 솔직히 조금 길고, 조금 개발자들에게 친숙…해요. 그리고 더 솔직하게 말하면, 저도 아직 다 정답을 몰라요.
뭔가 정답을 알려주는 튜토리얼 보다는.. 그냥 만들면서 쓰는 일지에 가까워요!
AI 네이티브한 회사를 만드는 ‘이론’을 설명하는 글은 인터넷에 너무 많은데, 막상 ‘그래서 실제로 어떻게 만드는데?’에 답해주는 실질적인 일지는 별로 없더라고요.
그래서 저라도 과정을 날것으로 좀 남겨보기로 했어요. 같은 고민을 하는 분께 참고가 되면 좋겠다고 생각하며…
그러니 재미있게 읽어주세요!
“AI를 잘 쓰는 회사”랑 “AI 네이티브 회사”는 다르다
SaaS 롤업에 쓰려고 에이전트로 이것저것 세팅하면서 공부하다보니.. 이 둘이 완전히 다른 이야기라는 걸 알게 되었어요.
세션 여러 개 열어놓고 “니 이름은 오늘부터 PM이야” “넌 오늘부터 진양 콘텐츠 담당 에이전트야” 이렇게 세팅해서 쓰는거는. 물론 저도 지금까지 이렇게 써왔고, 이 정도는 누구나 쉽게 할 수 있습니다. 그리고 모든 직원이 이 수준으로 AI를 활용하게 되면은. 이건 그냥 “AI를 잘 쓰는 회사”가 되는거에요.
물론 “AI를 잘 쓰는 회사”가 되는것도 나름의 장점이 있긴하죠. 근데 제가 만들어야 하는 건 이게 아니란말이죠.
지금 동업자와 둘이 SaaS를 4개. 아니 나아가서 30개 100개까지도 굴릴 수 있는 팀이 되는 것. 이게 가능하다면 그 자체가 우리 팀의 엄청난 강점이 되겠다 싶었어요. 아니, 강점을 넘어서 지속가능한 SaaS 롤업을 하려면 반드시 만들어야하는 기반에 더 가깝다고 생각을 했어요.
(저번에도 얘기했지만 SaaS 롤업은 하나 인수할 때마다 지식 노동 운영 코스트가 계속 붙는 구조라, 사람으로만 메우면 한계가 온다고 가정.. . 그래서 이게 옵션이 아니라 필수인 거예요.)
그래서 인터넷 자료를 닥치는 대로 뒤졌어요
인터넷 정령님께서 부디 나에게 올바른 길로 인도해주기를 기도하며(…) 열심히 인터넷을 뒤지다보니 YC 파트너 Diana Hu의 영상이랑 인터뷰, 트위터 창업자 잭 도시가 만든 AI 네이티브 조직 사례까지.. 일단 닥치는 대로 다 봤어요.
볼수록 “이걸 해내야 SaaS 롤업에 성공하겠다”라는 감정이 스멀스멀 올라오는데. 동시에 위에서 말한 갈증도 더 커지더라고요. 멋진 개념이랑 키워드는 가득한데, 적장 ‘그래서 어떻게 만드는데’에 답해주는 사람은 없는 느낌.
talk is cheap, now show me the implementation. 이 말이 목 끝까지 차오르더라고요.
조사해보니, AI 네이티브 회사의 3가지 조건
위 내용을 아주 짧게 요약하면, AI 네이티브한 회사가 되려면 회사가 Queryable / Closed-loop / Self-improving 이 세 가지 속성을 가져야 한다.
이게 뭔소리냐, 하나씩 풀어볼게요.
1. Queryable한 회사 → 회사 상태를 데이터로 물어볼 수 있어야 한다
말 그대로, 회사의 모든 상태를 SQL 쿼리 넣듯이 데이터로 답할 수 있어야 한다는 거예요.
예를 들어 “3주 전에 우리가 내린 경영 의사결정이 뭐가 있었지?”라고 물으면, 제 머리가 아니라 데이터가 답하는 상태요.
이게 되려면 회사의 모든 활동이 디지털 환경에 기록돼 있어야 해요. 극단적으로는:
의사결정은 카톡이나 구두가 아니라 슬랙에서
모든 회의는 녹음 필수..
심지어 에이전트랑 나누는 대화도, 동업자와 나눈 대화도 DM이나 외부 공간이 아니라 워크스페이스 안에서
회사 상태에 대한 어떤 질문이든 데이터가 답 할 수 있는 환경으로 만드는 게 첫 번째.
2. Closed-loop인 회사 → 행동이 결과로, 결과가 다시 학습으로
구성원(사람이든 에이전트든)이 한 모든 행동이 결과로 연결되고, 그 결과가 다시 다음 행동의 입력으로 먹여지는 상태예요.
출력을 다시 입력으로 먹이는 시스템.
저도 잘 몰라서 찾아봤는데, 자동차의 크루즈 기능이 대표적인 closed-loop이라고 하더라고요. 더 찾아보니 린 스타트업의 Build-Measure-Learn도 결국 회사를 closed-loop으로 돌리기 위한 방법론이고요.
정리하면, 사람과 에이전트의 행동이 어떤 ‘결과’로 시스템에 기록되고, 그게 다음 행동의 입력으로 다시 들어가면 closed-loop입니다.
3. Self-improving인 회사 → 시간이 갈수록 의사결정이 좋아진다
마지막으로, 시간이 갈수록 사람과 에이전트의 의사결정이 좋아지고, 그게 측정 가능한 상태가 되는 것.
한마디로 회사가 점점 더 정확하고, 빠르고, 저렴해지는 거예요.
초기에는 에이전트의 성과를 주기적으로 측정해서, 그 피드백이 위에서 말한 closed-loop의 입력으로 다시 들어가게 하면 됩니다. (말은 쉽지..)
결국 그러면, 내가 원하는 것은.. 딸깍딸깍만 하는 것
말은 거창하게 했는데, 결국 제가 필요한 건 아주 단순해요.
맨 위에서 저랑 동업자는 딸깍딸깍 의사결정만 하고 싶어요. 자본을 어디 넣을지, 전략을 어떻게 가져갈지 같은 결정만요. 실제 운영이랑 실무는 AI 직원들이 다 하고요. 실무를 안하는 상태를 만들고 싶어요 ㅋㅋㅋ…
그러면 결국 이 목표(일을 안하는 목표)를 위해서 구조를 레이어로 쪼개면 이렇게 돼요.
L0 (슈퍼바이저) → 저랑 동업자. 딸깍딸깍 명령만 내림
L1 (에이전트) → 명령을 받아 각자 자기 지식 기반으로 “어떤 스킬이랑 MCP를 써야 하나” 판단하고 행동
L2 (인텔리전스) → postgresql + pgvector. 실행 기록, 실행 프롬프트, 의사결정, 결과 아웃풋… self-improving에 필요한 데이터를 다 쌓는 곳.
L3 (연결) → 에이전트가 실제 업무를 칠 수 있게 연결된 MCP들. 의사결정의 손과 발
근데 아직도 너무 추상적임.
closed-loop, self-improving.. 개념적으로는 알겠어. 근데 아직 너무 추상적인 느낌. 이걸 그러면 어떻게 구현할지가 젤 고민... 개념은 알겠는데 어디서 부터 구현을 시작해야하는지 안 잡히는 느낌.
그래서 쪼갰어요. 조금 더 구체적인 질문으로.
새로운 질문: 지금 내가 진짜 필요한 직원이 누구지?
답변: 우리가 인수한 SaaS의 방대한 맥락을 나보다 더 잘 아는 직원. 회사를 나보다 더 잘 아는 전문가.
그래서 첫 직원을 만들고 이름을 붙였어요. ‘제라드’ PM.
신기하게도, 이렇게 구체적인 Role을 하나 정해놓고 상상하니까 closed-loop이랑 self-improving을 어떻게 구현할지가 훨씬 또렷해지더라고요. 질문이 구체적이게 변하니까, 설계도 아주 구체적으로 변하면서 위에서 그린 도표도 훨씬 또렷해지기 시작했어요.
예를 들면 이런 거예요
제가 제라드한테 이렇게 시킨다고 해볼게요.
“AA 회사가 연 구독 중에 환불을 요청했어. 과거 슬랙 데이터 뒤져서 어떻게 대응하면 좋을지 알려줘.”
이 요청은 agents_run에 자동으로 기록은 돼요. 근데 그걸로 끝이면 안 되죠. 얘가 뱉은 결과가 좋았는지, 별로였는지, 살짝 손봐야 했는지 같은 피드백이 또 DB에 쌓여야 closed-loop이 완성되거든요.
근데 PM한테 시키는 일들은 “조회수 1000 넘으면 성공” 같은 깔끔한 정량 기준을 잡기가 애매해요. 그래서 PM 같은 애들은 주간/일간으로 사람이 피드백을 넣어주는 프로세스가 따로 필요할 것 같아요.
반대로 단순하게 콘텐츠 찍는 에이전트라면? 콘텐츠 성과를 MCP로 땡겨와서 정기적으로 피드백을 자동으로 넣어줄 수 있죠. 어떤 콘텐츠가 잘됐고 못됐는지 기준을 알아서 만들어가게요.
그래서 피드백 구조는 이렇게
사람 피드백이 필요한 에이전트들은, 슬랙에서 리액션(이모지)을 달면 그게 action_outcomes 테이블로 수집되는 구조로 가려고 해요. 일하다 말고 평가 폼 채우는 게 아니라, 그냥 👍 👎 누르면 데이터가 쌓이게.
self-improving은 솔직히 아직 고민이 많아요
일단 Hermes 에이전트가 honcho 메모리를 켜면 기본적으로 ‘self-improving agent’를 지향하긴 해요. 안에서 system prompt에 넣을 맥락을 계속 동적으로 업데이트하면서, 사용자랑 환경에 대해 점점 정밀해지는 거죠. 그래서 이 구간은 일단 honcho에 좀 아웃소싱한 셈이에요.
근데 장기적으로는, 에이전트 한 명 한 명이 똑똑해지는 것만으론 부족해요. 회사 전체의 의사결정 자체가 좋아지려면 에이전트 평가는 물론이고, 사람(나 포함)의 의사결정도 다 측정하고 평가 가능하게 만들어야 하거든요.
self-improving 쪽은 일단 prompt 버저닝이랑, 버전별 acceptance_rate(에이전트가 뱉은 결과를 내가 그대로 받아들인 비율) 추적부터 시작하려고요.
honcho 상태를 어떻게 조회할지, 넣어주는 맥락의 양에 따라 진짜로 성능이 유의미하게 올라가는지도 봐야 하고. LLM Judge 같은 걸 녹여야 하나도 고민 중이에요.
지금 구조는 거의다 잡고 L0부터 L3까지 쭉 연결하는 걸 최우선으로 작업을 하고 있어요. 예를들어, Hermes랑 Langfuse를 붙여서 에이전트 실행 결과가 postgresql로 자동 싱크되게 했고, 인수한 SaaS에서 쓰던 모든 툴의 MCP에 에이전트가 접근할 수 있게 세팅도 끝냈어요. Queryable은 100%, Closed-Loop은 70%, Self-Improving은 10% 정도?
암튼 이건 끝난 이야기가 아니라 이제 막 시작한 일지예요!! 앞으로도 인수한 SaaS를 AI로 어떻게 굴리는지.. 날것 그대로 계속 풀어볼 거고요! AI를 붙여서 SaaS 롤업을 진짜로 돌려보는 과정이 궁금하시면, 구독 눌러두고 다음 편에서 이어서 봬요! 안녕!