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

요약

에이전트에게 지시는 명확해야 한다. 해석의 여지가 없도록 만들면 된다. 그런데 매번 말로 명확하게 푸는 것 자체가 또 다른 일이다. 그래서 나는 명령 대신 정의 를 택했다. 정의(RDF/OWL)와 규약(SHACL)을 에이전트가 직접 소비할 수 있기에, 나는 Semantic Web이 에이전트에게 최고의 인터프리터 언어 라고 생각한다.

이 정의로 풀어야 할 질문은 세 가지로 모인다. 기억이란 무엇인가, 워크플로우란 무엇인가, 그리고 개선이란 무엇인가. 이 글은 그중 개선 에 대한 이야기다.

일을 집합 으로 그려보면 개선의 구조가 또렷해진다. 일은 작은 작업(task)과 판단(decision)의 연속이고, 그 묶음이 워크플로우라는 하나의 집합이다. 평가는 결과물 한 장이 아니라 이 워크플로우 자체를 대상으로 하며, 평가하는 일 역시 또 하나의 워크플로우다. 그리고 워크플로우는 그 안에 더 작은 워크플로우를 품는다.

여기서 단 하나의 규칙이 모든 것을 지탱한다. 평가하는 워크플로우는 평가받는 워크플로우와 겹쳐선 안 된다(서로소, disjoint). 내가 만든 것에는 애틋함이 생기고, 그래서 자기 평가는 자기 변호로 무너지기 때문이다. 이 규칙을 매번 손으로 챙기는 것도 노동이라, 나는 그것을 의미(Semantic)로 박았다. 규약(SHACL Shape)만 있으면 에이전트가 스스로 제자리를 잡는다. 이 글은 그 경계를 왜, 어떻게 그었는지에 대한 기록이다.

1. 에이전트에게 지시는 명확해야 한다

AI에게 일을 시켜 본 사람은 같은 벽을 만난다. 두루뭉술하게 시키면 두루뭉술한 결과가 나온다. 잘하게 하려면 명확해야 한다. 무엇을, 어떤 기준으로, 어떤 형태로 원하는지 해석의 여지가 없도록 만들면 된다.

그런데 역설이 있다. 매번 명확하게 명령하는 것 자체가 일이다. 사람이 어떤 업무를 '잘한다'고 할 때 그 안에는 수년의 경험과 훈련, 말로 옮긴 적 없는 감각이 들어 있다. 그걸 매번 빠짐없이 풀어내는 건 불가능에 가깝다. 우리는 우리가 아는 것의 대부분을 말로 설명하지 못한다.

그래서 나는 매번 자연어로 푸는 대신, 명확함을 한 번 정의해 박아두는 쪽을 택했다. 그 도구가 Semantic Web 이다.

정의(RDF/OWL): 무엇이 작업이고 무엇이 판단인지, 무엇이 무엇에 속하고 무엇과 무엇이 서로 배타적인지를 기계가 읽을 수 있는 의미 로 적는다.
규약(SHACL): 그 정의가 지켜야 할 모양(shape)과 제약을 적는다. 어긋나면 기계가 스스로 잡아낸다.

자연어 지시는 모델이 매번 해석 해야 한다. 해석에는 여지가 있고, 여지는 편차를 낳는다. 반면 RDF/OWL/SHACL는 에이전트가 소비 하는 의미다. 해석의 여지를 설계 단계에서 줄여 둔다. 그래서 나는 Semantic Web이 에이전트에게 최고의 인터프리터 언어라고 본다. 명령은 한 번 쓰고 사라지지만, 정의는 남아서 다음 일의 바닥이 된다.

2. 그래서 명령이 아니라 정의로

명령을 정의로 옮기다 보면, 결국 세 가지 질문으로 수렴한다.

기억이란 무엇인가. 무엇을 남기고, 무엇은 흘려보내며, 다음 에이전트에게 무엇을 넘기는가.
워크플로우란 무엇인가. 일은 어떤 단위로 나뉘고, 무엇이 무엇을 만들어 다음으로 흘려보내는가.
개선이란 무엇인가. 잘 됐는지를 무엇으로 판단하고, 그 판단을 어떻게 다음 일에 되먹이는가.

이 글은 그중 세 번째, 개선 에 대한 이야기다. 그리고 개선을 제대로 정의하려면, 먼저 일을 집합 으로 그려야 한다.

3. 일은 작은 작업과 판단의 연속이다

거창해 보이는 일도 뜯어보면 단순하다. 우리가 하는 일은 작은 작업(task)과 판단(decision)의 연속 이다. 무언가를 만들고, 갈림길에서 고르고, 또 만들고, 또 고른다.

