세계를 명제화하다

MON · 월요일 아침 왜 데이터는 더 무거워지기만 할까

엑셀을 열고 처음 한 일은, 데이터가 거기 있다는 사실을 확인하는 일이었다. 공시 6,400건. 영문 뉴스 1만 8천 건. 국문 분석 리포트 920건. 행은 충분했다. 행은 늘 충분했다. 부족한 것은 한 번도 행이 아니었다. 부족한 것은 — 그 행들 사이의 연결을 누가 그릴 것인가였다. 매번 나였다. 매번 손으로.

그래서 먼저 사내 LLM 창을 열었다. 키보드 위에 손가락이 잠시 멈췄다가, 묻기 시작했다. "NVIDIA HBM 밸류체인의 2차·3차 벤더를 알려줘." 매끄러운 답이 돌아왔다. 회사 이름 일곱 개. 그중 둘은 내가 이미 아는 회사였고, 셋은 들어본 회사였고, 둘은 처음 보는 회사였다. 처음 보는 둘에 대해 다시 물었다. "왜 그 두 회사인가?" 두 번째 답은 첫 번째와 미묘하게 달랐다. 한 회사는 사라졌고, 다른 한 회사가 끼어들었다. 세 번째로 물었다. 또 달랐다.

0.1확률적 앵무새의 한계

세 번째 답을 본 순간 알았다. 이 친구는 답을 찾는 게 아니라 합성하고 있다. 본질적으로 보간(interpolation) 기계. 학습 분포 안에 있는 점들 사이에서 평균적인 정답을 매번 새로 만들어내는 일. 결함이 아니라 그게 작동 원리였다. 그러나 내가 찾는 답은 — 어제까지 아무도 연결시키지 않았던 두 회사가 이번 분기 공시 한 줄로 새로운 사슬을 만드는 그런 발견은 — 분포 바깥의 점을 잇는 일이었다. 외삽(extrapolation). 보간 기계가 가장 못하는 일.

2021년 Bender 등이 '확률적 앵무새' 논쟁을 꺼냈을 때 결론은 단순했다 — 모델이 아무리 커져도, 학습되지 않은 명제는 학습되지 않는다. 2026년에도 결론은 그대로다. 답변은 더 매끄러워졌다. 그러나 매끄러움은 새로움이 아니었다. LLM 창을 닫았다. 손이 키보드에서 한 번 떨어졌다가, 다시 책상 한쪽에 놓여 있던 수첩을 끌어왔다.

0.2기억 장치의 패러다임 시프트

문제가 모델 쪽이 아니라는 건 그제야 분명해졌다. 답은 다른 자리에 있었다. 모델 옆에 기억 장치(memory)를 다시 설계하는 일. 정확히는 — 기억 장치를 저장 창고가 아니라 생각의 기관(organ of thought) 으로 재정의하는 일.

수첩의 빈 페이지에 만년필로 네 줄을 적었다. 그동안 우리가 거쳐온 세 세대의 자취, 그리고 한 줄을 마지막에 더 적었다.

• 1세대 — '쌓는다'. 관계형 DB, 데이터 웨어하우스.
• 2세대 — '엮는다'. 그래프 DB, 벡터 DB.
• 3세대 — '연역한다'. 온톨로지·룰 기반 DB.
• 이번 주의 관통 질문 — 데이터가 결합할수록 스스로 똑똑해지는 구조는 어떻게 만들 수 있는가.

수첩을 덮지 않고 그대로 두었다. 자리에서 일어나 커피를 다시 따랐다. 첫째 잔은 미지근해져 있었다. 창밖이 어둑해지고 있었고, 월요일이 끝나가고 있었다. 마지막에 적은 그 한 줄이 — 다음 날 아침의 첫 페이지가 될 것이었다.

TUE · 화요일 세 가지 DB의 사각지대 선을 긋는 것과 맥락을 이해하는 것의 차이

화요일 아침. 책상 위엔 어제 펼쳐 둔 수첩 한 페이지가 그대로 누워 있었고, 그 옆에 200열짜리 엑셀이 다시 열렸다. 어제 적어둔 관통 질문을 다시 한 번 눈으로 따라간 뒤, 결심했다. 시도해 보기 전에는 그릇이 부족하다는 말도 함부로 하면 안 됐다. 우리 회사가 이미 운영하고 있는 도구 세 가지를 차례로 펼치기로 했다. RDB, 벡터 DB, 그래프 DB. 세 번 다 답이 나오지 않으면, 그때 그릇을 바꾸자.

