[바이브코딩 워크샵 회고록]비개발자 148명에게 2주 동안 AI를 붙여봤습니다

안녕하세요. 어피닛(Afinit) TFS(Tech Foundation Service) 팀에서 전사 AX(AI Transformation)을 맡고 있는 Woony입니다. 저희 팀은 "회사가 일하는 방식 자체를 AI 중심으로 재편하는 일"을 합니다. 이번 글에서는 그 전환의 한 단계로 인도 현장에서 2주를 보내고 온 이야기를 공유하려고 합니다.

우리가 어떤 상황에서 이걸 했는지부터 설명해볼게요

저희 팀은 지난 1년 가까이 'Sidekick'이라는 사내 AI 플랫폼을 만들어 왔습니다. 이를 한 문장으로 설명하면 “직원 한 명마다 자기 업무를 돕는 AI 비서를 한 명씩 붙여주자!”인데요. 개발자들은 이 플랫폼을 이미 일상적으로 쓰고 있습니다. Claude Code로 에이전트와 스킬을 만들어 쓰고, 팀 안에는 에이전트 사용 문화가 자리를 잡았습니다. 저희가 AI 전환의 정도를 재기 위해 만든 내부 지표(ANTI, AI-Native Transformation Index — 직원이 자기 업무를 AI로 얼마나 자율적으로 처리하는지를 단계로 나눠 측정)로 봐도, 개발자 조직은 이미 꽤 높은 단계에 올라와 있습니다.

문제는 그다음이었습니다. 회사의 대부분은 개발자가 아닙니다. HR, 재무, 법무, 마케팅, 리스크, CX 같은 직군의 사람들이 실제로 AI로 일하는 방식을 바꾸지 않으면 "AI 전환"이라는 말은 공허한 구호로 남습니다. 이 갭에 대해서는 Forward Deployed Engineer 글에서 자세히 다뤘으니 배경이 궁금한 분은 함께 읽어보시면 좋겠습니다.

저희는 개발자들 대상으로 해당 플랫폼에 대해 검증을 먼저 끝냈고, 뒤이어 얼리어답터를 타겟으로 한 프로그램을 거쳤습니다. 이번 워크샵은 그 흐름에서 비개발자 전체로 한 발 더 나아가는 단계였습니다. AI 툴을 가르치는 것 자체가 목적이라기보다, 개발자 다음으로 '바뀔 수 있는 비개발자'를 찾아내서 이후 사내 해커톤으로 연결하기 위한 첫 단계였습니다. 워크샵에서 가능성을 보인 사람들을 해커톤에서 실제로 회사 문제를 풀어내는 빌더로 키우는 게 다음 그림이었습니다.

그래서 2026년 3월 말, 저희는 인도 구르가온 사무실로 2주 동안 출장을 갔습니다. 비개발자 148명을 모아놓고 강의를 듣게 하는 게 아니라 직접 만들어보게 하는 워크샵을 열기 위해서였습니다.

현장 팀은 단출했습니다. 제가 현장을 총괄했고 저희 팀 인턴인 Mike와 Javis가 2주 내내 설치 지원과 현장 관찰을 맡았습니다. 인도 HR의 Akshit이 148명을 네 개 배치로 묶고 강사 섭외부터 현장 운영까지 해줬으며 — 이 중 세 배치가 비개발자 대상이었고, 마지막 네 번째는 개발자 대상이라 이 글에서는 다루지 않습니다 — 실제 강의는 외부 강사님이 진행했습니다. 인프라 지원은 한국에 계신 TFS 팀에서 맡아주셨습니다.

워크샵보다 설치가 먼저였습니다

막상 가서 가장 먼저 부딪힌 일은 워크샵이 아니라 설치였습니다. AI 도구가 자기 PC에서 실제로 돌아가지 않으면 워크샵은 강사가 데모하는 걸 구경만 하다 끝나기 때문입니다.

그래서 첫 주는 통째로 설치에 썼습니다. 148명에게 Claude Desktop을 일자별로 나눠서 설치해줬습니다. 자리로 찾아가 대면으로도 붙고, Slack으로도 붙고, 화상으로도 붙었습니다. 저희 팀 인턴인 Mike와 Javis가 각각 60건이 넘는 설치를 한 명 한 명 옆에 앉아서 도왔습니다.

