Yellowbirds

지난 글에서 사물에 RFID tag를 부착하고 그것들을 coupling해서 함께 다녀야 하는 물건들 중에 무언가가 누락되거나 내것이 아닌 물건이 내게 딸려오는 등의 사고를 막는 이야기를 했었다. 지난 글의 저자들이 조금 더 예전에 다른 제목의 논문을 또 낸 것을 확인하고 읽어보았는데, 내용상 거의 차이는 없었다. 논문 제목은

    Ubi-Check - A Pervasive Integrity Checking System
    Michel Banatre, et al.
    INRIA Rennes / IRISA

이들의 연구를 보면 아이디어는 단순하지만 실제 구현을 직접 해봤다는 점에서 의미가 있어 보인다.

모든 태그를 빠르고 정확하게 인식시키는 것이 상당히 어렵다고 한다. 여러 명의 사람이 문을 통과할 경우 사람들이 지니고 있는 물건에 붙어 있는 모든 태그를 동시에 읽는 것이 만만치 않은 모양이다. 논문에서는 한 명씩 통과하는 것을 권고하고 있고, 사람이 들어오기 시작한 후 다음 사람이 들어오기까지 2초 ~ 3초의 간격이 있으면 좋다고 말한다.

인식률을 높이는 것이 결국 어렵다는 결론이 나온다면, 문을 회전문 방식으로 만들고 한 명씩 들어가게 하는 것도 방법일 듯 하다. 회전문은 개별 공간이 나름 밀폐된 공간이므로 reader를 여러 군데에 부착하기도 좋을 것 같고, 특수한 재질로 설계한다면 칸마다 Faraday cage와 같은 효과를 낼 수도 있지 않을까 생각이 든다.

회전문이 아니면 어떨까. 일반적인 건물의 문이라면 여러 사람에 동시에 들어올 것이다. 사람마다 미리 coupling된 물건들을 가지고 있을 것이므로 사물이 어떻게 grouping되었는지는 coupled signature (group의 ID를 hash하여 얻는 값)을 보면 될 것이다. 같은 그룹은 같은 signature를 가지고 있을 것이니까. 하긴, 문제는 인식률이라고 하니까.

또 하나 생각해볼 수 있는 것은 문을 통과할 때 이 coupled signature가 틀리는 경우다.

1. 내가 1개 이상의 내 물건을 어딘가 다른 곳에 두고 문을 지나는 경우
2. 내가 1개 이상의 타인 물건을 지니고 문을 지나는 경우
3. 내가 1개 이상의 내 물건을 빠뜨리고 1개 이상의 타인 물건을 지니고 문을 지나는 경우
   

정도로 구분해볼 수 있겠다. 3번과 같은 케이스는 논문에서 언급이 되지 않고 있는데 내 카메라와 다른 사람 카메라가 똑같아서 내 것인줄 알고 가지고 가는 경우를 생각해볼 수 있다. 의외로 빈번히 발생할 수 있다고 본다.

각 케이스에 대해 정확히 판단을 내려줄 수 있는 방법은 없을까? 논문에서는 특정 디바이스에 전체 그룹의 구성원 수를 기록해둬서 그것을 이용해 판단한다는 이야기가 있다. 예를 들어 내가 지니고 있는 물건이 5개인데, 문을 나갈 때 6개의 사물이 인식이 되면 2번의 케이스라고 판단하고, 3개의 사물이 인식되면 1번의 케이스라고 판단한다는 것이다. 그러나 이것은 3번 케이스를 전혀 고려하지 않은 이야기다. 즉, 논문은 각 케이스를 구분하는 방법을 정확히 제시하지 못하고 있다. 전체 ID를 모아서 해시한 값을 모든 태그나 나눠서 가지기 때문에 당연한 결과인데, Bloom filter 등의 기법을 도입하여 다른 그룹 멤버에 대한 정보도 일부 가질 필요가 있다고 본다. 물론 각 케이스를 구분해야 하는 상황에서만. 구분할 필요 없이 이상이 있다 없다만으로 충분하다면 논문이 제시하는 이야기로도 충분히 해결이 된다.

논문을 보니 이것을 실제로 구현해서 전시회도 했다고 하는데, 이렇게 직접 구현하고 실험하고 하는 모습이 상당히 좋아보인다. 물론 귀찮겠지만 :p

다음 논문을 읽고 감상을 남긴다.

Pervasive Integrity Checking With Coupled Objects
Paul Couderc, et al.
INRIA Rennes, Compus Universitaire de Beaulieu, FRANCE

이번에 ANT 2011이라는 학회에 운 좋게 참석하게 되었다. 캐나다의 나이아가라 폴스에서 개최되는 학회라 나이아가라 폭포까지 감상할 수 있었다. 정말 운도 좋다. 심지어 학회장이 폭포가 보이는 거리에서 100미터 정도밖에 떨어지지 않은 거리.

