구글 앤티그래비티 : 개발자가 지휘자가 되는 IDE

오케스트라의 지휘자는 악기를 거의 연주하지 않습니다. 그의 손에는 얇은 지휘봉 하나가 전부이고, 연주 내내 그가 내는 소리는 없지요. 그렇다고 그의 역할이 사소한가 하면 전혀 그렇지 않습니다. 수십 명의 연주자가 같은 박자로, 같은 감정으로, 같은 곡을 향해 달릴 수 있도록 만드는 일은 악기 하나를 잘 연주하는 것과는 완전히 다른 차원의 기술입니다. 지휘자는 연주하지 않지만, 연주보다 더 깊게 음악을 만듭니다.

최근 몇 달 사이 소프트웨어 개발이라는 작업의 풍경이 이 지휘자의 자리를 닮아가고 있습니다. 2025년 초 앤트로픽이 클로드 코드(Claude Code)를 공개한 이래, 개발자의 역할은 조금씩 '코드를 한 줄 한 줄 쓰는 사람'에서 '코드를 대신 써주는 AI에게 지시하고 검토하는 사람'으로 이동해 왔지요. 그런데 2025년 12월 초, 구글이 공개한 앤티그래비티(Antigravity)는 이 변화를 한 단계 더 밀어붙인 제품입니다. 이 IDE는 개발자를 한 명의 에이전트와 페어 프로그래밍하는 존재가 아니라, 여러 에이전트를 동시에 지휘하는 매니저로 재정의합니다.

▸ VS Code의 포크, 그 자체가 메시지다

앤티그래비티는 마이크로소프트의 VS Code를 포크해 만든 IDE입니다. 이 선택부터가 꽤 함축적인 메시지를 담고 있습니다. VS Code는 지난 몇 년간 세계에서 가장 널리 쓰이는 개발 환경이었고, 깃허브 코파일럿과 마이크로소프트 생태계가 그 위에서 번성해 왔지요. 구글이 이 판에 굳이 자체 IDE를 들고 들어온다는 것은, 개발 환경 자체가 경쟁의 새로운 전장이 되었다는 신호입니다.

왜 이제 와서일까요. 그 답은 에이전트의 부상에 있습니다. 단일 AI 모델이 보조하는 코드 작성이라면 VS Code + 코파일럿 같은 기존 조합으로 충분합니다. 그러나 여러 에이전트가 동시에 서로 다른 작업을 수행하는 멀티 에이전트 개발이 되면, IDE의 설계 전제부터 달라져야 합니다. 한 명의 개발자가 한 개의 편집창에서 한 개의 파일을 건드리는 모델이 아니라, 여러 에이전트가 여러 파일에서 동시에 작업하는 상황을 조율할 수 있는 구조가 필요해지는 것이지요.

VS Code는 원래 이런 용도로 설계되지 않았습니다. 기존 IDE 위에 에이전트 기능을 플러그인으로 얹는 방식은 한계가 분명합니다. 그래서 구글은 포크라는 길을 택했습니다. 기존 사용자의 익숙함을 상속하되, 속은 완전히 다르게 만들겠다는 전략이지요.

▸ Editor View와 Manager View : 두 개의 눈

앤티그래비티의 핵심 구조는 두 개의 뷰로 요약됩니다.

첫째는 Editor View입니다. 우리가 익숙한 코드 편집창과 AI 사이드바의 조합이고, 클로드 코드나 커서(Cursor) 같은 기존 제품의 경험과 크게 다르지 않습니다. 개발자가 직접 코드를 읽고 쓰고, 사이드바의 AI에게 작업을 위임하거나 조언을 구하는 방식이지요. 이것이 '한 명의 개발자 + 한 명의 AI' 구조입니다.

둘째는 Manager View입니다. 이 뷰에서 개발자는 더 이상 코드를 직접 편집하지 않습니다. 대신 여러 에이전트들이 병렬로 돌아가는 워크스페이스 여러 개를 한눈에 보는 관제탑이 됩니다. 한 에이전트는 기능 A의 백엔드를 짜고, 다른 에이전트는 기능 B의 테스트 코드를 작성하고, 또 다른 에이전트는 외부 라이브러리 조사를 수행하는 식이지요. 개발자는 각 에이전트의 진척을 살피고, 필요할 때 끼어들어 방향을 수정하거나 다음 작업을 지시합니다.

