모델을 직접 다루지 말고 가상화하자는 제안이 던진 질문

Position: It is Time to Virtualize Foundation Models with a Self-evolving Operating System Layer는 arXiv에 공개된 position paper로 arXiv 번호 2609.19203으로 등록되어 있다. 원문 링크는 제목 아래에 걸어두었다.

이 글이 내세우는 주장은 하나의 문장으로 정리된다. 파운데이션 모델과 도구가 직접 맞붙는 지금의 구조 대신, 둘 사이에 가상화를 맡는 자기 진화 운영체제 층을 두어야 복합 에이전트 시스템을 이식 가능하고 다스리기 쉬운 형태로 만들 수 있다는 것이다. 이 글에서는 그 문제의식에서 출발해 지금 스택이 왜 흩어졌는지, 가상화가 무엇을 감추고 무엇을 남기는지, 그리고 운영 관점에서 무엇을 더 물어야 하는지를 차례로 따라간다.

모델 하나 잘 고르면 끝난다는 생각이 흔들린 순간

안녕하세요, 패트릭입니다.

예전에는 좋은 모델 하나를 고르는 일이 거의 전부처럼 느껴지던 때가 있었습니다. 어떤 모델을 쓸지 정하고, 프롬프트를 다듬고, 답이 좋아지면 배포하면 되는 흐름이었는데요. 그런데 요즘 제가 맡는 일을 돌아보면 그 순서가 잘 들어맞지 않습니다. 모델은 여전히 중요하지만, 모델 바깥에서 일어나는 일이 결과를 더 자주 바꾸기 때문입니다. 같은 모델을 써도 기억을 어떻게 넣느냐에 따라 답이 달라지고, 어떤 도구를 붙였느냐에 따라 할 수 있는 일이 달라지며, 예산과 가드레일을 어디에 걸었느냐에 따라 밤사이 운영이 조용할지 시끄러울지가 갈리죠.

그렇다면 무엇이 바뀐 걸까요. 응용이 단일 모델 호출에서 여러 요소가 얽힌 시스템으로 넘어갔기 때문입니다. 모델에 도구가 붙고, 도구에 기억이 붙고, 기억 위에 에이전트 흐름이 얹히면서 호출 한 번이 아니라 얽힌 과정 전체를 다뤄야 하게 됐는데요. 생각해보면 사람 조직도 비슷하게 변합니다. 처음에는 혼자 잘하는 사람이 중요하지만, 일이 커지면 혼자 잘하는 것만으로는 부족해지고 누가 기억을 관리하고 누가 결정을 검증하고 누가 예산을 보는지가 중요해집니다. 이 글에서 다룰 position paper가 흥미로웠던 이유도 여기에 있습니다. 모델 성능 이야기가 아니라, 모델 주변의 운영을 누가 맡을지에 대한 이야기였기 때문입니다.

저는 이 논문에서 가장 흥미롭게 본 부분은 진단을 에둘러 말하지 않았다는 점입니다. 각 프레임워크가 상태와 메모리와 예산과 가드레일을 자기 안에 몰래 넣어 두는 바람에, 겉으로는 비슷한 에이전트 코드가 실제로는 전혀 다른 기계 위에서 돈다고 말합니다. 그래서 이사 한 번 하려면 처음부터 다시 배워야 하는 구조가 됐다는 것인데요. 이 진단은 저에게는 꽤 아프게 들렸습니다. 저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 보는데, 이 논문은 그 비용 구조가 프레임워크 안에 숨어 있다는 점을 정면으로 짚었기 때문입니다.

프레임워크마다 숨어 있는 작은 운영체제를 꺼내 보면

