생성형 AI로 교육 자료나 설교 연구 초안을 만들면 완성된 문장만 남기기 쉽다.
누가 어느 표현을 고쳤고, 어떤 근거 없는 문장을 지웠으며, 최종 승인 전에 무엇을 확인했는지는 사라진다.
그러나 목회 문서에서 중요한 것은 매끄러운 결과만이 아니다. 사람이 신학적·목회적 책임을 실제로 행사했다는 과정도 보여야 한다.
소프트웨어 개발에 널리 쓰이는 Git을 문서의 변경 이력 장부로 제한해 사용하면, AI 초안과 사람의 최종본 사이에 일어난 판단을 눈으로 확인할 수 있다.
왜 최종본만으로는 부족한가
일반 업무 문서라면 결과가 맞으면 된다. 목회 문서는 조금 다르다.
교육 자료와 설교 연구는 공동체 안에서 권위를 얻어 인용되고 재사용된다. 한 번 실린 장절이 다음 해 교재로 옮겨 가고, 누군가는 그것을 근거로 삶의 결정을 내린다.
그래서 "사람이 마지막에 봤다"는 한 줄로는 부족하다. 무엇을 보았고 무엇을 고쳤는지가 남아야, 나중에 오류가 발견됐을 때 어디서부터 되짚을지 알 수 있다.
결과만 남은 문서는
틀렸을 때 고칠 자리를 알려 주지 않는다.
1. Git은 승인자가 아니라 '차이를 보존하는 장부'다
Git 공식 입문서는 커밋할 때 프로젝트 파일의 상태를 스냅샷처럼 저장하고, 수정됨·스테이징됨·커밋됨이라는 세 상태를 구분한다고 설명한다.
공식 git diff 문서는 작업 중인 파일과 스테이징 영역, 두 커밋, 또는 디스크의 두 파일 사이 변경을 보여 줄 수 있다고 안내한다.
문서 작업에 옮기면 AI가 낸 첫 초안, 검토자가 고친 중간본, 책임자가 승인한 최종본을 서로 비교할 수 있다는 뜻이다.
Git이 하지 못하는 일
그렇다고 Git이 문장의 옳고 그름을 판단해 주지는 않는다. 삭제된 표현과 추가된 표현을 표시할 뿐, 다음은 알지 못한다.
· 수정이 성경 본문에 충실한지
· 상처 입은 사람에게 적절한지
· 인용 허락이 있는지
커밋이 많다고 검토가 깊었다는 뜻도 아니다.
따라서 변경 이력은 사람의 책임을 대신하는 인증서가 아니라, 누가 무엇을 확인해야 하는지 놓치지 않게 하는 증거다.
해석 공동체라는 맥락
이 구분은 성경 해석에서도 중요하다. 볼트의 공개 칼럼 「성경의 명료성과 해석 공동체」가 강조하듯 평신도의 독해, 교회의 공적 가르침, 신앙고백적 검토는 경쟁하지 않는다.
AI 초안도 개인의 즉흥적 인상을 권위 있는 해석으로 포장하지 않도록 공동체의 검토 아래 두어야 한다.
Git은 그 검토의 내용이 아니라
흔적을 지키는 도구다.
2. 한 문서에 네 개의 검토 표지를 세운다
첫째, 출처
초안을 만들기 전에 공개와 이용 권한이 확인된 자료 목록, 확인 날짜, 적용 범위를 적는다.
AI가 제시한 성경 장절·통계·인용은 목록에 자동으로 편입하지 않고 원문에서 다시 확인한다.
둘째, AI 초안
사용한 서비스와 모델 표시, 생성 시각, 입력한 공개 자료의 범위, 아직 확인하지 않은 항목을 문서 머리에 남긴다.
프롬프트 전문에 민감정보가 있다면 저장하지 말아야 하므로 애초에 그런 정보를 입력하지 않는다.
셋째, 사람의 수정
초안 커밋 뒤 검토자는 사실 오류, 신학적 비약, 지나친 확신, 저작권 위험, 배제적 표현을 고친다.
각 수정 이유를 모두 장문의 설명으로 만들 필요는 없지만 커밋 메시지는 판단을 드러내야 한다.
· 좋은 예 — "성경 장절 원문 대조", "근거 없는 통계 삭제", "상담을 사람에게 연결하도록 수정"
· 나쁜 예 — "수정함", "최종", "final2", "오타"
말만 반복하면 장부는 있어도 책임의 내용은 보이지 않는다.
메시지를 쓰기 어려울 때는 한 문장으로 답해 보면 된다. *"이 변경을 하지 않았다면 어떤 문제가 남았을까."* 그 답이 곧 메시지다.
넷째, 승인과 배포본
최종 승인자는 변경 차이를 다시 읽고 확인한다.
· 출처 링크가 열리는지
· 인용이 문맥을 벗어나지 않았는지
· 개인정보가 없는지
승인된 커밋의 식별값과 배포 파일의 이름을 작업표에 연결한다. 게시 뒤 오류를 고쳤다면 예전 기록을 몰래 바꾸지 말고 새 수정 커밋과 정정 사유를 남긴다.
이 흐름은 AI가 많이 썼는지를 밝히기 위한 감시가 아니라, 사람이 어디서 책임을 되찾았는지 설명하기 위한 장치다.
3. 공개 자료 한 편으로 시작하는 실제 절차
작업 폴더를 분리한다 — 상담·심방·교인명부·아동·청소년 정보·출석·헌금·재정·인사 자료가 전혀 없는 별도 폴더를 만든다. 이미 공개된 교육 안내나 교회가 저작권을 가진 짧은 글 한 편만 고른다
목적을 적는다 — 원자료 목록과 작성 목적, 제외할 내용을 README에 적는다
초안을 표시해 저장한다 — AI 초안을 Markdown 파일로 저장하되 파일명에 draft를 쓰고, 아직 승인되지 않았다는 문구를 본문에 넣은 뒤 첫 커밋을 만든다
역할을 나눈다 — 검토용 가지를 복잡하게 늘리기보다 작은 팀에는 한 파일과 짧은 커밋을 권한다. 한 검토자는 원문·장절·고유명사·수치를 대조하고, 다른 검토자는 목회적 어조와 적용을 살핀다
차이를 읽는다 — git diff --word-diff 같은 단어 단위 비교로 부정어, 수치, 인명, 단정 표현이 어떻게 바뀌었는지 본다
점검표를 통과한 때만 승인한다 — '출처 확인, 성경 문맥, 개인정보 없음, 저작권, 편향·환각, 사람의 최종 검토'를 적고 모두 통과한 때에만 approved 표지를 남긴다
배포본을 연결한다 — DOCX나 PDF 같은 배포본을 만들고 원본 Markdown의 승인 커밋과 연결한다
변환 뒤에는 파일이 열리는지, 제목·본문·출처가 빠지지 않았는지 별도로 확인한다. Git이 텍스트 변경을 잘 보여 주더라도 변환 과정의 글자 깨짐이나 누락까지 대신 검사하지는 못한다.
한국어 문서에서 차이를 읽는 요령
공식 문서상 단어 단위 비교의 기본 경계는 공백이다. 그래서 한국어 조사나 붙여 쓴 표현은 기대만큼 잘 나뉘지 않을 수 있다. 자동 색상만 믿지 말고 문단 전체를 함께 읽는다.
도움이 되는 습관이 하나 있다. 한 문장을 한 줄로 쓰는 것이다.
긴 문단을 한 줄에 몰아 쓰면 조사 하나만 고쳐도 문단 전체가 바뀐 것처럼 표시된다. 문장마다 줄을 바꾸면 실제로 손댄 문장만 드러나고, 검토자는 그 문장만 읽으면 된다. 편집기에서 줄바꿈 표시를 켜 두면 화면에서는 평소와 똑같이 보인다.
세 화면의 역할을 구분한다
실무 화면에서는 이 순서를 지킨다.
· git status — 작업 전, 대상 파일만 있는지 확인한다
· git diff / git diff --word-diff — 수정 후, 무엇이 바뀌었는지 읽는다
· git diff --cached — 승인할 변경만 스테이징한 뒤, 실제로 커밋될 내용을 마지막으로 본다
명령을 복사해 실행하는 것보다 중요한 것은 이 세 화면의 역할을 구분하는 일이다.
작업 폴더의 모든 파일을 한꺼번에 추가하지 말고, 문서 한 편과 그 출처표만 선택한다.
이미지·DOCX 같은 이진 파일은 줄 단위 차이를 읽기 어려우므로 원본 Markdown을 책임 기록의 기준으로 삼고, 변환본에는 생성 시각과 원본 식별값을 붙인다.
이 절차는 공식 기능을 문서 검토에 적용한 제안이며, 특정 교회의 저장소에서 직접 운영 성능을 시험했다는 뜻은 아니다.
Git이 어렵다면 원리부터 옮긴다
명령어가 부담스러운 팀도 있다. 그렇다면 도구를 먼저 배우기보다 원리만 옮겨 와도 대부분의 효과는 얻는다.
· 초안·검토본·승인본을 각각 다른 파일로 남기고 덮어쓰지 않는다
· 파일명에 날짜와 상태를 넣는다
· 무엇을 왜 고쳤는지 문서 맨 아래 한 줄로 적는다
· 승인자와 승인 날짜를 본문에 남긴다
Git은 이 일을 자동으로, 빠짐없이 해 주는 도구일 뿐이다. 순서가 바뀌면 도구만 남고 검토는 사라진다.
처음 두 주는 세 편만 시험한다
오류를 몇 개 발견했는지뿐 아니라 이런 것을 함께 기록한다.
· 검토에 든 시간
· 되돌린 수정
· 근거를 찾지 못해 삭제한 문장
· AI 없이 쓰는 편이 나았던 작업
변경 이력이 형식적인 클릭만 늘리고 실제 검토를 돕지 못하면 커밋 단계를 줄인다. 반대로 부정어 하나나 오래된 수치를 찾아냈다면 그 유형을 다음 점검표에 추가한다.
도구를 지키는 것이 아니라
검토 품질을 높이는 것이 목적이다.
4. 로컬 저장은 비밀 보장이 아니다
Git 입문서는 대부분의 작업이 로컬 파일과 자원만으로 가능하다고 설명한다. 이 장점 때문에 인터넷 연결 없이 변경 이력을 관리할 수 있다.
그러나 로컬 저장소라는 말은 민감한 원문을 넣어도 된다는 허가가 아니다.
· 커밋된 내용은 일반 삭제 뒤에도 이력에 남을 수 있다
· 원격 저장소를 연결하면 의도하지 않은 자료가 전송될 수 있다
· 자동 백업·클라우드 동기화·공유 폴더·계정 권한도 별도로 점검해야 한다
기본값은 비민감 공개 문서다
비밀번호, API 키, 개인 이름과 연락처, 건강·가족 정보가 들어간 파일은 커밋하지 않는다.
.gitignore는 실수 방지에 도움을 주지만 이미 커밋한 비밀을 지우는 장치가 아니다.
잘못 포함했다면 단순히 다음 커밋에서 삭제한 뒤 끝내지 말고, 접근을 차단하고 필요한 자격증명을 교체하며 저장소 이력과 백업의 처리까지 담당자가 확인해야 한다.
지웠다는 사실보다
그동안 누가 볼 수 있었는지를 먼저 따져야 한다.
작게 적용하는 위험 관리
NIST의 AI 위험관리 프레임워크는 특정 제품에 합격 도장을 주기보다 조직이 AI 위험을 설계·사용·평가 과정에서 관리하도록 돕는 자발적 틀이다.
교회는 이를 작게 적용할 수 있다.
· 책임자를 정한다
· 위험한 문서 유형을 제외한다
· 변경 이력으로 검토를 측정한다
· 오류가 반복되면 사용을 중단한다
설교의 해석 책임, 돌봄 관계, 영적 분별은 로그에 위임되지 않는다. 기록은 책임을 증명하는 보조물이지 책임 그 자체가 아니다.
자주 나오는 오해 셋
· "커밋을 많이 하면 꼼꼼한 검토다" — 횟수는 성실함의 지표가 아니다. 무엇을 확인했는지가 메시지에 없으면 아무것도 남지 않는다
· "이력이 남으니 나중에 책임을 물을 수 있다" — 이력은 추궁의 도구가 아니라 재현의 도구다. 감시로 쓰이기 시작하면 사람들은 정직한 메시지를 쓰지 않는다
· "개발 도구니까 우리에겐 과하다" — 과한 것은 도구가 아니라 적용 범위다. 문서 한 편, 파일 하나, 커밋 몇 개로 시작하면 된다
결론: 최종본 뒤에 숨지 않는 편집 문화
AI 시대의 목회 문서에는 "사람이 마지막에 봤다"는 말보다 구체적인 편집 문화가 필요하다.
공개 가능한 자료만 골라 AI 초안을 별도 상태로 저장하고, 사실·신학·목회·권리의 관점에서 수정하며, 차이를 읽은 뒤 승인본을 만든다.
Git은 이 과정의 스냅샷과 차이를 남길 수 있지만 진리를 분별하거나 상처를 돌보지는 못한다.
좋은 변경 이력은 AI의 참여를 과시하는 기록이 아니다.
근거 없는 문장을 왜 지웠고, 어떤 표현을 왜 낮추었으며,
최종 판단을 누가 책임졌는지를
공동체가 다시 설명할 수 있게 하는 기록이다.
참고 자료
· What is Git?, Pro Git / Git 공식 문서 — https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F (확인 2026-09-20)
· git-diff Documentation, Git 공식 문서 — https://git-scm.com/docs/git-diff (확인 2026-09-20)
· AI Risk Management Framework, National Institute of Standards and Technology — https://www.nist.gov/itl/ai-risk-management-framework (확인 2026-09-20)
이 글은 손하람 목사의 창가에 2026. 9. 21에 올린 글을 옮긴 것입니다.