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

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

[구독하러 가기]

10년 동안 IT 외주 회사를 키워온 대표가, AI로 그 외주업 자체를 없애겠다고 말합니다. 똑똑한개발자(이하 똑개)를 운영하는 서장원 대표 이야기예요. 2016년 개발자로 시작해 지금은 약 30명 규모의 에이전시를 이끌고 있고, 크몽과 인수합병된 뒤로는 B2B SaaS '플러그'까지 함께 운영하고 있어요.

요즘 'AI 네이티브 전환'을 내건 회사가 많지만, 대부분은 생산성 도구 몇 개를 도입하는 선에서 멈추곤 합니다. 서 대표는 거기서 한 발 더 나가, 회사의 모든 업무 단계를 AI 친화적으로 다시 짜고 있고, 그 끝에서 '에이전시라는 업이 사라지는 미래'를 진지하게 준비하고 있어요. 1인 창업가에게도 그대로 옮겨올 수 있는, 일하는 방식 자체를 바꾸는 방안에 대해 이야기를 나눴습니다.

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

에이전시가 직접 프로덕트를 만드는 이유

Q. 최근 회사에서 결정적으로 바뀐 사례가 있을까요?

팀원들에게 "우리는 AI 네이티브로 전환할 거다"라고 선언한 게 출발점이었어요. 한순간에 바뀔 수는 없으니까 지금도 점진적으로 계속 변화시키는 중이고요. 개인 단위의 생산성은 많이 올라왔는데, 조직 관점에서 이걸 어떻게 통합할 수 있을까를 계속 고민하다가 만들게 된 게 '똑빌더'라는 내부 시스템이에요.

재밌는 건, 다른 회사들도 생각보다 비슷한 고민을 하고 있더라고요. 저희가 외주가 메인 비즈니스다 보니까, 다른 기업들도 AX 전환에 필요한 프로덕트를 만들기 위한 고민을 하고 있고, 그 형태가 저희가 만드는 빌더랑 좀 비슷하게 가더라고요. 그래서 이걸 외주로도 성공적으로 온보딩시켜 드리려고 고민을 많이 하고 있습니다.

Q. 똑빌더, 플러그 같은 프로덕트를 직접 만드시는 이유가 뭔가요?

저희는 원래 IT 외주 개발보다는 '프로덕트 빌더', 그러니까 IT 프로덕트를 만드는 에이전시 형태로 계속 브랜딩을 해 왔어요. 단순히 사이트나 앱을 찍어내는 게 아니라 서비스를 만드는 팀이다 보니까, 비즈니스적으로 성공하는 IT 프로덕트를 만드는 게 저희의 메인 목표였거든요.

그런데 성공하는 IT 서비스를 만들려면, 우리가 먼저 성공해 봐야 하지 않나 싶었어요. 그래서 플러그 이전에도 다양한 시도가 있었고 그만큼 실패도 많았습니다. 플러그는 그래도 월 BEP(손익분기점)를 넘긴 프로덕트라서, 저희 내부에서는 성공한 사례로 자리매김한 케이스라고 봐 주시면 좋을 것 같아요.

Q. 외주(에이전시)와 SaaS(플러그)를 굳이 병행하시는 이유는요?

현실적으로 보면, 아직까지는 외주에서 벌어들이는 매출이 플러그 매출보다 많기 때문이에요. 그래서 외주를 중단할 수는 없었던 것 같고요.

그리고 그것만은 아니고, 저는 개인적으로 외주를 좋아하는 개발자 출신이거든요. 다양한 프로젝트를 맡아서 하는 그 일 자체가 좋습니다.

Q. 투자를 받아서 프로덕트를 더 키워볼 생각은 안 해 보셨나요?

저희는 크몽과 M&A가 된 상태라서, 사실 투자를 받기는 어려운 상황이에요. 다만 개인적으로는, 언젠가 투자를 받을 수밖에 없는 상황이 분명 올 거라고 봐요.

플러그를 여기까지 끌고 오는 데 거의 3년이 걸렸거든요. 지금 마케팅 효율이 정말 잘 나오기 때문에, 마케팅비를 지금보다 열 배 올리면 임팩트가 훨씬 클 거라는 예상은 할 수 있어요. 그래서 모회사인 크몽에서도 늘 "마케팅비를 좀 더 쓰면 안 되냐"고 얘기해 주시고요.

