AI를 잘 쓰는 교육보다 중요한 것: AI와 함께 일하는 방식을 바꾸는 교육

Read in English: Knowledge Workers in the AI Agent Era: From Content Producers to Judgment Designers

AI가 일상적인 업무 도구가 되면서 교육의 질문도 달라지고 있습니다. 이제 중요한 질문은 “AI를 어떻게 쓸 것인가”가 아닙니다. 이미 많은 사람이 AI를 씁니다. 앞으로의 차이는 AI를 어떤 업무 맥락에 연결하고, 어떤 가치 있는 결과로 바꾸는가에서 만들어집니다.

2026년 6월 4일, 나주에서 진행한 강의의 주제는 “AI Agent 시대 효율적이고 가치 있는 교육 실현”이었습니다.

AI Agent 시대의 교육은 기능을 알려주는 시간이 아니라, 지식근로자가 일하는 방식을 다시 설계하는 과정이어야 합니다.

이 글은 강의 내용을 바탕으로 AI Agent 시대의 교육이 왜 달라져야 하는지, 지식근로자의 역할이 어떻게 바뀌는지, 조직은 어떤 방향으로 학습을 설계해야 하는지 정리합니다.

*기술 변화는 유행에서 끝나지 않고 조직 전략과 일하는 방식의 변화로 이어집니다.*

AI를 쓰는 사람과 쓰지 않는 사람의 경쟁은 이미 지나가고 있다

처음 생성형 AI가 확산되었을 때는 “AI를 쓰는 사람”과 “쓰지 않는 사람”의 차이가 크게 보였습니다. 하지만 지금은 상황이 달라졌습니다. 검색, 요약, 번역, 보고서 초안 작성, 회의 정리, 이미지 생성까지 많은 업무에서 AI 활용은 자연스러운 선택지가 되었습니다.

그래서 경쟁의 기준도 바뀝니다.

• AI를 쓰는가
• 어떤 도구를 쓰는가
• 질문을 얼마나 잘 쓰는가
• 업무 맥락을 얼마나 정확히 제공하는가
• 결과를 얼마나 잘 검토하고 판단하는가
• 조직의 일하는 방식과 어떻게 연결하는가

AI 활용 수준은 단순한 개인 생산성 문제가 아닙니다. 조직이 지식을 만들고 공유하고 실행하는 방식 전체와 연결됩니다.

프롬프트보다 중요한 것은 업무 맥락이다

AI 활용을 이야기하면 먼저 프롬프트가 떠오릅니다. 좋은 질문은 분명히 더 봐야 합니다. 원하는 산출물, 역할, 형식, 조건을 분명히 줄수록 결과가 좋아집니다.

하지만 프롬프트만으로는 충분하지 않습니다.

AI가 좋은 답을 만들려면 다음 정보가 해야 합니다.

• 이 업무의 목적
• 현재 조직의 상황
• 참고해야 할 자료
• 적용해야 할 기준
• 결과물을 사용할 사람
• 판단해야 할 제약 조건
• 최종 산출물의 형태

같은 질문이라도 맥락이 달라지면 답은 달라져야 합니다. 교육과정 설계, 정책자료 검토, 보고서 작성, 성과관리처럼 맥락이 중요한 업무에서는 더욱 그렇습니다.

프롬프트 엔지니어링은 질문을 잘 쓰는 기술입니다. 컨텍스트 엔지니어링은 AI가 일할 수 있도록 필요한 맥락과 자료를 구성하는 방식입니다. Agent 시대에는 여기에 한 단계가 더해집니다. AI가 목표를 이해하고, 필요한 절차를 수행하고, 산출물을 만들 수 있도록 업무 흐름 자체를 설계해야 합니다.

*AI Agent 시대에는 AI가 답변 도구를 넘어 업무 수행의 파트너로 이동합니다.*

지식근로자의 역할은 작성자에서 판단자로 이동한다

지식근로자는 문서를 만들고, 자료를 찾고, 분석하고, 보고하고, 의사결정을 지원하는 사람입니다. AI는 이 과정의 상당 부분을 빠르게 처리합니다.

보고서 초안을 만들 수 있습니다. 긴 문서를 요약할 수 있습니다. 자료를 비교할 수 있습니다. 회의 내용을 정리할 수 있습니다. 아이디어를 구조화할 수 있습니다.

그렇다고 지식근로자의 가치가 사라지는 것은 아닙니다. 오히려 역할이 바뀝니다.

앞으로 더 중요해지는 역할은 이렇게 볼 수 있습니다.

1. 문제를 정의하는 역할

무엇을 해결해야 하는지 분명히 잡아야 합니다.

1. 맥락을 제공하는 역할

AI가 참고할 자료와 기준을 정리해야 합니다.

1. 결과를 검토하는 역할

그럴듯한 답과 실제로 맞는 답을 구분해야 합니다.

1. 판단하고 선택하는 역할

조직의 목적, 사람의 상황, 책임의 범위를 고려해 최종 결정을 내려야 합니다.

1. 업무 흐름을 개선하는 역할

반복되는 일을 AI에 맡기고, 사람은 더 높은 수준의 문제해결에 집중해야 합니다.

AI가 일을 대신하는 만큼, 사람은 더 깊이 이해하고 더 정확히 판단해야 합니다.

지식을 소비하는 조직에서 지식을 만드는 조직으로

AI 시대의 조직은 그냥 외부 지식을 빠르게 가져오는 데서 멈추면 안 됩니다. 조직 내부의 경험, 기준, 사례, 판단 과정을 축적해야 합니다.

교육 조직도 마찬가지입니다. 교육과정을 운영하는 일은 일정 관리나 강사 섭외만으로 끝나지 않습니다. 교육이 실제 업무 성과와 연결되려면 조직 안에 지식이 남아야 합니다.

예를 들어 다음과 같은 자료가 쌓여야 합니다.

• 교육과정 설계 기준
• 과정별 학습 목표
• 실제 현장에서 반복되는 문제
• 교육생의 질문과 어려움
• 강의 후 적용 사례
• 성과를 확인할 수 있는 지표
• 다음 교육에 반영할 개선점

