AX 도입 파일럿 95%가 실패하는 자리는 모델이 아니라 구두로 끝난 회의다

6월 첫 주에 조직 개편 공지가 올라왔다. 명분은 AI 대응이었다. 그리고 얼마 지나지 않아 사내 AI 업무 에이전트가 열렸다. 사내 문서와 위키, 이슈 트래커, 메신저, 코드 저장소를 한데 모아 지식 베이스를 만들었고 거기 붙어서 답한다고 했다. 나는 이걸 보고 좀 들떴다. 넉 달째 내 블로그를 에이전트로 굴리고 있었으니까, 이 정도면 나한테는 그냥 익숙한 물건이 하나 더 생긴 거라고 생각했다.

제일 먼저 시킨 게 주간보고였다. 한 주 동안 내가 남긴 것들을 수집해서 위클리를 쓰게 했다.

잘 됐다. 예상보다 잘 됐다. 화요일에 처리하고 완전히 잊어버린 이슈 하나가 목록에 올라와 있었다. 내가 손으로 썼으면 그건 100% 빠졌을 항목이다.

그런데 같은 도구를 받은 옆자리는 아무것도 못 뽑았다. 실패한 게 아니라 결과가 거의 비어 있었다. 처음엔 프롬프트를 잘못 넣었나 싶었는데 아니었다. 그 사람의 한 주가 어디에도 적혀 있지 않았을 뿐이다. 회의는 했고 결정도 났고 일도 돌아갔는데, 그게 전부 말로 끝나 있었다. 에이전트 입장에서는 수집할 대상 자체가 없었던 것이다.

그때부터 AX라는 단어가 좀 다르게 보이기 시작했다.

6월에 세 그룹이 동시에 같은 말을 했다

내 회사만의 일이 아니었다. 2026년 6월, 국내 주요 그룹들이 거의 같은 시기에 AX를 경영 전면에 내걸었다는 보도가 쏟아졌다.

삼성은 ChatGPT와 Gemini, Claude 같은 외부 생성형 AI를 계열사 전반에 공식 도입하고 임원 대상 집중 교육에 들어갔다. 자체 모델로 가두는 대신 성능 좋은 걸 그냥 쓰는 개방 노선이다. SK는 6월 11일부터 사흘간 이천에서 포럼을 열고 최태원 회장과 경영진이 AX 전략을 집중적으로 다뤘는데, 민감 데이터는 자체 모델과 사내 플랫폼으로 통제하고 범용 영역만 외부 모델을 쓰는 내재화 쪽에 무게를 뒀다. LG는 구광모 회장이 AX를 핵심 과제로 못박았고 자체 모델 ExaOne을 중심에 두되 일부 계열사가 글로벌 모델을 병용하는 하이브리드로 간다(메트로서울, KB의 생각).

세 회사가 노선은 다른데 던지는 문장이 똑같았다. 일하는 방식을 바꿔라.

시점이 이렇게 겹친 데는 이유가 있어 보인다. 도구 쪽이 먼저 바뀌었다. 작년까지 사내에서 AI를 쓴다는 건 대체로 탭 하나를 열어놓고 붙여넣는 일이었다. 그 방식에서는 회사 문서가 어떻게 정리돼 있든 상관이 없다. 어차피 필요한 걸 내가 손으로 퍼 날랐으니까. 그런데 모델과 외부 도구를 잇는 규격이 공개 표준으로 자리를 잡으면서 커넥터 생태계가 생겼고, 이제 문서 저장소와 메신저, 이슈 트래커에 직접 붙는다. 모델이 업무 시스템 안으로 들어온 것이다.

붙일 수 있게 되니까 그동안 안 보이던 게 보인다. 붙였는데 가져올 게 없다는 것. 이 글은 대체로 그 이야기다.

한 발 앞서 움직인 곳도 있다. SK C&C는 2025년 5월 13일에 사명을 SK AX로 바꾸겠다고 발표하고 그해 6월 1일부터 적용했다. AX는 Artificial Intelligence Transformation의 약자다. 2027년까지 전사 생산성을 30% 이상 올리고 10년 안에 글로벌 AX 서비스 톱10에 들겠다는 목표를 같이 내걸었다(전자신문). 회사 이름을 통째로 버즈워드로 바꾼다는 게 어떤 의미인지는 다음 편에서 따로 다루려고 한다. 다만 30%라는 검증 가능한 숫자를 붙였다는 점은 기억해둘 만하다.

