대기업 내부에서 나온 AI 네이티브 실천 회피 가이드

이것은 창허(苍何)의 601번째 오리지널 글입니다!

안녕하세요, 창허입니다.

저는 대략 수백 개의 AI 그룹에 잠복해 있으면서, 그룹 핫이슈 모니터링 도구를 하나 만들었습니다.

최근 들어 적지 않은 커뮤니티에서 대기업 내부에서 흘러나온 《AI 네이티브 실천 함정 회피 가이드》 한 부가 미친 듯이 퍼지고 있는 것을 발견했습니다.

여러분도 각자의 커뮤니티에서 한 번쯤 봤을 거라 믿습니다. 아니면 못 봤을 수도 있고요.

하지만 그건 중요하지 않습니다. 중요한 건 제가 읽고 나서 꽤 감회가 깊어서, 따로 글 한 편을 써서 공유 겸 정리해보고 싶다는 것입니다.

이 가이드는 360 직원 한 명이 30여 개의 AI Native 실천 사례를 바탕으로 정리한 것으로, 연구개발, 보안, IoT, 법무, 마케팅 등의 업무를 아우릅니다.

완전한 가이드는 제가 GitHub에도 하나 복사해 두었으니, 직접 확인하시면 됩니다: github.com/freestylefl…

이 가이드는 모두 7개의 함정을 정리하고 있습니다.

제가 보기에는 하나의 흐름이 특히 선명합니다. 처음에는 우리가 AI가 자기 일을 하도록 어떻게 도울지에 관심을 가집니다. 많이 쓰다 보면, 그것이 만들어낸 결과물이 납품 가능한지에 관심을 갖기 시작합니다. 더 나아가면 문제는 이렇게 됩니다. 이미 돌려본 방법을 동료들도 쓸 수 있게 할 수 있을까?

저는 이 흐름을 따라, 제가 가장 감회가 깊었던 몇 가지 지점을 이야기해보려 합니다.

먼저 첫 번째 큰 함정입니다. 적지 않은 기업의 AI 전환이 시작하자마자 크게 한 방 벌이려 합니다. 저는 직접 목격한 적이 있는데, '우리는 모든 업무를 연결하고 폐쇄 루프를 형성하는 전능한 에이전트를 만들겠다'고 하더군요....

심지어 사장이 직접 킥오프 회의를 열어, 반드시 승리를 거두겠다고 했습니다.

결과적으로 업무가 연결됐는지 아닌지는 모르겠지만, 최종 결과는 모두가 AI에 대한 신뢰를 잃게 된 것이었습니다. 사장 자신도 포함해서요.

크고 완전한 것을 탐하는 것은 AI 전환의 첫 번째 킬러입니다. 모든 것을 다 하려는 것은 모든 것을 다 못 해내는 것과 같습니다.

가이드에서 말하는 '작게 빠르게 달리기(小步快跑)' 방식도 저는 비교적 동의합니다. 업무가 AI 도입을 이끌도록 하고, '통점(痛), 작음(小), 빠름(快)'이라는 기준으로 진입점을 잡아 결과를 빠르게 보는 것입니다.

하지만 또 다른 상황도 있습니다. 시나리오를 아주 작게 골랐고, AI도 빠르게 결과를 내놨는데, 막상 납품할 때 사람은 더 지치게 되는 경우입니다.

코드는 몇 분 만에 다 썼는데, 검사와 디버깅에 반나절이 걸렸습니다. 보고서는 단숨에 수십 페이지를 생성했지만, 그 안의 데이터를 한 줄 한 줄 대조해야 했습니다.

생성은 빠른데, 검수는 따라가지 못합니다.

이것이 바로 가이드에서 말하는 '원클릭 생성 함정'입니다. 저는 이 부분이 더 이야기할 가치가 있다고 봅니다.

가이드에서는 360 안전금고(Safe Box) 개발 시, 독립된 하위 에이전트가 코드를 심사하고 문제를 발견하면 되돌려 수정하게 하며, 재심사를 통과한 뒤에야 제출 단계로 넘어가고, 사람은 핵심 노드에서 판단과 검수를 한다고 언급합니다.

이 방식은 참고할 만합니다. AI가 생성 이후의 검사와 수정까지 이어받게 하는 것입니다. 결국 시간이 절약됐는지는 뒤의 검수와 재작업까지 함께 계산해야 합니다.

그런데 한 사람이 돌려냈다 해도, 다음 문제가 찾아옵니다. 이 방법을 동료가 바로 쓸 수 있을까?

여기서 가이드의 '고립된 섬 함정(孤岛坑)'으로 넘어갑니다.