이것을 그래프로 적으면 그대로 정의가 된다. 작업과 판단은 노드, 그 순서는 노드를 잇는 엣지(edge) 다. 그리고 이 노드와 엣지의 묶음 하나가 워크플로우, 즉 하나의 집합 이다.

워크플로우 = 작업과 판단을 감싼 하나의 집합.

그렇게 만든 결과물(artifact)이 좋았는지는 어떻게 아는가. 평가하고, 회고하고, 개선한다. 여기까지는 누구나 동의하는 상식이다. 문제는 이 상식이 조용히 깨지는 지점에 있다.

4. 평가는 결과가 아니라 흐름을 겨눈다. 그리고 평가도 워크플로우다

먼저 짚을 것. 평가는 결과물 한 장을 채점하는 게 아니다. 잘 됐는지는 그 결과물을 만들어낸 일의 흐름, 즉 워크플로우 자체를 대상으로 본다. 같은 결과라도 어떤 흐름에서 나왔는지에 따라 다음에 고칠 곳이 달라지기 때문이다.

그렇다면 평가하는 일은 무엇인가. 채점하고 개선하는 일에도 작업과 판단이 줄지어 있다. 결국 평가하는 일 역시 또 하나의 워크플로우 다. 나는 이 평가자를 Oracle 이라 부른다. 대상 업무도 집합이고, 평가·개선도 같은 모양의 집합이다. 둘은 같은 종류의 일이지만 역할이 다르다.

대상 업무도 워크플로우, 평가·개선(Oracle)도 워크플로우. 모양은 같고, 역할만 다르다.

5. 워크플로우 안에 워크플로우가 있다

워크플로우는 평평하지 않다. 그 안에 더 작은 워크플로우를 품는다(subWorkflow). 큰 일 안에 작은 일이 있고, 그 안에 또 더 작은 일이 있다. 집합 안의 집합, 그 안의 집합이다.

이건 단순한 구조 취향이 아니라 현실적인 선택 이다. 일 전체를 한 번에 평가하고 한 번에 고치는 건 비현실적이다. 작은 단위로 나눠 그 단위만 개선하는 편이 훨씬 다루기 쉽다. 그래서 어느 단위든, 저마다 평가 대상이 될 수 있어야 한다. 큰 워크플로우도, 그 안의 작은 워크플로우도.

이 포함 관계 역시 정의(OWL)로 또렷하게 적힌다. 무엇이 무엇에 속하는지가 의미로 남으면, 에이전트는 자기가 지금 어느 집합 안에서 일하는지 안다.

6. 단 하나의 규칙: 평가는 대상과 겹쳐선 안 된다

여기까지는 전부 자연스럽다. 그런데 딱 하나, 무너지기 쉬운 지점이 있다. 그리고 이 한 줄이 개선이라는 정의 전체를 지탱한다.

평가·개선 워크플로우는, 평가받는 대상 워크플로우와 절대 겹쳐선 안 된다.

집합의 언어로는 서로소(disjoint) 다. 둘은 나란히 놓이되, 결코 한쪽이 다른 쪽을 품거나 교집합을 갖지 않는다. 채점하는 집합과 채점받는 집합이 섞이는 순간, 평가는 평가이기를 멈춘다.

7. 왜 가르나: 내가 만든 것에는 애틋함이 생긴다

규칙은 알겠는데, 왜 그렇게까지 엄격해야 하나. 답은 사람의 마음에 있다.

내가 열심히 한 결과물일수록, 거기엔 애틋함 이 생긴다. 그렇게 만든 사정이 있었고, 포기한 대안이 있었고, 어쩔 수 없던 제약이 있었다. 그래서 우리는 자기 결과물을 평가할 때 평가하지 않고 정당화 한다. "이건 이래서 이렇게 한 거야." 틀린 말은 아니지만, 그건 평가가 아니다.

내가 들인 노력은, 내 결과물을 보는 눈을 흐린다.

에이전트는 이 함정에 더 잘 빠진다. 에이전트는 자기가 방금 내린 판단의 흐름을 그대로 따라 평가한다. 자기 논리 안에서는 모든 게 일관되어 보이기 때문이다. 사람의 애틋함이 정당화로 나타난다면, 에이전트에게는 그게 자기 일관성 으로 나타난다. 한 번 기울어진 기준이 다음 평가를 기울이고, 그 평가가 다음 일을 또 기울인다. 빠르게 도는 만큼, 편향도 빠르게 쌓인다.

대상이 자기를 고치는 일에 끼어들면, 평가는 자기 변호가 되고 개선은 자기참조 고리 에 빠진다. 자기 시험을 자기가 채점하고, 채점 기준까지 자기가 고치고, 그 기준으로 또 자기를 채점하는 끝없는 순환. 그래서 나는 다른 건 다 열어두되, '고치는 권한'만은 자기 자신에게 주지 않는다. 평가는 누구에게나 열려 있되, 나를 고치는 결정만은 내가 내리지 않는다. 그 한 줄이 고리를 끊는다.