!공중에 떠 있는 여러 가상 디스플레이가 중앙 지휘대 주변에 호를 그리듯 배치된 작업 공간

이 두 뷰 사이를 자유롭게 오간다는 것이 앤티그래비티의 약속입니다. 업무가 단순하고 깊게 파고들어야 할 때는 Editor View로, 일이 복잡해지고 여러 작업이 병렬로 돌아가야 할 때는 Manager View로. 같은 개발자가 상황에 따라 연주자와 지휘자 사이를 오가는 것입니다.

▸ 매니저의 일은 실제로 무엇인가

여기서 한 가지 조심스러워지는 대목이 있습니다. 코드를 직접 쓰지 않는 매니저 역할이, 과연 실제로 유효한 일인가. 많은 개발자들이 의심을 품어 온 지점입니다. 코드를 직접 읽지 않고서 에이전트의 작업을 제대로 검토할 수 있는가. 그렇지 못한다면 그 매니저 역할은 허울뿐인 것 아닌가.

이 의심에는 일리가 있습니다. 저도 처음에는 비슷한 생각이었습니다. 그런데 지난 몇 달 사이 실제 사용기를 읽으면서 생각이 조금 바뀌었습니다. 매니저 역할의 핵심은 '코드를 대충 훑어보는 것'이 아니라, 과제의 경계와 기준을 명확히 정의해주는 것이라는 점입니다.

좋은 매니저의 일을 구체적으로 적어보면 이렇습니다. 과제를 적당한 크기로 쪼개는 일, 각 에이전트에게 어떤 산출물을 기대하는지 명확히 전달하는 일, 에이전트들이 만든 결과물 사이에 모순이 없는지 점검하는 일, 막힌 에이전트를 다른 방향으로 돌려주는 일, 최종적으로 시스템 전체의 일관성을 책임지는 일. 이 일들은 코드를 직접 쓰지 않고도 충분히 할 수 있고, 오히려 코드를 쓰는 데 시간을 빼앗기지 않을 때 더 잘할 수 있는 일입니다.

▸ 주니어 개발자는 어디로 가는가

이 변화가 모두에게 똑같이 좋은 소식은 아닙니다. 특히 주니어 개발자, 그리고 이제 막 개발을 배우기 시작한 학생들에게는 이 변화가 날카로운 질문을 던집니다. 매니저 역할이 개발자의 기본값이 되는 시대에, 어떻게 매니저가 되는 훈련을 쌓을 것인가.

전통적인 개발자 성장 경로는 "코드를 많이 써보면서 감을 익힌다"였습니다. 주니어 때는 직접 손으로 많이 짜보고, 그 경험이 쌓이면 시니어가 되어 설계와 리뷰를 하게 되지요. 그런데 이제 주니어 시기의 '직접 손으로 짜보는' 단계가 에이전트에게 넘어갑니다. 그렇다면 경험은 어디에서 쌓일까요.

저는 이 질문에 정답을 가지고 있지 않지만, 한 가지 가설은 있습니다. 경험의 기준이 작성한 코드의 양에서 검토한 결과물의 양으로 이동하리라는 점입니다. 주니어는 에이전트가 만든 코드를 많이 읽어야 하고, 그 코드가 왜 틀렸는지 혹은 왜 좋은지를 판별하는 안목을 길러야 합니다. 이 '안목의 훈련'이 새로운 성장 경로의 핵심이 될 것입니다. 이 훈련은 전통적인 코딩 훈련보다 오히려 더 어렵고, 더 많은 독서와 더 많은 사례 학습을 요구합니다.

▸ IDE 시장의 새로운 판

!지휘봉 하나가 금빛 빛의 흐름 속에 놓인 극적인 정물

IDE 시장의 지각변동도 눈여겨볼 대목입니다. 지금까지 개발 도구 시장은 마이크로소프트의 VS Code + 깃허브 코파일럿이 압도적인 점유율을 가져가는 구도였습니다. 2025년 초에 등장한 커서(Cursor)가 'AI 네이티브 IDE'라는 새 카테고리로 성장했고, 앤트로픽의 클로드 코드가 터미널 기반 에이전트로 또 다른 흐름을 만들었지요.