AI는 이런 자료를 정리하고 연결하는 데 강합니다. 하지만 어떤 자료가 중요하고, 어떤 기준으로 해석해야 하며, 어떤 방향으로 개선해야 하는지는 사람이 결정해야 합니다.

*AI는 자료 정리와 구조화를 돕지만, 가치 있는 지식은 조직의 판단과 경험에서 만들어집니다.*

교육은 기능 전달이 아니라 문제해결 역량을 키우는 과정이 된다

AI 교육을 도구 사용법 중심으로만 구성하면 금방 한계가 옵니다. 버튼 위치와 기능은 계속 바뀝니다. 모델도 바뀌고 요금제도 바뀌고 플랫폼의 강점도 달라집니다.

그래서 AI 교육의 중심은 기능 설명보다 문제해결에 가까워져야 합니다.

교육에서 다뤄야 할 질문은 이런 것들입니다.

• 내 업무에서 AI가 맡을 수 있는 일은 무엇인가
• 사람이 반드시 판단해야 하는 일은 무엇인가
• 어떤 자료를 AI에게 제공해야 결과가 좋아지는가
• AI 결과를 검증하는 기준은 무엇인가
• 반복되는 업무를 어떤 흐름으로 자동화할 수 있는가
• 조직 차원에서 어떤 지식 DB를 만들어야 하는가

이런 질문을 다루면 교육은 단순한 “AI 활용법”을 넘어섭니다. 학습자는 자신의 업무를 다시 바라보게 됩니다. 조직은 교육을 통해 일하는 방식의 변화를 시작할 수 있습니다.

AI가 대신할 일과 사람이 남겨야 할 가치를 구분해야 한다

AI는 빠릅니다. 많은 자료를 읽고, 초안을 만들고, 비교하고, 요약하는 데 강합니다.

하지만 AI가 빠르게 만든 결과가 항상 가치 있는 결과는 아닙니다. 가치는 사람의 문제의식, 목적, 해석, 선택에서 나옵니다.

AI가 잘하는 일은 AI에게 맡길 수 있습니다.

• 초안 작성
• 자료 요약
• 표 정리
• 반복 조사
• 문장 다듬기
• 아이디어 확장
• 형식 변환

사람이 집중해야 할 일은 다릅니다.

• 왜 이 일을 하는지 정하기
• 누구에게 필요한 결과인지 판단하기
• 현장 맥락을 반영하기
• 위험과 책임을 검토하기
• 최종 방향을 선택하기
• 사람에게 의미 있는 경험으로 바꾸기

AI Agent 시대의 교육은 이 경계를 분명히 도와야 합니다. 그래야 AI가 사람을 대체하는 도구가 아니라, 사람이 더 가치 있는 일을 하도록 돕는 도구가 됩니다.

*AI는 실행을 도울 수 있지만, 가치는 문제를 해석하고 판단하는 사람에게서 나옵니다.*

조직 변화 없이 AI 교육만 늘리면 효과가 제한된다

AI 교육을 많이 해도 조직의 업무 방식이 그대로라면 효과는 작아집니다. 개인이 배운 내용을 실제 업무에서 쓰기 어렵기 때문입니다.

AI 활용은 개인의 기술만으로 완성되지 않습니다. 업무, 구성원, 문화, 구조, 전략이 함께 움직여야 합니다.

조직이 함께 점검해야 할 질문은 이렇게 볼 수 있습니다.

• 어떤 업무를 AI와 함께 다시 설계할 것인가
• 어떤 자료를 조직의 공통 지식으로 관리할 것인가
• AI 사용에 필요한 권한과 보안 기준은 무엇인가
• 결과 검토 책임은 누가 가질 것인가
• 교육 성과를 현업 적용과 어떻게 연결할 것인가
• 개인 실험을 조직 프로세스로 어떻게 확장할 것인가

AI가 팀원이 되는 시대에는 조직도 팀처럼 움직여야 합니다. 한 사람의 생산성 향상에서 끝나지 않고, 조직의 학습 구조와 업무 구조가 함께 바뀌어야 합니다.

*AI 활용은 개인 역량의 문제가 아니라 조직 설계의 문제와 연결됩니다.*

효율적인 교육과 가치 있는 교육은 함께 가야 한다

AI는 교육의 효율을 높일 수 있습니다. 자료 조사 시간이 줄어들고, 교육과정 초안을 빠르게 만들 수 있으며, 학습자료도 다양하게 변환할 수 있습니다.

하지만 효율만으로는 충분하지 않습니다. 교육의 목적은 시간을 줄이는 데 있지 않습니다. 더 나은 판단, 더 깊은 이해, 더 실제적인 문제해결을 가능하게 만드는 데 있습니다.

효율적인 교육은 빠르게 운영되는 교육입니다. 가치 있는 교육은 학습자가 실제 업무에서 다르게 행동하도록 돕는 교육입니다.

AI Agent 시대에는 이 둘을 함께 설계해야 합니다.

• AI로 반복 업무를 줄인다.
• 자료를 체계적으로 모은다.
• 학습자의 업무 맥락을 반영한다.
• 문제해결형 과제를 설계한다.
• 결과를 현업 적용과 연결한다.
• 교육 후 남는 지식을 조직 자산으로 축적한다.

이렇게 접근하면 AI 교육은 도구 교육을 넘어 조직 변화의 출발점이 됩니다.

마무리: AI 시대의 교육담당자는 일하는 방식을 설계하는 사람이다

AI Agent 시대에는 교육담당자의 역할도 넓어집니다. 교육을 운영하는 사람에서, 조직의 일하는 방식을 새롭게 설계하는 사람으로 이동합니다.

앞으로의 교육은 질문을 바꿔야 합니다.

“어떤 AI 도구를 알려줄 것인가?”에서 멈추지 말아야 합니다. “이 조직은 AI와 함께 어떤 방식으로 더 좋은 결과를 만들 것인가?”까지 가야 합니다.

AI는 일을 빠르게 처리합니다. 사람은 의미를 만들고 판단합니다. 교육은 그 둘을 연결합니다.

AI Agent 시대의 효율적이고 가치 있는 교육은 바로 그 연결을 설계하는 일에서 시작됩니다.

---

함께 읽으면 좋은 글

