ModelAid CEO's MacBlog

아래에 있는 것들을 체크해 보고 활용 가능한 부분들이 있는지 살펴봅시다.
참으로 할 것 많아 즐거운 세상이로군요.

• http://expressionengine.com/
• http://sypex.net/en/
• http://fengoffice.com/web/
• http://xinha.webfactional.com/
• http://www.openx.org/ (http://www.openx.org/docs/qsg-install)
• http://collabtive.o-dyn.de/
• http://www.mollify.org/
• http://www.mollify.org/
• http://www.sqlbuddy.com/
• http://www.group-office.com/

utf-8 로 저장을 해도 무슨 일인지 utf-8, no-BOM 으로 저장되는 바람에 불필요한 공백에 의한 에러가 발생하는데 한두번 당하는 것도 아니면서 매번 생각 날때마다 소스를 수정하다보니 또 다시 에러 어택속에 휘말려 있군요.

vnc 라도 되야 집에 있는 맥에 접속이라도 해서 손이라도 급하게 볼텐데 잠시 쉬는 시스템마저 없으니 그것도 힘들고...

아~ 나중에라도 iPad 사게 되면 이런 부분도 깔끔하게 확인해 보고 사야 할텐데...
ㅠㅠ

일단 10.4 버전에서의 수정은 포기하고 그냥 뭘 해야겠다는 메모만 남겨야 겠습니다.

ps. 근데 요즘 집에서 컴퓨터를 만지는걸 극도로 싫어라 하니 이것도 쉽지만은 않군요.

페이지의 타이틀은 함수를 이용해서 각 페이지별로 적절하게 구성되도록 했는데...

조금 더 욕심이 나는 부분은 메타 태그의 Description 과 Keyword 부분이로군요.

메타 태그의 Description 을 구글에서는 무시하겠다라고 하지만 여타 검색 엔진들도 이 부분을 버리기 전까지는 어떻게든 최적화해 주는 것이 좋을 것 같은데... 사실 외부 검색 엔진보다도 내부 검색엔진으로 사용하고 있는 OrcaSearch 에서도 이 부분은 문제가 발생하는군요.

이전 포스팅에서 말씀드렸던 것처럼 내부 검색 엔진 최적화를 위해 이런 저런 테스트를 진행하던 도중 메타 태그의 Description 과 Keyword 를 모두 삭제하고 스파이더링해 봤더니 모두 다 동일한 파일로 인식하고 검색 결과에서 차근차근 지워나가 버리더군요.

그래서 현재 생각하고 있는 방법으로는 해당 페이지의 일정 부분 - 예를 들면 article 태그 사이의 본문 내용만을 추출해서... (이 부분은 해당 콘텐츠를 구성하는 페이지의 함수에서 불러오면 가능하도록 되어 있습니다.) HTML 요소들은 삭제해버린 후에 (php 함수를 이용하면 한방에 해결되겠죠) 메타 태그에 변수로서 입력해 주는 방법이 있겠는데 현재 구성해 놓은 페이지 구성법과 순서가 맞지 않는 안타까움이 발생하고 있습니다.

현재 페이지 구성 방식은...
어떤 페이지가 로딩되면... 그 내부에 사용되는 다양한 변수들을 '환경설정 php 연산 파일' 에서 계산한 후에 관련된 요소들을 변수값으로 제공하게 됩니다. (이를테면 각 페이지의 네비게이션과 aside 메뉴를 어떤 것을 사용할 것인가를 판단하는 그런 요소입니다.)
이렇게 기본적인 변수를 계산하고 나면 스킨 파일을 불러오면서 위에서 설정한 경로별 파일을 불러와 CSS 에 맞춰 차근 차근 렌더링하는 방식입니다.

요즘 고민하고 있는 것중에 위의 CSS 조차도 함수로 정리해버리고 싶다는 것인데 최근 OrcaSearch 라는 검색엔진에 최적화하기 위한 이런 저런 테스트를 하면서 잠시 삼천포로 방향을 틀고 있는 중입니다.

