세상을 프로그래밍하라” 사물 인터넷 시대의 필수 개발 기술 12가지 > 개발자팁 | IOTsw_u2 U2 Project
개발자팁

Aduino 세상을 프로그래밍하라” 사물 인터넷 시대의 필수 개발 기술 12가지

본문

많은 신생업체들이 세상을 바꾸겠다는 포부를 가지고 출발하지만, 이들이 말하는 것은 세상 자체나 세상 속의 물리적인 사물을 의미하진 않는다. 사실상 이들이 말하는 변화의 구체적 모습은 데이터 패킷을 교환하거나 데이터베이스에 엔트리를 배치하는 등인 경우가 대부분이다. 물론 그것들이 중요하지 않은 것은 아니지만, 이는 어디까지나 비트(bit)로 이루어진 세계일 뿐이다. 반면 우리가 사는 세상은 원자로 이루어져 있다.


이런 비트와 원자 간의 경계가 사라지고 있으며, 프로그래머가 더 이상 가상 영역에 제한되지 않게 됐다. 이런 변화에는 한층 더 현실화되고 있는 사물 인터넷이 한몫을 하고 있다. 이제는 디스크에 1과 0의 두 가지 숫자만 쓸 수 있는 단계를 지나 원자를 압출, 절단, 변형하는 구체적 방식에 대한 코드 자체를 입력하는 것이 가능해졌다. 소프트웨어를 통해 불을 켜고, 공간의 모습을 바꾸고, 차를 운전하며, 벽을 옮기는 것이 가능해진 것이다.

덕분에 이제는 개발자들도 가상 세계뿐 아니라 실제 세계에서도 새로운 시장과 기회를 모색할 수 있게 됐다. 무인 자동차, 스마트 홈, 인텔리전트 오피스, 대량 맞춤 생산(Mass Customization) 분야의 급격한 발전은 이제 프로그래머들에게도 데이터 구조의 변화가 어떻게 물질의 변화로 이어지는지에 대한 이해가 요구됨을 의미한다. 이러한 개념은 ‘객체 지향 프로그래밍(object-oriented programming)’ 이라는 단어로 완벽하게 표현할 수 있을 것 같다.

물리적 변화에 초점을 맞춘 이러한 프로그래밍에는 새로운 언어가 필요하다. 아니면, 적어도 기존 언어를 토대로 한 새로운 규약이 있어야 한다. 세상을 바꾼다는 것은 이러한 언어와 프로토콜들의 작동 원리를 이해하고, 이들을 어떻게 배치, 활용할 지를 이해한다는 의미다. 그런 의미에서, 정말로 세상을 바꾸고 싶다면 반드시 알아야 할 몇 가지 언어와 프로토콜들을 소개한다. 일단 세상을 바꾸는 비트에 한 번 맛을 들이면, 다시 데이터베이스로 돌아가기 어려울 지도 모른다.

베이직(Basic)
초기 마이크로컴퓨터의 변혁을 주도한 고전적 프로그래밍 언어인 베이직은 아직도 몇몇 하드웨어 컨트롤러에서 그 흔적을 찾아볼 수 있다. 특히 ESP8266 컨트롤러 보드 제작에 이 언어가 사용되는데, 제작자들의 말에 따르면 베이직 언어는 “컴퓨터 과학을 배우지 않고도 놀라운 일들을 할 수 있게 해주는, 단순하면서도 매우 강력한 언어”이기 때문이다.

베이직은 고전 언어답게 goto를 비롯한 클래식한 구조를 유지하고 있다. 물론 웹 페이지나 이메일 전송을 위한 비교적 새로운 명령도 없는 것은 아니다. 베이직 언어를 사용할 경우 인터페이스 상의 핀을 통해 인터넷으로 전달할 데이터를 모으는 데 대부분 시간을 쓰게 되겠지만 말이다.

베이직 언어에 대한 더 자세한 정보는 ESP8266 커뮤니티나 이 언어 관련 웹사이트를 참조하길 바란다.

X10
처음에 프로그래머들을 가상의 세계에서 나와 실제 세계와 만나게 해 준 언어가 바로 X10이다. 결코 세밀하거나, 복잡한 프로토콜은 아니다. 스티브 잡스와 워즈니악이 애플 I을 출시하기도 전인 1975년에 만들어진 것도 그 이유 중 하나일 것이다. 이렇게 오래된 프로토콜임에도 불구하고, 다양한 저비용 기기들에서 지원이 된다는 이유 때문에 아직까지도 널리 사용되고 있다.

