computer

얼마 전 KLDP에 올라온 어느 글에 따르면, KBS의 어느 토론 프로그램에 나온 전문가 패널이 자그마치 “소리바다와 같은 오픈소스 운동”이라는 해괴망측한 주장을 했다고 합니다. 이런 심각한 오해가 있기 까지는, 도무지 알아 들을 수 없는 오픈소스 라이선스들이 한 몫을 하지 않았나 생각이 들었습니다. 그래서, 일반인도 알아들을 수 있는 간단하고 쉬운 오픈소스에 대한 설명을 하나 만들어 보았습니다. 🙂

우선, “소스”란 무엇인가?

오픈소스를 이해하기 위해서는 우선 “소스”가 무엇인지 개념을
알아야 합니다. “소스”는 요리할 때의 요리법이나, 그릇을 만들 때 그릇을 굽는 방법 같이, 사람이 최종적으로 쓰는 것 이전에, 만드는 사람 기준의 재료 같은 개념입니다. “소스”가 중요한 이유는, 요리나 그릇만 딱 보고서 똑같은 요리나 똑같은 그릇을 만드는 것을 간단하지가 많지만, 아무래도 요리법이나 그릇 만드는 법이 적힌 종이를 준다면 똑같은 요리를 만들기가 쉽겠지요. 따라서, 최종 사용자가 쓰는 프로그램을 만들 때, 그 프로그램을 변경하거나 개선하기 위해서는 “소스”가 필요한 것이고, 오픈소스에서는 그 “소스”를 공개하는 것을 가장 기본이 되는 원칙입니다.

그럼 소리바다는 왜 오픈소스가 아닌가?

소리바다는 소스를 공개하고 있지 않을 뿐만 아니라, 프로그램을
마음대로 재배포하거나 변경할 권리를 주지 않습니다. 즉, 요리를
만들어 놓고, 후추를 뿌려서 먹거나 치즈를 얹은 다음에 다른
사람과 나눠 먹는 것도 하면 안 되고, 더군다나 요리법은 더더욱
공개하고 있지 않습니다. 이 부분은 소리바다만 그런 것이 아니라
대부분의 상용 프로그램들은 이런 정책을 취하고 있습니다.
소리바다가 파일 전송을 지원한다는 것은 오픈소스와는 완전히
별개의 일입니다. 오픈소스 프로그램은 합법적인 저작권법 안에서
저작권자들이 자기의 의지에 따라 참여하고 싶을 때 자신이
행사할 수 있는 권리를 가지고 오픈소스로 선언하는 것이지,
아무거나 막 쓰자고 주장하는 것은 아니며 불법과는 거리가
멉니다.

그럼 오픈소스 프로그램을 만드는 사람들은 뭘 먹고 사나?

인터넷에 찾아보면 요리법이 돌아다니고, 친구들에게도 흔쾌히
자기가 맛있는 요리를 할 줄 알면 그 방법을 알려주듯이,
오픈소스는 프로그래머들이 자기 소스를 다른 프로그래머들에게
전달해 주고 같이 쓰는 것에 대해 기쁨을 느끼는 것에서 대체로
시작됩니다. 며느리도 모르는 고추장 만드는 방법을 남에게
알려주면 망한다고 생각하는 고추장 회사들은 나름대로 만드는
방법을 공개하지 않으려 할 것이고, 만드는 방법을 알려 줘도
분위기나 포장, 서비스, 추가음식 등으로 충분히 장사가 된다고
생각하는 식당들은 기쁘게 남에게 알려줄 것입니다. 오픈소스도
꼭 굳이 회사들이 목숨걸고 전사적으로 도입할 필요가 없습니다.
경영적으로 필요하다고 하는 부분은 오픈소스를 하고, 아닌 부분은
안 하고.. 오픈소스”로” 돈을 벌겠다고 하는 기업보다는,
오픈소스를 “하면서” 돈을 버는 기업이 훨씬 더 많습니다.

그릇-그릇만드는법-그릇으로 옮기는 것

오픈소스 라이선스의 종류

저작권법/특허법

오픈소스와 상용 프로그램의 공생

얼마전에 IRC하다가.. ^.^ 처음부터 시작하지 않으면 영원히 하기 힘든 세 가지..

C 프로그램에서..

• -Wall 옵션 붙이기
• valgrind에서 경고 안 나오게 하기
• i18n/m17n

구식 조직에서 여러 명이 하는 프로젝트에서..

