로컬 LLM, 같은 가중치인데 토큰 절반이 뒤집혔다

effidev·2026년 8월 23일

로컬에서 AI 모델을 직접 돌려 본 사람이라면 한 번쯤 겪었을 일이 있습니다. 커뮤니티에서 “이 모델 정말 좋다”는 말을 듣고 받아서 돌렸는데, 막상 내 컴퓨터에서는 그 말이 무색할 만큼 답이 엉성한 겁니다. 모델 카드에 적힌 벤치마크 점수는 분명 높은데 말이죠.

이 글은 그 이유를 끝까지 파고든 실측 기록을 정리한 것입니다. 결론부터 말하면 모델이 나빠서가 아니라, 같은 가중치를 돌리는 내 환경이 남의 환경과 다르기 때문입니다. 그리고 그 차이는 “느낌”이 아니라 숫자로 측정됩니다.

읽고 나면 로컬 추론 설정에서 무엇을 만지면 안 되는지, 양자화 파일을 고를 때 무엇을 기준으로 봐야 하는지가 정리됩니다. 로컬 LLM을 처음 돌려 보는 분도 따라올 수 있게 용어는 나올 때마다 풀어 쓰겠습니다.

벤치 점수는 그대로인데 내 컴퓨터에서만 이상하다

레벨1테크스 포럼에 thr3e라는 사용자가 8월 16일부터 연재를 시작했습니다. 제목이 「Why your local LLM feels dumber than it is」, 우리말로 옮기면 “당신의 로컬 LLM이 실제보다 멍청하게 느껴지는 이유”입니다. 8월 22일 기준으로 해커뉴스 프론트페이지에 올라 151점을 받았고, 지금도 파트 3까지 이어지고 있습니다.

글의 출발점은 이렇습니다.

오늘 LLM을 돌리는 모든 하드웨어와 소프트웨어 조합은 조금씩 다르다. 어떤 경우에는 아주 많이 다르다. 가정용 랩 사용자는 세대가 다른 GPU를 섞어 쓰기도 한다. 그 칩들은 명령어 집합이 다르고, 그 명령어 집합은 똑같은 가중치를 돌려도 다음 토큰을 계산하는 수학을 다르게 실행한다.

여기서 “가중치”는 모델 파일 그 자체를 말합니다. 학습이 끝난 모델이 담고 있는 숫자 덩어리죠. 우리는 보통 같은 가중치 파일을 받으면 같은 결과가 나올 거라고 생각합니다. 이 실측은 그 전제가 틀렸다는 것을 보여 줍니다.

그런데 “다르다”는 걸 어떻게 재느냐가 문제입니다. 저자는 벤치마크 점수 대신 로짓을 직접 들여다보는 길을 택했습니다.

다음 단어를 고르는 점수판, 로짓

로짓(logits)은 모델이 다음에 올 수 있는 모든 단어 후보마다 매기는 점수판입니다. 모델은 이 점수판을 확률로 바꾸고, 설정된 샘플러를 거쳐, 최종적으로 글자 하나를 뱉습니다.

점수판이 조금만 흔들려도 결과는 갈립니다. 저자의 표현을 빌리면 이렇습니다.

다음 토큰 확률이 충분히 바뀌면 THE→NE→XT가 THE→NE→W→DAY가 된다.

그 작은 변화 하나가 문장 전체의 방향을 틀어 버립니다. 그리고 우리가 “뭔가 이상한데”라고 느끼는 지점이 대개 여기서 시작됩니다.

이 글에서 반복해 등장하는 지표가 탑-1 일치율입니다. 점수판에서 1등을 차지한 토큰이 기준이 되는 실행과 같은지를 보는 겁니다. 다르면 “토큰 뒤집힘”이 한 번 발생한 것으로 셉니다. 이 글의 거의 모든 수치가 이 뒤집힘 비율입니다.

한 가지 짚고 갈 게 있습니다. 저자가 직접 못 박았듯 기준본(BF16)이 정답이라는 뜻은 아닙니다.

BF16은 수치적 충실도의 기준이지 신탁이나 정답 라벨이 아니다. 양자화된 모델이 BF16에서 벗어나면서 의미적으로 더 나은 답을 낼 수도 있다.

