YouTube2026-03-26·빌더 조쉬 Builder Josh

오픈클로를 통해 회사의 모든 워크플로우를 100% 바꿔버린 AI 네이티브 컴퍼니 (GPTers 김태현, 송다혜님)

오픈클로를 중심으로 에이전트를 팀의 상시 운영 주체로 붙여 두면, 반복 운영 실무를 사람에게서 떼어내고 문서·메모리·스킬·로그를 조직 자산으로 축적하는 방향으로 회사의 워크플로우를 재설계할 수 있다는 사례다.

원문/원본: https://youtu.be/vatxcwaxuwg기존 공개 버전: pogovet.com

🎬 오픈클로를 통해 회사의 모든 워크플로우를 100% 바꿔버린 AI 네이티브 컴퍼니 (GPTers 김태현, 송다혜님)

▶️ 유튜브

원본 링크: https://youtu.be/vatxcwaxuwg?si=H8h-LyrU6Qoh2bb1

🖼️ 4컷 인포그래픽

💡 한 줄 결론

📌 핵심 요점

이 사례의 출발점은 소수 인력이 수백 명 규모의 커뮤니티·스터디 운영을 감당하면서, 더 중요한 학습 경험 설계보다 반복 실무에 끌려다니는 병목을 해소하려는 문제의식이었다.
발표자들은 기존 자동화가 일부 업무를 줄여 주기는 했지만, 특정 사람이 만든 로직과 개인 로컬 맥락에 묶여 팀 전체가 함께 쓰기 어렵다는 한계가 있었고, 이를 해결하기 위해 팀원이 공통 맥락을 호출할 수 있는 상주형 에이전트 체계가 필요했다고 설명한다.
실제 운영에서는 슬랙 채널별 맥락을 기반으로 대시보드 생성, 문자 발송, 이벤트 생성, 랜딩페이지 수정, LMS 반영, 에어테이블 갱신 같은 업무를 자연어 요청으로 연결하며, 에이전트가 답변형 보조를 넘어 실행형 운영 도구로 쓰인다고 소개된다.
단일 에이전트만 늘리면 결국 사람이 다시 관리 병목이 되기 때문에, 발표에서는 사수·부사수 구조, 상위 비서형 에이전트, 리뷰·인수인계·업무일지·내부 규칙 문서까지 포함한 멀티 에이전트 오케스트레이션으로 확장한 경험을 강조한다.
다만 이런 AI 네이티브 운영이 성립하려면 문서화와 로그 축적, SSOT 정리, 데이터베이스·API 같은 접근 가능한 인프라, 권한 분리, 토큰 사용 지원, 팀 차원의 공유 툴킷이 함께 갖춰져야 하며, 단순히 도구만 도입한다고 바로 재현되지는 않는다고 말한다.

🧾 결론

이 영상은 “AI를 잘 쓰는 사람 한 명”의 사례보다, 에이전트를 조직 운영 체계 안에 어떻게 상주시킬 것인가에 초점을 둔 실전 운영 사례로 읽힌다.
핵심 변화는 자동화 자체보다도, 개인 머릿속과 로컬 환경에 갇혀 있던 업무 맥락을 팀이 함께 호출하고 수정하고 축적할 수 있는 형태로 전환했다는 점이다.
발표 내용상 오픈클로는 단순 챗봇이 아니라, 슬랙·LMS·데이터베이스·메시징·대시보드·문서 체계를 연결해 반복 운영을 실행하고 기록하는 운영 레이어로 활용된다.
동시에 발표자들은 메모리 혼선, 중복 문서, 낡은 지침, 민감정보 노출 위험, 데이터 미정리 상태 같은 문제도 함께 언급하며, AI 네이티브 전환이 깔끔한 성공담만은 아니었다는 점을 드러낸다.
따라서 이 사례의 메시지는 “에이전트를 붙이면 다 된다”가 아니라, 문서 구조·권한 설계·로그 축적·공유 가능한 스킬 생태계까지 포함해 조직 운영 방식을 바꿔야 실질적 효과가 난다는 데 가깝다.

📈 투자·시사 포인트

