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

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

[구독하러 가기]

요즘 AI 네이티브 컴퍼니라는 말을 많이 들어요. 그런데 실제로 어떻게 생겼는지 보여주는 팀은 드뭅니다. 대부분 "우리 팀도 AI 쓰고 있어요" 정도에서 멈추거든요.

델타소사이어티의 이웅재 님은 조금 다릅니다. 3명짜리 VC 팀 전체를 깃허브 레포지토리 위에 올려놓고, 의사 결정 문서부터 프로덕트 배포까지 클로드 코드 하나로 돌리고 있어요. 미팅 녹음본을 AI가 소화하고, 트리아지(할 일 분류)에서 에이전트가 스스로 태스크를 가져가는 구조까지 만들었습니다.

이 사람이 어떻게 여기까지 왔는지, 그 구체적인 이야기를 들어봤어요.

개발자가 만든 새로운 형태의 VC

Q. 간단한 자기소개 부탁드립니다.

한 10년 정도 프로덕트 개발을 한 개발자예요.

인썸이라는 스타트업 전문 외주 개발사에서 30여 개 프로덕트를 런칭해 본 경험이 있고, 그다음에 이오(EO)라는 스타트업 미디어 회사의 첫 번째 개발자로 입사해서 이오 플래닛, 이오 스쿨 같은 서비스들을 개발했습니다. 지금은 델타소사이어티라는 VC를 두 명의 VC와 함께 만들어 가고 있어요.

Q. 델타소사이어티는 어떤 곳인가요? 일반적인 VC와 다른 점이 있다고 들었는데요.

저희는 VC인데 로직이 좀 다릅니다. 보통 VC는 스타트업에 돈을 투자해서 지분을 사오는 구조잖아요. 저희의 큰 가설은 'AI 시대에는 스타트업을 하는 데 큰 돈이 필요하지 않을 것이다'라는 거예요. AI 에이전트들이 많은 역할을 해줄 거라는 가설이 하나 있었습니다.

대표적인 사례로 러버블(Lovable) 같은 경우도 2025년 초까지만 해도 소수 정예였다고 알고 있어요. 미드저니(Midjourney)도 오랫동안 소수 정예로 큰 기업 가치를 만들어낸 대표적인 사례라고 보고 있습니다. 저희는 앞으로 이런 사례들이 점점 더 많아질 거라고 생각하고, 스타트업들에게 필요한 건 돈이 아니라 다른 것일 거라는 가설을 가지고 새로운 형태의 VC를 만들어 가고 있어요.

Q. 돈이 아니라면, 스타트업에게 무엇이 필요하다고 보시나요?

지식과 네트워크라고 생각했어요. 그래서 지식을 중심으로 커뮤니티를 조성해서, 같은 고민을 하시는 분들을 모아서 좋은 기회를 만드는 방향으로 계속 모델을 만들고 있습니다.

Q. 구체적으로 어떤 프로그램들을 운영하고 계신가요?

몇 가지 프로그램이 있는데요. 가장 최근에 했던 AI 네이티브 캠프도 그중 하나입니다. 클로드 코드를 기반으로 일하는 걸 어떻게 하면 더 잘할 수 있을지 계속 고민을 했었거든요. 내부에서 각자 방법론들이 있었는데, 그런 분들 사이에서 갈증이 꽤 많았어요. 그래서 "우리끼리 꽁꽁 싸매고 있지 말고 같이 고민하자, 같이 잘되자" 하는 컨셉으로 저희가 가지고 있는 지식을 코스로 공개하고, 같은 고민을 하시는 분들이 와서 같이 문제를 해결해 보는 코스를 만들었습니다.

이거 외에도 AX 리서치 클럽이라든지 GTM(Go-To-Market) 리서치 클럽 같은 것들도 운영하고 있어요. 새로운 시대에 큰 변화를 맞이하고 있는 주제들에 대해서 여러 분들과 모여서 각자 당면한 상황들을 교류하고 있는 상황입니다.

깃허브 위에 회사를 올려놓다

Q. AI 네이티브 컴퍼니를 만들어 가고 계신다고 들었는데, 어떻게 시작하게 되셨나요?