이 학회에서 위 논문의 발표를 들을 수 있었는데, 들었던 발표중 가장 기억에 남는 아이디어라 한국에 도착해서 프로시딩 CD를 뜯고 가장 먼저 읽어보게 되었다. 이 논문에서 이야기하는 주 아이디어는 RFID tag coupling이다. RFID tag에는 고유한 아이디가 있을 것이다. RFID가 막 뜨기 시작할 때 많이 언급된 어플리케이션으로 물류가 있었는데, 모든 아이템에 태그가 붙어 있으면, 리더가 원거리에서도 사물을 읽을 수 있으므로, 태그마다 고유 아이디를 가지고 있다면 해당 물품을 정확히 인식할 수 있다는 것이었다. 태그에 아이디는 MIT에서 제안한 Auto-ID 같은 것을 쓸 수 있겠다. 이 논문에서는 EPC ID라는 것을 언급했는데 96 bits라고 한다.

논문에서는 개별 사물의 인식이 아닌 그룹 구성원에 대한 인식에 초점을 맞춘다. 그룹 구성원의 변동이 없어야 하는 상황에 대해 언급하고 있는데 생각외로 이렇게 시각을 바꿈으로써 적용해볼 수 있는 어플리케이션이 많아지더라.

• 유치원 선생님이 박물관에 아이들을 데려갔다고 하자. 30~40명 정도를 데리고 다녀야 하는 경우 한 두 명이 이탈하는 것을 파악하는 것이 쉽지 않다. 아이들에게 태그를 모두 부착해두면 어떨까? 선생님이 쉽게 이탈자 여부를 파악할 수 있지 않을까?
• 식당과 같은 곳에 갔을 때 내가 가지고 들어갔던 사물들(핸드폰, 가방, 노트북, 지갑 등)을 식당 입구에서 체크해둔다. 내가 식당을 빠져나갈 때 '물건을 두고 나오셨습니다!'라고 알려줄 수 있다면 좋지 않을까? 식당보다 택시를 예로 든다면 더 좋겠다. 택시에 뭔가 떨어뜨리고 나오는 것은 생각만해도 아찔하지 않은가!
  

요즘 NFC가 사물 인식에 대세로 떠오르고 있지만 이 경우에는 RFID가 더 편할 듯하다. 사용자가 특별히 인식하지 않고도 서비스를 받을 수 있어야 하니까.

여기까지 이야기를 들으면 서비스 제공자가 사용자가 가지고 있는 태그들을 특정 시점에 모두 스캔하여 보관하고 있다가 후에 체크하는 방식을 취하면 되겠다고 생각할 수 있다. 예를 들어 내가 식당에 A, B, C, 세 가지 물건을 가지고 들어갔다면 식당은 이 정보를 보관하고 있다가 후에 나갈 때 A, B, C가 함께 나가는지 체크해주면 된다. 하지만 여기서 문제는 A, B, C가 그룹을 형성하고 있다는 것을 어떻게 알 수 있는가 하는 것이다. 식당에 들어올 때 한 명씩 시간 간격을 두고 들어와준다면 (나갈 때도 마찬가지) 구현 가능할 듯 하지만 불편함은 있다.

이 논문은 조금 다른 방식으로 접근한다. 그룹을 맺어야 하는 사물들이 미리 그룹을 형성한다. A, B, C, 세 가지 사물은 당연히 각자 자신들의 아이디를 가지고 있을 것이다. 여기에 더해서, 자신을 제외한 그룹 멤버들의 정보 또한 가지고 있자는 것이다. 즉, A의 경우 B와 C의 아이디를 저장하고 있으면 된다. 그런데 RFID의 메모리는 넉넉하지 않다. 일반적으로 512 bits 정도라고 하는데 아까 말했듯 식별 아이디 자체가 96 bits 정도이니 그룹 구성원의 수가 대여섯개가 넘어가기 시작하면 이 방식은 구현이 불가능하다. 영어 좀 쓰면 scalability 측면에서 좋지 못하다.

그래서 제안하는 방법은 해시를 이용하는 것이다. SHA-256을 사용했다고 한다. 자신을 포함한 모든 구성원의 아이디를 이용해 해시값을 얻는다. 모든 그룹 구성원이 같은 값을 얻게 될 것이다. 이것을 태그에 모두 저장해둔다. 이렇게되면 space 문제는 해결할 수 있다. 모든 태그가 2 * [the length of ID] 만큼의 공간만 있으면 된다.

이 방식을 사용해도  점검자(예를 들면 식당이나 공항의 출입구)가 체크를 할 때 어떤 범위로 태그 집합을 인식하고 그것을 바탕으로 해시값 비교를 할 것인가는 여전히 어려운 문제다. A, B, C, 세 사물을 커플링해둔 상태에서 입구로 들어갔을 때, reader가 A, B만 인식했다면, 또는 타인의 사물인 D까지 포함해서 A, B, C, D, 네 개의 사물을 인식했다면 오류를 일으킬 것이기 때문이다. 이 문제에 대해 논문은 별다른 언급을 하진 않았지만, 후자의 경우는 D가 다른 해시값을 가지고 있을 것이니 쉽게 제외시킬 수도 있을 것으로 생각된다. 그러나 전자의 경우는 방법이 없다.

논문은 태그를 읽는 방식을 soft, hard로 나누어서 구현 시 이슈로 언급하고 있다. 소프트는 차례로 태그들을 읽어가는 것을 말하며 하드는 - inventory read라고 불리는 - 하드웨어적으로 한 번에 여려 태그를 인식하는 방식을 말한다. 인식률면에서는 소프트가 좋다고 한다. 인벤토리 리드는 태그의 수가 많을 때 전체를 인식하지 못하고 상당한 수의 태그를 놓치게 된다고 한다. 물론 인식 속도는 당연히 하드가 빠르다. 소프트는 순차적으로 모든 태그를 읽어야 하기 때문에 태그의 수에 비례하여 읽는 시간이 소요된다.