• AI 에이전트를 학습시키는 법: Hermes Agent로 AI 네이티브 조직 만들기
• AI를 쓸수록 똑똑해지는 사람의 6가지 습관
• AI 네이티브 전환법: 디지털 두뇌와 AI 에이전트로 일하는 방식 바꾸기

---

FAQ

AI Agent 시대 교육은 기존 AI 활용 교육과 무엇이 다른가요?

기존 AI 활용 교육은 주로 도구 사용법과 프롬프트 작성에 집중합니다. AI Agent 시대 교육은 업무 목표, 자료, 권한, 검증, 조직 프로세스까지 함께 다룹니다.

지식근로자는 AI 때문에 역할이 줄어드나요?

반복적인 작성과 정리 업무는 줄어들 수 있습니다. 대신 문제 정의, 맥락 제공, 결과 검토, 책임 있는 판단의 중요성은 더 커집니다.

교육 조직은 AI를 어디부터 적용하면 좋을까요?

교육과정 기획, 자료 정리, 강의안 초안 작성, 교육생 질문 분석, 성과 피드백 정리처럼 반복되지만 판단이 필요한 업무부터 시작하는 것이 좋습니다.

프롬프트를 잘 쓰는 것만으로 충분한가요?

충분하지 않습니다. 좋은 프롬프트는 출발점입니다. 실제 업무에서는 신뢰할 수 있는 자료, 조직 맥락, 검증 기준, 결과 활용 방식이 함께 해야 합니다.

AI 교육의 최종 목표는 무엇이어야 하나요?

그냥 AI 사용법을 익히는 것이 아니라, 학습자가 자신의 업무를 더 잘 이해하고 AI와 함께 더 가치 있는 결과를 만들 수 있도록 돕는 것입니다.

---

마이크로소프트의 사티아 나델라를 볼 때, 흔히 떠올리는 키워드는 클라우드와 OpenAI입니다. 하지만 지금 더 눈여겨볼 변화는 PC 쪽에서 일어나고 있습니다. 마이크로소프트는 AI를 거대한 서버에서만 돌리는 서비스가 아니라, 사용자의 노트북과 앱 안에서 즉시 실행되는 기본 기능으로 만들려 합니다.

Read in English: Satya Nadella’s Next Bet: How Microsoft Is Rebuilding the On-Device AI Ecosystem

이 관점에서 Copilot+ PC, NPU, Windows AI Foundry, Foundry Local, Phi 계열 소형 모델은 서로 따로 움직이는 제품이 아닙니다. 나델라식 플랫폼 전략이 클라우드에서 PC로 내려오는 흐름입니다. 핵심 질문은 하나입니다. 마이크로소프트는 온디바이스 AI 생태계를 어떻게 바꾸려 하는가입니다.

사티아 나델라를 이해하는 먼저 볼 부분은 제품보다 플랫폼이다

나델라는 2014년 마이크로소프트 CEO가 된 뒤 회사를 Windows 패키지 중심 기업에서 Azure, Microsoft 365, GitHub, Teams, Copilot을 잇는 플랫폼 기업으로 바꿨습니다. Microsoft 2024 Annual Report의 주주 서한에서도 그는 AI를 새로운 플랫폼 전환으로 설명합니다. 이는 그냥 챗봇 하나를 더 붙이는 문제가 아닙니다.

나델라의 방식은 반복적입니다. 먼저 개발자와 기업이 모이는 기반을 만들고, 그 위에 도구와 배포 경로를 얹습니다. Azure가 클라우드 개발의 기반이었다면, 온디바이스 AI 시대의 기반은 Windows PC, NPU, 로컬 모델 런타임, 앱 생태계가 됩니다.

그래서 마이크로소프트의 온디바이스 AI 전략은 “PC에도 AI 기능을 넣는다” 정도로 보면 부족합니다. 더 정확히는 Windows를 AI 앱의 실행 환경으로 다시 정의하려는 시도입니다.

Copilot+ PC는 AI 기능이 아니라 새 기준선을 만든다

Copilot+ PC에서 중요한 단어는 Copilot보다 NPU입니다. Microsoft Learn의 Copilot+ PC 개발자 가이드는 Copilot+ PC를 고성능 NPU를 갖춘 새로운 Windows 11 하드웨어로 설명합니다. 이 NPU는 실시간 번역, 이미지 생성 같은 AI 작업을 위해 설계된 칩이며, 40 TOPS 이상의 성능을 기준으로 보입니다.

이 기준은 PC 시장에 중요한 메시지를 줍니다. 앞으로 좋은 노트북은 CPU와 GPU만 빠른 기계가 아니라, AI 작업을 배터리 소모와 지연을 줄이면서 처리할 수 있는 기계여야 한다는 뜻입니다.

마이크로소프트 입장에서는 더 큰 효과가 있습니다. Windows 앱 개발자가 “사용자 기기에 AI 가속기가 있다”고 가정할 수 있는 순간, 로컬 요약, 이미지 보정, 문서 검색, 개인화 추천, 실시간 보조 기능이 앱 기본 기능으로 내려옵니다.

Windows AI Foundry는 개발자 생태계를 묶는 장치다

온디바이스 AI가 확산되려면 하드웨어만으로는 부족합니다. 개발자가 모델을 가져오고, 압축하고, 실행하고, 여러 장치에서 성능을 맞출 수 있어야 합니다. 여기서 Windows AI Foundry와 Foundry Local이 등장합니다.

Microsoft Learn은 Windows의 로컬 AI 개발 흐름에서 DirectML, ONNX Runtime, Windows ML, Foundry Local을 함께 설명합니다. 특히 DirectML과 ONNX Runtime은 GPU나 NPU를 활용해 모델 성능을 끌어올리는 경로입니다. Foundry Local은 기기 안에서 AI 애플리케이션과 에이전트를 설계하고 관리하는 문서 체계로 제시됩니다.

이 조합은 마이크로소프트가 원하는 생태계를 보입니다. 개발자는 클라우드 모델만 호출하는 앱이 아니라, 로컬 모델과 클라우드 모델을 섞어 쓰는 앱을 만들게 됩니다. 사용자는 더 빠른 응답과 개인정보 보호 이점을 얻습니다. 마이크로소프트는 Windows를 다시 개발자 플랫폼의 중심에 놓습니다.

