출처 : [한빛미디어] 2006-07-10 10:37

저자: Ed Burnette, 한동훈 역

가리발디: 이것들을 시도해 본 적 있어?
미스 크레이머: 그게 뭔데?
가리발디: 나도 몰라. 번역기에 따르면, 이건 성욕을 일으키는 것이거나 바닥 왁스야. 해볼만한 가치가 있는지는 모르겠어.
- 바빌론 5, "감염"

역주: 여성들에게 성욕을 유발시키는지 테스트 하기 위해 윗입술에 향을 발라주면서 하는 거짓말로 가장 흔한 것이 "새로운 바닥 왁스의 향을 시험하는 것"이라고 하는 데서 기인한 표현인 듯.

이클립스(Eclipse)는 자바 프로그래밍을 위한 인기있는 통합 개발 도구(IDE)이며, 데스크톱이나 서버 응용프로그램을 개발하기 위한 풍부한 기능을 제공하는 클라이언트 플랫폼으로, 다양한 툴들을 통합하는 프레임워크로서 C++이나 루비(Ruby) 같은 다양한 언어들을 위한 개발 환경으로도 사용된다. 이클립스 오픈소스 커뮤니티는 비즈니스 인텔리전스(BI)에서 소셜 네트워킹에 이르기까지 수십개의 프로젝트를 책임지고 있다. 또한, 이클립스는 이들 프로젝트를 관리하는 비영리 단체의 이름이기도 하다.(이게 바닥 왁스가 아니라고 확신하고 있지만, 이클립스 자동차, 축구 팀, 껌의 브랜드이다)

역주: 2006년에 미츠비시에서 새로운 승용차 브랜드, 이클립스를 내놓았다. 이클립스 축구 클럽이 있으며, 물론, 이클립스 껌도 있다.

이클립스 버전 3.2는2006년 6월 30일에 연이어 발표되는 10개의 이클립스 프로젝트의 첫번째에 해당한다. 이 기사는 이클립스 IDE에 중점을 두며, 특히 JDT(Java Development Tools)에 대해 설명한다.

JDT 만들기

JDT의 계보는 1996년 경에 스몰톡(Smalltalk)으로 작성된 비주얼 에이지 포 자바(VAJ)로 거슬러 올라간다. VAJ에서는 입력하는 대로 모든 것이 컴파일되고, 메모리에서 모든 것이 해석된다. 이러한 설계는 긴 코드에 적합하지 못하며, 확장하기 어려우며, 파일 정보를 재생성하는 것이 어려웠다.

1999년에 IDE 팀은 비주얼 에이지 마이크로 에디션(VAME)을 개발하기 시작했다. 모든 게 자바로 작성되었으며, 사용자 인터페이스에는 표준 위짓 툴킷(SWT)를 사용했다. VAME는 임베디드 영역을 위해 설계되었다. VAME는 표준 자바 VM을 사용했고, 파일 시스템에 작업공간(workspace)를 유지했다. 그러나, 파일과 폴더 이름은 읽기 나쁜 UUID로 되어 있었다.

VAME의 점진 컴파일러(incremental compiler)는 VAJ 보다 약 10배 정도 더 빨랐다. 여기서 사용된 모델은 상태 기반으로 구축되었다.(소스 기반으로 되어 있는 이클립스와는 반대다) VAME는 플러그인을 사용해서 확장할 수 있는 Rapier라는 저장소 시스템(repository system)을 갖고 있었다.

VAME는 커뮤니티에서 그리 많은 이목을 끌지 못했지만, 개발자들이 다음 프로젝트 즉, 이클립스에 심어놓을 좋은 아이디어를 많이 갖고 있었다. 2001년에 이클립스 1.0이 발표되었다. 이클립스 1.0은 "안되는 게 없는 IDE"로 소개되었다. 초기부터 이클립스와 JDT는 다른 개발 툴을 위한 플랫폼으로 구축되었다.

작업공간(workspace)는 디스크에 저장되었고, 다른 툴에서 열 수 있다. 이클립스 1.0은 독점적인 작업 공간을 사용하는 대신 CVS와 통합되어 있다.

이클립스는 이전 세대와 중요한 차이점 즉, 오픈소스다. 사용자 커뮤니티는 폭발적으로 증가했으며, 스스로 성장할 수 있게 되었다. 이클립스 3.2에서 새로운 기능이나 향상된 기능들의 대부분은 이클립스 사용자들이 채워넣은 개선들의 직접적인 결과물이다. 3.1이후로 3만개 이상의 수정 사항과 개선 사항들이 있었다. 이를 나열하는 것은 지나치게 길기도 하고, 지루하기도 하므로, 대부분의 자바 개발자들에게 중요한 몇 가지만 중점적으로 살펴보기로 하자.

이클립스 컴파일러

JDT의 가장 강력한 기능은 javac와 완벽하게 호환되는 내장형 점진 자바 컴파일러다. 이클립스에서 Ant와 javac를 사용하게 설정한 경우에도 IDE에서 문제에 대한 표식(problem marker)를 표시할 수 있다.(3.2의 새로운 기능). 이클립스 컴파일러는 보다 나은 소스 분석과 보다 빠른 처리 시간을 제공한다.

JDT 컴파일러는 본래 VAME를 위해 쓰여졌으며, 이클립스를 위해 수정되었다. 이는 개발자들이 로봇공학에 대한 아시모프의 3원칙 이후로 패턴처럼 된 "컴파일의 3원칙"으로 부르는 것을 토대로 구축되었다.

1. 정확성(Correctness): 컴파일러는 소스 프로그램에 위해를 가하지 않아야 한다
   
