사진 올리기 버튼이 대답하지 않았다 — 웹이 하던 일을 앱이 대신 한다
WebView 에 주소만 넣고 띄운 앱에서 사진 올리기를 누르면 아무 일도 일어나지 않는다. TWA 시절에는 Chrome 이 말없이 해 주던 일이었다. 링크를 누가 열지, 파일 선택 창과 카메라를 누가 띄울지, 위치를 누가 물을지 하나씩 앱이 떠맡은 이야기다.
애드소프트 기술블로그
개발·서버 운영 실무 기록
애드소프트 박재호입니다. IIS·ASP.NET 웹 서비스와 메일서버를 직접 운영하고, Unity 게임과 데스크톱 앱을 만들며 겪은 문제와 해결 과정을 기록합니다.
최신 글
TWA가 막혔다 — Bubblewrap 앱을 WebView 로 다시 짓기로 한 이유
앱은 멀쩡했다. 그런데 Play 비공개 테스트가 TWA 로 만든 앱의 접수를 멈췄다. Chrome 이 대신 그려 주던 앱을 WebView 로 다시 지으면서, 같은 Play 앱으로 업데이트되게 하려고 바꾸지 않은 이름들과 Chrome 이 말없이 해 주던 일들을 정리했다.
스토어에 올린 다음의 일 — 「식단서랍」을 Play 스토어와 운영으로 내보내며
Play 검토자는 내 앱을 처음 보는 사람이고, 빈 화면을 보면 기능이 없다고 판단한다. 그래서 검토자가 쓸 계정에 레시피부터 채워 넣었다. 웹 서비스를 스토어에 올리고 나니 도메인 증명, 정책 페이지, 간편가입, 앱 푸시, 배포 자동화까지 '그 바깥'의 일이 줄줄이 따라왔다.
배포했는데 폰에는 옛날 화면 — 「식단서랍」의 서비스 워커와 캐시
서버에서는 고쳤고 PC 에서도 고쳐졌는데, 폰에서는 호박 수프 카드에 여전히 카야 토스트 그림이 붙어 있었다. 범인은 오프라인을 위해 넣은 서비스 워커였고, 그 서비스 워커를 갱신하려고 만든 장치가 정작 폰에만 닿지 않고 있었다.
열한 가지 구멍 — 「식단서랍」을 공격자 눈으로 다시 읽기
기능을 붙이는 동안 한 번도 의심하지 않은 코드가 있었다. 사진 경로 하나, 레시피 번호 하나를 화면이 보내는 대로 믿고 있었다. 쓰는 사람 대신 노리는 사람의 눈으로 처음 서비스를 다시 읽었더니 열한 가지가 나왔다.
사진 한 장의 여정 — 「식단서랍」이 레시피 사진을 받아 저장하기까지
토스트 사진 한 장이 3000x4000, 3.3MB 였다. 레시피 상세에서도, 메뉴 썸네일에서도 그 3.3MB 를 통째로 내려받고 있었다. 사진을 줄이는 건 금방이었는데, 그 사진이 정말 사진인지 묻는 일과 라이브러리를 고르는 일이 훨씬 길었다.
오늘 뭐 먹지에 점수를 매기다 — 「식단서랍」의 추천 계산과 느려진 첫 화면
즐겨찾기 100점, 한 번 만들 때마다 1점. 메뉴 고르는 창의 정렬 한 줄에서 시작한 추천은 홈 화면의 오늘의 추천, 비슷한 레시피, 제철 재료를 섞은 이달의 추천까지 자랐다. 그리고 그 추천들이 화면을 열 때마다 레시피 전체를 읽고 있었다.
다시 눌렀더니 햄이 사라졌다 — 「식단서랍」 장보기 목록 자동 생성
메뉴 하나를 바꾸고 장보기 자동 생성을 한 번 더 눌렀다. 목록은 새로 채워졌는데 직접 넣어 둔 햄도, 이미 사서 체크해 둔 대파도 없었다. 목록의 행이 어디서 왔는지 기록하지 않은 대가였다.
손가락을 따라오는 달력 — 「식단서랍」의 월간 식단과 함께 쓰는 달력
달력을 옆으로 밀었는데 아무 일도 없다가, 손을 떼는 순간 갑자기 다음 달로 넘어갔다. 동작은 맞았지만 손에 붙지 않았다. 손가락을 따라 움직이다 넘어가거나 되돌아오는 달력을 만들고, 그 달력을 가족과 함께 쓰게 되기까지의 이야기다.
고치지 않고 밀어 두었다 — MVC 5 앱을 .NET 9 로 옮긴 아홉 걸음
오래된 MVC 5 앱을 고쳐 쓰는 대신 통째로 legacy/ 폴더에 밀어 두고 빈 솔루션부터 다시 시작했다. 옮기는 길에 테이블 이름 하나가 시드 SQL 을 깨뜨렸고, MySQL 은 인증 방식을 바꿨고, 별표 하나가 패키지 버전을 메이저째 끌어올렸다.