AI가 일을 대신할수록, 사람은 무엇을 해야 할까?

AI가 회의록을 정리하고 코드를 짜주기 시작했어요. 그런데 결과물을 받아 든 다음에도 일이 남아요. 빠진 조건을 찾고 동료에게 설명하고 실제로 쓸 수 있는지 확인해야 하죠. 만드는 시간이 줄었는데 하루는 여전히 바쁠 수 있어요.

지금 연습할 만한 사람의 역할은 풀어야 할 문제를 구체화하고 결과가 쓰이게 만들며 다음 작업에 배움이 남도록 하는 일이에요.

어떤 직업이 끝까지 남을지 예언하려는 글은 아니에요. 작은 회사의 운영 경험, 현장 개발자의 역량을 정리한 영상, AI 교육자의 강한 주장을 나란히 읽으며 내 업무에서 확인할 것을 찾아볼게요.

빨리 만든 결과가 팀의 일을 줄였나요?

빌더 조쉬가 정리한 아크포인트 인터뷰에는 회의록 이야기가 나와요. 작성은 쉬워졌지만 길고 모호한 문서를 받은 사람들이 핵심을 찾느라 더 오래 걸린다면 어떨까요? 인터뷰 속 시간 계산은 이런 상황을 보여주는 가정이에요. 회사에서 측정한 생산성 수치는 아닙니다.

이 인터뷰를 읽을 이유는 생산량을 자랑하는 데서 멈추지 않기 때문이에요. 결과물을 빨리 만드는 사람과 그걸 읽고 판단해야 하는 사람의 일이 연결돼 있다는 점을 짚어요. 내 작업이 빨라져도 다음 사람이 처리할 일이 늘면 팀의 병목은 그대로 남을 수 있죠.

팀에 경험을 남기는 방식도 나와요. 개인이 잘된 작업 방법을 제안하고 대표가 골라 공용으로 쓴다고 설명해요. 결과만 저장하는 대신 왜 그 방법을 골랐는지 남겨야 다음 사람이 판단의 맥락을 이어받을 수 있다는 이야기예요. 이 운영 방식의 효과가 다른 회사에서도 같다고 입증된 것은 아니에요.

다음 사람이 해야 할 일까지 적어보세요

AI로 고객 문의를 요약한다면 요약문 길이만 줄이지 말고 담당자가 다음에 내릴 결정을 먼저 정해보세요. 환불 여부를 판단해야 하는데 구매일과 적용 정책이 빠져 있다면 다시 원문을 찾아야 하니까요.

완료 기준을 ‘요약문을 만들었다’에서 ‘담당자가 필요한 근거를 찾아 판단할 수 있다’로 바꿔보세요. 잘된 사례는 판단에 쓴 정보와 예외까지 남겨 다음 업무에서 다시 확인할 수 있게 하고요. 혼자 일한다면 다음 주의 내가 그 담당자예요.

현장의 모호한 말을 누가 일로 바꾸나요?

노마드 코더는 고객의 업무 현장에 들어가 기술을 적용하는 FDE(Forward Deployed Engineer)를 설명해요. 추천할 구간은 02:31부터예요. 안정적인 구현, 시스템 설계, 고객 업무 파악, 운영 판단, 소통, 개선의 반복을 여섯 가지 역량으로 묶습니다. 영문 대본을 바탕으로 한국어로 옮긴 요약이에요.

특히 고객 업무 파악을 설명하는 문장이 이 글의 질문과 맞닿아 있어요.

“

정리되어 있지 않고 문서도 없는 업무 과정을 실제 기술 명세로 바꾸는 일.

02:46–02:55 · 한국어 번역 ↗

‘문의 처리 자동화’를 맡았다고 해볼게요. 어떤 문의가 급한지, 누구에게 넘겨야 하는지, 예외는 무엇인지 모르면 코드가 있어도 현장에서 쓰기 어려워요. 업무 담당자의 말을 듣고 이 조건들을 정리하는 일, 그리고 같은 선택을 동료와 책임자에게 각각 이해되게 설명하는 일을 연습할 수 있어요.

이 여섯 가지는 발표자가 채용 공고를 읽고 정리한 관점이에요. 모든 직무의 필수 조건이나 취업 보장이 아닙니다. 영상에는 유료 교육 과정 홍보가 포함돼 있고 제목에 나오는 연봉이나 채용 규모는 이 글의 결론을 뒷받침하는 근거로 삼지 않았어요.

기능을 요청하기 전에 질문 세 개를 적어보세요

‘누가 언제 이 결과를 쓰나요?’, ‘어떤 경우에는 자동으로 처리하면 안 되나요?’, ‘제대로 됐는지는 무엇을 보고 판단하나요?’를 먼저 적어보세요. 답을 모르는 항목이 있다면 그걸 아는 사람에게 확인하는 것이 다음 일이에요. AI로 초안을 만들어도 이 질문들의 답까지 자동으로 확보되는 것은 아니니까요.