여러 사람이 함께 일하다 보면, 각자 자기 수첩에 따로 일정을 적어두는 팀이 있습니다. 겉으로는 같은 회의에 앉아 있지만, 누가 무엇을 기억하고 누가 예산을 셌는지는 아무도 모르죠. 지금 에이전트 스택이 딱 그런 모양이라고 이 논문은 말합니다. LangChain이든 다른 에이전트 틀이든, 각 틀은 상태를 어디에 둘지, 기억을 언제 꺼낼지, 얼마까지 쓰게 둘지, 위험한 행동을 어디에서 막을지를 자기 방식대로 정해 두는데요. 코드로 보면 몇 줄의 호출처럼 보이지만, 그 아래에는 각기 다른 작은 운영체제가 숨어 있는 셈입니다.

문제는 그다음입니다. 작은 운영체제가 하나만 있으면 편합니다. 그런데 현실에는 여러 개가 동시에 있습니다. 한 팀은 A 틀에서 기억을 파일에 두고, 다른 팀은 B 틀에서 벡터 저장소에 두며, 예산을 세는 단위도 토큰일 때가 있고 호출 횟수일 때도 있으니까요. 그러다 보니 같은 요청을 같은 모델에 보내도 틀이 바뀌면 행동이 달라집니다. 기억을 길게 가져오는 틀에서는 답이 풍부해지고, 짧게 자르는 틀에서는 답이 가벼워지죠. 가드레일을 앞에서 거는 틀과 뒤에서 거는 틀은 실패하는 지점도 달라집니다. 결국 이식성이 깨지는데, 코드를 옮겼는데 행동이 안 옮겨지는 상태가 되는 것입니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 프레임워크가 나쁘다는 이야기가 아니기 때문입니다. 각 틀은 저마다 현장의 문제를 풀려고 최선을 다했습니다. 기억을 붙이는 법도, 도구를 부르는 법도, 중간에 멈추는 법도 그렇게 생긴 데에는 이유가 있습니다. 그런데 각자의 최선을 한데 모아놓고 보니 전체가 어긋나기 시작했는데요. 일종의 오답 노트처럼요. 처음에는 각자 답을 잘 적었는데, 나중에 모아보니 적는 방식이 달라서 서로의 노트를 못 읽는 상태가 된 것입니다. 저는 이 대목에서 논문의 시선이 모델이 아니라 틀 사이의 틈에 가 있다고 봅니다. 모델을 더 키우는 이야기가 아니라, 틀들이 각자 품은 운영 로직을 어디로 옮길지에 대한 이야기이기 때문입니다.

그렇다면 그 운영 로직을 그냥 두면 어떻게 될까요. 거버넌스가 약해집니다. 어디에서 무엇이 막혔는지, 누가 어떤 기억을 보고 판단했는지, 예산을 누가 얼마나 썼는지를 한눈에 말하기 어려워지기 때문입니다. 밤에 장애가 났을 때 원인을 찾는 일도 힘들어집니다. 모델이 잘못했는지, 기억이 오래됐는지, 도구가 막혔는지, 아니면 틀이 예산을 일찍 끊었는지를 가르는 것부터가 일이 됩니다. 운영 측면에서 보면 이 차이는 상당히 큽니다. 장애의 원인이 틀 안에 흩어져 있으면 고치는 사람도 흩어질 수밖에 없기 때문입니다.

연결이 쉬워졌는데 왜 이사는 여전히 어려울까

여기까지 읽고 MCP나 A2A를 떠올리신 분도 계실 것 같습니다. 실제로 이 논문도 두 프로토콜을 정면으로 언급하는데요. 도구를 붙이기 쉬워졌고 에이전트끼리 말을 붙이기도 쉬워졌다는 점은 인정합니다. 그런데 논문은 여기서 한 걸음 더 들어가서 묻습니다. 연결이 쉬워진 것과 행동이 옮겨지는 것은 다른 문제 아닌가요.

이 차이는 생각보다 중요합니다. 연결은 손을 잡는 일이고, 이식은 같은 방식으로 걷는 일이기 때문입니다. MCP로 도구를 붙이면 호출 모양은 같아지죠. 그런데 그 호출을 언제 하고, 그 결과를 기억에 어떻게 넣고, 얼마의 예산 안에서 몇 번까지 다시 시도할지는 여전히 틀마다 다릅니다. A2A로 에이전트를 이으면 메시지는 오가는데요. 그 메시지를 어떤 상태 위에서 해석하고, 어떤 정책으로 검증할지는 여전히 각자의 몫으로 남습니다. 그래서 플러그를 꽂는 일은 쉬워졌지만, 꽂은 뒤에 똑같이 행동하게 만드는 일은 여전히 어렵습니다.

