AI Native는 AI를 많이 쓰는 게 아니다 — 일하는 방식을 다시 발명해야 하는 이유

팀에 Claude Code를 도입했다. 한 달 뒤 코드 생성량은 3배가 됐다. 그런데 제품 출시 속도는 변하지 않았다. 회의는 여전히 주 5회이고, 기획서는 여전히 구글 독스에 쌓이고, 코드 리뷰는 여전히 병목이다. 무엇이 잘못된 건가?

1. 도구를 바꿨는데 왜 아무것도 안 바뀌었을까

2025년은 AI 코딩 도구의 해였다. Cursor, Claude Code, GitHub Copilot, Windsurf — 팀마다 하나쯤은 도입했다. 도입 초기의 흥분은 대단했다. “코드가 알아서 나온다!” “보일러플레이트를 안 쳐도 된다!” 생산성 지표는 실제로 올라갔다. 코드 생성량, 커밋 수, PR 생성 속도 — 숫자만 보면 혁명이다.

그런데 한 발 뒤로 물러서면, 이상한 것이 보인다.

코드를 3배 빨리 쓰는데, 기능 출시는 왜 똑같이 2주 걸리는가? 답은 단순하다. 코드를 쓰는 시간은 전체 개발 프로세스의 일부일 뿐이기 때문이다. 기획, 설계, 리뷰, QA, 배포, 커뮤니케이션 — 이 모든 단계가 여전히 “AI 이전”의 방식으로 돌아가고 있다. 펜을 워드프로세서로 바꿨지만, 여전히 같은 보고서를 쓰고 있는 것이다.

이것이 “AI를 도입한 조직”과 “AI Native 조직”의 본질적 차이다.

2. AI Enabled ≠ AI Native — 리트머스 테스트

IBM은 AI Native를 이렇게 정의한다. “AI를 핵심 구성 요소로 처음부터 설계된 제품, 회사, 또는 워크플로우.” 그리고 결정적인 한 문장을 덧붙인다. “AI를 제거하면 제품 자체가 무의미해진다.”

이것이 가장 강력한 리트머스 테스트다.

지금 당신 팀의 워크플로우에서 AI를 빼보라. Copilot을 끄고, Claude Code를 제거하고, ChatGPT 접속을 차단해보라. 팀이 여전히 동일한 프로세스로 일할 수 있다면 — 좀 느려질 뿐 본질적으로 같은 방식이라면 — 그것은 AI Native가 아니다. AI Enabled일 뿐이다.

업계에서 혼용되는 세 가지 용어를 정리하면 이렇다.

AI Enabled — 기존 프로세스에 AI를 “얹은” 상태다. Excel에 Copilot을 추가하면 수식 작성이 빨라진다. 하지만 여전히 Excel이고, 여전히 스프레드시트 기반 업무다. AI를 제거해도 기본 기능은 작동한다.

AI First — AI를 최우선 전략적 고려 사항으로 삼는 상태다. 새 프로젝트를 시작할 때 “이걸 AI로 할 수 있는가?”를 먼저 묻는다. Google이 2016년에 선언한 “AI First” 전략이 대표적이다. 하지만 조직 구조와 프로세스는 기존 것을 유지하면서 AI를 우선시하는 것이므로, 근본적 재설계와는 거리가 있다.

AI Native — AI가 아키텍처의 핵심이다. AI 없이는 존재 자체가 불가능하다. 프로세스, 조직 구조, 문화가 AI를 전제로 설계되어 있다. Perplexity에서 AI를 빼면 검색 엔진이 아니라 빈 껍데기가 된다. Claude Cowork에서 AI를 빼면 빈 화면만 남는다. 이것이 AI Native다.

