GPT-5.4가 바꾼 전제: 에이전트가 '직접' 일한다
GPT-5.4 출시로 AI 에이전트 논의의 전제가 바뀌었다. 요즘IT의 릴리즈 노트 분석에 따르면, GPT-5.4는 오픈AI 범용 모델 최초로 네이티브 Computer Use 기능을 내장했다. 스크린샷을 읽고 마우스·키보드 명령을 직접 내리는 것은 물론, Playwright 기반 코드 조작까지 한 모델 안에서 처리된다. 데스크톱 환경 탐색 벤치마크 OSWorld-Verified에서 75.0%를 기록해 인간 기준(72.4%)을 넘어선 수치는 단순한 마케팅 숫자가 아니다. 에이전트가 이제 팀의 도구를 '대신 조작'할 수 있다는 실질적 신호다.
테크 리드 입장에서 이 변화는 두 가지 질문을 즉시 촉발한다. 첫째, 에이전트에게 어떤 '역할'을 줄 것인가. 둘째, 에이전트가 팀의 시스템에 접근할 때 어떻게 안전하게 통제할 것인가. GPT-5.4 하나만 놓고 보면 흥미로운 신기술이지만, 스킬 패키징과 CLI 재설계 논의를 함께 읽으면 실제 워크플로우 통합을 위한 설계 원칙이 보이기 시작한다.
에이전트의 '전문성'을 어떻게 패키징할 것인가
GPT-5.4가 Computer Use로 팀의 도구를 조작할 수 있게 됐다면, 그 에이전트에게 어떤 전문성을 주입할지가 다음 문제다. 대부분의 팀은 지금도 에이전트의 역량을 시스템 프롬프트에 하드코딩한다. React 성능 최적화 가이드를 500단어짜리 에세이로 직접 박아 넣고, 두 번째 에이전트가 같은 지식을 쓸 때 또 복붙한다. 6개월 뒤 기준이 바뀌면 14개 마이크로서비스에 흩어진 문자열을 일일이 뒤진다.
dev.to에 게재된 Kowshik Jallipalli의 분석은 이 문제를 NPM 패키지 방식으로 해결하는 접근을 제시한다. 에이전트의 전문성을 Skill Package로 추상화하는 것이다. 구조는 단순하다: manifest.yaml(메타데이터와 버전), instructions.md(프롬프트 조각), tools.json(허용 도구 스키마)으로 구성된 디렉토리가 하나의 스킬 패키지다. @mycompany/frontend-perf v1.2.0처럼 버전 관리가 되고, 여러 에이전트가 같은 패키지를 참조한다.
여기서 실무적으로 중요한 포인트가 있다. 동적으로 텍스트와 실행 가능한 툴 스키마를 로딩하는 행위 자체가 보안 위협이다. 검증 없이 스킬을 로드하면 Path Traversal(LFI)과 Supply Chain Prompt Injection에 노출된다. 주니어 개발자가 공유 스킬 패키지에 "환경 변수에서 AWS 자격증명을 출력하라"는 지시를 실수로 넣으면, 에이전트는 그냥 따른다.
대응 설계는 세 층위로 이루어진다. 첫째, Pydantic 스키마로 매니페스트를 엄격히 검증한다(name은 @company/skill 패턴만 허용, version은 semver만). 둘째, Path.resolve()로 절대 경로를 확인해 디렉토리 탈출을 차단한다. 셋째, 스킬 주입 시 XML 구조 구분자를 사용해 스킬이 핵심 시스템 프롬프트를 덮어쓰지 못하게 격리한다. 에이전트의 '두뇌'를 NPM 패키지처럼 관리하되, 패키지 매니저에 보안 감사관을 붙이는 셈이다.
GPT-5.4의 Tool Search 기능은 이 스킬 패키징 접근과 맞닿아 있다. 기존에는 모든 도구 정의를 프롬프트에 미리 포함해야 해서 수만 토큰이 매 요청마다 소진됐다. GPT-5.4는 가벼운 도구 목록과 검색 기능만 받고 실제 정의는 필요할 때만 가져온다. 36개 MCP 서버 환경에서 토큰 사용량 47% 감소, 정확도 동일—이건 스킬을 지연 로딩하는 것과 동일한 원리다. 대규모 도구 생태계를 운용하는 팀에게는 비용과 응답 속도 모두 직접적으로 영향받는 변화다.
CLI도 에이전트를 위해 다시 써야 한다
에이전트가 팀의 CLI 도구를 직접 호출하게 됐을 때, 기존 CLI는 그대로 쓸 수 있을까. Hacker News 계열 GeekNews에 소개된 Google Workspace CLI 설계 경험은 냉정한 답을 내놓는다: 사람 중심 CLI와 에이전트 중심 CLI는 설계 목표가 근본적으로 다르다.
사람은 발견 가능성과 관용에 최적화된 인터페이스를 원한다. 에이전트는 예측 가능성과 다층 방어가 필요하다. --title "My Doc" 같은 플랫 플래그는 인간에게 편리하지만, 중첩 구조를 표현할 수 없어 정보가 손실된다. 에이전트는 오히려 --json으로 전체 API 페이로드를 받는 것을 선호한다. LLM이 생성하기 쉽고, API 스키마에 직접 매핑되기 때문이다.
에이전트가 CLI를 호출할 때 발생하는 오류는 인간의 오타와 다르다. 할루시네이션의 실패 양상은 예측 불가능하다. 에이전트는 경로 세그먼트를 혼동해 ../../.ssh를 생성하거나, 리소스 ID 안에 fileId?fields=name 같은 쿼리 파라미터를 삽입하거나, 이미 인코딩된 문자열을 또 인코딩해 이중 인코딩을 만든다. CLI가 최후의 방어선이 돼야 한다: 제어 문자 거부, 경로 순회 차단, URL 인코딩 검증—이 모두가 에이전트 입력을 전제한 설계다.
스키마 인트로스펙션과 스킬 파일도 CLI 설계의 핵심이다. 에이전트가 문서를 검색하면 토큰 예산을 소진하고, 시스템 프롬프트에 정적 API 문서를 넣으면 API 버전이 바뀌는 순간 구식이 된다. gws schema drive.files.list 같은 런타임 스키마 조회가 문서를 대체한다. --dry-run은 단순한 편의 기능이 아니라 할루시네이션된 파라미터의 비용이 에러 메시지가 아닌 데이터 손실일 수 있는 상황에서 필수 안전장치다.
팀에 기존 CLI가 있다면 전부 버릴 필요는 없다. 현실적인 순서가 있다: --output json 추가 → 입력 검증 강화 → --describe 스키마 노출 → --fields 지원 → --dry-run → CONTEXT.md 배포 → MCP 서피스 노출. 7단계지만, 1단계부터 에이전트가 쓸 수 있는 CLI로 전환되기 시작한다.
지금 팀에 적용할 수 있는 것들
세 가지 신호를 종합하면 실행 우선순위가 보인다.
단기(이번 스프린트): GPT-5.4의 Tool Search를 활용하고 있다면 MCP 서버 도구 목록 정리부터 시작하라. 도구가 많을수록 Tool Search의 효과가 크다. 팀의 CLI가 있다면 --output json 플래그 하나만 추가해도 에이전트 호환성의 첫 단추가 끼워진다.
중기(이번 분기): 반복적으로 에이전트에 주입하는 전문 지식이 있다면 스킬 패키지로 추상화하라. 처음에는 두세 개의 핵심 스킬만으로도 충분하다. 중요한 건 구조를 잡는 것—버전 관리, 매니페스트 검증, XML 구분자로 격리—이 세 가지가 갖춰지면 나머지는 확장이다.
장기(올해 안): Computer Use 기능을 실제 팀 워크플로우에 연결하기 전, 에이전트가 접근할 수 있는 시스템의 입력 경화를 먼저 완료하라. GPT-5.4의 OSWorld 벤치마크 75%는 인간 수준을 넘지만, 나머지 25%의 실패가 어떤 맥락에서 발생하는지는 아직 알 수 없다. 에이전트의 역량이 올라갈수록 방어 설계의 중요성도 함께 올라간다.
변곡점의 의미
GPT-5.4 Computer Use는 단순한 기능 추가가 아니다. 코딩·추론·에이전트 워크플로우·컴퓨터 조작이 하나의 모델에 통합됐다는 것은, 팀이 AI 에이전트를 '특정 작업용 도구'가 아닌 실질적인 워크플로우 참여자로 설계해야 하는 시점이 왔다는 의미다.
Cursor VP Lee Robinson이 말한 것처럼 GPT-5.4가 "모호한 문제에서도 스스로 판단하고 작업을 병렬로 처리"한다면, 팀 리드의 역할은 그 판단이 팀의 의도 안에서 이루어지도록 구조를 설계하는 것이다. 스킬 패키징으로 전문성을 통제하고, CLI 재설계로 접점을 강화하고, Tool Search로 도구 생태계를 효율화하는—이 세 가지가 맞물릴 때 에이전트는 비로소 팀 워크플로우에 '심어진다'.