삽질 연대기

프로그래머나 IT 업계에 종사하는 사람에게 밤샘은 아주 가까운 친구다. 1년 짜리 프로젝트를 한다고 하면 마지막 2개월에 거의 모든 일을 다한다. 프로젝트의 기간이 얼마가 되던 거의 비슷하다. 막판 피치에서 거의 90%가 완성된다. 프로젝트를 이렇게 수행하게 되는 이유는 먼저 갑이 일을 주면서 일에 대한 윤곽이 없이 개념만으로 일을 주기 때문이다. 따라서 납기를 코앞에 둔 상태에서 프로젝트의 근간을 흔드는 요청도 참 많다.

두번째는 국내의 열악한 개발환경 탓에 제대로된 소프트웨어 엔지니어가 없기 때문이다. 제대로된 소프트웨어 엔지니어가 없다 보니 소프트웨어를 전체적으로 보고 설계한 뒤 일을 시작하는 경우가 거의 없다. 일단 시작한 뒤 만드는 때가 많다. 이렇다 보니 프로젝트가 조금만 바뀌어도 바꿔야 하는 부분이 정말 많이 생긴다. 또 디버깅이 어렵다.

마지막으로 개발자 스스로도 이런 개발환경을 알고 있기 때문에 프로젝트가 막바지에 달하기 전까지는 대부분 시간 때우기로 일관한다. 따라서 철야는 애인보다 친한 친구다. 지금이야 나이를 먹어 하루밤을 세기도 힘들지만 모게임 사이트(웹진분야 국내 1위)를 개발할 때는 두 주 동안 단 한숨도 자지 않고 밤을 샌적도 있다.

삽질에도 종류가 많다. 꼭 해야하는 삽질과 하지 말아야 하는 삽질. 보람이 있는 삽질과 보람이 없는 삽질. 꼭 해야할 삽질을 보람을 느끼며 하는 것이 최선이겠지만 하지말아야할 삽질을 보람도 없이 하는 때도 많다. [그림출처]

그런데 프로그램을 짜지않는 요즘도 곧잘 삽질을한다. 컴퓨터 때문에 삽질을 할 때도 있고 오늘처럼 전혀 엉뚱한 문제로 삽질을 할 때도 있다. 그래서 이 계통의 종사자들은 항상 "삽질만이 길이요, 진리요, 생명*이라고 한다.

① 블로그 접속 문제
오늘 Yahoo에 관련된 글을 올렸다. 글을 모두 작성하고 저장한 뒤 다음 블로거뉴스 플러그인을 이용해서 블로거뉴스에 글을 송고하려는데 페이지가 뜨지 않았다. 이때부터 무슨 일인지 계속 접속이 되지 않았다.

예전에 무차별적으로 날라온 참조 URL 스팸 때문에 참조 URL에 성인 단어(예: Fuck, Sex)가 포함되어 있으면 차단하도록 설정해서 사용하고 있다. 이 설정 때문에 주소에 Fuck와 같은 단어가 포함되어 있으면 블로그의 페이지가 정상적으로 뜨지 않았다.

혹시 이 문제인가 싶어서 .htaccess에서 yahoo를 찾아 보니 search.kids.yahoo.com이 포함되어 있었다. yahoo를 필터링하는 것과 완전한 주소를 필터링하는 것은 차이가 있기 때문에 이 문제는 아닌 듯 싶었지만 혹시 몰라서 일단 지우고 블로그를 테스트했다. 역시 이 문제는 아니었다.

마지막으로 올린 글이 야후에 대한 글이라 이 글을 읽으면서 문제가 발생한 것이 아닌가 싶어서 텍스트큐브의 관리도구로 로그인했다. 관리도구는 느리기는 하지만 시간이 지나면 표시됐다. 그러나 글을 지우려고 하면 꼭 오류 메시지를 내 보냈다. 결국 블로그에 설치한 phpMyAdmin으로 접속했다. 텍스트큐브 관리도구와 비슷하게 느리기는 하지만 페이지는 표시됐다.

