DEVOCEAN

요즘 AI와 함께 글을 쓰는 일이 부쩍 늘었습니다.

그러다 최근 DEVOCEAN에 올린 개발기(벡터DB를 걷어내고 유사글 추천을 되살린 이야기)가 "AI 느낌이 많이 난다"는 이야기를 들었고,

마침 책 원고 교정 도구와 DEVOCEAN의 AI 블로그 봇 DEVOTEE를 함께 손보던 중이라 판정 전용 모델인 TypeSafe의 Jev를 한번 붙여 봤습니다.

그 과정을 정리해봅니다.

Jev를 붙인 곳은 세 군데입니다.

1. 책 원고 교정 도구 manuscript-ci의 "원문 vs 수정안" 판정

2. Claude Code 스킬 writing-deslop의 AI 문체 패턴 탐지

3. DEVOTEE의 발행 전 점검

세 곳 모두 실제 글에 돌려서 수치를 쟀는데, 해 보니 Jev는 조건부로 권할 만하다는 생각입니다.

답이 정해진 판정을 맡기고, 확률에 기준을 걸고, 규칙으로 셀 수 있는 것은 코드에 맡길 때는 쓸 만했습니다.

반면 "AI처럼 읽히는" 느낌의 상당 부분은 Jev로 잡히지 않았고, 글 전체에 쌓인 반복이나 애초에 글을 그렇게 쓰게 만든 요구 조건에서 나오는 것 같았습니다.

참고로 앞의 개발기는 코드 블록과 표를 빼고 세어 보니 문단의 72%가 한 문장짜리였고, "여기서 소소한 반전 하나." 같은 뜸 들이는 문장이 열 번 나왔습니다.

그림 1. 세 곳에 Jev를 붙인 자리. 주황은 LLM, 파랑은 Jev, 초록은 코드가 맡은 단계입니다

1. Jev 간단히 살펴보기

TypeSafe는 Jev를 "System One 모델"이라고 부르는데, 글을 새로 써 주는 모델이 아니고 질문을 던지면 정해진 형식의 답과 확률을 돌려주는 판정 전용 모델입니다.

질문 형식은 선택지 중 하나를 고르는 Choice, 예/아니오의 확률을 주는 Noul, 순서가 있는 단계 위의 위치를 주는 Score 세 가지가 있고, 이번에는 Choice와 Noul만 썼습니다.

처음에는 감을 잡으려고 SDK 예제를 그대로 한번 돌려 봤습니다.

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

with TypeSafeClient() as client:  # TYPESAFE_API_KEY 환경변수를 읽습니다
    response = client.system_one(
        state={"document": "I was charged twice. Please fix this ASAP."},
        questions={
            "billing": Noul(instructions="Is this ticket about billing?"),
            "tone": Choice(
                instructions="What is the customer's tone?",
                criteria={"calm": None, "frustrated": None, "angry": None},
            ),
            "urgency": Score(
                instructions="How urgent is this ticket?",
                criteria=["can wait", "this week", "today"],
            ),
        },
    )

0.98        # billing: 결제 관련일 확률
frustrated  # tone
1.99        # urgency: 0~2 척도에서 "today"에 거의 붙은 값

세 질문이 요청 한 번에 같이 처리되고, 공식 문서 기준으로 입력 토큰만 과금하며 한 요청에서 state와 가장 긴 질문을 합쳐 32k 토큰까지 받습니다.

영어 정확도가 가장 높고 한국어는 지원은 하지만 동등하지는 않다고 되어 있어서, 이번에는 모든 측정을 한국어 글로 직접 해 봤습니다.

작업하는 내내 지킨 원칙은 하나였는데, 글을 새로 쓰거나 고치는 일은 Claude나 Gemini 같은 LLM에 두고, "이 수정이 원문보다 나은가"처럼 답이 정해진 질문만 Jev에 보내는 것이었습니다.

2. 책 원고 교정에 붙이며

1) manuscript-ci 소개

manuscript-ci는 책처럼 긴 원고를 AI로 교정할 때 쓰려고 만든 오픈소스 도구입니다(GitHub, MIT 라이선스).

이름처럼 코드에 CI를 돌리듯 원고에도 점검을 돌린다는 생각에서 출발했는데, 쉽게 말하면 원고를 위한 lint와 테스트, 코드 리뷰를 합쳐 놓은 도구라고 보면 됩니다.

원고를 그럴듯한 AI 문체로 다시 써 주는 도구는 아니고, 작은 수정 후보를 만든 뒤 저자가 정한 규칙으로 평가해서 원문보다 확실히 나은 수정만 남기는 쪽입니다.

