점프와 쉼없는 나아감

2009년 09월 27일

아이피 차단 기능에 대해서

아이피 차단 기능 자체는 구현하기 어려운 건 아닐꺼다. 차단할 아이피 목록을 저장하는 기능과 댓글을 저장할 때 차단한 아이피에 해당되는지만 비교하여 차단하면 되니까. 그다지 많이 호출되는 기능도 아니기 때문에 특별히 효율적인 자료구조와 알고리즘을 고안할 필요도 아마 없을 꺼다.

다만 아이피 차단 기능의 효과에 대해선 고개를 갸웃할 수밖에 없다.

티스토리 같은 데엔 있지 않냐고 하는데... 아이피 차단 기능은 스팸 포스팅이나 brute force attack 같은 반복적인 공격에 대응할 때 주로 사용되는 거다. 설치형 블로그로 시작한 티스토리 같은 경우 스팸 차단과 같은 걸 스스로 해결할 수밖에 없으니 아이피 차단 기능이 있을 것이고 이글루스는 자체적으로 스팸은 차단하니까 없어도 별 문제되진 않을 꺼다.

커뮤니티 상의 갈등(?)을 해결하는 방법으로 아이피 차단을 사용하는 건 별로 효과가 없을 꺼다. 오히려 부작용만 더 많을 꺼라 생각한다. 대부분 DHCP를 통해 동적으로 아이피를 할당받아 사용하기 때문에 '아이피 == 사용자' 등식이 성립하지 않는다. 상황에 따라 다를 수 있는데 네트워크 설정만 내렸다 다시 올려도 다른 아이피를 할당받을 수 있다. 학교와 사무실 같은 곳도 관리상의 문제로 DHCP를 이용하는 경우가 많을 꺼다. 서버들도 DHCP로 관리하기도 하는데 뭘. 막고자 하는 사람은 안 막히고 엉뚱한 사람이 막힐 가능성만 많다.

아이피가 바뀌지 않더라도 Proxy를 이용하여 아이피 체크를 우회하는 건 쉽다. 간단히 쓸 수 있는 우회 툴도 많다. 파이어폭스에선 foxyproxy 같은 걸 쓰면 되고 proxy 목록은 구글로만 쳐봐도 쫙 나온다.

악플러나 뻘글러가 그런 수고를 감수하면서까지 댓글을 달까?라고 반문할 수도 있겠지만 "그런 수고를 감수하고"라도 그럴꺼라는데 100원 걸겠다. 그러니까 커뮤니티 상에서 갈등이 일어나는 거겠지.

이글루스가 아이피 차단 기능을 만들지 않는 이유는 모르겠다. 예전에 이글루스는 기능셋을 잘 관리한다는 느낌이 있었는데 지금은 좀 아니라는 느낌도 있다. 합리적인 이유에서인지 아니면 다른 이유에서인지는 모르겠다. 그렇지만 아이피 차단 기능이 추가된다고 해서 지금의 문제가 획기적으로 나아질 꺼라 생각하지 않는다. 그다지 나아지진 않을 꺼라 생각한다.

# by Corund | 2009/09/27 12:19 | 트랙백 | 덧글(6)

2009년 09월 17일

제대로 한 게 없다.

최근 몇 년동안 제대로 한 게 없다는 것을 느끼고 있는 요즘이다.

프로그래머로서 평생을 공부하면서 살 수 있을 거라 자신하며 이 길에 들어섰지만 어느덧 기존 관성에 빠져 허우적대고 있는 거 같다. 그저 재미로 이것저것 끄적여 보는 건 프로페셔널의 자세가 아닐텐데 여전히 dilettante적 자세를 고치지 못하고 있다. 건드려 본 건 많은데 그 중 제대로 하는 건 거의 없다. 일터에서 팀장으로서 무엇 하나 이뤄놓은 것도 없다. 개발 방법론도 없고 축적해놓은 라이브러리도, 노하우도 없다. 제대로 팀원을 교육시키는 메커니즘도 없도 업무를 인수 인계하는 프로세스도 없다.

계절은 가을로 접어들고 내 인생도 가을로 접어들었다. 연못가의 봄 풀이 채 꿈도 깨기 전에 계단 앞 오동나무 잎이 가을을 알린다는 그 짝이다. 우울한 요즘이다.

# by Corund | 2009/09/17 12:10 | 트랙백 | 덧글(0)

2009년 07월 30일

코코아 프로그래밍, 재미있네.