예전에 RFID tag에 대해 한참 이야기를 많이 할 때, 이를 이용하여 계산대에서 바로 계산되는 어플리케이션을 많이들 이야기 했었다. 카트를 전속력으로 밀고 계산대를 지나가버리면 몇 개 물품은 계산되지 않는 문제가 있다고 살짝은 농담 섞어 이야기들을 하곤 했는데, 아주 심각한 문제였다. 상용화가 되려면 이런 오류는 용납되지 않으니까. 이런 이야기를 한 것이 벌써 5~6년은 된 것 같은데 아직도 이 문제는 해결되지 않았나보다.

논문을 읽다 궁금했던 점은 태그가 가지는 ID가 copy(clone)되는 일은 없을까 하는 것이다. 태그의 아이디는 쉽게 얻을 수 있는 값이므로 복사하여 바꿔치기할 수도 있을 것 같다는 생각이 든다. 논문에서 이에 대한 언급은 없다.

또 하나 논문에서 언급한 것은 proxy fragment인데, 여기서 fragment는 커플링되는 개별 사물을 말한다. 프록시 프래그먼트는 실존하지 않는 사물에게도 아이디나 기타 다른 비트스트링을 부여하여 함께 해시값을 얻을 수 있다는 것이다. 예를들어, 자전거와 자전거 주인을 커플링할 수 있다. 누군가가 자전거 보관소에서 내 자전거를 훔쳐 자기 것인 듯 끌고 나갔을 때 자전거 보관소의 입구에서 내 자전거의 태그와 그 사람의 정보를 가지고 해시값 비교를 해볼 수 있다. 그 사람이 나인 척 impersonation에 성공하지 않는 이상 간단히 도둑질이 발각될 것이다.

아주 심플한 아이디어고 태그에 데이터를 저장하기 때문에 별도의 데이터베이스도 필요없다. 별도의 데이터베이스에 정보를 저장하지 않기 때문에 프라이버시 측면에서도 나쁘지 않은 디자인이다. 태그 인식률과 속도가 개선되고 태그값이 복사되거나 스푸핑되지 않도록 할 수 있다면 심플하면서도 상당히 쓸모가 많은 아이디어가 아닌가 생각된다.

The Most Expensive One-byte Mistake라는 글을 읽었다. acmqueue에 실린 글이고 Poul-Henning Kamp가 쓴 글이다. Kamp씨는 FreeBSD 커뮤니티에서 활동하는 사람이라 괜히 정감이 간다. 각설하고.

글쓴이는 역사상 가장 큰 비용의 실수는 뭔가? 하는 질문을 던진다. IT와 CS의 역사에서 잘못된 선택으로 인해 고생했던 몇 가지 예를 서두에 언급하지만 결국 하고자 하는 이야기는 NUL-terminated text string이다.

텍스트 스트링은 상당히 자주 사용되는 자료형이다. 자바 프로그램에서 가장 많이 생성되는 객체는 String이라는 글을 읽은 적이 있다. 초기에 C를 만든 세 명은 스트링을 표현하기 위해 다음 두 가지의 선택사항을 가지고 있었다. 물론 현재에도 누군가가 언어를 설계한다면 둘 중에 하나를 선택해야 할 것이다.

1. address + length
2. address + magic_marker (NULL)
   

그들은 2번을 선택했다. 최적화라는 취지에서 2번이 좋아보였을 것이다. 길이를 저장하기 위한 별도의 공간을 마련하지 않아도 되니까.

의외로, 그 당시 많은 언어들이 1번을 채택하고 있었다고 한다. 2번을 택했던 언어는 어셈블리였다고. 앞서 언급한대로 1번은 길이를 매번 따로 저장해야 하니 비효율적일 것이다라는 느낌을 준다. 하지만 유리한 점도 있다. 데이터 복사나 이동을 할 때 대상 데이터의 크기를 즉시 알 수가 있다는 점. Cache를 활용할 때도 유리할 수 있다. 2번과 같이 매직 마커를 쓰면 마커를 찾아야 하는 비용이 높다. 크기를 미리 안다면 블록 단위의 복사를 바로 실행할 수가 있는데, 마커를 사용하면 마커를 우선 찾고 복사를 시작해야 한다. memcpy와 strcpy가 다를 수밖에 없는 이유가 되는 것이다. Constant string의 경우 컴파일러가 그 크기를 알고 있기 때문에 사용자가 strcpy를 요청해도 memcpy로 대체하여 스피드면에서 이득을 얻기도 한다고 한다.

앞서 언급한 효율의 문제를 떠나 보안의 입장에서 바라보자. 2번을 택한 것이 훗날 버퍼 오버플로우가 일어날 수 있는 여지를 주었다. 이것은 정말 큰 문제고, 저자가 이 글을 쓴 이유다. gets()의 절망적인 보안 수준은 다들 공감할 것이다.

