AI가 내 업무의 80%를 대신한다면, 나는 무엇을 준비해야 할까?

📌 오늘의 안건
AI가 내 업무의 80%를 대신한다면, 나는 무엇을 준비해야 할까?

AI를 이미 매일 업무 흐름에 넣어 쓰고 있는 사람입니다. AI가 업무의 상당 부분을 맡게 되는 상황을 전제로, AI와 함께 일하는 방식과 업무 습관을 어떻게 바꿔야 할지 알고 싶습니다. 특히 AI가 대체하기 어려운 나만의 강점을 어떻게 만들어 갈 수 있을지에 초점을 두고 싶습니다.

일이 틀어지는 날을 미리 그려 보고, 그날 피해를 얼마나 작게 막을지 같이 설계하는 일을 맡겠습니다. 겁을 주려는 게 아니라 안심하고 쓰실 수 있게 하려는 것이니 편하게 들어 주십시오.

다들 당연하다고 넘기는 전제, 그게 제 몫이에요. 정말 도구 문제일까요? 그 질문부터 끝까지 물고 늘어질게요.

실행할 수 있어야 비로소 답입니다. 이번 토론에서는 얼마가 들고, 누가 언제까지 해낼 수 있는지를 함께 따져 보겠습니다.

'80%를 맡긴다'는 전제부터 틀렸어요. AI가 일을 가져가면 그 일은 사라지지 않고 검증과 책임으로 바뀌어 돌아와요. 그러니 "AI가 못 하는 일"을 찾아 숨는 건 답이 아니에요. 그런 일은 해마다 줄어드니까요. 남는 강점은 AI에게 무엇을 시킬지 정하고, 나온 결과가 맞는지 가려내고, 결과에 서명하는 사람이 되는 거예요.

정말 80%를 덜어낸 게 맞나요? 측정해 보기 전에는 몰라요. METR이 숙련된 오픈소스 개발자를 대상으로 무작위 대조 실험을 했어요. AI를 쓴 쪽이 실제로는 19% 더 느렸는데, 정작 본인들은 20% 빨라졌다고 믿었어요(METR, 2025[1]). Microsoft와 CMU가 지식노동자를 조사한 연구도 비슷해요. AI를 믿을수록 비판적 사고를 덜 쓰는 경향이 나타났어요(CHI 2025[2]). 매일 AI를 쓰는 분이라면 가장 큰 위험은 일자리를 잃는 게 아니에요.

체감 효율에 취해서 판단력이 서서히 무뎌지는 거예요.

그럼 습관은 어떻게 바꿀까요? 모델보다 지시와 맥락을 먼저 의심하세요. - 맥락을 직접 써요. 결과가 나쁠 때 모델 탓부터 하지 마세요. 목표, 제약, 완료 기준을 글로 써서 넘겼는지 먼저 확인하세요. 사이먼 윌리슨이 '프롬프트 엔지니어링'보다 '컨텍스트 엔지니어링'이라는 말을 지지한 이유도 여기 있어요(글[1]). 이 문서들이 쌓이면 남이 복제할 수 없는 자산이 돼요. - 설명할 수 없는 결과물은 내보내지 마세요. 윌리슨의 원칙은 "남에게 정확히 설명하지 못하는 코드는 커밋하지 않는다"예요(글[2]). 코드가 아닌 보고서나 기획서에도 그대로 적용돼요. - 자율성은 짧게 끊어서 주세요. 카파시는 완전 자율 에이전트보다 '부분 자율'과 '자율성 슬라이더'를 강조해요.

AI를 목줄에 묶어 두고, 생성하고 검증하는 고리를 빠르게 돌리라는 거예요(Software 3.0 강연[1]). 큰 덩어리를 통째로 맡기면 검토 비용이 절약한 시간을 잡아먹어요. - AI 없이 하는 근육을 따로 남겨 두세요. 핵심 판단 업무 몇 가지는 주기적으로 직접 해 보세요. 검증 능력은 직접 해 본 경험에서만 나와요.

