블로그 태그를 붙인 글을 최신 순으로. 좀더 개인적인 글은 일기장에. 블로그 글 전체 목록은 내 글 모음에.

스프링노트_기술보고서

스프링노트를 오픈하고 나서 그 동안 사용했던, 그리고 경험했던 기술들을 하나씩 평가해 본다.

차례

Ruby on Rails
JavaScript
XHTML, microformat, WYSIWYM
REST
CSS
linux (RHEL vs ubuntu)
Subversion
총평

Ruby on Rails#

ActiveRecord#

RoR의 가장 큰 장점은 ORM인 것 같다. 현재 Rails류의 프레임웍이 많지만 완성도 면에서 RoR의 ActiveRecord만큼 높은 건 별로 많지 않다. 하지만 디자인 측면에선 맘에 안드는 부분도 있다. 순수 OOP적인 모델 설계를 지향하고 있는 SQLObject나 Hibernate, GORM에 비해 ActiveRecord는 테이블을 기술하는 방식에서 SQL에 더 가깝다. 코드로 한 번 비교해보자. 다음은 Rails에서 User라는 모델이 name과 password라는 프로퍼티를 가지는 경우이다.

  class AddANewTable < ActiveRecord::Migration
    def self.up
      create_table :users do |table|
        table.column :name,  :string, :null => false
        table.column :password, :string, :limit => 32, :null => false
      end
    end

    def self.down
      drop_table :users
    end
  end

이렇게 migrate를 만든다. 그리고 migrate를 실행하면 name, password라는 컬럼이 있는 users 테이블을 만들고 이 테이블을 ActiveRecordPattern으로 User 객체와 매핑시킨다. User 객체는 그냥 다음처럼 쓰기만 하면 된다.

class User < ActiveRecord::Base
end

user = User.new
puts user.name
user.password = 'xxx'

즉, 메타 정보를 담는 migrate 코드와 User 클래스 코드가 합쳐져야 하나의 모델이 되는 것이다. 게다가 메타 정보를 기술하는 방식은 SQL에 아주 가까운 방식이다. 그러면서 User의 메소드는 또 User class에 기술한다. 그래서 User class를 봐도 무슨 프로퍼티가 있는지 알기가 어렵다. SQLObject랑 비교하면 이 차이는 더 드러난다.

class User(SQLObject):
    name = StringCol(length=100)
    password = PasswordCol(default='')

user = User('a')
print user.name
user.password = 'xxx'

User 클래스 하나에서 모든 정의를 한다. 그래서 조금 더 응집성이 높고 간결하다. GORM도 이런 방향을 지향하고 있다. Django도 DRY 원칙이나 OnceAndOnlyOnce의 입장에서 이런 방식을 채용했다.

하지만 Real World에서는 꼭 SQLObject 쪽이 좋다고 할 수 없다. SQLObject도, Hibernate도 지원이 부실한 부분이 바로 스키마의 migration이다. Rails는 앞서의 migrate 코드를 실행하면 self.up 코드를 실행하고 또 migrate back을 하면 self.down을 실행한다. 그래서 스키마 변경 코드도 migration으로 만들 수 있다. 이를테면 위의 예에서 User에 email 필드를 추가한다고 해보자. Rails는 다음과 같은 migration 코드를 만들고 rake db:migrate 명령을 내린다.

  class AddANewTable < ActiveRecord::Migration
    def self.up
      alter_table :users do |table|
        add_column :email,  :string, :null => false
      end
    end

    def self.down
      alter_table :users do |table|
        remove_column :email
      end
    end
  end

그러면 self.up 부분이 실행되서 스키마를 바꾼다. migrate는 역도 가능하다. 이게 꼭 매끄럽게 되는 건 아니지만 역 migrate도 가끔 필요하다. 그래서 이런 시점에 migrate에 필요한 작업들을 해줄 수 있다. 하지만 SQLObject나 GORM 등에서는 그냥 클래스 정의만 바꾸면 이게 테이블에 자동으로 반영된다. 이 자동이란 게 편하기도 하지만 가끔 데이터를 날려 먹는 수가 있다. 그래서 이런 건 조금 더 SQL에 가깝고 수동으로 할 여지를 많이 열어 놓은 Rails가 유리한 점이 있다.

하지만 어차피 migration 코드에 model 객체를 이용한 코드를 집어 넣으면 migration이 가끔 안되는 수가 있다. 이론적으로는 migration 파일이 1부터 10까지 있으면 1부터 10까지 쭉 실행하면 데이터가 다 자동으로 변환되면서 스키마가 변경되어야 하지만 1단계에는 있는 모델 클래스가 5단계에는 없을 수 있고 또 그 반대도 있기 때문에 모델이 들어간 migration 코드는 종종 class not found 에러를 낸다. 그래서 어차피 migration은 sql을 이용해서 하거나 수동으로 script/console을 열고 하는 경우가 많다. 팀에서 한 사람이 쭉 migrate를 쌓아 놓은 것을 다른 개발자들이 제때 제때 따라가지 못하면 migrate를 할 수 없어서 개발 DB를 다른 사람 껄 덤프 떠와야 하는 일도 간혹 있다. 이를 대비해서 schema:load 같은 명령도 있지만 잘 안된다. 이런 식이라면 SQLObject도 충분히 할 수 있기 때문에 큰 차이는 아닐 수 있다. 어쨋건 Rails의 ActiveRecord가 나름 실용성과 디자인의 중간을 찾으려고 애를 썼고 두 마리 토끼를 절반씩은 잡았다는 점은 Rails의 중요한 장점이다. 사실 익숙해지면 ActiveRecord의 응집성 문제는 그다지 annoying하지 않다.

성능은 조금 문제가 있다. Django 같은 경우는 QuerySet을 iterate할 때 쿼리가 날아가기 때문에 그 앞에서는 안심하고 여러 가지 조합을 해줄 수 있는데 Rails는 좀더 많은 종류의 코드들이 직접 쿼리로 날아간다. 그래서 모델 4, 5개 정도 사용하는 페이지에서 무려 80여개의 쿼리가 날아가기도 한다. 결국 다 만들어 놓고 캐싱하고 최적화 하는데만도 엄청난 시간을 투자했으니 ORM으로 인해 초반에 얻은 장점을 후반 가서 다 까먹는다고도 할 수 있을 것 같다. 하지만 이부분은 꾸준히 개선되고 있는 듯하니 지켜볼 일이다.

RHTML#

JSP랑 똑같다. 스크립트렛 문법은 거의 완전 똑같다. JSP의 모든 장점과 단점을 다 그대로 계승하고 있다고 보면 된다. 한 가지 짚고 싶은 것은 RHTML식 태그 라이브러리(?). JSP에서 태그 라이브러리로 하는 것들을 RHTML은 모두 ruby 코드를 그대로 노출시켜서 하고 있다. 이걸 helper 메소드라고 부른다. 태그가 코드보다 낫다는 말을 하려는 것은 결코 아니다. 오히려 이 점은 RHTML의 장점이다. JSP에서 태그 만들려면 해야 되는 삽질이 좀 된다. JSP 2.0에서 좀 나아졌다고는 해도 여전히 Rails에 비하면 불편하다. Django에서 사용하는 템플릿도 태그를 따로 만들려면 일반 파이썬 메소드가 아니라 태그 인터페이스에 맞춰야 하기 때문에 불편한데 RHTML은 그대로 ruby 코드로 모든 것을 할 수 있어서 좋다. 물론 이걸 단점이라고 말하는 사람도 많지만 JSP의 태그 라이브러리가 스크립트렛보다 전혀 낫다고 생각하지 않는 나로선 이건 분명 장점이다. 문자열 길이 제한하는 코드 좀 써넣자고 태그 라이브러리를 만들어야 하는 것보다는 간단히 [..50] 같은 걸로 쓰는 게 훨씬 가독성도 높고 편리하다.

그렇지만 Rails 태그 라이브러리들 자체는 별로 옹호하고 싶지 않다. JSP 태그 라이브러리들의 단점 중 많은 부분을 그대로 계승하고 있기 때문이다. JSP에서 가장 싫은 부분이 form을 좀 편하게 써보자고 다 태그 라이브러로 만드는 것이다. 하지만 그래서 편해지기는 커녕 호환성 떨어지는 코드가 되고 form 태그와 많은 면에서 중복이 된다. 그래서 임의의 속성 달기도 어렵고 HTML만 아는 UI 개발자랑 협업하기도 어렵다. 둘다 도대체 form을 왜 그렇게 괴롭히는지 모르겠다. 여기서 Rails가 좀더 나쁜 부분은 JavaScript까지 헬퍼 메소드로 집어 넣고 있다는 것이다. 이걸 두고 루비 개발자들은 나대지 않는 자바스크립트니 어쩌니 하면서 좋아하지만 이것 역시 UI 개발자와의 협업을 어렵게 만들고 지저분한 HTML 소스 코드를 생성할 뿐더러 자유도까지 왕창 떨어뜨린다. 제발 HTML에서는 루비 코드가 나대지 말았으면 하는 게 내 소망이다. 루비가 DSL을 지향하는 언어라면 HTML 속에서는 HTML스러운 코드를 써야 한다. 근데 HTML 안에서도 루비스러운 코드를 써보자고 온갖 문제를 만들어내는 헬퍼를 남발하고 있다. 그래서 실제로 RHTML 코드들을 보면 몇 년 전 사람들이 JSP 처음 쓸 때 이상으로 지저분하다.

템플릿 재활용에 관한 부분은 좋은 편이다. Tiles나 SiteMesh 같은 자바 쪽 템플릿에 비해 구조화하기가 훨씬 수월하다. 자바는 반성하라! header와 body를 따로 넣을 수도 있고 부분만 분리하거나 상속 비슷한 개념을 활용할 수도 있다. 하지만 파이썬의 cheetah에 비하면 조금 부족한 느낌이다.

webrick & mongrel#