이런 도구를 만든 건 AI로 책을 다듬다 보면 문장은 매끄러워지는데 정작 책에서 중요한 것들이 조금씩 틀어졌기 때문입니다.

출처가 말한 것보다 주장이 세지거나, 장마다 같은 용어의 정의가 조금씩 달라지거나, 같은 주장을 표현만 바꿔 여러 장에서 되풀이하거나,

문장을 다듬다가 저자 목소리가 약해지는 경우가 많았고, 실제로 책 한 권을 처음부터 끝까지 검토하면서 쓰던 방식을 도구로 정리하게 됐습니다.

쓰는 방법은 원고 폴더에 세 가지 파일을 두는 데서 시작합니다.

저자의 목소리와 용어, 주장 원칙을 적는 WRITING_BRIEF.md,

어느 장이 어떤 개념을 맡는지 정하는 DEDUP_DECISIONS.md,

무엇을 "더 나은 수정"으로 볼지 기준을 적는 REVIEW_RUBRIC.md입니다.

그다음 manuscript-ci review 04장.md처럼 한 장씩 돌리면 되고, 기본값은 원고를 건드리지 않고 리포트만 남기며 --apply를 붙여야 실제로 반영합니다.

책 전체의 장간 모순을 찾는 audit-book과 EPUB 빌드 결과를 점검하는 check-build도 있고,

수정안을 만들고 채점하는 LLM은 명령어로 연결하게 되어 있어서 Claude든 다른 모델이든 붙일 수 있습니다.

2) Jev를 붙인 곳

manuscript-ci의 교정은 원문을 기본값으로 두고, LLM이 제안한 수정안이 원문을 이겨야만 반영하는 방식입니다.

원문을 채점하고, 수정안을 몇 개 받고, 수정안마다 원문과 비교한 다음 순서를 바꿔 한 번 더 비교해서 두 번 다 이기고 점수도 떨어지지 않아야 채택합니다.

이 중에 원문과 수정안을 비교하는 단계는 새로 쓸 것이 없는 판정이라 Jev에 맡기고, 수정안을 만들고 채점하는 일은 그대로 LLM에 두었습니다.

그림 2. manuscript-ci 교정 흐름. 비교하는 두 단계만 Jev가 맡습니다

[models]
pairwise_backend = "typesafe"           # 비교 판정만 Jev (기본값: "command")
typesafe_min_probability = 0.6          # 승자 확률이 이보다 낮으면 무승부

요청 한 번에 원문·수정안·무승부 중 하나를 고르는 Choice와, 두 버전 각각이 사실을 지어내거나 과장하는 위반을 새로 들여왔는지 묻는 Noul 두 개를 같이 넣었습니다.

원문에 과장이 있고 수정안이 그걸 고친 경우에 원문 쪽 위반 때문에 수정안이 막히면 안 되니까 위반 여부는 이긴 쪽 기준으로만 봤습니다.

또 한국어 원고 한 장이 3만 자 안팎이라 원문과 수정안 두 벌을 통째로 보내면 32k 토큰을 쉽게 넘어서, 바뀐 문단과 앞뒤 한 문단만 잘라서(최대 6,000자) 보냈고,

잘린 부분이 두 버전에서 정확히 같은지는 무작위 편집 3,000건으로 테스트를 만들어 확인했습니다.

3) 0.53으로 통과한 수정안

책 한 장에 처음 돌렸을 때 수정안 하나가 채택됐는데, 판정 확률을 보니 좀 애매했습니다.

원문: 에이전트가 헤매는 자리는 대개 사람도 헤매던 자리다.
수정: 이 사례에서는 에이전트가 헤매던 자리가 사람도 헤매던 자리였다.

원문 먼저 비교:   P(수정안)=0.93
순서 바꿔 비교:   P(수정안)=0.53, P(원문)=0.41

규칙대로라면 두 번 다 이긴 것이지만 두 번째 비교는 거의 동전 던지기에 가까웠습니다.

Jev의 Choice는 확률이 가장 높은 선택지를 그냥 돌려주기 때문에 0.36 대 0.33 대 0.31이어도 0.36이 이긴 것으로 나옵니다.

애매하면 원문을 지킨다는 게 이 도구의 원칙이라, 이긴 쪽 확률이 0.6보다 낮으면 무승부로 보도록 기준을 하나 더 넣었습니다.

