회사의 두 번째 두뇌: 위키부터 기술까지, 모든 것은 맥락에 달려 있습니다1 min read

나는 “두 번째 뇌”를 둘러싼 모든 과대 광고에 대해 많이 생각해 왔습니다. 나는 이 분야의 다른 사람들과 두 번째 두뇌를 구축하고 있거나 그 버전을 갖고 있는 동료들과 이에 대해 논의했습니다.

익숙하지 않은 분들을 위해 설명하자면, 두 번째 뇌 운동은 Andrej Karpathy의 “Wiki” 아이디어로 시작되었습니다. 즉, 에이전트의 개인 지식을 일종의 로컬 MD 파일의 상호 연결된 Wiki 구조로 구성하는 것입니다. 이는 나중에 훨씬 더 광범위한 형식으로 개인 데이터를 구성하는 것으로 확장되었으며, 사용자는 종종 Obsidian을 사용하여 메모를 구성 및 시각화하고 회의 데이터(Granola/Whisperflow/Zoom 기록)를 Wiki에 추가했습니다.

로켓-카르파시-지식 기반:시작

로켓-카르파시-지식 기반:끝

“Wiki”가 확장되면서 그 안에 있는 정보를 공유하는 데 실질적인 가치가 있다는 것이 분명해졌습니다. 그리하여 ‘회사의 두 번째 두뇌’ 프로젝트가 꽃피우기 시작했습니다. 두 번째 두뇌의 Utopic 버전은 Zoom 통화, F2F 회의, 일상적인 상호 작용, 이메일, 슬랙 메시지, 문서 등 가능한 모든 것을 Snowflake와 같은 거대한 데이터 데이터베이스에 기록합니다. 회사의 누구든지 이 Snowflake 인스턴스에 원하는 것을 질문하고 즉시 모든 질문에 대한 답변을 얻을 수 있다고 상상해 보십시오.

이런, 좋은 생각은 아니네요. 첫째, 이것은 매우 비쌉니다. 이와 같은 방식으로 들어가는 데이터의 양은 정말 어마어마하며, 여기서 데이터를 검색하는 것은 극도로 어렵고 느리며 비용이 많이 듭니다. 보안 및 데이터 분리가 문제가 됩니다. 1:1 개인 데이터, 재무 데이터, 관리 결정, HR 데이터 또는 누군가를 해고하기로 한 결정이 성적표에 빠져 접근할 수 없도록 어떻게 방지할 수 있습니까? 모두가 그런 것은 아니다 해야한다 다 알아…

또한 이것이 필요한 사람은 누구이며 우리를 구하는 것은 무엇이며 이것이 과연 좋은 생각일까요?

나는 일반적으로 이것의 포함된 버전이 좋은 생각이라고 말하고 싶습니다. 중간 경영진이 존재하는 이유 중 대부분은 문제를 업스트림에 전달하고 다운스트림에서 결정을 명확히 하기 위한 것입니다. 이제 이 중 많은 부분이 두 번째 두뇌로 수행될 수 있습니다.

기술팀을 위한 두 번째 두뇌

기술적인 두 번째 두뇌는 유지 관리가 훨씬 쉬울 수 있습니다. 많은 회사에서는 Claude/Codex가 공유할 수 있는 공유 지식을 보유한 Dropbox/Google 드라이브/OneDrive 디렉터리를 사용합니다. 이를 Git 저장소로 푸시하는 자동화는 매우 간단합니다. 또는 실제로 Github를 사용하여 이를 관리할 수도 있습니다(OpenAI/Anthropic가 이러한 유형의 작업을 관리하기 위해 사용자 정의 기술을 설치하지 않고도 이 시나리오를 지원하는 것은 매우 작은 노력이라고 생각합니다). 이제 진실의 소스는 Github 저장소가 되고 로컬 복사본은 로컬 git 저장소가 됩니다.