여튼... 이렇게 필요한 파일들의 경로를 먼저 계산하고, CSS 기반으로 렌더링하는 도중에 페이지 본문 내용을 삽입해야 하는 article 부분을 만나면 실질적인 콘텐츠를 이루게 되는 내용을 불러오게 되는데 현재 이 글을 쓰면서 고민을 하고 있는 부분은 이 콘텐츠 페이지를 부르기 전에 완성되어 버리는 메타 태그에 나중에 불러오게 되는 콘텐츠 내용을 넣을수 있을 것인가에 관한 고민인 것입니다.

물론 간단한 방법으로 환경변수선언+스킨의 형태로 페이지를 변환하고, 환경변수 선언을 다 마친 후에 그 내용중에서 메타태그를 설정해 버리는 방법도 있겠지만 그러다 보면 실제 페이지를 구성하게 되는 모든 내용을 로딩하고 나서야 페이지 렌더링을 시작하게 될테니 사이트 이용에 있어 매우 거슬리는 구조가 될 것이 자명해서 그 방식은 사용하지 않으려 하고 있습니다.

그렇다면 헤드 태그가 아닌 다른 부분에 메타 태그를 넣어서 활용할 수 있는지에 대해서 약간의 꽁수를 찾는다거나 페이지 완성 후에 글을 읽는 시간 (정상적 움직임이라면 아무리 적어도 프로세스가 함수를 처리하는 시간보다는 길겠죠~) 동안 태그를 처리해서 살포시 끼워넣는 방법이 있다면 더욱 좋겠지만 아직까지는 방법을 알지 못하겠군요.

혹시라도 이런 방법에 대해 관심이 있으시거나 해법을 알고 계시는 분이 있다면 힌트라도 주셨으면 합니다.

사이트 리뉴얼 후 검색 봇들의 방문으로 페이지 뷰는 미친듯이 올라가고 있지만 실제로 필요했던 사용자의 액션 트래킹에 대한 부분을 모으기에는 직접적인 활동이 아직 빈약하다고 생각되는 바 액션 트래킹에 대한 체크를 대폭 축소합니다.




혹시라도 개인정보 수집등의 오해가 있을까봐 그간 설치되어 운영되고 있던 것들을 미리 말씀드리자면...
Piwik 과 Twatch 라는 로그 기록과...
카운터 기능으로 사용하기 위한 na@log...
화면상에서 클릭되는 위치만을 체크하는 clickheat...
Daum Inside Tag...
(헉... 적고 나니 무척이나 많았군요.)
입니다.

이중에서 호감이 가는 녀석은 Piwik 과 Twatch 인데 다른 것들은 없애버리더라도 이 두 녀석은 제공해주는 정보 방식이 확연히 차이가 나서 당분간 이 두 녀석만 운영하도록 하겠습니다.


덧... (2010. 9. 7. 20:58)


그리고 ClickHeat 의 경우에도 UI 가 통합된 이 마당에 각 섹션별로 많은 활용도를 보이는 것이야 로그 기록을 분석하면 나오는 것이므로 중복 체크의 기운도 있어 아예 없어버릴까 싶기도 하구요.

마지막 Daum Inside Tag 의 경우 외부의 엔진을 이용해 트래킹을 해 보자는 의미로 설치했었는데 Piwik 과 Twatch 의 경우도 상당한 신뢰도를 보이므로 굳이 어떤 내부 작용을 하는지 알기 힘든 외부 코드를 삽입하는 것도 조금은 조심스러워 집니다.

뭔가 더 결정이 되면 덧덧으로 적어두도록 하겠습니다.

기존에 사용하던 내부 검색 엔진에서 사용되었던 검색 쿼리 모듈을 추억으로 남겨놓습니다.

아직 스톰보드를 사용하시는 분들은 그다지 많지 않을거라 생각되지만 혹시라도 Stormboard + na@search 를 이용해 html 콘텐츠와 게시판의 통합 검색을 하고자 하신다면 아래에 있는 코드를 카피해 stormboar.php 로 저장하신 후 na@search 의 module 에 넣으시면 na@search 를 통해 스톰보드 게시물들도 통합 검색하실 수 있습니다.

stormboard.php