1.1기존 DB의 사각지대

RDB로 먼저 들어갔다. 공급계약 테이블, 회사 테이블, 부품 테이블, 공정 테이블, 시점 테이블. 다섯 테이블을 조인해서 "A가 B에 어드밴스드 패키징 용도로 2026년 2분기 조건으로 공급한 건"을 한 줄로 뽑으려고 했다. 쿼리가 길어졌다. 열일곱 줄. 스무 줄. 서브쿼리가 서브쿼리를 낳았다. 결과가 나오기까지 1분 40초가 걸렸다. 정형 데이터의 왕은 다차원 맥락 앞에서 — 매번 그랬듯이 — 조인 지옥으로 답했다.

벡터 DB로 옮겨갔다. 모든 공시를 이미 임베딩으로 변환해 두었으니, '어드밴스드 패키징과 비슷한 공시'를 찾는 일은 0.3초에 끝났다. 다만 — 한 가지 사실이 거기 있었다. 시스템은 왜 비슷한지를 모른다. 의미는 있되 논리는 없다. 결과를 의사결정자에게 들고 가서 "이 회사가 왜 후보인가요?"라는 질문을 받으면 답할 길이 없다. 검증·역추적 불가. 매끄러움이 그 자리에서 또 한 번 새로움을 대신할 뻔했다.

일반 그래프(Property Graph)가 마지막 카드였다. 점과 선의 자유로움. 어떤 관계든 빠르게 표현할 수 있다는 약속. 그러나 점과 선이 늘어날수록 사슬은 점점 더 엉켰다. 네 점을 묶는 관계를 표현하려면 가짜 노드(reification)를 끼워야 했다. 다섯 점이면 가짜 노드가 둘이었다. 데이터가 쌓일수록 우리가 그린 것은 — 의미 있는 그래프가 아니라 스파게티 그래프였다. 자유로움이 곧 한계였다.

1.2온톨로지의 본질

그날 저녁 책장에서 책을 한 권 꺼냈다. 몇 년 전 RFP 작성 워크숍에서 받았던 책. 펼치지 않은 채 책상 한쪽에 쌓여 있던 것. 표지에 '온톨로지'라는 단어가 박혀 있었다. 첫 장을 펴는 순간 한 단어 앞에서 멈췄다 — '명제화(propositionalization)'. 세계를 참/거짓이 판별 가능한 단위로 분해해 기계에 넘기는 일.

그 단어 앞에서 잠시 멈췄다. 우리가 그동안 해온 일은 데이터를 연결하는 일이었지, 의미를 명제로 분해하는 일이 아니었다. 점과 선은 데이터의 형식이지 의미의 단위가 아니었다. 의미는 — 도메인의 합의를 진리값을 갖는 형태로 적어둘 때 — 그때 비로소 기계로 넘어가는 것이었다.

그러고 보면 우리가 매일 하는 일이 그것이었다. 법령은 명제 모음이고, 회계 기준도 명제 모음이고, 의사가 환자를 진단할 때 쓰는 분류표(ICD-11)도 명제 모음이었다. 반도체 공정 사양도 마찬가지였다. 다른 점은 — 그것들이 기계가 읽을 수 있는 형태로 적혀 있느냐였다. 우리 회사 데이터 어디에도, 그런 명제 집합은 아직 깔려 있지 않았다.

사전이 없어도 외국어 문장을 흉내 낼 수는 있다. 발음도 따라 할 수 있고, 가끔 정확한 문장도 만들 수 있다. 그러나 그것이 무엇을 가리키는지, 어떤 명제가 참인지, 어떤 도메인 규칙을 위반하는지는 알지 못한다. LLM도 같았다. 외부에 명제 모음을 두지 않으면, 답변이 그럴듯하다는 것 외에는 검증할 길이 없었다. 책을 덮었다. 수첩의 그 페이지로 돌아가 한 줄을 더 적었다 — 그릇을 바꿔야 한다. 그리고 그 아래에 내일 보러 갈 후보 셋의 이름을 줄지어 적었다.

WED · 수요일 TypeDB의 해부학 다차원적 세계를 담는 그릇

수요일 아침, 어제 수첩 마지막 줄에 적어둔 세 후보를 다시 폈다 — RDF/OWL 트리플 스토어, Property Graph + 룰엔진, 그리고 TypeDB. 처음 둘은 우리 회사에서도 한 번씩 검토했던 도구였다. 세 번째가 낯설었지만, 어딘가 다른 결을 가지고 있다는 소문이 있었다. 노트북에 docs를 열었다. 그 결의 정체를 직접 만지러 갔다.

