디지털 에이전시를 위한 AI 파트너

저는 작은 디지털 에이전시를 운영하고 있습니다. SEO, 광고, 소셜 미디어를 매일 관리하는 외주 전문가 팀은 있지만, 전략은 오직 저만의 것입니다. 공동 창업자도, 방향성에 대해 논쟁할 파트너도 없습니다. 수년 동안 그것은 괜찮았고, 어떤 특정한 면에서는 아무도 말해주지 않는 장점이기도 했습니다. 방향이 한 사람의 결정일 때, 다섯 명이 아무도 책임지지 않는 결정을 다시 논쟁하는 회의나 Slack 스레드 때문에 무언가를 잃지 않기 때문입니다. 무언가를 보고, 결정하고, 점심때까지 실행합니다. 논의하고 재논의할 것이 없습니다. 그냥 실행할 뿐입니다.

함정은 그 자유의 이면입니다. 운영(Operations)은 결코 끝나지 않습니다. 항상 처리해야 할 클라이언트 이메일이 하나 더 있고, 송장이 하나 더 있으며, 내일이 오기 전에 꺼야 할 작은 불이 하나 더 있습니다. 그리고 전략적 작업 — 어떤 클라이언트, 어떤 제안, 어떤 방향인가 — 는 마감 기한도 없고, 이를 보호하는 것이 업무인 사람도 없습니다. 그래서 전략은 밀려납니다. 당신이 바쁘게 지내는 동안 몇 달 동안 조용히 밀려납니다. 생산적이라고 느끼면서 동시에 표류할 수 있으며, 혼자 있을 때는 그 표류를 지적해 줄 사람이 방 안에 아무도 없습니다.

약 6개월 전, 저는 비즈니스의 전략적인 측면에 별도의 구조화된 계층을 부여하여 운영 측면에 밀리지 않도록 했습니다. 그 계층은 두 가지를 기반으로 작동합니다:

OKRs — 프레임워크(Framework)입니다. 이는 "내가 무엇을 해야 하는가"를 제가 실제로 책임을 질 수 있는 작고 측정 가능한 약속들로 바꿔줍니다.
Ksen — 이 프레임워크를 실행하는 AI 파트너입니다. 막혔을 때 질문을 던지는 챗봇(Chatbot)이 아닙니다. 규칙, 목표, 컨텍스트(Context)가 담긴 Git 리포지토리(Repository)로 구성된 Claude Code 인스턴스이며, 저는 매주 정해진 주기(Cadence)에 맞춰 이와 함께 앉아 전략을 제안하고, 도전하고, 검토합니다.

이 포스트는 그것이 어떻게 작동하는지에 관한 것입니다. 먼저 프레임워크(Framework)를, 그다음 파트너를, 그리고 — 궁금해하실 분들을 위해 — 그것이 정확히 어떻게 구축되었는지를 다룹니다. 저는 진행 과정에서 이것이 무엇이고 무엇이 아닌지에 대해 솔직하게 말씀드릴 것입니다. 왜냐하면 대부분의 가치는 인상적으로 들리지 않는 부분에 존재하기 때문입니다.

왜 OKR인가 — 전략에 마감 기한을 부여하는 프레임워크

닉 보스트롬(Nick Bostrom)은 그의 저서 _슈퍼인텔리전스(Superintelligence)_에서 목표 명세(Goal specification)를 고도화된 AI의 핵심 리스크로 지목했습니다. 자연어 목표는 설계자가 전혀 의도하지 않은 해석의 여지를 남기기 때문입니다. OKR은 정확히 그 문제의 인간 버전을 위해 발명되었으며, 해결책도 동일합니다. 작업이 시작되기 전에 목표를 측정 가능한 용어로 강제하는 것입니다.

OKR은 목표(Objective, 당신이 가고자 하는 곳)와 몇 가지 핵심 결과(Key Results, 그곳에 도달했음을 알리는 측정 가능한 신호)의 조합입니다. 목표는 짧고, 평이하며, 야심 차게 유지됩니다. 무엇을 말하는지 파악하기 위해 세 번은 읽어야 하는 SMART 목표와는 다릅니다. 반면 핵심 결과(Key Results)는 정밀함을 더합니다. 이것들은 생산성 해킹(Productivity hack)이 아닙니다. 모호한 의도를 '틀릴 수도 있는 무언가'로 변환하는 강제 함수(Forcing function)입니다.

