구글검색 > 디자이너를 위한 프로그래밍

TODAY1,805 TOTAL2,153,191
사이트 이용안내
Login▼/회원가입
최신글보기 질문게시판 기술자료 동영상강좌

아두이노 센서 ATMEGA128 PWM LED 초음파 AVR 블루투스 LCD UART 모터 적외선


BASIC4MCU | 구글검색 | 프로세싱 | 디자이너를 위한 프로그래밍

페이지 정보

작성자 키트 작성일2017-08-24 10:24 조회1,691회 댓글0건

본문

 


3660040653_57bvkeZp_19644B344FE35B1F051CA6


티스토리에 프로세싱 강좌...비슷한 걸 연재할까합니다. 학부시절(아직 졸업은 안했습니다만...=ㅅ=) 수업시간에 같이 공부하던 친구들이 액션 스크립트나 프로세싱 프로그래밍 때문에 골머리를 썩이는 걸 보면서 이런 걸 한번 써봐야겠다, 라고 생각은 했었는데 꽤나 늦게 손을 대게 되었네요. 'ㅂ' 액션 스크립트는 책도 많이 나왔고 플래시는 하는 사람이 많으니까 별 문제가 없지만 프로세싱 쪽은 사용 계층이 좁은 편이라 그런지는 몰라도 상대적으로 자료가 좀 드물지요. 다행히 요즘 들어 하나 둘씩 역서는 물론이고 국내 저서까지 나오고 있어 반갑게 생각합니다.

아마 주된 내용은 제가 학부에서 배운 것을 기본틀로 하겠고요, 프로세싱 사이트의 문서들이나 프로세싱의 제작자들이 직접 저술한 입문서인 (역서명 <손에 잡히는 프로세싱>) 등의 커리큘럼을 참고해서 쓰게 되지 않을까 하네요. 덤으로 이것저것 뜯어다붙이고 말이죠. ㅎㅎ 

가능한한 제 친구들이 그랬듯이 쭉 학부 수업시간에 프로그래밍이라는 새로운 세계를 처음 접한 사람들이 이해하기 쉽게 쓰는 것이 목표입니다. 주된 타겟은 '인터랙션 수업 시간에 프로세싱을 처음 배우고 멘붕을 경험한 1,2학년 디자인 학부생'(....)으로 설정하고 있습니다. 제 입장도 '선생님'이 아닌 '멘붕한 후배들의 질문을 받아주는 학교 형' 정도가 되지 않을까 합니다('선생님'이 될만한 실력도 없고 저도 배워가는 입장이니까요. ^^). 제 친구나 후배들이 수업시간에 열받아서(-_-) 이 문서를 열람한다는 가정으로 강좌를 풀어나가려고 합니다. 죽이 될지 밥이 될지, 정말 이게 도움이 되는 강좌가 될지는 모르겠지만 일단 뭐...해보는 거죠. 

프로그래밍에 있어서는 저도 캐뉴비 비전문가고 실력이라고 해봤자 학교에서 배운 것+필요해서 추가로 조금 공부한 수준의 프로그래밍 실력이라 틀린 부분이나 어설픈 부분도 많으리라 생각합니다. 그래서 제목이 야매로 배우는 프로세싱 부끄럽지만 잘 아시는 분이 보신다면 잘못된 부분이나 빠뜨린 부분의 지적, 더 나은 접근방법에 대한 제언 등 많은 피드백을 부탁드리도록 하겠습니다. 

별 대단한 내용이 되진 않겠지만 프로세싱을 처음 공부하려고 하는 분들께 조금이나마 도움이 되었으면 합니다. 욕심을 부리자면 강좌를 읽은 (저나 제 친구들과 같은 입장의) 디자인 학부생들이 수업시간에 무슨 외계언어^^; 같은 프로세싱 때문에 스트레스를 받는 것이 아니라 '프로그래밍이라는 거 생각보다 재미있는 거였네?' 라는 생각을 가지기 시작하게 된다면 대성공이라고 스스로도 만족할 수 있을 거 같습니다. :)





 

여러분은 프로세싱을 언제, 어떤 이유로 처음 접하셨나요? 디자인학과나 그 비슷한 관련학과에 진학하면서 인터랙션 관련 수업을 들으면서 처음 접하신 분들이 많을 거 같습니다. 아니면 취미로 프로그래밍을 공부하시려고 시작하신 분도 계실테고 여러가지 이유가 있겠지요. 괜찮으시다면 덧글로 난 이래서 시작했음요~하고 경험담을 달아주셔도 재미있을거 같습니다. :)

제 경우엔 커뮤니케이션 디자인을 늦깎이로 전공하게 되면서 1학년 때 학교 선배의 작업을 구경하면서 처음 봤던거 같습니다. 신기해하면서 "우와 이거 뭐에요?"라고 묻는 제게 "4학년 되면 수업시간에 다 배워요."라고 선배가 얘기를 했었는데 그 이듬해였나 담당하셨던 교수님께서 다른 학교로 가시는 바람에 상설되어있던 프로세싱 수업이 없어져버렸다는 이야기를 들었지요. =ㅅ=;;

그러다가 3학년 수업시간에 아르두이노를 배우면서 잠깐 프로세싱의 기초도 함께 배우게 됐었는데, 그걸 바탕으로 그 해 졸업작품을 하는 분들 작업을 도와주면서 소스코드를 보고 전체적인 흐름을 터득하게 됐던걸로 기억합니다. 그런데 후배들을 보니까 요즘은 아예 1학년때부터 프로세싱을 배우고 있더군요. 후배들 과제를 보니까 제가 3학년때 했던 과제보다 수준이 높아요! 저는 수업시간에 듣도 보도 못한 기능들을 막 쓰고있고...과연 장강의 뒷물결은 앞물결을 밀어낸다는 옛말이 맞나봅니다. :)

여담이지만 저는 처음 '프로세싱'이라는 단어를 들었을 때는 이게 어떤 '프로그래밍 언어'라는 생각을 못했습니다. 보통 컴퓨터쪽 바닥에서 'processing'이라는 단어는 고유명사가 아닌 '(가공)처리' 정도의 뜻을 가진 일반 명사로 쓰일 때가 많거든요. '이미지 프로세싱'이라던지...덕분에 구글링할때 간혹 애로사항이 꽃피는 문제점이 있습니다. ㅠㅠ 상관없는 아티클이 많이 걸려들거든요(왜 이름을 이런 흔한 단어로 지어설랑은...ㅠㅠ).

어쨌건 강좌 첫 꼭지니까 일단 프로세싱에 대한 소개부터 하고 넘어가볼까 합니다. :) 괜찮겠죠?

 

1.1. 프로세싱이란?