2.1하이퍼 관계(Hyper-relation)

첫 차이는 처음 친 코드 한 줄에서 드러났다. 그래프 DB의 선(edge)이 두 점만 잇는 일이라면, TypeDB의 Relation은 — 다차원 맥락 전체를 하나의 독립된 개체로 묶어내는 일이었다. 화요일에 다섯 테이블 + 여섯 조인이 필요했던 그 한 가지 사건. 그게 한 줄로 끝났다.

2.2역할(Role)의 부여

그 다음 차이가 더 결정적이었다. TypeDB의 모든 Relation은 자기 안에 참여자의 역할을 명시했다. 같은 회사가 — 같은 분기에 — 어떤 관계에선 발주자였고, 다른 관계에선 경쟁자였고, 또 다른 관계에선 투자자였다. 점·선의 세계관에서는 이 셋이 모두 똑같은 점에 매달린 똑같은 선으로 보였다. 그래서 우리가 그동안 '같은 회사'라고 부르던 것들이 — 실은 같은 단어이지만 다른 의미였던 것이다.

환각의 절반은 거기서 일어났다는 걸 그제야 알았다. LLM이 '엔비디아'라고 말할 때 그것이 어떤 관계 안에서의 엔비디아인지를 구분하지 못해서. 데이터 모델 차원에서부터 역할이 보존되지 않으면, 위에 올라간 어떤 모델도 그 구분을 복원하지 못했다. 그릇이 못 담는 것은 — 그 위의 어떤 도구도 못 담았다.

2.3강타입 스키마 + 다형성

세 번째는 타입 계층이었다. Company → SemiconductorCompany → FoundryCompany → AdvancedPackagingFoundry 같은 계층. 이게 깔려 있으면, "TSMC가 어드밴스드 패키징 파운드리다"라는 한 명제로부터 자동으로 "TSMC는 회사다", "TSMC는 반도체 회사다", "TSMC는 파운드리다"가 따라왔다. 스키마가 곧 — 도메인 지식의 코드화였다.

수요일 저녁, 책상 등을 끌어당기고 노트에 세 줄을 다시 정리했다. 하이퍼 관계 + 역할 + 강타입. 셋이 따로 작동하지 않았다. 셋이 묶여서 한 가지 일을 했다 — 도메인 합의의 컴퓨터-가독 버전을 만드는 일. 우리 회사 RFP에 그동안 적혀 있던 "지식 그래프를 지원합니다"라는 한 줄이 — 이 순간 갑자기 부족해 보였다. 그게 다차원 관계와 역할과 타입 계층 모두를 의미하는 것인지, 아니면 점·선만 의미하는 것인지는 — 별개의 문제였다.

노트의 그 페이지를 덮기 전, 한 줄을 더 적었다. 그릇은 좋다. 그런데 — 좋은 그릇만으로 정말 답이 따라 나오는가. 내일의 첫 줄이 거기서 시작될 것이었다.

THU · 목요일 함축(Implication)의 마법 스스로 생각하는 데이터베이스

목요일 아침, 평소보다 한 시간 일찍 출근했다. 어제 마지막에 적어둔 그 의심을 안고 — reasoner를 직접 돌려보러 갔다. 다차원 관계가 좋은 그릇이라는 건 알겠다. 그런데 좋은 그릇만으로 정말 답이 따라 나오는가. 답을 도출하는 일은 결국 누군가가 코드를 짜야 하는 것 아닌가. 그 의심에 답을 듣고 싶었다.

3.1탐색에서 추론(Reasoning)으로

먼저 작은 예시 하나를 직접 만들었다. 룰 한 줄을 적었다 — "아빠의 아빠는 할아버지다." 그게 전부였다. 그리고 다른 명제는 적지 않았다. 아빠 관계 몇 개와 — 그 룰 한 줄. 쿼리를 던졌다. "X의 할아버지는 누구인가." 화면에 답이 떴다. 내가 한 번도 적지 않은 명제. 시스템이 스스로 도출한 결론. 어렵지 않은 예시였지만 — 어렵지 않다는 것이 핵심이었다. 룰 한 줄이 사실 N개를 만났을 때 일어나는 일이 그 자리에서 보였다.