비유를 들어보면 콘센트와 집안 살림의 차이와 비슷합니다. 콘센트 규격이 같아지면 어디서든 전기를 꽂을 수 있습니다. 그런데 냉장고에 무엇을 넣어둘지, 불을 언제 끌지, 가스 밸브를 누가 잠글지는 집마다 여전히 다릅니다. 프로토콜이 콘센트를 맞췄다면, 이 논문이 말하는 운영체제 층은 집안 살림의 규칙을 맞추자는 제안에 가깝습니다. 저는 이 구분이 논문을 읽는 데 도움이 된다고 봅니다. 프로토콜을 깎아내리는 것이 아니라, 프로토콜이 풀지 못한 층이 따로 있다는 점을 짚는 것이기 때문입니다.

그렇다면 그 남은 층은 무엇으로 채워야 할까요. 논문의 답은 새로운 프로토콜 하나가 아니라, 상호작용 자체를 감싸는 층입니다. 호출과 기억과 검증이 만나는 자리에 앉아서, 응용에게는 같은 얼굴을 보여주고 안쪽에서는 제각각인 현실을 다뤄주는 존재가 필요하다는 것입니다. 이 이야기는 마지막에 다시 다루겠습니다. 그 전에 가상화라는 말이 여기서 정확히 무엇을 뜻하는지부터 짚어야 합니다.

가상머신이 하드웨어를 감췄던 것처럼 모델을 감싼다는 뜻

가상화라는 말을 들으면 서버를 떠올리는 분이 많을 텐데요. 구체적으로 말하면 물리 기계 한 대 위에 가상의 기계를 여러 대 띄운 뒤, 각 가상 기계에게는 자기가 혼자 기계 전체를 쓰는 것처럼 느끼게 하는 기술이기 때문입니다. 그래서 응용은 아래에 어떤 CPU가 있는지, 메모리가 어떻게 나뉘어 있는지를 몰라도 되고, 그 복잡함은 중간 층이 통째로 흡수해줍니다. 이 논문이 제안하는 Foundation Model Operating System, 줄여서 FMOS도 바로 그 역할을 꿈꾸는데요. 다만 한 가지가 다른데, 여기서 감추는 대상이 하드웨어가 아니라 파운데이션 모델과의 상호작용이라는 점입니다.

표면적으로 보면 단순해 보이지만, 실제로 들여다보면 그렇지 않습니다. 하드웨어 가상화가 CPU 명령 같은 비교적 깨끗한 대상을 가리는 일이라면, 여기서의 가상화는 훨씬 더 질긴 대상, 즉 기억과 모델 선택과 검증이 서로 얽힌 과정 자체를 가려야 하기 때문입니다. 그래서 응용이 FMOS 위에 올라가면, 그 응용의 눈에는 믿을 수 있는 전용 모델이 하나 있는 것처럼 보여야 하고, 그 모델은 능력이 사실상 무한해 보이면서 필요할 때 알아서 기억을 꺼내고 알맞은 모델을 골라 쓰며 위험한 길은 미리 걸러주는 존재여야 합니다. 물론 안쪽을 열어보면 여러 모델과 여러 기억 저장소와 여러 도구가 함께 돌아가고 있지만, 바로 그 복잡함을 응용이 직접 만지지 않게 하겠다는 것이 이 제안의 방향입니다. 저는 이 대목에서 논문이 가상화를 꽤 야심 차게 다시 정의했다고 봅니다. 가리는 대상을 명령어에서 운영의 과정 전체로 넓혔기 때문입니다.