하지만 C를 만든 Ken, Dennis, Brian을 마냥 욕할 수는 없다. 그들이 C를 만들고 15년이 지나서야 사람들은 이게 보안적인 측면에서 나쁘다는 걸 알았다고 한다. 그러니 잘못된 선택을 했다고 비난하기는 힘들지 않은가.

현재 C로 직접 프로그래밍하는 사람이 예전만큼 많지는 않다. 그러나 대부분의 언어가 C로 구현되어있다. 다른 언어로 프로그래밍을 해도 결국엔 libc가 호출되고 여전히 NUL-terminated string은 쓰인다.

그럼 이제와서라도 2번을 버리고 1번을 선택해볼 것인가? 지금까지 만들어둔 프로그램이 아깝기 때문에, 당장 모든 대체 프로그램을 만들 수가 없기 때문에 바꿀 수는 없을 것이다. 이미 만들어진 프로그램의 수보다 앞으로 만들어질 프로그램의 수가 훨씬 많음에도 바꿀 수가 없는 것이다.

ps. 처음 이 글을 쓸 때는 살아있던 Dennis가 티스토리로 글을 옮기는 현재 세상에 있지 않다. 고인의 명복을 빈다.

글이 너무 재밌어서 번역해본다. 너무 심각하게 읽을 필요는 없다. 이 글을 쓴 사람도 프레임워크에 대한 비난을 하기 보단 개천을 건너기 위해 배를 건조하는 일은 없도록 하자는 정도로 이렇게 표현했다고 본다. 즐거운 유머로 받아들이면 될 듯. 글 중간중간에 역주를 달고 싶은 유혹이 무척 많았지만 오히려 글을 망치는 것 같아 관뒀다. 그리고 영어를 읽을 수 있다면 가급적 원문을 읽으시길 권한다. 자연스럽게 읽히도록 하다 보니 직역을 하진 않았다. 번역문 시작!

제목: 내가 프레임워크를 싫어하는 이유

요즘 자바 웹 어플리케이션을 만들어보려고 계획하는 중이다. (어쩔 수 없다. 자바여야 한다. 여러가지 이유가 있는데 지금 설명하고 싶진 않다) 여튼 만들려고 하다보니, J2EE 포틀릿이 가능하고 JSR을 준수하는 MVC 롤 기반의 CMS 웹 서비스 어플리케이션 컨테이너 프레임워크를 몇 개 살펴보게 되었다.

각 프레임워크에 대한 문서를 수십시간 읽고났더니 눈이 빠지려 한다.

양념통 선반을 만들기로 했다고 상상해보자.

예전에 몇 번 비슷한 걸 나무로 만들어봐서 나름대로는 뭐가 필요한지 잘 알고 있다. 나무와 몇 가지 기본적인 도구가 있으면 된다. 줄자, 톱, 평평한 작업대, 망치 정도?

내가 만약에 양념통 선반이 아니라 집을 짓고 싶었다고 해도 여전히 자, 톱, 작업대, 망치는 필요하겠지.

어쨌든 도구를 사러 상점에 갔다. 점원에게 망치는 어디 있나 물어봤다.

점원이 대답한다. "망치요? 요즘에 아무도 망치 안 사요. 완전 유행 지났는데."

좀 놀랬다. 왜 그런지 물어봤다.

"흠, 망치의 문제는 말이죠, 종류가 너무 많다는 거죠. 큰 망치, 장도리, 볼핀 해머, ... 이런 거 중에 하나만 사셨다가 나중에 다른 게 또 필요하시면 어떡해요. 그럼 또 사셔야 되잖아요. 그래서 우리는 이런 생각을 했어요. 살면서 망치질 할 일이 있을 때, 어떤 경우에도 쓸 수 있는 망치를 사람들이 정말로 원하겠구나 하고요."

"흐음. 뭐, 맞는 말인 거 같네요. 그럼 그 만능 망치는 어디 있어요?"

"없어요. 더 이상 안 팔아요. 그것도 옛날 이야기죠."

"네? 좀 전에 만능 망치가 대세가 될 거라고 하지 않았어요?"

"만능 망치를 만들어보니 오히려 어디에도 별 쓸모 없다는 걸 알게 됐어요. 못 박는데 커다란 망치를 쓰면 불편하잖아요. 그리고 옛날 여자친구를 죽이고 싶으면 볼핀 해머만한게 없기도 하고요."

"그건 그렇네요. 그래서, 이제 아무도 만능 망치를 안 사고, 상점에서는 옛날 스타일의 망치를 안 파시고. 그럼 어떤 망치를 파세요?"

"사실, 이제 우린 전혀 망치를 팔지 않습니다."

"그러면..."

"우리가 연구를 좀 해봤는데요, 사람들이 원하는 건 만능 망치 같은 게 아니었어요. 일을 할 때 그 일에 딱 맞는 망치를 쓰는 게 중요하죠. 그래서 우리는 망치 공장을 팔기 시작했어요. 어떤 망치든 만들 수 있는 공장이요. 망치 공장에서 일할 사람 구하시고 재료 좀 사신 다음에 기계 돌리면 아주 빠르게 정확히 원하는 망치를 만드실 수 있죠."

"저 그런데 전 정말로 망치 공장을 사고 싶은 생각은 안 드는데요."

"네네. 사실 그것도 더 이상 안 팔아요."

"저기 근데 좀 전에..."

