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

한 줄 요약

IT 에이전시 '똑똑한 개발자'를 10년 가까이 운영해 온 서장원 대표는 장기적으로 외주 대행업 자체가 사라질 거라고 봐요. 그래서 회사를 AI 네이티브로 바꾸고 계약부터 인력 배정·기획·빌드까지 한 화면에서 굴러가는 내부 도구 '똑빌더'를 만들고 있습니다. 팀 하나가 통째로 사라진 일, 만들어 놓고 아무도 안 쓴 도구, DX 없이 AX부터 하려는 회사들의 함정까지 솔직하게 풀어놓은 대담이에요.

전체 내용 정리

외주가 본업인 회사가 왜 자기 제품을 만들까요

서장원 대표는 개발자로 커리어를 시작해 '똑똑한 개발자'라는 IT 에이전시를 10년 차쯤 운영하고 있어요. 팀원은 30명 정도이고 내부 신사업으로 플러그라는 B2B SaaS(CRM 서비스)도 함께 돌립니다. 유튜브 채널 'AI 서대표'는 작년 하반기부터 AI 프로젝트를 하고 내부 AX(AI 전환)를 고민한 과정을 콘텐츠로 담아 보자며 시작한 채널이에요.

회사는 원래 'IT 외주 개발'보다 '프로덕트 빌더', 즉 IT 프로덕트 에이전시로 브랜딩해 왔어요. 사이트나 앱을 납품하는 게 아니라 비즈니스적으로 성공하는 서비스를 만드는 게 목표였거든요. 그러려면 우리가 먼저 성공해 봐야 하지 않나 싶어서 플러그 이전에도 시도를 많이 했고 실패도 많았다고 해요. 플러그는 월 손익분기점(BP)을 넘기면서 내부에서 처음으로 '성공한 제품'으로 자리 잡은 사례입니다.

그럼 왜 외주를 접지 않을까요? 현실적인 이유는 외주 매출이 아직 플러그 매출보다 많기 때문이에요. 여기에 서장원 대표 본인이 외주를 좋아하는 개발자 출신이라 다양한 클라이언트를 만나는 일이 즐겁다고 덧붙였어요.

투자 이야기도 나왔어요. 회사가 이미 모회사에 M&A된 상태라 투자를 받기는 어렵다고 해요. 플러그를 여기까지 끌고 오는 데 3년 정도 걸렸고, 마케팅 효율이 잘 나와서 지금보다 10배 정도 올리면 임팩트가 클 거라고 예상은 한대요. 모회사도 마케팅비를 더 쓰라고 권하고요. 그런데 돈을 벌고 살아남는 게 우선인 에이전시 일을 해 온 사람이 갑자기 비전에 베팅해야 하는 자리에 서니 두려움이 있다고 솔직하게 털어놨어요.

직무를 '빌더' 하나로 합쳤더니 팀 하나가 사라졌어요

진행자 조쉬는 예전처럼 손으로 코딩하는 개발자가 거의 없어진 지금 에이전시가 어떻게 바뀌었는지 물었어요. 서장원 대표는 AI 네이티브를 선언하면서 기획자·디자이너·프론트엔드·백엔드로 나뉘어 있던 직무를 'AI 빌더', '프로덕트 빌더' 하나로 합치자고 했어요.

다만 프로젝트마다 사정이 달라서 지금은 꽤 혼란스러운 상태라고 해요. 진보적인 기업은 피그마(Figma, 디자인 협업 툴)를 안 써도 되니 원하는 결과물만 달라고 합니다. 반대로 피그마 산출물은 꼭 있어야 하고 API 명세는 엑셀 양식에 맞춰 달라는 기업도 있어요. 그러다 보니 개발을 먼저 하고 디자인을 나중에 뽑는 순서 뒤집힘도 생겼어요. 작은 스타트업이라면 한 사람이 기획·디자인·개발을 다 하는 환경이 이미 만들어졌다고 봅니다.

조쉬가 직원 입장에선 그 일까지 다 떠맡아야 하나 싶은 반발이 있지 않겠냐고 묻자 서장원 대표는 그게 굉장히 민감한 부분이었다고 인정했어요. 방향은 그쪽이지만 당장 바꾸진 않고 정답을 같이 찾아가자는 생각이었는데, 팀원들은 훨씬 급하게 받아들였던 거죠. 실제로 팀 전체가 퇴사해 팀이 사라진 경우도 있었어요. 사라진 게 PM 팀입니다.

