지난번에 PPT 번역기를 하나 만들어서 게시글로 공유했었는데, 스터디장님께서 구체적인 피드백을 주셨어요.
주신 피드백을 바탕으로 아래의 작업등을 해봤어요.
제미나이 버전을 업데이트 하는 것
유료 번역서비스들과 비교를 해서 차이점을 찾아내고 그걸 개선하는 작업을 하는 것
진행 방법
이번 개선 작업은 크게 3가지 방향으로 진행했습니다.
1️⃣ 제미나이 모델 변경 (Gemini 3 Flash)
기존에 사용하던 모델 대신 Gemini 3 Flash 모델로 변경했습니다.
모델 변경 이유
속도와 비용 대비 성능이 더 좋아 보였음
번역처럼 짧고 반복적인 작업에 잘 맞는 모델이라고 판단
변경 후 체감
번역 속도가 더 안정적으로 느껴짐
문장 흐름이 이전보다 자연스러워진 케이스가 많아짐
👉 이 작업을 통해 느낀 점은, 모델 선택만 바꿔도 결과 체감이 꽤 크다는 점이었어요.
2️⃣ 유료 번역 서비스와 비교하며 품질 개선
두 번째로 한 작업은 유료 PPT 번역 서비스와의 직접 비교였습니다.
방식
같은 PPT를
유료 서비스
내가 만든 번역기
두 가지로 번역
결과를 나란히 놓고 비교
이 과정에서 나온 결과
어떤 경우에는 프롬프트 수정이 필요했고
어떤 경우에는 코드 로직 자 체를 수정해야 했음
예를 들면:
글자 크기, 글씨체, 볼드, 글씨 색 등이 깨지는 경우
의미는 맞지만 너무 직역처럼 느껴지는 표현
👉 이 작업을 반복하다 보니,
번역 품질은 모델 하나로 결정되는 게 아니라
프롬프트 + 코드 + 비교 기준이 함께 만들어진다는 걸 느꼈어요.
<원본>
<유료버전>
문장간의 구분이 명확하나 제목의 볼드가 빠짐
글씨체를 다르게 번역함
<버전 1 : 지난 주 작업물>
문장 들여쓰기가 너무 많이 들어감
제목 볼드는 유지됨
<버전 2>
제목 볼드 및 글자 들여쓰기는 유지되었으나 자간이 원본파일 그대로 반영되어서 읽기 힘들게 나타남
<버전 3>
일부 들여쓰기 미반영
3️⃣ 번역이 잘 되었는지 판단하는 검증 프로그램 (진행 중)
마지막으로 작업한 부분은 "번역 결과를 어떻게 믿을 수 있을까?"라는 고민에서 시작됐습니다.
그래서 아예 번역 검증용 프로그램을 새로 만들기 시작했어요.
아이디어
최종 번역 결과를
한글 버전
영어 버전
두 가지로 다시 만들어서
일정 기준에 따라 점수(스코어링) 를 매김
목표 구조
점수가 기준 미만이면
다시 번역을 시도하거나
어떤 부분이 문제인지 지적
해당 피드백을 다시 번역 단계로 돌려보내기
👉 이게 완성되면,
기존 번역기에 붙여서 자동으로 품질을 보정하는 구조로 업그레이드할 계획입니다.
앞으로의 계획 🚀
이제 단순한 개인 프로젝트를 넘어서, 실제로 회사에서 쓸 수 있는 도구로 발전시키려고 합니다.
현재 버전에서 품질 업데이트
1페이지 제대로 된 버전을 만들어서 이대로 결과물이 나올 수 있도록 계속 요구하기
+ 평가 프로그램을 만들어서 버전 업데이트 하기
( 1차 번역 -> 평가 및 피드백 -> 2차번역 - >다운로드)
회사 계정만 가입 가능한 회원가입 / 로그인 기능
가입자 명단 관리용 데이터베이스 구성
내부 사용자 피드백 수집
피드백 기반의 주기적인 업데이트
프롬프트 개선
코드 로직 개선
필요 시 모델 변경
👉 최종 목표는,
"쓰면 쓸수록 번역 품질이 좋아지는 내부용 PPT 번역기" 입니다 😊
의문사항
번역 평가 로직을 기존 시스템과 별도로 분리 개발 중인데, 이 방향이 최선일지 고민입니다. 통합 개발 시 공수 비대화와 품질 저하를 우려해 모듈 분리를 택했지만, 타당한 전략인지 궁금합니다.
실무 확장 시 통합형 vs 분리형 중 어느 구조가 운영상 유리한가요? 효율성과 안정성, 확장성 측면에서 조언 구합니다.또한, 만약 분리형으로 했다면 하나로 합칠 때 어떤 식으로 합치면 될까요?
(예를 들어 각각의 폴더에 파일들을 두고
"@A폴더 @B폴더 에 있는 파일들을 하나로 합치려고 해" 이런식으로 명령어를 치면 될까요?)
