당신은 LLM을 오해하고 있다
ChatGPT에게 마크다운 표를 그려달라고 했을때 과연 결과는 어떨까?
10행 괜찮다. 50행쯤 되면 줄이 어긋난다. 100행이면 완전히 망가진다.
"——————"를 20개 그려달라고 하면 19개가 나올 때도 있고 21개가 나올 때도 있다.
사람들은 이걸 보고 "AI가 아직 멍청하다"고 말한다. 틀렸다.
이건 멍청함의 문제가 아니다. 구조의 문제다.
LLM은 마법이 아니다. 트랜스포머라는 아키텍처 위에서 돌아가는 '다음 단어 예측기'다. 이 구조를 이해하면 왜 어떤 건 잘하고 어떤 건 못 하는지 알 수 있다.
태생적으로 '다음 토큰 예측기'인 LLM은 한 번에 한 토큰씩 생성한다. "오늘" 다음에 "날씨가" 다음에 "좋다" 와 같은 방식이다. 전체 문장을 미리 계획하고 쓰는 게 아니다. 마치 목적지를 모르고 한발씩 내딛는 사람처럼 말이다.
마크다운 표를 생각해보자.
| 이름 | 나이 | 직업 |
처럼 파이프(|) 문자로 열을 구분한다. 10행짜리 표를 그리려면 각 행의 파이프 위치가 정확히 맞아야 한다.
트랜스포머는 각 파이프를 독립적으로 예측한다. 첫 번째 행의 파이프 위치를 기억해서 두 번째 행에 적용하는 게 아니다. 매번 "여기에 파이프가 올 확률"을 계산할 뿐이다.
행이 많아지면 오류가 누적된다. 초기의 작은 어긋남이 뒤로 갈수록 커진다. 연구자들은 이걸 'compounding errors(오류 복합)'라고 부른다.
복잡한 표는 더 심하다. 셀 병합, 중첩 헤더, 다단 구조 같은 건 마크다운으로 표현 자체가 어렵다. LLM에게 "엑셀처럼 복잡한 표 그려줘"라고 하면 높은 확률로 망가진 결과가 나온다.
연속된 토큰도 마찬가지다. "대시 20개 그려줘"라고 하면 LLM은 "대시가 몇 개 필요한지"를 계산하지 않는다. "다음에 대시가 또 나올 확률"을 계속 예측할 뿐이다. 그래서 19개가 나오기도 하고 21개가 나오기도 한다.
한국 공문서를 다뤄본 사람은 안다. 목차에
"제1장 서론.......................1p"
같은 형식이 있다. 점의 개수가 페이지 번호 위치에 맞춰 정렬되어야 한다. LLM에게 이걸 시키면 정신이 나간다. 점이 23개가 되기도 하고 27개가 되기도 한다.
컨텍스트 윈도우도 한계다. LLM이 한 번에 처리할 수 있는 텍스트 양에는 한계가 있다. Claude는 200K 토큰, ChatGPT는 128K, Gemini는 1M까지 지원한다고 하지만 — 실제 사용해보면 다르다. 길어지면 까먹거나 환각이 생긴다.
Self-attention 메커니즘은 입력 길이의 제곱에 비례하는 계산량을 요구한다. 길이가 길어지면 품질도 떨어지고 속도도 느려진다. 단답형은 잘 맞춰도 장문을 뱉으라고 하면 문제가 생긴다.
정리하면:
트랜스포머는 한 토큰씩 생성한다 — 전체 구조를 계획하지 않는다
오류는 누적된다 — 초기 실수가 후속 예측을 오염시킨다
컨텍스트 윈도우 안에서만 작동한다 — 윈도우를 넘으면 맥락을 잃는다
멀티모달 LLM은 이미지를 "이해"한다. 하지만 "측정"하지는 않는다.
되는 것:
이미지 내용 설명 — "이 사진에 뭐가 보여?" → "해변에서 사람이 서핑하고 있습니다"
텍스트 추출 — 간판, 문서, 손글씨에서 글자 읽기
시각적 질의응답 — "이 사진에서 빨간 물체가 뭐야?"
스타일/분위기 분석 — "이 그림은 인상주의 화풍입니다"
안 되는 것:
픽셀 단위 측정 — "이 물체가 정확히 몇 픽셀인지"
극도로 정밀한 이미지 편집
복잡한 장면에서 공간 추론
복잡한 장면에서 Vision Language Model의 환각률은 10-30%다. 꽤 실수가 있는 편이다.
전처리도 비슷한 한계가 있다.
되는 것:
텍스트 정제(오타 수정, 포맷 통일)
데이터 구조화(CSV → JSON 변환)
간단한 필터링.
안 되는 것:
대용량 데이터 일괄 처리(컨텍스트 윈도우 제한)
100% 일관성 보장(확률적 생성의 특성)
LLM에게 1만 행짜리 CSV를 정리해달라고 하면 못 한다. 잘라서 여러 번 처리해야 하고, 그 과정에서 일관성이 깨질 수 있다. 같은 프롬프트를 줘도 매번 약간씩 다른 결과가 나온다. 이건 버그가 아니라 확률적 생성의 본질이다.
위 한계들 때문에 LLM을 다양한 케이스에 활용하기 어렵다. 그럼 포기해야 하나?
인간은 언제나 답을 찾는다. 그래서 외부 도구를 연결하기 시작했다.
Tool Calling은 LLM이 "이 도구를 써야겠다"고 판단하면 특정 포맷(주로 JSON)으로 출력하는 방식이다. LLM 자체가 도구를 실행하는 게 아니다. 호출 프로그램이 그 출력을 읽고, 실제로 도구를 실행하고, 결과를 다시 LLM에 피드백한다.
비유하자면: LLM은 "생각"만 한다. "행동"은 외부 시스템이 담당한다.
계산기를 예로 들어보자. LLM에게 "123456 × 789012"를 물어보면 틀릴 수 있다. 하지만 "계산기 도구를 쓰겠다"고 결정하고 JSON을 출력하면, 외부 시스템이 실제 계산을 수행해서 정확한 결과를 돌려준다.
계산은 계산기에 맡기고, 검색은 검색 엔진에 맡기고, 코드 실행은 인터프리터에 맡긴다. LLM은 "무슨 도구를 쓸지 판단"하는 역할만 한다.
예시)
{ "operation": "multiplication",
"operands": {
"a": 123456,
"b": 789012
},
"expression": "a * b"
}
MCP(Model Context Protocol) 는 Tool Calling을 표준화한 프로토콜이다. Anthropic이 오픈소스로 공개했다. MCP 이전에는 각 도구마다 커스텀 통합이 필요했지만 MCP 등장 이후에는 표준 인터페이스로 연결되었다.
핵심은 동적 발견이다. MCP 이전에는 도구 목록을 미리 정의해야 했다. MCP 이후에는 런타임에 "어떤 도구가 있는지" 물어보고, 상황에 맞는 도구를 골라 쓸 수 있다. USB처럼 생각하면 된다. USB 규격이 생기기 전에는 프린터, 키보드, 마우스 전부 다른 포트를 썼다. USB가 생긴 후에는 뭐든 꽂으면 된다. MCP가 AI 도구 세계의 USB다.
RAG(Retrieval-Augmented Generation)는 LLM의 지식 한계를 보완하는 기술이다. 외부 문서를 검색해서 LLM 입력에 추가한다. 학습 데이터에 없는 최신 정보나 전문 지식을 활용할 수 있다.
작동 방식은 단순하다:
질문이 들어오면
벡터 DB에서 관련 문서를 검색하고
검색 결과를 LLM에 전달하고
LLM이 답변을 생성한다
RAG 덕분에 LLM이 "모르는 것"도 답할 수 있게 됐다. 회사 내부 문서, 최신 뉴스, 전문 논문 — 학습 데이터에 없어도 검색해서 참고하면 된다.
단, RAG도 만능은 아니다. 검색이 잘못되면 엉뚱한 문서를 참고하고, 환각을 완전히 막지는 못한다. 하지만 "지식의 범위를 확장한다"는 점에서 중요한 극복 기술이다.
Skills는 한 단계 더 나아간다. 프롬프트와 도구를 묶어서 특정 작업에 최적화한 패키지다.
Tool Calling은 "도구 하나를 부르는 것"이다. Skills는 "프롬프트 + 여러 도구 + 리소스"를 하나의 전문 지식 패키지로 묶는다.
Claude Skills를 예로 들면: 엑셀 처리, PPT 생성, 심지어 도면 그리기까지 — 사람들이 직접 만든 Skills 생태계에서 내가 원하는 Skill을 가지고 와서 쓰는 개념이다. 이미 수천 개가 넘는 도구가 개발 커뮤니티에 퍼져있다. AI가 원래 못 하던 일들을 Skills로 하나씩 정복해 나가고 있다.
예전에는 모르는 게 있으면 책을 사거나, 강의를 듣거나, 전문가에게 상담료를 내야 했다. 시간과 돈이 들었다. 지금은 질문 하나면 된다. "계약서 검토할 때 주의할 점이 뭐야?" "이 증상이 뭘 의미해?" "이 코드 에러 원인이 뭐야?"
물론 정확성 검증은 필요하다. LLM의 답변을 무조건 신뢰하면 안 된다. 하지만 "첫 번째 진입점"으로서의 가치는 분명하다. 우리는 모르는 내용에 대해 묻고 개념을 알아낼 수 있다. 역사와 종교의 교집합을 찾아낼 수 도 있고, 철학과 물리학 사이의 교집합도 찾아낼 수 있다. 우리가 기존에 알고 있던 지식과 모르는 정보에 대한 호기심이 합쳐져 더 쉽고 빠르게 앎의 뿌리를 뻗어나갈 수 있게 된 것이다.
지식 접근 불평등이 줄어들고 있다. 좋은 학교를 나오지 않아도, 영어 혹은 특정 언어를 구사하지 못해도 — 누구나 전문 지식에 접근할 수 있다.
보고서 양식 채우기
이메일 초안 작성
데이터 정리 및 요약
반복 질의응답
위 항목들의 공통된 핵심은 "패턴"이다. 형식이 정해져 있고, 내용만 바뀌는 일. 이런 일은 LLM이 가장 잘하는 업무 중 하나다. 인간은 "이 보고서 내용이 맞나?", "이 이메일 톤이 적절한가?", "이 요약이 핵심을 담았나?"와 같이 판단에만 집중하면 된다.
항상 잊으면 안되는 요소는 — 최종 검토는 인간의 몫 — 이라는 점이다.
LLM은 기본적으로 대량의 데이터에서 정답 맞추기를 잘한다. 그 뜻은 보기를 주고 그 중에 하나를 고르는 일에는 귀신이라는 뜻. 놀라울 정도로 분류를 잘한다.
고객 문의를 "환불/배송/제품문의/기타"로 분류
뉴스 기사를 "정치/경제/사회/문화"로 분류
이메일을 "긴급/일반/스팸"으로 분류
감정 분석 — "긍정/부정/중립"
예전에는 분류기를 만들려면 데이터를 모으고, 라벨링하고, 모델을 학습시켜야 했다. 몇 주가 걸렸다.
지금은 프롬프트 한 줄이면 된다. "다음 텍스트를 A/B/C 중 하나로 분류해줘." 끝이다.
분류 기준만 명확하게 설명하면 사람이 하는 것과 비슷하거나 더 일관된 결과가 나온다. 사람은 피곤하면 판단이 흔들리지만 LLM은 그렇지 않다. 수천 개의 고객 리뷰를 주제별로 나누거나, 문서 더미를 카테고리별로 정리하거나. 사람이 하면 며칠 걸릴 일을 몇 시간에 처리할 수 있다.
기술 이야기는 여기까지. 이제 실전이다. 개발자가 아닌 일반 유저로서 LLM을 어떻게 활용할 것인가에 대해 이야기 해보자.
Skills가 "기술적 극복책"이라면, Gems, GPTs, Artifacts는 일반 유저가 쉽게 쓰는 "소비자용 인터페이스"다.
Gemini Gems:
커스텀 Gemini를 한 번 만들어 영구 재사용
무료 Google 계정으로 생성 가능
Google Docs, Sheets, Slides와 직접 연동
ChatGPT GPTs:
특정 용도에 최적화된 ChatGPT 버전
GPT Store에서 다른 사람이 만든 GPT를 바로 사용 가능
생성은 Plus($20/월) 필요, 사용은 무료
Claude Artifacts:
대화 중 생성한 코드나 문서를 별도 패널에 표시
실시간 미리보기 — HTML 만들면 바로 렌더링
차트, 웹페이지, 코드 실행 결과를 즉시 확인
활용 예시:
매일 아침 특정 주제 뉴스 요약하는 Gem
회의록을 정해진 양식으로 정리하는 GPT
데이터 시각화를 즉석에서 만드는 Artifact
ChatGPT Tasks와 Gemini Scheduled Actions를 쓰면 LLM이 정해진 시간에 자동으로 작업을 수행한다.
"매일 오후 3시에 AI 뉴스 요약해줘"
"매주 월요일 주간 보고서 초안 자동 생성"
"특정 키워드 웹 검색 결과 정기 알림"
최대 10개 활성 태스크, 결과는 앱 알림이나 이메일로 받는다.
이게 API 없이 할 수 있는 자동화의 끝이다. 더 복잡한 자동화는 코딩이 필요하다.
복잡한 작업은 하나의 거대한 프롬프트로 처리하기 어렵다. 대신 여러 개의 작은 전문 도구로 분해한다.
예시: 블로그 글 작성
왜 쪼개는가?
각 단계별 품질 검증 가능 — 어디서 문제가 생겼는지 안다
실패하면 해당 단계만 다시 실행 — 처음부터 안 해도 된다
단계별 최적화 가능 — 리서치용과 글쓰기용을 각각 튜닝
사람이 각 단계의 결과를 복사해서 다음 단계에 붙여넣는 "수동 파이프라인"이다. 번거롭지만 확실하다.
1. 마법을 기대하지 마라
LLM은 "다음 단어 예측기"다. 100행짜리 표를 완벽하게 그려주길 기대하면 실망한다. 한계를 알고 쓰면 화날 일이 없다.
2. 검증은 필수다
LLM의 답변을 그대로 쓰지 마라. 특히 숫자, 날짜, 고유명사는 반드시 확인하라. "첫 번째 초안"으로 받아들이고, 최종 판단은 본인이 해야 한다.
3. 작게 쪼개서 시켜라
"보고서 전체 써줘"보다 "개요 잡아줘" → "1장 써줘" → "검토해줘"가 낫다. 단계별로 확인하면서 진행하면 품질이 올라간다.
4. 반복 작업부터 자동화하라
매일 하는 단순 작업이 있다면 Gem이나 GPT로 만들어라. 한 번 세팅해두면 계속 쓴다. 시간 투자 대비 효과가 크다.
5. 도구는 도구일 뿐이다
LLM이 답을 줘도 결정은 당신이 한다. LLM은 "생각을 돕는 도구"지 "생각을 대신하는 기계"가 아니다.
LLM이 못하는 것과 잘하는 것을 명확하게 구분하여 내가 할 일과 AI가 할 일을 구분짓자. 이미 AI 시대가 시작되었고 뒤로 갈수도 없는 노릇. 이런 작업 방식에 적응해야만 살아남을 수 있는 시대가 되었다. 화이팅해서 살아남자. 모두.
LLM이 못 하는 것:
긴 표, 반복 패턴 — 토큰 단위 예측의 한계
정밀한 이미지 측정 — "이해"는 되지만 "측정"은 안 된다
대용량 일괄 처리 — 컨텍스트 윈도우와 일관성 문제
LLM이 잘하는 것:
지식 접근 비용을 0원에 가깝게 낮춘다
인간 인지 능력을 강화한다
모르는 분야의 진입 장벽을 낮춘다
패턴 있는 반복 작업을 자동화한다
분류 작업을 빠르고 일관되게 처리한다
일반 유저가 할 것:
Gems, GPTs, Artifacts로 나만의 도구를 만든다
복잡한 작업은 쪼개서 단계별로 처리한다
검증은 필수, 최종 판단은 본인이 한다
극복 기술:
Tool Calling → MCP → RAG → Skills
도구를 연결해서 한계를 보완한다