프로세싱은 2001년부터 당시 MIT 미디어 랩의 대학원생이었던 '벤 프라이(Ben Fry)'와 '케이시 리아스(Ceasy Reas)'가 개발하여 오픈소스로 공개하고 있는 프로그래밍 언어입니다. 저 개발자 두 사람은 미디어 아트 분야의 선구자인 '존 마에다(John Maeda)' 교수의 학생들이었는데, 프로세싱은 마에다 교수의 'Design By Numbers'  프로젝트(현재는 URL이 연결되지 않습니다)에서 영향을 받아 만들어지기 시작했다고 합니다. 

원래 DBN 프로젝트의 목적은 기술적 기반이 없는 사람들도 쉽게 프로그래밍 베이스의 뉴미디어 인터랙션 작업을 할 수 있도록 하는 것이었다고 합니다. 프로세싱은 그러한 DBN 프로젝트의 목적을 계승하고 있습니다.

 

3660040653_7IsmCPS6_117D56454FE36DAB134701

▲ 이것이 DBN. 어딘가 모르게 오늘날의 프로세싱하고 닮았습니다.
(이미지 출처 : http://www.moongift.jp/2007/12/design_by_numbers/)

 

이 프로젝트는 빠르게 호응을 받아 오늘날에는 많은 협력자들이 프로젝트에 다양한 공헌을 하며 미디어아트 분야에서는 가장 보편적인 프로그래밍 도구로 자리잡기에 이르렀습니다. 프로세싱의 첫 정식 버전(1.0)은 7년이 넘는 알파/베타 테스트 기간을 거쳐서 2008년 11월에야 처음으로 나왔는데, 알파 버전일때부터 이미 많은 학교에서 미디어 아트 과정을 위한 프로그래밍 도구로 널리 쓰이고 있었거든요. 

프로세싱 뿐만 아니라 와이어링(Wiring)이나 아르두이노(Arduino)와 같은 프로세싱에서 파생한 프로젝트 역시 좋은 반응을 얻어 널리 쓰이고 있습니다. 한마디로 요약하면 프로세싱은 '디자이너와 아티스트의 인터랙션 작업을 위한 쉽고 편리한 프로그래밍 언어'라고 할 수 있겠네요. :D 


1.2. 프로세싱 언어의 특징

■ 쉽고 흥미롭다

기술적으로 초보적인 수준에 있는 사람들도 간결한 문법으로 배우기 쉽고, 주로 시각적이고 인터랙션이 있는 작업을 쉽게 만들 수 있는 것이 프로세싱의 특징입니다. 의 서두에서 저자들은 프로세싱을 만들게 된 경위에 대해서 대강 이런 이야기를 하고 있습니다. 

프로그래밍 코스는 일반적으로 구조와 이론을 먼저 익히는데 초점이 맞추어져 있습니다.  마치 맛없는 야채를 다 해치우고 나서야 비로소 즐길 수 있는 디저트처럼 어떠한 시각적인 것 - 인터페이스라던가, 애니메이션이라던가, -이건 대개는 몇 주씩 걸리는 알고리즘이나 방법론의 학습 이후로 미루어지고는 하지요. 

저희는 많은 친구들이 이러한 코스에 도전했다가 첫 번째 수업 직후나 첫 과제 마감 전날의 긴 밤을 좌절로 지새우고 나서 프로그래밍을 접는 걸 오랫동안 보아왔습니다. 그 친구들이 처음에 가졌던 컴퓨터 작업에 대한 호기심이 사라진 이유는 처음에 배운 것들과 그들이 만들고자 하는 것 사이에 연결점이 전혀 보이지 않았기 때문입니다.

제가 영어를 매우 못하기 때문에ㅠㅠ 국내 번역서인 <손에 잡히는 프로세싱> 쪽의 번역이 훨씬 매끄럽지만 옛날에 책 나오기 전 문장 깔작 번역해놓은거 아까워서 제 번역으로 옮겨보았습니다(...응?). 

저는 이 문장을 읽고 "과연!"이라고 생각했었지요. '만들고자 생각한 것', 특히 누구나 하고 싶어하는 시청각적인 표현과 인터랙션(대표적으로 게임이라던가요!)을 컴퓨터 프로그램을 통해 보여주려면 상당히 많은 짬밥(?)이 필요합니다. 기술적으로 알아야할 것도 굉장히 많고 그것을 위해서는 일견 그것과 전혀 상관없어보이는(하지만 깊은 상관이 있는) 요소들을 밑에 깔고 들어가야하는데 그게 그렇게 만만한 일이 아니지요. 

그래서 전통적인 첫 프로그래밍 과제들은 전혀 시청각이나 인터랙션 그런 것과는 거리가 멉니다. 그냥 수나 문자열로 된 '데이터'를 처리하는 방법, 그리고 저자들이 얘기한 '알고리즘이나 방법론' 같은 것부터 배우는 거죠. 기술적으로 밑에 깔고 들어갈 것들부터 철저하게 다져 올리는 이런 방식이 전문적인 프로그래머를 양성하는 커리큘럼으로서 타당할지는 모르겠지만 까놓고 얘기해서 솔직히 재미는 없습니다. 물론 그게 재미있다는 공돌이사람도 있기는 하지만 적어도 다수의 목소리는 아닌 거 같습니다. 특히 디자인과 같은 이공계 바깥의 분야에 종사하는 사람들은 더 그렇게 느끼는 거 같습니다. 결국 저희 같은 디자인 전공자들이 그런 전통적인 커리큘럼과 프로그래밍 언어를 사용해서 인터랙션 작업을 하기에는 기술적인 벽이 너무나 높게 다가옵니다. 프로세싱은 이러한 벽을 허물기 위한 언어로서 고안되었습니다.

잠깐 이야기가 새지만, 지금 학부를 전공하는 20대 정도이신 분들은 모르시는 분들도 많겠지만 제 또래(제가 좀 학교를 늦게 들어가서 동기들보다 늙었습니다. 어흑...ㅠㅠ)나 그보다 더 연식이 되신(^^;;) 분들은 소싯적에 8비트 컴퓨터나 IBM-PC/XT 컴퓨터로 베이식(BASIC : Beginner's All-purpose Symbolic Instruction Code) 언어를 배운 기억이 있으신 분도 계실지 모르겠습니다. 표준 외국어 표기로는 '베이식'이 맞지만 그땐 다들 '베이직'이라고 불렀죠. '애플 베이직'이나 'GW 베이직' 같은 거 말이죠. 지금은 잘 사용하지 않는 옛날 프로그래밍 언어지만 베이직을 사용하면 굉장히 쉽게 화면에 그림을 그릴 수 있었고 조금만 열심히 공부하면 이런저런 재미있는 표현들을 하거나 심지어 간단한 게임도 만들 수 있었지요.   

저 시절에는 어린이나 청소년이 컴퓨터를 만진다면 BASIC이나 Logo와 같은 교육용 언어로 프로그래밍을 배우는 일이 많았습니다. 사실 그 시절 컴퓨터로는 할만한 게 그런 거 밖에 없기도 했고 컴퓨터 자체가 귀해서 컴퓨터를 공부하는 학생 수가 적기는 했지만, 어쨌거나 오히려 그런 쉽게 접근할 수 있는 언어들의 수요가 있었는데 지금은 오히려 프로그래밍 자체가 전문가들만이 하는 영역으로 축소되고 언어도 전문적인 것들만 살아남았다는 생각이 들때가 있습니다. 프로세싱의  저자들 역시 어린 시절에 Logo와 BASIC을 썼었던 모양인데, 이 언어들의 '쉽게 시각적이고 흥미로운 프로그램을 작성할 수 있는' 특성이 프로세싱에 영감을 주었다고 하는군요. 과연 비슷한 데가 있는거 같습니다. 

재미삼아서 어렴풋한 기억을 살려서(하도 오래돼서 가물가물거립니다. =ㅅ=;) 제가 사용했던 8비트 컴퓨터인 MSX에서 BASIC으로 화면에 사각형과 원을 그리는 프로그램을 만들어봤습니다. MSX 에뮬레이터(일종의 가상 컴퓨터)로 실행시켜 결과화면도 올려봅니다.

 

3660040653_NURCwB9T_1239703D4FE3BF4007AAE9 3660040653_dJLwS3Ir_16327D3D4FE3BF400B0F4C 

 

프로그램 코드 앞에 붙어있는 숫자는 '행번호'입니다. 프로그램 수정을 하거나 프로그램 내에서 여기로 가라 저기로 가라 하는 명령을 내릴 때 위치를 지정하기 위한 목적으로 붙어있던 건데 지금은 세상이 좋아져서 행번호 같은 건 필요없어졌습니다. 

심심해서(...) 프로세싱으로도 같은 그림을 그리는 프로그램을 만들어봤습니다. 소스 내용을 이해하지 못하셔도 상관없으니 내용은 신경쓰지말고 프로세싱 프로그램은 이렇게 생겼구나~하는 마음으로 한줄씩 죽 읽어내려가보세요. ^^ 그냥 눈에 익힌다는 느낌으로 보시면 됩니다.

3660040653_xtuOYIe3_2018DC334FE3C35F0B29AD

한마디 한마디가 뭔지는 잘 모르겠더라도 아무튼 몇줄 안되는 코드로 이런 그림을 그릴 수 있다는 게 신기하지 않나요? (...별로 안 신기한가... -_-ㅋ) 좀 더 들어가면 사용자의 입력에 반응하는 인터랙션 프로그램 같은 것도 별로 어렵지 않게 만들 수 있습니다. 오히려 주류 언어인 C++이나 Java 같은 언어는 프로세싱이나 BASIC과는 비교가 안될 정도로 강력한 힘을 가졌지만 그만큼 어려워서 이런 표현을 쉽게 할 수가 없지요. 여러분이 앞으로 맞닥뜨리게 될(^^;) 난관인 프로세싱의 문법 역시 Java를 바탕으로 삼긴 했지만 훨씬 간결하고 쉽게 되어 있습니다. 복잡하고 당장은 몰라도 되는 것들은 모두 프로세싱이 알아서 처리해주면서 사용자에게는 그 부분을 가려서 보여주지 않기 때문이지요.

BASIC과 함께 프로세싱에 영향을 준 Logo 라는 언어도 짧은 명령 몇 줄로 그림을 그리는 것이 가능했는데, 초창기에는 그래픽스를 표현 가능한 디스플레이가 귀하던 시절이라 '터틀'(turtle) 이라는 로봇이 명령에 따라서 바닥에 그림을 그렸다고 합니다. 저도 Logo를 써보지는 않았지만 사진을 보면서 당시의 아이들이 터틀을 보면서 얼마나 신기해했을까 하는 생각을 했었습니다. ^^ 그 전통으로 지금도 Logo는 화면에 그림을 그릴 때 거북이 모양의 커서가 표시된다고 하는군요.

 

3660040653_TyiUbefG_1507CF3F4FEFAEBD081C33

▲ 터틀은 이렇게 생겼습니다.
(이미지 출처 : http://www.bfoit.org/Intro_to_Programming/IntroCmds.html)

 

제가 목격한 바로도 실제로 프로그래밍을 처음 공부하는 학생들이 오오! 하면서 신기해하고 흥미를 가지는 부분은 이런 시각적인 표현이나 컴퓨터와 상호작용을 하는 인터랙션 부분인거 같았습니다. 변수가 어떻고 제어문이 어떻고 하는 딱딱한 얘기는 대개 재미없어 하는 게 정상이죠. 특히나 '눈에 보이는' 것들을 디자인하는 사람들 입장에서 구체적으로 눈에 보이는 것도 없고 머릿속에 추상적인 객체나 논리구조를 그려야 하는 부분이 재미없게 느껴지는 것은 당연할지도 모르겠습니다. 

물론 저자들의 비유를 빌리자면 맛있는 디저트 같은 것만 골라 먹을 수는 없는 것이고 결국 어쩔 수 없이 먹어야 하는 '맛없는 야채' 부분이 없을 수는 없을 겁니다. 결국은 프로세싱도 '프로그래밍 언어'니까요. 야채에 드레싱도 좀 하고 맛있는 과일도 곁들이고 해서 먹는다면 맛없는 야채도 맛있게 싹 비울수 있게 되겠지요. 그 부분이 프로그래밍을 교육하는 사람들이 고민하는 지점이기도 하고, 프로세싱 역시 그런 부분을 고려한 언어인 것 같습니다. 그뿐만이 아니라 영상 처리나 3D 그래픽스 같이 꽤 복잡한 고급기능도 비교적 쉽고 간단하게 처리할 수 있게 되어 있어서 여러모로 디자이너나 아티스트가 자신의 프로젝트나 프로토타입 제작을 위해 사용하기에 적합한 언어라고 할 수 있겠습니다. 

요즘은 프로세싱보다 더 쉬운 놈들도 속속 나오는 무서운 세상(?)이 되었습니다만서도. ㅎㅎㅎ

 

■ 다양한 플랫폼에 대응한다

 

프로세싱은 공식적으로 윈도, Mac OS X, 리눅스(x86)의 세 가지 운영체제에 맞추어 배포하고 있습니다. 왜안BSD요/왜안솔라리스요 하시면 골룸. 빌드해서 쓰세요. 웬만큼 특이한 컴퓨터 환경을 구축한 사람이 아니라면 누구나 프로세싱을 이용하는데 불편함이 없다는 이야기입니다. 특히 일반인에 비해 Mac 사용자의 비율이 높은 디자인 전공자에게 있어서 Mac OS X의 원활한 지원은 상당한 장점이라고 할 수 있겠습니다. 덤으로 공짜라는 장점까지! +_+

그리고 프로세싱으로 만든 결과물은 윈도, 맥 OS, 리눅스 어디서든 똑같이 작동합니다. 만들 땐 윈도에서 만들고 맥에서 아무런 수정없이 작동시킨다던지 하는 것도 웬만해선(드물게 안 웬만할 때가 있기는 있습니다. =ㅂ=;) 가능합니다.  별거 아닌 거 같지만 사실 이건 대단한 장점입니다. 다른 언어들은 이렇지 못한 경우가 더 많거든요. 이것은 프로세싱이 자바의 힘을 빌리고 있는 덕택이기도 합니다. 이건 원래 자바의 장점이거든요. 자세한 건 나중에 설명할 기회가 있을 겁니다. 

심지어는 1.5버전부터는 프로세싱을 안드로이드 개발도구로 활용할 수도 있게 되었습니다. 내가 만든 프로그램을 큰 손질 없이 폰에서도 돌려볼 수 있는거지요. 어쩌면 가장 쉬운 안드로이드 앱 개발 환경일지도 모릅니다. ^^ 아직 개발 중이지만 2.0 버전에서는 자바 스크립트로 결과물을 만들 수 있어서 작업을 웹에 쉽게 게시할수도 있게 될 겁니다. 그밖에도 아이폰 기반의 iProcessing이나 웹기반의 Processing.js 같은 프로젝트들도 있고보면 앞으로도 프로세싱을 사용할 수 있는 환경은 더더욱 늘어날 것으로 예상됩니다. 

 

■ 따라서 사용자(=정보)가 많다!

이건 좀 상대적인 얘기긴 합니다만, 상기한 장점 덕에 프로세싱은 사용자가 많습니다. 학교 등지에서 커리큘럼화된 곳도 많고 프로세싱 공식 사이트의 포럼도 비교적 활발하게 정보가 오가는 편입니다. 키넥트나 Wiimote 같은 외부 장비 연동을 비롯한 수많은 목적의 라이브러리가 개발되고 있어서 웬만큼 필요한 기능은 쉽게 라이브러리를 찾아서 가져다쓸 수 있고, 프로그래밍을 하다가 문제가 생겼을 때도 구글링을 해보면 웬만하면 거의 해결책을 찾아볼 수 있을 정도입니다. 웬만해선 선배 프로그래머들이 다 한번씩 당해보는(?) 문제인 경우가 많으니까요.

비슷한 목적(미디어 아트 지향)의 다른 프로그래밍 도구들과 비교하면 확실히 프로세싱 쪽이 필요한 정보나 라이브러리를 쉽게 구할 수 있는 거 같습니다. 예를 들어 저는 개인적으로 openFrameworks나 vvvv를 한번 배워보고 싶었는데, 이놈의 물건들이 하는 사람이 별로 없다보니 정보가 정말로 없더군요. ;ㅅ; 특히 vvvv는 정말 쉬운 구조기도 하고 튜터리얼도 프로세싱만큼은 아니지만 나름 잘되어있어서 배우려고 맘먹으면 못배울 건 없긴 하겠습니다만 어쨌거나 그랬습니다. (사실 자료는 핑계고 게을러서 못배웠다는 것이 진실에 가깝긴 합니다 어흑어흑)

그런데 왜 앞서 상대적이라는 얘기를 했느냐면 우선 정보가 많다는 장점은 영어를 잘하면(!)이라는 전제가 붙습니다. 외국에서는 알게 모르게 제법 쓰이는 언어라서 영어를 잘 알면 프로세싱 포럼이나 다른 커뮤니티에서 많은 정보를 얻을 수 있고, 정말 해결이 안되는 문제는 프로세싱 포럼에 질문을 올리면(당연히 영어로) 대개 친절하게 답변을 받을 수 있습니다. 그러나 아직 국내에서는 사용자가 극히 적은 편이라(딱 저와 여러분 같은 사람들만 쓴다고 생각하면 틀림없습니다. ㅠㅠ) 커뮤니티 활동도 그다지 활발하지 않은 편이다보니 한글로 된 자료가 드물고 어디 물어볼데도 별로 없고 그렇습니다. 비슷한 목적으로 많이 쓰이는 액션 스크립트와 비교해보면 뭐...좀 서럽습니다. ㅠㅠ 저도 영어는 검정 것은 글씨요 흰 것은 종이라 수준이다보니 좀 괴롭더군요. ㅠㅠ

그리고 솔직히 사용자가 많다고 해봐야 C++이나 자바, 심지어는 플래시 액션 스크립트와 같은 메이저급 언어에 비하면 매우 적은 사용자 수인 것은 틀림없습니다. C++이나 자바처럼 넘쳐나는 자료와 정보들의 혜택을 받는 언어는 못되지만, 적어도 필요한 정보나 자료는 구글링하면 대충 다 나오는 정도는 된다고 보시면 될거 같네요. (그러니까...찾아도 정보를 구하기가 힘든 언어나 프로그램도 세상엔 꽤 많답니다. 마이너리티의 설움이죠. 억울하면 메이저의 길을 가야합니다. ㅠㅠ)

쓰다보니 꽤 길어졌는데 아무튼 프로세싱은 이런 언어랍니다. :D 다음 꼭지에서는 직접 프로세싱을 간단하게 만져보도록 하겠습니다. 빨랑빨랑 써야는데 게으름 피우다보니 업데이트가 하염없이 늦네요. ㅎㅎ

 

 

 

이번에는 프로세싱을 직접 설치하고 사용해보도록 하겠습니다. 설치래봐야 별거 없으니 차근차근 따라오시면 됩니다. ^^

2.1 입수 및 설치 방법

프로세싱은 오픈소스/프리웨어로 누구에게나 공개되어있고, 무료로 받아서 사용할 수 있습니다. 

http://processing.org/download/

위의 링크는 프로세싱 공식 사이트의 다운로드 페이지입니다(프로세싱 사이트는 튜토리얼 같은 볼게 많으니 한번 둘러보시는 것도 좋겠네요. ^^). 여기서 자신의 컴퓨터 환경(Windows, Mac OS X, Linux)에 맞는 버전을 다운로드 받아서 사용하시면 됩니다. 이 글을 작성하는 현재의 최신 안정 버전은 1.5.1(2011.5.15)이고, 차기 버전인 2.0 beta 3이 공개중입니다. 둘중 아무거나 받아 사용해도 상관 없습니다만(베타 버전도 잘 돌아갑니다. 앞서 얘기했듯이 1.0 나오기 전 알파/베타 시절부터 학교에서 교육용으로 굴려먹었던게 프로세싱입니다. =ㅅ=;;) 일단 제가 사용하는 버전은 1.5.1이라 기준 역시 그쪽임을 미리 일러드립니다.

윈도 버전은 별도의 인스톨러를 제공하지 않으니 그냥 zip으로 압축된 파일을 적당한 폴더에 풀어서 사용하시면 됩니다. 윈도 버전만 without Java라고 되어있는 버전이 따로 있는데, 이것은 용량이 적은 대신 바로 실행이 안되고 추가로 자바 프로그래밍을 위한 환경(JDK라고 합니다)이 미리 세팅돼있어야 됩니다. 그렇지 않으면 아예 실행이 안되므로 처음 사용하시는 분은 Without Java 버전이 아닌 일반 버전을 받아주시기 바랍니다. 

왜 자바인지 뭔지가 얽혀있느냐하는 의문을 가지실 분이 계실까 싶어 부연하면 '자바'(Java)는 현재 가장 주류에 속한다고 할 수 있는 프로그래밍 언어인데, 프로세싱은 이 자바를 바탕으로 삼아 만들어졌고, 실행할 때도 자바의 힘을 빌리고 있는 약간 특이한 언어입니다. 프로세싱을 만드신 분들이 '프로세싱은 자바의 한 사투리'라는 재미있는 표현을 쓰시기도 하던데, 꽤 그럴듯한 표현이라고 생각합니다. ^^ 그런데 자바로 만든 프로그램들은 자바 프로그램을 실행하기 위한 환경(JRE라고 합니다. 걍 자바 가상머신, 혹은 JVM이라는 이름으로 부르기도 합니다만 엄밀하게 말하면 자바 가상머신은 JRE를 이루는 핵심요소입니다)이 미리 설치되어있을 필요가 있습니다. 

워낙 요즘은 자바가 보편적인 언어라 맥OS나 리눅스 같은 다른 운영체제에는 JRE나 그에 준하는 자바 환경이 내장되어있는데 윈도에는 법적 문제로 인해 자바 관련 기능이 빠져있습니다. 윈도 XP 초창기까지는 Mac OS X처럼 자체 자바 환경이 내장돼있었는데 마이크로소프트가 자바와 관련한 계약위반으로 썬 마이크로시스템즈(자바의 개발사)에게 소송을 당해서 패소한 뒤로는 해당 기능을 빼버리고 사용자가 직접 썬의 정품(?) 자바를 설치하게 하는 정책을 취하고 있습니다. 이에 따라 프로세싱은 컴퓨터에 익숙지 않은 사용자가 번거롭지 않도록 필요로 하는 자바 관련 패키지를 프로세싱 내부에 포함해서 배포하고 있는 것입니다. 프로세싱 하나 때문에 JDK를 설치하자니 번거롭기도 하고 용량도 크고 하니 서비스(?) 해주는거지요. without Java 버전은 JDK를 따로 설치해서 쓰고 있는 고급 사용자들을 위해 이 부분을 뺀 것인데 그래서 without Java 버전이 용량이 좀 더 작습니다.

그리고 요즘은 메모리 환경이 4기가바이트를 넘어가는 컴퓨터가 흔해지면서 64비트 윈도가 일반화 되어가고 있고, 프로세싱 2.0 베타는 Windows 32bit / Windows 64bit 두가지 버전을 모두 제공하고 있습니다만, 64비트 윈도를 사용하고 있다고 하더라도 웬만하면 32비트 버전으로 다운로드 받아서 사용하시는 것을 권장합니다. 32비트보다 64비트 응용 프로그램이 속도나 메모리 활용 측면에서 유리한 것이 일반적이기는 합니다만, 프로세싱의 경우에는 어차피 64비트의 이점을 활용할 수 있는 부분이 별로 없고 64비트 버전은 라이브러리 호환성 문제가 가끔 생기기 때문에 트러블 없이 쓰려면 32비트 버전 쪽이 좋습니다. 

Mac OS X는 예전부터 자바를 기본 프로그램 환경으로 밀어주고 있었기 때문에 자체적으로 자바랑 관련된 필수요소들이 운영체제에 다 내장되어있습니다(애플은 썬한테 소송을 안당해서...-_-). 덕분에 Mac OS X 버전 프로세싱은 자바 관련 패키지가 따로 들어있지 않고 용량도 작지요. 별다르게 신경쓸만한 부분이 없으니 좋네요. Mac OS X 버전은 1.5 버전부터는 .app 형태로 배포되고 있으니 그냥 간편하게 다운로드 받아서 응용 프로그램으로 옮겨서 쓰면 됩니다.  리눅스 버전도 RPM 등으로 따로 패키징하지 않았기 때문에 배포하는 tar.gz 파일을 단순히 압축 풀어 쓰시면 됩니다. 우분투(Ubuntu)에서 테스트 해봤는데 잘 되더군요. 참 쉽죠? :)

설치는 다 되었나요? 그럼 이제 다운로드한 프로세싱을 실행해봅시다.

 

 

2.2 PDE (Processing Development Environment)

용어를 섞어서 쓰고 있기는 하지만 엄밀히 말한다면 '프로세싱'이라는 것은 우리가 공부하고자 하는 프로세싱 언어 그 자체를 의미하고, 우리가 금방 다운로드 받은 프로그램은 'PDE'(Processing Development Environment, 프로세싱 개발 환경)라고 부르는 것입니다. 비유가 정확할지 모르겠지만 '프로세싱'을 '한국어'라고 하는 (추상적인) 언어 체계 자체에 비유한다 면 'PDE'는 '한글'이라던지 '국어사전'이라던지 '맞춤법'이라던지 기타 등등 한국어를 잘 사용하기 위해 필요한 것들의 종합 패키지 같은 거지요. (아 좀 미묘하게 비유가 안맞는데 이거...적당한 비유가 생각나면 수정하겠습니다. =ㅅ=;) 저도 앞으로 프로그래밍 개발 환경으로서의 프로세싱을 가리킬때는 PDE라는 표현을 쓰도록 하겠습니다.

원래 프로그래밍을 할때 쓰는 'IDE'라고 하는 것이 있습니다. IDE란 'Integrated Development Environment'의 줄임말입니다. 우리 말로는 보통 '통합 개발 환경'이라고 번역합니다만 이쪽 바닥 말들이 대개 번역어가 좀 찬밥신세라('운영체제'라는 단어랑 'OS'라는 단어 어느 쪽이 사용빈도가 높은지만 봐도...=ㅅ=;) 그냥 IDE라고 부르는 게 일반적입니다. IDE란 그냥 앞뒤 다 잘라내고 거칠게 말하면 '컴퓨터 프로그램을 개발하기 위한 프로그램'이라고 생각하시면 됩니다. 로봇공장에서 로봇을 만드는 로봇(?) 같은 이미지를 떠올리시면 되려나요. ^^;

여기서 굳이 '통합'이라는 표현을 쓰는 이유는 IDE라는게 나오기 전 호랑이 88라이트 피우던 쌍팔년도 시절 옛날 프로그래밍 환경이 별로 안통합(...)이었던데서 유래합니다. 지금은 당연히 IDE 하나만 있으면 프로그래밍을 할 수 있지만 옛날엔 프로그램 개발에 필요한 각개 기능들이 다 따로 떨어진 별개의 프로그램이었거든요. 프로그래밍에 관심이 있으신 분이라면 한번 쯤은 들어보셨을지도 모르는 '비주얼 스튜디오'나 'XCode', '이클립스' 같은 것들이 대표적인 IDE라고 할 수 있고 혹시나 플래시로 액션 스크립트 프로그래밍을 해보신 경험이 있는 분이라면 그 플래시의 액션 스크립트 개발 환경을 떠올리시면 이것도 대강 IDE의 개념에 들어맞습니다(그래서 플래시 프로그램을 플래시 IDE라고 부르는 경우도 있습니다). 우리가 금방 설치한 PDE는 프로세싱 프로그램 개발을 위한 프로세싱 전용 IDE인 셈이지요. 

비주얼 스튜디오나 XCode 같은 본격적인 IDE는 큰 프로젝트를 관리해야하다보니 정말로 어디에 무슨 기능이 있는지도 다 모를 정도로 많은 기능들을 갖고 있습니다만 PDE는 IDE 치고는 정말 단순하고 최소한으로 필요한 기능만을 갖춘 미니 IDE입니다. 기존의 IDE에 익숙한 사람에게는 '이게 뭐야?' 싶을 정도로 간소하지만 처음 배우는 사람의 입장에서는 오히려 간소한 만큼 금방 익숙해질 수 있다는 이점이 있습니다(여담이지만 비주얼 스튜디오 같은 전문적인 IDE는 처음 돌려보면 워낙 복잡하고 기능이 많아 초보자는 뭐 만들어보기 전부터 기가 팍 질립니다. -_-). 그래도 있을 건 다 있고, 이런 쪽이 프로세싱이라는 언어의 특징이나 사상과 어울린다고 생각도 됩니다. :) 일단 우리는 쉽게 가는겁니다.


3660040653_d72SO50Y_152F853850108333418DAA

▲ 비주얼 스튜디오 2010 프로페셔널입니다. 뭔가 매우 거창해보입니다. 실제로도 매우 거창합니다. -_-;

 

우선 다운로드 받은 PDE를 실행해봅시다. 예쁜 프로세싱 로고가 나오다가 곧 PDE가 뜰겁니다. 척 보기에도 메뉴도 몇 개 안되고 이쁜(?) 아이콘도 있고 크게 어렵지는 않아보입니다. 물론 뭐가 뭔지 모르는 지금에는 좀 무섭게(?) 생각될 분들도 계시겠지만 정말로 PDE 자체의 기능은 딱 프로세싱으로 작업하는데 필요한 것들만 있기 때문에 크게 복잡하지 않습니다. ^^

 

3660040653_Uw0Onh6H_203C4C45501083E9286518

▲ 다행히 우리의 PDE는 거창하지 않습니다. ^^

 

미리 말씀드리지만 앞으로 모든 설명은 윈도용 1.5.1버전을 기준으로 삼도록 하겠습니다. 가장 많이들 쓰시는 운영체제기 때문이기도 하지만 일단은 제가 주로 쓰는 게 윈도다보니...-_-; 아마도 우리 업계(?) 특성상 Mac OS X 버전을 쓰시는 분들도 꽤 많이 계실 거 같지만 윈도랑 크게 다를 건 없으니 걱정은 하시지 않아도 됩니다. 다만 단축키 같은 세세한 부분에서 약간 차이가 있을 수도 있는데 이 부분은 Mac OS X 사용자분들께는 죄송하지만 적당히 알아서 변환(?)해주시면 감사하겠습니다. :)  (제가 맥북만 한대 있었어도...ㅎㅎ)

 

