AI와 사람이 함께 일하는 구조 이렇게 만듭니다

URL: https://www.youtube.com/watch?v=QScl3AOevuY 날짜: 2026-08-11 채널: 김효율의 AI 개발단 영상 길이: 48분 25초 형식: 2026-08-06 진행 웨비나 녹화본 자막: 한국어 자동 자막을 기준으로 번역·정리함. ASR 오인식은 문맥에 맞게 보정했으며, 불확실한 고유 명령명은 원음 표기를 병기함.

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

AI를 쓰면 생산성이 높아지는 것처럼 보이지만, 세션 간 기억 단절과 흩어진 도구 때문에 오히려 컴퓨터 앞에 앉아 있는 시간이 늘어날 수 있다. 이를 해결하려면 AI의 기억을 파일 구조로 영속화하고, 업무별 세션과 역할별 에이전트를 분리하며, 사람이 전체 업무 흐름을 판단·감독하는 운영 환경을 만들어야 한다.

• AI 채팅 세션은 분리되어 있어 새 창을 열면 이전 업무의 맥락과 결과를 다시 설명해야 한다.
• 컨텍스트 윈도우가 자동 압축될 때 중요한 맥락이 사라지면 환각(hallucination)과 재작업이 발생한다.
• 멀티 에이전트는 멋있어 보이기 위해 쓰는 것이 아니라, 업무 맥락을 격리하고 역할을 분리할 때 사용해야 한다.
• Obsidian 자체보다 중요한 것은 에이전트가 읽고 쓸 수 있는 로컬 폴더·Markdown 파일·지도 구조다.
• 실행은 AI에게 맡기되, 무엇을 저장하고 압축하고 승인할지는 사람이 판단해야 한다.

발표자는 디자이너, 사업가, 비즈니스 모델·브랜드·상품 기획을 거쳐 현재 AX(AI Transformation) 업무를 하고 있다. 다양한 업무에서 병목을 찾고 해결해 온 경험을 바탕으로, Claude Code와 로컬 파일 구조, 업무별 에이전트, 자체 제작 대시보드와 UI 인스펙터를 하나의 시스템으로 묶어 시연한다.

1. AI를 써도 일이 줄지 않는 이유

AI 도입의 핵심 병목은 모델의 성능만이 아니라, 사람이 AI를 매번 다시 교육하고 결과를 찾아 헤매는 운영 방식이다.

1.1. 생산성은 올랐는데 컴퓨터 앞의 시간은 늘어난다

1. AI 도입 이후의 역설

   1. 발표자는 ChatGPT부터 AI를 사용하면서 업무 생산성이 올라간 느낌을 받았다.
   2. 그러나 AI를 사용하는 시간과 컴퓨터 앞에 앉아 있는 시간도 함께 늘었다.
   3. AI는 현존하는 업무 도구 중 가장 강력하고 재미있는 도구지만, 사용법을 모르면 사람이 AI에 맞춰 일하게 된다.

2. 도구의 편리함과 사용 구조의 차이

   1. 망치가 있으면 못을 더 빨리 박을 수 있듯이 도구는 생산성을 높인다.
   2. 하지만 도구가 편리하다는 사실만으로는 업무 전체가 줄어들지 않는다.
   3. AI가 어떤 업무 맥락을 기억하고 어디에서 결과를 찾아야 하는지까지 설계해야 도구의 성능이 실제 생산성으로 바뀐다.

1.2. 세션 기억 단절이 만드는 재설명 비용

1. 새 창을 열면 사라지는 맥락

   1. 어제까지 AI와 고민 상담, 업무 논의, 자료 작성 등을 진행했어도 새 세션에서는 이전 대화가 이어지지 않는다.
   2. AI가 원천적으로 기억을 못 하는 것이 아니라, 채팅 세션이 서로 분리되어 있기 때문에 다른 세션의 맥락을 자동으로 가져오지 못하는 것이다.
   3. 사용자는 “어제 이 이야기를 했잖아”라고 말한 뒤, 다시 배경·목표·현재 상태·기존 결과를 설명해야 한다.

2. 재설명의 누적 시간

   1. 발표자는 하루에 최소 15~30분 정도 과거에 했던 설명을 다시 하는 데 썼다고 말한다.
   2. 1년을 약 250일로 계산하면 하루 10분의 재설명만으로도 연간 약 42시간이 든다.
   3. 하루 30분이면 약 125시간이며, 하루 60분이면 약 250시간으로 8시간 근무일 기준 한 달 이상에 해당한다.
   4. 기억 저장소가 없으면 AI의 성능이 아니라 사용자의 반복 설명이 병목이 된다.

1.3. 세션과 도구가 흩어지는 문제

1. 결과를 다시 찾는 비용

   1. 여러 세션에서 일을 하다 보면 보고서나 문서를 어느 세션에서 만들었는지 기억나지 않는다.
   2. 사용자는 세션을 위로 스크롤하거나 Ctrl+F로 키워드를 검색하며 결과를 다시 찾아야 한다.
   3. 업무 결과가 텍스트로만 존재하면 숫자·진척률·상태를 한눈에 파악하기도 어렵다.

