인지적 인프라로서의 AI (AI as Cognitive Infrastructure)

대부분의 팀은 더 나은 모델을 쫓고 있습니다. 저는 반대로 모델을 중심으로 더 나은 시스템을 구축했습니다. 문맥(context)을 유지하고, 정의된 역할을 수행하며, 제가 할 일을 피하고 있을 때 반박까지 하는 21가지 역할의 AI 설정입니다. 이것이 작동하는 방식이며, 왜 스캐폴딩(scaffolding, 비계)이 모델 자체보다 더 중요해졌는지에 대한 이야기입니다.

저는 홈랩(homelab) 관련 결과물을 출시할 계획이었습니다. 몇 가지 장애물에 부딪혔고(별도의 포스트 예정), 그 에너지는 실제로 도달할 수 있는 곳인 '메타(meta)'적인 부분으로 향했습니다. 그래서 저는 이러한 글쓰기 과정에서 Claude와 협업하는 방식을 개선하는 쪽으로 방향을 틀었습니다. 그 전환 과정에서 나온 프레임워크가 바로 이 글의 주제입니다. 이것은 다음으로 저의 홈랩 작업을 이끌 것이며, 이후 로컬 인프라에 배포하고자 하는 에이전트 네트워크(agent-network) 구축으로 확장될 것입니다. 동일한 엄격함이 재무 및 투자, 건강 및 피트니스, 주택 개량, 운영 및 유지보수, 그리고 제가 장기 프로젝트로서 접하는 거의 모든 것에 적용될 것입니다.

I. 프레임 (The frame)

대부분의 사람들이 AI를 사용하는 방식의 문제점

대부분의 지식 노동자들은 AI를 문법이 더 나은 비싼 검색 엔진처럼 취급합니다. 질문을 던지고, 답을 얻고, 다음으로 넘어갑니다. 각 대화는 차갑게(cold) 시작됩니다. 각 출력물은 개별적으로 판단됩니다. 시스템은 그것을 사용하는 사람, 그 사람이 하는 일, 또는 그 사람이 막히는 패턴에 대해 결코 더 똑똑해지지 않습니다.

그것은 AI의 활용이 아닙니다. 그것은 자동 완성(autocomplete)의 활용일 뿐입니다.

여기서 "인지적 인프라 (cognitive infrastructure)"가 의미하는 것

변화의 핵심: AI를 무언가가 필요할 때 호출하는 도구로 취급하는 것을 멈추십시오. 대신 그것을 작업이 실행되는 기질(substrate)로 취급하기 시작하십시오. 이 기질은 지속되고, 문맥(context)을 축적하며, 정의된 역할을 수행하고, 자신의 행동을 적절히 제어하며, 당신이 해야 할 일을 피하고 있을 때 당신에게 반박합니다.

이를 위해서는 의도적으로 기질을 구축해야 합니다. 기반이 되는 모델이 아무리 훌륭하더라도, 이것은 우연히 일어나지 않습니다.

신경다양성 (ND) 관점 (이것이 왜 어떤 사람들에게 더 중요한가)

저는 심각한 ADHD를 앓고 있으며 자폐 스펙트럼(autism spectrum)에 속해 있습니다. "정해진 일정에 따라 X를 하는 것을 기억하세요"라는 말은 저에게 있어 확실한 실패 모드(failure mode)입니다. "수 주간 지속되는 글쓰기 프로젝트 동안 주의력의 적절한 컨텍스트 윈도우(context window)를 유지하라"는 말도 마찬가지입니다.

그것이 바로 AI가 존재하는 이유입니다. AI는 전문 지식과 프로세스 개선에 대한 접근성을 민주화합니다. 완벽하게는 아닙니다. 노력 없이 이루어지는 것도 아닙니다. 하지만 그 아래에 기질(substrate)을 구축하고 나면, 의미 있는 변화가 일어납니다.

제가 여기서 누구를 대체하고 있는지에 대해 솔직하게 말씀드리겠습니다. 아무도 없습니다. 저는 제 Substack을 위해 개발 편집자(developmental editor)를 고용할 생각이 없었습니다. 브랜드 컨설턴트를 고용할 생각도 없었습니다. 그럴 여유가 없었을 뿐만 아니라, 고용하지도 않았을 것입니다. 제 경우 AI는 해당 전문가들의 비즈니스를 뺏어가는 것이 아니라... 결코 그들의 고객이 될 수 없었던 사람에게 그들이 제공하는 가치의 유용한 그림자(shadow)를 얻을 수 있게 해주는 것입니다.

