이 글은 [조쉬의 뉴스레터]에서 발행되었습니다.

퀄리티 있는 프로덕트, 창업가, 비즈니스 이야기를 매주 구독해보세요. 
구독 시 100개의 1인 창업 케이스 스터디가 발송됩니다.

[구독하러 가기]

개발자 출신 김지혁 님은 지금까지 일곱 개 사업체의 영업권을 인수했고, 최근 처음으로 SaaS를 샀습니다. 아기 타이즈를 파는 커머스에서 시작해 BTS 팬 선물 배송, 무인 아이스크림 매장, 음료 도매, 주방 자재 유통을 거쳐 도착한 곳이 소프트웨어예요.

그런데 인수한 다음에 한 일이 좀 특이합니다. 사람을 뽑는 대신 실리콘밸리 드라마 캐릭터 이름을 붙인 AI 에이전트를 아홉 개 세팅하고, 회사 운영 자체를 그 위에 올렸어요. 요즘 Y Combinator가 말하는 'AI 네이티브 컴퍼니'를 대형 스타트업이 아니라 소규모 인수 사업체에서 그대로 굴려 보고 있는 셈이죠. 『진양의 인수창업』을 쓰는 김지혁 님과 나눈 이야기입니다.

['빌더 조쉬' 유튜브 구독하러가기]

일곱 번의 인수, 그리고 처음 산 SaaS

Q. 어떤 일을 하고 계신지 소개 부탁드립니다.

『진양의 인수창업』이라는 뉴스레터를 운영하면서, 지금까지 누적으로 일곱 개 사업체의 영업권을 인수해 사업하고 있는 김지혁이라고 합니다. 그동안은 커머스나 무인매장처럼 조금 작은 소규모 사업체를 인수해서 키우는 일을 해 왔어요. 그러다 최근에 기회가 돼서 SaaS를 인수하게 됐고, 그걸 계기로 조쉬 님과 다시 한번 이야기 나누게 됐습니다.

Q. 원래는 여러 회사를 다닌 개발자셨는데, 인수 창업으로 넘어오신 계기가 있나요?

사업 자체에는 원래 관심이 많았어요. 엔지니어로 일하면서 창업도 여러 번 시도했고 플랫폼도 운영해 봤거든요. 그런데 몇 번 말아먹고 나서 든 생각이, 제로 투 원으로 새로 시작하는 사업은 리스크 계산이 너무 안 된다는 거였어요. 얼마를 넣으면 얼마쯤 돌아온다는 감이 아예 안 잡히는 구조인 거죠. 저도 나이가 들어가고 아이도 생기다 보니까, 리스크를 헤징할 수 있는 형태의 사업이 있지 않을까 고민하던 참이었어요. 그러다 겸사겸사 첫 인수를 하게 됐는데, 그게 생각보다 괜찮게 돼서 여기까지 오게 됐습니다.

Q. 첫 인수 아이템은 뭐였나요?

회사 다니면서 사이드로 시작한 거였는데, 아기 타이즈를 파는 커머스를 인수하는 걸로 시작했어요. 처음부터 "인수를 하자"고 정해 놓고 시작한 건 아니었어요. 회사를 그만두려면 돈이 어디선가 흘러야 하는데 뭐부터 해야 하지, 하고 고민하던 중에 후보군 중 하나로 올라온 거였죠. 그런데 보니까 매출은 괜찮은데 가격이 싼 거예요. 다만 그때 그런 조건으로 나온 매물이 커머스밖에 없었어요. 그래서 그러면 이걸로 한번 시도나 해 보자고 했습니다. 잘 안 되면 직장을 조금 더 오래 다니면 되니까, 그 정도 마음으로 들어간 거예요.

Q. 인수 금액은 어느 정도였나요?

5천만 원 이하로 인수했어요. 처음부터 큰돈을 넣고 시작한 건 아니었습니다. 결과적으로는 그 아기 타이즈 회사에 타이즈 커머스를 하나 더 붙여서 법인 하나로 만든 다음에 매각한 케이스가 됐어요.

Q. 그 뒤로 인수하신 사업체들은 지금 어떻게 정리됐나요?

무인 아이스크림 매장은 폐업으로 종결했어요. 매장이 하나 늘면 그만큼 리스크도 같이 늘어나는 구조여서, 좋은 사업은 아니라는 생각이 들더라고요. BTS 팬 대상 선물 커머스는 주로 캐나다나 미국 같은 해외로 배송이 나가는 제품이었는데, 그건 잘 매각해서 정리했습니다. 그다음에 인수한 게 B2B로 음료를 도매하는 회사, 그리고 소상공인 대상으로 주방 자재를 유통하는 회사예요. 이 두 개는 창고 하나에 세팅해서 굴러가게 만들어 놓은 상태입니다.

Q. 음료 도매는 직접 물류까지 하셨다고 들었어요.

네, 인수하러 갔더니 지게차를 몰아야 하더라고요. 그래서 지게차부터 빠르게 배웠습니다. 개발자가 제조사에 들어가서 음료를 싣고 있었던 거죠. 인수 창업은 이런 부분이 있어요. 사업체를 사면 그 사업체가 원래 하던 일이 그대로 제 일이 되니까요.

Q. 그러다 SaaS를 인수하게 된 계기가 궁금해요.

예전에 조쉬 님한테 "SaaS는 아마 인수 안 할 것 같다"고 말했던 가장 큰 이유는 너무 비쌌기 때문이에요. 멀티플(연간 이익 대비 인수 가격 배수)이 기본적으로 5년치, 싸도 3년치, 비싼 건 7~8년치까지 붙었거든요. SaaS는 10배, 20배를 부르는 데도 많고요. 그런데 저는 인수 창업을 할 때 가장 펀더멘털로 깔고 가야 하는 마인드셋이, 서면으로 말하는 리스크 관리라는 표현을 넘어선다고 생각해요. 내가 실제로 이 돈을 놓고 이걸 샀을 때 "그래서 회수 가능해?"라는 질문이 아주 강하게 깔려 있어야 한다는 거죠. 이 돈을 어떻게 회수할 수 있냐는 생각 때문에 그동안 SaaS를 인수 대상에서 뺐던 겁니다.

