어제 친구랑 둘이서 결승전 보려고 장충 체육관엘 갔습니다. 3시 입장인데 2시 반쯤 갔는데 벌써 사람들이 바글바글하더군요. 줄이 쭈욱 서 있는데 그렇게 긴 줄을 기다려본 건 처음인 듯. 8000명 입장인데 우리 뒤에 한 40명 정도 더 들어오고 끊겼음-_-++ 2000명이 입장 못했다던데 어느 정도 사실인 거 같더군요. 사람들이 앉을 자리가 없어서 계단에 앉고 뒤에도 빼곡하게 서서 보더군요. 좀만 늦게 갔더라면 제대로 못 볼 뻔 했음.--+

들어가니까 해설자들끼리 겜한 거 결승전을 오프닝으로 하는데 정일훈이 좀 웃기더군요. 비록 임요환과 홍진호의 경기에 비해 수준은 좀 낮겠지만 재밌게 봐달라는 둥-_- 김도형이 전날 준결승에서 져서 어제 결승전에 못나왔는데 그거 가지고 계속 놀려먹고 나중에 김창선이 캐리어 1부대 나와서 다 밀고 있는데 상대 선수(송 머시긴데 까먹었음)가 커맨드 여기 저기 지으면서 도망다니면서 게기니까 저렇게 버티는 모습은 보기 안좋죠..등-_-;; 좀 심하다 싶을 정도로 깔아뭉개던데 어쨋든 재밌었음.

그리고 그거 끝나고 나서 코크배 온겜넷 스타리그 화제 베스트 3인가 했는데.. 부문별로 베스트 3를 선정한 거였는데, 이번 대회를 거치면서 팬이 가장 많은 비율로 늘어난 선수가 조정현, 홍진호, 임요환 순인데, 임요환은 팬이 4만을 돌파했더군요. 조정현은 팬클럽 없었는데 이번에 생겼는데 4천 돌파..대단.. 엽기 플레이 선정도 했는데 1위에 임요환의 바락 널뛰기가..ㅡ.ㅡ

그 다음 행사로 토크쇼를 했는데 초대손님이 마린과 메딕..-_-;; 열라 유치했지만 간간히 웃긴 대사로 무난히 시간 때움..-_-++ 근데 사실 이거는 없었어야한 행사인 듯. 이거 없이 그냥 4시 입장하고 5시부터 행사 시작, 6시 결승전..하면 좋았을 텐데.

그 외 잡다한 몇 가지 일들이 있고 나서 6시에 결승전 시작. 열라 흥분되더군요. 8천 관중과 함께 본다는 게...진짜 느낌이 색다름. 친구들이랑 모여서 티비 보는거랑 비교가 안될 정도. 게다가 첫 경기부터 환상적인 경기. 둘다 최고의 집중력을 발휘해서 역전에 역전을 거듭하는 경기였습니다. 처음 임요환이 멀티 드랍 실패할 때 홍진호가 첫 게임을 잡고 시작하나..싶은 느낌, 그리고 잠시 후 홍진호가 러커 드랍으로 타격을 꽤 주면서 게임 끝나나 싶었는데 임요환의 주력 부대가 홍진호의 본진에 드랍..--+ 상당한 병력이 있었는데 정말 화려한 컨트롤로 다 잡아내고 본진에 엄청난 피해를 줌. 결국 막아내고 또 홍진호가 임요환에게 타격을 줘서 재역전하나 했는데 다시 임요환의 본진 마무리 드랍..홍진호 본진 청소됨.-_-;; 임요환이 역전승하나..했는데 이후 이런 역전에 역전이 47분간 계속됨.. 정말 누가 이길지 마지막 5분 전까지도 예측하기 힘든 경기였음. 홍진호로서는 정말 아까울 듯.

둘째판은 정글 스토리, 개인적으로 저그가 많이 유리하다고 생각하고 있었는데 홍진호가 의외로 강도경의 전략을 선택하지 않고 자신의 스타일대로 헝그리저그로 출발, 초반 약간 컨트롤 미스가 있었지만 러커로 임요환이 거의 3~4분 이상 자원을 못 캐게 만들고 그 사이 자신은 멀티 띠고.. 여기서 겜 끝나나 싶었는데 임요환이 3마린 1메딕 1탱크 드랍으로 홍진호 본진 드론 다 잡고 자원 채취 방해, 잠시 후 저글링 1.5부대 가량 쏟아부었으나 사베가 와서 디펜시브 한 방 걸고 지형을 절묘하게 활용해서 전멸시키고 잠시 후 멀티까지 언덕 탱크로 교란, 홍진호도 3~4분 이상 자원 못 캠..-_-;; 그 사이 임요환은 몇 차례 러커 다시 막고 병력 모아 러시..여기서 임요환에게 정말 감탄했는데 홍진호 어느 새 복구하고 히럴 모아서 마메탱 막고 가디언으로 앞마당 치고 피니쉬. 역시 감동적인 경기..