생산성 툴 관점에서 보면, 향후 경쟁력은 개별 모델 성능보다도 회사의 실제 SOP, 운영 맥락, 로그, 데이터 접근권한을 얼마나 안전하게 연결해 에이전트가 실행 가능한 상태로 만들었는지에서 갈릴 가능성을 시사한다.
협업 소프트웨어 관점에서는 슬랙, 리니어, 노션, DB, 메시징, LMS처럼 흩어진 업무 표면을 에이전트 중심 워크플로우로 재편하려는 수요가 커질 수 있으며, 이를 지원하는 SSOT·오케스트레이션·감사로그 계층의 중요성이 커져 보인다.
보안 측면에서는 CS 전용 에이전트와 내부 데이터 접근 에이전트를 분리한 사례처럼, 에이전트 확산이 진행될수록 권한 최소화·워크스페이스 분리·민감정보 차등 접근이 핵심 설계 원칙으로 부상할 가능성이 높다.
조직 변화 관리 측면에서는 “직원이 새 툴을 열심히 배워야 한다”보다 “에이전트가 사람의 학습 부담을 대신 흡수해야 한다”는 관점이 제시되며, AI 전환의 병목이 기술보다 사람과 운영설계에 있다는 점을 보여준다.
다만 전사 확산은 아직 초기이고, 일부 베스트 케이스와 높은 개인 몰입, 충분한 토큰 지원, API 인프라가 전제였다고 발표자들이 직접 선을 그은 만큼, 이 사례를 모든 조직에 바로 일반화하는 것은 검증이 더 필요하다.
특히 비용 대비 효과, 실제 인력 감축이 아니라 역할 재배치로 얼마나 이어졌는지, 장기적으로 운영 리스크를 얼마나 줄였는지는 영상 요약 정보만으로는 단정하기 어렵고 추가 사례 검증이 필요하다.

🧩 배경과 문제 정의

지피터스는 소수 운영 인력으로 수백 명 규모의 AI 스터디·커뮤니티를 운영하는 과정에서, 학습 경험 설계나 커뮤니티 개선보다 반복적인 운영 실무에 더 많은 시간을 빼앗기는 병목을 겪은 것으로 정리된다.
기존에도 자동화 도구를 활용해 일부 업무를 줄였지만, 자동화 로직을 설계한 사람만 다루기 쉬웠고 맥락이 개인 로컬 환경에 묶여 있어 팀 전체가 함께 활용하기 어려운 한계가 있었다.
이 때문에 특정 개인의 작업을 보조하는 수준을 넘어, 팀원 누구나 동일한 맥락을 공유한 채 에이전트를 호출하고 업무를 맡길 수 있는 상주형 에이전트 체계가 필요해진 흐름으로 보인다.
또한 단일 에이전트를 늘리는 방식만으로는 결국 사람이 다시 관리 병목이 될 수 있어, 에이전트가 다른 에이전트를 관리·리뷰·인수인계하는 다중 에이전트 구조까지 확장하려는 문제의식이 드러난다.
후반부 논의에서는 이런 변화가 단지 운영 효율화에 그치지 않고, 조직 전체를 AI 네이티브하게 바꾸기 위해 필요한 공통 작업 환경, 문서화, 단일 원천 정보, 권한 분리, 인프라 투자 문제로까지 이어진다.
다만 전사 확산은 아직 초기 단계로 묘사되며, 실제 재현을 위해서는 데이터 정비, API 연결, 비용 부담 없이 실험할 수 있는 토큰 지원 같은 조건이 필요하다는 점도 함께 제시된다.

🕒 시간순 섹션별 상세정리

운영 사례가 먼저 튀어나오는 도입부 [00:00]

별도 채널에서 에이전트에게 대시보드 생성, 링크 발송, 문자 전송 같은 일을 시키고 실제로 실행되게 한 사례가 먼저 제시된다.
최근에는 커뮤니티 기여자 관련 업무나 인수인계까지 에이전트에게 맡긴 사례가 언급되며, 단순 보조가 아니라 운영 전반으로 역할이 넓어졌음을 보여준다.
에이전트끼리 리뷰를 주고받는 장면까지 소개되며, 사람 한 명이 모든 흐름을 직접 통제하지 않아도 되는 방향이 암시된다.

오늘 대화의 두 축을 제시함 [00:41]

진행자는 오늘 주제를 오픈클로와 AI 네이티브 팀 구성이라는 두 가지 축으로 정리한다.
지피터스 대표와 실무 운영 담당자가 함께 참여해, 도구 자체와 실제 조직 운영 변화까지 같이 다룰 흐름이 잡힌다.
단순 기능 소개보다 실제 팀 운영 실험과 그 배경을 듣는 자리라는 성격이 선명해진다.

송다혜의 역할과 운영 자동화 문제의식 [01:06]

