시스템 운영에서 AI 몫을 줄이려는 고민

16일 아침 8시 31분 더배러에 한 줄짜리 질문이 올라왔다. 이날 이 화제는 4명이 16건을 남긴 작은 대화였지만, 시스템을 오래 굴려 본 사람들의 고민이 짧은 문장에 담겨 있었다.

시스템에서 AI가 차지하는 비중이 커 보이는데 맞나요?

비중이 커 보인다는 말에서 출발

질문을 받은 다른 참가자는 실행하는 모습을 보면 크게 보인다고 답했다. 질문한 참가자는 곧이어 그만큼 시스템 운영에 토큰이 많이 필요해 보인다고 덧붙였다. 이 단계에서 대화의 초점은 성능이 아니라 비용이었다.

갑자기 든 생각인데 그만큼 시스템 운영에 토큰이 많이 필요해 보여서요

질문한 참가자는 이어서 구조화는 많이 된 것 같으니 이제 흔히 말하는 효율적인 시스템, 경제적인 시스템을 고민해도 좋을 것 같다고 제안했다. 틀을 잡는 단계는 지났으니 그다음은 덜 쓰는 법이라는 순서를 제시한 셈이다.

이 단계를 꼭 AI가 해야 하나

8시 49분 같은 참가자가 자신의 고민을 길게 적었다. 스크립트나 코딩으로 풀 수 있는 부분을 가려내고, 백업과 복구를 빠르고 경제적으로 할 수 있는 구조인지를 따져 본다는 이야기다.

어느 부분을 스크립트, 코딩으로 해결할 수 있을까, 이 단계를 꼭 AI가 처리해야 할까?

곧이어 다른 참가자가 짧게 의견을 보탰다.

AI의 처리를 최소화하는게 좋죠

판단이 필요한 곳에만 AI를 쓰고 규칙대로 돌아가는 곳은 코드로 돌리자는 취지로 읽힌다. 다만 이 말에도 어디까지가 AI가 필요한 곳인지에 대한 기준은 따라붙지 않았다.

세 가지 접근

이어진 발언은 서로 다른 방법을 내놓았다. 한 참가자는 AI 처리가 불필요한 부분은 AI가 대부분 알아서 코드로 바꿔 놓는 편이라, 그렇다면 어떤 저렴한 모델이 그 일을 해낼 수 있느냐가 핵심이라고 보았다. 이 참가자는 gemini flash와 minimax m3로 그 모델들이 할 수 있는 최대한도를 시험하는 중이라고 했다.

또 다른 참가자의 방식은 달랐다.

전 AI로 탬플릿 추출하고 필요시 코드화합니다

다량의 자료를 한 번에 처리하기 좋게 하려는 것이라는 설명이 이어졌다. 처음 질문한 참가자는 자기 경험을 하나 보탰다.

중간 연결 모델이 오류 나면 많이 짜증나더군요

그리고 다시 사용할 수 있는 코드 라이브러리를 AI로 만드는지 물으며 질문을 끝냈다. 이 물음은 템플릿을 한 번 뽑아 두면 같은 일에 AI를 다시 부르지 않아도 된다는 쪽으로 대화를 이끌었지만, 답은 이 대화 안에 올라오지 않았다.

정리

정리하면 이 대화에서 토큰 부담을 줄이는 길은 세 갈래였다. 처음부터 AI 몫을 가려 스크립트로 넘기는 길, 저렴한 모델에 일을 맡겨 한계를 재 보는 길, AI로 틀을 뽑아 필요할 때만 코드로 바꾸는 길이다. 방향은 같았지만 서로를 비교하거나 한쪽을 택하자는 결론으로 모이지는 않았다.

중간 연결 모델의 오류가 짜증스럽다는 말은 모델을 이어 붙이는 구조가 안은 부담을 짚은 것으로 읽힌다. 구체적인 절감 수치나 모델 간 비교 결과는 대화에 나오지 않았으므로, 어느 방식이 더 낫다고 단정할 근거는 없다.