AI 에이전트 시대의 컨텍스트 스위칭 — 사람이 스케줄러가 될 때#

2026-07-19

AI 에이전트가 최종 작업을 대신 수행하는 시대가 되면서, 사람은 동시에 여러 일을 진행할 수 있게 되었습니다. 그런데 요즘 필자는 이상한 피로를 느낍니다. 에이전트 두세 개와 동시에 대화하며 작업을 진행하다 보면, 분명 손은 바쁘지 않은데 머리가 계속 헛도는 느낌입니다. 응답 알림이 올 때마다 즉시 그 세션으로 전환해서 확인하는데, 정신은 없고 오히려 전체 퍼포먼스는 떨어지는 것 같았습니다.

이 글은 그 원인을 조사하고, 필자가 실제로 채택하기로 한 운용 규칙을 정리한 것입니다. 결론부터 말하면 문제는 에이전트가 아니라 사람 쪽, 정확히는 컨텍스트 스위칭(작업 전환 시 머릿속 맥락을 내리고 다시 올리는 일) 방식에 있었습니다.

새로운 병목: 이번에는 사람이다#

에이전트와의 협업 구조를 뜯어보면 이렇습니다. 에이전트는 필자의 머리에 직접 연결되어 있지 않으므로, 원하는 바를 전달하려면 대화가 필요합니다. 대화의 상당 부분은 작업 시작 전에 이루어지지만, 작업 중에도 계속 발생합니다. 그리고 에이전트도 즉답하는 존재가 아닙니다. 필자의 환경에서 에이전트의 응답은 평균 3분 정도 걸립니다.

3분을 그냥 기다리는 것은 비효율이니 자연스럽게 다른 작업을 병행하게 됩니다. 그렇게 에이전트와의 대화 세션이 두 개, 세 개로 늘어납니다. 여기까지는 합리적인 선택의 연속입니다. 문제는 그다음입니다. 세션 사이를 오갈 때마다 “이 세션에서 뭘 하고 있었더라"를 다시 파악하고, 그 맥락을 머리에 다시 로드하는 데 생각보다 시간이 오래 걸립니다.

작업 하나를 시켜두고 한 시간 뒤에 돌아오는 구조라면 전환 비용은 큰 이슈가 아닙니다. 전환이 드물기 때문입니다. 그런데 응답 주기 3분짜리 대화 세션이 두세 개 겹치면 이야기가 달라집니다. 전환이 몇 분 단위로 강제되는 구조가 되고, 사람은 운영체제의 스케줄러처럼 끊임없이 프로세스를 갈아끼우는 역할을 떠안게 됩니다. 차이가 있다면, 운영체제의 컨텍스트 스위칭은 마이크로초 단위인데 사람의 것은 분 단위라는 점입니다.

머리는 왜 못 따라오는가 — 세 가지 연구#

이 피로감이 기분 탓이 아니라는 근거는 이미 오래전부터 쌓여 있었습니다.

첫째, 주의 잔류(attention residue). 워싱턴대학교의 Sophie Leroy가 2009년 논문에서 정리한 개념으로, 작업 A에서 B로 전환해도 A에 대한 인지 활동이 완전히 꺼지지 않고 남아 B의 수행 성능을 떨어뜨린다는 것입니다(Leroy의 연구 소개). 중요한 것은 조건입니다. 잔류는 이전 작업이 미완결 상태일 때 가장 강하게 남습니다. 에이전트와의 대화는 구조적으로 항상 미완결 상태에서 전환됩니다. 응답을 기다린다는 것 자체가 열린 루프이기 때문입니다. 즉 에이전트 병행 작업은 주의 잔류가 최대로 발생하는 조건을 정확히 밟고 있습니다.

둘째, 회복 비용. UC 어바인의 Gloria Mark 연구팀은 작업이 중단된 뒤 원래 수준의 몰입으로 돌아오는 데 평균 23분가량 걸린다는 결과를 내놓았습니다(연구 요약). 응답 주기 3분짜리 대화를 알림 기반으로 오가면, 수학적으로 몰입에 도달하는 것 자체가 불가능합니다. 매 전환마다 회복 비용만 내고 몰입의 이득은 한 번도 받지 못하는 구조입니다.