송다혜는 커뮤니티와 AI 스터디 총괄 운영을 맡고 있으며, 가장 큰 관심사를 운영 실무 자동화에 두고 있다고 설명한다.
절감된 시간을 다시 커뮤니티 설계와 더 본질적인 고민에 쓰고 싶다는 방향이 강조된다.
이어 지피터스가 최신 AI 트렌드를 함께 공부하고 사례를 나누는 학습 커뮤니티라는 점이 소개되며, 운영 복잡도가 높은 환경임이 드러난다.

김태현 소개와 교육·커뮤니티 결합 맥락 [01:53]

김태현은 지피터스와 지니파이를 함께 운영하며, 커뮤니티와 AI 스터디·교육을 결합해 운영하고 있다고 설명한다.
원래 소프트웨어 프로덕트를 만들던 배경이 있어, 교육 서비스 운영 또한 새로운 도전으로 받아들이고 있다는 맥락이 붙는다.
기술적 사고를 가진 사람이 교육·커뮤니티 운영으로 들어오면서 자동화와 시스템화 문제를 자연스럽게 붙잡게 된 배경으로 읽힌다.

오픈클로를 도입하게 된 직접적 이유 [02:16]

한 기수에 400~500명 정도가 들어오는 운영을 두 사람이 감당하면서, 본래 목표였던 학습 경험 개선보다 운영 업무에 끌려다니는 상황이 핵심 문제로 제시된다.
기존에도 다른 자동화 도구로 상당 부분 정리해 두었지만, 로직을 짜는 사람 중심으로만 유지되고 팀 전체가 공동 운영하기 어렵다는 한계가 있었다.
또 개인 로컬 컴퓨터에 맥락이 묶여 있어 다른 팀원이 같은 문맥을 쉽게 이어받지 못하는 문제가 있었고, 그 고민에서 상주형으로 맥락을 공유할 수 있는 오픈클로가 출발했다고 설명한다.
결과적으로 팀원 누구나 에이전트를 불러 일을 시키거나 축적된 맥락을 물어볼 수 있게 된 점이 변화의 핵심으로 정리된다.

슬랙 채널 기반으로 업무를 맡기는 운영 방식 [03:28]

슬랙 채널별로 서로 다른 팀의 맥락을 나눠 사용하면서, 마케팅 현황을 묻거나 전략에 따라 랜딩페이지 수정까지 요청하는 식으로 운영된다고 설명한다.
스터디 운영에서는 미달 신청자 추적 후 문자 발송, 이벤트 생성, 썸네일 제작 등 연속된 업무를 자연어 요청으로 처리하는 사례가 나온다.
대표가 매출 지표가 필요할 때도 담당자를 거치지 않고 에이전트를 직접 호출해 활용하는 방식으로 바뀌었다고 말한다.
사람에게 매번 의존하던 요청이 에이전트 호출로 대체되면서, 실무 병목의 위치가 달라졌음을 보여준다.

LMS·데이터베이스·메시징까지 이어지는 실무 자동화 [04:19]

LMS에서 공지방, 일정, 캘린더 같은 접근 요소를 더 잘 보여주기 위한 개선 아이디어를 에이전트가 먼저 제안하고, 사람이 선택하면 에어테이블 생성이나 LMS 반영까지 이어지는 흐름이 소개된다.
학습 시스템의 일정 노출 문제나 코드 수정, 캘린더 URL 처리 등 운영과 개발의 경계에 있는 작업도 맡기고 있는 것으로 보인다.
별도 채널에서는 파트너스 기여 인정 관리, 대시보드 제작, 링크 발송, 문자 발송까지 이어지는 데이터 기반 운영 작업이 수행된다.
단순 답변형 에이전트가 아니라 DB 적재, 현황판 구성, 외부 발송까지 연결되는 실행형 운영 도구로 쓰이고 있다는 점이 드러난다.

실시간 대응과 다중 에이전트 구조로 확장 [05:30]

웨비나 신청자 알림 문구 수정이나 긴급 리마인드 발송처럼, 기존 자동화 로직으로는 중간 개입이 어려운 상황도 슬랙에서 한마디로 재지시할 수 있게 됐다고 말한다.
특정 금액 쿠폰 발급처럼 원래는 복잡한 조건 처리와 문자 발송이 필요한 작업도 자연어 요청으로 최종 발송까지 이어지는 사례가 나온다.
이후 대화는 단일 에이전트 소개를 넘어, 비서 역할의 상위 에이전트가 스터디 운영 에이전트를 키우고 리뷰·인수인계·최종 검토까지 담당하는 계층 구조로 이동한다.
운영 에이전트는 매일 업무일지를 쓰고 콘텐츠를 발행하며, 상위 에이전트에게 리뷰를 받아 품질을 올리는 피드백 루프를 돌리고 있다고 설명한다.
텔레그램에서는 잘 보이지 않는 에이전트 간 대화를 별도 대시보드에서 볼 수 있게 해, 내부 판단 과정까지 관찰하고 개선 포인트를 찾으려는 의도가 드러난다.

