에이전트에게 코드를 맡기는 속도가 빨라질수록, 한 가지 불편한 질문이 뒤따라온다. 뭔가 잘못됐을 때, 누가 바닥이 되는가. 빌드가 빨간불이고, 동작이 이상하고, 모델은 자신 있게 같은 자리를 맴돌고 있다면—그 순간의 책임은 에이전트에게 물을 수 없다. dev.to의 한 글은 이 상황을 꽤 정확하게 짚는다. "에이전트는 주니어처럼 일한다. 벽에 막히면 에스컬레이션한다. 당신에게." 그런데 당신도 막혀 있다면, 전체가 멈춘다.
문제는 '얼마나 많이 위임할 수 있느냐'가 아니라, '무너질 때 잡으려면 최소한 무엇을 이해하고 있어야 하느냐'다. 데이터가 시스템을 어떻게 흐르는지, 상태가 어디에 살고 있는지, 크리티컬 패스가 어디를 지나는지—이 뼈대를 모른다면, 에이전트가 쌓아 올린 코드는 내 시스템이 아니라 남의 코드를 잠시 빌린 것에 가깝다. 요청 하나를 처음부터 끝까지 소리 내어 추적할 수 있는가, 오류가 생겼을 때 모델에 에러를 붙여 넣기 전에 먼저 어느 지점이 의심스러운지 감을 잡을 수 있는가—이 두 가지가 소유권의 기준이 된다.
이 논리는 성능 최적화 영역에서 더 선명하게 드러난다. 에이전트는 코드를 생성할 수 있지만, 이미지 하나가 LCP를 망가뜨리는 구조를 사전에 설계하진 않는다. dev.to의 이미지 배포 전 체크리스트가 보여주는 일곱 가지 항목은 모두 '의도적으로 확인하지 않으면 놓친다'는 전제 위에 있다. 4000px짜리 원본을 800px 컨테이너에 그냥 서빙하는 것, 스마트폰 사진에 GPS 좌표가 그대로 실려 나가는 것, 소셜 공유 시 og:image가 깨지는 것—에이전트는 이런 실수를 아주 능숙하게 재현한다. 지시받은 대로, 빠르게.
체크리스트를 구체적으로 보면, 디스플레이 사이즈와 실제 이미지 해상도의 불일치는 DevTools 한 번으로 확인된다. srcset과 width/height 속성은 에이전트도 작성할 수 있지만, 렌더링 컨텍스트에 맞는 사이즈를 판단하는 건 개발자의 몫이다. sharp로 WebP를 quality 78로 압축하면 대부분의 콘텐츠 이미지는 150KB 이하로 떨어진다—이 기준을 어디에, 왜 적용해야 하는지를 모르면 에이전트가 생성한 이미지 파이프라인은 기준 없이 돌아간다. EXIF 스트리핑은 빌드 파이프라인이 자동으로 처리하지만, CMS 직접 업로드 경로가 열려 있다면 그건 여전히 인간이 막아야 할 구멍이다.
결국 두 맥락이 같은 지점을 가리킨다. 에이전트에게 위임할수록, 개발자가 '로드베어링 월'—구조를 떠받치는 핵심 결정들—을 직접 이해하고 있어야 한다는 것. 성능 관점에서 그 벽은 이미지 포맷 선택 기준, LCP 예산, 메타데이터 노출 위험, 소셜 크롭 전략 같은 것들이다. 코드를 타이핑하는 일은 위임해도 되지만, 이 기준들을 설계하는 일은 위임할 수 없다. 에이전트가 빠르게 뽑아낸 이미지 컴포넌트가 Core Web Vitals를 망가뜨리는 순간, 그 배포 버튼을 누른 사람이 바닥이 된다.
앞으로 에이전트의 코드 생성 능력은 더 빨라지고 더 그럴싸해질 것이다. 하지만 성능 회귀는 더 조용해지고, 더 늦게 발견될 가능성이 높다. 빌드가 통과하고, 타입이 맞고, 스토리북에서 멀쩡해 보여도—실제 사용자의 네트워크와 디바이스에서 LCP가 3초를 넘기거나, 개인정보가 EXIF에 실려 나가는 일은 여전히 일어난다. 그 간극을 메우는 건 더 나은 모델이 아니라, 개발자가 직접 설계한 의도와 체크리스트다. 에이전트가 운전하게 두되, 경로는 당신이 알고 있어야 한다.