상태 관리

화면이 한 장일 때는 기억할 것이 적었습니다. 입력란에 적힌 글자와 지금 열린 탭 정도를 그 화면 안에서 들고 있으면 됩니다. 값이 필요한 곳과 값이 있는 곳이 같은 자리라 고민할 것이 없습니다.

화면을 재사용 가능한 부품인 컴포넌트로 쪼개 쌓기 시작하면서 이 문제가 생겼습니다. 로그인한 사람의 이름은 화면 맨 위의 프로필 영역과 문서 목록의 작성자 표시와 공유 창의 소유자 칸에서 각각 필요합니다. 값을 들고 있는 곳이 하나면 그 값을 필요한 곳까지 전달해야 하고, 전달 경로가 네 단계 깊어지면 중간의 부품들은 쓰지도 않는 값을 받아 아래로 넘기기만 합니다. 반대로 필요한 곳마다 값을 따로 들고 있으면 한쪽에서 이름을 바꿨는데 다른 쪽은 옛 이름을 계속 보여 줍니다.

상태 관리는 그 값들을 어디에 두고 어떻게 옮길지를 규칙으로 정해 두는 일입니다. 도구를 고르는 문제로 보이지만 실제로는 값의 자리와 바꿀 권한을 정하는 설계 문제입니다.

값마다 어느 범위에서 살아야 하는지를 정하고, 그 범위에 맞는 자리에 둡니다. 실무에서 하는 판단은 넷입니다.

1. 값의 수명과 범위를 가릅니다. 입력 중인 글자처럼 그 부품 안에서만 쓰고 화면을 떠나면 버려도 되는 값이 있고, 로그인 정보처럼 앱 전체가 함께 봐야 하는 값이 있습니다. 앞쪽을 전역으로 올리면 화면 하나가 바뀔 때 관계없는 곳까지 다시 그려집니다. 입력란에 한 글자를 칠 때마다 목록 전체가 다시 그려지는 화면이 이 실수에서 나옵니다.
2. 서버에서 받아 온 값을 따로 다룹니다. 문서 목록처럼 서버가 원본을 들고 있는 값은 화면이 기억하는 값이 아니라 잠시 빌려 둔 사본입니다. 언제 다시 받아 올지, 받아 오는 동안 무엇을 보여 줄지, 실패하면 어떻게 할지를 함께 정해야 해서 요즘은 이 갈래를 전용 도구로 분리합니다.
3. 바꿀 수 있는 자리를 좁힙니다. 어느 부품이든 값을 직접 고칠 수 있게 두면 값이 언제 왜 바뀌었는지 추적할 수 없습니다. 바꾸는 방법을 정해진 함수 몇 개로 묶어 두면 바뀐 경로가 기록으로 남습니다. 값이 이상하게 들어간 사고를 찾을 때 이 기록이 있는지 없는지가 반나절과 이틀을 가릅니다.
4. 전역으로 올릴 것을 줄입니다. 전역 저장소는 편하지만 그 안의 값은 지우기가 어렵습니다. 쓰는 곳이 어디인지 알 수 없어지면 아무도 그 값을 지우지 못하고, 반년 뒤에는 무엇이 살아 있는지 모르는 덩어리가 남습니다.

값을 옮기는 가장 단순한 방법은 부모가 자식에게 직접 넘기는 것입니다. 이 방법이 깊어져 문제가 되는 상태를 프롭 드릴링이라고 하고, 전역 저장소나 문맥을 쓰는 도구들은 대개 그 문제를 줄이려고 나왔습니다.

로그인 정보와 권한이 첫째입니다. 누가 로그인했는지, 그 사람이 이 문서를 고칠 수 있는지는 거의 모든 화면이 함께 봐야 하는 값입니다. 이 값을 각자 들고 있으면 권한이 바뀐 뒤에도 옛 권한으로 동작하는 화면이 남습니다. 사용자는 고쳐지지 않는 버그로 겪고, 새로고침하면 사라지니 재현도 어렵습니다.

