AI 텍스트 탐지기를 처음부터 직접 구축하며 배운 점 — 고난의 길을 먼저 택하며 얻은 교훈

고난의 길

Aidetector를 출시하기 전, 저는 2주 동안 AI 탐지를 수동으로 수행했습니다.

농담이 아닙니다. 한 클라이언트가 AI가 생성한 콘텐츠인지 확인하기 위해 블로그 포스트 묶음을 검토해 달라고 요청했는데, 믿을 만한 무료 도구가 없었습니다. 그래서 저는 고집스럽고 약간 과신하는 개발자들이 하는 방식대로, 논문들을 읽기 시작했습니다.

저는 AI 글쓰기 패턴에 관한 연구 자료를 수집했습니다. 스프레드시트를 열었습니다. 그리고 다음과 같은 요소들에 표시를 했습니다:

• 문장 길이의 분산 (Sentence length variance) (AI 텍스트는 의심스러울 정도로 균일합니다)
• 완곡한 표현(Hedging language)의 과도한 사용 ("it is important to note that..." 등)
• 문단 전환 시의 낮은 어휘 다양성 (Low lexical diversity)
• 예측 가능한 의미 구조 (Predictable semantic structure) — 주제문, 세 가지 뒷받침 문장, 마무리

저는 12점 척도의 루브릭(rubric)을 사용하여 문서를 수동으로 채점했습니다. 기사 한 편당 약 20분이 걸렸습니다. 총 40편의 기사를 대상으로 말이죠.

그때 생각했습니다: 이것은 도구가 되어야 한다.

구축 이유

당시 대부분의 무료 AI 탐지기들은 다음과 같은 문제가 있었습니다:

1. 500단어로 제한됨 (긴 글(long-form content)에는 무용지물)
2. 회원가입이나 API 키를 요구함
3. 무엇을 실제로 확인하고 있는지에 대한 투명성 없이 단일 휴리스틱(heuristic)으로 작동함

저는 완전히 브라우저에서 실행되고, 추론 과정을 설명하며, GPT-5 및 Claude 3.7과 같은 최신 모델을 지원하고, 단어 수 제한이 없는 것을 원했습니다. 백엔드(Backend)도, 사용자 데이터도, 불필요한 절차도 없는 것 말이죠.

기술 스택

전체 시스템은 클라이언트 사이드(client-side)에서 실행됩니다:

• Vanilla JavaScript — 프레임워크 오버헤드 없이 빠른 DOM 조작만 사용
• HTML/CSS — 가볍고 접근성 있게 유지
• 외부 API 미사용 — 모든 것이 브라우저 내에서 로컬로 계산됨

탐지 로직은 발표된 NLP(자연어 처리) 연구에서 도출된 12가지 언어 패턴 검사를 실행합니다. 여기에는 다음이 포함됩니다:

- 버스티니스 점수 (Burstiness score, 문장 길이의 분산)
- 퍼플렉시티 근사치 (Perplexity approximation, 단어 예측 가능성 휴리스틱)
- 완곡한 문구 빈도 (Hedging phrase frequency)
...

각 검사는 가중치가 적용된 점수를 반환합니다. 최종 결과는 복합적인 신뢰도 백분율(confidence percentage)로 나타나며, 사용자가 도구가 왜 특정 부분을 플래그(flag)했는지 실제로 확인할 수 있도록 세분화되어 제공됩니다.

기술적 과제

1. LLM 없이 당혹도 (Perplexity) 근사화하기

진정한 당혹도 (Perplexity)를 측정하려면 토큰 확률을 계산할 언어 모델 (Language Model)이 필요합니다. 저에게는 백엔드 (Backend)가 없었기 때문에, 선별된 코퍼스 (Corpus)를 기반으로 구축한 트리그램 (Trigram) 빈도 조회를 사용하여 이를 근사화했습니다. 완벽하지는 않지만, 제가 중요하게 생각하는 패턴들에 대해서는 방향성 측면에서 정확합니다.

2. 기술 문서에서의 오탐 (False Positives) 방지

기술 문서는 본질적으로 문장 변동성이 낮고 격식 있는 구조를 가집니다. 이는 제 탐지기가 정확히 AI로 플래그(flag)하던 특성이었습니다. 저는 도메인 특화 어휘 밀도를 감지하고 그에 따라 점수를 조정하는 문맥 인식 예외 레이어 (Context-aware exemption layer)를 추가해야 했습니다.

3. 새로운 모델에 발맞추기

GPT-5와 Claude 3.7은 이전 모델들과 확연히 다르게 글을 씁니다. 저는 새로운 샘플 세트를 수집하고 여러 휴리스틱 (Heuristics)의 가중치를 다시 조정해야 했습니다. 이는 지속적인 보정 (Calibration) 문제이며, 모델이 발전함에 따라 패턴도 변화합니다.

배운 점

처음부터 어려운 길을 택한 것이 실제로 유용했습니다. 자동화하기 전에 수동 루브릭 (Manual rubric)을 만드는 과정은 문제 영역 (Problem domain)을 깊이 이해하도록 강제했습니다. 저는 단순히 다른 사람의 API를 연결하는 것이 아니라, 제가 무엇을 왜 탐지하고 있는지 실제로 파악할 수 있었습니다.

투명성이 신뢰를 구축합니다. 어떤 패턴이 트리거(trigger)되었고 그 이유가 무엇인지 사용자에게 보여주는 것이 가장 찬사를 받은 기능이었습니다. 사람들은 블랙박스 (Black box) 형태의 백분율을 원하지 않습니다. 그들은 추론 과정을 이해하고 싶어 합니다.

로그인이 필요 없는 도구는 사용됩니다. 마찰 (Friction)은 채택을 저해합니다. 가입 절차를 완전히 제거했더니 사람들이 실제로 다시 방문하고 도구를 공유했습니다.

브라우저 전용 방식은 단순한 기믹 (Gimmick)이 아닌 실질적인 제약 사항입니다. 서버 없이 계산적으로 실행 가능한 것이 무엇인지 신중하게 고민해야 합니다. 제가 추가하고 싶었던 기능들(실제 당혹도 (Perplexity) 점수 산출, 모델 미세 조정 (Fine-tuning)) 중 일부는 클라이언트 측 (Client-side)에서 대규모로 구현하는 것이 불가능합니다.

직접 체험해보기

학생의 제출물을 검토하는 교육자이거나, 프리랜서의 작업물을 확인하는 콘텐츠 편집자, 혹은 단순히 자신의 글이 어떤 점수를 받는지 궁금한 분이라면 직접 시도해 보세요: aidetector.getinfotoyou.com

글자 수 제한 없음. 로그인 불필요. API 키 불필요. 텍스트를 붙여넣고 결과가 어떻게 나오는지 확인해 보세요.

저는 여전히 휴리스틱 (Heuristics)을 적극적으로 개선하고 있습니다. 만약 오탐 (False positive)이나 미탐 (Miss)을 발견하신다면, 진심으로 의견을 듣고 싶습니다.