<?
##########################################################################
// n@search module
##########################################################################
// 모듈 설명 : zero board 4 기본 모듈
// 모듈 제작자 : navyism (http://navyism.com)

$module_mode = 1; // 0:웹페이지 1:게시판
$module_title = "모듈 타이틀"; // 모듈이름
$module_list_file = "sboard.php"; // 목록파일
$module_view_file = "view.php"; // 내용파일
$module_id_name = "code"; // 게시판구분자
$module_table_id = "stormb_{ID}"; // 테이블이름형식 ({ID}는 구분자)
$module_table_ban_word = ""; // 테이블제외형식
$module_col_primary = "num"; // 기본키컬럼
$module_col_writer = "name"; // 글쓴이컬럼
$module_col_subject = "subject"; // 글제목컬럼
$module_col_contents = "contents"; // 글내용컬럼
$module_col_mail = "mail"; // 이메일컬럼
$module_col_home = "homepage"; // 홈페이지컬럼
$module_col_secret = "secret"; // 비밀글컬럼
$module_secret_value = "T"; // 비밀글일때의값
$module_col_date = "dates"; // 작성시간컬럼
$module_date_converting = 1; // 0:시간보존 1:시간변환 (유닉스타임스탬프)
?>

그리고 혹시라도 이 모듈을 사용했을 때 변수값들을 어떻게 적용해야 하는지 모르시는 경우가 발생할지 몰라 제가 사용하던 스킨도 업로드해 놓겠습니다.

얼마전까지 열혈 달음박질을 하다가 검색엔진과 로그 기록 관련된 내용으로 몇일 정신을 못차리느라 잠시 중단한 내용을 잊지 않기 위해 정리해 두려 합니다.


시간은 조금 걸리더라도 차츰 정리가 되고 하나씩 구현이 되겠지요.

1. CSS 내용을 변수를 이용한 형태로 변환
• 작업을 진행하면서 모델에이드에 현재 사용되고 있는 CLASS 와 ID 를 모두 정리할 계획임
• 안타깝지만 가급적 IE 6 버전에서도 사이트를 볼 수 있도록 CSS 구성
2. Library, Explore 메뉴 재구성 검토
3. Macblog 스킨 규격화
4. 기존 게시판의 게시물 이동에 관한 고민 및 기술적 검토
5. 검색엔진 최적화
• 거창한 SEO 까지는 아니고 내부 검색엔진이 스파이더링하는 시간과 콘텐츠 업데이트 되는 시점 (게시판 포함)을 최적화해서 가급적 최단 시간 내에 내부 검색에 반영되도록 할 것

우선 생각나는 정도는 이정도로군요.

하나 하나가 복잡스럽긴 하지만 그래도 뭐 천천히 나가는 것이니 바쁘게 서두를 생각은 없고, 그보다 화들짝 놀라게 되는 큰 문제나 생기지 않았으면 좋겠네요.

최근에 과도한 작업으로 리뉴얼을 했지만 과연 제대로 가고는 있는걸까? 하는 의구심은 머리 한 구석에서 떠나질 않고 있었습니다.

그러던 중 통합 검색기에서 '리뉴얼' 이라는 주제로 검색한 후에 아주 아주 예전에 포스팅했던 글을 하나 다시 읽어 보았습니다.

글은 남아있는 리뉴얼꺼리... 그리고 새로운 구상들... 이라는 글인데 무려 2006년 말경에 정리한 것인데도 현재 나아가고 있는 방향과 그다지 다르지 않음에 잠시 깜짝 놀랐었습니다.

일단은 현재까지 가고 있는 길이 많이 틀려지지 않았음을 확인하게 되었으니 조금 더 계획을 다듬어 계속 나아가도록 해야겠습니다.

그런데 그 시절에는 php 에 대해서 해독할 수 있는 능력도 없을때였는데 어찌 저런 무지막지한 계획들을 세워놨는지 모르겠군요.

여튼 조만간 수정된 나아갈 방향에 대해서 정리를 해 봐야겠군요.