셋째판, 네오 레가시 오브 차, 임요환 1바락 더블커맨드, 성공하고 3바락으로 감. 여기서 임요환이 마메로 밀어 붙이면 금방 끝나는 겜이 아닌가 싶었는데 임요환 바락 볼 때마다 불 꺼져 있음-_-;; 웬지 져주는 게 아닌가 싶은 느낌이 들 정도로 임요환 삽질하다가 패배. 임요환이 머쉰의 생산력을 갖춘다면..하는 아쉬움이-_-

넷째판, 기대했던 라그나로크. 홍진호가 자신이 3:1 승리를 예상했다고도 했고 라그나로크가 해볼만하다고 말을 해왔기 때문에 기대를 많이 해왔고 기대대로 허를 찌르는 언덕 아래 성큰 러쉬-_- 성공은 했는데 의외로 언덕 위 공격 시 확률 감소가 커서 scv 몇 마리 잡지도 못하고 잠시 후 탱크 나와서 그거 밀리고 모았던 마린메딕파벳 러시, 멋진 저글링 버로우로 상당한 타격을 입으나 파벳이 워낙 많아서 거의 파벳 러시로 피니쉬..

다섯째판, 홍진호의 허접한 뮤탈 컨트롤이 돋보였던 게임-_-;; 아마 그 뮤탈을 내가 컨트롤했더라면 손쉬운 승리를 하지 않았을까..싶을 정도로 유리한 시점을 다 놓쳐버리고 임요환의 테크니칼한 드랍쉽 교차 드랍?에 털려 겜셋..싱거웠음.

막판이 싱거워서 좀 아쉬웠지만 정말 흥분되고 감동적인 결승전이었습니다. 마지막에 시상식까지 보고 왔는데, 가까이서 보니까 임요환 진짜 잘생겼더군요. 키도 크고 정말 외모에서는 흠잡을 데가 없을 정도. 장진남도 가까이서 보고 조정현도 보고 했는데 다들 잘생겼더군요. 홍진호는 겜 끝나고 울었다던데-_- 정말 눈물 나올만한 상황이었던 듯-_-

아뭏든 정말 재밌었습니다. 담에도 이런 기회가 있으면 한 번 가서 보면 정말 좋을 듯. 여자친구가 스타 좋아하면 같이 가서 봐도 좋을 꺼 같고..--+

스타크래프트분류 / 블로그

정석이라는 말은 수학의 정석이 흐려놓은 개념과는 달리 원래 바둑에서는 상당히 높은 유연성을 함축하고 있는 말이다. 수학의 정석에서는 문제를 푸는 최선의 방법 하나를 이야기하는 것이지만 바둑에서 정석은 정석 사전이 있을 만큼 다양하다. 정석은 귀에서의 수순을 이야기하는 것이지만 실상 실전에서 귀에서 같은 상황이 나왔다고 같은 정석을 써야 한다는 것은 아니다. 이웃한 다른 귀, 심지어 대각선 건너의 귀의 배석에 따라서도 정석 선택이 바뀐다. 그래서 사실 정석은 상황에 따라 선택해야 하는 것이다. 그렇다고 정석 중에만 선택하는 것도 아니다. 때때로 선수를 뽑기 위해 손해를 감수해야 할 때도 있고 여러 가지로 정석과 다른 수순을 밟아야 할 때가 많다. 그래서 정석은 배우고 잊어버려라라는 말이 있는 것이다.

블로그

창업하고 나서 GUI 프로그래밍을 많이 하게 된다. 원래 하던 웹에 더해서 플래시에 아이폰에 안드로이드까지. 그러면서 개발자들의 실력 차이가 정말 크게 드러나는 분야가 GUI라는 생각이 들곤 한다. 실력차가 크게 드러나는 이유 중 하나는 OOP다. GUI 프로그래밍은 OOP를 모른다면 제대로 돌아가게 만드는 것조차 힘든 분야다. 겉으로는 얼추 돌아가는 것처럼 보여도 버그가 산재해 있는 경우도 많다. 코드의 양도 엄청난 차이가 난다. 내가 본 경우에도 OOP를 아는 사람과 모르는 사람의 코드 라인수가 10배 가까이 차이가 나는 것을 본 적이 있다. 생산성의 차이는 그보다 더 컸으리라 짐작된다. 사실 난 개발이란 분야에서 전문가와 초보자간 생산성 차이가 최대 40배까지 난다는 이야기를 처음 들었을 때는 믿을 수가 없었다. 에이, 아무리 그래도 설마. 하지만 몇 차례의 경험 이후 조금 믿게 되었다.

