Git과 Obsidian으로 만드는, AI 에이전트가 일할 수 있는 조직 OS

서론

AI 에이전트(AI Agent)에게 업무를 맡기는 기회가 늘어날수록, 단순히 "AI를 똑똑하게 만드는 것"만으로는 부족하다고 느끼게 되었습니다.

처음에는 조사, 구현, 리뷰, 초안 작성 등을 단발적으로 부탁하는 것만으로도 충분히 편리합니다. 하지만 조금씩 맡기는 범위를 넓혀가다 보면 다른 문제가 눈에 띄기 시작합니다.

"지난번 판단이 어디에 남아 있었지?"

"이 AI는 어떤 전제를 바탕으로 이 제안을 하고 있는 거지?"

"인간은 알고 있지만, AI에게는 보이지 않는 정보가 너무 많다"

이러한 격차는 AI 모델의 성능만으로는 해결되지 않습니다. AI가 일하기 위한 "조직의 그릇"이 부족한 문제입니다.

이 기사는 AI 에이전트를 "채팅 상대"에서 "업무 프로세스의 일부"로 바꾸기 위한 설계 메모입니다. Claude Code, Codex, Hermes Agent와 같은 에이전트를 개인 이용에서 팀·사업 이용으로 확장하고 싶은 분들을 위해 다음 요소들을 다룹니다.

Git으로 관리되는 조직 기억 (Organizational Memory)
Obsidian 등을 사용한 인간 리뷰 UI
AI가 실행하기 쉬운 태스크 형식
판단 로그와 승인 플로우 (Approval Flow)
Human-in-the-Loop 권한 설계
복수의 AI 에이전트 간 보고·연락·상담
최소 구성의 디렉토리 설계

여기에서는 이 실무 기반을 AI 조직 OS라고 부릅니다.

인간과 AI의 정보 격차를 지속적으로 줄이고, 조직의 자산을 축적하며, AI가 근거에 기반하여 판단안을 만들고, 인간의 승인을 거치면서 정의된 권한 범위 내에서 사업 단위의 업무를 진행하기 위한 메커니즘입니다.

AI의 메모리와 조직 기억은 다르다

AI 에이전트에는 "메모리 (Memory)" 기능이 있습니다. 과거의 대화나 사용자 설정을 기억하여 다음 상호작용에 활용할 수 있는 것은 편리합니다.

하지만 사업 운영에 있어 AI의 내부 메모리를 정본(正本)으로 삼는 것은 위험합니다.

AI의 메모리는 어느 쪽인가 하면 작업 캐시 (Work Cache)에 가깝습니다.

사라질 수 있음
업데이트 이력을 리뷰하기 어려움
인간이 차이(Diff)를 확인하기 어려움
어떤 정보를 근거로 했는지 추적하기 어려움
조직 전체에서 공유하기 어려움

반면, 사업에 필요한 것은 "조직 기억 (Organizational Memory)"입니다.

조직 기억은 인간과 AI가 공유할 수 있도록 외부화된 자산입니다.

인간이 읽을 수 있음
AI가 검색할 수 있음
이력이 남음
차이(Diff)를 리뷰할 수 있음
판단 근거와 결과물이 연결되어 있음
나중에 다른 AI나 인간이 인수인계받을 수 있음

즉, AI 에이전트 운용에서 중요한 것은 "AI에게 기억시키는 것"이 아닙니다.

조직으로서 정보를 남기고, AI가 필요할 때 꺼내 쓸 수 있는 상태로 만들어 두는 것입니다.

인간과 AI의 정보 격차를 줄이기

AI 활용에서 자주 발생하는 실패는 인간과 AI가 서로 다른 전제하에 업무를 수행하는 것입니다.

인간은 과거의 경위, 암묵적인 우선순위, 고객과의 약속, 사내 제약 사항을 알고 있습니다. AI는 그 자리에서 전달받은 프롬프트 (Prompt)만을 보고 있는 경우가 많습니다.

이 상태에서 AI에게 "이전 내용 이어서 해줘"라고 의뢰하면 당연히 어긋나게 됩니다.

필요한 것은 AI에게 긴 프롬프트를 쓰는 것이 아니라, 인간과 AI가 동일한 정보 자산을 볼 수 있는 구조를 만드는 것입니다.

인간의 머릿속
↓ 외부화
Git / Markdown / Obsidian / Issue / Decision Log
...

이 루프가 돌아가면 인간과 AI 사이의 정보 격차가 작아집니다.

