Processing

미디어아트 및 교육용 언어 지향의 오픈소스 프로그래밍 언어. 라이센스는 GPL, 라이브러리 라이센스는 LGPL을 따르고 있다.

MIT 미디어 연구소 소속의 Casey Reas와 Ben Fry가 개발하여 2001년 처음 공개하였다. 알파, 베타 과정을 꽤 길게 거쳤으나, 이미 그 단계에서 미디어 아트 지향의 여러 교육기관에서 널리 사용되고 있었으며 첫 정식 버전인 1.0 버전은 2008년 11월에 공개되었다. 초창기에는 'Proce55ing'이라는 특이한 철자를 썼었는데(leet로 S와 5의 형태적 유사성을 이용) 이것은 processing.org의 도메인이 선점되어있어서 proce55ing를 쓸 수밖에 없었기 때문이었다는 듯(...). 현재는 Processing 쪽이 공식 표기이며 도메인도 processing.org를 사용한다(proce55ing.org로 들어가면 processing.org로 리다이렉트된다).

Processing은 기본적으로 Java 베이스의 언어이지만 JavaScript 버전으로 만들어진 P5.js 라이브러리가 있다. 따라서 이 라이브러리를 활용하면 웹브라우저에서도 Processing에서 구현할 수 있는 각종 에니메이션이나 그래픽 효과를 구현할 수 있어 보다 동적인 사이트를 쉽게 구축할 수 있다.

기본적인 아이디어는 과거 두 개발자가 소싯적에 사용했었던 Logo[1]나 BASIC이 간단한 명령 몇 줄로 그림을 그리거나 사용자와 상호작용 할 수 있는 프로그래밍 환경을 제공했던 데서 착안했다고 하며, Processing과 유사한 목적으로 만들어진 John Maeda[2]의 'Design By Numbers'의 영향도 크게 받았다고 한다. 실제로 인터페이스 등이 DBN과 유사하다.

언어 자체의 문법과 언어 스펙에 대한 기본적인 것은 Java에서 거의 그대로 가져왔지만 문장의 사용이 훨씬 단순화되어있는 것이 특징. 자바의 OOP 개념도 가려서 보이지 않게 해두어 소스를 얼핏 보면 C와 같은 절차형 프로그래밍 언어처럼 보인다.[3] OOP 개념이 오히려 초심자에게는 벽으로 작용한다고 판단한 듯 하다.

특히 간단한 명령(함수) 몇 줄만으로 시각적 표현이 가능한 것이 장점이다. 심지어는 3D 그래픽스나 영상 제어등도 별다른 라이브러리 없이 기본 라이브러리에 든 함수 만으로 그다지 어렵지 않게 구현 가능하다. 덕분에 비교적 프로그래밍에 전문성이 높지 않은 미디어 아티스트의 작업 및 디자이너의 프로토타이핑에 주로 활용되며, 언어 자체의 진입장벽이 비교적 높지 않아 취미 지향의 프로그래밍 초심자가 프로그래밍이라는 개념을 처음 익히기에도 적합한 편이다. 실제로는 Java를 래핑해서 돌아가는 구조이기 때문에 문법이나 언어의 상세 기술은 거의 자바의 그것을 그대로 따르고 있으며 컴파일한 결과물은 자바 가상머신에서 실행된다. 따라서 Java Applet 등으로 내보내서 웹에 작업물을 공개하거나 하는 것도 가능하다.

자바로 만들어진 심플한 자체 IDE를 제공하지만 기본적으로 자바를 래핑한 언어이므로 원한다면 이클립스와 같은 외부 IDE를 이용할 수도 있다. 물론 이 경우에는 자바에서 프로세싱의 pApplet 클래스를 가져다 쓰는 형식이 되므로 정식 프로세싱 코드와 완전히 동일하게 코딩할 수는 없고, 자바 프로그래밍에 대한 기초적인 지식 정도는 있어야한다. 잘 모르겠으면 그냥 전용 IDE를 쓰자.

국내에서는 디자인 및 예술 계통 학과의 커리큘럼 중심으로 보급되어 있지만 그 외의 사용은 매우 저조한 편. 사실 그쪽 전공자라거나 미디어 아트 작업이라도 하지 않는 이상 이걸로 할 만한 게 별로 없다[4]. 이쪽(디자인/예술 계열) 전공이 아닌 이상 이런 언어가 있는지 아무도 모른다. 심지어는 컴퓨터공학을 전공한 전문가들조차도 프로세싱에 대해 이야기하면 그게 뭐냐고 반응할 정도. 안습.

