옵시디언과 목회자: 오래 쌓아 온 설교가 다시 말을 걸 때

주일 저녁, 예배를 마치고 돌아와 노트북을 덮습니다. 한 주 내내 붙들었던 본문을 전했습니다. 준비한 말을 다 하지 못한 아쉬움도 있고, 예상하지 못한 대목에서 고개를 끄덕이던 성도의 얼굴도 떠오릅니다.

그런데 다음 설교를 준비하려고 앉으면 이상하게도 다시 처음인 듯합니다.

분명 예전에 이 주제를 깊이 공부했습니다. 어느 책에서 좋은 문장을 읽었고, 비슷한 본문으로 설교한 적도 있습니다. 그때 적어 둔 메모를 찾으면 도움이 될 텐데, 파일 이름이 떠오르지 않습니다. 한글 문서 몇 개를 열었다 닫고, 오래된 폴더를 뒤지다가 결국 새 문서를 만듭니다.

목회자의 컴퓨터에는 그렇게 다시 만나지 못한 생각이 쌓입니다. 수련회에서 밤늦도록 고친 원고, 신학교 시절의 연구 노트, 설교에는 넣지 못했지만 오래 마음에 남은 문장들. 하나하나에 시간과 고민이 들어 있습니다.

그 기록들이 이번 주의 목사님을 도울 수 있다면 어떨까요.

“이 본문을 공부하실 때 이런 질문을 남기셨습니다.” “몇 해 전 설교와 연결되는 대목이 있습니다.” “이번 원고에서 조금 더 설명하면 좋을 문장이 보입니다.”

그렇게 자료를 찾아 주고 함께 읽으며 다음 생각으로 이어 주는 비서가 곁에 있다면 설교 준비의 풍경도 달라질 겁니다.

옵시디언과 AI의 조합에서 제가 기대하는 것은 바로 이 장면입니다. 목회자가 오래 쌓아 온 시간을, 지금 필요한 순간에 다시 꺼내 쓸 수 있게 하는 일입니다.

설교 한 편에는 원고보다 많은 것이 들어 있습니다

설교문은 몇 장으로 끝나지만, 그 원고가 나오기까지의 시간은 훨씬 깁니다. 본문을 여러 번 읽고, 주석을 비교하고, 떠오른 적용을 적었다가 지웁니다. 어떤 문장은 맞는 말인데도 이번 주에는 전하기 어렵습니다. 그 말을 들을 한 사람의 얼굴이 떠오르기 때문입니다.

목회자에게 설교란 성경을 읽고 공동체의 삶을 돌아보며, 지금 이 말씀을 어떻게 전할지 책임 있게 분별하는 일입니다. 그래서 설교를 돕는 도구라면 이 시간을 소중히 다뤄야 합니다.

가령 설교에 쓰지 않은 주석 메모도 남겨 둘 가치가 있습니다. 이번에는 풀지 못한 질문이 다음 연구의 출발점이 될 수 있고, 설교 후 적어 둔 아쉬움은 다음 원고를 더 정확하게 만드는 단서가 될 수 있습니다.

매주 새로운 원고를 쓰더라도, 매주 모든 것을 새로 찾아야 할 필요는 없습니다.

자료를 찾는 수고가 줄어들면 본문 앞에 조금 더 머물 수 있습니다. 잊었던 질문을 다시 만나면 익숙한 구절도 천천히 읽게 됩니다. 저녁 시간을 조금 일찍 마칠 수도 있습니다. 설교자를 돕는 기술의 가치는 이런 변화에서 느껴집니다.

옵시디언, 내 폴더에 작은 도서관을 여는 일

옵시디언은 내 컴퓨터의 문서들을 연결해서 읽고 쓰는 앱입니다. 이름부터 낯선 ‘볼트’도 알고 보면 노트를 담은 폴더입니다. 그 안의 글은 마크다운이라는 일반 텍스트 형식으로 저장됩니다. 다른 편집기로 열어 읽을 수도 있습니다. (옵시디언의 데이터 저장 방식)

처음에는 세 가지만 알면 됩니다. 문서를 만들고 글을 쓰고 관련 문서를 연결하는 일입니다.

누가복음 15장을 연구한 노트가 있다고 해 보겠습니다. 그 글에 [[회복]]이라고 적으면 ‘회복’이라는 노트로 가는 길을 만들 수 있습니다. 여기에 과거의 설교문과 독서 메모를 함께 연결해 두면, 다음에 회복을 주제로 공부할 때 그 자료들을 따라 읽을 수 있습니다. (내부 링크 안내)

책을 읽다가 여백에 “지난번 누가복음 설교와 연결됨”이라고 써 두는 것과 비슷합니다. 종이에서는 기억을 더듬어 책을 다시 펼쳐야 했다면, 여기서는 링크를 누르면 됩니다.

설교자에게 이 방식이 잘 맞는 이유가 있습니다. 한 편의 설교는 본문 하나와 주제 하나에만 속하지 않습니다. 누가복음 연구이면서 회복에 관한 묵상이고, 새가족을 맞는 공동체에 전한 말씀이기도 합니다. 링크는 그 여러 관계를 함께 남겨 줍니다.

연구자와 작가도 같은 도움을 받을 수 있습니다. 한 번 읽은 논문, 한 번 밑줄 친 문장이 다음 글을 쓸 때 다시 눈앞에 나타납니다. 기록할수록 나중의 내가 도움을 받는 구조입니다.

설정을 좋아하면 하나씩 직접 꾸며도 됩니다. 그렇지 않다면 처음부터 폴더와 링크를 정리하지 않아도 됩니다. 이 반복 작업을 AI에게 맡기는 방법으로 이어가 보겠습니다.

AI에게 필요한 것은 맥락, 맥락, 맥락입니다

같은 본문으로 설교해도 목회자마다 붙드는 질문은 다릅니다. 교회의 역사도 다르고, 지금 공동체가 통과하는 시간도 다릅니다.

가족을 떠나보낸 성도들이 많은 교회에서 전하는 위로와, 새로운 사역을 시작하는 공동체에 전하는 격려는 같은 표현으로 담기 어렵습니다. AI에게 본문과 분량만 알려 주면 이 차이를 알 수 없습니다.

목회자가 중요하게 여기는 해석의 원칙, 자주 사용하는 말, 조심하는 표현, 공동체를 바라보는 시선이 기록으로 남아 있을 때 AI가 참고할 맥락이 생깁니다. 클로드든 GPT든, 먼저 내 자료를 읽게 하는 것이 출발점입니다.