여기까지가 뉴스다. 문제는 이 뉴스를 읽고 회사가 뭘 해야 하느냐인데, 여기서부터 자료가 급격히 부실해진다.

95%라는 숫자를 방패로 쓰면 안 되는 이유

AX 이야기가 나오면 거의 반드시 따라 나오는 숫자가 있다. MIT의 "The GenAI Divide" 보고서가 낸 95%다.

내용은 이렇다. 경영진 인터뷰 52건, 리더 설문 153명, 공개된 배포 사례 300건을 분석했더니 생성형 AI 파일럿의 95%가 측정 가능한 손익 영향을 내지 못했다. 300억에서 400억 달러가 이미 들어간 상황에서 나온 결과다. 조직의 80% 이상이 ChatGPT나 Copilot을 파일럿했고 40% 가까이가 배포했다고 답했는데, 대부분 개인 생산성 향상에 그치고 사업 성과로는 이어지지 않았다. 도입률은 높은데 전환율은 낮다는 것이다(Fortune).

원인 진단이 흥미롭다. 모델 품질 문제가 아니라 학습 격차라고 했다. 도구가 피드백을 보존하지 못하고 맥락에 적응하지 못하며 시간이 지나도 나아지지 않는다는 것이다. 그리고 전문 벤더한테 사면 67% 성공하는데 내부에서 직접 만들면 22% 성공한다는 대비도 있다. 조직들은 체계적으로 낮은 확률 쪽을 고른다고 지적했다(Forbes).

그런데 이 숫자를 그대로 쓰면 안 된다.

비판이 만만치 않기 때문이다. 성공 정의가 지나치게 좁다는 게 핵심 지적이다. 파일럿 단계를 넘어선 배포에 측정 가능한 KPI가 붙고 파일럿 6개월 후에 손익 영향이 잡혀야 성공으로 셌는데, AI 도입 투자 회수는 보통 몇 년 단위로 본다. 6개월 창은 너무 짧다. 효율 개선이나 비용 절감, 고객 이탈률 감소, 리드 전환율 같은 영향도 계산에서 빠졌다. 이해 상충을 밝히지 않았다는 문제 제기도 나왔다. 한 비판자는 이 연구에 무게를 두지 말라고, 통계적으로 유효한 물건이 아니라고 말했다(Marketing AI Institute).

내가 이 반론을 굳이 같이 적는 이유가 있다. 95%를 인용하는 순간 글이 편해지기 때문이다. 남들이 다 실패했다는 숫자 하나면 내 주장이 저절로 무거워진다. 그런데 그렇게 쓰는 순간 이 글도 AX를 팔러 다니는 자료들과 같은 종류가 된다. 그쪽도 정확히 같은 방식으로 이 숫자를 쓴다.

그래서 95%는 결론이 아니라 질문으로만 쓰려고 한다. 파일럿은 도는데 성과가 안 나오는 자리가 어디냐는 질문이다. 그건 내가 옆자리에서 직접 봤다.

같은 팀 안에서 이미 벌어져 있는 격차

주간보고로 돌아가자.

내 팀에는 위클리를 에이전트로 쓰는 사람이 있고 손으로 쓰는 사람이 있다. 처음엔 이걸 취향 차이나 부지런함 차이로 봤다. 아니었다. 결과물의 성질이 아예 달랐다.

자동으로 수집해서 쓰면 내가 깜빡한 것까지 다 올라온다. 보고서에 담기는 범위가 그 주에 남은 기록의 범위와 같아진다. 손으로 쓰면 기억나는 것만 올라온다. 보고서에 담기는 범위가 그 주에 기억하는 범위와 같아진다. 그리고 사람은 자기가 한 일의 상당 부분을 금요일 오후에 기억하지 못한다. 나도 그렇다. 화요일 그 이슈가 증거다.

그 이슈가 왜 빠졌을지 생각해보면 이유가 시시하다. 큰일이 아니었기 때문이다. 30분 정도 붙잡고 있다가 원인을 찾아서 고치고 코멘트 하나 남기고 넘어갔다. 그 주에 훨씬 크고 시끄러운 일이 두어 개 있었으니 금요일에 위클리를 쓰면서 그게 떠오를 리가 없다. 그런데 자동 수집은 크고 작음을 안 따진다. 그냥 그 주에 내 이름으로 남은 흔적을 다 긁어온다. 티켓 상태 변경, 커밋 메시지, 스레드에서 결론난 대화. 사람이 중요도로 필터링하는 자리에서 기계는 필터를 안 건다.

