책에 포함된 노트Google Antigravity: 코드를 쓰지 말고, 에이전트를 지휘하라

제22장 에이전트 시대의 개발자

2026-04-28Views 14약 9분생성형 AI 활용

제22장 에이전트 시대의 개발자

Antigravity를 여기까지 따라왔다면, 이제 가장 중요한 질문 하나가 남습니다. 도구가 얼마나 대단한가보다 더 큰 질문입니다. 이 시대에 개발자는 어떤 사람이어야 하는가?

이 책의 마지막 장에서 우리가 내려야 할 결론은 생각보다 단순합니다. 개발자는 사라지지 않습니다. 다만, 개발자가 가치 를 만드는 방식이 바뀝니다. 예전에는 손이 빠른 사람이 유리했다면, 이제는 문제를 정확히 정의하고, 에이전트에게 적절히 위임하고, 결과를 검증 가능한 형태로 통과시키는 사람이 유리합니다.

Google은 Antigravity를 'confidence'를 갖고 프로덕션 수준의 앱을 만들게 돕는 환경으로 소개합니다. 핵심은 단순 자동완성이 아니라, 여러 작업공간의 에이전트를 오케스트레이션하고 아티팩트로 검증하는 구조에 있습니다.¹ 공식 Codelab도 이 도구를 에디터가 아니라 '미션 컨트롤'을 포함한 에이전트 중심 플랫폼으로 설명합니다.² 이 말은 곧 이런 뜻입니다. 미래의 개발자는 타이피스트가 아니라, 점점 더 지휘자가 됩니다.

제6부 비교, 한계, 그리고 미래 — 에이전트 시대의 개발자

개발자는 없어지지 않는다. 대신 일의 무게중심이 옮겨간다

한때 좋은 개발자를 떠올리면 이런 장면이 먼저 떠올랐습니다. 키보드를 미친 듯이 두드리고, 복잡한 API를 외우고, 문법을 머릿속에서 바로 꺼내 쓰는 사람 말입니다. 물론 지금도 그런 능력은 중요합니다. 하지만 그것만으로는 부족해졌습니다.

에이전트가 계획을 세우고, 파일을 고치고, 테스트를 돌리고, 브라우저까지 열어 검증하는 순간부터 사람의 경쟁력은 '내가 몇 줄을 빨리 쓰는가'보다 '무엇을 어떤 경계 안에서 맡길 수 있는가'로 이동합니다. 예전의 개발 생산성이 손끝의 속도에서 나왔다면, 앞으로의 생산성은 판단의 밀도에서 나옵니다.

쉽게 말해 봅시다. 과거의 개발자가 벽돌공에 가까웠다면, 앞으로의 개발자는 현장 소장에 더 가까워집니다. 그렇다고 벽돌을 아예 몰라도 된다는 뜻은 아닙니다. 오히려 벽돌을 제대로 알아야 공사가 수상하게 흘러갈 때 바로 눈치챌 수 있습니다. 달라지는 것은 '직접 하는 비중'이지 '책임의 크기'가 아닙니다.

그래서 살아남는 개발자는 두 극단을 피합니다. '나는 AI 없이도 다 할 수 있어'라고 버티는 사람도 위험하고, 'AI가 해줬으니 됐겠지'라고 넘기는 사람도 위험합니다. 진짜 강한 사람은 그 사이에 있습니다. 직접 해야 할 일과 맡겨야 할 일을 구분하고, 맡긴 뒤에도 검증의 주도권을 놓지 않는 사람입니다.

코드 리뷰가 아니라 Artifact 리뷰의 시대

이 변화는 리뷰 방식에서 가장 선명하게 드러납니다. 과거의 중심 산출물은 코드였습니다. 당연히 리뷰도 코드 위에서 이루어졌습니다. 앞으로도 코드 리뷰는 사라지지 않습니다. 하지만 코드만 보는 리뷰는 점점 부족해집니다.

Antigravity의 공식 문서는 에이전트가 중간 아티팩트에 대해 리뷰를 요청해, 자신의 진행 방향이 사용자의 의도와 맞는지 확인할 수 있다고 설명합니다.³ 이 한 문장은 앞으로의 리뷰 문화를 거의 다 말해줍니다. 이제 리뷰 대상은 최종 코드만이 아닙니다. 작업 목록, 구현 계획, 테스트 결과, 스크린샷, 브라우저 녹화, 변경 요약까지 함께 봐야 합니다.

