[Graph Engineering ] 진짜 쉬운 설명

요즘 AI를 조금 깊게 쓰기 시작하면 이상한 단어를 계속 만나게 된다.

Context Engineering, Harness Engineering, Loop, Memory, Skill, Hook….

그리고 최근에는 또 하나가 자주 보인다.

Graph Engineering.

처음 이 말을 들었을 때는 나도 조금 피곤했다.

“또 새로운 개념인가?”

그런데 내용을 들여다보면 사실 완전히 새로운 기술은 아니다.

우리가 이미 가지고 있는 문서와 지식을
AI가 실제로 찾아갈 수 있도록 연결해주는 일에 더 가깝다.

그리고 생각보다 이 문제가 꽤 중요하다.

---

AI에게 자료를 줬는데, 왜 계속 엉뚱한 답을 할까

예를 들어 이런 상황을 생각해보자.

나는 몇 달 동안 AI와 일을 하면서 수많은 자료를 만들었다.

• 브랜드 가이드
• 고객 분석
• 글쓰기 스타일
• 회의록
• 과거 캠페인
• 잘된 콘텐츠 사례
• 실패한 콘텐츠 사례
• 프롬프트
• 업무 프로세스
• 프로젝트 회고
• 각종 Markdown 문서

폴더를 열어보면 자료가 가득하다.

겉으로 보면 훌륭한 지식베이스처럼 보인다.

그런데 막상 AI에게 새로운 글을 하나 써달라고 하면 이상하다.

분명 지난주에 브랜드 톤을 정리했는데 반영하지 않는다.

성공한 콘텐츠 사례도 있는데 전혀 다른 방식으로 초안을 만든다.

고객 분석 문서도 있는데 타깃이 좋아하지 않을 이야기를 꺼낸다.

문서는 존재한다.

그런데 AI 입장에서는 존재하지 않는 것이나 마찬가지다.

왜 그럴까?

---

AI는 폴더 전체를 항상 읽지 않는다

여기에서 중요한 오해가 하나 있다.

우리는 AI에게 프로젝트 폴더를 연결하면
AI가 그 안에 있는 모든 자료를 머릿속에 넣고 일한다고 생각하기 쉽다.

실제로는 그렇지 않다.

AI는 현재 작업을 수행하기 위해

“지금 어떤 정보를 읽어야 할까?”

를 계속 판단한다.

즉 문서가 1,000개 있다고 해서 1,000개를 항상 읽는 것이 아니다.

필요해 보이는 몇 개를 선택해서 읽는다.

문제는 여기에서 시작된다.

어떤 문서가 중요한지 알려주는 연결이 없다면
AI는 중요한 자료를 놓칠 수 있다.

그리고 이 문제는 문서가 많아질수록 심해진다.

---

Context, Harness, Loop, Graph

최근 AI 업무 시스템을 설명할 때 자주 등장하는 개념을 아주 단순하게 정리하면 이렇다.

Context

AI가 지금 보고 있는 정보다.

어떤 문서를 넣을지, 어떤 대화를 포함할지, 어떤 데이터를 보여줄지 결정하는 영역이다.

Harness

AI 주변에 붙여놓은 업무 환경과 규칙이다.

예를 들면

• CLAUDE.md
• AGENTS.md
• Skill
• 프로젝트 규칙
• 파일 구조
• 실행 권한
• 도구
• 검증 규칙

같은 것들이다.

Loop

AI가 한 번 작업하고 끝나는 것이 아니라
스스로 결과를 검사하고 다시 수정하게 만드는 구조다.

예를 들어

작성 → 테스트 → 오류 발견 → 수정 → 다시 테스트

를 반복하게 만드는 것이다.

Graph

그리고 Graph는

“어떤 정보가 어디에 있고, 서로 어떻게 연결되어 있는가”

를 정의한다.

개인적으로는 이 네 가지 중 Graph가 가장 늦게 체감되는 개념이라고 생각한다.

자료가 적을 때는 없어도 잘 돌아가기 때문이다.

하지만 자료가 수백 개를 넘어가는 순간부터 이야기가 달라진다.

---

폴더 구조부터 다시 생각해야 한다

Graph를 만들기 전에 먼저 할 일이 있다.

폴더를 나누는 것이다.

여기서 중요한 것은 “예쁜 폴더 구조”가 아니다.

실제 업무 구조를 그대로 반영하는 것이 중요하다.

예를 들어 콘텐츠를 만드는 회사라면

LinkedIn
Instagram
Newsletter
YouTube

처럼 나눌 수도 있다.

하지만 B2B SaaS 회사라면

Marketing
Sales
Customer Success
Operations
Product

