특집칼럼 AI 제작 · 클로드 · 아임웹 · 2026.07.29
클로드로 홈페이지 만드는 법
복사해서 쓰는 실제 프롬프트, 아임웹에 붙이는 방법, 직접 해보면 생기는 문제와 해결까지
그루브웹 · 읽는 시간 약 25분
핵심 요약
클로드로 홈페이지를 만드는 건 실제로 됩니다. 원페이지 소개 사이트는 반나절이면 형태가 나오고, 아임웹 같은 빌더 위에 커스텀 코드를 얹는 방식이면 실무 사이트에 필요한 확장까지 됩니다. 이 글에는 복사해서 바로 쓸 수 있는 프롬프트, 아임웹에 코드를 넣는 방법, 직접 해보면 자주 만나는 문제 4가지와 해결법을 넣었습니다. 제작 공정에 클로드를 실제로 쓰고 있는 입장에서, 되는 것과 막히는 지점을 그대로 적었어요. 읽고 직접 만들 수 있겠다 싶으면 직접 만드시면 됩니다.
- 원페이지는 프롬프트 1개 + 수정 몇 번으로 완성, 이 글의 템플릿 복사해서 시작.
- 아임웹 적용 시에는 일반 코드와 다르게 요청해야 함, 조건문 그대로 실어둠.
- 막히는 지점은 정해져 있음: 페이지 이동 후 기능 정지, 모바일 깨짐, 스타일 증발, 검색 미노출.
1. 결론부터, 어디까지 되나
가능 여부부터 답합니다. 행사 안내, 포트폴리오, 회사 소개 원페이지, 코드를 몰라도 만들 수 있습니다. 처음이어도 하루, 익숙해지면 반나절 안에 형태가 나와요. 아임웹 위에 커스텀 섹션·위젯을 얹는 것, 됩니다. 다만 일반 웹과 다른 요청 조건이 있고, 이 글 4장에 그 조건을 그대로 적어뒀습니다. 쇼핑몰·회원·예약이 있는 사이트 전체를 코드로 짓는 것, 클로드는 할 수 있지만, 결과물을 읽고 배포하고 책임질 개발 지식이 필요한 영역이라 이 글의 범위 밖입니다. 그 경우는 기능을 빌더에 맡기고 코드는 확장에만 쓰는 조합이 비개발자의 현실적인 선택지예요.
[그림 1] 클로드로 홈페이지를 만드는 세 가지 경로
하나만 미리 말해두면, 그루브웹도 제작 공정에 클로드를 씁니다. 그래서 이 글은 "AI는 위험하니 전문가에게 맡기라"는 글이 아니에요. 직접 할 수 있는 부분은 따라 할 수 있게 적었고, 막히는 지점은 왜 막히는지와 함께 적었습니다. 그 막히는 지점이 남으면 그때 업체를 찾으시면 됩니다.
2. 가장 쉬운 방법, 원페이지 만들기
순서는 다섯 개입니다. claude.ai 접속 → 프롬프트 입력 → 미리보기 확인 → 말로 수정 → 파일 저장. 클로드는 코드를 짜면 화면 오른쪽에 결과물을 바로 렌더링해서 보여주기 때문에(아티팩트), 코드를 한 줄도 안 읽고 결과만 보면서 진행할 수 있습니다.
시작 전에 메모장에 다섯 가지만 적으세요. 업종과 회사명, 페이지의 목적(문의 받기인지 소개인지), 넣을 섹션 목록, 실제 문구(첫 화면 한 줄, 연락처, 실적 숫자), 메인 색상. 이게 프롬프트의 재료입니다. 재료 없이 시작하면 클로드는 학습한 수많은 사이트의 평균적인 모습을 내놓고, 그 결과물은 어디서 본 듯한 페이지가 됩니다. 아래는 실제로 쓸 수 있는 형태의 비교예요.
이렇게 쓰면 평균적인 결과물이 나옵니다
"우리 회사 홈페이지 멋지고 고급스럽게 만들어줘"
복사해서 빈칸만 바꿔 쓰세요
"[업종] 회사 '[회사명]'의 소개용 원페이지 사이트를 HTML 한 파일로 만들어줘.
섹션 순서: 첫 화면 → 서비스 소개 3개 → 실적 숫자 → 진행 절차 → 문의.
첫 화면 문구는 '[실제 문구 그대로]'.
실적 숫자는 [누적 1,200건 / 업력 15년 / 평균 회신 4시간]처럼 내가 준 값만 사용하고 지어내지 마.
메인 색상 [#1a3c6e], 배경은 흰색, 글꼴은 Pretendard.
문의 버튼은 [전화번호] 전화 연결.
모바일에서 확인할 거니까 화면 폭이 좁아져도 깨지지 않게.
페이지 title과 meta description, 이미지 alt까지 넣어줘."
차이는 형용사와 값입니다. '고급스럽게'는 사람마다 다르게 해석되지만 색상 코드와 섹션 목록은 오해가 없어요. 특히 "내가 준 값만 사용하고 지어내지 마"는 꼭 넣으세요. 이 문장이 없으면 클로드가 그럴듯한 가짜 실적 숫자나 없는 서비스명을 채워 넣는 경우가 있고, 그걸 못 보고 그대로 올리는 사고가 실제로 납니다.
3. 수정하는 법, 실제 수정 요청 문장들
첫 결과물은 초안입니다. 여기서부터 품질이 결정되는데, 수정 요청에 요령이 있어요. 한 번에 한 가지, 위치를 지목해서. "전체적으로 더 세련되게"라고 하면 마음에 들던 부분까지 바뀝니다. 실제로 쓰는 수정 문장들을 그대로 옮깁니다.
· "첫 화면 제목을 두 줄로 나누고 크기를 1.3배 키워줘"
· "실적 숫자 섹션을 서비스 소개 위로 올려줘"
· "서비스 카드 3개의 높이를 통일해줘"
· "문의 버튼을 화면 스크롤해도 우하단에 고정으로 띄워줘"
· "전체 여백을 지금의 80% 수준으로 줄여서 밀도를 높여줘"
· "모바일에서 봤더니 진행 절차 4개가 세로로 너무 길어. 2×2로 바꿔줘"
두 가지 습관을 붙이세요. 하나, 마음에 든 버전이 나오면 코드를 복사해 메모장에 저장. 대화가 20~30번 오가면 "아까 그 버전으로 돌려줘"가 정확히 안 될 때가 있습니다. 저장해 둔 코드를 다시 붙여 넣으면 그 시점부터 재개할 수 있어요. 둘, 완성 후 검증은 미리보기가 아니라 실물로. 파일을 저장해서 크롬으로 열고, 본인 폰으로도 열어보세요. 미리보기 창과 실제 브라우저는 폭이 달라서, 미리보기에서 멀쩡하던 버튼이 실제 모바일에서 두 줄로 떨어지는 일이 흔합니다. 전화 버튼은 실제로 눌러서 발신까지 확인하고요.
4. 아임웹에 넣는 법, 조건이 다릅니다
이미 아임웹으로 운영 중인 사이트에 커스텀 섹션을 추가하고 싶은 경우입니다. 방법 자체는 간단해요. 사이트 편집 화면에서 코드 위젯(HTML 삽입)을 원하는 위치에 추가하고, 클로드에게 받은 코드를 붙여 넣으면 됩니다. FAQ 아코디언, 실적 카운터, 절차 안내 섹션, 견적 계산기 같은 것들이 이 방식으로 들어갑니다.
문제는 일반 HTML 파일용으로 받은 코드를 그대로 붙이면 어긋나는 경우가 있다는 겁니다. 아임웹은 완전한 HTML 문서가 아니라 페이지의 일부로 코드를 받기 때문에, 문서 전체 구조(DOCTYPE, html, head, body)는 빼야 합니다. 그리고 넣는 위치에 따라 조건이 달라요. 코드 위젯 자체는 HTML·CSS·자바스크립트를 지원해서 style 태그도 쓸 수 있습니다. 다만 게시판 글이나 일부 에디터 영역에 붙이는 코드는 저장 과정에서 style 태그가 제거될 수 있어요. 어느 위치에 넣어도 안전하게 가려면 인라인 방식이 무난하고, 기존 사이트의 전역 스타일과 간섭할 가능성도 줄어듭니다. 그래서 요청할 때 아래 조건을 프롬프트 끝에 붙이면 됩니다.
아임웹용 요청 조건, 프롬프트 끝에 그대로 추가
"이 코드는 아임웹의 코드 위젯에 넣을 거야. 조건:
· DOCTYPE, html, head, body 없이 div부터 시작
· 게시판 등 style 태그가 제거될 수 있는 영역에도 쓸 수 있게, 스타일은 인라인(style="") 위주로
· 클래스 이름 앞에 'gw-' 같은 고유 접두어를 붙여서 기존 사이트 스타일과 충돌하지 않게
· 폭은 고정 px 말고 max-width + 100%로, 모바일에서 넘치지 않게
· 자바스크립트가 있다면 페이지가 다시 그려져도 다시 작동하도록 작성"
마지막 조건이 낯설 텐데, 5장에서 실제 현상으로 설명합니다. 붙여 넣은 뒤에는 편집 화면 미리보기 말고 실제 게시된 페이지를 PC와 폰에서 각각 열어 확인하세요. 편집 화면에서는 정상인데 게시 화면에서 어긋나는 경우가 있습니다.
5. 직접 해보면 생기는 문제 4가지와 해결
여기가 이 글에서 가장 값어치 있는 부분일 겁니다. 클로드가 짜준 코드는 대부분 문법적으로 맞습니다. 그런데 맞는 코드가 실제 환경에서 안 돌아가는 경우가 있고, 그 유형이 정해져 있어요.
[그림 2] 자주 만나는 문제 4가지, 현상과 해결
문제 1. 처음엔 작동하는데, 다른 메뉴 갔다 오면 죽는다
아코디언이나 탭처럼 클릭에 반응하는 위젯에서 생깁니다. 페이지를 처음 열면 잘 되는데, 다른 메뉴로 이동했다가 돌아오면 클릭해도 반응이 없어요. 아임웹이 페이지를 이동할 때 화면 일부를 새로 그리는데, 처음 한 번 실행됐던 스크립트가 새로 그려진 화면에는 연결되어 있지 않아서 생기는 현상입니다. 해결은 코드를 고치는 게 아니라 요청을 바꾸는 거예요. 클로드에게 이렇게 말하면 됩니다: "아임웹에서 페이지 이동 후 돌아오면 클릭이 안 먹혀. 화면이 다시 그려져도 이벤트가 다시 연결되도록, 문서 전체에서 클릭을 위임받는 방식으로 바꿔줘." 이 한 문장으로 해결되는 경우가 많습니다.
문제 2. PC에서는 멀쩡한데 폰에서 깨진다
가장 흔한 유형입니다. 구체적으로는 이런 식이에요. 버튼 두 개가 나란히 있다가 폰에서 한 글자씩 두 줄로 찌그러지거나, 가로로 배치한 카드들이 화면 밖으로 넘쳐서 좌우 스크롤이 생기거나, 표가 잘려 나갑니다. 코드가 고정 폭(px)으로 짜였거나 좁은 화면 대응이 빠졌기 때문인데, 원인 분석은 필요 없고 현상을 그대로 전달하면 됩니다: "아이폰에서 보니 서비스 카드 3개가 화면 밖으로 넘쳐서 옆으로 스크롤이 생겨. 화면이 좁으면 카드를 세로로 쌓이게 바꿔줘." 폰 화면을 캡처해서 이미지로 붙여주면 더 정확하게 고쳐줍니다. 클로드는 스크린샷을 읽을 수 있어요.
문제 3. 붙여 넣고 저장했더니 디자인이 다 풀려 있다
아임웹 특유의 현상입니다. 분명 색과 간격이 잡힌 코드를 붙였는데, 저장 후 보니 스타일이 벗겨진 맨 HTML만 남아 있어요. 게시판·일부 입력 영역이 저장 과정에서 style 태그를 제거하기 때문입니다. 4장의 요청 조건에서 '인라인 스타일로'를 넣으라고 한 이유가 이거예요. 이미 받은 코드가 style 태그 방식이라면 이렇게 요청하세요: "style 태그가 제거되는 환경이야. 지금 코드의 모든 스타일을 각 요소의 인라인 style 속성으로 옮겨줘. 기능은 그대로." 참고로 hover 효과처럼 인라인으로 표현이 안 되는 것도 있는데, 그건 포기하거나 자바스크립트 방식으로 우회해야 합니다. 이런 트레이드오프가 있다는 것까지 알고 결정하면 됩니다.
문제 4. 만들었는데 검색에 안 나온다
이건 코드 문제가 아니라 오픈 이후의 문제인데, 직접 만든 분들이 가장 늦게 발견합니다. 사이트를 올리고 몇 주가 지나도 회사명 검색에 안 나와요. 우선 확인할 것은 검색엔진 등록(구글 서치콘솔, 네이버 서치어드바이저) 여부입니다. 직접 만든 사이트에서 가장 흔하게 빠지는 절차이고, 등록을 했더라도 신규 사이트는 검색 반영까지 수 주가 걸릴 수 있어요. 만드는 것과 찾아지게 하는 것은 별개의 작업입니다. 오픈 직후 두 곳에 사이트를 등록하고, 클로드에게 "이 사이트의 title, meta description, 이미지 alt가 제대로 들어갔는지 점검하고 빠진 걸 채워줘"를 마지막으로 한 번 돌리세요. 등록 절차 자체도 "서치콘솔 등록 방법 단계별로 알려줘"라고 물으면 안내받을 수 있습니다.
6. 업체가 개입하는 지점은 어디인가
오해 없이 적습니다. 클로드는 코드 작성만 하는 도구가 아니에요. 사이트 구조 제안, 카피 초안, 경쟁사 비교, SEO 구조 설계까지 시키면 다 합니다. 그래서 "AI는 실행만 하고 생각은 사람이 한다"는 구분은 정확하지 않습니다. 실제 프로젝트에서 갈리는 지점은 다른 데 있어요.
하나는 재료와 선택입니다. 클로드가 좋은 구조안을 내려면 이 회사의 고객이 누구인지, 문의가 어떤 경로로 오는지, 경쟁사 대비 뭘 앞세울지 같은 사업 맥락이 입력되어야 하고, 여러 안 중 뭘 고를지는 결과를 책임질 사람이 정해야 합니다. 그루브웹 공정에서 이 부분은 클라이언트 미팅과 기획 단계에서 사람이 만들고, 그 산출물이 클로드에게 주는 지시문의 재료가 됩니다. 다른 하나는 실환경 검증입니다. 5장의 문제 4가지가 바로 그 실환경이에요. 내부 작업에서는 코드를 요청할 때부터 조건을 미리 넣습니다. 클래스에 고유 접두어를 붙여 기존 위젯 스타일과 충돌하지 않게 하고, 화면이 다시 그려지는 영역의 스크립트는 실행 시점을 따로 확인하고, PC 화면만 보고 확정하지 않고 실기기에서 확인한 뒤 반영합니다. 5장에서 여러분이 문제를 만난 뒤에 해결하는 그 과정을, 만나기 전에 처리하는 것이 차이의 전부입니다.
7. 직접 제작 / 의뢰 판단 기준
직접 만드는 게 맞는 경우: 페이지 하나로 목적이 끝난다(행사·포트폴리오·간단 소개). 수정에 쓸 시간을 직접 낼 수 있다. 실패해도 손해가 크지 않다. 만들면서 배우는 것 자체가 목적의 일부다. 이 조건이면 2장의 프롬프트로 바로 시작하세요.
의뢰가 맞는 경우: 광고비가 실제로 들어가는 사이트다. 문의 전환이 매출에 직결된다. 페이지와 콘텐츠가 많다. 쇼핑몰·회원·외부 시스템 연동이 있다. 담당자가 이 일에만 시간을 쓸 수 없다. 이 조건에서는 5장의 문제들이 페이지 수만큼 곱해져서 돌아오고, 그걸 처리하는 시간이 제작비보다 비싸집니다.
업체를 알아보게 되면 질문 하나를 추가하세요. "AI를 어떤 공정에 쓰고, 사람은 어디서 확인하나요?" 구체적인 답이 나오는 곳과 얼버무리는 곳으로 갈립니다. 그루브웹의 답은 6장에 적은 그대로이고, 직접 만들다가 막힌 상태로 상담 오셔도 됩니다.
자주 묻는 질문
Q. 클로드와 ChatGPT 중 뭐가 더 나은가요?
이 글의 방법은 둘 다에서 통하고, 성능은 버전에 따라 엎치락뒤치락합니다. 코드 작업에 클로드를 주로 쓰는 이유는 긴 코드를 안정적으로 다루고, 결과물을 대화 안에서 바로 렌더링해 보여주는 작업 흐름이 수정 반복에 잘 맞아서예요. 도구 선택보다 지시문에 담기는 재료의 구체성이 결과물을 훨씬 크게 가릅니다. 도구를 비교할 시간에 2장의 메모 다섯 줄을 채우세요.
Q. 비용은 얼마나 드나요?
클로드 이용료는 무료 플랜으로도 시작할 수 있고 유료 플랜이 월 2~3만원대입니다. 별도로 도메인 등록비(연 1~5만원)와, 파일을 직접 올리는 경우 호스팅비(월 몇천원~)가 들어요. 아임웹에 얹는 방식이면 기존 요금제 그대로입니다. 진짜 비용은 이용료가 아니라 시간입니다. 처음이면 만들고 고치고 검증하는 데 며칠 분량의 시간이 들어가고, 그 시간을 낼 수 있는지가 7장 판단 기준의 사실상 첫 번째 항목이에요.
Q. AI로 만든 사이트는 검색에 불리한가요?
'AI로 만들었다'는 사실은 검색엔진 평가 항목이 아닙니다. 문제는 AI 제작 사이트들이 title·메타·alt·검색엔진 등록 같은 기본 작업이 빠진 채 오픈되는 경우가 많다는 것뿐이에요. 요청하지 않으면 안 들어가는 항목들이라서요. 2장의 프롬프트에 이 항목들을 포함해 뒀고, 5장의 문제 4가 등록 절차를 다룹니다. 그 이후의 검색 순위는 만든 방식이 아니라 콘텐츠와 운영에서 갈립니다.
Q. 코드를 전혀 몰라도 정말 가능한가요?
원페이지(2~3장)는 가능합니다. 코드를 읽지 않고 결과만 보면서 말로 수정하는 흐름이 실제로 작동해요. 벽은 두 군데서 만납니다. 완성 파일을 실제 주소로 여는 배포 단계, 그리고 5장 같은 문제가 생겼을 때요. 둘 다 클로드에게 물어가며 넘을 수 있지만 시간이 듭니다. 그 시행착오가 부담이면 아임웹 방식(4장)이 현실적입니다. 배포·호스팅·보안을 빌더가 대신하니 코드 위젯 안의 문제만 다루면 되거든요.
Q. AI가 결국 제작 업체를 대체하지 않을까요?
코드 작성만 팔던 업체는 대체될 거라고 봅니다. 남는 일은 사업 맥락을 읽는 것, 여러 안 중에 선택하는 것, 실제 환경에서 검증하는 것, 그리고 결과를 책임지는 것입니다. 그루브웹이 클로드를 공정에 가장 적극적으로 넣으면서 확인하고 있는 것도 이 일들의 값어치예요. 도구가 좋아질수록 결과물의 하한선은 올라가고, 상한선은 도구를 다루는 공정에서 갈립니다.
만들다 막힌 지점부터 상담받기 →
태그
클로드 AI홈페이지제작 아임웹 커스텀코드 프롬프트 특집칼럼
특집칼럼 AI 제작 · 클로드 · 아임웹 · 2026.07.29
클로드로 홈페이지 만드는 법
복사해서 쓰는 실제 프롬프트, 아임웹에 붙이는 방법, 직접 해보면 생기는 문제와 해결까지
그루브웹 · 읽는 시간 약 25분
핵심 요약
클로드로 홈페이지를 만드는 건 실제로 됩니다. 원페이지 소개 사이트는 반나절이면 형태가 나오고, 아임웹 같은 빌더 위에 커스텀 코드를 얹는 방식이면 실무 사이트에 필요한 확장까지 됩니다. 이 글에는 복사해서 바로 쓸 수 있는 프롬프트, 아임웹에 코드를 넣는 방법, 직접 해보면 자주 만나는 문제 4가지와 해결법을 넣었습니다. 제작 공정에 클로드를 실제로 쓰고 있는 입장에서, 되는 것과 막히는 지점을 그대로 적었어요. 읽고 직접 만들 수 있겠다 싶으면 직접 만드시면 됩니다.
목차
1. 결론부터, 어디까지 되나
가능 여부부터 답합니다. 행사 안내, 포트폴리오, 회사 소개 원페이지, 코드를 몰라도 만들 수 있습니다. 처음이어도 하루, 익숙해지면 반나절 안에 형태가 나와요. 아임웹 위에 커스텀 섹션·위젯을 얹는 것, 됩니다. 다만 일반 웹과 다른 요청 조건이 있고, 이 글 4장에 그 조건을 그대로 적어뒀습니다. 쇼핑몰·회원·예약이 있는 사이트 전체를 코드로 짓는 것, 클로드는 할 수 있지만, 결과물을 읽고 배포하고 책임질 개발 지식이 필요한 영역이라 이 글의 범위 밖입니다. 그 경우는 기능을 빌더에 맡기고 코드는 확장에만 쓰는 조합이 비개발자의 현실적인 선택지예요.
[그림 1] 클로드로 홈페이지를 만드는 세 가지 경로
하나만 미리 말해두면, 그루브웹도 제작 공정에 클로드를 씁니다. 그래서 이 글은 "AI는 위험하니 전문가에게 맡기라"는 글이 아니에요. 직접 할 수 있는 부분은 따라 할 수 있게 적었고, 막히는 지점은 왜 막히는지와 함께 적었습니다. 그 막히는 지점이 남으면 그때 업체를 찾으시면 됩니다.
2. 가장 쉬운 방법, 원페이지 만들기
순서는 다섯 개입니다. claude.ai 접속 → 프롬프트 입력 → 미리보기 확인 → 말로 수정 → 파일 저장. 클로드는 코드를 짜면 화면 오른쪽에 결과물을 바로 렌더링해서 보여주기 때문에(아티팩트), 코드를 한 줄도 안 읽고 결과만 보면서 진행할 수 있습니다.
시작 전에 메모장에 다섯 가지만 적으세요. 업종과 회사명, 페이지의 목적(문의 받기인지 소개인지), 넣을 섹션 목록, 실제 문구(첫 화면 한 줄, 연락처, 실적 숫자), 메인 색상. 이게 프롬프트의 재료입니다. 재료 없이 시작하면 클로드는 학습한 수많은 사이트의 평균적인 모습을 내놓고, 그 결과물은 어디서 본 듯한 페이지가 됩니다. 아래는 실제로 쓸 수 있는 형태의 비교예요.
이렇게 쓰면 평균적인 결과물이 나옵니다
"우리 회사 홈페이지 멋지고 고급스럽게 만들어줘"
복사해서 빈칸만 바꿔 쓰세요
"[업종] 회사 '[회사명]'의 소개용 원페이지 사이트를 HTML 한 파일로 만들어줘.
섹션 순서: 첫 화면 → 서비스 소개 3개 → 실적 숫자 → 진행 절차 → 문의.
첫 화면 문구는 '[실제 문구 그대로]'.
실적 숫자는 [누적 1,200건 / 업력 15년 / 평균 회신 4시간]처럼 내가 준 값만 사용하고 지어내지 마.
메인 색상 [#1a3c6e], 배경은 흰색, 글꼴은 Pretendard.
문의 버튼은 [전화번호] 전화 연결.
모바일에서 확인할 거니까 화면 폭이 좁아져도 깨지지 않게.
페이지 title과 meta description, 이미지 alt까지 넣어줘."
차이는 형용사와 값입니다. '고급스럽게'는 사람마다 다르게 해석되지만 색상 코드와 섹션 목록은 오해가 없어요. 특히 "내가 준 값만 사용하고 지어내지 마"는 꼭 넣으세요. 이 문장이 없으면 클로드가 그럴듯한 가짜 실적 숫자나 없는 서비스명을 채워 넣는 경우가 있고, 그걸 못 보고 그대로 올리는 사고가 실제로 납니다.
3. 수정하는 법, 실제 수정 요청 문장들
첫 결과물은 초안입니다. 여기서부터 품질이 결정되는데, 수정 요청에 요령이 있어요. 한 번에 한 가지, 위치를 지목해서. "전체적으로 더 세련되게"라고 하면 마음에 들던 부분까지 바뀝니다. 실제로 쓰는 수정 문장들을 그대로 옮깁니다.
· "첫 화면 제목을 두 줄로 나누고 크기를 1.3배 키워줘"
· "실적 숫자 섹션을 서비스 소개 위로 올려줘"
· "서비스 카드 3개의 높이를 통일해줘"
· "문의 버튼을 화면 스크롤해도 우하단에 고정으로 띄워줘"
· "전체 여백을 지금의 80% 수준으로 줄여서 밀도를 높여줘"
· "모바일에서 봤더니 진행 절차 4개가 세로로 너무 길어. 2×2로 바꿔줘"
두 가지 습관을 붙이세요. 하나, 마음에 든 버전이 나오면 코드를 복사해 메모장에 저장. 대화가 20~30번 오가면 "아까 그 버전으로 돌려줘"가 정확히 안 될 때가 있습니다. 저장해 둔 코드를 다시 붙여 넣으면 그 시점부터 재개할 수 있어요. 둘, 완성 후 검증은 미리보기가 아니라 실물로. 파일을 저장해서 크롬으로 열고, 본인 폰으로도 열어보세요. 미리보기 창과 실제 브라우저는 폭이 달라서, 미리보기에서 멀쩡하던 버튼이 실제 모바일에서 두 줄로 떨어지는 일이 흔합니다. 전화 버튼은 실제로 눌러서 발신까지 확인하고요.
4. 아임웹에 넣는 법, 조건이 다릅니다
이미 아임웹으로 운영 중인 사이트에 커스텀 섹션을 추가하고 싶은 경우입니다. 방법 자체는 간단해요. 사이트 편집 화면에서 코드 위젯(HTML 삽입)을 원하는 위치에 추가하고, 클로드에게 받은 코드를 붙여 넣으면 됩니다. FAQ 아코디언, 실적 카운터, 절차 안내 섹션, 견적 계산기 같은 것들이 이 방식으로 들어갑니다.
문제는 일반 HTML 파일용으로 받은 코드를 그대로 붙이면 어긋나는 경우가 있다는 겁니다. 아임웹은 완전한 HTML 문서가 아니라 페이지의 일부로 코드를 받기 때문에, 문서 전체 구조(DOCTYPE, html, head, body)는 빼야 합니다. 그리고 넣는 위치에 따라 조건이 달라요. 코드 위젯 자체는 HTML·CSS·자바스크립트를 지원해서 style 태그도 쓸 수 있습니다. 다만 게시판 글이나 일부 에디터 영역에 붙이는 코드는 저장 과정에서 style 태그가 제거될 수 있어요. 어느 위치에 넣어도 안전하게 가려면 인라인 방식이 무난하고, 기존 사이트의 전역 스타일과 간섭할 가능성도 줄어듭니다. 그래서 요청할 때 아래 조건을 프롬프트 끝에 붙이면 됩니다.
아임웹용 요청 조건, 프롬프트 끝에 그대로 추가
"이 코드는 아임웹의 코드 위젯에 넣을 거야. 조건:
· DOCTYPE, html, head, body 없이 div부터 시작
· 게시판 등 style 태그가 제거될 수 있는 영역에도 쓸 수 있게, 스타일은 인라인(style="") 위주로
· 클래스 이름 앞에 'gw-' 같은 고유 접두어를 붙여서 기존 사이트 스타일과 충돌하지 않게
· 폭은 고정 px 말고 max-width + 100%로, 모바일에서 넘치지 않게
· 자바스크립트가 있다면 페이지가 다시 그려져도 다시 작동하도록 작성"
마지막 조건이 낯설 텐데, 5장에서 실제 현상으로 설명합니다. 붙여 넣은 뒤에는 편집 화면 미리보기 말고 실제 게시된 페이지를 PC와 폰에서 각각 열어 확인하세요. 편집 화면에서는 정상인데 게시 화면에서 어긋나는 경우가 있습니다.
5. 직접 해보면 생기는 문제 4가지와 해결
여기가 이 글에서 가장 값어치 있는 부분일 겁니다. 클로드가 짜준 코드는 대부분 문법적으로 맞습니다. 그런데 맞는 코드가 실제 환경에서 안 돌아가는 경우가 있고, 그 유형이 정해져 있어요.
[그림 2] 자주 만나는 문제 4가지, 현상과 해결
아코디언이나 탭처럼 클릭에 반응하는 위젯에서 생깁니다. 페이지를 처음 열면 잘 되는데, 다른 메뉴로 이동했다가 돌아오면 클릭해도 반응이 없어요. 아임웹이 페이지를 이동할 때 화면 일부를 새로 그리는데, 처음 한 번 실행됐던 스크립트가 새로 그려진 화면에는 연결되어 있지 않아서 생기는 현상입니다. 해결은 코드를 고치는 게 아니라 요청을 바꾸는 거예요. 클로드에게 이렇게 말하면 됩니다: "아임웹에서 페이지 이동 후 돌아오면 클릭이 안 먹혀. 화면이 다시 그려져도 이벤트가 다시 연결되도록, 문서 전체에서 클릭을 위임받는 방식으로 바꿔줘." 이 한 문장으로 해결되는 경우가 많습니다.
가장 흔한 유형입니다. 구체적으로는 이런 식이에요. 버튼 두 개가 나란히 있다가 폰에서 한 글자씩 두 줄로 찌그러지거나, 가로로 배치한 카드들이 화면 밖으로 넘쳐서 좌우 스크롤이 생기거나, 표가 잘려 나갑니다. 코드가 고정 폭(px)으로 짜였거나 좁은 화면 대응이 빠졌기 때문인데, 원인 분석은 필요 없고 현상을 그대로 전달하면 됩니다: "아이폰에서 보니 서비스 카드 3개가 화면 밖으로 넘쳐서 옆으로 스크롤이 생겨. 화면이 좁으면 카드를 세로로 쌓이게 바꿔줘." 폰 화면을 캡처해서 이미지로 붙여주면 더 정확하게 고쳐줍니다. 클로드는 스크린샷을 읽을 수 있어요.
아임웹 특유의 현상입니다. 분명 색과 간격이 잡힌 코드를 붙였는데, 저장 후 보니 스타일이 벗겨진 맨 HTML만 남아 있어요. 게시판·일부 입력 영역이 저장 과정에서 style 태그를 제거하기 때문입니다. 4장의 요청 조건에서 '인라인 스타일로'를 넣으라고 한 이유가 이거예요. 이미 받은 코드가 style 태그 방식이라면 이렇게 요청하세요: "style 태그가 제거되는 환경이야. 지금 코드의 모든 스타일을 각 요소의 인라인 style 속성으로 옮겨줘. 기능은 그대로." 참고로 hover 효과처럼 인라인으로 표현이 안 되는 것도 있는데, 그건 포기하거나 자바스크립트 방식으로 우회해야 합니다. 이런 트레이드오프가 있다는 것까지 알고 결정하면 됩니다.
이건 코드 문제가 아니라 오픈 이후의 문제인데, 직접 만든 분들이 가장 늦게 발견합니다. 사이트를 올리고 몇 주가 지나도 회사명 검색에 안 나와요. 우선 확인할 것은 검색엔진 등록(구글 서치콘솔, 네이버 서치어드바이저) 여부입니다. 직접 만든 사이트에서 가장 흔하게 빠지는 절차이고, 등록을 했더라도 신규 사이트는 검색 반영까지 수 주가 걸릴 수 있어요. 만드는 것과 찾아지게 하는 것은 별개의 작업입니다. 오픈 직후 두 곳에 사이트를 등록하고, 클로드에게 "이 사이트의 title, meta description, 이미지 alt가 제대로 들어갔는지 점검하고 빠진 걸 채워줘"를 마지막으로 한 번 돌리세요. 등록 절차 자체도 "서치콘솔 등록 방법 단계별로 알려줘"라고 물으면 안내받을 수 있습니다.
6. 업체가 개입하는 지점은 어디인가
오해 없이 적습니다. 클로드는 코드 작성만 하는 도구가 아니에요. 사이트 구조 제안, 카피 초안, 경쟁사 비교, SEO 구조 설계까지 시키면 다 합니다. 그래서 "AI는 실행만 하고 생각은 사람이 한다"는 구분은 정확하지 않습니다. 실제 프로젝트에서 갈리는 지점은 다른 데 있어요.
하나는 재료와 선택입니다. 클로드가 좋은 구조안을 내려면 이 회사의 고객이 누구인지, 문의가 어떤 경로로 오는지, 경쟁사 대비 뭘 앞세울지 같은 사업 맥락이 입력되어야 하고, 여러 안 중 뭘 고를지는 결과를 책임질 사람이 정해야 합니다. 그루브웹 공정에서 이 부분은 클라이언트 미팅과 기획 단계에서 사람이 만들고, 그 산출물이 클로드에게 주는 지시문의 재료가 됩니다. 다른 하나는 실환경 검증입니다. 5장의 문제 4가지가 바로 그 실환경이에요. 내부 작업에서는 코드를 요청할 때부터 조건을 미리 넣습니다. 클래스에 고유 접두어를 붙여 기존 위젯 스타일과 충돌하지 않게 하고, 화면이 다시 그려지는 영역의 스크립트는 실행 시점을 따로 확인하고, PC 화면만 보고 확정하지 않고 실기기에서 확인한 뒤 반영합니다. 5장에서 여러분이 문제를 만난 뒤에 해결하는 그 과정을, 만나기 전에 처리하는 것이 차이의 전부입니다.
[그림 3] 실무 공정에서의 역할 분담
7. 직접 제작 / 의뢰 판단 기준
직접 만드는 게 맞는 경우: 페이지 하나로 목적이 끝난다(행사·포트폴리오·간단 소개). 수정에 쓸 시간을 직접 낼 수 있다. 실패해도 손해가 크지 않다. 만들면서 배우는 것 자체가 목적의 일부다. 이 조건이면 2장의 프롬프트로 바로 시작하세요.
의뢰가 맞는 경우: 광고비가 실제로 들어가는 사이트다. 문의 전환이 매출에 직결된다. 페이지와 콘텐츠가 많다. 쇼핑몰·회원·외부 시스템 연동이 있다. 담당자가 이 일에만 시간을 쓸 수 없다. 이 조건에서는 5장의 문제들이 페이지 수만큼 곱해져서 돌아오고, 그걸 처리하는 시간이 제작비보다 비싸집니다.
업체를 알아보게 되면 질문 하나를 추가하세요. "AI를 어떤 공정에 쓰고, 사람은 어디서 확인하나요?" 구체적인 답이 나오는 곳과 얼버무리는 곳으로 갈립니다. 그루브웹의 답은 6장에 적은 그대로이고, 직접 만들다가 막힌 상태로 상담 오셔도 됩니다.
자주 묻는 질문
이 글의 방법은 둘 다에서 통하고, 성능은 버전에 따라 엎치락뒤치락합니다. 코드 작업에 클로드를 주로 쓰는 이유는 긴 코드를 안정적으로 다루고, 결과물을 대화 안에서 바로 렌더링해 보여주는 작업 흐름이 수정 반복에 잘 맞아서예요. 도구 선택보다 지시문에 담기는 재료의 구체성이 결과물을 훨씬 크게 가릅니다. 도구를 비교할 시간에 2장의 메모 다섯 줄을 채우세요.
클로드 이용료는 무료 플랜으로도 시작할 수 있고 유료 플랜이 월 2~3만원대입니다. 별도로 도메인 등록비(연 1~5만원)와, 파일을 직접 올리는 경우 호스팅비(월 몇천원~)가 들어요. 아임웹에 얹는 방식이면 기존 요금제 그대로입니다. 진짜 비용은 이용료가 아니라 시간입니다. 처음이면 만들고 고치고 검증하는 데 며칠 분량의 시간이 들어가고, 그 시간을 낼 수 있는지가 7장 판단 기준의 사실상 첫 번째 항목이에요.
'AI로 만들었다'는 사실은 검색엔진 평가 항목이 아닙니다. 문제는 AI 제작 사이트들이 title·메타·alt·검색엔진 등록 같은 기본 작업이 빠진 채 오픈되는 경우가 많다는 것뿐이에요. 요청하지 않으면 안 들어가는 항목들이라서요. 2장의 프롬프트에 이 항목들을 포함해 뒀고, 5장의 문제 4가 등록 절차를 다룹니다. 그 이후의 검색 순위는 만든 방식이 아니라 콘텐츠와 운영에서 갈립니다.
원페이지(2~3장)는 가능합니다. 코드를 읽지 않고 결과만 보면서 말로 수정하는 흐름이 실제로 작동해요. 벽은 두 군데서 만납니다. 완성 파일을 실제 주소로 여는 배포 단계, 그리고 5장 같은 문제가 생겼을 때요. 둘 다 클로드에게 물어가며 넘을 수 있지만 시간이 듭니다. 그 시행착오가 부담이면 아임웹 방식(4장)이 현실적입니다. 배포·호스팅·보안을 빌더가 대신하니 코드 위젯 안의 문제만 다루면 되거든요.
코드 작성만 팔던 업체는 대체될 거라고 봅니다. 남는 일은 사업 맥락을 읽는 것, 여러 안 중에 선택하는 것, 실제 환경에서 검증하는 것, 그리고 결과를 책임지는 것입니다. 그루브웹이 클로드를 공정에 가장 적극적으로 넣으면서 확인하고 있는 것도 이 일들의 값어치예요. 도구가 좋아질수록 결과물의 하한선은 올라가고, 상한선은 도구를 다루는 공정에서 갈립니다.
만들다 막힌 지점부터 상담받기 →
태그
클로드 AI홈페이지제작 아임웹 커스텀코드 프롬프트 특집칼럼