팀원 모두가 프로덕트를 만드는 조직에서 개발자는 무엇을 해야 하는가
최근 저희 회사에서 비개발자 팀원이 클로드 코드로 1시간도 걸리지 않아 프로덕트를 만들어 냈습니다. 기획, 제작, 배포까지 완전 혼자서. 저한테는 한마디도 묻지 않았습니다.
저는 10년 정도 개발자로 일하였고, 꽤 하드한 개발자였는데, 솔직히 최근에 코드를 한 줄도 직접 작성하지 않았습니다. 전형적인 관리직처럼 명령과 검수만 하고, 그마저도 하는 시간이 점점 줄고 있습니다.
매일매일이 이런 경험의 연속이다보니, 정말 위기인가, 라는 감정을 피할 수가 없습니다. 솔직히 이 감정에 한동안 머물렀습니다. 개발자 커리어 10년간 쌓아온 것들이 흔들리는 느낌이었습니다.
AI로 높아진 생산성. 그리고 새로운 문제.
이 상황이 하루아침에 온 건 아닙니다. 저희 팀은 함께 시작하자마자, AI Native 기업을 만들기 위해 시간을 많이 썼습니다. AI 제품을 적극 도입하고, 워크플로우에 AI를 녹이는 행위를 정말 많이 해왔습니다.
AI 제품을 적극적으로 쓰기 시작하면서 개인의 생산 속도가 정말 빨라졌고, 결과가 빠르게 나오기 시작했습니다. 예전엔 일주일이 걸리던 일이 하루면 끝났습니다. 하루가 다르게 결과물이 쏟아져 나왔습니다.
그러다보니 새로운 문제가 생겼습니다. 다음 일을 하기 위해선 함께 협업하는 다른 사람의 작업을 기다리는 상황이 계속 발생했습니다. 앞에서 일어난 일의 맥락을 모두 공유하고, 같이 의사결정하고, 작업을 기다리고. 이 과정에서 시간도 시간이지만, 공유하는 과정에서 컨텍스트가 계속 유실됐습니다. 빈번한 핸드오프마다 맥락이 깎여나갔고, 의사결정은 불완전한 정보 위에서 이루어졌습니다.
더 큰 문제는, 이미 내려진 의사결정이 제때 공유되지 않아서 다른 팀원이 지난 의사결정을 기반으로 행동하는 일까지 생겼다는 겁니다. 속도가 빨라진 만큼 이런 엇갈림도 빠르게 쌓였습니다.
결국 AI로 실행 속도는 빨라졌는데, 두 가지가 병목이 된 겁니다. 사람의 의사결정을 기다리는 것, 그리고 내려진 의사결정과 맥락이 제때 퍼지지 않는 것. 실행은 AI가 빠르게 해주는데, 사람이 판단하고 결정해야 하는 지점에서 줄이 길어졌고, 그 사이에 조직의 컨텍스트는 계속 어긋나고 있었습니다.
저희만 겪는 일이 아니었습니다. Sequoia Capital의 Alfred Lin은 최근 인터뷰에서 자신이 참석한 보드미팅 이야기를 했습니다. 상위 5~10% 엔지니어들이 작년 대비 3배 많이 shipping하고 있다고. 그런데 그만큼 빠르게 만들어내니까, 이제는 조율과 커뮤니케이션이 새로운 병목이 되고 있다고. 더 빠르게 움직일 수 있다고 생각하지만, 나머지 조직을 따라오게 하고 얼라인시키는 것이 아직 남은 숙제라고 했습니다.
"모든 문제에는 해결책이 있고, 모든 해결책은 새로운 문제를 만든다."
그의 말 그대로의 상황이었습니다.
병목을 뚫은 방법
이 두가지 문제를 해결할 방법이 필요했습니다. 핵심은 간단했습니다. 의사결정자와 실행자가 같은 사람이면, 기다릴 필요가 없습니다. 누군가에게 설명하고, 확인받고, 기다리는 과정 자체를 없애는 겁니다.
그래서 각자가 처음부터 끝까지 직접 해결하는 e2e 구조로 전환했습니다. 문제를 가장 잘 아는 사람이, 해결책까지 직접 만드는 구조. 이걸 가능하게 만든 건 AI였습니다. AI를 기반으로 모두가 전문 지식을 갖추고 훨씬 넓은 범위의 일을 할 수 있게 됩니다. 프로덕트를 직접 만들 수도 있고, 직접 세일즈와 마케팅을 할 수도 있게 됩니다.
기획자에게 설명하고, 개발자에게 전달하고, 일정을 조율하는 단계가 통째로 사라졌습니다. 맥락을 가진 사람이 직접 만들면, 그 과정이 필요 없어집니다.
그런데 각자가 e2e로 일하려면 전제가 하나 있었습니다. 모두가 같은 맥락 위에서 일해야 한다는 것. 맥락이 흩어진 상태에서 각자 달리면, 속도만 빨라지고 방향은 제각각이 됩니다.
그래서 전 인원이 클로드 코드와 GitHub 위에서 일하는 구조를 만들었습니다. 모두가 문서 기반으로 커뮤니케이션하고, 최신화된 문서 위에서 AI와 협업합니다. 회사의 전략, 의사결정 로그, 업무 규칙이 하나의 저장소에 모여 있고, 사람도 AI도 그 위에서 일합니다.
모두가 프로덕트를 만드는 환경
이런 환경 위에서의 변화는 빠르게 왔습니다.
저희는 AI Native Camp라는 프로그램을 운영하였는데요. 참여자들이 클로드 코드를 배우고, 실제로 프로덕트를 만들어보는 캠프입니다. 이 캠프를 운영하는 팀원이 있었고, 매우 똑똑하신 분이긴 하나, 개발을 배우다 포기하신 경험이 있는 분이셨습니다.
이분이 캠프를 진행하면서 참여자들의 토큰 소비량을 서로 확인할 수 있는 페이지가 있으면 좋겠다는 이야기를 하셨습니다. 누가 얼마나 적극적으로 참여하고 있는지 알면 캠프 운영에 반영할 수도 있고, 참여자들 끼리 선의의 경쟁을 할 수 있으니까요. 예전이라면 저한테 토큰량 트래킹 할 수 있는 리더보드를 만들어 달라고 요청했을 겁니다.
그런데 이 분은 저에게 개발 요청하지 않았습니다. 직접 클로드 코드를 열고, 기획부터 제작, 배포까지 혼자서 하셨습니다. 1시간도 걸리지 않았습니다. 캠프를 직접 운영하고 있었기 때문에, 어떤 데이터를 어떻게 보여줘야 하는지 누구보다 잘 알고 있었고, 그 의도가 프로덕트에 그대로 담겼습니다. 내놓자마자 캠프 참여자들과 팀원들이 매일 들어가서 확인하기 시작했습니다.
이런 일이 한 번만 일어난 게 아닙니다. 다른 팀원들도 각자 영역에서 필요한 것들을 직접 만들기 시작했습니다. 기획서를 쓰고 전달하는 대신, 머릿속에 있는 기획을 바로 프로덕트로 만들어버리는 겁니다. 그리고 다른 팀원은 자주 쓰는 워크플로우를 자동화 하였으며, 한눈에 성과를 볼 수 있는 대시보드를 직접 만들기 시작했습니다.
마주한 새로운 상황
좋은 일이었습니다. 그런데 서비스 운영 도중에 문제가 발생하였습니다. 클로드 코드의 조언대로 만든 서버 스펙이 고려되지 않아, 중간에 서비스가 터진 것 입니다. 높은 빈도로 데이터 수집을 하였고, 이로 인한 문제였는데, 이런 상황에 대해서는 경험해보지 못한 사람이라면 예상하기 힘들었을 것이며, 기본 클로드 코드와 함께 만들었을 때에는 고려하기 쉽지 않은 요소였습니다.
이뿐만이 아니었습니다. 하루에도 몇개씩 워크플로우와 에이전트, 프로덕트가 나오면서, 같은 역할을 하는 프로덕트가 여러 개 생겼고, 파편화된 데이터베이스 정보는 회사 차원에서 모이지 않았으며, 사용하지 않는 프로덕트는 방치되었습니다. 각자 만들었기에 모두 흩어져 있었고, 누가 뭘 만들었는지 전체 그림을 아는 사람이 없었습니다. 모두가 만들 수 있는 환경은 해방이지만, 관리 없는 해방은 곧 혼란이었습니다.
개발자인 내가 할 일이 바뀌었다
이 혼란을 겪으면서 개발자인 저의 역할이 뭔지 명확해졌습니다. 개인사업을 할 것이 아니라면, 기업 구성원들이 일으키는 일들은 얼라인이 되어야 합니다. 기업이 이들을 충돌 없이 이끌기 위해서는, 컨텍스트를 얼라인하고 싱크시킬 수 있는 AI Native한 구조가 필요합니다. 각자가 무엇을 만들고 있는지, 회사가 어디로 가고 있는지, 어떤 우선순위로 움직여야 하는지. 이 맥락이 모두에게 실시간으로 공유되어야 합니다.
이 환경은 사람만을 위한 것이 아닙니다. 함께 일하는 AI Agent들도 싱크된 컨텍스트 위에서 일할 수 있게 되어야 합니다. 저희 팀에서 전 직원이 클로드 코드 위에서 일할 수 있는 이유도 이겁니다. 회사의 전략, 의사결정 로그, 업무 규칙, 프로덕트 현황이 하나의 저장소에 문서로 모여 있고, 사람도 AI도 그 위에서 일합니다. 사람이든 AI든, 같은 맥락 위에서 일하지 않으면, 속도가 빨라질수록 방향은 더 빠르게 흩어집니다.
모두가 프로덕트를 자유롭게 만들더라도, 조직과 얼라인 된 방향으로 만들 수 있어야 합니다. 그리고 안전한 구조 위에서 만들 수 있도록 프로덕트 개발의 판을 만들어야 합니다. 제공한 프로덕트 개발의 판을 통해서 만들면, 배포환경이 자동으로 세팅되고, 데이터베이스가 연결되고, 모니터링이 붙고. 개발에 대한 지식이 없어도 실험을 충분히 해볼 수 있는 프로덕트가 나오는 방향을 구성해야합니다.
만들어진 프로덕트에서 나오는 데이터는 중앙으로 모여야 하며, 비개발자는 비즈니스 로직에만 집중하면 되고, 나머지는 구조적으로 알아서 처리됩니다. 역할을 다한 프로덕트는 정리할 수 있는 경로가 있어야 합니다.
개발자인 저는 이 구조를 구상하고 구축하고 발전시키고 있습니다. 중앙에 모이는 결과물과 데이터를 처리하고, 관리하고, 다음 회사의 발전 방향에 기여할 수 있도록 만드는 것. 저희와 유사한 기업구조를 가지셨거나, 지향하신다면, 제가 한 경험이 앞으로 그 팀의 개발자들이 마주하게될 일이라고 생각합니다.
이건 사실 개발자들이 원래 잘하던 일입니다. 시스템을 설계하고, 인프라를 구축하고, 전체 아키텍처를 관리하는 것. 코드를 짜는 것에서, 조직이 만드는 모든 것의 판을 짜 것으로. 대상이 확장되었을 뿐입니다.
새로운 구조가 필요하다
같은 변화가 글로벌에서도 일어나고 있습니다. ARR $3.5억, 기업가치 $66억으로 세계에서 가장 빠르게 성장하는 기업 중 하나인 Lovable의 Head of Growth, Elena Verna는 최근 인터뷰에서 이런 취지의 이야기를 했습니다.
소프트웨어 제작이 민주화된 세상에서, 성장의 핵심 채널은 프로덕트 그 자체가 됐다고. Lovable에서는 전 직원이 코드를 프로덕션에 배포합니다. 전 직원이 자체 앱을 만들고, 전 직원이 자기 마케팅을 합니다. 20년간 코드를 프로덕션에 올려본 적 없던 Growth 리더인 자신도, 지금은 직접 앱을 만들고 캠페인을 돌립니다. Elena는 이것이 AI nativeness의 본질이라고 했습니다.
프로덕트는 여전히 중요합니다. 아니, 더 중요해졌습니다. 하지만 만드는 사람이 달라졌습니다. 그리고 모두가 만들 수 있는 환경에서, 만들어진 것들이 흩어지지 않도록 잡아줄 구조가 필요합니다.
프로덕트를 개발하기 위해서 코드를 짜는 개발자는 줄어들 겁니다. 하지만 무엇을 만들어야 하는지, 어떤 구조 위에서 만들어야 하는지, 만들어진 것들을 어떻게 연결하고 관리해야 하는지. 이 의도를 설계하는 사람은 더 필요해질 겁니다.
저희는 지금 이 단계에 있습니다. 완성된 답을 가지고 있지 않습니다. 환경을 조성하고, 팀원들이 프로덕트를 만들기 시작했으며, 그 과정에서 새로운 구조를 적용해 나아가고 있습니다. 그리고 마주하는 문제들을 하나씩 풀어가고 있습니다.
개발자의 위기가 아니라, 역할의 전환되는 시기라고 생각합니다. 제가 겪은 사례 역시 여러 상황중 하나이며, 빠르게 AI Native하게 구조 변경을 하고 있으신 회사라면 비슷한 경험을 하고 계실겁니다. 새로운 전환을 맞아 고군분투하고 계신 분들이 있으시다면, 어떤 상태에 있는지, 어떤 문제를 마주하고 있는지, 어떻게 풀고 있는지. 이야기를 나눠보고 싶습니다.
아래 메일로 편하게 연락 부탁드립니다.
woong@deltasociety.xyz
그리고 번외로 저희 팀원이 직접 개발한 프로덕트 역시 공유해보자 합니다. 모두가 AI를 도구로 활용하는 방법을 알려드리기보단, 일하는 방식을 바뀔 수 있도록 가이드 해드리는 AI Native Camp 라는 프로그램을 운영했습니다.
그리고 그 과정을 완전 무료로 오픈하였습니다. 모두가 참여하고 배우실 수 있도록 사이트를 만들었습니다. 이 과정을 수료하시면 claude code를 조직 OS로 사용할 수 있는 첫 발걸음을 만드시는데 도움이 되실겁니다.