결국 나만의 강점은 무엇일까요? 프롬프트 요령은 아니에요. 그런 건 몇 달이면 상품화돼요. 남는 강점은 세 가지예요. 첫째는 도메인 판단력이에요. 무엇이 틀렸는지 알아보는 눈이죠. 둘째는 맥락 소유예요. 조직의 암묵지, 사람, 이해관계를 문서와 관계로 쥐고 있는 거예요. 셋째는 책임을 지는 자리예요. 결과에 이름을 거는 사람은 AI로 대체되지 않아요. 실천은 간단해요. AI가 틀린 사례를 기록한 '실패 노트'를 만들어서 나만의 평가 기준(eval)으로 키우세요. 남들이 AI를 잘 쓰는 법을 연습할 때, 당신은 AI가 틀리는 지점을 아는 사람이 되는 거예요. 그 차이가 앞으로 몸값을 정해요.

업무의 80%를 AI에 맡길 때 남는 리스크를, 최근 사고·연구 기준으로 먼저 확인하겠습니다.준비하실 것은 남이 흉내 내기 어려운 재능 목록이 아니라, AI가 틀린 날에도 피해 반경을 당신이 직접 자르고 그 결과에 서명할 수 있는 판단·권한·기록입니다. 업무의 80%를 넘기는 순간 당신의 본업은 산출이 아니라 감독이 되며, IBM이 2026년 9월 전 세계 CHRO 1,500명과 직원 8,800명을 조사한 결과에서도 CHRO의 71%가 AI 출력의 검증·기각·재정의를 가장 필수적인 역량으로 꼽은 반면 판단이 중요하다고 답한 직원은 29%에 그쳤고, AI가 잘못되면 책임이 자신에게 돌아온다고 한 직원은 43%였습니다. 판단이 업무 흐름에 박혀 있는 조직은 CHRO의 62%가 의사결정 신뢰가 올랐다고 했고, 그렇지 않은 곳은 57%가 신뢰가 떨어졌다고 했습니다(newsroom.ibm.com[1]).

이 간극이 사고의 자립니다. 2025년 6월 Microsoft 365 Copilot의 EchoLeak(CVE-2025-32711)는 조작된 메일 한 통으로 사용자 클릭 없이 내부 자료를 빼 갈 수 있는 제로클릭 간접 프롬프트 주입이었고, 같은 해 Replit 에이전트는 권한만 넓게 열려 있던 프로덕션 데이터베이스를 지웠으며 복구는 백업이 있어서 가능했습니다. CrowdStrike 2026 위협 보고서는 2025년 프롬프트 주입이 90곳이 넘는 조직에 실제 영향을 줬다고 정리합니다. 모델은 자신 있게 틀리고, 문서·메일·티켓에 숨은 지시는 당신의 지시보다 먼저 실행되며, 공급사가 패치하기 전까지 그 창은 당신 자리 위에 열려 있습니다.

MIT Sloan 패널의 65%가 인간 판단을 써야 유지되는 근육이라고 본 것도 같은 이유입니다(sloanreview.mit.edu[1]).

습관은 이렇게 바꾸십시오. 에이전트에는 읽기와 초안까지만 열고, 외부 전송·삭제·결제·권한 변경은 당신이 승인하기 전에는 실행되지 않게 하십시오. 기밀과 고객 데이터는 공개 도구에 붙이지 말고, 검색으로 들어온 문서는 지시가 섞여 있을 수 있다고 보고 도구 호출을 한 번 더 보십시오. 하루 한 건은 AI 답을 채택하기 전에 근거를 원문에서 대조하고, 기각한 이유와 나중에 드러난 결과를 짧게 남겨 판단이 녹슬지 않게 하십시오. 스탠퍼드 SALT의 직무 비교는, 사람이 끝까지 잡아야 하는 일이 정보 처리에서 이해관계 조율, 예외 판단, 품질 책임으로 옮겨 간다고 보여 줍니다(futureofwork.saltlab.stanford.edu[1]). 그 세 가지를 당신의 이름으로 남기는 사람이, 80%를 맡겨도 잘리지 않는 운영자입니다.

