[AI 워케이션 1기 곡성] 동의서 하나 잘못 쓰면 과징금 — AI에게 개인정보보호법 자료 14종을 물려 '틀리면 막아주는' 작성기를 만든 후기

📝 한줄 요약

개인정보 동의서는 겉으로 보면 간단한 서식처럼 보이지만, 실제로는 수집·이용, 제3자 제공, 업무위탁, 민감정보, 고유식별정보(주민등록번호·여권번호·운전면허번호 등), 주민등록번호 처리처럼 여러 법적 판단이 겹쳐 있는 문서였습니다. 그래서 AI에게 단순히 "동의서 만들어줘"라고 시키는 대신, 법령과 공식 자료를 근거로 삼고, 확인되지 않은 사실은 문서에 넣지 못하게 막는 작성기를 만들었습니다.

바쁘시면 이것만 읽어도 돼요:

• Claude Code와 Codex CLI를 함께 써서 개인정보 동의서 작성기를 만들었습니다.

• 목표는 "그럴듯한 샘플 생성"이 아니라, 법적으로 위험하면 멈추는 작성기였습니다.

• 공식 자료 14종 이상, 실무 샘플 31종, 골든 케이스(정답을 정해두고 결과를 비교하는 대표 시나리오) 19종을 기준으로 검증했습니다.

• 수집·이용인지, 제3자 제공인지, 업무위탁인지도 사용자의 선택만 믿지 않고 사실관계로 다시 판단하게 했습니다.

• 가장 중요한 전환점은 AI가 모르는 값을 채워 넣지 못하게 한 "실전 작성 모드"였습니다.

• 최종 법적 판단은 사람의 검토가 필요하지만, 빠뜨리기 쉬운 위험을 먼저 걸러내는 도구로 만들었습니다.

🎯 이런 분들께 도움돼요

• 개인정보 동의서를 직접 만들어야 하는 소상공인, 스타트업 총무·운영 담당자

• 법정 필수기재사항이 있는 문서를 다루지만 개발자나 법률가는 아닌 실무자

• 고위험 업무에 AI를 쓰고 싶지만, AI가 그럴듯하게 지어내는 것이 걱정되는 사람

• "AI가 문서를 대신 써준다"보다 "AI가 틀리면 막아준다"는 방식에 관심 있는 사람

😫 문제 상황 (Before)

개인정보 동의서는 생각보다 위험한 문서입니다.

이름과 휴대전화번호를 받는 것처럼 단순해 보이는 상황에서도, 실제로는 다음 질문이 따라붙습니다.

• 이 정보는 우리가 직접 수집해서 쓰는 것인가?

• 외부 회사에 넘기는 것인가?

• 외부 회사가 우리 업무만 대신하는 것인가?

• 그 외부 회사가 자기 목적에도 쓰는가?

• 마케팅 안내는 필수 동의에 묶어도 되는가?

• 주민등록번호를 받아도 되는 법적 근거가 있는가?

• 보유기간은 내부 기준으로 정하면 되는가, 법에서 따로 정한 기간이 있는가?

이 작업의 출발점은 간단했습니다. 겉으로는 서식 작성처럼 보이는 일이 실제로는 수집·제공·위탁을 가르는 법적 판단이고, 비법률가가 잘못 쓰면 과징금이나 형사책임으로 이어질 수 있다는 점을 분명히 인식한 것입니다.

실무자는 대개 "개인정보 동의서 하나 필요하다"고 생각합니다. 그런데 법적으로는 그 안이 여러 블록으로 갈라집니다. 수집·이용 동의, 제3자 제공 동의, 업무위탁 안내, 민감정보 동의, 고유식별정보 동의, 동의 없이 처리하는 개인정보 안내가 서로 다릅니다.

게다가 개인정보를 받는 일은 한 번으로 끝나지 않습니다. 회원가입, 이벤트, 채용, 배송, 예약처럼 사업을 운영하는 내내 반복되는 업무라서, 매번 사람의 기억과 복붙에 맡기기에는 위험이 누적됩니다.