이를테면 이런 식이다. 초보자에게만 개발을 맡기면 처음에 기능의 개수가 적고 단순할 때는 그럭저럭 생산성을 낸다. 전문가만큼은 아니라도 전문가 절반만큼은 되는 것도 같다. 그런데 시간이 지나면서 점점 생산성이 떨어지고 어느 순간 생산성이 0이 되는 순간을 맞이한다. 더욱 놀라운 것은 그 시점을 지나면 마이너스로 내려가기도 한다는 것이다. 되던 기능을 망가뜨리고, 다른 사람이 코드를 건드리는 것 자체를 불가능하게 만들어버린다. 결국 그 사람이 만든 소스 코드를 폐기하게 되면 마이너스의 크기는 더 극적으로 변한다. 이 단계에 이르면 생산성 차이는 40배 정도가 아닐 것이다.

써놓고 보니 굉장히 익숙한 이야기다. 개발자들이 자주 하는 푸념 아니던가? 코드에 더 이상 손을 댈 수가 없어. 다시 짜는 것 말고는 답이 없어. 이런 일이 자신(혹은 팀)에게도 자주 일어난다면 왜 자신의 실력이 발전하지 않는지 고민해야 한다.

그렇지만 그래도 대부분의 프로그래머들은 그럭저럭 헤쳐 나간다. 시스템의 복잡도가 늘 엄청나게 큰 것은 아니기 때문이다. 시스템 프로그래밍이 어렵다 어렵다 하지만 중요한 알고리즘 문제는 이미 다 해결되어 있기 때문에 공학적인 복잡도는 별로 높지 않다. 엔터프라이즈 쪽도 비즈니스 로직의 복잡도는 대부분 RDBMS가 커버하며, 아키텍처도 결국 요청을 받아서 응답을 내주는 것으로 어느 정도 단순화되어 있다. 하지만 GUI는 알고리즘 하나 잘 짠다고 해결되는 것도 아니고, RDBMS가 쿼리 로직을 다 감당해주는 것도 아니다. 거기에 사용자 인터액션이 다양하게 들어온다. 엔터프라이즈는 보통 stateless가 많고, 설령 기능적으로 stateful하다고 하더라도 거시적인 비즈니스 로직 관점에서만 stateful하다. 하지만 GUI는 비즈니스로직 뿐 아니라 화면에 뿌려지는 모든 컴포넌트가 다 stateful하다. 엔터프라이즈에서 stateful이 될 때 stateless보다 얼마나 복잡해지는지를 생각해보면 GUI가 얼마나 복잡할지 상상할 수 있을 것이다.

이것이 아마 제대로 동작하는 GUI 애플리케이션이 드물고, 또 그래서 몇 안되는 GUI 애플리케이션이 시장을 다 잡고 있는 이유일 것이다. 해당 분야에서 시장을 지배하지 못하는 애플리케이션은 기능도 기능이지만 대체로 제대로 동작하지 않는 상황을 흔하게 접한다. 프로그램 쓰다가 아니 이 기능도 얼마 안되는 프로그램이 왜 이렇게 느린거야하는 생각이 든 적 없는가? 아이폰은 저렇게 플릭이 매끄러운데 왜 옴니아는 손가락을 고문하는가? 도대체 MSN 메신저 live는 왜 이렇게 느린 거야. 어떻게 더 intelligent한 IDEA는 메모리 60메가 먹고 있는데 이클립스는 왜 600메가씩 먹고도 느린 거야. 왜 Anycall PC manager는 자꾸 에러를 띄우는 것인가. 왜 우리투자증권의 머그는 띄우는데 5분씩 걸리고 창도 안 닫아지는 거야. 왜 오픈오피스는 느려터진데다가 자꾸 죽는 거야.

GUI 개발이 쉬운 일이라면 이렇게 되지는 않았을 것이다.

그럼 어떻게 하면 GUI 개발을 좀더 잘할 수 있을까? 뭐 개발을 잘하는 방법에는 여러 가지 도가 있겠지만 오늘은 OOP에 초점을 맞춰보자. GUI 개발은 OOP가 없이는 불가능하다. 비 OOP 언어로 개발된 Gtk조차도 OOP적인 개념을 차용하고 있다. OOP에도 여러 가지 특성이 있겠지만 GUI 개발에서 특히 중요한 요소는 다형성이다. GUI에서 다형성이 중요한 이유는 뭘까. 간단한 예를 들어보자. 탐색기에서 파일을 선택하고 Ctrl-C를 누르면 파일이 클립보드로 복사된다. 반면, 웹브라우저에서 텍스트를 긁어서 Ctrl-C를 누르면 텍스트가 복사된다. 이건 어떻게 구현할까? 다음처럼 짜면 어떨까?

function copy(source) {
  if (source is file) {
     copy_file_to_clipboard()
  } else if {source is text) {
     copy_text_to_clipboard()
  }
}

