초기 구현에서는 set_prompts before_action이 프롬프트 목록을 초기화하고 채웠습니다. 이후 공통 메시지를 add_callback_notices 메서드로 분리하고 별도의 before_action으로 호출했을 때도, 콜백은 정의된 순서대로 (set_prompts -> add_callback_notices) 실행되어 문제가 없었습니다.
Concern 도입과 콜백 순서 문제
그러나 이 add_callback_notices 로직을 Callbackable Concern으로 이동하고 Concern 내에서 included 블록을 통해 before_action :add_callback_notices를 정의한 후, 컨트롤러에서 include Callbackable을 before_action :set_prompts보다 먼저 배치하자 NoMethodError가 발생했습니다. 이는 Callbackable Concern의 before_action이 @prompts 변수가 초기화되기 전에 실행되어 nil 객체에 << 연산을 시도했기 때문입니다.
문제 해결 및 대안
-
include순서 조정: 이 문제를 해결하기 위해서는before_action :set_prompts가 먼저 실행되도록include Callbackable구문을before_action :set_prompts뒤에 배치해야 했습니다. 이는 콜백의 정의 순서 규칙이 Concern의included블록 내before_action에도 동일하게 적용됨을 의미합니다. -
include순서의 모호성: 하지만include문의 위치가 다른before_action콜백의 실행 순서에 영향을 미친다는 점은 코드의 가독성과 유지보수성을 저해할 수 있습니다.include순서에 대한 명확한 맥락이 없으면 개발자가 의도치 않게 순서를 변경하여 버그를 유발할 가능성이 있습니다. -
대안: Concern에서 콜백 정의 제거: 대안으로는 Concern 내에서
before_action을 직접 정의하지 않고, 단순히 공통 메서드(add_callback_notices)만 정의하는 방식이 제시됩니다. 이 경우 컨트롤러에서는 Concern을include한 후, 필요한 위치에before_action :add_callback_notices를 명시적으로 추가하여 콜백 순서를 직접 제어할 수 있습니다. 이 방법은include문의 위치에 대한 제약을 없애고, 컨트롤러 내에서 모든 콜백의 실행 순서를 한눈에 파악할 수 있게 하여 코드의 명확성을 높입니다.