모든 AI 에이전트 세션은 새로운 마음(fresh mind)으로 시작됩니다. 어제의 기억도 없고, 지난주에 당신이 준 수정 사항에 대한 기억도 없으며, 귀사가 이미 무엇을 결정했는지에 대해서도 전혀 알지 못합니다.

하나의 프로젝트를 수행하는 한 명의 개발자에게는 이것이 괜찮을 수 있습니다. 하지만 다섯 개의 팀이 생기는 순간 상황은 무너집니다. 왜냐하면 이제 모든 곳에서 반드시 지켜져야 하는 사항들이 모든 프로젝트의 모든 세션에서 영원히 어떻게든 지켜져야 하기 때문입니다.

명백한 답은 좋은 프롬프트 (prompt)를 작성하여 각 프로젝트에 붙여넣는 것입니다. 하지만 이 답은 두 번 실패합니다. 첫째, 규칙의 복사본이 6개라는 것은 6개의 규칙이라는 뜻이기에 첫 주 만에 동기화가 어긋나기 시작합니다. 둘째, 붙여넣은 모든 줄은 영원히 모든 세션에서 비용(pay)을 치러야 하므로, 당신의 표준을 인코딩하는 문서가 모든 미래 작업에 대한 세금이 되어버립니다.

더 나은 답은 귀사가 이미 사람들에게 사용하고 있는 방식입니다. 바로 조직도 (org chart)에 의해 범위가 지정된 상속 (inheritance), 그리고 인간에게 질문할 수 있는 채널입니다.

여기에 아키텍처 (architecture)가 있으며, 그중 절반이 작동했다는 것을 보여주는 데이터가 뒤따릅니다.

복사하는 대신 상속되는 3단계 계층

1단계는 헌법 (constitution)입니다. 루트 (root)에 위치한 하나의 문서로, 그 아래에 있는 모든 프로젝트의 모든 세션에 의해 자동으로 로드됩니다. 여기에는 정체성과 결코 협상할 수 없는 사항들이 담겨 있습니다. 무엇이 증거로 간주되는지, '완료 (done)'가 무엇을 의미하는지, 스타일의 문제가 아닌 법적인 안전 경계 (safety boundaries) 등이 포함됩니다.

저의 경우 약 40줄로 제한되어 있는데, 이 제한은 깔끔함 때문이 아니라 설계 때문입니다. 여기 있는 모든 줄은 모든 프로젝트의 모든 세션에서 영원히 읽힙니다. 커져가는 헌법은 누군가 작업을 시작할 때마다 도착하는 청구서와 같습니다. 만약 어떤 규칙이 자신이 무엇을 하고 있는지 알기 전부터 모든 프로젝트에 필요하지 않다면, 그것은 1단계에 속해서는 안 됩니다.

2단계는 프로젝트 헌법 (project constitution)입니다. 오직 이 프로젝트에만 적용되는 진실입니다. 1단계를 무료로 상속받으므로, 1단계를 다시 기술하지 않습니다.

3단계는 그 외의 모든 것입니다. 저의 경우 수백 개의 문서가 해당됩니다. 이 중 어느 것도 시작 시점에 로드되지 않습니다.

비용이 볼륨(volume)과 반대로 움직인다는 점에 주목하십시오. 가장 작은 계층(tier)이 가장 비싼데, 이는 모든 사람이 항상 그 비용을 지불하기 때문입니다. 가장 큰 계층은 거의 무료에 가까운데, 무언가가 요청하기 전까지는 아무도 그 비용을 지불하지 않기 때문입니다. 대부분의 사람들은 이를 거꾸로 구축합니다. 즉, 거대한 컨텍스트(context)를 최상단에 배치하고는 왜 모든 세션이 느리고 비용이 많이 드는지 의아해합니다.

3단계(tier three)를 작동하게 만드는 메커니즘

아무도 읽지 않는 문서 더미는 메모리(memory)가 아닙니다. 그것을 메모리로 바꾸는 것은 **특정 동작(an action)**을 **그 동작을 하기 전에 반드시 읽어야 하는 것(the thing you must read before doing it)**에 매핑하는 2단계(tier two)의 짧은 테이블입니다. 결제 코드를 건드리기 전에 이것을 읽으십시오. 고객이 보는 것을 변경하기 전에 저것을 읽으십시오.

