ModelAid CEO's MacBlog

이제 KimsQ 를 이용해서 포럼을 구성하는 작업은 거의 마무리된 것 같습니다.

포인트를 어디에 사용할 수 있을런지에 대한 운영 방법상의 규칙은 아직 마련되지 않았지만 실제로 포럼이 운영되는데 필요한 기본적인 환경 설정은 마무리되었다고 할 수 있죠.

하지만 슬슬 소스들에 대한 이해도가 높아지다 보니 하나의 사이트에서 여러개의 계정이 필요하거나 혹은 계정이 필요없다고 하더라도 서비스 레이아웃을 통일시키는 것이 여러모로 편리할 것 같다는 생각이 드는데 현재로서 가장 아쉬운 부분중의 하나는 바로 MacWiki 의 완전하게 다른 방식으로 구성되는 글쓰기 방식을 전체 레이아웃 안으로 들여오는 것입니다.

KimsQ 는 기본적으로 Wiki 와는 다른 형태의 글쓰기 방법론인 관계로 이를 이용해 위키를 자동으로 구성하기에는 너무나 많은 난관이 있으리라 생각됩니다.

하지만 가상발행이나 스킨의 조정 또는 프론트 페이지 수정등의 여러가지 기능을 혼합하다보면 이런 것들이 가능해지지 않을까 하는 고민도 약간은 해 보게 됩니다.

굳이 이런 고민을 하는 이유는 이미 KimsQ 를 메인으로 사용하기로 결정했고 여러가지 기능 테스트도 성공적으로 마친 상태이나 여전히 Wiki 의 글쓰기 방식이 편리한 콘텐츠들이 있기 때문입니다.

한편으로는 KimsQ 엔진이나 스킨 계열에서 이러한 기능까지 소화해준다면 발코딩을 해야만 하는 저로서는 무척이나 감동스럽겠지만 아무래도 당분간은 계획이 없어 보이기에 눈물이 앞을 가릴 뿐입니다.

외부로 표현되지는 않겠지만 내부적으로 이런 저런 테스트를 진행해 보면서 KimsQ 엔진을 이용한 Wiki 방식의 글쓰기를 구현하는 것에 대해 조금 더 고민해 볼 계획입니다.

물론 어느정도나 제가 필요로 하는 기능들을 구현할 수 있을런지는 미지수지만 뭔가 성공의 기운이 보인다면 낼롬 자랑하고 방법을 공개하도록 하겠습니다.

아무래도 kimsQ 내부 루틴에서 군데군데 변수를 재설정하는 부분이 있지 않을까 싶어서 소스를 뒤적거려봤더니 대략 40여개의 파일에서 상대주소형 변수가 튀어나왔습니다.

이런 저런 방법을 강구해도 문제를 해결할 수 없는 경우 최후의 수단으로 이 파일들에 있는 상대 주소 소스를 전부 수정하는 방법도 있겠으나...

나중에 kimsQ 가 업데이트 될 경우에는 또 다시 이 과정을 반복해야만 하는데 사실 이 방법이 얼마나 위험한지는 이전에 사이트를 운영하면서 프로그래밍을 자주 수정할 때 경험했던 것이라 끝까지 손대고 싶지 않은 것이 사실입니다.

서버 환경에서 리다이렉션시키는 것도 생각해보고 싶지만 상대주소라는 것의 특성상 그 방법 자체가 불가능할 것이라 생각됩니다.

일단은 이런 일이 있었다는 기록용 포스팅으로 흔적을 남겨둡니다.