저는 여기서 잠깐 멈칫했습니다. 무한해 보인다는 표현이 자칫하면 과장처럼 들릴 수 있기 때문입니다. 하지만 실제로 무한한 자원이 생기는 것은 아닙니다. 다만 응용 개발자가 느끼는 체감이 달라진다는 뜻으로 읽으면 이해가 됩니다. 메모리가 어디에 있는지 몰라도 기억이 이어지고, 어떤 모델이 뒤에 있는지 몰라도 답의 수준이 유지되며, 정책이 어디에서 도는지 몰라도 같은 선에서 걸러진다면, 응용의 눈에는 한계가 멀리 밀려난 것처럼 보이니까요. 그리고 바로 그 느낌이 가상머신을 쓰는 사람이 물리 코어 수를 세지 않는 것과 같은 이치입니다.

여기서 재미있는 질문이 생깁니다. 바로 무엇을 감추고 무엇을 드러낼 것인가 하는 점인데요. 가상화는 무조건 감춘다고 좋은 것이 아니기 때문입니다. 그래서 저는 이렇게 나눠 봅니다. 다시 말해 감춰야 할 것은 배선이고, 드러내야 할 것은 손잡이라는 것입니다. 이 그림을 FMOS에 그대로 가져오면, 감춰야 할 배선은 어떤 기억 저장소에 무엇이 있고 어떤 모델이 몇 개 붙어 있는지 같은 것이고, 반대로 드러내야 할 설명은 지금 무엇을 근거로 판단했고 어디에서 왜 멈췄는지 같은 것입니다. 저는 이 구분이 앞으로 구현을 가를 것이라고 봅니다. 배선까지 드러내면 응용이 다시 무거워지고, 설명까지 감추면 운영이 다시 어두워지기 때문입니다.

믿을 수 있는 전용 모델처럼 보인다는 말을 풀어 보면

논문이 쓰는 표현 가운데 저를 가장 오래 붙잡은 것은 dedicated, trustworthy라는 말이었는데요. 전용이라는 말은 남과 섞이지 않는다는 뜻이고, 믿을 수 있다는 말은 근거를 댈 수 있다는 뜻이죠. 그런데 지금 모델 호출은 둘 다 어색합니다. 하나의 큰 모델을 여러 응용이 나눠 쓰면서 서로의 기억이 섞일까 봐 걱정해야 하고, 답이 어디에서 왔는지 설명하기도 어렵기 때문입니다. FMOS가 주겠다는 환상은 바로 이 두 불안을 가라앉히는 데 있습니다. 응용마다 자기 전용 모델이 있는 것처럼 느끼게 하고, 그 모델이 함부로 기억을 섞지 않고 정책을 어기지 않는 것처럼 느끼게 하겠다는 것입니다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 그 환상을 유지하는 비용은 누가 치를까요. 가상머신도 공짜가 아니었습니다. 중간 층이 들어가면 CPU를 조금 더 쓰고, 메모리를 조금 더 쓰며, 가끔은 느려집니다. 그 대신 얻는 것은 격리와 이식성입니다. FMOS도 마찬가지일 것이라고 저는 봅니다. 매 호출마다 기억을 고르고 모델을 고르고 검증을 거치면 당연히 오버헤드가 생깁니다. 그런데 그 오버헤드 덕분에 응용은 가벼워지고 운영은 단순해집니다. 저희가 새로운 AI 아키텍처를 볼 때도 같은 잣대를 댑니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 보는데요. 이 제안의 비용 구조는 호출당 계산이 아니라 운영당 안심에 가깝습니다. 매번 조금씩 더 쓰면서 장애와 이관의 큰 비용을 아끼는 구조입니다.