팀이 없어져도 PM이 하던 일은 남잖아요. 남은 팀원들이 그 역할을 나눠 맡았고 PM 역할을 에이전트로 대체하자는 아이디어가 나왔어요. 지금은 모든 슬랙 채널에 에이전트가 들어가 대화를 모으고 할 일 목록을 만듭니다. 그래도 AI가 사람을 100% 대체하진 못해서 사람이 들여다봐야 하는 일이 계속 새로 생긴대요.

서장원 대표는 직무 구분이 많이 흐려지고 있다고 봐요. 마케터도 AI를 열심히 공부하면서 회사가 준비 중인 강의의 계획서와 자료를 같이 만들고 있거든요. 조쉬는 여기에 DRI(Directly Responsible Individual, 한 업무를 끝까지 책임지는 사람) 개념을 얹었어요. 직원 각자가 하나의 비즈니스를 도맡고 그 아래에 '빌더'라는 층이 있어야 한다는 게 조쉬의 생각이에요.

"에이전시업 자체가 이제 필요 없어질 것 같아요"

큰 그림을 묻는 질문에 서장원 대표의 답은 꽤 과감했어요. 장기적으로는 에이전시라는 업 자체가 없어질 거라고 봅니다. 그래서 팀원들에게 AI 네이티브를 서둘러야 하는 이유를 그 업을 우리가 먼저 없애자는 취지로 설명하고 있대요. 서장원 대표의 말로는 "우리가 없애자라는 취지로" 지금 움직이고 있다고 해요.

그 과정에서 회사에 쌓이는 건 경험이에요. IT 전문성이 있는 실무자들이 AI로 한 산업을 없애 보거나 생산성을 끝까지 끌어올려 본 다음, 그 방법을 다른 조직에 적용해 보는 것이 서장원 대표가 그리는 방향입니다.

실제 활동은 두 갈래예요. 하나는 AX용 내부 제품인 똑빌더를 만드는 일이고, 다른 하나는 매주 목요일 여는 AI 사례 공유회예요. 팀원들과 원온원(1:1 면담)을 해 보니 생각보다 다들 AI를 너무 잘 쓰고 있었대요. 그런데 에이전시는 프로젝트 단위로 움직여서 A 프로젝트 사람과 B 프로젝트 사람이 마주칠 일이 별로 없어요. 옆자리 사람이 AI를 어떻게 쓰는지 서로 알게 하려고 공유회를 열고, 찍은 영상은 거의 편집 없이 유튜브에 올리고 있습니다.

스킬 공유 웹사이트를 만들었는데 아무도 안 썼어요

도구는 올해 2월 클로드(Claude) 오퍼스 모델이 나온 뒤로 전부 클로드로 바꿨어요. 처음엔 클로드에서 만든 스킬(skill, 반복 작업을 묶어 둔 지시 모음)을 회사 공통 스킬로 정리해 공유하자는 데서 출발했는데, 그렇게 해도 공유가 잘 안 됐대요. 그래서 스킬을 클로드 코드(Claude Code) 기반이 아니라 웹에서 돌아가는 형태로 옮겼습니다.

조쉬는 다른 회사들도 '스킬 대시보드'를 만들어 공유한다는 얘기를 많이 들었지만 토스 정도를 빼면 잘된 사례를 거의 못 봤다고 했어요. 서장원 대표의 답도 비슷했어요. 쓰려고 만들었는데 결국 안 쓰게 됐다는 거죠.

이유는 플러그를 만들면서 이미 배운 것과 같았어요. 아무리 좋은 기능도 유저가 원하지 않으면 안 쓰잖아요. 리더가 필요해서 만들고 쓰라고 해도, 팀원 입장에선 클로드 코드 터미널이 훨씬 편한데 굳이 웹사이트에 들어가 스킬을 내려받고 Git과 연동하는 게 쓸데없는 일이 돼 버린 거예요.

클로드 코드 쓰는 것보다 이게 훨씬 편하다는 경험을 주지 못하면 절대 안 쓴다는 결론이 나왔고, 그래서 팀원을 고객으로 놓고 정말 쓸모 있는 서비스를 만드는 쪽으로 방향을 틀었어요.

조쉬도 비슷한 경험을 꺼냈어요. 오픈클로(OpenClaw) 에이전트를 슬랙에 여러 개 깔아 쓰는 게 유행이던 때 회사에서도 해 봤는데 아무도 안 썼대요. 각자 워크플로에 착 붙지 않으니 필요가 없었던 거죠. 그래서 최근 전부 지우고 헤르메스(Hermes) 하나만 남겼고, 이걸 공통 워크플로에 어떻게 붙일지가 지금의 과제라고 했어요.

