양실장의 바이브코딩대학 강의 **「암묵지 자산화를 위한 딥트윈 에이전트의 전체 원리와 설계 프로세스」**에서는 AI 에이전트를 단순히 LLM에 도구 몇 개를 붙인 자동화 수준이 아니라, **기업에서 운영·평가·개선 가능한 자산**으로 만드는 전체 구조를 설명합니다. 핵심은 각각의 기술 용어를 따로 외우는 것이 아니라, **메모리 → Harness → Loop/Graph → LLMOps → Eval → Deep Twin**이 어떻게 하나의 시스템으로 연결되는지를 이해하는 것입니다. ## AI 에이전트는 무엇으로 구성되는가? 강의에서는 에이전트의 기본 입력을 다음 세 가지로 설명합니다. - 시스템 프롬프트 - 사용자 프롬프트 - 현재 대화 히스토리 여기에 외부 메모리와 도구가 연결되면서 단순한 LLM 응답 시스템이 실제 업무를 수행하는 에이전트로 확장됩니다. ## 에이전트 메모리의 세 가지 유형 강의에서는 메모리를 세 가지 관점으로 나눕니다. ### 1. 절차적 메모리 **어떻게 행동해야 하는가**를 기억하는 구조입니다. 대표적인 예가 Skill입니다. 특정 작업을 언제 사용하고 어떤 순서로 처리해야 하는지가 정의되어 있기 때문에, 에이전트가 반복 가능한 업무 절차를 수행할 수 있습니다. ### 2. 의미론적 메모리 **무엇을 알고 있는가**에 해당합니다. 매뉴얼, 규정, 사용자 정보, 회사 문서 같은 사실성 정보를 벡터 데이터베이스에서 검색해 현재 작업에 주입하는 구조이며, 일반적으로 RAG가 여기에 해당합니다. ### 3. 일화적 메모리 과거 대화나 실제로 있었던 사건을 기억하는 구조입니다. 현재 채팅의 히스토리와는 달리, 이전 세션에서 있었던 대화나 판단 사례 중 현재 작업과 관련 있는 내용을 검색해 다시 활용합니다. 즉, 에이전트 메모리를 정리하면 다음과 같습니다. - Skill → 절차 기억 - RAG → 사실·지식 기억 - 과거 대화·행동 기록 → 경험 기억 ## Harness — 확률적인 LLM을 실제 업무에 쓰게 만드는 구조 LLM은 본질적으로 확률적으로 결과를 생성합니다. 하지만 기업 업무에서는 결과를 단순히 확률에 맡길 수 없습니다. 강의에서는 **Harness**를 LLM이 실제 업무 환경에서 안전하고 통제 가능하게 움직이도록 감싸는 구조로 설명합니다. Harness에는 다음과 같은 요소가 들어갈 수 있습니다. - 도구 사용 규칙 - 작업 절차 - 결과 검증 - 반복 실행 - 권한 제한 - 오류 처리 - 상태 관리 모델을 묶어두는 개념이라기보다, **LLM이라는 엔진에 실제 업무를 수행할 팔다리와 통제 장치를 붙이는 구조**에 가깝습니다. ## Loop — 목표를 달성할 때까지 실행하고 검증한다 에이전트가 한 번 작업했다고 해서 업무가 완료된 것은 아닙니다. 예를 들어 사용자가 10개의 항목을 처리해달라고 요청했는데 하나만 처리하고 "완료했습니다"라고 답한다면 자동화라고 보기 어렵습니다. Loop는 다음과 같은 구조를 만듭니다. **실행 → 결과 확인 → 목표 충족 여부 판단 → 미완료 시 다시 실행 → 완료** 즉, Loop는 **Goal-driven 구조**입니다. 정기적으로 실행되는 Cron 작업이나 반복적인 검증 프로세스 역시 넓은 의미에서 Loop의 일부로 볼 수 있습니다. ## Graph — 복잡한 업무를 병렬로 분기하고 다시 합친다 모든 업무가 단순한 반복 구조로 해결되는 것은 아닙니다. 기업 업무는 여러 작업이 동시에 진행된 뒤 하나의 결과로 합쳐지는 경우가 많습니다. 예를 들어 일정 관련 이메일을 처리한다고 하면 다음 작업이 병렬로 실행될 수 있습니다. - 이메일 내용 분석 - 캘린더 조회 - 담당자 정보 조회 - 관련 문서 검색 - 일정 충돌 확인 그리고 각 결과를 다시 모아 최종 답변을 생성합니다. 이처럼 **분기 → 병렬 실행 → 결과 통합** 구조가 필요할 때 Graph 기반 설계가 유용합니다. ## 개인 에이전트와 기업 에이전트의 가장 큰 차이 개인용 에이전트는 결과가 이상하면 사용자가 직접 확인하고 다시 요청할 수 있습니다. 하지만 기업에서 사용하는 에이전트는 그렇지 않습니다. 기업에서는 다음 질문에 답할 수 있어야 합니다. - 어떤 입력을 받았는가? - 어떤 메모리를 사용했는가? - 어떤 도구를 호출했는가? - 어떤 경로를 거쳐 결과를 만들었는가? - 왜 이런 판단을 했는가? - 비용과 응답 시간은 얼마나 들었는가? - 결과가 기준을 만족했는가? 이런 운영 환경이 없으면 에이전트는 기업 입장에서 **거대한 블랙박스**가 됩니다. ## LLMOps와 Tracing 그래서 필요한 것이 **LLMOps**입니다. 웹 개발에서 오류가 발생하면 stack trace를 따라가며 문제가 발생한 위치를 찾듯이, AI 에이전트 역시 작업 과정을 추적할 수 있어야 합니다. Tracing을 통해 다음과 같은 내용을 확인할 수 있습니다. - 어떤 프롬프트가 사용됐는가 - 어떤 도구를 호출했는가 - 어떤 메모리가 주입됐는가 - 어떤 단계에서 오류가 발생했는가 - 토큰이 과도하게 사용됐는가 - 특정 구간에서 지연이 발생했는가 - Loop가 불필요하게 반복됐는가 강의에서는 이런 구조가 있어야 기업이 에이전트를 관리 가능한 자산으로 볼 수 있다고 설명합니다. ## Eval — 결과가 기준을 만족했는지 평가한다 에이전트가 결과를 만들었다고 해서 업무가 끝난 것은 아닙니다. **Eval(Evaluation)** 은 결과가 사전에 정의한 기준을 만족했는지를 평가하는 과정입니다. 예를 들어 다음과 같은 기준을 둘 수 있습니다. - 사실 관계가 맞는가? - 필요한 항목이 모두 포함됐는가? - 회사 정책을 위반하지 않았는가? - 지나치게 많은 토큰을 사용하지 않았는가? - 응답 시간이 허용 범위 안인가? 평가 결과가 기준을 충족하면 실제 운영 환경에 적용하고, 그렇지 않으면 Tracing 결과를 바탕으로 다시 수정합니다. 즉, **실행 → Tracing → Eval → 개선 → 재배포** 라는 운영 루프가 만들어집니다. ## Hermes와 원격 AI 에이전트 강의에서는 Hermes 같은 원격 에이전트도 전체 구조 안에서 설명합니다. Telegram이나 Slack 같은 채널은 사용자와 에이전트를 연결하는 **Gateway** 역할을 합니다. 에이전트를 계속 사용하면 다음과 같은 정보가 축적될 수 있습니다. - 사용자의 반복적인 요청 - 선호하는 방식 - 업무 습관 - 자주 쓰는 절차 - 판단 기준 이 과정에서 일부는 메모리로 저장되고, 반복되는 작업은 새로운 Skill로 정리될 수 있습니다. ## 마지막 단계는 Deep Twin 강의의 핵심은 결국 **기업의 암묵지를 어떻게 AI 자산으로 만들 것인가**입니다. 기업에서 중요한 지식은 매뉴얼이나 규정에만 존재하지 않습니다. 숙련된 사람은 상황에 따라 다음 요소를 함께 고려합니다. - 과거 경험 - 비슷한 사례 - 상대방의 반응 - 조직의 분위기 - 결과에 대한 피드백 - 상황별 판단 기준 이런 지식은 문서만으로 완전히 설명하기 어렵기 때문에 **암묵지**라고 부릅니다. Deep Twin은 단순히 "나는 이런 사람이다"라는 프로필을 만드는 것이 아닙니다. 대신 다음 데이터를 지속적으로 축적합니다. - 실제로 어떤 행동을 했는가 - 무엇을 보고 판단했는가 - 어떤 선택을 했는가 - 결과가 어땠는가 - 그 결과에 어떤 피드백을 남겼는가 이 데이터가 계속 쌓이면 에이전트는 사람의 사고 절차와 판단 기준에 점점 가까워질 수 있습니다. ## 전체 구조 정리 영상의 내용을 하나의 흐름으로 정리하면 다음과 같습니다. **LLM → Memory → Skill·RAG → Harness → Loop·Graph → Tracing → LLMOps → Eval → Feedback → Deep Twin** 이 구조에서 중요한 점은 AI 에이전트를 단순한 자동화 프로그램이 아니라 **지속적으로 학습·평가·개선되는 업무 시스템**으로 바라보는 것입니다. 특히 기업에서는 사람의 경험과 판단 과정까지 데이터로 축적할 수 있을 때, AI 자동화가 단순한 생산성 도구를 넘어 **조직이 보유할 수 있는 새로운 형태의 지식 자산**이 될 수 있습니다.