솔직히 작은 팀들은 엄청나게 기민하게 움직여야 되잖아요. 그러다 보니까 의사 결정들이 빠르게 일어나요. 어제 했던 의사 결정이 오늘 뒤집히는 경우도 허다하고, VC라는 업 자체가 다양한 컨텍스트(맥락)들이 한꺼번에 진행되는 경향이 있어요. 그러다 보니까 "우리가 어제 이 의사 결정을 했는데 이거는 어디어디에 영향을 미치는지"도 파악이 안 되고, 계속 컨텍스트가 미싱(누락)이 되더라고요.

나중에 진짜 큰일 나겠다 싶어서, 우리가 의사 결정했던 내용들을 리파이(정제)해서 정리하고, "여기에 결정된 내용들만 결정됐다고 생각하고 움직이자"라는 합의를 했습니다. 마치 프로그램 배포를 하면 라이브 서버에 배포돼 있는 코드가 의사 결정의 결정체인 것처럼, 우리 의사 결정도 그런 형태로 라이브되고 있는 코드라고 생각하고 여러 문서로 저장을 해 놨어요.

Q. 그 의사 결정 문서를 어디에 저장하셨나요? 깃허브인지, 노션인지 궁금합니다.

처음에는 호기롭게 깃허브를 시도했죠. 깃허브라는 개념이 개발자들한테는 익숙하지만 다른 분들한테는 너무 어려운 개념이더라고요. 이상적으로는 깃허브의 풀 리퀘스트(Pull Request, 코드 변경 사항을 검토하고 병합하는 과정)라든지 커밋(Commit, 변경 내역을 기록하는 단위) 같은 개념들을 활용하고 싶었는데, 이것들을 고려하면서 업무까지 하는 게 너무 힘들었어요. 그래서 일단 노션으로 후퇴했습니다.

그래도 컨텍스트를 매번 복사 붙여넣기 하는 작업 자체가 번거롭기 때문에, 클로드 코드에 익숙한 사람들은 클로드 코드를 기반으로 노션의 컨텍스트를 MCP(Model Context Protocol, AI가 외부 도구와 연결되는 프로토콜)로 연결해서 당겨와서 일하는 방식으로 했었어요.

Q. 결론적으로는 깃허브로 완착이 됐나요?

네. 결국에는 지금 모두가 깃허브 베이스로 일을 하고 있습니다. 이게 개발자로서의 자존심이라고 해야 되나, 방어 기제라고 해야 되나... 이것들을 내려놓았어요. 브랜치(Branch, 기존 코드와 분리해서 실험적인 수정을 하는 기능)라는 개념이 있는데, 이런 추가적인 개념을 모두 버렸습니다. 메인 브랜치 하나에다가 모두 다 작업한다. 그러면 커밋하고 푸시(Push, 변경 사항을 서버에 올리는 것)하는 게 구글 드라이브에 파일 올리는 거랑 똑같은 거잖아요.

깃허브를 쓰되 브랜치로는 작업하지 않는다고 한다. 

하지만 어떤 문서 툴보다 로그(기록)로서의 역할은 잘하고, 체크백(이전 상태로 되돌리기)이 가능하니까 그 역할만 있으면 충분하겠다는 결정을 했습니다. 그리고 오히려 문서를 관리하는 파일 구조를 손봐서, 같은 브랜치에서 작업을 하더라도 충돌이 나지 않는 구조를 고려해서 구성하게 되었어요.

에이전트와 사람의 경계가 무너지는 팀

Q. 세 분이서 AI 네이티브 컴퍼니를 향해 가고 있다고 하셨는데, 구체적으로 어떤 업무 환경을 세팅하고 계신가요?

에이전트의 수를 늘려가는 방향보다 회사 전체가 하나의 유기체처럼 움직이는 방향으로 가고 있습니다. AI가 주로 판단을 하고, 그 판단을 바탕으로 사람과 에이전트들이 일을 가져가서 수행을 하고, 다시 그 결과를 문서로 병합하는 순환 구조를 가지고 있어요.

