서론 ― 단계 구분은 조직의 AI 체력 테스트다

"우리도 AI 활용하고 있어!"라고 말하는 사람과 이야기하다 보면, 자세히 들어보니 탭 보완(Tab Completion)만 사용하고 있었다는 경우가 꽤 있다. 반대로, "서브 에이전트(Sub-agent)를 역할별로 나누고 리뷰도 별도의 에이전트에게 맡기고 있다"는 식으로 운영이 한 단계 높은 팀도 있다. 같은 "AI 활용"이라도 그 내용은 천지 차이다.

이를 단계별로 맞추기 위한 좋은 프레임워크를 최근 접하게 되었다.

원문 기사의 주장을 요약하자면 **"현실적인 해답은 레벨 7이며, 레벨 8은 아직 이르다"**는 것이다. 이를 자신의 운영 방식에서 직접 비용을 지불하며 검증한 결론도 거의 동일했다. 여기에 나만의 독자적인 시각으로서 **"레벨 5야말로 가장 위험하다"**라는 경고를 덧붙이고 싶다.

이 글의 목표는 다음 세 가지다.

**L7(서브 에이전트 + 책무 분할)**을 현실적인 해답으로 이해하기 -
L5의 함정(MCP 정비로 아웃풋 속도만 올라가고, 리뷰어가 침몰하는 현상)을 가시화하기 -
자신의 위치를 측정하는 공통 언어로서 8단계를 사용할 수 있게 되기

3줄 요약 ― 이것만 가져가도 좋다

현실적인 해답은 레벨 7― 서브 에이전트 + 책무 분할 + AI 간의 리뷰. 인간은 상류 단계의 감독 역할을 수행한다 -
레벨 5가 가장 위험한 구역― MCP/Skills만 갖춰져 있고, 품질 보증은 여전히 인간에게 의존하는 상태 -
레벨 8은 아직 이르다― Agent Teams는 미래 가능성이 높지만, 현재는 가성비 측면에서 맞지 않는다

8단계 요약표 ― 스캐너는 여기만 봐도 된다

"우리 팀은 레벨이 몇 단계지?"라는 대화를 상사나 부하 직원에게 던져보길 바란다. 그것만으로도 꽤 많은 깨달음을 얻을 수 있을 것이다.

왜 단계별로 보는 것이 그렇게 중요한가?

DevOps를 해온 사람들에게는 익숙한 사고방식이지만, 조직의 능력을 단계별로 가시화하는 것은 Capability Maturity Model (CMM)의 계보이며, Lean과 DevOps 세계에서 수없이 다뤄온 이야기다. 그것의 AI 버전이 지금 정리되려 하고 있다.

왜 그렇게 중요한가 하면,

• "우리 AI 사용합니다!"라고 하지만, 실제로는 개인의 탭 보완 수준에 머물러 있는 경우가 있다 -
• 옆 팀과 비교했을 때 무엇이 부족한지 언어화할 수 없다 -
• 경영진에게 "다음에 무엇에 투자해야 하는가"를 설명할 공통 언어가 없다

이런 부분들을 단번에 맞출 수 있기 때문이다. "우리 팀은 레벨 5이고, 반년 안에 레벨 6으로 올리자"라는 대화가 성립되는 순간, AI 투자 논의는 차원이 달라진다.

레벨 1-2: 탭 보완과 AI 에디터 ― 여기서 멈춰 있으면 아무것도 쌓이지 않는다

GitHub Copilot이 탭 보완으로 세상을 뒤흔들었다. 이어서 Cursor / Windsurf / Antigravity 같은 **AI 통합 에디터 (AI-integrated Editor)**가 등장하여, 에디터 내장 채팅을 통해 여러 파일에 걸친 변경 사항을 제안할 수 있게 되었다.

레벨 1-2는 어디까지나 개인 단위의 이야기다. 조직 능력으로서는 아직 아무것도 쌓이지 않았다. "우리 팀은 AI를 사용합니다"라고 말하기 쉬운 페이즈지만, 여기서 멈춰 있는 조직은 출발선에 서 있지 않다고 생각하는 편이 좋다.

