외주 개발 곧 사라진다, AI 네이티브 전환한 IT 에이전시 대표가 단언한 진짜 이유 (똑똑한개발자 서장원 대표님)

관심사 유튜브 채널 전일 영상 번들로 수집한 YouTube 자료. 채널: 빌더 조쉬 Builder Josh, 게시: 2026-06-12 10:30 KST.

핵심 메타데이터

• URL: https://www.youtube.com/watch?v=tYvQq-MRyx0
• Video ID: tYvQq-MRyx0
• Channel: 빌더 조쉬 Builder Josh
• Raw: 2026-06-12-yt-tyvqq-mryx0-외주-개발-곧-사라진다-ai-네이티브-전환한-it-에이전시-대표가-단언한-진짜-이유-똑똑한개발자-서장원-대표님

기존 관련 문서 연결

• AI-Native-vs-AI-Assisted

설명

AI를 ‘도구’가 아니라 ‘일하는 방식’으로 바꾸는 이야기, AI서대표 채널에서 계속 다룹니다. 👉 https://www.youtube.com/@AISeoceo 🎙️ AI 네이티브 조직 전환: 서장원 대표의 AX 전략과 똑빌더 시스템 이번 HOW I AI Podcast에는 똑똑한개발자를 운영하는 서장원 대표가 출연해 AI 네이티브 조직으로 전환하는 과정과 실제 내부 시스템 구축 사례를 공유합니다. 에이전시 비즈니스와 B2B

TRANSCRIPT

