본문으로 건너뛰기
JournalTORIS / FIELD NOTES

← 블로그 프로젝트 기록

장면을 바꾸면 사라지는 도구: Drawer 저장 시점을 돌아보다

AlgeoMath 도구의 getData를 장면 전환 시 호출하며 겪은 문제를 바탕으로, React의 정리 함수와 사용자 데이터 저장의 책임을 구분한다.

약 2분 읽기

#회고 #React #useEffect #AlgeoMath

유주환 · Founder, Full Stack Developer

토리스(Toris) · 발행

프로젝트를 돌아보는 30일 · 3/30
과거 프로젝트 경험을 날짜별로 엮은 회고입니다. 표시 날짜는 연재 기준일이며, 실제 작업일과 다를 수 있습니다.

이 글의 목차
현재 장면 ID 확보, 살아 있는 도구의 스냅샷 읽기, 저장 결과 확인, 장면 이동의 순서와 도구 준비 상태 확인을 나타낸 개념도.
개념도 — 도구 준비 상태를 확인하고 스냅샷 저장을 마친 뒤 장면을 이동하는 순서.

교육 뷰어의 Drawer에서 장면이 바뀔 때 도구 데이터를 저장하려고 했다. tool?.api.data.getData()로 현재 내용을 읽고 다음 장면에서는 setData()로 복원하는 흐름이었다. 문제는 장면 번호가 달라질 때, 데이터를 읽으려는 순간 도구가 이미 유효하지 않을 수 있다는 점이었다.

오류가 없는데 저장도 없었다

옵셔널 체이닝은 도구가 없는 경우 예외를 피하게 해 준다. 하지만 저장이 필요한 상황에서 도구가 없다는 사실까지 해결해 주지는 않는다. 호출이 조용히 생략되면 화면은 다음으로 넘어가고, 사용자는 이전 작업이 남았다고 생각할 수 있다.

당시 질문은 “왜 getData()가 호출되지 않을까?”였다. 지금 다시 보면 “누가 장면 전환을 시작하고, 그전에 누가 저장을 보장해야 할까?”가 더 정확한 질문이었다. 컴포넌트가 사라지는 시점과 사용자의 작업을 확정하는 시점은 반드시 같지 않다.

정리와 저장을 같은 일로 취급하지 않기

useEffect의 정리 함수는 구독이나 연결을 정리하는 데 필요하다. 다만 의존성이 변경되어 다시 실행될 때도 정리가 일어난다. 그래서 정리 함수에 중요한 저장 책임을 모두 맡기면 어떤 장면의 어떤 도구를 읽고 있는지 추적하기 어려워진다.

지금 다시 설계한다면 장면 전환을 하나의 명시적인 동작으로 묶겠다. 현재 장면 ID를 확보하고, 살아 있는 도구에서 스냅샷을 읽고, 저장 결과를 확인한 뒤 이동하는 순서다. 비동기 저장이라면 연속 클릭도 고려해야 한다. 저장이 끝나기 전에 두 번째 이동을 허용할지 결정해야 하기 때문이다.

다시 검증한다면

확인할 상황은 빠르게 다음·이전을 누르는 경우, 도구가 아직 준비되지 않은 경우, 데이터 읽기가 실패하는 경우다. 특히 “도구 없음”을 정상적인 빈 데이터와 구별하겠다. 빈 도형을 저장한 것과 도구를 읽지 못한 것은 복원 단계에서 같은 값으로 취급하면 안 된다.

당시 질문을 다시 읽으니 데이터 저장을 컴포넌트 수명에 너무 기대고 있었다는 생각이 든다. 중요한 데이터는 컴포넌트가 사라지는 순간보다 사용자의 전환 동작 안에서 책임을 드러내는 편이 이해하기 쉽다. 도구가 아직 살아 있을 때 무엇을 읽고 어디에 남길지부터 명시하겠다.

기술 참고: React useEffect의 정리 동작

READERS / LIVE

읽고 난 뒤의 대화

조회 —

댓글 삭제 시 필요합니다. 8–128자로 입력해 주세요.

댓글은 바로 공개됩니다. 개인정보와 공격적인 표현은 남기지 말아주세요.

    댓글 삭제

    댓글 작성 시 설정한 비밀번호를 다시 입력해 주세요. 삭제한 댓글은 복구할 수 없습니다.

    더 읽어보기

    2026년 8월 17일표지 한 장이 번호를 흔들었다: index에 너무 많은 의미를 담았던 경험2026년 8월 16일페이지가 바뀌면 클릭 연결도 바뀌어야 했다2026년 8월 12일교육 콘텐츠를 만들며 배운 것: 원본과 풀이 상태를 나누는 이유
    TORIS

    INDEPENDENT DEVELOPER
    BASED IN KOREA

    korea@toris.krEnglish home ↗