핵심 이슈: 구현이 싸지면, 병목은 어디로 이동하는가
얼마 전까지만 해도 '팀이 크다'는 건 곧 '실행력이 있다'는 의미였다. PM이 스펙을 쓰고, 디자이너가 Figma를 넘기고, 개발자가 코드로 옮기는 이 흐름은 구현 비용이 비쌀 때 합리적인 분업이었다. 하지만 AI 코딩 에이전트가 구현의 상당 부분을 흡수하기 시작하면서, 그 분업의 전제가 흔들리고 있다.
dev.to에 게재된 「The Three-Person Team」은 이 변화를 날카롭게 포착한다. 저자는 AI가 코드 작성의 중간 단계를 맡게 되면 팀은 더 이상 '손'을 추가해서 확장하지 않는다고 말한다. 대신 더 선명한 판단력을 추가함으로써 확장한다. 이제 팀의 효율을 결정하는 것은 헤드카운트가 아니라, 세 가지 현실을 동시에 볼 수 있는 '렌즈의 조합'이다.
맥락 해석: 3인 팀 구조가 말해주는 것
그가 제시하는 이상적인 소형 팀의 구조는 단순하다. 디자인 렌즈(사용자 현실), 엔지니어링 렌즈(시스템 현실), 프로덕트 렌즈(비즈니스 현실). 세 사람이 각각의 현실을 소유하고, 세 관점이 일치할 때만 팀이 출시한다. 중요한 건 이것이 직책 이야기가 아니라는 점이다. 에이전트에게 위임할 수 없는 판단의 종류에 관한 이야기다.
핵심적인 변화는 핸드오프가 사라진다는 것이다. PM이 스프린트 이후 엔지니어가 읽을 문서를 쓰는 게 아니라, 세 사람이 동일한 '살아있는 스펙'을 동시에 편집하고, 에이전트는 그 스펙을 백그라운드에서 프로토타입으로 구현한다. 작업의 단위가 풀 리퀘스트에서 인텐트(intent)로 이동하는 것이다. 스펙이 명확할수록 AI의 아웃풋이 정확해지고, 재작업 비용이 줄어든다. '5분의 명확한 의도가 1시간의 코드 재생성을 아낀다'는 표현이 이를 잘 요약한다.
같은 맥락에서 dev.to의 「Editorial Engineering」은 AI 활용 개발자의 실제 작업 방식을 또 다른 언어로 설명한다. 저자는 '바이브 코딩(vibe coding)'이나 '에이전틱 엔지니어링' 같은 기존 레이블이 자신의 경험을 담지 못한다고 말한다. 자신이 하는 일은 오히려 잡지 에디터의 일과 닮았다—에이전트가 초안을 쓰면, 자신은 그것을 읽고, 되돌려 보내고, 기준을 적용하고, 최종 결과물에 이름을 건다.
이 비유는 프론트엔드 개발자의 역할 재편을 이해하는 데 꽤 유효하다. 에디터의 일은 타이핑을 줄이지 않는다—오히려 낯선 코드를 읽고 판단하는 인지 비용이 실재하며, AI가 빠르게 생성할수록 평가해야 할 코드의 볼륨도 늘어난다. 생산성의 레버리지는 단일 태스크의 시간 단축이 아니라 병렬화에서 온다. 한 에이전트가 리팩토링을 처리하는 동안, 다른 에이전트는 새 기능의 스펙을 프로토타이핑한다. 인간은 편집 작업을 프로젝트 전체 너비에 걸쳐 수행하게 된다.
시사점: 프론트엔드 개발자에게 무엇이 남는가
velog의 「AI 시대의 서비스 기획」은 이 흐름을 제품 기획 관점에서 확인해준다. 2024~2026년 AI 네이티브 서비스 시대의 핵심 차별화 요소는 모델 품질과 독점 데이터다. 그리고 그 사이를 연결하는 'Builder'—기획·개발·디자인을 AI와 함께 혼자 수행하는 사람—의 존재가 부상하고 있다. 2020년에 5명이 1개를 만들었다면, 2024년에는 2명이 5개를, 2026년에는 1명이 10개를 만드는 구조로 변화하고 있다는 것이다.
이 세 글이 공통적으로 가리키는 것은 하나다: 프론트엔드 개발자의 경쟁 우위는 '구현 속도'에서 '판단의 질'로 이동하고 있다. 좋은 코드를 빠르게 타이핑하는 능력은 이제 에이전트와 공유된다. 하지만 다음은 여전히 인간의 몫이다.
- 수백 개의 가능한 기능 중 지금 가장 중요한 하나를 고르는 능력
- 다섯 개의 프로토타입 중 '맞는 것'을 감지하는 감각
- 에이전트가 오후에 구현해줄 수 있는 기능을 '잘못된 방향'이라는 이유로 킬할 수 있는 결단력
- 에이전트가 코드로 변환할 수 있을 만큼 명확하게 의도를 언어화하는 능력
「Editorial Engineering」의 저자가 인정하는 것처럼, 손실도 분명히 있다. 머릿속에서 패턴을 뽑아내며 키보드를 달리던 그 즐거움, 십 년간 쌓인 신택스 유창성은 서서히 dormant 상태가 된다. 하지만 그 자리를 채우는 것은 더 넓은 시야에서 제품을 보는 역할이다. 코드 한 줄이 아니라 사용자 여정 전체를 읽는 역할.
전망: '렌즈'를 갖춘 개발자가 살아남는다
물론 3인 팀 구조가 모든 맥락에 적용되는 건 아니다. 「The Three-Person Team」 저자 스스로 인정하듯, 병원 기록 시스템이나 결제 인프라처럼 실수의 비용이 높은 영역에서는 여전히 전문화와 깊은 도메인 지식이 요구된다. AI 네이티브 소형 팀은 애플리케이션, 프로덕트, 내부 도구, 기능 개발 레이어에서 이미 작동 중인 모델이다.
프론트엔드 개발자로서 지금 당장 해볼 수 있는 실천은 단순하다. Cursor나 Claude Code로 구현을 위임하기 전에, 스펙을 먼저 언어화하는 습관을 만드는 것이다. 사용자가 어떤 마찰을 느끼는지, 그 마찰을 줄이기 위해 시스템이 무엇을 해야 하는지, 그 문장이 충분히 명확해졌을 때 에이전트에게 넘긴다. 'onboarding checklist를 추가하라'가 아니라 '가입 후 2분 안에 첫 번째 의미있는 액션이 명확하게 보이도록 만들어라'—이 차이가 AI 시대 개발자의 실력 차이가 된다.
헤드카운트가 줄어드는 건 증상이다. 팀의 형태가 바뀌는 것이 본질이다. 그 형태 변화의 중심에 서기 위해, 프론트엔드 개발자에게 필요한 것은 더 빠른 타이핑이 아니라—더 선명한 렌즈다.