Q. 그 판단이 최근에 바뀐 이유는 뭔가요?

AI가 나오면서 개발, 디자인, 마케팅 역량이 전부 커모디티(commodity, 누구나 싸게 구할 수 있는 범용재)로 변했고, 앞으로 지식의 값이 0에 수렴할 거라고 믿는 사람이 많아졌잖아요. 그러다 보니 예상보다 저렴하게 나오는 매물이 생기더라고요. 그리고 기존에 열 명 정도로 운영되던 SaaS라면, AI가 발전할수록 그 열 명이 필요 없어질 확률이 크거든요. 그러면 인수하는 동시에 비용을 계산해 볼 수 있는 요소가 넓어진다는 의미니까, 상방은 훨씬 넓어졌는데 하방은 조금 더 안전해졌다고 봤어요. 그래서 SaaS도 인수 후보군에 넣자는 쪽으로 생각이 바뀌었습니다.

Q. 개발은 원래 하시던 거니까 괜찮았을 텐데, 그래도 걱정되는 지점이 있었나요?

오히려 개발이 가장 큰 걱정이었어요. 인수하고 나면 개발 인프라도 봐야 하고, 유지보수를 위한 개발도 해야 하고, 고객 니즈에 맞추려면 신규 기능도 계속 붙여야 하잖아요. 이미 정규화된 SaaS라도 소프트웨어 특성상 대응을 안 하면 도태되니까요. 그걸 다 하면서 나머지까지 커버할 수 있을까가 제일 큰 고민이었습니다. 개발이 가장 큰 병목이거든요.

Q. 마케팅이나 운영 쪽은 부담이 덜하셨나요?

네, 저는 원래 세일즈나 마케팅 쪽에 관심이 많은 개발자였어요. 그리고 세일즈나 마케팅은 기존에 하고 있던 형태를 최대한 흡수하는 방식이어서 크게 고민하지 않았습니다. 새로 만드는 게 아니라 돌아가던 걸 이어받는 일이니까요. 그렇게 어려울 거라고 보지 않았어요. 결국 남는 건 개발이었는데, AI가 발전하면서 그 비용이 엄청나게 저렴해졌으니 충분히 감당할 수 있겠다고 판단했습니다.

인수할 때 진짜 사는 것: 현금흐름

Q. SaaS를 인수한다고 하면 대체 뭘 넘겨받는 건가요?

코드를 넘겨받는다고 볼 수도 있고 결제 계정을 넘겨받는다고 볼 수도 있는데, 어떤 형태의 사업체든 인수할 때 가장 펀더멘털로 깔려야 하는 건 현금흐름을 인수하는 게 가장 비중이 커야 한다는 점이에요. 지금까지 유지돼 온 이익을 앞으로도 유지할 수 있다는 전제가 가장 중요하게 깔려 있어야 합니다. 앞뒤를 바꿔서 생각하는 분이 많은데, 코드베이스는 현금흐름을 위한 수단이지 목적이 되면 안 돼요. 코드를 샀으니 이제 뭘 만들지부터 고민하는 순간 순서가 뒤집히는 겁니다. 인수할 때는 현금흐름을 인수하는 게 가장 핵심이다, 이걸 일단 깔고 가야 해요.

Q. 그 현금흐름을 유지하려면 실제로 뭐가 다 넘어와야 하나요?

일단 그걸 유지하려면 코드베이스가 당연히 필요하고, 이 매출을 유지하려면 기존 고객 데이터베이스도 다 넘어와야 해요. 결제 모듈이나 PG(결제대행) 계약 같은 것도 다 넘어와야 하고요. 거래처가 있다면 거래처가 원가율을 결정하니까 거래처 정보도 전부 넘어와야 합니다. 하나라도 빠지면 인수한 다음 날부터 매출이 끊기거나 원가가 달라지는 항목들이에요. 그래서 저는 이 목록을 코드보다 먼저 확인합니다.

Q. 그럼에도 SaaS가 커머스보다 인수하기 어려운 지점이 있다면요?

이 매출을 유지하기 위해서 내가 알고 있어야 하는 정보의 양이 엄청나게 비대해요. 이 제품이 왜 이렇게 개발됐고 어떻게 변해 왔는지 히스토리를 다 머릿속에 갖고 있어야 하고, 신규 기능을 개발할 때 어떤 요소를 고려해야 하는지도 알아야 하고, "이건 실험해 봤는데 안 좋아서 그 방향으로 안 갔다" 같은 누적된 노하우도 굉장히 많거든요. 이런 걸 제대로 흡수해 오지 못하면, 앞사람이 이미 겪은 시행착오를 똑같이 반복하게 됩니다. 같은 실패를 돈과 시간을 다시 써서 재현하는 셈이죠. 이걸 어떻게 줄일 수 있을까가 이번 PMI(인수 후 통합)에서 가장 큰 과제 중 하나였어요. 커머스는 물건과 거래처가 실체로 남지만, SaaS는 그 노하우가 대부분 사람 머릿속과 대화 기록에만 있거든요.

Q. 그 방대한 히스토리를 실제로 어떻게 넘겨받으셨나요?

