누구나 만드는 시대, 진짜 차이는

AI가 코드를 대신 짜주는 지금, 정작 개발자의 일은 어디로 가고 있을까? 오늘 GeekNews에서 가장 많이 읽힌 세 글은 약속이라도 한 듯 같은 질문을 던진다. 만드는 일이 쉬워질수록, 무엇을 어떻게 만들지가 더 중요해진다는 것. Figma는 ‘완성도’를, OpenAI는 ‘배포의 소멸’을, Anthropic은 ‘에이전트가 스스로 짜는 워크플로우’를 이야기한다. 셋을 묶어 읽으면 2026년 개발자의 일이 어떻게 재정의되는지가 보인다.

누구나 만드는데 왜 안 팔릴까

속도는 기본값이 됐고, 남는 건 방향과 완성도

Figma가 블로그에 올린 글의 결론은 단순하다. AI로 누구나 제품을 만들 수 있게 되면서 속도는 더 이상 단독 차별화 요소가 아니다. 상상과 현실 사이의 거리가 거의 사라져 아이디어가 즉시 구현되니, 빠른 것은 이제 기본 조건일 뿐이다. 문제는 빠른 속도가 ‘잘못된 방향으로의 진전’을 ‘진전’으로 착각하게 만든다는 점이다.

Figma는 초보 빌더의 흔한 함정으로 첫 아이디어에 매달려 깊이만 파는 ‘로컬 언덕 오르기(local hill climbing)’를 꼽는다. 계속 동조만 하는 에이전트는 첫 아이디어 너머를 보여주지 못해 터널 시야에 빠지기 쉽다. 그렇다고 MECE식으로 넓게만 매핑하면 너무 추상적으로 머문다. 옳은 방법은 넓게·깊게 동시에 탐색하는 것 — AI로 여러 방향을 병렬로 펼쳐 각각을 엔드투엔드 경험까지 구체화한 뒤, 인터랙티브 프로토타입을 나란히 놓고 실제로 비교하는 방식이다.

가장 뼈아픈 지적은 따로 있다. 진짜 실패의 원인은 능력 부족이 아니라 첫 제안에 수긍하고 멈춰 버리는 수동성(passivity)이라는 것. AI가 내놓은 기본값(defaults)이 그대로 제품이 되면, 서로 구별되지 않는 ‘그럭저럭 괜찮은’ 제품의 바다가 된다. 완성도(craft)는 수용이 아니라 선택이고, 각 결정을 다시 따져 묻고 다듬고 덜어내며 “이게 정말 맞나”를 반복하는 능동적 행위다. Figma의 정리는 결국 세 단어로 압축된다 — 속도, 방향, 완성도. 최고의 팀은 이 셋을 맞바꾸지 않고 모두 쥔다.

이제 코드 없이 배포된다고?

OpenAI가 호스팅까지, 배포 워크플로가 사라진다

OpenAI가 Codex에 Sites 플러그인을 공개했다. 핵심은 별도 배포 워크플로 구성 없이 웹사이트·웹 앱·게임을 프롬프트만으로 생성·저장·배포·점검할 수 있다는 점이다. @Sites로 호출해 신규 사이트, 대시보드, 내부 도구를 만들거나 기존 프로젝트의 배포를 요청한다. 게시는 ‘버전 저장’과 ‘버전 배포’ 두 단계로 분리돼, 검토 가능한 후보를 만든 뒤 승인된 버전만 실제로 내보낸다.

기술 스택을 들여다보면 그림이 분명해진다. Sites는 Cloudflare Worker와 호환되는 ES 모듈로 빌드한 프로젝트를 호스팅하고, 영구 저장이 필요한 정형 데이터는 관계형 DB D1에, 이미지·문서·오디오·비디오 같은 파일은 객체 스토리지 R2에 담는다. 워크스페이스 인증은 물론 외부 ID 프로바이더 기반 인증까지 지원하며, 접근 모드는 소유자/관리자(admins_only), 워크스페이스 전체(workspace_all), 커스텀(custom) 세 가지로 나뉜다. 사이트 연결과 스토리지 바인딩 정보는 .openai/hosting.json에 저장되지만, 시크릿은 여기에 넣지 말고 .env로 관리하라고 못 박는다.

현재는 프리뷰 단계로, ChatGPT Business는 기본 활성화, Enterprise는 관리자 RBAC을 통해 기능을 켜야 사용할 수 있다. 프런트엔드와 DB, 스토리지, 인증, 배포가 하나의 프롬프트 흐름 안으로 들어왔다는 점에서, ‘바이브 코더’에게는 특히 강력한 도구가 될 전망이다.

에이전트가 스스로 팀을 짠다

Claude Code 동적 워크플로우, 작업마다 하네스를 즉석에서

Anthropic이 Claude Code에 동적 워크플로우(dynamic workflows)를 도입했다. 그동안 Research, 보안 분석, 에이전트 팀, 코드 리뷰처럼 최고 성능을 내려면 Claude Code 위에 별도의 맞춤 하네스(harness)를 직접 구축해야 했다. 동적 워크플로우는 이 하네스를 Claude가 작업에 맞춰 즉석에서 직접 작성하게 한다. 구체적으로는 JavaScript 파일을 실행해 서브에이전트를 생성·조율하며, 각 에이전트가 쓸 모델과 worktree 격리 여부까지 Claude가 스스로 정한다.

왜 필요한가? 기본 하네스는 단일 컨텍스트 윈도우에서 계획과 실행을 동시에 처리하는데, 장기·대규모 병렬·적대적 검증 작업에서는 세 가지 실패 모드에 취약하다. 다단계 작업을 끝내기 전에 멈추고 부분 완료를 완료로 선언하는 agentic laziness, 루브릭 대비 검증에서 자기 결과물을 편애하는 self-preferential bias, 그리고 턴이 쌓이며 특히 compaction 이후 원래 목표가 흐려지는 goal drift다. 분리된 컨텍스트를 가진 여러 Claude를 조율하면 이 문제들을 구조적으로 막을 수 있다.

활용 패턴도 정형화됐다. 작업을 작은 단계로 쪼개 각각 에이전트를 돌린 뒤 합치는 fan-out-and-synthesize, 생성된 결과를 별도 에이전트가 기준 대비 적대적으로 검증하는 adversarial verification, N개 에이전트가 서로 다른 접근으로 같은 작업을 겨루고 판정 에이전트가 pairwise로 우승자를 가리는 tournament 등이다. 흥미로운 건 코딩 밖에서 더 빛난다는 점 — 실제로 Bun이 워크플로우로 Zig에서 Rust로 재작성됐고, 이력서 80개 순위 매기기, Slack #incidents 6개월치 근본 원인 분석, 사업계획서를 투자자·고객·경쟁사 관점으로 검토하는 등의 사례가 제시됐다. 함께 공개된 /deep-research 스킬도 이 위에서 동작한다. 다만 토큰 소비가 크므로, “정말 더 많은 컴퓨팅이 필요한가”를 먼저 자문하라는 단서가 붙는다.

관련 글

• 프로덕트 디자인이 변하고 있다
• AI는 프런트엔드의 잃어버린 10년을 반복하게 하는가?
• OpenAI 프런티어 모델과 Codex가 이제 AWS에서 제공됨
• Claude Code, 다이나믹 워크플로우 기능 공개
• 대규모 코드베이스에서 Claude Code가 작동하는 방식

출처

1. Figma Blog — What matters when anyone can build
2. OpenAI Developers — Codex Sites
3. Claude Blog — A harness for every task: Dynamic workflows in Claude Code
4. GeekNews (news.hada.io) — 오늘의 인기 토픽