이 LocalLLaMA 글이 재밌는 이유는 처음 5초는 순진해 보이는데, 곧바로 시스템 질문으로 바뀐다는 점이다. 원글은 아주 직접적이다. LLM의 내부 계산은 애초에 고차원 벡터 공간에서 돌아가는데, 왜 reasoning은 여전히 chain-of-thought 같은 자연어 형식으로 드러나느냐는 물음이다. 벡터에서 계산하고 마지막 답만 언어로 바꾸면 더 빠르고 더 압축되고 더 직관적이지 않겠냐는 얘기다. inference 최적화와 구조 논문 이야기가 일상인 서브레딧이라, 이 질문은 허술한 상상이 아니라 140개 댓글이 붙는 기술 논쟁이 됐다.

가장 많이 나온 답은 의외로 단순했다. 아직 그걸 제대로 훈련시키는 법을 모른다는 쪽이다. 댓글은 COCONUT 같은 시도와 JEPA 계열 아이디어를 거론했지만, 반복된 경고는 하나였다. latent space는 기호판처럼 고정된 작업장이 아니다. 모델이 학습되는 동안 같이 움직인다. 그러니 그 안에 “중간 생각”을 안정적으로 감독하기가 어렵다. 어떤 댓글은 더 근본적인 질문도 던졌다. 그런 시스템을 훈련하려면 데이터셋을 어떻게 만들 것인가. 자연어 reasoning은 수집하고 채점하고 필터링할 수 있지만, 숨어 있는 벡터 scratchpad는 의도적으로 라벨링하기가 훨씬 어렵다.

스레드는 chain-of-thought를 둘러싼 흔한 착각도 정리했다. 많은 사람이 언어형 reasoning을 인간 사고의 자막처럼 상상하지만, 실제 배치된 모델에서 CoT는 다음 토큰 생성에 다시 먹히는 추가 문맥으로 작동한다. 즉 설명문이 아니라 작업 메모리 역할도 한다. 그래서 자연어는 설명 가능성 이상의 장점이 있다. 사람과 도구가 한 단계씩 검토하고 디버깅하고 제한을 걸 수 있기 때문이다. 커뮤니티가 특히 민감하게 본 것도 이 지점이다. reasoning이 완전히 latent로 숨어버리면 압축과 속도는 얻을지 몰라도, 수학·코딩·법률 논리·안전 같은 영역에서 검증 가능성을 크게 잃는다.

결국 스레드 결론은 “벡터가 낫다”도 “언어가 답이다”도 아니었다. 지금의 시스템은 inspectability를 위해 효율 비용을 일부러 지불하고 있고, 현장에서는 그 선택이 아직 합리적이라는 쪽에 더 가깝다. LocalLLaMA도 latent reasoning 자체를 부정하지는 않았다. 오히려 다음 연구 축으로는 꽤 진지하게 본다. 다만 당장 버튼 하나로 바꿔 넣을 수 있는 해결책은 아니라는 점이 더 분명해졌다. 이 질문은 UI 취향이 아니라 학습 안정성, 감독 방법, 평가, 신뢰의 문제까지 한 번에 건드린다. 그래서 댓글이 길어졌다.

#latent-space

LLM은 왜 벡터로 생각하지 않나, LocalLLaMA 140댓글이 모인 지점