X10 프로토콜은 몇 가지 단순한 메시지들로 구성되어 있다. 비트를 통해 스위치를 켜고, 끄고, 밝기를 조절하는 것이 가능하다. 그게 전부다. 원격 스위치를 조절하거나 데이터를 약간 더 내장할 수는 있지만, 대부분의 기능은 뭔가를 켜고 끄는 데 집중되어 있다. 데이터 패킷은 X10의 파이어크래커(FireCracker) 등 별도의 기기를 통해 생성되며 일반 가정의 120V 전선을 통해 전달된다.

플리핏(Flipit), 보틀 로켓(Bottle Rocket) 등 몇몇 소프트웨어 프로젝트를 통해 파이어크래커에서의 데이터 패킷 생성 프로세스를 단순화할 수 있다. 아니면 파이어크래커를 탄생시킨 장본인이자 1978년부터 가전 제품의 1인자 자리를 지켜왔다고 자부하는 기업인 X10를 거치는 방법도 있다.

인스테온(Insteon)
2005년, 인스테온은 새로운 프로토콜을 발표했다. 더 다양한 메시지 전달과 더 나은 신소 송신을 장점으로 앞세워 X10 프로토콜을 대체하기 위해 만들어진 프로토콜이었다. X10 신호의 경우 집의 크기가 커지거나 배선이 복잡하면 잘 잡히지 않는다는 문제가 있었기 때문이다. 그런가 하면 신호가 노이즈에 영향을 받는다는 불평도 있었다. 반면 인스테온의 프로토콜은 각 노드 및 스위치가 하나의 리피터로 기능하여 신호를 더 멀리, 그리고 배선의 구석 구석까지 닿을 수 있도록 하는 메커니즘을 추가해 이러한 단점들을 보완했다. 신호를 널리 송신할 수 있는 똑똑한 전략을 쓴 것이다.

더욱 풍부하고 복잡성과 중복 수준이 높다는 점도 이 프로토콜의 주요한 특징이다. 인스태온 패킷은 한정적인 2비트의 명령이 아닌, (명령에 전속으로 할당된 2바이트를 포함해) 10바이트까지 확장된 형태로 구성된다. 대역폭을 많이 소모하는 사용자라면, 기기로 전달되는 패킷 내에 추가로 14바이트를 혼합하는 것도 가능하다. 주요 기능 자체는 여전히 대상을 켜고 끄는데 초점이 맞춰져 있지만, 그밖에 득표 센서, 스마트 온도계 제작 등과 관련한 옵션들 역시 이용할 수 있다.

인스테온의 프로토콜은 현재 아마존의 에코(Echo)나 로지텍의 하모니(Harmony) 등 여러 스마트 허브 및 홈 자동화 툴에서 이용되고 있다. 또한 리눅스 홈 자동화(Linux Home Automation) 프로젝트나 오픈리모트(OpenRemote) 같은 오픈소스 툴이 데이터 패킷을 송신하는 전선 컨트롤러와 통합되기도 했다.



지그비(Zigbee)와 Z-웨이브(Z-Wave) 등

X10과 인스테온은 시작일 뿐이다. 기기에 신호를 전달하는 방식은 이 외에도 매우 다양하다. 전선을 통한 방식뿐 아니라 무선으로 전달하는 방식도 있다. 지그비와 Z-웨이브 모두 기기간 저전력, 무선 송신을 가능케 하는 커뮤니케이션 표준으로, 앞으로 기업이나 가정에서 많이 사용될 저전력 내장형 센서 및 프로세서에 매우 적합할 것이다.

예를 들어 최근 지그비는 수퍼마켓에서 온도 센서를 통해 농수산물 코너의 온도를 일정하게 유지해 과일이나 야채가 시드는 것을 방지하는 새로운 시도를 소개한 바 있다. 또한 Z-웨이브는 웹사이트를 통해 무선 버튼을 통해 가정에 ‘품격을 부여하는’ 기기들을 소개하고 있다. 이런 시스템을 통해 노인, 환자가 있는 가정에서도 유사시 손쉽게 지인이나 병원에 연락을 할 수 있다는 것이다. 이처럼 한 번에 몇 비트의 데이터만을 전송하면 되는 애플리케이션들이 수백 가지가 존재한다.

하지만 지그비나 Z-웨이브 외에도 팬스탬프(Panstamp), AMX, KNX, 루트론(Lutron) 등등 다양한 표준이 존재한다. 틈새 시장을 공략하는 것들도 있다. 예를 들어 AMX는 회의실에서 사용하는 시청각 기기를, 팬스탬프는 전세계 어디에서나 널리 이용되는 소형 무선 컨트롤러를 집중 공략하고 있다. 모두 저마다의 포맷을 사용하지만 약간의 부가적 프로그래밍이 가미된다면 상호작용도 가능할 지 모른다. 이처럼 다양하고 풍성한 표준들이 자웅을 겨루는 상황이 약간 혼란스럽게 느껴질 수도 있지만, 표준이 아예 없는 것보다는 훨씬 낫다.

