모든 회사가 Slack, 이메일, 문서, 회의를 하나의 브레인으로 연결하고 있다. 그 브레인은 모든 사람이 회사가 아는 모든 것에 접근할 수 있게 해준다.
사실 아무도 그런 걸 원하지 않는다.
전체 회의에서 로드맵이 덕트 테이프로 붙여져 있는 거나 다름없다고 농담하면, 회의장이 웃음으로 가득 찬다. 여덟 달 후, 신입사원이 브레인에게 로드맵이 제대로 진행되고 있는지 묻고, 브레인은 웃음이 빠진 그 농담을 다시 꺼내든다.
고객이 영업 담당자에게 보낸 비공개 이메일에서 온보딩 때문에 거의 이탈할 뻔했다고 말한다. 제품팀은 그 사실을 알아야 하지만, 아무도 이메일함 전체를 넘겨주고 싶어 하지 않는다.
에이전트가 Matt이 쓴 제안서 세 개를 읽고 그가 모놀리스를 선호한다고 결론을 내린다. 그 결론이 맞을 수도 있다. 하지만 그렇다고 에이전트에게 "Matt이 모놀리스를 사용하자고 말했어"라고 말할 자격이 생기는 것은 아니다. 그는 그런 말을 한 적이 없다.
오늘날 표준 권한 모델은 단순하다. 내가 Slack 메시지를 볼 수 있다면, 내 에이전트도 그것을 볼 수 있다. 소스를 미러링하고 권한을 상속하면 끝이다. 그 방식은 소프트웨어가 소스를 그대로 돌려줄 때는 잘 작동한다.
회사 브레인은 다르게 동작한다. 회의에서 결정을 추출해 이메일과 결합하고, 결과를 메모리로 저장하고, 다른 사람에게 전달하고, 나중에는 고객에게 응답하는 에이전트에게 넘긴다. 그 시점에 정보는 원래 담겨 있던 객체를 훨씬 벗어나 이동해 있다. 권한 모델도 그와 함께 이동해야 한다.
권한의 단위는 더 이상 파일이 아니다. 바로 클레임(claim)이다. 즉, 브레인이 앞으로 전달하는 모든 맥락 조각이다. "Acme는 9월까지 SSO가 필요하다." "리드 엔지니어가 자리를 비워서 마이그레이션이 늦어질 가능성이 높다." 클레임은 누군가가 직접 말한 것일 수도 있고, 브레인이 다섯 가지 소스에서 조합한 것일 수도 있다. 어느 쪽이든, 클레임은 이제 어떤 파일 밖에 존재한다. 파일의 권한으로는 더 이상 설명할 수 없다.
소스 권한은 최소 기준이다
소스 권한은 여전히 필요하다. 누군가 Slack 채널이나 Drive 폴더에 접근할 수 없다면, 그 사람의 에이전트가 갑자기 그 내용을 볼 수 있어서는 안 된다. 실수는 정보가 변환된 후에도 소스 ACL이 필요한 모든 것을 알려준다고 가정하는 데 있다.
소스 권한은 하나의 좁은 질문에 답한다. 누가 이 객체를 열 수 있는가? 회사 브레인은 더 어려운 질문에 답해야 한다. 새로 입사한 영업 담당자의 에이전트가 CEO가 이사회에 말한 정리해고 일정을 알아야 하는가? 1:1 면담에서 나온 솔직한 발언이 영구적인 메모리가 되어도 되는가? 고객이 실제로 이탈한다고 말한 것인가, 아니면 브레인이 추론한 것인가? 에이전트가 그 추론을 바탕으로 행동할 수 있는가?
이런 질문이 생기는 이유는 회사 브레인이 단순히 검색만 하는 것이 아니기 때문이다. 브레인은 종합을 수행하고, 종합은 권한 문제를 바꾼다.
때로는 지식이 소스보다 더 멀리 전파되어야 한다
영업 담당자가 고객과의 비공개 이메일에서 중요한 사실을 알게 된다. 고객이 왜 구매했는지, 왜 경쟁사를 거절했는지 정확히 설명한다. 여섯 달 후, 제품팀이 같은 문제를 두고 토론하고 있다.
제품팀에게 필요한 것은 이메일함이 아니라 그 교훈이다.
오늘날 이 두 가지는 묶여 있다. 소스에 접근할 수 있거나 없거나, 둘 중 하나다. 회사 브레인은 이 둘을 분리할 수 있다. 교훈을 추출하고, 민감한 세부사항을 걸러내고, 증거로 돌아갈 수 있는 영수증을 보존한 다음, 그 교훈을 필요로 하는 사람들에게 전달할 수 있다. 이메일함은 비공개로 남고, 지식은 조직의 자산이 된다.
엔지니어링에서도 같은 일이 일어난다. 누군가 제한된 채널에서 잘 알려지지 않은 우회 해결책을 발견하고, 석 달 후 다른 엔지니어가 같은 버그를 만난다. 두 번째 엔지니어는 그 채널에 있는 모든 대화에 대한 접근 권한을 물려받지 않으면서도 첫 번째 엔지니어가 배운 내용의 혜택을 받을 수 있어야 한다.
회사는 개별 직원이 볼 수 있는 것보다 더 많은 것을 알고 있다. 브레인은 주변의 모든 것을 노출하지 않으면서 유용한 부분만 옮길 수 있어야 한다.
때로는 지식이 소스보다 덜 퍼져야 한다
회의 녹화본이 회사 전체와 공유된다. 처음 5분은 사람들이 근황을 나누는 시간이다. 어떤 사람은 주말 이야기를 하고, 어떤 사람은 동료에 대해 농담을 하고, 어떤 사람은 자신이 잘못됐다고 생각하는 결정에 대해 불만을 털어놓는다. 그다음 회의가 시작되고, 그 자리에서 중요한 제품 결정이 내려진다.
모든 사람이 그 녹화본에 정당한 접근 권한을 가질 수 있다. 그렇다고 모든 문장이 영구적인 회사 기억이 될 자격이 있다는 뜻은 아니다.
사람들은 이것을 자연스럽게 이해한다. 우리는 방 안에 있는 사람들에게는 적절하지만, 영구적인 조직 지식으로는 부적절한 말을 끊임없이 한다. 여섯 명의 동료에게 개인적인 이야기를 할 수는 있어도, 1년 후 신입사원이 그걸 검색해서 찾아내길 바라는 것은 아니다. 반쯤 정리된 의견을 흘려보낼 수는 있어도, 그게 확정된 입장으로 취급되길 바라는 것은 아니다. 농담은 원래의 말투와 청중에서 분리되어 몇 달 후 에이전트에 의해 다시 떠오르면 전혀 다르게 다가온다.
소스 ACL은 이런 것 중 어느 것도 표현할 수 없다. 브레인은 콘텐츠가 무엇을 의미하는지 이해해야 한다. 회의의 어떤 부분은 영속적인 기억이 되어야 하고, 어떤 부분은 녹화본에서만 접근할 수 있어야 하며, 어떤 부분은 조직 기억에서 완전히 빠져야 한다.
사람들은 이미 회의에 녹음기가 들어오면 더 조심한다. 이제 모든 대화가 자동으로 영구적이고 검색 가능한 회사 기억으로 증류된다고 상상해보라. 사람들은 농담을 덜 하고, 반쯤 정리된 아이디어를 덜 던지고, 개인적인 맥락을 업무 대화에 가져오는 것을 멈출 것이다. 회사는 더 많은 말을 포착하지만, 이해하는 것은 줄어든다.
선택적 망각은 좋은 회사 브레인의 일부다. 모든 것을 기억하는 브레인은 결국 자신이 이해하려는 사람들의 행동을 바꿔버린다.
에이전트 트레이스는 새로운 회의 녹화본이다
에이전트 자체가 몇 년 전만 해도 거의 존재하지 않았던 회사 맥락의 소스가 되었다.
엔지니어는 코딩 에이전트와 함께 세 시간을 보낼 수 있다. 그리고 나면 회사는 풀 리퀘스트 하나를 받게 된다. 하지만 PR은 최종 산출물일 뿐이다. 그 과정에서 에이전트는 파일을 살펴보고, 도구를 호출하고, 여러 접근 방식을 기각하고, 제약 조건을 발견하고, 엔지니어의 수정을 받고, 코드가 어떻게 동작해야 할지 결정했다. 그 맥락의 대부분은 사라진다.
우리는 결정에 이르는 대화에 유용한 정보가 담겨 있기 때문에 회의를 녹화할 가치가 있다고 판단했다. 에이전트 트레이스는 회의 녹화본에 해당한다. 최종 산출물은 무엇이 바뀌었는지 알려준다. 트레이스는 왜 바뀌었는지 알려준다. 그 안에는 어떤 설계가 기각된 이유, 코드베이스 어디에도 없는 제약 조건, 엔지니어가 대화에 붙여 넣은 고객 요구 사항, 다음 달에 다시 중요해질 수정 사항이 담겨 있을 수 있다.
에이전트가 더 많은 일을 할수록, 회사의 추론 중 더 많은 부분이 이런 상호작용 안에서 일어나게 될 것이다. 트레이스를 버리는 것은 점점 더 커져가는 조직 지식의 몫을 버리는 것이다.
그렇다고 모든 토큰을 영원히 저장하자는 뜻은 아니다. 원시 트레이스에는 노이즈, 실패한 시도, 비밀, 개인적인 프롬프트가 섞여 있다. 유용한 객체는 의사결정 이력이다. 무슨 일이 있었는지 재구성할 수 있는 충분한 증거와 영속적인 기억이 될 만한 부분들이 바로 그것이다.
이것은 새로운 소유권 문제를 만든다. Jessica가 회사를 떠난다면, 그녀의 코딩 에이전트가 배운 모든 것도 함께 떠나야 하는가?
아마 아니다. 에이전트는 마이그레이션이 왜 실패했는지, 고객 예외가 어떻게 작동하는지, 어떤 설계가 이미 두 번 기각되었는지를 배웠을 수 있다. 그 지식은 회사의 것이다. 하지만 같은 에이전트에는 Jessica가 누군가의 성과 평가를 준비하거나 동료와의 갈등에 대해 이야기한 대화가 담겨 있을 수도 있다. 그런 내용은 조직이 공유하는 기억이 되어서는 안 된다.
시스템은 맥락이 생성되는 동안 이 둘을 분리해야 한다. 퇴사 처리는 너무 늦기 때문이다.
출처 표시는 권한의 일부다
회사 브레인은 누구도 기록하지 않은 정보도 만들 것이다.
시스템이 Matt이 쓴 제안서 세 개를 읽고 그가 특정 아키텍처를 선호한다고 결론을 내린다고 가정해보자. 그것은 유용한 맥락이 될 수 있다. 하지만 시스템은 이렇게 말해서는 안 된다:
Matt이 이 아키텍처를 사용해야 한다고 말했다
Matt은 그렇게 말한 적이 없다. 브레인이 추론한 것이다.
이 구분이 중요한 이유는 "Matt이 X라고 말했다"가 "시스템이 Matt의 작업에서 X를 추론했다"보다 더 큰 무게를 지니기 때문이다. 첫 번째 진술에는 영수증이 필요하다. Matt이 실제로 그렇게 말한 이메일, 대화 기록, 또는 문서 구간 말이다. 그렇지 않으면 시스템은 자신의 목소리로 말해야 한다:
Matt이 쓴 제안서 세 개에서 추론함
모든 중요한 클레임에는 출처가 필요하다. 그것은 어디서 왔는가? 직접 말한 것인가, 추론된 것인가, 아니면 알 수 없는 것인가? 얼마나 최신인가? 시스템은 어느 정도로 확신해야 하는가?
그리고 그 이력은 변환을 견뎌야 한다. 비공개 이메일은 에이전트가 요약했다고 해서 접근 제한이 풀리지 않는다. 추론은 세 번 반복되었다고 해서 인용문이 되지 않는다. 신뢰할 수 있는 회사 브레인은 그 연결고리를 보존해야 한다.
요약은 권한을 세탁한다. 추론은 출처를 세탁한다.
권한에는 시계가 있다
시스템이 오늘 누가 무엇을 알아야 하는지 알고 있더라도, 그 답은 내일 바뀔 수 있다.
어떤 팀이 새로운 직원 복지를 도입하기로 결정한다. 출시를 준비하는 사람들은 즉시 알아야 한다. 고객은 알면 안 된다. 나머지 회사 직원들은 금요일 전체 회의에서 알게 될 수도 있다. 발표가 끝나면 그 정보는 채용, 영업, 마케팅으로 흘러갈 수 있다.
근본적인 사실은 아무것도 바뀌지 않았지만, 그 정보를 알아야 할 청중은 바뀌었다.
이런 의도는 어디에도 거의 기록되지 않는다. 누군가는 "이건 내가 직접 발표하고 싶어"라고 생각할 뿐, 엠바고 플래그를 설정하지 않는다. 고객은 자신의 이야기가 영업사원에게 도움이 되는 것은 기뻐하지만, 그 이야기가 LinkedIn 게시물로 변하는 것은 불편해한다. 창업자는 "엠바고"라는 단어를 입에 올리지 않은 채 다가올 제품에 대해 편하게 이야기한다.
사람들은 머릿속에 많은 권한 정책을 담고 있다. 때때로 시스템은 물어봐야 한다:
방금 중대한 제품 결정을 내리셨습니다. 이 내용을 회사와 공유할까요?
어려운 부분은 언제 끼어들어야 하는지를 아는 것이다. 5분마다 허락을 구하는 시스템은 사람들이 그 시스템을 무시하게 만든다. 인간의 판단은 답이 정말로 모호하고 결과를 되돌리기 어려운 경우를 위해 아껴두어야 한다. 내부 관찰 내용을 팀원 한 명과 더 공유하는 것은 되돌릴 수 있다. 무언가를 외부에 공개하거나, 고객에게 이메일을 보내거나, 되돌릴 수 없는 행동을 하는 것은 훨씬 더 높은 기준을 요구한다.
시스템은 일상적인 경우는 자동으로 처리하고 영수증을 남긴 다음, 인간의 주의를 판단이 중요한 몇 가지 결정을 위해 아껴야 한다.
단일 회사는 쉬운 경우다
대부분의 권한 시스템은 하나의 조직과 하나의 관리자를 가정한다. 에이전트는 그 가정을 깨뜨릴 것이다.
구매자의 에이전트는 판매자의 에이전트와 대화하게 될 것이다. 회사 에이전트는 직원의 개인 에이전트와 함께 일하게 될 것이다. 지원 에이전트는 내부 지식을 외부 답변으로 바꾸게 될 것이다. 결국 회사 브레인은 다른 회사 브레인과 직접 맥락을 교환하게 될 것이며, 양쪽을 통제하는 단일 권한 시스템은 존재하지 않는다.
그리고 "내부"와 "외부"라는 구분은 너무 단순하다. 고객에게서 서명받은 계약서가 내부 CRM 필드보다 더 권위 있을 수 있다. 다른 회사의 에이전트가 추론한 클레임은 연구에는 유용할 수 있지만, 되돌릴 수 없는 행동을 유발할 만큼 신뢰할 만한 수준은 못 될 수 있다.
맥락은 자신의 권위를 함께 지녀야 한다. 어떤 정보는 읽는 것은 안전하고, 추천에 사용하는 것도 안전하지만, 행동의 유일한 근거로 사용하기에는 안전하지 않을 수 있다. 에이전트가 질문에 답하는 것 이상을 할 수 있게 되면 그 차이는 결정적으로 중요해진다.
개인이 소유한 에이전트는 경계를 더욱 어렵게 만든다. 그들의 기억은 여러 직장에 걸쳐 있을 수 있다. 개인은 자신의 사적 이력을 유지해야 하고, 고용주는 회사가 비용을 들여 창출한 업무 지식을 유지해야 한다. 기밀 회사 맥락은 다음 회사로 새어 나갈 수 없고, 개인 맥락은 이전 회사에 흡수될 수 없다. 그 경계는 메모리 자체 안에 존재해야 한다.
권한 모델은 지식과 함께 이동한다
이 차원들은 서로 독립적이다. 어떤 회사는 엄격한 소스 경계와 강한 콘텐츠 필터링을 가질 수 있다. 다른 회사는 원시 대화를 거의 남기지 않으면서 유용한 지식이 팀 사이를 활발하게 이동하게 할 수 있다. 에이전트가 만든 맥락도 또 하나의 소스다. 인간의 판단은 에스컬레이션 메커니즘이다. 출처, 시점, 청중, 행동 권한은 이 모든 것을 가로지른다. 공통의 기본 단위는 클레임이다.
회사 브레인의 모든 영속적인 클레임은 자체 정책을 지녀야 한다. 최소한 브레인은 다음을 알아야 한다:
- 클레임이 어디서 왔는지, 그리고 직접 말한 것인지 추론된 것인지
- 누가 받을 수 있는지
- 무엇에 사용될 수 있는지
- 메모리에 얼마나 오래 남아 있어야 하는지
- 청중이 언제 바뀔 수 있는지
- 에이전트가 그것을 바탕으로 어떤 행동을 할 수 있는지
- 언제 인간이 결정해야 하는지
소스 권한은 출발점이다. 그리고 정책은 맥락이 요약되고, 결합되고, 기억되고, 공유되는 동안 그 맥락을 따라 이동한다. 전통적인 권한은 객체를 관리한다. 반면 회사 브레인은 이동하는 정보를 관리해야 한다.
이것은 나중에 보완할 수 있는 문제가 아니다. 무분별한 브레인을 1년간 돌린 회사는 1년치 되돌릴 수 없는 기억을 기록해버린 것이다. 농담, 불만, 반쯤 정리된 의견, 인용문으로 포장된 추론까지. 더 나쁜 것은, 그동안 직원들에게 브레인이 그들이 하는 말을 어떻게 처리하는지 가르쳐버렸다는 점이다. 직원들이 모든 것이 영구적이고 검색 가능해진다는 것을 배우고 나면 말하는 방식이 달라진다. 그리고 나중에 권한 모델을 고친다고 해도 그 솔직함은 돌아오지 않는다.
이해는 복리로 쌓이고, 불신도 복리로 쌓인다. 권한 모델을 처음부터 제대로 구축한 회사는 직원들이 실제로 그 앞에서 편하게 말하게 되는 브레인을 갖게 될 것이다.
권한은 지능의 일부다
Hyperspell에서 우리는 회사 브레인을 만들고 있다. 메시지, 문서, 회의, 시스템, 에이전트 전반에 걸쳐 회사가 알고 있는 것을 지속적으로 업데이트하는 모델이다.
커넥터는 센서 계층이다. 더 어려운 작업은 그 모든 맥락이 상호작용하기 시작한 뒤에 시작된다. 브레인은 어떤 소스를 신뢰할지, 무엇이 기억이 될 자격이 있는지, 결론이 어디서 나왔는지, 누가 그 결론을 받아야 하는지, 에이전트가 그 결론으로 무엇을 할 수 있는지 결정해야 한다.
유용한 지식은 주변의 모든 것을 노출하지 않으면서 그것이 필요한 사람과 에이전트에게 도달해야 한다. 가벼운 대화는 가벼운 대화로 남을 수 있어야 하고, 추론은 추론으로 남아야 하며, 회사 지식은 직원 퇴사 후에도 유지되되 주변의 개인적인 것까지 흡수하지 않아야 한다. 때로는 브레인이 말하기 전에 물어볼 줄도 알아야 한다.
이것은 Hyperspell이 해결하고 있는 핵심 문제 중 하나다. 실제 권한 모델을 갖춘 회사 브레인이 어떤 모습인지 보고 싶다면, 15분 안에 보여드릴 수 있다.
유용한 회사 브레인은 회사가 무엇을 아는지 안다.
신뢰할 수 있는 브레인은 언제 침묵해야 하는지도 안다.