에이전트(agent)는 지식을 찾아다니지 않습니다. 지식은 그것이 필요한 동작의 순간에 전달됩니다.

이 차이점은 사소한 디테일처럼 들릴 수 있습니다. 하지만 이것은 제 시스템에서 작동했던 절반과 실패했던 절반을 가르는 결정적인 차이이며, 저에게는 그 수치가 있습니다.

인간이 개입하는 지점

에이전트 조직에는 두 가지 인간 채널이 필요하며, 이 둘은 서로 다른 것입니다.

**에스컬레이션 (Escalation)**은 에이전트가 "제가 결정할 수 없는 결정이 필요합니다"라고 말하는 것입니다. 운영 환경의 변경, 지출 약정, 혹은 되돌릴 수 없는 모든 것이 이에 해당합니다.

**캘리브레이션 (Calibration)**은 인간이 "그것은 틀렸으며, 틀린 형태는 이러합니다"라고 말하는 것입니다. 이것은 앞서 언급한 두 가지 중 더 가치 있는 것이며, 대부분의 설정에서 완전히 누락되는 부분이기도 합니다. 채팅창에만 머무는 수정 사항은 3주 후에 다시 비용을 지불하게 될 수정 사항일 뿐입니다.

두 가지 모두 귀사의 조직이 이미 사용 중인 채널을 통해 실행되어야 합니다. 대부분의 기업에는 그것이 Teams일 것입니다. Teams가 특별해서가 아니라, 사람들이 이미 열어두고 있는 알림 영역(notification surface)만이 유일하게 읽히는 영역이기 때문입니다. 저는 이를 위해 아름다운 대시보드들을 만들어 보았습니다. 저를 포함해 아무도 그것을 열어보지 않았습니다.

여기서는 스레드(thread)가 보기보다 중요합니다. 스레드는 수정 사항에 대해 수정 대상과 연결된 지속 가능한 거처를 제공하며, 이는 해당 수정 사항을 다시 2단계(tier two)로 통합하고자 할 때 정확히 필요한 원재료가 됩니다.

제가 이렇게 깔끔할 것이라고 예상하지 못했던 부분

조직도(org chart)를 범위 설정 모델(scoping model)로 받아들이는 순간, 대부분의 어려운 문제들은 더 이상 귀사의 문제가 아니게 됩니다.

신원 및 권한 (Identity and permission): 귀사의 기존 디렉터리. 에이전트는 귀사가 이미 관리하고 있는 디렉터리 내의 주체(principal)가 됩니다. 에이전트는 그룹에 가입하고, 해당 그룹의 권한을 상속받으며, 퇴사자가 권한을 회수되는 것과 정확히 동일한 방식으로 권한이 취소됩니다. 대안은 실제 모델 옆에 존재하며 실제 모델로부터 점차 벗어나게 되는 두 번째 권한 모델을 만드는 것인데, 이는 결국 모든 이가 보고서를 작성하게 되는 보안 사고(security incident)로 이어집니다.

이는 모든 리스크 관리 팀이 가장 먼저 던지는 질문에 대한 답이기도 합니다. 그 질문은 "AI가 정확한가"가 아니라 "AI가 어디까지 접근할 수 있으며, 누가 그것을 결정했는가"입니다. 만약 그 답이 "이 업무를 수행하는 인간을 관리하는 것과 동일한 그룹"이라면, 귀사는 완전히 다른 차원의 대화를 나누게 될 것입니다.

계층 (The tiers): 귀사의 기존 문서 저장소. 1단계(Tier one)는 모든 사람이 읽고, 복사하기보다는 참조하는 사이트입니다. 따라서 규칙의 변경은 아무도 알아차리지 못한 편집이 아니라, 검토 가능하고 버전이 관리되는 이벤트가 됩니다. 2단계(Tier two)는 업무를 소유한 팀과 함께 존재하므로, 경계는 누군가 화요일에 임의로 만들어낸 폴더 관례가 아니라 회사가 이미 합의한 경계가 됩니다. 그리고 개인적 범위(personal scope)는 개인 저장소에 들어갑니다. 이는 기본적으로 비공개이며, 개인을 따라다니고, 실수로 공유 계층으로 유출될 수 없습니다. 왜냐하면 명명 규칙(naming rule)이 아닌 권한(permission)이 경계이기 때문입니다.