레벨 3-4: 에이전트화 + 컨텍스트 정비 ― 여기서부터 조직의 이야기가 된다

여기서부터 AI가 **에이전트 (Agent)**로서 움직이기 시작한다. 스스로 파일을 읽고, 편집하고, 터미널을 실행하며, 테스트를 돌린다. 다만, 그대로 사용하면 노이즈가 너무 많아지기 때문에,

• **시스템 프롬프트 (System Prompt)**의 정비 -
• 규칙 파일 (Rule File) (CLAUDE.md / .cursorrules 계열)의 정비 -
• 컨텍스트 엔지니어링 (Context Engineering) (필요한 것만 전달하도록 하는 설계)

이 부분이 고조되었다. 팀 단위로 배포 및 공유할 수 있다는 점이 핵심이다. 레벨 1-2는 개인 플레이였지만, 여기서부터 처음으로 「여러 명이 함께 수준을 끌어올리는 것」이 가능해진다.

다만, 정밀도는 올라가도 AI가 할 수 있는 일의 폭은 넓어지지 않는다. 이것이 레벨 5로 가는 복선이 된다.

레벨 5: MCP + Agent Skills ― 주전장이지만 가장 위험한 구간

MCP (Model Context Protocol) 와 Agent Skills 가 AI의 능력 그 자체를 확장한다. 레벨 3-4까지는 「어떻게 사용할 것인가」를 정리했지만, 기업이 업무에 도입하려면 결국 기존 시스템과 연결되지 않으면 아무 소용이 없다.

• 근태 관리 서비스
• 급여·인사 계열의 백오피스 (Back-office)
• 사내 DB · 문서 저장소 (Document Store)
• 채용 워크플로우 (Workflow)

이러한 벽을 MCP가 허물었다. Agent Skills는 기업의 도메인 지식 (Domain Knowledge)을 AI에게 전달하는 메커니즘으로서 정비가 진행되고 있다.

결과적으로,

• AI가 할 수 있는 일의 폭이 단번에 넓어졌다
• 엔지니어가 아닌 비즈니스 직군에게도 혜택이 돌아가기 시작했다
• 「AI, 우리 업무에서도 쓸 수 있겠는데?」라고 깨닫는 비엔지니어가 급증했다

2026년 5월 현재, 체감상 많은 기업이 여기에 머물고 있다. 레벨 5는 지금의 주전장이다.

…하지만 말이다, 여기에 함정이 있다. 다음 섹션에서 거칠게 써 내려가 보겠다.

여기가 가장 위험하다 ― 레벨 5의 함정을 조금 더 높은 해상도로

원문은 「현실적인 해답은 레벨 7」이라는 결론인데, 그 자체에는 동의한다. 하지만 나는 그보다 앞서 레벨 5에서 수렁에 빠지는 조직이 가장 많아질 것이라고 예상한다.

포인트는 「AI 캐치업 (Catch-up) 정도가 멤버마다 천차만별이다」라는 사실이다.

• 숙련도가 높은 멤버: 프롬프트 (Prompt)를 다듬고, 스스로 출력을 검증한 뒤 PR (Pull Request)을 올린다.
• 숙련도가 낮은 멤버: AI의 출력을 거의 체크하지 않고 PR에 쌓는다.

MCP/Skills를 워크플로우에 제대로 통합한 후에, 이 격차를 인간의 리뷰만으로 흡수하려고 하면, 질 낮은 결과물이 양산되어 검토 측이 과부하에 걸린다. 레벨 5에서 「우리도 AI 활용이 잘 되고 있어!」라며 만족해버리지 말고, 하네스 정비 (L6)와 서브 에이전트 (Sub-agent) 설계 (L7)를 세트로 준비한다는 의식이 리더층에 없으면 여기서 카오스가 발생한다.

「꽤 위험할지도 모르겠다」는 것이 나의 솔직한 감각이다.

레벨 6: 하네스 엔지니어링 (Harness Engineering) ― AI가 스스로를 바로잡는 메커니즘

