기업 연계 프로젝트: 버그바운티 리포트 다국어 번역 서비스 개발 회고

이번 프로젝트에서는 버그바운티 리포트의 다국어 번역을 자동화하는 AI 기반 시스템을 개발했다.

보안 리포트는 외부 공개가 제한되므로, 오픈된 API가 아닌 Private AI 환경에서 번역해야 하는 도전 과제가 있었다.
이 과정에서 번역 품질과 속도의 균형, 보안 특화 도메인 대응, MLOps 환경 구축 등 다양한 문제를 해결해야 했다.
이번 글에서는 프로젝트 진행 과정과 배운 점을 정리해보려고 한다.

 

프로젝트 개요

프로젝트명: 버그바운티 리포트 다국어 번역 서비스
기간: 2025.01.13 ~ 2025.02.14
목표:

• 다국어로 작성된 버그바운티 리포트를 자동 번역하여 글로벌 서비스 확장
• 외부 LLM API를 사용하지 않고, Private AI 환경에서 번역 처리
• 보안 특화 번역 모델을 구축하여 용어의 정확성과 품질을 개선

주요 작업:

• FastAPI 기반 번역 API 서버 구축
• Qwen 2.5 기반 번역 모델 파인튜닝 및 도메인 특화 모델 개발
• AWS EC2 서버 배포 및 API 연동 테스트

맡은 역할: 데이터 품질 검증 및 다양한 모델 테스트 

협업 방식

• 주 1회 기업 미팅: 매주 수요일 오후 3시, 기획 진행 후 주차별 진행 내용 공유
• Slack & Zoom: 기본 소통 도구, 이슈 발생 시 Zoom 미팅 진행
• Notion을 활용한 일정 공유: 마일스톤 설정 및 변경사항 기록

초기 기획안

모델 개발 및 최적화 과정

1. 모델 선택 및 이유

우리 팀은 Qwen 2.5 모델을 기반으로 번역을 진행했다.
Qwen 2.5는 긴 문서 처리(128K Token 지원), 다국어 지원(29개 언어), Private AI 환경 운영 가능 등의 장점이 있었다.

 

후보 모델 실험 결과

모델	설명	결과
MarianMT	기존 번역 모델, 성능 낮음	❌
NLLB-finetuned-en2ko	Meta의 다국어 모델, 성능 저조	❌
Helsinki-NLP/opus-mt-en-ko	중소형 번역 모델, 보안 용어 대응 불가	❌
Qwen 2.5	LLM 기반 최신 모델, 보안 용어 적용 가능	✅

 

결론:

• 도메인 특화 번역 모델이 필요하므로 Qwen 2.5를 선택
• 보안 특화 용어 및 문맥 유지가 중요하므로 Human Evaluation 진행

2. 데이터 수집 및 전처리

버그바운티 리포트 번역을 위한 데이터 수집 및 정제 과정

 데이터 수집 방식:

• CWE(보안 취약점) Mapping Excel 자료 활용
• CWE 관련 웹 페이지 크롤링(bs4, requests)
• Title, Description, Extended Description을 주요 번역 대상 섹션으로 설정

데이터 번역 프로세스:
1.OpenAI GPT-4o를 활용해 1차 다국어 번역 수행 (영어 → 5개 언어, 한국어 → 5개 언어)
2.보안 용어 유지 및 도메인 특화 번역을 위해 Prompt Engineering 적용

3.Secure Coding Guide(Java, C) 데이터 활용하여 품질 검증

4. 도메인 특화로 된건지 2차로 번역 품질 검증

 

기술 아키텍쳐

 

파이프라인 아키텍쳐

 

3. 모델 훈련 및 성능 개선

학습 과정

• Qwen 모델을 BitsandBytes 4bit QLoRA PEFT 방식으로 훈련
• 하이퍼파라미터 조정:
  • Batch Size = 4, Epoch = 3, Learning Rate = 2e-4
  • 손실 함수: CrossEntropyLoss, Optimizer: AdamW 8bit

성능 평가

• BLEU 스코어 기반 번역 품질 평가
• 보안 용어 번역 적절성 검토
• wandb를 활용한 학습 로그 모니터링

결론:

• Human Evaluation을 거쳐 보안 용어 번역 품질을 개선
• QLoRA 적용으로 모델 메모리 최적화 및 성능 유지

---

서비스 배포 및 운영 환경

 1. AWS 배포 방식

• AWS EC2 g6.xlarge 인스턴스 사용
• FastAPI 기반 RESTful API로 번역 서비스 제공
• 싱글턴 방식 (Lazy Loading)으로 모델 로드 최적화

2. 번역 속도 및 결과 비교

모델 크기	번역 속도(영어)	Markdown 형식 유지
7B	13s	일부 markdown 손실
32B	31s	대부분 유지

 

 

• 속도보다는 품질이 중요한 서비스이므로, 번역 속도보다는 Markdown 유지에 초점
• 사용자는 실시간 번역이 아닌, 저장된 번역 결과를 활용하므로 속도 문제는 크지 않음

---

프로젝트 결과 및 회고

최종 결과

AWS EC2에 번역 API 서버 배포 완료
번역 모델 학습 코드 및 API 서버 코드 정리하여 제공
Swagger API 문서 및 서버 사용 매뉴얼 작성

주요 도전 과제 및 해결 방법

• 도전 과제: 보안 용어 유지가 어려움
  → Secure Coding Guide를 활용한 번역 평가 방식 적용
• 도전 과제: 실시간 번역 속도 최적화
  → StreamResponse 적용하여 UI에서 순차 출력 가능하도록 개선

 

프로젝트를 통해 배운 점

1.번역 모델을 개발할 때 단순한 기계 번역이 아니라, 도메인 특화된 품질 검증이 필요하다.
2.Private AI 환경에서 LLM을 운영하는 방식(AWS + FastAPI + QLoRA)과 관련된 실무 경험을 쌓을 수 있었다.
3.서비스 배포 및 운영 시, 성능 최적화뿐만 아니라 사용자 경험까지 고려해야 한다.

4. 기업과 최소 주 1회 소통하면서 실무 경험을 좀 더 배울 수 있었다. 

 

마무리하며

이번 기업 연계 프로젝트를 통해 번역 모델 개발, 보안 도메인 대응, Private AI 환경 구축, AWS API 배포까지 다양한 경험을 할 수 있었다.
향후 MLOps 환경을 좀 더 고도화하여 자동화된 번역 파이프라인을 구축해볼 계획이다.