제16장 실전 1: 풀스택 웹앱 만들기

Antigravity를 처음 진지하게 써보는 사람에게 가장 인상적인 순간은, AI가 코드를 "조금 도와주는" 장면이 아니다. 빈 폴더 하나에서 시작해 프로젝트를 만들고, 필요한 패키지를 설치하고, 개발 서버를 띄우고, 브라우저에서 직접 눌러 보고, 이상한 부분을 고치고, 스크린샷과 녹화까지 남기는 장면이다. 그때 비로소 "아, 이건 챗봇이 아니라 작업자구나"라는 감각이 온다.¹

이번 장에서는 그 감각을 가장 직관적으로 보여 주는 예제로, Next.js 기반의 대시보드를 처음부터 끝까지 만들어 본다. 핵심은 화려한 기능을 많이 넣는 것이 아니라, 자연어 요구사항이 실제 제품 골격으로 바뀌고, 그 결과를 사람이 검증 가능한 형태로 확인하는 흐름 자체를 체험하는 데 있다. Antigravity는 이런 풀스택 시나리오에서 계획, 구현, 검증을 한 덩어리로 다루도록 설계되어 있다.²³

무엇을 만들 것인가

예제는 내부 운영용 SaaS 대시보드다. 화면은 단순하지만, 실무에서 자주 만나는 요소를 빠짐없이 담는다. 왼쪽에는 사이드바, 위에는 검색과 사용자 메뉴가 있는 헤더, 중앙에는 KPI 카드와 최근 활동 테이블, 아래에는 상태 요약 패널이 있다. 다크 모드와 모바일 반응형도 포함한다.

여기서 중요한 포인트는 "보기 좋은 목업"에서 멈추지 않는 것이다. 숫자 카드가 화면에 예쁘게 뜨는 것만으로는 풀스택이라 부르기 어렵다. 최소한의 API 경로 또는 서버 측 데이터 공급 구조가 있어야 한다. 그래서 이 예제에서는 app/api/metrics/route.ts 같은 간단한 라우트를 두고, 프론트가 그 데이터를 읽어 대시보드를 그리게 한다. 처음에는 더미 데이터를 써도 괜찮다. 핵심은 데이터 흐름이 존재해야 한다는 점이다.

이런 형태의 대시보드는 실제 예시 저장소에서도 자주 보인다. Next.js, Tailwind, shadcn/ui 조합에 인증, 설정, 분석 카드, 반응형 레이아웃을 붙이는 방식은 오늘날 웹앱의 기본 체력에 가깝다.⁴

첫 의뢰는 이렇게 던진다

처음부터 "대시보드 하나 만들어 줘"라고만 말하면, 에이전트는 성실하게 움직이지만 결과는 종종 애매하다. 실전에서는 범위를 좁히고, 완료 조건을 박아 넣고, 검증 방법까지 같이 적는 편이 훨씬 낫다.

예를 들어 첫 프롬프트는 이렇게 줄 수 있다.

새 Next.js App Router 프로젝트를 생성해 주세요. TypeScript, Tailwind CSS, shadcn/ui를 사용합니다.
목표는 운영용 대시보드의 첫 버전을 만드는 것입니다.
필수 화면은 다음과 같습니다.\

• 좌측 사이드바가 있는 대시보드 레이아웃\

• 상단 헤더, 검색 입력, 사용자 메뉴\

• KPI 카드 4개\

• 최근 활동 테이블\

• 시스템 상태 요약 패널\

• 다크/라이트 모드 토글\

• 모바일 반응형 레이아웃
  백엔드는 실제 DB 대신 mock 데이터를 제공하는 API route로 시작해 주세요.
  완료 후 개발 서버를 실행하고, 브라우저에서 데스크톱과 모바일 뷰포트 모두 검증해 주세요.
  결과물로 Implementation Plan, Code Diff, 스크린샷, 브라우저 녹화를 남겨 주세요.

이 프롬프트가 좋은 이유는 세 가지다. 첫째, 기술 스택이 명확하다. 둘째, 결과 화면이 구체적이다. 셋째, "검증까지 끝내라"는 요구가 들어 있다. 많은 사람이 여기서 세 번째를 빼먹는다. 그러면 에이전트는 코드를 만드는 데는 성공해도, 그 코드가 실제로 뜨는지까지는 보장하지 않는다.

