Antigravity 에이전트 아키텍처와 평가 루프 설계

1. 들어가며

최근 대형 언어 모델^LLM을 중심으로 코딩이나 추론 작업을 알아서 수행하는 에이전트 시스템이 주목받고 있다. 하지만 에이전트가 생성한 글에는 특유의 어색한 번역투나 인위적인 기계적 문체가 짙게 묻어나는 경우가 많다.

대표적으로 다음과 같은 유형들이 반복적으로 관찰된다.

• 단어나 문장을 큰따옴표나 작은따옴표로 묶어 과하게 강조하는 행위
• 영어 텍스트에서 긴 대시(—)를 남발하는 경향
• 현지 문체와 맞지 않는 과도한 지시대명사 사용
• 단순히 무엇이 아닌, 무엇을 넘어 와 같이 허수아비 논법이나 대구법을 서두에 기계적으로 반복하는 습관
• 리듬, 흔들린다, 냄새가 난다 처럼 현실 세계에서 거의 쓰이지 않는 어색한 비유적 어휘 사용
• 폭넓지 못한 어휘력 활용으로 유연함이나 준비성 등의 세부 뉘앙스를 모두 강력하다는 단어 하나로 뭉뚱그리는 현상
• 핵심, 중요 등 표상적인 표현을 문맥 앞에 강박적으로 서술하는 습관
• 기수 표현 시 아라비아 숫자를 쓰지 않고 문자로 풀어쓰는 현상 (예: 4가지 대신 네 가지, 3 options 대신 three options로 기입)

AI 문체 패턴이 여러 에이전트 시스템에서 반복되면서 독자들의 피로감이 누적되고 있다. AI 문체를 정량적으로 수치화하고 가드레일 기준으로 삼을 방법을 고민하며 가독성을 자동으로 보정하는 검증 도구^Harness와 에이전트 시스템을 설계했다. 이와 관련해 에이전트의 작동 로직과 가독성 평가 코드를 구현했다. 리포지토리의 소스 코드와 세부 세팅은 다음 링크를 통해 상세히 확인할 수 있다.

KennethanCeyer/natural-writing-harness

Preview unavailable.

https://github.com/KennethanCeyer/natural-writing-harness

에이전트에 모든 권한을 주면 발생하는 문제점을 살펴보고, 3단계 구조로 역할을 세분화한 아키텍처를 분석한다. 기존 방식처럼 에이전트가 평가, 수정, 파일 저장 과정을 한꺼번에 처리하도록 설정하면, 오류가 발생했을 때 하이퍼링크가 누락되거나 파일 자체가 손상될 위험이 크다. 이러한 문제를 예방하려면 각 과정을 독립된 단계로 나누어 처리해야 한다.

• 평가 단계^Evaluator: 작성된 초안을 분석하여 문장 시작 패턴의 중복을 style_diagnostics.py 모듈로 찾아내거나 어조 변화를 semantic_diagnostics.py 모듈로 검출한다.
• 교정 단계^Harness: 감지된 문제 구간만 선별하여 고치도록 제어한다. refinement_service.py가 수정 범위를 필요한 범위로 제한하고, quality_gate.py가 본문의 숫자나 링크 유실을 감시하여 원본의 사실 관계를 보존한다.
• 저장 단계^Agent: 파일 쓰기 권한을 통제한다. 파일 쓰기 도구인 save_candidate 실행을 샌드박스로 제한하고, 사용자가 승인한 내용만 안전하게 디스크에 기록하도록 제한한다.

이렇게 역할을 격리하면 에이전트가 파일 시스템에 직접 접근해 원본을 손상시키는 일을 원천 차단할 수 있다. 본 프로젝트에서는 문장 수정에 고성능 추론 모델을 사용하고, 파일 쓰기 권한은 에이전트 런타임 정책을 통해 통제했다. 수정에 활용된 모델의 상세 정보는 다음 링크에서 확인할 수 있다.

Gemini 3.5 Flash — Google DeepMind

Preview unavailable.

https://deepmind.google/models/gemini/flash/

본문에서는 다음과 같은 기능을 구현하고 실무에 적용하는 방법을 설명한다.

• AI 말투 진단: 번역투, 불필요한 큰따옴표, 기계적인 문맥 강조 패턴을 정량적으로 검출하고 보정하는 방법을 다룬다.
• 컨텍스트 보존형 하네스: 원본의 링크나 수치가 유실되는 문제를 방지하며 어색한 문장만 부분적으로 다듬는 하네스 설계 방안을 설명한다.
• 보안 가드레일: 에이전트 오동작으로 인한 로컬 파일 손상을 막기 위해 파일 쓰기 도구의 권한을 샌드박스로 제한하는 런타임 구성법을 소개한다.

이러한 3단계 구조가 로컬 소스 코드 레벨에서 어떻게 구현되어 있는지 모듈 명세와 함께 살펴본다.

2. 하네스와 에이전트 아키텍처

시스템의 구조와 파일별 역할은 다음과 같다.

src/natural_writing_harness/
├── style_diagnostics.py       # 구문 검사 (중복 표현 및 문장 길이 분석)
├── semantic_diagnostics.py    # 문맥 분석 (AI 번역투 및 어조 진단)
├── refinement_service.py      # 교정 서비스 (정적 변환 및 LLM 분기 처리)
├── quality_gate.py            # 정보 보존 검증 (숫자 및 하이퍼링크 유실 방지)
├── rewrite_policy.py          # 반영 정책 (수정 전후 경고 건수 비교)
├── agent_runtime.py           # 보안 실행 환경 (수동 저장 승인 및 도구 통제)
└── agent_state.py             # 저장 처리기 (승인된 해시 및 파일명 검증)

각 모듈은 글을 진단하고 교정하여 저장하는 전 과정을 세분화하여 담당한다. 각 모듈의 역할은 다음 도표와 같다.

각 모듈은 개별 기능을 독립적으로 수행하며, 전체 시스템은 하네스 검증과 에이전트 권한 관리의 2개 영역으로 분할된다.

하네스 검증 프로세스

하네스는 LLM의 입출력을 통제하는 제약 장치다. 모델에 문서 전체의 수정을 위임하면 원본 내용이 왜곡되거나 하이퍼링크 등이 유실될 위험이 있다. 이를 차단하기 위해 refinement_service.py가 전체 교정 흐름을 제어하며 문제 지점의 로컬 범위 내에서만 수정을 적용한다. 구체적으로, style_diagnostics.py와 semantic_diagnostics.py를 거쳐 초안 상태를 파악한 뒤, 수정본이 확보되면 quality_gate.py를 통해 사실 관계 및 링크 보존 여부를 대조하고, rewrite_policy.py에서 에러 경고 감소 수준을 확인하여 반영 여부를 최종 결정한다.

에이전트 권한 격리

단순 프롬프트 작성 규칙만으로는 로컬 작업 환경을 안전하게 보호할 수 없다. 에이전트 도구 권한에 디바이스 파일 쓰기 권한을 열어둘 경우 모델의 오작동 시 파일이 영구 유실될 수 있다. 따라서 쓰기 동작을 에이전트의 도구 실행 범위에서 분리했다. 수정된 텍스트는 임시 영역에 고유 해시^SHA-256 ID와 함께 대기하며, 사용자가 지정한 파일명 및 해시 정보가 정확하게 일치할 때만 승인을 받아 최종 저장된다.

이렇게 분리된 구조를 로컬 환경에서 실행하고 연결하기 위해 CLI 도구를 도입했다.

3. nwh CLI

개발 과정에서 에이전트 런타임이나 IDE 확장 기능과 독립적으로 문서 검증을 수행할 수 있도록 nwh^{Natural Writing Harness} CLI 도구를 설계했다. 이 도구는 자동화된 CI/CD 파이프라인과 통합하여 벤치마크 및 정량 분석을 실행하기 용이하다.

주요 명령어와 기능은 다음과 같다.

이들 명령을 실행하면 3가지 후보 텍스트와 진단 알고리즘을 중심으로 세부적인 검증 단계가 수행된다. 구체적인 워크플로는 다음과 같다.

4. 교정 및 검증 워크플로

4.1 고정된 비교 조건

성능을 정밀하게 측정하기 위해 동일한 프롬프트에서 생성된 3가지 대조군을 비교한다. 비교 대상은 1) 사람이 직접 작성한 참조본^Reference, 2) 제약 없이 즉시 출력된 초안^Baseline, 3) 보정 장치를 거쳐 다듬어진 최종본^Revised이다. 참조본은 대조 분석용으로만 활용되며, 모델 생성 시점의 프롬프트에는 포함되지 않는다.

4.2 규칙 검사와 문맥 검사의 균형

검증 프로세스는 오류 유형에 따라 정적 검증과 정성 진단으로 나누어 수행된다. 단순 치환 코드로는 누락된 숫자나 손상된 링크를 검토하고, Gemini 모델은 문장 구조나 글의 흐름을 여러 측면에서 분석한다. 모델 분석기는 문맥 정보가 모호한 경우 기권^ABSTAIN[1]을 출력하여, 분석 시스템 개발자의 개인적 성향이 과도한 제약 규칙으로 굳어지는 일을 차단한다.

단순 매칭이나 단순 통계 규칙만으로는 자연스러운 텍스트를 구성하기 어렵다. 글의 어감이나 뉘앙스를 정교하게 보정하기 위해서는 맥락적 판단을 수반하는 유연한 진단 로직이 결합되어야 한다.

4.3 수정 후 검증

문장을 고치는 도중 중요한 사실 정보가 소실될 수 있으므로, 수정본에 대해 동일한 진단 평가를 재실행한다. 검증 과정에서 새로운 스타일 경고가 추가되거나 기존 경고 수준이 25% 이상 유의미하게 감소하지 않으면 해당 수정본을 반려한다.

아래 코드는 수정 전후의 스타일 경고 지표를 대조하는 구체적인 검증 로직이다.

rewrite_policy.py
def require_contextual_improvement(baseline_signals, revised_signals):
    actionable = {"medium", "high"}
    baseline_levels = {
        signal.code: max(signal.normalized_excess, 1.0)
        for signal in baseline_signals
        if signal.severity.value in actionable
    }
    revised_levels = {
        signal.code: max(signal.normalized_excess, 1.0)
        for signal in revised_signals
        if signal.severity.value in actionable
    }
    new_codes = set(revised_levels) - set(baseline_levels)
    if new_codes:
        raise RewriteRejected(
            "The revision introduced actionable style failures"
        )
    improved = any(
        code not in revised_levels
        or revised_levels[code] <= baseline_levels[code] * 0.75
        for code in baseline_levels
    )
    if baseline_levels and not improved:
        raise RewriteRejected(
            "The revision did not materially reduce its trigger"
        )

이 함수는 수정 전후의 중간 및 높은 등급 스타일 경고를 취합한다. 검증 과정에서 새로운 경고가 하나라도 발생하면 예외를 일으켜 차단한다. 또한 기존 스타일 결함 중 최소 1개 이상이 해소되거나 에러 지표 수치가 25% 이상 유의미하게 하락해야 비로소 통과될 수 있다. 이를 통해 불필요한 편집으로 파일이 덮어쓰이는 것을 방지한다.

검증 단계를 거치면 본격적인 텍스트 교정 엔진이 가동된다. 아래에서는 정적 교정과 언어 모델의 문맥 수정을 상황에 맞게 분기하여 처리하는 구조를 다룬다.

5. 부분 교정 하네스

부분 교정 하네스는 대상 독자층, 작성 목적, 어조 및 원문 컨텍스트 정보를 넘겨받아 작동한다. 감지된 스타일 오류 코드를 기계적으로 제거하는 대신, 장르와 컨텍스트를 고려하여 수정 필요성을 사전 판별하기 위해서다.

하네스는 문서 전체를 재작성하지 않고 정형 정규표현식^Regex 기반의 정적 교정과 LLM 기반의 문맥 재작성으로 실행 경로를 나눈다. 해당 서비스의 구현 코드는 다음과 같다.

refinement_service.py
def prepare_revision(draft, *, context, profile, services, source_context=""):
    before_report = evaluate_text(draft, context, profile)
    before_signals = diagnose_response(draft, language=context.language)
    example = local_example(context, source_context)
    semantic_before, _ = services.semantic_reviewer.inspect(example, draft)
    decision = select_revision_operation(draft, before_signals, semantic_before)

    if decision.operation is RevisionOperation.CONTEXTUAL_REWRITE:
        rewrite = services.contextual_rewriter.rewrite(
            draft, before_report, context, profile, before_signals, semantic_before
        )
    elif decision.operation is RevisionOperation.EXACT_BOUNDARY_CLEANUP:
        rewrite = apply_exact_boundary_cleanup(draft)
    else:
        rewrite = RewriteResult(revised_text=draft, applied_changes=[])

    validation = validate_rewrite(
        draft,
        rewrite.revised_text,
        profile,
        authoritative_source=source_context or None,
    )
    if not validation.safe:
        raise RewriteRejected("Quality gate rejected revision")

이 서비스는 초안을 진단한 뒤, 고성능 모델이 필요한 문맥 재작성^{CONTEXTUAL_REWRITE}과 정적 정규식 대체로 처리할 수 있는 단순 교정^{EXACT_BOUNDARY_CLEANUP}으로 나누어 처리한다. 수정 결과물은 보존 검사^{validate_rewrite}를 거쳐 사실 관계, 숫자, 하이퍼링크가 온전히 유지되었는지 다시 확인한다.

검증 단계를 통과한 수정본이라도 최종적으로 디스크에 기록하는 작업은 별도의 권한 통제가 필요하다. 아래에서는 에이전트 도구 권한을 엄격히 제한하는 Antigravity 프레임워크 설정을 다룬다.

6. 파일 저장 권한 제어

에이전트의 도구 실행 권한과 보안 정책을 제어하기 위해 Antigravity 프레임워크 SDK^{Software Development Kit}를 도입했다. 아키텍처 및 상세 사양은 다음 공식 페이지에서 확인할 수 있다.

Google Antigravity

Google Antigravity - Build the new way

https://antigravity.google/

에이전트의 가용 도구를 prepare_candidate, save_candidate, finish의 3가지 도구로 제한하고 권한 격리 정책을 구성했다.

LLM 자체는 실행 환경이나 파일 시스템 구조를 인지하지 못한다. 프롬프트 주입^{Prompt Injection} 공격을 받거나 일시적으로 오동작할 경우 의도치 않은 시스템 명령이 실행되거나 로컬 파일이 손상될 위험이 존재한다. Antigravity는 도구 호출 정의와 권한 정책^Policy을 분리하여, 기본적으로 모든 접근을 차단^{Deny-by-Default}한 뒤 필요시 사용자의 수동 승인을 거치도록 가드레일을 구성한다.

실제 런타임 구성 코드는 다음과 같다.

agent_runtime.py
config = LocalAgentConfig(
    model=model,
    api_key=api_key,
    response_schema=AgentFinal,
    tools=[prepare_candidate, save_candidate],
    capabilities=types.CapabilitiesConfig(
        enable_subagents=False,
        enabled_tools=[types.BuiltinTools.FINISH],
    ),
    policies=[
        policy.deny_all(),
        policy.allow("prepare_candidate"),
        policy.ask_user(
            "save_candidate",
            handler=approval_handler(
                auto_approve=auto_approve, slot=slot, audit_path=audit_path
            ),
        ),
        policy.allow(types.BuiltinTools.FINISH.value),
    ],
    hooks=[restrict_save, audit_tool, audit_turn, sanitize_tool_error],
)

policy.deny_all() 설정을 통해 기본적으로 모든 도구 호출 권한을 박탈한다. 이후 임시 버퍼 생성 기능인 prepare_candidate는 별도 절차 없이 허용하되, 디스크에 직접 기록하는 save_candidate 도구 호출 시에는 ask_user 정책이 트리거되어 사용자 승인을 반드시 요구하도록 조율한다.

승인된 수정본이 정확히 디스크에 저장되도록 CandidateSlot은 수정본의 고유 해시^SHA-256를 생성한다. 저장 함수는 이 해시 값과 파일 경로를 검증하여 디렉터리 우회^{Directory Traversal} 공격을 차단한다. 해당 저장 처리 모듈의 코드는 다음과 같다.

agent_state.py
def save(self, candidate_id: str, filename: str) -> dict[str, str]:
    if candidate_id != self.candidate_id:
        raise ValueError("The requested candidate is not the validated candidate.")
    if safe_filename(filename) != self._output_path.name:
        raise ValueError("The filename differs from the approved filename.")

    target = (self._output_path.parent / filename).resolve()
    if target.parent != self._output_path.parent:
        raise ValueError("Resolved output path escapes the approved directory.")

    target.write_text(
        self.candidate.rewrite.revised_text.strip() + "
", encoding="utf-8"
    )
    write_audit(
        self._audit_path,
        "candidate_saved",
        candidate_sha256=self.candidate_id,
        filename=filename,
    )

이와 같이 해시 검증과 저장 위치 검사를 거쳐 예기치 않은 시스템 오작동이나 덮어쓰기 위험을 방지하고 작업 환경의 안전을 확보한다.

평가, 교정, 검증, 저장이 모두 조율되는 환경이 구축된 시점에서, 하네스가 실제로 수정한 상세 범위와 개선 효과 데이터를 정량적으로 검토해 본다.

7. 벤치마크 결과

No Robots 데이터셋의 특정 리비전을 기준으로 12개 영어 프롬프트를 실행했다. 수집 과정에서 데이터가 누락된 2개 프롬프트 그룹을 제외하고, 동일 프롬프트에 대해 참조문, Baseline 결과물, 하네스 수정본이 모두 확보된 10개 프롬프트 그룹을 최종 분석 대상으로 선정했다. 사람이 작성한 참조본은 대조군일 뿐 가독성의 절대적 기준이 아니다. 또한 이번 벤치마크에서는 교차 선호도 조사를 진행하지 않았으므로, 가독성 향상 여부를 섣불리 일반화하는 임의의 품질 점수나 레이더 차트는 배제했다.

7.1 하네스가 실제로 문장을 수정했는가

가독성을 분석하기에 앞서 하네스가 문장을 실제로 수정한 범위를 먼저 확인했다. Baseline 결과물과 하네스 수정본이 완벽하게 일치하면 정규화된 토큰 편집 거리와 문자 3-gram JS^{Jensen-Shannon} 거리는 0을 가리킨다. 측정 결과, 10개 프롬프트 중 문장이 변경된 사례는 2개에 그쳤으며 나머지 8개는 본래 텍스트를 그대로 출력했다. 수정이 일어나지 않은 8개 항목은 차트에 빈칸으로 두는 대신 동일^identical로 명시하여 본문 보존 결과를 드러냈다.

하네스가 무분별한 수정 시도를 방지하고 본문을 안전하게 보존했음을 보여주는 결과다. 다만, 대조 대상의 80%가 Baseline을 그대로 유지한 만큼 이 데이터만을 가지고 전체적인 문장 개선 효과를 입증했다고 결론짓기는 어렵다.

7.2 관찰된 분포는 어떻게 달라졌는가

다음 지표는 데이터 형태를 설명하는 단순 기술 통계치이며, 글의 품질을 뜻하는 점수가 아니다. 평균 단어 수는 참조문 89.6단어, Baseline 178.2단어, 하네스 수정본 154.1단어였다. 평균 어휘 다양도[2]는 각각 0.775, 0.757, 0.768로 나타났으며 문장 길이의 변동계수^CV[3] 평균은 0.400, 0.444, 0.377로 집계됐다. 이 수치들은 글의 길이나 구조적 다양성 등 텍스트의 특성을 묘사할 뿐, 특정 값이 글의 자연스러움을 대변하진 않는다.

대조군 간 특성 변화 차트는 각각의 프롬프트 조건에서 수정 전후로 어떤 변화가 일어났는지 시각적으로 보여준다. 차트의 요소는 다음과 같이 해석할 수 있다.

• 점^Point: 초안 대비 수정본에서 단어 수나 문장 길이 등이 어느 방향으로 얼마나 변했는지 나타내는 변화량이다.
• 가로선^Bar: 표본의 편차를 감안한 통계적 오차 범위다. 가로선이 가운데 기준선(0)을 가로지르고 있다면, 수정 전후의 차이가 통계적으로 유의미하지 않다는 것을 의미한다.
• 부호^Sign: 변화의 방향이 플러스(+) 혹은 마이너스(-)인 것 자체가 글의 품질을 보장하지 않는다. 예를 들어 단어 수가 감소(-)한 것은 군더더기를 줄인 결과일 수도 있지만, 중요 정보가 빠진 오작동의 결과일 수도 있기 때문이다.

7.3 스타일 벡터 시각화의 의의와 한계

흔히 텍스트 분석 시 단어별 벡터를 2차원에 투영한 뒤, 그 분포가 넓게 퍼진 상태를 보고 어휘의 다양성이나 글의 완성도가 높아졌다고 주장하곤 한다. 그러나 이는 통계적으로 무리가 있는 해석이다. LSA[4]나 t-SNE[5] 같은 차원축소 기법을 통한 시각화 상의 퍼짐 정도는 단순 사용 단어의 빈도나 시각화 알고리즘의 하이퍼파라미터 설정에 민감하게 좌우되므로, 이를 가독성 개선의 척도로 삼아서는 안 된다.