2. 업무 도구 전환 비용

   1. 실제 업무에는 Excel, Word, Google Calendar, Gmail, Notion 등 많은 도구가 동시에 사용된다.
   2. 창이 많아질수록 Alt+Tab으로 화면을 전환하고 작업 표시줄에서 프로그램을 찾는 시간이 늘어난다.
   3. 발표자는 이 도구들을 하나의 업무 환경으로 묶고, AI의 결과와 사람의 일정·업무·메일을 같은 화면에서 보고 싶다는 문제의식에서 시스템을 만들기 시작했다.

1.4. 기억이 있으면 요청의 수준이 달라진다

1. 기억이 없는 AI의 응답

   1. “지난 6월 컨퍼런스를 요약해 줘”라고 요청하면, 기록과 행사 맥락을 알 수 없어 다시 설명해 달라고 한다.
   2. 사용자는 과거 자료를 찾고, 행사 목적과 결과를 설명하고, 원하는 보고서 형식을 다시 지정해야 한다.

2. 기억이 연결된 AI의 응답

   1. 기억 저장소에 6월 컨퍼런스와 2분기 실적 정보가 남아 있으면 AI가 이전 자료를 찾아온다.
   2. “6월 컨퍼런스를 요약하고 2분기 실적 피드백까지 분석해 보고서로 만들어 줘”처럼 결과 중심으로 지시할 수 있다.
   3. 사용자는 반복 설명 대신 결과를 검토하고 커피 한 잔을 마실 여유를 얻는다.

2. 멀티 에이전트는 왜 필요한가

멀티 에이전트(multi-agent)는 여러 창을 띄워 과시하는 기능이 아니라, 컨텍스트를 분리하고 각 업무의 책임을 명확히 하기 위한 운영 방식이다.

2.1. 목적이 먼저이고 멀티 에이전트는 수단이다

1. 유행을 따라 쓰지 않기

   1. 최근에는 “멀티 에이전트를 어떻게 쓰느냐”는 질문이 많지만, 발표자는 먼저 “왜 쓰려고 하느냐”고 묻는다.
   2. 현재 모델은 단일 에이전트만으로도 많은 일을 처리하므로, 여러 에이전트를 반드시 써야 하는 것은 아니다.
   3. 터미널 창 여러 개와 수백 명의 가상 직원을 둔 그림은 멋있어 보이지만 실제 업무 목적을 해결하지 못하면 복잡성만 늘어난다.

2. 멀티 에이전트가 유효한 경우

   1. 업무마다 서로 다른 배경지식과 문서를 읽어야 할 때 컨텍스트를 분리할 수 있다.
   2. 디자이너에게 세무를 시키고, 개발자에게 마케팅을 시키는 식의 맥락 혼합을 막을 수 있다.
   3. 기획, 개발, 마케팅, 리서치, 영업, 재무를 역할별로 나누면 각 에이전트가 자기 직무에 필요한 정보만 우선 읽게 할 수 있다.

2.2. 컨텍스트 윈도우를 책상으로 이해하기

1. 토큰과 책상 크기

   1. 컨텍스트(context)는 AI가 현재 작업에 들고 있는 토큰(token)과 밀접하게 연결되어 있다.
   2. 발표자는 컨텍스트 윈도우를 책상의 크기에 비유한다.
   3. 예시로 Claude Code의 1.0m은 약 100만 토큰의 컨텍스트 윈도우를 뜻한다고 설명한다.
   4. 영어의 짧은 단어는 적은 토큰으로 표현되지만 한국어 문장은 상대적으로 더 많은 토큰을 사용할 수 있으므로 언어별 비용과 공간이 다를 수 있다.

2. 책상이 차면 자동 정리가 시작된다

   1. 대화와 파일이 쌓이면 책상 위에 문서가 계속 늘어나는 것처럼 컨텍스트가 가득 찬다.
   2. 컨텍스트가 100%에 가까워지면 AI는 자동으로 내용을 압축(compaction)한다.
   3. 사람이 책상을 정리하면 중요한 문서를 어디에 두었는지 알지만, 자동 압축은 어떤 문서를 버리고 어떤 맥락을 약화했는지 사용자가 통제하기 어렵다.
   4. 방금 보던 문서의 위치와 작업 의도가 흐려지면 AI가 잘못 추론하거나 환각을 만들 수 있다.

2.3. 의도적인 압축과 세션 초기화

1. 80%에서 수동 압축하기

   1. 발표자는 컨텍스트가 약 80% 찼을 때 Claude의 compact 기능으로 의도적인 압축을 실행한다.
   2. “가장 최근 작업에 높은 가중치를 두고, 이전 작업일수록 가중치를 낮춰 압축하라”는 식으로 다음 세션에 필요한 순서를 지정한다.
   3. 작업의 최신 상태, 다음 행동, 미완료 항목을 남기면 압축 뒤에도 바로 이어서 일할 수 있다.
   4. 매번 프롬프트를 복사하지 않도록 발표자는 압축용 사용자 명령을 등록해 두었다. 자막에는 이 명령명이 “로우프레스”처럼 인식되어 있으며, 핵심은 반복 가능한 압축 명령을 단축어로 만든다는 점이다.