이를테면 이런 부탁입니다.

이번 주에는 누가복음 15장을 준비합니다. 내 설교문과 연구 노트에서 관련 자료를 찾아 주세요. 과거에 반복해서 강조한 내용과 더 살펴볼 질문을 구분하고, 각각 어느 문서를 근거로 했는지 링크를 붙여 주세요.

여기에 자료를 바탕으로 한 답이 돌아온다고 상상해 보십시오. 잊고 있던 연구 노트가 열리고, 몇 년 전 원고와 이번 생각의 차이가 보입니다. 과거의 나에게 배울 수도 있고, 그때의 해석을 고쳐야겠다고 판단할 수도 있습니다.

세컨드 브레인, 곧 ‘두 번째 뇌’라는 말이 이때 조금 실감 납니다. 기억을 맡겨 두었다가 필요할 때 꺼내 생각을 이어 가는 겁니다. 옵시디언에 쌓인 기록과 AI의 읽기·정리 능력이 만나면 그 기록에 질문을 던질 수 있습니다.

오래된 HWP 설교문부터 다시 읽히게 했습니다

저도 최근 HWP Converter for AI로 설교문과 노트를 마크다운으로 바꾸고 서로 연결되는 LLM Wiki로 정리했습니다.

한국 목회자에게는 한글 파일이 익숙합니다. 강해설교 원고도, 성경공부 교안도, 여러 해의 묵상도 그 안에 남아 있습니다. 새로운 도구를 쓰기 위해 지난 기록을 포기할 이유는 없습니다. 그 기록을 다시 읽을 수 있는 형태로 옮기면 됩니다.

변환할 때는 본문뿐 아니라 제목과 작성일, 성경 범위, 인용 출처가 함께 남아야 합니다. 그래야 훗날 AI가 자료를 찾아왔을 때 “언제, 어떤 본문을 두고 쓴 글인지” 확인할 수 있습니다. 각주나 표가 있는 문서는 변환본을 원문과 대조해 보는 과정도 필요합니다.

한글 파일에서 나온 설교문 옆에 독서 노트가 놓이고, 본문 연구와 주제 문서가 연결됩니다. 그동안 파일 속에 따로 보관되던 생각을 한자리에서 찾아 읽을 수 있게 됩니다.

‘나만의 빅데이터 라이브러리’라는 표현은 거창하게 들릴 수 있습니다. 목회자의 입장에서는 내 설교와 공부가 어디에 있는지 알고, 서로 어떤 관련이 있는지 찾아갈 수 있는 서재라고 이해하셔도 좋겠습니다. 오래 쌓아 온 기록에는 이미 그 서재를 채울 내용이 있습니다.

RAG에서 LLM Wiki로, 질문이 끝나도 연구는 남습니다

이런 서재를 AI와 함께 이용하는 방식을 설명할 때 RAG라는 용어가 나옵니다. 관련 자료를 먼저 검색한 뒤, 찾은 내용을 참고해 답을 만드는 ‘검색 증강 생성’입니다.

“전에 고난을 주제로 어떤 설교를 했지?”라고 물으면 관련 원고를 찾아 답의 근거로 삼는 방식입니다. 자료를 매번 다시 찾아 조합하는 작업에서는, 이번에 발견한 연결이 다음 질문에도 남아 있을지 생각해 볼 필요가 있습니다.

안드레이 카파시는 「LLM Wiki」 원문에서 LLM이 원자료를 읽고, 서로 연결된 마크다운 위키를 지속적으로 작성·갱신하는 방법을 제안합니다. 질문할 때 검색하는 데서 한 걸음 더 나아가, 이미 읽고 정리한 내용을 다음 연구에도 남기는 것입니다.

목회 현장에서는 이렇게 이해할 수 있습니다. 새로 읽은 주석 메모를 AI에게 주면 출처별 요약을 만들고, 관련 본문 노트에 연결하고, 기존 연구와 다른 해석은 함께 표시하게 합니다. 나중에 질문해서 얻은 유용한 비교도 다시 연구 노트로 보관합니다.

원자료는 보존하고, 요약과 연결은 갱신합니다. 예전 해석과 새로 읽은 주석의 견해가 다르면 차이를 남깁니다. 무엇을 왜 고쳤는지도 기록합니다.

이런 의미에서 LLM Wiki를 RAG에서 진전된 지식 관리 방식으로 설명할 수 있습니다. 다만 모든 RAG의 상위 버전이라는 뜻은 아닙니다. 위키를 검색하는 데 RAG를 함께 쓸 수도 있습니다. 핵심은 연구의 결과가 다음 연구의 출발점으로 남는 것입니다.

한 주 동안 붙들었던 질문이 주일 이후에도 이어집니다. 다음 해 같은 본문을 펼쳤을 때, 그때의 연구와 지금의 질문을 함께 읽을 수 있습니다.

폴더 정리까지 목사님이 하실 필요는 없습니다

여기까지 읽고 “좋은 건 알겠는데, 언제 이걸 다 정리하지?”라는 생각이 드셨을지 모르겠습니다.

그 마음이 자연스럽습니다. 설교 준비만으로도 시간이 빠듯한데 파일 이름을 바꾸고, 폴더를 나누고, 링크를 붙이는 일까지 더해지면 또 하나의 업무가 됩니다.

이제는 그 정리 작업의 상당 부분을 AI에게 맡길 수 있습니다. 카파시의 제안에서도 사람이 자료를 고르고 질문하는 동안, LLM은 요약과 연결, 위키의 갱신을 담당합니다. 처음부터 완성된 분류 체계를 생각해 오실 필요가 없습니다. 가지고 계신 자료를 함께 보며 정해 갈 수 있습니다.

여기서 한 가지 구별만 하면 됩니다. 채팅창에서 클로드나 GPT와 대화하는 것과, 내 컴퓨터의 폴더를 읽고 수정할 수 있도록 연결된 에이전트를 사용하는 것은 다릅니다. 실제 파일 정리를 맡기려면 Claude Code나 Codex처럼 파일 작업 기능이 있는 도구에 작업할 폴더를 지정해야 합니다. 설치나 로그인, 접근 허용처럼 직접 확인할 단계는 있지만, 그다음부터는 말로 부탁하며 진행할 수 있습니다.