똑빌더의 출발점은 플러그 팀이었어요. 플러그 팀은 마케팅 데이터 분석, 분기별 계획 수립 같은 내부 시스템을 AX로 많이 바꿨어요. 한 달에 두 번 돌던 스프린트(sprint, 짧은 개발 주기)를 개선해 한 달에 열 개 정도가 동시에 돌아가게 했고, 비개발자도 스프린트에 들어와 페이지를 고칩니다. 비개발자가 참여하려면 태스크를 관리할 웹 대시보드가 꼭 필요했죠. 원래는 서장원 대표와 리더 한 명이 관리용으로 만들던 도구였는데, 이걸 보고 팀원 전체가 쓸 수 있는 수준으로 다시 만들자고 마음먹었대요.

계약에서 빌드까지, 똑빌더 시연으로 본 실제 흐름

똑빌더는 판매용이 아니에요. 영업이 끝나면 투입 인력을 검토·결정하고, 디자인과 개발을 하고, 고객사에 인수인계한 뒤 그 결과가 회사 자산으로 남아야 하잖아요. 이 전 과정을 AI 친화적으로 일할 수 있게 만든 업무 대시보드가 똑빌더입니다.

첫 단계는 인력 배정이에요. 회사 규모가 커질수록 누가 어떤 프로젝트를 하고 있고 어디가 지연되는지 따져 사람을 뽑는 일이 어려워지거든요. 영업 이력은 플러그 CRM에 남아 있어서, 거래를 '계약 인박스'로 옮기면 슬랙으로 알림이 갑니다. 계약 인박스는 법무 검토와 날인 전, 구두로 계약이 확정된 상태를 뜻해요.

여기서 눈여겨볼 원칙이 있어요. 서장원 대표는 확률적으로 동작하는 부분을 최소화하고 싶어서 이런 연결을 에이전트가 아니라 API와 웹훅(webhook)으로 짜 놨어요. 계약 인박스로 옮기면 프로젝트가 자동으로 생기고 슬랙에 검토 요청이 뜨는데, 이건 그냥 API 연동이에요. LLM은 그다음, 프로젝트 요약과 인력 추천에서 쓰입니다. 시연에서 '백엔드 한 명, 프론트 한 명'을 입력하고 담당자를 조회하자 여유 있는 사람, 투입 가능한 사람, 확인이 필요한 사람, 불가한 사람으로 나뉘었어요. AI 추천을 누르면 각자 해 온 프로젝트 데이터를 바탕으로 적재적소의 인력을 골라 줍니다.

두 번째는 슬랙 채널 생성이에요. 내부 채널과 외부 채널 두 개를 만들고 투입된 실무자를 바로 초대해요. 재무 담당자와 프로젝트 총괄 리드까지 초대하고 클라이언트에게 프로젝트 시작을 알리는 일은 원래 PM 몫이었는데 이걸 디지털화한 거죠.

굳이 채널을 여기서 만드는 이유도 있어요. 클라이언트와 팀원이 매일 나눈 대화를 원본 데이터로 모아 DB에 쌓기 때문이에요. 에이전트는 똑빌더 안에 있지 않아요. 데이터는 API와 훅으로 모으고, 중간에 헤르메스를 하나 띄워 DB 접근 권한을 줬습니다. 에이전트가 DB를 조회할 때 쓰는 조건값은 스킬로 만들어 뒀고요. 이 데이터로 LLM이 이슈를 감지하고, 준비 중인 기능으로는 커뮤니케이션 내역을 보고 고객 만족도가 떨어졌는지·왜 떨어졌는지 짚어 팀원에게 알려 주는 것도 있어요.

조쉬가 담당자들은 이미 다 알 텐데 왜 필요하냐고 묻자 서장원 대표는 실무자도 놓치는 경우가 많다고 답했어요. 개발자는 기능만 만들면 된다고 생각하기 쉽지만, 고객 입장에선 그 지점에서 만족도가 떨어질 수 있거든요. 기능을 멋지게 만드는 건 기본이고 더 중요한 건 커뮤니케이션이라는 게 오랜 에이전시 경험에서 나온 결론이에요. 그래서 지금 화가 나 있는 클라이언트가 있는지, 그 감정 상태까지 추적해 점수를 매깁니다.