TypeDB Rule이라는 게 결국 1차 논리(First-Order Logic)의 표현이었다 — "조건 명제들이 참이면, 결론 명제도 참이다". 그 위에 더한 정교한 트릭은 없었다. 그런데 그 단순한 구조가 — 데이터가 늘어남에 따라 거의 모든 것을 결합해 냈다.

3.2쿼리 패러다임의 변화

개발자 관점에서 이 변화가 얼마나 결정적인지는 — 같은 질문을 두 방식으로 던져보면 바로 보였다.

• Before — 복잡한 경로(multi-hop join, Cypher path)를 손으로 모두 친다. "A 테이블에서 B로 조인하고, B의 외래키로 C를 찾고, C의 속성으로 D를 필터링하고…" 어떻게 찾을지(how)를 매번 명시한다.
• After — 단순한 질문 하나만 던진다. DB가 논리적 징검다리를 스스로 놓아 결론을 도출한다. "무엇이 참인지(what)"만 묻는다.

"무엇"과 "어떻게"의 분리는 SQL이 30년 전에 일부 해낸 일이었다. 그러나 그 분리는 데이터 조회 차원에서만 머물러 있었다. 새로운 사실을 도출하는 일은 여전히 어플리케이션 코드의 몫이었다. TypeDB는 그 분리를 한 단계 더 밀어붙였다 — 지식 도출까지 DB가 책임진다.

3.3추론의 합성성(Compositionality)

그러다 깨달았다. 규칙 위에 규칙을 쌓을 수 있다는 것을. 작은 규칙 하나가 만든 함축이 다음 규칙의 조건으로 들어가고, 그 결론이 또 다음 규칙의 조건이 된다. 직접 손으로 3단 사슬을 한 번 만들어봤다. 작은 규칙 셋이 모이면 사슬 하나가 되고, 사슬 셋이 모이면 — 사람이 한 번도 손으로 그려보지 않은 결론에 도달했다.

실무적으로 풀면 이 한 줄이었다 — 도메인 전문가가 규칙을 한 줄 더하면, 시스템 전체의 지능이 그만큼 깊어진다. 코드를 다시 배포할 필요가 없다. 데이터를 다시 적재할 필요도 없다. 한 줄의 명제가 깔리는 순간, 기존 사실들 위에서 새로운 함축이 자동으로 깨어났다. 월요일에 적은 그 관통 질문에 답이 보이기 시작했다 — "데이터가 결합할수록 스스로 똑똑해지는 구조"의 정확한 모습이었다.

목요일 밤, 책상 등을 끄기 직전에 한 가지를 더 적었다. 비트겐슈타인이 1921년에 논리철학논고 5.122에서 이미 적어둔 것이었다 — "명제 p가 명제 q에서 따라오면, p의 의미는 이미 q의 의미 안에 포함되어 있다." 함축은 새로운 정보가 아니었다. 이미 우리가 적어둔 것 안에 잠겨 있던 것을, reasoner가 끝까지 드러낼 뿐이었다. 100년 전에 정리된 그 문장이, 목요일 밤 내 화면 안에서 다시 발견되고 있었다.

노트를 덮으며 한 줄을 더 적었다. 내일은 — 이 마법을 우리 데이터 위에서 한 번 부려볼 차례다. 책상 위엔 한 주 내내 펼쳐져 있던 공시 6,400건이, 마침내 쓰일 자리를 기다리고 있었다.

FRI · 금요일 숨은 연결고리의 등장 [실전 적용] 반도체 밸류체인의 해체

금요일이었다. 약속한 한 주의 마지막 날. 책상 위엔 공시 6,400건이 그대로 펼쳐져 있었고, 어드밴스드 패키징 사양서와 장비사 매핑표, 부품 분류표가 그 옆에 함께 깔려 있었다. 한 주 동안 만진 모든 것이 이 자리에 모여 있었다 — 월요일의 LLM, 화요일의 좌절, 수요일의 그릇, 목요일의 마법. 남은 것은 그것을 우리 도메인에 한 번 적용해 보는 일이었다.

4.1다차원 계약의 명제화

공시 한 줄을 골랐다. "당사는 ㈜A로부터 어드밴스드 패키징용 신규 장비를 2026년 2분기 납품 조건으로 수주하였습니다." 단순 명제로 적으면 "A가 B에 납품한다" 한 줄이 끝이었다. 정보의 90%가 거기서 누락됐다. 다차원 명제로 다시 적었다 —

4.2숨은 수혜주(α)의 창발

