파이썬 FastAPI로 다국어 웹사이트 구축하기: DeepL API 번역 자동화 및 Supabase DB 캐싱 최적화 경험기

👤 인스피

조회 수 14

1. 번역 엔진의 선택: 왜 구글 번역(Google Translate) 대신 DeepL을 선택했나?

가장 먼저 해야 할 일은 번역을 담당할 두뇌(API)를 고르는 것이었습니다. 보통 가장 먼저 떠올리는 것은 천하무적 구글 번역(Google Cloud Translation API)입니다. 저 역시 처음에는 익숙한 구글 번역기를 연동해 테스트를 진행했습니다.

하지만 커뮤니티 게시판 특성상 유저들이 작성하는 글에는 신조어, 인터넷 밈, 그리고 생략된 주어 등 비문이 엄청나게 많습니다. 구글 번역기는 이런 문장들을 너무 기계적이고 딱딱하게 번역하다 보니, 외국인이 읽었을 때 문맥이 전혀 맞지 않는 경우가 허다했습니다.

그래서 대안으로 선택한 것이 바로 DeepL(딥엘) API입니다. DeepL은 인공신경망 기반으로 문맥을 파악하는 능력이 탁월해서, 한국어 특유의 뉘앙스나 생략된 맥락을 기가 막히게 캐치하여 자연스러운 영어로 번역해 줍니다. 텍스트 처리 속도도 매우 빠르고, FastAPI와의 호환성도 훌륭했기에 주저 없이 DeepL을 메인 번역 엔진으로 채택했습니다. (물론 DeepL이 지원하지 않는 소수 언어에 한해서만 구글 번역 API를 보조로 사용하도록 폴백(Fallback) 구조를 짰습니다.)

2. 파이썬(FastAPI) 백엔드에 DeepL API 연동하기

DeepL API를 FastAPI 서버에 붙이는 과정은 공식 파이썬 라이브러리(deepl-python) 덕분에 아주 수월했습니다. 유저가 게시글을 클릭하여 상세 페이지를 요청할 때, 클라이언트(브라우저)의 언어 설정(Accept-Language)을 확인하여 한국어가 아니라면 즉시 번역본을 제공하도록 API 라우터를 설계했습니다.

코드를 배포하고 직접 영어 환경으로 사이트에 접속해 보았습니다. 게시글이 1초도 안 되어 완벽하고 자연스러운 영어로 바뀌어 나오는 것을 보니 짜릿한 쾌감이 밀려왔습니다. 드디어 내 사이트가 글로벌로 나간다는 생각에 들떴죠.

3. 청구서의 공포: 번역 API 호출 비용의 함정

하지만 기쁨도 잠시, 며칠 뒤 DeepL 대시보드에 들어가 본 저는 경악을 금치 못했습니다. 무료로 제공되는 한 달 50만 자의 번역 제공량이 단 3일 만에 바닥나버렸고, 유료 과금이 시작되려 하고 있었기 때문입니다.

원인은 명확했습니다. 해외에서 크롤링 봇이나 검색 엔진 로봇이 제 사이트의 수많은 게시글을 긁어갈 때마다, 혹은 여러 명의 외국인 유저가 '같은 게시글'을 조회할 때마다 백엔드 서버가 멍청하게 매번 똑같은 문장을 DeepL API로 전송하여 번역을 요청하고 있었던 것입니다. 번역 API는 글자 수대로 과금되기 때문에, 이대로 두었다가는 서버비로 파산할 것이 뻔했습니다.

4. Supabase DB 캐싱으로 비용 90% 절감하기

이 문제를 해결하기 위한 아키텍처 재설계가 시급했습니다. 핵심은 "한 번 번역한 문장은 우리 집 창고(DB)에 저장해 두고, 다음번에는 API를 호출하지 말고 창고에서 꺼내 쓰자"라는 '데이터베이스 캐싱(Caching)' 전략이었습니다.

저는 사용 중인 Supabase(PostgreSQL) 데이터베이스의 게시글 테이블(posts) 구조를 수정했습니다. 기존에 content 컬럼만 있던 것에 추가로 content_en (영어 번역본), content_ja (일본어 번역본) 등의 컬럼을 만들었습니다.

그리고 FastAPI 백엔드 로직을 아래와 같이 전면 수정했습니다.

외국인 유저가 100번 게시글을 조회한다.
DB의 posts 테이블을 확인하여, content_en 컬럼에 이미 번역된 데이터가 있는지 검사한다.
(캐시 히트) 만약 번역본이 저장되어 있다면? DeepL API를 쳐다보지도 않고 DB에 있는 영어 텍스트를 바로 꺼내서 보여준다. (비용 0원, 속도 0.01초)
(캐시 미스) 만약 번역본이 비어있다면(NULL)? 그때만 딱 한 번 DeepL API를 호출해 번역을 받아온 뒤, 유저에게 보여줌과 동시에 DB의 content_en 컬럼에 그 결과를 영구적으로 저장(UPDATE) 해둔다.

이 간단한 구조 변경의 효과는 그야말로 드라마틱했습니다. 어떤 인기 게시물을 1만 명의 외국인이 조회하더라도, 번역 API는 최초 1명째에 단 한 번만 호출되고 나머지 9,999명은 우리 DB에 저장된 데이터를 보게 됩니다. 번역 품질은 그대로 유지하면서, API 사용량과 청구 비용을 무려 90% 이상 썰어버리는 데 성공한 것이죠. DB 조회 속도가 API 네트워크 호출 속도보다 훨씬 빠르기 때문에, 외국인 유저들이 느끼는 페이지 로딩 속도도 눈에 띄게 개선되었습니다.

맺으며: 글로벌 서비스 확장을 꿈꾸는 1인 개발자들에게

처음에는 막연하게 "번역 API만 연동하면 다국어 지원 끝나는 거 아니야?"라고 가볍게 생각했다가, 트래픽과 비용이라는 현실적인 벽에 부딪히며 시스템 아키텍처의 중요성을 뼈저리게 배웠습니다.

다국어 처리를 위해 DeepL과 구글 번역을 저울질하고, 이를 파이썬 서버에 어떻게 부하 없이 녹여낼지 고민하는 과정은 분명 고통스러웠습니다. 하지만 한 번 탄탄하게 캐싱 시스템을 구축해 두고 나니, 이제는 구글 서치 콘솔에 미국, 일본 등 해외 국가에서 유입되는 트래픽이 찍히는 것을 보며 매일매일 큰 성취감을 느끼고 있습니다.

언어의 장벽 때문에 내가 만든 좋은 서비스가 국내에만 머무는 것이 아쉬우시다면, 파이썬과 번역 API의 조합을 통해 과감하게 세계 무대로 나가보시는 것은 어떨까요? 물론, 오늘 제가 말씀드린 'DB 번역 캐싱 구조'를 잊지 않고 꼭 챙기셔서 아까운 API 비용이 줄줄 새는 일은 없으시기를 바랍니다.