Insights
현장에서 검증한 데이터·AI 활용 인사이트를 나눕니다.
24시간 대신 일해주는 AI가 나오기 시작했습니다. 다들 '나 대신 알아서 24시간 돌아가면 좋겠다'고 말하죠. 그런데 왜 24시간을 원하는지 되물어보면, 상당 부분은 '일을 정의하는 수고를 건너뛰고 싶다'입니다. 알아서 해줘, 라는 마음이요. 문제는 24시간 자율이 정의를 덜 요구하는 게 아니라 더 요구한다는 겁니다. 24시간은 증폭기라서, 정의 안 한 것을 24배로 키웁니다.
AI가 오랫동안 미뤄둔 숙제를 하나 풀어줬습니다. '일단 다 모아둬라, 언젠가 쓴다' — 그 언젠가를 진짜로 데려온 거죠. 이제 쌓아둔 데이터 더미를 통째로 AI에게 넘길 수 있게 됐습니다. 그래서 넘겨봤더니, 못 씁니다. 문제는 데이터의 양이 아니었습니다. 모을 때 아무도 한 줄을 안 적어둔 거였죠. 그 한 줄은 나중에 복원되지 않습니다.
AI에게 일을 시켰더니, 준비 단계에서 제가 열어놓고 작업하던 소프트웨어를 그냥 종료시켰습니다. 저장 안 한 작업이 통째로 날아갔죠. 파일을 지우라고 시킨 적은 없습니다. 파일도 안 지워졌고요. 위험한 건 제가 시킨 일이 아니라, 그 일에 딸려온 부수효과였습니다. 그래서 위임의 상한선은 하나가 더 있습니다 — 되돌릴 수 있는 만큼만 맡길 수 있습니다.
요즘 '프롬프트 엔지니어링은 끝났다, 이제 한 줄이면 된다'는 말이 넘칩니다. 반은 맞고 반은 함정이에요. 그 한 줄이 데모처럼 작동하는 건, 수면 아래에 누군가 시스템 프롬프트·맥락·스키마·도구·루프를 다 깔아놨기 때문입니다. 프롬프트가 짧아진 게 아니라, 복잡함이 안 보이는 곳으로 옮겨간 겁니다. 부러워할 건 한 줄이 아니라, 그 밑의 구조예요.
구글 시트에서 받은 CSV를 엑셀로 더블클릭해서 열고, 고치고, 저장했습니다. 그 사이 한글 398자가 사라지고, 반복 횟수가 날짜로 바뀌고, 쉼표가 먹혀 표의 뼈대가 무너졌습니다. 더블클릭은 파일을 '여는' 게 아니라 추측해서 해석하고 자동으로 바꾸는 일이었고, 저장은 그 추측을 원본에 확정하는 일이었습니다. 깨진 건 연 순간이지만, 죽은 건 저장한 순간이었어요.
AI 코치는 6주치 기록을 분석했다고 자신 있게 말했습니다. 실제로 넘어간 건 세션 한 번 반이었습니다. 에러도 경고도 없었어요. 잘린 건 답이 아니라 근거였고, 근거는 화면에 나오지 않습니다. 붙여넣던 시절엔 최소한 내가 무엇을 줬는지 알았습니다. 연결해두는 순간, 아무도 모릅니다.
AI가 찾아온 근거는 한 점 흠이 없었습니다. 날짜도 장소도 인용 문구도 맞았고, 매체 여러 곳이 교차 확인해줬습니다. 다만 그 사실이 이미 뒤집혀 있었을 뿐입니다. 검색은 '그 일이 있었다'를 찾아주고, '그 뒤에 취소됐다'는 따로 물어야만 찾아줍니다.
차세대 모델이 하네스를 먹어치운다는 전망이 업계에 퍼지고 있습니다. 방향은 맞지만, '무용론'은 과장이고 '딸깍이면 끝'은 함정입니다. 껍데기가 벗겨질수록 남는 일은 오히려 더 어려워집니다.
자동검사 네 겹을 전부 통과하고도 결과물은 깨져 있었습니다. 통과는 맞다는 뜻이 아니라, 내가 물어본 것만 맞다는 뜻입니다. 한 번 데인 결함은 주의력이 아니라 장치로 막고, 그 장치가 진짜 작동하는지까지 시험해야 합니다.
낯선 양식이나 처음 보는 문법 앞에서 우리는 반사적으로 '규칙부터 배워야지' 합니다. 그런데 그 규칙은 기계가 이미 완벽히 아는 것이라, 사람이 머리에 넣을 이유가 없습니다. 형식을 외우는 대신 AI에게 정답 예시를 받아 모양만 복제하면 됩니다. 배울 것과 안 배울 것이 바뀌었을 뿐입니다.
AI 결과가 아쉬우면 우리는 모델을 의심합니다. 더 좋은 걸로 바꾸면 나아지겠지 하고요. 그런데 가장 앞선 모델조차 지식은 이미 몇 달 전에 멈춰 있고, 같은 모델이라도 프롬프트 형식만 바꾸면 성능이 최대 76점까지 갈린다는 연구가 있습니다. 결과를 가르는 건 어떤 모델이 아니라, 어떻게 쓰느냐입니다.
코딩을 못 하는데 크롤링을 어떻게 하냐는 말은 전제부터 틀렸습니다. 필요한 건 코드를 아는 게 아니라, AI에게 정확히 무엇을 시킬지 아는 것이니까요. 개발자도구로 어디를 짚고, 원하는 동작을 말로 시키고, 막히면 에러를 붙여넣어 고칩니다. 외운 코드 한 벌은 사이트가 바뀌면 죽지만, 받아내는 능력은 어느 화면에서도 다시 통합니다.
같은 회사, 같은 도구, 같은 교육. 그런데 어떤 팀은 AI로 확 달라지고 어떤 팀은 제자리입니다. 흔히 '잘하는 사람이 있어서'라고 하지만, 못 쓰는 팀에도 잘하는 사람은 있습니다. 진짜 차이는 그 한 사람의 방식이 팀 전체로 퍼지느냐 — 개인기로 흩어지느냐, 팀의 자산이 되느냐입니다.
두꺼운 보고서나 긴 회의록을 통째로 붙여넣고 정리해 달라고 했더니, AI가 앞부분을 빼먹거나 엉뚱한 데를 요약합니다. AI가 게을러서가 아니에요. AI에게는 한 번에 볼 수 있는 창이 정해져 있어서, 통째로 밀어넣으면 뒤가 잘리고 가운데가 흐려집니다. 잘 쓰는 사람은 통째로 던지지 않고 필요한 조각을 골라 줍니다. 갈리는 건 AI 성능이 아니라, 무엇을 창에 넣을지 고르는 손입니다.
애자일, 디자인씽킹, 그리고 지금은 AI. 조직은 도입이 끝나면 '성공했다'고 체크하지만, 진짜 성공은 그 다음에 결정됩니다. 아무리 좋은 기법도 기업문화에 뿌리내려야 살아남고, 그 문화를 만들 수 있는 건 결국 리더의 의지 하나입니다.
한 달 전 교육했던 회사를 다시 찾아 물어보면, 배운 걸 실제로 쓰고 있는 분은 드뭅니다. 교육장에서 눈을 반짝이던 그 사람들이요. 담당자는 '왜 다음 단계로 못 넘어갈까' 묻지만, 진짜 문제는 다음 단계가 아닙니다. 첫 단계가 조직에 뿌리내리지 않은 거예요. 정착은 교육이라는 하루가 아니라, 교육이 끝난 뒤에 남는 구조에서 옵니다.
어제 한참을 다듬어 마음에 들게 뽑아낸 그 프롬프트, 오늘 또 0에서 치고 있지 않으신가요. AI는 어제의 당신을 기억하지 못하니, 기억하는 일은 사람의 몫으로 남습니다. 잘 된 명령을 흘려보내지 않고 재사용할 수 있게 쌓아 두는 것 — 요즘 쏟아지는 에이전트 도구들이 자동화하려는 게 바로 그 습관입니다.
팀에 AI를 깔았는데도 일이 기대만큼 빨라지지 않습니다. 고장이 아닙니다. AI가 빠르게 만든 건 '실행'(손으로 만드는 일)이고, 정작 일의 시간을 쥔 건 무엇을 할지 정하고(정의) 맞는지 확인하는(검증) 과정이기 때문입니다. 실행은 원래 병목이 아니었습니다.
AI 요금이 '머릿수 × 월정액'에서 '무엇을 얼마나 시켰나'로 옮겨가고 있습니다. 종량 과금이 개발자 도구를 넘어 기본 오피스 환경으로 내려오면서, 비용을 가르는 건 어떤 도구를 샀느냐가 아니라 일을 어떻게 정의했느냐가 됐습니다. 그래서 비용 절감의 손잡이도 구매에서 일하는 방식으로 옮겨갑니다.
AI에게 '우리 업종 AI 도입 사례 좀 찾아줘' 하면 자꾸 뻔한 일반론만 돌아옵니다. AI가 무능해서가 아니라 질문의 해상도가 낮아서예요. 알맹이는 한 칸 더 좁혀 — 업종이 아니라 기업명까지 — 물어야 나옵니다. 검색을 AI에 맡길 때 진짜 갈리는 건 검색 실력이 아니라 무엇을 찾는지 내가 먼저 쥐고 있느냐입니다.
엑셀은 능숙하게 다루는데 그 표를 AI에 던지면 자꾸 헛돕니다. 이유는 하나예요 — AI는 서식이 아니라 데이터를 보기 때문입니다. 화려한 표를 만드는 능력과, AI가 읽을 수 있는 데이터를 건네는 능력은 다른 일입니다. 후자가 AI 시대의 데이터 리터러시입니다.
AI가 SQL을 대신 짜주는 시대, SQL이 필요 없어진 게 아니라 필요한 능력이 바뀌었습니다 — 짜는 능력에서, AI가 짠 쿼리를 읽고 검증하는 능력으로. SQL은 몰라도 되는 엔진룸 언어가 아니라, 그 결과가 곧 내 보고서의 숫자가 되는 운전석 언어입니다.
AI가 길게 답할수록 사람은 덜 읽고, 안 읽은 구간으로 오류가 빠져나갑니다. 카르파시의 처방은 간단합니다 — 답을 텍스트로 노려보지 말고, 눈으로 검증되는 형태로 바꿔서 보라는 것. 검증력이 곧 위임의 한계선입니다.
AI는 에러 없이 ‘완료’를 보고하고도 결과물은 깨뜨려 놓습니다. 코드를 못 읽는 비개발자가 자동화 결과를 검증하는 법은 딱 하나 — 글자가 아니라 그림으로, 끝까지 눈으로 보는 것입니다.
직원들에게 무료 AI를 쓰라고 했는데 왜 다들 어딘가에서 막힐까요. 무료 도구만으로 실습 과정을 설계하다 알게 된 건, 무료의 벽은 ‘기능 잠금’이 아니라 더 교묘한 자리에 박혀 있다는 사실이었습니다.
교육장에서 가장 자주 받는 불안한 질문 하나 — 저는 RAG가 뭔지도 모르는데, AI를 잘 쓴다고 할 수 있나요. 결론부터 말씀드리면, 그 세 단어는 당신이 외울 말이 아닙니다. 그건 엔진룸의 언어고, 당신은 운전석에 앉아 있습니다.
한 교육생이 그러더군요. 두꺼운 AI 책을 끝까지 읽었는데, 덮고 나니 손에 남는 게 없었다고. 그 책이 부실해서가 아닙니다. 도구를 친절하게 다 알려준 책일수록, 정작 일하는 법은 비어 있습니다.
같은 강의실, 같은 강사, 같은 세 시간. 그런데 끝나고 나면 누구는 그대로고 누구는 바뀝니다. 차이는 똑똑함이 아닙니다. 강의실에 무엇을 들고 들어왔느냐입니다.
“AI 좀 쓰세요?”라는 질문에 돌아오는 두 대답 — “전 아직 초보예요”와 “그거 그냥 쓰면 되는 거 아녜요?” — 은 정반대처럼 보이지만 같은 실수를 합니다. 둘 다 잘못된 자로 자기 실력을 잽니다. 활용능력을 재는 진짜 자는 따로 있습니다.
비개발자 AI 도입의 결론은 늘 '검은 터미널 말고 쉬운 GUI로 가자'입니다. 절반은 맞는 말입니다. 그런데 그 GUI를 매끄럽게 돌릴 하드웨어가 직원 손에 있다는 전제는, 현장에서 자주 무너집니다. 인터페이스의 모양 아래 숨은 두 개의 진짜 질문.
AI를 한 번 써보고 '별로네요'라고 판단하는 분이 많습니다. 하지만 첫 답은 제출물이 아니라 초안입니다. 그리고 그 초안을 끌어올리는 건 '다시' 버튼이 아니라, 무엇이 어긋났는지 짚어내는 조율입니다.
옵시디언에 노트를 쌓기만 하면 그냥 폴더입니다. 지식은 양으로 쌓이지 않고, 연결로 자랍니다.
데이터 분석은 의사결정을 위한 것이라고 배웁니다. 맞는 말입니다. 그런데 현장에서 한 겹이 빠져 있습니다. 결정은 사람이 내리고, 사람을 움직이는 마지막 일은 설득이니까요.
AI 잘 쓰는 법을 묻는 분들은 흔히 명령어나 프롬프트 문법부터 찾습니다. 새 프로그래밍 언어를 배우듯이요. 그런데 AI는 정복하는 기계가 아니라, 일을 맡기는 동료에 가깝습니다.
AI에게 '아까 말했잖아'는 통하지 않습니다. AI는 기억하는 게 아니라 매번 처음부터 다시 읽습니다. 그 '다시 읽는 창'에는 크기가 있고, 이걸 모르면 AI와의 대화가 계속 어긋납니다.
프롬프트 기법을 외우기 전에, 자기가 풀려는 문제를 정의할 수 있는지부터 봐야 합니다. 현상을 던지면 범용 답이 오고, 문제를 정의하면 날카로운 답이 옵니다.
업계는 '프롬프트 엔지니어링은 끝났다'고 말합니다. 저는 정반대로 봅니다. 도구가 똑똑해지고 일을 알아서 할수록, 무엇을 시킬지 명확히 말하는 능력은 오히려 더 귀해집니다.
AI에게 일을 시키려면 지식을 건네야 합니다. 그런데 당신의 지식은 AI가 읽을 수 있는 곳에 있습니까.
AI가 새로운 문제를 만든 게 아닙니다. 우리가 자기 업무를 구조화해 설명하지 못했다는, 원래 있던 문제를 드러냈을 뿐입니다.
에이전틱 AI가 노코드 자동화 도구를 끝냈다는 말 앞에서. 개인이라면 대체로 맞지만, 기업 현장이라면 너무 이른 결론입니다.
ChatGPT냐 Gemini냐 Claude냐. 기업 교육 현장에서 도구를 고를 때 가장 먼저 보는 것은 도구의 성능이 아니라, 그 회사가 이미 무엇을 쓸 수 있는가입니다.
AI로 뭔가 만들다 막히면 대부분 거기서 멈춥니다. 막힘을 뚫는 힘은 더 똑똑한 도구가 아니라, 막히기 전에 만들어 둔 작업 구조에서 나옵니다.
AI는 대단하다는데 막상 해보면 별것 없다고 느낀다면. 실망의 원인은 도구가 아니라, 우리가 AI에 거는 기대의 방향에 있습니다.