인수할 때 그 팀이 지금까지 운영되면서 쓰던 슬랙과 노션, 이 두 개를 같이 받았어요. 처음에는 이건 안 받아도 되겠다고 생각했는데, 하다 보니 이게 무조건 있어야 히스토리를 파악할 수 있겠더라고요. 그래서 노션이나 슬랙처럼 정규화되지 않은 데이터를 어떻게든 임베딩시켜서, 내가 물어보면 나보다 이 회사의 컨텍스트를 더 잘 알고 있는 AI를 만들자는 게 1번 과제였어요. 정리된 문서만 받는 게 아니라, 그동안 팀이 주고받은 대화 채널 자체를 통째로 넘겨받아 재료로 쓴 거죠. 히스토리가 너무 많아서 그걸 다 구두로 인수인계 받기에는 양이 감당이 안 되니까요.

Q. 파는 쪽 입장에서는 넘겨주기 꺼려질 수도 있는 정보잖아요.

맞아요. 제가 예전 에피소드에서도 자주 하는 말인데, 인수는 무조건 우호적인 양도자, 그러니까 파는 쪽을 잘 만나는 게 제일 중요해요. 이건 어쩔 수 없습니다. 가격이나 조건을 아무리 잘 협상해도, 넘겨주기 싫어하는 분을 만나면 정작 필요한 맥락은 못 받거든요. 슬랙과 노션을 통째로 넘겨준다는 건 그만큼 협조적인 분을 만났다는 뜻이기도 하고요.

제품 개선보다 계기판이 먼저

Q. 인수하고 나서 제품 개선이 아니라 내부 정비부터 하신 이유가 뭔가요?

인수를 여러 번 하다 보니 생긴 노하우인데, 보통 인수 직후에 뭔가 적극적인 의사결정을 많이 하면 나중에 후회하는 경우가 많더라고요. 그래서 파괴적인 기능 변경이나 의사결정은 최대한 안 하려고 노력하고 있어요. 단기적으로는 성장이 정체되는 것처럼 보일 수 있지만, 그 대가로 잃는 게 더 크다고 보는 거죠. 대신 인수하면 제일 먼저 하는 게 계기판을 만드는 일입니다. 운전으로 비유하면, 속도계 없이 운전하면 차는 무조건 사고가 나잖아요. 지금 이 사업이 몇 킬로로 달리고 있는지 모르는 상태에서 핸들부터 꺾는 건 위험한 일이에요.

Q. 계기판을 만든다는 게 구체적으로 어떤 작업인가요?

어떤 형태의 사업체든 기존 창업주가 보고 있던 지표가 뭔지를 무조건 다운로드받아요. 그분이 매일 어떤 숫자를 보면서 판단해 왔는지를 먼저 통째로 받아 두는 겁니다. 그다음에 우리가 앞으로 어떤 의사결정을 할지, 제품의 방향과 얼라인된 지표를 새로 만들기 시작합니다. 지표를 만들려면 결국 데이터가 수집돼야 하고 정량적인 기준이 필요하니까, 자연스럽게 데이터를 어떻게 적재하고 어떻게 시각화해서 의사결정에 쓸지를 항상 먼저 세팅하게 돼요.

SaaS는 이 지점이 정말 좋은 게, 보통 양도자분이 관리하시던 BI(Business Intelligence)나 데이터 구조가 이미 있어요. 모든 게 전산화돼 있어서 데이터를 빠르게 보고 의사결정할 수 있다는 게 SaaS 사업의 가장 큰 장점이기도 하니까요. 이번에는 창업자분이 메타베이스(Metabase)를 쓰면서 의사결정용 데이터를 이미 다 시각화해 두셨어서, 그걸 받아서 흡수하고 저희 것으로 변형해서 쓰고 있습니다.

Q. 기존 창업자의 지표를 그대로 쓰지 않고 변형하는 이유가 있나요?

목표가 다르기 때문이에요. 보통 기존 창업자분들은 성장을 위한 계기판을 만들어 놔요. 기능을 계속 찍어내서 신규 매출을 만들고 시장에 진입해야 한다는 목표를 갖고 계시니까요. 그런데 저희는 인수를 해서 현금흐름 방어가 최우선 과제거든요. 그러니 그 지표를 똑같이 따라가지 않아도 되는 상황이 되는 거죠. 대신 운영에 들어가는 시간을 줄이는 것 같은 게 첫 과제가 됩니다.

Q. 현금흐름을 유지하거나 올릴 수 있다고 판단하는 기준은 뭔가요?

저희는 그걸 매출 레버라고 표현을 많이 해요. 인수하면서 누구나 하는 생각이 "이것만 손보면 매출을 많이 올릴 수 있을 것 같은데", "내 인맥 써서 마케팅만 조금 얹으면 올라갈 것 같은데" 같은 거예요. 그런데 그게 제가 말하는 '똥촉'이거든요. 그때 어떤 파괴적인 의사결정을 하고 나서, 한참 뒤에야 잘못된 직감이었다는 걸 알게 되는 구간이요.

보통 기존 창업자분들이 대부분 다 해 보고 실험해 본 경우가 많기 때문에, 내가 뻔하게 "이렇게 하면 될 것 같은데" 싶은 것 중에 안 되고 있는 건 안 하고 있는 이유가 있다고 깔아 놓고 가는 게 마음이 편하더라고요. 사업을 하다 보면 비슷한 업을 하는 대표님들이 왜 저렇게 하시나 싶을 때가 있는데, 나중에 보면 저렇게 한 이유가 항상 있잖아요. 인수할 때도 똑같더라고요.

Q. 그래도 업사이드가 없으면 인수할 이유가 없잖아요. 이번 건은 어땠나요?

업사이드는 무조건 있죠. 없으면 살 이유가 없으니까요. 있는데, 그걸 첫 6개월에서 1년 안에 실행하면 안 된다는 의미예요. 비용 쪽은 이미 답이 보였어요. 사람이 하던 운영을 AI 에이전트로 돌리면 되겠다는 그림이 있었으니까요. 매출 쪽 레버도 분명히 존재하지만, 그건 이 사업을 충분히 이해한 다음에 당겨도 늦지 않다고 봅니다.