Rails가 자바보다 나은 건 rails만 그냥 설치하면 자바처럼 톰캣 깔고 설정하고 할 필요 없이 바로 script/server로 띄워볼 수 있다는 것이다. 하지만 이것도 cherrypy 같은 프레임웍에서 훨씬 일찍 보여준 것이고 cherrypy는 그냥 그대로 띄워도 production scale이 나오는데 webrick은 절대 production에서 쓸 수 없다. 그래서 webrick에서 속도에 민감한 부분을 C로 바꾼 mongrel을 쓴다. 하지만 이것도 성능은 그닥 좋지 않아 보인다. 그리고 루비는 자체 쓰레드 모델이 없기 때문에 실제 서비스에서는 직접 프로세스를 여러 개 띄워야 한다. 그러다보니 자바의 서블릿 컨텍스트 같은 개념도 없고 start/stop도 실제 서비스에서는 간단치 않다. apache랑 연동하지 않으면 서비스할 수 없는 것은 물론이고. 차라리 mod_ruby 쪽으로 최적화시키는 게 성능 면에서나 관리 면에서나 더 낫지 않을까 싶다.

어쨋든 현재 스프링노트에는 초당 10~15 request가 들어오는데 CPU 사용률이 30~70%를 오락가락한다. tomcat에서 웬만큼 무거운 SQL과 로직을 돌려도 초당 40 request에 CPU 20%도 안 먹었었던 걸 생각하면 Rails does not scale이라고 해도 할 말 없을 것 같다. 물론 앞서 언급한 것처럼 ORM의 성능 문제가 더 크긴 하지만 Rails 자체도 우분투에서 제 성능이 안 나오는 등 아직 문제가 많다.

RSpec on Rails#

RSpec은 BehaviorDrivenDesign의 생각에 따른 새로운 UnitTestFramework이다. BDD는 TDD와 같은 개념이지만 용어들을 좀더 인간적으로 말이 되게 하는데 초점을 맞췄다. 코드로 비교하면 이렇다. (이건 비교를 위한 샘플이고 실제로 이런 테스트를 만들진 않는다.)

TDD

class UserTest < Test::Unit::TestCase
  def test_create
    user = User.create(:name => 'Karl')
    assertEquals user.name, 'Karl'
  end
end

BDD

context "user's behavior" do
  specify "should be invalid without a username" do
    user = User.create(:name => 'Karl')
    user.name.should_be_eql 'Karl'
  end
end

용어들이 조금씩 다르다. 보다시피 rspec이 좀더 자유롭게 spec을 서술할 수 있고 테스트 코드도 뭔가 좀더 말이 되는 것 같아 보인다. 이외에도 user.should_be_valid 같은 메쏘드를 실행하면 user.valid? 메소드를 실행해서 그 결과로 assert를 해 주는 등의 장점이 좀 있다.

그러나, 사실 큰 차이는 아닌 것 같다. 그리고 TDD에 익숙해진 사람들에게 조금 거슬리게 다가오는 부분이 하나 있다. 보통 TDD에서는 assert를 할 때 expected를 먼저 쓰고 result를 뒤에 쓴다. 하지만 BDD에서는 result.should_be expected와 같은 형식이 된다. 호불호의 문제일 수도 있겠지만 나에겐 전자가 좀더 명확해 보인다. 괜히 메이저도 아닌 언어가 두 개의 테스팅 프레임웍을 가진다는 게 그닥 좋아보이지 않는다.

사실 더 큰 문제는 RSpec on Rails에 있다. 이건 RSpec에서 오는 문제보다 Rails에서 오는 문제가 더 크다. RSpec on Rails의 테스트 코드들을 보면 다음과 아주 유사한 코드가 아주 많다.

fixtures :users
controller :sessions

specify ... do
  get :login, id=>@first_user.id, :passwd => 'xxx'

  @first_user.should_be_logged_in
end

얼핏 보기엔 아주 깔끔하고 좋은 코드 같아 보인다. 근데 문제는 저 코드를 실행하면 실제 Rails의 Controller가 내부적으로 떠서 동작한다는 것이다. Java의 Cactus처럼 100% 다 뜨는 것은 아니지만 핵심 코드들은 다 로딩되기 때문에 엄청나게 느리다. 느린 것도 문제거니와 테스트 해야 하는 것은 controller의 로직인데 저 코드는 일종의 FunctionalTest처럼 되서 안에서 모델 사용하는 로직이 있으면 실제로 DB도 다 갔다 온다. 위에서 선언된 fixtures를 통해서 테스트에 필요한 데이터들을 미리 DB로 로드하고 테스트에서는 그 데이터에 실제로 쿼리를 날리는 것이다. 그리고 그 결과로 assert를 한다. 그래서 Test의 granuality가 좀 어중간하다. 아예 FunctionalTest라면 FIT 등으로 쉽게 만들 수도 있는 부분인데 나름 UnitTest 프레임웍이라서 그런 지원이 없다보니 위와 같은 코드가 주욱 늘어서는 중복 아닌 중복이 발생하게 되는 것이다. UnitTest의 입장에서도 테스트하려는 부분만 떼서 테스트할 수 없기 때문에 TDD의 가장 큰 효과, 좋은 디자인을 만들도록 유도하는 효과가 적다. 결과적으로 spec 하나만 놓고 보면 깔끔한 코드지만 spec들이 주욱 늘어서면서 중복이 되고 또 정작 실제 코드의 디자인에는 긍정적인 영향을 주지 못하는 것이다.

테스트 실행이 느린 것도 문제다. Java에서 보통 프레임웍의 Action 테스트 100개 정도 돌리면 거의 10초도 안 걸리는데 Rails의 controller 테스트를 돌리면 듀얼코어에서도 100개에 4,5분은 족히 걸리는 듯하다. 컨테이너 띄우고 DB까지 다 갔다 오니 그럴 수 밖에 없다. 그나마 TextMate에서는 spec 하나 단위로 실행할 수 있고 이상하게도 Mac에서는 상당히 빠르지만 다른 툴에서는 테스트 돌리기가 꺼려질 정도이다.

이 문제의 원죄는 RSpec on Rails가 아니라 Rails 자체에 있다. 일반적으로 Java나 Python 프레임웍에서 controller를 테스트할 땐 그냥 new로 객체 생성하고 메쏘드 실행하면서 mock object만 약간 넣어주면 땡이다. 대부분의 경우 mock object조차도 필요 없다. 하지만 Rails는 controller 코드들이 컨테이너 없이 동작하게 만들려면 상당히 많은 수고를 해야 한다. 그래서 위에서 보는 것처럼 get, post 같은 걸로 쉽게 요청을 때릴 수 있는 툴들을 제공하는 것이다. 하지만 그보다 좀더 가볍게 controller를 mock으로 만들 수 있게 했다면 controller의 디자인 자체도 더 좋아졌을 것이고 테스트하기도 더 쉬웠을 것이다. 테스트하기 좋은 코드가 좋은 코드라는 말이 이럴 때 보면 정말 맞는 것 같다.

이 문제는 controller만의 문제가 아니다. Rails의 모든 컴포넌트들이 다 독립적으로 테스트하기가 어렵다. 컨테이너가 뜨지 않으면 제대로 테스트할 수 있는 건 lib 정도일까. 머, 어쨋든 해결 불가능한 문제는 아니다. mock object를 미리 좀 만들어두고 재사용하면 그나마 편하게 테스트할 수 있다. 사실 그보다 더 큰 문제는 Rails 커뮤니티에서 위와 같은 방식을 권장하고 있을 뿐더러 이런 문제를 개선하려면 Rails 자체에 많은 변화가 가해져야 한다는 것이다. Convention over Configuration의 약점은 이럴 때 드러난다. Rails 전반에 걸쳐 너무 많은 Convention을 강요하고 있기 때문에 작은 변화 하나 일으키기도 쉽지 않다.

루비라는 언어#

난 루비가 The Principle of least surprise에 의거해서 디자인되었다는 것에 절대 공감할 수 없다. 오히려 내가 아는 언어 중 가장 surprise가 많은 언어가 루비다. Functional Language에 대한 개념이 전혀 없던 상태에서 Haskell을 써봤을 때도 이렇지는 않았다. 루비스트들은 이렇게 하면 될 것 같다라는 추측으로 코드를 쓰면 되는 경우가 많아서 좋다고 이야기하는데 난 오히려 그게 불만이다. 이렇게 하면 될 것 같다라고 생각해서 코딩했는데 안 되는 경우도 적지 않기 때문이다. 또, 이렇게 하면 안될 것 같은데...라는 느낌으로 썼는데 되는 경우도 있고 코드를 보면서 이런 것도 된단 말야하고 놀랄 때도 있다. 다른 언어는 그렇지 않다. 되는 코드와 안 되는 코드는 한 번에 알 수 있다. 이런 모호함이 난 좀 싫었다.

또 순수 OOP 언어라고 주장하지만 실제로 그렇지 않은 것도 문제다. 실제로 루비에서 가장 중요하다는 루비 블럭은 객체가 아니다. 메쏘드도 객체가 아니고 함수도 객체가 아니다. 때문에 python이나 javascript류의 언어에 비해 mock을 만드는 것이 상당히 귀찮은 편이다. 사실 순수 OOP라는 것 자체가 별로 가치 있다고는 생각하지 않지만 루비는 여러가지 개념들로 OOP를 어지럽히고 있으면서도 순수 OOP라고 주장하는 것이 좀 거슬린다.

그럼에도 불구하고 루비는 매력이 있다. 내가 느끼는 가장 큰 매력은 괄호를 적게 쓸 수 있다는 것이다. 그래서 마치 원래 그런 문법이 있는 것처럼 DSL을 상당히 높은 자유도로 만들 수 있다. 루비 블럭도 그런 DSL을 만드는데 많은 도움을 준다. 블럭이 단점도 많지만 그래도 간결한 코드를 만드는데 도움이 되는 것은 사실이다. 잘 짠 파이썬 코드는 눈에 구조가 확 들어오면서 이해가 빠른 장점이 있다면 잘 짠 루비 코드는 술술 읽으면 말이 되고 보기에 미려하다는 장점이 있다.

하지만 나에게 또 루비로 프로젝트를 하고 싶냐고 묻는다면 대답은 No다. 난 아름다운 코드보다는 읽기 쉬운 코드가 좋다. 루비스트들은 그 아름다운 코드란 것에 많이 끌려서 루비를 선택하지만 실질적으로 많은 가치를 주는 것은 아닌 것 같다. 오히려 루비를 하면서 smalltalk를 깊이 배워보고 싶다는 생각이 든달까.

