AI를 활용한 웹 애플리케이션 구축

AI를 활용해서 실제로 동작하는 웹 앱을 처음부터 끝까지 만드는 실전 가이드야. 프로토타이핑에서 한 단계 더 나간 거지.

AI로 웹앱을 만들 때 첫 번째로 할 일은 프로젝트 구조를 잡는 것이야. 접근법은 명확해 — AI에게 코드를 바로 생성시키지 말고, 먼저 프로젝트 계획을 세우게 해.

"Next.js 14, TypeScript, Tailwind CSS, Prisma, PostgreSQL로 할 일 관리 앱을 만들 건데, 먼저 폴더 구조와 기술 스택 결정 이유를 설명해줘. 코드는 아직 쓰지 마."

이렇게 시작하면 AI가 프로젝트 구조를 제안하고, 각 기술 선택의 이유를 설명해. 여기서 개발자는 AI의 제안을 검토하고 조정할 수 있지. "Prisma 대신 Drizzle ORM을 쓰고 싶은데, 폴더 구조를 그에 맞게 수정해줘" 같은 식으로.

중요한 건 — 설정 파일(tsconfig.json, eslint.config, tailwind.config 등)은 AI가 잘 생성해줘. 하지만 프로젝트 간에 일관성을 유지하려면 본인만의 템플릿을 갖고 있는 게 좋아. AI에게 매번 처음부터 만들게 하면 프로젝트마다 설정이 미묘하게 달라지거든.

패키지 의존성도 주의가 필요해. AI가 추천하는 라이브러리가 더 이상 유지보수되지 않는 경우가 있고, 최신 버전과 호환되지 않는 버전을 지정하는 경우도 있지. package.json은 반드시 직접 확인해야 해.

AI에게 데이터베이스 스키마를 설계시키면 합리적인 결과가 나오는 경우가 많아. 기본적인 정규화, 외래 키 관계, 인덱스 설정 같은 건 잘 하거든.

하지만 주의점들이 있어:

• 비즈니스 요구사항을 충분히 전달해 — "사용자 테이블 만들어줘"가 아니라 "사용자는 이메일 또는 소셜 로그인으로 가입할 수 있고, 한 사용자가 여러 조직에 속할 수 있고, 각 조직 내에서 역할(admin, member, viewer)이 다를 수 있어"처럼
• 마이그레이션을 고려해 — AI가 최초 스키마는 잘 만들지만, 이후 스키마 변경(마이그레이션)에서 데이터 유실이 생길 수 있어. 마이그레이션 스크립트는 반드시 검토해야 해
• 성능을 위한 인덱스 — AI가 기본 인덱스는 잡아주지만, 실제 쿼리 패턴에 맞는 복합 인덱스나 부분 인덱스는 직접 고려해야 하지
• 시드 데이터 — 테스트용 더미 데이터 생성은 AI가 아주 잘하는 영역이야. "각 테이블에 대해 현실적인 테스트 데이터 20건씩 만들어줘"

ORM 설정도 AI가 잘 해주는 부분이야. Prisma 스키마나 Drizzle 스키마를 자연어 설명에서 바로 생성해주지. 하지만 관계 설정(1:N, N:M)과 캐스케이드 삭제 정책은 꼭 직접 확인해야 해.

프론트엔드와 백엔드를 각각 AI로 만드는 건 비교적 수월해. 문제는 둘을 연결하는 부분이야.

풀스택 통합에서의 흔한 문제를 보면:

• API 계약 불일치 — 프론트엔드에서 기대하는 응답 형식과 백엔드가 보내는 형식이 다른 경우. AI에게 프론트와 백을 따로 요청하면 이런 일이 생기지
• 타입 불일치 — TypeScript를 쓰더라도 프론트와 백의 타입 정의가 따로 놀 수 있어
• 인증 흐름 — 로그인, 토큰 갱신, 로그아웃의 전체 흐름을 AI가 부분적으로만 구현하는 경우
• 상태 관리 — 서버 상태와 클라이언트 상태의 동기화. AI가 각각은 잘 하는데 둘 사이의 일관성은 놓치기 쉬워

