새 기능 하나에도 기획 문서의 요구사항, 코드의 구현, 화면의 디자인이 함께 필요합니다. Consilience는 지식그래프를 바탕으로 코딩·디자인·질의를 수행하는 범용 AI 에이전트입니다. 자료에서 근거를 찾아 답하고, 관련 코드를 수정하며, 화면 시안과 발표 자료를 만드는 작업을 한 공간에서 이어갈 수 있습니다. 지식그래프는 에이전트가 작업에 필요한 맥락을 찾는 데 쓰입니다.
그 기반이 되는 온톨로지는 문서 속 개념과 관계를 정리한 구조입니다. 문서 기반 온톨로지를 구축하고 관리하는 데 파견 엔지니어(FDE)가 상주하지 않아도 되도록 문서 가져오기, 개념과 관계 추출, 변경 반영, 중복 정리를 연결했습니다. 에이전트에게 이 과정을 요청할 수 있고, 사용자는 원문과 변경안을 살펴보며 개념의 의미를 바꾸는 제안을 승인합니다.
2025년 11월 혼자 개발을 시작해 지식 엔진과 에이전트 런타임부터 편집기, 디자인 캔버스, 앱 배포와 구독 과금까지 직접 만들었습니다. 핵심 과제는 에이전트가 필요한 지식을 찾아 실제 작업에 활용하게 하는 것이었습니다.
파일을 모아 두는 것만으로는 부족했습니다
문서 폴더를 AI에게 열어 주면 파일을 읽을 수는 있습니다. 하지만 “클레임을 가장 많이 제기한 고객은 누구인가?”라는 질문은 파일 하나를 찾는 일과 다릅니다. 클레임 기록을 모으고, 같은 고객을 묶고, 건수를 센 뒤 고객 정보와 연결해야 합니다. 필요한 자료를 모두 갖고 있어도, 그 사이의 관계는 질문을 받을 때마다 다시 만들어야 합니다.
그래서 문서 자체와 문서에서 찾은 관계를 분리했습니다. 사람이 읽고 고치는 원본은 평범한 Markdown 파일로 남겨 두고, 그 안에서 추출한 사실은 별도의 관계 색인에 쌓았습니다. 고객과 클레임이 어떤 관계인지 명시적으로 저장하면, 다음 질문에서는 관계를 따라가거나 묶어서 집계할 수 있습니다. 이 색인이 RDF 지식그래프이고, 조인과 집계에 사용하는 질의 언어가 SPARQL입니다.
이 선택에는 소유권도 걸려 있었습니다. 사용자의 글이 앱 안에서만 읽을 수 있는 독점 형식이 되어서는 안 됐습니다. Markdown을 중심에 둔 덕분에 사람과 에이전트가 같은 기록을 읽고 수정할 수 있고, 파생한 그래프도 원문과 대조할 수 있습니다. 다만 추출에는 LLM이 참여하므로, 같은 문서에서 항상 똑같은 관계가 나온다는 뜻은 아닙니다.
정답은 있었는데, 검색이 놓쳤습니다
그래프를 만들고 나면 검색이 자연스럽게 좋아질 것 같았습니다. 실제로는 표와 카탈로그처럼 이름이 비슷한 항목이 많은 자료에서 문제가 드러났습니다. 정답에 필요한 사실은 이미 추출돼 있는데, 의미 검색이 닮은 항목들을 상위에 몰아넣어 정작 필요한 항목을 밀어냈습니다. 자료가 없는 문제가 아니라, 있는 자료를 꺼내지 못하는 문제였습니다.
처음에는 유사도에 고정 기준을 두어 닮은 항목의 쏠림을 막으려 했습니다. 그러나 표에서 잘 듣는 기준은 산문에서 필요한 검색까지 막았습니다. 각 자료가 놓인 의미 공간의 밀도가 달랐기 때문입니다. 이 현상을 고차원 검색의 허브니스 연구와 연결했고, 번역 연구에서 사용한 CSLS 보정을 검색의 출발점을 고르는 단계에 적용했습니다. 질문과 얼마나 가까운지만 보지 않고, 주변의 다른 항목과도 두루 비슷한지를 함께 반영하는 방식입니다.
초기 실험에서는 상위 검색 결과에서 정답을 찾는 지표인 recall@10이 77.5에서 97.0으로 올랐습니다. 여기서 끝내지 않고 검색 대상을 10만 라벨까지 늘리자 다른 문제가 나왔습니다. 앞쪽 결과는 좋아졌지만, 더 넓은 범위를 보는 recall@40은 나빠졌습니다. 찾으려는 정답 자체가 비슷한 항목들 사이에 있으면 보정이 그 정답까지 밀어내고 있었습니다.
보정 전 가장 가까웠던 후보 하나는 검색에서 살아남도록 바꿨습니다. 손실은 줄었지만, 3만·6만 라벨 조건에는 정답 회수율이 기존 방식보다 여전히 4.9%p 낮았습니다. 이 결과도 함께 공개했습니다. 작은 실험에서 얻은 개선을 전체 검색 품질의 보증으로 쓸 수는 없었기 때문입니다. 검색 보정과 규모 실험에 채택한 방법과 남은 한계를 기록했습니다.
기억을 쌓으려면, 잘못 기억한 것을 고칠 수 있어야 합니다
연결이 많아질수록 잘못된 연결의 영향도 커졌습니다. 서로 다른 회사의 문서에 등장하는 “the Company”를 같은 이름으로 취급하면 별개의 회사가 하나로 묶일 수 있습니다. 반대로 기준을 지나치게 엄격하게 하면 같은 회사를 가리키는 한글 이름과 영문 이름이 갈라집니다. 연결을 더 많이 만드는 것과 정확하게 만드는 것은 다른 문제였습니다.
이 때문에 엔티티를 한 덩어리로 덮어 합치는 대신, 되돌릴 수 있는 연결을 별도로 저장했습니다. 사용자가 “둘은 다르다”고 판단하면 그 결정을 보존하고 자동으로 다시 묶이지 않게 했습니다. 문서에서 추출한 내용과 기계가 추론한 내용도 저장 공간을 분리했습니다. 어떤 문서에서 나온 관계인지 추적하고, 잘못된 추론은 원문을 훼손하지 않고 철회할 수 있게 하기 위해서입니다.
지식그래프를 제품으로 만드는 데에는 검색 알고리즘만큼 이런 수정 경로가 필요했습니다. 새 문서가 들어올 때뿐 아니라 문서가 고쳐지고, 삭제되고, 과거 결정이 바뀔 때에도 기억이 함께 갱신돼야 합니다. 이 생명주기를 검색과 에이전트의 작업까지 연결한 구조를 EngramRAG라고 부릅니다.
표 하나를 잘못 읽으면, 그 뒤의 추론도 틀립니다
문서 입력도 단순한 부가기능으로 둘 수 없었습니다. PDF에서 표를 평문으로 펼치면 어느 값이 어느 항목에 속하는지 사라질 수 있습니다. 실제 변환 기록에는 비교표의 체크 표시가 누락된 사례도 있습니다. 이런 내용을 그대로 그래프에 넣으면, 검색을 아무리 잘해도 잘못 읽은 사실을 자신 있게 돌려주게 됩니다.
그래서 파일 형식에 맞는 변환기를 만들고 표의 병합 셀, 제목, 차트 데이터를 보존하도록 했습니다. 구조를 직접 읽을 수 있는 문서는 파서로 변환하고, 스캔이나 복잡한 시각 자료는 비전 모델로 읽습니다. 요약문을 원본 대신 저장하지 않으며, 감지한 변환 실패와 잘림은 경고로 알리고 원본도 함께 보존했습니다. 22종 파일 형식을 받는 입력 기능은 이런 식으로 검색의 앞단까지 확장됐습니다.
별도의 문서 파싱 평가에서는 DP-Bench 공개 200문서의 단일 고정 실행에서 TEDS 96.34, TEDS-S 98.41을 기록했습니다. 이는 표의 내용과 구조를 평가한 후보 결과이며, 공식 등재 검토 중인 상태입니다. 문서 파싱 평가 기록에 조건을 남겼습니다.
찾아낸 맥락으로 실제 일을 이어가게 했습니다
문서에서 찾아낸 지식을 실제 작업으로 이어 붙였습니다. 질문에 답할 때는 지식그래프의 관계를 조회하거나 집계하고, 코딩할 때는 함수의 정의와 호출 관계를 따라 필요한 구현을 찾습니다. 코드의 구조는 tree-sitter로 추출하며, 에이전트가 파일을 수정하고 터미널에서 빌드와 테스트를 실행할 수 있도록 연결했습니다.
디자인도 같은 에이전트가 맡습니다. HTML/CSS로 화면 시안이나 발표 자료를 만들면 캔버스에 렌더링되고, 사용자는 바꾸고 싶은 요소를 골라 수정을 요청할 수 있습니다. 에이전트도 렌더링된 이미지를 다시 받아 결과를 확인합니다. 사람과 에이전트가 화면을 함께 살펴보며 수정을 이어갈 수 있도록 한 것입니다.
구조가 정말 도움이 되는지는 모델을 고정해 비교했습니다. 같은 모델·과제·에이전트에서 코드 그래프를 추가하자 위치 탐색 성공이 14/21에서 18/21로 바뀌었습니다. 별도의 SWE-bench Verified 전수 실행에서는 모델과 전체 실행 시스템을 합쳐 500개 중 394개, 78.80%를 해결했습니다. 전자는 구조의 기여를 보는 비교이고, 후자는 통합 시스템의 결과입니다. 후자의 점수를 그래프 하나의 효과로 설명하지 않습니다.
문서와 코드 검색은 같은 에이전트가 사용할 수 있지만, 두 그래프가 하나의 저장소로 완전히 통합된 것은 아닙니다. 과거 문서의 결정에서 현재 구현까지 한 번에 연결하는 검색은 별도 평가가 필요한 과제로 남겨 두었습니다. 어디까지 만들었고 무엇을 더 검증해야 하는지는 EngramRAG 연구 기록에서 구분했습니다.
실험을 매일 쓸 수 있는 앱으로 옮기는 일
검색이 잘되는 데모와 계속 사용할 수 있는 제품 사이에는 또 다른 작업이 있었습니다. 관계를 눈으로 살펴볼 수 있도록 3D 그래프를 만들었고, 큰 그래프를 다루기 위해 WebGPU 물리 엔진을 직접 작성했습니다. 50만 노드에서 기록한 물리 연산 시간은 틱당 18.3ms입니다. 이는 해당 물리 연산의 측정값이며, 앱 전체가 그 속도로 모든 작업을 처리한다는 의미는 아닙니다.
앱은 서명된 macOS·Windows 릴리스와 자동 업데이트로 배포하며, 웹에서도 사용할 수 있습니다. 7개 언어 UI, 실시간 공동 편집, 관리자 대시보드와 4단계 구독 과금까지 연결했습니다.
처음의 질문은 “AI에게 왜 같은 배경을 계속 설명해야 할까?”였습니다. 개발을 이어가면서 그 질문은 더 구체적이 됐습니다. 자료에서 필요한 사실을 빠뜨리지 않고 읽을 수 있는가. 연결을 따라 근거를 찾을 수 있는가. 잘못 연결했을 때 사람이 바로잡을 수 있는가. Consilience는 이 조건들을 하나의 작업 공간 안에서 이어 붙여 온 프로젝트입니다.