Cloud Native 비유가 이 차이를 가장 잘 설명한다. 기존 서버를 AWS에 올리는 것은 “클라우드를 사용하는 것(Cloud Enabled)“이지, Cloud Native가 아니다. Cloud Native는 마이크로서비스, 컨테이너, 자동 스케일링 — 클라우드의 속성을 전제로 아키텍처를 처음부터 다시 설계하는 것이다. 마찬가지로, 기존 업무에 AI 도구를 추가하는 것은 AI Native가 아니다. AI의 속성을 전제로 일하는 방식 자체를 다시 설계하는 것이 AI Native다.

3. “이전에는 하지 못했던 일” — AI Native의 진짜 가치

Anthropic은 2025년 8월, 자사 엔지니어와 연구원 132명을 대상으로 내부 연구를 수행했다. 53명의 심층 인터뷰와 Claude Code 사용 데이터 분석을 포함한 체계적 조사였다.

결과 중 가장 주목할 숫자는 이것이다. Claude를 활용한 업무의 **27%는 “기존에는 하지 않았을 일”**이었다.

이 숫자의 함의를 곱씹어 보자. AI 도입의 가치를 보통 “효율화” — 기존 업무를 더 빠르게 — 로 측정한다. 하지만 진정한 AI Native의 가치는 효율화가 아니라 가능성의 확장에 있다. 이전에는 시간이 없어서, 인력이 없어서, 전문성이 없어서 하지 못했던 일을 이제 할 수 있게 되는 것.

구체적으로 무슨 일이 벌어졌는가? 백엔드 개발자가 UI를 직접 구축하기 시작했다. 연구원이 데이터 시각화를 직접 만들었다. 한 엔지니어는 자기 전문 분야 밖의 코드베이스를 Claude와 함께 탐색하며, 이전 같으면 다른 팀에 요청했을 작업을 혼자 완료했다. 개인의 역할 범위가 AI에 의해 확장되고 있었다.

Anthropic은 이 현상을 **“풀스택화(full-stack化)“**라고 불렀다. 전문 영역의 경계가 AI에 의해 녹아내리는 것이다. 프론트엔드 개발자가 백엔드를, 백엔드 개발자가 인프라를, 디자이너가 프로토타입 코딩을 — 각자의 전문성에 AI가 겹쳐지면서, 한 사람이 커버할 수 있는 범위가 비약적으로 넓어졌다.

이것은 “같은 일을 더 빨리 하는 것”과 질적으로 다르다. **“하지 못했던 일을 하는 것”**이다. 그리고 이것이 AI Native 조직의 진짜 경쟁력이다.

4. 세 가지 AI Native 워크플로우 패턴

리서치를 종합하면, AI Native 조직이 채택하고 있는 워크플로우 패턴이 크게 세 가지로 수렴한다.

패턴 1: 역설계형 — “가치에서 역산하여 프로세스를 새로 설계한다”

메르카리의 접근이 대표적이다. 2025년 5월, CEO 야마다 신타로는 전사에 선언했다. “AI를 도입하는 회사가 아니라, AI를 전제로 재설계된 회사가 되겠다.” 단순한 슬로건이 아니었다. 100명 규모의 AI 태스크포스가 발족하고, 전사를 33개 도메인으로 나누어 약 4,000개의 워크플로우를 처음부터 다시 정의하기 시작했다.

핵심 발상의 전환은 이것이다. 기존 조직은 **“인간의 한계”**를 전제로 설계되어 있다. 인간의 집중력은 유한하고, 동시에 처리할 수 있는 정보량에 한계가 있고, 하루에 일할 수 있는 시간이 정해져 있다. 모든 프로세스, 회의 구조, 보고 체계가 이 전제 위에 서 있다.

AI Native 조직은 이 전제를 뒤집는다. “달성하고 싶은 가치”에서 역산하여 프로세스를 설계한다. “이 기능을 사용자에게 전달하려면 어떤 프로세스가 최적인가?”를 묻되, “인간만으로 해야 한다”는 제약을 빼고 묻는 것이다.