복잡한 프로젝트이므로 모드는 Fast보다 Plan이 잘 맞는다. Antigravity는 Planning 모드에서 작업 목록과 구현 계획을 먼저 만들고, 그다음 구현으로 넘어가는 흐름에 강하다.⁵

계획을 읽는 순간, 챗봇이 아니라 팀원이 된다

프롬프트를 보내면 에이전트는 곧바로 파일을 마구 만들기보다, 먼저 일을 쪼갠다. 보통 이런 순서가 나온다.

• 프로젝트 생성과 기본 의존성 설치

• UI 쉘 구성: 사이드바, 헤더, 콘텐츠 영역

• 데이터 모델 초안과 mock API 작성

• 카드, 테이블, 상태 패널 컴포넌트 구현

• 테마 토글과 반응형 처리

• 로컬 실행 및 브라우저 검증

이때 해야 할 일은 계획을 "통과 의례"처럼 넘기지 않는 것이다. 오히려 여기서 가장 많은 시간을 아끼게 된다. 예를 들어 다음 같은 코멘트를 미리 남길 수 있다.

"초기 버전에서는 인증은 제외해 주세요. 대신 나중에 붙이기 쉬운 구조로 레이아웃을 분리해 주세요."

"차트 라이브러리는 지금 넣지 말고, 카드·테이블 중심으로 먼저 완성해 주세요."

"모바일에서는 사이드바가 오버레이 드로어 방식이 되게 해 주세요."

이렇게 적으면 에이전트는 범위를 넓히지 않고, 지금 필요한 제품 뼈대에 집중한다. 사람 개발자에게도 같은 일이 벌어진다. 요구사항이 선명하면 구현은 빨라지고, 수정 횟수는 줄어든다.

프로젝트 스캐폴딩: 이제 진짜 일이 시작된다

계획이 승인되면 에이전트는 익숙한 개발자처럼 움직인다. 새 디렉터리를 만들고, Next.js 프로젝트를 초기화하고, Tailwind를 맞추고, shadcn/ui를 설정한다. 필요하면 아이콘 패키지나 테이블 유틸리티도 추가한다. 권한 설정에 따라 터미널 명령은 자동 실행되거나, 중간에 승인을 요청한다.

사람이 직접 하면 보통 이런 순서를 밟는다.

npx create-next-app@latest ops-dashboard
cd ops-dashboard
npm install
npx shadcn@latest init
npm run dev

Antigravity를 쓰면 이 순서를 사람이 타이핑하지 않아도 된다. 중요한 것은 "어떤 명령을 칠까"가 아니라, "어떤 결과를 얻고 싶은가"다.

물론 여기서부터가 진짜 실전이다. 프로젝트가 한 번에 매끈하게 뜨면 좋겠지만, 대개는 작은 삐걱거림이 생긴다. 예를 들면 이런 것들이다.

shadcn 초기화 도중 베이스 컬러 선택이 어긋나거나, Tailwind 설정 파일 위치가 예상과 달라질 수 있다. 아이콘 import 경로가 잘못 잡혀 첫 실행에서 에러가 날 수도 있다. App Router 레이아웃과 클라이언트 컴포넌트 경계가 헷갈리면 하이드레이션 경고가 생기기도 한다. 사람이 직접 작업할 때도 늘 만나던 문제들이다. 차이는, 이제 그 문제를 발견하고 수정하는 루프까지 에이전트가 이어서 처리할 수 있다는 점이다.

첫 화면이 떴다고 끝난 것이 아니다

많은 AI 코딩 데모는 여기서 멈춘다. "대시보드가 생성되었습니다." 멋진 말이다. 하지만 실제 제품 개발자는 그다음 질문을 던진다.

정말 뜨나?

깨지는 곳은 없나?

모바일에서는 어떻지?

콘솔에 빨간 에러는 안 뜨나?

Antigravity가 강한 지점은 바로 이 다음 단계다. 공식 문서가 강조하듯, 이 도구는 단순히 코드를 만드는 데서 멈추지 않고 브라우저 상호작용과 검증 결과를 함께 남기는 흐름을 지향한다.¹⁶