AI 직원을 채용하게 된 시작점

Q. SaaS 인수하고 나서 AI 직원 다섯 명을 채용하고 키우고 있다는 글을 쓰신 적이 있어요. 어떻게 시작하셨나요?

사실 이걸 하려고 SaaS를 인수한 건 아니었어요. 인수하고 PMI를 하면서 실사를 진행하는데 질문이 너무 많은 거예요. 그래서 이 질문을 풀어 주는 애를 하나 만들자로 처음 시작했어요. 슬랙 로그를 다 넣어 주고, 노션 MCP를 연결해 주고, 제가 물어보면 답해 주는 챗봇으로 출발했습니다. 처음에는 이름도 제라드가 아니었고, 그냥 이것저것 물어보는 봇이었어요.

Q. 그 봇을 파는 쪽과 함께 있는 채널에도 넣으셨다고요?

네, 제가 만들어서 양도자분이랑 같이 있는 채널에 초대를 했어요. 그 앞에서 물어보게 한 거죠. 대표적인 게 에러 로그였어요. 제품을 넘겨받고 나서 가장 큰 리스크 중 하나가, 인수하고 나서 버그가 났는데 그 버그를 못 고치면 어떡하나 하는 부분이거든요. 그래서 인수 기간 동안은 기존 창업자분들한테 하나하나 계속 물어봤어요. 이건 무슨 버그냐고요. 버그 나오면 설명 좀 해 달라고 부탁까지 드렸고요.

Q. 그 질문을 봇에게 넘기신 거군요.

네, 이게 너무 소모적인 것 같더라고요. 버그가 뜰 때마다 사람한테 물어보고 답을 기다리는 구조는 인수 기간이 끝나면 그대로 끊기잖아요. 그래서 이럴 거면 그냥 기존 창업자보다 이 버그에 대해 더 잘 알게 만들자고 생각했어요. 코드베이스를 이해하고 있는 상태로 라이브 DB 접속 권한까지 있으면, 누가 어떤 원인 때문에 겪은 이슈고 어떻게 고치면 된다는 답을 충분히 할 수 있겠다고 판단했거든요. 그래서 이 친구를 에러 로그 채널에 초대했습니다.

지금은 사실상 PM 역할을 하고 있고, 데이터에 대한 모든 접근 권한을 갖고 있어요. 심지어 라이브 데이터에 쿼리를 넣을 수 있는 권한까지 있습니다. 의사결정을 할 때 필요한 컨텍스트를 전부 갖고 있는 애로 포지셔닝하고 있는 거예요.

Q. 지금 그 에이전트는 에러가 뜨면 어떤 일을 하나요?

무슨 이슈인지 확인하고 분석해서 어떻게 고치면 좋을지 정리한 다음, 노션의 개발 요청 관리 문서함에 넣어 달라고 요청하면 원인을 파악해서 DoD(Definition of Done, 이 작업이 끝났다고 볼 수 있는 완료 기준)까지 만들어 문서화를 시켜요. 핵심은 원인이 뭐고, 이걸 어떻게 재현할 수 있고, 수동으로는 어떻게 고칠 수 있는지를 기획자 입장에서 작성하는 거예요. QA에서 쓰는 테스트 케이스와 비슷한 형태죠. 어차피 이건 제가 읽으려고 만드는 문서가 아니거든요. 이렇게 던져 놓으면 개발 요청 리스트가 쌓이고, 예전 것도 있고 새로 생긴 것도 있는 상태가 됩니다. 이게 실사를 하면서부터 시작된 첫 번째 기능이었어요.

Q. 기존 창업자의 판단 로그를 물려받아 기준으로 삼은 셈인데, 처음부터 이렇게 설계하고 만드신 건 아니었네요.

네, "이걸 만들자" 하고 시작한 게 아니었어요. 하다 보니까 내가 데이터를 주고 권한을 주면 나보다 더 좋은 의사결정을 할 수 있겠다 싶어서, 제라드한테 MCP를 끼워 주고 임베딩시켜서 의사결정을 시켰어요. 그러다 보니 이것도 주면 이것도 잘하겠네, 이것도 주면 이것도 잘하겠네, 이렇게 흘러간 게 많습니다. 결과적으로는 기존 창업자가 옆에 없어도 그때 그 판단 기준을 그대로 꺼내 쓸 수 있는 상태가 된 거죠.

제라드, 길포일, 얼릭: 아홉 개의 프로필

Q. 제라드 말고 다른 에이전트도 두고 계신가요?

지금은 여러 명으로 나눠 놨는데, 처음에는 제라드 한 명한테 다 몰아줬어요. 어차피 코드베이스도 갖고 있으니까 커밋도 넣고, 할 수 있는 걸 다 주면 괜찮겠다고 생각했어요. 그런데 이 친구가 알고 있는 양이 방대해질수록 의사결정이 마음에 안 들어지더라고요. 컨텍스트가 너무 넓으니까요. 같은 모델을 쓰는데도 뭔가 멍청해진 것 같았어요.

컨텍스트가 방대해지면 정확한 답변을 못 할 확률이 커진다는 건 뻔한 얘기잖아요. 그래서 역할을 명확하게 분리하고, 이 역할이 안 갖고 있어도 되는 컨텍스트는 날려야겠다고 판단했습니다. 사람으로 치면 한 명한테 전 부서 일을 다 맡기다가 직무를 나눈 셈인데, 그렇게 두 번째로 만든 게 개발자 페르소나였어요.

Q. 이름은 어떻게 붙이셨나요?