첫 부탁은 이 정도면 됩니다.

이 폴더에는 공개된 설교문 다섯 편이 있습니다. 원본은 보존하고 작업용 사본에서 정리해 주세요. 본문과 주제별로 다시 찾기 쉽게 만들고, 서로 관련된 문서를 연결해 주세요. 날짜나 출처가 불분명하면 추측하지 말고 표시해 주세요. 내가 옵시디언에서 어느 문서부터 열면 되는지도 알려 주세요.

폴더 구조를 제안하고, 필요한 문서를 만들고, 링크와 색인을 붙이는 일까지 맡길 수 있습니다. 이후에 “주제보다 성경 순서로 보는 게 편하겠습니다”라고 말하면 그 방향으로 고쳐 가면 됩니다. 플러그인 선택과 설정도 실제로 필요한 기능부터 도움을 받을 수 있습니다.

처음 운전석에 앉았을 때를 떠올려 보십시오. 익숙한 사람에게는 당연한 동작도 처음에는 하나하나 신경이 쓰입니다. 낯선 도구 앞에서 멈칫하는 마음 역시 능력의 부족으로 받아들이지 않으셨으면 합니다. 아직 손에 익지 않은 것일 수 있습니다.

문서 작업은 원본과 별도의 사본으로 작게 연습할 수 있습니다. 잘못 붙인 제목이나 마음에 들지 않는 폴더는 고치면 됩니다. 백업과 변경 이력을 준비해 두면 되돌아갈 길도 생깁니다. 첫날부터 모든 자료를 맡기실 필요는 없습니다.

설교문 한 편이 제대로 정리되고, 잊었던 메모 하나가 다시 찾아지는 경험이면 충분합니다. 그다음 부탁은 훨씬 쉬워집니다.

다른 설교자들은 어떻게 쓰고 있을까요

미국과 영어권의 글쓰기·성경연구 사례를 보면 저마다 시작한 지점이 다릅니다. 아래 사례에는 목회자의 실제 작업 기록과 성경 노트 교육 자료가 함께 들어 있습니다. 자신에게 익숙한 장면부터 살펴보시면 좋겠습니다.

Ryan Hayden: 설교문을 오래 쓸 수 있는 형태로 남기기

Ryan Hayden은 「Why Every Pastor Should Learn Markdown」에서 오랫동안 설교와 개인 노트를 마크다운으로 써 온 경험을 소개합니다. 옵시디언의 내부 링크와 성경 참조 플러그인도 자신의 글쓰기 흐름 안에서 설명합니다.

눈여겨볼 점은 원고의 다음 쓰임입니다. 한 번 쓴 설교를 다른 문서 형식으로 옮기고, ChatGPT를 이용해 유인물이나 슬라이드 초안을 만드는 식입니다. 주일 원고를 정성껏 준비한 수고가 주중의 교육과 나눔으로도 이어질 수 있습니다.

Chris J Wilson: 본문과 메모 사이에 길을 만들기

화면을 보며 감을 잡고 싶으시면 Chris J Wilson의 성경 노트 워크숍, Connected Bible Notes Starter Kit, 귀납적 성경연구 템플릿이 참고가 됩니다. 본문을 노트에 연결하는 방법과 관찰·해석·적용을 정리하는 과정을 살펴볼 수 있습니다.

모든 설정을 따라 할 필요는 없습니다. 내가 본문에서 발견한 것과 주석을 읽고 이해한 것을 구분해 적고, 다시 본문으로 돌아갈 길을 남기는 방식에 주목해 보십시오. 오래된 영상의 화면과 현재 앱의 메뉴는 다를 수 있지만, 기록의 원리는 자신의 연구에도 적용할 수 있습니다.

Mike Schmitz: 들은 설교가 다시 성경공부로 이어지도록

Mike Schmitz의 개인 교차참조 라이브러리 글은 설교를 들으며 남긴 노트를 성경 구절에 연결하는 사례입니다. 한 구절에서 출발해 그 구절을 언급한 다른 설교와 메모를 찾아갑니다.

이 방식은 설교자에게도 도움이 됩니다. “내가 이 구절을 어디에서 다뤘을까”뿐 아니라 “그때 어떤 구절과 함께 읽었을까”를 돌아볼 수 있습니다. 다른 사람의 설교에서 배운 내용에는 설교자와 날짜를 남겨 두면 자신의 관찰과도 구분할 수 있습니다.

화려한 그래프를 만드는 것이 목표는 아닙니다. 지난 기록으로 돌아갈 수 있으면 충분합니다. Schmitz도 모든 문장에 무작정 링크를 붙이기보다, 나중에 다시 만나고 싶은 관계를 골라 연결하라고 권합니다. AI가 연결을 제안하더라도 그 연결이 연구에 의미가 있는지는 직접 살펴보시면 좋겠습니다.

Darren Rowse: 설교가 끝난 뒤에도 배울 것을 남기기

호주 멜버른의 목회자 Darren Rowse는 Claude Code와 옵시디언을 연결한 과정과 AI를 활용한 설교 회고를 공개했습니다.

그는 원고와 연구 메모, 사용하지 않은 개요와 인용문을 설교 폴더에 함께 보관합니다. 설교 후에는 자신이 구성한 명령을 통해 자료를 검토하고, 더 다룰 내용과 앞으로 이어 갈 아이디어를 다시 노트로 남깁니다.

한국 목회자의 일주일에도 적용해 볼 만합니다. 월요일에 잠깐 시간을 내어 “이번 설교를 준비하며 배웠지만 전하지 못한 것은 무엇인가”를 정리하는 것입니다. 한 편을 마친 수고가 다음 편을 돕게 됩니다. Rowse가 강조하듯, 함께 예배한 동료와 나누는 대화도 이 회고에 꼭 필요합니다.

Daniel Rose: 설교 녹음을 다시 읽을 수 있는 글로

Daniel Rose는 자신의 작업 기록에서 설교 녹음을 MacWhisper로 전사하고, Gemini로 편집·서식화한 뒤 마크다운으로 옵시디언에 옮기는 흐름을 소개합니다.

설교 녹음이 남아 있다면 원고가 없는 설교도 다시 읽을 수 있는 자료로 정리할 가능성이 열립니다. 전사한 글을 원래 원고와 비교해 보면 강단에서 덧붙인 설명이나 생략한 대목을 돌아볼 수도 있습니다. 이 비교는 자신의 작업에 응용해 볼 수 있는 한 가지 방법입니다.

