함수 호출을 어디에서 실행할까, 탄소 배출로 답한 연구

오늘 다루는 논문은 arXiv에 공개된 Carbon-Aware Routing for Function Calling in Edge-Cloud LLM Systems (arXiv:2609.13559)입니다. 에이전트용 함수 호출 추론이 무거운 클라우드 모델에 몰리면서 에너지와 탄소 부담이 커진다는 진단에서 출발해, 쿼리마다 엣지와 클라우드로 이뤄진 3계층 중 실행 가능한 가장 낮은 배출 계층에 배정하는 탄소 인식 라우팅 틀을 제안한다는 것이 이 연구의 주장입니다. 원문 논문으로 이어지는 링크는 제목 아래에 붙어 있습니다.

저는 이 논문을 읽게 된 계기가 꽤 분명합니다. 에이전트 이야기를 하면 대개 어떤 도구를 얼마나 잘 고르는지에 시선이 모이는데, 정작 그 추론이 어디에서 돌아가는지는 잘 묻지 않기 때문입니다. 같은 함수 호출이라도 작은 모델로 충분한 경우가 있고, 큰 모델이 아니면 위험한 경우가 있는데, 운영에서는 둘을 같은 클라우드 엔드포인트로 보내는 일이 흔합니다. 그래서 이 논문이 정확도 이야기가 아니라 어디에서 실행할지의 이야기로 풀어냈다는 점이 눈에 들어왔습니다.

왜 무거운 클라우드 모델이 기본값이 되었을까

여러 사람이 함께 일하는 팀에서는 어려운 일이 생기면 일단 가장 잘하는 사람에게 맡기는 버릇이 생깁니다. LLM 에이전트 운영도 이와 비슷하게 흘러왔습니다. 함수 호출이 실패하면 도구를 잘못 고른 탓인지, 모델이 약해서 그런지 가리기가 어려우니까, 일단 가장 큰 클라우드 모델에 보내고 보는 쪽이 마음이 편했죠. 실패 원인을 쪼개어 분석하는 것보다 큰 모델 하나로 덮는 편이 당장의 사고를 줄여주었기 때문입니다.

그런데 이런 선택에는 보이지 않는 대가가 따라붙습니다. 큰 모델은 호출 한 번당 쓰는 전력과 지연이 크고, 그 전력을 만드는 그리드의 탄소 강도에 따라 배출도 함께 커집니다. 하루에 몇 번 쓰는 실험이라면 별일이 아니지만, 에이전트가 외부 도구와 API를 수시로 두드리는 기반 시설이 되면 이야기가 달라집니다. 호출량이 쌓일수록 전력 사용량이 그대로 운영비와 탄소 발자국으로 굳어지는데요. 저는 이 대목에서 운영의 기본값을 다시 묻게 되었습니다. 정확도를 지키는 방법 말고, 실행 장소를 바꾸는 방법은 왜 진지하게 다뤄지지 않았을까 하는 점이죠.

이 논문이 파고든 지점이 바로 여기입니다. 모델을 더 키우는 대신, 이미 있는 엣지와 클라우드 자원을 어떻게 나누어 쓸지를 묻습니다. 그렇다면 쉬운 부탁까지 비싼 모델에게 맡기는 관행은 어디에서 비롯된 걸까요. 다음 장면부터 그 관행을 하나씩 풀어보겠습니다.

쉬운 부탁까지 비싼 모델에게 맡기면 무슨 일이 생길까

아침에 캘린더에서 오늘 일정을 읽어오는 요청과, 여러 API를 엮어 여행 경비를 정산하는 요청을 같은 모델에 맡긴다고 생각해 보겠습니다. 사람으로 치면 전자는 인턴에게 맡겨도 되는 일이고, 후자는 경력이 있는 담당자가 봐야 하는 일인데, 운영에서는 둘 다 임원에게 결재를 올리는 셈입니다. 하나하나 보면 작은 낭비처럼 보이지만, 이 결정이 수천 번 반복되면 전력과 지연, 탄소가 그대로 쌓입니다.

