Aionda

2026-02-16

한국어 LLM 선택, 성능보다 데이터 조건

한국어 LLM 도입은 모델명보다 학습 사용, 보관 기간, 리전 저장·처리 조건을 먼저 점검해야 한다.

llmexplainersecurity
한국어 LLM 선택, 성능보다 데이터 조건

세 줄 요약

  • 무슨 변화/핵심이슈인가? 한국어 LLM 선택의 출발점이 “모델명”보다 학습 사용 여부, 보관(로그/상태/오브젝트), 리전(저장·처리) 같은 데이터 조건으로 옮겨가고 있다.
  • 독자는 뭘 하면 되나? 후보를 고르기 전에 (1) 학습 opt in/opt out (2) 보관 기간과 예외 (3) 저장 at-rest vs 처리 in-region을 분리한 체크리스트를 만들고, PoC에서 실제로 켜는 기능 기준으로 다시 확인하라.

회의에서 “이 대화 로그, 어디에 남죠?”라는 질문이 먼저 나오고, 이어서 “한국어 성능은요?”가 나온다. 이 순서는 우연이 아니다. 한국어 LLM 선택은 이제 모델 이름 비교만으로 끝나기 어렵다. 데이터가 어디로 가고, 얼마나 남고, 무엇에 쓰이는지를 먼저 정해야 한다. 그리고 문서에 적힌 ‘정책의 디테일’이 배포 가능 여부를 가른다.

예: 보안 담당자와 개발자가 같은 회의실에서 배포를 논의한다. 상담 내용이 시스템에 들어가고, 요약이 나오는 흐름을 시연한다. 기능을 늘리려는 순간, 저장되는 항목과 삭제 책임이 누가 갖는지가 쟁점이 된다.

현황

두 번째 축은 “보관”이 한 가지 의미로 끝나지 않는다는 점이다. OpenAI 문서에는 남는 데이터를 **abuse monitoring(최대 30일)**처럼 설명하는 부분이 있고, 별도로 Responses API의 Application State가 기본 30일이라는 표현도 있다. 또 “삭제되지 않은 오브젝트는 무기한 보관될 수 있다(Objects that are not deleted… are retained indefinitely)”는 문장도 등장한다. 따라서 “API는 30일”처럼 한 문장으로 요약하면 운영에서 맞지 않을 수 있다. 어떤 오브젝트가 생성되는지(예: 저장형 기능), 삭제 책임이 누구에게 있는지까지 같이 확인해야 한다.

분석

이 흐름이 중요한 이유는 한국어 품질 논쟁을 끝내기 때문이 아니다. 오히려 품질을 민감하게 보는 팀일수록, 도입 단계에서 더 자주 막히는 지점은 “성능”이 아니라 “데이터 경로”다. “학습에 쓰지 않는다”는 문구가 있더라도, 로그 보관(최대 30일), 애플리케이션 상태(기본 30일), 삭제되지 않은 오브젝트의 무기한 보관 가능성 같은 조항이 함께 있으면 보안·법무는 단순 승인/반려 대신 “무엇을 끄고, 무엇을 삭제하고, 무엇을 분리할지”를 요구한다. 결과적으로 LLM 선택은 엔지니어링 결정이면서 정책 설계가 된다.

리스크도 있다. 첫째, 벤더 문서가 “데이터를 안 쓴다/안 남긴다”처럼 요약되는 순간, 기능 사용에서 예외가 생길 수 있다. 문서가 말하는 “표준 API 호출”과 “파일 업로드/스레드/벡터스토어/로깅” 같은 저장형 기능은 동일하게 취급되지 않을 수 있다. OpenAI도 서비스 기능 사용 시 기본 API 호출과 달리 데이터가 저장될 수 있으니, 기능별로 어떤 데이터가 어디에 얼마나 보관되는지 검토하라는 취지로 안내한다.

둘째, 한국어 최적화/평가에서는 “좋아 보이는 점수”가 운영 성능을 보장하지 않는다. 연구들은 벤치마크 데이터 오염이 성능을 과대평가할 수 있다고 지적한다. 번역본을 통한 교차언어 오염 가능성도 논의된다. 또 다른 연구는 조건에 따라 오염이 MT 지표를 크게 부풀릴 수 있고 “최대 30 BLEU 포인트” 수준의 차이가 보고될 수 있다고 말한다. 그래서 “한국어 성능 1등” 같은 문구보다, 평가가 어떤 데이터로 어떻게 만들어졌는지를 먼저 확인해야 한다.