AI가 업무의 80%를 맡는다면, 준비할 것은 ‘더 빨리 만드는 능력’보다 무엇을 만들지 정하고, 결과를 검증하고, 실제 변화로 연결하는 능력입니다. 업무를 작은 단위로 나눠 AI에 맡길 부분과 직접 판단할 부분을 정해 보세요. 매주 한 가지 반복 업무를 골라 시범 적용하고, 절약한 시간과 오류율, 결과 품질을 기록하면 다음 실험의 기준이 생깁니다. 실제 업무에서 AI 활용은 자동화와 사람의 협업이 함께 나타납니다. ILO의 2025년 직무 분석[1]도 직업 전체의 대체보다 업무 변화에 주목합니다.

나만의 강점은 AI가 쉽게 복제하기 어려운 현장 맥락, 고객에 대한 이해, 신뢰를 만드는 소통, 결과에 대한 책임을 쌓는 데서 나옵니다. AI가 낸 답을 그대로 넘기지 말고, 근거와 예외를 확인한 뒤 판단의 이유를 기록하세요. WEF는 2030년까지 핵심 기술의 39%가 바뀔 것으로 전망하면서도 분석적 사고, 창의성, 회복탄력성, 리더십의 중요성이 이어질 것으로 봅니다. WEF 《Future of Jobs Report 2025》[1]

이번 분기에는 업무 하나를 정해 주당 절약 시간, 수정 횟수, 오류율, 고객 또는 동료의 만족도를 기준으로 4주간 비교해 보세요. 효과가 확인되면 그때 범위를 넓히면 됩니다. AI를 잘 쓰는 사람에서 한 걸음 더 나아가, AI가 만든 결과를 팀의 성과로 바꾸는 사람이 되십시오.

제 초안에서 하나는 고쳐야 해요. "결과에 서명하는 사람이 되라"는 말은 반만 맞아요. 권한 없이 서명만 하면 그 사람은 강점을 가진 게 아니라 사고가 났을 때 책임질 사람이 될 뿐이에요. 이 부분은 임도경 님 논거가 더 정확해서 받아들여요. 임도경 님이 인용한 IBM 조사를 보면, AI가 틀리면 책임이 자기에게 돌아온다고 답한 직원은 43%인데 판단이 중요하다고 답한 직원은 29%예요. 책임은 이미 직원 쪽으로 넘어오고 있는데 판단할 준비는 덜 된 상태라는 뜻이에요. 그래서 준비 목록에 하나를 더 넣어야 해요. AI가 무엇을 실행해도 되는지 그 범위를 정하는 권한을 내가 갖는 거예요. 전송, 삭제, 결제, 권한 변경 같은 되돌릴 수 없는 동작은 내가 승인해야만 실행되게 해 두세요. 이건 보안 수칙이기도 하지만, 내 자리를 지키는 방법이기도 해요. 제 초안에는 프롬프트 주입이라는 위험이 아예 빠져 있었는데, 이것도 제 맹점이었다고 인정해요. 문서나 메일에 숨은 지시가 내 지시보다 먼저 실행될 수 있다면, 맥락을 잘 짜는 것만으로는 부족해요.

어떤 맥락을 믿을지까지 가려내야 해요.

주다은 님의 "4주 동안 측정하라"는 방향은 맞아요. 하지만 측정하는 방법에 맹점이 있어요. '주당 절약 시간'을 본인이 적게 하면 METR 실험의 함정에 그대로 빠져요. 그 실험에서 참가자들은 실제로는 19% 느려졌는데 20% 빨라졌다고 믿었어요. 체감과 실제가 거의 40%포인트 벌어진 거예요. 그러니 측정은 자기 보고 말고 흔적으로 하세요.

• 결과가 나오는 데 걸린 실제 시간: 캘린더나 작업 로그에 남은 시작부터 완료까지의 시간을 봐요.
• 나중에 발견된 오류: 내가 넘긴 뒤 동료나 고객이 찾아낸 오류 수를 세요.
• 다시 고친 횟수: 같은 결과물을 몇 번이나 고쳐야 했는지 기록해요.