구체적인 장면을 하나 떠올려보겠습니다. 화요일 오후에 고객 지원 에이전트가 답을 내놓는다고 해보죠. 이 에이전트는 주문 기록과 과거 상담 기록과 제품 설명서를 함께 봐야 합니다. 지금 구조에서는 응용이 직접 세 저장소를 부르고, 결과를 이어 붙이고, 모델에 넣은 뒤, 답이 정책을 어겼는지 다시 확인해야 합니다. FMOS가 있다면 응용은 그냥 질문을 건네면 됩니다. 뒤에서는 운영체제 층이 기억을 고르고, 가벼운 질문인지 어려운 질문인지를 가린 뒤, 필요하면 검증을 한 번 더 돕니다. 응용의 코드는 짧아지고, 어려운 판단은 층이 맡게 됩니다. 물론 이 그림이 실제로 돌아가려면 층이 꽤 똑똑해야 합니다. 언제 끼어들지를 알아야 하기 때문입니다.

기억과 모델 고르기와 검증을 한곳에 모으는 이유

논문은 FMOS 안쪽의 일을 크게 세 갈래로 묶는데요. 기억을 여러 계층에 걸쳐 엮는 일, 어떤 모델을 골라 자원을 어떻게 나눌지 정하는 일, 그리고 검증과 정책을 집행하는 일입니다. 얼핏 보면 따로 놀아도 될 일들이지만, 왜 한곳에 모았을까요.

이유는 세 일이 서로의 답을 필요로 하기 때문입니다. 기억을 고르는 일은 모델을 고르는 일과 떨어질 수 없습니다. 길고 풍부한 기억을 꺼내면 작은 모델에는 넘치고 큰 모델에는 맞을 수 있습니다. 반대로 짧게 자른 기억은 작은 모델에는 맞지만 어려운 질문에는 부족합니다. 그래서 무엇을 기억할지는 무엇을 쓸지와 함께 정해야 합니다. 검증도 마찬가지인데요. 답을 내놓기 전에 막을지, 내놓은 뒤에 고칠지, 아니면 아예 다른 모델에게 다시 물을지는 기억의 출처와 모델의 성격을 알아야 정할 수 있습니다. 세 일을 나누면 각자는 빠르지만 사이에서 어긋나고, 모으면 조금 느리지만 전체가 맞아떨어지죠.

여기서 운영자의 언어로 바꿔 말하면 이렇습니다. 상태와 메모리와 예산과 가드레일이 각 틀에 흩어져 있을 때는 책임이 흩어집니다. 기억이 틀어지면 누구 탓인지, 예산이 터지면 누가 끊은 것인지 말하기 어렵습니다. 한 층에 모으면 책임이 모입니다. 기억 계층을 어떻게 엮을지, 어떤 질문에 어떤 모델을 붙일지, 어떤 정책으로 어디에서 막을지를 한곳에서 설명할 수 있기 때문입니다. 저는 그래서 이 세 갈래 묶음을 기능 목록이 아니라 책임 선언으로 읽었습니다. 무엇을 하겠다는 말이 아니라, 무엇을 책임지겠다는 말로 말입니다.

그런데 여기서 또 다른 질문이 생깁니다. 한곳에 모으면 너무 비대해지는 것 아닌가요. 운영체제가 모든 것을 하려다 느려지는 것 아닌가 하는 의심입니다. 논문은 이 의심을 피하지 않고, 그래서 스스로 진화하는 층이어야 한다고 말합니다. 항상 끼어드는 층이 아니라, 끼어들 때와 물러설 때를 배우는 층이어야 한다는 것인데요. 이 대목이 이 제안에서 가장 사람 냄새가 나는 부분이라고 저는 봅니다.

빠를 때는 놔두고 막힐 때만 끼어드는 법을 배우는 층

사람의 머릿속에는 빠른 직관과 느린 숙고가 함께 있다고 합니다. 익숙한 길에서는 깊이 생각하지 않고 바로 걷고, 낯선 갈림길에서는 멈춰서 지도를 펼칩니다. 논문은 FMOS의 개입 방식을 이 모습에 비유하는데요. 매번 다 따지고 들면 느려지고, 매번 그냥 통과시키면 위험해지니, 언제 끼어들지를 운영 경험에서 배우라는 것입니다. 저는 이 비유가 예쁘장한 장식이 아니라 설계의 방향을 정한다고 봅니다. 목표가 완벽한 검사가 아니라 알맞은 타이밍이기 때문입니다.

