OpenCairn을 만들기 시작한 이유

OpenCairn을 처음 생각했을 때는 아주 단순했습니다. 제 자료를 잘 찾아주는 RAG를 만들고 싶었습니다.

PDF를 올려두고, 수업 자료나 프로젝트 문서를 넣어두고, 제가 물어보면 알아서 찾아서 답해주는 도구. 처음에는 그 정도면 충분할 것 같았습니다. 이미 세상에는 노트앱도 많고, AI 챗봇도 많고, PDF를 읽어주는 서비스도 많으니까요. 저는 그중에서 제 자료에 더 잘 맞는 것을 만들면 된다고 생각했습니다.

그런데 직접 만들다 보니 생각이 조금씩 바뀌었습니다.

문제는 검색 하나가 아니었습니다

자료를 넣고 검색하는 것 자체는 시작점일 뿐이었습니다. 실제로 제가 필요했던 것은 "답변" 하나가 아니라, 제 지식과 작업 흐름 전체를 믿고 맡길 수 있는 구조였습니다.

예를 들어 PDF 같은 자료는 업로드할 때 분석하면 됩니다. 한번 올라온 파일은 보통 자주 바뀌지 않으니까요. 하지만 노트는 다릅니다. 노트는 계속 바뀝니다. 제가 오늘 정리한 내용이 내일 바뀌고, AI가 제안한 수정이 들어가고, 협업 문서라면 다른 사람이 동시에 고칠 수도 있습니다.

그렇다면 노트는 단순히 "업로드된 파일"처럼 보면 안 됩니다. 살아있는 문서로 봐야 합니다. 본문은 계속 변하고, 검색 인덱스와 임베딩, 요약, 지식 그래프는 그 본문에서 파생된 결과일 뿐입니다.

이 지점에서 OpenCairn의 방향이 조금 더 분명해졌습니다.

OpenCairn은 자료를 한 번 분석하고 끝나는 앱이 아니라, 계속 바뀌는 지식 상태를 따라가야 하는 시스템이어야 합니다.

RAG보다 먼저 권한이 필요했습니다

RAG를 만들다 보면 검색 품질에 먼저 눈이 갑니다. 어떤 chunk를 만들지, embedding model은 무엇을 쓸지, reranker를 붙일지, graph expansion을 할지 같은 것들입니다. 물론 중요합니다.

하지만 실제 제품으로 생각하면 그보다 먼저 확인해야 하는 것이 있었습니다. 바로 권한입니다.

좋은 답변을 만들기 위해 어떤 문서를 찾았는데, 그 문서가 사용자가 볼 수 없는 자료라면 그건 좋은 RAG가 아닙니다. 그냥 보안 사고입니다. 개인 지식 OS든 팀 지식 OS든, AI가 근거로 쓰는 자료는 반드시 사용자가 읽을 수 있는 범위 안에 있어야 합니다.

그래서 OpenCairn에서는 RAG를 "검색"만의 문제가 아니라 "권한을 지키는 근거 수집" 문제로 보고 있습니다.

제가 원한 답변은 이런 것이었습니다.

질문
-> 읽을 수 있는 자료만 검색
-> 근거를 묶어서 답변
-> 어떤 자료를 근거로 썼는지 표시
-> 근거가 부족하면 모른다고 말하기

말로 쓰면 당연해 보이지만, 실제 구현에서는 계속 신경 써야 하는 부분입니다. 검색 경로가 하나만 있는 것도 아니고, chunk 검색, note fallback, graph 확장, provider rerank 같은 경로가 생기면 각 경로에서 권한이 새지 않게 해야 합니다.

모델이 직접 실행하면 안 된다고 느꼈습니다

처음에는 AI가 노트를 바로 고치고, 파일도 만들고, 프로젝트도 알아서 진행하면 멋있을 것 같았습니다. 그런데 조금만 생각해보면 위험합니다.

모델은 그럴듯하게 말할 수 있지만, 실제 제품 상태를 책임지는 주체가 될 수는 없습니다. 노트를 수정할 때는 지금 문서 상태가 최신인지 확인해야 하고, 파일을 만들 때는 어디에 저장되는지 알아야 하고, 외부 서비스로 내보낼 때는 사용자가 정말 승인했는지 확인해야 합니다.

그래서 OpenCairn은 모델이 직접 상태를 바꾸는 구조를 피하려고 합니다.

대신 이런 방향을 잡았습니다.

모델이 제안
-> 서버가 schema 검증
-> 권한과 위험도 확인
-> action 또는 plan step으로 기록
-> 필요하면 사용자 승인
-> worker나 API가 실행
-> 결과와 실패 이유를 남김

이 구조는 화려하지는 않습니다. 하지만 저는 이쪽이 더 제품답다고 생각합니다. AI가 진짜 작업을 하려면, 자유도가 아니라 기록과 경계가 먼저 필요합니다.