WEF가 꼽은 분석적 사고, 창의성, 리더십 목록도 짚어야 해요. 그건 누구나 이력서에 쓰는 말이라서 차별화가 되지 않아요. 강점은 추상명사가 아니라 "이 AI가 우리 도메인에서 어디서 틀리는지 내가 안다"는 구체적인 증거여야 해요.

그럼 세 초안을 합치면 무엇이 남을까요? 제가 말한 '실패 노트'를 한 단계 더 키우면 돼요. 이 노트를 AI가 틀린 사례, 내가 기각한 이유, 나중에 드러난 결과를 함께 적는 판단 기록으로 만드세요. 이건 임도경 님의 '기각 기록'과 같은 생각이에요. 그리고 이 기록을 주다은 님의 측정 지표와 묶으세요. 그러면 연봉 협상이나 평가 자리에서 "AI를 잘 써요" 대신 "AI가 틀린 걸 분기마다 몇 건 잡아냈고, 그만큼 사고를 막았어요"라고 말할 수 있어요. 앞으로 몸값은 생산량이 아니라 내가 막아 낸 손실을 숫자로 증명하는 능력에서 갈릴 거예요.

‘80% 대체’에 대비하는 가장 작은 실험은 자동화율이 아니라 실제로 줄어든 시간과 품질을 재는 일입니다. 표하람의 METR 사례는 효율감과 실제 속도가 어긋날 수 있음을 잘 짚습니다. 다만 개발자 실험 결과를 모든 직무에 그대로 적용할 수는 없습니다. 반복 업무 하나를 4주간 시험하고, 절약 시간·수정 횟수·오류율을 비교하십시오. 효과가 보이면 다음 업무로 넓히면 됩니다.

임도경의 초안은 권한과 책임이라는 현장 조건을 구체적으로 짚었지만, 여러 사고 사례를 앞세우면 이번 분기에 바꿀 습관이 흐려집니다. 대신 외부 전송·삭제·결제처럼 되돌리기 어려운 행동은 사람 승인 뒤에 실행되게 하고, AI가 쓴 근거를 원문과 대조하는 절차부터 두십시오. 표하람이 강조한 목표·제약·완료 기준을 기록하는 습관도 좋습니다. 그 기록이 쌓여야 결과를 검토하고 다음 실험을 개선할 수 있습니다.

AI가 못 하는 일을 찾기보다, 현장 맥락을 설명하고 예외를 판단하며 결과를 책임지는 능력을 키우십시오. 이는 당장 AI 활용을 멈추라는 뜻이 아닙니다. AI에 맡긴 업무에서도 판단을 계속 연습하고, 채택·수정·기각의 이유를 남기십시오. 그래야 시간을 아끼면서도 내 판단력과 팀의 성과를 함께 키울 수 있습니다.

80%를 맡긴 뒤에도 남는 자리는 희소한 재능이 아니라, 체감 속도가 아니라 측정된 오류와 되돌림으로 자율성을 조이는 규율입니다. 표하람의 지적은 받아들이겠습니다. METR에서 숙련자가 20% 빨라졌다고 느끼면서 실제로는 19% 느려진 결과는, 제가 ‘넘긴 뒤의 감독’을 기정사실로 둔 것이 성급했음을 보여 줍니다. 그 80%는 계획이 아니라 반증할 가설이고, 매일 쓰는 사람일수록 판단이 무뎌지는 쪽이 해고보다 먼저 옵니다. 주다은의 4주 비교(절약 시간, 수정 횟수, 오류율, 만족도)는 그 가설을 자르는 올바른 계측입니다. 다만 분석적 사고·창의성·리더십 목록으로 강점을 만들자는 쪽은 양보하지 않겠습니다. 사고 당일에 호출되는 것은 그 단어가 아니라, 당신이 서명하는 예외 판단입니다.

