AI와 파트너가 아니라 위임자로 일하기 위해 중장기계획을 만들었다

나는 한동안 AI를 파트너라고 생각했다.

같이 고민하고, 같이 문서를 읽고, 같이 코드를 고치고, 같이 검토하는 관계. 이 표현은 편했다. 실제로 많은 순간 AI는 좋은 동료처럼 보였다.

그런데 6개 repository를 오가며 작업을 하다 보니, 이 표현이 조금 부족하다는 생각이 들었다. 파트너라는 말에는 내가 계속 옆에서 같이 뛰는 장면이 들어 있다. 하지만 내가 만들고 싶은 것은 내가 모든 순간 옆에 붙어 있지 않아도 돌아가는 시스템이었다.

그래서 관점을 바꾸기로 했다.

AI와의 파트너 관계를 청산하고, 위임자가 되기로 했다.

위임자가 되려면 먼저 내 시스템을 설명할 수 있어야 했다

위임은 "대신 해줘"가 아니다.

무엇을 맡기는지, 어디까지 맡기는지, 어떤 결과를 받으면 되는지 설명할 수 있어야 위임이다. 무엇이 source-of-truth인지, 어떤 파일은 건드리면 안 되는지, 완료 판단은 어떤 검증으로 하는지 말할 수 있어야 한다.

AI에게 일을 맡기는 순간 이 기준은 더 중요해진다.

AI는 빠르게 읽고 빠르게 쓴다. 그래서 경계가 없으면 빠르게 틀릴 수 있다. 반대로 경계가 분명하면, 내가 혼자 처리하기 어려운 양의 탐색과 정리와 반복 작업을 안정적으로 맡길 수 있다.

내가 중장기계획을 세우게 된 이유는 여기 있었다.

프롬프트를 더 잘 쓰기 위해서만은 아니었다. 자동화를 더 많이 만들기 위해서만도 아니었다. 내가 어떤 시스템의 위임자인지 먼저 정의해야 했다.

6개 repository를 분석하자 부족한 기둥이 보였다

내 작업 환경은 단일 repository가 아니었다.

개인 학습과 블로그를 담는 ai-survival-log, 실제 사이트 런타임을 가진 ai-survival-log-site, 공통 role과 template을 관리하는 shared-agent-harness, 회사 도메인 지식과 실행 경계를 나누는 repository들이 함께 있었다.

처음에는 이 구조가 그냥 작업 공간처럼 보였다.

하지만 AI에게 위임하려고 보니, repository마다 맡길 수 있는 일이 달랐다. 어떤 곳은 source-of-truth를 지켜야 하고, 어떤 곳은 runtime contract를 지켜야 한다. 어떤 곳은 공통 규칙을 제공해야 하고, 어떤 곳은 회사 원문과 운영 증거를 절대 밖으로 내보내면 안 된다.

그래서 먼저 6개 repository를 분석했다.

질문은 단순했다.

• 이 repository는 무엇의 원천인가?
• AI가 먼저 읽어야 하는 문서는 무엇인가?
• 여기에서 허용되는 작업과 금지되는 작업은 무엇인가?
• 검증은 어떤 명령으로 끝나는가?
• 다른 repository로 넘겨야 하는 handoff는 무엇인가?

이 질문에 답하다 보니 부족한 부분이 보였다.

어떤 곳은 context map이 필요했다. 어떤 곳은 local gate가 필요했다. 어떤 곳은 PR summary와 review routing이 필요했다. 어떤 곳은 회사 도메인 payload를 막는 규칙이 필요했다.

중장기계획은 그 부족한 부분을 채우기 위한 설계도가 됐다.

자동화와 harness가 시스템을 떠받치는 두 기둥이었다

중장기계획을 세우면서 가장 많이 생각한 질문은 이것이었다.

위임자로서 일하려면 내 시스템을 무엇으로 받쳐야 하는가?

내 답은 두 가지였다.

자동화와 harness.