"대부분의 사람들이 말이죠, 공장을 통째로 사는 걸 별로 원하지 않는다는 걸 알게 됐거든요. 볼핀 해머가 전혀 필요 없는 사람이 있을 수도 있으니까요. 뭐 헤어진 여친이 없다거나 볼핀 해머 대신에 송곳으로 죽였거나 뭐 그런 사람들이요. 그래서 포인트는, 모든 망치를 다 만들 수 있는 망치 공장을 사는 사람은 없더라 이거죠."

"네. 말되네요."

"그래서, 대신에 공장을 만들 수 있는 설계도를 팔기 시작했어요. 고객들이 직접 망치 공장을 만들 수 있게 해주는 거죠. 원하는 망치들만 정확히 만들어 낼 수 있는 망치 공장을 만들 수 있지요."

"내 생각엔, 그것도 이제 안 파시죠?"

"네. 당연히 안 팔죠. 망치 몇 개 만들자고 공장을 짓는 걸 별로 원하지 않는다는 걸 알게 됐거든요. 공장을 만드는 건 공장 짓는 전문가들이 해야죠."

"맞는 말씀입니다."

"네. 그래서 설계도 파는 건 그만두고 망치 공장을 만드는 공장을 팔기 시작했어요. 망치 공장 공장으로 부를게요. 이 망치 공장 공장은 일반인들을 위해서 최정상급 전문가들이 만들었어요. 그러니 공장 내부에 대해서는 전혀 신경 쓰실 필요가 없죠. 그러면서도 사용자의 취향에 딱 맞는 망치 공장을 만들어낼 수가 있죠. 사용자가 필요한 대로 망치를 설계한 다음에 대량 생산할 수도 있어요."

"어, 글쎄요, 그건 그다지..."

"그렇게 말할 줄 알았어요!! 그것도 역시 지금은 안 팔아요. 몇 가지 이유로, 망치 공장 공장을 사는 사람도 별로 없더라고요. 그래서 이 문제를 해결하기 위한 새로운 해결책을 생각해냈죠."

"아하."

"사람들이 망치 공장 공장과 거기서 만들어진 망치 공장을 관리하고 가동하는 부분에서 많이 좌절하더라고요. 확실히 그런 작업이 좀 부담스럽긴 하죠. 그리고 다른 공구들도 생각해봤을 때, 줄자 공장 공장, 톱 공장 공장, 선반 공장 공장 같은 거 더 모두 작동하려면 좀 힘들긴 하잖아요? 그냥 양념통 선반이나 만들려고 했던 사람한테는 확실히 복잡한 과정이긴 하죠."

"네. 정말 그렇네요."

"그래서 이번 주에 우리가 신제품을 하나 내놨어요. 범용 공구 제작 공장 공장 공장인데요, 사람들이 필요로 하는 어떤 공구 공장 공장이라도 이 하나의 통합된 공장에서 만들 수 있어요. 이 공장 공장 공장은요, 딱 필요로 하는 도구에 대한 공장 공장만을 만드실 수 있거든요. 그러면 이 공장 공장에다가 필요한 공구의 스펙을 넣어주면 그 공구를 만드는 공장이 짠 하고 만들어지는 거죠. 뭔가 만들려고 할 때 그것을 위한 딱 맞는 공구셋을 이 과정을 통해서 얻으실 수 있겠지요. 물론 정확한 설정 파일들을 세팅해주셔야 하긴 합니다만 버튼 한 번 누르시면 정확히 필요했던 망치, 정확히 필요했던 자를 얻으실 수 있는거죠."

"그래서 이제 망치는 전혀 안 파시는거에요? 하나도요?"

"네. 고품질의 양념통 선반을 만들고 싶으시면 싸구려 도구 상점에서 파는 조잡한 망치보다는 뭔가 세련된 도구가 확실히 필요하죠."

"어... 다른 사람들도 다 그래요? 다들 망치 필요할 때 범용 도구 제작 공장 공장 공장을 쓰고 있는거에요?"

"그럼요."

"흠, 알겠어요. 저도 그래야겠네요. 다들 그렇게 하고 있다면 저도 어떻게 하는지 배우는게 좋겠네요."

"잘 생각하셨어요!!"

"설명서도 같이 주시죠?"

- Benji Smith, 2005년 9월 30일 금요일.

Why Undergraduates Should Learn the Principles of Programming Languages라는 글을 읽었다. 왜 학부생들이 언어의 원리를 알아야 하는가? 하는 물음이다.

컴퓨터 공학을 배우러 왔다는 것은 컴퓨터를 잘 이해하려고 온 것이고 컴퓨터를 이해한 뒤에 해야할 일은 잘 써먹는 것이겠다. 그러니 공학이라고 부르는 것이고. 컴퓨터에게 일을 시켜먹으려면 정확히 어떻게 일해야 하는지 잘 설명해줘야하고 의도를 잘 전달하기 위해서 우리는 다양한 언어(language)를 사용한다.

글의 제목은 의문문을 선택했지만 결국 하고 싶은 말은 프로그래밍 언어의 원리를 알아야 한다는 주장이다. 어떤 것을 공부하는데 있어 그 원리를 아는 것은, 사실, 당연한 일이다. 저자가 제목을 이렇게 단 것은 다음과 같은 이유다.