XBMC, 프리박스(Freebox) 등의 프레임워크 
소파에 하릴없이 누워 바보 상자를 뚫어져라 응시하는 사람이 사실은 세상을 바꾸고 있다고 말한다면 무리가 있겠지만, 디지털 이미지, 비디오, 그리고 오디오가 엔터테인먼트에 국한돼 있던 전통적 역할에서 탈피하고 있는 것만큼은 부인할 수 없는 사실이다. XBMC, 프리박스, 그리고 VLC 등 여러 프로토콜 및 프레임워크들은 원래 소파에서 일어나기를 거부하는 ‘카우치 포테이토(couch potato)’들의 코 앞에 영상을 대령하기 위해 제작된 것들이지만 그 외에도 가정이나 건물에서 다양한 쓰임새를 가지고 있다.

이들은 얼핏 보기엔 그저 디지털 콘텐츠 파일을 다루는, 세상의 변화에 큰 영향은 미치지 못하는 프로토콜처럼 보일 지도 모른다. 그러나 사람들의 일상에서 평면 디스플레이가 차지하는 비중이 커지는 만큼, 이 프로토콜 및 프레임워크들이 가져오는 변화와 영향력을 인정하지 않을 수 없다. 스크린 상의 이미지를 통해 쉴새없이 변화하는 타임 스퀘어의 건물들이 그 대표적인 사례다. 스크린이 늘어난다는 건 결국 디지털 콘텐츠의 활동 무대가 스마트폰에 국한되지 않고 더 넓어 진다는 의미다. 이제는 스크린이 건물의 외양을 결정하고, 공간 인테리어를 새롭게 탈바꿈하게 된 것이다.

포스트스크립트(PostScript)
데이터를 PDF 파일 형식으로 저장하거나 특정 페이지의 텍스트를 프린터로 전송하는 과정은 겉보기와는 달리 여러 복잡한 처리 과정을 필료로 한다. 포스트스크립트 파일이 포함하는 데이터는 그저 단순한 글자의 목록이 아니다. 이는 페이지 안에서 펜을 움직이고, 글자와 선, 숫자, 도형을 그릴 수 있도록 해주는 엄연한 프로그램이다. 포스트스크립트 언어의 기본 용도는 직선이나 베지에(Bézier) 곡선을 따라 펜을 움직이고, 그로써 생성된 도형들을 채워나가는데 있다. 포스트스크립트에서는 폰트 역시 그저 단순한 비트맵이 아닌, 서브픽셀 수준 정확도의 확장과 위치 조정을 지원하는 곡선의 집합으로 구성된다.

포스트스크립트가 개발된 것은 70년대로, 괄호 내에 저장이 이뤄지는 스택 기반 구문을 갖춘 형태로 선을 보였다. HP 계산기 사용법을 익혀본 이들이라면 포스트스크립트 역시 낯설지 않게 이용할 수 있을 것이다. 오랜 기간 동안 포스트스크립트는 그 완성도를 높여왔으며, 복잡한 프랙털(fractal)을 비롯한 여타 특수한 대상들, 그리고, 바이러스를 작성하는데 이용되어 왔다.

XML 변종들이 웹 상에서 널리 지원되고 있다는 특성으로 인해, 오늘날 포스트스크립트는 SVG 파일의 말미에 주로 이용되고 있다. 그러나 그 구조의 기저에는 많은 유사성이 있으며, 전환 과정 역시 충분히 직관적이다. PS투에딧(PSToEdit)과 같은 여러 패키지를 통해, 두 언어 모두는 레이저 컷팅기나 밀링 머신 등을 구동하는 코드로 전환할 수 있다.

OBD-II
가스 탱크와 피스톤 몇 개, 그리고 폭발력을 바퀴의 움직임으로 바꿔주는 크랭크축 몇 개로 자동차를 정의하던 시절은 끝났다. 오늘날의 자동차들은 전통적인 네 개의 바퀴 위에, 다수의 컴퓨터와 그것들을 연결하는 복잡한 네트워크를 갖춘 정교한 전자기기로 발전하고 있다. OBD-II 표준은 오직 인간만이 그런 스마트카와 소통하고 그것의 현재 상황을 확인할 수 있도록 하는 수단이다.