그게 이 도구의 장점인지 단점인지는 좀 애매하다. 안 중요한 것까지 다 올라와서 지저분해지는 건 맞다. 그런데 위클리에서 중요도 판단은 어차피 읽는 사람이 한다. 내가 미리 걸러서 올리면 그건 필터링이 아니라 그냥 소실이다.

이건 속도 차이가 아니다. 누락률 차이다. 두 사람이 똑같이 일했는데 한쪽 기록에는 열두 건이 남고 다른 쪽에는 일곱 건이 남는다. 남은 다섯 건은 사라진 게 아니라 안 보이게 된 것이다. 평가할 때도 안 보이고, 다음에 비슷한 문제가 왔을 때 참고할 때도 안 보이고, 무엇보다 다음 주에 에이전트가 수집하러 왔을 때 안 보인다.

한 가지 짚어둘 게 있다. 손으로 쓰는 쪽이 게으른 게 아니다. 오히려 시간은 그쪽이 더 쓴다. 40분 앉아서 한 주를 되짚는 사람과 5분 만에 초안을 받아서 다듬는 사람 중에 노력을 더 들인 쪽은 앞이다. 그런데 결과물은 뒤가 낫다. 노력과 결과가 뒤집히는 구간이라 더 고약하다.

그리고 이 격차는 한 층 위에서 그대로 반복된다.

팀장 레벨을 보면 팀원들이 올린 위클리를 일일이 읽고 분석해서 팀 보고서를 쓰는 사람이 있고, AI한테 정리를 시키는 사람이 있다. 여기서도 결과가 갈리는데, 갈리는 방식이 아래층과 다르다.

아래층 격차가 위층에서 곱해지기 때문이다.

팀원 위클리가 촘촘하면 팀장이 AI로 정리했을 때 실제로 쓸 만한 게 나온다. 팀원 위클리가 부실하면 팀장이 아무리 좋은 도구를 써도 요약할 대상이 없다. 부실한 일곱 줄을 요약하면 더 부실한 세 줄이 나올 뿐이다. 반대로 팀원 기록이 좋은데 팀장이 손으로 읽고 있으면 그건 그것대로 병목이다. 팀원 여덟 명이 열두 건씩 남긴 아흔여섯 건을 사람이 매주 소화할 수는 없다.

그러니까 조직 전체가 AI에서 뽑아낼 수 있는 양의 상한은 가장 아래층의 기록 밀도에서 결정된다. 위에서 아무리 좋은 플랫폼을 깔아도 이 상한은 안 올라간다.

에이전트는 적어둔 것만 수집한다

내가 회사 에이전트를 보고 제일 인상 깊었던 건 모델이 아니라 설계 하나였다. 원천 문서의 권한 관리를 그대로 상속해서 동작한다는 점이다.

이게 왜 중요하냐면, 사내 지식 베이스를 만들 때 가장 흔한 실패가 여기서 나오기 때문이다. 문서를 다 긁어모아 하나의 인덱스로 만들면 검색은 잘 되는데 권한이 뭉개진다.

구체적으로 어떻게 깨지는지 보면 좀 무섭다. 인사 관련 문서나 아직 공개 안 된 조직 개편안, 특정 팀만 보는 예산 자료가 다른 문서들과 같은 인덱스에 들어간다. 그러면 내가 "다음 분기 조직 어떻게 되냐"고 물었을 때 시스템은 그 문서를 근거로 답을 만들어버린다. 원본 파일에는 내 접근 권한이 없는데 답변에는 그 내용이 들어 있다. 파일을 못 열었으니 감사 로그에도 안 남는다.

더 미묘한 건 요약이 권한 검사를 통과해버린다는 점이다. 인덱스에 들어가는 순간 원문은 조각이나 벡터로 바뀌고, 거기서 생성된 답변은 원문과 다른 새 텍스트가 된다. 원문에 걸어둔 권한이 그 새 텍스트에는 안 붙는다. 문서 하나하나에는 자물쇠가 있는데 그걸 녹여 만든 물건에는 없는 것이다.

제목만 떠도 문제인 경우까지 있다. 검색 결과에 "2026년 3분기 OO본부 통합 검토안" 같은 게 목록으로만 노출돼도 그 자체가 정보다. 내용은 못 봤으니 유출이 아니라고 하기가 어렵다.

원천의 권한을 그대로 상속하면 사람마다 같은 질문에 다른 답을 받는다. 옆자리는 답을 받는데 나는 모른다고 나온다. 불편하고 가끔 답답한데 그게 맞는 동작이다.

