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

Cursor로 작은 웹앱을 만들면 속도감이 좋습니다. 화면 하나, 버튼 하나, 간단한 상태 관리 정도는 생각보다 빨리 나옵니다. 그래서 처음에는 더 크게 맡겨도 될 것처럼 느껴졌습니다.

하지만 작은 앱도 기준 없이 만들면 금방 지저분해졌습니다. Daejin Lab 작업에서도 비슷했습니다. 빠르게 만드는 것보다, 어디까지 작게 유지할지 정하는 일이 더 중요했습니다.

먼저 만들 화면을 줄인다

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

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

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

코드 전에 화면을 말로 적는다

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

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

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

한 번에 붙이지 않는 기능

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

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

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

Cursor에게 맡기기 좋은 일

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

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

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

매번 빌드로 확인한다

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

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

npm run build

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

Daejin Lab에 적용한다면

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

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

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

제가 남긴 기준

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

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

첫 화면으로 줄인 기능 표

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

화면 요소	처음 넣을 기능	나중으로 미룰 기능
글 상태	글 수, 카테고리, draft 여부 표시	브라우저에서 직접 글 수정
SEO 점검	description 길이, 내부 링크 수 표시	Search Console 자동 조작
배포 확인	최근 빌드 시간과 대표 URL 체크리스트	자동 push, 자동 배포 승인
콘텐츠 보강	약한 글 후보 목록	검수 없는 초안 자동 발행

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

지금 만든다면 첫 버전의 완료 기준

Cursor로 작은 웹앱을 만든다면 지금은 기능보다 “보여줄 지표”를 먼저 줄일 것 같습니다. Daejin Lab 운영에서 실제로 반복 확인한 값은 글 수, 짧은 글 수, 내부 링크 부족 글 수, 대표 이미지 누락 수, sitemap URL 수였습니다. 이 값들만 읽기 전용으로 보여줘도 운영 판단이 훨씬 쉬워집니다.

첫 버전의 완료 기준은 아래 정도가 현실적입니다.

src/content/blog/*.md를 읽는다.
카테고리, tags, heroImage, updatedDate를 표로 보여준다.
1,800자 미만 글과 내부 링크 2개 이하 글을 표시한다.
수정은 하지 않고 후보 목록만 만든다.
npm run build 결과를 마지막 검증으로 남긴다.

여기서 중요한 점은 웹앱이 글을 자동으로 고치지 않는다는 것입니다. 후보를 뽑는 역할은 반복 작업을 Python 스크립트로 줄인 사례처럼 스크립트가 맡고, 실제 글 보강과 발행 판단은 사람이 봅니다. 나중에 기능을 키우더라도 GitHub Actions로 블로그 배포 자동화를 볼 때의 기준처럼 검증 자동화부터 붙이는 편이 맞습니다.

작게 만들 때 남긴 기준

Cursor는 작은 웹앱의 첫 모양을 잡을 때 좋았습니다. 다만 한 번에 기능을 많이 넣으면 검수할 것이 너무 늘어납니다.

다음에는 화면 하나, 데이터 흐름 하나, 저장 방식 하나처럼 잘라서 맡기려고 합니다. 작게 만들수록 AI 도구가 빛나고, 크게 뭉칠수록 사람이 다시 풀어야 했습니다.

빨리 만드는 만큼 빨리 망가질 수도 있다

Cursor로 화면이 빨리 나오면 기분이 좋습니다. 문제는 그 속도 때문에 아직 정하지 않은 기능까지 붙이고 싶어진다는 점이었습니다. 작은 웹앱일수록 먼저 버릴 기능을 정해야 했습니다. 그래야 빠른 도구가 진짜 빠르게 느껴졌습니다.

2026-05-31에 다시 본 작은 웹앱의 기준

Cursor로 작은 웹앱을 만들 때 가장 어려운 점은 시작이 아니라 멈춤이었습니다. 기능을 붙이는 속도가 빠르면 첫 화면이 금방 커집니다. AdSense 보강 관점에서 이 글도 단순 도구 소개가 아니라, 작은 범위를 어떻게 유지했는지 보여주는 글이어야 했습니다.

첫 화면, 최소 상태, 핵심 기능, build 검증으로 작은 웹앱 범위를 줄이는 카드

이 카드는 작은 웹앱을 만들 때 범위를 줄이는 공개용 기준입니다. 빠른 생성보다 검증 가능한 작은 단위를 우선합니다.

Daejin Lab 작업에도 같은 기준을 적용합니다. “블로그 운영 대시보드”를 한 번에 만들기보다, 공개 글 목록, draft 상태, 빌드 결과처럼 첫 화면에 필요한 것만 고릅니다. 화면이 작으면 검증도 작아집니다. 반대로 처음부터 로그인, 통계, 외부 API, 자동 발행까지 붙이면 웹앱보다 운영 리스크가 먼저 커집니다.

참고한 공식 문서

Cursor 문서는 도구 사용 전제, Astro 문서는 콘텐츠 구조, Google 문서는 공개 글의 품질 방향을 확인하는 데 봅니다. 이 글의 판단은 작은 앱을 실제 운영에 붙일 때의 범위 관리에 초점을 둡니다.

확인하지 않은 것

이 글은 특정 프레임워크나 Cursor 기능의 성능 비교가 아닙니다. 실제 앱을 만들 때의 코드 품질, 접근성, 배포 방식, 보안 검토는 별도 작업으로 분리해야 합니다.

FAQ

Cursor로 처음 만들 기능은 어느 정도가 적당한가요?

화면 하나, 상태 하나, 핵심 동작 하나 정도가 좋았습니다. 처음부터 대시보드를 크게 만들면 검증 범위가 너무 커집니다.

왜 작은 범위가 중요한가요?

작게 만들면 build와 동작 확인이 쉽고, 잘못됐을 때 되돌리기도 쉽습니다. AI 도구를 쓸수록 범위 제한이 중요했습니다.

블로그 운영과 어떻게 연결되나요?

블로그 운영 도구를 만들 때도 자동 발행이나 계정 조작보다 공개 글 상태 확인, 빌드 결과 표시 같은 안전한 기능부터 보는 것이 맞습니다.