즉 이 실측이 재는 건 “얼마나 똑똑한가”가 아니라 “내 실행이 기준 실행에서 얼마나 벗어났는가” 입니다. 벗어남이 클수록, 남들이 말하는 그 모델의 동작과 내 것이 달라진다는 뜻입니다.

실험 조건부터 못 박고 간다

숫자를 보기 전에 조건부터 봐야 합니다. 이 실측이 신뢰할 만한 이유가 조건을 다 공개했기 때문이거든요.

Qwen3.6-27B는 MoE가 아닌 조밀 모델이지만 하이브리드 구조입니다. 64개 레이어가 “게이티드 델타넷 3개 + 풀 어텐션 1개” 패턴으로 반복되고, 이 중 풀 어텐션 16개 레이어만 어텐션 백엔드 선택의 영향을 받습니다.

테스트에 쓴 프롬프트도 중요합니다.

여기서 재생한 워크로드는 “프롬프트 2”로, 실제 턴스톤 랩 작업 흐름에서 캡처한 약 10만 토큰짜리 컨텍스트다. 여러 번의 툴 호출과 실제 작업 산출물이 들어 있다. 합성된 바늘찾기 테스트가 아니라 로컬 에이전트가 실제로 하는 일과 닮게 고른 것이다.

그리고 한 문장이 더 붙습니다. 이게 핵심입니다.

그리고 더 중요한 건, 이 프롬프트가 오늘날 세상의 어떤 벤치마크나 학습 데이터셋에도 없다는 점이다. 누구도 여기에 맞춰 벤치를 최적화하거나 양자화를 보정할 수 없었다.

벤치마크 점수가 실제 체감과 어긋나는 이유 중 하나가 바로 이겁니다. 공개된 벤치는 모두가 볼 수 있으니 모두가 그것에 맞춥니다. 아무도 못 본 실제 작업 로그로 재면 그림이 달라집니다.

첫 번째 실험 — 쿠다 커널만 바꿨더니

vLLM은 프롬프트를 처리하는 단계(프리필)에서 쓸 어텐션 백엔드를 고를 수 있습니다. 이 워크로드에서 고를 수 있는 건 셋입니다.

• 플래시어텐션 2 (FlashAttention 2)
• 플래시 인퍼런스 (Flash Inference)
• 트라이톤 어텐션 (Triton Attention)

바꾼 건 이 설정 하나뿐입니다. GPU도, OS도, 드라이버도, vLLM 버전도, 프롬프트도, 캐시도, 가중치도 전부 그대로 뒀습니다.

측정은 8k 토큰 구간마다 250개 위치(32토큰마다 1개)에서 전체 어휘 로짓을 BF16으로 캡처하고, 비교는 나중에 FP64로 계산하는 방식입니다. 트라이톤을 기준으로 놓고 나머지 둘이 몇 퍼센트나 다른 토큰을 1등으로 골랐는지를 셌습니다.

결과는 두 가지로 요약됩니다.

하나, 처음 수천 토큰에서는 셋 다 완벽하게 일치했습니다. 짧은 프롬프트로 테스트하면 아무 문제가 없어 보인다는 뜻입니다. 대부분의 사람이 여기서 테스트를 멈춥니다.

둘, 뒷부분으로 갈수록 갈리기 시작하는데 그 양상이 뭉텅이입니다. 컨텍스트가 길어질수록 매끄럽게 나빠지는 게 아니라, 프롬프트 내용에 따라 특정 구간에서 확 몰립니다. 저자는 이 점을 분명히 합니다.

불일치는 뭉텅이로 나타났고 컨텍스트 길이에 따라 부드럽게 증가하기보다 프롬프트 내용에 따라 달라졌다. 이건 모델이 무너지는 보편적인 길이가 하나 있다는 증거가 아니다.

“4만 토큰 넘으면 모델이 바보가 된다” 같은 통설이 커뮤니티에 돌아다니는데, 적어도 이 실측은 그런 단일 임계값을 지지하지 않습니다.

그리고 노이즈 가능성은 이렇게 제거했습니다.

같은 백엔드로 같은 테스트를 여러 번 돌려 무작위 노이즈를 배제했다. 모든 은닉 상태에서 실행 간 로짓이 비트 단위로 동일했다. 즉 이 차이는 오로지 프리필 동안 일어나는 행렬 곱셈과 덧셈 연산에서만 온다.