2. 압축의 반복을 제한하기

   1. 압축을 반복하면 복사본을 여러 번 복사하는 것처럼 정보가 점점 흐려질 수 있다.
   2. 발표자는 한 세션에서 약 세 번까지 압축한 뒤 clear와 같은 초기화 명령으로 세션을 새로 시작하는 방식을 사용한다.
   3. 세션을 초기화해도 기억 저장소가 있으면 파일을 읽어 작업을 이어갈 수 있다.
   4. 압축 횟수를 표시하는 표식을 바꾸어 세션이 몇 번 정리되었는지 관리한다.

3. 지속 가능한 기억 장치

   1. 발표자는 Obsidian에 작업 결과와 상태를 저장해 세션과 PC가 달라져도 업무를 이어간다.
   2. Claude 계정을 바꾸거나 다른 컴퓨터에서 작업해도 동일한 폴더 구조와 파일을 읽으면 된다.
   3. Obsidian 자체가 필수라기보다, AI가 읽고 쓸 수 있는 로컬 폴더와 Markdown 파일을 지속적으로 관리하는 구조가 핵심이다.

3. 사람이 판단하고 AI가 실행하는 운영 원칙

AI에게 실행을 맡길수록 사람이 승인·정리·판단해야 하는 지점이 더 선명해야 한다.

3.1. 업무별 세션과 역할별 에이전트

1. 업무 맥락을 섞지 않기

   1. 하나의 세션에서 디자인, 세무, 개발을 모두 시키면 각 업무의 맥락이 섞인다.
   2. 세션을 업무별로 나누면 대화가 짧아지고, 파일과 지시의 의미가 더 분명해진다.
   3. 단일 에이전트가 모든 업무를 맡는 것보다 업무별 세션과 역할별 지시를 유지하는 편이 결과를 검토하기 쉽다.

2. 발표자의 역할 분담 예시

   1. Pepper: 여러 에이전트의 작업을 조정하는 모더레이터.
   2. Da Vinci: 기획을 담당하는 에이전트.
   3. 개발 에이전트: 기능 구현과 코드 작업을 담당한다.
   4. 마케터·리서처·영업·재무 에이전트: 각 직무에 맞는 자료와 실행을 맡는다.
   5. 역할별 에이전트는 자기 업무에 맞는 지식과 파일을 먼저 읽고, 불필요한 맥락을 끌어오지 않는다.

3.2. 실행은 AI, 판단은 사람

1. 사람이 결정해야 하는 것

   1. 어떤 지식을 영구 보관할지 결정한다.
   2. 어떤 정보를 압축하고 어떤 정보를 원본으로 남길지 결정한다.
   3. 중요한 비즈니스 판단과 승인, 고객에게 보내는 결과물의 최종 품질을 사람이 검토한다.

2. AI에게 맡길 수 있는 것

   1. 반복 문서 작성, 데이터 수집, 분류, 초안 작성, 일정 연결과 같은 실행을 맡긴다.
   2. 500건의 커머스 리뷰를 크롤링해 분석하거나, Instagram·TikTok·YouTube Shorts에서 키워드별 자료를 찾는 반복 작업을 자동화한다.
   3. 이메일이 오면 초안을 만들고, 견적서가 승인되면 계약서로 변환하는 연쇄 자동화를 실행한다.

3. 핵심 원칙

   1. AI가 스스로 모든 것을 판단하게 만드는 것이 목표가 아니다.
   2. 사람이 업무 목적과 승인 기준을 정하고 AI가 반복 실행을 담당하게 해야 한다.
   3. 발표자의 표현으로는 “실행은 AI가 하고 판단은 사람이 하는 것”이 운영의 기준이다.

4. 업무 전체를 보는 대시보드 구조

발표자는 사람과 AI가 같은 업무 공간에서 일하도록 로컬 웹 대시보드를 만들었다. 대시보드는 단순한 예쁜 화면이 아니라 기억·업무·메일·에이전트·자동화·사용량을 한곳에 모으는 운영 계층이다.

4.1. 메인 화면과 업무 현황

1. 한눈에 보는 정보

   1. AI 토큰 사용량을 확인한다.
   2. 현재 진행 중인 전체 업무와 각 업무의 상태를 확인한다.
   3. 전체 업무 수와 완료율을 확인한다.
   4. 미확인 이메일, 일정, 에이전트 작업, 자동화 현황을 같은 화면에 배치한다.

2. 에이전트와 핸드오버

   1. 대시보드에는 약 10명의 에이전트가 상주한다.
   2. 에이전트가 업무를 끝내고 결과를 저장·등록하면 핸드오버 완료 상태로 표시한다.
   3. 각 에이전트가 매일 수행한 일을 브리핑 영역에 기록하므로 사용자는 세션을 뒤지지 않고 작업 이력을 확인할 수 있다.

4.2. Gmail·Drive·Notion·Calendar 연결

1. 메일과 파일

   1. Gmail을 연결해 받은 편지함·보낸 편지함·임시보관함을 대시보드에서 본다.
   2. 미회신 메일의 초안을 에이전트에게 작성시킬 수 있다.
   3. Google Drive도 연결해 업무에 필요한 파일을 같은 환경에서 불러온다.

2. 업무 보드와 일정

   1. Notion 기반 업무 보드를 연결해 업무를 등록·수정한다.
   2. 업무 상태와 진척률을 표시하고, 전체 일정 중 완료된 작업 수를 확인한다.
   3. 업무 보드의 일정을 캘린더에서 한눈에 본다.
   4. 하위 노트를 만들고 단축키·번호·구분선을 사용해 메모를 정리한 뒤, 업무 보드에 바로 추가한다.