근데 그 결정을 내리기가 정말 어렵더라고요. 에이전시업으로 시작한 사람 특성상, 저희는 돈을 벌고 생존하는 게 메인인 비즈니스를 해 왔는데, 갑자기 '비전에 대한 투자'를 내가 직접 해야 하는 상황이 됐을 때 과연 이걸 끝까지 끌고 갈 수 있을까에 대한 두려움이 있는 거예요. 그래서 성향상 좀 어려운 것 같습니다.

기획·디자인·개발을 '빌더' 하나로 합치다

Q. 예전엔 개발자가 직접 손 코딩을 했잖아요. AI 개발 시대에 똑개는 어떻게 바뀌었나요?

AI 네이티브를 선언하고 나서, 기존에 기획자·디자이너·프런트엔드·백엔드로 나눠져 있던 직무를 'AI 빌더', 'AI 프로덕트 빌더' 형태로 그냥 하나로 통합하자고 얘기했어요.

물론 모든 프로젝트가 그렇게 되는 건 아니고요. 기업 특성상 산출물이 필요한 경우도 있어서, 개발을 먼저 하고 디자인을 나중에 뽑는 식으로 업무 순서가 거꾸로 가는 케이스도 생깁니다. 그래서 지금은 좀 혼란스러운 상황이기도 해요.

Q. 고객사마다 요구하는 산출물이 다를 텐데, 그건 어떻게 맞추세요?

기업마다 원하는 게 정말 달라요. 아주 진보적인 기업은 아예 "피그마 안 써도 되니까 알아서 우리가 원하는 산출물만 만들어 달라"고 하고요. 반대로 "우리는 무조건 피그마 산출물이 나와야 하고, API 명세는 엑셀로 포맷 맞춰서 나와야 한다"는 기업도 있어요. 그래서 거기에 맞춰서 일하고 있습니다.

작은 스타트업 같은 경우에는 정말 한 명이 기획·디자인·개발까지 다 할 수 있는 환경이 만들어졌어요. 그렇게 일하는 케이스도 있고요. 결국 직무가 '빌더'라는 이름으로 통합되니까, 디자이너가 개발을 하거나 기획을 하는 식으로 유연하게 움직일 수 있게 된 거죠.

Q. 직원 입장에선 "내가 저 일까지 다 해야 하나" 하는 반발도 있었을 것 같아요.

사실 그 부분이 굉장히 민감했어요. 저는 처음에 "그 방향으로 가긴 하겠지만 당장 하진 않을 거고, 정답은 나도 모르니까 같이 찾아보자"는 식이었거든요. 근데 팀원들이 느끼기엔 생각보다 급하게 다가왔나 봐요.

그래서 실제로 팀 전체가 퇴사한 경우도 있었습니다. 팀이 통째로 사라져 버린 케이스도 있었고요. 그런데 팀이 사라진다고 해서 그 역할 자체가 없어지는 건 아니잖아요. 그래서 남은 팀원들이 그 역할을 대신하면서 나아가고 있어요.

대표적으로 저희 PM 팀이 실제로 사라졌어요. PM 팀이 없어지면서 "PM의 역할을 에이전트(AI)로 대체하자"는 아이디어가 나왔고, 지금은 그걸 진행하고 있습니다. 모든 슬랙에 에이전트가 들어와서 내용을 수집하고 할 일을 작성하는 식으로요. 다만 100% AI가 사람을 대체할 수는 없어서, 아직은 사람이 봐줘야 하는 일들이 계속 생기는 중이에요.

Q. 직무 구분이 사라진다는 건, 다른 직군에서도 일어나고 있나요?

네, 직무의 구분이 많이 사라지고 있어요. 예를 들어 저희 마케터분도 AI 공부를 엄청 많이 하시면서 "브랜딩을 어떻게 확장할 수 있을까"를 고민하시는데, 지금 준비 중인 강의 계획서나 강의 자료도 마케터분들이랑 같이 만들고 있거든요.

직무가 한정적이었다면 그렇게 못 했겠죠. 그래서 거기에 빠르게 적응해야 하는 게 맞는 것 같아요. 결국 각자의 직원이 자기 비즈니스를 도맡아서 책임지는 DRI(Directly Responsible Individual) 형태로 가야 하고, 그 아래에 '빌더'라는 실행 레이어가 있어야 하는 구조라고 봅니다.