요즘 세상은 하나의 언어만 잘 아는 것으로는 부족하다. 요즘이 아니라도 예전에도 그랬을 것이다. 단 한대의 서버로 동작하는 웹서버를 만들더라도 SQL로 database와 이야기하고 자바로 웹서비스를 짜고, 클라이언트를 위해 자바스크립트도 써야 하지 않나.

언어가 많으니 난잡하다. 궁극의 언어가 있으면 좋지 않을까? Ultimate programming language? 하지만, 그런 것이 존재할 일은 없을 것이다. 지금 주요 언어들은 각자 자기의 영역을 확고히 하면서 생존하고 있다. 리눅스를 설치해보면 느낄 수 있다. Perl, Ruby, Python, ... 내가 설치하라 명령하지 않아도 기본적으로 패키지에 포함된다. 운영체제 설치 시 기본으로 포함되어 있는 필수 프로그램들이 저마다 다른 언어로 작성되어 있기 때문이다. 언어들은 살아남기 위해 치열하게 경쟁하고 있기도 하다. 옛날처럼 서버 스크립트가 몽땅 Perl로 짜여지고 있지 않다. (FreeBSD는 오래 전에 운영체제의 필수 스크립트를 Perl에서 shell script로 교체했다) 소위 4세대 언어라고 불리는(대표적으로 SQL) 언어들은 자기만의 독자적인 도메인을 가지고 있어 대체도 쉽지 않다.

언어가 많아서 난잡한 것이 아니라 언어가 다양함으로써 얻는 이득이 더 많은 것이 아닐까? 종의 다양성은 일반적으로 전체 생태계를 안정적으로 유지하는데 도움이 된다. 소프트웨어는 다양한 도메인이 있다. 그리고 각 도메인에 맞는 프로그래밍 언어가 있다. 상황에 맞게 언어를 선택하는 것이 중요하다는 이야기다. 엔지니어에게는 여러가지 상황이 발생할 수 있고 다시 말해서 새로운 언어를 습득해야 하면 유리할 경우가 발생할 수 있다. 결론적으로, 여러 언어에 쉽게 적응할 수 있도록 기초(fundamental)에 대한 습득이 필수적이다.

어차피 프로그램이란게 자료구조와 알고리즘 아닌가? 라고 말한다면 너무 기초로 간 것이고. 프로그래밍 언어에 따라 문제를 기술하고 해결하는 방식이 다르다는 것을 이해하고 각자가 가지는 장점과 단점이 무엇인가를 알 필요가 있다.

자, 그렇다면, 다시 글의 제목으로 돌아가자. 학부생에게 어떻게 프로그래밍의 기본 원리, 기초에 대해 정확히 교육시킬 것인가? 아쉽게도 이 글에서는 이 물음이 중요하다는 이야기만을 몇장에 걸쳐 하고 있다. How? 해결책은 구체적으로 나와있지 않다. 나도 모른다. 중요성에 대해서만 적극 공감할 뿐.

어설픈 의견을 내본다면, 여러 언어를 접해보는 것이 가장 좋은 방법이 아닐까 생각해본다. 언어라는 것은 부딪혀 직접 말해봐야 느는 것이니까. 자연어 세계에서 한 언어를 습득하면 그 언어만이 가지고 있는 표현 방식이나 단어 사용 패턴을 이해하게 되고 , 다른 언어에 그것을 잘 적용하면 굉장히 신선한 표현이 되는 경우가 많다. 이 원리는 컴퓨터 프로그래밍 언어에서도 다르지 않다.

크롬에 대해서 보다가 HSTS라는 것을 보게 되었습니다. HTTP Strict Transport Security의 약자인데요, (정확히 이해했는지 확신이 아직 좀 없지만) 쉽게 말하면 "무조건 HTTPS를 쓸 것!"이 됩니다.

크롬을 사용하고 있다면,

chrome://net-internals/#hsts

이 링크로 접근 가능합니다.

여기에 등록해두면 해당 사이트에 접근할 때, 명시적으로 앞에 https:// 를 타이핑하지 않아도 무조건 https로 접속을 시도합니다.

그런데 사용자가 일일이 이 리스트를 입력하고 관리하는 것이 꽤나 귀찮은 일이죠. 그래서 크롬은 preloaded HSTS list라는 것을 built-in으로 가지고 있습니다. 몇 가지 예를 들면

• www.paypal.com
• (chrome|checkout|health|docs|spreadsheets|sites|appengine|encrypted).google.com
• market.android.com
  

이런 사이트들이 포함되어 있지요. 이 리스트는 구글이 정해둔 것도 있겠지만 해당 웹사이트에서 요청한 것이 대부분입니다. 여러분 누구나 내 웹사이트는 무조건 https를 사용도록 강제하고 싶다면 구글에 요청 메일을 보내면 됩니다. (아마 사이트의 규모가 좀 있어야 해주겠죠?)

앞서 작성한 DigiNotar의 가짜 구글 인증서에 이어서 쓰는 글입니다.

IE의 경우 MS에서 windows update를 통해 처리한 것으로 들었습니다. 여기서 처리했다 함은 웹브라우저가 DigiNotar를 Root CA로 인정하지 않도록 하는 것을 말합니다. 심플한 대처지요.