4.3. 문서함·거래처·계약 업무

1. OCR 문서함

   1. PDF나 이미지를 문서함에 드래그 앤 드롭하면 OCR(Optical Character Recognition)로 이미지와 텍스트를 분리해 저장한다.
   2. 사업자등록증·명함 같은 거래처 자료를 올리면 거래처 정보와 문서함을 서로 연결한다.

2. 영업·계약 흐름

   1. 외주 요청이 들어오면 견적서를 작성한다.
   2. 견적서가 승인되면 계약서를 생성하는 자동화를 연결한다.
   3. 완성된 문서를 이메일로 바로 발송한다.

4.4. 지식망과 조직 운영

1. 파일 트리 기반 기억 저장소

   1. 대시보드의 지식망은 발표자가 사용하는 폴더 구조와 같은 형태로 구성되어 있다.
   2. 에이전트는 지식망을 기억 저장소로 사용하며, 업무 파일·대화록·작업 로그를 찾아 읽는다.
   3. 일별 브리핑을 바탕으로 주간·월간·연간 단위의 인사·성과 보고를 만들 수 있다.

2. 회사 내부 시스템으로의 확장

   1. 현재는 에이전트가 상주하지만 나중에 직원을 추가하면 사람의 업무도 같은 화면에서 볼 수 있다.
   2. 발표자는 이 구조를 인트라넷·ERP·그룹웨어와 비슷한 사내 운영 시스템으로 설명한다.
   3. 성과를 그래프로 분류해 사람과 AI의 작업 흐름을 함께 관리할 수 있다.

4.5. 에이전트·자동화·도구 현황

1. 에이전트 채팅

   1. 대시보드 안의 채팅 버튼으로 에이전트에게 직접 지시한다.
   2. Claude Code에서 사용하던 Pepper·Da Vinci 등의 세션도 대시보드에 연결한다.
   3. Claude Code에서 하던 작업과 대시보드에서 하던 작업이 하나의 업무 기록으로 통합된다.

2. 자동화 모니터링

   1. 현재 어떤 업무가 자동 실행 중인지 확인한다.
   2. 메일 초안 작성, 승인된 견적서의 계약서 변환 같은 자동화를 관리한다.
   3. 에이전트별·업무별·스킬별 토큰 사용량을 확인해 비효율적인 초기 컨텍스트를 줄인다.

3. 도구 인벤토리

   1. 에이전트가 사용하는 Skill과 MCP(Model Context Protocol)를 한 화면에 표시한다.
   2. Claude Code, Codex, Hermes 등 연결된 에이전트가 어떤 도구를 사용하는지 확인한다.
   3. 도구가 늘어날수록 처음 세션을 열 때 자동으로 읽는 정보가 많아지므로 사용량을 모니터링해 정리한다.

5. 대시보드 스킬팩과 실제 생성 시연

발표자는 대시보드를 매번 처음부터 코딩하지 않기 위해 디자인 시스템과 기능 생성 규칙을 스킬팩(Skill Pack)으로 묶어 두었다.

5.1. 범용 대시보드 설계

1. 도메인 지식의 한계 인정

   1. 시청자가 공간 대관 대시보드를 요청했지만, 발표자는 공간 대관 업무에 필요한 데이터와 업무 흐름을 충분히 알지 못한다고 답했다.
   2. 도메인 지식이 부족한 상태에서 그럴듯한 화면만 만드는 것은 실제 업무에 쓸 수 있는 대시보드가 아니다.

2. 시연용 주제 선택

   1. 직원 스케줄·근태 관리와 매출·현금 흐름은 비교적 범용적인 주제라서 시연하기 쉽다고 판단했다.
   2. 직원 수는 약 30명으로 설정했다.
   3. 메인 화면에는 근태 관리와 매출 관리를 배치했다.
   4. 매출·운영비·고정비·일별 매출·주간 매출을 포함하도록 요청했다.
   5. 시연 화면은 실제 데이터 연결이 아닌 범용 UI 생성 예시라는 점을 분명히 했다.

5.2. UX 우선 설계

1. UI와 UX의 구분

   1. UI(User Interface)는 화면과 컨트롤의 모양을 뜻하지만, 발표자는 UX(User Experience)를 먼저 설계한다.
   2. 사용자가 실제로 앱을 사용하는 경험이 편하고 업무 흐름이 자연스러운지를 먼저 정한다.
   3. 메뉴·데이터·승인·등록·조회 순서를 설계한 뒤 화면을 만든다.

2. 로컬 웹 서비스 구조

   1. 발표자의 대시보드는 로컬에서 실행되는 웹 서비스다.
   2. 모든 데이터를 외부 클라우드로 보내는 구조가 아니라, 필요한 기능만 Gmail·Notion API 등과 연결한다.
   3. 로컬에서만 사용해도 되고, 배포하면 회사 구성원이 같은 화면에 접속할 수 있다.

6. 라이브 Q&A에서 다룬 실무 원칙

6.1. Effort 설정과 모델 선택