디자인/예술 관련 학과의 커리큘럼이라는 측면에서 보자면 컴퓨터에 익숙하지 않은 디자인/예술 계통 전공 학부생들에게 액션 스크립트와 함께 충격과 공포를 안겨주는 존재. [5] 사실 학교 올 때까지(아니 입학한 뒤에도 상당기간) 자기가 학교에서 프로그래밍을 배우는 일이 생길 거라고 생각하는 미대생은 거의 없다. 디자이너도 프로그래밍 배워야 되는 더러운 세상 다만 이것은 학교에 따라 커리큘럼 차이가 커서 이런 게 있는지도 모르고 행복하게 졸업하는 학교도 많다. 프로그래머의 입장에서 보면 대단히 쉬운 언어에 속하지만 코딩에 문외한인 미대 학부생 입장에서는 프로세싱조차도 배우기 버거워하는 경우가 많아 학교에 따라서는 vvvv 같은 비주얼 언어를 대신 가르치는 곳도 있고 아예 눈높이를 확 낮춰서 1학년 수업에서는 초딩들 쓰라고 만든 스크래치나 엔트리 같은 것을 도입하는 곳도 있는 모양이다.

덕분에 국내에는 독학할 만한 자료도 거의 없다시피 했지만 2011년경부터 하나 둘씩 외국 서적들이 번역되는 움직임을 보이고 있으며 사용자가 늘어나면서 국내 저자들이 쓴 책도 여럿 나오고 있다. 책이 나오기 전에는 학교나 문화강좌 커리큘럼 아니면 웹을 통해서 독학하는 것[6] 정도가 거의 유일한 루트였다.

거의 시망 수준의 인지도를 달리는 국내사정과 달리 해외에서는 의외로 좀 인지도가 있는 편이라[7] 다양한 라이브러리를 찾아볼 수 있으며 트러블 슈팅도 오피셜 사이트의 포럼을 중심으로 그럭저럭 활발한 편이다. 프로세싱을 가지고 Wii 리모컨이나 키넥트 같은 것을 다룰 수 있는 라이브러리도 있고보면 미디어 아트 작업에 필요한 라이브러리는 상당히 충실하게 갖추어져 있음을 알 수 있다. 정말 웬만한 라이브러리는 다 있다고 해도 과언이 아니다. 문제는 영어울렁증 2012년 들어서는 프로그래밍 언어 점유율 집계에서도 50위권 밖이지만 집계에 잡히기 시작하고 있는 것으로 보아 나름대로 사용자가 늘고 있는 추세인 듯.

프로세싱의 사용사례로, 뇌졸중으로 인해 언어기능에 장애가 생긴 어머니를 위해 키넥트와 프로세싱을 이용해 메일을 보낼 수 있는 시스템을 구축한 사례가 있다. 상세한 설명은 키넥트를 통해서 12년 전에 뇌졸중에 걸린 여성이 메일을 보낼 수 있게 되다를 참조. [8]

파생 프로젝트로 Arduino가 있다. 이쪽은 AVR 기반의 임베디드 프로그래밍 환경.

프로세싱은 새 버전이 나오고 있더라도 구 버전의 파이널 버전[9]은 계속해서 홈페이지에서 공개하고 있다. 왜냐하면 작업에 따라서 최신 버전이 아닌 1.x나 2.x를 사용해야하는 경우가 종종 있기 때문이다. 버전업에 따라 언어의 스펙에 조금씩 개정이 가해져서 구버전의 소스가 최신버전에서 동작하지 않는 경우도 생각보다 흔하고 오래된 라이브러리를 사용하는 경우 높은 확률로 버전을 타서 현행버전의 프로세싱에서는 에러를 뱉거나 정상적으로 돌아가지 않는다. 이런 경우에는 구버전을 사용할 수밖에 없다.

또한 윈도와 리눅스 버전의 경우 64비트와 32비트 버전이 별도로 공개중인데 점차 컴퓨팅 환경이 64비트로 가고 있으므로 현재 새로 프로젝트를 시작하고자 한다면 64비트도 무방하겠으나 좀 오래된 라이브러리를 가져다 쓰려면 32비트 버전을 사용해야하는 경우가 꽤 있다. 특히 윈도 버전 전용 라이브러리가 그러므로[10] 외부 라이브러리가 잘 안돌아가면 32비트/64비트 버전 중 어느 것을 사용해야하는지 잘 알아보자.

