바이브코딩

AI 에디터 전용 배포 친화적 프롬프트 템플릿

Cursor Composer, Claude Code, ChatGPT에게 24시간 클라우드 런타임에 최적화된 코드를 작성하도록 유도하는 프롬프트 엔지니어링 가이드.

업데이트: 2026-10-02

Cursor, Claude Code, ChatGPT 같은 LLM 모델에게 단순히 "텔레그램 봇 만들어줘"라고 요청하면, AI는 개발자가 로컬 컴퓨터 터미널에서 1회성으로 실행하고 마는 형태의 코드를 작성하는 경향이 강합니다.

그 결과 대화형 input() 함수가 들어가서 클라우드 배포 시 프로세스가 멈추거나, requirements.txt 생성을 빠뜨리고, 로컬 PC 절대 경로를 하드코딩하여 서버 배포 즉시 크래시되는 문제가 발생합니다.

AI가 처음부터 DashCloud의 24/7 무중단 백그라운드 런타임에 완벽히 호환되는 견고한 코드를 생성하도록 지시하는 5대 프롬프트 원칙과 복사해 쓸 수 있는 도메인별 템플릿을 상세히 다룹니다.


AI가 로컬 친화적 코드를 작성하는 4대 이유와 부작용

  1. 대화형 입력 가정 편향: AI는 개발자가 터미널 창을 쳐다보고 있다고 가정하여 input("키를 입력하세요:")나 GUI 알림 창을 띄우는 코드를 작성하기 쉽습니다. 클라우드 런타임에는 키보드 입력기가 없으므로 프로세스가 무한 대기에 빠집니다.
  2. 스크립트 단발 종료 함정: 1회 실행 후 스크립트 끝에 도달하여 정상 종료되는 코드를 짭니다. 상시 런타임에서는 24시간 이벤트 대기 루프가 필요합니다.
  3. 환경변수 하드코딩 또는 누락: 코드 최상단에 TOKEN = "1234..."를 직접 적어두어 깃허브 유출 위험을 유발하거나, .env 파일 로더를 빠뜨립니다.
  4. 의존성 명세 누락: 로컬 컴퓨터에 이미 설치되어 있는 라이브러리를 requirements.txt에 적어주지 않아 배포 시 ModuleNotFoundError를 유발합니다.

클라우드 상시 가동을 위한 5대 프롬프트 황금률

AI 에디터에게 코드를 요청할 때는 항상 다음 5가지 제약 조건을 명시적으로 프롬프트에 주입해야 합니다:

[ 24/7 클라우드 배포 프롬프트 5대 필수 조건 ]
1. "터미널 종료 후에도 꺼지지 않도록 24시간 상시 백그라운드 루프로 작성해줘."
2. "모든 API 키와 시크릿은 os.environ.get()을 통해 환경변수에서 불러오도록 해줘."
3. "설치해야 할 라이브러리 목록을 requirements.txt (또는 package.json) 파일에 정확히 정리해줘."
4. "로컬 절대경로(C:\ 등)를 절대 쓰지 말고, pathlib 기반의 상대경로(/app/data)를 써줘."
5. "SIGTERM/SIGINT 신호 수신 시 안전하게 자원을 닫는 Graceful Shutdown을 넣어줘."

도메인별 실전 프롬프트 템플릿 (복사하여 사용)

템플릿 1: 24/7 텔레그램 알림 봇 요청 프롬프트

DashCloud의 24시간 클라우드 런타임에 배포할 파이썬 텔레그램 봇을 만들어줘.
아래 조건을 엄격하게 지켜서 코드를 작성해줘:
 
1. 프레임워크: python-telegram-bot v21 최신 비동기 문법 사용
2. 기능:
   - /start 및 /status 명령어 핸들러
   - 10분마다 특정 API(또는 웹사이트)를 검사하여 새로운 공지가 있으면 관리자에게 알림 전송
3. 인프라 조건:
   - 봇 토큰과 관리자 Chat ID는 os.environ.get("TELEGRAM_BOT_TOKEN") 및 os.environ.get("TELEGRAM_ADMIN_CHAT_ID")에서 로드
   - 환경변수 누락 시 친절한 안내와 함께 sys.exit(1) 종료
   - 429 Too Many Requests 에러 방지를 위한 예외 처리 내장
   - 서버 재시작 시 데이터가 유지되도록 /app/data/bot.db 경로에 SQLite로 이전 알림 발송 기록 저장
4. 산출물:
   - main.py
   - requirements.txt (정확한 버전 포함)
   - .env.example

