비하인드
글로벌버전 웹사이트 개발 with GPT & Copilot

웹사이트를 개발하다보면 자국어만을 기준으로 할 수도 있지만, 특히나 글로벌로 판매가 가능한 SaaS 서비스라면 무언가 아쉬운 느낌이 듭니다. 그렇다고 거창하게 글로벌을 노리고 제작하기에는 생각보다 품이 많이 들어 부담스럽습니다. 저희팀은 아래와 같은 우리만의 야매방법으로 고민을 해결하고 있습니다.

사용자 메시지처리

변수처리 방식의 단점

일반적인 i18n 라이브러리 등은 아래와 같은 방식으로 다국어를 처리합니다. 각 메시지의 키를 만들고, 해당 키에 상응하는 사용자의 언어별 표시를 하는 것입니다. 언뜻보면 가장 합리적인 방법처럼 보입니다.

const helloMessage = {
  ko: "안녕하세요",
  en: "Hello",
  ja: "こんにちは",
};
const userLang = 'ko';
alert(helloMessage[userLang]);

이 방식은 가장 간단한 형태의 다국어버전 구동방식을 표현합니다. 비즈니스가 성장함에 따라 다양한 다국어를 유연하게 추가할 수 있다는 장점이 있습니다. 하지만 비즈니스가 적절하게 성장한 상태가 아닐 때에, 소수의 개발팀에서 작업할 때에는 아래와 같은 과도기적인 문제가 있습니다.

UI를 구현하며 수많은 에러 및 사용자 메시지를 작성함에 있어서, 언어 키를 네이밍하고 확보해야하는 문제가 생깁니다.
각 언어별 번역하는 문제가 생깁니다(이는 외부 서비스 및 GPT로 어느정도 보완 가능)
이미 기존에 활용한 키가 있는지 검토하고 없는 경우에 추가하도록 검색을 하게 됩니다.
코드 수정을 유발하는 어떤 메시지가 유저로부터 발견되었을 때, 관련 언어키를 먼저 검색 후 오류위치를 찾게 됩니다.

사소한 잡일들이지만 사용자 메시지와 맞닿은 프론트쪽 개발을 하다보면, 이러한 과정으로 인해서 안그래도 부족한 개발 리소스가 낭비되게 됩니다.

코드에 녹이는 언어별 메시지

이러한 불편을 최소화하고자 비디오스튜팀은 자국어 단일 버전을 개발하는 속도로 다국어 버전을 개발하고 있습니다. 대신 다국어버전을 "영어" 하나로만 국한하고 있습니다. 추후에 시장이 넓어짐에 따라 이 방식은 유지될 수 없겠지만, 적어도 "영어" 사용가능한 유저층에게 어필하는 글로벌 초기단계에서는 아주 유용하게 사용하고 있습니다.

비디오스튜팀은 백엔드와 프론트에 d(irect)trans라는 global 헬퍼를 등록하고 씁니다. 이 코드의 구현은 아주 심플합니다. 첫번째 파라미터로 모국어인 한글 메시지를 받고, 두번째 파라미터로는 글로벌인 영어 메시지를 받습니다.

function dtrans(ko = '', en = ''){
  return userLang === 'ko' || en ==='' ? ko : en;
}

아래와 같이 유저에게 노출되는 메시지가 나타나는 부분은 단순히 아래와 같이 만들면 됩니다.

...(중략)
if (block === undefined){
  return alert(
    dtrans(
      '블록이 존재하지 않습니다',
      'No block exists'
    )
  );
}

이렇게 보면 어차피 코드짜면서 영어 번역해야하는거 아니냐 할 수 있지만, 코파일럿과 함께 사용하면 절대 그렇지 않습니다. 코파일럿은 혹은 Cursor AI 도구를 사용하면, 내가 자주사용하는 헬퍼 혹은 열려있는 탭의 함수정의, 입력된 패턴을 참고하기 때문에 위와 같이 자주 쓰는 헬퍼의 용법은 아주 잘 이해합니다.

아래와 같이 dtrans('.. 하고 한글을 입력하면, 바로 두번째 파라미터가 번역된 영어 메시지가 들어가는 것을 유추하므로, 에디터상에서 코드를 짜면서 글로벌 버전을 바로 만들어낼 수 있습니다.

< 모국어인 한글만 타이핑하면, 자동번역된 영어가 추가됨 >

이 방식으로 진행하면 위에서 언급한 정석적인 글로벌 버전의 개발 단점을 모두 극복할 수 있습니다.

코드를 짜면서 유저메시지를 모국어로 적으므로 별도의 번역 시스템을 사용할 필요가 없게되어 코드를 짜는데 지체되는 시간이 없습니다.
기존 키랑 무관하게 필요한 메시지를 바로바로 작성하면 됩니다(물론 중복메시지로 인한 코드가 길어지는 단점은 있지만, 생각보다 중복메시지는 별로 없습니다)
노출된 사용자 메시지를 기반으로 코드 부분을 찾을 때 빠르게 찾을 수 있습니다(메시지 자체가 코드에 있으므로)

앞서 언급한대로 이 방식은 힘을 들이지 않고 글로벌 버전을 빠르게 구현하는데에 목적이 있습니다. 보다 정교한 번역 품질이나 여러 언어버전을 만들기에는 적합하지 않은 방식입니다. 서비스가 성장함에 따라 언어 시스템은 변경을 해야합니다.

가이드 & 블로그의 자동 번역

코드에 들어가는 사용자 메시지 외에 서비스에는 수많은 메시지와 글이 동원됩니다. 랜딩페이지나 약관 등의 고정된 페이지는 1회성으로 번역을 해서 넣으면 그만이지만, 가이드나 블로그 같이 유동적으로 생성되고 수정되는 글에 대해서는 수작업으로 팔로우하기가 힘든 단점이 있습니다.

이에 비디오스튜에서는 게시글을 모국어인 한글로 등록하고, 일정한 시간후에 자동으로 수정된 부분을 추정하여 백엔드에서 GPT 모델을 이용하여 영어로 번역합니다. 번역에 관한 여러 API 서비스가 있을 수 있지만, LLM을 통한 번역시 아래와 같은 장점이 있습니다.

문체를 우리가 원하는대로 자연스럽게 설정할 수 있습니다.
시스템 메시지를 통해서 우리 서비스의 분야와 특성을 감안한 번역이 가능합니다.
전문 용어/사이트에서만 쓰는 특수한 용어들에 대한 오번역을 막을 수 있습니다.

실제 적용함에 있어서 텍스트가 큰 가이드의 경우(거의 책 한권 분량)은 수정시마다 전체를 번역하는 것이 불가능합니다. 따라서 아래와 같이 문단별로 내용을 기반으로 해시키를 만들고, 변경되는 문단만 추적해서 자동 번역을 돌리고 있습니다.

< 변화되는 문단만을 수정하기 위한 해시값 >

이러한 호출 타입은 (저희는 사용하고 있지 않지만) GPT의 대량 호출 할인을 사용하면 더 저렴하게 대량 번역이 가능할 듯합니다.

고객센터 대응

저희는 완벽한 서비스 경험 제공을 위하여 외부의 챗봇을 쓰지 않고 자체 챗봇을 사용중입니다. 사실 챗봇은 아니고 실시간 댓글이 가능한 저희의 게시판을 변형해서 사용하고 있습니다. 사용자의 정보가 모국어가 아닌 사용자의 경우에는, 자동으로 모국어를 첨부해서 원본과 보여줍니다. 우리가 모국어로 답변하면 이는 다시 사용자의 언어로 번역해서 전달됩니다.