설치는 생각보다 훨씬 더 너저분한 일이었습니다. 앱을 깔았다고 끝이 아니라, AI 스킬이 돌아가려면 별도의 의존성(uv, Python, Node.js)을 추가로 설치해야 했는데, 많은 분이 "앱 깔았어요"에서 멈춰 있었습니다. 윈도우에서는 관리자 권한이 없어 설치 파일이 아예 실행되지 않는 경우가 줄을 이었습니다. 공용 관리자 계정으로 묶여 설치 로그가 엉뚱하게 찍히는 바람에, 분명히 깐 사람인데 우리 추적 대시보드에는 "미설치"로 잡히는 일도 있었습니다. 누가 어디까지 했는지를 웹훅 로그와 이모지 반응, 스프레드시트를 교차검증해 매일 현황 리포트를 자동으로 뽑았는데 그 리포트가 매번 숫자가 달라져서 다시 손으로 맞춰야 했습니다.

그렇게 일주일을 갈아 넣어서, 148명 중 136명, 92%가 설치를 마친 상태로 워크샵에 들어갔습니다. 이 92%가 모든 것의 전제가 됩니다. 명심하세요. 도구가 손에 없으면 그다음은 아예 시작이 안 됩니다.

첫날 배치는 절반쯤 무너졌습니다

첫 번째 배치는 솔직히 절반의 실패였습니다. 저와 마이크, 자비스 옵저버 세 명이 15분 간격으로 현장을 기록했습니다. 그 기록을 시간 순서로 늘어놓으면 에너지가 어떻게 오르내렸는지가 그대로 보입니다.

• 처음에는 호기심으로 시작했다가,

• 세션 앞부분에서 AI 경험 설문을 작성하느라 집중이 끊기고,

• 모델과 카테고리를 설명하는 이론 구간에서 에너지가 바닥을 칩니다.

• 그러다 실습으로 넘어가면 살아나고,

• 자기 손으로 뭔가를 만드는 구간에서 가장 높아집니다.

• 그런데 만든 결과물이 꼬이기 시작하면 다시 좌절하고,

• 마지막에 개발자용 도구를 다루는 구간에서는 비개발자들이 그냥 빠져나갑니다.

패턴은 분명했습니다. 이론을 설명하면 가라앉고, 직접 해보게 하면 올라오고, 하다가 막히면 다시 가라앉았습니다.

현장에서 머리 아픈 상황도 잦았습니다. 회의실 와이파이가 너무 느려서 게스트 망으로 갈아타야 했고, 한쪽에 나란히 앉은 재무팀 세 분은 한동안 아무것도 안 하고 있었습니다. 워크샵을 더 몰입되게 해달라는 피드백을 서로 다른 네 명이 똑같이 남겼습니다. 결과물이 깨졌을 때는 AI에게 어떻게 고쳐달라고 말해야 하는지를 참가자들이 모르다보니 그 순간 그냥 손을 놨습니다. 개발자용 도구를 보여주는 구간은 비개발자에게는 남의 얘기였습니다. 심지어 옆에서 돕던 우리 팀조차 파일이 안 열리는 문제를 그 자리에서 풀지 못해, 막히거든 곧바로 제게 에스컬레이션하도록 하는 등 누구에게 물어볼지를 정하는 체계부터 다시 만들어야 했습니다.

그날의 추천 지표(NPS — 동료에게 추천하겠다는 사람의 비율에서 그렇지 않은 사람의 비율을 뺀 값으로, −100에서 +100 사이입니다)는 +39였습니다. 5점 만점 만족도는 4.1이었습니다. 숫자만 보면 나쁘지 않은데 정작 현장에서는 절반이 졸고 있었습니다. 이대로 네 번을 반복하면 안 되겠다고 생각했습니다.

그래서 매일 밤 고쳤습니다

여기서부터가 이 글에서 제일 하고 싶은 이야기입니다. 저희 팀은 배치가 하나 끝날 때마다 셋이 모여 30분씩 회고를 했습니다. 그날 무슨 일이 있었는지를 먼저 편하게 풀고, 설문 숫자와 관찰 기록을 같이 들여다보고, 다음 배치에 당장 바꿀 것을 정하는 순서였습니다. 회고 자리를 열 때마다 "평가가 아니라 함께 배우는 대화다, 틀린 답은 없다"는 원칙을 먼저 확인했습니다. 매 회고가 끝나면 정리한 내용을 강사님에게 피드백 이메일로 보냈습니다. 다음 날 아침에 바로 반영되도록 말이죠.

