- AI를 능숙하게 쓰지만 문제를 정의하지 못하고 결과를 검토할 줄 모르는 직원은 일을 더 잘하게 된 것이 아닙니다. 틀린 결과를 더 빨리 만들어 낼 뿐입니다.
- 그래서 길러야 할 것은 명령어 암기보다, 문제를 분명히 정의하고 어떤 정보를 믿을 수 있는지 가려내며 자기 일의 근거를 설명하는 능력입니다.
- 가장 정확한 측정법은 실제 결과물을 보는 것입니다. 교육을 몇 시간 이수했는지는 별로 알려 주는 것이 없습니다.
새 역량은 도구 이름보다 실제 업무로 판단합니다
직원을 새로 뽑을 때 어떤 프로그램을 쓸 줄 아는지 묻지 않습니다. 일을 끝까지 해낼 수 있는지 묻습니다. AI도 같은 기준으로 보아야 합니다. 물어야 할 것은 "누가 새 도구를 쓸 줄 아는가"보다 "그 사람이 맡은 일이 실제로 나아졌는가"입니다.
AI 도구는 빠르게 바뀌지만 일의 기본은 그만큼 빨리 바뀌지 않습니다. 고객은 지금도 정확한 답을 원합니다. 공장에는 좋은 제품이 필요하고, 경영진은 제약 속에서 결정을 내려야 하며, 팀은 기한 안에 결과를 내야 합니다. 그러니 중요한 질문은 "직원이 어떤 앱을 쓸 줄 아는가"보다 "직원이 처음부터 끝까지 일을 더 낫게 만들 수 있는가"입니다.
먼저 한 직무를 세부 업무로 나눠 보십시오. 영업 직원의 일은 하나가 아닙니다. 고객 정보 조사, 질문 준비, 영업 기회 평가, 제안서 작성, 협상, 진행 상황 기록, 후속 관리가 모두 들어 있습니다. AI는 조사나 초안 작성은 잘 도울 수 있지만, 고객의 속마음을 읽고 조건을 고르고 관계를 지키는 일에는 여전히 사람의 판단이 필요합니다. 세부 업무로 나눠 보면 회사는 어떤 역량을 가르쳐야 하는지 알게 되고, 지나치게 넓은 교육 과정에 휩쓸리지 않습니다.
역량의 세 단계
첫 단계는 AI를 이해하고 안전하게 쓰는 것입니다. 두 번째 단계는 AI로 자기 일의 품질을 높이는 것이고, 세 번째 단계는 팀 전체가 혜택을 보도록 업무 프로세스를 고치는 것입니다. 모든 직원이 세 번째 단계까지 갈 필요는 없지만, 부서마다 업무 지식과 워크플로 설계를 이어 줄 수 있는 사람은 있어야 합니다.
시작 단계 진단 질문
- 시간은 많이 들지만 고객에게 돌아가는 가치는 작은 업무는 무엇입니까?
- 오류나 수정 횟수가 많은 업무는 무엇입니까?
- 많은 양의 문서나 메시지를 읽어야 하는 업무는 무엇입니까?
- 소수의 사람이 쌓은 경험에 기대는 업무는 무엇입니까?
- 영향이 커서 사람의 승인을 계속 유지해야 하는 업무는 무엇입니까?
도구 사용자를 성과를 내는 사람으로 바꾸는 10가지 역량
그럴듯한 명령어를 외워 두어도 도구가 해마다 바뀌니 오래 쓰지 못합니다. 반면 문제를 분명히 정의하고, 어떤 데이터를 믿을 수 있는지 가려내고, 왜 그렇게 결정했는지 설명할 수 있는 사람은 회사가 어떤 세대의 도구를 쓰든 가치가 있습니다.