AI와 함께 공부해도, 목사님의 목소리는 남아야 합니다

자료가 잘 연결되면 AI에게 맡길 수 있는 일이 늘어납니다. 동시에 목회자가 더 선명하게 붙들어야 할 것도 보입니다.

설교문에는 그 교회를 섬겨 온 사람의 말이 들어 있습니다. 쉽게 위로할 수 없어서 오래 고른 표현, 단정하고 싶었지만 한 번 더 살펴본 문장이 있습니다. AI가 원고를 매끄럽게 고칠 때도 그런 대목은 함께 지켜야 합니다.

“이 문장은 조금 투박해도 남겨 주세요. 우리 교회에서 오래 사용해 온 표현입니다.”

이렇게 이유를 알려 주고 기록으로 남길 수 있습니다. 목회 비전도 표어만 적기보다 실제 판단을 함께 남기면 도움이 됩니다. 새 프로그램을 시작할 때 왜 속도보다 관계를 먼저 생각했는지, 어떤 경험이 그 선택에 영향을 주었는지 적어 두는 것입니다. 다음에 AI가 제안을 할 때 참고할 구체적인 근거가 생깁니다.

다만 나를 잘 아는 듯한 답이 언제나 정확한 것은 아닙니다. RAG나 LLM Wiki를 사용해도 자료를 잘못 읽거나, 주석의 견해를 성경 본문의 말처럼 섞을 수 있습니다. 정리된 위키의 오류가 다음 답으로 이어질 수도 있습니다. 그러므로 중요한 주장에는 원문을 열 수 있는 링크를 붙이고, 성경 본문·다른 저자의 해석·나의 적용을 구분하도록 맡기는 편이 좋습니다.

상담과 심방에서 배운 것을 기록할 때도 사람을 먼저 생각해야 합니다. 개인을 알아볼 수 있는 사연은 일반 연구 자료와 분리하고, AI와 함께 읽을 폴더에는 공개 설교와 비식별 연구 메모부터 넣으십시오. 로컬 폴더에 저장했다는 사실만으로 AI 처리까지 로컬에서 이루어지는 것은 아닙니다.

좋은 파트너에게 기대하는 태도는 분명합니다. 근거를 보여 주고, 모르는 것은 모른다고 말하고, 내 생각에 필요한 질문도 건네는 것입니다. 그렇게 도움을 받으며 마지막으로 본문과 공동체 앞에서 판단하는 자리는 목회자에게 남습니다.

성경연구의 서재를 넓히고 싶을 때

이제부터는 필요할 때 골라 볼 수 있는 도구들입니다. 모두 설치해야 하는 준비 목록으로 받아들이지 않으셔도 됩니다. 본문을 읽다가 “이 단어를 더 살펴보고 싶다”, “주석 메모를 한곳에서 보고 싶다”는 필요가 생겼을 때 돌아와 보시면 됩니다.

성경사전에서 확인한 설명, 주석가들이 달리 읽은 대목, 원어 본문의 형태를 관찰한 메모가 같은 본문 노트에 모이면 연구의 흐름을 따라가기 쉬워집니다. 각 메모에 저자와 책, 페이지, 사용한 판본을 남겨 두면 AI도 그 차이를 보존하며 정리할 수 있습니다. 링크가 있어도 필요한 대목은 실제 원문을 펴서 읽는 과정이 이어져야 합니다.

Logos와 내 연구 노트를 연결하는 시도

Logos를 쓰고 계시다면 그동안 읽어 온 주석과 사전, 개인 노트를 앞으로의 연구와 어떻게 연결할지 관심이 가실 것입니다. LogosBibleSoftwareMCP는 그 연결을 시도하는 커뮤니티 프로젝트입니다. MCP는 AI가 외부 도구와 자료에 접근하도록 연결하는 통신 규약입니다.

저장소는 본문 검색과 앱 탐색, 단어 연구와 주석 열기, 라이브러리 카탈로그 및 개인 노트 조회 등 24개 도구를 설명합니다. 기능에 따라 Biblia API, 로컬 자료 조회, 앱 제어와 화면 캡처 등을 사용하므로, 모든 주석 원문이 같은 방식으로 AI에 제공된다고 이해해서는 안 됩니다.

2026년 9월 8일 조사 당시 스타 26개, 포크 19개였으며, 공식 Logos 통합으로 소개할 수 있는 도구는 아닙니다. 실제 이용에는 운영체제와 Logos 버전, 필요한 권한의 확인이 따릅니다. 기존 연구 환경에 맞춰 연결을 시험해 보고 싶은 분이 살펴볼 만합니다.

한국어 성경을 내 서재에 들이는 다섯 가지 길

원어 연구 이야기를 듣다 보면, 정작 매주 펼치는 한국어 성경은 어디서부터 준비해야 할지 막막해집니다. 아래 다섯 저장소는 그 출발점을 조금씩 다르게 마련해 줍니다. 읽기 좋은 앱도 있고, AI와 검색 도구가 사용할 재료도 있습니다. 모두 설치할 목록이 아니라, 지금 필요한 한 가지를 고르는 안내로 읽어 주십시오.

Korean-Bible-1961-KRV — 한국어 본문을 차곡차곡 보관하고 싶다면

bluesaurel/Korean-Bible-1961-KRV는 1961년 개역한글 본문을 권별 JSON과 전체 통합 JSON으로 제공합니다. JSON은 컴퓨터가 ‘어느 책, 몇 장, 몇 절인가’를 구별해 읽기 좋은 자료 형식입니다. 성경 약어표와 장·절 통계, 교차 검증 보고서도 함께 두고 있어 데이터의 구성을 살펴보기 좋습니다.

목회자의 서재에서는 이 자료를 바탕으로 장별 MD 노트를 만들고, 설교문에서 해당 본문으로 연결하는 작업을 생각해 볼 수 있습니다. AI에게는 “본문을 고치지 말고, 책·장·절과 출처를 보존해 변환해 주세요”라고 요청하는 편이 좋겠습니다. 저장소가 제시하는 정확도는 제작자의 검증 결과이지 이 글에서 전수 대조한 결과는 아닙니다. 첫 변환에서는 장·절 누락과 옛 표기를 직접 대조해 보십시오. (파일과 검증 자료)

bible-db — 한국어 질문을 원어와 연결해 보고 싶다면