3660040653_AYCsTd1z_125AB241501084B71F8FCE

▲  PDE의 구성요소들입니다. (윈도 버전)

 

 

PDE를 이루는 인터페이스 구성요소들과 그 명칭은 위와 같습니다. 먼저 각 구성요소들에 대해 설명을 드리도록 하겠습니다. (그래서 언제 프로그래밍을 시작하는거야! 라고 짜증내시는 분들이 보이는 거 같은 환각이...아아...=ㅅ=)

 

2.2.1 메뉴 (menu) 

프로세싱 사용에 필요한 메뉴들이 들어있습니다.

  • File / 파일 열기/저장, 예제, 내보내기, 환경설정 등에 관련한 기능들입니다.
  • Edit / 복사, 붙여넣기, 들여쓰기 등 편집에 관한 기능들입니다.
  • Sketch / 실행, 멈춤, 라이브러리 가져오기 등 스케치에 관한 기능들입니다.
  • Tools / 폰트만들기, 컬러 선택 등 보조도구들이 들어있습니다.
  • Help / 레퍼런스, 트러블슈팅 등 여러 상황에 대한 도움말들입니다. 하지만 다 영어라는게 함정

'스케치'라는 단어가 좀 생소할텐데, 프로세싱에서는 사용자가 작성하는 프로그램을 가리켜 '스케치'라고 부릅니다. 다른 언어나 프로그램의 '프로젝트' 개념과 거의 유사하다고 생각하시면 됩니다. 그리고 이 스케치들이 저장되는 폴더를 '스케치북'이라고 부릅니다. 왠지 디자이너와 아티스트들이 사용하는 프로그래밍 언어다운 센스랄까요. ^^;