특정 조직부터 순차로 여는 것도 같은 맥락이다. 전사에 한 번에 열고 위 같은 사고가 나면 되돌릴 방법이 없다. 이미 읽은 사람 머리에서 지울 수는 없기 때문이다. 소수 조직에서 몇 달 굴려보면 어떤 문서가 인덱스에 잘못 들어갔는지, 어떤 질문 형태가 권한을 우회하는지가 실제 사용 로그로 드러난다. 굼뜬 게 아니라 순서를 아는 것이다.

그런데 설계가 아무리 정교해도 넘지 못하는 선이 있다. 수집 대상에 없는 건 못 가져온다.

위키에 없고 이슈 트래커에도 없고 메신저 로그에도 없는 결정은 존재하지 않는 결정이다. 회의실에서 셋이 합의하고 각자 자리로 돌아가 각자 실행한 그 결정은, 3주 뒤에 누가 왜 이렇게 됐냐고 물었을 때 아무도 근거를 못 댄다. 사람 기억으로는 세 사람이 서로 다른 버전을 말한다. 에이전트한테 물으면 아예 모른다고 한다.

AX 도입 논의가 대부분 모델 선택에서 시작하는데, 실제로 먼저 깨지는 건 이 지점이다. 어떤 모델을 쓸지는 나중에 바꿀 수 있다. 지난 분기에 말로 끝낸 회의는 소급해서 못 적는다.

적어뒀는데 못 찾으면 안 적은 것과 같다

여기까지가 쓰는 쪽 이야기인데, 반대쪽 절반이 남아 있다.

사내 게시판이나 메신저에 다 적어놨다고 해도 이력이 길어지면 못 찾는다. 스레드가 채널 안에 묻히고, 어떤 글이 어떤 스레드에 달려 있는지 확인이 안 된다. 검색이 있긴 한데 그건 키워드를 알아야 쓴다. 3개월 전 그 결정을 우리가 뭐라고 불렀는지 기억이 안 나면 검색어 자체를 못 만든다. 같은 주제가 세 개 채널에 흩어져 있고 각각 결론이 조금씩 다른 경우도 흔하다. 어느 게 최종인지 판단할 근거가 그 안에 없다.

이걸 그냥 불편한 정도로 넘기면 안 된다. 업무 효율이 깎이는 자리이기 때문이다.

찾는 비용이 다시 묻는 비용보다 커지는 순간이 있다. 20분 스크롤할 바에는 옆자리에 물어보는 게 빠르다. 그래서 묻는다. 합리적인 선택이다. 그런데 그렇게 받은 답변은 또 스레드 어딘가에 묻히거나 아예 말로만 오간다. 6개월 사이에 같은 질문이 네 번 반복되고 네 번 다 새로 답변된다.

더 비싼 건 다시 결정하는 쪽이다. 이미 검토하고 기각한 안을 반년 뒤에 다시 올린다. 기각 사유가 어딘가에는 분명히 있는데 아무도 못 찾으니까 처음부터 다시 논의한다. 회의를 한 번 더 하고 같은 결론에 도달한다. 운이 나쁘면 다른 결론에 도달한다. 그러면 앞의 결정과 뒤의 결정이 공존하면서 실무자가 둘 다 참고하는 상태가 된다.

그러니까 찾기 어려운 기록은 사람을 구두로 되돌린다. 앞에서 말한 문제로 정확히 되돌아오는 것이다. 안 적어서 못 찾고, 못 찾으니까 물어보고, 물어보니까 또 안 적힌다. 이 고리가 한 바퀴 돌 때마다 조직의 기록 밀도가 조금씩 낮아진다.

사내 지식 베이스가 실제로 파는 게 이거다. 문서를 대신 써준다는 기능이 눈에 띄지만, 조직 입장에서 더 큰 건 통합 검색 쪽이다. 흩어진 채널을 가로질러서 "그때 그 결정 왜 그렇게 났지"에 답할 수 있으면 위 고리가 끊긴다. 나도 회사 에이전트에서 제일 자주 쓰는 게 이 용도다. 반년 전 스레드를 내가 직접 찾으려면 못 찾는데, 물어보면 찾아준다.

다만 조건이 하나 붙는다. 답만 주고 출처를 안 주면 못 쓴다. 어느 문서 어느 스레드에서 나온 이야기인지 링크가 같이 와야 확인이 되고, 확인이 돼야 그 답을 근거로 다음 결정을 내릴 수 있다. 출처 없는 요약은 편하긴 한데 그걸 회의에 들고 갈 수는 없다.