crizin/bible-db는 개역한글·KJV·히브리어 WLC·헬라어 비잔틴 본문을 JSONL과 SQLite 데이터베이스로 묶습니다. 스트롱 번호, 형태 정보, 의미 범주도 연결합니다. 완성된 설교 앱이라기보다, 본문 검색과 비교 도구를 만들 때 사용할 연구용 재료에 가깝습니다.

이를테면 ‘열매’라는 주제로 공부할 때 관련 어휘를 찾고, 한국어 본문과 원어 정보를 함께 살펴보는 도구를 구상할 수 있습니다. 다만 의미 범주는 LLM이 생성한 보조 분류이므로 주석의 결론처럼 받아들이면 안 됩니다. 언어별 장·절 차이를 맞춘 좌표가 따로 있어, 비교 도구를 만들 때는 단순히 같은 절 번호끼리 이어 붙이지 않아야 합니다.

자연어 의미 검색 예제는 질문을 Gemini API로 보내 벡터로 바꾸므로 별도 API 키와 데이터 전송 확인이 필요합니다. 일반 데이터 조회와 이 검색 기능은 구별해 두십시오. 코드의 MIT 라이선스와 본문·태깅 자료의 이용 조건도 서로 다릅니다. (기능 설명, 자료별 출처와 라이선스)

Bible-krv — 한 권부터 작게 연결해 보고 싶다면

yuhwan/Bible-krv는 창세기.json, 요한복음.json처럼 한글 책 이름으로 구분된 개역한글 데이터와 books.json 목록을 제공합니다. 확인한 창세기 파일은 책 아래에 장, 장 아래에 절 번호와 본문을 담는 구조입니다. 처음에는 복잡한 검색 시스템보다 성경 한 권을 노트로 바꾸는 연습 재료로 살펴볼 만합니다.

예를 들어 이번 달에 요한복음을 설교한다면, 해당 자료의 구조를 확인하고 장별 연구 노트와 연결하는 방식을 AI에게 제안받을 수 있습니다. 다만 조사 당시 README와 명시적인 저장소 라이선스 파일을 확인하지 못했고 마지막 푸시도 2020년이었습니다. 간결한 구조는 장점이지만, 본문 정확성과 재사용 조건까지 확인된 완성 패키지로 소개할 수는 없습니다. (저장소 파일 목록)

Bible Sidecar KR — 설교 노트 옆에 한국어 성경을 펼쳐 두고 싶다면

KORThomasJeong/bible-sidecar-KR는 옵시디언 사이드바에서 성경을 읽고 선택한 구절을 노트에 복사하는 플러그인입니다. 히3, 히3:5, Heb 3 같은 참조를 입력해 본문으로 이동하고, 여러 절을 선택해 일반 텍스트나 인용 상자 형태로 가져오도록 설계되어 있습니다. 이 다섯 가지 중 ‘설교를 쓰는 화면에서 바로 써 보고 싶다’는 필요에 가장 가까운 도구입니다.

개역한글·NIV·KJV는 외부 본문 API를 이용하고, 개역개정은 포함하지 않습니다. 개역개정을 쓰려면 이용 권한을 갖춘 JSON 파일을 직접 준비해야 합니다. 원작 Bible Sidecar를 한국어 환경에 맞춘 MIT 코드이지만, 코드가 공개되어 있다는 사실이 각 역본의 자유로운 복제 허가를 뜻하지는 않습니다. 설치는 저장소의 릴리스와 안내를 확인하십시오. 공식 커뮤니티 목록에 이미 등록된 플러그인이라고 전제하지 않는 편이 안전합니다. (기능·본문 출처·설치 안내)

bible-crawler — 수집보다 먼저 검증과 이용 조건을 살펴볼 도구

동명 저장소 중 여기서는 한국어 성경 수집과 검증 절차를 설명한 ConanShin/bible-crawler를 소개합니다. README는 웹 본문을 JSON으로 저장하는 Python 크롤러, 재시도 처리, 구조와 누락 여부를 검사하는 검증 도구를 설명합니다. 목회자가 매주 실행할 앱보다는 개발 협력자와 자료 준비 과정을 검토할 때 참고할 프로젝트입니다.

이 도구가 주는 중요한 질문은 “얼마나 많이 가져올 수 있을까”보다 “빠뜨리거나 다른 역본과 섞지 않았는가”입니다. README의 출력 파일명은 통상적인 역본 약어와 혼동될 수 있으므로 파일명만으로 판본을 판정하지 않아야 합니다. 또한 조사 당시 명시적인 라이선스 파일을 확인하지 못했습니다. 수집 기능이 있다는 것과 수집·저장·재배포가 허용된다는 것은 별개입니다. 사이트 이용 조건과 역본별 권한을 확인하기 전에는 실행을 권하지 않습니다. 이 글의 조사에서도 크롤링을 실행하지 않았습니다. (구조와 검증 절차)

작은 저장소일수록, 별의 숫자 옆에 설명서를 함께 보십시오

2026년 9월 8일 GitHub 조회 기준입니다. 인기도와 본문 정확도는 같은 지표가 아닙니다. 아래 숫자는 순위가 아니라 규모를 가늠하는 참고입니다. 다섯 도구 모두 이번 글을 위해 설치·실행 검증한 것은 아닙니다.

마지막으로 개역한글과 개역개정은 구별해 주십시오. 대한성서공회는 개역한글의 저작재산권 보호기간이 경과했으며, 출처 표시와 동일성 유지에 유의해 사용할 것을 안내합니다. 이 안내를 다른 역본이나 주석·성경사전 전체에 확대 적용해서는 안 됩니다. AI에게도 성경 본문은 고쳐 쓰는 대상이 아니라, 출처를 보존하고 돌아가 확인할 기준 자료로 다루게 하십시오. (대한성서공회 저작권 FAQ)

한국어부터 히브리어·헬라어·라틴어까지, 연구에 보탬이 되는 저장소

아래 도구는 본문 비교, 원어 학습, 번역 연구처럼 서로 다른 필요에 답합니다. 기능 설명과 GitHub 지표는 2026년 9월 8일의 저장소 조사에 근거합니다. 직접 설치해 성능을 비교한 순위는 아니며, 적용 장면은 목회자의 연구를 위해 제안하는 예입니다.

1. 말씀숲 — 한국어 설교자를 위한 원문 연구 화면

