역할이 뒤바뀌고 있다
'개발자가 PM처럼 생각해야 한다'는 말은 오래됐다. 그런데 지금은 그 말의 의미가 바뀌었다. 이제는 개발자가 PM처럼 행동해야 하는 시대다. 코드를 직접 짜는 시간보다, 무엇을 만들지 결정하고 AI의 출력물을 검토하고 방향을 수정하는 시간이 더 길어지고 있다. dev.to에 최근 올라온 두 편의 실전 경험담—해외 여행 어댑터 툴을 Claude로 주말 만에 만든 사례와, AI 에이전트와 함께 Astro 6 마이그레이션을 진행한 사례—은 이 변화를 적나라하게 보여준다.
두 가지 실전 패턴이 말하는 것
첫 번째 사례부터 보자. Vientapps의 개발자는 여행 중 공항에서 '이 나라에서 어댑터 필요해?'를 매번 구글링하다 지쳐서 직접 툴을 만들기로 했다. 221개국, 15가지 플러그 타입을 커버하는 인터랙티브 도구다. 핵심은 구현 방식이다. 그는 Claude Code의 에이전트 런을 활용해 초기 빌드를 단 한 번의 실행으로 완성했다. 리스타일까지 포함해 이틀, 두 세션. 그의 표현이 정확하다: "내 역할은 코드를 짜는 개발자가 아니라, 결과물을 검토하는 PM에 가까웠다."
두 번째 사례는 결이 다르다. Astro 5에서 Astro 6으로의 마이그레이션—에러 로그를 AI 에이전트에게 붙여넣고, 에이전트가 진단하고, 개발자가 방향을 조율하는 방식으로 진행됐다. Tailwind CSS v4 전환, Content Layer API 마이그레이션, Cloudflare 어댑터 호환성 이슈까지. 에이전트는 빠르게 움직였지만, 확신에 차서 틀리기도 했다. post.id에 불필요한 .replace()를 붙이라고 제안하거나, 엉뚱한 방향의 PostCSS 설정을 밀어붙이는 식으로.
AI가 잘하는 것과 못하는 것의 경계
두 사례를 겹쳐보면 패턴이 선명해진다. AI 에이전트가 탁월한 영역은 범위와 속도다. 221개국 전기 규격 JSON 데이터셋을 한 번에 컴파일하고, 15가지 플러그 타입 SVG를 인라인으로 생성하고, Content Layer API 형식으로 코드를 재구성하는 일—이런 작업은 인간이 직접 하면 며칠이 걸릴 수 있는 것들이다.
반면 AI가 반복적으로 실패하는 지점은 정보 위계 설계다. 어댑터 툴의 초기 UI는 기술적으로 완전했지만, 실제로 쓸 수 없었다. 플러그 다이어그램, 전압 차트, 컨버터 가이드가 한꺼번에 쏟아졌다. 사용자가 원하는 건 단 하나—'뭔가 사야 해, 말아야 해?'라는 예스/노 판정인데. Astro 마이그레이션 사례에서도 에이전트는 '자신 있게 틀렸다'. 문서를 확인하도록 유도하기 전까지, 검증되지 않은 수정을 자신만만하게 제안했다.
이 두 사례가 공유하는 교훈: AI는 '무엇을 보여줄지'를 스스로 판단하지 못한다. 그 판단은 여전히 사람의 몫이다.
프로덕트 사고가 AI 활용의 실질적인 레버다
어댑터 툴 사례에서 결정적인 전환점은 '프로그레시브 디스클로저'를 적용하기로 한 판단이었다. 판정 결과를 맨 위 굵은 배너로, 구매 링크를 바로 아래에, 나머지 기술적 정보는 <details> 뒤에 접어두는 구조. 이건 Claude가 스스로 도달한 결론이 아니다. 개발자가 사용자 여정을 먼저 그리고, 그 구조를 구체적인 언어로 지시했을 때 비로소 나온 결과다.
흥미롭게도, 저자 스스로 회고에서 가장 아쉬웠던 점으로 꼽은 것도 같은 맥락이다: "와이어프레임 먼저 그렸어야 했다. 픽셀 단위 목업이 아니라, 정보 위계의 러프한 스케치라도." AI에게 레이아웃 제약 없이 '만들어줘'를 외치면, 에이전트는 기본값으로 '모든 데이터를 보여주는' 방향으로 수렴한다. 프로덕트 사고 없이 AI를 쓰면, 빠르게 복잡한 것을 만들 뿐이다.
개발자의 역할이 재정의되는 방식
두 사례가 보여주는 새로운 개발자 역할은 세 가지로 정리된다.
첫째, 문제 정의자. AI는 무엇을 만들지 모른다. '여행 어댑터 정보 사이트'가 아니라 '공항에서 30초 안에 답을 얻는 도구'라는 프레임을 잡는 건 사람이다.
둘째, 출력물 편집자. AI가 생성한 코드와 UI는 초안이다. 기술적 완성도와 실제 사용성은 다르다. Astro 마이그레이션 사례에서 개발자가 에이전트의 제안에 계속 '왜?'를 묻고 공식 문서로 되돌려 보낸 것처럼, 검증의 루프를 설계하는 것이 핵심 역량이 됐다.
셋째, 컨텍스트 설계자. 에이전트가 잘 작동하려면 제약 조건이 명확해야 한다. 어떤 정보를 먼저 보여주고, 무엇을 숨길지, 어떤 스택을 쓸지—이런 결정을 프롬프트에 녹여내는 것 자체가 개발자의 작업이 됐다.
앞으로의 전망: '판단 구조'를 설계하는 개발자
이 두 사례가 특별한 이유는, 단순히 'AI로 빠르게 만들었다'는 성공담이 아니기 때문이다. 두 저자 모두 AI가 잘못 가는 순간을 정직하게 기록했고, 그 순간마다 사람이 개입해 방향을 바로잡았다. 그 개입의 질이 최종 프로덕트의 품질을 결정했다.
AI 에이전트가 코드 생성의 많은 부분을 흡수할수록, 개발자에게 남는 것은 역설적으로 가장 인간적인 작업들이다. 사용자가 실제로 어떤 상황에서 이 도구를 쓰는지 상상하는 일, 기술적으로 가능한 것과 실제로 유용한 것을 구분하는 일, 에이전트의 확신 어린 제안에 '정말?'이라고 묻는 일.
프론트엔드 개발의 미래는 더 많은 코드를 짜는 방향이 아니라, 더 나은 판단 구조 위에서 AI를 운용하는 방향으로 이동하고 있다. 그 판단 구조를 설계하는 능력—그게 지금 가장 빠르게 가치가 오르는 개발자 역량이다.