나에게 맞는 병렬 에이전트 한계치 찾기

에이전트를 더 많이 돌린다고 해서 내가 더 많아지는 건 아닙니다. 요즘 에이전틱 엔지니어링(agentic engineering) 담론은 여전히 처리량과 병렬화 이야기가 대부분입니다. 그런데 루프 안에 있는 인간에게 실제로 어떤 비용이 발생하는지에 대해서는 거의 아무도 말하지 않습니다. 동시에 여러 문제 컨텍스트를 머릿속에 붙들어야 하고, 쉼 없이 판단을 내려야 하며, 어느 에이전트가 조용히 잘못된 방향으로 가고 있을지 모른다는 불안을 고스란히 떠안아야 합니다.

이것은 아직 마땅한 언어가 없는, 새로운 형태의 인지 노동입니다.

Simon Willison이 Lenny Rachitsky와의 최근 대담에서 한 말이 떠오릅니다. 에이전트 네 개를 동시에 띄우고 오전 11시까지 일하면 그날 하루가 완전히 방전된다고 했습니다. 맞는 말입니다. 컴퓨팅 확장에 대한 직관은 한 세기에 걸쳐 쌓여왔지만, 다섯 개의 문제 컨텍스트를 동시에 머릿속에 붙들고 모든 스레드에서 끊임없이 판단을 내린다는 게 어떤 느낌인지에 대한 감각은 거의 없습니다. 그 부담은 서서히 축적되다가, 낮 12시도 안 됐는데 이미 녹초가 되어 어느 스레드에서 일이 어긋났는지도 파악이 안 되는 지경이 되어서야 깨닫게 됩니다.

저는 에이전트 오케스트레이션의 매니지먼트 모델에 대해, 즉 비동기 엔지니어링 팀을 운영하듯 브리프와 위임 패턴, 검증 루프를 갖춰 병렬 세션을 관리하는 방식에 대해 글을 써왔습니다. 그런데 그 프레임은 주로 조직적인 오버헤드를 다루고 있습니다. 이 글에서 이야기하고 싶은 건 개인적인 오버헤드입니다. 오롯이 나 자신 안에서 벌어지는 그 부분입니다.

병렬 에이전트가 실제로 나에게 요구하는 것

에이전트 하나와 작업할 때는 인지 모델이 비교적 단순합니다. 활성 컨텍스트 하나, 의사결정 흐름 하나, 평가할 출력 스트림 하나. 깊이 파고들 수 있고, 방향이 틀어지는 것도 바로 알아챌 수 있습니다.

네 개를 동시에 실행하면 질적으로 다른 일을 하게 됩니다. 같은 작업을 네 번 하는 게 아니라, 완전히 다른 멘탈 모델 네 개를 동시에 관리하는 겁니다. 네 개의 서로 다른 코드베이스, 네 개의 서로 다른 문제 프레이밍, 네 개의 서로 다른 신뢰 조정값, 그리고 "이게 얼마나 조용히 잘못되고 있을까?"에 대한 네 개의 서로 다른 추정치를 동시에 붙들어야 합니다.

마지막 항목이 가장 과소평가되는 부분입니다. 병렬 에이전틱 작업이 피로한 이유는 상당 부분 능동적인 인지 활동 때문이 아닙니다. 배경 경계심 때문입니다. 20분째 확인하지 못한 스레드에서 뭔가 잘못되고 있을지 모른다는 것을 알기에 완전히 긴장을 풀지 못하는, 마음 한켠의 그 감각입니다. 저는 이것을 '상시 불안세(ambient anxiety tax)'라고 부릅니다. 할 일 목록에는 나타나지 않지만, 다른 모든 것과 같은 에너지 저장소에서 조금씩 빠져나갑니다.

이것은 제가 이해 부채(comprehension debt)에 대해 쓴 내용과 연결됩니다. 에이전트가 우리가 이해할 수 있는 속도보다 빠르게 생성하도록 내버려두면 부채가 쌓입니다. 단일 세션에서는 그 부채가 어느 정도 경계 안에 머뭅니다. 그런데 병렬 세션에서는 여러 스레드에 걸쳐 동시에 복리로 불어나고, 어느 스레드에서 가장 많은 부채가 쌓이고 있는지도 가늠하기 어렵습니다.

부담이 실제로 어디에 쌓이는가

먼저 컨텍스트 전환이 있는데, 겉으로 보이는 것보다 비용이 훨씬 큽니다. 에이전트 간에 이동한다는 건 멘탈 모델을 다시 불러오는 것을 의미합니다. 이 태스크가 어디서 시작됐는지, 에이전트가 어떤 접근 방식을 택했는지, 30분 전에 내가 내린 결정 중 현재 허용 범위를 제한하는 것은 무엇인지를 다시 파악해야 합니다. 태스크 전환에 관한 연구들은 일관되게 같은 결론을 보여줍니다. 비용은 전환 자체에 있는 게 아니라 회복 시간에 있습니다. 병렬 스레드가 네 개라면 그 비용을 끊임없이 치르게 되고, 다음 전환이 일어나기 전에 회복이 완전히 이루어지는 경우는 거의 없습니다.

