시간을 지키는 AI 에이전트는 어떻게 만들까

On the Clock: Towards Punctual and Productive Time-Budgeted AI Agents라는 논문이 arXiv에 공개됐습니다 (arXiv:2610.10833). 작은 언어 모델 에이전트가 벽시계 시간으로 주어진 예산을 정확히 지키면서도 그 시간을 생산적으로 쓸 수 있는지를 묻는 연구입니다. 이 글에서는 그 질문이 왜 어려웠는지, 하네스와 학습이 무엇을 바꿨고 무엇을 바꾸지 못했는지를 그 순서대로 풀어냅니다. 원문 논문으로 이어지는 링크는 제목 아래에 붙어 있습니다.

제가 이 논문을 처음 펼쳤을 때 솔직히 기대는 크지 않았습니다. 시간 예산이라니, 프롬프트 첫 줄에 마감 시간을 적어주면 되는 것 아닌가 싶었기 때문입니다. 그런데 읽다 보니 생각이 바뀌었습니다. 이 문제는 지시를 따르는 문제가 아니라 감각의 문제에 가까웠습니다. 에이전트는 시간을 말로는 듣지만 몸으로는 느끼지 못하고 있었습니다.

약속 시간을 매번 넘기는 에이전트를 본 적 있으신가요

여러 사람이 함께 일하다 보면 마감에 강한 사람과 약한 사람이 금방 드러납니다. 마감에 강한 사람은 중간중간 시계를 보고 일의 속도를 조절하는데, 마감에 약한 사람은 그렇지 못하죠. 그렇다면 AI 에이전트는 어떨까요? 주어진 시간을 지키면서도 그 안에서 제 할 일을 다 하는 에이전트는 어떻게 만들 수 있을까요?

이 논문이 던진 출발점도 바로 여기였습니다. 연구진은 작은 모델 에이전트가 명시적인 wall-clock 시간 예산 아래에서 제대로 동작할 수 있는지를 물었습니다. 여기서 시간 예산이란 토큰 개수가 아니라 실제 흐르는 시간을 말합니다. 몇 분 안에 끝내라는 요구는 우리에게는 익숙하지만, 에이전트에게는 낯설 수 있습니다. 모델은 토큰을 세는 데는 익숙해도 초와 분을 느끼는 기관이 따로 없기 때문입니다.

평가 무대도 두 갈래로 나뉩니다. 한쪽에서는 Qwen3.6-27B가 MLE-Bench Lite에 담긴 다섯 개 competition에서 머신러닝 엔지니어처럼 코드를 짜고 실험을 돌립니다. 다른 쪽에서는 Qwen3-4B가 Jericho로 실행되는 Zork I이라는 텍스트 어드벤처 게임에서 미로를 헤맵니다. 한쪽은 현실의 엔지니어링 작업이고, 다른 쪽은 통제된 게임 환경입니다. 저는 이 구성이 마음에 들었습니다. 현실적인 작업에서의 행동과 학습이 잘 관찰되는 환경에서의 행동을 함께 보면, 시간이라는 변수가 어디에서 다르게 작용하는지가 드러나기 때문입니다.

프롬프트에 시간을 적어주면 될 줄 알았죠

가장 단순한 설정부터 떠올려 보겠습니다. 프롬프트에 이번 작업은 30분 안에 끝내라고 적어주는 방식입니다. 사람에게는 꽤 자연스러운 지시인데, 이 논문의 관찰에 따르면 에이전트는 이 지시를 실제 시간 사용으로 옮기지 못했습니다. 말로는 예산을 들었지만 몸은 예산을 몰랐던 셈입니다.

왜 그럴까요? 저는 여기서 멈칫했습니다. 지시 따르기에 능한 모델이 왜 시간 앞에서만 유독 어설픈지 궁금했기 때문입니다. 연구진이 짚은 이유는 크게 세 가지였습니다. 첫째, 하네스에서 시간 피드백이 오지 않았다는 점입니다. 에이전트는 지금 몇 분이 지났고 몇 분이 남았는지를 실행 중에 전달받지 못했습니다. 둘째, 행동마다 걸리는 시간을 미리 가늠하지 못했다는 점입니다. 코드를 한 번 돌리면 몇 분이 걸릴지, 파일을 몇 개 읽으면 얼마나 소모될지를 예측하는 감각이 없었던 것입니다. 셋째, 시간과 전략을 연결하는 학습된 대응이 없었다는 점입니다. 시간이 넉넉할 때와 빠듯할 때 일을 다르게 배치하는 요령이 몸에 배어 있지 않았던 것이죠.