세 번째는 기획이에요. 플러그 영업 과정에서 오간 이메일, 마크다운 파일, 기획서, RFP(제안요청서)를 전부 가져와 초기 기획을 만듭니다. 이때 뒤에 붙어 있는 모델은 GPT예요. PRD(제품 요구사항 문서)를 쓸 때도 AI가 다 하진 않아요. 서장원 대표는 휴먼 인 더 루프(사람이 중간에 확인하는 구조)를 중요하게 봐서, 미결 사항을 AI가 질문으로 뽑아 사람에게 물어보게 했어요. 권한별·페이지별 구성(로그인이 필요한 페이지, 비회원도 볼 수 있는 페이지 등)을 정하면 상세 기획서와 IA(정보 구조), 화면별 데이터까지 나옵니다.

이 기획 품질은 그냥 나온 게 아니에요. 이미 AI 네이티브로 진행한 프로젝트들의 실제 산출물을 기준 삼아 원하는 수준이 나올 때까지 스킬을 다듬었대요. 그리고 PRD를 바로 확정하지 않고 '비평' 단계를 한 번 더 거쳐요. LLM이 PRD를 다시 분석해 네다섯 가지 항목에서 다음 단계로 넘어가도 되는지 점검한 뒤에야 확정합니다. 디자인은 디자인 시스템을 바탕으로 디자인 MD 파일을 만드는 방식이고, AI를 어떤 목적으로 쓰고 토큰과 비용이 얼마나 들었는지도 대시보드로 볼 수 있어요.

마지막은 빌드예요. 빌드를 생성하면 Supabase, Git, Vercel 연동이 자동으로 진행돼요. 중요한 건 어디까지 AI가 하고 어디를 사람이 해야 하는지 AI가 태스크로 나눠 준다는 점이에요. Vercel 토큰 발급이나 Supabase 쪽 발급 작업 같은 건 '휴먼 태스크'로 분류되고, 페이지와 API 만드는 일은 AI가 코드로 실행합니다. 실행은 클로드 코드에서 받아 진행해요.

현재 테스트 기준은 30페이지 정도 규모의 프로젝트를 빌드까지 한 번에 만드는 거예요. 돌려 놓고 집에 다녀오면 다 돌아가 있을 정도지만, 한 번 돌린다고 완성도 있는 결과가 나오진 않는다고 못 박았어요. 그래서 로컬에서 띄워 본 뒤 고칠 점을 태스크로 만들거나 클로드 코드에서 자연어로 요청하면, 미리 만들어 둔 스킬이 그걸 대시보드 태스크로 올려 줍니다. 웹에서 복사한 명령을 터미널에 붙여 넣으면 로컬에 프로젝트 폴더가 생기고, 클로드에게 프로젝트를 시작해 달라고 하면 기획·디자인 자료가 실린 상태에서 할 일 목록이 쫙 생성되는 구조예요.

똑빌더의 다음 단계와 AX를 시작하려는 조직에 주는 조언

지금은 담당자 한 명이 프로젝트 하나를 맡는 방식이라 큰 프로젝트는 아직 못 해요. 대형 프로젝트도 똑빌더 안에서 하는 게 궁극적인 목표이긴 하지만, 당분간은 규모를 한정해서 예비 창업자의 첫 제품을 만들어 주는 수준으로 갈 거래요. 그 규모의 프로젝트가 많으니 프리랜서들이 들어와 똑빌더로 일하고, 회사는 관리 쪽에 이 도구를 쓰는 구조를 그리고 있어요.

다음 기능은 모든 프로젝트에 들어간 똑빌더 봇으로 PM 역할을 일차적으로 자동화하는 거예요. PM 일에는 소통 말고도 프로젝트 관리와 태스크 관리가 있으니, 빌더들이 만드는 일에만 집중할 환경을 주려는 거죠. 디자이너 출신 빌더라면 기술 쪽 공백을 메워 주는 것도 목표예요. 외부 공개는 붙여야 할 기능이 많아 어렵다고 했어요. 다만 똑빌더의 기본 뼈대를 바탕으로 다른 외주 프로젝트를 많이 하고 있고, 마케팅 에이전시와도 협업 중이에요.

AX를 시작하려는 회사에 주는 조언은 세 가지였어요. 첫째는 팀원들이 AI를 어느 수준으로 쓰는지부터 파악하는 것이에요. 아직 GPT에 채팅하는 수준인데 갑자기 클로드 코드를 도입하면 힘들거든요. 그다음엔 전사에 클로드 코드든 제미나이(Gemini)든 일단 도입해 보는 게 우선이래요. 둘째는 AI를 잘 쓰는 개인을 빨리 찾는 거예요. 컨설팅 중에 만난 사람 가운데는 조직에서 AI를 가장 잘 쓴다는 이유로 본업과 상관없이 팀원 교육을 맡게 됐고, 노하우를 계속 넘기다 보니 자기 전문성이 사라지는 것 같아 고민하는 경우도 있었대요.

