저는 아침에 노트북을 열면 습관처럼 하는 일이 있습니다. GitHub 알림을 확인하고, 슬랙 메시지를 훑고, 여기저기 흩어진 메모를 뒤적이며 "오늘 뭐부터 해야 하지?"를 결정하는 것입니다. 프로젝트가 하나라면 금방 끝나겠지만, 회사 프로젝트와 개인 사업을 합쳐 8개 프로젝트를 동시에 운영하다 보면 이 과정만으로도 30분이 넘게 걸립니다. 정작 중요한 작업을 시작하기도 전에 에너지가 빠지게 되죠.

그래서 AI가 이런 아침 루틴도 대신 해줄 수 있지 않을까? 하는 생각을 하게 됐죠. 그래서 GitHub에 쌓인 이슈와 커밋 기록을 읽고, 내가 정리해 둔 우선순위 파일을 참조해서 매일 아침 슬랙(Slack)으로 "오늘 이것부터 하세요"라고 보고 해주는 비서 에이전트를 만들어 보기로 했습니다.

미리 요점만 콕 집어보면?

GitHub에 Hub Repo를 만들어 모든 프로젝트의 메타데이터와 컨텍스트를 한 곳에 모으고, Python 스크립트와 GitHub Actions로 AI 비서가 매일 아침 슬랙 메세지를 보내주는 시스템을 구축했습니다.
"한 곳에서만 쓰고 여러 곳에서 읽는다"는 컨텍스트 관리 원칙과 AI에게 단순 요약이 아닌 작업의 우선순위 판단까지 하도록 하는 프롬프트 설계를 반영했습니다.
실제로 통합 워크스페이스와 AI 비서를 도입한 뒤 아침 루틴이 "정보 수집과 판단"에서 "확인" 작업으로 바뀌었습니다. 다만, 여전히 우선순위 파일의 수동 업데이트나 AI 브리핑 품질 개선 같은 과제가 남아 있습니다.

통합 워크스페이스 구상

여러 프로젝트를 동시에 운영하다 보면, 컨텍스트 스위칭(Context Switching)이 자주 발생합니다. A 프로젝트 버그를 고치다가 B 프로젝트 회의에 참석하고, C 프로젝트 문서를 작성하다가 D 프로젝트 클라이언트 문의를 처리해야 하는 등 계속 머릿속 컨텍스트를 바꾸게 됩니다. 그리고 그 과정에서 각 프로젝트마다 "지금 어떤 상태인지, 다음 작업이 무엇인지"를 파악하는데 너무 많은 에너지를 소모하게 됩니다.

또한 프로젝트가 여러 GitHub Repo로 흩어져 있기 때문에 프로젝트 개수가 늘어날수록 아침마다 반복되는 업무 우선순위 판단 루틴도 점점 길어지게 됩니다. 예를 들어, 각 Repo의 이슈와 PR 상태를 확인하고, 어제 어디까지 작업했는지 커밋 로그를 체크하고, 슬랙에서 밤사이 온 메시지를 읽고, 노트 앱에 적어둔 할 일 목록을 다시 확인하는 등의 일이 많아집니다.

이와 같이 프로젝트 상태를 파악하고, 업무 우선순위를 판단하기 위한 정보는 각 프로젝트의 GitHub 이슈, 커밋 로그, 각종 문서 등에 흩어져 있습니다. 이렇게 흩어진 정보들을 찾고 그 과정에서 수많은 컨텍스트 스위칭이 일어나면 업무에 집중하기가 어려워집니다. 그래서 이 문제를 해결하기 위해 GitHub에 별도의 Hub Repo를 두어 모든 프로젝트의 메타데이터와 컨텍스트를 한곳에 모아 관리해 보기로 했습니다.

통합 워크스페이스를 위한 Hub Repo 설계

1) 구성 원칙

통합 워크스페이스를 설계하는 데 있어 제가 정한 핵심 원칙은 "한 곳에서만 쓰고, 여러 곳에서 읽는다"입니다. 즉, AI가 참조할 수 있는 모든 컨텍스트 한 곳에서만 관리하고, 이를 여러 프로젝트에서 활용하는 것입니다. 예를 들어, 개인 프로필, 회사 정보, 사업 전략, 프로젝트 배경, 작업의 우선순위 같은 모든 컨텍스트 정보를 Hub Repo 한 곳에 모아두고, 각 프로젝트 Repo에서 이를 참조하는 구조입니다.