2. 효율성(Efficiency): 첫번째 법칙을 위배하지 않는 한 컴파일러는 빨라야 한다.
   
3. 편의성(Friendliness): 컴파일러는 첫번째와 두번째 법칙을 위배하지 않는 한 사용자가 프로그래밍 오류를 수정하는 것을 도와야 한다.
   

역주: "로봇", "파운데이션" 같은 장편외에 영화 "바이센테니얼맨"의 원작인 "200살을 맞은 사나이" 등으로 잘 알려진 과학자이자 다작의 문필가였던 아이작 아시모프가 1940년에 만든 로봇 3원칙(The Laws of Robotics)은 이후 로봇 공학자들에게 있어 로봇의 기본 원칙으로 자리 잡았다. 1985년에는 0원칙이 추가된 "수정된 로봇 3원칙"이 발표되었습니다.

로봇 3원칙 (The Laws of Robotics)

제1원칙 (First Law): 로봇은 인간에게 해를 끼쳐서는 안되며, 위험에 처해있는 인간을 방관해서도 안된다.

제2원칙 (Second Law): 제1원칙에 위배되지 않는 경우 로봇은 인간의 명령에 반드시 복종해야만 한다.

제3원칙 (Third Law) : 제1원칙, 제2원칙에 위배되지 않는 경우 로봇은 자기 자신을 보호해야만 한다.

정확성: 자바 컴파일러를 설계할 때는 스펙을 따라야 하며, 스펙의 "정신"도 따라야 한다. 홀로 올바른 것(right alone)이 되어서는 안된다. 따라서, JDT 개발자들은 Sun의 컴파일러를 비롯해서 다른 컴파일러들의 동작 방식과 합의를 이루기 위해 수년간 작업해왔다. 정확성은 이클립스 3.2에서 15,000개 이상의 단위 테스트를 통해 검사되었다.

효율성: 수천개의 프로젝트와 수백만 줄의 코드를 표준으로 하였다. 이와 같은 표준은 수 많은 가정을 내제하고 있는 것이다. 예를 들어, 메모리 사용량은 예측 가능해야하며, 균형을 이뤄야 한다. 이클립스 3.2는 적극적인 최적화를 통해 이를 최대한 다듬어왔다. 예를 들어, 개발자들은 비트 연산을 사용해서 플로우 그래프(flow graph)를 재작성했으며, 전체 시간을 20%에서 4%로 낮췄다.

편의성: 오류 보고는 예술이다. 줄 번호로는 충분하지 않다. 2차 오류는 최소화되었다. 예를 들어, 어떤 파일에서 세미콜론(;)을 잊었다면, 이 파일에 의존하는 다른 파일에 영향을 주지 않는다. 향상된 정적 분석은 오류들의 패턴을 발견한다. 이클립스는 또한 정확성을 위해 Javadoc을 검사한다.

3.2 발표로 이클립스 컴파일러는 Java SE 6.0과 호환이 가능하다. 이클립스는 자바 6 카테고리를 지원하며, 자바6가 발표되지도 않았는데도 StackMapTable 특성을 지원한다. 뿐만 아니라, 컴파일러는 실행해보기도 전에 코드에 있는 문제들을 발견하는 것을 도와주는 새로운 분석 도구들을 갖고 있다. VAJ는 세가지 분석도구를 갖고 있었으며, 3.2 컴파일러는 45가지 분석도구를 갖고 있다. 이들 중에 새로운 것은 탐지와 관련된 것이다.

1. 명백히 null인 변수의 사용
   
2. null에 대한 불필요한 검사
   
3. 메서드 매개변수에 우발적인 할당
   
4. switch case가 이전 case로 부터 실행되는 경우
   
5. 비제네릭 형식 사용
   
6. 사용하지 않는 레이블
   
7. 불필요한 $NON-NLS$ 태그
   

이들 대부분은 사용하지 않음이 기본 설정이다. 또, @SuppressWarnings 어노테이션을 사용해서 이런 기능을 사용하지 않을 수 있다.

이클립스 없이 이클립스 컴파일러를 사용하고 싶다면, 3.2에서는 개별 다운로드를 이용하면 된다. 명령줄 매개변수는 javac와 호환되며, 1M 정도만 다운로드하면 된다. 이클립스 컴파일러는 오픈 소스이며, 아파치 톰캣이나 그외 함께 번들된 소프트웨어를 포함한 많은 프로젝트들도 오픈 소스이다.

편집

개발 도구의 가장 기본적인 기능은 편집이다. 대부분의 시간을 편집기에서 보내며, 편집기는 편해야 하며, 불편해서는 안되며, 또한 강력해야 한다. 이맥스에서 소스 언어에 대한 기본적인 지식을 갖고 있으며, 구문 강조 기능을 제공한 이래로 모든 편집기가 갖고 있는 기능을 갖고 있다. JDT는 자바 모델을 사용해서 이 문제를 해결한다. 예를 들어, JDT는 클래스와 인스턴스 변수의 차이점을 알고 있으며, 이들을 다른 색상으로 구별할 수 있다. 호출하는 함수가 폐기된 함수(obsolete 또는 deprecated)이면 소스 코드 코멘트에서 이를 알려줄 수 있으며, 살펴볼 코드 부분을 밑줄과 함께 강조해준다.

자바 편집기의 가장 강력한 기능은 Ctrl + Space(콘텐트 보조)다. 객체의 메서드가 기억나지 않거나, 클래스의 정확한 철자를 모를 때가 있지 않은가? Ctrl + Space를 누르면 이클립스는 현재 위치에서 사용할 수 있는 모든 목록을 제공한다. 예를 들어, "LongJavaName"과 같은 긴 이름을 가진 식별자를 입력한 경우는 없는가? 이제, "LJN"으로 입력하고 Ctrl + Space를 누르면 이클립스는 무것을 의미하는지 알 수 있다. 이를 "낙타표기법 완성(CamelCase completion)"이라 부른다. 이는 Ctrl + Shift + T, 형식 검색에도 동작한다.