HBO의 실리콘밸리라는 드라마를 좋아하는데, 거기서 제라드가 PM 역할이거든요. 제 뉴스레터 이름도 그 드라마에 나오는 진양에서 가져온 거고요. 그래서 두 번째로 만든 개발자 페르소나에는 그 드라마의 개발자인 길포일이라는 이름을 붙였습니다.

Q. 개발 쪽은 어떤 구조로 돌아가나요?

길포일은 헤르메스의 칸반 기능을 써서 자기가 오케스트레이터 페르소나를 맡고 있어요. 그 밑에 실제로 개발하는 개발자 페르소나가 하나 있고, 리뷰어가 두 명 있습니다. 하나는 클로드를 쓰는 리뷰어, 하나는 오픈라우터에서 엔비디아 모델을 쓰는 리뷰어예요. 빌드는 코덱스로 하고, 클로드로 리뷰하고, 오픈라우터의 무료 모델로 한 번 더 리뷰합니다.

Q. 리뷰어를 두 명 두신 이유가 있나요?

한 명은 조금 더 보수적인 리뷰고, 한 명은 조금 더 진보적인 리뷰예요. 보수적인 쪽은 이 기능이 정상적으로 동작하는지만 보고, 진보적인 쪽은 거기서 더 나아가 기능 개선의 여지까지 제안할 수 있는 형태고요. 게이트키핑은 오픈라우터 쪽이 합니다.

조금 덜 똑똑한 모델이 보수적인 의사결정을 하게 하고, 더 머리 좋은 모델이 진보적인 의사결정을 할 수 있게 세팅해 봤어요. 다만 이게 좋은 방식인지는 몰라요. 하다 보니 이렇게 된 거고, 오픈라우터 리뷰 세션과 클로드 리뷰 세션을 하나하나 다 열어 보지는 않아서 둘이 어떤 관계인지는 아직 정확히 모르겠습니다. 다행히 저희 제품은 보안 쪽으로 크게 이슈될 만한 게 없어서 이 상태로 굴려 보고 있어요.

Q. 실제 업무는 어떤 순서로 흘러가나요?

PM인 제라드가 저한테 개발 스펙을 다 말해 주면, 제가 그걸 이해하고 흡수한 다음 노션 문서 형태로 한 번 정제해요. 그러면 그걸 개발 쪽인 길포일한테 넘겨 줍니다. 최근에는 제라드가 올려 둔 버그 티켓을 두고, 본 앱이니까 조심스럽게 작업해야 한다고 전제를 깔면서 "이 문서 보고 나한테 필요한 게 있으면 물어보고, 없으면 그냥 PR 한번 넣어 봐라"라고 요청한 케이스가 있었어요. 개발이 끝나면 PR이 올라오는데, 그 PR은 제가 최종적으로 검토합니다. 제가 개발자다 보니 보안 이슈나 이상한 부분이 없는지 보는 거죠.

Q. 요즘은 PR 리뷰를 AI에 맡기는 분들도 많은데, 직접 하시는 이유가 있나요?

아직 못 믿어서요. AI가 쓴 코드를 라이브 서비스에 그대로 넣는 건 100% 믿을 수가 없더라고요. 그래서 PR 리뷰만 따로 하는 에이전트도 두고 있지만, 마지막에는 제가 한 번 더 봅니다. 다만 제가 리뷰만 하지, 이거 고치라고 요청한 적은 한 번도 없어요. 너무 잘하긴 하더라고요.

Q. 인수한 제품은 몇 개인가요?

인수할 때 받은 앱이 세 개예요. 메인 앱이 유료 전환이 일어나고 있는 서비스고, 나머지 두 개는 무료 유저만 있는 서비스입니다. 현금흐름을 만드는 건 사실상 메인 앱 하나인 셈이죠. 이 세 개에 대한 컨텍스트를 다 먹여서 저번 주부터 본격적으로 PR을 넣기 시작했어요.

Q. 세 번째인 콘텐츠 마케터는 어떤 역할인가요?

회사나 인수한 자산의 방향, 예를 들어 뉴스레터를 어떤 방향으로 끌고 갈지, 어떤 목적에 어떻게 도달할지에 대한 토론은 제가 제라드랑 많이 하거든요. 제라드가 그 컨텍스트를 많이 갖고 있으니까요. 최근에는 인스타그램 계정을 운영하고 싶은데 어떤 목적을 주고 어떤 식으로 키우면 좋겠냐고 물었더니, 제라드가 노션 문서를 만들어 줬어요. 저희가 갖고 있는 다른 서비스의 매출 레버를 어떻게 당기면 좋을지에 대한 질문이었는데, 답으로 목표를 몇 개 세워 주더라고요.

그중 하나가 SNS 계정을 운영하고 탑 콘텐츠(처음 들어오는 사람을 넓게 받아 주는 입구 역할의 콘텐츠)를 만들라는 조언이었거든요. 그래서 그 조언을 실행할 수 있는 애를 따로 만들었습니다. 전략을 짜는 쪽과 실행하는 쪽을 나눈 거예요. 이름은 얼릭 바크만이고, 드라마에서 홍보와 마케팅을 맡는 캐릭터입니다.

Q. 그 친구도 같은 구조인가요?

네, 똑같이 오케스트레이터이고 그 밑에 리서치를 하는 봇, 라이팅을 하는 봇, 리뷰를 하는 봇이 있어요. 서브 에이전트 세 개로 개발 쪽과 같은 3단 구도입니다. 만드는 애와 검토하는 애를 나눠 놓는 형태는 개발이든 콘텐츠든 똑같이 가져가고 있어요. 그래서 저희는 지금 3×3으로 총 아홉 개 프로필을 쓰고 있는데, 실제로 저랑 직접 대화하는 건 오케스트레이터 세 개뿐이에요. 얼릭은 아직 개선 핑퐁을 하고 있는 단계인데, 제라드가 만들어 준 콘텐츠 방향성에 맞춰서 계속 만들면서 레퍼런스를 쌓고 있습니다.