| 역량 | 눈에 보이는 행동 | 증거 예시 |
|---|---|---|
| 1. AI 리터러시 | AI의 한계를 설명하고, 위험 수준에 맞게 AI를 골라 씀 | 어떤 업무는 AI에 초안을 맡기고, 어떤 업무는 AI가 스스로 결정하면 안 되는지 구분할 수 있음 |
| 2. 문제 정의(Problem Framing) | 막연한 지시를 목표, 사용자, 제약, 성공 기준으로 바꿈 | 다른 사람이 읽고 바로 이어서 일할 수 있는 브리프(Brief) |
| 3. 비판적 사고(Critical Thinking) | 결론에 의문을 던지고, 반대 근거를 찾고, 사실과 가정을 구분함 | 무엇을 확인했는지, 왜 첫 번째 답을 고르지 않았는지 적은 기록 |
| 4. 데이터 리터러시 | 데이터의 출처, 정의, 단위, 기간, 완결성을 읽어 냄 | KPI 정의를 확인하기 전에는 대시보드만 보고 결론 내리지 않음 |
| 5. 검증(Verification) | 출처, 규칙, 다시 해 볼 수 있는 계산으로 답을 확인함 | 결과물 안의 체크리스트와 근거 링크 |
| 6. 프로세스 설계(Process Design) | 업무의 앞단부터 뒷단까지 보고 불필요한 인계를 줄임 | 승인 지점이 표시된 도입 전후의 워크플로 |
| 7. 커뮤니케이션 | 결론, 불확실한 점, 다음에 할 일을 간결하게 전달함 | 위험을 감추지 않는 경영진 보고용 요약 |
| 8. 창의성(Creativity) | 여러 선택지를 만들고 여러 분야의 지식을 엮어 문제를 풂 | 막연한 아이디어가 아닌, 사용자와 테스트한 프로토타입 |
| 9. 디지털 안전(Digital Safety) | 데이터, 권한, 지식재산을 보호함 | 승인된 도구와 데이터만 사용 |
| 10. 학습 민첩성(Learning Agility) | 작게 실험하고, 결과를 재고, 일하는 방식을 계속 고쳐 나감 | 그만둔 일까지 적은 실험 기록 |
이 역량들은 한 묶음으로 움직입니다. 비판적 사고 없는 데이터 리터러시는 직원이 잘못 정의된 데이터를 믿게 만들 수 있고, 검증 없는 창의성은 흥미롭지만 실제로는 쓸 수 없는 아이디어를 낳을 수 있습니다. 그래서 평가는 여러 역량을 함께 써야 하는 실제 과제로 해야 합니다.
역할과 책임 수준에 맞춘 학습 설계
회사 전체에 과정 하나를 돌리면 운영은 쉽지만 성과는 나기 어렵습니다. 회계팀에는 정확성, 규칙, 감사(Audit)가 중요합니다. 마케팅팀은 고객 이해, 주장의 근거, 브랜드 보이스(Brand Voice)에 무게를 두어야 하고, 공장 팀은 안전, 현장 신호, 예외 상황 전달을 익혀야 합니다. 관리자는 시스템을 읽고 KPI를 세우고 변화를 관리할 줄 알아야 합니다.

역량 개발의 네 단계
- 안전한 사용자: 허용된 데이터가 무엇인지 알고, 기본 브리프를 쓰며, 결과물을 쓰기 전에 확인합니다.
- 능숙한 실무자: 반복 업무용 템플릿이 있고, 품질을 비교하며, 동료를 가르칠 수 있습니다.
- 프로세스 설계자: 업무 흐름도(프로세스 맵)를 그리고, 자동화할 지점을 고르며, 예외 처리 대기열을 설계합니다.
- 성과 책임자: 비즈니스 KPI, 위험, 예산, SOP 변경을 책임집니다.
학습자가 교육 전에 결과물을 하나 만들고, 교육 후 같은 데이터와 같은 평가 기준으로 같은 일을 다시 하게 하십시오. 전체 과정에 걸린 시간, 정확도, 수정 횟수, 근거 설명의 질을 잽니다. 이렇게 하면 "교육장에서 할 수 있는 것"과 "실제 업무에서 할 수 있는 것"을 구분할 수 있습니다.
캡스톤(Capstone) 과제 예시
고객 서비스팀은 문의 건의 이력을 요약하고, 답변 초안을 쓰고, 도움말 문서를 추천하는 워크플로를 만들 수 있습니다. 이때 출처를 보여 주고 민감한 건은 팀장에게 넘겨야 합니다. 구매팀은 AI로 견적서의 조건을 읽게 하되, 점수는 규칙으로 계산하고 결정은 위원회가 내리게 할 수 있습니다. 학습자는 오류율이 기준을 넘지 않으면서 결과가 빨라졌을 때 통과합니다. 사례 하나를 시연한 것으로는 통과하지 못합니다.
좋은 인증 기준
- 실제 업무의 과제와 승인된 데이터를 씁니다.
- 일반 사례, 예외, 위험 사례가 들어 있습니다.
- AI가 무엇을 하고 사람이 어디서 책임지는지 설명할 수 있습니다.
- 결과를 느낌이 아닌 근거로 확인합니다.
- 팀이 계속 쓸 수 있는 템플릿, 체크리스트, SOP를 넘겨줍니다.
역량이 생산성으로 이어지는 환경 만들기
직원이 아무리 잘 배워도 승인된 도구가 없거나, 실험할 시간이 없거나, KPI가 여전히 예전 방식에 보상한다면 조직은 바뀌지 않습니다. 회사는 역량이 달릴 레일을 깔아 주어야 합니다: 이해하기 쉬운 데이터 정책, 검토를 거친 예시 모음, 질문을 받는 오피스 아워(Office Hour), 워크플로마다 정한 책임자, 신고한 사람이 불이익을 받지 않는 사고(Incident) 보고 채널.

