업무용 모바일 화면을 쓰다 보면 “오늘”이라는 말이 참 편합니다. 오늘 매출, 오늘 매입, 오늘 할 일. 그런데 김부장처럼 매일 숫자를 확인하다 보면 가끔 어제나 그저께의 숫자도 보고 싶어집니다. 문제는 화면 이름이 ‘오늘 카드’라서 그런지, 처음에는 정말 오늘 데이터만 보여 주는 구조였다는 점입니다.
저는 단순히 화살표 하나를 붙이면 끝날 줄 알았습니다. 왼쪽을 누르면 어제, 오른쪽을 누르면 오늘. 하지만 AI와 함께 로그를 읽어 보니, 이 작업은 버튼을 추가하는 문제가 아니라 ‘날짜 기준이 어디까지 퍼져 있느냐’를 확인하는 일이었습니다.
화면 안의 ‘오늘’은 하나가 아니었다
첫 번째로 막힌 지점은 화면 안의 날짜 기준이 하나가 아니었다는 점입니다. 매출 통계는 사용자가 보고 싶은 날짜를 따라가야 하지만, 일정과 할 일은 실제 오늘 기준으로 남아 있어야 했습니다. 어제 매출을 확인한다고 해서 오늘의 할 일까지 사라지면 안 되니까요.
그래서 조회용 날짜와 실제 오늘 날짜를 분리해서 생각했습니다. 비개발자인 제 입장에서는 ‘오늘’이라는 단어 하나도 화면의 영역에 따라 다른 의미를 가질 수 있다는 사실을 처음 실감했습니다.
사실 이 부분은 전에 [비개발자 자동화 노트] 거래처 등급이 1로 보일 때, DB값만 믿지 않은 날에서도 비슷하게 헤맸던 지점이라, 그때 기록을 다시 들여다보면서 확인했다.
날짜를 받을 수 있도록 DB 함수를 바꾸다
두 번째는 DB 함수였습니다. 화면에서 날짜를 바꿔도 서버 쪽 통계 함수가 날짜를 받을 수 없으면 계속 오늘 숫자만 돌려줍니다. 통계 함수에 날짜 파라미터를 추가하되, 기존처럼 날짜를 보내지 않는 호출은 그대로 오늘 기준으로 동작하게 만들었습니다. 새 기능을 붙이면서 기존 기능은 깨뜨리지 않는 방식이었습니다.
과거 조회값이 오늘 캐시를 덮지 않게 하다
세 번째는 캐시였습니다. 모바일 홈은 빠르게 보여 주기 위해 통계 값을 저장해 둡니다. 그런데 과거 날짜를 조회한 값을 ‘오늘 캐시’에 넣어 버리면, 다음에 앱을 열었을 때 오늘 숫자가 어제 숫자로 보일 수 있습니다.
그래서 실제 오늘을 볼 때만 캐시를 읽고 쓰고, 과거 날짜를 조회할 때는 오늘 캐시를 건드리지 않도록 나눴습니다. 저는 이 부분이 특히 인상적이었습니다. 당장 화면에 보이는 버그만 고친 것이 아니라, 나중에 생길 수 있는 혼란까지 미리 막은 셈이니까요.
버튼보다 먼저 데이터 기준을 정해야 했다
검증 과정도 기억에 남습니다. 먼저 타입 체크를 돌렸고, 서버 함수가 날짜 파라미터를 찾지 못하는 오류가 한 번 나왔습니다. 처음에는 코드가 틀린 줄 알았지만, 알고 보니 서버의 스키마 캐시가 바뀐 함수 형태를 아직 인식하지 못한 상황이었습니다. 캐시를 다시 읽게 한 뒤에는 날짜를 지정한 호출과 날짜를 생략한 호출이 모두 정상으로 돌아왔습니다.
이번 작업에서 배운 것은 ‘버튼 하나’도 데이터 기준을 먼저 정해야 한다는 점입니다. 사용자는 어제를 보고 싶다고 말하지만, 프로그램 안에서는 매출의 어제, 일정의 오늘, 캐시의 오늘이 각각 다릅니다. AI가 코드를 대신 써 주는 것도 중요하지만, 비개발자인 저는 그 기준을 말로 나누고 확인하는 역할을 해야 했습니다.
다음에는 모바일 화면에서 숫자뿐 아니라 인쇄, 알림, 일정처럼 서로 다른 기준이 한 화면에 섞일 때 어떤 순서로 점검했는지도 이어서 정리해 보겠습니다.