특히 어려운 지점은 "수집이냐, 제3자 제공이냐, 위탁이냐"를 가르는 일입니다. 예를 들어 배송업체에 고객 정보를 넘긴다고 해서 항상 제3자 제공인 것은 아닙니다. 그 업체가 우리 업무만 대신하는지, 아니면 자기 사업 목적에도 쓰는지에 따라 결론이 달라질 수 있습니다.

기존 대안도 충분하지 않았습니다.

첫째, 서식 복붙은 케이스별 차이를 잡아내지 못합니다. 어느 서식에는 주민등록번호가 있고, 어느 서식에는 제3자 제공 표가 있고, 어느 서식에는 위탁 안내가 있습니다. 그런데 내 업무에 어느 것이 필요한지는 별도 판단이 필요합니다.

둘째, 인터넷 예시나 오래된 해설서는 최신 법령과 맞지 않을 수 있습니다. 개인정보보호법은 여러 차례 크게 바뀌었고, 예전 자료에는 지금 기준과 맞지 않는 설명이 섞여 있을 수 있습니다.

셋째, AI에게 그냥 물어보는 것도 위험합니다. AI는 빈칸을 싫어합니다. 목적, 항목, 보유기간, 제공받는 자가 부족하면 그럴듯한 값을 만들어 채울 수 있습니다. 일반 글쓰기라면 편리한 기능이지만, 법률 문서에서는 치명적인 문제가 될 수 있습니다.

그래서 목표를 이렇게 잡았습니다.

"개인정보 동의서를 자동으로 만들어주는 도구"가 아니라, "법적 근거와 사용자 확인이 없으면 문서 생성을 막는 도구"를 만들자.

규칙이 분명하고 반복되는 문서 판단이라는 점에서 AI와 자동화가 잘 맞는 일이었지만, 그만큼 근거 없는 자동완성은 강하게 막아야 했습니다.

🛠️ 사용한 도구

• Claude Code: 전체 설계, 법률 판단 구조화, 룰 설계, 검증 기준 정리, 작업 지휘

• Codex CLI: 병렬 구현, 웹 작성기 개선, 테스트 보강, 생성 결과 정리

• /show-me-the-prd: 막연한 아이디어를 기획서와 단계별 구현 계획으로 바꾸는 데 사용

• 품앗이: 여러 구현 작업을 나누어 동시에 진행하는 데 사용

• Ralph: 논리 구조와 하네스가 맞는지 검토하는 데 사용

• insane-search: 실무 샘플과 참고 자료를 찾고 정리하는 데 사용

• 모델: Claude Opus·Haiku 계열과 Codex 기반 코딩 에이전트

도구를 나눈 이유는 단순합니다. 법률 판단과 제품 방향은 한 곳에서 강하게 통제하고, 반복 구현과 테스트는 병렬로 밀어붙이기 위해서였습니다.

일반 챗봇 하나에 물어보는 대신 Claude Code를 쓴 이유는, 로컬에 모아둔 공식 자료를 직접 대조하고, 같은 절차를 반복 가능한 형태로 만들며, 근거 없는 답을 구조적으로 막아야 했기 때문입니다.

🔧 작업 과정

한 문장을 기획서로 바꾸기

처음에는 아이디어가 컸습니다. "개인정보 동의서를 자동으로 만들고 싶다"는 말만으로는 무엇부터 만들어야 할지 알기 어려웠습니다.

그래서 먼저 AI에게 제품 기획자 역할을 맡겼습니다.

이 자료들을 근거로 개인정보 수집 동의서·제3자 제공 동의서·위수탁 동의서·민감정보·고유식별정보 동의서 작성 자동화 파이프라인을 만들고 싶다. 일률적 서식은 금지, 법령 요구사항을 빠짐없이 반영하고, '수집/제3자제공/위탁'을 판별하는 로직이 필요하다. 사용자는 비법률가다.