아까 말씀드린 SST(Single Source of Truth, 유일한 진실 공급원)라는 게 그 순환 구조의 중심에 있습니다. 각자 일어나는 이벤트를 기반으로 SST와 함께 의사 결정을 해요. "우리가 이런 이벤트를 일으키려고 하는데 뭐가 필요해? 어떻게 해야 돼?" 하면 AI가 판단을 해 줍니다. 그 판단 결과대로 이벤트를 수행하고, 혹시 과거에 했던 이벤트라고 하면 그 이벤트를 가져와서 형식을 주고 "이대로 해 봐라"고 센터에서 알려줘요. 그러면 그거대로 수행을 하거나, 더 좋은 방법을 얹어서 수행하고, 그 결과를 다시 리캡(정리)합니다. 리캡한 문서를 다시 SST에 반영하는 식으로 일을 하고 있어요.

Q. 이전에 링크드인에서 "사람 간의 커뮤니케이션이나 의사 결정 공유가 병목이 된다"고 한번 얘기하셨는데, 이 문제를 어떻게 풀어가고 계시나요?

저희도 비슷한 경험을 했었습니다. AI로 작업을 하다 보니까 생산물은 정말 빨리 나오는데, 팀 단위로 활동을 하다 보면 서로가 서로한테 의존도가 걸려 있거든요. 저희는 이 구조를 아예 해체했습니다. 처음에 프로젝트를 시작한 사람이 끝까지 책임을 지는 엔드투엔드(End-to-End, 처음부터 끝까지) 구조로 아예 일하는 방식을 바꿨어요.

이걸 할 수 있게 된 배경은 에이전트가 기존에 제가 하지 못하던 일들을 많이 할 수 있게 도와줬다는 겁니다. 디자이너가 아니라도 디자인을 할 수 있게 됐고, 기획자가 아니라도 기획을 할 수 있게 됐고, 프로덕트를 어떻게 셀링할지까지도 할 수 있게 되니까 구조를 아예 바꿨어요. 그러면 싱크(동기화)를 아예 안 해도 되는 구조가 생기겠죠. 결과물만 가지고 이야기를 하게 되고, 그 결과물을 기반으로 앞으로 어떻게 할지에 대해서만 이야기하게 된 거 같아요.

Q. 엔드투엔드로 가더라도 혼자서 해결할 수 없는 부분이 생길 텐데, 그런 경우에는 어떻게 하시나요?

엔드투엔드로 가더라도 책임지지 못하는 부분들이 간혹 발생해요. 그런 부분에 대해서는 정확히 분리를 해내서 "여기까지는 해 줘라"고 리퀘스트가 들어오고, 저는 거기에 대한 엔드투엔드만 가져가서 해결하고 모듈식으로 돌려주고, 마저 이어가는 방식으로 합니다.

작은 엔드투엔드든 큰 엔드투엔드든 다양한 엔드투엔드를 맡고 있을 텐데, 그게 사업적으로 방향이 계속 맞는지 서로 모여서 얼라인(방향 맞추기)을 맞춰 보고, 서로가 잘하지 못하고 있는 부분, 잘하고 있는 부분을 공유하는 것이 중요한 거 같아요. 계속 이런 부분이 더 중요해지고 있는 것 같습니다.

미팅 녹음본에서 글감까지 — 컨텍스트 순환 시스템

Q. 실제로 델타소사이어티가 어떻게 일하는지, 구체적인 도구와 프로세스를 보여주실 수 있나요?

저희는 자동화에 집중하기보다는 주변에서 일어나는 컨텍스트를 어떻게 잘 수집할지, 수집된 컨텍스트를 어떻게 잘 활용할지, 활용한 컨텍스트를 어떻게 다시 축적할지, 이 사이클에 집중을 하고 있어요.

몇 가지 시나리오를 보여드리겠습니다. 저희가 외부 미팅을 정말 많이 합니다. 보통 미팅을 통해서 미팅 내용을 디지털화하는 작업을 가장 먼저 해요. 파이어플라이스(Fireflies)라는 앱을 쓰고 있습니다. 파이어플라이스에 녹음이 되면 슬랙에 녹음이 완료됐다고 메시지가 오고요. 그러면 저희는 실에 들어와서 이 미팅에서 제가 놓친 부분들도 있고, 보지 못한 관점들도 많을 거잖아요. 그걸 추출하는 작업을 먼저 합니다.

Q. 추출 작업은 구체적으로 어떻게 진행되나요?