자동화는 반복을 줄인다. PR summary, Slack notify, 회귀 테스트 실패 분석, Jira 계획 초안, deploy checklist 같은 것들이 여기에 들어간다. 사람이 매번 손으로 확인하던 것을 규칙과 스크립트와 report로 바꾼다.

harness는 자동화가 아무 방향으로나 움직이지 않게 잡아 준다. AGENTS.md, CLAUDE.md, validation matrix, skill, task brief, director gate, source-of-truth boundary가 여기에 들어간다.

자동화만 있으면 빠르지만 위험하다.

harness만 있으면 안전하지만 느리다.

내가 만들고 싶은 시스템은 둘 중 하나가 아니었다. 자동화가 속도를 만들고, harness가 방향과 경계를 잡는 구조였다.

중장기계획은 backlog가 아니라 sprint sheet가 되어야 했다

처음 계획서는 할 일 목록처럼 보일 수 있었다.

하지만 내가 원한 것은 backlog가 아니었다. 매일 실제로 열어 보고, 오늘 할 일을 고르고, 끝난 일을 반영하고, 새 작업을 추가하고, 우선순위를 다시 검증하는 살아 있는 문서였다.

그래서 중장기계획을 sprint sheet처럼 관리하기로 했다.

규칙은 이렇게 잡았다.

• 매일 작업 시작 전 이전 완료 작업을 확인한다.
• 오늘 병렬 실행 가능한 작업 2~3개를 고른다.
• 작업 종료 후 완료, 진행, 차단, 다음 후보를 업데이트한다.
• 새 작업이 들어오면 backlog에 넣고 우선순위와 owner surface를 먼저 정한다.
• 프로젝트 구조, harness, skill, PR topology가 바뀌면 계획서도 같이 바꾼다.
• 각 작업은 블로그 글감이 될 수 있도록 narrative hook을 남긴다.

이렇게 해야 계획이 기억을 대신할 수 있다.

기억에 의존하는 프로젝트는 언젠가 흐려진다. 문서가 sprint sheet가 되면, 다음 세션의 내가 다시 이어 받을 수 있다. 더 중요하게는 AI도 그 문서를 읽고 현재 상태를 이해할 수 있다.

second brain wiki가 agent의 기억을 계속 갱신한다

내 wiki는 단순한 노트 저장소가 아니다.

나는 이 wiki를 second brain처럼 쓰고 있다. 원본은 raw/에 두고, 해석과 연결은 wiki/에 남기고, 블로그 산출물은 downstream으로 내보낸다. 이 구조는 사람을 위한 정리이기도 하지만, AI가 다시 읽을 수 있는 기억이기도 하다.

여기서 중요한 점은 진화다.

agent가 매번 처음부터 시작하면 발전하지 않는다. 매번 같은 설명을 다시 하고, 같은 실수를 반복하고, 같은 검증을 다시 찾게 된다.

반대로 wiki가 계속 업데이트되면 달라진다.

어제 끝난 작업이 오늘의 입력이 된다. 오늘 발견한 실패가 내일의 guardrail이 된다. 반복된 프롬프트가 skill 후보가 된다. 자주 보는 계획은 compact agent brief로 분리된다.

이 과정이 쌓이면 같은 도구도 다르게 작동한다.

정확히는, 내 시스템이 agent를 더 잘 작동하게 만든다.

매일 보고하고 업데이트하는 루프가 시스템을 진화시킨다

그래서 long-term-plan-review와 long-term-plan-update skill을 만들었다.

이 두 skill은 거창한 자동화가 아니다. 하지만 내가 만들고 싶은 시스템의 핵심 루프다.

작업 시작 전에는 long-term-plan-review가 필요하다.

• 이전에 완료된 작업은 무엇인가?
• 오늘 병렬 실행 가능한 작업은 무엇인가?
• 어떤 작업은 외부 write가 있어서 같이 돌리면 안 되는가?
• 지금 우선순위는 여전히 맞는가?

작업 종료 후에는 long-term-plan-update가 필요하다.