AI를 못 쓰면 대체된다는 말은 어디까지 받아들일까요?

윤자동은 훨씬 강하게 말해요. 영상에서 AI를 다루는 능력과 오프라인 영업·사람을 대하는 능력을 대비하고 자신도 대체될 수 있다는 생각으로 공부하며 직원들에게 AI를 함께 잘 쓰자고 말한다고 설명합니다.

이 주장은 AI 활용을 팀의 기본 역량으로 기대하는 현업 교육자의 관점을 보여줘요. 다만 여기서 코딩·디자인·영상 편집 직군이 모두 대체된다는 결론으로 건너뛸 수는 없어요. 짧은 영상은 고용 변화를 측정한 자료가 아니고 업무의 일부를 자동화할 수 있다는 것과 직무 전체가 사라진다는 것은 다른 주장이에요.

앞의 노마드 코더가 기술 구현과 현장 이해를 함께 묶었다면 윤자동은 AI 활용을 익혀야 한다는 압박을 더 강하게 전달해요. 둘을 읽고 내릴 실용적인 질문은 ‘나는 살아남을까?’보다 ‘내가 맡은 일 중 무엇을 AI와 해보고 무엇을 내가 이해하고 설명할 수 있어야 할까?’에 가까워요.

사람을 평가하기 전에 업무와 학습 조건을 나눠보세요

‘AI를 잘 쓴다’를 도구 이름을 많이 아는 상태로 두면 기대가 모호해요. 예를 들어 ‘문의 요약 초안을 만들고 빠진 사실을 원문과 대조해 설명할 수 있다’처럼 관찰 가능한 업무로 적어보세요. 팀에서는 필요한 도구와 연습 시간을 함께 마련하고 그 업무에서 도움이 됐는지 확인해볼 수 있어요. 영상의 강한 표현을 곧바로 채용·해고 기준으로 옮길 근거는 없습니다.

그래서 이번 주에는 무엇을 바꾸면 될까요?

세 사례를 관통하는 적용 질문은 이것이에요. 내가 빨리 만든 것 때문에 누군가의 다음 일이 쉬워졌나요? 여기에 답하려면 빨라졌다는 느낌도 확인해야 해요.

AI 평가 연구단체 METR의 2025년 실험은 체감과 측정이 어긋났던 사례예요. 연구팀은 현재 이 결과가 최신 도구의 영향을 반영하지 않는다고 표시하고 있어요. 당시 무작위 실험에서는 익숙한 오픈소스 저장소에서 일한 숙련 개발자 16명의 작업 246건을 비교했어요. 당시 AI 도구 사용을 허용한 조건은 허용하지 않은 조건보다 완료 시간이 평균 19% 더 길었습니다. 참여자들은 실험 뒤에도 AI가 자신을 더 빠르게 해줬다고 추정했고요. 연구 원문

이 결과는 2025년 초 도구와 특정 개발 작업의 결과예요. 지금의 모든 AI나 모든 직무가 느려진다는 뜻은 아니에요. METR의 2026년 2월 후속 설명은 이후 도구가 개발자를 더 빠르게 만들 가능성을 제시하면서도 AI 없이 일하기 싫어 연구에 참여하지 않거나 특정 작업을 제출하지 않는 선택 편향 때문에 그 효과의 크기를 신뢰하기 어렵다고 밝혔어요.

그래서 여기서 가져올 것은 AI가 빠르다거나 느리다는 고정된 답이 아니에요. 우리 업무에서 생성·검토·수정 시간을 함께 재보고 어떤 작업을 비교에서 뺐는지도 남기는 습관이에요.

다음 업무 하나에 작은 기록을 붙여보세요.

1. 결과를 쓸 사람과 완료 기준: 누구의 어떤 판단이나 행동을 도와야 하나요?
2. 전체 시간과 품질: 초안 작성, 사실 확인, 수정, 동료의 검토에 각각 얼마나 들었나요? 빠진 정보와 다시 한 일도 남겨요.
3. 다음에 바꿀 역할 하나: 맥락을 묻는 질문을 추가할지, 결과 형식을 바꿀지, 검토할 기준을 보완할지 고릅니다.
4. 팀에 남길 배움 하나: 잘된 조건과 실패한 예외를 함께 적고 다음 작업에서도 통하는지 확인해요.

한 번의 기록만으로 효과를 확정할 수는 없어요. 비슷한 업무에서 몇 차례 비교하면서 판단을 고쳐보세요. 사람의 기여를 다시 찾는 출발점도 내가 만든 양보다 일이 제대로 끝나는 데 어떤 판단을 보탰는지 살펴보는 데 있어요.