strncpy(des, src, count)을 사용할 때 종종 문제가 되는게 count의 크기다. 가끔 des보다 큰 count를 설정하는 경우가 있는데 많은 프로그램들이 src가 des를 넘치지 않으면 문제가 되지 않겠거니하고 만들어졌다. src에서 ‘\0′을 만나는 순간 더 이상 des에 복제가 이루어지지 않고 특별한 문제가 없을 것이라 생각하는 것.
이 경우 정말 문제가 없을까? strncpy의 경우 src의 ‘\0′을 만나든 말든 count의 개수만큼은 des에 기록해야 한다. src가 끝났느냐 안 끝났냐는 중요한게 아니다. strncpy는 src를 만나서 더 이상 복사할 게 없는 경우 남은 공간을 ‘\0′으로 채워준다. (zero_fill) 이 zero_fill 과정 동안 src의 문자열 길이 - count의 개수만큼 0을 채운다. 즉 strncpy는 최대 이 만큼을 복제하라는 것이 아니고 무조건 n만큼 des에 쓰라는 것이다. 그러니깐 count의 길이를 꼭 유념하자.
많은 사람들이 술만 마시면 살 찌지 않는다고 착각한다. 근거로 이야기하는 것은 공 칼로리(empty calories) 설. 알콜은 공 칼로리고 에너지로만 쓰인다고 주장하는 것이다. 많은 이들이 공 칼로리란 단어에서 느끼는 뉘앙스로 인하여 제로 칼로리의 동의어라고 생각하고 있으며 그렇기 때문에 술만 마시면 살 안찐다라는 루머가 돌아다니는 것이다. (그래서 민간 어원설은 위험하다.) 남의 글을 아무 생각없이 펌질하는 것은 그것을 더 강화시켰고.
골 칼로리(Empty Calories)란 무엇이냐? 열량 많고 영양 없음(high-energy foods with poor nutritional profiles)을 의미한다. 에너지만 많고 영양은 거의 바닥을 치는 저급한 음식들이다. 공 칼로리라는 단어를 보고 유추했던 뜻과는 전혀 다를 것이다. 이런 음식들은 비타민, 미네랄, 아미노 산 등의 유용한 영양은 전혀 포함하지 않지만 칼로리는 무지하게 높은 것이다. 간단히 말해 몸에 나쁜 음식으로 다음과 같다. 캔디, 껌, 음료수, 과당음료, 빵, 흰 쌀밥, 마가린, 쇼트닝유, 버터, 술, 튀김. 공 칼로리 음식이라서 살이 안찐다는 말은 다음의 말들과 동일하다고 볼 수 있다. “난 프라이드 치킨만 먹어서 살이 안쪄요.”
공 칼로리 얘기를 넘어서 술만 이야기 해보자. 공 칼로리가 잘못된 설이지만 술은 알콜이라서 지방이 되지 않는다고 이야기 하는 분들도 계신다. 아마 자신의 간을 장기기증을 하신 분으로 생각된다. 간은 알콜을 아세트 산으로 변환시키고 아세트 산을 에너지나 지방으로 바꾼다. 이건 빈도의 문제지 지방이 안되는 것이 아니다. 신체는 모든 아세트 산을 발열시키지 못한다. 더구나 또 문제점은 간에 순간적인 부담이 늘어난다는 점이다. 신체는 자연적으로 지방을 연소하는데 간이 부담을 느끼면 그 비중을 매우 낮추게 된다. 즉 술은 지방도 되고 지방의 연소도 방해한다. 문제는 그걸로 끝나는게 아니다. 술을 섭취하는 과정에 탄수화물 섭취에 대한 방해는 없다. 즉 술을 마시는 동안 안주의 소비는 그대로 이루어진다. 반면에 알콜은 대사과정에서 탄수화물의 고갈을 유도한다. 간이 포도당 합성을 제대로 못하게 되고 탄수화물을 갈구하게 된다. 다음 날 과식은 필연적.
글이 너무 길어서 정리를 해야할 것 같다. 공 칼로리는 살만 찌는 음식을 말한다. 술은 그 자체가 지방이 될 수 있으며 지방 연소를 방해하며 안주 섭취에는 지장없으며 다음 날 과식을 유발한다. 술과 공 칼로리에 대한 미신은 이제 끝내자.
핵 발전소보다 더 안전하면서 지속적으로 대량의 에너지를 공급하는 발전 방식이 있다면 어떻게 하겠는가? 다른 발전 방식으로 바꾸는 게 합리적이다. 해당 기술이 위험하며 다른 기술로 바꾸었을 때 동등한 가치를 얻을 수 있다면 바꾸어야 한다.
인터넷 뱅킹에서 ActiveX는 위험한 기술인 동시에 다른 기술로 대체가 가능하다. ActiveX가 쓰이는 이유는 크게 세가지인데 부인 방지, 보안 접속, 보안 프로그램의 제공이다. 부인 방지 기능은 본인이 특정 시간에 결제한 것을 증명할 수 있는 일종의 도장이다. 오프라인에서 결제의 부인 방지는 패스워드 입력, 도장, 사인, 지장 등의 다양한 방법으로 이루어진다. OTP는 개인 별로 지급되는 일회용 암호 발급기인데 30초에서 1분마다 새로운 패스워드를 발급해주고 모든 사람은 다른 패스워드를 받게 된다. OTP 정보를 이용하면 30초에서 1분 사이에 본인이 결제했다는 것을 증명할 수 있다. 도장이 위조될 수 있듯 OTP도 위변용될 가능성은 있다. MITM이라는 방법을 통해 훔칠 수 있다. 중간에 누군가 훔치는 것을 막기 위해서 공인 인증이 된 보안 채널이 필요하다. 공인 인증된 SSL 채널에서 OTP 결제 내역을 제공하면 부인 방지가 가능하다.
두번째로 언급되었던 보안 접속 기능은 앞에서 OTP를 위해 설명했던 “공인 인증된 SSL 채널”로 대체가 가능하다. 공인 인증된 HTTPS 채널에서 충분히 다룰 수 있는 문제이다. 이 경우도 MITM에서 안전하다.
세 번째로 언급되었던 보안 프로그램 이야기를 해보자. 보안 프로그램이 동작하기 위해서는 후킹이란 것이 가능해야 한다. 후킹은 특정 운영체제 수준이나 응용 수준의 기능을 가로채어 다른 기능을 하는 것이다. 일반적으로 후킹을 하기 위해서는 높은 수준의 권한이 필요하다. 보안 프로그램이 작동하기 위해서는 후킹이 가능한 수준의 권한이 필수적이다. 권한이 없는 보안 프로그램은 우리의 컴퓨터를 마음대로 뒤져볼 수 없고 악성 프로그램의 흔적을 찾기 힘들다. 악성프로그램도 후킹이 가능한 권한이 필요하다. 사용자의 컴퓨터의 키보드를 가로채거나 화면을 가로채는 것은 특별한 권한이 필요한 것이다. 즉 보안 프로그램이 동작할 수 있는 환경은 악성 프로그램이 동작가능한 환경이다. 높은 권한을 얻기 편리한 장점 때문에 ActiveX 기술 위에 보안 프로그램이 동작하고 있다. 인터넷 뱅킹에서 사용되는 ActiveX 기술로 인해 악성 프로그램이 동작하기 더 쉬워진다.
인터넷 뱅킹에서 ActiveX 기술은 더 이상 필요하지 않다. 다른 방법들이 익숙하고 않아서 당황스러울 수도 있지만 보다 더 안전하게 부인 방지와 보안 접속을 할 수 있는 인터넷 뱅킹법이다.
최근 지인 몇명의 다음 계정이 스팸용으로 쓰인다는 제보를 듣고 나의 다음 계정을 확인했다. 주로 3월 14, 15일 경에 스팸 쪽지 발송용으로 쓰이고 있었고 다음에 의해서 쪽지 발송이 차단당했다. 이미 수백개의 쪽지가 발송이 되었고 피해를 본 사람이 있을 것이다. 그 분들에 대해서는 미안하다.
어떻게 크래킹을 당했지는 방법을 생각해봤다. 일단 키보드 후킹 등에 의한 방법은 아니다. 나는 요즘 자주 공유하는 USB 등의 매체를 불신하고 있으며 따라서 자동실행을 하지 않고 있고 해당 파일이 들어있는지 여부를 확인하며 외산 백신을 수차례 돌리고 있다. 그리고 PC방에서 로컬로 인증정보를 남기지 않는다. 나는 익스플로러를 거의 사용하고 있지 않으며 악성 코드로 부터 상대적으로 안전하다고 본다. 내가 주로 인증을 하는 곳은 내 PC와 노트북, 아르고 휴대폰이다. 외부 컴퓨터에 접속 정보에 의해 해킹당하는 일은 드물 것이다. 나의 지인들도 나와 사용 패턴이 비슷하고 컴퓨터공학/과학의 전공자이며 컴퓨터를 오래 사용했던 사람들이다.
대체 어떻게 이런 크래킹이 가능했을까? 가장 강력한 가능성은 쓰레기 싸이트에 의한 것이 아닌가 싶다. 3월 경에 가입했던 사이트 중에 하나에서 정보가 유출되었을 가능성이 있다. 나는 4-5개의 암호를 쓰지만 포탈에 쓰는 암호는 싸이월드를 제외하고는 거의 동일하며 네이버도 3월 14, 15일 경 스팸 쪽지가 발송된 흔적이 있다. 시기적으로는 다음이 먼저 뚫렸으며 이미 획득한 암호 정보를 네이버에도 이용하여 스팸을 발송한 것으로 보인다.
두 번째 가능성은 다음 혹은 다음의 협력사에서 암호가 누출될 가능성이다. 이 쪽에는 가능성을 크게 열어두고 있지 않다. 다음에서 계정이 뚫려버리는 것은 상상만 해도 끔찍하기 때문이다. 몇일 전에 암호를 변경했는데 이미 차단당한 탓인지 아니면 암호가 변경된 탓인지 전송되고 있지 않았다. 타 사이트에서 노출되었을 가능성이 더 커 보인다.
문제의 재발을 막기 위해 스팸 쪽지를 모두 삭제하고 암호를 만드는 방식을 모든 사이트에서 다르게 변경하였다. 그리고 되도록이면 쓰레기같은 사이트에 가입하지 않을 것이다. 크래킹을 막을 수 있다는 확신이 없는 한 신뢰할 수 있는 사이트 이외에는 로그인을 하지 않을 것이다.
한국에서 태그가 글에 대한 덧붙임으로 쓰이는 경향이 있다. 여기에 대해 국내의 언어적 환경, 인터넷 유저의 학습부족으로 보는 의견도 있었고 여기에 반해 잘못된 UI의 탓이라는 의견도 있다.
나는 태그의 오용(?)이 잘못된 UI나 학습 부족의 탓이라고 보지 않는다. 상당 수 사용자들은 태그가 메타 데이터를 위한 장치인 걸 인지하고 있으며 그럼에도 불구하고 태그를 다른 용도로 사용한다. 초기 미투데이의 인터페이스는 태그를 덧붙임 말을 위해 쓰기에 불편한 인터페이스였다. 인터페이스가 지금보다 더 엄격해서 오히려 메타데이터로 사용하기에 더 적합했던 것. 하지만 사용자들은 태그의 폼을 수차례 정정하면서 구태여 덧붙임 말을 입력했다. 계몽운동이나 UI에 의해 사용자가 태그를 메타데이터로 사용할 가능성은 적다고 본다.
어떤 시스템이든 최초의 설계 의도대로 움직이지 않는 경우가 종종 발생한다. 그럴 경우 설계자들이 할 수 있는 첫번째 선택지는 보안을 위한 제약을 두거나 편의를 제공하여 설계에 맞추어 움직이도록 하는 것이다. 두번째 선택지는 어긋난 설계 대로 움직이는 것을 인정하고 장려하는 것이다.
첫번째 선택으로 문제를 해결할 수도 있지만 두번째 선택이 더 나을 수 있다. 격투게임의 초 필살기와 연속 공격(캔슬 연속기)는 스트리트 파이터 1과 2버전의 버그였다. 게임 설계자들은 초 필살기와 연속 공격의 컨셉을 배제하지 않고 발전시켰고 이 의도하지 않았던 컨셉에 90년대 격투 게임 마니아가 환호했다. 미투데이의 UI는 점점 태그를 덧붙임말로 쓰기 쉽도록 변했고 이게 미투데이의 문화에선 긍정적인 역활을 했다.
원래의 의도를 생각한다면 태그가 메타데이터로 쓰이지 않고 있는 현재 상황이 “쓰레기” 덩어리를 축척하는 것으로 볼 수 있겠지만 사용자와 제작자가 모두 만족하는 현 상황에서 쓰레기라고 말하는게 무슨 의미가 있나 싶다.
JVM 스펙에 따르면 중첩된 클래스는 존재하지 않는다는 것을 알 수 있다. 이상하다. 자바 언어에서는 이너 클래스(Inner Class)란 이름으로 중첩된 클래스를 지원한다.
대체 왜 JVM(Java Virtual Machine)이 지원하지 않으며 자바 컴파일러는 어떻게 이너 클래스를 지원하게 만들었을까? JVM이 지원하지 않는다면 중첩된 컴파일러의 처리는 전적으로 컴파일러의 책임이고 디스컴파일을 하면 자바 컴파일러가 어떻게 했는지 알 수 있다. Lauren양과 OuterClass.java씨가 실험에 참여했다.
cn@Lauren:~/disjava$ cat OuterClass.java
public class OuterClass {
static class InnerClass {
private String innerString = "Inner Hello";
public void sayInnerClass() {
System.out.println("Inner Class rules.");
}
}
public static void main(String args[]) {
System.out.println(”Hello World”);
InnerClass ic = new InnerClass();
ic.sayInnerClass();
System.out.println(ic.innerString);
}
}
OuterClass.java을 컴파일하고 결과물인 OuterClass.class와 OuterClass$InnerClass.class가 나오면 두 파일 모두 javap를 이용하여 디스컴파일한다.
java.lang.Object를 상속받는 두개의 객체 OuterClass와 OuterClass$InnerClass가 존재한다. 즉 OuterClass와 InnerClass는 동일한 높이에 있는 대등한 객체인 것이다. 단지 이름 공간의 오염을 막기 위해 OuterClass$가 접두사로 InnerClass에 붙는 것이 차이다.
또 한가지 차이가 있는데 access$000 메서드가 OuterClass$InnerClass에 위치한다. 이 메서드는 OuterClass의 main 메서드에서 System.out.println(ic.innerString)을 호출의 처리를 위해 JVM이 만들었다.
ic는 InnerClass 객체의 인스턴스. JVM의 입장에서 ic.innerString는 OuterClass$InnerClass의 private 멤버 변수일 뿐이다. InnerClass의 메서드는 OuterClass$InnerClass의 private 멤버 변수에 접근할 수 없다. 자바 컴파일러 입장에서 이너 클래스지만 JVM의 입장에서는 남남인 것이다.
이런 이유로 ic 멤버 변수 innerString을 전달할 방법이 필요하고 자바 컴파일러는 access$000이라는 숨겨진 메서드를 만들어서 해결한다. 이 메서드는 private 멤버 변수인 innerString의 값을 리턴하게 짜여있다.
access$000은 멤버 변수를 외부에서 읽기 위해 자바 컴파일러가 만든 메서드인데 멤버 변수를 외부에서 쓰기 위해 만드는 메서드도 상황에 따라 존재한다. 위의 소스에선 멤버 변수를 외부에서 쓰지 않기 때문에 자바 컴파일러가 불필요한 메서드를 만들지 않은 것이다. 만약 외부에서 멤버 변수에 기록을 한다면 다음과 같음 메서드가 제작된다.
마이크로커널은 1970년대에 나왔는데 운영체제의 핵심기능을 커널 영역에서 사용자 영역으로 옮기는 것이 핵심 아이디어이다. 마이크로커널의 지지자들은 적은 양의 코드만 커널 영역에 담는게 더 간결하고 더 나은 기능성을 얻을 수 있을 것이라 주장한다. 혹자는 미래의 커널은 마이크로커널이 되어야 한다고 이야기했다. 하지만 30년이 지난 지금 마이크로커널은 완전히 실패했다.
마이크로커널의 커널은 결코 간단하지 않았다는 것이다. 사용자 영역에 담은 운영체제의 기능들은 상호간의 소통과 커널 영역에 있는 기능과의 소통이 쉽지 않았다. 그 결과 구조는 복잡해졌으며 의사소통을 의한 IPC 비용이 증가되었다. 커널은 여전히 만들기 어려웠으며 심각하게 느렸다. 산업에서 가장 유명했던 매크(Mach) 커널도 역시 느리고 복잡했으며 GNU의 허드(Hurd)는 처참한 실패를 했다.
Jochen Liedtke. 영어로 표기하기 싫지만 이 사람을 어떻게 읽어야 할지 난감한 Jochen Liedtke는 기존의 마이크로커널이 잘못 구현되어 있기에 느렸다고 주장하며 마이크로커널이 빠르다는 것을 증명하기 위해 L3, L4 커널을 개발했다. 핵심적인 아이디어는 이식성과 안정성을 다소 포기하며 IPC의 성능에 집중한 것이다. 마이크로커널의 가장 큰 단점으로 지적되었던 성능문제만 신경 쓴 것이다. 이 커널의 문제점은 이식성과 안정성이다. 여러가지 기교를 사용하면 모노리딕 커널 역시 해당 플랫폼에서 더 나은 성능을 보일 수 있다. 이식성과 안정성을 희생하면서 범용 운영체제를 만드는 것이 좋은 선택이냐는 의문이 남는다. 이 커널은 퀄컴이 주로 밀었는데 퀄컴의 쇠퇴와 함께 쇠퇴하고 있다.
흔히 매크 마이크로커널은 그래도 살아남아 맥의 운영체제 Mac OS X에서 잘 작동되고 있지 않느냐고 주장한다. 이것은 사실이 아니다. 매크 “마이크로커널”은 거의 죽었고 맥의 운영체제에 쓰이는 커널은 이 커널이 기초가 된 XNU(XNU is Not Unix) 커널이다. 매크 마이크로커널이 기반이 되었으면 마이크로커널이 아니냐고 생각할 수 있다. 하지만 XNU의 핵심은 운영체제의 핵심 기능을 커널 영역에 삽입하여 성능을 향상시키는 것에 있고 이 아이디어는 마이크로커널과 상충되는 것이다. XNU는 BSD의 코드를 커널 영역에 삽입하였다. XNU는 이전에 마이크로커널 연구자들이 뚱뚱한 커널(fat-kernel)로 비난하던 모노리딕 커널이고 좋게 봐주어도 (모노리딕과 마이크로커널이 섞여 있다는) 하이브리드 커널이라 이야기할 수 있다.
Hani님이 적은 원고지 10장을 쓰는 힘을 통해 이런 책이 있다는 것을 알았다. 처음 제목을 접했을 때 왜 이렇게 낡았지란 생각을 가졌다. 지금 10대, 20대 중에 원고지에 큰 의미를 두는 이가 얼마나 될까? 낡은 냄새가 나는 제목 탓에 낡은 책이라는 생각이 들어 흥미가 없었다. 원고지 쓰는 법이 꽤 많은 분량을 차지하지 않을까 하는 생각도 들었다. 어쨌든 매력적인 책은 아니었다. 우연히 도서관에 들렸다 책을 발견하고는 냉큼 집었다. 제목은 맘에 안들었지만 한번 보았던 제목이었기에 눈이 갔고 얇아서 손에 잡혔다. 처음 예상과는 전혀 다른 책이다.
10km 달리기를 연습하려는 사람이 처음부터 10km를 뛸 수 없다. 짧은 거리를 달려서 연습한 이후에 10km를 달릴 수 있다. 마찬가지로 긴 글을 쓰려는 사람은 짧은 글 부터 써야 긴 글을 쓸 수 있다는 거다. 물론 100m 달리기와 같은 단거리 달리기만 연습해서는 장거리 달리기에 부적합할 것이다. 글 쓰기도 마찬가지다. 마이크로블로그만 쓰면 긴글을 잘 쓸리가 없는 것이다. (미투데이를 인용해서 미안하지만 조금이나마 트래픽이 늘어날테니 Win-Win이다.) 사이토 다카시는 이 적당히 짧은 글의 기준을 원고지 10장이라고 정했고 이 분량은 A4 2장쯤 되나 보다. 나라면 이 책의 제목을 “A4 2장을 쓰는 힘”이라고 지었을 것 같다. 계속 책 제목에 대한 불만만 말하게 된다. 일단 이 정도 분량을 연습하다 보면 글 쓰기에 대한 자신이 생기며 질도 좋아지게 된다.
글쓴이는 A4 2장을 채우기 위해서 키워드를 중심으로 글감을 모은 후 3개의 꼭지점에 배열시켰다. 3개의 꼭지점이 적당한 거리를 가질 수록 균형이 있으면서 매력적인 글이 된다. 3개의 꼭지점간의 거리 때문에 단조로움에서 벗어날 수 있고 3개 정도니 지나치게 난잡해지지도 않아 3개 정도로 제약했다. 키워드에 대해 3가지의 컨셉을 정해두는 것을 훈련하기 위해 독서 감성문을 적을 때도 세 개의 요점을 지적하는 훈련을 제안한다.
글의 구성에 대해 설명한 이후에는 문체에 대해서 이야기를 한다. 자신의 포지션을 이해하는데 중점을 맞추고 있다. 글쓴이의 포지션이 어떻게 되느냐에 따라 글의 구성과 문체가 바뀔 수 밖에 없다는 것이다. 그런 포지션을 이해하고 주관과 객관 사이의 균형을 잡으면서 글을 적으면 독창적이고 생명력있는 문체가 될 수 있다고 한다. 이 장은 조금 건성으로 쓰여진 느낌이 든다. 아직 글을 많이 써보지 않은 입장에서 포지션만 고려해서 긴글을 쓰기엔 부담이 된다. 평범하지만 구체적인 이야기를 더 다루어 봤으면 하는 아쉬움이 있다.
최근에 경제 위기에 대해 사람들은 과도한 파생상품의 문제라고 지적한다. 하지만 이런 주장은 올바르지 않다. 경제위기는 사람이 만든 것이다.
파생상품 때문에 경제 위기가 왔다는 것은 말이 되지 않는다. 파생 상품은 우리의 물류와 경제를 더 효과적으로 만들어 주었고 우리가 이렇게 풍요롭게 살게 되었다. 파생 상품이 위험했다면 파생 상품의 결함 때문에 우리는 수 많은 위기를 지난 수백년간 경험했어야 했다.
서브프라임 대출, 신용부도스와프를 사용해서 위기가 온 것은 위험관리가 잘못되었기 때문이다. 모든 투자에 이익과 손실이 있기 마련이다. 그것을 어느정도의 선에서 맞출 것인지는 사람이 결정하는 것이다. 서브프라임 대출과 신용부도스와프가 감당하지 못할 위험을 감수하게 한 것은 사람이다.
칼은 우리가 사용하는 손에 비해서 훨씬 효과적으로 사용할 수 있지만 위험은 존재한다. 칼을 얼만큼 효과적으로 사용할지 얼마만큼 위험을 감당할지는 사람이 결정하는 것이다.
경제위기는 어떤 체제나 도구의 문제가 아니라 사람의 문제다. 잘못된 판단과 결정을 하지 않도록 교육을 강화하고 잘못된 결정을 빨리 발견하고 수정되도록 해야 한다.