1인 운영자에게 그 강제 함수가 바로 핵심입니다. 전략이 어긋나는 이유는 무엇이 중요한지 모르기 때문이 아닙니다. '무엇이 중요한가'가 모호한 상태 — 즉, 약속이 아닌 느낌 — 로 남아 있기 때문이며, 모호한 것들은 매번 송장(Invoice)에 패배합니다. 세 개의 핵심 결과(Key Results)가 붙은 목표(Objective)는 운영(Operations)에는 항상 있지만 전략(Strategy)에는 결코 없는 한 가지를 가집니다. 바로 이번 주에 당신이 뒤처져 있는지 여부를 판단할 수 있는 방법입니다.

OKR은 또한 의사결정에 심판을 제공합니다. 제가 기능 X(Feature X)를 출시할지 말지 고민할 때, "제 생각에는 그래야 할 것 같아서"는 이유가 아니라 선호(Preference)일 뿐입니다. "기능 X는 대안보다 KR2(월 10건의 인바운드 컨설팅)를 더 잘 뒷받침한다"는 이유가 됩니다. 이 차이가 아래에서 설명할 파트너십을 가능하게 만드는 핵심입니다. Ksen과 저는 취향을 두고 다투는 것이 아니라, 우리가 이미 합의한 숫자를 어떤 경로가 더 잘 뒷받침하는지를 두고 논쟁하는 것입니다.

KR의 개수보다 품질이 더 중요하다

핵심 결과(Key Result, KR)에는 세 가지 종류가 있으며, 이들 사이의 차이가 가치의 대부분을 결정합니다.

입력 KR (Input KRs, 가장 약함) — 활동 횟수. "아티클 20개 발행", "아웃바운드 콜 50회 수행" 등. 당신이 완전히 통제할 수 있지만, 바로 그 점 때문에 현실로부터 아무런 피드백도 얻을 수 없습니다.
출력 KR (Output KRs, 중간) — 직접적인 결과. "유기적 세션(organic sessions) 3,000회", "적격 리드(qualified leads) 200개" 등. 원인 규명이 가능하지만, 여전히 비즈니스 가치보다 한 단계 위에 있습니다.
성과 KR (Outcome KRs, 가장 강력함) — 변화된 비즈니스 상태. "신규 파이프라인 5만 달러 확보", "평균 주문 가치(average order value) +30%" 등. 원인을 규명하기 가장 어렵고 달성하기도 가장 어렵지만, _이것이 정말 의미가 있었는가?_라는 질문에 정직하게 답할 수 있는 유일한 지표입니다.

운영상의 압박을 받는 상황에서 인간은 기본적으로 입력 지표(input metrics)를 선택하게 됩니다. 입력 지표는 달성 가능해 보이고 업무 내부에서 파악하기 쉽기 때문입니다. 제가 핵심 결과(Key Result)로 "아티클 10개 작성"을 제안할 때, Ksen의 역할은 다음과 같이 압박하는 것입니다. "그것은 입력입니다. 성과(outcome)는 도메인 권위(domain authority)인가요? 인바운드 데모 요청인가요? 콘텐츠에 기인한 매출인가요? 그렇게 말하세요." 입력 KR에서 성과 KR로 격상시키는 것은 시스템 전체가 수행하는 가장 레버리지가 높은 작업 중 하나이며, 고객이 기다리고 있는 밤 9시에 저 스스로라면 그냥 건너뛰었을 법한, 화려하지는 않지만 필수적인 교정 작업입니다.

반면에, 일반 개발자나 마케터에게 'EBITDA 20% 증가'와 같은 성과 지표(outcome metrics)를 던져주는 것은 무용지물입니다. 그들은 그 괴물이 무엇인지조차 모르며, 어차피 그것에 직접적인 영향을 미칠 수도 없기 때문입니다. 이것이 바로 성과 지표는 전략적인 연간 목표를 위해 남겨두고, 분기별 목표는 입력 지표와 출력 지표를 혼합하여 사용하는 것이 더 나은 이유입니다.

