요즘 나는 ‘죠비엣(Choviet)’ iOS 앱을 만들면서 한 가지를 자주 느낀다.
기능이 되는 것과 제품처럼 느껴지는 것 사이에는, 생각보다 깊은 강이 하나 흐른다는 것.
Turbo Native를 붙이는 작업은 딱 그 강을 건너는 일이었다.
처음엔 “웹을 앱으로 싸기만 하면 되겠지” 같은 순진한 마음이었다가,
막상 해보니 이건 ‘포장’이 아니라 경계면(네이티브 ↔ 웹)을 조각하는 일이었다.
그리고 그 강을 건너는 데 가장 큰 도움을 준 건, 의외로 화려한 기술이 아니라…
반복 가능한 자동화 스크립트였다.
1. Turbo Native 통합의 목표는 단순했다
“웹을 띄우되, 사용자는 앱이라고 믿게 만들기”
Turbo Native는 매력적이다.
웹을 그대로 활용하면서 iOS 앱처럼 보이게 만들 수 있으니까.
하지만 그만큼 함정도 있다.
- 헤더가 겹친다
- 스크롤이 어색하다
- 모달이 웹처럼 뜬다
- 제출 후 화면이 멈춘다
- 링크가 사파리로 빠진다
이런 문제들은 기능이 ‘실패’한 게 아니라,
사용자의 신뢰가 조용히 새는 구멍이 된다.
그래서 이번 통합 작업의 진짜 목표는 하나였다.
“앱이 웹을 품고 있다는 사실을, 사용자가 굳이 의식하지 않게 만들기.”
2. 해결한 것들: “앱다운 감각”을 만드는 체크리스트
이번에 완료된 핵심 항목은 다음 다섯 가지다.
✅ 1) 네이티브 헤더: 불투명 + 콘텐츠 겹침 없음
이거 하나만 해결돼도 체감이 확 바뀐다.
헤더가 투명하거나 겹치면, 앱이 아니라 “웹뷰” 느낌이 바로 난다.
결론: 헤더는 장식이 아니라 제품의 얼굴이다.
✅ 2) 웹 헤더 숨김
네이티브 헤더가 있으면 웹 헤더는 사라져야 한다.
헤더가 두 개면 사용자는 즉시 “아 이거 웹이네” 하고 마음이 떠난다.
결론: 한 화면에 왕은 한 명만 있어야 한다.
✅ 3) 스크롤 정상 작동
스크롤이 어색하면 기능이 아무리 많아도 “불안한 앱”이 된다.
사람은 스크롤로 제품의 품질을 판단한다. (진짜임)
결론: 스크롤은 UX의 심장박동이다.
✅ 4) 신고 모달 & 폼 제출
모달은 Turbo Native 경계에서 자주 깨지는 대표 구간인데,
여기까지 자연스럽게 되면 “이제 앱이 기능을 소화한다”는 감각이 생긴다.
결론: 모달과 폼은 ‘통합이 제대로 됐는지’ 보여주는 시험지다.
✅ 5) 성공 후 리디렉션
제출이 성공했는데 화면이 멈추면 사용자는 바로 불안해한다.
리디렉션(또는 명확한 피드백)이 있어야 “끝났다”가 된다.
결론: 성공은 완료 신호까지 포함해야 성공이다.
3. 진짜 승부처: “실수할 자유를 줄이기”
그래서 내가 만든 건… iOS 테스트 자동화 스크립트였다
Turbo Native 작업은 “한 번 고치고 끝”이 아니다.
조금만 손대도 다시 깨진다.
그러니까 매번 수동으로 확인하면, 사람은 지치고 제품은 흔들린다.
그래서 나는 test-choviet.sh를 만들었다.
이 스크립트가 하는 일은 단순하지만 강력하다.
- 서버 상태코드 + JSON 정상 여부 확인
- 시뮬레이터 자동 선택 & 자동 부팅
- 빌드 → 앱 경로 탐색 → 설치 → 실행
- 시나리오별 스크린샷 자동 저장
- 결과 폴더를 자동으로 열어 확인까지 빠르게
그리고 재미있는 점은…
이 스크립트도 진화했다는 것이다.
v2.4.1 → v2.4.3g 까지의 진화는 거의 “생존기”
- HEAD가 막히면 GET으로 우회
- 리다이렉트(-L) 대응
- 타임아웃 도입(무한 대기 방지)
- 상태코드가 빈 문자열이면 0 처리
- UDID 선택 로직 개선(booted 우선, runtime 검증)
- JSON 파싱 실패 시 응답 미리보기 출력
- 멀티바이트/개행 안전 출력(head -c, printf)
- STATUS 숫자 검증으로 이상한 문자열 방어
한 줄로 요약하면 이거다.
“스크립트는 점점 더 정직해졌고, 더 덜 믿음직한 세상에서도 버티게 됐다.”
4. 현실적인 이슈: 유니버설 링크 미설정이면 사파리로 새는 문제
스크린샷 파일명에 maybe-web이 들어간 이유도 이거다.
- /users/sign_in
- /posts/1
이런 링크는 설정이 없으면 사파리로 열린다.
그래서 스크립트는 솔직하게 말한다.
“이 화면은 앱일 수도 있고, 사파리일 수도 있다.”
이건 실패가 아니라 정확한 현상 기록이다.
그리고 다음 단계는 명확하다.
- Associated Domains(유니버설 링크)
- 또는 Custom URL Scheme(choviet://)
5. 최종 결과: Turbo Native 통합 완료 요약
- ✅ 네이티브 헤더 (불투명, 콘텐츠 겹침 없음)
- ✅ 웹 헤더 숨김
- ✅ 스크롤 작동
- ✅ 신고 모달 & 폼 제출
- ✅ 성공 후 리디렉션
이제 “작동하는 앱”을 넘어서,
사용자가 믿을 수 있는 앱으로 넘어가는 문턱에 섰다.
6. 다음 단계(너무 욕심내지 말고, 딱 3개만)
1. 유니버설 링크/딥링크 정리
maybe-web을 sure-app으로 바꾸는 작업
2. 로딩/에러 UX 추가
느린 통신에서도 앱이 멈춘 느낌이 안 나게
3. 테스트 결과 요약 파일 생성
스크린샷 + 상태코드 + 실행 환경을 summary.txt로 남기면
나중에 회귀 테스트에서 신이 된다
마무리: 결국 이건 “앱을 만드는 일”이 아니라 “신뢰를 만드는 일”
Turbo Native 통합은 기술 통합이지만,
내가 진짜로 통합한 건 사용자의 시간과 내 마음의 안정감이었다.
수동 테스트의 피로를 자동화로 바꾸고,
불확실성을 로그와 스크린샷으로 고정해버리면,
그제야 다음 기능을 만들 수 있는 힘이 생긴다.
나 같은 늦깎이에게 필요한 건 속도가 아니라,
다시 시작할 수 있는 구조니까.