AI는 "어렴풋이 기억하는 척"을 하는 것이 아니라, 매번 필요한 문맥 (Context)을 검색한 뒤에 작업할 수 있습니다. 인간은 AI의 판단 근거를 확인하고 필요에 따라 수정할 수 있습니다.

우선 수집해야 할 것은 사업의 멀티모달 자산

조직 기억은 텍스트만으로는 부족합니다.

사업 현장에는 다양한 형식의 정보가 있습니다.

채팅
GitHub Issue / PR
문서 (Document)
의사록
상담 음성
회의 녹화
데모 영상
스크린샷
화이트보드 이미지
Figma 등의 디자인 자료
고객의 목소리
KPI, 매출, 문의, 장애 로그
시장 조사, 경쟁 정보, SNS상의 반응

이것들을 그대로 두기만 해서는 AI도 인간도 충분히 활용할 수 없습니다.

따라서 음성, 영상, 이미지 등을 일단 "인간과 AI가 다룰 수 있는 텍스트 자산"으로 변환합니다.

Audio / Video / Image / Chat / Docs
↓
전사 (Transcription) / OCR / 요약 / 메타데이터 부여
...

원래의 음성·영상·이미지를 버리는 것이 아닙니다. 원본 데이터는 자산으로서 저장하면서, AI와 인간이 일상적으로 사용하는 입구를 텍스트로 집중시킵니다.

예를 들어 회의 음성이라면 다음과 같은 Markdown으로 만듭니다.

---
source_type: audio
recorded_at: 2026-05-26
...

이미지라면 OCR과 시각적 설명(Visual Description)을, 영상이라면 챕터(Chapter)와 중요 스크린샷을 만듭니다.

핵심은 AI가 직접 모든 것을 '보러 가는' 것이 아니라, 먼저 조직이 다룰 수 있는 형태로 정돈하는 것입니다.

Git을 정본(Source of Truth), Obsidian을 인간 리뷰 UI로 만들기

AI 조직 OS에서는 처음부터 거대한 전용 DB를 만들 필요가 없습니다.

실무에서는 우선 Git으로 관리되는 Markdown이 강력합니다. 여기서 말하는 '정본(Source of Truth)'이란, 최종적으로 신뢰할 수 있는 정보의 저장소를 의미합니다.

Git을 정본으로 삼으면 다음과 같은 장점이 있습니다.

차이(Diff)를 볼 수 있음
리뷰(Review) 가능
이력(History)이 남음
필요에 따라 과거 상태로 되돌릴 수 있음
PR(Pull Request)로 승인 프로세스를 만들 수 있음
AI가 변경한 내용을 인간이 확인할 수 있음
Markdown, YAML, JSONL과 궁합이 좋음

반면, Git만으로는 인간이 지식으로서 읽고 이해하기에 다소 딱딱할 수 있습니다.

그래서 Obsidian과 같은 Markdown 기반 도구를 인간 리뷰 UI(Human Review UI)로 사용합니다.

노트끼리 링크(Link)할 수 있음
태그(Tag)로 분류할 수 있음
인간이 AI 요약을 수정할 수 있음
관련된 판단이나 태스크(Task)를 추적할 수 있음
비엔지니어(Non-engineer)도 지식 베이스(Knowledge Base)로서 다루기 쉬움

역할 분담은 다음과 같습니다.

Git = 정본, 이력, 차이, 승인
Obsidian = 인간의 확인, 편집, 링크, 이해
AI Agent = 검색, 요약, 판단안, 태스크 실행

여기서 실수하기 쉬운 점은, 비즈니스 직군 사람들에게 갑자기 "Git을 사용해 주세요"라고 말하는 것입니다.

Git을 엔지니어의 도구로 도입하려고 하면, clone, branch, commit, pull, push, conflict 같은 용어만 나열하다가 멈추게 됩니다. AI 조직 OS에서 필요한 것은 모두가 Git 명령어를 입력할 수 있는 능력이 아닙니다.

우선 비즈니스 직군에게 Git은 이력이 남는 공유 폴더로서 설계되어야 합니다.

비즈니스 직군이 Obsidian과 Git을 사용할 수 있게 만드는 순서

추천하는 방식은 다음 4단계입니다.

1. 처음에는 Obsidian만 접하기

첫 경험은 Git이 아닌 Obsidian으로 시작합니다.

Obsidian 설치
Git으로 관리되는 폴더를 Vault로 열기
README.md, tasks/, memory/decisions/, reports/만 보기
노트 작성, 링크 걸기, 태그 달기

이 시점에서는 Git의 개념을 자세히 설명하지 않습니다. 우선 "Markdown 공유 노트를 편집할 수 있다"는 것을 목표로 합니다.

