나만 보는 문서를 만들고 있었다: '이거 쓸 사람 있어?'가 바꾼 자동화

각 절은 일상 비유로 먼저 설명하고, 이어서 한 겹 더 깊이 들어간다. 비유만 읽어도 흐름은 다 잡힌다. 더 들어가고 싶을 때만 계속 읽으면 된다.

요약

AI 에이전트로 내 일을 자동화하는 도구를 다듬다가, 좀 민망한 걸 깨달았다. 나는 받아 쓸 사람도, 다음 단계도 없는 결과물을 계속 만들어 쌓고 있었다.

생각해 보면 사람끼리 일할 때는 안 그런다. 협업할 때 나 혼자 보고 끝낼 문서를 굳이 보고서처럼 각 잡아 만들지는 않는다. 받는 사람이 있어야 그 형식도, 그 수고도 의미가 있으니까. 그래서 기준을 하나 세웠다. 무언가 만들기 전에 묻는다. "이거, 받아서 쓸 사람이 이 흐름 안에 있나?" 이 글은 그 질문에 닿기까지의 이야기다.

---

1. 작업 순서도를 그리려다 빈 화면을 봤다

내 자동화 작업의 순서도를 자동으로 그려주는 작은 도구를 만들었다. 어떤 일이 어떤 일로 이어지는지 한눈에 보려고. 그런데 막상 돌려보니 화면이 텅 비었다. 일은 분명히 칸칸이 들어 있는데, 그 칸들을 잇는 선이 하나도 안 그려졌다.

원인은 단순했다. 나는 "이 일 다음엔 저 일"이라는 연결을 각 일의 메모 안에 한 줄로만 적어두고 있었다. 사람이 읽으면 자연스럽게 이어지지만, 그림을 그리는 입장에서 연결은 칸 안의 메모가 아니라 칸과 칸을 잇는 별도의 '선'으로 있어야 했다. 그 선을 만들어 둔 적이 없으니 그릴 게 없었다.

워크플로 정의에서 yaml을 걷어내고 ttl(RDF Turtle)로 옮기던 중이었다. 정본(SSOT)을 사람이 읽는 선언 포맷이 아니라 기계가 추론할 수 있는 그래프로 두고 싶었기 때문이다. 그런데 yaml에서 next는 노드 블록 안에 박힌 속성이었다.

- node:
    id: id
    type: task
    property:
      - instruction: "prompt"
        input: {directory: <directory>, format: <format>}
        output: {directory: <directory>, format: <format>}
    next: id

그래프로 그리려면 next는 노드의 속성이 아니라 두 노드를 잇는 edge여야 한다. edge는 시작점과 끝점을 가진, 그 자체로 하나의 객체다. ttl로 옮기면서 이 next를 edge class로 따로 세워줬어야 했는데 그러질 못했고, 노드만 있고 잇는 관계가 데이터에 없으니 시각화 도구(mso-graph-observability)는 그릴 선이 없어서 깨졌다.

2. 알고 보니, 흐름이 내 머릿속에만 있었다

빈 화면이 알려준 건 따로 있었다. 내 작업이 어떻게 이어지는지, 그 전체 흐름이 사실 어디에도 적혀 있지 않고 줄곧 내 머릿속에만 있었다는 것이다. 전에는 메모를 눈으로 죽 이어 읽으며 머릿속에서 알아서 그림을 완성하고 있었다. 연결이 실제로는 없어도 사람은 흐름을 느끼니까, 빈자리가 안 보였다.

edge가 비어 있다는 건 결국 repository의 workflow topology와 sub-graph가 데이터 어디에도 없이 내 머릿속에만 있었다는 얘기였다. 관측 도구는 그 상상을 봐주지 않는다. 데이터에 edge가 없으면 화면에도 선이 없다. 머릿속 topology와 데이터 속 topology 사이의 간극을, 깨진 그래프가 곧이곧대로 드러낸 셈이다.

3. 진짜 물음: 나만 보는 문서를 만들고 있었나

간극을 메우려고 흐름을 하나하나 적다, 정작 물어야 할 게 바뀌었다. 처음엔 "이 결과물을 파일로 둘까, 데이터로 둘까" 같은 형식 문제인 줄 알았다. 그런데 그건 별로 중요하지 않았다. 중요한 건 이 결과물을 받아서 쓸 상대가 있느냐였다.

사람끼리 협업할 때를 떠올려 보자. 옆자리 동료에게 넘길 자료라면 그 사람이 읽기 좋게 정리한다. 나중에 팀이 다시 찾아볼 자료라면 검색되게 정해진 자리에 둔다. 그런데 받는 사람도 없고 다시 꺼낼 일도 없는 문서를, 굳이 시간 들여 보고서처럼 만들 이유는 없다. 내 자동화가 딱 그러고 있었다. 단계마다 문서며 메모를 그럴듯하게 만들어 쌓는데, 정작 그걸 받아 쓰는 다음 단계도, 읽을 사람도 없었다.

