2026-01-07

TIL | 바이브 코딩으로 Jekyll 사이트 배포를 진행했다

오늘의 문제

  • 디자인은 떠올랐으나, AI를 활용해 바로 빌드까지 이어지지 않는 문제가 발생했다.
  • Figma Make로 생성한 코드를 Jekyll 기반 사이트로 옮기는 과정에서 설정이 반복적으로 꼬였다.
  • GitHub Pages 배포 과정에서 CSS 경로, baseurl, 빌드 순서 문제로 디버깅 비용이 급격히 증가했다.
  • GPT 단독 사용만으로는 실제 브라우저 환경에서의 JS 실행 결과를 확인하는 데 한계가 있었다.

해결 과정

  • Figma Make 결과물을 단순 코드 결과물이 아닌 실제 배포 가능한 사이트로 먼저 띄웠다.
  • antigravity를 활용하여 브라우저에 직접 접속하며 다음 항목을 확인했다.
    • JavaScript 실행 결과
    • DOM 변경 사항
    • 반환 값과 실제 화면 출력의 차이
  • 기본 설정부터 다시 점검했다.
    • _config.yml의 baseurl
    • GitHub Actions의 빌드 및 배포 순서
    • Tailwind → Jekyll 빌드 파이프라인
  • 커밋과 푸시는 직접 수행하며 변경 범위를 지속적으로 통제했다.

배운 점

1. 바이브 코딩의 핵심은 초기 검증에 있었다

  • 구현 이전에 설계와 검증을 선행하는 것이 디버깅 시간을 크게 줄였다.
  • antigravity를 초기 설계 단계부터 활용하는 것이 더 효율적이었다.

2. antigravity는 강력한 디버깅 도구였다

  • 브라우저 기반으로 실제 동작을 확인할 수 있었다.
  • 레거시 프로젝트나 AI 생성 코드에 대해
    • 구조 가이드 문서
    • 학습용 설명 문서 를 요청했을 때 높은 정확도를 보였다.

3. Jekyll과 Tailwind의 빌드 구조를 이해했다

  • npm run build 단계에서 Tailwind가 사용된 클래스만 추출해 CSS를 생성했다.
  • jekyll build 단계에서 Liquid 변수를 치환하고 정적 HTML을 생성했다.
  • 결과물은 _site 폴더에 생성되어 GitHub Pages로 배포됐다.

4. SSR과 CSR의 차이를 실전에서 체감했다

  • Jekyll은 SSG 기반으로 배포 시 한 번만 렌더링됐다.
  • 일부 기능(연속 문제 풀이)은 CSR 방식으로 JS 실행 이후 화면이 갱신됐다.
  • 초기 로딩과 인터랙션 사이의 트레이드오프를 명확히 이해했다.

결과

  • 바이브 코딩을 활용한 알고리즘 트래커 사이트 배포를 완료했다.
  • URL: https://hann2a.github.io/algorithm-tracker/
  • 프론트엔드 관점에서 AI와 antigravity의 조합이
    • 무작위 삽질을
    • 관리 가능한 디버깅 과정으로 전환해 준다는 점을 확인했다.

다음 목표:

  • 백엔드 프로젝트 환경에서 antigravity 기반 디버깅 적용 방식을 정리해 볼 계획을 세웠다.

results matching ""

    No results matching ""