스마트폰이 등장한 이후로 한때 M2M이나 유비쿼터스(Ubiquitous)로 불리던 것들이 IoT(사물인터넷)란 이름으로 재조명 받고 있습니다. 정부나 기업들도 앞다퉈 IoT란 이름을 붙여서 새로운 사업이나 제품을 출시하고 있는 상황이죠. 

현재 가장 주목받고 있는 기술 중 하나가 블루투스 비콘(Bluetooth Beacon)일 겁니다. 이미 상품화 된 것도 많죠.  실질적으로 사용자들이 쉽게 체감 할 수 있고 별도로 장치를 구입하지 않아도 기존의 스마트폰에서 쉽게 사용이 가능 하기 때문일 겁니다. 

서론은 이쯤에서 접고.. 비콘기술에 사용되는 BLE(Bluetooth Low Energy)에 대해 알아봅시다. 

BLE란?

2010년 6월에 발표한 블루투스 버전 4.0에 Low Energy기술이 탑재되었습니다. Bluetooth Smart라고도 불리며 일반적으로 Bluetooth Low Energy를 줄여 BLE로 불립니다. 

요즘 출시되는 대부분의 스마트폰에 적용되어 있으며 Andorid는 4.3 이후 버전 부터, 아이폰은 iOS5(iPhone 4S) 이후 버전에서 사용 가능합니다. 

• 기존 버전 대비 다른 점은 아래와 같습니다. 

1. 저 가격 생산

2. 저 전력 동작

3. 디바이스 연결 절차를 간소화

4.  패킷 사이즈 감소

5. 채널 수 감소

6. 음성지원 안됨

7. 스타-버스 토폴로지 지원

한마디로 힘이 덜드는 일을 오랫동안 지속 가능하도록 했다는 겁니다.  

• 전원 사용의 효율성을 높히기 위해 다음과 같은 특징을 가집니다.

1. 동작 사이클을 줄여서 더 오랜시간 슬립(Sleep)하고 덜 자주 깨어납니다. 

2. GATT profile을 사용해서 더 작은 데이터 패킷을 더 짧은 시간동안 전송합니다. 

3. 통신을 하지 않는 동안 링크를 유지하지 않습니다. 다음 번 통신 시점에 빠르게 다시 연결을 맺습니다. 

이런 특징들 덕분에 기존 버전의 블루투스에서 주로 사용되던 헤드셋, 키보드와 같은 장치 보다는 헬스케어와 같은 애플리케이션에서 사용하기 적합합니다. 

그리고 비콘 처럼 별도의 전력을 연결하지 않고 작은 배터리로 동작하는 장치에 적용하려면 저전력에서 동작해야 하는데 그걸 BLE가 충족시킬 수 있어서 블루투스 비콘이 이처럼 빠르게 확산되고 있는 거라고 생각됩니다. 

프로토콜 구조

BLE의 프로토콜 스택은 크게 컨트롤러, 호스트 그리고 어플리케이션 영역으로 구분 할 수 있고, 컨트롤러와 호스트 영역 간의 통신을 위해 HCI가 사용됩니다. 

Bluetooth Protocol Stack

이 그림은 기존 블루투스와 BLE의 프로토콜 스택을 그림으로 표현한 것입니다. 

두가지 버전을 모두 지원하는 것을 듀얼 모드(Dual-mode)라고 하며 Bluetooth Smart Ready라고도 불립니다. 

• 각 스택별 역할 

1. LM(Link Manager): 두 장치간의 무선 링크를 설정하고 컨트롤 하는데 사용됩니다. 

2. HCI(Hardware Controller Interface): 컨트롤러와 호스트간 통신을 위해 사용됩니다. (bluez패키지에 포함되어 있는 hciconfig, hcitool 명령어를 사용하면 됩니다.)

3. L2CAP(Logical Link Control and Adaptation layer Protocol): 상위 레벨로 데이터 서비스를 제공하고, 컨트롤러로 보낼 패킷을 쪼개주거나 받은 패킷을 재조합 하는 역할을 합니다. 

4. SDP (Service Discovery Protocol): 자신이나 다른 장치에서 제공하는 서비스를 탐색하는데 사용됩니다. (bluez 패키지에 포함되어 있는 sdptool 명령어를 사용하면 됩니다. )

5. RFCOMM (Radio Frequency Communications): 가상 시리얼 데이터 스트림을 생성해서 케이블을 대신 할 수 있도록 해주는 프로토콜입니다. 다시 말해 시리얼 포트 에뮬레이션을 제공합니다. ( bluez패키지에 포함되어 있는 rfcomm 명령어를 사용하면 됩니다.)

6. GAP (Generic Access Profile): 장치간 페어링과 링크를 위해 사용됩니다. 어플리케이션 레이어에서 다른 블루투스 모드를 구현하기 위한 인터페이스로 사용됩니다.

7. SM (Security Manager): 암호화화 사용자 인증을 위해 사용됩니다. AES-128bit 암호화 엔진을 사용합니다.

8. GATT(Generic Attribute Profile): ATT(Attribute Protocol)을 이용하여 서비스 검색, 특성 값 파악, 읽기, 쓰기 등의 기능을 수행합니다. 