메르카리는 이를 **ASDD(Agent-Spec Driven Development)**라는 프레임워크로 구체화했다. 누가, 어떤 태스크를, 어떤 파일에서, 어떤 코드 스타일로 구현하는가를 명확히 정의하는 실장 지향 상세 사양 포맷이다. 이 사양서는 인간도 읽을 수 있지만, AI 에이전트가 바로 실행할 수 있도록 설계되어 있다. 기획 → 사양 작성 → AI 에이전트 실행 → 인간 검증. 전통적인 기획 → 설계 → 코딩 → 테스트 → 리뷰와는 근본적으로 다른 흐름이다.

2025년 8월 기준으로 메르카리의 AI 도구 활용률은 95%, 코드의 70%를 AI가 생성했다. 엔지니어 1인당 개발량은 전년 대비 64% 증가했다. 그런데 CTO 키무라는 이렇게 말했다. “아직 갈 길의 절반이다. 코딩 이외의 업무 프로세스 개혁이 늦어지고 있다.”

이 한마디가 AI Native의 본질을 꿰뚫는다. 코드 생성은 전체 업무의 일부일 뿐이다. 기획, 의사결정, 커뮤니케이션, QA — 이 모든 것이 AI를 전제로 재설계되어야 비로소 AI Native다.

패턴 2: 풀스택형 — “역할의 경계를 녹여 개인의 영역을 확장한다”

Anthropic 내부에서 관찰된 패턴이다. 앞서 언급한 “풀스택화”가 여기에 해당한다.

전통적 소프트웨어 조직은 역할을 분리한다. 프론트엔드, 백엔드, 인프라, QA, 디자인 — 각자의 전문 영역이 명확하고, 경계를 넘는 것은 비효율로 간주된다. 이 분리는 “한 사람이 모든 것을 잘할 수는 없다”는 전제 위에 서 있다.

AI는 이 전제를 흔든다. Claude와 함께라면, 백엔드 개발자가 React 컴포넌트를 만들 수 있다. 완벽하지는 않지만, 다른 팀에 요청하고 2주를 기다리는 것보다 낫다. 디자이너가 프로토타입을 코드로 구현할 수 있다. 시니어 엔지니어에게 물어봐야 했던 아키텍처 질문을 Claude에게 먼저 물어볼 수 있다.

Anthropic의 조사에서 직원들은 업무의 60%에서 Claude를 활용하고 있었고, 50%의 생산성 향상을 보고했다. 하지만 더 중요한 변화는 숫자에 잡히지 않는 곳에서 일어나고 있었다. “동료에게 물어보던 질문의 첫 번째 대상이 Claude로 바뀌었다.” 그리고 이것은 양날의 검이었다. 한 시니어 엔지니어는 이렇게 말했다. “후배들이 더 이상 질문을 많이 하지 않는다. 안타깝다.”

풀스택형 패턴의 핵심은 조직의 단위가 “역할별 팀”에서 **“AI 증강된 개인”**으로 이동한다는 것이다. 5명이 각자의 전문성으로 협업하던 일을, AI 도구를 갖춘 2명이 해낼 수 있다면, 조직 구조 자체가 바뀌어야 한다. 이것이 “도구를 바꾸는 것”을 넘어 “일하는 방식을 바꾸는 것”이다.

패턴 3: 에이전트 오케스트레이션형 — “인간이 설계하고, AI 에이전트 팀이 실행한다”

Deloitte가 2026년 Tech Trends 보고서에서 제시한 미래상이다. 기술 리더의 78%가 향후 5년 내 워크플로우에 AI 에이전트를 통합할 계획이라고 응답했다. 그리고 이미 2/3 이상의 조직이 AI 에이전트 배포를 진행 중이다.

이 패턴에서 인간의 역할은 **오케스트레이터(orchestrator)**다. 전체 프로세스를 설계하고, AI 에이전트들에게 각각의 태스크를 할당하고, 결과를 검증하고, 예외 상황을 처리한다. 코드를 직접 작성하는 사람에서, 코드를 작성하는 에이전트를 관리하는 사람으로. Anthropic의 표현을 빌리면, 70% 이상의 엔지니어가 이미 코드 작성자에서 검수자 역할로 이동하고 있다.