첫 배치에서 두 번째로 넘어갈 때는 이렇게 바꿨습니다. 사전 설문은 전날 미리 돌려서 현장 시간을 아꼈고, 파일 형식 가이드를 추가해서 결과물이 깨지는 걸 줄였습니다. 강사님이 앞에서만 설명하지 않고 자리를 돌면서 한 명씩 프롬프트를 봐주게 했고, 빈 화면에 알아서 쓰라고 하는 대신 강사님이 프롬프트를 주면 그대로 따라 치는 방식으로 바꿨습니다. Mike와 Javis가 옆에서 돕는 사람이라는 것을, 수업을 시작할 때 분명하게 소개했습니다.

여기서 솔직하게 적어둘 게 하나 있습니다. 두 번째 배치(PM, Design, Decision Scientist 등 Product 그룹)는 첫 배치보다 더 까다로운 그룹이었습니다. 이미 AI를 곧잘 쓰는 사람이 많아 기대치가 높았고, 만족도 평균은 오히려 조금 내려갔습니다(4.1 → 3.6). 그런데 추천 지표는 +39에서 +40으로 거의 그대로 유지됐습니다. 더 잘하는 사람들을 앞에 두고도 추천 의향이 떨어지지 않았다는 건, 매일 고친 것이 최소한 뒤로 미끄러지는 건 막고 있었다는 뜻이었습니다. 한 데이터 직군 참가자는 "기본적인 프롬프트 엔지니어링 말고 GitHub 연동, PR 리뷰, 배포까지 다루는 더 기술적인 세션을 기대했다"고 적었습니다. 이 한 줄이 나중에 개발자 배치를 어떻게 다르게 짜야 하는지를 알려줬습니다.

그래서 두 번째에서 세 번째로 넘어갈 때는 더 과감하게 잘랐습니다. 사전 설문을 아예 없앴고, 이론은 더 줄였습니다. 반응이 제일 좋았던 Cowork 실습을 오전으로 당겼고, 사람들이 오후 4시쯤 집중력이 떨어진다는 걸 확인하고는 4시간이 지나면 무조건 끝냈습니다. 슬라이드 대신 화이트보드에 직접 그려가며 설명했고, 막판에는 자율 실습 시간을 따로 허용했습니다.

이렇게 매일 바꾼 결과가 세 번째 배치에서 터졌습니다. 추천 지표가 +83까지 뛰었습니다. +39에서 +40으로 버티다가 +83으로 점프한 곡선입니다. 만족도도 4.2로 가장 높았습니다. 커리큘럼을 처음에 짜놓고 그대로 밀어붙였다면 절대 나오지 않았을 숫자입니다. 워크샵을 준비하는 분이 있다면, 저는 이 한 가지를 제일 먼저 권하고 싶습니다. 커리큘럼을 고정하지 말고, 하루 단위로 뜯어고치세요.

전환점은 자기 파일이 돌아간 순간이었습니다

분명한 전환점이 있었습니다. 자기 파일을 AI로 직접 다뤄보는 Cowork 실습이었습니다.

강사님이 앞에서 데모할 때 사람들은 그냥 구경했습니다. "강사가 잘하네, 신기하네" 딱 거기까지였습니다. 그런데 같은 걸 자기 노트북에서 자기 엑셀 파일로 돌려보게 하자, 반응이 완전히 달라졌습니다. "어, 내 파일로도 되네?" 하는 순간, 그게 남의 데모가 아니라 당장 내일 자기가 할 일로 바뀌었습니다. 두 번째 배치 기록에는 Claude for Excel 데모에서 관심이 그날 가장 높았다고 적혀 있습니다.