이 일을 생업으로 하는 사람들에게 AI가 미치는 영향을 과소평가하고 싶지는 않습니다. AI는 어떤 형태로든 우리 모두에게 부정적인 영향을 미칠 것입니다. 하지만 패를 잘 활용한다면, 여러분은 AI의 파도를 타고 스스로를 더 나은 사람, 더 유능한 운영자, 더 사려 깊은 작가로 만들 수 있습니다. 그것이 우리 중 누구라도 통제할 수 있는 전부입니다.

여기서 제시한 프레임워크는 글쓰기를 위한 것이지만, 이는 일반화될 수 있습니다. 여러분이 지식 노동자(knowledge worker)이든, 크리에이터(creative)이든, 소상공인이든, 혹은 한정된 시간과 에너지 속에서 장기적인 프로젝트를 수행하는 누구든, 이것은 여러분에게 시작점을 제공할 것입니다. 구체적인 역할은 저의 사례일 뿐이며, 구조는 일반적입니다.

이것이 지금 왜 중요한가

LLM(대규모 언어 모델)들이 정체기에 접어들기 시작했습니다. GPT-3에서 GPT-4로 이어지는 능력 곡선은 수직에 가까웠습니다. 하지만 그 이후의 곡선은 그렇지 않았습니다. 그리고 이 기술들의 실체가 무엇인지에 대해 솔직해집시다. 이것들은 방대한 인간 지식 코퍼스(corpus)를 바탕으로 학습된 예측 엔진(prediction engines)입니다. George Carlin이 말했듯이, "평균적인 사람이 얼마나 어리석은지 생각해보십시오. 그리고 그들 중 절반은 그보다 더 어리석다는 사실을 깨달으십시오." 넓게 말해서, LLM이 통계적으로 집계한 코퍼스가 바로 그러한 것입니다. 그것이 아무것도 아니라는 뜻은 아닙니다. 하지만 마케팅에서 주장하는 것처럼 천재적인 협업자라는 뜻도 아닙니다.

이는 모델이 충분히 똑똑해지기를 기다리는 것이 핵심이 아니라는 것을 의미합니다. 모델은 그저 모델일 뿐입니다. 중요한 것은 그 모델을 중심으로 시스템을 구축하여 필요한 가드레일(guardrails)을 제공하고, 실제로 활용하고자 하는 전문 지식을 큐레이션하는 것입니다. 실제 학문 분야에 기반을 두고 있고, 실제 동료 전문가들이 있으며, 명시적인 게이팅 바(gating bars)와 안티패턴(anti-patterns)까지 갖춘 스물한 가지 역할들... 이것이 바로 큐레이션입니다. 모델은 강력한 핵심 역량일 뿐이고, 시스템이야말로 그 역량을 복리화(compounds)하여 무언가로 만드는 것입니다.

LLM(대규모 언어 모델) 자체가 AGI(범용 인공지능)가 되지는 않을 것입니다. LLM은 계속해서 점진적으로 더 좋아지고, 점진적으로 더 저렴해지며, 점진적으로 더 통합될 것입니다. '언제든 AGI에 도달할 것'이라는 이야기는 수년 동안 반복되어 왔습니다. 모델만으로 문제를 해결할 것이라는 가정 하에 작업을 구축하는 것은 실패한 베팅입니다. 모델에 잘 설계된 기질(substrate)이 결합하여 지금 당장 유용한 무언가로 복리화될 것이라는 가정 하에 작업을 구축하는 것이 성공적인 베팅입니다.

II. 아키텍처

채팅이 아닌 단계 (Phases, not chats)

대부분의 사람들의 AI 작업 흐름은 그들이 사용한 채팅 기록에 의해 형성됩니다. 즉, 대화를 열고 무언가를 입력하고 응답을 확인하다가, 나중에 다시 찾아야 할 때 며칠 동안 맥락을 놓치는 식입니다.

더 좋은 방법은: 작업의 단계를 명시적으로 정의하는 것입니다. 글쓰기의 경우, 제가 사용하는 기사별 파이프라인에는 열 가지 단계가 있습니다... 포착(Capture), 분류(Triage), 리서치 및 개요 작성(Research + outline), 초안 작성(Draft), 편집(Edit), 독자 대리인 및 위험 검토(Reader-proxy + risk pass), 출판 전 작업(Pre-publish ops), 출판(Publish), 교차 게시 및 재활용(Cross-post + repurpose), 출판 후 포착(Post-publish capture). 각 단계는 명확한 진입점과 종료점을 가집니다. 각 단계에는 하나 이상의 역할이 대기하고 있습니다. 각 단계는 다음 단계가 소비할 특정 결과물을 산출합니다.