Phi 소형 모델은 클라우드 독점 구조를 흔든다

온디바이스 AI에서 소형 언어 모델은 결정적입니다. 거대한 모델을 모두 노트북에서 돌릴 수는 없습니다. 대신 특정 작업을 잘 수행하는 작은 모델이 해야 합니다. Microsoft의 Phi-3 발표는 이 방향을 잘 보입니다.

Phi-3는 소형 언어 모델의 품질과 비용 효율을 강조합니다. Microsoft는 Phi-3가 Azure AI뿐 아니라 Ollama로 로컬 노트북에서도 실행될 수 있고, ONNX Runtime과 Windows DirectML 지원을 통해 GPU, CPU, 모바일 하드웨어까지 폭넓게 활용할 수 있다고 설명합니다.

이 전략은 클라우드 AI를 버리자는 뜻이 아닙니다. 오히려 작업을 나누자는 뜻에 가깝습니다. 민감하거나 반복적인 작업은 로컬에서 처리합니다. 복잡한 추론이나 대규모 지식 검색은 클라우드 모델을 씁니다. 이렇게 되면 AI 비용, 지연 시간, 개인정보, 배터리 사용량을 동시에 조정할 수 있습니다.

Recall 논쟁은 온디바이스 AI의 신뢰 문제를 드러냈다

마이크로소프트의 방향이 항상 순조로운 것은 아닙니다. Recall은 좋은 사례입니다. Recall은 사용자의 화면 활동을 기기에서 분석해 과거 작업을 찾게 해주는 Copilot+ PC 기능입니다. 하지만 화면 스냅샷과 민감 정보 처리 문제로 큰 개인정보 논쟁을 불러왔습니다.

Microsoft Learn의 Recall 문서는 Copilot+ PC, Windows 업데이트, 정책 설정, 사용자 동의와 제어를 전제로 설명합니다. 이 논점은 온디바이스 AI의 본질을 보입니다. 데이터를 클라우드로 보내지 않는다고 해서 자동으로 신뢰가 생기지는 않습니다. 사용자가 무엇이 저장되는지 알고, 끄고, 삭제하고, 통제할 수 있어야 합니다.

그래서 온디바이스 AI 생태계의 승부는 성능만으로 결정되지 않습니다. 로컬 처리, 암호화, 접근 권한, 투명한 UI, 기업 정책 제어가 함께 설계되어야 합니다. 나델라의 마이크로소프트가 이 문제를 풀지 못하면, AI PC는 편리한 플랫폼이 아니라 감시 논란의 플랫폼이 될 수 있습니다.

마이크로소프트가 바꾸려는 생태계의 구조

마이크로소프트의 전략은 네 개 층으로 볼 수 있습니다.

이 표에서 가장 중요한 변화는 마지막 줄입니다. AI가 브라우저에서 접속하는 서비스로만 남지 않고, 운영체제와 앱의 기본 경험으로 들어갑니다. 사용자는 별도의 챗봇 창을 열지 않아도 문서, 사진, 회의, 검색, 코딩 도구 안에서 AI를 쓰게 됩니다.

애플·구글과 다른 마이크로소프트의 강점

애플은 기기와 운영체제를 강하게 통합합니다. 구글은 Android와 검색, Gemini 생태계를 갖고 있습니다. 마이크로소프트의 강점은 기업 업무 환경과 개발자 생태계입니다. Windows, Microsoft 365, Azure, GitHub, Visual Studio, Teams가 이미 업무 흐름 속에 들어가 있습니다.

그래서 마이크로소프트가 온디바이스 AI에서 노리는 시장은 단순한 개인 비서가 아닙니다. 기업 문서, 보안 정책, 회의, 개발, 고객 응대, 현장 업무까지 이어지는 생산성 플랫폼입니다. 이 지점에서 나델라의 전략은 명확합니다. 클라우드 AI와 PC AI를 경쟁시키는 것이 아니라, 하나의 Microsoft 생태계 안에서 연결하려 합니다.

사용자는 무엇을 준비해야 할까

온디바이스 AI 생태계가 본격화되면 사용자와 기업은 PC를 고르는 기준부터 바꿔야 합니다. CPU, RAM, 저장장치만 볼 것이 아니라 NPU 성능, 로컬 모델 지원, 메모리 용량, 보안 정책, 배터리 효율을 함께 봐야 합니다.

기업은 더 신중해야 합니다. 로컬 AI는 개인정보 보호에 유리할 수 있지만, 화면 캡처, 파일 접근, 앱 권한, 로그 저장 방식이 불투명하면 오히려 위험해질 수 있습니다. AI PC 도입은 장비 교체 사업이 아니라 데이터 거버넌스와 업무 설계의 문제입니다.

개인 사용자에게는 새로운 기회도 있습니다. 로컬 LLM과 소형 모델이 좋아질수록 인터넷 연결 없이도 글쓰기, 요약, 검색, 코딩 보조, 지식 관리가 가능해집니다. 이미 로컬 LLM 실사용과 AI 에이전트 학습법은 별도 글에서도 다룬 바 있습니다.

함께 읽으면 좋은 글

• M5 Pro Max 128GB 로컬 LLM 실사용
• AI 에이전트를 학습시키는 법
• 소형 언어 모델과 오픈소스 AI
• AI 취업 공포가 던진 질문
• AI 시대 인간의 가치

결론: 나델라의 목표는 AI PC가 아니라 Windows의 재플랫폼화다

사티아 나델라가 온디바이스 AI에서 노리는 것은 그냥 Copilot 버튼이 달린 PC를 많이 파는 일이 아닙니다. 더 큰 목표는 Windows를 AI 앱과 에이전트가 실행되는 기본 플랫폼으로 다시 세우는 것입니다.

이 변화가 성공하면 PC는 다시 중요한 AI 플랫폼이 됩니다. 클라우드 모델은 더 강력한 두뇌가 되고, 로컬 모델은 빠르고 개인적인 손발이 됩니다. 실패하면 AI PC는 마케팅 용어로 끝날 수 있습니다. 관전 포인트는 명확합니다. 마이크로소프트가 성능, 개발자 도구, 개인정보 신뢰를 동시에 설계할 수 있는가입니다.