스케치북 폴더는 윈도의 경우에는 기본적으로 윈도 XP라면 내 문서-Processing 폴더, 윈도 비스타/7이라면 라이브러리-문서-Processing 폴더로 지정됩니다. 실제 경로는 File-Preferences에서 Sketchbook Location에서 확인 및 변경이 가능합니다. 

맥의 경우엔 메뉴 바가 OS 수준에서 통합되어있다보니 메뉴 부분이 PDE에는 빠져있고 다른 응용 프로그램 처럼 OS 상단에 기본 메뉴들이 붙어있습니다. 개인적으로는 한참 맥을 쓰고 있을때는 괜찮은데, 윈도 쓰다가 간만에 맥을 쓰면 이게 그렇게 헷갈릴 수가 없습니다. -_-;; (어, 프로그램 실행했는데 왜 안뜨지? 하고...) 쭉 써오신 분이라면 이 쪽이 더 익숙하시겠지요. 그 외의 인터페이스는 거의 같다고 보셔도 됩니다. 

말미에 부록으로 모든 메뉴에 대해서 상세한 설명을 붙여두었습니다. 필요하실 때마다 보고 참고하시면 좋...을 지도 모릅니다.

 

2.2.2 툴바 (toolbar)

메뉴 중에서 특히 자주 사용하는 항목을 아이콘으로 만들어놓은 도구모음입니다. 

 

