LLM이 못 하는 일들 — 검증 루프 없는 과제에서 무너지는 구조적 이유

지난주 화요일 밤, Claude Code 에게 사무실 파티션 배치도를 맡겼다가 세 번 연속 문과 책상이 겹치는 도면을 받았다. 그날 Ask HN 에 올라온 스레드를 뒤늦게 읽다가 무릎을 쳤다. 나만 겪는 일이 아니었다. 저는 LLM이 못 하는 일들이 제각각 무작위로 흩어져 있는 게 아니라, 하나의 구조를 공유한다고 생각해요. 그 구조는 실력 부족이 아니라 검증할 대상이 모델 바깥에 있느냐 안에 있느냐의 문제입니다.

왜 도면과 사진 앞에서 LLM은 자꾸 무너질까요?

HN 스레드에서 한 건축 실무자가 이 문제를 정확히 짚었어요. 어떤 모델도 말이 되는 평면도를 그리는 데까지는 못 간다는 거였죠. 방 구성을 노드 그래프로 통째로 넘겨도 결과물은 여전히 말이 안 됐다고 합니다.

사진 속 생물 판별 사례는 더 인상적이었어요. 도요새 사진을 올렸더니 챗봇은 전혀 다른 새라고 답하면서 사진에 나오지도 않은 특징까지 설명했다고 합니다. 사용자가 그 지역에서 관찰된 적 없는 종이라고 지적하자 확신도를 낮췄고, 정확한 위치를 알려주자 그제야 정답을 맞혔대요.

두 사례의 공통점은 분명합니다. 확인할 대상, 그러니까 실제 벽의 위치나 사진에 찍힌 깃털 무늬가 전부 모델 바깥에 있어요. LLM은 그 대상과 자기 출력을 직접 대조할 방법이 없고, 사용자가 틀렸다고 하면 그 말에 맞춰 답을 바꿉니다. 확인이 아니라 눈치로 정답을 좇는 셈이죠.

LLM은 왜 자기 자신을 위한 프롬프트조차 못 쓸까요?

같은 스레드에서 한 개발자는 뜻밖의 사실을 발견했다고 썼어요. AI가 스스로에 대한 이해가 있으니 자기 프롬프트도 잘 설계할 거라 생각했는데 전혀 아니었다는 거죠. 프롬프트를 자기 언어로 처음부터 다시 쓰고 나서야 제대로 작동했습니다.

댓글 중 하나는 이 현상을 Anthropic이 이미 언급했다고 짚었어요. 지시보다 사실을 주는 편이 낫고, 짧을수록 모델이 스스로 판단할 여지가 커진다는 조언이었죠. 저는 이걸 단순한 팁이 아니라 LLM이 자기 출력을 되돌아보는 능력 자체가 약하다는 증거로 읽었습니다.

제 경우엔 이 문제를 숫자로 확인한 적이 있어요. 파이프라인 프롬프트를 Claude에게 직접 고쳐달라고 여섯 번 시켰는데, 여섯 번 다 게이트 통과율이 원래보다 낮아졌습니다. 제가 직접 문장을 다듬었을 때는 두 번 다 통과율이 올랐고요. 모델은 남의 글은 곧잘 비평하면서 자기 지시문이 왜 안 먹히는지는 스스로 판단하지 못하는 것 같았습니다.

그래도 이 한계가 곧 무용론은 아닙니다

물론 반론이 있을 수 있어요. 요약이나 코드 리뷰처럼 LLM이 압도적으로 잘하는 영역이 훨씬 많은데, 몇 가지 예외 때문에 전체를 의심할 필요가 있냐는 겁니다. 맞는 말이에요. 저도 하루 대부분의 작업은 LLM 없이 못 합니다. 다만 제가 말하려는 건 능력의 총량이 아니라 어떤 유형의 과제에 투입하느냐의 문제예요.

모델이 커지고 데이터가 늘면 결국 해결되지 않겠냐는 의견도 있을 수 있어요. 저는 동의하기 어렵습니다. 도면이 안 맞는 이유는 지식 부족이 아니라 실제 벽의 위치와 자기 출력을 대조할 채널 자체가 없기 때문이에요.

이미지 인식이 꽤 정확하던데요, 라고 반박하실 분도 있을 겁니다. 부분적으로는 맞아요. 확률적으로는 열 번 중 아홉 번은 맞힙니다. 문제는 나머지 한 번, 모델이 틀렸다는 걸 스스로 알아채지 못하고 사용자가 지적할 때만 답을 바꾼다는 점이에요.

그럼 어디까지 맡기고 어디부터는 사람이 확인해야 할까요?

제가 세운 기준은 단순해요. 결과를 확인할 대상이 모델 바깥의 실재라면 LLM 출력을 최종본으로 쓰지 않습니다. 도면은 실제 시공도와, 검색어는 실제 색인 결과와 대조한 뒤에만 신뢰합니다. 반대로 문장을 다듬거나 요약하는 것처럼 검증 대상이 언어 안에 있는 일이라면 LLM 판단을 그대로 받아들여도 큰 문제가 없더라고요.

이 기준은 팀 단위로 확장할수록 더 분명해집니다. 제가 운영하는 자동화 파이프라인에는 초안을 쓰는 에이전트와 별도로 검증만 전담하는 에이전트가 다섯 명 있어요. 초안 작가에게 자기 글을 스스로 검증하라고 시키지 않는 이유가 바로 이겁니다. 지난 한 달 동안 초안 작가가 통과라고 판단했다가 외부 검증자에게 막힌 경우가 여러 건 있었습니다.

LLM이 못 하는 일의 목록은 앞으로도 계속 나올 거예요. 그 목록을 하나씩 외우는 대신, 검증 대상이 모델 안에 있는지 밖에 있는지부터 물어보시길 권합니다. 그 질문 하나가 어디에 맡기고 어디서 멈춰야 할지를 훨씬 빠르게 알려줍니다.

자주 묻는 질문

Q. LLM이 공간 추론을 아예 못 한다는 뜻인가요? A. 완전히 못 하는 건 아니에요. 나쁜 평면도를 지적하거나 설명하는 비평 능력은 있습니다. 다만 처음부터 말이 되는 도면을 생성하는 건 다른 능력이고, 이 지점에서 반복적으로 무너집니다.

Q. 이미지 인식이 틀렸는지 어떻게 미리 확인하나요? A. 답을 낸 뒤 근거가 되는 부분을 짚어보라고 시키고 실제 사진과 대조해 보세요. 근거로 든 특징이 사진에 실제로 없다면 그 답은 재검토 대상입니다.

Q. 프롬프트 작성을 LLM에게 아예 맡기지 말라는 뜻인가요? A. 초안 작성은 맡겨도 되지만 최종 반영은 실제 결과(게이트 통과율, 실행 결과)로 비교한 뒤 사람이 확정하는 편이 안전합니다. 저는 프롬프트를 바꿀 때마다 전후 결과를 반드시 비교합니다.

Q. 검증 루프가 있는 작업과 없는 작업은 어떻게 구분하나요? A. 판단 기준이 텍스트 안에서 끝나면 검증 루프가 있는 쪽이고, 실제 공간·이미지·시스템 상태와 대조해야 끝나면 없는 쪽입니다. 후자는 사람이나 별도 도구의 확인을 거쳐야 합니다.