디바이스간 통신

BLE는 2.4GHz ISM, 40개의 채널을 사용합니다. 3개의 채널(38~40번째)을 사용해서 광고(advertise)를 하고, 남은 37개의 채널을 통해 데이터를 주고 받습니다.

• 역할 

BLE에서는 주변장치(Peripheral device) 와 중앙 장치(central device)로 역할을 나눌 수 있습니다. 보통 central은 scan을 하는 스마트폰이 되고, Peripheral 은 비콘과 같은 센서 장치가 됩니다. 

peripheral은 동시에 하나의 central 장치와만 연결을 맺을 수 있습니다. 물론, 하나의 central은 여러 개의 peripheral과 연결을 맺을 수 있습니다. 두 장치 간의 연결이 이루어진 이후에는 peripheral의 advertising이 중단되서 다른 장치에서 peripheral의 advertising을 스캔할 수 없게 됩니다. 

•  페어링(pairing)과 본딩(bonding)

페어링 절차는 본딩을 생성하기 위해 시작되거나, 서비스에 접속할 때 장치의 ID가 필요한 경우 시작됩니다. 페어링 과정에서 링크 키(link key or shared secret)를 생성하게 되고, 링크 키 생성 후에는 두 장치간 통신은 암호화 됩니다. 

페어링 매커니즘은 v2.1이전과 이후로 나뉘는데 2.0까지는 두 장치가 모두 동일한 PIN코드를 입력해야 페어링이 이루어 졌습니다. v2.1부터는 SSP(Secure Simple Pairing) 매커니즘이 적용 되었는데, 이는 공개키 암호화 형식을 사용해서 MITM공격으로 부터 보호할 수 있는 기능도 제공합니다.

페어링을 성공하고 난 후 두 장치간 본딩을 하도록 하면 다음 번 두 장치간 연결시에는 페어링를 필요로 하지 않게 됩니다.

개발 툴 설치 

BLE 동글(dongle)을 구입해서 다양한 설정을 직접 해보고 싶다면  bluez패키지를 설치 하시면 됩니다. 

해당 패키지 안에는 아래와 같은 유용한 툴들이 포함되어 있습니다. 

1. hciconfig : 블루투스 장치의 기본적인 설정이 가능합니다. scan을 켜고 끄거나, advertising을 시작/중지 시킬 수 있습니다.

2. hcitool: 블루투스 장치를 사용 하는데 필요한 기본적인 명령이 가능합니다. scan을 시작하거나 연결을 맺거나 끊을 수 있습니다.

3. sdptool: 서비스와 관련된 명령이 가능합니다. 자신이나 통신이 가능한 다른 장치의 서비스 정보를 조회하거나 새로운 서비스를 추가/삭제 하는것도 가능합니다.

4. rfcomm: rfcomm 관련 설정 및 조회가 가능합니다.

5. bluez-* : 블루투스 장치와 관련된 다양한 설정 및 정보 조회가 가능합니다.

예) bluez-test-discovery: 스캔 가능한 블루투스 장치들의 정보를 보여준다. Pairing, bonding 여부를 확인 할 수 있습니다.

기본적인 TPM(Trusted Platform Module) 프로그래밍에 대해 알아봅시다. 

 준비 단계 

먼저 필요한 라이브러리들을 설치해야 합니다. 

• Fedora계열 

• debian 계열 

설치를 완료하고 난 후에는 TPM의 takeownership 명령을 수행해서 사용 권한을 획득해야 합니다. 자세한건 이전에 쓴 글을 참고하시면 됩니다. 

 알고 넘어가기  

• TSS 아키텍처는 아래 그림과 같습니다. 

Architectural overview of the TSS

TPM 프로그래밍에서는 Tspi라이브러리 들을 사용합니다.

• 다음 라이브러리들은 미리 추가해 두고 시작하는게 편합니다. 

• 디버깅 함수를 미리 정의해 두고 사용하면 편합니다. 

tResult값은 Tspi명령을 수행한 후 리턴 받은 값을 넣어주면 됩니다. 

• 프로그램 초반부에 항상 필요한 값들은 미리 알아두면 편합니다. 

1. TSS_HCONTEXT 

2. TSS_HTPM

3. TSS_HKEY

이 외의 TSS 변수들은  'include/tss/tss_typedef.h' 파일을 참고하면 됩니다. 

• 모든 작업을 완료한 후에는 불필요한 자원을 해제해주면 됩니다. 

필요한 기능 구현하기 

1. 키 생성 - 서명키(signing key)

2. 키 저장 및 로드 

3. 공개키 생성 후 파일로 저장

4. 데이터 해시 (Hashing data)

5. 데이터 실링 (Sealing data)

6. 서명 및 검증 (signing and verify)

7. 랜덤 넘버 생성 

즐거운 TPM 프로그래밍 하세요~

TPM은 TCG(Trusted Computing Group)에서 만든 것으로 중요한 자료를 안전하게 보호하기 위해 사용됩니다. TPM에 대한 내용은 다음에 차차 다루기로 하고 이번에는 TPM을 사용하는 법에 대해 얘기해보고자 합니다. 