3660040653_lFHKYJLC_134E75495010A083191D3D

3660040653_HtNiKwMv_1938DA495010A083324AED  Run / 코드를 컴파일(...이 뭔지는 차차 설명해드리겠습니다 ^^;)한 다음 실행합니다. 아마 가장 자주 누르게 되는 버튼이 아닐까요? ^^; Shift 키와 함께 버튼을 누르면 전체화면으로 프로그램이 실행됩니다. (의외로 이거 모르시는 분들이 많더라는...)

3660040653_MRZrl2vs_1738A7495010A083330358  Stop / 실행 중인 프로그램을 중단합니다. 실행중인 프로그램이 창닫기로 중단이 안되는 경우가 종종 있는데 이럴 때 Stop버튼을 누르면 대개의 경우 잘 중단이 됩니다.

3660040653_QLObghVk_203ADC495010A08332C4E7  New / 현재 창에 작성중인 내용을 모두 지우고  새 스케치를 작성합니다. 메뉴의 File-New(Ctrl+N) 항목과는 약간 다른데, 이쪽은 새 스케치 작성을 위해 새 창을 띄워줍니다(Shift 키를 누른채로 New 버튼을 눌러도 같은 효과가 납니다).

3660040653_w89KDgtb_193976495010A083358929  Open / 현재 창에 스케치북, 혹은 예제에 있는 파일을 불러옵니다(예제 파일은 새 창에 열립니다). File-Open(Ctrl+O)과 다른 점은 이쪽은 새 창에 파일을 연다는 점입니다. 역시 스케치북에서 파일을 선택할 때 Shift키를 누르고 선택하면 새 창에 열립니다.