가이드에서는 10명짜리 AI 제품 팀이 있었는데, 각자 AI로 코드를 작성했고 개별적으로 보면 다들 빠른 편이었지만, 합치니 문제가 생겼다고 언급합니다. 명명이 통일되지 않고, 인터페이스가 맞지 않으며, 같은 기능이 중복 구현되기도 했습니다.

그 후 그들은 규범, 문서, Skill을 같은 Git 저장소에 넣고, 작업 시작 전에 같은 규칙 세트를 먼저 읽게 했습니다. 그리고 각자 만들어둔 에이전트를 나노 Work(纳米 Work)에 올려 팀 구성원들이 서로 호출할 수 있게 했습니다.

예를 들어 디자이너가 없어도 제품 담당자가 디자이너가 축적해둔 Skill을 호출해 규범에 맞는 페이지를 생성할 수 있습니다.

비슷한 방식이 가이드에 더 있습니다. 법무는 지식베이스와 심사 규칙을 나노 Work에 접속시켰고, 돌려본 심사 프로세스를 다시 Skill로 축적했습니다. IoT 팀은 로그 점검 경험을 디지털 직원으로 만들어, 동료가 문제를 겪으면 바로 @로 호출할 수 있게 했습니다.

한 사람이 시행착오로 터득한 방법이, 마침내 다른 사람이 같은 우회로를 덜 겪게 해줍니다.

저는 이것이 팀이 AI를 쓰는 데서 특히 주목할 만한 점이라고 생각합니다. 누가 더 빠른지를 보는 것 외에도, 그가 남긴 경험을 다음 사람이 쓸 수 있는지도 봐야 합니다.

조직 차원의 지식 공유 체계를 구축하는 것이 특히 중요해집니다. 지식을 Markdown으로 축적한 뒤, 흐르고 공유되게 하는 것입니다.

각자가 AI로 아낀 시간이 인수인계와 협업에서도 아껴져야 팀이 진짜로 효율을 높였다고 할 수 있습니다. Spec-First가 모두가 요구사항을 먼저 명확히 하도록 돕고, 돌려본 경험을 공유 저장소에 넣은 뒤 다시 Skill로 정리해 다음 사람이 이어서 쓰게 합니다.

여기까지 쓰니, 사실 이미 보입니다. AI를 쓸 줄 아는 직원 몇 명만으로는 이런 일들을 전부 밀어붙이기 어렵습니다.

누가 표준을 통일할 것인가? 누가 모두에게 시행착오할 시간을 확보해줄 것인가? 한 사람이 시간을 들여 팀 모두가 쓸 수 있는 Skill을 정리한 이 기여는 성과로 인정되는가?

이것들은 모두 관리자의 참여가 필요합니다.

그래서 가이드에 있는 한 문장에 저는 꽤 동의합니다. 관리자가 AI 네이티브 전환의 제1 책임자여야 한다는 것입니다.

자기가 먼저 업무 흐름 하나를 돌려봐야, 팀이 어디에서 막히는지 알 수 있고, 어떤 경험이 남길 가치가 있는지도 알 수 있습니다.

이 점에서 라오저우(老周)가 제게 깊은 인상을 남겼습니다. 예전에 WAIC에서 그를 모시고 전시장을 돌았는데, 그 자신이 이 AI 제품들이 대체 무엇을 할 수 있고 어디에 쓸 수 있는지 몹시 알고 싶어 한다는 것을 느낄 수 있었습니다.

360에 있는 친구가 말해주기를, 작년 8월 회사가 전사 올인 에이전트(All in Agent)를 선언하고 전 직원에게 토큰을 지급한 뒤, 각 주요 사업 라인에 사례를 돌려보게 했다고 합니다.

저는 오히려 이 직원들이 지금 무엇을 논의하는지 보면 어떤 변화가 있는지 알 수 있다고 봅니다.

AI가 쓴 코드를 누가 심사하는가, 내가 조정해둔 Skill을 동료가 어떻게 쓰는가, 디자이너가 없을 때 작업을 어떻게 이어가는가. 이런 문제들을 이야기할 수 있다는 것은, 적어도 이 팀들에서는 AI가 이미 꽤 깊이 쓰이고 있다는 뜻입니다.

쓰다 보면, 업무 하나를 받았을 때 자연스럽게 어느 단계를 AI에 맡길 수 있을지 먼저 생각하게 됩니다. 이런 습관이야말로 AI Native의 비교적 구체적인 모습이라고 생각합니다.