FAQ

사티아 나델라는 왜 온디바이스 AI에 집중할까?

AI가 클라우드 서비스에만 머물면 Windows와 PC의 전략적 가치가 약해집니다. 반대로 AI가 PC와 앱 안에서 실행되면 Windows는 다시 핵심 플랫폼이 됩니다.

Copilot+ PC의 먼저 볼 부분은 무엇인가?

먼저 볼 부분은 NPU입니다. 40 TOPS 이상급 AI 가속 성능을 기준으로 로컬 AI 기능을 더 빠르고 전력 효율적으로 실행하려는 하드웨어 기준입니다.

Windows AI Foundry와 Foundry Local은 왜 중요한가?

개발자가 로컬 모델을 앱에 넣고, ONNX Runtime·DirectML·Windows ML 같은 실행 경로를 활용하게 해줍니다. 즉 온디바이스 AI 앱 생태계를 만드는 개발자 도구입니다.

온디바이스 AI는 클라우드 AI를 대체하나?

아닙니다. 민감하고 반복적인 작업은 로컬에서 처리하고, 복잡한 추론과 대규모 지식 처리는 클라우드가 맡는 하이브리드 구조가 유력합니다.

Recall 논쟁이 주는 교훈은 무엇인가?

로컬 처리만으로 신뢰가 생기지는 않는다는 점입니다. 사용자의 명확한 동의, 저장 범위 제어, 삭제 권한, 기업 정책 관리가 함께 있어야 합니다.

참고자료

• Microsoft, Annual Report 2024
• Microsoft Learn, Copilot+ PCs developer guide
• Microsoft Learn, Use local AI with Microsoft Foundry on Windows
• Microsoft Learn, Foundry Local architecture overview
• Microsoft Learn, Foundry Local documentation
• Microsoft Azure Blog, Introducing Phi-3
• Microsoft Learn, Recall overview
• Wikipedia, Satya Nadella

AI 에이전트를 잘 쓰는 조직은 그냥 좋은 모델을 고르는 데서 끝나지 않습니다. 더 중요한 질문은 “에이전트가 무엇을 배워야 하고, 어디에 기억해야 하며, 어떤 기준으로 일해야 하는가”입니다.

김효율의 AI 개발단 영상은 이 질문을 Hermes Agent 운영 사례로 보입니다. 개발, 디자인, 콘텐츠, 강의 보조 역할을 나눈 여러 에이전트를 만들고, Telegram으로 원격 지시하. Obsidian Wiki로 맥락을 공유하는 방식입니다.

Read in English: This article is also available in English for global readers.

영상의 먼저 볼 부분은 설치법이 아니라 운영법이다

영상 제목은 AI 에이전트를 “학습시키는 방법”을 강조합니다. 실제 내용도 설치 명령어보다 운영 구조에 가깝습니다. Hermes Agent를 Telegram에 연결하고, Codex나 Claude Code 같은 도구와 조합해 여러 에이전트를 역할별로 나누는 흐름이 중심입니다.

Hermes Agent 공식 설명에서도 Hermes는 터미널, 메시징 플랫폼, IDE에서 실행되는 오픈소스 AI 에이전트 프레임워크입니다. 또한 스킬, 메모리, 프로필, 게이트웨이, 크론, MCP, 여러 모델 제공자 연결을 지원합니다. 영상의 사례는 이 기능들을 개인 업무 시스템으로 엮은 예시로 볼 수 있습니다.

여기서 중요한 점은 “AI 직원을 많이 만든다”가 아닙니다. 각 에이전트가 맡을 역할, 참고할 지식, 반복할 학습 루프, 보고 방식이 있어야 합니다. 그렇지 않으면 대화창만 늘어나고 실제 생산성은 올라가지 않습니다.

AI 에이전트를 직원처럼 나누는 이유

영상에서는 개발, UI 디자인, 테스트, 콘텐츠, 강의 보조 같은 역할을 가진 에이전트들이 소개됩니다. 이는 사람 조직의 직무 분장과 비슷합니다. 한 에이전트에게 모든 일을 맡기면 맥락이 섞이고, 지시도 길어지며, 결과 검증이 어려워집니다.

역할을 나누면 세 가지 장점이 생깁니다.

1. 지시가 짧아집니다. 개발 에이전트에게는 코드와 테스트를, 디자인 에이전트에게는 레이아웃과 레퍼런스를 중심으로 말하면 됩니다.
2. 기준이 선명해집니다. 각 에이전트의 규칙 파일이나 스킬 문서에 해야 할 일과 하지 말아야 할 일을 분리해 둘 수 있습니다.
3. 검증이 쉬워집니다. 만든 사람과 검토하는 사람, 즉 생성 에이전트와 리뷰 에이전트를 나눌 수 있습니다.

이 방식은 AI 도구를 하나로 묶는 Agent OS 구축법과도 연결됩니다. AI 활용의 본질은 개별 챗봇 사용이 아니라, 작업 흐름과 지식 흐름을 설계하는 데 있습니다.

실제 산출물이 나오려면 감독자의 역할이 필요하다

영상에서 흥미로운 부분은 “에이전트 다섯 명이 사이트를 만들었다”는 사례입니다. 쇼츠 영상을 수집하고 보여주는 사이트를 여러 역할의 에이전트가 협업해 만들었다고 설명합니다.

한 가지 조심할 점은 이 장면에서 놓치면 안 되는 부분이 있습니다. 영상 속 화자도 자신이 손을 놓고 있던 것은 아니라고 말합니다. 사람은 기획을 주고, 방향을 감독하고, 결과를 확인합니다.

그래서 AI 에이전트 도입의 현실적인 구조는 다음에 가깝습니다.

• 사람: 목표, 우선순위, 기준, 최종 판단을 맡는다.
• 에이전트: 조사, 초안, 코드 작성, 반복 수정, 정리 작업을 맡는다.
• 시스템: 기억, 파일, 버전, 일정, 알림, 검증 루프를 맡는다.