미팅 다이제스트라는 스킬을 쓰는데요. 제가 했던 미팅을 리스트업하고 거기서 소화하고 싶은 미팅을 고를 수 있어요. 항상 여러 정보를 받는 것 자체가 노이즈하니까, 제가 필요한 몇 가지 프롬프트를 넣어 놓고 그 프롬프트에 맞는 결과물을 뽑아 볼 수 있도록 스텝을 설정해 놨어요. 전략 분석, 아이디어 확장, 액션 플랜 — 보통 이 세 가지를 많이 씁니다.

예를 들어 아이디어 확장을 돌리면, 핵심 개념을 다섯 가지 추출해 주고, 3X라는 프레임워크를 기반으로 각 아이디어를 다양한 관점에서 볼 수 있게 도와줍니다. 마지막으로 인접 가능성 — 저희가 진행하고 있는 프로젝트랑 어떤 연관성을 가질 수 있는지 실제로 연결해 줘요.

사실 뇌에서 일어나는 일들을 그대로 옮겨 놓은 겁니다. 뇌는 한 개잖아요. AI는 메모리가 있으니까 많은 데이터를 한 번에 처리할 수 있고, 놓치는 부분 없이 꼼꼼히 볼 수 있게 도와줘요.

Q. 미팅에서 나온 아이디어를 글감으로 쓰고 싶을 때는 어떻게 하시나요?

최근에 글을 쓰기 시작하면서 미디어 페르소나 같은 걸 하나 잡아놓고 문서화시켜 놨는데, 이걸 기반으로 어떤 글을 쓸 수 있는지 AI한테 사고를 시켜 봅니다. 저희는 생각을 안 하고, 얘가 생각하게 만들어요. 결과만 보고, 저희 취향대로 선택만 하고 있는 거 같습니다. 저는 판단도 많이 시켜요.

예를 들어 세쿼이아의 알프레드 린이라는 분의 강연을 미팅 파일로 넣어 놨는데, 아이디어 확장을 돌리니까 "세 배 더 만들고 세 배 더 혼란"이라는 컨셉의 글을 쓰면 좋겠다고 제안하더라고요. 이건 제가 최근에 썼던 글이랑 결이 맞아서, 제 주장을 뒷받침하는 소재로 좋았어요.

Q. 그렇게 나온 아이디어를 실제로 어떻게 태스크로 만드시나요?

사고를 시키고 결과가 나오면, "1번 글을 쓰고 싶어. 근데 지금 시간 없으니까 트리아지에 넣어줘"라고 합니다. 그러면 리니어(Linear)라는 태스크 매니지먼트 툴에 트리아지로 들어가요. 리니어는 그냥 태스크를 관리하기 위한 툴로만 쓰고 있고요. 저희는 파일트리 프레임워크 자체를 컴파운드(Kompound)라고 부르고 있어요. 결과물은 이 컴파운드에 저장됩니다.

Q. 트리아지에 들어간 태스크는 그다음 어떻게 처리되나요?

트리아지 스크립트를 실행하면 트리아지 목록을 쭉 가져와서, 제가 할 일과 에이전트가 해 줄 수 있는 일을 분류합니다. 어차피 저한테 할당하더라도 제가 하는 일도 똑같잖아요. "조사해야 되나" 하고 AI한테 조사시키고, "초안 내가 써야 되나" 하고 초안시키고. 이런 일들은 에이전트가 할 수 있는 일이 있기 때문에, 제 과거 선택들을 기반으로 "어떤 일들은 어떻게 판단한다"는 컨텍스트를 담을 수 있도록 스킬을 설계해 놨어요.

지금은 그 데이터를 쌓는 단계라서 제가 직접 선택을 하고 있긴 합니다. "이건 내가 해, 이건 네가 해"를 지정해 주면, 에이전트한테 시킨 일들은 자기들이 일을 다 하고 그 태스크를 던(Done)으로 처리해요. 결과물은 컴파운드에 남겨 놓는 구조로 해 놨습니다.

Q. 그러면 실제로 AI가 하는 일과 웅재 님이 하는 일은 어떻게 나뉘나요?

오프라인에서 일어나는 일이라든지 외부 인원과 연락을 해야 되는 상황에서는 거의 제가 하고 있고요. 코드 개발, 스킬 개발, 문서 정리 — 이런 디지털 세상에서 일어나는 일들은 거의 위임을 해 보려고 하고 있습니다. 못 믿는 부분이 많긴 하지만, 계속 위임을 해 보려고 하는 건 이 감각을 익혀야 되는 거 같아요.