문제는 그 낭비가 눈에 잘 띄지 않는다는 데 있습니다. 클라우드 모델은 어지간한 함수 호출을 다 잘 처리해 주니까, 겉으로는 실패가 없습니다. 그래서 운영자는 정확도 그래프만 보고 안심하는데, 그 뒤에서는 필요 이상으로 큰 연산이 매번 돌아가고 있습니다. 마치 가까운 거리를 갈 때도 매번 대형 버스를 부르는 것과 같은데, 버스가 정시에 오니까 누구도 버스 크기를 의심하지 않는 것이죠.

여기서는 조금 조심해서 읽을 필요가 있습니다. 이 이야기가 작은 모델이 무조건 충분하다는 뜻은 아니기 때문입니다. 함수 호출은 겉보기에 짧은 요청이라도 인자 구조가 까다롭거나, 도구 설명이 모호하거나, 여러 도구를 순서대로 엮어야 해서 작은 모델이 자주 미끄러지는 경우가 있습니다. 그래서 무작정 엣지로 보내면 정확도가 깨지고, 무조건 클라우드로 보내면 배출이 늘어나는 딜레마가 생깁니다. 이 딜레마를 쿼리 단위로 풀어보겠다는 것이 이 연구의 출발선입니다.

엣지와 클라우드를 세 층으로 나눈다는 발상은 무엇일까

이 연구가 제안하는 틀은 엣지와 클라우드를 묶은 3계층 구조 위에 서 있습니다. 가장 아래에는 가볍게 돌릴 수 있는 엣지 계층이 있고, 중간에는 그보다 조금 더 다룰 줄 아는 엣지 계층이 있으며, 맨 위에는 가장 복잡한 호출을 맡는 클라우드 계층이 있습니다. 각 계층 아래에는 서로 다른 하드웨어가 놓여 있어서, 같은 쿼리라도 어디에서 돌리느냐에 따라 지연과 전력 사용량이 달라집니다.

이런 구조를 처음 보면 단순히 모델 크기를 세 단계로 나눈 것처럼 보일 수 있습니다. 그런데 제가 이 논문에서 가장 눈여겨본 부분은 층을 나눈 자체보다 층마다 할 수 있는 일을 미리 가늠하겠다는 태도입니다. 큰 모델을 기본값으로 두는 대신, 각 쿼리에 대해 각 엣지 계층에서 성공할 가능성을 먼저 따져보고, 가능하다면 아래 계층에서 끝내겠다는 것이죠. 아래에서 처리할 수 있는 일을 아래에서 끝내면, 위로 올라가는 트래픽 자체가 줄어듭니다.

물론 구조만 나눈다고 문제가 풀리지는 않습니다. 관건은 매 쿼리마다 어느 층에서 될지를 어떻게 아느냐는 점인데요. 매번 세 계층을 다 돌려보고 고를 수는 없으니, 실행 전에 미리 예측하는 장치가 필요합니다. 그렇다면 예측 없는 분산은 그저 희망 사항에 그치지 않을까요. 연구진은 그 질문에 가벼운 예측기로 답합니다.

쿼리마다 난이도가 다르다는 당연한 사실을 어떻게 증명할까

생각해 보면 사람도 부탁의 난이도가 제각각이라는 것을 경험을 통해 압니다. 같은 함수 호출이라도 인자가 명확하고 도구가 하나면 쉽고, 인자가 중첩되고 도구가 여러 개면 어려워집니다. 이 논문은 그 당연한 사실을 라우팅의 근거로 끌어올립니다. 모든 쿼리를 같은 비용으로 취급하는 대신, 쿼리마다 필요한 자원과 성공 가능성이 다르다는 점을 전제로 깔고 시작합니다.

이 전제가 중요한 이유는 라우팅 단위를 바꾸기 때문입니다. 시스템 전체의 평균 난이도로 용량을 맞추는 방식에서는 쉬운 쿼리가 어려운 쿼리를 위해 준비된 큰 자원을 함께 쓰게 됩니다. 반면 쿼리 단위로 보면 쉬운 호출은 아래 계층에서, 어려운 호출은 위 계층에서 처리하는 식으로 나눌 수 있습니다. 평균으로 보면 보이지 않던 여유가 쿼리 단위로 보면 비로소 보이는 것이죠.

