Joon's Field Notes — AI, knowledge, and systems

요약

VIO는 Visual Identity Ontology, 곧 브랜드 비주얼 아이덴티티를 위한 온톨로지로 시작했다. 그런데 실제로 만들어 보니 이건 비주얼을 위한 저장소가 아니었다. 더 큰 것을 설명하고 있었다.

이 글의 논지는 하나다. Agentic Workflow에서 Workflow, Conversation, Knowledge, Work Memory는 서로 다른 데이터가 아니다. 모두 하나의 그래프 위에서 표현되는 동일한 구조이며, 차이는 노드의 종류가 아니라 의미(Semantics)뿐이다. 그리고 에이전트의 역할은 문서를 만드는 것이 아니라 그 그래프를 실행 중에 계속 진화시키는 것이다.

그래서 글을 세 층으로 쌓는다. 첫째 사상: 기존 시스템은 데이터를 저장하지만 의사결정은 저장하지 않는다. 실제 업무는 문서가 아니라 관계, 곧 그래프다. 둘째 구조: Workflow도, 대화도, 지식도, 작업 기억도 들여다보면 모두 Node와 Relation의 같은 구조다. 셋째 런타임: 실행 과정 자체가 온톨로지를 바꾼다. 지식이 실행을 만들고, 실행이 새 지식을 만든다. 이 순환을 돌리는 시스템이 VIO다. 그래서 마지막에 VIO를 Visual Identity Ontology가 아니라 Dynamic Ontology Runtime, 더 정확히는 Semantic Runtime으로 다시 정의한다.

이 글을 따라가는 하나의 예시. 추상적인 이야기가 많이 나오니, 구체적인 장면 하나를 깔고 간다. "뉴스레터 글 하나의 히어로 배너 이미지를 만든다"는 작업이다. 후보 이미지 몇 개를 뽑고, 비교하고, 하나를 고르고, "좀 더 차분하게"라고 피드백을 주고, 다시 뽑는다. 누구나 한 번쯤 해 본 이 평범한 작업이, 알고 보면 전부 그래프를 만지는 일이라는 게 이 글의 줄거리다.

1부. 사상: 업무는 문서가 아니라 그래프다

1. 기존 시스템은 데이터를 저장한다. 의사결정은 저장하지 않는다.

대부분의 AI 시스템은 작업의 결과물을 파일 단위로 관리한다. Prompt.md, Style.md, Rule.md, History.md, Workflow.json. 각 파일은 존재한다. 그런데 그 파일들이 왜 그렇게 되었는지는 어디에도 연결되어 있지 않다.

예시로 돌아가 보자. 지난달 히어로 배너를 만들 때 후보 세 개 중 파란 버전을 골랐다고 하자. 한 달 뒤 새 배너를 만들려고 폴더를 열면 hero.png 한 장만 남아 있다. 나머지 두 후보도 없고, 왜 파란 버전이었는지도 없다. 그때 "주황은 경쟁사 색이라 뺐다"고 판단했더라도, 그 판단은 파일 어디에도 적혀 있지 않다. 그래서 이번에도 주황 후보를 또 만들고, 또 같은 이유로 지운다.

이게 핵심이다. "Prompt A로 Image C를 생성했다"까지는 남는다. 하지만 왜 C가 선택됐는가, 왜 그 Prompt가 수정됐는가, 왜 Workflow가 바뀌었는가는 사라진다. 즉 데이터는 저장되지만 의사결정은 저장되지 않는다. 남는 것은 결과의 스냅샷이고, 그 결과에 이르게 한 판단의 사슬은 휘발된다. 그래서 시스템은 매번 같은 판단을 처음부터 다시 한다.

2. 실제 업무는 관계(Relation)다.

사람은 문서를 만드는 게 아니라 계속 판단한다. 배너 하나를 정하는 과정만 봐도 그렇다. 후보(Alternative)를 만들고, 비교하고, 고르고, 피드백을 받고, 수정하고, 다시 만든다.

각 단계는 독립된 이벤트가 아니다. 원인과 결과를 가진다. 파란 후보를 고른 그 순간을 풀어 쓰면 이렇다.

Alternative C  --selected_by-->  User
               --because_of-->   Brand Fit
               --creates-->      Feedback
               --updates-->      Workflow

