React의 useEffect에서 배운 DB의 Trigger

[Henry-Hong]

배경

• Vibe Coding을 하던 중, AI가 데이터베이스 정의를 할 때, trigger를 많이 사용하는것을 발견했다.
• 분명 DB수업때 trigger의 단점이 많아서 실무에선 잘 안쓴다고 했었는데,, 그때 졸아서 잘 기억이 안났다.
• 그래서 trigger를 FE 경험을 바탕으로 다시 이해해보기로 했다.

useEffect와의 관계

• 왜 갑자기 useEffect가 나오냐면, trigger와 useEffect는 '반응형 구조'라는 공통점이 있기 때문이다.
• 그렇다면, useEffect는 어떤 장단점이 있고, 비슷한 철학을 지닌 trigger는 어떻게 비교될까?

useEffect의 장단점

• 장점
  • 선언적으로 부작용(positive) 로직을 실행시킬 수 있다.
  • 또 뭐가 있지..?
• 단점
  • 무한 호출이 발생할 수 있다.
  • 디버깅 및 예측이 어려움. (디펜던시 변화를 일으키는 요소가 너무 많을 수 있고, 실행순서가 다소 직관적이지 않음)
  • 비교연산 오버헤드. (디펜던시 비교를 통해 실행시킨다)

trigger의 장단점

• 위의 useEffect의 장단점을 바탕으로, trigger의 장단점도 이해해본다.
• 장점
  • 특정 로직을 자동화하여, 깔끔하게 처리가능
• 단점
  • 순환 트리거 발생
  • 디버깅 및 예측이 어려움. (자동으로 실행되는 장점이 오히려 단점이 될 수 있음 + 암묵적 의존성(A테이블 변화가 B테이블 변화 유발) + 따로 분리해서 unit test를 할수도 없다고 한다)
  • 비교연산 오버헤드는 없지만, 실행 오버헤드가 있을 수 있다. (업데이트시 로그쌓는 이벤트가 있다고 한다면, 10만 업데이트시 -> 10만개의 INSERT, but 이건 충분히 배치처리 가능)

결론

• 반응형 구조라는 공통점을 바탕으로 useEffect와 trigger를 조금 더 깊게 이해할 수 있었다.
• 내가 생각하는 반응형 구조의 최대 약점은, '디버깅 및 예측이 어려움' 인것같다.
• 따라서 반응형 구조를 최대한 지양하거나, 쓸거면 최대한 직관적이고, 단순하게 설계해야한다고 생각했다.
• 예제) 최근엔 useEffect를 활용한 초기화 로직을 아예 컴포넌트 마운트시점으로 대체한다거나.. what else?

[al-bur]

반응형 구조를 최대한 지양하거나, 쓸거면 최대한 직관적이고, 단순하게 설계해야한다고 생각했다.

완전 동의합니다.
요새는 useEffect를 거의 기피하다싶을정도로 생각하게 되었어요 매번 새로운 코드를 탐색할때 어디서 막히지? 어디서 복잡도가 올라갈까? 생각해보면 컴포넌트 하나에 수많은 useEffect가 있을때더라고요ㅠㅠㅠㅠ