이 균형이 없으면 AI 에이전트는 빠르게 많은 결과물을 만들지만, 그 결과가 조직의 기준과 맞는지는 알기 어렵습니다. 그래서 하네스 엔지니어링이 온다에서 말한 것처럼, 에이전트를 “잘 움직이게 묶는 기술”이 점점 더 봐야 합니다.

학습 루프의 먼저 볼 부분은 메모리를 무작정 늘리는 것이 아니다

영상의 가장 중요한 메시지는 Obsidian Wiki를 활용한 맥락 공유입니다. 매일 밤 리서치와 학습을 시키더라도 모든 내용을 에이전트 메모리에 밀어 넣으면 오히려 성능이 나빠질 수 있다는 문제의식이 나옵니다.

좋은 방식은 장기 기억과 작업 기억을 나누는 것입니다. 에이전트가 모든 내용을 항상 들고 있는 것이 아니라, 필요할 때 위키에서 관련 정보를 찾아오게 만드는 구조입니다.

실무적으로는 다음 구조가 안전합니다.

이 관점은 세컨드 브레인과 LLM Wiki의 주제와도 맞닿아 있습니다. AI 시대의 지식 시스템은 사람이 보기 위한 노트인 동시에, 에이전트가 검색하고 참조할 수 있는 운영 인프라가 됩니다.

Telegram 원격 실행은 ‘언제든 일시키기’가 아니라 운영 채널이다

영상에서는 Hermes Agent를 Telegram에 연결해 사용한다고 설명합니다. Slack을 쓸 수도 있지만, 1인 기업이라 가벼운 Telegram을 선택했다는 맥락입니다.

이 부분은 단순 편의 기능 이상입니다. 메시징 플랫폼은 AI 에이전트의 업무 접수 창구가 됩니다. 이동 중에도 일을 맡기고, 완료 알림을 받고, 파일이나 결과물을 전달받을 수 있습니다.

한 가지 조심할 점은 원격 실행은 강력한 만큼 운영 원칙이 해야 합니다.

• 위험한 명령은 승인 절차를 둡니다.
• 에이전트별 권한과 작업 범위를 나눕니다.
• 민감한 파일과 인증정보는 작업 지시에서 제외합니다.
• 자동 실행 작업은 로그와 결과 검토를 남깁니다.
• 실패했을 때 되돌릴 수 있는 체크포인트를 둡니다.

Hermes Agent의 게이트웨이, 프로필, 크론 기능은 이런 운영 체계를 만들 때 유용합니다. 하지만 도구가 있다고 해서 곧바로 안전한 자동화가 되는 것은 아닙니다.

AI 네이티브 조직은 대시보드보다 운영 규칙이 먼저다

영상 후반부에는 AI 네이티브 조직을 위한 운영 대시보드 구상이 나옵니다. 업무 현황, 일정, 메신저, 에이전트 상태, 예약 작업, 스킬과 플러그인, 토큰 사용량을 한눈에 보는 구조입니다.

이 구상은 매우 실용적입니다. 한 가지 조심할 점은 대시보드보다 먼저 정해야 할 것이 있습니다. 무엇을 자동화할지, 어떤 기준으로 성공을 판단할지, 어떤 지점에서 사람이 개입할지입니다.

AI 에이전트 운영을 시작하려는 팀이라면 다음 순서가 좋습니다.

1. 반복되는 업무 3개를 고릅니다.
2. 각 업무의 입력, 출력, 검증 기준을 문서화합니다.
3. 한 명의 에이전트에게 하나의 역할만 맡깁니다.
4. 결과물을 사람이 검토하고 규칙을 보강합니다.
5. 안정화된 뒤 크론잡이나 메시징 채널로 자동화합니다.

처음부터 “AI 직원 10명”을 만드는 것보다, 한 명의 에이전트가 한 가지 일을 꾸준히 잘하게 만드는 편이 더 빠릅니다.

도입 전 체크리스트

Hermes Agent나 유사한 AI 에이전트 시스템을 도입하기 전에는 아래 질문을 먼저 체크해 두세요.

• 이 에이전트가 맡을 반복 업무가 분명한가?
• 결과물을 검토할 사람이나 리뷰 에이전트가 있는가?
• 장기 지식을 저장할 위키나 문서 저장소가 있는가?
• 비밀정보와 권한을 어디까지 허용할지 정했는가?
• 실패했을 때 되돌릴 수 있는 로그와 백업이 있는가?
• 비용, 토큰 사용량, 실행 시간을 추적할 수 있는가?

이 질문에 답하지 못한 상태에서 에이전트 수만 늘리면, 자동화가 아니라 혼선이 늘어날 가능성이 높습니다.

함께 읽으면 좋은 글

• Hermes Agent Deliverable Mode: AI 산출물을 채팅에서 바로 받는 방법
• AI 네이티브 전환법: 디지털 두뇌와 AI 에이전트로 일하는 방식 바꾸기
• 세컨드 브레인과 LLM Wiki: AI 에이전트 시대의 개인 지식 시스템
• AI 도구를 하나로 묶는 Agent OS 구축법: 7단계 블루프린트
• 하네스 엔지니어링이 온다: AI 에이전트를 제대로 일하게 만드는 법

결론: AI 에이전트는 학습보다 운영 설계가 먼저다

이 영상이 던지는 핵심 질문은 “AI 에이전트를 얼마나 많이 만들 수 있는가”가 아닙니다. “에이전트가 조직의 지식과 기준을 어떻게 배우고, 어떻게 협업하며, 어떻게 검증받는가”입니다.

Hermes Agent는 이 실험에 좋은 운영 기반을 제공합니다. 메시징 플랫폼에서 실행하고, 프로필을 나누고, 스킬과 메모리를 쌓고, 크론잡으로 반복 작업을 돌릴 수 있기 때문입니다.

하지만 최종 성과는 도구보다 설계에서 갈립니다. 역할을 작게 나누고, 지식 저장소를 만들고, 검증 루프를 붙이고, 사람의 판단 지점을 남겨야 합니다. 그때 AI 에이전트는 단순 자동응답기가 아니라, 함께 일하는 운영 시스템에 가까워집니다.

FAQ

Hermes Agent를 설치하면 바로 AI 직원처럼 쓸 수 있나요?