가 더 자연스럽다.

1인 사업자라면

Clients
Products
Content
Finance
Admin

이 될 수도 있다.

기준은 단순하다.

두 업무가 거의 같은 자료를 사용하지 않는다면 폴더도 분리하는 것이 좋다.

---

문제는 폴더가 아니라 '연결'이다

폴더 안에 파일이 있다고 해보자.

customer-persona.md
brand-voice.md
linkedin-strategy.md
best-posts.md
newsletter-guide.md
sales-call-notes.md

사람은 파일 이름만 보고도 대충 관계를 추측한다.

하지만 AI에게는 조금 더 명확한 구조가 필요하다.

예를 들어

customer-persona
      ↓
brand-voice
      ↓
linkedin-strategy
      ↓
best-posts

와 같은 연결이 있어야 한다.

고객 분석을 기반으로 브랜드 톤을 만들었고,

그 브랜드 톤을 기반으로 LinkedIn 전략을 만들었으며,

그 전략의 실제 성공 사례가 best-posts.md라는 사실을 알려주는 것이다.

이게 Graph다.

거창한 그래프 데이터베이스가 없어도 된다.

처음에는 Markdown 파일 하나면 충분하다.

---

MAP.md 하나 만들기

가장 단순한 방법은 프로젝트 폴더에

MAP.md

를 만드는 것이다.

그리고 Claude Code나 다른 Coding Agent에게 폴더를 분석하게 한다.

예를 들어 이런 식이다.

이 폴더에 있는 모든 파일을 읽어라.

각 파일이 무엇에 관한 문서인지 분석하고,
어떤 파일들이 같은 주제나 개념을 공유하는지 찾아라.

그리고 MAP.md를 만들어라.

MAP.md에는 다음 내용을 포함한다.

1. 발견한 주요 주제
2. 각 주제와 관련된 파일
3. 다른 문서에서 전혀 참조되지 않는 파일
4. 서로 연결되어야 할 것 같은 파일
5. 전체 분석 파일 수
6. 분석 날짜

연결 관계에는 반드시 다음 표시를 붙인다.

FOUND:
두 문서에서 실제 연결 관계를 확인한 경우

GUESSED:
내용을 보고 연결 관계를 추론한 경우

추론을 사실처럼 작성하지 않는다.

여기서 재미있는 결과가 나온다.

---

생각보다 많은 문서가 '고아 문서'다

수백 개의 파일을 분석해보면
상당수 문서는 다른 파일에서 한 번도 언급되지 않는다.

이런 파일을 흔히

Orphan Document

라고 부른다.

파일은 존재한다.

삭제된 것도 아니다.

내용도 좋다.

하지만 어떤 문서도 이 파일을 가리키지 않는다.

AI 입장에서는 굳이 열어볼 이유가 없다.

그래서 실제 업무에서는 없는 문서와 비슷해진다.

원문 사례에서는 전체 2,364개 문서 가운데

1,840개가 다른 곳에서 연결되지 않은 상태였다고 한다.

약 78%다.

자료를 많이 만들어온 사람일수록 한 번쯤 확인해볼 만한 숫자다.

---

가장 재미있는 것은 '의외의 연결'이다

MAP을 만들면서 생각보다 가치가 큰 부분이 하나 있다.

AI가

“이 두 파일은 사실 연결되어 있습니다.”

라고 알려주는 순간이다.

예를 들어

customer-interview-2025.md

↓

pricing-strategy.md

처음에는 완전히 다른 문서처럼 보일 수 있다.

하지만 고객 인터뷰에서 반복적으로 등장한 불만이
현재 가격 전략의 근거가 되었다면 두 문서는 연결되어야 한다.

또는

failed-campaign.md

↓

brand-rules.md

도 연결될 수 있다.

실패한 캠페인에서 배운 교훈이
현재 브랜드 규칙을 만든 계기일 수 있기 때문이다.

사람은 시간이 지나면 이런 관계를 잊는다.

AI는 전체 문서를 한 번에 비교하면서
이런 연결을 다시 발견하는 데 꽤 강하다.

다만 한 가지 조건이 있다.

추론과 사실을 반드시 분리해야 한다.

그래서 FOUND와 GUESSED 표시가 중요하다.

---

Graph Engineering에서 가장 중요한 질문

MAP을 만든 다음에는 바로 파일을 수정할 필요가 없다.

먼저 이렇게 물어보는 편이 좋다.

MAP.md를 읽어라.

발견한 문제 각각에 대해

1. 그대로 두면 어떤 문제가 발생하는지
2. 해결하기 위한 가장 작은 수정은 무엇인지
3. 수정 위험도는 얼마나 되는지

분석해라.

