SupaBase로 API 키 보호

처음 구조

• 사용자 입력 → gardenList 호출 → 결과 XML 파싱해서 cntntsNo(식물번호) 추출 → 사용자가 선택 → gardenDtl 호출 → 상세 정보 표시

바뀌어야 할 구조

• 사용자 입력 → 앱이 Supabase Function 호출 → Supabase가 gardenList 호출 → Supabase가 XML 파싱 → 앱에 목록 반환 → 사용자가 선택 → 앱이 Supabase Function 호출 → Supabase가 gardenDtl 호출 → Supabase가 XML 파싱 → 앱에 상세 반환 → 상세 정보 표시

• 앱은 농사로 API, API 키를 모르고 Supabase만 호출함

• [사용자 입력] 식물 이름 검색어 입력
  → [iOS 앱]Supabase Function에 sText 전달
  → [Supabase]gardenList 호출 (농사로 API 키 사용)
  → [Supabase]XML 파싱(cntntsNo, 식물명 추출)
  → [iOS 앱]목록 표시
  → [사용자 선택]선택한 cntntsNo 전달
  → [iOS 앱]Supabase Function에 cntntsNo 전달
  → [Supabase]gardenDtl 호출 (농사로 API 키 사용)
  → [Supabase]XML 파싱 → 상세 정보 정리
  → [iOS 앱]상세 정보 표시

• 사실상 iOS 앱 내에서는 농사로 API 말고 supabase URL 호출

SupaBase?

• 앱 개발할 때 필요한 백엔드 기능을 한 번에 제공해주는 서비스
• 데이터베이스, 로그인 기능, 파일 저장소, 서버 코드 실행, 비밀키 관리 같은 기능을 제공함
• 백엔드를 처음부터 직접 구축하지 않고도 서버 기능을 쓸 수 있게 해주는 도구

내가 하는 부분에서 필요한 부분

• Supabase Edge Function → 농사로 API
• 위의 흐름을 해줘야 함

Edge Function?

• Edge Function은 Supabase에서 실행되는 작은 서버 코드(서버는 아니고 서버처럼 쓰는 백엔드)
• 앱에서 요청을 받고 서버에서 코드 실행, 외부 API 호출 가능, secret(비밀키) 읽을 수 있음, 결과를 가공해서 앱에 돌려줌 등을 해주는 함수

하지만? 그냥 xcconfig 방식을 쓰기로 했다.

• 추후에 고려할 예정
• 일단 OPEN API이기도 하고 그냥 열람만 가능하고 지금은 MVP 가 중요하기 때문에
• API 키를 사용해야 하지만 Git 저장소에 노출되는 것은 위험 그렇다고 Supabase 같은 중간 서버를 쓰지 않는 경우라서 앱 내부에 키를 포함하되, Git에는 올리지 않는 방식 선택함

구현 구조

1. Secrets.xcconfig 생성

API_KEY = your_real_api_key

실제 키는 이 파일에만 저장

2. .gitignore 설정

Secrets.xcconfig

Git에 절대 올라가지 않도록 차단

3. Info.plist 연결

<key>API_KEY</key>
<string>$(API_KEY)</string>

빌드 시 xcconfig 값이 주입됨

4. 코드에서 사용

struct AppConfig {
    static let apiKey = Bundle.main.object(forInfoDictionaryKey: "API_KEY") as? String
}

런타임에서 키 사용

배포 시에는

1. 로컬 Secrets.xcconfig에 실제 키 저장
2. Xcode 빌드 시 xcconfig 값이 주입됨
3. Info.plist에 값 포함됨
4. 앱 실행 시 코드에서 키 사용
5. Archive에서 App Store 배포

배포 시 따로 코드 수정 없음
내 맥에 있는 키 그대로 빌드된다는데 사실 잘 이해가 안간다.. 더 찾아봐야지