- AI는 표준화된 세부 업무를 하나씩 가져갈 뿐, 직책을 통째로 없애지는 않습니다.
- 결정하기 전에 직책을 세부 업무로 나눠 보십시오. 어느 부분을 시스템에 맡기고 어느 부분을 사람에게 남겨야 하는지 분명히 보입니다.
- 가치가 올라가는 일은 책임을 져야 하고, 관계를 다뤄야 하고, 매뉴얼에 없는 상황에서 판단해야 하는 일입니다.
1. 직무명을 예측하기 전에 업무부터 분석하기
"영업 지원 담당" 한 자리를 뜯어보면 세부 업무가 열 가지가 넘습니다. 같은 데이터를 반복해서 입력하는 일도 있고, 화가 난 고객에게 전화해 달래는 일도 있습니다. 직책 전체를 한꺼번에 놓고 대체할 수 있다, 없다를 판단하면 어느 쪽으로 답하든 틀립니다.
"영업 지원 담당"의 일에는 리드(잠재 고객) 접수, CRM 입력, 서류 준비, 일정 잡기, 진행 상황 확인, 고객과의 조율이 들어갈 수 있습니다. 이 가운데 일부는 상당 부분 자동화할 수 있고, 일부는 관계에 기대야 합니다. 회사가 직책 전체를 놓고 대체할 수 있는지 없는지만 평가하면 일을 새로 설계할 기회를 놓칩니다.
업무를 정형 정보(Routine Information), 비정형 정보(Variable Information), 신체 작업(Physical), 관계(Relationship), 책임(Accountability)으로 나누어 보십시오. 읽기, 옮겨 적기, 분류, 요약, 문서 작성은 갈수록 AI가 맡게 될 가능성이 큽니다. 결과에 책임을 지는 일, 협상, 현장에 직접 가야 하는 일, 신뢰를 쌓는 일에는 여전히 사람이 필요합니다. 다만 그 사람들도 AI에게서 더 많은 정보를 받아 일하게 됩니다.
2. 줄어들거나 모습이 크게 바뀔 가능성이 큰 업무
먼저 줄어드는 일은 대개 비슷하게 생겼습니다. 읽고, 옮겨 적고, 분류하고, 다음 사람에게 넘기는 일입니다. 남는 일은 매뉴얼에 없는 상황에서 판단해야 하는 일입니다.
데이터 사무 업무는 데이터 입력, 파일 정리, 형식 점검, 보고서 취합 같은 일로, 에이전트가 시스템을 연결하고 더 다양한 문서를 다룰 수 있게 되면서 줄어들 것입니다. 표준화된 콘텐츠 업무는 제품 설명, 캡션, 요약 보고서 같은 일로, 한 건에 드는 인력은 줄겠지만 방향을 정하고 사실을 확인할 사람은 여전히 필요합니다.
진행 상황 조율 업무는 누가 어디까지 했는지 묻고 정보를 전달하는 일인데, 점점 워크플로가 대신하게 됩니다. 1차 고객 지원은 FAQ에 답하는 일에서 감정, 위험, 예외가 얽힌 건을 처리하는 일로 바뀝니다. 주니어 분석 업무는 데이터를 모으고 슬라이드를 만드는 데 치우쳐 있어 인원이 줄 수 있고, 신입 직원에게는 실무를 통해 배우는 새로운 방법이 필요해집니다.
줄어드는 정도는 산업마다 다릅니다. 데이터가 디지털화되어 있지 않거나, 규칙이 복잡하거나, 규제를 받는 일은 더 천천히 바뀔 수 있습니다. 대표는 자기 회사의 업무 프로세스 데이터를 근거로 판단해야 하며, 인터넷에서 찾은 직업 목록을 기준으로 사람을 평가해서는 안 됩니다.
3. 가치가 커지는 업무와 역할
시스템을 가르칠 수 있는 현업 전문가(Domain Expert)는 절차는 따르지만 이유를 설명하지 못하는 사람보다 가치가 커집니다. 조직이 지식을 규칙, 예시, 평가 기준으로 바꿔야 하기 때문입니다. 프로세스 설계자(Process Designer)는 비즈니스, 기술, 고객 경험을 연결해 부서 사이의 인계를 없앱니다.
개발팀 참고 · 기술 세부 사항
AI Quality and Risk 담당자는 테스트 세트, 무작위 점검, Incident, Bias를 관리합니다. Customer Specialist는 AI가 해결하지 못한 상황을 넘겨받으며, 결정할 권한이 있습니다. Product Experimenter는 AI로 아이디어를 빠르게 만들고 시험하되, 선택은 시장의 증거를 보고 합니다.
분석적 사고, 창의성, 유연성, 리더십, 협업 같은 사람의 역량은 여전히 중요합니다. 초안을 만드는 비용이 싸질수록, 가치는 어떤 문제를 풀지 고르고, 무엇을 얻고 무엇을 포기할지 판단하고, 결과에 책임지는 쪽으로 옮겨 가기 때문입니다.
4. 일괄 감원 대신 인력 매트릭스(Workforce Matrix) 쓰기
| 그룹 | 업무 특성 | 전략 |
|---|---|---|
| 자동화(Automate) | 반복, 규칙 기반, 대량, 점검 쉬움 | 직접 작업 시간을 줄이고 결원은 충원하지 않음 |
| 보조(Augment) | 분석이 필요하지만 데이터의 도움을 받을 수 있음 | AI 활용을 교육하고 1인당 산출량을 높임 |
| 사람 주도(Human-led) | 관계, 책임, 예외 | 뛰어난 인재를 지키고 결정 권한을 넓힘 |
| 신규 업무(New Work) | 에이전트, 데이터, 평가, 거버넌스 | 새 역할을 만들거나 새 역량을 키움 |
팀장에게 역할마다 각 그룹에 몇 시간을 쓰는지 적게 한 다음, 업무의 25%, 50%, 70%를 자동화할 수 있다고 가정한 시나리오를 만들어 처리 용량과 추가로 필요한 역할을 계산하십시오. 그러면 회사는 줄어들 직책과 함께, 변화를 가로막을 수 있는 역량 격차(Skill Gap)도 보게 됩니다.
5. 2029년에 일하는 사람에게 필요한 핵심 역량
- 문제 정의(Problem Framing): 넓은 목표를 시스템이 이해할 수 있는 작업, 기준, 제약 조건으로 바꾸기
- 데이터 판단(Data Judgment): 어떤 출처를 믿을지 가리고, 빠진 데이터를 알아채고, 증거가 말하는 것 이상으로 결론 내리지 않기
- 프로세스 사고(Process Thinking): 일을 처음부터 끝까지 보고, 규칙과 AI와 사람의 결정을 구분하기
- 평가(Evaluation): 좋은 예시를 만들고, 품질을 점검하고, 오류를 유형별로 나누기
- 예외 처리(Exception Handling): 정보가 모호하거나 영향이 클 때 결정하기
- 고객 공감(Customer Empathy): 맥락과 신뢰, 그리고 아무도 글로 적지 않은 요구를 이해하기
- AI 안전 소양(AI Safety Literacy): 기밀 데이터, 권한, 프롬프트 인젝션, 추적성을 이해하기
프롬프트를 입력하는 것은 기본기에 불과하고, 앞으로는 도구가 프롬프트를 스스로 쓰는 경우가 늘어납니다. 오래가는 역량은 비즈니스를 이해하고, 결과물이 "맥락에 맞고 가치를 만드는지" 판단하는 능력입니다.
6. 리스킬링(Reskill)은 실제 워크플로와 연결해야 합니다
하루짜리 일반 AI 교육은 사람들이 이것저것 써 보게는 만들지만, 일하는 방식까지 바꾸지는 못합니다. 실제 워크플로 하나를 골라 팀이 도입 전과 후를 직접 설계하고, 시스템을 시험해 보고, KPI를 책임지게 하십시오. 교육생은 승인된 데이터를 쓰고, 평가 기준을 만들고, 비즈니스 성과를 발표해야 합니다. 그래야 배운 것이 회사의 자산으로 남습니다.
개발팀 참고 · 기술 세부 사항
수준을 나눕니다. 전 직원은 AI Literacy, 사용자는 Workflow Practitioner, 만드는 사람은 Builder, 리스크를 관리하는 사람은 Owner 과정을 밟습니다. 사내 Certification은 수강 시간 대신 실제로 낸 결과물을 기준으로 주고, Community of Practice를 만들어 Template과 Incident를 공유합니다.
7. 시나리오별 인력 계획(Headcount Plan) 세우기
개발팀 참고 · 기술 세부 사항
Base, Accelerated, Constrained 계획을 각각 만듭니다. 계획마다 업무량, Productivity Gain, Attrition, Hiring Freeze, Redeploy, 새 Role을 적습니다. 절감한 시간을 곧바로 인원 감축으로 계산하지 마십시오. 그 시간이 모여 몇 FTE가 되는지, 회사가 그 가치를 실제로 어떻게 거둬들이는지(Capture Value) 확인해야 합니다.
정형 업무 직책에는 채용 게이트(Hiring Gate)를 두십시오. 추가 채용을 승인하기 전에 팀이 업무 프로세스를 손보고 자동화 가능성을 검토했다는 것을 보여 주어야 합니다. 사람 주도 직책은 인재를 붙잡고 AI 활용 역량을 키우는 일을 서둘러야 합니다. 차이를 가장 크게 만드는 사람들이 이 그룹에 있습니다.
8. 대표와 인사팀을 위한 12개월 계획
- 1분기: 핵심 워크플로의 업무 목록(Task Inventory)과 인력 매트릭스를 만듭니다.
- 2분기: 업무 프로세스 두 곳에서 자동화와 보조를 시범 운영하고, 실제 업무로 짠 교육 과정을 함께 진행합니다.
- 3분기: 직무기술서, KPI, 채용 게이트, 경력 경로를 고칩니다.
- 4분기: 실제 생산성 결과를 바탕으로 2028~2029년 인력 시나리오를 만듭니다.
요약: 정형 정보 업무와 조율 업무는 줄어들 가능성이 크고, 현업 판단력, 프로세스 설계, 고객 신뢰, AI 거버넌스의 가치는 커집니다. 회사는 인력 계획의 기준을 직책에서 업무와 워크플로로 옮기고, 리스킬링은 실제 업무로 해야 합니다. 그래야 필요 이상으로 채용하는 일도, 나중에 역량이 모자라는 위험도 줄일 수 있습니다.
인력 계획을 감 대신 데이터로 결정할 수 있게 만듭니다
어떤 직책을 늘리고 줄이고 바꿀지는 실제 업무를 아는 인사팀과 현업 팀장이 답해야 합니다. 소프트웨어 회사가 줄 수 있는 답이 아닙니다. 그래서 저희는 회사 팀이 이미 알고 있는 것을 구조화하는 일부터 돕습니다. 직책 하나를 세부 업무로 나누고, 업무마다 시간이 얼마나 걸리는지, 어떤 데이터가 뒷받침하는지, 판단이 얼마나 필요한지, 실수하면 피해가 얼마나 되는지 적습니다. 이 데이터가 회사 전체에서 같은 형식을 갖추면 부서끼리 비교할 수 있게 됩니다.
인사팀과 팀장이 같은 그림을 보게 하는 시스템
그다음 저희가 만드는 것은 대개 팀장이 직접 입력할 수 있는 업무 목록과 인력 매트릭스용 사내 웹 애플리케이션입니다. 역할별 화면(Role-based View)을 두어 인사팀은 전체 그림을, 팀장은 자기 팀만 보게 하고, 생산성이 20%, 40%, 60% 오르면 인원과 역할이 어떻게 달라져야 하는지 보여 주는 시나리오 모듈도 붙입니다. 개발은 짧은 주기로 나눠 납품하며, 두세 개 부서에서 시작해 조직 전체로 넓힙니다. 업무 데이터 없이 지금 추가 채용을 결정하고 있다면, 첫 데이터 세트를 갖추는 일부터 기꺼이 돕겠습니다.
SOFTWARE ENGINEERING GLOSSARY
소프트웨어 엔지니어링 용어집
인력 데이터 시스템을 두고 개발팀과 정확하게 이야기할 때 쓰는 용어입니다.
| 용어 | 의미 | 쉬운 예시 | 개발팀에 물어봐야 할 질문 |
|---|---|---|---|
| Role-based View | 한 시스템 안에서 사용자의 역할에 따라 다른 데이터를 보여 주는 방식 | 팀장은 자기 팀만, 인사팀은 회사 전체를 봅니다. | 누가 어느 수준의 데이터를 보고, 직책이 바뀌면 권한은 어떻게 바뀝니까? |
| Data Model | 어떤 데이터가 있고 서로 어떻게 연결되는지 정한 구조 | 직책 하나에 여러 업무가 있고, 업무마다 소요 시간과 위험도가 있습니다. | 나중에 새 분석 항목을 추가하려면 시스템을 다시 만들어야 합니까? |
| Scenario Modeling | 여러 가정에서 결과를 시뮬레이션해 선택지를 비교하는 일 | 업무의 20%, 40%, 60%를 자동화할 수 있을 때의 인력 규모를 시뮬레이션합니다. | 가정은 어떤 실제 데이터에서 나왔고, 누가 확인합니까? |
| Capstone | 교육 과정을 마칠 때 교육생이 제출하는 실제 결과물로, 교육 이수 여부를 넘어 실제로 일을 해낼 수 있는지 확인하는 수단 | 팀이 자기 워크플로를 새로 설계하고 도입 전후 결과를 측정하게 합니다. | 학습 성과를 실제 업무로 측정합니까, 시험으로 측정합니까? |
| Adoption Analytics | 사람들이 시스템을 실제로 얼마나, 무엇에 쓰는지 보여 주는 데이터 | 매달 업무 목록을 업데이트하는 팀장이 몇 명인지 봅니다. | 실제 사용량을 측정합니까, 개설된 계정 수만 셉니까? |