이를 통해 공유 기술, 공유 결정, 건축 디자인, 시각적 디자인(예: 디자인 시스템 결정) 및 기타 다양한 회사 제품 결정과 같은 지식과 기능을 추가할 수 있습니다.

소규모 팀에는 리포지토리에 대한 단순한 동기화 외에는 실제로 많은 것이 필요하지 않지만, 수많은 대규모 팀이 있는 대규모 회사는 매우 빠르게 심각한 제한에 직면하게 됩니다. 가장 심각한 문제는 특정 사용자가 두 번째 뇌 데이터와 충돌하는 로컬 결정을 내릴 수 있는 상황 중독과 관련이 있습니다. 즉, 충돌하는 데이터를 도입하거나 실수로 회사 결정을 무시하는 것입니다(경우에 따라 의도적으로?).

git에 보관하고 병합하는 것은 충돌을 찾아 변경 사항이 충돌하는 경우 사용자에게 경고하고 충돌을 해결하고 결과를 병합할 수 있는 전용 에이전트를 사용하여 수행할 수 있습니다.

이는 프로젝트 문서를 유지 관리하는 데 좋은 방법이 아닙니다. 이를 위해 더 좋은 방법은 위키를 프로젝트 자체의 필수적인 부분으로 포함시키는 것입니다. 만드는 것은 꽤 쉽습니다. 코딩 에이전트를 따로 설정하고 프로젝트를 검토하고 문서 폴더에 철저하게 문서화하고 아키텍처, 문제, 제품 결정, 기술 결정 및 작은 포함 가능한 md 파일에 도움이 될 수 있다고 결론을 내리는 기타 항목으로 분할하도록 요청하면 됩니다. 핵심은 코드와 readme.md가 모두 문서 디렉토리를 가리키도록 하여 모든 곳에서 참조되고 외부 리소스가 아닌 프로젝트의 일부로 간주되도록 하는 것입니다. 에이전트가 알아야 할 핵심 사항은 여기의 의도가 함정, 움푹 들어간 곳 및 기술적 싱크홀을 피하기 위해 프로젝트에 다른 에이전트를 신속하게 온보딩할 수 있도록 하는 것입니다.

저장소 프로젝트 구조 자체에 통합되면 코딩 에이전트는 이를 마치 코드인 것처럼 유지합니다. 코드의 일부인 것처럼 읽고, 내용이 변경되면 문서를 조정하거나 수정합니다(“문서는 읽고 지우기 쉬운 코드입니다” 또는 “문서는 키보드를 떠나는 순간 오래된 것이 됩니다”를 기억하십시오. 이를 유지하는 AI를 신뢰하십시오. 따라서 더 이상 사실이 아닙니다).

제품, 마케팅 및 비기술 팀을 위한 두 번째 두뇌

이러한 유형의 두 번째 두뇌는 기술 팀에게는 정말 멋질 수 있지만 기술 팀이 아닌 팀에게는 동일한 작업을 수행하는 것이 매우 어려울 것입니다.

예를 들어 변호사 팀을 예로 들면, 그들은 매우 구체적인 지식 세트를 보유하고 있으며 이는 이메일, 슬랙, 워드 파일 및 기타 문서에 걸쳐 있습니다. 회계사, 영업, 고객 성공 등에 대해서도 마찬가지입니다. 그들은 각자 자신만의 두 번째 두뇌 지식을 가지고 있습니다.

또한 경영진은 데이터가 버블링(중간 경영진을 통해 필터링되지 않음)되기를 원할 수 있으며 팀에는 경영진이 생성한 정보가 필요할 수 있습니다. 보안되고 분리된 확장 가능한 지식 그래프를 제작하는 방법은 무엇입니까?

적어도 큰 소년들이 이 문제를 해결할 때까지는 개방형 방식으로, 그러나 값비싼 폐쇄형 솔루션을 통해 가능성이 더 높을 때까지 일을 더 쉽게 만들 수 있는 몇 가지 접근 방식이 있습니다.