다음으로 판단 호출이 있는데, 이것은 묶어서 처리하거나 미룰 수가 없습니다. 에이전트 수를 늘리기 시작했을 때 이 부분이 의외였습니다. 병렬 에이전트가 백그라운드에서 작업을 처리해줌으로써 나의 여유를 확보해줄 거라고 기대했고, 실제로 그런 면도 있습니다. 하지만 동시에, 판단을 요구하는 순간들이 쉬지 않고 끼어들기도 합니다. 이 접근 방식이 우리 아키텍처 원칙에 맞는가? 이 스레드를 멈추고 방향을 바꿔야 하는가? 이 오류는 수정 가능한 것인가, 아니면 근본적으로 방향이 틀어졌다는 신호인가? 이런 질문들은 이메일처럼 큐에 쌓아두고 나중에 한꺼번에 처리할 수 없습니다.

그리고 신뢰 조정 오버헤드가 있는데, 이것은 문제가 드러나기 전까지는 보이지 않습니다. 모든 에이전트 세션에는 동적이고 암묵적인 신뢰 조정이 따라붙습니다. 처음에는 꼼꼼히 지켜봅니다. 세션이 잘 흘러가는 중반쯤에는 좀 더 자율성을 줍니다. 그런데 이 조정값은 각 스레드마다 별도로 유지해야 하고, 제가 지켜보지 않는 사이에 조금씩 흐릿해집니다. 어느 스레드에 얼마큼의 신뢰를 주고 있었는지 파악이 안 된다는 것을 깨닫는 순간, 그 스레드가 생성한 모든 것을 처음부터 다시 읽어야 합니다. 생산적인 오전이 소진되는 오전으로 바뀌는 건 대개 그때입니다.

에이전트를 늘린다고 선형적으로 확장되지 않는 이유

병렬로 에이전트를 돌릴 때는 솔깃한 계산이 가능합니다. 에이전트 하나가 40분에 기능 하나를 완성할 수 있고 네 개를 동시에 돌리면, 같은 시간에 기능 네 개가 나와야 합니다. 처리량만 따지면 맞는 말입니다. 그런데 인간에게는 맞지 않습니다.

나의 인지 대역폭은 병렬화되지 않습니다. 에이전트는 생성을 담당합니다. 평가하고, 결정하고, 신뢰하고, 통합하는 일은 여전히 전부 내가 합니다. 이것들은 루프에서 내 쪽에 있는 단일 스레드 작업입니다.

확장되는 건 감독의 처리량이지, 이해의 처리량이 아닙니다. 깊이 이해할 수 있는 것보다 더 많은 에이전트를 감독할 수는 있습니다. 하지만 이해 없는 감독이야말로 이해 부채가 자라는 곳입니다. 코드는 배포되지만, 내가 무엇을 만들었는지에 대한 멘탈 모델은 스레드가 하나 늘어날 때마다 점점 더 뒤처집니다.

그래서 코드 에이전트 오케스트라 프레임에서 제시한 지휘자 비유가 여전히 유효합니다. 지휘자는 모든 악기를 직접 연주하지 않습니다. 곡 전체를 붙들고 있습니다. 그런데 곡 전체를 붙들고 있다는 것 자체가 시스템 전체에 대한 인식을 유지해야 한다는 의미이기 때문에 소진됩니다. 더 열심히 한다고 늘릴 수 있는 능력이 아닙니다.

자신의 한계치를 파악하는 것 자체가 기술이다

대부분은 한계를 넘어서고 나서야 한계를 알게 됩니다. 에이전트 두 개로 순조롭게 시작한 세션에서, 잘 되는 것 같으니 하나 더 추가하고, 또 하나 추가하다 보면, 낮 12시쯤에는 더 이상 꼼꼼히 검토하지 않고 그냥 출력을 수락하고 있게 됩니다. 이것은 실패처럼 느껴지지 않습니다. 생산성처럼 느껴집니다.

한계치는 고정된 숫자가 아닙니다. 각 스레드의 복잡도에 따라 달라집니다. 진짜 새로운 아키텍처 문제를 다루는 에이전트 두 개는, 범위가 잘 정의된 마이그레이션을 처리하는 에이전트 네 개보다 훨씬 빠르게 소진시킵니다. 스레드 수보다 스레드당 범위가 더 중요한 변수입니다.

사전에 작업을 얼마나 잘 명세화했느냐에 따라서도 달라집니다. 모호한 브리프는 진행 중에 불명확한 부분이 생겨 반복적으로 스레드에 다시 끌려 들어오게 만듭니다. 명확한 수용 기준이 있는 명확한 브리프는 스레드를 더 독립적으로 만들어줍니다. 에이전트를 실행하기 전에 제대로 된 브리프를 작성하는 것은 오버헤드가 아닙니다. 그것이 바로 내가 실제로 손을 뗄 수 있게 해주는 것입니다.