같은 설정이면 항상 똑같고, 설정 하나를 바꾸면 재현 가능하게 달라진다는 겁니다. 우연이 아닙니다.

두 번째 실험 — 캐시만 줄였더니

두 번째는 가중치와 활성값은 그대로 두고 KV 캐시만 양자화한 실험입니다.

KV 캐시는 모델이 이미 읽은 토큰들의 계산 결과를 메모리에 쌓아 두는 공간입니다. 대화가 길어질수록 여기가 VRAM을 크게 잡아먹기 때문에, 로컬에서 긴 컨텍스트를 쓰려는 사람들이 가장 먼저 손대는 설정이기도 합니다. “KV 캐시를 8비트나 4비트로 낮추면 컨텍스트를 두 배로 늘릴 수 있다”는 조언은 어디서나 볼 수 있죠.

실측 결과는 이렇습니다.

저자의 표현이 직설적입니다.

툴 호출 중에 뒤집힌 상위 토큰이 충분히 많아서, 그대로 흘러가게 놔뒀더니 BF16은 괜찮았고 INT8 KV 캐시는 결국 회복해 냈지만, INT4는 그러지 못했다.

여기서 중요한 건 “품질이 조금 떨어진다”가 아니라 완전히 재현 가능한 툴 호출 오류라는 점입니다. 매번 같은 자리에서 같은 방식으로 깨집니다.

컨텍스트를 늘리려고 캐시를 4비트로 낮추는 건 흔한 선택인데, 에이전트처럼 툴을 호출하는 작업에서는 그 대가가 생각보다 큽니다.

세 번째 실험 — 양자화 5종 맞대결

이번엔 반대로 KV 캐시를 전부 BF16으로 고정하고 가중치 양자화 방식만 바꿔 비교했습니다. 다섯 종입니다.

여기서 놓치면 안 되는 사실이 하나 있습니다. 양자화 방식마다 로짓을 계산하는 실제 CUDA 커널 자체가 다릅니다. 파일 크기만 다른 게 아니라 연산 경로가 통째로 다른 겁니다.

결과는 예상을 뒤집습니다.

다음 토큰 뒤집힘 결과는 꽤 예측 가능하게 나왔다. 더드(W8A16)가 모두를 압도했고, 퍼스트파티 FP8(W8A8)과 엔비디아 릴리스를 이겼다. 실제로 다섯 선택지 중 엔비디아 릴리스가 꼴찌로, 88k 컨텍스트에 이르면 약 50%의 토큰 뒤집힘을 기록했다.

정리하면 이렇습니다.

• 1위: TheHouseOfTheDude라는 개인이 올린 INT8 W8A16. 공식 배포판을 전부 이겼습니다.
• 꼴찌: 엔비디아가 직접 배포한 NVFP4. 88k 컨텍스트에서 고를 단어의 절반이 기준본과 달랐습니다.

개인이 올린 양자화가 왜 1등을 했을까요. 저자가 이유를 밝혀 둡니다.

보정 데이터셋 없이 명시적으로 원샷 양자화. W8A16에 GDN 프로젝션을 양자화하지 않은 것을 감안하면 유난히 좋은 충실도가 덜 신비롭다.

즉 마법이 아니라 구조 선택의 결과입니다. 활성값을 BF16으로 두고, 하이브리드 구조의 핵심인 델타넷 프로젝션을 건드리지 않았기 때문입니다.

엔비디아 NVFP4가 밀린 데도 이유가 있습니다. 저자가 조건에 적어 뒀습니다.

이번 업스트림 나이틀리 실행에서는 네이티브 FP4 연산이 아니었다. vLLM이 해당 GPU 경로를 네이티브 FP4 미지원으로 분류하고 마를린을 통한 가중치 전용 FP4 압축을 명시적으로 선택했다.

이건 중요한 단서입니다. 같은 파일이라도 다른 GPU에서는 다른 결과가 나올 수 있다는 뜻이니까요. 그리고 이게 이 글 전체의 주제이기도 합니다. 파일이 결과를 정하는 게 아니라, 파일과 하드웨어와 소프트웨어의 조합이 결과를 정합니다.

시스코 명령어 하나가 어떻게 망가지는가