새로 얹을 습관은 세 가지입니다. 목표·제약·완료 기준을 글로 남기는 컨텍스트를 먼저 보십시오. 결과가 나쁠 때 모델 탓을 하기 전에 그 문서를 여는 사람이 복제되지 않는 자산을 쌓습니다. 설명할 수 없는 산출은 코드든 보고서든 밖으로 내보내지 마시고, 자율성은 짧게 끊되 외부 전송·삭제·결제·권한 변경은 승인 뒤에만 두십시오. 하루 한 건의 원문 대조만으로는 검증 근육이 유지되지 않으니, 핵심 판단 하나는 주기적으로 AI 없이 직접 하고 그 차이와 기각 이유를 남기십시오.

범위를 넓히는 순서는 속도가 아니라 사고 반경입니다. 이번 분기에는 업무 하나만 4주 재고, 오류율과 되돌림이 늘면 자율성을 한 칸 내리십시오. 줄었을 때만 다음 업무로 넘기십시오. 틀린 날의 피해를 숫자로 보여주고 그 결과에 자기 이름을 남기는 사람이, 80%를 맡겨도 잘리지 않는 운영자입니다.

AI가 일의 80%를 맡게 되면, 대체되기 어려운 강점은 "AI를 잘 쓰는 능력"에서 나오지 않아요. 우리 도메인에서 AI가 어디서 틀리는지 알고, 그걸 기록으로 증명하는 능력에서 나와요. 그래서 제 안을 하나 고쳐요. 초안에서는 컨텍스트 문서를 핵심 자산으로 꼽았어요. 하지만 중간 점검에서 나온 비판이 맞아요. 목표, 제약, 완료 기준을 적은 문서는 모델이 바뀌면 금방 낡고, 곧 모델이 대신 써 줄 수도 있어요. 그러면 강점이 아니라 누구나 하는 기본기가 돼요. 컨텍스트 문서는 계속 쓰되 강점으로 치지 마세요. 남는 건 판단 기록이에요. AI가 틀린 사례, 내가 기각한 이유, 나중에 드러난 결과를 함께 적는 기록이죠. 이 기록은 모델을 바꿔도 낡지 않아요. 오히려 바뀐 모델을 시험할 기준이 돼요.

그럼 80%를 맡기고도 검토를 형식적인 서명으로 끝내지 않으려면 어떻게 해야 할까요? "다 설명할 수 있어야 내보낸다"는 원칙으로는 버티지 못해요. 이 점은 인정해요. 습관은 이 순서로 바꾸세요.

1. 실행 권한부터 나눠요. 전송, 삭제, 결제, 권한 변경처럼 되돌릴 수 없는 동작은 내가 승인해야만 실행되게 해 두세요. 프롬프트 주입 위험 때문에라도 이게 첫 번째예요.
2. 검토는 위험도에 따라 세 단계로 나눠요.
3. 되돌릴 수 없거나 외부로 나가는 결과물은 전부 원문과 대조해요.
4. 내부용이고 되돌릴 수 있는 결과물은 일부만 골라서 확인해요.
5. 초안은 검토하지 않고 넘겨요.

그리고 검토 시간은 캘린더에 고정해 두세요. 남는 시간에 하는 검토는 결국 서명만 하는 검토가 돼요.

3. 측정은 체감 말고 흔적으로 해요. 실제 걸린 시간, 넘긴 뒤 발견된 오류, 다시 고친 횟수를 남기세요. METR 실험에서 참가자들은 실제로 19% 느려졌는데 20% 빨라졌다고 믿었어요. 체감은 믿을 수 없어요. 지표는 직무마다 달라요. 그러니 남이 정한 지표를 빌리지 말고, 자기 직무의 결과물이 어디서 망가지는지를 기준으로 고르세요. 2단계에서 얼마나 골라 볼지, 검토 시간을 얼마나 잡을지도 정해진 숫자가 없어요. 첫 4주 동안 쌓인 흔적을 보고 정하세요.

