서광열님이 CTO로 계시는 company100에서 개발한 모바일 웹 애플리케이션 프레임워크. WAFLE은 빠른 인터넷, 3D User Interface,그리고 GPS와 camera access를 제공한다고 함. Dorothy, Thousand Hands와 함께 개발되고있음. 자세한 내용은 링크된 웹페이지참조. 2010년 컴퓨팅의 조류를 제대로 파악하고 있는 대한민국 IT 기업은 company100 하나뿐으로 판단됨. 단지 놀라울 뿐. 그렇지만 몇 가지 지적질(?)을 좀 해보자면 첫째, 경쟁상대가 정확하게 구글이라는 점(잠재적으로는 MS, Apple도 포함됨). 둘째, 포부에 비해서 개발팀의 규모가 숫자면에서 왜소하다는 점(특히 여기서 개발자라함은 코더가 아니고 아키텍트를 의미함). 이 두 가지를 어떻게 극복하느냐가 관건.
  
Bada(바다), Nov. 2009-2010 [http://developer.bada.com/apis/index.do]
삼성전자에서 개발한 Bada platform은 모바일 디바이스에서 사용자로 하여금 좀 더 풍부한 UI 경험을 가능케하는 새로운 오픈 플랫폼이라고 합니다. 
    1) 개발 취지
취지만 보자면 안드로이드와 흡사한 면이 있지만, 프로그래밍언어는 C++만을 지원하고, 운영체제의 경우 리눅스 및 기타 realtime OS를 지원한다는 점 등에서 차이가 있습니다. 마케팅적인 요소를 모두 배제하고 생각해보면, 각각의 아키텍처에서 제공되는 API와 OpenGL과 같은 그래픽 라이브러리를 적절하게 사용하여 
Bada platform
만의 고수준의 API를 제공하고 있습니다. 이것은 이노에이스나 유비벨록스같은 회사에서 오래 전부터 해오던 작업이라 새삼스러울 것은 없다고 보여집니다. 좀 특별한 것은 앱스토어와 연동한다는 점과, 무엇보다 삼성이라는 막대한 자금력을 가진 회사가 주도적으로 추진하고 있다는 점입니다.
    2) 원천 기술
요새 흔히들 부르짖는 원천기술 측면에서보면, 운영체제, 주요 라이브러리, 그리고 개발 툴을 오픈소스에서 차용했기 때문에 삼성이 독자적으로 개발한 핵심원천기술은 없는 것으로 생각됩니다.(삼성전자의 오픈소스에 대한 기여도는 별개의 문제로 생각했습니다.) 
    3) 비교 우위 및 전망
조심스레 몇 가지 예측을 해보자면, 
오픈소스를 차용해서 쓸 것같으면 선두인 구글 안드로이드보다 개발 인프라가 상당히 부족하고, 독자적 원천기술을 확보해서 플랫폼을 구축할 것같으면 애플과 비교해서 상당한 기술격차가 존재합니다. 더군다나 Chrome OS를 기반으로 한 구글 폰을 생각하면, 웹 플랫폼 기술력이 전무한 삼성의 경우 상당히 고전할 것으로 생각됩니다.(Osp::Web을 통해 embedded browsing functionality를 지원한다고 하지만 구현물의 performance와 html 표준에 대한 conformance가 얼마나 될지는 별개의 문제로 생각했습니다.) 결론은 "이거 쉽지 않겠구나"입니다. 재미있는 반전은 마케팅 관점에서 보면 전통적인 하드웨어 기업인 삼성은 단말기 시장 점유율만 높이면 때문에, "잘 되면 좋고, 안 되면 그만"이 되지 않을까 생각합니다. 쉽게 예측해 볼 수 있듯이 삼성은 바다 뿐만 아니라 안드로이드, 윈도우 모바일(윈도우 폰), 그리고 심비안 같은 다양한 플랫폼을 가진 모델을 꾸준히 출시하리라 보여집니다. 소프트웨어 시장에 대한 끊임없는 삼성의 러브콜, 그 무한도전에 박수를 보냅니다.
 // C++, Eclipse+GNU tool-chain

