이바닥이 원래 그래

EBADAC - OOPARTS : Out Of Place Articles.

Archive for October, 2006

웃자고 쓰는글 2.

October 31, 2006 at 4:55 pm · Filed under WebStandard, WorldWideWoops

“네, 이 기능에 치명적인 버그가 있다는 건 처음부터 알고 있습니다. 하지만 이 기능을 사용하는 사람은 전체의 1%도 안된다구요. 굳이 그 사람들을 위해 이 버그를 잡을 필요는 없다구요.”

“OOP가 더 효율적인 공정을 가져온다구요? 협력개발과 유지보수가 쉽다굽쇼? 무슨 소리에요. 저는 기존의 방식으로도 얼마든지 잘해왔어요. 지금 그까짓 외부업체와의 협력때문에 5년간 갈고 닦은 제 실력을 무시하는건가요? 상당히 기분나쁘군요.”

“우리 사이트가 대박을 쳤다구요? 회원 가입자 수가 1천명이 넘었다구요? 그래서 1001명이 사용가능하게 해달라구요? 그건 안되겠어요. 이 시스템은 애초에 1천명 정도만 쓰게 설계되었거든요. 처음부터 말씀하셨으면 1001명을 고려했겠지만 그런 말씀도 없으셨는데다 시간도 없었잖아요. 이제와서 1001명을 위한 사이트로 고치려면 얼마나 많은 비용이 들겠어요. 안타깝지만 이게 현실이죠.”

“네? 확장가능성은 설계할 때 기본 아니냐구요? 사장님이 직접 개발해보시죠? 그런 꿈같은 이야기는 연봉 더 많이 받는 사람한테나 요구하세요. 남들도 말만 그렇게 하는거지 실제로 확장기능 따위 개발안해요. 새 서비스 만들 때나 한번 고려해보죠.”

“저희 안전에어백은 현대자동차에 최적화되어있습니다. 앞으로는 해외로의 진출이 희망입니다. 저희 에어백을 사용하고 싶으신 고객은 타고 계신 자동차를 현대자동차로 바꾸세요. 안전을 위해서라면 그 정도 수고는 감수해야죠. 특히 차를 두대이상 소유하고 계신 분들은 필요에 따라 바꿔 타시면 되니까 별 문제없잖아요?”

“네? 다른 자동차에는 왜 쓸 수 없냐구요? 이보세요! 모르시면 가만히 계세요. 에어백을 장착하는 나사가 얼마나 특수한건데요. 공업표준 나사로 바꾸면 비용이 너무 많이 든단 말이에요. 설령 그렇다 하더라도 그걸 위해 얼마나 많은 기술자들이 달라붙어서 설계를 변경해야 하는지 아세요? 겨우 나사 하나 바꾸면 된다고 쉽게 말씀하지 마세요!”

“그치만 솔직히 말해서 현실을 너무 모르시는 것 같아요. 요즘 미국사람들도 영문법따위 잘 모른다구요. 저는 미국 친구들과 언제나 슬랭으로 의사소통을 해왔고, 그들은 제 말을 전부 이해했어요. 이제와서 문법이 올바르지 않다고 제 논문을 캔슬시킨다니 교수님은 문법편집증 환자임에 틀림없어요. 논문에 문법을 지키라는 게 어디 법으로 명시되어 있나요? 그건 어디까지나 권고일 뿐 강제력은 없는거에요.”

“그러니까, 10년 전에는 아무 소리 없더니, 이제와서 수입산 쇠고기가 광우병 위험이 있다고 호들갑떨면 나같은 수입업자는 어쩌란 말인가요? 적어도 나는 수입쇠고기의 위생과 안전을 위해 철저히 냉장유통과정을 관리하고 있다구요. 발생할 지 어쩔지도 확실히 모르면서 목소리만 큰 광우병 경고론자들이야말로 겨우 요사이 1,2년새에 나타나 마치 국민건강은 혼자 책임지는 것처럼 구는데 솔직히 아니꼽지요. 무슨 종교도 아니고 아주 잘난 척하는게 눈꼴시러우니 그냥 닥치고 있길 바래요. 댁들 때문에 광우병에 대해서는 생각도 하기 싫소이다.”