읽으면 이렇다. 파란 후보 C를 골랐는데(Alternative C), 골라준 건 나이고(selected_by User), 고른 이유는 브랜드 톤에 맞아서이며(because_of Brand Fit), 그 선택이 "주황 계열은 피하자"는 피드백을 낳고(creates Feedback), 그 피드백이 다음 생성의 기본 팔레트를 바꾼다(updates Workflow). "C를 골랐다"는 사실 하나에 누가·왜·그래서 무엇이 생겼고·무엇이 바뀌었는가가 전부 엮여 있다.

이걸 파일 다섯 개로 흩어 놓으면 그 관계가 끊긴다. 업무의 본질은 바로 그 관계인데 말이다. 즉 업무는 문서가 아니라 그래프다. 노드는 후보·사용자·근거·피드백이고, 엣지는 selected_by·because_of·creates·updates다. 의사결정을 저장한다는 건, 결국 이 엣지를 저장한다는 뜻이다.

2부. 구조: 모두 같은 그래프다

여기서부터가 VIO를 만들며 가장 분명해진 부분이다. 우리가 따로 짜고 있던 네 가지가, 들여다보니 같은 구조였다.

3. Workflow도 그래프다.

Workflow를 보통 순서로 생각한다. Generate → Review → Render. 하지만 실제 Workflow는 순서가 아니라 조건과 분기다.

Generate --> Review --> approved?
                        |-- Yes --> Render
                        |-- No  --> Generate Alternative

배너 작업이 정확히 이렇다. 후보 세 개를 올렸는데 다 마음에 안 들면 렌더로 넘어가지 못한다. "다시, 좀 더 미니멀하게"가 되어 후보 생성으로 되돌아간다. VIO의 생성 흐름도 같다. 후보를 만들고(Alternative Set), 비교표(Comparison Table)를 올리고, 고르면(User Selection) 슬롯을 잠그고(Final Slot Locking) Visual DOM으로 내려가지만, 못 고르면 다시 후보 생성으로 돌아간다. Workflow는 한 줄로 흐르는 파이프라인이 아니라, 조건에 따라 갈라지는 Instruction Graph다.

4. Conversation도 그래프다.

대화 역시 채팅 로그가 아니다. 시간순으로 쌓인 말풍선의 나열처럼 보이지만, 실제로 일어나는 건 상태(State)의 변화다.

Question --> Intent --> Entity --> Clarification --> Decision --> Memory --> Next Question

"좀 더 차분하게 해줘"라는 한마디를 보자. 이 말은 의도(톤을 낮춰라)로 해석되고(Intent), 어떤 속성을 건드릴지로 좁혀지고(Entity: 채도냐 여백이냐 폰트 굵기냐), 모호하면 "채도를 낮출까요, 여백을 늘릴까요"로 되묻고(Clarification), 하나로 정해지면 결정이 되고(Decision), 그 결정이 기억에 남아(Memory) 다음에 "차분하게"라고 하면 무슨 뜻인지의 전제가 된다. 모든 대화는 이렇게 상태를 한 칸씩 옮긴다. 곧 Interaction Graph다.

5. Work Memory도 그래프다.

작업 기억은 History가 아니다. "무엇이 있었는지"의 연대기가 아니라 "무엇 때문에 바뀌었는가"의 사슬이다.

Issue --> Alternative --> Decision --> Rule --> Workflow Update

"로고가 너무 작아서 안 보인다"는 지적이 한 번 나왔다고 하자(Issue). 그래서 로고를 키운 후보를 만들고(Alternative), "이 버전으로 가자"고 정하면(Decision), "로고는 가로폭의 최소 8%"라는 규칙이 되고(Rule), 그게 이후 모든 배너 생성 워크플로에 박힌다(Workflow Update). 다음부터는 같은 지적이 나오지 않는다. VIO의 MSO work-memory가 이 모양을 그대로 쓴다. 이슈 노트(IN), 후보 기록(AR), 결정(AD·UD)이 서로를 가리키며 이어진다. 기억이 저장하는 건 결과가 아니라 변화의 인과다. 곧 Experience Graph다.

6. Ontology도 그래프다.