파일이냐 데이터냐의 구분은 쓸모가 없었다. 파일도 데이터의 한 형태고, 워크플로 입장에선 둘 다 읽고 쓰는 대상일 뿐이다. 그래서 MSO는 데이터(Data)보다 Artifact를 가운데 놓고 워크플로를 짠다. 워크플로는 데이터를 직접 건드리지 않고, Repository 안의 Artifact를 읽고 해석해 새 Artifact를 만들어낸다. 즉 워크플로가 굴리는 건 Data Pipeline이 아니라 Artifact Supply Chain이다.

Artifact
   │ Read
   ▼
Data
   │ Parse / Query / Reasoning
   ▼
Knowledge
   │ Serialize
   ▼
Artifact

• Artifact는 Repository에서 관리하는 단위다. 커밋되고, 버전이 붙고, 공급망을 타고 도는 그 단위.
• Data는 그 Artifact 안의 표현이다. ttl, jsonl, 마크다운 텍스트 같은 형식.
• Knowledge는 그 Data를 해석했을 때 손에 남는 의미다. 관계, 추론, 판단.

들어오는 것도 Artifact, 나가는 것도 Artifact다. 가운데 Data와 Knowledge는 변환을 거치는 동안만 잠깐 머무는 상태일 뿐이다.

4. 결과물마다 '받는 사람'이 다르다

그러고 보니 결과물은 종류마다 받는 쪽이 달랐다. 한 폴더에 다 뭉뚱그릴 게 아니라, 누가 쓸지에 따라 자리도 형식도 달라져야 했다.

• 사람이 읽고 고치는 것 : 보고서, 메모, 설명서. 동료에게 건네는 자료처럼 사람도 읽고 에이전트도 참고한다. 사람이 쉽게 찾아 고칠 자리에 둔다.
• 나중에 다시 꺼내 쓸 것 : 지금 읽을 사람은 없지만 나중에 검색·재사용하려고 모아두는 자료. 회사로 치면 잘 정리된 장부나 데이터베이스다. 검색·조회가 쉬운 형태로 정리해 둔다.
• 밖으로 내보내는 최종물 : 고객이나 외부에 전달하는 발표자료, PDF, 이미지. 더 손볼 게 아니라 그대로 나가는 결과물이다.

이 세 갈래는 Artifact를 소비 방식으로 나눈 것이고, 더 잘게 보면 다섯 타입이다.

크게 묶으면, Machine-native(Knowledge Store·Event Store·Local Database)는 Agent가 직접 질의·검색·추론하는 자리, Hybrid(Document)는 사람과 Agent가 같이 읽고 고치는 자리, Human-native(Media)는 Repository 밖으로 나가는 Deliverable이다. 같은 "파일"이라도 워크플로가 대하는 방식이 다르니, 종류를 가르는 일이 곧 어디에 둘지를 정하는 일이었다.

5. 한 저장소 안에 여러 겹의 그림이 있었다

흐름을 적어 펼쳐 보니, 사실 작업이라는 게 한 겹이 아니었다. 세 가지가 겹쳐 있었다. 누가 다음에 일하나(순서), 누가 무엇을 만들어 누구에게 넘기나(인계), 그 안에 어떤 노하우가 담기나(의미). 평소엔 뭉뚱그려 "작업"이라 부르던 게, 뜯어보니 이 세 결의 합이었다.

Repository 안에는 세 그래프가 동시에 산다.

Task Graph 는 Task끼리의 실행 관계를 담는다. 처음에 next를 edge로 못 세워 깨졌던 그 그래프다. 대표 관계는 next, dependsOn, triggers.

Task A ──next──▶ Task B

Artifact Graph 는 Artifact를 누가 만들고 누가 쓰는지를 담는다. 대표 관계는 consumes, produces, reads, writes.

prompt.md ──consumes──▶ Task A ──produces──▶ summary.md ──consumes──▶ Task B

Task A가 만든 summary.md를 Task B가 가져다 쓰니까 두 Task가 이어진다. Knowledge Graph 는 Artifact 안에 담긴 의미와 관계(RDF/OWL 온톨로지, Workflow Topology 등)를 담는 의미 계층이다. 셋을 합치면 하나의 Repository Workflow Topology가 된다.

2절에서 "내 머릿속에만 있다"던 sub-graph 경계도 이제 데이터로 갈린다. 같은 target Artifact로 모여드는 stream은 한 워크플로로 묶고, 갈라지거나 다르게 소비되는 stream은 별개의 워크플로 경계 후보로 본다. 관측 도구도 한 덩어리로 안 그리고 세 갈래로 나눠 그린다. 공급망만 보는 artifact-stream, 거기서 뽑은 task 흐름만 보는 workflow, 둘을 겹친 integrated.

6. 자동화의 무게중심이 '흐름'에서 '저장소'로 옮겨갔다

여기까지 오니 자동화를 보는 눈이 바뀌었다. 자동화를 "일을 순서대로 돌리는 기계"로 여겼는데, 진짜 중심은 흐름이 아니라 그 흐름이 만들어 쌓는 결과물들의 묶음, 즉 저장소였다. 일은 지나가지만 결과물은 남고, 다음 일은 그 남은 것을 집어 든다.

