한국어 Text2SQL 프로젝트 - Part 1: 번역한 데이터셋의 품질 개선하기
2025년 상반기에 가짜연구소의 Hugging Face Hub Garden 스터디에서는 Text2SQL 한국어 데이터셋 구축 프로젝트가 진행되었습니다.
이번 포스트에서는 Spider 데이터셋을 한국어로 번역하면서 발견한 다양한 문제점들과 이를 해결하여 데이터셋 품질을 개선한 과정을 자세히 공유하려고 합니다.
프로젝트 배경과 목표
왜 한국어 Text2SQL 데이터셋이 필요할까요?
최근 AI의 도움으로 다양한 업무 영역에서 생산성이 크게 향상되고 있습니다. 데이터 분야도 마찬가지로, 많은 데이터 웨어하우스 서비스에서 구성원들이 전문적인 SQL 지식 없이도 데이터를 쉽게 활용할 수 있도록 AI 어시스턴트를 제공하고 있습니다.
하지만 현실적인 문제들이 있었습니다:
- 비용 부담: 데이터 웨어하우스의 AI 어시스턴트 사용 비용이 상당함
- 성능 한계: 실제 사용 시 기대만큼 의도에 맞는 쿼리를 생성하지 못하는 경우가 많음
- 도메인 특성: 각 회사의 고유한 도메인과 데이터 설계 방식으로 인해 일반적인 모델의 성능이 제한적
프로젝트 목표
이러한 배경에서 다음과 같은 목표를 설정했습니다:
- 성능 검증: Text2SQL 데이터셋으로 파인튜닝했을 때 태스크 성능 향상 여부 확인
- 한국어 지원: 한국어 사용자를 위한 자연어 질의와 SQL 쿼리 연결 데이터셋 구축
- 품질 확보: 실용적으로 활용 가능한 고품질 데이터셋 완성
데이터셋 구축 과정
Spider 데이터셋 선택 이유
여러 영어 Text2SQL 데이터셋 중 Spider 1.0을 번역 대상으로 선택한 이유는 다음과 같습니다:
Spider vs WikiSQL 비교
| 특징 | Spider | WikiSQL |
|---|---|---|
| 데이터 규모 | Train 7,000개, Validation 1,034개 | 더 방대한 데이터 양 |
| 쿼리 복잡도 | 서브쿼리, 조인, 집계 등 복합 구문 포함 | 단일 테이블 대상 간단한 쿼리 |
| 실용성 | 실제 활용도가 높은 다양한 쿼리 | 제한적인 쿼리 패턴 |
| 한국어 버전 | 존재하지 않음 | Kaggle에 한국어 데이터셋 존재 |
Spider는 데이터 양은 적지만 실제 업무에서 사용할만한 복잡하고 다양한 쿼리를 포함하고 있어 더 실용적이라고 판단했습니다.
초기 번역 결과와 문제 발견
Spider 데이터셋의 validation 데이터를 LLM으로 기계번역한 후 결과를 확인해보니, 예상보다 많은 문제점들이 발견되었습니다.
초기 번역 결과 예시
| 원문 (영어) | 번역 결과 (한국어) |
|---|---|
| What model has the most different versions? | 어떤 모델이 가장 많은 버전을 가지고 있나요? |
| What are the names of the singers and number of concerts for each person? | 각 사람별 가수 이름과 콘서트 횟수가 어떻게 되나요? |
| Among the cars with more than lowest horsepower, which ones do not have more than 3 cylinders? | 최저 마력보다 높은 마력을 가진 차들 중에서 실린더가 3개를 초과하지 않는 차량의 제조사 ID와 제조사명을 나열하세요. |
보시다시피 문법적으로는 문제없지만, 자연스럽지 않은 한국어 표현들이 상당히 많았습니다.
번역 과정에서 발견된 문제점들
단순한 기계번역으로는 해결되지 않는 다양한 문제점들을 발견하고, 이를 5가지 주요 유형으로 분류했습니다.
문제 유형 분석
| 오류 유형 | 주요 내용 | 개선 방향 |
|---|---|---|
| 1. 시간/수 비교 표현 오류 | more than을 ‘이상’으로, before/after를 ‘이전’/’이후’로 번역 |
‘초과’, ‘미만’, ‘~보다 전/후’ 등 경계값을 명확히 구분하는 표현으로 수정 |
| 2. 어색한 한국어 표현 | 불필요한 주어(우리는), 수식어(모든 다른), 어색한 단어(역알파벳순) 사용 |
한국어 문맥에 맞게 자연스럽게 생략하거나 ‘국가들은’, ‘알파벳 역순’ 등으로 수정 |
| 3. 서술어 호응 오류 | 개수나 나이를 묻는데 ‘무엇인가요?’로 답하거나, 여러 주어에 하나의 서술어만 사용 | 주어에 맞는 서술어(‘몇 명인가요?’, ‘얼마인가요?’) 사용 |
| 4. 도메인 어휘 오번역 | production time을 ‘생산 시간’으로, accelerate를 ‘가속도’로 번역 |
도메인에 맞게 ‘생산일자’, ‘가속 성능’ 등으로 수정 |
| 5. 의미 누락 및 변형 | average를 ‘평균’으로만 번역하여 ‘평균 수용 인원’의 의미가 누락됨 |
원문 의도를 정확히 반영하도록 누락된 정보 보충 |
고유명사 번역 딜레마
흥미로운 논의 포인트도 있었습니다. 바로 질의에 포함된 고유명사를 번역할지 여부였습니다.
예시:
| 원문 | 번역 결과 |
|---|---|
| What is the TV Channel of TV series with Episode “A Love of a Lifetime”? | 에피소드 “평생의 사랑”이 포함된 TV 시리즈를 방영한 TV 채널과 그 채널의 시리즈명을 알려주세요. |
실제 업무 환경에서는 테이블 데이터가 영어일 수도, 한글일 수도 있고, 사용자도 상황에 따라 영어나 한글로 질의할 수 있습니다. 따라서 다양한 상황을 반영하기 위해 번역 여부를 일관되게 정하지 않고 혼재시키기로 결정했습니다.
품질 개선 전략
발견된 문제점들을 해결하기 위해 3단계 개선 전략을 수립했습니다.
1단계: 개선된 프롬프트로 3단 번역
기본적인 문장 검수를 위해 피드백 과정을 포함한 3단계 번역을 진행했습니다.
prompt = f"""Human: 다음 영어 질문을 한국어로 번역해주세요. 다음 규칙을 엄격히 따라주세요:
1. 항상 질문이나 요청 형식으로 번역하세요.
2. "~를 표시합니다", "~를 출력합니다", "~를 보여줍니다" 같은 설명형/명령형 종결로 번역하지 마세요.
3. 대신 "~를 알려주세요", "~를 보여주세요", "~는 무엇인가요?" 같은 요청/질문 형식으로 번역하세요.
4. 번역문만 작성하고 쌍따옴표나 다른 설명 부호는 사용하지 마세요.
5. SQL 쿼리와 영어 질문이 일치하지 않을 수 있으니, SQL 쿼리의 내용을 우선적으로 참고하세요.
6. 데이터베이스 컨텍스트에 맞는 적절한 용어를 사용하세요.
데이터베이스 ID: {db_id}
SQL 쿼리: {query}
영어 질문: {question}
잘못된 예시:
- ❌ "수용량이 5,000명에서 10,000명 사이인 모든 경기장의 위치와 이름을 표시합니다."
- ⭕ "수용량이 5,000명에서 10,000명 사이인 모든 경기장의 위치와 이름을 보여주세요."
한국어 번역:
"""
2단계: 오류 유형별 수동 검수
프롬프트 개선으로도 해결되지 않는 문제들은 팀원들과 함께 오류 유형별로 체계적인 수동 검수를 진행했습니다.
3단계: 번역 기준 논의 및 결정
번역 여부를 판단해야 하는 부분들은 팀 내 논의를 통해 일관된 기준을 마련했습니다.
다른 프로젝트에 적용할 수 있는 인사이트
이번 프로젝트를 통해 얻은 경험을 다른 번역 프로젝트에도 적용할 수 있도록 3가지 핵심 원칙으로 정리했습니다.
1. 자연스러운 한국어 문장 만들기
한국어 화자가 실제로 사용할 법한 자연스러운 문장으로 번역하는 것이 가장 기본입니다.
한국어 사용자라면 읽으면서 바로 느낄 수 있는 부분인데요, LLM을 통해 번역 품질을 개선하고자 할 때에는 어떤 부분이 부자연스러운지 구체적인 예시를 포함해 프롬프트를 작성하는 것이 좋습니다.
2. 번역 범위 명확히 구분하기
태스크 특성에 따라 번역할 부분과 번역하지 않을 부분을 명확히 구분해야 합니다.
- 번역 불필요: SQL 쿼리 구문 내 테이블/컬럼명 (업계 관례상 영어 사용)
- 번역 고려: 질의 내 고유명사 (사용자 상황을 고려하여 결정)
3. 원문 의미 정확히 보존하기
번역 후에도 원문의 정확한 의미를 유지하는 것이 가장 중요합니다.
이 부분은 검수 과정을 여러 번 반복하여 가장 큰 개선 효과를 얻을 수 있습니다. 이번 작업에서는 시간 제약으로 충분히 개선하지 못했지만, 향후 프로젝트에서는 LLM을 활용한 반복 검수 과정을 구축하여 보완해보려고 합니다.
마무리
이렇게 구축된 한국어 Text2SQL 데이터셋은 Hugging Face Hub에 배포되었습니다🎉
프로젝트를 통해 배운 점
데이터셋 구축 작업을 처음 진행하면서 예상보다 사람이 직접 확인하고 고민해야 할 부분이 많다는 것을 깨달았습니다. 특히 개선 방향을 판단하는 과정에서 인간의 판단력이 필수적이었는데, 이런 부분을 AI로 더 효율적으로 처리할 수 있는 방법을 계속 고민하게 되었습니다.
다음 단계
현재 작업 과정에서 발견된 추가 개선 포인트들은 모델 학습과 평가 후 실제 성능에 미치는 영향을 분석하여 우선순위를 정해 보완하는 것으로 진행 방식을 정했습니다.
이렇게 구축한 Text2SQL 데이터셋으로 모델을 파인튜닝하고 평가하는 과정에서의 경험도 다음 포스트에서 소개하도록 하겠습니다! 이어지는 포스트에도 많은 관심 부탁 드립니다. 🤗
참고 자료
〰️〰️ 열린 프로젝트 〰️〰️
모집 중