돌아가는데는 문제가 없다. 그런데 이미지도 복사하고 싶으면 어떻게 될까? 저기에 else if가 한 줄 추가되어야 할 것이다. 복사하려는 객체의 종류가 늘어날 때마다 copy함수도 같이 늘어난다. copy만 있으면 뭐 그것만 고치면 되겠지. 그런데, 윈도우 시스템을 다 인스톨해놨는데 고칠 수는 없다. 누군가 새로운 종류의 객체를 copy&paste 가능하게 만들고 싶어도 할 수가 없는 것이다. 설령 고칠 수 있다 하더라도 문제는 남는다. paste는 어떻게 할 것인가? paste에도 똑같은 if else가 들어가야 할 것이다.

OOP에서는 이렇게 해결한다.

function copy(source) {
   source.copyTo(clipboard)
}

즉, 각 객체의 copy 동작은 각 객체에 위임하는 것이다. 다형성은 이런 식으로 if문을 제거한다.

이건 너무 전형적인 예라고 생각하는가? 그렇다면 이건 어떨까. 메일 클라이언트를 만든다고 해보자. 받은편지함에 들어가서 메일을 읽을 때는 답장, 전달, 삭제 등의 메뉴가 나와야 한다. 임시보관함에서 메일을 읽을 때는 보내기 메뉴가 나와야 하고 휴지통에서 읽을 때는 복원이나 완전히 삭제하기 등의 메뉴가 나와야 한다. 이 메뉴를 어떻게 그릴 것인가? 혹시 이렇게 메뉴를 그리려면 지금 어느 편지함에 있는지 알아야 한다라고 생각했다면 당신은 아직 절차적 패러다임으로 생각하고 있는 것이다. 그럼 아마 이렇게 짤 것이다.

class 메일클라이언트:
  def drawMenu(편지함):
    if 편지함 is 받은편지함:
      menu.add(답장)
      menu.add(전달)
      menu.add(삭제)
    elif 편지함 is 임시보관함:
      menu.add(보내기)
    elif 편지함 is 휴지통:
      menu.add(복원)
      menu.add(완전삭제)
    draw(menu)

이제 이걸 어떻게 짜야하는지 알 것이다. 어느 편지함에 있는지를 알려 하지 말고 편지함에 그 일을 맡기면 된다.

class 메일클라이언트:
  def drawtMenu(편지함):
    draw(편지함.getMenu())

class 받은편지함:
  def getMenu(self):
    menu.add(답장)
    menu.add(전달)
    menu.add(삭제)
    return menu

말하자면, 어떤 상태에 따라서 동작이 달라져야 하는 경우에 if else를 쓰지 말고 다형성으로 해결해야 한다는 것이다. if else를 쓰면 그 상태에 따라 달라지는 분기문이 코드 이곳 저곳에 산재하게 된다. 그리고 보통 그 분기 조건도 쓰는 곳마다 미세하게 다르다. 받은편지함의 목록 볼 때 나와야 할 필드와 보낸편지함의 목록을 볼 때 나와야 할 필드는 다르지만 또 사용자가 임의로 만든 폴더는 받은편지함과 비슷할 수 있다. 이런 것들이 다 if else로 처리되면 나중에 감당이 안되는 코드가 남는 것이다.

기능 차원의 거시적인 예를 들었지만 사실 미시적인 부분에서도 이런 다형성은 계속 필요하다. 이를테면 자식 뷰를 가질 수 있는 뷰 컨테이너를 그리는 코드는 어떻게 짤까? 컨테이너에 무슨 뷰가 들어와 있는지 if else로 확인하면서 그릴 수는 없을 것이다. 이 경우도 자식 뷰의 draw를 차례로 호출해서 그리는 로직을 위임한다. 그래서 화면 가득이 컴포넌트가 넘쳐나는 화면도 if else를 쓰지 않고 그리는 코드를 짤 수 있는 것이다.

사실 이런 것을 설명해야 한다는 사실 자체가 당혹스러웠던 적도 있다. 심지어 코드 리뷰할 때 type code를 쓰는 부분을 제거해야 된다는 이야기를 했더니 그럼 어떻게 해야 되느냐는 질문이 나왔는데 그 질문에 대답할 수 있는 사람이 아무도 없었던 적도 있다. 하지만 사실 생각해보면 대학에서 OOP를 가르치는 것도 아니고, 학원에서 OOP를 가르칠 리도 없고, 실무에서 가르쳐줄 수 있는 실력자가 많은 것도 아니니 당연한 현상인지도 모른다. 아마 다형성만 정확하게 이해하고 써도 전세계 개발자의 10% 안에는 충분히 들지 않을까.