ps. 요 몇일간 가장 머리 복잡하게 노력하고 있는 부분은 기존의 콘텐츠 페이지뿐 아니라 게시판이나 블로그를 통해 글을 작성했을 때 얼마나 빨리 검색엔진에 등록될 수 있도록 하느냐에 관한 것입니다. 전문용어로 하면 SEO 라고 해야 할라나요~ 테스트해 본 결과 하루가 되기 전에 구글을 통해서는 등록이 되던데 어느정도로 시간 간격을 최적화했을때 가장 효과가 좋을런지에 대해 여러모로 테스트를 진행중입니다.

참고삼아 이전에 정리했던 내용중 진행된 것들에 대해서는 표시를 해 둬야겠군요.

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

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

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

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

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

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

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

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

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

일단 이번 작업의 시작은 시간을 거슬러 올라가 서버 환경 업그레이드를 하면서부터 시작됩니다.

euc-kr 인코딩으로 그간 사용하고 있었던 서버 환경을 utf-8 로 업그레이드하면서부터 기존의 데이터베이스에 있던 인코딩된 수많은 레코드들은 모두 꼬이기 시작했고, 그것들을 보여주는 프로그램들의 인코딩도 모두 꼬여버렸기 때문이죠.

아마도 킴스큐 (인지 텍스트큐브 판올림인지) 설치할때부터가 아닌가 하는 기억이지만 어쨌거나 이미 상당히 오래전 얘기인지라 기억도 가물가물하군요.

일단은 기존 DB 를 조각 조각내어 euc-kr 로 열어서 utf-8 로 저장할 수 있는 부분은 그렇게 변환해서 저장하고, 그동안 쌓인 방식이 utf-8 이어서 텍스트 깨짐 현상이 없는 부분은 그런 부분대로 놔두는 이른바 데이터 토막내서 인코딩 맞춰 줄세우기 작업부터 진행했었습니다.

스톰보드는 위에서 말한 euc-kr 방식으로 구축된 데이터이므로 정성스럽게 잘라내어 utf-8 로 나누어 놓고 phpmyadmin 을 이용해 올리기 좋도록 대략 5메가 단위의 파일로 쪼개어 준비해 뒀습니다.

이렇게 준비해 놓은 데이터를 모두 업로드하고 나서 스톰보드를 구동해 보니 여전히 스킨과 함수 (특히나 정규식) 등이 euc-kr 인지라 정상적으로 보이지 않더군요.

해서 모든 파일을 BBEdit 을 이용해 euc-kr 로 열어서 한글 관련 내용이 정상적으로 보이도록 한 후에 utf-8 로 컨버팅해서 저장해 주었습니다.

하지만 여전히도 글자는 군데 군데 깨어져 보이더군요.
소스를 열어서 뒤적거려본 결과 소스 코드 내에 <meta http-equiv="Content-Type" content="text/html; charset=euc-kr"> 부분이 있더군요. 다시 파일을 모두 열어서 <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> 로 수정했더니 모두 정상적으로 보이기 시작하더군요.

어라~ 이렇게 쉽게 인코딩 변환을 할 수 있는 것인가라고 생각하고 있을 무렵 기존 갤러리의 한글 파일 이름으로 업로드한 이미지들이 정상적으로 출력되지 않는 문제점을 발견하게 되었습니다.

하.지.만... 이 부분을 어찌 정리해야 하는 것인지는 대략 5시간동안 소스를 뒤적거렸지만 아직 해법을 찾아내지 못했습니다.

str_replace 를 이용해 게시판 뒤에 붙는 수많은 옵션값들을 정리해서 img src=... 식으로 정리한다는 원리까지는 이해했지만 정작 동일한 코드에서 한글 이름이 들어갈 경우 정상적으로 작동하지 않더군요.

물론 좀 더 노력해서 연구해봐야 하겠지만 현재까지의 느낌으로는 정규식 관련 표현법에서 한글파일 이름이 들어가거나 특수문자가 들어가는 부분에 대해서는 특별히 고려하지 않고 넘어간 것이 아닌가 하는 생각을 하고 있습니다.