개발 서버가 올라가면 에이전트는 브라우저를 열고 localhost:3000으로 이동할 수 있다. 그리고 Browser Subagent가 등장한다. 이 서브에이전트는 클릭, 스크롤, 타이핑, 콘솔 로그 읽기, 스크린샷 촬영, 세션 녹화까지 할 수 있다.⁷

여기서 체감이 확 온다. 에이전트는 이제 에디터 속 글쓰기 기계가 아니다. 직접 화면을 본다. 버튼을 누른다. 레이아웃이 무너지면 그것을 증거로 남긴다.

Browser Subagent로 검증하는 법

대시보드 예제에서는 다음 정도만 자동 검증해도 상당히 실용적이다.

• 데스크톱 뷰에서 사이드바, 헤더, KPI 카드, 테이블이 정상 배치되는지 확인

• 모바일 뷰포트에서 햄버거 메뉴와 드로어가 정상 동작하는지 확인

• 다크 모드 토글 시 색상 대비와 아이콘 상태가 자연스러운지 확인

• 콘솔 에러가 없는지 확인

좋은 요청은 아주 인간적이다.

앱을 브라우저에서 열고, 1440px과 390px 뷰포트에서 각각 검증해 주세요.
모바일에서는 사이드바가 오버레이로 열리는지 확인하고, 다크 모드를 켜고 끈 뒤 스크린샷을 남겨 주세요.
콘솔 에러가 있으면 수정한 뒤 다시 검증해 주세요.

이 요청이 좋은 이유는 에이전트가 "무엇을 확인해야 하는지" 알기 때문이다. 그냥 "테스트해 줘"라고 하면, 대체 뭘 기준으로 성공인지 모호해진다.

실제로 브라우저 세션이 시작되면 에이전트는 페이지를 열고, 테마 토글을 누르고, 모바일 사이즈로 전환하고, 메뉴를 열고, 필요하면 새로고침까지 해 본다. 그 결과는 스크린샷과 녹화로 남는다. 이 장면이 중요한 이유는, 사람이 검증을 생략하지 않게 해 주기 때문이다. 코드를 다 읽지 않아도, 적어도 "어떻게 확인했는가"를 볼 수 있다.⁷

디자인 피드백은 대화창보다 Artifact 위에 남겨라

이제 재미있는 구간이 온다. 화면은 떴지만, 썩 마음에 들지 않는다. KPI 카드 간격이 조금 답답하고, 헤더가 너무 밋밋하고, 모바일에서 테이블이 갑갑하다. 여기서 많은 사람은 새 채팅에 다시 장문 프롬프트를 쓴다. 하지만 Antigravity의 묘미는 결과물 위에서 바로 방향을 꺾는 데 있다.

스크린샷 위에 특정 영역을 선택해 코멘트를 남기거나, 코드 diff 위에 직접 피드백을 달 수 있다. 마치 디자이너가 피그마에 댓글 남기고, 리뷰어가 Google Docs에 첨삭하는 느낌에 가깝다.

예를 들어 이런 코멘트가 실전에서 잘 먹힌다.

"이 카드 4개가 같은 높이로 정렬되게 해 주세요. 숫자와 라벨 사이 여백도 조금 더 주세요."

"모바일 화면에서 최근 활동 테이블은 가로 스크롤보다 카드 리스트 형태가 더 자연스럽겠습니다."

"다크 모드에서 배경 대비가 너무 약합니다. 카드 배경을 한 단계 더 띄워 주세요."

"헤더 오른쪽 사용자 메뉴가 약간 좁아 보입니다. 아바타와 이름 간격을 8px 정도 늘려 주세요."

중요한 점은, 피드백이 추상적 감상에 머물지 않아야 한다는 것이다. "좀 더 세련되게"는 에이전트에게도 어렵다. 반면 "모바일 390px 기준으로 카드 간 세로 간격을 늘려 달라"는 실행 가능하다.

한 번 더 돌리면 앱은 갑자기 제품처럼 보인다

첫 빌드는 대개 "작동하는 데모" 수준이다. 하지만 검증과 피드백을 한 바퀴만 돌면, 화면은 갑자기 제품처럼 보이기 시작한다.

