좀 더 멍청한 사람에게 파는 일
2026년 10월28일
비난의 희열
2026년 11월04일"너하고 이 오토바이 성능하고 혼동하지 마."
이제 어디와 일을 하더라도 함께 일하는 클라이언트 담당 직원들이 AI 네이티브 세대일 때가 많습니다. AI 네이티브 '태생'을 뜻하는 건 아닙니다. 사회에서 일을 시작할 때부터 AI를 사용하는 것이 기본인 세대를 뜻합니다. 그런 분들이 이제 신입 수준이 아닌 실무의 핵심 포지션에서 일을 하고 있습니다. 이 글을 읽는 분들의 대부분이 그런 분들과 일을 하고 있거나, 그 당사자라고 생각하기에 AI 세대와 일을 하면서 든 몇 가지 생각들을 공유하고자 합니다.
먼저, 저는 일 밥을 먹은 지 30년이 넘었습니다. 꼰대, 노땅, 고인물... 편리한 대로 생각하셔도 좋습니다. 다만 그런 논리에서 자주 쓰는 말로, 30년 동안 이 일을 아직 하고 있다면 그 또한 이유가 있을지도요. 어릴 때부터 주로 기술 지향적이었던 데다가 클라이언트의 다양한 업무 체계와 조응할 수밖에 없기에 오래 전부터 SaaS나 제작 프레임워크, 커뮤니케이션 툴, 지금의 다양한 AI 방식까지 가리지 않고 두루 익히는 편입니다. 특히나 지난 몇 년 동안은 다양한 생성형 AI를 나름 열심히 사용하고 실험해 왔습니다. 기술에 대한 반감은 없다고 생각합니다. 오히려 기술을 활용한 새로운 방식을 조직에 소개하는 경우가 많았죠.
너무 많은 문서(파일)들의 무덤
요 몇 년간 진행한 프로젝트들의 업무 폴더를 보면 그 안에 파일이 어마하게 쌓여 있는 걸 볼 수 있습니다. 프로젝트의 파이가 계속 비대해졌냐면 그건 아닙니다. 그러나 과거에 비해 한 프로젝트당 너무나 많은 문서와 이메일이 쌓인다는 것을 알 수 있죠. 클라우드 파일에는 더 많은 문서가 있습니다. 제가 만든 문서의 양은 과거나 지금이나 크게 다르지 않지만 클라이언트의 문서가 몇 배는 많아졌습니다. 왜인지는 다들 잘 아실 겁니다. 문서를 작성하는 일이 너무나 수월해졌기 때문입니다. 문서를 만드는 다양한 이유가 있겠습니다만 가장 중요한 두 가지 이유는 소통된 합의와 결과의 가시성 때문이라고 생각합니다. 상사에게, 조직에게 책 잡히지 않고 책임을 분명히 하기 위한 기록도 소통된 합의에 포함됩니다. 그런데 작금의 문서들은 거의 로그 수준과도 같습니다. 일주일 전 중요한 변경 포인트를 찾으려고 해도 수많은 문서들 중에 윌리를 찾는 것과 같은 수고가 이어집니다. 수많은 문서 속에서 상사에게 '전에 이렇게 결정했는데요'는 '그게 어디에 나와 있고', '어떻게 확인하냐'라는 불공정한 대답을 듣기 일쑤입니다.
"AI와 한 번의 대화 텀만으로도 하나의 문서가 생성될 수 있는 시대."
문서는 주요 전달자에게 핵심이 명확하게 전달되는 것이 최우선입니다. 제가 본 조직의 임원들은 일의 어느 시점부터 그렇게 차곡차곡 쌓이는 문서들을 따라잡는 것을 포기하는 경우도 많았습니다. "그래서 요점이 뭐지?", "그래서 무엇을 결정해야 하는 건데?" 와 같은 말을 할 때면 그걸 열심히 작성한 담당 실무자들의 노고가 안타깝기까지 합니다. 안타깝지만 그 실무진들은 '열심히'는 작성했으나, '효율적으로' 작성하지는 못 한 경우가 많습니다. AI와 한 번의 대화 텀만으로도 하나의 문서가 생성될 수 있는 시대입니다. 문서가 많이 만들어지고 상사에게 많은 문서를 전달하면 일을 많이 하는 것 같고, 심지어 잘하는 것 같기도 합니다. 문서 작업에서 '열심히'는, 내용을 추리기 위한 집요한 사고와 논리를 요구합니다. 내용을 추려내고 우리가 붙잡아야 할 핵심을 골라내서 문서의 양을 또는 갯수를 줄이는 일이 진정 열심히, 그것도 효율적으로 하는 일일 겁니다. 그걸 읽고, 그걸 이해하고, 그걸 활용할 대상에게 적확한 내용과 양을 조율하는 것이 이제 일의 기술이 되었으니까요.
모든 것을 디지털 폼으로 보여줘야 한다는 강박
약속된 소통 프로그램으로, 또는 제작 툴로 서로 의견을 주고받는 것은 이제 효율성을 대변하는 일이 되었습니다. 실제로 일에 있어 시간과 공간의 한계를 비약적으로 극복한 것은 다 이 툴들을 사용한 덕분입니다. 이 툴들은 모두 디지털로 이루어져 있습니다. 기본적으로 우리는 약속된 툴로, 또는 합리적이라고 상호 동의하는 툴을 사용해 소통하는 것을 전제로 이제 업무를 하고 있습니다.
그런데 효율이라고 믿는 일련의 디지털 툴 사용의 뒷면을 보면 많은 부분 효율을 떨어뜨릴 때가 많습니다. 가장 큰 문제는 툴 안에 생각을 가두기 때문이죠. 물론 생각을 가둘 순 없습니다. 하지만 표현해야 하는 양식이 정해져 있다면 그 양식에 맞춰 생각을 표현해야 할 때가 많습니다. 모든 사용자가 그 툴을 극단적으로 자유롭게 사용할 수 있다면 얘기는 다르겠습니다만 아무리 AI 세대라고 해도 그 정도는 모두 다릅니다. 저는 참여하는 모든 회의에 앞서 그 회의실에 화이트보드를 준비해 줄 것을 담당자에게 요청합니다. 다양한 사람들이 회의에 모여 있고 모두가 다른 사람의 장구한 아이디어를 다 따라잡기는 어렵습니다. 아무리 잘 작성한 PPT나 키노트도 장표가 지나가면 그만입니다. 인지의 지점을 어딘가에 써 놓고 또 그림을 그리며 논의가 진행되면 언제나 더 핵심이 단단해지는 것을 경험할 수 있습니다.
한 번은, 피그마(Figma)가 익숙하지 않은 담당자가 개발사의 와이어프레임 피드백을 하는 것을 옆에서 도와준 적이 있습니다. 담당자는 AI 세대라 금세 피그마에 익숙해집니다. 요청 사항을 피그마 양식에 맞게 정확하게 적용해서 피드백을 하더군요. 저는 그 방법이 탐탁치 않았습니다. 아마도 와이어프레임 피드백을 그냥 종이에 그려서 사진을 찍어 이미지를 첨부하는 것이 훨씬 나은 방법이라고 생각했죠. 아니, 약속된 양식이 있는데 왜 원시인처럼 그러냐고 하실 분들이 많을 것 같은데요. 맞습니다. 피그마 툴에 맞게 요청 사항을 그대로 넣으면 개발사에서는 디자인과 개발 언어로 번역 없이 바로 적용할 수 있는 '효율성'이 있습니다. 하지만 실제로 일은 그렇게 진행되지 않습니다. 개발사와 클라이언트 사이에 해당 피드백은 몇 주 동안 지난하게 계속해서 오고 가게 됩니다. 시간을 줄이는 게 효율성이 아니던가요? 최종적으로 적용하지 않을 와이어프레임의 형식을 담당자가 기입한 들 개발사에서는 무용지물입니다.
위의 예에 세 가지 중요한 '효율'의 이유가 있습니다. 첫째, 당연히 담당자가 표현하고자 하는 화면 레이아웃과 작동 로직은 피그마 툴의 와이어프레임 형식에 맞추지 않고 손으로 쓱쓱 그린 것이 더 정확합니다. 즉, 정확히 원하는 바를 '전달'하는 것이 우선이 되어야 하는 것이죠. 둘째, 와이어프레임 형식에 맞게 피드백을 하면 십중팔구 개발사에서는 그것과 거의 똑같은 화면을 디자인합니다. 그 툴이 그것을 편리하게 해 주기 때문입니다. 개발사의 기획자는 그 툴의 언어에 정확히 맞춰 준 피드백을 담당자의 '정확한 요구사항'이라고 생각하게 됩니다. 그래서 피드백 과정이 세 번 네 번 더 이루어지게 되는 겁니다. 담당자는 툴의 양식에 맞춰 줬을 뿐, 생각한 그대로는 아닐 확률이 높으니까요. 셋째, 피드백을 손으로 그리되 '대충' 그리는 것이 좋습니다. 두 번째 이유와 비슷한데, 정확히 그리면 정확히 그대로 구현합니다. 대충 그리면 그제서야 개발사의 창작의 불이 켜집니다. "그 아이디어는 이렇게 구현하면 더 좋을 것 같습니다." 와 같은 개발사의 의견이 나오게 되고 그것이야말로 건설적인 피드백 과정이 되겠지요. 효율로 따지면, 이런 과정이 피드백 시간을 획기적으로 줄일 수 있는 일임을 믿습니다.
누구에게도 실례하면 안 되는 사람들
다양한 사고와 양식을 지닌 사람들이 많아지면서 사회는 관계의 방식과 접점의 온도가 과거와 많이 달라졌습니다. 더 배려하고 누구에게도 실례하지 않기 위한 자세는 옛날 같으면 방어적으로 이해됐을지 몰라도 지금 한국 사회에서는 그것이 '상식'이 된 것 같습니다. 물론, 이는 비상식적이고 독단적인 사람들을 순화하는 긍정적 효과를 가져옵니다. 그러니까, 보편화됐다고 믿는 (조금의 실례도 하면 안 된다는) 양식대로 하지 않으면 무례한 사람이 되어버렸죠. 아마 저는 AI 세대와 일할 때 그들에게 다소 무례한 사람으로 인식되리라 생각합니다.
일이 교과서처럼 진행될 때도 희박한 수준으로 존재하긴 합니다만 대개 프로젝트는 어떤 때는 파고가 높아지거나 급물살을 탈 때도 있고, 완전히 유실될 위기에 직면하기도 합니다. 임기응변이 필요한데, 그것은 서로 우아하게 선을 고수하고 있을 때 발휘할 수 있는 일은 아닙니다. 아마 그럴 때 저는 '무례'해지는 것 같습니다.
제 무례함은 이렇습니다. 급박한 상황에서도 문자로 소통하며 문제를 타개하려 상대가 메시지를 보낼 때, 통화 버튼을 누릅니다. 전화 포비아까지 붙이고 싶지 않습니다만, 일할 때 전화로 하는 것을 꽤나 실례로 생각하는 상대가 많다는 사실에 놀라곤 합니다. 개인의 공간과 시간이 존중받아야 하는 시대에 전화 수신은 예상하지 못한 자기 영역의 끼어들기일 수도 있습니다. 저도 그럴 때가 많으니까요. 하지만 한 시가 바쁜 상황에서 문자 메시지나 슬랙 같은 소통 툴을 사용하는 것은 비효율적일 때가 많습니다. 곡해의 여지가 많고 서로 같은 수준의 이해에 도달하기 위해서는 많은 시간이 할애됩니다. 물론 조직에 보고하거나 공유하기 위해 모든 것을 소통 툴의 기록으로 남겨놔야 하는 이유도 있습니다만 통화 녹음이나 보이스 to 텍스트 변환 툴도 사용할 수 있지요. 메일도 마찬가집니다. 이메일을 채팅 화면과 같이 활용하는 양식도 일이 급박해지거나 이해도를 요하는 순간에는 수화기 버튼을 누르는 게 필요하다고 생각합니다.
"대면했을 때 바디랭귀지의 정보량에는 비할 바가 안 됩니다."
코로나 이후 줌이나 팀즈와 같은 화상 회의는 그야말로 일상이 되었습니다. 상대와 자신의 시간을 절약하는 훌륭한 장치죠. 저도 대부분의 미팅은 줌으로 진행하고 있습니다만 역시나 이해의 난이도가 있는 회의일 경우에는 굳이 대면 미팅을 요청합니다. 고객사는 저의 시간을 배려해서 화상 회의를 늘 제안합니다만 특정 회의들은 줌으로 진행 시, (대면했을 때의 성취를 이루기 위해서는)정신과 육체적 에너지를 엄청나게 고갈 시킵니다. 바디랭귀지의 효율성을 사람들은 간과하곤 합니다. 줌으로도 상대 표정 보고, 목소리의 높낮이 다 들을 수 있지요. 하지만 대면했을 때 바디랭귀지의 정보량에는 비할 바가 안 됩니다. 왕복 두 시간이 걸려도 제가 기꺼이 찾아뵙는다 합니다. 시간이 걸려도 몸을 움직여 얼굴을 맞대고 진행하는 것이 필요할 때가 더 나은 경우가 있습니다. 아니, 많습니다. 문제는 그걸 구분해 내는 일이겠지요. '이런 협의점을 도출해야 하는 미팅에서는', '이런 조정이 필요한 토론에서는' 우린 만나야 합니다. 그게 길게 보면 제 시간을 아끼는 일이기 때문에 그렇습니다. 제 무례함은 끝이 없지요.
너하고 이 오토바이 성능하고 혼동하지 마
강연이나 세미나 요청, 또는 프로젝트 협의 문의 시에 메일을 받을 때 상대가 AI로 작성했는지는 제게 그 전엔 없었던 담당자 또는 그 조직에 대한 첫인상이 되었습니다. 친절한 인사 뒤로 메일의 본문이 완벽한 인과 관계들로 이루어져 있고 온통 당위성으로만 가득 차 있는, AI로 작성된 이메일을 보면 그 담당자와 이 일을 진행할 수 있을까 상상하게 됩니다. 그런 차원에서는 첫인상이라고 하기에 꽤나 큰 척도가 되어 버렸습니다만.
"언제 AI를 쓰고 언제 내 손을 쓰고를 판단하는 그 일 자체가 일의 노련함을 뜻하는 역량."
AI가 완벽하지 않듯, 우리는 완벽하지 않습니다. 완벽은 환상의 관념이지요. 문제는 우리가 어떻게 완벽하지 않은지 인식하는 것이고, 또 어떻게 보완하려고 하는지에 대해 인지하는 것입니다. 그것을 기가 막히게 도와줄 수 있는 것이 AI 고요. 분명, 언제 AI를 쓰고 언제 내 손을 쓰고를 판단하는 그 일 자체가 일의 노련함을 뜻하는 역량일 것입니다. 노력해야 기를 수 있는 역량임은 분명합니다. 노력을 해야 하는 일이라는 걸 알아차리는 것이 우선이겠지요. 기술을 숭배하고 있는지조차 인식하지 못하는 기술 지향주의를 견제해야 하는 이유입니다.
어릴 때 봤던 영화 <비트>에서 정우성이 고소영을 오토바이 뒤에 태우고 질주하자 오토바이에 내려서 고소영이 내뱉는 대사가 있습니다. "너하고 이 오토바이 성능하고 혼동하지 마. 저능아같이 보여." 저는 어릴 때 이 대사가 영화를 통틀어 가장 인상 깊었던 장면이었습니다. 저@아 같은 단어는 사용하면 안 되겠습니다만 그 앞의 말은 여전히 우리가 기술에 올라탈 때 간과하면 안 되는 자기 인식을 가리킵니다.
앤드류와이어스
김해경