굳이 전세계를 언급한 이유는 안드로이드의 소스코드들도 반 OOP적인 특성으로 가득하기 때문이다. 처음에 다른 개발자들이 짠 안드로이드 앱 코드를 보면서 뭐 이따위로 짜놨나 생각을 했었는데, 안드로이드 소스코드와 예제들에 다 그렇게 되어 있었다. 그 소스를 보고는 정말 이게 구글에서 짠 코드인가 하는 생각마저 했었으니까. 이를테면 이런 것들이다. 앞서 이야기한 type code, 거의 OOP의 적이다. 그런데 안드로이드는 내부 소스 뿐 아니라 API에서도 type code를 개발자가 선언하고 쓰게 만드는 API가 많다. 게다가 거의 최근 10년 간 본 적도 없던 out parameter까지 등장했다. OOP 뿐 아니라 절차적 프로그래밍의 관점에서도 아주 나쁜 관례다. 상태를 많이 만들고 기억하게 만드는 코드이기 때문이다. 객체를 생성하고 사용하는 코드를 봐도 일단 생성한 다음 이것저것 세팅을 하고 나서 실행해야 하는 API가 여럿 있다. 헝거리안 표기법은 앞서의 단점들에 비하면 그래도 참아줄 만한 단점인지도 모른다. 아마도 C 개발자들이 자바 문법만 배우고 개발한 게 아닌가 하는 생각이 든다.

안드로이드 공식 문서의 퍼포먼스 팁도 거의 반 OOP 가이드나 다름 없다. 객체를 만들지 말라고 하고 인터페이스 대신 버추얼을, 버추얼 대신 스태틱을 쓰라고 할 정도니 심각하다. internal getter/setter도 나쁘다고 하니 상속할 때는 멤버를 죄다 protected로 하란 말인가. 또 하나 심각한 것은 field lookup을 멤버로 캐시해두라는 것. 거의 써먹을 만한 팁이 몇 안된다. 이런 식으로 코딩했는데도 안드로이드의 화면 응답성은 아이폰만 못하다면 안드로이드 개발자들의 실력이 부족한 거라고 봐야 하지 않을까.

자바도 OOP의 전통이 상당히 깊은 언어지만 아직 다형성을 정확하게 이해하는 개발자는 별로 많이 만나지 못한 것 같다. 자바 계열은 프레임웍을 상당히 많이 쓰고 프레임웍은 다형성 없이 존재할 수 없는 것인데 왜 이런 현상이 발생할까? 내가 세운 가설 하나는, 프레임웍이 나무만 보고 숲을 보지 못하게 만드는 넛지를 주기 때문이 아닌가 싶다. 위의 메일 클라이언트로 예를 들면, 받은편지함.getMenu만 짜게 만들기 때문에 메일클라이언트.drawMenu를 보지 못하는 것이다. 사실 다형성은 편지함.getMenu를 implement하는 곳에 있는 게 아니고 메일클라이언트.drawMenu에 있다. 이걸 봐야 다형성이 왜 필요한지 아는데, implement만 하다보니 이런 것을 잃어버리는 것이다. DependencyInjection이나 InversionOfControl도 결국 다형성으로 설명하는 것들이다. 그런데 다형성을 모르고 이런 개념들을 쓰는 사례가 간간이 보인다. AOP로 나아가는 것도 좋겠지만 그 전에 OOP부터 마스터하고 넘어가야 한다. 언제 또 이야기할 기회가 있겠지만 AOP는 OOP 없이 제대로 활용할 수 있는 개념이 아니며, 또한 AOP가 필요하다고 생각하는 많은 부분이 OOP로 해결된다.

아뭏든, OOP 개발자로 거듭나기 위해서는 다형성을 이해하는 것이 그 첫걸음이다. if else가 코드 안에서 번식하기 시작한다면 다형성을 생각해보자.

블로그 / 소프트웨어 개발

아이폰 개발은 내가 학습에서 가장 지진했던 분야다. Hello World를 완전히 이해하는데 무려 이틀이 걸렸고, ViewController 및 delegate 구조, nib와 outlet, 각종 UI 컴포넌트 사용법 등의 주요 개념을 파악하는데 2주 가량 걸렸다. 3주 째에 첫번째 아이폰 애플리케이션을 완성. HTML/CSS/JS로 만든다면 하루면 충분한 정도의 애플리케이션이었다. 한 달 가량이 지나서야 내 맘대로 개발할 수 있겠다는 생각이 들었다.

반면, 안드로이드는 Hello World는 할 것도 없었고 View, ViewGroup, Context, resource, Intent, Animation 등의 주요 개념을 학습하는데 1주가 안 걸렸다. 나흘 째에 이미 첫번째 업무로 주어진 애플리케이션의 기능을 대부분 완성하고 UI까지 다 입혔다. 아직 2주도 채 지나지 않았는데 다 파악했다는 느낌이 온다.

물론, 둘다 내 학습 스타일상, 책 펴놓고 공부하거나, 문서 열심히 읽고 시작하거나 하지는 않았고, 일단 개발 환경 실행시켜놓고 달려드는 식이었다. 하지만 아이폰 쪽은 문서를 안 읽고는 이해가 안가는 부분들이 너무 많아서 하면서 내내 문서를 뒤적거리면서 했던 반면, 안드로이드는 대부분 API 문서 찾아보는 것과 구글링으로 충분했다.