생각해보면 사람도 비슷하게 배웁니다. 처음 아르바이트를 하면 한 주문을 처리하는 데 몇 분이 걸리는지 모르다가, 몇 번 해보고 나서야 감이 생기죠. 에이전트에게는 그 몇 번의 경험과 중간중간 알려주는 시계가 모두 빠져 있었던 것입니다. 그래서 프롬프트에 적힌 시간은 달력에 적힌 다짐처럼 남게 됩니다. 보고는 있지만 행동을 바꾸지는 못하는 문구였던 셈입니다.

시계가 안 보이는 주방에서 일하기

앞선 세 가지 이유를 조금 더 들여다보고 싶습니다. 저는 이 대목이 논문에서 가장 현실적으로 읽혔기 때문입니다. 시간 피드백이 없다는 것은 주방에 시계가 없다는 것과 같습니다. 요리를 하면서 지금 몇 분이 지났는지 모르면 불 조절도 물 양 조절도 감으로 할 수밖에 없죠. 에이전트가 하네스로부터 경과 시간이나 남은 시간을 듣지 못한다는 것은 바로 그 상태였습니다.

행동의 소요 시간을 예측하지 못한다는 문제는 한 걸음 더 깊습니다. 머신러닝 실험에서는 작은 스크립트 하나가 몇 초 만에 끝날 수도 있고, 학습 루프 하나가 수십 분을 먹을 수도 있습니다. 사람은 몇 번 데여보고 나면 무거운 셀과 가벼운 셀을 구분하는데, 에이전트는 그런 구분 없이 다음 행동을 골랐습니다. 그래서 시간을 아껴야 할 때 오히려 무거운 행동을 먼저 집어 드는 일이 생겼던 것입니다.

세 번째 이유인 전략 대응의 부재는 앞의 두 가지와 이어집니다. 시간이 10분 남았을 때와 2시간 남았을 때 같은 일을 시키면 사람은 계획을 달리 짭니다. 10분이 남았으면 검증을 줄이고 제출 가능한 상태를 먼저 만드는데, 에이전트는 그런 전환을 배우지 못했습니다. 이 차이는 생각보다 중요합니다. 시간 예산 연구가 토큰 예산 연구와 다른 지점이 바로 여기이기 때문입니다. 토큰은 셀 수 있지만 시간은 흘러가고, 흘러가는 것에 맞춰 계획을 바꾸는 일은 별도의 감각을 요구합니다.

벽에 시계를 걸어주자 벌어진 일

그렇다면 시계를 걸어주면 어떻게 될까요? 연구진은 하네스를 통해 타이밍 정보를 직접 넣어주는 방식을 시험했습니다. 에이전트가 실행 중간에 지금 얼마나 지났고 얼마나 남았는지를 듣게 만든 것입니다. 결과는 Qwen3.6-27B가 치른 MLE-Bench Lite 다섯 개 competition에서 꽤 분명하게 나타났습니다. 예산을 지키는 정도가 크게 좋아졌는데, 작업 성능이 눈에 띄게 떨어지지는 않았던 것입니다.

저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 타이밍 정보를 준다는 것은 단순히 문장을 추가하는 일이 아니라 에이전트와 환경 사이의 통로를 하나 더 여는 일이기 때문입니다. 프롬프트는 출발선에서 한 번 들려주는 주의사항에 가깝지만, 하네스의 피드백은 달리는 중에 옆에서 불러주는 중간 기록에 가깝습니다. 출발선에서의 다짐보다 달리는 중의 페이스메이커가 훨씬 도움이 된다는 점은 운동을 해본 분이라면 바로 이해하실 겁니다.