8. 매번 손으로 챙기면 노동이다. 그래서 의미로 박았다

문제가 하나 남는다. 새 업무를 설계할 때마다 "이 평가 집합이 대상 집합과 겹치지 않았나"를 손으로 따지는 것 또한 노동 이다. 그리고 일이 늘수록 사람은 반드시 놓친다. 주의력은 일이 는 만큼 늘어나지 않는다.

그래서 나는 이 규칙을 머릿속 습관이 아니라 의미(Semantic)로 박았다. 규약(SHACL Shape)으로 적어 둔 것이다.

연속(stream): 작업물은 다음 일로 흐른다.
소속(subWorkflow): 작은 일은 큰 일에 속한다.
분리(disjoint): 평가는 대상과 겹치지 않는다.

이 규범만 정의해 두면, 에이전트가 워크플로우를 그릴 때 스스로 제자리를 잡는다. 평가 집합이 대상 집합과 겹치는 순간 규약이 어긋나고, 그 어긋남을 기계가 잡아낸다. 사람이 매번 감시하지 않아도, 잘못된 모양은 설계 단계에서 걸러진다. 흩어져 있던 집합들이 규범에 맞춰 제자리에 정렬되는 것이다.

이것이 1장에서 말한 'Semantic Web = 인터프리터'의 실제 쓸모다. 규칙을 말로 반복하는 대신 의미로 정의하면, 그 규칙은 잔소리가 아니라 구조 가 된다.

9. 정리: 세 규범이 워크플로우를 세운다

스스로 나아지는 시스템을 만들 때 우리는 흔히 무엇을 자동화할까 를 먼저 묻는다. 하지만 내가 오래 붙들고 내린 결론은 다른 질문이었다. 누가 무엇을 평가하고, 누가 무엇을 고칠 수 있는가.

그 답은 세 규범으로 압축된다.

규범	의미	한 줄
연속 (stream)	작업물이 다음 일로 흐른다	일은 흐름이다
소속 (subWorkflow)	작은 일은 큰 일에 속한다	작은 단위로 고친다
분리 (disjoint)	평가는 대상과 겹치지 않는다	만든 자가 채점하지 않는다

지시는 명확해야 하지만, 매번 명확하게 푸는 것도 일이다. 그래서 명령을 정의(RDF/OWL)와 규약(SHACL)으로 옮겼다.
일은 작업과 판단의 연속이고, 평가는 그 흐름을 대상으로 한다. 평가하는 일 또한 워크플로우다.
워크플로우는 그 안에 더 작은 워크플로우를 품고, 어느 단위든 평가 대상이 된다.
단 하나의 규칙은 분리다. 평가 집합과 대상 집합은 겹치지 않는다. 그 분리가 자기 변호와 자기참조를 막는다.
이 규범을 의미로 박아 두면, 에이전트가 스스로 제자리를 잡는다.

한 문장. 스스로 개선하는 시스템의 첫 단추는 더 똑똑한 실행이 아니라, 내가 만든 것을 내가 평가하지 않기로 정하는 것이다. 그리고 그 분리를 잔소리가 아니라 정의와 규약으로 박아 둘 때, 빠르게 도는 바퀴는 자기 편향으로 무너지지 않는다.

작성 메모

이 글은 특정 도구나 버전이 아니라, 내가 에이전트 워크플로우를 정의해 오며 세운 개선에 대한 관점 을 서사로 정리한 것이다. 핵심 어휘(작업 task, 판단 decision, 결과물 artifact, 평가자 Oracle, 연속 stream, 소속 subWorkflow, 분리 disjoint, 규범 Shape)는 그 작업에서 쓰는 개념틀이다.
기술 스택은 개방 표준을 그대로 가리킨다. RDF/OWL 로 노드·관계·포함·배타를 정의하고, SHACL 로 그 정의가 지켜야 할 모양(shape)과 제약을 규약으로 적는다. 'Semantic Web = 에이전트의 인터프리터 언어'라는 관점이 글 전체의 토대다.
중심 주장은 둘이다. (1) 자연어 명령을 정의·규약으로 대체해 해석의 여지를 줄인다. (2) 실행 집합과 평가 집합을 서로소(disjoint)로 두어 자기 평가 편향과 자기참조를 구조로 막는다.
비유(자기 채점, 애틋함)는 직관 전달용이며, 설계의 무게중심은 'disjoint 제약'과 '고치는 권한은 자기 자신에게 주지 않는다'는 경계에 있다. 슬라이드 버전은 carousel/slides.md.