-->

🎧 이 글을 오디오북으로 듣기
AI 로컬 합성 오디오북 (Qwen3-TTS)

엔터만 누르는 하루

한 개발자가 이렇게 적었습니다. “나는 서른셋인데, Claude Code가 내 뇌를 녹이고 있는 것 같다. 6개월 동안 매일 터미널을 대여섯 개씩 띄워 놓고 응답을 기다리다 90퍼센트는 그냥 엔터만 눌렀다. 그게 이제 일의 전부다. 그리고 그것이 나에게 무언가를 하고 있다.” 그는 뒤이어 이것이 도구의 문제가 아니라 도구에 기대는 자기 방식의 문제일 수 있다고 덧붙였지만, 효과는 실재한다고 말합니다.

이 짧은 고백이 개발자 커뮤니티에서 크게 번진 데는 이유가 있습니다. 많은 사람이 같은 자리에 서 있기 때문입니다. AI 코딩 에이전트를 여러 개 동시에 굴리는 방식은 이제 실험이 아니라 일상적인 작업 형태가 되었습니다. 한 사람이 병렬 워크플로로 사실상 소규모 엔지니어링 팀 하나의 처리량을 내는 방법을 다룬 안내서가 여러 곳에서 나왔고, 여러 개의 Claude Code 터미널을 한 화면에서 관리하는 도구도 등장했습니다. Anthropic 자신도 서브에이전트와 병렬 세션을 활용하는 파워 유저 팁을 공식 문서로 안내합니다. 도구는 준비되었고, 처리량은 분명히 늘었습니다. 그런데 그 처리량의 이면에서 사람의 머릿속에 무슨 일이 벌어지는지는 아직 충분히 이야기되지 않았습니다.

저는 이 글에서 그 이면을 다뤄 보려 합니다. 병렬 AI 코딩이 왜 뇌를 녹이는 것처럼 느껴지는지, 그 감각의 정체가 무엇인지, 그리고 이 문제를 개인의 의지력이 아니라 작업 구조의 문제로 다시 놓았을 때 어떤 출구가 보이는지를 순서대로 짚겠습니다. 마지막에는 이 관점이 ThakiCloud가 만드는 에이전트 플랫폼의 설계와 어떻게 맞닿는지도 이야기하겠습니다.

‘멀티 클로딩’이라는 새로운 노동

먼저 이 노동의 실제 모양을 정확히 그려 보겠습니다. 병렬 AI 코딩, 흔히 ‘멀티 클로딩’이라 불리는 이 방식은 대략 이렇게 흘러갑니다. 화면을 분할해 터미널을 대여섯 개 띄웁니다. 각 터미널에는 서로 다른 작업을 맡깁니다. 하나는 버그를 고치게 하고, 하나는 테스트를 쓰게 하고, 하나는 리팩터링을 시키고, 하나는 문서를 정리하게 합니다. 하나가 답을 내놓는 동안 다른 터미널로 시선을 옮겨 다음 지시를 넣습니다. 응답이 오면 대개는 내용을 꼼꼼히 읽기보다 그럴듯해 보이면 승인하고 다음으로 넘어갑니다. 그 승인의 물리적 형태가 바로 엔터입니다.

이 방식은 겉으로 보면 대단히 생산적입니다. 사람 하나가 네다섯 갈래의 작업을 동시에 진행시키니, 단순 산술로는 그만큼 빨라집니다. 실제로 처리량은 늘어납니다. 문제는 이 처리량의 단위가 코드가 아니라 사람의 주의라는 데 있습니다. 병렬 처리의 부담이 기계에서 사람으로 조용히 옮겨 온 것입니다. 컴퓨터에게 병렬은 자원을 나눠 쓰는 일이지만, 사람에게 병렬은 하나뿐인 주의를 계속 쪼개는 일입니다. 그리고 사람의 주의는 나눌수록 늘어나는 자원이 아니라, 나눌수록 닳는 자원입니다.

뇌가 녹는다는 감각의 정체

“뇌가 녹는다”는 표현은 과장된 비유처럼 들리지만, 그 안에는 인지과학이 오래 관찰해 온 몇 가지 구체적인 현상이 겹쳐 있습니다.

첫째는 주의 잔여물입니다. 한 작업에서 다른 작업으로 시선을 옮길 때, 우리 머릿속의 주의는 즉시 따라오지 않습니다. 이전 작업의 잔상이 얼마간 남아 다음 작업의 집중을 갉아먹습니다. 터미널을 여섯 개 오가면 이 전환이 하루에 수백 번 일어납니다. 각 전환의 손실은 작지만, 누적되면 하루의 끝에 남는 것은 무엇 하나 깊이 붙들지 못한 채 표면만 훑은 피로입니다.