다만 여기서 조심해서 읽을 필요가 있습니다. 예산을 더 잘 지켰다는 말이 일을 더 잘했다는 말과 같은 것은 아닙니다. 이 실험에서 성능이 떨어지지 않았다는 것은 다행스러운 일이지만, 그렇다고 시간이 생산적으로 쓰였다는 증거까지는 아닙니다. 마감 안에 들어온 것과 그 안에서 좋은 선택을 한 것은 다른 층위의 문제이기 때문입니다. 이 구분은 뒤에서 다시 중요해집니다. 그럼에도 하네스를 통한 타이밍 주입이 비용 없이 준수를 끌어올렸다는 점은 실무적으로 꽤 쓸모 있습니다. 모델을 다시 학습시키지 않고도 시스템 쪽 손질만으로 시간을 지키게 만들 여지가 열린 셈이니까요.

그래도 넘치면 문을 닫는 방법

타이밍 정보를 줘도 예산을 가끔 넘기는 경우가 남습니다. 듣는 것과 멈추는 것은 다른 근육이기 때문입니다. 그래서 연구진은 데드라인을 강제하는 enforcement hook을 함께 시험했습니다. 일정 시간이 되면 작업을 정리하고 마무리로 넘기는 갈고리를 하네스에 걸어둔 것입니다.

이 갈고리가 들어가자 예산 준수는 타이밍 정보만 줄 때보다 한층 더 단단해졌습니다. 저는 이 장치를 밤샘 공부를 막기 위해 도서관 불을 끄는 것에 비유하고 싶습니다. 의지가 아니라 구조가 멈춤을 만드는 방식이죠. 에이전트가 스스로 판단해서 멈추는 일에만 기대지 않고, 환경이 멈춤을 보장하는 쪽으로 설계를 옮긴 것입니다.

여기서 재미있는 질문이 생깁니다. 강제로 멈추게 하면 작업 품질이 깨지지 않을까요? 이 논문의 맥락에서 보면 강제 종료는 실패가 아니라 규칙입니다. 정해진 시간 안에 제출 가능한 상태를 만드는 것 자체가 능력의 일부이기 때문입니다. 물론 강제 후크가 만능은 아닙니다. 중간에 뚝 잘리면 아까운 시도가 버려질 수도 있고, 마무리를 서두르느라 검증이 얇아질 수도 있습니다. 하지만 운영 측면에서 보면 예측 가능성이 생긴다는 점이 큽니다. 언제 끝날지 모르는 작업과 언제 끝날지 아는 작업은 스케줄을 짜는 사람에게 완전히 다른 대상이기 때문입니다.

게임 속에서 시간을 몸으로 익힌 에이전트

이제 무대를 Zork I로 옮겨보겠습니다. 여기서 등장하는 모델은 Qwen3-4B이고, 학습 방법은 GRPO를 이용한 강화학습입니다. 미로 같은 텍스트 게임에서 에이전트는 명령을 입력하고, 방을 이동하고, 물건을 줍고, 점수를 쌓습니다. MLE-Bench의 엔지니어링 작업보다 단순해 보이지만, 시간을 배우기에는 오히려 좋은 교실입니다. 같은 구조가 반복되고 보상이 분명해서 시간과 행동의 관계가 더 잘 드러나기 때문입니다.

결과는 꽤 인상적이었습니다. GRPO로 학습한 에이전트는 Zork I에서 거의 완벽에 가까운 예산 준수를 보여줬습니다. 정해진 시간이 되면 일을 마무리하는 행동이 몸에 밴 것입니다. 말로만 듣던 시간을 몸으로 익힌 셈이죠. (참고로 GRPO는 여러 시도 가운데 상대적으로 나은 선택을 골라 강화하는 방식인데요. 시간 예산처럼 분명한 규칙이 있을 때 이런 상대 평가가 잘 맞는 경우가 많습니다.)

저는 여기서 한 가지 더 눈여겨봤습니다. 학습이 끝난 뒤 처음 보지 못한 held-out 예산에서도 준수가 이어졌다는 점입니다. 예를 들어 짧은 예산과 긴 예산 몇 가지만으로 학습했는데, 중간 길이의 새로운 예산에서도 시간을 맞췄다는 뜻입니다. 외운 시간을 맞춘 게 아니라 시간이라는 변수 자체에 반응하는 법을 익혔다는 신호로 읽힙니다. 게임이라는 작은 교실에서 배운 감각이 다른 시간표에도 통했다는 점은 분명히 고무적입니다. 그렇다면 이제 남은 질문은 하나입니다. 시간을 지키는 법을 배운 에이전트는 그 시간으로 더 좋은 결과를 만들까요?