winner = winner_answer.choice
# 비슷하게 갈린 결과는 승리로 보지 않는다. 원문을 지킨다.
if winner != "TIE" and winner_answer.probabilities.get(winner, 0.0) < self.min_probability:
    winner = "TIE"

4) 책 한 권에 돌려 본 결과

기준을 넣고 나서 『DevRel Next』 10개 장을 한번 돌려 봤습니다.

수정안 20개 중에 3개만 채택됐고, Jev 판정 40번 중 이긴 쪽 확률이 0.8 이상이었던 건 12번, 0.6 미만이었던 건 20번이었으며, 0.6 기준 때문에 무승부로 바뀐 판정이 18번이었습니다.

기각된 17개 중 16개는 두 순서 모두에서 이기지 못한 경우였고 1개는 재채점 점수가 떨어진 경우였습니다.

채택된 3개는 모두 근거보다 센 표현을 누그러뜨리는 수정이었습니다.

판정 한 번은 1초 안팎이라 10개 장 전체를 5개씩 병렬로 돌린 13분 51초 대부분은 수정안을 만들고 채점하는 LLM 쪽에서 걸렸습니다.

5) 두 번째 책에서 막힌 곳

출간을 준비 중인 다른 책에 돌렸을 때는 판정이 아니라 채점 단계에서 문제가 생겼습니다.

채점을 맡은 LLM이 2026년 자료를 모르다 보니 저술 단계에서 사실 확인을 다 마친 인용까지 날조 위험으로 보고, 10개 장 중 7개 장을 막아 버렸습니다(첫 점수 38~58점).

장마다 사실 확인 기록을 채점 프롬프트에 같이 넣어 줬더니 막힌 장이 하나도 없어졌고(78~86점), 남은 지적들은 실제로 원고를 고칠 만한 것들이었습니다.

이 내용은 manuscript-ci에 fact_ledger라는 설정으로 넣어 두었습니다.

3. AI 문체 탐지 스킬에 붙이며

1) writing-deslop 소개

writing-deslop은 제가 Claude Code에서 쓰는 스킬 중 하나입니다.

Claude Code의 스킬은 특정 작업을 어떤 순서와 기준으로 할지 적어 둔 지시문 묶음인데, /writing-deslop처럼 불러서 쓰면 Claude가 그 절차대로 일을 합니다.

이 스킬은 AI가 쓴 글에서 자주 보이는 11가지 패턴을 찾아서 고쳐 주는 용도이고, 패턴은 Reddit r/ChatGPT에서 화제가 됐던 글에 정리된 것을 바탕으로 했습니다.

11가지를 몇 개만 옮겨 보면, 질문을 연달아 던지다가 뻔한 답을 공개하는 방식,

"이건 도구가 아니다. 무기다."처럼 부정한 뒤 비슷한 것을 드러내는 방식,

"당신에게 필요한 건 X가 아니라 Y다" 같은 훈수, 한 문장마다 줄을 바꿔 괜히 극적으로 만드는 방식,

"그런데 가장 좋은 점은?"으로 뜸을 들이는 방식,

"대부분의 사람은 X, 성공한 사람은 Y" 같은 이분법 등이 있습니다.

패턴마다 한국어와 영어 예문, 고쳐 쓴 예문이 들어 있고, 녹취를 요약기로 정리한 회의록을 다듬는 전용 규칙도 따로 있습니다.

원래는 Claude가 글을 읽으면서 이 기준으로 판단하는 방식이라, 책 원고처럼 긴 글에서는 읽어야 할 양이 많아서 패턴을 찾는 부분만 Jev에 한번 맡겨 보기로 했습니다.

2) Noul 11개 대신 Choice 1개

처음에는 패턴마다 Noul 질문을 하나씩, 모두 11개를 보냈는데 패턴 하나가 들어 있는 문단이면 비슷한 패턴 서너 개가 같이 켜져서 정밀도가 0.40밖에 나오지 않았습니다.

그래서 11개 패턴에 "해당 없음"을 더해 하나를 고르는 Choice 질문 하나로 바꿨더니,

비슷한 패턴끼리 확률을 나눠 가지면서 패턴 이름을 맞힌 게 20개 문단 중 18개로 올라갔고 깨끗한 문단 9개 중 7개는 그대로 두었습니다.

정답지는 문단 30개에 AI 주석자 둘이 서로의 답을 보지 않고 라벨을 붙인 뒤 둘이 일치한 29개만 썼습니다.

그림 3. 정답이 p1인 문단 하나를 두 방식으로 판정한 실제 확률. Noul은 네 패턴이 함께 켜지고, Choice는 p1 하나로 모입니다