"내가 이걸 할 수 있구나, 못하는구나. 못하면 왜 못하지? 어떻게 하면 하게 할 수 있게 만들지"를 계속 그 접점에서 만져가면서 느껴야 뚫어낼 수 있는 거 같아요. "안 되네, 내가 해야겠네"가 저는 완전 컴포트존(안전 지대)이라고 생각합니다. 거기 있으면 앞으로 못 나가고 그 자리에 있게 되는 거 같아요.

모두가 프로덕트를 만드는 인프라

Q. 추가적으로 보여주실 부분이 있나요?

저희가 프로덕트를 모두가 만들 수 있는 환경을 구축했거든요. 실제로 만들어진 프로덕트들이 꽤 있고, 내부에서 많이 쓰고 있고, 실제로 어저께 외부에도 하나 배포를 했습니다.

지금 프로덕트를 만드시는 분들을 보면 그냥 계속 찍어내고 계시잖아요. 잘되든 못 되든 어쨌든 개인 정보라든지 리소스를 먹고 있기 때문에 관리가 가능해야 하거든요. 그래서 관리 가능한 형태로, 안전한 기본 인프라를 탑재한 채 프로덕트를 만들 수 있는 인프라를 구현해 놨어요.

Q. 구체적으로 어떻게 작동하나요?

프로덕트 크리에이트라는 스킬을 사용하면, 기본적으로 제가 과거에 경험했던 외주 개발 프로세스를 따라갑니다. 시나리오, 비전, 목적 — 이런 것들을 따라가고, 어떤 스펙을 사용해서 뭘 만들지까지 개발에 대해 구체적으로 알지 못해도 안전하게 만들 수 있는 프로세스를 구현해 놨습니다. 일종의 PRD(Product Requirements Document, 제품 요구사항 문서)를 구체화해 나가는 거예요.

중점을 둔 건 상상할 수 있게 만드는 거였어요. 실제로 제가 외주 개발에서 마주했던 문제들 중 가장 큰 원인이, 서로 커뮤니케이션하면서 상상하는 게 달라서 원하는 결과를 못 얻었던 거거든요. 그래서 유저 시나리오라는 걸 써서, 사용자가 A부터 Z까지 어떤 단계를 통해서 도달하는지 같은 상상을 할 수 있도록 설계해 놨습니다.

Q. 이렇게 만들어진 프로덕트들은 어떻게 관리되나요?

프로세스를 따라서 만들게 되면 저희 컴파운드 내부에서 프로덕트를 관리할 수 있는 형태로 구현해 놨어요. 프로덕트가 하나 더 추가되면 레포지토리(Repository, 코드 저장소)라는 개념 자체도 몰라도 됩니다. 그냥 컴파운드 위에서 작업을 하시면 되고, 거기서 AI가 자동으로 레포지토리 만들고, 서버 세팅하고, DB(데이터베이스) 연결하고, 배포까지 해줘요.

나중에 모두가 프로덕트를 만들 수 있는 환경이 된다고 하면 진짜로 하루에 회사 내에서 만들어지는 프로덕트들이 정말 많을 거란 말이죠. 쓸데없는 리소스로 프로덕트를 만드는 사람들도 많을 거고, 오류가 나는데 방치하는 사람도 많을 거고, 데이터가 많이 쌓였는데 처리할 줄 몰라서 방치하는 사람도 많을 거고. 그래서 미리 안전망을 만들어 놓고, 기본적인 인프라 세팅과 데이터 파이프라인을 이 프로세스를 따라가면 자연스럽게 밟을 수 있도록 구성해 놨어요.

각 프로덕트들은 전부 다 관리 가능하고, 데이터는 한 곳으로 모이고, 회사 차원에서 얼라인 맞지 않는 프로덕트들은 제거하거나 피드백을 줄 수 있는 환경이 마련됩니다.

컴파운드의 내부 구조

Q. 내부 지식 레포지토리인 컴파운드가 어떤 구조로 되어 있는지 설명해 주실 수 있나요?