라오저우가 말한 'AI로 다시 창업하기'는, 앞의 사례들이 어느 정도 이 말을 이해하는 데 도움을 줍니다. 회사의 기존 업무는 여전히 있지만, 이런 일을 하는 방식, 즉 사람이 어떻게 분업하는가까지 다시 고민해야 합니다.

나노 Work도 이런 배경 속에서 봐야 재미있습니다. 이 기업용 에이전트 오피스 플랫폼은 360이 내부에서 돌려본 방법을 조금씩 제품에 담아낸 결과입니다.

위챗, 페이슈(飞书), 딩딩(钉钉)을 연동할 수 있고, 웹에서 바로 쓸 수 있으며, 클라우드 작업은 컴퓨터를 꺼도 멈추지 않습니다. 이미 고정된 업무 습관이 있는 팀에게는 익숙한 도구를 그대로 쓸 수 있고 로컬 배포로 덜 헤매야 모두가 더 쉽게 쓰기 시작합니다.

또한 가이드에서 언급한 '나체로 뛰기 함정(裸奔坑)'도 해결해야 합니다. 에이전트는 파일을 읽고, 소프트웨어를 설치하고, 데이터를 수정하므로, 기업은 그 권한을 관리할 수 있어야 하고 그것이 무엇을 했는지도 조회할 수 있어야 합니다. 360이 제공한 IDC 평가 자료에 따르면, 나노 Work는 12개 평가 제품 중 '보안 통제 가능' 차원에서 유일한 Top 등급을 받았고, 멀티 에이전트 오케스트레이션, 생태계와 개방성 두 항목도 만점이었습니다.

자사 연구개발, 법무, 마케팅이 먼저 쓰기 시작하면, 제품은 한 무더기의 구체적인 요구사항을 마주하게 됩니다. 한 사람의 에이전트는 쓸 만한데, 팀 전체에 쓸 수 있게 할 수 있는가? 규칙이 바뀌면 모두가 쓰는 버전도 따라서 업데이트될 수 있는가? 이런 문제들은 실제 업무에서 피할 수 없습니다.

360 내부의 사용법도 꽤 직접적입니다. 바로 전 직원이 먼저 자기네 '개밥(도그푸딩)'을 먹는 것입니다. 360이 제공한 데이터에 따르면, 올해 5월 회사는 직원 한 명당 1억 토큰을 지급했고, 신청과 승인 없이 먼저 업무에 시험해보게 했습니다.

7월 나노 Work 출시에 이르러 360은 10만 개가 넘는 에이전트가 실제 업무에 투입되었고, 150일 동안 630개 직무를 커버했으며, 350조 토큰을 소비했고, 5.6만 건의 피드백을 수집했으며, 166개 버전을 반복했다고 공개했습니다.

이 규모의 에이전트를 연구개발, 법무, 보안, IoT, 마케팅에 넣을 배짱은 정말 크다고 할 만합니다. 배경에는 보안을 해온 축적도 있습니다. 클라우드 격리, 권한 통제 같은 것들이 먼저 따라와야 합니다. 참여하는 업무가 많을수록 문제는 더 빨리 드러나고, 제품은 실제 업무 속에서 고칠 기회를 더 많이 얻습니다.

이 숫자들 중에서 저는 그 5.6만 건의 피드백을 한 번 더 눈여겨봅니다. 회사 전체가 매일 쓰고 있으니, 어디가 쓰기 불편한지, 동료가 내일 또 찾아올 테니, 시연을 아무리 예쁘게 해도 소용없습니다.

쉽게 말해, 먼저 자기 회사 동료들이 순조롭게 쓰게 한 다음에, 남에게 내놓는 것입니다. 기업 AI 제품을 만들 때 이 순서가 꽤 중요하다고 생각합니다.

360은 자신을 '국내 최초로 AI Native 전환을 체계적으로 추진하는 회사'로 규정합니다. 이런 실천들을 보고 나서 다시 그것이 말하는 'AI로 다시 창업하기'를 보면, 무엇을 강조하려는지 이해됩니다. 사장이 직접 뛰어들고, 직원이 업무 속에서 반복적으로 시험하고, 돌려본 방법을 나노 Work에 담아내는 것입니다.

직원이 자발적으로 쓴 이 함정 회피 가이드에서도 보입니다. 이것은 아래에서 위로 자라난 직원 습관입니다. 이것이야말로 진정한 AI Native입니다.

AI가 모두가 일할 때의 습관이 되면, 이런 경험은 매번의 납품과 함께 계속 축적될 것입니다. 이것이야말로 기업이 일찍 실천을 시작하는 가치라고 생각합니다.

창허(苍何)

Java 개발/기술 리더 @앤트그룹(蚂蚁集团)

314

글

246k

읽음

571

팬