이쯤 되면 아이폰 개발을 안드로이드 개발보다 훨씬 후진 걸로 평가해야 정상일 텐데, 별로 그런 생각이 들지 않는다. 아무래도 직접 비교하기는 좀 그렇다. 사실 아이폰 개발은 다른 GUI 애플리케이션 개발과 구조가 완전히 다르다. 지금까지 GUI 애플리케이션 개발 경험을 보면 AWT에서 시작해서 비주얼 베이직, MFC, SWT, HTML/CSS/JavaScript, 플래시까지 많은 플랫폼을 써봤는데, 대부분 비슷비슷한 개념들을 쓰고 있고, 안드로이드도 그런 관례를 충실히 따르고 있다. 하지만 아이폰 UI 클래스들의 구조는 이런 것들과 완전히 다르다. 때문에, 나의 UI 개발 경험들이 안드로이드에는 거의 그대로 적용이 되었지만 아이폰에는 별 도움이 안되었다.

거기에 OS와 IDE에 익숙지 않은 것도 한 몫 한다. 코코아가 다른 GUI 툴킷과 다른 것처럼 맥도 리눅스, 윈도우와는 큰 차이가 있다. 특히 단축키 구조가 다른 것이 가장 고통스러웠다. 현실적으로 맥의 단축키 구조가 그 자체로 주는 장점이 거의 없는 이상, 윈도우의 관례를 따라가는 것이 좋지 않을까. 키보드도 다르게 생겼지만 UX적으로 아무런 장점도 주지 못하고 있다. 맥 애플리케이션의 멀티 윈도우 시스템도 고통스러운 점 중 하나. 파인더도 버그인지 기능을 몰라서 그런지 짜증스러운 점이 좀 있었다. Xcode는 나름의 장점이 있지만 편집 단축키가 한참 부족하고 리팩토링, 소스 스켈레톤 생성 등의 기능이 모자라다. 아뭏든, 이런 점들이 있기 때문에 익숙해지는 과정을 단순 평가하기는 힘들다. 물론, 안드로이드 개발이 기존의 경험을 잘 활용하게 해준다는 것은 그 자체로도 충분히 플러스 점수를 줄 수 있는 것이기는 하다.

그래서, 익숙해진 후의 관점을 비교한다면, 아이폰과 안드로이드는 장단점이 비슷하게 어우러지는 느낌이다. 완성도는 아이폰이 압도적으로 높다. 이미 코코아에서 탄탄하게 다져진 클래스들을 코코아 터치로 가져온 것이기 때문에 API의 완성도가 높고 되는 것 안되는 것이 명확하다. 하지만 안드로이드는 SWT나 스윙의 컴포넌트 상속 구조를 그대로 가져오지 않고 새로 만든 것이기 때문에 아직은 완성도가 낮다. 이벤트에 여러 개의 리스너를 지원하지도 않고 중첩 컴포넌트의 이벤트 전달도 좀 부실하다. View와 ViewGroup 등의 상속 구조, 난립하는 ViewGroup 클래스들 등이 UIView를 중심으로 하는 코코아 터치의 견고한 설계에 비하면 부족한 느낌이다.

인터페이스 디자이너의 완성도 차이는 그야말로 극과 극이다. 코코아 터치의 인터페이스 디자이너는 가히 UI 디자이너 중 최고라고 할 만한데 안드로이드의 레이아웃 에디터는 형편 없다. 스타일조차 에디터에서는 반영이 안되니 실행시켜봐야 한다. 여담이지만, 둘다 코드만으로 UI를 구성하는 것도 가능한데, 이건 정말 어리석은 일이다. 코드도 불필요하게 번잡해질 뿐더러, 직관성이 아주 떨어진다. UI를 구성할 때 눈으로 보면서 구성하는 것과, 실행해보고 고치고 하는 것의 생산성 차이는 엄청나다. 안드로이드에서는 레이아웃 에디터가 불편해서 xml 에디팅을 직접 하기는 하겠지만 그래도 자바 코드로 하는 것보다는 훨씬 낫다. 비유를 하자면, 웹 프로그래밍 하면서 HTML을 직접 쓰는 것과, 자바스크립트의 DOM으로 HTML을 그리는 것의 차이다. 많은 숙련된 자바스크립트 개발자들이 DOM을 쓰느니 차라리 innerHTML을 쓰라고 하는 것도 이게 더 직관적이기 때문이다. 심지어 플래시 개발할 때도 코드로 뷰를 그리는 개발자를 본 적이 있는데, 이래서는 안된다. 이 문제가 더 심각한 것은, 이렇게 코드로 뷰를 그리는 것을 선호하는 개발자들이 대개 뷰와 컨트롤러를 분리하지 않는다는 것이다. 그래서 뷰를 그리는 코드와 로직 코드들이 얽혀 있는 코드를 만들어내곤 한다. 그림은 툴로 그리고, 머리는 로직을 짜는데 쓰는 게 좋다.