1단계 쿼리어블: 회사를 검색 가능하게

Q. 이 구조를 AI 네이티브 컴퍼니 OS로 정리하면 첫 단계가 쿼리어블인데, 어떻게 세팅하셨나요?

쿼리어블(queryable, 회사 안의 정보를 AI가 언제든 조회할 수 있는 상태)한 상태를 만든다는 건, 결국 진실로 취급될 수 있는 자료가 어디에 있느냐를 정하는 일이에요. 에이전트 입장에서 SOT(Source of Truth)가 어디 있느냐죠. 같은 질문에 대해 슬랙과 노션의 답이 다르면 어느 쪽을 믿을지부터 정해 줘야 하니까요. 저희 같은 경우는 그게 노션이랑 슬랙에 엄청 많이 있었고, 프로젝트는 리니어(Linear)에 저장돼 있고, 실제 서비스 지표를 보려면 메타베이스를 조회해야 했어요. 제가 만든 구조도로 치면 이게 L3 레이어인데, 아래쪽 L1과 L2를 연결해 주는 구간이에요.

Q. 그 자료들을 실제로 어떻게 연결하셨나요?

임베딩한 데이터를 검색할 수 있게 해 주고, 흩어진 데이터를 한 번 정리한 다음에, 각각의 에이전트한테 어떤 자료를 연결해 놓을지를 정의합니다. 모두에게 전부 연결하는 게 아니라, 이 역할에는 이 자료까지만 붙인다고 정하는 거예요. 결국 회사의 모든 의사결정에 필요한 정보를 전산화시키는 작업입니다.

Q. 그렇게 연결해 놓으면 버그 하나가 들어왔을 때 어떤 순서로 흘러가나요?

PM인 제라드한테 물어보면 먼저 데이터베이스를 조회해서 어떤 사용자인지 확인해요. 그다음 그 사용자가 겪은 문제를 코드베이스에서 뒤져서 어떤 라인에서 에러가 터지는지 확인합니다. 그걸 조합해서 이미 알고 있는 버그인지 판단하고, 최종적으로 노션에 버그 픽스 리포트를 내요. 기존 창업자한테 "이거 무슨 버그냐"고 하나하나 물어봐야 했던 일이, 자료가 다 연결돼 있으면 질문 한 번으로 정리되는 거죠. 이 플로가 만들어지는 게 쿼리어블입니다.

Q. 그 데이터를 계속 쌓아 나가는 건 어떻게 하고 계신가요?

랭퓨즈(Langfuse, AI 에이전트와 주고받은 대화와 실행 기록을 남겨 주는 관측 도구)를 쓰고 있어요. 저희와 에이전트가 나눈 모든 대화가 일단 DB에 저장되고, 그중 의사결정에 중요했던 자료는 PM이 포스트그레스(PostgreSQL)로 빼냅니다. 크론(cron)으로 일주일에 한 번씩 에이전트 리뷰 세션을 돌리면서, 중요했던 의사결정이나 나빴던 것들을 골라내 나중에 기억할 수 있게 만들어요. 전부 다 남기면 오히려 참조할 때 방해가 되니까, 남길 것을 주기적으로 거르는 셈이죠. 거기에 사람이 피드백을 붙여 주고 있고요.

Q. 랭퓨즈나 포스트그레스 같은 스택은 어떻게 선택하셨어요?

이 구축의 대부분을 제라드가 하고 있어서, 사실 제가 결정한 게 아니에요. 이게 가장 범용적이니까 추적을 잘하려면 랭퓨즈를 써야 하고, 에이전트 대화 적재는 지금 상태에서는 포스트그레스가 제일 낫다고 에이전트가 스스로 판단한 거죠. 저는 인수한 서비스가 이미 AWS 인프라를 쓰고 있으니 그걸 최대한 활용해서 짜라는 정도로 가이드만 잡아 줬어요. 양도자분이 쓰던 스택을 그대로 이어받은 게 아니라, 이 구조는 인수하고 나서 새로 깔린 겁니다. 실제로 이 문서의 업데이트도 지금 제라드가 하고 있고, 자기가 스스로 우리가 얼마나 AI 네이티브한 회사인지를 평가하더라고요. 저보다 잘합니다.

Q. 혼초라는 것도 붙이셨다고요.

혼초(Honcho, 에이전트가 사용자와의 대화를 계속 분석해 장기 기억으로 쌓아 주는 메모리 서비스)는 헤르메스 프레임워크에서 가장 밀고 있는 개념인 것 같아요. 장기 메모리를 담당해 주는 외부 서비스 레이어더라고요. 저는 이건 좀 블랙박스로 취급하고 있는데, 장기 메모리를 가져가면 각 프로필마다 별도로 메모리를 쌓을 수 있어요. 제라드가 쌓는 기억과 길포일이 쌓는 기억이 섞이지 않는다는 뜻이죠. 나랑 지금까지 어떤 대화를 했고 어떤 형태로 답변하는 게 좋을지를 스스로 계속 돌리더라고요. 실제로 정확도 개선에 도움을 주냐고 물어봤는데, 도움은 된다고 하긴 합니다.

Q. 임베딩은 얼마나 자주 다시 하나요?

문서 성격에 따라 나눠 놨어요. 한 번 임베딩해 놓고 안 바뀌는 문서들은 폴더를 따로 만들어 두고, 사람이든 AI든 계속 수동으로 업데이트가 들어가는 문서함은 별도로 있어요. 제품 시장조사처럼 매주 갱신되는 문서는 제라드가 매주 다시 임베딩을 시킵니다.

