Rowboat로 업무를 지식 그래프화: 로컬 AI 동료의 등장
Rowboat는 이메일·회의 노트처럼 흩어진 업무 데이터를 PC 안에서 “지식 그래프(knowledge graph)”로 차곡차곡 쌓고, 그 맥락을 꺼내 문서·메일·브리핑을 만들어주는 오픈소스 AI 동료입니다1. 한 번 물어보고 끝나는 검색형 AI가 아니라, 시간이 지날수록 “기억이 자산처럼 불어나는” 장기 기억을 노리는 점이 핵심이에요. 이 글에서는 Rowboat가 왜 주목받는지, RAG 중심 업무 AI와 무엇이 다른지, 실제로 어디에 써먹을 수 있는지, 그리고 도입할 때 반드시 챙겨야 할 운영 포인트까지 한 번에 정리해보겠습니다.
Rowboat란? 로컬 퍼스트 지식 그래프 AI 동료
업무하다 보면 이런 장면이 반복됩니다. “지난달에 그거 누구랑 합의했지?” “왜 그 결정을 했더라?” “새로 합류한 사람에게 이 프로젝트 히스토리를 어디서부터 설명하지?”
Rowboat는 이 ‘설명 재시작 비용’을 줄이려는 도구예요1. Gmail, 회의 노트 도구(예: Granola, Fireflies)에서 들어오는 정보들을 구조화해 저장하고, 사람·프로젝트·결정·액션 아이템의 관계를 지식 그래프로 묶습니다. 그리고 그 관계를 바탕으로 다음 분기 로드맵 덱, 회의 브리프, 메일 초안 같은 결과물을 생성합니다1.
재미있는 건 저장 방식입니다. Rowboat의 기억은 특정 벤더 DB가 아니라, 사용자가 열어볼 수 있는 Markdown 파일로 남고(Obsidian vault와 호환), 링크로 관계를 표현해 “검은 상자”가 아니라 “열어볼 수 있는 기억”을 지향합니다1. 결국 “AI가 기억한다”가 아니라 “내가 소유한 기억을 AI가 활용한다” 쪽에 가깝습니다.
RAG 업무 AI의 ‘처음부터 설명’ 문제, 왜 계속 생길까?
요즘 많은 업무용 AI는 RAG(Retrieval-Augmented Generation), 즉 “LLM + 검색” 방식으로 움직입니다. 질문이 들어오면 관련 문서를 찾아 프롬프트에 붙이고 답을 만들죠2. 이 방식은 최신 문서 반영에 강하고, 학습을 다시 하지 않아도 된다는 장점이 큽니다2.
하지만 업무 현장에서 자주 터지는 문제도 선명해요. 문서 조각(텍스트 청크)은 찾아오는데, “그 결정이 어떤 전제에서 나왔는지”, “A와 B가 어떤 관계인지”, “이메일 스레드에서 최종 합의가 무엇인지” 같은 연결 정보는 AI가 매번 재조립해야 합니다. 전통적인 RAG가 관계를 기본 단위로 다루지 않기 때문이죠3.
그래서 사용자는 다시 길게 설명합니다. 프로젝트 배경, 담당자 관계, 지난 의사결정, 현재 리스크… 그리고 일주일 뒤 같은 질문을 또 합니다. Rowboat가 노리는 건 바로 이 지점입니다. 검색으로 문맥을 “매번 복원”하는 대신, 관계 자체를 기억으로 “누적”해 문맥 비용을 낮추는 것1. 즉, 일을 오래 할수록 AI가 더 ‘내 팀 사람’처럼 굴도록 설계된 셈입니다.
지식 그래프(knowledge graph)로 ‘관계’가 저장되면 달라지는 것
지식 그래프는 사람, 회사, 프로젝트 같은 엔티티(노드)와 그 사이의 관계(엣지)를 그래프 형태로 저장하는 지식 표현 방식입니다4. 문서 묶음이 아니라 “관계의 지도”가 생긴다고 생각하면 이해가 빨라요.
예를 들어 “이번 분기 목표” 문서가 있고 “회의록”이 있고 “메일”이 있다면, 텍스트 검색은 각 문서에서 관련 구절을 찾는 데 강합니다. 반면 지식 그래프는 “누가 결정했는지”, “어떤 회의에서 합의했는지”, “미결 이슈의 오너가 누구인지” 같은 연결 고리를 기본 단위로 삼을 수 있어요4. 그래서 질문이 복잡해질수록(여러 문서를 가로질러 ‘사실의 연결’을 요구할수록) 그래프 기반 접근이 유리해집니다3.
Rowboat의 방향성은 여기서 한 발 더 나갑니다. 그래프를 ‘조회’하는 데서 끝나는 게 아니라, 그 그래프를 바탕으로 문서 생성과 자동화까지 이어 붙입니다1. 즉 “기억(그래프) + 실행(에이전트)” 조합으로 업무 루틴을 굴리려는 거죠.
Rowboat 주요 기능: 이메일·회의 노트가 ‘업무 브리프’로 변하는 과정
Rowboat가 보여주는 대표 장면은 회의 직전입니다. 특정 인물과 미팅이 잡히면, 과거에 어떤 결정을 했고 무엇이 미결인지, 관련 메일 스레드가 무엇인지가 한 장짜리 브리프로 정리되어 나온다는 그림이죠1. 회의가 길어질수록 “아 맞다 그때…”를 되살리는 시간이 줄어듭니다.
자료 생성도 흥미롭습니다. “다음 분기 로드맵 덱 만들어줘”라고 하면, 그래프에 축적된 프로젝트 맥락을 반영해 PDF 슬라이드를 만드는 흐름을 지원합니다1. 단순 요약이 아니라, 과거 결정과 약속의 연속선 위에서 ‘일관된 문서’를 만들 수 있다는 게 포인트예요.
또 하나는 그래프의 가시화·편집입니다. 보통 AI 메모리는 사람이 손대기 어렵거나(심지어 존재를 확인하기도 어렵거나) 수정하면 무슨 일이 벌어질지 무섭습니다. Rowboat는 Markdown 기반으로 열람과 수정이 가능하다는 점을 전면에 둡니다1. 자동 추출이 실수했을 때 “기억을 고칠 수 있는가?”가 장기 운영에서 정말 중요하거든요.
백그라운드 에이전트와 MCP: 자동화는 ‘통제 가능’해야 한다
Rowboat는 백그라운드 에이전트를 통해 반복 작업을 자동 수행하는 방향을 강조합니다. 예를 들어 과거 맥락을 반영한 메일 초안 생성, 아침 우선순위·일정 요약 음성 노트, 정기 프로젝트 업데이트 작성, 새 정보 유입 시 그래프 갱신 같은 작업이죠1.
여기서 중요한 건 “자동화가 된다”가 아니라 “무엇이 언제 실행되고, 어떤 내용이 vault(Markdown 저장소)에 기록되는지 사용자가 통제한다”는 철학입니다1. 회사 입장에서는 감사 가능성, 개인 입장에서는 내 데이터 주권과 직결되는 문제니까요.
확장성도 눈여겨볼 만합니다. Rowboat는 MCP(Model Context Protocol)로 외부 도구와 연결해 컨텍스트를 넓히는 방향을 제시합니다(검색, DB, Slack, Jira/Linear, GitHub 등)1. 지식 그래프가 “노트 앱”에서 끝나지 않고 “업무 시스템 전체의 관계 지도”로 커질 가능성을 보여주는 대목입니다.
도입 전 꼭 알아야 할 한계: ‘그래프 오염’이 가장 무섭다
장기 기억형 AI의 최대 리스크는 단순합니다. 한 번 잘못 기억하면, 그 다음부터는 틀린 기억을 근거로 더 그럴듯한 결과물을 생산한다는 것. 특히 이메일·회의 노트에서 “무엇을 사실/결정으로 확정해 기록할지”가 품질을 좌우합니다1.
그래서 도입 초기에 운영 설계를 같이 해야 합니다. 예를 들어 결정/가정/미결 이슈를 문장 표기 규칙으로 구분하고, 에이전트가 write-back(그래프에 기록)하기 전에 검토 단계를 두고, 사람/프로젝트 단위로 vault 구조를 설계하는 식이죠1. AI가 똑똑해질수록 “데이터 정리”가 덜 중요해지는 게 아니라, 오히려 “기억의 품질 관리”가 더 중요해집니다.
시사점을 한 줄로 정리하면 이렇습니다. Rowboat가 흥미로운 이유는 지식 그래프 자체가 아니라, 업무 데이터를 로컬에 두고(Markdown으로 소유하고), 그 기억을 기반으로 자동화를 돌려 ‘맥락 비용’을 줄이려는 제품 철학에 있습니다1. 다만 ROI를 내려면 설치보다 운영이 먼저예요. 기록 규칙과 검토 흐름을 잡는 순간부터 Rowboat의 장기 기억은 진짜 “복리”가 되기 시작합니다.
참고
1Show HN: Rowboat – 작업을 지식 그래프로 바꿔주는 AI 동료(오픈소스)
2Retrieval-augmented generation - Wikipedia
3RAG vs Knowledge Graph–Enhanced AI: What’s the Real Difference?