여기서는 debian 환경을 기준으로 정리해보겠습니다.  먼저 TPM을 사용하기 위해서는 관련 패키지들을 설치해 줘야 합니다. 

libtspi-dev, trousers, tpm-tools 을 설치해 줍시다. 

tpm-tools 패키지 안에는 커맨드로 TPM 정보를 읽거나 설정 하는게 가능한 실행 파일들이 존재합니다. 

1.3.7 버전 기준으로 다음과 같습니다. 

tpm_nvread, tpm_changeownerauth, tpm_setoperatorauth, tpm_selftest, tpm_getpubek

tpm_clear, tpm_setpresence, tpm_resetdalock, tpm_restrictpubek, tpm_setclearable

tpm_revokeek, tpm_createek, tpm_nvinfo, tpm_nvrelease, tpm_version, tpm_setownable

tpm_nvwrite, tpm_nvdefine, tpm_setenable, tpm_setactive, tpm_takeownership, tpm_restrictsrk

이제 TPM을 사용하기 위한 초기화 과정을 알아봅시다. 

(명령별로 지정해준 옵션은 해당 명령에 '-h' 옵션을 주면 설명을 볼 수 있습니다. )

먼저, TPM이 정상적으로 인식되는지 확인 해 봅시다. 

버전 정보가 제대로 출력되지 않는 다면 TPM이 정상적으로 설치 되지 않았다는 의미입니다. 

TPM을 사용하기 위해서는 궁극적으로는 tpm_takeownership 명령을 수행해 줘야 합니다. 

하지만, 처음 이 명령을 실행하면  다음과 같은 오류가 연쇄적으로 발생하게 됩니다. 

Tspi_TPM_TakeOwnership failed: 0x00000006 - layer=tpm, code=0006 (6), TPM is deactivated

activate되어 있지 않는 다는군요. 

Tspi_TPM_SetStatus failed: 0x00000007 - layer=tpm, code=0007 (7), TPM is disabled

enable되어 있지 않다고 합니다. 

Tspi_TPM_SetStatus failed: 0x0000002d - layer=tpm, code=002d (45), Bad physical presence value

persence를 해줘야 할것 같군요. 

Tspi_TPM_SetStatus failed: 0x0000002d - layer=tpm, code=002d (45), No SRK 

SRK(Storeage Root Key)가 없다고 합니다. SRK는 takeownership을 해줘야 생성됩니다. 결국, 문제는 다시 원점으로 오게 됩니다. 

이를 해결하기 위한 절차는 다음과 같습니다. 

먼저 run level을 single user mode로 변경해 줘야 합니다. 

그렇지 않고 tpm_setenable 명령어를 수행해 보면 

Tspi_TPM_SetStatus failed: 0x0000002d - layer=tpm, code=002d (45), Bad physical presence value 처럼 오류가 발생합니다.

자.. run level을 변경한 후..  다시 해보면 .. 

Tspi_Context_Connect failed: 0x00003011 - layer=tsp, code=0011 (17), Communication failure와 같은 오류가 발생하게 됩니다.

trousers 서비스를 시작 시켜줘야 합니다.

toursers를 실행 해 주고.. 다시 enable을 시켜 줍시다. 

만약, 이 때 Tspi_TPM_SetStatus failed: 0x0000002d - layer=tpm, code=002d (45), Bad physical presence value 와 같은 오류가 여전히 발생 한다면..  setpresence 명령어를 실행해 줘야 합니다. 

별 에러 없이 수행이 완료되면 성공! 다시 한 번 enable해주고..

enable이 성공했다면 활성화를 시켜 줍니다. 

정상적으로 active 가 되었다면 .. 'Action requires a reboot to take effect' 이런 메시지가 나옵니다.  리부팅을 시켜줍니다. 

이제 takeownership을 해봅시다. 

Tspi_TPM_TakeOwnership failed: 0x00000023 - layer=tpm, code=0023 (35), No EK 와 같은 오류가 발생한다면.. EK(Endorsement Key)가 없다고 하니 EK를 먼저 생성해 줍시다. 

Tspi_TPM_TakeOwnership failed: 0x00002004 - layer=tcs, code=0004 (4), Internal software error 와 같은 에러 메시지가 발생한다면..

다시 한번 reboot을 해줍시다. 

오류가 발생하지 않았다면 드디어 ownership을 획득에 성공한 것입니다. 

사용하다가 설정을 다시 초기화 하고 싶다면 clear 명령을 실행하면 됩니다. 

이상으로 TPM을 사용하기 위한 절차를 알아봤습니다. 

TPM(Trusted Platform Module)은 TCG(Trusted Computing Group)-신뢰할 수 있는 컴퓨팅 그룹에서 만든 것으로 우리말로는 신뢰(할 수 있는) 플랫폼 모듈 정도로 해석 할 수 있습니다.  암호 키를 매우 안전하게 보관할 수 있는 금고 정도로 생각하면 됩니다. 

왜 TPM과 같은 것이 필요할까요?

