키보드가 올라오면 저장 버튼이 사라졌습니다

폰에서 일정을 하나 추가하려다 멈칫했습니다. 제목을 적고 저장하려는데 「추가」 버튼이 없었어요. 화면을 위로 밀어봐도 나오지 않습니다.

처음엔 캘린더 화면 하나가 잘못 만들어진 줄 알았습니다. 그 자리만 고치면 끝날 일로 봤어요. 그래서 고치기 전에 «다른 화면은 괜찮은가»만 확인해 보기로 했는데, 확인이 본 작업보다 훨씬 커졌습니다.

눈으로는 셀 수 없었습니다

입력 창은 앱 전체에 서른 개가 넘습니다. 하나씩 폰에서 열어 확인하려면 며칠이 걸리고, 그러고도 다음 달에 새 창이 하나 생기면 처음부터 다시 해야 해요. 그래서 창을 자동으로 띄워 재는 장치를 먼저 만들었습니다.

진짜 창 37개를 진짜 데이터 위에 올려 실제 폰 크기로 띄웁니다. 그리고 세 가지를 잽니다 — 창이 제 내용을 잘라냈는지, 창이 화면 밖으로 나갔는지, 그리고 굴려도 닿을 수 없는 버튼이 있는지. 마지막 것이 핵심이었어요. 스크롤해서 닿을 수 있으면 불편한 것이고, 닿을 수 없으면 못 쓰는 것입니다.

폭은 네 가지를 씁니다. 320×568(아이폰 SE 1세대와 폴더블 커버 화면), 360×640(안드로이드 보급형), 390×664(아이폰 12~15), 430×740(프로 맥스). 여기에 키보드가 올라온 상태와 아닌 상태를 각각 쟀습니다.

결과입니다. 숫자는 «닿을 수 없는 버튼이 있는 창»의 개수예요.

캘린더 하나가 아니었습니다. 탭 여덟 개에 걸쳐 있었어요. 가장 심한 것은 학업 탭의 과제 창으로 522픽셀이 잘려 있었습니다. 창 아래쪽이 통째로 없는 셈이에요.

왜 몇 달 동안 몰랐을까

재현 조건이 «좁은 화면 + 키보드»입니다. 그런데 만들고 검수하는 쪽은 넓은 창에서 보고, 거기서는 키보드가 뜨지 않아요.

여기에 하나가 더 겹칩니다. 입력 창 대부분이 열리자마자 첫 칸에 커서를 놓습니다. 바로 타이핑하라고 넣은 동작인데, 그 말은 쓰는 사람에게는 키보드가 올라와 있는 상태가 기본이라는 뜻이에요. 만드는 쪽이 한 번도 보지 않는 그 상태가, 쓰는 쪽에게는 늘 보는 상태였습니다.

자동 검사도 이걸 못 잡습니다. 잘림은 오류가 아니거든요. 예외도 안 나고 경고도 없어요. 화면은 멀쩡하게 떠 있고 그저 아래가 없을 뿐입니다.

처음 잰 숫자는 거짓말이었습니다

장치를 만들어 처음 돌렸을 때 나온 결과는 통째로 틀린 값이었습니다.

그 장치가 제품과 다른 설정으로 돌고 있었어요. 화면을 배치하는 규칙이 하나도 적용되지 않은 채로 «측정»되고 있었는데, 화면은 그럴듯하게 떠서 아무 경고도 없었습니다. 잘못된 자로 잰 숫자가 그럴듯한 범위로 나온 겁니다.

여기서 배운 것 하나. 조용히 거짓을 내는 검사는 없는 검사보다 나쁩니다. 검사가 없으면 «아직 확인 안 했다»는 것을 알기라도 하는데, 있으면 확인했다고 믿어버리니까요.

원인은 자가 두 개였다는 것

창의 높이를 정하는 곳이 두 군데였습니다. 바깥 껍데기가 «화면 높이만큼»으로 한 번 정하고, 안쪽 내용이 «화면의 65%까지»로 또 한 번 정해요. 문제는 두 곳이 «화면 높이»를 서로 다르게 잰다는 것입니다. 한쪽은 주소창을 뺀 실제로 보이는 높이를 쓰고, 다른 쪽은 주소창을 포함한 큰 높이를 씁니다. 그래서 안쪽이 바깥보다 커지고, 넘친 만큼이 잘려요. 잘리는 것은 늘 마지막 줄입니다. 저장·취소·삭제 버튼이 거기 있습니다.

이 대목에서 판단이 한 번 바뀌었습니다. 처음엔 «화면을 거의 다 채우는 큰 값만 위험하다»고 보고 85% 이상만 찾고 있었어요. 그런데 실제로 결함을 낸 값은 **65%**였습니다. 숫자가 작아도 다른 자로 잰 두 상자는 언제든 어긋납니다. «얼마나 큰가»를 따지는 것을 그만두고, 안쪽에서 높이를 다시 재는 것 자체를 막기로 했습니다.

37개를 고치는 대신 한 곳을 고쳤습니다

창을 하나씩 손보면 서른여덟 번째가 같은 실수를 합니다.

높이 상한은 바깥 껍데기 한 곳만 갖게 하고, 안쪽 내용은 남은 만큼을 쓰게 했습니다. 그래도 모자라면 잘라내는 대신 창 전체가 스크롤되도록 바꿨어요. 버튼이 사라지는 것과 굴려서 닿는 것은 쓰는 사람에게 전혀 다른 일입니다. 키보드가 올라올 때 남는 공간을 계산하는 식도 고쳤습니다. 가장 좁을 때 여백을 한 번 더 떼고 있었거든요.

고친 뒤 같은 조건에서 다시 셌습니다. 네 가지 폭 모두, 키보드가 있든 없든 0 / 37입니다.

되살아나지 않도록 검사를 둘 붙였습니다. 하나는 코드를 읽어서 «안쪽에서 높이를 또 정하지 않았는가»를 보고, 다른 하나는 매번 진짜로 창 37개를 띄워 «아래 버튼에 닿는가»를 잽니다. 둘은 서로를 대신하지 못해요. 앞의 것은 새로운 방식으로 어긋나는 경우를 못 보고, 뒤의 것은 목록에 없는 창을 못 봅니다. 새 창을 만들면 그 목록에 한 줄 더하는 것이 규칙이 됐습니다.

문의함이 조용했던 이유

이 결함으로 들어온 문의는 한 건도 없었습니다. 몇 달 동안 열여덟 개의 창에서 버튼이 안 보였는데도요.

사람은 저장 버튼이 안 보인다고 문의를 쓰지 않습니다. 몇 번 눌러보다가 «이 앱은 저장이 잘 안 되네» 하고 다음부터 덜 엽니다. 문의가 없는 것이 결함이 없다는 증거는 아니었어요. 만난 사람이 말없이 떠났을 뿐일 수도 있습니다.

요즘은 새 화면을 만들면 넓은 창에서 보기 전에 폰 크기로 먼저 띄웁니다. 키보드를 올린 채로요.