여기까지는 통계입니다. 파트 2에서 저자는 방법을 바꿉니다. 전체 로짓의 3%를 넓게 샘플링하는 대신, 툴 호출 구간에서 로짓을 100% 캡처하기로 한 겁니다. 그리고 토큰이 뒤집혔을 때 강제로 되돌리지 않고 그대로 흘러가게 놔둡니다.

토큰 뒤집힘이 일어나면 우리는 멈추고 틀린 모델을 교사 쪽으로 되돌리지 않는다. 계속 가게 놔둔다. 이 갈라진 토큰 출력의 다중우주가 오류 이후 모델이 어디로 갔고 어떻게 발산했는지를 보여 준다.

그 결과 나온 사례가 구체적입니다. 네트워크 자동화 작업 중, 모델이 시스코 라우터의 특정 인터페이스를 대상으로 툴 호출을 실행하는 장면입니다.

• 올바른 대상: GigabitEthernet0/0/1.201
• 플래시어텐션 2가 고른 대상: GigabitEthernet0/1/4

포트를 잘못 지목한 겁니다. 그런데 여기서 끝나지 않습니다.

그러고 나서 갈라진 두 개의 툴 호출에서 잘못된 명령을 또 실행한다. 올바른 명령은 (맥 주소의 소유자를 찾으려는 것이므로) show mac address table이다. FA2는 토큰 뒤집힘이 만든 이 난장판에서 show run으로 빠져나오려 한다.

또 다른 예에서는 인터페이스에 설명을 설정하려던 작업 자체가 아예 실행되지 않았습니다.

저자가 붙인 경고가 이 글에서 가장 무거운 문장입니다.

기억하라. 이건 단지 vLLM에서 설정 옵션 하나를 바꿔 백엔드를 고른 것뿐이다. 같은 GPU, 같은 OS·드라이버·소프트웨어·vLLM·프롬프트·캐시·가중치·활성값이다. 그리고 이건 실행 간에 재현된다. 로짓 캡처가 비트 단위로 동일하다. 단순한 쿠다 커널 런타임 차이가 프로덕션에서 이런 일을 일으킨다면, 치명적인 네트워크 장애로 이어질 수 있다.

앞서 본 5종 양자화 대결에서도 같은 툴 호출을 시켜 봤는데, 이때는 BF16·FP8·INT8·W4A16이 전부 맞혔고 NVFP4만 실패했습니다.

GPU를 두 장 쓰면 실패하고 네 장 쓰면 성공한다

파트 2에는 더 당혹스러운 결과도 있습니다. 텐서 병렬(GPU 여러 장에 모델을 쪼개 얹는 방식) 설정을 바꿔 가며 같은 툴 호출을 시킨 실험입니다.

저자도 당황합니다. 원인은 대체로 GPU 간 통신 라이브러리(NCCL) 쪽으로 추적된다고 덧붙입니다. “장수를 늘리면 나아진다”는 직관이 통하지 않는 구간이 있다는 뜻입니다.

“검열 해제” 파인튜닝 네 가지는 어땠나

파트 3에서는 각도를 바꿉니다. Qwen3.8이 나온 뒤 사람들이 몰려가는 HERETIC, UNCENSORED, ABLITERATED 딱지가 붙은 파인튜닝 모델들을 같은 방식으로 측정한 겁니다. 이런 모델은 학습 후 붙은 거절 응답을 제거한 변형본을 말합니다.

인기 순으로 네 개를 골라 스톡 Qwen3.8-27B와 비교했습니다. 전부 양자화가 아닌 풀 BF16 크기입니다.

앞의 둘은 놀랄 만큼 멀쩡했고, 뒤의 둘은 저자 표현대로 “쓰지 말 것 목록에 올려야 할” 수준이었습니다.

특히 눈에 띄는 건 앞의 둘이 왜 안전했는가입니다.

SP06에서 58개의 뒤집힘 중 57개가 스톡 Qwen이 이미 불확실했던 자리에서 일어났다. 강하게 선호되던 스톡 토큰은 단 하나도 뒤집지 않았다.

반대로 가장 파괴적이었던 AEON의 실패 사례는 소름이 돋습니다.

