구글 android 뒤에서 들리는 Sun의 곡소리

권순선의 이미지

제목을 조금 낚시성으로 뽑아 보았습니다. :-) 얼마전 공개된 구글 android에는 dalvik 이라는 다소 희한한 이름의 Java VM이 올라가 있습니다. 이것은 user application 관점에서는 매우 핵심적인 부분입니다. 왜냐면 android의 app는 java로 만들어서 올리게 되어 있기 때문입니다. dalvik java VM은 java 코드를 android 폰 위에서 돌아가도록 한 것이고요. 구글이 이걸 왜 넣었냐면 개발자가 android 폰 위에 proprietary application을 "자유롭게" 올릴 수 있도록 하기 위해서입니다.

원래 proprietary application을 자유롭게 만들 수 있는것 아닌가? 하고 생각하실 수 있는데 사실은 그렇지 않습니다. 이것을 이해하기 위해선 Sun이 java를 오픈소스화한 것을 좀더 살펴보셔야 합니다. Sun은 얼마전 java를 GPLv2로 오픈소스화하였습니다. LGPL이 아니고 GPL입니다. 즉 java 그 자체뿐만 아니라 java 컴파일러 등과 링크되는 java application도 모두 GPL이 되어야 한다는 뜻입니다. 이렇게 되면 아무도 java로 proprietary app를 못만들겠죠?

그래서 Sun은 java를 GPLv2로 오픈소스화하면서도 Java SE에는 예외를 허용하여 java로 짠 application은 GPL이 아니어도 되도록 하였습니다. 그런데 이 예외가 ME(Mobile Edition)에는 허용되어 있지 않습니다. 따라서 android 폰이 Sun의 Java ME를 이용하게 된다면 구글은 app가 proprietary가 될 수 있게 하기 위해 Sun과 별도의 계약을 맺었어야 할 것입니다. 수많은 핸드폰 관련 개발사들이 Java ME를 사용하면서 Sun에 이 예외조항(proprietary application을 올릴 수 있다는...)을 허용받기 위해 로열티를 지불하고 있을 것입니다. 그렇지 않으면 GPLv2로 예외가 없기 때문에 ME용 app도 모두 GPLv2가 되어야 합니다. 이게 바로 Sun의 핵심적인 수익원입니다. 일종의 듀얼 라이센스라고도 볼 수 있죠. 구글은 당연히 이게 싫겠죠. Sun에 묶이게 되니까... 그래서 Sun의 Java ME 관련 GPL의 의무사항을 피해가기 위해 dalvik java VM을 별도로 개발해서 넣은 것입니다.

android 플랫폼의 핵심은 누가 뭐래도 사용자들의 눈에 보이는 application을 만들 수 있는 framework일 것이고 그 핵심에는 이 dalvik java VM이 있습니다. 구글이 아파치 라이센스로 내놓겠다고 한 것에는 이 dalvik VM이 분명히 포함될 것입니다. (아직은 정식 버전이 아니라 android 전반적으로 라이센스가 정해지진 않았습니다.)

다만 Sun 입장에서는 dalvik 때문에 자기네들의 주요 수익원(Java ME)이 날아가게 생겼으므로 조만간 어떤 식으로든 법적인 대응을 할 것으로 생각되고, 관련해서 IP 분쟁이 예상됩니다. 핸드폰 개발사 입장에서는 이 dalvik VM이 쓸만하고, 기존 application들이 문제없이 잘 동작하며, Sun과 지적재산 관련해서 문제가 없는 것이 확인된다면 향후 핸드폰에 들어가는 java VM을 이 dalvik으로만 교체해도 개발사들이 Sun에 제공하는 로열티를 내지 않아도 되어 엄청난 금액을 절감할 수 있을 것입니다. Sun의 입장에선 당연히 초난감한 상황이 되는 거고요.

아마 지금쯤 Sun에서는 난리가 났을 겁니다. 관련 업계에 계신 분들의 많은 의견 부탁드립니다... :-)

업데이트: 다시 생각해 보니 Sun 입장에서도 그다지 손해볼 것이 없네요. http://kldp.org/node/88218#comment-417929 를 참고하세요...

댓글

cwryu의 이미지

여기 보면 잘 정리되어 있네요. http://www.betaversion.org/~stefano/linotype/news/110/

조금만 인용해 보면

Quote:
Dalvik은 가상머신으로 자바나 .NET VM과 같지만 구글이 직접 만든 가상 머신입니다. 다른 누구에게도 허락을 받을 필요 없이 오픈소스로 만들 수 있습니다. (음, 적어도 당장은 그렇습니다. 나중에는 빌어먹을 양의 지적재산권 관련 소송이 잇따르겠지요. 썬과 마이크로소프트는 몇년전에 바로 이러한 가상 머신 기술과 관련된 상호 지적재산권 협약에 서명했거든요. 그렇긴 하지만 IBM은 이미 메인프레임을 만들기 시작했을 때부터 메인프레임용 에뮬레이션 코드를 작성했다는 거!)

하지만 안드로이드의 프로그램은 자바로 작성되어 있고, 자바용 IDE를 사용합니다. (이클립스 플러그인도 있죠) 이 IDE는 자바 코드를 자바 바이트코드로 컴파일하는 게 아니라 Dalvik 바이트코드로 컴파일합니다. (이런, 썬이 드디어 이런 사건을 목격하게 되는 군요!)

자, 그래서 안드로이드는 자바 플랫폼의 문법과 (다시 말해서 자바 "언어"를 사용합니다. 자바 프로그래머가 편하게 사용할 수 있고, IDE에서 편집도 수월하겠죠.) 자바 SE 클래스 라이브러리를 사용합니다. 하지만 이 프로그램을 전화기에서 실행할 때는 자바 바이트코드나 자바 가상 머신을 사용하지 않습니다. (아 참, 게다가 안드로이드에서 사용하는 자바 SE 클래스 라이브러리는 아파치 Harmony예요.)