다만 그 전환은 공짜로 오지 않았습니다. Cowork은 윈도우에서 가상 머신 기능을 켜고 재부팅한 뒤 앱을 다시 깔아야 돌아갔는데, 이게 한 명씩 하면 끝없이 늘어졌습니다. 세 번째 배치 날에는 안 되는 사람이 너무 많아서, 아예 세션 중간에 텀을 두고 전원 환경을 병렬로 밀어버렸습니다. 한 사람당 세 명씩 잡고, 한 명을 진행하는 동안 나머지 두 명을 동시에 처리하는 식이었습니다. 그날 현장에서 인턴이 "여기 진짜 생지옥이에요"라고 메시지를 보냈을 만큼 정신없었습니다. 그래도 그 고비를 넘기자, 다들 자기 파일을 들고 직접 해보기 시작했습니다.

그 효과는 또 다른 숫자로도 드러났습니다. Sidekick을 바로 셋업하겠다는 사람이 첫 배치의 17%에서 69%로 뛰었습니다. 여기서 제가 배운 건 단순합니다. 환경만 매끄럽게 만들어주면, AI에 관심 있는 사람은 생각보다 훨씬 많았습니다. 관심이 없었던 게 아니라, 첫 장애물에서 막혀 있었을 뿐이었습니다.

바뀔 수 있는 사람은 분명히 있었습니다

앞에서 말했듯이 이 워크샵의 진짜 목적은 교육이 아니라 사람을 찾는 것이었습니다. 바뀌고 싶어 하는 사람, 그리고 실제로 바뀔 수 있는 사람을 찾고 싶었습니다.

그래서 후보를 다섯 가지로 봤습니다.

• 스스로 문제를 정의하는지,

• 막혀도 포기하지 않는지,

• 옆 사람을 가르치는지,

• 배운 걸 자기 실무에 연결하는지,

• 세션이 끝나고도 질문을 들고 오는지였습니다.

그렇게 12명을 찾았고, 후속 프로젝트 두 건이 바로 시작됐습니다. 하나는 재무팀의 대사(Reconciliation) 자동화였고, 다른 하나는 HR의 이력서 처리였습니다. 어떤 PM은 AWS 연동을 강사보다 빠르게 해냈고, 데이터 직군의 한 분은 ERD를 혼자 만들어내고는 옆자리 사람한테까지 알려주고 있었습니다. 또 다른 분은 세션이 끝나기도 전에 자기 AI를 직접 만들어 토큰까지 받아 갔습니다. 이런 사람들은 분명히 있었고, 우리가 할 일은 이들을 알아보고 옆에서 받쳐주는 것이었습니다.

챔피언을 1:1로 코칭하며 배운 네 가지

저는 워크샵에서 새로 선정한 12명과 별도로, 기존 얼리어답터 그룹에서 선정한 챔피언 후보 아홉 명을 따로 대면으로 트레이닝했는데요. 거기서 얻은 인사이트 또한 워크샵만큼이나 오래 남았습니다.

첫째, 프롬프트보다 플레이북(워크플로우, 업무 흐름)을 보여줘야 합니다. 한 시니어 리더에게 "팀원이 AI에게 먼저 보고하고, 그걸 사전에 검토한 다음, 정리된 상태로 본인에게 올라오는" 워크플로우를 통째로 보여줬더니 반응이 달라졌습니다. 프롬프트를 잘 쓰는 법을 알려주는 것보다, 일이 실제로 어떻게 바뀌는지를 보여주는 쪽이 훨씬 강했습니다.

둘째, "매니저가 실무자보다 AI를 더 잘 쓴다"는 말이 의외로 잘 통했습니다. 이 나이에 내가 이런 걸 어떻게 배우나, 하고 망설이는 시니어들의 심리적 장벽을 푸는 데 이 한마디가 제일 효과적이었습니다.

셋째, 대신 해달라는 의존을 일찍 끊어야 합니다. AI 지원팀이 다 대신 해주는 사람으로 오해받는 순간 전환은 실패합니다. 그래서 저는 "지금 저한테 물어보신 그 말을, 그대로 프롬프트에 적어보세요"라고 방향을 돌렸습니다.

넷째, 배운 걸 공유하게 하면 알아서 퍼집니다. 챔피언이 자기가 배운 걸 정리해서 사내 채널에 올리면, 본인의 학습도 단단해지고 그걸 본 동료가 따라 하는 흐름이 생겼습니다. CFO가 AI를 이용해 슬랙 메시지를 올렸을 때 반응은 엄청 뜨거웠습니다.