처음 보는 시간표에서도 통할까

앞선 장면을 조금만 더 밀고 들어가 보겠습니다. held-out 예산에서의 일반화는 왜 중요할까요? 실제 운영에서는 예산이 매번 달라지기 때문입니다. 어떤 작업은 15분이 주어지고, 어떤 작업은 두 시간이 주어집니다. 매번 새로운 예산마다 다시 학습시킬 수는 없으니, 본 적 없는 예산에서도 스스로 조절하는 능력이 있어야 실용성이 생깁니다.

연구진이 보고한 대로 Zork I에서 학습된 에이전트는 그런 전환에 꽤 잘 대응했습니다. 학습 때 보지 못한 길이의 예산이 주어져도 지나치게 일찍 멈추거나 늦게 멈추지 않고 예산 근처에서 마무리했습니다. 이 대목은 강화학습이 단순히 특정 숫자를 외운 것이 아니라는 점을 보여줍니다. 시간이라는 입력이 달라지면 행동의 배치도 함께 달라지는 대응 관계가 어느 정도 형성됐다는 뜻이기 때문입니다.

하지만 이 일반화를 너무 크게 해석해서는 안 됩니다. 게임 환경은 행동의 종류가 제한적이고 한 행동의 비용도 비교적 일정합니다. 반면 머신러닝 엔지니어링에서는 행동 하나의 비용이 들쭉날쭉합니다. 그래서 게임에서 통했던 감각이 현실 작업에서도 그대로 통할지는 별개의 문제로 남습니다. 저는 그래서 이 결과를 가능성을 보여준 사례로 읽었습니다. 시간에 반응하는 정책이 학습될 수 있다는 증거로는 충분하지만, 그 정책이 어떤 환경까지 옮겨갈 수 있는지는 아직 열려 있는 질문이기 때문입니다.

시간을 지켰는데 일은 그대로라면

이제 논문에서 가장 곱씹을 만한 대목으로 넘어갑니다. MLE-Bench 쪽에서 예산을 의식한 보상으로 강화학습을 시켰을 때, 작업 성능은 학습하지 않은 하네스보다 나아지지 않았다는 관찰입니다. 시간을 지키는 쪽은 좋아졌는데, 일을 더 잘하는 쪽은 그대로였다는 뜻입니다. punctuality는 올랐지만 productivity는 그대로였던 셈입니다.

표면적으로 보면 아쉬운 결과입니다. 실제로는 그렇지 않습니다. 이 둘을 구분했다는 점 자체가 성과이기 때문입니다. 지금까지 많은 논의는 시간을 지키면 생산성도 따라올 것처럼 말했지만, 이 실험은 그 연결이 자동으로 성립하지 않는다는 것을 보여줬습니다. 마감 안에 들어오는 것과 마감 안에서 좋은 결정을 내리는 것은 다른 능력입니다. 전자는 멈춤의 문제이고, 후자는 선택의 문제이기 때문입니다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 생산적인 시간 사용이란 무엇으로 측정할 수 있을까요? 제출 점수만으로 충분할까요, 아니면 중간 과정의 탐색 효율까지 함께 봐야 할까요? 논문이 남긴 문장도 이 간극을 가리킵니다. 시간을 지키는 것과 시간을 알뜰히 쓰는 사이의 거리가 예산 조건부 에이전트의 남은 과제라는 것입니다. 저는 이 솔직한 구분이 오히려 신뢰를 줬습니다. 잘된 것만 부풀리지 않고 안 된 부분을 정확히 짚었기 때문입니다.

짧은 시간 버릇이 긴 시간을 삼킬 때

여러 예산을 함께 학습시키면 어떻게 될까요? 상식적으로는 각 예산에 맞는 전략이 각각 생길 것 같습니다. 짧을 때는 짧게, 길 때는 길게 일하는 법을 따로 익히겠죠. 그런데 연구진이 본 현상은 그 기대와 달랐습니다. 여러 예산으로 GRPO 학습을 시키면 에이전트는 가장 짧은 예산에서 배운 전략 쪽으로 기울었고, 남는 시간은 같은 행동을 반복하면서 채우는 경향이 있었습니다.