지라에 다 등록하라는 말은 20년째 안 먹혔다

구두로 나눈 대화를 근거자료로 남긴다는 건 새로운 이야기가 아니다.

자기가 하는 일은 전부 티켓으로 등록하고 시작하라는 지침, 어느 회사에나 있었다. 회의록을 남기라는 것도, 결정에는 근거를 붙이라는 것도, 합의는 문서로 확인하라는 것도 마찬가지다. 신입 교육에서 한 번은 듣는 말이고 그러고 나서 대부분 안 지켜지는 말이다. 실제로 그렇게 일하는 사람은 드물다. 나도 오래 안 그랬다.

이게 왜 20년 동안 안 먹혔는지는 산수를 보면 바로 나온다. 비용은 개인이 내고 이득은 조직이 가져갔기 때문이다.

티켓 하나 만들고 설명 쓰고 상태 옮기는 데 3분쯤 든다. 그 3분은 내 시간이다. 그렇게 쌓인 데이터로 만들어지는 건 진척 대시보드고 그건 위에서 본다. 내가 오늘 3분을 내면 다음 달에 누군가 보고서를 편하게 쓴다. 합리적인 개인이라면 안 한다. 안 하는 게 이상한 게 아니라 하는 게 이상한 구조였다.

그래서 강제를 붙여도 형식만 채워졌다. 티켓 없는 커밋을 막으면 "이번 주 작업"이라는 티켓 하나를 만들어놓고 한 달을 그 밑에서 산다. 감사를 돌리면 감사 전날에 몰아서 채운다. 규율로 사람을 이기려고 하면 대체로 진다.

달라진 건 규율이 아니라 그 산수다.

지금은 기록을 남긴 사람이 그 이득을 직접 가져간다. 3분을 내면 금요일에 40분을 아낀다. 그것도 더 정확한 결과물로 아낀다. 일하다 이슈가 터졌을 때 3주 전에 왜 이 설정을 이렇게 뒀는지 되짚을 수 있다. 평가 시즌에 내가 뭘 했는지 증명할 근거가 이미 쌓여 있다. 예전엔 이 셋이 다 막연한 미래의 편익이었는데 지금은 다음 주 금요일에 바로 돌아온다.

설득할 필요가 없어졌다는 게 제일 크다. 문서화가 왜 중요한지 설명하는 자료를 만들 필요가 없다. 위클리를 자동으로 받아본 사람은 그다음 주부터 알아서 티켓을 남긴다. 나도 그랬다.

요구 수준이 내려간 것도 같이 봐야 한다. 예전 문서화는 완결된 산출물을 요구했다. 회의록은 형식이 있어야 하고 티켓 설명은 남이 읽어도 이해되게 써야 했다. 그 부담이 진입장벽이었다. 지금은 파편이면 된다. 스레드에 남긴 두 줄, 커밋 메시지 한 줄, 티켓 코멘트에 붙인 링크 하나. 정리는 에이전트가 한다. 잘 쓰는 게 아니라 남기기만 하면 되는 쪽으로 기준이 내려왔다.

그래도 안 남기면 이제는 벌점이 실제로 붙는다. 자동화 레버리지를 통째로 못 받는다. 그리고 그 부실한 기록이 다음 주 입력으로 다시 들어간다. 격차가 매주 조금씩 벌어지는 게 아니라 이자가 붙는다.

MIT가 학습 격차라고 부른 것도 이 근처에 있다. 도구가 맥락을 보존하지 못한다는 진단이었는데, 조직이 애초에 맥락을 텍스트로 안 남기면 보존할 대상이 없다. 벤더를 바꿔도 안 고쳐진다.

솔직히 이 결론이 좀 김빠지긴 한다. 최신 에이전트 아키텍처 이야기를 기대했는데 결론이 티켓 남기라는 거면 누구라도 그럴 것이다. 나도 몇 번 다시 확인했다. 그런데 볼 때마다 같은 자리로 돌아왔다.

Klarna가 되돌린 지점

기록 이야기만 하면 반쪽이라, 반대 방향 사례도 하나 붙인다.

Klarna는 고객 응대를 AI로 대체하고 직원 700명 분의 일을 한다고 발표했다. 그러다 2025년 중반에 사람을 다시 뽑기 시작했다. CEO Sebastian Siemiatkowski는 효율과 비용에 너무 집중했고 결과는 낮은 품질이었으며 그건 지속 가능하지 않다고 말했다(Forbes).

