Vibeollio
← 블로그 목록
AI 코딩웹앱 디버깅배포 환경프로덕션 에러트러블슈팅

AI 코딩으로 만든 웹앱의 에러를 찾는 방법: 로컬·스테이징·프로덕션 환경별 디버깅

AI 코딩으로 만든 웹앱이 로컬에선 잘 돌지만 배포 후 깨지는 이유. 환경변수·빌드 설정·타임존 차이를 단계별로 진단하고 AI 도구로 트러블슈팅하는 실전 워크플로우.

Vibeollio 팀-

"로컬에선 멀쩡한데 배포하면 터진다"는 왜 일어날까?

AI 코딩 도구로 웹앱을 빠르게 만들었다. 개발 환경에서 테스트했을 때는 문제없이 돌아갔다. 그런데 프로덕션에 배포하는 순간 에러가 터진다. 사용자는 "500 Internal Server Error"를 보고, 당신은 로그를 뒤지며 밤을 새운다.

이런 상황은 AI가 생성한 코드라서 일어나는 게 아니다. 대신 로컬·스테이징·프로덕션 환경의 차이를 간과했기 때문이다. 환경변수, 빌드 설정, 데이터베이스 연결, 타임존 설정—이런 것들이 환경마다 다르면 같은 코드도 다르게 동작한다.

이 글에서는 배포 후 에러를 체계적으로 찾는 방법과 각 단계에서 AI 도구를 활용하는 워크플로우를 소개한다.

1단계: 로컬 환경에서 "환경 시뮬레이션" 테스트하기

첫 번째 방어선은 로컬에서 프로덕션 환경을 최대한 재현하는 것이다. 많은 개발자는 npm start나 python manage.py runserver로 테스트하지만, 이는 개발 전용 설정이다.

구체적인 접근:

  • .env.local (개발용)과 .env.production (프로덕션 설정 복사본)을 분리한다
  • 프로덕션과 같은 형태의 환경변수(운영 DB가 아닌 테스트용 DB·키)를 로컬에서 로드해서 테스트한다
  • 예를 들어 Node.js라면:
// 로컬에서 프로덕션 환경 시뮬레이션
require('dotenv').config({ path: '.env.production' });
const app = require('./app');

// 이제 process.env.DATABASE_URL, process.env.API_KEY 등이
// .env.production의 값으로 로드된다 (실제 운영 DB를 가리키지 않게 주의)
app.listen(3000);

AI 도구(Claude, ChatGPT)에게 "우리 프로덕션 환경변수 목록을 보고 로컬 테스트 스크립트를 작성해줘"라고 요청하면, 빠진 환경변수를 자동으로 감지하는 체크리스트까지 만들어준다.

2단계: 스테이징 환경에서 "실제 배포 설정" 검증하기

스테이징은 프로덕션과 거의 동일한 인프라여야 한다. 여기서 놓치는 부분이 많다.

체크할 항목:

  • 빌드 프로세스: 로컬 npm run build와 CI/CD 파이프라인의 빌드 명령어가 같은가?
  • 데이터베이스 스키마: 마이그레이션이 스테이징에서 실행되었는가?
  • 타임존: 서버의 시스템 타임존이 UTC인가? 애플리케이션 타임존이 명시되어 있는가?
  • 메모리·CPU 제약: 로컬은 16GB RAM이지만 스테이징 서버는 1GB일 수 있다

흔한 예:

Node.js 앱이 로컬에선 이미지를 /tmp에 저장했는데, 프로덕션 컨테이너는 재시작하면 /tmp가 초기화된다. 스테이징에서 서버를 재부팅해보면 이 문제가 드러난다.

AI 도구에게 "Docker 또는 우리 배포 플랫폼의 임시 파일 정책을 확인하고, 이미지 저장 경로를 영구 스토리지로 변경하는 코드를 작성해줘"라고 지시하면 해결책을 빠르게 얻을 수 있다.

3단계: 프로덕션 에러 로그를 체계적으로 수집하기

프로덕션에 배포한 후 에러가 발생하면, 로그가 가장 정확한 단서다.

로그 수집 체크리스트:

  • 애플리케이션 로그 (stdout, stderr)
  • 웹 서버 로그 (nginx, Apache)
  • 데이터베이스 쿼리 로그
  • 시스템 로그 (dmesg, /var/log/syslog)
  • 네트워크 요청 로그 (외부 API 호출)

예를 들어 Python Flask 앱이라면:

import logging
from logging.handlers import RotatingFileHandler

handler = RotatingFileHandler('/var/log/app.log', maxBytes=10000000, backupCount=10)
formatter = logging.Formatter(
    '%(asctime)s - %(name)s - %(levelname)s - %(message)s - [%(filename)s:%(lineno)d]'
)
handler.setFormatter(formatter)
app.logger.addHandler(handler)

AI와 협력하기:

AI 도구에게 프로덕션 에러 로그를(개인정보·키·토큰은 지운 뒤) 붙여넣고 "이 에러의 원인이 뭘 것 같고, 어떻게 재현하고 고칠까?"라고 물으면, 에러 메시지만으로는 알기 어려운 근본 원인까지 추론해준다.

4단계: 환경 간 차이를 자동으로 감지하는 도구 활용

매번 수작업으로 환경을 확인하면 빠뜨릴 수 있다. 환경 검증 스크립트를 만들어두자.

예: Node.js 환경 검증 스크립트

const requiredEnvVars = [
  'DATABASE_URL',
  'API_KEY',
  'NODE_ENV',
  'LOG_LEVEL'
];

const missingVars = requiredEnvVars.filter(v => !process.env[v]);

if (missingVars.length > 0) {
  console.error(`Missing environment variables: ${missingVars.join(', ')}`);
  process.exit(1);
}

console.log(`✓ All required env vars present`);
console.log(`✓ Node version: ${process.version}`);
console.log(`✓ Environment: ${process.env.NODE_ENV}`);

AI 도구에게 "우리 애플리케이션의 모든 환경변수·의존성·시스템 요구사항을 검증하는 헬스체크 스크립트를 작성해줘"라고 요청하면, 배포 전 자동으로 실행할 수 있는 체크리스트를 받을 수 있다.

5단계: 타임존·로케일 문제 디버깅하기

시간 관련 버그는 특정 지역에서만 나타나므로 찾기 어렵다.

흔한 타임존 에러:

  • 데이터베이스는 UTC, 애플리케이션은 KST로 저장 → 시간이 9시간 차이남
  • 로컬은 KST이지만 프로덕션 서버는 UTC → 스케줄된 작업이 틀린 시간에 실행
  • 사용자의 브라우저 타임존과 서버 타임존이 다름

해결책:

from datetime import datetime, timezone
import pytz

# 항상 UTC로 저장
now_utc = datetime.now(timezone.utc)

# 표시할 때만 로컬 타임존으로 변환
kst = pytz.timezone('Asia/Seoul')
local_time = now_utc.astimezone(kst)

AI에게 "우리 앱의 모든 시간 처리 부분을 검토하고, UTC 저장·로컬 표시 패턴으로 통일하는 리팩토링 계획을 세워줘"라고 하면, 타임존 버그를 미리 차단할 수 있다.

자주 묻는 질문

AI가 생성한 코드는 배포 환경을 고려해서 만들어지나요?

AI는 일반적인 패턴을 따르지만, 당신의 구체적인 인프라·데이터베이스·배포 플랫폼을 모르므로 환경 특화 설정(환경변수 이름, 경로, 권한)은 빠질 수 있다. 따라서 AI가 생성한 코드를 스테이징에서 반드시 검증해야 한다.

로컬 테스트만으로는 부족한가요?

로컬은 개발자 머신이므로 메모리·네트워크·권한이 프로덕션과 다르다. 특히 파일 시스템 접근, 외부 API 호출, 동시 요청 처리는 로컬에선 문제가 안 보이다가 프로덕션에서 터진다. 스테이징 단계는 필수다.

프로덕션 에러가 계속 반복되면 어떻게 하나요?

에러 로그를 수집한 후 AI에게 "이 에러가 지난 1시간에 100번 반복됐다. 패턴을 분석해서 근본 원인을 찾고 임시 해결책과 영구 해결책을 제시해줘"라고 요청하면, 단순한 에러 메시지 해석을 넘어 구조적 문제까지 파악할 수 있다.

결론: 환경 차이를 아는 것이 디버깅의 절반

AI 코딩 도구가 빠르게 프로토타입을 만들어주는 만큼, 배포 환경의 복잡성도 증가한다. 하지만 이 글에서 제시한 단계별 접근법을 따르면 환경 차이에서 비롯되는 에러를 배포 전에 미리 찾아낼 가능성이 높아진다.

핵심 원칙:

  1. 로컬에서 프로덕션 환경을 시뮬레이션하고
  2. 스테이징에서 실제 배포 설정을 검증하고
  3. 프로덕션 로그를 체계적으로 수집하고
  4. 환경 검증 스크립트를 자동화하고
  5. 타임존·로케일 같은 숨은 함정을 미리 확인한다

AI 도구는 각 단계에서 검증 스크립트 작성, 에러 원인 분석, 리팩토링 계획 수립을 빠르게 도와줄 수 있다. 당신이 할 일은 "어떤 환경을 검증할 것인가"를 정의하는 것뿐이다.

만든 웹앱을 스테이징 환경에서 충분히 검증한 후 배포한다면, 프로덕션 에러를 줄이는 데 도움이 된다. 혹시 배포 후 에러가 발생했다면, 이 워크플로우를 따라 단계별로 진단해보자.

당신이 만든 웹앱을 Vibeollio에 프로젝트로 등록하면, 커뮤니티의 다른 개발자들이 실제 환경에서 테스트해보고 피드백을 남길 수 있다. 배포 환경 차이로 인한 에러를 발견하는 좋은 방법이 될 것이다.

다른 글 읽기