문서를 개념 그래프로 다룬다면, 정합성 검사는 어떻게 달라질까
2026년 3월 24일 AI Native Builders 세션의 네 번째 발표는 다소 큰 그림의 제안이었습니다. 문서를 더 잘 검색하는 수준이 아니라, 문서 자체를 보는 관점을 바꿔보자는 이야기였습니다. 핵심 아이디어는 이렇습니다. 문서는 단순한 파일 묶음이 아니라, 단어와 개념이 서로 연결된 네트워크로 다룰 수 있다는 것입니다.
이 관점이 흥미로운 이유는, 우리가 실제로 겪는 문제도 파일 단위보다 개념 단위에서 자주 생기기 때문입니다. 제품 문서, 디자인 문서, 코드, 운영 문서가 각각 따로 존재해도, 그 안에서 말하는 개념은 사실 연결돼 있습니다. 그런데 지금은 그 연결이 사람 머릿속에만 남아 있는 경우가 많습니다. 그래서 한 문서가 바뀌어도, 관련된 다른 문서나 코드가 같이 점검되지 않습니다.
문서 변경이 관련 문서와 코드까지 흔들 수 있어야 한다
발표자가 제안한 시스템은 이런 문제를 정면으로 다룹니다. 어떤 문서가 바뀌면 그 문서만 업데이트된 것으로 끝나는 게 아니라, 연결된 다른 문서와 코드까지 충돌 여부를 확인하는 흐름입니다. 핵심은 변화가 생겼을 때 관련된 의미 관계를 함께 점검할 수 있어야 한다는 문제의식이었습니다.
예를 들면 이런 질문이 가능해집니다.
- 이 정의는 현재 코드의 동작과 충돌하지 않는가
- 이 문서는 관련된 다른 문서보다 설명이 부족하지 않은가
- 기획 문서에서 바뀐 용어가 디자인 문서와 운영 문서에도 반영됐는가
여기서 LLM은 최종 판정자가 아니라 1차 점검자 역할을 맡습니다. 이 부분은 설명이 더 필요해 보인다거나, 이 정의는 코드와 충돌할 수 있다는 식의 첫 번째 체크를 맡기는 것입니다. 이 구조가 현실적인 이유는, 완벽한 자동 판정보다 먼저 불일치 가능성을 빠르게 드러내는 데 목적을 두기 때문입니다.
핵심은 개념을 노드와 관계로 뽑아내는 일이다
이 시스템이 성립하려면 결국 문서 안의 핵심 개념을 노드로 만들고, 그 관계를 엣지로 연결해야 합니다. 제품 개념, 정책 정의, 상태 전이, 역할, 책임, 입력과 출력 같은 것들이 그래프 안에서 연결되는 셈입니다.
말로 하면 매력적이지만, 발표에서도 구현 난제가 분명히 언급됐습니다. 좋은 노드와 엣지를 어떻게 만들 것인가, 너무 추상적이거나 품질 낮은 개념 모델링을 어떻게 피할 것인가가 가장 어려운 부분입니다. 개념을 지나치게 크게 잡으면 실제 점검에 도움이 안 되고, 너무 잘게 쪼개면 유지 비용이 커집니다. 결국 그래프의 품질이 시스템의 품질을 좌우하게 됩니다.
이 한계 인식이 오히려 좋았습니다. 문서를 그래프로 연결하면 다 해결된다는 식이 아니라, 어디서부터 어려워지는지까지 같이 이야기했기 때문입니다.
적용 가능성은 생각보다 넓다
발표에서는 이 아이디어의 활용 가능성도 여러 방향으로 언급됐습니다. 대표적으로는 다음 같은 영역입니다.
- 금융 문서처럼 정의와 기준의 일관성이 중요한 경우
- 법률, 규제 변경처럼 관련 문서 전파가 중요한 경우
- 기획, 디자인, 개발 사이의 의미 충돌을 줄이고 싶은 경우
공통점은 하나입니다. 문서가 많아서 힘든 게 아니라, 서로 연결된 문서들이 따로 놀아서 힘든 환경이라는 점입니다. 이런 상황에서는 파일 검색이나 키워드 매칭보다, 무엇이 무엇과 연결돼 있는가를 다루는 방식이 더 유효할 수 있습니다.
왜 이 아이디어가 인상적이었나
이 발표가 인상적이었던 이유는 분명합니다. 많은 팀이 이미 문서 불일치 문제를 겪고 있지만, 그 문제를 단순한 문서화 부족이 아니라 의미 구조의 부재로 본다는 점이 새로웠기 때문입니다.
보통은 문서를 더 열심히 쓰자고 말합니다. 하지만 이 발표는 그 다음 질문을 던집니다. 열심히 쓴 문서들이 서로 어떤 관계를 맺고 있는지까지 관리하지 않으면, 불일치는 계속 생기지 않겠느냐는 것입니다. 이 문제의식은 product, design, engineering, operations가 모두 얽힌 조직일수록 더 크게 다가옵니다.
지금 당장 구현하지 않더라도 가져갈 질문
당장 완성형 시스템을 만들기는 쉽지 않아 보입니다. 좋은 ontology를 만드는 일 자체가 어렵고, 의미 그래프를 신뢰할 수 있는 수준으로 유지하는 것도 만만치 않습니다. 그래도 이번 발표가 던진 질문은 실무적으로 유효합니다.
- 우리 문서들은 서로 어떤 개념을 공유하고 있는가
- 정의가 바뀌었을 때 어디까지 영향을 받아야 하는가
- 코드와 문서의 충돌을 누가, 언제 발견하고 있는가
- 설명이 부족한 문서를 AI가 1차로 걸러낼 수 있는가
이 질문들은 거대한 지식 그래프를 당장 만들지 않더라도, 팀의 문서 운영 방식을 다시 보게 만듭니다. 문서를 파일 단위로만 관리할지, 아니면 의미와 관계 단위로도 다뤄볼지. 이번 발표는 그 경계선을 꽤 선명하게 보여줬습니다.