Life is Simple, Thinking is High

ㆍJavaScript: The Definitive Guide (5/E) ㆍ원서 | 2006-08-01 ㆍO'REILLY ㆍDavid Flanagan

자바스크립트로는 HTML Form Validation이나 체크하고 가끔 이미지 rollOver시키는게 전부다라고 생각하는 오해가 있습니다. 자바스크립트를 작성하는 대부분의 사람들이 개발자가 아니거나 초보개발자였기에 좋은 예제가 상대적으로 많지 않으며 그리고 이것은 다시 자바스크립트는 초보자들을 위한 언어라는 인상을 주었습니다. 사실 스크립트라는 접미사는 보통의 C나 Java보다 약한 언어라는 인상을 줍니다. 하지만 이건 관점의 문제일뿐 Javascript는 표현력과 역동성을 위해 성능을 희생한 것입니다. 자바스크립트는 개념적으로 매우 심플한건 맞지만 단순 반복작업에나 사용될만한 그런 단순한 언어는 아닙니다. 오히려 그 심플함으로 인해 매우 우아하며 실용적입니다. 몇년 전부터 Ajax 열풍으로 인해 javascript가 조금 재조명을 받긴 했지만 여전히 자바스크립트는 초보개발자나 하는 노가다 작업으로 취급되고 있습니다. 그리고 여전히 대부분의 개발자는 자바스크립트에 대해 잘 알지 못합니다. 그에 대해서는 국내 자바스크립트 서적도 일정부분 책임이 있다고 생각합니다. 이제까지 Ajax를 제외하고도 몇권의 국내 자바스크립트 책을 읽어봤지만 그중에 사실 독자로서 추천하고 싶은 책은 한권도 없습니다. 그 책의 대부분은 기본적으로 개념이없고-_- (자바스크립트는 프로시저형 절차지향 언어가 아닙니다.) 틀린 내용이 많으며 잘못된 방법으로 구현된 예제를 부추깁니다. (해외 관련한 책중에도 상당수는 아주 바보같은 책들이 있습니다만 좋은 책이 몇권 더 있다는게 다릅니다.) 물론 자바 스크립트도 다른 언어들처럼 의문이 드는 설계나 버그가 없는 것은 아니지만 (게다가 더 많은 버그를 가지고 있는 브라우저에 내장되어 있었습니다.) 그렇다고 하더라도 지금 자바스크립트의 가치는 지나치게 평가절하되어 있습니다. 사설이 길었지만 다른 관련 서적에 불평이 많은 만큼이나 이 책은 자바스크립트와 관련하여 제가 알고 있는 최고의 책입니다. 기본적인 연산자와 함수부터 자바스크립트의 객체지향적 특징까지 아주 잘 설명해주고 있습니다. 그리고 아주 잘 정리되어 있기 때문에 옆에 두고 레퍼런스로 쓰기에도 손색이 없습니다. 3th가 국내번역이 되었지만 너무 오래전 책이라 지금의 버전과 차이가 있습니다. (자바스크립트는 아마도 가장 빨리 버전업이 되는 언어가 아닐까 합니다.) 이 책은 추가적으로 Javascript에서 사용되는 좋은 사용예제와 이디엄을 보여주고 설명해 주기 때문에 Ajax관련하여 이를테면 dojo나 prototype등의 소스를 보며 대체 이게 무슨말이야-_- 라고 당황했다면 아주 도움이 될거라 생각합니다. ps. 이 서평을 처음 썼을때는 없었는데 현재 번역본이 나와 있더군요.

우리나라의 온라인 시스템에서 스팸 처리를 하는 방식은 아주 원시적이다 -ㅅ-
물론 티스토리 또한 예외가 아니다.

특정 단어나, 특정 아이피, 특정 아이디를 제외하는 방식이다.

1. 특정 단어를 제외하는 방식은 사실 아주 바보같은 방법이다. 예전에 여기저거 포탈등에 댓글에 '최진실'이라는 글자가 들어가면 금지어가 사용되었습니라고 댓글 등록이 안되던 시절이 있었다. (아마도 무능한 어떤 인간이 금지어로 등록하라고 지시를 내려서였겠지만 ) 시험삼아 진실이 누나라고 해보니 등록이 되었다. 단어 기반으로 막는걸 피하는건 아주 쉽다.

2, 그렇다고 관련 단어까지 모두 등록하면 되지 않을까 라고 하는것도 바보같은 생각이다. 피할 수 있는 관련단어는 금지어 등록으로 할 수 있는 것보다 훨씬 많고 사실 등록을 많이 하면 많이 할수록 프로그램으로 검사하는데 시간이 많이 소요된다. 즉 일종의 낭비가 발생한다.

3. 시스템이 빵빵하다로 우겨볼수 있지만 다른 문제가 더 있다. 관련 단어가 많이 등록 될수록 정상적인 글 쓰기 또한 방해된다는 것이다. '진실'이라는 단어는 아주 일반적인 단어이기 때문에 금칙어로 등록이 되면 글쓰기가 불편해진다.

