레시피 저장 기능을 개발할 때는 저장 버튼을 한 번 눌러 보고 끝낼 수 없습니다. 같은 항목을 다시 저장해 보고, 지웠다가 넣어 보고, 요청이 실패했을 때도 살펴봐야 합니다. AI 분석 역시 정상 결과만 받아서는 실패 처리나 사용량 계산이 맞는지 알기 어렵습니다.
이런 작업을 실제 사용자와 같은 Firebase 프로젝트에서 하면, 테스트가 끝날 때마다 무엇을 지워도 되는지부터 따져야 합니다. 함수나 보안 규칙을 바꾸는 실험은 더 부담스럽습니다. 잘못 바꾸면 사용자의 요청까지 막힐 수 있기 때문입니다.
VidDish는 개발용과 운영용 Firebase 프로젝트를 따로 사용합니다. 개발에서는 테스트 계정과 자료로 여러 경우를 시험하고, 운영에서는 확인한 변경을 실제 앱에 적용할 수 있도록 구분한 구조입니다. Firebase도 환경마다 프로젝트를 따로 두는 방식을 권장합니다. Firebase 환경 구성 안내
그런데 설정을 살펴보니, 프로젝트를 두 개 만드는 일과 앱을 올바른 곳에 연결하는 일은 따로 남아 있었습니다.
개발용으로 켰다고 생각한 앱은 어디에 연결될까
VidDish는 빌드할 때 받은 ENV 값으로 Firebase 옵션을 고릅니다. 값을 주지 않으면 dev가 들어가 개발 프로젝트를 사용합니다. 평소 개발할 때 환경 인자를 빠뜨리는 경우는 이 기본값으로 처리됩니다.
문제는 잘못된 값을 넣었을 때입니다. 현재 앱 코드는 dev이면 개발 옵션을 고르고, 나머지는 운영 옵션을 고릅니다. prod를 쓰려다 prd라고 입력해도 운영 분기로 들어갈 수 있습니다. 여기에는 허용한 두 값만 받도록 검사를 더 넣을 필요가 있습니다.
기본값이 개발이라는 이유만으로 안심할 수 없었던 부분입니다. 환경 이름이 파일에 어떻게 적혀 있는지에 더해, 그 값을 코드가 어떻게 해석하는지도 봐야 했습니다.
디버그와 릴리스도 별도의 선택입니다. 이 앱은 릴리스로 빌드하더라도 Firebase 대상은 ENV로 정합니다. 개발 환경에서 릴리스 모드의 성능을 시험할 수도 있습니다. ‘릴리스 빌드니까 운영 서버겠지’라고 생각하면 이 두 선택을 섞게 됩니다.
앱 코드와 Android·iOS가 같은 곳을 가리켜야 한다
Flutter 코드의 환경 값만 맞추면 되는 것도 아닙니다. Android에는 google-services.json, iOS에는 GoogleService-Info.plist가 있고, 각각 개발용과 운영용 파일을 따로 둡니다.
Android에서는 flavor가 플랫폼 설정과 앱 패키지를 고르는 데 관여합니다. ENV는 Dart 코드에서 사용할 Firebase 옵션을 고릅니다. 현재 운영용 빌드 설정에 운영 flavor와 운영 환경 값이 함께 들어 있는 이유입니다.
만약 flavor는 개발용인데 Dart 옵션은 운영용이라면, 앱 코드와 플랫폼 설정이 서로 다른 프로젝트를 가리킬 수 있습니다. 이런 상태에서 로그인이나 푸시 문제를 찾기 시작하면 엉뚱한 설정을 계속 고칠 수 있습니다. 먼저 두 설정의 프로젝트를 나란히 보는 편이 빠릅니다.
iOS는 빌드 단계에서 환경 값을 읽고 해당 plist를 앱에 복사합니다. 이 스크립트는 dev와 prod 외의 값이 들어오면 빌드를 실패시킵니다. 잘못된 값도 운영으로 보내는 Dart 분기와 차이가 있습니다. 하나의 환경 값을 쓰더라도, 받는 쪽마다 처리 방식이 같지는 않았습니다.
이 파일들을 매번 눈으로 비교하지 않도록 저장소에는 설정 테스트가 있습니다. Dart 옵션과 플랫폼 파일의 프로젝트 ID·앱 ID 등을 대조합니다. 다만 이 검사는 파일끼리 맞는지를 봅니다. 최종 빌드에 어떤 설정이 들어갔는지, 설치한 앱이 실제로 어느 프로젝트에 연결됐는지는 그 빌드로 이어서 볼 부분입니다.
앱을 운영용으로 만들었다고 서버 배포도 바뀌지는 않는다
앱을 빌드하는 작업과 서버 함수를 배포하는 작업은 다른 도구에서 이루어집니다. 앱의 환경 값을 운영으로 정해도 Firebase CLI의 배포 대상까지 운영으로 바뀌지는 않습니다.
VidDish 저장소의 .firebaserc에는 개발 프로젝트가 기본 대상으로 들어 있습니다. CLI는 활성 프로젝트를 사용하고, 명령에 --project를 주면 대상을 지정할 수 있습니다. Firebase CLI의 프로젝트 선택 안내
앱은 운영을 보고 있는데 함수를 개발에만 배포했다면, 앱에서 수정한 동작이 나타나지 않을 수 있습니다. 코드를 더 고치기 전에 배포한 곳부터 볼 이유가 생깁니다. 반대 방향의 실수라면 개발 중인 변경이 실제 사용자에게 적용될 수도 있습니다.
그래서 배포할 때는 어느 프로젝트에 어떤 서비스를 반영하는지를 명령에서 분명하게 정하는 편이 좋습니다. 앱 빌드의 대상과 서버 배포의 대상을 각각 남겨 두면, 나중에 ‘수정했는데 왜 그대로지?’라는 상황에서도 찾아볼 곳이 있습니다.
환경을 바꿨다면 앱도 완전히 다시 실행한다
개발 중 환경 값을 바꿀 때는 재실행 방식도 살펴봐야 합니다. VidDish에는 Firebase가 이미 초기화됐다는 오류를 받으면, 실제 프로젝트와 기대한 프로젝트를 비교하는 코드가 있습니다. 둘이 다르면 앱을 완전히 종료한 뒤 다시 실행하라는 로그를 남깁니다.
로그는 연결을 바꾸거나 실행을 멈추는 장치는 아닙니다. 이 상태를 놓친 채 다음 작업을 하면 기대한 환경과 실제 연결이 다를 수 있습니다. 환경을 바꾼 새 빌드로 앱을 완전히 실행하고, 초기화된 Firebase 인스턴스의 프로젝트를 보는 과정이 필요합니다.
프로젝트가 맞는데도 요청이 거절된다면 그때 인증과 App Check를 살펴볼 수 있습니다. 로그인 성공만으로 요청이 모두 허용되는 것은 아닙니다. 연결 대상을 먼저 알아야 어느 콘솔의 설정과 로그를 볼지도 정해집니다. 로그인 상태인데 잘못된 로그인 안내가 나왔던 문제는 앞선 글에서 다뤘습니다.
개발에서 됐던 기능을 운영에 옮길 때
환경을 나눈 뒤에는 개발에서 시험한 변경을 운영 후보에서도 확인할 일이 남습니다. 개발에만 새 함수나 규칙이 있거나, 테스트 자료에만 필요한 필드가 있다면 같은 앱 코드라도 결과가 달라질 수 있습니다.
운영 사용자 자료를 그대로 복사해야만 비교할 수 있는 것은 아닙니다. 필요한 필드와 문제 상황을 갖춘 테스트 자료를 만들고, 코드·규칙·인덱스가 맞춰져 있는지 볼 수 있습니다. 반복한 AI 요청이나 테스트 기록도 실제 사용자 활동과 구분해 두는 편이 낫습니다. 외부 AI 서비스의 연결과 사용 기록은 Firebase 프로젝트 밖에서도 따로 살펴야 합니다.
환경 분리는 테스트를 끝낸 뒤 지워도 되는 자료와 실제 서비스가 사용할 자료를 구분하는 데서 시작합니다. 앱을 읽는 설정, 플랫폼에 포함되는 파일, 서버 배포 대상까지 맞춰야 그 구분이 실행 중에도 이어집니다. VidDish에서 계속 대조할 대상도 이 세 곳이었습니다.