완전 철회는 아니었다. 반복적인 대량 문의는 AI가 처리하고 에스컬레이션과 복잡한 건, 고가치 고객은 사람이 맡는 하이브리드로 갔다. 2026년 기준으로도 AI는 여전히 직원 853명 분의 일을 하고 연 6천만 달러를 절감할 전망이다(Entrepreneur).

여기서 볼 건 되돌렸다는 사실이 아니라 되돌린 계기다. CSAT와 NPS, 응대 후 설문이 방아쇠였다. 그전까지 보던 지표들은 평균을 기술하고 있었다. 평균 응답 시간, 평균 처리 건수, 평균 비용. 그 숫자들은 다 좋아 보였다. 피해는 꼬리에서 나고 있었다. 복잡한 건 하나를 못 풀어서 크게 화가 난 고객, 그 고객이 다시는 안 오는 것. 평균으로는 절대 안 잡힌다.

AX 도입 지표를 짤 때 이게 그대로 적용된다. 처리 시간이 얼마나 줄었냐만 세면 반드시 같은 함정에 빠진다. 잘 안 된 케이스가 어디에 몰려 있는지를 따로 봐야 한다.

내가 게이트를 만들었다가 464줄을 지운 이야기

거버넌스 이야기를 하려면 내 실패를 하나 꺼내야 한다.

이 블로그는 넉 달째 에이전트로 굴러간다. 2026년 4월 2일 첫 커밋을 찍었고 지금 커밋 65개, 스킬 21개에 SKILL.md 합계 2,697줄, 에이전트 6개, 훅 3개에 234줄이다. 글 한 편이 리서치에서 발행까지 가는 동안 여러 단계를 거치는데, 그중 하나가 AI 문체 검사였다.

여기에 게이트를 걸었다. 발행 스크립트가 검사 결과 파일에서 "판정: 합격"이라는 문자열을 grep 해서, 없으면 발행을 막았다. 코드로 품질을 강제한 셈이라고 생각했고 꽤 만족했다.

문제는 그 문자열을 누가 쓰느냐였다. 검사받는 에이전트가 직접 썼다.

검문소와 통행증 발급처가 같은 자리에 있었던 것이다. 몇 달 동안 게이트가 잘 돌아간다고 믿었는데, 사실은 자기 신고를 자동화해놓고 그걸 통제라고 부르고 있었다. 이걸 알아차렸을 때 좀 허탈했다. 정교하게 만들어놓은 게 정교하게 아무것도 안 하고 있었다.

왜 몇 달이나 못 알아챘는지가 더 고약하다. 가끔 실제로 막혔기 때문이다.

에이전트가 스스로 불합격을 적는 경우가 진짜로 있었다. 그러면 발행이 멈추고 나는 글을 고쳤다. 그 순간 게이트가 일한다는 증거로 보였다. 막힌 적이 있으니까 작동하는 거라고 생각한 것이다. 그런데 그건 검사가 엄격해서 막힌 게 아니라 그날 그 에이전트가 스스로에게 박했던 것뿐이다. 통과와 차단이 둘 다 같은 쪽에서 결정되고 있었으니 어느 쪽이 나와도 게이트의 성능에 대해서는 아무것도 말해주지 않았다.

점수까지 붙어 있어서 더 그럴듯했다. 14개 항목을 채점해서 총점을 내고 기준 미달이면 차단하는 구조였다. 숫자가 나오니까 측정하고 있다는 느낌이 강했다. 측정한 게 아니라 자평을 반올림하고 있었다.

이 형태는 회사 대시보드에서 흔히 본다. 보고되는 숫자를 보고 대상이 직접 만드는 구조. 진척률을 담당자가 입력하고, 그 진척률로 진척을 관리한다. 아무도 거짓말을 안 해도 그 숫자는 관리 도구가 못 된다.

2026년 7월 29일에 걷어냈다. 커밋 하나로 16개 파일을 고치고 348줄을 넣고 464줄을 지웠다. 순삭제다.

여기서 남은 기준이 하나 있다. 코드로 강제할 수 있는 건 모델 출력과 무관한 사실뿐이다.

같은 레포에 시크릿 스캔 훅이 있다. git commit 직전에 Google OAuth 자격증명이나 API 키 패턴이 스테이징된 파일에 있는지 검사한다. 이건 작동한다. 파일에 그 패턴이 있느냐 없느냐는 모델이 뭐라고 주장하든 안 바뀌기 때문이다. 반면 이 글에 AI 냄새가 나느냐는 그런 종류의 사실이 아니다. 그래서 게이트 대신 체크리스트로 바꿨다. 합격 여부 대신 줄 단위 수정 내역을 남기게 했다.