• docstring / doxygen comment 쓰기
• 네이밍 컨벤션 / 코딩 스타일 지키기
• 회귀 테스트 하기

요즘 아르바이트를 하면서 ARM 크로스툴체인이 필요해서
여러 방법을 시도해 봤는데, 역시 크로스 툴체인 세상은
빌드 자체부터 쉽지가 않은게 빡센 뭔가가 느껴지더군요.
파이썬도 아직까지 표준 배포로는 크로스 빌드가 제대로 안
되는 것을 보면~ 흐흐.

그래서 아예 바이너리 패키지는 없는가 한참을 찾아보다가
Scratchbox라는
것을 찾았습니다. 처음에 scratchbox는 단순히 deb가 있어서
우분투에 깔기 좋겠다 하는 생각으로 깔았는데, 생각보다
좀 더 뭔가 멋지구리한 것이었네요.

scratchbox는 툴체인만 묶어놓은 것이 아니라, 바로 누르자마자
개발과 테스트를 할 수 있는 개발환경이었습니다. 처음에
깔고 나서 scratchbox 로그인 프로그램을 실행하면,
환경 설정 화면이 예쁘게 뜨는데, 그 화면에서 툴체인 종류,
에뮬레이터 종류 같은 것들을 설정해 주면 그 다음부터는
로그인할 때 자동으로 크로스 개발환경으로 셸이 떡 하고 뜹니다.
그 다음이 아주 감동인데, 리눅스의 binfmt를 이용해서
qemu-arm과 직접 연결하는 바람에, 완벽하게 타겟 환경과 호스트
환경을 섞어놓은 듯한! 그러니까.. vim, wget, grep 같이
개발 중에 많이 쓰이는 툴들은 모두 호스트 바이너리로 되어있고
uname, python, perl 같이 빌드/테스트에 직접적으로 영향을 미치는 프로그램들은 모두 타겟 바이너리로 돼서 qemu-arm으로 에뮬레이트가 자동으로 됩니다. 그래서, 파이썬처럼 빌드 도중에 빌드된 바이너리를 쓰는 까다로운 빌드 환경도 깔끔하게 크로스빌드가 가능!

(아래의 호스트는 ubuntu-i386 임)

[sbox: ~/seed/orig] > cc -v 2>&1|tail -1
gcc version 3.4.2 (release) (CodeSourcery ARM Q3D 2004)
[sbox: ~/seed/orig] > uname -a
Linux ubuntu 2.6.12-10-386 #1 Fri Nov 18 11:51:02 UTC 2005 arm GNU/Linux
[sbox: ~/seed/orig] > cc -o tseed seed.orig.c seed_*.c test.c
[sbox: ~/seed/orig] > file tseed
tseed: ELF 32-bit LSB executable, ARM, version 1 (ARM), for GNU/Linux 2.0.0, dynamically linked (uses shared libs), not stripped
[sbox: ~/seed/orig] > ./tseed
SEED-CBC encoding: 11.765 Mbytes/second
[sbox: ~/seed/orig] >

노키아에서 리눅스 기반 플랫폼 개발을 위한 프로젝트에서 쓴 것 같은데, FreeBSD 포트에도 하나 이런 걸로 만들어 봄 직하군요. 🙂

오늘 SoftExpo 2005 부대행사로 열린 오픈소스 데스크탑 컨퍼런스의 부대행사로 (-.- 여러겹;;) OSS 커미터 원정대 모임이 있었습니다. 흐흐흐. 오랜만에 강남 가려니 어찌나 먼지;; 가급적이면 앞으로 강남 모임은 삼가해야하겠다는 생각이 흐흐;;

여러 얘기가 오가는 도중에, 오픈소스 프로젝트에 참가하는 방법을 대학 커리큘럼에서 가르치는 곳은 없냐는 얘기를 어느 분이 꺼내셔서 머디 먼 집에 돌아오는 길에 멍하니 생각해서 실라버스로 한번 만들어봤습니다. 🙂 (시험 전날이라 별게 다 재미있다-.-)

과목명: 오픈소스개발실습

