에이전트가 늘어날수록 개발이 느려지는 이유와 그 병목을 푸는 작업 공간

동시에 돌아가는 자동 코딩 실행기가 많아질수록 화면은 더 똑똑해지는 것이 아니라, 오히려 더 쉽게 막힌다. 이상하게 들리지만 현장에서는 이 역설이 아주 자주 반복된다. 처음에는 하나의 창에서 한 번에 하나의 답만 오가던 흐름이 꽤 효율적으로 보인다. 그런데 수정, 검색, 테스트, 문서 확인, 리팩터링, 버그 재현 같은 일을 여러 실행 주체에게 나눠 맡기기 시작하는 순간부터 속도의 정의가 바뀐다. 더 빠른 생성이 아니라, 더 적은 충돌과 더 낮은 대기 시간이 진짜 생산성을 좌우한다.

이 지점에서 흥미로운 변화가 보인다. IDE가 더 이상 편집기와 채팅창의 조합으로만 남지 않고, 여러 작업 흐름을 한 화면에서 배치하고 격리하고 합류시키는 조정 계층으로 바뀌기 시작한 것이다. Orca 같은 흐름이 주목받는 이유도 여기에 있다. 핵심은 “여러 자동 코딩 실행기를 붙일 수 있다”는 문장 자체가 아니다. 더 중요한 것은 그 실행기들이 동시에 움직일 때, 누가 어떤 문맥을 들고 있고, 어느 파일 계층에서 작업하고 있으며, 언제 충돌 없이 결과를 합칠 수 있는지를 화면과 실행 환경이 함께 책임질 수 있느냐는 점이다.

느려지는 원인은 계산량보다 경합에 있다

많은 팀이 처음 병렬 자동화를 도입할 때 착각하는 것이 있다. 실행 주체를 둘에서 넷으로, 넷에서 여덟으로 늘리면 처리량도 비슷한 비율로 늘어날 것이라고 기대한다. 실제로는 그 반대가 자주 일어난다. 각 실행 주체가 똑같은 파일을 읽고, 비슷한 테스트를 돌리고, 같은 에러를 서로 다른 방식으로 해석하기 시작하면 병목은 연산이 아니라 경합에서 생긴다.

경합은 여러 층위에서 나타난다. 가장 단순한 것은 파일 충돌이다. 같은 컴포넌트의 다른 부분을 고친다고 생각했는데 import 순서나 타입 정의 하나 때문에 변경 범위가 겹친다. 그다음은 실행 환경 충돌이다. 한쪽은 의존성을 올리고 다른 쪽은 기존 잠금 파일을 기준으로 테스트를 돌리면 결과가 일관되지 않는다. 더 미묘한 문제는 문맥 충돌이다. 어떤 실행 주체는 버그 수정이 우선이라고 판단하고, 다른 하나는 구조 개선을 먼저 한다. 둘 다 나름대로는 합리적이지만 합쳐 놓으면 되레 상태가 나빠진다.

사람이 여러 명일 때도 벌어지는 일 아닌가 싶지만, 자동 코딩 실행기에서는 이 문제가 더 자주 터진다. 이유는 속도 때문이다. 사람은 대개 눈치를 보고 멈춘다. 반면 자동화된 실행 주체는 멈추지 않는다. 문맥이 불완전해도 끝까지 전개해 버린다. 그래서 병렬성은 쉽게 확보되지만, 조율 비용은 더 가파르게 커진다.

한 화면의 문제는 사실 한 화면이 아니라 한 문맥의 문제다

기존 개발 도구의 기본 가정은 꽤 단순했다. 한 명이 한 브랜치에서 한 작업을 한다는 전제다. 그래서 탭과 패널을 늘리는 방식만으로도 어느 정도 버텼다. 하지만 여러 자동 코딩 실행기가 동시에 움직이는 상황에서는 화면 분할 자체보다 중요한 것이 있다. 각 결과물이 어떤 문맥에 속하는지를 사람이 즉시 구분할 수 있어야 한다는 점이다.

문맥은 단순한 대화 기록이 아니다. 어떤 파일 집합을 기준으로 판단했는지, 어떤 테스트 결과를 보고 행동했는지, 현재 수정이 기능 추가인지 결함 수정인지, 더 넓게는 이 변경이 어느 실행 단위에서 나왔는지까지 포함한다. 화면이 진짜 해야 할 일은 텍스트를 많이 보여주는 것이 아니라, 이 문맥의 경계를 시각적으로 유지하는 것이다. 경계가 무너지면 결과는 금방 채팅창의 홍수로 바뀐다.