둘째는 몰입의 붕괴입니다. 개발자가 가장 좋은 코드를 짜는 상태는 하나의 문제에 깊이 잠겨 맥락 전체를 머릿속에 올려 둔 몰입 상태입니다. 병렬 감시는 이 상태와 정면으로 충돌합니다. 몰입은 방해받지 않는 연속된 시간을 먹고 자라는데, 여섯 개의 터미널은 그 시간을 끊임없이 잘게 부숩니다. 결국 어느 작업도 몰입의 깊이에 도달하지 못한 채 얕은 관리만 반복하게 됩니다.

셋째는 수동적 감시의 함정입니다. 응답의 90퍼센트를 읽지 않고 승인한다는 고백이 정확히 이 지점을 찌릅니다. 자동화가 대부분의 경우 잘 작동하면, 사람은 점점 그것을 신뢰하고 검토를 멈춥니다. 항공 안전 연구에서 오래전부터 경고해 온 자동화 유발 안일함과 같은 구조입니다. 문제는 그 방심한 10퍼센트 안에 진짜 위험한 결정이 숨어 있을 때입니다. 감시자는 대부분의 시간 동안 아무것도 안 하다가, 정작 판단이 필요한 순간에는 이미 판단 근육이 무뎌져 있습니다.

넷째는 탈숙련의 위험입니다. 스스로 문제를 붙들고 씨름하며 얻는 이해와, 에이전트가 내놓은 답을 승인하며 지나가는 이해는 다릅니다. 전자는 근육을 만들고 후자는 근육을 쓰지 않습니다. 매일 엔터만 누르는 하루가 반복되면, 예전만큼 날카롭지 않다는 그 개발자의 자기 관찰은 엄살이 아니라 정직한 관찰일 수 있습니다.

