자동으로 뜨던 것을 껐더니 진입점이 사라졌습니다

귀찮아서 자동으로 올라오던 바텀시트를 껐습니다. 그 자동 노출이 그 화면의 유일한 진입점이었습니다. 이틀 사이 같은 방식으로 두 개를 잃었고, 둘 다 코드는 멀쩡히 남아 있었습니다.

앱을 쓰다 보면 할 일 탭에 들어갈 때마다 시트가 하나씩 올라왔습니다. 오늘의 의도를 적으라는 화면이었는데, 매번 닫는 게 번거로워서 자동 노출을 꺼버렸습니다. 효과 하나에 코드 몇 줄, 5분이면 끝나는 작업이었습니다.

그날 저녁에야 알았습니다. 이제 그 시트를 여는 방법이 아예 없다는 것을요.

끈 것은 노출인데 사라진 것은 진입점이었습니다

혹시나 해서 그 시트로 가는 진입점을 찾아봤는데 하나도 없었습니다. 버튼도 없고, 메뉴에도 없고, 설정에도 없었습니다. 들어가면 뜨는 것, 그게 전부였습니다.

그러니까 제가 한 일은 안 뜨게 하기가 아니라 사실상 없애기였던 셈입니다. 파일은 그대로 있고 컴포넌트도 멀쩡하고 타입 검사도 린트도 다 통과하니, 겉으로는 아무것도 부서지지 않았습니다. 다만 아무도 그걸 열 수 없게 됐을 뿐입니다.

이 시트는 전에도 한 번 사고를 낸 적이 있습니다. 자동으로 열리면서 가이드 오버레이의 터치를 통째로 가져가 앱이 멈춘 것처럼 보이게 만들었던 바로 그 시트인데, 그때는 너무 적극적으로 떠서 문제였고 이번엔 그걸 잠재웠더니 통째로 사라졌습니다.

비슷한 일이 한 번 더 있었습니다.

할 일 화면 상단에 달력 아이콘이 있었는데, 그 옆에 오늘과 주간을 고르는 토글을 새로 넣고 보니 아이콘이 여는 화면의 주간 보기와 토글의 주간 보기가 같은 일을 두 번 하고 있었습니다. 그래서 아이콘을 뺐습니다. 중복을 없앤 것이니 맞는 판단처럼 보였습니다.

그런데 그 아이콘이 여는 화면에는 주간 말고 월간도 있었고, 하필 그 아이콘이 거기로 가는 유일한 길이었습니다. 주간은 토글이 물려받았지만 월간은 갈 곳이 없어진 것입니다.

이번에는 지우기 전에 확인했기 때문에 알고 뺐고 코드에 이유도 적어뒀습니다. 앞의 건은 모르고 했고 뒤의 건은 알고 했지만, 결과만 놓고 보면 똑같습니다.

빌드는 성공하고 타입 검사도 통과합니다. 린트 역시 그 컴포넌트가 어딘가에서 여전히 import 되고 있으면 미사용이라고 말해주지 않습니다.

라우터에도 그대로 등록돼 있어서 코드로 navigate('그화면') 을 부르면 잘 열립니다. 즉 도달 불가능한 게 아니라 사람이 도달할 방법만 없는 상태입니다.

정적 분석이 잡아내는 건 참조 관계인데, 사람이 손가락으로 그 화면까지 갈 수 있느냐는 참조 관계가 아닙니다. 그래서 도구를 아무리 늘려도 이런 건 안 걸립니다.

그래서 노출 조건을 건드릴 때 한 줄짜리 확인을 넣기로 했습니다. 이 화면으로 오는 다른 길이 있는지부터 찾아보는 것입니다.

git grep -n "그화면이름" src | grep -v "screens/그화면/"

자기 자신을 뺀 참조가 하나도 없다면, 지금 제가 끄려는 그 조건이 유일한 문이라는 뜻입니다.

이때 선택지는 셋입니다. 다른 문을 먼저 만들고 끄거나, 화면까지 같이 지우거나, 아니면 문이 없어진다는 걸 알면서 끄고 그 사실을 적어두는 것입니다. 셋 다 괜찮습니다. 안 괜찮은 건 셋 중 무엇을 하고 있는지 모르는 채로 끄는 것입니다.

버튼을 지우면 손이 먼저 기억합니다. 여기 있던 게 없어졌다는 걸 다음에 누르러 갔다가 알게 되니까요.

자동으로 뜨던 것은 그렇지가 않습니다. 안 뜨는 게 애초에 원하던 결과라서 없어진 게 오히려 성공처럼 보이고, 실제로 그날 저는 만족했습니다.

게다가 자동 노출에는 대개 버튼이 없습니다. 알아서 뜨니까 굳이 안 만든 것이고, 그래서 끄는 순간 문이 0개가 되어버립니다. 자동으로 뜨는 기능일수록 그 트리거가 유일한 진입점일 확률이 높다는 뜻입니다.

두 화면 다 코드는 지우지 않았습니다.

앞의 시트는 회고 기능이고 뒤의 화면은 월간 달력인데, 둘 다 지금 방해가 된다는 이유로 끈 것이지 필요 없다고 판단한 게 아니어서입니다. 대신 테스트 문서에 도달 불가라고 적어뒀습니다. 그래야 나중에 되살릴 때 진입점부터 만들어야 한다는 걸 알 수 있으니까요.

이건 어디까지나 취향입니다. 바로 지우는 쪽이 저장소는 깨끗해지는데, 되살릴 때 다시 쓰는 비용과 남겨두고 잊어버리는 비용 중에 저는 후자를 택했습니다. 잊지 않으려고 적어둔 것이고, 그 메모가 실제로 읽히는지는 아직 모릅니다.

2026년 8월 15일 기준으로 Expo SDK 56 기반 리액트 네이티브 앱 하나에서 겪은 일이고, 같은 방식으로 도달 불가가 된 화면이 이틀 사이 두 개였습니다.

이게 일반적으로 얼마나 흔한지는 모릅니다. 제 저장소에 지금 도달 불가인 화면이 이 둘뿐인지도 아직 세어보지 않았습니다. 세는 걸 자동화할 수 있을 것 같긴 한데, 라우터 등록과 실제 호출을 대조하는 방식이 어디까지 정확할지는 해봐야 알 것 같습니다.