사이드프로젝트 slecs

입력모드 명시 토글로 포매팅 상태 누수 차단

목차

이번에 텍스트 발행 시스템에서 볼드 입력모드의 상태 누수 문제를 수정했다. lib_publish.js 의 포매팅 로직에서 굵은단어, 일반 텍스트, 단락 끝의 모드 전환을 명시적으로 토글하도록 강화한 작업이다.

상태 기반 시스템에서의 암묵적 제어

텍스트 포매팅 시스템은 본질적으로 상태 머신이다. 특히 마크다운이나 리치 텍스트 포매팅을 다룰 때, "지금 굵은텍스트를 쓰고 있는가", "단락이 끝났는가" 같은 상태를 추적해야 한다. 이 상태들이 제대로 관리되지 않으면 예상치 못한 포매팅이 발생한다. 굵은텍스트가 끝나야 할 지점에서 계속 진행되거나, 반대로 시작해야 할 곳에서 일반 텍스트로 나온다.

이전에는 각 입력 모드 간 전환이 암묵적이었을 것 같다. 즉, 코드가 "상태를 변경해야 한다"고 판단할 때 자동으로 전환하되, 그 지점을 명확하게 제어하지 않았던 것이다. 이렇게 되면 한 곳에서 상태를 변경하고도 다른 곳에서 그것을 인식하지 못하거나, 역으로 같은 상태 전환이 여러 번 일어나기도 한다. 이를 "상태 누수(state leakage)"라고 부르는데, 디버깅하기 매우 까다로운 버그다. 왜냐하면 상태 변화는 메모리에만 남아있고, 입출력 로그로는 명확하게 드러나지 않기 때문이다.

명시적 토글로 제어점 확보

이번 수정은 입력모드 전환 지점을 모두 명시적으로 나열했다. "굵은단어 ON → 일반 OFF → 단락끝 OFF" 라는 메시지는 세 가지 상태 전환을 명확히 한다는 뜻이다.

전환 지점 목적 효과
굵은단어 ON 굵은텍스트 블록 시작 이후 텍스트가 굵음 포매팅 적용
일반 OFF 굵은텍스트 블록 종료 이후 텍스트는 일반 포매팅으로 복귀
단락끝 OFF 모든 포매팅 상태 초기화 다음 단락은 깨끗한 상태에서 시작

이렇게 각 단계를 명시적으로 호출하면 몇 가지 이점이 생긴다:
- 디버깅 용이: 상태 전환 로그를 찍거나 어느 단계가 빠졌는지 코드 리뷰로 식별 가능
- 테스트 가능성 향상: 각 상태 전환마다 테스트 케이스를 작성할 수 있음
- 예측 가능성: 코드를 읽는 누군가(또는 6개월 후의 나)가 "여기서 상태가 바뀌네" 라고 명확하게 이해할 수 있음

팀의 상태 관리 패턴 정리

이 작업을 하면서 느낀 점은, 상태 기반 시스템에서는 암묵적(implicit)이 적의라는 것이다. 컴파일러나 런타임이 자동으로 뭔가 해주는 것 같으면, 결국 누군가가 그 "자동"을 이해하지 못해 버그를 낸다.

비슷한 패턴이 코드베이스 곳곳에 있을 것 같아서, 코드 리뷰 때 다음을 체크리스트로 삼았다:

  • 상태가 여러 개인가? → 명시적으로 초기화/전환하는 부분이 있는가?
  • "자동으로 리셋된다" 라는 주석이 있는가? → 누가 언제 그것을 보장하는가?
  • 테스트에서 같은 상태 전환을 여러 시나리오로 확인했는가?

마크다운/리치텍스트 처리, 권한 상태, 캐시 무효화 같은 부분들도 이 원칙을 적용하면 버그를 줄일 수 있다.


🛒 이 글과 어울리는 추천 상품

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.

댓글 0

첫 댓글 달아줘.