예를 들어 첫 번째 반복에서 레이아웃 안정성을 잡는다. 두 번째 반복에서 타이포그래피와 간격을 손본다. 세 번째 반복에서 빈 상태, 로딩 상태, 오류 메시지를 정리한다. 이 정도만 해도 사용자 눈에는 완성도가 확 올라간다.

이 과정에서 Antigravity가 남기는 Artifacts는 단순한 부산물이 아니다. 그것은 팀 커뮤니케이션 수단이다. 왜 이 구조로 갔는지, 어디를 확인했는지, 무엇이 바뀌었는지, 다음 수정 포인트가 무엇인지가 흐름으로 남는다. 특히 테크 리드나 리뷰어 입장에서는 "AI가 뭘 했는지 모르겠다"는 불안이 크게 줄어든다.²³

풀스택 감각을 살리는 작은 확장

대시보드 껍데기가 완성되면, 곧바로 데이터 흐름을 조금만 깊게 만들 수 있다. 어렵게 갈 필요는 없다.

예를 들어 KPI 카드의 수치를 정적 상수가 아니라 /api/metrics에서 가져오게 만들고, 최근 활동 테이블은 /api/activities를 읽게 한다. 설정 패널의 토글은 임시로 서버 액션 또는 API route에 저장한 뒤 낙관적 업데이트를 붙여 볼 수 있다. 이렇게 하면 앱은 단순 화면 생성기를 넘어, 프론트와 백이 실제로 이어지는 연습장이 된다.

중요한 것은 처음부터 DB와 인증과 배포를 전부 한 번에 다 넣지 않는 것이다. 첫 실전의 목적은 "한 번에 모든 걸 해냈다"가 아니라 "처음부터 끝까지 이어지는 개발 루프를 경험했다"에 있다. 빈 폴더에서 시작해, 구조를 세우고, 화면을 만들고, 데이터를 연결하고, 브라우저에서 검증하고, 피드백으로 다듬는 루프. 바로 그 루프가 Agent-First 개발의 핵심 감각이다.

이 장면에서 배워야 할 진짜 포인트

이 실습이 보여 주는 가장 큰 변화는 개발자의 타이핑 속도가 빨라졌다는 사실이 아니다. 역할이 바뀌었다는 점이다.

이제 개발자는 화면 하나하나를 손으로 그리는 사람이라기보다, 목표를 정의하고, 제약을 주고, 결과를 검증하고, 피드백을 통해 품질을 끌어올리는 사람에 가까워진다. Next.js 프로젝트를 생성하는 명령어를 외우는 일보다, 어떤 대시보드가 필요한지 분명하게 설명하는 일이 더 중요해진다. CSS 클래스 하나를 직접 넣는 일보다, 모바일에서 무엇이 불편한지 정확히 말하는 일이 더 중요해진다.

Antigravity가 보여 주는 "처음부터 끝까지 만든다"는 경험은 결국 이것이다. 코드를 덜 쓰는 대신 덜 생각하는 것이 아니라, 더 상위의 레벨에서 더 많이 생각하게 되는 것. 어떤 제품을 만들지, 어떤 기준으로 완성이라 부를지, 어떤 증거를 보고 신뢰할지를 계속 결정하게 되는 것이다.

그래서 이 장의 실습은 단순한 대시보드 예제가 아니다. Agent-First 시대에 개발자가 어떤 식으로 일하게 될지 보여 주는 축소판이다. 손은 조금 덜 바빠지고, 판단은 훨씬 더 바빠진다.

다음 장에서는 이 흐름을 더 까다로운 현실로 가져간다. 새 앱을 만드는 일보다 훨씬 성가신 작업, 즉 레거시 시스템을 안전하게 옮기는 작업이다. 거기서부터 비로소 에이전트의 진짜 실무 체력이 드러난다.

참고

¹Google Antigravity

²Google Antigravity Tutorial: Build a Finance Risk Dashboard

³Why fullstack developers choose Google Antigravity

⁴GitHub - montesinodev/nextjs-dashboard-antigravity

⁵Google Antigravity 시작하기  |  Google Codelabs

⁶Complete Guide to Google Antigravity

⁷Google Antigravity Documentation - Browser Subagent