AI가 하룻밤 사이에 기능을 완성하는 시대에, 정작 개발자가 손을 놓으면 안 되는 영역이 세 곳 있다. 사용자가 제품을 '좋아하게 만드는 감성', AI 에이전트가 무엇을 하고 있는지 파악하는 가시성, 그리고 아무도 의심하지 않았던 코드 한 줄이 프로덕션을 불태울 수 있는 성능이다. 세 가지 모두 AI가 자동으로 채워주지 않는다. 오히려 AI 속도가 빨라질수록 이 빈자리는 더 크게 벌어진다.
1. 감성: AI가 복제하지 못하는 마지막 해자
기능을 구현하는 데 20만 달러가 필요하던 시절엔 '작동하는 것'만으로도 차별화가 됐다. 이제 동일한 기능을 20달러면 만들 수 있고, 고객이 직접 만드는 경우도 생겼다. GeekNews가 소개한 MLP(Minimum Lovable Product) 논의는 이 지점을 정확히 짚는다. 기능 기반 차별화가 무너진 자리에서 유일하게 살아남는 것은 사용자가 제품과 맺는 감정적 관계다.
논의에서 제시하는 SaaS 니즈 피라미드는 단순하지만 날카롭다. Functional → Reliable → Usable → Lovable. 대부분의 AI 생성 제품은 앞의 두 단계를 빠르게 통과하지만 Lovable 단계에서 멈춘다. Superhuman이 받은편지함을 비울 때 띄우는 그림, Spotify AI DJ가 "이 노래 지난주 매일 들었죠"라고 건네는 한마디—이런 요소들은 기능적으로는 쓸모없어 보이지만, 사람들이 가장 오래 기억하는 순간을 만든다.
AI는 이 감정적 레이어를 아직 복제하지 못한다. 정확히는, AI에게 "이 인터랙션을 어떻게 더 lovable하게 만들 수 있을까?"라고 물어야 비로소 아이디어가 나온다. 즉, 감성의 방향을 설정하고 기준을 명시적으로 높게 유지하는 것은 여전히 개발자·프로덕트 팀의 몫이다. AI가 속도를 내주는 동안, "이것은 lovable한가?"라는 질문을 던지는 사람이 없으면 결과물은 매번 MVP 수준으로 회귀한다.
2. 가시성: 블랙박스 에이전트를 투명하게 만드는 일
Claude Code는 20만 토큰 컨텍스트 창을 제공하지만, 그 창의 몇 퍼센트를 사용하고 있는지, 세션당 비용이 얼마인지, 어떤 파일을 건드렸는지 전혀 보여주지 않는다. 개발자 slima4가 dev.to에 공개한 ClaudeUI 프로젝트는 이 답답함에서 출발했다. 자동 압축(auto-compaction)이 갑자기 발동해 컨텍스트가 날아가는 경험, 세션이 끝난 뒤에야 비용을 확인하는 상황—이것은 도구의 성능 문제가 아니라 가시성의 문제다.
ClaudeUI가 제공하는 것은 기술적으로 복잡하지 않다. Claude Code가 내부적으로 생성하는 JSONL 트랜스크립트 파일을 파싱해 상태바, 실시간 모니터, 세션 통계를 만든다. 외부 API도, 별도 서비스도 필요 없다. 그럼에도 이 도구가 의미 있는 이유는, AI 에이전트가 강력해질수록 그 내부가 더 불투명해진다는 역설을 정면으로 해결하기 때문이다. 컨텍스트 사용률, 잔여 턴 수, 파일별 수정 빈도—이것들을 실시간으로 볼 수 있을 때 비로소 에이전트를 '사용'하는 것이 아니라 '운용'할 수 있다.
이 프로젝트에서 눈여겨볼 교훈이 하나 더 있다. 도구의 내부 포맷이 문서화되어 있지 않아 역공학으로 해석해야 했고, 그 포맷은 업데이트 시 언제든 깨질 수 있다는 점이다. AI 에이전트를 실무에 통합할수록 이런 '비공식 인터페이스'에 의존하는 상황이 늘어난다. 가시성 레이어를 직접 설계하지 않으면, 블랙박스는 영원히 블랙박스로 남는다.
3. 성능: '작동한다'와 '괜찮다'는 다르다
dev.to에 올라온 한 편의 인시던트 리포트는 프론트엔드 성능 문제의 본질을 압축적으로 보여준다. 새벽 2시에 울린 프로덕션 CPU 96% 경보, 원인은 타임스탬프를 1밀리초마다 업데이트하는 setInterval 코드 한 줄이었다. 페이지에 존재하는 3,842개의 [data-time] 요소를 초당 1,000번 DOM 스캔하면 초당 약 400만 번의 DOM 연산이 발생한다. 수정은 간단했다. 인터벌을 1ms에서 60,000ms(1분)으로 바꿨고, CPU는 즉시 정상화됐다.
이 사례가 AI 시대에 더 위험해지는 이유가 있다. 코드를 작성한 개발자 Kevin은 잘못된 의도를 가진 게 아니었다. "실시간으로 업데이트하려면 setInterval을 써"라는 조언을 그대로 따랐고, 숫자가 작을수록 더 자주 업데이트된다는 것까지는 이해했다. AI가 생성한 코드도 이와 다르지 않다. "실시간 타임스탬프 업데이트 코드 짜줘"라고 프롬프트하면 기능적으로 작동하는 코드가 나오지만, 그 코드가 수천 개의 DOM 요소와 맞닥뜨렸을 때 어떤 일이 벌어지는지는 문맥이 없으면 AI도 고려하지 않는다.
프론트엔드 성능은 "작동한다"와 "괜찮다" 사이의 간극이다. AI는 전자를 빠르게 채워주지만, 후자는 여전히 개발자가 검증해야 한다. requestAnimationFrame vs setInterval, DOM 배치(batch) 업데이트, 가상화(virtualization)—이런 판단은 코드의 맥락, 데이터 규모, 실제 사용 패턴을 종합해야 내릴 수 있다. Core Web Vitals 지표가 나빠지는 순간은 대부분 이런 '기능적으로는 맞지만 현실에서는 틀린' 코드가 프로덕션에 올라갈 때다.
세 가지가 가리키는 하나의 결론
MLP 논의, ClaudeUI, 1밀리초 인시던트—세 이야기는 서로 다른 영역을 다루는 것 같지만 같은 방향을 가리킨다. AI가 만드는 속도는 이미 인간을 앞질렀다. 그 속도 속에서 감성의 기준을 세우는 것, 에이전트의 행동을 들여다보는 것, 코드가 현실과 충돌하는 지점을 검증하는 것—이 세 가지는 자동화되지 않는다.
달리 말하면, 이 세 가지야말로 AI 시대에 프론트엔드 개발자와 프로덕트 팀이 집중해야 할 고유한 영역이다. AI가 빠르게 만들수록, 사람이 직접 챙겨야 할 것들이 더 선명하게 드러난다. 속도가 빨라진다고 해서 책임의 범위가 줄어드는 게 아니라, 오히려 책임의 질이 달라지는 것이다.