🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

외주 개발 곧 사라진다는 주장은 단순한 위기론이 아니라, AI 네이티브 전환으로 기획·디자인·개발·PM·고객 커뮤니케이션까지 에이전시의 핵심 프로세스가 재편되고 있다는 현장 진단이다.

📌 핵심 요점

1. 외주 개발 에이전시의 변화는 개인이 AI 도구를 잘 쓰는 수준을 넘어, 영업 이력 수집부터 PRD 작성, 화면 구조 생성, 빌드, 배포 연동, 인수인계까지 조직 전체 워크플로를 AI 기반으로 다시 짜는 문제로 확장되고 있다.
2. 똑똑한개발자는 약 10년간 에이전시를 운영해 온 경험 위에서 B2B SaaS 플러그와 내부 AX 도구 똑빌더·톡빌더를 함께 실험하며, 외주 매출이라는 현실적 캐시카우와 프로덕트 성장 투자 사이의 긴장을 동시에 안고 있다.
3. AI 네이티브 전환은 기획자·디자이너·프런트엔드·백엔드·PM 같은 기존 직무 경계를 흐리게 만들고, 한 사람이 여러 역할을 수행하는 프로덕트 빌더 모델로 조직 구조와 산출물 기준을 바꾸고 있다.
4. 다만 전환은 기술보다 조직 변화의 문제에 가깝다. 빌더 전환 과정에서 팀원들이 급격한 변화로 받아들이거나 퇴사 사례가 발생했고, PM 역할을 AI 에이전트로 대체하는 실험도 아직은 사람의 확인과 보완이 필요한 단계로 설명된다.
5. 똑빌더·톡빌더의 핵심은 판매용 툴보다 내부 운영 시스템에 가깝다. 계약 이후 인력 배정, 프로젝트 생성, 슬랙 채널 운영, 자료 수집, PRD·IA·디자인 산출물 생성, 고객 만족도 감지, 태스크 관리까지 에이전시 업무를 데이터화·자산화하려는 시도다.

🧩 배경과 문제 정의

• 외주 개발 중심의 IT 에이전시 모델은 AI 네이티브 전환과 함께 직무, 산출물, 고객 대응 방식이 동시에 흔들리는 국면에 들어섰다.
• 이제 핵심 과제는 개인 생산성 향상을 넘어, 조직 전체의 업무 흐름과 고객 프로젝트 온보딩을 AI 기반으로 통합하는 것이다.
• B2B 에이전시의 캐시카우를 유지하면서 B2B SaaS 성장 가능성도 함께 만들어가야 하는 현실 속에서, 생존 중심 운영과 비전 투자의 긴장이 커지고 있다.
• AI 도입은 단순히 도구를 하나 더 쓰는 문제가 아니라, 기획자·디자이너·개발자·PM 등 기존 역할의 경계를 다시 정리하게 만드는 변화로 작동한다.

🕒 시간순 섹션별 상세정리

1. AI 네이티브 전환과 내부 시스템화의 출발점

• 외주 개발업이 장기적으로 사라질 수 있다는 문제의식에서 출발해, 영업 이력 관리·프로젝트 생성·실무자 초대·자료 수집·PRD 작성·빌드 생성까지의 흐름을 AI 기반 내부 시스템으로 통합한다 [00:56]
• PRD 작성 단계에서 화면 구조와 페이지가 함께 생성되고, 빌드 이후 슈퍼베이스·깃·버셀 연동까지 자동으로 이어지면서 기존 외주 프로세스의 상당 부분이 자동화 대상이 된다 [01:11]

2. 에이전시 10년 경험과 프로덕트 빌더 정체성

• 똑똑한개발자는 약 10년간 운영된 IT 에이전시로, 개발자 커리어에서 출발해 현재 약 30명 규모의 팀과 B2B SaaS 신사업 플러그를 함께 운영하고 있다 [01:56]
• AI 서대표 채널은 작년 하반기부터 AI 프로젝트와 내부 AX 고민을 콘텐츠로 풀어내려는 흐름에서 시작됐으며, 에이전시 운영 경험과 AI 전환 실험이 맞물려 있다 [02:11]