메인 컨셉 자체는 인체 구조랑 비슷해요. 세상에 있는 모든 지식을 다 잘 알고 있다고 해서 A라는 사람의 문제를 잘 해결해 줄 수 있는 건 아니잖아요. 저희가 필요한 맥락만 정확히 LLM(Large Language Model, 대규모 언어 모델)한테 전달해서 결과를 받아볼 수 있는 구조가 메인 컨셉이고요.

파일트리 단위로 접근할 수 있는 컨텍스트를 제한하면 원하는 답변을 잘 받을 수 있겠다는 가설 하에 개발된 프레임워크입니다.

기본적으로 위쪽 부분은 거의 시스템이에요. 클로드 코드가 작동할 수 있는 행동 원리들을 제어하는 부분들이고요. 예를 들면 "관리자 말고는 이 시스템단 코드를 건드리지 말아라"는 CLAUDE.md 같은 파일들이 들어가 있고, "어떤 의사 결정을 할 때 항상 이 폴더의 내용을 훑고 결과를 내놔라" 같은 몇 가지 요소들을 후크(Hook, 특정 시점에 자동으로 실행되는 기능)랑 같이 걸어 놨어요.

그 밑에가 워크스페이스예요. 여기는 충돌을 막기 위해서 만들어 낸 부분입니다. 각자마다 워크스페이스를 가지고 있고요. 하위 폴더 구조에서 자유롭게 작업을 할 수 있어요. 회사 엔티티(Entity, 항목)도 따로 있는데, 회사에서 중요하게 여기는 몇 가지 문서들을 저장해 놨고, 여기에 있는 내용들은 회사에서 의사 결정이 된 내용들만 업로드되는 부분입니다.

사실상 이 워크스페이스 부분만 빼서 다른 회사 것을 집어넣으면 누구나 사용할 수 있는 구조로 만들어 놨어요.

개발자의 역할이 바뀌고 있다

Q. 이 무에서 유의 프로덕트를 만들어내는 그린필드(Greenfield, 완전히 새로운 프로젝트) 쪽은 이제 누구나 할 수 있을 것 같은데, 개발자의 역할은 어떻게 바뀔 거라고 보시나요?

프로덕트가 나오면 땡이 아니라 거기서부터 유지보수를 계속 해 나가야 하는데, 개발자들이 해도 잘 안 되는 케이스들이 많잖아요. 그 브라운필드(Brownfield, 기존 시스템을 유지보수하며 발전시키는 영역) 영역의 하네스(Harness, 안정적으로 운영하기 위한 기반 체계)를 구축해 나가는 게 앞으로 개발자들이 해야 되는 역할이 아닐까 싶어요.

전체 시스템을 관할해서 데이터 수집, 프로덕트 매니징, 회사 전체에서 IT 서비스를 관리하는 게 앞으로 개발자들이 많이 하게 될 일이라고 예상합니다. 왜냐면 제가 지금 그걸 하고 있으니까요. 모든 조직에 적용되진 않겠지만, 작은 조직이라든지 프로덕트로 고투마켓(Go-To-Market, 시장 진출)을 해 보고 싶으신 분들은 많이 직면하게 될 문제가 아닐까 싶습니다.

AI 네이티브 캠프 — 비개발자도 클로드 코드를

Q. AI 네이티브 캠프는 어떤 형태로 진행됐나요?

팀 어텐션과 같이 진행했고요. 정구봉 님을 섭외해서 같이 진행하게 됐습니다. AI 네이티브 캠프는 제목 그대로 캠프였어요. 저희가 알려드린다기보다는 저희가 가지고 있는 프레임워크 정도를 제시해 드리고, 그 위에서 각자가 직면한 문제들을 각자 풀어내고 서로 모여서 푼 문제들을 공유하는 포맷이었습니다.

총 4일 정도 진행했고, 아주 기초적인 지식들 — 클로드 코드 설치, 스킬 사용법, MCP 사용법 같은 것들을 먼저 알려 드리고, 그다음에 저는 컨텍스트 엔지니어링(Context Engineering, AI에게 맥락을 효과적으로 전달하는 방법론), 컴파운드 엔지니어링 같은 개념들을 개념 단위로 심어 드렸습니다.