COMIC, 2008-2009 [http://comic.snu.ac.kr/]
서울대학교 컴퓨터공학부 이재진 교수님 연구실(CMP; 링크1)에서 개발함. COMIC(A Coherent Shared Memory Interface for Cell BE)은 Cell BE 프로세서에서 복잡한 프로그래밍 환경-예를 들어 SPE의 로컬 메모리 및 DMA를 직접 관리해야 하는 부담 등-을 개선하기 위한 런타임 시스템입니다. 다시 말해, 프로그래머에게 PPE와 SPE사이에 전역공유메모리가 있는 것처럼 보이게 함으로써, 프로그래밍 복잡도를 완화하는 겁니다. 참고로 Patterson 그리고 Hennessy 교수님 의견에 따르면, 흔히 사용하는 "shared memory"라는 표현보다는 "single address space"라는 표현이 더 정확한 뜻을 담고 있다고 합니다. 그런 의미에서 "단일주소공간에서 프로그래밍을 하는 것처럼 보이게 한다"라는 표현도 좋지 않을까 생각해봅니다.. 프로그래머는 데이터가 어디에 있는지, 어떻게 얻는지 고민할 필요가 없이 C 프로그래밍을 하면 됩니다. 관련 논문은 PACT'08에서 채택되었습니다.[링크2링크3] 덧붙여서, 버지니아 대학교의 Kim Hazelwood교수님은(쓸데없는 소리지만 사진으로 봤는데 상당한 미인이십니다) 이러한 기술이 하드웨어 수준에서 처리되는 것을 multicore virtualization의 일종이라고 부르는데요, 저수준에서 이루어지는 코어 관리(core management)를 추상화하여 소프트웨어 단에서의 부담을 줄이는 기술을 말합니다. 더욱 자세한 내용은 Philip M. Wells, Koushik Chakraborty, and Gurindar S. Sohi 라는 분들이 쓴 논문을 참조하세요. 또 OASES라는 것도 있는데요, runtime monitoring을 용이하게 하기 위해서 캐시 이벤트(cache event)를 명시적으로 소프트웨어 단에 노출하는 겁니다.(by Vijay Nagarajan and Rajiv Gupta). 이런 건 정말 생각만 해도 신나는 것들이로군요. 앞서 소개된 내용은 2009년 현재 cutting edge를 넘어서 bleeding edge에 속하는 기술들입니다. // Cell BE(IBM), C

CHAMELEO(까멜레오), 2008-2009 [http://chameleo.org/]
서광열님이 CTO로 계시는 노메드커넥션에서 개발한 멀티미디어 플랫폼입니다. 까멜레오를 활용해서 프로그래머는 손쉽게 다양한 비디오 플레이어 위젯을 만들 수 있다고 합니다. 다가올 미디어 플랫폼의 핵심(core)이 될 목표를 가지고 있다고 나와 있네요. 해외에서도 소개되었습니다.[링크1링크2] 개인적인 생각을 좀 써보자면, 까멜레오를 보면 오래전에 스티브잡스의 NeXTSTEP이 머릿속에 떠오릅니다.[링크3] 너무 시대를 앞서 나간 뛰어난 기술이었기 때문에 사람들에게 외면받았던 비운의 그리고 전설의 운영체제이죠.(하지만 어쨌든 NeXTSTEP은 이 후에 MAC OS X의 전신이 되었습니다.) 현재 노메드커넥션이라는 회사가 어떤 상황에 있는지 구체적인 것은 잘모르겠지만, 전체적으로 조용해진 것을 보면 까멜레오가 앞으로 NeXTSTEP과 같은 길을 걷게 되는 것은 아닐까 걱정이 됩니다. 오늘 마침 가상머신의 미래에 대해서 곰곰이 생각해보다가, 플랫폼 싸움은 결국 구글이 승기를 잡았구나, 앞으로 대한민국은 뭘해야할까 하는 고민을 하게 됐습니다. 그리고는 서광열님과 함께 까멜레오가 떠오르더라구요. 참고로 가상머신과 플랫폼에 대해서 오해를 하고 계신분들이 생각보다 많이 계신 것 같습니다. 가상머신, JAVA, 소프트웨어플랫폼, 클라우드컴퓨팅, Linux, VMware, OpenCL, Android... 이런 것들 솔직히 말씀드리면 큰 의미없습니다. 대부분의 기술이 추구하는 바는 소위 "윈텔" 한 번 잡아 보자는 쪽으로 수렴됩니다. 그리고 이 모든 기술들이 웹브라우저에 모조리 통합되리라는 것을 M$와 우리는 15년전부터 예견하고 있었고, M$는 필사적으로 버텨왔습니다.[링크4] 많은 분들이 짐작하시겠지만, 이제 그 치열했던 역사적인 싸움의 마무리가 구글에 의해서 자행(?)되는 것을 모두 함께 지켜보고 있는 셈이 되었습니다. 쓸데없는 소리는 여기까지만 하겠습니다. 멀지 않은 미래에 까멜레오는 21세기 대한민국에서 몇 번 나오지 않을 "신선하고 뛰어난" 기술중 하나로 회자될 것입니다. 이 글을 쓰고나서 나중에 좀 찾아봤더니 Company100, Inc.에 계시는 군요.[링크5] 잠깐 사이트를 둘러봤는데 상당히 인상적인 벤처인 것 같습니다. // 플랫폼중립, C, python

XASM, 2004-2008 [http://blog.naver.com/www56321]
캐나다에서 여운산님이(id: www56321) 개발한 intel architecture용 어셈블러. 어린 나이에도 불구하고 다양한 시도를 하고 있음. 소스코드는 공개되어 있지 않고, binary만을 배포하고 있음. 링커나 라이브러리가 따로 없는 것을 보니 naive한 기계어만을 뽑는 것같은데, 현재는 미약하지만 앞으로 차근히 parsing이나 syntax/semantic analysis 이론과 같은 기초를 공부해나간다면 새로운 language에 대한 컴파일러까지 구현할 것으로 기대하고 있음. 앞으로의 행보가 기대되는 rookie임. // C++(Windows), x86, x86_64, Itanium

Ada/CS compiler, 2006 [http://www.facebook.com/qhpark]
NVIDIA에서 시스템소프트웨어 엔지니어로 근무하고 계시는 박규하(masterQ)님께서 워털루 대학 시절 만들어 봤다는 컴파일러입니다. 학교 과제물로 만들어 보신 것 같구요. 어셈블리형태로 출력하고 gcc, ld같은 GNU tools로 실행파일을 만듭니다. 제작자는 Alan Leung, Kwan Lim, Q-ha Park. 사실 이건 한국에서 만들어졌다고 보기 힘든건데 기록으로 남기면 좋을 것 같아서 적어 봅니다. // Ada/CS, SPARC

이 글을 작성한 사람이 만든 Dokdo C language Compiler 입니다. 장기적으로는 llvm을 대체할 만한 소프트웨어 플랫폼으로 키워볼 생각입니다.(2009년 9월 현재, ACM/IEEE논문과 이 분야에 널리 알려진 명서들을 읽으면서 공부를 하는데 많은 시간을 보내고 있습니다.) 2008년 여름에 동국대학교 오세만 교수님이 작성하신 mini C 컴파일러 예제에 몇 가지 기능을 추가하고 버그를 수정하여 만들어진 초허접한 결과물인 0.01버전을 공개하였으며, 구현하면서 잘모르는 부분은 오세만교수님 연구실에 계신 손윤식님의 도움을 받았습니다. 자세한 내용은 위 링크를 참조하세요. // MIPS(Linux), x86(Windows, Linux), C

SK그룹 계열사인 이노에이스에서 개발하고 있는 OpenGL ES 기반의 H/W 가속 mobile 3D Game Platform. Class2, Class3, Class3Q, Class4 등의 버전이 있음. 실행환경, 개발환경을 포함하는 통합 Platform 임. 이거 그냥 OpenGL ES라는 low level api를 사용한 상위 API인 듯. // 하드웨어 중립, OpenGL ES, C

SK그룹 계열사인 이노에이스에서 개발하고 있는 통합 플랫폼 솔루션. T-PAK은 최소한의 시간과 비용으로 동일한 Look and Feel의 애플리케이션을 OS, Chipset, Protocol Stack에 독립적으로 구현할 수 있다는 장점을 제공함.. Over The Air(OTA) Platform Upgrade, 모듈화된 DSL 구조, Vector Font Engine, OS/Chipset 독립성, 외부 파일 시스템 등은 T-PAK을 기존의 플랫폼과 차별화 해주는 요소라고 함. 업체 홈페이지에서 T-PAK커널 관련 소개 부분에 "이벤트 driven 방식의 시스템은 고효율의 context switching을 제공합니다"라고 써놨던데... 이벤트 driven 방식은 프로세스간 통신 및 동기화를 효율적으로 하기 위함이지 context switching을 효율적으로 하는 것과는 하등의 연관이 없는 개념입니다. 이 부분을 보고 생각해보건데, 아마 T-PAK은 "통짜"로(단 한개의 커널스레드로) 만들어진 오래된 방식의 커널일 확률이 매우 다분하네요. 그러고보니 SKT 단말에서 Android나 iphone에서와 같은 멀티태스킹이 안 되는 이유가 여기에 있는지도 모르겠습니다. // 하드웨어 중립

Versert(버섯), 2005 [http://mearie.org/projects/versert/]
강성훈(lifthrasiir)님이 "Befunge라는 언어에 스택이 없으면 어떻게 되는가?"라는 물음으로 시작하여 개발한 독특한 로우레벨 프로그래밍 언어. 저급이라고 말한 이유는 전통적인 컴퓨터 아키텍처 관점에서 볼 때, 버섯이라는 언어 자체가 기존에 없는 특수한 머신을 가정했고, 그 머신에서 실행되는 기본적인 논리/연산/분기명령을 지원하는 형태이기 때문이다. 그런 의미에서 언어라기보다는 추상적인 가상머신에 대한 Instruction Set Architecture명세에 가깝지만, 기호화된 문법, 입출력을 추상화하여 지원한다는 점, 그리고 VM형태의 인터프리터에서 결과물을 직접 내놓기 때문에 저급언어라고 보아도 무방하겠다. 이 독특한 머신은 스택이 없고, 2차원 배열형태로 명령어/데이터가 메모리에 저장되고 명령어 실행순서가 순차적이지 않고 분기가 매우 격심한 레지스터-레지스터모델 형태임(load-store모델이라고도 함). 따라서 실제 해당 머신 및 프로그램 구현시 pipeline(ILP), cache(Memory Hierarchy), multiple issue(static or dynamic), SMT(TLP), paralle hardware, concurrent programming 등을 종합적으로 고려했을 때 그 어떤 언어보다 이해하기 어려우며 최악의 실행성능을 구현할 수 있음(Versert deserves the world worst awards). 내부적으로 Instruction Pointer, Velocity, Data Pointer, Register와 같은 변수를 갖고 있음. 참고로 Befunge라는 언어는 "가능한 컴파일하기 난해한 언어"가 목표라고 함. 더 자세한 내용은 해당 홈페이지 참조. // 버섯



JINOS2 Runtime, 2002-2006 [http://www.ubivelox.com/]
서울대학교 전기공학부 문수묵 교수님의 연구실(MASS, 링크1) 연구원들을 주축으로 회사 설립된 회사인 유비벨록스(주)(과거 벨록스소프트)에서 개발한 소프트웨어 런타임(Core engine). Java와 C application을 동시에 지원하고, AOTC (Ahead-Of-Time Compile) 기법을 통해 C 어플리케이션에 근접하는 성능향상을 이루었으며 native method를 지원함으로 C 어플리케이션과 동일한 기능 사용을 보장한다고 함. 국내에 보기드문 기술력을 가진 회사가 아닐까하는데... JINOS2만 밀어 부치는 것은 시대에 흐름에 부흥하지 못한 것 아닌가 하는 생각이 문득 들었음. AOTC 장단점을 모르는 것도 아닐 진데 약간 마케팅 멘트로 포장한 면도 있고, 잡종프로세서(heterogeneous processor)를 위한 concurrent programming을 지원하는 새로운 런타임을 개발해야하겠고... 그리고 Android, iPhone, OpenCL의 등장도 중장기적으로 악재일 수 밖에 없고. 어떻게 헤쳐나갈 것인가 기대해봅시다. // 하드웨어 중립, Java, C


한국무선인터넷 표준화 포럼(KWISF : Korea Wireless Internet Standardization Forum)의 모바일 플랫폼 특별 분과에서 WIPI(Wireless Internet Platform for Interoperability)를 만듦. 덕분에 SKT 단말용 GVM을 개발한 신지소프트가 타격을 입었고, 대표이사는 주가조작/배임/횡령 등의 혐의로 구속[링크1]됐었고... 여하튼 말도 많고 탈도 많았던 위피. 모바일 플랫폼 표준 규격으로서 무선 인터넷을 통해 다운로드 된 응용프로그램을 이동통신 단말기에 탑재시켜 실행 시키기 위한 환경을 제공하는데 필요한 표준규격. 2009년 4월을 기준으로 의무화가 해제되었으며, WIPI 3.0개발 중이라고 함. 2009년 현재 유관업체로는 "신지소프트(GNEX), 아로마 소프트, 엠페이지, 지어소프트, 이노에이스,  XCE, 유비벨록스(주)" 등이 있으며, WIPI플랫폼의 업체별 구현은 해당 홈페이지를 참조하세요, 따로 표기하지 않습니다. 왜냐하면 멀티코어나 잡종프로세서로 넘어가면 사실 WIPI는 의미가 없어지기 때문이죠. OpenCL이나 Cell BE 라이브러리/런타임 같은 기타 세계표준을 못따라갑니다. WIPI를 고집하다가는 세계시장에 묻히게 될게 뻔하거든요. 그래서 각 업체별로 독자적인 플랫폼을 제시하고 있습니다. innoace같은 회사가 앞서 나가는 것 같습니다. 어쨌든 여기서도 잡종프로세서에서 최대한 쉽게 concurrent프로그래밍을 할 수 있는 플랫폼이 승리하게 되겠습니다. 아직 블루오션이에요.. 이 부분은. 이거 잡으면 일단 국내에서는 돈을 벌 겠죠 하하하. COMIC같은 실험용 런타임은 그런 의미에서 신선한 연구결과물입니다. 이 문제가 해결되기 위해서는 진지한 의미에서 고급 아키텍트가 필요하구요, 또 이런 결과는 짠하고 갑자기 나타는게 아니고 연구과정에서 ACM/IEEE에 논문 몇 개 정도는 나와야 믿을 수 있습니다. 안 그럼 사기일 확률이 높으니 벤처 투자하시는 분들은 조심하시구요! 참.. 그런 의미에서 WIPI는 실패한 정책중에 하나라고 봅니다. 차라리 어언 10년 전에 신지소프트에서 개발한 GVM을 집중적으로 지원했더라면, OpenCL같은 결과물이 나왔을지도 모르는 일이니까요. 정말 안타깝습니다. // 하드웨어 플랫폼 중립, WIPI-Java, WIPI-C

GVM, 2000-2001 [http://www.sinjisoft.com/]
신지소프트에서 개발한 플랫폼. 초기 SWAP(SINJI Wireless Application Plug-in)이라는 명칭으로 개발된 GVM는 1.0 최종 버젼이 2000년 6월에 개발이 완료되었고, 2000년 10월에 최초로 SK Teletech IM-2000단말기에 적용되어 출시되었으며, SK Telecom의 무선인터넷 서비스인 nTOP을 통하여 서비스가 시작되었다. 이후 2001년에 GVM(General Vertual Machine)으로 이름이 변경되어 GVM Version 1X, 2X를 개발하여 단말기에 탑재됨. // Mini C 또는 Mobile C

nML, 1999-2004 [http://ropas.snu.ac.kr/n/]
서울대학교 컴퓨터공학부 이광근 교수님 연구실(ROPAS; 링크1)에서 관리/개발하고 있는 프로그래밍 언어. nML은 좀 더 고차원적이며, typed한 프로그래밍 언어라고 합니다. Standard ML과 Objective Caml에서 파생된 언어기 때문에 대부분의 특징을 공유할 것이라고 짐작해 볼 수 있음. 그리고 거의 대부분의 구현은 이광근 교수님께서 카이스트(KAIST)에 계실 때 작성된 것으로 알고 있음. 이광근 교수님은 2007년 4월 25일 서울대학교 학사과정 세미나에서 파수닷컴의 SPARROW(정적분석 툴)가 ML로 개발되었다고 설명함.[링크2] 그리고 nML 덕분에 프로그램이 작고 간단해지며 프로그램 기획이 편리해진다고 함. // Objective Caml compiler: nML parser + nML type-checker + nML-to-OCaml translator + the OCaml compiler


**관련 커뮤니티

LangDev.net [http://langdev.net]
홍민희(코리안클릭 기술혁신팀에 근무; dahlia)님이 운영하는 사이트. 본격적인 프로그래밍 언어와 구현에 관심이 있는 올바른 커뮤니티는 여기 한 곳 뿐으로 생각되므로 관심있는 분들의 많은 방문을 바랍니다. 저같은 경우는 언어 자체에는 그다지 관심이 없는 편이라서 또 플랫폼 구현이 아닌 파서나 언어 특성을 구현하는 부분에는 별로 관심이 없습니다. 그래서 잘 가지 않지만 다른 분들은 많은 도움이 되실 듯합니다. 여기서 활동하시는 서상현(feanor)님은 llvm 소스커미터 이기도 하시죠.

Linux Kernel Source 분석모임 [http://iamroot.org/] 
백창우(삼성전자근무; anfl)님이 운영하는 사이트. "KERNEL-x86, KERNEL-ARM, 안드로이드 플랫폼, GCC 분석" 등의 소모임으로 구성되어 있으며, 각종 세미나를 통해 활발히 교류하고 있는 곳. 특히 GCC 내부구조와 원리라는 세미나는 한 번씩 가보시길 추천합니다. 흠... 멀티코어의 대중화로 인해서 지난 50년간 근근히 이어져왔던 컴퓨터업계의 조류가 급변하고 있습니다. 이러한 때에 컴퓨터 아키텍처에 대한 깊이있는 이해와 운영체제 개발 경험은 이제 필수라고 할 수 있겠습니다. 그런 의미에서는 이 곳이 가장 선진적인 모임이라고 볼 수 있습니다.



출처 : http://njh1983.tistory.com



WRITTEN BY
RootFriend
개인적으로... 나쁜 기억력에 도움되라고 만들게되었습니다.

,