Multi-repo AI Native 자동화 실습 01. 중장기계획으로 위임 구조 만들기

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

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

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

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

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

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

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

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

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

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

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

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

여러 repository를 분석하자 부족한 기둥이 보였습니다

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

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

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

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

그래서 먼저 여러 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에게 위임할 수 있는 시스템을 만든다"로 관점이 바뀐 것입니다. 그 관점이 있어야 여러 repository 분석, 자동화, harness, sprint sheet, second brain wiki, daily review/update skill, Slack notify가 하나의 흐름으로 읽힙니다.

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

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