"StringBuffer buffer = new StringBuffer();"와 같은 표현들을 입력한 적이 있는가? 이제, 스스로 이를 반복하지 마라. 3.2에서는 대신에 "SB"를 입력하고 Ctrl + Space, Space, Ctrl + Space, " = new", Ctrl + Space, "();"를 입력하면 된다. 16번의 키 입력으로 47번의 키 입력을 대신할 수 있다. 변수 이름에 다른 접두어를 사용하고 싶은가? 문제 없다. 두번째 Ctrl - Space를 누르기 전에 원하는 접두어를 입력하면 된다. 예를 들어, 3.2에서는 "Element root" + Ctrl + Space는 그림1과 같이 "Element rootElement"로 완성된다.


그림1. 콘텐트 보조(Ctrl + Space)는 3.2에서 더욱 똑똑해졌다. 낙타표기법 완성을 지원하며, 이미 입력한 문자들을 기억한다.

여기, 또 다른 시간 절약이 있다. 3.2에서 Ctrl + Space는 사용 패턴에 기초해서 제안 항목을 동적으로 재배열한다. 예를 들어, 항상 List 변수에 ArrayList 인스턴스를 할당한다면, 재빨리 이 항목을 선택할 수 있도록 ArrayList가 목록의 첫번째에 위치한다. 코드 완성은 JavaDocs에서도 동작하며, 긴 이름들을 기억하지 않아도 @links를 생성하거나 참조할 수 있다.

"이 줄에 문제가 있다는 것을 IDE가 스스로 알만큼 영리하다면 왜 그걸 수정하지 않는 걸까?"라고 질문해본 적은 없는가? 이클립스는 Quick Fix라는 기능이 있다. 문제가 있는 줄에 커서를 옮겨놓고 Ctrl + 1을 누르면 이클립스는 이를 수정하기 위한 제안을 제공한다.

이클립스의 새로운 릴리스는 새로운 Quick Fix를 제공한다. 예를 들어, 3.2에서는 raw 형식을 사용할 때 경고를 받았다면, 해당 줄에 커서를 위치하고 Ctrl + 1을 누르면 "Add type parameters"와 같은 fix가 선택된다. 또한 3.2에서 Quick Fix는 같은 파일에서 많이 발생한 공통된 문제들을 개별적으로 다루지 않고, 한 번에 처리할 수 있다.

추천하고 싶은 한 가지 기능은 "타입 이름 변경(Rename Type)"이다. 여러분이 나와 같은 개발자라면, 변수나 메서드를 타입 이름에 맞게 지어줄 것이다. 예를 들어, Bar 타입을 갖고 있다면, 변수 이름은 fBar, 메서드는 CreateBar처럼 지을 것이다.(그림2) 문제는 Bar를 다른 이름으로 변경할 때, 바꿔야할 것들이 너무나 많다는 점이다. 3.2에서는 변경하려는 타입과 유사한 이름을 가진 변수, 메서드 변경 기능을 제공한다. 이 기능은 3.2에서 내가 좋아하는 기능이다.


그림2. 이클립스 3.2는 타입 이름을 변경할 때, 비슷한 이름을 가진 변수 및 메서드 이름 변경을 제공한다.

실행

일부 IDE에서는 "주 프로젝트(main project)"를 하나 설정해야 하며, 프로그램을 실행하기 위해 실행 명령(Run command)를 사용한다. 이클립스는 이런식으로 동작하지 않는다. 이클립스에서는 명령줄 매개변수, 클래스 경로, JRE 버전과 같이 코드를 디버깅하거나 테스트하거나, 실행하는 데 필요한 모든 세부 사항들을 저장한 "시작 설정파일(Launch configurations)"들의 목록을 갖고 있다. 이클립스 3.2에서는 필터링 사용과 실행 환경을 통해 시작 설정 파일을 보다 쉽게 관리할 수 있다.

필터링은 관심있는 항목들만 목록에 나타내기 때문에 설정에 드는 수고를 줄일 수 있다. 실행 환경은 "J2SE-1.4" 같은 일반적인 이름을 사용하는 자바 런타임의 사용 가능성을 기술한다. 이클립스는 지정한 환경의 요구사항에 맞거나 그 보다 더 나은 환경을 제공하는 JRE를 선택할 수 있다.

개발동안 하나 이상의 테스트 슈트를 실행하고 있는가? 3.2에서는 동시에 실행할 수 있는 슈트를 여러 개 지정할 수 있으며, 이전 실행의 히스토리를 이용해서 이전 실행 결과를 살펴볼 수 있다. 이클립스 3.2는 JUnit 4.0도 지원한다.

팀으로 작업하기

코드 작성을 하면서 누가, 왜 여기에 이런 코드를 넣었는가 궁금해본 적이 있는가? 이클립스 3.2는 CVS 히스토리를 읽어들여서 현재 파일에 누가 무엇을 했는지, 적절한 색상을 이용한 주석을 보여준다(그림3) 변경된 블록 위에 마우스를 가져가면, 변경사항에 대한 개발자 이름, 날짜, 코멘트를 보여준다. 또한, 다른 파일들에서도 같은 개정번호로 되어있는 변경된 부분들을 강조해준다.


그림3. CVS Quick Diff 주석은 파일에 대해 누가 무엇을 했는지 주석으로 보여준다. 영역 위로 마우스를 가져가면 개정 사항에 대한 세부 내용을 보여준다.