• 기본정보: 3학점, 주2시간 오프라인 강의
• 수강대상: 컴퓨터과학전공 2학년(2학기)
• 수업목표 및 개요: 오픈소스 개발은 비교적 쉽게 참여할 수 있으면서도 여러가지 형태의 진보된 개발 방법을 습득하고 연습할 수 있는 좋은 기회이자, 흥미를 느끼고 지속적으로 기여하는 경우 많은 경험을 할 수 있다. 일반적인 오픈소스 프로젝트들에 여러 형태로 기여하고 참여할 수 있는 방법과 그에 필요한 여러가지 기술들을 소개한다. 그리고, 실제로 관심 있는 오픈소스 프로젝트에 참여하여 실습해본다.
• 선수과목: 필수/없음, 권장/C프로그래밍,자료구조,시스템프로그래밍
• 성적평가방법: 중간(실기) 25%, 과제 50%, 퀴즈1회 15%, 수업외 참여 10% (수업기간 내에 있었던 버그보고 등의 관련 메일/URL을 제출)
• 교재 및 참고문헌: 주교재 없음
• 수업 일정:
  • 1주 – 오픈소스의 정의와 소개, 개요
    – 수강신청 확인 및 변경
  • 2주 – 개발 과정 개요
    – 일반휴학 접수 마감
  • 3주 – 버전 컨트롤 시스템: CVS와 Subversion 실습
  • 4주 – 버그 트래킹 시스템: Bugzilla, Trac, GNATS, 메일로 보고하기 실습
  • 5주 – 오픈 소스 라이선스
  • 6주 – 오픈 소스의 특징적 버그 추적 기술, 패치 제출, 스타일의 관례
    – 학기 1/3선, 퀴즈
  • 7주 – More 관례: 빌드, 배포, 버전, 문서화, 기여자 참여 과정, 번역 등
  • 8주 – 중간고사: (실습 시험) 버그 추적, 패치 제출, follow-up
    – 학기 1/2선
  • 9주 – 사례연구: 주요 오픈소스 프로젝트 2가지, 소규모 오픈소스 프로젝트 2가지
    – 수강철회기간, 졸업신청 및 연기신청
  • 10주 – 프로젝트 시작 안내 및 진행 방법 설명
  • 11주 – 진행 상황 발표: 대상 프로젝트 선정과 간단한 프로젝트 소개, 작업할 내용 소개
    – 학기 2/3선
  • 12주 – 진행 상황 발표 및 아이디어 교환: 작업할 내용의 1차 패치를 버그트래커에 제출한 후 그 내용을 소개 (11주 과제)
  • 13주 – 진행 상황 발표: 다른 사람의 패치들에 follow-up한 다음에 개선된 패치를 제출한 후 그 내용을 소개 (12주 과제)
  • 14주 – 진행 상황 발표: 11주에 제출한 자기의 패치에 대한 가급적이면 최종판의 개선된 버전을 제출한 뒤 소개 (13주 과제)
  • 15주 – 프로젝트 최종평가: 자신이 제출한 패치를 적용한 프로그램 스냅샷과 가상의 릴리스 어나운스를 만들어서 제출.
  • 16주 – (없음)
    – 기말고사 기간

으흐흐… 뭐 프로그래밍 실습 같은 비슷한 과목을 대체하는 형태도 좋고.. 그런대로 해볼만 할 것 같기도 해요 =3=33

대안언어축제에서 인기있었던 코너를 분리해서 새로운 행사로 만든 코드레이스를 했습니다. 이번에는 준비기간도 짧고, 학기중이라 자봉분들과 자주 만나지도 못하고 후다다닥해서 막 정신이 없었네요.. 리허설때도 여러가지 했어야 했는데, 학교 시험하고 겹쳐서 당일날 가서야 삽질을.. ㅠ.ㅠ

이번 대회에서는 참가자들의 프로그램에 대한 acceptance test를 계속해서 자동으로 채점을 해야했기 때문에, 자동채점 프로그램과 그를 공시하는 점수판 프로그램이 중요했습니다. 그런데, 그 전까지 특별히 제대로 돌아가는지 테스트도 못해보고 당일 아침에 별의 별 희한한 에러를 다 만나가며 수정하느라 좀 전반부 거의 대부분의 시간을 제대로 진행하지 못한 문제가 있었습니다. 대회가 진행되는 trac과 svn, 해설용 vnc 접속, 점수판, 채점들도 모두 같은 노트북에 세팅했었는데, trac과 점수판이 받아들이는 요청이 엄청나서 로그가 막 우루루루루 올라가는 판에 vncviewer 12개가 떠 있으니까.. 노트북이 로드가 80까지 올라가서 계속 멈추는 바람에 또 난감해하고.. 하여간 여러모로 해설을 할 수 있을 만한 맥락이 조성이 안 돼서 그 부분에 대해서는 정말 아쉬움이 남습니다. 그래서 이 부분에 대해서 다음부터는 해설자는 해설만 계속 하고, 옵저버와 trac/svn/스코어보드 유지를 담당하는 기술적인 자봉을 따로 둬서 해결하는 것으로 뒷풀이 때 의견이 모아졌습니다.