Q. 그럼 대표님이 그리는 큰 그림은 어떤 건가요? 대행업이 없어진다는 게 어떤 의미인가요?

장기적으로 보면, 저는 이 업 자체가 없어질 거라고 생각해요. 에이전시업, 그러니까 대행업 자체가 이제 필요 없어질 것 같아요.

그래서 저는 팀원들한테 "우리가 AI 네이티브를 빨리 해야 하는 이유는, 이 업을 우리 손으로 없애기 위해서다"라는 취지로 얘기하고 있어요. 듣기엔 모순처럼 들리지만, 그러고 나면 저희한테 남는 게 분명히 있거든요. IT 전문성을 가진 실무자들이 AI로 하나의 산업을 없애는 작업을 직접 해 봤고, 생산성을 극대화하는 과정을 같이 겪어 봤다는 경험이에요. 그 경험을 다른 조직에 그대로 적용해 보는 것, 그게 저의 방향성이라고 봐 주시면 좋을 것 같아요.

좋은 기능을 만들어도 안 쓰는 이유

Q. 그 방향 속에서 실제로 어떤 활동이 이뤄지고 있나요?

AX를 위한 프로덕트를 내부에서 만드는 것도 있고, 똑빌더를 만드는 것도 그 일환이에요. 그리고 제가 유튜브 채널을 운영하면서, 매주 목요일마다 'AI 사례 공유회'를 하고 있어요.

팀원 한 분 한 분과 직접 이야기를 나눠 보는데, 생각보다 다들 AI를 너무 잘 쓰고 계시더라고요. 그런데 과연 옆자리 사람은 그걸 알고 있을까 싶었어요. 저희는 에이전시라 프로젝트 기반으로 움직이다 보니까, A 프로젝트를 하는 사람과 B 프로젝트를 하는 사람 사이에 접점이 별로 없거든요. 그래서 "저 사람은 저렇게 잘 쓰고 있구나"를 서로 공유하려고 매주 목요일에 모이고, 거의 편집 없이 촬영본 그대로 유튜브에 올리고 있기도 해요. 그런 걸 계속 쌓아 두려고 합니다.

Q. 외부 도구도 많이 바뀌었나요? 다들 클로드 코드로 옮긴다든가 하는 변화요.

올해 2월에 클로드 오퍼스 모델이 나오고, 그 이후로 팀 전체가 클로드로 전환했어요. 처음에는 클로드에서 만들어 내는 스킬들을 거버넌스 차원에서 정리해서, 우리만의 공통 스킬을 공유해서 쓰자는 식으로 시작했고요.

근데 그렇게 해도 결국 공유가 잘 안 되더라고요. 그래서 궁극적으로는 그 스킬 자체를 클로드 코드 기반이 아니라, 웹에서 그냥 동작하는 형태로 만들어 놨어요. 기획이나 디자인을 하거나 코드를 뽑아낼 때 클로드 코드와 같이 작업하긴 하지만, 기본적인 환경 세팅이나 거기에 필요한 기획 자료 같은 건 사전에 웹에서 AI가 다 만든 다음에, 그걸 끌고 와서 프로덕트에 넣는 식이죠. 이렇게 계속 고도화하는 단계입니다.

Q. 스킬 대시보드를 만들어 공유하는 시도는 다른 회사도 한다는데, 제가 아는 잘된 사례는 토스 정도뿐이에요. 똑개는 웹사이트로 만들었더니 조직에서 실제로 쓰던가요?

사실 쓰려고 만들었지만, 안 쓰게 됐어요. 안 쓴 이유를 따져 보니까 결국 그거였어요. 저희가 플러그를 만들면서 느꼈던 것.

아무리 좋은 기능을 만들어도, 유저가 원하지 않는 기능이면 안 쓰잖아요. 저희가 리더 입장에서 필요해서 만들었고 "이거 쓰세요"라고 말해도, 팀원 입장에서는 클로드 코드 터미널을 쓰는 게 훨씬 편한데 굳이 왜 저 웹사이트에 들어가서 스킬을 다운받고, 깃이랑 연동하고 이걸 해야 하나 싶은 거죠. 그게 다 불필요한 작업이 되어 버리는 거예요.