그래서 MSO는 Workflow Engine이 아니라 Repository Execution System이다. Workflow Engine은 노드와 화살표로 짜인 실행 흐름을 돌리고, 데이터는 그 사이를 지나가는 메시지에 가깝다. 반면 MSO에서 정본은 흐름이 아니라 Repository 그 자체다. Repository 안에 Task·Artifact·Knowledge 그래프가 같이 들어 있고, 실행이란 이 그래프들을 읽어 Artifact를 다음 상태로 옮기는 일이다. 워크플로가 Artifact를 흐르게 하고, Artifact가 Knowledge를 담고, Knowledge가 Agent의 실행과 추론을 떠받친다.

7. 그래서 생긴 기준: "이거 받을 사람 있어?"

흐름을 다 적어 그림으로 펼치니, 비로소 결과물 하나하나에 받는 쪽이 있는지를 따질 수 있게 됐다. 전에는 일단 만들어 쌓았다면, 이제는 만들기 전에 묻는다.

• 받는 쪽이 없으면, 안 만든다. 받을 사람 없는 보고서는 흐름에 끼워 넣지 않는다.
• 지금 쓸 건 아니지만 나중에 다시 꺼내 쓸 거라면, 줄글로 적어두는 대신 검색·조회가 쉬운 형태로 정리해 둔다.

이 점검을 머릿속에만 두지 않고 도구로 내렸다. artifact-stream-report.md가 워크플로마다 "생산은 됐는데 같은 워크플로 안에서 소비되지 않는 Artifact"를 짚어준다. agent 소비자가 없는 markdown, 흐름 끝에 매달린 review 문서나 media 전달물, 밖에서 들어온 external input 후보를 분류해 보여준다. 그래서 받는 쪽 없는 markdown은 생략하거나, 장기 조회·추론용이면 jsonl·ttl·sqlite 같은 machine-native Artifact로 구조화하라는 신호로 읽는다.

덤도 따라왔다. 디렉토리를 먼저 그리지 않게 됐다. 디렉토리는 topology와 Artifact 소비 관계에서 파생되는 구현 경계라서, 소비자가 없는 Artifact 경계는 줄이거나 합칠 후보가 된다. 폴더부터 짜고 일을 끼워 맞추던 순서가, 무엇이 어떻게 소비되는지를 보고 그 결과로 디렉토리가 따라오는 순서로 뒤집혔다.

8. 진짜 핵심은 이걸 도구에 박제했다는 것

사실 이 글에서 제일 중요한 대목은 따로 있다. 이 기준을 내 머릿속이나 그때그때의 지시로 두지 않고, 도구에 박제했다는 점이다.

예전엔 파일을 전부 내가 직접 보고 만들었다. 그러면서 "이건 이렇게 정리하자", "저건 빼자" 하고 손으로 챙겼다. 내가 다 보니까 챙겨졌다. 그런데 여러 프로젝트를 동시에 오가기 시작하면, 당연한 것도 놓친다. 받는 사람 없는 문서가 쌓여도 눈에 안 들어오고, "이건 당연히 이렇게 하지" 싶던 정리도 빠진다. 사람이 일일이 챙기던 방식은 다루는 저장소 수만큼 같이 늘어나주지 않는다.

그래서 판단을 점점 더 "엄밀하게 정의"하게 됐다. 느슨한 관례나 그때의 감으로 두면 저장소마다 조금씩 달라지고 결국 놓친다. 받는 사람이 있는지를 무엇으로 판정하는지, 결과물의 종류를 어떻게 가르는지가, 내 머리가 아니라 도구 안에 또렷한 규칙으로 박혀 있어야 내가 안 보고 있어도 같은 기준이 돈다.

그래서 이 점검을 일회성으로 두지 않고 mso-graph-observability 스킬에 규칙으로 박았다. artifact_type과 소비자 적합성을 관례가 아니라 정의로 못 박으니, 여러 repo·여러 workflow에서 같은 기준이 자동으로 적용된다. "엄밀한 정의"가 자꾸 필요해지는 이유가 여기 있었다. 사람의 주의력은 repo 수에 비례해 늘지 않으니, 놓치지 않으려면 그 주의를 도구가 대신 가질 만큼 또렷하게 적어둬야 한다.

9. 자동화의 핵심은 더 많이 만드는 게 아니었다

돌아보면 빈 화면은 버그가 아니라 진단이었다. 머릿속에만 있던 흐름은, 적어내서 눈에 보이게 만들기 전까지는 점검할 수도 고칠 수도 없었다.

교훈은 단순하다. 머릿속에만 있는 구조는 구조가 아니다. 그리고 자동화의 핵심은 더 많이 만들어내는 게 아니라, 받을 사람이 있는 걸 제때 만드는 것이었다. 사람끼리 일할 때 당연히 지키던 그 감각을, 자동화에도 그대로 들여온 셈이다.

기술로 말하면, topology를 데이터로 끌어내 실재하는 객체로 세우고, Artifact를 목적과 소비자로 갈라 제자리에 두는 일이다. 쉽게 말하면, 무언가 만들기 전에 한 번만 물으면 된다. "이거, 쓸 사람 있어?"