개인 PC나 노트북에 다른 사람에게 공개되면 안되는 중요한 자료가 있다고 생각해봅시다. 해커가 이 자료를 훔쳐가지 못하게 하려면 어떻게 해야 할까요? 

아마도 가장 먼저 떠오르는 것은 백신일 겁니다. 이 외에도 애드웨어, 개인 방화벽 등이 해커들의 간단한 공격을 막아 줄 수는 있지만 완벽하게 공격을 차단할 수 있는 소프트웨어란 현실적으로 불가능합니다. 버그가 없는 소프트웨어를 만든다는게 거의 불가능에 가깝기 때문이기도 하지만, 금전적인 이익을 얻기 위한 해커들의 공격 수법이 날로 진화하고 있기 때문이기도 합니다. 

백신등으로 해커의 침입을 완벽하게 막았다 치더라도, 노트북을 분실하거나 A/S를 맡겼을 때 다른 사람이 데이터를 빼간다거나 하는 경우에는 속수무책일 수 밖에 없습니다. 데이터를 복사해가고 원본을 그대로 놔둔다면 자료가 유출됐는지 조차 알아채지 못할 겁니다. 

결국 이런 문제들을 해결하기 위해 중요한 자료를 암호화해서 보관하는게 좋겠다는 결론에 이르렀습니다. 

그래서 인터넷에서 데이터를 암호화 하는 프로그램을 다운로드 받아 중요한 데이터를 암호화 했다면 이제 안전 할까요? 

이전에 비해 상당히 안전해 진 것은 맞습니다. 하지만, 안타깝게도 암호키가 유출된다면 우리의 노력은 수포로 돌아가게 됩니다. 

그림에서 보는것 처럼 컴퓨터만 잠궈두게 되면 하드디스크만 띄어서 다른 컴퓨터에 연결하게 되면 그 안의 자료는 모두 볼 수 있게 됩니다. 

그래서 TCG에서는 이를 보완하기 위해 하드웨어적으로 암호화하는 방법을 고안해 냈고 그게 바로 TPM입니다. TPM을 사용하면 해당 TPM에서만 암호화된 자료를 복호화 할 수 있도록 하여 디스크만 추출해서 내부 자료를 탈취하려는 시도도 막아줍니다. 

TPM의 주요 기능에는 RTM(Root of Trust for Measurement), RTS(Root of Trust for Storage), RTR(Root of Trust for Report)가 있습니다. 

1) RTS(Root of Trust for Storage)

 RSA 암호화 알고리즘을 사용해 암호화 및 복호화를 수행합니다. 

 외부 스토리지에 암호화된 데이터를 저장하기 위해 내부에 보유하고 있는 SRK를 이용해 키를 생성 및 관리하고, 트리 형식으로 스토리지의 데이터를 암호화 하여 관리합니다. 컴퓨터에 저장된 자료를 모두 TPM을 사용해서 암호화 해두었다면 설령 컴퓨터를 도둑 맞더라도 자료가 유출되는 걱정은 하지 않아도 됩니다. 

2) RTM(Root of Trust for Measurement)

 디바이스가 부팅될 때 외부 사용자로부터 불법적인 변경 및 조작이 있었는지에 대한 상태를 점검하고 이전에 저장되어 있는 상태와 비교하여 변화된 동작이 없음을 확인함으로써 디바이스가 무결하다는 것을 증명하는 과정을 말합니다. 

한마디로 누군가 장치에 접근해서 펌웨어와 같은 것을 변조해서 TPM에 있는 키를 빼내려 하는 시도를 막아주기 위한 기능입니다. 

3) RTR(Root of Trust for Report)

 외부의 사용자에 의해서 디바이스에 대한 무결성 인증 요청을 받았을 경우 RTM과정을 통해서 무결성을 인증했던 데이터의 정보를 제공해 주는 역할을 수행합니다. 사실 이것이 보장되지 않는다면 RTM이 보장된다 하더라도 해커에 의해 공격을 받을 수 있기 때문에 반드시 필요한 기능입니다. 

이런 기능들을 제공하기 위한 TPM의 구조는 아래 그림과 같습니다. 

우리는 이제 TPM의 이런 기능 덕분에 노트북과 같은 장치를 도둑맞을 수 있어도 그 내부에 저장된 자료는 도둑맞지 않을 수 있는게 가능합니다. 물론, 노트북을 되찾기는 어렵겠지만요.. 

연말 연초가 되면 가족이나 연인끼리 즐거운 분위기를 즐기기 위해 맛있는 음식을 찾게 되죠. 

연휴 동안 스테이크와 회를 먹고나서 뭔가 새로운걸 생각하다가 간만에 랍스타를 먹기로 결정 했어요. 

사실 가격이 비싸서 자주 먹기는 힘들지만 그래도 가끔 먹으면 돈이 아깝지 않더라구요. 

메뉴를 결정 했으니 싱싱하고 저렴하게 구입할 수 있는 집 근처의 가락시장으로 고고~ 

가락시장에 가면 마트와 달리 호객행위도 있고 물도 튀고해서 싫어 하시는 분들도 계실텐데요.. 