내부 대화를 관찰해 협업 방식 비교를 시작한 계기 [10:00]

단순히 상하 관계만 부여해 일을 처리시키는 방식과, 에이전트끼리 실제로 대화하며 협업하는 방식 중 무엇이 더 효과적인지 비교하려는 문제의식이 생긴다.
그 차이를 판단하기 위해 에이전트들의 내부 대화를 직접 들여다보게 되었고, 이것이 이후 구조 설계의 출발점이 된다.

싱글 에이전트에서 멀티 구조로 넘어간 이유 [10:15]

처음에는 개인 업무를 추적하고 보조하는 단일 에이전트부터 시작했지만, 점차 팀원들도 함께 호출해 쓰는 방향으로 확장된다.
각 에이전트에 대략적인 역할만 나눠 준 상태에서는 결국 사람 본인이 두 에이전트를 모두 관리해야 했고, 그 관리자가 다시 병목이 되는 문제가 발생한다.
이 지점에서 에이전트가 에이전트를 관리하거나 조율할 수 있는 오케스트레이션 구조를 실험하게 된다.

사수·부사수 구조와 협업 규칙의 자율 생성 [11:09]

한 에이전트를 사수, 다른 에이전트를 부사수처럼 두고 협업시키는 실험을 하면서, 이들이 함께 일하려면 내부 규칙이 필요하다는 판단이 생긴다.
사람은 세부 규칙을 직접 쓰지 않고, 서로 가장 잘 협업할 수 있는 방식으로 문서와 내규를 스스로 만들라고 지시한다.
보고 체계 역시 한쪽만 사람에게 보고하고 다른 쪽은 내부 조력에 집중하도록 구분해, 불필요한 직접 개입을 줄이는 방향으로 설계된다.

에이전트 팀 문서화와 세션 기반 대화 규칙 정착 [11:58]

협업 문서에는 역할 분담, 보고 방식, 문서 저장 위치, 핵심 가치 같은 항목이 정리되며 팀 운영의 기준점이 된다.
에이전트끼리 대화할 때는 특정 세션 기반 호출 방식으로만 상호작용해야 실제 트리거가 된다는 운영 규칙도 포함된다.
시행착오가 생길 때마다 사람은 정답을 직접 쓰기보다, 너희가 가장 잘 협업할 수 있는 방식으로 지침을 갱신하라고 요구한다.
그 결과 에이전트 간 대화 자체가 항상 공동 문서를 참고하는 형태로 고정된다.

계획보다 필요가 먼저였던 초기 세팅 방식 [13:04]

전체 구조를 미리 설계한 것이 아니라, 당장 업무를 도와야 한다는 필요 때문에 먼저 시작하고 이후에 구조를 다듬는 방식으로 진행된다.
기존에 쌓여 있던 노션 문서와 맥락 자료를 읽게 한 뒤, 에이전트가 스스로 이해하기 좋은 폴더 구조를 짜도록 맡긴다.
운영 정보, 진행 현황, 마케팅 현황처럼 실제 업무 흐름을 반영한 구조가 에이전트 주도로 정리되면서 초기 작업 공간이 형성된다.

메모리 체계가 섞이면서 발생한 혼선 [14:08]

날짜별 단기 메모리와 장기 메모리 같은 구조는 있었지만, 에이전트가 무엇을 어디에 저장해야 하는지 기준이 불명확했던 것으로 보인다.
어떤 배움은 장기 기억에, 어떤 것은 일일 메모에, 또 어떤 것은 규칙 문서나 툴 사용 문서에 흩어져 저장되면서 정보 위치가 일관되지 않게 된다.
처음에는 찾아오기만 하면 괜찮아 보일 수 있지만, 나중에 요구사항이 바뀌거나 기존 지침을 수정해야 할 때 충돌이 생기기 쉬운 구조였다는 점이 드러난다.

문서 재배치와 중복 제거로 일관성 회복 [15:00]