여러분이 다른 사람의 코드를 호출해서 사용하고 있으며, 새로운 버전이 나오기 전까지 모든 것이 잘 동작한다. 그리고 나면, 호출하는 코드에 맞춰 내가 작성한 프로그램을 수정할 때 까지 해당 코드가 폐기되었다는 경고, 심지어는 컴파일러 오류까지 나타난다. 나는 여러분이 이런 경험이 있을 거라 믿는다. 이클립스 3.2는 이런 문제를 줄여주기 위해 "리팩토링 스크립트"라는 기능을 제공한다.

물론, 리팩토링은 동작을 변경하지 않으면서 소스 코드에 변화를 가하는 것을 의미한다. 예를 들어, 철자가 틀린 필드, 새로운 매개변수가 추가된 메서드등이 있을 수 있다. 이클립스는 여러분이 변경된 코드의 개발자인 경우 이런 변경사항을 자동화하는 기능을 지원한다. 이는 변경된 코드를 사용하는 고객들에게도 유용하다.
모든 리팩토링 동작은 히스토리에 기록된다. 이클립스 3.2에서는 이런 히스토리를 스크립트로 작성할 수 있고, 이를 나중에 재생할 수 있다. CVS에 스크립트를 저장할 수 있고, JAR 파일을 사용하는 사용자는 새로운 버전을 사용할 때 동일한 변경을 재생할 수 있도록 JAR 파일 안에 포함시킬 수도 있다. 이는 patch나 diff를 적용하는 것과는 다르다. 패치는 그들이 생성한 특정 소스 파일에 대해서만 동작한다. 리팩토링 스크립트는 리팩토링한 API를 사용하는 모든 소스 파일에 대해서 동작한다.

다른 사람들이 사용하는 API를 유지보수하는 것은 어려운 작업이며, 이제 이클립스가 이런 작업을 쉽게 해줄 수 있다. 메서드 이름을 변경할 때 이클립스 3.2는 이전 메서드를 그대로 남겨둘 것인지, 폐기된(deprecated)으로 표시할지, 새로운 메서드 호출로 돌려놓을 것인지를 물을 수 있으며, 이 메서드를 호출하는 모든 호출자에 이런 변경사항을 자동으로 적용하는 리팩토링 스크립트를 만들지를 묻는다.

코드 위생

이클립스는 전체 팀에서 코딩 표준(code formatting standards)를 적용하게 해주는 매우 강력한 코드 포매터가 오랜기간 사용되었다. 버전 3.2는 새로운 Clean Up 마법사를 두어 이를 더욱 발전시켰다.(그림4)마법사가 할 수 있는 작업들에는 다음과 같은 것이 있다.

1. 사용되지 않는 import 제거
   
2. 사용하지 않는 private 메서드, 생성자 제거
   
3. 누락된 @Override, @Deprecated 주석 추가
   
4. 누락된 $NON-NLS$ 추가 또는 불필요한 경우 제거
   
5. 모든 for 루프를 향상된for 루프로 변환
   
6. 제어 문의 본문을 블록으로 변환
   
7. 불필요한 캐스트 제거
   
8. Serializable과 Externalizable 클래스에 시리얼 버전 ID 추가
   

Clean Up 마법사는 자바 파일 하나, 패키지, 전체 프로젝트에 대해서 실행할 수 있다


그림4. Clean Up 마법사는 전체 프로젝트에서 일관된 코딩 표준을 지키도록 해준다.

결론

자바 프로그래머는 다른 언어나 플랫폼 보다 더 폭넓은 개발환경 선택권을 갖고 있다. 내가 단언할 수는 없지만, 이클립스는 마이크로소프트와 같은 단일 회사가 할 수 없는 부분을 사용자의 열정과 정력이 만들어낸 결과다. 이유가 무엇이든, 이클립스는 NetBeans, IDEA, JDeveloper, JBuilder를 포함한 다른 개발환경과 경쟁하고 있다. 3.2 발표와 함께 이클립스는 Java IDE의 경계를 한 단계 더 나아갔으며, 이는 여러분이 어떤 도구를 선택하든 간에, 모든 자바 개발자에게 유익한 일이 될 것이다.

참고자료

1. Eclipse home page
   
2. Callisto home page
   
3. JDT home page
   
4. Author's blog
   

Ed Burnette는 노스 캐롤라이나 주, 캐리(Cary)에 살고 있는 전문 개발자이자 저자이다.

글 : 게임메카 김명희 기자 [06.07.12 / 11:13]