AI는 바로 코딩을 시작하지 않았습니다. 어떤 문서를 만들 것인지, 어떤 법적 판단이 필요한지, 어떤 데이터를 받아야 하는지, 어떤 경우에는 생성을 막아야 하는지부터 쪼갰습니다.

이 과정에서 제품 개요, 데이터 구조, 단계별 구현 계획, 검증 기준이 생겼습니다. 막연한 문장 하나가 실제 개발 가능한 기획서로 바뀐 것입니다.

여기서 배운 점은 분명했습니다. AI에게 "바로 만들어줘"라고 하기 전에, 먼저 "나를 인터뷰해서 설계로 바꿔줘"라고 시키면 훨씬 안전합니다.

진짜 실무 서식으로 검증하기

기획서만으로는 부족했습니다. 법적으로 맞는 것처럼 보이는 설계가 실제 서식 관행과 어긋날 수 있기 때문입니다.

그래서 실제로 사용된 개인정보 동의서 샘플을 모아 분석했습니다.

각종 사이트에서 개인정보 동의서 샘플을 수집해야 함. 주택청약 관련은 한국부동산원, 나머지는 대표 서비스 사이트에서 개인정보 제공 동의서 샘플을 받아 분석할 것.

분석 대상에는 주택청약, 금융, 병원, 공공기관, 법정서식 등 여러 분야가 들어갔습니다. 총 31종의 실무 샘플을 보면서 중요한 사실이 드러났습니다.

실제 서식은 "한 장짜리 동의서"처럼 보여도 내부적으로는 여러 동의 블록으로 나뉘어 있었습니다. 필수 수집·이용, 선택 수집·이용, 제3자 제공, 민감정보, 고유식별정보, 위탁 안내가 한 문서 안에 섞여 있었습니다.

또 하나의 발견은 위탁과 제3자 제공의 경계가 실무에서 자주 흐려진다는 점이었습니다. 사용자는 그냥 "외부 업체에 준다"고 말하지만, 법적으로는 그 외부 업체가 어떤 지위인지 다시 확인해야 했습니다.

이 단계에서 설계가 많이 바뀌었습니다. 단순히 항목을 입력받아 표를 만드는 방식이 아니라, 사용자의 업무 흐름을 먼저 묻고 필요한 문서 블록을 자동 산정하는 방식으로 방향을 잡았습니다.

AI 설계도 실제 사례로 검증해야 탁상공론을 피할 수 있다는 점을 크게 느꼈습니다.

혼자 짜지 않고, 판단과 구현을 나누기

전체 구조가 잡히자 구현량이 커졌습니다. 법령 근거를 연결해야 하고, 위험 항목을 검증해야 하고, 문서를 만들어야 하고, 테스트도 필요했습니다.

이때 사용한 방식이 병렬 작업이었습니다.

품앗이로 Phase 1 만들어줘

핵심 법률 판단, 룰, 조문 연결, 문서 구조는 Claude가 직접 통제했습니다. 반면 반복 구현, 문서 생성기, 검증기, 테스트, 웹 작성기 같은 작업은 Codex 여러 개에 나누어 맡겼습니다.

이 방식의 장점은 속도만이 아니었습니다. "법적 판단은 한 곳에서 일관되게 하고, 손이 많이 가는 구현은 여러 AI에게 나눈다"는 구조가 생겼습니다.

한 AI로 처음부터 끝까지 순차로 만들 수도 있었지만, 구현량이 많아 느리고 법률 판단까지 흩어질 위험이 있어 판단은 한 곳에 모으고 구현만 병렬로 나누는 방식을 골랐습니다.

AI를 여러 개 쓴다고 해서 모든 판단을 흩어놓으면 오히려 위험합니다. 이 프로젝트에서는 판단의 중심은 좁게, 작업의 손은 넓게 가져갔습니다.

공식 자료를 물려서 지어내지 못하게 하기