2. Git 조작은 버튼화하기

다음으로, 동기화 조작을 최대한 버튼으로 처리합니다.

예를 들어 다음 중 하나면 충분합니다.

Obsidian Git 플러그인을 사용하여 정기적인 pull/push와 백업을 설정한다
GitHub Desktop에서 "Fetch", "Pull", "Commit", "Push"만 사용한다
사내용 작은 동기화 스크립트를 준비하여 "동기화하기" 버튼만 누를 수 있게 한다

비즈니스 직군에게 처음부터 branch 운용을 요구하기보다, 우선 다음 세 단어로 시작합니다.

Pull = 최신 버전을 가져오기
Commit = 변경 사항에 이름을 붙여 저장하기
Push = 공유하기

이 세 가지만 알면 초기 운용이 가능합니다.

3. 변경 규칙을 템플릿화하기

자유롭게 쓸 수 있는 Markdown은 편리하지만, 너무 자유로우면 AI가 다루기 어려워집니다.

그래서 비즈니스 직군이 고민하지 않도록 템플릿을 준비합니다.

templates/
task.md
decision.md
...

예를 들어 상담 메모라면, 처음부터 다음과 같은 헤더를 배치해 둡니다.

# 상담 메모
## Facts
## Customer Pain
...

인간은 빈칸을 채우기만 하면 됩니다. AI는 동일한 형식을 전제로 검색, 요약, 태스크화를 수행할 수 있습니다.

4. conflict를 "인간이 고치는 것"으로 만들지 않기

비즈니스 직군이 Git을 쓰면서 가장 힘들어하는 것이 conflict(충돌)입니다.

이 부분은 운영 방식으로 피해야 합니다.

한 파일을 여러 명이 동시에 편집하지 않는다
날짜나 ID로 파일을 나눈다
회의 메모, 판단 로그, 태스크는 추기형(Append-only)으로 한다
중요한 파일은 PR 리뷰로 넘긴다
conflict가 발생하면 본인에게 해결하게 하지 않고, AI 또는 엔지니어가 복구한다

즉, 비즈니스 직군에게 요구되는 것은 "올바른 Git 조작"이 아니라, "AI와 인간이 읽을 수 있는 형태로 정보를 남기는 것"입니다.

도입 시 최소 세트

비즈니스 직군을 대상으로 시작한다면, 첫 세트는 이 정도면 충분합니다.

1. Obsidian 설치
2. 공유 Vault 열기
3. GitHub Desktop 또는 Obsidian Git으로 동기화하기
...

중요한 것은 Git을 학습 대상으로 너무 과하게 잡지 않는 것입니다. Git은 뒷단의 이력·승인 기반이고, Obsidian은 일상적인 입력 화면이며, AI는 정리 담당입니다. 이렇게 역할을 분담하면 엔지니어가 아닌 사람도 참여하기 쉬워집니다.

중요한 것은 AI만 읽을 수 있는 데이터베이스로 만들지 않는 것입니다.

인간이 읽을 수 없는 조직의 기억은 언젠가 블랙박스가 됩니다. AI가 사업을 운영할수록, 인간이 확인할 수 있는 형태로 남기는 것이 중요해집니다.

단, Git에 무엇이든 넣어도 된다는 뜻은 아닙니다.

상담 음성, 회의 녹화, 문의 로그, 장애 로그, 스크린샷에는 개인 정보(personal data)나 기밀 정보가 포함될 수 있습니다. 비공개 리포지토리(private repository)라 하더라도 다음의 전제 조건은 반드시 지켜야 합니다.

개인 정보(personal data), 인증 정보, 비밀 정보는 원칙적으로 커밋(commit)하지 않는다
필요한 경우에도 익명화·마스킹·보관 기간·접근 권한을 결정한다
녹음, 녹화, 텍스트 변환(transcription)은 참여자의 동의와 이용 목적을 확인한다
외부 AI 서비스로 보내는 데이터는 사내 규정이나 이용 약관에 비추어 확인한다
공개 게시, 고객 전송, 계약, 채용, 결제, 운영 환경 변경은 인간의 승인을 필수적으로 한다
실행 로그, 승인 로그, 반려(rejection) 이력을 남긴다

AI 조직 OS는 정보를 수집하기 위한 메커니즘만이 아닙니다. 수집해서는 안 되는 정보, AI에게 보여줘서는 안 되는 정보, 인간이 반드시 확인해야 하는 행위를 결정하기 위한 메커니즘이기도 합니다.

AI 에이전트에게는 태스크 정의를 전달한다

