AI 계약 검토 도구를 만들면서 신뢰, 톤, 그리고 좁게 시작하는 것에 대해 배운 점
Source: Dev.to
Overview
사람들이 AI 계약 검토 도구에 대해 처음 들었을 때 보통 다음과 같은 반응을 보입니다:
“그거 간단해 보이네. 계약서를 업로드하고, 텍스트를 추출하고, 모델에게 설명하게 하면 돼.”
실제로는 전혀 간단하지 않습니다. WorkContractReview.com을 만들면서 계약 검토는 겉보기엔 단순해 보이지만 실제 사용자에게 신뢰성을 제공하려고 하면 복잡해진다는 것을 배웠습니다. 계약은 단순한 텍스트가 아니라 위험, 맥락, 모호성, 그리고 사용자 불안을 PDF 안에 담은 것입니다. 이 점이 모든 것을 바꿉니다.
Lesson 1: Start with One Contract Type
AI 제품을 만들 때 가장 큰 실수 중 하나는 겉보기 비슷한 작업들이 실제로는 같은 작업이라고 가정하는 것입니다. 고용 계약, 프리랜서 계약, NDA, 컨설팅 계약, 그리고 오퍼 레터는 충분히 비슷해 보여서 하나의 일반화된 워크플로우로 처리할 수 있을 것처럼 보이지만, 그 가정은 금방 깨집니다.
- 각 문서 유형마다 구조, 핵심 조항, 사용자 기대치, 위험 수준이 다릅니다.
- 한 계약에 잘 작동하는 동일한 모델 프롬프트가 다른 계약에서는 모호하거나 과도하게 조심스럽거나 오해를 일으킬 수 있습니다.
왜 좁게 시작해야 할까?
하나의 계약 유형에 집중하면 그 분야에 매우 능숙해질 수 있습니다. 신뢰는 일관성을 통해 구축됩니다—한 사용 사례에 잘 작동하는 도구가 열 개에 대충 작동하는 도구보다 더 가치가 있습니다. 조기 일반화는 제품의 취약성을 초래합니다.
Lesson 2: Tone Is Part of the Product
출력의 톤은 처음 생각했던 것보다 더 중요합니다. 사용자는 단순히 정보를 원하지 않고, 그 정보가 명확하고, 근거가 있으며, 유용하게 전달되길 원합니다.
- 너무 중립적 → 출력이 일반적으로 느껴짐.
- 너무 격식적 → “법률 로봇”.
- 너무 캐주얼 → “AI 어시스턴트”.
가장 적절한 지점은 지식이 풍부한 친구가 무엇에 주의를 기울여야 하는지 알려주는 것입니다. 이를 위해 모델은 다음을 해야 합니다:
- 위험을 적절한 무게로 전달 (예: 비경쟁 조항 vs. 수습 기간).
- 조항 종류에 따라 톤을 달리함 (표준 기밀 유지 vs. 일방적인 계약 해지).
프롬프트 설계만으로는 충분하지 않습니다. 필요합니다:
- 반복과 피드백 루프.
- 실제 출력 검토.
- 품질 체크: 이것이 신뢰할 만한가?
UX 라이터와 모델 행동은 긴밀히 연결돼 있습니다—톤은 장식이 아니라 제품 디자인의 일부입니다.
Lesson 3: PDF Extraction Is Not a Minor Detail
많은 AI 데모는 텍스트가 이미 깨끗하게 정리된 상태에서 시작하지만, 실제 사용자는 다음과 같은 파일을 업로드합니다:
- 스캔된 PDF
- 저품질 추출본
- 휴대폰 카메라 촬영본
- 부분적으로 손상된 파일
- 형식이 일관되지 않은 문서
추출 레이어가 조항을 망가뜨리면, LLM은 결함이 있는 텍스트를 자신 있게 분석해 겉보기엔 깔끔하지만 실제로는 부정확한 출력을 생성합니다. 이러한 무음 실패 모드는 눈에 보이는 충돌보다 더 위험합니다.
추출 품질을 핵심 제품 문제로 다루세요:
- 불확실성을 조기에 감지.
- 낮은 신뢰도의 추출을 명확히 표시.
- 분석이 완벽한 입력에서 이루어진다고 가장하지 않기.
사용자에게는 신뢰성 없는 자신감이 제한 메시지보다 더 나쁩니다.
The Real Product Is Trust
WorkContractReview.com을 구축하는 것은 사용자가 개인적인 이해관계가 걸린 상황에서 신뢰할 수 있는 시스템을 만드는 일입니다. 업무 계약은 수입, 의무, 유연성, 그리고 미래 옵션에 영향을 미칩니다. 사용자는 속도를 원하지만, 더 중요한 것은 명확성입니다.
이 전환—모델의 지능을 과시하는 것보다 모호성을 줄이는 데 집중하는 것—이 저에게 가장 큰 교훈이었습니다.