3660040653_b1STfCuj_115FCA495010A084016114  Save / 현재 창에서 작성중인 스케치를 저장합니다. 단축키 Ctrl+S로 대체할 수 있습니다. 디자이너라면 포토샵이나 일러스트레이터 등을 다루면서 수시로 Ctrl+S를 눌러야한다는 사실을 몸으로 익혔을텐데(...) 사실 프로세싱에서도 별로 다르지는 않습니다. -ㅅ-; 프로세싱이 자주 죽는다거나 그런 얘기는 아니지만 만일의 경우를 대비하는 습관이란 중요한 것이지요.

3660040653_zdhIW4AN_113F61495010A0842DE379  ExportApplet / 현재 창에서 작성중인 스케치를 자바 애플릿(웹에서 실행 가능한 형태의 자바 프로그램)이 포함된 HTML 문서로 내보내기 합니다. 윈도나 Mac OS X 등에서 바로 실행 가능한 응용프로그램 형태로 내보내기 할때는 Shift 키를 누른 채로 이 버튼을 누르면 됩니다. 최종적인 전시물을 만들 때 이 기능을 사용하게 되겠지요.

툴바 오른쪽에 있는 'STANDARD' 표시는 현재 '표준 모드'로 프로세싱이 작동되고 있음을 가리킵니다. 클릭하면 Standard와 Android 중 현재의 모드를 선택 가능합니다. 표준 모드는 컴퓨터에서 실행되는 일반적인 프로세싱 프로그램을 만들기 위한 모드이고 안드로이드 모드는 이름 그대로 안드로이드 폰이나 태블릿에서 실행되는 프로그램을 만들기 위한 모드입니다. 나중에 안드로이드 모드에 대해 설명하게 될 일이 있을지는 모르겠습니다만 일단은 표준 모드만을 위주로 강좌를 진행하는 걸로 해두겠습니다.