Sapphire Ventures는 이 전환의 비즈니스 모델적 함의도 짚었다. AI Native 시대에는 가격 모델이 “좌석 기반(per-seat)“에서 **“성과 기반(outcome-based)“**으로 바뀐다. 사람 수가 아니라 결과물로 가격을 매기는 것이다. 에이전트가 실행하는 세계에서, “사람 몇 명이 투입됐는가”는 의미 없는 질문이 된다.

5. 선행 조건 — Knowledge Management가 먼저다

세 가지 패턴 모두에 공통되는 선행 조건이 하나 있다. 지식의 구조화다.

메르카리의 CTO가 가장 강조한 것이 이것이었다. “AI 에이전트의 성능은 제공되는 컨텍스트의 질에 비례한다.” 아무리 강력한 모델도, 조직의 맥락 — 코딩 규약, 설계 결정의 이유, 과거 장애 기록, 비즈니스 로직의 배경 — 을 모르면 쓸모 있는 결과를 낼 수 없다.

메르카리는 Notion을 “Central Knowledge Base”로 지정하고, 분산되어 있던 정보를 일원화하는 작업부터 시작했다. 회의록 자동 생성, 의사결정 로그 구조화, 코드 리뷰 논의 아카이빙 — AI가 이해할 수 있는 형태로 조직의 지식을 정리하는 것이 AI Native 전환의 첫 번째 단계였다.

이것은 많은 조직이 간과하는 부분이다. AI 도구를 도입하면서 “어떤 모델을 쓸까”, “어떤 IDE 플러그인을 설치할까”를 먼저 고민하지만, 정작 AI에게 먹일 컨텍스트가 준비되어 있는지는 묻지 않는다. 조직의 지식이 슬랙 메시지와 개인 노션과 누군가의 머릿속에 흩어져 있다면, 세계 최고의 AI 모델도 무용지물이다.

AI Native의 첫 단계는 AI 도구 도입이 아니다. 조직의 지식을 AI가 소비할 수 있는 형태로 구조화하는 것이다.

6. 반론 — “일하는 방식을 바꾸기 전에 바꿔야 할 것이 있다”

여기서 불편한 질문을 피할 수 없다.

”사람이 안 바뀌는데 프로세스를 바꿔봐야 소용없지 않나?”

맞는 말이다. AI Native 전환의 가장 큰 장벽은 기술이 아니라 사람이다. Anthropic 내부 조사에서도 엔지니어들의 양가감정이 드러났다. “단기적으로는 낙관적이다. AI가 생산성을 높여주니까. 하지만 장기적으로? AI가 모든 것을 대체하면 나는 무의미해지는 것 아닌가?”

이 불안감은 합리적이다. 그리고 불안한 사람에게 “프로세스를 바꿔라”고 요구하는 것은 저항을 낳는다. “AI를 전제로 재설계하자”는 말이 “당신의 역할이 사라질 수 있다”로 들리기 때문이다.

기술 심화의 퇴화 문제

Anthropic의 엔지니어 중 일부는 이런 우려를 표명했다. “산출이 쉬워지니 시간을 들여 학습하기 어려워진다.” AI가 코드를 생성해주면, 그 코드가 왜 그렇게 작동하는지 깊이 이해할 동기가 줄어든다. 결국 AI의 출력을 검증할 능력 자체가 약화될 수 있다. 검증자가 검증 능력을 잃으면, 시스템 전체가 무너진다.

Ptacek — 보안 업계의 전설이자 AI의 열렬한 옹호자 — 도 비슷한 고백을 했다. “테이블 테스트 작성법을 잊어버렸다. AI가 다 생성해주니까. 그리고 이건 무섭다.” AI Native를 추구하면서 동시에 인간의 핵심 역량을 보존하는 것. 이것은 아직 아무도 해결하지 못한 과제다.