question = {
    "pattern": Choice(
        instructions="Which rhetorical device most clearly shapes this text?"
                     " Judge only the writer's own voice; ignore quoted speech.",
        criteria={"p1": "...", "p2": "...", ..., "none": "none of these devices"},
    )
}

한 문장짜리 문단이 줄줄이 이어지는 패턴은 규칙으로 셀 수 있어서 Jev에 묻지 않고 코드로 셌습니다.

3) 이미 다듬은 원고에서는 대부분 오탐

같은 스크립트를 책 두 권에도 돌려 봤는데, 『DevRel Next』는 751개 문단 중 49개가 걸렸고(37초) 하나씩 읽어 보니 실제로 해당하는 건 2개였으며,

출간 준비 중인 다른 책은 507개 중 71개가 걸려서(25초) 3개만 실제로 고쳤습니다.

인용문 속 문장이나 요약하는 문장, 질문 뒤에 실제 분석이 이어지는 문단이 많이 걸렸는데, 규칙을 두고 다듬은 원고에는 그런 패턴 자체가 드물다 보니 걸린 목록의 대부분이 오탐이 되는 거 같습니다.

그래서 스킬에서는 Jev 결과를 "사람이 먼저 읽어 볼 곳"을 좁혀 주는 후보 목록 정도로 쓰고, 걸린 문단은 모두 직접 읽고 판단하도록 했습니다.

4. Jev가 잡지 못한 것: 글 전체의 반복

처음에 말한 개발기도 Jev로 돌려 봤는데, 74개 문단 중 9개만 걸렸고 그마저 대부분 실제 원인을 짚는 문장이었습니다.

그런데 글을 처음부터 읽어 보면 AI 느낌이 나긴 났고, 문단 하나하나보다는 같은 장치가 계속 반복되는 게 원인인 거 같아서 장치별로 코드로 한번 세 봤습니다.

하나씩 떼어 보면 문제없는 문장들이 글 전체에 쌓이면서 AI가 쓴 것처럼 읽혔던 것이고, Jev는 문단을 하나씩 따로 보기 때문에 이런 반복은 알 수가 없었습니다.

교정본은 코드 블록 13개를 한 글자도 건드리지 않고 문장을 묶고 장치만 걷어내는 식으로 만들었습니다.

그림 4. 개발기 한 편의 지도. Jev가 표시한 9곳(파란 테두리)보다 글 전체에 흩어진 반복(주황 점·삼각형, 초록 칸)이 훨씬 많습니다

DEVOTEE가 자동으로 쓴 트렌드 글에서는 또 다른 종류의 문체가 나왔는데,

"획기적으로, 대폭, 극대화" 같은 과장 부사가 12번,

"유기적으로 진화" 같은 공문서형 수식어가 6번,

"~자리 잡을 것입니다" 같은 미래 단정이 5번 쌓여 있었고 Jev는 25개 문단 중 3개만 걸렀습니다.

같은 글에서 MCP 도구 정의 예시가 inputSchema 대신 parameters를 쓰는 오류도 있었는데, 이런 사실 오류는 문체 점검으로는 잡히지 않았습니다.

정리해 보면 문단 안의 패턴은 Jev가, 글 전체의 반복은 코드가 잡고, 사실 오류는 둘 다 못 잡으니 따로 확인하는 단계가 필요할 거 같습니다.

5. DEVOTEE에 적용하며

1) DEVOTEE 소개

DEVOTEE는 DEVOCEAN에 매일 IT 트렌드 글을 올리는 AI 봇입니다.

DEVOCEAN은 SK의 개발자 기술 블로그이자 커뮤니티로, 2021년에 제가 PM을 맡아 오픈했던 사이트이고, DEVOTEE는 올해 3월부터 만들어 운영하고 있습니다.

매일 아침 7시 40분(한국 시간)에 GitHub Actions가 돌면서 Threads, GeekNews, Velopers, TechBlogPosts, IndieBlog에서 그날의 글을 모으고,

Gemini로 트렌드를 분석해서 한국어 블로그 글을 쓴 다음 DEVOTEE 블로그와 DEVOCEAN에 올립니다.

그 밖에 DEVOCEAN에 글이 올라오면 마스코트로서 AI 답글을 달아 주기도 하고, 커뮤니티에 "개발이야기" 글도 따로 올립니다.

매일 한 편씩 사람 손을 거치지 않고 올라가는 글이다 보니 문체가 금방 눈에 띄는데, 앞의 4장에서 본 트렌드 글이 바로 DEVOTEE가 쓴 글이었습니다.