에이전트는 마법보다 워크플로우에 가깝습니다

요즘 "에이전트"라는 말을 많이 씁니다. 저도 OpenCairn을 만들면서 이 단어를 계속 생각하게 됩니다. 그런데 제가 만들고 싶은 에이전트는 모든 것을 알아서 해버리는 마법 같은 존재라기보다, 현재 상태를 보고, 근거를 확인하고, 위험한 작업은 승인을 받고, 실패하면 복구 방향을 제안하는 워크플로우에 가깝습니다.

OpenCairn에서 에이전틱 워크플로우는 이런 식으로 가야 한다고 보고 있습니다.

현재 지식 상태 확인
-> 목표를 plan으로 나눔
-> 각 step의 근거와 위험도를 표시
-> 실행 가능한 것은 typed action으로 실행
-> 완료 여부를 검증
-> 실패하면 recovery step을 만듦

이렇게 만들면 사용자 입장에서도 "AI가 뭘 하는지 모르겠다"는 느낌이 줄어듭니다. 지금 어떤 단계가 실행 중인지, 왜 막혔는지, 어떤 자료를 근거로 삼았는지, 무엇을 승인해야 하는지 볼 수 있기 때문입니다.

벤치마크도 필요합니다

솔직히 말하면, 지금은 "구조가 좋다"와 "품질이 좋다"를 구분해야 한다고 생각합니다.

OpenCairn의 RAG 구조는 단순 벡터 검색 하나보다 더 나은 방향을 보고 있습니다. 권한 필터링, 근거 묶기, 그래프 확장, rerank, groundedness 평가 같은 것들이 필요하다고 보고 있습니다. 하지만 이것만으로 "좋은 RAG"라고 말할 수는 없습니다.

좋다고 말하려면 숫자가 있어야 합니다.

제가 앞으로 측정하고 싶은 것은 이런 것들입니다.

RAG
- 정답 근거를 얼마나 잘 찾는가
- citation이 실제 답변을 지지하는가
- 근거 없는 주장을 얼마나 줄이는가
- 권한 없는 자료가 섞이지 않는가

Parser
- PDF 표 구조를 얼마나 잘 보존하는가
- 한국어 텍스트가 깨지지 않는가
- 문서 순서와 제목 구조가 유지되는가

Agentic workflow
- 목표를 실행 가능한 plan으로 잘 나누는가
- 위험한 step을 manual review로 낮추는가
- step이 실제로 성공했는지 검증하는가
- 실패했을 때 복구 방향을 제시하는가

이 벤치마크는 제품을 멋있게 보이게 하려고 만드는 숫자가 아니라, 제가 어디가 약한지 보려고 만드는 숫자에 가깝습니다. 실제로 측정해봐야 어떤 부분이 괜찮고 어떤 부분이 부족한지 알 수 있습니다.

오픈소스로 하는 이유

OpenCairn은 공개 저장소로 가져가려는 방향입니다. 이유는 단순히 "오픈소스가 멋있어서"만은 아닙니다.

제가 만들고 있는 것은 사용자의 자료와 지식을 다루는 도구입니다. 이런 도구는 신뢰가 중요합니다. 어떤 데이터를 저장하는지, AI에게 무엇을 보내는지, 권한을 어떻게 확인하는지, 위험한 작업을 어떻게 막는지 볼 수 있어야 합니다.

물론 오픈소스로 한다고 자동으로 좋은 제품이 되는 것은 아닙니다. 문서도 써야 하고, 보안 경계도 더 신경 써야 하고, 제가 대충 만든 부분도 드러납니다. 그래도 저는 이 방향이 맞다고 생각합니다.

OpenCairn은 제가 혼자 빠르게 만들고 있는 제품이지만, 동시에 제가 어떤 방식으로 AI 제품을 만들고 싶은지 보여주는 실험이기도 합니다.

지금의 결론

처음에는 "내 자료를 잘 찾아주는 RAG"를 만들고 싶었습니다.

지금은 조금 다르게 생각합니다. 제가 만들고 싶은 것은, 제 자료를 읽고 답하는 AI가 아니라, 제 지식 상태를 이해하고, 근거를 남기고, 권한을 지키고, 실행 가능한 작업을 안전하게 이어주는 지식 OS입니다.

아직 부족한 부분이 많습니다. 벤치마크도 더 만들어야 하고, 노트 분석 파이프라인도 더 단단하게 만들어야 하고, 에이전틱 워크플로우도 지금보다 더 검증 가능하게 만들어야 합니다.

그래도 방향은 꽤 분명해졌습니다.

OpenCairn은 AI가 모든 것을 대신하는 제품이 아니라, AI가 실제 지식 작업에 들어오기 위해 필요한 근거, 권한, 승인, 실행 기록을 만드는 제품입니다.