1. 기본값은 과도하게 높이지 않기

   1. 하네스(harness)로 AI의 행동을 충분히 통제할 수 있다면 항상 높은 추론 강도나 effort를 쓸 필요가 없다.
   2. effort가 높을수록 느려지고, 모델이 사용자가 원하지 않은 추가 추론과 기능을 넣을 수 있다.
   3. 정해진 형식대로 실행해야 하는 업무는 중간 수준으로 두고 속도와 일관성을 우선한다.

2. 높은 추론 강도가 필요한 경우

   1. 코드베이스가 복잡하게 꼬였거나 사람이 해결 방향을 정하기 어려운 문제에는 높은 추론 강도를 사용한다.
   2. 이때는 Fable 같은 강한 모델을 사용해 문제의 원인과 해결 방향을 모델이 판단하게 한다.
   3. 결과의 형식과 절차가 이미 정해져 있는 작업과, 해결 방법 자체를 찾아야 하는 작업을 구분해야 한다.

6.2. Obsidian보다 중요한 파일 구조

1. Obsidian은 선택 사항

   1. 발표자는 Obsidian 유료 클라우드를 사용하지 않고 자체 시스템을 만들었다.
   2. Claude Code에서 Obsidian에 저장하려면 Obsidian MCP가 편리하기 때문에 Obsidian을 사용한다.
   3. 단순히 로컬 폴더에 파일을 저장하려면 핸드오버 문서 업데이트만으로도 충분하다.

2. 폴더와 Markdown이 기억의 기반

   1. Obsidian의 핵심은 앱의 외형이 아니라 폴더 구조와 Markdown 파일이다.
   2. 에이전트가 상주하는 폴더와 업무별 문서 구조를 만들면 다른 도구에서도 같은 기억을 활용할 수 있다.
   3. 발표자는 Andrej Karpathy가 사용한 LLM 위키도 특정 앱보다 로컬 폴더 구조가 핵심이라고 설명한다.

6.3. 데이터 연결과 실제 대시보드

1. API가 있는 데이터

   1. Smart Store나 쿠팡처럼 API가 제공되는 서비스는 매출 데이터를 자동으로 가져올 수 있다.
   2. 누적 데이터를 대시보드의 그래프와 지표에 연결하면 수동 입력 없이 실시간에 가까운 현황을 만들 수 있다.

2. 도메인별 설계의 필요성

   1. 범용 시연 화면과 실제 회사용 시스템은 필요한 데이터·권한·승인 흐름이 다르다.
   2. 실제 구축에서는 먼저 업무 목적과 사용자의 행동을 정의한 뒤 메뉴와 데이터를 설계해야 한다.

6.4. 병목을 자동화하는 기준

1. 병목의 원인부터 찾기

   1. 병목은 특정 구간에 문제가 있다는 뜻이므로, 먼저 반복·지연·오류의 원인을 확인한다.
   2. 그 문제를 에이전트가 해결할 수 있는지, 사람이 판단해야 하는 구간이 어디인지 분리한다.

2. 반복량이 큰 수집·분석 업무

   1. 커머스 리뷰를 500건 단위로 수집하고 분석해 제품 소재를 찾는 작업은 사람에게 병목이 되기 쉽다.
   2. Instagram·TikTok·YouTube Shorts에서 키워드별 콘텐츠를 검색하는 작업도 자동화 후보가 된다.
   3. 이런 작업은 목적과 입력·출력 형식이 분명하므로 역할별 에이전트나 자동화로 전환하기 쉽다.

6.5. 기억의 정제와 보관

1. 기억이 많아질 때의 문제

   1. Markdown 파일과 기억 노드가 계속 늘어나면 사람의 뇌처럼 검색과 판단이 느려질 수 있다.
   2. 발표자도 Obsidian을 사용하며 기억이 많아지는 문제를 경험했고, 이를 ‘정제’ 과정으로 해결했다.

2. 4시간 비활성 후 정제

   1. 에이전트를 4시간 이상 사용하지 않은 시간이 생기면 하루 동안 사용 빈도가 낮았던 기억을 자동으로 스캔한다.
   2. 원본, 작업대(workbench), 대화록, 에이전트 로그를 보존하면서 검색용 큰 지도(index/map)를 만든다.
   3. 키워드와 태그를 붙여 최근 활성 기억을 먼저 검색하고, 필요할 때 정제·보관된 기억을 찾아온다.
   4. 즉, 삭제가 아니라 원본과 활성 기억을 분리해 컨텍스트를 가볍게 유지하는 방식이다.

7. 에이전트 오케스트레이션과 루프

7.1. Start Loop와 역할 간 대화

1. 에이전트 활성화

   1. 발표자는 Pepper와 Da Vinci에 Start Loop를 걸어 두 에이전트를 계속 활성화한다.
   2. 각 에이전트에는 자기 이름과 역할이 적힌 프로필 카드가 있다.
   3. Pepper가 Da Vinci에게 작업을 넘기고 Da Vinci가 다시 결과를 보내는 식으로 역할 간 대화를 만든다.

2. 메일함 기반 메시지 전달

   1. 각 에이전트의 폴더 안에 메일함과 인박스·아웃박스 구조를 만든다.
   2. 한 에이전트가 다른 에이전트에게 작업을 전달하면 파일 기반 메시지가 상대 에이전트의 메일함에 들어간다.
   3. 이메일의 수신자·참조처럼 에이전트 간 전달 대상을 지정할 수 있다.
   4. 이 구조가 발표자가 말하는 루프 엔지니어링(loop engineering)의 한 구현이다.

