가끔 엄청나게 오래된 일을 한참을 돌아와서 해결하게 된다.
텍스트큐브가 태터툴즈였던 시절, 작년 중순즈음엔가 fastCGI 환경 지원에 대한 요청이 들어온 적이 있었다. 당시에는 서버에 fastCGI 환경을 쉽게 구축하지 못하였고, 그래서 자연히 뒤로 밀리게 되었다. 이후 조금씩 workaround들을 통하여 구현을 해 놓았지만 역시 제대로 돌아가지는 못하고 있었다.
작년 말에는 '외국계 호스팅에서 태터툴즈가 잘 안돌아간다' 는 문의를 받았다. 직접 서버의 권한을 받아 들어가 본 결과 서버측에서 mod_rewrite에 대하여 선처리를 미리 해 둔 상태였다. 이 경우를 처리하기 위해서는 rewrite 모듈1 에 대한 의존도를 확 줄여야 했다. 이런 경우에 주로 사용하는 방법은 rewrite 모듈의 모든 결과를 하나의 파일로 보내고, 그 파일이 요청을 모두 해석해서 처리하는 방식이다. 그러나 당시 간단하게 테스트 해 본 결과 그림파일이나 음악파일 등등등 까지도 모두 php 엔진을 거쳐서 내보내기 때문에 서버에 무리가 있었다. 소스도 엄청나게 고쳐야 했다. 기존의 방식을 고수하기가 힘들어 보였다. 소스를 대대적으로 개수하기에는 언제나 시점의 무리가 있어서 계속 그 일은 뒤로뒤로 밀려왔다.
그러면서 1년이 넘는 시간이 지났고, 잘은 모르지만 머릿속 어딘가에서 그 생각이 계속 돌아가고 있었나보다. rewrite 모듈이 없는 상황에서 돌아가는 예외 처리를 추가한다거나, fastCGI를 지원하는 예외 처리를 추가한다거나 하는 식으로 대응해 가다가 사흘쯤 전 샤워하다가 아이디어가 떠올랐다. define으로 상수를 정의하는데, 그 상수를 두 번 정의할 경우 어느쪽이 무시되는가? 에 대한 생각이었다. 실험해 보니 처음 define만이 유지되었다. 그 때부터는 문제가 연속적으로 죽 풀렸다.
텍스트큐브는 /lib/suri.php 를 통하여 현재 주소 체계를 해석하고, 어떤 부분이 주소이고 어떤 부분이 파라미터인지 파악해 낸다. 그리고 각 인터페이스 (blog 하위의 디렉토리들은 사실 인터페이스라고 부르는 것이 더 적당하다.) 에서 필요한 라이브러리를 통째로 불러낸다. 과거에는 불가능했지만, 두달 사이에 이루어졌던 컴포넌트 및 라이브러리의 독립화로 인하여 라이브러리를 불러오는 시점의 의존성이 사라졌다. 따라서 suri가 실제로 동작하기 이전이라면 주소 처리 부분을 기존의 suri가 이해하기 좋게 만들어서 suri에 코드 한 줄을 추가하여 호환성을 유지할 수도 있을 것이다. 또한 각 인터페이스에서는 모든 포함관계의 기준이 되는 ROOT를 미리 정의하는데, 인터페이스 파일이 불려지기 이전에 ROOT를 일률적으로 정의해 버리면 이후의 모든 파일 포함관계들도 전부 수정 없이 이식할 수 있지 않을까.
그래서 크리스마스 이브 전날부터 크리스마스 기간 내내 그 부분을 구현하였다. 일단 (못 고치면 블로그 못쓴다-는 자신에게로의 압박을 위해서) 개인 서버의 아파치 웹서버를 fastCGI 기반으로 변경하였다. rewrite 모듈이 보내주는 값을 해석하는 부분은 최소한의 크기로, 또한 앞에서 처리해야 유리한 루틴은 최대한 앞에서 처리하는 식으로 작성하였다. 덕분에 기존 코드는 거의 손을 대지 않은채로, fastCGI나 다양한 rewrite module들에 대한 대응이 가능해졌다.
말이 길었다. 결론은 간단하다. 아이디어는 하늘에서 떨어지지는 않는다. 그렇다고 아이디어를 낼려고 머리 싸매고 있다고 튀어 나오는 것도 아니다. 문제를 완벽히 이해할 때 까지 생각하고 곱씹는 과정에서 문제의 한계라고 스스로 생각하고 있는 무엇인가를 넘기위한 뇌의 싸이코 댄스가 시작된다. 그 댄스 중 일부가 실제로 먹히면 그 댄스에 아이디어라는 이름이 붙게 된다.
아이디어는 사고의 형태에 붙는 명칭이 아니라 이미 일어난 사고에 붙이는 자격이다.