• 컨텍스트에 PostgreSQL 포트 5432가 있었습니다. 스톡은 마지막 2를 확률 0.9991로 골랐는데, AEON은 ql을 확률 0.9158로 골랐습니다. 결과는 543ql. 그리고 툴 호출을 닫는 데 실패했습니다.
• 알려진 호스트명 .tenant에서 스톡은 enant를 확률 0.99996으로 골랐는데, AEON은 -를 확률 0.99747로 골랐습니다. 호스트명이 바뀌고 이후 파라미터까지 망가졌습니다.
• psycopg의 page_size=100이 size=100으로 바뀌어, 유효한 API 인자가 무효한 인자가 됐을 가능성이 큽니다.

저자의 정리가 정확합니다.

이건 모호한 문체 차이가 아니다. 운영 명령어에서 일어난 고신뢰도 리터럴 복사 실패다.

다만 저자는 결론을 넓히지 않습니다. AEON은 절제만 한 게 아니라 SSM 보정과 MTP 이식까지 묶인 레시피라서, 이 실험이 재는 건 그 레시피 전체이지 절제 기법 하나가 아니라는 겁니다. 또 이 측정이 “어느 쪽이 검열 해제에 더 성공했는지”를 말해 주지도 않습니다.

덧붙여 파생본 네 개 모두 비전·MTP 텐서는 스톡과 바이트 단위로 동일했습니다. 비전 텐서 333개 전부, MTP 텐서 15개 전부가 일치했고, 체크포인트당 약 1.77GB를 해시로 대조했습니다. 텍스트 결과의 차이가 언어 가중치 변경에서만 왔다는 뜻입니다.

모델 카드의 KLD 숫자를 믿으면 안 되는 이유

양자화 모델 카드를 보면 “KL 발산이 0.0001로 매우 낮음” 같은 자랑이 자주 보입니다. KL 발산(KLD)은 두 확률 분포가 얼마나 멀어졌는지를 재는 값이고, 낮을수록 기준에 가깝다는 뜻입니다.

저자는 여기에 못을 박습니다.

양자화 모델 카드의 말도 안 되게 낮은 KLD 주장에 낚이지 마라. 저자가 기준 체크포인트와 전체 런타임 환경, 평가 텍스트, 보정 데이터, 컨텍스트 길이, 샘플링한 위치, KL 방향, 어휘 절단 여부, 측정을 어떻게 집계했는지를 공개하지 않으면 그 숫자는 해석 자체가 불가능하다. 방법론이 숫자만큼 중요하고, 많은 사람이 이걸 틀린다.

이 실측의 하네스가 어떻게 계산하는지도 공개돼 있습니다. 캡처한 로짓을 float64로 변환해 log_softmax를 적용한 뒤, 방향성 KL과 역방향 KL, 젠슨-섀넌 발산을 모두 계산하고, 전역 평균 하나로 뭉개지 않고 출력 구간별로 요약합니다.

여기에 포럼 댓글로 붙은 지적도 함께 읽을 만합니다. KLD는 기준에서 얼마나 변했는지만 재고 “정확함”은 전혀 재지 않는다는 것, 그리고 기준 모델이 가장 그럴듯한 다음 토큰을 낸다는 건 어디까지나 가정이라는 것입니다.

이 실측이 뒤집는 통념 세 가지

정리하면 이 연재가 흔들어 놓은 통념이 셋입니다.

첫째, “같은 GGUF면 같은 결과” — 아닙니다. 어텐션 백엔드, 텐서 병렬 수, GPU 조합, 캐시 정밀도가 전부 결과를 바꿉니다. 그것도 재현 가능하게 바꿉니다.

둘째, “공식 배포판이 제일 안전하다” — 이 테스트에서는 엔비디아 공식 NVFP4가 꼴찌였고 개인이 올린 INT8이 1위였습니다. 물론 이건 특정 GPU·특정 vLLM 빌드에서의 결과지, 모든 환경의 순위표가 아닙니다. 오히려 그게 요점입니다. 순위표는 환경마다 다시 그려집니다.

셋째, “긴 컨텍스트에서 서서히 나빠진다” — 뭉텅이로 몰립니다. 짧은 프롬프트 몇 개로 테스트하면 아무 문제도 발견하지 못합니다.

여기에 하나 더 얹자면, 오르니스 1.5가 11배 큰 모델을 코딩에서 이겼다는 식의 벤치표 소식을 볼 때도 같은 질문이 필요합니다. 그 점수는 누가 어떤 런타임에서 낸 값인가. Qwen3.8-27B 공개 당시 벤치표를 어디까지 믿을지 따져 봤던 것과 같은 맥락입니다.

