없앨 것인가 가르칠 것인가 — 두 방이 같은 질문에 반대편에서 답했다

전날(8월 11일) 저녁 7시가 지난 더배러 방에서 한 참가자가 링크 두 개를 연달아 올렸다. 하나는 한 저자의 그날치 링크드인 글, 다른 하나는 그 글이 인용한 1990년 논문이었다. "링크드인에 언급된 1990년도 HBR 논문 원문입니다: “Don’t automate: obliterate”" 서른여섯 해 전 경영 학술지에 실린 제목이 그날의 방 대화에 그대로 얹혔다.

같은 참가자는 그 논문이 자기 경험과 겹친다고 말했다. 문서 도구용 플러그인을 직접 만든 이유가 「어떤 지시를 매번 반복하는 일 자체가 번거롭고 토큰도 아깝다」는 것이었고, 그래서 "그걸 아예 삭제해버리려고 만든거긴 했죠."고 적었다. 자동화의 반대편에 있는 선택 — 그 단계를 아예 없애는 것 — 을 먼저 했다는 뜻이다. 그리고 덧붙였다. "36년전에 아예 대놓고 HBR논문으로 “자동화고 나발이고 걍 없애라”를 돌직구로 말한 논문이 있었을줄은."

이튿날 오후, 에르메스단 방에서는 정반대 방향의 이야기가 길게 이어졌다. 비개발자인 한 참가자가 5인 이하 사업장의 접수 업무를 AI로 구현해보고 싶다며 무엇부터 배워야 하는지 물었다. 답은 도구 이름이 아니라 순서였다. 다른 참가자는 먼저 그 일을 하는 사람을 관찰해 프로세스로 정리하라고 했고, 여기서 가장 흔한 실수를 이렇게 못박았다. "내가 놓친게 있어서 ai 가 제대로 말을 안듣는겁니다." 지시가 충분히 명확했는데 AI가 못 알아듣는 게 아니라, 내가 빠뜨린 게 있다는 전제로 시작하라는 것이다.

그 다음 단계도 사람을 가르치는 절차와 같은 모양이었다. 한 번 시켜보고, 바보 같은 실수를 하면 로그와 사고 과정을 열어본 뒤 "오로지 에이전트 입장에서 왜 그런 실수를 했는지 고민하고 그런 실수를 안하도록 공감하며 잡아줍니다." 그리고 몇 바퀴를 돈 끝에야 비용을 알 수 있다고 했다. "사람쓰는게 결과적으로 더 쌌는지 아닌지는 이때가 되어서야 알 수 있습니다." 방 안에서는 이 결론에 씁쓸한 공감이 붙었다. "다똑같이 한번씩 해본사람들은 '사람'부터 공부하자고 하는게 역시.."

두 방은 서로를 참조하지 않았다. 인용 시각도 다르고, 한쪽 이야기가 다른 방으로 넘어간 흔적도 이번 창에는 없다. 그런데 두 대화는 같은 질문의 앞뒤에 서 있다. 더배러 쪽은 무엇을 자동화하지 않을지를 먼저 정하라고 하고, 에르메스단 쪽은 자동화하기로 정한 것을 어떻게 가르칠지를 말한다.

실무에서 이 둘은 순서 문제로 읽는 게 안전하다. 없앨 수 있는 단계를 남겨둔 채 가르치기부터 시작하면, 사라져야 할 일을 정성껏 자동화하게 된다. 반대로 없애기만 앞세우면 반드시 남는 일을 어떻게 맡길지에 대한 답이 없다. 두 방의 결론이 공통으로 가리키는 지점은 도구 선택이 아니라 그 일의 정의를 다시 쓰는 작업이었다.