컴퓨터와 차량 사이를 오가는 코드 대다수는 순수한 정보 객체이다. 예를 들자면, 사용자가 포트로 전송한 몇 바이트의 명령이 차량 아랫부분의 스티어링 휠을 움직여 원하는 속력을 구현하는 것이다. 운행 속도뿐 아니라 RPM이나 엔진 효율, 그 밖의 다양한 기능들 역시 같은 방식으로 통제할 수 있다. OBD-II는 토크를 비롯한 많은 기본 앱으로 자동차의 상태를 추적하는 데에도 활용될 수 있다.

이런 앱은 현재는 아마추어 레이서들이나 얼리 어댑터를 중심으로 인기를 얻어가고 있으나, 향후 그 활용 범위는 더욱 확대될 것으로 기대되고 있다. 자동차를 컴퓨터와 연결할 수 있는 좋은 옵션 중 하나로는 아두이노OBD(ArduinoOBD)를 추천한다.

G
밀링 머신에 컴퓨터 수치 제어(Computer Numerical Control), 이른바 CNC 기술이 도입된 것은 1950년대의 일이다. 그리고 얼마지 않아 엔지니어들은 G라는 언어를 개발한다. G 언어는 절단용 도구들의 움직임을 제어하는 활동에 특화된 언어이다. 초반 G는 고체를 쌓아가는 방식이 아닌 원재료를 깎아 결과물을 제작한다는 점에서 반직관적이라는 지적을 받기도 했다. 하지만 최종 결과물을 구상하는 방식을 반대로 뒤집어본다면, 어떤 날카로운 회전체를 이용해 사용자가 원하는 것을 깎아낼 방법을 상상하는 것도 결코 어렵지는 않은 일이다.

코딩의 대다수는 좌표계를 선택하고 절단 공구를 특정 위치로 조정하는 활동에 적용된다. 직선이나 원 등 간단한 도형에서 중앙점을 계산해 표시하는 작업은 상대적으로 어렵지 않게 가능하지만, 그 밖의 복잡한 도형들의 경우에는 약간의 계획이 요구된다.

오랜 기간에 걸쳐 각각의 제조업체들이 나름의 개선을 진행하며 G는 처음의 모습에서 많은 부분이 변화한 상태다. 오늘날에는 로우 G 코드에 보다 현대적인 매크로, 객체 지향 계층을 추가해 기기로 전송하는 방식으로 활용되는 경우가 많다.

현재 G와 그 변형들이 두각을 나타내는 대표적인 분야로는 3D 프린터 산업을 꼽을 수 있다. 엄밀히 따지면 코드 자체는 정확히 동일한 것은 아니지만, 언어의 본질 자체는 G의 그것과 같다고 할 수 있다.




STL

3D 객체를 설명하는 표준 포맷은 비유하자면 3D 프린팅 산업의 공통언어라 할 수 있다. 온라인 상점들은 STL 파일을 전송하는 방식으로 가상의 사물을 판매할 수 있다. 전송된 STL 파일은 3D 프린터를 통해 실물로 구현되며, 구매자가 나름의 편집을 거치는 것도 가능하다.

언어 자체는 꽤 기초적인 편이다. 파일은 삼각형의 모서리들을 통해 도형의 표면의 외부를 덮는 면을 형성하는 3차원 좌표 형태가 대부분으로, 포맷만 보면 더 복잡한 다각형들을 지원하는 것처럼 보이긴 하지만, 파일이 전통적으로 다루는 형태는 삼각형이다. 삼각형이 입체를 완전히 덮거나 표면의 모든 부분을 정의하는 것이 파일 포맷의 필수 사항은 아니지만, 3차원의 대상을 구성하기 위해선 위의 두 조건 요구된다.

STL 파일들은 점(point) 혹은 2진 버전의 ASCCI 표현을 포함하는 것이 가능하지만, 경제성의 이유로 2진 버전을 교환하는 경우가 대부분이다.

슬라이서(Slicer)
STL 파일은 3D 프린터를 구동할 충분한 정보를 포함하는 형식은 아니다. 다시 말해 STL의 삼각형들이 구현하는 형태를 실제 프린터의 헤드를 움직이고 압출기를 켜고 끄는 일련의 지침 목록으로 전환하는 무언가가 필요한 것이다. 3D 프린터는 일반적으로 G코드(GCode), 이른바 슬라이서(Slicer)를 이용한다. 이는 CNC 밀링 머신에 쓰이는 G코드와 유사하다.. 둘 사이의 가장 큰 차이점이라면 CNC 머신이 블록을 깎아 부품을 만드는 절삭식인 반면, 슬라이서는 부품을 아무것도 없는 처음 단계부터 만들어가는 적층식이라는 점이다. 그밖에 프린터 헤드를 조정하는 명령의 대부분은 유사하며, 다만 후자에는 압출기를 동작하는 기능이 추가적으로 존재한다는 점은 차이라 볼 수 있다.