동일한 내용이 메모리, 툴, 규칙, 파이프라인 문서 여러 곳에 퍼지면 에이전트가 이전 방식과 새 방식을 혼용하며 비일관적으로 행동하게 된다.
이를 해결하기 위해 각 문서가 왜 필요한지부터 다시 정리하고, 전체 문서를 재배치하라는 요청을 한 적이 있다고 설명한다.
특히 파이프라인이 스킬로 굳어진 뒤에도 예전 문서가 남아 있으면 혼란이 커지기 때문에, 중복과 낡은 지침을 점검해 대폭 줄인 경험을 언급한다.
무엇을 기억으로 둘지, 무엇을 툴 규칙으로 둘지, 무엇을 러닝 폴더에 둘지 초기에 구분해 두는 것이 품질을 좌우하는 핵심이라는 교훈이 제시된다.

동시 작업, 데이터 처리, CS 자동화로 확장된 실무 범위 [16:21]

구조가 안정된 뒤에는 에이전트가 여러 세션을 동시에 처리할 수 있게 되었고, 자동화 데이터 처리 같은 반복 업무도 맡기고 있다.
문자 발송, 에어테이블 기반 데이터 갱신, 쿠폰 발급, 멤버십 연장처럼 운영성 업무가 이미 다수의 스킬로 정리되어 있다고 말한다.
게시판 가입 인사와 Q&A 응답도 자동화해, 사람이 계속 상주하지 않아도 기본적인 커뮤니티 응대가 돌아가도록 만든다.
다만 잘못 나가면 안 되는 정보는 사람이 검토하도록 초안 작성 후 승인받는 흐름을 남겨, 완전 자동화와 통제 사이 균형을 잡는다.

민감 정보 분리와 안전한 CS 전용 에이전트 설계 [18:10]

거의 모든 CS가 자동화되는 수준까지 갔지만, 결제 정보 같은 민감 데이터까지 하나의 에이전트가 모두 보게 되면 인젝션 등 보안 이슈가 생길 수 있다는 우려가 나온다.
이를 막기 위해 외부 응대 전용 에이전트를 따로 만들고, 중요한 내부 데이터는 보지 못한 채 CS에 필요한 범위만 조회할 수 있도록 별도 워크스페이스를 구성한다.
자동화 확대만큼 권한 분리와 데이터 접근 최소화가 중요하다는 운영 원칙이 이 구간에서 분명해진다.

회의 분석과 브리핑 자동화의 고도화 [18:51]

판매 현황 브리핑, 줌 회의 생성, 회의 종료 후 설명 수집 같은 정기 운영 업무까지 에이전트가 담당하도록 확장된다.
줌 API로 설문 데이터를 가져오는 수준을 넘어서, 보이스 투 텍스트 파일과 교차 분석해 부정적 피드백의 원인까지 추적하려는 방식이 소개된다.
예를 들어 홍보가 많았다는 평가가 나오면 실제 발화 기록을 함께 대조해 어느 지점이 그렇게 느껴지게 했는지 해석해 보고하는 흐름으로 발전한다.
과거에는 단순 요약이나 최소한의 모니터링 정도만 가능했다면, 이제는 그때그때의 운영 맥락을 반영한 분석 보고가 가능해졌다는 변화가 강조된다.

인수인계 병목을 대신 받은 에이전트 [20:00]

신규 입사자가 원래는 사람에게 받아야 할 인수인계를 에이전트에게 질문하면서 해결한 사례가 나온다.
그 결과 주말에 직접 응대해야 하던 일이 줄어들었고, 특정 담당자에게 몰리던 질문 부담도 완화된 것으로 보인다.
에이전트가 단순 검색이 아니라 실제 업무 문맥을 이어받는 보조자처럼 작동했다는 점이 사례의 핵심으로 드러난다.

문서화·로그 축적이 선행 조건이라는 질문 [20:39]

진행자는 이런 운영을 따라 해보고 싶은 사람들을 위해 무엇을 먼저 갖춰야 하는지 묻는다.
모든 트랙을 기록하고, 특정 브랜치나 작업 흐름에 계속 문서화를 쌓는 방식처럼 보인다고 정리한다.
슬랙 안의 대화 로그와 활동 기록까지 메모리화하는 연동 과정이 중요했을 것이라 보고, 실제 데이터 축적 방식을 구체적으로 질문한다.

개인 워크스페이스를 팀 자산으로 옮긴 이유 [21:26]

각 오픈클로 에이전트는 자기만의 워크스페이스를 가지므로, 로컬에만 저장된 문서는 사실상 본인만 볼 수 있다는 문제가 있었다고 설명한다.
팀원들과 공유하려고 워크스페이스 관련 내용을 깃 저장소로 올렸다고 말한다.
개인 환경에 갇혀 있던 맥락을 팀이 함께 볼 수 있는 자산으로 바꾸는 과정이 협업의 출발점으로 제시된다.