저는 자주 가는 집이 있어서 호객행위로 부터 자유로울 수 있었답니다. 

마트와는 달리 작은 크기의 랍스타는 안보이네요. 

저는 어차피 큰 녀석을 살꺼라 별 상관 없었지만요. 

여기 있는 녀석들은 다 살이 많은 숫놈들이랍니다. 

연말이라 시세가 좀 더 오르지 않았을까 걱정했는데 예년과 비슷하더군요. 

제가 샀을 당시 시세는 1Kg당 4만5천원이였습니다. (2014년 12월 28일 기준)

두 마리에 17만원 이니까.. 2Kg정도 되는 녀석 두마리를 구입했네요. 

(가격이나 서비스를 흥정 할 수도 있으니 참고하세요. )

보통 굴이나 새우를 같이 쪄주는데 저는 최근에 회를 먹어서 그냥 랍스타만 쪄서 받아왔어요. 

크기가 워낙 커서 집에서는 찔 엄두가 나지 않아요. 

서둘러 집에 와서 개봉 박두~~ 

집게 발은 집에서 어찌 해보려 하면 감당이 안돼서 망치로 살짝 깨왔습니다. 찜기에 넣기전에 집게발을 망치로 때린다고 당황하지 마세요. 

엄청난 포스를 자랑하는 랍스타 되시겠습니다. 

아이뻐5S랑 비교해보면 대략적인 크기가 직감이 되실겁니다. 집게발 하나가 폰만 하네요. 

꼬리는 살짝 구부러져 있어서 그렇지 사진보다 조금 더 길답니다. 

뒤집어서 살 바를 준비를 해줍니다. 

제가 하는 살 바르는 순서와 방법 입니다. 

이렇게 크고 단단한 랍스타도 가위 하나면 충분합니다. 

① 먼저 꼬리와 몸통 부분을 분리해 줍니다. 가위로 선을 따라 살짝 잘라 주시면 더 쉽습니다. 

② 분리한 꼬리의 중앙선을 따라 가위로 잘라줍니다. 그런 다음 손으로 잡고 양쪽으로 벌려주면 쉽게 살만 분리가 가능합니다. 

③ 집게 다리와 몸통이 연결된 부분을 손으로 살짝 돌려주면서 떼어냅니다. 

④ 다리 부분과 집게 부분의 연결 부위 역시 손으로 살짝 돌려주면 분리됩니다. 집게발은 망치로 살짝 깨놨기 때문에 부서진 부분의 껍질을 제거하면 살만 쏙~ 뽑아낼 수 있습니다. 

⑤ 몸통의 등 껍질을 분리한 후 들어있는 소금물을 충분히 빼준 다음 숟가락으로 내장을 긁어서 별도의 그릇이나 밥을 볶을 팬에 담아두고, 몸통 살은 가위로 절반으로 잘라 게살 발라 먹듯 손으로 발라 먹으면 됩니다. 

꼬리와 몸통 분리하기. 

꼬리 껍질에 가위질을 한 후 손으로 벌려주면 끝. 

살 한점 남기지 않고 먹음직 스럽게 꼬리살을 접시에 담았어요. 

조금 난이도가 있는 집게발 차례. 

집게발을 몸통에서 분리 한 후 다리와 집게도 비틀어 분리 해주세요. 

망치로 깨진 부분의 껍질을 손으로 잡아 제거한 후 벙어리 장갑의 엄지손가락 처럼 생긴 걸 잡아 당겨서 제거해 줍니다. 

그러면 한쪽 부분 껍질이 모두 제거 되서 집게살을 깔끔하게 빼낼 수 있답니다. 

오동통한 집게발 살도 접시에 예쁘게 올려봤어요. 

등껍질을 살짝 제거하고 나면 맑은 물이 나오는데 이건 짜기만 한 소금 물이므로 반드시 버려주셔야 합니다. 

볶음밥에 그냥 다 넣었다가는 짜기만 한 밥이 되버려요. 

물을 빼고 나서 숟가락으로 내장을 긁어서 밥을 볶기 좋은 후라이팬에 담아 줬습니다. 생긴건 저래도 참 맛있답니다. 

나머지 몸통살은 가위로 절반으로 잘라서 손으로 살만 발라 먹으면 됩니다. 

작은 다리도 천천히 가위로 발라 먹으면 은근 재밌고 맛있어요. 

그러는 사이 등장한 볶음밥~ 

간단한 야채를 넣어 자극적이지 않고 고소한 볶음밥. 

역시 한국 사람은 밥이 들어가줘야... ㅎㅎㅎ

항상 기억해 주시고 좋은 물건을 저렴한 가격에 주시는 제 단골집 형님. 

랍스타, 킹크랩, 대게 같은 갑각류 말고도 횟감도 다양하게 많답니다. 

참고로 돈이나 다른 대가를 받고 구입처를 언급한건 아니니 오해하지 마세요~ 

IDF 2014 에서 인텔은 에디슨 개발 플랫폼 판매를 시작한다고 발표했습니다. 