세션이 얼마나 오래 이어지느냐에 따라서도 달라집니다. 시간이 정해진 짧은 세션은 끝이 없는 세션과 질적으로 다르게 느껴집니다. 종료 상태가 정의되어 있지 않으면 열린 루프를 무기한으로 붙들고 있어야 합니다. 그리고 충분히 자고 회의가 없는 날의 한계치와, 여섯 시간 연속 회의 후 목요일 오후의 한계치는 의미 있는 수준으로 다릅니다. 두 상황에서 같은 수의 에이전트를 사용하는 것은 잘못된 조정이지만, 이미 번아웃이 온 뒤에야 알아채는 경우가 대부분입니다.

내가 실제로 바꾼 것들

저는 긴 에이전틱 세션을 깊은 집중 작업처럼 다루기 시작했습니다. 시간을 정해두고, 스레드마다 명확한 범위를 부여하는 방식으로요.

구체적으로는 이렇습니다. 이제 에이전트를 실행하기 전에 세션 시간을 먼저 정하고, 그 시간에 맞게 태스크 범위를 조정합니다. 세 개의 스레드로 두 시간짜리 세션을 진행하려면, 각 스레드를 해당 시간 안에 마무리할 수 있고 스레드당 30분 안에 검토할 수 있는 규모로 잡습니다. 태스크가 그 형태에 맞지 않으면, 태스크를 더 잘게 쪼개거나 스레드 수를 줄입니다.

시간 제한을 두면 조용한 이탈을 막아주는 자연스러운 체크포인트가 생깁니다. 불안해서 확인하는 게 아니라, 세션이 끝났기 때문에 확인하게 되는 것입니다. 상시 불안세도 달라집니다. 끝이 없는 스레드는 무한한 경계심을 요구하지만, 시간이 정해진 스레드는 경계심이 경계 안에 머뭅니다. 이 차이는 일주일 단위로 보면 상당히 누적됩니다.

두 번째 변화는, 집중해서 꼼꼼히 검토한 스레드 세 개가 건성으로 감독하는 스레드 여섯 개보다 실제로 쓸 수 있는 결과물을 더 많이 만들어낸다는 사실을 받아들인 것입니다. 처리량 수치는 여섯 개 쪽이 좋아 보입니다. 하지만 두 번 검토하지 않고도 실제로 머지할 수 있는 코드는 세 개 쪽이 더 많습니다. 일반적인 세션에서 제 한계치는 복잡도에 따라 스레드 세 개에서 네 개 사이 어딘가입니다. 그 숫자를 알게 되면, 스레드를 적게 쓰는 것을 더 이상 실패로 여기지 않게 됩니다.

의도적으로 조정하고 싶다면

적당하다고 느껴지는 것보다 스레드 하나 적게 시작하세요. 뭔가 깨질 때까지 에이전트 수를 밀어 올리고 싶은 충동이 생기지만, 반대로 접근하면 사후 대응이 아니라 사전 조정이 가능합니다.

에이전트 수가 아니라 검토 품질을 지켜보세요. 세션이 끝나기도 전에 수락하는 결과물에 대한 확신이 떨어지기 시작한다면, 그 세션의 한계치에 도달한 것입니다. 이 신호가 어떤 경험 법칙보다 솔직합니다.

불안 신호를 일찍 알아채세요. 스레드에서 무슨 일이 일어나고 있는지 잘 모르겠다는 느낌은 하나의 정보입니다. 그 느낌이 두 개 이상의 스레드에서 동시에 나타난다면, 처리 한계에 이른 것입니다.

스레드 수를 줄이기 전에 범위를 줄여보세요. 핵심 레버가 "에이전트를 덜 돌리기"가 아니라 "각 에이전트에게 더 좁은 태스크 주기"인 경우가 많습니다. 스레드당 범위를 좁히면 각 스레드가 요구하는 인지 부담이 줄어들고, 결과적으로 작업을 실제로 파악하면서 감당할 수 있는 스레드 수가 늘어납니다.

우리가 충분히 이야기하지 않는 부분

AI 코딩 에이전트에 관한 대화는 거의 전적으로 에이전트가 무엇을 할 수 있는지에 집중되어 있습니다. 인간이 무엇을 지속적으로 감당할 수 있는지에 대한 이야기도 함께 이루어져야 합니다.

한계치는 개인의 실패가 아닙니다. 우리는 제한된 작업 기억, 실질적인 컨텍스트 전환 비용, 그리고 유한한 경계심을 가지고 있습니다. 장기적으로 병렬 에이전트에서 가장 많은 것을 얻어내는 엔지니어는 가장 많이 동시에 돌리는 사람이 아닐 것입니다. 처리량과 이해의 차이를 알고, 그 차이를 극복해야 할 약점이 아니라 설계해야 할 제약으로 다루는 법을 익힌 사람일 것입니다.

이 도구들과 함께하면서 자신만의 한계치를 파악하는 것은 하나의 기술입니다. 대부분은 의도적으로 배우기 전에 먼저 몸으로 배우게 될 것입니다. 그 간격을 줄이는 것이 목표입니다.