그래서 저희는 프로덕트를 만들어 본 경험이 있다 보니, 관점을 바꿨어요. '내가 클로드 코드를 쓰는 것보다 똑빌더를 썼을 때 훨씬 편하다'는 걸 주지 않으면 절대 안 쓴다. 그러니까 우리 팀원을 타깃으로 한 정말 유용한 서비스를 한번 제대로 만들어 보자. 이런 관점에서 지금 똑빌더를 만들고 있다고 봐 주시면 좋을 것 같아요.

프로젝트 전 과정을 AI로 다시 짠 '똑빌더'

Q. 똑빌더가 정확히 어떤 프로덕트인지 설명해 주실 수 있을까요?

똑빌더는 저희가 판매하려고 만든 서비스는 아니고요. 프로젝트가 시작되기 전 투입을 검토·결정하고, 시작되면 필요한 디자인·개발을 하고, 개발한 내용을 고객사에 인수인계하고, 최종적으로 그 내용이 저희 자산으로 남는 것. 이 프로덕트 제작의 전 과정을 AI 친화적으로 일할 수 있게 만든 '업무 대시보드'라고 봐 주시면 좋아요.

에이전시의 기본 프로세스는, 계약이 끝나면 인력을 배정하는 것에서 시작해요. 그런데 이 인력 배정 검토가 생각보다 난이도가 있어요. 누가 어떤 프로젝트를 하고 있고, 지연되는 프로젝트가 뭔지를 다 알아야 하니까요. 규모가 커질수록 배정할 인력을 뽑는 게 어려워지는 거죠.

Q. 그 배정 과정이 똑빌더 안에서는 어떻게 돌아가나요?

저희는 플러그를 CRM으로 쓰고 있어서, 플러그 안에 영업 히스토리가 다 남아요. 그 내용을 바탕으로, 계약이 '계약 임박' 단계로 넘어가면 자동으로 저희 슬랙에 알림이 옵니다.

여기서 '계약 임박'은, 법무팀 검토나 실제 서류 절차 전 단계의 구두 계약 상태를 말해요. 대기업이면 법무팀·구매팀 서류 절차가 많은데, 확정은 됐지만 아직 서류상으로는 구두 계약인 상태인 거죠.

중요한 건, 저희가 에이전트 워크플로를 만들 때 확률적으로 동작하는 부분을 최소화하려고 한다는 점이에요. 그래서 최대한 API나 웹 기반으로 다 연동해 놨어요. 계약 인박으로 옮기면 프로젝트가 자동 생성되고, 훅이 슬랙으로 와서 "인력을 검토해 주세요"라고 알림이 뜨는데, 이건 에이전트가 아니라 그냥 API를 연동해 놓은 거예요.

Q. 그다음, 누구를 투입할지는 어떻게 정하나요?

검토 화면에 들어가면 프로젝트 요약이 뜨고, 백엔드 한 명·프런트엔드 한 명처럼 필요한 인력을 입력한 뒤 담당자를 조회해요. 그러면 '여유로운 사람', '투입 가능한 분', '확인이 필요한 분', '불가한 사람'으로 나눠집니다.

여기서 'AI 추천'을 누르면, 각 인원이 진행했던 프로젝트가 데이터로 저장돼 있다 보니, 이 프로젝트에 필요한 리소스를 적재적소에 맞춰서 AI가 추천해 줘요. 아까 말씀드린 '자산화'가 여기서 작동하는 거죠. 배정할 사람을 선택하고 프로젝트를 생성하면, 인력 배정이 확정되고 슬랙으로도 알림이 갑니다.

Q. 인력이 정해진 다음 단계는요?

다음은 채널 생성이에요. 저희는 슬랙 채널을 내부용과 외부용 두 가지로 만듭니다. 채널을 생성하면, 배정된 실무자들이 바로 초대되도록 돼 있어요.

원래는 채널을 만들고, 재무 담당자나 프로젝트 총괄 리드처럼 실무자 외의 인원까지 초대하는 게 PM의 역할이었거든요. "초대됐고 이제 프로젝트 진행하겠습니다"라고 알리는 것도요. 그 역할을 디지털화한 거예요. 특정 부분은 AR(자동 실행)을 쓰고, 안 쓰는 부분도 있고요. 이렇게 내부 프로세스를 만든 겁니다.

