'AI가 챗봇에서 업무 에이전트로 전환된다'는 말은 이미 1년 넘게 들어왔다. 그런데 이번엔 다르다. OpenAI가 발표한 ChatGPT Work는 단순한 기능 추가가 아니라, AI 제품 경쟁의 평가 기준 자체가 바뀌었음을 선언하는 신호다. 지금까지 AI 제품은 '얼마나 똑똑한 답을 내놓는가'로 평가받았다. 앞으로는 '실제 업무를 얼마나 완료시켜주는가'가 기준이 된다.
ChatGPT Work의 핵심은 GPT-5.6 모델과 Codex 기술을 결합해, 여러 앱과 파일을 넘나들며 복잡한 업무를 단계별로 수행하고 완성된 결과물까지 만들어내는 것이다. 디일렉 보도에 따르면 Scheduled Tasks 기능으로 사용자가 자리를 비운 사이에도 반복 업무를 이어가고, Computer Use로 화면 클릭과 파일 이동까지 백그라운드에서 처리한다. Slack, Google Drive, Microsoft 365, CRM까지 플러그인으로 연결되니 이건 어시스턴트가 아니라 사실상 주니어 팀원에 가깝다.
프론트엔드 개발자 입장에서 이 변화를 가장 직관적으로 정리하면 이렇다. 기존 워크플로우는 '사용자가 묻고 → AI가 답하고 → 사용자가 실행한다'는 구조였다. 에이전트 워크플로우는 '사용자가 목표를 주고 → AI가 단계를 쪼개고 → 도구를 쓰고 → 결과물을 만들고 → 사용자가 검토하고 승인한다'로 바뀐다. 이 두 구조의 차이는 단순한 편의성의 차이가 아니다. 설계해야 할 제품의 종류 자체가 달라진다.
dev.to의 분석이 정확히 짚은 것처럼, Codex가 의미 있는 이유는 코딩 에이전트이기 때문이 아니다. '목표를 이해하고 → 컨텍스트를 파악하고 → 도구를 쓰고 → 출력을 확인하고 → 반복하는' 루프 패턴이 이제 IDE 바깥의 일반 업무로 확장되기 때문이다. 프론트엔드 개발자가 만드는 프로덕트도 마찬가지다. 사용자에게 텍스트 입력창을 주는 것이 아니라, 사용자의 반복되는 작업 흐름 전체를 에이전트가 처리하도록 설계하는 것이 다음 단계다.
그렇다면 에이전트 시대의 프로토타이핑-검증-고도화 루프는 어떻게 재설계해야 할까. 힌트는 의외로 작은 오픈소스 프로젝트에서 온다. GeekNews에서 소개된 htmldrop은 AI가 생성한 HTML을 링크 하나로 즉시 공유할 수 있는 서비스다. MCP 서버를 붙여두면 에이전트가 결과물을 만들고 링크까지 알아서 공유한다. 이 작은 도구가 의미심장한 건, 에이전트가 생성한 산출물이 '파일로 저장되어 나중에 확인하는 것'이 아니라 '즉시 공유 가능한 URL로 팀원이나 사용자에게 전달되는 것'으로 바뀌는 흐름을 보여주기 때문이다.
이 흐름은 프론트엔드 워크플로우에 구체적인 설계 과제를 던진다. 에이전트가 만든 UI 프로토타입을 사용자가 즉시 클릭해볼 수 있어야 하고, 그 피드백이 다시 에이전트의 다음 이터레이션으로 연결되어야 한다. v0.dev 같은 도구가 코드를 생성하고, htmldrop 같은 도구가 그 결과를 URL로 만들고, 사용자가 실제로 써보고 피드백을 주면 에이전트가 다음 버전을 만드는 루프—이게 에이전트 시대의 빠른 프로토타이핑이 지향하는 그림이다. 설계자가 관리해야 할 것은 이 루프의 속도와 품질이다.
시사점은 명확하다. 앞으로 프론트엔드 개발자가 집중해야 할 설계 영역이 세 가지 이동한다. 첫째, '컴포넌트를 어떻게 구현할 것인가'에서 '에이전트가 어떤 순서로 어떤 도구를 써서 결과를 만들어낼 것인가'라는 에이전트 루프 설계로. 둘째, '사용자가 입력하는 폼'에서 '에이전트가 사용자 대신 실행하는 플로우'로. 셋째, '배포된 화면을 보여주는 것'에서 '에이전트가 만든 산출물을 즉시 공유하고 검증받는 말단 UX'로. 이 세 이동을 먼저 내재화한 팀이 에이전트 시대의 프로덕트 속도를 가져간다.
경고도 함께 읽어야 한다. dev.to 분석이 지적하듯 'input box + model response' 구조의 제품은 ChatGPT Work 같은 대형 플랫폼에 흡수될 가능성이 높다. 프론트엔드 개발자가 만드는 AI 제품이 살아남으려면 특정 직무의 특정 반복 작업을 더 깊게 파고드는 수직적 에이전트가 되어야 한다. '더 똑똑한 챗봇'이 아니라 '이 팀의 이 작업만큼은 끝까지 처리해주는 에이전트'가 목표여야 한다. 프론트엔드 개발자의 역할은 그 에이전트가 사용자와 만나는 접점, 즉 승인 UI와 결과 공유 인터페이스와 오류 복구 경험을 설계하는 것이다.
에이전트 시대는 프론트엔드 개발자를 위협하지 않는다. 다만 질문을 바꾼다. '이 버튼을 어떻게 만들 것인가'가 아니라 '이 에이전트가 사용자 대신 이 업무를 끝냈을 때, 사용자는 어디서 무엇을 확인하고 어떻게 다음 단계로 넘어가는가'—그 경험을 설계하는 사람이 되는 것. 프롬프트를 잘 쓰는 시대는 끝나가고, 워크플로우를 잘 설계하는 시대가 열리고 있다.