이 글의 핵심
- 강의로는 판단이 바뀌지 않습니다. 직접 만들어 본 경험이 바꿉니다. 바이브코딩으로 사내 도구를 만들어 보면 견적서와 벤더의 말이 다르게 들립니다.
- 달라지는 것은 세 가지입니다. 외주 견적에서 어느 항목이 부풀려졌는지 보이고, 가능한 일과 어려운 일의 경계를 몸으로 알게 되고, 조직이 "어렵습니다"라고 할 때 뭘 되물어야 하는지 알게 됩니다.
- 살아남는 도구는 결정과 연결된 것뿐입니다. 만들 수 있어서 만든 도구는 만든 사람도 열지 않습니다. 교육의 수료 기준은 이 구분에서 나와야 합니다.
코드 없이 자연어로 AI에게 지시해 동작하는 소프트웨어를 만드는 방식. "이런 기능이 필요한데"라고 입력하면 코드가 나온다. 개발 전문가 없이도 업무 도구를 직접 만들 수 있게 됐다는 점에서 경영진의 관심이 높아진 방식이다.
강의가 판단을 바꾸지 않는다는 걸, 임원들도 직감합니다. 그런데도 AX 교육 예산 대부분이 강의와 콘텐츠로 들어갑니다. 직접 만들어 본 경험이 구체적으로 무엇을, 어떻게 바꾸는지 설명하기 어려웠기 때문입니다. 바뀐다는 걸 알아도, 어떻게 바뀌는지를 회의실에서 말하기 어려우면 예산이 그쪽으로 가지 않습니다.
저는 AI 코딩 도구를 써서 필요한 사내 도구를 직접 만들기 시작했습니다. 업무 자동화 스크립트부터 운영 관리 화면까지, 예전이라면 외주 견적을 받고 몇 달을 기다렸을 일들이 며칠 안에 손에 잡혔습니다. 개발이 쉬워졌다는 자랑이 아닙니다. 직접 만들어 본 뒤로 판단이 세 군데서 달라졌습니다.
직접 만들어 본 사람은 다른 질문을 합니다
외주 개발 견적서를 받으면 어느 항목이 부풀려졌는지, 어느 부분이 진짜 어려운 일인지 눈에 들어옵니다. 만들어 보기 전에는 총액만 봤습니다. 공수 추정이 합리적인지, 특정 기능이 실제로 그만큼 걸리는지 감이 없었습니다. 직접 부딪혀 보면 달라집니다. 며칠이면 되는 기능과, 몇 주가 필요한 기능이 왜 다른지를 몸으로 압니다.
가능한 일과 어려운 일의 경계도 달라집니다. AI 코딩 도구로 빠르게 되는 일과, 아직도 전문 개발자가 있어야 하는 일이 무엇인지는 한 번이라도 직접 만들어 봐야 압니다. AI를 붙이기 전에 업무 병목부터 봐야 하는 이유도 같은 맥락입니다. 직접 만들어 본 임원은 벤더가 "다 됩니다"라고 할 때 어느 부분부터 따져야 하는지를 알게 됩니다.
조직이 "어렵습니다"라고 할 때 반응도 달라집니다. 임원이 직접 만들어 봤다는 걸 알면, 조직도 막연하게 어렵다고만 말하지 못합니다. 어디가 왜 어려운지 구체적으로 말하게 됩니다. 기술 회의의 질이 그 순간 달라집니다.
| 상황 | 만들어 보기 전 | 만들어 본 뒤 |
|---|---|---|
| 외주 견적서 | 총액만 보임 | 항목별 난이도가 읽힘 |
| 벤더의 "다 됩니다" | 그런가 보다 | 어느 부분을 검증해야 하는지 앎 |
| 조직의 "어렵습니다" | 수용 | 어디가 왜 어려운지 되물음 |
같은 회의실에 앉아 있어도 말이 다릅니다. 그것이 직접 만들어 본 사람과 아닌 사람의 차이입니다.
처음 만들 도구는 작을수록 좋습니다
거창한 것부터 시작할 필요가 없습니다. 제가 권하는 첫 과제는 자기 손으로 매주 반복하는 일 하나입니다. 회의록을 정리해 배포하는 일, 여러 파일을 합쳐 보고서 형식으로 만드는 일, 특정 키워드가 올라오는지 모니터링하는 일. 며칠이면 됩니다. 만든 날부터 그 반복 작업에 쓰던 시간이 줄어듭니다.
이 과정에서 가장 어려운 부분은 코딩이 아닙니다. "무엇이 필요한지"를 정의하는 일입니다. 어떤 화면이 나와야 하는지, 어떤 순서로 동작해야 하는지를 자연어로 설명해야 합니다. 그 설명이 막힐 때, 자기 업무를 얼마나 명확하게 이해하는지가 드러납니다. 도구보다 이 정리가 더 큰 소득일 때도 있습니다.
완성도는 두 번째 문제입니다. 중요한 것은 한 바퀴를 도는 경험입니다. 무엇이 필요한지 정의해서 만들고, 써 보면서 고쳐 가는 왕복을 한 번 경험한 사람은 이후의 모든 기술 회의에서 다른 질문을 합니다. 해 본 적 없는 사람과 나란히 앉아 있어도 하는 말이 다릅니다.
살아남는 도구는 결정과 연결돼 있었습니다
솔직하게 말씀드리겠습니다. 저도 만들 수 있어서 만든 도구가 있었습니다. 시연 반응은 좋았습니다. 몇 주 뒤에 저부터 열지 않았습니다.
왜 열지 않았는지는 나중에야 알았습니다. 그 도구들이 해결한 것은 불편함이었습니다. 배치가 귀찮아서, 파일 정리가 번거로워서 만들었습니다. 그런데 배치를 오늘 바꿔야 하는지 말아야 하는지를 결정하는 데는 도움이 되지 않았습니다. 불편함을 줄이는 도구와, 결정을 돕는 도구는 다릅니다.
지금까지 살아남은 도구는 구체적인 결정과 연결된 것들입니다. 이번 주 배차를 조정해야 하는지, 정산 오류가 어느 건에서 발생했는지. 결정이 필요한 시점에 꺼내 볼 수 있는 도구입니다. 도구가 결정과 연결되지 않으면 조용히 쓰이지 않게 됩니다. 만든 사람도 열지 않는 도구를 조직이 쓸 이유가 없습니다.
그래서 저는 만들기 전에 하나를 먼저 확인합니다. "이 도구가 없으면 지금 어떤 결정이 더 어려워지는가." 그 질문에 답이 없으면, 만들어도 몇 주 뒤에는 열리지 않을 가능성이 높습니다.
수료 기준을 바꾸면 교육의 산출물이 달라집니다
이 경험에서 AX 교육 설계의 기준이 하나 생겼습니다. 강의 비중을 줄이고 제작 비중을 늘리는 것입니다. 수료 기준을 "과정 이수"에서 "자기 업무의 도구 하나를 직접 만들어 왔는가"로 바꾸는 겁니다. 임원부터 예외가 없어야 합니다.
만들어 온 도구의 완성도는 중요하지 않습니다. 만들어 보는 과정에서 생긴 판단력이 진짜 산출물입니다. 어설프더라도 직접 돌아가는 것을 만들어 온 사람은 다음 기술 회의에서 다른 질문을 합니다. 발표 자료만 가져온 사람과는 다른 자리에 서 있는 겁니다.
보안과 품질 걱정이 따릅니다. 맞는 걱정이고, 선을 그어야 합니다. 직접 만드는 것은 자기 업무의 보조 도구까지입니다. 핵심 시스템과 고객 데이터가 흐르는 시스템은 전문가 영역입니다. 무엇을 입력해도 되는지 데이터 기준을 먼저 정하고 시작해야 합니다. 이 선 안에서 직접 만들어 본 임원이 늘어날수록 회사는 안전해집니다. 무엇이 위험한지 아는 사람이 결정 가까이에 있기 때문입니다.
우리 회사에 지금 던질 질문이 있습니다
우리 회사 임원 중 AI로 업무 도구를 직접 만들어 본 사람이 몇 명입니까. 가장 최근 AX 교육에서 참가자가 실제로 만들어 온 것은 무엇이었습니까.
두 번째 질문에 답이 없다면, 교육에서 가져온 것이 판단력인지 이수 기록인지 따져볼 만합니다. 다음 교육 공지에는 어떤 결과물을 요구하시겠습니까. 도구보다 판단이 먼저라는 이야기는 경영진이 가장 많이 하는 착각에서 이어집니다.
임원이 AI를 일상 업무에서 직접 써야 하는 이유와 어디서부터 시작할 수 있는가 AI를 직접 쓰는 임원과 보고로만 받는 임원의 판단이 달라지는 지점에서 이어집니다.
경영진이 AI로 직접 만든 도구를 팀이 쓰고 있는데 나중에 어떻게 관리해야 하나 경영진이 AI로 만든 도구는 그 경영진이 없으면 멈춥니다에서 이어집니다.