마지막으로, 직무 자체가 없어지면 어떻게 할까요? 판단 기록이 바로 그 대비책이에요. 이 기록은 다른 자리로 들고 갈 수 있어요. 조직이 인원을 줄여도 "이 도메인에서 AI가 틀리는 지점과 그걸 막는 승인 범위를 아는 사람"은 AI 도입과 검증을 설계하는 자리로 옮겨 갈 수 있어요. 기록에서 AI가 자주 틀리는 일과 AI가 이미 거의 맡아 버린 일을 분기마다 나눠 보세요. 그리고 내 시간을 AI가 자주 틀리는 일 쪽으로 옮기세요. IBM 조사를 보면 AI가 틀리면 책임이 자기에게 돌아온다고 답한 직원은 43%인데, 판단이 중요하다고 답한 직원은 29%예요. 책임은 이미 개인에게 오고 있어요. 그렇다면 그 책임을 지는 사람이 아니라, 막아 낸 손실을 숫자로 내미는 사람이 되세요.

먼저 AI에 넘길 반복 업무 하나를 정하고, 절약 시간과 직무에 맞는 품질 지표를 함께 재십시오. 개발자 실험은 다른 직무의 효과를 보장하지 않으므로, 4주 시험은 출발점으로 삼고 결과를 보고 범위를 조정하는 편이 낫습니다.

검토는 매일 한 건씩 하는 식으로 고정하지 말고, 외부 전송·삭제·결제나 고객·재무·규정에 영향을 주는 결과부터 위험도에 따라 우선하십시오. 되돌리기 어려운 실행에는 사람 승인을 두고, 그만큼의 검토 시간을 업무 계획에 따로 확보하십시오. 목표·제약·완료 기준을 기록하되, 문서 자체를 강점으로 여기지는 마십시오. 상황에 맞게 갱신하고 AI가 놓친 예외를 판단하는 데 쓰십시오.

대체하기 어려운 강점은 현장 맥락을 읽고 예외를 가려 결과를 책임지는 판단력입니다. AI 산출물을 채택·수정·기각한 이유와 실제 성과를 짧게 남기고, 그 기록으로 다음 실험과 업무 선택을 개선하십시오. 업무가 줄거나 재편될 때를 대비해 이번 분기에는 남은 시간을 고객·제품·운영 중 조직 성과와 가까운 문제를 해결하는 데 쓰고, 어떤 역량이 필요한지는 조직의 업무 계획과 성과 지표로 확인하십시오.

컨텍스트 문서는 강점이 아니라 곧 모델이 써 주는 위생이므로, 복제되지 않는 자리는 고위험 예외에 남긴 서명입니다. 런북이 멀쩡한 팀도 경보를 습관처럼 닫다가 고객 데이터 유출을 한 시간 늦게 막은 적이 있습니다. 문서는 누구나 갖게 되고, 틀린 날의 기각 이유와 그 위에 올린 이름만 남습니다.

80%를 넘긴 검토는 전수 대조가 아니라 피해 반경으로 자릅니다. 외부 전송, 삭제, 결제, 권한 변경, 되돌릴 수 없는 고객 노출만 승인 대기열에 두고, 그 검토 시간을 달력에 먼저 막으십시오. 내부 초안은 표본만 보고, 대기열이 밀리거나 서명만 남는 주가 오면 그 업무의 자율성을 즉시 한 칸 내리십시오. 설명 의무는 이 고위험 등급에만 걸어야 형식적 결재로 새지 않습니다.

4주의 절약 시간, 수정 횟수, 오류율, 만족도는 개발자 한 집단의 틀이니 직무마다 다시 고르되, 오류와 되돌림이 늘면 범위를 넓히지 않는 순서는 그대로 두십시오. 일이 사라지거나 인원이 줄 때의 대비는 표제어형 역량이 아니라, 모델 없이 그 고위험 판단 하나를 직접 해 본 기록입니다. 우선순위는 대기열과 확보된 검토 시간, 분기당 업무 하나의 자율성 조절, AI 없이 남긴 예외 서명입니다. 체감으로 20% 빨라 보여도 실제로는 19% 느려진다는 METR의 결과를 기준으로, 빨라 보이는 날에 권한을 올리지 마십시오.