3. 외주와 SaaS를 병행하는 이유와 성장 투자 부담

• 똑똑한개발자는 단순한 사이트·앱 제작보다 비즈니스적으로 성공하는 IT 프로덕트를 만드는 팀을 지향해 왔고, 고객의 성공을 돕기 위해서는 먼저 자체 성공 경험이 필요하다고 판단했다 [03:19]
• 플러그 이전에도 여러 시도와 실패가 있었으며, 플러그는 월 BEP를 넘긴 프로덕트로 내부에서 의미 있는 성공 사례가 됐다 [03:46]

4. AI 개발 전환이 직무와 산출물 요구를 흔드는 방식

• 기존의 기획자·디자이너·프런트엔드·백엔드 직무 구분은 AI 네이티브 빌더 또는 프로덕트 빌더 형태로 통합되는 방향으로 재정의된다 [06:53]
• 프로젝트에 따라 기존 산출물이 여전히 필요한 경우도 있지만, 먼저 개발을 진행하고 이후 디자인을 뽑는 방식처럼 업무 순서 자체가 바뀌는 사례도 나타난다 [07:08]

5. 빌더 전환의 조직 충격과 PM 역할의 AI 대체 실험

• 빌더라는 이름은 여러 역할을 아우르는 책임을 뜻하기 때문에, 직원 입장에서는 기존 직무 범위를 넘어서는 부담과 반발이 생길 수 있다 [08:15]
• 회사는 전환 방향을 제시하되 정답을 함께 찾아가려는 점진적 접근을 의도했지만, 팀원들에게는 훨씬 급격한 변화로 받아들여졌고 팀 전체가 퇴사하는 사례까지 발생했다 [08:30]

6. 에이전시 업의 소멸 가능성과 AI 네이티브 전환 방향

• 장기적으로 에이전시 비즈니스 자체가 사라질 수 있으며, AI 네이티브 전환의 목적은 기존 대행업을 스스로 대체하는 방향에 가깝다 [10:30]
• 핵심은 IT 전문성을 가진 실무자가 AI를 활용해 하나의 산업을 대체하거나 생산성을 극대화하는 경험을 쌓고, 이를 이후 다른 조직에 적용하는 것이다 [10:51]

7. 내부 AI 사례 공유와 조직 내 확산 문제

• 매주 목요일 AI 사례 공유회를 열어 구성원들이 실제 AI 활용 방식을 서로 확인하고, 프로젝트별로 분리된 팀 사이의 접점을 보완한다 [11:26]
• 에이전시 조직은 프로젝트 단위로 움직여 A 프로젝트와 B 프로젝트 구성원 간 교류가 적기 때문에, 공유회는 개인의 AI 활용법을 조직 지식으로 전환하는 장치가 된다 [11:39]

8. 클로드 전환과 공통 스킬 공유의 한계

• 올해 2월 클로드 오퍼스 모델 이후 팀 전체가 클로드로 전환했고, 초기에는 클로드에서 만든 스킬을 거버넌스로 묶어 공통 스킬처럼 공유하려 했다 [12:30]
• 그러나 스킬 공유 방식은 실제 확산이 잘 되지 않았고, 결국 클로드 코드 기반이 아니라 웹에서 동작하는 방식으로 스킬과 작업 환경을 재구성하는 방향으로 바뀌었다 [12:45]

9. 내부 도구가 쓰이지 않는 이유와 워크플로 적합성

• 내부 구성원을 위해 만든 도구라도 사용자가 불편하다고 느끼면 쓰이지 않고, 원하지 않는 기능은 아무리 좋아도 실제 사용으로 이어지지 않는다 [13:51]
• 클로드 코드 터미널이 더 편한 상황에서 웹사이트에 들어가 스킬을 내려받고 연동하는 과정은 불필요한 절차가 되며, 기존 워크플로보다 확실히 편해야만 사용된다 [14:11]

10. 똑빌더의 전체 프로세스와 프로젝트 자산화 구조

