결과를 못 낸 다섯 번의 실험
설치가 된다는 사실과 우리 언어를 검사할 수 있다는 사실은 다른 이야기였다.
이 글은 편집부의 실행 기록을 바탕으로 AI 도구의 도움을 받아 초안을 쓰고, 사람이 사실과 문장을 확정했습니다.
왜 이 글을 믿을 수 있나
2026년 8월 2일에 우리는 다섯 후보에서 아무 품질 결과도 만들지 못했다. 그 다섯 건을 지우지 않고 실패로 남겼다. 실패한 실험도 다음 사람의 시간을 아껴 주기 때문이다.
각 후보마다 고정 버전, 실행한 명령, 종료 코드, 표준 오류 로그, 화면 기록을 보존했다. 입력은 실제 작품이 아니라 합성 한국어 원고와 합성 DOCX다. 계정 생성, 결제, API 키 발급, 외부 게시물 작성은 하지 않았다.
우리가 하지 않은 것도 적는다. 호스팅형 LanguageTool은 확인하지 않았다. Manuskript를 손으로 클릭하는 방식은 시험하지 않았다. DeepL은 사람이 직접 브라우저를 조작하는 경로를 다시 열지 않았다. 그리고 이 다섯 건 중 어느 것도 제품의 한국어 품질이 나쁘다는 뜻이 아니다.
누구에게 필요한가
"이 도구 한국어 되나요?"를 검색해 본 사람. 그리고 후기에서 '설치 성공'이라는 말을 어디까지 믿어야 할지 판단하려는 사람.
어떻게 시험했나
다섯 후보를 각각 다른 이유로 골랐다. 로컬 맞춤법 검사기 하나, 로컬 집필 앱 하나, 로그인 없이 열리는 웹 윤문 서비스 하나, 구매 전 미리보기가 열리는 출판 앱 하나, 깃허브 공개 저장소 하나다. 로컬 후보는 프로젝트 폴더 안에만 설치했고, 웹 후보는 서로 분리한 새 브라우저 문맥에서 한 곳씩 열었다.
무엇이 나왔나
1. LanguageTool 6.6 독립 실행판은 한국어를 아예 모른다. 설치는 됐고 버전도 고정됐다. 그런데 언어를 한국어로 지정하자 이렇게 끝났다.
java.lang.IllegalArgumentException: 'ko' is not a language code known to LanguageTool.
Supported language codes are: ar, ast-ES, be-BY, br-FR, ca-ES, ... ja-JP, km-KH,
nl, nl-BE, nl-NL, pl-PL, pt, ... ta-IN, tl-PH, uk-UA, zh-CN.목록에 한국어 계열이 없다. 자동 감지로 바꿔 봤더니 언어를 NoopLanguage로 잡고 지적을 0개 반환했다.
"language":{"name":"NoopLanguage","code":"zz",
"detectedLanguage":{"name":"NoopLanguage","code":"zz","confidence":1.0}},
"matches":[]준비해 둔 필수 교정 12건은 비교조차 못 했다.
2. Manuskript 0.17.0은 이 macOS에서 자동 실행 경로가 없었다. 최신 릴리스가 deb, rpm, 윈도우 zip만 제공하고 macOS 파일이 없다. 소스를 받아 격리 환경에 의존성을 설치했고 모듈 불러오기까지는 성공했다. 그런데 --help조차 화면 앱으로 진입해 10초 제한에서 멈췄다. 5장짜리 한국어 원고를 넣고 빼는 확인은 실행하지 못했다.
3. DeepL Write는 우리가 한국어를 고를 수 없었다. 로그인 없이 입력창은 열렸다. 하지만 새 자동 브라우저가 원문 언어를 영어(영국)로 잡았고, 보안 확인 창이 언어 선택을 가로막았다. 기본 모드는 한국어 원고를 통째로 영어로 번역해 돌려줬다.
입력: 비는 올것처럼 하늘만 낮게 내려앉아 있었다. 서하는 우산 손잡이를 쥔체 골목 끝을 노려봤다.
출력: The sky was low and threatening, as if rain were about to fall.
Seo-ha held the umbrella handle and looked at the end of the alley.오류 교정만 하는 모드는 한국어와 영어가 섞여 나왔다. 유효한 한국어 결과는 두 번 시도해서 0건이다. DeepL 도움말은 DeepL Write가 한국어를 지원한다고 명시한다. 그러니 이건 제품의 한국어 실패가 아니라 우리 자동화 조건의 실패다. 같은 판정표로 돌린 격리 Codex 기준선은 필수 교정 12개를 모두 반영했지만, 상대할 DeepL 결과가 없으므로 둘을 점수로 비교하지 않는다.
4. Vellum은 성공했다고 썼다가 우리 손으로 철회했다. 공개 설치본 4.1.4의 버전과 서명, 실행은 확인했다. 합성 DOCX 가져오기도 시도했다. 문제는 남은 기록이다. 보존된 화면 텍스트가 Untitled, Untitled뿐이라, 그날 관찰한 5개 장 분리와 한국어 본문 미리보기를 다시 확인할 방법이 없었다. 당시 직접 봤다는 기억은 근거가 아니다. 그래서 가져오기 성공 주장을 내리고 '증거 부족'으로 바꿨다. 출판 파일 생성은 구매가 필요해 시도하지 않았다.
5. Book Writer는 실행 전제에서 멈췄다. 저장소 구조와 14개 에이전트, 15개 추가 기능, 셸 문법까지는 확인했다. 하지만 핵심 흐름이 Claude 실행에 묶여 있어 이번 정책에서는 호출하지 않았고, EPUB 생성 명령은 로컬에 pandoc이 없어 종료 코드 4에서 시작조차 못 했다. 준비해 둔 한국어 정합성 원고는 미실행으로 남겼다.
| 후보 | 어디까지 갔나 | 어디서 멈췄나 |
|---|---|---|
| LanguageTool 6.6 | 설치·실행 성공 | 지원 언어 목록에 한국어 없음 |
| Manuskript 0.17.0 | 소스 설치·모듈 불러오기 성공 | 자동 실행이 화면 앱으로 진입 |
| DeepL Write | 공개 입력창 열림 | 언어 선택이 보안 확인 창에 막힘 |
| Vellum 4.1.4 | 설치본 검증·가져오기 시도 | 보존 기록이 성공을 증명 못 함 |
| Book Writer | 구조·문법 확인 | pandoc 부재로 종료 코드 4 |
아쉬운 점과 한계
다섯 건 모두 표본 하나짜리다. 다른 운영체제, 다른 브라우저, 사람이 직접 클릭하는 방식이었다면 결과가 달라졌을 수 있다. 특히 DeepL과 Vellum은 제품 자체를 평가한 것이 아니라 우리 기록 조건이 부족했던 사례다.
우리가 여기서 정한 규칙은 세 가지다. 공개 화면을 봤다는 사실을 직접 써 봤다고 쓰지 않는다. 자동화 방어에 막힌 결과를 제품 실패로 옮겨 적지 않는다. 관찰했다는 기억만으로는 근거로 쓰지 않고, 다시 시험할 때는 장 목록과 본문이 함께 보이는 화면을 비식별 상태로 남긴다.
다른 선택지
- 한국어 맞춤법, 문법 검사가 목적이라면 독립 실행판 LanguageTool은 후보에서 빼도 된다. 지원 언어 단계에서 걸린다.
- 로컬 집필 앱을 macOS에서 자동화하려면 공식 macOS 배포 파일과 화면 없이 도는 명령이 있는지 먼저 확인한다.
- 웹 윤문 서비스는 원문 언어가 한국어로 잡혔는지부터 눈으로 확인하고 시작한다.
- 출판 앱 미리보기를 근거로 남기려면 장 목록과 본문이 한 화면에 보이는 상태를 캡처해 둔다.
- 깃허브 도구는 기능 목록보다 필요한 외부 프로그램 목록을 먼저 읽는다. 이번엔 pandoc 하나가 전체를 막았다.