🤖
0 in / 0 out / 0 total tokens
핫 토픽
tencent/Hy3
Tencent의 Hy3가 Simon Willison 피드에 올라왔다. 이름만 보면 대형 모델 공개나 생성형 AI 도구 계열로 보이지만, 지금 주어진 정보만으로는 모델 카드나 벤치마크, 라이선스까지 판단할 수는 없다. 그래서 여기서 중요한 건 "또 하나의 모델이 나왔다"가 아니라, 중국 빅테크가 계속해서 공개 가능한 AI 자산을 쌓고 있다는 흐름이다.
게임 개발자 입장에서는 이런 공개 모델을 볼 때 항상 두 가지를 먼저 본다. 첫째는 로컬 또는 사내 인프라에서 돌릴 수 있는가, 둘째는 파이프라인에 붙였을 때 비용 대비 지연 시간이 맞는가다. UE5 프로젝트에서 NPC 대사 생성, QA 자동화, 툴체인 보조 같은 기능은 멋있어 보여도, 결국 빌드 서버나 에디터 워크플로에 붙였을 때 병목이 생기면 바로 버려진다.
왜 중요한가: 공개 모델 경쟁은 "성능 1등"보다 "내 서비스 스택에 싸게 붙일 수 있는 선택지"를 늘린다는 점에서 중요하다.
출처: Simon Willison
논문
Teaching LLMs to Recommend and Defer in Underrepresented Epilepsy Care
이 논문은 전문 간질 진료 인력이 부족한 환경에서 LLM 기반 의사결정 지원을 어떻게 다룰지에 초점을 둔다. 핵심은 LLM이 무조건 답을 내는 시스템이 아니라, 추천할 때와 보류할 때를 배워야 한다는 점이다. 의료처럼 실패 비용이 큰 도메인에서는 "그럴듯한 답"보다 "모르면 넘기는 능력"이 훨씬 중요하다.
개발자로 보면 이건 단순한 프롬프트 문제가 아니다. 추천과 보류를 분리하려면 모델 출력 뒤에 신뢰도, 정책, 휴먼 핸드오프, 감사 로그가 붙어야 한다. 서버 아키텍처로 치면 LLM을 단일 응답 엔진으로 두는 게 아니라, triage service, policy layer, escalation queue를 가진 의사결정 파이프라인으로 봐야 한다.
여기서 삽질 포인트도 분명하다. "모델이 전문가처럼 답하게 만들자"로 접근하면 위험하다. 실제 현장에서는 데이터가 부족하고, 환자 기록은 길고, 맥락은 불완전하다. 이런 상황에서 좋은 시스템은 자신 있게 틀리는 모델이 아니라, 제한된 근거 안에서 조심스럽게 행동하고 필요하면 사람에게 넘기는 모델이다.
왜 중요한가: LLM 제품의 다음 단계는 더 많이 말하는 모델이 아니라, 언제 멈춰야 하는지 아는 모델이다.
개발자 코멘트
오늘 두 소식은 방향이 꽤 다르다. 하나는 공개 모델 생태계의 확장이고, 다른 하나는 고위험 도메인에서 LLM을 어떻게 안전하게 써야 하는가다. 그런데 실제 제품을 만드는 입장에서는 둘이 같은 질문으로 만난다. "이 모델을 어디까지 믿고, 어디서 시스템이 개입해야 하는가"다.
나는 AI 사이드프로젝트를 만들 때도 모델 성능표보다 실패 경로를 먼저 보게 된다. 응답이 느릴 때, 엉뚱한 답을 할 때, 사용자가 애매한 입력을 넣을 때, 외부 API가 죽었을 때 무엇을 할지가 제품 품질을 결정한다. 게임 서버도 마찬가지다. 평균 FPS나 평균 지연 시간보다 중요한 순간은 피크 타임에 큐가 밀리고 상태 동기화가 꼬이는 때다.
Hy3 같은 모델 소식은 선택지를 늘려준다. 반대로 의료 LLM 논문은 그 선택지를 제품에 넣을 때 안전장치를 어떻게 설계해야 하는지 상기시킨다. 모델이 좋아질수록 오히려 주변 시스템 설계의 중요성이 커진다. 추론 결과를 그대로 사용자에게 던지는 구조는 빠르게 만들 수는 있지만, 오래 버티는 제품 구조는 아니다.
좋은 AI 제품은 모델이 대답하는 순간보다, 대답하지 않기로 결정하는 순간에 실력이 드러난다.