• 똑빌더는 판매용 서비스가 아니라 계약 이후 투입 검토, 프로젝트 시작, 디자인, 개발, 인수인계, 자산화까지 프로덕트 제작 전 과정을 AI 친화적으로 처리하는 워크 대시보드다 [15:43]
• 에이전시에서는 계약 후 인력 배정 검토가 필요하며, 조직 규모가 커질수록 누가 어떤 프로젝트를 맡고 있는지, 어떤 프로젝트가 지연되는지 파악해 적절한 인력을 고르는 난도가 높아진다 [16:25]

11. 커뮤니케이션 데이터 수집과 고객 만족도 감지

• 슬랙 채널과 클라이언트·팀원 간 대화가 매일 로우 데이터로 수집되고, 프로젝트 이슈 추적과 요청 누락 감지를 위한 지식 베이스로 저장된다 [20:11]
• 에이전트는 화면에 직접 드러나지 않고 API나 훅으로 데이터를 모아 DB에 적재하며, 별도 헤르메스가 DB 조회 권한과 조건값을 받아 프로젝트 데이터를 조회한다 [20:46]

12. 기능 완성보다 중요한 고객 감정과 운영 거버넌스

• 관리자뿐 아니라 실무자도 이슈를 놓치거나 인지하지 못할 수 있으며, 개발자에게는 단순 기능 요청처럼 보여도 그 안에 고객 만족도 하락 지점이 숨어 있을 수 있다 [22:05]
• 에이전시 업무에서 기능을 잘 만드는 것은 기본값이고, 프로젝트 성공에는 커뮤니케이션과 고객 감정 상태를 추적하는 운영 역량이 더 중요한 요소가 된다 [22:24]

13. 영업 자료부터 PRD 초안까지 이어지는 AI 네이티브 기획

• 프로젝트가 시작되면 영업 과정에서 오간 이메일, 마크다운 파일, 기획서, RFP 같은 자료가 수집되고, 이 자료들이 초기 기획 생성의 기반이 된다 [24:11]
• 클라이언트가 상세 자료를 제공하지 않아도 통화 내용과 기본 정보가 기획의 출발점이 되며, 이후 단계부터 AI가 계속 개입한다 [24:35]

14. 검토 페이지, IA, 디자인 산출물로 이어지는 표준화

• 다음 단계에서는 기획이 생성되고 검토 페이지가 나오며, 로그인 페이지나 비회원 접근 가능 여부처럼 권한별·페이지별 구성을 추가할 수 있다 [26:06]
• 추가 코멘트를 반영해 완성하면 상세 기획서와 IA가 생성되고, 이미 AI 네이티브 방식으로 진행한 프로젝트 산출물을 기준으로 원하는 수준까지 스킬을 다듬는다 [26:36]

15. 휴먼 인 더 루프와 빌드 자동화의 역할 분리

• AI 사용 데이터는 개인 화면에서 목적, 토큰 사용량, 비용까지 대시보드로 추적되며, AI 활용 자체도 운영 지표로 관리된다 [27:51]
• 생성된 PRD는 바로 확정되지 않고 LLM 비평을 거쳐 네다섯 가지 항목 기준으로 다음 단계 진행 가능 여부를 점검한다 [28:02]

16. 톡빌더의 태스크 관리와 로컬 실행 기반 반복 구조

• 톡빌더는 일부 리더만 내부 도구를 만들던 방식에서 벗어나, 팀원 전체가 활용할 수 있는 거버넌스 체계로 확장하기 위해 개발되고 있다 [30:00]
• 스프린트는 톡빌더 안에서 페이지 단위로 관리되며, 초기 빌드만으로 완성되지 않기 때문에 로컬 실행과 수정 태스크 생성이 반복되는 구조로 운영된다 [30:21]

17. 기획·디자인 자료 기반 생성과 팀 작업 확장 한계

• 프로젝트 폴더에서 클로드를 실행하면 기존 기획·디자인 자료가 반영된 상태로 도구가 생성되고, 이후 자연어 수정 요청과 생성 결과가 톡빌더에 반영된다 [31:38]
• 클로드 스킬은 태스크 생성과 수정 요청 반영을 맡으며, 초기 빌드 이후 2단계·3단계 작업까지 로컬 작업 흐름을 톡빌더의 관리 흐름과 연결한다 [32:00]