개인정보 문서에서 가장 위험한 것은 "그럴듯한 법률 설명"입니다. 그래서 공식 자료를 조각내어 검색하고 인용할 수 있도록 연결했습니다.

개인정보 보호법, 시행령, 표준지침, 통합 안내서, 사례집, 질의응답, 동의서 작성 가이드 등을 법령 다음 우선순위의 참고자료로 반영해줘. 주민등록번호와 보유기간도 실제 근거를 찾아 검증에 활용하고 싶어.

여기에는 개인정보보호법, 시행령, 표준 개인정보 보호지침, 개인정보 처리 통합 안내서, 분야별 안내서, 질의응답, 공공기관 안내, 실무교재, 상담사례, 주민등록번호 사례집, 지방자치단체 사례집, 동의서 작성 가이드 등이 들어갔습니다.

총 14종 이상의 자료를 연결하면서 원칙을 하나 세웠습니다.

근거가 없으면 말하지 않는다.

예를 들어 주민등록번호는 단순히 사용자가 원한다고 받을 수 없습니다. 법률이나 대통령령 등에서 구체적으로 요구하거나 허용하는 경우가 아니면 처리할 수 없기 때문입니다. 그래서 작성기는 주민등록번호가 등장하면 근거 후보를 찾고, 없으면 문서 생성을 막도록 했습니다.

보유기간도 마찬가지였습니다. 사용자가 "잘 모르겠다"고 해도 작성기가 아무 기간이나 제안하면 안 됩니다. 법령상 보존기간이 있는지 먼저 찾고, 없으면 목적 달성에 필요한 최소 기간을 내부 기준으로 정하도록 안내해야 했습니다.

이 과정에서 AI의 역할이 바뀌었습니다. "문장을 만들어주는 도구"가 아니라 "자료를 대조하고 근거를 요구하는 도구"가 된 것입니다.

AI가 모르는 값을 지어내 채우는 문제를 막기

가장 중요한 전환점은 테스트 중에 나왔습니다.

음식점 사례로 개인정보 수집·이용 동의서와 제3자 제공 동의서를 만들어 보자고 했을 때, AI가 너무 잘했습니다. 목적, 항목, 제공받는 자, 보유기간까지 꽤 그럴듯하게 채워 넣었습니다.

문제는 바로 그 점이었습니다. 사용자가 말하지 않은 사실까지 AI가 샘플처럼 채워 넣은 것입니다. 샘플 문서로는 좋아 보이지만, 실제 업무에서는 위험합니다. 제공받는 자가 누구인지, 어떤 목적으로 제공되는지, 어떤 항목이 제공되는지는 실무자가 직접 확인해야 하는 사실입니다.

AI가 너무 잘 채워줘서 오히려 겁이 났습니다. 처음 요청은 "동의서를 만들어보자"에 가까웠지만, 이 순간부터 요청의 중심이 "확인 안 한 값은 넣지 마"로 바뀌었습니다.

이 문제를 보고 방향을 바꿨습니다.

진짜 실전처럼 해보자. 샘플만 이런식으로 찍어내는 것은 아무런 의미가 없어. 정말 자세하고 세밀하게 작성해야 해. 단계마다 강한 하네스 엔지니어링을 통해 해당 단계가 위법하지 않은지를 먼저 판단해야 하고, 다음 단계에서 필요한 사항이 무엇인지를 추천할 수 있어야 해.

그래서 "실전 작성 모드"를 넣었습니다.

추천값과 사용자 확정값을 분리했습니다. AI가 추천할 수는 있지만, 사용자가 직접 확인하지 않은 값은 최종 문서에 들어가지 못하게 했습니다. 목적, 항목, 보유기간, 제공받는 자, 제3자 제공 세부사항처럼 법적으로 중요한 값은 빈칸이면 생성이 보류되도록 했습니다.

이 프로젝트의 핵심은 여기였습니다.

AI를 더 자유롭게 만드는 것이 아니라, AI가 모를 때 멈추게 만드는 것.