셋째, 재개 지연(resumption lag)과 단서(cue). Altmann과 Trafton의 연구에 따르면, 중단된 작업을 재개할 때 걸리는 시간은 두 가지로 크게 줄일 수 있습니다(Task Interruption: Resumption Lag and the Role of Cues). 떠나기 직전에 “돌아오면 무엇부터 한다"는 목표를 의도적으로 새겨두는 것, 그리고 돌아왔을 때 눈에 띄는 재개 단서를 준비해 두는 것입니다. “세션에 돌아왔을 때 맥락을 다시 로드하는 시간"은 줄일 수 있는 변수라는 뜻입니다.

정리하면 이렇습니다. 알림이 올 때마다 즉시 전환하는 방식은, 미완결 상태의 전환(잔류 최대화)을 몇 분 간격으로(회복 불가능) 아무 단서 없이(재개 지연 최대화) 반복하는 것입니다. 나쁜 조건만 골라서 조합한 셈이니 정신이 없는 게 당연했습니다.

필자가 채택한 세 가지 규칙#

조사한 내용 중에서 지금 당장 행동을 바꿀 수 있겠다고 판단한 것은 세 가지입니다.

1. 알림 즉시 전환 금지 — 코루틴 방식으로#

핵심은 전환 시점의 주도권을 알림에서 사람에게 가져오는 것입니다. 알림이 와도 바로 넘어가지 않고, 지금 보고 있는 세션의 작은 태스크 단위를 마무리한 뒤에 전환합니다. 여기서 작은 태스크 단위란 “응답을 다 읽고 다음 질의를 보냈다” 정도의 완결 지점을 말합니다.

프로그래밍에 비유하면 멀티스레딩이 아니라 코루틴을 택하는 것입니다. 멀티스레딩에서는 스케줄러가 아무 때나 실행을 끊고 다른 스레드로 넘겨버리지만(선점형), 코루틴은 각 작업이 스스로 “여기서 멈춰도 안전하다"는 지점에서만 차례를 양보합니다(협력형). 알림 즉시 전환은 내 머리를 선점형으로 운영하는 것이고, 태스크 단위 완결 후 전환은 협력형으로 운영하는 것입니다.

이 비대칭을 기억해 두면 마음이 편해집니다. 에이전트는 기다려도 아무 비용이 없습니다. 응답이 3분 늦게 읽혀도 손해는 0인데, 사람의 생각이 중간에 끊기는 비용은 실측된 값이 있습니다. 그러니 항상 사람의 리듬이 우선입니다.

2. 떠나기 전, 질의 입력란에 재개 메모를 남긴다#

필자는 여러 개의 IDE(통합 개발 환경) 창을 띄워 두고, 각 창에 여러 에이전트 세션을 열어 두고 작업합니다. 이 환경에서 가장 자주 겪는 문제가 “이 세션에서 뭘 하고 있었더라"입니다. Altmann과 Trafton의 연구가 말하는 재개 단서를 여기에 적용하면 답이 나옵니다. 세션을 떠나기 전에 20초만 들여, 그 세션의 질의 입력란에 현재 맥락과 다음에 할 일을 짧게 적어두는 것입니다. 입력란은 어차피 돌아왔을 때 가장 먼저 시선이 가는 곳이므로, 별도 메모 도구 없이 그 자체로 재개 단서가 됩니다.

한 단계 더 나아가면 이 역할을 에이전트에게 위임할 수도 있습니다. 자리를 비우기 전에 “내가 돌아오면 현재 상태 요약과 나에게 필요한 결정 사항을 맨 위에 정리해 달라"고 요청해 두면, 재개 단서가 화면에 자동으로 준비됩니다. 맥락 저장소 역할을 사람의 머리가 아니라 에이전트가 맡게 되는 것입니다.

3. 대화형 작업은 동시에 두 개까지#

병행 중인 작업을 두 종류로 나눕니다.