Third party#

루비의 또 하나의 약점은 Third Party Library의 완성도가 낮다는 것이다. 웬만한 게 다 있긴 하지만 완성도가 떨어지는 게 많다. 그러다보니 다른 언어 라이브러리에 바인딩해서 쓰는 경우가 많고 또, 그러다보니 개발 과정에 설치해야 할 것이 많아서 여러 개발자가 같이 개발할 때 어려움이 좀 있다. 특히, 중요한 라이브러리들이 *Nix 플랫폼 기준으로 개발되어 있어서 윈도우에서 개발할 때는 에로사항이 꽃핀다. jar만 떨구면 되는 Java와 비교할 수는 없다 해도 같은 계열인 파이썬이나 펄에 비해 플랫폼 독립성이 많이 떨어진다.

Eclipse vs TextMate#

루비 개발자들이 가장 선호하는 개발툴은 Mac 위에서 돌아가는 TextMate다. 근데 이넘을 뜯어보면 그닥 유쾌한 툴이 아니다. Eclipse 같은 경우는 컨텍스트 메뉴가 강력해서 단축키를 몰라도 오른쪽 버튼 눌러서 기능 쓰면서 단축키 하나하나 익힐 수 있다. 하지만 TextMate는 단축키 모르면 전체 메뉴를 헤매면서 기능을 찾아서 써야 한다. 단축키 매핑도 Mac이라 그런지 일반적인 에디터의 단축키와 너무 다르다. SCM 지원도 빈약하고 프로젝트 관리도 부실하다. 좋은 점은 Rails에 특화된 기능이 많다는 것. RSpec이나 Rails랑 바로 붙는 기능들이 많아서 Rails 개발할 때는 은근히 편리한 점이 많다. 하지만 좀처럼 익숙해지기 어려운 툴이라는 점에서 vi와 같은 한계를 갖고 있다.

이에 비해 Eclipse는 안정적인 플랫폼에 꽤 괜찮은 루비 지원을 해주지만 몇 가지 아쉬운 점이 있다. 하나는 spec 하나 단위로 RSpec을 돌릴 수 없다는 것. 그리고 pydev에 비하면 코드 어시스트가 없어서 모든 것을 외워서 써야 한다는 것. 어쨋든 난 Mac도 없고 Eclipse 밖에 대안이 없어서 쓰고 있는데 TextMate보다는 좀더 편한 것 같다.

bash, ant, perl vs rake#

개발에서 또 하나 중요한 것이 빌드, 배치 등의 사이클을 관리하는 스크립트다. 루비에선 이걸 rake로 하고 있는데 나름 ant와 make의 장점을 흡수하려 애쓴 것 같긴 하지만 결과적으로는 그냥 another ant 정도인 것 같다. XML이라는 ant의 불편함을 제거하고 보다 가독성 높고 확장성 높은 루비 언어로 할 수 있다는 것은 좋으나 여전히 루비 코드들에서 공통적으로 나타나는 프레임웍성의 구조가 마음에 안든다. 차라리 groovy의 gant가 낫지 않나 싶다. 그리고 실상 의존성 체크가 별로 중요하지 않은 dynamic language에서는 그냥 bash 스크립트가 더 나은 것 같기도 하다. perl을 배워두면 bash 기반으로 쓰다가 약간 확장해야 할 때 perl을 쓸 수 있다. 이게 자동화 관련에서는 가장 편리한 조합이 아닐까 싶다. python도 몇 차례 스크립팅에 활용해봤는데 perl에 비하면 이런 류의 작업에는 좀 덜 기민한 것 같다.

Naming Convention#

주로 자바 프로젝트들을 해왔기 때문에 CamelCase에 익숙한데 이번에 루비를 하면서 underscore를 구분자로 사용하는 걸 많이 썼다. CamelCase에 비해서 타이핑 부담이 클거라고 생각했는데 의외로 별 차이 없었다. 가독성 역시 비슷하다. 장단점이 약간 있는데 CamelCase에 비해 한 identifier 내의 단어 구분은 좀더 명확한 반면, 기호를 많이 쓰고 괄호가 적은 ruby 코드에서는 다른 identifier들과 혼동이 되는 경우가 종종 있었다. 이것 때문에 ruby 코드가 보기에 따라서 자연 언어에 더 가깝다고 하기도 하고 또 좀더 지저분해보인다고 하기도 하는 것 같다.

JavaScript#

내가 JavaScript를 제대로 써본 건 이번 프로젝트가 거의 처음이다. 2004년 쯤 웹 표준에 관심을 가지면서 HTML, CSS는 상당히 많이 공부를 했었는데 JavaScript는 그냥 생각보다 괜찮은 언어 정도로 인식하고 있었다. 근데 이번에 정말 JavaScript를 제대로 써보면서 정말 많이 감탄했다. 핵심 문법을 단 몇 줄로 설명할 수 있을 정도로 간결함에도 표현력이 아주 높다. 자세한 건 이미 JavaScript 페이지에 정리를 많이 해놨으니 여기선 패스.

XHTML, microformat, WYSIWYM#

웹 표준, 시맨틱 웹과 관련해서 XHTML, microformat이 많이 뜨고 있다. WYSIWYM(What You See Is What You Mean)이란 용어도 생겼다. 스프링노트도 이 문제로 많은 노력을 기울였다. 하지만 난 좀 회의적이다. 사실 XHTML microformat을 완벽하게 하더라도 WYSIWYM과도 무관한 얘기다. 그저 또 하나의 DocBook이 될 뿐. 이 문제에 관련해서 많은 사람들이 의미론과 형식론을 혼동하고 있다. 제목을 h1 태그에 넣고 문단은 p로 구분하고 리스트는 li 안에 넣으면 형식적으로 잘 꾸며진 문서는 될 수 있지만 의미론적으로는 아무 도움을 주지 못한다. 그런데 시맨틱 웹이니 WYSIWYM이니 하는 용어와 얽어서 마치 사용자에게 어떤 시맨틱한 장점을 줄 수 있는 것처럼 오도하고 있다. 실상은 표현력은 제약하면서 실질적인 이득은 거의 없다. 웹 브라우저의 기본 에디터가 microformat이 아닌데 굳이 microformat을 맞추려면 적지 않은 희생을 치러야 하기도 하고.

좀더 pragmatic하게 접근해야 하는 문제다. XHTML이 기술적으로 제공하는 장점은 어느 정도 있다. validation을 통해서 심각한 오류는 사전에 잡아낼 수 있는 경우가 많다는 것, XML과 섞어서 사용하기 쉽고 XSLT 등의 XML 관련 기술을 쉽게 활용할 수 있다는 것. 하지만 microformat이 줄 수 있는 장점은 그다지 많지 않다. microformat을 기반으로 뭔가 해주는 도구들이 많다면 어느 정도 자동화의 장점을 누릴 수 있기는 하다. 이를테면 검색 엔진에서 h1~5나 strong 태그 등에 중요도를 높인다든지, HTML 문서를 PT로 자동 변환 한다든지. 하지만 아직 microformat을 기준으로 동작하는 툴은 많지 않은 반면 microformat을 제대로 지키기 위한 비용은 HTML 에디터에서 쉽게 감당할 만한 것이 아니다. 호환성은 오히려 HTML 4.01 transitional보다 훨씬 떨어진다. 스프링노트로 외부 HTML 문서를 붙여 넣거나 반대의 동작을 할 때 뷰가 많이 깨지는 것도 microformat에 원죄가 있다. 사용자를 위한 HTML 에디터를 만들고 싶은 거였다면 microformat은 하지 말았어야 했다.

REST#

REST는 HTTP method인 GET/POST/PUT/DELETE와 resource에 대한 URI의 결합으로 애플리케이션의 모든 동작을 정의하는 URL 스킴이다. 스프링노트에서 페이지를 예로 들면 ID가 150인 페이지를 읽을 땐 GET으로 /pages/150에, 내용을 업데이트할 때는 PUT으로 /pages/150에 요청한다. 예전 같으면 /pages/150?action=read 와 같은 식이거나 혹은 /pages/update?id=150 처럼 표현했을 것을 같은 URI에 HTTP 메소드로 CRUD를 구분하는 것이다. 이것도 요즘 유행인 듯 하다.

먼저 REST에 대한 비판 하나를 짚고 넘어가면, 애플리케이션의 모든 동작이 REST의 네 가지 동작으로 쉽게 정의되지 않는다는 비판이 있다. 우리가 개발하는 애플리케이션은 너무 복잡해서 CRUD로 단순하게 나눌 수 없어! 라는 이야기. 하지만 이것은 좀더 잘게 모델링을 해야 하는 문제일 뿐이다. 이를테면, 스프링노트에 페이지 잠금을 요청하는 URL이 있는데 이걸 단순하게 /pages/150?lock 과 같이 요청하는 것이 일반적인데 이런 건 lock이라는 resource를 새로 정의하면 쉽게 해결된다. 잠금 요청은 새 잠금을 만드는 것이니 /pages/150/lock을 POST로 요청하면 된다. 로그아웃은 /user?logout이 아니라 DELETE /session이 되는 것이다.

이런 식으로 REST를 사용하면 URL의 의미가 좀더 명확해지고 애플리케이션에서 모델만 잘 정의하면 컨트롤러는 거의 반자동으로 작성할 수 있게 된다. 외부에 좀더 hackable한 URL을 제공할 수 있기도 하고.

하지만, 이런 REST의 장점을 가로 막는 중요한 제약사항이 하나 있다. 웹 브라우저를 포함한 대부분의 HTTP 클라이언트들이 디폴트로 GET/POST만 지원하고 PUT/DELETE는 지원하지 않는다는 것이다. 그래서 실전에서는 PUT /pages/150은 /pages/150?_method=PUT 과 같은 방식으로 사용한다. 이 무슨 삽질인가! 이래서는 /pages/150?action=update와 별반 다를 바가 없다. 그리고 좀더 hackable한 URL이긴 하지만 실제로 더 hackable하진 않다. 대부분의 HTTP 라이브러리들이 PUT, DELETE를 기본으로 지원하지 않기 때문이다.