아닙니다. 설치는 시작일 뿐입니다. 역할, 규칙, 참고 지식, 검증 기준을 정해야 실제 업무에 쓸 수 있습니다.

AI 에이전트 학습은 모델을 파인튜닝한다는 뜻인가요?

이 글에서 말하는 학습은 파인튜닝보다 운영 학습에 가깝습니다. 규칙 문서, 스킬, 위키, 작업 로그를 통해 에이전트가 반복 업무의 맥락을 더 잘 참조하게 만드는 방식입니다.

Obsidian Wiki가 꼭 필요할까요?

꼭 Obsidian일 필요는 없습니다. 한 가지 조심할 점은 에이전트가 검색하고 참조할 수 있는 장기 지식 저장소는 해야 합니다. Notion, Markdown Wiki, Git 저장소, LLM Wiki 등으로 대체할 수 있습니다.

Telegram 연결은 안전한가요?

연결 자체보다 권한 설계가 더 봐야 합니다. 위험한 명령 승인, 민감정보 분리, 로그 확인, 권한 제한을 함께 설계해야 합니다.

처음 도입할 때 몇 개의 에이전트부터 시작하는 것이 좋을까요?

처음에는 한두 개가 적절합니다. 반복 업무 하나와 검증 업무 하나로 시작한 뒤, 안정화된 역할만 늘리는 편이 좋습니다.

참고자료

• 김효율의 AI 개발단, 99.9%가 모르는 AI 에이전트를 학습시키는 천재적 방법
• Hermes Agent 공식 문서
• NousResearch Hermes Agent GitHub 저장소

AI 에이전트를 쓰기 시작하면 가장 먼저 놀라는 것이 답변 품질이 아닐 수 있습니다. 더 현실적인 충격은 사용량과 비용입니다. 코딩 에이전트가 로그, 파일, 검색 결과, 대화 기록을 계속 읽으면 토큰은 빠르게 불어납니다.

Read in English: AI Token Diet: What Headroom Teaches About Cutting LLM Agent Costs

최근 The Register는 넷플릭스 시니어 엔지니어 Tejas Chopra가 만든 오픈소스 프로젝트 Headroom을 소개했습니다. 기사에 따르면 이 프로젝트는 Netflix의 공식 프로젝트는 아니지만, 여러 팀과 외부 프로젝트에서 사용되고 있습니다. 먼저 볼 부분은 간단합니다. LLM에 보내기 전에 불필요한 컨텍스트를 줄여 “토큰 다이어트”를 하자는 것입니다.

Headroom은 무엇인가

Headroom은 AI 에이전트가 LLM에 보내는 입력을 압축하는 컨텍스트 압축 계층입니다. GitHub 저장소 설명에 따르면 tool output, 로그, 파일, RAG chunk를 LLM에 도달하기 전에 줄이는 도구입니다.

Headroom은 하나의 프롬프트 압축 팁이 아닙니다. 라이브러리, 프록시, MCP 서버, 에이전트 wrapper 형태로 쓸 수 있는 개발자 도구에 가깝습니다. Claude Code, Codex, Cursor, Aider 같은 코딩 에이전트 앞단에 붙여 토큰 낭비를 줄이는 방식입니다.

중요한 점은 “모든 글자를 무조건 압축한다”가 아닙니다. Headroom은 입력의 종류를 보고 다른 압축 방식을 적용합니다. JSON은 JSON에 맞게, 코드는 코드 구조에 맞게, 일반 텍스트는 텍스트에 맞게 줄이는 식입니다.

왜 AI 에이전트 시대에 토큰 비용이 커지는가

챗봇을 쓸 때는 사용자가 질문을 입력하고 답을 받습니다. 하지만 AI 에이전트는 다릅니다. 에이전트는 파일을 읽고, 검색하고, 로그를 확인하고, 도구를 호출하고, 그 결과를 다시 LLM에 넣습니다.

문제는 이 과정에서 중복이 많이 생긴다는 점입니다. 같은 에러 로그가 여러 번 들어가고, 필요 없는 파일 내용이 함께 들어가며, RAG 검색 결과가 너무 넓게 붙습니다. 사람에게는 잡음처럼 보이는 정보도 토큰으로는 모두 비용이 됩니다.

The Register 기사에 따르면 Chopra는 Claude Sonnet 사용 중 $287 청구서를 보고 토큰 절감 문제에 관심을 갖게 됐습니다. 이후 많은 입력이 실제 추론에 꼭 필요한 정보가 아니라 반복·보일러플레이트·중복 데이터라는 점을 확인했다고 설명했습니다.

Headroom의 핵심 구조

Headroom README는 구조를 CacheAligner, ContentRouter, CCR, SmartCrusher, CodeCompressor, Kompress-base 같은 구성으로 설명합니다. 이름은 복잡하지만 흐름은 실무적으로 이해할 수 있습니다.

첫째, ContentRouter는 입력의 종류를 구분합니다. 코드, JSON, 로그, 일반 텍스트를 같은 방식으로 줄이면 오류가 납니다. 그래서 먼저 내용의 성격을 판단합니다.

둘째, CodeCompressor와 SmartCrusher는 코드와 JSON처럼 구조가 중요한 데이터를 조심스럽게 줄입니다. 코드에서 식별자나 문법을 망가뜨리면 절감보다 손실이 커집니다.

셋째, CCR은 원본을 로컬에 보관하고 필요할 때 다시 가져오게 하는 방식입니다. 압축본만 보내되, 모델이 원문이 필요하다고 판단하면 retrieval 도구로 원본을 조회할 수 있게 합니다.

넷째, CacheAligner는 provider의 캐시가 깨지지 않도록 입력 prefix를 안정화하는 역할을 합니다. 단순 압축은 캐시 적중률을 낮춰 오히려 비용을 늘릴 수 있습니다. 이 지점이 Headroom이 단순 프롬프트 요약 도구와 다른 부분입니다.

숫자는 어떻게 봐야 할까

Headroom README는 실제 agent workload에서 60~95% fewer tokens를 내세웁니다. 예시로 code search, SRE incident debugging, GitHub issue triage, codebase exploration 같은 작업에서 큰 절감률을 보입니다.