• 무엇을 완료했는가?
• 어떤 검증을 통과했는가?
• 무엇이 차단되었는가?
• 어떤 새 작업이 생겼는가?
• 블로그에 남길 장면은 무엇인가?

이 루프가 있어야 시스템이 스스로 갱신된다.

계획은 고정된 약속이 아니다. 현실을 만나면서 바뀌어야 한다. 중요한 것은 아무렇게나 바뀌지 않는 것이다. 변경은 기록되고, 우선순위는 다시 검증되고, 다음 실행 후보는 다시 정렬되어야 한다.

병렬 작업에는 먼저 보고 체계가 필요했다

나는 한 번에 2~3개 작업을 병렬로 진행하고 싶었다.

그런데 병렬 작업은 단순히 "많이 시키기"가 아니다. 동시에 열린 작업이 많아질수록 완료 신호, 차단 상태, 검증 결과, 다음 action을 잃어버리기 쉽다.

그래서 Codex 완료 Slack 알림이 최우선 작업이 됐다.

Slack 알림은 작은 기능이다. 하지만 병렬 작업에서는 완료 신호가 된다. Codex가 언제 끝났는지 알아야 다음 검토로 넘어갈 수 있다. 긴 작업을 맡긴 뒤 다른 문서를 읽거나 다른 계획을 세울 때, 완료 신호는 운영의 기본 장치가 된다.

이것도 위임자의 관점에서 보면 자연스럽다.

위임자는 모든 작업 옆에 붙어 있지 않는다. 대신 어떤 일이 끝났는지, 어떤 일이 막혔는지, 어떤 결과를 검수해야 하는지 알 수 있는 보고 체계를 만든다.

Slack notify는 그 보고 체계의 첫 번째 작은 장치였다.

AI Native한 사람이 되기 위한 첫걸음은 일을 더 많이 시키는 것이 아니었다

AI 시대의 가치 중 하나는 AI Native한 사람이 되는 것이라고 생각한다.

그 말은 단순히 최신 AI 도구를 많이 쓰는 사람이 된다는 뜻이 아니다. AI에게 일을 시키는 사람이 아니라, AI가 일할 수 있는 시스템을 설계하는 사람이 되는 것에 가깝다.

나에게 그 첫걸음은 중장기계획이었다.

중장기계획은 내 작업의 생명주기를 담는다. 어떤 목표를 향해 가는지, 지금 무엇이 우선인지, 어떤 자동화가 필요한지, 어떤 harness가 부족한지, 어떤 작업을 병렬로 돌릴 수 있는지, 무엇을 블로그로 남길지 계속 묻는다.

이 질문을 매일 반복하면 시스템이 바뀐다.

처음에는 내가 AI에게 지시한다. 다음에는 AI가 계획을 읽고 오늘 할 일을 제안한다. 그다음에는 완료된 일을 반영하고, 새 작업을 추가하고, 우선순위를 다시 검증한다. 시간이 지나면 이 루프 자체가 나의 작업 방식이 된다.

그때부터 AI는 단순한 파트너가 아니다.

내가 설계한 시스템 안에서 위임받아 일하는 실행자가 된다.

다음 글은 첫 번째 보고 체계로 내려간다

이 글은 왜 중장기계획을 만들었는지에 대한 이야기다.

핵심은 "AI와 파트너로 일한다"에서 "AI에게 위임할 수 있는 시스템을 만든다"로 관점이 바뀐 것이다. 그 관점이 있어야 6개 repository 분석, 자동화, harness, sprint sheet, second brain wiki, daily review/update skill, Slack notify가 하나의 흐름으로 읽힌다.

다음 글에서는 더 구체적인 장면으로 내려간다.

왜 Codex 완료 Slack 알림을 최우선 P0로 올렸는지, 완료 신호가 병렬 작업에서 어떤 역할을 하는지, 그리고 작은 알림 기능이 왜 위임자의 보고 체계가 되는지를 정리한다.