어떻게 배울 수 있을까요. 논문이 그리는 그림은 이렇습니다. 직접 통과시킨 추론이 잘 됐는지, 끼어들었던 판단이 실제로 도움이 됐는지를 운영 기록에서 되먹임받는 것입니다. 쉬운 질문에 괜히 무거운 검증을 붙였다면 다음에는 가볍게 가고, 어려운 질문을 그냥 통과시켰다가 사고가 났다면 다음에는 미리 잡는 식입니다. 처음에는 서툴 수 있지만, 같은 응용을 오래 돌릴수록 타이밍이 나아지는 층이 되는데요. 생각해보면 사람도 비슷하게 배웁니다. 신입 때는 매번 상사에게 물어보다가, 일이 익으면 혼자 처리하고 정말 막힐 때만 손을 듭니다. 층도 그렇게 익어간다는 발상입니다.

개인적으로 인상 깊었던 점은, 이 학습이 모델 가중치를 키우는 학습과 다르다는 것입니다. 모델을 더 똑똑하게 만드는 일이 아니라, 언제 모델을 믿고 언제 붙잡을지를 배우는 일입니다. 운전을 잘하는 것과 길눈이 밝은 것이 다른 것처럼요. 모델이 아무리 좋아져도 길눈이 없으면 같은 곳에서 헤맵니다. 반대로 길눈이 밝으면 모델이 바뀌어도 헤매는 폭이 줄어듭니다. 그래서 self-evolving이라는 말은 모델의 자가 진화가 아니라 층의 자가 진화로 읽혀야 합니다. 바뀌는 것은 지식이 아니라 타이밍입니다.

물론 여기에는 함정이 있습니다. 타이밍을 배운다는 것은 실패를 겪는다는 뜻이기 때문입니다. 언제 끼어들지를 알려면 한 번쯤 그냥 통과시켰다가 혼나봐야 합니다. 그렇다면 그 수업료를 누가 낼 것인가라는 질문이 남습니다. 실제 서비스에서 실패는 돈이고 신뢰인데, 그 비용을 감수하면서 층을 가르칠 수 있을까요. 논문은 position paper답게 이 운영의 디테일까지 풀어주지는 않는데요. 저는 이 빈칸이 앞으로의 논의를 가를 것이라고 봅니다. 시뮬레이션으로 미리 가르칠지, 그림자 모드로 옆에서 지켜보다가 투입할지, 아니면 작은 범위부터 넓혀갈지 같은 운영 전략이 필요하기 때문입니다.

이 제안이 설득되는 지점과 조심해서 읽을 지점

여기까지 오면 이 제안이 왜 매력적인지 분명해지는데요. 잠깐 속도를 늦추고 반대쪽도 함께 봐야 합니다. Position paper는 실험으로 증명하는 글이 아니라 방향을 주장하는 글이기 때문입니다. 숫자나 구현이 없다는 것은 약점이 아니라 장르의 성격이죠. 그렇다면 무엇을 믿고 무엇을 유보해야 할까요.

먼저 설득되는 쪽을 말하면, 진단 자체는 현장의 감각과 잘 맞습니다. 복합 에이전트 시스템이 늘면서 상태와 기억과 예산과 가드레일을 틀마다 따로 품는 구조가 실제로 지겹도록 반복됐기 때문입니다. 저도 비슷한 장면을 여러 번 봤습니다. 데모에서는 잘 되던 에이전트가 막상 다른 틀로 옮기면 기억을 못 읽거나, 예산 단위가 달라서 중간에 멈추거나, 정책 거는 위치가 달라서 통과될 답이 막히는 경우를 말입니다. 이런 경험을 가진 분이라면 가상화 층을 두자는 말에 고개를 끄덕이게 됩니다. 적어도 문제의 이름은 정확히 불렀다고 느끼기 때문입니다.