저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 함수 호출의 어려움과 자원 필요가 쿼리마다 크게 달라진다는 관찰이 있어야만, 매번 라우팅을 고민할 이유가 생기기 때문입니다. 만약 모든 쿼리가 비슷하다면 한 번 정한 규칙을 계속 쓰면 됩니다. 하지만 편차가 크다면 규칙이 아니라 매번 판단하는 장치가 필요합니다. 이 논문은 후자의 세계를 가정하고, 그 판단을 자동화하는 쪽으로 설계되어 있습니다.

답을 내기 전에 결과를 미리 짐작할 수 있을까

여기서 재미있는 질문이 생깁니다. 아직 실행하지도 않은 쿼리의 정확도와 지연, 전력 사용량을 미리 알 수 있을까요. 연구진이 꺼낸 답은 가벼운 k-NN 예측기입니다. 새로 들어온 쿼리를 임베딩 공간에 올려놓고, 과거에 처리했던 비슷한 쿼리들이 각 엣지 계층에서 어떤 결과를 냈는지를 주변 이웃에서 빌려오는 방식입니다.

이 방식을 동네 약국에 비유하면 이해가 쉬워집니다. 처음 보는 증상이라도 약사는 비슷한 증상을 가진 이전 손님들의 기록을 떠올려서 이 약으로 될지, 큰 병원으로 보내야 할지를 가늠합니다. k-NN 예측기도 이와 비슷하게 작동하는데, 새로 온 쿼리와 가까운 과거 쿼리들을 찾아서 그 쿼리들이 가벼운 계층에서 성공했는지, 얼마나 걸렸는지, 전력을 얼마나 썼는지를 모아 예측으로 삼습니다. 무거운 모델을 또 돌려서 판단하는 것이 아니라, 과거 기록을 뒤져서 가볍게 판단한다는 점이 이 설계의 매력입니다.

개인적으로는 이 선택이 운영 감각에 가깝다고 느꼈습니다. 매 요청마다 거대한 판단기를 돌리면 라우팅이 오히려 부담이 되는데, k-NN처럼 가벼운 장치는 라우팅 자체의 비용을 낮게 유지할 수 있기 때문입니다. 물론 이웃이 희박한 생소한 쿼리에서는 예측이 흔들릴 수 있습니다. 그래서 예측기의 정확도 자체보다 예측이 틀렸을 때의 대응이 함께 중요합니다. 이 논문은 그 예측을 다음 단계의 탄소 계산과 엮으면서, 틀릴 여지를 감안한 보수적인 선택으로 이어지게 만듭니다.

의미와 글자를 함께 보는 임베딩 공간은 왜 필요할까

그런데 이웃을 찾는다는 말은 쉽게 끝나지 않습니다. 함수 호출에서는 말의 뜻이 비슷해도 글자 수준에서 달라서 결과가 갈리는 경우가 많기 때문입니다. 예를 들어 도구 이름 하나, 인자 이름 하나가 다르면 호출 성패가 갈리는데, 의미만 보는 임베딩은 그 차이를 뭉개버릴 수 있습니다. 반대로 글자만 보면 같은 의도를 다르게 표현한 쿼리를 전혀 다른 것으로 취급하게 됩니다.

그래서 연구진은 의미와 어휘 정보를 함께 담은 통합 임베딩 공간을 씁니다. 뜻의 가까움과 글자의 겹침을 한 공간에서 함께 따지는 것이죠. 이렇게 하면 같은 일을 다르게 적은 쿼리는 가깝게 모이고, 비슷하게 생겼지만 다른 도구를 부르는 쿼리는 멀리 떨어집니다. 이웃의 질이 좋아지면 k-NN 예측의 질도 함께 좋아지는데, 이 연결이 생각보다 중요합니다. 라우팅의 성패가 결국 이웃을 얼마나 잘 고르느냐에 달려 있기 때문입니다.

저희가 새로운 AI 아키텍처를 볼 때도 벤치마크 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 이 통합 공간도 같은 잣대로 보면 이해가 됩니다. 임베딩을 조금 손본 것이 아니라, 라우팅이 참고하는 과거 기록의 검색 품질을 바꾸는 장치이기 때문입니다. 검색이 좋아지면 아래 계층에서 처리해도 되는 쿼리를 더 자신 있게 아래로 보낼 수 있고, 그만큼 클라우드로 올라가는 호출이 줄어듭니다.

탄소 강도를 라우팅 식에 넣으면 판단이 어떻게 달라질까