매일 저랑 에이전트가 대화하면서 새로 업데이트되는 회사 컨텍스트가 있잖아요. 그 안에 있는 문서들은 매일 색인해요. 그래야 다음 날 헛소리를 안 하니까요. 반면 랭퓨즈에 쌓인 대화를 색인하는 건 일주일에 한 번만 진행합니다. 대화는 모두 실시간으로 적재되지만, 그중 무엇을 기억으로 남길지는 주 단위로만 거르는 거예요. 노션 문서를 색인하는 애가 따로 있고, 랭퓨즈 데이터만 수집하는 건 헤르메스의 크론 기능이 하고 있습니다.

2단계 클로즈드 루프, 3단계 셀프 임프루빙

Q. 다음 단계인 클로즈드 루프는 뭔가요?

개념을 이해하는 데 시간을 좀 썼는데, 대표적인 클로즈드 루프 시스템이 온도계더라고요. 온도가 올라가면 자동으로 내려가게, 떨어지면 올라가게 피드백이 돌아가도록 세팅돼 있는 거요. 결국 내가 어떤 인풋을 넣었을 때 산출물이 나오고, 그 산출물이 다시 인풋으로 들어가게 만들면 그게 클로즈드 루프라고 이해하고 있어요.

제가 정의했을 때 클로즈드 루프와 셀프 임프루빙의 경계가 가장 명확하게 드러나는 구간은 제품 데이터를 뽑아내는 쪽이고요. 아까 말한 매주 크론이 도는 과정, 그러니까 노션 문서를 색인하고 랭퓨즈 대화 중 중요했던 것을 다시 집어넣는 작업은 사실 쿼리어블한 상태와는 별개예요. 자료를 조회 가능하게 만드는 일과, 결과물을 다시 재료로 되돌리는 일은 다른 층이니까요. 그래서 저는 저 작업이 오히려 클로즈드 루프 쪽에 가깝다고 봅니다. 이 친구가 뱉어낸 값 중에서 그나마 괜찮았던 걸 다시 수집해서, 나중에 의사결정할 때 노션 문서를 MCP로 조회해서 참조할 수 있게 만들어 준 거니까요.

Q. 좋았는지 나빴는지는 누가 판단하나요?

그건 사람이 합니다. 에이전트가 실행한 로그는 다 집계돼서 랭퓨즈에 쌓이고, 그걸 포스트그레스에 집어넣은 다음에 저희가 매주 직접 체크해요. 괜찮았던 건 체크 표시를 하고, 이 답변은 별로였다 싶은 건 X 표시를 합니다. 슬랙 이모지 반응을 동기화해 두는 구간이 있어서, 제가 대화하면서 안 좋았던 것에는 이모지로 세게 표시를 하거든요. 새로운 이모지가 달려 있으면 이 친구가 그걸 보고 긍정으로 반영할지 부정으로 반영할지를 판단해요. 별도 평가 도구를 여는 게 아니라, 일하던 자리에서 클릭 한 번으로 피드백이 남는 구조인 거죠. 그러면 그 결과가 단기 메모리에 저장되는 것도 있고, 프롬프트를 직접 수정하는 데까지 가는 것도 있습니다.

Q. 에이전트가 제대로 돌고 있는지 감시해 주는 회사들도 생기고 있어요. 어라이즈 AI 같은 곳을 두고 에이전트 CCTV라는 표현도 쓰던데요.

그런 도구가 있다고 해도, 저는 애초에 AI 전문가가 아니어서 정확히는 모릅니다. 다만 클로즈드 루프 구조를 만드는 일 자체는 사람이 해야 되는 영역이 꽤 많다고 생각해요. 이 친구가 뱉어낸 값을 다시 잘 참조하게 만들려면, 중간에서 누군가 이건 좋았고 이건 나빴다고 말해 줘야 하거든요. 나중에 그 감시 역할을 다른 서비스가 대신하더라도, 그 판단 자체는 결국 제가 계속 수동으로 해 줘야 하는 거고요. 그걸 하기에 슬랙이 굉장히 좋은 환경이라 매주 리뷰를 돌리고 있습니다. 기술은 많은데, 결국 저랑 동업자가 사람으로서 어떻게 개입해서 이걸 닫힌 구조로 만드냐가 중요한 요소인 것 같아요.

Q. 그렇게 모인 피드백은 어디에 쓰이나요?

긍정 쪽으로는 스태틱 프롬프트 리파인먼트(정적 프롬프트 개선)라는 게 있어요. 일주일에 한 번 리뷰를 하고 나면, 그 결과로 이 친구가 직접 자기 MD 파일을 건드립니다. 자기가 연결돼 있는 SOUL.md랑 AGENTS.md 파일을 스스로 업데이트해요. 이 파일들이 에이전트의 성격과 작업 규칙을 담고 있는 문서라, 여기가 바뀌면 다음 주부터 일하는 방식이 바뀌는 겁니다. 제가 리젝트한 것들은 다 빼내고 재사용 가능한 교훈 중심으로 반영해서, 메모리 파일을 업데이트하라고 시키는 거죠. 이게 셀프 임프루빙의 약식 구현이에요.

Q. 나머지 셀프 임프루빙은 어떻게 처리하고 계신가요?

기본적으로 많은 부분을 헤르메스에 위임했어요. 프레임워크가 발전할수록 이 레이어는 알아서 좀 발전할 거라고 생각하고 있거든요. 대표적인 게 툴과 스킬인데, 헤르메스를 쓰다 보면 이 친구가 스스로 "이런 스킬 있으면 좋겠네, 이거 지금까지 여러 번 반복했으니까 스킬로 만들게" 하는 구간이 많아요. 반복 작업을 자기가 알아서 절차로 굳혀 두는 거죠. 헤르메스 덕분인지 모델 자체가 해 주는 건지는 모르겠는데, 쓰다 보면 스킬로 만들어 주고 툴로 만들어 주는 경우가 꽤 많더라고요. 제가 직접 뭘 안 해도 헤르메스를 씀으로써 딸려온 기능들이라, 이 레이어는 프레임워크가 좋아질수록 저절로 같이 좋아질 거라고 보고 있어요.