밑에 "Update and Errata"에 "SDK는 직접 Dalvik 코드로 컴파일하는 게 아니라 한번 컴파일한 자바 바이트코드를 Dalvik 바이트코드로 변환한다"라고 써 있네요.

----
익명이나 오래전 글에 리플은 무조건 -1

권순선의 이미지

흠... 결국 기술적으로 얼마나 Sun의 IP를 피해갈 수 있느냐가 관건이 되겠네요. Sun의 대응이 정말 궁금합니다.

권순선의 이미지

좀 생각해 보았는데 Sun 입장에선 그다지 나쁠 것이 없습니다.

핸드폰 제조사들의 로열티 절감 가능성은 Sun이 Java 관련한 IP를 모두 포기하지 않는 한 Sun으로부터 소송을 당할 가능성이 항상 있으므로 실제 실현 가능성은 낮습니다. 구글만이 아니라 이 dalvik VM을 따로 탑재한 제조사도 Sun이 침해혐의로 고소할 수 있는데 어느 핸드폰 제조사가 함부로 가져다 쓰면서 Sun에 로열티를 안주려고 시도할까요.

따라서 구글과 Sun은 android 플랫폼으로부터 발생한 수익(아마도 광고)을 분배하고 그 대신에 android의 dalvik VM에 대해서만 Sun이 GPL 예외를 허용하는 식으로 합의가 될 것으로 생각합니다. (이미 협상을 해 놓았을지도…)

그러면 Sun은 기존 핸드폰 제조사들로부터 받는 로열티 외에 구글로부터도 추가로 수익을 챙길 수 있으니 좋고, 구글은 android 플랫폼 확장에 커다란 장애가 없어지니 좋습니다. GPL 예외 범위(Sun이 로열티를 받을 수 있냐/없냐)를 명확히 하기 위해서 아마 android 폰 인증 제도(이 핸드폰은 android를 사용했고 구글이 Sun에 수익 일부를 제공했으므로 Sun이 고소하지 않겠다는 것을 보증하는...)도 뒤이어 생기겠죠.

하지만 핸드폰 제조사 입장에선 결국 이게 오픈 플랫폼이고 dalvik이 아파치 라이센스라고는 해도 이러한 문제점 때문에 android에 lock-in되기만 하지 dalvik만 쏙 빼먹기는 어렵게 될 것으로 생각합니다. android에서 dalvik을 빼면 앙꼬없는 찐빵인 셈이고요.

생각하면 생각할수록 놀라운 전략입니다.

권순선의 이미지

정말로 곡소리가 나고 있는 곳은 Sun이 아니라 MontaVista, WindRiver 등의 임베디드 리눅스 관련 회사들일 것입니다. 돈을 받고 팔 수 있는 소프트웨어의 영역이 점점 사라지고 있습니다...

서영진의 이미지

TrollTech, ACCESS, 저희 회사(미지 리서치) 그리고 브라우저 회사들이 될 것 같습니다.
그렇지만 사견으로는 android 플랫폼이 2-3년 내에 시장에 안착할 것 같지는 않습니다.
그후는 급변하는 IT 상황상 또 어떻게 변할지는 모르구요 :-)

권순선의 이미지

그렇네요. linux os 위에 일부 proprietary sw stack을 탑재해서 차별화를 꾀하고 있는 업체들이 더 전전긍긍하고 있겠군요. 저 역시 최소 1년, 최대 2-3년 정도의 시간적 여유는 있다고 봅니다. 다만 구글도 놀고있지만은 않을 테니 그때쯤이면 또 다른 업체가 완전히 새로운 전략을 선보이기도 하겠지요. 그 전략을 상상해 보는 것도 재미있을듯...

엠브리오의 이미지

구글의 행보를 보면 이미 모든 조건을 갖추어 놓고, 혹은 모든 소프트웨어가 동작하는 것을 확인한 후 발표하는 전략을 취해왔습니다.

안드로이드 플랫폼을 발표하겠다고 한것은 이미 모든 물밑 작업은 진작에 끝났다는 걸 의미하는 거겠죠.
마이크로 소프트처럼 Windows 시리즈를 언제쯤 발표하겠다고 미리 공언해 놓고 출시를 계속 미루는 미련한 짓은 하지 않겠다는 계산이 깔려있습니다.

SDK를 발표한것만 봐도 왠만한것은 거의 다 구동되도록 되어 있는것을 보면 표면적으로는 아직 베타라고 소개하고 있지만 할만한것은 다 이미 했다는 뜻입니다.

권순선님의 지적대로 아마 기존의 임베디드 리눅스 관련 회사들은 최대의 위기를 맞을것 같습니다. 핸드폰은 일년에 약 10억개가 생산되는 엄청난 갯수를 자랑하는 제품군입니다. 안드로이드 플랫폼이 휴대폰의 표준OS로 굳어질 경우 Symbian, Windows Mobile 도 타격이 크겠지만, 여러개로 흩어져 존재했던 모바일용 임베디드 리눅스 업체는 아예 사라질지도 모르겠습니다.

방법은 두가지일겁니다. 모바일이 아닌 다른쪽에 발길을 돌리던지, 아니면 안드로이드 플랫폼에 적극적으로 동참해서 10위권 안에 들던지.. 갈수록 살아남기 힘든게 기업의 현실입니다.

아무리 구글이라고 그런 임베디드 리눅스 기업의 현실까지 감안해 주긴 어려울겁니다.

권순선의 이미지

기술지원에 대한 수요는 여전히 있을 것이므로 약간의 틈새시장은 계속 존재할 것입니다. 다만 그렇게 될 경우 자기 제품/플랫폼이 없고 플랫폼에 대한 주도권이 전혀 없는 상태에서 끌려가기만 하겠지요.

tristansong의 이미지

순선님 이번 구글의 모바일 행보에 누구보다 많은 관심을 가진 걸로 보입니다.

아마 무슨 이유가 있는 것 같은데, 이건 제 개인적인 호기심인데, 혹시 다니는 회사의 정책에 관련된 것입니까, 아님 개인전인 관심사입니까?

