AMD가 IEEE Spectrum에 공개한 글에 따르면, AMD는 2024년부터 코드 생성과 테스트 자동화, 버그 분석, 코드 리뷰에 AI 시스템을 도입했다. 원래 목표는 2027년까지 25%의 코드를 AI로 생성하는 것이었는데, 이미 올해 초 20%를 넘겼고 전체 코드베이스 기준 50%를 향해 가고 있다고 한다. 일부 구성 요소에서는 80% 이상이 AI가 만든 코드다.
흥미로운 건 단순한 코드 생성이 아니라 생산성 수치다. AMD는 AI 도입으로 30%의 전체 생산성 향상을 기록했다고 밝혔다. 여기서 ‘AI가 만든 코드’는 리뷰와 테스트를 통과해 실제 제품에 포함된 것만 센다는 점도 중요하다. 즉 허튼 코드가 아니라 품질 검증을 거친 결과물이라는 얘기다.
AMD가 그리는 다음 단계는 ‘에이전트 스웜’이다. 사람이 문제와 목표, 제약 조건만 정하면 여러 AI 에이전트가 병렬로 해법을 만들고 검증하고 비교한다. 이건 사실 P2P 네트워크에서 오래된 숙제를 떠올리게 한다. 개별 노드가 서로 조율 없이 일하면 결과가 흩어진다. 그래서 분산 시스템에서는 리더 선출, 합의, 복제 같은 메커니즘이 필요하다. 에이전트 스웜도 마찬가지다.
에이전트가 여러 개의 솔루션을 만들고, 그중 좋은 것을 고르려면 결과를 비교할 공통 기준이 필요하다. AMD는 성공 기준을 정의하고, 검증 결과와 성능 지표를 랭킹으로 만들어 엔지니어가 승인하게 한다고 설명한다. 이 흐름은 P2P 네트워크에서 각 피어가 제안을 검증하고 다수가 채택하는 과정과 닮았다.
AMD의 사례 중 RSX(Radeon Software eXperience)는 그래픽 드라이버 설정 UI다. 2025년 10월부터 AI 에이전트로 이슈를 자동 디버깅하기 시작했는데, 초기에는 도구가 문제의 6%만 해결했다. 하지만 학습 루프를 만들고 실패 원인을 분석한 뒤 2026년 6월에는 75%까지 끌어올렸다고 한다. 이건 실시간 네트워크 운영에도 그대로 적용되는 감각이다.
WebRTC나 피투피 시그널링 같은 실시간 시스템은 장애 재현이 어렵고, 패킷 로그와 피어 상태가 뒤섞인다. 문제 보고를 자동으로 분류하고, 유사한 이슈를 묶고, 수정 후보를 제안하는 에이전트 구조는 이런 분야에서 특히 유용하다. 초기 도구가 6%에 머문 건 데이터가 바로 연결되지 않았기 때문일 가능성이 크다. AMD가 만든 학습 루프처럼, 장애 데이터가 에이전트 학습에 다시 들어가는 파이프라인이 핵심이다.
PonsLink와 PonsWarp를 만들면서 느낀 건, P2P 제품은 ‘표준적인 디버깅 흐름’이 잘 안 만들어진다는 것이다. 중계 서버가 없는 구조라서 로그가 각 피어에 흩어지고, 에러 재현 조건이 사용자 네트워크 환경에 따라 크게 달라진다. AMD가 코드 리뷰와 테스트 전 과정에 에이전트를 붙인 방식은, 분산 네트워크 운영에서 필요한 자동화의 방향성을 알려준다.
다만 AMD의 숫자를 그대로 P2P에 가져가긴 이르다. 30% 생산성 향상은 개발 프로세스에 대한 지표이지, 분산 네트워크 자체의 성능 지표가 아니다. 우리가 주목해야 할 건 ‘에이전트가 코드를 얼마나 잘 쓰는가’보다 ‘장애 데이터가 학습 루프로 얼마나 잘 흐르는가’다. 그 파이프라인이 갖춰지면 실시간 네트워크의 운영 비용도 비슷하게 줄어들 수 있다고 본다.
AMD는 아직 해결해야 할 문제도 명확히 언급한다. 지금은 엔지니어 한 명이 에이전트 출력을 리뷰하고 프롬프트를 고치는 방식으로 한 번에 하나씩 개선된다. 에이전트가 서로에게서 배우고, 성공한 전략을 재사용하며, 프로젝트와 팀을 넘어 협업하려면 트레이닝 방식이 바뀌어야 한다고 한다. 이건 P2P 네트워크에서 경험과 보상을 공유하는 메커니즘이 필요하다는 말과도 닿아 있다.
또 신뢰 문제는 결국 측정 문제다. AMD는 ‘AI가 만든 코드’를 리뷰와 테스트를 통과한 코드로만 집계함으로써 과장을 막는다. P2P 분야에서도 에이전트가 만든 결과물이 실제 네트워크 품질에 기여했는지 객관적으로 검증하는 기준을 함께 만들어야 한다. 그래야 에이전트 스웜이 재미있는 실험이 아니라 운영 가능한 도구가 된다.
댓글