PHP 3의 공동 창시자 중 한 명이자 Google의 Agentic Data Cloud 총괄인 Andi Gutmans는 에이전트에 의존한 소프트웨어 개발을 과거와의 완전한 단절로 보지 않는다. 그는 Stack Overflow의 Leaders of Code 프로그램에서 Eira May와 Peter O'Connor가 진행한 대담에서, 현재의 전환을 PHP가 컴퓨터 과학을 전공하지 않은 사람을 포함해 더 많은 사람이 웹사이트를 만들 수 있게 했을 때의 영향에 비유했다.
그러나 새롭게 높아진 접근성이 엔지니어링 전문성의 소멸을 의미하지는 않는다. Gutmans의 설명에 따르면, 개별 개발자는 점차 ‘에이전트 팀의 리더’와 비슷한 역할로 바뀐다. 요구 사항을 정하고, 업무를 배분하고, 결과를 검토하며, 제한 없이 위임할 수 없는 결정을 내리는 것이다.
가치는 코드 작성에서 엔지니어링 판단으로 이동한다
Gutmans는 에이전트의 등장에도 일부 기본적인 질문은 바뀌지 않았다고 본다. 팀은 여전히 해결책이 올바른 문제를 다루는지, 아키텍처가 확장 가능한지, 시스템이 안전하고 제대로 관리되며 사용하기 쉽고 비용 측면에서도 적절한지 확인해야 한다. 달라진 점은 에이전트가 더 많은 작업을 자율적으로 수행할 수 있다는 것이며, 따라서 생성된 코드를 검토하는 데 그치지 않고 에이전트를 감독하는 방식을 설계해야 한다는 점이다.
Gutmans는 이를 설명하기 위해 에이전트를 사용해 약 1,000개의 테스트를 만든 뒤, 다른 에이전트를 활용해 이 테스트들을 비판적으로 검토한 사례를 들었다. 검토 결과 산출물은 충분히 양호하지 않았고, 그는 직접 개선해야 했다. 이 경우 인간의 판단이 사라진 것이 아니라, 세부적인 실행에서 설계와 조율, 평가로 그 위치가 바뀐 것이다.
이러한 변화는 익숙하지 않은 코드베이스를 이해하는 일에도 확대된다. 에이전트는 프로젝트의 더 넓은 범위를 탐색할 수 있으며, 인간 검토자가 시스템의 제한된 부분을 살필 때 발견하기 어려운 유형의 오류를 찾아낼 수도 있다. 그럼에도 Gutmans는 Google이 특히 결정이나 변경 사항이 민감한 경우 인간 검토와 에이전트 검토를 함께 사용한다고 말했다.
검토는 절대적인 신뢰가 아니라 위험 관리의 문제다
대담에서는 감독을 세 가지 방식으로 바라볼 것을 제안한다. 인간이 루프 안에 있는 방식, 에이전트가 루프 안에 있는 방식, 에이전트가 루프 위에 있는 방식이다. 이는 모든 경우에 적용되는 하나의 선택이 아니라, 오류가 발생할 가능성과 그 영향에 따라 적절한 검토 수준을 정하는 것을 의미한다.
보안 토큰과 같은 민감한 보안 구성 요소와 관련된 변경에서는 인간 전문가의 참여가 더 중요하다. 반면 CSS와 HTML 변경이나 일부 Python 스크립트는 에이전트의 보안 검사를 병행하면서 다른 수준의 자동화에 의존하는 것이 실용적일 수 있다. 여기서 핵심은 에이전트가 오류를 범하지 않는다거나 인간이 모든 것을 똑같이 효율적으로 검토한다는 것이 아니다. 검토 여부에 대한 결정이 위험의 규모와 결과를 반영해야 한다는 것이다.
Gutmans는 감각과 데이터 사이의 격차를 설명하는 사례로 Waymo의 경험을 들었다. 그는 Uber 운전자와 함께 이동하는 것보다 Waymo를 이용할 때 사람이 피해를 입는 사고를 당할 가능성이 80% 낮다고 말했다. 그럼에도 많은 사람은 여전히 운전석에 인간이 있을 때 더 편안함을 느낀다. 마찬가지로 어떤 팀은 특정 업무에서 에이전트를 사용하면 인간이 대체하는 경우보다 위험을 줄일 수 있다는 지표가 있어도, 인상만으로 에이전트의 자율성을 거부할 수 있다.
채용과 학습은 지휘 능력을 시험하는 방향으로 향한다
Gutmans는 컴퓨터 과학 교육이 중단되지는 않겠지만, 학생들이 에이전트의 도움을 받아 더 복잡하고 규모가 큰 프로젝트를 수행할 수 있게 될 것이라고 본다. 따라서 시스템을 구축하고 운영하며 확장하는 방법에 대한 지식은 여전히 필수적이고, 문제를 정식화하고 해결책을 평가하며 지능형 도구를 지휘하는 능력도 중요해질 것이다.
그는 Google이 엔지니어링 면접 과정의 일부를 바꾸고 있다고 말했다. 지원자에게 quick sort와 같은 알고리즘을 손으로 직접 작성하도록 요구하는 데 집중하는 대신, Gemini와 에이전트를 사용해 문제를 해결하도록 한 뒤 사고 방식, 문제를 처리하는 순서, 에이전트를 지휘하는 방식을 평가한다는 것이다. 이는 기술적 역량을 없애는 것이 아니라 면접에서 측정하려는 대상을 바꾸는 일이다. 추상적인 해결책을 빠르게 만들어 내는 능력에서 추론과 설계, 조율의 수준으로 초점이 이동하는 것이다.
가장 큰 장애물은 모델이 아니라 데이터에 있을 수 있다
Gutmans에 따르면 Gemini와 Opus 같은 모델은 이미 기업 업무의 상당 부분을 자동화할 수 있게 되었으며, 따라서 모델 자체만이 주요 병목은 아니다. 더 중요한 과제는 의미적 관계, 권한, 거버넌스를 유지하면서 기업 데이터를 에이전트가 이해하고 사용할 수 있도록 만드는 것이다.
여기에는 구조화된 운영 데이터뿐 아니라 클라우드 스토리지나 다른 장소에 있는 이미지, PDF 파일, 계약서 및 기타 비정형 데이터도 포함된다. Google은 에이전트가 데이터의 위치를 발견하고, 데이터 간 연결을 이해하며, 과거에는 많은 수의 데이터 스튜어드가 필요했던 의미 체계를 구축하는 데 도움을 줄 수 있다고 본다. Gutmans는 이러한 방향을 ‘borderless lakehouse’라는 개념으로 설명하며, 데이터가 GCP, AWS, Azure 또는 온프레미스 환경에 존재하는지와 관계없이 데이터를 활용하는 것을 목표로 한다.
그는 또한 Iceberg와 같은 개방형 데이터 형식의 중요성을 언급했으며, 클라우드 간 통합이 기가바이트당 데이터 전송 요금에 전적으로 의존하지 않고 데이터에 접근하는 데 도움이 될 수 있다고 말했다. 아울러 ‘knowledge catalog’에 대해서도 이야기하며, 온톨로지 구축을 전적으로 인간이 주도하던 과정에서 에이전트가 주도하는 과정으로 옮기되, 인간은 무거운 수작업을 실행하는 대신 조율과 편집을 담당하게 될 것이라고 설명했다.
실제로 무엇이 달라지는가? 기술 팀의 경우 소프트웨어 에이전트를 제공한 뒤 작동하게 내버려 두는 것만으로는 충분하지 않다. 효과적으로 사용하려면 자동화할 가치가 있는 업무를 정하고, 위험에 맞는 검토 수준을 설정하며, 에이전트가 접근하는 데이터와 권한의 품질을 확인해야 한다. 개발자의 역할은 사라지지 않는다. 오히려 실행할 수 있는 도구 집합을 지휘하는 엔지니어에 가까워지며, 에이전트가 산출한 결과에 대한 최종 판단의 책임을 맡게 된다.