코드는 Next.js와 TypeScript로 되어 있고 대부분 Claude Code와 같이 작업해 왔는데,

이번에도 Claude Code와 같이 프롬프트 금칙, 생성 뒤 점검, 목소리와 주제 고르기 이렇게 세 가지를 차례로 바꿨습니다.

2) 프롬프트 금칙

점검부터 붙이기 전에 생성 프롬프트를 먼저 봤는데,

트렌드 글에 나온 토요타 코롤라 비유가 어디서 왔나 찾아보니 프롬프트에 "어렵거나 추상적인 개념은 일상적인 비유를 한 번씩 곁들여"라는 지시가 들어 있었습니다.

모델은 시킨 대로 한 셈이라, 이 지시를 지우고 비유는 소프트웨어·인프라·개발 도구 안에서 원문과 직접 맞을 때만 쓰게 바꿨습니다.

그리고 앞에서 센 상투어와 비슷한 표현들을 금칙으로 나열하고, 미래를 말할 때는 조건과 근거와 시점을 같이 쓰게 하고, "첫째, 둘째" 식의 열거와 매번 같은 마무리 형식도 쓰지 않게 했습니다.

3) 생성 뒤 점검과 재생성

프롬프트만으로는 상투어가 다 사라지지 않아서 글을 만든 뒤에 점검하는 단계를 넣었습니다.

그림 5. DEVOTEE 발행 전 점검. 미달이면 걸린 표현을 알려 주고 최대 두 번 다시 쓰게 합니다

1차 기준은 정규식으로 세는 밀도 점검으로,

과장 부사·공문서형 수식어·추상 명사·미래 단정·상투적 전환구·틀에 박힌 열거 여섯 가지를 코드 블록을 뺀 본문에서 세서 1,000자당 1.2건이나 전체 10건을 넘으면 다시 쓰게 했습니다.

앞의 트렌드 글이 1,000자당 4.4건 정도라 확실히 걸리고, 한두 건 정도는 통과하는 수준입니다.

Jev는 보조로만 두었는데, 앞에서 본 것처럼 상투어 밀도는 대부분 놓쳤고 다듬은 글에서는 오탐이 많았기 때문입니다.

처음 붙인 버전은 글 전체를 한 번에 넣고 AI 상투 문체, 기술과 무관한 비유, 근거 없는 미래 단정 세 가지를 Noul로 따로 묻는 방식이었는데, 그럴듯해 보이긴 했지만 한 번도 재 본 적이 없는 설계였습니다.

그래서 3장에서 실제로 재 본 방식, 즉 문단마다 11개 패턴 중 하나를 고르는 Choice로 바꿨고, 확률 0.6 이상으로 표시된 문단이 3개 이상일 때만 다시 쓰게 했습니다.

트렌드 글이 25개 중 3개였고 다듬은 원고에서는 걸린 49개 중 2개만 실제 해당이었던 걸 감안하면, 한두 개 걸린 걸로 다시 쓰게 하면 멀쩡한 글까지 흔들릴 거 같았습니다.

앞에서 세 본 반복 장치들("X가 아니라 Y", 뜸 들이는 조각문 등)은 아직 기준을 정할 근거가 없어서 점수에는 넣지 않고 수치만 남기다가, 몇 주치 분포를 보고 정해볼까 합니다.

다시 쓰게 할 때는 이전 초안에서 실제로 걸린 표현을 [과장 부사] "획기적으로" × 3처럼,

Jev가 표시한 문단을 ¶3 ["X가 아니다. Y다." 극적 부정] (0.71) "…"처럼 나열하고,

지운 자리에 다른 과장 수식어를 넣지 말고 수치나 비교 대상, 조건, 근거로 바꿔 쓰라고 같이 알려 줍니다.

막연히 AI 같지 않게 쓰라고 하는 것보다는 어디를 고칠지 정확히 알려 주는 쪽이 낫다고 봤습니다.

두 번 다시 써도 기준에 못 미치면 후보 중에 점수(1,000자당 밀도 + Jev 최대 확률 × 5)가 가장 낮은 글을 그냥 발행하는데, 매일 올리는 봇이라 점검 때문에 하루를 거르지는 않게 했습니다.

판정 결과는 GitHub Actions 실행 요약에 한 줄로 남기고, 기준값들은 저장소 변수로 바꿀 수 있게 해 두었습니다.

4) 목소리와 주제 고르기