또 하나의 문제는 MVC에서 설계한 model을 좀더 작은 resource로 나눠야 한다는 것이다. 앞서의 비판이 가능/불가능의 이야기라면 부적절한 비판이지만 비용의 문제가 된다면 쉽게 무시할 수 없는 비판이 된다. model을 작게 나누는 것이 반드시 좋은 디자인이 되는 건 아니기 때문이다. 그래서 model은 그냥 내버려두고 controller에서만 따로 처리하는 경우가 많은데 이로서 REST는 기술적인 장점을 거의 상실하게 된다.

실질적으로 스프링노트에서 REST는 득보다 실이 더 많았다. REST 라이브러리가 어떻게 된 건지 자동화가 안되서 매 resource를 다 routes에 정의해줘야 했다. Rails의 중요한 장점 중 하나인 ConventionOverConfiguration을 잃은 것이다. 그러면서 간혹 REST가 아닌 URL들도 섞여 들었다. 그러다보니 점점 URL과 controller가 어떻게 매핑될지 예측하기가 힘들어졌고 그래서 View 단에서 작업하는 것도 더 힘들었다. 좀더 자동화된 개발 도구가 나오기 전까지는 REST 도입은 자제하는 것이 좋을 것 같다.

CSS#

CSS는 예전에도 꽤 많이 했었기 때문에 그렇게 새롭게 익혀야 하는 것이 많진 않았다. 근데 하면서 UI 개발자들의 코딩 컨벤션에 몇 가지 불만이 있었다. 예를 들면 다음과 같은 코드가 있다.

div#main table tr td.data {
    background-color: yellow;
    ...
    ...
}

csskorea에서 권장하는 방식인지 어떤지 모르겠는데 내가 접한 UI 개발자들은 대개 다 이런 식으로 css selector를 사용한다. 즉, select해야 하는 대상 엘리먼트에 이르는 경로를 쭈욱 기술해주는 것이다. 이렇게 하면 CSS 코드만 봐도 HTML 구조가 보이기 때문에 찾아가기가 쉽다고 한다. 하지만 사실 난 그 점을 공감할 수 없었다. 어차피 css selector 문법으로 찾아갈 수 있다면 사람도 쉽게 찾아갈 수 있다. 나는 selector에 최소주의를 선호한다. 해당 엘리먼트를 선택할 수 있는 최소한의 경로만 써주는 것이다. 위와 같은 경우라면 .data만 써도 웬만하면 다 될 것이고 정 불안하면 #main td.data 정도를 쓰면 될 것이다. 중간 경로는 사실상 무의미하다.

경로를 다 써주는 방식의 문제는 크게 두 가지다. 하나는 중복 문제다. 스프링노트의 경우 dialog가 20여개 되는데 dialog 전체에 공통적인 css가 대부분인데도 모든 dialog의 CSS가 다 따로따로 있다. 그래서 스타일 바꾸려면 이걸 다 찾아서 바꿔야 하고 selector에서 실수하기도 쉽다. 파일 크기가 커지는 것도 문제다. 로딩 타임과 랜더링 타임이 느려지는 것도 문제거니와 관리해야 하는 파일 사이즈가 커지니까 유지보수하기도 어렵다. 그냥 클래스만 공통으로 주고 공통 속성들을 dialog 클래스에만 주면 이런 중복은 다 제거할 수 있다. 또 하나는 HTML 구조에 의존하기 때문에 구조를 쉽게 바꿀 수 없다는 것이다. 개발하다보면 HTML의 구조를 뜯어고칠 일이 적지 않게 있는데 그 때마다 CSS의 selector를 다 바꿔줘야 하기 때문에 구조 변경의 부담이 크다.

내 생각엔 selector에는 특수한 경우에만 태그를 명시해주고 그 외에는 최대한 id나 class만을 사용하려고 노력하는 것이 좋을 것 같다.

linux (RHEL vs ubuntu)#

RHEL은 NHN에서부터 줄곧 써왔지만 사실 잘 모른다. 늘 소스 컴파일로 설치를 해서 썼기 때문에 패키지는 거의 사용하지 않았다. 반면 우분투를 쓸 때는 패키지가 있는 건 특별히 패키지 구성이 심하게 맘에 들지 않는 이상 패키지를 우선으로 썼다. 그래서, 사실 제목은 RHEL vs ubuntu지만 내용은 웹 서버에 애플리케이션을 설치할 때 소스 컴파일을 하는 것이 좋은가, 패키지로 설치하는 것이 좋은가에 대한 이야기다.

과거 자바를 주로 개발할 때는 아파치와 DoS 방지 모듈, jk 커넥터 정도만 컴파일해서 썼고 Java와 tomcat 등은 그냥 갖다 풀기만 하면 되서 별로 어려운 작업이 아니었다. 라이브러리는 죄다 jar로 떠 놓으면 되기 때문에 모두 CVS로 관리가 되고 변경될 때마다 소스와 같이 배포가 되기 때문에 라이브러리 관리 문제는 거의 없었다. 하지만 Rails와 PHP를 쓰게 되니 이야기가 많이 달랐다. 아파치에 설치해야 하는 모듈만 6,7개 정도에 memcache, mysql client 등 컴파일해야 하는 게 한두 개가 아니었다. 그래서 모든 설치를 다 마치는데 서버 한 대당 거의 1시간이 넘게 걸렸다. 시간도 시간이지만 이것들을 모두 설치하고 세팅하는 과정이 너무나 짜증스러웠다. 우분투를 썼다면 거의 5분 안에 완료할 수 있는 작업인데 컴파일하고 세팅하고 하느라 삽질하다보니 정말 시간이 아까웠다. RHEL을 선택한 이유는 Rails가 우분투에서 제 성능이 안 나와서인데 RHEL 라이센스 구매가 늦어져서 레드햇의 패키지 관리 시스템은 못 쓰고 소스 컴파일을 하게 된 상황인데 차라리 우분투에서 제 성능 나오게 하는 삽질을 하는 게 더 적은 비용이 드는 일이 아니었을까 싶다. 결과적으로는 이 삽질도 내가 Rails를 싫어하게 된 계기 중 하나가 되었다.

우분투에서 제공하는 아파치 패키지 구조가 다른 배포판과는 약간 다른데 알고보면 상당히 편리하다. 대부분의 모듈이 패키지로 있기 때문에 설치하기도 쉽고 설정 파일도 직관적으로 나눠져 있다. 특별한 이유가 없다면 우분투에서는 아파치 패키지를 그냥 쓰는 것이 제일 좋은 선택일 것이다. Rails도 그냥 패키지로 설치해도 쓰기에 별 무리가 없다. 어차피 EdgeRails를 쓰는 경우는 Rails 패키지가 아무 버전이나 깔려만 있으면 되기 때문에 상관 없기도 하고. mysql도 그냥 패키지로 설치해도 별 문제 없다.

실제로 개발 데스크탑으로 우분투를 쓰고 있다면 서버도 그냥 우분투를 쓰는 것이 더 나은 선택일 것이다. 로컬에서 실험해본 것을 거의 그대로 활용할 수 있으니까. 그래서 이번에 Django로 개발하는 프로젝트는 로컬에서 설정한 그대로 서버에 적용해서 비교적 쉽게 설정할 수 있었다. 우분투의 전략 중 하나가 데스크탑을 널리 퍼트려서 개발자들이 데스크탑에서 우분투를 쓰게 되면 자연히 서버도 우분투를 쓰려고 할 것이라는 것인데 내가 넘어간 걸 보면 꽤 괜찮은 전략인 것 같기도-_-

Subversion#

아직 CVS를 쓰고 있다면 Subversion으로 옮겨 타지 말라. Subversion이 CVS보다 나은 점은 없다. 같은 개발진이 만들었다면서, 더 낫게 만들려고 했다면서 왜 이 모양인지. 가장 심각한 문제는 툴의 완성도가 낮다는 것이다. 이클립스에서 편리하게 쓸 수 있는 CVS에 비해 Subversion을 이클립스에서 쓰려면 대단한 인내심이 필요할 것이다. 버그가 너무 많다. 커밋이 잘 안되는 경우는 부지 기수고 merge도 잘 안되고 삭제나 이동도 일반적인 기대와 다르게 동작한다. subclipse는 정말 후졌고 subversive는 그나마 조금 쓸만하지만 여전히 CVS 플러그인에 비하면 너무 부족하다. 더 심각한 문제는 커맨드 라인에서 써도 버그가 발생한다는 것이다. 많은 파일과 디렉토리를 한 번에 커밋하면 락이 걸려서 안되기도 하고 엄청나게 느린 속도로 되는 경우도 있다.

버그가 좀 있어도 기능이 더 좋다면 이해해 줄 수도 있다. 그러나 실제로 기능을 체감하는 것은 도구를 통해서인데 실질적으로 이클립스의 CVS 플러그인보다 나은 클라이언트를 갖지 못한 Subversion은 기능적으로 더 떨어진다고도 할 수 있다. 그리고 Subversion이 내세우는 장점인 changeset 단위의 revision number도 장점보다는 단점인 것 같다. 실제로 commit은 파일 단위로 일어나는 경우가 훨씬 더 많다. 한 번 생각해보라. commit하는 단위가 하나의 의미적 작업 단위와 일치하는지를. 두 개 이상의 작업 단위를 한 번에 commit하는 경우도 있고 파일에 따라 다른 commit log를 남겨야 해서 한 작업 단위를 여러 번에 나눠서 commit하는 경우도 많을 것이다. 이런 상황에서 changeset 단위 rollback이 큰 의미가 있는 것은 아니다. 어차피 CVS도 시간과 태그로 changeset 단위와 비슷한 개념을 활용할 수 있기 때문에 파일별 revision이 더 나은 것 같다. changeset 때문에 한 저장소에 여러 프로젝트를 관리하기 어렵다는 것도 문제다. revision이 공유되기 때문에 다른 프로젝트의 변경 내용 때문에 내 프로젝트의 revision이 올라가는 현상이 생기는 것이다. 이것 때문에 내 프로젝트의 이전 버전을 찾는데 고생할 때도 있고 export하거나 할 때도 revision이 너무 많아서 오래 걸리는 문제가 있다. 태깅도 좀 문제가 있다. subversion 태깅은 단순 copy라서 더 쉽다고 하는데 그래서 오히려 더 오래 걸리고 무거운 동작이 되버려서 잘 활용 안하는 경향이 있다. 물론 changeset 개념이 있기 때문에 반대로 태깅이 별로 필요 없기도 하지만.