에디슨은 인텔의 급성장하는 사물인터넷(IoT)을 위한 개발 플랫폼 입니다. 우표보다 조금 더 큰, 매우 작은 크기의 에디슨은 아톰(Atom) CPU와 쿼크(Quark) CPU를 사용한 듀얼 코어를 탑재하고 있습니다. 주요 스펙은 다음과 같습니다. 

에디슨은 인텔의 22nm 공정으로 아톰 실버몬트(Silvermont Atom)과 쿼크(Quark)를 듀얼코어로 탑재하고 있다는 점이 흥미롭습니다. 아톰은 SoC를 위한 주 프로세서이고, 쿼크는 플랫폼에서 다른 기능들을 실행하기 위한 임베디드 마이크로 컨트롤러(embedded microcontroller)의 역할을 하게 된다고 합니다. 무선은 브로드컴(Broadcome) 43340으로 Wifi와 Bluetooth를 제공한다고 하네요. 경량, 저전력 장치를 개발하기에 적합하기 때문에 웨어러블 장치에 많이 사용될것 같습니다. 

에디슨 플랫폼은 추가적은 개발 보드에 부착함으로써 기능을 확장하거나 I/O에 접근할 수 있습니다. 인텔은 USB보드 타입의 'Breakout Board'와 아두이노(Arduino)와 호환가능한 'Arduino Kit' 두가지를 제공합니다. 물론, 아두이노와의 호환성을 제공합니다. 

Edison용 Brakout Board

Edison용 Arduino호환 Board

에디슨 모듈은 현재 $50, Brakout board kit은 $75, Arduino kits은 $100 정도에 판매되고 있습니다. 

혹시 구입해 보고 싶으시다면 SparkFun 상점에서 구입이 가능합니다.  참고로, SparkFun에서 자체 제작해서 판매하는 다양한 kit들도 있답니다. 

휴대용/절충형 유모차를 비교해보기 위해 들른 박람회에서 듣도 보지도 못했던 브랜드(관심이 없어서)의 유모차를 덜컥 구입해 버렸습니다. 

구입하고 나서야 레카로가 유명한 브랜드라는걸 알게 되었네요. 

브랜드를 고려하지 않고도 구입할 만큼 제품 자체에 대한 만족도가 높았기 때문에 가능한 일이였습니다. 

제가 사려 했던 유모차의 기준을 우선 순위 순서대로 나열해보면 다음과 같았습니다. 

1. 아기가 좋아해야 한다. 당연한 얘기겠죠? 

2. 자동차 트렁크에 넣기 쉬울만큼 작게 접혀야 한다. 아무래도 너무 크면 놀러 갈때나 건물안에 들어갈때 너무 불편하더군요. 

3. 핸들링나 수납이 편하면 좋겠다. 사실 이건 이왕이면 이랬으면.. 하는 정도였습니다. 

4. 가격! 이건 뭐 더 설명할 것도 없겠죠? (이건 제가 박람회에서 구입한 가격을 기준으로 판단한 것이니 개인차가 있을 수 있습니다.)

제품을 구입하고자 하는 사람 입장에서는 매우 당연하고 간단한 기준임에도 여러 제품을 비교해 보니 모든 조건을 만족하는 제품이 없더군요. 

전시장을 두 번 둘러보며 모든 유모차를 접어보고 끌어보고 하다가  실망하며 나오는 길에 레카로 이지라이프를 보게 되었어요.  

우선 매우 작게 접히기에 눈길이 가더군요. 아기를 태워봤는데 좋아하기도 했구요. 

고심끝에 다음날 다시 박람회장에 가서 구입을 하게 되었습니다. 

자.. 그럼 제품 개봉기와 실제 제품을 사용해본 경험자로써의 장/단점에 대해 얘기해 볼께요~ 

제품 개봉기 

기다리던 택배가 도착~~

겉 박스를 뜯어보아요.

속에 색이 예쁜 박스가 하나 더 있네요. 

꺼내서 개봉박두~!

한 눈에 보기에도 콤팩트하게 접힌 유모차가 똭~!!

앞 바퀴는 따로 들어있네요. (바퀴를 조립하고 다시 박스에 넣어보니 이게 살짝 튀어나와 있어서 빼서 배송하는거였네요.)

이건 레인커버와 멜빵 벨트에요. 

앞 바퀴는 완충제를 제거하고 끼워주면 끝. 

조립이 끝났답니다~ 

제품 주요 특징

유모차를 펼쳐보면.. 짜~잔~!

차양막 내려오는 위치도 맘에 들어요. 

차양막 위에는 아이를 볼 수 있도록 구멍이 나 있어요. 

등받이 조절은 이렇게 등받이에 달린 끈을 잡아 당기면 된답니다. 

아이가 누워있는 상태에서도 쉽게 조절이 가능합니다. 

유모차를 타고 가다가 잠이 들었다면 살며시 등받이를 내려줘도 아이가 깨지 않아서 참 좋아요. 

앞 바퀴 방향 고정 기능도 있어요. 레바를 잡아 당기면 고정되고 누르면 풀려요. 

사실 이 기능은 거의 쓸 일이 없더라구요~ 