이전에 스톰보드에서 가장 편했던 것중의 하나인 [==1==] ... [==9==] 와 같은 방식으로 이미지를 삽입했던 부분도 오늘에서야 정규식을 이용해서 구현했다는 것을 알게 되었습니다. (사실 이전에 스톰보드를 사용할 때 까지만 해도 php 코드만 보면 머리가 아팠었는데 이제는 그저 막코딩이 더 편한 것처럼 느껴지는 상황이다보니 어렵지 않은 부분은 이해가 되는 부분도 있더군요.)

저 편했던 기능조차도 1~9 까지밖에 지원되지 않아서 많은 아쉬움이 있었는데 이전에 알았더라면 01~99 까지 정규식 글자 하나만 추가해줬어도 됐을걸~하는 생각도 뒤늦게 들더군요.

그러면서도 현재 운영하려고 하고 있는 킴스큐에서 한글 파일이름의 첨부에 대해서는 실험조차도 안하고 있었으니 오늘은 그 부분을 실험해 봐야겠습니다.

여.튼... 스톰보드를 utf-8 기반으로 변환하고 기존 데이터베이스의 복구까지도 성공적으로 마쳤다는 기념으로 기록을 해 둡니다.

ps. 아직 한글 파일 이름에 대한 부분은 해결되지 않았습니다. 스톰보드에서의 한글파일이름 첨부파일에 대한 이슈를 알고 계시는 분은 알려주시면 감사하겠습니다.

모든 페이지가 같은 코드 진행 방식으로 구성되어 있는 사이트 특성상 몇가지 색상값만 바꾸면 각 메뉴별로 색상을 달리할 수 있는데 - 이전부터 그랬었죠 - 나중에라도 색상을 교체하기 쉽도록 이것들을 변수화해서 사용할 수 없을까를 고민만 하다가 CSS 에서는 변수를 지원하지 않는다는 것을 알고 포기했었더랍니다.

그러던 중 몇 가지 수정해야 할 것이 있어 KimsQ 소스를 수정하던 중 CSS 안에서 변수를 사용하고 있는 것을 확인하게 되었습니다.

그렇다면 이전에 체크했던 시점 이후로 뭔가 개발된 것인가 하고 한참을 뒤적거리고 이런저런 테스트를 진행한 결과 그 방법을 알게 되었습니다.

아직은 스킨 개념으로 구조화시킨 것이 아니라 우선은 이전에 있던 CSS 파일을 변수를 포함한 CSS 형태로 수정하는 중인지라 복잡하기 이를데 없지만 일단은 수정해 놓고 다시 정리하면서 스킨화시켜야 겠습니다.

이 복잡한 일을 하는 이유는 나중에 모바일이나 인쇄등 다양한 환경에서도 사이트가 제대로 보일 수 있도록 만들 필요가 있는데 이때 별도의 CSS 를 치수 계산해 가며 새로 작성하기는 번거로우니 몇가지 특정 변수들을 이용해서 만들어 보겠다는 아주 아주 장기적인 계획때문입니다.

일단은 작업을 마저 진행해보고 중간중간에 브라우저 테스트도 거치면서 완성되고 감이 잡히면 새로운 포스팅으로 요령에 대해서 정리해 보도록 하겠습니다.

어제 새벽을 기해 HTML5 / CSS3 형식으로 리뉴얼을 단행했습니다.

아직은 게시판 환경설정을 완전하게 끝내지 못한 느낌이지만 향후 사용에 관해 큰 영향을 미치지 않는 부분정도만 남아있는 상태인지라 그냥 오픈하고 말았습니다.

테스트 폴더에서 보름정도 작업을 하면서 스크립트를 다듬곤 했었는데 실제 적용될 폴더가 아니다 보니 이래 저래 복잡한 느낌이 들어 차라리 뒤집고 에러를 잽싸게 수정하는 쪽으로 방향을 선회한 것이죠.

이래저래 오픈은 했다고 하지만 아직까지 내용이 없는 커뮤니티 메뉴인지라 언제쯤이나 자리를 잡게 될런지는 알 수 없지만 그래도 차근 차근 채워나간다고 생각해 보렵니다.

아직 CSS2 와 혼재되어 있는 부분도 있어 하나씩 체크하고는 있지만 이것마저도 빨리 끝날거라는 확신은 없습니다.