그래서 병렬 자동화 시대의 IDE는 “응답을 잘 보여주는 도구”보다 “작업 단위를 격리하는 도구”에 가까워진다. 파일 트리, diff, 로그, 테스트 결과, 실행 이력, 승인 상태가 한데 섞여 보이면 읽는 사람은 더 많이 보면서도 덜 이해하게 된다. 반대로 각 흐름이 독립된 작업 공간과 변경 집합을 유지하면, 화면은 오히려 더 복잡해 보여도 실제 판단은 쉬워진다.

worktree가 다시 중요해지는 이유

여러 실행 주체를 동시에 다룰 때 git worktree 같은 방식이 자주 다시 호출되는 이유는 단순하다. 브랜치만 다르고 실제 파일 계층은 같은 상태로 놓아두면, 병렬 실행은 곧바로 상호 오염으로 이어지기 때문이다. 하나의 작업이 node_modules와 빌드 산출물, 캐시, 로컬 설정까지 바꾸는 순간 다른 실행 흐름은 같은 바닥을 공유하면서도 서로 다른 세계를 상상하게 된다.

worktree는 이 문제를 원시적이지만 강력하게 잘라낸다. 각 작업 흐름이 별도 체크아웃을 갖게 되면 파일 충돌만 줄어드는 것이 아니다. 테스트 재현성이 좋아지고, 롤백 판단이 쉬워지며, 무엇보다 “누가 어디를 기준으로 작업했는지”가 명확해진다. 병렬 자동화에서 진짜 중요한 것은 실행 주체의 수보다 작업 경계의 선명도다. worktree는 바로 그 경계를 파일 시스템 수준에서 강제한다.

다만 이것도 만능은 아니다. worktree를 여러 개 열어 놓기만 하면 해결될 것 같지만, 운영 비용은 금방 드러난다. 의존성 설치가 중복되고, 인덱싱 비용이 늘고, 언어 서버가 메모리를 더 먹고, 테스트 캐시 전략이 꼬인다. 데스크톱 환경에서는 그럭저럭 버틸 수 있어도 모바일이나 저사양 장비까지 고려하면 “격리”와 “복제”는 같은 말이 아니라는 사실이 선명해진다. 잘 설계된 도구는 worktree를 많이 만드는 것이 아니라, 필요한 수준만큼만 분리하고 나머지는 최대한 공유하는 균형점을 찾아야 한다.

병렬성의 적은 CPU가 아니라 승인 지연이다

현장에서 자주 놓치는 지표가 있다. 자동 코딩 실행기의 속도를 평가할 때 토큰 처리량이나 응답 시간만 보는 습관이다. 하지만 여러 흐름이 동시에 도는 환경에서 실제 체감 속도를 떨어뜨리는 가장 큰 요인은 승인 지연이다. 네 개의 실행 주체가 각각 3분 만에 수정안을 내놓아도, 사람이 어느 것을 채택할지 15분 동안 결정하지 못하면 전체 시스템은 느린 것이다.

이 병목은 화면 설계와 직접 연결된다. 변경 이유가 보이지 않는 diff, 테스트 실패의 맥락이 사라진 로그, 어디까지 자동 적용되었는지 불분명한 상태 표시는 모두 승인 지연을 부른다. 반대로 승인 비용을 낮추는 도구는 병렬 실행의 효과를 크게 끌어올린다. 변경 요약이 짧고 정확해야 하고, 테스트 범위가 명확해야 하며, 서로 충돌하는 수정안이 한눈에 비교 가능해야 한다. 결국 좋은 자동화 환경은 “더 많은 제안”을 만드는 쪽보다 “더 빨리 버릴 수 있는 제안”을 만드는 쪽에 가깝다.

이 관점에서 보면 IDE의 역할도 달라진다. 편집을 돕는 도구에서 의사결정 지연을 줄이는 콘솔로 바뀐다. 한 화면에서 여러 흐름을 본다는 말은, 단순히 여러 패널을 띄운다는 뜻이 아니다. 같은 문제를 두세 방식으로 풀어본 결과를 비교하고, 신뢰할 수 없는 흐름을 빨리 폐기하고, 살아남은 결과만 메인 라인으로 합류시키는 운영 인터페이스가 필요하다는 뜻이다.

채팅창 중심 경험이 금방 한계에 닿는 순간

