공공 현장의 로컬 LLM과 클라우드 사이 고민

일요일 밤, 공공AX 네트워크 방에서는 웍스AI(코딩 에이전트 기능이 붙은 AI 서비스로 언급됐다)로 코드를 짜고 미리보기까지 되느냐는 질문이 나왔다. 한 참가자는 코딩 에이전트가 있어 가능은 하다면서 한계를 나눠 답했다.

웍스AI에도 코딩에이전트가 있어 가능은 합니다만, 1. 개발자대상으로 만든 기능이 아니라, 코드 전체에 대한 수정이나 리뷰가 제한적입니다. 2. 토큰 비용이 생각보다 높게 나옵니다.

답변은 배포 기능도 지원하지만 쓰는 현장에 따라 제약이 있다는 경험담으로 이어졌다. 코딩 에이전트가 붙어 있다고 해서 개발 현장의 요구가 곧바로 채워지지는 않는다는 경험담으로 읽힌다. 도구의 기능 목록과 실제로 쓸 수 있는 범위가 다를 수 있음을 시사한다. 다만 이는 한 참가자의 체감이며, 다른 현장에서도 같은 한계가 나타나는지는 대화에서 확인되지 않았다.

LLM에도 DLP가 있느냐는 놀람

월요일 오후에는 화제가 통제 방식으로 옮겨 갔다. 한 참가자가 LLM을 대상으로 한 DLP, 곧 정보 유출 방지 장치가 없다는 사실에 놀라움을 드러냈다.

LLM대상 DLP가없네요?

이에 다른 참가자가 차세대 DLP를 쓴 지 꽤 됐고 생성형 AI 접근 통제는 기관이 선택하는 것 같다고 답했다. 같은 종류의 보안 장비라도 생성형 AI 접근을 열어 둘지 막을지는 기관마다 달리 정할 수 있다는 뜻으로 보인다. 어느 기관이 어떤 설정으로 쓰는지는 나오지 않았고, 통제 수준이 기관 사이에 얼마나 벌어져 있는지도 이 대화만으로는 가늠하기 어렵다.

로컬이냐 클라우드 위 전용 환경이냐

이어 로컬 LLM을 쓰는 곳이 많은지를 두고 의견이 갈렸다. 한 참가자는 로컬이 아닌 곳이 엄청 많다면서도 요즘 추세는 로컬 개발이라는 취지로 말했다.

로컬아닌곳 엄청많아서 요새 추세가 로컬개발이 트렌드에요

다른 참가자는 바이브코딩 용도로는 glm-5.3-flash 정도가 그나마 쓸 만하고 나머지는 어려운 것 같다고 평가했다. 그러면서 AWS Bedrock처럼 클라우드 위에 프라이빗 테넌시, 곧 우리 기관만 쓰는 격리된 공간을 구축해 쓰는 쪽이 현실적인 대안이 아니겠느냐고 했다. 곧바로 반론이 붙었다.

그러면 saas형태가 되어버려서 폐쇄망이 아니게되고

이 짧은 맞받아침이 대화의 긴장을 요약한다. 쓸 만한 성능의 모델을 쓰려면 클라우드로 나가야 하고, 보안 요건을 지키려면 외부 인터넷과 분리된 폐쇄망 안에 머물러야 하는데 두 조건이 한 번에 만족되지 않는다는 문제다. 로컬 LLM이 많다는 쪽과 적다는 쪽 모두 사용 비율을 보여 주는 수치를 내놓지는 않았고, 모델 성능 평가도 한 참가자의 개인 의견에 머물렀다.

그래서 이 대화는 어느 쪽이 맞는지를 가리기보다, 공공 현장이 도구 기능, 비용, 접근 통제, 망 구성이라는 여러 기준을 동시에 저울질하고 있음을 보여 준다. 웍스AI의 토큰 비용 지적과 클라우드 전용 환경의 폐쇄망 논란이 하루 사이로 이어서 나온 것도, 도입 방식을 정하는 일이 한 가지 기준으로 풀리지 않는다는 점을 시사한다.