참고로 2.0 버전부터는 JavaScript 모드가 추가되었고 STANDARD는 JAVA로 표기가 바뀌었습니다만, 크게 내용에 변경은 없습니다. 저는 일단 1.5.1을 사용하므로 '표준 모드'라고 칭하기로 하겠습니다.

 

2.2.3 탭 (tab)

프로세싱으로 프로그램을 만들 때, 작성중인 파일은 .pde 확장자가 붙은 파일에 저장이 되는데, 하나의 프로그램을 파일 하나에 몰아넣고 저장할 수도 있지만 필요에 따라 여러 파일에 나누어 분할 작성하는 것도 가능합니다. 아무래도 프로그램이 막 길어지다보면 그대로 쓰기보다는 적당한 단위로 나눠서 작성해야 나중에 관리하거나 수정하기가 편하겠지요.

새 스케치를 만들면 스케치 이름으로 폴더가 만들어지고, 폴더랑 같은 이름의 pde 파일이 하나 만들어지는 것을 확인할 수 있는데 이것이 기본적인 스케치의 최소 구성입니다. 예를 들면 스케치 이름이 mySketch 라고 한다면 이 스케치는 스케치북 폴더 아래 mySketch란 폴더에 들어가고 기본 파일은 mySketch.pde가 되는 식이지요. 프로세싱은 스케치 이름을 가진 pde파일을 프로그램의 기본파일, 즉 시작부분('진입점'이라는 표현을 많이 씁니다)으로 생각하기 때문에 반드시 이 파일은 스케치 폴더와 같은 이름을 가지고 있어야 합니다(함부로 파일이름 바꾸지 말라는 얘깁니다. 바꾸려면 폴더랑 한세트로 바꿔줘야 됩니다). 

그리고 스케치 폴더 안에 있는 저 메인 파일 외의 pde 파일은 기본 파일에 부속되는 스케치의 일부로 인식이 됩니다. 한 스케치는 결국 폴더 안의 모든 pde파일(+만약 있다면 그림파일이나 동영상 파일 같은 부속파일까지)로 구성이 되는거지요. 그리고 이 모든 pde파일은 스케치를 불러오면 모두 별도의 탭으로 분리되어 표시/관리됩니다.

 

3660040653_UHgOuMDW_13236E4A505271D90FB9BD