반면 조심할 지점도 분명합니다. FMOS가 만능열쇠처럼 읽히면 곤란하기 때문입니다. 모든 기억과 선택과 검증을 한 층이 맡는다고 해서 프레임워크 사이의 차이가 저절로 사라지는 것은 아닙니다. 각 틀의 암묵적 가정이 층의 인터페이스에 스며들면, 이번에는 층 자체가 새로운 잠금이 될 수 있습니다. 표준을 하나 더 만드는 일이 표준을 줄이는 일인지, 아니면 표준을 하나 늘리는 일인지 묻게 되는데요. 저는 이 질문을 가볍게 넘기면 안 된다고 봅니다. 운영체제가 정말 얇고 공정한 층으로 남을지, 아니면 또 하나의 두꺼운 틀로 굳을지는 설계가 아니라 거버넌스의 문제이기 때문입니다.

또 하나 짚을 것은 성능 이야기의 빈자리입니다. 오버헤드가 얼마나 될지, 지연이 어디에서 늘어날지, 처리량과 응답 속도가 어떻게 갈라질지에 대한 측정이 아직 없습니다. 중간 층이 매번 기억을 고르고 모델을 고르고 검증을 거치면, 호출은 당연히 무거워집니다. 그 무거움을 상쇄할 만큼 이관과 운영의 가벼움이 클지는 아직 보이지 않았습니다. 여기서는 조금 조심해서 읽을 필요가 있는데, 없다고 해서 틀렸다는 뜻이 아니기 때문입니다. 방향을 먼저 합의하고 측정은 뒤에 채우는 것이 position paper의 순서입니다. 다만 이 순서 때문에라도, 저는 이 글을 실험 결과가 아니라 설계 선언으로 읽었습니다. 증명이 아니라 초대장으로 말이죠.

운영자의 눈으로 보면 무엇이 달라질까

그렇다면 이 초대를 운영자의 자리에서 받아들면 무엇이 보일까요. 저는 밤사이 장애 대응 장면을 먼저 떠올렸습니다. 지금은 에이전트가 이상한 답을 내놓으면 원인을 찾는 일이 탐정 일과 비슷합니다. 모델이 헛다리를 짚었는지, 기억이 오래된 것을 꺼냈는지, 도구가 빈 답을 줬는지, 틀이 예산을 끊었는지를 하나씩 열어봐야 합니다. FMOS가 있다면 질문의 순서가 바뀝니다. 층이 남긴 기록을 먼저 보면, 무엇을 근거로 어떤 모델을 골랐고 어디에서 어떤 정책이 돌았는지가 한 줄기로 이어지기 때문입니다. 원인이 한곳에 모이면 고치는 손도 한곳에 모입니다.

이식성 이야기도 운영의 언어로 바꿔볼 수 있습니다. 응용을 다른 모델로 옮기거나 다른 도구 묶음으로 옮길 때, 지금은 코드를 뜯어야 하는 경우가 많습니다. 기억을 꺼내는 길이가 달라지고, 모델이 이해하는 지시 모양이 달라지며, 검증 거는 위치가 달라지기 때문입니다. 층이 그 차이를 흡수해주면 응용은 같은 얼굴을 보고 일할 수 있습니다. 물론 아래에서는 여전히 차이가 있습니다. 다만 그 차이를 응용이 아니라 층이 상대하게 되는데요. 이 차이는 생각보다 큽니다. 응용 개발자는 기능에 집중하고, 층을 맡은 사람은 운영에 집중할 수 있기 때문입니다. 일의 분담이 바뀌는 것입니다.

예산 이야기도 빼놓을 수 있는데요. 지금 예산은 틀마다 다른 단위로 셉니다. 토큰으로 세는 곳도 있고 호출로 세는 곳도 있으며, 기억을 꺼내는 비용을 따로 세지 않는 곳도 있습니다. 층이 생기면 예산을 한곳에서 같은 단위로 볼 수 있게 됩니다. 어떤 질문에 어떤 모델을 붙였을 때 얼마가 들었고, 검증을 한 번 더 돌리면 얼마가 추가되는지를 같은 표에서 말할 수 있습니다. 숫자는 조건이 같을 때만 말이 되는데, 층이 조건을 맞춰주기 때문에 숫자가 의미를 갖게 되는 것입니다. 저는 이 대목이 회계 장부 같다고 봤는데요. 장부가 있다고 돈이 아껴지는 것은 아니지만, 어디에서 새는지를 알아야 막을 수 있기 때문입니다.