뭐 개인적인 질문인데 답을 안하셔도 괜찮구요, 다시 한번 저 개인적인 호기심입니다.

권순선의 이미지

개인적인 관심입니다. 재미있는 부분이 많아서요... :-)

poss의 이미지

이쪽 업계에대해서는 별로 아는바가 없습니다.
그런와중에 궁금한점이 생기는군요.

국내 휴대전화 생산업체들이 현재 사용하는 플랫폼을 버리고 구글이 만든 플랫폼으로 이동할 가능성이 있을까요?

codebank의 이미지

국내 휴대전화 생산업체는 별로 상관 없을거라고 생각합니다.
사용하는 플렛폼도 다르다고 알고 있고요...
Google이 우리나라만을 위해서 저런것을 생각하는 것도 아니고...
저 내용은 외국을 기준으로 생각하시면 됩니다.
외국에 휴대전화를 수출하는 회사가 있다면 그 회사도 참고할 내용이겠지만 사실 생산업체에서는
환경만 제공하는 거니 결국에는 application을 작성하는 회사가 고민해야할 내용같네요.

논외입니다만 결국에는 프로그램으로 밥벌어먹고 살기가 점점 어려워지는 것 같네요. :-)
------------------------------
좋은 하루 되세요.

------------------------------
좋은 하루 되세요.

오호라의 이미지

제 의견으로는 우선 걱정(?)하시는 만큼은 안드로이드가 성공하기 힘들 것 같습니다.

불안요인

첫째, 출시가 늦다. 2008년 하반기
둘째, 내년이면 삼성..등 리눅스폰을 본격적으로 출시한다.
셋째, 생각외로 복잡한걸 싫어하는 사람이 많다.
넷째, 구글은 어디까지나 소프트웨어회사!
다섯째, J2ME = VM = 라이센스!

성공요인

첫째, SDK
둘째, JAVA
셋째, 구글 소프트웨어
넷째, OpenGL|ES + WiFi + bluetooth + Camera + Game + SQLite
다섯째, homebrew, DIY

Hello World.

지리즈의 이미지

현재의 휴대전화식의 폐쇄적인 소프트웨어 방식은 언제인가는 한계에 도달할 것으로 보입니다.

구글이 노리는 것이 그것이죠.

구글은 애플처럼 모바일폰을 만들지는 못합니다. 하드웨어관련된 노하우가 없기 때문이죠.
개발도 그렇고 마케팅도요.

윈도우의 IE를 가장 처음 열면 MSN이 나오고, IE가 DNS resolve가 실패하면 MSN으로 넘어가 검색되고..
SK폰을 사면, 모바일폰 포털이 Nate가 되는 것 처럼

플렛폼 종속적이고 폐쇄적인 환경이 모바일쪽에서 지금처럼 계속된다면
커가는 모바일시장에서 구글의 입지는 자꾸만 적어지지요.

이부분에서 구글이 세련되게 대처한다는 생각이 드는게,
애플처럼 구글폰을 만들어 파는 것이 아니라,
아에 이러한 플렛폼 종속적이고 폐쇄적인 모바일 플렛폼을 현재의 PC처럼 개방시키려고 한다는 것입니다.

물론 Sun에 대한 구글의 힘겨운 싸움이 시작될지도 모르지만,
구글다운 행보라는 생각이 듭니다.

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

thyoo의 이미지

국내에서는 WIPI 규격으로
CP가 MNO나 칩셋에 의존하지 않을 수 있었는데,
(일본의 경우 도꼬모의 Doja, 퀄컴의 BREW등)
구글폰이 업계 표준이 된다면 CP가 전세계로 마켓을 크게 잡을 수 있겠군요.

* Dalvik VM에 대해서 좀 찾아 봤읍니다.

http://groups.google.com/group/android-developers/browse_thread/thread/a466b9d72fe2321f
Jingtao Wang이라는 사람 얘기로는
Dalvik의 jar class 파일을 열어서 바이트 코드를 확인한 결과
JAVA하고는 100%로 호환되는 코드가 아니더라.
dx로 최적화하는 게 아닌가 생각한다.

구글 관계자의 언급인 듯.
http://groups.google.com/group/android-developers/msg/a57b46be8e21ead5?
안드로이드 SDK는 현재로서는 JAVA에만 촛점을 맞추고 있다.
C/C++ 네이티브 지원을 배제하고 있지는 않다.

___________________________________
Less is More (Robert Browning)

___________________________________
Less is More (Robert Browning)

익명 사용자의 이미지

우리나라에 있어서 CP 대부분이 MNO의 그룹사이기도 하고
CP로부터 상당한 비율로 레브뉴 쉐어를 하고 있기 때문에
MNO로서는 누구라도 CP로 진입해서 자신의 수익을 빼앗을 수 있는
구글 OS를 꺼려할 수 밖에 없읍니다.

MNO가 단말기 시장을 포함하는 먹이 사슬 정점에 있는
현 구조를 깨뜨릴 어떤 압력이 있기 전까지는
이통사가 자발적으로 안드로이드 채택 하기가 어렵겠읍니다.

외국의 경우에도 대체로 비슷할 것 같습니다만..

익명 사용자의 이미지

구글 android 가 확산되면 기존의 핸드폰 제조업체의 위상이 어떻게 될까요?

소프트웨어 플랫폼이 생기고 확산되고,이를 통해서 KTF, SKT등의 사업자에
공통적인 방식으로 접근이 가능해지면..
신규 핸드폰제조업체의 진입장벽도 낮아진다는 말인데..

PC가 표준화되면서 대기업에서만 만들던 PC를 중소기업에서 만들 수 있고,
나중에는 일반 사용자가 조립까지 가능하게 된 것 처럼..
핸드폰도 그렇게 되는 것은 아닐까요?ㅎㅎ (핸드폰은 사이즈가)