뒷 바퀴 고정은 오른쪽 빨간색 레바를 발로 눌러주면 고정되고, 왼쪽 녹색 레바를 누르면 풀려요. 참 쉽죠잉~

마트 에스컬레이터 같은거 탈때 쓰면 힘들이지 않아도 되서 좋아요. 

색깔이 직관적이라 헷갈릴 일도 없고 좋아요. 

멜빵끈 설치는 핸들이랑 아래쪽에 있는 축에 채우면 되요. 

핸들에는 두 줄로 되어 있는 쪽을 채우면 되요. 

접거나 펼쳐도 딱히 걸리적 거리진 않아요. 

유모차를 들고 다녀야 할 일이 많지 않다면 멜빵끈은 궂이 사용하지 않아도 되더라구요. 

아래에는 여유로운 수납 공간이~ 장보러 다닐때 매우 유용하죠.

장바구니가 필요 없을 정도로 생각보다 넉넉하답니다. 

접고 펼치는건 동영상으로 살펴볼까요? 

손잡이에 있는 레바를 오른쪽으로 밀면서 잡고 아래 방향으로 돌려주면 됩니다. 

한 눈에 보기에도 참 편해보이죠? 실제로 해보시면 더 편하고 좋답니다~ 

제품의 장/단점

• 장점:

1. 가볍고 작게 접혀서 수납 및 휴대하기 매우 편하다. 

휴대하기 편하라고 멜빵끈을 별도로 판매하지만 멜빵끈이 있음에도 설치할 필요성을 딱히 느끼지 못할만큼 접어서 들고 다니기 편합니다. 

건물 계단이나 에스컬레이터에서 접어서 들고 갈때도 전혀 불편하지 않아요. 

그리고, 집 현관이 좁은 편임에도 작게 접히고 셀프 스탠딩도 되기 때문에 현관 한켠에 세워두면 걸리적 거리지 않아서 매우 좋아요. 

2. 아기가 너무 좋아해요. 

아기 낮잠이나 밤잠 재울때 너무 울어서 힘들었었는데.. 

요즘은 유모차에 태워서 아파트 단지 한 바퀴 돌면 어지간 하면 잠들어 버리네요. 

아기가 탄 채로 잠들면 등받이를 천천히 내려주면 깨지 않고 그대로 잘 잡니다. 

그러면 깨우지 않고 현관에 아기가 잠든 채로 유모차를 들여다 놓으면 끝~!

유모차 처음 조립한 날은 거실에서 태워줬더니 타자마자 1분도 안되서 바로 잠들어서 깜짝 놀랬던 기억이 나네요. 

바퀴 탈착이 쉬웠다면 바퀴를 추가로 구입해서 집안에서도 태워주고 싶을 만큼 아기가 너무 좋아합니다. 

요즘도 밖에 나가고 싶으면 현관에 세워둔 유모차를 가리키며 '타! 타!' 이럽니다. 너무 귀여워요. 

3. 접는 방식이 너무 편해요. 

작게 접히는 다른 유모차의 경우 접는게 조금 불편하더군요. 

이지라이프는 한 손으로 손잡이를 잡고 돌리고 누르면 끝~!

저 레카로 영업사원 아닌데요 정말 비교할 수 없을 만큼 너무 편해요. 

이건 매장가서 한 번 직접 비교 해보면 알꺼에요. 

4. 등받이 조절이 쉽고 편해요.

아기가 자고 있을 때도 쉽게 등받이 조절이 가능해서 다른 아기 엄마들이 부러워 해요.

5. 핸들링, 수납 모두 훌륭합니다. 

바람쐴겸 마트에 가면 장바구니가 없어도 걱정이 없을 만큼 기대 이상의 수납 능력을 보유하고 있어요. 

핸들링도 부드럽고 만족스러워요. 

• 단점:

1. 안전바가 없다. 

사실 안전 벨트만 채워도 되긴 하지만.. 아기들이 가만히 앉아 있으려고 하지 않잖아요?

그럴 때 안전바가 있으면 그걸 잡고 있을 텐데 안전바가 없어서 잡을게 없다보니 보기에 좀 안쓰러워요. 

2. 다리 받침을 조절할 수 없다. 

아기가 누워서 잠들면 조금이라도 편하게 해주고 싶은게 부모 마음이겠죠?

다리 받침을 조절 할 수 있다면... 하는 아쉬움이 남더라구요. 

3. 뒷 바퀴도 탈착이 가능 했으면..

사실 이건 지극히 개인적인 사심입니다만.. 

앞 바퀴는 개봉기에서 보면 알겠지만 탈착이 쉽게 가능합니다. 하지만, 뒷바퀴는 탈착이 쉽지 않아 보입니다. 

나중에 바퀴면 따로 교체(소모품이므로..) 한다거나, 실내에서 태워주고 싶을 때 탈착이 가능 했으면 좋겠다는 생각이 들더라구요. 

종합평점

부모 입장: ★★★★★  (접기 편하고, 작아서 휴대하기 편하며 핸들링, 수납도 만족스럽다. )