파이어폭스의 경우에도 업데이트를 통해 동일한 처리를 했고, 업데이트가 싫으신 분은 설정에 인증서 관리에 가셔서 직접 제거하셔도 된다고 합니다.

크롬도 마찬가지로 제외시켰다고 했는데, 크롬을 사용하고 있었다면 '혹시 내가 당하지 않았나?'하는 생각을 하지 않아도 됩니다. 왜냐하면 이 사건이 알려진 것이 크롬의 역할이 컸으니까요.

구글의 지메일 포럼에다가 누가 이런 글을 올렸는데, 크롬이 인증서가 이상하다며 경고 메시지를 보내줬다는 것이죠. 그래서 이게 man-in-the-middle attack이 아닌가하고 질문을 했고, 세상에 알려지게 되었습니다.

크롬 입장에서는 은근 자랑할만한 사건이 생긴 것이 되겠네요.

크롬이 경고를 날릴 수 있었던 것은 certificate pinning이라는 개념을 크롬이 도입하고 있어서인데, 개념이라고 하니 무척 고급 기술이 들어간 것 같지만, 별거 아니고, 특정 사이트의 인증서에 대한 root CA 리스트를 강제해두는 것입니다. 좀 더 쉽게 말하면 구글의 인증서를 인증해줄 수 있는 기관은 여기 여기뿐이다라고 정해두는 것이죠. 즉, 사이트별로 root CA whitelist를 가지는 것입니다.

구글은 (2011년 5월 4일 시간 기준으로) 구글 사이트들에 대한 인증을 해줄 수 있는 기관을 Verisign, Google Internet Authority, Equifax, GeoTrust 이렇게 4개의 인증기관으로 한정지어 두고 있습니다. 그러니 DigiNotar가 비록 root CA로써 활동하고 있는 인증 기관임에도 여기서 발행된 *.google.com에 대한 인증서는 크롬 입장에서는 '이상한데?' 하고 의심할 수 있게 되는 것이죠.

안녕하세요? 천재태지 서주영입니다.

EFL 에서 widget 에 해당하는 elementary 라이브러리를 개발하다보면 src/lib 디렉토리에 있는 파일 이름이 왜 els, elc, elm, elu 로 시작하는지 궁금하실겁니다.
이에, 간단히 설명을 해봅니다.

• els : elementary smart object
  elementary 내부적으로 사용하는 smart object 입니다.
  예를 들면, diskselector, entry, gengrid, genlist, list, map, scroller 등의 widget 은 내부적으로 scroller 를 가지고 있습니다. 이 때, scroller 에 해당하는 공통적인 코드를 els_scroller 로 만들어놓은 것이 els widget 입니다. 그리고 이를 다른 widget 이 사용합니다. 즉, els widget 은 elementary 내부에서 공통적으로 사용되는 smart object 입니다. 어플리케이션에서 직접 사용하지 않습니다.
  els_box, els_icon, els_scroller 등이 있습니다. 
  참고로 elm_scroller widget 도 내부적으로 els_scroller 를 사용하고 있습니다.
  
• elm : elementary widget
  일반적인 widget 입니다.
  actionslider, button,  bubble, check, entry, gengrid, genlist, icon, image, label, list 등이 있습니다.
  
• elc : elementary collector widget
  여러 widget 을 합쳐놓은 widget 입니다. 한 widget 이 내부적으로 다른 elm widget 을 사용할 때 주로 쓰이는 용어입니다.
  anchorblock, ctxpopup, fileselector, naviframe 등이 있습니다.
  
• elu : elementary utility
  widget 이라기보다는 편의를 위하여 제공되는 기능입니다. 
  현재는 elu_ews_wm 밖에 없습니다. EWS는 Ecore + Evas Single Process Windowing System 을 의미하며, 이 기능이 활성화 되어 있으면 elementary widget 이 내부적으로 window manager 를 구현해줍니다.  

위 규칙이 엄격하지는 않습니다만, 대략적으로 이 규칙을 따라주면 나중에 코드를 이해하고 사용하기에 좋을 것입니다. 물론 어플리케이션 프로그래머들은 이 규칙을 알 필요가 없습니다.

감사합니다. 

친구(@skyisle)의 페이스북 글에서 가짜 구글 인증서 사건이 있었다는 것을 알게 되었다. DigiNotar라는 곳에서 구글(정확히 말하면 *.google.com)에 대한 인증서를 발행했다는 것이다. DigiNotar는 네덜란드의 인증 기관(certificate authority, CA)이다.

문제는 DigiNotar가 Root CA 중에 하나라는 것인데, 이것이 왜 문제인지 내가 아는데까지 간단히 설명을 해보면,

우선 공개키 방식에 대해서 이해할 필요가 있다. 공개키 방식은 1977년인가에 Diffie와 Hellman이라는 두 사람이 공식적으로 제안한 것으로 유명하다. 그 이전까지는 하나의 키를 두 사람이 남들 모르게 공유하고 이것을 가지고 암호화 및 복호화를 하는 방식에만 모두가 집중하고 있었다. 그래서 키를 어떻게 몰래 나눠가질 것인가가 주요 이슈였다.