온톨로지 역시 단순한 Class Tree가 아니다. 상속만 있는 분류 나무가 아니라 의미를 가진 관계의 망이다. 우리가 만들던 그 히어로 배너를 지식으로 적으면 이렇게 된다.

Hero Banner --has-->       Headline
            --has-->       CTA
            --supports-->  Brand Identity
            --used_in-->   Landing Page

Hero Banner가 Headline과 CTA를 가지고, 그것이 Brand Identity를 떠받치고, Landing Page에서 쓰인다. 지식 자체가 관계다. 곧 Knowledge Graph다.

7. 결국 모두 같은 구조다.

겉으로는 Workflow, Conversation, Ontology, Work Memory 네 가지처럼 보인다. 하지만 내부적으로는 모두 Node -> Relation -> Node만 존재한다. 위에서 본 네 개의 다이어그램을 다시 보라. 화살표에 붙은 이름만 다를 뿐, 노드를 관계로 잇는 모양은 전부 똑같다.

보이는 이름	실제 정체
Workflow	Instruction Graph
Conversation	Interaction Graph
Ontology	Knowledge Graph
Work Memory	Experience Graph

차이는 노드의 종류가 아니라 의미(Semantics)뿐이다. 같은 그래프 기계 위에 무엇을 노드로 두고 어떤 엣지로 잇느냐만 다르다. 그래서 이 넷을 따로 짠 시스템은, 사실 같은 엔진을 네 번 다시 구현하고 있었던 셈이다. 배너 하나를 만들 때도 우리는 이 네 그래프를 동시에 만지고 있었다. 분기(Workflow)를 타고, 대화(Conversation)로 의도를 좁히고, 지적을 규칙(Work Memory)으로 남기고, "배너는 이런 것"이라는 지식(Ontology)을 갱신한다.

3부. 런타임: 실행이 지식을 바꾼다

구조가 같다는 것까지는 정적인 관찰이다. VIO의 진짜 차이는 여기서부터다. 이 그래프는 실행 중에 멈춰 있지 않다.

8. Agent는 그래프를 수정하는 존재다.

많은 Agent Framework는 Prompt -> LLM -> Tool -> Output에서 끝난다. 입력을 받아 출력을 뱉는 함수다. 하지만 실제 에이전트가 하는 일은 이 순환이다.

Graph --> Decision --> Edge 수정 --> State 변경 --> Graph

에이전트가 새 배너 후보를 만들 때를 떠올려 보자. 빈손에서 시작하지 않는다. 그래프에서 "지난번에 주황은 뺐고, 로고 최소 크기 규칙이 있고, 톤은 차분하게로 합의됐다"를 읽어 와(Graph), 그걸 반영한 후보를 내고(Decision), 이번 선택과 피드백을 다시 그래프에 엣지로 쓴다(Edge 수정 → State 변경 → Graph). 즉 에이전트의 역할은 문서를 생성하는 것이 아니라 그래프를 진화시키는 것이다. 출력(이미지 한 장)은 부산물이고, 본체는 그래프의 변형이다.

9. Dynamic Ontology: 실행이 온톨로지를 바꾼다.

기존 온톨로지는 정적이다. "Apple isA Fruit"는 어제도 오늘도 같다. 한 번 정의되면 실행과 무관하게 고정이다.

하지만 Agentic Workflow에서는 다르다. 후보가 선택되고(Selected), 컴파일되고(Compiled), 렌더링되고(Rendered), 리뷰되고(Reviewed), 피드백이 정책을 바꾸고(Policy Update), 정책이 워크플로를 바꾼다(Workflow Update). 예를 들어 배너 작업을 몇 번 거치며 "둥근 모서리가 우리 브랜드답다"가 거듭 선택되면, 그건 일회성 취향으로 끝나지 않는다. 지식 그래프에 Brand Identity --prefers--> Rounded Corners라는 새 엣지로 남아 다음 생성의 전제가 된다. 실행 과정 자체가 온톨로지를 변화시킨다. 온톨로지는 박제된 정의가 아니라 실행 중(Runtime)에 계속 성장하는 살아 있는 구조다.

10. Dynamic Ontology Runtime

그래서 VIO는 Visual Identity Ontology가 아니라, 더 정확히는 Dynamic Ontology Runtime이다. 여기서는 다음이 하나의 순환을 이룬다.

