목회자 모임에서 인공지능 이야기가 나오면 분위기는 대개 둘로 갈립니다. 한쪽은 이미 써 보고 있다고 하고, 다른 한쪽은 조심스럽게 고개를 젓습니다. 그런데 고개를 젓는 분들의 말을 끝까지 들어 보면, 그것이 게으름에 대한 훈계가 아니라는 것을 알게 됩니다.
“설교를 거들어 준다는 게 못마땅한 것이 아닙니다. 그 자료를 어디서 가져왔는지 알 수가 없으니 못 쓰는 겁니다.”
이 말은 정확합니다. 그리고 이 글은 그 한 문장에 대한 답으로 쓰였습니다.
반대의 진짜 이유는 게으름 논쟁이 아닙니다
인공지능이 “헬라어로는 본래 이런 뜻입니다”라고 알려 줄 때, 우리는 그 문장에 대해 가장 기본적인 질문을 던질 수 없습니다. 어느 사전입니까. 표제어가 무엇입니까. 그 뜻은 몇 번 항목입니까. 물어도 답이 돌아오지 않거나, 더 나쁘게는 그럴듯한 사전 이름이 하나 더 지어져서 돌아옵니다.
주석서 한 권을 인용할 때 우리는 저자와 책과 쪽수를 확인합니다. 그것이 학문의 예의이기 이전에, 강단에 서는 사람의 최소한의 책임이기 때문입니다. 그런데 인공지능이 준 문장에는 그 확인 절차를 걸 자리가 없습니다. 근거를 물을 수 없는 문장을 회중 앞에서 말한다는 것 — 목회자가 주저하는 지점은 바로 여기입니다.
그러니 이 주저는 보수적인 태도가 아니라 옳은 태도입니다. 문제는 도구를 쓰느냐 마느냐가 아니라, 근거를 확인할 수 있는 도구를 쓰느냐입니다.
위험한 것은 틀린 문장이 아니라, 그럴듯한 문장입니다
명백히 틀린 문장은 위험하지 않습니다. 읽는 순간 걸러지기 때문입니다. 정작 강단까지 올라가는 것은 그럴듯한 문장입니다. 설교 준비에서 그런 문장은 대개 세 가지 얼굴로 옵니다.
첫째는 원어 어원 비유입니다. “이 단어는 본래 두 낱말이 합쳐진 것으로, 문자적으로는 이러이러한 그림을 그립니다”라는 식의 풀이입니다. 아름답고, 설교에 잘 붙고, 대개 사전에 없습니다.
둘째는 출처 없는 통계입니다. “최근 연구에 따르면 현대인의 몇 퍼센트가…”로 시작하는 문장입니다. 기관도 연도도 보고서명도 없이, 숫자가 주는 권위만 남습니다.
셋째는 1차 자료 없는 역사 주장과 익명 인용입니다. “당시 유대인들은 이러이러했습니다”, “한 학자는 이렇게 말했습니다” — 확인할 수 있는 이름이 하나도 없는 문장들입니다.
이 세 가지가 특별히 위험한 이유는, 그것이 목회자의 권위를 타고 전달되기 때문입니다. 회중은 강단에서 들은 말을 검증하지 않습니다. 검증할 수단도 없고, 검증할 이유도 느끼지 않습니다. 검증되지 않은 한 문장이 수백 명의 마음에 사실로 새겨질 수 있다는 것 — 그래서 설교 도구에서 이 문제는 부가 기능이 아니라 가장 먼저 풀어야 할 문제였습니다.
설교관리매니저는 이것을 네 겹으로 막습니다.
첫째 — 애초에 쓰지 못하게 막았습니다
설교를 생성할 때 앱은 매번 사실성 가드를 프롬프트에 함께 넣습니다. 사후에 걸러 내는 것이 아니라, 처음부터 그런 문장을 만들지 못하게 하는 규칙입니다. 실제로 들어가는 문구는 이렇습니다.
- 원어: 어원 분해 비유, 사전에 없는 “더 깊은 뜻”, 본문 어형과 사전 표제어의 혼동은 금지. 인용은 BDAG·HALOT·BDB·LSJ의 표제어와 사전적 의미 항목 안에서만 허용합니다.
- 통계: 기관명 + 발표 연도 + 보고서명을 댈 수 없으면 쓰지 마라. “최근 연구에 따르면” 같은 모호한 권위 위장 금지.
- 역사: 본문에 없는 시대 묘사는 1차 자료(요세푸스·미슈나·탈무드·교부 저작·IVP 성경배경주석) 직접 인용이 있을 때만 쓴다.
- 인용: “한 학자는”, “어떤 신학자는”, “유대 랍비들은” 같은 익명 인용은 금지한다.
여기에 하나가 더 있습니다. 저작을 인용할 때 쪽수와 따옴표 친 직접 인용문은, 그 판본을 직접 대조한 경우가 아니면 쓰지 못하게 했습니다. 이유는 규칙 안에 그대로 적혀 있습니다 — 확인할 수 없는 세부는 지어낸 것과 구별되지 않는다. 그리고 본문을 내놓기 전 다섯 문항의 자가 점검을 통과하지 못하면 결과를 반환하지 않습니다.
다만 저희는 이 규칙들이 “지켜 달라는 부탁”이라는 것도 알고 있습니다. 그래서 가장 흔한 위반인 익명 인용은 부탁으로 두지 않았습니다. 앱의 코드가 문장 패턴을 직접 찾아내 확정 판정합니다. 모델의 선의에 맡기지 않는 부분이 있어야, 나머지 규칙도 신뢰할 수 있게 됩니다.
둘째 — 대조할 사전을 앱 안에 넣었습니다
여기가 “그 자료를 어디서 가져왔는지 알 수 없다”는 주저에 대한 정면 답입니다. 확인할 수 없는 이유는 대개 확인할 자료가 그 자리에 없기 때문입니다. 그래서 자료를 앱 안에 넣었습니다.
- 히브리어 구약·헬라어 신약 인터리니어 — STEPBible의 TAHOT·TAGNT 자료로, 단어마다 원어·음역·뜻·스트롱 번호·형태소가 들어 있습니다 (CC BY 4.0).
- 스트롱 사전 — openscriptures 판 (CC BY-SA 4.0).
- BDB 히브리어 사전 전문 — 7,263항목 (1906년판, 퍼블릭 도메인).
- Abbott-Smith 신약 헬라어 사전 전문 — 5,416항목 (1922년판, 퍼블릭 도메인).
- 성경 네 역본 — 개역개정, 새번역(대한성서공회와 맺은 저작권 약정에 따릅니다), 영어 WEB·KJV(퍼블릭 도메인).
사전을 고르는 과정에서 한 가지를 바꿨습니다. 흔히 쓰이는 BDB 축약본은 한 항목이 중앙값 39자에 불과합니다. 그 길이로는 “이 단어는 문자적으로 이런 그림을 그린다”는 주장을 반박할 수도, 확인할 수도 없습니다. 그래서 축약본을 버리고 항목당 중앙값 296자인 무삭제 전문을 넣었습니다. 가드가 금지하는 바로 그 주장을 판정할 자료가 없다면, 가드는 선언에 그치기 때문입니다.
이 자료들은 배경에서만 돌아가지 않습니다. 성경 검색의 원어 탭에서 목사님이 절 안의 단어를 직접 눌러 원어·음역·스트롱 번호를 보고, ‘사전 전문’을 펼쳐 BDB나 Abbott-Smith의 해당 항목을 그 자리에서 읽으실 수 있습니다. 화면 아래에는 출처와 라이선스가 늘 표시됩니다. 인공지능이 무엇을 보고 말했는지, 목사님도 같은 것을 보실 수 있어야 한다 — 이것이 설계의 원칙입니다.
그런데 그 사전은 1906년과 1922년입니다
여기서 정직하게 말씀드릴 한계가 하나 있습니다. 앱에 넣은 두 사전은 저작권이 만료된 고전입니다. BDB는 1906년판이고 Abbott-Smith는 1922년판입니다. 오늘 학계의 표준인 HALOT이나 BDAG는 저작권이 살아 있어 프로그램 안에 넣을 수 없습니다. 넣을 수 없는 것을 넣었다고 말하지 않기 위해, 이 한계를 그대로 적어 둡니다.
그렇다고 그 한 세기를 비워 둘 수는 없었습니다. 그래서 원어 해설에 **「최근 해석 동향」**이라는 절을 따로 두었습니다. 웹 검색을 켜시면, 그 단어의 의미 이해가 1906년 이후 어떻게 다듬어졌는지를 찾아 정리합니다 — 새로 밝혀진 용례(파피루스·사해문서·비문), 지금 학계에서 논쟁 중인 지점, 번역과 설교에서 흔히 오해되는 대목입니다.
핵심은 그것을 사전 항목과 같은 칸에 쓰지 않는다는 데 있습니다. 섞어 놓으면 어디까지가 검증된 사전이고 어디부터가 검색 결과인지 목사님이 구별할 수 없게 됩니다. 그래서 이 절에는 네 가지 규칙이 붙습니다.
- 모든 문장에 출처 링크를 답니다. 링크를 댈 수 없는 주장은 이 절에 아예 쓰지 못합니다.
- 내장 사전과 어긋나면 한쪽을 고르지 않습니다. *“Abbott-Smith(1922)는 이렇게 보지만, 이 연구는 저렇게 제안한다”*처럼 둘 다 적고 라벨합니다. 어느 쪽이 옳다고 단정하지 않습니다.
- 이 절의 내용은 위 「사전적 의미」 절로 넘어가지 못합니다. 그 절의 근거는 내장 사전 본문뿐입니다.
- 찾지 못하면 지어내지 않고 “검색 결과 없음 — 내장 사전 의미로 충분”이라고 적습니다.
요한복음 3:16의 ἀγάπη로 한 번 켜 보았습니다. 동향 절은 출처 링크 열여섯 개를 달아 정리하면서, “아가페는 신약이 하나님의 사랑을 말하기 위해 새로 만든 고유어”라는 — 설교에서 자주 들리는 — 문장을 출처와 함께 반박했습니다. 사전 한 권으로는 확인할 수 없고, 근거 없는 인공지능은 오히려 거들었을 문장입니다.
이 기능은 처음에 아무 일도 하지 않았습니다. 프롬프트 안에 “도구를 호출하지 마라”는 금지와 “웹 검색 도구를 사용하라”는 지시가 함께 실려 있었고, 모델은 그 모순을 감지해 검색을 거부한 뒤 사유를 적어 놓았습니다. 응답은 정직했지만 기능은 멈춰 있었습니다. 켜 보고서야 드러났고, 그래서 고쳤습니다. 검색은 횟수마다 비용이 드는 일이라 상한을 두었고(단어 하나는 여섯 번, 본문 범위는 열 번), 그래서 이 절은 목사님이 필요할 때 직접 켜시는 기능으로 두었습니다.
셋째 — 근거 없이는 “틀렸다”고 말하지 않습니다
완성된 원고는 사실성 검증을 거칩니다. 그런데 이 검증 자체도 인공지능이 하는 일이므로, 검증기가 근거 없이 의심만 늘어놓으면 목회자의 시간만 빼앗게 됩니다. 저희가 실제로 겪은 일입니다.
예전 방식은 원고 한 편을 통째로 주고 “문제를 찾아라” 하고 한 번 묻는 구조였습니다. 에스겔 37장 설교에서 열아홉 건이 잡혔는데, 화면에 올라온 세 건을 확인해 보니 전부 실재하는 주석서 인용이었습니다. 검증기는 대조할 자료를 한 번도 찾아보지 않은 채 “확인이 되지 않는다”를 위반으로 세고 있었습니다.
그래서 구조를 바꿨습니다. 지금은 두 단계로 나뉩니다. 먼저 확인이 필요한 후보만 뽑습니다. 이때 프롬프트가 못을 박습니다 — 여기서 낸 항목은 최종 판정이 아니라 확인할 후보다. 확인해 보지 않은 것을 이미 틀렸다고 단정하지 마라. 그다음 후보 한 건마다 판정을 한 번씩 붙입니다.
그 결과 모든 지적에는 판정과 근거가 함께 붙습니다.
판정은 세 가지입니다 — 반증됨, 확인됨, 확인 권장. 근거는 다섯 가지입니다 — 앱 내장 성경 본문, 원어 인터리니어·스트롱 사전, 문장 규칙 판정, 웹 검색, 그리고 근거 없음(모델 판단). 마지막 항목이 중요합니다. 대조한 자료가 없으면 검증기는 그렇게 스스로 밝힙니다. 화면에는 “근거 없음 — 대조한 자료 없음”이라고 적힙니다. 근거 없는 의심이 근거 있는 지적과 같은 무게로 쌓이지 않게 하기 위해서입니다.
판정을 도울 자료도 미리 깔아 둡니다. 성경 인용을 대조할 때는 개역개정과 새번역을 나란히 넣습니다. 역본이 다르다는 이유로 멀쩡한 인용이 오류로 잡히는 일을 막기 위해서입니다. 원어 주장에는 인터리니어와 사전 전문을, 그 외에 같은 설교의 본문 연구 노트와 Logos에서 조회한 실측 자료도 함께 대조 자료로 넣습니다. 검증기가 자기 기억이 아니라 앱이 실제로 갖고 있는 자료를 보고 판단하게 하려는 것입니다.
한 가지 더 있습니다. 검증기가 “검색했지만 찾지 못했다”고 적어 놓고 “반증됨”이라고 판정하면, 앱의 코드가 그 판정을 ‘확인 권장’으로 강등시킵니다. 지시를 내려 두는 것과 지켜지는지 확인하는 것은 다른 일이기 때문입니다.
넷째 — 마지막 권위는 끝까지 목회자입니다
검증을 통과해도 화면의 안내는 사라지지 않습니다. “강단 사용 전 본인이 한 번 더 확인 후 ‘확인 완료’를 누르세요.” 확인 완료를 누르는 사람은 앱이 아니라 목사님입니다.
확인하지 않은 원고를 인쇄하면 본문 맨 위에 경고가 자동으로 붙습니다 — “⚠ AI 생성 — 강단 사용 전 본인 확인 필수.” 검증에서 걸린 항목은 본문 첫머리에 별도의 메모로 남고, 이슈 목록에서 문장을 누르면 원고의 그 자리로 바로 이동합니다. 확인하고 싶은 주석이 있으면 우클릭 한 번으로 Logos의 그 본문이 열립니다.
그리고 이 검증은 인공지능이 쓴 원고 전용 장치가 아닙니다. 목사님이 직접 쓰신 원고, 예전에 써 두었다가 불러온 원고에도 똑같이 돌릴 수 있습니다. 이것은 인공지능을 감시하는 기능이기 이전에, 설교자의 사실 확인 도구입니다.
근거는 원고로 넘어가야 근거입니다
이 대목도 쓰다가 드러나 고쳤습니다. 원어 해설이 사전 전문과 형태소와 최근 동향까지 갖춰 화면으로 열 페이지가 되어도, 마지막 「설교 적용」이 두 문장으로 끝나면 그 근거는 원고까지 오지 못합니다. 실제로 그랬습니다. 근거를 갖추는 일에만 공을 들이고, 그것이 설교로 건너가는 마지막 한 걸음을 비워 두었던 것입니다.
그래서 적용을 다섯 블록으로 못박았습니다. 한 문장 메시지 · 설교 대지 제안 · 도입 훅과 예시 아이디어 · 회중 적용 질문 · 설교에서 피할 오해 — 매번 같은 자리에 같은 종류의 재료가 나오고, 분량도 위의 분석 절들과 균형을 맞추게 했습니다.
이 가운데 두 블록에는 이 글의 주제가 그대로 들어 있습니다. 대지를 제안할 때는 근거가 된 원어를 괄호로 밝히되 위 분석에서 실제로 다룬 것만 쓰게 했습니다. 그리고 「설교에서 피할 오해」는, 이 본문이 설교에서 흔히 오용되는 방식과 앞의 사전·형태소 근거가 그것을 어떻게 막아 주는지를 적는 자리입니다. 근거는 무엇을 말할지 알려 줄 때만이 아니라, 무엇을 말하지 않을지 알려 줄 때 가장 크게 쓰입니다.
「도입 훅과 예시 아이디어」에는 금지 문구를 한 번 더 붙였습니다. 예화는 지어내고 싶은 유혹이 가장 큰 자리이기 때문입니다. 일상에서 누구나 확인할 수 있는 관찰, 본문 자체의 이미지, 성경 안의 다른 장면으로만 만들고, 실화·통계·인물 일화·역사 사건은 출처를 댈 수 없으면 쓰지 않습니다.
그러고 나서야, 나머지가 의미를 가집니다
신뢰의 문제가 풀리고 나면 비로소 나머지가 자기 자리를 찾습니다.
성경 프로그램과 워드와 메모 앱을 오가느라 끊기던 사고의 흐름은 한 작업 공간으로 모입니다. 원고 옆에서 성경을 찾고, 주석 PDF를 펼치고, 예화를 끌어오고, 마인드맵으로 뼈대를 그립니다. 매주 “무엇을 설교하지” 하는 부담에는 매일 쌓이는 설교 제안과, 아직 설교하지 않은 장을 점선으로 드러내는 본문 허브와, 한 해의 주일을 미리 채워 보는 연간 계획이 있습니다. 쌓여서 다시 못 찾던 지난 설교는 의미로 검색되고 지도처럼 이어져 보입니다.
한 편의 설교는 주일 한 시간에서 끝나지 않습니다. 가정예배 순서지, 소그룹 나눔지, 엿새치 묵상, 주보 칼럼, 슬라이드와 카드뉴스까지 같은 화면에서 이어 만듭니다. 예배가 끝나면 QR 하나로 성도의 익명 반응을 받아 다음 주 준비 자리에 함께 놓습니다. 인터넷이 없는 예배당에서는 태블릿이 미리 받아 둔 원고를 열어 줍니다.
그리고 이 모든 것의 바탕에 하나가 더 있습니다. 목회자의 원고와 묵상은 가장 사적인 기록입니다. 그래서 이 앱은 자료가 목사님의 기기 안에 머무는 것을 기본으로 설계되었습니다. 신뢰는 근거를 확인할 수 있다는 데서 시작해서, 내 기록이 내 곁에 있다는 데서 완성됩니다.
자주 묻는 질문
인공지능이 쓴 설교를 그대로 강단에서 써도 됩니까?
아닙니다. 그리고 앱의 설계 자체가 그것을 전제하지 않습니다. 검증을 통과해도 “본인이 한 번 더 확인하라”는 안내가 남고, 확인하지 않은 원고를 인쇄하면 경고 라벨이 자동으로 붙습니다. 초안을 앞당겨 드리는 도구이지, 강단의 책임을 대신 지는 도구가 아닙니다.
원어 자료의 출처는 무엇입니까?
히브리어·헬라어 인터리니어는 STEPBible의 TAHOT·TAGNT(CC BY 4.0), 스트롱 사전은 openscriptures 판(CC BY-SA 4.0), 히브리어 사전은 BDB 무삭제 전문(1906년판, 퍼블릭 도메인), 헬라어 사전은 Abbott-Smith 전문(1922년판, 퍼블릭 도메인)입니다. 성경은 개역개정·새번역·영어 WEB·KJV를 갖추고 있으며, 새번역은 대한성서공회와 맺은 저작권 약정에 따라 수록했습니다. 앱 화면 안에서도 출처와 라이선스를 늘 표시합니다.
BDAG나 HALOT 같은 최신 사전은 왜 없습니까?
저작권이 살아 있어 프로그램에 넣을 수 없습니다. 그래서 내장 사전은 저작권이 만료된 BDB(1906)와 Abbott-Smith(1922)이고, 그 이후의 논의는 「최근 해석 동향」 절이 웹 검색으로 채웁니다. 다만 그 내용은 사전 항목과 다른 칸에, 출처 링크와 함께 적히고, 내장 사전과 어긋날 때는 어느 쪽이 옳다고 단정하지 않고 양쪽을 나란히 보여 드립니다. 목사님이 BDAG나 HALOT을 이미 갖고 계시다면, 이 절은 그 사전을 어느 표제어에서 펼쳐 보실지 알려 주는 안내로 쓰시는 것이 가장 좋습니다.
제가 직접 쓴 설교도 검증할 수 있습니까?
가능합니다. 직접 쓰신 원고와 파일로 불러온 원고 모두 같은 방식으로 검증할 수 있습니다. 제목 표시줄의 ‘사실성 검증’ 버튼으로 필요할 때 실행하시면 됩니다. 다만 묵상 에세이는 성격이 다른 글이라 검증 대상에서 제외했습니다.
제 원고가 인터넷에 올라갑니까?
기본은 목사님의 기기입니다. 설교와 자료는 컴퓨터 안의 데이터베이스에 저장되고, 인공지능 생성을 요청하실 때만 그 요청 내용이 처리를 위해 오갑니다. 태블릿으로 원고를 보내는 기능은 기본이 꺼져 있는 선택 기능이며, 켜시더라도 본문은 목사님만 아는 원고 암호로 잠근 뒤에 올라갑니다.
이 검증이 완벽합니까?
아닙니다. 이 글에서 가장 정직하게 말씀드리고 싶은 대목입니다. 검증은 명백한 지어냄을 걸러 주고 무엇을 근거로 판단했는지 밝혀 주지만, 모든 사실을 확인해 주지는 못합니다. 그래서 판정에 **‘확인 권장’**이라는 항목을 두었습니다. 그것은 “문제없다”는 뜻이 아니라 **“여기는 목사님이 확인해 주십시오”**라는 뜻입니다. 웹 검색까지 동원하는 깊은 확인은 설교 한 편을 검증할 때 기본으로 켜지고, 열두 관점을 한꺼번에 생성하실 때는 비용을 고려해 필요할 때 직접 켜시도록 두었습니다.
도구가 똑똑해질수록, 분별하는 자리가 중요해집니다
저는 앞선 글에서 인공지능이 설교의 마지막 권위가 되어서는 안 된다고 썼습니다. 그 문장은 다짐이었고, 이 글은 그 다짐을 어떻게 코드로 옮겼는지에 대한 보고입니다. 금지할 것은 처음부터 금지하고, 대조할 사전은 앱 안에 두고, 그 사전이 닿지 못하는 한 세기는 출처 링크와 함께 다른 칸에 적고, 근거 없이는 판정하지 않고, 마지막 확인은 목사님께 남겨 두는 것 — 신뢰는 “믿어 주십시오”라는 말이 아니라 이런 구조에서 생긴다고 믿습니다.
인공지능이 정확히 무엇을 보고 그렇게 말했는지 목회자가 되물을 수 있을 때, 비로소 이 도구는 강단 앞에 놓일 자격을 얻습니다. 그 되물음이 가능하도록 만드는 것이 저희가 할 일이고, 되물어 판단하시는 것은 끝까지 목사님의 일입니다. 도구가 똑똑해질수록 분별하는 목회자의 자리는 작아지는 것이 아니라 오히려 더 중요해집니다.
그러니 “그 원어 풀이는 어느 사전에 있습니까” 하고 물어 주십시오. 그 질문에 답할 수 있는 도구만 강단 곁에 두시면 됩니다.