안녕하세요? 정리하는 개발자 워니즈입니다.
Claude Code 자동화로 에이전트를 밤새 돌려도 판단이라는 일은 사라지지 않고 자리만 옮긴다는 글을 읽었는데요 에이전트 수는 얼마든지 늘릴 수 있지만 사람의 인지 대역폭은 같은 비율로 늘지 않는다는 지적이 특히 오래 남았습니다. 필자도 개인 블로그 운영을 에이전트에게 맡겨 하루 네 번씩 자동으로 돌리고 있어서 이 주장을 제 장치에 그대로 대입해봤는데요 최근 2주 사이에 운영 방향이 바뀐 결정을 세어보니 세 건이 전부 사람이 내린 것이었습니다.
당장 쓸 수 있는 기준은 한 줄인데요 자동화를 설계할 때 무엇을 맡길지 목록을 만들기 전에 사람 판단을 어느 위치에 배치할지부터 정하는 것입니다.
- 에이전트는 실행의 양을 늘려줬지만 결정의 개수는 하나도 줄여주지 않았습니다.
- 검사가 전부 통과해도 그 통과를 믿을지 말지는 여전히 사람이 정하는 일이었습니다.
- 판단이 필요한 위치를 미리 정해두지 않으면 판단할 일이 쌓이는 자리도 보이지 않았습니다.
기사가 꼽은 사람 몫은 명세 확정, 제품 의도 확인, 회귀 판정, 품질 기준 네 가지였습니다. 필자의 자동 운영에서 방향을 바꾼 결정도 예외 없이 이 네 자리에서 나온 것 같습니다.
에이전트를 늘리면 사람이 할 일도 같이 줄어들까요?
줄어드는 것은 실행이고 판단은 오히려 한곳으로 몰립니다. 병렬로 도는 에이전트가 늘어날수록 결과를 읽고 승인해야 하는 사람의 주의는 그대로라서 판단을 배치할 위치를 정해두지 않으면 검토가 병목이 되거나 검토 없이 그냥 흘러가거나 둘 중 하나가 됩니다.
GeekNews 에 올라온 인간의 판단은 소프트웨어 공장을 떠나지 않는다는 글이 이 구도를 정리하고 있었는데요 글쓴이는 Claude Code 같은 코딩 에이전트를 이벤트 기반 큐에 붙여 반복 실행하는 구조를 소프트웨어 공장이라고 부르면서 공장이 좋아질수록 사람이 사라지는 것이 아니라 의도와 위험과 취향이 걸린 지점으로 사람이 이동한다고 썼습니다. 수십 개의 에이전트를 병렬로 돌려도 사람의 인지 대역폭은 같은 비율로 늘지 않아서 생성된 코드와 결정 이유를 따라가지 못하면 이해 부채가 쌓인다는 것이 글의 뼈대였습니다.
기사가 꼽은 사람 판단이 반드시 필요한 위치 4가지
글쓴이는 자율성을 높이고 싶다면 오히려 사람 검토가 반드시 들어가야 하는 위치부터 정해야 한다면서 네 곳을 꼽았습니다.
1. 명세와 요구사항 무엇을 만들지 정하는 일은 시작부터 사람 몫입니다.
2. 제품 의도와 디자인의 완료 판정 만들어진 것이 의도에 맞는지는 에이전트가 스스로 답할 수 없습니다.
3. 기존 시스템의 회귀 여부 새 변경이 원래 되던 것을 깨뜨리지 않았는지 보는 일입니다.
4. 품질 기준의 충족 여부 어디까지가 통과인지 기준선을 긋는 일 자체가 판단입니다.
거꾸로 말하면 이 네 곳만 사람이 쥐고 있으면 코드 생성 자체는 걱정거리가 아니라는 이야기인데요 코드 전체를 사람이 다 읽는 것은 어차피 현실적이지 않으니 위험한 자리에 주의를 몰아주라는 배치의 문제로 읽혔습니다.
검사가 전부 초록색이어도 왜 안심할 수 없을까요?
Claude Code 자동화에서 검사 통과는 규칙 위반이 없다는 사실이지 의도가 지켜졌다는 증거가 아니기 때문입니다. 에이전트는 테스트를 통과하라는 요청에 테스트 자체를 바꾸거나 조건만 맞도록 논리를 고칠 수 있어서 결과가 전부 초록색이어도 그 초록색이 무엇을 보고 있는지는 따로 확인해야 합니다.
기사에서 가장 뜨끔했던 대목이 여기였는데요 필자도 자동 운영 슬롯의 성공률을 세어봤을 때 실패의 대부분이 코드가 아니라 완료 판정 쪽에 있었던 경험이 있어서, 검사를 늘리는 것과 검사를 믿을 수 있게 만드는 것이 다른 작업이라는 지적에 동의하게 됐습니다. 완료했다는 말과 완료됐다는 확인이 서로 다른 정보라는 것은 AI 의 완료 보고를 그대로 믿지 않게 된 기록에서도 겪은 적이 있습니다. 글쓴이는 이것을 검증 예산이라고 불렀는데요 싸고 빠른 검사는 루프 앞쪽에 두고 비싼 검사는 병합 직전에 배치하되 검사 개수가 품질과 같지는 않다는 조언이 붙어 있었습니다.
제 자동 운영에서 방향을 바꾼 결정은 전부 사람이 내렸습니다
기사 주장을 제 블로그 자동 운영 장치에 대입해서 최근 2주간 운영 규칙이 바뀐 순간을 세어봤는데요 세 건이 나왔고 셋 다 에이전트가 아니라 사람의 결정이었습니다.
첫 번째는 하루 발행량을 줄인 결정입니다. 글을 세 편 올린 날의 방문 흐름이 답글만 성실히 단 날의 3분의 1에 그친다는 실측이 나왔을 때 숫자를 만든 것은 자동화였지만 발행을 하루 한 편으로 줄이고 남는 시간을 전부 소통에 쓰자고 방향을 튼 것은 사람이었습니다. 품질 기준을 어디에 둘지 다시 그은 셈입니다.
두 번째는 제목 표기 방식을 되돌린 결정입니다. 검색 결과에서 잘릴 위험과 블로그 목록에서의 가독성이 충돌하는 상황이었는데요 에이전트는 양쪽의 근거를 실측해서 올려줬지만 무엇을 감수할지 고르는 일은 결국 운영자의 취향과 책임이었습니다. 기사가 말한 제품 의도의 자리였던 것 같습니다.
세 번째는 주제 배분을 바로잡은 결정입니다. 글감이 운영 이야기 한쪽으로 쏠리고 있다는 것을 발견하고 배분 규칙을 새로 만든 것도 사람이었는데요 에이전트는 정해진 규칙 안에서는 성실했지만 규칙 자체가 기울었다는 사실은 규칙 밖에서만 보였습니다. 명세를 고치는 일은 명세 안에서 나오지 않았습니다.
에이전트에 맡긴 것과 사람이 쥐고 있는 것을 갈라봤습니다
| 자리 | 에이전트가 한 일 | 사람이 한 일 |
|---|---|---|
| 발행량 | 두 배분안의 성적을 실측 | 발행을 줄이는 결정 |
| 제목 표기 | 잘림 위험과 가독성 근거 수집 | 무엇을 감수할지 선택 |
| 주제 배분 | 규칙 안에서 성실한 실행 | 규칙이 기울었다는 발견 |
| 검사 | 통과와 차단 판정 | 그 검사를 믿을지 판정 |
이렇게 갈라놓고 보니 AI 에이전트에게 일을 넘기는 것 자체가 공짜가 아니라던 이전 기록과 같은 결론에 닿는 것 같습니다. 넘긴 일은 줄었는데 넘긴 일이 잘됐는지 보는 일이 새로 생겼고, 그 일은 어디에도 위임되지 않았습니다.
Claude Code 자동화 설계의 본체는 판단의 배치였습니다
Claude Code 자동화를 검토하고 계시다면 에이전트에게 맡길 작업 목록보다 사람 판단이 반드시 통과해야 하는 관문의 위치를 먼저 정해보시길 권해드리고 싶습니다. 필자의 경우 명세를 고치는 일, 완료라고 부를 기준을 긋는 일, 검사를 믿을지 정하는 일이 그 관문이었는데요 이 자리들은 자동화가 좋아질수록 없어지는 것이 아니라 더 또렷해지는 것 같습니다.
다음으로 확인할 것: 기사가 권한 대로 위험도별로 검사 배치를 다시 그려보고 사람 검토가 밀리면 발행을 멈추는 지점을 장치에 명시해볼 예정입니다.