주의할 점은 이 숫자는 그대로 모든 조직에 적용되는 보장값으로 보면 안 됩니다. 어떤 작업은 로그와 검색 결과가 많아 절감 여지가 큽니다. 반대로 짧은 질문이나 이미 잘 정리된 입력은 줄일 토큰이 많지 않습니다.

그래서 실무 판단 기준은 “얼마나 줄어든다고 홍보하는가”가 아닙니다. 우리 조직의 실제 agent workflow에서 입력 토큰, 출력 토큰, 지연 시간, 캐시 적중률, 실패율을 함께 측정해야 합니다.

토큰 다이어트가 필요한 팀의 신호

Headroom 같은 도구를 바로 도입해야 하는 팀은 몇 가지 신호가 있습니다.

1. 코딩 에이전트가 큰 저장소를 반복해서 읽습니다.
2. 로그와 테스트 결과가 매 요청마다 길게 붙습니다.
3. RAG 검색 결과가 과도하게 많이 들어갑니다.
4. 같은 시스템 프롬프트와 정책 문서가 계속 반복됩니다.
5. 사용량 한도나 월 비용 때문에 AI 도구 활용이 멈춥니다.

이런 상황에서는 모델을 바꾸기 전에 컨텍스트 구조부터 봐야 합니다. 비싼 모델이 문제가 아니라, 비싼 모델에 불필요한 입력을 계속 보내는 구조가 문제일 수 있습니다.

조직이 배워야 할 5가지 교훈

첫째, AI 비용 최적화는 재무팀의 일이 아니라 엔지니어링 문제입니다. 비용은 토큰 구조, 도구 호출, 캐시 설계, RAG 품질에서 결정됩니다.

둘째, 프롬프트 압축은 마지막 단계입니다. 먼저 검색 결과를 줄이고, 중복을 제거하고, 필요한 파일만 읽게 해야 합니다. 원천에서 줄이지 못한 낭비를 문장 압축만으로 해결하기는 어렵습니다.

셋째, 압축은 품질 검증과 함께 가야 합니다. 토큰이 줄어도 답이 틀리면 실패입니다. Headroom이 benchmark와 재현 명령을 함께 제시하는 이유도 여기에 있습니다.

넷째, 캐시를 깨지 않는 설계가 더 봐야 합니다. 공급자의 prompt cache는 입력이 조금만 바뀌어도 효과가 떨어질 수 있습니다. 절감 도구가 캐시를 망가뜨리면 총비용은 오히려 늘어납니다.

다섯째, 원본 보존이 해야 합니다. AI가 압축된 정보만 보고 판단하면 중요한 맥락을 놓칠 수 있습니다. 필요할 때 원문을 다시 조회할 수 있는 구조가 안전합니다.

도입 전 체크리스트

Headroom이나 유사 도구를 검토한다면 다음 항목부터 체크해 두세요.

1. 현재 agent 작업별 입력 토큰과 출력 토큰을 측정하고 있는가?
2. RAG 검색 결과의 topK와 중복 제거 기준이 있는가?
3. 로그·파일·테스트 결과를 통째로 넣고 있지는 않은가?
4. 압축 전후 정답률과 작업 성공률을 비교할 수 있는가?
5. 코드, JSON, 보안 정책, URL, 식별자를 안전하게 보호하는가?
6. 캐시 적중률이 압축 후에도 유지되는가?
7. 실패 시 압축을 끄고 재실행하는 fallback이 있는가?

함께 읽으면 좋은 글

• AI 네이티브 전환법: 디지털 두뇌와 AI 에이전트로 일하는 방식 바꾸기
• 하네스 엔지니어링이 온다: AI 에이전트를 제대로 일하게 만드는 법
• 에이전틱 엔지니어링: 안드레이 카파시가 말한 바이브 코딩 이후의 개발 방식
• AI 도구를 하나로 묶는 Agent OS 구축법: 7단계 블루프린트

결론: AI 비용은 사용량 문제가 아니라 설계 문제다

Headroom이 주는 시사점은 “토큰을 아껴 쓰자” 정도가 아닙니다. AI 에이전트가 조직의 일하는 방식 안으로 들어오면, 컨텍스트를 어떻게 수집하고 줄이고 보존하고 재사용할지가 핵심 역량이 됩니다.

앞으로 좋은 AI 시스템은 모델만 좋은 시스템이 아닙니다. 필요한 정보만 보내고, 중복을 줄이며, 캐시를 활용하고, 실패 시 원본으로 돌아갈 수 있는 시스템입니다. 토큰 다이어트는 비용 절감 기술이면서 동시에 AI 운영 설계의 출발점입니다.

FAQ

Headroom은 Netflix 공식 프로젝트인가요?

The Register 보도에 따르면 Headroom은 Netflix 공식 프로젝트가 아닙니다. 넷플릭스 시니어 엔지니어 Tejas Chopra가 만든 오픈소스 프로젝트이며, 여러 팀과 외부 프로젝트에서 사용되는 것으로 소개됐습니다.

Headroom은 프롬프트를 요약하는 도구인가요?

단순 요약 도구로 보기에는 좁습니다. Headroom은 로그, 파일, RAG 결과, tool output, 대화 기록을 LLM 호출 전에 줄이는 컨텍스트 압축 계층입니다. 라이브러리, 프록시, MCP 서버, 에이전트 wrapper 형태로 사용할 수 있습니다.

토큰을 줄이면 답변 품질이 떨어지지 않나요?

수 있습니다. 그래서 압축 전후의 작업 성공률, 정답률, 지연 시간, 캐시 적중률을 함께 봐야 합니다. 코드나 JSON처럼 구조가 중요한 데이터는 무리하게 압축하면 위험합니다.

어떤 조직에 먼저 필요할까요?

코딩 에이전트, RAG, 대규모 로그 분석, SRE incident 대응, 대형 코드베이스 탐색을 자주 하는 조직에 먼저 해야 합니다. 짧은 질의응답 위주의 팀이라면 효과가 제한적일 수 있습니다.

참고자료

• GitHub, chopratejas/headroom
• Headroom README 원문
• Headroom 문서 사이트
• The Register, Netflix wiz creates app to slash AI bills