스크립트
00:00:00좋습니다, 다들 보이시죠.
00:00:15안녕하세요 여러분.
00:00:17참석해 주셔서 감사합니다.
00:00:18제가 오늘 이야기할 주제는 만약 여러분이
00:00:23회사의 두뇌 역할을 하는 시스템을 구축하게 된다면,
00:00:25회사 기밀이 유출될 가능성이 높다는 점입니다.
00:00:28이것은 어쨌든 회사 두뇌를 구축할 때 우리가 갖는 가장 큰 두려움이죠.
00:00:32예를 들어 신입 사원이 회사에 들어와서
00:00:34갑자기 급여 세부 정보를 알게 되는 식의
00:00:36상황 말입니다.
00:00:37우리는 그런 상황을 경계해야 합니다.
00:00:40이것이 아마도 지금까지 우리가 OpenClaw와
00:00:43Hermes 같은 시스템을 전면적으로 배포하지 못하도록
00:00:47가로막던 가장 큰 요인이었을 겁니다.
00:00:49또한 이런 이유 때문이기도 한데요...
00:00:50며칠 전에 있었던 최근 출시에서 ClaudeTag가
00:00:52가졌던 엄청난 기회이기도 했지만,
00:00:54막상 막을 열어보니 다들 생각하기에,
00:00:56음, 이게 회사의 두뇌가
00:00:57될 것 같지는 않다는 반응이었죠?
00:01:00그렇죠?
00:01:01그래서 무엇이 이를 어렵게 만드는지 이야기해 보려고 합니다.
00:01:03본격적으로 들어가기 전에, 이 '회사 두뇌' 비즈니스를
00:01:07조금 이해하고 분석해 볼까요?
00:01:09저는 탄마이입니다.
00:01:10PromptQL의 공동 창업자이자 CEO입니다.
00:01:13나중에 PromptQL을 확인해 보셔도 좋지만, 저희 팀의 배경은
00:01:18Hustle Graph 쪽에서 왔다는 점입니다--
00:01:21저희는 Hustle GraphQL 엔진의 개발자들입니다.
00:01:23GraphQL 분야에서 매우 인기 있는 오픈 소스 프로젝트로,
00:01:26많은 데이터 액세스 문제를 해결해 왔습니다.
00:01:28Apple, Meta, JPMorgan 등 다양한 곳에 배포되었죠.
00:01:32기타 등등요.
00:01:33그 경험을 통해 저희는 많은 기반을 다질 수 있었습니다--
00:01:39데이터 및 데이터 보안에 대한 애증 관계 같은 것도
00:01:43생기게 되었고요.
00:01:44그래서 지난 1년 동안 저희가 작업해 온 내용과
00:01:51거기서 배운 점들을 여러분께 보여드려,
00:01:53여러분이 이를 활용하고 직접 실습해 보실 수 있도록
00:01:56도와드리고자 합니다.
00:01:58물론 강연이 끝난 후에는 의견을 나누며
00:02:01어떤 방식이 효과가 있고 어떤 방식이 아닐지 함께 이야기해 보면 좋겠습니다.
00:02:06지난 1년 동안 우리는 규모 면에서 어떤 급성장을 보여준
00:02:08소수의 파트너들과만 협력해 왔습니다.
00:02:12지금까지 약 15~20개 정도의 기업이죠.
00:02:15그리고 이제 다른 분들에게도 이를 개방하기 시작했습니다.
00:02:17그 과정에서 우리는 요구사항이 매우 다른
00:02:20세 가지 유형의 사용자 그룹을 살펴보았습니다.
00:02:22동작만 한다면 무엇이든 기꺼이 하려는 AI 네이티브 기업이 있고,
00:02:25작동하기만 하면 되는 식이죠.
00:02:27인스카트(Instacart) 같은 기술 선도 기업들도 있습니다.
00:02:30이들은 최고 수준의 기술(best-of-breed)을 선호하죠.
00:02:33그래서 빠르게 움직입니다.
00:02:34무언가 고장 나는 것도 어느 정도 감수하고요.
00:02:36다만 성능이 정말로 뛰어나야 하죠.
00:02:38그리고 마지막으로 포춘 100대 은행들이 있는데, 이들은 정말
00:02:41엄격한 수준의 보안을 요구합니다.
00:02:43제 은행 계좌가 거기에 있으니 그렇게 철저하다는 게 다행이죠.
00:02:45제 돈이 들어있는 곳이기 때문에 대충 코딩된 AI 에이전트가
00:02:48은행 내부에서 실행되는 일은 절대 원치 않거든요.
00:02:51그래서 이들은 보안 규칙이 매우 까다롭습니다.
00:02:54정말 감사합니다.
00:02:55하지만 저희는 그런 곳들에도 배포되어 있습니다.
00:02:59회사 브랜드의 시작점이나 전두엽 같은
00:03:01역할을 하는 곳에요.
00:03:02따라서 이러한 경험과 교훈에 대해 이야기할 수 있습니다.
00:03:05우리 스스로 회사 두뇌를 구축하며 얻은 데이터는
00:03:10대략 5,000페이지 정도 됩니다.
00:03:13저희는 이를 위키 형태로 모델링했습니다.
00:03:14여러분은 원하는 방식으로 모델링하면 됩니다.
00:03:16GitHub의 마크다운 파일 세트로 구성할 수도 있고,
00:03:17아, 그래프 프래그(graph frag) 기억하시나요?
00:03:21지식 그래프(knowledge graphs)로 모델링할 수도 있습니다.
00:03:23원하는 대로 하시면 됩니다.
00:03:25원하는 곳에 배치할 수 있죠.
00:03:27다만 저희의 경우는 약 5,000개의 상호 연결된 페이지로 구성되어 있습니다.
00:03:32여러분께 질문 하나 드리겠습니다.
00:03:33작동하는 회사 두뇌가 있다고 가정해 봅시다. 잘 작동하고 있어요.
00:03:36모든 준비가 끝났고요.
00:03:37그렇다면 이 회사 두뇌에 발생하는
00:03:40일일 업데이트 수는 어느 정도 될까요?
00:03:41이 회사 두뇌에 가해지는 업데이트는 매일 어떻게 될까요?
00:03:44회사의 모든 직원들로부터 정보를 학습하기 때문이겠죠?
00:03:47그렇죠?
00:03:47재무팀, 인사팀, 엔지니어들, 그리고 모든 이들로부터 말입니다.
00:03:52그렇다면 회사 두뇌에 일어나는 일일 업데이트 수를 그래프로 그려보면
00:03:55대략 어떤 모양새를 띨까요?
00:04:00대체로 우하향하는 추세를 보일까요?
00:04:04마치 무작위 그래프들처럼 말이죠.
00:04:05시작했다가 아래로 내려가는 형태일까요?
00:04:09아니면 업데이트가 급증함에 따라 오르내리며 안정적인 형태를 유지할까요?
00:04:12아니면 꾸준히 우상향할까요?
00:04:16공유 스킬 저장소에 대한 커밋 기록이
00:04:18어떻게 생겼을지 한번 생각해 봅시다.
00:04:21정상적으로 작동하는 회사 두뇌에는
00:04:26매일 얼마나 많은 업데이트가 발생할까요?
00:04:27그 추세는 어떤 모습일까요?
00:04:29A번 옵션에 투표하실 분 계신가요?
00:04:31A번이라고 생각하시는 분?
00:04:33알겠습니다, 좋습니다.
00:04:34B번 옵션은요?
00:04:37C번 옵션은요?
00:04:39좋습니다.
00:04:41그래서 제가 우리 데이터를 그래프로 그려보았을 때,
00:04:44정상적인 회사 두뇌가 어떤 모습인지 확인해 보기 위해,
00:04:47첫 번째 경우를 보면 기본적으로 이런 식입니다.
00:04:50처음에는 열정이 넘쳤죠.
00:04:53첫째 날과 둘째 날에 회사 두뇌를 구축했습니다.
00:04:56누군가에게 작업을 맡기면서 이렇게 말했습니다.
00:04:57모든 공유 스킬 저장소를 만들고,
00:04:59슬랙을 다 긁어모으고, 이메일도 다 긁어서 시스템을 구축해 줘,
00:05:02그럼 우리 다 같이 쓰자고요.
00:05:03그러고 나서는 아무도 신경 쓰지 않죠, 맞나요?
00:05:05아니면 자동 학습 시스템이 있을 수도 있습니다.
00:05:07어쩌면 사내에 배포된 Hermes 같은 시스템이 있을 수도 있겠네요.
00:05:09댓글이 점점 더 많이 추가되는 그런 걸 살펴보고 있었습니다.
00:05:11코멘트가 늘어나는 거죠.
00:05:12열정이 얼마나 있느냐에 따라 위아래로 오르내리기도 하고요.
00:05:14그렇죠?
00:05:15그리고 지난 두 달 동안의 우리 기록을 그래프로 그려보았을 때—
00:05:19지금은 이 데이터가 약간 지난감이 있지만—
00:05:22이러한 결과를 얻었습니다.
00:05:24저는 좀 충격을 받았어요.
00:05:26'아니, 왜 이게 계속 증가하는 거지?'라는 생각이 들었죠.
00:05:30완만한 곡선 형태이긴 한데요, 그렇죠?
00:05:32하지만 왜 부드럽게 계속 올라가는 걸까요?
00:05:34왜 하루 업데이트 횟수가 점점 늘어나는 걸까요?
00:05:38정말 흥미로운 광경이었습니다.
00:05:39제가 깨달은 것은, 만약 잘 작동하는 시스템이 있다면
00:05:42사람들이 거기에 훨씬 더 많은 것을 가르치기 시작한다는 점입니다.
00:05:46이런 식이죠. 만약 제가 여러분에게 데이터를 조회하는 기술을 가르쳐 주었다면,
00:05:50내일은 그 데이터를 해석하는 기술을 가르쳐 줄 것입니다.
00:05:53그리고 모레에는
00:05:55그에 바탕을 두고 조치를 취하는 법을 가르쳐 주겠죠.
00:05:57그고 나서는 어떻게
00:05:59A/B 테스트를 할지 알아내고요. 사람들은
00:06:00여러분처럼 계속해서 더 많은 걸 추가할 겁니다.
00:06:03하지만 모든 것이 에이전트이고 완벽한 학습이란 없으므로
00:06:05모든 것에는 저마다의 고유한 안정적인 비율이 존재하잖아요?
00:06:08그렇죠?
00:06:08그러니까 그 비율들이...
00:06:10기본적인 안정 속도 위에 계속 누적되는 것입니다.
00:06:12우리 시스템에서도 바로 그런 점을 눈치채기 시작했죠.
00:06:15아직 초기 단계라 결국 시들해질지 누가 알겠어요.
00:06:18어쩌면 B 옵션처럼 보이기 시작할지도 모릅니다.
00:06:20하지만 물론 건강한 두뇌라면 전체적인 크기는 계속해서 커집니다.
00:06:24심지어 하루 단위의 업데이트 건수마저 계속해서 늘어나게 되죠.
00:06:28그러니 그것이야말로 여러분이 잘 구축한 훌륭한 두뇌의 증거인 셈입니다.
00:06:32회사를 위해 만든 건강한 두뇌 말입니다.
00:06:35좋습니다.
00:06:36회사 두뇌의 활용 사례는 우리가 시스템을 어떻게 분석하는지
00:06:39비밀을 유출하지 않는 시스템을 구축하는지 살펴보는 방법입니다.
00:06:42자, 두 가지 활용 사례가 있습니다.
00:06:44첫 번째 활용 사례는 회사 두뇌가 존재하는 경우입니다.
00:06:48이를 내 AI, 에이전트 등에서 활용해 업무를 처리하고 싶습니다.
00:06:55그 예시를 보여드리겠습니다.
00:06:56고객으로부터 답변해야 하는 보안 설문지가
00:06:59포함된 이메일을 받았다고 해봅시다.
00:07:00그리고 저는 AI에게 말합니다. 회사 두뇌를 찾아보고
00:07:03보안 설문지에 답하는 것을 도와달라고요.
00:07:05이것이 바로 회사 두뇌의 지극히 타당한 활용 사례입니다.
00:07:08두 번째로 매우 유용한 활용 사례죠.
00:07:10다른 사람들의 지식이 내게로 들어오는 것이기 때문입니다.
00:07:14회사 두뇌의 두 번째 활용 사례는 클라우드 태그와 비슷한 개념으로
00:07:18멀티플레이어라는 개념에 가깝습니다.
00:07:21여러 사람이 상호작용할 수 있는 슬랙(Slack) 같은 곳에 에이전트를 배치해 왔다면
00:07:25그건 일종의 공유 AI로 사용해 온 셈입니다.
00:07:29업무를 처리하는 식이죠.
00:07:32그 예로 협업 기반 장애 관리 같은 것을 들 수 있습니다.
00:07:36예를 들어 이런 식으로 요청하고 싶을 겁니다. 로그를 가져와줘.
00:07:40장애가 발생했으니 조사해 줘.
00:07:42로그를 가져오고, 코드베이스를 조사하고, PR을 올리고, 스테이징에 배포하고,
00:07:46프로덕션에 배포하고, 알림을 설정해 줘.
00:07:48여러 사람이 회사 두뇌를 가지고 무언가를 하기를 원할 것입니다.
00:07:51이것이 회사 두뇌의 두 가지 활용 사례입니다.
00:07:53하나는 공유 협업 지식 활용 사례이고요,
00:07:56다른 하나는 공유 AI 활용 사례 자체입니다.
00:08:00이 두 가지 모두 엄청난 보안 문제를 안고 있습니다.
00:08:06따라서 이를 보호하기 위해 개념을 좀 더 강력하게 정의해 봅시다.
00:08:15그렇다면 회사 두뇌란 정확히 무엇일까요?
00:08:18이것은 저의 정의입니다.
00:08:20마크다운에 담아두는 공유 컨텍스트이자
00:08:23일련의 마크다운 파일에 넣어두는 내용입니다.
00:08:26또한 코딩 에이전트에 부여하고자 하는 다양한 데이터와 도구에 대한
00:08:29접근 제어 규칙이기도 합니다.
00:08:34제가 이렇게 부르는 이유는...
00:08:38제가 말하는 사람이니 제 마음대로 정의할 수 있기 때문입니다.
00:08:41그게 제 정의입니다.
00:08:42이것이 도구 호출을 수행할 LLM으로 끌어들여지는
00:08:46지식을 말하는 것은 아닙니다.
00:08:48범용적인 작업을 수행하는 AI가 아니라는 뜻입니다.
00:08:51주어지는 어떤 문제든 해결하는 코딩 에이전트인 AI를 말하는 것입니다.
00:08:56여러분이 이전에 들었을지도 모를 앞선 강연의 내용과도 약간 비슷합니다.
00:09:00즉, 코딩 에이전트를 사용하여 일반적인 문제를 해결할 수 있는가 하는 아이디어죠.
00:09:04바로 그것입니다.
00:09:05가장 사소한 경우로, 트윗을 하나 작성해 달라고 한다면 작은 트윗을 작성하는 AI 호출을 수행하는 스크립트를 짜는 것입니다.
00:09:13굳이 그럴 필요는 없을 겁니다.
00:09:14AI가 직접 여러분에게 트윗을 반환해 주면 되니까요.
00:09:17하지만 기본적으로 모든 곳에 Claude Code가 사용되는 식입니다.
00:09:20Claude co-work도 같은 아키텍처입니다.
00:09:22Codex 앱도 같은 아키텍처인데, 코딩 에이전트를 이용해 범용적인 문제를 해결할 수 있다는 깨달음에서 나온 것입니다.
00:09:28따라서 우리는 그것을 위한 두뇌를 구축하고 있습니다.
00:09:30회사를 위한 거대한 지식 그래프나 지식 베이스를 만들고 보호하려는 게 아닙니다.
00:09:34애초에 그런 방식은 통하지도 않았고, 앞으로도 통하지 않을 것입니다.
00:09:39회사 두뇌의 설계를 어떻게 접근해야 할지 관점에서 보면, 과연 회사 두뇌를 구축해야 할까요?
00:09:50만약 여러분이 대기업 직원이라 빈둥거리며 월급을 받는다면 회사 두뇌를 구축하는 이런 아이디어를 좋아할 겁니다.
00:09:57그래요, 2년짜리 프로젝트를 맡아서 J.P. 모건을 위한 회사 두뇌를 만들겠다고 나설 테니까요.
00:10:02하지만 그런 일은 일어나지 않습니다.
00:10:03100년 된 조직을 위한 회사 두뇌를 구축할 수는 없으니까요.
00:10:07겨우 몇 달이나 몇 년 된 우리 가족을 위해서조차 제대로 구축하기 힘든데요.
00:10:13따라서 회사 두뇌를 구축하는 아이디어와 방식은, 회사에서 각자 업무의 일부를 담당하는 사람들이 자신의 회사 두뇌 파트를 직접 소유하고 구축하게 하는 것입니다.
00:10:23그것이 바로 우리가 구축해야 하는 방식입니다.
00:10:25이것이 제가 제시하는 두 번째 제약 조건입니다.
00:10:27하나는 회사 두뇌의 정의였고, 두 번째는 회사 두뇌가 구축되는 방식에 대해 우리가 취하고자 하는 접근법입니다.
00:10:33저는 이런 식으로 표현하는 걸 좋아합니다. 우리는 회사 두뇌를 '구축'하는 게 아니라 '키워나갈' 것입니다.
00:10:41자연스럽게 합쳐지도록 놔둘 겁니다.
00:10:43자연스럽게 어우러지게 두는 거죠.
00:10:44시스템은 저절로 어우러져야 합니다. 그렇지 않으면 구축하는 것이 불가능합니다.
00:10:47좋습니다.
00:10:48대체로 우리는 각 사람이 회사 두뇌의 자신의 몫을 셀프 서비스로 관리할 수 있게 하기를 원하며, 이것들이 바로 여러분이 따라야 할 여러 단계입니다.
00:10:57시간이 된다면 나중에 더 자세히 다루겠지만, 우선 특정 활용 사례부터 시작해 봅시다.
00:11:03이 특정 활용 사례에서 제가 여러분에게 보여드리고자 하는 구체적인 상황은 다음과 같습니다.
00:11:12이메일을 받았는데, 보안 설문지 예시일 뿐입니다.
00:11:15스티치픽스(Stitch Fix)의 데이브로부터 이메일을 받았고, 답변해야 할 질문들이 여러 개 있습니다.
00:11:20이메일을 불러오니 보안 온보딩 스크린샷이 첨부되어 있었고, 그 질문들에 대한 답변을 하기 시작합니다.
00:11:30어떻게 알았는지 정말 영문을 모르겠습니다.
00:11:32우리의 신뢰 센터가 어떠하며 보안 시스템은 어떻게 생겼는지, 그리고 게이트웨이가 있다는 점 등에 대한 모든 질문에 답해준 것을 보고 아주 놀랐습니다.
00:11:40무언가를 해내죠.
00:11:41이 모든 것이 회사 두뇌로부터 나오는 것입니다. 그에 대한 답변인 셈이죠. 그러고 나서 진행을 이어갑니다. 좋아요, 그냥 이대로 보내죠.
00:11:50이 초안이 마음에 드니, 데이브에게 이 초안을 그대로 보내줘.
00:11:53그리고 실제로 그 이메일을 발송합니다. 제가 하고자 하는 일의 아주 단순한 예시입니다.
00:11:57자, 여기서의 난제이자 문제는 다른 사람이 기여한 내용을 제3자가 사용하는 시스템을 어떻게 구축하느냐는 것입니다.
00:12:13우리 보안에 대한 이 지식은 어떻게 들어오게 되었을까요?
00:12:18아마도 누군가 동일한 보안 설문지 작업을 하고 있었겠죠.
00:12:22그래서 그들에게는 헤르메스 에이전트 같은 게 있었을 겁니다.
00:12:24그걸 작업하고 있었던 거죠.
00:12:25메모리가 자동으로 저장되었고요.
00:12:27어쩌면 누군가 기술을 적어두었을지도 모릅니다.
00:12:28어떻게든 그 조각이 내 AI 에이전트로 전달되어야 합니다.
00:12:32어떻게 그것을 가능하게 만들 수 있을까요?
00:12:35자, 첫 번째 뻔한 방법을 시도해 봅시다. 모두가 GitHub에 서로를 위해 공유 기술을 작성해 주는 것입니다.
00:12:42보안 담당자가 처음으로 보안 설문지에 답변했을 때를 상상해 보세요. 여러분 머릿속에 보안 및 컴플라이언스 담당자의 모습이 떠오를 겁니다.
00:12:50자, 그들이 이 거대한 엑셀 시트 설문지에 답변한 후를 상상해 보세요. 설문지 답변하기는 정말 짜증 나는 일입니다.
00:12:56이 거대한 엑셀 시트 설문지에 답변을 마친 후, 그들이 GitHub에 들어가 공유 기술을 업데이트했다고 해보죠.
00:13:04여러분 중 많은 분은 우리 구세주 그리스도를 닮아 너무나 친절한 나머지 GitHub 리포지토리에 들어가 공유 기술을 업데이트해 줄 분들과 함께 일하는 행운을 누리고 계실 겁니다.
00:13:16하지만 대부분의 사람은 그렇게 하지 않습니다.
00:13:18아무도 GitHub에서 다른 사람을 위해 기술을 작성하려 들지 않습니다.
00:13:24그건 우리에게 자연스러운 행동이 아니니까요.
00:13:27일상 업무를 하다가 미래에 알지도 못하고 연결되지도 않은 누군가에게 정말 유용할지도 모른다는 이유로 갑자기 기술을 작성하겠다고 마음먹지는 않습니다.
00:13:39그런 일은 일어나지 않습니다.
00:13:40제 기억이나 문맥을 정리하는 것조차 겨우 해내는 판입니다.
00:13:44다른 사람에게 보내거나 남을 위해 기록해 둘 시간 따위는 없어요.
00:13:49둘째로, 회사 전체의 브레인을 만드는 대신 팀 브레인을 만들면 어떨까요?
00:13:53다 같이 공유 공간 하나를 쓰면 되지 않나요?
00:13:55보안팀 같은 곳에서 이런 작업을 할 수 있는 공유 사일로를 하나 더 쓰면 되는 거 아닐까요?
00:14:01즉, 에이전트를 구축해서 스스로 메모리에 저장하게 만드는 거죠.
00:14:04그리고 아마 여러분 중 많은 분들이 슬랙(Slack)에 헤르메스(Hermes) 같은 걸 더해서 그런 아키텍처를 쓰고 계실 겁니다.
00:14:09여러 사람이 함께 쓰는 AI가 메모리를 자동 저장하고 문맥을 자동 추가해 주는 팀 브레인 같은 시스템을 쓰시는 분 계신가요?
00:14:18소규모 팀 단위로 이미 그런 기능을 하는 스킬을 써보신 분 있나요?
00:14:23한 분. 또 다른 분은요? 알겠습니다.
00:14:24몇 분 정도 계시네요. 좋습니다.
00:14:26좋긴 한데, 여전히 격리되어 있어서 완전한 회사 브레인이라고 할 수는 없다는 게 문제입니다.
00:14:31사일로가 하나 더 늘어나는 셈이죠. 예를 들어 클로 태그(claw tag) 같은 걸 쓰면 채널별 메모리가 생기거든요.
00:14:40채널마다 저장되긴 하지만, 결국 그 특정 채널 안의 또 다른 사일로가 되는 겁니다.
00:14:46결과적으로 다른 곳에서는 쓸 수 없고 한곳에 갇혀버리게 되죠.
00:14:50누가 그 채널에 새로 추가되면 작동하겠지만, 그렇지 않으면 소용이 없습니다.
00:14:55그래서 세 번째 대안이 나옵니다.
00:14:59세 번째 옵션은 모든 문맥을 단 하나의 공유 위키에 집어넣는 것입니다.
00:15:06위키란 마크다운 파일들의 집합이며, 마크다운 파일들은 서로 링크로 연결될 수 있습니다.
00:15:08아주 거대한 폴더를 상상해 보세요.
00:15:10그 폴더 안에는 수많은 마크다운 파일이 들어 있겠죠.
00:15:13그리고 마크다운 파일들은 서로를 참조할 수 있습니다.
00:15:16따라서 모든 문맥을 이리저리 폴더에 분산시키거나 사일로에 가두는 대신에,
00:15:21마크다운 파일에, 마크다운 파일과 다름없는 곳에 담고
00:15:25서로 링크되도록 내버려 두는 겁니다.
00:15:28두 번째로 할 일은 각 파일마다 접근 권한 범위를 설정하는 것입니다.
00:15:33해당 파일에 대해 누가 읽고 쓸 수 있는지 범위를 지정하는 거죠.
00:15:38그리고 세 번째이자 가장 중요한 조치가 있습니다.
00:15:42에이전트가 메모리를 자동으로 추가하게 내버려 두지 않는 것입니다.
00:15:49자동으로 추가하게 두면 어떤 일이 일어났는지 전혀 알 수가 없거든요.
00:15:55결국 원점으로 돌아가서, 무언가가 무작정 추가되고
00:16:00그 에이전트의 메모리 범위 안에 운 좋게 속해 있기만을 바라는 예전과 다를 바 없어집니다.
00:16:04그래서 세 번째로 해야 할 일은 에이전트가 알아서 추가하게 하는 대신에,
00:16:07어떤 내용을 어떤 권한 범위로 추가하면 좋을지 에이전트가 제안하게 만드는 것입니다.
00:16:16그런 다음 사람이 그것을 수락하거나 거절하도록 하는 거죠.
00:16:21직접 들어가서 글을 쓰고, 공유 스킬을 업데이트하고, PR 리뷰를 거쳐
00:16:28병합해야 하는 GitHub 방식만큼 무겁지는 않습니다.
00:16:30그렇다고 에이전트가 무분별하게 메모리를 자동 작성하게 두는 무모한 방식도 아니죠.
00:16:36일하는 도중에 적절한 지점에서 팝업이 뜨고,
00:16:40올바른 권한 범위를 제안해 주면 사람이 확인 후 추가하는 이상적인 절충안입니다.
00:16:45이렇게 아주 간단한 방식을 더하면, 사람들은 거대한 위키에 내용을 보태면서도
00:16:51동시에 자신이 공개 범위를 통제하는 책임까지 쥘 수 있게 됩니다.
00:16:57재무 위키에 뭔가를 더할 때 민감한 내용이라면 확실히 재무 관련 권한 범위를 설정하고 싶을 겁니다.
00:17:01민감한 내용이라면 확실히 재무 관련 권한 범위를 설정하고 싶을 겁니다.
00:17:03개인적인 내용을 추가할 때는 개인용 범위로 지정되도록 확실히 해두어야 하죠.
00:17:06실제 사용자 경험(UX)이 어떤 모습인지 예시를 보여드리겠습니다. 저희가 실제로 이렇게 하고 있습니다.
00:17:15이건 영업 담당자 중 한 명이 저를 통화에 초대하며 보낸 최근 이메일입니다.
00:17:33이 이메일을 보고 답변을 도운 뒤에, 어떤 내용들이 추가될지 정리된
00:17:39여러 개의 요약 항목을 제안하는 작은 창이 떴습니다.
00:17:43그리고 '위키에 추가'를 누르면 되죠. 이제 추가될 내용을 검토하기가 훨씬 수월해집니다.
00:17:47이 마크다운 파일에 들어가든 저 마크다운 파일에 들어가든 신경 쓸 필요가 없습니다.
00:17:52어떤 링크를 맺을지는 에이전트가 알아서 처리하니까요. 제가 신경 쓰는 건 오직 '이 사실들이 정확한가' 하는 점뿐입니다.
00:17:58사실관계가 맞다면 '위키에 추가'를 누르고 끝내면 됩니다.
00:18:02위키에 추가하는 동안 위키 페이지별로 어떤 권한 범위를 적용할지 선택할 수 있습니다.
00:18:08즉, 위키 페이지마다 누구에게 접근 권한을 줄지 결정할 수 있는 권한 범위를 부여할 수 있죠.
00:18:12예를 들어 제 이메일 관련 위키 페이지가 있고 이메일 우선순위를 지정하는 방식이 있다면,
00:18:17여기에 누가 접근할 수 있는지, 소유자는 누구인지, 역할 기반 액세스 제어(RBAC)는 어떻게 되는지 결정할 수 있습니다.
00:18:22시스템의 구체적인 생김새는 여러분이 결정하기 나름이지만 핵심 아이디어는 동일합니다.
00:18:26에이전트가 직접 변경을 수행하는 대신 변경 사항을 '제안'하도록 만드는 것이죠.
00:18:32자, 규칙은 두 가지입니다. 첫째, 모든 내용은 전사 공용 위키 하나에 들어가야 합니다. 이 원칙은 절대 양보하지 마세요.
00:18:38둘째, 그 과정의 일환으로 모든 변경 사항에는 반드시 사람의 이름이 기록되어야 합니다.
00:18:44'Claude가 추가함', 'AI 에이전트가 추가함', 'Hermes가 추가함' 같은 식의 기록은 위키에 절대 허용해서는 안 됩니다.
00:18:51'Tanmay가 추가함'처럼 담당자 이름이 반드시 남아 있어야 합니다.
00:18:57그래야 나중에 누구나 볼 수 있는 사내 연봉 정보 같은 민감한 내용을 실수로 노출시킨 사람이 누구인지 추적할 수 있겠죠.
00:19:04원인 제공자가 누구인지 알 수 있으니 그에 따른 시정 조치를 취할 수 있습니다.
00:19:09성과 개선 계획(PIP) 대상자로 지정하든 말이죠. 위키 편집 법도 몰랐던 거니까요. 이 점이 매우, 매우 중요합니다.
00:19:14그리고 두 번째 규칙으로 넘어가서, 사람들이 이 작업을 쉽게 할 수 있도록 환경을 만들어 주어야 합니다.
00:19:19바로 여기서 앞서 말한 권한 범위(scope) 개념이 들어오는 것인데,
00:19:23누가 접근할 수 있는지에 따라 각 파일의 범위를 지정하고 그 주변으로 시스템을 구축하는 식입니다.
00:19:26구조는 대략 이런 아키텍처 다이어그램 형태가 됩니다. 사용자가 있고,
00:19:32사용자는 에이전트와 대화합니다. 에이전트는 컨텍스트를 읽을 때 해당 사용자의 클레임을 사용하죠.
00:19:39따라서 재무 문제를 해결하기 위해 무언가를 읽는다면, 제가 재무 위키에 접근할 권한이 있었기 때문에
00:19:46제 클레임을 사용하여 저처럼 읽어들이는 식이며, 이 과정은 매번 수행됩니다.
00:19:52즉, 에이전트는 항상 사용자의 자격 증명을 사용하여 위키의 올바른 부분을 읽어옵니다.
00:20:00좋습니다. 두 번째 유스케이스를 다루기에는 시간이 거의 다 되었네요. 그래서 두 번째 유스케이스의
00:20:06맛보기만 살짝 보여드리고, 이 아이디어를 확장해 보겠습니다. 이것이야말로 진짜 핵심 유스케이스입니다.
00:20:13정말 복잡한 유스케이스인데요, 왜냐하면 이제는
00:20:17단 한 사람이 이메일에 답장하는 게 아니기 때문입니다. 우리 여러 사람이 공유된 컨텍스트를 활용해
00:20:25다양한 에스컬레이션과 권한 수준을 거치며 문제를 해결해야 하니까요.
00:20:31바로 이런 상호작용 속에서 AI와 함께 기업의 집단 지식이 가장 많이 생성됩니다.
00:20:36예를 들어, 저희에게 이것이 실제로 어떻게 나타나는지 실제 사례를 짧게 보여드리겠습니다.
00:20:42이건 SRE 상황에서 발생한 사례인데요.
00:20:50누군가 “야, 우리의 자동 학습, 위키 학습(꽤 메타적인 기능인데)이 안 되고 있어. 작동하지 않아,
00:20:57무슨 일이지?”라고 말했죠. 그래서 조사를 시작하는데 제대로 안 됩니다. 왜냐하면
00:21:02관련 스킬이 없어서 실패했거든요. 그래서 “야, 이러지 말고 이 오픈텔레메트리 스팬 이름을 써줘”라고 합니다.
00:21:07오픈텔레메트리 스팬 이름을 사용했더니 조금 나아지긴 했지만 여전히 너무 느렸습니다. 그래서
00:21:13코드를 살펴보니 이렇게 말하죠. “어, 너 라이크(like) 쿼리 쓰고 있네. 너 바보냐?”
00:21:18이건 오푸스 4.5라고요. “이러지 마”라는 식이죠. 그래서 라이크 쿼리를 쓰지 말고
00:21:24이퀄스(equals) 쿼리를 쓰라고 합니다. 그렇게 이퀄스 쿼리를 쓰니 몇 가지 세부 정보가 나타나고,
00:21:29“어, 여기에 대해 더 깊이 파봐”라고 말합니다. 그러곤 에러가 발생하는
00:21:33코드 라인을 찾아냅니다. 간단한 일이죠? 여기서 어떤 지식이 표면화되냐면요.
00:21:39아하, like가 아니라 equals를 써야 한다는 걸 배웠죠! 그리고 위키 페이지 이름에
00:21:45커스텀 접두사가 붙어 있으면 문제를 일으킬 수 있다는 걸 배웠습니다. 이런 학습 내용을
00:21:50선택해서 수용할 수 있도록 제시해 주는 겁니다. 그래서 문제의 원인에 대해 더 깊이 파고들었습니다.
00:21:56그러자 다른 사람이 대화에 참여해서 말합니다. “우리가 여기서 내린 기술적 결정이
00:22:02틀렸어. 왜 이런 일이 일어나는 거지?” 이제 두 사람이 논쟁을 시작합니다. 논쟁을 벌이죠.
00:22:09“이러면 안 되지, 이렇게 해야 해. 근데 왜 이 모양이야? 아니, 이렇게 되어야 한다니까” 하고 말이죠.
00:22:12이러한 논쟁이 지식을 만들어냅니다. 실제 문제는 누군가가 문서화되지 않은
00:22:17기술적 결정을 내렸다는 점이었기 때문입니다. 그 문제를 해결하기로 하고,
00:22:22그것이 정말 근본 원인임을 확인한 뒤, 다음과 같이 해결하기로 결정합니다.
00:22:26“문제를 일으키는 이 접두사를 제거하자” 등등 무엇이 되었든 간에,
00:22:31바로 이 과정이 기업의 두뇌에 추가될 가장 높은 품질의 컨텍스트를 만들어냅니다. 이전의 제안은
00:22:38“페이지에 접두사가 있으면 안 된다”가 아니라 단순히 “페이지에 접두사가 있다”는 사실 자체가 문제라는 식이었죠.
00:22:44그래서 이제 두뇌에 문서화하는 내용은 다음과 같습니다. “페이지에는 접두사가 없어야 한다.
00:22:49접두사가 있으면 프로덕션에서 조회 문제를 일으킬 수 있다.” 이는 여러 사람이 서로 소통하고
00:22:54함께 문제를 해결할 때 발생합니다. 슬랙(Slack) 스레드에서 두 사람이 대화를 나누며
00:22:59문제를 해결할 때 벌어지는 일이죠. 최고 품질의 컨텍스트가 만들어집니다. 바로 이런 것을
00:23:05원하는 것입니다. 하지만 문제점은 이와 관련된 권한 상승 문제가 매우,
00:23:10매우 심각해진다는 점입니다. 여러 사람과 함께 모든 것을 할 수 있는 에이전트를 구축한다면
00:23:18무서운 일입니다. 엔지니어에게는 PR 작업을 허용했는데, 이제 같은 에이전트를 사용해서
00:23:23프로덕션에 배포까지 할 수 있게 되니까요. 너무 무서운 일이죠. 디버깅하면서
00:23:29안전하게 배포까지 하는 대화를 나눌 수는 없습니다. 특히 은행에 있다면 더욱 그렇습니다. 디버깅을 하고,
00:23:35스테이징에 배포하고, 알람을 설정하고, 배포를 수행하는 사람들이 서로 다르지 않나요? 하지만 이 역할들이 같아지는 것에도
00:23:40많은 가치가 있습니다. 모든 지식이 거기에 집중되어 있기 때문이죠. 그래서 이것이 바로
00:23:45두 번째 아키텍처로 이어지게 됩니다. 세부적인 내용은 너무 깊게 다루지 않겠지만,
00:23:49사용자 자격 증명과 클레임을 사용하여 컨텍스트를 읽던 기존 아이디어와 비슷한 맥락으로 생각하시면 됩니다. 코드에서 도구를 실행할 때도
00:23:58마찬가지로 사용자 자격 증명을 사용하는 것입니다. 절대 샌드박스에 자격 증명을 저장하지 마세요.
00:24:05그 대신 HTTP 계층이나 SQL 계층에서 사용자의 자격 증명을 주입하여, AI가 특정 상호작용에서
00:24:13실제 인간처럼 행동할 수 있도록 합니다. 여기에 아주 흥미로운 세부 사항들이 있습니다. 하지만 바로 이것이
00:24:20공유된 AI가 공유된 컨텍스트와 함께 작동할 수 있게 해주는 핵심 요소입니다. 이것이 바로 다루어야 할 두 가지 핵심 요소죠.
00:24:25요약하자면, 이 아키텍처가 특별히 복잡한 것은 아니지만 이 두 가지 규칙을 거슬러 올라가면 매우 단순합니다.
00:24:30첫째, 클라우드 샌드박스에 자격 증명을 저장하지 마십시오. 그리고 둘째,
00:24:36실제 데이터와의 모든 상호작용을 가상화하고 프록시 처리하며 가상화하는 등 원하는 용어를 써서
00:24:41사용자가 직접 통제할 수 있게 하세요. 특정 도구를 추가한 사용자가 해당 도구에 대한 접근 권한을
00:24:48누가 가질지 제어해야 합니다. 따라서 이 네 가지 원칙을 따르고 그로부터 역산해 나간다면
00:24:53이 모든 구조를 도출해 낼 수 있습니다. 말이 되는 아키텍처는 오직 하나뿐입니다.
00:24:58즉, 컨텍스트를 관리하는 방법, 설정하는 제약 조건, 도구를 관리하는 방식, 그리고 어떤 보안
00:25:02규칙을 설정하느냐 하는 점들이 그렇습니다. 제 발표 시간은 여기까지입니다. 강연이 끝나고 더 이야기 나누면 좋겠네요. 부스도 따로 마련되어 있으니
00:25:10이 아키텍처의 세부적인 뉘앙스에 대해 더 편하게 대화 나누러 오세요. 저는 트위터의 탠메이 고(Tanmay Go)이고,
00:25:16저희 팀은 프롬프트QL(PromptQL)입니다. 꼭 확인해 보세요. 결국 AI 엔지니어링 커뮤니티와 함께
00:25:24제품을 런칭할 예정입니다. 그래서 여러분 모두와 그 소식을 공유하고 싶습니다.
00:25:30나중에 공유할 수 있도록 무대 위에서 다 함께 사진을 한 장 찍으려고 합니다. 무대에 있는 동안 지금 바로 진행해 볼게요.
00:25:40자, 다들 치즈 해 주시겠어요?
00:25:45정말 감사합니다. 기대해 주셔도 좋습니다. 저희가 선보이는 Cloud Tag 방식인 PromptQL Tag는
00:25:52클라우드에만 갇혀 있지 않다는 점만 빼면 여기서 이야기 나눈 아이디어들과 매우 유사합니다.
00:25:57GLM도 사용할 수 있고, GPT도 사용할 수 있으며, Sol이 나오면 그것도 활용하면서 재미있게 즐길 수 있죠.
00:26:03그러니 꼭 한번 확인해 보시고, 그럼 곧 또 뵙겠습니다.
00:26:19잠시 후 다시 돌아오겠습니다.