최근 온라인게임을 즐기는 유저들이 “더 이상 할 게 없다”, “업데이트가 늦다”는 이유로 게임을 그만두는 사례가 늘어나고 있다. 온라인게임의 숫자와 유저들의 컨텐츠 소모 속도는 폭발적으로 늘어났지만, 이에 대응하는 컨텐츠 업데이트 속도나 서비스의 질은 몇 년 째 제자리걸음. 무엇보다 지속적으로 정식서비스 중인 게임의 새로운 컨텐츠를 제공해야 할 ‘패치팀’의 운영이 제대로 이루어지지 않아 업계의 골칫거리로 자리잡고 있다 베타테스트를 마치고, 정식서비스 중인 게임을 떠나는 가장 큰 이유로 유저들은 "정식서비스 이후 패치가 거의 이루어지지 않고, 더 이상 새로운 컨텐츠가 공급되지 않기 때문"이라고 입을 모은다. 이 같은 유저들의 잦은 서비스 이탈현상은 온라인게임의 수명을 전반적으로 단축시키는 원인으로 지적되고 있다. ▲ “패치팀은 남이 하던 일”, 개발자 기피현상 극심 게임 업체에서 ‘패치팀’이란 기존 게임의 버그를 수정하고, 새로운 컨텐츠 업데이트를 책임지는 개발팀을 말한다. 그러나 운영자들(GM)과 함께 게임의 안정적인 서비스를 책임지는 패치팀을 개발자들이 기피하는 등, 파행 운영되면서 그 피해를 유저들이 고스란히 떠안고 있다. 게임이 테스트 단계부터 좋은 평가를 받지 못했을 경우, 초기부터 개발에 참여했던 핵심 개발자들은 새로운 프로젝트로 투입되거나 다른 게임업체로 빠져나가는 것이 게임업계의 인력 이동상황. 결국, 비핵심개발자나 회사의 신입인력들이 패치팀으로 남아 게임의 버그 수정과 업데이트를 맡게 된다. 실제로 한 개발자는 “개발자들은 패치팀의 작업을 ‘남이 하던 일’이라는 생각에 기피한다”며 “패치팀에서 일하고 있으면 게임을 ‘창조’하는 기분이 아니라 ‘노동’하는 기분이 든다”고 고백했다. 특히, 이 같은 개발자들의 이동 대부분은 회사 측으로부터 이루어지는 정리해고나 인사이동이 아닌, 개발자 스스로의 선택이다. 게임업계 한 관계자는 “회사의 재정난이나 문제를 일으킨 직원이 아니라면, 개발자들을 함부로 자르는 회사는 없다”며 “(패치팀으로 남아도) 회사 측의 대우가 변함이 없음에도 불구하고, 개발자 스스로 새로운 게임을 찾아 떠나는 경우가 많다”고 말했다. 개발자들이 패치팀을 기피하는 이유는 프로젝트 별로 진행되는 게임업계의 특수한 제작환경과 함께 개발자 스스로 자신의 경력관리를 위해 끊임없이 성공할만한 게임을 찾기 때문. 실제로 개발자들은 “기존 게임은 대부분 과거의 형식에 맞춰 작업해야 하기 때문에 개발자로서 도전할 요소가 적다”는 것을 패치팀 기피의 가장 큰 이유로 들고 있다. ▲ ‘울며 겨자 먹기’식 패치팀 운영 개발팀의 인원은 일반적으로 오픈베타테스트 직전에 가장 많이 늘어나며, 상용화 두 달 이후부터 본격적인 인력 이동이 시작된다. 이때 게임이 실패한 경우뿐만 아니라, 게임이 성공한 경우도 눈덩이처럼 불어난 몸값의 핵심 개발자들은 더 좋은 조건을 제시하는 다른 회사로 대거 이탈하게 된다. 물론 서비스를 중단할 수 없는 회사 측에서 개발자들의 이탈을 막기 위한 ‘당근’을 내놓지만, 이마저도 새로운 게임에 초기 개발팀으로 참여했을 경우에 얻을 수 있는 높은 인센티브에는 비교할 수 없는 것이 현실이다. 한 중견 개발자는 “핵심 개발자들이 다 나가면 부랴부랴 후임 개발자가 팀장으로 올라가서 급하게 팀을 꾸린다”며 “패치팀의 경우 경력개발자들은 대부분 기피하기 때문에 직책이 필요한 사람이나, 신규인력 위주로 팀을 꾸릴 수 밖에 없는 게 현실”이라고 말했다. 게임 업데이트가 정기적으로 진행되는 엔씨소프트의 ‘리니지’, ‘리니지 2’나 상용화에서 큰 성공을 거둔 게임 몇몇을 제외하면, 이렇게 패치팀 운영은 대부분 주먹구구식이다. 새로운 게임을 쫓아 떠나는 일부 철새 개발자들. 그들로 인해 패치팀으로 남은 개발자의 소외감은 더욱 커지고, 버그 수정이나 업데이트에 무심해지면서 게임을 그만두는 유저들은 갈수록 늘어난다. 유저가 줄어들면 매출이 감소하고, 그에 따라 회사 측의 패치팀 지원은 당연히 축소되기 때문에 악순환이 반복될 수 밖에 없는 것이다. ▲ 철새 개발자, 오베족 유저, 매출 감소의 ‘악순환’ 게임을 개발하는 데 걸리는 시간은 짧게는 1년에서 길게는 2~3년이 소요된다. 신입 개발자들 대부분이 이 과정을 통해 경험과 경력을 쌓게 되고, 일할 수 있는 회사와 프로젝트 선택의 기회가 늘어나면서, 가장 많은 이직의 유혹을 받는다. 업계 전문가들은 “낮은 연봉과 열악한 작업환경에도 불구하고 게임업계에 지원했던 개발자들이 더 나은 프로젝트로 이동하는 것은 자연스러운 현상”이라며, “문제는 이 같은 패치팀 기피현상이 고착화되면서 전반적으로 온라인게임 서비스의 질이 떨어지고 수명이 짧아지는 데 있다”고 지적했다. 폴에버와 게임메카 온라인 조사에 따르면 2005년에 클로즈베타테스트나 오픈베타테스트 게임을 즐기는 유저들은 전체의 30%이다. 나머지 70%의 유저가 월정액제나 부분유료화 방식으로 정식서비스 중인 게임을 즐기고 있는 것으로 보고된다. 온라인게임 서비스 이용인구가 늘고, 해마다 더 많은 숫자의 새로운 온라인게임이 등장해 정식서비스에 들어가지만 유저들의 기대감이나 서비스 이용만족도는 해를 거듭할수록 떨어지고 있다. 온라인게임 비즈니스 전략의 저자 위정현 교수는 “온라인게임의 수명은 얼마나 적절하게 지속적으로 사용자 관리를 잘 했느냐에 달려 있다”고 지적한다. 그는 게임 시스템의 업그레이드에 대한 지속적인 투자가 가능한 개발자와 이를 전폭적으로 지원하는 개발사만이 게임 자체의 매력을 증가시키고, 매출을 증가시킬 수 있다고 조언했다.

