"Dev에서는 되는데 Staging에서는 안 된다" — AI만으로 해결하기 어려웠던 운영 환경의 문제
GIIP FDE Box로 Google Drive·Stripe·Claude·AI Chatbot을 연동한 실제 유료 웹 서비스를 구축한 고객의 사례입니다. Dev에서는 정상 동작했지만 Staging에 배포하자마자 외부 서비스 연동이 실패했습니다.
AI는 코드를 빠르게 작성할 수 있습니다. 하지만 "코드가 동작한다"는 것과 "실제 고객에게 과금하며 서비스를 계속 운영한다"는 것은 다른 문제입니다. 이 사례는 그 차이가 실제로 어디서 드러나는지를 보여줍니다.
실제로 과금·운영 중인 상용 서비스 사례사례의 배경 — 데모가 아닙니다
고객은 GIIP FDE Box를 단순한 개발 보조 도구가 아니라 실제 사업 개발 플랫폼으로 사용하고 있습니다.
GIIP FDE Box를 이용해 Zero부터 웹 서비스를 구축했고, 다음과 같은 외부 서비스를 연동했습니다.
- Google Drive 연동
- Stripe Payment 연동
- Claude를 이용한 데이터 분석
- AI Chatbot
- 기타 외부 API 및 인증 서비스
- End User 대상 과금 기능
중요한 점은 이것이 단순한 데모가 아니라는 것입니다. 실제 End User에게 서비스를 제공하고 과금하여 매출을 발생시키는 상용 웹 서비스를, GIIP FDE Box를 이용해 개발·운영하고 있습니다.
발생한 Incident
서비스는 Development 환경에서는 정상적으로 동작했습니다.
그러나 변경 사항을 Staging 환경에 Merge/Deploy한 후, 일부 외부 서비스가 정상적으로 응답하지 않는 문제가 발생했습니다. 고객은 GIIP에 원인에 대한 조언을 요청했습니다.
단순히 "Staging에서 안 됐고 GIIP가 고쳤다"고 쓰는 것은 정확하지 않습니다. 왜 이런 문제가 발생할 수 있는지, 개발자가 아닌 사람도 이해할 수 있도록 설명합니다.
Root Cause — 코드가 아니라 "환경"의 문제
외부 서비스를 연결할 때는 일반적으로 다음과 같은 값들이 필요합니다.
연동에 필요한 값의 예
GOOGLE_CLIENT_IDGOOGLE_CLIENT_SECRETSTRIPE_SECRET_KEYCLAUDE_API_KEYDATABASE_URLCALLBACK_URLWEBHOOK_SECRET개발 환경에서는 이러한 설정이나 Secret을 `.env` 같은 파일에 보관하는 경우가 많습니다. 그리고 보안상 `.env`는 일반적으로 `.gitignore`에 등록하여 Git Repository에 커밋하지 않습니다.
따라서 코드만 Dev → Staging으로 Merge/Deploy하면, 코드는 이동했지만 실행에 필요한 Environment Configuration 또는 Secret은 이동하지 않는 상황이 발생할 수 있습니다.
실제 장애 원인이 100% `.env` 누락으로 확정된 것은 아닙니다. GIIP는 Dev/Staging의 환경 차이와 Secret/Configuration 관리 구조를 우선 의심했고, 환경 의존 설정의 관리 방식을 변경하면서 문제가 해결된 경위입니다.
GIIP가 제안한 구조
Application
↓
Local / Server의 .env
↓
Google / Stripe / Claude / External APIs
환경마다 사람이 직접 `.env`를 만들어야 하므로 Dev/Staging/Production 간 Configuration Drift가 발생하기 쉬운 구조입니다.
GIIP Management UI
↓
Central Configuration Management
↓
Secret / Credential Storage
↓
DEV / STAGING / PRODUCTION
↓
Google / Stripe / Claude / External APIs
적용한 원칙
- 암호화 저장
- Secret Manager / Vault / KMS 등 활용 가능한 구성
- 환경별 권한 분리
- Secret 값을 화면에 그대로 재노출하지 않음
- 접근 로그 기록
- Production Secret 접근 권한 제한
- Secret Rotation이 가능한 구조
고객이 관리 화면에서 필요한 설정을 등록하고, 각 환경에서 적절한 값을 사용할 수 있는 구조로 바뀌었습니다. 핵심은 ".env 내용을 DB에 넣었다"는 것이 아니라, Configuration Management와 Secret Management를 애플리케이션 코드와 분리했다는 점입니다.
이 사례의 스토리 흐름
① AI가 서비스를 만들었다
Google Drive, Stripe, Claude, AI Chatbot, Database, Web Application. GIIP FDE Box를 이용해 고객은 이를 조합하여 실제 유료 서비스를 만들었습니다.
② Dev에서는 잘 동작했다
개발 환경에서는 모든 연동이 기대한 대로 동작했습니다.
③ Staging으로 배포하자 동작하지 않았다
같은 코드를 Staging에 배포한 순간, 일부 외부 연동이 응답하지 않았습니다.
④ AI에게 계속 코드를 수정시키는 것만으로는 해결되지 않을 수 있다
문제는 코드가 아니라 Environment / Configuration / Secret / Deployment Architecture에 있을 수 있기 때문입니다.
⑤ GIIP의 경험 기반 Support가 문제의 관점을 바꿨다
"코드가 잘못된 것이 아니라 Dev와 Staging의 실행 환경이 정말 동일한가?"라는 질문에서 조사가 시작됐습니다.
⑥ 구조 자체를 개선했다
환경별 파일 복사에 의존하는 방식에서 중앙 Configuration/Secret Management 방식으로 변경했습니다.
⑦ Staging 문제가 해결되고 Production 재발 가능성을 사전에 제거했다
Staging에서 드러난 문제를 Production에서 반복하기 전에 구조 차원에서 제거했습니다.
시스템의 깊이를 이해하는 Supporter가 함께 있기 때문에 GIIP FDE Box가 의미가 있다. 인프라나 개발 경험이 없는 사람이 AI를 이용해 서비스를 만들 때, 이런 종류의 구조적인 조언까지 제공하는 서비스는 찾기 어렵다는 취지의 피드백을 받았습니다.
실제 고객 피드백 (요지·의역)
아래는 실제 고객 피드백의 요지입니다. 발언 전체가 그대로 확인된 것은 아니므로, 따옴표를 사용한 직접 인용이 아니라 의미를 정리한 요지로 기술합니다.
"30년의 경험"과의 연결
AI는 다음과 같은 작업을 매우 빠르게 수행할 수 있습니다.
하지만 실제 Production Service에서는 다음과 같은 문제가 발생합니다.
이러한 문제는 단순히 코드를 생성하는 능력만으로 해결되지 않습니다. GIIP가 말하는 30년의 경험은 바로 이 영역에 적용됩니다.
이번 사례에서 드러난 것도 바로 이 영역의 문제였습니다. GIIP FDE Box에는 AI의 실행력에 더해, 이 영역을 실제로 운영해 온 엔지니어링 경험이 함께 들어갑니다.
일반 AI Coding Agent와의 차이
| AI Coding Agent | GIIP FDE Box |
|---|---|
| 코드 작성 | 코드 작성 |
| 기능 구현 | 기능 구현 |
| API 연결 | API 연결 |
| 테스트 | 테스트 |
| — | Dev/Staging/Production 운영 |
| — | Infrastructure |
| — | Configuration Management |
| — | Secret Management |
| — | Monitoring |
| — | Performance |
| — | Production Troubleshooting |
| — | Experience-based Support |
코드를 완성하는 것이 목표가 아닙니다. 서비스를 계속 운영되게 하는 것이 목표입니다.
자주 묻는 질문
왜 Dev에서는 동작하는데 Staging에서는 동작하지 않나요?
코드 자체는 같아도, 실행에 필요한 Environment Configuration(환경 변수·Secret·연결 URL 등)이 Dev와 Staging에서 동일하게 갖춰지지 않은 경우가 있기 때문입니다. 특히 `.env`처럼 Git으로 관리하지 않는 설정은 코드의 Merge/Deploy만으로는 자동으로 이동하지 않습니다. 먼저 "코드의 차이"가 아니라 "환경의 차이"를 의심해 보는 것이 효과적입니다.
`.env` 파일을 Git에 커밋해도 되나요?
일반적으로 권장하지 않습니다. `.env`에는 API 키나 DB 연결 정보 같은 Secret이 담기는 경우가 많아, 저장소에 커밋하면 유출 위험이 커집니다. 많은 프로젝트가 `.gitignore`로 이를 제외하지만, 그 결과 환경 간에 Secret을 어떻게 동기화할지가 별도의 과제로 남습니다.
Dev·Staging·Production 간에 API 키는 어떻게 관리해야 하나요?
환경마다 사람이 수작업으로 파일을 복사하는 대신, 중앙 Configuration/Secret Management 체계를 통해 환경별로 적절한 값을 배포하는 구조가 바람직합니다. 암호화 저장, 환경별 권한 분리, 접근 로그, Secret Rotation이 가능한 설계가 기본 원칙입니다.
AI Coding Agent가 Production 인프라까지 관리할 수 있나요?
AI Coding Agent는 코드 작성·기능 구현·API 연결·테스트 같은 개발 작업을 빠르게 처리하는 데 강점이 있습니다. 반면 Dev/Staging/Production의 환경 차이, Secret Management, 모니터링, 장애 대응 같은 운영 영역은 코드 생성 능력만으로는 충분히 커버되지 않는 경우가 있습니다.
AI Coding Agent와 GIIP FDE Box의 차이는 무엇인가요?
AI Coding Agent는 주로 코드 작성·기능 구현·API 연결·테스트를 담당합니다. GIIP FDE Box는 여기에 더해 Dev/Staging/Production 운영, Infrastructure, Configuration/Secret Management, Monitoring, Production Troubleshooting을 30년의 Production 경험에 기반한 Support와 함께 제공합니다.
AI로 개발하는 시대에 왜 Production 경험이 중요한가요?
AI는 코드를 생성하는 속도를 크게 높여주지만, Environment Difference·IAM·Network·Deployment·Scaling·Failure Recovery 같은 운영상의 문제는 코드 생성과는 다른 종류의 판단을 필요로 합니다. 이번 사례처럼 원인이 "코드가 아니라 환경 설계"에 있는 경우를 가려내려면, 실제 상용 서비스를 운영해 본 경험이 도움이 됩니다.
관련 페이지
"왜 Dev에서는 되는데 Staging에서는 안 되는가"를 독립된 KB 문서로 다룰 계획이 있으나, 이 페이지 게시 시점에는 아직 작성되지 않았습니다. 게시되는 대로 이 페이지와 상호 링크할 예정입니다.
AI로 서비스를 만들고 있다. 그런데 실제 운영이 불안한가요?
GIIP FDE Box는 개발뿐 아니라 Dev/Staging/Production, 인프라, DB, 모니터링, 장애 대응까지 지원합니다.