Comments

PHP를 사용하는 데는 엄청난 비용이 든다.

October 30, 2006 at 10:44 pm · Filed under WebDevelopment, WebStandard, WorldWideWoops

웃자고 쓰는 글.

PHP를 사용하는데는 엄청나게 많은 비용이 듭니다.

단순히 유지, 보수, 개편에서 뿐만이 아니라 아니라 새로 시작하는 사이트에서도 마찬가지입니다. 게다가 PHP를 사용한다고 해서 완전한 프리웨어/오픈소스로 인한 비용절감이 되는 것도 아닌지라, 예를 들어 Zend Guard라도 설치하려면 단지 몇십만원 하는 서버구축 비용보다도 더 많은 비용을 또 쏟아야 합니다. 가끔은 유료인 라이브러리 패키지를 구매해야 프로그램 개발이 용이할 때도 있구요.
특히, 구성원이 PHP에 대한 이해도가 떨어질 때에는 학습하는 시간과 비용이 장난이 아닙니다. 그뿐아니라 그 시간동안 진행되어야 할 프로젝트가 미뤄지는 것은 기업 입장으로써는 엄청나게 많은 기회 비용을 잃게 되는 것입니다. 그에 비해 PHP5의 OO적 특성을 제대로 이해하는 사람은 극소수이고요.
확실히 PHP는 무료이고 개발속도가 빠르고, 그런 것을 홍보해나가는 것은 좋지만, 이게 더 저렴한데도 왜 선택안하냐는 이야기는 안했으면 좋겠습니다. 절대 싸지 않으니까요.

Comments (1)

referez.com 유감

October 30, 2006 at 1:19 am · Filed under WebDevelopment

referez를 일단 걸어두긴 했는데, 나 자신은 뭐, 별로 쓸 일도 거의 없어서 들어가보지도 않지만.(게다가 나같은 마이너가 1000명만 쓸 수 있는 referez 아이디를 가지고 있는 것도 좀 껄끄럽긴 함.)

어쨌거나 조금 유감인 건, 다음과 같은 코드 때문.
[javascript]
function DoSubmitReferezForm(){
if(is.mac){
document.all.submit_referez_form.submit();
}else{
document.submit_referez_form.submit();
}
}
[/javascript]

is.mac이라는 멤버는 Mac 디텍팅을 위해 사용되는 듯 한데… Mac을 쓰지만 IE for Mac을 쓰지 않는 나로서는(아니, 과연 저거를 쓰는 사람이 있기나 한건가?) 저 코드가 계속 javascript 에러를 일으키고 있다. IE for Mac은 너무 옛날 버전이고, MS에서도 더 이상 공식적으로 지원을 포기한 브라우저인데 그 때문에 Mac에서의 다른 브라우저 모두가 오류를 만나게 된다니 이거 참…
IE for Mac 디텍팅은 다른 방법을 써주기를 간절히 바래본다.

Comments (6)

웹표준의 경제학 -3-

October 30, 2006 at 12:53 am · Filed under WebDevelopment, WebPlan, WebStandard

CN님의 포스트에 달린 덧글을 보다가…