3. 과도한 오케스트레이션은 피하기

   1. 루프를 만들 수 있다고 해서 모든 업무를 에이전트끼리 계속 대화하게 만들 필요는 없다.
   2. 발표자도 해당 구조를 많이 활용하지는 않으며, 분명한 업무 위임이 있을 때 제한적으로 사용한다.

7.2. 스킬과 하네스는 계속 진화해야 한다

1. 스킬에서 하네스로 확장하기

   1. 발표자는 처음부터 거대한 하네스를 만드는 대신 스킬부터 만든다.
   2. 반복되는 작업과 행동 규칙을 스킬로 고정한 뒤, 여러 스킬을 묶어 하네스로 발전시킨다.
   3. 하네스는 모델의 행동을 통제하기 위한 운영 계층이다.

2. 모델이 좋아질수록 하네스도 고쳐야 한다

   1. 모델은 계속 진화하므로 기존 하네스가 새 모델의 행동과 맞지 않을 수 있다.
   2. 강아지가 자라면 더 큰 집이 필요하듯, 모델의 능력이 커질수록 더 적합한 하네스가 필요하다.
   3. 낡은 규칙은 정리하고, 새 모델의 장점을 살리도록 스킬·권한·검증 절차를 다시 다듬어야 한다.

7.3. 다른 PC에서도 재현되는 폴더 구조

1. 포터블한 구조
   1. 발표자는 개발자들과 이야기하며 한 PC에서 만든 폴더 구조가 다른 PC에서도 그대로 작동하는지가 중요하다는 점을 배웠다.
   2. 에이전트·지식·메일함·로그·스킬을 폴더 구조로 정의하면 특정 화면이나 계정에 덜 종속된다.
   3. 사람이 구조를 이해하고 있으면 다른 환경으로 옮기거나 일부 도구를 교체하기 쉽다.

8. 대시보드 생성 결과와 UI 인스펙터

8.1. 생성 후 반복 개선

1. 첫 결과는 완성품이 아니다

   1. 발표자는 약 3210번 포트에서 생성된 매출·영업이익·추세·매출·근태 관리 대시보드를 열어 보였다.
   2. 생성 직후부터 보기 불편한 부분과 오류가 발견되며, 이를 하나씩 수정해야 한다.
   3. AI에게 한 번 지시하고 끝내는 방식이 아니라, 사용하면서 문제를 찾고 스킬과 프롬프트를 개선하는 반복 과정이 필요하다.

2. 디자인 시스템의 재사용

   1. 앱의 기본 껍데기에 카드 간격, 한글 텍스트가 깨지지 않는 규칙, 아이콘, 컴포넌트 등을 미리 정의한다.
   2. 이후 업무에 필요한 기능만 Claude Code를 이용한 바이브 코딩(vibe coding)으로 추가한다.
   3. 메뉴에 광고 대시보드를 넣거나 메인 화면에 특정 지표를 추가하는 식으로 기능을 확장한다.

8.2. UI 인스펙터와 주석 기반 수정

1. 요소를 직접 선택하기

   1. 화면을 캡처하고 빨간색으로 수정 영역을 표시하는 기존 방식의 반복을 줄이기 위해 UI 인스펙터를 만들었다.
   2. 인스펙터를 켜면 화면의 카드·그래프·메뉴를 직접 선택할 수 있다.
   3. 선택한 요소의 이름, 코드 이름, 소스 코드, 현재 상태가 표시된다.

2. 주석으로 수정 지시하기

   1. 여러 카드를 선택하고 “카드 간격을 넓혀 달라”거나 그래프를 선택해 “도넛 차트 스타일로 바꿔 달라”고 주석을 단다.
   2. 각 선택 영역에 1번·2번 같은 번호가 붙고, AI가 번호별 주석과 실제 코드 요소를 연결한다.
   3. 주석을 확인해 반영하면 양방향 호출로 UI가 수정된다.
   4. 반영이 끝난 요소에는 체크 표시가 생기며, 완료된 주석은 삭제할 수 있다.

8.3. 시각 언어를 만드는 프롬프트

1. 대시보드는 비언어적 결과물이다

   1. 최종 대시보드는 숫자·카드·그래프·메뉴로 표시되는 비언어적 인터페이스다.
   2. 그러나 원하는 시각 구조를 만들려면 사람이 자연어로 메뉴·데이터·관계를 정확히 설명해야 한다.

2. 필요한 기초 역량

   1. 프롬프트 엔지니어링(prompt engineering)으로 원하는 작업과 출력 형식을 지시한다.
   2. 컨텍스트 엔지니어링(context engineering)으로 AI가 읽어야 할 업무 맥락과 파일을 구성한다.
   3. 결과가 막혔을 때 어디까지 설명하고 어떤 자료를 보충해야 하는지 판단하는 능력이 중요하다.

9. 비용·알림·운영 선택

9.1. 사용량과 구독 비용

