
그 'AI 활용 레벨 8단계', 팀의 실력 지표로 사용하고 계신가요?
요약
AI 활용 8단계를 팀의 실력 지표로 오해하는 경향을 지적하며, 이는 실력이 아닌 도구 구성의 분류임을 설명합니다. 적절한 AI 활용 레벨은 작업의 신뢰도와 실패 시 리스크(Blast Radius)에 따라 결정되어야 함을 강조합니다.
핵심 포인트
- AI 활용 레벨은 실력 지표가 아닌 도구 구성의 분류임
- 높은 레벨이 반드시 우수한 것은 아니며 과제에 따라 선택해야 함
- 신뢰 구간 추정과 장애 발생 시 영향 범위(Blast Radius) 고려가 핵심
- 리스크 관리 방식에 따른 전략적 레벨 선택이 중요함
이 기사는 note에 쓴 글을 엔지니어를 위해 가감하여 수정한 것입니다.
결론부터 말하자면, 다음에 제시하는 'AI 활용 레벨 8단계' 표는 팀의 실력 지표가 아니라 수단의 분류입니다. 레벨은 '어떤 도구 구성을 사용하고 있는가'의 분류이며, 'AI의 출력에 대해 무엇을 할 수 있는가'라는 실력과는 다른 축입니다. 게다가 출처인 Every지 스스로도 "레벨이 높을수록 우수한 것은 아니다", "레벨 5~8은 엔지니어 영역이며, 프론티어 엔지니어라도 레벨 8은 인간이 담당하고 있는 실험 단계이다"라고 반복해서 유보 조항을 두고 있음에도 불구하고, SNS상에서는 그 유보 조항만 삭제된 채 "계단을 올라갈수록 우수해진다"라는 오독이 독자적으로 퍼지고 있습니다.
지표로 삼아야 할 것은 레벨의 숫자가 아니라, "AI가 인간의 개입 없이 좋은 일을 수행하는 것을 얼마나 신뢰할 수 있는가"와 "실패했을 때 어느 정도의 손해가 발생하는가"라는 두 가지 척도입니다. 이 기사에서는 그 근거가 된 1차 자료의 검증 과정과, 나름대로 설계한 실력 기반의 대체 지표(급수표)를 소개합니다.
X(구 Twitter)에서 "팀 멤버 간의 AI 활용 레벨 차이가 너무 커서 객관적인 지표가 필요하다"라는 게시물을 보았습니다. 답글에는 "@every 참조"라는 한마디와 함께 이미지 한 장이 첨부되어 있었습니다.
챗봇(Chatbot)부터 오케스트레이터(Orchestrator)까지, AI의 활용도를 8단계로 정리한 표입니다. 링크는 걸려 있지 않았고 이미지뿐이었습니다.
첨부되어 있던 이미지는 이 표였습니다.
| 레벨 | 설명 |
|---|---|
| 레벨 1 — 챗봇 (Chatbot) | AI에 지시를 내리면 답변을 돌려준다 |
| ... |
팀의 스킬 맵(Skill Map)으로 사용하기에는 충분해 보입니다. "우리 멤버는 지금 어느 레벨인가"를 판정 기준으로 삼는다면 육성 계획이나 태스크 할당에도 사용할 수 있을 것 같습니다. 실제로 이 표를 평가 축처럼 다루고 있는 현장을 본 적도 있습니다.
이것이 정말 평가 지표가 될 수 있을까. 궁금해져서 출처를 찾았습니다. "@every"라는 답글 한마디가 단서였고 링크는 없었습니다. 검색 끝에 도달한 곳이 Every지의 원문 기사인 The Eight Levels of AI Adoption (저자: Mike Taylor, Laura Entis, Claude)였습니다.
읽으면서 가장 먼저 놀란 점은, 저자가 "레벨이 높을수록 우수하다"라는 해석을 기사 서두에서 명확히 부정했다는 점입니다.
A higher level isn't necessarily better. The most sophisticated AI users I know operate at several levels at once, identifying the best level to work within based on the specific challenge in front of them.
레벨이 높다는 것이 반드시 좋은 것은 아니다. 내가 아는 가장 세련된 AI 사용자들은 여러 레벨을 동시에 운용하며, 눈앞의 과제에 따라 작업하기에 가장 적합한 레벨을 식별한다.
어떤 레벨이 적절한지는 "AI가 인간의 개입 없이 좋은 일을 수행하는 것을 얼마나 신뢰할 수 있는가"와 "실패했을 때 얼마나 타격이 큰가"로 결정된다고 저자는 쓰고 있습니다. 엔지니어링 측면에서 바꾸어 말하면, 모델의 출력에 대한 신뢰 구간(Confidence Interval)의 추정과 장애 발생 시의 블래스트 반경(Blast Radius, 영향 범위)의 추정입니다. 하이 스테이크스(High-stakes)한 운영 환경이라면 낮은 레벨에 머물며 사람이 리뷰하거나, 높은 레벨에서 동등한 신뢰성을 내기 위한 테스트, 가드레일(Guardrail), 롤백(Rollback) 메커니즘에 공수를 투자합니다. 둘 다 리스크를 받아들이는 방식의 선택일 뿐, 우열의 문제가 아닙니다.
나아가 저자는 레벨별 주전장(Main battlefield)에 대해서도 구체적으로 쓰고 있습니다.
The sweet spot for knowledge workers right now falls somewhere between Levels 1 and 4. Engineers are more often in Levels 5 through 8, partly because they can build the scaffolding that makes newer, less stable systems usable before they're ready for everyone else.
일반적인 지식 노동자의 현재 위치는 레벨 14 중 어딘가에 머문다. 엔지니어가 레벨 5678에 있는 경우가 많은 이유는, 아직 누구에게도 안정적이지 않은 새로운 시스템을 다른 사람들이 사용할 수 있게 되기 전에 스스로 다룰 수 있는 토대, 즉 발판을 직접 구축할 수 있기 때문이다.
레벨 5 「워크플로우 (Workflow)」 항목에는 "This level is primarily the domain of engineers." (이 레벨은 주로 엔지니어의 영역이다)라고 명시되어 있다. 레벨 7 「멀티 에이전트 (Multi-agent)」에는 "This level is firmly in senior engineering territory—it is rare for knowledge workers to be running multiple parallel agent sessions." (이 레벨은 명확히 시니어 엔지니어의 영역이며, 지식 노동자가 여러 개의 에이전트 세션을 병렬로 운용하는 것은 드문 일이다)라고 적혀 있다.
그리고 레벨 8 「오케스트레이터 (Orchestrator)」에는 더욱 심도 있는 유보 조항이 붙어 있었다.
It's critical to note that this level is highly experimental. Even engineers operating at the frontier still largely fill the role of orchestrator themselves rather than trusting an orchestrator agent to handle complex coordination work.
(이 레벨은 매우 실험적이라는 점에 주의해야 한다. 프론티어에서 활동하는 엔지니어조차 복잡한 조정 작업을 오케스트레이터 에이전트에게 맡기기보다는, 대부분의 경우 스스로가 오케스트레이터 역할을 수행하고 있다.)
프론티어의 엔지니어조차 레벨 8은 아직 인간이 오케스트레이터 역할을 맡고 있다. 저자는 그렇게 단언한다. 멀티 에이전트 오케스트레이션 프레임워크 (Multi-agent orchestration framework)를 다뤄본 적이 있는 엔지니어라면 이 문장의 무게감을 이해할 것이다. 에이전트 간의 상태 공유, 에러 전파, 태스크 분할의 타당성을 현재의 도구만으로 완전히 맡길 수 있는 단계에는 아직 이르지 않았다.
X(구 Twitter)에서 유통되던 이미지에는 이러한 일련의 유보 조항들이 모두 포함되어 있지 않았다. Level과 Description이라는 두 열만 추출되어 있었으며, "레벨이 높을수록 우수하다"는 식의 해석을 부정하는 서두의 문장과 "레벨 5·7·8은 엔지니어 영역"이라는 명시도 통째로 누락되어 있었다.
"객관적인 지표를 원한다"는 수요에 대해 저자가 명시적으로 부정했던 "계단식으로 읽는 방식"만이 살아남아, 평가 지표로서 소비되고 있다. 이는 악의적인 왜곡이라기보다, 표(Table) 자체가 단독으로 완결된 것처럼 보이기 때문에 발췌하기 쉬웠기 때문일 것이다. 다만, 발췌되는 순간 저자가 가장 강력하게 경고했던 부분이 사라지는 구조적 문제가 남는다. 이는 문서에서 코드 조각만 뽑아 복사하여 붙여넣으면서, 전제 조건이나 제약 사항에 대한 주석을 놓쳐버리는 사고와 같은 구도다.
저자가 본문에서 아무리 "레벨이 높다고 해서 좋은 것은 아니다"라고 써도, Level 1부터 Level 8까지 일련번호를 부여한 시점에서 서열로 읽힐 토대는 이미 마련된다. X(구 Twitter)에서의 오독은 이미지가 유보 조항을 깎아낸 데다, 번호 매기기(Numbering)라는 형식 자체가 오독을 불러일으키기 쉬운 구조를 처음부터 안고 있었던 점이 겹쳐서 발생한 것이라고 생각한다.
칼럼: 번호 매기기가 서열을 암시한다는 점은, 분류하는 측에서 아무리 말을 아껴가며 "이것은 서열이 아니다"라고 설명해도 기호 자체가 가진 서열 암시력이 더 강력하게 작용하는 사례로, AI 활용 외의 분야에서도 찾아볼 수 있다. 동네 하천의 표지판에 '1급 하천'이라고 적힌 것을 보고, "이렇게 가는 하천이 1급인가?"라고 생각한 적은 없는가? 1급·2급이라는 구분은 하천의 크기나 수질의 등급이 아니다. 실제 기준은 유역의 중요성과 관리 주체의 차이(1급은 국토교통부 장관, 2급은 도지사가 지정 및 관리)이다. 작은 하천이 1급 하천으로 지정된 사례도, 큰 하천이 2급 하천에 머무는 사례도 전국에 흔히 있다. 그럼에도 '1급', '2급'이라는 기호를 보면 많은 사람은 우선 우열의 순서로 받아들인다. Every지의 "Level"도 동일한 구조를 안고 있다.
내가 관찰하는 범위 내에서도 최근 "레벨 7·8을 해보고 싶다"는 목소리가 늘어나는 것을 목격한다. 멀티 에이전트를 돌려보고 싶다거나, 오케스트레이터를 구축해보고 싶다는 목소리들이다.
그러한 동기 속에는 실무적인 필요에 의한 것이라기보다, X(구 Twitter)에서 흔히 보이는 "AI 에이전트에게 일을 맡겼더니 한 달에 수천 달러를 벌었다"와 같은 AI 놀라움 판매자(AI hype-monger)의 존재가 크다고 생각합니다.
저 또한 직접 멀티 에이전트(Multi-agent) 구성을 만들어 보았습니다만, 이를 수행하기 위해서는 대상 업무에 대한 깊은 업무 지식과, 이를 에이전트의 지시서(Markdown 등)로서 모호함 없이 정확하게 기술할 수 있는 기술이 필요했습니다. 이는 곁다리로 할 수 있는 수준의 일이 아닙니다.
앞서 보았듯이, 그 레벨은 프론티어(Frontier) 엔지니어조차 아직 인간이 담당하고 있는 실험 단계입니다. 레벨 5의 항목에는 그 전 단계에서 필요하게 되는 작업에 대해 다음과 같이 적혀 있습니다.
Reviewing a plan, evaluating which tests need to be done, and designing the harness that keeps the agent from going off the rails all require an understanding of what's happening under the hood.
계획을 리뷰하고, 필요한 테스트를 파악하며, 에이전트가 탈선하지 않도록 하는 메커니즘(Harness)을 설계하는 것. 이 모든 것은 내부에서 어떤 일이 일어나고 있는지를 이해하고 있음을 전제로 합니다.
토대(내부 메커니즘에 대한 이해, 실패 시 스스로 디버깅 및 롤백(Rollback)할 수 있는 기술력, 장애의 영향 범위를 감당할 수 있는 리스크 허용도)를 쌓기 전에 계단의 윗단만을 목표로 삼는다면, 저자가 처음에 부정했던 "레벨이 높다 = 뛰어나다"라는 오해를 그대로 실행에 옮기는 셈이 됩니다. 표를 평가 지표로 받아들이는 시점에서, 이미 저자의 경고와 반대 방향을 향하고 있기 때문입니다.
비슷한 형태의 표는 Every지의 8단계뿐만이 아닙니다. "AI와의 관계"를 검색 엔진, 작업 어시스턴트, 전문 파트너, 업무 시스템, 개발 기반이라는 단계로 나누고 각각에 급을 매긴 표를 본 적도 있습니다. 내용은 다르더라도 구조는 같습니다. 단계를 나열하고, 아래에서 위로 올라가는 것으로 제시합니다.
이러한 표는 언뜻 보면 "나(혹은 팀원)가 지금 어디에 서 있으며, 다음에 어디를 목표로 해야 하는가"를 보여주는 스킬 맵(Skill map)처럼 보입니다. 스킬 맵이라고 생각하며 바라보았지만, 자세히 보면 현재 위치의 바늘이 움직이지 않습니다.
이는 Every지 스스로가 쓰고 있는 내용과 일치하기 때문입니다. "가장 세련된 AI 사용자는 여러 레벨을 동시에 구분하여 사용하고 있다". 어떤 태스크는 레벨 2, 다른 태스크는 레벨 6라는 일이 흔히 발생하므로, "이 멤버는 현재 레벨 5입니다"라는 단일 평가 방식은 처음부터 성립되지 않습니다. 목적지도 제시할 수 없습니다. 저자는 "레벨이 높다고 해서 반드시 좋은 것은 아니다", "레벨 5·7·8은 엔지니어 영역이며, 프론티어 엔지니어조차 레벨 8은 인간이 담당하고 있다"라고 반복해서 주의를 주고 있습니다. 지향해야 할 이유가 제시되지 않은 도달점은 목적지라고 부를 수 없습니다.
이러한 표들이 실제로 보여주는 것은 현재 위치도 목적지도 아닌, "어떤 도구 구성(Tool configuration)을 사용하고 있는가"라는 도구의 분류입니다. 챗봇을 사용하고 있는지, 에이전트를 사용하고 있는지, 여러 에이전트를 조합하여 사용하고 있는지. 그것은 구성의 차이이지, 능력의 차이가 아닙니다.
지표라고 부를 수 있는 것이 있다면, 그것은 "어떤 도구를 사용하는가"가 아니라 "AI의 출력에 대해 무엇을 할 수 있는가"여야 합니다. 같은 레벨 4(오토파일럿, Autopilot)를 사용하더라도, 생성된 코드의 타당성, 경계값의 누락 여부, 성능 저하를 판별할 수 있는 사람과 테스트가 통과되었다고 해서 그대로 머지(Merge)하는 사람 사이에는 실력이 완전히 다릅니다. 반대로, 챗봇(레벨 1)만 사용하더라도 프롬프트(Prompt)를 구성하는 방식 하나로 출력의 정밀도를 크게 바꿀 수 있는 사람도 있습니다. 도구 구성의 고도화와 사용자의 실력은 별개의 축입니다. 이 표를 "실력의 지표"로 읽어버리는 것은 CI 파이프라인의 복잡성을 엔지니어의 숙련도 점수로 그대로 취급하는 것과 같다고 생각합니다.
X(구 Twitter)의 원래 게시물이 요구했던 것은 "객관적인 지표"였습니다. 답을 내리자면, 8단계 표 그 자체는 평가 지표가 되지 않습니다. 지표로 삼아야 할 것은 저자가 반복해서 사용하고 있는 두 가지 척도입니다.
- AI가 인간의 개입 없이 좋은 일을 수행하는 것을 얼마나 신뢰할 수 있는가
- 그 일이 실패했을 때 어느 정도의 손실이 발생하는가
이 두 가지를 기준으로 현재의 태스크에 어느 레벨이 적정한지를 결정합니다. 레벨의 숫자는 결과이지 목표가 아닙니다. "저 멤버는 레벨 3에 머물러 있다"가 아니라 "이 태스크는 신뢰도와 리스크를 고려했을 때 레벨 3이 적정하다"라는 순서로 생각한다면, 같은 표라도 읽는 방법은 완전히 달라질 것입니다.
그리고 이 두 가지 척도 또한, 궁극적으로는 "무엇을 할 수 있게 되었는가"를 묻는 도구입니다. AI의 판단을 어디까지 신뢰할 수 있는지 파악할 수 있는 것 자체가 실력이며, 장애의 손해를 정확히 추산할 수 있는 것 자체가 실력입니다. 툴 구성의 레벨을 쫓는 것이 아니라, 툴을 능숙하게 다루는 자신의 판단력을 단련해야 합니다. 평가 지표를 찾는다면 그쪽을 향하는 것이 좋다고 생각합니다.
그럼에도 단계를 만들고 싶다면, "어떤 툴을 사용하고 있는가"가 아니라 "AI의 출력(Output)에 대해 무엇을 할 수 있는가"로 구분합니다. 시험 삼아 만들어 보면 다음과 같습니다.
| 급 | 제목 | 무엇을 할 수 있는가 |
|---|---|---|
| 5급 | 알아채지 못함 | AI의 출력을 그대로 머지(Merge)·채택한다. 오류를 알아채지 못해 후속 공정이나 리뷰에서 발견된다 |
| ... |
같은 챗봇(Chatbot)만 사용하고 있어도 2급인 사람이 있고, 오케스트레이터(Orchestrator)를 돌리고 있어도 5급인 사람이 있습니다.
당면한 목표로서는 3급(수정시킬 수 있음)을 목표로 하는 것이 현실적이라고 생각합니다. 오류를 알아채고, 지시를 다시 내려 수정하게 만들 수 있는 단계까지 오면 일상 업무의 대부분은 처리할 수 있습니다. 2급·1급(판단할 수 있음·체계화할 수 있음)은 Every지가 레벨 5·7·8을 "엔지니어의 영역", "프론티어 엔지니어라도 인간이 담당하고 있는 실험 단계"라고 위치 지었던 것과 같은 의미로, 아직 엔지니어의 시제품(Prototype) 영역이라고 생각합니다. 사전 설계로 리스크를 없애거나, 혹은 체계 그 자체를 타인이나 AI가 운용하도록 안정적으로 가져가는 것은 사후 리뷰 경험을 쌓은 뒤의 이야기입니다. 3급을 건너뛰고 2급·1급의 간판만 내걸어도 내용은 따라오지 않습니다.
이 5단계의 차이는 실제로 손을 움직일 때 어떻게 나타날까요? 예를 들어 문장 퇴고에 AI를 사용하는 상황을 생각해 보겠습니다. 5급인 사람은 AI가 생성한 문장을 그대로 사용합니다. 즉, AI 슬롭(AI Slop)의 양산입니다. 3급인 사람은 생성된 문장에 자신의 생각·말하고자 하는 바가 올바르게 표현되어 있는지를 체크하고, 수정을 반복함으로써 품질을 높입니다. 2급·1급인 사람은 퇴고 로직 그 자체를 체계(System)에組み込み(組み込み, 내장)하지만, 이것이 가능한 것은 규칙 아래에서 작성하는 정형 문서·기술 문서·조작 매뉴얼 등 정오(正誤)의 기준이 명확한 문장에 한정됩니다. 쓰는 이의 해석이나 말투가 요구되는 문장에서는 퇴고 로직을 기계적인 규칙으로 떨어뜨리는 것 자체가 좀처럼 떠오르지 않습니다. 이 부분은 인간의 스킬로서 얼마나 추상적으로 분석 표현할 수 있는가라는 스킬과 관련됩니다. 따라서 2급·1급은 엔지니어 영역인 동시에 대상 문서의 전문 영역에도 의존하게 됩니다.
같은 레벨 8이라는 툴 구성이라도, 사용하는 사람의 급에 따라 "오류의 증폭 장치"가 될 수도 있고 "오류를 막는 체계"가 될 수도 있습니다. 이 변동 폭은 Every지의 8단계를 보고 있는 것만으로는 알 수 없습니다. "어떤 툴 구성을 사용하고 있는가"라는 축과 "사용자가 무엇을 꿰뚫어 볼 수 있는가"라는 축은 별개의 것이며, 이 양쪽을 겹쳐서 보아야 비로소 "누가 사용하면 어떤 일이 일어나는가"까지 보입니다.
1on1에서 "레벨 7·8을 목표로 하고 싶다"는 멤버가 있다면, 먼저 물어야 할 것은 "그 툴을 써보고 싶은가"가 아니라 "지금의 태스크에서 AI의 출력을 어디까지 리뷰하고 있는가"라고 생각합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기