「하네스 엔지니어링」이라는 말을 처음 듣는 사람도 있을 것이다. 간단히 말하면 모델 이외의 주변 메커니즘의 정비 전반을 의미한다. 말의 장구류인 하네스(Harness) 이미지로, 모델 본체(=말)를 제어하기 위한 장구 일set라고 생각하면 된다.

레벨 6에서 하는 일은 다음과 같다.

• AI에게 성공 기준을 부여한다 (테스트 통과 · 타입 검사 통과 · Lint 통과 등)
• AI에게 검증 절차를 부여한다 (스스로 동작 확인을 할 수 있도록 함)
• 실패하면 스스로 원인을 분석하여 자율적으로 루프 (Loop)를 돌리는 설계로 만든다

즉 자동 피드백 루프 (Automatic Feedback Loop) 가 돌아가는 메커니즘을 만드는 것이 레벨 6의 핵심이다. 레벨 5까지는 「AI에게 이것저것 시키는 것」뿐이었지만, 여기서부터는 AI가 스스로 개선하게 된다. 이것이 인간의 리뷰 부하를 직접적으로 줄이는 가장 효과적인 수단이다.

레벨 5 → 6의 벽이 다른 단계에 비해 너무 두꺼운 건에 대하여

레벨 3-4에서 레벨 5로의 점프는 솔직히 툴 도입으로 어떻게든 된다. MCP 대응 툴을 넣고 Skills를 작성하는 단계까지는 AI 캐치업이 진행된 개인이라면 혼자서 돌파할 수 있다.

하지만, 레벨 5 → 레벨 6은 차원이 다르다. 이는 독자적인 검증을 통해 실감했다.

레벨 6의 하네스 (Harness)는 한 번 만들고 끝나는 것이 아니다. 프로젝트가 바뀌면 하네스도 바뀌고, 새로운 툴이 나오면 다시 구성해야 한다. 지속적인 브러시업 (Brush-up)이 필요한 세계다. 이를 개인적인 차원에서 수행하면 회수가 불가능하다. 반면, 많은 인원이 사용할수록 효과가 승수 (Multiplier)로 작용하기 때문에, 조직 차원의 투자 판단이 내려지지 않으면 앞으로 나아갈 수 없다.

리더층과 경영진을 끌어들이지 않으면, 레벨 5에서 영원히 제자리걸음을 하게 된다.

이것이 현실적인 해답이다

레벨 7: 에이전트 오케스트레이터 (Agent Orchestrator) ― 여기서부터가 본 기사의 주인공, 레벨 7이다.

레벨 7의 핵심은 **에이전트의 오케스트레이션 (Orchestration)**이다. Claude Code와 같은 툴이 가진 서브 에이전트 (Sub-agent) 기능을 역할별로 나누어 사용하는 이미지다.

책임을 나눈다는 것은 무엇인가 ― 3 에이전트 체제의 구체적인 예

추상적으로 "책임을 나눈다"라고 말하면 전달되기 어려우므로, 내가 실제로 운용 중인 3 에이전트 체제를 적어두겠다.

구현 에이전트 (Implementation Agent)

• 역할: 코드를 작성하고 테스트를 통과시킴
• 부여할 스킬 (Skill): 구현 관점 (코딩 규칙, 프레임워크 관례, 테스트 작성법)
• 부여할 권한: 파일 편집 (Edit/Write), 테스트 실행 (Bash)
• 부여하지 않을 권한: PR 머지 (Merge), 운영 환경 배포 (Production Deploy)

리뷰 에이전트 (Review Agent)

• 역할: 구현 에이전트의 결과물을 다른 시각에서 체크
• 부여할 스킬 (Skill): 코드 리뷰 관점 (가독성, 유지보수성, 보안, 엣지 케이스)
• 부여할 권한: 읽기 전용 (Read/Grep)
• 부여하지 않을 권한:
  편집 권한은 의도적으로 제외한다. 리뷰 전담으로 설정함으로써 "직접 수정하러 가고 싶어지는" 유혹을 차단한다.

오케스트레이터 (인간)