예측이 준비되었다면 이제 실제로 어디에 보낼지를 정해야 합니다. 이 연구의 라우팅은 예측된 성능과 전력에 실시간 그리드 탄소 강도를 곱해서 판단합니다. 같은 전력을 쓰더라도 전기가 깨끗한 시간과 더러운 시간의 배출은 다르기 때문에, 전력 예측만으로는 부족하고 지금 그리드가 얼마나 탄소를 내뿜는지를 함께 봐야 한다는 것이죠.

이 차이는 생각보다 큽니다. 전력만 보면 아래 계층이 항상 유리해 보이지만, 탄소 강도까지 함께 보면 선택이 시간에 따라 움직입니다. 그리드가 깨끗한 시간에는 조금 더 쓰는 선택도 감당할 수 있고, 그리드가 더러운 시간에는 아래 계층에서 간신히 되는 쿼리라도 아래로 붙잡아 두는 편이 배출 측면에서 이득이 됩니다. 다시 말해 라우팅이 고정된 규칙이 아니라, 그리드 상태에 따라 숨을 쉬는 결정이 되는 것입니다.

여기서 오해하기 쉬운 지점을 바로잡을 필요가 있습니다. 탄소 인식이라고 해서 무조건 엣지로 보내는 것이 아니라는 점입니다. 이 틀의 기준은 실행 가능한 가장 낮은 배출 계층을 고르는 것으로, 성공 가능성을 희생하면서 배출만 줄이는 방식이 아닙니다. 아래 계층에서 성공하기 어렵다고 예측되면 위로 올리는데, 그 판단에 탄소 강도가 함께 들어갈 뿐입니다. 그래서 정확도를 지키면서 배출을 줄이는 두 마리 토끼를 노릴 수 있습니다. 그렇다면 그 약속은 실제로 지켜졌을까요. 이제 측정 이야기로 넘어가 보겠습니다.

클라우드 정확도를 지키면서 배출을 4분의 1로 줄인다는 말의 뜻은

연구진은 최신 함수 호출 벤치마크와 여러 LLM 계열에 걸쳐 이 틀을 평가했고, 클라우드 수준의 정확도를 유지하면서 운영 탄소 배출을 평균 4배 줄였다고 보고합니다. 달리 말하면 같은 일을 하면서 배출은 4분의 1로 낮추었다는 것인데, 정확도를 깎아서 얻은 결과가 아니라는 점이 이 문장의 무게를 만듭니다.

이 숫자는 그대로 믿기 전에 조건을 봐야 합니다. 평균 4배라는 말은 모든 쿼리에서 같은 비율로 줄었다는 뜻이 아니라, 쉬운 쿼리에서 크게 아끼고 어려운 쿼리에서는 클라우드를 쓰면서 전체 평균을 낮추었다는 뜻에 가깝습니다. 쉬운 호출이 전체에서 차지하는 비중이 클수록 평균 절감은 커지고, 어려운 호출만 몰려 있는 워크로드에서는 절감이 작아질 수 있습니다. 그래서 이 결과는 라우팅이 만능이라는 선언이라기보다, 쿼리 분포에 따라 절감 폭이 달라지는 구조적 효과로 읽는 편이 맞습니다.

저는 여기서 멈칫했습니다. 4배라는 숫자가 크다 보니 배출 계산의 분모와 분자가 무엇을 포함한 것인지가 궁금해졌기 때문입니다. 논문이 말하는 것은 운영 단계의 탄소로, 라우팅으로 직접 줄일 수 있는 실행 전력에 그리드 강도를 곱한 부분입니다. 학습 비용이나 하드웨어 제조 과정까지 포함한 전 생애 배출이 아닙니다. 이 구분을 분명히 해야 오독이 없습니다. 운영 배출을 4분의 1로 낮추는 것만으로도 에이전트처럼 호출량이 많은 시스템에서는 상당한 절감이지만, 그 바깥의 배출까지 줄었다는 뜻은 아니기 때문입니다.