2) Hub Repo 연결 방식 선택

저는 Hub Repo를 각 프로젝트 Repo와 어떻게 연결할지 꽤 오랫동안 고민했습니다. 제가 검토했던 선택지는 세 가지였으며, 그 첫 번째는 Git submodules를 이용한 방식이었습니다. Git submodules는 각 프로젝트 Repo를 Hub Repo의 서브모듈로 연결하는 방식인데, 버전 관리가 복잡하고 매번 submodule update를 해야 해서 오히려 관리 부담이 늘어날 가능성이 있었습니다,

Git Submodule 컨셉 <출처: dev-repository.com>

두 번째로 생각했던 것은 yaml + API 방식이었습니다. Hub Repo에 프로젝트 메타데이터를 YAML로 저장하고 API로 접근하는 것이었는데, API 서버를 따로 운영해야 하므로 과하다는 생각이 들었습니다.

YAML 직접 참조 + GitHub Actions 활용 <출처: 작가, Gemini 제작>

결국 최종적으로 선택한 방식은 yaml + GitHub Actions였습니다. 로컬 환경에서는 yaml 파일을 직접 읽도록 하고, AI 비서 에이전트처럼 클라우드 환경에서 Cron 작업이 필요할 때는 GitHub Actions으로 Hub Repo를 checkout하여 yaml 파일을 읽도록 하는 것입니다. 이런 방식으로 구성하면 별도의 API 서버를 구성하거나 복잡한 서브모듈을 적용하지 않더라도 yaml 파일의 프로젝트 메타데이터를 효율적으로 관리할 수 있었습니다.

3) Notion MCP를 검토했다가 GitHub으로 돌아온 이유

사실 처음에는 노션(Notion)을 컨텍스트 저장소로 고려했었습니다. 그동안 쌓아온 노트와 작업 이력이 노션에 많이 남아 있었기 때문이었는데요. 노션 MCP(Model Context Protocol)를 활용하면 AI가 노션의 데이터베이스를 직접 읽을 수 있으니 기존 자산을 그대로 활용할 수 있겠다고 생각했었습니다.

하지만 실제로 구현을해보니 여러 문제가 있었습니다. 일단 MCP를 통한 노션 접근에는 토큰 비용이 발생하고, 컨텍스트가 노션과 GitHub 두 곳에 흩어지게 되면서 오히려 관리 부담이 늘어날 수 있었습니다. 또한 클로드 코드가 노션에 있는 자료를 참조할 수 있도록 하는 MCP 설정이 생각보다 번거로 웠습니다. 결국 이러한 이유로 노션을 컨텍스트 저장소로 하려던 계획을 철회하고, GitHub에 별도의 Hub Repo를 두어 컨텍스트 관리를 일원화하기로 결정했습니다. 아울러 장기적으로는 노션에 있는 기존 자산 중에 필요한 것만 마크다운으로 변환해서 Hub Repo에 옮기기로 했습니다.

4) Hub Repo 구조

Hub Repo의 구조는 root > works > projects 이렇게 3계층으로 설계했습니다. 최상위 폴더(root)에는 모든 업무와 프로젝트에 공유될 수 있는 컨텍스트 정보(개인 프로필, 인생 비전, 우선 순위 등)를 두었습니다. 그리고 각 work에는 업무 단위 맥락을, 각 project에는 개별 프로젝트의 컨텍스트와 메타데이터(project.yaml), 요구사항 문서(PRD.md) 등을 두었습니다.

만약 새로운 프로젝트가 생기면 해당 업무 그룹 아래에 프로젝트 폴더를 만들고 project.yaml를 추가합니다. project.yaml은 각 프로젝트의 핵심 정보를 담는 간결한 YAML 파일입니다. 여기에는 간단하게 프로젝트의 이름, 설명, 상태, GitHub Repo 주소, 노트 같은 정보를 담았습니다.

AI 비서 에이전트 "정대리" 구축

Hub Repo에 모든 프로젝트 정보를 모아놓고 나니 자연스럽게 다음 작업이 떠올랐습니다. 각 프로젝트의 데이터를 매일 아침 자동으로 읽어서 “오늘 뭐부터 해야 하는지”를 정리해주는 AI 비서 에이전트를 만드는 것이었습니다. 개인적으로 저는 비서 에이전트에 “정대리”라는 이름을 붙여 주었습니다. 이름에 특별한 뜻은 없지만, 에이전트를 의미하는 “대리”를 붙이고 싶었습니다.