왜냐하면 에이전트 시대의 실패는 결과물 한 장면에서만 생기지 않기 때문입니다. 애초에 잘못 이해한 계획, 누락된 완료 기준, 검증 없는 완료 선언, 브라우저에서는 깨지는데 테스트만 통과한 기능. 이런 문제는 코드 diff만 읽어서는 놓치기 쉽습니다.

앞으로 좋은 리뷰어는 이런 질문을 합니다.

이 작업의 성공 기준이 처음부터 분명했는가?
에이전트가 남긴 증거가 실제 동작을 뒷받침하는가?
테스트와 스크린샷, 녹화가 서로 모순되지 않는가?
코드가 맞는가를 넘어, 이 변경이 안전하게 운영 가능한가?

이 질문들은 단순히 깐깐한 태도가 아닙니다. 신뢰를 감으로 만들지 않고, 증거로 만드는 태도입니다. 앞으로는 'PR을 빨리 읽는 사람'보다 '결과의 진위를 빠르게 판별하는 사람'이 더 귀해집니다.

살아남는 개발자는 무엇을 잘하는 사람인가

그렇다면 앞으로 강한 개발자는 정확히 어떤 사람일까요. 문법 암기보다 중요한 능력은 점점 더 분명해지고 있습니다.

문제를 잘게 쪼개는 사람입니다. 큰 기능을 그대로 던지지 않고, 경계가 선명한 작업 단위로 나눕니다.
완료 기준을 먼저 쓰는 사람입니다. 무엇이 끝인지, 무엇은 이번 범위가 아닌지, 어떤 테스트가 통과해야 하는지 먼저 적습니다.
권한과 위험을 설계하는 사람입니다. 어디까지 자동 실행을 허용할지, 어느 지점에서 사람 리뷰를 강제할지 결정합니다.
비즈니스 문맥을 코드와 연결하는 사람입니다. 단순히 동작하는 기능이 아니라, 왜 이 기능이 제품과 고객에게 중요한지 설명할 수 있습니다.
검증 루프를 운영하는 사람입니다. 한 번 생성된 결과를 덮어놓고 믿지 않고, 빠르게 실험하고, 반례를 찾고, 다시 고칩니다.

이 다섯 가지는 화려해 보이지 않습니다. 하지만 에이전트 시대에는 바로 이런 능력이 팀 전체의 속도와 안전성을 결정합니다. 문법은 모델이 꽤 잘 압니다. 그러나 무엇을 만들지, 어디까지 허용할지, 어떤 결과를 통과시킬지는 여전히 사람의 영역입니다.

조금 냉정하게 말하면, 앞으로 평균적인 코드를 '어느 정도' 작성하는 능력만으로는 차별화가 어려워집니다. 대신 평균 이상의 개발자는 더 크게 벌어집니다. 이유는 간단합니다. 좋은 개발자는 에이전트를 붙여 자신의 역량을 증폭시키고, 나쁜 개발자는 에이전트를 붙여 자신의 실수를 대량 생산하기 때문입니다.

채용은 '코딩 테스트'만으로 설명되지 않게 된다

이 변화는 채용 공고부터 바꿉니다. 이미 여러 산업 분석은 기술 채용의 무게중심이 코드 중심 역할에서 거버넌스, AI 운영, 윤리, 저위험 설계 쪽으로 이동하고 있다고 지적합니다.⁴ 예전에는 '이 언어를 얼마나 깊게 아는가'가 거의 전부였다면, 이제는 '에이전트가 실행하는 시스템을 안전하게 만들 수 있는가'가 점점 더 중요한 질문이 됩니다.

특히 리드급 이상 채용에서는 더 그렇습니다. 최근의 에이전트 리더십 평가 프레임워크는 후보자를 볼 때 세 가지를 확인합니다. 가드레일을 설계할 수 있는가, 일을 에이전트와 사람 사이에 올바르게 배분할 수 있는가, 그리고 결과를 리스크와 사업 언어로 번역할 수 있는가 하는 점입니다.⁵ 이것은 임원 채용 이야기처럼 들리지만, 사실 개발 조직 전체로 내려오는 기준이기도 합니다.

앞으로 면접은 이런 식으로 바뀔 가능성이 큽니다. 라이브 코딩 한 문제만 푸는 대신, 애매한 요구사항을 주고 '이걸 에이전트에게 어떻게 위임하겠는가'를 묻는 식입니다. 혹은 계획 아티팩트와 코드 diff, 테스트 로그를 함께 보여주고 '무엇이 불안한지 말해보라'고 물을 수도 있습니다. 좋은 답은 정답 코드 한 조각이 아니라, 좋은 운영 판단으로 드러납니다.