둘째는 여러 화면에 걸친 작업입니다. 화면 이동을 브라우저가 처리하는 SPA 구조에서는 이 값이 특히 자주 문제가 됩니다. 결제 흐름처럼 세 화면에 걸쳐 값을 모으는 경우, 중간에 뒤로 갔다 돌아와도 입력한 것이 남아 있어야 합니다. 화면 하나가 사라져도 남아 있어야 하므로 각 화면이 들고 있을 수 없고, 그렇다고 앱 전체가 볼 필요도 없습니다. 이 흐름이 끝나면 지워지는 자리를 따로 두는 것이 이때의 답입니다.

셋째는 서버에서 받아 온 목록과 그 화면 표시입니다. 같은 요소가 상황에 따라 달라지는 모습인 UI 상태와 맞물리는 자리인데, 불러오는 중과 비어 있음과 실패를 각각 어떤 화면으로 보여 줄지가 이 값에 붙습니다. 세 경우를 정하지 않으면 실패했을 때 빈 목록이 보이고, 사용자는 문서가 사라졌다고 읽습니다.

반대로 손을 대지 않아도 되는 자리가 있습니다. 한 부품 안에서만 쓰는 값은 그 자리에 두는 것이 맞습니다. 창이 열려 있는지처럼 다른 곳에서 알 필요가 없는 값을 전역으로 올리면, 이 값이 어디서 바뀌는지를 찾는 데 나중에 시간을 씁니다.

"이 값은 전역으로 올리지 말고 이 부품 안에 두죠."

범위를 좁혀 다시 그려지는 범위를 줄이자는 제안입니다.

"서버에서 받아 온 목록은 전역 저장소에 넣지 않습니다."

원본이 서버에 있는 값은 다른 갈래로 다루자는 뜻입니다.

"이 값을 누가 바꾸는지 못 찾겠어요."

바꿀 수 있는 자리를 좁혀 두지 않았을 때 나오는 말입니다.

페이지덱의 문서 편집 화면에서 이 문제가 드러난 적이 있습니다. 공유 권한을 바꾼 뒤에도 편집 화면의 버튼이 옛 권한으로 남아 있었습니다. 권한 값을 상단 영역과 편집 화면이 각각 들고 있었기 때문입니다.

태오는 권한과 로그인 정보만 한 자리로 올리고, 문서 본문과 목록은 서버에서 받아 오는 값으로 따로 다뤘습니다. 편집 중인 글자는 그 부품 안에 그대로 두었습니다. 셋을 갈라 두는 것이 도구를 하나 더 들이는 것보다 먼저였습니다. 실제로 새 도구는 들이지 않았고, 옛 권한이 남는 문의도 그 뒤로 들어오지 않았습니다.

도구를 고르는 문제로 읽는 경우가 가장 많습니다. 후보 이름이 여럿이라 무엇을 쓰느냐가 결정처럼 보입니다. 하지만 도구를 바꿔도 값의 자리를 정하지 않으면 같은 문제가 그대로 남습니다. 전역에 올릴 값과 그 자리에 둘 값을 가르지 않은 채 도구만 들이면, 전에 여러 곳에 흩어져 있던 값이 한곳에 흩어져 있게 됩니다.

전역으로 모아 두면 관리된다고 보는 것도 흔합니다. 한 곳에서 보이니 정돈된 느낌이 듭니다. 그런데 전역 저장소는 넣기는 쉽고 빼기는 어렵습니다. 어느 화면이 그 값을 읽는지 추적하기 어려워지면 지우는 결정을 아무도 내리지 못하고, 값이 쌓일수록 한 값을 바꿀 때 무엇이 함께 바뀌는지 예측하기 어려워집니다. 그래서 전역에 올리는 기준을 미리 적어 두는 팀이 나중에 덜 고생합니다.