1) AI 비서 에이전트 동작 구조

전체 흐름은 다음과 같습니다. 먼저 GitHub Actions로 매일 아침 정해진 시간에 Python 스크립트를 실행합니다. 그러면 스크립트가 먼저 Hub Repo의 각 works 디렉토리에 있는 모든 project.yaml 파일을 읽어 프로젝트 목록과 상태를 파악합니다. 그 다음 각 프로젝트의 GitHub Repo에서 오픈 이슈, PR, 최근 커밋을 조회하고, 우선순위 판단에 대한 정보가 담겨있는 current-priorities.md을 참조한 후 Claude API로 오늘의 브리핑을 생성합니다. 그렇게 완성된 브리핑은 Slack Webhook을 통해 슬랙 메시지로 발송됩니다.

Python 스크립트는 클로드 코드를 이용해 작성했습니다. 핵심 로직은 앞서 설명한 것처럼 프로젝트 데이터 수집, GitHub 활동 조회, Claude API로 브리핑 생성, 슬랙 전송으로 나뉩니다. 첫 번째 단계는 각 프로젝트의 데이터 수집으로 다음 코드와 같이 works 디렉토리 아래에 있는 모든 project.yaml 파일을 재귀적으로 찾아 읽습니다.

두 번째는 GitHub 활동 조회입니다. 각 프로젝트의 Repo 필드에 GitHub URL이 있으면, gh CLI를 통해 오픈 이슈, PR, 최근 커밋을 가져옵니다. 여기서 GitHub API 대신 gh CLI를 쓴 이유는 인증 처리가 간편하고, GitHub Actions 환경에서 별도 설치 없이 바로 사용할 수 있기 때문이었습니다.

2) GitHub Actions로 매일 자동 실행하기

저는 매일 아침 cron 작업을 위해 GitHub Actions를 선택했습니다. cron 작업을 실행하는 방법에는 여러가지가 있지만, GitHub Actions는 클라우드에서 실행되기 때문에 로컬보다 안정적이고, 다음과 같은 워크플로 파일로 간단하게 설정할 수 있다는 장점이 있습니다.

3) 프롬프트 설계

각각의 프로젝트 데이터를 수집하고, 슬랙으로 메시지를 전송하는 것은 기술적으로 그다지 어렵진 않습니다. 대신 개인적으로 가장 어렵게 느껴졌던 부분은 AI가 적절한 브리핑을 할 수 있도록 프롬프트를 설계하는것이었습니다. 우선 정대리의 브리핑을 위해 필요한 것은 각 작업의 우선순위를 어떻게 판단할 것인가에 대한 것이었습니다.

일단 저는 점수를 부여하는 방식으로 프롬프트를 만들었습니다. 예를 들어, 긴급도(35점)에는 외부 마감이나 클라이언트 대응처럼 시간에 민감한 요소를 반영하고, 수익 영향도(30점)는 그 작업이 회사나 개인 비즈니스 매출에 얼마나 직결되는지를 봅니다. 블로커 해제(20점)는 이 작업을 끝내야 다른 프로젝트가 진행될 수 있는지를 판단하며, 에너지 매칭(15점)은 아침의 집중력이 높을 때 해야 할 작업과 오후의 낮은 에너지로도 할 수 있는 작업을 구분하는 용도로 활용했습니다. 아울러 프롬프트에 브리핑 출력 형식도 구체적으로 지정했습니다. AI에게 브리핑을 자유롭게 쓰게 하면 매번 형식이 달라져서 빠르게 훑어보기가 어렵기 때문입니다.

실제 사용 후기와 개선 아이디어

1) 좋았던 점

정대리를 며칠간 써보며 가장 좋았던 점은 아침 루틴이 정보 수집과 판단에서확인작업으로 바뀌었다는 점이었습니다. 즉, 여러 GitHub Repo나 메모를 체크하며 뭐부터 시작할지 고민하는 시간을 줄일 수 있었습니다. 그래서 요즘에는 정대리 브리핑을 훑고 바로 오전 작업을 시작하고 있습니다. 가끔은 “진짜 이거부터 하는게 맞나?” 하는 경우도 있지만, 직접 뭐부터 할지 정하는 것보다 효율적이었습니다.