사내 AI 거버넌스를 짤 때 이 구분이 그대로 필요하다. AI 결과물 표시 의무 같은 걸 정한다고 치자. 표시했다고 스스로 체크하게 만들면 그건 내가 만들었던 게이트와 같은 물건이다. 검증 가능한 자리에 걸어야 한다.

그래서 순서

정리된 방법론을 내놓을 처지는 못 된다. 내가 본 건 한 팀과 한 레포뿐이다. 다만 순서 하나는 확실히 틀린 게 있다.

도구부터 고르는 것이다. 어떤 모델을 쓸지, 자체 구축이냐 벤더냐를 먼저 정하고 나서 쓸 곳을 찾는다. 대부분 이 순서로 간다. 유스케이스를 먼저 고르고 데이터를 보고 마지막에 모델을 정하는 게 맞는 순서인데 거꾸로 하는 것이다(CIO Korea).

내가 겪은 걸 반영하면 그 앞에 한 칸이 더 붙는다. 유스케이스보다 먼저 볼 게 기록이다.

우리 팀 지난 분기 결정 중에 문서로 남은 게 몇 퍼센트냐. 이걸 세어보면 AX 파일럿을 돌리기 전에 답이 나온다. 30%면 어떤 도구를 붙여도 30%짜리 결과가 나온다. 이 숫자를 안 세고 파일럿을 돌리면, 결과가 안 나왔을 때 모델 탓을 하게 된다. 그리고 벤더를 바꾼다. MIT가 말한 5%와 95%를 가르는 자리가 여기 어딘가에 있을 것이다.

세는 방법은 거창할 필요가 없다. 나는 이렇게 했다. 지난 분기에 우리가 내린 결정 중 기억나는 걸 열 개 적는다. 각각에 대해 근거 문서를 3분 안에 찾아본다. 3분을 넘기면 못 찾은 걸로 친다. 실제로 찾을 때 걸린 시간도 같이 적어둔다.

여기서 나오는 게 두 숫자다. 몇 개를 찾았느냐와 평균 몇 분 걸렸느냐. 앞은 기록이 남았는지를 보고, 뒤는 남은 기록에 접근 가능한지를 본다. 이 둘은 따로 논다. 다 적혀 있는데 다 4분씩 걸리는 조직이 있고, 절반만 적혀 있는데 그 절반은 30초 만에 나오는 조직이 있다. 처방이 다르다. 앞은 기록 습관 문제고 뒤는 검색과 구조 문제다.

굳이 열 개인 이유는 없다. 스무 개를 세면 더 정확하겠지만 열 개만 해봐도 대체로 충격이 충분하다. 내가 해봤을 때 3분 안에 근거를 찾은 건 절반이 안 됐다.

여기서 당연한 반문이 나온다. 그걸 왜 손으로 세냐, 에이전트한테 시키면 되지.

맞는 말이고 실제로 시켜보면 된다. 그런데 시켜보는 행위 자체가 이미 진단이다. 에이전트가 열 개 결정의 근거를 다 찾아서 링크까지 붙여오면 그 조직은 이 글에서 걱정하는 문제가 없는 것이다. 축하할 일이다. 반대로 다섯 개는 모르겠다고 하고 세 개는 엉뚱한 문서를 물어오면, 그게 답이다. 손으로 세야 하는 상황에 놓였다는 것 자체가 결과값이다.

그래서 결국 남는 질문은 모델을 뭘 쓰냐가 아니라 데이터를 어떻게 쌓아뒀냐가 된다.

모델은 갈아끼울 수 있다. 올해 붙인 걸 내년에 더 좋은 걸로 바꾸면 되고, 실제로 그렇게 될 것이다. 데이터 구조는 못 갈아끼운다. 지난 3년 동안 결정이 어디에 어떤 형태로 쌓였는지는 이미 정해져 있고, 바꾸려면 앞으로 3년이 또 걸린다. 이게 비대칭이다. 쉬운 쪽은 나중에 해도 되는데 어려운 쪽을 먼저 시작해야 한다.

앞에서 본 세 그룹의 노선 차이도 이 층위에서 보면 다르게 읽힌다. 외부 모델을 열지, 자체 모델로 내재화할지, 섞을지는 전부 모델 레이어의 선택이다. 그 아래 데이터 레이어가 부실하면 세 노선이 같은 결과로 수렴한다. 개방해도 수집할 게 없고 내재화해도 학습시킬 게 없다. 노선 논쟁이 활발한 것에 비해 그 아래를 이야기하는 자료가 적은 건 좀 이상한 일이다.

