Ruby 정규표현식의 /o 옵션: 위험한 최적화

/o 옵션은 ‘보간 모드(Interpolation mode)’로 알려져 있으며, Ruby는 보간된 정규표현식을 처음 만났을 때 생성된 Regexp 객체를 저장하고 이후 모든 평가에 재사용합니다. 즉, 정규표현식 내부에 삽입되는 변수(#{input})는 첫 번째 실행 시의 값으로 고정되어 이후에는 변경되지 않습니다. 이는 동적인 정규표현식이 사실상 불변의 상수로 작동하게 만듭니다. 이 현상을 이해하기 위해 Ruby VM의 바이트코드를 분석한 결과, once라는 특별한 명령어가 발견되었습니다. once 명령어는 insns.def 파일에 정의되어 있으며, vm_once_dispatch 함수를 통해 캐싱 로직을 구현합니다. 이 함수는 이미 캐시된 값이 있으면 즉시 반환하고, 없으면 현재 스레드가 값을 계산하여 캐시하며, 다른 스레드들은 해당 값이 생성될 때까지 대기합니다. 이러한 메커니즘은 다중 스레드 환경에서 비결정적인 동작을 유발하며, 어떤 스레드가 먼저 값을 캐시하느냐에 따라 결과가 달라지는 ‘하이젠버그’와 같은 문제를 야기할 수 있습니다. 또한, reload!와 같은 코드 재로드 상황에서는 once 캐시가 재설정될 수 있지만, 이는 오히려 비결정성을 더욱 심화시킬 수 있습니다. /o 옵션은 Perl에서 유래된 것으로 추정되며, 성능 최적화를 목적으로 도입되었을 수 있으나, 2003년에도 ‘절대 사용하지 말라’는 의견이 지배적일 정도로 그 부작용이 큽니다. 수동으로 정규표현식을 캐싱하는 것이 훨씬 안전하고 명확한 대안입니다. 흥미롭게도, 이 once 명령어는 /o 옵션 외에도 Ruby의 END 언어 구문(프로그램 종료 시 실행되는 블록)에서도 사용됩니다. 이는 once 명령어가 특정 정규표현식 최적화만을 위한 것이 아님을 보여줍니다. 그러나 /o 옵션의 경우, Once 클래스 구현 사례에서 볼 수 있듯이, 스레드 안전성을 보장하면서 한 번만 실행되도록 하는 데 사용될 수 있지만, 인스턴스별 동작이 아닌 명령어 수준의 전역 캐싱으로 인해 여러 인스턴스에서 동일한 정규표현식을 사용할 때 문제가 발생합니다. 결론적으로, /o 옵션은 그 의도가 어떻든 간에 실제 사용에서는 예측 불가능하고 디버깅하기 어려운 버그를 초래할 가능성이 매우 높습니다.