LLM은 어디까지 진화할까? 대화 상대에서 일하는 동료까지

대형 데이터센터에서 개인 기기로 이어지는 LLM의 발전과 미래를 표현한 이미지 1

AI를 활용하여 생성한 이미지입니다.

LLM의 다음 단계는 더 유창한 대화만이 아닙니다. 텍스트를 생성하던 모델이 이미지와 음성을 읽고, 검색·파일·코드 실행 도구를 호출하는 방향으로 넓어지고 있습니다. 그 결과 모델은 “답을 쓰는 프로그램”에서 “정해진 권한 안에서 일을 요청하는 시스템”으로 가까워질 수 있어요. 다만 자동 실행은 정확성이나 책임을 자동으로 보장하지 않으므로, 승인·로그·복구를 설계에 포함해야 합니다.

Transformer에서 다양한 입력으로

2017년 발표된 Attention Is All You Need 논문은 Transformer 구조와 attention 기반 처리 방식을 제시했습니다.[1] 이후 대규모 언어 모델은 요약, 번역, 질문 답변, 코드 작성처럼 서로 다른 작업을 한 인터페이스에서 다루게 됐습니다. 중요한 변화는 모델이 사람처럼 이해한다는 뜻이 아니라, 하나의 모델이 여러 입력과 출력 형식을 처리할 수 있게 된 점입니다.

최근 개발 API는 텍스트 외에도 이미지와 음성 입력, 도구 호출, 구조화된 출력을 지원합니다. Google Gemini API 문서가 이런 기능과 구현 방식을 안내합니다.[2] 사진에서 표를 읽거나 회의 녹음에서 할 일을 추출하는 작업은 편리하지만, 이미지 속 숫자를 잘못 읽거나 발화자의 의도를 놓칠 수 있습니다. 입력 형식이 늘어도 결과 확인이 사라지는 것은 아닙니다.

대화와 작업 수행은 어떻게 다른가요?

캘린더 조회, 파일 검색, 코드 실행, 데이터베이스 호출을 연결하면 모델은 설명만 하는 대신 외부 시스템에 작업을 요청할 수 있습니다. Anthropic이 제안한 Model Context Protocol은 AI 애플리케이션과 외부 도구·데이터를 연결하기 위한 표준적 방법을 설명합니다.[3] 하지만 연결 표준이 있다고 해서 도구가 안전해지는 것은 아닙니다. 어떤 계정으로 어떤 파일을 읽고, 쓰기 작업을 어디까지 허용하는지가 별도 문제입니다.

단계 모델이 하는 일 사람이 확인할 항목
답변 문장·요약·코드 초안 생성 사실, 날짜, 출처, 입력 누락
도구 사용 검색·파일 조회·계산 요청 권한, 검색 범위, 반환 원문
자동화 여러 도구를 순서대로 호출 승인, 변경 내역, 실패 시 복구

앞으로 예상할 수 있는 변화

역할을 나눈 작은 팀 구조

조사, 작성, 검수, 실행을 서로 다른 모델이나 단계별 호출로 나누는 설계가 늘어날 수 있습니다. 조사 단계는 읽기 권한만 갖고, 작성 단계는 초안을 만들며, 실행 단계는 승인된 변경만 적용하는 구조입니다. 이 방식은 역할별 오류를 추적하기 쉽지만, 단계가 늘수록 전달된 정보와 권한을 기록해야 합니다.

큰 모델과 작은 모델의 분업

알림, 간단한 분류, 짧은 요약은 노트북이나 휴대폰의 작은 모델이 처리하고 복잡한 문제만 서버 모델로 보내면 비용과 지연을 줄일 여지가 있습니다. 반대로 기기 안에서 처리하면 메모리와 배터리, 모델 업데이트 관리가 부담이 될 수 있습니다. 실제 지원 범위는 모델과 기기별로 확인해야 하며, “로컬이면 무조건 비공개”라고 단정해서도 안 됩니다.

행동 로그가 답변보다 중요해지기

파일을 고치고 코드를 실행하는 시스템에서는 최종 문장보다 어떤 파일을 읽었고 어떤 명령을 실행했는지가 중요합니다. 사용한 모델, 프롬프트 버전, 도구 입력, 반환 결과, 승인자와 변경 시각을 남겨야 문제가 생겼을 때 원인을 좁힐 수 있습니다. 로그에 개인정보와 비밀 토큰이 들어가지 않도록 별도 보존 정책도 필요합니다.

비용은 토큰만의 문제가 아닙니다

Stanford AI Index 2025는 모델 개발 경쟁과 활용 범위가 여러 국가와 산업으로 넓어지는 흐름을 다룹니다.[4][5] 서비스 비용을 계산할 때는 모델 호출료뿐 아니라 데이터 정제, 평가, 저장, 지연으로 인한 재시도, 사람이 결과를 검토하는 시간까지 포함해야 합니다. 모델을 많이 호출했다고 업무 결과가 좋아지는 것은 아닙니다.

