6월 첫 주에 조직 개편 공지가 올라왔습니다. 명분은 AI 대응이었습니다. 얼마 안 가서 사내 AI 업무 에이전트도 열렸습니다. 사내 문서, 위키, 이슈 트래커, 메신저, 코드 저장소를 한데 모아 지식 베이스를 만들었고 거기 붙어서 답한다고 했습니다. 저는 좀 들떴습니다. 몇 달째 제 블로그를 에이전트로 돌리고 있었으니까, 저한테는 익숙한 물건이 하나 더 생긴 정도라고 생각했습니다.
제일 먼저 시킨 게 주간보고였습니다. 한 주 동안 제가 남긴 것들을 모아서 위클리를 쓰게 했습니다.
생각보다 잘 됐습니다. 화요일에 처리하고 까맣게 잊어버린 이슈 하나가 목록에 올라와 있었습니다. 제가 손으로 썼으면 그건 틀림없이 빠졌을 겁니다.
그런데 같은 도구를 받은 옆자리는 아무것도 못 뽑았습니다. 에러가 난 게 아니라 결과가 거의 비어 있었습니다. 처음엔 프롬프트를 잘못 넣었나 했는데 그게 아니었습니다. 그 사람의 한 주가 어디에도 적혀 있지 않았던 겁니다. 회의도 했고 결정도 났고 일도 돌아갔는데 그게 다 말로 끝나 있었습니다. 에이전트 쪽에서 보면 가져올 게 처음부터 없었습니다.
그때부터 AX 라는 말이 좀 다르게 들리기 시작했습니다. 같은 날 같은 도구를 받았으니 출발선도 같다고 생각했는데, 실제로는 도구를 받기 훨씬 전에 이미 출발선이 정해져 있었던 겁니다. 그동안 뭘 얼마나 적어 왔느냐로요. 그 사람이 일을 덜 한 것도 아니고 도구를 못 다룬 것도 아니었습니다. 그냥 일하는 방식이 말 쪽에 있었을 뿐인데, 그게 이 도구 앞에서는 아무것도 안 한 것처럼 보였습니다.
6월에 세 그룹이 같은 말을 했습니다
저희 회사만 그런 게 아니었습니다. 6월에 국내 큰 그룹들이 거의 동시에 AX 를 경영 전면에 내걸었다는 기사가 쏟아졌습니다. 삼성은 외부 생성형 AI 를 계열사 전반에 공식 도입하는 쪽으로, SK 는 민감한 데이터는 자체 모델과 사내 플랫폼으로 묶어 두고 범용 영역만 외부 모델을 쓰는 쪽으로, LG 는 자체 모델 ExaOne 을 가운데 두고 일부 계열사가 글로벌 모델을 같이 쓰는 쪽으로 간다고 했습니다(메트로서울). 노선은 셋이 다 다른데, 아래로 내려오는 문장은 똑같았습니다. 일하는 방식을 바꾸라는 겁니다.
시기가 이렇게 겹친 건 도구 쪽이 먼저 바뀌어서 그런 것 같습니다. 작년까지 사내에서 AI 를 쓴다는 건 대체로 탭 하나 열어 놓고 붙여 넣는 일이었습니다. 그렇게 쓸 때는 회사 문서가 어떻게 정리돼 있든 상관이 없었습니다. 필요한 걸 제가 손으로 퍼 날랐으니까요. 그러다 모델과 외부 도구를 잇는 규격이 공개 표준으로 정착하면서 커넥터가 생겼고, 이제는 문서 저장소와 메신저와 이슈 트래커에 바로 붙습니다. 모델이 업무 시스템 안으로 들어온 겁니다.
붙일 수 있게 되니까 그동안 안 보이던 게 보이기 시작했습니다. 붙였는데 가져올 게 없다는 것.
95% 라는 숫자
AX 이야기가 나오면 거의 꼭 같이 나오는 숫자가 있습니다. MIT 보고서 "The GenAI Divide" 의 95% 입니다. 생성형 AI 파일럿의 95% 가 측정 가능한 손익 효과를 내지 못했다는 내용입니다(Fortune). 도입은 많이 했는데 대부분 개인 생산성 정도에서 끝나고 사업 성과로는 안 이어졌다는 겁니다. 보고서는 그 원인을 모델 품질이 아니라 학습 격차라고 봤습니다. 도구가 피드백을 기억하지 못하고, 맥락에 맞춰 바뀌지 못하고, 시간이 가도 나아지지 않는다는 겁니다.
이 숫자는 비판도 많이 받았습니다. 성공을 너무 좁게 정의했다는 게 핵심인데, 파일럿 몇 달 뒤에 손익 효과가 잡혀야 성공으로 쳤으니 그럴 만합니다.
저는 이 숫자를 쓰는 게 좀 꺼려집니다. 95% 를 인용하면 글이 편해지기 때문입니다. 남들이 거의 다 실패했다는 숫자 하나만 있으면 제 말이 저절로 무거워집니다. 그런데 그렇게 쓰는 순간 이 글도 AX 를 팔러 다니는 자료들과 같은 글이 됩니다. 그쪽도 이 숫자를 똑같이 씁니다. 그래서 저는 95% 를 결론 말고 질문으로만 보려고 합니다. 파일럿은 도는데 성과가 안 나오는 데가 어디냐는 질문이요. 그건 제가 옆자리에서 봤습니다.
같은 팀 안에서 벌써 벌어진 차이
다시 주간보고 이야기입니다.
저희 팀에는 위클리를 에이전트로 쓰는 사람이 있고 손으로 쓰는 사람이 있습니다. 처음엔 취향이나 부지런함 차이인 줄 알았는데, 결과물의 성질이 아예 달랐습니다.
자동으로 모아서 쓰면 제가 깜빡한 것까지 다 올라옵니다. 보고서에 담기는 범위가 그 주에 남은 기록의 범위와 같아집니다. 손으로 쓰면 기억나는 것만 올라옵니다. 보고서 범위가 그 주에 기억하는 범위와 같아집니다. 그리고 사람은 자기가 한 일의 꽤 많은 부분을 금요일 오후에 기억하지 못합니다. 저도 그렇습니다. 그 화요일 이슈가 그랬습니다.
그 이슈가 왜 빠졌을지 생각해 보면 이유가 시시합니다. 큰일이 아니었습니다. 삼십 분쯤 붙잡고 있다가 원인을 찾아서 고치고 코멘트 하나 남기고 넘어갔습니다. 그 주에 훨씬 크고 시끄러운 일이 두어 개 있었으니 금요일에 위클리를 쓰면서 그게 떠오를 리가 없습니다. 자동 수집은 크고 작은 걸 안 따집니다. 그 주에 제 이름으로 남은 흔적을 그냥 다 긁어 옵니다. 티켓 상태 변경, 커밋 메시지, 스레드에서 결론이 난 대화 같은 것들이요. 사람이 중요도로 거르던 걸 기계는 안 거릅니다.
안 중요한 것까지 다 올라와서 지저분해지는 건 맞습니다. 그런데 위클리에서 중요한지 아닌지는 어차피 읽는 사람이 판단합니다. 제가 미리 걸러서 올리면 그건 거른 게 아니라 그냥 빠뜨린 겁니다.
두 사람이 똑같이 일했는데 한쪽 기록에는 열두 건이 남고 다른 쪽에는 일곱 건이 남는다고 해 보겠습니다. 나머지 다섯 건은 없어진 게 아니라 안 보이게 된 겁니다. 평가할 때도 안 보이고, 다음에 비슷한 문제가 생겨서 찾아볼 때도 안 보이고, 무엇보다 다음 주에 에이전트가 모으러 왔을 때 안 보입니다.
손으로 쓰는 쪽이 게으른 것도 아닙니다. 시간은 오히려 그쪽이 더 씁니다. 사십 분 앉아서 한 주를 되짚는 사람과 오 분 만에 초안을 받아 다듬는 사람 중에 공을 더 들인 쪽은 앞사람입니다. 그런데 결과물은 뒷사람 것이 낫습니다. 공을 들인 만큼 결과가 나오지 않는 상황이라 더 고약하게 느껴집니다.
이 차이는 한 층 위에서도 그대로 나타납니다. 팀장 중에도 팀원들 위클리를 하나하나 읽고 분석해서 팀 보고서를 쓰는 사람이 있고, AI 한테 정리를 시키는 사람이 있습니다. 여기서도 결과가 다른데, 다른 방식이 아래층과는 좀 다릅니다. 아래층 차이가 위층에서 곱해집니다.
팀원 위클리가 촘촘하면 팀장이 AI 로 정리했을 때 쓸 만한 게 나옵니다. 팀원 위클리가 부실하면 팀장이 아무리 좋은 도구를 써도 요약할 거리가 없습니다. 부실한 일곱 줄을 요약하면 더 부실한 세 줄이 나옵니다. 반대로 팀원 기록은 좋은데 팀장이 손으로 읽고 있으면 그건 그것대로 막힙니다. 팀원 여덟 명이 열두 건씩 남긴 걸 사람이 매주 다 소화할 수는 없습니다.
그래서 조직 전체가 AI 로 뽑아낼 수 있는 양은 결국 맨 아래층에 기록이 얼마나 촘촘하게 남아 있느냐에서 정해진다고 봅니다. 위에서 아무리 좋은 플랫폼을 깔아도 그 위로는 안 올라갑니다.
그렇게 보면 AX 를 위에서부터 시작하는 게 좀 이상하게 느껴집니다. 임원 교육을 먼저 하고 전사 플랫폼을 먼저 까는데, 실제로 결과를 정하는 건 맨 아래에서 매일 뭘 적고 뭘 안 적느냐입니다. 위에서 할 수 있는 건 그걸 적고 싶게 만드는 것 정도인데, 그건 교육으로 되는 일이 아닌 것 같습니다.
에이전트는 적어 둔 것만 가져옵니다
회사 에이전트에서 제일 인상 깊었던 건 모델이 아니라 설계 하나였습니다. 원본 문서의 권한을 그대로 물려받아서 동작한다는 점입니다.
사내 지식 베이스를 만들 때 제일 흔하게 나는 사고가 여기서 나옵니다. 문서를 다 긁어모아 인덱스 하나로 만들면 검색은 잘 되는데 권한이 뭉개집니다. 인사 문서나 아직 공개 안 된 조직 개편안, 특정 팀만 보는 예산 자료가 다른 문서들과 같은 인덱스에 들어갑니다. 그러면 제가 "다음 분기 조직 어떻게 되냐" 고 물었을 때 시스템이 그 문서를 근거로 답을 만들어 버립니다. 원본 파일은 제가 열 권한이 없는데 답에는 그 내용이 들어 있습니다. 파일을 연 게 아니니 감사 로그에도 안 남습니다.
요약이 권한 검사를 그냥 통과해 버린다는 게 더 미묘합니다. 인덱스에 들어가는 순간 원문은 조각이나 벡터로 바뀌고, 거기서 나온 답은 원문과는 다른 새 텍스트가 됩니다. 원문에 걸어 둔 권한이 그 새 텍스트에는 안 붙습니다. 문서마다 자물쇠가 달려 있는데, 그걸 녹여서 만든 물건에는 자물쇠가 없는 겁니다. 제목만 보여도 문제가 되는 경우도 있습니다. 검색 결과에 "OO본부 통합 검토안" 같은 제목이 목록으로만 떠도 그 자체가 정보입니다.
원본 권한을 그대로 물려받으면 같은 질문에도 사람마다 다른 답을 받습니다. 옆자리는 답을 받는데 저는 모른다는 답을 받습니다. 불편하고 가끔 답답한데 저는 그게 맞게 동작하는 거라고 생각합니다. 다만 쓰는 사람들은 이걸 도구가 덜 된 걸로 받아들이기 쉬울 것 같습니다. 옆자리는 되는데 나는 안 된다고 하면 불만부터 나오니까요. 그 불만이 쌓이면 권한을 좀 넓혀 달라는 요청이 올라올 텐데, 만드는 쪽에서는 그때 버티는 게 제일 어려운 일일 것 같습니다.
특정 조직부터 순서대로 여는 것도 같은 이유로 보입니다. 전사에 한 번에 열었다가 이런 사고가 나면 되돌릴 방법이 없습니다. 이미 읽은 사람 머리에서 지울 수는 없으니까요. 작은 조직에서 몇 달 써 보면 어떤 문서가 인덱스에 잘못 들어갔는지, 어떤 식으로 물으면 권한을 돌아가는지가 실제 사용 로그로 드러납니다.
그런데 설계가 아무리 꼼꼼해도 못 넘는 선이 있습니다. 모을 대상에 없는 건 못 가져옵니다.
위키에도 없고 이슈 트래커에도 없고 메신저 로그에도 없는 결정은 없는 결정입니다. 회의실에서 셋이 합의하고 각자 자기 책상으로 돌아가서 각자 실행한 결정은, 3주 뒤에 누가 왜 이렇게 됐냐고 물었을 때 아무도 근거를 못 댑니다. 사람 기억으로는 세 사람이 각자 다른 버전을 말하고, 에이전트한테 물으면 아예 모른다고 합니다.
AX 이야기는 대부분 어떤 모델을 쓸지에서 시작하는데, 실제로 먼저 막히는 건 여기입니다. 모델은 나중에 바꿀 수 있습니다. 지난 분기에 말로 끝낸 회의는 지금 와서 적을 수가 없습니다.
적어 뒀는데 못 찾으면
쓰는 쪽 이야기만 하면 반쪽이고, 찾는 쪽 이야기가 남아 있습니다.
사내 게시판이나 메신저에 다 적어 놨다고 해도 이력이 길어지면 못 찾습니다. 스레드가 채널 안에 묻히고, 어떤 글이 어느 스레드에 달려 있는지 알 수가 없습니다. 검색이 있긴 한데 키워드를 알아야 씁니다. 석 달 전 그 결정을 우리가 뭐라고 불렀는지 기억이 안 나면 검색어부터 못 만듭니다. 같은 주제가 채널 세 군데에 흩어져 있고 결론이 조금씩 다른 경우도 흔합니다. 그중 어느 게 최종인지는 그 안에서 알 수가 없습니다.
찾는 수고가 다시 묻는 수고보다 커지는 순간이 옵니다. 이십 분 스크롤할 바에는 옆자리에 물어보는 게 빠릅니다. 그래서 묻습니다. 그렇게 받은 답은 또 스레드 어딘가에 묻히거나 아예 말로만 오갑니다. 반년 사이에 같은 질문이 몇 번이고 다시 나오고 매번 새로 답이 달립니다.
더 비싼 건 다시 결정하는 경우입니다. 이미 검토해서 기각한 안이 반년 뒤에 다시 올라옵니다. 기각한 이유가 어딘가에는 분명 있는데 아무도 못 찾으니까 처음부터 다시 논의합니다. 회의를 한 번 더 하고 같은 결론이 납니다. 운이 나쁘면 다른 결론이 나고, 그러면 앞의 결정과 뒤의 결정이 같이 남아서 실무자가 둘 다 들여다보는 상태가 됩니다.
찾기 어려운 기록은 사람을 다시 말로 일하게 만듭니다. 안 적어서 못 찾고, 못 찾으니까 물어보고, 물어보니까 또 안 적힙니다. 이게 한 번 돌 때마다 조직에 남는 기록이 조금씩 줄어듭니다.
사내 지식 베이스가 실제로 해 주는 일도 여기에 있는 것 같습니다. 문서를 대신 써 준다는 기능이 눈에 잘 띄지만, 조직 입장에서는 통합 검색이 더 큽니다. 흩어진 채널을 가로질러서 "그때 그 결정 왜 그렇게 났지" 에 답을 해 주면 위의 반복이 끊깁니다. 저도 회사 에이전트를 제일 자주 쓰는 용도가 이겁니다. 반년 전 스레드를 제가 직접 찾으려면 못 찾는데 물어보면 찾아 줍니다. 검색어를 모르는 채로 찾는다는 건 사실 사람한테 물어보는 것과 비슷합니다. "그때 그거 있잖아요" 하고 물으면 사람은 알아듣는데 검색창은 못 알아듣습니다. 에이전트는 그 "그때 그거" 를 알아듣는 쪽에 처음으로 가까워진 도구라고 생각합니다. 옆자리에 묻던 걸 에이전트한테 묻게 되면, 적어도 같은 질문을 사람한테 몇 번이고 다시 하는 일은 줄어들 것 같습니다.
다만 답만 주고 출처를 안 주면 못 씁니다. 어느 문서 어느 스레드에서 나온 이야기인지 링크가 같이 와야 확인을 할 수 있고, 확인이 돼야 그 답을 근거로 다음 결정을 할 수 있습니다. 출처 없는 요약은 편하긴 한데 그걸 회의에 들고 갈 수는 없습니다.
지라에 다 등록하라는 말
말로 나눈 이야기를 근거로 남기자는 건 새로운 얘기가 아닙니다. 자기가 하는 일은 전부 티켓으로 등록하고 시작하라는 지침은 어느 회사에나 있었습니다. 회의록을 남기라는 것도, 결정에 근거를 붙이라는 것도, 합의는 문서로 확인하라는 것도 마찬가지입니다. 신입 때 한 번은 듣는 말이고, 그러고 나서 대부분 안 지켜지는 말입니다. 저도 오래 안 그랬습니다.
이게 그렇게 오랫동안 안 먹힌 이유는 계산해 보면 금방 나옵니다. 수고는 개인이 하고 이득은 조직이 가져갔습니다. 티켓 하나 만들고 설명 쓰고 상태 바꾸는 데 몇 분이 듭니다. 그 몇 분은 제 시간입니다. 그렇게 쌓인 데이터로 만들어지는 건 진척 대시보드고, 그건 위에서 봅니다. 제가 오늘 몇 분을 쓰면 다음 달에 다른 누군가가 보고서를 편하게 씁니다. 그러니 안 하는 게 이상한 게 아니라 하는 게 이상한 일이었습니다.
그래서 강제를 붙여도 형식만 채워졌습니다. 티켓 없는 커밋을 막으면 "이번 주 작업" 이라는 티켓 하나 만들어 놓고 한 달을 그 밑에서 지냅니다. 감사를 하면 감사 전날 몰아서 채웁니다. 규율로 사람을 이기려고 하면 대체로 사람이 이깁니다.
지금 달라진 건 규율이 아니라 그 계산입니다. 이제는 기록을 남긴 사람이 그 이득을 직접 가져갑니다. 몇 분을 쓰면 금요일에 사십 분을 아낍니다. 그것도 더 정확한 결과물로 아낍니다. 일하다 이슈가 터지면 3주 전에 왜 그 설정을 그렇게 뒀는지 되짚을 수 있고, 평가 시즌에 제가 뭘 했는지 보여 줄 근거가 이미 쌓여 있습니다. 예전엔 이게 다 언젠가 좋아질 거라는 막연한 이야기였는데 지금은 다음 주 금요일에 바로 돌아옵니다.
설득할 필요가 없어졌다는 게 제일 큰 것 같습니다. 문서화가 왜 중요한지 설명하는 자료를 만들 필요가 없습니다. 위클리를 자동으로 받아 본 사람은 그다음 주부터 알아서 티켓을 남깁니다. 저도 그랬습니다. 누가 시켜서가 아니라 다음 금요일에 덜 고생하고 싶어서였습니다.
요구하는 수준이 내려온 것도 같이 봐야 합니다. 예전 문서화는 완성된 결과물을 요구했습니다. 회의록은 형식을 갖춰야 했고 티켓 설명은 남이 읽어도 알아듣게 써야 했습니다. 그게 진입장벽이었습니다. 지금은 조각이면 됩니다. 스레드에 남긴 두 줄, 커밋 메시지 한 줄, 티켓 코멘트에 붙인 링크 하나. 정리는 에이전트가 합니다. 잘 써야 하는 게 아니라 남기기만 하면 되는 쪽으로 기준이 내려왔습니다.
그래도 안 남기면 이제는 손해가 실제로 생깁니다. 자동화로 얻을 수 있는 걸 통째로 못 받습니다. 그리고 그 부실한 기록이 다음 주 입력으로 다시 들어갑니다. 차이가 매주 조금씩 벌어지는 게 아니라 이자가 붙듯이 벌어집니다.
MIT 가 학습 격차라고 부른 것도 이 근처에 있다고 봅니다. 도구가 맥락을 붙들지 못한다는 진단이었는데, 조직이 애초에 맥락을 글로 안 남기면 붙들 게 없습니다. 벤더를 바꿔도 안 고쳐질 것 같습니다.
이 결론이 좀 김빠지긴 합니다. 최신 에이전트 구조 이야기를 기대했는데 티켓을 남기라는 얘기로 끝나면 누구라도 그럴 겁니다. 저도 몇 번을 다시 생각해 봤는데 매번 같은 데로 돌아왔습니다.
Klarna 가 되돌린 이유
반대 방향 이야기도 하나 있습니다. Klarna 는 고객 응대를 AI 로 바꾸고 직원 수백 명 분의 일을 AI 가 한다고 발표했습니다. 그러다 2025년 중반에 사람을 다시 뽑기 시작했습니다. CEO 는 효율과 비용에 너무 집중했고 그 결과 품질이 낮아졌다고 말했습니다(Forbes). 완전히 접은 건 아니고, 반복되는 대량 문의는 AI 가 받고 복잡한 건이나 중요한 고객은 사람이 받는 식으로 섞었습니다.
저는 되돌렸다는 사실보다 되돌린 계기가 더 눈에 들어왔습니다. 고객 만족도와 응대 뒤 설문이 계기였습니다. 그전까지 보던 숫자들은 평균이었습니다. 평균 응답 시간, 평균 처리 건수, 평균 비용. 그 숫자들은 다 좋아 보였습니다. 피해는 끝자락에서 나고 있었습니다. 복잡한 건 하나를 못 풀어서 크게 화가 난 고객, 그리고 그 고객이 다시는 안 오는 것. 평균으로는 그게 안 잡힙니다.
AX 도입 지표를 짤 때도 이게 그대로 해당된다고 봅니다. 처리 시간이 얼마나 줄었는지만 세면 같은 함정에 빠집니다. 잘 안 된 경우가 어디에 몰려 있는지를 따로 봐야 합니다. 처리 시간이 줄었다는 숫자는 보고하기 좋습니다. 위로 올라갈수록 그런 숫자만 남고, 화난 고객 한 명 이야기는 중간에서 빠집니다. 생각해 보면 금요일 위클리에서 빠지던 화요일 이슈하고 비슷한 모양입니다. 작고 귀찮은 건 위로 올라가는 동안 다 떨어져 나갑니다.
이 글을 쓰고 나서 사무직 밖에서 같은 모양을 하나 더 봤습니다. 쉬운 요청은 기계가 가져가고 나머지가 예외 경로로 밀려나는 동안 일하는 사람은 줄고 남은 사람의 근로시간은 늘어난 사례입니다. 밀려난 비용이 원래 장부에 안 잡히니까 평균 지표는 계속 좋아 보입니다.
제가 만든 게이트를 걷어낸 이야기
거버넌스 이야기를 하려면 제 실패를 하나 꺼내야 합니다.
제가 몇 달째 쓰고 있는 개인 자동화 레포가 있습니다. 스킬과 에이전트와 훅이 여러 개 들어 있고, 글 하나가 초안에서 발행까지 가는 동안 여러 단계를 거칩니다. 그중 하나가 문체 검사였습니다.
여기에 게이트를 걸었습니다. 발행 스크립트가 검사 결과 파일에서 "판정: 합격" 이라는 문자열을 grep 해서, 없으면 발행을 막았습니다. 코드로 품질을 강제했다고 생각했고 꽤 만족했습니다.
문제는 그 문자열을 누가 쓰느냐였습니다. 검사받는 에이전트가 직접 썼습니다.
검문소와 통행증 발급처가 같은 곳이었던 겁니다. 몇 달 동안 게이트가 잘 돌고 있다고 믿었는데, 실제로는 자기 신고를 자동화해 놓고 그걸 통제라고 부르고 있었습니다. 알아차렸을 때 좀 허탈했습니다. 꼼꼼하게 만들어 놓은 게 꼼꼼하게 아무것도 안 하고 있었습니다.
몇 달이나 못 알아챈 게 더 고약합니다. 가끔 실제로 막혔거든요. 에이전트가 스스로 불합격을 적는 경우가 진짜 있었고, 그러면 발행이 멈추고 저는 글을 고쳤습니다. 그때마다 게이트가 일하고 있다는 증거처럼 보였습니다. 막힌 적이 있으니까 작동한다고 생각한 겁니다. 그런데 그건 검사가 엄격해서 막힌 게 아니라 그날 그 에이전트가 자기한테 박했던 것뿐입니다. 통과도 차단도 같은 쪽에서 정하고 있었으니, 어느 쪽이 나와도 게이트가 제대로 하고 있는지에 대해서는 아무것도 알려 주지 않았습니다.
점수까지 붙어 있어서 더 그럴듯했습니다. 여러 항목을 채점해서 총점을 내고 기준에 못 미치면 막는 방식이었습니다. 숫자가 나오니까 뭔가를 재고 있다는 느낌이 강했습니다. 실제로는 자기 평가를 점수로 바꿔 적고 있었을 뿐입니다.
회사 대시보드에서도 이런 모양을 자주 봅니다. 보고되는 숫자를 보고받는 대상이 직접 만드는 구조입니다. 진척률을 담당자가 입력하고, 그 진척률로 진척을 관리합니다. 아무도 거짓말을 안 해도 그 숫자로는 관리가 안 됩니다.
7월 말에 그 게이트를 걷어냈습니다. 커밋 하나로 넣은 것보다 지운 줄이 백 줄 넘게 많았습니다.
그 뒤로 남은 기준이 하나 있습니다. 코드로 강제할 수 있는 건 모델이 뭐라고 쓰든 상관없는 사실뿐이라는 겁니다. 같은 레포에 시크릿 스캔 훅이 있습니다. git commit 직전에 Google OAuth 자격증명이나 API 키 패턴이 스테이지된 파일에 있는지 봅니다. 파일에 그 패턴이 있느냐 없느냐는 모델이 뭐라고 주장하든 안 바뀝니다. 이 글에서 AI 냄새가 나느냐는 그런 종류의 사실이 아닙니다. 그래서 문체 쪽은 게이트를 빼고 체크리스트로 바꿨고, 합격 여부 대신 줄 단위로 뭘 고쳤는지를 남기게 했습니다. 그 뒤로는 무슨 장치를 만들든 이 숫자를 누가 쓰는지부터 보게 됐습니다. 검사받는 쪽이 쓰는 숫자라면 아무리 그럴듯해도 그건 신고서에 가깝습니다.
사내 AI 거버넌스를 짤 때도 이 구분이 그대로 필요하다고 봅니다. 회사에서 만드는 규정은 대부분 사람이 스스로 지켰다고 표시하는 방식으로 끝나는데, AI 가 끼어들면 그 표시를 AI 가 대신 해 줄 수도 있습니다. 그러면 표시는 더 깔끔하게 채워지고, 실제로 지켰는지는 더 알기 어려워집니다.
순서에 대해서
도구부터 고르는 순서는 틀렸다고 봅니다. 어떤 모델을 쓸지, 직접 만들지 벤더한테 살지를 먼저 정해 놓고 나서 쓸 곳을 찾습니다. 대부분 이렇게 갑니다. 쓸 곳을 먼저 고르고 데이터를 보고 마지막에 모델을 정하는 게 맞는데 거꾸로 간다는 지적은 전부터 있었습니다(CIO Korea).
저는 그 앞에 한 칸을 더 두고 싶습니다. 쓸 곳보다 먼저 기록을 봐야 한다고 생각합니다. 우리 팀 지난 분기 결정 중에 글로 남은 게 얼마나 되는지를 세어 보면, AX 파일럿을 돌리기 전에 대충 답이 나옵니다. 열 개 중 세 개만 남아 있으면 어떤 도구를 붙여도 세 개짜리 결과가 나옵니다. 이걸 안 세고 파일럿을 돌리면 결과가 안 나왔을 때 모델 탓을 하게 되고, 벤더를 바꿉니다.
세는 방법은 대단할 게 없습니다. 저는 이렇게 했습니다. 지난 분기에 우리가 내린 결정 중 기억나는 걸 열 개 적고, 하나씩 근거 문서를 3분 안에 찾아봅니다. 3분이 넘으면 못 찾은 걸로 칩니다. 찾는 데 걸린 시간도 같이 적어 둡니다.
그러면 숫자가 두 개 나옵니다. 몇 개를 찾았는지와 평균 몇 분이 걸렸는지입니다. 앞은 기록이 남았는지를 보고, 뒤는 남은 기록을 꺼낼 수 있는지를 봅니다. 이 둘은 따로 놉니다. 다 적혀 있는데 매번 몇 분씩 걸리는 조직이 있고, 절반만 적혀 있는데 그 절반은 금방 나오는 조직이 있습니다. 앞은 기록하는 습관의 문제고 뒤는 검색과 구조의 문제라서 손볼 곳이 다릅니다.
열 개인 데 특별한 이유는 없습니다. 열 개만 해 봐도 대체로 충분히 놀랍니다. 제가 해 봤을 때는 3분 안에 근거를 찾은 게 절반이 안 됐습니다.
이걸 왜 손으로 세냐, 에이전트한테 시키면 되지 않냐고 할 수도 있는데, 시켜 보면 그게 그대로 진단이 됩니다. 에이전트가 열 개 결정의 근거를 다 찾아서 링크까지 붙여 오면 그 조직은 이 글에서 걱정하는 문제가 없는 겁니다. 다섯 개는 모르겠다고 하고 세 개는 엉뚱한 문서를 물어 오면 그게 답입니다. 손으로 세야 하는 상황이라는 것 자체가 결과입니다.
모델은 갈아 끼울 수 있습니다. 올해 붙인 걸 내년에 더 좋은 걸로 바꾸면 되고 실제로 그렇게 될 겁니다. 데이터가 쌓인 모양은 못 갈아 끼웁니다. 지난 몇 년 동안 결정이 어디에 어떤 형태로 쌓였는지는 이미 정해져 있고, 그걸 바꾸려면 앞으로 또 몇 년이 걸립니다. 쉬운 쪽은 나중에 해도 되는데 어려운 쪽은 지금 시작해야 합니다.
앞에서 본 세 그룹의 노선 차이도 이렇게 보면 좀 다르게 읽힙니다. 외부 모델을 열지, 자체 모델로 갈지, 섞을지는 전부 모델 쪽 선택입니다. 그 아래 데이터가 부실하면 세 노선이 결국 같은 결과로 모입니다. 외부 모델을 열어도 가져올 게 없고, 자체 모델로 가도 가르칠 게 없습니다. 노선 이야기는 그렇게 많은데 그 아래 이야기는 잘 안 보이는 게 좀 이상합니다.
AI 로 만든 결과물에 표시를 붙이자는 규정 같은 것도 같은 감각이 필요하다고 봅니다. 방침 자체는 금방 합의가 됩니다. 문제는 어디서 확인하느냐입니다. 쓴 사람이 스스로 체크박스를 누르게 하면 그건 제가 만들었던 게이트하고 똑같은 물건입니다. 지킬 사람은 안 시켜도 지키고, 안 지킬 사람은 체크박스도 누릅니다. 결과물이 지나가는 시스템 쪽에서 확인할 수 있는지, 아니면 적어도 나중에 몇 개 뽑아서 대조해 볼 수 있는지를 같이 정해야 규정이 규정으로 남을 것 같습니다.
쓸 곳을 찾는 것도 위에서 정하면 잘 안 되는 것 같습니다. 워크숍을 열어서 AI 로 뭘 하면 좋을지 아이디어를 모으면 그럴듯한 목록이 나오는데, 대부분 실제로는 안 쓰입니다. 그보다 이미 자기 방식으로 뭔가를 자동화해 놓은 사람을 찾는 게 빠릅니다. 어느 조직에나 몇 명씩 있습니다. 승인 안 된 도구를 쓰고 있어서 조용히 하고 있을 뿐입니다. 조사마다 숫자가 들쭉날쭉하긴 한데, 회사 몰래 AI 도구를 쓰는 사람이 이미 꽤 많다는 데는 다들 비슷한 이야기를 합니다. 그 사람들이 이미 만들어 둔 방식이 진짜 쓸 곳입니다. 새로 찾아낸다기보다 찾아가서 옮겨 적는 일에 가깝고, 그러다 보면 그 사람들이 왜 승인된 도구를 안 쓰고 있었는지도 같이 알게 됩니다.
교육도 비슷합니다. 도구 사용법은 반나절이면 가르치고 효과도 딱 반나절 갑니다. 정작 가르쳐야 하는 건 자기 일을 어떻게 기록으로 남기느냐입니다. 재미없고 티도 안 나는데, 앞에서 이야기한 것처럼 이게 위쪽 한계를 정합니다. 반나절 교육 대신 지난주 위클리를 에이전트로 한 번 뽑아 보게 하는 쪽이 더 빨리 와닿을 수도 있겠습니다. 비어 있는 결과를 한 번 받아 보면 설명이 필요 없을 테니까요.
처음 그 자동화를 시작할 때 저는 좋은 프롬프트를 쓰는 게 제일 중요한 줄 알았습니다. 스킬 파일을 그렇게 길게 쓴 것도 그 믿음 때문이었습니다. 지금 그 레포에서 실제로 일하는 건 프롬프트가 아니라 파일들입니다. 브리프, 세션 상태, 메모리, 발행 아카이브. 다 그냥 텍스트입니다.
효과가 제일 컸던 건 짧은 훅 하나였습니다. 세션이 시작될 때 지난번에 어디까지 했는지 적어 둔 파일을 읽어서 앞에 붙여 줍니다. 그게 다입니다. 똑똑한 구석이 하나도 없는데, 이게 없으면 매번 처음부터 설명해야 합니다. 이게 있으면 지난주에 뭘 하다 말았는지, 뭐가 틀렸다고 판명 났는지가 그냥 이어집니다. 에이전트가 똑똑해서 일이 되는 게 아니라 읽을 게 있어서 일이 됩니다. 읽을 게 없으면 아무리 좋은 모델을 붙여도 똑같이 멈춥니다. 몇 달 동안 이걸 모양을 바꿔 가며 몇 번이나 다시 배웠습니다.
회사도 크게 다르지 않을 것 같습니다. 티켓부터 남기라는 말로 끝나는 게 좀 민망하긴 한데, 이번에는 남기면 그 이득을 남긴 사람이 가져간다는 게 예전하고 다릅니다.
써 놓고 보니 전환의 주어는 회사인데 정작 격차는 같은 팀 두 사람 사이에서 벌어지고 있더라는 이야기가 됐습니다.
댓글
댓글 쓰기