② Cafe24에 연락
할 수 있는 모든 방법을 동원해 봤지만 그 이유를 알 수 없었다. 혹시 오늘 올린 글이 블로거뉴스에 올라서 사용자가 폭주한 것이 아닌가 싶었지만 로그 기록에는 다음 블로거뉴스를 거의 찾기 힘들었다. 또 지난번에 퍼간글이 네이버 메인에 올라 전송량을 잡아먹은 적도 있기 때문에 네이버를 확인해 봤지만 펌로거의 문제는 아니었다. 결국 Cafe24의 고객센터에 연락했다.

확인한 뒤 알려 주겠다는 답변을 듣고 잠시 뒤 연락이 왔다. 문제는 /entry/Yahoo라는 폴더가 없어서 발생한 현상이라는 것이었다. /entry/Yahoo라는 폴더가 없어서 발생한 문제라면 홈페이지가 이렇게 늦게 뜰리 없고 결정적으로 Yahoo는 실제 폴더가 아니라 가상 폴더이며, .htaccess와 rewrite.php라는 프로그램이 이런 가상화를 처리한다고 알려 주었다.

결국 기술자에게 연락해서 다시 연락을 주겠다는 연락을 받았다. 원인을 조사했지만 이렇다할 원인을 찾지 못한 Cafe24에서는 "오늘 오전에 백업한 데이타로 복구하겠다"는 연락을 해왔다. 파일을 바꾼 것은 아무것도 없는 상황이지만 혹시나 싶어서 오전에 백업한 데이타로 복구했다. 그러나 역시 문제는 해결되지 않았다. 결국 서버에는 아무런 이상이 없기 때문에 알아서 해결하라는 답변을 들었다.

③ 원인 분석
일차적으로 DB의 문제로 보고 야후에 관련된 글을 phpMyAdmin으로 삭제했다. 그리고 DB가 손상됐을 가능성이 있어서 DB를 복구하고, DB를 최적화한 뒤 DB를 검사했다. 그러나 증상은 개선되지 않았다. 또 직접 설치한 'phpMyAdmin'으로 접속하면 속도가 상당히 느리지만 Cafe24에서 제공하는 웹 DB 관리 도구로 접속하면 상당히 빠르게 페이지가 표시되는 것을 보고 DB의 문제가 아니라 다른 문제로 파악했다.

Cafe24의 웹 DB 관리도구는 빠르게 뜬다는 점, 텍스트큐브의 관리도구와 내가 설치한 phpMyAdmin은 느리지만 뜬다는 점 때문에 일단 플러그인의 문제로 판단했다. 그래서 이런 문제를 발생할 소지가 있는 플러그인을 모두 사용 중지 시켰다. 그러나 역시 문제는 해결되지 않았다. 일단 작업하는 도중 데이타가 날라갈 수 있기 때문에 DB를 덤프해서 백업하고 파일도 로컬 컴퓨터에 백업했다.

④ .htaccess 문제
문제의 원인을 분석하던 중 .htaccess가 없으면 블로그 페이지를 제외한 텍스트큐브 관리도구와 phpMyAdmin이 아주 빠르게 뜬다는 사실을 발견했다. .htaccess를 제거한 뒤 빠르게 뜬다는 것은 일단 .htaccess에 문제가 있는 것으로 판단했다. 물론 그 사이 .htaccess를 수정하지 않았기 때문에 근본적인 문제는 .htaccess가 아니지만 문제의 원인을 파학하기 위해 .htaccess의 의심가는 항목을 수정했다.

결국 찾아낸 항목은 블로그에 악풀을 남긴 사람을 차단하기 위해 deny from으로 IP 대역을 차단한 부분이었다. 이 항목을 제거하자 텍스트큐브의 관리도구와 phpMyAdmin이 빠르게 뜨는 것이었다. 그러나 이 당시에는 문제가 되는 부분만 찾았을 뿐 문제의 원인은 찾지 못했다. 다만 블로그 관리도구가 빨리 뜨기 때문에 작업하기는 훨씬 편했다.