앤티그래비티는 이 판을 한 번 더 흔듭니다. 구글이라는 빅테크가 직접 IDE를 들고 나왔다는 사실은, 마이크로소프트 독주 구도의 종료를 예고하는 신호입니다. 그리고 앤티그래비티의 '멀티 에이전트 매니저 뷰' 같은 개념은 VS Code 플러그인만으로는 구현하기 어려운 것이어서, IDE 아키텍처 자체의 재설계 경쟁을 촉발하게 됩니다.

개발자 입장에서는 당분간 꽤 어지러운 시기가 이어질 것입니다. VS Code에 머물 것인가, 커서로 갈 것인가, 앤티그래비티를 시도해볼 것인가, 아니면 클로드 코드 같은 터미널 에이전트를 중심에 둘 것인가. 각 도구가 만드는 생산성의 차이는 점점 커지고 있지만, 한 도구에 숙달되기도 전에 새 도구가 출시되는 속도가 만만치 않지요.

▸ 한국의 개발 조직이 준비해야 할 일

한국의 많은 IT 조직이 지금 고민 중인 주제가 있습니다. "AI 도구를 도입해서 생산성을 얼마나 올릴 수 있는가." 대부분의 벤치마크 자료는 "개발 속도 30% 향상" 같은 수치를 제시하지만, 저는 이런 숫자들을 신뢰하지 않습니다. 도구의 도입만으로 30%가 올라간다면 세상 모든 회사가 이미 도입했을 테니까요.

진짜 질문은 도구의 도입이 아니라 업무 구조의 재설계입니다. 매니저 뷰가 상정하는 업무 방식 — 한 개발자가 여러 에이전트를 동시에 지휘하는 방식 — 이 실제로 작동하려면, 과제를 쪼개는 방식, 리뷰의 주기, 코드 오너십의 개념, 장애 대응의 책임 배분이 모두 바뀌어야 합니다. 이것은 IDE를 설치한다고 자동으로 따라오는 변화가 아닙니다.

한국의 조직들이 먼저 준비해야 할 것은 이런 구조 재설계입니다. 구체적으로는 세 가지입니다. 첫째, 어떤 업무를 에이전트에게 맡길 수 있고 어떤 업무를 사람이 해야 하는지의 경계 설정. 둘째, 에이전트의 결과물을 책임지고 검토할 수 있는 리뷰 역량의 체계화. 셋째, 에이전트가 만들어낸 코드에 대한 품질과 보안의 사후 검증 프로세스. 이 세 가지가 없으면 앤티그래비티 같은 도구가 아무리 좋아도 실제 생산성 향상으로 이어지지 못합니다.

▸ 지휘대에 올라설 준비

다시 처음의 이야기로 돌아갑니다. 오케스트라 지휘자는 악기를 연주하지 않지만 음악을 만듭니다. 개발자가 코드를 직접 쓰지 않아도 소프트웨어를 만드는 시대가 열리고 있고, 앤티그래비티는 그 시대의 IDE가 어떤 모양일지를 꽤 구체적으로 보여주는 첫 제품입니다.

이 변화를 두려워할 필요는 없지만, 준비 없이 맞이해도 되는 것은 아닙니다. 지휘자의 기술은 연주자의 기술과 겹치는 부분이 많지만, 완전히 같은 기술은 아닙니다. 우리 개발자들이 지휘대 위에 올라서 연주 전체를 조망하는 능력을 키우지 못한다면, 에이전트가 아무리 유능해져도 그 유능함이 조직의 성과로 이어지지 못할 것입니다.

여러분은 지금 어떤 곡을 준비하고 있습니까. 그리고 그 곡을 함께 연주할 에이전트들에게 무엇을 어떻게 부탁하고 계십니까. AI를 쓰는 인간이 그렇지 못한 인간을 대체한다는 명제는, 이제 개발자 세계 안에서 에이전트를 지휘하는 개발자와 그렇지 못한 개발자의 구도로 구체화되고 있습니다.