• 역할: 사양 전달 → 구현 에이전트에게 작성 지시 → 리뷰 에이전트에게 통과 → 필요 시 반려 (Reject) → 머지 (Merge) 판단
• 보유 항목: 사양서, 요구사항, 판단 기준
• 가장 중요한 업무:
  "AI들이 모두 OK라고 하고 있지만, 정말로 이것이 맞는가?"를 마지막에 질문하는 것

이 세 가지를 돌리는 것만으로도, 레벨 5에서 발생하던 "체크 없는 PR의 범람"이 거의 사라진다. 리뷰 작업의 제1단계를 별도의 AI가 맡기 때문에, 인간은 판단에만 집중할 수 있게 된다.

설계 사상의 핵심 ― "AI의 자기 평가가 느슨함"을 전제로 한다

이 부분이 가장 중요하므로 독립해서 적어둔다.

구현 에이전트에게는 "구현 관점의 최적화"만을 시킨다. 리뷰 에이전트에게는 "비판적 시각에서의 결함 찾기"만을 시킨다. 평가자와 피평가자를 물리적으로 분리하기 때문에, 자기 평가의 편향 (Bias)이 걸리지 않는다.

이 트릭은 인간 사회의 리뷰 제도 (코드 리뷰, 논문 심사, 인사 평가의 평가자 분리)와 동일하다. AI에게도 동일한 규율을 적용할 뿐이다.

팀 도입 경로 ― 개인 운용에서 조직 운용으로

L7은 "개인이 로컬에서 사용하는 단계"와 "조직의 워크플로우에 편입시키는 단계"의 2단계가 있다.

• 개인 운용 페이즈 (Phase): 자신의 로컬 환경에서 서브 에이전트를 정의하고, 자신의 작업 흐름에서 돌린다. Claude Code의 .claude/agents/ 하위에 YAML/Markdown으로 에이전트를 작성하는 방식이다. 여기서는 혼자서 시작할 수 있다.
• 팀 공유 페이즈 (Phase): 직접 돌려보며 효과가 있었던 에이전트 정의를 리포지토리 (Repository)에 커밋하여 팀과 공유한다. .claude/agents/code-reviewer.md와 같은 것을 팀 전체 (Team-wide)로 전개한다.
• CI/CD 통합 페이즈 (Phase): PR 생성 시 자동으로 리뷰 에이전트가 실행되고, 커밋 시 하네스 (L6)와 연계하여 테스트, 타입 체크, 린트 (Lint)까지 포함한 검증이 돌아간다. 여기까지 오면 조직으로서 완전히 L7이다.

국내외 AI 선진 기업의 테크 블로그를 보면, 이미 세 번째 페이즈에 도달한 사례가 나오기 시작했다. 엔지니어는 더 상류의 감독 포지션으로 이동하게 된다는 메시지는 여러 곳에서 강력하게 언급되고 있다.

AI로 경쟁에서 이기려면, 레벨 7 정도의 메커니즘 구축을 전사적으로 수행해야 하는 단계에 와 있다고 느낀다.

레벨 8: 자율형 에이전트 팀 ― 아직 이르다는 점만 적어둔다

레벨 8은 **자율형 에이전트 팀 (Autonomous Agent Team)**이다. Claude Code의 Agent Teams 기능을 상상하면 된다. 여러 AI 에이전트가 옆에서 협조하여, 인간의 손을 거의 거치지 않고 하나의 태스크를 완수하는 세계다. 이론적으로는 완성형에 가깝다.

다만, 나도 Agent Teams를 업무 태스크로 한 차례 시도해 봤지만, 현실은 가성비(Cost-performance)가 맞지 않는다는 것이 결론이다. 여러 세션이 협조하기 위한 조정 및 컨텍스트 공유(Context sharing) 비용이 현재의 모델 가격과 균형을 이루지 못하고 있다. 동일한 태스크를 L7의 서브 에이전트(Sub-agent) 방식으로 수행하는 것이 지금은 더 저렴하고 빠르다.