결국은 Google이 플랫폼 잡고,
Chip회사들이 Goole 플랫폼에 바로 붙을수 잇는 Chipset 만들고,
삼성이나 LG는 거의 조립 수준
이 되지 않을까 생각되는데...

어떻게들 생각하시는지..

@궁금한게 있는데요, 삼성은 핸드폰 만들때 자체적인 플랫폼이 있나요?
아니면 매번 개발할때 마다 개발팀이 처음부터 끝까지 다시 다 만드나요?

권순선의 이미지

좋은 점을 지적하셨습니다. 기존에 가지고 있는 브랜드가 없거나 혹은 약한 업체들의 시장 진입 장벽을 낮추는데 어떤 형태로든 일조할 것으로 보입니다. 업체들은 어떻게든 차별화할 요소를 찾기 위해 골몰할 것인데 안드로이드가 UI를 포함한 전체 SW stack을 제공한다고 하니 최소한 안드로이드 기본 UI보다는 더 좋은 것을 집어넣어야 할 것입니다만 에뮬레이터 화면으로 봤을 때는 그냥 그대로 넣어도 괜찮다 싶은 생각이 들더군요. 명확한 차별화 요소를 찾아내지 못한다면 핸드폰도 PC처럼 결국 상당부분 표준화되면서 가격경쟁이 더욱 심화되지 않을까요. 제품의 차별화가 어렵다면 결국 남는 카드는 가격뿐이니까...

modestcode의 이미지

Quote:
얼마전 공개된 구글 android에는 dalvik 이라는 다소 희한한 이름의 Java VM이 올라가 있습니다.

구글은 이것을 자바 VM이라고 부르지 않고 있습니다. 위에도 나온 링크와 몇몇 관련 글을 읽고 어설프게 짐작컨데 아마 이것이 IP를 피해가는 핵심이 아닌가 생각합니다.

제 생각엔 안드로이드로 인해,
휴대폰 제조 업체 +
모바일 플랫폼 업체 -
모바일 어플리케이션 업체 +
모바일 유저 +
이지 않을까 조심스럽게 짐작해 봅니다.
기존 휴대폰 제조 업체의 경우 안드로이드가 PC시장과 같은 호환성을 보장해 준다면 결국 파이를 넓혀주기 때문에 혜택을 볼 것인데 소규모 업체에서는 초기 진입 장벽이 낮아져서 입지가 커지지만 장기적으론 플랫폼에서 차별화가 더욱 어려워지기 때문에 특화된 플랫폼과 결합해서 별도의 시장을 개척하도록 만들 것이라고 생각합니다. 흔히 플랫폼까지 소유하고 있는 대규모 업체에서는 단순히 안드로이드 호환성만을 제공함으로써만도 시장이 커지기 때문에 경쟁력이 더욱 커지지만 어플리케이션 보다는 플랫폼 호환성과 성능이 주요 이슈로 부각할 것이라고 생각합니다. 기존 플랫폼 업체는 안드로이드를 채용하는 업체가 늘어날수록 입지가 줄어드는 것은 자명하고, 결국 안드로이드 어플리케이션을 실행가능하도록 압력을 받을 것입니다. 나아가 단지 안드로이드 플랫폼을 이식하는 일로 전업해야할 수도 있겠지요. 어플리케이션 업체로선 역시 시장이 커지고 기존 어플리케이션을 안드로이드로 포팅하는 것이 어렵지 않을 것이기에 혜택을 볼 것이고 유저들은 훨씬 다양한 어플리케이션과 호환성으로 인해 선택의 폭이 넓어 질 것입니다. 파이썬이나 루비 개발자들은 Jython이나 Jruby로 모바일 환경에서도 입지를 넓힐 수 있을 것 같습니다. 그러나 개방된 안드로이드 플랫폼의 호환성을 깨뜨리는 업체가 있다면 어플리케이션 개발자들로서는 아주 짜증나는 일을 많이 해야할 수도 있을 것 같습니다. 이것이 마치 리눅스가 여러 하드웨어에서 돌아가는 것과 같은 효과와 비슷함을 생각할 때 흥미롭습니다.
Sun으로서는 좀 애매할 것 같습니다. 왜냐면 현재로선 잘 되면 자바 시장을 키워줄 것 같지만(이미 충분히 큰 것 같지만) 이것을 온전히 Sun의 자바라고 말할 수 없기 때문입니다. 파이가 커질수록 선의 자바라고 말하게 할지 법정에 세울지 결정해야할 때가 가까워 질 것 같습니다. 파이가 커지고 나서 싸울 때는 아파치 라이센스로 공개한 구글뿐만 아니라 실질적으로 커스터마이징해서 사용하는 각 벤더들과 해야하기에 위험부담이 크다고 생각합니다. 또 마냥 커지고 나선 구글이 (현재도 보장은 안 하지만) 자바 언어 자체의 호환성을 깨뜨려도될만큼 되고 나면 Sun으로선 할 것이 없기 때문에 그 전에 행동을 취할 가능성이 높다고 생각합니다. 그러나 Sun 내부적으로 확신이 있다면 가능한 늦게 제기할 것 같습니다. 다만 구글이 노벨처럼 타협하거나 마이크로소프트 처럼 질싸움을 봤기 때문에 그런 것을 피해서 시작했을 거라고 생각하지만 각 벤더들이 그런 위험부담을 떨쳐버릴만큼 구글을 믿고 동참하느냐가 문제겠네요. 이것은 구글이 대표로 싸워주거나 라이센스 관련 문제가 발생할 때 보전해준다면 충분할 것 같습니다. 아니면 세르게이 브린이 걸은 천만달러에 도전하는 것도 충분히 재밌다고 생각했다면 구글로서는 다행이겠습니다.
어쨌든, 관건은 Sun이 아니라 기존 제조업체를 어떻게 끌어 들이느냐인 것 같습니다. 핸드폰에 기본 탑재 안 된 플랫폼을 일반 유저들이 쓸리 만무하니까요. 안드로이드와 기존 플랫폼의 저울질은 기존 플랫폼의 어플리케이션들이 가져다주는 수익을 안드로드에서도 쉽게 가져올 수 있고, 플랫폼 로열티도 없다면 끝날 것 같습니다.