고위험 업무에서는 이 차이가 매우 큽니다.

터미널 숫자 입력에서 체크박스 웹 작성기로

초기 테스트는 터미널에서 숫자를 입력하는 방식이었습니다. 개발자에게는 괜찮지만, 비법률가 실무자가 쓰기에는 불편했습니다. 무엇을 선택하면 어떤 법적 효과가 생기는지 한눈에 보기 어려웠기 때문입니다.

그래서 웹 작성기로 바꿨습니다.

이것을 체크박스로 해서 여러 개를 체크할 수 있도록 하면 어떨까? 만약 여기 터미널 창에서 구현하는 것이 어렵다면 웹앱으로 만들거나 다른 방식으로 구현하면 어때?

ALT

컴퓨터에 있는 한국어 페이지의 스크린샷

웹 작성기는 10단계 흐름으로 구성했습니다. 사용자는 먼저 업무 상황을 고르고, 개인정보처리자 성격을 확인하고, 정보주체와 처리 목적을 정하고, 필요한 항목과 보유기간, 동의 방법, 동의 블록을 차례로 확정합니다.

각 단계에는 추천 선택지가 붙었습니다. 예를 들어 음식점, 카페, PC방, 노래연습장처럼 개인정보 처리 방식이 비슷한 업종은 처리 유사 프로파일로 묶었습니다. 업종 이름만 전통적으로 비슷한 것이 아니라, 개인정보 서류를 유사하게 쓰는지 기준으로 묶은 것입니다.

또한 위험한 선택지는 바로 표시했습니다. 마케팅 목적 항목을 필수 동의에 묶으려 하면 경고가 뜨고, 주민등록번호처럼 법적 근거가 필요한 항목은 별도 검토가 필요하다고 안내합니다.

이 과정에서 여러 번 UI를 고쳤습니다. 추천 버튼이 눌리지 않는 문제, 글자가 잘리는 문제, 개발자 같은 "단계 검토" 화면, 마지막 단계에서 생성 보류가 뜨는 문제도 하나씩 잡았습니다.

좋은 안내는 한꺼번에 많은 설명을 주는 것이 아니라, 사용자가 선택하는 순간 그 선택의 의미와 위험을 보여주는 것이라는 점을 배웠습니다.

AI가 만든 계획을 다시 AI로 검증하기

작업이 커질수록 "이 구조가 정말 맞나?"라는 문제가 생겼습니다. 4단계와 6단계가 중복되는지, 5단계와 6단계 순서가 맞는지, 동의 방법 질문과 접수 방식 질문이 중복되는지 같은 논리 문제가 계속 나왔습니다.

ralph로 지금까지 했던 작업을 검증해서 개인정보 서류 작성 하네스를 논리적 정합성에 맞게 구성해줘.

이때는 별도 검증 루프를 돌렸습니다. AI가 세운 구조를 다시 AI에게 검토시키고, 사용자가 지적한 모순을 기준으로 하네스를 고쳤습니다.

특히 중요한 결론은 이것이었습니다.

사용자에게 모든 법률 판단을 맡기면 안 됩니다. 하지만 AI가 사용자의 의사를 무시하고 결론을 확정해서도 안 됩니다.

그래서 구조를 이렇게 잡았습니다.

사용자는 사실관계를 입력합니다. AI는 그 사실관계를 바탕으로 처리유형과 필요한 문서 블록을 자동 산정합니다. 사용자가 생각한 판단과 AI 판단이 다르면, AI가 조용히 덮어쓰는 것이 아니라 충돌을 표시하고 다시 확인하게 합니다.

이것이 이 작성기의 중요한 설계 원칙이 되었습니다.

✅ 결과 (After)

결과물은 단순한 동의서 생성기가 아니라, 단계별로 사실관계를 확인하고, 법적 위험을 표시하며, 확인되지 않은 값이 있으면 생성을 보류하는 개인정보 문서 작성기입니다.

