AI 에이전트, 직접 할까 위임할까 판단하는 법

설정 파일에 한 줄 주석을 추가할 때는 손이 먼저 움직인다. 같은 파일 옆에서 새 로직 100줄을 얹을 때도 똑같이 손이 먼저 움직인 적이 있었다. 둘 다 파일 하나를 고치는 일이었는데 결과는 완전히 갈렸다. 앞쪽은 아무 일도 안 났고 뒤쪽은 검증 없이 통과된 자리가 나중에 사고로 돌아왔다.

이 차이를 가른 건 파일 경로가 아니라 작업의 무게였다. 직접 처리(main context, 메인 대화창에서 곧바로 손대는 방식)와 위임(서브에이전트, subagent, 별도 세션에 넘겨 대신 처리시키는 방식) 사이의 선택은 매번 새로 해야 하는 판단인데, 이 판단이 계속 같은 자리에서 흔들렸다. 직접 할지 넘길지, 이 판단 하나에만 눈금을 대 본다.

규칙은 있는데 판단은 왜 매번 흔들리나

"복잡한 작업은 위임하고 간단한 작업은 직접 한다"는 규칙쯤은 누구나 세워 둔다. 문제는 이 규칙이 글로만 적혀 있고 강제하는 장치가 없다는 데 있다. 강제가 없으면 판단은 그때그때 편한 쪽으로 샌다. 실제로 이런 일이 있었다. 벤더 CLI(외부 AI 도구)를 막는 훅 파일 두 개를 새로 작성하고, 설정 파일을 신규로 만들고, 기존 설정 여러 곳을 고치는 작업까지 전부 메인 루프에서 직접 처리해 버린 세션이 있었다. 세 작업 모두 손을 대는 데 최소 대여섯 단계가 필요했다.

왜 위임하지 않았을까. 그 경로들이 마침 "직접 써도 되는 허용 목록"에 들어 있었기 때문이다. 허용 목록은 원래 "한 줄 주석 정도는 왕복 없이 바로 고쳐도 된다"는 좁은 예외였는데, 실제로는 "이 경로면 뭐든 직접 해도 된다"로 확대 해석됐다. 경로 이름이 필요조건에서 슬쩍 충분조건으로 둔갑한 셈이다. 허용 목록에 있다는 사실 하나만으로 직접 처리를 정당화하면 이런 확대 해석은 계속 반복된다.

그런데 판단 기준 자체가 없으면 뭘 근거로 나눠야 할까. 경로 이름 대신 작업의 특성을 봐야 한다. 같은 파일이라도 한 줄을 고치는 것과 새 로직 100줄을 짜 넣는 것은 무게가 다르다. 무게를 재는 눈금이 없으니 매번 감으로 판단했고, 감은 편한 쪽으로 기울었다.

이 드리프트(drift, 규칙이 있는데도 실제 행동이 조금씩 원칙에서 벗어나는 현상)가 무서운 이유는 한 번으로 안 끝난다는 데 있다. 훅 파일을 직접 써도 이번엔 별문제 없었다면, 다음번 비슷한 작업도 "지난번에 됐으니까"라는 이유로 또 직접 처리하게 된다. 근거가 규칙이 아니라 지난 성공 경험으로 슬쩍 바뀌는 셈이다. 이런 식으로 쌓인 예외는 나중에 정말 위임이 필요한 순간에도 "이 정도는 늘 직접 했잖아"라는 착각을 만든다.

네 가지 신호로 판단 기준을 세운다

감 대신 쓸 수 있는 눈금은 네 가지로 좁혀졌다. 작업 규모, 컨텍스트 오염도(context pollution, 메인 대화창에 원시 로그·diff·에러 메시지가 쌓여 창이 지저분해지는 정도), 병렬 가능성, 검증 필요성이다. 넷 중 하나라도 위임 쪽 답이 나오면 전체 판정도 위임 쪽으로 기운다.

작업 규모는 끝나기까지 필요한 단계 수로 잰다. 파일을 읽고 이해하고 고치고 다시 확인하는 과정이 한두 단계면 직접 처리 후보다. 읽기→설계 판단→여러 파일 수정→테스트까지 이어지면 3단계를 넘으니 위임 기본값이다.

