hook 기능의 한계에 대해 질문드려요. 정보
hook 기능의 한계에 대해 질문드려요.
본문
이건 기능에 대한 질문이 아니라,
사용해 본 분들의 경험상 후기가 필요해서 여기에 질문드립니다.
그누보드의 기본 코어를 건드리지 않고도 기능을 추가할 수 있는
hook 기능은 매우 훌륭한 기능입니다.
그런데, hook를 사용해도 해결할 수 없는 한계는 무엇이 있었나요?
또는 hook를 사용해서는 안 되는 것에는 무엇이 있을까요?
즉, 결국은 코어를 건드려야 했던 경험담이 궁금합니다.
추천
1
1
댓글 4개

기능 자체에는 문제가 없지만 아직 배치된 곳이 좀 부족합니다. 영카트 쪽은 최근에 제가 추가한 것을 제외하면 더 열악했었고요.
아쉬운 부분은 hook 대부분이 충분한 데이터를 넘겨주지 않는다는 겁니다.
몇가지 간단한 정보는 넘겨주지만 활용할 수있는 정보가 제한되어있기 때문에 이벤트를 받아서 전역변수에서 정보를 수집해야하고, 이는 데이터의 무결성에 취약하죠.
그래도 어쩔 수 없이 전역변수에 의존해서 처리할수 밖에 없죠. 예외상황을 고려해야하지만 어쨌든 그걸로도 대부분 동작은 시킬수는 있습니다.
어차피 모든 상황에 만족시킬수는 없으니 hook이 넘겨주는 정보에 제한은 있을수밖에 없긴합니다. 다만, 전역변수에 너무 의지하지 않도록 규격화된 인터페이스를 제공해줬으면 좋겠는데 그것도 너무 큰 희망사항이겠다 싶습니다.
전역변수에 의존하는 것들이 많아질수록 그누보드가 발전하는데에는 걸림돌이 되어갈겁니다.
호환성 유지 때문에 그누보드의 발전이 멈춘것처럼 전역변수에 의존하는 플러그인이 많아질수록 그누보드의 발전을 가로막겠죠.
느리더라도 꾸준하게 리팩토링해서 정리해왔어야 했는데 그러지 못한 것이 업보가 되고 말았죠. 작년 한해 동안 냑 개발팀의 많은 시도들도 무언가에 막혀 결국 물거품이 되어버린 것처럼요.
전역변수 의존은 지금의 구조를 더욱 개선하기 어렵게 합니다. API를 만든다해도 호환성을 유지하기위해 거기에 기존 동작하는 hook처럼 동일한 hook을 호출해야한다면 기존 코드에서 사용하는 전역변수를 그대로 흉내내는 코드를 작성해야만 호환성이 유지되겠죠. API에선 필요없는 데이터도 호환성을 유지하기위해 끌어다 전역변수에 넣어줘야만하죠.
그뿐인가요. 지금 있는 코드도 변경하지 못합니다. 그냥 코드의 일부일 뿐인, 그냥 이름일 뿐인 변수명 하나 바꿨다가는 hook을 사용하는 플러그인의 동작이 망가질 수 있습니다.
그누보드는 이 굴레에서 벗어나지 못하게 됩니다. 호환성을 포기하지 않는한 그누보드는 변수명 하나도 바꾸지 못하는 처지가 됐습니다. 인터페이스를 제공하지 않았기 때문에 변수명마저 바꾸지 못하는 처지가 된거죠.
$member, $board 이런 그누보드의 주요 변수명만 해당하는 것이 아닙니다.
게시판, qna, 영카트 등 hook이 붙은 모든 곳에서 그 훅을 사용하는 플러그인이 어떤 변수명을 참조해서 동작할지 알수없기 때문에 거의 모든 변수명이 영향범위에 있다고 봐야겠죠.
아쉬운 부분은 hook 대부분이 충분한 데이터를 넘겨주지 않는다는 겁니다.
몇가지 간단한 정보는 넘겨주지만 활용할 수있는 정보가 제한되어있기 때문에 이벤트를 받아서 전역변수에서 정보를 수집해야하고, 이는 데이터의 무결성에 취약하죠.
그래도 어쩔 수 없이 전역변수에 의존해서 처리할수 밖에 없죠. 예외상황을 고려해야하지만 어쨌든 그걸로도 대부분 동작은 시킬수는 있습니다.
어차피 모든 상황에 만족시킬수는 없으니 hook이 넘겨주는 정보에 제한은 있을수밖에 없긴합니다. 다만, 전역변수에 너무 의지하지 않도록 규격화된 인터페이스를 제공해줬으면 좋겠는데 그것도 너무 큰 희망사항이겠다 싶습니다.
전역변수에 의존하는 것들이 많아질수록 그누보드가 발전하는데에는 걸림돌이 되어갈겁니다.
호환성 유지 때문에 그누보드의 발전이 멈춘것처럼 전역변수에 의존하는 플러그인이 많아질수록 그누보드의 발전을 가로막겠죠.
느리더라도 꾸준하게 리팩토링해서 정리해왔어야 했는데 그러지 못한 것이 업보가 되고 말았죠. 작년 한해 동안 냑 개발팀의 많은 시도들도 무언가에 막혀 결국 물거품이 되어버린 것처럼요.
전역변수 의존은 지금의 구조를 더욱 개선하기 어렵게 합니다. API를 만든다해도 호환성을 유지하기위해 거기에 기존 동작하는 hook처럼 동일한 hook을 호출해야한다면 기존 코드에서 사용하는 전역변수를 그대로 흉내내는 코드를 작성해야만 호환성이 유지되겠죠. API에선 필요없는 데이터도 호환성을 유지하기위해 끌어다 전역변수에 넣어줘야만하죠.
그뿐인가요. 지금 있는 코드도 변경하지 못합니다. 그냥 코드의 일부일 뿐인, 그냥 이름일 뿐인 변수명 하나 바꿨다가는 hook을 사용하는 플러그인의 동작이 망가질 수 있습니다.
그누보드는 이 굴레에서 벗어나지 못하게 됩니다. 호환성을 포기하지 않는한 그누보드는 변수명 하나도 바꾸지 못하는 처지가 됐습니다. 인터페이스를 제공하지 않았기 때문에 변수명마저 바꾸지 못하는 처지가 된거죠.
$member, $board 이런 그누보드의 주요 변수명만 해당하는 것이 아닙니다.
게시판, qna, 영카트 등 hook이 붙은 모든 곳에서 그 훅을 사용하는 플러그인이 어떤 변수명을 참조해서 동작할지 알수없기 때문에 거의 모든 변수명이 영향범위에 있다고 봐야겠죠.


hook 을 사용해도 안되는 건
처음부터 이건 후킹으로 안 될 거라는 강한 확신이 옵니다.
그런건 아예 시도조차 안하죠.
그러니 애초에 한계에 대한 고민이 없습니다.^^
단 only 자바스크립트로 만드는 건 거의 한계가 없습니다.
tail 에서 폐이지 판별 후 원하는 엘레먼트 안으로 동적으로 끼워넣는 작업이 대부분이라서요.
처음부터 이건 후킹으로 안 될 거라는 강한 확신이 옵니다.
그런건 아예 시도조차 안하죠.
그러니 애초에 한계에 대한 고민이 없습니다.^^
단 only 자바스크립트로 만드는 건 거의 한계가 없습니다.
tail 에서 폐이지 판별 후 원하는 엘레먼트 안으로 동적으로 끼워넣는 작업이 대부분이라서요.

@비타주리 :
오.. 키워드 찾았습니다. "끼워넣는 작업"... 감사합니다. ^^
오.. 키워드 찾았습니다. "끼워넣는 작업"... 감사합니다. ^^