LLM이 코딩과 수학은 잘하지만 일상 질문에는 약한 이유는 모순이 아니다

최근 연구들에 따르면 대규모 언어 모델(LLM)이 코드 리팩토링이나 수학 문제 풀이에서는 뛰어난 성능을 보이면서도 일상적인 질문에는 엉뚱한 답변을 내놓는 현상이 반복적으로 관찰되고 있다. 이는 LLM의 학습 구조를 이해하면 자연스러운 결과다. 코딩과 수학은 명확한 규칙 체계, 풍부한 고품질 학습 데이터(오픈소스 코드, 논문, 교과서), 그리고 정답 여부를 검증할 수 있는 객관적 피드백 루프가 존재한다. 반면 일상적 질문은 암묵적 맥락, 문화적 배경지식, 상식 추론이 요구되며, 학습 데이터에서도 이런 유형의 정답-오답 쌍이 체계적으로 구축되어 있지 않다. 결국 LLM은 형식적 추론(formal reasoning)에는 강하지만, 체화된 경험(embodied experience)에 기반한 판단에는 구조적 한계를 가진다.

이 현상이 개발자에게 시사하는 바는 명확하다. LLM을 코드 생성, 리팩토링, 버그 탐지 등 형식적 규칙이 명확한 영역에 활용할 때는 높은 생산성 향상을 기대할 수 있다. 실제로 많은 팀에서 AI 어시스턴트를 도입해 보일러플레이트 코드 작성 시간을 크게 단축하고 있으며, 알고리즘 최적화나 테스트 케이스 생성에서도 실질적인 효과를 얻고 있다. 그러나 요구사항 해석, 사용자 의도 파악, 비즈니스 로직의 맥락적 판단처럼 암묵적 지식이 필요한 영역에서는 LLM의 출력을 그대로 신뢰하기 어렵다. 예를 들어 "이 기능이 사용자에게 혼란을 줄 수 있는가"와 같은 판단은 여전히 인간 엔지니어의 몫이다.

개발자가 취해야 할 실질적인 행동은 LLM의 강점과 약점을 정확히 구분하여 활용 전략을 세우는 것이다. 코드 작성, 정적 분석, 문서화, 테스트 자동화 등 구조화된 작업에는 적극적으로 LLM을 투입하되, 아키텍처 의사결정이나 사용자 경험 설계처럼 맥락 의존적인 판단에는 반드시 인간의 검토를 거쳐야 한다. 또한 프롬프트 설계 시 모호한 자연어 질문보다는 구체적인 제약 조건과 형식을 명시하면 LLM의 약점을 상당 부분 보완할 수 있다. "이 함수를 최적화해줘"보다 "이 함수의 시간 복잡도를 O(n²)에서 O(n log n)으로 줄여줘"처럼 형식적으로 정의된 요청이 훨씬 안정적인 결과를 만든다. LLM은 만능 도구가 아니라 특정 영역에서 극도로 강력한 전문 도구이며, 그 경계를 인식하는 엔지니어가 가장 효과적으로 활용할 수 있다.