즉, 채용은 점점 다음 능력을 보게 됩니다. 문제 분해, 명세 작성, 검증 설계, 위험 감지, 협업 언어, 그리고 에이전트 실패를 인간이 책임 있게 수습하는 능력입니다.

이 변화는 주니어에게도 영향을 줍니다. 단순 CRUD 티켓만 조용히 처리하는 역할은 줄어들 수 있습니다. 하지만 반대로, 빠르게 배우는 주니어에게는 기회가 커집니다. 예전에는 선배 옆에서 몇 달 동안 단순 작업을 하며 감을 익혔다면, 이제는 에이전트가 만든 결과를 리뷰하면서 훨씬 많은 사례를 짧은 시간에 볼 수 있기 때문입니다. 주니어의 경쟁력도 결국 '얼마나 많이 치는가'보다 '얼마나 빨리 판단을 배우는가'로 옮겨갑니다.

평가는 산출량이 아니라 통제 가능한 자율성으로 이동한다

성과 평가도 달라질 수밖에 없습니다. 줄 수, 커밋 수, 밤샘의 양, 티켓 소화량 같은 지표는 원래도 허술했지만, 에이전트 시대에는 더 빨리 무너집니다. 에이전트가 초안을 대량 생산하는데, 그 양을 사람 성과로 그대로 읽는 순간 조직은 착시를 보게 됩니다.

앞으로 더 유의미한 평가는 이런 질문에 가깝습니다. 이 사람이 에이전트를 붙였을 때 더 빠르고 더 안전한 결과를 만들었는가? 작업 단위를 명확히 정의하는가? 실패를 조기에 발견하는가? 리뷰 비용을 줄이는 흔적을 남기는가? 팀의 지식 기반과 규칙을 개선해 다음 작업이 더 쉬워지게 하는가?

좋은 평가는 개인의 손기술만 보지 않습니다. 그 사람이 만든 운영 체계의 품질을 봅니다. 예를 들어 이런 차이가 생깁니다.

한 사람은 기능을 빨리 내놓습니다. 그런데 매번 요구사항이 흔들리고, 테스트가 부실하고, 에이전트가 같은 실수를 반복합니다. 다른 한 사람은 첫 속도는 조금 느릴 수 있습니다. 하지만 명세가 명확하고, 리뷰 포인트가 잘 잡혀 있고, 재작업이 적고, 팀 전체가 그 방식을 재사용할 수 있습니다. 장기적으로 더 가치 있는 사람은 누가 될까요? 점점 후자입니다.

성과의 단위가 '내가 직접 만든 코드'에서 '내가 설계한 신뢰 가능한 생산 시스템'으로 옮겨가기 때문입니다.

팀 구조는 '개발팀'에서 '오케스트라'로 바뀐다

에이전트 시대의 팀은 겉으로는 그대로여도, 안쪽 구조가 달라집니다. 국내외 현장 논의에서 공통으로 나오는 메시지도 비슷합니다. 핵심은 에이전트를 도입하는 것이 아니라, 무엇을 맡기고 무엇을 사람이 지킬지 경계를 설계하는 것입니다.⁶

이제 팀장은 사람 일정만 관리하지 않습니다. 어떤 작업을 사람에게 줄지, 어떤 작업을 에이전트에게 병렬로 흘릴지, 어디에 승인 게이트를 둘지 결정해야 합니다. 테크 리드는 아키텍처만 보는 사람이 아니라, 지식 기반과 규칙, 리뷰 정책, 검증 루프를 운영하는 사람이 됩니다. 시니어 개발자는 복잡한 로직을 직접 다루는 동시에, 팀이 반복적으로 쓰는 위임 패턴을 표준화하는 사람이 됩니다.

조직 안에서는 눈에 잘 띄지 않던 역할도 커집니다. 예를 들어 프롬프트와 작업 명세를 표준화하는 사람, AGENTS.md나 지식 기반을 관리하는 사람, 에이전트의 실행 정책과 로그를 점검하는 사람, 모델·쿼터·권한을 운영하는 사람은 예전보다 훨씬 중요해집니다. 예전에는 '개발 외 잡무'처럼 보였던 일이, 앞으로는 생산성의 핵심 인프라가 됩니다.