yongsuk77-art/malssumsoop은 한국어 설교자가 한 절을 번역본, 히브리어·헬라어 원문, 형태 분석, 스트롱 코드, 사전과 주석을 한 화면에서 살펴보도록 만든 설치형 PWA입니다. 최대 네 개 번역본을 장·절 단위로 맞춰 보고, 베들레헴 자료 파일을 직접 가져올 수 있다는 점이 국내 목회자의 실제 환경과 맞닿아 있습니다.

특히 중요한 부분은 연구 데이터의 경계가 비교적 분명하다는 점입니다. 가져온 베들레헴 자료는 브라우저의 IndexedDB에 보관되고 서버로 업로드되지 않지만, AI 통찰 기능을 누르면 선택한 구절과 문맥, 원어 분석 정보가 Cloudflare Workers AI로 전송됩니다. 따라서 이 도구를 교회 자료와 함께 사용할 때는 “원문 연구 정보”와 “성도 상담·목회 기록”을 한데 넣지 않는 편이 안전합니다.

이 저장소는 2026년 9월 8일 기준 스타 0개, 포크 0개, 열린 이슈 1개, MIT 라이선스였습니다. 숫자는 작지만, 개역개정·한국어 원어사전·베들레헴 자료를 중심으로 한 한국어 연구 흐름을 보여 주는 국내 사례라는 점에서 의미가 있습니다. 목회자가 사용한다면 먼저 공개된 데모를 확인하고, 사용하려는 성경 번역본과 사전의 라이선스를 별도로 확인해야 합니다.

2. 미도트 32 성경 연구소 — 해석 방법을 질문으로 바꾸는 국내 실험

yongsuk77-art/midot32-bible-lab은 랍비 엘리에제르에게 전승되는 32가지 해석 규칙을 본문 연구 흐름에 적용하고, 복음주의적 정리와 설교 적용을 구분해 보여 주는 모바일 우선 웹 앱입니다. 본문의 구조와 핵심 원어를 관찰한 뒤, 각 규칙이 실제로 적용 가능한지 ◎ / ○ / △ / —로 판정하고, 적용이 어려운 규칙은 보류하도록 설계한 점이 흥미롭습니다.

이 프로젝트가 목회자에게 주는 가장 큰 교훈은 AI가 해석을 많이 내놓는 것이 아니라, 어떤 해석 규칙을 적용했고 어디서 멈췄는지를 기록하는 것이 중요하다는 점입니다. 연구 결과를 그대로 설교에 옮기기보다, “본문의 1차 의미”와 “기독교 정경 안에서의 종합”, “오늘의 적용”을 서로 다른 층위의 노트로 저장하면 LLM Wiki의 근거 구조를 훨씬 정직하게 만들 수 있습니다.

2026년 9월 8일 기준 스타 0개, 포크 0개, MIT 라이선스이며, 저장소 설명에는 요청 크기 제한과 보안 헤더, 프롬프트 인젝션 방어, Markdown 다운로드 기능이 기재되어 있습니다. 다만 AI가 생성한 결과는 어디까지나 연구 초안이므로, 본문과 주석을 직접 대조한 뒤 사용해야 합니다. 이 프로젝트는 “신학적 정답을 주는 앱”이 아니라 “해석 과정의 질문을 구조화하는 실험”으로 보는 것이 적절합니다.

3. BibleOL — 히브리어와 헬라어를 함께 배우는 학습 시스템

EzerIT/BibleOL은 Biblical Hebrew와 Greek를 웹에서 학습하도록 만든 오픈소스 프로젝트입니다. 단순히 성경 본문을 보여 주는 뷰어가 아니라, 원어 학습자가 본문을 읽고 어휘와 문법을 익히도록 돕는 교육 시스템에 가깝습니다. 설치 시 필요한 데이터베이스를 별도로 내려받는 구조이고, 기술 문서와 Docker 설치 경로도 제공합니다.

목회자의 활용법은 “설교문 자동 작성”이 아닙니다. 설교 본문을 정한 뒤 해당 본문에서 반복되는 어휘와 문법 요소를 학습 과제로 만들고, 내가 실제로 확인한 원어 관찰만 [[본문 관찰]] 노트에 옮기는 것입니다. AI에게 원어 설명을 바로 묻기 전에 BibleOL 같은 학습 도구로 형태를 직접 확인하면, 사전의 한 가지 뜻을 본문 전체의 의미로 과장하는 위험을 줄일 수 있습니다.

이 저장소는 2026년 9월 8일 기준 스타 28개, 포크 17개, 열린 이슈 42개이며 라이선스 표시는 NOASSERTION입니다. 따라서 코드를 활용하거나 데이터베이스를 재배포할 때는 저장소의 기술 문서와 각 데이터의 권리 조건을 반드시 확인해야 합니다. “오픈소스 레포”라는 이유만으로 포함된 성경 데이터까지 자유롭게 재배포할 수 있는 것은 아닙니다.

4. HebrewTools Reader — 본문에 등장한 어휘만으로 히브리어 독본 만들기

HebrewTools/Reader는 성경 히브리어 본문에서 특정 범위에 실제로 등장하는 표제어만 뽑아 독본(reader)을 생성하는 도구입니다. 창세기 전체나 시편 1편처럼 원하는 범위를 지정하면, 본문과 그 본문에 필요한 어휘 목록을 포함한 텍스트·PDF를 만들 수 있습니다. 성경 히브리어 분석 데이터인 BHSA와 Text-Fabric을 사용합니다.

원어 공부를 다시 이어 가고 싶은 분에게는 이번 주 본문에 등장하는 어휘부터 살펴볼 수 있다는 점이 반갑습니다. 예를 들어 한 본문의 동사 목록을 독본으로 만들고, 각 동사의 형태·문맥·번역상의 차이를 별도 Markdown 노트로 기록할 수 있습니다. 단어 하나의 어근 뜻을 설교의 중심 명제로 확대하지 않도록, 어휘 관찰, 문맥 관찰, 설교 적용을 분리해 저장하는 것이 좋습니다.

2026년 9월 8일 기준 스타 18개, 포크 7개, 열린 이슈 0개, MIT 라이선스이며 웹 서비스도 제공합니다. 다만 PDF 생성에는 Python과 XeLaTeX가 필요하고, BHSA 데이터는 별도 취득 절차가 있으므로 처음부터 교회 전체 시스템으로 도입하기보다는 연구자 개인의 본문 준비 도구로 시험하는 편이 현실적입니다.