이 장면은 꽤 사람 같습니다. 바쁜 학기를 보낸 학생이 방학에도 바쁜 학기처럼 군다고 할까요. 몸에 밴 짧은 리듬이 긴 시간을 삼켜버리는 것입니다. 에이전트도 짧은 예산에서 통했던 빨리 끝내기 전략을 긴 예산에서도 그대로 썼고, 추가로 주어진 시간은 새로운 탐색이 아니라 반복으로 메웠던 셈입니다.

왜 이런 일이 생길까요? 가능한 설명은 짧은 예산의 행동이 보상을 빨리 가져오기 때문에 학습 초기에 강하게 자리 잡는다는 것입니다. 일단 자리 잡은 습관은 긴 예산에서도 깨기 어렵습니다. 길게 탐색해서 더 좋은 결과를 내는 경로는 보상이 늦게 오고 불확실하기 때문입니다. 그래서 에이전트는 안전한 반복을 택합니다. 여기서 교훈은 분명합니다. 예산을 여러 개 섞는다고 해서 각 예산에 맞는 전략이 자동으로 생기지는 않습니다. 시간에 따라 전략을 바꾸는 법을 따로 가르치지 않으면, 학습은 가장 쉬운 해 쪽으로 미끄러집니다.

그래서 운영팀은 무엇을 준비해야 할까

그렇다면 이 흐름을 실제 운영에 어떻게 옮길 수 있을까요? 저희가 새로운 AI 아키텍처를 볼 때도 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 이 논문도 같은 잣대로 읽으면 할 일이 꽤 분명해집니다.

첫째, 하네스에 시계를 다는 일입니다. 에이전트에게 남은 시간을 주기적으로 알려주고, 행동의 예상 소요 시간을 함께 전달하는 것만으로도 준수는 크게 좋아질 수 있습니다. 모델을 바꾸지 않고 시스템 쪽에서 할 수 있는 개선이라는 점이 매력적입니다. 둘째, 데드라인 강제 장치를 두는 일입니다. 에이전트의 자율 판단에만 맡기지 말고, 예산이 다 되면 정리와 제출로 넘어가는 경로를 하네스가 보장해야 합니다. 셋째, punctuality와 productivity를 따로 재는 일입니다. 마감 준수율과 작업 점수를 같은 표에 두되 같은 것으로 착각하지 말아야 합니다. 시간을 지켰는데 점수가 그대로라면 다음에 손봐야 할 곳은 멈춤이 아니라 선택이기 때문입니다.

제가 앞으로 보고 싶은 것은 시간에 따라 전략을 바꾸는 법을 가르치는 연구입니다. 짧을 때는 빨리 제출 가능한 상태를 만들고, 길 때는 탐색과 검증을 넓히는 식의 전환 말입니다. 여러 예산을 섞는 것만으로는 부족하다는 것이 이번에 드러났으니, 예산 길이에 따라 보상을 다르게 주거나 중간 평가를 넣어주는 설계가 필요할지 모릅니다. 게임에서 배운 감각을 엔지니어링 작업으로 옮기는 연구도 궁금합니다. Zork I에서 통했던 시간 감각이 MLE-Bench 같은 들쭉날쭉한 환경에서도 살아남을지, 아니면 새로운 장치가 필요할지 지켜볼 일입니다.

시간을 지키는 에이전트와 시간을 잘 쓰는 에이전트는 다른 존재입니다. 이 논문은 전자를 만드는 법을 꽤 구체적으로 보여줬고, 후자가 아직 남았다는 것을 솔직하게 남겼습니다. 그래서 저는 이 연구를 도착이 아니라 출발로 읽었습니다. 시계를 달고, 문을 닫는 법을 배우고, 이제는 그 안에서 무엇을 할지를 가르칠 차례니까요. 그렇다면 여러분이 운영하는 에이전트에게 지금 가장 먼저 달아주고 싶은 시계는 어떤 모습인가요.