이번 행사에는 C++팀이 4군데, C#팀이 1군데, Python팀이 2군데, Ruby팀이 2군데, Java팀이 2군데 해서 모두 12팀이 참가를 했습니다. 생각보다 C++의 비율이 엄청 높았는데, 처음 기획 때는 동적 언어들이 너무 유리하지 않을까 해서 무척 고심을 해서 동적 언어들이 너무 유리하지 않은 방향으로 가도록 초기 문제를 조정했었습니다. 그 영향인지 동적 언어를 쓰는 팀들이 속도가 C++에 비해서 크게 나지 않았던 것이 약간 아쉽지만, 적당히 평형을 유지했던 것 같습니다. 🙂 초반기에는 중앙대 동아리에서 단체로 출전한 “밥묵자”라는 팀이 C++로 굉장한 리드를 했었는데, 이 팀에서는 다른 여러 프로그래밍 대회의 경험이 많아서 그런지, 경진대회에 적합한 코드를 빨리 만드는 것을 잘했습니다. 그런데, 후기에 타입이 여러가지로 늘어나거나 evaluation 규칙이 바뀌는 등의 기존의 디자인을 벗어나는 요구사항들이 나오기 시작하자, 역시 경진대회를 많이 연습한 팀인 연대의 “액션가면사주세요”가 엄청나게 유연한 C++ 코드를 무기로 계속 만점가도를 달려서 결국 우승하게 되었습니다.

김형용님께서 찍으신 사진입니다.

기획하던 단계에서의 생각은, 아무래도 요구사항이 많이 바뀌는데다가, 알고리즘이 크게 어려운 것이 필요한 문제가 없고 거의 디자인 문제였기 때문에 경진대회 준비팀들이라고 특별히 유리할 것은 없다고 생각했었습니다. 그런데 아무래도 문제를 빨리빨리 풀고, 발생하는 난관들을 잽싸게 해결하는 부분에서 경진대회팀들이 많이 익숙해 있어서 유리하지 않았나 싶네요. 2위를 한 “Effect”팀은 독특하게도 C#으로 출전하셨는데, MonoDevelop을 굉장히 익숙하게 다루시는 모습이 아주 인상적이었습니다. 1위가 C++이고 2위가 C#이라니 정말 충격이지요.. -O-;

다른 팀들도 다들 잘 해주셨는데, 문제 출제에서 약간 문제가 있어서 초기에 너무 요구사항들이 한꺼번에 나가서 상당히 혼란스러웠음에도 불구하고 금방 적응하고 빨리빨리 해결하고 그러셔서 적지않이 놀랐습니다. 역시 코딩 고수이 이렇게 많구나!

이제, 코드레이스 준비는 다 끝났으니(-O-;;;;), 본격적으로 다음엔 재미있는 코드레이스가 될 수 있을 것 같습니다. 좀 더 좋은 코드레이스를 위해 창준형이 말한 두가지가 집에 오는 길에 계속 생각이 났습니다. 아직 마땅한 좋은 생각은 없지만~ 계속 생각해 봐서 2회는 더욱 좋은 대회로.. 🙂

• 1,2위 팀 뿐만 아니라 모두가 집에 가면서 나도 이겼다 하는 생각을 갖고 돌아갈 수 있게 하는 방법은 없을까
• 축구나 야구처럼 선수들이 재미있기 보다는 관객들이 즐길 수 있고 배울 수 있는 흥미로운 대회를 만들 수는 없을까

몇가지 대회 자료입니다. (여기 있는 것 외의 trac 안의 데이터 등은 곧 소프트웨어진흥원 홈페이지에 공개될 예정입니다.)

• 참가자 소스 저장고 (svn co 명령으로 접근 가능합니다.)
• 요구사항 세트
• 팀 좌석 배치도 및 팀원 명단
• 점수판 프로그램 소스
• 채점 프로그램 소스
• 최종 채점표
• 최종 순위별 점수판

물론 채점 프로그램과 점수판 프로그램은 zlib/libpng 라이선스을 적용하여 다른 곳에 사용하실 수 있습니다.

