Cursor로 작은 웹앱을 빠르게 만드는 흐름

카테고리: AI 도구 #Cursor#AI 코딩#웹앱 개발#개인 프로젝트

Cursor는 작은 웹앱을 시작할 때 확실히 빠릅니다. 빈 화면에서 컴포넌트와 기본 스타일을 잡는 속도는 사람이 처음부터 치는 것보다 훨씬 낫습니다.

다만 처음부터 전부 맡기면 구조가 금방 커집니다. 개인용 도구는 기능보다 유지가 더 어렵기 때문에, 저는 범위를 아주 작게 잡는 쪽이 맞다고 봅니다.

먼저 만들 화면을 줄인다

“블로그 자동화 대시보드 만들어줘”라고 하면 결과가 너무 커집니다. 대신 첫 화면은 이 정도로 줄이는 편이 좋습니다.

오늘 작성할 글감 목록
작성 중인 글 상태
배포 전 체크리스트
카테고리별 글 수
Search Console 확인 항목

이 정도면 서버 없이도 시작할 수 있습니다. Markdown이나 JSON 파일을 읽어서 보여주는 정적 화면이면 충분합니다.

Cursor에게 바로 코드를 맡기기 전에 화면을 문장으로 적어둡니다.

상단에는 서비스 이름과 설명을 둔다.
왼쪽에는 오늘 볼 글감을 둔다.
가운데에는 최근 글 상태를 둔다.
오른쪽에는 배포 전 체크리스트를 둔다.
모바일에서는 한 줄로 쌓이게 한다.

이렇게만 해도 결과가 덜 흔들립니다. 디자인 시안까지는 아니어도, 화면의 우선순위는 사람이 먼저 정하는 편이 낫습니다.

작은 웹앱에서 초반부터 아래 기능을 붙이면 관리가 커집니다.

로그인
데이터베이스
관리자 권한
결제
복잡한 알림
여러 사용자 지원

개인용 도구라면 처음에는 “나만 보는 정적 화면”으로 충분합니다. 나중에 정말 필요해지면 저장 기능을 붙이면 됩니다.

제가 보기에 Cursor가 잘하는 일은 비교적 분명합니다.

기본 컴포넌트 생성
반복되는 CSS 정리
타입 정의 초안 작성
간단한 유틸 함수 작성
기존 코드 설명
에러 메시지 원인 후보 정리

반대로 제품 방향, 보안 판단, 데이터 구조의 장기 유지보수는 직접 결정하는 편이 안전합니다. 코드는 빨리 만들 수 있지만, 잘못 잡은 구조는 오래 갑니다.

AI 코딩에서 제일 위험한 건 “그럴듯한 코드”입니다. 설명은 맞아 보이는데 실제로는 빌드가 깨질 수 있습니다.

그래서 작은 변경 뒤에는 바로 확인합니다.

npm run build

에러가 나오면 에러 전체를 다시 주고, 한 번에 여러 파일을 고치게 하기보다 원인부터 설명하게 합니다. 이 방식이 시간이 조금 걸려도 결과가 안정적이었습니다.

나중에 만들고 싶은 1차 도구는 거창한 CMS가 아닙니다. 블로그 운영 상태를 한눈에 보는 작은 대시보드면 됩니다.

Markdown 글 30개 목록
카테고리별 글 수
updatedDate 누락 글
내부 링크가 적은 글
배포 전 체크리스트
sitemap URL 수

이 정도 기능은 정적 데이터만 읽어도 만들 수 있습니다. 먼저 읽기 전용으로 만들고, 저장·수정 기능은 나중에 붙이는 쪽이 부담이 적습니다.

Cursor는 작은 웹앱의 출발 속도를 올려줍니다. 하지만 좋은 결과를 얻으려면 “크게 요청하기”보다 “작게 만들고 자주 확인하기”가 더 중요했습니다.

개인 블로그나 자동화 도구라면 처음에는 정적 화면, Markdown 기반 데이터, npm run build 검증부터 시작하는 편이 가장 현실적입니다.

Cursor로 작은 웹앱을 만들 때도 처음부터 관리 시스템 전체를 만들 필요는 없었습니다. Daejin Lab 기준으로는 “읽기 전용 점검 화면” 정도가 첫 단계로 적당했습니다.

이 방향은 반복 작업을 Python 스크립트로 줄인 사례에서 말한 읽기 전용 점검과 맞고, 개인 프로젝트에 AGENTS.md를 두는 이유처럼 작업 규칙을 먼저 정해두면 더 안전하게 확장할 수 있습니다.