1. 개발과 업무의 비용 차이

   1. 발표자는 프로젝트를 개발할 때 Claude Max 계정 두 개를 사용했다.
   2. 그러나 평상시 개발이 아닌 업무 자동화에서는 여러 에이전트를 돌려도 Claude Max 한 계정으로 충분하다고 말한다.
   3. Codex는 현재 구독하지 않고 있으며, 도구를 많이 연결하는 것보다 실제 업무량과 사용량을 기준으로 선택한다.

2. Heartbeat의 토큰 비용

   1. OpenClaw나 Hermes의 heartbeat는 트리거를 기다리는 동안 데몬과 훅을 계속 실행한다.
   2. 이 방식은 자동화에는 편리하지만 트리거가 오기 전에도 토큰을 소모할 수 있다.
   3. 발표자는 일정과 리마인더에는 Notion의 모바일 푸시 알림을 사용해 불필요한 heartbeat 비용을 줄인다.

9.2. 자동화와 알림의 분리

1. 일정은 Notion에서 알림

   1. 업무 일정을 Notion에 등록한다.
   2. 에이전트는 일정에 리마인드 정보를 넣고, 실제 알림은 Notion 앱이 휴대폰 푸시로 보낸다.
   3. 에이전트가 계속 대기하는 대신 이벤트가 확정된 시스템에 알림을 맡긴다.

2. 도구 선택의 기준

   1. AI가 잘하는 실행과 외부 서비스가 잘하는 알림·인증·데이터 저장을 분리한다.
   2. 모든 기능을 에이전트가 직접 수행하게 만들면 구조와 비용이 불필요하게 커질 수 있다.

10. AI 시대의 경력과 도메인 지식

10.1. 경력자의 레버리지

1. 기존 경험이 AI 활용도를 높인다

   1. 발표자는 디자인·사업·브랜드·상품·비즈니스 모델 경험이 AI 업무 구조를 설계하는 데 도움이 됐다고 말한다.
   2. 도메인 지식이 있으면 AI에게 무엇을 시킬지, 어떤 결과가 이상한지, 어떤 판단을 사람이 해야 하는지 알 수 있다.
   3. 경력이 긴 사람 중에는 AI를 활용해 오히려 연봉과 생산성을 높이는 사례가 많다고 설명한다.

2. 신입이 겪는 진입 장벽

   1. 발표자는 미국에서 신규 채용이 거의 없다는 이야기를 소개하며, 그 이유로 신입이 도메인 지식을 갖기 어렵다는 점을 든다.
   2. AI 도구를 잘 다루는 것만으로는 어떤 업무를 시켜야 하는지, 결과를 어떻게 검증해야 하는지 알기 어렵다.
   3. 따라서 AI 시대에는 도메인 지식과 업무를 구조화하는 능력이 더 중요해질 수 있다.

10.2. 지금 시작해도 늦지 않다

1. AI를 아직 깊게 배우지 못한 사람도 업무 기억·파일 구조·자동화부터 작은 단위로 시작할 수 있다.
2. 발표자는 “오늘이 가장 빠른 시기”라는 메시지로 학습을 미루지 말라고 강조한다.
3. 처음부터 완성된 멀티 에이전트 시스템을 만들기보다 반복되는 한 업무를 파일·스킬·자동화로 바꾸고 점차 확장하는 접근이 현실적이다.

주요 발언 모음

“실행은 AI가 하고 판단은 사람이 하는 겁니다.”

“멀티 에이전트를 왜 사용하려고 하시냐부터 여쭤 봅니다. 사실상 목적이 먼저 있어야 돼요.”

“컨텍스트 윈도우는 제 책상의 크기입니다.”

“압축을 반복하면 복사본을 계속 복사하는 것처럼 나중에 맥락이 날아갑니다.”

“옵시디언 자체가 아니라 폴더 구조만 잘 짜도 AI의 기억을 늘릴 수 있습니다.”

“모델들이 좋아질수록 그 좋은 성능에 맞는 하네스가 필요합니다.”

“오늘이 가장 빠른 시기입니다. 절대 늦었다고 생각하지 마세요.”

핵심 데이터 & 수치

• 15~30분/일: 세션이 기억하지 못하는 내용을 다시 설명하는 데 쓰는 시간의 예시.
• 약 250일/년: 발표자가 업무일 계산에 사용한 연간 근무일 수.
• 약 42시간/년: 하루 10분의 재설명을 1년간 반복했을 때의 누적 시간.
• 약 125시간/년: 하루 30분의 재설명을 1년간 반복했을 때의 누적 시간.
• 약 250시간/년: 하루 60분의 재설명을 1년간 반복했을 때의 누적 시간.
• 1M 토큰: 시연에서 설명한 Claude Code 컨텍스트 윈도우 예시.
• 80%: 자동 압축 전에 발표자가 의도적인 compact를 실행하는 기준.
• 약 3회: 한 세션을 압축한 뒤 clear로 초기화하는 발표자의 운영 기준.
• 약 4시간: 에이전트 비활성 후 저빈도 기억 정제를 시작하는 기준.
• 약 10명: 대시보드에 상주하는 에이전트 수의 시연 예시.
• 30명: 라이브 대시보드 생성 시 설정한 직원 수.
• 8/10: 시연 화면에 표시된 전체 일정의 완료 예시.
• 500건: 리뷰 크롤링·분석 자동화의 예시 작업량.
• 약 200달러/월: Claude Max를 포함해 발표자가 업무 자동화 비용을 설명한 수준.
• 3210번 포트: 시연한 로컬 대시보드가 실행된 포트로 자막에 인식된 값.
• 157명: 웨비나 종료 무렵 확인된 참가자 수.
• 약 20분: 예정 시간보다 길어진 웨비나 진행 시간.