아기 입장: ★★★★☆ (아기가 타거나 눕기 편하지만, 안전바나 다리받침에 있어 아쉬움이 남는다.)

기        타: ★★★★☆ (사실 제품에 작은 문제가 있어 A/S 신청을 했었습니다. 레카로 측에서는 흔쾌히 신품으로 맞교환 해주더군요. A/S는 매우 만족하지만 어쨌거나 제품에 문제가 있었다는 점에서 살짝 실망.)

휴대용 이나 절충형 유모차 구입을 고민하게 계신다면 레카로 이지라이프 한 번 비교해보세요. 

개인적으로 매우 만족하며 쓰고 있답니다. 

리눅스 환경에서 프로그래밍을 한다면 Makefile의 필요성을 절실하게 느낄겁니다. 

Makefile이 있기에 수 많은 파일을 간단한 명령어 하나로 손쉽게 빌드하는게 가능하기 때문입니다. 

문제는 대규모 프로젝트에서 Makefile을 문법에 맞게 작성하는것이 간단한 일은 손이 많이 가고 귀찮은 일일 겁니다. 

이럴 때 autotool을 사용해 보세요. 

초기 설정과 수정이 용이하고, 누구나 쉽게 변경 할 수 있게 해줍니다. 

프로젝트 폴더로 이동해서 아래의 순서에 따라 명령어를 수행해 보세요. 

$ autoscan 

하위 폴더를 검색해서 configure.scan 파일을 생성해줍니다. 

이 파일을 configure.ac로 이름을 변경해서 사용 하면 됩니다. 

파일명을 변경 한 후 configure.ac 파일을 열어서 대괄호로 묶여 있는 변수에 적절한 값을 채워주세요. 

예를 들면  'AC_INIT'에는 이렇게 되어 있을 겁니다. 

여기에 아래와 같이 현재 프로젝트에 맞게 값을 채워주시면 됩니다.  

$ autoconf 

configure 스크립트를 생성합니다. (동시에 autom4te.cache 파일도 생성해줍니다. )

이 과정을 위해서는 configure.ac 파일이 존재해야 합니다. 

즉, configure.ac 파일에 있는 설정을 참고해서 configure 파일을 생성하는 겁니다. 

$ aclocal

다음 과정인 automake를 하기 위해 필요한 aclocal.m4 파일을 생성해줍니다. 

이 파일에는 automake에서 쓰는 매크로(macros)에 대한 내용이 들어있습니다. 

$ automake 

Makefile을 만드는데 필요한 Makefile.in 파일을 만들어 줍니다. 

automake명령어를 수행하게 되면 Makefile.am 파일을 참고해서 Makefile.in 파일을 생성해줍니다. 

Makefile.am은  프로그래머가 작성해 줘야 하는 파일로, 해당 프로젝트에 해당하는 정보를 기술해 주는 파일입니다. 

결과물로 생성될 실행 파일 이름을 뭐라고 할 지, 하위 디렉터리, 소스 파일, 사용할 라이브러리 정보 등을 써주셔야 합니다. 

위의 예제만 봐도 대충 어떻게 작성해줘야 하는지 감을 잡을 수 있을 겁니다. 

이 파일은 프로젝트의 모든 디렉터리 마다(include 폴더는 제외) 작성해 주어야 하며, 해당 경로에 소스코드가 없다면 'SUBDIRS'만 쓰면 됩니다. 

Makefile.am 파일의 문법에 대해 자세히 알고 싶으시다면 다음 링크를 참고하세요. 

만약, automake 과정에서 아래와 같은 에러가 발생하면.. 

configure.ac 에 아래처럼  'AM_INIT_AUTOMAKE'를 추가해 줘야 합니다. 

$ autoreconf 

automake 과정에서 config.h.in 파일이 없다고 아래와 같은 오류가 나오면 실행해 줍시다. 

그러면 config.h.in 파일이 생성됩니다. 

$ automake --add-missing

automake 에서 아래와 같이  'COPYING' 이 필요한데 없다고 에러가 나면 실행해 줍시다. 

그러면, 'COPYING'와 같은 automake 에 필요한 디렉터리가 자동으로 생성됩니다. 

$ ./configure

autoconf로 생성한 configure를 실행 시킵니다. 

이 스크립트는 automake로 생성한 Makefile.in을 참고해서 Makefile을 만들어줍니다. (중간 과정에서 config.status 파일이 생성됩니다. )

이 과정까지 모두 오류없이 진행 하였다면 Makefile이 생성되어 있어야 합니다. 

$ make

위 과정에서 생성한 Makefile에 따라 빌드를 수행합니다.

$ make install

필요에 따라 빌드한 결과를 설치하면 됩니다. 

결과적으로 직접 만들어 줘야 하는 것은 Makefile.am 파일 하나 밖에 없구요. configure.ac는 조금 수정만 해주면 됩니다. 

과정이 조금 복잡해 보이기는 하지만 한 번 설정 해두면 복잡한 문법의  Makefile  대신 하위 디렉터리, 소스코드 이름 정도만 나열해 주면 되는 Makefile.am파일만 수정하면 되기 때문에 매우 편하게 작업을 할 수 있답니다.