엠브리오의 이미지

결국엔 핸드폰도 User Customized 된 제품이 등장하는 것이 궁극의 목표라고 보여집니다.

사용자가 탑재될 하드웨어 및 소프트웨어를 지정하여 개인의 구미에 맞는 핸드폰 제품을 주문생산하는 시대가 곧 도래하겠지요. 구글의 행보는 이러한 시도의 전초전이라 보여집니다.

소프트웨어 SDK를 오픈한다는 의미는 사용자 및 개발자에게 원하는 기능을 선택하거나 새로 개발할수 있는 폭이 훨씬 넓어진다는 것을 뜻합니다.

나중엔 아마도 이렇게 되겠지요.

핸드폰 주문서.

하드웨어
1. 영상통화 기능 필요없음.
2. IrDA빼고 블루투스 넣어줄것.
3. 무선랜 반드시 탑재할것.
4. 커넥터는 MicroUSB대신 표준 20핀으로 할것.
5. 카메라 필요없음.
6. GPS 반드시 필요.

소프트웨어
1. 무선랜이 끊어질경우 자동으로 3G망으로 넘어가도록 하지 말것.
2. VoIP 소프트웨어 반드시 탑재할것.
3. 구글과(캘린더, 이메일..) 연동되는 소프트웨어 탑재요망.
4. 국내 포털 사이트와의 연동은 필요없음.
5. 한글,중국어(번체), 일본어, 영어, 순으로 로케일 데이터 넣어줄것.

그럴듯해 보이나요? ^^;

오호라의 이미지

저렇게만 해준다면...

밴더 한두개빼고 전부 망할듯...^^;

Hello World.

오호라의 이미지

밴더들이 유저를 얼마나 생각해줄지 모르겠습니다...

구글같은 다국적 무적기업이야. 단말기팔아서 먹고 살생각을 안할테지만...

암튼.

외국에서 성공하고, 국내에서 실패할듯 합니다. ㅠㅠ

국내 악덕통신사들은 유명하죠. 무선망 공개건! 3사 독자플랫폼(?)

모바일업체에서 진취적인 프로젝트를 진행 해볼려고 해도 대부분 통신사의 귀차니즘(돈?)으로 인해서 무산되고...

국내 밴더중 톱인 LG, 삼성에서 과연 구글님의 뜻을 따를지...

Hello World.

galien의 이미지

휴대폰 제조회사 및 이동통신사의 진입 장벽으로 안드로이드가 국내에 상륙하는 일은
일어나지 않을 것 같아보입니다.

구글이 진정한 영향력을 미치는 것은 구글 검색이라기 보다는 페이팔, 구글 맵, 블로그, 피카사 등의
서비스들의 연계 플레이 덕분일 텐데요, 미국 이외의 국가에서는 미국만큼 위력을 발휘하기 어렵기 때문에

세계에서 가장 큰 찻잔(미국)이라 하더라도 결국 대한민국 소비자에게는 "남의" 찻잔 속의 태풍이 되지 않을까
생각합니다.

샘처럼의 이미지

이쪽 분야는 잘 모릅니다만,,
wibro대신(?) WCDMA가 대세가 된다면 gsm방식으로도 그냥 전화를 쓸 수 있을 것이고,
usim카드에 대한 전화회사의 제한도 풀린다면,
구글 폰을 가져와서 KTF의 USIM 카드를 꼽아서 쓸 수 있는것도 상상할수 있지 않을까요?

샘처럼 드림.

ggangsi의 이미지

구글의 Dalvik VM은 선의 스택방식의 VM과는 전혀 다른 레지스터 방식의 VM입니다. 게다가 자바 바이트코드도 개발과 배포시에만 사용하고, 실제 런타임시에는 (이름을 뭐라 불러야 할지 모르겠지만) Dalvik의 바이트코드로 동작합니다. 따라서 선과 구글의 VM은 개발과정에서 자바라는 같은 언어를 사용하지만, 동작시에는 서로 다른 기술을 사용하기 때문에 IP문제가 제기되기가 어렵습니다.

휴대폰 단말사들도 통신사들이 원하는 플랫폼이 선의 J2ME냐 구글의 안드로이드냐에 따라 달리 선택하면 되기 때문에 그리 고민할 이유가 없습니다. 휴대폰에 안드로이드 플랫폼의 전면 도입없이 Dalvik VM만을 가져오는 것은 의미가 없습니다.
결국 J2ME(또는 Java FX)와 안드로이드간의 또 다른 모바일 플랫폼 싸움일 뿐이며, 선과 구글의 전략적 합의는 없을 것으로 판단하고 있습니다.

권순선의 이미지

예 좋은 분석 감사드립니다. Sun의 IP 포트폴리오와 Dalvik에서 이용하고 있는 기술/특허에 대해 지금 시점에서 모두 안다는 것은 불가능하나 최대한 광범위하고 일반적인 기술영역을 커버하려고 하는 특허의 속성상 Sun이 마음만 먹으면 Dalvik에 대해 어떤 식으로든 IP 분쟁을 일으킬 수는 있습니다. 따라서 기술적인 분석보다는 전략적인 분석이 향후 전망에 더 효과적이라고 생각합니다.

Sun의 입장에서는 자기네들의 핵심적인 수익모델을 android가 겨냥하고 있기 때문에 매우 불편한 심정을 가지고 있을 것이기 때문에 어떤 식으로든 android가 시장에서 확대되는 것을 절대 원하지 않을 것이므로 IP 분쟁은 이를 막기 위한 한가지 가능한 수단이 되겠고요.

dynaxis의 이미지