4. 게다가 맘만 먹으면 굳이 일반적인 단어를 쓰지 않아도 된다. 진.실. 이라고 쓰면 그만이고 씨X~ 이라고만 써도 금칙어 따위는 얼마든지 피할수 있다.

5. 아이피나 아이디를 막는 방법도 마찬가지이다. 아이피를 변경하거나 새로운 아이디를 얻는 방법은 너무나 쉽다.
    스팸을 써서 얻는 이득 > 아이피를 변경하거나 새로운 아이디를 얻기 위한 수고 + 스팸글을 쓰는 수고
    이 등식이 성립하는 한 아이피나 아이디로 막는 방법은 효과가 없다.

6. 스팸이라는건 아주 지역적이다. 시스템에 따라 어떤 글이 스팸인지에 대한 판단여부가 다르다는 뜻이다. 심하게는 글에 따라 다를수도 있다. 그에 따라 시스템마다 다른 스팸처리를 만든다면 지나치게 많은 제작 비용과 관리비용이 든다.

위와 같은 단점때문에 관리자가 직접 확인후에 삭제 하는 방법이 있겠지만 이는 관리비용이 너무 많이 든다는 약점이 있다. 24시간 수만개의 댓글등을 봐야하는 관리자의 비용은 유형이지만 스팸을 막음으로써 생기는 이득은 무형이므로 관리자 시스템이 제대로 운영되지 않는다. 



이제 코드를 작성 하기 전에 생각해 봐야 할것은
"스팸이란 무엇인가"에 대한 본질적 질문이다.

개인적으로 컴퓨터 코드를 짜는 방법은 간단한다. 쪼갤수 없을때까지 쪼갠다음 공통점을 찾아서 다시 합치면 된다. -ㅅ-
이를테면 세상을 분자 단위까지 쪼갠다. 일단 쪼갠후 관.점.에 따라 공통점을 가진 분자끼리 묶어보면 세상을 코딩을 할 수 있게 된다.

갑자기 웬 헛소리냐는 말을 하기전에
스팸에 대한 판단은 종합적이다. 즉 단순히 어떤 단어나 아이피의 문제가 아니고 단어와 아이피를 포함하고 문맥과 기타 여러 제반사항등을 모두 고려 대상이 되며 이러한 두뇌는 종합적인 판단으로 이 글은 스팸이군 이라는 결정을 내린다는 뜻이다.

두번째로 각각의 개별적인 판단은 단순히 or나 and 연산이 아니며 꽤 복잡한 연산을 하게된다. 그리고 여기서 연산은 다시 지역적이며 주관적 판단이 들어가게 된다. 단순히 몇몇 단어가 들어갔다고 해서 혹은 특정 아이피에서 쓰여졌다고 해서 스팸이 아니며 그렇다고 스팸이 아니라는 것도 아니다.

사실 위의 2단계는 어느 프로그래밍이나 마찬가지이다. 종합적인 측면을 고려하기 위해 쪼개는 과정은 객관적인 측면이 강하지만 그걸 다시 합치는 측면은 주관적이다. 예컨데 모든 물질을 분자단위로 쪼개는 것은 과학이지만 그걸 합쳤을때 책상으로 인식하는 것은 철학이다.


위의 생각이 너무 추상적이라면 좀 더 실질적인 얘기를 해보면 
  A 스팸을 써서 얻는 이득 < 스팸글을 쓰는 수고 * n개   이 수식만 유지해주면 된다. 
  B 그리고 이 수식을 유지하는데 늘어나는 정상적인 글쓰기의 수고를 최소한으로 유지하여야 한다.

기존 단순 매칭 방식의 스팸 처리방식은 그 방어막을 벗어나기가 너무나 쉽기 때문에 A를 위반한다. 일단 그 방법을 인식하면 스팸을 써서 얻는 이득 > 스팸글(0에 수렴한다) 올리는 수고 * n 개(n은 무한에 수렴) 도 참일 확률이 높다.

그래서 글을 쓸때마다 특정 그림에 뜬 문자를 입력하게 만드는 방식도 있다. 글쓰기마다 글자들은 랜덤으로 나타나기 때문에 스팸글을 올리는 수고는 0에 수렴하지 않으며 따라서 일면적으로는 아주 효율적이다. 그러나 이 방법은 따른 정상적인 글쓰기의 수고도 또한 늘린다. 간단한 댓글을 달기위해 잘 보이지 않는 숫자들 여러개를 입력하는건 아주 짜중이다-ㅅ-

사실 이 방법은 그림에 보이는 글자가 여러개일 필요는 없다. 3개정도면 해도 스팸을 올리기 귀찮을 정도로 충분한 갯수이므로 7개 이상을 유지하는 멍청한 짓은 제발 좀 하지말자-ㅅ- 스팸을 막고자 하는거지 정상적인 글쓰기까지 방해하자는 것은 아니니까 말이다.

작년에 모기업 서류통과-필기시험-실기시험을 통과하고
마지막으로 인성면접때 면접관이 나에게 한 질문이다.