시장에는 상용뿐 아니라 오픈소스 형태로도 여러 슬라이서 프로그램들이 선을 보이고 있다. 어떤 툴들은 정교한 IDE를 이용해 출력 전 편집을 지원하기도 한다. 대표적인 예로, 키슬라이더(KISSlider)는 무료 버전의 경우 싱글헤드 프린터에서만 동작이 가능하지만, 프로 버전을 구매하면 보다 정교한 멀티 헤드 기기들까지 매끄럽게 지원하고 있다.

파이썬(Python)
파이썬은 생물학 실험실이나 사회 과학 분야 등에서 가장 사랑 받는 언어이며, 라즈베리 파이 커뮤니티에서는 ‘공식 언어’로까지 불리고 있다. 물론 이 별명에는 과장된 측면도 분명 존재한다. 라즈베리 파이 보드들은 보통 리눅스로 곧바로 부팅되는 경우가 많으며, ARM(v6 혹은 7) 아키텍처로 바로 편집된 경우라면 대부분의 리눅스 코드 기반을 통해 보드를 구동하는 것이 가능하기 때문이다.

그럼에도 파이썬은 여전히 충분히 매력적인 언어다. 이는 깔끔한 구문을 갖춘 고급의 언어이며, 데이터를 돌려보는 것과 관련한 규정 역시 상당히 관대한 편이다. 프로그래머로써는 클로저(closure)와 같은 추상화에 지나치게 얽매이지 않아도 되며, 포인터와 관련한 복잡한 규정을 외울 필요도 없다는 점이 큰 장점으로 다가온다. 단순히 수를 처리하는 지침을 작성하고 그 값을 이용해 간단히 라즈베리 파이에 동작을 명령할 수 있다.

이러한 이유로 라즈베리 파이 커뮤니티는 파이썬을 기초부터 교육하는, 포괄적인 자료도 제공하고 있다.

프로세싱(Processing)
실물, 로봇 공학 산업은 아두이노(Arduino) 보드로 채워진 세상이다. 아두이노는 C, C++의 서브셋 언어에 기반을 두고 있다. 그러나 많은 프로그래머는 그보다 간결한 무언가를 원한다. 이것이 프로세싱(Processing)이라는 언어가 지지를 얻고 있는 이유다.

프로세싱은 자바의 간소화 버전으로 볼 수 있는 코드로, 자바의 많은 훌륭한 디테일들을 포기한 대신, 결과를 도출해내고 스위치를 동작하는데 도움을 주는 각종 표준 방법론들을 추가했다. 자바를 다뤄온 프로그래머들이라면 기존의 낡은 AWT 애플릿과 프레임의 기반 위에서 어떻게 프로세싱이 개발되었는지 자체에 놀라움을 금치 못할 것이다. 물론 이외의 많은 사용자들에겐 그저 루프를 작성하고 코드를 바꾸는 과정이 가장 큰 관심사일 것이다.

프로세싱 코드는 일반적으로 아두이노에 지시를 전달하는 컴퓨터인, 호스트 컴퓨터(이 과정을 위해선 퍼마타(Firmata)라는 로컬 해석 툴이 필요하다) 상에서 구동된다. 호스트 기기에서 개발이 진행되고, 실제 동작은 아두이노에서 구현되는 방식이다.

프로세싱은 모바일 앱 개발에도 이용되고 있으며, 웹 앱 분야의 근간을 이루는 역할을 하기도 했다. 자바스크립트로 작성된 프로세싱 버전을 통해 거둔 성과다. 칸 아카데미(Khan Academy)에서는 컴퓨터 프로그래밍 교육 도구로 이를 이용하고 있기도 하다.  editor@itworld.co.kr

 

댓글목록

개발자팁 목록

Total 3건 1 페이지
게시물 검색

IOTsw_u2 정보

회사 . U2
주소 . 어느별 하늘 아래에 있것지요
사업자 등록번호 . 백수임 대표 . 김씨 전화 . 02-123-4567 팩스 . 팩스없음
통신판매업신고번호 . 낼할께 개인정보관리책임자 . 김씨가 알아서 함 부가통신사업신고번호 신고안함
Copyright © 2001-2013 U2. All Rights Reserved.
닫기