구글이 움직였습니다. 엔지니어만이 아닙니다. 영업, 전략, 비기술 직군까지 AI 활용을 요구하고, 일부는 연말 성과 평가(GRAD)에 AI 사용 빈도를 반영하겠다고 공식 통보했습니다. AI타임스 보도에 따르면 구글 CFO는 "전체 코드의 약 50%가 AI 에이전트가 작성하고 인간 엔지니어가 검토하는 방식"이라고 밝혔습니다. 메타와 마이크로소프트도 같은 방향입니다. AI 도구를 '잘 쓰는 몇 명'이 아니라 '팀 전체가 쓰는 기본값'으로 만드는 흐름이 빠르게 굳어지고 있습니다.
그렇다면 팀 전체가 AI를 쓴다는 게 실제로 어떤 모습일까요? 도구를 어떻게 설계하고, 어디서 자동화하고, 어디서 인간이 개입해야 할지—그 구체적인 그림이 최근 커뮤니티에서 빠르게 쌓이고 있습니다.
GitHub Copilot: 프롬프트 한 개로 열 개를 대신한다
dev.to에 올라온 'Coding on a Ration' 포스트는 조금 유머러스하지만 핵심을 찌릅니다. GitHub Copilot 무료/기본 플랜을 쓰는 대부분의 개발자는 월간 요청 쿼터가 있고, 이 한도를 효율적으로 쓰는 것이 생산성을 좌우합니다. 문제는 많은 팀이 Copilot을 '채팅 창에 명령 하나씩 치는 도구'로만 쓴다는 겁니다.
여기서 결정적인 차이가 생깁니다. dotnet test 실행 → 에러 확인 → 수정 요청 → 재실행 → 커밋, 이 다섯 단계를 프롬프트 다섯 개로 쓰는 팀이 있고, 하나의 지시문으로 전부 묶는 팀이 있습니다. "테스트를 실행하고, 실패하면 원인을 파악해서 고치고, 다시 테스트를 돌려서 확인되면 커밋해줘." 이게 전부입니다. 프롬프트 소비는 5분의 1로 줄고, 실제 처리량은 배로 늘어납니다.
더 나아가 .github/copilot-instructions.md에 프로젝트 기본 규칙을 문서화하고, agent.yml로 Agent Hooks를 설정하면 반복 작업은 프롬프트 바깥으로 빠집니다. 빌드 전 의존성 복원, 테스트 후 코드 포맷, 변경사항 자동 스테이징—이런 것들이 에이전트 동작의 전제조건으로 '구워지는' 거죠. 이거 자동화하면 팀원들이 정말 중요한 판단에 집중할 수 있어요.
Claude Code: 책상을 떠나도 AI는 멈추지 않는다
Claude Code를 쓰다 보면 반드시 부딪히는 벽이 있습니다. 에이전트가 파일 수정이나 명령 실행 전에 승인을 요청하는데, 자리를 비운 순간 에이전트가 15분째 멈춰있는 상황입니다. 터미널 앞에 붙어있거나, 아니면 모든 걸 허용 목록에 넣거나—둘 다 좋은 선택이 아닙니다.
dev.to의 claude-push 프로젝트가 이 딜레마를 60줄짜리 bash 스크립트로 풉니다. Claude Code의 PermissionRequest 훅과 무료 푸시 알림 서비스 ntfy.sh를 연결하면, 에이전트가 승인을 요청할 때 스마트폰으로 알림이 날아오고 Allow/Deny 버튼 하나로 응답할 수 있습니다. 회의 중에도, 커피 타러 가는 중에도 가능합니다. 타임아웃 이후엔 자동으로 터미널 프롬프트로 폴백되어 권한이 조용히 승인되는 일은 없습니다.
이 구조가 중요한 이유는 HITL(Human-in-the-Loop)을 '편한 방식으로' 유지한다는 점입니다. 자동화의 범위를 넓히면서도 인간 판단이 개입하는 체크포인트를 없애지 않는 설계—이게 AI-First 워크플로우의 핵심 원칙 중 하나입니다.
AI 보안 리뷰: 선택이 아니라 기본값
이번 주 보안 커뮤니티를 뒤흔든 소식이 있습니다. AI 시스템이 OpenSSL에서 제로데이 취약점 12개를 독립적으로 발견했는데, 그 중 세 개는 1998년부터 27년간 살아남은 버그였습니다. Google을 포함한 여러 조직의 수백만 CPU-시간 퍼징을 통과한 것들입니다. dev.to 보도에 따르면, Anthropic의 Claude Code Security(Claude Opus 4.6 기반)는 프로덕션 오픈소스 코드베이스에서 500개 이상의 취약점을 찾아냈습니다.
인간 리뷰어의 한계는 명확합니다. 피로, 맥락 전환 비용, 전체 의존성 그래프를 머릿속에 담아두는 것의 불가능성. AI는 이 제약이 없습니다. 콜 체인 전체를 맥락으로 잡고 추론합니다. 결론은 단순합니다. 2026년에 AI 기반 보안 스캔 없이 코드를 배포한다면, 그건 알려진 맹점을 가진 채 배포하는 것입니다. 인증, 파일 파싱, 네트워크 I/O—이 경로에는 AI 리뷰를 CI/CD의 기본값으로 넣어야 합니다.
동시에 주의해야 할 역설도 있습니다. OpenClaw 사례가 보여줍니다. 10만 GitHub 스타를 받은 AI 에이전트 플랫폼이 치명적인 RCE 취약점과 서드파티 마켓플레이스의 악성 스킬 341개로 붕괴했습니다. Sabrina Ramonov의 분석처럼 "기술 실패가 아니라 신뢰 모델 실패"입니다. AI가 보안을 강화하는 동시에 새로운 공격 표면을 만들고 있다는 것—에이전트를 설계할 때 권한 범위를 세션 단위로 제한하고, 서드파티 스킬에 대한 신뢰를 플랫폼 아키텍처 수준에서 검증하는 것이 필수입니다.
팀 차원에서 AI-First를 만든다는 것
구글의 사례로 돌아와서—이게 왜 중요하냐면, AI 도구 도입의 가장 큰 장벽이 '좋은 도구가 없어서'가 아니라는 걸 증명하기 때문입니다. 구글만큼 좋은 도구를 가진 회사가 없는데도 공식적으로 의무화하고 성과 평가에 반영해야 한다는 것은, 변화는 문화와 구조로 만들어야 한다는 뜻입니다.
팀 리빌딩 관점에서 지금 당장 할 수 있는 것들이 있습니다. Copilot Instructions 파일을 팀 레포에 넣고 표준화하기, Claude Code 승인 워크플로우를 팀 단위로 설정하기, CI/CD에 AI 보안 스캔 단계 추가하기. 그리고 이것들이 개인 생산성 해킹이 아니라 팀의 기본 운영 방식이 되도록 만드는 것. 구글이 인사평가에 반영하는 이유가 바로 여기에 있습니다.
"이거 Claude한테 물어보니까 이런 구조가 나오더라"가 한 명의 습관에서 팀 전체의 루틴이 되는 순간—그때 AI-First 팀이 완성됩니다. 도구는 이미 충분히 준비되어 있습니다.