다시 돌아와서, 에뮬레이터도 아이폰은 금방 뜨는데 안드로이드는 이미 악명이 높다. 안드로이드 에뮬레이터의 성능에 관한 최고의 조언은, 일단 띄워 놓으면 절대 닫지 말라는 것. 에뮬레이터 뜨고 나서의 실행 시간도 느리다.

하지만 안드로이드의 API들은 익숙하다. 설계는 조금 다르지만 기본 컨셉은 기존의 GUI 툴킷과 같기 때문에 경험을 쉽게 재활용할 수 있다. Objective C와 Java의 차이도 크다. 둘다 문법이 verbose한 편이기는 하나, Java가 그래도 조금 더 간결하다. 무엇보다 Objective C의 verbosity는 Xcode가 썩 잘 커버해주지 못한다. 캐스팅이라든지, protocol implement, property 등을 보면 만드는 과정의 중간 단계들은 자동 완성 지원이 되는데, 전체 과정이 자동화되지는 않는다. 반면 이클립스는 중간 단계들은 물론이고 전체 단계도 스무스하게 잘 완성시켜 준다. 사실 자바는 이클립스든 IDEA든, IDE가 워낙 좋아서 문법의 verbosity로 인한 context 끊김이 적다. 뭔 소리냐면, 예를 들어, 퀵 소트 알고리즘을 직접 구현한다고 할 때, 알고리즘을 생각하다가 리스트 사용법을 생각하느라고 알고리즘 생각이 끊기는 일이 없다는 것이다. 하지만 Objective C는 로직을 생각하다가 빠뜨린 괄호를 붙이러 맨 앞으로 간다든지, 프로퍼티를 바로 연결하고 싶은데 IBOutlet property로 선언하느라 .h와 .m을 왔다갔다 하는 등, 문법의 verbosity로 인한 끊김이 크다. 거기에 가비지 컬렉션이 안되는 건 정말 불편하다.

또 다른 중요한 차이는, 아이폰이 훨씬 이쁘다는 것이다. 계속 쳐다보고 싶은 생각이 든다. 하지만 안드로이드의 에뮬레이터는, 아니 어떻게 그렇게 못 생기게 만들 수가 있는지. 이건 진짜 내가 디자인해도 저거보다 잘하겠다. 기본 위젯들의 생김새도 차이가 크다.

물론, 아이폰이 안드로이드보다 더 견고한 아키텍처와 깔끔한 API를 가질 수 있는데는 아이폰이 더 단순하다는 것도 있다. 다양한 화면 크기와 입력 장치를 생각해야 하는 안드로이드와 달리 아이폰은 그런 고민이 필요 없다. 키 이벤트도 필요 없고 포커스 개념도 first responder 정도로 충분하다. 가변폭도 생각할 필요가 거의 없고, 위젯도 없고 멀티 윈도우도 없고 intent 같은 것도 없다. 물론 단순함이 주는 장점도 크지만 그것이 아이폰을 장난감에 머무르게 하는지도 모른다. 위젯이 안된다는 것은 정말 비즈니스 스마트폰으로는 실격이다.

어느 쪽이 개발이 즐거운지는 좀 애매하다. 일단 아무리 UI 개발이라도 개발의 대부분은 코드와 함께하는데, 코딩하기에는 역시 이클립스가 Xcode를 압도한다. 다양한 편집 기능과 단축키, 리팩토링, 프로젝트 관리, 소스 저장소 등등, 거의 모든 기능에 차이를 보인다. 딱 하나 좋은 것은 타이핑할 때 자동완성이 이클립스보다 좀더 기민하다는 것. 하지만 이것도 IDEA나 RubyMine 앞에서는 무릎을 꿇어야 한다. IDEA나 RubyMine에 90점을 준다면 이클립스는 80점, Xcode는 50점 정도다. 비주얼 스튜디오 2008은 60점 정도? RubyMine을 써보면서 꼭 이놈은 내가 뭘 하고 싶은지를 알고 있는 것 같다는 느낌을 많이 받았는데, Xcode는 그냥 내가 뭘 타이핑하고 싶은지를 아는 정도다. 그러다보니 코딩의 재미는 안드로이드 쪽이 더 크다. 반면, 아이폰은 에뮬레이터가 좋고 UI가 미려하고, UI 그리기가 수월하다보니 만들고 실행해보고 하는 과정은 아이폰이 훨씬 재미있다.

