다음 팀 회의에서 이렇게 질문해 보세요: "우리 팀에서 AI를 가장 잘 사용하는 사람은 누구인가요?"

아마도 잠시 침묵이 흐를 것입니다. 누군가는 도구를 가장 많이 사용하는 사람을 떠올릴 것입니다. 누군가는 프롬프트 (Prompt)를 잘 다루는 사람을 떠올릴 것입니다. 누군가는 최근에 AI로 인상적인 결과물을 만들어낸 사람을 떠올릴 것입니다. 하지만 이 중 어떤 답변도 설득력이 느껴지지 않을 것입니다. 무언가 잘못되었다는 직감이 들지만, 정작 무엇이 올바른 기준인지 아는 사람은 아무도 없습니다.

거의 모든 기업이 현재 이 벽 앞에 서 있습니다. AI 역량 (AI competence)이 채용 및 성과 기준의 최상위로 떠오르고 있지만, 이를 측정할 척도가 없습니다. 이 에세이는 그 척도 하나를 제안합니다. 짧은 답변을 드리자면, 제가 ABCD2라고 부르는 다섯 가지 축의 집합입니다. 하지만 그전에, 질문 자체부터 바로잡아야 합니다.

"AI를 잘 사용한다"는 생각 자체가 틀렸다

이 에세이의 제목은 "AI를 잘한다"라고 되어 있지만, 그 표현 자체가 함정입니다.

"사용한다(using)\

그리고 그들은 무엇을 돕는가? 크게 두 가지입니다. 하나는 **지식 구축 (knowledge building)**입니다. 이는 AI가 서 있는 기반을 마련하는 작업입니다. 즉, 우리 조직의 용어가 실제로 무엇을 의미하는지, 판단 기준은 무엇인지, 좋은 결과물과 나쁜 결과물을 가르는 차이는 무엇인지 등을 AI가 활용할 수 있는 형태로 포착하는 것입니다. 다른 하나는 **컨텍스트 파이프라이닝 (context pipelining)**입니다. 이러한 지식이 적절한 시점에 적절한 형태로 AI에게 전달되도록 흐름을 설계하는 것입니다. 어떤 컨텍스트가 어떤 작업과 함께 전달되어야 하는지, 출력물이 무엇을 기준으로 검증되는지, 그리고 검증에 실패했을 때 어디로 다시 경로가 지정되는지 등을 설계하는 과정입니다.

이러한 관점에서 볼 때, 프롬프트(prompt)란 무엇일까요? 그것은 훨씬 더 긴 흐름의 마지막 줄에 불과합니다. 좋은 프롬프트는 훌륭한 지식 구축과 훌륭한 컨텍스트 파이프라이닝의 _결과물 (output)_이지, 역량 그 자체의 실체는 아닙니다.

예리한 독자라면 이미 눈치챘겠지만, 바로 이 지점에서 **온톨로지 (ontology)**가 중요해집니다. 조직의 용어와 개념, 그들 사이의 관계, 그리고 판단 기준을 AI가 활용할 수 있는 형태로 구조화하는 것 — 이것이 바로 온톨로지의 정의입니다. "지식 구축"이라는 문구에서 한 겹을 벗겨내면, 그 안에서 발견하게 되는 것이 바로 온톨로지입니다. AI가 조직의 실행 엔진 (execution engine)이 되어갈수록, 그 엔진이 발을 딛고 설 온톨로지를 가진 조직과 그렇지 못한 조직 사이의 격차는 더욱 벌어질 것입니다.

기존의 모든 척도가 놓치고 있는 이유

이러한 재정의를 붙잡고 본다면, 오늘날 사용되는 평가 방법들이 왜 모두 목표를 빗나가고 있는지 한눈에 명확해집니다.

전통적인 척도들부터 살펴보겠습니다: 코딩 테스트, 알고리즘 문제, 자격증, 학위 등입니다. 이것들이 실제로 측정해 온 것은 바로 실행 능력 (execution ability) — 즉, 잘 정의된 문제를 얼마나 정확하고 빠르게 수행하는가 하는 점입니다. 하지만 실행이야말로 정확히 AI에게 넘어가 버린 부분입니다. 측정 도구는 여전히 인간을 향하고 있는 반면, 측정 대상은 통째로 AI의 영역으로 이동했습니다. 당연히 예측력은 증발해 버립니다. 코딩 테스트에서 만점을 받는 사람이 AI와 협업을 잘할 것이라는 보장은 없습니다. 오히려 어떤 사람이 잘 정의된 문제를 빠르게 해결하는 데 최적화되어 있을수록, 문제를 정의하고 맥락을 설계하는 데에는 더 서툴 수 있습니다.