1. 개인적인 두 번째 뇌 – 이를 원하는 각 사람은 자신의 회의를 기록하고 자신의 두 번째 두뇌를 유지할 수 있습니다. Obsidian은 이를 위해 매우 유용합니다. 모든 에이전트는 기본적으로 이를 정렬하고 정리할 수 있습니다. REM 절전 메커니즘을 사용하여 최적화하세요. 에이전트는 밤에 일어나서 낮에 수집한 모든 정보를 식별하고, 미래를 위해 보관해야 할 중요하고 중요한 정보를 찾아 폴더와 MD 파일에 쉽게 검색할 수 있는 방식으로 구성해야 합니다. 즉, 특정 고객과 대화한 경우 해당 고객에 대해 기억해야 할 중요한 정보, 함께 작업 중인 내용 등을 반영하는 md 파일이 업데이트된다는 의미입니다. 프로젝트도 마찬가지입니다. 중복이 있을 것입니다. 중복은 좋습니다. 특정 프로젝트에 대한 정보가 대화한 사람의 파일, 회사 및 프로젝트 파일 모두에 있어도 괜찮습니다. 상담원이 이를 관리하도록 하세요. 질문이 있는 경우 이를 에이전트의 기본 데이터 소스로 만드세요. 귀하의 에이전트를 귀하의 이메일/대화 등에 노출시킬 수 있습니다. – 문서화하고 싶지 않은 내용을 복사하지 않도록 주의하세요(리얼리티 쇼나 드라마로 만들지 말자).

2. 팀 레벨의 두 번째 두뇌 – 데이터의 두 번째 계층에는 에이전트가 전체 팀과 관련이 있다고 100% 확신하는 개인의 두 번째 두뇌에 있는 데이터 또는 본질적으로 팀 기반인 팀 수준 회의에서 생성된 데이터가 포함됩니다. 에이전트는 팀 슬랙 채널에서 이 두 번째 두뇌에 대한 데이터를 수집할 수도 있습니다. 1:1 채널이나 줌 통화에 있어서는 안 됩니다. 데이터를 검색하면 에이전트는 데이터를 실시간 또는 야간에 정리하고 결정이 뒤집혔거나 개인 또는 관리 결정과 일치하지 않는 불일치를 지적할 수 있습니다. 양립할 수 없는 결정을 내리는 사람에게 이러한 사항을 강조하고 경고하여 그들이 정보를 바탕으로 선택할 수 있도록 해야 합니다.

3. 관리 수준의 두 번째 두뇌 – 이것은 기본적으로 팀 수준의 두 번째 두뇌이지만 데이터와 결정의 민감도 때문에 훨씬 더 미묘한 방식으로 처리되어야 합니다. 회사의 나머지 부분으로의 유출 가능성을 방지하기 위해 최종 결정과 공개 데이터만 여기에서 공유되어야 합니다. 데이터 보안을 보장하기 위해 적어도 처음에는 사람이 데이터의 일부를 검토하는 것이 좋은 생각일 수 있습니다. 회사의 두 번째 두뇌에서 관리 두뇌를 분리하는 것도 좋은 생각입니다.

4. 전사적 제2의 두뇌 – 이것은 가장 어려운 것이며, 회사 전체와 관련될 수 있는 구체적이고 정보를 제공하는 데이터만 보유해야 합니다. 재무 결과만 보고됩니다(예: 직원에 대한 정보(누가 어떤 직책을 맡고 있는지)).

예를 들어 경영진이 전체 팀으로부터 듣고 싶어하는 감정 데이터를 포함하여 많은 데이터가 누락됩니다. 이는 별도로 수집하거나 Slack 및 기타 소스에서 수집할 수 있습니다. 이러한 유형의 데이터를 회사 두뇌에서 직접 수집하는 것은 좋은 생각이 아닙니다.

그렇다면 두 번째 두뇌 또는 회사 두뇌에서 무엇을 찾고 있습니까? 이를 구축하려고 시도한 적이 있으며 결론은 무엇입니까?