AI도 놓친 번역 오류, ESLint 플러그인으로 해결!

본문에서 제시된 @lib/i18n 라이브러리는 사용자에게 노출되는 문자열 관리를 위해 세 가지 핵심 컨벤션을 정의했습니다. 첫째, '한글 문구에 번역 API 사용' 규칙은 주석, 타입명, 로그 등 번역이 불필요한 경우를 제외하고 모든 사용자 노출 문자열에 `t()` 계열 함수 적용을 강제하여 번역 누락(Translation Omission)을 원천 차단합니다. 둘째, '기수·서수형 번역 API 사용'은 수량이나 순서를 나타내는 문구에 `tCardinal()` 또는 `tOrdinal()` 함수와 ICU 메시지 포맷(`{count}`)을 사용하도록 하여 오역(Mistranslation)을 방지합니다. 마지막으로 'Trans 컴포넌트의 엄격한 사용'은 자손에 엘리먼트가 있을 때만 사용하고, 단순 문자열에는 `t()` 함수 사용을 권장하여 코드 복잡도(Code Complexity)를 낮추고 가독성(Readability)을 향상시킵니다. 이 컨벤션들은 개발 생산성과 번역 품질을 동시에 확보하기 위한 필수 요소입니다.

AI와 사람 모두 컨벤션 준수 검증에 한계를 보였습니다. AI는 확률론적 특성으로 인해 코드 컨텍스트를 깊이 이해하는 데 어려움을 겪어, 사용자 노출 문자열 판단 오류 및 내부용 문자열의 오탐(False Positive)을 발생시켰습니다. 또한, 기수·서수형 API 적합성 판단이나 Trans 컴포넌트 사용 여부에 대한 AI의 판단력은 완벽하지 않았습니다. 사람은 높은 집중력이 요구되는 작업에서 실수를 하기 쉬워 번역 누락 및 오역이 발생했습니다. 이러한 문제는 미래에 새로운 한글 문구가 추가될 때도 반복될 가능성이 높아, 결정론적이고 엄격한 규칙 기반의 탐지 메커니즘의 필요성이 대두되었습니다.

컨벤션 위반 탐지를 위해 커스텀 ESLint 플러그인 개발이 결정되었습니다. AI와 린트의 장점을 결합한 하이브리드 접근법을 채택하여, 린트가 결정론적으로 위반을 탐지하고 AI가 확률론적으로 교정하는 방식을 사용했습니다. 개발 전략으로는 엄격한 초기 규칙 설정으로 미탐(False Negative)을 최소화하고, 테스트 주도 개발(TDD) 방식으로 프로젝트 코드에서 테스트 케이스를 추출했습니다. 또한, AST(Abstract Syntax Tree) 분석을 통해 코드 구조를 파악하고, 스코프 스택(Scope Stack)을 활용하여 문자열 리터럴, 템플릿 리터럴, JSX 텍스트 노드가 안전지대(Safe Zone) 밖에 있는지 판별하는 로직을 구현했습니다. 세밀한 옵션 설정과 AI 주도 교정을 통해 개발 및 교정 속도를 높였습니다.

개발된 세 가지 ESLint 규칙은 각각 특정 컨벤션 위반을 탐지합니다. `no-literal-string` 규칙은 AST 노드 순회를 통해 안전지대 밖에 있는 한글 문자열 리터럴을 식별하여 번역 누락을 방지합니다. `prefer-plural` 규칙은 키워드 매칭(Keyword Matching) 방식으로 기수·서수형 문구를 판별하고, 해당 문구가 부적합한 번역 API(`t()`)와 함께 사용될 경우 위반으로 보고합니다. `strict-trans-component` 규칙은 JSXElement 노드를 탐색하여, 자손에 엘리먼트 없이 단순 문자열만 포함된 Trans 컴포넌트의 남용을 잡아냅니다. 각 규칙은 Allow List 형식의 옵션을 통해 프로젝트별 커스터마이징을 지원하며, 상세한 에러 메시지로 AI 교정을 용이하게 합니다.