장기 자율형은 몇 개가 돌아도 무방합니다. 문제는 대화형이고, 필자는 동시 진행 수를 두 개 전후로 제한하기로 했습니다. 숫자 자체는 상황에 따라 조정할 수 있지만, 대화형 작업의 동시 진행 수에 상한을 둔다는 원칙이 핵심입니다. 실무자들의 경험담도 비슷한 지점으로 수렴합니다. 다수의 에이전트를 병행 운용해 본 사람들은 공통적으로 서너 개 이상은 인지적으로 감당되지 않는다고 말합니다(Addy Osmani, The Code Agent Orchestra).

이론은 맞지만 현실이 만만치 않은 두 가지#

조사 과정에서 나온 처방 중, 원칙에는 동의하지만 그대로 적용하기는 어렵다고 판단한 것도 있습니다. 이 둘은 참고 사항으로 남겨두고 응용할 생각입니다.

질문을 앞단으로 몰기. 작업 중 몇 분 주기의 핑퐁이 발생하는 근본 원인은 시작 시점에 컨텍스트가 부족했기 때문이니, 명확화 질문을 시작 시점에 한꺼번에 소진시키면 전환 횟수 자체가 줄어든다는 처방입니다. 이론적으로 매우 맞는 말이고 필자도 상당히 신경 쓰는 부분이지만, 막상 해보면 쉽지 않습니다. 시작 시점에 완전한 종료 상태를 사람이 다 알 수 없는 경우가 많기 때문입니다. 사람도 대화를 하면서 “아, 결국 이렇게 해야 하는 거구나"를 뒤늦게 판단하게 되는 경우가 흔합니다. 현실적인 절충은 발견을 없애는 게 아니라 발견의 타이밍을 앞당기는 것입니다. 본 작업 전에 “구현하지 말고, 내가 결정해야 할 사항을 먼저 조사해서 목록으로 가져와 달라"는 탐색 패스를 한 번 돌리거나, “막히는 것은 모아뒀다가 단계가 끝날 때 한꺼번에 물어봐 달라"고 지시해 질문의 도착 간격을 넓히는 방식입니다.

깊은 작업은 하나만. 맥락 로딩이 많이 필요한 깊은 작업은 하나만 주인공으로 두고, 나머지 슬롯은 몇 분 안에 완결되는 얕은 작업으로 채우라는 처방입니다. 이것도 방향에는 동의하지만, 깊은 작업과 얕은 작업의 경계가 모호해서 결국 깊은 작업 둘 이상을 병행하는 상황이 생길 수밖에 없습니다. 다만 조사하면서 얻은 재해석이 하나 있습니다. 깊이는 작업의 속성이 아니라 국면의 속성이라는 것입니다. 같은 작업도 설계를 고민하는 국면에서는 깊고, 에이전트가 혼자 구현하는 국면에서는 얕습니다. 그렇다면 규칙은 “깊은 작업을 하나만 두라"가 아니라 “두 작업의 깊은 국면이 겹치지 않게 위상을 어긋나게 배치하라"가 되고, 이는 결국 위의 대화형 작업 수 제한과 같은 규칙의 다른 표현이 됩니다.

마치며#

에이전트를 잘 쓰는 능력이 중요해진 시대라고들 합니다. 필자는 그 능력의 절반이 프롬프트가 아니라 사람 쪽 스케줄링에 있다고 느낍니다. 에이전트의 성능은 계속 좋아지고 있으니, 남는 병목은 여러 세션 사이를 오가는 사람의 머리입니다. 그리고 이 병목은 도구를 바꾼다고 해결되지 않고, 전환의 주도권을 알림에서 회수하고(코루틴 방식), 열린 루프의 수를 제한하고(대화형 두 개), 열린 루프마다 재개 단서를 붙이는(입력란 메모) 습관의 문제였습니다.

가장 레버리지가 큰 개입은 전환을 잘하는 것이 아니라 전환할 일 자체를 줄이는 것이라는 점도 함께 적어둡니다. 에이전트가 한 번의 지시로 더 오래, 더 멀리 갈수록 사람의 컨텍스트 스위칭 문제는 자연히 완화됩니다. 결국 이 글의 규칙들은 에이전트의 자율 실행 능력이 충분히 좋아질 때까지의 과도기를 버티는 기술일지도 모릅니다. 다만 그 과도기가 생각보다 길 수 있으니, 버티는 기술도 제대로 갖춰둘 가치가 있습니다.