프레이머, 그리고 시각적 편집의 단점
프레이머도 결국은 단점이 있다. 그러나 당분간은 계속 쓰긴 할 듯
예전에 프레이머를 처음 접했을 때에는 약간의 적응이 필요하곤 했지만, 로직을 거의 대부분 이해하고 나서는 정말 사랑하는 도구 중 하나가 되었다. 특히 피그마랑 거의 같은 로직을 공유하는 게 좋았고, 일부는 더 나은 점도 있었음. 예를 들면 Z 인덱스 조정, Fill 비중 설정 같은 것들.
근데 최근에 프레이머로 작업하면서, 'AI로 했으면 안 이랬을텐데'라는 생각이 가끔 들곤 한다. 물론 프레이머 안의 AI 에이전트를 써도 되긴 하지만, 그럼 캔버스의 존재 이유도 없고, 무엇보다 사용량을 다 썼다(..) 그래서 간단히 적어보고자 함
눈에 안 보이는 건 놓치게 된다
얼마 전 블로그 상세 페이지에서 이 글이 어떤 타입이냐에 따라 한쪽은 B2C CTA, 반대편은 B2B CTA 버튼을 표시하려고 한 적이 있었다. 그런데 프레이머 캔버스의 경우에는 보고 있는 글 중 하나를 선택해서 보는 방식이고, 내가 열어둔 페이지가 B2C였기에 그 레이아웃만 보고 있었다는 것을 잠시 망각하게 됨. 그래서 이 CTA 버튼의 가로폭을 조정했는데, B2B CTA는 조건문 때문에 숨겨져 있던 상태라서 조정을 잊어버렸고, 결국에는 배포 후 나중에야 B2B 글을 한 번 확인해보면서 알아차렸다.
만약 AI한테 시켰으면, '블로그 최하단 CTA 버튼의 가로폭 최댓값을 700px로 제한해줘'라고 했을 테고, 그럼 아무 문제 없이 잘 적용이 되었지 않았을까 싶다.
사실 내가 이런 문제 때문에 UI 코드를 시각적으로 직접 편집하는 툴(특히 익스텐션)을 별로 안 좋아하는 이유이기도 함. 화면에 표시되는 버튼의 스타일을 수정했는데, 다른 조건에서 다른 Variant로 나오는 버튼의 디자인은 그대로 남아버린다던가 하는 식. 아무래도 단순한 스태틱 페이지가 아니라 복잡한 기능이 있는 UI라면 이런 경우가 더 잦을 테고, 그럼 내가 못 보던 경우의 수에 해당하는 화면은 엉뚱하게 표시되고 있는 경우가 많아질 거라는 생각이다.
그래도 랜딩페이지에는 이런 경우가 많지 않으니 별 신경을 안 썼던 건데, 거의 유일한 조건문 표시 로직 부분에서 놓쳐버린 거였음
직접 구현할 땐 공짜였던 것들이 유료가 된다.
가장 간단한 예시는 당연히 'Made with Framer' 같은 낙인일거고, 여기서 좀 더 나아가면 리다이렉트, A/B 테스트, 스테이징 및 복구, 페이지 수 제한 같은 것들이 될 것이다.
(가장 낮은 플랜으로도 이전 기록을 볼 수는 있다. 그런데 되돌릴 순 없다. 그 동안의 발전을 감상하라는 용도인가?ㅋㅋ)
이 기능들은 이미 알겠지만 다 그냥 구현을 하면 되는 문제다. 그러나 프레이머에서는 아니다. 커스텀 코드로 어느 정도는 처리할 수 있다 해도 한계가 있고, 억지로 구현한다 해도 관리도 지저분해지니까.
특히 AI가 코드베이스부터 전부 읽을 수 없다는 문제도 있다. AGENTS.md 같은 문서를 넣기도 힘들고, AI는 원래 자기가 잘 알던 언어나 프레임워크가 아니라 Framer라는 새로운 인프라 위에서 작동하는 시스템에 대한 지식만을 바탕으로 작동해야 한다. 실력이 뒤떨어질 수 밖에 없다.
AI 사용량도 마찬가지. 이미 다른 AI를 구독하고 있어도 이를 기반으로 프레이머를 연동해서 쓰기가 상당히 까다롭다. 내부 사용량을 쓰게 하려는 목적이겠지만 영 불편한 상태임
프레이머에 발이 묶인다.
가장 큰 단점이라고 볼 수도 있음. 언제든 떠날 수 있었다면 위의 문제들도 별 고민이 안 된다. 그러나 대부분의 프레이머 기반 웹사이트들은 완벽히 프레이머에 맞춰 디자인된 상태고, 그 어떠한 변환 툴들도 이런 디자인을 완벽하게 일반 코드베이스 방식으로 복제 혹은 마이그레이션 할 수 없다는 거. 게다가 리다이렉트 작업도 들어가야 할 거고, 이래저래 챙길 것도 수두룩하다.
간단히 말해서 락인이 너무 심하다는 거다. 그나마 프레이머는 정적 페이지 용이고 이런 페이지는 복제하기에 더 용이하긴 하지만, 그래도 대공사가 될 것임은 틀림없다.(GPT 6 Astra가 다 해주려나?)
그래서 갑자기 프레이머가 가격을 올리면 정말 멘붕이 빠질 것 같다. 억지로 비싼 돈을 내던지, 엄청난 수고를 들여서 웹사이트를 마이그레이션 혹은 처음부터 다시 제작해야 하니까.
그래도 쓸 이유는 여전히 있다
시각적 편집, 그리고 Publish 버튼 하나만으로 변경사항이 몇 초면 반영된다는 건 물론 장점이다.
특히 웹사이트 변경이 잦고, Pixel-Perfect한 디자인을 구현하고 싶다면 프레이머가 사실 여전히 좋은 선택지라고 생각하긴 함. 만약 디자인 팀이 이미 있는 회사라면 굳이? 라는 생각은 들지 모르겠지만, 어쨌든 디자이너가 직접 페이지에 바로 관여할 수 있다는 것도 장점이다. 적어도 프레이머는 뭔가 프레임을 하나 잘못 건드려도 페이지가 500을 내뿜지는 않는다!
이미지 배치같은 것도 몇 픽셀씩 움직여보면서 마음에 드는 값을 찾기 마련인데, 코드의 숫자를 계속 바꾸면서 제어하는 것보단 확실히 편하다. (당연히 AI한테 시키는 것보다도 빠르고) 카피라이팅의 경우에도 아무래도 코드에서 보는 것보다, 실제 화면에서 어떻게 보이는지를 실시간으로 보면서 제어하는 게 확실히 직관적이다.
그리고 템플릿들도 아주 큰 장점이라고 생각함. 일단 이 템플릿들을 컴포넌트와 인터랙션, 디자인 시스템까지 모두 고려해서 완벽하게 코드로 마이그레이션하는 도구는 없는 걸로 알고 있고, 무료 템플릿들의 퀄리티도 아주 좋은 편이다. 특히 사이드프로젝트에서는 처음부터 만드는 것보다 템플릿이 훨씬 좋음. AI 조련해서 처음부터 다 만들고 AI 밤티 디자인 제거하면서 작업할 생각하면 벌써부터 머리가 아프다. 간단한거면 모르겠는데 특히 비주얼이 중요한 곳에서는 더더욱.
이렇게 적어보니까, (템플릿 같은 걸 빼면)프레이머의 장점이 코드 편집 및 저장 버튼을 눌러 눈에 보이기까지의 시간차로 인한 스트레스를 줄여주는 도구일 뿐인가 하는 생각도 드네. 어차피 배포라면 워크플로우를 구성해서 충분히 편리하게 만들 수 있으니까.
사실 대부분의 단점은 피그마 AI 에이전트로 해결이 된다고 생각은 한다만, A/B 테스트나 스테이징, 롤백은 여전히 이걸로 해결이 안 되는, 의도적으로 급 차이를 두면서 막아놓은 부분이라 해결할 순 없다. 이제 AI로 누구나 웹사이트를 만들 수 있는 시점에서, 어쨌든 제대로 쓰려면 돈을 내야 하는 프레이머를 막 추천하기는 애매해졌다는 생각이 든다. AI가 있다 해도 어쨌든 피그마처럼 툴에 대한 적응도 필요할거고.
결론: 여전히 좋지만 확실히 입지는 줄었을 것 같다. 만약 서비스 중단하면 내 사이트도 다시 만들어야 하는거 아님? 마이그레이션을 지원해줄까? 걸리는 건 이놈들은 피그마와 유사한 프로토타이핑 툴에서 이미 피보팅을 한 전적이 있다는 거임..