다들 Dalvik VM에 대해 지극히 영민한 방법이라고 이야기하시지만 과거 WIPI의 Java 부분은 따지고 보면 지금 Dalvik VM 접근법보다 더 Sun IPR에서 자유로웠어야 하는 접근법이었습니다. 결론부터 말씀 드리면 당시 우리나라는 Sun이 IPR 이슈를 재기하자 MIDP를 받아 들이는 방법으로 WIPI 상의 IPR 분쟁을 해결했고 따라서 WIPI는 Sun 로열티 정책에 휘둘리는 상황입니다. 원래 WIPI는 Sun에 로열티를 내지 않는 순수 국내 기술로 다음과 같이 디자인 됐음에도 말이죠.

- JVM bytecode-> Dalvik VM bytecode로 하는 대신 JVM bytecode->machine code로 바꿔서 전송했습니다. (VM을 안 쓰는데 뭔가 VM 만드는 쪽보다는 IPR 침해가 없겠죠)
- 표준 API는 java.lang/java.io 중 일부만 빼고는 전부 새로 디자인했습니다. (약점은 차치하고 Sun이 디자인한 API가 거의 없다고 봐야하니 Android보다 자유롭습니다)

이런데도 Sun은 자신 있게 딴지를 걸었습니다. 제 생각에 구글이 자금력 등으로 Sun 입장에서는 소송에 신중하기는 하겠지만 JavaME 비지니스를 생각하면 실제 단말이 나오는 시기를 따져서 분명히 소송을 걸겁니다. 법리적으로 조금이라도 승소 가능성이 있다면 말이죠.

그리고 IBM이 옛날부터 VM을 만들고 있다 뭐다 하는 건 JVM에 대한 IPR을 무시하는데 별반 도움 안됩니다. 위키피디아 가서 Virtual Machine 찾아보십시오. 역사적으로 VM 기반 소프트웨어는 꽤 많았습니다. 좀 더 서베이해 봐야 명확히 말씀 드릴 수 있겠습니다만 JVM은 그 이전 VM과 다소 다른 면이 있습니다. 특허 부분도 대체로 그런 부분에 있지 않을까 합니다 (예전 JVM 스펙에는 Sun이 특허를 가지고 있다고 나오는 JVM 구현 방법이 있었는데 사실 상 JVM 구현할 때는 그런 방법을 쓰면 효율적이기도 합니다).

ggmoon의 이미지

android가 자바를 개발 언어로 사용하지만, SDK를 살펴보니 기존 J2ME 환경에서 사용하는 프레임워크와는 별개의 새로운 프레임워크와 라이브러리를 제공하고 있더군요. 결국 기존 J2ME와 다양한 JSR에서 정의한 API를 사용한 어플리케이션들은 다시 작성을 해야하는 것으로 보입니다. 심비안을 주도하는 노키아는 어플리케이션 개발 언어로 자바를 지원하면서 JSR 표준 API 사용을 권장하고 있습니다.

구글이 기존 J2ME 어플리케이션들을 호환시키는 작업을 진행할 지? 아니면 원래 호환성을 염두에 두지 않은 까닭이 있을 지 좀 더 지켜봐야 하겠습니다.

{ 스스로 평화롭고 반듯하게 }

{ 스스로 평화롭고 반듯하게 }

권순선의 이미지

흠... 그렇군요. 저는 android가 핸드폰용이므로 J2ME를 새로 만든 것으로 알고 있었는데 만약 그렇지 않고 J2ME와는 완전히 다른 거라면 또 얘기가 달라지네요. J2SE와 J2ME의 차이점이 무엇인지 좀더 상세히 알려주실 수 있을까요?

M.W.Park의 이미지

예전에 잠시 모바일쪽 일을 했던 것을 떠올려보면, J2ME는 개발 언어로 java를 이용하면서, 기존의 J2SE의 서브셋 클래스들을 제공하는 플랫폼입니다.
핸드폰의 제한적인 자원 때문에 스레드나 소켓관련 쪽은 J2SE에 비해서 좀 많이 부족했던 것같구요. GUI쪽도 핸드헬드에 적합한 위젯셋을 제공했던거같습니다.

그리고, J2ME는 일종의 spec정의 같은 것이고 보통 sun과 계약한 (이통사 밑의) 핸드폰제조사가 리눅스의 HAL 계층 비슷한 것을 만들어 Java VM을 올렸던것같네요. 또 이통사 고유의 클래스들이 추가적으로 포함되기도 했습니다. 정확하진 않지만 본래의 J2ME 스펙에는 정의가 없었던 것들(핸드폰의 주소록 접근, 인증관련 등)은 기괴한 이름의 이통사 고유 클래스 및 메서드들로 해결했던것으로 기억합니다.

참고: http://java.sun.com/products/cldc/wp/KVMwp.pdf --> 22 page에 아주 직관적인 그림이 있습니다.

ps. 참 그리고 J2ME는 말그대로 micro edition으로 꼭 핸드폰 뿐만아니라 휴대기기나 가전제품용으로 만들어진것으로 알고 있습니다.

-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂

-----
오늘 의 취미는 끝없는, 끝없는 인내다. 1973 法頂

milkit의 이미지

J2ME에 관련해서라면 다음의 사이트에서 나름 괜찮게 설명되고 있는거 같습니다.

http://jus1170.tistory.com/4853?srchid=BR1http%3A%2F%2Fjus1170.tistory.com%2F4853

J2ME가 타깃으로 하는 시장이 기기간의 Fragmentation 유독 강하고 ME가 포괄하는 부분이 넓기 때문에 ME Platform의 전개가 복잡한 양상으로 이루어 집니다. Optional Package도 상당히 많구요..

권순선의 이미지

만약 dalvik vm이 j2me와는 관계없는 새로운 프레임워크라 sun의 j2me와는 아무 상관이 없고 sun이 ip 분쟁을 일으킬 여지도 없으며 기존 j2me용 app들이 모두 포팅되고 기존 j2me 고객들인 현재의 핸드폰 개발사들도 dalvik vm을 채택하게 된다면 그야말로 sun에는 초난감한 상황이 될 것입니다.