5. greek-reader — 헬라어 본문을 읽기 위한 맞춤형 독본 생성기

jtauber/greek-reader는 MorphGNT와 형태론적 어휘 자료를 바탕으로 헬라어 본문 독본을 생성하는 Python 도구입니다. 특정 본문을 지정해 LaTeX 독본을 만들고, 각 단어에 표제어와 동사의 형태 분석 코드를 붙일 수 있습니다. 자주 나오는 단어를 제외 목록으로 만들거나, 표제어별 기본 번역어를 YAML로 추가하는 기능도 제공합니다.

이 도구의 장점은 AI에게 “이 헬라어 단어의 뜻이 무엇인가”라고 묻는 대신, 본문 전체에서 같은 단어가 어떤 형태와 문맥으로 나타나는지 직접 비교하게 한다는 것입니다. 생성된 독본은 PDF로 보관하고, 중요한 관찰은 다음처럼 본문 노트에 연결할 수 있습니다.

본문: [[요한복음 18:1-11]]
어휘 독본: [[Greek Reader - John 18 1-11]]
관찰: [[헬라어 동사 관찰 - 2026-09-13]]
주의: 형태 분석은 의미 해석과 동일하지 않음

2026년 9월 8일 기준 스타 35개, 포크 11개, 열린 이슈 3개, MIT 라이선스입니다. 다만 저장소의 마지막 업데이트 시점과 사용 중인 MorphGNT 자료의 범위를 확인해야 합니다. 형태 분석 코드를 번역이나 주석의 결론으로 오해하지 말고, 문장 구조와 문맥, 주요 주석가의 논의를 함께 검토해야 합니다.

6. bible-corpus — 여러 언어의 번역을 나란히 비교하는 데이터셋

christos-c/bible-corpus는 성경 번역본을 여러 언어로 정렬한 병렬 말뭉치입니다. 책·장·절 색인을 기준으로 언어별 텍스트를 거의 문장 단위로 맞추어 놓았기 때문에, 한국어 번역과 영어· 다른 언어 번역에서 문장이 어떻게 나뉘고 표현이 달라지는지 비교하는 데 사용할 수 있습니다. 저장소는 2025년 업데이트에서 TextGrid Repository로 호스팅 위치와 인코딩·메타데이터가 개선되었다고 안내합니다.

이 자료는 히브리어·헬라어 원문 데이터베이스와는 성격이 다릅니다. 번역본의 차이를 보는 비교 자료이지, 원문 비평의 최종 근거가 아닙니다. 목회자는 한 구절의 한국어 표현이 영어 번역에서 어떻게 풀렸는지 살펴보고, 그 차이를 설교의 질문으로 삼을 수 있습니다. 하지만 번역 간 차이를 곧바로 “원문의 진짜 뜻”으로 단정해서는 안 됩니다.

2026년 9월 8일 기준 스타 198개, 포크 54개, 열린 이슈 3개, CC0-1.0으로 표시되어 있습니다. 다만 저장소 안의 개별 자료와 인용 논문, TextGrid에 옮겨진 데이터의 이용 조건을 확인해야 합니다. LLM Wiki에 넣을 때는 원문 파일 전체를 무분별하게 복사하기보다, 필요한 구절·언어·출처·버전 정보를 메타데이터와 함께 보존하는 방식이 좋습니다.

라틴어 자료를 찾을 때의 현실적인 선택

라틴어를 함께 읽고 싶은 분께는 작은 도구 하나를 덧붙입니다. tdupes/dlv는 라틴어와 영어 성경 구절을 터미널에서 보여 주는 작은 프로젝트로, 2026년 9월 8일 기준 스타 2개, 포크 0개, 열린 이슈 0개였습니다. 연구 플랫폼이라기보다 라틴어 본문을 빠르게 확인하는 최소 도구에 가깝습니다.

라틴어 성경을 연구하려는 목회자라면 이 도구 하나만으로 충분하다고 생각하기 보다, 불가타 판본과 사용 중인 라틴어 텍스트의 판본·저작권·편집 정보를 먼저 확인해야 합니다. 라틴어 자료는 예배 전통, 교부 문헌, 불가타 판본 비교라는 별도의 연구 문맥을 가지므로, 검색 결과를 곧 헬라어 신약 연구 방식으로 환원하지 않는 것이 중요합니다.

옵시디언 플러그인 10개, 필요한 순간에 하나씩

플러그인은 옵시디언에 붙이는 작은 추가 기능입니다. 성경 구절 입력을 돕거나, 본문별 설교 목록을 만들거나, 독서 자료의 출처를 관리합니다. 아래는 앞선 조사에서 살펴본 후보 10개입니다. 미국 목회자의 사용량 순위로 검증된 목록은 아닙니다. GitHub 스타·포크는 2026년 9월 8일 확인값이며, 실제 선택에는 기능과 문서, 데이터 처리 방식, 현재 지원 상태를 함께 살펴야 합니다.

시작할 때는 기본 노트와 링크만 사용하셔도 됩니다. 성경 구절을 자주 입력하게 되면 성경 참조 도구를, 연구 자료가 늘면 문헌 관리나 목록 기능을 추가하십시오. 선택이 어렵다면 AI에게 지금의 자료와 작업 방식을 설명하고 필요한 기능을 골라 달라고 부탁할 수 있습니다.

볼트 안에서 AI와 대화하는 화면을 원하시면 Claudian도 살펴볼 수 있습니다. Claude Code와 Codex 같은 에이전트를 연결하는 도구로, 2026년 9월 8일 조사 당시 스타 15,207개와 포크 1,007개였습니다. 선택한 제공자에게 질문, 첨부 파일, 도구 출력이 전송될 수 있습니다. 개인 상담 기록, 성도의 이름, 민감한 기도 제목을 그대로 AI 플러그인에 넣어도 되는지 먼저 결정해야 합니다. 옵시디언 공식 문서 역시 커뮤니티 플러그인은 제3자 코드를 실행하므로 위험을 검토해야 한다고 안내합니다. (커뮤니티 플러그인과 보안)

목사님의 설교를 AI가 읽을 수 있도록 준비해 보십시오

컴퓨터에 쌓여 있는 한글 파일을 떠올려 보십시오. 주일마다 고쳐 쓴 설교문, 성경공부 교안, 책을 읽으며 남긴 메모가 있을 것입니다. 그 안에는 목사님이 오랫동안 본문을 붙들고 공동체를 섬겨 온 시간이 담겨 있습니다.