근데 이걸 활용하시는 참가자분들은 진짜 저희가 예상하지도 못하는 방법으로 소화를 하셨고, 엄청 오랫동안 고민했던 문제를 빠르게 해결하신 케이스도 많았습니다. 참가자분들이 서로 유즈 케이스들을 공유하면서 다 같이 지식을 교류하는 장이었어요.

Q. 비개발자분들이 클로드 코드를 처음 시작하실 때 가장 힘들어했던 점은 무엇이었나요?

일단 설치부터 힘들어 하셨고요. 터미널이라는 거 자체가 엄청 낯설다고 하시더라고요. 터미널이라고 하면 해커들처럼 화면들이 막 뜨는 걸 떠올리시잖아요. 거기서부터 압도되는 감정을 많이 가지시더라고요. 이 허들을 넘는 게 최초에 좀 힘들었던 거 같고, 설치를 하고 나서부터는 "힘들다 힘들다" 하시면서도 잘 따라와 주셨어요.

Q. 접근 방식에서 중요하게 생각하신 포인트가 있다면요?

저희가 접근한 방식은 도구로서 AI를 잘 쓰는 법을 공부하는 거보다, "일하는 도구"라고 생각하고 모든 걸 위임하게 하는 이 멘탈 모델을 바꾸는 게 중요하다고 생각했습니다. 내가 가진 컨텍스트만 잘 담아서 AI가 잘 이해해서 알아서 일을 잘하도록 만드는 게 더 중요하다는 게 코스 전반적인 서브 텍스트로 깔려 있었어요.

Q. AI 네이티브 캠프를 앞으로도 계속 하실 건가요?

앞으로 AI 네이티브 캠프를 할지는 미정이고, 대신 캠프에서 나오신 분들과 함께 심화 과정들을 운영해 보려고 하고 있어요. 이미 모집을 하고 있는 건 AI 네이티브 캠프 파이낸스 편인데, 파이낸스 쪽에서 AI를 어떻게 쓰는 게 좋을지에 대한 코스를 모집하고 있습니다. 앞으로 패스 편, 프로덕트 편도 계속 진행을 해 보려고 하고 있고요. 저희 또한 문제를 겪고 있는 당사자들이기 때문에, 같이 참여해서 같이 무언가 만들어 나가는 커뮤니티로 구성해 보려고 합니다.

자동화보다 내비게이션

Q. 이전에 링크드인에서 "자동화에 집중하면 AI를 반밖에 못 쓰는 것 같다"고 하셨는데, 그 이유가 궁금합니다.

자동화 자체를 부정하고 싶었던 건 아니에요. 가장 처음에 퇴사해서 같이 고군분투할 때 만들었던 게 영어 모델을 번역해서 쓰는 건데, 한 3개월 만에 대체됐고요. 스킬이 나오기 전에 스킬 같은 걸 만들어서 썼었는데, 그것도 한 달 못 가서 클로드에서 내더라고요. 그러다 보니까 이런 자동화나 툴 같은 거에 집중을 하는 건 금방 무너지는 거 같아요.

자동화는 코스트(비용)를 줄이는 방법에 가깝다고 생각해요. 정말 오랫동안 지속될 일이라면 자동화를 하는 게 맞죠. 근데 그게 아니라면, 투입한 시간을 오랫동안 지속할 수 있는 일에 집중하는 게 맞는 거 같고요.

AI가 해 줄 수 있는 걸 다시 진지하게 생각해 봤는데, 결국 사람들이 사업을 하거나 커리어를 이어가는 건 자기가 원하는 상태를 만들기 위함이잖아요. 그 목적지를 정말 뾰족하게 갖고, 정확하게 도달할 수 있는 최단 거리를 알려 줄 수 있는 게 AI가 잘할 수 있겠다라는 가설이 있어요.

제가 원하는 것을 명확하게만 깎으면, 제 세계관 밖에서도 그 목적지를 찾아서 도달할 수 있게 만들어 주는 거 같아요. 목적지를 먼저 깎으면 자동화는 그다음에 해도 된다고 생각하는 편입니다.

🌟 델타소사이어티의 다음 캠프가 궁금하다면 → 바로가기

오늘 레터가 좋았다면, 조쉬의 뉴스레터를 주변에 알려주시거나, 구독을 해주세요. 소중한 노력이 들어간 글을 널리 알려주세요. 

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

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

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

[구독하러 가기]