결론 및 시사점

1. AI를 도입하고도 일이 줄지 않는다면 먼저 모델을 바꾸기보다 재설명·검색·도구 전환·검토 병목을 측정해야 한다.
2. AI의 기억은 한 번의 긴 세션에 맡기지 말고, 원본·현재 작업·대화록·로그를 폴더와 Markdown 파일로 영속화해야 한다.
3. 컨텍스트가 차기 전에 최신 작업을 중심으로 의도적으로 압축하고, 반복 압축을 제한한 뒤 새 세션으로 초기화해야 한다.
4. 멀티 에이전트는 목적과 업무 분리가 있을 때만 사용한다. 역할별 세션과 지식 경계를 먼저 설계한다.
5. 에이전트의 실행 권한이 커질수록 사람의 승인·판단·원본 보존·검증 지점은 더 명시적으로 남겨야 한다.
6. 대시보드는 AI 채팅을 예쁘게 보여주는 화면이 아니라 메일·일정·업무·지식·에이전트·자동화·토큰 사용량을 연결하는 운영 계층이다.
7. Obsidian은 유용한 인터페이스이지만 필수 조건은 아니다. 이식 가능한 폴더 구조와 Markdown, 검색 지도(index)가 더 본질적이다.
8. 기억이 많아지면 삭제 대신 활성 기억과 보관 기억을 나누고, 최근 사용 빈도와 태그로 검색 순서를 조정해야 한다.
9. UI 인스펙터처럼 반복되는 수정 작업은 스킬로 제품화하면 AI와 사람이 협업하는 마찰을 줄일 수 있다.
10. 도메인 지식을 가진 사람은 AI에게 무엇을 시킬지와 결과를 어떻게 판단할지 알기 때문에 AI 시대에 더 큰 레버리지를 얻을 수 있다.

핵심 요약 (20줄)

1. AI를 쓰면 생산성은 올라가지만 세션 기억 단절과 도구 전환 때문에 컴퓨터 앞의 시간도 늘어날 수 있다.
2. 하루 10분의 재설명만 반복해도 1년에 약 42시간이 사라진다.
3. AI 기억을 유지하려면 대화 세션 밖에 업무 상태와 결과를 저장하는 기억 저장소가 필요하다.
4. 컨텍스트 윈도우는 AI가 작업할 수 있는 책상 크기이며, 문서와 대화가 쌓이면 자동 압축이 일어난다.
5. 자동 압축은 중요한 맥락을 약화할 수 있으므로 컨텍스트 80% 부근에서 의도적으로 정리하는 편이 안전하다.
6. 최신 업무에 높은 가중치를 두고 과거 업무의 가중치를 낮추는 압축 프롬프트를 단축어로 등록할 수 있다.
7. 한 세션을 여러 번 압축하면 정보가 흐려질 수 있으므로 약 세 번 뒤 세션을 초기화하고 파일에서 이어간다.
8. 멀티 에이전트는 멋있어 보이기 위해 쓰는 기능이 아니라 업무 맥락을 분리하기 위한 수단이다.
9. Pepper·기획·개발·마케팅·리서치·영업·재무처럼 역할을 나누면 에이전트별 책임과 지식 경계가 분명해진다.
10. 실행은 AI가 하고 중요한 저장·압축·승인·비즈니스 판단은 사람이 맡아야 한다.
11. 발표자의 로컬 대시보드는 토큰, 업무, 진척률, 메일, 일정, 에이전트, 자동화를 한 화면에 모은다.
12. Gmail·Google Drive·Notion·Calendar를 연결하면 문서 작성부터 일정과 업무 등록까지 이어진다.
13. OCR 문서함은 PDF·이미지에서 텍스트를 추출해 거래처·계약·견적 업무와 연결한다.
14. 대시보드 스킬팩은 디자인 시스템을 재사용해 근태·매출·비용 같은 업무 화면을 빠르게 생성한다.
15. 실제 대시보드는 UI보다 UX를 먼저 설계하고, 도메인 지식과 데이터 연결을 반영해야 한다.
16. 반복 리뷰 수집과 소셜 콘텐츠 검색처럼 입력과 출력이 명확한 업무는 자동화 후보가 된다.
17. 기억은 활성 데이터와 보관 데이터로 나누고, 4시간 이상 사용하지 않은 저빈도 기억을 정제할 수 있다.
18. 에이전트는 폴더 안의 메일함과 인박스·아웃박스를 통해 서로 작업을 전달하는 루프를 만들 수 있다.
19. 모델이 진화할수록 기존 스킬과 하네스도 행동 변화에 맞춰 계속 수정해야 한다.
20. AI 시대의 핵심 경쟁력은 도구를 많이 구독하는 것이 아니라 도메인 지식과 업무 구조화·판단 능력을 결합하는 것이다.

관련 자료

• 스킬팩·UI 인스펙터 공유 안내: https://open.kakao.com/o/p8e9zfbi
• 강의 안내: https://fastcampus.co.kr/biz_online_efficient