목차
코딩을 배우며 직접 랜딩페이지를 만드는 경우와 AI 도구 Bolt.new·v0를 활용하는 경우를 문과생의 실제 경험 관점에서 비교합니다. 학습 난이도, 작업 시간, 수정·유지보수 측면을 단계별로 정리해 랜딩페이지 제작 방식을 선택할 때 참고할 수 있는 기준을 제공합니다.
랜딩페이지를 처음 만들기로 결정했을 때 가장 먼저 떠오른 질문은 “직접 코딩을 배워서 만들 것인가, 아니면 AI에 맡길 것인가”였습니다. 주변에서는 HTML과 CSS 기초만 배우면 어렵지 않다고 말했지만, 인문계 전공자인 제 입장에서는 새로운 문법과 개발 환경을 익히는 일이 만만하게 느껴지지 않았습니다. 동시에 AI 도구를 사용하면 빠르게 결과물을 얻을 수 있지만, 품질과 통제력을 잃을 수 있다는 우려도 있었습니다. 그래서 저는 동일한 목적의 랜딩페이지를 두 가지 방식으로 각각 시도해 보고, 체감 난이도와 과정의 차이를 직접 비교해 보기로 했습니다.
이 글에서는 문과생인 제가 직접 코딩으로 랜딩페이지를 만들려고 했던 시도와, AI 도구 Bolt.new·v0를 활용해 페이지를 완성한 과정을 나누어 설명합니다. 이어서 두 방식의 난이도를 학습량, 작업 시간, 디버깅의 부담, 디자인 자유도, 유지보수 관점에서 정리해 문과생에게 현실적인 선택 기준을 제시합니다. 글 전반에서 강조하고 싶은 점은 어느 한쪽이 절대적으로 더 낫다고 단정하기보다, 목적과 상황에 따라 적합한 방식을 선택하는 것이 중요하다는 사실입니다.
비전공자가 직접 코딩으로 랜딩페이지를 만들 때의 실제 난이도
먼저 직접 코딩 방식의 난이도를 살펴보겠습니다. 저는 기본적인 HTML 구조와 CSS를 이해하기 위해 온라인 강의를 수강하고, 예제 코드를 따라 치는 것부터 시작했습니다. 제목, 문단, 버튼, 이미지 배치를 위해 필요한 태그와 속성을 익히는 데만도 꽤 많은 시간이 필요했습니다. 문장 하나를 쓰면 바로 의미가 전달되는 글쓰기와 달리, 코드 한 줄은 브라우저가 어떻게 해석하느냐에 따라 전혀 다른 모양으로 나타나기 때문에 처음에는 작은 수정에도 결과를 예상하기 어려웠습니다.
환경 설정도 예상보다 난이도가 높았습니다. 코드를 작성하기 위한 에디터를 설치하고, 폴더 구조를 정리하고, 이미지와 폰트를 불러오는 상대 경로를 맞추는 일은 순전히 규칙을 익히는 문제였습니다. 문과생에게는 이런 규칙이 머릿속 개념으로 연결되기 전까지 단순 암기처럼 느껴졌습니다. 파일을 저장해도 브라우저에서 캐시가 남아 있어 변경 사항이 바로 보이지 않는 상황이 반복되자, “내가 무엇을 잘못한 것인지”를 찾는 과정 자체가 하나의 큰 장벽처럼 느껴졌습니다.
레이아웃을 잡는 단계에서는 난이도가 급격히 올라갔습니다. 화면을 좌우로 나누거나, 이미지와 텍스트를 가로로 정렬하는 등의 기본적인 작업을 하려면 flexbox나 grid 같은 CSS 개념을 이해해야 했습니다. 튜토리얼에서는 간단해 보였던 구문들이 실제 랜딩페이지에 적용되자마자 충돌을 일으키거나, 의도와 다르게 요소들이 겹쳐 보였습니다. 결과적으로 하나의 섹션을 원하는 형태로 정렬하기 위해 여러 번 코드를 지우고 다시 쓰는 과정을 반복했습니다.
반응형 페이지를 구현하는 부분은 또 다른 난관이었습니다. 데스크톱 화면에서는 나름 보기 좋게 정리된 레이아웃이었지만, 브라우저 창 크기를 줄이거나 모바일에서 확인하면 글자가 겹치거나 버튼이 화면 밖으로 밀려나기도 했습니다. 이를 해결하려면 미디어 쿼리를 작성해 특정 해상도에서 스타일을 다시 정의해야 했는데, 각 기기별 기준을 설정하고 테스트하는 작업이 생각보다 복잡했습니다. 문과생 입장에서는 “콘텐츠를 어떻게 전달할 것인가”보다 “어떤 코드 조합에서 깨지지 않는가”를 찾는 데 더 많은 시간을 쓰게 되는 느낌이었습니다.
디버깅 과정도 난이도를 높였습니다. 브라우저 개발자 도구에서 콘솔 에러를 확인하고, 어떤 태그가 예상보다 넓은 영역을 차지하는지 박스 모델을 체크하는 일은 전형적인 개발자의 사고 방식을 요구했습니다. 글을 다듬는 과정처럼 의미를 기준으로 수정하는 것이 아니라, 속성 값과 픽셀 단위를 기준으로 조정해야 했기 때문에 집중력을 꽤 많이 소모했습니다. 결과적으로 한 페이지를 직접 코딩으로 만들어 보는 데에는 학습 시간까지 포함하면 수십 시간이 소요되었고, 완성 후에도 코드 구조에 자신이 없어서 수정과 확장에 대한 부담이 크게 남았습니다.
AI Bolt.new·v0로 만드는 랜딩페이지: 난이도와 작업 흐름
다음으로 AI 도구 Bolt.new와 v0를 활용한 경우의 난이도를 살펴보겠습니다. 이 방식에서는 코드를 직접 작성하지 않고, 랜딩페이지의 목적과 구성, 원하는 톤을 자연어로 설명하는 것이 출발점이었습니다. 즉, 글쓰기와 기획이 중심이 되는 작업이었고, 이는 문과생에게 상대적으로 익숙한 영역이었습니다. 어떤 사용자를 대상으로 어떤 메시지를 전달하고 싶은지, 섹션별로 어떤 정보가 필요할지 정리하는 과정은 기획 문서를 작성하는 것과 크게 다르지 않았습니다.
Bolt.new에서는 이러한 요구사항을 프롬프트 형태로 입력하면, 자동으로 HTML과 스타일 코드가 생성되었습니다. 저는 코드 내용을 세부적으로 이해하지 않고, 오른쪽 미리보기 화면만 보면서 결과를 판단했습니다. 마음에 들지 않는 부분이 있을 때에는 코드 수정 대신 프롬프트 문장을 조금 더 구체적으로 바꾸는 방식으로 접근했습니다. 예를 들어 “첫 화면에서 헤드라인과 버튼이 동시에 보이도록 해 달라”, “후기 섹션은 카드 형태로 세 개만 배치해 달라”와 같이 요구하면, AI가 이를 반영해 전체 구조를 다시 생성해 주었습니다.
이 과정에서 느낀 난이도는 “문장을 얼마나 구체적으로 쓰느냐”에 달려 있었습니다. 추상적인 지시를 했을 때에는 결과물이 만족스럽지 않았고, 원하는 요소를 명시적으로 나열했을 때에는 훨씬 적은 수정으로도 충분히 사용할 수 있는 페이지가 만들어졌습니다. 즉, 기술적인 용어를 모른다고 해서 작업이 막히지는 않았지만, 머릿속에 있는 그림을 말이나 글로 정확하게 설명하는 능력이 필요했습니다. 이 부분은 문과생에게 상대적 강점이 될 수 있는 영역이기도 했습니다.
v0를 활용한 단계에서는 생성된 컴포넌트를 기반으로 디자인을 다듬고 텍스트를 수정했습니다. 색상과 폰트, 여백 등은 인터페이스 상에서 옵션을 선택하거나 슬라이더를 조정하는 정도로 해결할 수 있었기 때문에, CSS 문법을 새로 배우지 않아도 어느 정도 일관된 디자인을 유지할 수 있었습니다. 특히 버튼 색상을 브랜드 컬러로 맞추고, 섹션 간 간격을 조절해 리듬감을 주는 작업은 시각적인 감각과 사용자 입장을 상상하는 능력이면 충분히 수행할 수 있는 수준이었습니다.
텍스트 카피 수정은 오히려 직접 코딩 방식보다 더 수월했습니다. 코드 파일을 열어 특정 문구를 찾아 수정하는 것이 아니라, 화면에서 해당 텍스트 블록을 바로 선택해 고칠 수 있었기 때문입니다. 헤드라인과 서브 카피, 기능 설명 문장을 하나씩 손보면서 전체 톤을 맞추는 작업은 문서 편집에 가깝게 느껴졌습니다. 자주 쓰는 표현을 정리해 두고 반복적으로 활용하면, 이후 다른 랜딩페이지를 만들 때에도 동일한 패턴을 쉽게 적용할 수 있었습니다.
반응형 확인 측면에서도 난이도는 크게 낮았습니다. v0에서는 미리보기 모드를 통해 모바일·태블릿·데스크톱 화면을 바로 전환해 보면서 요소 배치를 확인할 수 있었습니다. 문제가 보이는 경우에도 “모바일 화면에서는 버튼이 첫 화면에 보이도록 섹션 높이를 조정해 달라”와 같이 문장으로 수정 요청을 전달했습니다. 결국 AI 방식에서 느낀 난이도는 복잡한 문법이나 디버깅 기술보다는, 요구사항을 논리적으로 정리해 전달하는 능력과 결과물을 사용자의 관점에서 평가하는 능력에 더 가깝다고 할 수 있었습니다.
직접 코딩 vs AI 사용, 문과생 입장에서의 비교 정리
두 방식을 직접 경험해 본 후, 문과생 입장에서 난이도를 비교해 보면 몇 가지 차이가 뚜렷하게 드러납니다. 먼저 학습 난이도 측면에서 직접 코딩은 새로운 언어와 개념을 익히는 과정이 필수입니다. 이는 장기적으로는 큰 자산이 될 수 있지만, 단기간에 하나의 랜딩페이지를 만드는 것을 목표로 할 때에는 부담이 상당히 큽니다. 반면 AI 방식은 기존에 가지고 있던 글쓰기와 기획 능력을 활용해 시작할 수 있기 때문에, 초기 진입 장벽이 훨씬 낮았습니다.
작업 시간 측면에서는 AI 방식이 확실히 유리했습니다. 직접 코딩을 할 때에는 레이아웃 하나를 잡는 데에도 여러 차례 시행착오를 겪어야 했고, 브라우저마다 스타일이 다르게 보이는 문제를 해결하는 데 시간을 많이 사용했습니다. 반면 Bolt.new·v0를 활용했을 때에는 전체 뼈대를 만드는 데 몇 분이 채 걸리지 않았고, 남은 시간은 문구와 디테일을 다듬는 데 집중할 수 있었습니다. 특히 일정이 촉박한 프로젝트에서는 이 시간 차이가 의사결정에 중요한 요소로 작용할 수 있습니다.
통제력과 확장성 측면에서는 직접 코딩 방식이 여전히 강점을 가집니다. 코드 구조를 이해하고 있는 경우, 새로운 기능을 추가하거나 외부 서비스와 연동할 때 자유도가 높습니다. 그러나 문과생인 제 입장에서는 그런 확장까지 고려하기 전에, 기본 페이지를 안정적으로 유지하는 것 자체가 큰 과제였습니다. AI 방식에서는 내부 코드 구조를 깊이 이해하지 않아도 되지만, 아주 특수한 동작이나 복잡한 상호작용을 구현해야 할 때에는 한계가 존재할 수 있습니다. 따라서 장기적으로 고도화된 웹서비스를 운영할 계획이라면, 어느 시점에는 개발자와의 협업이 필요합니다.
정신적 피로도와 동기 유지 측면에서도 차이가 있었습니다. 직접 코딩을 할 때에는 작은 에러 하나 때문에 한참을 붙들고 있을 때가 많았고, 그 과정에서 “나는 이 분야와 안 맞는 것 아닐까”라는 생각이 들기도 했습니다. 반면 AI 도구를 사용할 때에는 짧은 시간 안에 눈에 보이는 결과가 나오기 때문에, 작업을 계속 이어 가고 싶은 동기가 더 쉽게 유지되었습니다. 문과생에게는 “작은 성공 경험”이 반복되는 방식이 학습과 실험을 지속하는 데 중요하다는 점을 체감했습니다.
결론: 요약 및 정리
정리하면, 문과생이 랜딩페이지를 만들 때 직접 코딩과 AI 도구 활용은 서로 다른 강점과 약점을 가진 선택지입니다. 직접 코딩은 초기에 학습 부담과 시간이 많이 들지만, 웹 구조에 대한 이해를 쌓고 장기적으로 더 높은 통제력을 확보하는 데 유리합니다. 반면 Bolt.new·v0와 같은 AI 도구를 활용하는 방식은 기존의 글쓰기·기획 능력을 바탕으로 짧은 시간 안에 쓸 수 있는 결과물을 얻는 데 적합하며, 특히 첫 페이지를 빠르게 만들어 보고 싶을 때 현실적인 선택이 됩니다.
이 글에서 살펴본 것처럼 문과생에게 중요한 것은 “코딩을 할 수 있는가”보다 “전달하고 싶은 메시지를 얼마나 명확하게 정의하고 설명할 수 있는가”입니다. AI 도구는 이러한 메시지를 코드와 화면으로 옮기는 역할을 대신할 뿐, 무엇을 보여 줄지 결정하는 부분은 여전히 사람의 몫입니다. 따라서 랜딩페이지가 당장 필요하다면 AI 기반 워크플로우로 빠르게 첫 버전을 만들고, 이후 필요에 따라 직접 코딩이나 개발자와의 협업으로 확장하는 전략을 추천할 수 있습니다. 이렇게 단계적으로 접근하면, 문과생도 과도한 부담 없이 웹 제작 경험을 쌓으면서 자신의 아이디어를 실제 페이지 형태로 구현해 볼 수 있습니다.