아무도 안오던 AI 미팅, 이제는 자리가 없습니다.
안녕하세요. 한국신용데이터 품질개선팀 QA 리드 JM입니다.
저는 회사에서 'AI를 활용하여 업무 생산성을 높이자'라는 목표를 가진 전사 AI 확산 프로그램 'AI Smart Work'를 맡고 있습니다. 이렇게 말하면 다들 똑같이 묻습니다. "QA 리드라는 사람이 왜 그걸 해?" 네, 저도 의아하지만, 제가 이 프로그램을 맡은 이유는 마지막에 말씀드리겠습니다. 그게 이 글이 하려는 이야기 전부거든요. (이러면 끝까지 읽어주시려나요 ㅎㅎ)
AI를 확산시킬 전도사, 앰버서더를 뽑다
1년 전, 사내에 AI 도구를 막 들여오던 시절 저는 이렇게 믿었습니다. "AI를 잘 쓰려면 프롬프트나 지침 같은 기술부터 익혀야 한다." 그래서 팀마다 AI 전도사를 한 명씩 두기로 했죠. 전도사는 좀 종교적이니까 이름은 '앰버서더'로. 그리고 당연히 AI 좀 만질 줄 아는 개발자분들로 골랐습니다.
개발 리더에서 개발자 전체로, 저변을 넓히다
초기 앰버서더는 개발 리더들이 맡았습니다. 리더가 먼저 써봐야 도입을 결정하고 팀에 권할 수 있으니까요. 리더들은 관심도 많고 잘 사용하였습니다. 문제는, 리더 몇 명이 잘 쓰고 관심 있는 것으론 부족하다는 겁니다. 개발자 모두가 잘 써야 했죠. 그래서 저변을 넓혔습니다.
그렇게 앰버서더 1기는 다양한 개발자들이 맡았습니다. AI 효과가 가장 빨리 눈에 보이는 사람들이니까요. 이때 사내 엔지니어링 위키에 AI 사례가 쏟아졌어요. 처음엔 "Cursor 써봤더니" "Copilot 후기" 수준이다가, 점점 KCD 개발 컨벤션을 AI한테 학습시키고, 사내 도구랑 연결하고, 코드리뷰 봇까지 직접 만드는 쪽으로 갔죠. "AI 써봤다"가 아니라 "AI를 우리 팀원처럼 굴린다"는 단계로요. 제 팀(QA)도 손으로 짜던 테스트 케이스랑 자동화 코드를 AI를 활용해서 만들면서 커버리지를 끌어올리고 있었고요.
이쯤 되니 궁금해졌어요. 다들 얼마나 쓰는지 측정을 할 수 있을까? 뭘로 측정을 해야 할까?
어떻게 측정해야 할까?
KCD에서 귀에 못이 박히게 듣는 말이 있어요. "측정할 수 없으면 개선할 수 없다." 피터 드러커가 했다는 그 말이요. 그래서 AI 도구별로 누가 얼마나 쓰는지 한눈에 보이는 사용량 대시보드부터 만들었습니다. Claude, Cursor, Gemini, Figma AI까지 주간 활성 사용자(WAU)랑 토큰·요청·크레딧이 쭉 쌓이게요.
누가 뭘 얼마나 쓰는지 한 화면에. 측정이 안 되면 "잘 되고 있다"는 말도 그냥 느낌일 뿐이니까요.
대시보드를 만들고 나니, 마침 비슷한 얘기를 하는 사람이 있더군요. 엔비디아 CEO 젠슨 황이 최근 한 콘퍼런스에서, 엔지니어를 코드 줄 수가 아니라 AI 토큰 사용량으로 평가해야 한다고 했거든요.[1] 연봉 50만 달러짜리 엔지니어가 토큰을 25만 달러어치는 써야 한다고요. AI 안 쓰는 건 칩 설계자가 CAD 놔두고 종이랑 연필로 설계하겠다는 거랑 같다나요.[2]
한 70%는 동의합니다. AI 쓰는 사람과 안 쓰는 사람 격차가 벌어진다는 건 확실하고, 솔직히 지금처럼 다들 막 익숙해지는 초기엔 일단 많이 써보는 게 장땡이거든요. 손에 붙어야 잘 쓰든 말든 할 테니까요. 우리가 AI Smart Work를 시작한 이유도 거기 있었고요.
근데 나머지 30%는 갸웃했습니다. 토큰 많이 쓴다는 건 프롬프트를 비효율적으로 짰거나 같은 걸 몇 번씩 다시 시켰다는 뜻일 때도 많거든요. 대시보드 숫자는 쓸모가 있지만, 그게 곧 '잘 쓴다'는 아니란 거죠. 많이 쓰는 조직 말고, 잘 쓰는 조직이 되고 싶었습니다. 그런데 '잘 쓴다'를 정의하려니 딱 막혔어요. 다들 그러잖아요. AI 잘 쓰려면 프롬프트를 잘 짜야 하고, 지침도 정교하게 세팅하고, 설정 파일까지 다룰 줄 알아야 한다고. 근데 정말 그런 걸 잘해야만 AI를 잘 쓸 수 있을까요?
클로드가 나오면서 더 빠르게 바뀌었다
방향을 다시 잡게 된 건, 클로드를 도입하면서였습니다.
클로드가 나오고 AI가 달라졌어요. 예전엔 질문을 또박또박 구조적으로 던져야 쓸 만한 답이 나왔는데 클로드는 뭐같이 말해도 찰떡같이 알아듣기 시작하더라고요. 두서없이 막 설명해도 의도를 척 짚어냈습니다. 게다가 클로드 CLI를 쓰면 비개발자도 진짜 '바이브코딩'이 되더군요. 코드 한 줄 못 짜는 사람이 원하는 걸 말로 떠들기만 했는데 자기 업무 자동화 도구가 뚝딱 나오는 겁니다.
여기서 옛날 검색 엔진이 떠올랐어요. 구글 창업자 래리 페이지가 그랬죠. "궁극의 검색엔진은 당신이 의미하는 바를 정확히 이해하고, 원하는 걸 정확히 돌려준다"고.[3] 초창기엔 검색어를 똑똑하게 넣어야 결과가 나왔습니다. 근데 검색은 사용자한테 "검색어 잘 넣는 법"을 가르치지 않았어요. 반대로, 대충 쳐도 알아서 의도를 읽는 쪽으로 진화했죠. 애쓰는 쪽이 사람에서 시스템으로 넘어간 겁니다.
AI도 딱 그 길을 가고 있었어요. 그렇다면 비개발자도 바이브코딩으로 개발자처럼 AI를 쓸 수 있겠구나, 그들의 업무도 자동화해서 생산성을 높일 수 있겠구나 싶었죠. 그래서 2기는 비개발자로 모집했습니다.
2기는 AI와 가깝지 않은 사람들로 구성했다
2기 앰버서더를 뽑을 때, 선정 기준은 "AI를 잘 다루는가"가 아니었어요. 오히려 정반대였죠.
2기 모집을 공지했을 때 많은 분들이 신청을 해주셨어요. 50%는 탈락을 시켜야 하는 상황에서 첫 번째 기준은 개발자랑 일할 일이 가장 적은 팀이었습니다. 평소 개발 리소스를 좀처럼 못 받는 팀일수록, 개발자 멘토가 붙는 게 귀하니까요. 그래서 개발·QA·데이터분석처럼 이미 개발자랑 붙어사는 팀은 오히려 뒷순위로 밀었습니다. (제 팀 QA도 여기서 모두 탈락이었어요. 이미 개발자랑 붙어사는 팀이니까요.) 두 번째는 반복·정형 업무가 많은 자리였어요. 데이터 가공, 정산 검증, 상품 등록처럼 자동화하면 ROI가 확 뛰는 일을 가진 분들이요.
그렇게 데이터사업·정산·마켓·인사·법무·콘텐츠·PR·디자인까지, 팀도 직군도 죄다 다른 분들이 모였습니다. 공통점이라곤 "개발자랑 일할 일이 별로 없다"는 것뿐이었죠. 여기에 개발자 멘토를 1:1로 붙였어요. 클로드 CLI를 사용하려면 CLI 창에서 작업을 해야 하는데 처음 셋업하는 단계와 시작하는 단계에서 허들이 좀 있다고 생각했거든요.
초기 허들만 넘으면, 비개발 앰버서더들이 직접 업무 자동화를 시작할 거라고 봤어요. AI가 개발 직군에만 고이지 않고 회사 구석구석 퍼지게 하려는 그림이었죠. 개발자가 아닌 사람들이 "저분도 하시는데, 나도 해볼까" 하며 따라오지 않을까 하는, 반쯤은 도박이었습니다.
앰버서더와 개발자 멘토를 1:1로. '도와주세요 → 배정 → 함께 진행중 → 해결 완료' 칸반 위에서 비개발자의 AI 사용 요청이 실제로 진행됩니다.
모두가 사례를 공유할 수 있게, AI 캠퍼스
누군가 AI로 뭔가 해냈는데 그게 그 사람 혼자 경험으로 끝나면, 확산은 안 일어납니다. 한 사람의 사례가 다른 사람의 출발점이 돼야 하죠. 근데 기존 방식인 구글 시트는, 끝도 없이 길어지기만 하고 아무도 안 봤어요. 솔직히 저도 안 봤습니다.
그래서 그냥 만들었습니다. Claude Code로 'AI 캠퍼스'라는 사내 사이트를 짜서 지금 운영 중이에요. 누구나 자기 AI 활용 사례를 올리고, 좋아요 누르고, 댓글 달고, 인기 사례에 투표하는 공간입니다. 앞에서 보여드린 도구 사용량 대시보드도 사실 여기 안에 있어요. '얼마나 쓰는지'랑 '어떻게 쓰는지'를 한 화면에서 보는 거죠. 대단한 건 아니고, 코드 모르던 동료들이 자기 업무를 자동화하는 걸 보다가 "나도 하나 만들어볼까" 하고 주말에 끄적인 겁니다. 잘 만들었다기보단, 그냥 만들 수 있는 시대가 됐다는 게 포인트죠.
캠퍼스에 올라온 사례들은 직군 경계가 없습니다. 법무 담당자가 만든 환각 없는 법률 검색, 정산 담당자의 수납 대사 자동화 같은 비개발자 사례가, 개발자가 올린 코드리뷰 봇이나 쿼리 분석이랑 같은 화면에서 인기순으로 나란히 경쟁해요. 예를 들어 반나절씩 손으로 맞추던 정산 검증이 클릭 한 번으로 끝나고, 수백 개 상품 등록이 한 방에 처리됩니다. 한때 "AI는 개발자나 쓰는 거"라던 그 선이, 캠퍼스 안에선 안 보입니다.
AI 캠퍼스에 업무 자동화 사례를 등록해 공유하고, 다른 사람이 쓴 사례에 댓글 달고 좋아요를 눌러 반응할 수 있어요.
숫자로 보면 더 확실합니다
말로만 "퍼졌어요" 하면 안 믿으실 테니, 숫자로 보여드릴게요.
올해 목표는 '구성원 1인당 월 1건, 연간 2,000건' AI 전환입니다. 프로그램을 본격화한 3월부터 지금까지 912건 쌓였고, 목표의 45.6%를 지났어요. 그중 이번 달(5월)에만 273건. 갈수록 등록 속도가 붙고 있다는 뜻입니다. 이번 달 참여율은 193명 중 190명, 98%. 사실상 전 직원이 한 번씩은 손을 댔다는 얘기예요.
연간 2,000건 중 912건, 이번 달 참여율 98%
더 재밌는 건 추세예요. 주차별 신규 사례가 23건 → 42건 → 89건 → 119건으로 매주 가팔라지고 있습니다. 누적 좋아요 388개, 댓글 364개. 이건 시켜서 억지로 채우는 숫자가 아니라, 남의 사례 보고 "오 이거 나도" 하면서 따라 하는 숫자입니다.
주차별 신규 사례 23 → 42 → 89 → 119건. 곡선이 알아서 가팔라지고 있습니다.
아무도 안 오던 미팅룸이 꽉 차기까지
이 변화가 제일 피부로 느껴지는 데가, 매주 여는 AI Office Hour입니다. 미팅룸에 모여서 자기 업무를 어떻게 자동화했는지 직접 발표하는 시간이에요.
솔직히 처음엔 처참했습니다. 발표할 사람 구하는 게 일이었어요. "저는 대단한 거 한 것도 없는데요", "이런 걸 발표해도 되나요" 하면서 다들 손사래. 빈자리가 많은 날도 있었습니다. (진행하는 입장에서 꽤 힘든시간이였어요.)
그런데 요즘은 미팅룸 자리
가 모자랍니다. 발표하겠다는 사람들도 많아졌어요. 뭐가 달라졌냐고요? 대단한 성공담이 아니라 "나도 이 정도는 했다"는 소소한 사례들이 캠퍼스에 쌓이면서였어요. 반나절 걸리던 정산 검증을 자동화한 얘기, 상품 수백 개를 한 방에 등록한 얘기. 그걸 본 옆자리 동료가 따라 하고, 그게 또 다음 발표가 됩니다. AI 자동화가 더는 특별한 일이 아니라, 그냥 일하는 방식이 되어가고 있었어요.
매주 수요일 AI Office Hour에서는 업무 자동화 사례를 공유하는 세션이 열리고 있습니다.
그래서, QA 리드가 왜 이걸 맡았느냐면
이제 맨 처음에 미뤄둔 질문에 답할 차례네요.
처음 CTO가 AI 활성화 프로그램을 맡아달라고 했을 때, 솔직히 "네? 전 QA인데요?" 하고 뺄까 했습니다. 근데 안 뺐어요. 어차피 회사가 가는 방향이고 AI로 인해 직군의 경계도 허물어지고 일하는 방식을 완전히 바꿀 건데 나부터 변화해보자고 긍정적으로 생각하는 게 좋을 것 같았거든요.
그렇게 처음 시작한 일인데, 1년이 지나고 보니 생각이 정리되더라고요.
처음엔 AI 잘 쓰는 사람과 못 쓰는 사람의 격차를 '프롬프트 기술'로 메우려 했어요. 근데 두서없이 말해도 알아듣는 도구가 나오고, 코드 모르던 분이 자기 일을 자동화하고, 텅 비었던 미팅룸이 차오르는 걸 보니 답이 나오더라고요. 물론 프롬프트를 잘 짜면 지금도 결과는 더 좋습니다. 다만 그게 'AI 잘 쓰는 사람'의 자격 조건은 아니더라는 거예요. 그 격차는 점점 줄어들 테니까요. 그냥 일단 AI와 같이 시작해보면, 누구든 자기 앞의 벽 하나쯤은 넘습니다.
그러고 보니 이건 결국 QA가 늘 하던 일이더라고요. 측정해서 현상을 드러내고, 안 되는 지점을 찾아내고, 누구나 걸리지 않고 쓸 수 있을 때까지 품질을 끌어올리는 것. 대상이 '소프트웨어'에서 '일하는 방식'으로 바뀌었을 뿐이었어요. QA 리드가 왜 이걸 맡았냐고요? 1년 지나고 보니, 의외로 제일 잘 맞는 사람인 것 같다는 생각도 듭니다.
마지막으로
이 글은 제가 썼지만, 회사일에서 혼자 하는 건 없습니다.
AI가 지금처럼 똘똘하지 않던 시절에도 많은 시도를 하며 다양한 사례를 발표하며 판을 받쳐준 앰버서더 1기 개발자들, 비개발 동료들 곁에서 강의를 열고 가장 많이 발표해준 동료, 발표자가 펑크 날 때마다 급하게 요청해도 싫은 내색 없이 자리를 메워준 동료. 그리고 시키지도 않았는데 자발적으로 뛰어든 2기 앰버서더분들, 바쁘지만 매주 AI Office Hour에 참석해주는 CTO, 인프라보안 실장님 그리고 자기의 사례를 공유해주시는 KCD 분들 모두와 함께 하고 있습니다.
지금, KCD는 사장님의 더 나은 내일을 위해 함께할 동료를 찾고 있어요. AI가 직군의 경계를 지우는 이 변화를 직접 만들어가고 싶다면, 아래에서 만나요!
✨ 영입 중인 포지션 확인하기
✨ KCD가 더 궁금하다면?
참고 (References)
[1] Jensen Huang, All-In Podcast (Nvidia GTC 2026, 2026.03) — 엔지니어를 코드 줄 수가 아니라 AI 토큰 사용량으로 평가해야 한다는 발언. "If that $500,000 engineer did not consume at least $250,000 worth of tokens, I'm going to be deeply alarmed." (링크)
[2] Tom's Hardware (2026.03), "Jensen Huang says Nvidia engineers should use AI tokens worth half their annual salary every year to be fully productive — compares not using AI to using paper and pencil for designing chips." (링크)
[3] Larry Page, "The perfect search engine would understand exactly what you mean and give back exactly what you want." — Google, Ten things we know to be true (Our Philosophy). (링크)
안녕하세요. 한국신용데이터 품질개선팀 QA 리드 JM입니다.
저는 회사에서 'AI를 활용하여 업무 생산성을 높이자'라는 목표를 가진 전사 AI 확산 프로그램 'AI Smart Work'를 맡고 있습니다. 이렇게 말하면 다들 똑같이 묻습니다. "QA 리드라는 사람이 왜 그걸 해?" 네, 저도 의아하지만, 제가 이 프로그램을 맡은 이유는 마지막에 말씀드리겠습니다. 그게 이 글이 하려는 이야기 전부거든요. (이러면 끝까지 읽어주시려나요 ㅎㅎ)
AI를 확산시킬 전도사, 앰버서더를 뽑다
1년 전, 사내에 AI 도구를 막 들여오던 시절 저는 이렇게 믿었습니다. "AI를 잘 쓰려면 프롬프트나 지침 같은 기술부터 익혀야 한다." 그래서 팀마다 AI 전도사를 한 명씩 두기로 했죠. 전도사는 좀 종교적이니까 이름은 '앰버서더'로. 그리고 당연히 AI 좀 만질 줄 아는 개발자분들로 골랐습니다.
개발 리더에서 개발자 전체로, 저변을 넓히다
초기 앰버서더는 개발 리더들이 맡았습니다. 리더가 먼저 써봐야 도입을 결정하고 팀에 권할 수 있으니까요. 리더들은 관심도 많고 잘 사용하였습니다. 문제는, 리더 몇 명이 잘 쓰고 관심 있는 것으론 부족하다는 겁니다. 개발자 모두가 잘 써야 했죠. 그래서 저변을 넓혔습니다.
그렇게 앰버서더 1기는 다양한 개발자들이 맡았습니다. AI 효과가 가장 빨리 눈에 보이는 사람들이니까요. 이때 사내 엔지니어링 위키에 AI 사례가 쏟아졌어요. 처음엔 "Cursor 써봤더니" "Copilot 후기" 수준이다가, 점점 KCD 개발 컨벤션을 AI한테 학습시키고, 사내 도구랑 연결하고, 코드리뷰 봇까지 직접 만드는 쪽으로 갔죠. "AI 써봤다"가 아니라 "AI를 우리 팀원처럼 굴린다"는 단계로요. 제 팀(QA)도 손으로 짜던 테스트 케이스랑 자동화 코드를 AI를 활용해서 만들면서 커버리지를 끌어올리고 있었고요.
이쯤 되니 궁금해졌어요. 다들 얼마나 쓰는지 측정을 할 수 있을까? 뭘로 측정을 해야 할까?
어떻게 측정해야 할까?
KCD에서 귀에 못이 박히게 듣는 말이 있어요. "측정할 수 없으면 개선할 수 없다." 피터 드러커가 했다는 그 말이요. 그래서 AI 도구별로 누가 얼마나 쓰는지 한눈에 보이는 사용량 대시보드부터 만들었습니다. Claude, Cursor, Gemini, Figma AI까지 주간 활성 사용자(WAU)랑 토큰·요청·크레딧이 쭉 쌓이게요.
누가 뭘 얼마나 쓰는지 한 화면에. 측정이 안 되면 "잘 되고 있다"는 말도 그냥 느낌일 뿐이니까요.
대시보드를 만들고 나니, 마침 비슷한 얘기를 하는 사람이 있더군요. 엔비디아 CEO 젠슨 황이 최근 한 콘퍼런스에서, 엔지니어를 코드 줄 수가 아니라 AI 토큰 사용량으로 평가해야 한다고 했거든요.[1] 연봉 50만 달러짜리 엔지니어가 토큰을 25만 달러어치는 써야 한다고요. AI 안 쓰는 건 칩 설계자가 CAD 놔두고 종이랑 연필로 설계하겠다는 거랑 같다나요.[2]
한 70%는 동의합니다. AI 쓰는 사람과 안 쓰는 사람 격차가 벌어진다는 건 확실하고, 솔직히 지금처럼 다들 막 익숙해지는 초기엔 일단 많이 써보는 게 장땡이거든요. 손에 붙어야 잘 쓰든 말든 할 테니까요. 우리가 AI Smart Work를 시작한 이유도 거기 있었고요.
근데 나머지 30%는 갸웃했습니다. 토큰 많이 쓴다는 건 프롬프트를 비효율적으로 짰거나 같은 걸 몇 번씩 다시 시켰다는 뜻일 때도 많거든요. 대시보드 숫자는 쓸모가 있지만, 그게 곧 '잘 쓴다'는 아니란 거죠. 많이 쓰는 조직 말고, 잘 쓰는 조직이 되고 싶었습니다. 그런데 '잘 쓴다'를 정의하려니 딱 막혔어요. 다들 그러잖아요. AI 잘 쓰려면 프롬프트를 잘 짜야 하고, 지침도 정교하게 세팅하고, 설정 파일까지 다룰 줄 알아야 한다고. 근데 정말 그런 걸 잘해야만 AI를 잘 쓸 수 있을까요?
클로드가 나오면서 더 빠르게 바뀌었다
방향을 다시 잡게 된 건, 클로드를 도입하면서였습니다.
클로드가 나오고 AI가 달라졌어요. 예전엔 질문을 또박또박 구조적으로 던져야 쓸 만한 답이 나왔는데 클로드는 뭐같이 말해도 찰떡같이 알아듣기 시작하더라고요. 두서없이 막 설명해도 의도를 척 짚어냈습니다. 게다가 클로드 CLI를 쓰면 비개발자도 진짜 '바이브코딩'이 되더군요. 코드 한 줄 못 짜는 사람이 원하는 걸 말로 떠들기만 했는데 자기 업무 자동화 도구가 뚝딱 나오는 겁니다.
여기서 옛날 검색 엔진이 떠올랐어요. 구글 창업자 래리 페이지가 그랬죠. "궁극의 검색엔진은 당신이 의미하는 바를 정확히 이해하고, 원하는 걸 정확히 돌려준다"고.[3] 초창기엔 검색어를 똑똑하게 넣어야 결과가 나왔습니다. 근데 검색은 사용자한테 "검색어 잘 넣는 법"을 가르치지 않았어요. 반대로, 대충 쳐도 알아서 의도를 읽는 쪽으로 진화했죠. 애쓰는 쪽이 사람에서 시스템으로 넘어간 겁니다.
AI도 딱 그 길을 가고 있었어요. 그렇다면 비개발자도 바이브코딩으로 개발자처럼 AI를 쓸 수 있겠구나, 그들의 업무도 자동화해서 생산성을 높일 수 있겠구나 싶었죠. 그래서 2기는 비개발자로 모집했습니다.
2기는 AI와 가깝지 않은 사람들로 구성했다
2기 앰버서더를 뽑을 때, 선정 기준은 "AI를 잘 다루는가"가 아니었어요. 오히려 정반대였죠.
2기 모집을 공지했을 때 많은 분들이 신청을 해주셨어요. 50%는 탈락을 시켜야 하는 상황에서 첫 번째 기준은 개발자랑 일할 일이 가장 적은 팀이었습니다. 평소 개발 리소스를 좀처럼 못 받는 팀일수록, 개발자 멘토가 붙는 게 귀하니까요. 그래서 개발·QA·데이터분석처럼 이미 개발자랑 붙어사는 팀은 오히려 뒷순위로 밀었습니다. (제 팀 QA도 여기서 모두 탈락이었어요. 이미 개발자랑 붙어사는 팀이니까요.) 두 번째는 반복·정형 업무가 많은 자리였어요. 데이터 가공, 정산 검증, 상품 등록처럼 자동화하면 ROI가 확 뛰는 일을 가진 분들이요.
그렇게 데이터사업·정산·마켓·인사·법무·콘텐츠·PR·디자인까지, 팀도 직군도 죄다 다른 분들이 모였습니다. 공통점이라곤 "개발자랑 일할 일이 별로 없다"는 것뿐이었죠. 여기에 개발자 멘토를 1:1로 붙였어요. 클로드 CLI를 사용하려면 CLI 창에서 작업을 해야 하는데 처음 셋업하는 단계와 시작하는 단계에서 허들이 좀 있다고 생각했거든요.
초기 허들만 넘으면, 비개발 앰버서더들이 직접 업무 자동화를 시작할 거라고 봤어요. AI가 개발 직군에만 고이지 않고 회사 구석구석 퍼지게 하려는 그림이었죠. 개발자가 아닌 사람들이 "저분도 하시는데, 나도 해볼까" 하며 따라오지 않을까 하는, 반쯤은 도박이었습니다.
앰버서더와 개발자 멘토를 1:1로. '도와주세요 → 배정 → 함께 진행중 → 해결 완료' 칸반 위에서 비개발자의 AI 사용 요청이 실제로 진행됩니다.
모두가 사례를 공유할 수 있게, AI 캠퍼스
누군가 AI로 뭔가 해냈는데 그게 그 사람 혼자 경험으로 끝나면, 확산은 안 일어납니다. 한 사람의 사례가 다른 사람의 출발점이 돼야 하죠. 근데 기존 방식인 구글 시트는, 끝도 없이 길어지기만 하고 아무도 안 봤어요. 솔직히 저도 안 봤습니다.
그래서 그냥 만들었습니다. Claude Code로 'AI 캠퍼스'라는 사내 사이트를 짜서 지금 운영 중이에요. 누구나 자기 AI 활용 사례를 올리고, 좋아요 누르고, 댓글 달고, 인기 사례에 투표하는 공간입니다. 앞에서 보여드린 도구 사용량 대시보드도 사실 여기 안에 있어요. '얼마나 쓰는지'랑 '어떻게 쓰는지'를 한 화면에서 보는 거죠. 대단한 건 아니고, 코드 모르던 동료들이 자기 업무를 자동화하는 걸 보다가 "나도 하나 만들어볼까" 하고 주말에 끄적인 겁니다. 잘 만들었다기보단, 그냥 만들 수 있는 시대가 됐다는 게 포인트죠.
캠퍼스에 올라온 사례들은 직군 경계가 없습니다. 법무 담당자가 만든 환각 없는 법률 검색, 정산 담당자의 수납 대사 자동화 같은 비개발자 사례가, 개발자가 올린 코드리뷰 봇이나 쿼리 분석이랑 같은 화면에서 인기순으로 나란히 경쟁해요. 예를 들어 반나절씩 손으로 맞추던 정산 검증이 클릭 한 번으로 끝나고, 수백 개 상품 등록이 한 방에 처리됩니다. 한때 "AI는 개발자나 쓰는 거"라던 그 선이, 캠퍼스 안에선 안 보입니다.
AI 캠퍼스에 업무 자동화 사례를 등록해 공유하고, 다른 사람이 쓴 사례에 댓글 달고 좋아요를 눌러 반응할 수 있어요.
숫자로 보면 더 확실합니다
말로만 "퍼졌어요" 하면 안 믿으실 테니, 숫자로 보여드릴게요.
올해 목표는 '구성원 1인당 월 1건, 연간 2,000건' AI 전환입니다. 프로그램을 본격화한 3월부터 지금까지 912건 쌓였고, 목표의 45.6%를 지났어요. 그중 이번 달(5월)에만 273건. 갈수록 등록 속도가 붙고 있다는 뜻입니다. 이번 달 참여율은 193명 중 190명, 98%. 사실상 전 직원이 한 번씩은 손을 댔다는 얘기예요.
연간 2,000건 중 912건, 이번 달 참여율 98%
더 재밌는 건 추세예요. 주차별 신규 사례가 23건 → 42건 → 89건 → 119건으로 매주 가팔라지고 있습니다. 누적 좋아요 388개, 댓글 364개. 이건 시켜서 억지로 채우는 숫자가 아니라, 남의 사례 보고 "오 이거 나도" 하면서 따라 하는 숫자입니다.
주차별 신규 사례 23 → 42 → 89 → 119건. 곡선이 알아서 가팔라지고 있습니다.
아무도 안 오던 미팅룸이 꽉 차기까지
이 변화가 제일 피부로 느껴지는 데가, 매주 여는 AI Office Hour입니다. 미팅룸에 모여서 자기 업무를 어떻게 자동화했는지 직접 발표하는 시간이에요.
솔직히 처음엔 처참했습니다. 발표할 사람 구하는 게 일이었어요. "저는 대단한 거 한 것도 없는데요", "이런 걸 발표해도 되나요" 하면서 다들 손사래. 빈자리가 많은 날도 있었습니다. (진행하는 입장에서 꽤 힘든시간이였어요.)
그런데 요즘은 미팅룸 자리
가 모자랍니다. 발표하겠다는 사람들도 많아졌어요. 뭐가 달라졌냐고요? 대단한 성공담이 아니라 "나도 이 정도는 했다"는 소소한 사례들이 캠퍼스에 쌓이면서였어요. 반나절 걸리던 정산 검증을 자동화한 얘기, 상품 수백 개를 한 방에 등록한 얘기. 그걸 본 옆자리 동료가 따라 하고, 그게 또 다음 발표가 됩니다. AI 자동화가 더는 특별한 일이 아니라, 그냥 일하는 방식이 되어가고 있었어요.
매주 수요일 AI Office Hour에서는 업무 자동화 사례를 공유하는 세션이 열리고 있습니다.
그래서, QA 리드가 왜 이걸 맡았느냐면
이제 맨 처음에 미뤄둔 질문에 답할 차례네요.
처음 CTO가 AI 활성화 프로그램을 맡아달라고 했을 때, 솔직히 "네? 전 QA인데요?" 하고 뺄까 했습니다. 근데 안 뺐어요. 어차피 회사가 가는 방향이고 AI로 인해 직군의 경계도 허물어지고 일하는 방식을 완전히 바꿀 건데 나부터 변화해보자고 긍정적으로 생각하는 게 좋을 것 같았거든요.
그렇게 처음 시작한 일인데, 1년이 지나고 보니 생각이 정리되더라고요.
처음엔 AI 잘 쓰는 사람과 못 쓰는 사람의 격차를 '프롬프트 기술'로 메우려 했어요. 근데 두서없이 말해도 알아듣는 도구가 나오고, 코드 모르던 분이 자기 일을 자동화하고, 텅 비었던 미팅룸이 차오르는 걸 보니 답이 나오더라고요. 물론 프롬프트를 잘 짜면 지금도 결과는 더 좋습니다. 다만 그게 'AI 잘 쓰는 사람'의 자격 조건은 아니더라는 거예요. 그 격차는 점점 줄어들 테니까요. 그냥 일단 AI와 같이 시작해보면, 누구든 자기 앞의 벽 하나쯤은 넘습니다.
그러고 보니 이건 결국 QA가 늘 하던 일이더라고요. 측정해서 현상을 드러내고, 안 되는 지점을 찾아내고, 누구나 걸리지 않고 쓸 수 있을 때까지 품질을 끌어올리는 것. 대상이 '소프트웨어'에서 '일하는 방식'으로 바뀌었을 뿐이었어요. QA 리드가 왜 이걸 맡았냐고요? 1년 지나고 보니, 의외로 제일 잘 맞는 사람인 것 같다는 생각도 듭니다.
마지막으로
이 글은 제가 썼지만, 회사일에서 혼자 하는 건 없습니다.
AI가 지금처럼 똘똘하지 않던 시절에도 많은 시도를 하며 다양한 사례를 발표하며 판을 받쳐준 앰버서더 1기 개발자들, 비개발 동료들 곁에서 강의를 열고 가장 많이 발표해준 동료, 발표자가 펑크 날 때마다 급하게 요청해도 싫은 내색 없이 자리를 메워준 동료. 그리고 시키지도 않았는데 자발적으로 뛰어든 2기 앰버서더분들, 바쁘지만 매주 AI Office Hour에 참석해주는 CTO, 인프라보안 실장님 그리고 자기의 사례를 공유해주시는 KCD 분들 모두와 함께 하고 있습니다.
지금, KCD는 사장님의 더 나은 내일을 위해 함께할 동료를 찾고 있어요. AI가 직군의 경계를 지우는 이 변화를 직접 만들어가고 싶다면, 아래에서 만나요!
✨ 영입 중인 포지션 확인하기
✨ KCD가 더 궁금하다면?
참고 (References)
[1] Jensen Huang, All-In Podcast (Nvidia GTC 2026, 2026.03) — 엔지니어를 코드 줄 수가 아니라 AI 토큰 사용량으로 평가해야 한다는 발언. "If that $500,000 engineer did not consume at least $250,000 worth of tokens, I'm going to be deeply alarmed." (링크)
[2] Tom's Hardware (2026.03), "Jensen Huang says Nvidia engineers should use AI tokens worth half their annual salary every year to be fully productive — compares not using AI to using paper and pencil for designing chips." (링크)
[3] Larry Page, "The perfect search engine would understand exactly what you mean and give back exactly what you want." — Google, Ten things we know to be true (Our Philosophy). (링크)