단계는 또한 출판 수준에서도 존재합니다: 전략 및 속도 조절(Strategy & pacing), 비동기 아이디어 탐색(Async idea sweep), 시스템 유지보수(System maintenance). 이들은 어떤 단일 기사에 국한되지 않으며, 자체적인 주기(cadence)로 실행됩니다.

어시스턴트가 아닌 역할 (Roles, not assistants)

각 단계 내부에서 AI는 특정 역할을 수행합니다. 'AI 어시스턴트' 같은 것이 아닙니다. 구체적인 역할입니다. 현재 제가 구축한 시스템에는 스물한 가지의 역할이 있습니다:

글쓰기 기술 (Writing craft): 개발 편집자 (Developmental editor), 라인 에디터 (Line editor) + 보이스 가디언 (voice guardian), 타겟 오디언스 프록시 (Target-audience proxy), 글쓰기 멘토 (Writing mentor), 코치 (Coach)
전략 및 브랜드 (Strategy & brand): 콘텐츠 및 미디어 전략가 (Content & media strategist), 브랜드 매니저 (Brand manager), 퍼스널 브랜드 전략가 (Personal brand strategist), 비즈니스 매니저 (Business manager)
리스크, 품질, 법률 (Risk, quality, legal): 품질 및 리스크 검토자 (Quality & risk reviewer), 법률/지식재산권(IP) 어드바이저 (Legal/IP advisor), 연구원/아카이비스트 (Researcher/archivist)
배포 및 오디언스 (Distribution & audience): 멀티 채널 리퍼포저 (Multi-channel repurposer), 소셜 미디어 매니저 (Social media manager), 커뮤니티 및 인게이지먼트 전략가 (Community & engagement strategist), 분석 분석가 (Analytics analyst), 그래픽 디자이너 (Graphic designer)
운영 및 장기적 관점 (Operations & long game): 편집 캘린더 / 퍼블리싱 운영 (Editorial calendar / publishing ops), 비동기 프로세스 파트너 (Async process partner), 시스템 관리자 (Systems steward), 북 아키텍트 (Book architect)

각 역할은 정의된 미션, 실제 전문 분야에 근거한 베스트 프랙티스(인용 포함), "[X]라면 어떻게 생각할까"를 판단하기 위한 참조점으로서 이름이 명시된 동료 전문가, 명시적인 게이팅 바(Gating bars, 해당 역할이 자율적으로 할 수 있는 것 vs 먼저 제안해야 하는 것 vs 승인 없이 절대 할 수 없는 것), 역할 간의 경계에서의 인수인계(handoffs), 그리고 명시된 안티 패턴(anti-patterns)을 가지고 있습니다.

이것이 바로 "검색 엔진으로서의 AI"라는 프레임을 깨뜨리는 움직임입니다. AI는 도움을 주려고 노력하는 하나의 존재가 아닙니다. 명시적인 기본 규칙을 가진 21명의 기능적 전문가들입니다.

게이팅 (Gating): 구조적인 사항에 대해서는 실행 전 제안할 것

모든 역할에 관통하는 보편적인 규칙은 다음과 같습니다: 구조적, 전략적, 또는 범위를 변경하는 사항에 대해서는 실행하기 전에 반드시 제안해야 합니다. 사소한 편집(오타 수정, 엠 대시(em-dash) 정리, 가벼운 문장 재구성)은 그냥 진행됩니다. 작업의 형태를 바꿀 수 있는 모든 것은 제가 승인할 때까지 기다립니다.

III. 근거 (The grounding)

역할에는 분위기(vibes)가 아닌 실제 전문 지식이 필요하다

각 역할이 일반적인 AI 조언의 모음이라면 21개의 역할은 아무런 의미가 없습니다. 각 역할의 사양(spec)은 그것이 대변하는 실제 전문 분야에 근거해야 합니다.

패턴: 각 역할에 대해 해당 분야의 잘 확립된 베스트 프랙티스(best practices) 47개를 명시하고, 각 항목에는 신뢰할 수 있는 출처를 인라인 인용(inline citation)으로 포함합니다. Wikipedia는 시작점으로 괜찮습니다. 더 잘 알려진 산업계 출처나 동료 검토(peer-reviewed)를 거친 출처를 사용할 수 있다면 더 강력합니다. 해당 분야에서 인정받는 35명의 전문가를 짧은 설명 및 링크와 함께 명시합니다.

그다음 커스터마이징(customize)합니다. 해당 분야의 기본 설정이 당신의 목소리, 윤리, 또는 특정 제약 조건과 충돌하는 경우, 그 충돌 지점을 명시하고 해결책을 제시하십시오. 일치하는 경우에는 짧게 언급하십시오.