물론 질문은 나한테 한거지만
기본적으로 프로그래머들은 "고집불통에 독선적이고 까칠한 성격이라서 타협할 줄 모르고 자기 주장만을 하는 인.종."이라는 인식이 있다. (.. 라는 사실을 프로그래머들도 알고 있다. )

그냥 대충 상황에 따라 다르다 라고 말했지만(그리고 그 인성 면접에서 떨어졌다-ㅅ-)
속으로는 다른 생각을 하고 있었다.

개인적으로는 - 비록 다른 인종들은 그닥 동의하지 않지만 -
프로그래머들 이야말로 타협의 프로라고 생각한다.
프로그래머는 항상 타협을 한다.

요구사항때는 수많은 이해당사자와 타협을 하고
설계시 여러 프레임워크와 여러 아키텍쳐, 방법론들 사이에서 타협하고
코드를 짤때 시간의 효율과 공간의 효율 사이에서 타협을 한다.
그리고 현재의 코드와 미래 발생할지 모르는 유지보수 사항과도 타협을 해야 한다.

사실 프로그래머의 일상은 타협의 일상에 다름아니다.

그러함에도 프로그래머들이 타협을 할 줄 모르는 독단적인 캐릭으로 취급받는 이유는
프로그래머는 항상 타협을 할때 타협의 이유를 무의식으로 생각하기 때문이다.


"당신은 6개월의 일정을 예상했지만 나는 2개월을 예상합니다. 이제 4개월로 타협합시다"
라는걸 타협이라고 부른다면 계속 읽지 않아도 된다.


사람들이 자주 망각하는 것중 하나는 프로그래머라는 직업은 매우 지적인 활동이며 관리자들이 생각하는 것보다는 훨씬 더 프로그래머는 영리한 사람들이라는 것이다. 물론 프로젝트가 4개월 이내에 완성되지 않으면 안되는 이유가 있을 수도 있다. 그때까지 완료하여 자본회수가 안된다면 회사가 심각한 위기에 처해 도산한다든가 그때까지 완료되지 않으면 핵발전소가 폭팔한다던가 혜상이 지구와 충돌하는 아마게돈이 일어난다고 개발자에게 솔직이 말한다면 중요도에 따라 일부 기능을 삭제한다든가 "상황은 매우 안좋지만 분발해보죠"라는 도전의식을 가질지도 모른다.


하지만 사실은 이 계약을 따낼때 접대 술자리에서 4개월에 무조건 하기로 했다던가 사실 당신의 말보다는 파킨슨의 법칙을 더 신용하기 때문이라면 프로그래머들은 타협의 이유를 생각하게 된다. 팀원에게 육체적,정신적 건강과 인간관계를 희생하라고 할때 그 희생의 결과는 무엇일까. 사실 대부분의 프로그래머들은 이러한 문제 프로젝트들은 대부분 실패하고, 또 그 정도까지는 아니라도 다른 생활을 포기하면서까지 매달릴만한 가치가 없다는 사실을 그동안의 값진 경험을 통해 잘 알고 있다. 그리고 그 타.협.대로 진행되서 일주일에 100시간 근무를 했더라도 25% 확률의 수고했어 라는 한마디 말 정도의 보상밖에 없다는 것도 말이다.


그렇다고 나를 비롯한 프로그래머들이 이러한 프로젝트를 항상 거부하는 것은 아니다. 사실 대부분의 프로그래머들이 그러하듯이 컴퓨터에 열광하는 내성적이고 그닥 사람들과 어울리는 것에 크게 관심이 없고 관심을 끌만한 도전의식이 있는 과제라면 최저한의 보상이라도 이러한 프로젝트에 참여할 것이다.

등산가들이 산이 거기 있기때문에 라는 어처구니 없는 이유로 에베레스트를 오르듯이 멋진 무언가를 만들기위해서는 일주일데 2번 가는 희생따위는 아랑곳 하지 않는 비정상적인 사람들이 우글우글 몰려 있는곳이 IT 바닥이다. 하지만 변덕스러운 고객의 마음을 독심술을 동원하여 맞추는데만 3개월이고 사실은 그저그런 재미없는 새로울것도 없고 멋진것도 없는 어디 내놔도 부끄러운 것을 만들어야 한다면 의욕은 감퇴하기 마련이다. (그래서 보통은 기한을 이유로 기능을 줄이지 않고 품질을 희생시키는 것은 좋은 생각이 아니다.)


결국 프로그래머들이 타협을 할 줄 모르는게 아니다.
다만 타협의 이유를 아무도 알려주지 않거나 사실 타협의 이유 따윈 없기때문에 타협을 하지 않는 걸 오해받을 뿐이다.




"전에도 말했지만 나는 누구나 한번씩은 문제 프로젝트에 참가해 볼 필요가 있다고 생각합니다. 그 외에도 한번씩 해봐야 할 일로는 이런것들이 있어요
 - 감옥에서 하룻밤 보내기
 - 변기를 끌어안을 정도로 술 마시기
 - 어린아이 키우기
 - 창업하기
 - 후지산 등반하기 "
by Rick Zahniser