18. PM 자동화와 빌더 역량 보완을 향한 로드맵

• 톡빌더 봇은 전체 프로젝트에 들어가 데이터를 수집하고 있으며, 장기적으로는 PM 역할의 일부를 자동화해 프로젝트 관리와 태스크 관리 부담을 줄이는 것을 목표로 한다 [33:40]
• PM 역할에는 커뮤니케이션뿐 아니라 프로젝트 관리와 태스크 관리가 포함되므로, 실무자가 빌딩 자체에 더 집중할 수 있는 환경을 만드는 것이 중요하다 [33:51]

19. AX 도입의 출발점은 구성원 수준 파악과 DX 기반 점검

• 조직마다 AI 활용 수준의 편차가 크기 때문에, 아직 GPT 채팅 수준에 머문 팀에 곧바로 클로드 코드를 도입하면 전환 난도가 크게 높아진다 [35:47]
• 전사적으로 클로드 코드나 제미나이를 먼저 시도해보는 과정이 필요하며, 조직 안에서 AI를 잘 활용하는 개인을 빠르게 발굴하는 일이 우선 과제가 된다 [36:07]

20. 데이터 적재·거버넌스·프로젝트 맥락 관리

• AI 도입은 단순한 기술 도입이 아니라 일하는 환경과 조직 리듬의 변화에 가깝기 때문에, 컨설팅만으로는 부족하고 데이터 수집과 업무 방식 재설계가 함께 필요하다 [37:13]
• 미팅 회의록은 캐럿으로 녹음·기록한 뒤 API로 연결하고, 프로젝트별 데이터를 축적해 각 프로젝트의 운영 맥락을 남기는 구조를 지향한다 [38:03]

21. AI 의사결정 자동화의 한계와 사람 중심 데이터 구조

• AI가 의사결정까지 모두 맡으려면 더 많은 데이터와 기존 의사결정 기록이 필요하지만, 모든 과정을 한 번에 자동화하는 방식은 현실적으로 어렵다 [40:00]
• 조직은 AI의 도움을 받을 수 있는 영역을 선별하고, 실제로 중요한 핵심 지표를 중심으로 사람이 지속적으로 검수하는 구조를 만들어야 한다 [40:11]

22. 문의 방식과 개발자·비개발자 협업 환경의 의미

• 유튜브 채널을 시작한 뒤 문의가 늘었지만 본업과 병행하다 보니 답장을 놓치는 경우가 있어, 궁금한 내용은 가능한 한 상세히 남기는 방식이 도움이 된다 [40:55]
• 개발자와 비개발자가 같은 눈높이에서 일할 수 있는 환경을 만드는 일은 단순한 도구 도입을 넘어, 협업 방식 자체를 바꾸는 핵심 변화로 압축된다 [41:24]

🧾 결론

• 이 영상의 핵심 메시지는 외주 개발이 당장 모두 사라진다는 단정이라기보다, 기존 방식의 외주 개발 에이전시는 AI 네이티브 업무 방식에 적응하지 못하면 점점 경쟁력을 잃을 수 있다는 경고에 가깝다.
• AI 도입의 본질은 툴 구매나 자동화 기능 추가가 아니라, 조직 안의 데이터 흐름·업무 순서·역할 정의·고객 커뮤니케이션 방식을 다시 설계하는 데 있다.
• 특히 에이전시 업에서는 기능을 잘 만드는 것만으로는 부족하고, 고객의 요청 누락, 불만 신호, 프로젝트 지연, 인력 배정, 과거 프로젝트 맥락까지 관리하는 운영 역량이 AI 전환의 핵심 대상이 된다.
• 똑빌더와 톡빌더 사례는 AI가 사람을 완전히 대체한다기보다, 사람이 하던 반복적 관리·정리·초안 생성·맥락 수집을 시스템 안으로 옮겨 실무자가 더 중요한 판단과 빌딩에 집중하도록 만드는 방향으로 제시된다.
• 검증이 필요한 부분은 “외주 개발이 곧 사라진다”는 시간표와 범위다. 영상에서는 장기적 소멸 가능성과 자기 파괴적 전환 방향을 말하지만, 모든 외주 시장이 언제 어떤 속도로 사라질지는 별도 시장 데이터와 사례 검증이 필요하다.

