AI를 잘 쓰는 사람과 못 쓰는 사람을 가르는 질문이 있습니다.
"그거 내가 직접 하면 더 빠르지 않나요?"
이 질문을 한 번도 안 해본 사람은 없을 거예요. 저도 했거든요. 창업 초기에 이메일 하나 쓰면서 "이걸 Claude한테 맡기면 프롬프트 짜고, 다듬고, 다시 맥락 설명하고 — 그냥 내가 쓰는 게 낫겠다"고 생각했어요. 실제로 그 이메일 하나만 놓고 보면 맞는 말이기도 했고요.
근데 거기서 멈추면 안 됐습니다.
AI 업무 효율은 시스템 단위로 측정한다
"내가 더 빠르다"는 판단은 틀리지 않아요. 다만 측정 단위가 틀렸습니다.
이메일 한 통, 회의록 하나, 일정 확인 한 번 — 태스크 단위로 보면 내가 직접 하는 게 더 빠를 수 있어요. 문제는 우리가 하루에 그런 태스크를 수십 개씩 한다는 겁니다. 그리고 그 태스크들 사이를 오가면서 맥락을 전환하는 비용이 눈에 보이지 않습니다.
서울에서 부산까지 간다고 생각해보세요. KTX를 타려면 셋업이 필요합니다. 티켓을 예매하고, 서울역이나 수서역까지 이동하고, 시간에 맞춰 플랫폼에서 기다려야 해요. 이 과정만 놓고 보면 택시보다 훨씬 느립니다. 택시는 지금 바로 타면 되니까요.
근데 한번 KTX에 올라타면 서울에서 부산까지 논스톱입니다. 반면 택시로 서울에서 부산까지 가려면 매 구간 갈아타면서 대기하고, 목적지를 다시 설명하고, 결제하고 — 이 비용이 구간마다 반복됩니다. 셋업 비용이 제로인 대신, 누적 비용이 계속 쌓이는 거예요.
AI도 같은 구조입니다. 프롬프트 세팅하고, 워크플로우 만들고, 맥락을 입력하는 초기 셋업 비용이 있어요. 그리고 셋업이 끝나도 바로 논스톱은 아닙니다. AI의 아웃풋을 교정하고, 정확도를 올리는 구간이 뒤따릅니다. 실무자 입장에서는 이 구간이 가장 답답해요. "이걸 고치느니 내가 처음부터 하는 게 낫지" 하는 생각이 드는 시점이 바로 여기입니다.
근데 이건 개인 태스크 단위의 체감입니다. 조직 전체로 시야를 넓히면 얘기가 완전히 달라집니다. 그 셋업과 교정 구간을 넘긴 뒤에 조직이 얻는 것 — 모든 미팅의 맥락이 축적되고, 누가 담당해도 같은 퀄리티의 팔로업이 나가고, 데이터가 CRM에 자동으로 쌓이는 구조 — 이건 택시를 아무리 빨리 갈아타도 절대 만들 수 없는 겁니다.
이메일 한 통에 숨은 8분: AI 워크플로우가 바꾸는 것
예전에 제가 고객한테 팔로업 이메일을 직접 쓸 때를 떠올려봤어요. 3분이면 충분했습니다. 빠르죠.
근데 그 3분 뒤에 뭐가 따라오는지를 한 번도 계산해본 적이 없었습니다. 이메일 한 통을 보내고 나면 실제로 이런 일이 벌어집니다.
Gmail에서 이메일 작성 → 3분
캘린더 열어서 다음 팔로업 일정 등록 → 1분
Salesforce 로그인해서 활동 기록 남기기 → 2분
팀 슬랙 채널 찾아서 공유 메시지 작성 → 1분
그 사이사이 툴 전환 (Gmail → 캘린더 → Salesforce → Slack) → 1분
다 합치면 이메일 한 통에 엮인 총 시간은 7~8분입니다. 이메일 자체는 3분이지만, 그 뒤에 딸려오는 후속 작업과 스위칭 코스트가 이메일보다 더 큽니다.
지금은 Claude에서 같은 일을 처리하면 흐름이 완전히 달라집니다. 이메일 초안이 나오면서 동시에 "다음 팔로업은 언제 할까요?"라는 질문에 바로 답해서 캘린더에 넣을 수 있어요. 그 고객 관련 Salesforce 기록도 같이 업데이트할 수 있고요. 세일즈포스에 직접 로그인할 필요가 없습니다. 맥락을 이미 Claude가 갖고 있으니까 별도로 설명할 필요도 없습니다. 한 곳에서 5분이면 끝납니다.
이메일 하나만 보면 제가 느렸죠. 근데 그 5분 안에 이메일, 캘린더, CRM 업데이트, 팀 공유까지 다 끝났어요. 예전에는 7~8분 걸리면서 네 개의 툴을 오갔던 작업이, 한 곳에서 5분에 끝난 겁니다.
같은 시간 안에 다른 일을 한 겁니다.
AI 미팅 자동화: 회의 끝나고 12분이면 끝나는 구조
가장 크게 체감한 건 회의 처리입니다.
1시간짜리 미팅을 하고 나면 해야 할 일이 있습니다.
회의록 정리
다음 액션 아이템 정리
팀에 공유할 메시지 작성
Salesforce에 활동 기록 남기기
블로그 글감이나 가설 검증 포인트로 쓸 만한 인사이트 발굴
예전에는 이게 다 따로따로였거든요. 회의록은 노션에서, 액션 아이템은 슬랙에서, Salesforce는 별도 로그인해서, 팀 공유는 또 다른 채널에서. 합치면 한 시간도 넘게 걸렸습니다. 그리고 솔직히 그렇게 해도 퀄리티가 좋지 않았습니다.
왜 퀄리티가 안 나왔냐면, 사람이 미팅 내용을 정리할 때는 필연적으로 자기 해석이 들어가거든요. 고객이 한 말을 내가 이해한 대로 축약하고, 중요하다고 생각한 것만 남기고, 나머지는 빠집니다. 고객이 특정 단어를 세 번 반복했다든가, 어떤 주제에서 톤이 바뀌었다든가 — 이런 건 제 기억에서 사라집니다. 미팅이 끝나고 30분만 지나도 벌써 세부 맥락이 날아가기 시작합니다.
지금은 회의 중에 녹음만 합니다. 그게 전부입니다. 회의가 끝나고 12분 정도 지나면 방금 말한 것들이 전부 나와 있어요. 제가 직접 만들 수 없는 수준으로요. 회의 중에 제가 어떤 말투로 말했는지, 고객이 어디서 반응했는지, 어떤 단어를 반복했는지 — 이런 게 다 살아있는 회의록이 나오거든요. 그리고 그 위에 액션 아이템, Salesforce 활동 기록, 팀 공유 메시지까지 같이 생성됩니다.
저는 같은 퀄리티를 직접 만들 수 없습니다. 사람의 기억은 이미 편집된 상태이기 때문에, 원본 데이터를 갖고 있는 AI와 애초에 경쟁이 안 됩니다.
AI 업무 위임의 심리적 저항: "이건 내가 해야 하는 거 아닌가?"
솔직히 이 전환이 처음부터 편하지는 않았습니다.
고객에게 간단한 팔로업 이메일 하나 보내는 것도 AI가 대신 써서 보낸다고 했을 때, 처음 든 생각은 "그래도 이건 직접 써야 하는 거 아닌가?"였어요. 회의록도 마찬가지입니다. "내가 한 번은 읽어봐야 하지 않나?" 하는 생각. "이거는 AI가 못하지 않을까?" 하는 의심. 다 겪었습니다.
이 저항감의 뿌리는 "이건 사람이 해야 해"라는 전제입니다. 그 전제가 너무 오래되고 당연해서 의심 대상이 아니었던 겁니다. 그런데 이 전제를 가만히 들여다보면, 우리가 과거에도 똑같은 패턴으로 저항했던 것들이 보입니다.
10년 전에 전자계약으로 서명해도 되냐는 질문에 "당연히 종이 계약서에 도장 찍어야지"라고 답하던 시절이 있었어요. 5년 전에 화상회의로 미팅을 해도 되냐는 질문에 "직접 만나야 예의지"라고 하던 시절도 있었습니다. 지금 와서 보면 웃기지만, 그때는 진심으로 그렇게 믿었습니다. "이건 사람이 직접 해야 해"라는 전제가 그 시대의 상식이었으니까요.
지금 "AI가 쓴 메시지를 그대로 보내도 되나?"라는 질문도 같은 구조입니다. 종이 계약서가 그랬고, 화상회의가 그랬듯이 — 돌아보면 시대적 관성이었다는 걸 알게 될 가능성이 높습니다.
그 전제를 한 번 뒤집으면 질문 자체가 바뀝니다. "이건 내가 해야 하는 거 아닌가?"가 "이건 AI가 왜 안 하고 있지?"가 되거든요. 이 전환이 생기면 행동이 달라집니다. 되게 만들 방법을 찾게 됩니다.
AI 활용이 안 될 때 필요한 디버깅 마인드셋
AI가 뭔가 원하는 대로 안 될 때 두 가지 반응이 있습니다.
하나는 "역시 AI는 여기까지야"라고 결론짓는 겁니다. 거기서 멈추죠. 다른 하나는 "아, 이 부분은 내가 아직 최적화를 못 했구나"라고 생각하는 거예요. 이쪽은 계속 파게 됩니다.
엔지니어가 코드를 짜다가 에러가 나면 "이 언어로는 안 되는구나"라고 하지 않습니다. 디버깅을 합니다. 에러 메시지를 읽고, 로그를 확인하고, 한 줄씩 추적해서 원인을 찾아요. 그리고 고칩니다. 그 언어가 할 수 있는 일의 범위를 이미 전제하고 있으니까, 안 되는 건 내 코드의 버그라고 보는 겁니다.
AI 네이티브로 일한다는 건 이 디버깅 마인드셋을 업무 전반에 가져오는 겁니다. 모든 게 가능하다는 걸 전제로 깔고, 막히는 부분이 나오면 그게 내가 풀어야 할 버그라고 보는 것. AI한테 보고서를 시켰는데 결과가 마음에 안 들면, "내가 뭘 빠뜨렸지?"를 먼저 물어봅니다.
맥락을 충분히 줬나? 이 고객의 히스토리, 이전 미팅에서 나온 이슈, 우리 제품의 포지셔닝까지 전달했나?
지시가 모호하지 않았나? "잘 정리해줘"라고 했는데, "잘"이 뭔지 정의하지 않은 건 아닌가?
데이터가 부족하지 않았나? 미팅 녹취 전문을 줬나, 아니면 내가 기억나는 대로 세 줄 요약해서 줬나?
한 번에 너무 많은 걸 시키지 않았나? 분석, 요약, 액션 아이템, 이메일 초안까지 한꺼번에 요청한 건 아닌가?
원하는 결과물의 형태를 보여줬나? "이런 식으로 해줘"라는 예시 하나가 프롬프트 열 줄보다 나을 때가 많습니다.
실제로 이 프레이밍 하나가 행동을 완전히 바꿉니다. 저도 처음에는 Claude가 원하는 결과를 안 줄 때 "역시 한계가 있네"라고 넘겼거든요. 근데 디버깅 프레이밍으로 접근하기 시작하면서 — 프롬프트를 바꿔보고, 맥락을 추가하고, 단계를 나눠보고 — 안 풀리던 것들이 풀리기 시작했어요. 제가 AI를 다루는 방식이 정교해진 겁니다.
세일즈포스에서 '안 된다'는 공식 답변을 받았을 때도 같은 접근이었습니다. 공식 지원이 안 된다고 했지만, 그건 내가 풀어야 할 문제였고, Claude와 함께 직접 만들었거든요.
AI 업무 자동화의 복리 효과: 사이클이 만드는 차이
"내가 더 빠른데"라는 생각이 틀린 건 아닙니다. 그 시점에는 맞는 말입니다.
근데 AI를 시스템으로 쓰기 시작하면 사이클이 생깁니다. 제가 매일 겪고 있는 사이클이 이겁니다.
고객 미팅을 녹음한다
녹음에서 회의록과 인사이트가 자동으로 나온다
그 내용이 Salesforce에 기록된다
기록된 맥락이 다음 팔로업 이메일의 입력이 된다
이메일 기록이 다시 다음 미팅 준비 자료가 된다 → 1번으로 돌아간다
이 구조는 피드백 루프입니다. 제가 이메일 초안을 고치면 그게 피드백이 되어 다음 초안의 퀄리티가 올라갑니다. 회의록에서 제가 어떤 인사이트를 뽑아 쓰는지를 AI가 익히면, 다음 회의록에서는 그 패턴에 맞춰 먼저 정리해줍니다. 교정이 쌓일수록 교정할 게 줄어드는 구조예요.
이 사이클이 한 바퀴 돌 때마다 AI가 갖고 있는 맥락이 두꺼워집니다. 이 블로그도 같은 구조입니다. 미팅에서 얻은 인사이트가 글감이 되고, Claude에서 글을 쓰고 MCP로 발행까지 한 곳에서 끝납니다.
맥락이 두꺼워지면 아웃풋 퀄리티가 올라갑니다. 처음에 이메일 초안을 받으면 70% 정도만 쓸 만해서 나머지를 직접 고쳐야 했어요. 근데 미팅이 3번, 5번, 10번 쌓이면서 Claude가 이 고객과의 대화 톤, 이전에 논의한 이슈, 제가 자주 쓰는 표현까지 알게 되니까 — 어느 순간부터 "보내도 되겠다"만 판단하면 되는 수준이 됐습니다. 제가 검토하고 수정하는 시간이 점점 줄어든 겁니다.
태스크들이 서로를 강화하는 구조가 만들어집니다. 이게 복리입니다.
"AI를 오래 쓰면 좋아진다"는 말은 절반만 맞습니다. 그냥 오래 쓰는 건 의미 없습니다. 쌓인 맥락이 다음 일의 입력이 되는 구조를 만들었을 때 비로소 복리가 작동합니다. 그리고 이 구조는 일찍 시작한 사람일수록 유리합니다. 오늘 시작한 사람과 6개월 뒤에 시작한 사람의 차이는 6개월치 시간이 아닙니다. 맥락의 두께가 다르고, 그 두께 위에서 만들어지는 아웃풋의 퀄리티가 다르고, 그 퀄리티 차이가 매일 복리로 쌓이는 거니까요.
그래서 이 셋업 비용을 기꺼이 지불한 사람만 6개월 뒤에 완전히 다른 자리에 있게 됩니다.
AI 네이티브는 전제를 바꾼 사람이다
"모든 게 된다"는 전제 위에서 안 되는 부분을 최적화하는 사람. 더 정확히 말하면, "이건 내가 해야지"에서 "이건 AI가 왜 안 하고 있지?"로 질문이 뒤집힌 사람입니다.
앞으로 태어나는 세대들은 이 전제를 이미 갖고 시작합니다. AI가 얼마나 강력한지 아는 채로 자라니까요. 반면 지금 세대는 "그래도 이건 사람이 해야 돼", "그래도 이건 AI가 할 수 없어"라는 저항감과 매일 싸워야 합니다. 이 저항감이 AI 네이티브가 되지 못하는 가장 큰 장벽입니다. AI가 어디까지 할 수 있는지에 대해 스스로 상한선을 긋는 순간, 그 선 너머의 가능성은 전부 닫힙니다.
창업 초기에 이메일 하나 직접 쓰는 게 더 빠르다고 생각했던 저도, 지금은 그 이메일을 포함한 모든 후속 작업이 하나의 사이클 안에서 돌아가는 걸 매일 경험하고 있습니다. 그 전제 하나가 시작점을 바꿨고, 시작점이 바뀌니 결과가 달라졌습니다.
오늘 하루 업무 중에 "이건 내가 직접 해야지"라고 생각한 게 있다면, 한 번만 뒤집어 보세요. "이건 AI가 왜 안 하고 있지?"