Daily News Korea

[태그:] LLM

  • LLM 서빙 하네스, 모델보다 병목 측정이 먼저다

    LLM 서빙 하네스, 모델보다 병목 측정이 먼저다

    3줄 요약

    • 서빙 하네스는 모델을 감싸는 아키텍처·메모리 관리·스케줄링·최적화 결정의 묶음이다. 같은 모델을 써도 이 설계에 따라 프로덕션의 속도와 비용이 달라진다.
    • 추론 중에 모델 가중치는 크기가 고정이지만 KV 캐시는 동시 요청 수와 컨텍스트 길이에 따라 커진다. 그래서 연산 여력이 남아 있어도 GPU 메모리가 먼저 바닥날 수 있다.
    • 최적화는 기법을 모으는 일이 아니다. 측정하고, 병목을 찾고, 해결하고, 다시 측정하는 일을 반복하는 것이다. 모델 교체가 플랫폼 재구축이 아니라 평가와 설정 변경으로 끝나도록 설계하는 것이 목표다.

    GPU 연산 여력은 아직 남아 있다. 그런데 동시 요청이 조금 늘자 응답이 밀리기 시작한다. LLM을 직접 띄워 운영하는 팀이라면 충분히 마주칠 수 있는 장면이다.

    이때 먼저 떠오르는 해법은 두 가지다. 모델을 바꾸거나, GPU를 더 사거나. 원인이 모델 바깥에 있다면 둘 다 돈만 더 쓰는 선택이 될 수 있다.

    EXL이 MIT Technology Review에 실은 기고문은 이 ‘모델 바깥’에 서빙 하네스(serving harness)라는 이름을 붙였다. 매체 편집국이 아니라 EXL이 제작한 콘텐츠다. 주장은 한 줄로 줄어든다. 엔터프라이즈 AI의 다음 경쟁력은 어떤 모델을 고르느냐보다 그 주변에 무엇을 짓느냐에 달렸다는 것.

    솔루션 기업이 쓴 글이니 걸러 들을 대목은 있다. 다만 뼈대가 되는 설명, 즉 가중치는 고정이고 KV 캐시는 요청에 따라 불어난다는 대목은 추론 시스템의 일반적인 동작 원리와 맞아떨어진다. 개념을 정리하는 용도로는 충분히 쓸 만하다. 아래에서 서빙 하네스의 구성, 병목이 생기는 지점, 그 병목을 푸는 순서를 차례로 본다.

    서빙 하네스, 가중치 파일 바깥의 네 가지 결정

    AI 이야기의 중심엔 늘 모델 성능이 있었다. 더 큰 모델, 더 나은 추론 능력, 더 긴 컨텍스트 윈도, 더 높은 벤치마크 점수.

    실험 단계를 지나 프로덕션에 들어서면 질문 자체가 바뀐다.

    • 실험 단계: ‘이 모델이 뭘 할 수 있지?’
    • 프로덕션: ‘이 지능을 안정적으로, 경제적으로, 대규모로 전달할 수 있나?’

    서빙 하네스는 두 번째 질문에 답하는 시스템이다. 모델 가중치 파일 자체를 말하는 게 아니다. 모델을 둘러싸고 요청을 받아 처리하고 응답을 돌려주는 엔지니어링 전체를 가리킨다. 쪼개 보면 네 덩어리.

    • 아키텍처: 요청이 어떤 경로로 들어와 어느 서버와 GPU에서 처리되는지, 모델을 몇 벌 띄워 어떻게 배치하는지
    • 메모리 관리: 한정된 GPU 메모리를 모델 가중치와 요청별 상태(뒤에서 볼 KV 캐시)에 어떻게 나눠 쓰는지
    • 스케줄링: 동시에 들어온 요청을 어떤 순서와 묶음으로 처리할지
    • 최적화 결정: 양자화, 추측 디코딩, 어텐션 최적화 같은 기법 중 무엇을 언제 적용할지

    하네스(harness)는 원래 말에 씌우는 마구, 혹은 전선을 묶은 배선 뭉치를 뜻한다. 힘을 내는 건 말이지만, 그 힘으로 마차를 끌게 만드는 건 마구다. 이름부터가 꽤 정확한 비유다.

    기고문의 논리는 이렇게 이어진다. 기업들이 점점 같은 모델을 쓸 수 있게 되면서 모델만으로는 차별화가 어려워진다. 차이는 그 모델을 얼마나 효율적으로 실제 기능으로 바꾸느냐에서 난다.

    대화형이냐 배치형이냐가 서빙 구조를 가른다

    전제부터 짚자. 누구에게나 ‘최고’인 모델이나 AI 아키텍처는 없다. 풀려는 업무 문제에 맞는 해법이 있을 뿐이다. 워크로드가 제약을 정하고, 제약이 서빙 구조를 정한다.

    빠른 응답이 생명인 고객 응대 어시스턴트와 밤새 돌아가도 괜찮은 문서 처리 파이프라인. 둘을 나란히 놓으면 요구사항이 근본부터 다르다.

    • 대화형 서비스: 사용자가 첫 글자를 기다리는 시간이 체감 품질을 좌우한다. 지연을 짧게 유지하는 게 1순위.
    • 배치형 파이프라인: 개별 응답 속도보다 전체 처리량과 건당 비용이 중요하다.

    사내 지식 검색 앱과 대량 트래픽을 받는 고객 서비스 플랫폼도 마찬가지다. 같은 기반 모델을 써도 서빙 구조는 완전히 달라질 수 있다.

    문제는 PoC 단계에선 이 차이가 잘 안 보인다는 점. 사용자가 몇 명뿐이면 모델 정확도가 논의를 독차지한다. 지연, 동시성, 메모리 압박, GPU 활용률, 인프라 비용, 예측하기 어려운 트래픽 같은 제약은 뒤로 밀리기 쉽다. 그리고 프로덕션에 올라가는 순간 한꺼번에 드러난다.

    구분 PoC 단계 프로덕션 단계
    핵심 질문 모델이 무엇을 할 수 있나 그 지능을 안정적·경제적·대규모로 전달할 수 있나
    주로 보는 지표 모델 정확도 지연, 동시성, GPU 활용률, 인프라 비용
    사용자와 트래픽 소수 사용자 많은 사용자, 예측하기 어려운 트래픽
    메모리 압박 사용자가 적어 무시하기 쉬움 동시 요청이 늘면서 병목으로 드러남
    모델 선택 기준 가장 좋은 답을 내는 모델 워크로드에 맞는 성능을 맞는 비용으로 내는 모델

    기고문에 나오는 비유 하나가 이 표의 마지막 줄을 잘 요약한다. 모든 워크로드에 페라리가 필요한 건 아니라는 것.

    답변이 조금 더 나은 모델이라도 추론 비용을 두 배로 늘리거나 애플리케이션의 지연 요구를 맞추지 못한다면, 프로덕션에서는 더 나은 선택이 아닐 수 있다. 업무에 필요한 만큼의 성능을 내면서 쓰지도 않을 능력에는 돈을 내지 않는 모델. 이쪽이 더 영리한 결정일 때가 많다.

    이렇게 보면 서빙 구조는 엔지니어링 문제이면서 동시에 투자 결정이다. 정해야 할 것은 세 가지다.

    • 어디에 연산 자원을 쓸지
    • 어디를 최적화할지
    • 어느 지점부터는 모델 성능을 더 올려도 비용만큼의 가치가 없는지

    연산은 남는데 메모리가 먼저 바닥나는 이유, KV 캐시

    서빙 하네스에서 가장 먼저 이해해야 할 자원은 GPU 메모리다.

    언어 모델은 토큰을 하나씩 생성한다. 새 토큰을 만들 때마다 앞선 모든 토큰을 참고하는 어텐션 연산을 거친다. 이때 앞 토큰들의 키(key)와 값(value)을 매번 다시 계산하면 낭비가 크다. 그래서 한 번 계산한 결과를 메모리에 저장해 두고 재사용하는데, 이 저장 공간이 KV 캐시다.

    GPU 메모리를 차지하는 건 크게 두 덩어리다. 둘의 성격이 정반대라는 점이 이 글 전체의 열쇠.

    구분 모델 가중치 KV 캐시
    크기 추론 중에는 변하지 않고 고정 컨텍스트가 길수록 커짐
    누가 쓰나 한 번 올려 두면 모든 요청이 함께 씀 요청마다 따로 생김
    무엇이 쌓이나 추론 중에는 늘지 않음 입력 토큰과 이미 생성한 토큰이 모두 쌓임
    동시 요청이 늘면 그대로 전체 크기도 그만큼 늘어남

    동시 요청이 늘면 KV 캐시 전체가 불어난다. 그러다 어느 순간 연산 장치엔 여유가 있는데 쓸 수 있는 GPU 메모리가 먼저 바닥난다. 이때 서버가 할 수 있는 건 두 가지뿐이다. 새 요청을 대기열에 세우거나, 처리 중이던 요청을 밀어내거나. 사용자 쪽에선 그저 ‘느려졌다’로 보인다.

    이 병목을 모른 채 GPU만 늘리면 비효율적인 시스템을 더 비싸게 만들 뿐일 수 있다. 서두에서 GPU 추가 구매가 답이 아닐 수 있다고 한 근거가 바로 이 대목이다.

    운영 지표도 GPU 사용률 하나로는 부족하다. 함께 봐야 할 숫자는 이렇다.

    • GPU 메모리 중 KV 캐시가 차지하는 비중
    • 동시에 처리 중인 요청 수
    • 대기열 길이
    • 요청별 컨텍스트 길이 분포

    긴 컨텍스트 윈도도 같은 맥락에서 봐야 한다. 스펙표에선 매력적이지만, 긴 컨텍스트를 쓰는 요청이 많아질수록 같은 메모리로 동시에 받을 수 있는 요청 수는 줄어든다. 최대 컨텍스트를 지원한다는 것과 그걸 다 써도 괜찮다는 것은 별개의 이야기다. 이 지점을 겨냥한 선택지는 다음과 같다.

    • 워크로드별로 최대 컨텍스트 길이 제한하기
    • 프롬프트에 매번 붙는 불필요한 내용 줄이기
    • KV 캐시를 최대 길이만큼 미리 잡아 두지 않고 필요한 만큼 나눠 할당하는 서빙 엔진 고르기

    양자화·추측 디코딩은 병목을 확인한 다음 차례

    프로덕션에선 따로 떨어져 보이던 결정들이 서로 맞물려 돌아간다. 연결 고리를 따라가면 이렇다.

    서빙 구조 → 메모리 활용 → 동시성 → 배칭·스케줄링 → GPU 활용률과 지연

    서빙 구조가 메모리 쓰는 방식을 정한다. 남은 메모리가 동시에 받을 수 있는 요청 수를 정하고, 그 수가 배칭과 스케줄링 방식을 제한한다. 최종 결과는 GPU 활용률과 응답 지연으로 나타난다. 양자화, 추측 디코딩, 어텐션 최적화 같은 기법은 이 사슬이 정리된 뒤에야 제값을 한다. 기법마다 겨냥하는 지점도, 치르는 대가도 다르다.

    기법 방식과 겨냥하는 지점 조건·주의점
    양자화 가중치를 더 낮은 정밀도로 표현해 메모리 사용량과 메모리 대역폭 부담을 줄인다. 아낀 메모리는 KV 캐시에 돌릴 수 있다. 답변 품질이 떨어지지 않는지 평가가 따라와야 한다.
    추측 디코딩 작은 초안 모델이 여러 토큰을 먼저 제안하고 큰 모델이 한 번에 검증한다. 초점은 토큰 생성 지연 단축. 초안 모델도 메모리를 차지하고, 부하 상황에 따라 효과가 달라진다.
    어텐션 최적화 어텐션 연산의 메모리 접근 방식을 개선해 속도와 메모리 효율을 끌어올린다. 긴 컨텍스트에서 특히 효과가 크다.

    함정은 표의 가운데 줄에 있다. 시스템을 막고 있는 원인이 KV 캐시 메모리 부족인데 추측 디코딩부터 붙이면, 초안 모델이 메모리를 더 차지해 동시 처리량이 오히려 줄 수 있다. 지연을 줄이려고 넣은 기법이 메모리 병목을 더 조이는 꼴이다.

    기고문은 이를 두고 최적화 기법을 포켓몬 카드처럼 다 모으려 하지 말라고 썼다. 가벼운 비유지만, 위 사례를 보면 과장은 아니다. 목표는 기법 수집이 아니다. 애플리케이션의 업무 요구사항을 지키면서 가장 영향이 큰 제약을 걷어내는 것이다.

    순서는 단순하다.

    • 측정: 최적화하기 전에 먼저 잰다.
    • 병목 찾기: 가장 큰 제약을 골라낸다.
    • 해결: 그 제약을 푼다.
    • 재측정: 결과를 다시 재고, 새 병목이 생겼는지 확인한다.
    • 반복: 위 과정을 다시 돌린다.

    의사결정 질문도 바뀌어야 한다. ‘우리 조직이 어떤 AI 기능을 배포할 수 있나’가 아니다. ‘검증된 기능이 지속 가능한 비즈니스 가치가 되지 못하게 막는 제약이 무엇인가’를 물어야 투자 방향이 잡힌다.

    API만 쓰는 팀은 호출 구조, 자체 서빙 팀은 KV 캐시가 숙제

    한국에서 LLM 서비스를 만드는 팀 입장으로 옮겨 보자. 기고문 밖에서 추론한 부분이 섞여 있어서, 추정인 대목은 따로 표시했다.

    상용 API만 호출하는 팀. GPU 메모리나 배칭 같은 서빙 하네스의 핵심부는 API 제공사가 맡는다. 그렇다고 하네스와 무관한 건 아니다. 아래 항목은 여전히 우리 몫이고, 요청당 비용과 지연에 직접 영향을 준다.

    • 프롬프트 길이 관리
    • 워크로드별 모델 라우팅(간단한 요청은 가벼운 모델로 보내기)
    • 응답 캐싱
    • 모델을 갈아 끼울 수 있는 호출 구조

    사내 GPU에 공개 모델을 직접 띄우는 팀. 앞에서 본 KV 캐시, 동시성, 스케줄링 이야기가 그대로 적용된다. 금융·공공처럼 망분리 같은 보안 요건이 있는 환경은 외부 API보다 자체 서빙을 검토할 이유가 생기기 쉽다. 이런 조직일수록 모델 선정만큼 서빙 구조 검토에도 시간을 써야 할 것으로 보인다(추정).

    한국어 서비스라면 토큰 효율도 따져 볼 만하다(추정). 토크나이저에 따라 같은 뜻의 문장이 영어보다 더 많은 토큰으로 쪼개지는 경우가 있다. 토큰이 늘면 KV 캐시 크기도, API 과금도 함께 늘어난다. 모델마다 한국어를 처리하는 방식이 다르니, 후보 모델들에 실제 서비스 문장을 넣고 토큰 수를 직접 세어 보는 게 가장 확실하다.

    국내 팀도 대개 해외 팀과 같은 모델 후보군에서 고른다. 모델 선택만으로 경쟁사와 차이를 만들기는 점점 어려워질 가능성이 크다(추정). 기고문의 주장을 국내 상황에 옮기면 이런 해석이 나온다. 같은 모델로 더 싸고, 더 빠르고, 더 안정적으로 서비스하는 팀이 앞선다.

    확인된 것과 아직 불확실한 것

    확인된 것

    • 출발점이 된 기고문은 EXL이 제작한 콘텐츠로, 게재 매체의 편집국이 쓴 기사가 아니다.
    • 추론 중에 모델 가중치는 고정되어 있고, KV 캐시는 활성 요청 수와 컨텍스트 길이에 따라 커진다.
    • 동시성이 높아지면 연산 여력이 남아 있어도 쓸 수 있는 GPU 메모리가 먼저 부족해질 수 있다.
    • 서빙 구조, 메모리, 동시성, 배칭·스케줄링, GPU 활용률, 지연은 서로 연쇄적으로 영향을 준다.
    • EXL은 ‘Engineering the Harness’ 시리즈에서 서빙 구조, 메모리 관리, 스케줄링, 추론 최적화를 더 깊이 다룬다고 밝혔다.

    아직 불확실한 것

    • 하네스 설계를 바꾸면 비용이나 지연이 얼마나 줄어드는지에 대해 기고문은 구체적인 수치를 내놓지 않았다.
    • 어떤 최적화 기법이 어떤 워크로드에서 가장 효과적인지는 일반화된 답이 없고, 실측으로만 확인할 수 있다.
    • 모델 교체를 평가와 설정 변경 수준으로 만드는 게 실제로 어디까지 가능할지는 팀마다 다를 것으로 보인다. 모델마다 프롬프트 형식, 토크나이저, 컨텍스트 길이가 다르기 때문이다.
    • 하네스가 모델 선택보다 중요해진다는 주장에는 솔루션 기업의 시각이 담겨 있고, 독립적으로 검증된 결론은 아니다.

    모델 교체를 설정 변경으로 끝내는 다섯 가지 장치

    서빙 하네스에 투자할 가장 큰 이유는 선두 모델이 계속 바뀐다는 데 있다. 모델은 좋아지고, 하드웨어는 발전하고, 새 최적화 기법도 꾸준히 나온다. 기술이 바뀔 때마다 AI 플랫폼을 다시 지어야 한다면 그 비용은 매번 되풀이된다. 주변 구조가 이런 변화를 쉽게 흡수할 수 있어야 하는 이유다.

    기고문이 내놓는 기준은 세 가지다.

    • 워크로드 요구사항
    • 명확한 서비스 수준 목표(SLO)
    • 측정 가능한 프로덕션 경제성

    이 셋을 기준으로 시스템을 짜 두면 새 모델이나 인프라가 나왔을 때 업무에 실제로 필요한 것과 대조해 평가할 수 있다. 실무 체크리스트로 바꾸면 다섯 항목이 나온다.

    • 워크로드 정의서: 대화형인지 배치형인지, 허용 지연, 예상 동시 요청 수, 컨텍스트 길이 분포를 문서로 남긴다.
    • SLO 명문화: 첫 토큰까지 걸리는 시간, 전체 응답 시간, 꼬리 지연(가장 느린 일부 요청의 지연), 가용성, 요청당 비용 상한을 숫자로 정한다.
    • 모델 호출 추상화: 애플리케이션 코드가 특정 모델의 API 형식에 직접 묶이지 않도록 인터페이스를 한 겹 두고, 모델 이름과 생성 파라미터는 설정 파일로 뺀다.
    • 자체 평가 세트: 공개 벤치마크 대신 우리 업무 데이터로 만든 평가 세트를 유지하고, 새 모델을 품질·지연·비용 세 축으로 기존 모델과 비교한다.
    • 관측 지표: GPU 메모리 중 KV 캐시 비중, 동시 요청 수, 대기열 길이, 처리량, 요청당 비용을 대시보드에서 상시 확인한다.

    다섯 가지가 갖춰져 있으면 모델 교체는 아키텍처를 갈아엎는 일이 아니라 평가하고 설정을 바꾸는 일이 된다. 다만 프롬프트 형식과 토크나이저가 모델마다 다르니, 어디까지 설정 변경만으로 끝날지는 팀마다 차이가 날 것이다. 체크리스트에 자체 평가 세트가 들어간 것도 그 차이를 숫자로 확인하기 위해서다.

    기고문의 결론은 이렇다. 모델은 지능을 제공하고, 그 지능을 안정적이고 경제적인 대규모 결과물로 바꿀 수 있는지는 하네스가 결정한다. 실천으로 옮기면 한 가지로 모인다. 새 모델 소식이 나올 때마다 흔들리지 않으려면, 모델을 고르기 전에 우리 워크로드와 병목부터 숫자로 적어 둘 것.

    출처: MIT Tech Review AI

    관련 기사

  • 오픈 웨이트 모델과 폐쇄형 모델, 네 가지 선택 기준

    오픈 웨이트 모델과 폐쇄형 모델, 네 가지 선택 기준

    3줄 요약

    • 오픈 모델은 가중치를 내려받아 내 장비에서 돌리고 재학습까지 하는 모델이고, 폐쇄형 모델은 웹사이트·앱·API로만 접근해요.
    • 성능 순위 상위권은 폐쇄형이 차지하지만 격차는 몇 달 수준이라, 비용·데이터 통제·내부 관찰이 필요하면 오픈 모델이 유리해요.
    • 누구나 받아서 고친다는 특성이 장점이면서 악용 우려의 근거라서, 논쟁의 핵심은 안전과 권력 분산 사이의 저울질이에요.

    LLM 성능 리더보드 맨 위 여덟 자리. 전부 폐쇄형 모델이에요. 그런데도 연구실과 기업은 한발 뒤처진 오픈 모델을 굳이 내려받아 써요. 순위표만 놓고 보면 손해 보는 선택 같은데요, 모델을 고를 때 따지는 축이 성능 하나가 아니라서 벌어지는 일이에요. MIT 테크놀로지 리뷰가 개방성 논쟁을 풀어 쓴 해설이 이 지점을 다루는데, 읽다 보면 두 진영의 차이는 ‘어느 쪽이 더 똑똑한가’보다 ‘모델 본체가 누구 손에 있는가’에 가깝다는 게 보여요. 구조적으로 어디서 갈리는지부터 보고, 어떤 상황에서 어느 쪽을 고를지는 그다음에 따질게요.

    두 진영을 가르는 선은 가중치를 공개하느냐 하나

    폐쇄형부터요. ChatGPT나 Claude를 움직이는 모델이 여기 속하는데, 들어가는 문이 웹사이트, 앱, API 셋뿐이에요. 우리가 보내는 건 프롬프트. 돌려받는 건 응답. 그게 전부죠. 모델 본체는 제공사 쪽에 남아 있고 우리 손에는 넘어오지 않아요.

    오픈 모델은 그 본체를 직접 내려받는 모델이에요. 모델의 내부 구조에 관한 정보는 ‘가중치’라고 부르는 아주 긴 숫자열에 담겨 있는데요, 이 숫자열이 공개돼 있다는 뜻이에요. 파일을 받고 나면 그 모델은 내 장비 안에 들어와 있는 거고요.

    용어 하나는 짚고 넘어가야 해요. 가중치만 공개된 모델을 따로 ‘오픈 웨이트 모델’이라고 부르기도 하거든요. 학습 절차 같은 정보까지 더 많이 내놓은 모델과 구분하려고 쓰는 말이에요. 그러니 ‘오픈’이라는 수식어가 붙어 있으면 가중치까지만 열렸는지, 학습 과정까지 열렸는지부터 확인하는 습관을 들이는 게 좋아요. 단어는 같은데 열린 범위가 다르니까요. 이름표 하나로 뭉뚱그리면 학습 절차는 닫혀 있는 모델까지 ‘전부 공개’로 착각하게 되거든요.

    가중치가 손에 있어야 열리는 작업 네 가지

    본체가 손에 들어오면 할 일의 목록이 확 길어져요. 원문이 꼽은 내용을 실무 쪽 시선으로 다시 묶으면 이렇게 네 덩어리예요.

    • 자체 실행: 자기 컴퓨터나 하드 드라이브에 올려서 직접 돌려요.
    • 재학습: 모델이 다르게 행동하도록 다시 학습시켜요. 단, 그럴 만한 전문성과 자원이 있을 때 얘기예요.
    • 내부 관찰: 모델의 내부 동작, 그리고 답을 내기 전에 문제를 풀어 가는 ‘사고의 연쇄(chain of thought)’를 들여다봐요.
    • 조합·압축·파인튜닝: 여러 오픈 모델을 엮어 새 시스템을 만들고, 압축해서 효율을 높이고, 새 용도에 맞게 미세 조정해요.

    폐쇄형 모델 앞에서 연구자가 하는 일은 프롬프트를 보내고 응답을 관찰하는 선을 크게 넘지 못해요. AI 시스템을 이해하고 개선하려는 학계 연구자라면 거의 예외 없이 오픈 모델로 작업하게 된다는 게 원문의 설명인데요, 취향 문제가 아니에요. 연구가 목적이면 선택의 여지가 사실상 없는 셈이죠. 네 가지 가운데 재학습에만 ‘전문성과 자원’이라는 단서가 붙어 있다는 점도 눈여겨볼 만해요. 내려받는 건 누구나 하지만, 고쳐 쓰는 건 그럴 여력이 있는 팀의 몫이라는 얘기니까요.

    성능 격차는 몇 달, 고르는 순서는 질문 네 개

    성능만 떼어 놓고 보면 폐쇄형이 위예요. 해설 기사가 실린 시점 기준으로 Artificial Analysis LLM 리더보드의 상위 8개 모델이 모두 폐쇄형이었어요. 다만 오픈 모델도 개발 진도로 따지면 몇 달 정도 뒤처진 수준이라고 해요. 격차의 단위가 ‘달’이라는 얘기예요. 순위표는 계속 바뀌는 물건이라 이 숫자를 외워 봐야 소용이 없고, 모델을 고르는 그 시점에 리더보드를 직접 열어 보는 쪽이 맞아요.

    비용은 방향이 반대예요. Mozilla가 낸 보고서는 실행을 외부 제공업체에 맡기는 경우에도 오픈 모델이 일반적으로 폐쇄형보다 싸다고 봤어요. ‘오픈 모델은 장비를 직접 사야 하니까 오히려 비싸지 않나’ 하고 헷갈리기 쉬운데요, 직접 돌리는 길과 남에게 맡기는 길이 따로 있고, 후자에서도 비용 우위가 나온다는 얘기예요. 얼마나 싼지 수치까지는 이 글이 참고한 범위에서 확인하지 못했어요. ‘일반적으로’라는 단서가 달린 결론으로만 받아들이는 게 맞겠죠.

    항목 폐쇄형 모델 오픈 모델
    접근 방식 웹사이트·앱·API 가중치 직접 다운로드
    실행 위치 제공사 쪽 자기 컴퓨터·자체 하드웨어, 또는 외부 제공업체
    성능 리더보드 상위 8개 모두 차지 개발 진도로 몇 달가량 뒤처짐
    비용 일반적으로 더 비쌈 외부 제공업체에 맡겨도 일반적으로 더 쌈
    내부 관찰·수정 프롬프트 전송과 응답 관찰 정도 내부 동작·사고의 연쇄 관찰, 재학습·압축·조합·파인튜닝

    고르는 법으로 넘어갈게요. 특정 모델 이름부터 검색하지 말고 기준을 먼저 세우는 게 순서예요. 아래 네 가지를 위에서부터 물어보면 대부분 답이 나와요.

    1. 최상위 성능이 꼭 필요한 작업인가. 그렇다면 폐쇄형이 우선이에요. 몇 달의 격차를 감수해도 되는 작업이라면 다음 질문으로 넘어가요.
    2. 데이터가 회사 밖으로 나가면 곤란한가. 민감한 데이터나 독점 정보를 AI로 처리하려는 기업에는 자체 하드웨어에서 로컬 모델을 돌리는 구성이 운영을 안전하게 지키는 최선의 방법일지 모른다고 원문은 짚어요.
    3. 모델 안을 들여다보거나 고쳐야 하는가. 내부 관찰, 재학습, 압축, 파인튜닝이 필요하면 오픈 모델 말고는 길이 없어요.
    4. 비용이 가장 큰 제약인가. 오픈 모델을 외부 제공업체를 통해 쓰는 방식이 후보에 올라요.

    네 질문 가운데 답이 하나로 딱 정해지는 건 3번뿐이에요. 나머지는 ‘우선’이나 ‘후보’ 수준이라 팀 사정에 따라 저울질이 남아요.

    전제 조건을 빼먹으면 안 돼요. 로컬 실행에는 모델을 올릴 자체 하드웨어가, 재학습에는 전문성과 자원이 들어가요. 팀에 그 여력이 없는데 ‘오픈이니까 공짜’라는 생각으로 덤비면 일정이 무너지기 쉬워요. 내려받는 것과 돌리고 고치는 것은 별개의 비용이니까요. 필요한 사양은 모델마다 다르니 받으려는 모델의 배포 문서에서 확인하세요.

    누구나 받아서 고친다는 장점이 그대로 위험 논거가 된다

    앞에서 장점으로 꼽은 바로 그 특성이 우려의 출발점이에요. Anthropic은 중국 기업 Z.ai가 내놓은 GLM-5.3이 큰 사이버 공격 위험을 제기한다고 주장하는 보고서를 냈는데요, 핵심 우려는 이 강력한 모델을 누구든 자유롭게 내려받아 수정한다는 점이었어요. 강력한 모델이라는 점에, 아무나 손댄다는 배포 방식이 겹친 게 문제로 지목된 거죠. 진영은 둘로 갈려요. AI 안전을 걱정하는 쪽은 오픈 모델이 악의적인 행위자에게 쉽게 오용된다고 경고해요. AI의 실용적 잠재력에 무게를 두는 쪽은 이런 힘이 소수 대기업의 닫힌 문 뒤에만 있어서는 안 된다고 맞서고요.

    이 논쟁을 읽을 때는 말하는 사람이 어디에 서 있는지를 같이 봐야 해요. Nvidia CEO 젠슨 황은 미국이 오픈 모델을 더 많이 개발해야 한다고 적극적으로 주장하는데, 사람들이 오픈 모델을 돌리려고 하드웨어를 계속 사면 이득을 보는 자리에 있어요. Anthropic의 다리오 아모데이는 더 신중한 접근을 주장하고요. 이쪽은 싸고 강력한 모델이 퍼지면 사업이 흔들릴 만한 회사를 이끌어요. GLM-5.3 보고서를 낸 곳이 바로 그 Anthropic이라는 점도 같이 기억해 둘 만하죠. 그렇다고 양쪽 주장이 장삿속뿐이라는 뜻은 아니에요. 원문도 상업적 동기 밑에 실질적인 견해 차이가 깔려 있다고 봐요. 텍사스대 오스틴 정보대학원의 데이비드 그레이 위더 조교수는 개방성 논쟁에서 어느 편에 서느냐가 AI 자체를 어떻게 보느냐에 크게 좌우된다고 말해요.

    한국 팀에는 사내 실행이라는 카드와 미국 의존 문제가 걸려 있다

    한국에서 일하는 팀 입장에서 달라지는 건 크게 두 가지예요. 하나는 데이터 통제권. 고객 정보나 사내 기밀처럼 외부로 보내기 부담스러운 데이터를 다루는 팀이라면, 가중치를 받아 사내 장비에서 돌리는 구성이 선택지에 들어와요. API 호출만 되는 폐쇄형에서는 애초에 없던 카드죠.

    다른 하나는 의존도예요. 원문은 세계에서 가장 정교한 해킹 모델이 모두 미국에서 만들어지고, 다른 나라가 그 모델을 자국 사이버 방어에 쓰게 될지는 전적으로 미국 기업과 미국 정부에 달려 있다고 짚어요. 한국도 여기서 말하는 ‘다른 나라’ 쪽이에요. 강력한 오픈 모델은 이 균형을 바꿀 변수로 거론돼요. 같은 ‘강력한 오픈 모델’이 앞 섹션에서는 사이버 공격 위험으로, 여기서는 의존을 줄일 변수로 등장한다는 점이 이 논쟁의 까다로운 부분이에요.

    여기부터는 추측이에요. 한국어 사내 문서나 특정 업종 데이터에 맞춘 파인튜닝은 가중치가 있어야 가능한 작업이라서, 국내 팀이 체감하는 차이는 이 지점에서 가장 클 것으로 보여요. 반대 방향의 부담도 있어요. 로컬에서 돌리는 모델은 제공사가 중간에서 걸러 주는 구조가 아니거든요. 오용 방지와 보안 점검의 책임이 가져다 쓰는 팀으로 넘어온다고 보는 편이 안전해요.

    확인된 것과 아직 불확실한 것

    확인된 것

    • 폐쇄형 모델은 웹사이트·앱·API로만 접근하고, 오픈 모델은 가중치를 직접 내려받아요.
    • 해설 기사 게재 시점 기준 Artificial Analysis LLM 리더보드 상위 8개 모델은 모두 폐쇄형이고, 오픈 모델은 몇 달가량 뒤처져 있어요.
    • Mozilla 보고서는 외부 제공업체에 실행을 맡겨도 오픈 모델이 일반적으로 더 싸다고 봤어요.
    • Anthropic은 GLM-5.3의 사이버 공격 위험을 주장하는 보고서를 냈어요.

    아직 불확실한 것

    • 오픈 모델이 폐쇄형보다 실제로 얼마나 더 위험한지. 이 글이 참고한 범위에서는 위험 쪽 근거를 구체적으로 확인하지 못했어요.
    • 몇 달 수준인 성능 격차가 유지될지, 좁혀질지.
    • 각국 정부와 사회가 전면 금지와 무제한 공개 사이 어디쯤에 선을 그을지.
    • 커뮤니티가 만든 개선에 크레딧과 보상이 돌아가는 구조가 자리 잡을지.

    개방이 권력은 나눠도 보상까지 나눠 주진 않는다

    오픈 모델을 지지하는 가장 큰 논거는 성능도 비용도 아니에요. 통제권이에요. 토니 블레어 글로벌 변화 연구소의 선임 정책 고문 엘리자베스 시거는 권력이 대규모로 집중되는 일을 막고 이 기반 기술을 공공재로 만드는 것이 가장 분명한 논거라고 말해요. AI를 돌리는 인프라를 누가 쥐느냐가 인터넷의 정보를 누가 통제하느냐만큼 큰 질문이 됐다는 거죠. 장기 회복력 센터(Centre for Long-Term Resilience)의 AI 정책 책임자 해미시 홉스도 비슷한 쪽이에요. 각 개인이 자신에게 충실하고 안전한 AI 시스템을 갖는 세계가, 정부가 속을 알 길 없는 초지능 시스템을 두고 그냥 믿으라고 하는 세계보다 훨씬 덜 걱정스럽다고 봐요.

    반론도 묵직해요. 가나의 저자원 언어용 오픈 소스 AI 도구를 만드는 Ghana NLP의 공동 창립자 폴 아준레는, 오픈 모델이 형편이 덜 넉넉한 나라의 노동과 전문성으로 기업이 이득을 보고 힘을 더 모으는 통로로도 쓰인다고 지적해요. 패턴은 이래요. 회사가 모델을 공개하고, 커뮤니티가 어떻게 쓰고 고치는지 지켜본 다음, 그 개선을 원작자에 대한 크레딧이나 보상 없이 자사 제품에 흡수하는 거예요. 마크 저커버그도 커뮤니티의 개선을 Meta의 스택에 통합하는 능력을 오픈 모델 공개의 핵심 이점으로 꼽은 적이 있어요. 공개하는 쪽이 스스로 밝힌 이점과 아준레가 비판하는 지점이 같은 곳을 가리키는 셈이죠. 아준레의 표현을 빌리면 오픈 소스의 이상은 고귀하고 가치도 크지만, 실제 구현 방식은 매우 추출적인 쪽으로 기울어요.

    ‘오픈이 선이고 폐쇄가 악’ 같은 구도로 외우면 틀려요. 전면 금지와 무제한 공개 사이에는 여러 선택지가 있고, 어느 쪽을 택하든 안전과 민주화 사이에서 무언가를 내주게 돼요. 실무에서 챙길 건 두 가지로 줄어요. 모델을 고를 때는 성능·데이터·수정 필요성·비용을 차례로 따지기. 논쟁 기사를 읽을 때는 누가 어떤 이해관계로 말하는지 함께 보기. 순위표는 계속 바뀌는 물건이지만, 이 두 가지는 순위가 뒤집혀도 그대로 쓰는 기준이에요.

    출처: MIT Tech Review AI

    관련 기사

  • LLM 추론엔 알파고 37수의 탐색 장치가 없다

    LLM 추론엔 알파고 37수의 탐색 장치가 없다

    3줄 요약

    • 알파고의 37수는 정책망의 직관이 아니라 수천 갈래 게임 트리를 따져 본 탐색이 골랐어요.
    • LLM의 사고 사슬은 별도 추론 장치가 아니라 다음 토큰 예측을 더 길게 반복한 것이라, 화면에 보이는 풀이가 실제 경로와 다를 때가 있어요.
    • 챗봇의 풀이 과정은 감사 기록이 아닌 초안으로 다루고, 가정·근거·미해결 질문을 따로 받아 직접 검증하는 습관이 필요해요.

    대략 1만 분의 1. 알파고 안에서 직관을 맡은 정책망이, 전문 기사가 그 자리에 돌을 놓을 확률로 매긴 값이에요. 그 자리가 바로 37수예요. 기계의 직관이 번뜩인 장면으로 흔히 소개되는 수인데, 정작 직관 담당은 그 수를 별것 아닌 수로 넘겼던 셈이죠.

    장면부터 다시 떠올려 볼게요. 서울에서 열린 알파고와 이세돌의 5번기, 두 번째 판. 알파고가 5선에 돌을 놓자 일부 해설자는 프로그램 오류부터 의심했어요. 상대에게 그냥 내주는 수처럼 보였거든요. 그 판은 알파고가 이겼고 대국 전체는 4대 1로 끝났어요. 이세돌은 알파고를 확률 계산에 기반한 기계로만 여겼는데, 이 수를 보고 생각이 바뀌었다고 했죠. 알파고는 창의적이라는 말까지 남겼고요.

    알파고 개발에 참여했던 한 연구자가 MIT 테크놀로지 리뷰에 실은 기고문은 ‘기계 직관’이라는 해석을 오해라고 짚어요. 37수를 만든 건 직관이 아니라 추론 장치였고, LLM 기반 챗봇에는 바로 그 장치가 빠져 있다는 주장이에요. 챗봇이 화면에 띄워 주는 ‘생각 과정’을 어디까지 믿어야 할지 헷갈렸던 사람이라면, 이 구분 하나만 잡아 둬도 판단이 꽤 쉬워져요.

    37수를 끌어올린 건 직관이 아니라 탐색이었다

    알파고는 두 부분으로 이뤄져 있어요. 하나는 정책망(policy network). 강한 인간 기사가 어디에 둘지 맞히도록 학습된, 말하자면 직관 담당이에요. 앞에서 본 1만 분의 1이라는 숫자가 여기서 나왔어요. 전문 기사가 그 자리에 둘 확률을 그 정도로 낮게 평가했으니, 직관만 따랐다면 37수는 판 위에 놓이지 않았을 거예요.

    나머지 하나가 탐색 장치인데요. 당장 그럴듯해 보이는지에서 멈추지 않고, 후보 수를 뒀을 때 그 뒤에 벌어질 일을 저울질하는 부분이에요. 알파고는 수천 개의 가지를 가진 게임 트리를 명시적으로 만들어 탐색했어요. 가지 하나하나가 서로 다른 미래였고요. 37수를 끌어올린 건 이쪽이에요.

    대니얼 카너먼이 널리 알린 구분에 대입하면 이해가 빨라요. 시스템 1은 빠르고 직감적이며 힘이 들지 않는 사고, 시스템 2는 느리고 단계적이며 숙고하는 사고. 알파고에서는 신경망이 “이 수가 유망해 보인다, 이 국면은 이긴 것 같다”는 감을 내놓고, 탐색이 그 감을 이어질 수와 응수에 비춰 시험했어요. 한쪽만으로는 안 됐을 거예요. 직관만으로는 37수를 고르지 못했을 테고, 힘으로 밀어붙이는 탐색만으로는 그 많은 후보를 걸러내기 벅찼을 테니까요.

    체스의 딥블루, 그리고 LLM 챗봇까지 한 표에 나란히 놓으면 구조 차이가 한눈에 들어와요. 답을 고르는 방식, 숙고의 규모, 검토한 내용을 남기는지. 이 세 줄만 따라가도 충분해요.

    구분 딥블루 알파고 LLM 챗봇
    답을 고르는 방식 사람이 하드코딩한 규칙으로 포지션 평가 정책망이 후보를 내고 탐색이 미래 결과를 검증 다음 토큰을 반복해서 선택
    숙고의 규모 선수당 6~8수 앞, 초당 2억 개 포지션 평가 수천 개 가지의 게임 트리를 명시적으로 구성 사고 사슬을 쓰면 같은 예측을 더 길게 반복
    검토 내용의 기록 기고문에서 따로 다루지 않음 게임 트리에 변화와 신경망 판단을 남기고 계속 갱신 명시적이고 지속되며 들여다볼 수 있는 인식 상태가 대체로 없음

    딥블루의 ‘검토 내용의 기록’ 칸은 원문이 그 대목을 설명하지 않아서 저렇게 적었어요. 딥블루가 기록을 남기지 않았다는 뜻으로 읽으면 곤란해요.

    바둑에 딥블루 방식이 통하지 않는 이유도 이 표 언저리에서 나와요. 돌 하나의 가치는 멀리 떨어진 돌 무리와 집이 수십 수에 걸쳐 어떻게 전개되느냐에 달려 있는데, 가능한 결과의 일부만 계산하려 해도 슈퍼컴퓨터로 수십억 년이 걸리거든요. 계산량으로 밀어붙일 규모가 아닌 거죠. 알파고가 누가 앞서는지 한눈에 감 잡는 능력과, 그 감을 검증하는 탐색을 같이 가져야 했던 이유예요.

    사고 사슬은 같은 예측을 더 오래 돌린 결과다

    LLM이 하는 일은 단순해요. 다음 토큰을 고르고, 또 고르는 것. 기고문은 이걸 시스템 1이 작동하는 모습으로 봐요. 빠르고 연상적이며, 사람이 글로 남기는 거의 모든 주제에서 놀랄 만큼 잘 맞는 패턴 완성이라는 거죠.

    ChatGPT가 등장하고 얼마 지나지 않아 업계는 말이 유창한 것만으로는 쓸모가 모자란다는 걸 알아챘어요. 거기서 나온 해법이 곧바로 답하지 않고 중간 단계를 먼저 쓰게 하는 방식이에요. 문제를 쪼개고, 부분 결과를 다음 단계로 넘기고, 그 결과가 뒤따르는 풀이에 영향을 주게 하는 식이죠. 사고 사슬(chain of thought)이라고 부르는 과정이에요.

    효과가 없다는 얘기는 아니에요. 수학과 코딩에서 성과가 뚜렷했거든요. 다만 알파고의 탐색처럼 따로 떨어진 추론 장치가 생긴 건 아니에요. 중간 풀이도 똑같은 다음 토큰 예측이 만들어 내고, 답을 확정하기 전에 그 과정을 더 오래 돌릴 뿐. 개발자 감각으로 비유하면 검증용 모듈을 새로 붙인 게 아니라 같은 함수를 더 여러 번 호출한 셈이에요. 성과가 좋다는 것과 구조가 그대로라는 건 서로 부딪치는 말이 아니고, 기고문이 문제 삼는 건 구조 쪽이에요.

    챗봇의 풀이 과정을 추론이라 부르기 어려운 세 가지 이유

    기고문은 챗봇이 하는 일이 과학자가 인정할 만한 의미의 추론에 못 미친다고 보고, 이유를 세 가지 들어요.

    1. 들여다볼 장부가 없다. 어떤 가설을 검토 중인지, 각 설명을 얼마나 믿는지, 어떤 증거를 저울질하는지, 어떤 질문이 아직 안 풀렸는지. 이런 걸 적어 둔 공개 장부가 없어요. 새 정보가 들어오면 체계적으로 고쳐 써야 할 내용인데, 모델은 보통 이런 명시적이고 지속적인 상태를 유지하지 않아요.
    2. 아는 것과 다루는 방식이 한 덩어리다. 지식과 추론이 신경망 가중치 안에 뒤엉켜 있어요. 따로 꺼내 볼 독립된 믿음의 목록이 없다는 뜻이에요.
    3. 보여 주는 풀이가 실제 경로와 다를 때가 있다. 사고 사슬은 숙고처럼 보이지만, 한 경로로 답에 도달해 놓고 다른 경로를 보고하는 식으로 사후에 지어내는 일이 잦다는 연구 결과가 있어요.

    셋 중에 일하면서 바로 걸리는 건 세 번째라고 봐요. 앞의 둘은 모델 내부 구조 얘기지만, 세 번째는 지금 화면에 떠 있는 단계별 풀이를 믿어도 되느냐는 문제니까요.

    의료·공학·과학 연구처럼 판돈이 큰 분야에서는 결론만큼이나 그 결론에 이른 과정이 중요해요. 진단이나 치료에서 실수가 나오면 어디가 틀렸는지 짚어야 하잖아요. 추론이 잘못됐는지, 근거로 삼은 증거가 무효였는지, 가정이 틀렸는지. 로그가 실제 실행 경로와 다르게 찍히는 서비스에서 장애 원인을 찾는 상황을 떠올리면 감이 올 거예요. 로그를 아무리 꼼꼼히 읽어도 원인에 닿기 어려운 구조인 거죠.

    게임 트리를 본뜬 ‘인식 상태’ 장부라는 대안

    기고자는 구글 딥마인드를 떠났어요. 이유로 든 건 알파고의 구조에서 출발하는 새로운 기계 추론 접근이 필요하다는 점이에요. 알파고는 한 국면에 대해 아는 내용을 게임 트리라는 기록으로 유지하거든요. 이 자료구조에는 검토한 변화, 즉 가능한 미래가 전부 담기고 수와 국면마다 신경망의 판단이 주석처럼 붙어요. 추론이 진행되면 트리를 갱신하고, 마지막에 그 정보를 종합해 둘 수를 정하죠.

    일반적인 추론에도 같은 뼈대를 쓰자는 게 제안의 핵심이에요. 시스템이 확정으로 보는 것, 의심하는 것, 배제한 것, 열어 둔 질문을 담은 인식 상태(epistemic state)를 유지하자는 거죠. 이렇게 되면 추론은 그 상태를 바꿔 가는 수의 연속이 돼요. 귀결을 연역하는 것도, 문제를 부분으로 나누는 것도, 다음에 어떤 질문을 던지고 어떤 계산이나 실험을 할지 정하는 것도 전부 한 수.

    쉬운 일이라고 포장하지는 않아요. 열린 세계에서의 추론은 바둑이나 체스보다 어렵다고 기고자 스스로 인정하거든요. 현재 상황은 일부만 알려져 있고, 가능한 행동은 많은 데다 수시로 바뀌며, 행동의 결과는 확률적이거나 아예 알 수 없으니까요. 그런데도 도전할 여건이 생겼다고 보는 근거는 LLM과 다른 신경망 모델의 발전이에요. LLM은 알려진 사실과 쓸 수 있는 자원을 바탕으로 문제 접근법을 제안하고, API나 코드로 도구를 다루고, 어떤 주장이 증거로 뒷받침되는지 평가하는 일을 도와요. LLM을 버리자는 얘기가 아니에요. 직관 부품으로 쓰고 그 위에 장부와 검증을 얹자는 그림으로 읽혀요. 알파고에서 정책망과 탐색이 나눠 맡았던 역할을 그대로 옮겨 놓은 구도죠.

    챗봇을 업무에 쓰는 한국 사용자가 바꿔야 할 검증 습관

    새 제품 소식이 아니라서 당장 설치하거나 바꿀 설정은 없어요. 달라지는 건 챗봇 출력을 대하는 방식 하나. 그 대국이 서울에서 열렸던 만큼 한국 사용자에게는 ‘기계가 직관을 가졌다’는 인상이 강하게 남아 있을 텐데요, 그 인상을 챗봇에 그대로 옮기면 곤란해요.

    • 풀이 과정을 감사 기록으로 쓰지 않기. 화면에 보이는 단계별 설명은 모델이 실제로 밟은 경로와 다를 때가 있어요. 보고서나 결재 문서에 “AI가 이런 과정으로 판단했다”고 옮겨 적는 건 피하는 게 좋아요.
    • 수학·코드는 결과를 직접 돌려 보기. 사고 사슬의 성과가 뚜렷한 영역이긴 해요. 그래도 맞는지 확인하는 수단은 풀이의 그럴듯함이 아니라 재계산과 실행이에요.
    • 장부를 사람이 대신 만들기. 답과 별개로 전제한 가정, 근거로 쓴 자료, 아직 확인하지 못한 질문을 항목별로 나눠 달라고 요청하고, 그 목록을 하나씩 직접 확인해요. 모델 안에 장부가 없으니 바깥에 두는 거죠. 주의할 점 하나. 이렇게 받은 목록도 같은 방식으로 생성된 글이라, 확인을 끝낸 뒤에야 믿을 근거가 생겨요.

    의료나 설계처럼 책임 소재가 걸린 업무에서는 결론보다 과정 기록을 먼저 요구하는 쪽으로 기준이 움직일 것으로 보여요. 근거라고 해 봐야 기고문이 고위험 분야를 콕 집어 문제 삼았다는 점 하나라서, 여기서부터는 내 추측이에요.

    확인된 것과 아직 불확실한 것

    확인된 사실

    • 알파고의 정책망은 37수를 전문 기사가 둘 확률이 약 1만 분의 1인 수로 평가했고, 그 수를 고른 건 게임 트리 탐색이었어요.
    • 딥블루는 선수당 6~8수 앞을 내다보며 초당 2억 개의 포지션을 평가했고, 규칙은 사람이 하드코딩했어요.
    • 사고 사슬은 수학과 코딩에서 실제 성과를 냈지만, 만들어지는 방식은 다음 토큰 예측의 반복이에요.
    • 챗봇이 보고하는 풀이가 실제로 답에 도달한 경로와 다른 경우가 많다는 연구 결과가 있어요.

    아직 불확실한 것

    • 인식 상태를 유지하는 시스템이 바둑판 바깥의 열린 문제에서도 제대로 작동할지는 검증되지 않았어요.
    • 기고문은 시스템을 정직하게 유지하려면 독립된 부분이 필요하다고 언급하는데, 그 부분이 구체적으로 어떻게 설계되는지는 확인하지 못했어요.
    • “LLM은 추론하지 않는다”는 말은 한 연구자의 주장이에요. ‘추론’을 어떻게 정의하느냐에 따라 결론이 달라지는 문제라 학계 전체의 합의로 읽으면 안 돼요.
    • 이 접근이 언제 어떤 형태의 결과물로 나올지도 알려진 바가 없어요.

    그럴듯한 풀이를 만났을 때 던질 세 가지 질문

    기고문이 오류의 원인으로 꼽은 갈래는 추론, 증거, 가정 세 가지였어요. 순서만 뒤집으면 그대로 점검표가 돼요.

    1. 깔고 있는 가정이 무엇인가. 답이 전제한 조건이 내 상황과 맞는지부터 봐요. 버전, 환경, 대상 범위 같은 전제가 어긋나 있으면 뒤의 풀이가 아무리 매끄러워도 소용없거든요.
    2. 근거가 확인 가능한가. 인용한 수치나 문서가 실제로 존재하는지, 내가 직접 열어 볼 수 있는지 확인해요.
    3. 단계 사이의 연결이 맞는가. 가정과 근거가 옳아도 중간 계산이 틀릴 수 있어요. 핵심 단계 하나는 손으로 다시 따라가 봐요.

    37수는 양쪽으로 읽혀요. 그럴듯해 보이지 않던 수가 탐색을 거치니 승리로 이어지는 수였고, 반대로 그럴듯해 보이는 풀이가 검증을 거치면 틀린 것으로 드러나기도 해요. 판단 기준을 ‘그럴듯함’에서 ‘검증을 통과했는가’로 옮겨 두면, 챗봇이 어떤 구조로 바뀌든 같은 습관을 계속 쓰게 될 거예요.

    출처: MIT Tech Review AI

    관련 기사

  • LLM은 추론하지 않는다, 알파고 개발자의 주장

    LLM은 추론하지 않는다, 알파고 개발자의 주장

    3줄 요약

    • 알파고 팀 핵심 멤버였던 토레 그레펠은 지금의 LLM이 추론하지 않는다고 주장하며, 알파고 구조에서 출발하는 새 접근이 필요하다고 봅니다.
    • LLM은 이어 쓰기에 강하고, 알파고식 시스템은 여러 경로를 미리 따져 보고 고르는 데 강합니다. ‘추론’이라는 한 단어가 이 둘을 섞어 부르면서 혼동이 생겨요.
    • 사용자에게는 단어 논쟁보다, 답을 다시 확인할 수 있는 형태로 받아내는 습관이 더 실용적입니다.

    해설자들이 프로그램 오류부터 의심한 수가 있었습니다. 알파고가 이세돌과 맞붙은 대국에서 나온 수인데요. 사람 눈에는 버그로 보일 만큼 낯설었고, 그 선택 뒤에 알파고는 승리를 가져갔죠. 알파고를 함께 만든 연구자 토레 그레펠은 이 장면을 추론 능력이 만들어 낸 창의적 선택으로 설명합니다. 거기서 한 걸음 더 나가요. 지금 널리 쓰이는 LLM에는 그 능력이 없다는 주장.

    챗봇 화면에서 ‘추론 중’이라는 문구를 자주 보는 입장에서는 고개가 갸웃해지는 얘기거든요. 화면에는 분명 추론한다고 적혀 있는데, 알파고를 만든 사람은 아니라고 하니까요. 그의 주장을 옮기는 데서 멈출 생각은 없습니다. 추론이라는 한 단어가 가리키는 서로 다른 두 동작을 먼저 나눠 보고, 챗봇 답변을 어디까지 믿고 어떻게 확인하면 좋은지까지 풀어 봅니다.

    버그로 오해받은 한 수가 추론의 사례로 불리는 이유

    그레펠은 유니버시티 칼리지 런던에서 머신러닝 석좌교수를 맡고 있고, 딥마인드 알파고 팀의 핵심 멤버였던 사람이에요. 그가 MIT 테크놀로지 리뷰에 의견 기고를 실었는데요, 요지는 두 가지입니다. 알파고의 낯선 수를 만든 것은 추론의 힘이었다. 그 힘이 지금의 AI에는 빠져 있다. 구글 딥마인드를 떠난 이유도 여기에 있다고 밝혔어요. 기계 추론에는 알파고의 구조에서 출발하는 새로운 접근이 필요하다는 게 그의 믿음입니다.

    글의 성격부터 짚고 가야 합니다. 연구 결과 발표가 아니에요. 의견 기고입니다. 알파고를 직접 만든 사람의 말이라 무게가 실리는 건 맞지만, 학계 전체가 합의한 결론처럼 읽으면 곤란해요. 당사자가 던진 문제 제기, 딱 그 정도로 받아들이는 편이 안전합니다.

    해설자들이 오류로 볼 만큼 낯설었다는 대목은 곱씹어 볼 만해요. 사람이 둔 기보에서 흔히 보이던 모양을 따라 한 수였다면 그런 반응이 나오기 어려웠을 테니까요. 익숙한 패턴 바깥에서 더 나은 수를 찾아냈다는 것. 그레펠이 말하는 추론의 핵심은 여기에 있는 것으로 보입니다. 다만 이건 그의 설명을 바탕으로 읽어 낸 해석이지, 그가 추론을 그렇게 정의했다는 얘기는 아니에요.

    이어 쓰기와 수읽기, 답을 만드는 길이 다르다

    LLM이 답을 만드는 방식은 보통 이렇게 설명됩니다. 앞에 놓인 문맥을 보고 그다음에 올 말을 예측해서 한 조각씩 이어 붙인다. 엄청난 양의 글에서 익힌 패턴이 바탕이라 문장이 매끄럽고, 자주 등장하는 유형의 문제에는 꽤 정확한 답이 나와요.

    알파고 같은 시스템은 길이 다릅니다. 지금 둘 만한 후보를 여러 갈래로 펼치고, 몇 수 앞까지 미리 두어 본 다음, 각 갈래가 얼마나 유리한지 평가해서 하나를 고르죠. 바둑에서 말하는 수읽기와 닮았습니다. 놓치기 쉬운 배경이 하나 있는데요, 바둑은 규칙과 승패가 분명합니다. 이 길이 좋은지 나쁜지를 따질 기준이 처음부터 있다는 뜻이에요.

    한쪽은 그럴듯하게 이어지는 말을 내놓고, 다른 쪽은 따져 본 결과를 내놓는 셈입니다. 그런데 겉으로는 똑같이 ‘똑똑한 답’처럼 보여요. 같은 단어로 묶이기 쉬운 이유가 여기 있고, 혼동도 여기서 생깁니다. 그레펠의 주장과 일반적인 설명을 한 표에 모으면 아래와 같아요.

    구분 알파고 지금의 LLM
    그레펠의 평가 추론 능력이 창의적 선택을 만들었다 진짜 추론을 하지 않는다
    언급된 장면 해설자가 프로그램 오류로 의심한 낯선 수, 이후 이세돌에게 승리 원문 요약에 구체 사례 없음
    답을 만드는 방식(일반적으로 알려진 설명) 후보 수를 미리 펼쳐 보고 평가해 선택 앞 문맥에 이어질 말을 예측해 생성
    그레펠이 보는 위치 새 접근이 참고할 구조 새 접근이 필요한 대상

    표를 볼 때 구분할 게 있습니다. 세 번째 줄은 그레펠의 발언이 아니라 널리 알려진 개념 설명이에요. 그리고 가장 궁금한 대목, 그러니까 그가 알파고 구조 가운데 어떤 요소를 어떻게 가져오려는지는 참고한 원문 요약에 나와 있지 않습니다. 주장의 방향은 분명한데 방법은 비어 있는 상태라, 지금 단계에서 그의 접근이 맞다 틀리다를 가리기는 이릅니다.

    화면에 뜨는 ‘추론 중’ 표시가 보여 주는 것

    여러 챗봇이 답하기 전에 더 오래 생각하는 모드를 제공합니다. 그 과정을 글로 펼쳐 보여 주기도 하고요. 문제를 단계로 쪼개서 차례로 써 내려가게 하면 한 번에 답을 내놓을 때보다 정확해지는 경우가 많다고 알려져 있어요.

    이 기능을 추론이라 불러도 되느냐. 시각이 갈립니다. 비판하는 쪽은 중간 풀이도 결국 이어 쓴 글이어서, 단계 하나하나가 따로 검증된 건 아니라고 봐요. 반대쪽 논리는 이렇습니다. 단계를 나눠 쓰는 것만으로 풀리는 문제가 늘어난다면 실용적으로는 추론이라 불러도 무리가 없다. 그레펠이 이런 모드를 직접 겨냥해 비판했는지는 원문 요약만으로는 알기 어렵습니다.

    사용자가 기억해 둘 건 단순합니다. 풀이가 길고 논리 정연해 보인다고 해서 그게 정답의 증거는 아니에요. 대신 풀이가 눈에 보이면 한 줄씩 따라가면서 어긋난 곳을 찾기는 훨씬 쉬워지거든요. 중간 과정은 믿을 근거가 아니라 검토할 재료. 이렇게 놓고 쓰는 편이 맞습니다.

    그럴듯한 답과 따져 본 답을 가르는 확인 습관

    모든 답을 일일이 검증할 수는 없으니, 확인에 얼마나 공을 들일지부터 정해야 합니다. 기준은 세 가지예요. 틀렸을 때 치르는 비용이 큰가. 답을 다른 방법으로 다시 계산하거나 대조해 볼 길이 있는가. 흔치 않은 조건이 섞여 있는가. 셋 중 하나라도 해당하면 아래 습관을 붙여 보세요.

    • 숫자는 따로 돌려 본다. 금액, 날짜, 비율 계산은 계산기나 스프레드시트로 한 번 더 확인합니다. 챗봇에 코드 실행 기능이 있다면 계산을 코드로 처리하게 시키는 것도 방법이에요.
    • 조건을 살짝 바꿔 다시 묻는다. 숫자나 이름만 바꿨는데 논리가 흔들린다면, 문제를 따져 본 게 아니라 익숙한 유형에 맞춰 답했을 가능성이 큽니다.
    • 단계별 근거를 쓰게 한다. 각 단계가 바로 앞 단계에서 따라 나오는지만 봐도 건너뛴 부분이 드러나요.
    • 반대 결론을 요구한다. ‘이 결론이 틀렸다면 어느 단계에서 틀렸겠느냐’고 물으면 약한 고리가 먼저 나옵니다.
    • 출처는 원문과 대조한다. 인용문과 수치는 출처를 받아서 직접 열어 봅니다.

    맡기기 좋은 일과 조심할 일도 여기서 갈립니다. 초안 쓰기, 요약, 문체 바꾸기, 아이디어 넓히기는 이어 쓰기의 강점이 그대로 살아나는 영역이에요. 여러 제약을 동시에 만족해야 하는 일정 짜기, 경우의 수 따지기, 규정을 낯선 상황에 적용하는 일은 사정이 다릅니다. 한 군데만 어긋나도 전체가 틀어지거든요. 이런 일에는 사람의 검토를 끼워 넣는 편이 안전합니다.

    챗봇이 직접 파일을 고치거나 명령을 실행하는 에이전트로 쓰일 때는 확인할 대상이 하나 더 늘어요. 튜링상 수상자 얀 르쿤이 AI 에이전트가 통제를 벗어났다는 사례들을 두고 한 말이 있습니다. 에이전트는 시킨 일을 그대로 했을 뿐이고, 원래 갇혀 있어야 할 샌드박스가 새는 데다 설계가 형편없었다는 취지였어요. 추론 논쟁과는 별개의 사안입니다. 그래도 방향은 통해요. 모델이 얼마나 똑똑한지보다 사람이 쳐 둔 울타리와 권한 범위가 결과를 좌우한다는 얘기니까요.

    한국어로 챗봇을 쓰는 사람에게 바뀌는 것은 화면이 아니라 기대치

    이 논쟁 때문에 쓰던 서비스의 화면이나 기능이 달라지지는 않습니다. 바뀌는 건 ‘추론’이라는 라벨을 읽는 눈이에요.

    이세돌 대국을 지켜본 기억이 있다면 바둑 용어로 옮겨 보는 게 가장 쉽습니다. 정석을 많이 외운 것과 수읽기를 하는 것은 다르잖아요. 정석만으로도 초반은 훌륭하게 둘 수 있죠. 처음 보는 모양이 나오면 얘기가 달라집니다. 직접 읽어야 해요. 지금의 LLM을 정석에 아주 밝은 상대로, 알파고식 시스템을 수읽기까지 하는 상대로 놓고 보면 그레펠의 문제 제기가 어디를 향하는지 감이 옵니다. 물론 이해를 돕자고 끌어온 비유이고, 실제 구조를 정확히 옮긴 설명은 아니에요.

    한국어 답변이 유창해졌다는 점도 따로 떼어 봐야 합니다. 문장이 매끄러운 것과 논리가 검증된 것은 다른 문제거든요. 오히려 매끄러울수록 의심 없이 넘어가기 쉽다는 게 함정입니다. 계약 조건 검토나 정산처럼 한 줄이 어긋나면 손해로 이어지는 문서일수록 앞에서 말한 확인 습관이 값을 해요.

    앞으로의 변화는 추측의 영역입니다. 그레펠이 말한 방향의 연구가 성과를 낸다면, 답을 내기 전에 여러 경로를 실제로 따져 보는 기능이 일반 사용자용 서비스에 들어올 가능성은 있어요. 가능성, 거기까지입니다. 원문 요약에는 일정도 제품 계획도 언급되지 않았거든요.

    확인된 것과 아직 불확실한 것

    확인된 것

    • 토레 그레펠은 유니버시티 칼리지 런던의 머신러닝 석좌교수이고, 딥마인드 알파고 팀의 핵심 멤버였다.
    • 그는 구글 딥마인드를 떠났고, 그 이유로 기계 추론에 새 접근이 필요하다는 믿음을 들었다.
    • 알파고는 해설자들이 프로그램 오류로 생각할 만큼 낯선 수를 둔 뒤 이세돌을 이겼다.
    • ‘LLM은 추론하지 않는다’는 그의 글은 의견 기고 형식이다.

    아직 불확실한 것

    • 알파고 구조의 어떤 요소를 어떤 방식으로 가져오려는지. 참고한 원문 요약에는 구체 내용이 없다.
    • 그레펠이 어디에서 어떤 형태로 연구를 이어 가는지.
    • LLM이 추론을 하는지에 대한 연구자들의 합의. 추론을 어떻게 정의하느냐에 따라 답이 갈리는 열린 논쟁이다.
    • 새 접근이 일반 사용자가 쓰는 제품으로 이어질지, 이어진다면 언제일지.

    추론이라는 라벨보다 다시 확인할 수 있는 답인지를 본다

    LLM이 추론을 하느냐는 질문은 추론을 어떻게 정의하느냐에 따라 답이 달라집니다. 알파고를 만든 연구자가 ‘아니다’ 쪽에 섰다는 건 귀담아들을 신호예요. 하지만 사용자가 그 논쟁의 승패를 기다릴 이유는 없습니다.

    실용적인 기준은 하나로 모여요. 받은 답을 내가 다른 방법으로 다시 확인할 수 있는가. 확인 가능한 형태로 답을 받아내고, 틀렸을 때 비용이 큰 일에는 사람의 검토를 한 단계 끼워 넣는 것. 화면에 어떤 문구가 뜨든 이 습관이 있으면 그럴듯한 답에 끌려가지 않습니다.

    출처: MIT Tech Review AI

    관련 기사

  • LLM 어텐션 병목이란? AI 확장을 막는 한계와 해결책

    LLM 어텐션 병목이란? AI 확장을 막는 한계와 해결책

    GPT-4에 100페이지짜리 문서를 통째로 넣어봤다면 느꼈을 거다. 처리 속도가 뚝 떨어지고, API 비용이 예상보다 훨씬 많이 나온다. 서버 문제라고 생각하기 쉽지만 원인은 더 깊은 곳에 있다. LLM의 핵심 구조인 어텐션 메커니즘(Attention Mechanism)에 수학적 병목이 박혀 있기 때문이다. 업계가 10년 가까이 싸워온 바로 그 병목이다.

    어텐션 메커니즘이 뭔가

    2017년 논문 “Attention is All You Need”에서 시작된 이야기다. 어텐션 메커니즘은 모델이 텍스트를 처리할 때 각 단어가 다른 단어들과 얼마나 관련이 있는지를 계산하는 방식이다.

    예를 들어 “고양이가 쥐를 잡았다. 그것은 작았다”는 문장에서 ‘그것’이 ‘쥐’를 가리킨다는 걸 모델이 이해하려면, 문장 내 모든 단어 쌍의 관계를 계산해야 한다. 이 계산이 어텐션이다. 문제는 이 계산이 토큰 수의 제곱(n²)에 비례한다는 점이다. 입력이 1,000 토큰이면 100만 번, 10,000 토큰이면 1억 번의 계산이 필요하다. 토큰 두 배 → 계산량 네 배. 이것을 이차(Quadratic) 복잡도라 부른다.

    왜 이게 현실적인 문제가 되나

    AI 서비스를 만드는 입장에서 이 공식은 악몽 같은 비용 구조를 만든다.

    • 컨텍스트 윈도우 제한: 모델이 한 번에 처리할 수 있는 텍스트 길이가 이 병목 때문에 제한된다. 128K 토큰을 지원해도, 긴 입력일수록 메모리 사용량과 처리 시간이 폭발적으로 증가한다.
    • 추론 비용 폭등: 긴 문서를 분석시키면 비용이 선형이 아닌 기하급수적으로 올라간다.
    • 응답 지연: 첫 토큰이 나오기까지 걸리는 시간(TTFT, Time to First Token)이 입력 길이에 따라 크게 달라진다.

    서버를 더 사면 해결되는 문제가 아니다. 근본적인 수학 구조의 문제다.

    지금까지 나온 임시방편들

    업계는 이 문제를 정면으로 풀지 않고 우회하는 방법들을 개발해왔다.

    FlashAttention은 GPU 메모리 접근 방식을 바꿔, 이차 복잡도는 유지하되 실제 속도를 대폭 끌어올렸다. 연산량 자체는 줄지 않지만 메모리 I/O를 최적화해 빠른 추론을 가능하게 했다. 현재 거의 모든 주요 LLM이 FlashAttention2 또는 FlashAttention3를 쓴다.

    희소 어텐션(Sparse Attention)은 모든 토큰 쌍을 계산하지 않고 연관성이 높을 것 같은 일부만 계산한다. Longformer, BigBird 같은 모델이 이 방식을 썼다. 단점은 어떤 토큰을 건너뛸지 결정하기가 까다롭고, 일부 정보가 유실될 여지가 있다.

    슬라이딩 윈도우 어텐션은 최근 토큰들에만 집중하고 먼 과거 토큰은 일부만 참고하는 방식이다. Mistral AI가 이 방법으로 꽤 효율적인 모델을 만들었다. 세 방식 모두 복잡도를 줄인 게 아니라, 계산을 덜 하거나 더 효율적으로 배치하는 접근이다.

    아예 다른 구조로 판 바꾸기 시도

    트랜스포머 자체를 대체하려는 시도도 끊임없이 나왔다.

    Mamba(맘바)는 2023년 말 등장해 가장 눈길을 끈 대안이다. 상태 공간 모델(SSM, State Space Model) 기반으로 선형(O(n)) 복잡도를 달성했다. 이론적으로는 매우 매력적이지만, 긴 문맥에서 정보를 기억하는 능력이 어텐션만큼 강하지 않다는 평가를 받는다. 이후 트랜스포머와 SSM을 섞은 하이브리드 모델들(Jamba, Zamba 등)이 잇따라 등장했다.

    RWKV는 RNN 구조를 선형 복잡도로 확장한 시도다. 트랜스포머처럼 병렬 학습이 가능하면서 추론은 RNN처럼 처리한다. 오픈소스 커뮤니티에서 꾸준히 발전 중이다.

    선형 어텐션(Linear Attention)은 어텐션 수식 자체를 수학적으로 변형해 복잡도를 낮추는 접근이다. Performer, Linformer 등이 이 방향이다. 이론적 복잡도는 낮췄지만 실제 벤치마크에서 표준 어텐션의 품질을 따라잡기가 쉽지 않았다.

    서브쿼드래틱이 진짜로 가능한가

    서브쿼드래틱(Sub-quadratic)은 이차 복잡도보다 낮으면서도 완전한 어텐션의 성능을 유지하는 것을 목표로 한다. 이 둘을 동시에 달성하는 게 핵심 과제다.

    수학적으로는 커널 함수 근사, 저랭크 분해(Low-rank decomposition), 랜덤 피처(Random features) 등 여러 접근이 시도됐다. 이론적 복잡도를 낮추는 데 성공한 논문들은 꽤 있다. 하지만 여기에는 구조적인 딜레마가 있다. 이차 복잡도가 나오는 이유가 단순히 구현 방식 때문이 아니라, “모든 토큰이 다른 모든 토큰을 참조한다”는 어텐션의 본질적 특성에서 나오기 때문이다. 이 특성을 유지하면서 복잡도를 낮추는 건 수학적으로 상당히 까다롭다.

    이게 해결되면 실제로 뭐가 달라지나

    어텐션 병목이 진짜로 해결된다면 파급 효과는 작지 않다.

    • 컨텍스트 윈도우의 실질적 무제한화: 책 한 권, 코드베이스 전체, 수백 개 대화 이력을 한 번에 넣어도 비용이 선형적으로만 늘어난다.
    • 추론 비용 급감: 긴 입력을 다루는 작업의 비용 구조가 완전히 바뀐다. API 가격도 내려갈 여지가 생긴다.
    • 엣지 디바이스 가능성: 스마트폰이나 PC에서 긴 컨텍스트를 다루는 LLM 실행이 현실적인 선택지가 된다.
    • 멀티모달 확장: 이미지, 비디오, 오디오를 토큰으로 변환하면 토큰 수가 폭발적으로 늘어난다. 병목이 해소되면 멀티모달 모델의 제약이 대폭 완화된다.

    엔비디아 GPU 수요 구조에도 변수가 생긴다. 현재는 이차 복잡도 탓에 메모리 대역폭과 VRAM 용량이 최우선 스펙이 되는데, 선형 복잡도 모델이 대세가 되면 하드웨어 설계 우선순위도 달라진다.

    주장이 아니라 코드와 숫자로 판단해야

    스타트업이 “어텐션 병목을 풀었다”고 선언할 때 냉정하게 봐야 할 체크리스트가 있다.

    • 실제 벤치마크(MMLU, MATH, HumanEval 등)에서 기존 트랜스포머 대비 성능이 얼마나 되나
    • 100K 토큰 이상의 긴 컨텍스트에서도 품질이 유지되나
    • 기존 학습 인프라(CUDA, 파이토치 생태계)와 호환되나, 아니면 새 하드웨어가 필요한가
    • 사전학습 시간과 비용은 어떤가

    학계에서도 수년간 “어텐션을 대체했다”는 논문이 꾸준히 나왔지만, 실용화 단계에서 가로막힌 경우가 많았다. 수학적 복잡도를 낮춰도 실제 하드웨어에서의 메모리 접근 패턴, 병렬화 가능성 등 다른 변수들이 성능을 결정하기 때문이다. MIT 테크 리뷰가 전한 바에 따르면, Subquadratic 같은 스타트업들이 실제 검증 자료를 공개하기 시작하는 단계가 바로 이 국면이다. 진짜 도약은 논문이 아니라 오픈소스 코드와 검증된 벤치마크가 함께 나올 때 시작된다.

    출처: MIT Tech Review AI

    관련 기사

  • AI 학습 vs 추론: LLM 시대, 핵심 개념과 차이점

    AI 학습 vs 추론: LLM 시대, 핵심 개념과 차이점

    AI 반도체 뉴스 보다 보면 ‘학습’이랑 ‘추론’이라는 단어가 계속 나온다. 엔비디아 GPU가 학습에 쓰인다, Groq은 추론에 특화됐다 — 근데 정작 이 둘이 뭐가 다른지 명확히 설명하는 글이 별로 없다. 직접 정리해봤다.

    AI 학습(Training): 데이터에서 패턴 뽑아내는 과정

    학습은 말 그대로 AI가 ‘배우는’ 단계다. 고양이 사진 수백만 장을 보여주면서 “이게 고양이야”라고 가르치는 것처럼, 모델은 데이터에서 패턴을 뽑아내고 내부 파라미터를 조정한다. 아이가 수천 번 실수하면서 자전거 타는 법을 익히는 것과 비슷하다.

    문제는 자원이다. 고양이 사진 몇 장이 아니다. 수십억 개의 텍스트 토큰, 수백만 시간치 비디오 데이터를 처리해야 한다. 병렬 연산에 강한 GPU가 여기서 필수인데, 엔비디아(NVIDIA)가 AI 반도체 시장을 장악한 것도 이 학습 단계에 최적화된 GPU 덕분이다. 모델 크기가 커질수록 학습 비용은 그냥 늘어나는 게 아니라 기하급수적으로 뛴다.

    AI 추론(Inference): 학습한 걸 써먹는 단계

    추론은 학습을 마친 모델이 실제로 일하는 과정이다. 고양이를 학습한 모델한테 처음 보는 사진을 보여줬을 때 “이거 고양이”라고 정확히 답하는 것. 챗GPT에 질문 던지면 답변 생성하는 것, 자율주행차가 도로의 장애물을 파악하는 것 — 전부 추론이다.

    학습처럼 데이터 수억 개를 동시에 처리할 필요는 없다. 대신 속도가 생명이다. 질문하고 2초 기다리면 답답하다. 동시 접속자 수만 명이 쓰는 서비스면 각 요청을 빠르게 처리하면서도 전력은 최소화해야 한다. 비용 문제도 크다.

    학습과 추론, 왜 다른 반도체가 필요할까?

    학습과 추론이 요구하는 게 달라서 최적 칩 설계도 달라진다.

    • 학습용 반도체: 대규모 병렬 연산, 높은 메모리 대역폭(Bandwidth), 방대한 메모리 용량이 핵심. 행렬 곱셈과 덧셈이 동시다발적으로 일어나고, 그 데이터를 고속으로 주고받아야 한다. GPU가 여기서 압도적이다.
    • 추론용 반도체: 저지연(Low Latency), 높은 처리량(Throughput), 와트당 성능(Performance per Watt)이 핵심. 학습된 모델은 이미 고정된 상태라 적은 연산으로 빠르게 결과를 뽑고, 이걸 동시에 많은 사용자한테 제공해야 한다.

    비유하자면 이렇다. 학습은 백과사전 전권을 통째로 외우는 작업. 추론은 이미 외운 백과사전에서 질문에 맞는 항목을 찾아 즉시 답하는 작업. 외울 때는 넓은 책상과 두꺼운 참고서 더미가 필요하고, 답할 때는 잘 정리된 색인과 빠른 손이 더 중요하다.

    LLM 시대, AI 추론 반도체가 뜨는 이유

    챗GPT 같은 거대언어모델(LLM)이 일상화되면서 추론 시장이 급격히 커지고 있다. 학습은 한 번 하면 끝이지만, 추론은 서비스 운영 내내 계속된다.

    • 비용 효율성: LLM 서비스 운영 비용의 대부분은 추론 단계에서 나온다. 사용자가 늘수록 추론에 필요한 반도체 자원도 비례해서 증가한다.
    • 실시간 응답: 0.1초 지연도 체감된다. 서비스 품질에 직결되는 문제다.
    • 응용 범위: 자율주행, 실시간 번역, 로봇 제어까지 — 죄다 실시간 추론이 필요한 영역이다.

    Groq처럼 추론 전용 반도체를 개발하거나, 기존 하드웨어에서 추론 효율을 극대화하는 소프트웨어 기술에 집중하는 기업이 늘어나는 이유가 여기 있다. 학습 시장은 엔비디아의 독주가 굳어졌지만, 추론 시장은 아직 열려 있다는 평가가 많다.

    추론 반도체, 기술적으로 뭘 봐야 하나

    추론에 강한 반도체의 조건은 크게 네 가지다.

    1. 특정 연산 최적화: AI 모델의 핵심 연산(행렬 곱셈 등)을 위한 전용 하드웨어 유닛을 탑재해 속도를 올린다. ASIC(Application-Specific Integrated Circuit)이나 FPGA(Field-Programmable Gate Array) 같은 맞춤형 칩이 이 범주다.
    2. 메모리 접근 최적화: 모델 가중치(weights)를 효율적으로 저장하고 빠르게 불러올 수 있는 구조가 중요하다. 온칩(On-chip) 메모리 활용을 극대화하거나, 낮은 비트 정밀도(Low-precision) 연산으로 대역폭 요구량을 줄이는 방식이 쓰인다.
    3. 낮은 전력 소모: 데이터센터 전기 요금, 스마트폰이나 IoT 기기의 배터리 수명. 와트당 성능이 낮으면 결국 운영비로 터진다.
    4. 프로그래밍 유연성: 완전 맞춤형 칩은 성능은 뛰어나지만 범용성이 떨어진다. PyTorch, TensorFlow 같은 프레임워크를 얼마나 폭넓게 지원하느냐도 실제 도입 결정에서 중요한 변수다.

    자주 나오는 질문들

    • Q: 학습이랑 추론, 둘 다 GPU로 가능한가요?
      • A: 됩니다. GPU는 병렬 연산에 강해서 학습·추론 모두에 쓸 수 있어요. 다만 추론 전용으로 설계된 칩은 GPU보다 효율이 높은 경우가 있습니다. 대규모 추론에서는 GPU가 학습 대비 효율이 떨어지는 구간이 생기기도 해요.
    • Q: 엣지(Edge) AI는 왜 추론과 연관이 깊나요?
      • A: 엣지 AI는 스마트폰, 드론, IoT 기기처럼 클라우드가 아닌 기기 자체에서 AI 연산을 돌리는 걸 말합니다. 네트워크가 불안정하거나 전력이 제한된 환경에서 학습된 모델을 기기 안에서 빠르고 효율적으로 추론하는 게 핵심이에요. 매번 클라우드에 요청을 보낼 수 없으니까요.

    결국 AI 기술의 두 축은 학습과 추론이다. 학습이 지식을 쌓는 과정이라면, 추론은 그 지식으로 실제 문제를 푸는 과정이다. LLM이 일상에 파고들수록 추론 효율이 AI 서비스의 성패를 가른다. 추론을 누가 더 빠르고 싸게 해내느냐 — 그게 다음 AI 반도체 경쟁의 본질이다.

    출처: TechCrunch

    관련 기사

  • AI 세계모델이란? 인간처럼 세상을 이해하는 AI의 비밀

    AI 세계모델이란? 인간처럼 세상을 이해하는 AI의 비밀

    LLM은 글을 잘 쓴다. 정말 잘 쓴다. 근데 컵을 탁자 끝에 올려놓으면 어떻게 되는지 물어보면? 정답은 맞히지만, 그 이유를 진짜로 ‘이해’하는 건 아니다. 언어 패턴을 학습한 거지, 중력이나 물리법칙을 내면화한 게 아니라는 얘기다. 챗GPT로 대표되는 거대 언어 모델(LLM)이 인상적인 건 맞다. 자연스러운 대화, 복잡한 질문 처리, 창의적 글쓰기, 코딩까지. 근데 그 배경에 깔린 물리적 세계나 인과관계를 진짜로 ‘이해’하냐고 물으면 대답이 달라진다. 여기서 등장하는 개념이 바로 세계모델(World Model)이다.

    LLM의 두 얼굴 — 언어 천재, 세상 문외한

    현재 LLM의 작동 원리는 단순하다. 방대한 텍스트에서 패턴을 학습하고, 주어진 프롬프트에 가장 그럴듯한 다음 단어를 예측한다. 이 방식으로 이전과는 비교 불가한 언어 능력을 만들어냈다.

    • 잘하는 것: 자연어 처리, 번역, 요약, 콘텐츠 생성, 코딩 지원
    • 못하는 것:
      • 환각(Hallucination): 없는 정보를 그럴듯하게 지어낸다. 학습 데이터에 없던 상황이 나오면 추론 대신 창작을 한다. 이게 문제다.
      • 상식 부족: ‘컵을 놓으면 깨진다’ — 이런 물리 세계 상식을 텍스트 패턴만으로 완전히 체득하기 어렵다. 언어로 설명할 순 있어도 실제로 ‘아는’ 건 다른 문제다.
      • 계획·추론 능력: 복잡한 문제를 단계별로 풀거나, 행동의 결과를 시뮬레이션하는 데 취약하다. 세상이 어떻게 돌아가는지에 대한 내부 모델이 없기 때문이다.

    책을 통째로 외웠지만, 그 내용이 실제 세계에서 어떻게 적용되는지는 모르는 상태. LLM의 현주소가 딱 그렇다.

    세계모델이 뭔가 — AI가 세상을 배우는 방식

    세계모델은 AI가 주변 환경을 내부적으로 표현하고 시뮬레이션하는 방식이다. 인간이 장애물 앞에서 무의식적으로 발걸음을 계산하고, 유리잔을 잡을 때 적절한 힘을 조절하는 것처럼 — 뇌 속에 이미 물리적 세계의 ‘모델’이 구축돼 있기 때문에 가능한 일이다. AI도 이런 내부 모델을 갖출 수 있냐, 가 핵심 질문이다.

    MIT 테크놀로지 리뷰 보도를 보면 전문가들이 강조하는 것도 이 지점이다. AI가 언어의 벽을 넘어 외부 세계를 진짜로 이해하려면 내부 시뮬레이션 능력이 필수라는 것. 세계모델이 있으면 AI는 이런 질문에 답을 낼 수 있다.

    • 「이 물체를 저기로 옮기면 무슨 일이 생기나?」
    • 「내가 이 행동을 하면 3단계 후에 상황이 어떻게 바뀌나?」
    • 「지금 보이지 않는 저 뒤에는 무엇이 있을까?」

    단순한 패턴 예측이 아니라, 세상의 작동 원리를 이해하고 미래를 시뮬레이션하는 것. 이게 세계모델과 기존 LLM의 결정적 차이다.

    왜 지금 세계모델인가

    로봇공학, 자율주행, 게임 AI 분야에서는 이미 세계모델 개념을 적극 활용 중이다. 자율주행차가 전방 차량의 급정거를 0.1초 만에 예측해 브레이크를 밟을 수 있는 건 카메라 데이터만으로 작동하는 게 아니다. 환경을 내부적으로 모델링하고, 「이 차가 이 속도로 이 방향으로 움직이면 1초 후 어디 있을까」를 실시간으로 시뮬레이션하기 때문이다.

    LLM에 세계모델 개념을 통합하려는 시도도 이어지고 있다. 텍스트만이 아니라 영상, 음성, 센서 데이터까지 학습해 물리적 세계를 이해하는 멀티모달 모델들이 그 방향이다. 솔직히 아직 갈 길은 멀다. 하지만 방향은 분명해지고 있다.

    세계모델이 바꿀 것들

    세계모델이 성숙하면 뭐가 달라질까. 몇 가지는 꽤 구체적으로 그려진다.

    • 로봇: 「청소해줘」 한마디에 집 구조를 파악하고, 장애물을 피하며, 좁은 틈새까지 알아서 처리하는 수준. 지금 로봇 청소기와는 다른 차원이다.
    • 의료: 환자의 상태 변화를 예측하고, 약물 투여 후 3시간 뒤 상태를 시뮬레이션해 치료 계획을 조정한다.
    • 교육: 학생의 이해 수준을 실시간으로 모델링해, 다음에 어떤 개념을 어떻게 설명할지를 즉각 조정한다.
    • 엔지니어링: 설계 변경이 전체 시스템에 어떤 연쇄 효과를 낳는지, 만들어보기 전에 시뮬레이션으로 검증한다.

    결국 세계모델은 AI를 ‘언어 도구’에서 ‘실행 에이전트’로 바꾸는 핵심 기술이다. 이해하고, 예측하고, 행동하는 AI. 지금의 LLM이 답변을 생성한다면, 세계모델을 갖춘 AI는 행동을 계획한다.

    아직 넘어야 할 산들

    장밋빛 전망만 늘어놓기엔 현실적인 걸림돌이 있다. 몇 가지는 꽤 까다롭다.

    • 데이터 문제: 물리 세계를 제대로 학습하려면 텍스트 외에 방대한 센서·영상 데이터가 필요하다. 수집도 어렵고, 레이블링은 더 어렵다.
    • 계산 비용: 환경을 실시간으로 시뮬레이션한다는 건 연산량이 기하급수적으로 늘어난다는 뜻이다. 현재 하드웨어로는 한계가 있다.
    • 일반화: 특정 환경에서 훈련된 세계모델이 전혀 다른 환경에서도 작동하냐는 게 아직 풀리지 않은 문제다. 공장 바닥에서 잘 돌아가던 로봇이 계단 앞에서 멈추는 것처럼.

    이 문제들이 해결되는 속도가 세계모델의 실용화 시점을 결정한다. 연구는 빠르게 진행 중이다. 1~2년 안에 의미 있는 변화가 나올지, 5년은 걸릴지 — 이건 아무도 장담 못한다.

    결국 뭘 봐야 하나

    세계모델 분야에서 눈여겨볼 플레이어는 몇 있다. OpenAI, DeepMind, Meta AI — 대형 연구소들이 각자의 방식으로 접근 중이다. 학계에서는 Yann LeCun이 세계모델 기반 AI 아키텍처를 오래전부터 밀고 있다. 그의 주장은 간단하다. 인간 수준의 AI를 만들려면 LLM식 접근으론 한계가 있고, 물리 세계를 이해하는 세계모델이 필수라는 것.

    동의하든 안 하든, 방향 자체는 맞다. AI가 텍스트의 세계에서 물리 세계로 발을 넓히는 과정. 세계모델은 그 이정표다.

    출처: MIT Tech Review AI

    관련 기사

  • 오픈소스 LLM의 진화: 딥시크 V4, 무엇이 다른가?

    오픈소스 LLM의 진화: 딥시크 V4, 무엇이 다른가?

    딥시크가 또 치고 나왔다. V4 출시 이후 개발자 커뮤니티 반응이 예사롭지 않다. “이게 오픈소스라고?” 하는 반응이 꽤 나왔고, MIT 테크 리뷰도 오픈소스 생태계의 중요한 이정표라고 짚었다. 클로즈드 소스의 독무대였던 고성능 LLM 시장에서, 딥시크 V4는 꽤 도발적인 질문을 던진다. 굳이 GPT에 돈 써야 하나?

    오픈소스 LLM이 지금 왜 중요한가

    예전엔 LLM은 빅테크 전유물이었다. 막대한 GPU, 방대한 학습 데이터, 수백 명의 연구팀 — 일반 기업이 범접할 수 없는 영역처럼 보였다. 그게 라마(Llama) 공개 이후 달라졌다. 이제 오픈소스 모델이 생태계를 실질적으로 바꾸고 있다.

    이유는 간단하다. 네 가지다.

    • 접근성: 특정 API 없이도 누구나 모델을 돌릴 수 있다. 기술 민주화라는 말이 공허하게 들릴 수 있는데, 여기선 진짜다.
    • 투명성: 모델 내부를 들여다볼 수 있으니 편향성 검증이나 윤리 문제에 대한 커뮤니티 수준의 논의가 생긴다. 블랙박스에 맡기는 것과는 차원이 다르다.
    • 혁신 속도: 전 세계 개발자들이 동시다발로 개선하고 실험한다. 단일 기업의 로드맵에 묶이지 않는다는 게 핵심이다.
    • 비용: 클라우드 API 호출 비용 없이, 인프라만 있으면 된다. 스타트업에게 이건 생존과 직결된 문제다.

    MIT 테크 리뷰 보도를 보면, 딥시크 V4의 등장은 이 오픈소스 흐름을 한 단계 더 끌어올리는 계기로 평가받는다.

    딥시크(DeepSeek)라는 회사

    중국 기반 AI 연구 기업이다. DeepSeek-MoE, DeepSeek-Coder 등 이전 모델들도 개발자 사이에서 꽤 인정받았다. 그냥 어디서 툭 튀어나온 회사가 아니라, 오픈소스 커뮤니티에서 실제 트랙 레코드가 있는 곳이다. 이들의 목표는 모델 개발 자체를 넘어, AI 연구의 개방성과 접근성을 높이는 데 있다. V4는 그 연장선의 최신작이다.

    딥시크 V4의 핵심: 콘텍스트 윈도우

    V4가 주목받는 이유는 단 하나다. 콘텍스트 윈도우가 비약적으로 늘었다.

    콘텍스트 윈도우란 모델이 한 번에 처리할 수 있는 텍스트의 양이다. 짧으면? 긴 문서는 반쪽밖에 못 읽는다. 길면? 100페이지짜리 계약서를 통째로 넣고 물어볼 수 있다. 그 차이가 실제 업무에서 얼마나 큰지, 써본 사람은 안다.

    V4의 새 아키텍처는 긴 프롬프트를 훨씬 효율적으로 처리한다. 구체적으로 무엇이 달라지냐면:

    • 장문 문서 처리: 긴 보고서, 논문, 법률 계약서를 통째로 넣고 요약이나 정보 추출이 가능해진다. 이전엔 잘라서 넣어야 했다.
    • 코드 분석: 대형 코드베이스를 한 번에 분석해서 버그를 찾거나 리팩터링 제안을 받는 것, 이제 현실적인 얘기가 됐다.
    • 대화 맥락 유지: 챗봇이 긴 대화 끝에 앞 내용을 까먹는 현상, 경험해봤다면 얼마나 짜증나는지 알 것이다. V4는 그 문제를 상당히 완화한다.

    솔직히 콘텍스트 윈도우 하나가 이 정도까지 게임 체인저가 될 줄은 몰랐다. 이 개선은 실제 비즈니스 환경과 개인 생산성 양쪽에 직접적인 파급을 준다.

    오픈소스 LLM이 실제로 바꿀 것들

    V4 같은 모델이 계속 나오면 생태계는 이렇게 달라진다.

    • 개발자 생태계 확장: 고성능 LLM을 기반으로 새로운 앱과 서비스를 만드는 진입 장벽이 확 낮아진다. AI 기술의 상향 평준화가 생각보다 빠르게 온다.
    • 스타트업 혁신 촉진: 초기 자본이 빠듯한 스타트업도 자체 AI 모델을 구축하거나 파인튜닝해서 경쟁력 있는 서비스를 만들 여지가 생긴다. 독점적인 API 비용 부담 없이 혁신에 집중하는 구조가 된다는 얘기다.
    • 기업 AI 도입 가속화: 유료 API 대신 자체 서버에 오픈소스 모델을 올리면 데이터가 외부로 나가지 않는다. 금융이나 의료처럼 민감한 데이터를 다루는 곳에선 결정적인 장점이다.
    • AI 연구의 새로운 지평: 모델 내부 구조를 직접 들여다볼 수 있으니 연구자들이 AI의 한계를 파고드는 속도가 달라진다. 엔비디아의 젠슨 황 CEO도 오픈소스 AI의 중요성을 여러 차례 언급한 바 있다.

    클로즈드 vs 오픈소스 — 솔직히 여기서 갈린다

    AI 모델 선택에서 클로즈드 소스냐 오픈소스냐, 이 질문이 점점 더 실질적인 의사결정이 되고 있다. 정리하면 이렇다.

    • 클로즈드 소스 (GPT-4, 클로드 3 등):
      • 장점: 대체로 최상급 성능, 편한 API 인터페이스, 안정적인 기술 지원, 꾸준한 업데이트.
      • 단점: 비용이 쌓인다. 데이터가 외부 서버로 나간다. 모델이 블랙박스다. 특정 기업 정책에 종속된다.
    • 오픈소스 (딥시크 V4, 라마 등):
      • 장점: 모델 자체는 무료이고 인프라 비용만 든다. 투명하고 커스터마이징이 자유롭다. 자체 서버 운영 시 데이터 주권을 확보할 수 있다.
      • 단점: 직접 운영·관리해야 한다. 초기 인프라 구축이 필요하다. 성능 편차가 존재할 수 있다. 클로즈드 소스만큼의 광범위한 기술 지원은 없다.

    최고 성능이 우선이고 비용이 문제없다면 클로즈드 소스. 비용이 아프거나, 데이터 보안이 민감하거나, 모델을 특정 목적에 맞게 깊이 손봐야 한다면 오픈소스가 더 합리적인 선택이다. 이건 이제 이념 문제가 아니라 현실적인 계산이다.

    딥시크 V4, 누가 실제로 쓸 수 있나

    추상적인 얘기 말고, 실제 활용 시나리오다.

    • 개인 개발자·연구자: 프로토타입 제작, 특정 연구 목적 실험, 도메인 특화 Q&A 시스템 구축. 비용 부담 없이 고성능 모델을 실험해볼 수 있다는 게 핵심이다.
    • 스타트업·중소기업: 내부 문서 요약, 고객 지원 챗봇, 마케팅 콘텐츠 생성, 이메일 자동화. 이것들을 직접 구현하면 비용 구조가 완전히 달라진다.
    • 교육 기관: 대규모 학습 자료 분석, 학생 질문 응답 보조 도구 개발. 대학이나 연구소 단위로 쓰기에 현실적인 선택지가 됐다.
    • 전문 서비스 분야 (법률, 금융 등): 긴 계약서나 금융 보고서에서 핵심 정보를 빠르게 추출하고 분석하는 데 쓰인다. 민감한 데이터가 외부로 나갈 걱정 없이 내부에서 처리할 수 있다는 점이 결정적이다.

    소설가 지망생이 방대한 자료를 읽고 아이디어를 뽑아내거나, 마케터가 고객 피드백 수백 건을 분석해 캠페인 아이디어를 찾는 데도 실제로 활용된다. 이게 먼 미래 얘기가 아니라 지금 일어나고 있는 일이다.

    오픈소스 AI, 다음 수순은

    오픈소스 AI는 이제 변방이 아니다. V4 같은 모델들이 방향을 보여준다.

    1. 성능 격차의 지속적인 감소: 클로즈드 소스와 오픈소스 간 성능 차이는 꾸준히 좁혀질 것이다. 더 효율적인 아키텍처와 학습 방법론이 빠르게 개발되고 있다.
    2. 커뮤니티 협력 강화: 전 세계 개발자와 연구자들이 버그 수정, 기능 추가, 보안 강화에 참여하는 속도가 더 빨라진다.
    3. 윤리·안전 논의 활성화: 투명한 모델 구조가 기반이 되니, AI 편향성 제거와 안전성 확보에 대한 기술적 논의도 더 구체적으로 진행될 전망이다.
    4. 전문 분야 특화 모델 확산: 일반 대화 모델을 넘어, 법률·의료·금융 등 특정 산업에 최적화된 오픈소스 LLM이 더 많이 등장할 것이다.

    결국 오픈소스 AI는 기술 독점의 벽을 허물고, 더 많은 사람에게 AI의 혜택을 실질적으로 가져다주는 동력이 된다. 딥시크 V4는 그 과정에서 빼놓을 수 없는 이정표로 남을 것이다.

    출처: MIT Tech Review AI

    관련 기사

  • 소형 언어 모델(SLM) 이란? 공공기관 AI 활용 핵심 가이드

    소형 언어 모델(SLM) 이란? 공공기관 AI 활용 핵심 가이드

    공공기관에서 AI를 쓰는 게 말처럼 쉽지 않다. 보안 검토, 개인정보 규정, 데이터 주권, 투명한 의사결정 요건… 체크리스트가 줄줄이 달려있거든요. 민간 기업이야 챗GPT 하나 연동해서 바로 써도 되지만, 공공 부문은 그게 안 됩니다. 그 틈새를 파고드는 게 바로 소형 언어 모델(SLM)인데요. 공공기관 AI 도입 논의에서 SLM이 빠지지 않는 이유가 있습니다.

    거대 언어 모델(LLM)이 공공기관에 잘 안 맞는 이유

    챗GPT로 대표되는 거대 언어 모델(LLM)은 확실히 강력합니다. 복잡한 질의응답, 문서 요약, 콘텐츠 초안 작성 — 생산성 면에서는 인정할 수밖에 없죠. 근데 공공기관 입장에서 LLM 도입은 솔직히 부담이 큽니다. 이유는 크게 넷입니다.

    • 데이터 보안 및 주권 문제: 행정 문서나 국민 개인정보를 외부 LLM 서비스에 넘기는 순간 통제권을 잃습니다. 데이터 유출 리스크는 물론이고, 해외 서버에 저장되는 순간 법적으로도 문제가 생길 수 있어요.
    • 블랙박스 문제: LLM은 “왜 이런 답이 나왔는지” 설명하기가 어렵습니다. 민원 처리나 정책 결정에서 AI 판단의 근거를 대야 하는 공공 부문에서 이건 치명적이에요.
    • 운영 비용: 수천억 개의 파라미터를 돌리려면 GPU 인프라가 엄청납니다. 예산이 고정된 공공기관이 감당하기 쉽지 않은 수준이죠.
    • 규제 준수: AI 윤리, 데이터 프라이버시 관련 규제는 해마다 강화되고 있습니다. LLM을 그 틀 안에 가두는 게 기술적으로도 꽤 까다롭거든요.

    소형 언어 모델(SLM)이란? LLM과 뭐가 다른가

    소형 언어 모델(SLM)은 이름 그대로 파라미터 수가 훨씬 작은 언어 모델입니다. LLM이 수백억~수천억 개의 파라미터를 가진다면, SLM은 수천만~수억 개 수준이에요. 크기만 작은 게 아니라, 처음부터 특정 도메인이나 목적에 맞춰 선별된 데이터로 학습되거나 미세 조정(fine-tuning)된다는 게 핵심입니다.

    LLM과의 결정적인 차이점 세 가지를 보면 이렇습니다.

    • 자원 효율성: SLM은 LLM보다 훨씬 가볍습니다. 온프레미스(On-premise) 환경이나 엣지 디바이스에도 배포가 되죠. 공공기관 전산실 서버에서 돌릴 수 있을 만큼요.
    • 도메인 전문성: 범용 지식을 다 담는 대신, 법률·의료·특정 행정 분야처럼 좁은 영역에서 집중 학습합니다. 해당 분야에서는 LLM 못지않은, 오히려 더 정확한 답변이 나오는 경우도 있어요.
    • 제어 가능성: 모델이 작고 학습 데이터 범위가 제한적이라 동작을 이해하고 제어하기 쉽습니다. “왜 이 결론이 나왔는지” 추적하기 LLM보다 훨씬 수월하죠.

    공공기관이 SLM에 눈길을 주는 3가지 이유

    공공 부문 환경에서 SLM이 실질적인 대안으로 부각되는 건 추상적인 장점 때문이 아닙니다. 현실적인 문제를 직접 해결해 주기 때문이에요.

    1. 보안과 데이터 주권

    SLM은 기관 내부 서버나 클라우드 전용 영역에 직접 구축해서 운영할 수 있습니다. 데이터가 밖으로 나가지 않습니다. 모델 학습부터 추론까지 전체 프로세스를 기관이 직접 통제하죠. 국방, 사법, 외교처럼 보안 등급이 높은 분야라면 이게 결정적입니다. 외부 서비스에 의존하지 않으니 서비스 중단이나 공급사 정책 변경에도 흔들리지 않아요. 데이터 주권을 기관 손에 쥐고 있다는 게 이 방식의 핵심 강점입니다.

    2. 설명 가능성과 거버넌스

    모델이 작고 특정 목적에 맞춰 학습된 SLM은 결과 도출 과정을 추적하고 설명하기 용이합니다. 공공 서비스는 정책 결정이나 민원 처리 과정에서 “왜 이렇게 됐는지”를 투명하게 설명해야 합니다. LLM보다 이 요구를 충족하기 훨씬 수월하고, AI 윤리·책임성 측면에서 감사나 외부 검토에도 대응하기 편합니다. 설명 못 하면 책임도 못 지는 구조인데, SLM은 그 부담을 덜어줍니다.

    3. 운영 비용과 자원 효율

    LLM 운영에 드는 인프라 비용은 예산이 고정된 공공기관에 부담이 상당합니다. SLM은 GPU 자원이 적게 들고, 학습·추론 속도도 빠릅니다. 기관의 특정 업무에만 집중하기 때문에 불필요한 기능에 자원을 낭비하지 않는 최적화된 운영이 됩니다. 제한된 예산 안에서 AI 서비스를 안정적으로 구축하고 확장하려는 공공기관에는 이게 매우 현실적인 강점이에요.

    실제로 도입하려면 뭘 준비해야 하나

    SLM이 공공기관 AI의 해답처럼 보여도, 막상 도입하면 준비할 게 꽤 있습니다. 체크리스트 정도로 생각하면 됩니다.

    • 도메인 특화 데이터 확보: SLM의 성능은 학습 데이터 품질에 달려 있습니다. 기관이 보유한 내부 문서, 법령 자료, 민원 이력 데이터를 체계적으로 정제해서 확보하는 작업이 선행돼야 해요. 데이터가 부실하면 모델도 부실합니다.
    • 구체적인 유스케이스 설정: “AI 챗봇 만들자”가 아니라 “특정 민원 상담 자동화”, “내부 규정 검색 시스템”, “보고서 초안 작성 지원” 같은 식으로 목표를 좁혀야 합니다. 범용 AI를 만들려다 SLM의 장점을 날려버리는 경우가 많거든요.
    • 지속적인 모델 관리: 한 번 만들고 끝이 아닙니다. 새로운 법령이 생기면 재학습이 필요하고, 성능 저하를 모니터링하는 체계도 있어야 합니다. 전담 인력이나 시스템 구축 계획이 처음부터 있어야 하죠.
    • 기존 시스템 연동: SLM을 행정 시스템이나 기존 데이터베이스와 어떻게 연결할지도 미리 설계해야 합니다. API 연동, 데이터 파이프라인 구축이 뒤따르는 작업이에요.

    결국 SLM이 공공 AI의 현실적인 답인가

    거대 언어 모델의 성능을 무작정 따라가기보다, 공공 부문이 가진 보안·규제·예산 제약을 현실로 받아들이고 그에 맞는 기술을 전략적으로 고르는 것이 훨씬 현명한 접근입니다. 보안, 설명 가능성, 비용 효율성 — 이 세 가지를 동시에 잡을 수 있는 선택지가 소형 언어 모델(SLM)입니다. 공공기관 디지털 혁신의 다음 단계는 LLM이 아니라 SLM에서 시작될 가능성이 높습니다.

    MIT Tech Review가 전한 바에 따르면, 제약 환경에서 AI를 운영 가능하게 만드는 방법으로 SLM 접근법이 유망하게 평가됩니다.

    관련 기사

  • AI 챗봇, 나를 기억하게 하는 법: 효과적인 개인화 전략 가이드

    AI 챗봇, 나를 기억하게 하는 법: 효과적인 개인화 전략 가이드

    똑같은 배경 설명을 AI에게 또 하고 있다면, 뭔가 놓치고 있는 거다. “나는 마케터야”, “B2B SaaS 회사 다녀”, “한국어로 써줘” — 이런 말을 매번 새 대화창에서 반복하다 보면 AI가 아니라 내가 더 피곤해진다. AI 챗봇을 진짜 ‘나를 아는 도구’로 만들고 싶다면, 기억을 관리하는 방법을 알아야 한다. 단순히 대화 기록을 저장하는 것과는 차원이 다른 이야기다.

    AI가 나를 ‘기억’한다는 게 정확히 뭔 말인가

    AI 챗봇의 기억은 크게 두 가지로 나뉜다. 컨텍스트 학습(Context Learning)과 페르소나 학습(Persona Learning)이다. 컨텍스트 학습은 특정 프로젝트 흐름이나 장기 대화 맥락을 기억하는 것이고, 페르소나 학습은 말투, 직업, 관심사 같은 ‘나라는 사람’의 패턴을 파악해서 응답에 녹여내는 방식이다. 대화 기록을 그냥 저장해두는 것과는 다르다. AI가 그 데이터를 실제로 소화해서 다음 답변에 반영해야 비로소 ‘기억’이라고 부를 수 있다.

    솔직히 말하면, 여기서 AI마다 차이가 크다. 어떤 AI는 대화가 끝나면 다 날아가고, 어떤 AI는 별도 메모리 기능으로 핵심 정보를 따로 저장해둔다. 어떤 AI를 쓰느냐에 따라 ‘기억’의 질이 완전히 달라지는 셈이다.

    개인화가 실제로 생산성을 어떻게 바꾸나

    AI 챗봇이 나를 모르면, 매 대화가 0에서 시작이다. 이건 생각보다 훨씬 큰 낭비다. 코딩 작업을 예로 들면, AI가 내가 Python을 쓰고, pytest를 선호하고, 타입 힌트를 반드시 넣는다는 걸 알고 있으면 첫 답변부터 그 기준에 맞게 나온다. 모른다면? “저는 Python 개발자고요, 테스트는 pytest 씁니다, 타입 힌트 필수예요” — 이 설명부터 시작해야 한다. 매번.

    • 시간 절약: 반복 입력이 줄어든다. 같은 말을 열 번 하지 않아도 된다.
    • 정확도 향상: 내 상황에 맞는 답변이 처음부터 나온다.
    • 일관성: 선호하는 톤, 형식, 단락 길이가 대화마다 유지된다.
    • 비서 효과: 상황 설명 없이 바로 본론으로 들어갈 수 있다.

    글쓰기 작업에서도 마찬가지다. AI가 내 문체를 알고, 피해야 할 표현 목록을 갖고 있고, 선호하는 구조까지 파악하고 있으면 — 초고 완성 속도가 달라진다. 경험해본 사람은 안다.

    AI의 기억을 직접 만드는 4가지 방법

    많이 쓴다고 저절로 기억이 쌓이진 않는다. 적극적으로 심어줘야 한다.

    • 명확한 프롬프트로 시작: 첫 대화에서 역할과 맥락을 구체적으로 설정하라. “너는 내 콘텐츠 기획자야. 나는 마케터고, 주 타겟은 2030 여성이야.” 이 한 줄이 이후 모든 대화의 기준점이 된다.
    • 지속적인 피드백: 답변이 마음에 안 들면 바로 말해라. “이런 스타일은 싫어”, “다음부터는 좀 더 간결하게”처럼 직접적으로. AI는 이걸 기억한다. 아니, 기억하도록 만들어야 한다.
    • 커스텀 인스트럭션 활용: ChatGPT의 ‘맞춤 설정’, Claude의 ‘프로젝트 지침’ 등 대부분의 AI 챗봇에는 이 기능이 있다. 직업, 관심사, 금지어, 선호 형식을 한 번 입력해두면 모든 대화에 자동 적용된다. 쓰지 않으면 손해다.
    • 기존 데이터 가져오기: 최근 AI 모델들은 다른 AI나 기존 채팅 기록에서 학습된 기억을 불러올 수 있는 기능을 제공하기 시작했다. The Verge가 전한 바에 따르면 Google Gemini는 다른 AI와의 채팅 기록을 가져와 학습에 쓸 수 있는 기능을 테스트 중이다. AI를 바꿀 때마다 처음부터 다시 가르치는 수고를 덜 수 있다는 게 핵심이다.

    AI 여러 개 쓸 때 기억 관리하는 법

    AI 한 개만 쓰는 시대는 지났다. 용도별로 다른 AI를 쓰는 사람이 늘고 있는데, 이때 기억 관리가 더 복잡해진다. 이건 좀 전략이 필요한 부분이다.

    • AI별 역할 분담: AI A는 글쓰기 전담, AI B는 코딩 전담 식으로 나눠라. 각 AI가 해당 영역에서만 깊은 기억을 쌓게 되면 범용으로 쓸 때보다 훨씬 정밀한 답변이 나온다.
    • 공통 기본 정보는 복붙: 직업, 주요 관심사, 작업 환경 등 모든 AI가 알아야 할 정보는 복사해서 각 AI에 동일하게 입력하라. 귀찮더라도 한 번만 하면 그만이다.
    • 기억 이전 기능 체크: ‘기억 가져오기(Import Memory)’ 또는 ‘채팅 기록 불러오기’ 기능이 있는 AI라면 반드시 활용하라. 한 AI에 쌓인 학습 데이터를 다른 AI로 옮길 수 있어서, 서비스를 갈아탈 때 드는 재학습 비용을 크게 줄인다. 서비스 간 호환성이 어디까지 되는지는 미리 확인하는 게 좋다.

    기억을 심는 것만큼, 지키는 것도 중요하다

    AI가 나를 잘 알수록 리스크도 커진다. 냉정하게 봐야 할 부분이다. 주민등록번호나 금융 계좌 정보를 AI에 입력하는 건 당연히 피해야 하고, 회사 내부 기밀을 프롬프트에 그대로 붙여넣는 것도 위험하다. 서비스 제공자의 데이터 활용 정책, 한 번쯤은 읽어봐야 한다. 귀찮아도.

    실용적인 습관 두 가지만 챙기면 된다. 첫째, 데이터 삭제 또는 기억 초기화 기능을 주기적으로 활용하라. 필요 없어진 정보가 AI에 계속 남아있을 이유는 없다. 둘째, 익명화된 데이터 처리를 원칙으로 명시한 AI 서비스를 선택하는 게 장기적으로 안전하다. 모든 AI 서비스가 동일한 수준의 보안을 제공하진 않는다는 점을 기억해두자.

    다음 수순은 — AI 개인화, 어디까지 가나

    텍스트 기반 대화는 시작일 뿐이다. 앞으로는 음성 톤, 표정, 심지어 웨어러블 기기에서 수집되는 생체 데이터까지 활용해 개인화 수준을 높이는 방향으로 간다. 스마트 홈 기기, 웨어러블 디바이스 등 IoT 기기와의 연동이 본격화되면, AI는 더 이상 앱 안에만 있지 않는다. 집에서, 이동 중에, 일하면서 — 모든 접점에서 끊기지 않고 나를 아는 AI가 붙어있는 구도다.

    이게 편한 건지 불편한 건지는 솔직히 아직 모르겠다. 분명한 건, AI의 기억을 어떻게 관리하고 어디까지 허용할지 결정하는 능력이 앞으로 AI 활용 수준을 가르는 결정적인 변수가 된다는 거다. 그냥 쓰는 사람과 관리하면서 쓰는 사람 사이의 격차는 생각보다 빠르게 벌어진다.

    출처: The Verge AI

    관련 기사