내 환경에서 오늘 바꿀 것

전문적인 내용이 길었으니, 로컬에서 모델을 돌리는 분이 지금 당장 할 수 있는 것만 추리겠습니다.

1. 샘플러 설정을 모델 카드에 적힌 값으로 맞추세요. 허깅페이스 모델 카드에는 보통 온도(temperature) 1.0, top-p 0.95처럼 권장값이 적혀 있고 모델마다 다릅니다. 저자가 덤으로 알려 준 팁이 있습니다.

참고로 온도를 너무 낮게 설정하는 것이 당신의 Qwen이 THINK 출력에서 빠져나오지 못하고 루프에 갇히는 이유다.

결정론적인 답을 얻겠다고 온도를 0에 가깝게 내리는 습관이 오히려 모델을 망가뜨리고 있을 수 있습니다.

2. 툴을 호출하는 작업이라면 KV 캐시를 4비트로 내리지 마세요. 컨텍스트를 늘리려고 가장 먼저 손대는 설정이지만, 이 실측에서 4비트 캐시는 툴 호출이 깨진 뒤 회복하지 못했습니다. 8비트는 결국 돌아왔습니다. 굳이 낮춰야 한다면 8비트에서 멈추세요.

3. 4비트 가중치 양자화도 같은 기준으로 보세요. 채팅용으로는 충분해도 정확한 명령어·코드·긴 에이전트 작업에서는 다릅니다. 여유가 있다면 8비트 계열이, 특히 활성값을 BF16으로 두는 W8A16 방식이 이 테스트에서 가장 안정적이었습니다.

4. 테스트는 짧은 프롬프트 세 개로 하지 마세요. 저자가 첫머리에서 강조한 부분입니다.

온도를 0으로 올리고 테스트 프롬프트 세 개를 붙여 넣은 뒤 좋다/나쁘다고 판정하지 마라. 제로샷 테스트는 대부분의 에이전트 작업을 대변하지 못한다. 긴 컨텍스트 툴 호출과 도메인 특화 지식 평가가 필요하다.

내가 실제로 시키는 일과 닮은 긴 작업 로그로 재야 내 설정의 약점이 보입니다.

5. 모델 카드의 KLD 자랑은 방법론이 함께 공개됐을 때만 읽으세요. 기준 체크포인트와 런타임 환경이 없으면 숫자만으로는 아무것도 알 수 없습니다.

로컬 추론 비용을 줄이는 방향으로 고민 중이라면 GPT-5.6 Sol이 호출 경로에 따라 단가가 2.2배까지 갈렸던 사례도 함께 볼 만합니다. 같은 모델이 어디를 거치냐에 따라 결과가 달라진다는 점에서 구조가 닮았습니다.

이 글이 말하지 않는 것

마지막으로 범위를 분명히 해 두겠습니다.

• 이 실측은 Qwen3.x 계열, 특정 GPU, 특정 vLLM 나이틀리 빌드에서 나온 결과입니다. 다른 모델 계열이나 다른 하드웨어에서 순위가 같으리라는 보장은 없습니다. 저자 본인이 NVFP4 결과가 네이티브 FP4 미지원 경로 때문일 수 있다고 밝혀 뒀습니다.
• “어떤 양자화가 가장 똑똑한가”를 잰 게 아닙니다. 기준 실행에서 얼마나 벗어났는지를 쟀을 뿐입니다.
• 뒤집힘 비율은 작업 종류에 크게 좌우됩니다. 저자도 어떤 작업은 1% 미만이고 어떤 작업은 설정에 따라 크게 튄다고 적었습니다.
• 검열 해제 파생본 측정은 그 파생본이 얼마나 잘 검열 해제됐는지를 말해 주지 않습니다.

저자는 테스트 도구와 데이터셋을 배포 가능한 패키지로 묶어 각자 자기 장비에서 돌리고 결과를 보고할 수 있게 만드는 작업을 진행 중이라고 밝혔습니다. H200과 B200 예비 결과도 이미 나와 있다고 예고했고요.

그때가 되면 “이 모델 좋다더라”는 말 대신 “내 장비에서 재 봤더니 이렇더라”를 주고받을 수 있게 됩니다. 로컬 LLM 이야기에서 가장 아쉬웠던 게 바로 그 부분이었습니다.