서로 뭔가 비밀 정보를 알고 있다면 그것을 이용해서 암호화해서 키를 보내주면 되는데, 뭔가 비밀 정보를 이미 공유하고 있다면 이미 그 자체가 키가 아닌가! 그래서 예전에는 키를 보낼 때 등기 우편으로 보내거나 사람을 사서 안전하게 전달한다는 내용이 논문이 당연하다는 듯이 기술되어 있다. 하지만 이건 사람이 개입되는 것이니 비용이 높고 속도가 느리다. 네트워크를 통해서 쉽게 할 수는 없을까? 하고 당연한 의문이 생겼을 터.

공개키 방식은 말 그대로 키를 공개할 수 있다는 것인데, 그렇게만 된다면 키를 누가 보게 되더라도(즉, 도청을 당할 위협을 고려하지 않고) 필요한 녀석들에게 던져줄 수가 있다. 하지만 공개된 로또 번호가 의미가 없듯, 남들 다 아는 주식 정보가 의미가 없듯, 키가 공개되는 건 이미 그 자체로 의미가 없다.

그럼에도 불구하고 이런 개념이 나올 수 있었던 것은 키가 하나가 아니라 두개이기 때문이다. Key pair를 만들어서 하나는 비밀로 숨기고 하나를 공개한다. 내부적으로 많은 알고리즘이 있을 수 있지만 다음 규칙을 따르면 공개키 방식에 사용될 수 있다.

(1) 공개키로 암호화한 것은 비밀키로 복호화할 수 있다. 반대로,
(2) 비밀키로 암호화한 것은 공개키로 복호화할 수 있다.

첫 번째 방식을 이용해서 안전하게 데이터를 전달하거나 혹은 비밀키를 전달한다.
두 번째 방식을 이용해서 전자서명을 한다.

이것이 디피와 헬만이 제안한 내용이다. 획기적이고 멋진 아이디어지만 여기서 문제가 하나 있다. 공개키가 말 그대로 공개되기 때문에 다른 녀석이 나를 사칭하여 자신의 공개키를 내 것이라고 다른 사람들에게 거짓말을 할 수 있기 때문이다.

즉, A가 B에게 어떤 비밀 메시지를 보내려고 B의 공개키로 암호화를 한다. 그럼 B는 자신만의 비밀키로 풀어서 그 내용을 볼 수가 있다. B의 공개키는 공개되어 있지만 누구도 비밀키는 모르므로 비밀 메시지를 볼 수가 없다.

이 때, E가 B인척 A를 쉽게 속일 수 있다. A가 B의 공개키가 뭔지 알아볼 때 E가 끼어들어 자신의 공개키를 A에게 알려주면서 "이거 B꺼야." 한다. A는 E의 공개키로 암호화 한다. E는 자신의 비밀키로 풀어서 메시지를 쉽게 읽을 수 있다.

이것 때문에 나온 것이 certificate이다. (인증서 개념은 역시 70년대 말에 MIT의 어떤 학부 학생의 졸업 논문에서 제안되었다고 하는데, 학부생이라니! MIT는 MIT다.) 인증 기관이 있어서 이 공개키는 B의 것이 맞소, 하고 인증해주는거다. E가 이것이 B의 인증서이다하면서 자기 인증서를 A에게 들이 밀어도 A가 인증기관에 알아보면 쉽게 이것이 뻥이라는 것을 알 수 있게 된다.

현재 인증서는 누구든 발행할 수 있고 대신에 chain을 형성하면 된다. Chain을 형성해야 한다는 것 자체가 아무나 발생할 수 없다는 소리가 되긴 하지만... 여튼 누군가가 "이 물건이 믿을만한 것이요."라고 말했을 때 못 믿겠다면 그 사람이 믿을만한 사람인지 또 누군가에게 물어봐야 한다. 이렇게 점점 연결 고리가 형성되는데 이 방식대로라면 최후에 절대 신뢰할 수 있는 누군가가 있어야 한다. 뭐, 정부의 인증! KS 마크! 이런 거라고 보면 될까? 비유가 안 좋았다. 하여튼 이걸 Root CA라고 한다.

이야기가 굽이굽이 많이도 돌았다. 결론적으로 하고 싶은 이야기는 DigiNotar는 root CA라서 여기서 발행된 인증서를 봤을 때 사용자는 믿을 수 있다고 생각한다.

이 인증서가 DigiNotar가 직접 발행한 건지 아니면 누군가가 DigiNotar를 해킹해서 한 건지는 내가 본 기사에서는 누구도 다루지 않았지만 여튼 이 인증서는 유효한 인증서였고 이란에 있는 많은 사용자들이 이 가짜 인증서를 사용했다. 아까 말했듯 인증서에는 공개키가 있고 사람들은 이 조작된 공개키를 암호화에 활용했을 것이다. 적발될 때까지 두 달 정도 사용되었다고 하니 꽤 많은 사람들의 지메일이나 구글독스가 털렸을 수도 있겠다.

여기 위키 페이지가 관련 링크로 넘어가기 좋다.

어떻게 적발되었고, 현재는 어떻게 대처하고 있는지는 다음 번으로 미룬다. 힘들다.

 $ svn checkout svn+ssh://{id}@svn.enlightenment.org/var/svn/e/trunk

예) $ svn checkout svn+ssh://seoz@svn.enlightenment.org/var/svn/e/trunk 

[global]

http-proxy-host = 192.168.1.10

http-proxy-port = 8080