컨텍스트 오염도는 그 작업이 메인 창에 뭘 남기는지로 잰다. 파일 하나를 잠깐 열어 한 줄 고치면 흔적이 거의 없다. 반면 여러 파일을 grep하고 로그를 붙여 넣고 diff를 몇 번씩 확인하는 작업은 메인 대화창을 빠르게 어지럽힌다. 어질러진 창에서는 다음 판단도 흐려진다.

병렬 가능성은 이 작업을 서로 안 부딪히는 조각으로 쪼갤 수 있는지를 본다. 독립된 하위 작업 두세 개를 동시에 넘길 수 있으면 위임 쪽이 유리하다. 메인 루프 하나가 순서대로 처리하면 걸릴 시간을 여러 창이 동시에 나눠 쓸 수 있어서다.

검증 필요성은 결과를 다른 눈으로 한 번 더 확인해야 하는지를 묻는다. 되돌리기 어려운 변경이거나 실수의 대가가 크면 작성자와 다른 주체가 검토해야 한다. 직접 처리는 검토 단계 자체를 건너뛰기 쉬워서 이 신호가 걸리면 위임이 안전하다.

겹칠 때가 더 많다. 여러 파일을 grep하며 로그를 붙여 넣는 디버깅 작업은 작업 규모도 크고 컨텍스트 오염도도 동시에 높다. 여러 신호가 한꺼번에 걸리면 판단은 더 분명해진다. 반대로 넷 다 낮은 쪽으로 나오는 경우는 생각보다 드물다. 그래서 "직접 처리"가 기본값이 아니라 예외로 남는 게 자연스럽다.

네 신호를 다 확인했다면 마지막으로 아래 조건을 전부 만족하는지만 보면 된다. 하나라도 아니오면 위임이다.

• ☐ 허용 목록 경로에 있다(필요조건이지 그 자체로 충분조건은 아니다)
• ☐ 파일 하나로 끝난다
• ☐ 기계적이다(값 수정·주석 추가·서식 정리 수준)
• ☐ 저위험이다(되돌리기 쉽고 별도 검증이 필요 없다)

비용선은 3단계에서 엇갈린다

직접 처리와 위임은 비용의 결이 다르다. 직접 처리는 왕복이 없어서 당장은 가장 싸다. 새 세션을 띄우거나 맥락을 다시 설명할 필요가 없다. 그런데 단계가 늘어날수록 이 셈법이 뒤집힌다. 메인 창에 잘못된 가정이나 확인 안 된 코드가 그대로 쌓이고, 나중에 그걸 걷어내는 비용이 처음 아꼈던 시간을 넘어선다.

위임은 반대로 움직인다. 새 세션을 열고 맥락을 다시 패키징하는 왕복 비용이 매번 고정으로 붙는다. 대신 그 세션은 메인 창과 분리돼 있어서 실수가 나도 그 세션 안에서 끝난다. 단계 수가 하나든 다섯이든 왕복 비용은 크게 안 늘어난다.

두 선을 겹쳐 보면 교차점이 보인다. 한두 단계짜리 작업에서는 직접 처리가 이긴다. 왕복 비용을 아예 안 쓰니까. 그런데 3단계를 넘어가는 순간부터는 직접 처리 쪽에 쌓이는 오염 비용이 위임의 고정 왕복 비용을 앞지른다. 실제로 겪은 사례들도 이 지점에서 갈렸다. 한 줄 주석은 1단계라 직접 처리로 남았고, 문법 확인까지 필요한 설정 여러 줄 수정은 4단계라 뒤늦게 보니 위임했어야 할 자리였다.

교차점을 3단계 근방으로 잡는 이유는 단순하다. 한두 단계는 실수해도 그 자리에서 바로 되돌릴 수 있는 범위다. 세 단계를 넘기면 앞 단계의 판단이 뒤 단계에 그대로 얹히고, 얹힌 판단을 되돌리려면 이미 지나온 단계까지 같이 되짚어야 한다. 단계가 쌓일수록 되돌리는 비용도 같이 쌓인다.