우선 저는 그냥 장기적으로 봤을 때는이 업 자체가 없어질 거라고 생각을 하고 있고요. 에이전시 비즈니스 자체가이 플러그 CRF 안에 영업에 대한 히스토리가 남겨지고 있어요. 개정하실 분을 선택하고 프로젝트 생성을 하게 되면은 이렇게 프로젝트 생성된 거를 볼 수 있습니다. 렉 채널도 어 여기에 지금 수입된 실무자분들이 바로 초대가 되게 돼 있어요. 안에는 실무자들 다 들어와 있는데 그다음부터는 수집 자료인데 저희가 데이터를 다 가져옵니다. 그래서 참고할 자료를 선택해서 생성을 시작하면 PRD 작성을 진행을 하는데 화면 구조까지 나오고요. 이렇게 페이지가 나오는 거죠. 빌드 생성이 되면은 슈퍼베이스랑 기랑 버셀 연동을 자동으로 진행해 줘요. [음악] 중요한 거는 그래서 어디까지 AI가 해 줄 거고 어디를 사람이 해야 된다라는 것들을 테스크를 AI가 만들어 줍니다. AI를 도입하는 많은 회사들이 기술의 도입으로 생각하시는 거 같은데 기술의 도입보다는 환경의 변화인 거 같아요. >> 네. 안녕하세요 구독자 여러분. 오늘 하우이 AI 팟캐스트에는 똑똑한 개발자를 운영하고 계신 AI 서대표님을 모셨습니다. 서장원 대표님이신데요. 현재 유튜브 어 AI 서대표를 운영하고 계신데 평소에 정말 궁금했던 이런 여러들이 있어서 인연이 닿아서 저희 오늘 이야기를 좀 함께 나눠 보고자 합니다. 안녕하세요 대표님. 자기 소개 한번 해 주시면 감사하겠습니다. >> 네, 안녕하세요. 저는 똑똑한 개발자라는 IT 에이전시를 운영하고 있는 서장원이고요. 지금까지 에이전시는 운영한지 한 10년 차 된 거 같아요. 그래서 개발자를 커리어로 시작해서 지금 에이전시를 운영하고 있고요. 저희 현재 팀원 규모는 한 30명 정도 됩니다. 그래서 내부에 이제 플러그라는 신사업도 같이 그 B2비 사스를 운영하고 있고요. 그리고 AI 서대표는 저희가 뭐 작년 거의 하반기부터 AI를 뭐 프로젝트로 또 진행하고 내부 AX에 대한 고민도 많이 했었는데 그런 것들을 좀 컨텐츠로 담아보면 좋지 않을까 해서 시작했던 유튜브 채널이라고 봐 주시면 좋을 것 같습니다. 반갑습니다. >> 네, 반갑습니다. 네, 저 개인적으로는 AI 서대표 채널에 그 올라오는 콘텐츠들 자체가 저는 또 같은 비슷한 업이다 보니까 굉장히 많이 공감하면서 봤었어요. 지금 사업하시는게 B2B 에이전시 그리고 B2B 사스 이렇게 진행이 되고 있는 것으로 파악이 되어요. 근데 두 가지를 다 병행을 하시는데 좀 눈에 뛸 만한 뭔가 큰 변화라든가 예전에 비해서 굉장히 좀 AI 네이티브한 회사를 만드시려고 노력을 많이 하시는 거 같아 보였었어요. 유튜브를 또 보면서. 근데 뭐 최근에 좀 회사에서 좀 결정적으로 좀 변화한 사례라든가 아니면 지점 뭐 이런 것들이 좀 있을지 좀 궁금합니다. >> 저희가 회사 내부에서 이제 팀원들에게 이제 AI 네이티브로 전환할 거다라고 말씀을 다 드리고 나서 당연히 뭐 한 순간에 바뀔 수 없으니까 점진적인 변화를 지금도 계속해서 하고 있는 중이고요. 생산성은 개인 측면에서는 굉장히 많이 바뀐 거 같은데 조직 관점에서 어떻게 하면 이걸 통합할 수 있을까에 대한 고민을 계속 하다가 저희가 만들게 된게 똑빌더라는 내부 시스템이라고 봐 주시면 좋을 것 같고 실제로 좀 재밌는 부분은 다른 회사들도 생각보다 비슷한 고민을 하고 있더라고요. 저희가 외주가 메인 비즈니스다 보니까 다른 기업들도 AX 전화안에 필요한 프로덕트를 만들기 위한 고민을 하고 있고 그거의 형태를 저희가 만드는 빌더랑 좀 유사하게 가져가고 계신 거 같아서 그렇게 저희도 계속해서 고도하고 있고 이거를 외주로서도 좀 성공적으로 온보딩 시켜 드리기 위해서 고민을 많이 하고 있습니다. >> 네. 쪽 빌더라고 하는 이런 프로덕트 자체도 만드시고 플러그도 이렇게 만드시고 계신데 그런 프로덕트들을 자체적으로 만드시는 이유가 어떻게 되세요? 저희는 원래는 그 IT 외주 개발보다는 프로덕트 빌더라고 하는 IT 프로덕트 에이전시 형태로 계속 브랜딩을 해 왔는데 결국에는 그 저희가 만드는게 단순히 사이트 뭐 앱 이런게 아니라 서비스를 만드는 팀이다 보니까 비즈니스적으로 성공하는 IT 프로덕트를 만드는게 저희의 좀 메인 표였던 거 같아요. 그래서 성공하는 IT 서비스를 만들려면 우리가 먼저 성공해 봐야 되지 않나 싶어서 사실 플러그 이전에 굉장히 다양한 시도가 있었고 굉장히 많은 실패가 있었고 근데 이제 플러그는 그래도 월 그 BP를 넘긴 프로트라서 저희 내부에서는 이제 성공한 프로덕트로 좀 자리 매임한 그런 사례라고 봐 주시면 좋을 것 같습니다. 저도 유산 비즈니스를 하는 입장에서 너무너무 공감이 되는 포인트가 많은데 그냥 B2비 에이전시도 직접 계속 해오시면서 이제 캐시카우를 계속 걸어 나가 보시고 그리고 B2비 사스 그니까 한마디로 플러그를 지금 운영하시면서 이렇게 두 가지를 병행하는 이유는 혹시 어떻게 되시나요? 현실적으로 보면은 저희가 외주 쪽으로 벌어드리는 매출액이 그래도 아직까지는 플러그에서 벌어드린 매출보다 많기 때문에 외주를 중단할 수는 없었던 거 같고요. 근데 그것뿐만 아니라 저는 개인적으로 외주를 좋아하는 개발자 출신이거든요. 그 다양한 [웃음] 에이션트가 좋습니다. >> 그렇군요. 네. 근데 그냥 정말 개인적인 질문인데 저 또한 이제 같은 사장의 입장이다 보니까 저희 회사에서도 이제 외주 쪽을 더 어 막 키우는 그런 형태보다는 이제 B2비 사스 계열로 비즈니스 더 좀 더 많은 상승시켜 보고 싶다. 그렇게 하기 위해선 어떤게 효율적일까? 그래서 투자를 받아볼까 하는 생각도 개인적으로 최근에 좀 했었고 그런 일을 하고 있는데 저희 똑똑한 개발자 운영하시는 대표님 입장에서는 그 투자를 받아서까지 다른 프로덕트를 좀 더 발전시켜 본다 그런 생각들은 안 해 보셨는지도 궁금합니다. >> 저희는 사실 그 몽이랑 M&가 된 상태라서 투자를 받긴 어려운 상황이고요. 근데 개인적으로는 투자를 받을 수밖에 없는 상황이 분명 될 거고 저희도 플러그를 여기까지 끌고 오는데 거의 3년 정도 걸렸거든요. 마케팅 비용을 넣으면 저희 마케팅 효율이 정말 잘 나와요. 지금보다 10열배 올렸을 때 임팩트가 굉장히 클 거라고 예상할 수 있거든요. 근데 그 결정을 하기가 정말 어렵고 그래서 몽에서는 모회사에서는 늘 저희한테 마케팅비 좀 더 쓰면 안 되냐라는 그 얘기를 해 주시는데 에이전시 업을 이제 업으로 시작했던 사람 특성상 저희는 돈을 벌고 그 생존을 하는게 좀 메인인 비즈니스를 해 왔는데 갑자기 이제 비전에 대한 투자를 내가 해야 되는 상황이 됐을 때 과연 내가 정말 이거를 끌고 갈 수 있을까에 대한 좀 두려움이 있는 거 같아요. 그래서 저는 성향상 좀 어려운 거 같고 그렇습니다. >> 네. 아, 너무 솔직한 답변 감사합니다. [웃음] 되게 저도 정말 공감이 되는 포인트인 거 같고요. 드라이브를 건다는 거 자체가 상당히 어려운 일인데 일단은 이제 지표나 숫자들은 잘 나온다는 거잖아요. 하지만 이제 여기서 어떻게 우리가 더 다른 스텝으로 나아갈지가 진짜 큰 고민이 된다 말씀해 주신 거 같아요. 근데 저도이 AX 사업이라고 해야 될까요? 어쨌든 이전에는 외주 개발이라고 했었던 것들에 해당하는 사업들이 AX라든지 아니면 뭐 조직 컨설팅, 교육 이쪽으로 좀 더 많이 확장되고 퍼진다는 느낌이 들어요. 그런데 지금 똑똑한 개발자는 지금이 AI 개발이라고 하는이 변화에 맞춰서 어떻게 대응하고 계신지가 좀 궁금했어요. 그러니까 예전에는 똑똑한 개발자를 운영한다고 쳤었을 때 실제 개발자들이 들어가서 뭐 손으로 코딩하고 유지보수하고 이런 것들이 상당히 많았다면 지금은 손 코딩을 하는 개발자는 없잖아요. 그런데 지금 뭐 똑똑한 개발자 회사는 그에 맞춰서 어떻게 변화하셨는지 좀 궁금합니다. 우선 저희는 그 AI 네이티브를 선언하고 나서 기존에 이제 기획자, 디자이너, 프런트엔드, 백엔드 이렇게 나눠져 있던 직무를 그냥 AI 네이티브 뭐 빌더, AI 빌더런 식으로 프로트 빌더 형태로 그냥 하나로 통합을 하자라고 얘기를 했습니다. 물론 그렇게 되는 프로젝트도 있고 이제 아닌 프로젝트도 있는데 그 기업의 특성상 뭐 산출물이 필요한 경우도 있어서 업무 프로스 자체가 개발을 먼저 하고 디자인을 나중에 뽑는 케이스도 생기는 거 같고요. >> 그래서 지금 약간 엄청 혼란스러운 상황인 거 같아요. 그래서 엄청 진보적인 기업 같은 경우에는 아예 저희한테 피그마 사용 안 해도 되니까 그냥 알아서 우리가 원하는 산출을 만들어 달라라고 하는 기업도 있고요. 아, 우리는 무조건 피그마 산출매물 나와야 되고 API 명세에서는 엑셀로요 포맷을 맞춰서 나와야 됩니다라는 기업들도 있어서 거기에 맞춰서 저희는 일을 하고 있고요. 근데 작은 스타트업 같은 경우에는 정말 한 명이 기획 디자인 개발까지 다 할 수 있는 환경이 만들어진 거 같고 그렇게 일을 하고 있습니다. 그러니까 고객사의 상황과 요구 사항에 따라서 계속 그 산출물과 일하는 방식들이 조금 더 달라진다라는 건 맞는 거 같은데 이전 상황관 대비해서 고객의 요청 사항에 더 많이 유연하게 대응할 수 있다는게 지금 대표님께서 회사 구성원들과 함께 일을 하시는 방식인 거 같아요. 그러니까 디자이너가 이제 개발을 할 수 있다던가 기획을 할 수 있다던가 그러니까 이런 식으로 운영되다 보니까 빌더라고 하는 이름으로 통합이 되는 형태로 운영이 되는 거 같고요. 그러면서 빌더라고 한다는게 솔직히 말씀드리면 많은 부분들을 다 아울러야 된다는 뜻이거든요. 근데 직원 입장에서는 하이 내가 저런 일까지 다 더 음마타 해야 되나라고 그런 반대 급부가 있을 수가 있는데 혹시 그런데 어떻게 대응하셨는지 좀 궁금합니다. >> 네. 사실 그 부분이 굉장히 약간 민감한 부분이었던 거 같아요. 저도 그래서 처음에 이제 예측으로 전환해야 된다라고 했을 때 그 방향으로 우리는 나아갈 거지만 그걸 당장 하진 않을 거고 점진적으로 가면서 정답은 뭔지 저도 모르니까 같이 좀 찾아보자라는게 저의 방식이었는데 생각보다 이제 팀원들이 느끼기에는 엄청 급하게 다가왔나 봐요. 그래서 실제로 저희는 그 팀 자체가 전체 태어하는 경우도 있었습니다. 네. 그래서 팀이 사라져 버린 케이스도 있었고요. [웃음] >> 아, 마음 아파. 그렇구나. 그래서 그 그러면 결국엔 그 팀이 사라진다고 해서 그걸 해야 되는 역할이 없어지진 않잖아요. 그러다 보니까이 남겨진 이제 팀원들이 해당 역할을 대신해 주면서 이렇게 잘 나아가고 있고 예를 들면 저희 PM 팀이 실제로 사라졌습니다. 그래서 PM 팀이 없어지면서 PM의 역할을 에이전트로 대체하자라는 아이디어가 올라와서 현재는 PM 직무를 AR로 대체하는 거를 이제 하고 있고 저희 모든 슬렉에 에이전트가 들어와서 그 내용을 수집하고 뭐 투드를 작성하고 이런 거 하고 있는데 사실 그렇다고 해서 100% AI가 사람을 대체할 수 없기 때문에 아직까진 그래서 여기에 사람이 봐주고 있는 일들이 계속 생겨나고 있는 중이죠. 개인적으로 봤을 때는 직무의 구분이 조금 많이 사라지는 거 같아요. 저희 마케터분께서도 AI 관련해서 공부 엄청 많이 하시면서 브랜딩적으로 어떻게 확장할 수 있을까? 뭐 저희 강의도 지금 준비하고 있는게 있는데 그런 강의 계획서도 그렇고 강의 자료 같은 경우에도 마켓터분들이랑 같이 만들고 있거든요. 그니까 이게 직무의 한정적이었다면 그렇게 못 했겠죠. 그래서 거기에 좀 빠르게 적응해야 되는게 맞는 거 같습니다. >> 맞습니다. 저도 직원들이 이제는 DRI라고 하죠. 그런 다이렉트 리스폰서블 인디비주얼이라고 표현을 하는데 각자의 직원들이 좀 비즈니스를 도맡아서 해야 되는 그런 쪽으로 저는 돼야 된다고 개인적으로 생각해요. 근데 그 하위에는 빌더라고 하는 레이어가 있어야 되는 거 같고요. 하지만 대표님의 구체적인 그림도 좀 그 궁금하긴 해요. 전체적인 큰 그림에 있어서 어떻게 이게 변화가 되고 있는지에 대해서 좀 더 자세히 설명해 주실 수 있을까요? 우선 저는 그냥 장기적으로 봤을 때는이 업 자체가 없어질 거라고 생각을 하고 있고요. 에이전시 비즈니스 자체가 >> 대행업이 없어진다고요? >> 네. 에이전시업 자체가 이제 필요 없어질 것 같아요. 그래서 저는 팀원들한테 우리가 AI 네이티브를 빨리 해야 되는 이유는 그거 우리가 없애자라는 취지로 지금 움직이고 있습니다. 그럼 저희한테 쌓이는 거는 IT 전문성을 갖고 있는 그 실무자분들이 AI를 통해서 하나의 산업을 없애는 작업을 같이 해보고 아니면 정말 생산성을 극대화시키는 과정을 같이 해 본 다음에 이거를 다른 조직에 적용시켜 보는 것들 그런 것들을 좀 해보는게 저의 방향성이라고 봐 주시면 좋을 것 같아요. >> 음. 그런 방향성 속에서 어떤 [콧방귀] 실제적인 활동이 이루어지고 있는지 좀 자세하게 설명해 주시면 감사하겠습니다. >> 저희 내부에 이제 AX를 위한 그런 프로덕트를 만드는 것도 있을 것 같고요. 그래서 저희는 그런 방향성에 맞춰서 저희 프로덕트 톡빌더 만들고 있는 것도 그렇고요. 그리고 제가 유튜브 채널 운영하면서 저희 매주 목요일마다 저희는 AI 사례 공유회를 하고 있어요. 제가 원원 팀원들 직접 한 분 한 분 얘기를 나누는데 생각보다 저희 팀원들이 AI을 너무 잘 쓰고 계시더라고요. 그래서 과연 옆자리의 분을 알고 있을까? 저희는 에이전시다 보니까 아무래도 프로젝트 기반으로 그 움직여서 A 프로젝트라는 사람들이 B 프로젝트 하는 사람들과의 그 접점이 많이 없어요. 그러다 보니 이런 공유회를 통해서 아 저 사람 저렇게 이해 잘 쓰고 있구나 이런 거를 서로 공유하기 위해 매주 목요일 날 저희 편집 거의 업시에서 촬영한 거 그대로 유튜브에 올리고 있기도 하고요. 근데 그런 것들 좀 쌓아 놓으려고 하고 있어요. >> 네. 아, 그런 구성원들이 직접 그렇게 AI를 활용을 해서 직접적인 사 개인 사례들을 내부적으로 공유할 수 있다는게 되게 멋지고 좋은 시스템인 거 같아요. AI 네이티브를 이제 이렇게 운영한다는게 여러 가지 측면이 있을 것 같은데 어쨌든 에이전트를 내부적으로 설치한다던가 아니면 도구 자체를 다른 걸 바꿔 버린다든가 그러니까 모드가 다 클로드 코드를 쓴다든가 이런여 여러 가지 형태가 있을 것 같은데 대표님 회사는 다른 외부적인 도구가 좀 진화가 됐는지 궁금합니다. 올해 2월에 클로드 그 오퍼스 모델 나오고 그때 이후로 다 클로드 전환을 했고요. 팀 전체로는 클로드를 쓰면서 그 클로드에서 만들어내는 스킬들을 저버넌스로 우리만의 공통 스킬을 공유해서 써 보자라는 식으로 처음에는 시작을 했어요. 근데 그렇게 해도 결국에는 공유가 잘 안 되더라고요. 그래서 궁극적으로 만들게 된 거는 그 스킬 자체도 클로드 코드 기반이 아니라 웹로 그냥 동작하는 형태로 만들어 놨어요. 예를 들면 기획 작업을 하거나 디자인을 하거나 뭐 코드를 뽑아내야 될 때 클로드 코드랑 같이 작업을 하지만 기본적인 환경 세팅이나 거기에 필요한 기획 자료나 이런 것들을 사전에 웹상에서 다 AI가 만든 다음에 그걸 끌고 와서 프로더트에 넣을 수 있도록 만드는 거. 요렇게 해서 지금 프로트 계속 고도하고 있는 단계입니다. >> 되게 공감이 되는 거 같아요. 그러니까 저도 많은 사례를 들었거든요. 다른 기업들에서도 스킬 대시보드 같은 걸 운영을 해서 서로가 스킬을 좀 공유하고 다운로드 받고 뭐 활용을 한다는 그런 이야기를 듣긴 들었는데 제가 알고 있는 사례는 토스 그 정도의 사례 말고는 다른 회사들이 그런 시도를 했다고 해서 잘된 경우를 사실 본 적이 별로 없었어요. 근데 말씀해 주셨던 그런 대시보드 화, 그러니깐 웹사이트 화를 했더니 내부적으로 그런 도구를 만들면 조직 내에서 썼다라고 볼 수가 있나요? 혹시 그런 사례이신지가 궁금합니다. >> 어 사실 쓰려고 만들었지만 안 쓰게 된 거죠. 근데 안 쓴 이유를 하다 보니까 >> 그냥 결국에는 그거였어요. 저희가 플럭을 만들면서 느꼈던 거. 저희가 아무리 좋은 기능을 만들어도 유저가 원하지 않는 기능을 만들면 유저는 쓰지 않잖아요. 저희가 아무리 리더가 필요해서 만들었어요. 그래서 저희 팀원들한테 쓰세요라고 말해도 클로드 코드 터미널을 쓰는게 훨씬 더 편한데 굳이 왜 내가 저 웹사이트 들어가서 스킬 다운받고 이걸 왜 해야 되지? 기시랑 연동하고 이런게 엄청 불필요한 작업이 돼 버리는 거죠. 그래서 불필요한 작업이 되지 않게끔 정말 내가 클로드 코드 쓰는 것보다 우리 서비스 독빌더를 썼을 때 훨씬 더 편하더라라는 걸 주지 않으면 절대 쓰지 않을 거다라는 거를 이제 저희는 프로덕트를 만들어 본 경험이 있다 보니까 그러면 우리는 우리 팀원들을 타겟으로 한 정말 좋은 유용한 서비스를 한번 만들어 보자라는 관점에서 접근에서 지금 프로트를 만들고 있다라고 봐 주시면 좋을 것 같아요. >> 음. 진짜 공감되고요. 저희 회사도 예전에 오픈클로에 어 에이전트를 슬레에 설치해 가지고 여러 개 쓰는게 한번 유행인 적이 있었거든요. 그렇게 해서 한번 써 보려고 하니까 안 쓰시는 거예요. 왜 그러냐 생각해 봤을 때 필요가 없었던 거죠. 그냥 그 작업 자체에 대해서 내 워크플로에 착 달라붙지가 않으니까. 그래서 저희는 최근에 다 지워 버리고 헤르메스 딱 한 개만 남기고 있는데 그러면서도 헤르메스를 어떻게 하면은 좀 각자의 워크플로우 공통적인 내부 워크플로우에 착 달아붙게 할 것이냐가 진짜 저한테 과제였던 거 같아요. 그래서 되게 공감된 포인트였던 거 같고요. 그러면서 제가 이제 들었던게 지금 똑빌더라고 하는 프로덕트를 내부적으로 구성원들을 위해서 만들게 된 계기가 방금 말씀해 주셨던 그런 맥락이었던 거 같아요. 실제로 좀 그 내용에 대해서 좀 보여 주시고 그게 무슨 프로덕트인지 좀 말씀해 주시면은 그다음에 한번 시현을 한번 하면 좋겠습니다. >> 네. 우선은 똑빌더는 뭐 저희가 뭐 판매를 위해서 만든 서비스는 아니고요. 저를 비니스를 했을 때 있을 거고 업이 끝나고 나면은 프로젝트가 시작이 될 텐데 시작 전에 저희가 투입을 검토하고 투입을 결정하고 그다음에 프로젝트가 시작이 되면은 뭐 프로젝트에 필요한 디자인 개발을 하고 그다음에 개발한 내용들을 고객사한테 인수인기하고 최종적으로 그 내용이 저희의 자산이 돼서 남아야 되잖아요. 그래서 지금 독빌더는 그냥 저희가 프로덕트를 만드는데 필요한 전 과정을 AI 프렌들리하게 그 일할 수 있는 워크 대시보드를 만들었다라고 봐 주시면 좋을 거 같아요. 빌더는 아까 말씀드렸던 것처럼 에이전시의 기본적인 프로세스는 계약이 끝나고 나면은 배정을 하죠. 인력을. 그래서 인력을 배정하기 검토를 하는데이 과정도 굉장히 좀 난이도가 좀 있어요. 누가 어떤 프로젝트를 하고 있고 지연되는 프로젝트가 뭔지 >> 규모가 커지면 커질수록 개정되는 인력을 뽑는게 어려운 거죠. 그래서 그런 것들을 하기 위해서 저희가 단계적으로 보여 드리면 저희는 플러그라는 CRM2를 쓰고 있다 보니까이 플러그 CRM 안에 영업에 대한 히스토리가 남겨지고 있어요. 그래서 그 내용을 바탕으로 그 계약 인박으로 넘겼을 때 자동으로 저희 슬랙으로 알림니다. 요거는 이제 >> 계약 인박이라는게 어떤 거예요? 가계약 상태까진 아닌 거 같고 어떤 경우를 계약 인박이라고 표현하는 건가요? 계약이라는 절차가 이제 법무팀 검토도 있어야 되고 >> 그 실제도 있어야 되니까 그 전 단계 뭔가 구두 계약이 된 상태라고 봐 주시면 좋을 것 같아요. >> 아 이제 대기업일 경우에는 법무팀, 구매팀 아니면 여러 가지 서류 절차 이런 것들이 굉장히 많은 내용이 있는데 확정된 상태지만 구두 계약 상태다라는 것을 계약 인박이라고 표현하는 거군요. 그래서 그 저희는 기본적으로 그 에이전트 AI 워크플로를 만들 때 그 확률적으로 동작 부분이 최소화 되었으면 해서 최대한 API나 웹 기반으로 해서 다 연동을 해 놓은 상태예요. 계약 인박으로 옮기면 기본적으로 테스크가 프로젝트가 자동으로 생성되게 되어 있어요. 그래서 훅이 오면은 슬랙으로 연동을 해 놨는데 그 방금 전에 제가 그 옮긴 거예요. 그래서 >> 아 네 >> 환자를 검토해 주세요. 이렇게 알림이 옵니다. 근데 이게 에이전트가 아니라 그냥 API 운동해 놓은 거라고 봐 주시면 좋을 것 같고요. 그래서 실제 트익 검토로 가면은 요렇게 검토 대기로 해서 담당자가 지정이 되지 않았다라고 이렇게 뜨게 될 거예요. >> 그래서 레스트 앱을 들어가서 저희가 그 프로젝트 요약도 이렇게 해 줍니다. 근데 지금 제가 샘플로 먹서 내용이 없어서 지금 AI는 판단할 수 없다라고 나와 있고 여기서 이제 저희가 LRM을 쓰게 된 거고요. 임의로 제가 입력을 해 보겠습니다. 백엔드 한 명, 프론트 한 명. 해서 담당자 조회를 누르면 여유로운 사람 그리고 수익 가능하신 분 이제 확인 필요하신 분 불가한 사람 이렇게 나눠지고요. 여기서 이제 AI 추천을 누르면 지금 저희가 자산화라고 마지막에 말씀드렸던게 각 인원들이 진행했던 프로젝트가 데이터로 저희가 저장을 해 놓고 있어요. 그러다 보니까 제가 저희이 투드 앱에 필요한 리소스를 좀 적제적소에 맞춰서 AI가 추천을 해 주는 겁니다. 예정하실 분을 선택하고 프로젝트 생성을 하게 되면은 이렇게 프로젝트 생성된 거를 볼 수 있습니다. 일단 인력 배정된 거 이렇게 확인할 수 있고요. 슬랙으로도 알림이 갑니다. 그리고 슬랙 채널을 저희는 그다음에 생성을 하게 돼요. 저희의 다음 스텝은 인력이 되면 채널 생성입니다. 근데 채널은 저희는 내부 채널과 외부 채널 두 가지를 생성하고 있어요. 셀렉 채널도 저희가 채널 생성을 딱 하면 어 여기에 지금 수익된 실무자분들이 바로 초대가 되게 돼 있어요. 그래서 원래 채널 생성하고 저희는 뭐 재무 담당자도 따로 있고 프로젝트 총괄 리드도 따로 있어서 그 실무자 제외하고도 이런 분들 다 초대하는 거를 하는게 PM의 역할이었고 그다음에 이제 클라 때 저희 초대됐고 이제 프로젝트 진행하겠습니다라고 얘기하는 역할을 저희가 요렇게 좀 디지털화시킨 거죠. 그러면서 특정 부분 AR 쓰고 이제 AR을 안 쓰는 부분도 있고 요렇게 해서 내부 프로세스를 만든 거고요. 지금 초대를 하면은이 스팀원들이 초대될 거 같아서 일단은 다른 분으로 해서 제가 세팅을 하겠습니다. 네. 그래서 생성을 하면 생성이 되고요. 그 실제 저희 채널로 생성이 됩니다. 요렇게. 네. >> 그리고는 실무자들 다 들어와 있는데 왜 굳이 여기서 슬을 생성하냐면 저희가 데일리로 클라이언트와 저희 팀원들이 나눈 내용들을 매일매일 기록을 하고 있어요. 그거를 로우 데이터로 뽑아와서 >> 저희가 저장을 해 놓고 그걸리지 베이스로 써서 에이전트한테 저희가 프로젝트 이슈 사항을 트래킹하거나 아니면 클라이언트 요청 사항이 있었는데 누락된 부분이 있거나 이런 것들을 A가 좀 보조하는 역할로 데이터를 수집하고 있는 거고요. 실제로 데이터를 한 번씩 데일리로 수집을 하게 됩니다. >> 그래서 >> 어디서 어떻게 수집을 하는 건가요? 에이전트는 현재 어디 있는 것이고 회의록이나 이런 것들은 여기에서 어떻게 들어가게 되는 건지에 대해서 좀 보안 설명을 해 주십사 부탁드릴게요. >> 우선은 에이전트는 여기엔 없고요. 그냥 저희는 API나 훅으로 해서 데이터를 수집하고 더 저희 DB에 적제를 해 놓니다. >> 네. 그리고는 어떤 역할하냐면 중간에 헤르메스 하나 띄어놓고 그 헤르메스가 저희 베비에 접속할 수 있는 권한을 줬어요. 그리고 그 에이전트가 DB를 조회할 때 필요한 조건값들을 킬로 만들어서 하고 있고요. 그래서 예를 들면 고게 만족도 조사 같은 것들 지금 이제 준비 중인 기능이긴 한데 특정 프로젝트의 데이터는 계속 쌓고 있어요. 그러다 보니까 그 사인 데이터 바탕으로 현재 고객이 뭔가 만족도가 떨어졌는지 왜 떨어졌는지 이런 것들을 정해서 그거를 이제 저희 팀원들한테 알림을 주는 그런 형태로 사용하려 하고 있고요. 그 만족도 특정은 뭘 기반으로 할 하나요? 회의록을 기반으로 하나요? 아니면은 어떤 커뮤니케이션 내역이라든가 이런 걸 기반으로 하나요? >> 네. 커뮤니케이션 내역으로 하고 저희가 매일매일 수정 사항이 있는 시점에 맞춰서 그 데이터를 수집하고 있고 실제로요 이슈 사항 같은 경우에는 실제 수집된 내용 바탕으로 이슈를 감지한 거예요. LLM이 >> 궁금한 점은 이게 왜 필요한 건가요? 솔직히 말씀드리면 그 담당자들 본인들은 다 알 텐데 대표가 필요해서 저게 있는 것인지 아니면 당장 이런 이슈들이 있을 것 같으니까 데뷔를 해야 된다라고 하는 그런 커뮤니케이션 차원에서 필요한 것인지 그게 조금 궁금한 포인트였던 거 같아요. >> 저의 경험상 관리자도 필요하지만 실제무자분들도 이걸 놓치는 경우가 굉장히 많고요. 그리고 좀 더 나아가면 그거를인지를 못하는 경우도 있어요. 개발자 입장에서는 어이 기능을 개발해 주면 되네라고 인지할 수 있는 부분인데 그게 사실 사람 보니까 거기서 만족도가 떨어질 수 있다라는 지점들 또는 에이전시업을 저는 좀 오래 해하다 보니까 이게 단순히 우리가 기능을 멋있게 잘 만들었다라는 건 그냥 기본 디폴트 해야 되는 상황이고 더 중요한 건고 커뮤니케이션인 거 같더라고요. 저희 빌더 테스트할 때도 저희 다임 님이 피오분이신데 지금 혹시 화가 나 있는 플라이언트가 있나라는 것들을 그 화가 나 있다라는 그 감정 상태까지 우리는 트래킹해야 된다라고 생각을 하고 있어요. 프로젝트를 잘 수행하기 위해서는. 그래서 모든 데이터로 추출하고 거기에 이제 점수를 먹긴 거라고 봐 주시면 좋고요. 그리고 애초에 거버넌스를 만든 목적 자체는 관리 측면이고요. 근데 그거를 프로덕트로 구별하는 거는 관리만 되면 되는게 아니라 이제 사용자 입장에서도 편해야 되기 때문에 그거를 넣은 거다라고 봐 주시면 좋을 것 같아요. >> 네. 저 저는 이제 처음 보는 입장에서만 제가 해석한 부분을 설명을 좀 구독자분들한테 드릴 수 있다면 똑똑한 개발자에서 수십개 프로젝트를 동시발적으로 관리를 원래 하다 보니까 각자 클라이언트가 현재 지금 어떤 뭐 감정 상태인지 프로젝트가 잘 진척되고 있는지 뭐 이런 것들을 관리자가 한꺼번에 거버넌스를 운영하면서 보고 싶다라고 하는 니즈가 일단 당연히 첫 번째인 거 같은데 근데 이런 관리를 한다는 거 자체가 커뮤니케이션이라든지 아니면 고객 만족을 더 올리기 위한 하나의 장치로서 로서 운영이 되는 것으로 파악하고 있고 그것들을 헤르메스가 페이록을 읽든 슬렉 관련된 대화 내역을 읽든 해 가지고 그것들을 수집을 해서 만족도를 저렇게 제공하고 있다라고 저는 보여지고 있어요. 그래서 굉장히 재밌는 형태로 보이는데 어떻게 해서이 기능을 좀 중점적으로 파악을 해서 어 집어넣게 되셨는지 그 뒷배경에 좀 더 궁금하기도 합니다.요 요 속빌러는 프로스 전반적인 과정을 AI 네이티브 화시키는 과정이기 때문에 지금 앞에 조금 설명드린 거거든요. >> 그래서 뒤에 좀 맞아 드리면은 이해가 되실 것 같아서 저희가 지금 어쨌든 프로젝트 이제 시작이 된 거잖아요. 그 채널을 만들했으니까. 그다음부터는 수집 자료인데 저희가 플러그의 영업 과정에서 논의 나눴던 이메일 정보라든지 아니면 마크다운 파일이라든지 뭐 아니면 기획서 정보 RFP 이런 것들을 저희가 데이터를 다 가져옵니다. 프로 생성하게 되면 지금 >> 그 비어 있어서 안 가져오게 되는데 지금 제가 샘플로 만들어 놓은게 있어요. 그래서 이렇게 MD 파일 제가 기획서 파일을 하나 만들었고요. 사실 이렇게까지 상세하게 주시는 클라이언트 분들은 거의 없으실 것 같긴 한데 기본적으로 총화 내이라든지 뭐 그런 내용들을 바탕으로 여기서 기획을 진행을 하게 됩니다. 그래서 그 여기서부터 이제 AI가 계속 쓰여지게 되고요. 일단은 수집 자료 바탕으로 초기을 생성하게 돼요. 근데 결국에는 그 기획서를 만드는 과정도 뭐 저희 잘 만들어 놓은 스킬들도 있고 하겠지만 저희만의 또 프로세스가 있고 저희만의 노하우가 있잖아요. 그런 걸로 기능을 구현해 놨다라고 봐 주시면 될 거 같고요. 지금은 GPT가 뒤에 붙어 있습니다. 그래서 참고할 자료를 선택해서 생성을 시작하면 저희가 PRD 작성을 진행을 하는데 AI가 다 하진 않고 저희는 휴먼 인드로프가 좀 중요하다라고 생각하고 있어서 해당 내용 바탕으로 질문이 필요하거나 체크가 필요한 사람들을 AI가 질문으로 뽑아 주는 걸 이제 다음 스텝에서 진행을 하게 될 거예요. 그래서 미결 사항에 대해서 정리하고 AI가 이제 사람한테 물어보게 되는 거죠. 예를 들면 뭐 굉장히 디테일하게 질문이 나와 줘요. 그래서 그래서 기획에 대한 좀 디테일한 질문들을 좀 잡아 주고 있고요. 지금 저희가 테스트로 계속 하고 있는 규모는 한 30페이지 정도 되는 프로젝트를 기준으로 빌드까지 만드는 거를 일차적으로 하고 그다음에 사람이 계속 붙어 가지고 퀄리티는 높여 주긴 해야 돼요. 근데 적어도 기획에 대한 내용이 변하지 않은 상태에서 프ont트 핸드나 백핸드나 환경 세팅까지는 다 여기서 이제 개발 없이 가능하게끔 만드는 거죠. >> 초기에 정말 실제로 개발을 다 프로젝트에 착수를 할 만한 환경들을 모두 다 만든다라는 거가 주가 되겠네요. >> 네. 이렇게 해서 다음 단계 넘어가면 기획을 생상을 합니다. 그래서 여기 이제 초반에 이제 아예 검토 페이지가 나오고요. 근데 페이지가 필요할 수도 있잖아요. 예를 들면 >> 네.인 로그인 페이지 필요하다. 그지? 그리고 비회원자가 비록이 방문할 수 있어야 되고. 근데 할리 페이지는 비록이 방문 못 한다. 이런 것들을 지금 유형이 없어서 그런데 그런 유형들을 좀 추가한다든지 해서 권한별로 페이지별로 저희가 그 구성을 할 수 있고요. 요렇게 해서 추가 코멘트를 달아서 완성하기를 누르면 실제 탕세 기획서랑 IA가 나오게 됩니다. 그래서 지금 이미 샘플로 AI 네이티브로 진행해 온 프로젝트들이 있어요. 그래서 그런 프로젝트에 실제 산춤을 기준으로 해서 어 저희가 원하는 수준에 그 기획서가 나오는 데까지 좀 그 스킬을 좀 다듬어 가지고 지금 내용이라고 봐 주시면 좋을 것 같아요. 그 IA 화면 구조까지 나오고요.이 이 화면 구조를 조금 더 시각적으로 보기 위해서 저희 그냥 이렇게 화면 페이지마다 어떤 데이터 들어가야 되는지 볼 수 있게끔 지금은 페이지 페이지밖에 없 나오긴 하는데 예 >> 실제 저희 기획 자료가 아 보면 이렇게 페이지가 나오는 거죠. 그래서 로그인 이제 타 탐색, 상색, 등록 페이지 요런 식으로 페이지가 좀 나오게 되어 있고요. 그걸 기반으로 이제 디자인 작업을 하게 됩니다. 디자인 같은 경우에는 기본적으로 디자인 시스템 기반으로 디자인 MD 파일 만들어내는 건데 저희 플러그 서비스도 바이브 코딩으로 다 디자인 작업을 하고 있어요, 지금. 그래서 거기 맞춰서 줄 세팅도 어느 정도 진행을 해서 디자인 관련된 파일이 나오고 그다음에 이제 빌드를 진행하는 프로세스라고 봐 주시면 좋을 것 같아요. >> 그래서 실제 저희가 AI를 쓴 데이터도 개인 화면에서 >> 그 어떤 목적으로 썼고 토큰 얼마 썼고 비용 얼마 나왔는지 이런 거 트래킹할 수 있게끔 대시보드로 나오고 있고요. 오, >> 기획서에서는 저희가 계속 그 휴먼인드로프를 강조하는게 이렇게 만들어진 PRD를 바로 저희가 확정하지 않고 비평을 좀 시작합니다. 비평을 통해서이 LM이 PRD를 다시 한번 분석해서네 가지, 다섯 가지 정도의 항목에 있어서 다음 단계로 넘어도 되는지 요런 거 저희가 체크를 한번 진행을 하고요. >> 그다음에 D를 최종 확정하는 단계로 진행하고 있습니다. 이렇게 해서 넘어가서 빌드 생성이 되면은 그 슈퍼베이스랑 기이랑 버셀 연동을 자동으로 진행해 줘요. 그리고 중요한 거는 그래서 어디까지 AI가 해 줄 거고 어디를 사람이 해야 된다라는 것들을 테스크를 AI가 만들어 줍니다. 그래서 휴먼 테스크라고 하는 부분들은 사람이 좀 진행해야 되는 테스크 예를 들면 버셀 토큰 발급하거나 슈퍼베이스 뭐 발급해야 되는 것들 그런 것들은 AA가 분류해 줘서 사람이 해야 된다라고 하고요. 나머지 페이지 만들거나 API 만드는 것들은 코드 단에서 AI가 이제 실행을 하는 거죠. 요걸 실행할 때는 저희가 [음악] 실제 클로드 코드에서 받아와서 진행을 하고 있고요. >> 네. 제가 봤을 때는 모드가 다 AI 네이티브가 아니고 개발자가 아니다시피 한데 그것들을 표준화할 수 있는 도구로서는 충분히 역할을 하고 있다라고 하는게 저에게는 좀 되게 와닿는 부분이었던 거 같아요. >> 사실 이걸 시작하게 된 뭔가 시작점은 저희 플러그 팀에서 그 저희 B2B 서스 만들면서 AX로 좀 내부 시스템을 좀 많이 바꿨어요. 뭐 마케팅 데이터 분석하는 거부터 시작해서 >> 분기별 플랜 짜는 거. 그리고 그 스프린트를 저희가 한 달에 두 번씩 돌아갔었는데 이거를 >> 좀 개선을 해 >> 한 달에 한 열 개 정도의 스프린트가 동시에 돌아갈 수 있게끔 만드시면서 비개발자분들도이 스프린트에 참여해서 페이지를 개선할 수 있게끔 만들어서 그 일을 하고 계시더라고요. 근데 결국에 대시보드가 필요하고 비계 발자도 처음해서 해야 되다 보니까 그런 테스크 관리나 이런 목적으로서 충분히 그 웹 기반으로 동작을 해야만 했었고 그래서 그걸 만든 걸 보면서 아 우리도 그 빌더를 원래는 저 저랑 이제 저희 그 리더분이나 둘이서 그걸 만들고 있었어요. 저희 거버넌스를 우리가 필요한 >> 네 >> 이게 아니라 이제 팀원들 전체가 쓰려면 팀원들이 사용 가능한 수준으로 만들어져야겠다 싶어서 지금 독빌더가 만들어지고 있다라고 봐 주시면 좋을 것 같아요. [콧방귀] >> 네. 스프린트 관리는 빌더에서 어떻게 할 수 있나요? >> 어, 스프린트는 지금 톡빌더에서는 그냥 페이지로 해서 저희가 관리를 하고 있고요. 사실 요거 그냥 돌려 놓고 이제 집에 갔다 오면은 다 돌아가 있을 거예요. 근데 이걸 한번 돌린다고 해서 완성도 있는 프로젝터 나오지 않아요. 절대로. 그래서 한번 돌리고 나서 그걸 로컬에서 실행해서 띄어 본 다음에 수정 사항들을 다시 테스크로 만들거나 그거를 바이브 코딩으로 클로드 코드 안에서 요청하면 저희가 만들어 놓은 스킬들이 있어서 여기 테스크로 다 올라갑니다.이 테스크도 실제로 로컬에서 실행한 내용들을 테스크로 올려 준 거예요. 그래서 API로 스킬을 다 만들어 놓은 겁니다. 그러면 그 실제로 초기 빌드하고 난 뒤에 페이지 2라든가 3 단계에서 내가 클로드 코드로 작업을 진행하고 있다라고 한다고 하면 어떻게 테스크로 저기 등록이 되는 형태인가요? 스킬이라고 말씀해 주셨는데 그 스킬이라고 하는게 어떤 실체인지 좀 말씀해 줄 수 있을까요? >> 아, 네.이 이 프로젝트 파일이 실제로 방금 보여 드린 여기에 있는 코드를 가져온 거예요. 근데 가져온 저희가 보여 드리면 빌드를 진행하고 나면 토큰이랑 그 실제 코드가 나옵니다. 그래서 요거 복사해 가지고 기본적으로 웹에서 빌드 시작하게 되면은 명령을 복사해서 컴퓨터에 붙여 놓고 실행하게 되면 설치 도구가 저희 로컬의 컴퓨터에 설치를 하고요. 파일을 >> 그다음에 거기도 이제 시작을 하게 됩니다. >> 그러면 실제 프로젝트 폴더가 생기고요. 저희가 클로드 실행해서 여기서 이제 프로젝트 시작해 줘라고 하면은 기존에 저희 기획 자료나 디자인 자료가 탑재된 상태에서 요거 기반으로 투가 쫙 생성이 돼요. 그 투가 여기에 이렇게 올라고요. 그래서거나 여기 자연어로 이제 수정 요청하거나 하면은 그게 이제 여기 반영이 되는데 반영되는 프로세스는 저희가 기존에 이제 만들어 놓은 클로드의 스킬들이 있습니다. 그래서요 스킬들로 테스크를 생성하거나 할 수 있게끔 되어 있고요. >> 그렇군요. 그렇군요. 네. 자세하게 설명해 주셔서 감사합니다. 그러면은이 이제 그 전체적인 이해가 되는데 향후에 좀 부가적으로 보안하고 싶은 그런 포인트가 좀 있으신지가 궁금해요. 뭐 예를 들면은 지금 현재는 공동으로 작업을 처음에 시작을 해서 이니셜하게 이걸 직업한다기보다는 담당 PM이나 혹은 메인 담당자가 이걸 직접 이니셜라이징을 해야 된다고 해야 될까요? 그렇게 해서 진행이 되는 느낌인데 이거를 팀 작업으로는 어떻게 처리하면 좋을지 아니면 뭐 나중에이 팀이이 프로젝트를 이관받아야 될 때라든지 이런 때는 이걸 어떻게 활용할 수가 있을지 좀 궁금합니다. 사실 지금 당장은 저희가 AI 네이티브를 전환하면서 한 명의 담당자가 하나의 프로젝트를 진행하는 방향으로 하려고 하고 있고 근데 규모가 큰 건 그렇게 못 하기 때문에 저희도 궁극적으로는 대형 프로젝트도 여기 안에서 할 수 있게끔 만드는게 목표긴 해서 그런 방향으로 고민은 하고 있긴 하고요. 그리고 일단은 지금 저희 기준으로는이 독빌더로 진행할 수 있는 프로젝트 규모를 한 정 지어서 진행할 거기 때문에 어떻게 보면 예비 창업자들의 첫 번째 프로덕트를 저희가 만들어 드린다 정도 수준이 될 거 같아요. 그래서 그 정도 수준에서 할 수 있는 저희 프로젝트들 규모가 많기 때문에 그런 거를 같이 할 수 있는 프리랜서분들이 들어와서 쓰거나 요런 구조가 될 거 같고요. 그러면 저희는 관리에 대한 프로젝트가 점점 더 많아질거다 보니까 그런 목적으로 어 독빌더를 쓰게 될 거 같습니다. 음. 그렇군요. 독빌더에 대해서 자세하게 설명해 주셔서 너무 감사합니다. 혹시 추가적인 뭐 기능 검토라든가 뭐 반영 계획 같은게 있으세요? 일단은 지금 전체 프로젝트에 저희 그 톡빌더 봇이 들어가 가지고 데이터 수집하고 있는 것들에 대해서 조금 더 PM의 역할을 일차적으로 자동하는 거를 아마 목표로 갈 거 같고요. >> 그다음 PM의 역할이라는게 결국에는 그 소통 커뮤니케이션도 있지만 뭐 프로젝트 관리랑 >> 그리고 테스크 관리 부분도 있어서 실무자들이 조금 빌더들이 빌딩하는 거에 집중할 수 있는 환경을 제공해 주기 위함이고요. 거기에 맞춰서 디자이너 출신의 빌드면 기술적인 파트가 부족할 거니까 그런 것들에 공백을 없앨 수 있게끔 만드는게 톡빌더의 궁극적인 방향성이라고 봐 주시면 좋을 것 같아요. >> 네. 자세한 로드맵을 설명해 주셔서 감사합니다. 정말 필요성이 있는 프로덕트라고 느껴졌었어요. 제가 단순히 개발자라면 개발자분들이 같이이 톡빌더를 쓰면서 어떻게 하면은 좀 함께 어떤 기준을 넘을 수 있는 프로덕트를 같이 만들 수 있느냐에 대한 고민을 이렇게 프로덕트로서 풀어 나간다는게 저게 되게 멋진 지점이었던 거 같고요. 그 내부적으로 AX를 하데 있어서 좀 상당히 많은 도움이 될 거 같다는 생각도 듭니다. 근데 혹시나 뭐 외부 공개를 하실 뭐 계획이나 이런 것들이 또 있으실지가 또 궁금해요. >> 사실 이거를 외부로 공개하게 된다면 붙어야 되는 기능이 많다 보니까 그렇게는 좀 어려울 다만 실제로 그 톡빌더의 기본 베이스를 기반으로 다른 프로젝트도 외주 형태로 많이 하고 있어요. 그래서 어떻게 보면 그 AX를 위한 경험인 거 같아요.이 경험을 새로운 또 대시보드를 만들 수 있는 좀 바탕이 된 거죠. 그래서 그렇게 지금 마케팅 에이전시 쪽이랑 협업하는 것도 있고요. 그렇습니다. 앞으로는 그 똑똑한 개발자에서 내부적으로 이런 AX를 이제 빌딩을 하실 거 같은데 이제 내부적인 그런 구성원들이 이렇게 기술 역량을 이렇게 높아가는 거 외에 AX를 실제로 실현하고자 하는 조직들에게 좀 해 주실 만한 어떤 조언 같은게 있으실지도 궁금하더라고요. >> 그러니까 AX를 굉장히 진지하게 검토 중인 회사들이 상당히 많거든요. 요즘은 대표님께서는 내부적으로 구성원들이 AX를 하고자 한다면 무엇부터 시작하는게 좋을지 한번 고견을 여주고 싶습니다. >> 조시님도 매우 공감하실 것 같긴 한데 조직마다 AI를 사용하는 수준이 굉장히 다르기 때문에 저는 일단 그거부터 파악해야 되는 거 같아요. 우리 팀원들이 어디에 와 있는가. 예를 들면 아직도 GPT에 채팅하는 수준으로 쓰고 있는데 갑자기 클로드코 도입한다 하면은 이제 힘들 거니까 그런 일차적으로 수준을 파악하고 나서 도입을 어떻게든 일차적으로는 시도를 해야 되는 거 같아요. 그냥 전사 클로드 코드 아니면 재미나에 뭐 도입합시다 해서 일단은 도입하는게 전 우선인 거 같고요. 제가 옛날에 컨설팅하다가 한번 그 들었던 질문 중에 본인은 조직 내에서 AI을 가장 잘 쓰고 있어서 이제 본인의 업무는 AI 전문가로 오는게 아닌데 팀원들한테 AI 교육을 하고 있는 상황이 된 거죠. 근데 마치 그게 자기의 노하우를 자꾸 팀원들한테 전달하다 보니까 나의 전문성이 사라지는 거 같아서 고민이 되는 분들도 계시더라고요. 이제 그런 그 잘하는 개개인을 좀 빨리 발굴할 수 있는 그래서 그게 우선이지 않을까 싶고 그리고 저는 기업 관점에서 보면은 우리 회사가 일단 디지털 전환은 되어 있는가를 먼저 봤으면 좋겠어요. 그니까 DX가 안 되어 있는데 AX를 뭔가 하려고 시도하는 케이스가 정말 많아서 그게 좀 쉽지 않은 거 같습니다. >> DX가 안 돼 있다는 뜻은 어떤 걸까요? 그 우선은 데이터 수집 관점인 거 같아요. 뭐 예를 들면 영업을 최적하고 싶다라고 하는데 그거를 뭐 누군가가 당연히 통합을 해서 엑셀로 관리하고 있어야 될 텐데 그게 아니라 개개인의 뭔가 개인기로 관리가 되고 있다면 그거는 사전에 좀 일하는 방식부터가 바뀌어져야 되잖아요. AI를 도입하는 많은 회사들이 기술의 도입으로 생각하시는 거 같은데 제 생각에는 기술의 도입보다는 환경의 변화인 거 같아요. 그 일하는 환경이 별 건데 그게 뭔가 기술의 도입이라고 해서 컨설팅 받는다고 해결되는게 아니라 전체의 그 리듬을 바꿔야 되는데 >> 네. 거기까지 고민을 하하셔야 되지 않을까 싶은 생각이 좀 듭니다. >> 진짜 맞는 말씀이신 거 같아요. dx 앞서 dx가 무엇이냐라고 해서 좀 질문을 드린 바 내부적인 데이터 수집이 안 돼 있는 경우가 상당히 많은 조직들이 있는데 뭐 예를 들면 영업을 하는 조직이라고 한다고 하더라도 각자가 뭔가 회의록을 한 곳에 모은다던가 가지고 있는 많은 안목지와 지식들 그리고 하는 활동들이 한 곳에 안 모이는 경우가 상당히 태반인 거 같은데 대표님 회사는 그 데이터 적제 그러니까 한 곳으로 모으기 위해서는 어떤 걸 하시는지 그런 것들 좀 더 알려 주신다면 더 많은 또 도움이 될 거 같아요. 저희는 예를 들면 미팅 회의로은 무조건 캐럿으로 녹음을 해서 기록하고 있고요. 거기에 API 연결해서 >> 실제로 데이터를 프로젝트별로 수집을 하고 있습니다. 그래서 각 프로젝트별로 데이터를 수집하는 거를 궁극적으로 목표를 하고 있고요. 그다음에 그 자산화 측면에서는 결국에 실무자분들 개개인이 어떤 프로젝트를 진행해 왔고 어떤 연차고 확력은 어떻게 되고 이런 데이터들을 기록하는 목적으로 쓰고 있어요. 저희도 원래 노션을 쓰다가 이제 독빌더를 만나면서 프로젝트 관리 관련해서선 다 내제화하고 있는 중이고요. >> 네. 마지막으로 두 가지 질문만 좀 드리고 끝내고 싶은데요. 일단 그 이런 데이터 적재도 보면은 결론적으로 거버넌스 측면으로 빠질 것 같아요. 이게 노션 같은 경우야 뭐 어떤 위키 같은 개념으로이 전체적으로 정리가 되겠지만 지금 이런 그 회의록 데이터나 혹은 이제 실무자들의 데이터 자체가 어떻게 관리가 돼야 되느냐에 대한 이슈가 또 따로 발생이 된다고 생각이 들거든요. 그런 부분에서 대표님은 어떻게 현재 관리하고 계신지가 좀 궁금하고요. 그리고 데이터 적제는 이렇게 해야 한다라고 하는 어떤 조언 같은게 있으시다면 말씀해 주시면 감사하겠습니다. >> 저희는 그 어떻게 보면 프로젝트 단위로 데이터가 많은데 그 프로젝트가 끝나고 나면 그 데이터가 사실 결국에는 불필요해지거든요. 이런 방대한 데이터가 저희의 고민은 계약을 하고 나서 끝난 프로젝트인데 다시 추가 계약을 하게 되는 경우 과거의 이역이나 이런 것들을 저희가 알아야지만 다음 담자한테 그 맥락을 전달할 수 있을 텐데 그런 목적으로 프로젝트 당 하나의 테이블을 구성한다든지 이런 식으로 해서 그게 필요한 시점에 불러올 수 있게끔 하는데 레그나 뭐 뭐 벡터디나 이런 거는 사실 저희는 안 쓰고 있고요. 저희 다 그냥 MD 거의도 진행하고 있고. 근데 말씀하신 데이터 관리 측면에서는 어 저는 그게 진짜 중요한 거 같더라고요. 데이터가 많다고 해서 좋은 것도 아닌 거 같고 어 정말 그 핵심적인 것들만 보고 결국엔 의사 결정을 사람이 하는게 중요한 거 같아요. 의사 결정까지 AI가 할 수 있도록 더 많은 데이터들과 우리가 진행했던 의사 결정 다 넣어 주고서 딸각으로 되게끔 만드는 거 자체가 조금 불가능하다라는 거를 마음에 품고 최대한 그 도움을 받을 수 있는 것들을 받아서 실제로 우리가 핵심으로 생각하는 그 중요한 지표들 위주로만 해 가지고 꾸준히 사람이 검수하고 우리 조직에 맞춰서 데이터 적재하는 그 구조를 만들어야 되는게 맞지 않을까 싶습니다. 참 어려운 거. 아, 너무 훌륭한 답변이네요. 그러니까 단순히 모든 데이터들을 다 넣었다고 해서 답변 품질이 좋아지는게 아니라 사람이 어느 정도는 유의해 했었던 그런 부분들을 별도로 정리를 해서 그걸 가지고 AI가 활용을 하게끔 만드는게 정말 중요하다라는 말씀이신 거 같아요. 네. 너무너무 훌륭한 답변 감사드리고요. 네, 오늘 이렇게 해서 지금 굉장히 많은 이야기를 나눴습니다. 끝으로 이제 저희 구독자님들께 하시고 싶은 말씀이라든가 뭐 홍보하시고 싶은 그런 내용 있으신지 궁금합니다. >> 사실 저희도 그 유튜브를 시작한지 얼마 안 됐다 보니까 저희 채널 보고 문의를 주시는 분들이 많으신데 저희가 사실 그 본업도 있고 하다 보니까 본이 아니게 답장을 못 하는 경우가 좀 많이 생기는 거 같아요. 그래서 혹시라도 궁금하신 분 있으실 때 좀 상세하게 남겨 주시면 좋지 않을까라는 말씀을 드리면서 네. 오늘 좋은 시간 만들어 주셔서 감사합니다. >> 네. 저도 좋은 시간 이렇게 함께 해 주셔서 정말 감사드리고요. 네. 오늘 이렇게 똑똑한 개발자 서장원 대표님과 같이 이야기를 나눠봤는데 이게 단순히 개발자분들과 그리고 비발자분들이 이렇게 같은 눈높이에서 일을 할 수 있게끔 현경을 설정한다는 거 자체가 사실 대단한 거 같아요. 저 좀 저는 굉장히 좀 많은 상상이 깊었고요. 오늘 이렇게 함께 출연해 주신 어 서장원 대표님 저 유튜브 AI 서대표 채널 여기 나가고 있으니까 꼭 많이 구독해 주시고 또 많은 사랑 부탁드리도록 하겠습니다.네 네. 오늘 지금 이렇게 빌더 조시 하우와 AI 팟캐스트는 여기서 마무리하도록 하겠습니다. 저희는 또 다음번에 또 도움 좋은 분 만나고 AI 관련된 이야기 또 하도록 할게요. 감사합니다. 다음에 뵙겠습니다. 감사합니다.