AI가 프론트엔드에서 멍청한 이유

^{source https://nerdy.dev/why-ai-sucks-at-front-end}

AI는 뻔한 패턴 복제엔 꽤 쓸모 있지만, 프론트엔드의 맥락·렌더링·인간 변수 앞에선 급격히 멍청해짐.

• AI는 온갖 튜토리얼만 잔뜩 훑은 아첨형 개발자 지망생 같음.

  • 결과물은 학습 중 본 패턴을 바탕으로 한 확률적 추정치일 뿐.

  • 학습 재료도 오래된 해법, 개성 없는 UI 패턴, 물 탄 잡지식 위주라 출력이 쉽게 평범하고 낡아짐.

  • 유용한 점도 분명 있는데, 동시에 꽤 한심함.

• 좋은 쪽은 명확함. AI는 boring한 일, 평범한 작업, 닳고 닳은 패턴에 강함.

  • 스캐폴딩: 어디서 본 구조 빨리 토해내기, 이런 건 잘함.

  • 토큰 작업: 토큰 마이그레이션, 매핑 정리 같은 지루한 일 처리 속도 괜찮음.

  • 기능 아웃라인: 뻔한 목록 뽑기에는 적합.

  • 뻔한 패턴 재조합: 결국 copy-paste 속도 부스터 역할.

  • 다만 자신감 넘치게 헛소리도 잘함.

    • 코드 조각 하나 툭 던지고 일 끝났다고 말함.

    • 실제로는 끝난 게 아님.

  • 그래도 프로그래밍의 큰 비중이 이런 well-worn pattern 위에 있어서, 이 영역만 보면 실제 도움을 꽤 받는 편.

• 나쁜 쪽도 명확함. 픽셀 단위 완성도나 bespoke 해법이 필요한 순간 바로 무너짐.

  • 커스텀 솔루션, 특수 인터랙션: 스크롤 기반 애니메이션이나 미세 상호작용을 시키면 IE6 시대에나 있을 법한 CSS 문법을 지어냄.

  • 레이아웃, 간격: intrinsic/extrinsic 속성 예측이나 동적 계산이 들어가면 수학부터 흔들림.

    • 대칭이어야 할 간격도 제대로 못 맞춤.

  • 복합 상태: 복잡한 컴포넌트 state에서 어디를 고쳐야 하는지 집어내는 일을 힘들어함.

  • 접근성: aria-hidden="true" 같은 걸 벽에 던져놓고 붙길 기대하는 수준.

  • 성능: 명시적으로 요구하지 않으면 가장 무겁고 버벅이는 해법을 내놓기 쉬움.

  • 테스트: 좋은 테스트는 잘 못 쓰고, 많은 테스트는 잘 씀.

  • 특히 컴포넌트가 복잡해질수록 프론트엔드 지원 품질이 더 느려지고 더 멍청해짐.

    • 첫 시도에 그럴듯한 UI나 컴포넌트를 한 방에 뽑아놓고도, 후속 수정 요청 하나에 질식하는 모습이 전형적.

왜 이러냐면

• 첫째, 오래된 쓰레기 위주로 학습했기 때문.

  • 인터넷 자체가 표준 템플릿으로 넘치니 거기에 과하게 기대게 됨.

  • 현대 CSS에 대한 감각도 빈약한 편.

• 둘째, AI는 렌더링 엔진이 아니라 LLM이라서 실제로는 "보는" 능력이 없음.

  • 원래 수학에 약하고, 스크린샷을 던져줘도 큰 도움을 못 받음.

  • 사실상 어둠 속에서 찔러보는 식.

  • 그래서 UI 대화가 늘 이런 식으로 흘러감.

    • AI: "끝났습니다! 완벽한 UI입니다."

    • 나: "아이콘 있어야 할 자리가 뻥 뚫렸는데, 빠진 아이콘부터 고쳐."

    • AI: "맞습니다. 바로 수정하겠습니다."

• 셋째, 우리가 왜 그런 설계를 택했는지 그 "이유"를 모름.

  • 아키텍처 결정의 배경을 이해하지 못하니 표면 패턴만 흉내 냄.

  • SDD, BDD, state machines 같은 틀이 가이드는 될 수 있음.

  • 문제는 모델이 그런 방식과 정말 훌륭한 해법의 짝을 충분히 학습한 것도 아니라는 점.

  • 결국 우리는 거대한 text predictor에게 즉석에서 새 연결을 만들라고 요구하는 셈.

    • 원하는 연결을 만들게 하려면, 고려해야 할 맥락을 사람이 먼저 아주 구체적으로 풀어줘야 함.

• 넷째, 코드가 놓일 환경을 통제하지 못함.

  • Rust, TypeScript, Python은 적어도 실행 환경을 예측 가능하게 고정하거나 pinning하기 쉬움.

    • 글에서는 v14.4처럼 버전 고정 가능한 환경을 예로 듦.

  • HTML, CSS는 전혀 다름.

    • 브라우저 종류, 창 크기, 브라우저 버전, 입력 방식(키보드·마우스·터치·음성), 사용자 선호 등 고정 불가 변수가 너무 많음.

  • 렌더링 엔진은 최종 출력 전까지 수많은 시나리오, 컨텍스트, 변수를 동시에 처리함.

  • LLM은 이걸 통제하지 못하니, 사람이 일부러 중요 변수로 끌어올리기 전까지는 대체로 무시함.

  • 심지어 prompting in logical properties 같은 CSS도 직접 요구해야 나오는 수준.

    • 원래라면 LLM이 기본 출력으로 깔아줘야 할 CSS 상식에 가까운데도 그렇지 않음.

    • 문서까지 던져줘도 제대로 작동한다는 보장 없음.

  • HTML/CSS가 실제로 렌더링되는 장소인 브라우저는 본질적으로 혼돈 그 자체.

    • 버전도 많고, 렌더링 방식도 많고, 상호작용 방식도 많고, 망가지는 방식도 많음.

  • 결국 목표물이 계속 움직이는데, LLM은 이런 moving target에 특히 약함.

• 문제는 인간 쪽도 만만치 않음. 우리 자체가 LLM 입장에선 끝없는 변수의 조합 대상.

  • 사람은 예측 불가함.

  • 생각을 바꾸고, 뷰포트를 바꾸고, 테마 선호를 바꾸고, 기기를 바꾸고, 브라우저와 버전을 바꾸고, 입력 방식까지 계속 바꿈.

  • 우리는 정적인 목표도 아니고, 단순히 학습 가능한 하나의 패턴도 아님.

  • 물론 행동·선호·기대의 "주류 영역"에서는 LLM이 실제로 꽤 도움이 됨.

  • 하지만 인간의 "전체 가능성" 매트릭스는 앞으로도 한동안 LLM 출력 패턴을 계속 폭발시킬 거라는 게 내 생각.

    • 우리가 (스타트렉의) '보그'처럼 개성을 잃고 모두 똑같이 동화되어 버리지 않는 한..