초기의 자동 코딩 경험이 채팅창 중심이었던 것은 자연스러운 출발점이었다. 질문을 던지고 답을 받는 방식은 배우기 쉽고 진입 장벽이 낮다. 문제는 병렬화가 시작되면 이 구조가 거의 바로 무너진다는 점이다. 채팅은 시간 순서를 잘 보여주지만, 작업 순서를 잘 보여주지는 못한다. 그리고 병렬 작업 환경에서는 시간보다 작업 순서가 중요하다.

예를 들어 하나의 실행 흐름은 로그 분석을 하고, 다른 흐름은 타입 오류를 정리하고, 또 다른 흐름은 테스트 픽스를 시도한다고 하자. 이 셋의 결과를 채팅창에 시간순으로 흘려보내면, 사람은 실제로는 세 갈래의 작업 트리를 머릿속에서 수동으로 재구성해야 한다. 결국 많은 메시지를 읽었지만 적은 결정을 내리게 된다. 이것이 “자동화는 늘었는데 개발은 더 느려졌다”는 체감의 핵심이다.

그래서 앞으로의 도구는 채팅을 없애기보다 채팅을 주변화할 가능성이 크다. 대화는 여전히 필요하지만 중심은 아니다. 중심은 작업 그래프, 변경 집합, 실행 상태, 승인 큐, 충돌 시그널이다. 대화는 그 옆에서 이유를 보충하는 역할로 내려온다. 이 전환을 받아들이지 못하면 자동화는 계속 많아지는데도 화면은 계속 산만해질 것이다.

모바일까지 내려오면 본질이 더 잘 보인다

데스크톱에서는 자원이 많기 때문에 문제를 가리기 쉽다. 창을 더 띄우고, 메모리를 더 쓰고, 백그라운드 프로세스를 더 돌리면 일단 돌아간다. 하지만 모바일 지원을 이야기하는 순간 무엇이 본질이고 무엇이 사치인지 금방 드러난다. 작은 화면과 제한된 입력 장치는 “모든 정보를 동시에 보여주겠다”는 태도를 바로 벌준다.

이 환경에서 살아남는 인터페이스는 대개 세 가지 특성을 가진다. 첫째, 현재 결정에 필요한 정보만 전면으로 올린다. 둘째, 자동화 흐름 간의 경계를 강하게 유지한다. 셋째, 승인과 폐기 같은 핵심 조작을 짧은 동선으로 압축한다. 즉, 모바일 대응은 단순한 화면 축소가 아니라 오케스트레이션 구조의 정리 작업이다.

이 점이 중요하다. 여러 자동 코딩 실행기를 진짜 운영 가능한 수준으로 다루려면 결국 화면이 아니라 모델이 단순해야 한다. 어떤 실행 단위가 어떤 입력을 받고 어떤 파일을 바꾸며 어떤 검증을 통과했는지, 그 흐름이 압축된 상태 객체로 존재해야 한다. 그래야 작은 화면에서도 다룰 수 있다. 데스크톱 중심 사고에서는 이 구조적 단순화가 종종 미뤄지지만, 모바일 문턱을 넘으려는 순간 더는 피할 수 없어진다.

생산성이 아니라 운영성이 승부를 가른다

자동 코딩 실행기를 이야기할 때 생산성이라는 단어가 너무 쉽게 앞에 나온다. 몇 퍼센트 빨라졌는지, 몇 시간을 줄였는지 같은 숫자는 매력적이다. 그러나 병렬 실행 환경에서 더 오래 남는 질문은 운영성이다. 이 흐름은 실패했을 때 추적 가능한가. 잘못된 수정이 들어왔을 때 원인을 특정할 수 있는가. 누가 어떤 기준으로 승인했는지 남는가. 특정 실행 주체가 반복적으로 같은 유형의 실수를 내면 이를 정책으로 막을 수 있는가.

이 질문들은 결국 도구의 성격을 바꾼다. 단순한 생성 도구는 결과를 내놓으면 끝나지만, 병렬 자동화 플랫폼은 상태를 관리해야 한다. 실행 주체의 수가 늘어날수록 필요한 것은 더 강한 마법이 아니라 더 좋은 회계다. 어떤 변경이 어디서 나왔는지, 어떤 자원을 썼는지, 어떤 검증을 통과했는지, 언제 폐기되었는지를 남겨야 한다. 그래야 속도 향상이 일시적 해프닝이 아니라 지속 가능한 운영 방식이 된다.

