병렬 에이전트 한계선 찾기
TMTTip: 여러 에이전트를 병렬로 돌릴 때, 나에게 맞는 상한선을 스스로 파악하세요.
에이전트를 더 많이 돌린다고 해서, 당신 자신 이 더 늘어나는 건 아닙니다. 지금 에이전트 엔지니어링을 둘러싼 이야기는 거의 전적으로 처리량과 병렬성에 초점이 맞춰져 있지만, 인간이 그 사이에서 실제로 어떤 비용을 치르고 있는지에 대해서는 거의 아무도 말하지 않습니다. 당신은 동시에 여러 문제의 컨텍스트를 머릿속에 붙잡고 있어야 하고, 계속해서 판단을 내려야 하며, 각 에이전트가 조용히 뭔가를 틀리고 있을지 모른다는 불안을 고스란히 떠안고 있습니다.
이건 우리가 아직 제대로 된 언어조차 갖추지 못한 새로운 종류의 인지 노동입니다.
이는 Simon Willison이 Lenny Rachitsky와의 최근 대화에서 했던 말과도 이어집니다. 에이전트 네 개를 동시에 띄워서 오전 11시까지 일하면, 그날은 그대로 방전된다는 이야기죠. 그는 옳습니다. 우리는 컴퓨팅 리소스를 어떻게 스케일링할지에 대해서는 100년에 가까운 직관을 쌓아 왔습니다. 하지만 다섯 개의 문제를 동시에 머릿속에 올려둔 채, 그 모든 스레드에서 끊임없이 판단을 내려야 하는 게 어떤 느낌인지는 거의 감이 없습니다. 그렇게 부담이 서서히 쌓이다가, 정작 언제부터 어떤 스레드가 흐트러졌는지도 모른 채 정오 무렵 완전히 탈진해 버렸다는 걸 뒤늦게 깨닫게 됩니다.
나는 에이전트 오케스트레이션을 위한 매니지먼트 모델에 대해 써 왔습니다. 병렬 세션을 다루는 방식을 비동기 엔지니어링 팀을 운영하듯이 보는 관점이죠. 브리프를 쓰고, 위임 패턴을 설계하고, 검증 루프를 두는 식으로요. 하지만 이 프레이밍이 다루는 건 주로 조직적 오버헤드입니다. 여기서 이야기하려는 건 그보다 더 개인적인 오버헤드, 즉 전적으로 당신 안에서만 일어나는 부담입니다.
병렬 에이전트가 실제로 당신에게 요구하는 것
에이전트 하나와만 페어링해서 일할 때, 인지 모델은 비교적 단순합니다. 하나의 활성 컨텍스트, 하나의 의사결정 흐름, 하나의 출력 스트림만 평가하면 됩니다. 깊게 파고들 수 있고, 어디서부터 엇나가기 시작하는지도 포착할 수 있습니다.
반대로 네 개를 동시에 돌리면, 이제는 완전히 다른 일을 하고 있는 셈입니다. 같은 작업을 네 번 병렬로 하는 것이 아니라, 네 개의 서로 다른 멘탈 모델을 동시에 관리하는 일이 되는 거죠. 서로 다른 코드베이스 네 개, 서로 다른 문제 정의 네 개, 서로 다른 신뢰도 보정 네 개, 그리고 ‘지금 이게 조용히 얼마나 크게 틀어지고 있을 수 있을까?’라는 서로 다른 추정 네 개입니다.
마지막 것이 우리가 가장 과소평가하는 부분입니다. 병렬 에이전트 작업이 피로한 진짜 이유는, 눈앞에서 열심히 생각하는 일 자체라기보다는 그 뒤에 깔린 ‘배경 경계 상태’ 때문입니다. 20분 동안 확인하지 않은 스레드에서 뭔가가 조용히 이상하게 돌아가고 있을지 모른다는 걸, 마음 한 켠이 계속 알고 있어서 완전히 긴장을 풀지 못하는 상태 말이죠. 나는 이걸 ‘주변부 불안 세금(ambient anxiety tax)’이라고 생각합니다. 할 일 목록에는 나타나지 않지만, 다른 모든 일에 쓰이는 것과 같은 자원에서 계속 조금씩 가져가 버립니다.
이건 내가 이해 부채(comprehension debt)에 대해 썼던 내용과도 연결됩니다. 우리가 이해할 수 있는 속도보다 더 빠르게 에이전트가 무언가를 만들어내도록 허용하면, 그만큼 부채가 쌓입니다. 단일 세션에서는 이 부채가 일정 범위 안에 머무릅니다. 그런데 병렬 세션에서는 이 부채가 여러 스레드에서 동시에 복리처럼 불어나고, 어느 스레드가 가장 큰 탭을 찍고 있는지조차 쉽게 알 수 없습니다.
부하는 실제로 어디에 쌓이는가
우선 컨텍스트 스위칭이 있습니다. 보기보다 훨씬 비싼 비용이죠. 에이전트 사이를 오간다는 건, 매번 멘탈 모델을 다시 로드한다는 뜻입니다. 이 작업이 어디서 시작됐는지, 에이전트가 어떤 접근법을 택했는지, 30분 전에 당신이 내린 결정이 지금 무엇을 가능하거나 불가능하게 만들었는지를 다시 떠올려야 합니다. 태스크 전환에 관한 연구를 보면, 비용은 전환 행위 자체에 있다기보다는 ‘복구 시간’에 있습니다. 네 개의 병렬 스레드가 있으면, 이 전환 비용을 끊임없이 지불하게 되고, 복구가 채 끝나기도 전에 다음 스위치가 들어옵니다.
다음은 판단입니다. 이건 묶어서 처리하거나 나중으로 미룰 수 없습니다. 나는 에이전트 수를 늘려 보면서 이 지점을 새삼 크게 느꼈습니다. 처음에는 병렬 에이전트가 백그라운드에서 일을 처리해 주면서 내 대역폭을 많이 늘려 줄 거라 기대했죠. 실제로 그런 면도 있지만, 동시에 끊임없이 ‘판단을 요구하는 순간들’을 만들어내면서 나를 방해하기도 합니다. 이 접근이 우리 아키텍처 원칙에 맞는가? 이 스레드를 여기서 끊고 방향을 바꿔야 할까? 이 에러는 회복 가능한 수준인가, 아니면 근본적으로 엇나가고 있다는 신호인가? 이런 질문들은 이메일처럼 나중에 몰아서 처리할 수 있는 것이 아닙니다.
그리고 ‘신뢰도 보정(trust calibration)’의 오버헤드가 있습니다. 눈에 잘 안 띄다가도 어느 순간 크게 다가오는 영역이죠. 에이전트 세션마다 그 순간의 암묵적인 신뢰도가 항상 깔려 있습니다. 초반에는 더 촘촘히 지켜보며, 세션이 잘 흘러가면 중간쯤부터는 조금 더 여유를 주게 됩니다. 그런데 이 보정치는 스레드마다 따로 관리해야 하고, 내가 잠시 눈을 떼는 동안 쉽게 흐려집니다. 어느 순간 ‘이 스레드에 대한 신뢰도가 지금 어느 정도였는지’ 감을 잃었다는 걸 깨닫는 순간, 나는 그동안 나온 결과물을 전부 다시 읽는 입장이 되어 버립니다. 보통 그 지점에서, 생산적으로 잘 흘러가던 오전이 한순간에 극도로 피로한 오전으로 바뀝니다.
에이전트를 더 붙인다고 선형으로 스케일되지 않는 이유
병렬 에이전트를 돌리다 보면, 아주 그럴싸한 수학에 빠지기 쉽습니다. 에이전트 하나가 기능 하나를 40분 만에 끝낼 수 있고, 그런 에이전트를 네 개 돌릴 수 있다면, 같은 시간 안에 기능 네 개를 끝낼 수 있을 것처럼 느껴집니다. 처리량만 놓고 보면 이 계산은 맞습니다. 하지만 인간에게는 그렇지 않습니다.
당신의 인지 대역폭은 병렬화되지 않습니다. 생성은 에이전트가 합니다. 그러나 평가, 의사결정, 신뢰 구축과 조정, 그리고 결과 통합(integration)은 여전히 전부 당신 몫입니다. 그리고 이 모든 일은 당신 쪽 루프에서는 하나의 싱글 스레드 위에서 돌아갑니다.
실제로 스케일하는 것은 ‘이해의 처리량’이 아니라 ‘감독(supervision)의 처리량’입니다. 당신은 깊이 이해할 수 있는 양보다 더 많은 에이전트를 감독할 수 있습니다. 하지만 이해 없이 감독만 늘어나는 지점이 바로 이해 부채가 쌓이는 자리입니다. 코드는 배포되지만, 내가 무엇을 어떻게 만들었는지에 대한 멘탈 모델은 스레드가 하나 늘어날 때마다 조금씩 더 뒤처집니다.
그래서 Code Agent Orchestra 프레이밍에서 가져온 ‘지휘자(conductor)’ 은유가 꽤 잘 맞습니다. 지휘자는 모든 악기를 직접 연주하지 않습니다. 대신 전체 곡을 머릿속에 통째로 붙잡고 있죠. 그런데 이 ‘전체 시스템을 통째로 붙드는 일’이 바로 지독하게 피곤한 이유이기도 합니다. 이건 더 열심히 한다고 해서 가용 범위를 마음대로 늘릴 수 있는 종류의 일이 아닙니다.
나만의 상한선을 찾는 것도 하나의 기술이다
우리 대부분은 이 상한선을 정면으로 부딪혀 본 뒤에야 알게 될 것입니다. 두 개의 에이전트로 시작한 세션이 초반에는 꽤 괜찮게 느껴집니다. 그러다 ‘이 정도면 하나 더 늘려도 되겠는데?’ 싶어서 세 개로 올리고, 다시 네 개로 늘립니다. 그리고 정오쯤이 되면, 더 이상 어떤 결과도 꼼꼼히 리뷰하지 않고 출력물만 받아들이고 있는 자신을 발견하게 됩니다. 이게 실패처럼 느껴지지는 않습니다. 오히려 엄청나게 생산적인 것처럼 느껴지죠.
당신의 상한치는 고정된 숫자가 아닙니다. 각 스레드의 복잡도에 따라 달라집니다. 정말 새로운 아키텍처 문제를 다루는 에이전트 두 개는, 범위가 잘 정의된 마이그레이션 작업을 처리하는 에이전트 네 개보다 훨씬 빠르게 당신을 소진시킬 수 있습니다. 실질적으로는 ‘에이전트 개수’보다 ‘스레드당 스코프’가 훨씬 더 큰 변수입니다.
작업을 얼마나 잘 스펙팅했는지에 따라서도 달라집니다. 애매한 브리프는, 진행 중간에 발생하는 모호함 때문에 당신을 그 스레드로 계속 다시 끌어들입니다. 반대로, 명확한 수용 기준을 가진 탄탄한 브리프는 스레드를 훨씬 더 자기완결적으로 만들어 줍니다. 에이전트를 띄우기 전에 브리프를 제대로 쓰는 일은 부가적인 오버헤드가 아니라, 정말로 그 스레드에서 한 발 떨어질 수 있게 해 주는 핵심 장치입니다.
세션이 얼마나 오래 이어지는지도 중요한 축입니다. 짧게 시간을 정해 둔(time-boxed) 세션은 오픈 엔드(open‑ended) 세션과는 근본적으로 다른 느낌을 줍니다. 끝나는 시점을 정하지 않으면, 열린 루프들을 무기한 품고 있게 됩니다. 그리고 전날 충분히 자고 회의가 거의 없는 날과, 목요일 오후처럼 이미 회의를 여섯 시간이나 치른 날의 상한선은 말 그대로 다릅니다. 두 상황에서 같은 에이전트 개수를 쓰는 건, 대부분의 사람이 이미 번아웃에 가까워지기 전까지는 잘 알아차리지 못하는 ‘미스 캘리브레이션’입니다.
내가 실제로 바꾼 것들
나는 이제 긴 에이전트 세션을 ‘딥 포커스 작업’과 거의 비슷하게 다루기 시작했습니다. 시간 박스를 정하고, 스레드마다 명시적인 스코프를 부여하는 식으로요.
구체적으로 말하면: 에이전트를 띄우기 전에 우선 세션의 전체 길이를 정하고, 그 안에 들어갈 수 있게 작업 스코프를 맞춥니다. 예를 들어 두 시간짜리 세션에서 세 개의 스레드를 돌리고 싶다면, 각 스레드는 그 안에서 해결 가능한 단위로 쪼개고, 결과물을 내가 스레드당 30분 안에 리뷰할 수 있을 정도의 크기로 한정합니다. 그 모양에 들어가지 않는 작업이라면, 작업을 더 쪼개거나 아예 스레드 개수를 줄입니다.
시간을 박스 치는 것은 조용한 드리프트를 막는 자연스러운 체크포인트를 만들어 줍니다. 불안해서 수시로 확인하는 게 아니라, 세션이 끝났기 때문에 확인하는 구조가 되는 거죠. 이건 ‘주변부 불안’의 성격도 바꿉니다. 끝나는 시점이 없는 열린 스레드는 무기한의 경계 상태를 강요합니다. 반면, 시간으로 구획된 스레드는 유한한 범위의 경계만 요구합니다. 이 차이는 일주일 단위로 보면 꽤 크게 누적됩니다.
두 번째 변화는, 잘 집중해서 꼼꼼히 리뷰한 세 개의 스레드가, 내가 절반만 감독하는 여섯 개의 스레드보다 실제로는 훨씬 더 쓸 만한 결과를 낸다는 사실을 받아들였다는 점입니다. 겉보기 처리량은 여섯 개일 때 더 좋아 보입니다. 하지만 ‘두 번째 패스 없이 바로 머지해도 되겠다’ 싶은 코드는 세 개일 때 훨씬 더 많이 나옵니다. 보통 세션에서 나의 상한선은 스레드 복잡도에 따라 세 개에서 네 개 사이 어딘가쯤입니다. 이 숫자를 알고 나니, 더 적은 스레드를 돌리는 걸 실패로 보지 않게 되었습니다.
의도적으로 상한선을 알고 싶다면, 이렇게 조율해 보세요
딱 맞아 보이는 것보다, 항상 하나 적은 스레드로 시작하세요. 대부분의 사람은 ‘언제 뭔가가 망가지는지’를 보기 위해 에이전트 수를 계속 밀어붙입니다. 이걸 반대로 뒤집으면, 항상 파국 직전이 아니라 ‘의식적으로 조율된 상태’에 자신을 두게 됩니다.
에이전트 개수가 아니라, 리뷰의 질을 관찰하세요. 세션이 아직 끝나지 않았는데도, 내가 받아들이는 결과물에 대해 스스로 느끼는 신뢰감이 떨어지기 시작한다면, 그게 바로 그 세션에서의 상한선입니다. 어떤 경험칙보다 이 신호가 훨씬 솔직합니다.
그리고 불안 신호를 초기에 포착하세요. ‘저 스레드에서 지금 정확히 무슨 일이 벌어지는지 잘 모르겠다’는 느낌 자체가 이미 하나의 정보입니다. 이 감각이 동시에 두 개 이상의 스레드에서 떠오르기 시작하면, 그때가 바로 당신이 한계에 도달했다는 뜻입니다.
마지막으로, 에이전트 수를 줄이기 전에 스코프를 먼저 줄여 보세요. 꼭 필요한 레버가 “에이전트를 더 적게 돌려라”가 아니라 “각 에이전트에게 더 타이트한 작업을 줘라”인 경우가 훨씬 많습니다. 스레드당 스코프를 줄이면, 각 스레드가 머릿속에 차지하는 오버헤드가 줄어들고, 그만큼 더 많은 에이전트를 돌리면서도 ‘일을 정말로 제대로 파악하고 있다’는 상태를 유지할 수 있게 됩니다.
우리가 아직 충분히 이야기하지 않은 부분
AI 코딩 에이전트에 대한 대화는 지금 대부분 ‘에이전트가 무엇을 할 수 있는가’에만 맞춰져 있습니다. 이제는 ‘인간이 무엇을 끝까지 버텨낼 수 있는가’에 대해서도 이야기해야 합니다.
상한선이 있다는 건 개인의 실패가 아닙니다. 우리는 한정된 작업 기억 용량을 갖고 있고, 컨텍스트 스위칭에는 실제 비용이 들며, 경계를 유지할 수 있는 시간도 유한합니다. 장기적으로 병렬 에이전트를 가장 잘 활용하게 될 엔지니어는, 단순히 동시에 가장 많은 에이전트를 돌리는 사람이 아닐 것입니다. 처리량과 이해 사이의 차이를 분명히 알고, 그 차이를 ‘극복해야 할 약점’이 아니라 ‘그 안에서 설계해야 할 제약’으로 받아들이는 사람일 것입니다.
이 도구들과 함께 일할 때, 자신의 개인적인 상한선을 찾아가는 건 하나의 기술입니다. 대부분의 사람은 무심코 한계를 넘겨 본 뒤에야 의식적으로 배우게 될 겁니다. 우리의 목표는 그 간극을 최대한 줄이는 것입니다.