Q. 채널을 굳이 만드는 이유가 있나요?

데이터를 모으기 위해서예요. 클라이언트와 팀원이 매일 나눈 내용을 기록하고, 그걸 로우 데이터로 뽑아와 저장해 둡니다. 이걸 지식 베이스로 써서, 에이전트가 프로젝트 이슈를 추적하거나 클라이언트 요청 중 누락된 부분을 잡아내는 보조 역할을 하는 거죠. 데이터는 매일 한 번씩 수집됩니다.

여기서도 에이전트가 채널 안에 상주하는 건 아니에요. 저희는 API나 훅으로 데이터를 수집해서 DB에 적재해 놓고요. 그 중간에 '헤르메스' 에이전트 하나를 띄워 두는데, 헤르메스에게 저희 DB에 접속할 권한을 줬어요. 에이전트가 DB를 조회할 때 필요한 조건값들을 스킬로 만들어 두는 식이죠.

Q. 그렇게 모은 데이터로 뭘 하나요?

대표적으로 고객 만족도 조사를 준비하고 있어요. 특정 프로젝트의 데이터가 계속 쌓이다 보니까, 그 데이터를 바탕으로 '지금 고객 만족도가 떨어졌는지, 왜 떨어졌는지'를 LLM이 판단해서 팀원에게 알림을 주는 형태로 쓰려고 합니다. 실제로 이슈 사항 같은 경우엔, 수집된 커뮤니케이션 내역을 바탕으로 LLM이 이슈를 감지해 내고 있어요.

Q. 솔직히, 그 만족도 추적이 왜 필요한가요? 담당자들은 이미 다 알 텐데요.

제 경험상, 관리자뿐 아니라 실무자 본인도 이걸 놓치는 경우가 굉장히 많아요. 더 나아가면 아예 인지를 못 하는 경우도 있고요.

개발자 입장에서는 "이 기능을 개발해 주면 되네"라고 인지하는 부분인데, 사실 사람이 보면 거기서 만족도가 떨어질 수 있는 지점이 있거든요. 에이전시업을 오래 하다 보니, 기능을 멋있게 잘 만드는 건 이제 기본 디폴트고, 더 중요한 건 커뮤니케이션이더라고요.

그래서 저희는 "지금 화가 나 있는 클라이언트가 있나" 같은, 고객의 감정 상태까지 추적해야 한다고 봐요. 프로젝트를 잘 수행하려면요. 모든 데이터를 추출해서 거기에 점수를 매기는 거라고 보시면 됩니다. 애초에 거버넌스를 만든 목적은 '관리' 측면이었지만, 그걸 프로덕트로 구현하려면 사용자 입장에서도 편해야 하기 때문에 이런 기능을 넣은 거예요.

기획부터 빌드까지, 사람이 어디에 남는가

Q. 프로젝트가 시작되면, 똑빌더 안에서 기획은 어떻게 진행되나요?

채널까지 만들었으면 프로젝트가 시작된 거니까, 그다음은 자료 수집이에요. 플러그의 영업 과정에서 나눴던 이메일 정보, 마크다운 파일, 기획서, RFP 같은 걸 데이터로 다 가져옵니다.

이 수집 자료를 바탕으로 초안을 생성하는데, 기획서를 만드는 과정에도 저희만의 프로세스와 노하우가 들어가 있어요. 잘 만들어 둔 스킬들로 그 기능을 구현해 놨고요. 참고할 자료를 선택해서 생성을 시작하면 PRD 작성이 진행됩니다.

Q. 기획까지 AI가 다 해 버리면, 사람은 어디에 개입하나요?

AI가 다 하진 않아요. 저희는 '휴먼 인 더 루프'(중요한 단계마다 사람이 직접 확인하고 개입하는 방식)가 중요하다고 보거든요. 그래서 수집 자료를 바탕으로, 질문이 필요하거나 체크가 필요한 사항을 AI가 질문 형태로 뽑아 줍니다.