첫번째 문제.
전산쟁이라면 Greedy 알고리즘에 관해 한번쯤은 들어보았을 것이다.
간단히 설명하자면, 서울에서 부산까지 버스를 갈아타고 가야할 때, “가장 빨리 출발하는 차를 잡아타고 가다보면 가장 빨리 도착한다.”는 전략이라고 할 수 있다. 그러니까, 일단 고속터미널에서 현재 가장 빨리 출발하는 것이 수원행 버스라면 그것을 타고 가서 수원터미널에서 역시 가장 빨리 출발하는 광주행버스를 타고, 광주에 도착해선 가장 빨리 출발하는 대구행 버스를 타고…. 뭐 이런 알고리즘이다.
때로는 Greedy알고리즘은 가장 효율적인 결과를 주기도 하지만, 대개의 경우 좀 더 최적화된 알고리즘이 있기 마련이다. 대신, 구현이 용이하고 이해하기가 쉽다는 장점이 있다.
따라서 실제로 Greedy알고리즘은 빠른 개발과 확인이 필요한 테스트단계에서나 쓰이는게 대세이다. 정확한 테스트 결과를 얻게 되면 정식 배포전에는 좀더 효율적인 알고리즘으로 대체된다.
만약 Greedy알고리즘을 좀 더 효율적인 알고리즘으로 교체하지 않는다면 어떻게 될까? 당연한 이야기겠지만, 실행시간이 오래걸리거나 리소스가 많이 사용된다거나 하는 불편이 있을 수 있겠다.
여기, 이전 버전까지 개발을 담당했던 개발자가 Greedy알고리즘으로 된 로직을 그대로 둔 채로 퇴직하는 바람에 당신이 프로젝트를 담당하게 되었다고 하자. 이럴 경우, 당신은 이 Greedy알고리즘을 투덜거리면서 새 알고리즘으로 바꿔야할 것이고 그러기 위해 시간과 노력 비용이 투자되어야 한다. 이 비용은 당신때문에 발생하는 비용일까?

두번째 문제.
예전 어떤 프로젝트에서 실제 경험했던 문제.
런칭한 새 서비스는 테스트도 완벽하게 통과했고, 처음 3개월간은 아무런 문제없이 잘 돌아갔었다. 그러나 그 후, 누적되는 데이터를 DB가 감당하지 못하여 서비스에 중대한 문제가 발생하게 되었다. 전적으로 사용량을 잘못 예측한 기획자와, 대용량 서비스를 염두에 두지 않고 DB를 설계한 개발자의 잘못이라 할 수 있겠다.
이 문제를 해결하기 위해서(해결할 생각이라면) 매우 많은 인력과 시간과 비용이 필요하고, 심지어 새로 서비스를 만드는 것보다도 많이 들지도 모른다. 과연 이렇게 비용을 들여서까지 이 문제를 해결해야만 하는가?

답은 각자 생각해보도록 하시고.

웹표준에 대한 비용문제에 빠지지 않고 등장하는 발언 중 하나는,
“예상외로 많은 비용”이라는 점이다. (일단, 코더 하나 뽑으면 될 거라 생각하는 수준이 대부분, 그러니 “예상”보다 비용이 많이 들 수 밖에.)

* “분석/설계 단계에서부터 웹표준을 고려하지 않았다면 나중에 웹표준을 적용하기 위한 수정은 비싼 비용을 치루어야만 한다.”
1) 그럴 수도…
2) 허나, 그 책임은 일차적으로 “분석/설계 단계에서 웹표준을 고려하지 않은” 기획자/아키텍트에게 있다.
3) 명색이 “웹” 기획자 또는 아키텍트라면 “웹”에 대해 고려해야만 했다.
4) 물론, 뭐, 형편상 못했을 수도 있겠다. 허나 기획이나 설계단계에서 놓쳤다 하더라도, 개발단계에서 Model과 View를 충분히 분리한 구조로 개발했다면, 차후 웹표준을 위해 수정이 필요하더라도 View단의 수정만으로 훌륭히 대처할 수 있었을 것이다.
5) 그러나 웹표준을 적용하기 위해 DB자체를 풀어헤쳐야 한다거나, 라이브러리를 전부 새로 만들어야 한다든가, 프레임워크를 통째로 갈아치워야 할 정도라면, 애초에 개발자체가 별로 아름답지 못하게 이루어졌다는 폭로일 뿐이다. 이건 웹표준을 떠나서 개발자로서 부끄러워해야 할 부분이다.
6) 또는, 어쩌면 개발자가 아직도 웹표준에 대한 기술이 부족한 것일 뿐일 수도 있다. 가끔 보면 “표준을 위한 표준”에 목이 매어 어렵게 돌아가는 케이스가 보이기도 하기 때문이다.
7) 하긴 컨베이어 벨트 시스템의 Waterfall개발방식을 아직도 고수하는 환경이라면 어느 누구한테 책임을 묻는다는 것 조차 언감생심이겠다. 8) “사실은 우리가 뭔가 꽤 잘못해왔고, 여전히 잘못하고 있긴 한데, 그걸 드러내서 인정하기는 좀 그렇고, 당분간 고치기에는 능력이 딸리고… 뭐, 우리가 일부러 그럴려는 건 아니고 우리에게 주어진 현실이 그랬고, 그 때는 다들 그걸로 좋았으니까…”