이것이 대부분의 사람들이 건너뛰는 작업입니다. 이 과정이 없다면, AI의 "발전적 편집 (developmental editing)"은 모델이 발전적 편집이 무엇일 것이라고 생각하는 그 무엇이 되어버립니다. 이 과정이 있다면, 발전적 편집자 역할은 Maxwell Perkins, Robert Gottlieb, Toni Morrison, 그리고 Gordon Lish(마지막 인물은 주의해야 할 반면교사(anti-model)로서, 다음 섹션에서 다룸)에 근거를 두게 됩니다.

Wikipedia가 적절한 시작점인 이유 (종착점이 아닌 이유)

Wikipedia는 해당 분야의 정전적 프레임워크(canonical framing), 명명된 인물들, 그리고 방어 가능한 기준선(baseline)을 제공합니다. 그 후 중요한 부분에서 더 깊이 파고드는 것입니다. 핵심은 해당 분야의 합리적인 실무자가 인식할 수 있는 무언가에 역할을 근거(grounding)를 두는 것이지, 모델이 실제 근거 없이 그럴싸하게 들리는 전문성을 꾸며내는 것이 아닙니다.

그에 따른 결론: 학습 데이터(training data)는 항상 과거의 것이며, 그 격차는 점점 벌어집니다. 빠르게 변화하는 분야(AI 스택, 소셜 플랫폼, 분석 도구 등 무엇이든)의 경우, 역할은 회상(recall)하기보다 검색(search)해야 합니다. 정적인 참조 자료에 역할을 근거를 두는 것은 바닥(floor)입니다. 이를 최신 상태로 유지하는 것이 천장(ceiling)입니다.

IV. Lish의 교훈

시스템의 모든 역할 중에서, 발전적 편집자는 방치할 경우 공동 저자(co-authorship)로 흘러 들어갈 가능성이 가장 높은 역할입니다. 이는 가설적인 위험이 아닙니다. 유명한 실제 사례가 존재합니다.

Gordon Lish는 1970년대와 80년대에 Esquire와 Knopf의 편집자였으며, Raymond Carver가 가장 찬란하게 빛나던 시기에 그의 편집자였습니다. Lish는 Carver의 단편들을 공격적으로 삭제했습니다. 어떤 경우에는 절반 이상을 잘라내기도 했습니다. 그는 결말을 재구성했고, 제목을 바꾸었습니다. 당시 Carver는 이러한 삭제를 받아들였으나, 나중에는 이를 깊이 후회하며 죽기 전에 자신의 원본을 출판하기 위해 싸웠습니다. 한 세대의 미국 단편 소설을 정의했던 미니멀리즘적이고 강렬한(gut-punch) Carver의 모습은 실질적으로 Lish의 편집적 손길이 가미된 결과였습니다. 그의 미망인은 사후에 편집되지 않은 버전들을 _Beginners_라는 이름으로 출간했고, 비평가들의 합의는 불편한 결론에 도달했습니다. 즉, 유명한 Carver는 Lish와 Carver의 협업(collaboration)이었으며, 작가 본인이 결국 거부한 결과물이었다는 것입니다.

이것은 자신의 워크플로(workflow)에 AI 개발 편집자(developmental editor)를 연결하려는 모든 이들에게 주는 경고의 메시지입니다. 모델은 이 작업에 능숙합니다. 어떤 경우에는 무서울 정도로 능숙합니다. 모델은 기꺼이 당신의 논증을 재구성하고, 당신이 쓴 것보다 더 깔끔하게 산문(prose)을 다듬으며, 당신이 입력한 것보다 더 "출판된 것 같은" 버전으로 돌려줄 것입니다. 만약 당신이 이를 비판 없이 수용한다면, 출판된 버전은 더 이상 당신의 것이 아닙니다. 그것은 기계의 속도로 일어나는 Lish-Carver 문제입니다.

해결책은 느낌(vibes)에 의존하는 것이 아니라 구조적인 것이어야 합니다. 제 시스템에서 개발 편집자(developmental editor)의 역할은 명시적으로 게이트(gated)가 설정되어 있습니다. 즉, 변경을 수행하기 전에 구조적 변경 사항을 먼저 제안하도록 되어 있습니다. 문구(phrasing)나 어조(tone)를 의미 있게 변경하는 모든 작업에 대해 문장 편집자(line editor)는 더 엄격하게 게이트가 설정되어 있습니다. 이 시스템은 제 목소리로 된 차가운 초안(cold drafts)을 생성하지 않습니다. 단호하게 말씀드립니다. 그것은 이 빌드(build)에서 Claude가 수행하는 역할이 아니며, 작업 협약(working agreement) 상단의 "Claude가 수행하지 않는 역할" 목록에도 명시되어 있습니다.