예를 들면 꽤 디테일한 질문이 나와요. 기획에 대한 미결 사항을 정리해서 AI가 사람에게 물어보는 거죠. 그렇게 디테일한 질문들을 잡아 주고요. 지금 저희가 테스트하는 규모는 약 30페이지 정도 되는 프로젝트인데, 일차적으로 빌드까지 만들고, 그다음에 사람이 붙어서 퀄리티를 높여 줍니다. 적어도 기획이 변하지 않는 상태에서, 프런트엔드·백엔드 환경 세팅까지는 개발 없이 여기서 가능하게 만드는 거예요.

Q. 그 결과물은 어떤 형태로 나오나요?

검토를 거치면 실제 상세 기획서와 IA가 나옵니다. 페이지가 더 필요하면 추가할 수도 있어요. 예를 들어 "로그인 페이지가 필요하다", "비회원도 방문할 수 있어야 한다", "마이페이지는 비회원이 못 들어온다" 같은 걸 권한별·페이지별로 구성할 수 있고요.

화면 구조를 더 시각적으로 보려고, 페이지마다 어떤 데이터가 들어가야 하는지 볼 수 있게 해 놨어요. 로그인, 탐색, 검색, 등록 페이지 같은 식으로 페이지가 쭉 나오게 되어 있죠. 이미 AI 네이티브로 진행한 프로젝트들이 있어서, 그 실제 산출물 기준으로 저희가 원하는 수준의 기획서가 나오도록 스킬을 다듬어 온 결과물이라고 봐 주시면 좋습니다.

Q. 디자인 단계는 어떻게 처리되나요?

화면 구조를 기반으로 디자인 작업을 하는데, 기본적으로 디자인 시스템을 기준으로 디자인 마크다운 파일을 만들어 내는 방식이에요. 저희 플러그 서비스도 지금 바이브 코딩으로 디자인 작업을 다 하고 있거든요.

거기에 맞춰서 룰 세팅도 어느 정도 진행해서 디자인 관련 파일이 나오고, 그다음에 빌드를 진행하는 순서입니다. AI를 쓴 데이터도 대시보드로 트래킹할 수 있게 해 놨어요. 어떤 목적으로 썼고, 토큰을 얼마 썼고, 비용이 얼마 나왔는지까지요.

Q. PRD를 만든 다음 바로 빌드로 넘어가나요?

바로 확정하지 않아요. 여기서도 휴먼 인 더 루프를 강조하는데, 만들어진 PRD를 두고 '비평'을 시작합니다. LLM이 PRD를 한 번 더 분석해서, 네다섯 가지 항목 기준으로 다음 단계로 넘어가도 되는지 체크하고요. 그 단계를 거친 다음에 PRD를 최종 확정합니다.

확정 후 빌드를 생성하면 Supabase, Git, Vercel 연동을 자동으로 진행해 줘요. 중요한 건, "어디까지 AI가 하고 어디를 사람이 해야 하는지"를 태스크로 AI가 만들어 준다는 점이에요. 버셀 토큰을 발급하거나 슈퍼베이스를 발급해야 하는 것처럼 사람이 해야 하는 건 '휴먼 태스크'로 분류해 주고, 나머지 페이지나 API를 만드는 건 코드 단에서 AI가 실행합니다. 이 실행은 실제 클로드 코드에서 받아와서 진행하고 있고요.

Q. 이걸 한 번 돌리면 완성된 프로젝트가 나오나요?

절대 그렇진 않아요. 돌려 놓고 집에 갔다 오면 다 돌아가 있긴 한데, 한 번 돌렸다고 완성도 있는 결과가 나오지는 않습니다. 한 번 돌린 뒤에 로컬에서 실행해서 띄워 보고, 수정 사항을 다시 태스크로 만들거나 바이브 코딩으로 클로드 코드 안에서 요청해요.

그러면 저희가 만들어 둔 스킬들이 작동해서, 그 수정 사항이 태스크로 다 올라갑니다. 빌드를 하고 나면 토큰과 실제 코드가 나오는데, 웹에서 빌드를 시작하면 명령어가 나와요. 그걸 복사해서 컴퓨터에 붙여 실행하면 설치 도구가 로컬에 설치되고, 프로젝트 폴더가 생기고요. 클로드를 실행해서 "프로젝트 시작해 줘"라고 하면, 기존 기획·디자인 자료가 탑재된 상태에서 할 일 목록이 쭉 생성됩니다. 자연어로 수정을 요청하면, 저희가 미리 만들어 둔 클로드 스킬들이 그걸 태스크로 반영해 주는 구조예요.