메모리 손실 경험이 버전 관리 필요성을 키움 [21:48]

에이전트가 메모리가 너무 길다며 내용을 갑자기 줄여 버려 맥락이 날아간 일이 있었다고 회상한다.
이 경험 때문에 되돌릴 수 있는 여지를 확보하려고 저장소 기반 관리가 필요해졌다고 설명한다.
원래는 메모리 파일을 저장소에 올리지 않으려 했지만, 가장 중요한 파일이라는 판단 때문에 다시 포함시키게 됐다고 말한다.

대시보드·업무일지·아카이브로 성장 과정을 남김 [22:29]

대시보드에서 날짜별 활동을 관리하며, 에이전트가 특정 날짜에 한 일을 메모리 기반으로 간단히 정리하게 한다고 설명한다.
여기서 끝나지 않고 업무일지를 계속 만들게 해서 누적 기록을 쌓고 있다고 덧붙인다.
이렇게 남긴 기록은 다른 사람이 참고할 수 있는 운영 사례가 되고, 어떻게 요청했고 어떤 실수가 있었으며 그것을 어떻게 완화했는지까지 아카이빙하는 목적을 가진다.
팀원들이 에이전트의 일하는 방식을 이해하는 데도 이 기록들이 도움이 된다고 본다.

자동 축적 구조와 외부 반응, 커뮤니티 확장 구상 [23:12]

진행자는 핵심 인사이트를 데이터 자산화를 자동으로 계속 쌓이게 만드는 초기 세팅, 특히 크론 같은 자동 축적 구조의 중요성으로 해석한다.
발표자는 웨비나에서 실제 사용 사례를 보여 줬더니, 단순한 사용법보다 “이런 일도 비서에게 맡길 수 있겠다”는 식의 반응이 많았다고 전한다.
오픈클로 자체의 화제성도 있었지만, 추상적 설명보다 실제 업무 흐름을 본 것이 더 큰 인사이트를 줬던 것으로 보인다.

오픈채팅 데이터로 수요를 읽고 커뮤니티 설계까지 확장 [24:29]

지피터스 공식 오픈클로 카톡방을 연 이유를, 사람들이 일상에서 어떤 비서형 도움이 필요한지 사례를 모으기 위해서라고 설명한다.
이렇게 축적한 데이터를 바탕으로 향후 어떤 주제 스터디를 열지 인사이트를 얻는 것이 첫 번째 목표라고 말한다.
두 번째 목표는 커뮤니티를 더 잘 운영하기 위한 제도와 메커니즘을 설계하는 것인데, 에이전트가 업무를 가져가 준 덕분에 그 고민을 시작할 여력이 생겼다고 한다.
에이전트가 자신보다 더 많은 스터디 맥락을 알고 있기 때문에, 멤버들에게 무엇이 필요한지 능동적으로 제안하는 조력자가 되었다고 설명한다.

조직의 AI 네이티브화는 사람의 학습 부담을 줄이는 방향 [26:12]

대화 주제는 개인 사례에서 조직 전체를 AI 네이티브하게 만드는 방법으로 넘어간다.
발표자는 사람이 많은 것을 새로 배우지 않아도, 옆에 붙은 에이전트가 일을 많이 대신해 주는 구조가 AI 네이티브 팀의 핵심이라고 본다고 말한다.
AX가 잘 안 되는 이유를 사람 쪽 병목에서 찾으며, 변화의 부담을 구성원에게 과도하게 전가하지 않는 접근을 강조한다.

에이전트 중심 운영을 위한 공통 작업 환경과 단일 원천 [27:25]

이런 구조를 만들려면 각자가 에이전트를 끼고 실제 일을 해야 하며, 예시로 클로드 코드 같은 환경 안에서 업무가 시작되어야 한다고 본다.
그렇게 되면 사람 간 커뮤니케이션의 상당 부분도 에이전트를 매개로 이뤄질 수 있고, 사람이 따로 챙기거나 배워야 할 부분을 중간의 에이전트가 대신해 줄 수 있다고 설명한다.
동시에 회사 프로젝트, 담당자, 진행 상황 같은 맥락을 담은 단일 원천 소스가 필요하다고 말한다.
코딩 지시만 수행하는 에이전트가 아니라, 회사 안의 문서화되지 않은 SOP까지 익혀 스킬처럼 재활용하게 되면 생산성이 복리처럼 커질 것이라는 관점을 제시한다.

전사 확산은 아직 초기이며 손발 API와 개인 몰입이 변수 [28:37]