또한 프로젝트 사각지대가 줄었습니다. 동시에 여러 프로젝트를 돌리다 보면 며칠째 손 대지 않는 프로젝트가 생기기 마련인데, 정대리 브리핑을 통해 매일 전체 프로젝트 현황을 빠르게 훑고 보충해야할 사안을 떠올릴 수 있었습니다. 아울러 각 프로젝트의 상호 보완과 시너지 전략을 정대리와 토론하고, 앞으로 어떤 방향으로 프로젝트를 진행해할지 전반적인 큰 그림도 그릴 수 있었습니다.

2) 개선 해야할 점

현재는 정대리가 GitHub 활동(이슈, PR, 커밋 현황 등)을 우선 순위 판단의 핵심 자료로 사용하고 있습니다. 하지만 GitHub 활동만으로는 프로젝트의 진짜 맥락을 파악하기 어렵습니다. 예를 들어, 커밋이 2주간 없는 프로젝트를 정대리는 "정체됨"으로 판단하지만, 실제로는 클라이언트 피드백을 기다리는 중이거나 의도적으로 보류한 것일 수 있습니다. 현재는 project.yaml의 notes 필드에 이런 맥락을 수동으로 기록해서 보완하고 있는데, 이 맥락 정보 자체를 어떻게 자동으로 기록하고 체계화 시킬 수 있을지가 다음 개선 과제입니다.

또한 지금은 각 프로젝트의 GitHub 이슈를 직접 작성하고 있는데, 이 역시 AI 비서를 통해 자동화할 수 있는 영역입니다. 이처럼 AI 에이전트를 일상 업무에 활용하다 보면 자동화할 대상이 계속 눈에 들어오게 되는 것 같습니다. 다만 이러한 작업들은 본 업무를 지원하기 위한 것인 만큼, 오버엔지니어링(Overengineering)으로 오히려 개발과 관리 부담이 늘어나지 않도록 균형을 잡는 것이 중요하다고 생각합니다.

마치며

이번에 통합 워크스페이스와 AI 비서 에이전트를 구축해 보면서, 워크플로를 자동화하기 위해서는 맥락을 어떻게 정리하고 관리하는지가 정말 중요하다는 생각이 들었습니다. 지금 정대리에게 제공하는 데이터는 project.yaml의 메타데이터와 GitHub 활동, 그리고 notes 필드에 적어둔 메모 정도입니다. 이 정도만으로도 아침 브리핑은 충분히 쓸모가 있지만, "이 작업이 저 프로젝트와 어떻게 연결되는지", “이 작업을 먼저 했을 때 다른 프로젝트 어떤 영향을 미치는지”처럼 맥락의 깊이가 필요한 판단에서는 여전히 한계가 있습니다. 즉, AI 비서 에이전트의 품질을 결정하는 것은 모델 성능이나 도구가 아니라, 본인의 맥락을 얼마나 잘 구조화해서 전달하는지에 달려있다고 생각합니다.

결국 에이전트를 만들고 나서는 나만의 온톨로지(Ontology) 구축이 핵심이라는 생각이 듭니다. 프로젝트 간의 관계, 상태 변화의 이유, 의사 결정의 배경 같은 것들을 기계가 이해할 수 있는 형태로 정의해야 AI 비서를 한 단계 더 성장시킬 수 있습니다. 예를 들어, A 프로젝트 개발이 지연되면 B 일정에 영향을 준다"는 의존 관계나 “이 프로젝트는 클라이언트 피드백 대기 중이라 의도적으로 멈춘 것이다" 같은 맥락을 구조적으로 표현할 수 있다면, 정대리의 브리핑이 단순한 오늘 할 일 정리를 넘어 보다 깊은 수준의 조언까지 가능할 것이라고 생각합니다.

개인적으로 AI 에이전트 시대에 요구되는 핵심 역량은 코딩 실력이나 프롬프트 기법이 아니라, 자신의 업무 맥락을 체계적으로 정의하고 구조화하는 능력이라고 생각합니다. 좋은 온톨로지가 설계되면 특정 AI 도구에 종속되지 않으면서도, 동시에 수행하는 프로젝트가 많아져도 에이전트 시스템이 흔들리지 않도록 할 수 있을 것입니다.