아이폰 듀오, 일주일만에 대응 완료한 이야기
듀오가 채널에게 오는건 너무 수동적이다, 채널이 듀오에게 간다
Finn • Bonwook Koo, iOS Engineer I currently have a beard, just FYI
- Mobile
안녕하세요. 채널톡의 모바일 엔지니어 핀입니다.
지난 9월, 소문만 무성하던 애플의 첫번째 폴더블 폰이 공개되었습니다. 바로 아이폰 듀오입니다.
아이폰 듀오가 공개되기 전까지는 폴더블 폰이 나온다는 루머가 그렇게 크게 신경쓰이지는 않았습니다. 채널웍스 모바일 앱의 경우 이미 아이패드의 창 크기 조절 기능에 대응해둔 상태였기 때문에 폴더블 폰이 출시된다 하더라도 앱의 주요 레이아웃 요소가 보이지 않거나 상호작용을 하지 못하는 등의 치명적인 문제가 발생하지는 않을거라고 생각했거든요. 또 기존 코드를 수정해야 한들 일부만 부분적으로 수정하는 선으로 대응을 마칠 수 있을거라고 생각했기 때문이죠.
하지만 막상 실제로 발표된 아이폰 듀오를 보니, 역시나 애플답게 폴더블 폰도 특유의 감성(?)을 섞어 기존 개념을 확장한 채로 출시했더군요. 카메라 영역에 의해 발생하는 Reserved Region, 측면 Safe Area를 활용하는 Vertical Controls, 기존에 아이패드에서만 지원하고 있던 화면 분할까지… 단순히 화면 사이즈가 변한다는 수준으로 신경써서 될 일이 아니었던 겁니다. 생각보다 듀오 대응을 위해 고려할 것이 많아보였죠.
그래도 우리 팀은 최대한 빠르게 듀오 대응을 진행해보기로 했습니다.
물론 빠르게 대응한다는 결론을 내리기전에 우선 상황을 관망한다는 선택지도 있었습니다. 그런데 이 선택지를 선택했을때의 결과를 확인해보니 iOS 27.1 미만 SDK를 기준으로 빌드한 앱을 배포했을 경우, 아래 첨부한 스크린샷처럼 앱이 아예 화면 일부만 보여지는 문제가 발생할 수 있었습니다.
iOS 26 이하 SDK에서 빌드한 앱을 아이폰 듀오에서 실행했을 경우, 일반적인 아이폰 비율로만 화면을 볼 수 있습니다
iOS 27 SDK에서 빌드한 앱을 아이폰 듀오에서 실행했을 경우, 화면 너비는 확장되지만 우측 SafeArea까지 확장되지는 않습니다
저희는 채널웍스 유저에게 이런 화면이 보이는 상황 - 좋지 못한 사용자 경험을 제공하는 상황 - 은 최대한 피하고 싶었기 때문에 빠르게 대응해보자! 는 결론을 내리게 된 것이죠.
천 리 길도 한걸음부터 - 문제 파악하기
워낙에 큰 변화이다보니 애플에서도 듀오 대응을 위한 자료를 많이 제공해주고 있습니다. 하지만 그것으로 알 수 있는 것은 “우리 앱이 듀오에서 어떻게 보일 것이다” 이지, 실제로 우리 앱 화면이 어떻게 보이는지까지는 알 수 없습니다. 결국 듀오 대응의 완성도를 높이기 위해서는 실제 화면을 확인해야만 하죠. 이를 위해서는 일단 우리 앱의 모든 화면이 듀오에서 어떻게 그려지는 지 확인할 수 있도록 전수 조사부터 시작해야 했습니다.
이를 위해 AI의 도움을 받아 각 화면의 레이아웃 깨짐 사례를 분석 + 유형화 해서 팀 내 공유 가능한 형태로 웹페이지를 만들어 제공했어요. 그 과정을 자세히 설명하기는 어렵지만 간략하게 설명하자면 아래와 같습니다.
프로젝트 내 검증 대상 목록 확보하기 - 프레젠테이션 레이어가 별도로 분리되어있었고, 각 화면이 별도 모듈로 나뉘어있는 구조여서 거의 바로 목록을 확보할 수 있었습니다
검증 대상을 순차로 돌아가면서 스크린샷 확보하기 - 앱 실행시 삽입한 환경변수를 통해 특정 화면이 열리도록 하고, 미리 준비한 더미 데이터를 삽입해 화면을 띄울수 있게 만든 후 별도의 스크립트를 마련해 반복 실행했습니다
수집한 스크린샷을 동일 지침 하에 여러 에이전트에게 분산하기 - 콘텐츠가 잘리거나 겹치는 상황, 화면에 비정상적으로 큰 여백이 보여지는 등의 레이아웃 오류로 판단할 수 있는 기준을 지침으로 만들어서 여러 에이전트에게 스크린샷을 분산해서 전달하여 판단하도록 합니다
취합후 보고서 형태로 만들기 - 여러 에이전트로부터 보고받은 레이아웃 오류 사례를 하나의 메인 에이전트가 취합하여 보고서 형태로 만들도록 합니다
전체 스냅샷을 모아서 볼 수 있는 보고서를 만들었다.
이렇게 약 300개 남짓 되는 화면에 대해서 아이폰 듀오에서 실행했을때의 상황에 대한 보고서를 뽑아냈습니다. 당연한 얘기지만 이 모든 화면을 하나하나 보면서 교정할 수는 없는 노릇입니다. 앞서 레이아웃 깨짐 사례를 분석한 것을 기반으로 각 사례에 대해 어떤 식으로 대응할지에 대해 다시 유형화를 수행했고, 결과적으로 우선 대응할 부분으로 정리한 것은 좌우 Safe Area 적용과 내비게이션바, 탭바와 같은 화면 내 컨트롤에 대한 처리였습니다.
하나하나 해결해 나가기
좌우 Safe Area의 경우 다소 시간이 필요했으나 간단한 작업이었습니다. 앞서 레이아웃 깨짐 사례를 기반으로 수정이 필요한 화면이 확보된 상황이었으니 Safe Area 반영 이후의 스크린샷을 확인하는 형태로 반복해서 검증을 수행토록 하고, 최종 디테일 확인만 개입하는 식으로 접근할 수 있었습니다.
내비게이션바와 탭바 처리의 경우 Safe Area 대응에 비해 좀 더 신경써서 대응해야 하는 상황이었죠. 애플에서는 아이폰 듀오에서 콘텐츠의 세로 공간을 확보하기 위해 내비게이션바나 탭바와 같은 컨트롤을 측면 Safe Area에 배치하는 것을 권장하고 있습니다.
기본적으로 UINavigationController와 UITabBarController를 그대로 사용한다면 위에 첨부한 스크린샷과 같은 처리가 자동으로 적용됩니다. 다만 순정 상태의 UI가 아닌 커스텀 UI를 활용하는 경우에는 자동 적용을 기대하기는 어렵습니다.
채널웍스 모바일 앱의 경우 내비게이션바와 탭바 구현에 있어서 커스텀 컴포넌트로 구현되어있는 부분이 많았습니다. iOS 26부터 적용된 리퀴드 글라스 이펙트를 챙길 때, iOS 26 미만에서도 비슷한 경험을 제공할 수 있도록 버전 분기에 따라 별도 이펙트를 적용하는 커스텀 컴포넌트를 만들어서 사용하고 있었기 때문입니다. 아래 첨부한 스크린샷처럼 효과는 조금 다를지언정 동일한 형태를 적용해 동일한 경험을 주도록 한 것이죠.
iOS 18에서의 첫 화면과 iOS 26에서의 첫 화면 캡처 비교
내비게이션바는 이미 커스텀한 UI를 UINavigationController에 통합했기 때문에 세로로 노출되는 상황과 가로로 노출되는 상황에서의 레이아웃 변화 대응을 수행하는 것으로 상당 부분 듀오에 맞춰진 형태로 구현할 수 있었습니다.
예를 들어, 내비게이션바에 배치되는 UIBarButtonItem은 세로 배치를 위한 프로퍼티를 제공하고 있기 때문에 대응 자체가 어렵지 않습니다.UIBarButtonItem.axisProperty에 verticalPreferred를 적용하면 Vertical Control로 표현될 수 있는 상황에서는 세로 배치가 되는 것을 우선시하게 됩니다.
다만 우리 앱의 경우에는 내비게이션바 역시도 커스텀해서 사용하고 있는 부분이 많았기 때문에 프로퍼티 적용 만으로는 모자란 부분이 있었습니다. 이 경우에는 UITraitCollection의 verticalBarEdge 를 기준으로 삼아서 분기 처리를 주면 됩니다.
탭바의 경우에는 내비게이션바와 달리 iOS에서 제공하는 커스텀 가능한 영역에 대한 제약이 컸기 때문에 상황별로 어떤식으로 그려져야 할 지에 대한 명세를 좀 더 상세히 작성해야 했습니다. 아래와 같이 traitCollection의 변화를 구독하고, 탭바의 위치나 가로/세로 배치가 변경되어야 하는 상황에서 탭바 재배치 계산을 수행합니다.
이와 같은 처리를 추가한 후에는 앱에서 자연스럽게 화면 전환이 되는지를 체크해야 했습니다. 이 부분의 경우 어색하냐 아니냐를 사람의 눈으로 판단하는 쪽이 좀 더 세밀하기 때문에 직접 동작 확인을 해야하는 상황이 자주 발생했습니다. 그렇게 다음으로 병목 아닌 병목(?)이 발생했죠.
실기기 확인까지가 대응이다
이미 대부분의 개발자들이 그러듯이, 저 역시도 한번에 여러 작업을 병렬로 진행하고 있었습니다. 그렇기 때문에 한번에 여러 대의 아이폰 시뮬레이터를 띄워놓고 작업하게 되는 상황이 자주 발생합니다. 이번 듀오 대응 역시도 이런 식으로 진행되었어요. 이 상황에서 자동화된 테스트를 수행하는 것에는 다소 시간이 걸리더라도 문제는 없었지만, 실제로 사용자가 아이폰 듀오를 조작하면서 받을 느낌을 재현하기 위해 시뮬레이터를 조작하기에는 다소 성능 부하가 존재했습니다. 화면 하단을 쓸어올려서 왼쪽이나 오른쪽 패널에 배치하도록 한다는 식의 동작을 수행할 때 버벅거리는 경우가 자주 발생했던거죠.
당시 시뮬레이터로 작업하면서 나눴던 대화
결국 아이폰 듀오 실기기를 갖고 테스트해볼수 있어야 한다는 결론을 내렸습니다. 이를 위해 예약 구매까지 시도했으나, 안타깝게도 예약 구매 물건을 수령할 수 있는 예상 날짜가 2027년 1월로 배정되었습니다. 이래서야 실기기에 실행 한 번 못해보고 출시하는 모양새가 될 판이었는데…
크랙 게이트 덕분이었을까요? 애플 오프라인 매장에 취소 물량이 풀리면서 기적적으로 듀오 실기기를 구할 수 있었습니다. 하루라도 빨리 대응할 수 있도록 팀 동료인 이안이 당일 바로 픽업하러 명동까지 다녀오면서 듀오 대응의 디테일을 챙길수 있게 되었어요.
크랙 게이트란?
아이폰 듀오 새 제품을 사용한지 몇 시간 만에 내부 디스플레이가 갈라지는 현상이 발생하는 것으로부터 시작된 논란
일주일 만에 대응 성공 ️ 그리고…
실기기를 입수한 후부터는 좀 더 빠르게 디테일을 챙겨가면서 작업할 수 있게 되었습니다. 수정한 화면이 어떻게 보이는지뿐 아니라 화면 전환에 따라 컨트롤이 어떻게 동작하는지도 직접 확인하기 좋았으니까요. 그렇다고 듀오에서만 잘 동작하는 것을 확인하는 것으로 끝나는 것은 아닙니다. 듀오 뿐 아니라 iOS 26 이상 / 미만인 다른 기종의 아이폰 환경에서의 동작도 검토했죠.
작업을 마무리하고 검토하는 과정에서는 다크 모드에서의 버튼 색상이나 바 아이템 간의 간격, 애니메이션처럼 추가로 손봐야 할 부분도 발견됐습니다. 이 때 수정한 내용을 번복하거나 더 나은 보완안을 마련하기 위해 머리를 싸매는 등 디테일한 경험을 챙기는 순간이 이어졌죠. 기술적인 대응 뿐 아니라, 더 나은 경험이 무엇인가를 고민하는 과정을 거쳤습니다.
테스트하면서 이래저래 만져봤는데 좀 사고싶어졌을지도...?
이것으로 일주일간의 숨가쁜 듀오 대응 작업이 완료되었습니다. 처음에는 몇 군데만 손보면 될 줄 알고 시작했던 것이 실기기를 구하러 다녀오고 여러 환경을 오가며 확인하는 작업까지 이어지는 대공사가 되었네요.
이번 작업은 아이폰 듀오라는 새로운 폼팩터에서 기존 채널웍스 모바일 앱이 어떻게 동작해야 하는가에 대한 고민의 결과물입니다. 아마도 이 이후로는 아이폰과 아이패드를 넘나드는 다양한 화면에서 채널웍스 모바일 앱이 어떤 경험을 제공해야하는가에 대한 고민으로 이어질 것 같습니다.
이런 고민을 함께 나누고 더 나은 사용자 경험을 만들어 나갈 동료를 찾고 있습니다. 이 글을 읽고 관심이 생기셨다면, 아래 첨부한 채용 공고를 확인해 주세요!
[채용] Software Engineer
We Make a Future Classic Product! 우리에게 중요한 건, 언제나 고객이었습니다 채널톡이 의사결정할 때 묻는 질문은 하나입니다. 이 결정으로 비즈니스가 고객과 가까워지는가? 채널톡은 이 의사결정 방식을 Customer Driven이라는 Core Value로 정의하고 일합니다. 기업의 지속 가능한 성장을 돕는 올인원 AI 메…
Channel.io
![[채용] Software Engineer](https://cf.channel.io/thumb/1200x630,cover,webp/pub-file/cht/web-page/1/6af5cd0dea845da8dbf5/jobs-og.webp)