맥북을 사고 나서 OSX 용 프로그램은 어떻게 만드나 궁금해서 코코아 프로그래밍을 공부하기 시작했다 - 하나라도 제대로 공부해야 하는데 자꾸 이것저것 건드리기만 하니 이것도 문제다.

일단 "코코아 프로그래밍"이라는 책을 도서관에서 빌렸다. 반쯤 읽고 나서 예제를 실행시켜 보려고 xcode를 실행시켜 보니 책의 내용과 많이 달랐다. 알아보니 도서관에서 빌린 책은 2판이었고 최신 내용은 3판에 있는 거였다. 결국 책을 샀다.

Objective-C는 처음 접해보는 건데 시작하기에 그리 어렵진 않았다. C 언어에다 Smalltalk를 섞어 놓은 듯 보이는데 메시지 sending의 개념과 메서드 syntax가 Smalltalk와 같았다. Smalltalk는 대충 공부하다 말았는데 - 아무리 봐도 실용적으로 쓰기는 어렵다 싶어서 - 여기서 Smalltalk의 방식을 만나니 반갑기도 했다.

맥에서의 컴퓨팅은 즐거운 경험인데 코코아 프로그래밍도 아직까진 그렇다. 인터페이스 빌더를 이용해 비주얼하게 인터페이스를 디자인하고 객체와 연결시키는 작업이 참 산뜻하게 진행된다. nib에 객체가 아카이브되는 개념도 재밌다. xml 같은 것을 이용해서 코드로 작성했다면 참으로 지겨웠을 일이다.

맥북을 사용하면서 문제를 해결하는 또다른 방식을 자주 보게 된다. 코코아 프로그래밍도 그렇다. 재미있는 경험이고 새로운 경험이다. 내친 김에 아이폰 개발도 해볼까? :)

맥북, 코코아

# by Corund | 2009/07/30 15:53 | 트랙백 | 덧글(1)

2009년 07월 30일

scala 언어를 전면적으로 사용하기에는 아직 이른 듯하다.

scala는 여러가지 좋은 특징을 가지고 있고 자바에 비해 코드도 간결한 편이다. 자바 이후 또는 보조 언어로 우리 팀에 도입해 볼까 생각하며 공부해 봤지만 아래의 이유로 아직 전면적으로 쓰기에는 이른 듯 하다.

첫째로는 기존 자바 프로그래머가 scala에 익숙해지려면 공부해야 할 께 꽤 많다는 점이다. 함수형 패러다임과 용례에 익숙해지는 것부터가 만만치 않으며, 자바보다 복잡한 타입 시스템도 알아야 하고 여러가지 함축적 표현도 익혀야 한다.

둘째 IDE 지원에 문제가 있다. scala 이클립스 플러그인이 있긴 하지만 Syntax Highlighting 정도만 되는 수준이다. 자동 완성과 리팩토링 지원 정도는 되어야 한다. 이것이 안 되는 환경에서 코드를 작성하려니 갑자기 석기 시대로 이동한 기분이다.

세째 웹 개발의 경우 scala 웹 개발 프레임워크인 Lift가 꽤 난해(?)하다는 점이다. 서블릿 API 또는 JSP를 가지고 Front Controller 스타일 위주로 개발하는 것과는 사못 다른 방식을 취하고 있어서 개념을 잡기가 쉽지 않다. 더구나 환경 구성에 maven을 이용하는 법만 제시하고 있어서 maven을 모르는 경우 진입 장벽이 만만치 않다. 한 권밖에 없는 해설서도 난해한 편이어서 프레임워크를 이해하기가 쉽지 않다.

첫째 문제는 scala의 본질적인 문제라서 어찌 해결할 방법이 없다. 다만 scala 언어가 담고 있는 여러 개념들은 더 나은 개발자가 되려면 알아야 할 것들이라는 협박(?)으로 해결하는 수밖에 없다.

둘째와 세째 문제는 시간이 지나면 나아질 거라 기대해 본다. scala는 정적 타입 언어이기 때문에 동적 타입 언어보다 자동 완성과 리팩토링 지원 기능 구현이 상대적으로 쉽다 - 하지만 scala 언어가 상당히 복잡해서 구현이 쉽지는 않다 - 고 한다. scala 커뮤니티에서도 IDE 지원 문제가 꽤 논의되는 거 같다. 웹 프레임워크 문제도 시간이 지나면 좀더 많은 프레임워크가 등장하리라 기대한다.

능력과 시간이 되는 팀이라면 둘째, 세째 문제는 자체적으로 해결할 수도 있을 것이다. 우리 팀은 그럴 능력이 되지 못해서 거인의 어깨를 기다릴 수밖에 없다.

scala