틀린 부분을 찾으시면 알려주세요. 🙂

최근 몇년새에 CPU가 하도 빨라져서 그런지, 범용VM이 트렌드로
떠오르고 있는 듯 합니다. 90년대 말의 Java의 유행의 뒤를 이어서
.NET(ECMA CLI)가 여러 언어들이 동시에 통합된 인터페이스로 라이브러리를 공유하는 것을 VM의 주요 특징으로 뽑아내기 시작한 것이 대중적으로는 그 시초라고 볼 수 있겠습니다. 한동안 GNU lightning이나 Psyco같은 VM을 포함하지 않은 JIT 시스템이 뭔가 비전을 제시해줄 것만 같았지만, 결국엔 JIT에서 높은 효율을 내기 위해서 빠질 수 없는 타입 인퍼런스, 메모리 참조 단축, 가비지 컬렉션 같은 것 때문에, 돌아가는 상황을 완전히 제어할 수 있는 VM 수준의 것이 있어야 안정하게 좋은 성능을 낼 수 있었기에 결국은 이렇게 범용 VM의 유행이 왔을 것이라고 봅니다.

Parrot

오픈소스 범용VM으로 처음 알려지기 시작한 것은 아무래도 parrot이라고 할 수 있겠습니다. parrot은 스크립트 언어를 위한 범용VM을 표방하고, 인스트럭션들을 굉장히 스크립트 언어의 주요 작업들에 직관적으로 대응될 수 있을 정도로 간단한 환경을 만들어 주었습니다. 그렇지만, 너무 원대한 꿈을 꾸면서 만든터라, 새로운 아키텍처로의 이식이 다른 VM들에 비해서 쉽지 않고, 내부적인 구조가 너무 어려워서 처음 보는 사람들이 길을 잃어버리기 좋은 환경이라 새로운 개발자의 참여가 적어서 결국은 지금의 상태처럼 다른 사람들은 베이퍼웨어라고 부르지만, 자기들은 곧 릴리스한다고 우기는 상태가 된 것 같습니다.

Mono

그 다음으로 뜬 범용VM은 Mono라고 할 수 있겠는데, 물론 Mono는 ECMA CLI의 스펙을 구현한 것이기 떄문에 VM의 디자인은 독창적인 것은 아니지만 Microsoft제품과의 호환성을 충분히 확보함으로써, 일단은 사용자 뿐만 아니라 개발자들의 관심을 많이 얻었습니다. Mono는 Parrot이 헤메는 과정을 어느정도 보고 나서 개발이 되었기 때문에, 초기부터 너무 큰 꿈을 그리는 것보다 돌아가는 작은 것들을 엮어놓고 나중에 좋은 것으로 부분 부분을 교체하는 방식으로 발전이 되어 와서 결과적으로 쓸만한 것이 나오는 시간이 훨씬 적게 들었고, 그에 따라 지금과 같은 성공을 거둘 수 있었습니다. Mono는 가비지 콜렉터로 boehm-gc를 쓰고 있는데, 이게 겉으로나 소스에서나 보이는 것에 비해서 훨씬 포터블하지가 못합니다. 포팅하기도 쉽지가 않고요.. 그래서, 결국은 Mono는 마이너 플랫폼에 포팅할 때 boehm-gc가 상당한 걸림돌인데, 곧 Mono에서 자체적으로 만든 gc를 도입한다고 하니까 기대를 걸만 하겠습니다. 🙂

LLVM

LLVM은 2002년 정도부터 다른 VM들과는 달리 최적화를 위한 플랫폼이 주요 목적으로 개발되었습니다. 이 VM을 만든 사람은 석사,박사학위 논문의 주제로 LLVM을 썼는데, 박사학위 논문은 “광범위 데이터 구조 분석과 최적화”라는 제목인데, 그에 걸맞게 LLVM은 머신 코드를 실행하면서 데이터 구조적으로 발생하는 여러가지 최적화 가능 지점들을 자동으로 발견해서 최적화를 수행합니다. 대표적인 예로 strcat의 두번째 인자로 변하지 않는 스트링 상수가 들어가는 경우에 memcpy로 교체해버리는 것이 있는데, 이런 것이 컴파일타임에 수행되는 경우 상당한 부작용을 유발할 수도 있다는 점을 생각해 보면, valgrind같이 틈새시장을 굉장히 잘 노린 기발한 착상이라고 할 수 있겠습니다.