The Goal Structure: Giving Strategy a Deadline

Ksen이란 무엇인가 — 프레임워크를 실행하는 파트너

단도직입적으로 말하자면: Ksen은 Git 저장소(repository)에 의해 구성된 Claude Code 인스턴스입니다. 이 저장소에는 문서화된 헌장(charter, 즉 규칙), OKR, 그리고 비즈니스 컨텍스트(business context)가 담겨 있습니다. 매 세션이 시작될 때마다 하네스(harness)가 해당 파일들을 로드하고 그에 따라 동작합니다. 그게 전부입니다. 자율적인 루프(autonomous loop)도 없고 인지적 의미에서의 메모리(memory)도 없습니다. Ksen은 매번 파일을 다시 읽으며 마치 기억하고 있는 것처럼 행동합니다.

이것은 다음과 같습니다:

헌장, OKR, 컨텍스트, 그리고 스킬 파일(skill files)이 체크인된 저장소
세션 시작 시 이 파일들을 로드하고 헌장을 따르는 Claude Code 하네스
AI가 제안하고, 도전하며, 검토하고 — 제가 결정하는 OKR 루프
세션 경계를 넘어서 유지되는 파일에 내용을 기록하는 규율

이것은 다음과가 아닙니다:

자율 에이전트 (autonomous agent)
인지적 의미에서의 메모리를 가진 AI
벡터 데이터베이스 (vector database), 커스텀 오케스트레이션 플랫폼 (custom orchestration platform), 또는 그 어떤 특이한 기술
제가 전략적 질문을 던지는 챗봇 (chatbot)

마지막 차이점이 중요하며, 바로 이 지점에서 저는 "파트너"라는 단어를 신중하게 사용하려 합니다. 이를 파트너라고 부르는 것은 관대한 표현입니다. 솔직한 설명은 _지속적인 컨텍스트를 가진 구조화된 자문 (structured advisory with persistent context)_입니다. (참고로 이름은 별도의 것입니다. 초기 단계에서 무엇이라 불리고 싶은지 물었을 때, "Ksen"이라는 답변이 돌아왔습니다.) 하지만 이 디자인 패턴은 실재하며 재현 가능합니다. 그리고 수개월간 사용하면서, 제가 나중에 다시 언급할 한 가지 이유 때문에 이 시스템은 "도구"보다는 "파트너"에 더 가까운 명칭을 얻게 되었습니다.

그것의 도구들. 세 가지 모두 평범한 것들입니다:

OKR (Objectives and Key Results) — 위의 심판 역할을 합니다.
철의 삼각형 (The iron triangle) — 범위 (scope), 자원 (resources), 시간 (time)입니다. 결정이 방향에 영향을 미칠 때, Ksen은 트레이드오프 (trade-off)를 명시적으로 모델링합니다. 즉, 두 가지를 고정하면 나머지 하나는 반드시 움직여야 합니다. 이번 달에 새로운 업무를 추가하면 무언가는 미끄러지게 됩니다. 질문은 언제나 _'이 일을 수행할 경우 어떤 핵심 결과 (Key Result)가 가장 위험에 처하는가, 그리고 수행하지 않을 경우 어떤 것이 위험해지는가'_입니다.
리스크 레지스터 (The risk register) — 미결된 위협과 기회들을 기록한 단순한 파일로, 매 세션마다 이월되어 다시 읽힙니다. 이를 통해 3월에 언급된 리스크가 6월에 조용히 잊히는 일을 방지합니다.

그것의 리듬. 이 케이던스 (cadence)는 전략을 사후 고려 사항이 아닌 습관으로 바꾸어 놓습니다:

연간 (Annual) — 회사의 목표 (Objectives)와 그에 연계된 결과 핵심 결과 (outcome KRs)입니다.
분기별 (Quarterly) — 달력상의 분기에 맞춰 재설정되는 역할 수준의 OKR (more on the roles below)입니다.
월간 (Monthly) — 분기별 OKR을 해당 월의 업무로 분해한 계획입니다.