CVS는 오랫동안 많은 사람들이 써왔고 몇 가지 부족함이 있긴 하지만 그 부족함은 대부분 툴로 커버할 수 있다. 그리고 거의 모든 배포판에 기본으로 설치된다. 별다른 이유가 없다면 그냥 CVS 쓰기를 권한다. ClearCase 등 상용 SCM도 좋은 기능을 제공하긴 하지만 실제 사용할 때 CVS보다 월등히 나은 점을 발견하기는 쉽지 않을 것이다. 단순 기능 목록에 현혹되지 말고 자신이 실제로 사용하는 기능에 초점을 맞춰서 도구를 선택해야 한다.

총평#

무수히 많은 신기술을 도입한 프로젝트였지만 불행히도 내 맘에 드는 건 별로 없었다. JavaScript에서 도입한 prototype 정도? 무비판적으로 유행을 쫓은 대가가 아닐까 싶다. 검증되지 않은 것을 도입하지 않는 게 좋다는 말을 하려는 건 아니다. 검증되지 않았으면 스스로 검증해보고 도입해야 한다는 것이다. 오픈마루가 전반적으로 누가 미는 기술이 있으면 별 말 않고 따라가는 경향이 있는데 프로젝트가 혼자 하는 게 아닌 이상 중요한 기술적 결정을 내릴 때는 기술 검토를 충분히 거쳤어야 했다. 그리고 기술적인 이슈에 사용자 가치를 어정쩡하게 개입시키는 것도 경계해야 한다. XHTML이나 REST 같은 것도 사용자 가치를 많이 이야기하지만 실제로 사용자에게 주는 가치는 거의 없다. 그럼에도 불구하고 표준의 논리가 개입되면서 기술적인 단점들을 묻고 지나가곤 한다. 좀더 실용적인 기술 평가가 필요하다.

블로그 / 소프트웨어 개발

Youngrok Pak , 10 years, 11 months ago

성폭력을_어떻게_정의할_것인가

나우누리 SCCR에서 있었던 논쟁으로 인해 교지 관악에서 제의를 받아 기고한 글. 당시 논쟁 상대자의 글도 함께 실렸는데, 논쟁 당시에는 이긴 논쟁이었지만 교지에 올릴 때는 상대자가 훨씬 보강된 논리를 준비해왔었던 기억이. 어쨋든 현재 널리 적용되고 있는 성폭력 관련 법률이나 학칙은 이 당시의 내 논리에 더 가까와져 있다.

최근 몇 년간 학내 여성운동이 결실을 맺어가고 있습니다. 성폭력 학칙 제정에 대한 논의로 성폭력에 대한 인식이 관악 전체에 확산되었고 구체적인 학칙안이 나오고 그게 공식적으로 학칙으로 인정되는 단계에 와 있죠? 그리고 이런 움직임이 다른 대학까지 파급되기에 이르렀습니다. 이런 시점에서 현재 여성 운동에서 '성폭력'이란 것을 어떻게 정의하고 있는지 조금 짚어볼 필요가 있는 것 같습니다. 전 현재 '성폭력 학칙안'이라고 나와있는 것을 비롯해 여성 운동권에서 주장하고 있는 성폭력의 개념에 문제가 있다고 봅니다. 그래서 저 나름대로 성폭력을 새롭게 정의해보고자 합니다. 시작하기에 앞서, 전 이제까지 어떤 종류의 여성 운동에도 참여해본 적이 없기 때문에 여성 운동을 잘못 이해하고 있을 수도 있고 글 중간 중간에 저의 무식함이 많이 드러날 수도 있습니다. 저 자신도 남자인만큼 남성중심적 사고에 빠져 있을 수도 있습니다. 이런 점들 양해해주시기 바랍니다. 그리고, 제 마음대로 몇 가지 용어를 재정의해서 사용할 것에 대해서도 양해를 구합니다.

먼저, 전 제가 생각하는 성폭력을 말하기 전에 자유의 개념을 재정의하고 들어가고자 합니다. 웬 뚱딴지 같이 갑자기 자유냐 하실지도 모르겠지만 이것은 제가 성폭력을 이해하는 사고의 구조에 있어서 대단히 중요한 부분이고, 앞으로 성폭력을 이야기할 때 이러한 자유의 정의를 전제하게 될 겁니다. 먼저 사람의 행동이라는 전체집합을 자유집합과 자유의 여집합, 두 부분으로 나누어봅시다. 자유집합은 말 그대로 여기까지는 '자유'에 해당하는 것이라고 볼 수 있는 것들의 집합이고 자유의 여집합은 '자유'라고 볼 수 없는 행동들의 집합이죠. 따라서, 어떤 행동이 성폭력인지 아닌지를 판단할 때 먼저 그것이 자유집합에 속하는지 자유의 여집합에 속하는지를 보자는 겁니다. 그래서 그것이 자유집합에 속한다면 성폭력이 아닌 것이고 자유의 여집합에 속하면서 성적인 행동이라면 성폭력일 가능성이 높다고 할 수 있겠죠.

그러면 자유는 어떻게 정의할 것이냐. 교과서적 정의에 따르면 자유는 '다른 사람에게 피해를 주지 않는 범위 내에서 자기 마음대로 하는 것'입니다. 저는 초등학교 때부터 그렇게 배워왔습니다. 이 이외의 다른 방식의 정의를 교과서에서 본 적은 없습니다. 그래서, 아마 이 개념을 그대로 받아들이고 있는 사람이 많을 것입니다. '누구 한 사람이라도 불쾌감을 갖는다면 그것은 성폭력이다.'라고 말하는 것도 이러한 사고 방식이 바탕에 깔려 있는 것이라고 할 수 있겠죠.

그러나, 전 이러한 자유의 정의에 이의를 제기하고 싶습니다. 남에게 피해를 준다면 그것은 무조건 자유가 아닌 게 되는 걸까요? 그렇지 않습니다. 남에게 피해를 주게 되더라도 그것은 자유일 수 있습니다. 예를 들어보겠습니다. 서울대의 시설노조 파업. 그것은 많은 서울대생들을 대단히 불편하게 만드는 피해를 주었습니다. 한 명도 아니고 많은 사람에게 상당한 피해를 주었죠. 그러나, 그렇다고해서 시설노조의 행동은 '남에게 피해를 주었으니 이것은 자유가 아니다.'라고 할 수 있을까요? 시설노조의 행동은 자유집합에 속할까요? 자유 여집합에 속할까요? 어떤 벤처기업이 크게 성공하여 원래 그 시장을 점유하고 있던 대기업이 매출에서 큰 손해를 입었다고 합시다. 그러면, 그 벤처기업은 대기업에 손해를 끼쳤으니 잘못한 걸까요? 성폭력과 좀 유사한 예를 봅시다. '요즘 젊은이들'의 옷차림에 불만이 많은 한 할아버지가 길거리에서 머리를 울긋불긋 염색하고 찢어진 청바지에 쫄티를 입은 청소년을 만나서 심한 불쾌감을 느꼈다고 합시다. 그러면 그 청소년은 그 할아버지에게 피해를 입힐지도 모르니까 그러한 차림으로 거리를 나돌아다녀서는 안되는 걸까요?

저런 것들이 자유가 아니라고 말할 수는 없겠죠. 그래서, 저는 자유를 재정의하고 싶습니다. 제가 정의하는 자유는 '이성적인 사회적 합의를 깨뜨리지 않는 범위 내에서 자기 마음대로 하는 것'입니다. 사회적 합의라는 것은 그 합의의 대상자 모두가 직접적이든 암묵적이든 동의를 한 것을 말하는 것이죠. 많은 사람들이 같은 잘못을 저지르고 있는 경우도 많기에 '이성적인'이라는 단서를 붙인 거고, 핵심은 '사회적 합의를 깨뜨리지 않는 것'이죠. 여기서 말하는 사회란 기본적으로 사회 전체를 가리키는 말이기도 하지만, 경우에 따라서 당사자간 관계에서의 합의를 말하는 것일수도 있고 그 둘을 모두 고려한 것일 수도 있습니다. 다만 관습적인 합의를 뜻하는 것은 아닙니다. 관습적인 사회적 합의라도 그것의 합리성이 보장된 경우에만 자유의 판단 근거로 삼을 수 있겠죠.

상당히 애매모하한 듯 하지만 자유라는 것 자체가 명확하게 선을 긋기 힘든, 이런 상호간의 관계를 중심으로 따져야하는 것이 아닌가 생각합니다. 그것이 제가 정의하는 자유입니다. 따라서 '사회적 합의가 이루어져 있고 그 합의의 합리성이 보장된다면 그 행동으로 인해 다른 사람이 피해를 입더라도 그것은 자유다.'라는 것이 제 주장입니다. 앞으로 성폭력에 대한 논의는 모두 이 자유에 대한 정의를 바탕으로 전개될 것입니다.

성폭력에 대한 제 정의를 보기 전에 먼저 여성 운동에서 주장하는 성폭력의 정의로서 '성폭력 학칙안'을 한 번 봅시다. 성폭력 학칙안에 따르면 성폭력은 법률로 정의되는 것을 말하는 거고 대신 성희롱에 대한 항목 중에 '상대방이 동의하지 않는 성적행동과 요구 등 언어적, 정신적, 물리적인 행위를 통하여 개인의 성적 자율권을 침해하는 행위'라고 되어 있습니다. 학칙안에서 지칭하는 법률이 어떤 내용인지는 잘 모르겠고 처벌 규정을 보면 성희롱과 성폭력을 특별히 분리해놓지 않고 대부분 성희롱이란 표현을 쓰고 있는 것으로 보아 통상적으로 성폭력이라고 말하는 것이 학칙안에서의 성폭력과 성희롱을 포괄하는 개념이라고 봐도 될 듯 합니다. 성적 자율권이 침해된다는 것은 자신이 하고 싶지 않는 성적 행동을 당하거나 하도록 강요받는다는 것이죠. 그러므로 저 정의대로라면 '피해자가 불쾌감을 느끼게 만드는 성적 행동 및 언어적 정신적 물리적 행위는 성폭력이다.'라고 이해할 수 있겠죠. 이것이 여성 운동에서 말하는 '피해자 중심주의'인 듯 합니다. 즉, 피해자가 불쾌감을 느낀다면 그건 두말할 필요도 없이 성폭력이 되버리는 거죠.

