지금 무슨 일이 벌어지고 있나
이번 주 AI 개발 생태계에서 주목할 만한 신호 세 개가 동시에 터졌다. OpenAI가 GPT-5.4를 공개하면서 범용 모델 최초로 네이티브 computer-use 기능을 탑재했고, The Pragmatic Engineer의 개발자 설문(약 1,000명 응답)에서는 Claude Code가 GitHub Copilot과 Cursor를 제치고 사용률 1위에 올랐다. 그리고 한 기획자(PO)가 7일간의 AI Native Camp 참여 후 Claude Code로 데이터 조회·분석·인사이트 초안 작성을 자동화했다는 경험을 공유했다. 각각 따로 보면 뉴스지만, 붙여서 보면 팀 구조에 대한 질문이 된다.
GPT-5.4의 핵심은 '코딩 성능 향상'이 아니다
Geek News 보도 기준으로 GPT-5.4의 스펙은 화려하다. SWE-Bench Pro 57.7%, OSWorld-Verified 75.0%(인간 72.4% 초과), 1M 토큰 컨텍스트, Tool Search로 MCP 서버 전환 시 토큰 사용량 47% 감소. 숫자만 보면 코딩 모델의 업그레이드처럼 읽힌다.
그런데 내가 주목하는 건 따로 있다. computer-use의 실용화다. 브라우저 스크린샷을 해석해 마우스·키보드를 직접 조작하는 기능이 범용 모델에 내장됐다는 건, AI가 더 이상 '코드를 생성하는 도구'가 아니라 '워크플로우를 실행하는 에이전트'로 전환됐다는 선언이다. Playwright 기반의 시각적 디버깅, 다단계 도구 호출, 스프레드시트·프레젠테이션 작업 자동화까지—이 기능들이 결합되면 개발자뿐 아니라 모든 지식 노동자의 반복 업무가 사정권에 들어온다.
물론 냉정하게 볼 필요도 있다. 272K 토큰 초과 시 2배 과금, GPT-5.4 API 출력 토큰당 $15(gpt-5.4 기준)라는 비용 구조는 실험적 사용과 프로덕션 투입 사이의 거리를 아직 유지시킨다. 긴 컨텍스트 구간(512K~1M)에서 성능이 급격히 떨어지는 수치(MRCR v2 기준 36.6%)도 숨기지 말아야 할 현실이다.
Claude Code 1위가 의미하는 것
Dev.to의 AI Weekly 보도에 따르면, Claude Code는 2025년 5월 출시 후 8개월 만에 개발자 설문 1위를 차지했다. 소규모 팀에서는 75%가 주 도구로 사용한다. 더 눈에 띄는 수치는 따로 있다—응답자의 55%가 이제 자동완성이 아닌 AI 에이전트를 정기적으로 쓴다.
이 변화는 도구 선호의 문제가 아니다. 개발자가 AI와 일하는 방식 자체가 '제안 수락/거절'에서 '작업 위임 후 검토'로 이동했다는 신호다. Claude Code가 선택받은 이유도 단순 코드 생성 품질이 아니라, 로컬 파일 시스템 접근·명령 실행·Skills 기반 워크플로우 재사용 같은 에이전트적 특성 때문이라는 점이 브런치 기고에서도 확인된다.
다만 이 흐름에는 부작용도 따라온다. 같은 보도에서 Gentoo Linux, NetBSD 등 오픈소스 프로젝트들이 AI 생성 기여를 전면 금지했다는 내용도 나온다. AI 에이전트가 생산하는 코드의 양이 늘수록 리뷰어의 판단 부담도 같이 커진다. 속도와 품질 사이의 긴장은 도구가 좋아진다고 자동으로 해소되지 않는다.
기획자의 실험이 던지는 진짜 질문
브런치에 올라온 기획자의 경험은 조용하지만 핵심을 찌른다. 7일간 Claude Code를 직접 설치하고 세팅하면서 터미널을 다룬 비개발자가, 데이터 조회→분석→인사이트 정리→Slack 공유까지의 흐름을 자동화했다. 완전한 자동화는 아니지만 "반복 작업에 쓰던 에너지를 판단이 필요한 영역으로 돌렸다"는 표현이 정확하다.
이 사례가 팀 리빌딩 관점에서 중요한 이유는 하나다. AI 도구의 사용 범위가 개발 직군 경계를 넘었다. 코딩 능력이 없어도 업무 흐름을 구조화하고 AI에 위임하는 역량이 생기면, 기획자·PM·데이터 분석가가 직접 반복 업무를 자동화할 수 있다. 이건 개발자 생산성 향상 이야기가 아니라, 팀 전체의 AI 리터러시가 경쟁력이 되는 이야기다.
팀 리빌딩 관점의 시사점
세 가지 신호를 종합하면 실무 팀에 즉시 적용 가능한 관찰 세 가지가 나온다.
첫째, 에이전트 설계 능력이 새로운 T자 역량이다. Subagent 구조로 복잡한 업무를 쪼개고, Skills·CLAUDE.md로 재사용 가능한 워크플로우를 정의하는 능력—이건 개발자만의 영역이 아니다. 기획자 사례처럼 '업무를 구조화하려는 사람'이라면 누구든 시작점이 될 수 있다.
둘째, AI 도구 온보딩의 기준이 바뀌어야 한다. '어떤 도구를 쓰나'보다 '어떻게 요청하나'가 더 중요해졌다. 브런치 기고자가 7일 캠프에서 가장 의미 있었다고 꼽은 것도 기능 학습이 아니라 "목적과 맥락을 명확히 정의하는 연습"이었다. 온보딩 설계가 도구 튜토리얼이 아닌 사고 방식 훈련으로 전환돼야 한다.
셋째, 품질 게이트는 여전히 사람이 잡아야 한다. GPT-5.4가 중요한 데이터 손실 버그를 놓쳤다는 Hacker News 코멘트는 축소하면 안 된다. 생성 속도가 빨라질수록 검토 없이 통과되는 결함도 같이 늘어난다. AI가 초안을 만들고 사람이 판단하는 구조는 선택이 아니라 필수다.
앞으로 6개월을 어떻게 볼 것인가
NIST의 AI 에이전트 보안 표준 이니셔티브, Google의 gRPC-MCP 기여, Linux Foundation의 MCP 관리 이관—이 움직임들은 에이전트 인프라가 실험 단계를 넘어 거버넌스 단계로 진입했음을 보여준다. 표준이 쌓이면 프로덕션 투입의 문턱이 낮아지고, 그 속도는 팀이 준비되어 있든 아니든 상관없이 진행된다.
내가 팀에 던지는 질문은 이것이다. 지금 우리 팀에서 가장 반복적인 지식 노동은 무엇인가? 그 목록을 만드는 것부터 AI-First 전환이 시작된다. GPT-5.4의 computer-use가 됐든 Claude Code의 Skills가 됐든, 도구는 이미 충분히 강력하다. 남은 건 팀이 그 도구를 어떻게 업무 흐름에 녹여낼지를 설계하는 능력이다.