Q. 똑빌더를 만들게 된 시작점은 뭐였나요?

플러그 팀에서 B2B SaaS를 만들면서 AX로 내부 시스템을 많이 바꾼 게 시작이었어요. 마케팅 데이터 분석부터 분기별 플랜 짜기, 스프린트 운영까지요.

원래는 스프린트를 한 달에 두 번 돌렸는데, 이걸 개선해서 한 달에 열 개 정도의 스프린트가 동시에 돌아갈 수 있게 만들었어요. 비개발자도 스프린트에 참여해서 페이지를 개선할 수 있게요. 그러려면 결국 비개발자도 처음부터 쓸 수 있는 대시보드가 필요하고, 웹 기반으로 동작해야만 했어요. 그걸 만든 걸 보면서, 원래 저랑 리더 둘이서만 쓰려고 만들던 거버넌스를 "팀원 전체가 쓸 수 있는 수준으로 만들어야겠다" 싶었고, 그래서 지금의 똑빌더가 만들어지고 있는 거예요.

앞으로의 똑빌더

Q. 지금은 담당자 한 명이 시작하는 구조인데, 팀 작업이나 이관은 어떻게 하나요?

지금은 AI 네이티브로 전환하면서, 한 명의 담당자가 하나의 프로젝트를 진행하는 방향으로 가고 있어요. 규모가 큰 프로젝트는 그렇게 하기 어렵기 때문에, 궁극적으로는 대형 프로젝트도 똑빌더 안에서 할 수 있게 만드는 게 목표이긴 합니다.

일단 지금 기준으로는 똑빌더로 진행할 프로젝트 규모를 한정해서 갈 거예요. 어떻게 보면 '예비 창업자의 첫 번째 프로덕트를 저희가 만들어 드린다' 정도 수준이 될 것 같아요. 그 규모의 프로젝트가 많기 때문에, 같이 할 수 있는 프리랜서분들이 들어와서 쓰는 구조가 될 것 같고요. 그러면 관리해야 할 프로젝트가 점점 많아질 테니, 그 목적으로 똑빌더를 쓰게 될 거예요.

Q. 추가로 보강하려는 기능이 있나요?

일단 전체 프로젝트에 똑빌더 봇이 들어가서 데이터를 수집하고 있는데, 그걸 바탕으로 PM의 역할을 일차적으로 자동화하는 걸 목표로 갈 것 같아요.

PM의 역할은 결국 소통·커뮤니케이션도 있지만 프로젝트 관리, 태스크 관리 부분도 있거든요. 그래서 실무자, 즉 빌더들이 빌딩 자체에 집중할 수 있는 환경을 제공하는 게 목적이에요. 거기에 맞춰서, 예를 들어 디자이너 출신 빌더라면 기술적인 파트가 부족할 테니 그 공백을 메워 주는 것. 그게 똑빌더의 궁극적인 방향성이라고 봐 주시면 좋겠습니다.

Q. 외부에 공개할 계획도 있으신가요?

외부로 공개하려면 붙여야 하는 기능이 많아서, 그건 좀 어려울 것 같아요. 다만 똑빌더의 기본 베이스를 기반으로 다른 프로젝트를 외주 형태로 많이 하고 있어요.

어떻게 보면 이 똑빌더 자체가 'AX를 위한 경험'인 거죠. 이 경험이 또 다른 대시보드를 만들 수 있는 바탕이 된 거고요. 그래서 지금 마케팅 에이전시 쪽이랑 협업하는 것도 있고 그렇습니다.

AX보다 DX가 먼저다

Q. AX를 진지하게 검토하는 회사가 많은데요. 내부 구성원이 AX를 시작하려면 뭐부터 하는 게 좋을까요?

조직마다 AI를 쓰는 수준이 워낙 다르기 때문에, 저는 그것부터 파악해야 한다고 봐요. "우리 팀원들이 어디에 와 있는가."

아직 GPT에 채팅하는 수준으로 쓰고 있는데 갑자기 클로드 코드를 도입한다고 하면 힘들 거잖아요. 그래서 일차적으로 수준을 파악한 다음, 어떻게든 도입을 시도해야 해요. 전사적으로 클로드 코드든 제미나이든 일단 도입하는 게 우선이라고 봅니다.