개발팀 참고 · 기술 세부 사항
팀장은 "오늘 AI를 사용했습니까"라고 묻는 대신 "어느 부분의 일이 나아졌고, 근거는 무엇이며, 아직 어디에 위험이 있습니까"라고 물어야 합니다. HR은 Capstone을 Reviewer, Knowledge Curator, Automation Champion, Process Owner 같은 Career Path와 연결해야 합니다. 도구를 가장 빨리 누르는 사람에게 모든 공을 돌리지 말고, 동료가 일을 더 잘하게 돕는 사람을 인정해야 합니다.
한 부서를 위한 90일 계획
| 기간 | 할 일 | 산출물 |
|---|---|---|
| 1~30일 차 | 업무 목록(Task Inventory)과 역량 기준선(Skill Baseline)을 만들고 워크플로 2개 선정 | 과제·책임자·데이터·가드레일 |
| 31~60일 차 | 역할별 교육과 실제 업무 시범 적용 | 템플릿, 체크리스트, 통과한 예시 |
| 61~90일 차 | 도입 전후 측정, SOP 개선, 사용자 인증 | 비즈니스 성과와 확대 계획 |
프로젝트는 세 가지 결정으로 마무리합니다. 무엇을 넓힐지, 무엇을 고칠지, 무엇을 멈출지입니다. 수지가 맞지 않는 활용 사례를 접을 줄 아는 것도 조직의 역량입니다. 최종 목표는 더 빠르고 정확하게 결과를 내고 새로운 방식을 책임 있게 만들어 내는 팀입니다. AI 이야기를 많이 하는 직원이 늘어나는 것은 목표가 될 수 없습니다.
FIELD NOTE · 실무자의 시선
눈여겨볼 사람은 프롬프트를 가장 빨리 치는 사람이 아닙니다
팀을 한번 살펴보십시오. AI를 제대로 활용하는 사람들은 비슷한 습관이 있습니다. 과제를 읽고 되묻고, 어떤 정보가 미덥지 않은지 알아보며, "이건 아직 답할 수 없습니다"라고 말하기를 부끄러워하지 않습니다. 화려해 보이지는 않지만 큰 손해를 막아 주는 훌륭한 안전장치입니다. 회사에 필요한 사람은 AI를 만족시키는 직원보다 고객과 실제 업무에 더 나은 결과를 가져오는 직원입니다.