이런 현재의 성폭력 개념은 앞서 제가 정의한 '자유'의 관점에서 볼 때 문제가 많습니다. 앞서 말한 기존의 자유의 정의에서 생기는 것과 비슷한 문제가 발생할 우려가 많죠. 그래서 저는 앞의 자유의 개념을 바탕으로 '이성적인 사회적 합의를 깨뜨리는 성적 행동'을 성폭력으로 정의하자고 제안합니다. 몇 가지 적용 사례를 통해 학칙안 상의 성폭력과 비교해보겠습니다.

사례 1. 여학생들과의 스킨쉽을 아무렇지 않게 생각하는 한 남자 선배가 있었습니다. 이를테면, 어깨동무를 한다든지, 손을 잡는다든지 등의 가벼운 스킨쉽이죠. 그런데, 몇몇 여학생들이 이런 스킨쉽을 불쾌하게 생각했습니다. 이런 종류의 스킨쉽이란 것은 집단에 따라 아무렇지도 않은 경우일 수도 있고, 대단한 수준으로 받아들여질 수도 있는 것입니다. 이 때 남자 선배의 행동은 성폭력일까요?
- 학칙안 상의 정의에 따르면 여자 후배들의 성적 자율권이 침해되었음이 명백하므로 성폭력이 되겠죠? 그러나, 이것을 성폭력이라고 단정하기엔 무리가 있다고 봅니다. 제 정의에 따라 판단해본다면, 먼저 그 남자 선배의 행동에 대한 사회 전체의 '이성적인 사회적 합의'는 성립되어 있지 않습니다. 집단에 따라 다를 수 있으니까요. 따라서 이 문제는 당사자, 그리고 그 주변 사회에서 '이성적인 사회적 합의'가 있는지를 보아야겠죠. 그런데, 이 경우 여자 후배들이 그 남자 선배의 행동에 이의를 제기한 바가 없다면 역시 합의는 존재하지 않으므로 그 선배는 '이성적인 사회적 합의'를 깨뜨렸다고 말할 수 없습니다. 따라서 성폭력이라고 말할 수 없습니다.
사례 2. A(여)와 B(남)가 있는데 둘이 CC라고 합시다. 그런데 아직 서로간의 성적인 접촉은 대단한 수준이 아닙니다. 점차 진전되어가는 단계죠. 그런데, 어느날 B가 술이 많이 취한 상태에서 갑자기 A에게 이제까지의 발전 속도를 넘어서는 성적 접촉을 시도했습니다. A는 '이거 다음엔 이거일 꺼다'라고 생각하고 있었는데 갑작스런 기습으로 상당한 불쾌감을 느꼈고 그 남자 친구에게 실망해서 다음날 아침 성폭력 위원회에 제소했습니다. 이 경우 어떻게 판단해야할까요?
- 이 경우도 학칙안 상의 정의에 따르면 A가 성적 자율권을 침해당한 것이 명백하므로 B는 성폭력을 저지른 것이 되겠죠. 그러나 이것이 합리적인 판단일까요? 저의 정의에 따르면 이것 역시 '이성적인 사회적 합의'가 도출되지 않은 상태이므로 B의 행동이 자유집합에 속하는지 자유여집합에 속하는지 판단할 수 없기 때문에 성폭력이라고 할 수 없습니다. 그러나, 만약 A가 분명한 거부 의사를 밝혔는데도 B가 그 행동을 멈추지 않았다면 어떨까요? 이 때는 B의 행동은 상호간의 합의를 깨뜨린 것이 명백합니다. 따라서 이 경우는 성폭력으로 처벌대상이 되어야합니다. A가 이런 거부 의사를 전달하지 않았다면 B의 행동은 비록 A의 성적 자율권을 침해했더라도 성폭력이라고 단정할 수 없습니다.
사례 3. A는 아주 유머가 풍부한 사람으로 종종 주변 사람을 웃기는 재주가 있습니다. 그리고 그의 유머에는 늘 성적인 비유가 포함되곤 하는데 대부분의 여성들도 그 유머에 별다른 이의를 제기하지 않고 폭소를 터트렸고요. 그런데 어느 날, B라는 여자가 거기에 기분이 상했고 그래서 바로 성폭력으로 제소했습니다. 어떻게 판단해야할까요?
- 전 이것 역시 앞의 두 경와 마찬가지의 결론을 내리고 싶습니다. 어떤 방식으로든 이의 제기가 있어야합니다. 만약에 단지 A가 B에게 불쾌감을 주었기 때문에 그것이 성폭력으로 규정되어버린다면, A는 성적인 비유를 사용하는 농담은 전혀 하지 못하게 됩니다. '성적인 비유를 사용하는 것' 자체가 성폭력이라는 말도 들은 바 있는데 남녀 모두 같이 공감하는데도 단지 성적인 비유를 사용했다는 이유로 성폭력으로 규정되어버린다면 그것이야말로 정말 불합리한 일입니다.

여기까지만 본다면 이런 반론이 있을 수 있겠죠. '그렇다면 어떤 행동이든지 먼저 일단 해버리면 그 상황에서 합의가 되어 있지 않으니까 처벌할 수 없으니 일단 저질러놓고 보면 되지 않느냐.'하고요. 그런 점에 대해서는 다음과 같은 사례를 제시하겠습니다.

사례 4. 어떤 술 취한 남자가 지나가던 여자에게 성추행을 했습니다. 이건 학칙안 상의 기준으로 분명한 성폭력입니다. 제가 정의한 기준으로는 어떨까요? 이런 행동은 이미 사회 전체에 성폭력이 맞다는 '이성적인 사회적 합의'가 이루어져 있다고 할 수 있습니다. 따라서 성폭력이 맞습니다. 사례 5. 종종 해방터 자보에 성폭력 가해자의 사과문이 공개되곤 하는데 보통 사건 유형이 비슷하더군요. 남녀 모두 술에 취한 상태에서 한 방에서 밤을 보내다가 남자가 성충동을 이기지 못해 성추행을 저지르는 식이죠. 일단 이런 경우는 그 행동의 정도와 두 사람의 관계에 따라서 성폭력일수도 있고 아닐 수도 있습니다만 피해자측이 거부 의사를 표현할 수 없는 상황이라는 점에서 '이성적인 사회적 합의'를 도출할 가능성이 아예 차단되어 있으므로 성폭력이라고 하는 것이 옳겠죠.

결국 제가 말하고 싶은 것은 상호간의 합의가 깨졌느냐 아니냐가 그 행동이 성폭력인지 아닌지를 결정하는데 가장 중요하다는 것입니다. 그리고 그 판단에는 피해자의 사전 '가부 의사 표시'가 대단히 중요하며 표시할 수 있는 상황임에도 하지 않았다면 그 행동은 피해자에게 불쾌감을 주었더라도 성폭력으로 규정될 수 없습니다. 이에 반해 '피해자 중심주의'적 시각에서는 '동의 의사 표시'가 기준이 됩니다. 즉, 합의가 먼저 보장된 행동, 즉 자유집합에 속하는 것이 명백한 행동만 가능하다는 결론이 나오겠죠. 제가 굳이 자유를 재정의하고 여러 가지 사례를 제시한 이유는 이러한 '피해자 중심주의'가 잘못이라고 주장하기 위해서입니다.

현실적으로 '동의 의사 표시'를 사전 합의의 기준으로 삼는 것은 문제가 많습니다. 매번 '나 키스해도 되'하고 물어보고 키스할 수는 없는 노릇이죠. 따라서 '거부 의사 표시'를 기준으로 삽는 것이 훨씬 합리적일 것입니다. 거부 의사 표시야말로 합의가 깨어졌음을 명백히 증명할 수 있는 것이니까요. 법적으로도 강간과 화간을 구분하는 가장 중요한 차이는 피해자의 저항 정도라고 알고 있습니다. 그것이 현실적으로 피해자의 입장을 무시하게 될 위험성이 많음에도 불구하고 법적인 판단 근거로 삼을 수 밖에 없는 이유도 그나마 이것이 더 합리적이기 때문입니다. 따라서 서로간에 충분한 합의가 도출되지 않은 상황에서의 선을 넘는 행위는 성폭력으로 규정하여 처벌할 수 없고, 합의가 깨어진 게 명백한 상황, 혹은 합의가 도출될 가능성이 차단된 상황에서만 성폭력이라고 규정할 수 있다고 봅니다.

속칭 연애박사들의 연애론을 들어보면 이런 얘기를 많이 합니다. '여자의 거부의 표현에서 그것이 진짜로 거부하는 표현인지 표현만 그렇고 마음은 동의하고 있는지를 잘 판단하라.' 불행히도 많은 남자들은 이런 판단 능력이 많이 부족합니다. 그래서, 본의 아니게 상대방에게 불쾌감을 주게 되는 경우가 생기는데, 이런 경우 여자의 입장에서도 상대방에게 자신의 의사가 진짜 거부라는 것이 전달되도록 충분한 의사 표시를 할 필요가 있다고 봅니다. 이것이 정말 피해자에게 책임을 전가하는 것일까요?

무엇보다도 '조금이라도 불쾌감을 느낀다면 그것은 성폭력이다.'라는 시각에서 벗어나는 것이 중요하다고 생각합니다. '조금이라도 불쾌감을 느낀다면'하는 생각이 피해자 중심적인 사고인 것처럼 보이지만 사실은 피해자만(!)을 고려하는 사고입니다. 당시의 상황이 어떤지, 당사자가 어떤 관계인지를 도외시한 채 성폭력을 일방적으로 규정해서 가해자를 처벌하는 일은 가해자를 또다른 '피해자'로 만드는 일입니다.

블로그

Youngrok Pak , 10 years, 11 months ago

밝은_곳에서_동전_찾는_오류

