AI 잘 쓰는 인재, 뭘 보고 평가할 것인가: ABCD2 프레임워크
https://gist.github.com/casamia918/678cd716333a43f6b5fe539625b1e1ac
팀 회의에서 이렇게 물어보자. "우리 팀에서 AI를 제일 잘 쓰는 사람이 누구야?"
아마 잠깐 정적이 흐를 것이다. 누군가는 툴을 제일 많이 쓰는 사람을 떠올리고, 누군가는 프롬프트를 잘 다루는 사람을 떠올리고, 누군가는 최근에 AI로 뭔가 그럴듯한 걸 만들어온 사람을 떠올린다. 그런데 그 어느 답도 확신이 안 선다. 뭔가 아니라는 직감은 있는데, 그럼 뭘 보고 판단해야 하는지는 아무도 모른다.
지금 거의 모든 기업이 이 벽 앞에 서 있다. AI 역량이 채용과 평가의 핵심 항목으로 올라오고 있는데, 정작 그걸 잴 잣대가 없다. 이 글은 그 잣대를 제안하는 글이다. 결론부터 말하면, ABCD2라는 다섯 축이다. 하지만 그 전에, 질문 자체를 먼저 고쳐야 한다.
"AI를 잘 쓴다"는 개념부터 틀렸다
제목에 "AI 잘 쓰는 인재"라고 썼지만, 사실 이 표현부터가 함정이다.
"잘 쓴다(use)"라는 말에는 프레임이 하나 깔려 있다. AI는 도구이고, 사람은 사용자라는 프레임. 엑셀을 잘 쓴다, 포토샵을 잘 쓴다의 연장선에서 AI를 바라보는 것이다. 이 프레임 위에서는 평가도 자연스럽게 '도구 숙련도' 측정이 된다. 단축키를 얼마나 아는가, 기능을 얼마나 능숙하게 다루는가.
그런데 AI는 망치가 아니다. AI는 판단하고 실행하는 지능 엔진이다. 도구라기보다는, 일을 맡길 수 있는 신입 동료에 가깝다. 그리고 신입 동료를 생각해보면 프레임이 뒤집힌다. 일 잘하는 신입 옆에는 반드시 그 신입이 일을 잘 하도록 만들어주는 선배가 있다. 업무의 맥락을 알려주고, 판단 기준을 정리해주고, 애매한 것을 물어볼 수 있게 해주고, 결과물을 검증해주는 사람. 그 선배는 신입을 '쓰는' 게 아니다. 신입이 '일을 잘 하게' 만드는 것이다.
AI도 정확히 같다. AI를 정말 잘 활용하는 사람은 AI를 잘 쓰는 사람이 아니라, AI가 일을 잘 하도록 도와주는 사람이다.
그럼 무엇으로 돕는가. 크게 두 가지다. 하나는 지식 구축이다. AI가 딛고 설 지식을 정비해주는 것 — 우리 조직의 용어는 무엇을 뜻하는지, 판단 기준은 무엇인지, 좋은 결과물과 나쁜 결과물의 차이는 무엇인지를 AI가 참조할 수 있는 형태로 만들어두는 일이다. 다른 하나는 컨텍스트 파이프라이닝이다. 그렇게 구축한 지식이 필요한 시점에, 필요한 형태로, AI에게 흘러들어가도록 흐름을 설계하는 일이다. 어떤 과업에 어떤 맥락을 실어 보낼지, 결과를 무엇으로 검증할지, 검증에서 걸리면 어디로 되돌릴지.
이 관점에서 보면 프롬프트는 무엇인가. 이 긴 흐름의 마지막 한 줄일 뿐이다. 좋은 프롬프트는 좋은 지식 구축과 좋은 컨텍스트 파이프라이닝의 결과물이지, 그 자체가 역량의 본체가 아니다.
감이 빠른 독자라면 여기서 이미 눈치챘을 것이다 — 앞으로 온톨로지(ontology)가 중요해진다는 것을. 조직의 용어와 개념, 그들 사이의 관계와 판단 기준을 AI가 참조할 수 있는 형태로 구조화해두는 것, 그게 바로 온톨로지이기 때문이다. 지식 구축이라는 말을 한 꺼풀 벗기면 그 안에 있는 것이 온톨로지다. AI가 조직의 실행 엔진이 될수록, 그 엔진이 딛고 설 온톨로지를 가진 조직과 그렇지 못한 조직의 격차는 벌어질 수밖에 없다.
기존 잣대가 전부 빗나가는 이유
이 재정의를 손에 쥐면, 지금 쓰이는 평가 방식들이 왜 전부 빗나가는지가 한눈에 보인다.
먼저 전통적인 잣대들. 코딩 테스트, 알고리즘 문제, 자격증, 학벌. 이것들이 실제로 측정해온 것은 '수행 능력'이다. 잘 정의된 문제를 얼마나 정확하고 빠르게 실행하는가. 그런데 그 수행이 바로 AI에게 넘어간 부분이다. 측정 대상이 통째로 AI 쪽으로 이동했는데 측정 도구는 여전히 사람을 겨누고 있으니, 예측력이 사라지는 게 당연하다. 코딩 테스트 만점자가 AI와 일을 잘한다는 보장은 어디에도 없다. 오히려 잘 정의된 문제를 빠르게 푸는 데 최적화된 사람일수록, 문제를 정의하고 맥락을 설계하는 일에는 서툴 수 있다.
그럼 AI 시대에 맞게 나왔다는 새 잣대들은 어떤가. 흔한 것이 두 가지다.
첫째, 프롬프트 스킬 평가. 앞서 봤듯 프롬프트는 흐름의 마지막 한 줄이다. 마지막 한 줄만 재는 것은 요리사를 플레이팅만 보고 뽑는 것과 같다. 게다가 프롬프트 테크닉은 특정 툴과 특정 모델 버전에 종속적이라 반감기가 짧다. 모델이 좋아질수록 잔기술의 가치는 떨어지고, 남는 것은 무엇을 시킬지와 어떤 맥락을 줄지를 설계하는 능력이다.
둘째, 툴, 토큰 사용량과 AI 활용 시간. AI를 많이 쓰는 사람이 잘 쓰는 사람이라는 가정인데, 이건 거꾸로일 수 있다. 파이프라인을 제대로 만들어둔 사람은 오히려 이 지표가 낮게 나올 수 있다. 매번 처음부터 수동으로 긴 대화를 반복하는 사람이 사용량은 제일 많이 나온다. 많이 쓰는 것과 잘 하게 만드는 것은 다른 문제다. 똑같은 일을 시켰는데 반복적으로 10만 토큰으로 일을 완수하는사람과 100만토큰으로 일을 완수하는 사람이 있다면, 누가 더 AI 를 잘 쓰고 있다는 것인가?
두 잣대의 공통점은, 둘 다 'use' 프레임의 측정법이라는 것이다. 도구 숙련도를 재는 방식으로는 '일을 잘 하게 만드는' 능력이 잡히지 않는다.
그럼 무엇을 재야 하나 — ABCD2
'AI가 일을 잘 하게 만드는 능력'은 뭉뚱그리면 잴 수 없다. 측정하려면 분해해야 한다. 나는 이 능력을 다섯 축으로 분해한다. 이해하고(Comprehend), 추상화하고(Abstract), 분해하고(Dissolve), 구축하고(Build), 설명한다(Describe). 앞글자를 따서 ABCD2다.
평가자의 관점에서, 각 축은 이런 질문이 된다.
Comprehend(이해) — 이 사람은 연결할 세상을 이해하는가. 과업이 실제로 무엇을 건드리는지, 이 조직에서 그 단어가 무슨 뜻인지, 누가 그 결과에 영향을 받는지를 파악하는가. 이해가 없으면 AI에게 무엇을 시켜야 하는지 자체를 오해한다.
Abstract(추상화) — 이 사람은 본질을 추상화하는가. 지저분한 현실에서 다룰 수 있는 구조를 걷어내는가. 좋은 추상화는 단순화하되 중요한 것을 버리지 않는다. 이 균형 감각이 없으면 AI에게 넘기는 문제 정의 자체가 뒤틀린다.
Dissolve(분해) — 이 사람은 검증 가능한 단위로 분해하는가. 통째로 맡기면 어디서 틀렸는지 알 수 없다. AI의 출력을 확인할 수 있는 경계를 따라 일을 쪼개는가. 이건 AI의 그럴듯한 오답을 걸러내는 능력과 직결된다.
Build(구축) — 이 사람은 흐름을 구축하는가. 쪼갠 단위들을 검증과 폴백이 있는 하나의 흐름으로 엮는가. 일회성 요청이 아니라 반복 가능하고 물려줄 수 있는 파이프라인을 만드는가.
Describe(설명) — 이 사람은 설명하고 책임지는가. 무엇을 왜 어떻게 연결했는지 말로 풀 수 있는가. 그리고 AI가 낸 결과물에 대해 "이건 내가 이렇게 판단하도록 설계했다"고 책임의 주어가 되는가.
눈치챘겠지만, 이 다섯 축 어디에도 '특정 툴을 다루는 능력'이 없다. 툴이 바뀌어도, 모델이 바뀌어도 이 축들은 유효하다. 그게 평가 기준이 갖춰야 할 최소 조건이다.
사례 — 같은 지시, 두 사람
추상적인 축만으로는 감이 안 오니, 장면 하나를 보자. 팀장이 두 팀원에게 같은 지시를 내렸다. "이번 달 고객 문의 데이터, AI로 분석해서 정리해줘."
A는 이렇게 한다. 문의 데이터를 내려받아 AI에 통째로 붙여넣고, "이 고객 문의들을 분석해서 주요 이슈를 정리해줘"라고 요청한다. 몇 번의 되물음 끝에 깔끔한 요약이 나온다. 카테고리별 비중, 주요 불만, 개선 제안까지. 소요 시간 30분. 보고서는 그럴듯하다.
B는 이렇게 한다. 먼저 이 문의들이 어디서 오는지 확인한다. 채널별로 성격이 다르고, CS팀이 이미 태깅해둔 분류 체계가 있다는 걸 알게 된다(Comprehend). 그 분류 체계를 기준으로 삼되, 이번 분석의 목적 — 다음 분기 개선 과제 도출 — 에 맞게 "반복 문의 / 신규 유형 / 긴급"이라는 세 관점으로 재정리한다(Abstract). 데이터를 통째로 넣지 않고 채널별·주차별로 나눠서, 각 묶음의 결과를 원본과 대조 확인할 수 있게 한다(Dissolve). 분류 기준과 우리 회사 용어 정의, 좋은 분류의 예시를 문서 하나로 정리해 매 요청에 함께 실어 보내는 흐름을 만들고, 분류가 애매한 건은 사람 확인으로 빠지게 한다(Build). 그리고 보고서 말미에 이렇게 쓴다. "이 분석은 CS 태깅 체계를 기준으로 했고, X 채널 데이터는 포함되지 않았으며, '긴급' 판정 기준은 내가 이렇게 정의했다"(Describe). 소요 시간 반나절.
자, 이번 달 보고서만 놓고 보면 누가 더 잘했는가. 구분이 잘 안 된다. 솔직히 A의 보고서가 더 빨리 나왔고 겉보기에 뒤지지도 않는다. 기존 평가 방식 — 산출물의 품질과 속도 — 으로는 A가 이길 수도 있다.
차이는 다음 달에 드러난다. 다음 달에 같은 지시가 내려오면, A는 처음부터 다시 한다. 지난달과 분류 기준이 달라져서 추이 비교도 안 된다. B는 만들어둔 흐름에 새 데이터를 흘려보내면 끝이다. 기준이 같으니 월별 추이가 쌓이고, B가 휴가를 가도 다른 사람이 그 흐름을 돌릴 수 있다. A가 남긴 것은 보고서 한 장이고, B가 남긴 것은 자산이다.
이게 핵심이다. 기존 평가는 '이번 달 결과물'만 보기 때문에 A와 B를 가르지 못한다. ABCD2는 결과물이 아니라 결과물이 만들어진 과정의 다섯 지점을 보기 때문에, 이 둘을 가른다.
실무 적용 — 면접과 평가에서 이렇게 묻는다
그럼 실제 면접이나 인사 평가에서 ABCD2를 어떻게 확인하는가. 축별로 하나씩만 예를 들면 이렇다.
Comprehend — 일부러 맥락이 빠진 과업을 준다. "우리 서비스의 이탈률을 AI로 분석한다면 어떻게 하겠냐"처럼 '이탈'의 정의도, 데이터의 형태도 말해주지 않는다. 좋은 후보는 답을 시작하기 전에 되묻는다. 이탈을 뭘로 정의하고 있는지, 어떤 데이터가 있는지. 되묻지 않고 바로 그럴듯한 절차를 읊는 사람은, 실무에서도 AI에게 오해된 문제를 시킬 사람이다.
Abstract — 지저분한 실제 사례를 주고 구조를 잡게 한다. 예외투성이 업무 프로세스를 던져주고 "이걸 AI에게 맡긴다면 어떤 단계로 정리하겠냐"고 묻는다. 모든 예외를 다 담으려는 사람과, 중요한 것을 버리는 사람 사이에서 균형을 잡는지를 본다.
Dissolve — AI가 낸 그럴듯한 오답을 준다. 표면적으로는 매끄럽지만 한 군데 사실관계가 틀린 산출물을 보여주고 "이걸 검수해야 한다면 어떻게 하겠냐"고 묻는다. 통째로 다시 읽겠다는 답과, 검증 가능한 단위로 쪼개서 원본과 대조하겠다는 답은 완전히 다른 역량이다.
Build — "그 작업을 매주 반복해야 한다면?"이라고 이어 묻는다. 일회성 해법을 반복 가능한 흐름으로 바꿀 수 있는지, 검증과 예외 처리를 흐름 안에 설계하는지를 본다.
Describe — 후보가 만든 AI 산출물에 대해 "이 결과가 틀렸다면 그건 누구 책임이냐"고 묻는다. "AI가 그렇게 냈다"는 답과 "내가 이런 기준으로 판단하게 설계했으니 내 책임이고, 어디를 고치면 된다"는 답의 거리가, 이 축의 거리다.
공통점이 보일 것이다. 전부 정답이 있는 문제가 아니라, 문제를 다루는 방식을 드러내는 질문들이다. 수행 능력 평가와 정반대 방향이다.
프레임의 완성 — 세 축
ABCD2만으로 채용 의사결정이 완결되지는 않는다. 두 축을 더해야 실제로 쓸 만한 프레임이 된다. 하나는 인적성 — 이 사람이 그런 사고와 오너십을 감당할 기질을 애초에 가졌는가. 다른 하나는 도메인 업무 적합성 — 이 사람이 이해하고 연결해야 할 세상이 바로 우리 도메인인가. ABCD2가 아무리 높아도 도메인을 모르면 Comprehend가 작동하지 않고, 역량과 도메인이 맞아도 오너십을 회피하는 기질이면 Describe가 무너진다.
정리하면 ABCD2(역량) × 인적성(기질) × 도메인 적합성(맥락). 이 세 축이 "AI 시대에 인재를 어떻게 뽑고 배치할 것인가"라는 질문에 대한 나의 답이다.
마치며 — 잘 쓰는 사람을 찾지 마라
제목으로 돌아가자. "AI 잘 쓰는 인재, 뭘 보고 평가할 것인가." 이제 답할 수 있다. AI를 잘 쓰는 인재를 찾지 마라. AI가 일을 잘 하도록 만드는 사람을 찾아라. 그리고 그 능력은 뭉뚱그리면 잴 수 없지만, 분해하면 잴 수 있다. 연결할 세상을 이해하는가, 본질을 추상화하는가, 검증 가능한 단위로 분해하는가, 흐름을 구축하는가, 설명하고 책임지는가.
한 가지는 미리 말해두는 게 정직하겠다. 이 기준을 진지하게 적용하면, 통과하는 사람이 생각보다 훨씬 적다는 걸 알게 될 것이다. 그건 기준이 잘못돼서가 아니라, 우리가 그동안 '수행'이라는 넓은 잣대로 재왔기 때문이다. 잣대를 바꾸면 인재 지도가 다시 그려진다. 그리고 그 지도를 먼저 그리는 회사가, AI 시대 인재 재배치의 선두에 선다.