왜 아직 자주 틀리나요?

LLM은 다음에 올 토큰을 예측하는 시스템이지, 문장을 생성했다는 이유만으로 사실을 확인하는 시스템은 아닙니다. 최신 정보, 긴 문서의 예외, 계산, 권한이 필요한 작업에서 오류가 발생할 수 있습니다. 외부 도구가 잘못된 값을 반환하면 모델이 그 값을 사실처럼 정리할 수도 있어요. 중요한 결과는 원문, 공식 출처, 실행 로그를 함께 확인해야 합니다.

도구 연결을 시작하는 안전한 기준

작업 권한 초보자 운영 기준
문서 요약·질문 읽기 공유 범위와 개인정보를 확인
검색·자료 수집 외부 읽기 검색어, 날짜, 원문 링크를 기록
파일 수정·메일 작성 쓰기·전송 미리보기와 사람 승인 후 실행
삭제·구매·배포 고위험 변경 자동 실행 목록에서 제외하고 이중 확인
  1. 민감하지 않은 복사본과 제한된 계정으로 시작합니다.
  2. 모델이 읽을 파일, 호출할 도구, 예상 결과를 문서로 적습니다.
  3. 첫 실행은 미리보기나 승인 모드로 두고 사람이 원문과 비교합니다.
  4. 문제가 생기면 실행을 중지하고 변경 기록과 백업으로 되돌립니다.

자동 승인은 지능을 높이지 않습니다. 승인 단계를 줄일 뿐 모델의 사실성이나 판단력을 개선하지 않습니다. 특히 파일 삭제, 메일 전송, 결제, 공개 배포처럼 되돌리기 어려운 작업은 사람이 마지막 결과를 직접 확인하는 편이 안전합니다.

자주 묻는 질문

멀티모달이면 사람처럼 이해하나요?

아닙니다. 입력 종류가 늘어도 인식 오류와 최신 정보 오류가 사라지는 것은 아닙니다. 이미지의 작은 글자, 음성의 말투와 맥락, 화면 밖의 조건은 놓칠 수 있습니다.

도구를 쓰는 AI는 곧 자율적인 직원인가요?

도구 호출은 정해진 권한 안에서 작업을 요청하는 기능입니다. 책임과 최종 승인까지 모델에 넘긴다는 뜻은 아닙니다. 조직은 계정 소유자, 승인자, 복구 담당자를 따로 정해야 합니다.

여러 모델로 나누면 오류가 없어지나요?

오류를 다른 단계에서 발견할 가능성은 높일 수 있지만 자동으로 사라지지는 않습니다. 모델이 같은 잘못된 입력을 공유하거나, 앞 단계의 오류를 뒤 단계가 그대로 신뢰할 수 있습니다. 단계별 입력과 결과를 기록하고 독립적인 검토 기준을 두세요.

업무에 도입할 때의 결정 기준

새로운 LLM을 고를 때는 대화 품질만 비교하지 말고 입력 데이터가 어디에 저장되는지, 관리자와 사용자의 권한을 나눌 수 있는지, 결과를 내보낼 수 있는지부터 확인하세요. 사내 문서를 연결할 경우 문서 삭제나 권한 변경이 검색 색인에 언제 반영되는지, 퇴사자의 접근이 즉시 끊기는지, 공급자가 장애 때 어떤 상태를 제공하는지도 운영 조건입니다. 기능 시연에서는 잘 보이지 않지만 실제 비용과 위험을 좌우합니다.

작은 팀이라면 먼저 사람이 이미 검토하는 읽기 전용 업무를 골라 기준선을 만드세요. 예를 들어 회의록에서 할 일을 추출하는 경우 누락률, 잘못된 담당자 지정, 검토에 걸리는 시간을 기록합니다. 그 뒤 검색과 파일 조회를 붙이고, 초안 작성으로 넓힌 다음, 마지막에만 외부 발송이나 시스템 변경을 검토하세요. 단계별로 중단할 수 있어야 모델 교체나 권한 축소도 어렵지 않습니다.

도입 질문 확인할 자료 중단 신호
무엇을 줄이려 하나요? 현재 처리 시간·오류·검토량 측정할 업무 결과가 없음
어디까지 읽나요? 파일·계정·도구 권한 목록 전체 저장소 권한이 기본값
틀리면 어떻게 복구하나요? 백업·승인·변경 로그 삭제·전송을 되돌릴 방법이 없음

Sources

  1. [1] arXiv: Attention Is All You Need
  2. [2] Google Gemini API 문서
  3. [3] Anthropic: Model Context Protocol
  4. [4] Stanford HAI: AI Index 2025 Report
  5. [5] Stanford HAI: AI Index 2025 PDF

관련 콘텐츠

함께 읽을 글