템플릿 2: 무중단 Playwright 크롤러 요청 프롬프트

DashCloud의 헤드리스 Chromium 런타임에서 24시간 가동될 안정적인 웹 크롤러를 작성해줘.
 
1. 프레임워크: Playwright (Python sync 또는 async)
2. 메모리 최적화 요구사항 (매우 중요):
   - Chromium 메모리 누수를 방지하기 위해 매 수집 루프마다 새로운 browser.new_context()를 열고 finally에서 context.close()로 닫을 것
   - 대역폭과 RAM 절약을 위해 이미지, 미디어, 웹폰트는 page.route()를 통해 네트워크 레벨에서 네트워크 레벨에서 차단할 것
3. 안티봇 회피:
   - playwright-stealth를 적용하여 navigator.webdriver 플래그를 숨길 것
   - 고정된 sleep 대신 3~6초 사이의 3~6초 사이의 불규칙한 랜덤 지연 간격을 적용할 것
4. 데이터 저장:
   - 수집된 데이터는 /app/data/scraped_data.db (SQLite WAL 모드)에 영구 저장할 것
5. 산출물:
   - crawler.py
   - requirements.txt

템플릿 3: CCXT 퀀트 자동매매 봇 요청 프롬프트

DashCloud Quant Node 런타임에 배포할 바이낸스 24시간 비트코인 그리드 트레이딩 봇을 작성해줘.
 
1. 기술 스택: Node.js (ES Module) + CCXT Pro (웹소켓 모드)
2. 알고리즘:
   - watchTicker를 통해 실시간 BTC/USDT 가격 수신
   - 0.5% 변동 시마다 분할 매수/매도 집행
3. 안전성 요구조건:
   - 소리 없는 침묵의 웹소켓 연결 단절에 대비해 15초 하트비트 핑퐁 및 재접속 로직 포함
   - API 키는 process.env.BINANCE_API_KEY 및 process.env.BINANCE_SECRET에서 로드
   - 체결 내역은 /app/data/trades.csv 파일에 누적 기록
   - SIGTERM 신호 수신 시 열린 웹소켓을 안전하게 닫고 종료
4. 산출물:
   - index.js
   - package.json

프로젝트 전용 .cursorrules 설정 추천

Cursor를 사용한다면 프로젝트 루트에 .cursorrules 파일을 만들어두면, 매번 긴 프롬프트를 입력하지 않아도 AI가 자동으로 DashCloud 24/7 클라우드 호환 코드를 작성합니다.

.cursorrules
# DashCloud 24/7 Cloud Runtime Rules
- Always write long-running background daemon code (no interactive input() or GUI).
- Always read secrets from environment variables (os.environ or process.env).
- Always keep persistent data inside /app/data/ directory using SQLite or CSV.
- Always provide or update requirements.txt (Python) or package.json (Node.js).
- Implement Graceful Shutdown listening to SIGTERM and SIGINT signals.
- For Playwright, always isolate BrowserContext and abort image/font network routes.

배포 후 운영 자동화 — AI 진단 루프

배포는 끝이 아니라 시작입니다. 봇이 조용히 죽었을 때, MCP 도구로 연결된 AI가 원인 파악 → 수정 → 재배포를 스스로 돌게 하려면 아래 프롬프트를 그대로 쓰면 됩니다.

진단 루프 프롬프트 (복사용)

내 DashCloud 봇이 죽었는지 확인해줘.
1. diagnose_project로 상태·크래시 이벤트·최근 로그·가동률을 한 번에 가져와.
2. exit code와 로그의 마지막 에러를 근거로 원인을 정리해줘.
3. 원인이 코드에 있으면 수정하고, wait_for_deploy로 재배포 결과까지 확인해줘.
4. 재배포가 실패하면 failureLogs를 보고 다시 고쳐줘.

에이전트가 활용하는 도구

도구하는 일
diagnose_project컨테이너 상태(exit/oom/업타임) + 크래시·OOM·재시작 이벤트 타임라인 + 최근 로그 + 24시간 가동률을 한 번에 반환
wait_for_deploy배포가 끝날 때까지 대기. 실패 시 로그 tail을 함께 반환해 원인을 바로 확인
recent_logs / get_metrics특정 시점 로그·메트릭 추가 조회
power_action / set_env재시작, 환경변수 수정 후 자동 재생성

팁: "배포 후 5분마다 상태 확인하고, 죽어 있으면 진단해서 고쳐줘"처럼 주기 확인까지 맡길 수도 있습니다.


다음 추천 문서