지금까지 안티그라비티(Antigravity)의 개념과 기본 환경 설정을 다뤘다면, 이번 편에서는 그것을 실제로 손에 익히는 시간이다. 첫 실습 대상은 ‘개인 소개 웹페이지’다. 화려한 기능이 필요 없고, 완성 형태를 누구나 머릿속에 그릴 수 있으며, 그러면서도 기획-요청-검토-수정이라는 바이브 코딩의 전체 루프를 한 번씩 다 거칠 수 있는 딱 좋은 크기의 과제이기 때문이다.
이 편의 목표는 예쁜 페이지 하나를 얻는 것이 아니다. AI 개발 파트너에게 무엇을, 어떤 순서로, 얼마나 구체적으로 요청해야 원하는 결과에 가까워지는지를 몸으로 익히는 것이다. 워크스페이스를 만들고, 첫 프롬프트로 뼈대를 요청하고, 그 결과물을 보며 다음 지시를 내리는 흐름을 그대로 따라가 보자. 이 흐름은 이후 어떤 규모의 프로젝트를 하게 되더라도 그대로 반복된다. 그래서 첫 실습에서 이 순서 자체를 몸에 익혀두는 것이 개별 결과물보다 더 중요하다.
참고로 아래 실습은 실제 배포 가능한 정적 웹페이지 하나를 완성하는 것을 전제로 한다. 특정 프레임워크 지식이 없어도 상관없다. 코드를 직접 짜는 대신, AI 파트너가 짠 코드를 읽고 판단하고 다음 지시를 내리는 역할에 집중하면 된다. 다만 코드를 전혀 읽지 않고 결과만 보고 판단하는 것은 권하지 않는다. 최소한 어떤 태그가 어떤 섹션을 담당하는지 정도는 눈으로 훑어보는 습관을 들이는 편이 나중에 원하는 부분만 콕 집어 수정을 요청할 때 훨씬 유리하다.
1단계 — 무엇을, 누구에게 보여줄지 먼저 정한다
코드를 열기 전에 답해야 할 질문이 있다. 이 페이지를 볼 사람은 누구인가. 잠재적 고용주라면 경력과 기술 스택을 앞세워야 하고, 프리랜서로서 고객을 유치하려는 목적이라면 포트폴리오와 연락처가 첫 화면에서 바로 보여야 한다. 이 답이 정리되지 않은 채로 AI에게 “개인 소개 페이지 만들어줘”라고만 던지면, AI는 가장 무난한 템플릿을 내놓을 수밖에 없다. 구체적인 요청이 구체적인 결과를 만든다는 원칙은 바이브 코딩에서도 그대로 적용된다.
이 단계에서 흔히 하는 실수는 목적을 두 개 이상 동시에 잡는 것이다. “고용주에게도 어필하고 프리랜서 고객도 유치하고 싶다”는 식으로 목표를 넓히면, 페이지는 어느 쪽에도 확신을 주지 못하는 어중간한 결과물이 된다. 실습 단계에서는 하나의 목적, 하나의 대상만 정하고 시작하는 편이 좋다. 필요하면 이후에 다른 목적을 가진 페이지를 별도로 하나 더 만들면 된다.
실습에 들어가기 전에 아래 항목 중 이 페이지에 넣을 것과 뺄 것을 먼저 골라두면 다음 단계의 프롬프트가 훨씬 명확해진다.
- 자기소개 섹션: 이름, 직함, 한 줄 소개, 프로필 사진
- 경력·학력 섹션: 주요 경력, 프로젝트 경험, 학력
- 기술 스택 섹션: 사용 가능한 언어, 프레임워크, 도구
- 포트폴리오 섹션: 과거 프로젝트 사례(링크 또는 이미지)
- 연락처 섹션: 이메일, 링크드인, 깃허브 등
전부 넣을 필요는 없다. 오히려 실습 단계에서는 2~3개 섹션으로 줄여서 시작하고, 뼈대가 마음에 들면 이후 단계에서 섹션을 추가 요청하는 편이 AI의 응답을 검토하기에도, 잘못된 방향을 빨리 되돌리기에도 유리하다. 처음부터 다섯 개 섹션을 한꺼번에 요청하면, 그중 하나만 마음에 안 들어도 전체를 다시 검토해야 하는 부담이 생긴다.
목적과 포함할 섹션을 정했다면, 이를 한두 문장으로 정리해두자. 예를 들어 “신입 백엔드 개발자로서 채용 담당자에게 기술 스택과 프로젝트 경험을 보여주는 한 페이지짜리 소개 페이지”처럼 정리해두면, 다음 단계에서 AI에게 넘길 프롬프트의 뼈대가 이미 절반은 완성된 셈이다.
2단계 — 안티그라비티에서 새 워크스페이스 만들기
안티그라비티는 Google이 공개한 에이전트 우선(agent-first) 개발 플랫폼으로, 별도 결제 없이 개인 사용자에게 공개 프리뷰 형태로 제공되며 macOS·Windows·Linux를 모두 지원한다. 모델 선택 폭도 넓어서 Gemini 3 Pro에 대해서는 넉넉한 요청 한도를 제공하고, Anthropic의 Claude Sonnet 4.5와 OpenAI의 GPT-OSS도 함께 지원한다. 실습용으로 부담 없이 열어볼 수 있는 이유다.
프로젝트를 시작할 때는 항상 새 워크스페이스부터 만든다. 프로젝트마다 독립된 작업 공간을 두면 AI가 참조하는 파일과 맥락이 섞이지 않고, 나중에 다른 프로젝트를 진행할 때도 혼란이 없다. 하나의 워크스페이스 안에서 여러 프로젝트를 뒤섞어 진행하면, AI가 이전 프로젝트의 파일 구조나 코드 스타일을 잘못 참조해 엉뚱한 제안을 내놓는 경우가 생긴다. 사소해 보이지만 실습을 반복할수록 체감되는 차이다.
안티그라비티를 실행한 뒤 워크스페이스 생성 메뉴에서 프로젝트 이름을 정한다. 이번 실습에서는 personal-intro-page 같은 이름이면 충분하다. 이름 자체는 결과물에 영향을 주지 않지만, 나중에 여러 워크스페이스가 쌓였을 때 한눈에 구분할 수 있도록 프로젝트의 성격이 드러나는 이름을 붙여두는 습관을 들이는 편이 좋다.
워크스페이스가 생성되면 AI 파트너와의 대화창이 함께 열린다. 이 대화창이 앞으로 이 프로젝트에 관한 모든 요청과 응답이 쌓이는 공간이다. 대화가 길어지면 AI가 앞서 만든 파일 구조와 결정 사항을 계속 참조하므로, 같은 워크스페이스 안에서는 맥락이 끊기지 않도록 이어서 대화를 진행하는 것이 좋다.
3단계 — AI 개발 파트너에게 첫 프롬프트 던지기
워크스페이스가 준비되면 이제 대화를 시작한다. 처음부터 완성형을 요구하지 말고, 뼈대(구조)부터 요청하는 것이 핵심이다. 뼈대 단계에서 방향을 잘못 잡으면 이후 모든 수정이 그 위에서 어긋나기 때문이다. 색상이나 폰트 같은 디자인 요소는 구조가 확정된 다음에 다뤄도 늦지 않다.
기본 구조를 요청하는 프롬프트
아래는 1단계에서 정리한 항목을 반영해 AI 파트너에게 그대로 입력할 수 있는 프롬프트다. 이 프롬프트는 페이지의 전체 골격(HTML 구조와 섹션 배치)만 요청하고, 세부 디자인은 다음 단계로 미루는 역할을 한다.
정적 HTML/CSS로 개인 소개 웹페이지의 기본 골격을 만들어줘.
대상: 신입~주니어 개발자로서 잠재적 고용주에게 보여줄 용도.
섹션은 다음 순서로: 히어로(이름·직함·한 줄 소개), 기술 스택,
포트폴리오 카드 3개, 연락처.
지금 단계에서는 화려한 디자인 대신 시맨틱 태그와 섹션 구분이
명확한 뼈대만 만들어줘. 완성되면 각 섹션이 무엇을 담고 있는지
한 줄씩 설명해줘.이 프롬프트에는 세 가지가 명시돼 있다는 점을 눈여겨보자. 대상(누구에게 보여줄 것인지), 섹션의 순서, 그리고 지금 단계에서 하지 말아야 할 것(화려한 디자인)이다. 이 세 가지를 빼고 “개인 소개 페이지 골격 만들어줘”라고만 요청하면, AI는 임의의 순서와 임의의 섹션 개수로 결과를 내놓는다. 제약을 명확히 줄수록 검토할 여지가 줄어든다.
AI 파트너는 보통 이 요청에 대해 index.html과 기본 style.css 파일, 그리고 각 섹션의 역할을 요약한 설명을 함께 내놓는다. 아래는 그런 응답으로 흔히 나오는 골격의 형태다.
받게 되는 골격 코드의 예시
이 코드는 히어로·기술 스택·포트폴리오·연락처 네 개 섹션을 시맨틱 태그로만 구분해 둔, 디자인 이전 단계의 순수 구조다.
<body>
<header class="hero">
<h1>이름</h1>
<p class="role">직함 · 한 줄 소개</p>
</header>
<section class="skills">
<h2>기술 스택</h2>
<ul></ul>
</section>
<section class="portfolio">
<h2>포트폴리오</h2>
<div class="cards"></div>
</section>
<footer class="contact">
<h2>연락처</h2>
</footer>
</body>이 시점에서 할 일은 코드를 한 줄씩 이해하는 것이 아니라, 섹션 구성이 1단계에서 정한 목적과 맞는지 확인하는 것이다. 순서가 어색하다면, 예를 들어 연락처를 맨 아래 대신 히어로 바로 아래로 옮기고 싶다면 그 자리에서 바로 요청하면 된다. header와 footer, section 태그를 의도적으로 나눈 것도 확인해두자. div만 나열한 구조보다 이렇게 시맨틱 태그로 구분된 구조가 나중에 스타일을 입힐 때도, 검색엔진이 페이지를 이해할 때도 유리하다.
골격을 받았는데 목적과 어긋나 보인다면 처음부터 다시 요청하기보다, “포트폴리오 섹션을 기술 스택 위로 옮겨줘”처럼 골격의 일부만 콕 집어 수정하는 프롬프트를 보내자. 전체를 다시 요청하면 이미 괜찮았던 부분까지 예상치 못하게 바뀌는 경우가 있다.
4단계 — 결과를 보며 다음 지시로 이어가기
바이브 코딩의 핵심은 한 번의 완벽한 프롬프트가 아니라, 결과를 보고 다음 프롬프트를 다듬는 반복이다. 골격이 마음에 든다면 이제 스타일과 반응형 레이아웃을 요청할 차례다.
이 프롬프트는 골격은 그대로 두고 시각적 완성도(색상, 여백, 모바일 대응)만 개선해 달라는 요청이다. 구조를 다시 흔들지 않도록 “구조는 유지”라는 조건을 명시한 점이 중요하다.
구조는 그대로 유지하고 style.css만 다듬어줘.
- 히어로 섹션: 화면 세로 60% 정도, 중앙 정렬
- 포트폴리오 카드: 3열 그리드, 640px 이하에서는 1열로 전환
- 색상은 어두운 배경 + 밝은 텍스트 조합으로
- 폰트는 시스템 폰트 스택 사용
수정 후 어떤 CSS 속성을 왜 바꿨는지 간단히 알려줘.이렇게 “구조 요청 → 검토 → 스타일 요청 → 검토”를 두세 번 반복하면, 처음에 막연했던 페이지가 실제로 배포할 만한 형태로 좁혀진다. 한 번에 모든 것을 요청하고 통째로 평가하는 방식보다, 작은 단위로 나눠 확인하는 쪽이 무엇이 잘못됐을 때 되돌리기도 훨씬 쉽다.
스타일까지 정리됐다면, 콘텐츠를 실제 내용으로 채우는 프롬프트를 마지막으로 요청한다. 이 시점에는 예시 문구가 아니라 자신의 실제 이름, 경력, 프로젝트 링크를 직접 전달해야 한다. AI에게 “적당히 채워줘”라고 맡기면 그럴듯하지만 사실과 다른 내용이 들어갈 수 있으니, 채워 넣을 정보는 사람이 직접 정리해 넘기는 편이 안전하다.
5단계 — 배포 전에 점검할 것들
완성된 것처럼 보여도 배포 전에 꼭 확인해야 할 항목이 몇 가지 있다. AI가 만든 코드라고 해서 검토 없이 그대로 올리는 것은 권장하지 않는다.
- 모바일 화면 너비(360~420px 부근)에서 레이아웃이 깨지지 않는지 직접 브라우저 창을 줄여 확인한다.
- 이메일, 깃허브, 링크드인 등 연락처 링크가 실제로 클릭되는지, 오타는 없는지 하나씩 눌러본다.
- 이미지에 대체 텍스트(alt)가 비어 있지 않은지 확인한다.
- 페이지 제목(title 태그)이 “제목 없음” 같은 임시값으로 남아 있지 않은지 확인한다.
이 목록에서 하나라도 걸리는 것이 있다면, 해당 항목만 콕 집어 AI에게 수정을 요청하면 된다. “연락처 섹션의 이메일 링크에 mailto: 스킴이 빠져 있어. 수정해줘”처럼 구체적으로 지적할수록 수정도 빠르게 끝난다.
결론
개인 소개 웹페이지는 작아 보이지만, 기획-요청-검토-재요청이라는 바이브 코딩의 전체 사이클을 처음부터 끝까지 경험할 수 있는 과제다. 안티그라비티에서 워크스페이스를 만들고, 뼈대부터 단계적으로 요청하고, 매 결과물을 확인하며 다음 지시를 다듬는 흐름에 익숙해졌다면 이번 실습의 목적은 달성한 것이다.
여기서 익힌 순서, 즉 목적 정의 → 골격 요청 → 검토 → 스타일 요청 → 콘텐츠 채우기 → 배포 전 점검이라는 흐름은 페이지 하나짜리 실습에만 쓰이는 것이 아니다. 이후 더 복잡한 애플리케이션을 만들 때도 같은 리듬이 반복된다. 지금 이 페이지가 완벽하지 않아도 괜찮다. 다음 실습에서 더 큰 과제를 만났을 때, 오늘 거친 이 절차를 그대로 다시 꺼내 쓸 수 있다면 그것으로 충분하다.
다음 편에서는 이렇게 만든 페이지를 더 빠르고 가볍게 다듬는 성능 최적화 전략을 다룬다. 지금 만든 결과물을 그대로 두고 넘어가도 좋다.
참고 자료
- Google Antigravity 공식 제품 페이지 — https://antigravity.google/product
#바이브코딩실습, #안티그라비티워크스페이스, #개인소개웹페이지제작, #AI프롬프트뼈대요청, #포트폴리오사이트기획, #바이브코딩, #안티그라비티, #Antigravity, #AI개발파트너, #에이전트IDE