flowchart TB 사람["사람: 하나뿐인 주의"] --> T1["터미널 1
응답 대기"] 사람 --> T2["터미널 2
응답 대기"] 사람 --> T3["터미널 3
응답 대기"] 사람 --> T4["터미널 4
응답 대기"] T1 -.엔터.-> 승인["대충 승인
90퍼센트 미검토"] T2 -.엔터.-> 승인 T3 -.엔터.-> 승인 T4 -.엔터.-> 승인 승인 --> 비용["주의 잔여물
몰입 붕괴
수동적 감시
탈숙련"]

감시자에서 오케스트레이터로

여기서 흔한 처방은 개인의 의지에 호소하는 것입니다. 터미널 개수를 줄여라, 한 번에 하나에 집중해라, 응답을 꼼꼼히 읽어라. 다 옳은 말이지만, 처리량이라는 강력한 유혹 앞에서 의지력만으로 버티는 전략은 대개 오래가지 못합니다. 저는 이 문제를 의지의 문제가 아니라 작업 구조의 문제로 다시 놓아야 한다고 생각합니다.

핵심 질문은 이것입니다. 사람은 왜 여섯 개의 터미널을 직접 감시하고 있어야 할까요. 그 이유는 대개, 에이전트가 내놓은 결과가 맞는지 틀렸는지를 사람이 직접 눈으로 확인해야만 하기 때문입니다. 검증의 책임이 전적으로 사람의 눈에 걸려 있으니, 사람은 모든 터미널 옆에 붙어 있을 수밖에 없습니다. 엔터를 누르는 손가락은 사실 검증기 역할을 대신하고 있는 셈입니다. 그리고 그 검증은 대충일 수밖에 없습니다.

출구는 검증의 책임을 사람의 눈에서 코드로 옮기는 것입니다. 에이전트의 결과를 사람이 승인하는 대신, 결정론적인 게이트가 판정하게 만드는 것입니다. 테스트를 통과했는가, 타입 체크가 맞는가, 정책 위반은 없는가. 이런 것들은 사람이 읽어야 확인되는 판단이 아니라, 명령 하나로 통과와 실패가 갈리는 객관적 신호입니다. 팬아웃한 여러 에이전트의 결과를 합치기 전에, 서로 다른 시각을 가진 검증 단계가 그 결과를 반증하듯 감사하게 만들 수도 있습니다. 이렇게 되면 사람은 여섯 개의 터미널을 감시하는 감시자에서, 무엇을 만들지 설계하고 게이트가 걸러 낸 결과만 판단하는 오케스트레이터로 자리를 옮깁니다.

flowchart TB 설계["사람: 설계와 판단"] --> 오케["오케스트레이터"] 오케 --> A1["에이전트 1
격리 샌드박스"] 오케 --> A2["에이전트 2
격리 샌드박스"] 오케 --> A3["에이전트 3
격리 샌드박스"] A1 --> 게이트{"검증 게이트
테스트·정책·감사"} A2 --> 게이트 A3 --> 게이트 게이트 -.통과분만.-> 설계

차이는 미묘해 보이지만 결정적입니다. 감시자 모델에서 사람의 주의는 모든 병렬 갈래에 얇게 발려 있습니다. 오케스트레이터 모델에서 사람의 주의는 두 지점에만 모입니다. 무엇을 위임할지 정하는 앞단과, 게이트를 통과한 소수의 결과를 판단하는 뒷단입니다. 그 사이의 지루한 대기와 대충 승인은 사람이 아니라 코드가 소유합니다. 처리량은 유지되거나 오히려 늘지만, 사람의 인지 부하는 극적으로 줄어듭니다.

ThakiCloud 제품 적용 시사점

이 관점은 저희가 만드는 Paxis의 설계 철학과 정확히 맞닿아 있습니다. Paxis는 ThakiCloud의 ai-platform 위에서 도는 Agent-Native Cloud 제어 평면으로, 스킬과 도구와 정책과 감사 로그를 일급 리소스로 다룹니다. 여기서 병렬 에이전트는 사람이 터미널마다 붙어 감시하는 대상이 아니라, 오케스트레이터가 위임하고 게이트가 걸러 내는 자율 실행 단위입니다.

구체적으로 몇 가지가 앞서 말한 출구를 그대로 구현합니다. 각 에이전트는 격리된 샌드박스에서 실행되므로 서로의 절반쯤 끝난 작업을 오염시키지 않습니다. 사람이 여섯 개의 작업 상태를 머릿속에 동시에 올려 둘 필요가 줄어듭니다. 팬아웃한 결과는 정책 게이트와 감사 로그를 통과해야 하며, 저희는 실제로 팬아웃한 작업을 반드시 검증 단계로 닫는다는 규율을 운영에 못 박아 두었습니다. 코드 산출물은 테스트 실행 결과로, 판단이 필요한 산출물은 서로 다른 시각의 적대적 검증으로 걸러 냅니다. 검증의 책임이 사람의 눈이 아니라 코드에 있으니, 개발자는 엔터를 누르는 감시자가 아니라 방향을 정하는 사람으로 남을 수 있습니다.

여기에 ai-platform의 인프라 관점이 더해집니다. 이렇게 위임된 에이전트들은 K8s와 Kueue가 관리하는 GPU 자원 위에서 스케줄링되며, 멀티테넌트로 격리됩니다. 자율 실행의 처리량을 인프라가 떠받치고, 검증 게이트가 품질을 지키고, 사람은 설계와 판단이라는 가장 사람다운 일에 주의를 모읍니다. 저비용의 자율 실행이 에이전트 경제성을 만들고, 그 경제성이 다시 사람을 반복 감시에서 해방합니다. 병렬 AI 코딩의 인지 비용 문제는, 결국 사람을 병렬 처리의 부담에서 끌어내리는 플랫폼 설계로 풀리는 문제입니다.

한계 및 반론

이 이야기에는 정직하게 짚어야 할 반론이 있습니다.

첫째, 처음 그 개발자가 인정했듯 이것이 정말 도구가 아니라 사람의 문제일 가능성입니다. 어떤 사람은 병렬 감시를 능숙하게 다루며 별다른 인지 피로를 느끼지 않을 수 있습니다. 인지 부하는 개인차가 크고, 하나의 일화를 모두의 진단으로 일반화하는 것은 위험합니다. 다만 같은 고백이 광범위하게 공감을 얻었다는 사실은, 이것이 소수의 예외가 아니라 구조가 만들어 내는 흔한 경험일 가능성을 시사합니다.

둘째, 오케스트레이션 자체가 새로운 인지 부하를 만든다는 점입니다. 위임을 잘하려면 무엇을 어떻게 쪼갤지, 어떤 게이트로 검증할지를 설계해야 하고, 이 설계는 결코 공짜가 아닙니다. 감시의 부담을 설계의 부담으로 옮긴 것에 불과하다는 비판이 가능합니다. 그러나 두 부담은 성질이 다릅니다. 감시는 하루 종일 얇게 지속되는 반응적 부담이고, 설계는 앞단에 집중되는 능동적 부담입니다. 후자가 사람의 성장과 숙련에 훨씬 가깝습니다.

셋째, 게이트가 만능이 아니라는 점입니다. 검증 게이트가 잡지 못하는 종류의 결함이 분명히 있습니다. 게이트가 아무것도 걸러 내지 않는다면 그것은 완벽함의 신호가 아니라 게이트가 무력하다는 신호입니다. 검증을 코드로 옮긴다고 해서 사람의 판단이 사라지는 것은 아니며, 오히려 게이트가 걸러 낸 소수의 결과에 사람의 판단을 온전히 쏟는 것이 이 구조의 핵심입니다. 자동화는 사고를 대체하는 도구가 아니라 사고를 가장 필요한 곳으로 모아 주는 도구여야 합니다.

엔터만 누르다 뇌가 녹는다는 감각은 도구를 탓할 이유가 아니라, 우리가 도구와 함께 일하는 구조를 다시 설계하라는 신호입니다. 감시자로 남을지 오케스트레이터가 될지는 결국 개인의 의지가 아니라, 검증의 책임을 어디에 둘 것인가라는 설계 결정에 달려 있습니다.

출처

참고