그리고 이제 — 도메인 전문가가 깔아두는 규칙 한 줄. 우리 팀이 그동안 회의실에서 입으로만 하던 그 한 줄. 그 한 줄을 처음으로 코드로 적었다 —

"특정 공정의 병목을 해결하는 기술을 가진 기업은, 해당 밸류체인에 편입된다."

Enter를 눌렀다. reasoner가 돌기 시작했다. 화면이 잠시 비었다가 — 결과가 펼쳐졌다. AI 가속기 시장의 2차·3차 벤더가 한 줄씩 나타났다. HBM → CoWoS → TGV → 글래스 기판 → 레이저 드릴 장비사 → 광학 정렬 부품사 → … 인간 애널리스트(즉, 내가) 일주일에 걸쳐 손으로 매핑하던 작업을 — 시스템이 한 번의 쿼리로 연역했다.

숨이 잠깐 멎었다. 결과 중 하나는 — 내가 처음 보는 회사였다. 광학 정렬 부품을 만드는 한 중견기업. 공시에는 NVIDIA의 이름이 단 한 번도 등장하지 않았다. 그러나 시스템은 — 그 회사가 만든 부품이 특정 패키징 공정의 병목을 해결한다는 명제와, 그 공정이 HBM 어드밴스드 패키징의 핵심 단계라는 명제를 결합해서 — 그 회사를 NVIDIA 밸류체인의 일원으로 자동으로 끌어다 놓았다.

이게 핵심이었다. 결과의 양이 핵심이 아니었다. 결과의 역추적 가능성(traceability)이 핵심이었다. 시스템이 "X사는 NVIDIA 밸류체인 멤버다"라고 결론을 내면, 어떤 명제들과 어떤 규칙들이 그 결론을 함축했는지 — 단계별로 거꾸로 따라갈 수 있었다. 결론만 받는 게 아니라, 결론과 함께 그 결론의 증명 사슬을 받는다는 의미였다. 의자에 등을 한 번 기댔다가 다시 화면 쪽으로 끌어당겼다.

4.3비즈니스 임팩트

한 가지 차이가 — 그저 한 가지 아키텍처 선택의 차이가 — 우리 팀의 일하는 방식 전체를 바꿀 수 있겠다는 게 그제야 보였다. 노트 새 페이지에 두 줄을 마주 적었다.

DART Insight 관점에서 다시 적으면 한 줄이었다 — 공시는 명제의 원천 소스다. TypeDB는 그 명제들의 의미를 연역하는 엔진이다. 둘 사이에 LLM이 명제 추출자로 서고, 그 위에 에이전트가 액션 실행자로 선다. 그 그림이 머릿속에서 처음으로 깨끗하게 그려졌다. 다음 주 월요일 회의에 들고 갈 슬라이드 — 이미 보였다. 노트북을 덮고 의자를 밀었다. 주말이 시작되고 있었다.

MON · 다음 주 월요일 뉴로-심볼릭의 실무적 완성 분업의 정확한 경계

다음 주 월요일 회의실. 어깨에 짊어진 가방 안에는 한 주의 노트가 그대로 들어 있었다. CTO와 운영팀장, AI팀장, RFP 작성팀이 한자리에 모였다. 첫 슬라이드를 띄웠다. 모두가 묻고 있던 같은 질문 — "그래서 LLM과 TypeDB는 어떻게 같이 가는 거야?" 답은 단순했다. 둘은 경쟁 관계가 아니었다. 분업 관계였다.

5.1LLM과 TypeDB의 완벽한 분업

역할 분담을 한 그림에 담았다 — 세 손이 함께 일하는 그림.

분업의 핵심은 한 줄이었다 — 각자가 가장 잘하는 일만 시킨다. LLM에게 논리적 일관성을 기대하지 않는다. TypeDB에게 비정형 텍스트 이해를 기대하지 않는다. 에이전트에게 진리값 판단을 기대하지 않는다. 각자의 강점이 다른 자리의 약점을 메운다. CTO가 고개를 끄덕였다. 처음으로.

5.2에이전틱 워크플로우

그리고 실제 파이프라인. 우리가 다음 분기 안에 깔아야 할 다섯 단계 —

