AI-native 팀에서 먼저 깨지는 것은 코드가 아니라 운영이다

코드 작성 비용이 내려가면 개발팀의 병목은 구현이 아니라 계획, 리뷰, 보안, 책임 구조로 이동한다.

AI-native engineering org라는 말은 멋있게 들린다.

모든 엔지니어가 Claude Code를 쓰고, PR이 빨리 나오고, 반복 구현이 줄고, 제품 실험이 많아지는 팀. 겉으로 보면 생산성 이야기처럼 보인다. 하지만 실제로 더 큰 변화는 다른 곳에서 일어난다.

코드 작성이 싸지면 오래된 프로세스가 깨진다.

Fiona Fung의 Running an AI-native engineering org는 이 변화를 조직 운영의 언어로 설명한다. 발표의 핵심은 “AI를 쓰면 개발자가 빨라진다”가 아니다. 코드 작성이 병목이 아니게 되면, 그동안 코드 작성의 느린 속도에 맞춰져 있던 계획, 리뷰, 협업, 보안, 유지보수 방식이 더 이상 맞지 않는다는 것이다.

이게 무서운 지점이다.

프로세스는 보통 크게 실패하지 않는다. 조용히 안 맞기 시작한다. 예전에는 설계 문서를 길게 쓰고, 회의를 잡고, 리뷰를 기다리고, 구현을 나눠서 진행하는 흐름이 자연스러웠다. 코드 작성이 비쌌기 때문이다. 만들기 전에 오래 생각하는 비용이 합리적이었다.

그런데 구현과 프로토타입이 싸지면 상황이 달라진다.

아이디어를 두고 오래 말다툼하는 것보다 실제 PR이나 프로토타입을 보는 편이 빠를 수 있다. 문서로 모든 가능성을 설명하기보다, 작게 만들어 내부 사용자를 붙여보고 반응을 보는 편이 낫다. 이때 예전 프로세스를 그대로 유지하면 이상한 일이 생긴다. 팀은 더 빨리 만들 수 있는데, 결정 방식은 여전히 느린 시대에 머문다.

하지만 반대로 아무 계획 없이 만들기만 하면 더 위험해진다.

코드가 싸졌다고 논의가 필요 없어지는 건 아니다. 오히려 alignment의 중요성은 커진다. 마지막에 PR을 올린 사람이 이기는 문화, 가장 오래 깨어 있던 사람이 방향을 밀어붙이는 문화는 AI 시대에 더 위험하다. 만들기가 쉬워질수록 잘못된 방향도 더 빨리 쌓인다.

그래서 AI-native 팀의 핵심은 속도가 아니라 규범이다.

무엇을 문서로 남길지, 무엇을 PR로 논의할지, 어떤 변경은 프로토타입으로 충분한지, 어떤 변경은 여전히 설계가 필요한지 정해야 한다. 모든 일을 가볍게 만들자는 뜻이 아니다. 무거워야 할 일과 가벼워져도 되는 일을 다시 나누자는 뜻이다.

리뷰도 달라진다.

AI가 코드를 많이 만들수록 사람은 모든 코드를 같은 깊이로 읽을 수 없다. 그러면 리뷰의 목적을 다시 정해야 한다. 스타일을 고치는 리뷰인지, 제품 감각을 보는 리뷰인지, 보안과 유지보수 리스크를 보는 리뷰인지 분리해야 한다. Claude가 잡을 수 있는 것은 Claude에게 맡기고, 사람이 봐야 하는 것은 더 명확히 봐야 한다.

보안도 뒤로 밀리면 안 된다.

생성 속도가 빨라질수록 잘못된 권한, 과한 자동화, 민감 정보 노출, 위험한 배포 경로도 빨리 생긴다. AI-native 팀은 “AI를 많이 쓰는 팀”이 아니라, AI가 빨리 움직일 때 어떤 gate가 필요한지 아는 팀이어야 한다.

인재상도 바뀐다.

영상에서 강조되는 두 축은 흥미롭다. 하나는 제품 감각이 있는 creative builder다. 문제를 발견하고, 빠르게 만들어보고, 사용자 경험을 다듬는 사람. 다른 하나는 깊은 시스템 전문성이다. 복잡한 기반 구조를 이해하고, 모델이 놓치는 낮은 층위의 문제를 잡는 사람.

중간의 반복 구현만 잘하던 역할은 압력을 받는다.

AI가 반복 구현을 싸게 만들면, 사람에게 더 중요해지는 것은 방향 감각과 깊이다. 무엇을 만들지 정하는 감각, 만든 것이 실제로 좋은지 보는 감각, 시스템이 어디서 깨질지 아는 감각이다. 단순히 “코드를 쓸 줄 안다”만으로는 충분하지 않다.

측정 지표도 조심해야 한다.

“AI가 몇 퍼센트의 코드를 썼나”는 쉬운 지표지만, 좋은 지표는 아니다. 코드가 늘어난 것이 곧 제품이 좋아진 것은 아니다. 중요한 건 품질, 신뢰성, 사용자 문제 해결, 유지보수성이다. AI-native 팀이 진짜로 봐야 하는 것은 output volume이 아니라 outcome이다.

이 점에서 AI-native라는 말은 도구 도입보다 조직 재설계에 가깝다.

Claude Code를 전원에게 설치한다고 팀이 AI-native가 되지 않는다. 코드가 빨라진 뒤 어떤 논의가 줄어들고, 어떤 검증이 늘어나야 하며, 어떤 역할이 더 중요해지는지 바꿔야 한다. 그렇지 않으면 팀은 더 많은 코드를 더 빠르게 만들 뿐, 더 나은 제품을 만들지는 못한다.

AI-native 팀의 첫 번째 변화는 손이 빨라지는 것이 아니다.

조직의 오래된 리듬이 안 맞기 시작하는 것이다.

그 리듬을 다시 맞추는 팀만이 속도를 진짜 힘으로 바꿀 수 있다.