감사 (Audit): 귀사의 기존 감사 로그 (audit log). 누가 에이전트에게 무엇을, 언제 말했는가. 귀사는 에이전트를 위한 감사 시스템을 처음부터 구축하는 대신, 그 답을 그대로 상속받습니다.

이 중 그 어떤 것도 구매해야 할 제품이 아닙니다. 그것이 핵심입니다. 에이전트 플랫폼의 지루한 부분들, 즉 신원(identity), 범위 설정(scoping), 감사(audit), 그리고 인간이 실제로 읽는 채널은 바로 귀사가 수년 전 직원들을 위해 이미 해결해 놓은 부분들입니다. 에이전트 조직은 이를 재발명하여 더 약한 복사본을 만드는 것이 아니라, 이를 그대로 상속받아야 합니다.

신호(Signal), 그리고 프라이버시 설계가 데이터 품질 메커니즘인 이유

정보가 상위 계층으로 흐르지 않는다면, 상위 계층은 허구에 불과합니다. 하지만 개인의 정체성이 상위로 흐른다면, 당신은 감시 체계(surveillance)를 구축한 것이며, 감시는 당신이 수집하려 했던 대상 자체를 파괴합니다.

해결책은 신호(signal)가 사람이 아닌 패턴(pattern)을 전달하는 것입니다.

허용됨: "이번 달에 4명의 사용자가 이 표준이 불분명하다고 표시했습니다"
허용되지 않음: "Sarah가 이를 4번 표시했습니다"

정체성은 팀 계층(team tier)에서 제거됩니다. 그 이상의 모든 계층은 패턴만을 수신하며, 구조적으로 역추적(reverse lookup)이 불가능합니다. 이 마지막 조항이 중요한 이유는, 이것이 누군가가 지키겠다고 약속한 정책(policy)이 아니라, 권한(permissions)과 집계(aggregation)가 구축되는 방식의 구조적 속성(structural property)이기 때문입니다.

또한 임계값(threshold)이 존재합니다. 단일 이벤트는 패턴이 아니므로, 동일한 유형의 신호가 여러 번 나타날 때까지 아무것도 상위로 격상되지 않습니다. 이를 통해 단 한 번의 좋지 않은 오후가 조직의 트렌드로 상향 보고되는 것을 방지합니다.

지배적인 형태는 다음과 같습니다: 개인적인 진실(private truth), 그다음은 익명의 패턴(anonymous patterns), 마지막으로 조직적 지능(organizational intelligence)입니다.

이것이 윤리적 장식(ethics decoration)이 아닌 엔지니어링인 이유는 다음과 같습니다. 만약 사람들이 자신의 개인적 계층이 자신에게 불리하게 사용될 수 있다고 믿는다면, 그들은 보여주기식(performatively)으로 데이터를 입력할 것입니다. 보여주기식 입력은 거짓된 패턴을 생성합니다. 거짓된 패턴은 조직의 상층부에서 확신에 찬 잘못된 결정을 내리게 하며, 이는 시스템이 아예 없는 것보다 더 나쁩니다. 시스템의 전체적인 지능 가치는 최하위 계층이 진정으로 프라이빗(private)하다는 점에 달려 있으므로, 프라이버시 보장은 하중을 견디는 기반 시설(load-bearing infrastructure)입니다.

스스로를 개선하게 만드는 루프

저장만 하는 메모리 시스템은 서류 보관함에 불과합니다. 이를 복리로 성장하게 만드는 것은 질문을 라우팅(routing)하는 것입니다.

누군가가 어시스턴트에게 표준이나 정책에 대해 질문할 때:

• 교정된 답변(calibrated answer)이 존재하는 경우, 정확한 버전을 인용하여 즉시 답변하고 해당 질문을 기록(log)합니다.
• 답변이 존재하지 않는 경우, 임의로 답변을 만들어내지 말고 다음으로 넘어갑니다. 이를 해결되지 않은 엣지 케이스(edge case)로 표시하고 해당 표준의 소유자에게 라우팅(route)합니다.
• 동일한 질문이 반복해서 나타나는 경우, 이는 여러 명의 사람이 혼란스러워하는 것이 아닙니다. 그것은 하나의 모호한 표준이며, 그에 따라 에스컬레이션(escalation)되어야 합니다.

마지막의 이 역발상이 바로 가치 있는 부분입니다. 규칙에 대해 세 사람이 같은 질문을 한다는 것은 사람들에 대한 증거가 아니라, 규칙에 대한 증거입니다. 대부분의 조직은 이를 반대로 해석하여 세 사람을 교육 현장으로 보냅니다.

축적되는 질문 로그는 설문 조사나 포커스 그룹 없이도, 조직이 어디에서 혼란을 겪고 있는지를 지속적으로 생성해내는 실시간 지도 역할을 하게 됩니다.

이제 실패한 절반에 대하여

나는 한 가지 요소를 더 추가했습니다. 각 프로젝트 세션이 끝날 때 무엇이 변했는지 한 줄을 작성하여 프로젝트 간 요약(cross-project summary)에 반영하는 공유 로그(shared log)였습니다.

22일 후, 나는 실제로 그 안에 무엇이 들어있는지 확인했습니다.

단 10개의 항목. 그중 8개는 처음 3일 사이에 작성되었습니다. 나머지 하나는 11일 전에 작성되었습니다. 그 이후로는 아무것도 없었습니다.

5개의 프로젝트 중 10개 항목 모두가 단 하나의 프로젝트에서 나왔습니다. 실제 고객과 함께 진행 중인 라이브 프로젝트는 단 한 줄도 작성하지 않았습니다.

이 레이어(layer)가 존재했던 유일한 이유인 공유 요약(shared summary)은 생성된 당일에 마지막으로 수정되었습니다. 그것은 여전히 8일 후에 내가 폐기한 껍데기 폴더를 프로젝트라고 자신 있게 설명하고 있습니다. 그것은 단순히 오래된 것이 아닙니다. 그것은 틀렸으며, 틀린 상태로 권위 있어 보이기까지 합니다. 이는 비어 있는 것보다 훨씬 더 나쁩니다.

내가 미처 알아차리지 못한 스키마 드리프트(schema drift)도 있었습니다. 타임스탬프(timestamp)가 첫 번째 행에서는 정수(integer)이고 마지막 행에서는 포맷된 문자열(formatted string)이었습니다. 이 모든 것을 분석하기 위해 작성한 스크립트가 이 부분에서 충돌(crash)하며 멈춘 후에야 비로소 알게 되었습니다.

왜 죽었는지, 그리고 왜 3단계(tier three)는 죽지 않았는지

설계는 괜찮았습니다. 트리거(trigger)가 문제였습니다.

그 코드를 작성하는 것은 기억에 의존한 행위였습니다. 아무것도 그것을 실행(fire)시키지 않았습니다. 그것은 세션의 끝에 놓여 있었고, 누군가가 피곤하고 업무를 마친 상태에서 그것을 하기로 선택하는 것에 의존했습니다. 그런 방식은 약 3일 정도만 작동합니다.

3단계(tier three)가 작동하는 이유는 그것이 하나의 행위(act)에 결합되어 있기 때문입니다. 파일을 건드리면, 규칙을 가져옵니다. 규칙이 존재한다는 것을 누군가 기억해야 하는 것에 의존하는 것은 아무것도 없습니다.

동일한 시스템. 동일한 주. 동일한 작성자. 유일한 차이점은 무엇이 쓰기(write)를 시작하느냐입니다.

남아있는 모든 의구심을 제거할 두 번째 사례가 있습니다. 저는 운영상의 답변을 위한 조회 테이블(lookup table)을 만들고, 8개의 행으로 초기화한 뒤, 에이전트에게 진행하면서 이를 추가하라고 명령했습니다. 하루 뒤에 그 테이블은 여전히 8개의 행이었습니다. 추가된 것은 0개였지만, 같은 날의 작업 과정에서 자격을 갖춘 항목이 최소 3개는 생성되었고 그것들은 다른 어딘가에 저장되었습니다. 테이블에 행이 더 필요했던 것이 아닙니다. 테이블에는 트리거(trigger)가 필요했습니다.