멘토십의 소멸

풀스택화의 이면에는 협업과 멘토십의 축소가 있다. 질문의 첫 번째 대상이 동료에서 AI로 바뀌면, 시니어와 주니어 사이의 지식 전달 통로가 막힌다. 주니어 개발자가 AI에 의존해 학습 과정을 건너뛰면, 시니어가 될 수 없다. 주니어를 키우지 않으면, 결국 시니어도 소멸한다. AI Native 조직은 이 파이프라인 문제에 대한 답을 가지고 있어야 한다.

이 반론들은 유효하다. AI Native 전환이 기술적 프로세스 재설계만으로 완성되지 않는 이유다. 조직 문화, 심리적 안전, 학습 체계 — 이것들이 함께 전환되지 않으면, 아무리 세련된 AI 워크플로우도 지속 불가능하다.

7. AI Native는 기술 전환이 아니라 조직 문화 전환이다

돌아보면, “AI Native”라는 단어는 2026년 현재 유행어처럼 번지고 있지만, 아직 합의된 정의는 없다. IBM은 아키텍처를 강조하고, Sapphire Ventures는 비즈니스 모델을 강조하고, Deloitte는 거버넌스를 강조하고, 메르카리는 프로세스 재설계를 강조하고, Anthropic은 역할의 변화를 강조한다. World Economic Forum은 이렇게 요약했다. “2025년이 AI로 구축하는 법을 배운 해였다면, 2026년은 AI Native 조직으로 운영하는 법을 배우는 해다.”

정의가 다양하다는 것은, 이 개념이 아직 형성 중이라는 뜻이다. 그리고 그것은 기회다. 남의 정의를 빌려 쓰는 것이 아니라, 우리 조직만의 AI Native를 정의할 수 있다는 뜻이기 때문이다.

내가 이 글을 쓰면서 내린 잠정적 결론은 이것이다.

AI Native의 핵심은 세 가지 질문에 있다.

첫째, “이 프로세스는 AI 없이도 존재했을까?” 기존 프로세스에 AI를 얹은 것이라면, 그것은 AI Enabled다. AI를 전제로 처음부터 설계된 프로세스만이 AI Native다.

둘째, “이전에는 불가능했던 일을 하고 있는가?” 같은 일을 더 빠르게 하는 것은 효율화다. 이전에는 하지 못했던 일을 하는 것이 AI Native의 진짜 가치다. Anthropic의 27%가 보여주듯, AI Native 조직의 차별적 경쟁력은 가능성의 확장에 있다.

셋째, “사람의 역할은 어떻게 재정의되었는가?” 도구가 바뀌었는데 역할이 그대로라면, 아직 AI Native가 아니다. 코드 작성자에서 검수자로, 실행자에서 오케스트레이터로, 전문가에서 풀스택 인재로 — 역할의 전환이 일어나야 한다. 그리고 이 전환을 지탱하는 조직 문화와 학습 체계가 갖춰져야 한다.

결국 AI Native는 기술의 문제가 아니라 문화의 문제다. 어떤 AI 도구를 쓰느냐보다, “AI가 있는 세계에서 우리는 어떻게 일할 것인가”를 묻는 것이 더 중요하다. 그리고 그 질문에 대한 답은, 아직 아무도 완성하지 못했다. 메르카리도 “절반”이라 했고, Anthropic도 “탐색 중”이라 했다.

완성된 답이 없다는 것은 불안한 일이지만, 동시에 가장 정직한 출발점이기도 하다. AI Native 조직이 되는 것은 어떤 도구를 도입하는 것이 아니라, “우리는 왜, 어떻게 일하는가”를 처음부터 다시 묻는 것이다. 그 질문 앞에서 겸허해지는 것이, AI Native의 첫 번째 단계일 수 있다.

참고 자료