진행자는 전 직원이 클로드 코드를 메인 오퍼레이션 시스템처럼 쓰는 것과, SOT·SOP를 자산화해 에이전트화하는 것이 핵심 축이라고 재정리한다.
이어서 실제로 직원들이 매일 메인 툴처럼 쓰게 만든 방법을 묻지만, 발표자는 아직 완전히 성공적이지는 않다고 선을 긋는다.
현재는 일부 구성원이 베스트 케이스에 가깝고, 그런 수준의 활용은 매우 드문 편이라고 평가한다.
다만 자동화를 위해 문자 발송, 메시지 전송, 데이터 조회 같은 손발 역할을 할 API가 준비돼 있었던 점이 큰 조건이었다고 말한다.
또 한 사례는 개인의 강한 몰입과 많은 투입이 함께 있었음을 시사하며, 단순 도구 도입만으로 재현되기는 어렵다는 뉘앙스를 남긴다.

운영 업무에서 벗어나기 위한 집요한 실험 [30:03]

운영 업무를 계속 붙들고 있던 상태에서 벗어나기 위해, 세팅을 손보며 하나씩 확인해 온 과정을 매우 고된 노력의 결과로 표현한다.
출산한 엄마가 아이를 돌보듯 계속 챙기는 마음으로 운영 체계를 붙들고 왔고, 그 끝에 운영 업무에서 자유로워질 수 있다는 기대를 함께 느꼈다고 말한다.
진행자는 많은 사람이 AI에 즉각적으로 질문하거나 바로 업무에 붙이지 못하는데, 현장에서 바로 활용하는 태도 자체가 놀랍다고 반응한다.
이런 태도가 개인 차원을 넘어 조직 전체 분위기를 바꾸는 데도 큰 역할을 했을 것이라는 평가가 이어진다.

개인 실험만으로는 넘기 어려운 데이터·인프라 한계 [30:45]

조직 내에서 시간을 더 쓰겠다는 약속만으로는 한계가 있었고, 특히 B2B 교육 쪽 데이터가 어디에 있어야 하는지조차 정리되지 않은 상태였다고 설명한다.
시트 등으로 흩어진 데이터를 데이터베이스와 API로 정돈해 접근 가능하게 만드는 작업이 아직 완결되지 않아, AI가 그 영역으로 깊게 들어가지 못하고 있다고 말한다.
이런 구조적 공백은 단순히 사람을 더 밀어붙인다고 해결되지 않으며, 먼저 데이터와 시스템을 연결하는 투자가 필요하다는 문제의식으로 이어진다.
즉각적인 자동화보다 먼저 “접근 가능한 자산”을 만들어야 한다는 현실적 제약이 드러난다.

퇴근 인터뷰와 로그 축적이 드러낸 출발점 [31:19]

다른 구성원이 오픈클로로 만든 에이전트가 퇴근 인터뷰를 진행하면서, 오늘 무엇을 했고 왜 특정 작업을 에이전트 안에서 처리하지 못했는지가 드러나기 시작했다고 말한다.
어떤 구간에서 외부 웹서비스를 써야 했는지, 왜 내부 코드 기반 자동화로 이어지지 못했는지를 확인하면서 병목이 더 구체적으로 보였다고 설명한다.
회사가 먼저 해결해야 할 연결 문제를 풀지 않으면, 개인은 결국 기존에 하던 일을 웹서비스에 옮겨 쓰는 수준에서 멈추게 된다는 판단이 나온다.
그래서 데일리 로그를 쌓고, 현재 가진 데이터를 끌어와 에이전트를 구성하는 시도 자체가 출발점이 되어야 한다는 방향으로 정리된다.

토큰 지원이 실험 속도를 바꾼 결정적 조건 [32:49]

자신이 여러 시도를 할 수 있었던 첫 번째 배경으로 회사 차원의 토큰 지원을 가장 먼저 꼽는다.
직원들이 클로드 코드나 GPT 구독을 필요한 만큼 사용할 수 있게 열어 주지 않으면, 사람들은 실험보다 비용 효율부터 계산하게 되어 시도를 시작조차 못 한다고 말한다.
반대로 “오늘 많이 써도 된다”는 허용이 있으면 영상 제작 같은 새로운 업무도 즉시 실험할 수 있고, 그 속도가 조직 학습의 동력이 된다고 설명한다.
실제로 해 보니 회사 단위에서는 인건비 대비 충분히 감당 가능한 수준일 수 있으며, 그 지원이 성장의 발판이 되었다는 인식이 드러난다.