이것은 dalvik vm이 sun과의 ip 분쟁을 불러올 가능성이 0이라는 것을 가정하고 있는데 제가 위에서도 이야기했듯 dalvik vm은 분명히 apache 라이센스로 전체 소스가 릴리즈될 것이 분명한 바, 핸드폰 개발사들은 sun으로의 로열티 절감을 위해서라도 매우 관심을 가지고 지켜보게 될 것입니다.

모두들 기존 모바일 플랫폼 개발사인 ms, nokia의 반응만 궁금해 하고 있는데... 정말 골머리 썩히고 있는 곳은 아무리 봐도 sun인것 같네요.

ggmoon의 이미지

윗 분께서 J2SE, J2ME 차이는 설명을 해 주셨으니 android와 J2ME 프레임워크 차이를 좀 더 설명하겠습니다.
우선 J2ME 어플리케이션은 MIDlet 클래스에 정의된 lifecycle 함수를 구현해야 합니다. android는 MIDlet 클래스가 아닌 Activity 클래스를 상속받아 여기에 정의된 lifecycle 함수를 구현하도록 되어 있습니다.
그리고 JCP에서 J2ME 어플리케이션이 멀티미디어, SMS, location 기능 등을 사용하기 위해 정의된 JSR에 포함된 클래스가 아닌 구글이 새로 만든 패키지들을 사용해야 합니다.

재미있는 점은 다운로드 어플리케이션이 아닌 폰 native 어플리케이션을 모두 자바로 작성한다는 개념은 얼마 전 SUN에서 발표한 JavaFX Mobile과 유사한 점이 있습니다. JavaFX Mobile도 레퍼런스 모델이 리눅스를 기반으로 하고 있고 android 처럼 full software stack 구조를 가지고 있습니다. 물론 JavaFX Mobile은 기존 J2ME 어플리케이션 호환성을 지원하고 많은 프레임워크 라이브러리는 기존 JSR 표준 API들을 사용합니다.

또한 JavaFX Mobile은 기존 데스크탑 class (J2SE) 어플리케이션과 동일한 수준의 개발 환경을 제공하려 하는데 이 이유 중 하나가 수 많은 데스크탑 자바 개발자들을 모바일 영역으로 끌어들이기 위한 것이라고 합니다. 반면 구글은 엄청난 상금을 걸고 android 개발자들을 유혹하고 있죠 ^^;

아무튼 이래 저래 SUN이 가려는 길에 구글이 발을 들여 놓은 듯 합니다.

{ 스스로 평화롭고 반듯하게 }

{ 스스로 평화롭고 반듯하게 }

gmdduf의 이미지

저도 향후 그림에 대해 관심이 많아 저의 소견을 몇자 적고자 합니다.
기업들간의 새로운 전략은 늘 기존 질서에 충격을 주며 그 결과 항상 승자와 패자가 존재하는 것 같습니다.

구글의 의도는 단지 기존의 휴대폰 개발에 필요한 SDK만을 제공한 것이라고 볼 수 없을 것 같습니다. 그렇게 생각하기엔 구글의 전략과 가려는 방향이 너무 좁기 때문입니다. 언젠가부터 구글은 MS와의 경쟁자로 피력된적이 있습니다. gmail, Google Earth등을 만들면서 어떻게 MS와의 경쟁자가 된다는 것인지 이해하기 어려웠습니다. 적어도 안드로이드를 발표하기 전까지는요...

구글은 PC에서 MS처럼 Mobile device에서 안드로이드 전략을 갖고 있습니다. OS가 HW platform에 독립적인것 처럼 안드로이드도 독립적, 개방형 하드웨어를 지향할 것입니다. 거기에 개발자에게 편리한 SDK를 제공하므로써 Windows에 수 많은 Apps가 있듯이 안드로이드 플랫폼에 수 많은 Apps를 만들어 갈 것이고 이는 사용자에 의해 install/uninstall식으로 사용될 것 입니다. 이것이 가능하려면 인터넷과 같은 개방형 망과 개방형 플랫폼의 조건이 선행되어야 할 것입니다.

미국을 시작으로 세계적으로 Analog 방송의 Digital화가 늦어도 2012년이면 끝나게되고 통신에서 황금거위로 불리우는 700MHz 대역의 주파수 여분이 생기게 됩니다. 얼마전 미국 FCC의장의 말에 의하면 이 황금 주파수는 플랫폼 개방뿐아니라 서비스 개방을 피력하는 자가 경매의 승자가 될 것이라고 하였습니다. 여기서, 그 망이 누구에 의해 어떤 서비스를 하게될지는 모르지만 한 가지 확실 한 것은 인터넷과 같은 개방형 차세대 망이 될 것이라는 점입니다. 가장 유력한 후배는 역시 Mobile WiMAX, 3G LTE가 될 것으로 보고 있습니다.

이런 망에서 사용되는 모바일 단말기는 지금까지 몇몇 application을 가지고 차별화되던 이통사의 망과는 다른 특징을 가지고 있습니다. 이름하여 MID (Mobile Internet Device)가 그것입니다. 간단히 말해 소형 휴대 컴퓨터 정도가 되겠지요.. 데이타 통신을 기본으로하는 이러한 4G에서 종전과 같은 핸드폰 서비스는 구시대의 유물이 될 것입니다. 구글은 바로 이 시대를 준비한다고 봐야 할 것입니다... 경매에 입찰하기위해 미리 안드로이드를 발표한것 같기도 하구요.

물론, 기존 통신사들이 가만히 있지는 않겠지만...현재까지 가장 많은 점수를 따고있는 구글이 내년 1월에 있을 700MHz 경매에서 승자가 된다면, 안드로이드는 4G시대의 초석이 될 수 있으리라 생각합니다...얼마 남지 않았으니.. 한 번 지켜보시지요...

익명 사용자의 이미지

> 구글이 내년 1월에 있을 700MHz 경매에서 승자가 된다면

경매가 이루어졌나요?

Julian76kr의 이미지

I'm not a family man.

cleansugar의 이미지

