AI 도구가 본격적으로 팀 워크플로우에 자리 잡은 지 1~2년이 지났다. '속도'라는 약속은 어느 정도 이행됐다. 코드는 더 빠르게 생성되고, 프로토타입은 몇 시간 안에 완성된다. 그런데 현장의 목소리는 묘하게 지쳐있다. 빨라진 건 맞는데, 무언가가 자꾸 뒤에서 어긋나는 느낌. 그 '무언가'가 무엇인지를 세 개의 실무 사례가 각기 다른 층위에서 정확히 짚어준다.
코드는 AI가 짜는데, 책임은 여전히 사람 몫
100개 이상의 개발팀을 4개월 동안 인터뷰한 결과를 정리한 Dev.to 아티클은 불편한 사실 하나를 수면 위로 끌어올린다. AI 에이전트가 코드를 대량 생산하는 시대에도, 인간이 루프에서 빠져나간 게 아니라 루프의 가장자리로 밀려난 것뿐이라는 점이다.
팀들이 공통적으로 겪는 리뷰 병목은 표면적으로는 '시간 부족' 문제처럼 보인다. 에이전트가 PR을 쏟아내는 속도를 인간 리뷰어가 따라가지 못한다. 하지만 인터뷰 대상의 약 40%는 더 근본적인 불안을 토로했다. 시간이 아니라 제어력 상실이었다. 코드가 시스템 전체에 어떤 영향을 미치는지, 그 변경이 왜 이 방향으로 만들어졌는지를 더 이상 자신 있게 말할 수 없다는 것.
시니어 개발자가 PR을 빠르게 리뷰할 수 있는 건 코드베이스 전체의 멘탈 모델이 머릿속에 있기 때문이다. 데이터 모델의 변화를 보고, API 경계를 확인하고, 비즈니스 로직을 점검한다. 그 리뷰 행위 자체가 멘탈 모델을 최신 상태로 유지하는 메커니즘이었다. 그런데 AI가 코드를 작성하면서 이 안전망이 끊겼다. 예전엔 코드 작성자가 팀원이었고, 왜 이렇게 짰는지 물어볼 수 있었다. 지금은 작성자가 이미 자리를 뜬 낯선 누군가다. 변경의 맥락은 에이전트의 세션 안에 있지, diff 안에 없다.
그 결과, 리뷰어는 스캔이 아니라 추론을 해야 한다. 14,000줄짜리 PR을 마주하고 "이게 뭘 하는 건지 어떻게 믿지?"라는 말이 나오는 건 과장이 아니다. 리뷰 봇을 추가해도 해결이 안 된다. 봇은 개별 라인을 플래그하지만, 정작 중요한 질문인 '이 변경이 시스템에 무슨 일을 하는가'에는 답하지 못한다. 결국 코드는 AI가 쓰고, AI가 검토하며, 사람은 그 신호를 슬쩍 무시하게 되는 구조가 만들어진다.
인터뷰에서 반복적으로 등장한 결론은 냉정하다. AI 도구는 쓰기 비용을 낮췄지만, 읽고 이해하고 책임지는 비용은 오히려 높아졌다. 제약의 위치가 이동했을 뿐, 제약 자체는 사라지지 않았다.
눈에 안 보이는 캐시 버그가 몇 주를 날린다
속도 지향 개발이 만드는 문제는 팀 프로세스에만 있지 않다. 기술적 층위에서도 '잘 돌아가는 것처럼 보이지만 사실은 망가져 있는' 상태가 조용히 쌓인다. Next.js 15.5의 ISR 버그 분석은 그 전형적인 사례다.
export const revalidate = 300을 선언했다. 9개 로케일은 ISR이 정상 작동하고 있었다. 그런데 크롤러가 가장 많이 때리는 canonical URL, 영어 비접두사 경로만 몇 주째 요청마다 서버 사이드 렌더링을 풀로 돌리고 있었다. 원인은 단 하나, middleware.ts의 NextResponse.rewrite()였다.
Next.js 15.5에는 미들웨어 rewrite를 거친 경로에 대해 ISR 캐시가 생성되지 않는 버그가 존재한다(이슈 #83862). 정확히는 라이터 사이드 장애다. 캐시 엔트리 자체가 만들어지지 않으니, 캐시 조회를 아무리 개선해도 의미가 없다. 헤더를 보면 명확하다. rewrite를 거친 경로는 Cache-Control: private, no-cache, no-store에 x-nextjs-* 헤더가 아예 없다. 반면 접두사 경로(/ja/...)는 s-maxage=300, stale-while-revalidate가 정상적으로 붙는다.
이 버그가 몇 주간 탐지되지 않은 이유가 흥미롭다. 접두사 붙은 로케일은 정상이라 'ISR 작동 확인' 테스트가 통과한다. /en/bot은 /bot으로 307 리디렉트되니 curl 테스트가 리디렉트 응답만 보고 끝난다. 게다가 하루에도 여러 번 배포하면서 buildId가 바뀌고 캐시가 무효화되니, 콘텐츠가 실제로 stale하게 보이는 일도 없었다. revalidate = 300은 그냥 장식이었고, 배포 빈도가 그 사실을 덮어버리고 있었다.
수정 방법은 rewrite를 middleware.ts에서 꺼내 next.config.mjs의 rewrites()로 옮기는 것이다. 설정 rewrite는 라우트 매니페스트를 통해 적용되므로 Next 서버가 pre-rewrite 경로를 보지 않는다. afterFiles를 사용하면 실제 라우트가 먼저 우선 처리되어 /sitemap.xml 같은 정적 파일들이 자연스럽게 제외된다. 단, 정규식 트랩이 두 개 있다. 세그먼트 경계 앵커((?:/|$))를 빠뜨리면 빌드는 통과하고 프로덕션에서 404가 난다. 루트 레벨 다이나믹 라우트는 afterFiles의 정적 라우트 우선 보호를 받지 못해 reserved 목록에 수동으로 명시해야 한다.
이 사례가 시사하는 건 기술적 수정법만이 아니다. AI 보조 개발로 배포 사이클이 짧아질수록, 이렇게 조용히 망가져 있는 상태를 정상으로 오인하는 시간도 길어진다는 점이다. 시스템이 빠르게 변하고, 확인해야 할 경로의 조합이 늘어나며, 진짜 병목은 코드 작성이 아니라 '이게 실제로 제대로 동작하는가'를 검증하는 데 있다.
음성 에이전트 UX: 신뢰는 응답 품질이 아니라 실패 순간에 결정된다
속도와 품질의 긴장은 AI 인터페이스 설계에서 또 다른 형태로 나타난다. 음성 에이전트를 평가하는 UX 프레임워크를 제안한 Dev.to 글은, 대부분의 리뷰가 전사 품질과 응답 자연스러움에 집중하는 걸 비판하며 시작한다. 그건 음성 품질 체크리스트지, 신뢰 체크리스트가 아니라고.
음성 인터페이스는 시각적 affordance가 없다. 스피너도, '입력 중...' 표시도, '종료' 버튼도 없다. 시스템 상태는 타이밍과 말, 그리고 턴 교환을 통해서만 전달된다. 그래서 저자는 여섯 가지 평가 차원을 제시한다.
대화 여정(해피패스가 아닌 실제 분기 경로), 메모리와 망각(컨텍스트를 언제 어떻게 잊는지, 그리고 그걸 솔직하게 알리는지), 침묵과 망설임(1~2초 이상의 무음이 '처리 중'인지 '오류'인지 사용자는 알 수 없다), 끼어들기와 명확화 요청(신뢰도가 낮을 때 계속 밀어붙이는지, 아니면 되묻는지), 오해 복구(에이전트의 신뢰도에 대한 가장 지속적인 인상은 실수 이후 어떻게 행동하느냐에서 형성된다), 마지막으로 신뢰 형성(앞의 다섯이 누적되어 사용자가 실제로 중요한 것을 맡길 의향이 생기느냐).
이 프레임워크가 흥미로운 건 기능 목록이 아니라 태도를 강조한다는 점이다. '기능 전에 동의, 속임 대신 공개, 설정이 아닌 구조적 감독.' AI임을 초반에, 묻기 전에 알린다. 단순히 사실을 전달하는 게 아니라 언제 알리느냐가 중요하다. 30초 동안 친밀감을 쌓은 뒤 "저는 AI입니다"라고 말하는 것과 첫 마디에 밝히는 것은 전혀 다른 경험이다. 결제, 예약, 삭제같은 결과가 따르는 행동에는 "정말요?"가 아닌 구조적 확인 단계가 플로우 안에 있어야 한다.
자기 보고 신뢰도와 실제 행동이 자주 불일치한다는 지적도 날카롭다. "신뢰하셨나요?"라고 물어보는 것만으론 부족하다. 사용자가 실제로 다음 태스크를 에이전트에 위임하는지를 함께 봐야 한다.
세 사례가 가리키는 하나의 지점
세 이야기는 서로 다른 레이어를 다루지만, 같은 곳을 가리킨다. AI가 생산 속도를 높이면서 기존에 인간이 자연스럽게 담당하던 검증, 이해, 신뢰 형성의 비용이 수면 위로 올라왔다는 것.
팀 프로세스에서는 리뷰어의 멘탈 모델 유지 비용이 올라갔다. 인프라 레이어에서는 빠른 배포 사이클이 조용한 기술 부채를 감추는 시간을 벌어준다. UX 레이어에서는 기능이 완성되어도 사용자가 그걸 신뢰하기까지의 설계가 따로 필요하다.
프로덕트 관점에서 보면 이건 나쁜 소식이 아니다. 제약의 위치가 명확해졌다는 뜻이니까. 작성은 저렴해졌다. 이제 투자해야 할 곳은 읽고, 검증하고, 신뢰를 설계하는 레이어다. 그게 다음 병목이고, 거기에 도구와 프로세스와 UX 사고가 집중되어야 할 이유다.