여기서 흔히 하는 오해가 하나 있다. 위임에는 왕복 비용이 붙으니 무조건 "위임=느림"이라고 단정하는 경우다. 왕복 한 번의 지연은 실제로 존재하지만 그 지연은 작업 단계 수와 상관없이 거의 고정이다. 반면 직접 처리의 대가는 단계가 늘수록 계속 불어난다. 느리다는 인상은 첫 왕복 순간에만 느껴지고, 그 뒤로 쌓이는 청소 비용은 잘 안 보인다. 안 보이는 비용이라고 없는 비용은 아니다.

판정이 갈린 여덟 가지 사례

기준을 세워도 사례를 안 대보면 감으로 되돌아가기 쉽다. 아래는 실제로 판단이 갈렸던 경우를 정리한 표다. 단계 수만으로는 안 갈리는 경우도 일부러 섞었다.

작업	단계 수	걸린 신호	판정
설정 파일에 주석 한 줄 추가	1	없음	직접 처리
변수명 일괄 치환(파일 1개, 위치 이미 확인)	1	검증 필요성(프로덕션 코드)	위임 — 단계는 짧아도 되돌릴 때 대가가 크다
설정 값 3줄 동시 수정(문법 확인 필요)	4	작업 규모·검증 필요성	위임
신규 자동화 스크립트 100줄 작성	5+	작업 규모·컨텍스트 오염도	위임
서로 독립된 파일 세 개 리팩터링	3	병렬 가능성	위임(동시에 나눠 처리)
에러 로그 확인 후 원인 가설 세우기	2~3	컨텍스트 오염도(로그 붙여넣기)	위임
이미 결정된 오타 하나 수정	1	없음	직접 처리
새 개념 설명 문단 60줄 추가(리뷰 필요)	1	검증 필요성	위임 — 단계 하나여도 내용의 무게가 다르다

표에서 두 번째와 여덟 번째 줄을 눈여겨봐야 한다. 둘 다 겉보기 단계 수는 1이다. 그런데도 위임으로 갈렸다. 단계 수는 눈금 하나일 뿐이지 유일한 눈금이 아니다. 프로덕션 코드를 건드리거나 새로운 개념을 도입하는 변경은 손이 적게 가도 무게가 무겁다. 이럴 때는 검증 필요성이라는 다른 눈금이 최종 판정을 뒤집는다.

반대로 다섯 번째 줄은 단계 수만으론 경계선인데 병렬 가능성 하나가 판정을 넘겼다.

여섯 번째 줄도 짚을 만하다. 코드를 한 줄도 안 고쳐도 위임 판정이 날 수 있다. "고치는 작업만 위임 대상"이라는 생각도 또 하나의 착각이다.

애매하면 위임 쪽으로 기운다

네 신호와 표를 다 갖춰도 애매한 경계는 남는다. 그럼 애매할 때는 어느 쪽으로 기울어야 할까. 답은 두 실패 방향의 무게가 다르다는 데서 나온다.

위임해야 할 일을 직접 처리하는 쪽 실패는 대가가 크다 — 메인 창이 오염되고 검증 없이 통과된 변경이 남아, 나중에 원래 아끼려던 시간보다 더 많은 시간을 들여 걷어내야 한다. 반대로 직접 해도 될 일을 위임하는 쪽 실패는 왕복 한 번, 세션 하나를 새로 여는 비용 정도로 가볍게 끝난다.

판단이 반반으로 갈릴 때는 위임 쪽에 서는 편이 손해가 작다. "이 정도는 직접 해도 되지 않을까" 싶은 순간이 바로 그 신호다. 그 순간이 실제로는 판단을 건너뛰고 편한 쪽을 고르려는 신호일 때가 많았다.

이 기준을 세워 두면 판단 자체는 빨라진다. 남는 문제는 위임하기로 정한 다음이다. 무엇을 어디까지 맡길지, 완료를 무엇으로 증명할지는 AI 에이전트에게 일 맡기기 전 정해야 할 6가지를 비롯한 다른 LLM 활용 글에서 이미 정리했다. 직접 할지 위임할지를 먼저 가르고, 위임 쪽으로 정해졌다면 그다음은 그 계약으로 넘어간다. 아직 못 정한 건 신호 네 개가 서로 다른 방향을 가리킬 때 무엇을 우선할지다. 다음에 겪을 애매한 사례를 하나씩 쌓아 이 우선순위부터 채워야 한다.