웹표준적용에 들어가는 비용은 웹표준 때문에 발생하는 것이 아니라, “이전에 잘못 만들어왔기에” 발생하는 비용이다.
결국, 웹표준 적용에 비용이 많이 든다면, 그건 지금까지 그만큼 무언가 놓치고 간과했고 실수하고 잘못해왔다는 고백일뿐.

이런 글을 쓰면 씁쓸해 하는 사람들이 많을 지도.(난 불친절한 금자씨라서. ^^;;)
헌데, 생각해보면,
그 비용은 회사로서는 당연히 지불해야하는 비용이고, 대개의 경우 개개 개발자들의 책임으로 지불해야하는 비용은 아니다. (그래서 웹표준 컨설팅때에는 언제나 경영자의 의지를 가장 중요한 선행조건으로 강조하고 있다.)
게다가 그동안 이 부분은 국내에서는 너나 할 것 없이 취약한 부분이었기 때문에, 지난 개발에 대해 누구에게 직접적으로 잘못을 묻기도 어렵다. 즉, 조건없는 면죄부가 주어진거나 다름없는 셈.
그러므로 이 문제에 관해 일개 말단 직원의 가장 속편한 반응은 “지나간 일은 지나간 일이고, 앞으로 잘하면 되지”인 셈이다. 책임이 있다면 경영진이나 최소한 프로젝트의 책임위치인 매니저나 리더가 져야 할 뿐. 헌데도 왜들 이리도 애써 변명(?)하고 저항(?)하는지 모를 일이다. (이게 모두 노무현 탓 아니, 불친절한 금자씨 때문이라면 할 말 없고.)

관련글

웹표준의 경제학 -1-

웹표준의 경제학 -2-
불친절한 금자씨

Comments (2)

트랙백의 가치

October 28, 2006 at 8:33 pm · Filed under WebDevelopment, WebPlan

트랙백의 방향
트랙백은 가치가 있어야 한다.

“A에서 B로 트랙백을 보내다”의 본시 의미는,
1) A는 B를 링크하고 있다는 신고 (Send Ping to Auto-Link)
2) B에게 A가 존재함을 알림 (Notify Ping)

“B가 A로부터 트랙백을 받는다”의 본시 의미는,
1) A가 B를 링크했을 거라는 가정
2) A가 B에게 흥미있을 거라는 가정

트랙백은 “링크”도, “원격댓글”도 아닌, 그저 “알림”일 뿐.
링크나 원격댓글은, 트랙백의 활용법 중 아주 극히 일부분. 비록 그게 전부인 것처럼 보일지라도.

Comments

트랙백 수신모듈 제작시 주의점

October 25, 2006 at 2:18 pm · Filed under WebDevelopment

필요에 의해 정리해보는 Trackback 수신모듈 제작시 고려해야할 점들.

1) 반드시 트랙백 주소가 별도로 존재해야하는 것은 아니다.
일종의 미신/신화, 내지는 아무 생각없이 트랙백을 붙인 서비스들이 대표적인데,
굳이 문서의 URL과 별도로 트랙백의 URL이 존재할 이유는 없다.
이렇게 된 이유는 Trackback규격을 만든 SixApart사의 MovableType만의 특수성때문.

MovableType은 처음엔 Perl로 만들어진 CMS-블로깅 도구로써, 그 특징 중 한가지로 스태틱빌드를 통한 정적인 페이지 생산을 들 수 있다. 즉, 모든 아카이브 페이지를 HTML 파일로 만들어 서버에 둔다는 뜻.
서버사이드 스크립트를 쓰지 않고 HTML파일이 생성되기 때문에, 트랙백이나 커멘트를 위해서는 별도의 서버사이드 스크립트 프로그램을 필요로 했다. 그래서 문서 URL과 트랙백 프로그램 URL이 다를 수 밖에 없었다.