▲ 이렇게요. 세개의 pde파일로 구성된 프로세싱 예제입니다.

 

프로그램을 분할 작성하는 것은 문법만 맞으면야 어떻게 분할해도 크게 상관은 없지만 주로 프로그램을 '클래스'라는 단위로 나누어 작성하거나 할 때 많이 사용하는 기능입니다. 대개 클래스를 만드는 이유는 나중에 재사용하기 위해서인데 이걸 파일로 따로 나눠두면 편리하거든요. (그래서 보통은 클래스 하나를 파일 하나에 담는 것이 일반적입니다)

새 탭을 만들고 싶을 때는 탭 공간의 맨 오른쪽에 있는 3660040653_0lEscJ17_1847573950416E10150351 화살표 아이콘을 클릭해서 나오는 메뉴 중 New Tab을 선택하고, 탭 이름(=파일명)을 지어주면 새 탭과 함께 탭 이름을 가진 pde파일이 생성이 됩니다.

클래스를 만들고 하는 게 좀 고급 기술(?)이다보니 탭도 당분간 제 강좌에서는 잘 안쓰는 기능일테니 이런게 있구나 하는 정도로만 알아두세요. ^^; 하지만 필요할 때가 언젠가는 올겁니다. 

 

2.2.4 텍스트 편집기 (text editor)

우리가 프로세싱으로 프로그램 코드를 짜서 입력하는 공간입니다. PDE의 핵심(?)이자 여러분이 적어나가는 노트같은 공간이랄까요. ^^ 이곳에 타이핑한 내용이 바로 여러분의 스케치, 즉 프로그래밍 코드가 되는 것이지요. 여기서 작성한 코드는 .pde 확장자가 붙어서 저장됩니다. 

사실 pde 파일의 내용물은 평범한 텍스트 파일하고 똑같습니다. 텍스트 편집기의 기능도 사실상 메모장 비슷한 것이지만 프로세싱 코드를 짜는데 필요한 기능들이 덧붙어있지요. 예를 들면 코드에 색을 입혀주어 요소들을 시각적으로 잘 구분할 수 있게 해준다던지요. 본문은 검정, 명령어는 주황, 문자열 같은 요소는 파랑, 주석문은 회색 등등으로 알록달록하게 나오는데, 이것만으로도 코드들의 요소가 색상으로 한눈에 구분되니 훨씬 코드를 읽기가 수월해지지요. 비주얼 스튜디오의 인텔리센스 기능처럼 자동완성 기능이 있으면 좋겠지만 PDE의 미덕은 작고 심플한데 있으니 아쉽지만 어쩔수 없죠. ^^; Edit-Auto Format으로 자동 들여쓰기 수정을 해주는 기능도 아주 편리합니다. 나중에 설명해드리겠지만 바른 들여쓰기는 프로그램 실행에는 영향을 끼치지 않더라도 코드 작성에 있어서 아주 중요한 부분입니다.

참고로, PDE의 텍스트 에디터는 한글입력기능이 불완전합니다. 덕분에 주석 같은 것을 적어넣기가 좀 불편한데, Mac OS X에서는 그냥 풀어쓰기(...)로 표시되고 윈도에서는 좀 나아서 그나마 제대로 입력은 됩니다만 매끄럽게 써지지는 않습니다(포토샵 영문판 텍스트 도구로 한글입력하는 느낌을 생각하시면 딱 맞습니다). 2.0 beta 3까지 이 문제가 해결되지 않은 것을 확인했습니다. 그럴 일은 드물겠지만 장문의 한글 입력이 필요한 경우에는 메모장 등에서 작성해서 붙여넣는 것이 편할 겁니다. (특히 Mac OS X에서)

 

2.2.5 메시지 영역 (message area)

주로 프로그램에서 발생한 에러(오류)에 대해 어떤 오류가 발생했는지를 알리는 메시지를 출력해줍니다. 아예 여기에 뭐가 출력되는 상황 자체를 안만나는게 제일 좋지만 그런 게 가능할리가 없고 그것이 불가능한 이상은 에러 메시지랑 친해지는 수밖에 없지요. ^^;

사실 에러를 두려워하기보다는 일단 뭔가 해보고 적극적으로 에러를 고치는 연습을 하는 쪽이 프로그래밍이 빨리 늡니다. 제 경우는 학교에서 프로세싱을 처음 배울때 선생님이 첫째시간인가 둘째시간인가 일단 막 에러를 일부러 종류별로 막 내보고(...) 그걸 정리해보는 수업을 하셨었습니다. =ㅅ=;;;

어쨌거나 에러 얘기는 언제 따로 한번 자세히 하긴 해야할 거 같아요.

 

2.2.6 콘솔 (console)

이 영역은 꽤 다용도스러운 영역입니다. 보통은 에러가 발생했을때 메시지 영역에서 출력되는 짧은 에러 메시지 이상의 상세한 오류정보를 제공해주기도 하고 사용자가 필요할 때 메시지나 데이터 등을 출력시킬 수도 있습니다. 오류를 잡기 위해서 프로그램이 사용하는 값을 추적하거나 할 때도 이 콘솔 영역을 사용합니다. 다용도 계기판(?) 같은 느낌이라고 해야할까요. ^^;

보통 프로그래밍 언어에서 '콘솔', 혹은 '콘솔 창'이라고 하는 것은 오로지 기본 텍스트만을 출력가능한 가장 기본적인 출력화면을 의미합니다. 쉽게 생각해서 윈도의 '도스 창'이나 맥OS X의 '터미널 창' 같은게 콘솔입니다. 

 

3660040653_xSzMbeui_151D1C3E505273CA2E751C

 

시커먼 화면에 작고 하얀, 그리고 참 기계적인 타입페이스로 알수 없는 메시지가 출력되는 이런 거 말이죠. ^^; (아...맥 터미널창은 흰바탕에 검은 글씨군요. ㅎㅎㅎ)

원래 프로세싱의 아

댓글 0

조회수 1,691

등록된 댓글이 없습니다.

구글검색HOME > 구글검색 > 전체 목록

게시물 검색

2022년 1월 2월 3월 4월 5월 6월 7월 8월 9월 10월 11월 12월
2021년 1월 2월 3월 4월 5월 6월 7월 8월 9월 10월 11월 12월
2020년 1월 2월 3월 4월 5월 6월 7월 8월 9월 10월 11월 12월
2019년 1월 2월 3월 4월 5월 6월 7월 8월 9월 10월 11월 12월
2018년 1월 2월 3월 4월 5월 6월 7월 8월 9월 10월 11월 12월
Privacy Policy
MCU BASIC ⓒ 2020
모바일버전으로보기