AI 에이전트에게 일을 맡길 때, "이전 작업에 이어서 해줘"라고 하는 것은 위험합니다.

대신, 실행 단위를 태스크(task)로서 명확히 합니다.

---
id: TASK-001
organization: media-business
...

태스크에는 목적, 문맥, 수락 조건, 산출물, 승인 조건을 부여합니다.

이를 통해 AI의 업무는 단순한 대화의 연장이 아니라, 감사 가능한(auditable) 업무 프로세스가 됩니다.

AI의 판단 로그를 구조화한다

AI에게 사업을 맡기려면 태스크 실행뿐만 아니라 판단이 필요합니다.

하지만 AI의 판단을 그대로 실행하는 것은 위험합니다.

판단은 다음과 같이 분해하여 남깁니다.

Facts
사실
Interpretation
...

판단 로그의 예시입니다.

---
id: DECISION-2026-05-26-001
organization: media-business
...

AI가 판단할 때 중요한 것은 결론만 내놓지 않는 것입니다.

인간이 확인할 수 있도록 사실, 선택지, 권장 사항, 리스크, 승인 필요 여부를 나누어 남깁니다.

Human-in-the-Loop 권한 설계

"AI에게 맡긴다"와 "인간이 책임을 진다"는 모순되지 않습니다.

오히려 AI에게 맡기는 범위를 넓힐수록, 인간이 어느 시점에 개입할지를 명확히 해야 합니다.

저는 승인 레벨을 최소 4단계로 나누는 것이 좋다고 생각합니다.

레벨	AI의 권한	예시
Level 0	자동 실행 가능	정보 수집, 요약, 내부 메모 작성, 테스트 실행
...

이러한 설계가 없으면 AI 에이전트는 "아무것도 못 하거나" 혹은 "위험한 일까지 멋대로 하는" 양극단으로 치우치기 쉽습니다.

Human-in-the-Loop는 단순한 확인 작업이 아닙니다.

AI가 사업을 움직이기 위한 권한 설계입니다.

사업 단위로 AI 에이전트 조직을 설계한다

AI 에이전트를 한 명의 만능 비서로 다루기보다, 사업 단위의 작은 AI 조직으로 설계하는 것이 실무에 더 적합합니다.

예를 들어 다음과 같은 이미지입니다.

Company
├── Development Business Organization
│ ├── PM Agent
...

각 AI 조직에는 미션, KPI, 권한, 참조할 수 있는 기억, 승인 조건, 보고 대상이 부여됩니다.

organization:
id: media-business
mission: 독자의 과제를 수집하여 유익한 정보 자산을 만들고, 사업 기회로 연결한다
...

이렇게 정의하면 AI 에이전트는 "무엇이든 하는 존재"가 아니라, 조직 내에서 역할을 가진 실행 주체가 됩니다.

복수 AI 에이전트의 보고·연락·상담(報連相) 설계하기

복수의 AI 조직이 움직이게 되면, 인간 조직과 마찬가지로 호렌소(報連相, 보고·연락·상담)가 필요해집니다.

단, AI 간의 호렌소는 잡담이 아니라 구조화된 메시지(Structured Message)로 만드는 것이 좋습니다.

보고 (Report)

type: report
from: media-business.editor-agent
to: executive-agent
...

연락 (Notify)

type: notify
from: development-business.pm-agent
to: media-business.editor-agent
...

상담 (Consult)

type: consult
from: sns-agent
to: legal-review-agent
...

호렌소를 AI를 통해 설계하는 목적은 채팅량을 늘리는 것이 아닙니다.

사업 단위로 움직이는 AI 조직이 서로의 상태를 이해하고, 필요한 시점에 인간에게 에스컬레이션(Escalation)할 수 있도록 하는 것입니다.

도구 실행이 가능한 AI 에이전트를 전제로 하면 무엇이 바뀌는가

도구 실행, 파일 조작, Git 조작, 브라우저 조작, 스케줄 실행, 외부 서비스 연동까지 가능한 에이전트를 전제로 하면, AI 조직 OS는 단순한 문서가 아니게 됩니다.

예를 들어 Hermes Agent와 같은 에이전트라면, 환경이나 설정에 따라 이러한 설계를 실제 작업 흐름(Workflow)에 연결할 수 있습니다.

AI가 다음과 같은 일들을 실제로 실행할 수 있기 때문입니다.