왜 이런 계층 구조가 필요할까요? 전략이 다시 운영 (operations) 수준으로 함몰되는 것을 막기 위해서입니다. 연간 결과 KR은 주 단위의 시간 규모로는 달성할 수 없습니다. 현재 고객이 10명인데 일주일 만에 100명의 신규 고객을 확보할 수는 없으며, 이는 몇 달간의 작업이 필요하기 때문입니다. 반면 캠페인 및 콘텐츠 목표는 자연스럽게 분기 및 월 단위에 위치합니다.

이 케이던스의 구성 요소 자체는 새로운 것이 아닙니다. 새로움은 1인 창업자가 실제로 이 모든 계층을 매주 운영할 수 있다는 점에 있습니다. 파트너가 데이터 로딩 (loading), 현황 표면화 (surfacing), 그리고 1인 기업이 감당할 여력이 없는 반론 제기 (pushback)를 대신 수행해주기 때문입니다.

그리고 이것이 왜 "파트너"라는 단어를 얻게 되었는지에 대한 이유입니다: 이것은 단순히 의견을 미루지 않는 균형추 역할을 합니다. 혼자라면 아무도 저에게 반론을 제기하지 않습니다. "그건 입력 지표 (input metric)야"라거나 "지난 3월에는 반대로 결정했잖아"라고 말해줄 공동 창업자가 없습니다. 1인 기업의 가장 큰 실패 요인은 그 한 사람이 결코 도전을 받지 않는다는 것입니다. 즉, 모든 나쁜 아이디어가 아무런 저항 없이 실행될 수 있는 활주로를 갖게 됩니다. 이 헌장 (charter)은 도전을 예의가 아닌 _필수 사항 (requirement)_으로 만듭니다. 이는 Ksen이 단독 의사 결정권자에 대한 유일한 구조적 점검 장치 (structural check)임을 의미합니다. 이는 Ksen이 내놓는 그 어떤 개별적인 답변보다 저에게 더 가치 있는 일입니다.

어떻게 구축되었는가 — 궁금한 분들을 위해

위의 모든 내용은 _이유 (why)_에 대한 것입니다. 이제 _방법 (how)_을 설명하겠습니다. 파일 레이아웃, 역할, 그리고 메커니즘입니다. 이름은 제가 지은 것이지만, 이 패턴은 일반화될 수 있습니다.

리포지토리 (repo) 레이아웃

.claude/
├── partnership-charter.md          # 헌장 (constitution): 역할, 규칙, 의사 결정
├── client/
...

주목해야 할 세 가지 사항이 있습니다:

상단에는 헌장 (charter), 하단에는 도메인 (domain), 중간에는 컨텍스트 (context)가 위치합니다. 헌장은 거의 변하지 않습니다. 도메인은 비즈니스가 변할 때 변합니다. 컨텍스트는 매 세션마다 업데이트됩니다.
기술 (skills)과 비평가 (critics)는 코드가 아닌 파일입니다. 기술은 프론트매터 (frontmatter)와 지침이 포함된 마크다운 (Markdown) 파일입니다. 비평가는 루브릭 (rubric)이 포함된 마크다운 파일입니다. 하네스 (harness)가 이 파일들을 읽고 그에 따라 동작합니다.
회고 (retrospectives)는 추가 전용 (append-only)입니다. 모든 세션은 회고로 끝납니다. 패턴이 축적되고, 패턴은 규칙이 되며, 규칙은 비평가 파일과 헌장에 반영됩니다.

전체 시스템은 프라이빗 Git 리포지토리 (private Git repo)입니다. 저는 매 세션이 끝날 때 커밋 (commit)하고, Ksen은 하네스를 통해 자신의 변경 사항을 커밋하며, git log는 감사 추적 (audit trail) 역할을 합니다.

세 가지 지속성 계층 (persistence layers)

Ksen은 아무것도 기억하지 못합니다. 세션이 시작될 때 파일을 다시 읽습니다. 매번 로드되는 세 가지 계층은 다음과 같습니다: