Local LLM 개발일지 02

2026년 3월 11일

시간이 좀 지났는데, 프로젝트나 학업 준비로 바빠서 글을 못 쓰다가, 이제서야 글을 쓰네요. 지난 글에서는 Local LLM을 활용한 블로그 글 번역 기능 개발을 시작했고, 이번 글에서는 아키텍처 재설계에 대해 다뤄보겠습니다.

지난 글 Local LLM 개발일지 01에서, 로컬 LLM을 활용한 블로그 글 번역 기능 개발을 시작했습니다.

이번 글에서는 아키텍처 재설계에 대해 다뤄보겠습니다.

아키텍처 재설계

우선, 개인 블로그에 작성하는 글은 모두 mdx,md 형식으로 로컬에서 작성을 하고, 이를 Github에 push하면 Vercel이 자동으로 빌드 및 배포를 하는 형태로 운영이 되고 있습니다.

그렇다면, 자동 번역을 위해서는 생각났던 방법이

글을 작성하고 push하기 전에 로컬에서 돌려서 번역을 해서, 번역한 글까지 검수를 한 뒤 같이 push한다.
한국어로 작성된 포스트를 Github에 push를 하면 그걸 다른 프로그램이 감지해서 번역을 한다. 그럼 그걸 번역해서 검수한 뒤 en,jp언어로 각각 push한다.

효율적인 방법은 당연히 1번입니다. 그러나, 로컬에서 번역을 하는 경우, 제 노트북을 번역하는 동안 사용하지 못하기 때문에 클라우드 GPU를 활용하는 방법을 선택했습니다.

혹시 몰라서 GTX1070TI에서 돌릴려고 AI한테 물어보니까 추천하지는 않는다고 함.

Docker Image만들어서, Hub에 올리고 Runpod까지 해서 번역을 테스트 해봤는데, 결과가 이상했음
그래서 다시 로컬모델에서 테스팅을 거쳐 번역이 잘 되는 것을 확인한 뒤, 해당 환경 그대로 Image를 만들어서 다시 배포
근데, 글을 일주일에 많아봐야 3개정도 쓰거나 작성하지 않을 때도 있는디, 그냥 한 번 로컬에서 돌리면서 기다리는게 더 좋지 않을까 생각이 됨.
조금더 고민해서 결정해야할듯, 우선 Runpod에 10달러 넣었더니 15달러를 추가로 줘서 25달러가 있음 근데, 글 한번 돌렸다고 0.09달러가 나갔음, KR -> EN번역하는 작업이였고, 한국돈으로 환산하면 약 130원정도지만 60초만에 번역이 됬음. 번역이 되지 않은 부분인 코드 주석부분과 지 멋대로 가져다 붙인 부분을 제외하면 번역이 괜찮았지만, 띄어쓰기나 들여쓰기 문제가 존재했음.

gemma4:latest 모델을 사용 -> 확실히 잘함, 그러나 python 같은 코드 블럭에서는를 ”```” 이 문자가 아예 없었다. 그러나, 내부 코드 주석은 번역을 잘했어서, 코드 블럭 부분만 확실하게 Prompting 하면 될 것 같다.

중간에 개발하면서, Runpod랑 로컬에서 개발하면서 번역 정확도를 올리려고 했는데, 공부를 해보니까. 이런 방향성으로는 번역 정확도를 올리는게 쉽지 않을 것 같아서, 시간이 좀 걸리더라도 읽어볼 만한 논문들이나 자료들을 찾아보면서, 번역 정확도를 올리는 방법에 대해서 생각해 보려고 합니다.

2026년 04월 13일

거의 1달만인데, 다른 프로젝트하고 포트폴리오 정리하고 학교 공부하느냐 바빠서, 중간 중간 글을 채워 넣지는 못했습니다. 번역 시스템을 다시 손보게 된 건 포트폴리오 만들면서 부족한 부분이 많이 눈에 띄었기에, 2주 정도 전부터 계속해서 고민해보고 생각해봤습니다.

우선, 제가 읽어본 논문이나 자료들은 한국어 - 일본어 번역에 대해서 얘기한 논문과 일반적으로 적용할 수 있는 방법론들에 대한 논문들과 자료들이였고, 번역의 품질을 결정하는 요소들에 대해서도 찾아봤습니다. 자세한 내용은 다른 글에서 다루도록 하겠습니다. 아래 간단하게 작성하며, 해당 링크를 걸어두고자 합니다.

번역의 품질

[참고] : https://machinetranslate.org/ 우선, 번역의 품질을 다루는 기술부터 소개하고자 합니다.

n-그램 일치도: 문장을 n개 단어 단위로 쪼갠 뒤, 두 문장에서 같은 조각이 얼마나 겹치는지를 보는 방법.

BLEU : 기계 번역 평가의 대표적인 지표로, 번역 결과와 참조 문장 간의 n-그램 일치도를 기반으로 점수를 계산합니다. 주로 표면적인 텍스트 유사성을 측정합니다.
ROUGE : 원래는 텍스트 요약 평가를 위해 개발된 지표로, 번역에도 사용되지만 BLEU보다 요약 분야에서 더 많이 활용됩니다. n-그램 기반 유사도를 측정합니다.
METEOR : BLEU의 한계를 보완하기 위해 제안된 지표로, 단어 일치뿐 아니라 어간(stem), 동의어, 의미적 유사성을 반영하여 더 정교한 평가를 수행합니다.
BERTScore : BERT와 같은 사전학습 언어모델을 활용하여, 단어의 의미를 벡터로 비교함으로써 문장 간 의미적 유사성을 측정하는 지표입니다.
COMET : 단순 유사도 계산이 아니라, 사람 평가 데이터를 기반으로 학습된 기계 번역 품질 예측 모델입니다. 의미 보존, 문맥, 자연스러움 등을 종합적으로 평가할 수 있어 최근 가장 강력한 지표 중 하나로 사용됩니다.

용어 제약 기반 번역 (Lexically Constrained Translation)

일반적인 신경망 번역(NMT)은 문장을 자유롭게 생성하기 때문에, 동일한 용어가 문서마다 다르게 번역되거나 고유명사가 변형되는 문제가 발생합니다.

이를 해결하기 위해 연구에서는 Lexically Constrained Translation(용어 제약 기반 번역) 이라는 방법을 제안합니다.

대표적으로 Hokamp & Liu (ACL 2017)는 Grid Beam Search를 통해 번역 과정에서 특정 단어를 반드시 포함하도록 강제할 수 있음을 보였으며, 이 방법이 번역 품질을 유의미하게 향상시킨다는 것을 실험적으로 검증했습니다.

이후 Post & Vilar (NAACL 2018)는 이를 개선하여, constraint 개수와 관계없이 효율적으로 적용할 수 있는 방법을 제안했으며, 실제 환경에서도 사용할 수 있는 수준의 성능과 속도를 확보했습니다.

2020년도 연구에서는 Transformer 기반 모델에서도 이러한 제약을 적용할 수 있으며, 특정 용어를 100% 유지하면서도 전체 번역 품질을 향상시킬 수 있음이 확인되었습니다.

[Lexically Constrained Neural Machine Translation with Levenshtein Transformer: https://aclanthology.org/2020.acl-main.325/]

모델 선택과 적용

본 프로젝트에서는 Qwen3-14B 모델을 번역 모델로 사용했습니다. -> 오픈소스 모델 중에서, 가장 한국어 - 일본어간 번역 성능이 좋다고 나온 모델이었습니다.

Qwen3-14B는 Transformer 아키텍처 기반의 대형 언어 모델로, Self-Attention 메커니즘을 통해 문맥을 이해하고 자연스러운 문장을 생성할 수 있습니다. 이러한 구조는 번역 작업에서도 높은 성능을 보이며, 특히 다국어 처리에 강점을 가지고 있습니다. 동일한 용어가 문서마다 다르게 번역됨, 고유명사가 변형됨, 문맥에 따라 번역이 달리짐 등등 기존의 번역 시스템에서 발생하는 문제들을 해결하기 위해, Qwen3-14B 모델에 Lexically Constrained Translation 방식을 적용했습니다.

수작업

우선, 제가 기존에 만들었던, glossary_backup에서 번역이 이상하거나 잘못된 애들을 모두 제거하고, 좋은 번역만 남기는 작업을 했습니다. 그리고, 모델에게 확실한 데이터를 제공하기 위해 json 형식으로 정리하며, 규칙을 정했습니다.

    {
      "ko": "Baekjoon",
      "canonical": "Baekjoon", -> 번역 통일을 위한 기준값
      "en": "Baekjoon",
      "jp": "Baekjoon",
      "type": "proper_noun",
      "translate": false, -> 번역 금지 설정
      "priority": "required", -> 번역 필수 설정
      "status": "approved"
    }

Hun-Bot