이에 본 분석에서는 고정된 StyleDistance 인코더 모델을 도입하여 전체 문장을 768차원의 문체 표현 벡터로 수치화했다. 왼쪽 차트는 개별 프롬프트의 주제 편향을 보정하기 위해 프롬프트별 평균 벡터를 뺀 후 주성분 분석^PCA을 거친 탐색용 2차원 시각화 자료다. 첫 2개 축이 보존하는 잔차 분산비가 각각 38.8%와 35.2%에 불과하므로, 화면상에 가깝게 표현되었다 하더라도 다차원 공간상에서의 실제 유사성을 입증하지 못한다.

보다 정밀한 분석을 위해 오른쪽 차트와 같이 본래의 768차원 공간에서 유사도 분석을 실행했다. 각 프롬프트 단위로 Baseline과 하네스 수정본이 사람이 쓴 참조문과 얼마나 가까운지를 코사인 거리로 측정하여 비교했다. 점을 연결하는 선분은 동일 프롬프트 내에서의 정량적 수치 추이를 의미하며 생성 과정의 이동 궤적을 나타내지 않는다. 측정 결과, 하네스 수정본 1개는 참조문에 더 가까운 방향으로 좁혀졌고, 다른 1개는 멀어졌으며, 나머지 8개는 본래의 텍스트 형태를 유지했다.

문체 표현 벡터는 분석 결과 어색함이 검출된 프롬프트를 우선 식별하여 정밀 재검증 대상을 추려내는 용도로 적합하다. 다만 768차원 다차원 공간의 기하학적 유사도가 독자의 실제 문체 선호와 항시 비례하지 않으며, 특정 표현의 부적절함을 자동으로 짚어내어 명시해주지도 않는다. 수집된 결과는 교정 하네스가 원본을 유실하지 않으면서 최소한의 변경을 적용했음을 증명할 뿐, 글쓰기 수준을 일관되게 높였다는 정성적 주장을 뒷받침하긴 어렵다. 향후 글의 장르를 넓히고 다각도의 사용자 블라인드 테스트 평가를 병행해야 비로소 가독성의 실질적 개선을 논의할 수 있다.

8. 결론

안전한 글쓰기 에이전트 시스템을 구축하기 위해서는 문맥 평가, 로컬 단위 교정 하네스, 정보 보존 검증, 파일 쓰기 권한 격리 단계를 분리하는 구조적 분할 설계가 권장된다. 각 단계를 나누면 에이전트 오작동 시에도 프로젝트 디렉터리가 손상되지 않도록 막을 수 있고, 오류 로그 추적으로 사후 모니터링 체계까지 갖출 수 있다.

가장 큰 시사점은 가독성 지표의 정의가 모호할수록 실제와 무관하게 결과를 과장하기 쉽다는 점이다. 복잡한 어감을 점수 1개로 억지로 요약하기보다, 수치 유실을 확인하는 보존 검사^{Quality Gate}와 문체 표현 모델을 함께 활용하여 가독성 문제를 고치는 구조를 만드는 쪽이 낫다.

이번 실험에서 확보한 실질적 결과는 안전한 권한 통제 구조와 오작동 억제 파이프라인의 안정성이다. 언어적 자연스러움의 완성은 향후 장르와 언어의 범위를 확장하고 대규모 블라인드 선호도 평가를 누적하면서 지속적으로 규명해 나가야 할 과제다.

• 역할 분리 설계: 평가, 부분 교정, 보존 검증, 쓰기 승인의 각 단계를 독립된 컴포넌트로 세분화하여 설계했다.
• 대조 분석 데이터: 동일한 프롬프트로부터 생성된 10개 대조군 중 2개 문항만 실제 변경이 발생했다는 통계를 빠짐없이 기록했다.
• 배포 승인 조건: 다차원 문체 표현 모델은 잠재적 오류 진단용으로만 제한적으로 활용하며, 정성적 가독성의 실질적 개선 판단과 최종 배포 승인은 다국어 사용자 선호도 검토 이후로 보류한다.