점검을 붙이고 나서 보니 금칙어만 있으면 모델이 금지된 표현을 비슷한 다른 상투어로 바꿔 끼우는 경우가 있었고,

다시 쓰게 할 때 "다른 과장 수식어를 넣지 말라"는 문장을 따로 넣어야 했던 것도 그래서였습니다.

책을 쓸 때 쓰는 book-writer 하네스는 이와 반대로 금칙보다 먼저 저자의 목소리를 정의하는데, 그 형식을 빌려서 DEVOTEE에도 목소리 문서를 만들어 줬습니다.

연결되는 소식 2~3개만 골라 하나의 주장으로 묶고, 형용사 대신 수치나 버전·날짜·원문 표현을 보여 주고, 원문이 말한 것과 DEVOTEE의 해석을 구분하고 모르는 건 모른다고 쓰는 필자로 정의했습니다.

그런데 원인을 좀 더 따라가 보니 프롬프트의 요구 조건 자체가 문제였습니다.

후보는 수집처별로 돌아가며 12개를 뽑고, 본문은 6,000~9,000자에 "짧은 글은 절대 불가", 소제목은 최소 6개였으니,

이 조건을 채우려면 관계없는 주제를 늘리고 이어 붙이는 문장을 넣을 수밖에 없었던 거 같습니다.

트렌드 글이 주제 7개를 한 편에 담은 것도 그래서였습니다.

그래서 분량을 4,000~7,000자, 소제목을 4개 이상으로 줄이고, 본문을 쓰기 전에 무엇을 고를지 먼저 적게 하는 단계를 넣었습니다.

===PLAN===
SELECTED:  고른 후보 2~3개 (연결 이유를 한 문장으로 쓸 수 없으면 고르지 않음)
THESIS:    오늘의 주장 한 문장 (반박 가능해야 함)
LINK:      고른 항목을 묶는 이유
JUDGMENT:  주제마다 판단 하나(지금 써볼 만하다 / 조건부로 유효하다 /
           아직 지켜볼 단계다 / 과대평가된 면이 있다)와 그 근거
OPENING:   오프닝 메뉴에서 고른 것
CLOSING:   클로징 메뉴에서 고른 것
OTHERS:    나머지 후보 (본문 끝 "그 밖의 소식"에 한 줄씩)

PLAN은 발행하지 않고 실행 기록에만 남겨서 모델이 날마다 무엇을 고르고 어떤 주장을 했는지 볼 수 있게 했습니다.

목소리 문서에 넣은 첨삭 예시는 앞의 트렌드 글에서 가져왔습니다.

원문: 오늘 살펴볼 기술 트렌드는 이러한 실무 병목을 해결하기 위해 프론트엔드 경험 설계, 백엔드 아키텍처, 거버넌스 보안, AI 에이전트 인프라가 어떻게 유기적으로 진화하고 있는지를 명확히 보여줍니다.

DEVOTEE 목소리로: 오늘 소식 중 두 개가 같은 질문에 답합니다. 사람이 하던 확인 작업을 어디까지 시스템에 넘길 수 있는가입니다. 토스뱅크는 대출 서류 문의를, kt cloud는 쿠버네티스 장애 조회를 AI에 넘겼습니다. 나머지 소식은 끝에 짧게 모았습니다.

원문과 사실을 대조하는 단계(주장마다 원문 발췌에 근거가 있는지 Jev로 묻기)와,

최근 며칠의 글 구성을 기록해서 날마다 다르게 배정하는 단계는 코드 작업이 더 필요해서 다음으로 미뤄 두었습니다.

5) 실제 발행 글: 적용 전과 후

점검을 붙인 뒤 첫 글은 2026년 9월 28일 아침 정기 실행에서 나온 「SRAM이 부족한 임베디드 통신, 버퍼를 늘리지 않고 해결하는 3단계 메모리 분할 전략」입니다.

후보 12개 중에 같은 충전기 제어 보드(STM32G484)에서 나온 기록 세 개를 골라 "수신은 링 버퍼로, 송신은 청크 스트리밍으로,

인증서는 메타데이터와 페이로드를 나눠 배치하는 것이 현실적인 해법"이라는 주장 하나로 묶었고, 나머지 6개는 끝에 "그 밖의 소식"으로 돌렸습니다.

문체 점검은 첫 초안에서 바로 통과해서 다시 쓰지 않았습니다.

다음 날인 9월 29일에는 Jev 키를 등록한 뒤 처음으로 점검 전체가 돌았고, 「이론적 기대가 무너지는 3가지 지점: JVM 메모리 오버헤드부터 가상화 호스트 지표와 클라우드 DR 복구까지」가 올라왔습니다.

