설탕빵의 설탕공방디자이너가 싫어하는 말 "알아서 해주세요"
다행이 AI는 불평을 하지 않는다. 그냥 알아서 할 뿐이다.
그저 우리가 마음에 안들 뿐
이번에는 간단히 AI와 프론트엔드 작업시 발생하는 문제점들을 다뤄보고자 한다.
성능은 포기한다.
React 등의 프론트엔드 프레임워크가 왜 나왔을까
바로 최적화된 성능을 위해서다.
버튼 하나 클릭했다고 "오케이 페이지 다시 그릴게~"에서 벗어나고자
"애랑 연관있는 애네들만 그리자"라는게 기반이다.
또한 웹에 사용자가 많아지고, 기능도 많아지니 복잡해져서
복잡해지니 성능을 관리해야해서
상태(State)를 효율적으로 기억하고 다루고자 나온 것이다.
즉 체급 커지고 먹을게 많아지더니 자잘한 지병이 찾아오니 건강 관리하자는 거다.
AI는?
안물어보면 안궁금하다 애는 구현에 초점이 맞춰져있으니
구현 = 체지방량 증가다.
자잘자잘한 살이 덕지덕지 붙기 시작하는 거다.
응 구현한거 또 구현할게
React에 경우 높은 재사용성과 생산성을 위해 한번 만든 구조를 컴포넌트화 해서 여기저기서 돌려쓴다.
AI한테 "~페이지 만들어줘"하면 애는 그걸 딱 만들어준다.
"재사용성을 고려한~ 한 컴포넌트" 를 따로 명시해줘야한다는 것이다.
이거를 안지키면?
A 페이지를 만들더니
디자인이 다른 B 페이지를 만든다.
같은 디자인이지만 뭔가 서로 다른 애매한 페이지들이 나온다는 것이다.
반응형? 그런 형 모름
애는 약간 복불복인데 페이지 만들면 종종 개별요소가 상위 요소를 뚫어버리거나
모바일 환경으로 줄이면 콘텐츠가 정해진 틀을 벗어나 새로운 도전을 하기 시작한다.
당장 우리 일일미션 달성 페이지만 가더라도 콘텐츠 내용이 div를 탈출해서 날뛰는 모습을 볼 수 있다.
이 사이트가 바이브 코딩으로 만들어졌다에 내 클로드 구독권을 걸 수 있다.
아무튼 반응형까지 까리하게 되길 원하면 그리드 시스템을 명시해주자.
layout:
grid: { columns: 12, gutter: 24, maxWidth: 1280 }
breakpoints: [360, 768, 1024, 1280]
위와같이 설계도를 던져주는 방식이 좋다.
상태 관리? 디자인만 요청하셨자나요
"카드형 디자인으로 해주고 데이터도 밀어넣어줘!"
때로는 우리가 요구를 추상적으로 할 수 있다.
보통 백엔드가 프론트 AI한테 맞긴다고 하면
"아 내가 디자인을 잘모르니 AI에 맡겨보자"
라는 방식으로 접근하는 경우가 있다.
프론트엔드의 꽃은 디자인이 아니다.
효율적인 컴포넌트와 상태관리 그리고 화면 렌더링이다.
프롬프트는 처음이 중요하듯이 처음이 디자인으로 시작한다면 AI는 디자인에 집중하게 된다.
또한 디자인 다음에는 기능이다.
기능에 부차적으로 고려해야 될 안정성은 인지하지 못하면 뒷순위로 밀려날 가능성이 크다는 뜻이다.
제 눈에는 보이는데요
접근성이라는 개념이 있다.
눈이 불편하신 분들도 어떻게 우리 사이트를 이용하기 용이하도록 할 것인가.
이건 공공쪽 일을 하다 보면 더욱 체감이 된다.
하지만 AI가 학습한 대부분에 코드에는 이러한 접근성이 고려된 코드보다는 비용과 효율을 생각해 급하게 짠 코드가 더 많을 것이다.
또한 매번 새롭게 작업하거나 세션이 초기화되거나 AI의 개발 스타일은 매번 달라질 수 있다.
요청해서 잘 하다가도, 어느순간 한번 어긋나기를 반복 할 수 있다는 것이다.
우리는 AI를 어떻게 다뤄야하는 가
AI의 발전이 너무나 빨라 개발자는 이제 오퍼레이터가 될 것이라는 의견이 있다.
실제로도 조금의 정성들인 설계도와 규칙과 함께 작업을 맡기면 너무나도 쉽게 원하는 기능을 개발해주기도 한다.
하지만 결국 나 자신의 이해가 기반이 되어야하듯이
AI가 만든 코드라고 해도 추가적으로 이해하고 학습하는 과정이 필요해야한다고 생각한다.
디자인을 맡기더라도
어떠한 디자인 개념이 존재하는지 찾아보고 "감각적이고 모던한 디자인을 만들어줘!"대신
글래스모피즘 기반으로 '반투명 유리 질감', '배경 흐림', '밝은 테두리'
등을 명시하고, 정확한 설계도를 던지는 노력이 중요하다.