여기서 많은 팀이 처음 겪는 함정도 보인다. 결과가 그럴듯하면 바로 메인 브랜치로 합치고 싶어진다. 하지만 자동화된 병렬 흐름은 사람보다 쉽게 “겉보기 그럴듯함”을 만든다. 정작 중요한 것은 수정 자체가 아니라 수정 경로의 신뢰도다. 어떤 정보에 근거했는지 अस्पष्ट한 결과는 짧게는 편하지만 길게는 비싸다. 운영성이 약한 자동화는 대체로 초반 체감은 강하고, 몇 달 뒤 피로도는 더 크다.

가장 좋은 구조는 늘리는 구조가 아니라 줄이는 구조다

여러 자동 코딩 실행기를 도입한다고 해서 모든 일을 병렬로 돌릴 필요는 없다. 오히려 잘 작동하는 팀은 어디를 병렬화하지 않을지 먼저 정한다. 검색과 초안 제안, 테스트 재현, 로그 분류, 코드 읽기처럼 독립성이 높은 작업은 병렬성이 잘 먹힌다. 반면 동일한 파일 묶음에 대한 구조 변경, 데이터 흐름 개편, 핵심 타입 재설계처럼 결합도가 높은 작업은 병렬성의 이익보다 충돌 비용이 더 크다.

좋은 도구는 바로 이 선택을 쉽게 만들어야 한다. 무엇이 병렬 후보인지, 무엇이 단일 흐름으로 묶여야 하는지, 어디에서 worktree를 분리하고 어디에서는 같은 맥락을 공유해야 하는지를 사용자가 빠르게 판단할 수 있어야 한다. 기능이 많다고 좋은 것이 아니라, 병렬 실행의 적정 수준을 발견하게 도와줄 때 비로소 좋은 도구가 된다.

예를 들면 이런 식의 운영 감각이 필요하다.

git worktree add ../fix-auth bugfix/auth-timeout
git worktree add ../refactor-cache refactor/cache-boundary

중요한 것은 명령 두 줄 자체가 아니라, 서로 다른 성격의 작업을 물리적으로 분리해 충돌 가능성을 낮춘다는 태도다. 병렬성은 늘릴수록 좋은 자원이 아니라, 올바른 경계 위에서만 이익이 나는 자원이다.

앞으로의 IDE는 편집기보다 관제실에 가까워진다

Orca 같은 흐름이 던지는 신호는 꽤 선명하다. 개발 도구의 중심축이 “내가 직접 고치는 시간”에서 “여러 자동 실행 흐름을 조율하는 시간”으로 이동하고 있다는 것이다. 이것은 채팅이 편집기를 대체한다는 뜻도 아니고, 자동화가 사람을 밀어낸다는 뜻도 아니다. 오히려 반대에 가깝다. 사람이 진짜 집중해야 할 일이 키 입력이 아니라 경계 설정, 우선순위 판단, 승인 정책, 병합 타이밍으로 이동한다는 뜻이다.

그래서 앞으로의 경쟁력은 더 화려한 답변을 뽑아내는 데 있지 않을 가능성이 크다. 더 중요한 것은 서로 다른 실행 흐름을 얼마나 안전하게 분리하고, 얼마나 빠르게 비교하고, 얼마나 싸게 폐기할 수 있느냐다. 이 기준에서 보면 IDE는 지식 도구이면서 동시에 운영 도구다. 파일을 여는 프로그램이 아니라, 병렬 작업을 믿을 수 있는 상태로 유지하는 조정 시스템에 가까워진다.

개발이 느려지는 이유는 자동화가 부족해서가 아니라, 자동화가 늘어난 뒤에 생기는 경합을 다룰 구조가 없어서인 경우가 많다. 여러 실행 주체를 한 화면과 여러 worktree 위에서 다룬다는 발상은 단순한 편의 기능처럼 보이지만, 실제로는 이 경합을 제어하기 위한 기초 체력에 가깝다. 병목을 푼다는 것은 더 많은 것을 동시에 시키는 일이 아니라, 서로 다른 흐름이 서로를 망치지 않도록 만드는 일이다.

병렬성의 시대에 개발 속도를 결정하는 것은 얼마나 많은 자동 코딩 실행기를 붙였는지가 아니다. 그들을 얼마나 잘 떨어뜨려 놓고, 얼마나 잘 다시 만나게 하느냐다. 그 차이가 보이기 시작하는 순간, 채팅창 하나로는 설명되지 않던 답답함의 정체도 함께 드러난다.

댓글

댓글을 읽어오는 중입니다.