공부하고 테스트하고 적용하고 하는 과정이 반복되어야 할테니까요.

여하튼 화이팅입니다.

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

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

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

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

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

안프로그래머가 프로그래밍을 배워가며 홈페이지를 만들고 있는터라 생각만큼 진도가 빠르진 않지만 오늘 장족의 발전을 거듭했으므로 기념삼아 기록해 둡니다.

1. 현재 열린 파일이 위치한 최상위 폴더를 자동으로 추출해 해당 섹션에 맞는 CSS 파일과 Aside, Nav, Footer 등 외부 파일을 자동으로 임포트 : 이로써 Context 부분만 신경쓰면 디렉토리의 깊이 때문에 신경써야 했던 이런 저런 문제들이 해결되게 됐습니다.

2. Webkit 을 이용하는 브라우저에서 제대로 보이도록 설계되었지만 IE 계열에서도 대략적인 형태는 보이도록 구성했습니다. : 이 부분은 CSS 로만 해결했기에 이전처럼 과도한 Table 의 사용이라거나 자그마한 조각조각 이미지를 로딩하지 않아도 되므로 속도도 더욱 빨라질 것입니다. (물론 아직 CSS 를 정리하지 못했으므로 그다지 쾌적한 환경은 아닙니다.)

아직 KimsQ 엔진의 외부 추출에 대한 부분에서 해결책을 찾지 못한 부분이 있어 난해함이 있긴 하지만 그래도 제 스스로에게는 장족의 발전이라 생각됩니다.

꺄울~!!!

HTML5 를 핑계삼아 CSS3 를 공부하면서 사이트 리뉴얼을 위한 샘플 페이지를 만들고 있는데... (실은 드림위버가 영 손에 잡히지 않아 텍스트 편집기로 일일이 하드 코딩을 하고 있는 상태이고 와중에 추후 변경 사항에 대한 노가다를 줄이기 위해 include 함수를 활용한 블럭식 구조로 구성하고 있습니다.)

잘 코딩되가다가 외부 파일로 저장하고 include 함수만 사용하면 정체를 알 수 없는 공백이 생기더군요.

처음에는 그저 뭔가 이상한데? 라는 의문만 가지고 CSS 의 속성값을 바꿔 끼워맞췄지만 나눠지는 덩어리가 늘어날수록 이런식으로 해결할 수는 없는 문제라 생각되서 이리 저리 검색을 하고 돌아다녔습니다.

하지만 이런 결과가 흔하지 않은 것인지 아니면 아무도 신경쓰지 않는 것인지 좀처럼 원인을 알기 어렵더군요.

그러던 중에 utf-8/BOM 타입의 파일에는 파일 헤더에 공백을 생성할 수 있는 코드가 탑재되고, 이 부분이 include 함수를 적용해 불러올 때 뜻하지 않은 공백을 생성할 수 있다는 점을 알게 되었습니다.

이 문제를 해결하기 위해 바이너리 파일을 열어 앞의 3바이트를 일일이 수정하라는 프로그래머들도 하기 귀찮은 일을 지시하는 분들도 있더군요.

일단 황급히 ftp 를 열어 파일 속성을 체크해본 결과 새롭게 include 하려고 하던 녀석들의 정체가 utf-8/BOM 이라는 첩보를 입수하게 되었고 그저 깔끔한 utf-8 타입으로 수정해주었더니 깔끔하게 문제가 해결되더군요.

혹시라도 같은 경우를 경험하신 분이 계시다면 조금이라도 쉽게 문제를 해결하시기 바라는 마음에서 포스팅으로 기록해 둡니다.

현재 스킨 변경중...

스킨이 일반 스킨이 아니라 CSS 로 만들어진다 기능 함수들이 해독 불가능해서 은근히 시간 많이 걸리는군요.

그냥 심플하게 나오는 레이아웃이 있으면 그걸 토대로 헤더와 푸터만 붙여서 쓸텐데 레이아웃 특성상 그렇게 나오는 것도 없을테고...

천상 공부해가며 연구해야겠습니다.