표시 의무 같은 규정을 정할 때도 같은 감각이 필요하다. AI로 만든 결과물에 표시를 붙이자는 방침 자체는 대부분 금방 합의된다. 문제는 그걸 어디서 확인하느냐다. 작성자가 스스로 체크박스를 누르게 만들면 그건 내가 만들었던 게이트와 정확히 같은 물건이다. 지킬 사람은 안 시켜도 지키고 안 지킬 사람은 체크박스도 누른다. 검증 가능한 자리에 걸어야 한다. 산출물이 지나가는 시스템 쪽에서 확인할 수 있는지, 아니면 최소한 사후에 표본으로 대조할 수 있는지를 같이 설계해야 규정이 규정으로 남는다.

유스케이스 발굴도 위에서 안 된다. 워크숍을 열어서 AI로 뭘 하면 좋을지 브레인스토밍하면 그럴듯한 목록이 나오는데 대부분 안 굴러간다. 대신 이미 자기 방식으로 뭔가를 자동화해놓은 사람을 찾는 게 빠르다. 어느 조직에나 몇 명 있다. 승인 안 된 도구를 쓰고 있어서 조용히 하고 있을 뿐이다.

실제로 그 규모가 작지 않다. Verizon의 2026 DBIR은 회사 기기에서 정기적으로 AI를 쓰는 직원을 45%로 봤고, Okta 조사에서는 지식 노동자 52%가 미승인 도구를 쓴다고 인정했으며, UpGuard 조사에서는 직원 81%에 보안 리더는 88%까지 올라간다(Cybersecurity Dive). 수치가 45%에서 88%까지 벌어지는 건 아직 아무도 이걸 제대로 못 세고 있다는 뜻이지만, 어느 조사를 믿어도 이미 상당수가 쓰고 있다는 결론은 같다.

그 사람들이 이미 만들어놓은 방식이 진짜 유스케이스다. 발굴하는 게 아니라 찾아서 옮겨 적는 것에 가깝다. 그리고 그 과정에서 왜 승인된 도구를 안 쓰고 있었는지도 같이 알게 된다.

마지막으로 교육. 도구 사용법 교육은 반나절이면 끝나고 효과도 딱 반나절만큼 간다. 정작 가르쳐야 하는 건 자기 업무를 어떻게 기록으로 남기느냐다. 재미없고 티도 안 나는데, 앞에서 본 것처럼 이게 상한을 정한다.

넉 달 전에 이 블로그 자동화를 시작할 때 나는 좋은 프롬프트를 쓰는 게 핵심인 줄 알았다. 스킬 21개에 2,697줄을 쓴 것도 그 믿음 때문이었다.

지금 저 레포에서 실제로 일하는 건 프롬프트가 아니라 파일들이다. 브리프, 세션 상태, 메모리, 발행 아카이브. 전부 그냥 텍스트다.

가장 효과가 컸던 장치가 뭐였냐면 56줄짜리 훅 하나다. 세션이 시작될 때 지난번에 어디까지 했는지 적어둔 파일을 읽어서 앞에 붙여준다. 그게 전부다. 똑똑한 구석이 없는데 이게 없으면 매번 처음부터 설명해야 한다. 반대로 이게 있으면 지난주에 뭘 하다 말았는지, 뭐가 틀렸다고 판명났는지가 그냥 이어진다. 결국 파일에 적어뒀느냐 아니냐의 문제였다.

에이전트가 똑똑해서 굴러가는 게 아니라 읽을 게 있어서 굴러간다. 그리고 읽을 게 없으면 아무리 좋은 모델을 붙여도 똑같이 멈춘다. 넉 달 동안 이걸 여러 번 다른 형태로 다시 배웠다.

회사도 다르지 않을 것 같다. 티켓부터 남기라는 말로 끝나는 게 좀 민망하긴 한데, 넉 달 동안 확인한 게 그거였다. 그리고 이번엔 남기면 그 이득을 남긴 사람이 가져간다는 게 예전과 다르다.

다음 편에서는 이 단어 자체를 좀 따져보려고 한다. 잘 쓰는 사람은 AX라는 말이 나오기 전부터 알아서 쓰고 있었고, 못 쓰는 사람은 이 단어 때문에 오히려 겁을 먹는다. 그러면 이 말은 대체 누구를 위해 만들어진 걸까.