초기 Blogger.com같은 경우에는 자체적으로 트랙백 등이 지원되지 않아, 많은 유저들이 써드파티 플러그인을 사용했었다. 이 경우도 문서 URL과 트랙백 URL이 다를 수 밖에.

그러나 이런 경우들을 제외한다면, 서버사이드 스크립트(PHP, ASP, JSP등)를 사용하는 블로깅 도구나 트랙백 서비스들이 굳이 별도의 트랙백용 URL을 유지할 필요는 없다. 바로 이 트랙백 URL과 문서 URL이 다른 까닭에 트랙백을 보내는 것이 귀찮고 번거로운 일이 되지 않았나… 아마도 MT등을 관습적으로 카피하다보니 이런 현상이 발생한 듯 하다.

2) 트랙백 Method 형식
트랙백은 보통 HTTP Request POST 형태로 수신된다. 아주아주 오래전 규격에서는 GET을 이용하기도 했었으나 현재는 거의 대부분이 POST를 이용하고 있다.
형식은 다음과 같다.


[HTTP header]
POST http://트랙백수신주소
Content-Type: application/x-www-form-urlencoded; charset=utf-8

charset을 반드시 명시해야 한다.

그리고, 넘어오는 필드들은 다음의 것들이다.

  • url : 필수, 이것이 없다면 수신서버에서는 에러메시지를 리턴해야 한다.
  • title : 옵션
  • excerpt : 옵션
  • blog_name : 옵션

이상은 모두 text를 데이터값으로 한다.

3) 인코딩
이상의 POST field들은 모두 charset에 정의된 인코딩을 따라야만 한다. (속편하게 아예 UTF-8로 하자.)
가끔 보면 국내 블로그 도구/서비스에서 EUC-KR을 써서 보내는 경우가 있다.
친절하게 하자면야, 들어온 메시지가 인코딩이 맞지 않는다면 강제컨버팅(iconv같은…)을 통해 인코딩을 UTF-8로 변환시켜주는 것이 좋을지도.

4) 길이
예전에 GET 메쏘드를 이용할 때에는 그 특성상 각 필드의 길이값에 제한이 있었으나, POST를 사용하는 지금은 그렇지 않다.
절대로 받아올 트랙백 메시지의 길이를 임의로 추측하거나 가정하지 말 것. (특히 excerpt의 255자 제한따위.)

5) 옵션
title, excerpt, blog_name 모두 생략가능하다. 즉, url을 제외한 어떠한 것도 안넘어올 수 있다. 따라서 유효한 트랙백 메시지인지 판별할 때에는 url만 가지고 체크할 것. 또한 다른 필드들 값이 반드시 넘어올 것이라고 가정하지 말 것.

6) url
url로 넘어온 값이 반드시 발신처와 일치할 것이라 가정하지 말 것. 트랙백 메시지자체는 단순한 ping신호일 뿐, url은 전혀 다른 제 3의 문서를 가리킬 수도 있다. (물론, 이를 이용해 스팸 트랙백을 걸러내기도 하지만 이는 트랙백의 가능성을 제한하는 일이다. 트랙백 발송 URL의 도메인과 url값에 들어있는 도메인은 서로 달라도 된다.)

7) excerpt
excerpt가 옵션이라서 없을 수도 있다. 또한 블로그 도구마다 excerpt 생성방식이 다양하다. 따라서 만약 트랙백 url의 문서내용이 필요하다면 excerpt를 이용하는 것은 불가. 필요하다면 url을 소켓으로 열고 스크린 스크래핑 기법을 통해 가져오기를 추천한다.
8) 리턴 메시지
트랙백 메시지를 수신한 후, 수신모듈은 반드시 메시지를 리턴해주어야 한다.(그래야 발신처에서 제대로 트랙백이 발송되었는지 확인할 수 있음)

올바르게 수신되었을 때
[xml]
< ?xml version="1.0" encoding="utf-8"?>

0

[/xml]

문제가 생겼을 때
[xml]
< ?xml version="1.0" encoding="utf-8"?>

1
The error message

[/xml]

9) Auto Discovery
트랙백 수신 문서에는 다음과 같은 트랙백 RDF를 추가해준다.
[html]