Knowledge --> Workflow --> Execution --> Decision --> Memory --> Knowledge

지식은 실행을 만들고, 실행은 결정을 낳고, 결정은 기억에 남고, 기억은 다시 지식이 된다. 닫힌 고리다. 배너를 한 장 만들 때마다 이 고리가 한 바퀴 돌고, 돌 때마다 "우리 브랜드다움"의 그래프가 조금씩 더 정확해진다. 백 번째 배너는 첫 번째 배너보다 적은 피드백으로 완성된다. 그래프가 그동안의 결정을 기억하고 있기 때문이다.

핵심 정의. Dynamic Ontology Runtime은 Workflow, Conversation, Knowledge, Work Memory를 동일한 그래프 언어 위에서 표현하고, 실행 과정에서 그래프 자체를 지속적으로 진화시키는 Agentic Runtime이다.

4. 가장 독창적인 지점: Semantic Runtime

여기에 한 관점을 더하고 싶다. VIO의 가장 독창적인 부분은 "Dynamic Ontology"보다 "Semantic Runtime"에 있다.

Semantic Web은 원래 지식을 표현(Representation) 하기 위한 기술로 알려져 있다. RDF/OWL은 보통 "지식을 어떻게 저장하고 교환할 것인가"의 형식으로 쓰인다. 그런데 VIO는 RDF/OWL을 단순한 저장 형식이 아니라, 실행 중인 시스템의 상태(State), 의사결정(Decision), 경험(Memory), 정책(Policy) 까지 표현하는 공통 언어로 쓴다.

차이가 여기서 갈린다. 대부분의 시스템은 지식 그래프는 시맨틱하게 두되, 워크플로는 코드로, 대화는 로그로, 기억은 또 다른 포맷으로 짠다. 앞의 배너 예시로 말하면, "배너는 Headline과 CTA를 가진다"는 지식만 그래프로 두고, "후보가 거절되면 다시 생성한다"는 분기나 "주황은 뺐다"는 결정은 전부 그래프 바깥의 코드와 로그에 흩어 둔다. VIO는 그 넷을 모두 같은 Semantic Graph 위에 올린다. 그래서 VIO는 Knowledge Graph를 저장하는 시스템이 아니라, Knowledge·Workflow·Conversation·Memory를 모두 동일한 Semantic Graph 위에서 실행하는 Runtime이다.

이 정의가 현재의 Agent Framework와 VIO를 가르는 철학적·기술적 포지셔닝이다. 다른 프레임워크가 "LLM을 어떻게 호출하고 도구를 어떻게 엮을 것인가"에 답한다면, VIO는 "지식·실행·대화·경험을 어떤 하나의 언어로 표현하고, 그 언어를 실행하면서 어떻게 진화시킬 것인가"에 답한다.

정리

세 층으로 다시 압축한다.

사상. 기존 시스템은 결과(hero.png)를 저장하지만 "왜 그걸 골랐는가"는 휘발시킨다. 실제 업무는 문서가 아니라 관계, 곧 그래프다. 저장해야 할 것은 결과가 아니라 엣지다.
구조. Workflow(Instruction Graph), Conversation(Interaction Graph), Ontology(Knowledge Graph), Work Memory(Experience Graph)는 모두 Node -> Relation -> Node의 같은 구조다. 배너 한 장을 만들 때 우리는 이 네 그래프를 동시에 만진다. 차이는 의미뿐이다.
런타임. 에이전트는 그 그래프를 실행 중에 진화시킨다. 지식이 실행을 만들고 실행이 지식을 만드는 순환이 돌며, 배너를 만들수록 "브랜드다움"이 또렷해진다. 그래서 VIO는 Visual Identity Ontology가 아니라 Dynamic Ontology Runtime이고, 가장 정확히는 RDF/OWL을 실행 언어로 쓰는 Semantic Runtime이다.

VIO를 브랜드 비주얼 저장소로 시작했지만, 그 안에서 만들어진 진짜 물건은 비주얼에 국한되지 않는다. 같은 그래프 위에서 지식과 실행을 함께 진화시키는 런타임. 그게 이 프로젝트가 실제로 짓고 있는 것이다.