코딩 에이전트가 만드는 새로운 EPD(엔지니어링·프로덕트·디자인) 질서
TMTEPD (Engineering, Product, and Design)는 소프트웨어 회사에서 좋은 소프트웨어를 만드는 조직입니다. 역할은 나뉘어 있지만, 궁극적인 목표는 비즈니스 문제를 해결하고 사용자가 실제로 사용할 수 있는 기능적인 소프트웨어를 만드는 것입니다. 그리고 결국 이 모든 것은 코드일 뿐입니다. EPD 조직이 만드는 결과물이 결국 코드라는 점이 중요한 이유는… 코딩 에이전트 덕분에 이제 코드를 쓰는 일이 갑자기 아주 쉬워졌기 때문입니다. 그렇다면 이 변화는 EPD의 역할을 어떻게 바꿀까요?
변화하는 프로세스:
- PRD는 죽었다
- 병목은 구현에서 리뷰로 옮겨간다
- PRD 만세
역할에 미치는 영향:
- 제너럴리스트의 가치가 그 어느 때보다 높아진다
- 코딩 에이전트는 필수 요건이다
- 좋은 PM은 더 빛나고, 나쁜 PM은 더 치명적이다
- 모두가 프로덕트 센스를 가져야 한다
- 스페셜리스트가 되기 위한 기준이 더 높아진다
- 당신은 빌더이거나 리뷰어다
- 모두가 “코딩 에이전트로 가장 크게 이득 보는 건 내 역할”이라고 생각하고, 실제로 그 말이 맞다
PRDs are dead
PRD(Product Requirement Document, 제품 요구사항 문서)는 클로드(Claude) 이전 시대에 소프트웨어를 만들 때 중심이 되는 도구였습니다. 당시 EPD 프로세스는 대략 이런 식이었습니다:
- 누군가(보통 프로덕트)가 아이디어를 낸다
- 프로덕트가 PRD를 작성한다
- 디자인이 PRD를 받아 와이어프레임/목업을 만든다
- 엔지니어링이 그 목업을 코드로 구현한다
이게 항상 딱 맞춰 지켜지는 규칙은 아니었습니다(스타트업에서는 이 단계들이 서로 섞여 있었고, 최고의 빌더들은 이 중 여러 단계를 스스로 다 해냈습니다). 하지만 “교과서적인” 빌딩 방식은 대체로 이랬습니다.
이렇게 했던 이유는, 소프트웨어를 구현하는 것(그리고 목업을 만드는 것) 자체가 상당한 시간과 노력이 드는 일이었기 때문입니다. 그래서 그 작업에 특화된 역할들이 생겨났습니다. 사람들이 점점 더 전문화되자, 그 역할들 사이를 이어 주는 커뮤니케이션 수단이 필요해졌습니다. PRD가 바로 그 출발점이었고, 모든 것을 시작하게 하는 기반이었습니다. 그런 다음 이 PRD가 디자인으로 “폭포수처럼” 흘러가고, 디자이너는 그 예쁜 글들을 예쁜 UI와 매끄러운 UX로 바꾸었습니다. 엔지니어링은 그것을 실제로 동작하게 만들었습니다.
코딩 에이전트가 이 모든 것을 바꿉니다. 코딩 에이전트는 한 아이디어를 받아 기능하는 소프트웨어를 만들어낼 수 있습니다. 제가(그리고 다른 사람들도) “PRD는 죽었다”고 말할 때 실제로 의미하는 바는, PRD 작성에서 출발하던 이 전통적인 소프트웨어 빌딩 방식이 이제 끝났다는 뜻입니다.
구현이 아니라 ‘리뷰’가 병목이 되는 시대로의 전환
이제 누구나 코드를 쓸 수 있고, 그 말은 누구나 무엇인가를 만들 수 있다는 뜻입니다. 그렇다고 해서 만들어지는 것들이 모두 잘 설계되어 있다거나, 올바른 문제를 해결한다거나, 쓰기 쉬운 것은 아닙니다. 엔지니어링, 프로덕트, 디자인은 각각 이런 부분들을 검토하고 최종 판단을 내려야 하는 역할입니다. 문제는, 생성되는 코드가 항상 “훌륭한(great)” 수준은 아니라는 점입니다. EPD의 역할은 이 코드를 리뷰하면서 “훌륭하다” 싶은 상태가 되도록 만드는 것으로 바뀝니다. 여기서 “훌륭하다”는 여러 의미를 담고 있습니다:
- 엔지니어링 시스템 관점에서 잘 설계되어 있는가: 확장 가능하고, 성능이 좋고, 견고하게 작성되어 있는가?
- 프로덕트 관점에서 잘 고민되었는가: 실제로 사용자 페인 포인트를 해결하는가?
- 디자인 측면에서 잘 설계되었는가: 인터페이스가 직관적이고 사용하기 쉬운가?
초기 버전 코드를 만드는 비용이 아주 낮아졌기 때문에, 우리는 훨씬 더 많은 프로토타입이 만들어지는 것을 보게 됩니다. 그런 프로토타입들이 새로운 초점이 되고, 프로덕트·엔지니어링·디자인이 그것들을 함께 리뷰하는 구조가 됩니다.
문제는, 코드를 생성하는 일이 너무 쉬워졌다는 것입니다. 예전에는 코드를 만드는 데 시간이 꽤 걸렸기 때문에, 리뷰어 입장에서는 한 번에 검토해야 할 프로젝트 수가 제한적이었습니다. 하지만 이제는 누구나 코드를 쓸 수 있습니다. 그 말은 진행 중인 프로젝트 수가 늘어난다는 뜻입니다. 실제로 우리는 세 역할 모두에서 병목이 리뷰 쪽으로 옮겨가는 것을 보고 있습니다. 프로토타입을 가져와 “좋은 상태”로 만드는 과정이 병목이 됩니다.
PRD의 방식은 바뀌지만, ‘좋은 PRD’의 필요성은 여전히 유효하다
클로드 이전 시대의 소프트웨어 빌딩 방식(즉, PRD에서 시작하는 프로세스)은 끝났습니다. 하지만 제품 요구사항을 설명하는 문서 자체는 여전히 필수적입니다.
누군가 아이디어를 떠올리고, 매우 빠르게 프로토타입을 만들었다고 가정해 봅시다. 이게 실제 프로덕션에 들어가려면 어떻게 해야 할까요? EPD의 다른 구성원들이 이걸 리뷰해야 합니다. 이 과정에서, 텍스트로 정리된 문서는 항상 도움이 되며, 많은 경우 필수적입니다. 다른 사람들이 코드를 리뷰할 때, 어떤 코드가 “실수로 들어간 것인지”, 아니면 “의도적으로 그런 것인지”를 어떻게 알 수 있을까요? 이는 의도(intent)에 달려 있습니다. 그 의도를 전달하는 무엇인가가 반드시 필요합니다.
저는 기존의 PRD 프로세스(PRD → 목업 → 코드)는 죽었다고 봅니다. 하지만 제품 요구사항을 설명하는 텍스트는 여전히 매우 중요합니다. 이 문서는 프로토타입을 리뷰에 전달하기 전에 반드시 붙어 있어야 하는 “동반 문서”가 되어야 합니다.
가장 표준적인 형태는 일반적인 문서(document)일 것입니다. 하지만, 이 기능을 만들 때 사용한 프롬프트들을 공유하는 방식으로 의도를 전달하는 것도 흥미로운 아이디어입니다. 만약 미래의 PRD가, 구조화되고 버전 관리되는 프롬프트들 그 자체라면 어떨까요?
이제는 ‘멀티 롤’ 플레이어가 그 어느 때보다 값지다
여기서 말하는 제너럴리스트란, 프로덕트·엔지니어링·디자인 세 영역 모두에 대한 감각을 갖춘 사람을 의미합니다. 이런 사람들은 예전부터도 언제나 가치 있고 영향력이 컸지만, 코딩 에이전트가 등장한 이후로는 그 가치가 훨씬 더 커졌습니다. 왜 그럴까요?
가장 어려운 것은 커뮤니케이션이고, 그것이 속도를 늦추는 주범이기 때문입니다. 프로덕트·디자인·엔지니어링을 모두 할 수 있는 한 사람이, 각 역할을 나눠 맡은 세 명의 팀보다 더 빠르게 움직일 수 있습니다. 그 이유는 커뮤니케이션 오버헤드가 없기 때문입니다.
예전에는 구현(implementation)이 병목이었기 때문에, 제너럴리스트라 해도 일을 끝내려면 결국 다른 사람들과 커뮤니케이션을 해야 했습니다. 이제는 에이전트와만 소통하면 됩니다. 덕분에 이들은 혼자서도 예전보다 훨씬 큰 임팩트를 낼 수 있게 되었습니다.
코딩 에이전트는 이제 선택이 아니라 ‘필수 스킬’이다
코딩 에이전트 덕분에 구현 비용이 싸졌기 때문에, 이제 코딩 에이전트를 사용하는 것은 선택이 아니라 필수입니다. 코딩 에이전트를 잘 받아들일 수 있는 사람은 혼자서 더 많은 일을 해낼 수 있습니다:
- 코딩 에이전트를 도입한 PM은, 스펙을 먼저 쓰고 기다릴 필요 없이 직접 프로토타입을 만들어 아이디어를 검증할 수 있습니다.
- 코딩 에이전트를 도입한 디자이너는, 더 이상 Figma 안에서만이 아니라 실제 코드 위에서 반복적으로 시도해 볼 수 있습니다.
- 코딩 에이전트를 도입한 엔지니어는, 구현 자체보다는 시스템 차원의 사고에 더 많은 시간을 쓸 수 있습니다.
코딩 에이전트를 쓰는 것은 필수입니다. 사용하는 것이 어렵지 않은데도 사용하지 않으면, 결국 코딩 에이전트를 잘 쓰는 사람에게 자리를 내주게 될 것입니다.
좋은 PM은 엄청난 자산이지만, 나쁜 PM은 조직에 큰 해악이 된다
좋은 프로덕트 사고(product thinking)는 그 어느 때보다 더 가치가 있습니다. 그렇게 해야 쓸모 있는 것을 만들 수 있기 때문입니다. 반대로 나쁜 프로덕트 사고는 그 어느 때보다 더 큰 낭비를 만듭니다. 누군가 나쁜 제품 아이디어를 가지고 있다면, 이제는 그 사람이 실제 프로토타입까지 들고 나타날 수 있습니다. 그런데 그 프로토타입이 쓸모 없거나, 애초에 잘못 설계된 기능일 수도 있습니다. 이런 프로토타입은 이제 엔지니어링, 프로덕트, 디자인이 더 많은 리뷰를 해야 합니다. 이 과정이 시간과 리소스를 빨아들입니다. 게다가 “이미 존재하는 기능이니까 그냥 머지하자!”라는 관성이 생길 수 있어, 이런 프로토타입이 실제 프로덕션에 들어가 버리는 일도 생깁니다. 그 결과 제품이 더 나빠지거나 불필요하게 비대해질 위험이 커집니다.
지금 가장 갈고닦아야 할 건 ‘시스템적으로 생각하는 힘’이다
실행(implementation) 비용이 싼 세상에서는 시스템 사고(system thinking)가 차별점입니다. 여러분은 시스템 사고 능력을 정말 탁월한 수준까지 끌어올리고, 자신이 다루는 특정 도메인에 대해 명확한 멘탈 모델을 가져야 합니다:
- 엔지니어링: 서비스, API, 데이터베이스를 어떻게 설계해야 하는지에 대한 뛰어난 멘탈 모델
- 프로덕트: 사용자가 실제로 무엇을 필요로 하는지(말로 요구하는 것과는 별개로)를 꿰뚫는 멘탈 모델
- 디자인: 왜 어떤 것이 보기 좋고, 사용감이 좋은지에 대한 명확한 멘탈 모델
시스템 사고는 항상 중요했습니다. 그렇다면 무엇이 달라졌을까요? 바로 구현 비용이 크게 내려갔다는 점입니다. 이제 무언가를 실제로 구현하는 일은 그 어느 때보다도 쉬워졌습니다. 하지만 그렇다고 해서 그것이 “훌륭한” 결과라는 뜻은 아닙니다. 좋은 시스템 사고를 갖추고 있으면, 처음부터 올바른 것을 만들고 있는지 확인할 수 있습니다. 또한 나중에 다른 사람들이 만든 것을 리뷰할 때도 큰 도움을 줍니다. 이 두 가지 모두 때문에, 시스템 사고의 중요성이 예전보다 훨씬 더 커졌습니다.
이제 모두에게 ‘프로덕트 감각’이 필수 소양이 되었다
코딩 에이전트 역시 누군가가 프롬프트를 줘야 움직입니다. 무엇을 하라고 지시할 사람이 필요합니다. 만약 에이전트에게 잘못된 것을 만들라고 시키면, 결국 다른 사람들이 리뷰해야 할 “쓰레기”만 더 쌓이게 됩니다. 에이전트에게 “무엇을 만들라고 말해야 하는지”를 아는 능력, 즉 “프로덕트 센스”는 필수입니다. 이게 없으면 조직 전체에 부담을 주는 존재가 됩니다. 이는 엔지니어링과 디자인, 그리고 말할 것도 없이 프로덕트 모두에게 해당됩니다.
EPD의 큰 부분은 이제 프로토타입을 리뷰하는 일입니다. 리뷰는 프로덕트 센스를 가질수록 훨씬 수월해집니다. 디자인이나 엔지니어링을 리뷰할 때도 마찬가지입니다. 프로덕트 센스가 없다면, 프로토타입 옆에 아주 세세하게 적힌 제품 문서가 꼭 필요합니다. 반면 프로덕트 센스가 있다면, 짧고 간단한 스펙만으로도 기능의 의도를 바로 이해하고, 커뮤니케이션·리뷰·딜리버리 속도를 모두 끌어올릴 수 있습니다.
이제 ‘전문가’로 인정받기 위한 기준 자체가 훨씬 높아졌다
이제는 코딩 에이전트를 다룰 줄 알아야 합니다. 프로덕트 센스도 필요합니다. 모든 역할이 서로 뒤섞이고 있습니다.
역할 간의 경계가 겹치는 일은 예전부터 있었습니다. 디자인과 프로덕트는 오랫동안 엮여 왔고, Apple이나 AirBnb 같은 회사에서는 디자이너가 사실상 프로덕트 매니저 역할까지 맡기도 합니다. Vercel 같은 회사에서는 “디자인 엔지니어”라는 역할이 점점 주목받고 있습니다.
그렇다고 스페셜라이제이션(전문화)의 자리가 사라지는 것은 아닙니다. 시스템 아키텍처만 깊이 고민하는 아주 시니어한 엔지니어는 여전히 가치 있습니다. 코드를 거의 쓰지 않더라도, 고객 문제와 무엇을 만들어야 하는지에 대한 멘탈 모델이 매우 명확한 PM도 마찬가지입니다. 여전히 Figma 안에서만 작업하더라도, 사용자 여정과 인터랙션을 깊이 이해하고 모형화할 수 있는 디자이너 역시 마찬가지입니다.
하지만 스페셜리스트가 되기 위한 기준은 훨씬 높아졌습니다. 자신의 도메인에서 뛰어난 수준을 넘어 “환상적(fantastic)”이어야 할 뿐 아니라, 리뷰를 엄청나게 빠르게 해낼 수 있어야 하고, 커뮤니케이션 능력도 탁월해야 합니다. 그리고 이런 역할은 어떤 회사든 아주 소수만 존재할 것입니다.
이제 당신의 역할은 ‘빌더’ 아니면 ‘리뷰어’ 둘 중 하나다
우리는 EPD 안에서 두 가지 유형의 역할이 등장하는 것을 보고 있습니다.
첫 번째는 빌더(builder)입니다. 이 아키타입은 좋은 프로덕트 사고를 가지고 있고, 코딩 에이전트를 능숙하게 사용할 수 있으며, 기본적인 디자인 직관도 갖추고 있습니다. 테스트 스위트나 컴포넌트 라이브러리 같은 가드레일이 잘 마련되어 있다면, 작은 기능을 아이디어 단계에서 프로덕션까지 직접 끌고 갈 수 있고, 더 큰 기능에 대해서도 실제로 동작하는 프로토타입을 만들 수 있습니다.
두 번째는 리뷰어(reviewer)입니다. 크고 복잡한 기능에는 세밀한 EPD 리뷰가 필요합니다. 여기서 요구되는 기준은 매우 높습니다. 자신이 맡은 도메인에서 탁월한 시스템 사고를 갖춰야 합니다. 또한 리뷰해야 할 것이 많기 때문에, 매우 빠른 속도로 일할 수 있어야 합니다.
만약 지금 엔지니어라면, 시스템 디자인에 엄청나게 능숙해지고 아키텍처 리뷰에 익숙해져 “리뷰어”가 되기를 목표로 삼거나, 아니면 프로덕트·디자인 역량을 키워 “빌더”가 되기를 목표로 삼아야 합니다.
프로덕트나 디자인 쪽에 있다면, 프로덕트·디자인에 대한 멘탈 모델을 압도적으로 잘 갖추어 주로 리뷰 역할을 맡거나, 아니면 코딩 에이전트에 과감히 뛰어들어 코딩 실력을 함께 끌어올려야 합니다.
모두가 “코딩 에이전트 덕을 제일 많이 보는 건 우리 역할”이라 생각하고, 실제로 그 말이 맞다
코딩 에이전트로부터 가장 큰 혜택을 받는 사람의 유형에 대한 트위터의 훌륭한 글이 있었습니다.
지금 존재하는 이 제품을 직관적으로 꿰뚫고 있어서, 어디가 약한지, 어디서 빛나는지, 그리고 그것을 어떻게 더 날카롭게 다듬어 가야 할지를 감으로 아는 사람.
이 중에서도 가장 희귀한 버전은 문화와 깊은 기술의 교차점에 서 있는 사람이다. 말 그대로 둘 사이를 자유롭게 오가는 진짜 바이링구얼처럼, 무엇이 기술적으로 가능한지 알고, 어떤 문화적 흐름이 진짜이고 어떤 것은 금방 사라질 거품인지도 구분할 줄 안다. 이 두 가지가 동시에 갖춰졌을 때, 그 사람이 만드는 제품은 ‘이것저것 붙여 조립한 느낌’이 아니라, 원래부터 그 자리에 있어야 했던 것처럼 필연적으로 느껴지는 제품이 된다.
이 글은 이 새로운 세계를 아주 잘 요약하고 있었고, 반쯤 바이럴이 되었습니다. 사람들이 이 글을 공유한 이유 중 하나는, 읽는 모든 사람이 이 글이 “자기 자신 혹은 자신의 역할을 설명하고 있다”고 느꼈기 때문입니다. 프로덕트 사람들, 디자이너들, 디자인 엔지니어들, 창업자들까지… 모두가 이 글이 자기와 자기 역할에 대해 말하고 있다고 생각했습니다.
그리고 그들 모두가 실제로 맞았을 가능성이 큽니다! 제가 이 새로운 세상이 정말 멋지다고 생각하는 이유 중 하나는, 출신 배경이 덜 중요해졌기 때문입니다. 저는 이런 유형의 사람이 프로덕트, 디자인, 엔지니어링 어느 쪽 출신이든 나올 수 있다고 진심으로 믿습니다. 물론 그렇다고 해서 모두가 이런 사람이 될 수 있다는 뜻은 아닙니다. 말처럼 쉬운 일이 아니고, 진짜 유니콘 같은 사람은 매우 드뭅니다.
지금은 무언가를 만들기에 정말 흥미로운 시대입니다 :)