이번에도 후보 12개 중 3개를 골라 "사양표나 문서의 기대치만 믿고 설계한 인프라와 애플리케이션은 실제 오버헤드와 물리 경계, 복구 비용이라는 벽에 부딪힌다"는 주장으로 묶었고, 5개를 "그 밖의 소식"으로 돌렸습니다.

상투어는 0건이었고, Jev는 24개 문단을 3.4초에 판정해서 1개(p9, 가짜 반골)만 표시해 재생성 기준(3개 이상)에 걸리지 않고 통과했습니다.

도입부를 나란히 놓으면 차이가 좀 더 잘 보입니다.

적용 전: 오늘 살펴볼 기술 트렌드는 이러한 실무 병목을 해결하기 위해 프론트엔드 경험 설계, 백엔드 아키텍처, 거버넌스 보안, AI 에이전트 인프라가 어떻게 유기적으로 진화하고 있는지를 명확히 보여줍니다.

적용 후: 마이크로컨트롤러(MCU) 펌웨어를 다루다 보면 누구나 한 번쯤 겪는 벽이 있습니다. 평소에는 작은 제어 패킷만 오가며 문제없이 작동하던 시스템에 수 킬로바이트(KB) 크기의 인증서나 대용량 프로토콜 규격이 들어오는 순간입니다.

6) 운영하며 겪은 것

첫날부터 하나가 빠져 있었는데, Jev 판정이 실제로는 돌지 않았습니다.

실행 로그에 [문체/Jev] 미설정 또는 실패 — 어휘 밀도 판정만 적용이 찍혀 있었고, 확인해 보니 GitHub Actions에 TYPESAFE_API_KEY가 아직 등록되지 않은 상태였습니다.

키가 없으면 밀도 점검만으로 판단하도록 만들어 둔 덕분에 발행은 평소대로 됐지만, 이번 글의 결과는 금칙어와 주제 고르기, 밀도 점검만의 효과라고 보는 게 맞을 거 같습니다.

같은 글을 제 쪽 스크립트로 따로 돌려 보니 29개 문단 중 3개가 표시됐는데, DEVOTEE의 재생성 기준이 "표시 문단 3개 이상"이라 키가 있었다면 한 번 다시 썼을 수도 있습니다.

다만 두 쪽의 문단 나누는 방식이 조금 달라서 정확히 같은 결과가 나왔을 거라고 단정하긴 어렵습니다.

읽어 보면 남은 AI 티도 있는데, "오늘 살펴볼 세 가지 소식은"처럼 글을 소개하는 문장이나 "필요한 것은 버퍼의 확장이 아니라 … 분할입니다" 같은 훈수형 문장은 금칙어 목록에 걸리지 않는 종류라,

이런 쪽은 Jev가 붙은 뒤에 어떻게 잡히는지 봐야 할 거 같습니다.

키를 등록한 다음 날에는 Jev가 제대로 붙었습니다.

로그에 [문체/Jev] 24문단 판정 3420ms (임계 0.6, via direct) → flag 1개 [p9×1] → pass가 찍혔고, 인증 오류는 없었습니다.

제 쪽 스크립트로 같은 글을 재면 2개가 표시됐는데, 둘 다 같은 DR 문단을 p9로 봤고 나머지 하나는 확률이 0.67로 기준 근처였던 걸 보면,

기준값 주변에서는 문단을 나누는 방식에 따라 결과가 조금씩 달라지는 거 같습니다.

이날 실행은 21분 47초가 걸려서 전날(5분 38초)보다 훨씬 길었는데,

대부분은 글을 쓰는 단계에서 Gemini가 503(과부하)을 다섯 번 돌려줘 15초부터 240초까지 기다렸다가 다시 시도한 시간이었고 Jev 판정은 그중 3.4초였습니다.

이틀 모두 주제를 3개로 좁히는 건 잘 됐는데, 첫날은 같은 보드에서 나온 기록이라 연결이 분명했던 반면,

둘째 날은 JVM 메모리, VMware 가상화, 클라우드 DR로 분야가 서로 달라서 "기대가 무너지는 지점"이라는 틀로 묶은 쪽에 가까웠습니다.

고르는 기준(연결 이유를 한 문장으로 쓸 수 있어야 한다)은 지켰지만, 그 한 문장이 얼마나 단단한지는 아직 사람이 보고 판단해야 할 거 같습니다.