1. 수집 — LLM이 원문(뉴스, 공시, 보고서)을 읽어 Entity-Relation-Role 형태의 명제 후보로 변환. 출력은 아직 진리값을 갖지 않는 후보.
2. 검증 — 스키마 정합성 검사 + 신뢰도 점수 필터링. 도메인 타입을 위반하는 명제, 임계 신뢰도 아래의 명제는 여기서 잘려나간다.
3. 적재 — 통과한 명제를 TypeDB에 하이퍼 관계로 저장. 이 순간부터 명제는 시스템의 진리 집합에 속한다.
4. 추론 — 룰이 자동 발화. 새 명제 하나가 들어오면, 그 명제와 결합 가능한 모든 규칙이 자동으로 평가되고, 함축된 사실이 생성된다.
5. 회신 — LLM이 함축 결과를 자연어 인사이트로 재포장. 의사결정자는 자연어 결과 + 그 결과의 증명 사슬을 함께 받는다.

5.3환각(Hallucination) 제어 메커니즘

AI팀장이 질문했다. "환각은 어떻게 잡혀요?" 좋은 질문이었다. 한 주 동안 내가 마지막에 도달한 자리도 그 질문이었다. 환각의 정체를 다시 정의해야 답이 나왔다 — 환각은 진리값 검증 없이 흘러나온 자연어 출력이었다. 매끄러움과 진리는 별개라는 사실을, 시스템 차원에서 한 번 분리해야 잡히는 것이었다.

• LLM 단독 응답 — 사실 여부 검증 불가. 그럴듯함과 참됨이 분리되지 않는다.
• TypeDB 경유 응답 — 모든 결론이 입력 명제 + 규칙으로 역추적 가능(Explainable). 답변과 함께 증명 사슬이 흘러나온다.

즉, 뉴로-심볼릭은 LLM의 환각을 잡는 가장 자연스러운 안전장치였다. 별도의 fact-checking 레이어를 따로 깔지 않는다. 답변 생성 경로 자체가 검증된 명제 위에서만 흐르도록 설계할 뿐이다. RFP 작성팀의 눈이 잠시 빛났다 — "환각 방지 기능이 있습니다"는 마케팅 카피로 빠지지만, "모든 결론이 명제와 규칙으로 역추적됩니다"는 검증 가능한 아키텍처 요건이 되는 거였다. 우리 RFP 문구 한 줄이 그 자리에서 바뀌었다.

SAT · 그 다음 주말 진정한 지식 엔진의 미래

토요일 아침, 다시 책상 앞에 앉았다. 한 주의 노트가 펼쳐져 있었고, 첫 페이지엔 월요일의 그 관통 질문이, 마지막 페이지엔 금요일 오후의 두 줄이 적혀 있었다. 그 사이에 — 한 사람의 일주일이 들어 있었다.

폴더 위에 명제가 깔리고, 명제 위에 규칙이 깔리고, 그 위에 함축이 자라는 구조 — 그게 다음 단계의 '기억 장치'였다. 살아 있는 명제 집합. Living Knowledge Graph. 그리고 그 코드화의 품질은 — 안타깝게도, 모델 가중치처럼 외부에서 사 올 수 없는 것이었다. 우리 같은 사람이 한 줄 한 줄 적어 내려가야 하는 일.

장자(莊子)의 통발(筌)을 넘어

得魚而忘筌 — 물고기를 잡으면 통발을 잊는다.

명제는 통발이었다. 좋은 통발은 자기 존재를 드러내지 않고 의미만 건져 올린다. 잘 깔린 시스템은 사용자에게 보이지 않을 것이다 — 그러나 그 답의 정확도는, 뒤에 깔린 명제 구조의 품질에 정직하게 비례할 것이었다.

그러나 한 가지 인정은 남았다. 인간의 암묵지(tacit knowledge)는 여전히 명제로 환원되지 않는 영역에 살아 있었다. 의사가 환자를 마주한 첫 3초의 직관, 도메인 전문가가 한 줄의 공시에서 읽어내는 의미의 결 — 그런 것들은 명제로 옮겨지는 순간 잃어버리는 무엇인가를 안고 있었다.

그래서 노트의 마지막 페이지에 — 답이 아니라 남은 과제를 적었다. 형식화 가능한 지식과 형식화될 수 없는 직관 사이의 경계를 어디까지 밀어붙일 것인가. 한 줄을 더 옮길 때마다 시스템은 그만큼 똑똑해진다. 그러나 한 줄을 옮기는 일은 자동화되지 않는다. 누군가는 사전을 한 단어씩 적어 내려가야 한다 — 그게 다음 라운드의 진짜 질문이었다.

노트를 덮었다. 토요일 아침의 햇빛이 책상 위에 길게 누워 있었다. 이번엔 무엇을 명제로 옮길 차례인지 — 이미 머릿속에 한 줄이 떠올라 있었다.