팀 구조를 한 문장으로 요약하면 이렇습니다. 앞으로 좋은 팀은 코드를 많이 치는 팀이 아니라, 사람과 에이전트가 함께 일하는 방식을 잘 설계한 팀입니다.

다음 5년, 개발 문화는 어떻게 바뀔까

업계 전망도 비슷한 방향을 가리킵니다. 3~5년 안에 소프트웨어 엔지니어라는 말 자체가 '코드를 쓰는 사람'보다 '문제를 명세하고, 아티팩트를 리뷰하고, 에이전트 무리를 관리하는 사람' 쪽으로 이동할 수 있다는 관측이 나옵니다.⁷ 과장이 조금 섞였더라도, 방향 자체는 이미 시작됐습니다.

앞으로의 개발 문화는 대략 다섯 가지 변화를 겪을 가능성이 큽니다.

첫째, 명세가 코드만큼 중요해집니다. 좋은 팀은 요구사항을 말로 흘려보내지 않습니다. 에이전트가 실행 가능한 수준의 작업 정의로 남깁니다.

둘째, PR은 더 두꺼워지고, 더 읽기 쉬워집니다. 코드 diff만 있는 것이 아니라 계획, 근거, 검증 결과, 스크린샷, 녹화, 위험 메모가 함께 붙습니다. 양은 많아지지만, 오히려 판단은 빨라질 수 있습니다.

셋째, 팀의 실력 차이는 지식 기반에서 벌어집니다. 개인의 손재주보다, 팀이 얼마나 좋은 규칙과 패턴, 검증 자산을 축적했는지가 더 큰 격차를 만듭니다.

넷째, 리더의 역할이 더 기술적으로 변합니다. 사람 관리만 잘하는 것으로는 부족합니다. 권한 정책, 승인 흐름, 로그, 모델 운영, 비용과 위험 균형까지 이해해야 합니다.

다섯째, 개발 문화가 더 문서화되고 더 감사 가능해집니다. 재미없게 들릴 수 있지만, 이 변화는 매우 중요합니다. 에이전트를 믿는 유일한 길은, 결국 흔적을 남기는 것이기 때문입니다.

이 다섯 가지 변화가 자리 잡으면, 개발 조직의 분위기 자체가 달라집니다. '누가 제일 빨리 짰나'보다 '누가 제일 안정적으로 위임하고 검증했나'가 더 중요한 칭찬이 됩니다. 밤새워 히어로처럼 불 끄는 사람보다, 애초에 불이 크게 나지 않게 시스템을 만든 사람이 더 높은 평가를 받습니다.

결국, 앞으로 살아남을 개발자는 이런 사람이다

이 책은 Antigravity라는 도구를 다뤘지만, 마지막 결론은 특정 제품을 넘어섭니다. 앞으로 살아남을 개발자는 AI를 거부하는 사람도 아니고, AI에게 무릎 꿇는 사람도 아닙니다.

앞으로 살아남을 개발자는 애매한 요구를 명확한 작업으로 바꾸는 사람, 자율성을 통제 가능한 범위 안에 가두는 사람, 결과를 증거로 검증하는 사람, 그리고 코드와 비즈니스 사이를 번역하는 사람입니다.

좋은 개발자는 더 이상 단순히 '잘 짜는 사람'이 아닙니다. 이제는 '잘 맡기고, 잘 멈추고, 잘 통과시키는 사람'입니다.

이 변화는 조금 불편할 수 있습니다. 손으로 해내던 자부심의 일부를 내려놓아야 하기 때문입니다. 하지만 다른 방식으로 보면, 개발자는 더 작아지는 것이 아니라 더 커집니다. 한 줄의 코드보다 더 큰 단위를 다루게 되고, 한 파일보다 더 넓은 시스템을 책임지게 되기 때문입니다.

Antigravity가 남길 패러다임도 바로 여기에 있습니다. 코드를 덜 쓰게 만드는 도구가 아니라, 개발자를 더 높은 수준의 책임으로 밀어 올리는 도구라는 점입니다.

반중력이라는 이름은 꽤 적절합니다. 앞으로의 개발자는 더 이상 키보드에만 붙잡혀 있지 않습니다. 문법의 중력, 반복 작업의 중력, 끝없는 컨텍스트 스위칭의 중력에서 조금씩 벗어납니다.

하지만 떠오른다고 해서 가벼워지는 것은 아닙니다.

오히려 더 높은 곳으로 올라갈수록, 방향을 잃지 않는 능력이 더 중요해집니다.