법칙

기억에 의존하는 모든 것은 일어나지 않습니다. 그것을 행위에 결합하십시오. 그렇지 않으면 그것은 존재하지 않는 것입니다.

에이전트가 부주의해서가 아닙니다. 모든 세션은 해당 습관에 동의했다는 기억이 없는 새로운 마음(fresh mind)이기 때문입니다. 건망증 환자들에게 분산된 선의만으로는 조직적 기억(organizational memory)을 구축할 수 없습니다.

그리고 풀 기반(pull-based) 시스템은 가능한 가장 그럴싸한 방식으로 실패합니다. 파일은 여전히 그곳에 있습니다. 설계는 여전히 다이어그램 상에서 잘 읽힙니다. 아무런 오류도 발생하지 않습니다. 여러분이 직접 가서 행의 개수를 세어보기 전까지는 알 수 없습니다. 이것이 바로 여러분이 직접 가서 행의 개수를 세어봐야 하는 이유입니다.

제가 대가를 치르고 배운 두 가지 결론은 다음과 같습니다:

읽기 측면(read side)도 푸시(pushing)가 필요합니다. 저는 누군가가 요약본을 열어볼 것이라고 가정했습니다. 작성자를 포함해 아무도 3주 동안 열어보지 않았습니다. 누구에게도 전달되지 않는 요약본은 아무도 읽지 않는 요약본입니다. 세션 시작 시점에 자극 없이(unprompted) 이를 노출시키거나, 아니면 그것이 존재하지 않는다는 사실을 받아들이십시오.

파생된 모든 것에는 최신성 확인(freshness check)이 필요합니다. 조용히 11일 동안 방치된 대시보드는 대시보드가 없는 것보다 더 나쁩니다. 여전히 정답처럼 보이기 때문입니다. 생성된 시점을 표시하고, 그 시점이 오래되면 경고를 보내도록 만드십시오.

만약 당신이 이것을 구축하고 있다면

제가 다시 한다면 수행할 순서는 다음과 같습니다:

1. 1단계(tier one) 규칙을 작성하고 제한하십시오. 40줄 이내로 작성하십시오. 만약 40줄 안에 설명할 수 없다면, 그것은 2단계(tier two) 규칙이 변장하고 있는 것입니다.
2. 문서(documents)를 만들기 전에 트리거 테이블(trigger table)을 구축하십시오. 전달 메커니즘(delivery mechanism)이 곧 제품입니다. 문서는 재고(inventory)일 뿐입니다.
3. 첫 번째 신호(signal)를 보내기 전에 프라이버시 경계(privacy boundary)를 설정하십시오. 사람들이 이미 불신하고 있는 시스템에 사후적으로 익명성(anonymity)을 끼워 맞출 수는 없습니다.
4. 에이전트를 디렉토리(directory)에 배치하십시오. 맞춤형 설정(bespoke config)이 아닌 그룹(groups) 단위로 관리하십시오. 권한 회수(deprovisioning)는 첫날부터 이미 작동해야 합니다.
5. 에이전트가 필요하기 전에 에스컬레이션(escalation) 기능을 채팅 도구에 연결하십시오. 에이전트가 처음으로 사람의 개입을 필요로 하는 시점이 해당 채널을 처음 테스트하는 시점이 되어서는 안 됩니다.
6. 교정(calibration) 비용을 낮게 만드십시오. 에이전트를 교정하는 데 답장 한 번 이상의 시간이 걸린다면, 교정은 일어나지 않을 것이며 당신은 동일한 오류에 대해 반복적으로 비용을 지불하게 될 것입니다.
7. 그다음에, 오직 그때만 상향 흐름(upward flow)을 구축하십시오. 그리고 이를 선한 의도(good intention)가 아닌, 업무 종료 시점에 이미 일어나고 있는 무언가에 결합하십시오.