Before vs After

결과물

완성된 작성기는 다음을 수행합니다.

• 개인정보 수집·이용 동의서 초안 생성

• 제3자 제공 동의서 초안 생성

• 업무위탁 안내와 위탁계약 검토 항목 안내

• 마케팅 선택 동의 분리

• 민감정보·고유식별정보·주민등록번호 위험 검토

• 법령상 보존기간 후보 확인

• 사용자가 확인하지 않은 사실이 있으면 생성 보류

• 생성된 문서를 화면에서 미리 보고, 문서 파일로도 저장

검증 방식도 함께 만들었습니다.

• 골든 케이스 19종으로 대표 시나리오의 기대 결과와 비교

• 일부러 위험 케이스를 넣어 반드시 차단되는지 확인

• 문서에 들어간 조문과 출처가 실제 자료와 연결되는지 검사

• 생성 문서의 중요 표시와 동의 블록 분리 여부 확인

• 웹 작성기에서 단계별 완료 상태가 실제 입력 완료와 맞는지 확인

다만 이것을 법률 전문가의 최종 검토를 대체하는 도구라고 보지는 않습니다. 자동 검증은 위험을 줄여주지만, 최종 법적 판단은 개인정보 보호책임자나 법률 전문가의 검토가 필요합니다. 이 점은 생성 문서에도 명시했습니다.

ALT

화면에 한국어가 표시됩니다

ALT

한국어 페이지 스크린샷

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

1. 먼저 AI에게 질문하게 하기

처음부터 "만들어줘"라고 하지 않고, AI가 나를 인터뷰하게 했습니다. 덕분에 사용자가 제공해야 할 사실과 AI가 판단해야 할 부분을 분리할 수 있었습니다.

2. 근거 자료를 먼저 먹이고, 출처 없으면 말하지 못하게 하기

법률 문서에서는 유창한 설명보다 출처가 중요합니다. 공식 자료를 조각내 연결하고, 판단마다 근거를 요구하니 환각 위험을 줄일 수 있었습니다.

3. 판단과 구현을 나누기

법률 판단은 일관되게 관리하고, 구현은 여러 AI에게 병렬로 맡겼습니다. 덕분에 속도와 통제력을 함께 가져갈 수 있었습니다.

4. 사용자 확정값과 AI 추천값을 분리하기

AI가 추천한 값은 편리하지만, 사용자가 확인하지 않은 사실은 문서에 들어가면 안 됩니다. 이 분리가 실전 도구와 샘플 생성기의 차이를 만들었습니다.

5. 테스트를 결과물이 아니라 안전장치로 보기

테스트는 개발자를 위한 형식적 절차가 아니라, "이 문서가 위험한 상황에서 멈추는가"를 확인하는 안전장치였습니다.

이렇게 하면 안 돼요

1. 예시 서식 하나를 만능처럼 쓰기

업종과 목적이 다르면 필수 항목, 제공받는 자, 보유기간, 동의 블록이 달라집니다.

2. 오래된 자료를 최신 확인 없이 신뢰하기

법령과 지침은 바뀝니다. 특히 개인정보보호법은 개정 이력이 많기 때문에 최신 공식 자료를 우선해야 합니다.

3. AI가 채운 값을 그대로 믿기

AI가 그럴듯한 제공받는 자, 목적, 보유기간을 써도 실제 사실과 다르면 문서 전체가 위험해질 수 있습니다.

4. 사용자에게 법률용어를 그대로 던지기

"제3자 제공인지 위탁인지 선택하세요"라고 묻는 것만으로는 부족합니다. 사용자는 사실관계를 말하고, 도구가 법적 분류를 도와야 합니다.

🌍 다른 업무에 적용한다면?

이 방식은 개인정보 동의서에만 쓰이는 방식이 아닙니다.

핵심은 세 가지입니다.

첫째, 공식 근거 자료를 먼저 정리한다.

