Build in Public Ep. 4 Framer 선택 이유, inblog 서브디렉토리 설정 삽질기
Build in Public Ep.4에서는 비개발자가 웹사이트 빌더 Framer를 선택하고, 인블로그(Inblog)를 /blog 서브디렉토리 형태로 연결하기까지의 과정과 Cloudflare 설정 오류 해결기(삽질기)를 공유합니다.
1. 창업 초기, 웹사이트(홈페이지) 구축 시점 결정 및 CMS 선택 이유
전 9월달에 퇴사하고 창업해서 명함도 없고, 로고도 없고, 웹사이트도 없는 상태였습니다. "뭣이 중헌디?" 원칙에 따라 진짜로 필요할 때 만들자라고 생각했습니다.
그러던 중 이제는 컨텐츠 마케팅을 시작해야 한다고 판단했고, 과거 콜라보에서 사용했던 인블로그(Inblog)가 만족스러웠기에 이번에도 인블로그로 만들어보자 라고 결론내렸습니다. 여기서부터 생각이 꼬리를 물었습니다.
블로그를
aientry.io/blog같은 서브디렉토리(Subdirectory) 형태로 운영해야 도메인 권위(Authority)를 하나로 통합해 SEO에 유리하다고 판단했습니다.방문자들이 웹사이트를 볼 텐데 최소한 aientry.io 대문은 있어야겠다.
웹사이트가 필요하겠네. 뭘로 만들지?
그럼 웹사이트에 들어갈 로고도 필요하잖아?
결국 웹사이트와 로고 작업까지 해야겠구나 싶었습니다. 마침 추석 연휴가 다가오고 있었고, 처음 해보는 웹사이트 작업에 집중적으로 몰입하기 딱 좋은 타이밍이었죠.
2. 인블로그(Inblog) 서브디렉토리 연결 가능 웹사이트 빌더 비교 (Webflow, Framer)
CMS 툴로 인블로그를 이미 결정해놓은 상태였습니다. 그래서 인블로그와 서브디렉토리 형태(aientry.io/blog) 로 연결이 가능한 툴이나 방법을 찾아봤습니다.
확정: 블로그 = 인블로그 (CMS 역할)
필수: 서브디렉토리 연결 (aientry.io/blog)
제외: Wix, Squarespace (인블로그와 서브디렉토리 연결 불가)
가능: 바이브코딩 툴 (대표적으로 Lovable)
가능: Framer vs Webflow (인블로그 연결 가능)
3. 비개발자에게 가장 빠른 웹사이트 빌딩, Lovable 을 제외한 이유
인블로그와 서브디렉토리 형태로 연결이 가능한 옵션이 3가지 남았고, 이 중에서 나에게 뭐가 맞는지 알아내야 했습니다. 처음하는 일이다 보니 무슨 기준으로 선택해야 하는지 몰라서 유튜브도 보고, 구글링도 해보고, 클로드 프로젝트 생성해서 질문하면서 어떤 기준으로 선택해야 하는지 감을 잡아가기 시작했습니다.
‘비개발자인 나에게 뭐가 제일 빠르게 구현하기 좋을까?’ 이 기준에 따라 Lovable 같은 바이브코딩 툴을 제외했습니다. 제외한 이유는 자유도 때문이었습니다.
웹사이트를 내 마음대로 만들고 싶었던 게 아니었습니다. 이미 수많은 웹사이트들이 존재하니, 좋은 템플릿을 활용해서 최대한 빠르게 만들자 주의였습니다. 자유도는 저 같은 비개발자 쌩초보에게는 오히려 틀이 없어서 더 시간이 많이 투입되고 느리게 만듭니다. 그리고 코드를 어쨌든 생성하게 되니 그럼 깃허브도 써야하고, 배포도 관리해야 하고 유지보수 측면에서 지금은 아니다라고 판단했습니다.
4. 비개발자 웹사이트 빌더 최종 결정: Framer를 선택한 3가지 이유
최종 선택지인 Webflow와 Framer 2개 다 사용을 짧게라도 해봤습니다. 결론적으로 제가 Framer를 선택한 이유는 크게 3가지입니다.
Figma와 거의 동일한 사용성: 비개발자이지만 기획과 디자인을 위해 Figma는 사용해왔습니다. Framer는 Figma 사용하는 것과 거의 유사해서 학습 곡선이 매우 낮았습니다.
강력한 템플릿 생태계: 템플릿으로 후다닥 만들기 위해 Framer를 선택했습니다. 템플릿을 수정하는 것만으로도 전문가 수준의 웹사이트를 빠르게 구현할 수 있었습니다.
개발 지식이 거의 불필요: Framer는 디자인을 하면 바로 웹에 배포(Publish)가 되는 방식입니다. 반면 Webflow는 더 정교한 CMS와 로직 구현이 가능하지만, 그만큼 '개발'에 대한 이해가 필요했습니다.
요약하자면, 개발 지식이 있다면 Webflow, 아니라면 Framer를 추천합니다.
가격은 둘 다 비슷해서 큰 요인은 아니었고, 할인코드 검색해보니 25% 짜리가 있어서 더더욱 부담이 덜했습니다. Framer 기본 플랜 할인코드 적용해서 1년 연결제하니 9만원이 조금 안되었습니다 :)
5. Cloudflare Worker를 이용한 리버스프록시 설정으로 서브디렉토리 연결하기
이제는 기술적인 설정을 하는 작업을 시작했습니다. 인블로그에 연결 가이드가 있으니 그냥 하나하나 따라가면서 해보자 했습니다.
특히 Framer의 웹사이트 서브디렉토리로 인블로그를 연결하려면 Cloudflare에 가입해야 하고, Cloudflare의 리버스프록시(Reverse Proxy) 기능을 구현해야 한다고 가이드 문서에 있었는데 무슨 말인지도 모르면서 일단 따라했죠.
Cloudflare 가입 및 네임서버 변경
Squarespace에서 구매한 도메인의 네임서버를 Cloudflare로 이전
DNS 레코드 설정 - A 레코드 2개, CNAME 레코드 1개 추가
Cloudflare DNS 레코드 설정 화면 SSL/TLS 설정 - Full (Strict) 모드 설정, Always Use HTTPS 활성화
Page Rule 추가 - SSL 인증서 발급을 위한 특수 경로 설정
Cloudflare Worker 생성 및 코드 배포 - 리버스 프록시 JavaScript 코드 붙여넣기
[스크린샷: Cloudflare Worker 코드 붙여넣기 화면]Worker Routes 설정 - /blog*, /robots.txt 등 4개의 경로 설정
설정 자체는 2시간 정도 걸렸습니다.
6. Framer Auto Connect 오류: Cloudflare Proxied vs DNS only 차이점 및 해결 방법
설정을 완료하고 aientry.io/blog 접속했는데... 404 에러가 떴습니다. 클로드와 함께 한참을 씨름하다가 문제를 발견했습니다.
Framer의 Auto Connect 기능이 DNS 설정을 변경해버린 것이었습니다.
Cloudflare에서 수동으로 설정한 DNS 레코드들이 Proxied 상태였는데, Auto Connect가 이걸 DNS only 상태로 바꿔버렸던 거죠.
DNS only 상태에서는 트래픽이 Cloudflare를 거치지 않고 바로 Framer 서버로 가버려서, Worker가 /blog 경로를 인블로그로 보낼 수가 없었던 겁니다.
방문자 → aientry.io/blog 입력
DNS only 상태: Framer 서버 직행 = Cloudflare Worker 실행 안 됨 → 404 에러!
Proxied 상태: Cloudflare Worker 실행 = blog 연결 → 인블로그로 전달
Framer의 Auto Connect 버튼 안 누르고, Cloudflare에서 수동으로 3개의 DNS 레코드(A 레코드 2개, CNAME 1개)를 모두 Proxied 상태로 바꿔주니 드디어 aientry.io/blog 정상적으로 인블로그로 연결되었습니다!
7. 삽질 끝에 배운 교훈: 일단 시작하고 문제 해결하며 배우는 개발 지식
DNS가 뭔지도 모르면서 설정했고, 리버스프록시가 뭔지도 모르면서 코드를 붙여넣었죠. 404 에러 뜨고 나서야 Proxied 상태가 뭔지 알게 됐고요. 모든 걸 이해하고 시작하려고 했다면 아직도 시작도 못 했을 겁니다.
문제를 해결하는 과정에서 머릿속에 지식이 쌓이고 구조가 잡혀갔습니다.
일단 해보는 게 제일 빠르게 배웁니다 :)