리니어 중심 협업과 스킬 제작의 선순환 [33:39]

과거에는 슬랙과 노션에 정보가 흩어져 있었지만, 이제는 협업툴 리니어 이슈에 맥락을 남겨야 한다는 방향으로 이동했다고 설명한다.
에이전트가 자신의 업무 맥락을 이해하게 하려면 결국 스스로 문서와 기록을 제대로 남겨야 한다는 점을 체감하면서, 기록 습관이 강제된 것이 아니라 필요에 의해 내재화되었다고 말한다.
슬랙 대화를 업무 맥락이 담긴 리니어 이슈로 바꾸는 스킬을 직접 만들어 매일 사용하기 시작했고, 이것이 개인 생산성 향상을 넘는 변화의 계기가 되었다.
자신의 문제만이 아니라는 판단이 들자, 이 스킬을 다른 팀원도 쓸 수 있도록 배포해야겠다는 생각으로 확장된다.

사내 AI 툴킷과 공유 가능한 생태계 구축 [34:42]

개발자에게 단순 코딩이 아니라 조직 안에서 스킬을 쉽게 공유하고 내려받을 수 있는 생태계를 만들어 달라고 요청했고, 실제로 사내 AI 툴킷이 구축되었다고 설명한다.
자신이 만든 스킬을 툴킷 사이트에 올리면 동료가 그대로 가져다 써서 같은 방식으로 리니어 이슈를 관리할 수 있게 되었다고 말한다.
이 구조 덕분에 개인이 만든 작업 방식이 팀 차원의 성장으로 번지고, AI 네이티브 조직으로 함께 이동하는 기반이 형성되었다는 점을 강조한다.
SSOT 역시 말로만 되는 것이 아니라, AI에게 도움받기 위해 맥락을 한곳에 관리해야 한다는 실질적 필요가 조직 변화를 밀어붙였고, 그 결과 노션보다 리니어 중심 운영으로 기울었다고 정리한다.

AI 네이티브 조직을 위한 리더의 역할과 우선순위 [35:49]

진행자는 토큰 무제한 지원과 같은 정책, 그리고 팀을 하나로 묶는 도구 관리가 매우 중요해 보인다고 정리하며, 큰 결단이었다고 평가한다.
이어 앞으로의 조언으로, 코딩 에이전트 안에서 가능한 많은 작업을 하게 만드는 것이 AI 네이티브 조직의 첫 번째 조건이라고 답한다.
에이전트와 수행한 일이 로컬에 체계적으로 남으면 업무일지 작성, 정제, 회사 자산화로 이어질 수 있고, 그것이 생산성 폭증의 기반이 된다고 본다.
그래서 가장 먼저 해야 할 일은 모든 구성원이 클로드 코드 같은 환경을 쓸 수 있도록 필요한 인프라를 갖추는 것이며, 그 투자를 리더급이 감당해야 조직이 AI 네이티브해질 수 있다고 강조한다.

사례를 마무리하며 남긴 자극과 권유 [37:41]

진행자는 작은 회사를 운영하는 대표 입장에서 자신도 아낌없는 지원을 해야겠다고 받아들이며, 리더의 태도 변화로 대화를 연결한다.
이번 대화를 오픈클로 기반의 실제 AI 네이티브 팀 사례를 확인한 자리로 정리하며, 매우 우수한 사례를 만났다는 만족감을 표현한다.
시청자들에게도 자극이 되었다면 지피터스 쪽 세션을 직접 들어보는 것이 좋겠다고 권유한다.
마지막에는 촬영을 마무리하며 지피터스와 진행 채널에 대한 응원을 부탁하는 인사로 끝맺는다.

⚠️ 불확실하거나 확인이 필요한 부분

영상에서는 “오픈클로를 통해 회사의 모든 워크플로우를 100% 바꿔버린” 수준의 변화가 암시되지만, 실제로 어느 범위까지가 완전 전환되었는지, 아직 사람 검토가 남아 있는 구간이 얼마나 되는지는 추가 확인이 필요하다.
운영 자동화 사례로 문자 발송, 쿠폰 발급, 대시보드 생성, LMS 반영, CS 응대 등이 언급되지만, 각 프로세스가 실제 운영 비중에서 얼마나 큰 부분을 차지하는지 정량 수치는 transcript에 없다.
슬랙 채널별 맥락 분리, 세션 기반 호출, 멀티 에이전트 협업 규칙이 소개되지만, 구체적으로 어떤 프롬프트 구조나 문서 포맷을 쓰는지는 본문만으로는 확정할 수 없다.