핵심 요약
AI를 “똑똑한 채팅 상대”로만 쓰고 있다면, AI 활용의 10%도 못 쓰고 있는 셈이다. 나는 개발자가 아닌 법무팀 리드다. 하지만 지금 계약서 검토, 블로그 운영, 심지어 연동 도구 개발까지 AI 에이전트 기반 시스템으로 돌리고 있다. 이 글은 “프롬프트를 잘 쓰는 법”이 아니라, AI에게 업무 매뉴얼을 줘서 시스템을 만드는 법에 대한 실전 경험기다.
“매번 처음 만나는 사이”가 된 AI
처음 AI를 업무에 쓰기 시작했을 때, 정말 똑똑하다고 느꼈다. 계약서 조항의 리스크를 물어보면 생각지도 못한 관점에서 분석해주고, 블로그 글 초안도 30분이면 뚝딱 만들어줬다.
그런데 문제는 다음 날이었다. 어제 했던 이야기를 오늘 다시 해야 했다. “우리 회사는 플랫폼 회사이고, 계약서 검토 시 중점적으로 봐야 하는 조항은…”부터 다시. 매번 처음 만나는 사이처럼.
블로그 글도 마찬가지였다. “톤은 전문가인데 친근하게, 출처는 반드시 달아줘, 법률 내용이면 조문 번호 꼭 넣어줘”를 매번 타이핑했다. 한 편 쓰는 건 괜찮은데, 매주 꾸준히 같은 품질로 만들어내는 건 채팅만으로는 불가능하다는 걸 깨달았다.
전환점: “프롬프트” 대신 “업무 매뉴얼”을 줬더니
전환점은 AI에게 매번 말로 지시하는 대신, 텍스트 파일로 업무 매뉴얼을 써서 넘기면 어떨까?라는 생각이었다. (참고로 내가 사용하는 도구는 Anthropic의 Claude다. 하지만 다른 Gemini 등 다른 AI를 사용하는 사람들에게도 적용되는 규칙이다.)
마크다운(.md) 파일에 이런 것들을 적었다:
- 이 프로젝트가 뭔지 (배경, 목표, 끝그림)
- AI가 지켜야 할 규칙 (출처 표기 방식, 톤, 금지사항)
- 작업 순서 (리서치 → 초안 → 검증 → 결과물 작성)
- 사람이 개입하는 지점 (어디서 내 승인을 받아야 하는지)
비유하자면, 신입 직원에게 주는 “업무 인수인계서”를 AI용으로 만든 거다. 이걸 프로젝트마다 하나씩 만들어 두면, AI는 세션이 바뀌어도 이 파일을 읽고 “아, 이 프로젝트는 이렇게 하면 되는구나”를 스스로 파악한다.
결과는 기대 이상이었다. 같은 질문을 반복할 필요가 없어졌고, 산출물의 일관성이 눈에 띄게 올라갔다. 그리고 이 방식이 블로그 운영에만 적용되는 게 아니라는 걸 알게 됐다.
실전 사례 ① 법무: AI가 가장 “위험한” 영역에서 쓰는 법
나는 회사에서 계약서 검토, 법률자문, 분쟁 대응 같은 법무 업무를 한다. 법무는 AI 활용이 가장 매력적이면서 동시에 가장 위험한 영역이기도 하다.
왜 위험한가? AI는 존재하지 않는 판례를 자신 있게 인용한다. 스탠퍼드 대학 HAI 연구(2024)에 따르면, AI 모델은 법률 질의에서 6건 중 1건 이상 할루시네이션(허위 정보 생성)을 보였다. 법률 전문 AI 도구도 예외가 아니다. Lexis+ AI와 같은 전문 법률 리서치 도구조차 17% 이상의 오류율을 기록했다.
이게 무슨 뜻이냐면, AI에게 “이 계약서 검토해줘”라고 채팅으로 물어보면 그럴듯한 답이 나오지만, 그 안에 있는 법령 번호나 판례 사건번호가 아예 존재하지 않는 것일 수 있다는 거다.
“틀리지 마”는 통하지 않는다
내가 배운 건, AI에게 “틀리지 마”라고 말하는 건 의미가 없다는 것이다. 대신 “틀릴 수 있는 구간을 미리 설계”해야 한다. 나는 법무 업무 매뉴얼에 이런 규칙들을 박아넣었다.
규칙 1 — 사실 추론 금지: 확인되지 않은 사실을 마치 확정된 것처럼 서술하지 않는다. 불확실한 정보에는 반드시 [미검증], [추정] 태그를 붙인다.
규칙 2 — 출처 없는 인용 차단: 법령은 조문 번호, 판례는 사건번호를 반드시 명시한다. 출처를 확인할 수 없으면 “출처 미확인”이라고 적는다.
규칙 3 — 3단 구조 강제: 사실 확인 → 법적 분석 → 결론의 순서를 지킨다. AI가 멋대로 결론부터 내리는 걸 막기 위한 장치다.
AI로 AI를 검증한다
여기서 한 발 더 나아갔다. AI는 나보다 똑똑하지만, 나보다 실수도 훨씬 많이 한다. 그래서 AI가 만든 결과물을 AI 스스로 재검증하는 단계를 넣었다.
계약서 검토 의견을 작성하면, 바로 “이 분석에 논리적 약점이 있다면 무엇인가? 반론을 제기해봐”라고 지시한다. 이건 내가 채팅에서 매번 수동으로 하는 게 아니라, 업무 매뉴얼에 검수 단계로 미리 포함되어 있다. AI가 초안을 쓰면 → 스스로 팩트체크 → 스스로 반론 제기 → 그 결과를 합쳐서 최종본을 제출하는 구조다.
법률 문서에서 AI 환각이 심각한 문제라는 건 업계 공통 인식이다. 호주의 법률 연구자 다미엔 샤를로탱(Damien Charlotin)은 법원에서 AI가 만들어낸 허위 인용이 적발된 사례를 추적하는 데이터베이스를 운영하고 있으며, 현재 1,200건이 넘는 사례가 수집되어 있다. “AI를 믿지 않되, AI를 활용해서 AI를 검증한다” — 이것이 법무에서 AI를 쓰는 유일하게 안전한 방법이라고 생각한다.
실전 사례 ② 콘텐츠: “한 편”이 아니라 “시스템”을 만든다
블로그 운영에서도 같은 방법론을 적용했다. 나는 워드프레스(메인)와 네이버 블로그(서브)를 병행 운영하는데, 각 플랫폼의 목적이 완전히 다르다.
워드프레스는 AI를 위한 글이다. 구글, Perplexity, ChatGPT 같은 AI 검색엔진이 답변의 소스로 인용할 수 있는 구조를 만든다. 출처와 통계를 꼼꼼히 달고, 질문형 헤딩을 쓰고, 구조화된 계층(H1→H2→H3)을 지킨다.
네이버 블로그는 사람을 위한 글이다. 같은 주제를 다루되, 경험담 중심으로 톤을 완전히 바꾼다. “법원 판례에 따르면”이 아니라 “실제로 겪어보니”의 느낌이다.
이 구분이 왜 중요한가? 프린스턴 대학 연구에 따르면, 검증 가능한 통계와 명시적 출처가 포함된 콘텐츠는 AI 검색에서의 가시성이 30~40% 더 높다. 이것이 바로 GEO(Generative Engine Optimization)의 핵심이다. 기존 SEO가 구글 검색 순위를 올리는 기술이었다면, GEO는 AI가 당신의 콘텐츠를 답변의 출처로 선택하게 만드는 기술이다.
사람이 개입하는 지점을 설계한다
이 워크플로우에서 내가 직접 하는 일과 AI가 하는 일은 명확히 나뉘어 있다:
AI가 하는 일: 주제 리서치, 법령·판례 확인, 초안 작성, GEO 최적화 구조 적용, 워드프레스에 초안(draft) 상태로 업로드
내가 하는 일: 최종 내용 검토, 사진과 영상 삽입, 발행(publish) 버튼 클릭
핵심은 AI가 만든 초안이 바로 발행되는 게 아니라, 반드시 “초안” 상태로만 올라간다는 거다. 나는 실제 블로그 화면에서 미리보기를 확인하고, 필요한 이미지를 넣고, 내용을 최종 점검한 후에야 발행한다. 이 “승인 게이트”가 없으면 AI의 실수가 그대로 독자에게 전달된다.
실전 사례 ③ 도구가 없으면 만든다
여기서 “나는 개발자가 아닌데?”라는 생각이 들 수 있다. 나도 그랬다.
법무 업무를 하다 보면 한국 법령과 판례를 자주 검색해야 한다. 그런데 AI에게 “민법 제750조가 뭐야?”라고 물으면 정확한 답이 올 때도 있고, 완전히 엉뚱한 답이 올 때도 있다. AI의 학습 데이터에 최신 법령이 포함되어 있지 않을 수도 있고, 있더라도 할루시네이션이 발생할 수 있으니까.
그래서 법제처 국가법령정보센터와 대법원 종합법률정보에 직접 접속해서 데이터를 가져오는 연동 도구(MCP 서버)를 만들었다. AI가 법령을 “기억”에서 꺼내는 게 아니라, 실시간으로 공식 데이터베이스를 조회해서 가져오는 거다. 비유하자면, AI에게 “알고 있는 걸 말해봐” 대신 “이 도서관에서 찾아서 읽어봐”라고 시킨 것이다.
“비개발자가 어떻게 그런 걸 만들어?”라는 질문이 당연히 나온다. 나도 비개발자라 아무것도 모르기 때문에 그냥 AI한테 다 만들어달라고 했다. 내가 한 건 “법제처 사이트에서 법령을 검색하고 조문 내용을 가져오는 도구가 필요해. MCP로 연결할 수 있게 만들어줘”라고 요구사항을 명확히 전달한 것 뿐이고, 실제 코드는 AI가 작성했다. 물론 한 번에 완성되지는 않았고, 오류를 잡아가면서 수차례 수정했지만, “무엇이 필요한지”를 정의할 수 있으면 “어떤 점에 개선이 필요하고, 어떻게 만드는지”는 AI가 해결해줄 수 있다는 걸 경험했다.
Gartner는 2026년까지 기업 애플리케이션의 40%가 작업 특화 AI 에이전트를 탑재할 것으로 전망했다. 2025년 기준 5% 미만이었으니, 1년 만에 8배 증가 예측이다. 이 흐름에서 중요한 건 “코드를 짤 수 있느냐”가 아니라 “자기 업무에서 AI가 채워줄 빈 칸이 어디인지 정확히 아느냐”다.
채팅에서 시스템으로 넘어가기 위한 3가지 원칙
지금까지의 경험을 정리하면 세 가지로 압축된다.
1. 업무를 텍스트로 정리하라
AI 에이전트의 핵심은 코드가 아니라 업무 매뉴얼이다. 자신의 업무가 어떤 순서로 진행되는지, 어떤 규칙을 따르는지, 어디서 판단이 필요한지를 텍스트 파일로 정리할 수 있다면, 에이전트를 만들 준비가 된 거다. 많은 사람들이 “어떤 AI 도구를 쓸까”에서 막히지만, 진짜 병목은 자기 업무를 구조화하는 첫 번째 단계에 있다.
2. AI가 틀려도 되는 구간과 안 되는 구간을 나눠라
AI는 리서치와 초안 작성에는 탁월하지만, 최종 판단과 사실 확인은 여전히 사람의 영역이다. “어디까지 자동으로 돌리고, 어디서 내가 확인할 것인가”를 명확히 정하지 않으면, AI의 실수가 그대로 결과물이 된다. 나는 모든 워크플로우에 “승인 게이트” — AI가 임의로 넘어갈 수 없는 사람 확인 지점 — 을 두고 있다.
3. 한 번에 다 만들려 하지 말고 하나씩 쌓아라
나도 처음부터 이 시스템을 설계한 게 아니다. 채팅으로 시작했고, 반복이 짜증 나서 파일로 정리하기 시작했고, 하나의 프로젝트에서 성공하니 다른 프로젝트에도 같은 방식을 적용했다. 블로그 운영에 쓰던 구조를 법무에 가져오고, 법무에서 배운 검증 체계를 다시 블로그에 적용하는 식으로 점진적으로 확장했다.
마무리: 자동화의 시작은 AI가 아니라 “내 업무”
많은 사람들이 “AI를 어떻게 써야 하지?”라는 질문에서 출발한다. 하지만 내 경험상 올바른 질문은 “내 업무를 어떻게 정리하지?”다.
업무를 체계적으로 정리할 수 있다면, 그것을 AI에게 전달하는 건 마크다운 파일 하나로 충분하다. 코딩 실력이 필요한 게 아니라, 자기 일을 정확히 아는 것이 필요하다.
지금 AI와 채팅하면서 “아, 또 처음부터 설명해야 하네”라고 느낀 적이 있다면, 그 “설명”을 파일로 한 번만 적어보길 권한다. 그게 시스템의 시작이다.
참고 자료
- Stanford HAI, “AI on Trial: Legal Models Hallucinate in 1 out of 6 (or More) Benchmarking Queries” — 원문 링크
- Damien Charlotin, AI Hallucination Cases Database (1,200건+ 법원 사례 추적) — 원문 링크
- Princeton/Georgia Tech/IIT Delhi, “GEO: Generative Engine Optimization” (ACM KDD 2024) — 원문 링크
- Gartner, “40% of Enterprise Apps Will Feature AI Agents by 2026” (2025.08) — 원문 링크
답글 남기기