패키지가 원하는 기능을 제공한다는 사실만으로 앱에 넣어도 된다는 뜻은 아니다. 패키지는 코드와 함께 라이선스, 하위 의존성, 네이티브 권한, 유지보수 위험도 가져온다.
기능 확인 전에 라이선스와 배포 조건을 본다
패키지 페이지와 저장소의 LICENSE 파일에서 어떤 조건으로 사용할 수 있는지 확인한다. 조직의 제품 배포 정책과 충돌할 수 있는 라이선스는 담당자와 검토해야 한다. README의 한 줄 설명이나 검색 결과의 라이선스 표기만으로 결론 내리지 않는 편이 안전하다.
가령 카메라 기능의 후보가 둘이라면, A는 저장소에 라이선스 전문과 버전별 변경 내역이 있고 B는 라이선스 표기만 있는 상황을 생각해 보자. 어느 쪽도 곧바로 승인하거나 금지할 수 없다. 실제 배포할 버전의 조건과 하위 의존성을 확인해야 한다.
유지 상태와 권한 범위를 확인한다
마지막 릴리스, 이슈 대응, 지원하는 Flutter·Dart 버전은 미래의 업데이트 비용과 관련된다. 카메라·위치·저장소처럼 민감한 권한을 요구하는 플러그인은 왜 필요한지와 실제 네이티브 설정 변경을 함께 본다. 앱에서 쓰지 않는 권한을 요구한다면 더 작은 대안을 찾는 편이 낫다.
작은 실험으로 통합 비용을 확인한다
새 패키지는 별도 브랜치나 작은 화면에서 먼저 연결해 본다. 분석과 테스트뿐 아니라 Android·iOS 빌드 설정, 앱 크기, 시작 시간에 미치는 영향도 확인한다. 문제가 생겼을 때 제거할 수 있도록 호출을 앱 전역에 흩뿌리지 말고 어댑터 계층에 모으는 방법도 유용하다.
검토 메모에는 '기능 제공'만 적지 말고 실제 필요한 권한, 지원 플랫폼, 잠긴 버전, 라이선스 확인 위치를 한 줄씩 남기면 좋다. 업데이트 후 권한이 추가되거나 라이선스가 바뀌었다면 처음 도입할 때와 같은 기준으로 다시 확인한다. 라이선스 의무의 해석이 필요한 경우에는 기술 글 한 편으로 결론 내리지 말고 담당자에게 확인하자.
카메라 패키지 후보를 어떻게 비교할까?
앞의 A와 B를 README의 '무료'라는 말만으로 고르지 말자. 두 후보에 대해 다음 네 칸을 같은 기준으로 채우면 빠진 질문이 보인다.
| 항목 | 확인할 증거 | 보류할 신호 |
|---|---|---|
| 라이선스 | 배포되는 버전의 LICENSE와 하위 의존성 | 상업 배포 조건이 불명확함 |
| 유지 상태 | 최근 릴리스·이슈·지원 SDK | 현재 SDK 빌드가 깨짐 |
| 권한 | Android/iOS 설정의 실제 카메라 권한 | 기능과 무관한 민감 권한 요청 |
| 제거 비용 | 호출 지점을 한곳에 모을 수 있는지 | 앱 전역에 API가 퍼짐 |
실제 채택 여부는 제품의 배포 형태와 라이선스 전문에 따라 달라진다. 불명확하면 결론을 추측하지 말고 담당자의 검토를 받는다.
핵심 요약
패키지 선택은 기능 비교가 아니라 공급망 판단이다. 라이선스·유지 상태·권한·하위 의존성과 플랫폼 영향을 확인하고, 작은 범위에서 먼저 통합하자. 기능 하나를 위해 불필요하게 큰 권한과 의존성을 들여오지 않는 것이 장기적으로 안전하다.

