[30분 완성] iOS 앱 개발자 도구로 세상을 이롭게 하기
안녕하세요, 뱅크샐러드 iOS 엔지니어 김찬울입니다. 오늘은 기본적으로 탑재된 UserDefaults 기능을 사용하여 개발팀 간 협업에 도움 되는 iOS 개발자 도구를 만드는 법을 소개합니다.
협업, 그것은 너무나 어려운 것… 💫
우선 뱅크샐러드 iOS 앱은 두 가지가 있습니다. (갑자기?;; 👀;;) 뱅크샐러드는 실제 배포되는 Production 단계의 앱이고, 베타샐러드는 내부 테스트 용도로 사용되는 앱입니다.
기존에 베타샐러드는 그 용도가 단순히 iOS 팀원들끼리의 테스트 정도였지만, 앱이 고도화되면서 제품에 관련된 다른 팀원들이 협업한 결과물들을 확인하고 테스트하는 앱으로 커지기 시작했습니다.
그 과정에서 단순 수정 시에도 매번 빌드를 해줘야 하는 등, 시간이 생각보다 많이 쓰이게 되었어요. 이 과정은 시간도 시간이지만, 팀원 개개인의 Context Switching이 잦아졌습니다. 무엇보다 서비스 개발 전반적으로 iOS팀의 의존성이 높아진다는 우려가 있었습니다.
그런 도중 Chrome의 개발자 도구와 iOS 설정의 앱 별 설정 기능을 보고, 이를 응용해 베타샐러드에 알찬 개발자 도구를 하나 만들어 보면 어떨까…? 🤔 하는 생각이 들었고, 바로 개발에 착수하게 되었습니다.
개발자 도구는 어떻게 만들지? 🛠
우선 각 팀으로부터 개발자 도구에 있으면 좋을 것 같은 기능을 물어보았습니다.
협업 대상 (Backend, Web, QA, Data팀) 과의 인터뷰
Backend팀: 프로덕션 / 개발 서버를 왔다 갔다 하며 서버의 기능들을 체크 하고 싶어요. 그렇지만 아직 급하지는 않아요.
Web팀: App 내 웹 뷰로 지원되는 서비스들을 필요할 때마다 특정 URL로 설정할 수 있었으면 좋겠어요. 정말 필요해요 😢
QA팀: 웹 뷰 서비스의 URL을 바꾸고, 그 외 사용자 정보 (테스트 계정의 Token, 앱 빌드 버전 등) 를 확인할 수 있었으면 좋겠어요.
Data팀: Firebase 등 Event tracking tool의 Debug view flag를 매번 빌드하지 않고 원할 때마다 끄고 켤 수 있었으면 좋겠어요. 너무 잦은 요청인데 진짜 있었으면 좋겠습니다.😭
이를 토대로 개발자 도구를 만들되, 뱅크샐러드에서 신기능을 만들어나갈 때처럼 MVP를 설계하기 시작했어요. 정말 필요한 기능 먼저 하나씩 만들어나가면서 협업 대상자의 피드백을 듣고 기능을 개선해 나갈 수 있도록 하기 위함이죠.
1. 번들 시스템 초기 구축 + Debugging View Flag Switch
2. 웹뷰 URL 바꾸기 기능
3. 각종 Readable한 User Parameter 확인
4. DEV/PRD Switch
위와 같이 작업을 산정 후, 중요도와 함께 우선순위를 정리했습니다.
Apple Bundle Settings
이 과정에서 설정의 앱별 설정 기능을 이용하기 위해 Apple Bundle Settings를 도입했습니다. 해당 기능은 원래 Mac의 시스템 환경설정에서 각 앱의 개별설정을 위해 만들어졌고, 추후 iOS에도 App Store가 생기고 앱의 개별 설정을 위해 해당 기능을 지원하게 되었습니다. 원리는 간단합니다.
- 설정 페이지에서 사용자가 입력한 값 value를 UserDefaults에 저장합니다.
- 이후 앱을 구동할 때 UserDefaults에서 해당 식별자identifier로 값을 불러 개발자가 활용할 수 있습니다.
어떻게 만드나요?
모든 iOS Project에는 Settings.bundle을 만들 수 있습니다. File > New > File을 통해 위 메뉴로 파일을 생성하면 다음과 같은 화면이 나옵니다.
지원하는 Type은 Switch, TextInput, Label, Slider 등이 있습니다. 다음 공식 문서를 참조하세요.
프로젝트 설정 편집하실 일이 많았다면 많이 보셨을 plist (XML) 로 구성된 화면이 나옵니다. 각 컴포넌트는 Type과 Identifier를 가지게 되는데, XML로 보자면 이렇게 구성되어 있겠죠?
이후 베타샐러드일 때, UserDefault의 설정값을 참조하여 앱이 동작할 수 있도록 기존 코드를 수정합니다.
마지막으로 프로덕션에 영향을 주지 않기 위해 Settings.bundle의 Target Membership을 베타샐러드로 설정 후, 잘 동작하는지 테스트를 하면 완료!
이렇게 만들어진 기능들은 협업 대상자들에게 배포되고, 일주일에 1~2회씩 피드백을 받아 개선해 나가고 있습니다.
결론: (90분 → 5분) x 횟수 = 최적화된 시간
간단한 코드 수정이더라도 iOS팀이 직접 빌드해 줘야 하는 요청이 들어왔을 때, 아카이빙 소요 시간 20~30분 + Testflight의 승인시간 30–60분, 합산 90분 이후에야 결과를 전달할 수 있었습니다. 협업자들 간의 집중도와 시간 효율이 떨어지기 마련이었죠. 하지만 위와 같은 시스템을 도입한 후, 협업 대상자들이 5분 남짓한 셀프세팅으로 원하는 결과를 도출할 수 있었고, 조금 더 본인의 업무에 집중할 수 있게 되었습니다. 👍
물론 베타샐러드 개발자 도구는 일반 사용자들에게는 노출되지 않습니다. 하지만 iOS팀에서는 같이 일하는 협업 대상자들도 우리의 사용자라고 생각하고, 이들을 위해 제품을 만든다는 마음으로 개발했습니다. 협업 시 발생하는 비효율을 줄여 구성원 모두의 생산성 높이기라는 목표에 기반한 작업의 결과는 성공적이었습니다. 👏
이 과정을 진행하면서 좋은 아이디어와 피드백이 있다면 협업은 언제든지 즐거울 수 있다는 인사이트를 얻었습니다. 서비스 규모가 커지면서 협업을 위한 잦은 바이너리 제출은 클라이언트 개발자분들이 충분히 느낄만한 고민거리 중 하나인데, 이런 방식으로 풀어보면 어떨까요? 🙌
Reference