해결책은 — API 계약을 먼저 정의하고, 프론트와 백 모두 그 계약을 따르게 하는 거야. OpenAPI 스펙이나 tRPC 같은 도구를 쓰면 타입 안전한 API 계약이 보장돼. AI에게 "이 OpenAPI 스펙에 맞는 백엔드 핸들러를 구현해줘"라고 하면 계약 불일치 문제를 줄일 수 있지.

서버 컴포넌트(React Server Components)나 서버 액션 같은 최신 패턴도 AI가 잘 생성해주지만, **데이터 페칭 전략(언제 서버에서 가져오고, 언제 클라이언트에서 가져올지)**은 개발자가 판단해야 해.

웹앱의 테스트를 AI에 활용하는 전략을 계층별로 보면:

유닛 테스트 — AI가 가장 잘하는 영역이야. 개별 함수, 유틸리티, 헬퍼에 대한 테스트를 빠르게 생성하지. "이 함수에 대해 경계값 테스트를 포함한 유닛 테스트를 Jest로 작성해줘"

통합 테스트 — API 엔드포인트, 데이터베이스 연동 테스트. AI가 합리적인 테스트를 만들어주지만, **테스트 환경 설정(테스트 DB, 목 서버 등)**은 직접 잡아야 하는 경우가 많아

E2E 테스트 — Playwright나 Cypress를 활용한 전체 흐름 테스트. AI에게 "사용자가 로그인하고, 할 일을 추가하고, 완료 처리하는 E2E 테스트를 Playwright로 작성해줘"라고 하면 합리적인 테스트가 나와

수동 검증 체크리스트 — 자동화가 어려운 부분(UI/UX, 크로스 브라우저, 접근성)은 체크리스트를 AI에게 만들게 하고 직접 확인하는 거지

테스트는 AI가 생성한 코드에 대한 안전망이야. 테스트 없이 AI 생성 코드를 프로덕션에 배포하는 건 안전벨트 없이 운전하는 거라고 보면 돼.

프로토타입이 아니라 실제 서비스로 배포할 때 고려할 점들도 있어.

• CI/CD 파이프라인 — GitHub Actions 같은 CI/CD 설정도 AI가 잘 생성해줘. 하지만 시크릿 관리, 환경변수 설정은 직접 해야 하지
• 인프라 코드 — Docker 설정, 쿠버네티스 매니페스트 같은 것도 AI가 생성 가능해. 하지만 리소스 제한, 헬스 체크, 로깅 설정 같은 운영 디테일은 경험이 필요하거든
• 모니터링 — 에러 추적(Sentry), 로깅(Datadog), 성능 모니터링(Vercel Analytics) 설정. AI에게 기본 설정을 시키고 세부 조정은 직접

마지막으로 강조할 건 — AI로 앱을 빠르게 만들 수 있게 됐지만, 운영의 복잡도는 줄어들지 않았다는 거야. 코드 작성은 소프트웨어 생명주기의 일부일 뿐이고, 배포, 모니터링, 장애 대응, 스케일링은 여전히 인간의 영역이지.

---

정리

7장에서 기억할 거 세 가지:

1. 프로젝트 설정부터 AI에게 시키되, 계획을 먼저 세우고 코드를 나중에 생성해. 바로 코드부터 뽑으면 구조가 엉망이 되거든
2. 풀스택 통합에서 가장 많은 문제가 생겨. API 계약을 먼저 정의하고, 프론트와 백이 같은 계약을 따르게 해야 해
3. 코드 작성은 소프트웨어 생명주기의 일부일 뿐이야. 배포, 모니터링, 운영의 복잡도는 AI가 줄여주지 않거든