Dalvik: how Google routed around Sun’s IP-based licensing restrictions on Java ME
http://www.betaversion.org/~stefano/linotype/news/110/

___________________

http://blog.aaidee.com

재벌 2세가 재벌이 될 확률과
금메달리스트 2세가 금메달을 딸 확률이 비슷해지도록
자유오픈소스 대안화폐를 씁시다.

아이디의 아이디어 무한도전
http://blog.aaidee.com

귀태닷컴
http://www.gwitae.com

neocoin의 이미지

Sun 이 사라졌군요. http://sun.com 가도 orarcle 로 안내되구요.

권순선의 이미지

Sun을 인수한 Oracle이 Google에 Android의 Java 관련 특허침해 소송을 제기했군요. http://news.cnet.com/8301-30684_3-20013546-265.html

cleansugar의 이미지

오라클의 자바 특허를 검색해봤습니다.

http://www.google.com/patents/about?id=dyQGAAAAEBAJ&dq=patent:6125447&as_drrb_ap=q&as_minm_ap=0&as_miny_ap=&as_maxm_ap=0&as_maxy_ap=&as_drrb_is=q&as_minm_is=0&as_miny_is=&as_maxm_is=0&as_maxy_is=

Patent number: 6125447
Filing date: Dec 11, 1997
Issue date: Sep 26, 2000

Protection domains to provide security in a computer system

A method and apparatus are provided for maintaining and enforcing security rules using protection domains. As new code arrives at a computer, a determination is assigned to a protection domain based on the source from which the code is received. The protection domain establishes the permissions...

http://www.google.com/patents/about?id=G1YGAAAAEBAJ&dq=patent:6192476

Patent number: 6192476
Filing date: Dec 11, 1997
Issue date: Feb 20, 2001

Controlling access to a resource

A method and system are provided for determining whether a principal (e.g. a thread) may access a particular resource. According to one aspect of the invention, the access authorization determination takes into account the sources of the code on the call stack of the principal at the time the...

http://www.google.com/patents/about?id=5GMZAAAAEBAJ&dq=patent:5966702

Method and apparatus for pre-processing and packaging class files

A method and apparatus for pre-processing and packaging class files. Embodiments remove duplicate information elements from a set of class files to reduce the size of individual class files and to prevent redundant resolution of the information elements. Memory allocation requirements are...

http://www.patentgenius.com/patent/7426720.html

System and method for dynamic preloading of classes through memory space cloning of a master runtime system process

A system and method for dynamic preloading of classes through memory space cloning of a master runtime system process is presented. A master runtime system process is executed. A representation of at least one class is obtained from a source definition provided as object-oriented program code. The representation is interpreted and instantiated as a class definition in a memory space of the master runtime system process. The memory space is cloned as a child runtime system process responsive to a process request and the child runtime system process is executed, inheriting the memory state of the parent, which reflects the data structures and state corresponding to the preloaded classes.

http://www.google.com/patents/about?id=8xkPAAAAEBAJ&dq=patent:RE38104&as_drrb_ap=q&as_minm_ap=0&as_miny_ap=&as_maxm_ap=0&as_maxy_ap=&as_drrb_is=q&as_minm_is=0&as_miny_is=&as_maxm_is=0&as_maxy_is=

Method and apparatus for resolving data references in generated code

A hybrid compiler-interpreter comprising a compiler for "compiling" source program code, and an interpreter for interpreting the "compiled" code, is provided to a computer system. The compiler comprises a code generator that generates code in intermediate form with data references made on a...

http://www.google.com/patents/about?id=U-4UAAAAEBAJ&dq=patent:6910205

Interpreting functions utilizing a hybrid of virtual and native

Systems and methods for increasing the execution speed of virtual machine instructions for a function are provided. A portion of the virtual machine instructions of the function are compiled into native machine instructions so that the function includes both virtual and native machine instruction...

http://www.google.com/patents/about?id=mEwEAAAAEBAJ&dq=patent:6061520

Method and system for performing static initialization

The disclosed system represents an improvement over conventional systems for initializing static arrays by reducing the amount of code executed by the virtual machine to statically initialize an array. To realize this reduction, when consolidating class files, the preloader identifies all...

모노 프로젝트도 영향권이라고 합니다.

___________________

http://blog.aaidee.com

재벌 2세가 재벌이 될 확률과
금메달리스트 2세가 금메달을 딸 확률이 비슷해지도록
자유오픈소스 대안화폐를 씁시다.

아이디의 아이디어 무한도전
http://blog.aaidee.com

귀태닷컴
http://www.gwitae.com

익명 사용자의 이미지

안드로이드에 대한 비관적인 생각과 긍정적인 생각들이 공존하였네요, 결과는 놀아울 정도로 대단한 안드로이드입니다.
오라클은 계속 구글을 IP로 위협하고 있는 상황이구요.
MS는 안드로이드도 결국 리눅스OS를 쓰는데 자기네 특허가 리눅스에도 들어있기 때문에 특허료를 내야한다고 주장하고 있습니다.
실제 HTC는 대당5달러의 특허료를 지불하고 있답니다.

익명 사용자의 이미지

최근 M$에서 요구하는 특허료는 FAT시스템에 관한 특허라고 하더군요. 즉 외장 SD카드 포맷형식을 일부 벤더에서 쓰고있기때문에 그런것입니다. FAT를 안쓰고도 안드로이드폰을 얼마든지 만들 수는 있지요.
FAT말고 다른 M$특허는 잘 모르겠네요.

익명 사용자의 이미지

MS에서 더욱 강력하게 FAT 특허 권리 행사를 했으면 좋겠습니다.
MS에서 FAT 특허 권리를 강력하게 주장할수록 FAT의 시장 점유율은 하락할 겁니다.
MS 스스로도 그걸 알텐데...

익명 사용자의 이미지

그러면, FAT의 대안으로 쓸만한 파일 시스템은 뭐가 있나요?
최근의 파일 시스템들은 대체로 무겁고 복잡한 느낌이 강한데...

익명 사용자의 이미지

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.