회의 전날, 같은 안건을 두고 온 문서가 세 개쯤 열리면 눈은 이미 문단 사이를 왕복하고 있습니다. 이때 필요한 것은 ‘누가 맞는지’ 판정하는 AI가 아니라, 같은 문장·서로 다른 문장·아직 답이 없는 질문을 같은 표에서 보게 하는 작은 도구입니다. 붙여넣은 텍스트를 서버로 보내지 않는 단일 HTML MVP라면 비개발자도 바이브코딩으로 시작할 수 있습니다.
30초 요약
- 여러 문서를 입력칸에 붙여넣고, 문장 단위로 나눠 비교합니다.
- 두 문서 이상에 겹치는 문장은 공통점, 한 문서에만 있으면 차이점으로 표시합니다.
- ‘확인’, ‘결정’, ‘근거’, ‘기한’ 같은 단어가 든 문장은 확인할 쟁점 후보로 따로 모읍니다.
- 이 결과는 의미를 판정한 결론이 아니라, 사람이 다시 읽을 위치를 줄이는 규칙 기반 초안입니다.
이걸 만들면 무엇이 달라질까요?
문서 A에는 “외부 공개 전 법무 검토가 필요하다”고 적혀 있고, 문서 B에는 일정만 적혀 있다고 해보겠습니다. 기존에는 두 탭을 오가며 같은 내용을 형광펜으로 찾고, 빠진 조건을 메모장에 다시 적어야 합니다.
이 도구는 문장을 정리한 뒤 한 번 이상 나온 문장과 한 번만 나온 문장을 표로 나눕니다. 공통점은 합의의 출발점으로, 차이점은 확인할 대화의 출발점으로 보게 됩니다.
예시 데이터 · 비교 결과 화면
| 구분 | 문장 | 출처 | 다음 행동 |
|---|---|---|---|
| 공통점 | 공개 전 검토가 필요하다 | 문서 A, B | 검토 담당 확인 |
| 차이점 | 공개 일정은 금요일이다 | 문서 B | 일정 근거 대조 |
| 확인 쟁점 | 법무 검토 기한은? | 문서 A | 담당자에게 질문 |
이 표는 작동하는 앱이 아니라 글 안에서 결과 모양을 설명하는 예시 화면입니다. 실제 도구는 아래 프롬프트와 코드로 만들며, “공통”이라는 표시는 문장 정규화 뒤 동일한 문장이 두 문서 이상에 나온다는 뜻입니다.
왜 ‘의미 비교’라고 부르면 위험할까요?
“검토는 필요하다”와 “검토를 거친다”는 사람에게 비슷해 보여도, 아래 MVP는 같은 문장으로 보지 못합니다. 반대로 쉼표와 공백만 다른 문장은 같은 문장으로 묶을 수 있습니다.
이 MVP의 표는 결론표가 아니라 재검토 목록입니다. 계약, 인사, 법률처럼 표현 하나가 중요한 자료는 원문과 표를 함께 보고 담당자가 최종 판단해야 합니다. 이 경계를 프롬프트에 먼저 넣어야 AI가 그럴듯한 판정을 과장하지 않습니다.
문장을 웹 화면에 다시 보여 줄 때도 입력값을 HTML로 해석시키면 안 됩니다. OWASP는 신뢰하지 않은 입력을 검증·인코딩 없이 동적 콘텐츠에 넣는 경우 스크립트 주입 위험이 생길 수 있다고 설명합니다. 그래서 코드에서는 innerHTML 대신 textContent로 셀 내용을 넣습니다.
AI에게 처음 붙여넣을 프롬프트
바이브코딩은 코드를 처음부터 외우는 일이 아니라, 원하는 화면과 규칙을 구체적으로 설명하고 결과를 작은 단위로 확인하는 방식입니다. 아래 프롬프트는 서버 없이 단일 HTML로 시작하는 범위를 고정합니다. 받은 코드는 opinion-compare.html이라는 이름으로 저장하면 됩니다.
외부 라이브러리와 서버 없이 단일 HTML 파일을 만들어줘.
목적: 여러 문서의 의견을 붙여넣으면 공통점, 차이점, 확인할 쟁점을 표로 보여 주는 로컬 MVP.
화면: 문서 제목 입력칸과 여러 줄 텍스트 입력칸을 최대 5개 제공하고, ‘비교하기’와 ‘결과를 TXT로 저장’ 버튼을 둬.
규칙: 줄바꿈·마침표·물음표·느낌표로 문장을 나누고, 앞뒤 공백과 연속 공백을 정리해 비교해. 같은 문장이 2개 이상 문서에 있으면 공통점, 1개 문서에만 있으면 차이점으로 표시해. ‘확인’, ‘결정’, ‘근거’, ‘기한’, ‘담당’, ‘예산’이 들어간 문장은 확인할 쟁점 후보 표에도 보여 줘.
안전: 붙여넣은 문장을 화면에 넣을 때 innerHTML을 쓰지 말고 textContent를 사용해. 서버 요청, API 호출, 자동 저장, localStorage는 사용하지 마.
결과: 표에 구분, 문장, 나온 문서, 다음 확인을 표시하고, 빈 입력·문서 2개 미만일 때 이해하기 쉬운 오류 문구를 보여 줘. 모바일에서도 표를 가로 스크롤로 읽을 수 있게 해.
첫 프롬프트의 핵심은 ‘AI가 뜻을 알아서 비교한다’고 쓰지 않는 데 있습니다. 비교 기준을 문장 중복과 키워드로 제한해야 결과가 틀렸을 때 어디를 고칠지도 보입니다.
완성 화면에서 무엇을 확인하면 성공일까요?
저장한 파일을 더블클릭해 브라우저에서 엽니다. 제목이 “문서 1”, “문서 2”인 입력칸이 보이고, 각 칸에 짧은 예시를 붙여넣을 수 있으면 첫 화면은 성공입니다.
다음처럼 두 문서를 넣고 비교 버튼을 누릅니다. 이 예시는 문서 기반 예상 동작이며, AI가 만든 코드의 실제 결과는 아래 기준으로 직접 대조해야 합니다.
문서 1
공개 전 검토가 필요하다.
법무 담당을 확인한다.
문서 2
공개 전 검토가 필요하다.
공개 일정은 금요일이다.
기대하는 표에는 “공개 전 검토가 필요하다”가 공통점으로, 나머지 두 문장은 차이점으로 나타나야 합니다. 문서 이름이 결과 표에 함께 보이면, 나중에 원문으로 돌아갈 길도 남습니다.
비교 로직은 이 정도면 충분합니다
textarea는 여러 줄의 자유 텍스트를 받는 HTML 입력 요소입니다. 문서를 문장 배열로 바꾼 뒤 출처를 함께 기록하는 것이 이 비교의 핵심입니다.
아래 코드는 AI가 준 결과에서 비교 핵심이 보이지 않을 때 교체해 달라고 요청할 수 있는 최소 함수입니다. 실행 위치는 opinion-compare.html의 <script> 태그 안이며, 코드 블록 전체를 복사합니다.
function splitSentences(text) {
return text
.split(/[\n.!?]+/)
.map(sentence => sentence.replace(/\s+/g, ' ').trim())
.filter(Boolean);
}
function buildIndex(documents) {
const index = new Map();
documents.forEach(({ title, text }) => {
[...new Set(splitSentences(text))].forEach(sentence => {
const sources = index.get(sentence) ?? [];
sources.push(title);
index.set(sentence, sources);
});
});
return index;
}
new Set()은 같은 문서 안에서 같은 문장이 두 번 나와도 출처를 한 번만 남기게 합니다. 여러 문서에 반복된 문장을 찾는 데는 충분하지만, 동의어나 숫자 표기 차이까지 연결해 주지는 않습니다.
결과가 어색할 때는 이 수정 프롬프트를 쓰세요
첫 결과에서 공통점 표가 비거나, 문장이 너무 길게 붙는 일은 흔합니다. 눈으로 본 현상과 바꿀 규칙을 함께 전달하면 수정 범위가 작아집니다.
현재 단일 HTML에서 비교 결과는 나오지만, 줄바꿈만 다른 같은 문장이 분리됩니다.
기존 기능을 지우지 말고 splitSentences 함수만 고쳐줘.
연속 공백은 하나로 만들고, 문장 끝의 마침표는 비교 전에 제거해. 다만 결과 표에는 사람이 읽기 쉬운 원문 문장을 그대로 보여 줘.
또한 확인 쟁점 표의 키워드는 대소문자 구분 없이 찾고, 각 행에 ‘원문에서 다시 확인’이라는 다음 행동을 표시해.
수정한 전체 HTML을 한 파일로 다시 출력하고, 바뀐 함수 위에 짧은 주석을 달아줘.
수정은 한 번에 한 규칙만 바꾸는 편이 원인을 찾기 쉽습니다. 표 색상, 입력칸 수, 문장 분리 규칙을 한꺼번에 요구하면 어느 변경이 결과를 흔들었는지 알기 어렵습니다.
문서가 밖으로 나가지 않는다고 바로 안심하면 안 됩니다
이 글의 MVP는 서버 요청·외부 API·자동 저장을 넣지 말라고 지시합니다. 그 조건을 지키면 붙여넣은 텍스트를 별도 서비스로 보내지 않는 구조를 만들 수 있습니다.
다만 브라우저 확장 프로그램, 회사 기기 정책, AI에게 프롬프트로 전달한 원문은 별개의 문제입니다. 민감한 이름·계약 금액·개인정보는 넣기 전에 가리고, 회사 보안 규정이 있다면 그 규정을 먼저 따르는 것이 기준입니다.
브라우저에 내용을 남기고 싶어 localStorage를 추가하고 싶을 수 있지만, MDN은 이 저장소가 브라우저 세션을 넘어 남을 수 있고 file: URL에서의 동작은 보장되지 않는다고 설명합니다. 처음 버전은 저장 기능을 빼고, 필요가 확인된 뒤 회사 환경에 맞는 저장 방식을 별도로 결정하는 편이 낫습니다.
파일로 저장할 때와 안 될 때
결과를 회의 메모에 옮겨야 한다면 텍스트 다운로드가 편합니다. Blob은 생성한 비교표를 텍스트로 내려받는 기능에 쓸 수 있습니다.
하지만 이 기능이 문서 형식 보존까지 해결하는 것은 아닙니다. 표 모양이 꼭 필요하면 우선 화면에서 복사해 문서 도구에 붙여넣고, TXT 저장은 비교 기록을 남기는 보조 수단으로 두는 편이 단순합니다.
이 도구가 잘 맞는 경우와 아닌 경우
회의 안건, 제안서 초안, 인터뷰 메모처럼 “어떤 문장이 반복되고 무엇이 빠졌나”를 빠르게 훑는 작업에는 잘 맞습니다. 문서 수가 많아도 비교 기준이 눈에 보인다는 점이 장점입니다.
반대로 법률 해석, 의료 판단, 계약 조항의 동치 판단처럼 단어 하나의 무게가 큰 자료에는 맞지 않습니다. 문장 중복 표를 사람의 최종 판단으로 바꾸지 않는 것이 이 도구의 가장 중요한 사용 조건입니다.
작업 환경을 함께 정리한다면
문서 입력칸과 결과표를 나란히 대조하는 일이 잦다면, 아래 두 카드만 작업 보조 관점에서 검토할 수 있습니다. 제품의 세부 모델·호환성·가격은 카드에서 직접 확인하고, 이미 있는 장비로 충분하다면 추가 구매는 필요 없습니다.
문서 입력과 결과표를 나란히 놓고 대조하는 용도라면 휴대용 모니터가 ‘핵심 실행’ 보조가 될 수 있습니다. 카드의 실제 연결 방식과 조건은 구매 전에 확인해야 합니다.
문서 창과 결과표를 번갈아 확인하는 편이라면 멀티페어링 마우스는 ‘준비·편의’ 역할입니다. 이 글의 비교 규칙을 대신하는 제품은 아니며, 입력과 대조 환경을 보완하는 선택지입니다.
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
출처
- MDN,
<textarea>HTML textarea element — 여러 줄 텍스트 입력과 JavaScriptvalue속성 확인. - MDN,
Window: localStorage property— 저장 지속성과file:URL의 동작 경계 확인. - MDN,
Blob— 문자열 데이터를 파일 같은 객체로 다루는 API 설명 확인. - OWASP Foundation, Cross Site Scripting (XSS) — 신뢰하지 않은 입력을 동적 HTML에 넣을 때의 위험 확인.
핵심 정리: 다섯 가지 질문과 답
Q. 여러 문서의 뜻을 AI처럼 판정하나요?
아닙니다. 이 MVP는 문장 중복과 지정 키워드로 다시 볼 위치를 표시합니다.
Q. 첫 파일에는 무엇이 꼭 있어야 하나요?
문서 입력칸, 비교 버튼, 공통점·차이점·확인 쟁점 표, 빈 입력 오류 문구면 충분합니다.
Q. 결과가 이상하면 어디부터 고치나요?
문장 분리와 공백 정리 규칙부터 한 가지씩 수정합니다.
Q. 붙여넣은 문장은 안전한가요?
서버 전송을 넣지 않은 MVP라도 민감정보를 가리고 회사 보안 규정을 먼저 따라야 합니다.
Q. 이 표만 보고 결론을 내려도 되나요?
아닙니다. 특히 계약·법률·의료처럼 표현의 무게가 큰 문서는 반드시 원문과 담당자 판단을 함께 확인합니다.
글을 읽어 주셔서 감사합니다.
이 글이 도움이 되었고 새로운 정보를 계속 받아보고 싶으시다면 구독해 주세요.
댓글