Q. 그러면 사람이 반드시 해야 할 일은 뭐가 남나요?

셀프 임프루빙은 데이터만 잘 넣어 주면 되고, 제가 직접 해야 하는 건 인간이 개입해서 뭐가 좋고 뭐가 나쁘다고 말한 걸 다시 에이전트한테 넣어 주는 구간, 그것만 있는 것 같아요. 나머지는 다 그걸 하기 위한 수단인 것 같고요. 쿼리어블하게 만드는 것도, 로그를 쌓는 것도, 결국 그 판단을 제때 정확하게 넣어 주기 위한 준비 작업인 셈이죠.

달성률 30%, 지금 병목은 저입니다

Q. 지금은 일이 어떤 식으로 시작되나요?

제가 "오늘 뭐 하자"라고 시작을 걸고 있어요. 아침에 일어나서 버그 티켓 이거 이거 고치자, 콘텐츠는 이렇게 가자, 이런 식으로 대화를 시작하는 거죠. 그 부분은 일부러 자동화시켜 놓지 않았어요. 하루를 여는 의사결정 자체는 아직 제가 합니다.

Q. 그럼 에이전트가 스스로 판단하는 영역은 어디까지인가요?

자기 내부 답변의 정확도에 대해서만 스스로 계산하고 있어요. 전략이나 자본 배분, 어떤 프로젝트를 이번 2주 동안 시작할지 같은 최종 승인은 제가 다 하고 있고요. "어디로 가야 하지"는 제가 말하고, "어떻게 해야 하지"부터는 PM한테 맡기는 구조입니다. 크론으로 돌아가는 건 내부 개선 루프와 셀프 임프루빙 쪽이에요.

Q. 버그 같은 건 자동으로 처리해도 될 것 같은데, 왜 아직 안 하시나요?

지금 병목이 어차피 저거든요. PR도 제가 다 보고 있으니까, 앞단이 아무리 자동으로 돌아가도 결국 제 앞에서 줄을 서게 돼요. 그러면 자동화한 의미가 없죠. 아직 이 친구를 완전히는 못 믿겠고, 계속 개선해 나가는 중이기도 하고요.

Q. Y Combinator의 AI 네이티브 컴퍼니 세션에는 CS가 들어오면 크론으로 자동 개선해서 PR까지 올리고 고객 회신까지 끝내 버린다는 사례도 나왔어요. 그 방식을 아직 도입하지 않으신 이유가 있나요?

큰 이유 중 하나는 저희 인프라가 보안을 하나도 신경 쓰지 않은 상태라는 거예요. 지금은 저희만 쓰는 구조라 괜찮은데, 엔드포인트 자체를 열어 놓고 자가 개선까지 다 돌리게 만들면 공격의 여지 같은 것도 고려해야 하잖아요. 그러면 또 머리 아파지고요. 저는 지금 인수한 자산을 잘 운영하겠다는 목적으로 이걸 만들고 있어서 상대적으로 속도가 느린 편이에요. 매출을 더 잘 만들고 다음 인수를 잘하고 운영하는 데 포커스가 있지, 이건 수단이거든요.

Q. AI 네이티브 OS는 몇 % 정도 달성된 것 같으세요?

한 30% 정도요. 그중에서 쿼리어블은 꽤 많이 된 편이에요. 더 추가해야 할 건 저랑 동업자가 구두로 하는 회의들인데, 그렇게 오간 의사결정은 지금 하나도 적재를 안 하고 있거든요. 그것만 올리면 쿼리어블은 거의 끝날 것 같습니다.

Q. 그건 금방 되겠는데요.

그게 어떻게 해야 효율적일지 확신이 안 서서 안 하고 있어요. 형식적으로 회의록을 남기는 건 할 수 있는데, 그렇게 쌓인 기록이 실제로 의사결정에 쓰일지가 아직 확신이 안 서거든요. 일단 적재는 시켜 놔야 하니까 최대한 슬랙으로 모든 대화를 하고 슬랙에 남겨 놓고는 있습니다. 효율성에 대해서는 아직 고민 중이에요. 저는 어차피 이 분야의 프런티어가 아니다 보니, 열심히 제 사업 하면서 프런티어들이 길을 뚫어 놓으면 "셀프 임프루빙 이렇게 하면 되겠네" 하고 당겨 오려고 생각하고 있어요.

Q. 다음 목표는 어떻게 되시나요?

단기 목표는 SaaS를 두 개 정도 더 인수하는 겁니다. 지금 갖고 있는 이 시스템을 바탕으로 최대한 자동화를 해 보려고요. 다만 순서가 있어요. 실제로 이 AI 시스템이 기존에 열 명에서 운영하던 걸 한두 명이 운영할 수 있게 만드는지를 먼저 검증해야, 다음 인수가 의미가 있거든요. 그 전에 개수부터 늘리면 예전에 매장 늘리다 리스크만 같이 늘린 것과 똑같아지니까요. 그래서 당분간은 그 검증을 위한 실험을 계속 진행할 것 같습니다.

소중한 노력이 들어간 글을 널리 알려주세요. 

이 기사가 좋으셨다면, 보상을 해주세요. 

가장 좋은 보상은 ‘조쉬의  뉴스레터 구독’입니다. :) 

구독을 하시면 100개의 1인 창업가 데이터베이스를 발송해드립니다.

[구독하러 가기]