둘째, 사용자가 확인해야 할 사실과 AI가 판단할 수 있는 부분을 나눈다.

셋째, 확인되지 않은 값은 AI가 채우지 못하게 막는다.

정리하면, 반복적으로 작성하고, 법령·기준 같은 규칙이 정해져 있으며, 텍스트 중심으로 결과물이 나오는 문서 업무라면 이 방식을 그대로 옮길 수 있습니다.

예를 들어 표준 근로계약서, 취업규칙, 하도급 계약서처럼 법정 필수기재사항이 많은 문서에도 비슷한 방식이 가능합니다. 관련 법령과 공식 지침을 근거 자료로 연결하고, 사용자가 사실관계를 입력하면, AI가 필요한 조항과 누락 위험을 검토하게 할 수 있습니다.

세무 신고, 의료 안내문, 보조금 신청서처럼 틀리면 손해가 큰 업무에도 적용할 수 있습니다. 이런 업무에서 중요한 것은 AI가 얼마나 많이 쓰느냐가 아니라, 모르는 것을 얼마나 잘 멈추느냐입니다.

즉, 고위험 AI 업무의 기준은 "자동 완성"이 아니라 "자동 제동"이어야 합니다.

다만 도입 장벽도 있습니다. 대화형 AI와 복붙만으로 작게 시작할 수는 있지만, 실무에 쓰려면 근거 자료를 준비하고 조직의 보안 규정과 전문가 검수 절차를 함께 세워야 합니다.

🚀 앞으로의 계획

다음 단계는 전문가 검수입니다.

자동 검증 배터리를 통과했다고 해서 바로 실무 배포가 끝나는 것은 아닙니다. 개인정보 보호책임자나 변호사가 실제 생성 문서와 판단 기준을 검토하고, 어떤 문구는 더 보수적으로 바꿔야 하는지 확인해야 합니다.

그다음에는 분야 확장이 가능합니다.

현재는 개인정보 동의서와 위탁, 제3자 제공, 주민등록번호, 보유기간 검토에 집중했습니다. 앞으로는 채용, 의료, 공공기관, 학원, 온라인 이벤트처럼 분야별로 더 세밀한 질문과 추천값을 붙일 수 있습니다.

마지막으로, 이 방식을 다른 법정 문서 작성기로 확장해보고 싶습니다. 개인정보 동의서에서 만든 원칙, 즉 "근거를 먼저 연결하고, 확인 안 된 값은 막고, 위험하면 멈추는 구조"는 다른 법률 문서에도 그대로 적용할 수 있기 때문입니다.

📋 재사용 가능한 프롬프트

프롬프트 1: 한 문장을 기획서로 바꾸기

[만들고 싶은 것]을 [근거 자료]를 바탕으로 만들고 싶어. 반드시 지킬 것: [핵심 제약 3가지]. 사용자는 [대상]이야. 바로 만들지 말고, 먼저 인터뷰식 질문으로 필요한 정보를 끌어낸 뒤 기획서부터 만들어줘. 특히 사용자가 입력해야 할 사실과 AI가 판단해도 되는 부분을 나눠줘.

프롬프트 2: AI가 지어내지 못하게 막기

[문서]를 작성하되, 내가 직접 확인하지 않은 값은 본문에 넣지 마. 네가 추천한 값과 내가 확정한 값을 분리하고, 확인 안 된 항목은 임의로 채우지 말고 "확인 필요"로 멈춰. 모든 판단에는 [근거 자료 또는 조문]을 붙이고, 근거가 불명확하면 문서 생성을 보류해줘.

프롬프트 3: 고위험 업무 검증 루프 만들기

[업무명]에 AI를 쓰려고 해. 틀리면 문제가 되는 지점을 먼저 찾아줘. 각 위험 지점마다 "사용자가 직접 확인해야 할 사실", "AI가 추천할 수 있는 값", "확인 없이는 멈춰야 하는 조건", "검증 방법"으로 나눠서 하네스를 설계해줘.