그렇다면 AI 시대를 위해 만들어졌다고 여겨지는 새로운 척도들은 어떨까요? 두 가지가 흔히 쓰입니다.

첫째, 프롬프트 기술 (prompt-skill) 평가입니다. 방금 보았듯이, 프롬프트는 흐름의 마지막 단계입니다. 마지막 단계만을 측정하는 것은 마치 플레이팅(plating)만 보고 요리사를 채용하는 것과 같습니다. 설상가상으로, 프롬프트 기술은 특정 도구 및 특정 모델 버전과 결합되어 있어 반감기가 짧습니다. 모델이 발전할수록 이러한 기술(tricks)의 가치는 떨어지며, 결국 남는 것은 _무엇을 요청할 것인가_와 _어떤 맥락을 제공할 것인가_를 설계하는 능력입니다.

둘째, 도구 사용량과 소요 시간입니다. AI를 가장 많이 사용하는 사람이 가장 잘 사용하는 사람이라는 가정이 깔려 있지만, 이는 정확히 정반대일 수 있습니다. 제대로 된 파이프라인 (pipeline)을 구축한 사람은 실제로 타이핑을 더 적게 합니다. 매번 처음부터 시작하여 긴 대화를 수동으로 힘들게 이어가는 사람이 가장 높은 사용량을 기록합니다. 많이 사용하는 것과 그것을 잘 작동하게 만드는 것은 별개의 문제입니다.

이 두 가지 척도의 공통점은 둘 다 "사용" 프레임에서의 측정이라는 점입니다. 도구 숙련도 측정기는 무언가가 일을 잘 수행하도록 만드는 능력을 포착할 수 없습니다.

그렇다면 우리는 무엇을 측정해야 하는가 — ABCD2

"AI가 일을 잘 수행하도록 만드는 능력"은 하나의 덩어리로 측정될 수 없습니다. 이를 측정하려면 분해해야 합니다. 저는 이를 다섯 가지 축으로 분해했습니다: 이해(Comprehend), 추상화(Abstract), 분해(Dissolve), 구축(Build), 설명(Describe). 각 단어의 첫 글자를 따면 ABCD2가 됩니다.

평가자의 관점에서 각 축은 하나의 질문이 됩니다.

Comprehend (이해) — 이 사람은 연결된 세상을 이해하고 있는가? 이들은 작업이 실제로 무엇과 맞닿아 있는지, 이 조직에서 그 단어가 무엇을 의미하는지, 결과에 의해 누가 영향을 받는지 파악하고 있는가? 이해가 없다면, 이들은 AI에게 시키려는 바로 그 일 자체를 오해하게 됩니다.

Abstract (추상화) — 이 사람은 본질을 추상화하는가? 혼란스러운 현실 속에서 실행 가능한 구조를 추출해낼 수 있는가? 좋은 추상화는 중요한 것을 버리지 않으면서 단순화합니다. 이러한 균형 감각이 없다면, AI에게 전달되는 문제 정의는 시작부터 왜곡됩니다.

Dissolve (분해) — 이 사람은 작업을 검증 가능한 단위로 나누는가? 전체 덩어리를 통째로 위임하면 어디서 잘못되었는지 알 수 없습니다. 이들은 AI의 출력을 확인할 수 있는 경계에 따라 작업을 나누는가? 이는 AI가 그럴듯하게 들리는 오답을 내놓았을 때 이를 잡아내는 능력과 직결됩니다.

Build (구축) — 이 사람은 흐름을 설계하는가? 분해된 단위들을 검증 및 폴백(fallback) 기능이 포함된 하나의 흐름으로 엮어내는가? 일회성 요청이 아니라, 반복 가능하며 타인에게 전달할 수 있는 파이프라인(pipeline)을 구축하는가?

Describe (설명) — 이 사람은 설명하고 책임을 지는가? 무엇을, 왜, 어떻게 연결했는지 명확하게 표현할 수 있는가? 그리고 AI의 출력물에 대해, "제가 이런 방식으로 판단하도록 설계했습니다"라고 말하며 책임의 주체가 될 수 있는가?