정기적으로 정보를 수집한다
음성이나 문장을 요약하여 Markdown으로 변환한다
Git에 차분(Diff)을 만든다
PR(Pull Request)을 생성하여 인간의 리뷰로 넘긴다
태스크 목록을 읽고 다음에 할 일을 선택한다
검증 명령어를 실행하고 결과를 저장한다
승인이 필요할 때만 인간에게 확인한다
다른 AI 조직에 보고나 상담을 보낸다

이때 중요한 것은 AI에게 "자유롭게 생각해서 움직여"라고 말하는 것이 아닙니다.

AI가 움직일 수 있도록 조직 측을 기계 판독 가능(Machine-readable)하게 만들어 두는 것입니다.

미션 (Mission)
권한 (Authority)
참조할 수 있는 기억 (Memory)
금지 사항 (Prohibitions)
승인 조건 (Approval Conditions)
태스크 형식 (Task Format)
결과물 형식 (Artifact Format)
보고 형식 (Reporting Format)

이러한 것들이 잘 갖춰질수록 AI는 안전하고 빠르게 움직일 수 있습니다.

최소 구성 디렉토리 예시

처음부터 거대한 기반을 만들 필요는 없습니다.

작게 시작한다면 다음과 같은 구성으로도 충분합니다.

org-os/
README.md
organizations/
...

첫 번째 목표는 고도의 검색 시스템을 만드는 것이 아닙니다.

인간과 AI가 동일한 정보를 보고, 태스크와 판단을 동일한 형식으로 다룰 수 있게 하는 것입니다.

검색이나 벡터 DB(Vector DB)는 나중에 필요해지면 추가하면 됩니다. 다만, 파일명, ID, 프론트매터(Frontmatter), 링크 규칙만은 처음에 가볍게 정해두면 나중에 검색 기반으로 옮기기 쉬워집니다.

우선 1시간 만에 시작한다면

처음부터 전사 기반을 만들려고 하면 무거워집니다. 우선은 1개 사업, 1개 팀, 1개 프로젝트만으로도 충분합니다.

예를 들어, 첫 1시간 동안은 다음 4가지만 만듭니다.

org-os/
README.md
organizations/default.yaml
...

README에는 이 리포지토리가 어떤 조직의 기억인지 작성합니다. organizations/default.yaml에는 미션, KPI, AI가 접근해도 되는 범위, 승인이 필요한 행위를 작성합니다.

TASK-001.md에는 AI에게 의뢰할 첫 번째 태스크를 딱 하나만 작성합니다. DECISION-001.md에는 해당 태스크와 관련된 판단이나 전제 조건을 남깁니다.

그다음 AI 에이전트에게 다음과 같이 의뢰합니다.

tasks/ready를 읽고, 다음에 실행해야 할 태스크를 하나 선택하세요.
실행 전에 관련 있는 organizations/default.yaml와 memory/decisions를 확인하세요.
승인이 필요한 작업은 실행하지 말고 승인 요청으로 정리하세요.

이것만으로도 "어렴풋이 AI에게 부탁하는" 상태에서 "동일한 자료를 보며 AI와 업무를 진행하는" 상태로 바뀝니다.

요약

AI 에이전트 활용의 본질은 AI에게 기억을 갖게 하는 것만이 아닙니다.

사업을 운영하기 위해서는 AI가 일할 수 있는 조직의 그릇이 필요합니다. 정보를 외부화하고, 판단의 근거를 남기며, 태스크와 승인의 흐름을 정돈합니다. 음성, 영상, 이미지와 같은 현장의 자산도 인간과 AI가 다룰 수 있는 형태로 바꾸어 나갑니다.

그 위에 AI에게 역할과 권한을 부여합니다. 무엇을 봐도 되는지, 어디까지 실행해도 되는지, 그리고 어느 지점에서 인간에게 확인을 받아야 하는지 말입니다.

AI에게 일을 맡긴다는 것은 편리한 도구를 하나 추가하는 것이 아닙니다. AI가 일할 수 있는 회사의 시스템을 만드는 것입니다.

인간과 AI 사이의 정보 격차를 줄이고, 소수 인원으로도 여러 사업을 운영할 수 있는 상태를 만드는 것. 이를 위한 토대가 바로 AI 조직 OS입니다.

처음부터 거대한 기반을 만들 필요는 없습니다. memory/, tasks/, decisions/, reports/라는 4개의 디렉토리를 만들고, AI에게 의뢰한 태스크와 판단 로그를 Markdown으로 남기는 것부터 시작하는 것만으로도 충분합니다.

AI 에이전트 (AI Agent)를 팀이나 사업에서 사용하고 계신 분이 있다면, 어떻게 기억·승인·태스크 관리를 설계하고 계신지 꼭 댓글로 알려주세요.