어쨋든 전부 플래시 개발이랑 비교하면 형편 없다. 개발 도구도 이클립스에 FDT를 쓸 수 있기 때문에 좋고, 플래시 툴 자체도 코코아의 인터페이스 디자이너처럼 쉽지는 않지만 편리함에서는 비슷하다. 무엇보다 큰 차이는 아키텍처다. UI 개발에서 가장 중요한 것은 View 상의 컴포넌트를 어떻게 조작하고, 이벤트를 어떻게 연결하는가이다. 코코아 터치에서는 코드로 일단 써놓고 인터페이스 디자이너에서 연결해야 해서 좀 번거로운 편이다. 반대로 인터페이스 디자이너 쪽에서 뭔가 지정하고 자동으로 코드를 생성하게 했다면 훨씬 나았을 텐데. 안드로이드는 리소스 클래스를 이용하는 방식이라 글로벌한 ID를 지정해야 하는데, 이게 캐스팅 문제도 좀 있고, 간혹 뷰를 넘겨야 하는지 ID를 넘겨야 하는지 혼동되는 점도 있는 등, 약간 불편하다. 반면 플래시는 뷰를 디자인하면서 속성 이름만 지정해주면 그대로 코드에서 프로퍼티로 쓸 수 있다.

이벤트 지정 방식도 IBAction을 선언하고 연결해줘야 하는 코코아 터치는 역시 순서가 바뀐 느낌이라 불편하다. 안드로이드는 예의 자바의 익명 클래스를 활용한 이벤트 리스너 등록이라 문법이 번잡하다. 플래시는 클로저가 가능하니 당연히 훨씬 좋다. 하지만 이벤트 전달 방식은 HTML 쪽이 더 좋은 듯.

UI 재활용 측면에서도 재활용하려면 별도의 nib로 분리하고 컨트롤러를 붙이거나, View에서 로드하거나 해야 하는 코코아 터치는 많이 번거롭다. 안드로이드도 layout xml 파일을 분리해야 하므로 불편. 사실 큰 부분을 재활용할 때는 분리하는 게 더 낫지만 테이블의 셀처럼 작은 부분을 컴포넌트화하고 싶을 때도 그 때마다 파일을 분리해야 되면 번거롭다. 반면 플래시는 심볼로 만들어주기만 하면 손쉽게 재활용 가능하다.

애니메이션은 뭐 비교 불허. 비디오, 오디오 등의 미디어를 다루는 것도 월등이 편리하다.

개발 생산성을 비교한다면, 똑같은 애플리케이션을 만들 때, 플래시로 일주일이 걸리는 일이라면, 안드로이드는 1개월, 아이폰은 2개월 가량 걸리지 않을까. 잡스는 고집 그만 부리고 그냥 플래시 탑재하자. 플래시는 이미 아이폰보다 오래 전부터 핸드폰에서 쓰였고, 성능에 아무 문제 없다.

블로그 / 소프트웨어 개발

[프로페셔날의 조건]에 나온 이야기. 아테네의 파르테논 신전 위에는 페이디아스라는 조각가의 작품이 서 있는데 지금도 최고의 걸작으로 평가 받고 있다. 그런데 정작 아테네의 재무관은 작품료 지불을 거절했다. "조각들은 신전의 지붕 위에 있고 신전은 아테네의 가장 높은 언덕에 있기 때문에 사람들은 조각의 전면 밖에 볼 수 없다. 그런데 당신은 아무도 볼 수 없는 조각 뒷면의 비용까지 청구했으니 줄 수 없다."가 이유였다. 이에 대해 페이디아스는 이렇게 답했다. "아무도 볼 수 없다고? 당신은 틀렸어. 하늘의 신들이 볼 수 있지."

그리고 이어서 피터 드러커는 사람들로부터 "당신이 쓴 책 가운데 어느 책을 최고로 꼽습니까?"라고 물으면 "바로 다음에 나올 책이지요"라고 대답한다는 말을 남겼다.

프로 바둑 기사들도 비슷한 이야기를 한다. 바둑 해설을 보다보면 [정석에 대한 오해]와는 달리 프로 기사들의 유연한 사고 방식이 참 많이 느껴진다. 특히 포석 단계에서는 이렇게 두어도 한 판의 바둑, 저렇게 두어도 한 판의 바둑이라는 말처럼 유연성이 많이 강조된다. 하지만 그럼에도 불구하고 프로기사들은 포석 단계에서도 신의 한수를 추구한다. 언젠가 조훈현 9단이 그런 말을 한 적이 있다. 가볍게 이야기할 때는 이렇게 두어도, 저렇게 두어도 한 판의 바둑이라는 이야기를 하지만 사실은 분명히 최선의 한 수가 존재한다. 단지 찾지 못하고 있을 뿐이고 프로 기사들은 모두 그 한 수를 찾기 위해 끊임 없이 연구한다. 이런 자세가 아마도 젊은 기사가 득세하는 바둑계에서 환갑을 바라보는 조훈현 9단이 살아 남는 이유이기도 할 것이다.

나에게도 비슷한 욕망이 있다. 당장은 현재의 기술로도 한 판의 프로젝트를 제대로 해낼 수 있다. 하지만 늘 그 너머의 신의 한수를 찾고 싶은 욕망이 있다. 그건 프로그래밍 언어가 되기도 하고 프레임워크가 되기도 하고 OS가 되기도 한다. 이런 욕망들이 기술의 발전을 이끌고 있는 것이리라.

블로그