이제 그 기록을 AI가 함께 읽을 수 있도록 준비해 보면 어떨까요.

첫걸음은 가지고 있는 HWP 문서를 마크다운, 곧 MD 파일로 바꾸는 것입니다. 마크다운은 비유하자면 ‘AI의 모국어’에 가깝습니다. 제목과 문단, 목록과 인용을 단순한 텍스트로 표현하므로 AI가 글의 내용과 구조를 읽고 다루기 좋은 형식입니다.

파일을 변환한다고 AI가 목사님의 뜻을 모두 이해하는 것은 아닙니다. 하지만 그동안 따로 열어 보아야 했던 설교와 연구 노트를 AI와 함께 읽고, 서로 연결할 준비가 됩니다. 무엇을 고민했고 어떤 말씀을 전하려 했는지, 이제 실제 기록을 보여 주며 대화할 수 있습니다.

처음부터 모든 파일을 정리하려고 애쓰지 않으셔도 됩니다. 설교문 몇 편으로 변환 결과를 확인하고, 익숙해지면 연도별로 범위를 넓혀 보십시오. 원본 HWP는 보관하고, 변환한 문서의 본문과 각주, 성경 구절이 제대로 옮겨졌는지만 먼저 살펴보시면 됩니다.

지금 시작할 수 있는 세 가지

1. 옵시디언을 설치하고, 설교를 담을 폴더 하나를 만드십시오. 폴더 이름이나 분류 체계를 완벽하게 정할 필요는 없습니다. 우선 ‘나의 설교 서재’ 정도면 충분합니다. 세부 정리는 AI와 함께 만들어 갈 수 있습니다.
2. HWP 설교문 몇 편을 MD로 변환해 넣어 보십시오. HWP Converter for AI 같은 변환 도구로 작업용 사본을 만들고, 개인 상담 내용이 없는 원고부터 클로드나 GPT에 전달해 보십시오. 첫 경험을 위해 유료 결제부터 서두를 필요는 없습니다. 사용하면서 필요한 기능과 처리할 자료의 양을 알게 되면 그때 선택하셔도 됩니다.
3. 막히는 부분을 누군가에게 물어보십시오. “MD 파일이 어디에 저장됐는지 모르겠습니다.” “옵시디언에서 이 폴더를 어떻게 여나요?” 이런 질문이면 됩니다. 지금 모르는 한 가지를 해결하는 것이 다음 단계로 가는 가장 구체적인 방법입니다.

자료를 준비했다면 AI에게 이렇게 부탁해 보셔도 좋겠습니다.

이 설교문들을 읽고, 내가 중요하게 다뤄 온 본문과 주제를 정리해 주세요. 서로 연결되는 대목을 찾아 원문 위치와 함께 보여 주세요. 글에서 확인되는 내용과 당신의 추정을 구분하고, 앞으로 더 연구할 질문도 남겨 주세요.

그 답을 읽다가 잊고 있던 문장을 다시 만날 수 있습니다. 예전에 남겨 둔 질문이 이번 주 본문과 이어질 수도 있습니다. AI가 내 뜻과 다르게 읽었다면 설명해 주시면 됩니다. 그 설명도 다음 연구를 위한 맥락이 됩니다.

목사님은 이미 이 서재를 채울 내용을 오래 쌓아 오셨습니다. 오늘 할 일은 그중 몇 편을 꺼내, AI와 함께 읽을 수 있게 준비하는 것입니다.

혼자 막히지 않으셔도 됩니다

처음 해보는 일은 작은 데서 막힙니다. 다른 사람은 쉽게 하는 것 같은데 내 화면에는 같은 메뉴가 보이지 않고, 설명대로 했는데 파일이 열리지 않기도 합니다. 그럴 때 혼자 오래 붙들고 계시지 않으셨으면 합니다.

이 블로그 운영자가 운영하는 ‘미디어와 A.I를 통한 교회사역 공유’ 오픈카톡방을 소개합니다. 미디어와 AI를 교회 사역에 어떻게 활용할지 함께 배우고 성장해 가는 커뮤니티입니다.

잘 알고 계셔야 참여할 수 있는 자리가 아닙니다. 해보고 싶은 일이 있는 분도, 어디서부터 시작할지 막막한 분도 편하게 오셨으면 합니다. “이걸 해보고 싶은데 여기서 막혔습니다”라는 말로 이야기를 시작하셔도 좋습니다.

혼자 알아낸 작은 방법이 다른 목회자의 시간을 아껴 줄 수 있고, 내가 꺼낸 질문이 누군가에게도 꼭 필요한 질문일 수 있습니다. 그렇게 서로의 경험을 나누며 각자의 사역에 맞는 길을 찾아가면 좋겠습니다.

미디어와 A.I를 통한 교회사역 공유 오픈카톡방 참여하기

참고한 자료

• Obsidian Help: How Obsidian stores data
• Obsidian Help: Internal links
• Obsidian Help: Community plugins
• LogosBibleSoftwareMCP
• Obsidian Bible Reference
• Obsidian Bible Linker
• Dataview
• Templater
• Tasks
• Obsidian Linter
• Citation
• Smart Second Brain
• Omnivore
• Obsidian Git
• Claudian
• 말씀숲
• 미도트 32 성경 연구소
• BibleOL
• HebrewTools Reader
• greek-reader
• bible-corpus
• Daily Latin Verse
• Andrej Karpathy: LLM Wiki 원문
• Ryan Hayden: Why Every Pastor Should Learn Markdown
• Chris J Wilson: Digital Bible Notes 워크숍
• Chris J Wilson: Obsidian Connected Bible Notes Starter Kit
• Chris J Wilson: Inductive Bible Study Obsidian Template
• Mike Schmitz: Obsidian 교차참조 성경 라이브러리
• Mike Schmitz: 5 Ways to Connect Your Notes & Ideas — 실제 로컬 그래프 화면
• Mike Schmitz: Connecting and Transcluding Notes in Obsidian — 실제 성경 교차참조 화면
• Joschua: Bible Study in Obsidian Kit — 실제 성경 노트 화면
• Obsidian Forum: My Bible Study Workflow — 실제 본문 연구 화면
• Darren Rowse: Claude Code와 Obsidian 연결
• Darren Rowse: AI 설교 디브리핑
• Daniel Rose: 설교 녹음에서 Markdown까지