화면에서 사용자가 바꾼 설정을 저장하는 일을 맡았을 때는 꽤 단순하게 생각했다. 필요한 값을 JSON으로 만들고 파일에 저장한 다음, 다음 실행 때 다시 읽으면 끝이라고 봤다. 실제로 처음 만든 기능도 한 화면에서만 시험할 때는 잘 동작했다. 그래서 생각보다 금방 끝났다고 좋아했던 기억이 난다.
문제는 사용하는 상황이 조금만 달라지면서 시작됐다. 계정이 바뀌었는데 이전 설정이 나타나거나, 여러 화면 중 마지막에 닫은 화면의 값이 다른 곳에 덮어써지는 일이 생겼다. 저장은 됐는데 앱을 다시 켜면 기본값으로 돌아가는 경우도 있었다. 파일 안의 값은 맞아 보여서 한동안 어디가 잘못됐는지 찾기 어려웠다.
처음에는 저장 함수만 계속 확인했다. 하지만 원인은 저장하는 코드 하나가 아니라 시점과 순서에 있었다. 화면이 준비되기 전에 값을 읽으면 나중에 기본값이 다시 덮였고, 반대로 너무 늦게 저장하면 종료 과정에서 변경한 내용이 빠졌다. 어떤 계정의 값인지 구분하는 기준도 필요했다. 같은 JSON이라도 누가 언제 쓰고 언제 읽는지에 따라 결과가 완전히 달라졌다.
그 뒤로는 값을 고치기 전에 상태가 움직이는 순서를 먼저 적었다. 화면이 열릴 때 무엇을 읽는지, 사용자가 바꾼 값은 메모리에 언제 반영되는지, 파일에는 어느 순간 기록되는지를 하나씩 확인했다. 가져오기와 내보내기도 단순히 파일을 복사하는 일이 아니라 지금 화면과 저장된 값 중 무엇을 기준으로 삼을지 정해야 했다. 글로 적어 놓고 보니 놓친 순서가 눈에 들어왔다.
이 작업을 하면서 데이터 구조보다 데이터의 시간표가 더 어려울 수 있다는 걸 배웠다. 예전에는 변수에 올바른 값이 들어 있으면 문제가 없다고 생각했지만, 이제는 그 값이 언제 만들어졌고 언제 다른 값으로 바뀌는지도 함께 보려고 한다. 거창한 방법을 배운 건 아니어도, 저장 문제를 만났을 때 파일부터 의심하지 않고 상태와 시점을 먼저 확인하게 된 계기였다.