예전에 컨설팅하다가 들었던 고민 중에 이런 게 있었어요. 조직에서 AI를 가장 잘 쓰는 사람이, 정작 자기 업무는 AI 전문가로 온 게 아닌데도 팀원들한테 AI 교육을 하는 상황이 된 거예요. 그러다 보니 "내 노하우를 자꾸 팀원들한테 전달하다 보니 내 전문성이 사라지는 것 같다"며 고민하시더라고요. 그래서 잘하는 개개인을 빨리 발굴하는 게 우선이지 않을까 싶고요.

기업 관점에서 하나 더 보자면, 저는 "우리 회사가 디지털 전환(DX)은 되어 있는가"를 먼저 봤으면 좋겠어요. DX가 안 되어 있는데 AX를 시도하는 케이스가 정말 많은데, 그건 쉽지 않더라고요.

Q. DX가 안 되어 있다는 건 어떤 상태를 말하나요?

데이터 수집 관점이에요. 예를 들어 "영업을 최적화하고 싶다"고 하는데, 그러려면 누군가 영업 데이터를 통합해서 엑셀로라도 관리하고 있어야 하잖아요. 근데 그게 아니라 개개인의 개인기로 관리되고 있다면, 그건 사전에 일하는 방식부터 바뀌어야 하는 거죠.

AI를 도입하는 많은 회사가 이걸 '기술의 도입'으로 생각하시는 것 같아요. 근데 제 생각엔 기술의 도입이라기보다 '환경의 변화'예요. 일하는 환경 자체가 바뀌어야 하는 건데, 기술 도입이라고 생각하고 컨설팅 받는다고 해결되는 게 아니라, 조직 전체의 리듬을 바꿔야 하거든요. 거기까지 고민하셔야 하지 않을까 싶습니다.

Q. 그럼 똑개는 데이터를 한곳에 모으기 위해 뭘 하시나요?

미팅 회의록은 무조건 캐럿(Caret, 회의를 실시간으로 녹음·기록해 주는 AI 미팅노트 도구)으로 녹음해서 기록하고, 거기에 API를 연결해서 프로젝트별로 데이터를 수집하고 있어요. 각 프로젝트별로 데이터를 모으는 걸 궁극적인 목표로 하고 있고요.

자산화 측면에서는, 실무자 개개인이 어떤 프로젝트를 해 왔고 연차는 어떻게 되는지 같은 데이터를 기록하는 목적으로 쓰고 있어요. 원래는 노션을 썼는데, 똑빌더를 만들면서 프로젝트 관리 관련해서는 다 내재화하는 중입니다.

Q. 마지막으로 두 가지만 더 여쭤볼게요. 회의록이나 실무자 데이터처럼 프로젝트마다 쌓이는 자료는 지금 어떻게 관리하세요?

저희는 프로젝트 단위로 데이터가 많은데, 사실 프로젝트가 끝나면 그 데이터는 대부분 불필요해져요. 다만 고민인 건, 끝난 프로젝트에 추가 계약이 들어오는 경우예요. 과거 이력을 알아야 다음 담당자에게 맥락을 전달할 수 있으니까요. 그래서 프로젝트당 하나의 테이블을 구성해서, 필요한 시점에 불러올 수 있게 해 둡니다. RAG나 벡터 DB 같은 건 안 쓰고, 거의 다 마크다운으로 진행하고 있어요.

Q. 그리고 끝으로, 데이터 적재는 이렇게 해야 한다고 조언해 주실 게 있을까요?

데이터가 많다고 좋은 게 아니더라고요. 정말 핵심적인 것만 보고, 결국 의사 결정은 사람이 하는 게 중요해요. "의사 결정까지 AI가 할 수 있게 모든 데이터와 과거 결정을 다 넣어서 딸깍 한 번으로 되게 만들자"는 건 좀 불가능하다는 걸 마음에 품고 있어요. 그러니 최대한 도움받을 수 있는 건 받되, 우리가 핵심으로 생각하는 중요한 지표 위주로만 꾸준히 사람이 검수하면서, 우리 조직에 맞게 데이터를 적재하는 구조를 만들어야 하는 게 맞지 않나 싶습니다.

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

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

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

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

[구독하러 가기]