결국 나는 모든 태스크를 L7(서브 에이전트 방식)로 되돌렸다. 자세한 수치나 경위는 별도의 글로 작성할 예정이지만, 결론만 여기에 남겨두겠다 —— L8은 미래 가치는 높지만, 지금 이 순간 모든 태스크를 대체하는 것은 가성비의 함정이다.

향후 모델 가격이 저렴해지거나 Agent Teams 측의 효율이 올라간다면 단번에 현실적인 해답이 될 가능성은 있다. 따라서 PoC(Proof of Concept) 및 기능 평가 차원에서는 계속 만져볼 가치가 있지만, 본업 운영의 주축으로 삼기에는 시기상조라는 것이 2026년 5월 시점에서의 나의 판단이다.

그럼, 다음에 무엇을 해야 할지 입장에 따라 적어보겠다

레벨 감각이 잡혔다면, 다음은 "나는 어디에 투자할 것인가"이다.

개인 엔지니어의 경우

• 우선 레벨 5(MCP + Skills)를 확실히 해낼 수 있는 상태로 만든다.
• 자신이 재사용하고 싶은 절차를 Skill 1개부터 추출해 본다.
• L7의 서브 에이전트 운용을 자신의 로컬에서부터 시작한다 (.claude/agents/에 파일 하나를 작성하는 것만으로도 가능하다).
• L6 이상은 팀 단위로 움직이는 페이즈다. 혼자서 모든 것을 짊어지지 마라.

팀 리더의 경우

• 레벨 5에서 멈추지 마라. 여기서 멈추면 반년 뒤에 리뷰(Review)가 파탄 난다.
• L7의 서브 에이전트 운용을 팀에 전개한다 —— 구현/리뷰/오케스트레이터(Orchestrator)의 3가지 역할을 분담하는 것을 시도한다.
• 하네스(Harness) 정비(L6)에 대한 투자 판단을 리더급 및 경영진으로 격상시킨다.
• "L5의 위험성"을 가시화하여 투자 판단의 재료로 삼는다.
• AI 숙련도에 따른 멤버 간 격차를 평가가 아닌 팔로업(Follow-up) 체계로 흡수하는 설계를 만든다.

조직으로서

• 레벨 7을 전사 목표로 설정한다.
• 레벨 8은 아직 기능 평가 및 PoC 단계에 머무른다.
• 하네스 정비와 서브 에이전트 설계를 엔지니어링의 정식 투자 영역에 포함시킨다.
• "엔지니어는 상류의 감독 포지션으로 이동한다"라는 커리어 시프트(Career shift)를 평가 제도 및 채용 요건에도 반영해 나간다.

그럼, 정리해 보자

8개 레벨을 다시 한번 복습하자.

• L1 탭 완성(Tab completion)
• L2 AI 통합 에디터
• L3-4 에이전트 + 컨텍스트 정비
• L5 MCP + Agent Skills —— 지금 여기가 가장 많고, 가장 위험하다
• L6 하네스 엔지니어링 (Harness Engineering) —— 자동 피드백 루프
• L7 에이전트 오케스트레이터 (Agent Orchestrator) —— 현실적인 해답
• L8 자율형 에이전트 팀 (Autonomous Agent Teams) —— 아직 이르다

마지막으로 가져갔으면 하는 3가지다.

• L7이 현실적인 해답이다 —— 서브 에이전트 + 책임 분할 + AI 간 리뷰, 인간은 상류의 감독 역할을 맡는다.
• L5는 위험하다 —— 아웃풋(Output) 속도만 올라가고, 리뷰어가 침몰한다.
• L8은 시기상조다 —— 미래 가치는 높지만, 본업 운영의 주축으로 삼기에는 아직 이르다.

조직의 AI 성숙도를 높이는 우선순위는, L7의 서브 에이전트 운용을 구축하여 리뷰 파탄을 방지하는 것부터 시작하는 것이 결국 가장 효율적이다. "우리 회사는 AI를 쓰고 있습니다!" 수준에 그치는 것이 아니라, 인간이 감독 포지션으로 이동할 수 있는 메커니즘을 만드는 것에 투자해야 하는 단계에 와 있다는 뜻이다.