‘AI 도입’이라는 말은 이미 낡았다. 2026년 국내 IT·커머스 기업의 화법은 ‘AI 네이티브(AI Native)’ 혹은 ‘AX(AI Transformation)’로 넘어갔다. 리디는 개발 직군을 넘어 기획·운영 같은 비개발 직군까지 AI로 업무를 자동화하는 전사 확산을 내걸었고, 무신사는 AI 도입으로 개발 생산성이 75% 올랐다고 밝혔다. 네이버·카카오는 챗GPT와 클로드(Claude)를 함께 쓰는 ‘멀티 AI’로 방향을 잡았다. 클로드를 만든 앤트로픽(Anthropic)은 아예 AI를 슬랙(Slack) 채널에 태그해 부르는 ‘상주 팀원’ 방식을 공개했다. 문제는 이 헤드라인들을 그대로 벤치마킹하면 대부분 실패한다는 점이다. 같은 도구를 깔아도 성과가 갈리는 이유는 모델이 아니라 ‘도입의 순서와 전제’에 있다. 이 글은 홍보성 수치를 나열하는 대신, 각 사례에서 ‘어떤 조건일 때 성과가 되고 어디서 무너지는가’를 판단 기준으로 재구성한다.
‘도입’과 ‘네이티브’는 다른 단어다 — 3단계로 내 조직을 진단하기
‘우리도 AI 쓴다’는 말은 최소 세 단계를 뭉뚱그린다. (1단계) 직원 개인이 알아서 챗GPT를 켜는 개별 사용, (2단계) 특정 부서에 도구를 깔아주는 부분 도입, (3단계) 업무 프로세스와 데이터·권한 체계 자체를 AI 전제로 재설계하는 AI 네이티브/AX다. 리디가 ‘비개발자까지’를 강조하고 무신사가 ‘전사’라는 단어를 붙인 것은 개인기 수준(1단계)이 아니라 조직 워크플로(3단계)를 겨냥한다는 신호다. 그래서 진짜 지표는 ‘몇 명이 쓰느냐’가 아니라 ‘반복 업무의 몇 %가 개인 재량이 아닌 표준 워크플로에 편입됐느냐’다. 사용률 90%인데도 각자 다른 프롬프트로 제각각 결과를 내고 있다면 그 조직은 여전히 1단계다.
여기서 가장 흔한 오해가 ‘도구를 깔면 생산성이 오른다’는 가정이다. 실제는 정반대에 가깝다. 업무가 문서화·표준화되지 않은 조직에 AI를 얹으면 사람마다 입력이 달라 결과 품질의 편차만 커지고, 그 편차를 다시 사람이 손보느라 순이득이 사라진다. AX의 첫 단추가 모델 선정이 아니라 ‘자동화 후보 업무를 빈도×소요시간으로 줄 세우는 일’인 이유다. 실전 기준선을 하나 제시하면, 주 5회 이상 반복되고 회당 30분 이상 걸리며 판단보다 규칙이 지배하는 정형 업무(리포트 요약, 문의 1차 분류, 회의록 정리, 코드 리뷰 초안)가 1순위다. 반대로 예외 처리가 많고 맥락 판단이 개입하는 업무를 첫 대상으로 삼으면, 검수 부담이 자동화 이득을 잡아먹는다.
‘개발 생산성 75%’를 읽는 법 — 숫자가 아니라 정의를 물어라
무신사의 ‘개발 생산성 75% 향상’은 강한 헤드라인이지만, 실무자라면 ‘무엇의 75%인가’부터 되물어야 한다. 개발 생산성 지표는 보통 코드 작성 속도, 특정 태스크 완료 시간, 배포 빈도, 버그 수정 리드타임 중 하나에 근거한다. 같은 75%라도 ‘보일러플레이트 초안 작성 시간이 75% 줄었다’와 ‘개발 조직 전체 산출량이 75% 늘었다’는 전혀 다른 문장이다. 사내 발표 수치는 대개 전자, 즉 특정 반복 구간의 국소 개선치다. 이걸 조직 성과로 확대 해석하면 도입 뒤 ‘기대만큼 안 나온다’는 실망으로 되돌아온다. 참고할 이론적 상한이 하나 있다 — 아무리 빠른 도구도 전체 개발 시간에서 ‘코딩’이 차지하는 비중(설계·리뷰·회의·대기를 빼면 흔히 절반 이하)까지만 단축한다. 코딩 구간을 100% 없애도 전체 리드타임은 그 비중만큼만 줄어든다.
실무 체크포인트는 셋이다. 첫째, 개선치를 ‘코드가 나온 속도’가 아니라 ‘리뷰·수정·재작업을 포함한 최종 머지까지의 시간’으로 재라. 초안이 3배 빨라도 검증에 시간이 들면 순이득은 작다. 둘째, 시니어와 주니어의 효과는 반대로 나타날 수 있다. 옳고 그름을 판별하는 시니어는 가속되지만, 결과 검증이 어려운 주니어는 그럴듯한 오류 코드를 그대로 통과시켜 오히려 결함률을 높이기도 한다. 따라서 ‘전사 평균 생산성’이라는 지표는 이 편차를 가린다. 셋째, 생성 코드의 청구서는 6개월 뒤에 온다. 지금의 속도 이득이 아무도 완전히 이해하지 못하는 코드, 즉 기술 부채로 이전되지 않는지 테스트 커버리지와 코드 소유권(누가 이 코드를 책임지고 고치는가) 규칙을 함께 봐야 한다. 속도만 재고 부채를 안 재면 이듬해 유지보수 인력으로 그 이득을 반납한다.
왜 한 모델에 올인하지 않는가 — 멀티 AI의 진짜 이유와 청구서
네이버·카카오가 챗GPT와 클로드를 병행하는 건 취향의 저울질이 아니라 종속(lock-in) 회피에 가깝다. 벤더 하나에 워크플로를 묶으면 가격 인상, 정책 변경, 특정 지역 서비스 중단, 모델 성능 후퇴가 그대로 사업 리스크가 된다. 대안이 곧 협상력이다. 여기에 모델마다 강점이 갈리는 실무적 이유가 더해진다 — 통상 장문 문서 이해·긴 맥락 유지에 강한 모델과, 범용 대화·플러그인 생태계에 익숙한 모델이 다르다. 그래서 성숙한 조직은 업무 유형별로 모델을 배분하고, 그 위에 ‘어떤 데이터를 어느 모델로 보내도 되는가’를 정하는 라우팅·거버넌스 계층을 둔다. 모델을 늘리는 것과 규칙을 늘리는 것은 세트다.
다만 멀티 AI의 청구서를 과소평가하면 안 된다. 관리 복잡도가 곱으로 는다. 모델이 둘이면 프롬프트 표준, 출력 품질 기준, 로그·감사 체계를 이중으로 운영해야 하고, API 비용은 사용량에 선형으로 붙는 게 아니라 긴 맥락을 반복 주입하는 습관 하나로 몇 배씩 튄다. 그래서 도입 초기 정답은 대체로 ‘한 모델로 워크플로를 먼저 정착시킨 뒤 확장’이다. 순서가 핵심이다 — ①월별·부서별 토큰 사용 상한과 비용 배분 규칙, ②민감정보(개인정보·미공개 재무·핵심 소스코드) 전송 금지 목록, ③출력 로그 보관·감사 기준을 정책으로 못 박고 나서 모델을 늘려라. 도구를 먼저 늘리고 규칙을 나중에 붙이는 순서는 거의 예외 없이 비용 초과나 정보 유출로 되돌아온다.
AI가 ‘상주 팀원’이 될 때 — 검증·책임·역량의 재설계
앤트로픽이 슬랙 채널에서 클로드를 태그해 부르는 기능을 공개하고 이를 전담 운영하는 인력을 따로 둔다는 흐름은, AI의 위치가 ‘내가 켜는 도구’에서 ‘채널에 상주하는 참여자’로 옮겨가고 있음을 보여준다. 위치가 바뀌면 쟁점도 기능에서 규칙으로 바뀐다. 상주 AI에게는 최소 세 질문의 답이 미리 있어야 한다. AI가 채널에서 낸 답의 사실 여부는 누가 검증하는가, 그 답으로 의사결정이 틀어지면 책임은 누구에게 있는가, 오간 사내 정보는 어디까지 저장·학습되는가. 이 답이 비면 ‘공개된 팀원’은 곧 ‘책임 소재가 없는 리스크’가 된다. 특히 채널 대화는 근거 없이도 자연스럽게 읽히기 때문에, 자동화된 오답이 조용히 합의처럼 굳는 위험이 개인 사용보다 크다.
일자리 논의의 결도 여기서 바뀐다. ‘AI가 일자리를 없앤다’는 단순 구도 대신, AI를 관리·검증·운영하는 직무(워크플로 설계, 출력 품질 검수, AI 거버넌스)가 새로 생기고 있다. 위협의 본질은 직업의 소멸이 아니라 역량의 이동이다. 초보자가 가장 오해하는 지점이 바로 여기다 — ‘AI를 잘 쓴다’는 건 프롬프트를 화려하게 쓰는 기술이 아니라, 결과의 오류를 잡아내고 ‘언제 사람이 개입해야 하는지’를 판단하는 능력이다. 6개월~2년 관점에서 개인이 준비할 것은 셋이다. ①내 업무를 ‘검증 가능한 정형 작업’과 ‘판단이 필요한 비정형 작업’으로 나눠 두기, ②AI 출력의 근거를 되짚어 확인하는 습관 들이기, ③데이터 보안·저작권·책임 규칙을 이해하는 최소한의 리터러시 갖추기. 기술의 좋고 나쁨을 논하기 전에, 조직이든 개인이든 이 전제가 갖춰졌는지가 성과의 실제 분기점이다.
자주 묻는 질문
AI 도입하면 정말 개발 생산성이 75% 오르나요?
특정 반복 작업 구간의 국소 개선치일 가능성이 큽니다. ‘보일러플레이트 초안 작성 시간 75% 단축’과 ‘조직 전체 산출량 75% 증가’는 전혀 다른 문장입니다. 게다가 전체 리드타임에서 코딩이 차지하는 비중(설계·리뷰·회의를 빼면 흔히 절반 이하)까지만 단축되므로, 코딩 구간을 아무리 줄여도 전체 시간은 그 비중만큼만 줄어듭니다. 판단하려면 코드가 나온 속도가 아니라 리뷰·수정·재작업을 포함한 최종 머지까지의 시간으로 재보세요.
챗GPT 하나만 써도 되는데 왜 멀티 AI 전략을 쓰나요?
핵심은 벤더 종속 회피입니다. 한 모델에 워크플로를 묶으면 가격 인상·정책 변경·서비스 중단이 그대로 사업 리스크가 되고, 대안 모델이 있어야 협상력이 생깁니다. 여기에 장문 이해, 범용 대화 등 모델별 강점 차이가 더해집니다. 다만 관리 복잡도와 비용이 곱으로 늘기 때문에, 초기에는 한 모델로 워크플로를 정착시킨 뒤 확장하는 편이 안전합니다.
비개발자도 AI로 업무 자동화가 가능한가요?
가능하지만 전제가 있습니다. 자동화할 반복 업무가 문서화·표준화돼 있어야 결과 품질 편차가 줄어듭니다. 주 5회 이상, 회당 30분 이상 걸리고 판단보다 규칙이 지배하는 정형 업무(리포트 요약, 문의 1차 분류, 회의록 정리)부터 시작하는 것이 효과가 큽니다. 반대로 예외 처리와 맥락 판단이 많은 업무를 첫 대상으로 삼으면 검수 부담이 이득을 잡아먹습니다.
AI가 슬랙 팀원처럼 쓰이면 잘못된 답의 책임은 누가 지나요?
최종 검증과 의사결정 책임은 사람에게 남습니다. 그래서 AI를 채널에 상주시키기 전에 ‘출력 사실 검증 담당, 오류 시 책임 소재, 사내 정보 저장·학습 범위’ 세 가지를 규칙으로 먼저 정해야 합니다. 채널 대화는 근거 없이도 자연스럽게 읽혀 오답이 조용히 합의처럼 굳기 쉽기 때문에, 개인 사용보다 검증 규칙이 더 중요합니다.
AI 때문에 개발자 일자리가 사라지나요?
‘소멸’보다 ‘역량 이동’에 가깝습니다. AI를 관리·검증·운영하는 직무(워크플로 설계, 출력 품질 검수, 거버넌스)가 새로 생기고 있습니다. 특히 결과의 옳고 그름을 판별하기 어려운 주니어는 오류 코드를 통과시킬 위험이 커서 대비가 필요합니다. 프롬프트를 화려하게 쓰는 기술보다, AI 오류를 잡아내고 사람이 개입할 시점을 판단하는 역량을 키우는 것이 핵심입니다.