⑤ fsockopen 문제
그러나 역시 블로그의 페이지는 뜨지 않았다. 일단 관리도구는 빠르게 뜨기 때문에 관리도구에서 글과 플러그인을 확인했다. 그리고 글의 수정은 잘되는지 확인하려고 하던 중 블로거뉴스 플러그인이 뜨지 않는 것을 보고 블로거뉴스 플러그인을 사용 중지했다. 그러나 블로그 페이지는 여전히 뜨지 않않았다.

블로거뉴스 플러그인과 비슷한 형태의 플러그인을 찾기 위해 일단 스킨을 바꿔서 스킨이 정상적으로 뜨는지 확인해 봤다. 그런데 스킨을 바꾸자 역시 블로그가 정상적으로 표시됐다. 이제 남은 것은 문제가 되는 플러그인을 찾으면 되기 때문에 스킨에서 치환자를 지워 나가는 방법으로 문제를 발생하는 치환자를 찾았다.

의외로 전송량을 표시해주는 전송량 표시 플러그인 때문에 블로그가 표시되지 않은 것이었다. 해당 플러그인의 치환자인 [ ##_traffic_## ]를 제거하자 그토록 열망하던 블로그 페이지가 열렸다. (역시 삽질만이 길이요, 진리다). 이때 '두 플러그인 모두 fsockopen 함수를 사용한다'는 사실을 깨달았다. 그리고 잠시 뒤 Cafe24측에서 연락이 왔다. 이제는 블로그가 정상적으로 뜬다는 것이었다.

블로그가 정상적으로 뜬 이유와 최근에 서버 설정이 바뀐 것이 있는지 물었다. 그 이유는 접속이 잘되던 블로그가 갑자기 접속이 되지 않았고 내가 변경한 부분은 없었기 때문이었다. 서버 설정 중 어떤 부분이 바뀌었는지 알아다 주기로 하고 전화를 끊었다.

⑥ 네임서버 문제
fsockopen의 문제인지 아니면 다른 문제인지 확인하기 위해 fsockopen으로 QAOS.com을 열어 봤다. 역시 페이지를 열지 못했다. 다시 fsockopen으로 qaos.com의 IP(61.74.62.27)를 열어봤다. 그런데 IP를 사용하면 정상적으로 열렸다. IP를 사용하면 정상으로 열리기 때문에 다음 문제 중 한가지 일것으로 최종적으로 결정을 내렸다.

• Cafe24의 DNS 서버에 이상
• 호스팅하고 있는 서버의 DNS 설정 오류

그러나 Cafe24에서 똑 같이 호스팅하고 있는 QAOS.com에는 아무 문제가 없다는 점, 그리고 QAOS.com에서 사용하는 프로그램에도 fsockopen 함수를 사용한다는 점을 생각하면 호스팅하고 있는 서버의 네임서버 설정에 문제가 있을 것으로 판단했다.

다만 아직도 Cafe24측에서 연락이 없어서 문제의 원인을 Cafe24에 알려 주었다. 그리고 받은 Cafe24의 최종 답변은 UDP에 대한 규칙을 적용하다 규칙 적용이 잘못되서 KT서버로의 DNS 조회가 막혔기 때문에 발생한 일이라고 한다. 총 6대의 서버에 규칙을 적용한 뒤 이상이 발생하자 원인을 찾고 있었다고 한다. 그리고 내네임서버 문제를 지적하자 오늘 적용한 규칙에 UDP를 필터링한 정책을 적용한 것을 떠 올리고 "이 문제를 해결했다"고 한다.

오후 3시 10분 부터 오후 6시 30분까지 무려 3시간 20분 동안 문제의 원인을 찾기 위해 참 많은 삽질을 했다. 단독으로 호스팅하는 서버이고 따라서 원격으로 로그인한 뒤 관리도구를 사용할 수 있는 상황이라면 이런 삽질을 하지 않아도 될 부분이 었다. 그러나 Cafe24는 다른 호스팅 업체처럼 보안을 위해 telnet 로그인은 허용해도 시스템 관리도구는 사용할 수없도록 설정되어 있다.

심지어 telnet으로 계정에 로그인한 뒤 다시 telnet으로 다른 사이트에 접속하는 것까지 막혀있기 때문에 HTTP의 RAW 연결도 힘든 상황이라 삽질한 시간이 더 길어졌다. 역시 IT 개발자에게

삽질은 길이요, 진리요, 생명이다.

다만 서버의 정책 변경으로 발생한 문제를 사용자의 문제로 판단하고 알아서 하라고 한 상담 태도는 문제를 지적하지 않을 수 없었다. 그 이유는 Cafe24에서 확인했지만 파일이 수정된 부분은 없었다. 나도 파일의 수정은 없었고 글만 하나 올렸다는 것을 Cafe24에 전달한 상황이었다. 이런 상황이라면 당연히 그날 서버 설정에서 바꾼 부분이 무엇인지 먼저 생각했어야 한다. 그러나 서버 정책의 변경은 생각하지 않고 잘못을 고객에게 넘긴 것은 역시 문제가 많다고 본다.

남은 이야기

현재 나는 Cafe24에서 QAOS.com과 Offree.net을 호스팅 받고 있다. 이전 글들을 보면 알 수 있지만 Cafe24에서 호스팅을 받고 이런 저런 문제가 있었지만 Cafe24에서 다른 업체로 바꾸는 것은 아직 생각하지 않고 있다. 그 이유는 다음과 같다.

가격 및 기술력

가격 및 기술력으로 보면 국내 호스팅 업체 중 Cafe24를 능가하는 곳은 많지 않다. 가격이 더 싼 업체도 많지만 기술력이 뒷 받침하지 못하고 기술력이 더 좋을지 모르지만 가격은 턱없이 비싼 곳도 많다.

특별관리

홈페이지와 블로그를 특별히 관리해주고 있다. 다음 블로거뉴스에 몇번 노출되면서 하루 전송량을 다 사용하고 호스팅 업체의 서버가 다운되는 사태까지 발생했다. 이 일이 발생한 뒤로는 "홈페이지와 블로그를 호스팅하고 있는 서버는 특별히 관리하고 있다"고 한다. 직원이 근무하는 중에는 트래픽 초과가 날 것 같으면 자동으로 트래픽을 초기화 해주기도 한다. 또 하루 전송량 3G짜리를 사용하고 있지만 실제 전송량은 14G로 설정되어 있는데 그 이유도 블로그 호스팅용 서버를 특별관리하고 있기 때문이라고 한다.

친분

고객관리팀 팀장님과의 친분도 한 이유이다. 예전에 Cafe24 호스팅에 문제가 발생해서 몇시간 동안 홈페이지가 죽은 적이 있다. 이때 고객관리팀 팀장님의 적극적인 대처로 이 문제를 해결할 수 있었다. 이 뒤로는 고객센터를 통해 처리되지 않는 문제는 고객관리팀 팀장님을 통해 처리하는데 항상 적극적으로 대처해 주기 때문에 다른 곳으로 이사갈 명분을 찾지 못하고 있다.

그 나물에 그 밥

다른 호스팅 업체를 사용하고 있는 사람들에 따르면 Cafe24보다 더한 곳도 많다고 한다. 따라서 섣부르게 옮기다 낭패를 볼 수 있기 때문에 일단 몇 달간 시험을 한 뒤 옮긴다. 한 예가 파란 호스팅이다. 호스팅 서버를 관리하면서 오후 6시만 되면 모든 직원이 퇴근하는 이런 호스팅 업체에 어떻게 호스팅을 맞길 수 있을까?