같은 LLM을 써도 결과가 다른 이유, 도메인 전문성이 만드는 차이

같은 LLM을 써도 결과가 다른 이유, 도메인 전문성이 만드는 차이

AI 뉴스 썸네일

LLM을 쓰면 익숙하지 않은 분야에서도 어느 정도 쓸 만한 결과를 빠르게 만들 수 있어요. 하지만 같은 모델을 사용해도 숙련자가 얻는 결과는 다를 수 있어요. 모델의 답에서 필요한 단서를 골라내고, 틀린 방향을 바로잡는 데 도메인 지식이 쓰이기 때문이에요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
LLM 활용	요청 형식보다 해당 분야를 이해하는 능력이 결과 차이를 만들어요	좋은 답을 알아보고 다음 질문을 고르는 기준이 생겨요
수학 사례	테런스 타오는 짧은 질문과 대안 제시로 수학 대화를 주도했어요	답을 그대로 받기보다 검토하고 방향을 좁히는 과정이 보여요
개발 실무	코드베이스를 아는 개발자는 기존 구조와 제약을 근거로 모델을 교정할 수 있어요	일반론보다 현재 시스템에 맞는 해법을 찾기 쉬워져요
사람의 역할	모델이 강해져도 결과를 판별하고 원하는 해법을 설명하는 일은 남아요	검토 능력과 업무 지식이 AI 활용 성과에 직접 연결돼요

1. LLM 활용의 격차는 답을 판별하는 순간 벌어져요

Sean Goedecke는 2026년 7월 24일 공개한 글에서 LLM이 누구나 여러 분야의 제너럴리스트처럼 일하도록 돕는다고 봤어요. 예전에는 CSS처럼 부족한 기술을 숙련된 동료나 정확한 검색 결과에 의존해 메워야 했어요. 지금은 모델에 맡겨 기본 수준의 결과를 빠르게 얻을 수 있어요. 다만 저자는 이 접근성이 전문성의 가치를 낮추지는 않는다고 설명해요. 2

차이는 첫 답을 받은 뒤 드러나요. 도메인을 잘 아는 사람은 답변에서 쓸 만한 아이디어를 골라요. 이상한 가정이나 불필요하게 복잡한 경로도 알아차려요. 이어서 더 단순한 방법을 요구하거나, 이미 존재하는 규칙과 기능을 다시 확인할 수 있어요. 분야를 모르면 그럴듯한 답과 실제로 맞는 답을 구분하기가 훨씬 어려워요.

728x90

테런스 타오의 짧은 질문이 통했던 배경

글은 수학자 테런스 타오가 ChatGPT와 Jacobian Conjecture의 반례를 논의한 대화를 사례로 들어요. 타오는 모델의 긴 답을 항목별로 따라가지 않았어요. 필요한 부분만 짚고, 복잡해 보이는 접근에는 간접적으로 의문을 제기했어요. 모델이 제안한 다음 단계를 그대로 받기보다 스스로 다른 경로와 표현을 제시했어요. 2

겉으로 보이는 대화 형식만 따라 하면 같은 결과를 얻기 어려워요. 어떤 아이디어가 문제와 관련이 있는지, 어느 전개가 수상한지 판단하려면 수학을 이해해야 해요. 짧게 묻는 기술보다 짧은 질문 안에 무엇을 넣어야 하는지 아는 능력이 더 큰 비중을 차지해요.

코드베이스를 알면 구체적인 반박이 가능해요

개발 현장에서도 비슷해요. 코드베이스의 구조와 과거 결정 이유를 아는 개발자는 "이 기능은 기존 모듈이 이미 처리하지 않나요?" 또는 "현재 구조를 유지하면서 더 단순하게 풀 수 있나요?"처럼 범위를 좁힐 수 있어요. 모델의 일반적인 설계 원칙보다 실제 서비스의 데이터 흐름, 배포 조건, 팀 규칙이 더 중요한 문제도 많아요.

이런 지식은 모델이 만든 코드를 검토할 때도 쓰여요. 코드가 실행된다는 사실만으로는 충분하지 않아요. 기존 권한 체계와 맞는지, 중복 로직을 늘리지 않는지, 운영 중 어떤 장애를 만들 수 있는지 확인해야 해요. 숙련자는 답변을 완성품으로 받기보다 검토할 재료로 다룰 수 있어요.

낯선 분야에서는 초안을 얻는 데 의미가 있어요

전문성이 없는 분야에서 LLM을 쓰는 일도 유용해요. 빈 화면에서 시작하는 대신 용어, 접근 순서, 초안 구조를 얻을 수 있어요. 다만 검증할 기준이 약하다는 점을 고려해야 해요. 중요한 의사결정이라면 해당 분야의 공식 자료를 확인하거나 전문가의 검토를 거치는 편이 안전해요.

한 사람은 모든 분야의 전문가가 될 수 없어요. 익숙한 분야에서는 모델을 적극적으로 교정하고, 낯선 분야에서는 탐색과 초안 작성에 활용하는 식으로 역할을 나누는 접근이 현실적이에요. 저자도 대부분의 사용자가 두 방식을 섞게 된다고 설명해요. 2

왜 중요한가요

모델 성능이 좋아질수록 기본 결과를 만드는 비용은 낮아져요. 그다음 병목은 결과의 품질을 판별하고 업무 맥락에 맞게 수정하는 과정으로 옮겨가요. 개발자는 코드 생성 속도만 볼 게 아니라 요구사항, 기존 구조, 보안 조건을 근거로 결과를 검토해야 해요. 기획자나 분석가도 같은 방식으로 숫자의 의미와 빠진 조건을 확인해야 해요. 2

실무에서는 질문 문구를 외우는 것보다 검토 기준을 먼저 갖추는 편이 나아요. 원하는 결과의 조건을 적고, 모델 답변이 그 조건을 충족하는지 확인해 보세요. 틀린 답을 빠르게 알아보는 능력과 구체적인 대안을 제시하는 능력이 쌓이면 같은 LLM에서도 더 안정적인 결과를 얻을 수 있어요.

참고 자료

1. LLM은 전문성을 보상함 — GeekNews
2. LLMs reward expertise — Sean Goedecke