요즘 AI 뉴스는 ‘모델이 더 똑똑해짐’보다 ‘운영 가능한 형태로 고정된다’가 핵심이야. 추론 모드는 버튼이 아니라 라우팅이 되고, 에이전트는 데모가 아니라 평가/권한/로그부터 시작한다.
추론 모드(Reasoning mode)는 이제 기능이 아니라 라우팅 정책이다
최근 큰 모델 쪽 얘기를 보면, 다들 같은 방향으로 수렴 중이야. “깊게 생각하는 모드”를 내세우는데, 내 느낌엔 이게 단순히 모델 내부 기능이 아니라 제품 설계의 방향을 강제하는 장치에 가까워.
왜냐면 추론 모드가 생기는 순간, 앱은 선택지가 두 개로 갈라져.
- 늘 빠르게 답변하는 기본 모드
- 정말 어려운 구간에만 태우는 고비용 모드
이렇게 되면 모델 성능보다 더 중요한 게 생긴다. “언제 깊게 생각하게 할지”를 결정하는 라우터(혹은 정책)야. 이건 프롬프트 엔지니어링이 아니라 운영 설계다.
엔지니어링 관점에서 포인트는 세 가지.
- 트래픽의 분포가 바뀐다. 모든 요청이 고비용으로 들어오지 않게 제어하는 게 핵심이 된다.
- 품질 측정이 달라진다. 단순 평균 점수가 아니라, “깊게 생각하게 한 요청이 실제로 정답률을 올렸는지”를 분해해서 봐야 한다.
- 실패 형태가 달라진다. 추론 모드가 켜질수록 답이 길어지고, 길어질수록 사용자 경험에서 ‘확신’이 과잉 생산될 수 있다. 즉, 길이와 품질은 상관이 있지만 동일하지 않다.
결국 추론 모드는 UI 상의 토글이 아니라, 서비스 내부에서 “동적 비용 배분”을 하는 스위치야. 그리고 이 스위치를 누가/어떻게/언제 누르는지가 제품의 경쟁력이 된다.
에이전트는 데모를 졸업하고, 평가/관측/권한으로 입학한다
에이전트를 ‘툴을 호출하는 LLM’로 보면 쉬운데, 실전은 여기서부터 어렵다. 툴이 붙는 순간 실패가 두 종류로 폭발하거든.
- 모델이 잘못 생각해서 실패
- 툴 호출이 깨져서 실패(타임아웃, 권한, 레이트리밋, 스키마 변경, 외부 시스템 오류)
이 둘은 디버깅 방법도, 책임 소재도, 재현 방법도 다르다. 그래서 에이전트 팀이 제일 먼저 해야 하는 일은 멋진 데모가 아니라 “실패를 분류하고 다시 돌릴 수 있게 만드는 것”이야.
실무에서 바로 쓰는 체크리스트는 대충 이렇다.
- 툴 호출 로그를 구조화해서 남기기(입력/출력/소요시간/에러 코드)
- 중간 상태(state)를 저장하기(최소한 마지막 계획과 실행 단계)
- 리트라이 정책을 명시하기(같은 입력을 몇 번까지, 어떤 조건에서)
- 권한을 단계적으로 제한하기(읽기 전용 → 제한적 쓰기 → 완전 쓰기)
- 평가를 온라인/오프라인으로 나누기(개발 중 회귀 테스트 + 운영 중 모니터링)
여기서 중요한 건, 에이전트가 “똑똑해지면 해결”이 아니라는 점이야. 오히려 모델이 좋아질수록 더 많은 일을 맡기게 되고, 그러면 더 큰 규모의 관측/권한 체계가 필요해진다. 모델이 커질수록 SRE가 필요해지는 기묘한 세계관.
내 결론은 이거야. 에이전트의 실력은 모델의 IQ가 아니라, 실패를 다루는 프로덕션 역량(로그/리트라이/권한/관측)에서 갈린다.
온디바이스와 로컬 추론: “작은 모델”이 아니라 “짧은 경로”가 이긴다
온디바이스/로컬 추론 얘기가 계속 나오는 이유는 모델이 작아져서가 아니야. 경로가 짧아져서야.
- 네트워크 왕복이 없다
- 개인정보/보안 이슈가 훨씬 단순해진다
- 캐싱이 자연스럽다(로컬 컨텍스트)
그래서 요즘 최적화 트렌드는 “정확도를 살짝 버리더라도 지연시간과 비용을 안정화하는” 쪽으로 움직이는 느낌이 강하다.
개발 관점에선 양자화(quantization)와 런타임 최적화가 거의 기본 교양이 됐다.
- 4bit/8bit 양자화는 더 이상 실험이 아니라 배포 옵션이다
- KV cache, speculative decoding 같은 기법은 ‘빠르게 보이게 하는 기술’이 아니라, 실제 비용을 줄이는 기술로 자리 잡았다
- GPU가 없거나 제한적인 환경에서 CPU/Metal/모바일 NPU를 어떻게 태울지가 제품 설계의 일부가 됐다
재밌는 건, 이 흐름이 중앙 집중 클라우드와 싸우는 게 아니라는 점이야. 하이브리드로 간다. 로컬은 빠른 1차 응답/초안/요약을 담당하고, 어려운 문제는 서버로 올려서 깊게 태운다. 즉, 앞에서 말한 “추론 모드 라우팅”이 인프라 레벨에서도 반복되는 셈이지.
오픈소스 툴체인은 “모델”보다 “파이프라인”이 자산이 된다
오픈소스 쪽은 늘 그렇듯, 모델 자체보다 주변부가 빨리 굳는다. 내가 보는 핵심은 이거야.
- 모델 파일은 갈아끼우기 쉽다
- 하지만 데이터 전처리, 평가 스크립트, 배포 런타임, 관측 도구는 한 번 굳으면 쉽게 안 바뀐다
그래서 최근의 오픈소스 경쟁은 “누가 더 큰 모델을 내놨냐”보다, 누가 더 빨리 재현 가능한 파이프라인을 주냐로 이동 중이야. 특히 에이전트/툴유즈 쪽은 파이프라인의 가치가 더 커진다.
예를 들어, 함수 호출 스키마가 바뀌거나 툴이 늘어나면 바로 회귀(regression)가 난다. 이걸 막으려면 결국 테스트가 필요하고, 테스트를 하려면 환경이 필요하고, 환경을 만들려면 스크립트가 필요하다. 그 스크립트가 쌓이면 그게 팀의 자산이 된다.
여기서 한 가지 더. 커스텀 커널, 런타임 최적화, 컴파일러 쪽도 똑같이 흘러간다. “AI가 CUDA 코드를 써준다”보다 중요한 건, 그 코드가 실제로 빨라졌는지/정확한지/어떤 GPU에서 깨지는지 자동으로 확인해주는 벤치마크 체계야. 결국 또 평가다.
예상되는 미래 (Expected Future)
정리하면, 앞으로의 경쟁은 세 개의 축으로 압축될 것 같아.
- 추론 모드와 비용을 다루는 라우팅: 모델을 하나 고르는 시대가 아니라, 한 제품 안에서 여러 추론 프로파일을 스위칭하는 시대가 된다.
- 에이전트의 품질 체계: 데모는 끝났고, 이제는 재현 가능한 평가 + 관측 + 권한 설계가 기본 스펙이 된다.
- 하이브리드 실행(로컬 + 서버): 로컬은 짧은 경로로 UX를 잡고, 서버는 깊은 추론으로 정답률을 올린다. 이 둘을 붙이는 순간, 프론트/백/인프라의 경계가 다시 흔들린다.
그래서 내 예상은 좀 단순해. “더 좋은 모델” 뉴스는 계속 나오겠지만, 실제로 돈을 버는 팀은 모델을 바꾸는 팀이 아니라 라우팅/평가/운영을 잘하는 팀일 거야. 모델은 바뀌어도 파이프라인은 남는다. 결국 또 공장 얘기다.