이미 눈치채셨을 수도 있습니다. 이 다섯 가지 축 중 어디에도 "특정 도구에 대한 숙련도"는 포함되어 있지 않습니다. 도구를 바꾸거나 모델을 바꿔도 이 축들은 여전히 유효합니다. 이것이 채택할 가치가 있는 모든 평가 기준의 최소 요구 사항입니다.

사례 — 동일한 지시, 두 사람

추상적인 축(Abstract axes)만으로는 충분히 와닿지 않을 수 있으니, 한 장면을 가정해 봅시다. 한 매니저가 두 팀원에게 동일한 지시를 내립니다: "AI를 사용하여 이번 달 고객 문의 사항을 분석하고 보고서를 작성하세요."

A는 다음과 같이 합니다: 문의 데이터를 다운로드하여 전체 내용을 AI에 붙여넣고, "이 고객 문의 사항들을 분석해서 주요 이슈를 요약해 줘"라고 요청합니다. 몇 차례의 후속 대화(follow-up exchanges)를 거친 후, 카테고리 분류, 주요 불만 사항, 심지어 개선 제안까지 포함된 깔끔한 요약본이 나옵니다. 소요 시간: 30분. 보고서는 탄탄해 보입니다.

B는 다음과 같이 합니다: 먼저 이 문의 사항들이 어디에서 오는지 확인합니다. 각 채널마다 특성이 다르다는 점을 파악하고, CS 팀이 이미 태깅 분류 체계(tagging taxonomy)를 유지하고 있다는 사실을 학습합니다 (Comprehend). 해당 분류 체계를 기반으로 삼되, 이번 분석의 목적—다음 분기 개선 백로그(improvement backlog) 도출—에 적합한 세 가지 관점, 즉 "반복되는 문의 / 새로운 유형 / 긴급 사항"을 중심으로 재구성합니다 (Abstract). 데이터를 통째로 입력하는 대신, 채널별 및 주차별로 나누어 각 배치(batch)의 결과가 원본과 일치하는지 확인할 수 있도록 합니다 (Dissolve). 분류 기준, 회사의 용어 정의, 그리고 올바른 분류 사례를 하나의 문서로 작성하여 모든 요청에 함께 전달하며, 모호한 사례는 사람의 검토(human review)를 거치도록 합니다 (Build). 그리고 보고서 마지막에 다음과 같이 적습니다: "이 분석은 CS 태깅 분류 체계를 기반으로 작성되었습니다. 채널 X의 데이터는 포함되지 않았습니다. '긴급'의 기준은 다음과 같이 정의했습니다" (Describe). 소요 시간: 반나절.

자, 이제 이번 달 보고서만 놓고 본다면 누가 더 잘했을까요? 판단하기 어렵습니다. 솔직히 말해서, A의 보고서가 더 빨리 나왔고 질적으로 뒤처져 보이지도 않습니다. 기존의 평가 방식—결과물의 품질과 속도—에 따르면, A가 오히려 승리할 수도 있습니다.

그 차이는 다음 달에 나타납니다. 동일한 지시가 다시 내려왔을 때, A는 처음부터 다시 시작합니다. 분류 기준(classification criteria)이 지난달과 달라졌기 때문에 추세 비교(trend comparison)조차 불가능합니다. 반면 B는 이미 구축된 워크플로우 (flow)에 새로운 데이터를 쏟아붓기만 하면 끝납니다. 기준이 안정적이므로 월간 추세 (month-over-month trends)가 축적되며, B가 휴가를 가더라도 다른 사람이 그 워크플로우를 실행할 수 있습니다. A가 남긴 것은 보고서입니다. B가 남긴 것은 자산 (asset)입니다.

이것이 핵심입니다. 기존의 평가는 오직 "이번 달의 결과물"만을 바라보기 때문에 A와 B를 구분할 수 없습니다. ABCD2는 결과물이 아니라 그것을 만들어낸 프로세스 (process) 내의 다섯 가지 지점을 바라보기 때문에 이를 구분할 수 있습니다.

실전 — 인터뷰와 성과 검토에서 질문하는 법

그렇다면 인터뷰나 성과 검토 (performance review)에서 실제로 ABCD2를 어떻게 탐색해야 할까요? 각 축(axis)별로 한 가지 예시를 들어보겠습니다.

