로컬 AI를 준비해야 할 시간

[GN#358] 로컬 AI를 준비해야 할 시간 | GeekNews

 

최근 GeekNews에서 "로컬 AI를 준비해야 할 시간"이라는 기사를 읽었다.

작년 이맘때 쯤만해도 Cursor가 처음 나와서 '이게 뭔데?' 하고 있었는데, 1년이 지난 이 시점에서 Claude Code나 Codex 없이 개발하는 사람이 더 드물어졌다. 개발에서 AI의 도움을 받는 것이 점점 자연스러워지면서, 개인 개발자에게는 구독료와 사용량 제한이 부담되고, 회사 입장에서는 팀 전체의 토큰 사용량과 비용, 보안과 데이터 반출 문제를 관리해야 하게 되었다. 이제는 단순히 AI를 써야한다는 말을 넘어서 "어떤 작업을 어떤 모델에게 맡길 것인가"를 설계해야 하는 시점이 되었다.

여기서 로컬 AI 모델들이 다시 주목받고 있다. 구글에서 나온 Gemma 4나 엔비디아에서 나온 Nemotron 3 등 멀티모달 기능을 앞세워 충분히 실용적인 수준까지 발전했다. 물론 Claude Opus나 Gemini Pro 같은 최상위 모델처럼 복잡한 문제들을 혼자 해결할 수준은 되지 못하지만, 작업을 작게 나누어 단계별로 지시하는 방식이 도움이 된다고 한다. 자료 정리, 코드 오류 추적, 간단한 구현 보조처럼 개발자가 방향을 잡아주는 작업에는 이미 쓸만한 수준이며, 추론 요청마다 과금되지 않는다는 장점이 있다.

물론 복잡한 아키펙터 판단, 긴 맥락을 요구하는 설계 등은 프론티어 모델이 더 잘하지만, 이미 계획이 잡힌 상태에서 세부 구현을 맡기거나 테스트 케이스를 추가하거나 코드 리뷰 초안을 만드는 일 정도는 로컬 모델에게 넘길 만해졌다고 한다. 이른바 "비싼 모델을 꼭 써야 하는 작업"과 "로컬 모델로 충분한 작업"을 나누는 하이브리드 워크플로우가 자연스러워 질 가능성이 크다는 것이다.

앞으로의 변화는 개발 도구 뿐만 아니라 우리가 매일 쓰는 앱 안에서 일어날 가능성이 크다. 앱 기능에 OpenAI나 Anthropic API 호출을 무분별하게 추가하는 트렌드는 SW를 취약하게 만들 수 있다. 서버 장애나 신용카드 만료 만으로 앱 기능이 멈추고, 사용자 콘텐츠를 서드파티에 스트리밍하는 순간 데이터 보존 동의, 유출 같은 문제가 따라 붙는다. 우리가 쓰는 스마트폰은 이미 강력한 뉴럴 엔진을 가지고 있는데 왜 안 써먹고 서버 응답만 기다리려고 하는 거지? 단순 요약 분류 추출 재작성 정규화 작업은 온디바이스 AI 모델로도 충분히 가능하다.

사내 백오피스 도구도 마찬가지다. 예전에 삼성에서 데이터 유출 문제 때문에 사내에서 GPT의 사용을 금지했다는 뉴스를 본 기억이 있다. 고객 정보, 결제 정보, 내부 운영 데이터처럼 외부로 보내기 부담스러운 정보가 많기 때문에 이런 보조 기능들을 온디바이스에서 처리할 수 있다는 점은 제품 설계에서 큰 장점이 될 것이다.

클라우드 모델을 앱에 붙이는 순간 그 기능은 네트워크 인증 비용 장애 데이터 보존에 영향을 받는 분산 시스템이 된다. 반면 로컬 모델로 처리할 수 있는 기능은 훨씬 더 '함수'에 가깝다. 서버 비용과 외부 API 상태에 덜 의존하게 된다는 점에서 제품 구조 자체가 단순해 진다 아키텍처적 관점이 신선했다.

이 기사를 읽고 든 생각은 "그렇다면 왜 다들 로컬 LLM을 쓰지 않는 걸까?"였다. 나도 LM Studio를 통해 로컬 LLM 모델을 실행한 적이 있었지만, 한국어 처리 능력을 포함해 여러 부분에서 실망했던 기억이 있다. 기사의 장점들에는 공감하지만, 현실적으로 한국어 처리 능력이나 로컬 환경에서의 추론 속도 면에서 아직 프론티어 모델들을 대체하기엔 아쉬움이 크다는 한계도 몸소 체감할 수 있었다.

기술의 이상향과 현실의 장벽을 동시에 경험하면서, 앞으로 AI를 단순히 가져다 쓰는 것을 넘어 '어떤 비용과 보안 리스크를 고려해 어떤 모델을 적재적소에 배치할 것인가'를 설계하는 능력이 차세대 백엔드 개발자의 진짜 차별성이 될 것이다.