📈 투자·시사 포인트

• 에이전시와 SI 시장에서는 단순 개발 인력 공급보다 AI 기반 프로젝트 운영, 고객 커뮤니케이션 분석, PRD·IA·디자인·코드 생성 워크플로를 통합하는 역량이 차별화 요소가 될 가능성이 크다.
• B2B SaaS 관점에서는 “AI 기능” 자체보다 기존 업무 흐름에 자연스럽게 붙는지가 중요하다. 클로드 코드 터미널보다 불편한 내부 스킬 대시보드는 확산되지 않았다는 사례처럼, 워크플로 적합성이 adoption의 핵심 변수다.
• 조직 전환 관점에서는 AI를 잘 쓰는 개인을 찾는 것만으로는 부족하다. 개인 노하우를 조직 지식으로 바꾸는 공유회, 데이터 적재, 표준화된 프로젝트 관리, 휴먼 인 더 루프 구조가 함께 필요하다.
• 개발자·디자이너·기획자에게는 단일 직무 전문성만으로는 역할이 좁아질 수 있고, AI를 활용해 기획·디자인·구현·운영 맥락을 연결하는 빌더형 역량이 더 중요해질 수 있다.
• 투자 관점에서 검증이 필요한 지점은 AI 네이티브 에이전시 모델이 실제로 매출총이익률, 납기, 고객 만족도, 재계약률을 얼마나 개선하는지다. 영상은 내부 실험과 방향성을 보여주지만, 정량 성과는 별도 확인이 필요하다.

⚠️ 불확실하거나 확인이 필요한 부분

• 영상에서는 “외주 개발 업 자체가 장기적으로 사라질 수 있다”는 강한 문제의식이 제시되지만, 실제 시장 전체가 어느 속도와 범위로 축소될지는 별도 데이터 확인이 필요하다.
• 똑빌더와 톡빌더가 내부에서 어느 정도까지 실제 운영 효율을 개선했는지, 예를 들어 프로젝트 리드타임 단축률·인력 배정 정확도·고객 만족도 개선 수치 등은 영상 내용만으로는 확인되지 않는다.
• PM 역할을 AI 에이전트로 대체하는 실험은 진행 중이지만, 현재 단계에서는 사람이 확인하고 보완해야 하는 일이 계속 발생한다고 언급되므로 완전 대체 가능성은 검증이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 외주 개발 조직이라면 현재 프로젝트 흐름을 영업·계약·온보딩·기획·디자인·개발·인수인계·자산화 단계로 나누고, 각 단계에서 AI가 맡을 수 있는 업무와 사람이 반드시 검토해야 할 업무를 구분한다.
• 조직 내 AI 활용 수준을 먼저 진단하고, GPT 채팅 수준에 머문 구성원과 클로드 코드·바이브 코딩까지 가능한 구성원을 분리해 교육·도구 도입 단계를 다르게 설계한다.
• 개인이 잘 쓰는 AI 활용법이 조직 지식으로 남도록 정기 공유회, 사례 아카이브, 프로젝트별 사용 패턴 기록 체계를 만든다.
• 내부 도구를 만들 때 “기능이 좋은가”보다 “기존 워크플로보다 더 편한가”를 우선 검증하고, 슬랙·문서·로컬 개발환경 등 실제 업무 접점에 자연스럽게 붙이는 방식을 우선한다.

❓ 열린 질문

• 외주 개발사가 AI 네이티브 조직으로 전환할 때, 기존 기획자·디자이너·프런트엔드·백엔드 역할은 어디까지 통합되고 어디부터는 전문 직무로 남아야 할까?
• PM 역할 중 AI가 먼저 대체하기 좋은 업무는 태스크 정리·회의록 요약·요청 누락 감지일까, 아니면 고객 감정 관리와 우선순위 조정까지 포함할 수 있을까?
• 내부 AI 도구가 실제로 사용되게 만들려면 웹 대시보드, 슬랙 봇, 로컬 CLI, IDE 플러그인 중 어떤 접점이 가장 효과적일까?