실전 적용

“한국어 LLM 생태계 지도”를 그릴 때 모델 이름을 맨 위에 두면, 도입 단계에서 다시 뒤집는 일이 생길 수 있다. 대신 배포 조건을 맨 위에 두고, 그 아래에 후보를 끼워 맞추는 편이 작업이 단순해진다. 순서는 보통 이렇다.

  1. 데이터 학습 사용(옵트인/옵트아웃)
  2. 보관 기간과 예외(로그, 상태, 삭제되지 않은 오브젝트)
  3. 리전(저장 at-rest, 처리 in-region을 분리)
  4. 저장형 기능 사용 여부(파일/스레드/벡터스토어 등)
  5. 그 다음에야 한국어 품질 PoC

PoC도 “한국어 평균 점수”만 보지 말고, 업무 도메인 문서/대화 샘플로 정답을 검증 가능한 방식으로 만든다. 데이터 오염 이슈를 줄이려면 사내 자료를 그대로 평가셋으로 쓰기보다, 출처와 중복 가능성을 점검한 별도 평가셋을 준비하는 편이 낫다(학습 데이터 혼입 가능성은 추가 확인이 필요할 수 있음).

오늘 바로 할 일:

  • 벤더 문서에서 학습 사용 여부(기본값, opt in/opt out) 문장을 원문 그대로 내부 문서에 인용하라.
  • 최대 30일, 기본 30일, 무기한 보관 가능을 한 줄로 뭉치지 말고(예: abuse monitoring, Application State, 오브젝트 보관), 항목별로 분리해 적어라.
  • 데이터 레지던시 요구사항을 **저장(at rest)**과 **처리(in-region)**로 나눠, 각각이 필요한지 여부를 먼저 확정하라.

FAQ

Q1. “우리 데이터는 학습에 안 쓴다”면 끝 아닌가요?
A. 끝이라고 보기 어렵다. 학습 사용과 별개로 로그/상태/오브젝트 보관이 남을 수 있다. 예를 들어 OpenAI 문서에는 최대 30일 보관, Responses API Application State 기본 30일, 삭제되지 않은 오브젝트는 무기한 보관될 수 있음 같은 조항이 함께 등장한다. 운영에서 어떤 기능을 켜는지까지 포함해 확인해야 한다.

Q2. 데이터 레지던시만 맞추면 규제 이슈가 사라지나요?
A. “저장 at-rest”와 “처리 in-region”이 항상 함께 보장된다고 단정하기 어렵다. OpenAI는 eligible 고객에 대해 in-region 저장을, 그리고 해당 프로젝트 요청을 in-region 처리한다고 설명한다. 요구사항이 “저장만”인지 “처리까지”인지 먼저 정하고, 문서가 그 범위를 어디까지 다루는지 확인해야 한다.

Q3. 한국어 성능 비교는 뭘 믿어야 하나요?
A. 외부 벤치마크만으로 결론을 내리면 위험할 수 있다. 연구들은 벤치마크 데이터 오염이 성능을 과대평가할 수 있고, 번역본을 통한 교차언어 오염도 가능하다고 지적한다. 또 오염이 MT 점수를 크게 부풀릴 수 있고 최대 30 BLEU 포인트 수준의 인플레이션이 관측됐다는 보고도 있다. 그래서 “우리 도메인 + 오염 점검”을 포함한 자체 평가가 필요하다.

결론

한국어 LLM 선택은 ‘성능 경쟁’만의 문제가 아니다. 데이터 통제(학습/보관/리전) 설계에서 시작해야 한다. 먼저 배포 조건을 고정하고, 그 범위 안에서만 후보를 비교하라. 다음 단계는 저장형 기능을 어디까지 쓸지 결정하는 일이다. 그 결정이 보관·리전·삭제 책임을 어떻게 바꾸는지 문서로 확인하고, PoC 설정과 함께 재검증해야 한다.

다음으로 읽기

참고 자료

공유하기:

업데이트 받기

주간 요약과 중요한 업데이트만 모아서 보내드려요.

RSS로 구독메일로 문의

오류를 발견했나요? 정정/오류 제보로 알려주시면 검토 후 업데이트에 반영할게요.