엔지니어를 위한 AI 기술 동향 — 2026년 10월 15일

일반 AI 뉴스와는 별도로, 시스템을 설계하고 개발하는 엔지니어가 알아 두면 좋은 기술 흐름만 골랐습니다. 오늘은 에이전트 규모의 개발 인프라와, 병목이 된 검증·리뷰에 대한 논의가 중심입니다.

Anthropic은 왜 Git를 버리고 자체 소스 관리 'Scion'을 만들었나

Anthropic이 모노레포의 버전 관리를 Git에서 자체 시스템 Scion으로 교체한 엔지니어링 글을 공개해 Hacker News에서 800점 넘는 반응을 얻었습니다. 숫자가 배경을 설명합니다. 하루 병합되는 코드 변경은 5월의 약 2,500건에서 9월 3만 건 이상으로 늘었고, 메인 브랜치 히스토리만 100GB에 육박하며, CI만으로 하루 약 2,500만 번의 체크아웃이 발생합니다. 수백 대의 Git 미러를 운영해도 팁을 따라잡지 못하는 지점이 왔다는 것입니다. 사람이 협업하던 전제로 설계된 도구가 에이전트 규모의 처리량 앞에서는 병목이 된다는 것 — CI, 아티팩트 저장소, 코드 리뷰까지 개발 인프라 전반을 다시 보게 하는 사례입니다. 기술 정리

코딩 에이전트는 코드를 늘리지만, 소프트웨어를 늘리지는 않는다

코딩 에이전트 도입 효과를 분석한 연구가 눈길을 끕니다. 에이전트 도입 뒤 PR이 제출돼 병합되기까지의 리뷰 과정 시간은 평균 49% 늘었고, 변경 요청을 받는 PR의 비율은 거의 두 배, PR당 댓글 수는 35% 늘었습니다. 리뷰를 담당하는 인력 비중도 14% 증가했습니다. 기업의 80%가 AI 코드 리뷰를 쓰지만, 전체 리뷰 댓글 중 에이전트가 단 것은 23% 수준이라 여전히 사람이 대부분의 리뷰를 감당합니다. 생성 속도가 빨라진 만큼 병목은 검증으로 이동했다는 것 — 어제 다룬 평가 논의와 같은 방향의 실증입니다. 팀의 처리량을 재려면 '생성량'이 아니라 '리뷰·검증 용량'을 기준으로 삼아야 한다는 뜻이기도 합니다. Real Hacker News 정리

스펙 주도 개발(SDD) — 에이전트에게 채팅이 아니라 설계도를

dev.to에서는 스펙 주도 개발을 다룬 글이 이어지고 있습니다. 느슨한 프롬프트로 에이전트에게 맡기는 '바이브 코딩'은 데모에는 좋지만, 에이전트가 데이터베이스 컬럼 이름을 멋대로 바꾸는 식의 조용한 표류가 유지보수를 망친다는 문제의식입니다. 대안은 코드를 쓰기 전에 구조화된 스펙(SPEC.md)을 만들어 사람과 에이전트가 공유하는 단일 진실 공급원으로 삼는 것 — GitHub의 Spec Kit 같은 도구도 나왔습니다. 엄밀함의 단계도 spec-first(초기 구축용), spec-anchored(테스트와 함께 유지), spec-as-source(스펙에서 코드 생성)로 나뉘어 논의됩니다. 유지해야 할 시스템일수록 최소 단계부터라도 스펙을 남기자는 제안입니다. dev.to

에이전트 평가는 '성공률'이 아니라 실패 양식으로 설계하라

에이전트 평가(eval) 실무 가이드도 공감을 얻고 있습니다. 핵심은 세 가지입니다. 첫째, 가능한 곳에서는 LLM 심판이 아니라 결정적 검사(테스트, 타입 체크, DB 상태 확인)를 먼저 쓰라는 것. 둘째, 평가 데이터셋은 깨끗한 예시가 아니라 실제 운영 실패, 경계 조건, 권한 경계 같은 사례에서 만들라는 것 — 실패가 쌓일수록 평가가 운영의 기억이 됩니다. 셋째, '작업을 해냈는가(능력)'와 '규칙을 지켰는가(정책)'를 분리해 재라는 것. 성공과 위반을 한 점수로 합치면 시스템이 공격적으로 변하는 방식으로 '개선'될 수 있기 때문입니다. 코드를 짜기 전에 평가부터 만들어 '완료'의 정의를 고정하는 eval 주도 개발 흐름과도 맞닿아 있습니다. dev.to 가이드

내일도 실무에 닿는 주제만 골라 이어 가겠습니다.