마치며: 도구를 깔아주는 일이 아니라, 일하는 방식을 바꾸는 일

AI 전환에서 가장 흔한 오해는, 도구를 깔아주면 알아서 쓸 거라는 생각입니다. 그래서 몇 명이 깔았는지를 성공의 기준으로 삼습니다. 하지만 2주 동안 현장에서 제가 본 건 정반대였습니다. 사람이 일하는 방식이 바뀌어야 하고, 그건 강의를 들을 때가 아니라 직접 만들어보고 막힌 걸 누군가 옆에서 풀어줄 때 일어났습니다.

그래서 이 워크샵을 한 문장으로 정리하면 이렇습니다. 환경만 제대로 만들어주면, 바뀔 수 있는 사람은 분명히 있습니다. 이제 다음은 해커톤에서 그들이 실제로 회사 문제를 풀어내는 빌더인지를 증명할 차례입니다.

AI와 함께 일하는 방식을 어떻게 측정하고 바꿔왔는지에 대해서는, 같은 블로그의 AI와 함께 일하는 법 시리즈와 한 명의 PM이 더 큰 임팩트를 만드는 방식에서도 이어집니다. 관심 있는 분은 함께 보시면 좋겠습니다.

부록: 회사에서 바이브코딩 워크샵을 연다면 명심해야 할 팁

2주 동안 직접 부딪히며 정리한 것들입니다.

1. 설치를 먼저 끝내세요. 도구가 손에 없으면 워크샵은 구경하는 시간이 됩니다. 저는 90% 이상을 목표로 잡았고, 앱 설치와 의존성 설치는 별개라는 점을 미리 챙겼습니다.

2. 이론은 최대한 줄이세요. 에너지는 이론에서 가라앉고 실습에서 올라옵니다. 모델 차이는 슬라이드로 설명하는 것보다 직접 두 모델로 같은 걸 시켜보게 하는 쪽이 빠릅니다.

3. 따라 치는 방식으로 시작하세요. 빈 화면에 알아서 써보라고 하면 막힙니다. 강사가 준 프롬프트를 그대로 쳐보게 한 다음 자유 실습으로 넘어가면 진입 장벽이 확 낮아집니다.

4. 자기 파일을 다루는 실습을 앞쪽에 두세요. "내 파일로도 되네?"를 깨닫는 순간이 전환점입니다. 데모를 구경하는 것과 자기 데이터로 돌려보는 것은 완전히 다릅니다.

5. 집중력 한계를 인정하세요. 사람의 집중은 보통 4시간이 한계였습니다. 5시간으로 늘리는 대신, 가장 중요한 내용을 앞 4시간에 몰아넣는 편이 낫습니다.

6. 매일 회고하고 다음 날 반영하세요. 커리큘럼을 고정하지 말고 하루 단위로 고쳐나가는 것이, 추천 지표를 끌어올린 가장 큰 한 가지였습니다.

7. 워크샵의 목표를 "교육"이 아니라 "사람 찾기"로 두세요. 끝까지 해내는 사람을 알아보고, 그 사람을 다음 단계로 연결하는 게 진짜 성과입니다.

TL;DR (EN): I'm on the team driving AI transformation at Afinit, where we've built an internal platform that pairs each employee with their own AI. Developers already use it daily; the hard part is everyone else. So we spent two weeks at our Gurgaon office running a vibe-coding workshop for 148 non-developers. The first week went entirely to installs — 136 of 148 (92%) before any session started — because a tool that isn't running on your own laptop turns a workshop into a spectator sport. Day one half-collapsed: theory drained the room while hands-on work revived it. After each batch we ran a 30-minute retro and emailed fixes to the instructor overnight. NPS held at +39 through the first batch, stayed flat at +40 with a tougher, higher-baseline crowd in the middle, then jumped to +83 in the third once we cut theory, moved hands-on work earlier, and hard-stopped at four hours. The real turning point came when people ran the tools on their own files and saw it actually worked, pushing "set it up now" intent from 17% to 69%. We found 12 champions and kicked off two follow-up projects. The lesson: AI transformation isn't about tool adoption — it's about changing how people work, and that happens when they build something themselves with someone there to unblock them.