셋째가 가장 중요해요. 디지털 전환(DX)이 안 된 상태에서 AX부터 하려는 경우가 정말 많다는 거예요. 여기서 DX는 데이터 수집을 말해요. 영업을 최적화하고 싶다면 누군가 영업 데이터를 통합해 엑셀로라도 관리하고 있어야 하는데, 각자의 개인기로 굴러가고 있다면 일하는 방식부터 바꿔야 하죠.

"기술의 도입보다는 환경의 변화인 거 같아요."

컨설팅을 받는다고 해결되는 게 아니라 조직 전체의 리듬을 바꿔야 한다는 뜻이에요.

똑똑한 개발자는 미팅을 무조건 녹음 도구로 기록하고 API로 연결해 프로젝트별로 모아요. 실무자 개개인이 어떤 프로젝트를 했고 연차와 학력이 어떤지도 자산으로 기록하고요. 원래 노션을 쓰다가 똑빌더를 만들면서 프로젝트 관리를 내재화하는 중이에요.

데이터 관리 원칙도 인상적이에요. 프로젝트 데이터는 끝나면 대부분 불필요해지지만 추가 계약이 들어오면 과거 맥락이 필요하잖아요. 그래서 프로젝트당 테이블 하나를 두고 필요할 때 불러오는 방식을 쓰고, RAG나 벡터 DB는 쓰지 않고 거의 MD 파일로 관리한대요. 데이터가 많다고 좋은 게 아니고, 핵심만 보고 의사결정은 사람이 해야 한다는 게 서장원 대표의 생각이에요. 의사결정까지 AI가 한 번에 해 주게 만드는 건 불가능하다는 걸 전제로, 중요한 지표 위주로 사람이 꾸준히 검수하며 데이터를 쌓는 구조가 맞다고 봅니다.

핵심 인사이트

• 에이전시의 AI 전환은 '자기 업을 없애는 연습'이에요: 서장원 대표는 대행업이 장기적으로 사라질 거라 보고, 남는 자산을 '한 산업을 AI로 없애 본 경험'에서 찾아요. 외주에 기대는 1인 사업자도 내 일이 언제까지 대행으로 남을지 먼저 물어볼 만해요.
• 확정적인 연결은 API로, 판단만 LLM에게 맡겨요: 계약 이동 알림, 프로젝트 생성, 채널 초대는 웹훅·API로 짜고 LLM은 요약·추천·이슈 감지에만 씁니다. 결과가 매번 같아야 하는 단계에 에이전트를 넣지 않는 게 자동화를 망가뜨리지 않는 방법이에요.
• 내부 도구도 '지금 쓰는 것보다 편해야' 쓰여요: 스킬 공유 사이트도, 슬랙 에이전트 여러 개도 결국 안 쓰였어요. 리더가 필요해서 만든 도구는 현업의 워크플로에 붙지 않으면 버려집니다.
• AX 앞에 DX가 있어요: 데이터가 한곳에 모이지 않으면 AI가 할 일이 없어요. 데이터는 많을수록 좋은 게 아니고 핵심 지표를 사람이 검수하며 쌓아야 한다는 점도 함께 기억할 만해요.

오늘 당장 해볼 것

1. 반복 업무 하나를 골라 '확정 단계'와 '판단 단계'로 나눠 보세요. 예를 들어 계약이 확정되면 폴더 만들기·고객 안내 메일 초안·일정 등록이 이어진다면, 앞의 정해진 동작은 노코드 자동화의 웹훅으로 연결하고 메일 문구 같은 판단만 AI에게 맡기는 식이에요. 어디에 AI를 써야 할지 선이 또렷해집니다.
2. 고객 미팅을 녹음해 고객별 MD 파일 하나에 모아 보세요. 녹음 도구의 요약본을 고객 이름으로 된 파일에 날짜순으로 붙여 두기만 해도, 몇 달 뒤 재계약 때 과거 맥락을 바로 꺼낼 수 있어요. 벡터 DB 없이도 충분하다는 게 이 영상의 사례예요.
3. AI가 만든 기획서나 제안서를 바로 쓰지 말고 '비평' 단계를 한 번 넣어 보세요. "이 문서를 다음 단계로 넘겨도 되는지 다섯 가지 기준으로 점검하고 빠진 질문을 뽑아 줘"라고 다시 요청하면 됩니다. 사람이 확인해야 할 미결 사항이 눈에 보이기 시작해요.