"1분반-Locauto"의 두 판 사이의 차이
cdc wiki
(→향후계획) |
(→경제적, 사회적 기대 및 파급효과) |
||
(같은 사용자의 중간 판 6개는 보이지 않습니다) | |||
125번째 줄: | 125번째 줄: | ||
====경제적, 사회적 기대 및 파급효과==== | ====경제적, 사회적 기대 및 파급효과==== | ||
− | * IT 프로덕트에 번역을 도와주는 솔루션으로 발전되었다고 | + | * IT 프로덕트에 번역을 도와주는 솔루션으로 발전되었다고 가정해본다. |
− | + | : 여러 조사에 따르면 전 세계적으로 약 3만 800여 개의 SaaS 기업이 활동 중이며, 그중 절반 이상은 직원 10명 미만의 소규모 팀으로 이루어진 스타트업들이다. | |
− | + | : 이러한 시장에서 기업들의 예상 사용량을 다음과 같이 추산할 수 있다. | |
− | : 이를 고려하여 고객당 연간 수익을 산정하면 다음과 같다. | + | :: 가격 모델은 월 $20의 구독료에 번역 사용량 기반 요금이 추가되는 형태라고 가정한다. |
− | : 우선 기본 구독료로 연 $240의 고정 수익이 발생한다. 한 고객당 3개 언어로 500단어씩 단어당 $0.02를 사용한다고 가정하면 약 $30의 번역 사용량 요금이 발생한다. | + | :: 이를 고려하여 고객당 연간 수익을 산정하면 다음과 같다. |
− | + | :: 우선 기본 구독료로 연 $240의 고정 수익이 발생한다. 한 고객당 3개 언어로 500단어씩 단어당 $0.02를 사용한다고 가정하면 약 $30의 번역 사용량 요금이 발생한다. | |
+ | :: 5%의 기업이 사용한다고 가정하면 ($240 + $30) * 30800 * 0.05 = $415,800의 연간 반복 수익이 일어날 것으로 예상된다. | ||
===기술개발 일정 및 추진체계=== | ===기술개발 일정 및 추진체계=== | ||
136번째 줄: | 137번째 줄: | ||
* 정민혁 (팀장) : 프로젝트 총괄 및 Web GUI, CLI/SDK 개발 | * 정민혁 (팀장) : 프로젝트 총괄 및 Web GUI, CLI/SDK 개발 | ||
− | * 정인호 : CLI | + | * 정인호 : CLI/SDK 개발 |
* 최용훈 : 백엔드 개발 | * 최용훈 : 백엔드 개발 | ||
− | * 이종우 : AI, Web GUI | + | * 이종우 : AI, Web GUI 개발 |
==설계== | ==설계== | ||
145번째 줄: | 146번째 줄: | ||
MVP 개발에 선택된 사용자 요구사항 | MVP 개발에 선택된 사용자 요구사항 | ||
− | * R1: 프로젝트 설정 & 코드 연결 | + | * <code>R1</code>: 프로젝트 설정 & 코드 연결 |
− | * R2: 프로젝트 생성 및 관리 | + | * <code>R2</code>: 프로젝트 생성 및 관리 |
− | * R3: 계정 및 인증 관리 | + | * <code>R3</code>: 계정 및 인증 관리 |
− | * R4: 번역 테이블 편집 및 관리 | + | * <code>R4</code>: 번역 테이블 편집 및 관리 |
− | * R5: AI 기반 자동 번역 요청 | + | * <code>R5</code>: AI 기반 자동 번역 요청 |
− | * R6: 브랜드 번역 룰 관리 | + | * <code>R6</code>: 브랜드 번역 룰 관리 |
− | * R7: 용어집(Glossary) 관리 | + | * <code>R7</code>: 용어집(Glossary) 관리 |
− | * R8: 번역 리뷰 및 수정 → AI 학습 반영 | + | * <code>R8</code>: 번역 리뷰 및 수정 → AI 학습 반영 |
− | * R9: 번역 적용 및 배포 (CLI or SDK) | + | * <code>R9</code>: 번역 적용 및 배포 (CLI or SDK) |
{| class="wikitable" | {| class="wikitable" | ||
221번째 줄: | 222번째 줄: | ||
기능 정의 | 기능 정의 | ||
− | * F1: 번역 대상 문자열 추출 | + | * <code>F1: 번역 대상 문자열 추출</code> |
: CLI를 실행해 번역 프로젝트를 로컬 코드베이스에 연동함 | : CLI를 실행해 번역 프로젝트를 로컬 코드베이스에 연동함 | ||
: 코드베이스에서 문자열(StringLiteral, JSXText 등)을 AST로 추출함 | : 코드베이스에서 문자열(StringLiteral, JSXText 등)을 AST로 추출함 | ||
: 추출된 번역 대상 문자열을 서버에 전송해 저장함 | : 추출된 번역 대상 문자열을 서버에 전송해 저장함 | ||
− | * F2: 번역 프로젝트 초기화 | + | * <code>F2: 번역 프로젝트 초기화</code> |
: CLI에서 lingotuner init 명령어를 이용하여 번역 프로젝트 초기화 | : CLI에서 lingotuner init 명령어를 이용하여 번역 프로젝트 초기화 | ||
: Web App에 로그인하여 새로운 프로젝트를 생성함 (이름, 기본 언어 지정) | : Web App에 로그인하여 새로운 프로젝트를 생성함 (이름, 기본 언어 지정) | ||
231번째 줄: | 232번째 줄: | ||
: 프로젝트 이름, 언어 설정 등을 수정하거나 삭제함 | : 프로젝트 이름, 언어 설정 등을 수정하거나 삭제함 | ||
: 각 프로젝트별로 언어별 번역 상태를 시각적으로 파악함 | : 각 프로젝트별로 언어별 번역 상태를 시각적으로 파악함 | ||
− | * F3: 마이페이지 | + | * <code>F3: 마이페이지</code> |
: 로그인한 사용자는 자신의 프로필, 이메일, 요금제(Plan)를 조회함 | : 로그인한 사용자는 자신의 프로필, 이메일, 요금제(Plan)를 조회함 | ||
: 인증 토큰을 발급받아 CLI 연동 시 사용함 | : 인증 토큰을 발급받아 CLI 연동 시 사용함 | ||
− | * F4: 번역 테이블 편집 및 관리 | + | * <code>F4: 번역 테이블 편집 및 관리</code> |
: 프로젝트별 문자열 리스트(원문, 번역)를 테이블 형태로 확인함 | : 프로젝트별 문자열 리스트(원문, 번역)를 테이블 형태로 확인함 | ||
: 각 row를 수동으로 수정하거나 직접 번역을 입력함 | : 각 row를 수동으로 수정하거나 직접 번역을 입력함 | ||
: AI 번역 버튼을 통해 한 row 또는 전체 column을 자동 번역함 | : AI 번역 버튼을 통해 한 row 또는 전체 column을 자동 번역함 | ||
: 번역 대상 언어를 추가함 (예: 영어 → 한국어, 일본어 등) | : 번역 대상 언어를 추가함 (예: 영어 → 한국어, 일본어 등) | ||
− | * F5: AI 기반 자동 번역 요청 | + | * <code>F5: AI 기반 자동 번역 요청</code> |
: 번역할 텍스트와 브랜드 룰을 함께 AI에게 전달함 | : 번역할 텍스트와 브랜드 룰을 함께 AI에게 전달함 | ||
: AI는 LLM을 사용해 다국어 번역을 생성함 | : AI는 LLM을 사용해 다국어 번역을 생성함 | ||
: 프롬프트 체인을 통해 브랜드 톤 및 용어집을 반영함 | : 프롬프트 체인을 통해 브랜드 톤 및 용어집을 반영함 | ||
: 결과는 테이블에 자동 반영되고, 사용자가 최종 수동 수정 가능함 | : 결과는 테이블에 자동 반영되고, 사용자가 최종 수동 수정 가능함 | ||
− | * F6: 용어집(Glossary) 관리 | + | * <code>F6: 용어집(Glossary) 관리</code> |
: 브랜드 고유명사, 기술 용어 등 번역 일관성이 중요한 단어들을 등록함 | : 브랜드 고유명사, 기술 용어 등 번역 일관성이 중요한 단어들을 등록함 | ||
: 다국어 용어 맵핑 테이블로 관리하며 수정, 삭제 가능함 | : 다국어 용어 맵핑 테이블로 관리하며 수정, 삭제 가능함 | ||
: 번역 시 AI가 용어집 우선 적용을 하도록 반영함 | : 번역 시 AI가 용어집 우선 적용을 하도록 반영함 | ||
− | * F7: 번역 적용 및 배포 (CLI or SDK) | + | * <code>F7: 번역 적용 및 배포 (CLI or SDK)</code> |
: CLI에서 apply 명령을 실행해 번역 완료 데이터를 코드베이스에 적용함 | : CLI에서 apply 명령을 실행해 번역 완료 데이터를 코드베이스에 적용함 | ||
: SDK를 사용하는 앱에서는 앱 로딩 시 번역 데이터를 자동으로 불러옴 | : SDK를 사용하는 앱에서는 앱 로딩 시 번역 데이터를 자동으로 불러옴 | ||
254번째 줄: | 255번째 줄: | ||
===기능 구현을 위한 세부기술 선택사항 (디자인)=== | ===기능 구현을 위한 세부기술 선택사항 (디자인)=== | ||
'''Server''' | '''Server''' | ||
− | * Framework: Spring Boot 3.4.3 | + | * Framework: <code>Spring Boot 3.4.3</code> |
− | * ORM: Spring Data JPA | + | * ORM: <code>Spring Data JPA</code> |
− | * 인증: Supabase Auth | + | * 인증: <code>Supabase Auth</code> |
− | * DB: PostgreSQL | + | * DB: <code>PostgreSQL</code> |
265번째 줄: | 266번째 줄: | ||
* 사용 프레임워크 & 사용 기술 | * 사용 프레임워크 & 사용 기술 | ||
− | : - LangChain | + | : - <code>LangChain</code> |
− | : - GPT-4.1 | + | : - <code>GPT-4.1</code> |
274번째 줄: | 275번째 줄: | ||
* 사용 프레임워크 & 사용 기술 | * 사용 프레임워크 & 사용 기술 | ||
− | : - Next.js | + | : - <code>Next.js</code> |
− | : - TypeScript | + | : - <code>TypeScript</code> |
− | : - Tailwind | + | : - <code>Tailwind</code> |
284번째 줄: | 285번째 줄: | ||
* 사용 프레임워크 & 사용 기술 | * 사용 프레임워크 & 사용 기술 | ||
− | : - Next.js(ESM) | + | : - <code>Next.js(ESM)</code> |
− | : - Babel Parser & Traverse | + | : - <code>Babel Parser & Traverse</code> |
− | : - JSX/TSX 문법 분석을 위한 AST사용 | + | : - <code>JSX/TSX 문법 분석을 위한 AST사용</code> |
− | : - Commander.js (CLI command router) | + | : - <code>Commander.js (CLI command router)</code> |
− | : - Keytar (OS 레벨 키 저장) | + | : - <code>Keytar (OS 레벨 키 저장)</code> |
− | : - Apply를 위한 LLM | + | : - <code>Apply를 위한 LLM</code> |
===시스템 설계=== | ===시스템 설계=== | ||
296번째 줄: | 297번째 줄: | ||
− | * CLI | + | * <code>CLI</code> |
: 터미널 인터페이스를 통해 서버의 데이터베이스에 있는 번역 프로젝트를 연결하여 데이터를 가져올 수 있는 커맨드를 제공함 | : 터미널 인터페이스를 통해 서버의 데이터베이스에 있는 번역 프로젝트를 연결하여 데이터를 가져올 수 있는 커맨드를 제공함 | ||
: 주로 코드 베이스에 있는 String들을 추출하고 이를 대체하는 기능을 제공함 | : 주로 코드 베이스에 있는 String들을 추출하고 이를 대체하는 기능을 제공함 | ||
− | * WEB APP (Frontend) | + | * <code>WEB APP (Frontend)</code> |
: 번역될 데이터들을 관리할 간편한 웹 어플리케이션 | : 번역될 데이터들을 관리할 간편한 웹 어플리케이션 | ||
: 관리자가 이용하기 쉽도록 GUI를 구성하여 사용할 수 있는 기능을 제공함 | : 관리자가 이용하기 쉽도록 GUI를 구성하여 사용할 수 있는 기능을 제공함 | ||
− | * SERVER (Backend) | + | * <code>SERVER (Backend)</code> |
: 번역 데이터 및 원본 데이터 저장 | : 번역 데이터 및 원본 데이터 저장 | ||
: CLI/WEB-APP/AI에서 사용할 API들을 노출함 | : CLI/WEB-APP/AI에서 사용할 API들을 노출함 | ||
− | * AI | + | * <code>AI</code> |
: 브랜드 톤 앤 매너 학습 및 번역 기능 제공 | : 브랜드 톤 앤 매너 학습 및 번역 기능 제공 | ||
: 멀티 에이전트로 높은 번역 품질을 제공함 | : 멀티 에이전트로 높은 번역 품질을 제공함 | ||
483번째 줄: | 484번째 줄: | ||
===완료 작품의 소개=== | ===완료 작품의 소개=== | ||
====프로토타입 사진==== | ====프로토타입 사진==== | ||
− | [번역 전] | + | <code>[번역 전]</code> |
[[File: Locauto8.png]] | [[File: Locauto8.png]] | ||
− | [번역 후] | + | <code>[번역 후]</code> |
[[File: Locauto9.png]] | [[File: Locauto9.png]] |
2025년 6월 18일 (수) 04:13 기준 최신판
프로젝트 개요
기술개발 과제
국문 : SMB 소프트웨어 비즈니스를 위한 간편한 랜딩페이지 로컬라이제이션 툴
영문 : Easy landing page localization tools for SMB software businesses
과제 팀명
Locauto
지도교수
이경재 교수님
개발기간
2025년 3월 ~ 2025년 6월 (총 4개월)
구성원 소개
서울시립대학교 컴퓨터과학부 20199200** 정*혁(팀장)
서울시립대학교 컴퓨터과학부 20199200** 정*호
서울시립대학교 컴퓨터과학부 20199200** 최*훈
서울시립대학교 컴퓨터과학부 20209200** 이*우
서론
개발 과제의 개요
개발 과제 요약
- SMB 소프트웨어 비즈니스를 위한 간편한 프로덕트 로컬라이제이션 툴이다.
- 사용자는 CLI 및 WEB GUI을 조작하여 코드를 적용하여 페이지를 변환하고, SDK가 자동으로 번역 결과를 렌더링한다.
- 웹앱을 통해 번역의 세부 사항 및 기타 설정을 변경한다.
개발 과제의 배경 및 효과
- SMB는 글로벌 진출 기회를 이용하고 싶으므로, 로컬라이제이션을 하고 싶어 한다.
- 그러나 '로컬라이제이션'이라는 과정은 굉장히 노동집약적이므로, 소규모의 소프트웨어 비즈니스는 리소스가 부족하다고 느낀다.
- 본 프로젝트를 이용하면 ‘로컬라이제이션’의 과정을 자동화하여 코드 수정, 번역, 적용의 단계를 10분 안에 마칠 수 있다.
- 브랜드와 문맥, 사용자 설정을 반영하는 AI 번역 서비스로 오류 없는 메시지를 명확히 전달한다.
- 다만 모든 IT 프로덕트를 번역하는 서비스로 만들기에는 ‘컴퓨터과학종합설계’ 내에서는 어려우므로, 랜딩페이지에 집중하여 우선적으로 개발하려고 한다.
개발 과제의 목표 및 내용
목표
- 자동화된 로컬라이제이션 환경 구축을 위한 CLI, SDK, 웹앱 개발
- AI를 활용한 브랜드 톤 및 용어의 일관성 있는 자동 번역 제공
- 번역 품질과 현지화 정확도 향상 및 관리 효율화
- 쉽고 빠르게 사용 가능한 사용자 인터페이스 제공
CLI 개발
-
localize init
: 번역 프로젝트 초기화 -
localize extract
: 프로젝트의 문자열 데이터를 추출 및 문자열 데이터를 비교하여 변경사항 추적 -
localize push
: 프로젝트 디렉토리의 추출된 문자열 데이터를 서버에 전송 -
localize pull
: 서버에서 최신 번역 데이터를 받아 프로젝트 파일 내 저장 -
localize apply
: 코드베이스를 읽으면서 문자열 자동 업데이트 -
localize translate
: 서버에서 최신 번역 데이터를 받아 프로젝트 파일 내 문자열 자동 업데이트
SDK 개발
- 초기화 시 사용자 locale 설정
- TypeScript 타입 자동 생성 및 로컬라이제이션 파일 export
- 언어 변경 기능 수동 제공
- Next.js 프레임워크를 우선적으로 적용
서버 개발
- CLI에서 전송된 데이터 수신 및 구조화 매핑
- 번역 데이터 버전 관리 및 변경사항 추적
- 웹앱 대시보드를 위한 CRUD API 제공
- AI 번역 모델과 연계하여 문맥 기반 자동 번역
- 텍스트 유형(제목, 버튼, 설명 등)에 따라 최적화된 번역 프롬프트 개발
대시보드 개발
- 언어별 번역 데이터 입력 및 저장
- 향후 검색 및 필터링 기능 확장 가능 구조 마련
관련 기술의 현황
관련 기술의 현황 및 분석
가. State of art
- 자동 기계번역: 신경망 기계번역(NMT)의 품질 향상으로, 번역 워크플로우에 자동 번역을 도입하는 것이 일반화되었다. 2024년 기준 전체 번역 작업의 70%가 기계 번역의 도움을 받는 형태로 진행되고 있을 정도로 확대되었으며, 이는 전년 대비 크게 증가한 수치이다. 기업들은 번역 초안을 AI가 생성하고 인간이 후기 편집하는 MTPE(Machine Translation Post-Editing)방식으로 생산성을 높이고 있다. 특히 GPT, Claude 등 대형 언어모델(LLM)기반 번역이 전통적인 번역 엔진을 능가하는 정확도를 보이며 새롭게 주목받고 있다.
- 코드베이스 해석기: 리액트(React)와 타입스크립트(TypeScript) 파일을 파싱하는 최신 기술은 주로 다음과 같은 도구와 라이브러리를 활용한다.
- 타입스크립트 컴파일러 API (TypeScript Compiler API): 타입스크립트 자체에서 제공하는 컴파일러 API를 사용하여 TSX 파일을 파싱하고, 추상 구문 트리(AST)를 생성하여 코드 구조를 분석할 수 있다.
- Babel: Babel은 자바스크립트 컴파일러로,
@babel/preset-react
와@babel/preset-typescript
프리셋을 사용하여 TSX 파일을 파싱하고 변환할 수 있다. 이를 통해 최신 문법을 구버전 자바스크립트로 트랜스파일하거나, 코드 분석을 위한 AST를 생성할 수 있다. - ESLint: 코드 품질과 일관성을 유지하기 위한 린터 도구로,
@typescript-eslint/parser
를 사용하여 TSX 파일을 파싱하고, 코드 규칙을 적용하여 정적 분석을 수행할 수 있다.
나. 기술 로드맵
- MVP 기능 구현
- 웹 문자열 추출 엔진 개발: 사용자 코드베이스에서 본문 텍스트와 일부 속성값(alt, title 등)을 식별 및 추출.
- 추출된 텍스트를 구조화하여 백엔드로 전송하고 데이터베이스에 저장.
- 번역 API 호출을 통해 각 타깃 언어로 기계 번역된 초안 생성.
- 번역 완료 후, 수정된 텍스트를 코드베이스에 적용하는 기능 구현.
시장상황에 대한 분석
가. 경쟁제품 조사 비교
- 글로벌 SaaS 스타트업을 위한 랜딩페이지 로컬라이제이션 툴과 유사한 기능을 제공하는 주요 경쟁 제품으로 Lokalise, Crowdin, Localazy, POEditor 등이 있으며, 자동 번역 엔진으로 Google Translate와 DeepL도 활용되고 있다.
- vs 자동 번역 엔진
- 자동 번역 엔진은 Google Translate, DeepL과 같은 전문 번역 툴을 의미한다.
- Pros: 자동 번역 엔진은 일반적인 상황에서 높은 번역 품질을 자랑하고 광범위한 언어 지원한다
- Cons: 맥락 고려 부족으로 어색한 번역이 존재한다. 전문용어/업계용어 정확도 한계가 존재하며, 브랜드가 원하는 톤앤 매너로 일관성있게 번역하기 힘들다.
- vs 로컬라이제이션 툴
- 로컬라이제이션 툴은 Lokalise, Crowdin 같은 앱의 에셋을 관리 및 번역을 도와주는 툴을 의미한다.
- - Lokalise
- Pros: 많은 통합 기능과 풍부한 기능 세트, 포괄적인 지원 옵션(이메일/헬프 데스크, 채팅, 지식 베이스, 24/7 실시간 지원 등)을 제공한다.
- Cons: SMB가 진입하기에는 가격이 높다. 소규모 프로젝트에는 과복잡한 기능 셋이다.
- - Crowdin
- Pros: 오픈소스 프로젝트로 스타트업 개발자에게 친숙한 이미지를 쌓았고, 600여개의 통합을 내세워 자동화/개발 워크플로우에 강점이 있다.
- Cons: 신속한 초기 설정이 불가능하다. 개발자나 일일히 코드베이스에서 sdk 문법에 따라서 작성해줘야한다. 따라서 작은 규모의 스타트업이 제대로 도입하기 위해서는 허들이 있다.
나. 마케팅 전략 제시
- 포지셔닝: 경쟁사들은 각자 대상 고객(대기업/스타트업/개인)과 강조 포인트(풍부한 기능 vs 자동화 vs 가격 등)이 다르다. 우리 제품은 SMB를 위한 간편한 로컬라이제이션이라는 컨셉에 맞게, 쉬운 사용성, 즉각적인 결과(자동 번역), 가성비 등을 전면에 내세워 마케팅한다. 이를 통해 글로벌 시장을 노리는 스타트업에게 “낮은 진입장벽의 필요한 기능만 담은 최적화된 솔루션”으로 포지셔닝한다.
- 초기 시장 진입 채널: 소규모 개발자들을 타겟하고 있으므로 인스타그램, 쓰레드, geek news 등의 마케팅 채널을 타겟팅한다.
개발과제의 기대효과
기술적 기대효과
- 본 프로젝트를 통해 개발되는 로컬라이제이션 툴은 기존 대비 뛰어난 자동화 수준과 사용자 경험을 제공함으로써 여러 기술적 혁신을 이끌 것으로 기대한다.
- 높아진 자동화로 인한 생산성 향상
- 기존 툴에서는 개발자가 소스 문구를 추출하고, 번역 완료 후 수동으로 사이트에 반영하는 작업이 필요했다. 반면 본 제품은 이러한 과정을 자동화하여, 번역 필요 문구 감지 → 기계번역 → 편집까지의 사이클을 최소한의 인력 개입으로 완료한다. 이를 통해 IT 프로덕트를 다국어로 개설하는 데 걸리는 시간이 획기적으로 단축된다 (과거 수일 소요 작업을 몇 시간 내로 단축).
- 사용 편의성 혁신
- 기술적으로 아무리 뛰어나도 최종 사용자가 어려움을 느끼면 도입이 망설여진다. 본 제품은 진입장벽을 최소로 빠르게 적용할 수 있는 쉬운 UI/UX를 지향하여, 소규모 스타트업에서도 쉽게 직접 다국어 페이지를 만들 수 있게 된다. 이는 곧 기업 로컬라이제이션 프로세스의 보편화로 이어져, 프로덕트의 글로벌 대응이 가능한 업무 혁신을 가져온다
경제적, 사회적 기대 및 파급효과
- IT 프로덕트에 번역을 도와주는 솔루션으로 발전되었다고 가정해본다.
- 여러 조사에 따르면 전 세계적으로 약 3만 800여 개의 SaaS 기업이 활동 중이며, 그중 절반 이상은 직원 10명 미만의 소규모 팀으로 이루어진 스타트업들이다.
- 이러한 시장에서 기업들의 예상 사용량을 다음과 같이 추산할 수 있다.
- 가격 모델은 월 $20의 구독료에 번역 사용량 기반 요금이 추가되는 형태라고 가정한다.
- 이를 고려하여 고객당 연간 수익을 산정하면 다음과 같다.
- 우선 기본 구독료로 연 $240의 고정 수익이 발생한다. 한 고객당 3개 언어로 500단어씩 단어당 $0.02를 사용한다고 가정하면 약 $30의 번역 사용량 요금이 발생한다.
- 5%의 기업이 사용한다고 가정하면 ($240 + $30) * 30800 * 0.05 = $415,800의 연간 반복 수익이 일어날 것으로 예상된다.
기술개발 일정 및 추진체계
구성원 및 추진체계
- 정민혁 (팀장) : 프로젝트 총괄 및 Web GUI, CLI/SDK 개발
- 정인호 : CLI/SDK 개발
- 최용훈 : 백엔드 개발
- 이종우 : AI, Web GUI 개발
설계
사용자 요구사항
MVP 개발에 선택된 사용자 요구사항
-
R1
: 프로젝트 설정 & 코드 연결 -
R2
: 프로젝트 생성 및 관리 -
R3
: 계정 및 인증 관리 -
R4
: 번역 테이블 편집 및 관리 -
R5
: AI 기반 자동 번역 요청 -
R6
: 브랜드 번역 룰 관리 -
R7
: 용어집(Glossary) 관리 -
R8
: 번역 리뷰 및 수정 → AI 학습 반영 -
R9
: 번역 적용 및 배포 (CLI or SDK)
번호 | 요구사항 | 중요도 | 비고 |
---|---|---|---|
1 | 다국어 지원 | 대 | MVP 제작 |
2 | 수정을 위한 웹 애플리케이션 제공 | 대 | MVP 제작 |
3 | 브랜드 톤 학습 번역 기능(용어집) | 대 | MVP 제작 |
4 | CLI 제공 | 대 | MVP 제작 |
5 | SDK 제공 | 대 | MVP 제작 |
6 | 다양한 파싱 엔진 제공 | 중 | 희망 |
7 | 기계 번역 API 연동 | 중 | 희망 |
8 | 실시간 미리보기 | 중 | 희망 |
9 | 외부 에이전시 협업 기능 | 소 | 희망 |
10 | 분석 및 리포팅 | 소 | 희망 |
11 | SEO 최적화 프롬프팅 지원 | 소 | 희망 |
사용자 요구사항 만족을 위한 기능 정의
기능 정의
-
F1: 번역 대상 문자열 추출
- CLI를 실행해 번역 프로젝트를 로컬 코드베이스에 연동함
- 코드베이스에서 문자열(StringLiteral, JSXText 등)을 AST로 추출함
- 추출된 번역 대상 문자열을 서버에 전송해 저장함
-
F2: 번역 프로젝트 초기화
- CLI에서 lingotuner init 명령어를 이용하여 번역 프로젝트 초기화
- Web App에 로그인하여 새로운 프로젝트를 생성함 (이름, 기본 언어 지정)
- 기존 프로젝트 목록을 조회하고, 최근 업데이트 상태를 확인함
- 프로젝트 이름, 언어 설정 등을 수정하거나 삭제함
- 각 프로젝트별로 언어별 번역 상태를 시각적으로 파악함
-
F3: 마이페이지
- 로그인한 사용자는 자신의 프로필, 이메일, 요금제(Plan)를 조회함
- 인증 토큰을 발급받아 CLI 연동 시 사용함
-
F4: 번역 테이블 편집 및 관리
- 프로젝트별 문자열 리스트(원문, 번역)를 테이블 형태로 확인함
- 각 row를 수동으로 수정하거나 직접 번역을 입력함
- AI 번역 버튼을 통해 한 row 또는 전체 column을 자동 번역함
- 번역 대상 언어를 추가함 (예: 영어 → 한국어, 일본어 등)
-
F5: AI 기반 자동 번역 요청
- 번역할 텍스트와 브랜드 룰을 함께 AI에게 전달함
- AI는 LLM을 사용해 다국어 번역을 생성함
- 프롬프트 체인을 통해 브랜드 톤 및 용어집을 반영함
- 결과는 테이블에 자동 반영되고, 사용자가 최종 수동 수정 가능함
-
F6: 용어집(Glossary) 관리
- 브랜드 고유명사, 기술 용어 등 번역 일관성이 중요한 단어들을 등록함
- 다국어 용어 맵핑 테이블로 관리하며 수정, 삭제 가능함
- 번역 시 AI가 용어집 우선 적용을 하도록 반영함
-
F7: 번역 적용 및 배포 (CLI or SDK)
- CLI에서 apply 명령을 실행해 번역 완료 데이터를 코드베이스에 적용함
- SDK를 사용하는 앱에서는 앱 로딩 시 번역 데이터를 자동으로 불러옴
기능 구현을 위한 세부기술 선택사항 (디자인)
Server
- Framework:
Spring Boot 3.4.3
- ORM:
Spring Data JPA
- 인증:
Supabase Auth
- DB:
PostgreSQL
번역 AI
- 사용 프레임워크 & 사용 기술
- -
LangChain
- -
GPT-4.1
Dashboard
- 사용 프레임워크 & 사용 기술
- -
Next.js
- -
TypeScript
- -
Tailwind
CLI
- 사용 프레임워크 & 사용 기술
- -
Next.js(ESM)
- -
Babel Parser & Traverse
- -
JSX/TSX 문법 분석을 위한 AST사용
- -
Commander.js (CLI command router)
- -
Keytar (OS 레벨 키 저장)
- -
Apply를 위한 LLM
시스템 설계
-
CLI
- 터미널 인터페이스를 통해 서버의 데이터베이스에 있는 번역 프로젝트를 연결하여 데이터를 가져올 수 있는 커맨드를 제공함
- 주로 코드 베이스에 있는 String들을 추출하고 이를 대체하는 기능을 제공함
-
WEB APP (Frontend)
- 번역될 데이터들을 관리할 간편한 웹 어플리케이션
- 관리자가 이용하기 쉽도록 GUI를 구성하여 사용할 수 있는 기능을 제공함
-
SERVER (Backend)
- 번역 데이터 및 원본 데이터 저장
- CLI/WEB-APP/AI에서 사용할 API들을 노출함
-
AI
- 브랜드 톤 앤 매너 학습 및 번역 기능 제공
- 멀티 에이전트로 높은 번역 품질을 제공함
- 사용자 Rule 및 용어집 학습으로 브랜드 최적화된 번역 제공
이론적 계산 및 시뮬레이션
- Codebase에서 적절한 String을 자동으로 뽑아내기
- 이론적 배경 및 계산: 현Typescript 및 React 계열의 프레임워크만 지원할 예정이므로 1개의 언어만 지원한다고 가정한다. TypeScript의 Compiler API나 Babel을 활용하여 코드로부터 AST를 생성한 뒤, 특정 노드 유형(StringLiteral, JSXText, JSXAttribute)을 타겟하여 추출한다. 이를 통해 룰 기반으로 특정 조건을 정의할 수 있으며 String 연산 등 정적 분석으로 불가능한 부분은 MVP 단계에서 고려하지 않는다.
- AI에서 높은 품질의 번역 생성하기
- 제약 조건을 고려한 프롬프트 체인: 중요 키워드나 용어의 정확한 번역을 보장하기 위해, LLM은 특정 제약 조건을 부여하는 프롬프트 체인을 활용하여 번역의 충실도를 높일 수 있다.
- 용어집 반영 및 수정 메커니즘: LLM은 생성된 번역문을 자체적으로 분석하여 오류나 부정확한 부분을 식별하고, 이를 기반으로 수정된 번역문을 생성할 수 있다. 이 과정에서 용어집의 데이터를 참고하고, 맥락을 고려하여 보다 자연스럽고 정확한 번역을 추구한다.
하드웨어 설계
- 소프트웨어 시스템으로, 별도의 물리적 하드웨어 설계가 요구되지 않는다.
소프트웨어 설계
Backend(Spring Boot 3.4.3)
- 주요 엔티티: User, Project, Asset, Label
- ORM: Spring Data JPA (with QueryDSL)
- 인증: Supabase Auth JWT 인증 → Spring Security Filter 연동
- REST API 구조:
Controller | Method & Endpoint | 설명 |
---|---|---|
account-key-controller | GET /api/account-keys | key 조회 |
POST /api/account-keys | key 생성 | |
GET /api/account-keys/projects | 계정 프로젝트 목록 | |
DELETE /api/account-keys/{accountKeyId} | account key 삭제 | |
glossary-controller | PUT /api/projects/{projectId}/glossaries/{glossaryId} | 단어집 수정 |
DELETE /api/projects/{projectId}/glossaries/{glossaryId} | 단어집 삭제 | |
GET /api/projects/{projectId}/glossaries | 단어집 조회 | |
POST /api/projects/{projectId}/glossaries | 단어집 생성 | |
cli-controller | POST /api/cli/{projectId}/localize | CLI 용 번역 |
POST /api/cli/projects | 프로젝트 생성 | |
project-controller | GET /api/projects | 프로젝트 리스트 조회 |
POST /api/projects | 프로젝트 생성 | |
GET /api/projects/{id} | 단일 프로젝트 조회 | |
DELETE /api/projects/{id} | 프로젝트 삭제 | |
PATCH /api/projects/{id} | 프로젝트 정보 수정 | |
pull/push-controller | POST /api/push | CLI PUSH |
GET /api/pull/{projectId} | CLI PULL | |
resource-controller | GET /api/resources/assets/{projectId}/{locale} | project locale 에셋 추출 |
rule-controller | GET /api/projects/{projectId}/rules | 프로젝트 번역 규칙 조회 |
PUT /api/projects/{projectId}/rules | 프로젝트 번역 규칙 수정 | |
table-controller | PUT /api/projects/{projectId}/tables/rows/{rowId} | 테이블 ROW 직접 수정 |
POST /api/projects/{projectId}/tables/localize | 테이블 localize | |
POST /api/projects/{projectId}/tables/columns | 테이블 COLUMN 추가 | |
GET /api/projects/{projectId}/tables | 번역 테이블 조회 | |
user-controller | POST /api/users | user 생성 |
CLI Tool(Node.js)
- 주요 명령어
명령어 설명 lingotuner signin API 키 인증 및 저장 lingotuner init 프로젝트 생성/선택 및 프로젝트 키 저장 lingotuner extract Babel 기반 JSX 파싱, 라벨 JSON 생성 lingotuner push/pull REST API로 서버 전송/수신 lingotuner translate 프로젝트에 Push된 Asset 번역 lingotuner apply AI 기반 사용자 코드 수정 → 라벨 키 적용
- 내부 구조: commander, @babel/core, fs-extra
SDK(Runtime)
- 역할
- 사용자 locale에 따라서 적절한 string을 불러옴
- SSR 대응
- middleware를 통해 클라이언트의 locale을 감지하여 적절한 url로 리다이렉트 및 accept-language 서버로 전달. url 및 헤더로 브라우저 언어 감지 후 context 전달
예외 처리 및 안정성
- CLI
- config 경로 오류, asset JSON 오류, 통신 실패 등 예외별 친절한 로그 제공
- Backend
- 글로벌 예외 처리기 (Spring @ControllerAdvice)
- 인증 실패, 프로젝트 미존재, 중복 라벨 등에 대한 상세 응답 코드
결과 및 평가
완료 작품의 소개
프로토타입 사진
[번역 전]
[번역 후]
관련사업비 내역서
구분 | 항목 (품명, 규격) |
수량 | 단가 | 금액(단위: 천원) | 비고 | |
---|---|---|---|---|---|---|
계 | 현금 | |||||
직접개발비 | ChatGPT (1달 기준) | 11 | 30.1 | 331 | 331 | |
Cursor (1달 기준) | 1 | 29 | 201 | 201 | ||
AI 토큰 사용 비용 | 1 | 18 | 18 | 18 | ||
합계 | 550 | 550 |
완료작품의 평가
평가 항목 | 평가방법 | 적용기준 | 개발 목표치 | 비중 (%) | 평가결과 |
---|---|---|---|---|---|
1. 처리 속도 | 번역 시작에서 적용까지 걸리는 시간 측정 | 시스템 로그 측정 | 10분 이내 완료 | 25% | 25 |
2. 용어 일관성 | 용어집 매칭률 검사 | 용어집 기준 적용 여부 | 95% 이상 | 20% | 20 |
3. 자동화 수준 | 시스템 내 개입 필요성 측정 | 시스템 작동 로그 및 인터랙션 분석 | 95% 이상 자동화 | 25% | 20 |
4. 번역 품질 | 완성된 번역본의 품질 평가 | 기계번역 상대 설문 평가 | 70% 이상 | 30% | 25 |
향후계획
가. 어려웠던 내용들
- GPT-4.1을 사용한 번역 모델에서, "+ 맥락: 소프트웨어 구독 서비스"라는 것을 번역해야 하는데, 번역하지 않고 이것을 시스템 프롬프트처럼 입력을 받는 것으로 이해하여 출력 오류가 발생하는 상황이 있었다. 따라서 <source_texts>와 같이 태그로 맥락을 구분하는 것과, 출력된 번역 결과의 label을 비교하여, 적절하게 생성되지 않거나 누락된 label만 반복하여 번역을 시도하는 방식으로 수정을 시도하였다.
- Next.js를 사용하여 사용자 대시보드를 개발하고 있다. layout.tsx에서 번역 항목을 표시하는 Table 컴포넌트를 children으로 넘기는 구조이다. 문제는, layout에서 project 데이터를 불러온 후 이 데이터를 기반으로 Table에서 값을 불러오도록 설계했는데, 실제 실행 순서를 보니 Table이 layout보다 먼저 렌더링되는 상황이 발생된다. 그 결과, project 데이터가 준비되기 전에 Table이 먼저 렌더링되어 이전 Table값이 화면이 표시되고, 깜빡임 현상도 함께 발생한다. 이 문제를 해결하기 위해, 각 페이지 진입 시 project 값을 null로 초기화하고, 데이터가 준비되면 Table이 다시 렌더링되도록 로직을 추가하여 해결하였다.
- SSR(Server Side Rendering)과 CSR(Client Side Rendering)을 함께 사용하는 현대 웹 개발 환경에서는, 동일한 코드베이스에서 국제화(i18n)를 적용하는 것이 상당히 복잡하게 느껴졌다. 특히 JSON 기반의 번역 파일을 SSR과 CSR 모두에서 일관되게 적용하려다 보니 여러 가지 문제에 직면했다. 먼저 어려웠던 점은 초기 렌더링 시점의 불일치이다. SSR에서는 서버가 HTML을 렌더링할 때 이미 번역이 적용된 콘텐츠를 만들어야 하기 때문에, 서버 코드가 정확한 언어를 인식하고 그에 맞는 번역 파일을 불러와야 한다. 반면 CSR에서는 브라우저가 JavaScript를 실행한 후 클라이언트 측에서 번역 파일을 비동기적으로 불러오고 적용하기 때문에, 서버에서 렌더링한 내용과 클라이언트가 최종적으로 보여주는 내용이 일치하지 않을 수 있다. 이를 해결하기 위해서 추가적으로 url에서 language를 주는 방법이 필요했는데, 이는 사용자가 수동으로로 설정해야할 것들이 추가되어 불안정한 것 중 하나이다.
나. 차후 구현할 내용
- 높은 번역 품질을 보장해도, 신뢰성에 대한 피드백을 잠재고객들이 제기했다. 이는 꽤 정확한 AI를 사용하더라도 인간 개입이 없으면 신뢰성을 주지 못한다. 따라서 각 지역의 원어민이나 문화를 잘 아는 번역가가 검토해주는 단계를 보장해주려고 한다. 이는 Optional하게 판매할 서비스이며 이를 위한 웹 UI가 필요하다고 판단된다.
- 현재는 랜딩페이지를 위주로 번역을 진행했다. 다만 본래 목적은 IT 프로덕트 전체를 번역을 손쉽게 도와주는 것이기 때문에 스트링 추출과정과 적용과정이 더 고도화되어야한다. 이를 위한 기술 고도화 과정이 추가적으로 필요하다.
- 현재는 Lambda 내부에서 처리량을 제한하기 위해 스프링 내부에서 sleep 및 순차 처리 방식으로 구현했으나, 이는 유휴 시간 동안 리소스를 점유하게 되어 확장성에 한계가 존재한다. 향후에는 SQS나 Kafka 등의 외부 큐 시스템을 도입하여 비동기적으로 작업을 분산 처리하고, Lambda는 큐에 쌓인 메시지를 소비(consume)하는 방식으로 전환함으로써 시스템의 안정성과 유연성을 높일 수 있다.
- 구독 등에 관련된 사용량 제한이나 과금 체계
- 현재는 asset 데이터를 서버에서 직접 받아와 클라이언트에 렌더링하고 있으나, 일반 사용자 유입이 늘어날 경우 서버 부하 및 응답 속도 저하가 우려된다. 이에 따라 이미지 및 정적 파일을 CDN을 통해 서빙하여 응답 속도를 개선하고, 서버 리소스를 효율적으로 분산할 계획이다.
특허 출원 내용
-