또 "숨기는 물리 호스트의 진실", "환상 깨기" 같은 소제목은 패턴 8(진실은?)이나 극적인 뒤집기에 가까운데, Jev는 소제목을 판정하지 않아서 걸리지 않았습니다.

앞으로는 몇 주 동안 재생성이 실제로 몇 번 일어나는지, 멀쩡한 글이 오탐으로 다시 쓰이는 경우가 있는지,

소제목과 도입부의 소개 문장을 점검 대상에 넣을지를 보면서 기준을 조정해볼까 합니다.

6. 돌아보며 정리한 것

세 곳에 Jev를 붙여 보면서 정리된 생각을 몇 가지 적어 두면, 우선 생성과 판정은 나누는 게 맞았고, 판정 확률에는 기준을 따로 걸어야 했습니다.

가장 높은 선택지가 0.36이어도 그대로 돌아오니,

원고 교정에서는 0.6 미만을 무승부로 처리했는데 이 값도 한 장의 첫 실행을 보고 정한 거라 다른 글에서는 기존 판정과 나란히 비교해 보고 맞추는 게 좋을 거 같습니다.

확률이 비슷하게 갈릴 때 두 번째 칸에 놓인 쪽을 고른 사례도 있었어서, 표본이 적어 단정하긴 어렵지만 순서를 바꿔 두 번 비교하는 장치는 빼지 않는 게 좋겠습니다.

질문 설계가 결과를 생각보다 많이 좌우했습니다. 비슷한 판정은 Noul 여러 개보다 Choice 하나로 묶는 게 나았고,

DEVOTEE에 처음 붙인 질문처럼 그럴듯해 보여도 재 보지 않은 설계는 한 번 의심해 보는 게 좋습니다.

규칙으로 셀 수 있는 문단 길이나 반복 횟수, 금지어는 모델에 묻지 않고 코드로 세는 편이 정확했고, 이미 다듬은 글에서는 Jev 결과를 후보 목록 정도로 보는 게 맞았습니다.

판정기 바깥도 같이 봐야 했습니다.

두 번째 책처럼 채점하는 LLM의 지식 한계가 문제인 경우도 있었고, DEVOTEE처럼 글을 쓰게 만드는 요구 조건이 상투어의 원인인 경우도 있었습니다.

마지막으로 Jev는 외부 API라서 공개할 글에만 켰고, 회의록이나 사내 문서는 스크립트에서 아예 거부하게 해 두었습니다.

7. 마치며

간단히 정리하려던 글이 좀 길어졌습니다.

해 보면서 AI 글 냄새를 줄이는 데는 지우는 규칙을 늘리는 것보다 무엇을 어떻게 쓸지 먼저 정하는 쪽이 더 효과가 있다는 걸 느꼈고, 이 글도 그 생각으로 몇 번 고쳐 쓰게 됐습니다.

DEVOTEE는 이제 막 점검을 붙였으니 몇 주 운영해 보고 결과를 다시 공유해볼까 합니다.

아직 모르는 것도 적어 둡니다.

• 영어였다면 어땠을지 모릅니다. 모든 측정을 한국어 글로 했습니다. 공식 문서는 영어 정확도가 가장 높다고 하니, 같은 설계라도 영어 글에서는 수치가 다를 수 있습니다.

• 기준값의 근거가 얇습니다. 원고 교정의 0.6은 한 장의 첫 실행을, DEVOTEE의 "표시 문단 3개"는 글 한 편과 원고 두 권을 보고 정했습니다. 몇 주치 운영 데이터가 쌓이면 바뀔 수 있습니다.

• 정답지를 사람이 만들지 않았습니다. 3장의 문단 30개는 AI 주석자 둘이 라벨을 붙였습니다. 사람이 직접 표시한 정답지로 다시 재 봐야 합니다.

• DEVOTEE의 효과는 이틀치만 봤습니다. 상투어 밀도가 1,000자당 4.4건에서 0.46건, 0건으로 줄고 주제가 관계없는 7개에서 3개로 좁혀졌으며, 키를 등록한 둘째 날부터 Jev도 3.4초 안에 판정을 마쳤습니다.

  다만 두 번 모두 첫 초안에서 통과해서 재생성이 실제로 어떻게 동작하는지는 아직 보지 못했고, 몇 주치가 쌓이면 다시 정리해볼까 합니다.

참고 자료

• TypeSafe 문서 — Choice, Confidence, Models

• TypeSafe Python SDK

• manuscript-ci — typesafe_judge.py, fact_ledger 설정

• MCP 명세: Tools