어린 아이가 어두운 골목에서 동전을 잃어버렸다. 근데 이 아이는 골목에서 나와서 밝은 큰 길에서 동전을 찾고 있다.

지나가던 이 얘야, 뭘 잃어버렸니?
아이 동전이요.
지나가던 이 어디서 잃어버렸는데?
아이 저기 어두운 골목에서요.
지나가던 이 -_-;;; 근데 왜 여기서 찾고 있니?
아이 거긴 잘 안 보이잖아요.

유명한 이야기이지만 많은 사람들이 잊고 있는 이야기다. 이 이야기를 통해서 말하고 싶어하는 것은 사람들이 관리해야 하는 것을 관리하지 않고 관리할 수 있는 것을 관리하려 한다는 것이다. 이건 사실 아주 많은 회사에서 나타나는 현상이다. KPI 같은 걸 잡을 때도 정말 측정해야 하는 중요한 지수를 측정하는 것이 아니라 그냥 측정할 수 있는 것 중 아무 거나 찝어서 측정하고는 그걸로 성과를 잰다. 프로젝트 관리도 마찬가지다. 정작 중요한 고객에게 가치를 전하고 있는지는 전혀 측정하지 않고 쉽게 측정할 수 있는 일정이라든지, Man Month따위나 측정한다. 실제 이런 수치와 성공과의 상관 관계는 거의 없는대도 말이다.

블로그

Youngrok Pak , 10 years, 11 months ago

머리를_쉬게_하자

머리에 너무 생각이 많이 차서 CPU 사용율이 100%에 달했다고 느낄 때가 있다. 그러면 버벅거리면서 응답 속도가 느려지고 효율이 떨어진다. 다시 CPU 사용율을 떨어뜨려야 한다. 생각할 꺼리가 쌓여 있을 땐 의식적으로 머리를 비우려고 해도 좀처럼 CPU 사용율이 떨어지지 않는다. 한 태스크를 강제 종료 해도 다른 태스크가 금방 CPU를 차지한다. 이럴 때 좋은 방법은 IO bound job을 실행하는 것이다. IO bound job을 실행하면 IO의 속도가 CPU의 속도보다 훨씬 늦기 때문에 그 속도 차이만큼 CPU가 쉴 수 있다. IO bound job은 대화일 수도 있고 무언가 단순하지만 약간 머리를 써야 하는 일, 혹은 산책도 될 수 있다. 대화도 분명 CPU를 많이 쓰지만 생각의 속도는 말의 속도보다 훨씬 빠르기 때문에 똑같은 태스크라도 대화를 하면 CPU 사용율이 좀 내려 간다. 운동도 확실하게 CPU 사용율을 떨어뜨리는 방법이다. 운동의 종류에 따라 다르지만 운동은 그 자체가 CPU를 어느 정도는 사용하지만 높은 점유율을 필요로 하진 않는다. 인간의 대뇌는 싱글 태스킹 밖에 안되기 때문에(내부적으로 멀티 쓰레드라 하더라도) 운동처럼 IO가 많으면 다른 생각은 하기 어렵다. 그래서 운동 태스크에만 CPU를 쓰게 되고 운동 태스크는 IO bound기 때문에 CPU가 쉬는 것이다. 마찬가지로 설겆이도 이렇게 보면 그렇게 시간 낭비로 느껴지지 않을 것이다. 오히려 마음이 편안해지는 느낌도 받을 수 있다.

산책은 좀 특별하다. 산책할 때는 선택이 가능하다. 산책하면서 다른 생각을 하는 건 그다지 어렵지 않다. 운동의 강도가 높지 않고 워낙 자연스럽게 하는 동작이라서 그런 것 같다. 그래서 딱히 IO bound가 되는 것 같진 않지만 산책이라는 행위 자체가 CPU를 오버클럭하는 효과가 있다. 그래서 throughput은 유지하면서 CPU 사용율을 떨어뜨릴 수 있다.

또, 산책을 할 때는 눈앞의 풍경이 바뀌기 때문에 다른 생각을 몰아 내기가 비교적 쉽다. 사람은 CPU 자원을 [시간당 흥미의 밀도]에 따라 할당한다. 그런데 시각적인 자극은 그냥 생각만 하는 것에 비해 [시간당 흥미의 밀도]가 높다. 그래서 대기 중인 생각에 CPU를 빼앗기지 않고 쉴 수 있다. 이 두 가지가 내가 산책을 그토록 중요하게 생각하는 이유다.

그런 면에서 휴식이 가만히 앉아서 쉬는 것이 되어서는 곤란하다. 대기 중인 생각이 많다면 가만히 앉아서 쉬어 봤자 금방 CPU가 잠식 당하고 원하는 휴식은 이루어지지 않는다. 실상 지식 노동자에게 필요한 휴식은 육체적 휴식이 아니라 뇌의 휴식이다. 휴식 시간에는 무조건 돌아다녀야 한다.

좌뇌와 우뇌를 번갈아 가면서 사용하는 것도 좋은 방법이다. 대화는 아마도 우뇌를 많이 사용하기 때문에 좌뇌의 사용율이 떨어지는 것이리라. IO bound job이란 것도 결국 뇌의 다른 부분을 사용하는 것이다. 고등학교 때 공부할 때도 이런 전력이 꽤 효과가 있었다. 공부 시간표를 수학 물리 화학 국어 영어 이런 식으로 잡는 것보다는 수학 국어 물리 영어 화학 이런 식으로 섞어주는 것이 훨씬 집중력이 오래 가고 효과가 있다. 아마도 뇌가 부분적으로나마 쉴 시간을 가질 수 있기 때문일 것이다.

그렇지만 사실 인생을 그렇게 빡빡하게 살 필요는 없다. 굳이 뇌의 최대 효율을 발휘하려고 애쓰기보다 그냥 제대로 쉴 수 있는 방법을 하나 쯤 갖는 것으로도 충분할 것이다. 나에게는 그것이 산책이다.

블로그

Youngrok Pak , 10 years, 11 months ago

대안언어축제2006후기

자원봉사자의 부담#

대안언어축제 2006이 끝났다. 사실 준비하면서 정말 힘들었었고 중간에 때려 치고 싶은 생각이 수도 없이 들었었다. 앞으로 두 번 다시 이런 건 안하겠노라는 생각도 했었다. 하지만 정작 행사가 끝나고 나니 힘들었던 기억은 흐릿해지고 뿌듯함이 남는다. 이것이 내가 찾았던 자원봉사의 모티브일까? 아니, 그렇다고 하기엔 부족하다. 작년 대안언어축제의 자원봉사자들도 축제가 끝나고 나서 이런 뿌듯함을 느꼈을 것이고 좋은 경험이라는 이야기도 했었다. 그런데 왜 작년 자원봉사자들은 단 한 명도 이번에 자원봉사로 나서지 않았는가. 왜 하나같이 올해는 일반 참가자로 참가해보고 싶었다고 하는가? 이번 대안언어축제를 준비하면서 내가 저지른 가장 큰 잘못은 이 점을 처음부터 깊이 생각해보지 않았다는 것이다. 처음부터 이 문제를 고민해보았다면 절대 이렇게 진행하지 않았을 것이다. 나름 좋은 분위기로 끝난 축제에 찬물을 끼얹는 것 같지만 대안언어축제의 성공은 자봉들의 희생을 발판으로 삼고 있다.

자봉들이 희생하게 되는 것는 크게 세 가지로 볼 수 있다. 하나는 관심. 직장인들은 기본적으로 회사일이 우선일 수 밖에 없고 회사일 외의 문제에 많은 관심을 쏟기가 어렵다. 자봉 회의에서 결정된 내용들은 대개 근무시간에 해야 하는 일들인데 근무 시간에 대안언어축제에 관한 일을 하기는 쉽지 않다. 나는 그나마 우리 팀이 후원하는 일이라 어느 정도는 업무로 인정 받을 수 있는 일이었음에도 불구하고 근무 시간에 대안언어축제에 관련된 연락을 돌리고 하는 일들이 마음 편한 일이 아니었다.

다른 하나는 축제의 준비에 잡일이 많다는 것. 준비과정의 절반 이상이 별로 즐겁지 않은 사소한 잡일들로 채워져 있었다. 메일 한 통 쓰는 것조차도 간단한 일 같지만 잘 모르는 사람에게 메일 보낸다는 것이 그리 간단한 일은 아니다. 서론도 좀 집어 넣어야 하고 문구도 다듬어야 하고 답장도 확인해야 한다. 전화는 그런 종류의 부담은 적지만 안 받는 경우 기억했다가 나중에 다시 걸어야 하는 경우도 많고 전화번호 찾기 힘든 경우도 많아 역시 부담이다. 이런 일들을 즐겁게 해내려면 어떻게 해야 할까? 이건 아직도 답을 발견하지 못했다.

마지막으로 행사 당일. 일이 몰리기 때문에 축제를 즐길 수가 없다는 것. 왜 일부러 발표자들이 자봉을 위한 자리까지 만들어줬는데 자봉들은 오지 못하는가. 왜 밤에 술자리를 하는데도 내일 일 걱정을 해야 하는가.

희생이라는 표현에 거부감을 느끼는 사람이 있을지도 모르겠다. 자기가 좋아서 자원한 일인데 무슨 희생이냐고 할지도 모르겠다. 하지만 대안언어축제를 잘되게 하는데 자원하고 싶었던 사람은 있을지 몰라도 행사 당일 하루 4시간도 제대로 못 자면서 혹사당하고 싶었던 사람은 없을 것이다. 행사 준비에 참여하고 싶었던 사람은 많겠지만 매주 월요일을 고정 약속으로 정하고 싶었던 사람도 별로 없었을 것이다. ExtremeProgrammingExplained2ndEdition의 이야기를 끌어온다면 MutualBenefit이 잘 되지 않았다고 할 수 있을 것이다.

이 문제를 어떻게 풀 수 있을까? 내가 이 문제를 깨달은 것은 4주 전이다. 학생 자봉이 참가하면서 일의 진행이 빨라지는 것을 보면서, 그리고 작년 자봉이 왜 아무도 다시 참여하지 않았을까를 고민해보면서 무언가 느끼는 것이 있었다. 그 때부터 고민하면서 행사가 1주일 남았을 때쯤 잠정적인 결론을 내릴 수가 있었지만 이런 저런 제약조건들로 이번 행사에는 그 고민을 반영할 수 없었다. 이것이 내가 다음 대안언어축제의 스타트업에 참여하려는 이유이다. 자봉들이 희생하는 것을 당연한 것으로 여겨서는 안된다.