2011년부터 2.0 버전이 개발되기 시작하여 알파, 베타 테스트를 거쳐 2013년 6월에 2.0 정식버전이 발표되었다. 정식버전으로 오면서 아이콘, 로고, IDE 디자인 등이 일신되었고 사이트도 리뉴얼되었다. 2.0과 구버전과의 기본적인 호환성은 크게 문제가 없는 듯하나 일부 클래스가 삭제, 변경된 부분이 있고 종종 구버전용의 라이브러리가 문제를 일으키는 경우도 있다고 알려져 있으며. 렌더러가 변경되면서 화면 출력이 아주 미묘하지만 다르게 나오는 경우가 있어 같은 소스를 컴파일 했을 때 100% 동일한 결과가 나온다고 보장할 수 없다. 이런 문제로 인해 부득이하게 프로세싱 1의 최종버전인 1.5.1 버전(2011.5.15 발표)을 계속해서 사용해야 하는 경우도 드물게 생기는 듯.

2.0 버전의 대체적인 개선 사항은 이하와 같다.

이 외에도 자잘한 변화 및 개선점이 상당히 많다. 이 중 가장 반길만한 변화는 동영상 및 웹캠 관련 표준 라이브러리인 Video 라이브러리의 리뉴얼. 구버전인 1.5.1까지는 애플의 QuickTime Player의 기능에 의존하는 구조였는데, OS X의 경우에는 별 문제가 되지 않지만 윈도우즈에서는 매우 문제가 심각하다. 왜 문제가 심각한지는 QuickTime Player 문서를 보면 상세히 나오지만, 프로세싱 때문에 퀵타임 설치하고 MIME 타입 다 꼬이는 경험을 하고 나면 애플의 만행에 이를 갈게 된다(...). 더욱 더 흉악한 것은 '''QT Lite나 퀵타임 얼터너티브 같은 변종버전으로 우회도 불가능했다는 것. 엎친데 덮친 격으로 퀵타임이 없는 리눅스는 그냥 쿨하게 Video 라이브러리가 지원이 안됐었다.

이런 문제 때문에 GStreamer 기반의 외부 라이브러리인 GSVideo라는 것을 사용하는 사람이 많았는데, 프로세싱 2.0에서 리뉴얼된 Video 라이브러리가 바로 이 GSVideo의 개량버전. 덕분에 퀵타임 같은 멀웨어 설치를 하지 않아도 동영상/웹캠 관련 기능이 사용가능해졌으며 드디어 리눅스에서도 Video 라이브러리를 사용할수 있게 되었다. 부수적인 효과로 mov 파일만 지원하던 구버전보다 지원하는 포맷도 크게 늘었다. 다만 일부 사용자의 경우 GStreamer가 문제를 일으켜서 이유없이 에러를 뱉으며 Video 라이브러리를 사용할 수 없는 경우가 있다. 똑같은 소스인데 누구 컴퓨터에서는 돌아가고 누구 컴퓨터에서는 안돌아가서 사람 환장하게 만드는 에러였다.

2013년 10월에 공개된 2.1버전에서 IDE의 폰트를 직접 설정할 수 있는 기능[12]이 들어가면서 소스파일에 있는 한글 주석이 깨지는 현상이 발생한다. 환경설정에서 폰트를 굴림체 등의 한글이 지원되는 폰트로 바꾸면 깨지는 문제는 해결되기는 하는데, 이번에는 한글 자간이 반각 단위로 출력되면서 글씨가 서로 겹치는 기괴한 문제가 발생한다(...). 이 문제는 한자 등의 2바이트 전각 문자에서 공통적으로 일어나는 것으로 해당 문제는 개발자인 Ben Fry에게 리포트 되었으니 다음 버전에서는 개선될 것 같다. 그때까지는 이상이 없는 2.0.3 버전을 쓰던지 영문으로 주석을 달자(...). 그밖에도 2.1버전은 Serial 클래스에도 심각한 버그가 있었으나 이 문제는 2.1.1에서 해결. 하지만 전각문자 겹치는 문제는 해결이 안됐다.

사실 문자 입력관계로는 2.0.3 등의 이전 버전에도 문제가 있는데, 프로세싱 2가 되면서 일본어 등의 비알파벳계 문자들의 입력을 IDE에서 지원하는 옵션이 생겼지만 이 옵션을 켜면 윈도판 기준으로 한글의 경우에는 오히려 문자 입력이 꼬이는 기괴한 문제가 발생한다. 옵션을 끄면 1.5 시절처럼 타이핑 중간 과정이 제대로 출력되지 않지만 입력 자체는 제대로 된다. 프로세싱/아두이노 IDE의 한글입력 문제는 꽤나 고질적인 문제인데 국내에서는 사용자가 적어서 그런지 리포트가 제대로 되지 않는 듯.

프로세싱 2의 최종버전은 2.2.1(2014.5.19 발표). 이후에는 프로세싱 3로 이행했다.

프로세싱 1에서 2로 이행할 때처럼 알파/베타테스트를 진행하다 2015년 9월 30일 3.0 버전을 정식 릴리스했다. 1때보다 2때의 알파/베타기간이 (많이) 짧았는데, 3의 알파/베타기간은 더 짧았던 것을 보면 개발환경이 점점 좋아지고 있는 듯하다. 3가 되면서 로고 디자인도 새로 바뀌었다. 프로세싱 3의 변경점은 대략 다음과 같다.

내부적으로는 프로세싱 2때만큼 갈아엎어지진 않은 인상이지만 외형적인 변화(UI 등)가 제법 있는 편이다. 대부분은 프로세싱 2때와 비슷하게 사용할 수 있고 프로세싱 2의 스케치북을 3로 마이그레이션하는 기능도 제공한다고 한다. 자동완성 기능과 디버거만으로도 3로 옮겨갈만한 요인은 충분할 듯.

2011년 4월에 공개된 1.5버전부터는 안드로이드 프로그래밍도 지원하기 시작했다. 프로세싱으로 제작한 스케치를 JVM이 아닌 안드로이드의 Dalvik VM에서 구동할 수 있도록 컴파일해주는 기능인데, 추가로 안드로이드 SDK를 설치할 필요가 있다. 아직은 제약이 많은 편이지만 자신이 만든 프로그램이 안드로이드 폰이나 태블릿에서 돌아가는 것을 보면 나름 뿌듯하다. 몇몇 안드로이드 모드 전용 코드가 있기는 하지만 대체적으로는 표준 자바 모드에서와 거의 똑같이 코딩하면 된다.

참고로 구버전인 1.5에서는 안드로이드 모드가 존재는 하지만 사용할 수 없다.. 이런 기괴한 상황이 생긴 이유는 안드로이드 SDK가 업데이트 되면서 예전 버전의 프로세싱과 호환이 되지 않는 부분이 생겼기 때문. 1.5 버전이 처음 등장했을 당시의 SDK에선 제대로 돌아갔었다. 현행 안드로이드 SDK를 이용하는 경우 1.5~2.0a6 버전에서 안드로이드 모드가 정상동작하지 않는다. 안드로이드 모드가 필요한 경우에는 2.0을 쓰자.

참고로 1.5 당시 지원한 버전은 2.1(API 7)과 2.2(API 8)였으나 현재는 2.3.3(API 10) 및 그 이상만을 지원한다. 제작자 입장에서도 아직 사용자가 좀 있는 2.2 정도는 계속 지원하고 싶었는데 만들다보니 상황이 그리 여의치 않았던 모양. 프로요 지원 중단은 현재는 대부분의 사용자가 진저브레드 이상을 사용하기 때문에 큰 문제가 안될지 모르나, 정말 폰이 구려서 프로요에서 진저브레드로 업그레이드를 지원하지 않는다거나[15] iPhone 등의 비 안드로이드 계열 폰을 사용하는 사람이 프로세싱으로 안드로이드 작업하려고 싼 구형 공기계 중고로 사서 에클레어나 프로요 올려서 잘 쓰다가 진저브레드 업그레이드 지원 안해서 망했어요가 됐다거나 하는 경우는 종종 있는 듯 싶다.

안드로이드 모드 사용에 필요한 조건은 다음과 같다.

프로세싱 3의 경우에는 기본적으로 Java모드만 세팅되어있기 때문에 안드로이드 모드 사용을 위해서는 컨트리뷰션 매니저에서 안드로이드 모드를 따로 다운로드 받아야한다. 물론 SDK도 미리 설치해야하는 것은 당연하다. 이밖에도 3에서는 Python 모드나 R 모드(!) 같은 것도 추가되었다.

Calsign Labs의 APDE와 Kwipi의 에디터가 올라와 있다. 그중 APDE는 컴퓨터 자체에디터와 비교하고싶을 만큼 믿을 수 없는 퀄리티를 보여준다. 줄 수가 표시되지 않는 것만 빼면 완벽함.
개발사에서 만들어놓은 예제들도 높은 퀄리티를 자랑한다. 수학물
라이브러리 사용은 물론(PC 전용은 에러가 발생)이고 이클립스로 내보내기, 심지어는 버전관리 기능까지 있다고 한다.
빌드시 바로 안드로이드 기기에 앱을 깔아 사용할 수 있다.

교육기관명을 기준으로 가나다순으로 추가해주시고 간략한 커리큘럼 내용을 기록하여주십시오.

본래의 목적이 목적이니만큼 주로 공과대학교의 1학년 프로그래밍 입문 과목이나 시각/영상디자인 관련 학과의 커리큘럼으로 많이 채용되고 있다. 본 문서가 처음 만들어질 무렵에는 프로세싱을 커리큘럼으로 채용한 학과가 그리 많지 않았으나 점차적으로 늘어가는 추세이며 이에 따라 본 문단의 내용도 늘어나고 있다. 그만큼 고통받는 예비 디자이너들