LFM2.5 Encoder — 로컬 개인정보 필터 설계 가이드
기업이 생성형 AI를 도입할 때 가장 먼저 마주치는 문제는 모델의 답변 품질만이 아닙니다. 직원이 고객 이름, 전화번호, 계좌번호, 계약서 식별자, API 키를 프롬프트에 붙여 넣은 뒤에야 보안 장치가 작동한다면 이미 민감한 데이터는 외부 경계로 이동했을 수 있습니다. 그래서 중요한 질문은 ‘모델이 개인정보를 잘 숨기는가’가 아니라 ‘외부 모델을 호출하기 전에 로컬 환경에서 민감한 구간을 찾아낼 수 있는가’입니다.
Liquid AI가 공개한 LFM2.5-Encoder 계열은 이 앞단 문제를 겨냥할 수 있는 소형 양방향 인코더입니다. 공식 모델 카드에 따르면 230M과 350M 두 크기로 제공되며, 8,192토큰 문맥, 다국어 처리, 분류·토큰 분류·검색·재순위화 같은 작업을 위한 파인튜닝을 지원합니다. 별도로 공개된 PII 탐지 데모 모델은 40종의 개인정보를 16개 언어에서 찾아 제거하는 용도를 제시합니다. 다만 기본 인코더가 설치 즉시 모든 개인정보를 완벽하게 판별한다는 뜻은 아닙니다. 실제 서비스에서는 작업별 헤드, 정책, 임계값, 후처리, 평가 데이터가 함께 필요합니다.
이 글은 공식 모델 자료와 Hugging Face 모델 카드를 바탕으로 LFM2.5-Encoder의 구조를 살펴보고, 이를 LLM 게이트웨이 앞단의 로컬 개인정보 필터로 배치하는 방법을 설명합니다. Threads의 choi.openai 계정은 화제성 탐색에만 참고했으며, 수치와 기능은 Liquid AI의 공식 자료로 다시 확인했습니다. 핵심은 특정 모델을 홍보하는 것이 아니라 작은 인코더를 보안 통제 지점으로 쓸 때 무엇을 검증해야 하는지 정리하는 데 있습니다.
생성 모델 앞에 별도 인코더를 두는 이유
대형 생성 모델은 문맥을 이해하고 자연스러운 답을 만드는 데 강하지만, 모든 입력 토큰에 대해 개인정보 경계를 안정적으로 표시하는 전용 시스템은 아닙니다. 프롬프트로 ‘개인정보를 지워 달라’고 지시할 수는 있으나, 그 요청 자체가 외부 API로 전송된다면 데이터 최소화라는 목적을 달성하지 못합니다. 또한 생성 결과는 확률적이고 출력 형식이 흔들릴 수 있어, 보안 정책처럼 결정적인 처리 단계에 그대로 의존하기 어렵습니다.
인코더 기반 토큰 분류는 입력 전체를 양방향으로 읽고 각 토큰 또는 문자 구간에 라벨을 붙이는 방식에 적합합니다. 예를 들어 ‘홍길동 고객의 계좌는 123-45-67890’이라는 문장에서 이름, 계좌번호의 시작과 끝을 표시하고 해당 범주를 반환할 수 있습니다. 이후 애플리케이션은 원문을 외부로 보내지 않은 채 민감 구간을 마스킹하거나, 사용자의 확인을 요구하거나, 요청 자체를 차단할 수 있습니다.
이 분리는 운영 측면에서도 유리합니다. 생성 모델은 품질과 비용에 따라 바뀔 수 있지만 개인정보 정책은 조직의 통제 아래 유지해야 합니다. 게이트웨이 앞단에 독립된 탐지기를 두면 OpenAI, Anthropic, Google, 사내 모델 등 뒤쪽 공급자를 교체해도 같은 입력 정책을 적용할 수 있습니다. 탐지 로그와 오탐 통계도 생성 모델의 응답 로그와 분리해 관리할 수 있습니다.
LFM2.5-Encoder의 핵심 구조
이미지: LiquidAI/LFM2.5-Encoder-350M 공식 모델 카드. 모델 제공자 Liquid AI가 공개한 자료를 로컬로 내려받아 첨부했습니다.
공식 카드에서 LFM2.5-Encoder는 LFM2 하이브리드 백본을 바탕으로 한 다국어 양방향 마스크 언어 모델로 설명됩니다. 230M 모델은 약 229.7M, 350M 모델은 약 354.5M 파라미터이며 숨김 크기는 모두 1,024, 어휘 크기는 65,536입니다. 문맥 길이는 8,192토큰입니다. 지원 언어 목록은 영어, 독일어, 스페인어, 프랑스어, 이탈리아어, 네덜란드어, 폴란드어, 포르투갈어, 아랍어, 힌디어, 일본어, 러시아어, 터키어, 베트남어, 중국어의 15개로 제시됩니다.
여기서 주의할 점은 기본 인코더의 공식 지원 언어 15개와 PII 데모가 설명하는 16개 언어를 섞어 말하면 안 된다는 것입니다. PII 탐지기는 별도 파인튜닝 산출물이며 데이터와 라벨 체계가 다를 수 있습니다. 한국어 서비스에 도입할 경우 모델 이름이나 데모 문구만 보고 지원을 가정하지 말고, 한국어 주소·주민등록번호·계좌·이름 표기 변형을 포함한 자체 평가가 먼저입니다. 공식 기본 모델 카드의 지원 언어 목록에는 한국어가 명시돼 있지 않습니다.
아키텍처는 짧은 합성곱 블록과 그룹 쿼리 어텐션을 섞은 LFM2 백본을 사용합니다. 생성 모델의 인과 마스크 대신 입력의 앞뒤를 모두 볼 수 있는 비인과 양방향 어텐션을 적용하고, 마스크 언어 모델링 헤드로 학습합니다. 개인정보 구간은 앞 단어만 보고 결정하기 어려운 경우가 많습니다. 같은 숫자열도 앞뒤에 ‘주문번호’, ‘계좌’, ‘연락처’가 붙는지에 따라 의미가 달라지므로 양방향 문맥이 토큰 분류에 도움이 됩니다.
230M과 350M을 선택하는 기준
작은 모델을 선택할 때 파라미터 수만 비교하면 운영 결정을 놓치기 쉽습니다. 230M은 메모리와 지연 예산이 빡빡한 클라이언트, 지점 단말, 브라우저와 가까운 환경에서 출발점이 될 수 있습니다. 350M은 더 높은 품질을 우선하는 서버 측 로컬 게이트웨이나 워크스테이션에 적합한 후보입니다. 그러나 실제 지연은 토큰 길이, 배치 크기, 정밀도, 런타임, CPU 명령어, 동시 요청 수에 따라 달라집니다.
PII 탐지는 평균 요청보다 긴 최악의 요청에서 안정적이어야 합니다. 500자 채팅에서는 빨라도 50쪽 문서를 붙여 넣었을 때 대기열이 쌓이면 사용자가 필터를 우회하려 할 수 있습니다. 따라서 평균 지연뿐 아니라 p95와 p99, 최대 메모리, 긴 문서 분할 비용, 동시성에 따른 처리량을 측정해야 합니다. 입력을 자를 때 개인정보가 청크 경계에 걸리는 문제도 확인해야 합니다.
품질 비교에는 같은 파인튜닝 데이터와 같은 라벨 헤드를 사용해야 합니다. 230M과 350M에 서로 다른 학습 데이터나 임계값을 적용하고 결과만 비교하면 크기 효과를 알 수 없습니다. 먼저 공통 데이터셋과 평가 코드를 고정하고, 오탐 비용과 미탐 비용을 업무별로 정의한 뒤 모델 크기를 선택해야 합니다. 고객 지원 채팅과 소스코드 보조 도구는 보호해야 할 정보 유형과 실패 비용이 다릅니다.
40종 개인정보 탐지를 어떻게 해석해야 하는가
‘40종’은 완전한 보안 보증이 아니라 라벨 체계의 범위를 뜻합니다. 개인정보 범주는 국가와 산업에 따라 다르고, 같은 값도 상황에 따라 민감도가 달라집니다. 공개된 이메일 주소는 마케팅 문서에서는 정상 데이터일 수 있지만 비공개 고객 문의에서는 제거 대상일 수 있습니다. 탐지 모델은 문자열과 문맥에서 후보를 찾고, 최종 처리 정책은 조직이 결정해야 합니다.
정규식으로 잘 잡히는 정보와 문맥 모델이 필요한 정보를 구분하는 편이 좋습니다. 이메일, IPv4 주소, 일부 카드 번호는 형식 규칙과 체크섬으로 높은 정밀도를 얻을 수 있습니다. 반면 사람 이름, 회사 내부 프로젝트명, 자연어 주소, 건강 상태는 문맥 의존성이 큽니다. 하나의 모델로 모두 해결하기보다 정규식·사전·체크섬·토큰 분류기를 조합하고 충돌 해결 규칙을 두는 것이 실용적입니다.
API 키와 비밀 토큰도 별도 취급해야 합니다. 알려진 접두사나 길이 패턴은 규칙 기반으로 빨리 찾을 수 있지만, 내부에서 만든 키 형식이나 문서 속 예시는 문맥 판단이 필요합니다. 탐지 후에는 단순히 별표로 바꾸는 것보다 자격 증명을 즉시 폐기해야 하는지 판단하는 대응 흐름이 중요합니다. 이미 로그나 클립보드에 노출됐다면 마스킹만으로 사고가 끝나지 않습니다.
권장 아키텍처: 로컬 프라이버시 게이트웨이
이미지: Liquid AI 공식 LFM2.5-Encoder 자료에 포함된 도식. 출처와 라이선스는 공식 모델 페이지의 LFM Open License v1.0 표기를 확인해야 합니다.
첫 단계는 입력 수집과 정규화입니다. 웹 채팅, 문서 업로드, 코드 에디터, 이메일 플러그인처럼 입력 경로가 다르면 문자 인코딩과 메타데이터도 달라집니다. 원문을 보존한 채 분석용 복사본에서 유니코드 정규화, 제어 문자 처리, 문서 형식의 텍스트 추출을 수행합니다. 공격자가 보이지 않는 문자나 전각 숫자로 패턴을 회피할 수 있으므로 정규화 전후 값을 모두 추적해야 합니다.
둘째 단계는 복수 탐지기 실행입니다. 형식이 명확한 값은 정규식과 체크섬으로 검사하고, 이름·주소·조직·문맥형 비밀은 인코더 토큰 분류기로 찾습니다. 조직 내부의 프로젝트명과 고객 코드에는 관리되는 사전을 추가할 수 있습니다. 각 탐지기는 시작 위치, 끝 위치, 범주, 신뢰도, 탐지 근거를 공통 스키마로 반환해야 합니다.
셋째 단계는 정책 결정입니다. 예를 들어 주민등록번호와 비밀 키는 신뢰도가 낮아도 차단하고, 일반 이름은 외부 전송 전에 사용자 확인을 요구할 수 있습니다. 사내 승인 모델에는 일부 범주를 허용하되 외부 API에는 더 엄격한 규칙을 적용할 수도 있습니다. 정책은 코드와 버전으로 관리하고 누가 언제 바꿨는지 감사할 수 있어야 합니다.
넷째 단계는 변환입니다. 마스킹은 원문 길이를 유지하는 방식, 범주 토큰으로 치환하는 방식, 가역 토큰화 방식 중 목적에 맞게 선택합니다. ‘김철수’를 ‘[PERSON_1]’로 바꾸면 생성 모델이 문맥을 유지하면서 답할 수 있고, 응답 뒤에 권한 있는 로컬 시스템이 토큰을 원래 값으로 복원할 수 있습니다. 복원 테이블은 외부 모델이나 일반 로그로 보내지 않아야 합니다.
마지막 단계는 외부 호출과 출력 검사입니다. 입력을 안전하게 만들었다고 응답이 안전한 것은 아닙니다. 모델이 연결된 검색 도구나 사내 데이터베이스에서 새 개인정보를 가져올 수 있으므로 출력에도 같은 탐지 체계를 적용해야 합니다. 입력 정책과 출력 정책은 목적이 다르므로 임계값과 허용 범주를 독립적으로 관리합니다.
청크 분할에서 생기는 경계 오류
8,192토큰 문맥은 채팅과 일반 문서에 충분할 수 있지만 대용량 첨부 파일은 분할해야 합니다. 단순히 고정 길이로 자르면 ‘서울특별시 종로구’와 상세 주소가 다른 청크로 나뉘거나, 키 접두사와 본문이 분리될 수 있습니다. 각 청크에 겹침 구간을 두고 결과를 원문 좌표로 다시 병합해야 합니다. 겹침 길이는 이메일·키·주소처럼 예상되는 최대 엔터티 길이를 고려해 정합니다.
문서 구조를 활용하면 품질을 높일 수 있습니다. 표의 열 제목, 양식의 필드명, 코드 블록의 변수명은 값의 의미를 설명합니다. 텍스트만 평탄화하면 ‘전화번호’라는 헤더와 실제 번호가 멀어져 문맥이 사라질 수 있습니다. 표 셀과 헤더의 관계, 페이지와 문단 위치를 메타데이터로 보존하고 모델 입력에 제한적으로 포함하는 방식이 필요합니다.
병합 과정에서는 중복 탐지를 하나로 합치되 범주 충돌을 숨기지 않아야 합니다. 같은 구간을 한 탐지기는 전화번호, 다른 탐지기는 계좌번호로 분류할 수 있습니다. 보안상 더 엄격한 범주를 선택하거나 사용자에게 확인을 요청하고, 충돌 사례를 평가 데이터로 축적합니다. 좌표 변환 오류는 엉뚱한 글자를 지우는 치명적인 버그가 될 수 있으므로 다국어와 이모지 문자열로 단위 테스트해야 합니다.
한국어 환경에서 별도 검증이 필요한 이유
공식 기본 인코더 카드의 지원 언어 목록에는 한국어가 없습니다. 따라서 한국어 이름과 주소가 포함된 서비스라면 영어 벤치마크나 다국어 평균만으로 도입하면 안 됩니다. 한글 이름은 짧고 일반 명사와 겹칠 수 있으며, 주소에는 도로명·지번·건물명·동호수가 혼합됩니다. 전화번호도 하이픈, 공백, 국가번호, 한글 표현이 섞입니다.
주민등록번호와 사업자등록번호는 형식 규칙으로 후보를 찾을 수 있지만 실제 값을 평가 데이터에 그대로 저장하면 또 다른 개인정보 저장소가 생깁니다. 합성 데이터를 만들고, 필요한 경우 안전한 환경에서 비식별 실데이터를 제한적으로 평가하며, 데이터 접근과 삭제 정책을 마련해야 합니다. 합성 데이터만 사용하면 실제 오타와 문서 잡음을 놓칠 수 있으므로 두 데이터의 역할을 구분합니다.
평가 세트에는 정상적인 비민감 숫자도 충분히 포함해야 합니다. 날짜, 가격, 주문 수량, 논문 식별자, 소프트웨어 버전이 모두 개인정보로 잡히면 업무 도구를 사용할 수 없게 됩니다. 한국어 조사와 띄어쓰기 변형, OCR 오류, 초성, 전각 문자, 이미지에서 추출된 깨진 텍스트도 넣어야 합니다. 개인정보를 숨긴 공격 예시와 정상 예시를 함께 관리해야 임계값을 현실적으로 정할 수 있습니다.
성능 평가는 정확도 하나로 끝나지 않는다
전체 토큰 정확도는 대부분이 비개인정보인 데이터에서 쉽게 높아집니다. 중요한 지표는 범주별 정밀도와 재현율, 엔터티 단위 완전 일치, 일부 구간 일치, 문서당 미탐률입니다. 계좌번호의 한 글자만 남겨도 유출 위험이 있으므로 토큰 평균보다 엔터티 전체가 제거됐는지를 봐야 합니다. 고위험 범주는 재현율을 우선하고, 일반 이름처럼 업무를 방해하기 쉬운 범주는 정밀도와 사용자 확인 절차를 함께 봅니다.
오탐과 미탐의 비용을 숫자로 연결하면 임계값을 선택하기 쉽습니다. 미탐 한 건이 사고 대응과 규제 위험을 만들 수 있는 범주에는 낮은 임계값을 적용합니다. 반대로 소스코드의 일반 변수명을 사람 이름으로 계속 차단하면 개발자가 기능을 끄게 됩니다. 업무 유형별 정책을 분리하고, 단일 글로벌 임계값을 피하는 이유입니다.
운영 평가는 시간에 따라 계속해야 합니다. 새로운 키 형식, 제품명, 언어, 문서 템플릿이 등장하면 데이터 분포가 바뀝니다. 탐지율 변화, 사용자의 마스킹 해제, 수동 차단, 충돌 사례를 익명화해 분석하고 재학습 후보를 만듭니다. 다만 운영 로그 자체에 원문 개인정보를 저장하지 말고 범주, 길이, 해시, 정책 결과처럼 필요한 최소 정보만 남깁니다.
파인튜닝과 배포에서 확인할 사항
기본 LFM2.5-Encoder는 마스크 언어 모델이므로 실제 PII 작업에는 토큰 분류 헤드와 라벨 데이터가 필요합니다. 공식 PII 탐지 모델을 사용하더라도 조직의 라벨 정의와 맞는지 확인해야 합니다. BIO 또는 유사한 시퀀스 라벨 방식에서는 엔터티 시작과 내부 토큰의 불일치를 후처리해야 하며, 서브워드 토큰 결과를 원문 문자 좌표로 정확히 복원해야 합니다.
학습 데이터 분할은 같은 문서 템플릿이 학습과 평가에 동시에 들어가지 않도록 해야 합니다. 고객 양식의 이름만 바꿔 두 세트에 넣으면 모델이 형식을 외워 실제 일반화 성능보다 높게 보일 수 있습니다. 시기, 고객군, 문서 유형을 기준으로 분리하고, 완전히 새로운 템플릿을 외부 평가로 남겨야 합니다.
모델 카드에는 로딩 시 trust_remote_code=True 예시가 포함돼 있습니다. 이는 저장소의 사용자 정의 코드를 실행할 수 있다는 뜻이므로 기업 환경에서는 커밋을 고정하고 코드를 검토하며, 네트워크와 파일 권한이 제한된 빌드 환경에서 패키징해야 합니다. 매번 최신 브랜치를 자동으로 받아 운영 서버에서 실행하는 방식은 공급망 위험을 키웁니다. 가중치 해시와 토크나이저 버전도 함께 고정합니다.
공식 라이선스는 LFM Open License v1.0으로 표시됩니다. 상용 배포, 수정, 재배포 조건은 실제 라이선스 전문과 조직의 법무 정책을 확인해야 합니다. 모델 페이지의 짧은 라벨만 보고 모든 사용이 허용된다고 단정해서는 안 됩니다. 파인튜닝 데이터의 권리와 개인정보 처리 근거도 모델 라이선스와 별개의 문제입니다.
간단한 처리 흐름 예시
raw_text = receive_input()
normalized, offset_map = normalize_without_overwrite(raw_text)
rule_hits = regex_and_checksum_scan(normalized)
model_hits = pii_encoder.predict(normalized)
hits = merge_to_original_offsets(rule_hits, model_hits, offset_map)
decision = policy_engine.evaluate(hits, destination, user_role)
if decision.block:
return request_user_action(decision)
safe_text, token_map = redact_or_tokenize(raw_text, hits)
response = call_approved_model(safe_text)
return output_filter(response, token_map, user_role)이 예시의 중요한 부분은 모델 호출이 마지막에 가깝다는 점입니다. 정규화 과정이 원문을 덮어쓰지 않고 좌표 맵을 만들며, 규칙 기반 결과와 모델 결과를 병합하고, 목적지와 사용자 역할에 따라 정책을 결정합니다. 탐지 결과가 있다고 무조건 삭제하지 않고 차단·확인·치환 중 적절한 행동을 선택합니다.
가역 토큰화를 사용할 때는 복원 권한을 세분화해야 합니다. 모델 응답을 같은 사용자에게 보여주는 경우에는 필요한 토큰만 복원할 수 있지만, 요약본을 다른 팀과 공유할 때는 복원하지 않아야 합니다. 토큰 맵의 수명은 요청 처리 시간으로 제한하고 메모리와 임시 파일에서 제거합니다. 오류 추적 시스템에도 원문이나 토큰 맵이 들어가지 않도록 필터를 둡니다.
실패 조건과 한계
첫째, 모델은 보지 못한 형식과 의도적으로 변형된 문자열을 놓칠 수 있습니다. 공백, 유사 문자, 이미지, 음성, 암호화된 첨부는 일반 텍스트 탐지기로 처리되지 않습니다. 입력 채널별 추출기와 파일 검사, OCR, 멀웨어 검사를 별도 계층으로 둬야 합니다. 개인정보 필터 하나가 데이터 유출 방지 전체를 대체하지 않습니다.
둘째, 문맥을 과도하게 사용하면 정상 표현을 민감 정보로 오인할 수 있습니다. 소설 속 인물, 공개 회사 대표번호, 샘플 코드의 가짜 키를 모두 차단하면 사용성이 나빠집니다. 반대로 공개 정보라고 해서 모든 재사용이 안전한 것도 아닙니다. 목적 제한과 데이터 결합 위험을 정책에서 고려해야 합니다.
셋째, 로컬 실행은 자동으로 안전하다는 뜻이 아닙니다. 모델 프로세스가 과도한 파일 권한을 갖거나 입력 로그를 남기거나 원격 텔레메트리를 전송하면 로컬 배치의 이점이 사라집니다. 네트워크 차단, 최소 권한, 메모리 덤프 정책, 로그 샘플링, 업데이트 검증까지 포함해야 합니다.
넷째, 공개 모델의 데모 성능은 조직의 실제 데이터 성능과 다릅니다. 언어, 산업 약어, OCR 품질, 문서 길이, 라벨 정의가 달라지면 결과가 변합니다. 배포 전에 그림자 모드로 탐지만 수행하고 기존 흐름과 비교한 뒤, 고위험 범주부터 단계적으로 차단을 켜는 방식이 안전합니다.
도입 체크리스트
- 외부 모델 호출 전에 탐지가 완료되고 원문이 외부 로그에 남지 않는가
- 기본 인코더와 PII 파인튜닝 모델의 기능을 구분했는가
- 한국어와 조직 고유 정보 유형을 자체 평가했는가
- 정규식·체크섬·사전·토큰 분류기의 역할이 나뉘어 있는가
- 청크 경계와 유니코드 좌표 변환 테스트가 있는가
- 고위험 범주의 미탐과 업무 방해 오탐을 별도로 측정하는가
- 목적지, 사용자 역할, 데이터 유형별 정책 버전이 관리되는가
- 가역 토큰의 복원표가 외부 모델과 로그로 전송되지 않는가
- trust_remote_code 사용 코드와 모델 커밋을 검토·고정했는가
- 라이선스와 파인튜닝 데이터의 처리 근거를 확인했는가
- 입력뿐 아니라 도구 결과와 최종 출력도 검사하는가
- 모델 실패 시 차단·수동 확인·안전한 폴백이 정의돼 있는가
결론
LFM2.5-Encoder가 주는 실무적 메시지는 모든 문제를 더 큰 생성 모델에 맡길 필요가 없다는 것입니다. 개인정보 탐지는 입력 전체를 양방향으로 읽고 구간을 표시하는 전용 인코더가 잘 맞는 과업입니다. 230M과 350M이라는 크기는 로컬 게이트웨이와 온디바이스 배치를 검토할 수 있게 하지만, 작다는 사실만으로 품질과 안전이 보장되지는 않습니다.
성공적인 도입은 모델 선택보다 경계 설계에서 결정됩니다. 외부 전송 전 탐지, 규칙 기반 검사와 모델의 결합, 목적지별 정책, 안전한 마스킹과 복원, 출력 재검사, 지속적인 한국어 평가가 하나의 흐름으로 연결돼야 합니다. 특히 공식 기본 모델의 언어 범위와 별도 PII 데모의 설명을 구분하고, 조직 데이터에서 재현 가능한 지표를 확보해야 합니다.
결국 로컬 개인정보 필터의 목적은 AI 사용을 막는 것이 아니라 민감한 원문이 불필요하게 이동하지 않도록 통제 지점을 만드는 데 있습니다. 생성 모델 공급자가 바뀌어도 앞단 정책과 평가 자산이 남는 구조를 만들면, 조직은 더 빠르게 AI를 실험하면서도 데이터 최소화와 감사 가능성을 유지할 수 있습니다.
참고 자료
'LLM' 카테고리의 다른 글
| LLM 텍스트 워터마크 — 같은 뜻에 다른 주사위를 심는 법 (0) | 2026.08.17 |
|---|---|
| GLM-5.3 공개 지연 — 코딩 성능과 사이버 위험 해설 (0) | 2026.08.17 |
| Gemma 4 12B 로컬 실행 — 16GB 노트북 활용 가이드 (0) | 2026.08.14 |
| Gemini 3.7 Flash 출시 — 코딩·에이전트 실무 분석 (1) | 2026.08.14 |
| Qwen3.8-Max 가중치 공개 — 2.4T 모델의 의미와 조건 (0) | 2026.08.13 |