오늘 내 기분??

[사회]‘문자’에 살고 ‘메신저’에 죽는다

‘퀵백’에 열광하는 1318세대… 디지털 기기 없으면 불안하고 소외감 느껴 ‘단1초의 기다림도 지겹다!’ 요즘 중·고등학생인 1318세대(13∼18세)의 특징이다. 대홍기획은 5월 8일 1318세대의 가치관과 소비행동을 조사 분석한 트렌드 보고서에서 ‘자신의 행동에 대한 반응이 1초의 기다림도 없이 즉각적으로 오길 바라고 언제 어디서든 반응의 추이를 보고 싶어하는’ 1318세대의 트렌드를 특징화했다. 대홍기획은 이런 특성을 퀵백(Quick Back)이라고 이름붙였다. 퀵백은 ‘퀵(빠른)’과 ‘피드백(반응)’의 합성어다. 기다림을 지루해 하고 즉각적인 반응을 기대하는 1318세대의 행동 양식은 여러 형태로 나타난다. 게시물을 올리고 일정시간이 지난 후에야 반응이 나타나는 블로그나 미니 홈피보다 즉각적인 반응이 나타나는 메신저를 더 좋아한다. ‘퀵백’을 위해 1318세대가 선호하는 것은 휴대전화 문자메시지. 한 친구가 아닌 여러 친구에게 동시에 문자메시지를 보내면 몇 초후 수 십개의 답장메시지가 날아온다. 휴대전화의 대기 벨소리를 기다리는 것조차 지루해 한다. 대홍기획 브랜드마케팅연구소 최숙희 부장은 “1318세대는 스피드가 있는 세대”라면서 “문자메시지, 펌글, 댓글 등을 통해 재빨리 피드백을 만든다”고 말했다. 가장 무서운 벌은 ‘휴대전화 뺏기’ 대홍기획측은 2005년 10월부터 2006년 3월까지 6개월 동안 서울에 거주하는 13∼29세의 남녀 600명을 대상으로 개별 면접조사했다. 이 조사에서 ‘퀵백’의 특성은 다양한 형태로 나타났다. 강북에 사는 A군(중2)은 “통화하는 것보다 문자를 보내는 게 더 빠르다”면서 “동시에 여러 사람한테 빨리 보낼 수 있다”고 답했다. A군은 게임하면서 문자를 보낼 수 있다는 점에서 더 편리하다는 점을 강조했다. 문자 내용에는 심각한 것은 없고 그냥 간단한 감탄사도 많이 보내는 편이라는 것이 A군의 답변이다. B군(고1)은 “문자메시지는 아무 때나 보낼 수 있어서 좋다”며 “메신저도 빠르긴 한데 컴퓨터 앞에 앉아야 하지 않느냐”라고 반문했다. 언제 어느때나 보낼 수 있는 문자메시지를 선호한다는 것이다. B군의 경우 TV를 보면서 바로 친구에게 메시지를 보낸다. ‘TV에서 연예인 누가 뭐하더라’라는 식의 메시지를 주고 받는다. 강남에 살고 있는 C양(중3)은 “길을 가다가 이쁜 거, 특이한 거, 신기한 거 보면 친한 친구들한테 찍어서 보내준다”면서 “재밌잖아요”라고 답변했다. ‘나는 직접 말하기보다 문자·메신저를 많이 사용한다’고 응답한 1318세대는 63.5%에 이른다. 하지만 대학생 세대인 1924세대는 38.7%에 그쳤다. 1318세대에게는 휴대전화가 중요하다. 특히 휴대전화의 기능 중 가장 중요한 기능으로 73%의 1318세대 학생이 SMS문자 기능을 손꼽았다. MP3와, 사진 또는 동영상 촬영은 각각 6%에 불과했다. 휴대전화의 본래 기능인 통화기능은 1.9%에 그쳤다. 휴대전화로 문자메시지를 보내고 있는 모습. 휴대전화를 갖고 있지 않으면 불안하다는 답변이 1318세대에서는 62%에 이르렀다. 휴대전화가 이들에게 분신 같은 존재가 되고 있는 것이다. 특히 여학생의 경우 70.5%가 ‘불안하다’고 응답해 높은 수치를 보였다. 즉각적인 반응을 보일 수 있는 디지털 기기가 없으면 불안하다는 것이다. D군(중3)은 “학원을 다니면서 시간이 없으니깐, 짬짬이 문자메시지를 보내는 것이 편하다”면서 “휴대전화가 없으면 너무 불안하다”고 말했다. 불안한 이유로 D군은 친구들의 대화에서 자신만이 모르는 화제가 나올 경우 바보가 된 느낌을 받는다고 고백했다. 이들의 손에서 휴대전화를 뺏는 것은 인격비하 발언 다음으로 가장 무서운 벌로 여겨진다. 1318세대는 가장 무서운 벌로 ‘인격비하 발언’을 43.1%로 손꼽았고, 다음으로 휴대전화 뺏기(15.5%), 컴퓨터 접근 금지(11.5%), 용돈줄이기(11.5%), 회초리로 때리기(10.1%), 게임금지 (6.2%)라고 답했다. 휴대전화 뺏기와 컴퓨터 접근 금지, 게임 금지 등 디지털 기기와의 단절을 무서운 벌이라고 응답한 학생이 무려 33.2%에 이른다. 인격 비하 발언, 회초리에 버금가는 벌이 되고 있는 셈이다. 하루 평균 5.3명에게 98.3건 보내 10대들은 컴퓨터를 켜면 바로 메신저를 이용, 친구와 커뮤니케이션을 갖는다. 1318세대는 쉴 새 없이 재잘거리며 행동하는 즉각성을 보인다. 이것이 휴대전화의 문자메시지 기능과 컴퓨터의 메신저 기능과 결합해 ‘퀵백’의 특성을 나타낸다. 디지털 기기가 기다림이 없는 기술과 문화, 리플과 펌문화를 선도하는 것이다. 대홍기획은 “1318세대의 이러한 즉각성이 편리성·이동성을 강조하는 유비쿼터스 기술과 결합하면 ‘스피드’에 대한 욕구가 더욱 가속될 것”이라고 말했다. 이 조사에 의하면 ‘기다리거나 심심한 것은 참지 못한다’는 응답자가 1318세대에서는 69.0%, 1924세대에서는 65.4%로 1318세대가 더 높았다. 잠시도 기다리지 못하는 1318세대의 특징인 ‘퀵백’은 ‘하루 중 잠자는 시간을 제외하고 수다를 떨거나 문자를 보내지 않고 혼자 조용히 있는 시간은 얼마나 되나’는 질문에서도 나타났다. 다른 사람과 전화·문자메시지·메신저 등의 커뮤케이션을 하지 않는 시간을 묻는 질문에 27.9%가 ‘3시간 미만’이라고 응답했고 26.5%가 3∼5시간 미만, 30.4%가 5∼10시간 이상이라고 답했다. F군(중3)은 “하루 종일 문자 안 보내고 수다 안 떨고 메시지 안 보내는 시간은 2시간도 되지 않는 것 같다”며 “계속 이야기하고 게임하고 친구들에게 문자를 보낸다”고 답했다. 1318세대는 하루 평균 5.3명과 휴대전화로 문자 메시지를 주고 받고, 평균 98.3건의 문자를 보낸다. 메신저에 등록된 친구는 평균 80.2명이고 이중 실제로 대화하는 친구는 16.4명이다. 동시에 여러 명의 친구와 커뮤니케이션을 갖는 것이다. 이 숫자는 1924세대의 하루 평균 문자메시지 상대(4.7명), 하루 평균 문자 건수 (65.8건), 메신저를 통해 실제로 대화하는 친구 수(11.3명) 보다 훨씬 높은 수치다. 강북에 사는 G군(중2)은 “한번 문자를 보내면 보통 20∼30명의 친구들에게 동시에 보낸다”며 “그중 6∼7명은 답변이 오고, 계속 문자를 주고 받으며 평균 30회는 보내야 끝난다”고 답변했다. 강남에 사는 H양(중3)은 “학교 친구들 중에 누가 무슨 일이 있었는지, 옆 학교에서 무슨 싸움이나 이슈가 있었는지 다 안다”며 “소문나는 데에는 아마 5분도 걸리지 않을 것”이라고 설명했다. 즉각적으로 반응하는 퀵백 특징에 대해 전 사이버문화연구소장인 민경배 교수(경희사이버대)는 “빨리빨리 문화는 한국인의 공통된 특성이지만 기성세대가 성과에 집착한 ‘빨리빨리’라면 10대들의 성향은 반응을 빨리한다는 의미에 가깝다”면서 “꼭지점 댄스의 경우처럼 10대들은 새롭고 신선한 것을 바로바로 흡수하고 전파하는 능력도 빠르다”고 말했다. 반응이 느린 것은 ‘불친절한’ 행위 발랄한 디자인의 스니커즈를 신은 여학생들. 한양대 정보사회학과 윤영민 교수는 “눈에 보이는 것에 즉각적으로 반응하고 상대방도 피드백을 나타내야 이들 사이에 암묵적으로 정해진 사회규범에 맞추는 것이 된다”며 “즉각적으로 반응하고 전파하는 이들 세대에서 이 규범을 지키지 않으면 같이 어울릴 수 없게 되는 것”이라고 말했다. 반응을 기다리게 만드는 것이 1318세대에게는 ‘불친절한 행동’이 된다는 것이 윤 교수의 설명이다. 윤 교수는 “기성세대의 ‘고립된 개인’은 1318세대의 ‘네트워크화된 개인’을 이해할 수 없겠지만 동일한 환경에 놓인 1318세대에게 네트워크를 끊으라고 요구한다면 이들이 견디지 못할 것”이라면서 “이들 세대가 어차피 동일한 네트워크 환경 속에 있는 만큼 누가 잘 적응하면서 효율성을 갖고 새로운 아이덴터티를 구축하는가가 더 중요한 문제”라고 분석했다. 1318세대는 WANT세대 대홍기획에서는 1318세대를 WANT(Wide Active New Teenager)세대로 명명했다. 1993년 이후 출생자로 현재 13∼18세의 중·고등학생이 여기에 해당한다. WANT세대란 명칭은 이들 1318세대가 다수 대 다수의 커뮤니케이션을 주도하고(Wide), 온라인과 오프라인을 거침없이 넘나들며 자유롭게, 열정적으로 행동하며(Active), 새로움과 다양함을 열망하는 새로운 십대(New Teenager)라는 뜻을 담고 있다. 또한 중의적인 의미로 1318세대의 꿈을 상징하고 있다. 이들 세대가 즐거움이라는 코드를 통해 끊임없이 새로움과 다양함을 원하고 갈망하기 때문이다. WANT세대는 8가지 특성으로 나타난다. 1 대 다수, 다수 대 다수를 대상으로 동시다발적으로 커뮤니케이션을 하는 뉴럴 커뮤니케이션(Neural Communication), 비주얼과 텍스트를 뛰어넘는 신언어 세대를 뜻하는 네오 텍스트(Neo-Text), 마치 벌들이 꽃에서 나오는 단물을 물어와 입으로 전하고 토해내며 벌꿀을 만드는 것처럼 자신의 생각을 또래 집단과 커뮤니티를 통해 표출하고 싶어하는 버징 컴(Buzzing Comm’), 기다림을 지루해 하고 즉각적인 반응을 기대하는 퀵백(Quick Back), 경쟁을 승리의 수단이 아니라 서로 이기는 게임으로 보는 배틀 빙(Battle Being), 사회적·도덕적 규범에 대한 불의를 참지 못하고 온라인을 통해 익명으로 정의감으로 표출하는 사이버 저스티스(Cyber Justice), 이성적·논리적 재미가 아니라 감성적이며 단순한 재미 그 자체를 즐기는 펀토피아(Funtopia), 자신의 꿈을 이루기 위해 정보를 모으고 비상을 준비하는 프티 어덜트(Petit Adult) 등이 WANT세대를 특성화한다. 대홍기획 측은 “기존 연구에서 10대들의 특성이 1 대 소수를 대상으로 커뮤니케이션하며, 경쟁을 이기는 수단으로 생각한다고 보고돼 있으나 이번 연구에서는 10대들이 1 대 다수, 다수 대 다수를 대상으로 동시다발적으로 커뮤니케이션을 하며 경쟁을 윈윈 게임으로 생각하는 것으로 나타났다”며 기존 연구와 다른 특성을 부각시켰다. 하지만 이런 특성 분석에 대한 부정적인 의견도 있다. 경희사이버대 민경배 교수는 “세대 특성을 명확하게 하는 점에서 명칭을 부여하는 것을 이해는 하지만, 광고기획사에서 X세대·N세대·P세대·W세대·R세대 등의 조어를 만들어내고 이를 구분하는 것에 대해서는 선뜻 동의하기 어렵다”고 지적했다. <윤호우 기자 hou@kyunghyang.com> - 대한민국 희망언론! 경향신문, 구독신청(http://smile.khan.co.kr) - ⓒ 경향신문 & 미디어칸(www.khan.co.kr), 무단전재 및 재배포 금지

>더보기

>접기

2006년 5월 24일(수) 오후 3:39 [세계일보]

100달러 노트북 실제 제품 공개

‘어린이마다 한대의 노트북을(One Laptop per Child, http://www.laptop.org/)’이란 목표 아래 초저가 교육용 노트북PC를 개발하고 있는 니콜라스 네그로폰테 MIT 교수팀이 실제 동작하는 ‘100달러 노트북’ 시제품을 전격 공개했다. 사용할 수 있는 시제품이 일반에 공개되기는 이번이 처음이다. 100달러 노트북이란 니콜라스 네그로폰테 MIT 교수팀이 지난해 말 북아프리카 튜니지 튜니지아에서 열린 '정보사회 UN 세계 정상회의'에서 개발도상국 교육용 PC로 최초 공개한 초저가형 노트북을 말한다. 니그레폰테 교수는 23일(현지시간) G8 7개국 태스크 포스 모임(G8 Seven Countries Task Force Meeting)에서 실제 동작하는 100달러 노트북 모델을 선보였다. 이 소식은 이날 행사에 참석한 피트 바-왓슨(Pete Barr-Watson)씨가 자신의 인터넷 사진첩(http://www.flickr.com/photos/pete/)에 자료를 올리면서 온라인을 통해 빠르게 확산되고 있다. 자료에 따르면 이번에 공개된 제품은 기존 공개 디자인과 달리 발전용 크랭크가 사라졌으며, USB 단자, 이어폰 및 마이크 단자를 보호하기 위해 화면 상단 양쪽에 스위블(swiveling)형 디자인을 채택했다. 전문가들은 “정확한 규격은 확인할 수 없지만 화면이나 키보드는 기존에 공개된 디자인보다 좀 더 작아진 것으로 보인다"고 말했다. 이에 앞서 월터 벤더(Walter Bender) 100달러 노트북 프로젝트 담당자는 지난 20일 프로젝트 진행 상황을 소개하는 글을 통해 “첫번째 15개 A테스트(A-Test) 노트북 주기판이 성공적으로 조립되어 캠브리지로 이송중이며, 500여개의 개발자용 주기판도 중국 상하이서 조립 중"이라고 밝힌 바 있다. 또 그는 “레드햇 개발팀과 함께 낸드 플래시에 들어갈 운영체제 JFFS2(Journaling Flash File System, Version 2) 파일 시스템의 배포판 크기를 줄이는데 집중한 결과 지난주 400MB였던 것을 250MB로 낮추는데 성공했다"며 “사용자 인터페이스(UI) 프레임워크 작업도 순조롭게 진행되고 있다"고 전했다. 한편 지난 5일 인텔도 ‘에듀와이즈(Eduwise)’라는 400달러짜리 초저가 노트북PC로 개발도상국 시장 공략을 선언한 바 있다. 울트라모바일 PC를 내 놓은 빌게이츠 MS 회장 역시 “100달러 노트북은 교육용으로서 가치가 없다"며 연일 강하게 비판하고 있다. 이에 맞서 네그로폰테 MIT 교수는 “100달러 노트북을 50달러까지 낮추겠다"는 파격안까지 제시하고 있어 개발도상국 교육용 PC 시장의 경쟁 구도가 한층 복잡해지고 있는 상황이다. 세계일보 인터넷뉴스부 서명덕기자 mdseo@segye.com 보도자료 및 제보 bodo@segye.com 팀블로그 http:/in.segye.com/bodo