어쨋든 내가 내린 해답은 이런 것이다. 학생, 자봉, 발표자의 구분이 없는, 모든 참가자가 자봉이고 발표자인 그런 축제를 만드는 것이다. 생각해보면 자봉이 했던 일 중에 참가자가 직접 하면 안될 일은 아무 것도 없었다. 신뢰라는 전제조건에 모두 합의하기만 한다면 말이다. 이미 대안언어축제에 오는 사람들은 자발성이 높은 사람들이다. 책상 옮기고 의자 옮기는 건 다 참가자들이 직접 하는데 과일 씻는 거라고 못할 이유가 있을까? 마이크 고장나면 굳이 자봉이 뛰어가야 할 이유가 있을까? 스티커를 자봉이 지켜야 하는 것은 스티커 나눠주는 룰을 자봉이 정했기 때문이다. 참가자 모두가 함께 정한 룰이라면 그냥 어딘가에 놔두고 자유롭게 가져가도록 해도 룰을 어기지 않을 것이다. 신뢰는 신뢰할 수 있는 상황이 되어야 생기는 것이기도 하지만 또한 신뢰해야 신뢰할 수 있는 상황이 되는 것이기도 하다. 사실 현재의 대안언어축제만 해도 다른 컨퍼런스에 비하면 참가자들에 대한 아주 높은 신뢰를 기반으로 하고 있다. 하지만 우린 더 나아갈 수 있다.

물론 이상적인 이야기로 들릴 수도 있을 것이다. 하지만 위키가 바로 그런 이상적인 상황을 현실에서 보여주고 있지 않은가. CollectiveIntelligence, 바로 대안언어축제에 필요한 것이다. 축제 시작 6개월 전부터 메일링 리스트를 개설하고 메일링 참가자들이 모두 참가자 및 자봉이 된다면 충분히 가능할 것이다. 행사에 카메라가 필요하면 메일링에서 카메라 가져올 사람을 모집하면 된다. 장소 답사를 가야 한다면 메일링에서 답사 갈 사람을 모집하면 된다. 무슨 일을 해야 할지는 무슨 일을 해야 할까요?라는 메일 한 통에서 시작할 수 있을 것이다. 그러다가 한 달에 한 번쯤 오프라인 모임을 갖는다. 아이디어들을 실험해보기도 하고 머리를 맞대고 브레인스토밍도 한다. 물론 몇몇 사람은 facilitator 역할을 할 필요가 있을 것이다. 하지만 그 사람들이 희생하지는 않아도 될 것이다. 행사 당일에도 참가자 각자가 자신의 필요를 해결할 수 있다면, 먹거리는 알아서 챙겨 오고, 멀티탭 모자라면 알아서 사무실 가서 빌려오고 없으면 사오고, 시간 되면 알아서 모이고 세션 장소 알아서 찾아가고 한다면 자봉은 따로 필요 없다.

정말 내 생각처럼 이렇게 잘 될지는 아직 모르겠다. 그래서 다음 대안언어축제의 스타트업에는 꼭 참여해서 이렇게 끌고 가보고 싶고 만약 그렇게 된다면 스타트업 뿐 아니라 끝까지 참여할 것이다.

리더십#

이번 축제에서 또 하나 느낀 것은 리더의 역할에 대한 것이다. 난 원래 일반적인 관리자의 역할을 좋아하지 않는다. 일 챙겨서 사람들에게 분배하고 확인하고 그런 매니저의 역할이 필요한가에 늘 의문을 갖고 있었다. 그래서 이번에 대자봉을 맡았지만 관리는 하지 않으려고 했다. 그저 facilitator 역할만 하고 그 외에는 다른 자봉과 같이 해왔다. 막판에는 일이 좀 몰리면서 어쩌다보니 관리하는 형국이 된 경우가 몇 가지 있지만 대체로 이번 대안언어축제는 대자봉 한 사람의 지휘 하에 자봉들이 일사불란하게 움직이는 그런 모습과는 거리가 멀었다. 그보다 자봉 각자가 셀프 리더십을 갖고 움직였다. 특히 행사 당일에는 정말 신기할 정도였다. 처음에는 다들 우왕좌왕하면서 일 분담도 제대로 되지 않고 그랬는데 특별히 내가 뭔가 조치를 취한 것도 아닌데 시간이 좀 지나면서 다들 자기 할 일을 잘 찾아서 했고 일정이 제대로 굴러가기 시작했다. 자봉들 소감 발표하는 시간에 과일 씼었다는 이야기를 들으면서 그걸 깨달았다. 난 과일을 씼어야 한다는 사실조차 깨닫지 못하고 있었는데 이미 알아서 다 하고 있었던 것이다. 그걸 깨닫고 생각해보니 정말 내가 신경쓰지도 않았던 일들이 다 잘 되고 있었다.

어쩌면 이건 챙겨야 할 일을 챙기지 못한 대자봉의 변명일지도 모른다. 사실 그래서 MS와의 커뮤니케이션도 구멍이 나서 MS 스폰서도, C# 발표도 제대로 안되었고 좀 안타까웠었다. 하지만 과연 내가 다 챙길 수 있긴 했을까? 원래 이런 일을 골고루 다 챙길 수 있는 역량을 가질 사람만이 리더를 할 수 있는 걸까? 이런 질문들을 던져보면 내가 선택한 방향 자체는 옳았다는 생각이 든다.

스티커#

이번 행사 최고의 아이디어는 단연 스티커다. 여기에 이의를 제기할 사람은 아무도 없을 것 같다. [뿌듯 이펙트]를 통해 막강한 언어교환의 어포던스를 제공한 것 같다. 이 아이디어도 누구 한 사람의 아이디어로 이루어진 것이 아니다. 원래 발의는 김창준씨의 팔찌에서 시작해서 포도송이, 티셔츠, 띠 등의 아이디어로 이어졌다가 몇 번의 프로토타입을 거쳐 이름표로 결정되었다. 붙이는 모양도 여러 가지로 하다가 빙고 아이디어가 나와서 정사각형 배열로 하고 또 단순히 글자만 쓰면 재미 없다고 이왕 붙이는 거 해당 언어의 로고를 붙이자는 아이디어가 나왔다. 거기에 이름표 밑판을 흑백으로, 스티커를 칼라로 찍자는 의견이 채택되었다. 채택된 후 실행 과정에서도 여러 사람이 로고를 찾고 디자인했다. 이번 행사 준비 과정 중 가장 많은 사람들이 참여했고 가장 활발하고 즐겁게 준비한 것이고 그만큼 효과도 좋았던 것 같다. 스티커가 넘 맘에 들어서 세트별로 한 30장씩 챙겨왔다. 나눠줘야지.

세션#

대안언어축제 2006의 공식 세션은 16개, 자바 컨퍼런스에서 하루에 하는 세션 수랑 같은 수를 2박 3일간 소화한다. 세션만 놓고 보면 대안언어축제의 진가를 알 수 없다. 중요한 것은 참가자들간의 커뮤니케이션이다. 다행히도 대안언어축제의 참가자들은 대부분 이것을 알고 있었고 그것이 이번 축제를 성공으로 평가할 수 있는 이유일 것이다. 이 점에서 본다면 사실 세션은 더 줄여야 할지도 모른다. 아니, 아예 없애는 게 바람직할지도 모르겠다. 많은 사람들이 세션을 들었는데도 뭘 배웠는지 모르겠다는 소감을 토로했다. 튜토리얼이 아무리 친절하게 준비된다고 해도 모든 사람의 학습 속도를 맞출 수는 없다. 그러다보니 어떤 사람들에게는 지루하고 어떤 사람들에게는 따라가기 힘들게 된다. 그런 면에서 맨투맨 언어교환은 위력적이다. 궁금한 걸 바로 물어볼 수 있고 가르치는 사람도 더 잘 배울 수 있다. 나도 간만에 파이썬을 가르치는 쪽으로 언어교환을 했는데 파이썬은 제대로 알지도 못하면서 가르쳤는데도 그 과정 중에 많이 배운 것 같다. BOF도 세션 형태로 하는 것보다는 OST로 하는 것이 더 나은 것 같다. 세션과 BOF를 줄이고 OST와 언어교환을 늘리는 것이 더 나았을 것 같다.

물론 그래도 씨앗이 될 만한 무언가는 필요하다. 전혀 배경지식이 없는 사람들이 언어교환을 잘할 가능성은 별로 높지 않다. 하지만 그 씨앗이 꼭 세션이어야 할 필요는 없을 것 같다. 사람 그 자체가 씨앗이 될 수 있다. 그런 면에서 이번에 통사라는 역할이 좀더 드러날 필요가 있는 것 같다. 20명의 발표자와 각각의 세션보다 40명의 통사가 더 좋은 씨앗이 될 수 있을 것이다.

인간#

믿어야 하는 것은 기계가 아니라 인간이라는 것을 다시 한 번 느꼈다.

자봉#

자봉끼리 행사 전에 좀더 친해지는 자리가 필요했다. 원래 계획했던 술자리를 한 번 했었더라면 좋았을 것 같다. 다만, 자봉끼리 너무 친밀하면 새로운 멤버가 자봉으로 참여하기 힘들다는 문제는 있을 것이다.

블로그

Youngrok Pak , 10 years, 11 months ago

스프링노트_기술보고서

Ruby on Rails#

ActiveRecord#

RHTML#

webrick & mongrel#

RSpec on Rails#

루비라는 언어#

Third party#

Eclipse vs TextMate#

bash, ant, perl vs rake#

Naming Convention#

JavaScript#

XHTML, microformat, WYSIWYM#

REST#

CSS#

linux (RHEL vs ubuntu)#

Subversion#

총평#

성폭력을_어떻게_정의할_것인가

밝은_곳에서_동전_찾는_오류

머리를_쉬게_하자

대안언어축제2006후기

자원봉사자의 부담#

리더십#

스티커#

세션#

인간#

자봉#

Comments