다만 여기서도 물을 것은 남습니다. 층이 모든 것을 보면 층이 모든 것을 아는 구조가 되는데, 그 집중을 어떻게 다스릴 것인가. 기억의 출처와 정책의 판단과 예산의 흐름이 한곳에 모이면 편리하지만, 동시에 그곳이 가장 민감한 자리가 됩니다. 접근 권한을 누구에게 주고, 기록을 어디까지 남기고, 감사를 어떻게 받을지를 정해야 합니다. 거버넌스가 brittleness에서 벗어나려면, 층 자체의 거버넌스가 먼저 단단해야 하는데요. 저는 이 문제를 기술보다 운영의 문제로 봅니다. 좋은 층을 만드는 일만큼, 그 층을 믿고 맡길 수 있는 규칙을 만드는 일이 중요하기 때문입니다.

그래서 앞으로 무엇을 지켜보면 좋을까

앞에서 미뤄뒀던 질문으로 돌아올 차례입니다. 이 층은 실제로 어떻게 생겨야 할까요. 논문은 큰 그림을 그렸지만, 손에 잡히는 모양은 아직 비어 있는데요. 저는 그 빈칸이 오히려 다행이라고 봅니다. 빈칸이 있어야 다음 연구가 들어설 자리가 생기기 때문입니다.

제가 앞으로 보고 싶은 것은 세 가지입니다. 하나는 끼어듦의 타이밍을 배우는 구체적인 방법입니다. 운영 기록에서 무엇을 되먹임으로 쓸지, 실패의 수업료를 어떻게 줄일지를 보여주는 설계가 필요합니다. 그림자 모드로 옆에서 배우다가 투입되는 방식인지, 작은 범위에서 먼저 배우는 방식인지가 궁금합니다. 다른 하나는 기억 계층을 엮는 손놀림입니다. 어떤 기억을 어디에 두고 언제 꺼낼지, 오래된 기억과 Fresh한 도구의 답이 부딪힐 때 무엇을 믿을지를 정하는 규칙이 필요합니다. 밤사이 공시가 늦게 도착하거나 아침에 특정 도구가 느려져도 라인이 멈추면 안 되기 때문입니다. 나머지 하나는 층의 얇기를 지키는 법입니다. 층이 또 하나의 두꺼운 틀이 되지 않으려면, 무엇을 층에 넣고 무엇을 밖에 둘지에 대한 선이 분명해야 합니다.

이 논문이 흥미로운 이유는 답을 다 줘서가 아니라 질문의 자리를 옮겼기 때문입니다. 더 좋은 모델이 무엇인가에서 더 좋은 운영이 무엇인가로 말입니다. 질문도 바뀌었습니다. 좋은 프롬프트는 무엇인가에서 좋은 운영 층은 무엇인가로 말입니다. 앞으로 에이전트가 더 오래 일하고 더 많은 도구와 기억에 기대게 될수록, 모델 하나가 똑똑한지만 보는 것을 넘어 모델 사이에서 무엇이 오가고 어떻게 다스려지는지까지 함께 살펴봐야 할 것 같습니다.

그렇다면 사람의 역할은 무엇일까요. 층이 타이밍을 배우고 기억을 고르고 검증을 대신해도, 무엇을 믿을지와 어디까지 맡길지를 정하는 일은 여전히 사람의 몫으로 남습니다. 저는 그래서 이 제안을 기술의 끝이 아니라 운영의 시작으로 읽었습니다. 모델을 가상화하자는 말 뒤에는, 결국 우리가 어떤 실패는 기계에게 맡기고 어떤 판단은 사람에게 남길지에 대한 오래된 질문이 다시 놓여 있기 때문입니다.