LLVM은 valgrind처럼 머신코드를 직접 받아주는 것은 아니고, LLVM의 바이트코드로 생성된 코드를 만들어주는 C/C++ 등의 컴파일러를 사용해서 컴파일하면 그 코드를 실행하면서 분석하고 최적화를 해 주게 되어있는데, 최적화 자료를 토대로 컴파일할 때 아예 머신코드로 컴파일해버리는 기능도 있어서, mono의 머신코드 컴파일러보다도 한단계 더 발전한 것이라고 볼 수 있습니다. LLVM은 현재 PyPy같은 여러 다른 언어 프로젝트에서도 LLVM 코드를 생성하는 기능이 들어가고 있다는 점에서 많은 사용자들을 확보해가고 있어서 앞으로 아주 장래가 기대가 됩니다.

NekoVM

NekoVM은 올해 나온 것이라 다른 것들에 비해서 상대적으로 역사가 짧습니다. NekoVM도 Parrot 만큼이나 굉장히 고수준의 인스트럭션을 갖고 있어서 스크립트 언어를 만들기가 굉장히 간단하게 되어 있습니다. 그리고, NekoVM은 VM 코드가 라이브러리 코드로 단지 50KB 내외밖에 안 된다는 점에서 고속의 실행 코드가 필요한 고수준 도메인 언어에서 뭔가 아주 쓸모가 있어 보입니다. 그런데, NekoVM은 Parrot보다도 더 고수준으로 올라가 있어서 속도를 위해서는 저수준 VM보다는 약간의 희생이 있고, 런타임 최적화를 수행하지 않기 때문에, 장기간 돌더라도 크게 빨라지지는 않습니다. 게다가, 라이선스가 다른 VM과는 달리 GPL이 적용되어 있기 때문에, 기업 사용자들이나 X11/BSD 계열 라이선스를 쓰는 오픈소스 프로젝트들에게 어필하기가 어렵다는 점이 걸림돌로 작용합니다. 만약 GPL을 감수할 수 있는 환경이라면 특히 웹 애플리케이션의 템플릿용 언어로는 굉장한 효율을 발휘할 수 있을 것 같네요.

이제 VM이 이렇게 점점 늘어감에 따라서, 새로운 언어를 만들거나 독특한 동적 실행환경을 만들기에는 점점 좋아지고 있습니다. DSL(Domain Specific Language)로 프로그램 내부에 스크립팅 기능을 추가하면서도 빠른 속도를 유지할 수 있고, 여러가지 다른 언어들을 하나의 VM 위에서 서로 호출하고 참조할 수 있다는 점에서 옛날 패러다임과는 다른 색다른 시도를 할 여지가 많아지고 있는 것 같아서 기대가 됩니다! 🙂

알림: 이 외에도 GNU Portable .NET이나 여러 오픈소스 JVM들이 있겠지만, 거기는 관심이 없어서 자세히 안 본터라 안 적었습니다. =3=3

다음 주 토요일에 공개SW 개발자 경진대회라는 이름으로 지난 대안언어축제 때 인기를 누렸던 코너 코드레이스가 다시 열립니다. 이번에는 코드레이스만 독립해서 하기 때문에, 시간도 넉넉하고 준비도 어느 정도 완결된 상태에서 진행될 것 같아서 손에 땀을 쥐는 대회가 아닐까 합니다. 상금도 많고요~ -O-;

선수 참가 조건은 이렇게 되어 있습니다.

• 최소 2인 이상 최대 6인 이하 팀
• 개발시 대회장에서 제공되는 리눅스 환경의 컴퓨터를 사용해야 함
• 상용 소프트웨어를 개발 도구로 사용할 수 없음

물론 선수 외에 방청객으로도 참가가 가능하고, 방청객이 현장에서 선수로 전환하는 것도 자유로이 가능하니까 얼마든지 즐기러 와 주세요~

저는 이번에 해설로 참가하게 되었는데, 지난번에 얼떨결에 하느라 온게임넷에 비해서 좀 지루한 경향이 있었는데 이번에는 온게임넷에서 흥분만 뺀… (그럼 남는게 있나..) 그런 것을 한번 해 볼까.. 하는 -O- (그 전날과 다음다음날에 시험이 있어서 과연 제 정신에 할 수 있을지는 잘 모르겠군요;;)

참가 신청이 며칠 남지 않았으니 얼른 팀을 꾸려서 신청해 주세용~ (위의 링크 참조)