Comprehend (이해) — 맥락 (context)을 의도적으로 누락시킨 과제를 부여합니다. "AI를 활용해 우리 서비스의 이탈률 (churn rate)을 어떻게 분석하시겠습니까?"라고 질문하되, "이탈"에 대한 정의나 데이터에 대한 설명은 하지 않습니다. 역량 있는 후보자는 답변하기 전에 되묻습니다. "이탈을 어떻게 정의하고 있으며, 어떤 데이터를 보유하고 있습니까?" 질문 없이 그럴듯해 보이는 절차를 바로 시작하는 사람은, 실제 업무에서도 AI에게 잘못 이해된 문제를 던져줄 사람입니다.

Abstract (추상화) — 엉망인 실제 사례를 주고 이를 구조화하게 합니다. 예외 사항이 가득한 비즈니스 프로세스 (business process)를 던져주고, "이 업무를 AI에게 위임한다면 어떤 단계들로 구성하시겠습니까?"라고 물어보십시오. 모든 예외 사항을 억지로 끼워 넣으려는 사람과, 중요한 것마저 버려버리는 사람 사이에서 적절한 균형을 찾아내는지 관찰하십시오.

Dissolve (해체) — AI가 내놓은 그럴듯하게 틀린 답을 제시합니다. 문장은 매끄럽게 읽히지만 사실 관계에 오류가 하나 포함된 결과물을 보여주며, "이것을 검토해야 한다면 어떻게 하시겠습니까?"라고 묻습니다. "전체를 다시 읽어보겠습니다"라고 답하는 것과 "검증 가능한 단위로 나누어 각각 원천 데이터 (source)와 대조하겠습니다"라고 답하는 것은 완전히 다른 역량입니다.

Build (구축) — 다음과 같이 후속 질문을 던지세요: "만약 이 작업을 매주 반복해야 한다면 어떻게 하시겠습니까?" 그들이 일회성 솔루션을 반복 가능한 흐름 (repeatable flow)으로 전환할 수 있는지, 그리고 검증 (verification)과 예외 처리 (exception handling)가 흐름 내에 설계되어 있는지 확인하십시오.

Describe (설명) — 지원자가 만들어낸 AI 결과물에 대해 다음과 같이 질문하십시오: "만약 이 결과가 틀린 것으로 판명된다면, 누구의 책임입니까?" "AI가 그렇게 만들었습니다"와 "이러한 기준에 따라 판단하도록 제가 설계했으므로 제 책임입니다. 그리고 제가 수정할 부분은 다음과 같습니다" 사이의 간격이 바로 이 축의 핵심입니다.

이 질문들의 공통점을 발견하셨을 것입니다. 이 중 정답이 정해진 질문은 하나도 없습니다. 이 질문들은 사람이 문제를 처리하는 방식을 드러내는 질문들입니다. 실행 능력 (execution-ability) 테스트와는 정반대 방향에 있는 질문들입니다.

프레임 완성하기 — 세 가지 축

ABCD2만으로는 채용 결정을 내리기에 충분하지 않습니다. 여기에 두 가지 축을 더하면 실제로 사용할 수 있는 프레임워크가 됩니다. 하나는 **성격 적합성 (personality fit)**입니다. 이 사람이 애초에 그러한 사고방식과 책임감을 감당할 만한 기질을 갖추고 있는가 하는 점입니다. 다른 하나는 **도메인 적합성 (domain fit)**입니다. 그들이 반드시 이해하고 연결해야 하는 세계가 정확히 우리의 도메인인가 하는 점입니다. 누군가의 ABCD2가 아무리 높더라도 도메인 지식이 없다면 그들의 Comprehend (이해)는 작동하지 않습니다. 또한 역량과 도메인이 아무리 잘 일치하더라도, 책임을 회피하는 기질을 가진 사람은 Describe (설명) 축에서 무너지고 맙니다.

종합하면 다음과 같습니다: ABCD2 (역량) × 성격 적합성 (기질) × 도메인 적합성 (맥락). 이 세 가지 축이 "AI 시대에 인재를 어떻게 채용하고 배치할 것인가?"라는 질문에 대한 저의 답변입니다.

맺음말 — AI를 잘 사용하는 사람을 찾는 것을 멈추십시오