확실한 수정만 진행하고,
기존 운영 문서나 중요한 파일을 수정해야 한다면
먼저 나에게 확인해라.

여기서 중요한 표현이 있다.

“가장 작은 수정.”

AI에게 시스템 전체를 개선하라고 하면
과도하게 파일을 합치거나 구조를 다시 만들 가능성이 있다.

하지만 대부분의 경우 필요한 것은 대수술이 아니다.

링크 하나,

설명 한 줄,

참조 하나만 추가해도 충분하다.

---

그리고 Loop를 붙인다

MAP을 한 번 만들고 끝내면
몇 주 뒤 다시 오래된 문서가 된다.

그래서 중요한 것이 Loop다.

프로젝트의 CLAUDE.md나 AGENTS.md 등에 이런 규칙을 넣는다.

이 폴더에서 작업하기 전에 MAP.md를 읽는다.

작업이 끝난 뒤 새롭게 발견한 중요한 관계가 있다면
MAP.md를 업데이트한다.

이렇게 하면 Graph가 정적인 문서가 아니라 살아 있는 구조가 된다.

새로운 파일을 만들고,

기존 파일을 수정하고,

새로운 연결을 발견할 때마다

Graph도 조금씩 좋아진다.

---

결국 이것은 'AI용 사내 위키'다

Graph Engineering이라는 이름 때문에
조금 어렵게 느껴질 수 있다.

하지만 실제로 하는 일은 꽤 익숙하다.

사람이 일하기 편하도록 만들었던

• 위키
• 문서 링크
• 목차
• 업무 매뉴얼
• Knowledge Base
• 사내 포털

을 AI도 사용할 수 있는 구조로 바꾸는 것이다.

차이가 있다면 하나다.

사람은 경험과 눈치로 빈 연결을 어느 정도 채울 수 있다.

AI는 그렇지 않다.

그래서 연결을 좀 더 명확하게 만들어줘야 한다.

---

개인 AI 시스템에서 팀 AI 시스템으로

여기서 Graph의 진짜 장점이 나타난다.

개인이 Claude Code를 잘 사용하는 것은 어렵지 않다.

문제는 팀이다.

A가 만든 Skill을 B가 모른다.

B가 수정한 프롬프트를 C는 여전히 예전 버전으로 사용한다.

대표가 가지고 있는 브랜드 노하우는 대표 컴퓨터 안에만 있다.

그러면 AI를 도입했는데도 지식은 계속 사람에게 종속된다.

Graph를 만들고 프로젝트 구조를 GitHub 같은 저장소에 올리면 상황이 달라진다.

팀원은 같은

• MAP
• Skill
• Memory
• Workflow
• Rule
• Example

을 공유할 수 있다.

누군가 시스템을 개선하면

다른 사람도 최신 버전을 받을 수 있다.

이때부터 AI는 개인 생산성 도구에서

조직의 운영 시스템으로 바뀐다.

---

좋은 AI 시스템은 프롬프트보다 구조에 가깝다

AI를 처음 사용할 때는 좋은 프롬프트를 찾는다.

조금 익숙해지면 Context를 고민한다.

더 많이 사용하면 Skill과 Workflow를 만든다.

그리고 자료가 쌓이기 시작하면 결국 이런 질문에 도착한다.

“AI가 이 많은 것 중에서 무엇을 봐야 하는지 어떻게 알지?”

Graph Engineering은 바로 그 질문에 대한 답이다.

중요한 것은 AI에게 정보를 많이 주는 것이 아니다.

AI가

어떤 정보를 언제 찾아야 하는지 알 수 있게 만드는 것.

어쩌면 앞으로 개인과 회사의 AI 활용 능력을 가르는 차이는
모델의 성능보다 이런 지식 구조에서 더 크게 벌어질지도 모른다.

---

오늘 바로 해볼 수 있는 것

거창한 시스템부터 만들 필요는 없다.

매주 가장 자주 열어보는 폴더 하나를 고른다.

그리고 AI에게 묻는다.

이 폴더의 모든 파일을 분석해서

어떤 정보가 있고,
어떤 문서가 서로 연결되어 있으며,
어떤 문서가 아무 곳에서도 참조되지 않는지

MAP.md로 만들어줘.

결과를 보면 의외로 재미있다.

그리고 아마 이런 생각이 들 가능성이 높다.

“나는 자료가 부족했던 것이 아니라, 연결이 부족했던 거구나.”

AI 시대의 지식관리는
점점 파일을 많이 모으는 일이 아니라

정보 사이에 길을 만드는 일이 되고 있다.

그게 요즘 이야기하는
Graph Engineering의 가장 현실적인 의미다.