실제로 서빙한다면 어디에서 막힐까

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 이 라우팅을 운영에 올리면 어디에서 막힐까요. 저는 세 군데가 먼저 떠올랐습니다. 첫째는 예측기의 신선도입니다. 도구 설명이 바뀌거나 새로운 API가 추가되면 과거 이웃의 기록이 낡은 지도가 되는데, 그때 k-NN이 낡은 이웃을 계속 참고하면 아래 계층에서 실패가 늘어날 수 있습니다. 그래서 임베딩 기록을 얼마나 자주 갈아엎을지, 새로운 도구에 대한 콜드스타트를 어떻게 메울지가 운영의 숙제로 남습니다.

둘째는 이종 하드웨어의 측정 문제입니다. 각 계층의 지연과 전력은 같은 숫자로 비교하기 어려운데, 엣지 기기와 클라우드 가속기는 전력 측정 방식도 다르고 부하에 따른 변동도 다릅니다. 예측이 전력을 숫자로 뱉는다고 해도, 그 숫자의 오차가 계층마다 다르면 라우팅이 체계적으로 한쪽으로 기울 수 있습니다. 그래서 예측값을 그대로 쓰기보다 계층별 여유를 두고 보수적으로 해석하는 과정이 필요합니다.

셋째는 탄소 강도 신호의粒度가 아니라 입자입니다. 그리드 탄소 강도는 지역과 시간에 따라 바뀌는데, 실시간 신호를 어디에서 받아오고 얼마나 자주 갱신하느냐에 따라 라우팅의 움직임이 달라집니다. 신호가 너무 자주 바뀌면 라우팅이 출렁이고, 너무 뜸하면 배출이 많은 시간에 큰 모델을 쓰는 일이 생깁니다. 밤사이 배치 작업을 돌리는 팀이라면 이 신호의 주기가 곧바로 배출로 이어질 수 있습니다. 운영 측면에서 보면 이 세 가지는 논문의 바깥에 있지만, 도입을 결정할 때는 논문의 안만큼 중요해집니다.

남는 질문은 무엇이고 앞으로 무엇을 지켜봐야 할까

모든 연구에는 남는 질문이 있고, 이 논문도 예외가 아닙니다. 제가 앞으로 보고 싶은 것은 크게 세 가지입니다. 첫째, 예측이 틀렸을 때의 복구 경로입니다. 아래 계층에서 실패한 호출을 위로 다시 올리는 재시도 구조가 있다면 정확도는 더 단단해지지만, 그만큼 지연과 배출이 늘어납니다. 아래에서 먼저 시도하고 위로 올리는 폴백이 있는지, 아니면 한 번의 판단으로 끝내는지에 따라 실제 배출 절감은 달라질 수 있습니다.

둘째, 지연 제약이 있는 워크로드에서의 동작입니다. 배출만 보면 아래 계층이 유리해도, 실시간으로 답해야 하는 요청에서는 지연이 더 무서울 수 있습니다. 탄소와 지연을 함께 제약으로 놓고 보면 라우팅의 모양이 바뀌는데, 이 논문이 제시한 틀이 지연 상한을 만났을 때 어떻게 휘는지가 궁금합니다. 에이전트가 사람 앞에서 바로 답해야 하는 자리라면 배출보다 체감 속도가 먼저일 수 있기 때문입니다.

셋째, 더 많은 계층과 더 다양한 모델로의 확장입니다. 지금은 세 계층이지만, 실제로는 양자화된 작은 모델부터 긴 문맥에 강한 큰 모델까지 선택지가 더 많습니다. 선택지가 늘면 절감 여지도 커지지만, 예측해야 할 조합도 함께 늘어납니다. 이웃 기반 예측이 그 복잡도를 감당할 수 있을지, 아니면 계층이 늘수록 예측 오차가 먼저 커질지가 다음 관전 포인트입니다.

그렇다면 사람의 역할은 무엇일까요. 저는 이 논문을 읽고 나서 운영자의 질문이 바뀌어야 한다고 느꼈습니다. 어떤 모델이 가장 똑똑한지를 묻는 데서 멈추지 않고, 어떤 호출을 어디에서 처리해야 가장 적게 배출하면서도 일을 끝낼 수 있는지를 묻는 쪽으로 말이죠. 배출을 줄이는 일이 정확도를 깎는 일이 아니라 실행 장소를 고르는 일이 될 수 있다는 것, 그리고 그 선택을 쿼리마다 자동으로 할 수 있다는 것. 이 논문이 남긴 가장 구체적인 생각은 바로 그 한 줄입니다.