AI 결과를 쓰기 전 T.E.S.T. 점검법
- Truth: 사실은 어디서 왔습니까?
- Exception: 이 답이 통하지 않는 경우는 언제입니까?
- Stake: 틀리면 누가, 얼마나 피해를 봅니까?
- Transfer: 이 방법을 다른 사람이 다시 쓸 수 있게 어떻게 남겨 두겠습니까?
팀에서 해 볼 일: 일주일에 한 번, 각자 "하마터면 잘못 보낼 뻔한" 결과물을 가져와 5분 동안 이야기하게 하십시오. 잡아낸 실수에서 얻는 교훈이 잘 다듬은 프롬프트 열 개보다 값질 때가 많습니다.
지식에서 실제로 문제를 해결하는 시스템으로
문제의 핵심
역량 문제의 원인은 학습량 부족보다, 회사가 "더 잘하게 되었다"는 것을 어떤 업무에서 확인할지 정의한 적이 없다는 데 있습니다.
단계별 해결 방법
- 업무·역량 지도(Task & Skill Map)를 만들어 AI가 도울 일, 사람이 검토해야 할 일, 시스템에 절대 맡기면 안 되는 일을 나눕니다.
- 회사의 실제 데이터와 상황으로 역할별 아카데미(Role Academy)와 캡스톤 과제를 설계합니다.
- 도입 전후를 측정하고, 효과가 확인된 것은 템플릿, SOP, 경력 경로(Career Path)로 바꿉니다.
인재 개발 계획을 진척이 보이는 시스템으로
많은 조직에 이미 좋은 교육 과정이 있습니다. 부족한 것은 교육장에서 실제 업무로 돌아오는 다리입니다. DNA Maker는 HR, 팀장, 직원이 같은 업무를 앞에 두고 이야기하는 데서 시작합니다. AI를 쓰기 전에는 일이 어떻게 흘러갔는지, 어디서 시간이 새는지, 어떤 실수는 용납할 수 없는지, "실제로 할 수 있다"고 부를 만한 결과물은 어떤 모습인지 묻습니다. 누가 무엇을 잘해야 하는지 저희가 대신 정하지는 않습니다. 조직이 쌓아 온 지식을 역량 지도(Skill Map), 실제 상황에서 가져온 연습 과제, 모든 부서가 같은 뜻으로 이해하는 검토 워크플로로 바꾸도록 돕습니다. 그래서 인재 개발이 수료증에서 끝나지 않고, 직원이 일을 더 잘하게 되었으며 언제 도움을 청해야 하는지 안다는 근거가 남습니다.
이 그림을 바탕으로 DNA Maker는 캡스톤 과제, AI 연습 공간(AI Practice Workspace), 지식 베이스(Knowledge Base), 진척 대시보드를 한곳에 모은 사내 웹이나 앱을 개발할 수 있습니다. 역할별 권한을 설정하고, 통과한 결과물을 팀의 템플릿이나 SOP와 연결합니다. 디스커버리 워크숍(Discovery Workshop), UX/UI, 프로토타입, 시스템 아키텍처, AI 에이전트부터 실제 시스템 개발과 운영 후 개선까지 도울 수 있습니다. 교육 과정과 소프트웨어 중 무엇부터 시작할지 아직 정하지 못했다면, 시험해 보기에 충분히 작으면서도 모두가 가치를 느낄 만큼 중요한 "첫 번째 업무"를 함께 찾아보겠습니다.
SOFTWARE ENGINEERING GLOSSARY
소프트웨어 엔지니어링 용어집
경영진, 업무 책임자, 개발팀이 같은 용어를 서로 다르게 이해하지 않도록 정리한 표입니다. 외울 필요는 없고, 의미와 예시, 오른쪽 열의 질문까지 함께 읽으면 됩니다. 이 질문을 던지면 개발을 시작하기 전에 숨어 있던 범위와 위험, 비용이 드러나는 경우가 많습니다.
| 용어 | 의미 | 쉬운 예시 | 개발팀에 물어봐야 할 질문 |
|---|---|---|---|
| Workflow | 누가 무엇을 하는지 보여 주며 시작부터 결과까지 이어지는 작업 순서 | 교육 신청 → 연습 과제 → 팀장 검토 → 역량 인증 | 어느 단계를 자동화하고, 어느 지점에서 사람이 결정해야 합니까? |
| AI Agent | 목표를 받아 데이터나 도구를 쓰면서 여러 단계의 작업을 수행하는 AI 소프트웨어 | 에이전트가 결과물을 읽고 체크리스트와 비교한 뒤 검토자에게 넘깁니다. | 에이전트는 어떤 데이터와 도구를 쓰고, 어디서 멈춥니까? |
| Role-based Access | 역할에 따라 권한을 정하는 방식 | 직원은 일반 교육 자료를 보고, HR은 평가 결과까지 봅니다. | 데이터 유형마다 누가 보고, 고치고, 승인하고, 내려받을 수 있어야 합니까? |
| Knowledge Base | 분류해 두고 검색할 수 있는 지식 저장소 | SOP, 업무 예시, 자주 묻는 질문을 한곳에 모읍니다. | 내용은 누가 승인하고, 오래된 정보는 어떻게 내립니까? |
| Prototype | 본격적으로 개발하기 전에 아이디어를 시험해 보는 시제품 | 한 부서에서 시험 운영하는 역량 대시보드(Skill Dashboard) 화면 | 본격 개발에 투자하기 전에 프로토타입에서 무엇을 확인해야 합니까? |
