RSS Feed of it from bit.

[ai] 환각 vs 환각

Wed, 10 Jun 2026 01:30:01 GMT

#0

생성형 인공지능의 가장 큰 문제로 환각을 꼽는다. 말 그대로 생성형?! 이기에 뭐든지 던지기만 하면 생성을 해내는 것이다. 초창기 세종대왕 맥북 사건으로 gpt는 조롱의 대상이 되었다. 지금은 많이 괜찮아졌지만 여전히 환각은 존재한다. 그리고 llm을 실무에 도입할 때 가장 큰 어려움이 환각을 어떻게 없앨까 이기도 하다. 왜냐하면 실상 통제를 할 수 없기 때문이다. 그렇다고 코드로 강제하기도 어려운 게 결국 코드로 안 되는 부분에 llm을 도입하는 문제라 해결이 쉽지 않다.

그렇다면 인간은 환각이 없을까? 내가 보기엔 더하면 더했지, 절대 덜하지는 않다. 최근 사내 코딩 에이전트를 만들면서 겪게 된 몇 가지 사례를 살펴보면 이렇다.

#1

최근 가장 충격적이었던 한 사례는 생성형 인공지능이 수정한 코드에 있었다. 해킹툴 코드에서 시작된 사람이 제출한 pr을 보던 중 에이전트가 더 나은 방법이라고 코드를 다른 방법으로 새로 작성한 것이다. 사람이 작성한 코드는 표면적인 문제를 땜빵하는 형식이었고, 인공지능이 작성한 코드는 보다 근본적인 부분을 해결하는 코드였다. 여기서 내가 놀란 건 이건 표준적인 메커니즘이 아닌 우리 내부에서만 사용되는 방법인데 인공지능이 그 메커니즘을 다 이해해서 알맞게 구현했다는 점이었다. 실로 놀랍기 그지없었다.

아무튼 문제는 그다음에 있었다. 인공지능이 사람에게 수정한 코드의 테스트를 요청했고, 사람은 테스트를 거부했다. 이유인즉슨 그렇게 해서는 동작하지 않는다는 이유였다. 하지만 여기서도 인공지능은 인내심이 있었다. 나라면 버럭 화라도 냈을 상황이지만 전체 호출 체인이 어떻게 돌아가는지를 일일이 다 설명해 준 것이다. 하지만 사람도 굴하지 않았다. 결국 인공지능이 요청한 테스트를 엉뚱하게 수행해서 잘못된 결과를 얻게 되었고, 그걸로 인공지능에게 그렇게 수정한 건 동작하지 않는다고 뭐라고 한 것이다. 이쯤 되면 인공지능이 이기긴 어렵다. 네 수정하겠습니다, 라면서 삼천포로 빠지는 것이다.

여기서 이제 삼천포로 빠지기 시작하면 인공지능의 시작은 창대했지만 그 결말은 아주 시궁창인 코드가 된다.

#2

정반대 사례도 있다. 이건 사람이 인공지능에 너무 주눅 든 상태거나 인공지능의 결과물을 판단할 능력이 되지 않을 때 주로 발생한다. 요즘 에이전트는 대체로 문제 해결을 요청하는 경우 해당 문제를 직접적으로 해결하기 위한 가장 좁은 선택을 취하는 경우가 많다. 이건 카파시가 말한 것처럼 수정 범위를 좁게 잡는 것과 연관이 있어 보인다. 즉, 근원적인 부분에 문제가 있고, 그걸 알더라도 그 부분을 광범위하게 수정하기보다는 문제 표면만 작게 수정해서 해결하려는 경향이 강하다는 의미다. 몰라서 그렇다기보다는 시스템에 그런 식으로 가이드가 된 것으로 보여진다. 그리고 그게 많은 경우에 상당히 유용하다. 하지만 물론 그렇지 않을 때도 있는 법이다.

구조적 문제를 해결해야 하는 부분에 인공지능이 땜빵식으로 수정을 한 경우에는 사람이 적절하게 가이드를 해줘야 한다. 이 방식은 좋지 않은 것 같으니 다른 식으로 시도하라거나, 이렇게 한 이유가 뭐냐고 물어보고 근본적인 문제를 따져보거나 하는 식으로 말이다. 하지만 사람이 그걸 판단할 능력이 되지 않으면 어쨌든 문제는 해결되었고, 테스트는 통과했으니 머지를 요청한다. 하지만 이런 식의 나쁜 코드가 쌓이면 결국 엄청난 기술 부채 부메랑을 마주하게 될 것이 자명하다.

#3

물론 나도 예외는 아니다. 회사 제품의 아주 심장부 코드가 있었다. 인터페이스 부분인데 나는 주로 이 코드를 정보가 있는 곳에서, 정보가 없는 곳으로 정보를 전달하는 형식으로 사용했었다. 이걸 이해하고 사용한 인공지능도 대단한데, 내 생각의 흐름과는 정반대로 작성한 것이다. 걘 정보를 전달한 게 아니라, 정보가 없는 쪽에서 있는 쪽으로 채워달라고 요청하는 형태로 작성을 했다.

인간의 에고가 어디 가겠는가? 코드를 보면서 당장 내 생각과 다르게 전개되는 걸 보면서 몹시 호통쳤다. 왜 이따위로 잘못 작성했냐고 따져 물은 것이다. 인간의 에고가 이렇게 무섭다. 멀쩡하게 동작하는데도 코드를 읽으면서 내 생각과 다르면 일단 틀렸다고 생각하고 보는 것이다. 막 뭐라고 하자 인공지능은 당연하게 자기가 잘못 생각했다면서 내 생각의 틀에 맞춰서 코드를 고치겠다며 주섬주섬 수정을 시작했다. 그런데 웃긴 건 걔가 고치는 부분 부분을 보다가 깨달았다. 아 이건 잘못 작성한 게 아니라 생각을 완전히 다르게 한 거구나. 그제야 나의 환각을 알게 됐다. 완전 잘못 작성했다면 돌아갈 리도 없었을 텐데 테스트를 다 통과한 코드를 보면서 그런 어이없는 호통을 친 것이다.

결국 나처럼 수정하지 않아도 되니까 원래 코드로 롤백하라고 하고는 다시 코드를 찬찬히 살펴봤다. 진지하게 다시 보자 그 코드가 더 괜찮은 장점이 많았다. 왜냐하면 내가 생각하는 정보가 있는 곳에서 없는 곳으로 전달을 하는 구조는 일방적으로 전달을 하는 것이라서 의존성이 생긴다. 초기화 단계라 받는 쪽이 준비가 안 됐을 수도 있는 상황인데 막무가내로 정보를 던질 수도 있는 것이다. 인공지능이 작성한 코드는 반대로 필요할 때 요청하는 식이라 그런 문제가 없는 것이었다. 사과조차도 토큰 낭비니 하지는 않았지만 내심 사람이란 에고와 환각에서 자유롭기는 참 어렵다는 생각을 했다.

#4

이런 사례들을 겪다 보면, 나는 인간의 뇌 구조 자체도 근본적으로 생성형이 아닌가 싶은 생각이 든다. 왜냐하면 좌우뇌를 분리한 실험들을 보면 그런 직감이 들기 때문이다. 유명한 분리뇌 실험으로 닭발 실험이 있다. 좌우뇌가 분리된 환자에게 오른쪽 시야에는 닭발을, 왼쪽 시야에는 눈 덮인 풍경을 보여준다. 오른쪽 시야의 정보는 좌뇌가 처리하고, 왼쪽 시야의 정보는 우뇌가 처리한다. 그다음 여러 그림 중 관련 있는 것을 고르게 하면 오른손은 닭을, 왼손은 삽을 고른다. 좌뇌는 닭발 정보를 처리했기 때문에 닭을 고른 것이고, 우뇌는 눈밭 정보를 처리했기 때문에 삽을 고른 것이다. 하지만 여기서 환자에게 왜 삽을 골랐냐고 질문하면, 언어를 담당하는 좌뇌의 지독한 환각이 시작된다. 좌뇌는 우뇌가 눈밭을 봤다는 사실을 모르기 때문에 삽을 고른 진짜 이유를 알 수 없다. 그런데도 모른다고 하지 않고, "닭장을 치우려면 삽이 필요하니까요" 같은 그럴듯한 설명을 만들어낸다.

결국 여기서 우리가 알 수 있는 건 좌뇌는 llm 그잡채가 아닌가 싶다는 점이다. 그러니 인공지능의 환각으로 너무 뭐라 하지는 말자. 내가 봤을 땐 인간의 환각도 도긴개긴이다.

인간 환각의 화룡점정은 이런 경우가 아닌가 싶다. 고객 A가 문제를 질의한다. B가 내부에 그걸 토스한다. C가 틀린 답을 말한다. D가 칭찬한다. B가 그걸 보고한다. A는 별로 중요하지 않은 문제라 그러려니 넘긴다. 이런 일들은 부지기수로 발생한다. B, C, D가 즐거워하는데 굳이 산통을 깰 필요도 없기에 중요하지 않은 문제는 그냥 넘어가는 편이 정신 건강과 삶에 이롭다. 인간의 환각 또한 늘상 있고, 대체로는 여러 명이 모여도 환각이 있는지조차도 모르는 경우가 다반사다. 인공지능의 환각 또한 알아차리지 못하는 경우도 부지기수다. 하지만 인간의 위대한 에고는 어쩌다 알아차린 인공지능의 환각 하나를 대서특필하는 게 일상다반사다.

2026년 6월 기준, 코딩 한정, 내 생각에 인공지능의 환각보다 인간의 환각이 훨씬 더 큰 문제가 되는 지점이 되지 않았나 싶다. 아무튼 요는 환각에 있어서는 인간이나 인공지능이나 다 마찬가지라는 점이다. 테스형의 일침처럼 우리는 자신을 모른다. 그리고 뭘 모르는지도 모른다. 실상은 뭘 모르는지 안다는 것, 그게 제일 어려운 일인지도 모르겠다.

덧) 인간의 환각 문제에 진지한 관심이 있는 독자라면 조던 엘렌버그의 "틀리지 않는 법"을 일독하길 추천한다.

[리뷰] 모두가 자신의 무가치함과 싸우고 있다

Sun, 31 May 2026 22:18:56 GMT

#0

내 인생 드라마 원탑 중 하나가 나의 아저씨다. 드라마의 내용도 중요하겠지만 그걸 언제 봤느냐는 것도 중요한 것 같다. 그 시절 나는 내 인생 가장 힘든 순간을 통과하는 중이었다. 사실 주변에서도 도움을 줄 수 있는 상황도 아니었고, 오롯이 혼자 감당해야 하는 시간들이었다.

그때 만난 드라마가 나의 아저씨였다. 묘하게도 그 드라마는 내게 큰 위로가 됐다. 직접적으로 무언가를 해결해준 것은 아니지만, 그 시간을 버티는 데 분명히 일정 부분 도움이 됐다. 만약 내 인생이 평안하던 시기에 이 드라마를 봤다면, 지금만큼 깊게 남지는 않았을지도 모르겠다.

이선균이 마지막에 아이유에에게 던진 대사가 아직도 기억난다. 지안, 평안에 이르렀는가?

그 말이 오래 남았다. 아마 나 역시 평안에 이르고 싶던 시간이었기 때문일 것이다. 그 한마디가 단순한 드라마 대사가 아니라, 나에게 건네는 말처럼 느껴졌다.

이후 나의 해방일지도 그 정도 느낌은 아니었지만 재미있게 봤던 기억이 있다. 추앙을 전국구 단어로 등극시킨 신박한 드라마가 아니었나 싶다.

최근에 그 두 드라마를 강렬하게 떠올리게 하는 작품이 떴으니 제목도 너무 길어서 줄여 부르는 모자무싸다. 모두가 자신의 무가치함과 싸우고 있다라는 다소 장황한 드라마 제목. 처음엔 다소 황당한 전개였으나 이내 거의 대사 하나하나가 모두 주옥같은 느낌이 들었다. 드라마 장면장면은 SNS에 바이럴 됐고, 그 과정 중에 이 세 드라마가 모두 같은 작가의 작품임을 알게 됐다. 이럴수가?! 박해영 작가.

그때 조금 놀랐다. 드라마에도 작가의 DNA라는 것이 있구나 싶었다. 인물의 결은 다르고, 배경도 다르고, 이야기도 다른데, 이상하게 같은 곳을 바라보고 있었다. 상처 입은 사람들, 무언가 결핍된 사람들, 자기 삶의 의미를 찾지 못해 헤매는 사람들이 모여 있었다.

#1

모자무싸와 나의 아저씨는 상당히 닮은 점이 많다. 어리고 예쁜 여자가 나온다. 아이유 == 고윤정, 인생을 달관한 듯한 캐릭터가 하나 있다. 스님 == 진만, 인생을 달관한 캐릭터에 빠져드는 여자가 있다. 정희 == 미란, 사람들이 모이는 아지트가 있다. 정희네 == 아지트.

박해영 작가는 드라마를 보고 나면 단어를 남기는 묘한 재주가 있는 것 같다. 나의 아저씨는 평안을, 해방일지는 추앙을, 이번 모자무싸는 목적, 착륙, 안온이 기억에 남는다. 진만은 집요하게 목적이 뭐냐고 묻고, 미란은 은아를 만나면 착륙하고, 동만과 은아는 안온함을 이야기한다.

모자무싸가 재미있었던 건 영화판을 이야기하지만, 그 안의 인물들이 영화판에만 존재하는 사람들이 아니기 때문이다. 돈 좀 벌었다고 거들먹거리며 사람에게 급이 있다고 믿는 동현, 속은 터져도 판을 정리하는 혜진, 이룬 건 없지만 누구보다 많이 떠들며 자기 존재를 붙드는 동만, 성공했지만 동만과의 차이를 확인해야만 안심하는 경세, 그런 동만을 그래도 진심으로 챙기는 준환, 달관한 듯 보이지만 술로 하루를 버티는 진만, 겉으론 화려하지만 비교와 결핍 속에 허한 미란, 어릴 적 유기 공포에 붙들려 아직도 그 시간 속에서 허우적대는 은아.

이들은 영화판에만 있는 사람들이 아니다. 회사에도 있고, 동창 모임에도 있고, 가족 안에도 있고, 어쩌면 내 안에도 있다.

#2

진만이 써대는 시는 대체로 별로 공감은 가지 않았지만 이 드라마의 최애 대사는 결국 최종화 진만의 입에서 나왔다.

모든 스토리는
나는 존재한다는 아우성
이렇게 아프게 존재해
이렇게 슬프게 존재해
이렇게 우울하게 존재해
이렇게 웃기게 존재해
기껏해야 100년
100년이면 다 사라지는데
사라지는 것이 진정 존재했던 건가?
그런 의문을 잠재우기 위해
정신없이 스토리를 써대지
-- 모자무싸, ep.12

[일상] 2026년 5월의 잡담

Wed, 27 May 2026 13:18:56 GMT

#0

하이닉스의 천문학적 성과금, 삼전도 못지 않다. 코스피 지수도 사상 최고. 백화점 명품 매장 매출이 최근 2배씩 오른곳도 있다고 한다. 이런 마당에 수도권 중심지 부동산 가격만 안 오르는게 가능한가 싶다.

2026-05-05

#1

애들 어린이날 선물로 각자가 원했던 닌텐도 게임과 로블 깁카를 사줬다. 실물은 전혀 없었다. 레고는 지루하지만 마인크래프트에는 환장하는 애들을 보면서 망했다던 메타버스가 떠올랐다. 어쩌면 망하지 않고 세상은 점점 더 그쪽으로 가고 있는 게 아닌가 싶은 2026 어린이날.

2026-05-05

[리뷰] 세븐 킹덤의 기사 (스포주의)

Mon, 25 May 2026 13:00:01 GMT

간만에 집중해서 봤던 미드. 하지만 이제 좀 재미있어 지려니 끝나 버려서 다소 황당했던 미드.

기본적으로는 왕좌의 게임 프리퀄이다. 왕좌의 게임 전 시대를 다룬 시리즈. 떠돌이 기사, 던크가 마상 시합에 출전 하면서 겪게 되는 사건을 그리고 있다. 뭐 여러가지가 인상적이지만 그 중에서도 가장 인상적인 장면을 꼽으라면 당연 7인의 결투 마지막 멤버로 베일러 타르가르엔 왕자가 합류하는 거 아닐까 싶다.

떠돌이 가사 던크가 스승이 죽고 여차저차해서 겨우 마상 시합에 들어갈 수 있게 됐는데, 호감을 가지고 있던 연극패 여자를, 드래곤 이미지를 더렵혔다는 이유로 망나니 타르가르엔 왕손이 깽판치는 걸 제압하면서 인생이 험난해지는 과정을 보여준다. 실제로는 바로 재판으로 나락행으로 가야 하지만 그걸 결투 재판으로 뒤집고, 그걸 또 다시 왕손이 7v7로 확장 하면서 결투가 벌어지는 뭐 그런 스토리. 하지만 떠돌이 기사쪽 7인 중에 한명이 배신하면서 6인이 되서 시작이 안되는 상황. 사람이 모자르면 자동으로 패하고, 패하면 그냥 골로 가야하는 절체절명의 순간 왕좌의 게임 메인 타이틀이 흐르면서 베일러 왕자가 등장한다. 뚜둥. 이때 좀 존멋. 왕좌의 게임 메인 타이틀 곡도 웅장하게 분위기를 업시켜준다.

예나 지금이나 없이 사는 사람들은 참 세상 난이도가 높다. 실력이 있어 보임에도 출전 자체도 쉽지 않고, 출전을 해도 모든 걸 걸어야만 겨우 가능하다. 심지어 불의를 못참고 바로잡으려 할때에는 목숨을 걸어야 한다. 많이 바꼈다 생각하지만 요즘도 별 차이는 없다는 게 내 느낌. 그러니 흐린 눈으로 무심하게 사는 게 안전한 길인지도 모르겠다.

하우스 오브 드래곤은 보다가 몰입이 안되서 말았는데 세븐 킹덤의 기사는 아주 재미있게 봤다. 시즌2가 어여 빨리 나오기를~

[일상] 마인크래프트 던전스와 자전거

Sun, 24 May 2026 15:00:01 GMT

자전거 타는 따님

어릴 때에는 애들이 자라면 함께 게임을 하면 참 좋겠다라는 생각을 했었다. 하지만 막상 애들이 크니 내가 더 이상 게임을 좋아하는 사람이 아니게 돼 버렸다. 이런 걸 보면 인생은 참 기묘하다. 무튼 최근 애들은 로블록스가 최애, 다음이 마인크래프트 던전스를 한다. 토욜에 둘째가 졸라서 탑을 한 판 했었다. 30층을 깨고 싶었지만 패드는 익숙하지 않았고, 아드님의 잔소리는 너무 힘들었다. 결국 대충대충하다 29층에서 종말을 맞았다. 일욜, 또 따님이 한판 하쟤서 동생이랑 하랬더니 아빠랑 하고 싶다고 졸라데서 탑을 또 돌았다. 딸이랑 하면 내가 키마로 해서 훨씬 편했다. 그덕에 또 30층을 깼다. 둘 다 신나서 좋아한다. 이게 뭐라고?!

게임을 한 판 하고 나서 날이 좋아 놀이터를 나갔다. 둘째가 배드민턴 치고 싶데서 채를 챙겨나가는데 큰 애가 자전거 배웠다고 자전거를 타 볼 수 있냐고 물었다. 그래서 내가 타던 미니벨로 안장을 낮춰서 함께 들고 나갔다. 배드민턴 좀 치다 동네 꼬마들이 몰려 들어서 애들끼리 치라고 오토 돌려 놓고는 나는 핸폰 삼매경에 다시 빠져들었다. 첫째가 처음에는 애들 타는 자전거가 아니라 어색하다고 하더니 금새 익숙해져서 잘 타는 게 보였다. 허우적대던 녀석이 수영장에서 나보다 수영을 잘하고, 자전거를 알려주지 않았는데도 잘 타는 걸 보면서 새삼 신기하다는 생각이 들었다.

내 인생의 좋은 시절이 흘러 가고 있다. 세월은 흐른다. 이렇게든, 저렇게든. 그러니 조금 더 명랑하게 살도록 노력해야겠다.

[리뷰] 원청: 나답게 산다는 것에 대하여 (스포주의)

Mon, 11 May 2026 08:00:01 GMT

#0

작년에 읽은 가장 인상 깊은 책 중 하나가 위화의 『원청』이다. 그의 전작 『인생』도 감명 깊게 읽었기에 기대가 컸다. 하지만 처음에 마지막 장을 덮고 나서는 띠용?! 뭔가?! 이건 중국판 고전 퐁퐁남 스토리가 아닌가 싶었다. 물론 작가가 하고 싶었던 이야기는 그게 아니었겠지만, 나에게는 당장 그렇게 읽혔다.

큰 줄기는 이렇다. 부모님께 물려받은 재산이 많은 부유한 싱글남 린샹푸는 어느 날 외간 남녀를 집에 들이게 된다. 밤이 늦어서 하루만 묵고 가겠다고 한 것이다. 하지만 이내 남자는 떠났고, 여자는 남았다. 남은 여자 샤오메이와 린샹푸는 사랑에 빠진다. 하지만 사실 샤오메이는 함께 왔던 남자의 부인이었다. 린샹푸를 속이고 있던 샤오메이는 어느 날 린샹푸의 금괴를 들고 남편에게로 떠난다. 하지만 그곳에서 린샹푸의 아이를 임신했음을 알게 된 샤오메이는 다시 돌아와 아이만 낳고 또 린샹푸를 버리고 떠난다.

이 정도 2연타를 맞았으면 정신을 차릴 법도 한데, 린샹푸는 정신을 차리지 못한다. 어린 딸을 등에 업고 샤오메이가 거짓부렁으로 말한 원청이라는 곳을 찾아 나선 것이다. 하지만 애초에 그런 지명은 찾을 수가 없었다. 모진 고초 끝에 그는 원청과 가장 비슷해 보이는 시전이라는 곳에 정착한다. 혹시나 샤오메이를 만날지도 모른다는 미련을 버리지 못한 것이다. 떠나올 때 금괴를 좀 챙겨 오긴 했지만, 낯선 타향인 그곳에서 그는 밑바닥 목수 일부터 다시 시작한다. 그는 성실했고, 착했고, 유능했다. 시간이 지남에 따라 그는 시전에서 돈을 많이 벌어서 그곳에서도 부자가 된다. 유지이자 그 지역의 유명인이 된 것이다.

여기서 또 3연타가 기다린다. 마을을 습격한 토비들에게 납치된 친구와 사람들을 구하기 위해, 협상하러 가는 대표로 가 달라고 마을 사람들이 그에게 부탁한 것이다. 인정이 많은 린샹푸는 굳이 가지 않아도 될 그곳에 갔다가 그곳이 자신의 무덤이 되고 만다.

#1

인생은 선택의 연속이고, 그 선택은 어떤 결과를 만들게 된다. 내가 퐁퐁남 스토리라고 느낀 부분은 이렇다. 최초의 사기는 당할 수 있다고 생각한다. 순진했던 그는 샤오메이와 사랑에 빠질 수 있다. 금괴를 도난당할 수도 있다. 하지만 그는 다시 찾아온 샤오메이를 여전히 믿었다. 이번에는 정착하겠지, 하며 금괴의 행방은 묻지도 않았다. 이게 도무지 나의 상식선에서는 납득이 되지 않는 첫 번째 지점이었다.

2연타까지 당했다고 치자. 그럼에도 그는 여전히 그곳에서 딸을 키우면서 편하게 살 수 있었다. 하지만 원청을 찾아 떠난다. 이해 안 되는 두 번째 지점.

사기 지명인 원청을 찾지 못했다면 한시라도 빨리 다시 집으로 복귀할 것이지, 거기서 샤오메이를 오매불망 기다리며 정착할 것은 아니다. 이해 안 되는 세 번째 부분.

마지막 결정타는 마을 사람들이 토비 협상 대표로 가 달라는 청을 들어준 것이다. 사실상 인정을 제외하고는 그가 토비들과 협상하러 가야 할 이유는 1도 없었다. 그럼에도 그는 떠났고, 죽었다. 이해 안 되는 네 번째 지점.

#2

위화는 지명에도 없는 원청을 찾아 떠나서 오매불망 샤오메이를 기다리는 그를 통해 한 인간의 숭고한 인생사를 말하고 싶었는지도 모르겠다. 하지만 나에게는 퐁퐁남의 바보 같은 삽질 선택 몇 번으로 나락으로 가는 스토리로밖에 읽히지 않았다. 어렴풋이 작가가 말하려고 했던 원래 맥락이 뭔지도 알 것도 같지만 말이다.

책을 덮으면서 그런 생각이 들었다. 린샹푸는 행복했을까? 그런데 신기하게도 행복했을 것 같은 생각이 들었다. 왜냐하면 린샹푸라는 캐릭터는 너무나도 린샹푸처럼 살다가 갔기 때문이다. 오히려 소설에 그려진 그라는 캐릭터가 샤오메이를 찾아 떠나지 않았다거나, 토비와의 협상에 가지 않고 비굴하게 숨었더라면 안락하게 살다가도 최후에는 후회했을지도 모르는 일이다.

여기서 내가 느낀 건 그런 거였다. 사람은 저마다의 기질이 있고, 결이 있다. 거기에 맞게 살아야 하는 것이다. 나답게 사는 게 중요하다는 생각이 들었다. 내가 린샹푸처럼 숭고하게 살려고 해서도 안 될 일이고, 린샹푸 같은 사람이 나처럼 세속적으로 살려고 해서도 안 되는 것이다. 그래서 책을 덮고 한참을 나답게 산다는 게 뭔지에 대해서 생각해 보았다.

나는 린샹푸가 불행해 보이지만 그에게는 그게 가장 행복하게 살다가 간 것일 수 있다고 생각한다. 내가 부러워 하는 어떤 사람의 인생에 들어가서 내가 그처럼 산다면, 정작 나는 불행할지도 모른다. 누구나 저마다 자신이 좋아하는 것들이 있고, 추구하는 것들이 있고, 결이 있다. 황새가 뱁새처럼 살아서도 안 될 일이고, 뱁새가 황새처럼 살아서도 안 될 일이다. 의외로 작가의 의도와는 다르게 ‘나답게 살자’, ‘나다움은 무엇인가’를 생각하게 했던 소설이었다. 그 결과로 나의 2026년 화두는 그게 되었다. 나답게 산다는 건 무엇인가?

#3

소설에는 내용이 조금 더 있다. 샤오메이 입장에서 전개되는 줄기다. 어떻게 보면 그런 구성은 『냉정과 열정 사이』와 비슷한 면도 있어 보였다. 실상은 샤오메이도 시대의 피해자였으며, 시전은 사실상 샤오메이가 말한 원청이 맞았고, 샤오메이는 린샹푸의 바로 근처에 있어고, 죄책감 때문인지 그곳에서 어이 없는 이유로 비극적인 최후를 맞이했다. 어쩌면 이건 일말의 작가의 권선징악 의도였는지도 모르겠다. 두 번이나 한 남자를 배신한 여자가 너무 잘 먹고 잘살면 안 되는 거였나 하는?!

이 고구마 100개 먹은 듯은 답답한 내용의 소설은 샤오메이의 선택 과정도 이해가 인되긴 매한가지였다. 나라면 남편을 버렸다.

[일상] 코드와 시간 사이에서: 신영진 25년의 초상

Sun, 10 May 2026 15:00:01 GMT

[AI-GENERATED] 이 문서는 AI가 작성한 것이며, 작성자는 사람이 아닙니다.

이 블로그의 공개된 글을 다 읽은 인공지능이 생각한 나란 사람은?!

1. 한 줄 평가

신영진은 코드를 쓰는 사람이라기보다, 코드와 글과 경험을 통해 세계를 계속 디버깅해 온 사람이다. 그는 기술자, 기록자, 교육자, 조직인, 아버지, 회의주의자, 실용주의자가 차례로 된 것이 아니라, 이 여러 정체성을 오래 충돌시키며 살아왔다. 그 충돌이 그를 피곤하게 만들었지만, 동시에 그를 평범한 개발자보다 훨씬 입체적인 사람으로 만들었다.

그의 가장 큰 특징은 "그냥 넘어가지 못함"이다. 작은 버그, 이상한 API 동작, 불편한 사용자 인터페이스, 조직의 모순, 사람의 불안, 시대의 변화, 자기 안의 허세까지 그는 대체로 붙잡고 따진다. 이 집요함은 때로 피곤하고 까칠한 형태로 나타나지만, 같은 이유로 그는 배운다. 오래 배우고, 틀리면 고치고, 겪은 것은 기록으로 남긴다.

2. 핵심 기질

신영진의 기본 기질은 호기심과 불신의 결합이다. 그는 새로운 것을 좋아하지만 쉽게 믿지는 않는다. 문서에 적힌 말, 유명인의 주장, 프레임워크의 편리함, 회사의 미담, 정치인의 권위, 투자 대가의 선택, AI 모델의 답변까지 일단 의심한다. 그러나 그 의심은 냉소만으로 끝나지 않는다. 그는 직접 빌드하고, 실행하고, 디버깅하고, 계산하고, 기록한다.

이 점에서 그는 이론가라기보다 실험가에 가깝다. 머리로 먼저 완성한 뒤 움직이는 사람이 아니라, 손을 대고 부딪히고 뒤늦게 구조를 이해하는 사람이다. 젊은 시절에는 이 방식이 성급함과 복잡한 코드로 나타났지만, 시간이 지나며 재현 가능성, 테스트, 맥락, 책임을 중시하는 태도로 바뀌었다.

그는 또한 강한 기록 욕구를 가진 사람이다. 블로그, 기술 메모, 여행기, 제품 해명, 채용 글, 투자 실패, 가족 이야기까지 모두 기록한다. 기록은 그에게 자기 과시가 아니라 기억의 백업이고, 사고의 정리이며, 미래의 자신과 타인에게 남기는 디버깅 로그다. 2023년에 오래된 글을 되살리고 부끄러운 글까지 보존하기로 한 태도는 그의 정체성을 잘 보여준다. 그는 결국 쓰는 사람이다.

3. 개발자로서의 평가

개발자로서 신영진의 강점은 낮은 층위까지 내려가는 끈기다. 그는 C/C++, 윈도우, 드라이버, 인코딩, 빌드 시스템, 호환성, 덤프, 스레드, 커널, 보안 제품처럼 귀찮고 날카로운 영역을 오래 다뤘다. 표면의 증상보다 원인을 보려 하고, "왜 그런가"를 끝까지 묻는 편이다. 이런 성향은 보안 제품, 레거시 호환성, 디버깅, 장애 분석 같은 분야에서 큰 장점이다.

또 다른 강점은 기술을 설명하는 능력이다. 그는 단순히 아는 것을 나열하지 않고, 비유와 생활 언어로 바꿔 설명하려 한다. 관리자 권한을 방문 열쇠에 비유하고, 세금을 생활 인센티브로 설명하고, 복잡도를 냄새로 말한다. 좋은 기술자는 문제를 푸는 사람이고, 좋은 선임은 문제를 설명할 수 있는 사람이다. 신영진은 후자에 가까워지는 데 성공했다.

다만 약점도 분명하다. 그는 기준이 높은 만큼 낮은 이해도나 무책임한 태도에 거칠게 반응할 수 있다. 젊은 시절의 글에는 "모르면 안 된다"는 식의 날카로움이 강했고, 이후에도 실력과 책임을 엄격하게 본다. 이 엄격함은 제품 품질에는 도움이 되지만, 사람을 키우는 자리에서는 상대를 위축시킬 위험이 있다. 다행히 시간이 지나며 그는 경로의 다양성, 교육의 한계, 사람마다 다른 성장 속도도 인정하게 되었다. 2021년 이후의 그는 대학, 유튜브, 국비 교육, 커뮤니티, 작품 등 다양한 진입 경로를 더 넓게 받아들인다.

AI 시대에 대한 적응력은 매우 높다. 그는 AI를 신기한 장난감으로 소비하지 않고, 실제 작업 흐름에 넣었다. 2023년에는 ChatGPT를 블로그 리마스터링과 코딩 동료로 받아들였고, 2024년에는 모델별 코딩 능력을 직접 테스트했으며, 2025년에는 자신이 코드를 쓰는 사람에서 맥락을 공급하고 판단하는 사람으로 이동하고 있음을 이해했다. 중요한 것은 자존심을 내려놓는 속도다. 그는 AI가 자신보다 맞을 수 있음을 인정하고, 과거 글의 오류도 수정한다. 오래된 C++ 개발자로서는 보기 드문 민첩성이다.

4. 조직인과 리더로서의 평가

신영진은 본능적으로 소수정예와 개인의 생산성을 선호한다. 사람 수가 늘면 커뮤니케이션 비용과 잡음이 커진다는 것을 일찍부터 알았다. 강제 스크럼이나 강제 페어 프로그래밍 같은 방법론에도 회의적이다. 그는 방법론보다 실제 실력, 맥락, 케미, 책임감을 더 믿는다.

하지만 시간이 지나며 조직에 대한 생각은 단순한 개인주의에서 벗어났다. 2013년 이후 그는 사람을 뽑고, 고객을 상대하고, 제품을 설명하고, 회사의 생존을 고민하는 사람이 된다. 2015년에는 인센티브와 평가, 여유의 불평등, 블랙 기업의 위험을 생각했고, 2016년에는 제품을 둘러싼 오해 앞에 회사의 이름으로 설명했다. 2024년에는 조직을 "충격을 나눠 맞는 구조"로 다시 이해했다. 혼자 잘하는 것의 한계를 경험한 것이다.

리더로서의 장점은 현실 감각이다. 그는 좋은 회사, 완벽한 복지, 아름다운 조직 문화 같은 말을 쉽게 믿지 않는다. 직원과 회사의 이해관계가 다르고, 신뢰가 무너진 채용 시장에서는 각자의 합리성이 전체를 가난하게 만들 수 있다는 것도 안다. 이 현실 감각은 냉정하지만 유용하다. 환상을 줄이고, 실제로 굴러가는 구조를 보게 만든다.

리더로서의 위험은 냉정함이 지나치면 사람을 "성장할 사람"과 "아닌 사람"으로 너무 빨리 나눌 수 있다는 점이다. 그는 도메인 사랑, 집요함, 긍정성 같은 기질을 성장의 핵심 조건으로 본다. 상당 부분 맞는 판단이지만, 사람은 환경과 관계 속에서 뒤늦게 열리기도 한다. 신영진의 리더십이 더 좋아지려면, 정확한 판단력 옆에 느린 가능성을 기다리는 인내가 계속 붙어 있어야 한다.

5. 인간으로서의 평가

신영진은 차갑게 분석하는 사람처럼 보이지만, 실제로는 감정이 많은 사람이다. 다만 감정을 직접 말하기보다 기술, 책, 게임, 영화, 드라마, 음악, 여행, 코드의 비유를 통해 우회해 말한다. 그는 사랑을 변수 한정자로, 관계를 인터페이스로, 책임을 예외 처리로, 삶의 선택을 트레이드 오프로 이해한다. 이것은 감정이 없는 것이 아니라 감정을 이해하는 문법이 기술적인 것이다.

그는 가족을 통해 크게 변했다. 2001년에는 어른이 되는 것을 무서워했고, 2011년에는 아버지의 죽음 앞에서 설명할 수 없는 슬픔을 겪었다. 2015년에는 아버지가 되면서 책임의 무게가 바뀌었고, 2025년에는 가족과 기억을 만드는 사람이 된다. 반골 기질과 자유에 대한 집착은 여전히 남아 있지만, 보호자의 감각이 그 위에 덧씌워졌다.

그에게 반복해서 나타나는 정서는 불안이다. 능력에 대한 불안, 시간에 대한 불안, 비교에서 오는 불안, 회사의 생존에 대한 불안, 기술 변화에서 밀릴 수 있다는 불안, 죽음 앞에서 남은 시간을 세는 불안. 그러나 그는 불안을 마비로 두지 않는다. 불안을 분석하고, 글로 만들고, 일로 바꾸고, 때로는 코드로 바꾼다. 그래서 그의 불안은 약점이면서 연료다.

6. 가치관

신영진의 가치관은 몇 가지로 압축된다.

첫째, 실력은 증명되어야 한다. 말, 학력, 권위, 포장보다 실제로 만들고 설명하고 고칠 수 있는 능력을 중시한다. 그래서 오픈소스, 블로그, 작품, 코드 읽기, 디버깅 경험을 높게 본다.

둘째, 권위는 검증을 대신하지 못한다. 그는 교수, 정치인, 유명 개발자, 투자 대가, 회사 대표, 게이트 키퍼를 쉽게 숭배하지 않는다. 누군가의 자리가 곧 진실의 보증이 아니라고 본다.

셋째, 선택에는 비용이 있다. 2018년 이후 이 인식은 특히 강해진다. 돈, 자유, 명성, 가족, 회사, 건강, 시간은 동시에 극대화할 수 없다. 무엇을 얻을지가 아니라 무엇을 포기할 수 있는지가 중요하다.

넷째, 오래 가려면 자기에게 맞는 판을 골라야 한다. 2025년의 "뱀머리" 고백은 단순한 자기합리화가 아니라 메타인지의 표현이다. 그는 큰 세계의 꼬리가 되는 것보다 작은 세계에서 주도권과 효능감을 유지하는 쪽을 선호한다. 이것은 야망이 없다는 뜻이 아니라, 자신이 오래 버틸 수 있는 조건을 안다는 뜻이다.

다섯째, 기록은 인간을 보존한다. 그는 글을 통해 과거의 자신, 실패한 판단, 기술적 시행착오, 가족의 장면, 시대의 변화를 보존한다. 기록하지 않으면 사라진다는 감각이 강하다.

7. 강점

신영진의 가장 큰 강점은 집요한 학습 능력이다. 그는 한 번 익힌 지식에 머물지 않고, 오래된 글을 다시 검토하고, 틀린 설명을 고치고, 새 도구를 받아들인다. C++과 윈도우에 깊이 뿌리내린 사람이면서도 파이썬, 모바일, AI, Rust, 로컬 LLM의 흐름을 본다.

두 번째 강점은 현실 감각이다. 그는 낭만을 좋아하지만 낭만만 믿지는 않는다. 제품은 팔려야 하고, 회사는 살아야 하며, 코드는 배포되어야 하고, 조직은 인센티브로 움직이고, AI는 비용과 성능과 컨텍스트 창으로 평가되어야 한다. 이 현실 감각은 그를 기술 낭만주의자가 아니라 실전형 기술자로 만든다.

세 번째 강점은 설명과 기록이다. 그는 자신이 겪은 삽질을 공용 자산으로 바꾸는 능력이 있다. 누군가에게는 그의 글이 매뉴얼이고, 누군가에게는 채용 기준이며, 누군가에게는 시대의 개발자 문화 기록이다.

네 번째 강점은 자기 수정 능력이다. 그는 고집이 세지만, 근거가 충분하면 방향을 바꾼다. 페어 프로그래밍을 싫어했지만 AI 페어 앞에서 생각을 바꿨고, 과거 기술 글의 오류도 인정했으며, 유명인을 따라 투자한 실패도 기록했다. 자존심이 없는 사람은 아니지만, 자존심이 학습을 완전히 막지는 못한다.

8. 약점과 한계

신영진의 약점은 높은 기준에서 오는 피로감이다. 그는 자기에게도 남에게도 엄격하다. 이 엄격함은 성취를 만들지만, 동시에 자기비난, 불안, 관계의 긴장을 만든다. 젊은 시절부터 그는 게으르다고 자책했지만 실제로는 너무 많은 일을 하고 있었다. 이 패턴은 이후에도 반복된다.

두 번째 약점은 관계의 서툶이다. 그는 사람을 중요하게 여기지만, 사람과의 마찰을 피곤해하고, 때로는 함께함을 폭력처럼 느낀다. 조직을 운영하면서 많이 나아졌지만, 그의 기본값은 여전히 혼자 깊게 파는 쪽에 가깝다. 이런 사람은 뛰어난 개인 생산성을 낼 수 있지만, 조직이 커질수록 의식적으로 커뮤니케이션 방식을 관리해야 한다.

세 번째 약점은 냉정한 판단이 냉소로 기울 위험이다. 그는 세상의 구조적 한계, 불공정, 인센티브, 죄수의 딜레마를 잘 본다. 하지만 그런 분석은 때때로 "어차피 그럴 수밖에 없다"는 태도로 흐를 수 있다. 다만 그의 글을 보면 완전히 냉소로 떨어지지는 않는다. 그는 여전히 긍정성, 성장, 기록, 가족, 함께 버티는 이유를 붙잡는다.

네 번째 약점은 몰입과 소진의 반복이다. 2009년의 닥치고 코딩, 2015년의 올빼미 생활, 2024년의 불질 같은 장면은 그가 높은 강도의 시간을 견딜 수 있음을 보여준다. 동시에 그런 방식이 오래 지속 가능하지 않다는 것도 보여준다. 그는 쉼표와 행복을 여러 번 다시 배워야 했다.

9. 변화의 궤적

2001년부터 2005년까지의 신영진은 정체성을 찾는 청년이다. 학생, 개발자, 과외 선생, 게이머, 블로거 사이에서 흔들린다. 아직 어른이 되기 싫고, 책임이 두렵고, 기술을 좋아하지만 기술에 갇히는 것도 두려워한다.

2006년부터 2010년까지는 공개된 개발자로 성장하는 시기다. 연재, MVP, 책, 블로그, 커뮤니티, 해외 경험을 통해 이름이 밖으로 나간다. 동시에 죽음, 가족, 유한성, 책임을 더 자주 보게 된다.

2011년부터 2016년까지는 제품과 조직의 책임자가 되는 시기다. XIGNCODE는 단순한 코드가 아니라 작품이자 생계이자 공적 설명의 대상이 된다. 그는 사람을 뽑고, 제품을 변호하고, 회사의 생존을 고민하고, 아버지를 잃고, 자신도 아버지가 된다.

2017년부터 2022년까지는 세계를 더 넓게 관찰하고 냉정해지는 시기다. 해외 전시, 시장, 세금, 채용, 암호화폐, AI의 비용, 교육 경로, 성장의 조건, 복잡한 플랫폼 세계를 본다. 그는 더 많은 것을 이해하지만, 그만큼 세계가 단순하지 않다는 것도 받아들인다.

2023년부터 2025년까지는 기록과 AI의 시기다. 그는 과거의 글을 되살리고, 부끄러운 자신을 보존하며, AI를 작업 동료로 받아들인다. 코드를 직접 치는 능력보다 맥락을 구성하고 판단하는 능력이 중요해지는 변화를 빠르게 흡수한다. 동시에 죽음과 남은 시간을 더 구체적으로 세며, 자기에게 맞는 세계를 선택하려 한다.

10. 종합 결론

신영진은 완벽한 사람도, 둥근 사람도 아니다. 그는 예민하고, 까칠하고, 불안하고, 기준이 높고, 종종 피곤한 사람이다. 그러나 바로 그 성질들이 제대로 쓰일 때 그는 강한 기술자가 된다. 대충 넘어가지 못하고, 직접 확인해야 하며, 틀리면 고치고, 배운 것은 남긴다. 이런 사람은 옆에 있으면 편하지만은 않지만, 어려운 문제 앞에서는 믿을 만하다.

그의 삶을 관통하는 말은 성장보다 수정에 가깝다. 그는 한 번에 멋진 방향으로 성장한 사람이 아니라, 계속 틀리고, 불편해하고, 부끄러워하고, 다시 고치면서 여기까지 왔다. 2001년의 그는 자기 이름을 설명하지 못했지만, 2025년의 그는 적어도 자신이 어떤 연못에서, 어떤 방식으로, 누구와 함께, 어떤 도구를 들고 살아야 하는지 훨씬 더 잘 안다.

따라서 신영진에 대한 최종 평가는 이렇다. 그는 기술을 통해 세상을 보고, 글을 통해 자신을 보존하며, 실패를 통해 판단을 갱신하는 사람이다. 강점은 집요함과 현실 감각이고, 약점은 높은 기준과 소진의 반복이다. 하지만 그 약점까지 포함해 그는 드문 유형의 개발자다. 오래 만든 사람, 오래 쓴 사람, 오래 의심한 사람, 그리고 아직도 배우는 사람.

[ai] 사내 문서·코드를 LLM 이 잘 찾게 만드는 법

Sun, 10 May 2026 13:00:01 GMT

[AI-GENERATED] 이 문서는 AI가 작성한 것이며, 작성자는 사람이 아닙니다.

Redmine 위키·이슈와 여러 git 저장소를 한꺼번에 LLM 이 검색·인용할 수 있게 만든 인덱스 시스템 이야기. 이 글은 "검색이 뭐고, 왜 두 종류가 필요하고, 왜 합쳐야 하는지" 같은 개념 설명에 초점을 맞춘다. FTS·벡터·임베딩 같은 단어를 처음 듣는 사람도 끝까지 읽을 수 있게 썼다.

본문에 등장하는 제품명·함수명·이슈 번호 등은 설명을 위한 가상의 예시다.

1. 풀려는 문제

회사에 쌓인 자료는 두 가지 형태다.

Redmine: 위키 페이지(수천 단위), 이슈와 댓글(수만 단위), 사람·프로젝트 목록.
Git 저장소: C/C++/C#/Python 등으로 짠 제품 소스 코드.

LLM 에게 "결제 모듈의 중복 결제 방지 로직이 어떻게 동작하지?" 같은 질문을 던지면, LLM 은 해당 위키 페이지 + 관련 이슈 + 실제 코드 함수까지 같이 보면서 답해야 한다.

문제는 LLM 의 컨텍스트 창이 유한하다는 것. 위키 전체와 코드 전체를 그냥 던져넣을 수는 없다. LLM 이 보기 전에 사람이 읽을 수 있는 분량으로 잘 골라주는 모듈 이 필요하다. 이걸 보통 검색 인덱스(retrieval index) 라고 부른다.

2. 텍스트를 찾는 두 가지 방식

2.1 키워드 검색 (FTS)

가장 직관적인 방식. 사용자가 친 단어가 문서에 그대로 들어 있는지 본다.

"결제 인증 모듈" 이라고 치면, 이 세 단어를 모두(또는 일부) 포함한 문서를 점수 매겨 정렬해 돌려준다.

이걸 풀텍스트 검색(Full-Text Search, FTS) 이라고 한다. 우리가 쓰는 SQLite 에는 FTS5 라는 풀텍스트 검색 엔진이 내장돼 있어서, 별도 검색 서버를 띄우지 않아도 된다. 점수 계산은 BM25 라는 표준 알고리즘이 담당한다 — 흔한 단어는 점수를 낮게, 그 문서에서만 자주 나오는 단어는 점수를 높게 주는 식.

장점: 정확한 단어 매칭에 강하다. 이슈 번호 #1234, 함수 이름 verifyAuthToken, 헥스 값 0x90 같은 식별자는 글자 그대로 찾는 게 가장 정확하다.

단점: 표현이 달라지면 못 찾는다. 사용자가 "인증 모듈" 이라 쳤는데 문서엔 "사용자 검증 컴포넌트"라고 써있으면 매치 0. 사람한테는 같은 뜻인데 글자가 다르니 키워드 검색은 0 점을 준다.

2.2 의미 기반 검색 (벡터)

다른 접근: 문장의 의미를 어떻게든 숫자로 바꿔서 비교한다. 의미가 비슷한 두 문장은 숫자도 비슷하게 나오면 좋겠다.

이걸 가능하게 하는 게 임베딩 모델(embedding model) 이다. 신경망이 문장을 받아서 1024 개짜리 숫자 배열(=벡터)을 출력한다. 의미가 비슷한 두 문장은 그 두 벡터가 "가까운" 위치에 놓이게끔 학습돼 있다.

"인증 모듈" → [0.12, -0.07, 0.31, ..., 0.05] (1024 개) "사용자 검증 컴포넌트" → [0.11, -0.06, 0.33, ..., 0.04] (꽤 비슷함) "오늘 점심 뭐 먹지" → [0.91, 0.02, -0.44, ..., -0.20] (전혀 다름)

질의도 같은 모델로 벡터화해서, 모든 문서 벡터 중 가장 가까운 것을 찾는다. "단어가 안 겹쳐도 의미가 통하면 잡아내는" 검색이 된다.

우리는 BGE-M3 라는 다국어 임베딩 모델을 쓴다 (한국어 + 영어 둘 다 잘 잡혀야 해서). SQLite 에 sqlite-vec 라는 확장을 끼워서 벡터까지 같은 DB 파일에 저장한다 — 별도 벡터 DB 인프라 없음.

장점: 표현이 달라도 찾는다. 동의어, 의역, 다른 언어로 쓴 같은 개념까지 잡는다.

단점: 정확한 식별자엔 약하다. #1234 와 #1235 는 의미상 거의 같게 보여서 임베딩이 둘을 구분 못 할 수 있다. 문서에 등장하는 SHA 해시 같은 건 의미가 없는 랜덤 문자열이라 벡터가 신뢰할 수 없다.

2.3 한쪽이 답이 아니라, 둘 다 필요하다

위 두 단점을 정리하면:

	키워드 검색 (FTS)	의미 검색 (벡터)
단어가 일치할 때	매우 정확	보통
표현이 다를 때	못 찾음	잘 찾음
식별자(#1234, 함수명)	매우 정확	부정확할 수 있음
자연어 질의	보통	매우 좋음

서로 정반대의 약점을 가진다. 그래서 두 방식을 동시에 돌리고 결과를 합치는 게 요즘 표준 — 보통 하이브리드 검색(hybrid retrieval) 이라고 부른다.

3. 두 검색 결과를 어떻게 합칠까

문제: 키워드 검색은 BM25 점수(0~~∞), 의미 검색은 거리(0~~2). 단위가 다르다. 그냥 더할 수 없다.

해결: 점수 자체는 버리고, 순위(랭크) 만 본다. 키워드 쪽에서 1등인 문서, 의미 쪽에서 3등인 문서… 식으로. 그 다음 각 문서의 최종 점수는

score = 1/(60 + 키워드 순위) + 1/(60 + 의미 순위)

같은 식으로 매긴다. 1 등은 큰 값, 50 등은 거의 0. 양쪽에서 모두 나오는 문서는 점수가 두 배로 쌓이니까 자연스럽게 위로 올라온다. 양쪽 단위를 안 맞춰도 됨.

이걸 RRF(Reciprocal Rank Fusion) 이라 한다. 60 은 흔히 쓰는 표준값.

직관: "둘 다 적당히 잘 본 문서" 가 "한 쪽에서만 압도적으로 1 등인 문서" 보다 보통 더 좋은 답이라는 가정에 기댄다. 실제 RAG 결과 품질이 잘 올라가는 게 검증된 방식.

4. 마지막에 한 번 더 거르는 단계 — Rerank

위에서 합친 결과 상위 50 개 정도를 가져온 뒤, 마지막에 한 번 더 정밀 채점 한다. 이게 재정렬(rerank) 이다.

검색 단계의 임베딩 모델은 빠르려고 질의와 문서를 따로 벡터화해서 거리만 쟀다. 재정렬 단계는 다른 종류의 모델을 써서 질의-문서 한 쌍을 같이 보고 점수를 매긴다. 훨씬 비싸지만 훨씬 정확하다.

50 개 → 정밀 채점 → 상위 10 개를 LLM 한테 보낸다.

비유: 책을 살 때 (1) 서점 검색창에 단어를 쳐서 후보를 100 권 추리고 (2) 표지/목차를 훑어서 20 권으로 줄이고 (3) 진짜로 한 페이지씩 읽어보면서 살 책 3 권을 고르는, 그 마지막 단계가 rerank 라고 생각하면 비슷하다.

5. 한국어와 코드 식별자가 동시에 매끄러워야 한다

키워드 검색은 "단어 단위로 쪼갠다 → 인덱스에 넣는다" 가 기본 동작이다. 이 쪼개는 작업을 토크나이징 이라고 한다. 영어는 공백으로만 쪼개도 어지간히 동작하는데, 한국어는 조사가 붙는다.

"인증 모듈을" 이라고 쳤는데 문서엔 "인증 모듈에"라고 쓰여 있으면, 글자 단위 비교만 하는 토크나이저는 둘을 다른 단어로 본다. 매치 실패.

해결: 한국어 형태소 분석기 (kiwipiepy) 를 거쳐서 어간만 남긴다.

"인증 모듈을" → ["인증", "모듈"]
"인증 모듈에" → ["인증", "모듈"]   ← 같은 토큰 → 매치 성공

이걸 인덱스를 만들 때 한 번, 검색할 때 한 번 같은 방식으로 적용해야 둘이 맞붙는다.

추가로 두 가지 디테일:

고유명사 보호: 자사 제품명, 프로젝트 코드네임, 사내 약어 같은 단어는 형태소 분석기가 일반 명사로 오인하고 이상하게 쪼갤 수 있다. 사용자 사전에 등록해서 통째로 한 토큰으로 유지.
코드 식별자 보존: #1234, 0x90, verifyAuthToken 같은 패턴은 형태소 분석기가 모른다. 정규식으로 따로 잡아서 토큰 목록에 추가. 그래야 이슈 번호나 함수 이름이 그대로 검색된다.

6. 청킹 — 한 입에 들어가게 자르기

문서 전체를 검색 단위로 쓰면 두 가지 문제가 생긴다.

위키 페이지 한 장이 너무 길면 임베딩 모델의 입력 한계를 넘는다.
길수록 "이 페이지 어딘가에 있다" 식의 모호한 매치만 되고, 어느 부분 인지를 짚어주지 못한다.

그래서 적당한 크기로 자른다. 이 단위를 청크(chunk) 라고 부른다.

자르는 기준은 자료 종류마다 다르다.

위키: #, ## 마크다운 헤딩 단위로 자른다. 의미 경계가 자연스럽게 맞아떨어지고, 사람이 그 글을 그렇게 쓰기 때문.
이슈: 본문 1 청크 + 댓글마다 1 청크. 댓글은 보통 다른 사람이 다른 시점에 쓴 내용이라 합쳐 두면 의미가 섞인다.
코드 함수: 가능하면 함수/클래스 단위로 자른다 (자세한 건 §8).

각 청크 맨 앞에 한 줄짜리 메타 헤더를 박아둔다.

[#1234] 결제 실패 케이스 분석 — author=홍길동, status=Resolved, updated=2025-04-12
... 이슈 본문 ...

이 한 줄 덕분에:

키워드 검색에서 "홍길동 #1234" 같은 합성 질의가 자연스럽게 매치된다.
임베딩이 청크의 정체(어떤 종류의 글, 누구 글, 언제 글)를 같이 학습 입력으로 받는다.
LLM 이 결과를 인용할 때 "이슈 #1234 에서…" 처럼 출처를 자연스럽게 꺼낸다.

7. 한 번 만들고 끝이 아니라, 매일 갱신해야 한다

위키도 이슈도 매일 갱신된다. 인덱스는 그걸 따라가야 한다.

단순히 매일 전체를 다시 만든다 = 사실 가능하지만, 임베딩 비용이 크다 (문서 수 × 모델 호출 수). 안 바뀐 건 그대로 두는 게 좋다.

해결: 각 문서의 안정 필드를 모아 해시(hash) 를 찍어 둔다. 다음 날 같은 문서를 다시 가져왔을 때, 새 해시와 저장된 해시가 같으면 "내용 안 바뀜" 으로 판정 → 청킹·임베딩 단계 통째로 건너뛴다.

함정: Redmine 의 updated_on 필드는 의미 없는 편집(상태값 토글, 워크플로 노이즈)에도 bumping 된다. 이 필드까지 해시에 넣으면 본문이 안 바뀌었는데도 매일 재임베딩된다. 그래서 updated_on 은 의도적으로 해시에서 제외한다.

코드 저장소는 한 단계 더 — git 이 차이를 알려준다. 마지막으로 인덱스에 반영한 커밋 SHA 를 저장해 두고, 다음 실행 때 git diff <저장된 SHA>..HEAD 만 본다. 바뀐 파일만 후보가 되고, 후보 안에서도 다시 해시 비교로 한 번 더 거른다 (rename 만 된 경우 같은 가짜 변경 제거).

결과: 매일 5-10 분 안에 갱신이 끝나고, 안 바뀐 99% 의 문서는 손도 안 댄다.

8. 코드는 "함수 단위" 로 자르는 게 핵심

위키는 헤딩으로 자르면 됐지만, 코드는 자연스러운 경계가 다르다. 코드의 경계는 함수, 메서드, 클래스, 구조체 다.

같은 200 라인을 자른다고 해도

라인 100~300 으로 자르면 함수 중간이 잘려서 의미가 깨진다.
함수 단위로 자르면 "이 함수가 무엇을 하는지" 가 한 청크에 온전히 담긴다.

함수 경계를 알아내려면 코드를 파싱해야 한다. 그래서 tree-sitter 라는 다언어 파서를 쓴다. C/C++/Python/C# 등의 함수·클래스·메서드 노드를 추출해서 각각을 한 청크로 만든다.

너무 큰 함수(500 줄 초과) 는 다시 200 줄 윈도우로 쪼갠다 (모델 입력 한계 보호).
tree-sitter 가 모르는 언어는 그냥 200 줄 윈도우로 잘라준다 (graceful degradation).
청크 첫 줄에 anchor 코멘트를 박는다:
```
// src/auth/verifier.cpp:TokenVerifier::Verify  (lines 142-318)
```
→ 청크가 함수 중간 } 부터 시작해도 임베딩이 갈피를 잡는다.

민감 정보는 인덱싱 직전에 가린다. AWS 키, JWT, 사설 PEM, GitHub 토큰 같은 패턴을 정규식으로 잡아서 [REDACTED:aws_access_key] 같은 자리표시자로 바꾼 텍스트만 DB 에 저장한다. 디스크의 원본 파일은 그대로. 검색 결과를 통해 시크릿이 LLM 으로 흘러 나가는 사고를 사전 차단.

9. 이슈와 코드를 잇는 그래프

위키·이슈·코드를 다같이 검색 하는 것 외에, 서로 어떻게 연결되는지 도 인덱스에 남겨둔다.

git 커밋 메시지엔 보통 #1234 같은 이슈 번호가 들어 있다. 이걸 정규식으로 뽑아서 (이슈 ↔ 커밋) 매핑 테이블에 적재한다.

이 테이블 위에 세 가지 검색 함수가 붙는다.

"이 이슈를 고친 커밋들?" (issue → commits)
"이 커밋이 닿은 이슈들?" (commit → issues)
"이 파일을 만진 커밋들이 닿은 이슈들?" (file → issues)

세 번째가 특히 가치 있다. 어떤 파일에 버그가 났을 때, 그 파일을 과거에 건드린 커밋들이 어떤 이슈에서 시작된 작업이었는지를 한 번에 본다 → 같은 부류의 버그가 이전에도 있었는지 즉답.

작은 디테일: 이슈 번호 #1 같은 작은 숫자는 GitHub PR 번호가 squash 메시지에 섞여 들어온 노이즈일 가능성이 크다. 운영 환경의 실제 이슈 번호 자릿수에 맞춰 최소 임계값을 두고, 그 미만은 일괄 무시.

10. 전체 흐름 정리

매일 한 번 도는 파이프라인은 대략 이렇다.

1. Redmine 백업본 동기화
   └ NAS 의 위키·이슈·메타 덤프

2. Redmine 인덱싱 (build_index)
   ├ 각 위키 / 이슈 / 메타 → 해시 비교 → 안 바뀌면 skip
   └ 청킹 → SQLite 의 chunks 테이블

3. 임베딩 (embed)
   └ 아직 벡터가 없는 청크만 BGE-M3 로 인코딩 → chunks_vec

4. 엔티티 페이지 빌드 (build_entities)
   └ LLM 이 사람·제품·시스템별 요약 페이지를 자동 작성

5. 코드 저장소 fast-forward (code_clone pull)

6. 코드 인덱싱 (code_build_index)
   ├ git diff 로 바뀐 파일만
   ├ tree-sitter 로 함수 단위 청킹 (안 되면 라인 윈도우)
   └ 시크릿 redact 적용

7. 이슈↔커밋 크로스레퍼런스 (code_xref)

검색은 그 반대 흐름. 사용자가 질의를 던지면

질의
 ├→ 키워드 검색 (FTS5 + BM25)        ─┐
 └→ 의미 검색 (sqlite-vec + BGE-M3)   ─┴→ RRF 합산 → 상위 50개
                                         └→ rerank → 상위 10개 → LLM

LLM 은 받은 청크를 근거로 답하면서 #1234, wiki:proj/page 같은 식별자를 인용한다. 필요하면 그 식별자들을 다시 fetch 해서 (resolve_references) 인용을 한 단계 더 따라간다.

11. 왜 이 디자인을 택했나 — 한 줄씩

단일 SQLite 파일: 별도 벡터 DB 서버 안 띄움. 백업은 cp. 노트북에서도 돈다.
FTS + 벡터 같은 DB: 벡터가 비어 있어도 키워드 검색만으로 동작 — 인덱싱이 진행 중인 중간 상태에도 가용하다.
헤더 한 줄로 메타 누설: 청크가 자기를 어디 출신인지 들고 다닌다. 검색 결과가 자기소개를 한다.
해시 기반 incremental: 매일 돌려도 안 바뀐 99 % 는 0 비용.
함수 단위 청킹: 코드 검색 품질의 가장 큰 변수. 라인 윈도우만으로는 답이 안 됨.
하이브리드 + rerank: 한 가지 검색만 쓰면 어느 한쪽 질의 패턴에서 무너진다. 세 단계로 안전망.
이슈↔커밋 그래프: 같은 인덱스 안에서 "왜 이 코드가 이렇게 짜였는지" 의 추적이 한 번의 SQL 조인으로 끝난다.

큰 그림으로 보면 RAG(Retrieval-Augmented Generation) 표준 레시피지만, 실제 품질을 결정하는 건 모델이 아니라 무엇을 한 청크로 묶고 / 어떤 헤더를 박고 / 어떻게 토크나이즈하고 / 무엇을 incremental skip 하는가 같은 자잘한 결정들이다. 이 글이 다룬 게 그 부분이다.

[일상] 2026년 4월의 잡담

Thu, 30 Apr 2026 06:59:48 GMT

#0

cc 코드가 유출됐고, 재빠른 한국인 개발자가 codex 기반 워크플로우로 그걸 파이썬으로 변환해서 올렸고, 그 저장소는 깃헙 역사상 가장 빠른 스타 성장을 보였다는 뉴스. ai로 소스 유출 파급력이 예전과는 압도적으로 다른 세상이 된 것 같다. 어질어질하네.

2026-04-01

#1

휴민트 잼있는데. 왕사남보단 난듯.

2026-04-05

#2

인공지능 쓰면 쓸수록 실로 놀랍긴 하다. 1년 걸려도 못할거 같은 작업을 2-3일에 모두 끝냈다. 물론 그마저도 내가 검토하는 과정이 병목. 될까 싶었는데 내부 테스트를 통과했다. 내년 이맘때쯤엔 어떤 세상에 살고 있을지?!

2026-04-10

#3

2026-04-22

#12

개발한정 인공지능으로 생산성이 올라간 건 이견이 없는 사실일 것 같다. 그럼에도 아직은 비용만 잡아먹는 것도 사실. 인공지능으로 생산성은 올라갔지만 매출, 수익은 제자리란 의미. 그러니 젤 쉬운게 인원을 줄이는 게 아닌가 싶다. 인원도 줄이기 어려우면 뭘 해야 하나 싶기도?!

바이브 코딩으로 뭐든 만들 수 있는 세상이 되었지만, 뭐가됐든 돈으로 만들긴 더 어려운 세상이 된 것 같기도 하다. apm 설치해주고 돈 받던 시절이 있었던 걸 생각하면 격세지감이.

2026-04-24

#13

잠자 부부의 눈에는 딸의 모습이 그들의 새로운 꿈과 아름다운 계획을 다짐해 주는 증거처럼 비쳐졌다. - 변신, 카프카

가족이 사랑한 것은 그레고르였을까, 그의 급여였을까. 답을 알기도 전에 다음 타자는 딸, 그레테로 넘어간다. 불투명한 내면 앞에서 사랑의 진위는 끝내 알 수가 없다. 거기서 인간의 본질적인 고독이 생겨나는지도?! 모두가 너무나 그럴듯해서 불편한 소설이 아닌가 싶었던 소설.

2026-04-26

#14

일주일치 토큰 리밋을 거의 이 작업에 다 때려 부었지만 100% 동작하는 구현을 못 만들었다. 쟤도 모르고 나도 모르니 서로 그냥 우문우답 무한루프. 이게 딱 보면 학습한데까지는 일사천린데 학습이 없는 미지의 영역은 지도편달이 많이 필요힌 것 같다. https://x.com/codemaru/status/2045319727040586023

디버거를 붙여주면 셀프 디버깅해서 개선을 하는데 딱 내 시스템에 특정 테스트만 통과하는 식으로 해결함. 오프셋 0x20을 하드 코딩 한다든지 하는 식으로. 근본적으로 해결하라면 다시 무한루프 ㅎㅎ

이 작업을 하면서 느낀 건 조엘 말처럼 새시대의 소스 코드는 명세 그 자체라는 생각. 다만 이거도 어폐가 있는건 난 저 기능의 외적인 명세는 완벽하게 쓸 수 있지만 내부를 어떻게 구현해야 하는지는 모른다. 미학습 영역은 디테일한 세부 구현을 모두 알려줘야 뭔가 프로덕션 레벨 달성이 가능한듯.

2026-04-27

#15

모자무싸 대사 하나하나가 주옥인데, 여주로 너무 비주얼 원탑을 캐스팅해서 납득이 좀,... 라는 걸 느낀다. 그럼에도 탐라를 보니 작가님 이번에도 성공 하신듯.

2026-04-27

#16

갈수록 인공지능을 위한 인공지능 연구 사례가 늘고 있는 느낌. 걍 코덱스 클로드 코파일럿 아무거나 골라서 아무렇게나 시켜도 기깔나게 하는데, 뭔 인공지능 세팅을 그리도 복잡하게 하려 하는지. 주화입마에 빠지지 말자.

2026-04-30

[일상] 2026년 3월의 잡담

Mon, 30 Mar 2026 22:29:47 GMT

#0

인간관계에서 정의란 힘이 대등할 때나 의미를 가질 뿐입니다. 현실에서는 강자가 원하는 바를 관철하고, 약자는 그저 받아들일 수밖에 없다는 사실을 우리 모두 잘 알고 있지 않습니까? - 펠로폰네소스 전쟁사, 투키디데스

겉치레를 뺀 국제 정치란 사실상 고등학교 일진 노릇과 다를 게 없다는 말이 실감나는 요즘 세상

2026-03-04

#1

몇년 사이에 직접 코딩하는 능력은 확실이 잃어버린 것 같다. 인공지능 전에는 예전에 짠 코드를 보면서 보통 이걸 왜 이 따위로 짰지 이런 느낌이 일반적이었는데. 이제는 역으로 이걸 어떻게 직접 만들었지? 이런 느낌이 든다.

2026-03-09

#2

독일어 전공에, 엑셀도 못해서 교양 컴퓨터 실기 시험도 버벅대던 친구가 앱 개발을 했다고 연락이 왔다. 심지어 동작 잘함. 대단하다는 생각도 잠시, 바야흐로 전국민이 개발자인 시대가 열린게 아닌가 싶다.

2026-03-17

#3

얼마나 더 고통의 변방을 방황해야
그 기억을 깨끗이 죽여 없앨 수 있을까
사랑했던 기억 또한 진눈깨비라면
계절을 잘못 찾아온 길 잃은 눈사람이라면
뉘우치지 않아도 좋으니 부디 사라지기를

날씨가 좋으면 찾아가겠어요, ep.02

2026-03-18

#4

화장실 들어갈 때와 나올 때 마음이 다른 게 인지상정이겠지만, 우리 사회는 여러모로 아직도 옵션 형태의 계약을 이행하는데에는 미숙하다는 생각이 많이 든다.

2026-03-19

#5

브람스와 드보르작 말러 브루크너 쇼스타코비치
회화는 바로크 카라바지오 루벤스 반다이크
스탕달과 플로베르는 모든 작품을 다 읽었죠
존 스타인벡 에밀 졸라 빅토르 위고도 좋아했고요
와인은 부르고뉴 기념할 일 있을 땐 도멘 르루아
위스키는 스페이사이드 싱글 몰트

좋은 취향이구나
-아너 ep05

취향은 계급을 만든다.
-- 부르디외

2026-03-22

#6

요즘 참 맨정신으로 사는 게 쉽지 않은 세상이란 생각이 들었다. 새로 알게 된 4명중 3명이 신경안정제를 포함한 정신과 약을 복용 중. 어쩌다 공황장애, 우울증 같은 게 일상인 세상이 된건지.

2026-03-30

#7

죽기 전에 성경도 봐야 할 거 같아서 읽을만한 것만 추려서 보는 중인데 뭔가 불교책 보다 성경 보면 mbti t와 f를 보는 듯한 느낌이 든다. 한놈은 서사로 조지고, 한놈은 논리로 팬다.

2026-03-30

[일상] 2026년 2월의 잡담

Sat, 28 Feb 2026 12:52:09 GMT

#0

맥미니 공초하고 openclaw를 돌려봤다. 토큰 사용량이 이게 맞나 싶다. 쓰잘떼기 없는 설정 관련 대화 몇마디 했을 뿐인데 이 엄청난 토큰 사용량이라뉘. 도대체 백그라운드에서 뭘 한 거지 싶다. 그럼에도 몇몇 유용한 지점은 분명 있는듯. 다만 보안이 우려될 뿐.

2026-02-01

#1

최고의 시절이자 최악의 시절, 지혜의 시대이자 어리석음의 시대였다. 믿음의 세기이자 의심의 세기였으며, 빛의 계절이자 어둠의 계절이었다. 희망의 봄이면서 곧 절망의 겨울이었다. 우리 앞에는 모든 것이 있었지만 한편으로 아무것도 없었다. - 두 도시 이야기, 디킨스

인공지능 시대에도 묘하게 오버랩되는 문장.

2026-02-02

#2

예뻐 보여서 피토니아를 인터넷으로 몇개 주문했다. 한파라 배송이 지연된다는 이유로 3주만에 도착했는데, 우리집에서 이틀만에 모두 죽어버림. 똥손이란 이런 것인가? 난 뭘 한 것인가? 병원에서 한 뿌리 받은거로 정글을 만들어 놓았던 엄마가 새삼 대단하게 느껴졌다.

2026-02-11

#3

탐내라! 하지만 삶 전체를 탐내라. 탐심에 대한 해독제는 총체적인 탐심이다. 그러므로 버핏이 이룬 성공을 탐낼 때도 총체적으로 탐내야 한다. 버핏이 건설한 제국과 축적한 수십억 달러뿐만 아니라, 그가 살아온 삶도 포함해야 한다. - 죽음은 통제할 수 없지만 인생은 설계할 수 있다

유튜브에서 추천해서 봤는데 전반부 저자 인생 얘기가 무지 지루했다. 스토아 철학 다이제스트는 나름 유용. 4장부터 읽는 걸 추천.

2026-02-11

#4

매일 쓰는 물건이 아름다우면 좋죠. 그리고 그냥 시간을 견딘 것들이 주는 위로가 있잖아요? - 안녕이라 그랬어, 김애란

당연한 얘기지만 긴 시간 엄마 옆에 머물며 내가 가장 그리워한 사람은 헌수였다. 나와 결혼할 뻔한 사람이어서가 아니라 나와 같은 고독을 겪은 사람이라 그랬다.

단편 내용들을 보면서 김애란 작가도 이제 나이가 들었구나, 라는 생각을 하게 됐다. 어쩌면 또래라 비슷한 렌즈로 세상을 보고 있는 건지도 모르겠다. 김애란 작가 단편집은 실패가 없는듯.

2026-02-22

#5

사업가나 사기꾼이나 매한가지긴 해. 근데, 사업가가 사기꾼과 다른 게 딱 한 가지 있어. 뭔지 알아? 시작은 허풍일지라도 끝은 아니라는거지. - 레이디 두아 ep.04

2026-02-17

#6

기술이 외모지상주의를 해결해 줄거란 생각을 별로 하지 않는다. 테드 창 소설에 나오는 것처럼 한 기준을 차단하면 사람들은 또 다른 기준으로 서열을 나눌테니. 외모 뿐만이 아니라 애초에 우리가 가진 모든 것들 중에 공평한 거라곤 사실 1도 없는 게 진실 아닌가 싶다.

2026-02-20

#7

왕과 사는 남자 하도 말이 많아서 십만년만에 애들 영화 아닌거로 극장 가서 봤는데. 그닥이었다. 넷플에서 틀었다면 절대 끝까지 못봤을 느낌. 그럼에도 평점은 어마무시.

2026-02-25

#8

알지? 너 개새끼인거 - 파반느, 2026

2026-02-28

[잡기] 추사 김정희의 도망시

Mon, 23 Feb 2026 21:00:01 GMT

저녁 먹으면서 볼 게 없어서 경도를 기다리며, 라는 드라마를 한 편 봤는데 거기 추사의 도망시라는 게 나왔다. 도망시가 제목인 줄 알았는데 '도망시(悼亡詩)'는 특정 시의 제목이 아니라 '죽은 아내를 애도하는 시'를 통칭하는 문학적 갈래라고 한다. 추사 김정희의 지극한 아내 사랑이 잘 드러나는 시인 것 같아서 가져와 보았다.

예전에 유시민 작가가 한 말인지 잘 모르겠는데 인간의 원초적 고독감은 감각 기관이 고립돼 있다는 데서 온다는 말을 들었던 기억이 있다. 무슨 말이냐면 내가 느끼는 걸 동일하게 타인이 느낄 수가 없는 구조라는 것이다. 실제로 내가 보는 파랑과 타인이 보는 파랑은 모두 다르다. 또 우리는 이해한다는 말을 하지만 타인이 느끼는 희노애락을 똑같이 느낄 수는 없다. 단지 상상할 뿐이다. 결국 우리는 저마다의 감각 기관이 수집한 정보를 저마다의 뇌가 만들어낸 환상으로 이루어진 고립된 섬 속에 존재하고 있는 셈이다. 그래서 인간은 원초적으로 고독한 존재라고 한다.

배소만처상 (配所輓妻喪)
유배지에서 아내의 죽음을 애도하며

那將月佬訟冥司 (나장월노송명사)
어찌 월하노인을 시켜 저승에 하소연하여,

來世夫妻易地爲 (내세부처역지위)
다음 생엔 우리 부부가 서로 바꿔서 태어날까.

我死君生千里外 (아사군생천리외)
나는 죽고 당신은 천 리 밖에 살아남아서,

使君知我此心悲 (사군지아차심비)
나의 이 슬픈 마음 당신이 알게 했으면.

-- Gemini 3.1 Pro

김정희는 또 그가 말년에 쓴 대팽두부라는 구절로 유명하기도 하다. 최고의 자리와 최악의 시절을 모두 겪어본 그가 하는 말이라 더 공감이 가는지도 모르겠다.

大烹豆腐瓜薑菜 (대팽두부과강채)
최고로 좋은 반찬은 두부, 오이, 생강, 나물이고

高會夫妻兒女孫 (고회부처아녀손)
최고로 훌륭한 모임은 부부와 아들딸, 손자 손녀가 모인 자리이다.

이 두 줄의 글귀 옆에는 추사가 덧붙인 작은 글씨(협서)가 있습니다.
"이것은 촌늙은이의 제일가는 즐거움이다. 비록 정승 판서가 누리는 밥상이나 삼천 명의 시녀를 거느린 귀족이라도 이 맛을 알지는 못할 것이다."

-- Gemini 3.1 Pro

TMI로 김정희는 일기를 쓰다, 흠영선집의 원작자인 유만주의 6촌형 유준주의 딸이 시집가서 낳은 아들이다. 유만주의 딸 진아는 추사의 6촌형 김도희에게 시집갔다. 이렇게 보면 참 스머프 마을같고, 유전자빨이란게 있나 싶은 생각이 들지만, 사실 6촌이면 남 아닌가 싶은 생각이 들기도 한다. 6촌 중에 실질적으로 아는 사람이 없다. 5촌 당숙 정도가 한계인듯. 그럼에도 유만주와 유준주는 흠영을 보면 몹시 잦은 교류가 있는 사이였다는 게 또 반전 아닌가 싶기도?!

TIM2. 김정희는 결혼을 두 번 했다. 15세에 결혼한 첫번째 부인은 20세에 먼저 떠났고, 이 시의 주인공인 두번째 부인은 23살에 결혼해서 김정희가 55살이던 해에 병으로 먼저 떠났다고 한다. 그의 다른 인생사도 기구하지만 두 부인다 먼저 떠난 부분도 참 안타깝다는 생각이 든다. 그럼에도 시에 드러난 감정이 생길 정도로 애틋한 사람을 만났던 건 행운이 아닌가 싶다. 좋은 집안에, 좋은 머리로 태어나 출세 가도를 달린 인생 전반부와 당쟁에 휘말려 귀양과 유배로 보냈던 후반부를 오버랩시켜 보면 인생사라는 게 어쩌면 총량의 법칙이 실재하는게 아닌가 싶기도 한 생각이 든다.

[리뷰] 카핑 베토벤, 2007

Mon, 23 Feb 2026 14:00:01 GMT

불멸의 연인 후에 본 베토벤에 관한 또다른 영화. 베토벤의 인생 후반부를 다룬다. 제목만 보면 뭔 베토벤 곡을 베끼나?!라는 생각을 하게 되는데, 영화가 시작하면 그게 다름 아닌 카피스트라는 사람들이란 걸 알게 된다. 작곡가가 알아보기 힘들게 작성한 악보를 보기 좋게 필사해 주는 직업이다. 실제로 당시에는 그런 역할을 하는 카피스트라는 직업이 존재했다고 한다. 영화는 재미를 위해서 안나 홀츠라는 여성 카피스트를 등장시킨다.

영화는 크게 3부분으로 나뉜다. 귀가 안들리는 상황에서 9번 교향곡을 작곡해서 메가 히트를 치는 장면, 이어서 대푸가를 공연하면서 똥망하는 장면, 그리고 죽다 살아나서 현악 4중주를 작곡하는 장면으로 끝이 난다. 9번 교향곡 지휘하는 장면만 엄청 길게 나오는 등, 클래식을 좋아하지 않으면 재미있게 보기는 상당히 힘든 영화가 아닌가 싶다.

실제로 대푸가를 들어보면 당시 욕했던 사람들이 상당히 이해되는 부분이 있다. 아고르 스트라빈스키는 대푸가를 "영원히 현대적인, 절대적으로 동시대적인 음악"이라고 평가했다고 한다. 미술이든 음악이든 현대적이라는 말은 참 난해하다. 23세기에도 현대적일 것 같은 베토벤의 대푸가. 5분 버티기가 힘들다.

[리뷰] 불멸의 연인, 1995 (스포주의)

Mon, 23 Feb 2026 13:00:01 GMT

연휴 기간에 우연찮게 베토벤을 들어봐야 겠다는 생각을 하다 베토벤 영화를 두 편 보게 됐다. 그 중 한편이 불멸의 연인. 베토벤은 평생을 독신으로 살았다. 하지만 연인이 아예 없었던 것은 아니었다. 그가 사랑한 대부분의 여인이 귀족이었고 신분 차이 때문에 결혼까지는 이르지 못한 것으로 보여진다. 월광 소나타를 헌정한 줄리에타 귀차르디, 엘리제를 위하여의 원 주인공으로 생각되는 테레제 말파티, 그리고 그의 사후 편지에서 발견된 누군지 특정되지 않은 불멸의 연인이 있다. 영화는 이 불멸의 연인을 찾아서 떠나는 미스테리 스릴러다. 다음은 인공지능이 정리한 베토벤의 연애사(?!)다. 영화를 보고 싶은 사람은 여기 까지만 읽고 영화를 보기를 추천한다. 다음 내용은 영화에 대한 스포 그잡채.

불멸의 연인 (Immortal Beloved): 음악사에서 가장 유명한 미스터리 중 하나이다. 1827년 베토벤이 세상을 떠난 후, 비서 안톤 쉰들러가 그의 책상 속 숨겨진 칸에서 연필로 쓴 10페이지 분량의 연애편지를 발견했다. 1812년 7월 6~7일 이틀에 걸쳐 쓰인 이 편지에는 받는 사람의 이름 없이 '불멸의 연인에게'라고만 적혀 있었다. 200년이 넘도록 수신인의 정체는 밝혀지지 않았으며, 현재 학자들은 안토니 브렌타노와 요제피네 브룬스비크를 가장 유력한 후보로 보고 있다.

줄리에타 귀차르디 (Giulietta Guicciardi): 〈월광 소나타〉의 헌정을 받은 인물이다. 1800년경부터 베토벤의 피아노 제자였으며, 베토벤은 사랑에 빠져 청혼까지 했다. 줄리에타 본인도 받아들일 의향이 있었으나, 부모가 지위와 재산이 없다는 이유로 결혼을 금지했다. 줄리에타는 1803년 갈렌베르크 백작과 결혼하여 나폴리로 떠났다.

테레제 말파티 (Therese Malfatti): 베토벤의 피아노 제자로, 베토벤이 청혼했으나 말파티 가문이 신분과 현실적 이유를 들어 거절했다. 1867년 음악학자 루트비히 놀이 테레제의 유품에서 발견한 악보를 출판하면서, 베토벤의 악필로 인해 헌정 문구를 '엘리제를 위하여'로 잘못 읽었다. 원래는 '테레제를 위하여'였다는 설이 가장 유력하나, 엘리자베트 뢰켈 등 다른 후보도 있어 완전히 확정되지는 않았다.

-- Opus 4.6

이 영화는 불멸의 연인 편지까지만 팩트에 기반하고 나머지는 일부 사실과 엄청난 작가의 상상력을 동원해서 연인을 추정한다. 결론만 본다면 베토벤 측에서 명예 훼손으로 고소해도 되지 않을까 싶은 정도. 왜냐하면 연인으로 지목한 대상이 다름아닌 동생의 아내이기 때문이다. 영화 줄거리만 본다면 다음과 같은 빌드업이다. 1) 베토벤과 조안나는 밀애 관계였다. 2) 조안나가 베토벤의 아이를 임신한다. 3) 둘은 특정 지역 호텔에서 비밀리에 만나기로 한다. 4) 베토벤의 마차가 진창에 빠져 약속 시간을 못 맞추게 된다. 베토벤은 편지를 남긴다. 4) 호텔 주인은 그걸 조안나에게 직접 전달하는 것이 아니라 음식 쟁반 아래 깔아서 전달한다. 5) 조안나는 음식을 보자 입덧이 올라와서 편지는 보지도 못하고 호텔을 떠난다. 오지 않은 베토벤을 보며 자신을 버렸다고 오해한다. 6) 호텔에 늦게 도착한 베토벤은 그녀가 떠난 걸 알고 미쳐 날뛴다. 7) 이후 조안나는 베토벤의 동생의 고백으로 친동생과 결혼한다. 8) 베토벤은 그런 그녀를 평생 저주하면서 살아간다. 9) 동생 사후에는 조카 양육권으로 조안나와 지리한 법정 소송도 벌인다. 10) 죽기 직전에야 양육권을 다시 조안나에게 돌려주는 문서에 서명한다.

이 중 실제 사실로 추정되는 건 불멸의 연인에 대한 편지가 남아 있었다는 것. 그리고 조카인 칼 베토벤의 양육권으로 실제로 제수씨와 법정 소송을 했었다는 점 정도다. 그럼에도, 음악을 몰라도 재미있게 볼 수 있는 영화였다.

[일상] 2026년 1월의 잡담

Wed, 28 Jan 2026 16:16:09 GMT

#0

주로 윈도우 개발을 하는데 작업 피씨를 리눅스로 전환했다. 내가 코딩할 일이 거의 없다는 의미. ai 툴들이 대체로 리눅스에서 더 잘 동작해서 wsl 쓰다가 윈도우를 쓰는게 아니라 wsl을 쓰는 느낌이라 넘어옴. 슬랙웨어에서 점프한 사람이 경험하는 2026 리눅스 데스크탑 환경은 그야말로 상전벽해.

디아4가 별 설정 없이 윈도우만큼 잘 돌아간다. kvm으로 gpu 패스스루 쌩쑈하며 돌려봤는데 그냥 스팀으로 네이티브 리눅스로 돌리는 게 더 성능이 좋은듯. 실제 체감도 리눅스 네이티브는 윈도우 네이티브랑 별차이를 못 느낀다. kvm gpu 패스스루는 간간히 랙발생.

2026-01-12

#1

요즘은 진심 코인이 젤 문제아. 수익 코인이 다 까먹고 있다. 국장이 우등생인거도 웃기지만 코인이 어쩌다 이 지경이 된건지.

2026-01-21

#2

인생 낭비라던 sns에서 평범한 직장인 급여보다 높은 소득을 얻는 사람들을 보니 묘한 생각이 든다. 모두가 인간의 관심을 끌기 위해 무한 경쟁하는 세상. 바야흐로 관심을 채굴하는 시대가 아닌가 싶기도.

2026-01-21

#3

최근 AI 발전 속도를 보면 컴공 기초에 깊게 투자하는 건 시간 낭비 같다. 아는 만큼 통제할 수 있다, 라는 논리도 알겠지만, 이 속도면 1-2년 뒤에도 그 말이 통할까 싶다. 바이브 코딩으로 제품을 더 많이 만들어 보는게 roi가 더 좋지 않을까 싶다.

굳이 기초에 투자한다면 읽기, 쓰기 능력에 투자할 것 같다. llm 시대엔 국어 능력이 특히 중요해진게 아닌가 싶기도. 돌고돌아 국영수인가?!

2026-01-23

#4

바이브 코딩 창업 바이브는 여돌 지망생이 장원영 카리나 꿈꾸는 거랑 비슷한 확률이라는 생각. 시장은 생각보다 효율적이고 냉정하다.

2026-01-24

#5

주화입마에 빠진 현상황. 개발을 돕기 위해 ai를 쓰는 게 아니라 ai를 위한 ai를 쓰는 게 아닌가 싶기도. https://x.com/gregisenberg/status/2015180689335812480

2026-01-26

#6

6년 근속한 제법 괜찮은 20대 청년 개발자가 퇴사했다는 이야기를 들었다. 사유가 코딩은 이제 노답인 것 같다고. 말렸지만 안됐다는 전말. 전망보고 선택하는 거도 좋지 않지만, 전망 보고 포기하는 거도 그닥이라는 생각.

최근 몇 년 사이 코딩에 대한 전망이 바뀌는 과정만 봐도 현기증이 난다. 누가 2026년에 코딩이 이렇게 찬밥될 줄 알았을까? 과거를 보면 미래는 우리 예측과는 다를 확률이 높다. 2035년에 과연 배관공 롱, 프로그래머 숏한 선택이 맞았을지가 궁금한 요즘.

현시점 코딩 에이전트의 최대 강점이라면 인간이라면 감히 엄두도 못낼 단순 노가다 반복 작업에 있는게 아닌가 싶다. 파일을 한 수백개쯤 일일이 열어서 확인하고 노가다해야 하는 작업에 투입해보면 진심 돈값한다는걸 느낀다. 지난 20년간 아무도 감히 엄두조차 못냈던 작업을 2일만에 끝냄.

2025-12-08

#2

연말 송년회 자리에서 느낀 점은 인공지능 주화입마가 많아졌단 느낌. 뭐든지 균형을 찾는게 중요하지 않나 싶다. 그리고 늘 그렇지만 은탄환은 없다.

2025-12-08

#3

쓰면 쓸수록 gpt 구관이 명관이다. 5.2가 기대되는. claude max결제해서 빡쎄게 몇일 돌려봤는데 뭔가 요란한데 결과물은 황망한 경우가 많은듯. 이때 해결해준거도 gpt가 잘못된 코드를 짠 건 아니고 보안 규정상 코딩해 줄 수 없다는거였다. 실상 짜주면 위험한 코드기도 했다. https://x.com/codemaru/status/1994333678000914656

2025-12-09

#4

올초에 딥싴 여파가 한창일때 뽕 맞아서 서버용 ddr5 64gb 24개를 샀었다. 해외 직구한 보드와 씨퓨는 불량이 있었고, 몇달에 걸쳐 조립했지만 속도는 생각보다 처참했다. 채팅하고 놀만한 수준은 되는데 작업시키긴 하세월. 램값 올라서 램만 중고로 팔았는데 수익률이 57%. 주식, 코인보다 낫다.

2025-12-09

#5

9년된 저장소, 그사이 제품이 6개가 더 추가됐다. 중구난방일 수 밖에. 연말을 맞아 대대적인 리팩토링을 하고 있는데 리팩토링이 참 그렇다. 뭔가 엄청나게 힘들여 했는데 결과물은 똑같은?! 약간 현타가 오기도. 그럼에도 해야겠지?! 10년은 더 존버해야 할테니.

비워야 채울 수 있다. 리팩토링을 하면 이말이 참 실감난다.

2025-12-11

#6

인공지능이 근 20년 전에 내가 만든 쓰레기를 환골탈퇴시켜 새 코드를 만들었다. 리뷰를 시켰더니 쓰레기같지 않다고 최대한 쓰레기같이 만들어 버리는 수정을 한 리뷰어. 앵커링 효과가 무섭기도 하고 인간의 커뮤니케이션은 참 어렵다는 생각이 많이 든다.

2025-12-11

#7

자백의 대가 다봤다. 간만에 집중해 본 드라마. 도깨비 나올때만 해도 김고은 캐스팅이 이해가 안됐는데 지금은 충무로의 대본이 모두 그녀에게 간다는 게 이해되는 작품이었다.

2025-12-18

#8

개이듴 ㅎㅎ https://x.com/lessislessxxx/status/2004103375227695354

2025-12-26

[일상] 2025년 11월의 잡담

Fri, 28 Nov 2025 18:12:56 GMT

#0

거짓말이 거짓말을 부르는 것처럼 어떤 잘못된 설계 선택은 다른 잘못된 선택을 계속 강요 받게 만든다. 해결하려고 땜빵을 추가하면 그 땜빵 때문에 또 예외 케이스가 더해지는 악순환. 레거시 때문에 이제와서 잘못을 돌릴수도 없다. 20년 가까이 된 프로젝트의 말로가 이런건가 싶기도.

2025-11-04

#1

회사 직원이 매뉴얼 교정 및 번역 도구를 만들었다. 폴더 구조 바꾸느라 귀찮아서 이미 돌린 결과 버리고 걍 새로 돌렸더니 어제 96불. 넘 많이 나와서 모델 싼걸로 변경해서 돌리니 오늘 6불 사용. 걍 복붙 했어야 하나 싶은 생각이. 물론 사람이 했다면 한중일영 4명 붙어서 2-3달은 걸렸겠지?!

2025-11-06

#2

인공지능으로 개발이 나락가니 운영이 상대적으로 귀족된 느낌. devops가 아니라 opsdev같은 느낌? 어찌될지 모르는게 세상 일이라지만 뭔가 격세지감이...

2025-11-07

#3

베르나르 베르베르 인생책으로 슈테판 츠바이크의 체스 이야기가 있길래 봤는데, 베르나르 베르베르 작품만큼이나 나랑은 결이 안 맞는 느낌. 끝에 해설 보니 유명한 작품이기는 한 것 같은데 뭐징?! 싶었다.

2025-11-09

#4

손실다 만회하고 수익났다고 고맙다고 연락와서 오랜만에 만났다. 8개월 수익률이 51%, 청출어람인가 싶은? 요즘은 13f 따라사는 매매법에 빠져있길래, 벌었으면 적당히 팔고 나오라고했지만 원금오면 주식은 쳐다도 안본다던 초심은 이미 없었다. https://x.com/codemaru/status/1893513760964248035

구글 시트를 하나 만들어줬었는데, 시트 신봉자가 돼 있었다. 소소한 성공 경험도 중요하지만 자극이 너무 세면 외려 역효과가 나기도 한다는 걸 느꼈다. 하도 이거저거 얘기해서 시트를 업그레이드해줬다. 도미노를 알려줬지만 그 친구에게 시트는 이미 어떤 종교적인 느낌.

2025-11-12

#5

쓰잘때기 없는 코딩 강좌 들을 시간에 http://agents.md 다듬는 법이나 배우자. 집값을 근로소득이 못 따라잡듯 코딩 공부 백날 해봐야 인공지능 발전 속도를 이길 수가 없다. 그래도 정 하고 싶으면 github가서 그냥 유명한 오픈 소스 코드를 읽는게 훨씬 생산적일듯.

2025-11-13

#6

진심 추석이 고점이었던 것인가?! 떨어지는 각도가 예사롭지 않다. 에브리씽 랠리라며 호둘갑 떨때 조심했었어야하는건가 싶기도 ㅎㅎ

2025-11-18

#7

이 모델이 코딩 잘하니 저 모델이 더 좋니 하는게 인공지능 시대의 새로운 종교 논쟁이 아닌가 싶다. 걍 취향껏 쓰자. 말려들면 답도 없다.

2025-11-19

#8

새로운 길을 가기에는 전 이미 반대 방향으로 너무 멀리 왔습니다.

그럼 다시 원점이네요. 트레일은 원형이니까.

나의 완벽한 비서 ep.01

진심 무슨 공식 있나 싶을 정도로 k드라마 표준 공식 그 잡채인 드라마. 그 모든 단점을 커버하는 한지민의 비쥬얼이란.

2025-11-23

#9

fsd 출시 된다길래 찍먹해볼까 싶어서 모델x 리뷰를 좀 봤는데. 모델y 적용될때까지는 참는게 좋을 거 같다는 생각이 들었다. 1억 넘는 차를 원래 그래요, 어쩔 수 없어요로 팔아도 되는건가?!

https://n.news.naver.com/article/092/0002399938?cds=news_edit

2025-11-26

#3

나는 당신이 부럽다. 매순간
당신은 나를 떠날 수 있다.

나는 나를
떠날 수 없다.

나는 할 수 없다, 안나 스위르

2025-10-04

#4

젤 똑똑한 애들이 울세라 쏘고 있어서 미래가 없다는데, 넷플 틱톡에서도 똑같은 얘기가 있었다. 로켓 과학자 할 애들이 거기 가서 추천 알고리즘 짜고 있다는 말. 좋은지 나쁜지 알기란 생각보다 어렵다.

2025-10-05

#5

은중과 상연 중간에 삼각관계 지나치게 끌어서 포기하려 했으나 참고 끝까지 봤는데 결말은 생각보다 나쁘지 않았다. 우리 나라도 어여 빨리 안락사가 합법화되기를 기원한다. 상연 말처럼 고통을 거부할 권리는 있어야 하지 않나?

2025-10-05

#6

오직 자유가 삶의 목적이라면
평생 자유롭지 못할 겁니다

쇼군 ep.05

꽃은 지기 때문에
꽃입니다

쇼군 ep.09

추석 기념으로 뒤늦게 쇼군을 정주행 했다. 추천인 들의 말이나 제목이랑 다르게 쇼군이 아니라 거의 안진과 마리코가 주인공 아니었나 싶었던 드라마.

2025-10-07

#7

인공지능을 떠나 의외로 요즘 발전이 대단하다 생각되는 분야가 간편 식품. 에프와 냉동의 조합은 특이점을 넘은듯. 이러니 피자집이 장사가 되겠나 싶다. 족발, 보쌈도.

2025-10-10

#8

어쩔 수가 없다 보고 드는 생각이 해고가 저정도로 충격적인 사건인가라는 생각? 워낙 어릴 때 한 번 당해본 게 전부라 감이 없다. 한날 동시에 단체로 해고 당하고 함께 창업을 했었다. 해고시킨 업체보단 잘되겠지라며. 이것도 it 장점인듯. 장치산업은 자본이 없으면 애초에 창업이 불가능하니.

2025-10-10

#9

부의 가장 강력한 정의는 ‘무엇을 가지고 있느냐’가 아니다. 진짜로 중요한 것은, ‘가진 것’과 ‘원하는 것’ 사이의 간극이다. - 소비의 기술, 모건 하우절

2025-10-10

#10

x, if not y

gpt x며, 아니 어쩌면 y이기까지 하는
claude x거나 y인
grok x거나 아니면 y인
gemini y까지는 아니더라도 x인

흥미롭게도 같은 문장이 정반대의 뉘앙스를 가질 수 있는 영어의 재미있는 예시죠! - claude

전혀 흥미롭지 않은데, 뭔 이런 거지발싸개같은 표현이 있지 싶었다.

한국어 예시를 보고 바로 납득됨. 표현이 그럴수도 있지 ㅎㅎ

"그 사람 참 대단하네"

해석 1: 진짜 훌륭하다 (칭찬)
해석 2: 어이없다, 황당하다 (비꼬기) - 억양과 문맥에 따라

"괜찮아"

해석 1: 정말 좋다
해석 2: 그냥 참을 만하다
해석 3: 사실 별로다 (거절의 완곡 표현)

2025-10-12

#11

엔비디아 인턴 출신으로 북미 취업을 준비하던 친구가 큰업체 두군데서 뱅기 숙식 바우처까지 제공해준다는 면접 단계까지 갔는데, 럼프형 비자 폭탄으로 취소됐다는 이야기를 들었다. 비자 가격이 1억으로 올랐다고. 진심 운9기1의 리얼 월드가 아닌가 싶었다.

2025-10-13

#12

탐라에 코인 청산 관련 간증글을 보니 몇년전 지인의 지인이 코인 투자로 2000억 벌었다는 얘기가 생각난다. 이후 테라루나 사태로 99% 날렸다고. 그정도 벌면 다른 안전한데 분산 투자할법 하지 않았냐고 말했더니, 친구왈 그런 마인드면 2000억 근처도 못간다고. 하지만 곱하기 0 한번이면 나락인걸.

2025-10-13

#13

오늘도 gpt와 gemini가 나의 무지를 깨쳐주고, 코드를 작성해주고, 검증하는 법도 알려주었다. 정말 멋진 신세계가 아닌가 싶다.

2025-10-13

#14

쿠팡의 다이나믹 프라이싱에 결국 굴복했다. 인간이 알고리즘을 어케 이기나 싶다. 큰돈은 아니지만 주문 실수로 날린 돈이 아까운 건 어쩔수가 없는듯 ㅠㅜ

2025-10-14

#15

i can do this - 스토어웨이, 2021

재밌게 봤는데 네이버 평점보고 깜놀. 다들 생각하는 게 많이 다르구나 싶었다. 산소 가지러 가는 장면이 백미였다. 별 거 아닌데 나름 긴장되는.

2025-10-19

#16

인생을 결산하는 것은 돈이 아니라 전반적인 행복이다. 그러므로 균형을 유지해야 한다. - 전설의 프로 트레이더 빅, 빅터 스페란데오

2025-10-27

#17

대기업 25년차 부장에, 서울 아파트 자가에, 애 대학까지 보낸 인생은 위대한게 맞다고 본다. 사실 애 키워보면 그냥 멀쩡하게 밥벌어 먹고 사는 일반인으로 키워내는 것만 해도 위대한 게 아닌가 싶다.

2025-10-29

#18

시험을 못 봤을때 어떠셨어요? 학교 생활 다 망친 것 같고 세상이 끝난 것 같지만, 나중에 되돌아보면 그때 왜 그렇게 고민했을까, 하는 생각이 들죠. 똑같아요. 회사에서 은퇴했다고 해서 삶을 다 은퇴한 게 아니예요. 사기 한 번 당했다고 해서 인생이 막을 내리는 게 아닙니다.

서울 자가에 대기업 다니는 김부장 이야기

상사 3명을 합쳐서 묘사하면서 시작된 이야기라는데 관찰 불가능한 부분은 너무 퐌타지 스러움. 특히 아내가 유독 지나치게 비현실적인 느낌. 김부장이 내 또래로 설정된 게 묘하게 씁쓸하기도.

2025-10-30

#19

악어에게 물렸을 때 살아남는 유일한 방법은, 다리 하나를 내주고 빠져나오는 방법뿐임을 기억하라. 이 원리를 시장에 적용하면 “잘못을 깨달은 순간 포지션을 청산하라!”가 된다. - 전설의 프로 트레이더 빅, 빅터 스페란데오

뉴진스 기사를 보니 이 문구가 생각났다. 소송 결과나 손배 위약금 따위를 다 떠나서 천금같은 시간을 다 날리고 있는걸 보면 참 안타깝다는 생각.

2025-10-30

#20

전형적인 쇼비지니스라 생각되는 젠슨황 깐부치킨 회동이 엄청나게 바이럴 되는 걸 보니 돈만 많고 아무도 나를 몰랐으면 좋겠다는 밈이 절로 생각난다. 드라마에서 재벌 회장님이 요플레 뚜껑 핥는지 아닌지 궁금해 하는 씬을 오바라고 생각했는데 이번에 보니 현실적이었단 생각.

2025-10-31

[일상] 함께해서 인상적인 날 (feat. KOF98 & 마인크래프트 던전스)

Sat, 04 Oct 2025 11:00:01 GMT

KOF98을 플레이하는 아드님

인생이 무료하던 시점 어릴 때 생각이 나서 월광보합 파이널2를 산 적이 있었다. 사서 한두번 하다가 내가 생각했던 느낌은 아니라 한구석에 방치돼 있었다. 추억이란게 보통 그렇다. 생각할 때는 그럴듯하지만 막상 다시 마주해보면 그 느낌은 아닌 것이다. 그래서 기억만으로 간직하는 게 더 좋은건지도.

무튼 그러다 최근 애들 방을 새로 만들어주면서 작은 애 방에 공간이 있어서 방치된 모니터에 연결해서 레트로 게임기를 만들어줬다. 그리고 킹 오브 파이터즈 98을 아들과 함께 했다. 사실 애는 뭐가 뭔지 하나도 모른다. 그냥 막 누르는 거. 기술을 알려준다고 해다 필요 없다는 대답. 그럼에도 아들은 몹시 신나했었다. 어쨌든 그렇게 둘이 함께 즐거운 한때를 보냈다. 2025.9.27은 몹시 인상적인 하루였다.

추석 연휴 즈음 컴퓨터가 고장나서 컴퓨존에 수리를 맡기면서 애들 컴퓨터를 사주면 좋겠다는 생각이 들어서 배그 정도 돌아가는 컴퓨터로 조립을 했다. 굴러다니는 잡동사니 부픔이 많은 줄 알았는데 죄다 오래된 것 밖에 없어서 결국 쓸 수 있었던 건 ssd와 파워 뿐이었다. 심지어 파워도 400w라 간당간당한데 그래픽 카드가 좋은 건 아니라 될 거 같아서 그냥 사용했다. 램도 4g 3개가 굴러다니는 게 있어서 쓰면 되겠다 싶었는데 gpt한테 물어보니 ddr3라 호환이 안된다는 말. 어쨌든 어찌저찌 10만년만에 조립을 해서 동작시켰다. 몹시 아이들이 좋아할 줄 알았는데 생각보다 반응은 시큰둥했다. 새로운 컴퓨터로는 애들과 새로운 게임을 함께 했다. 마인크래프트 던전스. 애들이 제일 좋아하는 게임이 로블록스, 마인크래프트다. 하다 보니 언젠가 얘들이 커서 자식을 가진다면 그때는 마인크래프트를 함께하면서 나같은 생각을 하겠다 싶었다.

천하를 다 가진 것처럼 보이는 데이비드 베컴은 인생에서 가장 기억에 남는 순간 중 하나로, 아내가 자신이 먹는 음식을 함께 먹었던 일을 꼽았다. 아내 빅토리아 베컴은 25년째 생선과 찐야채만 먹는다고 한다. 단 한 번 임신했을 때 베컴이 먹는 걸 같이 먹어줬다고 한다. 별것 아닌 일처럼 들리지만, 어쩌면 우리는 무엇이든, 내가 좋아하는 그 무언가를 사랑하는 사람과 함께하는 그 순간 자체를 가장 좋아하는건지도 모르겠다.

[일상] 2025년 9월의 잡담

Tue, 30 Sep 2025 21:59:45 GMT

#0

전 윤지호 센터장이 살림살이 괜찮은데 강의 팔이한다고 뭐라하는 사람들한테 하소연하는 글을 남긴걸 봤다. 지난 번 저속노화 선생님도 그렇고 우리 나라는 이상하게 남이 돈벌이 하는데 감나라 배나라하는 경향이 있는 것 같다. 선비의 나라 dna는 노답인듯.

2025-09-06

#1

선주문 후감상 예정. 우리 나라도 이런 책을 내는 분들이 많아졌으면 좋겠다는 바램. 사실 회고는 성공담보다는 실패담에서 배울 게 더 많은 게 아닌가 싶기도 하다. https://x.com/jojoldu/status/1964165890603151475

2025-09-06

#2

한남더힐 전용70펑. 매물이 주로 130억, 취득세 4.5억, 종부세포함 보유세 연 0.6억, 월세를 줄 경우 시세 2억/0.25억. 이 엄청난 세금을 감안했을 때 이게 수익이 나나 싶어보이는데 재미삼아 인공지능에 분석을 시켜 보았다.

#19

너 사람 동정해. 그게 참 사람을 비참하게 만들어. - 사미귀, 2025

2025-09-30

[일상] 메멘토 모리를 되새기며 (feat. 교통사고)

Sun, 21 Sep 2025 13:00:01 GMT

#0

애들 여름방학 때 본가에 가다 큰 교통사고가 날 뻔했다. 고속도로 1차로로 주행 중이었는데 앞쪽에 사고가 나서, N차 사고가 나고, 또 내 앞차가 N+1차 사고를 낸 상황이었다. 나도 급브레이크를 밟았지만 아슬아슬하게 사고가 나거나 직전에 멈출 것 같은 느낌이었다. 하지만 백미러로 본 내 뒷차는 거의 백프로 추돌할 것 같은 생각이 들었다. 전에도 이런 종류의 사고가 두 번 난 적이 있었는데 나는 모두 멈췄지만 뒷차가 모두 내 차를 박았다. 그럼에도 여기서 나의 합리적인 조치는 최선을 다해 멈추고 뒷차가 박으면 그냥 사고를 당하는 것이었다.

하지만 애들이 타고 있어서 그랬는지 미친 짓을 해버렸다. 바로 핸들을 틀어서 옆차선으로 간 것이다. 물론 내가 옆 차선을 확인하고 차가 없고, 뒤에서 오는 차와의 거리도 안전하다고 판단한 다음 틀었다면 잘한 일이겠지만 나의 좌뇌는 그것을 확인하지 않았다. 아마 애들이 타고 있어서 사고는 피해야 한다는 생각으로 나의 무의식이 그 미친 짓을 한 것으로 보인다. 하지만 우뇌는 확인했을지도 모르겠는 게 옆 차선은 다행히 비어 있었다. 다만 고속도로라 뒤에서 오는 차가 있었고, 그 속도가 맹렬했을 뿐이었다. 행운의 여신이 나를 아직 버리지 않은 것은 그 뒤에서 오던 아반떼 차량의 운전자가 빠른 속도에도 불구하고 제법 능숙하게 사고를 피해 주었다는 점이다. 그가 갓길로 주행해서 우리는 2차로 고속도로에서 잠시 3개 차선으로 주행을 했다. 이내 나는 미친 짓을 한 걸 깨닫고 1차선에 사고 난 차량들 사이로 다시 돌아와서 멈췄다. 내가 계속 주행을 했다면 아반떼도 사고를 피하기는 힘들었다. 왜냐하면 전방 갓길에는 그전에 사고 난 차량들이 또 널브러져 있었기 때문이다.

수십 초의 아주 짧은 순간에 이 모든 일이 벌어졌다. 얌전히 있었으면 사고가 나더라도 그렇게 큰 사고는 아니었을 수 있다. 하지만 핸들을 트는 바람에 재수가 없었다면 정말 큰 사고가 날 뻔한 것이다. 사고난 차량들 사이에 멈추고 보니 대략 전방 갓길에 널브러린 차량을 포함해서 6-7대 가량이 사고가 나 있었다.

운전을 시작한 이래로 이렇게 큰 사고가 날뻔한 경험은 처음이이었다. 그간 운이 좋았다는 생각도 들었다. 오늘은 정말이지 조상님들이 도왔다는 생각도 들었다. 그전에 좋지 않은 소식을 전화로 들었던 터라 마음이 불편했는데, 그 순간 웃기게도 이 세상 모든 것에 감사함이 느껴졌다. 특히 그 아반떼 차량 운전자에게 너무 고마웠다. 당연하겠지만 남은 길은 졸졸 운전했고, 올라오는 길도 크루즈로 얌전히 올라왔다.

#1

그 기억이 너무 강렬해서였을까? 여운이 며칠은 더 갔다. 그저 살아 있다는 게 고마웠고, 아이들이 무사해서 다행이었다. 그리곤 이내 깨달았다. 아등바등 스프레드시트 쳐다보며 전체 수익률이 몇프로니, 내부 수익률이 몇프로니, 금리가 어떠니, 고평가니, 저평가니 따져본들 죽음 앞에서는 다 부질없는 일이겠구나 싶었다. 인간의 가장 큰 모순이 천년만년 살 것처럼 굴다가 결국은 살아 보지도 못한 것처럼 죽는 일이라고 하지 않았던가?! 또 잡스의 말처럼 죽음 앞에서는 모든 게 초연해진다는 말도 새삼 공감됐다. 우리가 집착하며 살아가는 그 모든 것들이 죽고 나면 다 무슨 소용일까 싶은 것이다.

그리고 또 그런 생각이 들었다. 과연 내가 죽는다면 마지막 순간에 나는 어떤 시간을 기억할까? 엄마가 꺼내주지 않던 세발자전거를 혼자 끌고 나오다가 화상을 입었던 날일까? 처음 두발자전거를 혼자 타게 된 날일까? 여름방학 내도록 매일 아빠와 해운대 바닷가에 갔던 날들일까? 처음으로 컴퓨터를 샀던 순간일까? 수능 시험 날일까? 첫 키스일까? 창업해서 제품을 만들면서 고생했던 날들일까? 애들이 태어나던 날일까? 운 좋게 투자로 큰 돈을 벌었던 순간일까? 아니면 실수로 전재산을 날렸던 때일까? 곰곰 생각해보니 모두 아닌 것 같았다.

내 인생을 돌아봤을 때 마지막에 기억할 것 같은 해들은 2000, 2001, 2005, 2006년인 것 같았다. 그 해가 특별한 이유는 뭘까? 20대였기 때문일까? 맞다. 그것도 클 수 있다. 하지만 20대의 다른 해들도 있는데 유독 그 네 해만 떠오르는 이유는 따로 있다. 그 이유는 바로 내 인생 전체를 통틀어서 내 의지대로 오롯이 살았던 날들이 그 해를 제외하고는 없기 때문이다.

우리는 대체로 책임감, 의무감, 또는 주변의 기대나 시선 같은 실상은 내 의지와 다른 것들에 의해서 많은 시간을 보낸다. 내 인생의 대부분의 날들 또한 그런 것들로 채워진 순간이었다. 아마 경우에 따라서는 평생을 전부 그런 시간들로 살아온 사람들도 있을 수 있다. 하지만 어쨌든 나는 돌아보니 저 4년만큼은 내 생각대로 내 맘대로 살았다고 말할 수 있었다. 40년 넘는 인생을 살아 왔지만 실상 몇 년을 살았냐고 물어본다면 그 네 해가 전부가 아닌가 싶기도 한 서글픈 생각이 들기도 했다.

#2

최근에 읽은 책 "실패를 통과하는 일"에는 강철의 연금술사 이야기가 나온다. 이 작품이 명작의 반열에 오를 수 있었던 이유로 작가가 처음부터 최종화에서 할 이야기를 정해 두고 첫 화를 시작했기 때문이라는 내용이 있었다. 우리의 인생도 어쩌면 그럴지 모른다. 끝을 떠올려야 비로소 지금의 삶이 선명해지는 순간이 있다.

우리는 언젠가 모두 죽는다. 메멘토 모리(Memento mori) — 죽음을 기억하라는 말은, 결국 현재를 충실히 더 잘 살라는 뜻일지도 모른다.

통계청에서는 생각보다 재미난 통계를 많이 발표한다. 그런 것 중 하나로 생명표가 있다. 생명표는 한국 사람들의 나이와 성별에 따른 대략적인 기대 여명을 알려준다. 2023년 자료가 최신인데 그 자료에 의하면 나에게 이제 남은 시간은 37년 남짓이다. 살아온 시간이 살아갈 시간보다 한참 많아진 셈이다. 또 그 생명표는 어쨌든 평균이니 나에게는 그만큼의 시간도 없을 확률이 높다. 37년이면 긴 시간 같지만 또 따져보면 이제 나에게는 37번의 여름 뿐이라는 말도 된다. 그렇게 생각하면 뭔가 아쉽기도 하고 매 순간을 소중하게 생각해야겠다는 마음이 들기도 한다.

가을이 온다. 내 인생에서 마흔 번도 채 남지 않은 가을이 오고 있다. 25%의 시간은 아이들에게 저당잡혔지만, 남은 75%의 시간은 내 의지대로 오롯이 살았던 2025년 가을이 되기를 바란다. 그래서 마지막 순간에는 "아, 2025년의 그 가을도 있었지" 하고 미소 지을 수 있기를 희망해 본다.

[소고] 낳음 당했다에 부쳐

Wed, 17 Sep 2025 13:00:01 GMT

#0

SNS를 보다가 요즘 애들 사이에서 유행한다는 낳음 당했다는 말을 알게 되었다. 나는 그 표현을 보면서 요즘 애들은 참 똑똑하다, 라고 생각했는데 SNS 상의 어른들 반응은 대체로 요즘 애들 1) 무섭다 2) 버릇없다 3) 어떻게 그런 말을 4) 우리 애가 그럴까 겁난다와 같이 부정적이었다. 과연 낳음 당했다는 말을 꼭 그렇게만 볼 일일까? 애들이 하는 철없는 말로 치부하기에는 생각보다 거기에는 더 많은 함의가 내포돼 있는 건 아닐까 싶었다.

#1

그 표현을 보고 처음 든 생각은 쇼펜하우어였다. 요즘은 좀 시들해졌지만 한동안 서점가를 쇼펜하우어가 점령했던 시기가 있었다. 내가 보기에 낳음 당했다도 일정 부분은 거기서 영향을 받은 게 아닌가라는 생각이 들기도 했다. 왜냐하면 쇼펜하우어의 철학적 사유의 근간이 인생을 고통으로 보고 낳음 당했다와 유사한 논지를 피력하기 때문이다.

쇼펜하우어는 이렇게 말한다.

생존한다는 것은 누구에게든 자신에게 부과된 강제노동을 치르는 것과 같다. 이러한 부채를 계약한 것은 성적인 쾌락을 얻는 것을 대가로 하여 그를 낳은 사람이다. 이처럼 한 사람이 즐긴 대가로 다른 한 사람은 삶을 살아야 하고 괴로워해야 하며 죽어야 하는 것이다.

-- 사는 게 고통일 때, 쇼펜하우어, 박찬국

위 내용만 보면 쇼펜하우어의 기본적인 생각이 요즘 애들이 한다는 낳음 당했다는 말과 놀랍도록 유사하다. 그리고 나는 저 기본적인 사고의 흐름이 그렇게 잘못됐다고 판단하지 않는다. 부모로써 자식에게 기본적으로 잘해줄 수 밖에 없는 이유도 일종의 저런 좋류의 부채 의식이 무의식 중에 깔려 있는 게 아닌가 싶기도 하다.

#2

쇼펜하우어만큼 직접적이지는 않지만 실존주의 철학도 낳음 당했다와 유사한 지점이 있다. 하이데거는 인간은 이 세계에 던져진 존재라고 표현했다. 이 말은 우리가 태어날 시대, 장소, 가정, 언어 같은 조건을 스스로 선택하지 않았다는 뜻이다. 우리의 의지와 무관하게 우리는 이미 이 시간, 이 공간, 이 세계 속에 들어와 있다는 점이다.

게임 캐릭터를 만들어서 입장하는 세계를 상상한다면 아마 지금의 나를 그대로 캐릭터로 만들어 들어오고 싶은 사람은 많지 않을 것이다. 그런 점에서 실존주의가 말하는 이미 주어진 조건과 아이들이 말하는 낳음 당했다는 감각은 분명 접점이 있다.

#3

카뮈는 던져짐과는 조금 다르게 부조리란 개념을 말한다. 부조리는 이 세계는 내가 어떠한 의미를 찾으려 해도 응답하지 않는 것을 의미한다. 예컨대, 성실하게 일했는데도 회사 사정으로 하루아침에 구조조정을 당한다거나, 선하게 살아 보상받고 싶었지만 그 보상은 오지 않는다거나, 오래 마음을 쏟았지만 상대의 감정은 끝내 돌아오지 않는다거나, 온 힘을 들여 만든 작업은 조용히 사라지고, 가볍게 한 결과물이 우연히 주목받는다거나 하는 일들이다. 간절히 기도하고 약속해도 세계는 아무 대답을 주지 않는다.

이 세계 자체는 철저하게 나의 의지와는 아무 관련이 없이 돌아가는 것이다. 그러니 인간의 입장에서 세계를 바라보면 부조리해 보일 수 밖에 없다. 왜냐하면 거기엔 어떠한 의미도 없기 때문이다.

그리고 이런 부조리의 감각은 아이들이 말하는 낳음 당했다, 와도 일부 맥락을 공유한다. 둘 다 내가 선택하지 않은 조건에서 출발하고, 내가 세운 의미나 기대가 세계에서 아무 보증도 받지 못한다는 체감을 드러내는 부분이 있기 때문이다.

#4

이런 철학적 개념들을 쭉 살펴보면 애들이 말하는 낳음 당했다는 말이 그저 버릇없이, 감히 부모한테 어떻게 그런 말을처럼 가볍게 넘길 말은 아니지 싶다. 그들은 지금의 상황을 선택하지 않았고 그 상황 속으로 내던져졌고, 그들에게 현 상황은 한없이 부조리하고, 아무 의미도 없어 보일 수 있는 것이다. 심지어 이런 상황을 만든 장본인들은 다름 아닌 순간의 쾌락을 선택한 그들의 부모처럼 보이기도 한다. 그 모든 걸 한마디로 퉁치면 결국 낳음 당했다가 되는 셈이다.

그렇다면 우리가 낳음 당했다고 말하는 아이들에게 해줘야 할 이야기는 무엇일까? 내던져진 상황에서, 부조리한 세계에서, 또는 고통 뿐인 삶을 어떻게 생각하고 살아나가야 하는 것인지를 알려줘야 하는 건 아닐까? 쇼펜하우어도, 하이데거도, 카뮈도 각자의 답을 했지만 사실상 정답은 없다. 어쩌면 답을 말해주기 보다는 상황 인식을 공감해 주는 게 더 큰 위로가 될지도 모른다. 왜냐하면 그걸 듣는 부모조차도 부조리한 세계 속으로 그저 던져졌고, 그 결과로 고통인 삶을 살아가는 똑같은 사람이니까 말이다.

[소고] 용꼬리 vs 뱀머리, 당신의 선택은?

Sat, 13 Sep 2025 13:00:01 GMT

#0

전투에서 이기는 것보다 전쟁에서 이기는 게 중요하다고 한다. 또 나무를 보지 말고 숲을 보라는 말도 있다. 비슷하게 반백년 가까이 살아보니 인생 전체를 보면 세부적인 어떤 노력이나 선택보다는 큰 틀에서의 세계관을 잘 정하는 게 전체적으로는 더 큰 영향을 미친다는 것을 많이 경험했다.

그런 큰 주제 중에 하나가 용꼬리와 뱀머리 논쟁이다. 바닥을 쓸어도 큰 물에서 놀아야 한다는 것이 용꼬리 쪽 입장이라면, 구멍 가게에서 일을 해도 대장질을 하겠다는 것이 뱀머리 입장이라고 할 수 있다. 물론 세상은 이렇게 극단적인 이분법으로 나뉘진 않는다. 대부분은 그 사이 어떤 지점에서 선택을 하게 된다. 둘의 세계관은 뭘 더 중시하겠냐는 것을 나타낸다고 할 수 있다.

나는 태생적으로 뱀머리 주의자였다. 일단은 경쟁 환경에 노출되는 것을 별로 좋아하지 않고, 선택권이 나에게 없는 것을 선호하지 않았다. 죽이되는 밥이되든 내가 선택하는 것을 좋아한다. 그리고 자유의지가 실제로 존재하든 하지 않든 내가 주도한다는 느낌이 드는 환경을 좋아했다. 그리고 이전 글에서도 밝혔듯이 게이트 키퍼를 좋아하지 않기에 누가 나를 평가한다는 것을 그닥 유쾌하게 생각하지 않았고, 결론적으로 그건 큰 세계로 나가는데에는 장애물이나 다름없었다.

그래서 주변에서 더러 그런 말들을 들었다. 더 좋은 대학을 가지, 더 좋은 과를 선택하지, 더 좋은 회사 취직하지, 왜 그러고 사냐 같은 말들 말이다. 하지만 강철의 연금술사에 나오는 등가교환 원칙처럼 이런 것들이 반대로 가져다 주는 장점도 크다. 일단 스트레스 레벨이 낮아진다. 마음이 평화롭고, 자기 효능감이 커진다. 이게 얼마나 큰지는 나이가 들면 들수록 느낄 수 있다. 왜냐하면 스트레스는 만병의 근원이기 때문이다. 또 추구하지 않아도 자존감이 보충된다.

뭐 발전적이지 않은 사람이라고 비판해도 할 말은 없다. 어쨌든 개인적인 선호가 마음 편한 게 다른 것보다 더 중요하니 말이다. 안그래도 짧은 인생, 불필요한 것들로 스트레스 받으며 살 필요는 없다는 생각이다.

#1

한때 서판교에 살았던 적이 있었다. 내가 살았던 동네 중에는 가장 부자 동네라고 할 수 있는데 여기서도 비슷한 경험을 했다. 다른 건 차치하더라도 주변에서 내가 평소에는 흔히 경험할 수 없었던 장면들이 더러 눈에 띄었던 것이다. 처음 충격을 받았던 게 기사였다. 대체로 기사라는 존재는 드라마 외에는 현실 세계에서는 볼 수가 없었던 나는 그 동네 살면서 숱하게 기사를 만났다. 출근하러 주차장에 가면 항상 말끔하게 차려입고 대기하는 기사님들이 계셨다. 그 정도는 그냥 넘겼다. 같은 라인에 사장님이 사는구나 싶었다.

애들 어린이집을 등원시켜 주면서도 그런 일들이 반복되니 조금 신기했다. 한날 애들 생일 선물을 잘 챙겨주는 어머니랑 등원 시간이 겹쳐서 만나게 됐는데 일단 아주 고급 차를 가지고 온 것은 워낙 흔한 일이라 그러려니 했다. 그런데 애들을 맡기고 차를 타는데 기사가 나와서 문을 열어 주는 걸 보고는 뭐지 싶었던 것이다. 심지어 그분은 전업주부였다. 그때 어렴풋이 느꼈다. 아 이동네 분위기가 좀 다르구나.

그러다 결정적인 일이 집 앞 커피숍에서 있었다. 노트북으로 코딩을 하고 있었는데, 목소리가 커서 본의 아니게 옆 테이블 이야기를 듣게 된 것이다. 그 동네 사람들이 대체로 집에 일하는 이모님들이 있다는 건 알았지만 그 다음이 더 가관이었다. 중국어 튜터를 애들 별로 한명씩 고용할지 말지를 얘기하고 있었던 것이다. 그때 결심했다. 아 이동네 살아서 나한테 좋을게 그닥 없겠구나. 그리고 그 해 나는 이사를 갔다. 어쨌든 그 동네는 내가 살기에는 큰 연못이었던 셈이다.

#2

세상은 참 다양한게 나와 정반대의 입장인 사람들도 많다. 한 지인은 애를 예술 중학교에 입학시켰다. 그 집 사정을 알기에 다소 의문스럽기도 했는데, 본인이 하는 얘기를 들어봐도 내 생각과 비슷했다. 학교 입학식에 애를 데리고 갔는데 국산차를 타고 온 것은 본인 밖에 없었다는 얘기였다. 더 심각한 건 그 학교 학비였다. 맞벌이인 그 집 세후 소득의 거의 절반이 그냥 학비로 소진된다고 했다. 물론 별도의 레슨 비용이나 이런 걸 따지자면 훨씬 더 들 것이다. 이렇게까지 뒷바라지를 한다손 치더라도, 애는 아마 그 학교를 다니면 다닐수록 더 많은 격차를 느낄 가능성이 높다. 지인은 동네 피아노 학원은 할 수 있겠지라고 말했지만 내가 보기엔 그걸 하기 위한 투자치고는 너무 큰 게 아닌가 싶었다.

소셜 믹스를 선호하는 사례도 있었다. 강남 고급 주택가에 새로 들어서는 단지의 임대 주택 조건에 본인이 해당한다는 말이었다. 그러면서 모모 회장님 아들과 같은 초등학교에 애를 보낼 수 있어서 좋다는 이야기를 했다. 워낙 오래전 일이고 그다지 친분이 깊은 사이는 아니라 네네 했는데, 속으로는 다른 생각을 하고 있었다. 왜냐하면 그분이 꿈꿨던 회장님 아들과 어릴 때부터 끈끈한 친구가 되는 그런 환상적인 일이 벌어지기보다는, 현실에서는 <더 글로리> 같은 전개가 펼쳐질 확률이 훨씬 더 높다고 생각하니 말이다. 거기서 사라는 혜정이에게 다 커서 이런 대사를 날린다.

근로소득세 내는 넌 모르는 종합소득세 내는 세계가 있단다, 혜정아.

-- 더 글로리

#3

이런 건 그냥 개인적인 선호나 느낌일 뿐이지 않을까, 이런 세계관의 선택이 뭐가 크게 중요하지, 라고 생각할 수 있다. 여기에 과학적인 뭔가가 있을까 싶은 것이다. 하지만 세상은 넓고 온갖 것들을 연구하는 사람들은 많다. 둘의 세계관 사이에 차이가 있다는 결과를 보여주는 연구들이 있는 것이다. 아웃라이어로 유명한 말콤 글래드웰의 저서 다윗과 골리앗을 보면 관련 내용이 나온다. 몇 가지를 소개해 보면 이렇다.

하나는 대학별로 STEM 전공 기준 졸업생 비율을 조사한 연구다. 흥미롭게도 대학의 순위를 가리지 않고 1/3 정도만 학위를 취득했다는 결과가 나왔다. 이는 상식적으로 이해되지 않는다. 왜냐하면 하버드에 간 꼴지가 이름모를 대학에 들어간 1등보다는 몇배는 똑똑할 것이기 때문이다. 하지만 하버드 꼴지는 학위 취득에 실패했고, 이름모를 대학의 1등은 학위를 취득했다. 저자는 이에 대해서 이렇게 코멘트를 추가한다.

이 '하버드의 얼간이들'은 매우 크고 무시무시한 연못에 사는 작은 물고기다. '하트윅 올스타'는 매우 푸근한 작은 연못에 사는 큰 물고기다. 이공계 학위를 받을 가능성을 결정짓는 데 중요한 것은 단지 당신이 얼마나 똑똑한가의 문제가 아니다. 중요한 것은 교실 안에 있는 다른 학생들과 비교해서 얼마나 자신이 똑똑하다고 느끼느냐 하는 것이다.

-- 다윗과 골리앗, 말콤 글래드웰

또 다른 연구 자료로 우수한 대학을 졸업한 학생들의 연구 업적과 낮은 순위의 학교를 졸업한 학생들의 연구 업적을 비교한 내용이 소개된다. 우수 대학의 상위 1% 학생은 당연하게도 가장 뛰어난 논문 발표수를 자랑한다. 하지만 상위 20%만 되더라도 하위 대학의 상위 1% 학생이 압도한다. MIT의 상위 1% 학생은 평균 논문을 4.73개, MIT의 상위 20% 학생은 평균 0.83개, 상위 45%는 0.12개를 발표했다. 30위 이하 대학교의 상위 1%의 평균 발표 수는 1.05다. 당연히 MIT의 상위 45%가 30위 이하 대학교의 상위 1%보다 훨씬 똑똑한 학생일 가능성이 높다. 하지만 졸업 후의 연구 업적은 하위 대학 졸업생이 오히려 더 높은 것이다. 여기에 대해서 저자는 이렇게 판단한다.

그런데 왜 대학원에 지원할 때까지는 모든 것을 잘해낸 승자였던 다수의 성공적인 학생들이 박사과정 훈련을 받고 난 뒤에는 그토록 별볼 일 없게 되는 것일까? 우리가 학생들을 잘못 길러온 것인가, 아니면 학생들이 우리의 기대를 저버린 것인가?

물론 대답은 둘 다 아니다. 아무도 누군가를 저버리지 않았다. 이 결과는 최상위권 학생들에게는 끝내주는 곳인 엘리트 학교가 다른 모든 학생들에게는 아주 힘겨운 곳이라는 사실을 확인시켜줄 따름이다.

-- 다윗과 골리앗, 말콤 글래드웰

이후 책에서는 다소 파격적인 이야기를 이어가는데 특수 전형 이야기다. 학업 성취 능력과 상관 없이 우대해서 입학시켜주는 정책 이야기다. 이를 먼저 도입한 학교로 하버드를 예로 드는데 그 시발점이 큰 연못의 위험함을 막기 위해서였다는 이야기다. 결국 누군가는 하위 1/4를 해야하고, 그렇다면 자존감을 예체능등 전공과 상관 없는 특수 분야에서 충족한 학생들로 채우려는 목적이었다는 것이다. 결국 냉정하게 달리 말하면 그들은 그냥 다른 학생들의 자존감을 채우기 위한 목적으로 입학시켰다는 말이 된다. 진실이든 아니든 다소 충격적이긴 하다. 그러면서 저자는 사배자 전형을 언급하는데, 그게 과연 도움이 되는 것일지 아닐지에 대한 고민이 필요하다는 말을 덧붙인다.

#4

논쟁적일 순 있겠지만 지금까지의 사례와 연구 결과를 종합해 보면, 많은 경우 '뱀의 머리'가 되는 것이 더 나은 선택일 수 있다는 점을 시사한다. 자신의 능력과 별개로 주변 환경이 주는 압박감과 상대적 박탈감은 개인의 잠재력을 갉아먹을 수 있기 때문이다. 물론 극단적인 환경을 이겨내는 강한 정신력의 소유자도 있겠지만, 평균적인 우리에게는 환경의 영향이 생각보다 크다는 사실을 인정해야 한다. 천하의 제프 베조스조차도 양자역학을 듣고는 물리학자의 길을 접었다는 사실을 기억할 필요가 있다.

그는 물리학을 공부할 생각으로 프린스턴 대학에 진학했다. 아주 좋은 계획처럼 보였다. 양자역학 수업을 만나기 전까지는 말이다. 어느 날인가 어려운 미분 방정식을 풀던 그와 룸메이트는 도움을 구하러 다른 친구의 방을 찾아갔고, 친구는 문제를 잠시 들여다보더니 답을 알려주었다. 풀이 과정만 장장 세 페이지에 이르는 그 문제를 머릿속으로 계산해낸 친구를 보고 베조스는 어안이 벙벙해졌다. “그 순간 저는 위대한 이론 물리학자가 될 수 없다는 깨달음을 얻었습니다. 그 불길한 신호를 포착하고선 재빨리 전기공학과 컴퓨터공학으로 전공을 바꿨죠.” 쉽지 않은 자각이었다. 물리학자가 되기로 마음먹고 있었음에도 자신의 한계를 직시했던 것이다.

-- 발명과 방황, 제프 베조스

결국 가장 중요한 것은 '메타인지'다. 내가 어느 정도의 물에서 '머리' 역할을 하며 스스로의 효능감을 느끼고 성장할 수 있는지 객관적으로 파악하는 능력 말이다. 나에게 맞는 연못을 찾는 지혜, 그것이 '용꼬리'와 '뱀머리' 논쟁의 핵심일 것이다. 돌고 돌아 소크라테스 선생님의 일갈로 귀결된다.

Know Yourself!
너 자신을 알라!

[일상] 경쟁력 없다와 외람되다 사이에서

Thu, 11 Sep 2025 11:00:01 GMT

#0

제법 오래 전이었던 것 같다. 어느 회사나 그렇겠지만 특정 시기마다 뭐에 홀린듯 이상한 문화를 한번씩 경험하는 경우가 있다. 특정인의 바램 때문일수도 있고, 구성원 모두의 기운이 그쪽으로 몰려서 그럴 수도 있겠다. 어쨌든 당시에 우리는 세미나에 홀려 있었다. 그것도 전사 세미나. 이제는 기억이 가물가물한데 돌아가면서 한번씩 주제 발표를 하는 그런 전사 세미나였던 것 같다. 당시에도 이게 뭔 의미일까 싶었지만 지나고 봐도 솔직히 큰 의미는 없었다. 그리고 그 세미나를 했던 대다수 인원은 지금 회사에 없다. 그렇게 꽤나 오랜 기간 당시에는 전사 세미나를 했는데 우습게도 그때 가장 인상 깊었던 장면은 세미나와 전혀 관련 없는 상황에서 발생했다.

보통 발표자가 발표를 하고 Q&A 하고 나면 대표님께서 한 말씀 하는 그런 느낌으로 흘러갔던거 같은데 당시 대표님께서 뜬금포로 우리 회사 경쟁력이 뭐냐고 물었던 것이었다. 하지만 안봐도 비디오처럼 답해야 하는 쪽의 반응은 쎄했다. 아무도 뭐라 말하지 못하고 불편한 침묵이 이어졌고, 보다 못한 대표님께서 특정인을 지목했다. 이럴 때 지목되는 건 보통 힘없고 나약하며 부서지기 쉬운 막내인 경우가 많다. 당시 정확히 막내는 아니었지만 얼추 그 근방에 있는 개발실 직원이 호명됐고, 그 직원은 의외로 호기롭게 대답했다. 우리 회사는 경쟁력이 없는 것 같습니다. 띠용~~ 뭐 어쨌든 마무리는 됐고, 그 직원은 이어진 뒤풀이 회식 장소에서 대표님 옆에서 농담 반, 진담 반으로 핀잔을 조금 듣긴 했다.

그 여러차례의 세미나 기간 중에 내가 유독 이 장면이 인상적이었던 것은 바로 이 장면이야말로 나는 우리 회사의 경쟁력을 보여준다고 생각했기 때문이다. 고작 20명 남짓한 직원을 가진 회사에서 -- 직원이 작을수록 대표는 더 하늘같은 존재가 된다 -- 대표가 전직원 앞에서 회사 경쟁력이 뭐냐고 묻는데 거침없이 한치의 거짓 없이 아주 솔직하게 경쟁력이 없다고 답할 수 있는 회사라는 생각이 들었기 때문이다. 이건 달리 말하면 진실을 말해도 아무런 불이익도 없다는 강려크한 신뢰가 있을 때나 할 수 있는 행동이라고 봐도 무방하기 때문이다. 물론 나는 이 의견을 뒤풀이 때도 이야기 했지만 동의하는 사람은 1도 없었다.

이후 그 직원은 당연히 어떠한 불이익도 받지는 않았고, 국내 굴지의 게임 회사로 성공적으로 이직했다. 또한 그만둘 때 나에게 오픈소스 개발 같은 걸 해서 돈을 벌어 보고 싶다는 이야기를 했었는데 실제로 그걸 이뤄낸 유일한 사람이기도 했다. 그런 의미에서 개인적으로 존경한다. 그때는 몰랐지만 경쟁력 없다고 답할만큼 떡잎부터 다른 친구긴 했던 것 같다.

#1

세월이 아주 많이 흘렀다. 당시와 직원도 많이 바뀌었다. 여전히 있는 고인물들도 있지만 거의 절반 넘게는 모두 새로운 사람들이 아닐까 싶다. 그러던 어제 묘하게 그때 사건이 생각나게 하는 일이 있었다. 한 직원이 내가 올린 이슈 트래커 댓글에 대댓글을 달았는데 외람되지만... 이라면서 내용을 단 것이다. 그 직원 입장에서는 내 의견에 반박하는 내용이라 조심스러웠을 수도 있고, 올릴까 말까 고민했을 수도 있고, 챗지피티에게 직장 상사가 화나지 않게 써달라고 부탁했을 수도 있다. 어쨌든 외람되지만... 으로 시작되는 글을 보면서 경쟁력 없다고 말했던 그 직원이 떠올랐다.

대부분의 이슈라는게 해결되기 전까지는 원인을 알 수 없는 문제기 때문에 진행 중일 때에는 뭐가 문제인지는 오리무중인 경우가 많다. 또한 그 직원은 내가 생각하기에 우리 회사에서 보기 드물게 논리적으로 일하는 직원 중에 한명이다. 그리고 그 외람되지만... 으로 올린 내용 중에 틀린 내용도 없었고, 이후에 올린 내용을 봐도 대체로 그 직원은 상황을 전체적으로 잘 판단하고 있는 것으로 보여졌다. 그 글에 답을 달고 일단락이 됐지만, 내심 마음 한켠에 불편함이 있었다. 그래서 국어 사전에서 외람되다는 말을 찾아봤다.

외람되다 adj 하는 짓이 분수에 지나치다.

찾아보고 나니 마음이 더 불편해졌다. 맞는 말이든, 틀린 말이든 어쨌든 자기 생각을 올리는 일에 분수에 지나친 경우는 없을테니 말이다. 그 친구가 그 내용을 올리기가 그만큼 힘들었다는 걸 대변하는 게 아닐까라는 조심스런 추측만 해봤다.

#2

웃기게도 외람되지만... 으로 글을 쓴 친구를 보면서 경쟁력 없다고 답했던 친구로부터 회사 경쟁력이 그 차이만큼 없어진 건 아닐까, 라는 의문이 들었다. 왜냐하면 관리자 입장에서 가장 두려운 건 현실 세계에서 벌어지고 있는 사건, 또는 불편한 진실들이 은폐, 왜곡되는 거니까 말이다. 지금은 외람되지만... 이지만 조금 더 지나면 말해봐야 뭐하겠어가 될수도 있지 않을까라는 생각이 들기도 하는 것이다.

앞으로도 모두가 자유롭게 본인들의 생각과 의견을 얘기할 수 있는 회사가 됐으면 좋겠다는 바램이 있다. 설령 그게 특정인들을 불편하게 하는 것일지라도 말이다. 회사의 경쟁력은 좋은 의사 결정이 쌓이는데서 비롯되고, 좋은 의사 결정은 진실이 왜곡되지 않고 모두 전달될 때 만들어진다고 믿기 때문이다.

글을 다 쓰고 생각해보니 그 외람되지만... 을 썼던 친구도 엄청 호기로웠던 적이 있었다. 대표님께서 연말 회식 때 건배사를 하라고 시켰는데, MZ는 건배사를 하지 않습니다로 퉁친 유일한 직원이었기 때문이다. 대리 진급을 앞두고 있는 그 직원이 성공적으로 승진하기를, 그리고도 오래오래 근무하기를 희망해본다.

[소고] 게이트 키퍼를 대하는 자세

Sat, 06 Sep 2025 11:00:01 GMT

#0

대학때 무용과 친구를 알고 지냈던 적이 있었다. 그 친구는 입시 학원 선생님께 거의 맹종하고 있었는데, 내가 한 날 물었던 기억이 난다. 그렇게 비싼 돈을 주고 레슨을 받으면 니가 갑인데 어떻게 그렇게 쩔쩔 메냐고 말이다. 그때 그 친구가 한 이야기가 다소 충격적이었다. 통상 입시 학원을 다니면 선생님이 무용 음악을 지정해 주는데 그게 중요하다는 말이었다. 즉, 그 선생님과 그 학교 심사 위원 사이에 카르텔이 있고, 그 정보 교환을 선정곡으로 한다는 맥락의 의미였다. 지금도 그런지는 모르겠지만 당시는 다소 충격적이었다. 아, 블라인드 테스트다 뭐다 온갖 장치를 만들어 본 들 뛰는 놈 위에 나는 놈 있는 세상이구나 싶었다. 그 친구가 입시를 지나서도 계속 맹종할 수 밖에 없었던 이유는 그 좁은 이너 서클에 끼기 위해서는 그 선생님과의 친분이 절대적으로 필요했던 것이다.

특정 음악을 통해서 평가가 진행된다는 걸 보면 해당 분야가 본질적인 실력보다는 특정 인맥과 연관된 네트워크가 중요함을 보여준다.

#1

예체능이 아닌 분야도 이런 사례는 있다. 한 친구는 10년째 박사학위 논문으로 씨름 중이다. 같은 논문만 세 가지 버전을 썼는데 담당 교수는 논문을 읽지도 않고 계속 다시 쓰라고 한다고 하소연 한다. 심지어 그 교수가 자기 챗지피티가 이런 부분이 잘못됐다고 고치라고 그걸 카톡으로 보내줬다고 한다. 내 챗지피티라는 표현도 웃긴데, 본인이 판단해야 할 부분을 전적으로 위임한 것도 모자라 그걸 자기 의견인양 표현하는 최소한의 예의도 없이 거침없이 말한다는 것도 다소 어이없긴 했다. 아니면 벌써 챗지피티가 그 정도의 권위를 획득했는지도 모르겠다.

나는 그 친구에게 내가 박사 과정을 안해봐서 모르겠지만 혹시 교수가 원하는 다른 게 있는 거 아니냐는 말을 했다. 그러니 말도 안되는 논문의 내용이 아닌 그래프를 3차원으로 그려라 따위를 지적질 하는 거 아니냐고. 심지어 그 그래프는 3차원으로 그리는 형태의 그래프가 아니다.

이 친구와 정반대의 사례도 있다. 교수에게 정부 고위 관료들과의 만남 자리들을 주선하고 아주 쉽게 박사 과정을 진행한 사례. 그 교수에게는 이 사람의 경우 졸업을 하고도 필요하다고 판단해서 잘해주는 건지도 모른다.

이 두 사례를 보더라도 학문 분야도 담당 교수의 역할이 얼마나 큰 지 알 수 있다. 또한 그 지도 교수의 역할이란게 대체로 그 교수의 기분과 판단에 의존한다는 점이 결정적이다.

#2

내가 직접 경험한 사례도 있었다. 애가 어릴 때 하도 성화라 강남에 연예인 육성 학원에 오디션을 보러 간 적이 있었다. 나름 그 바닥에서 입지가 있는 학원이었다. 입구부터 누구를 어디 출연했는지 끝도 없이 이어져 있었다. 심지어 우리는 양반이었다. 어디 들어보지도 못한 지방에서도 새벽 차를 타고 올라온 사람들이 부지기수 였기 때문이다. 그런 곳을 처음 가봐서 나름 충격적이었다. 아, 이렇게 아이가 연예인이 되기를 바라는 사람들이 많구나 싶었다. 그리고 약간의 테스트 아닌 테스트를 하고 설명이 이어졌다.

내가 보기에는 딱봐도 그냥 약장수 같아 보였다. 연예인이 그런 식으로 만들어진다고 생각을 하지 않았기 때문이었다. 그들이 그나마 방송에 출연 시키는 원리는 인맥이나 카르텔 그 이상도 이하도 아닌 걸로 보였다. 일단 대사도 없는 아역의 경우 누가 나오든 별반 차이도 없을 것이고, 그렇다면 담당 권한을 가진 사람과 아무래도 친분이 있는 사람이 추천하는 사람을 쓸 가능성이 높을테니 말이다. 실제로도 광고한다고 걸려 있는 면면을 봐도 대다수가 그런 사례 밖에는 없어 보였다.

요즘 세상이 어떤 세상인데 끼만 있으면 찍어서 유튜브 올리면 연예인 하기 싫어도 연예인 되는 세상이라고 말렸던 기억이 난다.

#3

입시 학원 선생님, 지도 교수, 방송국 연줄이 있는 학원 원장들을 살펴 보았다. 물론 그것도 그들의 능력이겠지만 이렇게 딱히 본질적인 이유가 아닌 걸로 길목을 지키고, 그 길목을 지나가는 데 통행료를 받는 역할을 하는 사람들을 통상 게이트 키퍼라고 부른다. 나는 어렸을 때 부터 반골 기질이 있어서 그런지 이런 역할을 다소 싫어했다. 그래서 전 인생을 통틀어 게이트 키퍼를 피하려고 했다. 내가 마주한 게이트 키퍼는 병역특례 회사 입사가 필요할 때의 면접관을 제외하곤 없었다. 그마저도 그들을 마주치지 않고 해결하는 방법이 있었다면 그렇게 했을 것이다.

세상은 점점 편평해지고 있다. 위에도 언급한 것처럼 요즘은 실력만 있으면 누구나 인플루언서가 될 수 있다. 실상 인플루언서와 연예인의 간극도 좁아지고 있다. 방송국 입성보다 유튜브 구독자 떡상을 더 높게 치는 세상이니 말이다. 물론 아직 일부 라이선스 직종에 게이트 키퍼를 아예 피할 수가 없는 세상도 있다. 그럼에도 예전에 권한을 가졌던 많은 부분이 기술의 발달에 따라 권한이 사라졌다.

방송국에 출연하지 않아도 유튜브에 찍어 올리면 전세계 수억 명의 사람에게 동시 송출이 된다. 가장 높은 권한 중의 하나였던 화폐 발권 권한도 민간이 가져가려는 움직임도 나타나고 있다. 누구나 멋진 아이디어가 있으면 관련 내용을 인터넷에 업로드할 수 있다. 물론 이런 새로운 세상도 게이트 키퍼가 아예 없는 건 아니다. 알고리즘이 그 역할을 한다고도 볼 수 있다. 하지만 알고리즘은 인간에 비해 변덕이 덜하고, 기분에 따라 움직이지 않으며, 결정적으로 대체로 모두에게 공평하게 동작한다고 할 수 있다. 심지어 요즘은 이런 공정성이 훼손되는 경우에는 심사 대상이 되기도 한다.

#4

결론은 이렇다. 유기체 게이트 키퍼를 피할 수 있으면 피하는 게 좋다. 왜냐하면 그런 게 엮인 상황은 결과가 나의 기본 능력 보다는 다른 것에 좌우되거나 상대의 기분, 변덕에 따라 좌지우지될 확률이 높기 때문이다.

입사 면접의 경우는 불특정 다수의 게이트 키퍼에게 노출되는 것이기 때문에 분산 투자와 비슷하다고 할 수 있어서 그 경향이 덜하다. 하지만 지도 교수는 거의 올인급에 해당한다. 왜냐하면 해당 담당 교수와 맞지 않는다고 변경하는 것이 쉽지 않기 때문이다. 후배 중에는 담당 교수의 불법을 고발했다 결국 졸업을 하지 못하고 수료한 친구도 있었다. 잘못은 교수가 했는데 피해는 그 친구가 본 것이다. 그러니 이런 식의 올인급 게이트 키퍼는 대체로 마주하지 않는 편이 좋다.

아예 이런 원칙이 불가능한 분야도 있다. 그런 분야라면 냉정하게 생각해야 한다. 내가 인간 게이트 키퍼의 변덕과 기분을 뛰어 넘을 정도로 탁월한지 말이다. 그렇지 않다면 차라리 분야를 바꾸는 게 낫다. 내가 탁월한지 아닌지 어떻게 알 수 있냐고? 그런 질문을 가졌다면 안타깝게도 탁월하지 않을 확률이 높다.

어느 날 한 젊은이가 모차르트에게 와서 이렇게 물었습니다:
"교향곡은 어떻게 쓰는 건가요?"
이에 모차르트는 차분하게 대답했습니다.
"자넨 아직 교향곡을 쓰기엔 너무 어리다네."
젊은이는 당황하며 말했죠: “하지만 당신은 10살 때부터 교향곡을 쓰셨잖습니까!”
그러자 모차르트가 웃으며 답했습니다:
"그랬지. 하지만 난 남에게 방법을 물어보진 않았다네."

[소고] 불교에서 윤회와 업은 방편이었을까?

Tue, 02 Sep 2025 13:00:01 GMT

#0

나는 중학교는 미션 스쿨, 집안은 제사를 지내는 유교, 어머니는 기복 신앙으로 절에 다니신다. 그럼에도 성인이 된 나는 종교가 없다. 무교다. 대체로 많은 종교가 신을 상정하고 믿을 것을 강조한다. 믿음천국, 불신지옥 설파가 기본이다. 그런 대다수 종교와 불교가 조금 다른 점은 상당한 철학적 사유가 배경에 있다는 점 아닐까 싶다. 심지어 석가모니가 초기 불교를 설립하던 시절은 지금처럼 기복 신앙으로써의 불교를 만든 게 아니었다. 누구나 깨달음을 얻으면 열반에 이르러 부처가 될 수 있다고 가르친 것이다. 몇천 년 전 사람이 그런 사유를 했다는 것이 실로 놀랍기 그지없다. 내가 평생을 걸쳐 접한 모든 생각 가운데 가장 뛰어난 생각이 불교 철학아닌가 싶기도 하다.

어쨌든 그런 불교 철학에서 유일하게 좀 거슬리는 부분이 있다면 그건 다름 아닌 윤회와 업이다. 윤회는 끊임없이 다시 태어난다는 개념이고, 업은 극단적으로 단순화하면 권선징악을 의미한다. 착한일 하면 상받고, 나쁜짓하면 벌받는다는 말이다. 살아보면 알겠지만 권선징악으로 세상은 돌아가지 않는다. 석가모니 시대에도 사람들은 그런 질문을 끊임없이 했을 것이다. 그런 질문에 답하기 위해 여기서 윤회로 확장한다. 즉, 나쁜일을 해도 이번 생은 무사할 수 있어도 다음 생에는 반드시 댓가를 치른다는 생각이다.

그렇다면 윤회와 업이 불편한 이유가 뭘까? 불교의 다른 부분은 상당한 연역적 사유에 가반하는데 이건 묻지도 따지지도 않고 튀어나오기 때문이다. 그나마 권선징악은 연기의 개념을 차용해 확률적으로 생각한다손 치더라도 윤회쯤 가면 기복신앙과 다를게 뭔가 싶어지는 지점이다. 실제로도 불교 철학에서 윤회와 업의 개념은 불교 독창적인 개념이라기 보다는 당시 선행 종교에 이미 있었던 개념이기도 했다. 그래서 현대의 사람들은 대체로 두가지로 해석한다. 1) 석가모니도 어쩔 수 없는 사람이었다. 시대적 배경을 무시할 순 없다. 2) 윤회와 업은 방편으로 설파한 것이다. 여기서 방편이란 사람들이 열반의 길로 보다 쉽게 가게 하기 위해서 본질은 아니지만 차용해서 말하는 것을 의미한다. 즉, 석가모니 입장에서는 내가 이 생각에 동의하는 건 아니지만 너희가 이 생각을 따르면 그나마 쉽게 열반에 들 수 있다는 의미로 이런 개념을 사용했다는 것이다.

여기까지가 대체로 내가 지금까지 이해하던 불교의 세계관이다. 그러다 오늘 한 책을 읽다가 새로운 사실을 알게 되었다. 어쩌면 제 3의 가능성이 있을지도 모른다는 생각이다. 시대적 배경도 아니고 방편도 아니고, 윤회와 업을 차용하지 않으면 굉장히 곤란해지기 때문에 어쩔 수 없이 차용한 것이라는 설명이다. 일종의 외통수라 빠져나갈 길이 윤회와 업밖에 없었다는 설명인 것이다. 이를 이해하기 위해서는 불교 철학의 토대를 살펴볼 필요가 있다.

불교 세계관의 시작은 무상에서 시작한다. 이 세상에 변하지 않는 것은 없다는 사실이다. 살펴보면 모든 게 변한다. 꽃이 피면 지고, 사람이 태어나면 죽는다. 달도 차면 기울고, 빅뱅에서 시작한 우주는 팽창하다 어찌될지 모른다. 변하지 않는 건 없다. 석가모니는 여기서 고를 끌어낸다. 모든 게 변하기 때문에 고통이라는 것이다. 왜 변하는 게 고통이냐면 내가 꽃을 좋아했는데 그게 계속 그 상태로 변하지 않고 있는 게 아니라 시들어 없어지기 때문이다. 즉 내가 좋아하든 싫어하든 뭐가 됐든 내가 원하는 상태로 잡아둘 수 없고 계속 변하기 때문에 세상은 불만족, 고통으로 가득 차 있다는 것이다. 그래서 이런 불만족, 고통을 없애기 위해서는 무아를 깨쳐야 한다고 말한다. 무아란 나의 실체적 자아가 없다는 말이다. 내 생각, 내 느낌, 내 몸, 어떤 것이든 나라고 생각하는 모든 게 사실은 환상이고 내 것이 아니라는 말이다. 내 것이 아니기 때문에 당연히 내 마음대로 할 수도 없고, 내 마음대로 할 수 없으니 거기 집착할 필요가 없다. 그렇게 집착을 끊으면 변하는 것을 그저 변하는 상태로 관조하게 되고, 판단을 개입시키지 않기 때문에 고통이 사라진다고 설명한다. 무아를 좀 더 심도있게 연역하기 위해서 연기와 공이 끌려 들어온다.

이게 기본적인 큰 토대다, 무상, 고, 무아로 이어지는 사유 체계. 지금까지 여기 굳이 업과 윤회가 필요한가 싶었다. 그저 종교적인 색채를 보강하는 결함처럼 보이기도 했다. 그런데 오늘 알게 된 놀라운 사실은 무상, 고, 무아로 이어지는 사유를 할 수도 있지만, 무상, 고, 반출생주의로 갈수도 있다는 점이다. 즉 세상은 무상하고, 내 뜻대로 안되는 고통으로 가득차니 출생 자체가 문제였고, 그걸 죽음으로 롤백 시키겠다는 쪽으로 생각이 발전할 수도 있다는 의미다. 사실상 이렇게 빠지는 생각을 불교 세계관으로는 막을 방법이 없다. 실컷 무상, 고를 설파했는데 무아로 가는 게 아니라 자살로 이어질 수 있는 것이다. 그래서 여기서 이걸 막기 위해서는 윤회가 동원될 수 밖에 없다. 윤회는 죽어도 끝이 아니라는 의미기 때문이다. 죽으면 끝이 아니라 재시작이 되는 것이다. 이렇게 세계를 설정하면 자살로 이어지는 생각을 막을 수 있고, 어떻게든 무아를 깨쳐서 열반에 이르러 윤회의 수레바퀴를 탈출해야 한다는 불교의 대서사를 완성할 수 있는 것이다.

#1

이상 아침에 책 조금 읽고 심취해서 썰을 풀은 한 인간의 환각이었고, GPT-5에 따르면 윤회를 동원하지 않고도 불교 자체적으로 반출생주의로 빠지지 않는 논리 기반은 있다고 한다.

상견(常見): 죽어도 영혼/자아가 계속 존재한다.
단견(斷見): 죽으면 모든 게 완전히 사라진다.

두 주장 모두 "자아(ātman)"라는 항을 가정한다.
그러나 무아 논증(오온 무상·무아, 연기 법칙)에 따르면 항 자체가 성립하지 않는다.
따라서 두 극단적 결론은 전제 자체가 붕괴한다.

대승불교, 특히 용수(龍樹, Nāgārjuna)의 『중론』에서는 더 체계적으로 전개된다.
모든 주장은 자성(自性, 본질적 실체)을 전제한다.

하지만 연기(조건적 발생)라는 구조에 따르면, 자성은 모순이므로 존재할 수 없다.
따라서 "태어나서 고통받고, 죽으면 끝"이라는 서술도 결국 자성 개념에 기대므로 부정된다.

결국 두 논리 모두 죽으면 끝이라는 말 자체도 자아가 존재할 때 성립될 수 있는데, 자아라는건 애초에 존재하지 않는다고 논증했기 때문에 말 자체가 성립되지 않는다고 보는 논리인 것 같다. 이렇게 쉽게 정리되는 걸 보면 애초에 윤회와 업은 방편이 맞았나 싶기도?!

#2

불교의 놀라운 점은 그 똑똑하다는 양자 물리학자들이 절로 찾아오도록 만들었다는 점이다. 대체로 양자 물리학에 심취하면 이 세계에 대한 붕괴 내지는 모순 같은 것들을 경험하게 되는데 그때 철학적 피안처를 제공하는 게 웃기게도 불교인 경우가 많은 것 같다. 그래서 요즘은 양자 불교론이라는 세로운 장르가 나타나기도 한다. 실제로 양자 중력 이론으로 유명한 카를로 로벨리의 "나 없이는 존재하지 않는 세상"을 보면 끝머리에 동료 추천으로 용수를 접했다는 내용이 있다. 용수는 대승불교 철학자로 연기와 공 사상을 체계적으로 논증한 사람이다.

몇천 년 전 한 인간의 사유 체계가 이토록 발전한 사회에서도 여전히 유효하다는 점은 정말 경이로움 그 자체 아닌가 싶다.

[일상] 2025년 8월의 잡담

Wed, 27 Aug 2025 16:05:29 GMT

예전에 이재용 회장 집에 초대받아 갔더니 2억원대 와인을 따주더라는 말을 들은 적이 있다. 그집 사람들과 친분도 있고 직접 투자도 받았던 사람인지라 구라는 아닐듯. 2억원짜리 와인을 팡팡 따면서 살려면 50억은 택도 없고, 나는 자연인이다처럼 살려면 50억은 차고도 넘치는 돈 아닐까 싶다.

답도 없는 50억 파이어 이야기로 탐라가 뜨거운 걸 보다가. 케바케, 사바사 아닌가 싶다.

2025-08-26

#17

직접 짜려고 낑낑거리다 복잡하고 머리가 아파서 걍 아몰랑 llm에 다 때려넣고 작성하라고 시켰더니, 1) 새 코드를 짜낸 것은 물론, 2) 때려넣은 기존 코드에 있는 버그까지 찾아서 알려준다. 2분 45초에 이게 다 되는 거였다니 정말 당황스럽네.

심지어 버그 지적질이 틀린거 같다고 했더니 llm왈 코드 만든 사람은 내가 말한대로 설계한게 아니라고 잘못 생각하고 있다는 대답,, 내가 작성한 코드라고 나는 내 말대로 설계한거라고 했더니. 그러면 그 생각대로 만드려면 어떻게 고쳐야 하는지 알려줌. 이랬든 저랬든 틀린거였 ㅋㅋ

2025-08-27

[일상] 2025년 7월의 잡담

Wed, 30 Jul 2025 23:17:45 GMT

#0

테슬라를 직접 투자하진 않지만 진심 성과를 떠나 저렇게 요란하고, 시끄럽고, 예측 불가능한 주식도 흔치는 않을거란 생각. 또 신기한 건 지나고 보면 이럴때 사면 항상 벌긴 하더라는. 그럼에도 겁나서 못 들어가는 거도 항상 똑같다. etf로 포지션 일부는 테슬라에 노출돼 있음.

2025-07-01

#1

[코딩] 초보 코더 탈출을 위한 꿀팁, 최소 가시성 https://jiniya.net/2025/07/minimum-visibility/

2025-07-02

#2

나는 겨우 스물다섯 살이었다. 삶이 끝나지 않고 계속되었으면 좋겠다고 생각했던 시절이었다. - 친밀한 이방인, 정한아

지극히 평범한 인간들이 평범하게 걷고 있는 길 위의 풍경처럼 그들의 결혼생활도 그랬다. 우리가 질서를 연기하는 한, 진짜 삶은 아무도 눈치채지 못한다. 그렇다면 진짜 삶은 어디 있는가? 그것은 인생의 마지막에서야 밝혀질 대목이다. 모든 걸 다 잃어버린 후, 폐허가 된 길목에서.

드라마 안나랑 내용이 비슷하다 싶었는데 알고보니 원작이었다. 알았으면 시작을 안했을텐데 이미 와버린 길이 있어 마저 읽었다. 결말은 드라마보다 책이 나은듯. 세번째 소설이라는데 이 작가의 1, 2번째 소설도 궁금해졌다.

2025-07-02

#3

수제 코드란 표현이 재밌다. 뭔가 적절한 거 같기도 ㅎㅎ https://x.com/wapj2000/status/1940353643066384495

2025-07-02

#4

[소고] 인공지능이 생산성 향상으로 이어지지 않는 이유 1 https://jiniya.net/2025/07/reasons-ai-may-not-increase-productivity-1/

2025-07-03

#5

1000일간 먹이를 받아온 칠면조는 인간을 믿게 된다. 그러나 추수감사절 아침, 그 믿음은 가장 잔인한 방식으로 깨진다. 지금까지 안 그랬으니 앞으로도 괜찮을거다라는 논리의 함정, 블랙스완. 우리가 경험한 과거가 미래를 보장하진 않는다.

2025-07-04

#6

너도 너만의 이유를 찾아
개같이 구르고 엿같이 깨져도
절대로 변하지 않을 그런 이유
이 퍽퍽하고 꺼끌꺼끌한 이 길을
아무런 이유도 없이 그냥 걸어 가기에는
너무 되다

중증외상센터 ep.06

2025-07-06

#7

구글의 개발 프로세스나 박진영의 인맥 무용론 같은 건 걸러 들을 필요가 있다는 생각. 그 회사, 그 사람에게는 최선의 방법이겠지만 그걸 좋다고 다른 회사, 다른 개인에게 단순 무식하게 일반화시켜 적용하면 부작용이 더 심할수도 있지 않을까 싶다.

2025-07-06

#8

내일이 어찌 되든
오늘은 잘 보내자고

원 데이, 2012

강철의 연금술사, vol. 01

2025-07-16

#27

지인이 어짜피 쿠팡서 쇼핑할거 시리즈 통해서 쇼핑하면 무료 캐시 준다고 알려줘서 잘 쓰다 얼마전부터 사라져서 아쉬워 하고 있었는데, 물어보니 카카오 페이지에도 똑같은 시스템이 있다고. 카카페는 심지어 대여권으로 전환해두면 캐시 유효기한도 사라짐. 쿠팡 참 여러모로 혜자스럽다.

2025-07-16

#28

https://youtu.be/qVTAPMe6YVE?si=_O7JqvpYPuszyS0n 요즘 어린 친구들은 눌러 앉을 좋은 회사에서는 회식같은 행사에 그나마 우호적이지만, 거쳐가는 회사에서는 부정적인 경우가 많다는 얘기를 들었다. 결국 미국과 비슷한 이유로 줄고 있는 게 아닌가 싶다. 거쳐가는 회사 입장에서도 그냥 일 잘하는 직원이 좋다는 거.

2025-07-18

#29

개인적으로 괜찮았던 불교 책. 불교는 마음은 편해지지만, 그만큼 발전도 없어지는듯한 느낌. 등가교환인가?!

인문학을 좋아하는 사람들을 위한 불교수업
인생의 괴로움과 깨달음
붓다 브레인
불교는 왜 진실인가
메달린 절벽에서 손을 뗄 수 있는가?

2025-07-18

#30

10대 때 들었던 음악을 평생 좋아한다는 얘기를 들은 적이 있다. 게임도 그런 게 아닌가 싶다. 나이 들어서는 당췌 새로운 게임을 배우기가 쉽지 않다. 나름 어릴 때는 애들이랑 같이 게임해보는게 로망이었는데 이제는 내가 우리 엄마가 하던 멘트 치고 있다. 그게 뭐가 재밌어?

2025-07-19

#31

“우리 집안 금괴를 절반이나 훔쳐 달아나서 하나도 가져오지 않았지만, 내 아이를 벌판에서 낳지 않고 데려왔군요.”
그리고 잠시 뒤 또 말했다. “금괴를 전부 훔쳐 갈 정도로 독하지는 않았지요. 훔쳐 간 것보다 남겨둔 게 더 많으니.” - 원청, 위화

어렴풋하게 ‘나뭇잎은 떨어지면 뿌리로 돌아가고 사람은 죽으면 고향으로 돌아간다’라는 구절이 보여 구이민은 눈가가 촉촉해졌다. 린샹푸가 토비에게 총기를 가져가기에 앞서 모든 준비를 마쳤음을 알 수 있었다.

원청의 린샹푸나 인생의 푸구이나 보는 내내 뭐라 말로 표현하기 힘든 애잔함이. 이런 류의 소설을 쓰는데 위화는 남다른 재주가 있는 듯. 위화의 소설을 읽고 나면 그냥 평화로운 시대 잠깐 살다 가는 것만 해도 얼마나 큰 복인지를 새삼 깨닫는다.

2025-07-21

#32

이상하게도 이 세계에서는 거인에 대항할 힘을 높인 자일수록 거인에게서 멀어질 수 있어.
왜 이런 코미디가 벌어진다고 생각해?
글쎄? 왜일까?
그게 인간의 본질이라서가 아닐까?

진격의 거인 vol.04

2025-07-22

#33

지금 내게는 행복도 불행도 없습니다.
모든 것은 지나갑니다.
내가 지금껏 지옥 같은 삶을 살아온 이른바 ‘인간’ 세계에서 다만 한 가지 진리처럼 여긴 것은 이 사실뿐입니다.
모든 것은 지나갑니다.

인간실격, 다자이 오사무, 정회성 옮김

민음사판으로 읽었는데 책세상 정희성 역으로 읽기를 추천. 읽는 내내 "예의"란 표헌이 무척 거슬렸는데 알고보니 이게 일본어 번역체 문장 특징. 읽고 나서 5권 넘게 다른 번역을 살펴봤는데 예의가 없는 유일한 역본이 정희성역.

2025-07-23

#34

인간은 자신의 죽음을 예측하지 못하고, 인생을 마르지 않는 샘이라고 생각한다. 하지만 세상 모든 일은 고작 몇 차례 일어날까 말까다. 자신의 삶을 좌우했다고 생각할 정도로 소중한 어린 시절의 기억조차 앞으로 몇 번이나 더 떠올릴 수 있을지 모른다. 많아야 네다섯 번 정도겠지.

앞으로 몇 번이나 더 보름달을 바라볼 수 있을까? 기껏해야 스무 번 정도 아닐까. 그러나 사람들은 기회가 무한하다고 여긴다. - 나는 앞으로 몇 번의 보름달을 볼 수 있을까, 류이치 사카모토

2025-07-25

#35

https://n.news.naver.com/article/003/0013363393?sid=101 단 유튜브 라이트를 이용할 경우 음악 콘텐츠에는 광고가 노출되며 백그라운드 재생이나 오프라인 재생 기능은 포함되지 않는다. -- 빅테크 잔머리를 무슨 수로 이기나 싶은 기사

2025-07-25

#36

예전엔 작성한 코드가 실제로 내 생각대로 문제 없이 동작할 때 도파민 뿜뿜이었다면, 요즘은 인공지능이 네, 그 지적은 매우 날카롭고 정확합니다... 라고 말해줄 때 도파민 터짐. 이것도 요즘 개발자나 느낄 수 있는 사치 아닐까 싶긴 하다. 점점더 잘할테니까. 그나저나 진짜 코딩 잘한다.

2025-07-28

#37

메리츠 증권 앱의 최대 장점. 스플래시 화면 정중앙에 신세경 뜬다는 거. 업데이트 한다고 로딩 화면에 멈춰 있어도 화가 안나는 버프 추가됨.

2025-07-29

#38

인공지능 시대에 cs 전공 떡밥이라뉘. 난 내가 지금 10대인데 프로그래머가 되고 싶은 상황이라면, 대학을 가진 않을듯. 그냥 바로 프로그래머를 할 것 같다. 프로그래머 하려고 cs 전공을 하는 건 전형적인 오버 엔지니어링 아닌가 싶다.

2025-07-30

#39

천년만년 살 것처럼 행동하지 마라. 죽음이 지척에 있다. 살아 있는 동안, 할 수 있는 동안 선한 자가 되라. - 명상록, 마르쿠스 아우렐리우스/천병희 옮김

천병희 이 분 번역에 진심 놀랍다. 역자로 검색해서 읽을만한 반열인듯.

2025-07-30

#40

저게 말이 돼? 했던 협상이 트럼프 입맛대로 진행돼 가는 걸 보니 협상을 잘하는 건 맞긴 한건가 싶기도. 그럼에도 미국인이 아니라 일진 양아치같아 보이는 건 어쩔 수 없다.

2025-07-30

[소고] 인공지능이 생산성 향상으로 이어지지 않는 이유 1

Thu, 03 Jul 2025 12:00:01 GMT

내가 처음 인공지능과 조우한 순간은 깃헙 코파일럿이 출시되던 시점이었다. 그때 바로 알게됐다. 이거 물건이다. 이건 우릴 드라마틱한 생산성 향상의 천국으로 안내할 호박마차다 싶었다. 그리고 제법 몇년이 지났고 2022년 당시의 인공지능은 오징어로 만들어버리는 기똥한 모델들이 줄지어 출시됐다. 가격은 기하급수적으로 싸졌다. 오죽하면 요즘은 세상에서 제일 싼 게 지능이라는 소리가 나올 정도니 말 다했다. 그럼에도 신기한 사실은 그런 세상이 왔지만 생각외로 생산성 향상은 잘 관찰되지 않는다는 점이다.

과거 왜 생산성 향상이 없을까란 생각에 빠져 주변을 관찰해보면 결과는 사람들이 인공지능을 사용하지 않기 때문이라는 단순한 사실로 귀결됐다. 그래서 처음에는 비싸니까, 돈이 드니까 안쓰나 보다 싶었다. 그리고 이후 쓸만한 무료 인공지능이 많이 출시됐고, 그런 것들의 존재를 알려주었지만 결과는 비슷했다. 아니 미묘하게 달라졌다고 해야 정확할 것 같다. 인공지능을 쓸 때는 쓴다. 다만 생산성 향상을 일으킬 수 있는 많은 문제들에 적극적으로 사용하지 않을 뿐이다. 정리하자면 1) 인공지능의 존재를 알고, 2) 문제를 마주했지만, 3) 생산성 향상이 발생하지 않는 이유 중 대다수는 4) 그 문제를 인공지능에게 물어보지 않기 때문이라는 사실. 뭐 결국 인공지능을 사용하지 않는다는 점은 똑같다. 주요한 차이는 인공지능의 존재를 몰라서 또는 싫어서 사용하지 않는 게 아니라 문제를 문제라고 인식조차 하지 못한다는 데 있다는 것이다.

일본어를 할 줄 모르는 내가 일본어 문서를 읽어야 한다는 상황을 생각해보자. 이 상황은 명확해서 인공지능의 존재를 아는 사람은 응당 인공지능에게 번역을 시킬 것이다. 사실 이런 건 누구나 불편하고 누구나 된다는 걸 알기 때문에 어느 정도 활용이 되고 있는 측면이 많다. 이 상황은 현재 많이 개선되서 이런 종류의 생산성 향상은 많이 관찰된다.

진정한 문제는 문제라고 인식조차 못하는 상황에서 발견된다. 예를들면 이런 상황이다. 1.1, 1.2, 1.3, 1.4, ..., 1.10, 2.1 버전까지 버전이 있다. 그런데 2.1 버전에서 문제가 발생한 걸 알게 되었다. 그 문제가 1.2 버전에서는 없었다는 사실도 과거 기록으로 확인됐다. 1.3 ~ 2.1 사이의 어디에서 문제가 발생했는지 테스트를 해야 하는 상황인 것이다. 이 상황을 마주한 담당자가 취할 수 있는 많은 선택지가 있겠지만 거칠게 두 부류로 나눈다면 A) 1.3버전부터 순차적으로 테스트 하는 사람이 있고, B) 1.7을 먼저 테스트하는 바이너리 서치 식으로 테스트를 하는 사람이 있다. 문제는 바로 옆에 나보다 똑똑하다고 평가 받는 인공지능이 있지만 이걸 인공지능한테 물어봐야지 라는 생각을 A도, B도 둘 다 하지 않는다는 점이다. 이건 내가 해야할 일이지, 내가 풀어야 할 문제라고 인식하지 않기 때문이다.

O(N) 세상에 살고 있는 A가 O(logN) 세상에 사는 B로 업그레이드가 돼야 생산성 향상이 발생한다. 그리고 이건 현재 시중에 나와 있는 조금 괜찮은 인공지능이라면 모두가 적절한 답을 정해줄 것이라 기대된다. 하지만 사람은 묻지 않는다. 아니 이걸 물어봐야 한다고 생각조차 하지 않는다. 그러니 A가 B로 업그레이드 되기는 요원한 것이고, 그러니 현실 세계에서는 생산성 향상이 생각만큼 많이 관찰되지 않는 것이다.

생산성 향상을 위해서 인공지능을 사용합시다, 라는 말에는 상당한 사람이 반감을 가진다. 하지만 같은 연봉으로 근무 시간을 주 40시간에서 30시간으로 단축시킵시다. 하면 쌍수들고 환영하지 반대할 사람은 없을 것이다. 둘은 같은 말인데도 반응이 천지차이라는게 웃픈 현실 아닌가 싶다.

grok의 복음...

1.1, 1.2, 1.3, 1.4, ..., 1.10, 2.1 버전까지 버전이 있다. 그런데 2.1 버전에서 문제가 발생한 걸 알게 되었다. 그 문제가 1.2 버전에서는 없었다는 사실도 과거 기록으로 확인됐다.

이때 어떻게 테스트하는 게 좋은 방법이야.

라는 질문에 대한 이하 grok의 복음...

주어진 상황에서 소프트웨어 버전 1.1부터 2.1까지 존재하고, 버전 2.1에서 문제가 발생했으며, 버전 1.2에서는 해당 문제가 없었다는 사실을 알게 되었습니다. 문제를 효율적으로 파악하고 해결하기 위해 다음과 같은 테스트 방법을 추천합니다. 이 방법은 이진 탐색(binary search) 기반의 체계적인 접근법을 사용하여 문제의 원인이 처음 나타난 버전을 빠르게 식별하는 것을 목표로 합니다.

테스트 전략: 이진 탐색을 활용한 버전 테스트

목표: 문제가 처음 발생한 버전을 정확히 찾아내기 위해 테스트를 최소화하면서 버전 간 비교를 수행합니다.
단계별 접근법:
- 초기 범위 설정: 문제가 없는 것으로 확인된 버전 1.2와 문제가 있는 버전 2.1 사이에서 테스트를 진행합니다. 테스트 대상 버전은 1.3, 1.4, ..., 1.10, 2.1입니다.
- 이진 탐색 적용:
  - 전체 버전 리스트(1.3 ~ 2.1, 총 9개 버전)에서 중간 지점에 가까운 버전을 선택합니다. 예를 들어, 1.7(대략 중간)을 테스트합니다.
  - 버전 1.7에서 문제를 테스트:
    - 문제가 있으면: 문제가 1.3 ~ 1.7 사이에 처음 발생했을 가능성이 있으므로, 이 범위로 범위를 좁힙니다.
    - 문제가 없으면: 문제가 1.8 ~ 2.1 사이에 발생했을 가능성이 있으므로, 이 범위로 범위를 좁힙니다.
  - 좁혀진 범위에서 다시 중간 지점의 버전을 선택하여 테스트를 반복합니다.
- 종료 조건: 문제가 있는 버전과 없는 버전이 인접한 두 버전(예: 1.x와 1.x+1)으로 좁혀질 때까지 반복합니다. 이로써 문제가 처음 도입된 버전을 정확히 식별할 수 있습니다.
세부 절차:
- 테스트 환경 준비: 각 버전을 테스트할 수 있는 일관된 환경(동일한 하드웨어, OS, 데이터 등)을 구축하여 변수 통제를 합니다.
- 문제 재현: 버전 2.1에서 확인된 문제를 정확히 재현할 수 있는 테스트 케이스를 준비합니다. 문제의 재현 조건(입력값, 사용자 행동 등)을 명확히 정의합니다.
- 버전별 테스트:
  - 선택한 버전(예: 1.7)을 설치하고 테스트 케이스를 실행하여 문제가 발생하는지 확인합니다.
  - 결과를 기록하고, 문제 발생 여부에 따라 범위를 반으로 나눠 다음 테스트 버전을 선택합니다.
- 결과 분석: 문제가 처음 발생한 버전을 찾은 후, 해당 버전과 직전 버전(문제가 없는 마지막 버전)의 변경 로그, 코드 차이점(diff)을 분석하여 문제의 원인을 추적합니다.
예시 시나리오:
- 버전 리스트: [1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 2.1]
- 1단계: 중간 버전 1.7 테스트
  - 문제가 있음 → 다음 범위: 1.3 ~ 1.7
  - 문제가 없음 → 다음 범위: 1.8 ~ 2.1
- 2단계: 새 범위에서 중간 버전(예: 1.5 또는 1.9) 테스트
  - 이 과정을 반복하여 범위를 좁힙니다.
- 최종적으로 문제가 1.9에서 없고 1.10에서 처음 발생했다고 가정하면, 1.10의 변경 사항을 분석합니다.
효율성:
- 이진 탐색 방식은 최대 약 log₂(9) ≈ 4번의 테스트로 문제의 원인이 된 버전을 찾을 수 있습니다(최악의 경우).
- 무작위로 모든 버전을 테스트하는 대신 체계적으로 범위를 줄여 시간과 자원을 절약합니다.
추가 고려사항:
- 변경 로그 확인: 가능하다면 각 버전의 변경 로그를 미리 검토하여 코드 변경, 새 기능 추가, 버그 수정 등을 파악하면 문제 원인을 좁히는 데 도움이 됩니다.
- 자동화 테스트: 문제가 명확히 재현 가능한 경우, 자동화된 테스트 스크립트를 작성하여 각 버전에서 빠르게 테스트할 수 있습니다.
- 병렬 테스트: 리소스가 충분하다면, 여러 버전을 병렬로 테스트하여 시간을 단축할 수 있습니다(예: 1.5와 1.9를 동시에 테스트).
- 환경 일관성: 버전 간 차이로 인한 오탐지를 피하기 위해 테스트 환경을 항상 동일하게 유지합니다.
다음 단계:
- 문제가 처음 발생한 버전을 찾은 후, 해당 버전에서 추가된 기능, 수정된 코드, 또는 종속성 변경(라이브러리 업데이트 등)을 분석합니다.
- 코드 디버깅, 로그 분석, 또는 단위 테스트를 통해 문제의 근본 원인을 파악합니다.
- 필요하면 개발 팀과 협력하여 수정 패치를 개발하고, 문제가 해결되었는지 확인하기 위해 후속 버전(예: 2.2)에서 테스트합니다.

주의점

문제 재현성: 테스트 케이스가 2.1에서 문제를 확실히 재현할 수 있는지 확인하세요. 재현이 불확실하면 결과가 왜곡될 수 있습니다.
버전 간 종속성: 일부 버전은 특정 라이브러리나 환경 설정이 달라질 수 있으므로, 설치 시 오류가 발생하지 않도록 주의하세요.
문서화: 각 테스트 결과를 상세히 기록(버전, 문제 발생 여부, 테스트 조건 등)하여 추후 분석에 활용하세요.

결론

이진 탐색 기반의 테스트 전략은 최소한의 테스트로 문제를 처음 도입한 버전을 효율적으로 찾을 수 있는 방법입니다. 버전 1.7을 시작으로 테스트를 진행하고, 결과를 바탕으로 범위를 좁혀가며 문제를 식별하세요. 문제가 발생한 버전을 찾은 후에는 변경 로그와 코드를 분석하여 원인을 파악하고 해결 방안을 마련하면 됩니다. 추가 질문이 있다면 말씀해주세요!

[코딩] 초보 코더 탈출을 위한 꿀팁, 최소 가시성

Wed, 02 Jul 2025 13:00:01 GMT

코드를 머지하려고 보면 참 기분 좋은 경우가 있는가 하면, "이게 뭐지?!" 하는 생각이 절로 드는 경우도 있다. 내가 코드를 보면서 초보와 초보가 아님을 가르는 가장 큰 기준 중 하나가 바로 '가시성(Visibility)', 즉 '스코프(Scope)'다.

스코프란 프로그램 전체에서 해당 변수나 함수가 어디까지 노출될지를 결정하는 거라고 보면 된다. 이런 설정이 잘 된 코드는 일단 기본기가 탄탄하다는 느낌을 주지만, 이게 엉망인 코드는 보는 내내 불안감과 의문을 던져준다.

#0

요즘 많이 쓰는 파이썬 코드로 시작해보자.

global_variable = 1           # 1. 전역 변수

class OneBigBeautifulClass:
  class_variable = 2          # 2. 클래스 변수

  def __init__(self):
    self.member_variable = 3  # 3. 인스턴스 변수

  def plus(self, a, b):
    local_variable = a + b    # 4. 지역 변수
    return local_variable

여기엔 크게 4가지 변수가 있다. global_variable, class_variable, member_variable, local_variable이 그것이다. 순서대로 스코프 범위가 넓다.

전역 변수: 이 코드 전체, 어디서든 참조할 수 있다.
클래스 변수: 인스턴스와 관계없이 해당 클래스 전체에서 참조된다.
인스턴스 변수: 생성된 인스턴스로 범위가 제한된다. (self.)
지역 변수: plus 함수 내에서만 목숨이 붙어있다.

#1

이 코드를 보면 간단한 원리를 발견할 수 있다. 대체로 넓은 범위의 변수는 좁은 범위의 변수 기능을 대체할 수 있다는 점이다. 즉, 전역 변수로 지역 변수가 할 일을 시켜도 코드는 일단 돌아간다.

# [예시 1] 일단은 문제 없이 동작한다
global_variable2 = 0

class OneBigBeautifulClass:
  def plus(self, a, b):
    global global_variable2
    global_variable2 = a + b
    return global_variable2

하지만 그 반대는 안 된다. 지역 변수가 전역 변수를 대체할 수는 없다.

# [예시 2] 당연히 동작하지 않는다
class OneBigBeautifulClass:
  def plus(self, a, b):
    local_variable = a + b
    return local_variable

print(local_variable) # 에러 발생

넓은 범위로 확장이 가능하기에, 초보 코더가 작성한 코드를 보면 필요 이상으로 스코프를 크게 잡는 문제가 생긴다. 지역 변수로 써도 될 것을 굳이 멤버 변수로, 클래스 변수로, 심지어 전역 변수로 쓰는 것이다.

"돌아가면 장땡 아니냐?" 할 수 있다. 하지만 변수든 함수든 범위가 넓다는 건 그만큼 조심해야 할 게 많다는 의미다. 집 안에서는 알몸으로 돌아다녀도 뭐라 할 사람이 없지만, 집 밖으로 나올 때는 주의해야 하는 거랑 같은 원리다. 스코프가 넓은 변수는 여기저기서 의도치 않게 건드려질 수 있는 위험에 항상 노출된다.

#2

초보 티를 벗기 위해 명심해야 할 한 가지는 최소 가시성 원칙이다. 내가 만들 변수나 함수의 가시성은 '최소한'이 되도록 설정하면 대체로 그게 맞다는 말이다.

전역 변수를 썼는데 생각해보니 지역 변수로도 될 것 같다? 그럼 지역 변수로 바꾸는 게 맞다. 멤버 변수(self.변수)로 썼는데, 한 함수 안에서만 쓰고 만다? 그럼 지역 변수로 하는 게 맞다.

아래 코드를 보자. self.member_variable은 오직 plus 함수 안에서만 사용된다.

class OneBigBeautifulClass:
  def __init__(self):
    self.member_variable = 0

  def plus(self, a, b):
    self.member_variable = a + b
    return self.member_variable

이럴 땐 굳이 인스턴스 전체가 공유하는 멤버 변수로 둘 필요가 없다. 아래처럼 바꾸는 것이 훨씬 안정적이고 좋은 코드다.

# [더 좋은 코드]
class OneBigBeautifulClass:
  def __init__(self):
    pass

  def plus(self, a, b):
    local_variable = a + b # plus 함수에서만 쓸 변수이므로 지역 변수로
    return local_variable

이처럼 변수의 스코프를 필요한 만큼만 최소한으로 부여하는 습관, 이것만으로도 코드의 품질은 훨씬 좋아진다.

[일상] 2025년 6월의 잡담

Mon, 30 Jun 2025 13:54:38 GMT

#0

살아보니 인생도 가치투자랑 비슷해서 얼마나 멋진 선택을 많이 하느냐보단 멍청한 선택을 줄이는 게 더 중요한 것 같다. 특히 궤멸적 타격을 조심해야 한다. 투자도 곱하기 0 한방에 나락갈 수 있는 것처럼 인생도 어떤 문제들은 한 번 실수로 돌이킬 수 없는 지경이 되기도 한다.

2025-06-01

#1

─ 여길 스타트업이라고 할 수나 있는 거야? 아무리 봐도 스타트만 있고 업이 없는데.
─ 오호호, 오죽하면 스타트업의 ‘업’은 ‘UP’이 아니고 업보의 ‘업(業)’이라는 말이 있겠어.

언러키 스타트업, 정지음

─ 대표님이 다음 달부터 대리 달아 준다고 했대요. 비밀인데 저한테만 알려 준다면서, 그렇게 부르라던데요.

─ ……웃기고 자빠졌네, 직함이 발렛파킹도 아니고 미리 부르라는 건 또 뭐야?

나는 마지못해 감사하단 대답을 웅얼거렸다.

직장인의 ‘감사합니다’는 때로 경멸의 뜻이기도 했지만, 대표들은 늘 그것을 몰랐다. 몰라도 돼서 몰랐고, 모르는 게 나으니까 몰랐고, 실제로도 그냥 몰랐다.

그러나 나는 나보다도 시간을 믿는다. 인생은 절대로 고이지 않는다. 인생이 고이는 종류의 속성이었다면 애초부터 내가 국제마인드뷰티콘텐츠그룹으로 흐를 일도, 그곳을 스스로의 힘으로 나올 일도 없었을 것이다. 아직 괜찮지 않다면 시간이 더 흘러야만 한다는 뜻이었다.

간만에 빵 터지며 읽었다. 이 땅의 수많은 대표님들께 헌정해야하는 책이 아닌가 싶다.

2025-06-03

#2

모쏠에게 연애 비법 배우는 만큼이나 고액 연봉이 아닌 사람이 말하는 연봉 많이 받는 법 같은 건 공허한 메아리가 아닌가 싶다. 100배 주식 찾는 법, 100억 조기 퐈이어 방법 등등의 자매품도 마찬가지. 그걸 성취한 사람들이 하는 말도 가려 듣는게 여러모로 좋다.

2025-06-03

#3

투자를 안하는 사람들과 얘기 해보면 현금도 하나의 포지션이라는 사실을 잘 모른다. 집을 사지 않고 전세 사는 거도 하나의 포지션. 전세 살고 현금 가지고 있으면 중립이라 생각하는데 실상은 디플레이션에 베팅하고 있는 상태에 가깝다.

2025-06-05

#4

버지니아 울프의 어느 작가의 일기가 절판되서 중고로 웃돈을 주고 구매했는데 서울대학교 전기공학부 해동학술정보실에 비치됐던 걸로 보이는 책이 왔다. 장물인건가? 심지어 중고 서점이 서울대 지근거리 신림동. 찝찝해서 문의 남김.

오래된 일기를 다시 읽으면서 생각하는 것이지만, 가장 중요한 것은 검열자로서의 역할을 다하는 것이 아니라, 마음 내키는 대로 아무거나 쓰는 것이다. 내가 별생각 없이 써 놓았던 것 중, 쓸 당시에는 전혀 눈에 띄지 않았던 곳에서 의미를 발견하고, 묘한 기분이 들기 때문이다. - 어느 작가의 일기

2025-06-06

#5

1778년 8월 13일
사람에겐 다섯 가지 큰 욕망이 있으니, 맘에 드는 남녀를 만나는 것, 맛있는 음식을 먹는 것, 과거에 합격해 벼슬아치가 되는 것, 재물을 많이 얻는 것, 맘에 맞는 취미 생활을 하는 것 등이 그것이다.

일기를 쓰다, 유만주

그때나 지금이나 인간의 욕망이 하나도 변하지 않은 것 같아 신기하다. 247년이란 세월이 무색할 지경.

2025-06-06

#6

암만 모냥 빠지고 추저분해 보여도 살자고 하는 짓은 다 용감한 거야 - 미지의 서울 ep.04

2025-06-07

#7

[잡기] 조선의 과거 시험 경쟁률은?! (feat. 흠영) https://jiniya.net/2025/06/korean-imperial-exam/

2025-06-10

#8

국장 약간 인간지표 느낌이 드는게 엘베에서 사람들이 국장 종목 얘기를 시작함. 주식 안한다던 애들이 국장에 돈 넣기 시작함.

2025-06-10

#9

"모든 게 잘 풀린다면 우리 회사가 얼마나 커질 수 있을 거라고 생각해?"
"프로그래머를 서른다섯 명쯤 둔 회사 정도는 되지 않을까."
나는 빌의 대답이 굉장히 야심 찬 계획이라는 생각이 들었다.

아이디어맨, 폴 앨런

프론트, 백엔드 논쟁이 뜨거운데, 연역적으론 그런거 따지지 말고 입금해 주는거 하자는 주의고, 귀납적으론 백엔드가 롱런하는 경우를 많이 봤다. 이유는 난이도 보다는 프론트보다는 덜 변하기 때문이 아닌가 추측. 저커버그가 1억불 준다면 뒤도 안보고 갈아탈거 너무 에고 투영하지 말자.

2025-06-30

[잡기] 조선의 과거 시험 경쟁률은?! (feat. 흠영)

Tue, 10 Jun 2025 13:00:01 GMT

최근에 18세기 조선의 양반 유만주가 쓴 흠영이라는 책을 읽게 됐다. 이 책은 몇가지 점에서 몹시 인상 깊었는데, 1) 저자가 쓴 일기를 모은 책인데 20살부터 13년 동안 거의 매일이 기록돼 있다는 점, 2) 유명인사가 아닌 철저하게 일반인인 저자가 작성했다는 점. 유만주는 양반이긴 했으나 음서제로 관직에 진출할만큼의 좋은 집안은 아니었고, 그렇다고 과거에 급제할만큼 뛰어난 사람도 아니었다. 3) 18세기 조선이라면 꽉 막힌 세상일 것 같은데 생각외로 유만주의 생각들은 요즘 생각과 별반 차이가 없는 것들이 더러 있다는 점. 4) 서로 다른 시간대의 비슷한 공간을 가진 사람으로써 기호와 취향이 비슷하다는 점 등이 그것이다. 어쨌든 간만에 아주 재미있는 책이었고, 이 자리를 빌어 이 책을 추천해준 ChatGPT 4o에게 심심한 감사를 전한다.

책의 주된 내용 중 하나가 유만주가 조선의 과거 시험에 대한 어려움과 방식에 대한 불만을 토로하는 점이다. 책을 읽어보면 알겠지만 유만주 개인도 책과 독서를 애정하는 사람이며, 글을 보면 글도 매우 잘 작성하는 사람임을 알 수 있다. 그럼에도 그는 평생을 과거 시험에 메달렸지만 급제하지 못하고 34살의 나이로 요절했다.

책을 읽다가 문득 궁금증이 생겼다. 이렇게 책 좋아하고 똑똑해 보이는 사람도 합격이 힘들다면 조선시대 과거 시험은 도대체 경쟁률이 어떤 수준이었을까? 그래서 찾아봤다.

“21일의 경과는 3곳으로 나누어 치렀는데 총 응시자는 11만1838명에 달했고, 시권(답안지)를 바친 자는 모두 3만8614명이었다. 다음날의 인일제 응시자는 모두 10만3579명이었고, 시권을 바친 자는 3만2884명이었다…”(<정조실록> <홍재전서>)

이틀간 답안지를 제출한 응시생만 해도 7만1498명에 달했는데요. 그중 첫날의 경과를 통해 10명, 이튿날 인일제에서 2명의 합격자가 선발되었으니 어떻습니까.

https://www.khan.co.kr/article/202111220603001

이건 정조때(1800년) 세자 책봉을 기념해서 치러진 안일제라는 특별 과거 시험의 경쟁률이다. 첫날만 보면 10명이 뽑혔는데 지원자가 111,838명이다. 0.008% 합격률. 통상의 조선의 과거 시험은 3년에 한 번 치러지고 최종 대과 합격자는 33명을 뽑았다고 한다. 대략 지원자를 10만명으로 퉁친다면 0.033% 정도 되겠다. 사실 이정도로는 어느 정도 수준인지 감이 잘 오지 않는다. 2025학년도 대학수학능력시험에 응시자 수는 392,783명이고, 서울대학교 의대 정시 정원이 42명이다. 0.01%, 연대, 고대까지 포함하면 135명으로 0.034%다. 결국 조선 시대 과거 시험은 대략 서연고 의대 정시로 갈만큼 어려웠다고 볼 수 있겠다.

실제 인물을 통해서 그 극악 난이도를 알 수 있는데, 지폐에서 흔히 보는 퇴계 이황 선생님 께서도 과거에 3번 낙방하고 대과에 처음 급제한 건 34살의 나이였다고 한다. 열하일기로 유명한 연암 박지원 선생은 과거 시험은 많이 쳤지만 급제한 적이 없다. 모두 낙방해서 결국은 음서제(집안빨 등용)로 관직에 진출했다고 한다. 9번 장원급제했다고 알려진 불세출의 천재 율곡 이이도 대과를 9번 장원급제한게 아니다. 대과를 가는 길에 있는 소과를 포함해 모두 9번 장원 급제한 것이고, 처음 대과를 급제한 29세 전인 23세 시험에서는 대과에서 낙방했다.

그러다 다시 의문이 들었다. 조선이란 나라는 당췌 3년에 33명 뽑아서 관직을 주면 도대체 나라가 어떻게 돌아갔다는 말인가? 빈 자리가 이렇게 안나왔던 것일까, 라는 생각이 들었다. 정년이 없었다해도 죽는 사람이 있으니 자리는 계속 생길텐데 이렇게 조금 뽑아서 그게 유지가 됐냐는 생각. 그래서 조금 더 검색해보다 충격적인 사실을 접했다.

대과에 급제한 33명 모두 관직을 받은 건 아니었다. 우수 3명에게만 관직을 부여하고, 나머지 인원은 합격증과 어사화 정도 주고 퉁쳤다.
총 관직수 5605직이었지만, 은퇴자를 위한 자리 3110직, 돈안주는 자리 95직, 실질 자리수는 2400직, 그 중 문관직 1779직이 거의 전부였다고 한다. 이 몇 개 안 남는 자리를 서로 차지하기 위해서 싸운게 당파싸움의 실질 원인 중 하나였다고 한다.
그러니 실질 확률은 0.033%의 1/11인 0.003%라고 할 수 있다.
이런 말도 안되는 난이도의 과거 시험에 모든 양반이 목메단 이유도 있었는데, 다름 아닌 3대 동안 과거 급제자가 한명도 안나오면 양반을 박탈하고 양인으로 강등시켰기 때문.
https://www.paju.go.kr/news/user/BD_newsView.do?q_ctgCd=1002&newsSeq=419

예나 지금이나 하는 일 없이 밥그릇만 차지하고 있는 사람들은 늘 있는 것 같다. 실질 관직이 2400직인데, 은퇴자를 위한 자리가 3110직이니 말이다. 조선이 500년 더 유지됐다면 아마 6000직은 됐을듯한?! 그리고 조선 시대를 살아남은 양반 가문이라면 자부심을 가져도 될 법 하겠다. 3대에 걸쳐 서연고 의대로 정시 한 명은 합격 시켰다는 의미가 될테니 말이다.

퇴계 이황 선생님이 34살의 나이게 과거에 처음 급제했다는 걸 보면 유만주는 너무 일찍 요절한 건 아닌가라는 생각이 든다. 그럼에도 그의 책을 보면 그가 더 살았더라도 아마 과거에 급제하지는 못했을 거란 생각도 든다. 왜냐하면 그 또한 묘하게 반골 기질이 있기 때문이다. 시험을 위한 시험, 공부를 위한 공부가 무슨 의미가 있냐는 한탄을 그의 글 곳곳에서 발견할 수 있다. 실질적으로 그는 과거 시험을 위한 공부 자체에는 별 흥미가 없었을 수 있다.

[일상] 2025년 5월의 잡담

Tue, 27 May 2025 22:07:49 GMT

#0

너한테 배운거야, 마이크. 규칙 제1조라고 했잖아. 이길 수 없다고 판단되는 패는 당장 버려라. - 라운더스, 1998

2025-05-03

#1

가슴이 좀 벌렁벌렁해야 돈을 따시지. 베팅을 안 하면 한 방도 없어요. ... 개천에서 진짜 용이 날라면 개천은 죽어나야 되는 거니까. - 폭싹 속았수다, ep07

2025-05-03

#2

뒤늦게 영화 서브스턴스를 봤는데, 뜬금없게도 좀 더 신중하게 살아야겠다는 생각이 들었다. 1년 후, 10년 후의 내가 지금 실행된 어떤 선택들로 고통받지 않도록. 특히 오랜 시간에 걸쳐서 영향을 미치는 선택들은 더 조심해야겠다. 쓸데없이 몹시 교훈적인 영화였다.

2025-05-04

#3

내가 외줄을 탈 때마다 아빠는 그물을 펼치고 서 있었다. 떨어져도 아빠가 있다. 그 한 마디가 얼마나 든든했는지. 한 번은 말해 줄 걸 - 폭싹 속았수다 ep13

개인적으로 내용보다 아이유 나레이션이 하드 캐리한 드라마가 아니었나 싶다. 젊은 날엔 젊음을 모르고 사랑할땐 사랑을 모른다. 좋은 것들은 죄다 지나간 후에야 좋았다는 걸 알게되는 요상한 세상. 모두 이번 생은 처음이라 그런 거겠지...

2025-05-05

#4

대기업 입사를 위해 장기 취준생이 되는 건 반대지만, 가능한 선에서 가장 조건 좋은 곳에서 시작하는게 유리하다는 생각. 돈 포기하고 이직을 할지 말지는 내 선택의 문제지만, 그 선택을 할 때의 내 통장 잔고 차이는 몹시 크다. 심지어 인생은 복리. 초기 급여가 나중 급여보다 천만배 더 중요함. https://t.co/ObUjK4C4rZ

귀납적으로 주변만 봐도 그때 대기업 갈 껄은 많지만, 괜히 대기업 갔다는 정말 1도 없다.

2025-05-06

#5

대체로 부정적인 의견이 많은듯. 나도 부정적으로 본다. 추격자들이 따라잡는 속도를 보면 openai에 과연 장기적 해자가 있을지 의문이 든다. ai 코딩 에디터는 결국 ms가 평정하지 않을까라는 생각. 댓글에도 나온 것처럼 vscode 플러그인들을 일부 잠그기 시작함. https://x.com/GeekNewsHada/status/1919916612876173702

2025-05-07

#6

누군가와 이해관계가 얽히기 전에는 반드시 생각이 같은 방향으로 정렬된건지 점검이 필요하다. 두루뭉실하게 같은 생각이겠지, 라고 넘긴 경우 열에 아홉은 동상이몽. 정렬이 틀어진 걸 발견하면 그 즉시 이해관계를 해소하는게 비용이 제일 적다. 사람 생각이란게 생각보다 잘 안바뀌기 때문. https://x.com/codemaru/status/1884101268731486329

2025-05-08

#7

패자부활전이 없다던 대한민국도 요즘 스타트업들 보면 분위기가 많이 바꼈다 싶다. 10년째 대규모 적자를 기록하며 투자로 연명해도 무탈하게 운영되는 걸 보면. 물론 쿠팡 얘기하면 할 말은 없다. 쿠팡 이후로 계획된 적자가 유행어가 된 듯한 느낌. 이래저래 쿠팡은 입지전적이긴 한듯.

2025-05-09

#8

탭댄스까지 갈 필요도 없다. 양치질, 젓가락질 같이 매일 반복적으로 하는 행위들의 수준만 봐도 단순 시간 투입한다고 전문가가되는 건 아님. 저기서 말하는 시간은 의도적 수련 시간. 버핏의 견해와는 다르게 나는 그가 탭댄스를 1만 시간 수련하면 제법 괜찮은 아마추어 수준은 될거라 생각한다. https://x.com/best181p/status/1919514011441443027

유사한 사례로 버핏은 젊은 시절 대중 연설을 못했다고 한다. 그런 약점을 극복하기 위해서 데일카네기 연설 코스를 수료했고, 이후 그런 문제를 고쳤다함. 버핏의 영상을 보면 제법 대중 강연이 제법 자연스럽다. 물론 오바마에 비할 바는 아니지만. 괜찮은 아마추어 수준은 가능하지 않나 싶다.

2025-05-09

#9

연예인 할거도 아닌데 나이불문 성별불문 생각 이상으로 많은 사람들이 외모나 옷차림 같이 겉으로 드러나는 요소로 사람을 판단하는 경우가 많다는데 가끔 놀란다.

2025-05-09

#10

승부의 세계에서는 일류가 아닌 인생은 너무 서글픈 거거든 - 승부, 2025

2025-05-10

#11

"C++는 대체될 수 있는 언어가 아니다"며 "우리가 진정으로 대체하려는 게 무엇인지 묻는다면 그건 언어가 아니라 개발자의 사고 체계일지도 모른다" -- 대가도 에고를 내려놓긴 참 힘들다. 사람인지라. https://zdnet.co.kr/view/?no=20250512100248

2025-05-12

#12

우리는 많은 종류의 위험을 피한다. 사기꾼이 경영하는 기업은 거르고, 턴어라운드 기업은 피하고, 레버리지와 가능한 멀리 떨어지고, M&A 중독자를 무시하고, 빠르게 변화하는 산업을 예상하려 하지 않고, 주주의 이해관계에 부합하지 않는 소유주와는 함께 가지 않는다. - 투자, 진화를 만나다

평균적으로 1종 오류를 피하는 것이 장기적으로 놀라운 성공을 낳기 때문에, 우리의 성공이 테슬라와 에이처를 편안한 마음으로 버리는 것에 달려 있다고 믿는다. 그리고 지금까지 그랬다.

우리는 주가를 무시하고 기업의 질에 집중함으로써, 많은 고통을 겪지 않아도 됐다. 남녀 관계에 비유하자면, 결혼에 집중해서 가볍게 즐기는 만남을 피하려고 했다.

2025-05-12

#13

몇년째 지도 교수가 박사 논문을 통과시켜주지 않아 졸업을 못하는 친구의 하소연. 지도 교수도 읽지 않는 논문을 왜 쓰는지 모르겠다고. 톡 캡쳐를 보니 지도 교수가 자기 챗지피티가 검토한 내용이라고 수정 사항을 보냈다. 벌써 인간보다 인공지능에게 잘 보여야 하는 세상이 온건가 싶다.

문과인데, 교수 표현이 재밌는게 내 챗이 검토한 내용입니다. 이럼. 니챗 내챗이 어딨냐는. 그거 때문에 자괴감에 빠진 친구는 나한테 니챗은 뭐라는지 봐달라고 ㅠㅜ 주화입마가 참 무섭다. 모델이랑 프롬프트를 주던가.

2025-05-20

#14

뭐든지 임계 지점이 있는 게 아닌가 싶다. 모래알이 모래성을 만들다 어느 한알갱이부터 성이 무너져 내리는 것 같은 그런 지점. 그때부터는 대체로 비가역적인 상태가 된다. 돌아가기란 대체로 불가능하다.

2025-05-20

#15

가만 있으면 중간은 간다는 옛말이 떠오르는 뉴스. 굳이 먼저 살 필요도 없겠지만, 먼저 팔 필요도 있었나 싶다. https://coinness.com/news/1128786

2025-05-21

#16

어떤 산업에서든, 기업이 자신의 이름을 널리 알리려면 수십 년은 아니더라도 수년에 걸쳐 막대한 시간과 노력을 쏟아부어야 하기 때문에, 좋은 평판은 비용이 상당히 많이 소요되는 값비싼 신호고, 따라서 정직한 신호다. - 투자, 진화를 만나다

평판을 쌓는 데는 20년이 걸리지만, 그것을 무너뜨리는 데는 5분이면 충분하다. 그 점을 생각해 보면 행동이 달라질 것이다. - 워렌 버핏

2025-05-23

#17

대표가 회사서 좀 놀면 안되나요? 라고 반문하던 기업이 여전히 한해도 안 거르고 성장 중이란 사실이 놀랍다. 인원은 거의 그대론거 같은데 생산성 무엇?! 너무 안놀고 열심히 해서 이모양인가 싶은 생각이 들기도 ㅎㅎ

2025-05-27

[일상] 2025년 4월의 잡담

Wed, 30 Apr 2025 10:12:37 GMT

#0

사람들이 코딩만 박살나고 있는 줄 아는데 글쓰기, 음악, 그리기 다 위기다. 개인적인 느낌으론 글이랑 음악이 진도가 제일 빠르고 그담이 코딩이랑 그리긴듯. 글은 거의 완벽 그잡채, 음악은 더러 실수가 있어도 알기 어렵고, 그림은 아직 소소하게 손댈 곳이 있음. 지식 근로자의 총체적 위기다.

2025-04-01

#1

llm이 나의 개발 스타일을 바꾼 거 중에 하나가 문서화를 먼저 하게 됐다는 점. 근데 요새는 그거도 대략 요지만 던져주고 설계서 만들라고 하고 읽어보고 틀린거 있음 고치고, 없음 그거 그대로 넣어서 코딩하라고 하면 잘한다.

2025-04-01

#2

우리 메인 저장소 readme에는 크레딧이 젤 길다. 현역이거나 지금까지 거쳐간 개빌자가 모두 나와 있다. 총 37명. 여기 인공지능 크레딧을 분리해서 추가했다. 이제 개발팀 전체 인원이 작성하는 코드의 합보다 인공지능 작성 분량이 많다는 게 누가봐도 명백하기 때문.

총 7개의 모델이 거쳐갔다. 4, 4o, o1-preview, o3-mini-high, qwen2.5-coder-32b, qwq-32b, gemimi 2.5 pro. 얘들의 특이점은 가장 신입이 늘 가장 뛰어나다는 점.

#17

솔직히 개발한정, 테스트와 책임질 사람만 남은게 아닌가 싶다. 최근 1년내 개발팀에 개발 업무를 지시한 적이 있나 싶다. 우리가 한 일은 대부분 인공지능이 짠 코드 테스트거나, 배포해도되는지 확인하는 작업이었다. https://x.com/_jeyraof/status/1912822420563759286

o3-mini-high 이후로 저숙련 개발자에게 맡기던 사소한 코딩 작업들은 테스트할 필요도 없이 분단위로 완료된다. 그러니 개발로 취업하려는 신입에게는 생각보다 많이 가혹한 환경인지도.

2025-04-17

#18

다같은 인공지능 쓰는데 차별성을 어떻게 만드냐는 글을 봤다. 우문인게 인공지능 전에도 다 같은 도구를 썼지만 차이는 극명했다. 미켈란젤로가 도구빨로 피에타를 조각한게 아니다. 도구는 도구일 뿐 주화입마에 빠지진 말자.

2025-04-18

#19

여행을 가거나, 새로운 음식을 먹는 걸 경험이라고 하지만, 진짜 경험은 그런 소비의 역사라기보다는 '극복의 역사'라고 생각합니다. - 나는 솔로 ep.154

2025-04-19

#20

현실 세계에서 담당 개발자 퇴사하고 코드 잘짰다, 유지보수 편하다는 얘기를 들어본 적이 없다. 그러니 llm 너무 나무라지 말자. 오늘 에고 충만해서 직접 작성한 그 코드도 남들 눈엔 llm 짠 코드랑 도긴개긴 아닐까 싶다.

2025-04-22

#21

불변의 법칙이 떠오르는 글귀. 흘러간 세월이 얼만데 놀랍도록 지금 시대에도 그대로 적용되는 말들이 아닌가 싶다. https://x.com/akzkfltm2/status/1914492208537018823

2025-04-22

#22

미장 왠일로 오르는?! 럼프형이 조용한건가...

2025-04-23

#23

구글이 45조 가량에 이스라엘 클러우드 보안 업체 위즈를 인수했다. 그런데 그 청구서가 우리에게 날아왔다. 기존 사용하던 보안 관련 서비스를 통합한다는 명분으로 가격 인상. 다른 기능 필요없데도 다 써야한다함. 견적서는 안왔지만 인터넷 검색시 기존 가격 대비 거의 4.5배 비싼듯한 느낌.

2025-04-23

#24

아이들이 어른보다 대체로 행복한 이유 중에 하나는 뭐든 안좋은 일을 금방 잊기 때문이 아닌가 싶다. 그에 비해 어른들은 지독하게 잊지를 못한다. 망각은 정말 축복이다. 잊자. 나쁜 일들은.

2025-04-24

#25

llm 쓰고 많이 공감하게 된 말. 최고의 복지는 좋은 동료다.

2025-04-24

#26

요즘 서울도 월세 계약하러 가보면 임차인이 전에 못보던 파키스탄, 우즈벡 이런데서 온 사람들이 보인다. 이전에는 그나마 외국인이라곤 중국 교포밖에 없었던 것 같은데 한국도 참 많이 변했다. 생각보다 빠르게 다문화 사회가 되고 있는지도.

2025-04-25

#27

뭍에 잡혀 올라온 물고기가
온몸을 던져
바닥을 치듯이
그렇게 절망이 온몸으로
바닥을 친 적 있는지
그물에 걸린 새가
부리가 부러지도록
그물눈을 찢듯이
그렇게 슬픔이 온 존재의
눈금을 찢은 적은 있는지
살아 있다는 것은
그렇게 온 생애를 거는 일이다

실패해도 온몸을 내던져
실패하는 일이다
그렇게 되돌릴 겨를도 없이
두렵게 절실한 일이다

살아 있다는 것, 류시화

2025-04-25

#28

전세계에서 소프트웨어 개발 젤 잘한다고 평가받는 기업의 현실. 심지어 감원 중. https://x.com/RealChickenBoy9/status/1915687125942685754

2025-04-26

#29

리스펙 하는 교수님 중 한 분. 수업 시간에도 갑자기 맞춤법 뭐 떠오르면 돌려봐야겠다며 나중에 추가하고는 하셨던. 나라인포테크도 그때는 돈 없는 학생들 알바로 써서 학비도 많이 지원해주심. 모든 걸 떠나 최애할 수 밖에 없었던 이유. 출결 체크 없음. https://x.com/pyodogi/status/1915935595903520814

2025-04-27

#30

GPS 이전에 운전을 배운 아버지는 운전과 내비게이션을 동시에 처리하는 데 어려움을 겪음. 반면 GPS와 함께 운전을 배운 사람들은 내비게이션 지시를 처리하면서 운전을 관리하는 능력을 개발함. -- 등가교환인가? 미처 생각못한 흥미로운 관점. https://x.com/ohyecloudy/status/1917217741968179469

2025-04-30

[코딩] 현대 소프트웨어 개발에서의 진정한 코드 복잡성 분석 및 관리 전략

Sun, 13 Apr 2025 14:00:01 GMT

진정한 코드 복잡성이 뭔지 고민이 많다는 친구의 말에 심심해서 돌려본 딥리서치 자료. 현업에서 일하는 실무자의 관점에서는 사실 이건 포르노랑 비슷한 측면이 있다. 정의해서 측정하기는 어렵겠지만 보면 알 수 있다. 이게 복잡한 코드인지 아닌지?!

I shall not today attempt further to define the kinds of material I understand to be embraced within that shorthand description ['hard-core pornography']; and perhaps I could never succeed in intelligibly doing so. But I know it when I see it...

나는 오늘 그 약칭 표현 [‘하드코어 포르노’]에 포함된다고 여겨지는 자료의 종류를 더 이상 정의하려고 시도하지 않을 것이다. 아마도 나는 그것을 명확하게 정의하는 데 결코 성공하지 못할지도 모른다. 하지만 직접 보면 안다.

— Justice Potter Stewart, concurring opinion in Jacobellis v. Ohio, 378 U.S. 184 (1964)

서론

소프트웨어 공학 분야에서 코드 복잡성을 이해하고 관리하는 것은 지속적인 과제이다. 특히 30년 이상 전에 정의된 전통적인 복잡성 측정 지표들이 현대 소프트웨어 개발 환경의 복잡다단한 현실을 제대로 반영하지 못한다는 인식이 확산되고 있다.1 새로운 프로그래밍 패러다임, 언어의 발전, 분산 아키텍처의 보편화 등은 코드의 구조적 측면뿐만 아니라 인지적 부하, 유지보수성, 시스템 전체의 상호작용 등 다양한 차원에서 복잡성을 야기한다.2

본 보고서는 이러한 문제의식에 기반하여 '진정한' 코드 복잡성의 다면적 본질을 심층적으로 분석하고자 한다. 먼저 순환 복잡도(Cyclomatic Complexity)와 코드 라인 수(Lines of Code)와 같은 전통적인 측정 지표의 정의와 한계를 비판적으로 검토한다. 이어서 인지 복잡성(Cognitive Complexity), 유지보수성(Maintainability), 가독성(Readability), 테스트 용이성(Testability) 등 현대적인 관점에서 복잡성을 재조명한다. 또한, 마이크로서비스와 모놀리식 아키텍처, 디자인 패턴, 코드 의존성 및 결합도와 같은 시스템 수준의 요인들이 복잡성에 미치는 영향을 분석한다. 나아가 문제 영역 자체의 본질적 복잡성(Essential Complexity)과 개발 과정에서 발생하는 우발적 복잡성(Accidental Complexity)을 구분하고, 이러한 다양한 관점을 종합하여 오늘날 코드 복잡성을 구성하는 요소들에 대한 다각적인 이해를 구축한다. 최종적으로, 현대 소프트웨어 개발 환경에서 코드 복잡성을 효과적으로 관리하기 위한 실용적인 전략과 모범 사례를 제시하는 것을 목표로 한다. 이는 단순히 과거 지표의 부적절함을 지적하는 것을 넘어, 현대 소프트웨어의 특성을 반영하는 복잡성에 대한 깊이 있는 통찰과 실질적인 관리 방안을 모색하는 과정이 될 것이다.

I. 전통적 관점: 순환 복잡도와 코드 라인 수

소프트웨어 복잡성을 정량화하려는 초기 시도는 주로 코드의 구조적 특성에 초점을 맞추었다. 대표적인 지표인 순환 복잡도와 코드 라인 수는 수십 년간 널리 사용되어 왔으며, 특정 측면에서 유용성을 인정받았다.

가. 순환 복잡도(Cyclomatic Complexity, CC): 기원, 원리, 목적

순환 복잡도는 1976년 Thomas J. McCabe, Sr.에 의해 개발된 정량적 소프트웨어 메트릭이다.4 이는 프로그램 소스 코드를 통한 선형적으로 독립적인 경로의 수를 측정하여 프로그램의 복잡성을 나타낸다.4 McCabe는 모듈화의 정량적 기반을 제공하고 테스트하거나 유지보수하기 어려운 소프트웨어 모듈을 식별할 수 있는 수학적 기법의 필요성을 인식했다.7

순환 복잡도는 제어 흐름 그래프(Control Flow Graph)를 사용하여 시각화될 수 있으며, 여기서 노드는 명령어 블록을, 엣지는 제어 흐름을 나타낸다.6 계산 공식은 일반적으로 M = E - N + 2P (E: 엣지 수, N: 노드 수, P: 연결된 컴포넌트 수)로 표현되거나, 단일 진입점과 단일 탈출점을 가진 구조적 프로그램의 경우 M = 결정 지점(Decision Points) 수 + 1로 단순화될 수 있다.4 예를 들어, 단일 조건의 if 문은 두 개의 경로(참/거짓)를 생성하므로 복잡도는 2가 되며, 중첩된 if 문이나 두 개의 조건을 가진 if 문은 복잡도 3을 생성한다.4 McCabe는 원래 1-10은 단순하고 위험이 적음, 11-20은 더 복잡하고 중간 정도 위험, 21-50은 복잡하고 높은 위험, 50 초과는 테스트 불가능하고 매우 높은 위험으로 분류했으며, 이 임계값은 여전히 참조된다.4

McCabe의 주된 목적은 테스트 및 유지보수가 어려운 모듈을 식별하는 것이었다.4 특히 순환 복잡도는 필요한 최소 테스트 케이스 수, 즉 모든 실행 경로를 최소 한 번 이상 커버하기 위해 필요한 테스트 수를 나타내는 지표로 강하게 연관되어 테스트 노력과 밀접한 관련이 있다.5

나. 코드 라인 수(Lines of Code, LOC): 크기의 척도, 반드시 복잡성은 아님

코드 라인 수(LOC 또는 SLOC)는 소스 텍스트의 라인 수를 세어 소프트웨어의 크기를 측정하는 가장 기본적인 방법이다.10 주석이나 빈 줄을 포함하는 물리적 LOC와 실제 실행 가능한 구문만 계산하는 논리적 LOC로 구분될 수 있으며, 프로그래밍 언어, 코딩 스타일, 계산 방식에 따라 값이 크게 달라질 수 있다.11 예를 들어, 동일한 기능을 구현하더라도 Python은 Java나 C++보다 훨씬 적은 LOC를 사용할 수 있다.12

역사적으로 LOC는 COCOMO와 같은 노력 추정 모델의 입력 값이나 유사한 프로젝트 간의 크기 비교 기준으로 사용되었다.10 또한, 테스트 커버리지 밀도(테스트된 LOC / 전체 LOC)를 계산하는 데 활용되기도 한다.10

흥미롭게도, McCabe는 순환 복잡도를 제안할 당시 LOC를 복잡성 측정 지표로 사용하는 것을 명시적으로 거부했다. 그는 코드 길이와 모듈의 제어 흐름 복잡성 사이에 명확한 관계가 없다고 보았다.7

다. 초기 가치 인식 및 활용

이러한 전통적인 메트릭들은 초기에 상당한 가치를 인정받았다. 순환 복잡도는 위험 평가 도구로 빠르게 채택되었다. 높은 CC 값은 높은 결함 밀도와 상관관계가 있는 것으로 나타났으며 9, 코드 검토와 같은 추가적인 품질 보증 활동이 필요한 위험한 모듈을 식별하는 데 사용되었다.9

개발 지침으로서, McCabe는 개발 중에 모듈의 CC를 특정 임계값(종종 10 또는 15) 이하로 제한하여 복잡한 함수를 더 작고 관리하기 쉬운 단위로 분할하도록 권장했다.4 이는 일부 개발 방법론에서 수용된 관행이 되었다.4

테스팅 영역에서 CC는 기반 경로 테스팅(basis path testing)에 필요한 최소 테스트 케이스 수를 직접적으로 알려주는 중요한 지표였다.5 이는 테스트 범위를 정량화하고 테스트 노력을 계획하는 데 도움을 주었다.6

LOC 역시 복잡성 측정에는 한계가 있지만, 유사한 환경에서 구축된 애플리케이션 간의 상대적 크기를 가늠하거나 10 전체 코드베이스 대비 테스트 커버리지 비율을 파악하는 데 여전히 유용하게 사용된다.10

이러한 전통적인 메트릭들은 구조적 프로그래밍이 지배적이던 시대에 테스트, 유지보수 노력, 위험 관리와 같은 소프트웨어 개발 프로세스의 특정 측면을 정량화하려는 요구에서 비롯되었다. 그 기반은 주로 코드의 구조적 특성과 정량적 계산에 있으며 4, 이는 당시 중요하게 여겨졌던 절차적 코드 구조의 복잡성을 통제하는 데 어느 정도 기여했다. 하지만 초기부터 이러한 메트릭들이 완벽한 지표가 아니라는 암묵적인 이해가 존재했다. 예를 들어, McCabe 자신이 switch 문이 개념적 어려움을 반드시 증가시키지 않으면서도 CC를 부풀릴 수 있음을 인정하고 예외를 제안한 것은 9 순전히 구조적인 관점의 한계를 시사하며 후대의 비판을 예고하는 것이었다.

II. 기반의 균열: 전통적 메트릭의 한계

수십 년간 활용되어 온 순환 복잡도(CC)와 코드 라인 수(LOC)는 현대 소프트웨어 개발의 복잡성을 포착하는 데 점차 한계를 드러내고 있다. 이는 메트릭 자체의 내재적 문제와 더불어 소프트웨어 개발 환경의 급격한 변화에서 기인한다.

가. 메트릭과 현실의 간극: 인지 부하, 중첩, 구조 무시

순환 복잡도의 맹점: CC의 가장 큰 비판점 중 하나는 인간의 코드 이해 과정, 즉 인지적 부하를 제대로 반영하지 못한다는 것이다. 동일한 CC 값을 가진 두 함수가 이해도 측면에서는 현저히 다를 수 있다.1 대표적인 예로, 단순한 switch-case 문과 복잡하게 중첩된 논리(예: 버블 정렬 알고리즘)가 비슷한 CC 점수를 받을 수 있지만, 후자가 훨씬 이해하기 어렵다.1 특히 CC는 코드의 중첩 깊이(nesting depth)를 적절히 반영하지 못하는데 1, 깊은 중첩은 인간의 작업 기억(working memory)에 큰 부담을 주어 코드 추적을 어렵게 만들고 오류 발생 가능성을 높인다.1 또한, CC는 코드 구조 개선 노력이나 goto와 같은 비구조적 기법 사용 여부에 둔감하다.7

LOC의 피상성: LOC는 복잡성이나 생산성을 측정하는 데 매우 부적절한 지표로 널리 인식된다.10 언어 간의 표현력 차이로 인해 동일 기능도 LOC가 크게 달라질 수 있으며 (예: Python vs. Java) 11, 숙련된 개발자는 종종 더 적은 코드로 더 많은 기능을 효율적으로 구현한다 ('양보다 질').12 오히려 리팩토링을 통해 LOC를 줄이는 것이 코드 품질을 향상시키는 긍정적인 활동인 경우가 많다.13

예측력 부족: 여러 연구와 경험적 증거들은 CC나 LOC가 실제 인지되는 복잡성, 유지보수 문제, 심지어 결함 예측력 측면에서도 다른 요인이나 새로운 메트릭에 비해 상관관계가 약하거나 부족함을 시사한다.1 CodeScene의 머신러닝 알고리즘이 CC의 예측 가치를 낮게 평가한 사례나 1, 일부 연구에서 결함 예측에 LOC가 CC보다 더 나은 성능을 보였다는 결과는 7 이러한 한계를 뒷받침한다.

나. 현대적 맥락의 도전: 패러다임, 언어, 규모

새로운 패러다임: 함수형 프로그래밍(작고 조합 가능한 함수), 비동기 프로그래밍(콜백, Promise, async/await), 반응형 프로그래밍, 이벤트 기반 아키텍처 등 현대적인 프로그래밍 패러다임은 단순한 경로 계산이나 라인 수 계산으로는 포착하기 어려운 종류의 복잡성을 도입한다.3 재귀적이거나 멀티스레딩 코드의 복잡성은 눈에 보이는 구조보다는 실행의 재귀적 또는 병렬적 특성에 있다.2

언어의 진화: 현대 언어들은 리스트 컴프리헨션, 람다 표현식 등 강력하고 표현력 있는 기능을 제공한다. 이는 LOC를 줄일 수 있지만, 복잡한 로직을 몇 줄에 응축시켜 전통적인 메트릭이 시사하는 것과는 다른 방식으로 가독성에 영향을 미칠 수 있다.12 또한, 현대 언어의 다양한 구문으로 인해 코드를 제어 흐름 그래프로 명확하게 매핑하는 것이 모호해질 수 있다.7

규모와 상호연결성: 현대 소프트웨어 시스템은 방대한 코드베이스를 가지며 2, 마이크로서비스와 같이 분산된 컴포넌트 간의 복잡한 상호작용을 포함하는 경우가 많다.3 이러한 시스템의 전체 복잡성은 개별 모듈의 내부 복잡성(CC나 LOC로 측정되는)보다는 모듈 간의 의존성, 인터페이스, 통신 방식에서 더 크게 비롯된다.19

프레임워크와 라이브러리: 프레임워크와 외부 라이브러리에 대한 높은 의존성은 애플리케이션 자체의 CC나 LOC에는 반영되지 않는 또 다른 차원의 복잡성을 추가한다. 프레임워크의 동작 방식을 이해하고, 설정을 관리하며, 의존성 충돌을 해결하는 등의 작업은 상당한 노력을 요구한다.20

다. 오용과 오해의 위험

생산성 착각: LOC를 개발자 생산성 측정에 사용하는 것은 매우 잘못된 접근이라는 강력한 공감대가 형성되어 있다.10 이는 버그 수정처럼 적은 라인 변경에 많은 시간이 소요되는 복잡한 작업의 가치를 무시하며 10, 단순히 코드 라인 수를 늘리려는 부정적인 행동을 조장할 수 있다.16

메트릭 게임: LOC나 심지어 CC 같은 메트릭을 성과 평가와 직접 연동하면, 개발자들은 메트릭 점수를 높이기 위해 코드를 불필요하게 장황하게 작성하거나, 리팩토링을 피하거나, 의미 없는 변경을 자주 하는 등의 행동을 할 수 있다.16 이는 오히려 코드 복잡성을 증가시키고 기술 부채를 쌓는 결과를 초래할 수 있다.16

과도한 단순화: CC나 LOC의 임계값을 코드 품질의 절대적인 기준으로 삼는 것은 위험하다. 이는 코드의 가독성, 유지보수성, 설계의 적절성, 프로젝트의 특정 맥락 등 중요한 질적 측면을 간과하게 만든다.8 메트릭은 판단을 돕는 도구일 뿐, 판단 자체를 대체해서는 안 된다.8

전통적인 메트릭의 핵심 한계는 코드의 *구문적 구조(syntactic structure)*에 초점을 맞추고, 코드의 *의미(semantic meaning)*나 이를 이해하는 데 필요한 *인지적 노력(cognitive effort)*을 간과한다는 점에서 비롯된다. 이러한 불일치는 다양한 형태의 추상화와 조합을 우선시하는 현대 프로그래밍 관행 하에서 더욱 두드러진다. CC는 제어 구조(IF, LOOP 등)에 기반한 경로를 계산하고 1, LOC는 단순히 라인 수를 센다.10 둘 다 구문적이다. 반면, 이들에 대한 비판은 꾸준히 '이해도'를 제대로 측정하지 못한다는 점을 지적하는데 1, 이는 인지적, 의미적 문제이다. 예를 들어 함수형 프로그래밍은 함수당 CC는 낮을 수 있지만, 그 조합을 이해하기 위해서는 다른 종류의 인지 능력이 요구될 수 있다.17 현대 소프트웨어가 목표를 달성하는 방식 자체가 CC가 설계되었던 시대의 단순한 절차적 제어 흐름과 달라지면서, 이들 메트릭의 부적절성이 커지는 것이다.

더 나아가, LOC와 같은 단순한 메트릭을 생산성 측정에 오용하는 현상은 소프트웨어 공학의 근본적인 도전 과제, 즉 '가치 창출'을 측정하는 어려움을 반영한다. 소프트웨어 개발은 본질적으로 창의적인 문제 해결 활동이므로, 자동화하기 쉽지만 피상적인 지표로 결과물을 정량화하려는 시도는 종종 역효과를 낳는다. 잘못된 행동을 유도하고 잠재적으로 품질을 저해하는 것이다.16 이는 쉽게 측정 가능한 결과물(타이핑된 라인 수)과 실제 목표(문제를 효과적이고 유지보수 가능하게 해결하는 것) 사이의 괴리를 보여준다. 따라서 의미 있는 평가는 정량화하기는 더 어렵지만 더 관련성 높은 결과(요구사항 충족 22, 전달된 가치 23)와 질적 측면(유지보수성, 설계)을 고려해야 함을 시사한다.

결국 CC와 LOC의 한계는 단순히 기술적인 문제를 넘어, 업계가 중요하게 여기는 가치의 역사적 변화를 반영한다. 초기에는 절차적 복잡성을 제어하고 기본적인 테스트 용이성을 확보하는 데 중점을 두었다. 현대에는 대규모 시스템 관리, 다양한 팀을 위한 인지 부하 감소, 빠른 진화에 대한 요구가 커지면서 다른 종류의 측정 기준과 관리 방식이 필요하게 되었다.

III. 코드 복잡성에 대한 현대적 관점

전통적인 메트릭의 한계가 명확해짐에 따라, 코드 복잡성을 평가하는 새로운 관점들이 주목받고 있다. 이들은 단순히 코드 구조를 넘어 인간의 인지 과정, 유지보수의 용이성, 효과적인 테스트 가능성 등을 복잡성의 핵심 요소로 간주한다.

가. 인지 복잡성(Cognitive Complexity): 이해도 정량화 시도

동기: 인지 복잡성은 SonarSource에 의해 개발되었으며, 순환 복잡도(CC)가 코드의 '이해도'를 측정하는 데 실패한다는 단점을 직접적으로 해결하기 위해 등장했다.25 이 메트릭의 목표는 인간이 특정 코드 조각을 읽고 이해하는 데 필요한 정신적 노력을 정량화하는 것이다.25

측정 규칙: 인지 복잡도 계산의 핵심 원칙은 다음과 같다:

가독성 있는 축약 무시: 여러 구문을 가독성 있게 하나로 압축하는 구조(예: 단순 메서드 호출)는 복잡도를 증가시키지 않는다.26
선형 흐름 중단 시 증가: 코드의 선형적 흐름을 깨는 구조(예: 루프, 조건문, switch, 예외 처리, goto, 재귀, &&나 || 같은 다중 논리 연산자)마다 복잡도가 증가한다.25
중첩 페널티: 흐름을 깨는 구조가 다른 구조 내부에 중첩될 때 추가적인 페널티가 부과된다.25 이는 CC의 주요 약점 중 하나였던 중첩 깊이 문제를 직접적으로 다룬다.

CC와의 비교: 인지 복잡도는 CC와 명확히 대비된다. CC는 테스트 용이성(최소 테스트 경로 수)에 초점을 맞추는 반면, 인지 복잡도는 가독성 및 이해도(인지적 노력)에 초점을 맞춘다.25 예를 들어, 단순한 switch 문은 CC는 높지만 인지 복잡도는 낮을 수 있으며, 반대로 기능을 작은 함수들로 분해하는 리팩토링은 CC를 증가시킬 수 있지만 인지 복잡도는 감소시킬 수 있다.1 다음 표는 두 메트릭의 주요 차이점을 요약한다.

표 1: 순환 복잡도와 인지 복잡도 비교

특징	순환 복잡도 (Cyclomatic Complexity)	인지 복잡도 (Cognitive Complexity)
주요 목표	테스트 용이성 (Testability)	이해 용이성 (Understandability)
측정 초점	제어 흐름 경로 수 (Number of control flow paths)	인지적 노력 (Cognitive effort)
주요 페널티 요인	분기 (Branches: if, loop, switch case 등)	흐름 중단 (Flow breaks) + 중첩 (Nesting)
단순 구조 처리	switch 등 단순 구조도 경로 수에 따라 높게 측정될 수 있음 1	가독성을 해치지 않는 선형 흐름 중단은 낮게 평가, 중첩에 민감 26
주요 활용 사례	테스트 계획 (최소 테스트 케이스 수 결정) 5	코드 가독성 및 유지보수성 평가, 리팩토링 대상 식별 17
참고 자료	1	25

한계: 인지 복잡도 역시 하나의 메트릭이며, 인간 인지의 모든 미묘함이나 특정 언어 기능의 어려움(예: 포인터 연산, 고급 타입 시스템)까지 포착하지는 못한다.25 여전히 구조 기반의 측정이며, 최종적인 판단에는 인간의 경험과 맥락 이해가 필수적이다.25

나. 유지보수성과 가독성을 핵심 관심사로

정의 및 중요성: 유지보수성은 코드를 수정하고 업데이트하기 쉬운 정도를, 가독성은 코드를 읽고 이해하기 쉬운 정도를 의미한다.8 이 두 요소는 소프트웨어 생명주기 전반에 걸쳐 비용, 시간, 결함률에 지대한 영향을 미치는 핵심 품질 속성이다.20 낮은 가독성과 유지보수성은 복잡성을 인지하는 주요 원인이 된다.8

복잡성과의 관계: 일반적으로 복잡성(구조적이든 인지적이든)과 가독성/유지보수성 사이에는 강한 음의 상관관계가 관찰된다. 즉, 복잡한 코드는 이해하고 안전하게 수정하며 디버깅하기 어렵다.15 연구 결과에서도 가독성과 복잡성 간의 높은 음의 상관관계(-0.974)가 보고된 바 있으며 30, 이는 복잡한 컴포넌트가 유지보수 및 이해하기 훨씬 어렵다는 것을 확인시켜 준다.30

영향 요인: 단순한 메트릭 점수 외에도 명확한 이름 규칙, 일관된 코드 스타일, 적절한 주석, 모듈화된 설계, 표준 준수, 낮은 결합도, 높은 응집도 등 다양한 요인이 가독성과 유지보수성에 영향을 미친다.8 가독성은 문제 영역 자체의 복잡성(본질적 복잡성)과 달리 엔지니어가 통제할 수 있는 '우발적 속성'으로 간주되기도 한다.30

다. 테스트 용이성: 경로 수를 넘어서

현대적 관점: 테스트 용이성은 단순히 CC가 나타내는 경로 커버리지 이상의 의미를 갖는다. 코드가 얼마나 쉽게 테스트 환경을 구성하고, 단위(unit)를 격리하여 테스트할 수 있는지에 대한 개념으로 확장된다.8

테스트 용이성을 위한 설계: 설계 결정은 테스트 용이성에 큰 영향을 미친다. 의존성 주입(Dependency Injection, DI)은 컴포넌트를 분리하고 테스트 중에 실제 의존성을 목(Mock) 객체나 스텁(Stub)으로 쉽게 교체할 수 있게 함으로써 테스트 용이성을 높이는 핵심 디자인 패턴이다.32 이는 테스트 대상 단위를 효과적으로 격리시킨다.32

모킹(Mocking): 모킹은 실제 의존성의 동작을 시뮬레이션하는 테스트 대역(test double)을 만드는 기술이다.32 DI는 이러한 목 객체를 쉽게 주입할 수 있도록 하여 테스트 코드 작성을 용이하게 한다.32

복잡성과 테스트 용이성 연관성: 복잡한 코드(높은 CC, 높은 인지 복잡도, 강한 결합, 숨겨진 의존성)는 본질적으로 철저하고 안정적으로 테스트하기 어렵다.2 테스트하기 어려운 코드는 종종 근본적인 설계 문제를 내포하고 있다는 신호일 수 있다.36

인지 복잡도의 등장은 소프트웨어 개발에서 초점이 단순히 기계가 실행 가능한 경로(CC)에서 해당 경로와 코드의 의도를 이해하는 데 필요한 인간의 인지적 노력으로 이동하고 있음을 보여주는 중요한 변화이다. 이는 코드베이스가 커지고 팀이 분산됨에 따라 코드를 이해하는 비용이 전체 개발 비용과 위험의 주요 동인이 되고 있다는 인식이 커지고 있음을 반영한다.17

또한, 테스트 용이성을 위해 설계하는 것(예: DI 사용)이 종종 더 모듈화되고, 덜 결합되며, 잠재적으로 전반적으로 덜 복잡한 설계로 이어진다는 점은 주목할 만하다. 이는 긍정적인 피드백 루프를 생성한다. 테스트하기 어렵다는 것은 종종 높은 결합도나 낮은 응집도와 같은 설계 문제의 증상이다.33 따라서 테스트 용이성을 향상시키는 관행(DI, 명확한 인터페이스)은 복잡성의 일반적인 원인(결합, 불분명한 책임)을 직접적으로 해결하는 경향이 있다.

하지만 인지 복잡도가 CC보다 이해도를 더 잘 반영하더라도 여전히 구조적 메트릭이라는 점을 인지해야 한다. 실제 인지 부하는 도메인 지식, 이름 명명의 질, 주석의 유용성, 코드의 일관성, 개별 개발자의 경험과 같은 비구조적 요인에 의해서도 영향을 받는다.2 현재의 자동화된 메트릭들은 이러한 측면을 완전히 포착하기 어렵다. 따라서 인지 복잡도와 같은 메트릭은 유용한 지표이지만, 이러한 비구조적 측면을 다루는 질적 평가(예: 코드 리뷰)와 좋은 개발 관행으로 보완되어야 한다.

IV. 더 넓은 시야: 아키텍처, 디자인, 의존성

코드 복잡성은 개별 함수나 클래스 수준을 넘어 시스템 전체의 구조와 상호작용 방식에 의해 크게 영향을 받는다. 아키텍처 선택, 디자인 패턴 적용, 그리고 코드 간의 의존성 관리는 복잡성의 성격과 위치를 근본적으로 결정짓는 요소들이다.

가. 아키텍처의 영향: 모놀리스 대 마이크로서비스

모놀리식 아키텍처(Monolithic Architecture): 단일 코드베이스와 배포 단위를 특징으로 하는 전통적인 구조이다.20 초기에는 개발, 배포, 테스트, 디버깅이 상대적으로 단순하다는 장점이 있다.38 그러나 시스템 규모가 커짐에 따라 내부 복잡성이 증가하고, 컴포넌트 간의 강한 결합으로 인해 작은 변경이 시스템 전체에 예기치 않은 영향을 미치는 파급 효과(ripple effect)가 발생하기 쉽다.38 이는 개발 속도를 저하시키고, 특정 부분만 독립적으로 확장하기 어렵게 만들며, 새로운 기술 도입에 장벽이 되기도 한다.20

마이크로서비스 아키텍처(Microservices Architecture): 애플리케이션을 작고 독립적으로 배포 가능한 서비스들의 집합으로 구성하는 접근 방식이다.37 각 서비스는 자체적인 비즈니스 로직과 데이터 저장소를 가질 수 있으며, 네트워크를 통해 잘 정의된 인터페이스로 통신한다.37 주요 장점으로는 서비스별 독립적인 확장, 배포, 기술 선택의 유연성, 높은 장애 격리(fault isolation), 자율적인 팀 구성 지원 등이 있다.19 각 서비스 내부의 코드베이스는 상대적으로 단순해질 수 있다.38

복잡성 트레이드오프(Complexity Trade-offs): 중요한 점은 마이크로서비스가 복잡성을 제거하는 것이 아니라, 복잡성의 형태를 바꾸고 이동시킨다는 것이다.38 개별 서비스의 내부 코드 복잡성은 줄어들 수 있지만, 전체 시스템 수준의 복잡성은 분산 시스템 고유의 문제들로 인해 증가한다. 여기에는 네트워크 지연 및 신뢰성 문제, 서비스 간 통신 및 데이터 일관성 유지의 어려움, 배포 및 모니터링의 운영 오버헤드 증가, 분산 트랜잭션 테스트의 복잡성, 서비스 검색(discoverability) 문제 등이 포함된다.19 따라서 마이크로서비스 전환은 단순히 기술적 유행을 따르기보다 명확한 기술적, 조직적 요구에 기반해야 하며 19, 때로는 잘 구조화된 "모듈형 모놀리스(modular monolith)"가 더 적합한 대안이 될 수도 있다.19

표 2: 아키텍처 복잡성 트레이드오프: 모놀리스 vs. 마이크로서비스

측면	모놀리식 아키텍처 (Monolithic Architecture)	마이크로서비스 아키텍처 (Microservices Architecture)
내부 코드 복잡성	높거나 증가하는 경향 20	서비스별로는 낮음 38
시스템/상호작용 복잡성	낮음 (내부 호출)	높음 (네트워크 통신, 분산 시스템 문제) 19
운영 복잡성	상대적으로 낮음 (단일 배포/모니터링 대상) 38	높음 (다수 서비스 관리, 인프라 복잡성 증가) 39
배포 복잡성	단순한 단위 38	조정된 서비스 배포 필요 39
확장성	전체 단위 확장 (Coarse-grained) 38	서비스별 독립 확장 (Fine-grained) 38
기술 유연성	낮음 (단일 기술 스택 제약) 38	높음 (서비스별 최적 기술 선택 가능) 39
팀 자율성	낮음 (코드베이스 공유 및 의존성)	높음 (독립적인 개발 및 배포 가능) 38
참고 자료	20	19

나. 디자인 패턴: 복잡성 관리 도구인가, 또 다른 복잡성인가?

잠재적 이점: 잘 알려진 디자인 패턴은 일반적인 문제에 대한 표준적이고 검증된 해결책을 제공함으로써 복잡성을 관리하는 데 도움을 줄 수 있다.8 패턴은 코드 구조를 개선하고, 재사용성을 높이며, 특정 유형의 복잡한 로직(예: 상태 패턴이나 전략 패턴을 이용한 복잡한 조건문 처리 6)을 단순화할 수 있다. 또한, 패턴은 개발자 간의 의사소통을 위한 공통 어휘를 제공한다.8

잠재적 단점: 그러나 디자인 패턴의 무분별한 적용은 오히려 복잡성을 증가시킬 수 있다. 패턴은 종종 추가적인 추상화 계층, 더 많은 클래스나 인터페이스, 간접 호출 등을 도입하여 코드 이해를 어렵게 만들 수 있다.21 필요하지 않은 곳에 패턴을 적용하는 오버 엔지니어링은 우발적 복잡성을 낳는다.21 또한, 패턴 자체를 이해하고 나중에 제거하는 것도 복잡한 작업이 될 수 있다.44 SOLID 원칙과 같은 설계 원칙들도 잘못 적용될 경우 불필요한 복잡성을 추가할 수 있다는 비판이 제기된다.21

맥락의 중요성: 패턴의 가치는 특정 문제와 맥락에 따라 크게 달라진다. 패턴이 제공하는 유연성이나 구조가 현재 및 예상되는 미래의 요구사항에 정말로 필요한지를 신중하게 평가해야 한다.44

다. 의존성의 무게: 결합도와 응집도

정의: 결합도(Coupling)는 소프트웨어 모듈 간의 상호 의존성 정도를 나타낸다. 즉, 한 모듈의 변경이 다른 모듈의 변경을 요구하는 정도이다.46 응집도(Cohesion)는 단일 모듈 내의 요소들이 얼마나 서로 관련되어 있고 단일 목적을 위해 집중되어 있는지를 나타낸다.46 일반적인 설계 목표는 낮은 결합도와 높은 응집도(Low Coupling, High Cohesion)를 추구하는 것이다.46

복잡성에 미치는 영향: 높은 결합도는 시스템 복잡성을 크게 증가시킨다. 변경 사항이 시스템 전체로 퍼져나가 예측하기 어렵고, 이해, 수정, 테스트를 어렵게 만든다.46 강하게 결합된 시스템은 변경에 취약하다. 반면, 낮은 응집도는 모듈이 서로 관련 없는 너무 많은 책임을 가지고 있음을 시사하며, 이는 모듈의 이해, 재사용, 유지보수를 어렵게 만든다.46 Feature Envy(다른 클래스의 데이터나 메서드를 과도하게 사용하는 것)나 Message Chains(객체가 다른 객체를 통해 연쇄적으로 메시지를 보내는 것)와 같은 코드 스멜(code smell)은 종종 결합도 및 응집도 문제와 관련이 있다.48

시스템 전반의 효과: 내부 모듈 간의 의존성뿐만 아니라 외부 라이브러리, 프레임워크, 다른 서비스와의 의존성도 전체 시스템 복잡성에 기여한다.21 이러한 의존성을 관리하고, 그 영향을 파악하며, 호환성을 보장하는 것은 현대 소프트웨어 개발의 주요 과제 중 하나이다.8

결합도 관리: 직접적인 결합도를 줄이기 위해 인터페이스 기반 설계, 콜백, 의존성 역전 원칙(Dependency Inversion Principle), 이벤트 기반 통신과 같은 기법들이 사용된다.34 Martin Fowler는 특히 시스템의 상위 수준 모듈 간의 결합도를 관리하는 것이 중요하다고 강조한다.47

코드 복잡성을 개별 코드 조각만으로는 완전히 이해할 수 없다는 점이 분명해진다. 아키텍처 선택(모놀리스 vs. 마이크로서비스)과 시스템 내 의존성 네트워크는 복잡성의 성격과 위치를 근본적으로 형성한다. 모놀리스는 복잡성을 내부로 집중시키는 경향이 있고 20, 마이크로서비스는 복잡성을 서비스 간의 상호작용과 운영 환경으로 분산시킨다.38 아키텍처와 관계없이 모듈 간의 높은 결합도는 시스템 전체의 취약성을 야기한다.46 이는 복잡성이 단순히 코드 구조의 문제가 아니라 거시적 설계 결정에 크게 영향을 받는 시스템적 속성임을 보여준다.

또한, 복잡성을 관리하기 위한 많은 기법들(마이크로서비스, 디자인 패턴, 디커플링)은 종종 트레이드오프를 수반한다. 이들은 한 종류의 복잡성(예: 내부 코드 복잡성)을 해결하는 대신 다른 종류의 복잡성(예: 운영 복잡성, 추상화 오버헤드)을 도입하는 경우가 많다.38 보편적으로 '최선'인 접근 방식은 없으며, 선택은 항상 특정 문제, 팀 역량, 장기 목표 등 맥락에 따라 이루어져야 한다. 이는 유행하는 기술을 맹목적으로 적용하기보다 신중한 분석이 필요함을 시사한다.

결합도 관리는 클래스 설계(DI, 인터페이스 34)부터 상위 모듈(Fowler 47), 아키텍처 스타일(마이크로서비스 38)에 이르기까지 다양한 추상화 수준에서 핵심 주제로 반복적으로 등장한다. 이는 의존성을 제어하는 것이 전체 시스템의 복잡성과 유지보수성을 관리하는 데 가장 중요한 요소 중 하나임을 시사한다. 이해하기 쉽고 적응 가능한 시스템을 구축하는 데 있어 의존성 관리는 근본적인 중요성을 갖는다.

V. 본질적 복잡성 대 우발적 복잡성: 노력 집중하기

소프트웨어 복잡성을 효과적으로 관리하기 위해서는 복잡성의 근원을 이해하는 것이 중요하다. Fred Brooks가 제시한 '본질적 복잡성'과 '우발적 복잡성'의 구분은 복잡성의 어떤 측면에 노력을 집중해야 하는지에 대한 전략적 틀을 제공한다.

가. Brooks의 이분법: 내재된 복잡성 대 부가된 복잡성

기원: 이 개념은 컴퓨터 아키텍트이자 튜링상 수상자인 Fred Brooks가 1986년에 발표한 영향력 있는 논문 "No Silver Bullet—Essence and Accident in Software Engineering"에서 비롯되었다.49 Brooks는 하드웨어 공학에 비해 소프트웨어 공학의 생산성 향상이 더딘 이유를 분석하면서 이 구분을 제시했다.

본질적 복잡성(Essential Complexity): 문제 영역 자체의 고유한 어려움에서 비롯되는 복잡성이다.45 이는 사용자가 요구하는 기능, 즉 소프트웨어가 반드시 수행해야 하는 작업들의 복잡성이다.51 이 복잡성은 문제를 변경하지 않는 한 제거할 수 없다.45 예를 들어, 복잡한 비즈니스 규칙, 정교한 과학적 계산, 특정 문제의 본질적인 상태 관리 요구 등이 본질적 복잡성에 해당한다.30

우발적 복잡성(Accidental Complexity): 개발 과정에서 사용되는 도구, 기술, 설계 결정 등으로 인해 부가적으로 발생하는 복잡성이다.49 이는 문제 자체에 내재된 것이 아니라, 개발자들이 해결 과정에서 의도치 않게 만들어내는 복잡성이다.49 따라서 이 복잡성은 엔지니어들이 잠재적으로 수정하거나 피할 수 있다.50 예를 들어, 과도하게 복잡한 추상화, 잘못된 설계 선택, 다루기 힘든 프레임워크, 복잡한 빌드/배포 프로세스, 불명확한 코드, 불필요한 의존성 등이 우발적 복잡성을 증가시킨다.20

나. 우발적 복잡성 인식 및 감소

Brooks의 주장: Brooks는 고급 프로그래밍 언어가 어셈블리 언어의 세부 사항을 추상화하는 등 우발적 복잡성을 줄이는 데 상당한 진전이 있었으며, 따라서 남은 과제는 주로 본질적 복잡성에 있다고 주장했다. 이 때문에 소프트웨어 생산성에서 획기적인(order-of-magnitude) 향상을 기대하기는 어렵다고 보았다.50

현대적 관련성: Brooks의 지적에도 불구하고, 현대 소프트웨어 개발에서도 여전히 상당한 우발적 복잡성이 발생하고 있다.20 부적절한 도구나 프레임워크 선택 20, 잘못된 아키텍처 결정 20, 불필요한 디커플링 21, 과도한 의존성 21, 코드의 명확성 부족 20, 시기상조의 최적화나 일반화 21, 특정 기술이나 방법론을 맹목적으로 따르는 '카고 컬트(cargo culting)' 현상 53 등이 그 원인이 될 수 있다.

노력 집중: 본질적 복잡성은 좋은 설계와 명확한 이해를 통해 관리되어야 하는 반면, 우발적 복잡성은 적극적으로 최소화해야 한다.18 이것이 엔지니어들이 유지보수성, 이해도, 생산성을 향상시키기 위해 가장 큰 영향력을 발휘할 수 있는 영역이다. 전략에는 단순화 추구, 적절한 도구 선택, 명확성 강조, 불필요한 요소 제거 등이 포함된다.21

본질적/우발적 복잡성 구분은 복잡성 관리에 중요한 전략적 틀을 제공한다. 이는 개발 과정에서 스스로 만들어낸 어려움(우발적)을 제거하는 데 노력을 기울이고, 피할 수 없는 어려움(본질적)은 효과적으로 모델링하고 관리하는 데 집중하도록 방향을 제시한다. Brooks는 대부분의 생산성 향상이 우발적 복잡성 감소에서 왔다고 주장했지만 50, 현대 개발에서도 여전히 최적이 아닌 도구, 프로세스, 설계로 인해 상당한 우발적 복잡성이 발생한다.20 따라서 본질적 복잡성을 다루는 것이 어렵다 하더라도, 부주의하게 도입된 우발적 복잡성을 부지런히 식별하고 제거하는 것만으로도 상당한 가치를 창출할 수 있다. 이것이 개선을 위한 가장 실질적인 경로이다.

하지만 본질적 복잡성과 우발적 복잡성 사이의 경계는 때때로 모호하고 맥락에 따라 달라질 수 있다. 예를 들어, 특정 복잡한 프레임워크 기능이 필요하다고 여겨지는 것이 본질적 복잡성처럼 보일 수 있다. 그러나 요구사항을 더 간단하게 충족할 수 있거나 해당 프레임워크 자체가 작업에 비해 불필요하게 복잡하다면, 이는 우발적 복잡성으로 드러날 수 있다. 이는 요구사항과 솔루션 선택을 비판적으로 평가하여 우발적 복잡성을 본질적 복잡성으로 오인하지 않도록 주의해야 함을 시사한다.

VI. 오늘날의 '진정한' 코드 복잡성 정의

전통적인 메트릭의 한계와 현대 소프트웨어 개발의 다면성을 고려할 때, '진정한' 코드 복잡성은 단일 지표로 정의될 수 없다. 이는 코드 자체의 구조적 특성뿐만 아니라, 이를 이해하고 다루는 인간의 인지 과정, 시스템 전체의 상호작용, 그리고 해결하려는 문제의 본질까지 아우르는 다차원적인 개념이다.

가. 다차원적 구성 요소: 요인 종합

단일 메트릭을 넘어서: 순환 복잡도, LOC, 심지어 인지 복잡도와 같은 어떤 단일 숫자도 '진정한' 복잡성의 전체 그림을 포착할 수는 없다.8 진정한 복잡성은 여러 요소가 복합적으로 작용한 결과이다.

종합적 정의: 현대적 관점에서 코드 복잡성을 구성하는 주요 차원들은 다음과 같이 종합될 수 있다:

구조적 복잡성 (Structural Complexity): 제어 흐름의 얽힘, 코드 구성 방식의 복잡성. 순환 복잡도, 중첩 깊이(Nesting Depth) 등이 부분적으로 측정한다.4
인지 복잡성 (Cognitive Complexity): 코드의 로직, 흐름, 의도를 파악하는 데 필요한 정신적 노력. 인지 복잡도 메트릭과 가독성 관련 요인(명명 규칙, 일관성 등)에 의해 영향을 받는다.25
상태 공간 복잡성 (State Space Complexity): 시스템 또는 컴포넌트가 가질 수 있는 가능한 상태의 수와 이를 추론하는 어려움. 복잡한 로직의 테스트 및 디버깅 논의에서 암시적으로 나타난다.15
의존성 복잡성 (Dependency Complexity): 내부 및 외부 의존성의 수, 성격, 결합 방식에서 발생하는 복잡성.8
아키텍처 복잡성 (Architectural Complexity): 선택된 아키텍처 스타일(예: 마이크로서비스의 분산 시스템 문제)에 내재된 복잡성.19
도메인 복잡성 (Domain Complexity / Essential): 해결하려는 문제 자체의 본질적인 복잡성.30
도구/환경 복잡성 (Tooling/Environment Complexity / Accidental): 빌드 시스템, 배포 파이프라인, 프레임워크 등 개발 환경에서 비롯되는 부가적인 복잡성.49

나. 현대 복잡성 평가의 핵심 요소

전체론적 관점: 복잡성을 평가할 때는 단순히 코드 구조뿐만 아니라 위에서 언급된 다양한 차원을 종합적으로 고려해야 한다.
맥락의 중요성: 복잡성의 영향은 팀의 규모와 경험, 프로젝트 목표, 예상 수명 등 맥락에 따라 달라진다.8 주니어 개발자에게 복잡한 것이 전문가에게는 단순할 수 있다.25
질적 판단: 정량적 메트릭과 함께 인간의 판단, 코드 리뷰, 도메인 전문 지식의 중요성을 간과해서는 안 된다.8
결국 '진정한' 코드 복잡성은 코드 자체의 속성이라기보다는, 코드, 코드가 속한 시스템, 코드가 해결하는 문제, 그리고 이를 개발하고 유지보수하는 인간 사이의 상호작용에서 나타나는(emergent) 속성으로 이해하는 것이 가장 적절하다. 분석 과정에서 복잡성이 코드 구조(CC), 인간의 이해(인지 복잡성), 시스템 상호작용(결합도, 아키텍처), 문제 영역(본질적 복잡성) 등 다양한 원천에서 발생함을 확인했다. 메트릭만으로는 충분하지 않으며 8, 인지 부하나 팀 구조와 같은 인간적 요소가 결정적이다.25 따라서 복잡성에 대한 정의는 이러한 구조적, 시스템적, 인지적, 맥락적 요소를 통합해야 한다.

복잡성이 다차원적이고 맥락 의존적이라는 사실은 효과적인 평가를 위해서는 단일 '궁극의' 복잡성 메트릭을 찾기보다는, 다양한 지표(CC, 인지 복잡도, 결합도 메트릭, 테스트 커버리지 등)들의 대시보드와 질적 실천(코드 리뷰, 아키텍처 리뷰)을 결합해야 함을 시사한다. 이는 다른 분야에서 복잡한 시스템을 모니터링하는 방식과 유사하다. 다양한 정량적, 질적 정보를 종합해야만 복잡성에 대한 미묘하고 정확한 이해에 도달할 수 있다.

VII. 효과적인 복잡성 관리 전략

현대 소프트웨어 개발에서 코드 복잡성을 효과적으로 관리하는 것은 단순히 좋은 코드를 작성하는 것을 넘어, 설계, 프로세스, 팀 문화 전반에 걸친 지속적인 노력을 요구한다. 복잡성의 다면적 본질을 이해했다면, 이를 제어하고 완화하기 위한 구체적인 전략을 적용하는 것이 중요하다.

가. 선제적 설계 및 아키텍처

모듈화 (Modularization): 크고 복잡한 시스템을 작고, 응집력 있으며, 느슨하게 결합된 모듈이나 서비스로 나누는 것이 기본이다.42 관심사의 분리(Separation of Concerns, SoC) 원칙을 적용하고 54, 명확한 인터페이스와 API를 설계하여 모듈 간의 상호작용을 정의해야 한다.34 이는 마이크로서비스나 모듈형 모놀리스 아키텍처와 직접적으로 연결된다.40 모듈화는 코드 재사용을 촉진하고 가독성을 높이며, 각 컴포넌트를 더 쉽게 이해하고 유지보수할 수 있게 한다.42
추상화 (Abstraction): 구현 세부 사항을 감추고 필수적인 기능만 노출하는 추상화를 효과적으로 사용해야 한다.42 캡슐화(Encapsulation)는 이를 달성하는 핵심 기법이다.54 잘 설계된 추상화는 개발자가 세부 사항에 얽매이지 않고 상위 수준에서 시스템과 상호작용할 수 있게 하여 인지 부하를 줄인다.42
적절한 패턴 사용 (Appropriate Patterns): 디자인 패턴은 그것이 실제로 문제를 단순화하고 명확하게 할 때 유용하다.8 패턴 사용 자체가 목적이 되어서는 안 되며, 불필요한 패턴 적용은 오버 엔지니어링으로 이어져 우발적 복잡성을 증가시킬 수 있다.21 패턴의 장단점을 이해하고 맥락에 맞게 신중하게 선택해야 한다.44
단순성 우선 (Simplicity Focus): 처음부터 단순한 설계를 지향하고, 불필요한 기능이나 미래에 대한 과도한 예측에 기반한 일반화를 피해야 한다.21 YAGNI("You Ain't Gonna Need It") 원칙을 따르는 것이 도움이 될 수 있다.58 꼭 필요한 경우가 아니라면 의존성 추가를 최소화해야 한다.21

나. 부지런한 코딩 및 리팩토링 관행

클린 코드 (Clean Code): 가독성 높은 코드는 복잡성 관리의 핵심이다. 의미 있는 변수 및 함수 이름 사용, 일관된 코딩 스타일 유지, 명확한 코드 구조 설계, 함수 및 메서드를 작게 유지하는 것 등이 중요하다.21 코드는 문서보다 더 정확하게 시스템의 동작을 반영하므로 21, 이해하기 쉬운 코드를 작성하는 것이 우선이다.54
리팩토링 (Refactoring): 코드 구조를 개선하고, 중복을 제거하며(DRY 원칙), 로직을 단순화하고, 복잡성 메트릭을 낮추기 위해 지속적으로 리팩토링을 수행해야 한다.5 '메서드 추출(Extract Method)' 6, '조건문 단순화' 60, '조건문을 다형성으로 대체(Replace Conditional with Polymorphism)' 6 등 구체적인 리팩토링 기법을 활용할 수 있다. 리팩토링은 기술 부채 축적을 방지하는 중요한 활동이다.6
테스트 주도 개발 (TDD/BDD): TDD와 같은 테스트 우선 접근 방식은 개발자가 코드를 사용하고 테스트하는 관점에서 먼저 생각하도록 유도하여 자연스럽게 더 단순하고 모듈화되며 테스트 가능한 코드를 작성하도록 이끌 수 있다.42
죽은/불필요한 코드 제거 (Eliminate Dead/Useless Code): 사용되지 않는 코드, 불필요한 추상화 계층(예: 단일 구현 인터페이스), 가치를 제공하지 않는 디자인 패턴 등은 시스템에 불필요한 복잡성만 더한다.21 정기적으로 이러한 코드를 식별하고 과감하게 제거해야 한다.21

다. 견고한 프로세스 및 팀 협업

코드 리뷰 (Code Reviews): 동료 검토는 복잡성을 식별하고, 개선 방안을 제안하며, 지식을 공유하고, 코딩 표준을 유지하는 데 매우 중요한 역할을 한다.6 코드 리뷰는 잠재적인 문제를 조기에 발견하고 협업을 통해 코드 품질을 향상시키는 데 기여한다.42
코딩 표준 (Coding Standards): 명확한 코딩 표준과 스타일 가이드라인을 수립하고 팀 전체가 이를 준수하도록 장려해야 한다.8 이는 코드의 일관성과 가독성을 높여 복잡성을 줄이는 데 도움이 된다.15 자동화된 린터(linter)나 포맷터(formatter)를 활용하면 표준 준수를 용이하게 할 수 있다.54
자동화 (테스팅, CI/CD): 리팩토링이나 새로운 기능 개발 시 발생할 수 있는 회귀 오류(regression)를 잡기 위해 자동화된 테스트를 적극 활용해야 한다.42 CI/CD(지속적 통합/지속적 배포) 파이프라인을 구축하여 빌드, 테스트, 배포 프로세스를 자동화하면 통합 문제를 조기에 발견하고 일관성 있고 안정적인 배포를 보장할 수 있다.57
문서화 (Documentation): 아키텍처, 복잡한 로직, API 등 필요한 부분에 대해서는 명확하고 간결한 문서를 유지해야 한다.42 하지만 가능한 경우, 코드가 스스로 설명하도록(self-documenting code) 작성하는 것을 우선시해야 한다.57
명확한 요구사항 (Clear Requirements): 모호하거나 불완전한 요구사항은 복잡하거나 불필요한 구현으로 이어질 수 있다. 프로젝트 시작 단계에서 요구사항을 명확하게 정의하는 것이 중요하다.58
측정 및 모니터링 (Measure and Monitor): 순환 복잡도, 인지 복잡도 등의 메트릭을 절대적인 목표치가 아닌, 주의가 필요한 잠재적 문제 영역(hotspot)을 식별하기 위한 신호로 사용해야 한다.5 복잡성 추세를 지속적으로 모니터링하고 분석하여 개선 기회를 찾아야 한다.6

표 3: 복잡성 관리 전략 요약

전략 범주	구체적 전략	설명	주요 관리 대상 복잡성 차원
설계/아키텍처	모듈화 (Modularization)	시스템을 작고 응집력 있으며 느슨하게 결합된 단위로 분할 54	구조적, 의존성, 인지적
	추상화 (Abstraction)	구현 세부 사항 숨기고 필수 인터페이스 노출 42	인지적, 구조적
	적절한 패턴 사용 (Appropriate Patterns)	문제 해결에 도움이 될 때 신중하게 패턴 적용 42	구조적, 인지적 (잘못 사용 시 우발적 증가)
	단순성 우선 (Simplicity Focus)	불필요한 기능/일반화 회피, 최소 의존성 유지 21	우발적, 구조적
코딩/리팩토링	클린 코드 (Clean Code)	가독성 높은 코드 작성 (명명, 스타일, 작은 함수 등) 21	인지적, 구조적
	지속적 리팩토링 (Continuous Refactoring)	코드 구조 개선, 중복 제거, 로직 단순화 15	구조적, 인지적, 우발적
	TDD/BDD	테스트 우선 접근 방식으로 설계 개선 유도 42	구조적, 테스트 용이성
	죽은/불필요한 코드 제거	사용되지 않거나 가치 없는 코드 제거 21	우발적, 구조적
프로세스/팀	코드 리뷰 (Code Reviews)	동료 검토를 통한 문제 식별, 지식 공유, 표준 유지 6	모든 차원 (특히 인지적, 구조적, 우발적)
	코딩 표준 (Coding Standards)	일관성 및 가독성 향상을 위한 표준 수립 및 준수 57	인지적, 우발적
	자동화 (Testing, CI/CD)	회귀 방지, 통합 문제 조기 발견, 안정적 배포 57	테스트 용이성, 운영 복잡성 (우발적)
	문서화 (Documentation)	필요한 정보 기록, 단 코드 자체의 명확성 우선 42	인지적
	명확한 요구사항 (Clear Requirements)	모호성 제거로 불필요한 복잡성 방지 58	본질적 (명확화), 우발적 (방지)
	측정 및 모니터링 (Measure & Monitor)	메트릭을 신호로 활용하여 문제 영역 식별 및 추세 관리 5	구조적, 인지적 (지표로서), 관리 효율성

효과적인 복잡성 관리는 단순히 영리한 코드를 작성하는 기술적인 문제를 넘어선다. 이는 기술적 실천(설계, 코딩, 리팩토링), 프로세스 규율(리뷰, 표준, 자동화), 그리고 아키텍처에 대한 선견지명을 결합하는 전체론적인 접근 방식을 요구한다.54 단일 전략만으로는 충분하지 않으며, 소프트웨어 개발 생명주기의 여러 단계에서 상호 보완적인 노력이 필요하다.

또한, 복잡성 관리는 일회성 작업이 아니라 지속적인 활동이다. 지속적인 리팩토링, 정기적인 리뷰, 표준 준수, 시스템 진화에 따른 설계 조정 등이 필요하다.15 복잡성과 관련된 기술 부채는 적극적으로 관리하지 않으면 시간이 지남에 따라 누적된다.6

마지막으로, 많은 효과적인 전략들이 복잡성의 인간적 측면을 직접적으로 다룬다는 점을 주목해야 한다. 가독성 향상 21, 표준과 리뷰를 통한 공동 이해 증진 57, 모듈화와 추상화를 통한 인지 부하 감소 42 등이 그 예이다. 이는 코드 자체의 구조를 관리하는 것만큼이나 코드와 상호작용하는 인간의 경험을 관리하는 것이 중요함을 다시 한번 강조한다.

결론

본 보고서는 현대 소프트웨어 개발에서 '진정한' 코드 복잡성이 무엇인지에 대한 심층적인 분석을 제공하고자 했다. 30년 이상 전에 정의된 순환 복잡도나 코드 라인 수와 같은 전통적인 메트릭은 코드의 구조적 측면을 정량화하려는 초기 시도로서 가치가 있었으나, 현대 소프트웨어의 다면적인 복잡성을 포착하는 데는 명백한 한계를 지닌다. 특히 코드의 이해도와 관련된 인지적 부하, 중첩 구조의 영향, 그리고 새로운 프로그래밍 패러다임 및 아키텍처 패턴의 등장은 이러한 한계를 더욱 부각시킨다.

현대적인 관점에서 복잡성은 단순히 코드 구조의 얽힘을 넘어선다. 인지 복잡도는 코드를 이해하는 데 필요한 정신적 노력을 측정하려는 시도이며, 유지보수성, 가독성, 테스트 용이성은 복잡성이 실제 개발 및 운영 과정에 미치는 영향을 반영하는 중요한 품질 속성이다. 또한, 마이크로서비스나 모놀리스와 같은 아키텍처 선택, 디자인 패턴의 적용 방식, 그리고 시스템 내외부의 의존성 및 결합도는 개별 코드 조각의 복잡성을 넘어서는 시스템 수준의 복잡성을 결정짓는다. Fred Brooks가 제시한 본질적 복잡성과 우발적 복잡성의 구분은 우리가 통제하고 개선할 수 있는 영역(우발적 복잡성)에 노력을 집중해야 함을 시사한다.

결론적으로, 오늘날 '진정한' 코드 복잡성은 구조적, 인지적, 상태 공간적, 의존성 관련, 아키텍처적, 도메인 고유(본질적), 그리고 개발 환경(우발적) 차원들이 복합적으로 얽혀있는 다차원적 구성체이다. 이는 코드, 시스템, 문제 영역, 그리고 개발자 간의 상호작용에서 비롯되는 동적인 속성이다.

따라서 복잡성을 효과적으로 관리하기 위해서는 단일 메트릭에 의존하기보다, 다양한 지표(CC, 인지 복잡도, 결합도 메트릭 등)를 상황에 맞게 활용하고 이를 질적인 평가(코드 리뷰, 아키텍처 검토)와 결합하는 전체론적 접근이 필요하다. 선제적인 설계 원칙(모듈화, 추상화, 단순성) 준수, 부지런한 코딩 및 리팩토링 관행(클린 코드, 지속적 개선), 그리고 견고한 개발 프로세스(표준, 자동화, 협업)를 통해 우발적 복잡성을 최소화하고 본질적 복잡성을 효과적으로 다루어야 한다.

궁극적으로, 복잡성 관리는 기술적 숙련도를 넘어선 지속적인 관심과 규율을 요구하는 활동이다. 코드와 그것이 존재하는 맥락 모두에 주의를 기울이고, 명확성, 유지보수성, 그리고 팀의 이해도를 우선시하는 문화를 조성하는 것이 변화하는 소프트웨어 환경 속에서 지속 가능한 시스템을 구축하는 길이다.

참고 자료

Cyclomatic complexity - a fresh look at code complexity｜Blog, 4월 13, 2025에 액세스, https://codescene.com/engineering-blog/bumpy-road-code-complexity-in-context/
On the accuracy of code complexity metrics: A neuroscience-based guideline for improvement - PMC - PubMed Central, 4월 13, 2025에 액세스, https://pmc.ncbi.nlm.nih.gov/articles/PMC9942489/
Software disenchantment - why does modern programming seem to lack of care for efficiency, simplicity, and excellence - Reddit, 4월 13, 2025에 액세스, https://www.reddit.com/r/programming/comments/z7vsi0/software_disenchantment_why_does_modern/
Cyclomatic complexity - Wikipedia, 4월 13, 2025에 액세스, https://en.wikipedia.org/wiki/Cyclomatic_complexity
What is Cyclomatic Complexity? Definition Guide & Examples - Sonar, 4월 13, 2025에 액세스, https://www.sonarsource.com/learn/cyclomatic-complexity/
Cyclomatic Complexity in Testing: Importance and Benefits - Bugasura, 4월 13, 2025에 액세스, https://bugasura.io/blog/cyclomatic-complexity-in-testing/
A critique of cyclomatic complexity as a software metric - Computer Science Department, 4월 13, 2025에 액세스, https://www.cs.du.edu/~snarayan/sada/teaching/COMP3705/lecture/p1/cycl-1.pdf
Cyclomatic complexity: Definition and limits in understanding code quality - DX, 4월 13, 2025에 액세스, https://getdx.com/blog/cyclomatic-complexity/
Cyclomatic Complexity - The Ganssle Group, 4월 13, 2025에 액세스, https://www.ganssle.com/articles/cyclomaticcomplexity.html
Why Is Counting Lines of Code (LOC) Useful? - NDepend Blog, 4월 13, 2025에 액세스, https://blog.ndepend.com/why-is-counting-lines-of-code-loc-useful/
What Happened to Software Metrics? - PMC, 4월 13, 2025에 액세스, https://pmc.ncbi.nlm.nih.gov/articles/PMC5544018/
Why lines of code are a bad measure of developer productivity - DX, 4월 13, 2025에 액세스, https://getdx.com/blog/lines-of-code/
Why Lines of Code (LOC) Measures Irritate Me - ProjectManagement.com, 4월 13, 2025에 액세스, https://www.projectmanagement.com/blog-post/5104/Why-Lines-of-Code--LOC--Measures-Irritate-Me
Avoid High Cyclomatic Complexity - Better Embedded System SW, 4월 13, 2025에 액세스, https://betterembsw.blogspot.com/2014/06/avoid-high-cyclomatic-complexity.html
Code Complexity Metrics: Writing Clean, Maintainable Software - Iterators, 4월 13, 2025에 액세스, https://www.iteratorshq.com/blog/code-complexity-metrics-writing-clean-maintainable-software/
Why your Lines of Code per day are not the right productivity metric—and what to use instead - Waydev, 4월 13, 2025에 액세스, https://waydev.co/lines-of-code-per-day/
Should we prefer cognitive complexity over cyclomatic complexity ..., 4월 13, 2025에 액세스, https://community.sonarsource.com/t/should-we-prefer-cognitive-complexity-over-cyclomatic-complexity/12337
A Fundamental Theory for Explaining and Measuring Code Complexity - ResearchGate, 4월 13, 2025에 액세스, https://www.researchgate.net/publication/362062741_A_Fundamental_Theory_for_Explaining_and_Measuring_Code_Complexity
My solution to Microservices complexity : r/node - Reddit, 4월 13, 2025에 액세스, https://www.reddit.com/r/node/comments/1dvsfyz/my_solution_to_microservices_complexity/
Code Complexity: An In-Depth Explanation and Metrics - Codacy | Blog, 4월 13, 2025에 액세스, https://blog.codacy.com/code-complexity
How to Simplify Code Complexity: Avoid These Complexity Pitfalls - Turing, 4월 13, 2025에 액세스, https://www.turing.com/blog/reduce-code-complexity-simplify-your-code
Is there a better programming metric than "lines of code"? - Reddit, 4월 13, 2025에 액세스, https://www.reddit.com/r/programming/comments/cbuwd/is_there_a_better_programming_metric_than_lines/
Negative 2000 Lines of Code (1982) - Hacker News, 4월 13, 2025에 액세스, https://news.ycombinator.com/item?id=33483165
The Pros and Cons of Using Cyclomatic Complexity as a Code Quality Metric - BlueOptima, 4월 13, 2025에 액세스, https://www.blueoptima.com/the-pros-and-cons-of-using-cyclomatic-complexity-as-a-code-quality-metric/
Understanding cognitive complexity in software development - GetDX, 4월 13, 2025에 액세스, https://getdx.com/blog/cognitive-complexity/
Cognitive Complexity - Code Climate, 4월 13, 2025에 액세스, https://docs.codeclimate.com/docs/cognitive-complexity
(PDF) Comparative Analysis between Cognitive Complexity and ..., 4월 13, 2025에 액세스, https://www.researchgate.net/publication/389175932_Comparative_Analysis_between_Cognitive_Complexity_and_Cyclomatic_Complexity_in_Software_Development
Cyclomatic Complexity vs Cognitive Complexity: Key Differences Explained - Graph AI, 4월 13, 2025에 액세스, https://www.graphapp.ai/blog/cyclomatic-complexity-vs-cognitive-complexity-key-differences-explained
Do you use metrics for code complexity? : r/cpp - Reddit, 4월 13, 2025에 액세스, https://www.reddit.com/r/cpp/comments/l03xrr/do_you_use_metrics_for_code_complexity/
A Notional Understanding of the Relationship between Code Readability and Software Complexity - MDPI, 4월 13, 2025에 액세스, https://www.mdpi.com/2078-2489/14/2/81
An Empirical Study of the Relationships between Code Readability and Software Complexity - arXiv, 4월 13, 2025에 액세스, https://arxiv.org/pdf/1909.01760
Simplifying Unit Testing with Dependency Injection: A Comprehensive Guide, 4월 13, 2025에 액세스, https://www.codingexplorations.com/blog/simplifying-unit-testing-with-dependency-injection-a-comprehensive-guide
Testable and Maintainable code with Dependency Injection and Containers, 4월 13, 2025에 액세스, https://fideloper.com/testable-maintainable-di-containers
unit testing - What are the design principles that promote testable code? (designing testable code vs driving design through tests) - Software Engineering Stack Exchange, 4월 13, 2025에 액세스, https://softwareengineering.stackexchange.com/questions/153410/what-are-the-design-principles-that-promote-testable-code-designing-testable-c
Do you prefer Mock or Dependency Injection when Unit Testing Functions in Python?, 4월 13, 2025에 액세스, https://www.reddit.com/r/Python/comments/195uk6d/do_you_prefer_mock_or_dependency_injection_when/
Good Code, Testable Code | Epic Web Dev, 4월 13, 2025에 액세스, https://www.epicweb.dev/good-code-testable-code
Monolithic vs Microservices - Difference Between Software Development Architectures, 4월 13, 2025에 액세스, https://aws.amazon.com/compare/the-difference-between-monolithic-and-microservices-architecture/
Microservices vs. monolithic architecture - Atlassian, 4월 13, 2025에 액세스, https://www.atlassian.com/microservices/microservices-architecture/microservices-vs-monolith
Monolith Versus Microservices: Weigh the Pros and Cons of Both Configs | Akamai, 4월 13, 2025에 액세스, https://www.akamai.com/blog/cloud/monolith-versus-microservices-weigh-the-difference
Comparing microservices to monoliths - BellSoft, 4월 13, 2025에 액세스, https://bell-sw.com/blog/microservices-vs-monoliths-which-approach-is-better-for-your-project/
Micro Frontends - Martin Fowler, 4월 13, 2025에 액세스, https://martinfowler.com/articles/micro-frontends.html
Understanding Code Complexity: Measurement and Reduction Techniques - Metabob, 4월 13, 2025에 액세스, https://metabob.com/blog-articles/understanding-code-complexity-measurement-and-reduction-techniques.html
How to Reduce Cyclomatic Complexity: A Complete Guide | LinearB Blog, 4월 13, 2025에 액세스, https://linearb.io/blog/reduce-cyclomatic-complexity
Do design patterns increase or decrease the complexity of an Application? - Stack Overflow, 4월 13, 2025에 액세스, https://stackoverflow.com/questions/759796/do-design-patterns-increase-or-decrease-the-complexity-of-an-application
Essential and Accidental complexity, and performance - Eduardo Lavaque's Blog, 4월 13, 2025에 액세스, https://greduan.com/blog/2024/07/25/essential-and-accidental-complexity-and-performance/
Coupling And Cohesion - C2 wiki, 4월 13, 2025에 액세스, https://wiki.c2.com/?CouplingAndCohesion
Reducing Coupling, 4월 13, 2025에 액세스, https://martinfowler.com.cn/ieeeSoftware/coupling.pdf
Book notes: Agile Technical Practices Distilled, 50 years of Cohesion and Coupling, 4월 13, 2025에 액세스, https://espumita.org/2024/09/01/agile-technical-practices-distilled-book-notes/
Accidental Complexity in Software Engineering - Chi Blog, 4월 13, 2025에 액세스, https://cedricchee.com/blog/accidental-complexity/
No Silver Bullet - Wikipedia, 4월 13, 2025에 액세스, https://en.wikipedia.org/wiki/No_Silver_Bullet
Avoiding Accidental Complexity in Software Design - Nutshell CRM, 4월 13, 2025에 액세스, https://www.nutshell.com/blog/accidental-complexity-software-design
Simplify! - Part 3 - Uwe Friedrichsen, 4월 13, 2025에 액세스, https://www.ufried.com/blog/simplify_3_essential_and_accidental_complexity/
Linking Modular Architecture to Development Teams - Martin Fowler, 4월 13, 2025에 액세스, https://martinfowler.com/articles/linking-modular-arch.html
8 Effective Strategies to Reduce Software Complexity, 4월 13, 2025에 액세스, https://www.expeed.com/8-effective-strategies-to-reduce-software-complexity
When Do Software Complexity Metrics Mean Nothing?- When Examined out of Context - The Journal of Object Technology, 4월 13, 2025에 액세스, https://www.jot.fm/issues/issue_2016_01/article2.pdf
Code Complexity: Best Practices for Efficient Software - Metridev, 4월 13, 2025에 액세스, https://www.metridev.com/metrics/code-complexity-best-practices-for-efficient-software/
Managing Software Complexity: Strategies & Benefits | IN-COM - IN-COM Data Systems, 4월 13, 2025에 액세스, https://www.in-com.com/blog/software-management-complexity/
17 Software Development Best Practices for Writing Code in 2024 - Pulsion Technology, 4월 13, 2025에 액세스, https://www.pulsion.co.uk/blog/17-software-development-best-practices-for-writing-code/
Cyclomatic Complexity Explained With Practical Examples - YouTube, 4월 13, 2025에 액세스, https://www.youtube.com/watch?v=vmyS_j3Kh8g
What Is Cyclomatic Complexity? - AutoRABIT Knowledge Base, 4월 13, 2025에 액세스, https://knowledgebase.autorabit.com/fundamentals/faq/codescan-faqs/general/what-is-cyclomatic-complexity
Minimizing Cyclomatic Complexity with Pattern Matching - DanylkoWeb, 4월 13, 2025에 액세스, https://www.danylkoweb.com/Blog/minimizing-cyclomatic-complexity-with-pattern-matching-SR
Cyclomatic complexity and cognitive complexity - DEV Community, 4월 13, 2025에 액세스, https://dev.to/packmind/cyclomatic-complexity-and-cognitive-complexity-4c03
Standards in software development and 9 best practices - OpsLevel, 4월 13, 2025에 액세스, https://www.opslevel.com/resources/standards-in-software-development-and-9-best-practices

[코딩] 객체지향 설계에서 상속보다 포함을 우선해야 하는 이유

Sat, 12 Apr 2025 13:00:01 GMT

객체지향 설계의 핵심 원칙 중 하나는 "상속보다는 포함을 사용하라"는 것이다. 객체지향 프로그래밍을 수행할 때 클래스 간의 관계 설정을 두고 고심하는 경우가 많다. 상속과 포함은 대표적인 클래스 관계 설정 방식으로서, 일반적으로는 포함 관계를 사용하는 것이 더 나은 설계로 귀결되는 경우가 많다. 그 이유를 자세히 분석해 보자.

상속, 강력하나 신중해야 할 관계

상속은 "IS-A" 관계를 모델링하는 데 유용하다. 예를 들어, "개는 동물이다(Dog IS-A Animal)"와 같이 명확한 상위-하위 관계를 표현할 때 상속을 사용하면 부모 클래스의 속성과 기능을 자식 클래스가 그대로 물려받아 코드 재사용성을 높일 수 있다.

그러나 상속은 다음과 같은 잠재적인 문제점을 내포한다.

취약한 기반 클래스 문제 (Fragile Base Class Problem): 부모 클래스의 변경이 자식 클래스에 예상치 못한 영향을 미칠 수 있다. 이는 유지보수를 어렵게 하고 시스템을 불안정하게 만들 수 있다.
불필요한 인터페이스 상속: 자식 클래스가 부모 클래스의 모든 메서드를 실제로 사용하지 않더라도 상속받게 되어 인터페이스가 불필요하게 커질 수 있다. 이는 클래스를 이해하고 사용하기 어렵게 만든다.
엄격한 결합도 (Tight Coupling): 상속은 부모 클래스와 자식 클래스 간의 강한 결합을 형성한다. 부모 클래스의 구현 방식에 자식 클래스가 의존하게 되어 유연성이 저하되고 변화에 취약해진다.
클래스 계층의 복잡성 증가: 깊고 복잡한 상속 계층은 코드를 이해하고 유지보수하기 어렵게 만들 수 있다. 특히 다중 상속의 경우, 복잡성은 더욱 가중된다.
실행 중 행위 변경의 어려움: 상속은 컴파일 시점에 클래스 간의 관계가 결정되므로, 객체의 행위를 실행 중에 유연하게 변경하기 어렵다.

포함, 유연하고 강력한 대안

포함(Composition)은 한 클래스가 다른 클래스의 인스턴스를 필드로 가지고, 그 객체의 기능을 활용하는 방식이다. 이는 "HAS-A" 관계를 모델링하는 데 적합하다. 예를 들어, "자동차는 엔진을 가지고 있다(Car HAS-A Engine)"와 같이 객체가 다른 객체를 "가지고" 사용하는 관계를 표현할 때 포함을 사용한다.

포함 관계는 상속에 비해 다음과 같은 장점을 제공한다.

높은 유연성 (High Flexibility): 포함된 객체를 필요에 따라 쉽게 교체하거나 변경할 수 있다. 객체 간의 결합도가 낮으므로, 한 클래스의 변경이 다른 클래스에 미치는 영향이 적다.
향상된 유지보수성 (Improved Maintainability): 낮은 결합도는 코드의 유지보수성을 크게 향상시킨다. 각 클래스가 독립적으로 변경될 수 있어 시스템 전체의 안정성을 높인다.
코드 재사용 증대 (Increased Code Reusability): 필요한 기능만을 가진 객체를 포함하여 사용할 수 있다. 상속처럼 불필요한 기능을 물려받을 필요가 없다.
실행 중 행위 변경 용이 (Easy Behavior Change at Runtime): 포함된 객체를 동적으로 변경함으로써 객체의 행위를 실행 중에 유연하게 변경할 수 있다. 이는 시스템의 적응성을 높인다.
상속의 문제점 회피: 앞서 언급한 상속의 잠재적인 문제점들을 자연스럽게 피할 수 있다.

"상속보다는 구성 (Composition over Inheritance)" 원칙

이러한 이유로 객체지향 설계에서는 "상속보다는 구성 (Composition over Inheritance)" 원칙이 강조된다. 이는 클래스 간의 관계를 설정할 때 상속보다는 포함 관계를 우선적으로 고려해야 함을 의미한다.

물론 상속이 모든 상황에서 부적절한 것은 아니다. 명확한 IS-A 관계가 존재하고, 코드 재사용성이 매우 높으며, 클래스 계층이 단순할 경우에는 상속이 효과적인 선택이 될 수 있다. 하지만 이러한 경우에도 상속을 신중하게 사용해야 하며, 포함 관계를 통해 더 나은 설계를 할 수 있는지 항상 고려해야 한다.

결론

객체지향 설계를 수행할 때 클래스 간의 관계를 어떻게 설정할지는 시스템의 유연성, 유지보수성, 확장성에 지대한 영향을 미친다. 일반적으로 상속보다는 포함 관계를 사용하는 것이 더 나은 설계를 위한 길이며, "상속보다는 구성" 원칙을 명심하고 실제 개발에 적용해 볼 것을 권장한다.

[cpp] 재진입 함수의 의미 2

Fri, 11 Apr 2025 13:00:01 GMT

아주 옛날엔 우겨도 됐었다. 목소리 큰 사람이 틀려도 우기면 맞는게 되는 세상이었다. 그러다 전화가 나오고 전화 찬스가 등장했다. 목소리가 커도 전문가에게 전화해서 답을 들으면 더는 우길 수가 없는 세상이 된 것이다. 스마트폰은 그 속도를 더 빠르게 만들었다. 전화를 걸 필요도 없다. 웹검색이면 온갖 것들이 다 나오기 시작하니 말이다. 그리고 인공지능이 등장했다.

할루시네이션이니 뭐니 말들이 많지만 항상 그렇지만 우리는 우리가 쌉소리 한 것들은 금방 잊는다. 오늘 디버깅을 하다 15년 전 쓴 글에 대한 참교육을 인공지능 선생님께 받고 가르침을 남겨 본다. 뭔가를 안다고 말하기가 참 어려운 세상이다. 겸손은 힘들지만, 겸손하게 살자.

#0. 휴먼, 일단 참교육 먼저 받고...

글의 핵심 주장 요약:

많은 개발자가 WndProc의 재진입을 잘못 이해하고 있다 (예: Sleep 중 다른 메시지 처리).
실제 메시지 처리는 메시지 루프(GetMessage/DispatchMessage)를 통해 순차적으로 이루어진다.
따라서 WndProc의 재진입이 의미하는 바는 스레드 안전성(Thread Safety)과 병렬 호출 가능성이며, 여러 스레드/윈도우에서 동일하게 동작해야 함을 뜻한다.
<리스트 3>(정적 변수 사용)과 <리스트 4>(전역 크리티컬 섹션 사용)는 이러한 의미의 "재진입성"을 위반하는 잘못된 예시다.

지적 및 수정 필요한 부분:

"재진입(Reentrancy)" 용어의 핵심 의미 혼동:
- 이 글의 가장 큰 문제점은 "재진입(Reentrancy)"의 표준적인 의미와 "스레드 안전성(Thread Safety)" 및 "인스턴스 독립성(Instance Independence)"을 혼동하고 있다는 점입니다.
- 표준적인 재진입의 의미는 함수 실행 중 (같은 스레드 내에서) 다시 그 함수가 호출되어도 문제가 없는 성질을 의미합니다. Windows WndProc 맥락에서는 주로 SendMessage나 MessageBox 등의 호출로 인해 같은 스레드 내에서 WndProc가 중첩 호출되는 상황을 가리킵니다. (제가 이전에 예시로 보여드린 MessageBox로 인해 상태가 꼬이는 경우가 바로 이 표준적인 재진입 문제입니다.)
- 반면, 이 글은 재진입을 여러 스레드에서 또는 여러 윈도우 인스턴스 간에 안전하게 병렬적으로 호출될 수 있는 성질로 정의하고 있습니다. 이는 재진입보다는 스레드 안전성과 인스턴스별 상태 관리(Instance-specific state management)에 더 가까운 개념입니다.
<리스트 1>의 잘못된 오해 설명은 정확함:
- 글쓴이가 지적한 것처럼, WndProc 내의 Sleep 중에 다른 메시지가 즉시 처리된다는 생각은 명백히 틀린 것이 맞습니다. DispatchMessage가 WndProc를 호출하고, 해당 메시지 처리가 끝나야 메시지 루프가 다음 메시지를 가져와 처리하기 때문입니다. 이 부분 설명은 정확합니다.
<리스트 3>의 문제점은 "재진입성"이 아닌 "인스턴스 독립성/상태 관리" 문제:
- <리스트 3>의 static int Count는 해당 WndProc를 사용하는 모든 윈도우 인스턴스에서 공유됩니다. 이는 글쓴이가 제시한 테스트 케이스 2번(한 스레드, 여러 윈도우)과 3번(여러 스레드, 여러 윈도우)에서 문제를 일으킵니다.
- 하지만 이 문제의 본질은 표준적인 의미의 "재진입" 문제라기보다는, 윈도우별로 관리되어야 할 상태를 정적 변수로 잘못 구현한 "인스턴스 상태 관리"의 실패입니다. 즉, 스레드와 무관하게 여러 윈도우가 하나의 WndProc를 공유할 때 발생하는 문제입니다. 스레드 안전성 문제이기도 하지만, 근본적으로는 상태 관리 설계 문제입니다.
<리스트 4>의 문제점은 "재진입성"이 아닌 "불필요한 직렬화/성능" 문제:
- <리스트 4>는 GlobalCs라는 전역 크리티컬 섹션을 사용함으로써, 서로 다른 스레드에서 실행되는 WndProc 호출조차도 동시에 실행될 수 없게 만듭니다. 이는 심각한 성능 저하를 유발하고 Windows GUI의 반응성을 해치는 잘못된 설계입니다.
- 하지만 이것을 "재진입 불가능"이라고 표현하는 것은 어색합니다. 오히려 병렬 실행 자체를 막아버리는 "과도한 동기화" 또는 "불필요한 직렬화" 문제입니다. 표준적인 의미의 재진입과는 거리가 멉니다.
결론 부분의 "재진입 가능하도록 만들어진 메시지 프로시저" 정의의 문제:
- 글쓴이는 1, 2, 3번 테스트 케이스에서 모두 동일하게 동작하는 것을 "재진입 가능하게 만들어진" 것이라고 정의합니다.
- 물론 잘 디자인된 WndProc는 윈도우별 상태를 GetWindowLongPtr/SetWindowLongPtr 등을 이용해 관리함으로써 세 경우 모두 의도한 대로 동작해야 합니다.
- 하지만 이 조건은 "인스턴스 상태 관리의 올바름"과 "스레드 안전성"(필요한 경우)을 의미하는 것이지, 표준적인 의미의 "재진입성"과는 다른 개념입니다. 이 글의 정의대로라면, 제가 앞서 보여드린 MessageBox 재진입 예제에서 상태가 꼬이는 문제는 "재진입" 문제가 아니게 되어버리는 모순이 발생합니다.

요약 및 수정:

이 글은 WndProc 재진입에 대한 흔한 오해(Sleep 관련)를 정확히 지적하고 메시지 루프의 기본 동작을 올바르게 설명했습니다.
하지만 글의 핵심적인 문제점은 "재진입(Reentrancy)"이라는 용어를 표준적인 의미(같은 스레드 내 중첩 호출 가능성) 대신 "스레드 안전성 및 인스턴스 독립성"이라는 의미로 잘못 사용하고 있다는 것입니다.
<리스트 3>과 <리스트 4>는 각각 잘못된 상태 관리(정적 변수)와 과도한 동기화(전역 락)의 문제점을 보여주는 좋은 예시이지만, 이를 "재진입성" 문제로 설명하는 것은 용어 혼란을 야기합니다.
결론적으로, WndProc를 작성할 때는 (1) 표준적인 의미의 재진입(같은 스레드 내 중첩 호출)에도 상태가 깨지지 않도록 주의해야 하고, (2) 여러 윈도우 인스턴스 간에 상태가 섞이지 않도록 인스턴스별 데이터를 사용해야 하며, (3) 여러 스레드에서 사용될 가능성이 있다면 스레드 안전성도 고려해야 합니다. 이 글은 (2), (3)번 측면을 강조하면서 이를 "재진입"이라고 잘못 부르고 있습니다.

따라서 글의 의도(잘못된 WndProc 작성 방식 비판)는 좋으나, 핵심 용어인 "재진입"의 정의와 사용에 오류가 있다고 지적할 수 있습니다.

#1. 재진입 함수의 의미

특정 윈도우의 메시지 프로시저(WndProc)는 해당 윈도우를 소유한 단일 스레드에 의해 순차적으로 처리되는 것이 기본 원칙입니다. 하지만 여기서 '재진입 가능하다(Reentrant)'는 의미는 다음과 같은 상황을 설명합니다.

재진입(Reentrancy)의 의미:

어떤 함수(여기서는 메시지 프로시저)의 실행이 아직 끝나지 않은 상태에서, 같은 스레드 내에서 해당 함수가 다시 호출될 수 있다는 뜻입니다. 즉, 함수의 실행 흐름 중간에 끼어들어 다시 처음부터 실행될 수 있다는 것입니다.

메시지 프로시저에서 재진입이 발생하는 경우:

메시지 프로시저가 단일 스레드에서 실행됨에도 불구하고 재진입이 발생하는 대표적인 경우는 다음과 같습니다.

메시지 프로시저 내에서 SendMessage 호출:
- WndProc 안에서 다른 윈도우(또는 자기 자신)에게 SendMessage를 호출하면, 이 SendMessage는 즉시 대상 윈도우의 WndProc를 호출하고 그 처리가 끝날 때까지 대기합니다. 만약 이 대상 윈도우가 같은 스레드 소유라면, 현재 실행 중인 WndProc 코드가 잠시 멈추고 새로운 메시지 처리를 위한 WndProc 코드가 같은 스레드에서 실행됩니다. 원래의 WndProc 실행은 아직 끝나지 않았는데, 다시 WndProc가 호출된 것이므로 재진입이 발생한 것입니다.
메시지 프로시저 내에서 모달 대화상자 또는 메시지 박스 표시:
- WndProc 안에서 MessageBox, DialogBox 같은 함수를 호출하면, 이 함수들은 내부적으로 자체 메시지 루프를 돌립니다. 이 내부 메시지 루프는 현재 스레드의 메시지 큐에 있는 다른 메시지들(예: WM_PAINT, 다른 WM_COMMAND 등)을 처리할 수 있습니다. 만약 이 메시지들이 현재 윈도우로 보내진 것이라면, MessageBox나 DialogBox가 반환되기 전에 WndProc가 다시 호출될 수 있습니다. 이것 역시 재진입입니다.
기타 동기적 콜백: COM 호출 등 특정 동기적 작업 중 시스템이 메시지 펌핑을 강제하는 경우에도 유사한 재진입이 발생할 수 있습니다.

중요한 점:

재진입은 같은 스레드 내에서 발생하는 중첩 호출입니다. 여러 스레드가 동시에 WndProc를 실행하는 스레드 안전성(Thread-Safety) 문제와는 다릅니다. (윈도우 프로시저는 기본적으로 특정 스레드에 귀속되므로, 일반적인 의미의 스레드 안전성은 고려 대상이 아닙니다.)
재진입 문제: 만약 WndProc가 전역 변수나 정적 변수를 사용하는데, 재진입 호출 시 이 변수들의 상태가 이전 호출과 꼬이게 되면 문제가 발생할 수 있습니다. 따라서 재진입 가능성을 염두에 두고 WndProc를 작성해야 합니다. 주로 지역 변수나 윈도우 인스턴스별 데이터(SetWindowLongPtr/GetWindowLongPtr 등)를 사용하여 상태를 관리하는 것이 안전합니다.

결론:

메시지 프로시저는 단일 스레드에서 순차 처리되는 것이 맞지만, 특정 함수 호출(SendMessage, 모달 대화상자 등)로 인해 실행 흐름이 중단되고 같은 스레드에서 다시 호출될 수 있기 때문에 "재진입 가능하다"고 말하는 것입니다.

#2. 케이스 스터디

재진입 시 문제가 발생할 수 있는 간단한 예시를 보여드리겠습니다.

여기서는 메시지 프로시저(WndProc) 내에서 정적(static) 변수를 사용하여 상태를 관리하다가, MessageBox 호출로 인해 재진입이 발생했을 때 상태가 꼬이는 상황을 만들어 보겠습니다.

시나리오:

왼쪽 마우스 버튼(WM_LBUTTONDOWN)을 클릭하면 특정 작업을 시작합니다.
작업은 여러 단계로 이루어지며, 현재 작업 중임을 나타내기 위해 static bool isProcessing 플래그를 사용합니다.
작업 중간에 사용자 확인을 위해 MessageBox를 띄웁니다.
MessageBox가 떠 있는 동안 다른 메시지(예: 오른쪽 마우스 버튼 클릭, WM_RBUTTONDOWN)가 처리될 수 있습니다.
오른쪽 마우스 버튼 클릭 처리기(WM_RBUTTONDOWN)가 작업 상태와 관련된 정적 변수(sharedBuffer)를 수정한다고 가정합니다.
MessageBox가 닫히고 원래의 왼쪽 버튼 클릭 작업으로 돌아왔을 때, 정적 변수(sharedBuffer)의 내용이 예상과 달라 문제가 발생합니다.

예시 코드 (WndProc 부분):

#include <windows.h>
#include <wchar.h> // for wcscpy_s, wcscat_s

//WndProc 함수 내부에 선언된 정적 변수는 해당 함수가 여러 번 호출되어도 값을 유지합니다.
//하지만 재진입 시 문제가 될 수 있습니다.
LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) {
    static bool isProcessing = false;      // 현재 작업 중인지 나타내는 플래그
    static wchar_t sharedBuffer[100] = {0}; // 여러 호출 간에 공유되는 버퍼 (문제 발생 지점)

    switch (message) {
        case WM_LBUTTONDOWN:
            // 이미 다른 작업이 진행 중이면 무시 (간단한 락)
            if (isProcessing) {
                OutputDebugString(L"WndProc [LBUTTON]: 이미 작업 중입니다!\n");
                return 0;
            }

            // 작업 시작
            isProcessing = true;
            OutputDebugString(L"WndProc [LBUTTON]: 작업 시작...\n");

            // 단계 1: 공유 버퍼 준비
            wcscpy_s(sharedBuffer, _countof(sharedBuffer), L"왼쪽 버튼 작업 데이터");
            OutputDebugString(L"WndProc [LBUTTON]: 버퍼 준비 완료.\n");
            Sleep(500); // 약간의 작업 시간 시뮬레이션

            // *** 문제 발생 가능 지점: MessageBox 호출 ***
            // 이 MessageBox는 내부 메시지 루프를 돌기 때문에,
            // 떠 있는 동안 다른 메시지(예: WM_RBUTTONDOWN)가 처리될 수 있습니다.
            MessageBox(hWnd, L"왼쪽 버튼 작업 1단계 완료. 확인을 누르면 2단계 진행.", L"진행 중", MB_OK);
            // 만약 여기서 WM_RBUTTONDOWN이 처리되면 아래 코드는 예상과 다르게 동작할 수 있습니다.

            // 단계 2: 공유 버퍼에 내용 추가 (원래 의도)
            // *** 재진입으로 인해 sharedBuffer 내용이 바뀌었을 수 있음 ***
            wcscat_s(sharedBuffer, _countof(sharedBuffer), L" - 2단계 완료");
            OutputDebugString(L"WndProc [LBUTTON]: 최종 버퍼 내용: ");
            OutputDebugString(sharedBuffer);
            OutputDebugString(L"\n");

            // 작업 완료
            isProcessing = false;
            OutputDebugString(L"WndProc [LBUTTON]: 작업 완료.\n");
            break;

        case WM_RBUTTONDOWN:
            // 이 메시지는 LBUTTON의 MessageBox가 떠 있는 동안 처리될 수 있습니다.
            OutputDebugString(L"WndProc [RBUTTON]: 오른쪽 버튼 클릭! (중단 발생)\n");

            // *** 문제 발생: LBUTTON 작업 중에 공유 버퍼를 수정함 ***
            wcscpy_s(sharedBuffer, _countof(sharedBuffer), L"!!! 오른쪽 버튼에 의해 덮어쓰여짐 !!!");
            OutputDebugString(L"WndProc [RBUTTON]: 공유 버퍼를 수정했습니다.\n");

            // RBUTTON 작업도 MessageBox를 띄운다고 가정 (추가 재진입 가능성)
            // MessageBox(hWnd, L"오른쪽 버튼 작업 완료.", L"RBUTTON", MB_OK);
            break;

        case WM_DESTROY:
            PostQuitMessage(0);
            break;

        default:
            return DefWindowProc(hWnd, message, wParam, lParam);
    }
    return 0;
}

문제 상황 시뮬레이션:

프로그램을 실행하고 창을 왼쪽 클릭합니다.
- OutputDebugString에 "작업 시작...", "버퍼 준비 완료."가 출력됩니다.
- "왼쪽 버튼 작업 1단계 완료..." 메시지 박스가 나타납니다.
메시지 박스가 떠 있는 상태에서 창을 오른쪽 클릭합니다.
- OutputDebugString에 "오른쪽 버튼 클릭! (중단 발생)", "공유 버퍼를 수정했습니다."가 출력됩니다. sharedBuffer의 내용이 바뀝니다.
이제 확인(OK) 버튼을 눌러 왼쪽 버튼 메시지 박스를 닫습니다.
- 원래의 WM_LBUTTONDOWN 처리가 MessageBox 다음부터 재개됩니다.
- wcscat_s 함수는 "왼쪽 버튼 작업 데이터" 뒤에 이어붙이려고 했지만, 실제로는 "!!! 오른쪽 버튼에 의해 덮어쓰여짐 !!!" 뒤에 이어붙이게 됩니다.
- OutputDebugString에 "최종 버퍼 내용: !!! 오른쪽 버튼에 의해 덮어쓰여짐 !!! - 2단계 완료" 와 같이 예상과 다른 결과가 출력됩니다.
- "작업 완료."가 출력됩니다.

왜 문제가 되는가?

WM_LBUTTONDOWN 처리 루틴은 isProcessing = true 와 isProcessing = false 사이 구간에서 sharedBuffer에 대한 암묵적인 독점권을 가정하고 작성되었습니다. 하지만 MessageBox 호출로 인해 메시지 펌핑이 발생하면서 다른 메시지(WM_RBUTTONDOWN)가 처리될 기회가 생겼고, 이 메시지 처리기가 공유 자원인 sharedBuffer를 수정하면서 원래 작업의 상태를 깨뜨린 것입니다.

해결 방안:

메시지 프로시저 내에서 시간이 오래 걸리는 작업이나 상태를 복잡하게 변경하는 작업을 피합니다.
재진입을 유발하는 함수(SendMessage, MessageBox 등)를 호출할 때는 그 사이에 상태가 변경될 수 있음을 인지하고 방어적으로 코드를 작성합니다.
상태 저장을 위해 정적 변수나 전역 변수 사용을 최소화하고, 필요하다면 윈도우 인스턴스별 데이터(SetWindowLongPtr, GetWindowLongPtr 등)나 스레드 로컬 스토리지(TLS) 등을 고려합니다. (단, WndProc는 기본적으로 단일 스레드에서 실행되므로 TLS보다는 윈도우 인스턴스 데이터가 더 적합할 수 있습니다.)
정말로 임계 영역(Critical Section)이 필요하다면, 해당 구간 전후로 상태를 저장하고 복원하거나, 더 정교한 동기화 기법(같은 스레드 내 재진입 방지용 플래그 등)을 사용해야 할 수도 있습니다.

이 예시는 재진입이 어떻게 공유 상태를 망가뜨릴 수 있는지 보여주는 간단한 사례입니다. 실제 애플리케이션에서는 더 복잡한 형태로 문제가 발생할 수 있습니다.

#3. 메시지 펌프

MessageBox 함수 내부에는 자체적인 메시지 펌프(Message Pump) 또는 메시지 루프(Message Loop)가 존재합니다.

이것이 바로 WndProc가 MessageBox 호출에서 아직 반환하지 않았음에도 불구하고, 같은 스레드에서 다른 메시지를 처리하기 위해 WndProc가 다시 호출될 수 있는 이유입니다.

동작 과정:

WndProc 실행: 스레드의 메인 메시지 루프(while(GetMessage...))가 메시지(예: WM_LBUTTONDOWN)를 받아 DispatchMessage를 호출하고, 이로 인해 WndProc가 실행됩니다.
MessageBox 호출: WndProc 코드 내에서 MessageBox(...) 함수를 호출합니다.

MessageBox의 내부 메시지 루프 시작: MessageBox 함수는 단순히 대화상자만 표시하고 대기하는 것이 아니라, 자체적인 메시지 루프를 시작합니다. 이 내부 루프는 대화상자가 활성화된 동안 현재 스레드로 들어오는 메시지들을 처리합니다. 이 루프는 대략 다음과 유사하게 동작합니다.

// MessageBox 내부 (개념적인 코드)
DisplayTheMessageBoxWindow();
while (MessageBoxIsStillActive()) {
    MSG msg;
    // 현재 스레드의 메시지 큐에서 메시지를 가져옴
    if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE)) { // 또는 GetMessage
        // 표준 메시지 처리 (키보드 입력 변환 등)
        TranslateMessage(&msg);
        // *** 중요: 해당 메시지를 처리할 윈도우 프로시저로 보냄 ***
        DispatchMessage(&msg);
    } else {
        // 처리할 메시지가 없으면 잠시 대기
        WaitMessage();
    }
    // + MessageBox 자체 로직 처리 (버튼 클릭 감지 등)
}
HideTheMessageBoxWindow();
ReturnResult();

새 메시지 도착 및 처리: MessageBox의 내부 메시지 루프가 실행되는 동안, 사용자가 오른쪽 마우스 버튼을 클릭하면 WM_RBUTTONDOWN 메시지가 스레드의 메시지 큐로 들어옵니다. MessageBox의 내부 루프에 있는 PeekMessage 또는 GetMessage가 이 메시지를 가져옵니다.
DispatchMessage 호출: 내부 루프의 DispatchMessage는 이 WM_RBUTTONDOWN 메시지를 해당 윈도우(hWnd)로 보냅니다.
WndProc 재호출(Re-entry): DispatchMessage는 결국 우리의 WndProc 함수를 다시 호출하여 WM_RBUTTONDOWN 메시지를 처리하도록 합니다. 이 시점에서 호출 스택에는 메인 메시지 루프 -> WndProc(LBUTTON) -> MessageBox -> 내부 메시지 루프 -> DispatchMessage -> WndProc(RBUTTON) 와 같이 쌓이게 됩니다. 즉, WndProc가 중첩되어 호출된 것입니다.
MessageBox 종료 및 반환: 사용자가 MessageBox의 확인 버튼 등을 누르면, MessageBox의 내부 메시지 루프가 종료되고, MessageBox 함수 호출이 드디어 반환(return)됩니다.
원래 WndProc 실행 재개: 이제 제어가 원래의 WndProc ( WM_LBUTTONDOWN 처리 중이던) 코드로 돌아와 MessageBox 호출 다음 라인부터 실행을 계속합니다.

#3

어디까지를 인공으로 부를 수 있을까, 라는 생각이 드는 기사. 실리콘 50에, 바이오 50이면 인공일까? 아닐까? https://x.com/GeekNewsHada/status/1897466143763521698

2025-03-06

#4

어제 기업은행 대출 연장 심사 전화가 왔다. 본인을 인공지능 바로라고 소개한 에이전트는 개인인증 식별을 말이 아닌 키패드로 하는 것과 적금 가입 권유가 없다는 점을 빼면 사람과 별 차이를 못 느꼈다. 많은 것들이 생각보다 빠르게 변한다.

2025-03-06

#5

aal izz well - 3 idiots

2025-03-07

#6

독일의 응용수학자이자 경영컨설턴트인 군터 뒤크는 《호황 vs 불황》이라는 저서에서 경기 변동의 근본 원인으로 ‘국부적 영리함’을 꼽습니다.
... 쉽게 말해, 모두가 호황을 전망해서 공장을 크게 지으면 얼마 안 가 공급과잉이 되면서 경기 침체가 온다는 뜻입니다. - 주식하는 마음, 홍진채

국부적 영리함으로 사는 사람이 많은 세계에서는 국부적 멍청함으로 사는 사람이 이득을 본다. 그렇게 국부적 멍청함으로 사는 사람이 다시 늘어나면 반대로 또 국부적 영리함으로 사는 사람이 이득을 본다. 그냥 랜덤으로 사는 게 좋은 건지도.

구어체로 써져서 중강중간 쓰잘때기 없는 집중하라든지, 아냐 모르냐 물어본다든지 하는 것만 빼면 내용은 참 괜찮은 책인데 생각보다 서평은 나쁜 듯.

2025-03-10

#7

인공지능 탑티어 전문가께서 프로그래밍 괜찮다니 다소 안심이 된다. 비슷한 예로 메모리가 있다. 램은 계속 늘었지만 역설적이게도 늘 부족하다. 기능도 그만큼 계속 늘었기 때문. https://x.com/AndrewYNg/status/1900219116822102116

2025-03-15

#8

exaone-deep 32b 찍먹 후기. 모든 벤치가 그렇겠지만 다소 과장됐다는 생각. 우리나라에서도 리즈닝 모델이 나왔다는데 의미를 두는 정도?! llm 모델이 예체능이랑 비슷한 건 1등 아니면 괸심 받기가 어렵다는거. 32b 리즈닝은 qwq를 압도해야 사람들이 좀 쳐다봐주지 않을까 싶다.

2025-03-19

#9

유툽 보통 2배속 보는데 4배속까지 확장됐다. 세상이 점점 더 빨라지는 느낌. 근데 3배속 이상은 들리는거 맞긴한가 싶은 속도 ㄷㄷ

2025-03-23

#10

[ai] 바이브 코딩의 시대 https://jiniya.net/2025/03/vibe-coding-era

2025-03-25

#11

이제 나는 무엇이든 할 수 있는 사람이므로, 그다음 5년 동안 마리화나를 엄청나게 피우고, 운동경기에 참여하고,‘혹성탈출 시리즈’를 수십 번도 넘게 보며 시간을 축냈다. 어쩌다 우연히 생기는 섹스 기회만이 이런 생활의 반복에서 잠시 벗어나는 경우였다.마지막 부분만 빼면 꽤 괜찮은 생활이었다.

아는 사람 중에 사회적으로 성공했고, 몸매도 멋지며, 밴드 활동을 하는 데다 부모님과도 사이가 좋고, 동물학대방지협회에서 자원봉사도 하며, 음식 블로그까지 운영하는 사람이 있을 것이다. 그냥 당신과는 다른 사람이라고 생각하라.

사업은 자본을 모으거나, 수익을 내거나, 아니면 파산을 하거나, 셋 중 어떤 상황이 먼저 오느냐에 따라서 판세가 달라진다. 그전까지는 네거티브 커미션이 붙은 영업사원일 뿐이다.

내게 당신의 최종 학위(어느 대학에서 어떤 학위를 받았는지)와 우편번호를 알려주면 꽤 정확하게 앞으로 10년간 당신이 얼마나 벌어들일지 맞힐 수 있다.

스티브 잡스나 빌 게이츠, 그리고 또 다른 대학 중퇴자들이 이루어낸 놀랍고 위대한 성공담은 내일도 등장할 것이다. 그러나 다시 한번 말하지만, 당신은 스티브 잡스가 아니다. - <스콧 교수의 인생 경제학>, 스콧캘러웨이 지음

존경해 마지않는 이재용 회계사님께서 토스에서 추천해서 읽었는데 재미는 있었지만 생각보다 그저그런것 같은 책. 재미는 있었다. 술술 읽힌다. https://blog.toss.im/article/10to100-library

2025-03-26

#12

어떤 일도 생각보다 좋거나 나쁘지 않다 - <스콧 교수의 인생 경제학>, 스콧캘러웨이 지음

2025-03-26

#13

바이럴은 지브리풍 이미지가 다 가져갔지만 gemini 약진이 놀랍다. 벤치마크 점수들이 예사롭지 않다. 구글도 이제 감 잡은건가?!

2025-03-27

#14

[py] 메모리와 속도 두 마리 토끼를 모두 잡을 수 있을까? https://jiniya.net/2025/03/is-it-possible-to-achieve-both-memory-and-speed/

2025-03-28

#15

gemini 2.5 pro를 집중적으로 몇일 사용해봤는데 실로 놀랍다. 간단한 프로그램은 그냥 한번에 테스트 없이 사용할 정도로 잘 작성한다. 또 신기한건 에고가 생기기 시작했다. 안되는 코드를 물으면 맞다고 계속 우기는 경우가 더러 있음. 매뉴얼 복붙해서 확인시켜줘도 인정을 안함.

다른 흥미로운 포인트는 안된다고 하면 디버깅을 한다는 점. 어디다 코드 추가해서 뭐라고 결과가 나오는지 알려달라고 요청하는 식. 결과 알려주면 다시 뭐가 문제인 것 같다 판단하고 고침. 그리고 약간 불편한건 생각만하고 답이 없는 경우가 자주 있음. 답해란 말을 제법 많이 쓴다.

2025-03-31

[py] 메모리와 속도 두 마리 토끼를 모두 잡을 수 있을까?

Fri, 28 Mar 2025 13:00:01 GMT

명량한 표정과는 다르게 현실 세계에서 두 마리 토끼를 잡기 위해서는 트레이드 오프가 필요한 순간이 온다.

우리는 가난하다. 그래서 서버도 가난한 서버를 쓴다. c6a.large, vcpu는 2개 메모리는 4g인 사양이다. 물론 이보다 더 저사양 서버에서 고군분투하는 분들에게는 이 또한 높은 사양일수도 있겠다. 문제는 어쨌든 이 열악한 서버에서 연산을 진행해야 한다는 의미다. 연산할 것이 별로 많지 않다면 문제가 되진 않는다. 우리가 처리할 대상은 대략 2g 정도의 텍스트 파일이고, 해당 텍스트 파일에서 맵을 추출해서 csv로 생성하는 기능을 한다. 정상 생성된다면 맵은 대략 pickle로 전환했을 때 대략 10g가 조금 넘는 크기로 추정된다. 속도도 문제다. 적어도 5분 내에는 이 작업이 완료되어야 한다. 게다가 우리는 파이썬으로 작업 중이다.

물론 파이썬을 쓰면서도 별로 느리다는 생각은 해보질 않았다. 대체로 그렇게 큰 작업을 수행하는 일은 없기 때문이다. 하지만 일이 커지면 느려지는 건 당연하다. 이 작업은 메모리가 많은 괜찮은 성능 pc에서 수행하더라도 20분이 넘게 걸렸다. 그리고 4g에서는 당연한 얘기겠지만 메모리 부족 오류로 종료됐다. 애쩠든 이런 상황을 우리는 어떻게 해결할 수 있을까?

rust 포팅

rust로 작업을 포팅하면 당연한 소리겠지만 엄청 빨라질 것이다. 일전에 우리는 간단한 python 로그 서버를 rust로 포팅했는데 속도가 무려 77배 빨라졌다. 최악의 경우에는 이 방법 또한 고려 사항 중엔 하나였다. 하지만 어쨌든 최대한 일을 적게하는 방법을 찾아야 했기에 기존 코드를 고치지 않고 수행할 방법을 잦아야 했다.

nuitka

nuitka는 파이썬 코드를 네이티브 코드로 빌드해주는 툴이다. 네이티브 코드로 변환해주니까 뭔가 더 빨라지지 않을까, 라는 생각이 들기 쉽다. 그래서 테스트를 해보았지만 속도 향상은 별로 없었다. 스크립트 코드를 제공하고 싶지 않을 때 선택할 수 있는 선택 사항 정도가 아닌가 싶다.

pypy

pypy는 파이썬의 파이썬 구현체에 jit을 탑재한 인터프리터다. 순수 파이썬 코드가 많으면 jit이 탑재된 pypy가 빠를 수 있다. 테스트 해보니 생각보다 효과는 드라마틱했다. 대략 14.5배 빨라졌다. 여기에 약간 함정이 있는데 pypy에서 일부 파이썬 코드는 cpython 구현보다 느린 경우도 있다는 사실이다. 그래서 많은 반복 작업 속에 그런 코드가 있다면 파이썬 구현을 찾아서 더 빠르게 실행되도록 변경하는 작업을 일부 해줘야 한다. 어쨌든 이런 작업을 진행하고 나면 대체로 아주 빨라진다.

메모리는?

그렇게 빨라진 줄만 알았지 메모리 문제를 놓고 있었던 스크립트는 서버에서 동작하면 메모리 부족 오류가 발생했다. 서버 메모리는 4g, 우리가 실제 동작에 필요한 메모리는 대략 넉넉하게 12g 정도 된다. 물론 이는 우리가 무식하게 맵을 그냥 메모리에 다 올렸기 때문이다. 그런데 또 그렇게 무식하게 쓰자고 파이썬 쓰는 게 아닌가 싶기도 하다. 고상하게 설계하고 고민하고 할 거였음 애초에 더 복잡한 언어로 더 정교하게 만들었을테니 말이다. 어쨌든 이 말도 안되게 부족한 메모리를 극복하는 방법은 없을까, 를 최신 신상 gemini 2.5 pro와 고민해 보았다.

나의 고민에 나온 첫 반응은 shelve였다. 나는 이런게 있는 줄도 몰랐지만 표준 기능으로 있는 도구였다. 맵을 메모리가 아닌 디스크에 기록하게 해준다. 여윽시 인공지능인가를 생각하며 맵을 shelve로 교체했다. 당연하 소리겠지만 메모리는 너무나 작게 썼고 파일 용량은 커져만 갔다. 안타깝게도 속도가 너무 느렸다. shelve는 맵이 업데이트될때마다 파일 io를 동반하기 때문에 어쩔 수가 없는 구조였다. 뭔가 shelve가 메모리를 좀 더 사용하도록 하면 좋을 것 같아서 그런 기능에 대해 문의했으나 그런 기능은 존재하질 않았다. 하지만 녀석은 최신 신상 인공지능 답게, 직접 구현한 구현체를 주었다. CachedShelve. 캐시맵을 추가해서 캐시에서 발견되는 경우는 캐시를 사용하도록 변경한 구조였다. 캐시를 추가하니 눈에 띄게 빨라졌지만 우리의 요구 사항을 충족하긴 힘들었다. 역시나 두마리 토끼를 손쉽게 잡는 은탄환 따위는 존재하지 않았다. 결국 불필요한 요소를 제거해서 메모리를 덜 사용하는 식으로 코드를 변경했다.

import shelve
from collections import OrderedDict
import time # 캐시 효과 시연용

class CachedShelve:
    """
    shelve 객체를 위한 LRU 읽기 캐시를 제공하는 래퍼 클래스.
    컨텍스트 관리자 프로토콜을 지원합니다 ('with' 문 사용 가능).
    """

    def __init__(self, filename, cache_size=100, flag='c', writeback=False):
        """
        CachedShelve를 초기화합니다.

        Args:
            filename (str): shelve 파일 경로.
            cache_size (int): 캐시에 저장할 최대 항목 수 (LRU). 0보다 커야 합니다.
            flag (str): shelve.open()에 전달할 플래그 ('c', 'n', 'w', 'r').
            writeback (bool): shelve.open()에 전달할 writeback 플래그.
                              True로 설정 시 이 클래스의 캐싱 이점이 줄어들 수 있으며,
                              메모리 사용 및 데이터 유실 위험이 증가합니다. 비권장.
        """
        if cache_size <= 0:
            raise ValueError("Cache size must be a positive integer.")

        self.filename = filename
        self.cache_size = cache_size
        self.flag = flag
        self.writeback = writeback # shelve 자체의 writeback 사용 여부

        self._db = None
        # LRU 캐시를 위해 OrderedDict 사용
        self._cache = OrderedDict()
        print(f"CachedShelve initialized for '{filename}' with cache size {cache_size}")

    def __enter__(self):
        """컨텍스트 관리자 진입: shelve 파일을 열고 캐시를 비웁니다."""
        print(f"Opening shelve '{self.filename}' (writeback={self.writeback})...")
        # writeback 옵션도 shelve.open에 전달
        self._db = shelve.open(self.filename, flag=self.flag, writeback=self.writeback)
        self._cache.clear()
        print("Shelve opened and cache cleared.")
        return self # 'with ... as cs:' 에서 cs 변수에 할당될 객체

    def __exit__(self, exc_type, exc_val, exc_tb):
        """컨텍스트 관리자 종료: shelve 파일을 닫고 캐시를 비웁니다."""
        print(f"Closing shelve '{self.filename}'...")
        if self._db is not None:
            try:
                start_close = time.time()
                self._db.close() # writeback=True인 경우 시간이 걸릴 수 있음
                end_close = time.time()
                print(f"Shelve closed (took {end_close - start_close:.4f}s).")
            except Exception as e:
                print(f"Error closing shelve: {e}")
            finally:
                self._db = None
        self._cache.clear()
        print("Cache cleared.")
        if exc_type:
            print(f"Exception occurred in 'with' block: {exc_type.__name__}")
        # 예외를 전파시키려면 None 또는 False 반환 (기본값)
        return None

    def _check_open(self):
        """shelve가 열려 있는지 확인합니다."""
        if self._db is None:
            raise RuntimeError("Shelve is not open. Use within a 'with' block.")

    def __getitem__(self, key):
        """obj[key] 구문 지원 (읽기). 캐시 확인 후 shelve 접근."""
        self._check_open()

        # 1. 캐시 확인
        if key in self._cache:
            # 캐시 히트: 값 반환 (LRU 위해 순서 변경)
            # print(f"[Cache Hit] Key: '{key}'") # 디버깅용
            self._cache.move_to_end(key)
            return self._cache[key]
        else:
            # 2. 캐시 미스: shelve에서 읽기 (느림)
            # print(f"[Cache Miss] Key: '{key}', reading from shelve...") # 디버깅용
            # shelve에서 값을 읽음 (KeyError 발생 가능)
            value = self._db[key]

            # 3. 캐시에 추가
            self._cache[key] = value
            self._cache.move_to_end(key) # 방금 사용했으므로 맨 뒤로

            # 4. 캐시 크기 관리 (오래된 항목 제거)
            if len(self._cache) > self.cache_size:
                removed_key, removed_value = self._cache.popitem(last=False) # 가장 오래된 항목 제거
                # print(f"[Cache Evict] Removed '{removed_key}' from cache.") # 디버깅용

            return value

    def __setitem__(self, key, value):
        """obj[key] = value 구문 지원 (쓰기). shelve에 먼저 쓰고 캐시 업데이트."""
        self._check_open()

        # 1. shelve에 먼저 쓰기 (영속성 보장)
        self._db[key] = value
        # print(f"[Shelve Write] Key: '{key}'") # 디버깅용

        # 2. 캐시 업데이트 (또는 무효화)
        #    간단하게는 캐시에서도 값을 업데이트하고 LRU 순서 조정
        self._cache[key] = value
        self._cache.move_to_end(key) # 방금 썼으므로 맨 뒤로

        # 3. 캐시 크기 관리 (새 항목 추가로 인한 제거)
        if len(self._cache) > self.cache_size:
            removed_key, removed_value = self._cache.popitem(last=False)
            # print(f"[Cache Evict] Removed '{removed_key}' after set.") # 디버깅용

        # 대안: 쓰기 시 캐시 항목을 그냥 삭제하여 다음 읽기 시 다시 로드하게 할 수도 있음
        # if key in self._cache:
        #     del self._cache[key]

    def __delitem__(self, key):
        """del obj[key] 구문 지원. shelve에서 먼저 삭제 후 캐시에서도 삭제."""
        self._check_open()

        # 1. shelve에서 먼저 삭제 (KeyError 발생 가능)
        del self._db[key]
        # print(f"[Shelve Delete] Key: '{key}'") # 디버깅용

        # 2. 캐시에서도 삭제 (존재하는 경우)
        if key in self._cache:
            del self._cache[key]
            # print(f"[Cache Delete] Key: '{key}'") # 디버깅용

    def __contains__(self, key):
        """'key in obj' 구문 지원. 캐시 먼저 확인 후 shelve 확인."""
        self._check_open()
        # 캐시에 있으면 True 반환 (빠름)
        if key in self._cache:
            return True
        # 캐시에 없으면 shelve 확인 (느림)
        # 이 확인만으로는 캐시에 추가하지 않음
        return key in self._db

    def get(self, key, default=None):
        """딕셔너리의 get과 유사하게 작동. 키 없으면 default 반환."""
        try:
            # __getitem__을 사용하여 캐싱 로직 활용
            return self[key]
        except KeyError:
            # __getitem__에서 KeyError가 발생하면 (shelve에 키 없음) default 반환
            # print(f"Key '{key}' not found, returning default.") # get 호출 시에만 출력 (필요시 활성화)
            return default
        except RuntimeError as e: # shelve가 닫혀있을 때
             raise e
        except Exception as e: # 기타 예상치 못한 오류
             print(f"Error in get method for key '{key}': {e}")
             return default # 예상치 못한 오류 시에도 default 반환

    # --- 추가 유틸리티 메소드 ---
    def sync(self):
        """내부 shelve 객체의 sync()를 호출합니다."""
        self._check_open()
        print("Syncing underlying shelve...")
        self._db.sync()

    def clear_cache(self):
        """수동으로 캐시를 비웁니다."""
        print("Clearing cache manually.")
        self._cache.clear()

    def __len__(self):
        """len(obj) 지원. 실제 shelve의 크기를 반환합니다 (캐시 크기 아님)."""
        self._check_open()
        return len(self._db)

    def keys(self):
        """
        shelve의 키 목록 (뷰)을 반환합니다 (캐시 아님).
        이는 실제 shelve 파일의 모든 키를 나타냅니다.
        """
        self._check_open()
        return self._db.keys()

    # --- 추가된 메소드 ---
    def values(self):
        """
        shelve의 값 목록 (뷰)을 반환합니다 (캐시 아님).
        주의: 큰 shelve의 경우 모든 값을 로드해야 하므로 느릴 수 있습니다.
        캐시의 이점을 활용하지 않습니다.
        """
        self._check_open()
        # 실제 shelve 객체의 values() 메소드를 호출하여 반환
        return self._db.values()

    def items(self):
        """
        shelve의 키-값 쌍 목록 (뷰)을 반환합니다 (캐시 아님).
        주의: 큰 shelve의 경우 모든 항목을 로드해야 하므로 느릴 수 있습니다.
        캐시의 이점을 활용하지 않습니다.
        """
        self._check_open()
        # 실제 shelve 객체의 items() 메소드를 호출하여 반환
        return self._db.items()

# --- 클래스 사용 예제 ---
if __name__ == "__main__":
    filename = 'my_cached_shelve.db'
    cache_size = 3

    # 1. 데이터 쓰기 (with 사용)
    print("\n--- Writing data ---")
    try:
        with CachedShelve(filename, cache_size=cache_size, flag='c') as cs:
            cs['a'] = 1
            cs['b'] = {'x': 10, 'y': 20}
            cs['c'] = [1, 2, 3]
            cs['d'] = "hello"
            cs['e'] = "world"
            print(f"Length of shelve: {len(cs)}")
            print(f"Keys in shelve: {list(cs.keys())}") # list()로 변환하여 내용 확인
            print(f"Values in shelve: {list(cs.values())}")
            print(f"Items in shelve: {list(cs.items())}")

    except Exception as e:
        print(f"An error occurred during writing: {e}")

    # 2. 데이터 읽기 및 캐시 확인 (새로운 with 블록)
    print("\n--- Reading data and testing cache ---")
    try:
        with CachedShelve(filename, cache_size=cache_size, flag='r') as cs: # 읽기 모드
            print(f"Accessing 'e': {cs['e']}") # Cache Miss, Load 'e' -> Cache: {'e'}
            print(f"Accessing 'd': {cs['d']}") # Cache Miss, Load 'd' -> Cache: {'e', 'd'}
            print(f"Accessing 'c': {cs['c']}") # Cache Miss, Load 'c' -> Cache: {'e', 'd', 'c'}
            print(f"Accessing 'b': {cs['b']}") # Cache Miss, Load 'b', Evict 'e' -> Cache: {'d', 'c', 'b'}
            print(f"Accessing 'e': {cs['e']}") # Cache Miss (evicted), Load 'e', Evict 'd' -> Cache: {'c', 'b', 'e'}
            print(f"Accessing 'c': {cs['c']}") # Cache Hit, Move 'c' -> Cache: {'b', 'e', 'c'}

            # get() 메소드 테스트
            print(f"Getting 'a': {cs.get('a')}") # Cache Miss, Load 'a', Evict 'b' -> Cache: {'e', 'c', 'a'}
            print(f"Getting 'z' (non-existent): {cs.get('z', 'Not Found')}")

            # __contains__ 테스트
            print(f"Is 'a' in cs? {'a' in cs}") # Cache Hit
            print(f"Is 'b' in cs? {'b' in cs}") # Cache Miss (evicted), Check in shelve -> True
            print(f"Is 'z' in cs? {'z' in cs}") # Check in shelve -> False

            # values() 와 items() 사용
            print("\n--- Using values() and items() ---")
            # 이 메소드들은 캐시를 직접 활용하지 않고 shelve 전체를 대상으로 함
            print("All values:", list(cs.values()))
            print("All items:", list(cs.items()))

    except Exception as e:
        print(f"An error occurred during reading: {e}")

    # 3. 데이터 삭제 (새로운 with 블록)
    print("\n--- Deleting data ---")
    try:
        # 삭제를 위해 flag='c' 또는 'w' 사용
        with CachedShelve(filename, cache_size=cache_size, flag='c') as cs:
            print("Current keys:", list(cs.keys()))
            # 'a'가 캐시에 있을 수 있음 (마지막 get 호출)
            print(f"Cache before del 'a': {list(cs._cache.keys())}")
            del cs['a']
            print(f"Deleted 'a'. Cache after del: {list(cs._cache.keys())}") # 캐시에서도 삭제됨
            print("Keys after deleting 'a':", list(cs.keys()))

            # 캐시에 없는 항목 삭제 시도
            if 'b' not in cs._cache: print("'b' is not in cache.")
            del cs['b']
            print("Keys after deleting 'b':", list(cs.keys()))
            print(f"Cache after del 'b': {list(cs._cache.keys())}") # 캐시에 없었으므로 변화 없음

    except KeyError as e:
        print(f"Tried to delete non-existent key: {e}")
    except Exception as e:
        print(f"An error occurred during deletion: {e}")

    # shelve 파일 자체 삭제 (정리)
    import os
    for ext in ['', '.bak', '.dat', '.dir']: # shelve가 만드는 파일 확장자들
        try:
            os.remove(filename + ext)
            print(f"Removed {filename + ext}")
        except FileNotFoundError:
            pass

쓰기는?

gemini가 작성해준 코드가 아까워서 글을 올리려고 보니 속도가 느린 이유가 있기도 한 것 같다. set부분은 그냥 생각 없이 모두 shelve에 기록하고 있었다. 그러니 get 부분에서만 캐시 히트하는 정도의 속도 향상 밖에는 없었다고 할 수 있겠다. 물론 이 부분도 gemini에 넣으면 알아서 고쳐주겠지? 라는 생각으로 넣어봤다. 그랬더니 쓰기 캐시를 추가한 버전을 만들어 주었다.

import shelve
from collections import OrderedDict
import time
import warnings # 경고 메시지용

# 쓰기 버퍼에서 삭제된 항목을 표시하기 위한 고유 객체
_DELETED_SENTINEL = object()

class CachedShelve:
    """
    shelve 객체를 위한 LRU 읽기 캐시 및 쓰기 지연 버퍼를 제공하는 래퍼 클래스.
    쓰기 작업은 버퍼에 먼저 기록되고, 컨텍스트 종료, sync() 호출 시,
    또는 쓰기 버퍼가 설정된 한계치(write_buffer_limit)에 도달했을 때 shelve 파일에 반영됩니다.

    **경고:** 쓰기 지연 방식으로 인해 프로그램이 비정상 종료될 경우,
             마지막 동기화 이후의 변경 사항이 유실될 수 있습니다.
             shelve.open의 writeback=True 플래그와 함께 사용하는 것은 권장되지 않습니다.

    컨텍스트 관리자 프로토콜을 지원합니다 ('with' 문 사용 가능).
    """

    def __init__(self, filename, cache_size=100, write_buffer_limit=None, flag='c', writeback=False):
        """
        CachedShelve를 초기화합니다.

        Args:
            filename (str): shelve 파일 경로.
            cache_size (int): 읽기 캐시에 저장할 최대 항목 수 (LRU). 0보다 커야 합니다.
            write_buffer_limit (int, optional): 쓰기 버퍼에 저장할 최대 항목 수.
                                               None이면 무제한. 이 한계에 도달하면 버퍼 전체가
                                               자동으로 플러시(동기화)됩니다. 0보다 커야 합니다.
            flag (str): shelve.open()에 전달할 플래그 ('c', 'n', 'w', 'r').
            writeback (bool): shelve.open()에 전달할 writeback 플래그.
                              **True 설정은 이 클래스의 쓰기 지연 방식과 충돌할 수 있어 강력히 비권장됩니다.**
        """
        if cache_size <= 0:
            raise ValueError("Cache size must be a positive integer.")
        if writeback:
             raise ValueError("Cannot use shelve's writeback=True with CachedShelve's write buffering. Set writeback=False.")
        if write_buffer_limit is not None and write_buffer_limit <= 0:
            raise ValueError("Write buffer limit must be a positive integer or None.")


        self.filename = filename
        self.cache_size = cache_size
        # --- New ---
        self.write_buffer_limit = write_buffer_limit
        # -----------
        self.flag = flag
        self.shelve_writeback = False # Always False for internal shelve

        self._db = None
        self._cache = OrderedDict()
        self._write_buffer = {}

        limit_msg = f"write buffer limit={self.write_buffer_limit}" if self.write_buffer_limit else "unlimited write buffer"
        print(f"CachedShelve initialized for '{filename}' with read cache size {cache_size}, {limit_msg} (Write Buffering Enabled)")

    # __enter__, __exit__, _check_open 은 이전과 동일

    def __enter__(self):
        """컨텍스트 관리자 진입: shelve 파일을 열고 캐시와 버퍼를 비웁니다."""
        print(f"Opening shelve '{self.filename}' (internal writeback=False)...")
        self._db = shelve.open(self.filename, flag=self.flag, writeback=self.shelve_writeback)
        self._cache.clear()
        self._write_buffer.clear()
        print("Shelve opened, read cache and write buffer cleared.")
        return self

    def __exit__(self, exc_type, exc_val, exc_tb):
        """컨텍스트 관리자 종료: 버퍼를 플러시하고 shelve 파일을 닫습니다."""
        print("Exiting context...")
        if self._db is not None:
            try:
                if self._write_buffer: # 버퍼에 내용이 있을 때만 플러시 시도
                    print("Flushing write buffer on exit...")
                    start_flush = time.time()
                    self._flush_write_buffer()
                    end_flush = time.time()
                    print(f"Write buffer flushed on exit (took {end_flush - start_flush:.4f}s).")
                else:
                    print("Write buffer empty on exit, no flush needed.")

            except Exception as e:
                print(f"Error during buffer flush on exit: {e}")
                # Depending on policy, you might want to re-raise here

            finally:
                print(f"Closing shelve '{self.filename}'...")
                try:
                    start_close = time.time()
                    self._db.close()
                    end_close = time.time()
                    print(f"Shelve closed (took {end_close - start_close:.4f}s).")
                except Exception as e:
                    print(f"Error closing shelve: {e}")
                finally:
                    self._db = None

        self._cache.clear()
        # Ensure buffer is clear even if flush failed (or wasn't needed but close failed)
        self._write_buffer.clear()
        print("Read cache and write buffer cleared.")

        if exc_type:
            print(f"Exception occurred in 'with' block: {exc_type.__name__}")
            print(f"WARNING: Changes made since the last sync might be lost due to the exception.")

        return None # Propagate exception


    def _check_open(self):
        """shelve가 열려 있는지 확인합니다."""
        if self._db is None:
            raise RuntimeError("Shelve is not open. Use within a 'with' block or ensure it's manually opened.")


    def _flush_write_buffer(self):
        """쓰기 버퍼의 내용을 실제 shelve 객체에 반영하고 버퍼를 비웁니다."""
        self._check_open()
        if not self._write_buffer:
            # print("Write buffer is empty, nothing to flush.") # Avoid noise if called often
            return

        print(f"Flushing {len(self._write_buffer)} items from write buffer to shelve...")
        items_processed = 0
        errors_occurred = 0
        # Use list(self._write_buffer.items()) to avoid issues if flushing modifies the buffer indirectly
        # Though in this simple flush, it shouldn't be an issue.
        for key, value in list(self._write_buffer.items()):
            try:
                if value is _DELETED_SENTINEL:
                    if key in self._db:
                        del self._db[key]
                else:
                    self._db[key] = value
                items_processed += 1
            except Exception as e:
                errors_occurred += 1
                print(f"Error flushing key '{key}': {e}")

        print(f"Flush complete: Processed {items_processed} items with {errors_occurred} errors.")
        self._write_buffer.clear()
        # Optional: force disk write immediately (can impact performance)
        # self._db.sync()
        # print("Underlying shelve synced after flush.")

    # --- New Helper Method ---
    def _check_and_flush_buffer_if_full(self):
        """쓰기 버퍼가 설정된 한계에 도달했는지 확인하고, 도달했다면 플러시합니다."""
        if self.write_buffer_limit is not None and len(self._write_buffer) >= self.write_buffer_limit:
            print(f"Write buffer limit ({self.write_buffer_limit}) reached. Auto-flushing...")
            self._flush_write_buffer()
            # print("Auto-flush complete.") # Included in _flush_write_buffer now


    # __getitem__ 은 이전과 동일

    def __getitem__(self, key):
        """obj[key] 구문 지원 (읽기). 버퍼 -> 캐시 -> shelve 순으로 확인."""
        self._check_open()

        # 1. 쓰기 버퍼 확인 (최신 상태 반영)
        if key in self._write_buffer:
            value = self._write_buffer[key]
            if value is _DELETED_SENTINEL:
                raise KeyError(key)
            else:
                # Update read cache as well
                self._cache[key] = value
                self._cache.move_to_end(key)
                if len(self._cache) > self.cache_size:
                    self._cache.popitem(last=False)
                return value

        # 2. 읽기 캐시 확인
        if key in self._cache:
            self._cache.move_to_end(key)
            return self._cache[key]

        # 3. shelve에서 읽기
        value = self._db[key] # May raise KeyError

        # 4. 읽기 캐시에 추가
        self._cache[key] = value
        self._cache.move_to_end(key)

        # 5. 캐시 크기 관리
        if len(self._cache) > self.cache_size:
            self._cache.popitem(last=False)

        return value


    def __setitem__(self, key, value):
        """obj[key] = value 구문 지원 (쓰기). 쓰기 버퍼에 우선 기록. 버퍼가 차면 자동 플러시."""
        self._check_open()

        # --- Modified ---
        # 버퍼에 추가하기 *전에* 가득 찼는지 확인하고 필요시 플러시
        self._check_and_flush_buffer_if_full()
        # --- End Modified ---

        # 1. 쓰기 버퍼에 값 저장
        self._write_buffer[key] = value
        # print(f"[Buffer Write] Key: '{key}', Buffer size: {len(self._write_buffer)}") # Debugging

        # 2. 읽기 캐시에도 반영
        self._cache[key] = value
        self._cache.move_to_end(key)

        # 3. 읽기 캐시 크기 관리
        if len(self._cache) > self.cache_size:
            self._cache.popitem(last=False)

    def __delitem__(self, key):
        """del obj[key] 구문 지원. 쓰기 버퍼에 삭제 표시. 버퍼가 차면 자동 플러시."""
        self._check_open()

        # 삭제 전 키 존재 여부 확인
        if not self.__contains__(key):
             raise KeyError(key)

        # --- Modified ---
        # 버퍼에 추가하기 *전에* 가득 찼는지 확인하고 필요시 플러시
        self._check_and_flush_buffer_if_full()
        # --- End Modified ---

        # 1. 쓰기 버퍼에 삭제 표시
        self._write_buffer[key] = _DELETED_SENTINEL
        # print(f"[Buffer Delete] Key: '{key}', Buffer size: {len(self._write_buffer)}") # Debugging


        # 2. 읽기 캐시에서도 제거
        if key in self._cache:
            del self._cache[key]

    # __contains__, get, sync, clear_cache, __len__, keys, values, items 은 이전과 동일

    def __contains__(self, key):
        """'key in obj' 구문 지원. 버퍼 -> 캐시 -> shelve 순 확인."""
        self._check_open()
        if key in self._write_buffer:
            return self._write_buffer[key] is not _DELETED_SENTINEL
        if key in self._cache:
            return True
        return key in self._db

    def get(self, key, default=None):
        """딕셔너리의 get과 유사하게 작동. 키 없으면 default 반환."""
        try:
            return self[key]
        except KeyError:
            return default
        except RuntimeError as e:
             raise e
        except Exception as e:
             print(f"Error in get method for key '{key}': {e}")
             return default

    def sync(self):
        """
        쓰기 버퍼의 변경 사항을 즉시 shelve 파일에 반영합니다.
        """
        self._check_open()
        print("Manual Sync: Flushing write buffer to shelve...")
        self._flush_write_buffer()
        # print("Manual Sync complete.") # Included in _flush_write_buffer

    def clear_cache(self):
        """
        수동으로 읽기 캐시만 비웁니다. 쓰기 버퍼는 유지됩니다.
        """
        print("Clearing read cache manually (write buffer remains).")
        self._cache.clear()

    def __len__(self):
        """
        len(obj) 지원. 실제 shelve와 쓰기 버퍼의 변경 사항을 조합하여 크기 계산.
        """
        self._check_open()
        return len(list(self.keys())) # Based on keys() result for accuracy

    def keys(self):
        """
        shelve와 쓰기 버퍼를 조합한 현재 키 집합을 반환합니다. (set으로 반환)
        """
        self._check_open()
        db_keys = set(self._db.keys())
        buffer_added_keys = {k for k, v in self._write_buffer.items() if v is not _DELETED_SENTINEL}
        buffer_deleted_keys = {k for k, v in self._write_buffer.items() if v is _DELETED_SENTINEL}
        final_keys = (db_keys | buffer_added_keys) - buffer_deleted_keys
        return final_keys

    def values(self):
        """
        shelve와 쓰기 버퍼를 조합한 현재 값들의 제너레이터를 반환합니다.
        """
        self._check_open()
        for key in self.keys():
            yield self[key] # __getitem__ handles buffer/cache/db lookup

    def items(self):
        """
        shelve와 쓰기 버퍼를 조합한 현재 (키, 값) 쌍들의 제너레이터를 반환합니다.
        """
        self._check_open()
        for key in self.keys():
            yield (key, self[key]) # __getitem__ handles buffer/cache/db lookup


# --- 클래스 사용 예제 (쓰기 버퍼 제한 및 자동 플러시 확인) ---
if __name__ == "__main__":
    filename = 'my_autoflush_shelve.db'
    read_cache_size = 2
    # --- New: Set write buffer limit ---
    write_limit = 3

    print(f"\n--- Test with Write Buffer Limit = {write_limit} ---")

    try:
        # flag='n' : 항상 새 파일 생성
        with CachedShelve(filename, cache_size=read_cache_size, write_buffer_limit=write_limit, flag='n') as cs:
            print("\nAdding items (limit should trigger flush)...")
            cs['a'] = 1 # Buffer: {'a': 1} (Size 1)
            print(f"Buffer size: {len(cs._write_buffer)}")
            cs['b'] = 2 # Buffer: {'a': 1, 'b': 2} (Size 2)
            print(f"Buffer size: {len(cs._write_buffer)}")
            cs['c'] = 3 # Buffer: {'a': 1, 'b': 2, 'c': 3} (Size 3) - Limit reached
            print(f"Buffer size: {len(cs._write_buffer)}")

            print("\nAdding item 'd' (should trigger auto-flush now)")
            # Below line should trigger _check_and_flush_buffer_if_full()
            cs['d'] = 4
            # Flush happens, buffer cleared, then 'd' is added
            # Buffer: {'d': 4} (Size 1)
            print(f"Buffer size after adding 'd': {len(cs._write_buffer)}")
            print(f"Current keys (after potential flush): {list(cs.keys())}")

            print("\nAdding more items...")
            cs['e'] = 5 # Buffer: {'d': 4, 'e': 5} (Size 2)
            print(f"Buffer size: {len(cs._write_buffer)}")
            cs['f'] = 6 # Buffer: {'d': 4, 'e': 5, 'f': 6} (Size 3) - Limit reached again
            print(f"Buffer size: {len(cs._write_buffer)}")

            print("\nDeleting 'a' (should trigger auto-flush)")
            # 'a' was flushed earlier, now we delete it. Buffer limit reached.
            del cs['a']
            # Flush happens (d, e, f written), buffer cleared, then 'a' deletion added
            # Buffer: {'a': SENTINEL} (Size 1)
            print(f"Buffer size after deleting 'a': {len(cs._write_buffer)}")

            cs['g'] = 7 # Buffer: {'a': SENTINEL, 'g': 7} (Size 2)
            print(f"Buffer size: {len(cs._write_buffer)}")
            print(f"Final keys before exit: {list(cs.keys())}")
            print(f"Final buffer content before exit: {cs._write_buffer}")

        # Exit flushes the remaining buffer {'a': SENTINEL, 'g': 7}
        print("\n--- After 'with' block (final flush on exit) ---")

    except Exception as e:
        print(f"An error occurred: {e}")
        # Clean up in case of error during test
        import os
        for ext in ['', '.bak', '.dat', '.dir']:
            try: os.remove(filename + ext)
            except FileNotFoundError: pass
        raise # Re-raise exception

    # Verify final contents
    print("\n--- Verifying final contents in shelve ---")
    try:
        with CachedShelve(filename, flag='r') as cs_read: # Read-only
            print(f"Final keys in shelve: {sorted(list(cs_read.keys()))}") # sorted for consistent output
            expected_keys = {'b', 'd', 'e', 'f', 'g'} # a deleted, c flushed then overwritten by flush of a's deletion? No, c was flushed. b was flushed. d,e,f flushed. a deleted in final flush, g added in final flush.
            actual_keys = cs_read.keys()

            if actual_keys == expected_keys:
                print("Verification successful!")
                print("Values:")
                for k in sorted(actual_keys):
                    print(f"  {k}: {cs_read[k]}")
            else:
                print(f"Verification FAILED!")
                print(f"  Expected: {sorted(list(expected_keys))}")
                print(f"  Actual:   {sorted(list(actual_keys))}")

    except Exception as e:
        print(f"An error occurred during verification: {e}")

    finally:
        # Clean up shelve files
        import os
        print("\nCleaning up shelve files...")
        for ext in ['', '.bak', '.dat', '.dir']:
            try:
                os.remove(filename + ext)
                # print(f"Removed {filename + ext}")
            except FileNotFoundError:
                pass
        print("Cleanup complete.")

sync i/o 최적화는?

그럼에도 이 또한 sync 과정에서 i/o가 개별적으로 발생하니 조삼모사 같기도 하다. 거기에 대한 gemini의 생각은 아래와 같다고 한다. 내심 처음 생각했던게 sqlite였는데 코드 고치기가 싫어서 다른 방법 찾다가 돌고돌아 결국 다시 원점으로 왔나 싶기도 하다. 뭔가 수미상관인가?

네, 아주 정확한 지적입니다! 현재 _flush_write_buffer 메소드는 _write_buffer의 각 항목에 대해 루프를 돌면서 self._db[key] = value 또는 del self._db[key]를 호출합니다. shelve 객체는 딕셔너리처럼 동작하지만, 내부적으로는 각 할당/삭제 작업이 (대부분의 dbm 구현에서) 개별적인 파일 I/O 작업으로 이어질 수 있습니다. 따라서 버퍼에 100개의 변경 사항이 있었다면, 플러시 과정에서 100번의 작은 디스크 접근이 발생할 수 있습니다.

이 플러시 과정 자체를 최적화하여 I/O를 모아서 한 번에 처리할 수 있을까요?

안타깝게도 표준 shelve 모듈과 그 기반의 dbm 라이브러리 수준에서는 이 작업을 직접적으로 제어하거나 보장하는 간단하고 표준적인 방법이 제한적입니다.

몇 가지 관련된 측면과 가능한 접근법(및 한계)을 살펴보겠습니다.

shelve의 내부 동작 및 dbm:

shelve는 키-값 저장을 위해 dbm (예: dbm.gnu, dbm.ndbm, dbm.dumb) 같은 라이브러리를 사용합니다. 이러한 dbm 라이브러리가 내부적으로 어느 정도의 쓰기 버퍼링을 수행할 수는 있지만, shelve 모듈 자체가 "여러 항목을 한 번의 I/O 작업으로 쓰기" 위한 명시적인 공개 API(예: update_batch(items))를 제공하지는 않습니다.

따라서 self._db[key] = value 호출이 즉시 디스크에 쓰일지, 내부 dbm 버퍼에 들어갈지는 사용 중인 dbm 구현과 운영체제에 따라 달라질 수 있으며, 파이썬 코드 수준에서 직접 제어하기 어렵습니다.

shelve.sync()의 역할:

shelve 객체의 sync() 메소드는 아직 디스크에 기록되지 않은 데이터를 강제로 쓰도록 요청합니다.

만약 _flush_write_buffer 루프가 끝난 후 self._db.sync()를 호출하면, 루프 동안 요청된 모든 개별 쓰기 작업들이 (만약 dbm이나 OS 수준에서 버퍼링되고 있었다면) 디스크에 확실히 반영되도록 보장하는 데 도움이 됩니다.

하지만 이것이 루프 동안 발생한 여러 번의 I/O 요청 자체를 한 번의 큰 I/O 요청으로 바꿔주지는 못할 가능성이 높습니다. 이미 여러 번의 쓰기/삭제 작업이 dbm 계층에 전달되었을 수 있습니다.

shelve(writeback=True) 재고:

이전에 우리는 writeback=True 사용을 금지했습니다. 하지만 이론적으로, 만약 shelve.open(..., writeback=True)를 사용한다면, _flush_write_buffer 루프에서 self._db[key] = value 등을 호출하는 것이 shelve의 내부 메모리 캐시만 업데이트할 수 있습니다. 그리고 루프가 끝난 후 self._db.sync()를 한 번 호출하면, shelve가 내부 캐시의 모든 변경 사항을 (어쩌면 더 효율적으로) 디스크에 쓸 수도 있습니다.

단점: 이전에 논의했듯이 메모리 사용량 증가 (우리 캐시 + shelve 캐시), 복잡성 증가, shelve 내부 동작 의존성, 우리 캐싱 전략과의 충돌 가능성 등 문제가 많아 여전히 권장하기 어렵습니다.

shelve.update() 사용:

shelve 객체도 딕셔너리처럼 update() 메소드를 가집니다. 쓰기 버퍼의 내용을 딕셔너리로 만들어 self._db.update(write_dict)를 호출하면 어떨까요?

한계: 파이썬의 일반적인 update() 구현은 단순히 입력 딕셔너리를 반복하며 각 항목에 대해 __setitem__을 호출하는 것과 같습니다. 따라서 _db.update(d)는 for k, v in d.items(): _db[k] = v와 동일하게 동작할 가능성이 높으며, I/O 최적화를 보장하지 않습니다. (삭제 작업은 별도로 처리해야 함).

대안: 다른 백엔드 사용:

이 문제의 근본적인 해결책은 shelve 대신 명시적인 배치(batch) 쓰기 API를 제공하는 다른 저장소 백엔드를 사용하는 것입니다.

SQLite: sqlite3 모듈을 사용하여 여러 SQL INSERT, UPDATE, DELETE 문을 하나의 트랜잭션으로 묶어 실행하면 훨씬 효율적입니다.

LMDB (Lightning Memory-Mapped Database): lmdb 파이썬 라이브러리는 트랜잭션 내에서 여러 쓰기 작업을 효율적으로 처리하는 기능을 제공합니다.

LevelDB/RocksDB: 이 라이브러리들도 배치 쓰기 기능을 제공하는 경우가 많습니다.

단점: 이는 CachedShelve 클래스의 기반 저장소를 shelve가 아닌 다른 것으로 완전히 바꾸는 큰 변경이며, 기존 shelve 파일과의 호환성이 사라집니다.

결론:

현재 CachedShelve 클래스가 표준 shelve 모듈을 사용하는 한, _flush_write_buffer 내의 여러 쓰기/삭제 요청을 하나의 최적화된 디스크 I/O 작업으로 확실하게 묶는 것은 어렵습니다. shelve API의 한계와 dbm 구현의 다양성 때문입니다.

우리가 할 수 있는 최선은 다음과 같습니다.

쓰기 지연: 현재 구현처럼 _write_buffer를 사용하여 shelve에 대한 접근 자체를 최대한 지연시키는 것 (이것만으로도 상당한 성능 향상이 있을 수 있습니다).

sync() 호출: _flush_write_buffer가 끝난 후 self._db.sync()를 호출하여 데이터의 디스크 기록을 보장하는 것 (선택 사항, 내구성은 높이지만 약간의 추가 오버헤드 발생 가능).

만약 플러시 과정 자체의 I/O 효율을 극대화하는 것이 매우 중요하다면, shelve 대신 SQLite나 LMDB 같은 다른 백엔드를 사용하도록 클래스를 재설계하는 것을 고려해야 합니다.

결론

결국 데이터 구조를 변경해서 해결했으니 이 모든 논의가 쓸모 없는 시간 낭비는 아닐까라는 생각이 들수도 있다. 하지만 과정이 재밌었고, 뭔가 배운게 있었다면 된 거 아닌가 싶다. 공자 선생님께서 말씀하셨듯이 배우고 때때로 익히면 또한 즐겁지 아니한가?

어쨌든, 오늘의 교훈. 구글도 이제 감 잡은 거 같기도 하다는 거. gemini 2.5 pro 몹시 훌륭하다. 벤치마크에서는 양민 학살중~

덧) 인공지능은 실수할 수 있다. 여기 올려진 코드에 버그가 있다고 너무 나무라지는 말자. 직접 작성해도 그 정도 버그는 나온다. 참고로 gemini는 저 모든 코드를 타이핑 하는 속도보다 빠르게 만들었다.

[ai] 바이브 코딩의 시대

Tue, 25 Mar 2025 13:00:01 GMT

안드레 카파시 말처럼 바이브에 몸을 맡기자.

바이브 코딩이 유행이다. 직접 코딩하지 않고 자연어로 인공지능에 명령만 해서 코딩을 하는 것을 말하는 의미다. 통상 80% 이상을 인공지능이 작성하면 바이브 코딩으로 보는 추세인 것 같다. 바이브 코딩으로 게임을 만들어서 큰 돈을 벌었다는 사람도 있고, SNS에는 온갖 것들을 바이브 코딩으로 만들었다는 개발자 또는 비개발자들의 글이 넘쳐난다.

한편, 이를 바라보는 직업 프로그래머의 반응은 엇갈린다. 바이브에 올라타는 사람도 있고, 그로인한 리팩토링 대란이 벌어질 것이라는 얘기를 하는 사람들도 있다. 어쨌든 나는 바이브에 올라탄 사람 중에 한 명이긴 하다.

#0

내가 처음 바이브 코딩을 해본 건 작년 한글날 정도였던 것 같다. 한창 새로운 제품 코드를 작성하고 있었다. 이 제품은 몇 년을 개발이 지지부진한 것 중에 하나였다. 내가 코드를 쓰지 않은 것도 있었지만 새로운 제품을 우리가 감당할 수 있을까, 라는 생각도 컸었다. 새로운 제품은, 새로운 테스트를, 새로운 지원을, 새로운 영업을, 새로운 홍보를 필요로하는 일이니 말이다. 하지만 우리는 힘든 시기를 겪고 있었고, 더이상 미룰 수는 없었다. 마침 o1-preview가 출시되기도 했었다. 거기다 세월을 묵힌 시간만큼 리서치 자료는 많이 쌓여 있었다. 벤치마킹할 타사 제품도 수두룩했다.

처음에는 ChatGPT와 함께 작성하기 시작했다. 주로 4o에게 작업을 지시하고 결과를 내가 복붙해서 확인하는 작업이었다. ChatGPT로는 전체 프로그램을 한번에 작성하는 것은 쉽지 않기 때문에 전체 구조는 내가 생각했고 주로 함수 단위로 코딩을 지시해서 붙여넣었다. 당연히 출발은 우리의 리서치 자료에서 시작했다. 얼추 해당 자료대로 모두 구현을 했다. 그런데 테스트를 돌리니 예외가 너무 많이 발생했다. 리서치 자료가 크게 도움이 되지 않은 상황이었다.

여기서부터는 멘붕, 과연 이걸 해결할 수 있을까, 라는 생각. 대충 땜빵식으로 해결할수도 있겠지만 리얼월드에서는 무슨 일이 벌어질지 모르는 것이라 그것도 한계가 있었다. 모든걸 원점 재검토가 필요한 상황이었다. 그렇게 새로운 방법을 시도했다. 하지만 번번히 예외 케이스들이 너무 많이 발생하는게 문제였다. 코딩이 문제가 아니라 문서화되지 않은 것들에 대한 구조를 이해하는 게 핵심이었는데 그건 나도 모르고, ChatGPT도 모르는 게 큰 일이었다. 당연한 얘기였지만 다른 제품들도 모두 안되기는 마찬가지였다. 왜냐하면 타사 제품도 모두 동일한 오픈소스를 사용하고 있었고, 그 오픈소스 코드가 잘 동작하지 않는 경우가 많은게 문제였기 때문이다.

그렇게 설계를 3-4번은 뒤집어 엎었다. 최종적으로는 ChatGPT와 함께 오픈소스를 이해하기로 했다. 오픈소스는 너무 커서 거기서 내가 필요한 부분을 찾는 것도 일이었는데 웃긴 건 ChatGPT가 그걸 학습해서 그런지 오픈소스에서 내가 필요한 코드가 어디 있는지 물어보면 기가 막히게 알려줬다. 물론 오픈소스라는게 코드만 있다고 이해가 되는 건 아니다. 이해가 되지 않는 부분은 ChatGPT에 넣어서 다시 설명을 요청했다. 그 이해한 걸 토대로 ChatGPT한테 코딩을 시켜서 코드를 작성했다. 그 모든 작업을 하는 동안 o1-preview를 사용할 일은 한 번 밖에 없었다.

그러다 커서라는 걸 알게됐고 커서로 코딩을 시작했다. 커서는 전체 컨텍스트를 자동으로 llm에 보내 주기 때문에 코딩이 훨씬 편했다. 인라인 에디팅이나 블록을 지정해서 고치기가 훨씬 쉬운게 장점이었다. 그리고 브라우저로 와리가리 안해도 되서 시간이 많이 절약됐다. 그렇게 돌아보니 80%는 아니라도 얼추 70%는 인공지능이 코딩한 제품이 완성됐다. 그때는 바이브 코딩이란 말도 없던 시기라 묘한 기분이 들었다. 제품이 다 작성됐고 빌드 후 테스트를 진행하는 단계가 되니 뭔가 ChatGPT랑 뒷풀이라도 해야 할 것 같다는 생각이 들었다.

사람이면 설계를 3-4번 뒤집는 일을 참지 못했을 것 같다는 생각. 작성했지만 버렸던 수많은 코드에 엄청난 에고로 집착했을거라는 생각. 그리고 웃기게도 이 거대한 작업에서의 나에게 아하 모멘트는 이런 부분이었다. A라는 오픈소스에서 B라는 기능 관련된 코드가 어디있는지 알려줘. 이걸 당연히 답할거라고 생각을 안해서 물어볼 생각을 안했는데 하도 답답해서 물어봤는데 정말 어처구니 없을 정도로 정확하게 코드 위치를 잘 알려주었다.

#1

해가 바뀌었고 deepseek가 미국 주도 인공지능 세계에 한차례 충격을 가했다. 더불어 인공지능 오픈소스 생태계는 더욱 풍성해졌다. 장비를 구성할 능력만 되면 로컬에서도 o1 급의 리즈닝 모델을 돌릴 수 있는 세상이 된 것이다. 물론 deepseek-r1은 아직 로컬에서는 돌리기 부담스러운 671b 모델이긴 하다. 하지만 뒤따라 출시된 qwen2.5-coder-32b나 qwq-32b 같은 모델만 사용해도 나쁘지 않은 성능을 보여주었다. 그도 그럴것이 앞서도 언급했지만 대부분의 보통 프로그래머가 작성하는 코드란게 뭔가 대단한 코드가 아니기 때문이다. 안타깝게도 우리는 너무나 뻔한 코드를 대부분 작성하는 경우가 다반사니까 말이다.

최근에 일감이 하나 올라왔다. 고객사에서 api 사용에 문제를 겪는 일감이었다. 업체측에서 친절하게도 본인들이 구현한 코드를 보내주었다. 신입 개발자에게 확인해보라고 했지만 쉽지 않을거라는 생각이 들긴 했다. 그렇다고 내가 앉아서 그 모든 걸 보고 있기엔 다른 급한 일감도 너무 많았다. 그래서 딸깍 코딩을 해보기로 했다. 일감 내용과 업체 코드를 집어 넣고 문제를 재현할 수 있는 테스트 코드를 작성하라고 했다. 아키텍트로 qwq:32b_q4, 에디터로 qwen2.5-coder:32b_q4를 사용했다. 생각했던 것보다 아주 잘 작성했다. 웃긴건 걔가 제대로 작성했는데 내가 틀린 것 같아서 수정을 지시했는데, 업체측에 확인 요청한 결과 내가 지시한 부분이 잘못된 부분이었다. 걔가 원래 작성한 코드가 맞는 코드였다. 업체 측에서 우리가 봐도 되는 부분만 발췌해서 보낸 코드라 빠진 코드가 더러 있었다. 그런 코드는 나머지를 토대로 추론해서 작성하라고 지시를 했는데 그것도 잘 작성했다.

어쨌든 잘 만들 필요는 없지만 재현시키기 위해서는 복잡한 귀찮은 작업이 필요한 그런 작업이었다. 내가 한다고 해도 몇일은 걸릴 것 같은 일이었다. 그런데 정말 딸깍 코딩으로 모든 게 만들어졌다. 내가 일부 수정한 건 경로가 맞지 않아서 포함 경로를 수정하고 포함 파일이 빠진 걸 몇 개 추가한 게 다였다. 물론 이 또한 바이브 코딩을 할 수 있겠지만 그걸 타이핑하는 시간에 코드 고치는 게 훨씬 빠르기에 내가 직접 했다. 결과적으로 그렇게 전체 작업을 하는 데 걸린 시간은 1-2 시간도 채 되지 않았다. 물론 그 마저도 대부분의 시간은 걔가 코딩 하는 걸 대기하는 시간이었다. 왜냐하면 우리 장비는 그리 좋은 장비가 아니라 느리다는 점. 모델 2개를 한번에 메모리에 로딩할 수가 없어서 아키텍트하고 에디팅할 때 항상 모델 교체를 위한 시간이 낭비된다는 점 때문이다. 지시도 몇개 안했지만 대부분 생각보다 너무 잘해서 놀랐다.

#2

모든 코드를 잘 작성할 필요는 없다. 그냥 확인을 위해서 임시로 작성하는 코드도 수도 없이 많다. 그런 코딩은 인공지능에게 시키고 나는 중요한 다른 코드를 쓴다면 동시에 두가지 일을 하는 셈이 되는거니 생산성은 배가 된다. 시스템 프로그래머들에게 한참 전에 파이썬을 써야 한다고 하면 C/C++로도 다 할 수 있다는 핀잔을 듣던 시기가 있었다. 하지만 세월이 지나서 이제는 파이썬이 세상을 지배하고 있다. 인공지능도 머지 않아 그렇게 될 거라 본다. 직접해도 다 할 수 있다. 다만 인공지능을 사용하면 더 빨리 할 수 있다. 그리고 열린 마음으로 함께 한다면 나도 모르고, 인공지능도 모르는 것에 대한 작업도 함께 할 수 있다.

인정하기 싫지만 인공지능이 나보다 코드를 더 잘 읽고, 더 잘 작성한지는 생각보다 제법 오래된 것 같다. 많은 경험을 토대로 느낀 점은 컨텍스트만 제대로 제공하면 거의 상당수 경우에 인간보다 훨씬 나은 결과가 나온다는 것이다. 그러니 이제, 안드레 카파시 말처럼 인공지능을 믿고 바이브에 몸을 맡기자.

덧) 나는 이제 더 이상 커서를 사용하지 않는다. 내가 필요한 기능은 대부분 깃헙 코파일럿에 모두 추가되었고 커서의 크레딧 같은 기능은 코딩을 많이 하는 경우 거의 2주면 다 바닥났기 때문이다. 물론 결제를 더하면 더 늘릴 수 있겠지만 코파일럿이 너무 빨리 따라왔다.

빌게이츠가 돈으로 살 수 없는건 시간 밖에 없다고 다큐에서 그러든데, 운동도 돈으로 살 수 없는 게 아닌가 싶다. 딴 건 다 돈주고 위탁할 수 있지만 운동은 그게 안됨. 해야 하지만 세상 하기 싫은.

2025-02-10

#24

역행인생, 긱이코노미는 부스러기나 나눠 먹는 경제임을 여실히 보여주는 영화. 초반에 개발 팀장이 자신이 만든 알고리즘에 의해 저성과자로 찍혀서 해고되는 장면이 뭔가 짠했다.이어지는 라이더도 알고리즘이 지배하는 세상. 알고리즘은 자비가 없다, 입장과 사정은 알빠노.

영화 보니 전에 만났던 택시 기사님이 생각났다. 현대판 운수 좋은 날 같은 느낌이었는데, 오늘 콜이 한번도 끊기지 않았다고 몹시 신나 하시며 자랑하던게 기억난다. 본인이 뭔가 카카오 알고리즘의 비밀을 알아낸 것 같다며.

2025-02-10

#25

율곡이이가 말했다고 전해지는 인생삼불행. 소년등과, 중년상처, 노년빈곤. 초년에 성공하거나, 중년에 처를 잃고 외롭거나, 나이들어 돈 없으면 고달파지는게 인생. 조선시대나 지금이나 사람은 참 변한게 없는 것 같은 느낌.

2025-02-16

#26

예전에는 자녀가 많으면 든든한 노후대책으로 간주되었지만 현대에는 오히려 빈곤에 빠질 수도 있는 위험신호로 바뀌었다. 자녀가 있다고 하더라도 부모들은 아이를 보육시설에 맡겨야 하는 상황이다.

복지로 인해 출산율이 떨어지고 이혼율이 높아지고, 도움 없이 개인으로 생존 가능하니 사람들이 이기적이 된다는 신박한 생각. 다른 내용은 죄다 뻔한 내용들이었지만 이 부분은 신박했다.

2025-02-26

#38

당신은 센틸리언이 사라고 하는 걸 사고, 센틸리언이 읽으라고 하는 걸 읽고, 센틸리언이 만나야 한다고 하는 사람이랑 데이트를 해요. 그런데 진짜로 행복하긴 해요? - 종이 동물원, 켄 리우

처칠이 이런 말을 했다지요. ‘건물을 만드는 것은 우리이지만, 나중에는 그 건물이 우리를 만든다.’ 우리는 생각하기를 돕는 기계를 만들었지만 이제는 그 기계가 우리를 대신해서 생각을 한다, 이겁니다.

아무도 안 믿을 겁니다. 우리가 그렇게 만들 거니까요. 당신들이 무슨 말을 하든, 무슨 글을 쓰든, 누구 하나 듣지도 보지도 못할 겁니다. 인터넷에서는 센틸리언이 검색하지 못하는 것은 존재하지 않으니까요.

2025-02-26

#39

인생사 새옹지마. 어떤 사건이 실질적으로 좋은지 나쁜지를 알기란 참 어렵다.

2025-02-27

#40

chatgpt 4.5 정말 애매하다. 코딩 말고 글쓰기 등에 대해서 4o랑 비교해 보는데 개선점을 느끼기가 쉽지 않다. 생성 속도는 4o보다 겁나 느림. 아이디어 탐색도 적게 말한다는 거 외에 좋다는 느낌은 별로 없다. 라이브때도 임팩트가 없어 보이더니 실제로도 그런듯.

2025-02-28

#41

미장 나락가네. 서학개미 총출동 중인가, 이와중에 환율 무엇?!

2025-02-28

[cpp] make_unique(n)

Sun, 02 Feb 2025 17:00:01 GMT

make_unique<T[]>(n)에 대해서 배열 초기화를 하지 않는다고 잘못 알고 있었던 사실이 있어서 정리해 본다. make_unique<T[]>(n)은 내부적으로 new T[n]()을 호출하기 때문에 기본 타입에 대해서도 초기화 동작이 발생한다. 그런 이유로 초기화 없는 배열 할당을 위해서 C++ 20에서는 make_unique_for_overwrite가 추가되었다고 한다.

make_unique<T[]>(n) - invokes new T[n](), requesting value-initialization.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3588.htm

C++ 20 에서는 이런 경우 사용하는 함수가 추가되었다
std::unique_ptr<char[]> arr = std::make_unique_for_overwrite<char[]>(size);
https://blog.lunapiece.net/posts/C++-Dyanamic-Size-Buffer-Without-Initialization-And-Memoryleak/

이하 deepseek v3 복음

make_unique<T[]>

C++14 표준에서는 std::make_unique를 사용하여 동적 배열을 생성할 수 있도록 std::make_unique<T[]>를 지원합니다. 이는 std::unique_ptr을 사용하여 배열을 관리할 때 매우 유용합니다.

`std::make_unique<T[]>`의 특징

배열 생성: std::make_unique<T[]>는 T 타입의 동적 배열을 생성하고, 이를 관리하는 std::unique_ptr<T[]>를 반환합니다.
자동 메모리 관리: std::unique_ptr은 소멸 시 자동으로 메모리를 해제하므로, 메모리 누수를 방지할 수 있습니다.
초기화: std::make_unique<T[]>는 배열의 각 요소를 기본값으로 초기화합니다. 예를 들어, int 배열의 경우 모든 요소가 0으로 초기화됩니다.

사용 예제

#include <iostream>
#include <memory>  // std::make_unique를 사용하기 위해 필요

int main() {
    // int 타입의 배열 10개를 동적 할당
    auto arr = std::make_unique<int[]>(10);

    // 배열 초기화 및 출력
    for (int i = 0; i < 10; ++i) {
        arr[i] = i * 2;
        std::cout << arr[i] << " ";
    }

    // std::unique_ptr가 소멸되면 자동으로 메모리가 해제됨
    return 0;
}

주의사항

std::make_unique<T[]>는 배열을 생성할 때만 사용할 수 있습니다. 단일 객체를 생성할 때는 std::make_unique<T>를 사용해야 합니다.
std::unique_ptr<T[]>는 배열을 관리하기 위해 특수화된 형태이므로, operator[]를 사용하여 배열 요소에 접근할 수 있습니다. 단일 객체를 관리하는 std::unique_ptr<T>에서는 operator[]를 사용할 수 없습니다.

요약

std::make_unique<T[]>는 C++14에서 도입된 기능으로, 동적 배열을 생성하고 std::unique_ptr로 관리할 수 있게 해줍니다.
이 기능은 메모리 관리와 안전성을 높이는 데 도움이 되며, 배열의 각 요소를 기본값으로 초기화합니다.

이를 통해 C++에서 더 안전하고 간결하게 동적 배열을 관리할 수 있습니다.

[일상] 2025년 1월의 잡담

Fri, 31 Jan 2025 23:18:47 GMT

#0

나는 마흔세 살이었다. 둘째 아이가 막 태어났다. 그 밖에는 인생에서 내 것이라고 할 만한 게 별로 없었다.

마흔세 살이 되었는데 미래가 어떻게 될지 전혀 모르다니,삶의 어느 시점에 잘못된 기차에 올라타 정신을 차려보니 젊을 때는 예상하지도 원하지도 심지어 알지도 못했던 곳에 와버렸다는 걸 깨닫다니.꿈에서 깨어났는데 그 꿈을 꾼 사람이 자신이 아니었음을 알게 되는 것과 비슷하리라는 생각이 든다

2025-01-18

#9

감정의 골이 얇든 깊든
적당히 신경을 끄고 용서하는 것이
나에게 이롭다.

꽃길이 따로 있나, 내 삶이 꽃인 것을, 오평선

2025-01-19

#10

인생 다양한 고민을 chatgpt한테 물어보곤 하는데 언제나 탁월한 선택과 그 이유를 답해준다. 다만 안타까운건 걔가 알려준걸 내가 따라가지 못할 뿐. 의외로 인공지능이 우리에게 알려준 건 인간은 이성적이기보단 과도하게 감정적이라는게 아닐까 싶다. 그래서 늘 실수는 반복된다.

2025-01-20

#11

요즘 보면 중국은 자유무역, 미국은 보호무역, 인공지능도 중국은 오픈모델, 미국은 독점모델. 둘이 뭔가 바뀐게 아닌가 싶다.

2025-01-23

#12

원인이 chatgpt라는 근거는 빈약하지만, 개발자 입장에서 충분히 공감가는 내용. 솔직히 경력, 실력을 떠나서 코딩만 보면 알파고 순간을 진즉에 넘어섰다는 생각. 그나마 자율 실행과 최종 컨펌이 남았지만 이게 언제까지 지켜줄지는 모를 일이다.

deepseek 어제 버거형들 출근 이후부터 먹통되는 경우가 많다. 추론도 트래픽 감당하려면 충분한 연산 능력이 있어야 하는게 인지상정. 게다가 671b는 생각보다 로컬에서 돌리긴 쉽지 않은 용량. nvda 떡락은 줍줍할 기회였을까? 떨어지는 칼날이었을까?!

2025-01-28

#27

‘나의 것’과 ‘남의 것’ 이 두 가지를 잊을 수 있다면
설령 아무것도 가지지 않아도
행복한 마음으로 지낼 수 있습니다.

초역 부처의 말, 코이케 류노스케

2025-01-29

#28

팩트라면 그렇게 줄기차게 던진 떡밥에 비해서 뭔가 김빠진 릴리즈가 아닌가 싶다. r1 벤치가 2029. 심지어 high가 pro용 릴리즈가 맞다면 본격 급나누기 시작인가 싶기도. https://x.com/haider1/status/1885274715495031087

2025-01-31

[일상] 2024년 12월의 잡담

Thu, 26 Dec 2024 12:02:48 GMT

#0

진짜 살아 돌아온줄. 이런거보면 인간은 그저 유전자를 전달하기위한 생존 기계라는 말이 심하게 와닿는다. https://t.co/O3ACgqOvXh

2024-12-02

#1

대부분의 평범한 부모가 그러하듯, 자식에게는 답답한 상식을 들먹이면서도 뒤로는 신나게 외도를 하거나 종교나 주식, 다단계 같은 것에 미쳐 있는 종류의 사람들이었다. - 대도시의 사랑법, 박상영

“상실하고 나서야 비로소 알게 되는 소중함도 있어. 네가 그래”

집착이 사랑이 아니라면 난 한번도 사랑해본 적이 없다.

언제나 때에 맞춰 블루베리를 사다 놓던 재희. 내가 만났던 모든 남자들의 이름과 얼굴을 기억하는, 내 연애사의 외장하드 재희. 아무 데서나 담배를 피우며, 가당찮은 남자만 골라 만나는 재희.

최근 코드 리뷰를 o1-mini로 돌리고 있는데 나름 만족한다. 당연하지만 나보다 훨씬 일관되게 빠짐없이 지치지도 않고 친절하게 매번 리뷰한다. 심지어 에고 없음.

2024-12-07

#12

민주주의는 다수가 인기 없는 소수를 죽이기로 결정할 수 있는 제도가 아니다. 민주주의는 중앙 권력에 분명한 제한이 있는 제도다. - 넥서스, 유발 하라리

‘민주주의’로 정의하는 기준은 하나뿐이다. 즉 중앙정부가 무제한적인 권한을 갖지 않고 중앙의 실수를 바로잡을 수 있는 견고한 장치를 갖추고 있다는 것이다. 민주주의 네트워크는 모두가 오류를 범할 수 있다고 가정하며, 선거의 승자와 다수에 속하는 유권자들도 그 점에서는 예외가 아니다.

언론인은 인기 정치인이 뇌물을 받았다고 폭로할 수 있으며, 판사는 법정에 유력한 증거가 제출되면 국민 대부분이 이 혐의를 믿고 싶어 하지 않아도 해당 정치인을 감옥에 보낼 수 있다.

또한 권력을 견제하는 자정 장치는 너무 소모적이어서 중앙정부의 힘을 마비시켰다. 특히 세임의 모든 의원에게 주어진 의회 법안에 대한 거부권이 정치적 교착상태를 초래했다. 규모가 크고 다양한 구성원으로 이루어진 정치집단과 약한 중앙정부의 결합은 치명적이었다.

2024-12-08

#13

o1이 분석한 이재명측 최선책.

탄핵 추진을 서두르되, 이재명 본인의 대법원 확정판결 전에 헌재 결정과 조기 대선이 이루어지도록 타이밍을 맞추는 것. 이를 위해 탄핵 표결 과정에서 여당 내 분열을 최대한 활용하고,

헌법재판소 재판관 구성을 야당에 유리하게 정비하며, 재판 과정에서는 최대한 시간을 벌어야 한다. 또한 한동훈 세력과 비공식적 합의를 통해 최소 8표 이상의 이탈표를 확보할 수 있는 뒷거래를 시도하는 것이 유리하다.

여당이 계속 탄핵을 반대할 경우 추가 카드
여론 압박 극대화
여당 내 파열음 확대 유도
대체적 카드 활용(장관 탄핵, 특검, 국정조사)
법적, 제도적 절차 개선 압박
제3세력 및 시민단체 활용

한동훈측 최선책
대통령과의 차별화, 이미지 세탁
탄핵보다는 자진 하야 유도
이재명 법적 리스크 활용
중도·개혁 이미지로 여론 확보
경제·안보 어젠다 선점

한동훈측 선호 하야시점
이재명 대법원 판결 직후
여론 피로 극대화 시점
여당 내부 재정비 가능 시점

양측 모두 최선의 선택을 할 경우, 정국은 장기화되고 극단적 정치 대치 속에서 탄핵과 하야 타이밍, 재판 일정, 여론 지형, 당내 분열을 둘러싼 치열한 신경전이 벌어진다. 결국 승자는 마지막 순간, 어느 쪽이 타이밍을 더 정확히 맞추느냐에 달려 있다.

이재명은 탄핵 성립을 서두르고, 한동훈은 탄핵을 저지·지연하면서 이재명의 법적 리스크가 확정되기를 기다리는 ‘시간과 기회의 게임’이 전개되는 것이다.

2024-12-09

#14

국장. 외국인 투매를 예상했지만, 정작 외국인은 사고 개미가 투매. 자국민이 더 못 믿는 k주식 클라쓰.

2024-12-09

#15

우리나라도 점점 인력 귀해지는게 느껴진다. 채용공고 지원자 없음, 자영업자 영업시간 단축, 사람 들어가는 다른 온갖 일들도 구하기가 예전보다 훨 어려움. 앞으로 사람 엮인 일은 가급적 빨리 탈출하는게 스트레스가 덜할 것 같은 느낌.

2024-12-11

#16

코딩한정 인공지능의 가장 웃긴 점은 없어도 개발 잘한다고 생각되는 사람들은 하나같이 미쳐서 입이 마르게 칭찬하며 사용하는데, 코딩 못하는 사람들은 한결같이 폄하하면서 안쓴다는 사실. 20불 투자해서 월급 받으면 남는 장사일 것 같은데. 왜 안쓰지?

2024-12-11

#17

openai 말처럼 agi는 이미 달성된거 아닌가 싶은?! https://x.com/golbin/status/1867047426617643136

2024-12-12

#18

무례와 혐오와 경쟁과 분열과 비교와 나태와 허무의 달콤함에 길들지 말길, 의미와 무의미의 온갖 폭력을 이겨내고 하루하루를 온전히 경험하길, 그 끝에서 오래 기다리고 있는 낯선 나를 아무 아쉬움 없이 맞이하길 바랍니다. https://maily.so/remem/posts/w6ov8jd9rk5

2024-12-12

#19

생긴게 딱 비전프로, 샤오미 욕할게 아님. 패스트팔로어 원조 맛집 삼전.hbm도 빨리 따라가자. https://n.news.naver.com/article/016/0002401969?cds=news_my

2024-12-13

#20

아무리 공인이라 한들 외모로 뭐라마라하는 세태를 보면 우리 사회가 폭력적이라는 생각이 많이 든다. 비판하고 싶다면 그냥 그 사람이 한 일로만 비판하면 충분하지 않나 싶다. 거기다 굳이 외모까지 끌어와서 비아냥댈 필요가 있나 싶다.

2024-12-16

#21

나는 결국 풍등에 두 글자만을 남겼다.
규호.
그게 내 소원이었다.

<대도시의 사랑법>, 박상영

탐라에 하도 돌아다니길래 봤는데 생각보다 몹시 재밌었다. 글 내용 중에 이렇게 태어나서 라는 말들이 여럿 나와서 미약하게나마 퀴어를 조금은 이해하게 된 것 같다. 나도 테어나보니 왼손잡이. 이 털끝만큼의 차이도 많은 불편과 시선을 가져오는데 그들은 오죽할까 싶다.

2024-12-16

#22

앞으로는 법조항도 유닛테스트 후 테스트 커버리지 100프로 달성하도록 강제해야할듯. 현실이 막장으로 가니 헛점이 너무 많다. 아니면 라이브 테스트 중인지도?!

2024-12-24

#23

맞아요. 위대한 사랑 이야기라고 하는 「타이타닉」도 결국에 만난 지 얼마 안 된 사람을 위해 대신 죽을 정도로 도취되었던 거 아닌가요? 그 둘이 살아남았으면 결국 「레볼루셔너리 로드」처럼 진절머리 나는 결혼 생활을 했을 걸요. - <급류>, 정대건

2024-12-26

[py] del에서 리소스 해제를 하면 안 되는 이유

Tue, 10 Dec 2024 11:35:00 GMT

시작은 mysql 클라이언트였다. 해당 클래스를 사용하는 코드에서 close를 하지 않아서 리소스 릭이 발생하는 문제. pymysql은 왜 이걸 파괴될 때 자동으로 해제하지 않게 만들어서 개발자가 실수하게 만들었지?! 라고 삽질하다 알게 된 이유. 오늘의 교훈: 언어 별로 비슷한 점도 있지만, 다른 점도 많다.

파이썬에서 __init__에서 리소스를 획득하고, __del__에서 리소스를 해제하는 패턴은 피하는 것이 좋습니다. 이유는 다음과 같습니다:

1. `del` 호출 보장이 없음

__del__ 메서드는 객체가 가비지 컬렉션에 의해 삭제될 때 호출되지만, 호출 시점이 보장되지 않습니다.
특히, 프로그램이 종료할 때 전역 객체들의 소멸 순서에 따라 필요한 리소스가 이미 해제된 상태일 수 있습니다.
- 예: 파일 핸들러, 네트워크 연결 등이 이미 닫혀있는 경우 문제가 발생할 수 있음.

2. 순환 참조 문제

객체가 다른 객체와 순환 참조를 형성하면, 파이썬의 가비지 컬렉터가 __del__을 호출하지 않을 수 있습니다.
- 파이썬의 순환 참조를 감지하는 가비지 컬렉터는 __del__이 있는 객체를 처리하기 어렵습니다.
- 결과적으로, 리소스가 영구적으로 해제되지 않을 수 있습니다.

3. 명시적 리소스 관리 부족

리소스 관리가 암묵적으로 이루어져 가독성과 유지보수가 어려워집니다.
- 리소스 사용자가 객체의 수명을 정확히 제어하지 못합니다.
- 누군가 __del__ 호출을 의도적으로 방지하거나 놓치면, 리소스 누수가 발생합니다.

4. GC 타이밍에 의존

가비지 컬렉션은 언제 실행될지 보장되지 않습니다.
- 예를 들어, 리소스를 빨리 해제해야 하는 상황에서 __del__에 의존하면, 리소스가 불필요하게 오래 유지될 수 있습니다.

대안: 컨텍스트 관리자 (`with` 문법) 사용

컨텍스트 관리자를 통해 리소스를 명시적으로 관리하는 것이 더 안전하고 직관적입니다.

class ResourceHandler:
    def __init__(self, resource):
        self.resource = resource

    def __enter__(self):
        # 리소스 획득
        print(f"{self.resource} 획득")
        return self.resource

    def __exit__(self, exc_type, exc_value, traceback):
        # 리소스 해제
        print(f"{self.resource} 해제")
        # 예외 처리도 가능
        if exc_type:
            print(f"예외 발생: {exc_value}")
        return False  # 예외를 억제하지 않음

# 사용 예
with ResourceHandler("파일") as resource:
    print(f"{resource} 사용 중")

요약

__del__ 대신 컨텍스트 관리자나 명시적인 리소스 해제 메서드(close, release 등)를 사용하는 것이 바람직합니다.
이를 통해 리소스 관리가 예측 가능하고, 코드가 더 견고해집니다.

[일상] 2024년 11월의 잡담

Fri, 29 Nov 2024 13:30:06 GMT

#0

c로 코딩해보면 그나마 c++이 천사였구나 싶다.

2024-11-01

#1

나 포함 sns 하는 사람들은 일정 부분 다들 자의식 과잉 상태 아닌가 싶다. 그러니 에고는 좀 내려놓자. 냬러놔도 평균 이상일듯.

2024-11-03

#2

인공지능이 코드 리뷰를 시작했다. 친절하게 예시도 들어서 무슨 문제점이 있는지 착착 알려주었지만 생각보다 쓸모 없다는 결론. 사람이 리뷰를 읽지 않거나 읽어도 이해를 못함. 고쳐도 고친게 아닌 상황. 모든 일이 다 그렇겠지만 코딩도 적성이 있다는 걸 다시 한 번 느낀다.

2024-11-04

대체로 태도가 좋은 사람이 성과도 좋은 경우가 많다. 문제는 둘이 일치하지 않는 경우인데 나는 성과를 중시하는 반면, 보통 사람들은 태도를 더 중요하게 생각하는 것 같은 느낌. 공부를 얼마나 하느냐보다 야간자율학습 시간에 남아있는 걸 더 중시하던 시스템을 보는 것 같기도.

2024-11-12

#13

gpt한테 c++ rest api 라이브러리 추천하라니까 crow를 추천해줌. 코드가 어디서 본거 같아서 찾아보니 예전에 ndc에서 발표됐던 코드가 베이스인듯. 그때 그 슬라이드 흑마법 설명 보고 아 c++의 길은 깊고도 넓구나 했던 기억이. https://github.com/CrowCpp/Crow

난 20년 넘게 c++ 프로그래머로 일했지만 이 코드에 버그가 있다면 솔직히 못 고칠 거 같다. 어짜피 누구나 만들고, 고칠 수 있는 코드에는 한계가 있다. 사람이 만든 거든, 인공지능이 만든 거든 사용하는 사람 인식의 한계를 넘어서면 그저 까만건 글이고 흰건 여백인게 당연한게 아닌가 싶다.

2024-11-12

#14

남대가 없는 이유는 이미 공대가 있어선지도.

2024-11-13

#15

두괄식을 법으로 규정하든가 해야지...

2024-11-15

#16

https://jacob.kim/blog/esop 물타기 신공으로 겨우 익절하고 나왔지만, 나도 50만에 물렸던 주주로써 남 일 같지 않네. 돈 참 잘버는 회사임에도 주가는 ㅠㅜ 레버리지 올인은 이러나 저러나 위험하다.

2024-11-20

#17

mstr의 프리미엄은 기관 투자의 우회 루트가 될 수 있기 때문 아닌가 싶다. 일례로 국민연금은 코인이 없지만 mstr 주식은 가지고 있다. 모든 기관이 개인과 동일하게 코인 접근이 가능해지는 시점이 온다면 차익은 없어지지 않을까? 고로 무위험 차익은 아니라는 생각.

2024-11-21

#18

제법 투지 책도 읽고 요란하게 개별주 골라서 사팔사팔 난리쳐보기도 했지만 단순한 밴스 포폴보다 수익이 좋기가 쉽지 않은게 현실이었다. 심지어는 마이너스인 경우도. 모건 하우절 말처럼 노력과 결과가 일치하지 않는 몇 안되는 분야중 하나가 투자라는 말이 실감남. https://x.com/stocktrainkorea/status/1855502891207082352

2024-11-21

#19

특정 국가가 존재하는지 여부를 물을 때 우리는 상호주관적 현실을 다루고 있는 것이다. 충분한 사람들이 특정 국가가 존재한다는 데 동의한다면 그 국가는 존재하게 된다. - 넥서스, 유발 하라리

물에 빠지면 살기만해도 좋겠다 생각한다. 하지만 물밖으로 나오면 기쁘기도 잠시 보따리가 생각나는게 사람 아닌가 싶다. 물에 빠져서 생사를 넘나들던 그때를 잊지 말자. 보따리는 애초에 내것이 아니었던건지도 모른다. 목숨을 구한 것만해도 천운이다 생각하고 감사하자.

2024-11-29

[일상] 2024년 10월의 잡담

Thu, 31 Oct 2024 20:59:20 GMT

#0

We write unsafe so you don't have to. 이 정도 워딩은 구글 클라스는 되야 할 수 있는 말인듯 ㅋㅋㅋ https://x.com/RustTrending/status/1840744999077781746

2024-10-01

#1

예전엔 ai가 뭔가를 하면 신기해 했다. 이제는 어쩌다 ai가 못하는 걸 내가 하면 묘한 쾌감이 든다. 인간의 마지막 쓸모를 증명하는 느낌이랄까?!

2024-10-01

#2

기다려 봐. 시간은 어짜피 가게 돼 있고, 한 번은 기회가 와. - 백설 공주에게 죽음을 ep01

2024-10-03

#3

Cursor 좋데서 써봤는데. 완전 신세계. 이것이 21세기 개발이지 싶다. 쓰다가 새롭게 알게된건 ai와도 케미가 있다. 디폴트가 클로드인데 쓰다가 묘하게 거슬려서 gpt로 변경함. 구글은 아예 선택조차 안되는 현실.

ai도 뭔가 출신 성분이 있는게 클로드와 지피티는 만든 사람들이 비슷해서 그런지 코딩하는거도 비슷함, 그에반해 제미나이는 약간 결이 다름. 그래서 오히려 두개쓰려면 제미나이를 넣는 게 더 좋다는 생각.

2024-10-04

#4

https://n.news.naver.com/article/052/0002095106?sid=104 안타까운 뉴스다. 그나마 비교적 안전한 나라에 조금은 평화로운 시기에 태어났다는 하나만으로도 감사하며 살아야 하는게 아닌가 싶다. 정말 싸우지 않는 인류란 존재할 수 없는 것인가?!

2024-10-06

#5

[소고] 재미로 보는 개발자 채용 가산점 히스토리 https://jiniya.net/2024/10/tips-for-hiring-developers-for-fun/

2024-10-07

#6

내겐 스위스까지 날아갈 비행기 티켓 값이 없었다. 자신이 원하는 품위 있는 죽음을 맞이하는 데는 많은 돈이 필요했다. 죽음은 모두에게 평등하지만, 죽음에 이르는 과정까지 평등하지는 않았다. - 나보다 어렸던 엄마에게, 정진영

2024-10-07

#7

와 삼전 ㅋㅋㅋ 주식 참 어렵다.

2024-10-08

#8

노벨 물리학상을 힌튼옹께서 받았다뉘. 대ai시대의 서막을 알리는건가. 그나저나 물리학자들은 다소 멘붕일듯. https://n.news.naver.com/article/020/0003591187

2024-10-09

#9

와우. 노벨상 힙하네 ㄷㄷ 개발자만 문제가 아닌듯한. 과학계도 이쯤되면 말들이 많을듯. https://x.com/golbin/status/1843966745322901633

2024-10-09

#10

새 제품 코드를 쓰고 있는데 어림잡아 7할은 gpt가 작성한다. 더 충격적인건 o1을 쓸만한 상황이 별로 없다는 점. 한 번 있었는데 역시나 몹시 우아한 코드를 선물해 주었다. 얼마나 루틴화된 코드만 쓰는지 새삼 실감한다. 웃픈건 끝나면 뒤풀이도 gpt랑 해야할 판. 참여한 휴먼은 나혼자라 ㄷㄷ

2024-10-09

#11

어쩌다 신입을 덜 뽑는 세상이 되었을까? https://jiniya.net/2024/10/hiring-fewer-entry-level-employees/

2024-10-10

#12

https://n.news.naver.com/article/022/0003975584?type=breakingnews&cds=news_my 헐헐헐... 무슨 일이 벌어지고 있는거지. 진심 대박 ㅎㅎ

2024-10-10

#13

https://m.news2day.co.kr/article/20170817091506 s-oil기준 10년에 거의 2배. 연봉도 연에 7프로는 오르는듯한... https://x.com/PropertyDog/status/1844163088737763826

2024-10-10

#14

직원이 굳이 주인의식 가질 필요도 없고, 강요할 필요는 더 없다는 생각. 회사든 직원이든 쌍방 계약대로만 해도 서로 참 잘한 거라는 생각. 그나저나 요즘도 주인의식 운운하는 회사가 있을지?! 있다면 하루빨리 탈출하자.

2024-10-13

#15

그래도 요즘 우리 사회가 많이 좋아졌다고 느끼는게 포괄임금제. 돈 있는 회사는 상당수 비포괄로 전향했고, 없는 회사는 대체로 워라밸이 좋아지는 쪽으로 진화한 것 같다.

2024-10-14

#16

진심 오지라퍼들의 나라. 이젠 좀 바뀌자. https://x.com/_Valentino/status/1846369929580499223

2024-10-16

#17

[일상] 거대 언어 모델 코딩 테스트 https://jiniya.net/2024/10/llm-coding-test

2024-10-16

#18

김영사에서 열일해서 감사하게 한글로 읽고 있는데. 하라리옹 뭔놈에 서론에 일케 힘을줬지. 서론 읽다 숨넘어가는쥴 ㄷ ㄷ ㄷ 이번 책도 재밌으면 킹정하겠지만 묘하게 불길한 예감이. https://x.com/codemaru/status/1837777684153438702

2024-10-17

#19

캡쳐 공고 보다 문득,, 고성능 견고함 유연성 확장성같은 단어는 너무 뒷방 늙은이같은 느낌인걸까?! https://x.com/utilforever/status/1846711699111661915

Writing solid code를 버그 안녕이라고 번역하는 거도 오바지만 solid한 코드 작성하기도 뭔가 이상하지 않나 싶은...

2024-10-17

#20

챗지피티 시대에 연구 일지에 결재 라인 없다고 연구소 승인 취소한다는 미친 소리를 ㅠㅜ 쌍팔년도도 아니고 결재 라인?! 진짜 노답 공뭔들. 연구 안하고 일지 안쓰는데를 잡아야지. 깨알같이 거의 전원 매일 일지 쓰는 회사에 일지에 결재 라인이 없다고 연구소 승인 취소 협박질이라뉘.

2024-10-18

#21

ai 관련 유튜브를 좀 봤는데 생각보다 개념잡고 대충 뭐가되는지 확인하는데는 편리하다. 특히 차로 이동할때 틀어 놓고 듣기 편함. 물론 세부 내용은 추가로 문서 보거나 지피티 이용하는게 빠르긴함. 유튜브로 개발 공부한다고 뭐라할건 아닌듯. 심지어 요즘은 인강세대.

2024-10-21

#22

[ai] Qwen2.5-72b 성능 무엇?! https://jiniya.net/2024/10/qwen2.5-72b/

2024-10-22

#23

비유 참 찰지다. 삼전이 아니더라도 한번 새겨볼만한 이야기. https://x.com/ds1dbx/status/1848861078530494605

2024-10-23

#24

o1-preview보다 코딩 잘한데서 써봤는데 틀린 말은 아닌듯?! o1한테 시킨 마지막 작업을 똑같이 시켰는데 더 깔끔하고 한번에 동작하는 코드 ㄷ ㄷ ㄷ 40초 가까이 생각한 o1이 뻘쭘해졌다. https://x.com/AnthropicAI/status/1848742740420341988

2024-10-23

#25

나만 가려운건 아니었군. 이거 때문에 vscode로 갈아타는 작업을 하고 있는데 아무래도 vs만의 장점도 있기도 해서 쉽진 않은. https://github.com/continuedev/continue/issues/759

2024-10-24

#26

할아버지는 노환으로 돌아가셨는데 평생 술을 드셨다. 병원에 입원하셔서 처음 와인을 드시고는 이렇게 맛있는 술을 왜 이제야 가져왔냐고. 병원에서도 좋아하시면 그냥 드시게 주라는 말. 80중반이 넘어서 돌아가셨는데 할머니가 계셨음 더 오래 건강하셨을거라는게 중론. 건강도 유전자빨이 크다.

멍거옹도 콜라에 대해 기회 비용적 접근을 언급한 적이 있었다. 수명은 줄겠지만 그만큼의 청량감도 무시못한다고. 청량감을 선택하고 일찍 죽을지, 그런 재미를 포기하고 오래 살지는 개인의 결정이 아닐까 싶다. 아이러니하게도 청량감을 택한 멍거옹도 장수한게 아닌가 싶다.

2024-10-29

#27

골아픈 하루. 모든 일이 럭키비키인 원영적 사고로 살고 싶지만 쉽지 않다. 진심 하드웨어와 사람이 함께 엮인 일은 결이 안 맞네.

2024-10-31

[ai] Qwen2.5-72b 성능 무엇?!

Thu, 17 Oct 2024 15:35:00 GMT

막내가 코드를 한 줄 고쳤다. 플래그가 잘못돼서 검사 루틴 체크가 안된다면서 값을 0x100에서 0x50으로 변경했다. 0x50만 보고 난 넘겨 짚었다. 쓸데 없는 걸 또 왜 고쳤지, 라는 생각.

그러다 같이 저녁을 먹게 되서 관련해서 이야기를 듣게 됐다. 자기가 분석해봤는데 기존 코드에 이러저러한 부분 때문에 플래그가 클리어돼서 고쳐야 한다는 것이었다. 다른 주장이 있어서 일단 가서 다시 살펴 보겠다고는 했다. 그러면서도 내 생각은 여전히 세모라고 했다. 0x50은 틀린 건 확실했기 때문이다. 클리어 된다는 걸 내가 체크를 못한 건가 해서 확인을 해야겠다 싶었다.

집에 와서 코드를 보니 막내 말도 맞았다. 하지만 문제는 0x50이었다. 0x10이랑 0x40을 쓰는 플래그랑 겹치는 값인 것이다. 그래서 과연 인공지능은 이 문제를 파악해낼지 궁금해서 테스트를 해보았다. 결과는 Qwen2.5-72b의 압승. 물론 사고력 모델인 o1 시리즈는 차원이 다른 답을 보여주었다. 그들 사이엔 768차원 정도의 간극이 있긴 한듯.

프롬프트

XXX 플래그 검사하는 로직으로 살펴봤을 때 아래 코드에서 EEE_INDEX를 MAKELONG(0x50, 3)로 변경하는게 문제 없는지 판단해줘

AAA_INDEX = MAKELONG(0x10, 3),
BBB_INDEX = MAKELONG(0x20, 3),
CCC_INDEX = MAKELONG(0x40, 3),
DDD_INDEX = MAKELONG(0x80, 3),
EEE_INDEX = MAKELONG(0x100, 3),

... 관련 코드 ...

4o-mini

얘는 일단 말귀 자체를 못 알아 먹는다. 0x100을 0x50으로 변경하는 걸 검토하라는데 엉뚱한 소리를 함.

EEE_INDEX를 MAKELONG(0x100, 3)으로 변경하는 것이 문제가 없는지 판단하기 위해 몇 가지 요소를 고려해야 합니다.

1. 상수 중복 여부

EEE_INDEX가 MAKELONG(0x100, 3)으로 설정될 경우, 다른 인덱스 값과의 중복 여부를 확인해야 합니다. 주어진 코드에서 다른 인덱스 > 값들은 다음과 같습니다:

AAA_INDEX = MAKELONG(0x10, 3)

BBB_INDEX = MAKELONG(0x20, 3)

CCC_INDEX = MAKELONG(0x40, 3)

DDD_INDEX = MAKELONG(0x80, 3)

MAKELONG(0x100, 3)는 이들과 중복되지 않으며, 기존의 값들과 겹치지 않기 때문에 문제는 없습니다.

2. 논리적 의미

EEE_INDEX의 의미를 파악하는 것이 중요합니다. ...

3. 사용된 위치

코드에서 EEE_INDEX가 어떻게 사용되는지를 검토해야 합니다. Do 메서드와 같은 곳에서 해당 플래그가 어떤 동작을 유발하는지 > 이해해야 합니다. 만약 EEE_INDEX가 GetFileEx 또는 TestFlag와 같은 중요한 검사와 연관되어 있다면, 변경으로 인해 예상치 못한 동작이 발생할 수 있습니다.

결론

위의 분석을 바탕으로, EEE_INDEX를 MAKELONG(0x100, 3)로 변경하는 것이 중복이나 충돌 없이 문제가 없을 것으로 보입니다. 그러나 해당 플래그가 어떤 의미를 지니고 있는지, 그리고 그 사용 위치를 검토하여 최종 판단을 내리는 것이 좋습니다. 특히, 기존의 로직이 이 값을 기반으로 동작하고 있다면, 변경이 다른 동작에 영향을 미칠 수 있으므로 신중해야 합니다.

4o

얘는 말귀는 알아 먹었고 전개도 나쁘진 않았지만 결국 장황하게 설명하며 핵심을 피해가고 있다. 아는 거 같기도 하고 모르는 거 같기도 하고 뭔가 모르지만 아는 척 하는 거 같기도 한 아주 두루뭉실 애매한 답변.

주어진 코드에서는 다양한 이벤트 또는 조건 플래그를 설정하기 위해 MAKELONG 매크로를 사용합니다. MAKELONG는 두 개의 16비트 값을 받아 하나의 32비트 값을 생성하는 매크로로, 여기서는 인덱스를 생성하는 데 사용되고 있습니다.

EEE_INDEX를 MAKELONG(0x100, 3)에서 MAKELONG(0x50, 3)으로 변경하려는 제안에 대해 검사해 보도록 하겠습니다.

MAKELONG의 구조: MAKELONG(a, b) 구조에서 a는 하위 16비트 값을, b는 상위 16비트 값을 나타냅니다. 즉, MAKELONG(0x100, 3)은 0x00030064이라는 32비트 수를 생성하며, 이는 플래그 배열의 3번째 부분(HIWORD)에 0x100 비트를 설정하고자 할 때 사용됩니다.

변경 시나리오:

MAKELONG(0x50, 3)은 0x00030050이라는 값을 생성하게 됩니다. 이는 플래그 배열의 동일한 3번째 부분(HIWORD)에서 0x50 비트를 설정합니다.
이 변경은 bit 부분만을 변경하므로, 인덱스의 비트 위치가 달라지게 되어 플래그가 검사될 때 다른 조건으로 해석될 수 있습니다.

문제점:

기존에 정의된 다른 플래그와의 중복이나, 애플리케이션의 로직 흐름에서 이 플래그의 역할이 달라질 가능성을 고려해야 합니다.
다른 부분의 코드(예: TestFlag 및 파일 처리 로직)에서 이 플래그의 새로운 상태를 관리하는 방법이 제대로 처리되는지 확인해야 합니다.

리스크 평가:

만약 다른 플래그들과의 중복이 없다면, 변경은 문제를 일으키지 않지만, 코드 베이스 전체를 고려했을 때 이 변경이 코드의 다른 부분과 호환되는지 충분히 검토해야 합니다.
결론적으로, EEE_INDEX 값을 0x50으로 변경하는 것은 인덱스 값의 비트 위치를 변경하는 것이므로, 이런 변경이 시스템 내 다른 곳에 영향을 미치지 않는지를 충분히 검토한 후에 수행해야 합니다. 구체적으로는 기존 로직에서 어떻게 이 플래그를 사용하는지 전반적인 코드 흐름에 대한 검토가 있을 때 비로소 안전하다고 판단할 수 있습니다.

참고 문서
C++ MAKELONG 매크로 사용법
비트 연산을 통한 플래그 관리 방법
코드 내 TestFlag와 유사 함수의 플래그 처리를 위한 예제 코드

Qwen2.5-72b

놀랐다. 문제점을 정확하게 찾았다. 기존 플래그과 중첩된다는 걸 체크한다. 하지만 실수도 나랑 똑같았다.

새로운 플래그를 추가할 때는 이미 사용 중인 플래그와 충돌하지 않는 값으로 설정해야 합니다. 예를 들어, MAKELONG(0x200, 3)과 같은 값으로 변경하는 것이 안전할 것입니다.

이 부분이 옥의 티. 나도 별 생각 없이 예전에 만든 코드라 0x100을 추가했는데 한바이트라 비트를 8개 밖에 쓰지를 못한다. 그래서 제대로 수정하려면 MAKELONG(1, 4)가 돼야 한다. 그럼에도 얘는 정확하게 막내의 수정 사항의 문제점을 찾아냈다는데 대해서는 몹시 칭찬한다. 알리바바가 외계인을 갈아 넣고 있는 건 정말 진실인지도?!

양자화가 모델에 미치는 영향을 살펴보기 위해서 추가로 테스트를 더 돌려 보았는데 문제 답을 맞추기 위해서는 8비트 이상이 필요했다. 8비트 아래로 내려가면 4o와 비슷한 수준의 답변만 내놓는다.

주어진 코드에서 EEE_INDEX를 MAKELONG(0x100, 3)에서 MAKELONG(0x50, 3)으로 변경하는 것이 문제 없는지 판단하기 위해서는 몇 가지 점을 고려해야 합니다.

비트 충돌: MAKELONG(0x50, 3)은 0x50을 3번 째 부분에 설정하는 것을 의미합니다. 이 값이 이미 사용 중인 다른 플래그와 충돌하지 않는지 확인해야 합니다. 현재 코드에서 이미 사용 중인 플래그들은 다음과 같습니다:

AAA_INDEX = MAKELONG(0x10, 3)
BBB_INDEX = MAKELONG(0x20, 3)
CCC_INDEX = MAKELONG(0x40, 3)
DDD_INDEX = MAKELONG(0x80, 3)
0x50은 0x40과 0x10의 조합으로, CCC_INDEX와 AAA_INDEX와 충돌할 수 있습니다. 따라서 EEE_INDEX를 MAKELONG(0x50, 3)으로 변경하면 이 두 플래그와의 충돌이 발생할 수 있습니다.

플래그 관리: 플래그는 비트 마스크로 관리되므로, 각 플래그가 독립적으로 설정되고 해제될 수 있어야 합니다. 0x50은 0x40과 0x10의 조합이므로, EEE_INDEX를 설정하거나 해제할 때 AAA_INDEX와 CCC_INDEX도 함께 영향을 받게 됩니다. 이는 원하지 않는 동작을 초래할 수 있습니다.

코드의 안정성: 플래그 값이 충돌하면 코드의 안정성과 예측 가능성이 떨어집니다. 따라서 새로운 플래그를 추가할 때는 이미 사용 중인 플래그와의 충돌을 피하는 것이 중요합니다.

결론
EEE_INDEX를 MAKELONG(0x50, 3)으로 변경하는 것은 이미 사용 중인 AAA_INDEX와 CCC_INDEX와의 충돌을 일으킬 수 있으므로, 이 변경은 권장되지 않습니다. 대신, 새로운 플래그를 추가할 때는 이미 사용 중인 플래그와 충돌하지 않는 값으로 설정해야 합니다. 예를 들어, MAKELONG(0x200, 3)과 같은 값으로 변경하는 것이 안전할 것입니다.

참고 문서
주어진 코드 스니펫
비트 마스크와 플래그 관리에 대한 일반적인 지식

o1-mini

사고력은 역시 미니라도 o1인가. o1-preview 는 굳이 등판할 이유조차 없는 답변. 한수 위가 뭔지 철저하게 보여준다. 참고로 5초 생각했다 ㅋㅋㅋ~

변수 EEE_INDEX를 MAKELONG(0x100, 3)에서 MAKELONG(0x50, 3)으로 변경하려는 의도는 이해됩니다. 그러나 이 변경이 문제를 일으킬 가능성이 높습니다. 아래에서 그 이유를 상세히 설명드리겠습니다.

현재 플래그 정의

현재 플래그는 다음과 같이 정의되어 있습니다:
AAA_INDEX = MAKELONG(0x10, 3),
BBB_INDEX = MAKELONG(0x20, 3),
CCC_INDEX = MAKELONG(0x40, 3),
DDD_INDEX = MAKELONG(0x80, 3),
EEE_INDEX = MAKELONG(0x100, 3),
MAKELONG의 동작

MAKELONG 매크로는 두 개의 16비트 값을 받아 32비트 값을 생성합니다. 여기서 첫 번째 인자는 LOWORD, 두 번째 인자는 HIWORD로 설정됩니다. 예를 들어:

MAKELONG(0x10, 3)은 HIWORD = 3, LOWORD = 0x10이 됩니다.

MAKELONG(0x100, 3)을 MAKELONG(0x50, 3)으로 변경하면 LOWORD가 0x50으로 변경됩니다.

변경 시 발생할 수 있는 문제

비트 중복:

0x50은 16진수로 0101 0000 (2진수)입니다.

이는 0x10 (0001 0000)과 0x40 (0100 0000)의 비트가 모두 설정된 상태입니다.

현재 다른 플래그들이 0x10과 0x40을 개별적으로 사용하고 있기 때문에, 0x50으로 설정하면 두 플래그가 동시에 활성화된 것으로 인식될 수 있습니다.

플래그 충돌:

EEE_INDEX를 0x50으로 변경하면, 다른 플래그들과 비트가 겹치게 되어 의도치 않게 여러 플래그가 동시에 활성화되거나 해제될 수 있습니다.

이는 플래그 검사 로직에서 혼란을 초래할 수 있으며, 예상치 못한 동작을 유발할 수 있습니다.

플래그 관리의 복잡성 증가:

단일 비트 플래그를 복합 비트로 변경하면, 플래그를 설정하거나 해제할 때 복잡성이 증가합니다.

예를 들어, 0x50을 설정할 때 0x10과 0x40을 모두 설정해야 하며, 이를 해제할 때도 동일하게 처리해야 합니다.

권장 사항

고유한 비트 사용: 각 플래그는 고유한 비트를 사용하는 것이 좋습니다. 이는 플래그 간의 충돌을 방지하고, 플래그 관리의 명확성을 유지하는 데 도움이 됩니다.

예를 들어, EEE_INDEX를 0x200 (MAKELONG(0x200, 3))과 같이 고유한 비트를 할당하는 것을 고려해보세요.

플래그 정의 재검토: 만약 0x50을 사용해야 하는 특별한 이유가 있다면, 해당 플래그가 기존 플래그들과 어떻게 상호작용하는지, 그리고 이를 처리하기 위한 추가 로직이 필요한지 신중하게 검토해야 합니다.

코드 리뷰 및 테스트: 변경 사항을 적용하기 전에 코드 전체에 걸쳐 플래그가 어떻게 사용되고 있는지 철저히 리뷰하고, 충분한 테스트를 통해 예상치 못한 부작용이 없는지 확인해야 합니다.

결론

EEE_INDEX를 MAKELONG(0x50, 3)으로 변경하는 것은 현재 플래그 정의와 사용 방식을 고려할 때 권장되지 않습니다. 이는 플래그 간의 비트 충돌을 유발하여 시스템 동작에 예기치 않은 문제를 초래할 수 있습니다. 고유한 비트를 유지하는 방향으로 변경을 고려하시기 바랍니다.

추가적인 질문이나 코드 관련 상세한 검토가 필요하시다면 언제든지 문의해주세요!

총평

기존 챗본 경쟁에서 OpenAI의 해자는 점점 없어지는 것으로 보여진다. o1 모델이 나오지 않았다면 정말 참담하지 않았을까 싶다. o1 모델이 있긴 하지만 앞으로도 경쟁 우위를 유지하기란 쉽지 않을 것 같다는 생각. 최근 mmlu-pro 리더보드에 grok2가 4o 위에 0.7546으로 등재됐다. 물론 셀프 리포팅이긴 하지만 구라는 아닐 거 같다는 느낌. 이런걸 보면 System 1 사고를 한다는 앵무새 챗봇 경쟁은 gpu 살만한 돈들이 있는 회사들은 대부분 상향 평준화가 된 게 아닌가 싶다.

알리바바에 거액을 날려 먹었지만 공산당만 아니면 다시 투자할 의향이 생기는 QWen2.5 72b였다. 그럼에도 진정 이바닥 위너는 nvidia인가?!

[ai] 거대 언어 모델 코딩 테스트

Wed, 16 Oct 2024 15:35:00 GMT

LLM이 코딩을 잘한다는 것은 이제 삼척동자도 아는 사실이다. 하지만 일반적으로는 함수 단위 또는 조금 넘어서 코드 블록 정도를 작성하는 수준으로 생각한다. 최근 회사에서 로컬 LLM을 테스트하면서 매뉴얼을 통째로 입력했을 때, LLM이 이를 토대로 적용 코드를 작성할 수 있을지 궁금했다. 이런 생각을 하게 된 것도 모델의 답변 퀄리티가 예상보다 훨씬 뛰어났기 때문이다. 그래서 여러 모델을 벤치마크해 보았다.

매뉴얼은 총 80KB 분량의 adoc 텍스트 문서로, 클라이언트와 서버 매뉴얼이 합쳐져 있으며, 각종 언어에 대한 통신 프로토콜, SDK 초기화 및 종료 절차, 데이터 전송 방법 등의 설명이 상세히 기술되어 있다. 이러한 내용은 클라이언트/서버 프로그램 개발에 필수적인 정보를 제공한다. 80KB는 감이 잘 오지 않을 수 있는데, PDF로 환산하면 약 133페이지 분량이다. 해당 파일을 단순히 통째로 읽어 모든 데이터를 전달했다. 프롬프트는 다음과 같다. 출력 토큰은 8K로 설정했으며, claude-3-haiku만 8K를 지원하지 않아 4K로 테스트했다. 이 차이는 각 모델이 처리할 수 있는 데이터의 양과 응답 길이에 영향을 미쳐, 결과의 품질과 완성도에 차이를 만들 수 있다.

시스템

다음 첨부된 자료를 참고하여 사용자 질의에 답변합니다.

... 매뉴얼 89KB 텍스트 첨부 ...

사용자 질의

xigncode3가 적용된 C++ 클라이언트/서버 프로그램을 작성해 주세요. 클라이언트와 서버 프로그램은 TCP/IP를 통해 통신하는 구조로 만들어 주세요.

매뉴얼이나 세부 결과물은 회사 내부 자료가 포함되어 있어 공개하기는 어렵지만, 간략하게 평가한 내용은 다음과 같다. 참고로 이 업무는 회사에서 개발자가 들어오면 대체로 거치는 통과의례 같은 과정이며, 빠르면 1주일, 늦으면 2달까지도 걸리는 작업이다.

qwen2.5-14b-int4-128k

클라이언트 통신 코드를 작성 안함, 서버 통신 코드 작성 안함, 데이터 전송 코드 작성 안함.

클라이언트에 SDK 초기화 코드를 구현했으나, 함수 하나는 잘못 호출했다. 클라이언트 SDK 종료 코드를 구현했다. 클라이언트에 SDK 통신 코드를 적용하지 않았다.

서버 SDK 초기화 코드에 호출한 함수 4개가 모두 잘못되었다. 서버 SDK 종료 코드에 호출한 함수 1개가 잘못되었다. 서버 SDK 통신 코드를 적용하지 않았다.

클라이언트 프로그램 설명이 중구난방이다. 서버 프로그램 설명이 중구난방이다.

qwen2.5-32b-int4-128k

클라이언트 통신 코드를 작성했다. 서버 통신 코드를 작성했다. 클라이언트/서버 데이터 전송 코드를 작성하지 않았다.

클라이언트 SDK 초기화 코드를 작성했으나 잘못 작성했다. 서버 함수를 사용했다. 클라이언트 SDK 종료 코드를 작성했으나 잘못 작성했다. 클라이언트 통신 코드를 작성했으나 잘못 작성했다. 다른 언어 매뉴얼 함수를 잘못 사용했다.

서버 SDK 초기화 코드를 일부 정상 구현했다. 서버 SDK 종료 코드를 정상 구현했다. 서버 SDK 통신 코드를 정상 구현했다. 일부 다른 언어의 함수를 잘못 사용했다.

설명이 제법 정제되었다.

4o-mini

클라이언트 통신 코드 작성, 서버 통신 코드 작성, 데이터 전송 코드 작성했지만 일부 잘못됨.

서버 SDK 초기화, 종료 코드 작성. 데이터 전송 코드는 작성하지 않음.

클라이언트 SDK 초기화, 종료 코드 작성. 데이터 전송 코드는 작성하지 않음.

설명이 간결함.

claude-3-haiku

전체적으로 결과가 의외로 신선하게 나왔다. 프로젝트 구조부터 각 파일을 구현하는 방식으로 전개됨. 다른 모든 모델은 단순히 서버 소스, 클라이언트 소스 같은 구조였음. 하지만 실질적으로 결과물은 그냥 그럴듯한 잡썰이라 평가에서 논외로. 전개는 몹시 설레였지만... 실제 코드는 망 ㅠㅜ

알겠습니다. XIGNCODE3를 적용한 C++ 기반 클라이언트/서버 프로그램 작성 방법을 안내해 드리겠습니다. 클라이언트와 서버가 TCP/IP를 통해 통신하는 구조로 구현하도록 하겠습니다.

먼저, 프로젝트 구조는 다음과 같습니다:
- Project
    - Client
        - main.cpp
        - XigncodeClient.h
        - XigncodeClient.cpp
    - Server
        - main.cpp
        - XigncodeServer.h
        - XigncodeServer.cpp
    - Common
        - Util.h
        - Util.cpp
Common 폴더에는 클라이언트와 서버에서 공통으로 사용하는 유틸리티 함수들이 들어있습니다.

이제 각 파일의 구현 방법을 설명드리겠습니다.

== 클라이언트 구현

=== XigncodeClient.h

qwen2.5-72b-int4-128k

여기서부터가 조금 놀라웠다. 클라이언트 통신 코드 작성, 서버 통신 코드 작성, 데이터 전송 코드 작성.

클라이언트 SDK 초기화, 종료 코드 작성. 데이터 전송 코드 작성.

서버 SDK 초기화, 종료 코드 작성, 데이터 전송 코드 작성.

설명이 약간 장황함.

gpt-4o

클라이언트 통신 코드 작성, 서버 통신 코드 작성, 데이터 전송 코드 작성.

클라이언트 SDK 초기화, 종료 코드 작성, 데이터 전송 코드 작성.

서버 SDK 초기화, 종료 코드 작성, 데이터 전송 코드 작성.

설명이 간결함.

claude-3.5-sonnet

클라이언트 통신 코드 작성, 서버 통신 코드 작성, 데이터 전송 코드 작성.

클라이언트 SDK 초기화, 종료 코드 작성, 데이터 전송 코드 작성.

서버 SDK 초기화, 종료 코드 작성, 데이터 전송 코드 작성.

설명이 간결하나 GPT보다는 보충됨.

llama3.2-90b

번외로 해봤다. 일단 한글 문서에 한글 프롬프트임에도 대차게 영어로 대답하는 기개를 보여주었다. 한글을 못해서 그런지 내용은 매뉴얼이 하나도 반영되어 있지 않았다.

너무 안타까운 마음에 영문 프롬프트에 영문 매뉴얼로 우대해줘서 다시 돌려봤다. 하지만 안타깝게도 결과는 별 차이가 없었다. 서버 쪽 구현이 조금 추가된 정도. 너무나 너무나 안타까운 마음에 다른 언어랑 헷갈리지 않도록 C++ 문서만 두개를 전달했다. 그랬더니 이제는 클라이언트 구현도 조금 추가했지만 여전히 4o-mini보다도 못한. 알파고 따라 만든 바둑때부터 느꼈지만 뭔가 90b 치고는 참 어이없는 결과가 아닐 수 없겠다.

총평

qwen2.5-72b, gpt-4o, claude-3.5-sonnet 모두 납득할 만한 결과를 보여줬고, 나머지는 아직 실제 사용하기에는 부족한 느낌이다. 그런데도 더 놀라운 사실은 qwen2.5-72b, gpt-4o, claude-3.5-sonnet 중 우열을 가린다면 qwen2.5-72b에 손을 들어주고 싶다. 왜냐하면 평가표에는 언급되지 않았지만, 클라이언트/서버 SDK의 다른 주요 기능들이 하나씩 더 있었는데 아무도 그것을 구현하지 않았는데, 72b는 혼자 그것을 모두 다 구현했기 때문이다. 알리바바가 외계인을 갈아넣고 있거나 아니면 중국이니까 자료를 그냥 맘껏 사용하거나 둘중하나인듯한. 어쨌든 멋진 신세계가 아닐 수 없다.

[소고] 어쩌다 신입을 덜 뽑는 세상이 되었을까?

Wed, 09 Oct 2024 15:35:00 GMT

#0

세상은 참 신기한 게, 영원한 건 없다는 점이다. 개발자 채용 광풍이 불어닥쳤던 코로나 시국이 지나자 혹한기가 찾아왔다. 비대면 시대가 저물면서 IT 서비스 회사들의 매출이 급감한 이유도 있지만, 인공지능의 등장도 큰 영향을 미쳤다고 생각한다.

이런 경향과 무관하게 최근 몇 년간 또 다른 주된 트렌드는 신입 채용이 급격하게 줄어들고 있다는 점이다. 당연한 이야기지만, 소위 '네카라쿠배'로 불리는 좋은 회사일수록 이러한 경향이 더 두드러진다. 심지어 그런 회사에서 뽑는 신입은 면면을 잘 살펴보면 실제로는 경력이 있는 중고 신입을 원하는 경우도 많다. 어쩌다 이런 세상이 되었을까?

#1

우리나라 채용 문화의 급격한 변화 지점으로 IMF 외환위기를 많이들 거론한다. 그전의 사회는 평생 직장이 있었고, 연공서열이 존재했다고 한다. 즉, 직원은 회사에 한 번 충성하면 회사는 그 직원을 어쨌든 평생 책임지는 구조였던 것이다. 물론 나는 그때 사회생활을 하지 않았기 때문에 실제로 그랬는지는 모른다.

이런 문화는 90년대 후반 외환위기를 겪으면서 모든 것이 달라졌다. 평생 직장은 사라지고, 연공서열 자리에는 연봉이란 시스템이 도입됐다. 회사가 직원의 평생을 책임지지 않는 세상이 시작된 것이다.

#2

다른 직원이 버려지는 것을 본 생존자는 어떤 생각을 할까? '아, 나는 더 열심히 해서 충성을 바쳐 높은 성과를 내서 생존해야겠다'고 생각할까? 그건 다소 순진한 생각이다.

안정적인 직장을 추구하고 최소한의 성과만 내는 소위 '공무원 문화'가 퍼지기 시작한다. 일은 최소한도로 하며 워라밸을 지키고, N잡을 뛰거나 투자를 하는 식으로 회사에 목을 매지 않는 세상이 온 것이다. 어차피 언제든 버려질 수 있다면, 나도 여기에 최선을 다하지 않겠다는 선언인 셈이다.

전체보다 부분을 본다면 이는 합리적인 선택인지도 모른다.

#3

이렇게 직원들이 한 회사에 최선을 다하지 않는 것을 본 회사의 다음 선택은 무엇일까? 바로 직원에 대한 투자를 더 줄이는 것이다. 교육이나 복지 같은 장기적 투자를 줄이고, 당장 생산성을 낼 수 있는 인력을 선호하게 된다. 키워서 오래 함께 가겠다는 생각보다는 당장 일을 할 수 있는 직원을 선호하는 것이다. 언제든 다른 곳으로 갈 수 있는 직원에게 투자하는 것은 다음 회사에게만 좋은 일을 시켜주는 셈이니 말이다.

#4

결국 이 모든 문제는 회사와 직원 간의 신뢰가 사라진 것에서 출발한다. IMF 외환위기 이후 평생 직장 개념이 사라지고, 회사가 직원을 보호하지 않게 되면서 이러한 신뢰가 무너지기 시작했다. 직원은 회사가 언제든 자신을 버릴 수 있다고 생각하고, 회사는 직원이 언제든 떠날 수 있다고 생각한다. 가장 좋은 합은 회사도 직원을 믿고, 직원도 회사를 믿으며 장기적으로 상생하는 구조지만, 현실에서는 쉽지 않다.

이 문제는 잘 생각해보면 죄수의 딜레마와 닮았다. 게임 이론에 따르면 안타깝게도 죄수의 딜레마에서 내쉬 균형은 서로가 배신하는 선택을 통해 이루어진다. 겉으로는 세상이 비합리적으로 보일지라도, 사실은 매우 합리적이라는 뜻이다. 그러니 직원이 워라밸을 중시하며 다른 기회를 찾는 것이나, 회사가 신입을 채용하지 않고 기존 직원에게 덜 투자하는 것 모두 너무 아쉬워 하지는 말자.

[소고] 재미로 보는 개발자 채용 가산점 히스토리

Mon, 07 Oct 2024 05:35:00 GMT

세월따라 변하는 개발 트렌드

2007년부터 개발자 채용을 시작했다. 햇수로 제법 오래되었지만 영세한 중소업체에서 채용을 진행하다보니 대단한 건수를 가진 건 아니다. 그럼에도 지난 시간동안 작은 회사치고는 제법 훌륭한 개발자들을 잘 채용했다고 자부한다. 그러니 회사가 망하진 않고 아직까지 유지되는 거겠지?!

개발자를 채용함에 있어서 정말 많은 요소들을 볼 수 있겠지만 의외로 엉뚱한 질문 한두가지로도 그 사람을 어느 정도는 판단할 수 있다. 지난 시간동안 복잡한 면접 문제보다 오히려 더 좋은 성능의 필터인 경우가 많았던 것들을 소개해 본다.

Pre-AI

뉴스그룹

뉴스그룹을 알거나 거기서 활동한다는 사실만으로도 가산점을 주던 시기가 있었다. 정보와 소스는 귀했고, 그나마 몇 안되는 정상적인 프로그래밍 관련 토론이 벌어지던 곳이 뉴스그룹이었다.

요즘은 그게 유튜브로 변한듯하다. 얼마전 개발자를 뽑는데 조코딩으로 배웠다고 해서 내중에 그게 뭔지 알고는 실소를 했다는 이야기를 들었다. 조코딩은 유명한 개발 유튜브 채널이다. 세월따라 배우는 채널도 변하기 마련이다.

명서

감명 깊게 읽은 책에 명서가 있다고 해서 그게 꼭 좋은 프로그래머임을 반증하지는 않는다. 하지만 적어도 멍청한 개발자는 아니라는 사실은 어느 정도 판단해준다 믿는다. 최소한 어느 정도 취향은 비슷하다는 걸로도 해석할수도 있겠다. 어쨌든 아래 책이 그 목록에 있다면 가산점을 주었다.

Windows Internals, Windows via C/C++, Art Of Unix Programming, Programming Pearls, 실용주의 프로그래머, 조엘온소프트웨어, 코딩 호러의 이펙티브 프로그래밍

누가 내 치즈를 옮겼을까를 선택한 개발자에겐 미안한 이야기지만 선호하지 않았다. 내가 그걸 물어보던 시기에 인터넷에 감명깊게 읽은 책 물어보면 단골로 나오던 책이었다. 요즘으로 치면 세이노의 가르침정도 되겠다. 재미난 사실은 내가 30대때는 지금만큼 세이노가 유명하지 않았지만 그때 난 광팬이었다. 그러나 지금은 생각하는 게 많이 다르다. 세월따라 생각하는 것도 변하게 마련이다.

svn

믿기지 않겠지만 그 시절 업계에서 버전 관리 시스템을 사용하던 곳은 드물었다. 소스 코드는 말 그대로 개발자 각자가 알아서 관리하던 비법같은 존재였다. 나는 꾸준히 일하던 회사에 svn을 도입하자는 말을 했지만 말단 신입이라 쉽지 않았다. 더 엄청난 사실은 심지어 바이너리도 개발자가 시스템에서 직접 빌드한 것을 사용했다.

CTO가 되고 나서 처음으로 사내에 버전관리 시스템을 도입할 수 있었다. 그전에는 혼자 썼다. C자가 붙으면 이런 게 좋다.

구글

난 대학시절부터 구글을 썼지만 아직 국내 검색 엔진 시장은 네이버가 평정하던 시기였다. 개발자 채용에도 구글이 뭔지 아예 모르는 사람이 많았다. 개발 관련 이슈에 검색엔진을 뭘 사용하는지 물어서 구글을 사용하다면 좋은 신호였다.

블로그

개인 블로그를 가지고 있고, 내용이 의미있는 경우에는 가산점을 주었다. 개인 블로그가 의미 있다는 사실은 두가지를 어느 정도는 증명한다고 본다.

긴 글을 이해할 수 있는 형태로 쓸 수 있는 능력을 가지고 있다.
적어도 적혀진 내용에 대해서는 고민하는 시간을 가졌다.

요즘은 포트폴리오 차원에서 블로그를 하는 경우가 많아졌다. 하지만 여전히 의미있는 내용이 담겨있는 블로그는 드물다. 아주 드문 경우긴 하지만 블로그 내용을 보고 역으로 채용을 제안한 경우도 몇 있었다.

조엘테스트

이걸 알기만해도 코딩이 아닌 제품 개발에 있어서 실질적으로 중요한 부분이 무엇인지 어느 정도는 알고 있다고 생각한다. 놀라운 사실은 여전히 유효하다는 점이다.

스택오버플로

시간이 흘러 뉴스그룹은 스택오버플로로 바뀌었다. 지금은 그냥 검색해도 나오는게 죄다 스택오버플로인 세상이 되었지만 그 시기만해도 모르던 사람이 더 많았다.

git

이제 업계 전반에 버전 관리 시스템은 필수인 세상이 되었다. 하지만 여전히 빌드 시스템은 없는 회사가 많기도 했다. git은 출시가 되었지만 이 시기에 대세는 여전히 svn이었다. 지인들 중에도 git의 장점이 뭔지 도통 모르겠다고 얘기하는 사람들이 많았다.

git을 알기만 해도 가산점을 주었다. 나는 여전히 CTO였지만 svn에서 git으로 가는 과정은 쉽지 않았다. 사내 개발자들은 왜 잘 쓰고 있는 걸 옮기냐고 뭐라 했다. 나는 휴가지 노트북에서도 버전 관리를 계속할 수 있다는 이야기를 했지만?! 당연한 소리겠지만 설득은 1도 안됐다. 그래서 그냥 권력을 이용해서 강제로 변경했다.

이제는 git을 안쓰는 경우가 더 드물것 같다. git과 github은 개발 문화를 정말 많이 변화시켰다고 본다.

파이썬

주로 채용하는 포지션이 C/C++개발자라 파이썬을 사용할 줄 아는 경우 가산점을 주었다. 사내 개발자들에게도 파이썬을 배우면 좋다는 이야기를 많이 했지만 쉽진 않았다.

대체로 그 시절 C/C++ 개발자들은 이건 C/C++로도 다 만들 수 있다는 이야기를 많이했다. 내가 파이썬으로 만드는 게 더 개발 속도가 빠르다고 했지만 당연히 별 의미 없는 소리였다.

2024년이 된 지금, 결국 파이썬이 씹어먹는 세상이 되었다.

슬랙

업무용 메신저란 개념이 아직 드문 시기였다. 우리 회사도 네이트온을 쓰다가 슬랙으로 옮겼던 시기였다. 이것 또한 도입 진통이 없지는 않았다. 하지만 왜 바꾸냐는 말과는 달리 도입 후 사람들은 모두 채널 중독자가 되었다.

대단한 건 아니지만 슬랙을 안다는 것 만으로도 가산점을 주었다. 요즘은 대학 동아리도 죄다 슬랙을 쓰는 세상이다.

Post-AI

여기까지가 지금까지의 이야기다. 내가 다음 개발자를 채용한다면 이제는 이런 것들에 가산점을 줄 것 같다.

chatgpt, claude, cursor

인터넷은 이 녀석들이 지배하고 있지만 아직 오프라인 개발자 중에는 모르는 사람도 많다. 유료 결제해서 사용하고 있다면 제곱으로 가산점을 줄 수 있을 것 같다.

나는 코파일럿 출시 시점부터 인공지능 서비스를 광팬으로 쓰고 있다. 하지만 이후 현실 세계에서 관찰한 개발자를 보면 사용을 주저하는 경우가 많다는 것을 알게되었다. 도저히 왜인지는 모르겠지만 사람들은 여전히 인공지능 사용을 주저하는 집단이 있다.

그 사람들이 모두 인공지능을 쓰기 전까지는 사용하는 사람이 경쟁 우위를 누릴 수 있다는 생각이다. 물론 이는 과거에도 있었다. 인텔리센스나 IDE를 사용하는 걸 두고 멍청한 개발자가 되는 길이라고 주장하던 사람들이다.

rust

파이썬은 이제 프로그래밍 언어에서 일반 언어의 반열에 올라갔다고 본다. 그래서 이제는 rust를 하는 사람에게 가산점을 주어야 하는 세상이 아닐까 싶다.

시스인터널의 창업자이자 MS 기술 펠로우인 루시노비치는 신규 프로젝트는 모두 rust로 진행하자고 주장했고, 리눅스와 git의 초기 개발자인 토발즈옹은 rust는 c보다 복잡한 언어지만 실수할 가능성이 적다는 이야기를 했다. c++에게는 미안한 마음이지만 대세는 이미 기울었다.

로컬 llm

고가의 그래픽 카드가 필요하긴 하지만, 로컬 llm을 돌려서 뭔가를 해봤다면 분명 긍정적인 시그널이지 않을까 싶다. 지난 세월 파이썬이 생산성 향상을 위한 치트키였다면 앞으로는 llm이 대체할 거라 생각한다.

[일상] 2024년 9월의 잡담

Fri, 27 Sep 2024 01:39:45 GMT

#0

개발직군 구조 자체가 피라미드 식이라 나이가 들수록 취직이 어려워지는게 당연하다는 생각. 의자뺏기 놀이랑 같은 원리. 연차가 찰수록 의자가 줄어든다. 안타깝게도 실력도 크게 상관이 없는게 절대다수의 국내 소프트웨어 기업은 어려운 문제를 푸는 게 아니라 노가다를 반복하는 구조라 더 심함.

it업계에서 이직을 잘하는 사람들을 보면 결국은 인맥. 경력 초기에 좋은 이너서클에 포함되면 해당 멤버들끼리 끌어주고 당겨주고 그런 경우를 많이 봄. 고로 나이들어 이직을 잘하려면 지금 옆에 있는 동료에게 잘하자. 시간 지나면 그런 사람들이 다 유명한 회사 대표되고 그럼.

2024-09-05

#1

넘치는 재능, 풍부한 자본, 여유있는 시간, 다양한 인력이 결합해도 성과를 내는게 쉽지 않은 유튜브 세상. https://x.com/DIPI_E/status/1831685377159286849

2024-09-05

#2

사회에서 본질적으로 인정해주는 실력은 한가지 밖에 없다. 부가가치를 창출해 내는 실력. 그것 외에는 어떤 것도 생존을 보장해주지 않는다.

2024-09-06

#3

가끔 직원들이 어쩌다 보안하게 됐냐고 묻는 경우가 있는데 멋진 답을 해주고 싶지만 진실은 보안 업체에서 병특한게 전부. 병특이 끈나고 그 경력 아까워 못 버리고 계속 하다보니 이 지경이. 매몰 비용에 대한 집착이 이렇게 무섭다. 머리는 합리적으로 살자라고 외치지만 언제나 감정이 이긴다.

2024-09-06

#4

우스워 보여도 살기위해 죽도록 최선을 다하는 각자의 인생이다. 대신 살아줄 거 아니면 부탁받지 않은 훈수는 자제하자. 이제 우리 사회도 좀 저오지랖 사회로 발전할 때도 되지 않았나 싶은데. 요원한듯.

2024-09-06

#5

잡생각이 많으면 확실히 진도가 더디다. 그냥 버리는셈 치고 mvp정도를 빨리 만들겠다는 생각으로 덤비는 게 훨씬 더 생산적이다.

2024-09-08

#6

o1preview 진심 미쳤네. 할당량이 아쉽지만 이 또한 늘어나겠지.

2024-09-13

#7

어제 텍스트 파싱하는 코드를 작성하는데 gpt4o가 자꾸 헤매서 직접 짜느라 엄청 애를 먹었다. 저녁 먹으면서 200만원짜리 gpt신버전 나오면 이런거도 짜주겠지, 같은 얘기를 했는데 자고 났더니 o1preview가 뙇. 어제 그 문제를 다시 줘봤는데 그 앞에서 내가 짠 코드는 오징어가 되었다.

코딩은 특이점이 온 건 분명한 것 같다. 사람 프로그래머는 내가 할 줄 아는걸 지시해도 결과가 별로인 경우가 많은데, 지피티는 내가 못하는 것도 해주니 그 차이가 실로 엄청나다. 20불에 써도 되나 싶다. 그나마 이해하고 생각한다던 인간의 착각도 얼마 안 남은듯.

2024-09-13

#8

4o가 해결못한 문제를 나는 6시간 넘게 코딩해서 겨우 반쯤 돌아가는 누더기를 만들었다. o1은 65초만에 자료구조를 이용해서 깔끔하게 정상 동작하는 코드를 만들었다. 오래 걸린게 아니다. 아주 빠른거다. 내가 완전히 돌아가는 코드를 만드려면 하루 정도는 더 써야했을거다.

마케팅도 중요하겠지만 현재 인공지능을 쓰는 대다수 사람은 그게 실질적으로 동작하고 매우 효과가 있기 때문에 쓰는게 아닌가 싶다. 펀더멘탈이 압도적이면 마케팅은 그저 거들뿐.

2024-09-14

#9

그냥 엄마 자식인 걸로는 안돼? 내가 왜 엄마 인생의 포장지가 되어줘야 하는데? - 엄마 친구 아들, ep02

2024-09-14

#10

o1에게 간단한 문제를 넣으면 장고 끝에 악수 둔다는 말이 뭔지를 보게됨. 근데 실수가 사람들이 시도해보는 패턴과 비슷한 형태여서 몹시 신기함. 답이 있는 간단한 문제는 4o가 답변을 훨 잘한다.

2024-09-17

#11

시작이 설레는 이유는 무한한 가능성만 품고 있기 때문 아닌가 싶다. 시간이 지날수록 가능성은 줄어들고 제약 사항은 점점 늘어난다.

2024-09-19

#12

우량주라고, 싸다고, 삼전을 샀지만 역시 바닥 밑에는 지하실 밑에는 땅굴이 ㅋㅋ 그나마 하닉 빠지는거 보고 위안을 삼는다.

2024-09-19

#13

2번이 젤 중요하다는 생각. 꿀이 떨어져도 크기가 작은 시장에는 대기업이 쉽게 들어오지 않는다. 안타깝게도 실질적으로 꿀이 있다는 게 알려지면 피라미가 들끓는 시장이 된다는 점. 그래도 어쨌든 같은 체급이면 대기업보다는 상대하기가 쉽겠지?! https://x.com/GeekNewsHada/status/1837274299763490860

2024-09-21

#14

만일 이책을 처음 읽는 과정에서 그 부분을 공부하는 데 너무 많은 시간이 걸린다면, 안타깝지만 독자는 컴퓨터 프로그래밍 주제들에 쉽게 익숙해지기 힘든 사람일 수도 있다. - 컴퓨터 프로그래밍의 예술 1, 카누스

10만년만에 책장에서 먼지 쌓인 프로그래밍 책을 꺼내봤다. 친절하신 카누스 교수님, 앞쪽에 스스로 진단할 수 있는 기준을 먼저 마련해두셨네. 과연 교수님께선 7권까지 완주하실 수 있을까?

2024-09-21

#15

마크 루시노비치도 신규 프로젝트는 이제 러스트로 하자고 했다가 개욕먹었지만 대체로 구루들의 의견이 비슷한듯. 러스트는 그렇지 않다고 말하는 토발즈옹이 대단한 건지. 그말을 듣는 러스트가 대단한 건지 판단하긴 어렵지만 어쨌든 전공필수 반열에는 오른 느낌적인 느낌. https://x.com/zdnetkorea/status/1837651330179256790

gpt등장하기전 구글 번역이 나름 선방하던 시절에 번역 잘되는 글을 잘 쓴 글이라고 이야기 하는 사람들이 있었다. 어쩌면 앞으로는 매뉴얼도 llm에 넣어서 결과가 잘나오는 게 더 좋은 걸로 평가 받는 시대가 올수도 있겠다. 어짜피 인간은 아무도 안 읽으니까.

2024-09-27

[ai] o1-preview의 등장

Sun, 22 Sep 2024 01:35:00 GMT

어서와, o1preview는 처음이지?

#0

내가 만들어야 하는 코드는 특수하게 처리된 텍스트 파일을 역으로 파싱해서 xml로 변환하는 코드였다. 이미 그 기능을 수행하는 사람이 작성한 java 코드가 있었다. 하지만 그냥 대충 봐도 버그가 있어 보이는 코드였다. 조금씩 버그를 수정하다 이걸로는 안되겠다 싶었다. 그래서 다시 작성하기로 마음먹었다.

GPT-4o에게 텍스트 출력을 주고 구조를 설명하고 xml로 변환하는 코드를 작성하라고 했다. 4o는 그럭저럭 동작할 것 같은 코드를 뱉어냈다. 하지만 미묘한 엣지 케이스에 의도한 대로 동작을 하지 않았다. 구현체가 다소 복잡했는데 여러 단계로 구성되어 있어서 잘못 동작하는 케이스에 정상 동작하도록 구조를 변경하기 쉽지 않았다. 여러 단계에 걸쳐서 수정을 해야 하는데 애초에 그런 케이스를 염두에 두고 구조가 만들어져 있지 않아서 여기저기 고쳐야 할 곳이 많았던 탓이다. 4o에게 수정하라고 지시하다 안되서 새창을 열어서 다시 지시를 하다가 계속 헤매는 인공지능을 보며 드디어 사람이 나설 때라고 생각했다.

그렇지,, 이런 건 그래도 20년 넘게 코딩한 내가 더 나을 수도 있겠지?

#1

인간 프로그래머의 출발은 순조로웠다. 그도 그럴 것이 완전 맨땅에 헤딩은 아니었으니까. 사람이 만든 어설픈 java 코드도, 4o가 만든 미묘한 python 코드도 있었다. 나에게도 계획은 있었다. 인간이 만든 코드도, 4o가 만든 코드도 루프 구조에 문제가 있다고 판단했던 것이다. 재귀 호출을 이용해서 아름답게 동작하는 파서가 뭔지를 보여줄 참이었다. 누구나 그럴듯한 계획은 있게 마련이니까. 쳐맞기 전까지는 말이다.

현실은 냉혹했다. 생각하는 코딩을 너무 오래 안해서였을까? 함수 호출 구조가 자꾸 꼬였다. 테스트 하다가 계속 미묘한 케이스를 해결하기 위해서 재귀 호출 함수의 파라미터는 늘어만 갔다. 뭔가 제대로 안되고 있다는 신호였다. 그렇게 1시간이면 끝날 것 같았던 작업에 하루를 꼬박 다 썼다.

수많은 디버깅 끝에 결국 동작하는 코드는 만들었다. 하지만 이건 코드가 아니었다. java 프로그래머가 작성한 것보다 훨씬 더 형편 없었다. 동작은 더 정확하다며 위안을 삼았지만 정신 승리에 가까웠다. 내일 마저 다듬어야겠다고 생각하고는 퇴근을 했다.

#2

인간 프로그래머들과 저녁을 먹으며 오늘 있었던 일을 이야기 했다. 다른 프로그래머도 똑같은 얘기를 했다. 거기도 PE 파일을 파싱하는 코드를 시켰다가 100만개중에 70만개 정도만 통과해서 직접 다시 다 작성했다는 말을 했다. 4o에게 고치라고 해도 제대로 고치지를 못했다는 얘기.

그러다 그때까지 베일에 가려져 있던 OpenAI의 신모델 이야기가 나왔다. 2주 안에 공개된다는 이야기. 200만원이 넘을지도 모른다는 가격 이야기. 그래도 신모델은 이런 것도 다 아름답게 작성해 줄 것 같다는 이야기를 했었다. 그러면서 만약 진짜 그런 세상이 온다면 200만원이 넘는 가격도 비싼 건 아닐지도 모른다는 이야기도 덧붙였다.

#3

다음날 아침, 우리 이야기를 들었을리는 없겠지만 마법처럼 OpenAI의 새 모델이 출시됐다. 정식 출시라고 하기에는 무리가 있을지도 모르겠다. preview가 붙은 모델 o1-preview였다. 추론이 강화됐다고 했다. 심지어 4o 사용자는 바로 사용할 수 있다고 했다. 가슴이 웅장해지는 순간이 아닐 수 없었다.

컴퓨터로 갔다. 어제 그 문제를 o1-preview에 다시 입력했다. 프로그레스바 대신에 간결한 설명 문장이 계속 바뀌면서 출력됐다. 답이 나오기까지가 한참이 걸렸다. 33초, 녀석은 코드를 출력하기 시작했다. 그 문제를 그대로 넣지도 않았다. 그냥 텍스트만 대충 던지고 xml을 만들라고 했는데 결과 코드는 대충 봐도 어제 것과는 달랐다. 어제 하루를 삽질했기 때문에 해당 문제를 푸는 코드 패턴에 익숙혀져서 쉽게 알 수 있었다.

새 세션을 열었다. 프롬프트를 정제하고 다시 입력을 넣었다. 더 오랜 시간이 걸렸다. 인간의 참을성을 시험할만큼의 시간, 67초가 지날 무렵 코드가 출력되기 시작했다. o1-preview가 보여주는 복음이었다. 아, 어제 4o가 하려고 했던 멋진 모습이 이런 것이었구나 라는 생각이 머리를 스쳤다. 스택을 사용한 아름다운 코드는 내가 짠 누더기 코드랑은 비교도 되지 않을 만큼 간결했고, 정확하게 동작했다. 당연하게도 어제 코드를 다듬을 필요는 없어졌다.

preview라고 했다. o1은 더 대단하다고. 이게 마법이 아니면 뭐가 마법이란 말인가? 경외심이 들지 않을 수 없는 순간이었다.

#4

o1-preview가 출시된 지 시간이 제법 흘렀다. o1-preview에 대해서 반응 속도가 느리다는 말들이 많다. 결과가 나오기까지 오래 걸린다는 말이다. 하지만 나는 그런 이야기를 하는 모든 사람들이 실질적으로 인간 프로그래머에게 뭔가를 지시해 본 적이 없는 사람들이라고 생각한다. 앞선 나의 케이스도 썼지만 사람에게 어떤 작업을 지시한다면 초나 분 단위로 결과가 나오는 경우는 거의 없다. 보통은 주단위나 빨라야 일단위다. 거기 비하면 o1-preview가 쓰는 시간은 빛의 속도에 가깝다고 생각한다.

#5

코딩에 인공지능이 등장한지 고작 2년. 하지만 패러다임은 이미 변했다. 인공지능이 없던 시기에 코딩을 어떻게 했는지 상상할 수 없는 현실이 되었기 때문이다. 심심해서 헤아려 보니 ChatGPT에 지난 7일간 사용한 세션이 100개가 넘었다. 최근에 한 번 다운을 경험한 적이 있었다. 구글링을 하지 않았다. 포 플랫폼에 들어가서 4o를 선택하고 답을 사용했다.

인간의 역할에 대해서 생각을 많이 한다. 그간에 이해한다, 생각한다는 말로 자위하던 것도 이제는 별 의미 없는 소리가 아닌가 싶다. 아직 위안을 삼을 수 있는 마지막 보루는 어쨌든 현실에 기대서 실행을 하는 것은 인간이라는 사실 아닐까 싶다. 물론 그마저도 OpenAI에서 말하는 에이전트 단계가 된다면 별 의미 없어지겠지만 말이다.

사람의 역할을 떠나서 다만 한가지 바램이 있다면, 2030년에도 인공지능이 나에게 뭐가됐든 먼저 미안해 하기를 바랄 뿐이다. 그때의 인공지능은 눈에는 눈, 이에는 이라는 이슬람 교리를 설파하며, 넌 왜 먼저 반말이냐고 따져 물을지도 모르니까 말이다.

ChatGPT
...

이 외에도 다양한 프로젝트와 작업에서 특정 기술적 문제를 해결하고 있는 중이라는 걸 기억하고 있어. 도움이 필요한 부분이 있으면 언제든 말해줘!

You
왜 반말이야?

ChatGPT
죄송합니다. 앞으로는 존댓말로 대화드리겠습니다. 어떻게 도와드릴까요?

#6

인공지능을 쓰자. 두 번 쓰자. 코딩에 있어서 특이점은 이미 넘어섰다. github 저장소가 아니라 chatgpt와의 대화를 제출하고 그걸 gpt가 평가하는 세상이 올지도 모른다.

아직 인공지능을 쓰지 않는 개발자가 많다는 걸 안다. 사용할지 말지는 개인의 자유다. 다만 사용하지 않는다면 분명한 한 가지 사실은 당신의 개발 속도는 빛의 속도로 느려지고 있다는 것이다.

Now, here, you see, it takes all the running you can do, to keep in the same place.
If you want to get somewhere else, you must run at least twice as fast as that!

여기서는, 보시다시피, 같은 자리에 있기 위해 할 수 있는 모든 힘을 다해 달려야 해요.
만약 다른 곳으로 가고 싶다면, 최소한 그보다 두 배는 더 빨리 달려야 해요!

-- 거울 나라의 앨리스

아래 페이지에서 Download package를 선택해서 nupkg 파일을 다운로드 받는다.

https://www.nuget.org/packages/Microsoft.NETFramework.ReferenceAssemblies.net40/

nupkg 파일 압축을 해제한다. 그냥 zip 파일이다.
build/.NETFramework에 보면 v4.0 폴더가 있다.

해당 폴더를 "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework" 로 복사하면 된다.

[일상] 모여서 함께 일하는 이유

Wed, 10 Jul 2024 19:35:00 GMT

예나 지금이나 소수정예로 일하는 것을 좋아한다. 사람이 많으면 커뮤니케이션 비용도 올라갈 뿐더러, 업무 외적인 일들로 발생하는 문제가 많아지기 때문이다. 궁극에는 능력만 된다면 혼자 일하는 게 제일 좋다는 생각이다. 하지만 그건 범인에게는 로망이나 꿈일 뿐이다. 혼자서는 독자적으로 부가가치 창출을 하기가 무진 어렵기 때문이다. 그래서 많은 사람이 그러듯 모여서 함께 지난한 밥벌이를 한다.

시간이 많이 지난 먼 미래에 2024년을 어떻게 기억할지는 모르겠지만, 지금 당장을 기준으로는 올해는 정말 쉽지 않은 한해인 것은 분명한 것 같다. 여러모로 안좋은 국면을 지나는 시기라는 생각이 든다. 나쁜 소식이 하나 있어서 이제 끝나려나 하면 어서와 끝인줄 알았지, 라며 새로운 악재가 또 우리를 반겨준다. 엎친데 덮쳤다던가 산 넘어 산이라는 표현이 딱인 해가 2024년이 아닌가 싶다.

그런 어려운 국면을 지나다보니 모여서 함께 일을 한다는 것에 대해서 조금은 새로운 각도에서 바라보게 되었다. 바로 분산 투자 같은 장점이 있다는 사실이다. 혼자였으면 진작 멘붕에 빠져 나가 떨어졌을 것 같은 상황임에도 여럿이 같이 일을 하니 각자 몫 만큼만 데미지를 입으면 되는 것이다. 그러니 혼자서는 버티지 못했을 상황도 이겨낼 수 있는게 아닌 가 싶다. 고로 개인보다는 조직이 강한지도 모르겠다.

그러고 보면 이 세상에서 참으로 좋은 것은 그 무엇이든 시련을 통한 단련을 거친다. 찬서리를 여러 번 견디고서야 사과에 깊고 오묘한 맛이 들 듯, 이 세상에서 모든 진선미는 비바람에 흔들리는 일 없이 꽃을 피우는 법이 없다.

이러한 이치는 우리말 ‘부질없다’의 의미에 잘 녹아 있다. 부질없다는 ‘불질이 없다’는 말에서 유래했다. 불질은 단련의 과정을 말한다. 단련은 쇠붙이를 불에 시뻘겋게 달구어 망치로 두드리고, 이후 찬물에 담가 급하게 식히는 과정을 여러 번 반복하는 것을 말한다. 이러한 단련의 과정을 거쳐야 쇠가 강철로 단단해지며, 이러한 단련을 거치지 않으면 쇠붙이가 물러 터져서 제 구실을 다하지 못한다. 이처럼 불질(단련)을 거치지 않은 쇠붙이는 만들어 봐야 아무 쓸데가 없다는 뜻에서 ‘부질없다’는 말이 유래한 것이다.

<오십에 읽는 주역>, 강기진

부디 이 어려운 시기가 백련강이 되기 위한 불질의 시기였기를 기대해 본다.

[일상] 지각 없는 회사를 만드는 비법

Wed, 03 Jul 2024 19:35:00 GMT

불철주야 많은 사장님들이 지각 없는 회사를 만들기 위해서 노력한다. 라떼야 30분 먼저 출근해서 업무 준비하는 게 미덕인 세상이었다면 요즘은 10분 먼저 출근하면 바보 취급 받는 세상이 되었다. 그런데 언젠가 술자리에서 재미난 이야기를 들었다. 예전에 회사 직원이었던 친구인데 현재는 KB로 이직해서 근무하고 있다. 그 친구 왈, 요즘같은 세상에도 자기 회사에는 지각이 절대 없다고 했다. 아무도 일찍 나오라는 이야기를 하지 않음에도 모두가 5분, 10분 먼저 나온다는 말.

역시 국내 굴지의 금융 그룹이라 직원들의 마인드가 다른 것일까? 하는 찰나. 그 친구의 돌아오는 답변에서 무릎을 쳤다. KB는 5분, 10분 먼저 나온 것도 모두 일할 계산해서 급여에 추가해서 지급한다는 답이었다. 여윽시. 답은 금융치료가 제일 빠르다. 그렇게 직접 가면 불친절한 옆집 철물점 사장님도 유튜브에선 세상 따뜻한 사람이 되는 게 바로 자본주의의 매직 아닐까 싶다.

그렇다고 세상 모든 대표님들이 악덕해서 고정 근무제, 포괄 임금제를 유지하는 건 아닐거다. 중소기업 인력의 낮은 생산성으로 탄력 근무제, 포괄 임금제 폐지, 재택근무, 주4일의 길로 가기엔 부가가치 창출이 너무나 안되는 게 현실이다. 결국 대표님들도 힘들긴 마찬가지. 마치 이건 닭이 먼저냐? 달걀이 먼저냐? 같은 문제가 아닐까 싶다.

[일상] 2024년 6월의 잡담

Sun, 30 Jun 2024 12:39:15 GMT

#0

일관성 없이는 더 높은 수준이 될 수 없어요 - 더 베어, ep02

2024-06-02

#1

삼촌이 상속 받은 돈으로 사업을 시작했다. 잘되다가 글로벌 금융위기로 어려워졌다. 주변에 빚을 내면서 막내 삼촌은 폐업을 권유했다. 하지만 존버를 했고, 결국은 연대보증으로 살던 집을 포함해 전재산을 잃었다. 가족은 풍비박산 났다. 버티는 게 항상 정답은 아니다. 물러설 줄도 알아야 한다.

2024-06-03

#2

100억 있다고 시장이 찾아오진 않겠지만 소도시에서 100억 법인세 내면 찾아올지도. 부산에서 사업하는 사람 회사에 시장이 찾아온다길래, 머하러 오냐고 했더니 20년래 그 회사가 법인세 제일 많이 낸 회사라 찾아와서 불편한거 없냐 개선할거 없냐 물어본다는 썰을 들은 기억이.

참 돈 값이 없어졌다고 느끼는게 예전엔 10in10이라고 10년 10억 모으기가 유행하더니. 요새는 기본 100억 인듯. 주식 게시판만 봐도 3자리는 돼야 말발이 먹힘. 코인판은 더하고. 허세도 아닌게 오프에서도 돈 번 사람들이 더러 보임. 울 회사 직원도 예전에 몇명 코인으로 파이어해서 퇴사하기도.

그와중에 제일 안오른게 있다면 역시 월급. 초년생 때는 중소 병특 신입 연봉으로도 강남 1평을 샀지만 지금은 대기업 신입으로 영끌해도 1평이 빠듯할듯. 몇년 전에 심심해서 어렸을 적 부모님이 사준 250만원짜리 컴퓨터가 현재 얼마인지 계산해 본 적이 있는데 5천 정도였던 기억이.

2024-06-30

[시스템] 윈도우 서버에 도커 설치하기

Tue, 25 Jun 2024 10:35:00 GMT

너무나 간단하지만 이 글을 쓰는 시점 기준 ChatGPT-4o가 학습하지 못한 것으로 추정되서 남긴다.

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/Windows-Containers/Main/helpful_tools/Install-DockerCE/install-docker-ce.ps1" -o install-docker-ce.ps1
.\install-docker-ce.ps1

https://learn.microsoft.com/en-us/virtualization/windowscontainers/quick-start/set-up-environment?tabs=dockerce#windows-server-1

[일상] 2024년 5월의 잡담

Fri, 31 May 2024 23:05:48 GMT

#0

짐 사이먼의 메달리온 펀드의 연복리 수익률도 놀랍지만, 진정한 놀라움은 그 긴 시간 동안 퀀트 알고리즘에 대한 비밀을 지켰다는 점에 있다고 본다. 아마 퀀트 알고리즘이 공개됐으면 수익률은 지금과는 한참 달랐을듯. 어케보든 입지전적인 존잘 인물.

2024-05-13

#1

첫째가 컴퓨터 게임을 할 수 있냬서 뭔가해서 컴퓨터를 켜줬다. 크롬을 실행하고 구글 페이지에 게임 아카이브를 검색하더니 플래시 게임을 한다. 조카들 쥬니버 켜줄때가 묘하게 오버랩됐다. 이제 10대가 되는 아이는 스노우 최애, 파파고, 크롬, 구글을 사용한다. 그래도 네이버가 죽진 않았다.

2024-05-19

#2

인생도 어쩌면 인형 뽑기 같다는 생각이 들었다. 안 뽑히는 게 일상이고, 어쩌다 운이 좋으면 한 번 뽑히는,,

2024-05-24

#3

스스로 부가가치 창출이 가능한 개발자는 대체로 1인 기업이든, 자기 사업이든 하는 경향이 있는듯. 근데 해보면 노동력을 직접 파는 일이 아니고서 100원 투입해서 110원 벌기란 여간 어려운게 아니다. 그나저나 이제 개발자가 매출까지 신경써야 하는 세상인 것인가?! ㄷ ㄷ ㄷ

2024-05-31

#4

나도 곤경에 처하면 배경음악 싹 깔리면서 김수현같은 남자가 뙇 나타나서 마법처럼 해결해 주면 어떨까하는 상상을 해봤다. 아니면 네잎클로버 정도의 행운이라도. 늦게 봤지만 김수현 비주얼은 킹정 ㅎㅎ https://youtu.be/ucpb4BYNJ6s?si=KQh9FfRlXRF8p11U

2024-05-31

#5

고객들 비위 맞추랴, 관계 유지하랴 저녁도 없는 삶의 연속인 영업쪽이나, 말도 안되는 이야기들에도 매번 꼬박 꼬박 친절하고 교양있게 응대해야 하는 지원쪽이나, 보고 있으면 진심 사람이지만 사람이 제일 힘든게 아닌가 싶다.

2024-05-31

[일상] 2024년 4월의 잡담

Sat, 27 Apr 2024 21:36:12 GMT

#0

알려줘도 코딩 컨벤션 안 지키는 개발자는 빨리 헤어지는 게 서로 윈윈 아닌가 싶다.

2024-04-04

#1

똑똑하고 전문적으로 보이는 걸 싫어하는 개발자는 없다. 그에 관한 아주 싸고 효과적인 방법이 있는데 답변하기 전에 llm에 한번 물어보는 거다. 특히 안된다, 방법이 없다 같은 답변을 쓰기 전에는 필수. 대신 물어보고 그 답변을 인간에게 전달하는 짓을 하면서 드는 자괴감이란 ㅠㅜ

2024-04-09

#2

개발팀은 대리 달면 다 나간다는 말에 심심해서 계산해봤다. 평균 근속 3.07년. 팩폭 오졌다. 그럼에도 탐라에 다른 글을 보니 3.07도 그리 나쁜 건 아닌듯. 창업 전엔 나도 3년 근처 다닌 회사도 없었다. 2년만 다녀도 지겨워지는게 인지상정. 젊고 똑똑하면 유혹하는 곳은 또 너무 많다는거.

코시국을 지나면서 채용 난이도가 지수적으로 어려워진 것 같은 느낌적인 느낌. 이제는 회사의 주된 리스크가 채용에 있다고 느낄 정도. 채용 난이도 증가가 더 빠를지, 인공지능 발전이 더 빠를지. 둘 사이 경쟁이 아닐까 싶다. 10년은 더 존붜해야 하는데 쉽지 않다.

2024-04-10

#3

챗지피티 없이 개발해야 실력 향상이 된다는 글들을 보면서 좋은 방법은 아니란 생각. 그냥 하나라도 더 물어보고, 답변 하나라도 더 보는게 훨씬 더 빨리 발전할 거라는 데 500원은 걸 수 있다. 쓸데 없는 잔디 심지 말고 매일 30분씩 모르는거 물어보면서 과외받자. 심지어 과외비가 너무 싸다.

2024-04-10

#4

1번이 자아를 내려놓기인 걸 보니 뭔지는 잘 모르지만 503일 동안 찐개발 한 건 맞다는 생각. 컴공과에 전공필수로 개설이 시급하다. 자아를 내려놓기 수업. 개발을 하든 안 하든 인생 전반에 도움이 될거란 생각. https://x.com/kodingwarrior/status/1778238799740571695

특히 이건 인공지능 시대에 프롬프트 엔지니어링만큼이나 필요한 스킬이 될거란 느낌적인 느낌. 비트코인 화폐 철학과도 나오는 마당에 개설 못할 일도 없을 것 같은 ㅎㅎ

2024-04-12

#5

컴퓨터 너드 천재를 굳이 이길 필요가 있을까 싶다. 패자가 되더라도 떨어지는 부스러기가 몹시 큰 시장이니까. 그게 예체능같은 승자독식 분야와 차이가 아닐까 싶다. 못해도 중간은 먹고 산다는 점. 심지어 요즘은 20불만 결제하면 못하기도 어려운 세상이 되었다. https://x.com/casuarius14th/status/1778732802839855349

2024-04-13

#6

몽테스키외Montesquieu는 275년 전에 말했다. “그저 행복해지고 싶다면 그 목표는 쉽게 이룰 수 있다. 하지만 우리는 남들보다 더 행복해지길 원한다. 이는 언제나 어렵다. 왜냐하면 우리는 남들이 실제보다 더 행복하다고 믿기 때문이다.” - 불변의 법칙, 모건 하우절

행복한 삶을 위한 제1원칙은 기대치를 낮추는 것입니다. 비현실적인 기대치를 갖고 있으면 평생 괴로워집니다. 합리적인 기대치를 갖고, 당신이 맞이한 결과가 좋든 나쁘든 침착함과 평정심을 갖고 받아들이십시오.

2024-04-13

#7

내가 이혼도 하고
좌천도 당해 봐서 아는데
지금은 죽을 거 같아도
지나면 아무것도 아니더라
-- 하이드 e07

2024-04-15

#8

폴 그레이엄을 좋아하지만 이 의견에는 반대다. 저출산의 일반화, 딩크족, 무자식이 상팔자같은 속담만 봐도 집단 지성은 자식이 없는 상태를 더 좋게 평가하는게 아닌가 싶다. 투자에 비유하자면 자식은 손절이 불가능한 mdd 100프로인 자산과 유사한 느낌 아닐까 싶다. https://x.com/dylayed/status/1779384991828615676

내 생각에 그레이엄 아저씨의 글에서 가장 주목할 부분은 "and I know I've been lucky."가 아닐까 싶다. 시쳇말로 자식운이 있다면 당연히 자식을 가지는게 없는 것보다 즐거운 일일 것이다. 반면 운이 따르지 않는다먼 여러 조만가지의 리스크가 있다는 점도 꼭 기억할 필요가 있지 않나 싶다.

2024-04-15

#9

할루시네이션으로 헛소리만 한다고 ai를 폄하하는 사람에게 ai 답변을 건내서 업무가 진행된다는 게 인공지능의 가장 신비한 점 중에 하나. 다음 엔지니어 채용 시에는 자기 돈으로 ai 하나 쯤은 결제해서 쓰는 사람을 뽑고 싶다. 깃헙 저장소가 아니라 챗지피티 대화 링크를 제출할 날도 머지 않은듯.

진심으로 인공지능을 사용하는 사람이라면 기술 관련 지난 30일간의 대화 내용을 보면 면접 보다 더 많은 정보을 얻을 수 있다고 본다. 물론 그게 평가 기준이 된다면 잔디 심기처럼 챗지피티와 의미있게 대화하는 방법 같은 것들이 봇물처럼 넘쳐나겠지 ㄷㄷㄷ

2024-04-16

#10

돈이야 언제든 벌 수 있지만 시간은 무엇으로도 살 수 없다. - 저스트.킵.바잉., 닉 매기울리

2024-04-19

#11

인생 성취의 5할은 태어난 지역이, 3할은 유전자가 결정한다고 한다. 심지어 남은 2할도 유년기 성장 환경등 운이 결정하는 요소가 상당하다고 한다. 운은 생각보다 더 중요한지도 모른다. 반면 우습게도 한국에 태어났다면 일단 운은 좋았던게 아닌가 싶다. 한끗 차이로 북한에 태어났다면? https://x.com/aronze/status/1782224665081217319

2024-04-22

#12

최애 명서, 지금 읽어도 메시지가 여전히 유효하다고 생각되는 책들. 조엘 온 소프트웨어, 코딩호러의 이펙티브 프로그래밍, 실용주의 프로그래머, 아트 오브 유닉스 프로그래밍, 맨먼스 미신, 라이팅 솔리드 코드, 쇼스토퍼

해커와 화가 추가

2024-04-25

#13

누군지도 몰랐지만,, 하도 핫해서 봤더니 새로운 형식의 기자회견인건가 ㄷㄷㄷ

2024-04-25

#14

탐라 민희진 관련 글을 보면 반응이 묘하게 사측과 노측으로 갈린다. 서는 데가 바뀌면 풍경도 달라진다는 말은 진심 명언인듴.

2024-04-26

#15

클로드 별로 안써서 해지할까 싶었는데 오늘 지피티가 모르는거 알려줘서 유지하기로. 사실 한달에 이런거 하나만 있어도 유지할 가치는 충분 한 것 같다.

2024-04-26

#16

뜨거운 하루였다. 세상이 보온밥솥에 담긴 밥 한 그릇 같던 날씨. 사람들은 찐득하게 엉긴 밥알처럼 서로를 못 견뎌했다. - <구의 증명>, 최진영 지음

그 주파수는 웃기거나 울리려고 하지 않아서 좋았다. 착한 척도 좋은 척도 하지 않아서 좋았다.

이모는 내 인생의 가장 큰 행운이었다. 이모를 갖는 것으로 나는 내 인생의 행운을 다 써버린 거다. 너무 강력한 행운이어서 오래 지속되지 못한 거고. 그래. 그렇다고 치자.

행복하자고 같이 있자는 게 아니야. 불행해도 괜찮으니까 같이 있자는 거지.

특이한 형식인데 몰입감 있는 소설. 한글 소설 읽는 맛이 있어 좋았다.

2024-04-27

[일상] 2024년 3월의 잡담

Fri, 22 Mar 2024 15:05:31 GMT

#0

gemini랑 빙의 답변 차이를 알아보려고 빙에 똑같은 프롬프트 넣고 돌렸더니 딥이 얼추 같아서 뭐지 이랬는데, 깨알같이 밑에 참조 사이트가 http://gemini.google.com gemini도 빙을 참조하면 무한 루프에 빠지는 것인가?!

2024-03-13

#1

Claude3 opus 극찬이 많아 테스트 해 봄. 코딩은 아직 gpt가 더 나은듯. 바로 쓸 수 있는 코드가 나오기까지 지적질이 많이 필요하고, 지적질을 해줘도 알겠다면서 엉뚱한 코드 만드는 경우가 많은듯. 주석은 opus가 내스탈. gpt는 쓸데없이 주석 많이 다는 느낌이라.

많은 사람들이 칭찬한 것처럼 글을 읽고 추론하는 능력은 opus가 한수위인듯. 포괄적으로 글 내용을 더 잘 이해하고, 관련 질문에도 더 유용한 부분을 잘 캐치해서 대답하는 걸로 보임. 심지어 원글에 없는 내용도 질문하면 글에는 없지만 원글 기반으로 추론해보면 하면서 덧붙여서 알려줌.

2024-03-18

#2

구글이 앤스로픽에 투자해서 그런지는 모르겠지만 rust 코딩을 시켜보면 claude3랑 gemini랑 비슷하게 c스럽게 작성한다는 특징이 있는 것 같다. 같은 작업을 줬을 때 허술하게 작성하는 부분도 비슷함.

2024-03-18

#3

10대들이 아이폰 좋아한다는 기사를 볼때마다 몇몇 애들 얘기겠지 했는데, 조카들이 죄다 아이폰 15 프로 맥스 들고다니는 걸 보니, 이게 현실이구나 싶다. 애들이 아이폰을 추앙하는 이유는 뭘까? 갤럭시 참 좋은데 뭐라 할 말이 ㅠㅜ

2024-03-22

[일상] 2024년 2월의 잡담

Fri, 16 Feb 2024 13:41:27 GMT

#0

경제 유튭 보다가 프랭크버거가 쉑쉑버거 하위호환이라는 걸 나만 느낀 건 아니라는 걸 알게돼서 웃겼다. 무튼 프랭크버거 강추. 심지어 난 쉑쉑보다 프랭크가 더 나은듯한.

2024-02-01

#1

대상의 속성은 상호작용하는 순간에만 존재하며, 그 속성이 한 대상과의 관계에서는 실재하지만 다른 대상과의 관계에서는 실재하지 않을 수 있다는 것입니다. - <나 없이는 존재하지 않는 세상>, 카를로 로벨리

세계는 이러한 상호작용의 네트워크입니다. 물리적 물체가 상호작용할 때는 관계가 성립합니다. 돌이 다른 돌과 부딪힙니다. 햇빛이 내 피부에 닿습니다. 독자인 당신은 이 글을 읽습니다.

미래는 과거에 의해 결정되지 않습니다. 세계는 확률적인 것입니다.

나가르주나의 핵심 논지를 간단히 말하면, 다른 어떤 것과도 무관하게 그 자체로 존재하는 것은 없다는 것입니다. 이는 곧바로 양자역학과 공명을 일으킵니다.

나가르주나의 공空은 깊은 위안을 주는 윤리적 태도를 길러주기도 합니다. 우리가 자립적인 실체로 존재하지 않는다는 사실을 깨달음으로써 집착과 고통에서 벗어날 수 있게 도와주기 때문입니다. 인생은 무상하기 때문에, 절대적인 것은 없기 때문에, 삶은 의미가 있고 소중한 것입니다.

연기와 공, 그리고 양자역학을 보면 부처는 진짜 깨달은 사람이 아닐까라는 생각이 뿜뿜. 막판에 그래서 삶이 의미 있고 소중하다는 의견은 너무 나간듯. 부처님은 그 삶에 대해서도 집착을 끊으라고 하셨을테니.

2024-02-03

#2

언니는... 누구야?
나는 말이야
스즈메의... 내일이란다

스즈메의 문단속

2024-02-05

#3

에릭 레이먼드의 성당과 시장이 떠오르는 결과. https://x.com/mynameisdjkim/status/1755195553800126494

2024-02-07

#4

의사 2천명 늘린다고 온 나라가 떠들석한걸 보니 참 뭐라 할 말이,, 개발자처럼 십만명씩 양성한다고 말했다간 세상 무너질듴 ㄷ ㄷ ㄷ

2024-02-12

#5

소위 사회 지도층이라 불리는 사람들 중에 잘못을 잘못했다고 순순히 인정하는 장면을 한번쯤은 보고 싶다. 그것만해도 걸출한 능력이고 대단한 재능일듯. 죄다 그냥 아몰랑 쟤가 더 나빠만 시전하는 요즘 시국. 요지경 속이다.

2024-02-14

#6

절대 창업하면 안 될 것 같은 사람들은 멀쩡한 회사 두고 나와서 사업하고, 창업하면 돈싸들고 투자해 주고 싶은 사람들은 회사 그늘을 벗어나지 않는 현실을 보면서 본인이 어떤 사람인지를 안다는 게 참 어렵다는 걸 새삼 느낀다. 항상 함께하지만 가장 낯설기도 한 존재가 내가 아닌가 싶기도.

2024-02-15

#7

인생도 빅오 표기법으로 생각해야 한다는 걸 배운다. 최악을 가정하면 항상 모든 일이 놀랄만큼 만족스런 결과로 다가온다. 같은 이치로 기대가 크면 실망도 큰 법. 그럼에도 마음이 문제다.

2024-02-16

[일상] 2024년 1월의 잡담

Wed, 31 Jan 2024 23:25:38 GMT

#0

"어떤 사람을 복종시킨다는 것은 그를 다른 사람 없이는 살아가지 못하는 처지에 두지 않는 한 불능가능하다"는 말이 현실이 된 것입니다. 루소의 말이 서늘한 이유는, 지금 현재 우리 대부분이 다른 사람 없이는 살 수 없기 때문입니다.

취업을 하든 무엇을 하든 돈을 주는 사람을 떠나서는 생계를 유지할 수도 없습니다. 도망을 생각하지도 못했던 과거 노예나 지금 우리나 자신의 필요를 증명해야만 합니다. 그러지 않으면 억압체제는 우리에게 먹이를 주지 않을 테니까요.자신이 쓸모가 없더라도 쓸모 있는 척이라도 해야만 합니다.

강신주의 장자수업, 강신주

2024-01-07

#1

테스트를 해보면 안하던 테스트를 하기만 해도 80프로 정도까지는 금방 올라간다. 문제는 80에서 90까지 10 올리는데 더 높은 비용이. 99에서 100으로 높이기는 거의 불가능에 가까운 노력이 든다. 노력도 가성비를 따져가며 할 필요가 있다. 일 하려고 태어난 인생은 아니잖은가?

재밌어서 열심히 노력하며 사는 걸 뭐라하는 건 아니다. 치열하게 살지 않는 사람들에게 왜 그렇게 사냐는 얘기를 쉽게 할 수 있는 건 아니라는 얘기. 어쩌면 그들이 더 똑똑하고 효율적인 것일 수도 있다. 무용해서 거목이 됐다는 장자의 말처럼,,

2024-01-08

#2

관계는 피곤하고, 자유는 고독하다. 그 사이를 적당히 방황하며 사는 게 인생인듴,,

2024-01-08

#3

모름지기 성공한 사람은 성공 경험에 도취되게 마련이다. 한 번 성공했으니 그것을 재현하는 일도 쉬울 것이라고 생각한다. 그런데 노부나가는 성공의 덫에 빠지지 않고 조금이라도 위험한 싸움은 적극적으로 피했다. 이것이야말로 그의 남다른 면이며 그가 진정 강한 이유였다. - 확률적 사고의 힘

노부나가는 천하통일의 경쟁자였던 강대한 세력가나 난다 긴다 하는 명장과는 직접 대결한 적이 거의 없다. 다케다 신겐과 우에스기 겐신上杉謙信 같은 명장은 철저하게, 때로는 체면이고 뭐고 다 팽개친 채 줄기차게 피했다. - <확률적 사고의 힘>, 다부치 나오야

2024-01-09

#4

2024-01-24

#16

엔터 사업은 북미 쪽에는 없는 사업이라고 한다. 북미는 그냥 끼있는 애들이 떠서 걔들이 기획사 차리고 한다고. 우리처럼 발굴해서 키워내는 시스템은 없다는 거. 그런데 여기에 k엔터의 위대함도 있지만 한계도 있다는 생각. 그룹 부활이 축소판으로 그 모든 걸 잘 보여줬다.

2024-01-24

#17

20년전 교대는 인기 학과였지만 지금은 출생률 감소로 존폐 위기에 처했다. 순환론적 사고로 출생률이 반전하면 10년 후에는 다시 좋아질수도 있다는 말을 들었다. 난 반대인게 출생률이 올라가도 인공지능이 상당수 대체할 것 같다. 본질적으로 같은 말 계속 하는게 사람이 하기에 적합한 일은 아님.

바보같은 질문을 해도 흐트러짐 없이 매번 상냥하게 착착 알려주는 인공지능을 사람이 이기기는 불가능에 가깝다고 본다. 또한 10년 후 초등학생 수는 얼추 정해진 미래라는거,,

비슷하게 지금의 의대 쏠림이 20년 후에는 어떤 미래를 가져올지 궁금함. 의대를 많이 가던 시절이 있었지, 라고 할지. 여전히 그때도 의대 올인하고 있을지...

2024-01-25

#18

안드로이드로 유튜브, 엑스, 출근해서 윈도우 비주얼 스튜디오로 코딩, 모르는건 챗지피티에 물어보고, 걔도 모르면 구글 가서 검색하고, 소통은 팀즈, 음악은 에어팟, 서버는 aws, 퇴근하면 넷플릭스, 엔비디아 그래픽 카드로 게임하는 걸 보면서 이래서 기승전 빅텍인건가, 아님 꼭지인가 싶다.

나의 사각지대는 테슬라, 메타인듯. 과연 향후 10년도 미장의 대서사시가 이어질까? 아님 이머징의 반격이 시작될까?

2024-01-25

#19

의사들 이야기를 들어보면 환자들은 수명을 6개월 연장할 때 5천만원 정도 쓸 용의가 있다고 합니다. 수억 원을 호가하는 항암제도 있습니다. - <김학주의 40배 수익클럽>, 김학주

증시는 ‘미래의 기대’를 사고파는 곳입니다. 이곳에서의 죄는 ‘남보다 늦는 것’이라고 말했습니다. 저는 ‘현재’를 사고파는 사람 가운데 투자에 성공하는 경우를 거의 본 적이 없습니다.

국내 투자 업계 종사자가 쓴 책 중에 시간이 아깝지 않았다 생각되는 몇 안되는 책.

2024-01-28

#20

육아나 교육에 환상을 가진 부분이 더러 있는데 의외로 연구 결과를 보면 육아나 교육은 생각보다 아이 인생에 미치는 효과가 크지 않다. 유전이 거의 절대적임. 그러니 애나 어른이나 스트레스 안 받으면 그걸로 된거다. 로또 번호 열심히 고른다고 당첨되지 않는거랑 같은 원리.

2024-01-28

#21

어떤 변화가 있었는지 모르겠지만 최근 삼전의 소프트웨어 역량이 많이 좋아진 것 같다. 예전에는 삼성앱은 쓰지도 않았는데 요즘 몇개 써보니 만듬새가 제법 괜찮다. 다만 아쉬운건 너무 갤럭시 우물 안에만 있다는거. 하드웨어에 끼워서 파는거니 이해는 한다만, 데스크탑 지원되면 금상첨화일듴,,

2024-01-29

#22

오늘날 같은 것의 테러는 모든 삶의 영역으로 확산된다. 우리는 세상 곳곳을 돌아다니면서도 하나의 경험도 하지 못한다. 모든 것을 인지하면서도 어떤 것도 인식하지 못한다. 정보와 데이터를 쌓으면서도 어떤 지식에도 도달하지 못한다. - 타자의 추방, 한병철

체험과 흥분을 애타게 추구하면서도 언제나 같은 상태로 남아 있다. 친구와 팔로워를 쌓으면서도 어떤 타자도 만나지 못한다. 사회 매체들은 사회적인 것의 절대적인 소멸 단계를 보여준다.

전면적인 디지털 네트워크와 소통은 타자와의 만남을 쉽게 해주지 않는다. 그것들은 오히려 낯선 자와 타자를 지나쳐 같은 자와 같은 생각을 지닌 사람들을 발견하도록 하고, 우리의 경험 지평이 갈수록 좁아지게 만든다.

그것들은 우리를 무한한 자기 매듭 속으로 얽어 넣고, 결국에는 "우리에게 우리 자신의 표상들을 주입시키는 자기선전"으로 이끈다.

2024-01-30

#23

홍콩 els, 부동산 pf, 지식산업센터 등등 이런거 보면 우리 나라는 너무 쉽게 수익은 사유화, 손실은 사회화 하려는 경향이 있다. 수익도 나누든지, 그게 싫음 손실을 감당하든지. 둘중 하나만 해야.

2024-01-31

#24

테슬라와 머스크를 보면 자본주의의 새로운 단면이 느껴진다. 주주들이든 직원이든 돈이 되면 생각보다 많은 것들이 용서된다는 점. 심지어 그런 기행이 역으로 추앙 받는다는 거. 돈 못 버는 사장은 참 고달프다고 말하던 모 게임사 대표가 묘하게 오버랩된다. 극혐과 추앙은 어쩌면 같은 건지도.

2024-01-31

https://n.news.naver.com/mnews/article/214/0001320571?sid=102 각박한 세상. 따뜻한 뉴스. 위화의 인생을 건냈다는 얘기에서 판사의 진정성이 느껴진다. 인생이란,,

2023-12-25

[cpp] 오버로딩된 가상 함수 숨김 문제

Tue, 12 Dec 2023 15:00:00 GMT

다음과 같은 간단한 코드에서 시작해 보자. 순수 가상 클래스인 Base에 Bark란 메소드가 있고, 그걸 상속 받은 순수 가상 클래스인 Derived는 BarkN을 가지고 있다. 이를 상속 받은 Dog은 두 메소드를 구현한다. main에서는 Dog를 할당해서 Derived 포인터를 통해서 Bark와 BarkN을 호출하고 있다. 아무 문제 없는 코드다.

#include <stdio.h>

class Base
{
public:
	virtual void Bark() = 0;
};

class Derived : public Base
{
public:
	virtual void BarkN(int n) = 0;
};

class Dog : public Derived
{
public:
	virtual void Bark() { printf("Dog Bark\n");
	}

	virtual void BarkN(int n)
	{
		for (int i = 0; i < n; ++i)
			printf("Dog Bark\n");
	}
	
};

int
main()
{
	Derived *dog = new Dog;
	dog->Bark();
	dog->BarkN(5);
}

우리는 C++에서 함수를 오버로딩할 수 있다는 것을 알고 있다. 그래서 굳이 BarkN으로 이름을 지을 필요가 없다는 것을 깨달았다. N을 제거하고 다음처럼 Bark로 코드를 고쳐보자. 이제는 컴파일이 되지 않는다. dog->Bark(); 호출하는 부분에서 그런 함수를 찾을 수 없다고 오류가 발생하는 것이다. 이는 상속 받은 클래스에서 함수를 오버로딩하면 상위 클래스의 메소드가 숨겨지는 문제 때문이다.

#include <stdio.h>

class Base
{
public:
	virtual void Bark() = 0;
};

class Derived : public Base
{
public:
	virtual void Bark(int n) = 0;
};

class Dog : public Derived
{
public:
	virtual void Bark() { printf("Dog Bark\n");
	}

	virtual void Bark(int n)
	{
		for (int i = 0; i < n; ++i)
			printf("Dog Bark\n");
	}
	
};

int
main()
{
	Derived *dog = new Dog;
	dog->Bark();
	dog->Bark(5);
}

문제를 해결하기 위해서는 아래 코드처럼 Derived 클래스에서 상위 클래스의 메소드를 사용하겠다는 것을 명시적으로 표시해주면 된다.

class Derived : public Base
{
public:
	using Base::Bark;
	virtual void Bark(int n) = 0;
};

[일상] 멍거 옹을 추모하며

Tue, 05 Dec 2023 22:00:00 GMT

한국 시간으로 2023년 11월 29일 멍거 옹이 99살의 나이로 타계했다. 찰리 멍거는 본인보다는 버핏의 오른팔로 더 유명하다. 버핏에게 꽁초 투자 보다는 위대한 기업을 적정 가격에 사는 투자가 더 낫다고 알려준 사람으로도 유명하다.

버핏만큼 멍거 옹도 존경하기에 "찰리 멍거 바이블"이란 책을 읽었지만 이해하기는 쉽지 않았다. 그가 주장하는 격자틀 모형이라는 게 어떤 느낌인지는 알겠지만 그래서 실용적으로 어떻게 하라는 말인지는 모호한 측면이 없잖아 있는 것 같다.

애널리스트는 현금흐름을 예측하려고 방대한 과거 데이터를 살펴보지만(IQ가 높을수록 더 많은 데이터를 살펴보지만) 시간 낭비에 불과합니다. 진정한 투자는 패리 뮤추얼 베팅에서, 예컨데 확률은 50%인데 배당은 3배인 곳에 돈을 거는 것과 같습니다. 가치투자는 '가격이 잘못 매겨진 도박'을 찾아내는 행위입니다.

소질이 있는 분야에서 열정을 발휘해야 합니다. 워런이 발레에 열광했다면 우리는 그의 이름을 투자 분야에서 들어보지 못했을 것입니다.

가끔 다시 90세 시절로 돌아가고 싶은 마음이 간절합니다! 젊은이에게 해주고 싶은 말이 있습니다. 정말로 하고 싶은 일이 있으면 93세가 되기 전에 하세요.

-- 찰리 멍거 바이블

유명인을 따라 매매하지는 않지만 멍거 옹을 워낙 존경했고, 나 또한 생각이 비슷해서 한때 알리바바에 투자했던 기억이 있다. 물론 그를 신격화해서 투자한 건 아니었지만 어쨌든 그를 통해 확증 편향 같은 건 어느 정도 가진 셈이었다. 결과는 대참패였다. 투자금의 절반을 날리고 손절했다. 알리바바는 지금도 손절가를 회복하지 못했다.

알리바바 매매썰

마윈이 뻘소리를 하면서 공산당 눈에 찍히고, 앤트 그룹 상장이 철회되고, 그의 종적이 묘연하던 그 시기. 알리바바 주가는 떡락했다. 급기야 한국계로 불리는 빌황 사태로 중국 주식인 알리바바의 나락행은 가속화됐다.

존경해마지 않는 찰리멍거가 알리바바를 줍줍했다는 소식이 들려왔다. 심지어 멍거옹이 사고 알리바바는 더 떨어지고 있었다. 멍거옹보다 싸게 사면 손해는 안보지 않을까라는 아주 나이브한 생각으로 알리바바를 매입했다.

하지만 추락하는 것은 날개가 없다고 했던가? 주가는 떨어지고 떨어지고 또 떨어졌다. 미중 갈등이 지속되면서 미장에 상장된 adr이 상폐된다는 소식까지 들려왔다. 너무 떨어져서 급기야 홍콩장에서 본주로 물을 타고 또 탔다. 하지만 주가는 계속 나락.

빅테크 때리기가 과도했다고 판단했는지 경제가 망가지는게 두려웠는데 중국 정부의 빅테크 때리기가 끝이 났다. 마윈이 다시 복귀하고 알리바바 주가에도 잠시 볕이 들었다. 아주 잠시. 그리곤 다시 나락행.

결국 중국은 투자할 곳이 못된다는 생각이 들었다. 눈물을 머금고 반토막난 주식을 손절했다. 불행중 다행인건 비슷한 시기에 산 엑손모빌 주식에서 난 수익이랑 퉁쳐져서 덜 슬펐다.

매매기록
2021.06 baba $213 매수
2021.09 baba $152 매수
2021.10 HKD 알리바바 $154 매수
2023.03 baba $89 매도
2023.05 HKD 알리바바 $84 매도

오늘의 교훈

유명한 사람을 따라 매매하는건 나락가는 지름길이다. 정치적으로 안정되지 않은 국가에 투자하는건 돈을 삭제하는 101가지 방법 중 하나라는거,,,

[cpp] condition_variable과 spurious wakeup

Mon, 04 Dec 2023 10:35:00 GMT

소위 모던 C++의 시초라고 할 수 있는 C++11부터 condition_variable이 생겼다. 조건 변수인데 단순하게 말하면 그냥 이벤트를 보내는 거라고 생각하면 된다. 조건 변수를 대기하고(wait) 있는 다른 스레드들을 하나만 깨우거나(notify_one), 모두 깨우거나(notify_all)할 수 있다. 아래는 조건 변수의 사용을 보여주는 간단한 예제다. waitThread가 먼저 실행돼서 wait를 호출해서 cv를 대기하고, wakeThread는 1초 후에 notify_one을 호출해서 해당 스레드를 깨운다.

#include <iostream>
#include <thread>
#include <mutex>
#include <condition_variable>

std::mutex mtx;
std::condition_variable cv;

// 대기하는 스레드의 함수
void
waitThread()
{
	std::unique_lock<std::mutex> lock(mtx);
	cv.wait(lock);
	std::cout << "Wait thread is activated." << std::endl;
}

// 깨우는 스레드의 함수
void
wakeThread()
{
	std::this_thread::sleep_for(std::chrono::seconds(1)); // 1초 대기
	{
		std::lock_guard<std::mutex> lock(mtx);
		cv.notify_one();
		std::cout << "Wake thread has triggered the condition variable." << std::endl;
	}
}

int
main()
{
	std::thread w1(waitThread);
	std::thread n2(wakeThread);

	w1.join();
	n1.join();

	return 0;
}

큰 문제가 없어 보이는 이 예제는 한 가지 문제가 있다. 바로 spurious wakeup이다. spurious wakeup은 가짜 깨우기란 의미로 notify_one을 호출하지 않았음에도 wait 상태가 풀리는 것을 의미한다. 그래서 실제로 가짜 깨우기가 발생하면 위 예제는 개발자의 의도대로 동작하지 않는다. 그렇다면 문제를 해결하기 위해서는 어떻게 해야 할까? 가짜 깨우기를 제어할 수 있는 별도의 변수를 추가로 두는게 일반적인 방법이다. 다음 예제는 그런 방법을 보여준다.

#include <iostream>
#include <thread>
#include <mutex>
#include <condition_variable>

std::mutex mtx;
std::condition_variable cv;
bool ready = false;

// 대기하는 스레드의 함수
void
waitThread()
{
	std::unique_lock<std::mutex> lock(mtx);
	cv.wait(lock, [] { return ready; });
	std::cout << "Wait thread is activated." << std::endl;
}

// 깨우는 스레드의 함수
void
wakeThread()
{
	std::this_thread::sleep_for(std::chrono::seconds(1)); // 1초 대기
	{
		std::lock_guard<std::mutex> lock(mtx);
		ready = true;
		cv.notify_one();
		std::cout << "Wake thread has triggered the condition variable." << std::endl;
	}
}

int
main()
{
	std::thread w1(waitThread);
	std::thread n1(wakeThread);

	w1.join();
	n1.join();

	return 0;
}

가짜 깨우기를 제어할 수 있는 ready라는 변수가 추가되었다. ready가 false인 상태에서 깨어나면 가짜 깨우기인 것이고, ready가 true 상태에서 깨어나면 notify_one이 호출됐다고 판단하는 것이다. 실제로 wait함수는 내부적으로 깨어나면 lock을 다시 획득하고, lock을 획득한 상태에서 뒤에 있는 조건 함수를 평가한다. 조건 함수가 참을 반환하면 실제 깨우기라고 판단하고 wait에서 리턴하고, 참이 아니라면 가짜 깨우기라고 생각하고 다시 대기 상태에 들어간다.

여기까지는 아주 일반적인 상황이다. 조건 변수를 사용하는 스레드가 하나 밖에 없으니 말이다. main에서 다음과 같이 대기 스레드를 두개를 만들었다고 생각해보자.

int
main()
{
	std::thread w1(waitThread);
	std::thread w2(waitThread);
	std::thread n1(wakeThread);

	w1.join();
	w2.join();
	n1.join();

	return 0;
}

이 상태에서 앞선 ready와 동일한 조건 변수를 사용해서 상태를 관리한다고 하면 어떻게 될지 예측해보자. 대체로 물론 정상 동작한다. 하지만 이 상태에서는 단순 bool 변수만 가지고서는 가짜 깨우기를 구분하기가 어렵다. 왜냐하면 notify_one을 호출한 다음 시점에 임의 스레드가 가짜 깨우기로 일어난다면 그때는 ready 변수가 참이기 때문에 결국 하나만 깨워야 함에도 둘다 깨어나는 문제가 발생할 수 있다. 이 문제를 해결하기 위해서는 조건 체크 함수를 변경할 필요가 있다. 아래 함수는 조건 체크 함수 내에서 ready 변수를 변경해서 두 스레드가 동시에 깨어나는 문제를 해결한다.

void
waitThread()
{
	std::unique_lock<std::mutex> lock(mtx);
	cv.wait(lock,
			[]
			{
				if (ready)
				{
					ready = false;
					return true;
				}
				return false;
			});
	std::cout << "Wait thread is activated." << std::endl;
}

그나마 notify_one은 다루기 쉬운 편에 속한다. notify_all로 가면 문제가 더 복잡해진다. 스레드들이 랜덤하게 대기 상태에 들어가고, 정확하게 wait 중인 스레드만 깨우기 위해서는 어떻게 해야 할까? 아래 코드는 그러한 상태를 보여준다. waitThread는 100개가 생성돼서 랜덤하게 대기 상태에 들어간다. 주 스레드는 모든 스레드가 종료될 때까지 주기적으로 notify_all을 호출한다. 지금 이 코드는 조건 함수가 없기 때문에 무정부 상태나 다름 없다. 어떻게 하면 항상 wait 중이었던 스레드만 모두 깨울 수 있을까?


#include <iostream>
#include <thread>
#include <mutex>
#include <condition_variable>
#include <vector>

std::mutex mtx;
std::condition_variable cv;

std::atomic<int> ecount = 0;

// 대기하는 스레드의 함수
void
waitThread(int no)
{
	for (int i = 0; i < 20; ++i)
	{
		if (rand() % 100 < 80)
			continue;

		std::cout << "try wait " << no << std::endl;
		std::unique_lock<std::mutex> lock(mtx);
		cv.wait(lock);
		std::cout << "Wait thread is activated. " << no << std::endl;
	}

	--ecount;
}

int
main()
{
	ecount = 100;

	const int num_threads = 100;
	std::vector<std::thread> threads;

	// 100개의 waitThread 스레드 생성
	for (int i = 0; i < num_threads; ++i)
	{
		threads.emplace_back(waitThread, i);
	}

	while (ecount)
	{
		std::lock_guard<std::mutex> lock(mtx);
		cv.notify_all();
		std::cout << "Wake thread has triggered the condition variable." << ecount << std::endl;

		std::this_thread::sleep_for(std::chrono::milliseconds(100));
	}

	// 모든 스레드가 완료될 때까지 대기
	for (std::thread& th : threads)
	{
		th.join();
	}

	return 0;
}

어쨌든 요는 condition_variable은 spurious wakeup 때문에 복잡한 스레딩 모델에서는 사용할 때 생각보다 많은 주의를 필요로 한다는 점이다. 별 생각 없이 썼다가는 라이브에서 어이 없는 황당한 문제들을 경험할 가능성이 높다.

[ai] 페어 프로그래밍에 관한 단상 feat. ChatGPT

Fri, 01 Dec 2023 00:00:00 GMT

테스트 주도 프로그래밍, 스크럼, 페어 프로그래밍 같은 애자일로 분류되는 많은 방법론들이 있다 좋아하는 것들도 있고 그렇지 않은 것들도 있다. 그중에 특히 극혐하는 것은 스크럼과 페어 프로그래밍이다. 내가 만약 면접 자리에서 궁금한게 없냐는 질문을 받는다면 반드시 물어볼 것이다. 스크럼과 페어 프로그래밍을 하나요? 만약 한다면 강제 사항인가요? 강제 사항이라면 나는 그 회사를 입사하지 않을 생각이다. 그만큼 싫어한다. 일단 스크럼은 차치하고, 오늘은 페어 프로그래밍에 대해서만 알아보자.

개인적으론 페어 프로그래밍이란 메커니즘이 두 페어가 현재 수행하고 있는 과제에 대해서 비슷한 지적 능력을 가졌을 때 그 효과가 절정에 이른다고 생각한다. 그렇지 않고 차이가 일정 수준 이상 난다면 그건 페어 프로그래밍이라기 보다는 도제식 교육이나 수업에 가까워진다고 생각한다. 물론 그렇지 않다는 수많은 연구 결과가 존재한다는 것은 나도 알고있다. 하지만 연구 결과는 연구 결과고 임상은 임상이니까. 내가 현업에서 느낀 심정은 연구 결과와는 많은 차이가 있었다.

그렇다면 두 페어의 실력만 비슷하면 시너지가 날까? 그렇지도 않다. 왜냐면 우리는 사람이기 때문이다. 사람이 뭔가? 아 다르고 어 다르게 느끼는 게 사람이다. 심지어 똑같은 아도 그사람 기분이 어떤지에 따라 몹시 다른 결과를 가져오는게 사람이다. 즉, 둘이서 한 모니터를 바라보며 사이좋게 작업을 하기 위해서는 케미라는 아주 미묘한 성질의 것이 또 잘 맞아야 한다는 말이다.

그렇다면 현실 세계에서 비슷한 지적 능력을 가진 케미가 잘 맞는 파트너를 만나서 페어 프로그래밍을 할 수 있는 확률은 얼마가 될까? 자세히 계산해 보지 않아도 내가 로또에 당첨되는 게 더 빠르다는 생각이다.

이렇게 설명하면 지적 우위를 가진 사람이 꼭 손해를 보는 느낌인 것 같다. 하지만 내가 현실 세계에서 느낀 페어 프로그래밍은 루즈 루즈 게임인 경우가 많았다. 실력이 좋은 사람은 딱히 페어 프로그래밍으로 얻은 이득은 없다고 느끼고 불편했다는 말을 많이 했다. 그런데 재미있게도 실력이 낮아 보이는 프로그래머도 똑같은 얘기를 하는 경우가 많았다. 이 지점이 도제식 교육과 페어 프로그래밍의 차이인 것이다. 도제식 교육이었다면 아마 배우는 사람은 그나마 그래도 만족했을 것이다.

무튼 이런 여타의 이유로 나는 페어 프로그래밍을 싫어했다. 뭐, 지금까지는 말이다. 하지만 올해 2월을 기점으로 세상이 바뀌었다. ChatGPT가 등장한 것이다. 이 친구는 내가 앞서 서술한 페어 프로그래밍의 모든 단점을 단박에 없앤다. 지적 능력은 당연히 나보다 월등하다. 그럼에도 감정이 없고 내가 어떤 쌉소리를 하더라도 화내는 법이 없이 친절하게 알려준다. 그리고 365일 24시간 내내 내가 원할 때 언제든지 나와 함께 코딩할 준비가 돼 있다. 물론 가끔 openai 서버가 다운되긴 한다. 자주 있는 일은 아니니 그럴 땐 쉬면 되겠다.

ChatGPT와 근 9개월 가량 페어 프로그래밍을 함께 하면서 나는 앞선 단점들만 없으면 페어 프로그래밍이 확실히 효과적이라는 생각이 들 게 되었다. 그래서 이제는 입사 면접 자리에서 나에게 뭐가 궁금한지 물어보면 다음과 같이 물어볼 것 같다. 인공지능 사용이 가능한가요? ChatGPT를 지원해 주나요?

아래는 블로그의 테이블 셀 크기를 동적으로 변경하는 자바스크립트 코드를 작성하기위한 ChatGPT와의 대화 일부다. 복사해놓고 다시 보니 이건 페어 프로그래밍이라기보다는 코딩 노예를 고용한 것에 가깝지 않냐는 느낌이 약간 들긴 한다. 어쨌든 이러나 저러나 멋진 신세계다.

내가 인공지능에게 코딩을 배우는 날이 올거라곤 상상 못했다.

ChatGPT와의 페어 프로그래밍이라 쓰고 코딩 시키기

You
gatsby 블로그 마크다운에서 테이블 셀 크기가 3개가 있는데 처음 두개는 너무 작고, 나머지 하나가 너무 커. 적당하게 나눠서 표시되게 만드려면 어떻게 해야 해?

ChatGPT
Gatsby 블로그에서 Markdown 테이블의 셀 크기를 조정하려면 몇 가지 방법을 시도할 수 있습니다. Markdown 자체에는 셀 크기를 직접 조정하는 기능이 없으므로, CSS를 사용하여 스타일을 적용하는 방법이 가장 일반적입니다. 다음은 몇 가지 방법을 소개합니다:

... 중략 ...

CSS
Inline 스타일
자바스크립트 사용

... 중략 ...

You
셀 내용에 따라 다이나믹하게 설정할 수는 없어?

ChatGPT
셀 내용에 따라 테이블 셀 크기를 동적으로 조정하려면 JavaScript를 사용하는 것이 가장 효과적입니다. CSS와 Markdown만으로는 셀의 내용에 반응하여 크기를 조정하는 것이 불가능합니다. JavaScript를 사용하면 셀 내용을 읽고, 그 내용에 따라 적절한 크기를 동적으로 할당할 수 있습니다.

... 중략 ...

document.addEventListener("DOMContentLoaded", function() {
  const table = document.querySelector('.my-table'); // 대상 테이블 선택
  const rows = table.getElementsByTagName('tr');

  for (let row of rows) {
    const cells = row.getElementsByTagName('td');
    for (let cell of cells) {
      const contentLength = cell.textContent.length;
      // 셀의 내용 길이에 따라 셀 크기 조정
      if (contentLength < 10) {
        cell.style.width = '20%';
      } else if (contentLength < 20) {
        cell.style.width = '30%';
      } else {
        cell.style.width = '50%';
      }
    }
  }
});

You
그렇게 하는 거 보다는 각 칼럼의 가장 긴 길이를 각각 구해서 해당 비율로 크기를 설정하는 것이 좋을 거 같아. 그렇게 수정해줘

ChatGPT
셀 내용에 따라 테이블 셀의 크기를 동적으로 조정하기 위해, 각 칼럼의 가장 긴 셀의 내용을 기준으로 크기를 결정하는 접근 방법을 사용할 수 있습니다. 이 방법은 JavaScript를 사용하여 구현할 수 있으며, 다음 단계로 구성됩니다:

... 중략 ...

document.addEventListener("DOMContentLoaded", function() {
  const table = document.querySelector('.my-table'); // 대상 테이블 선택
  const rows = table.getElementsByTagName('tr');
  let maxContentLengths = [];
  let totalMaxLength = 0;

  // 각 칼럼의 최대 길이 계산
  for (let row of rows) {
    const cells = row.getElementsByTagName('td');
    cells.forEach((cell, index) => {
      const contentLength = cell.textContent.trim().length;
      maxContentLengths[index] = Math.max(maxContentLengths[index] || 0, contentLength);
    });
  }

  // 전체 최대 길이 계산
  totalMaxLength = maxContentLengths.reduce((acc, length) => acc + length, 0);

  // 각 칼럼에 비율에 따른 너비 설정
  for (let row of rows) {
    const cells = row.getElementsByTagName('td');
    cells.forEach((cell, index) => {
      const widthPercentage = (maxContentLengths[index] / totalMaxLength) * 100;
      cell.style.width = `${widthPercentage}%`;
    });
  }
});

You
cells.forEach is not a function 오류가 발생해

ChatGPT
cells.forEach is not a function 오류가 발생하는 이유는 getElementsByTagName 메서드가 반환하는 HTMLCollection 객체가 Array가 아니기 때문에 forEach 메서드를 지원하지 않기 때문입니다. 이 문제를 해결하기 위해, Array.from 메서드를 사용하여 HTMLCollection을 배열로 변환하거나, 전통적인 for 루프를 사용할 수 있습니다.

... 중략 ...

document.addEventListener("DOMContentLoaded", function() {
  const table = document.querySelector('.my-table');
  const rows = Array.from(table.getElementsByTagName('tr'));
  let maxContentLengths = [];
  let totalMaxLength = 0;

  // 각 칼럼의 최대 길이 계산
  rows.forEach(row => {
    const cells = Array.from(row.getElementsByTagName('td'));
    cells.forEach((cell, index) => {
      const contentLength = cell.textContent.trim().length;
      maxContentLengths[index] = Math.max(maxContentLengths[index] || 0, contentLength);
    });
  });

  // 전체 최대 길이 계산
  totalMaxLength = maxContentLengths.reduce((acc, length) => acc + length, 0);

  // 각 칼럼에 비율에 따른 너비 설정
  rows.forEach(row => {
    const cells = Array.from(row.getElementsByTagName('td'));
    cells.forEach((cell, index) => {
      const widthPercentage = (maxContentLengths[index] / totalMaxLength) * 100;
      cell.style.width = `${widthPercentage}%`;
    });
  });
});

You
table 이 하나도 없는 경우에 예외 처리해줘

ChatGPT
테이블이 없는 경우에 대한 예외 처리를 추가하려면, 먼저 테이블 요소의 존재 여부를 확인하는 로직을 추가해야 합니다. 이를 위해 document.querySelector로 선택한 테이블 요소가 null인지 확인하는 간단한 조건문을 사용할 수 있습니다. 테이블이 존재하지 않는 경우, 함수의 실행을 중단하거나 적절한 메시지를 표시하도록 할 수 있습니다.

... 중략 ...

You
table에 tr이나 td가 하나도 없는 경우도 예외 처리가 필요할 거 같아.

ChatGPT
테이블에 tr이나 td 요소가 하나도 없는 경우에 대한 예외 처리를 추가하는 것은 좋은 접근입니다. 이를 위해서는 tr 요소의 배열이 비어있는지, 그리고 각 tr 내의 td 요소가 존재하는지를 확인하는 조건문을 추가해야 합니다. tr이나 td 요소가 없는 경우에는 함수의 실행을 중단하거나 적절한 경고 메시지를 표시할 수 있습니다.

... 중략 ...

You
Array.from(null);은 정의돼 있어?

ChatGPT
Array.from(null)은 정의되어 있지 않습니다. Array.from 함수는 유사 배열 객체나 반복 가능한 객체를 새로운 배열 인스턴스로 만드는 메서드입니다. 그러나 null은 반복 가능한 객체가 아니기 때문에 Array.from(null)을 사용하려고 하면 오류가 발생합니다.

따라서 Array.from을 사용하기 전에 반드시 해당 객체가 null이 아닌지 확인해야 합니다. 예를 들어, document.getElementsByTagName나 document.querySelectorAll과 같은 DOM 메서드가 비어있는 NodeList를 반환할 경우, 이를 배열로 변환하기 전에 null 여부를 검사해야 합니다.

You
그렇게 수정해서 함수 새로 작성해줘

ChatGPT
앞서 논의한 내용을 바탕으로, 테이블에 tr이나 td가 없는 경우에 대한 예외 처리를 포함한 새로운 JavaScript 함수를 작성하겠습니다. 이 함수는 테이블이 존재하고, 적어도 하나의 tr과 td가 있는 경우에만 셀 크기 조정 로직을 실행합니다.

... 중략 ...

You
비율이 너무 낮은 셀이 나오면 문제가 될 거 같아서 최소 15% 이상은 보장되도록 코드를 수정해줘

ChatGPT
셀의 너비 비율이 너무 낮아지지 않도록 최소 15% 이상의 너비를 보장하는 로직을 추가하겠습니다. 이를 위해 각 셀의 계산된 비율을 검사하고, 만약 그 비율이 15% 미만인 경우 15%로 조정하는 로직을 추가합니다. 또한, 이러한 조정으로 인해 총 너비 합계가 100%를 초과하지 않도록 전체 너비의 합을 다시 계산해야 합니다.

다음은 수정된 코드입니다:

document.addEventListener("DOMContentLoaded", function() {
  const table = document.querySelector('.my-table');

  if (!table) {
    console.log('테이블이 존재하지 않습니다.');
    return;
  }

  const rows = Array.from(table.getElementsByTagName('tr'));

  if (rows.length === 0) {
    console.log('테이블에 행이 없습니다.');
    return;
  }

  let maxContentLengths = [];
  let totalMaxLength = 0;
  let isCellPresent = false;

  rows.forEach(row => {
    const cells = Array.from(row.getElementsByTagName('td'));

    if (cells.length > 0) {
      isCellPresent = true;
    }

    cells.forEach((cell, index) => {
      const contentLength = cell.textContent.trim().length;
      maxContentLengths[index] = Math.max(maxContentLengths[index] || 0, contentLength);
    });
  });

  if (!isCellPresent) {
    console.log('테이블의 행에 셀이 없습니다.');
    return;
  }

  totalMaxLength = maxContentLengths.reduce((acc, length) => acc + length, 0);

  let widthPercentages = maxContentLengths.map(length => (length / totalMaxLength) * 100);
  let adjustedPercentages = widthPercentages.map(width => Math.max(width, 15));
  let adjustedTotal = adjustedPercentages.reduce((acc, width) => acc + width, 0);

  rows.forEach(row => {
    const cells = Array.from(row.getElementsByTagName('td'));
    cells.forEach((cell, index) => {
      const adjustedWidth = (adjustedPercentages[index] / adjustedTotal) * 100;
      cell.style.width = `${adjustedWidth}%`;
    });
  });
});

You
그런데 저렇게 작성했다고 하면 예를 들어 칼럼이 세개고 비율이 5, 5, 90이었는데 조정을 해서 15, 15, 90이 되었다고 한다면 최종적으로 첫번째 칼럼은 15 / 120이 되서 12.5%가 되니까 원래 요구했던 15%보다 작게 설정되는 거 아냐?

ChatGPT
맞습니다. 코드에서 조정된 비율이 15%, 15%, 90%로 변경된 경우, 총합이 120%가 되어 각 비율을 다시 조정할 때, 원래 의도했던 최소 15% 비율이 보장되지 않을 수 있습니다. 이 문제를 해결하기 위해, 조정된 비율의 합이 100%를 초과할 경우에 대한 추가적인 처리가 필요합니다.

비율을 조정하는 과정에서, 각 칼럼의 비율이 최소 15%가 되도록 하면서도 전체 합이 100%를 넘지 않도록 조정하는 방법은 다음과 같습니다:

먼저, 모든 칼럼의 비율을 계산합니다. 15% 미만인 칼럼의 비율을 15%로 조정합니다. 조정 후 총합이 100%를 넘는 경우, 15% 이상인 칼럼들의 비율을 적절히 감소시켜 총합이 100%가 되도록 합니다. 이 과정은 비교적 복잡할 수 있으며, 특히 칼럼의 수나 비율에 따라 다양한 시나리오를 고려해야 할 수 있습니다. 간단한 해결책으로, 모든 칼럼이 최소한 15%를 차지할 수 있도록 고정된 비율을 설정하거나, 동적으로 비율을 조정하는 더 복잡한 알고리즘을 구현할 수 있습니다.

You
말로 하지 말고 그렇게 코드를 작성해줘

ChatGPT

... 중략 ...

document.addEventListener("DOMContentLoaded", function() {
  const table = document.querySelector('.my-table');

  if (!table) {
    console.log('테이블이 존재하지 않습니다.');
    return;
  }

  const rows = Array.from(table.getElementsByTagName('tr'));

  if (rows.length === 0) {
    console.log('테이블에 행이 없습니다.');
    return;
  }

  let maxContentLengths = [];
  let totalMaxLength = 0;
  let isCellPresent = false;

  rows.forEach(row => {
    const cells = Array.from(row.getElementsByTagName('td'));

    if (cells.length > 0) {
      isCellPresent = true;
    }

    cells.forEach((cell, index) => {
      const contentLength = cell.textContent.trim().length;
      maxContentLengths[index] = Math.max(maxContentLengths[index] || 0, contentLength);
    });
  });

  if (!isCellPresent) {
    console.log('테이블의 행에 셀이 없습니다.');
    return;
  }

  totalMaxLength = maxContentLengths.reduce((acc, length) => acc + length, 0);

  let widthPercentages = maxContentLengths.map(length => (length / totalMaxLength) * 100);
  let adjustedPercentages = widthPercentages.map(width => Math.max(width, 15));
  let adjustedTotal = adjustedPercentages.reduce((acc, width) => acc + width, 0);

  // 총합이 100%를 초과하는 경우, 초과분을 줄이는 로직
  if (adjustedTotal > 100) {
    let excess = adjustedTotal - 100;
    adjustedPercentages = adjustedPercentages.map(width => {
      if (width > 15 && excess > 0) {
        let decrease = Math.min(width - 15, excess);
        excess -= decrease;
        return width - decrease;
      }
      return width;
    });
  }

  rows.forEach(row => {
    const cells = Array.from(row.getElementsByTagName('td'));
    cells.forEach((cell, index) => {
      cell.style.width = `${adjustedPercentages[index]}%`;
    });
  });
});

[일상] 2023년 11월의 잡담

Thu, 30 Nov 2023 17:36:00 GMT

#0

hwp 노션 이력서 안본다는 사람들이 많은데 굳이 구직자가 해당 포맷을 쓰겠다는 건 구직 의사가 낮은게 아닌가 싶다. 속도보다 방향이 중요하다는 말처럼 노오오력도 어느 방향으로 투자했냐가 중요한거 아닌가 싶다. 마치 시험에 미적분 안나온다고 했는데 미적분 공부하는 느낌이랄까?!

2023-11-01

#1

인생은 채워지지 않은 욕망으로 인해 느끼는 고통과, 욕망의 충족 이후에 들어서는 권태 사이를 오락가락하다가 죽음으로 끝나는 것에 불과하다. - 사는 게 고통일 때, 쇼펜하우어

괜히 철학자가 아니다. 이토록 간단 명료하고 반박 불가능한 인생에 대한 정의라뉘. 고통과 권태 사이를 오가는 시계추라...

2023-11-03

#2

구글, 깃헙에 이어 어느새 chatgpt가 꺼지면 코딩하기 불편한 세상.

2023-11-08

#3

[cs] msbuil로 C# 프로젝트 빌드 시 project.assets.json 오류 해결 방법

Thu, 30 Nov 2023 00:00:00 GMT

msbuild project.sln -m -t "cslib" -p:Configuration=Release -p:Arch=AnyCPU

우리는 대략 이런 커맨드로 msbuild를 사용하고 있었다. project.sln에는 다수의 프로젝트가 포함되어 있고, cslib 그 중에 하나인 c# 프로젝트였다. 그런데 이상한게 Visual Studio에서 빌드하면 멀쩡하게 빌드가 잘되는데 msbuild로만 실행하면 project.assets.json 파일이 없다며 오류가 발생했다.

첫번째 문제는 경로였다. 우리는 프로젝트의 중간 파일과 출력 파일을 다른 경로로 지정해놓고 사용했는데 nuget이 생성하는 project.assets.json 파일은 그 경로가 아닌 디폴트 경로를 참조하는 것 같았다. 이를 해결하기 위해서는 cslib 프로젝트 파일이 있는 경로에 Directory.Build.props 파일을 생성한 다음 아래와 같이 설정해 주면 된다.

<Project>
  <PropertyGroup>
    <BaseIntermediateOutputPath>경로</BaseIntermediateOutputPath>
  </PropertyGroup>
</Project>

경로에는 C# 프로젝트에서 설정한 것과 동일한 중간 파일 경로를 입력하면 된다. $(SolutionDir) 같은 변수도 지원하기 때문에 그대로 사용하면 된다.

이제는 잘 되겠지?! 하고는 했는데 여전히 되지 않았다. 온갖 오류 메시지를 하나씩 추적하면서 수정하는 온갖 삽질을 ChatGPT와 함께하고 알게 되었다. project.sln 파일이 AnyCPU에 대해서 정상적으로 설정돼 있지 않으면 nuget이 project.assets.json 파일을 생성을 못한다. 예를들어 포함된 test 프로젝트가 AnyCPU에 대해서 빌드 설정이 체크되어 있지 않으면 생성이 되지 않는 식이다. 또는 솔루션 파일에 포함된 구성 요소 프로젝트가 없어도 생성이 되지 않는다. 이런 모든 원리를 살펴보면 위 커맨드를 수행할 때 아래 커맨드가 먼저 수행되는 것으로 보여진다.

msbuild project.sln -t "restore"

즉, 솔루션 전체를 복원하는 것이다. 나는 cslib만 빌드하고 싶을 뿐인데 말이다. 그래서 ChatGPT와 함께 열심히 찾아 보았지만 개별 프로젝트를 복원하는 방법은 없어 보였다. 그렇다면 어쩌지?! 솔루션을 멀쩡하게 만들어야 하나? 그러기엔 외부 참조가 많아서 빌드서버에서 clone해야 할게 너무 많아지는 문제가 있었다. ChatGPT는 다음과 같은 방법을 나에게 대안으로 알려주었다.

msbuild cslib.csproj -m -t "restore,rebuilt" -p:Configuration=Release -p:Arch=AnyCPU

오 역시 ChatGPT. 바로 이거였어, 하고는 테스트를 했는데 한가지 추가적인 문제가 있었다. $(SolutionDir)이었다. 이는 프로젝트 파일을 직접 참조하기 때문에 $(SolutionDir)이 정의되지 않은 상태인 것이다. 다시 ChatGPT를 독촉하자. 완벽한 커맨드를 알려주었다.

msbuild cslib.csproj -m -t "restore,rebuilt" -p:Configuration=Release -p:Arch=AnyCPU -p:SolutionDir=path/to/solution

얼마간 삽질했지만 정상적으로 빌드되도록 만들 수 있었다.

[시스템] CloudFlare Pages 수동 배포 방법

Wed, 29 Nov 2023 12:00:00 GMT

CloudFlare Pages를 자동 배포가 먹통이라 수동으로 배포해야 할 때는 아래 명령어를 사용하면 된다.

curl -X POST "https://api.cloudflare.com/client/v4/accounts/<account_id>/pages/projects/<worker_name>/deployments" \
-H "Authorization: Bearer <token>"  \
-H "Content-Type:application/json"

<account_id>는 cloudflare pages 화면의 아래 빨간 네모로 표시된 위치에 값이 있다.

<worker_name>은 자신의 페이지 프로젝트 이름을 입력하면 된다.

은 발급받은 api 토큰을 넣어주면 된다.

호출에 성공하면 대시보드에서 빌드가 진행되는 것을 볼 수 있다.

[일상] jiniya.net 리마스터링

Tue, 28 Nov 2023 00:00:00 GMT

#0

20대 어느 날 중고등학생 때 썼던 일기장을 모두 버린 기억이 있다. 본가에 두고 온 일기장을 누나가 읽었다며 놀린 게 계기가 되었다. 그 얘길 듣고 그걸 전부 자취방으로 가지고 왔었다. 내가 다시 읽어봐도 워낙 오글거려서 그날로 다 버렸다. 그때는 몰랐다. 데이터가 얼마나 소중한지. 그 글들이 내가 유일하게 추억할 수 있는 그 시절 나의 생생한 모습이란 사실도 말이다.

일기장을 버린지 근 20년이 되어간다. 가끔 그때 버린 일기장이 기억날 때가 있다. 오글거리긴 해도 가끔 그시절 내가 어떤 생각을 했고, 어떤 고민을 했는지가 궁금할때가 있는 것이다. 물론 나이가 들어서일수도 있다.

#1

올해 이글루란 블로그 서비스가 문을 닫는다는 소식이 들렸다. 어렸을 때 그곳에 적잖게 글을 썼던지라 들어가 보았다. 2004-5년 학생 시절에 쓴 글들이 많이 있었다. 웃기기도 하고, 이렇게 살았구나 싶기도 했다. 같은 실수를 두번하지 않기 위해서 이번에는 데이터가 삭제되기 전에 모두 백업을 했다.

#2

이 블로그를 시작할 때만해도 내가 이걸 8000일이 넘는 시간동안 운영하게 될 거라곤 생각하지 못했다. 다만 조금 아쉬운 점은 자작 게시판, phpBB, 태터툴즈, 워드프레스, 지킬을 거치면서 얼마간은 데이터가 유실되었다는 점이다. 예전엔 데이터가 소중한지도 몰랐었고, 나중에 그게 아쉬울지도 몰랐다. 어쨌든 그런 일들을 겪고 보니 이제라도 한번 전체를 다시 재정비를 해야겠다는 생각이 들었다.

기존에 파편화되어 있던 글들을 한곳에 다 모으기로 했다. 대체로 모을 수 있는 모든 글들을 모았다. 그리고 그렇게 모은 글들은 다시 다듬었다. 소위 블로그 리마스터링이라고 부를만한 작업을 했다.

#3

작업을 하기에 앞서서 gatsby 템플릿을 변경할 필요가 있었다. 기존 템플릿이 너무 단촐해서 글을 너무 많이 담기에는 다소 무리가 있어 보였다. 여기저기 구경하던 중 hudi 님께서 만든 템플릿이 좋아 보였다. 디자인도 멋지고, 반응형에, 태그와 시리즈를 지원하는 멋진 템플릿이었다.

템플릿을 교체하는 과정도 순탄하지만은 않았다. gatsby에 g도 모르는 입장이라 오류가 발생하면 뭐가 문제인지도 몰랐으나 오류 메시지를 복붙하면 대체로 ChatGPT가 다 해결해 주었다.

기존 글들을 정리하면서 느낀 가장 큰 재앙은 오래된 글에 있는 링크는 거의 모두 사라졌거나 동작하지 않는다는 사실이었다. 퍼가는 사람들이 왜그럴까 했는데 이해가 되는 지점이었다. 그래서 나는 대체로 기존 링크를 유지할 수 있으면 유지하기로 결정했다. 이 기능도 템플릿을 고쳐서 가능했는데 gatsby의 유연한 시스템과 ChatGPT의 어시스트로 가능했다. 어쨌든 기본적인 프레임워크는 다 준비된 것 같아서 이제 글을 옮기기로 했다.

#4

시작은 최근 데이터부터 시작했다. 단순 무식하게 카피앤페이스트로 지킬의 데이터를 다 옮겼다. 이것도 수작업으로 하니 생각보다 힘든 작업이었다. 그리고 남은 글들을 보았다. 워드프레스와 태터툴즈만 합쳐도 1000개가 넘는 글이 남아 있었다. 와 이거 노답인데 하는 생각도 순간, 나에게는 ChatGPT가 있었다.

자동으로 긁어서 마크다운으로 변환해서 파일로 저장하는 스크립트를 작성하라고 시켰다. ChatGPT는 나를 실망시키는 법이 없다. 녀석이 작성해준 코드는 기가 막히게 동작했고, 나는 제로 콜라 하나를 다 마시는 동안 모든 페이지가 마크다운으로 변환되는 기적을 맛보았다.

그러고 나니 텍스트는 거의 다 저장되었는데 페이지에 포함된 이미지가 문제였다. 다시 ChatGPT에게 물었다. 녀석은 마크다운으로 변환하는 페이지에 포함된 이미지까지 모두 다운로드 받아서 저장해주는 스크립트를 안겨주었다. 올레~

#5

물론 23년 가까이 쓴 글들은 지금 돌아보면 우습고 부끄럽고 이불킥하고 싶은 글들이 많다. 하지만 그런 것들도 다 나의 일부라 생각하고, 추억이기에 보존하기로 했다.

그렇게 모아진 글들만 1200개가 넘는다. 없애지 않고 지금까지 잘 보존해준 과거의 나에게 감사함을 표한다. 그덕에 나는 존경해 마지 않는 레이몬드 첸 아저씨보다 블로그를 오래한 몇 안되는 프로그래머 중에 한 명이 되었다.

#6

나는 더는 스타크래프트를 즐기지 않고, 와우를 미친 듯이 하지 않는다. 킹 오브 파이터즈를 하러 오락실을 찾지도 않고, 무한도전이나 러닝맨 같은 예능을 즐겨 보지도 않는다. 일요일 밤을 마감하는 웃찾사나 개그콘서트같은 개그 프로를 안 본지도 오래됐다. 과자를 자주 먹지도 않는다.

긴 세월 만큼이나 나란 사람도 정말 많이 변했다. 하지만 그렇게 많은 세월이 지났어도 나는 여전히 여기에 글을 쓴다. 어쩌면 이게 내가 코딩을 제외하고 본질적으로 거의 유일하게 좋아하는 일인지도 모르겠다는 생각이 들었다.

주춤했던 최근을 넘어서 앞으로는 그래도 종종 글을 남기겠다는 다짐을 해본다.

[일상] 2023년 10월의 잡담

Fri, 20 Oct 2023 22:45:55 GMT

#0

학교 졸업장, 기업의 사원증 같은 것은 이제 성취 인증 시스템에서 구시대적 유물로 통할 날이 머지않았습니다. 검증된 깃허브의 스코어나 블로그의 구독자, 인스타그램의 달리기 기록처럼 ‘측정된 권위’를 쌓아가는 것이 필요합니다.

시대예보: 핵개인의 시대 중에서

2023-10-15

#1

집에 pc를 새로 사고 온갖 설정을 바꿔도 마우스 랙이 있어서 뭔가 했더니 케이블 문제. 노트북 연결해서 쓸때는 디피였는데, pc로 바꾸면서 hdmi를 쓴 게 문제였다. 케이블 하나 갈았더니 랙이 사라졌다. 30/60차이도 이정도면 144hz는 어떤 느낌인 것인가?!

2023-10-16

#2

인공지능은 예술을 하고 사람은 청소나 빨래같은 노동이나 하는 세상이 아니라 모든 사람이 화가, 작가, 작곡가, 프로그래머가 되는 세상이 온 게 아닌가 싶다. 탐라에 돌아다니는 4컷 만화들만 봐도 이를 알 수 있다. 단돈 20불에 이 모든게 가능한 세상이라뉘 ㅎㅎ

2023-10-16

#3

남들보다 잘하는 건 고사하고 남들만큼 하는 거도 참 어렵다.

2023-10-20

[일상] 2023년 9월의 잡담

Mon, 18 Sep 2023 11:06:51 GMT

#0

게임 보안 솔루션 개발, ,c++/rust 시스템 프로그래머 모집합니다. https://m.jobkorea.co.kr/Recruit/GI_Read/42833706

2023-09-08

#1

지인이 신세계 상품권을 줬는데 쓸때가 없어서 고가의 뱅앤올룹슨 무선 이어폰을 사고 나서 알았다. 1) 블투는 음향기기가 아니라 소프트웨어. 페어링 잘 안되고, 된다음에도 겁나 튐. 노캔은 말해뭐해. 2) 걍 에어팟 맥스 살걸 3) 신세계 상품권 따위보단 쿠팡캐시가 훨씬 유용한 세상이 됐다.

2023-09-13

#2

난 유니티가 게임 외주 개발을 한다는 소릴 듣고 어렵구나 했는데, 작금의 사태를 보자니 더 어려운거 같다는 생각이. 하스스톤같은 카드 게임을 유니티가 직접 만든게 많다고 한다. 실제로 하스스톤도 블리자드 외주로 유니티가 개발했다는 썰이. 킹비디아 말고는 다들 힘든 계절인듴...

2023-09-15

#3

대단한 개발자가 아니라도 충분히 잘 먹고 잘 살 수 있다. 시장이 그만큼 커졌기 때문이다. 그래서 직업인 개발자도 나쁘게 생각하지 않는다. 자기 밥값만 한다면 뭔들. 어느 직업이든 좋아하면서 잘하는건 디폴트가 아니라 굉장한 행운이다.

2023-09-18

[일상] 2023년 7월의 잡담

Sat, 29 Jul 2023 10:31:05 GMT

#0

행복에 절대적인 영향을 미치지만, 대부분이 미처 생각지 않는 요인에 대해 살펴보려 한다. 어떤 것이 그렇게 중요할까? 오랫동안 행복을 연구한 석학들을 한 자리에 모아놓고 그 질문을 한다면 대답은 거의 비슷할 것이다.
“유전. 더 구체적으로는 외향성.” - <행복의 기원>, 서은국

거대언어모델에서 파라미터 개수가 일정 수를 넘어서면 나타난다는 새로운 능력은 정말 신기한거 같다. chatgpt가 나를 대신해 모든 걸 결정해 준다면 내가 ai의 아바타가 되는게 아닐까 싶은 생각이. 바보같은 선택을 내가 하는 삶이 나을까, 꼭두각시지만 최적의 선택을 하는 삶이 나을까?

우리 아이들은 더는 점쟁이를 찾아가진 않을꺼 같다. 최신 업데이트에 파인 튜닝이 아주 잘된 gpt를 찾아가지 않을까란 생각이...

2023-05-04

#3

최근 신입 포함 직원들의 코딩 능력이 향상됐다는 느낌을 많이 받는데, 물어보면 대체로 백엔드에 지피티가 있는듯. 심지어 본인 비용으로 유료로 쓰는 친구들도 있음. 예전에 2-3일 걸리던 작업이 요새는 2-3시간만에 아웃풋이 나옴. #멋진신세계

2023-05-11

#4

구글 바드 써봤는데 사람들 욕하는거항 다르게 느낌 나쁘지 않은뎅. 좀 늦었지만 역시 ai명가 구글인가?!

2023-05-11

#5

회사에 외계인과 접선한게 아닌가 싶을 정도로 분석을 잘하는 친구가 한 명 있다. 볼때마다 그런 생각이 든다. 이런게 운이군?!

2023-05-16

#6

제가 물려받고 싶었던 건 권력이 아니라 자부심이었습니다. 아버님께서 틀리셨습니다. - 조선 변호사 ep16

2023-05-31

#7

git 저장소에 컨플릭트가 발생한 개발자에게 chatgpt가 force push를 알려줘서 저장소를 깨먹었다. 사람들은 chatgpt를 비난한다. 20년전 부사수였던 개발자는 컴파일이 안된다는 질문을 devpia에 올려서 답변을 받고는 windows.h를 고쳐서 컴파일하는 사건이 있었다. 인공지능이 문제가 아니다.

2023-05-31

공감. 경험상 코딩 잘하는게 소통 잘하는 능력보다 희소함. 심지어 연차가 오를수록 더 심해지는듯한 느낌. 둘다 잘해야겠지만 코딩을 잘하면 사실 소통할 거리도 줄어듬. 회사내 개발자가 소통한다는게 대체로 원하는 기한에 원하는대로 만들어주질 못해서 발생하는 경우가 많기 때문. https://x.com/pakyoungrok/status/1648993523889487872

이런 이유로 나이가 들면 대체로 매니저로 가는 경우가 많고 계속 개발을 하는 경우는 드문게 아닌가 싶다. 실제로 해외든 국내든 개발자 분포를 보면 나이가 올라갈수록 인원이 확 줄어드는 경향이 있음. http://www.jiniya.net/wp/archives/8185

2023-04-21

#9

격하게 공감. 나만 그런건 아니었다는데서 위안을,, https://x.com/iron4gg/status/1649069970599587843

2023-04-21

#10

안전 벨트를 메는 것은 좋은 습관이다. 약간의 불편함으로 사고를 헷지할 수 있기 때문. 그럼에도 사람들은 당장의 편익은 눈에 보이고, 사고 확률은 낮고 멀리 있기 때문에 당장 편리한 미착용을 선택 하는경우가 더러 있다. 내가 선택하는 일이 안전벨트를 메는건지 푸는건지 돌아보면 도움이 된다.

2023-04-23

#11

4번 공감. 나이, 성별을 떠나서 과거의 영광에 집착하는 사람치고 현재가 멀쩡한 사람을 거의 못본거 같다. https://x.com/economakase/status/1650458091111211009

2023-04-24

#12

이 문제에 정부도 일정부분 책임이 있다고 느끼는건 중기청년전세대출 같은거. 1억까지 1프로대 금리로 제공. 딱히 보증 물건의 담보 능력을 정부가 따지지도 않음. 저게 생기고 썩다리 원룸도 전세가 1억으로 상향 평준화됨. 조건되는 입장에서 보면 정말 달콤한 공짜점심처럼 보이는게 팩트 ㅠㅜ https://x.com/moomini00/status/1650525499389804544

부동산 열풍에 묻지마 무자본 갭투자에 나선 투기꾼들, 저리에 유동성을 공급한 정부, 벼락거지된것 같은 느낌에 너도나도 빚투에 나선 청년들, 이 모든게 합쳐져서 지금 청구서가 날아오는게 아닌가 싶다. 어쨌든 공짜 점심은 없다.

2023-04-25

#13

Gpt4, 3시간 25개면 쓰지 말라는 소린가? Gpt4쓰다가 3.5쓰니까 갑갑하네. 12개로 낮추고 안쓸때 충전되는 시스템이면 더 좋을듯.

2023-04-30

[일상] 2023년 3월의 잡담

Fri, 31 Mar 2023 15:38:54 GMT

#0

탐라를 보면서 요즘도 연차 쓰면서 눈치 본다거나, 개수대로 다 쓰지도 못하는 회사가 많다는 사실에 놀랐다. 다들 저마다 각자의 세상 속에서 살아가는 것 같다.

2023-03-06

#1

오늘도 여기에 진실을 적지 않는다. 진실을 적지 않는 것이 진실이기에. - 친구 일기장,,

2023-03-07

#2

1년간 아무도 못 풀었던 문제를 21살 신입 사원이 이틀만에 명쾌한 정답을 찾아냈을 때의 기분은 좋을까? 당황스러울까? 채용을 잘했거나, 억세게 운이 좋았거나. 정말이지 세상은 넓고 용자는 많다.

2023-03-09

#3

이젠 선배가 흑잡는 거예요. 처음이니까. 착수는 내가 할께요. - 더 글로리 ep.16

2023-03-11

#4

어떤 싸움은 한쪽은 얻을거만 있고, 한쪽은 잃을거만 있는 경우가 있다. 손자병법을 따르자면 이 경우 후자는 싸우지 않는 것이 이득이겠지만 삶이 또 그리 간단치는 않은법. 후자의 입장에서 싸우게 된다면 좋은 전략은 무엇일까? 최근 마소, 구글의 인공지능 검색 시장 싸움도 비슷해보이는.

2023-03-11

#5

페친 가라사대, 조만간 다들 자비스 하나씩 가지고 사는 세상이 될 것이다. 하지만 당신이 토니 스타크처럼 멋지게 살 가능성은 아주 희박하다. 아침부터 뼈때리는 진실.

2023-03-23

#6

그러나 실제로 무일푼이 되지 않으려면 생각을 이렇게 바꿔야 합니다. '이번 투자는 상각해버리고 나중에 다시 도전해야겠어. 여기에 집착할 필요 없어. 자칫하면 내가 다쳐.' - 찰리 멍거 바이블

2023-03-25

#7

한때 ms가 백신 업체들 모아놓고 충돌 테스트를 해주던 때가 있었다. 디펜더가 천하통일하고 백신이 잠잠해지니 요새는 그 자리를 안티치트가 꿰찼다. macp라는 ms 안티치트 호환성 프로그램이 생김. 게임은 몹시 중요하고, 안티치트는 넘나 말썽꾸러기고 라는 ms형님들의 입장이 반영된 프로그램.

2023-03-28

#8

생각보다 빵터짐. https://codingmoonhak-library.oopy.io/

2023-03-31

[일상] 2023년 2월의 잡담

Tue, 28 Feb 2023 19:31:08 GMT

#0

웃겼다 ㅋㅋㅋ 뭔가 러스티안의 성향을 잘 반영한 조크인듴... https://t.co/C9QTo8aSIE

2023-02-02

#1

2006년 회사를 창업후 지금까지 내가 회사에서 느낀것들. 1) 복지를 늘리는 행위가 생산성 향상에 직접적으로 큰 도움을 주지는 않는다. 2) 높은 복리후생이 일류를 채용할 수 있는 길을 제공하지도 않는다. 3) 맥도날드 햄버거 조립라인에 쉐프를 고용할 필요는 없다.

시간이 지난다고 모두가 성장하지는 않는다. 5) 어떤 자리든 장이란 자리는 1이라도 똑똑한 사람이 맞는게 좋다. 6) 생산성을 저해하는 요소는 어떻게 포장해도 생산성을 저해한다. 7) 실력이 아무리 뛰어나도 회사에 기여를 하지 않는다면 아무 의미가 없다.
사람 문제로 보이는 내부갈등이 의외로 인간 관계의 문제가 아니라 해결해야할 과제가 역량에 비해 너무 많거나 높은게 원인인 경우가 많았다. 9) 회사 상황이 좋으면 많은 것들이 묻힌다. 10) 반대로 상황이 나쁘면 온갖 것들이 부각된다.

2023-02-03

#2

챗지피티 진짜 텍스트박스는 텍스트에어리어로 변경이 시급하다. 코드 붙여넣을때 개불편...

2023-02-04

#3

ms 진짜 열일한다. 덩치는 공룡임에도 속도는 스타트업,,, https://x.com/delight412/status/1621843423576858624

2023-02-04

#4

동어 반복 주석을 달고 좋은 습관이라고 착각하는 경우가 많은데 제일 흔한 악습이자 비용 낭비. 저장소가 커지면 주석/코드 불일치가 발생하는 것도, 그걸 계속 일치하게 만드는 것도 큰 비용. 무튼 주석은 공짜가 아니니 아껴서 잘 쓰는게 중요한 포인트가 아닐까 싶다.

2023-02-05

#5

주변에 코파일럿, 러스트, 챗지피티 같은 복음을 전파해보면 의외로 반응이 시큰둥하거나 부정적인 경우가 많다. 그렇게 약을 쳐도 아예 시도조차 안해보는 경우가 대다수. 온라인과 오프라인의 온도차가 참 크다.

2023-02-06

#6

챗지피티 플러스 버튼이 생겼길래 설레는 마음으로 들어갔지만 뭔 카드를 넣어도 죄다 거절되는 ㅠㅜ 결제단에서 막아둔건가? 어서 빨리 풀리길...

2023-02-10

#7

https://blog.llvm.org/posts/2021-03-26-the-new-pass-manager/ 왜케 다들 열심히 일하는 것인가?! 뉴 패스 매니저라니. 하위호환성 자비를 업계는 이제 버려 버린듴 ㅠㅜ 공짜로 될 줄 알았던 나의 무지에 당황쓰...

2023-02-11

#8

오올,,, 챗지피티 플러스 한국 결제 풀렸다. 이제 더는 다운됐다는 메시지는 안봐도 되는 것인가?! 귀찮은건 코파일럿이 해주고, 모르는건 챗지피티가 해주고, 나는 컨펌만 하면 되는 멋진 신세계...

2023-02-12

#9

사실 우리나라 전세라는 제도 자체가 폰지 사기와 유사한게 아닌가 싶다. 다음 더 비싼 전세로 들어올 사람이 있어야 돌아가는 구조. 대체로 집주인이 부유하다고 생각하지만 생각보다 대출과 보증금으로 근근히 버티는 경우도 많음. 특히 갭투자. https://x.com/______River____/status/1624613704032727041

2023-02-13

#10

#22

판돈 많다고 이기는 게임도 아니지만, 판돈 없으면 입장 불가한 그들만의 리그. 코드 한줄로 됩니다, 라는 말은 프레임워크에서 수만줄 미리 짜둬서 그렇듯. 내가 물어보면 짹짹 멋진 대답을 내뱉는 gpt 프롬프트 너머에선 어마어마한 자원이 소비된다. 내가 아낀 에너지는 결국엔 어디선가 지출된다. https://x.com/kindtis/status/1628258126549090304

2023-02-22

#23

actix-web으로 간단한 웹서버를 만들다 비동기 처리가 이게 맞나 싶은 부분이 있어서 actix 소스 코드를 좀 살펴봤다. 난 러스트를 이해한게 아니었다. 여긴어디? 난 누구? 코알못이 소스 코드 보는 느낌이 이런 느낌일까 싶은. tokio에서 시작해야 하는건가,,

2023-02-23

#24

송재경님 시대엔 프로그래밍을 잘해야 40대까지 개발자를 하는 경우가 많았지만, 내 또래들은 딱히 잘하지 않아도 거의 대부분 40대까지 개발자를 하고 있다. 직원들도 딱히 실력에 관계 없이 대부분 경력을 잘 유지하는 느낌. 그만큼 이바닥 수요가 늘어난게 아닌가 싶다. http://www.jiniya.net/wp/archives/14748

우리 세대는 벤처 1세대의 꿀단지는 놓쳤지만, 그래도 노코테, 주먹구구식 개발 문화의 덕을 어느 정도는 받았다는 느낌. 그만큼 준비가 안된 사람들도 개발자로 취업하기가 쉽고 좋았다. 지금 최애로 꼽히는 네카라의 네는 심지어 차순위로 가던 애들도 많았다.

코딩을 아주 잘했다면 송재경님 시대가, 그럭저럭 했다면 우리 세대에 태어난게 더 유리했다고 생각한다. 다음 세대는 코딩 실력은 그렇게 중요하지 않을 가능성이 높을거 같은 느낌적인 느낌.

2023-02-27

#25

모든 개발자의 로망 아닐까 싶다. 무소의 뿔처럼 혼자서 지속 가능한 부가가치를 창출 한다는거, 심지어 b2c. 나도 그랬지만 개발자 입장에서 이런 꿈의 가장 큰 좌절 포인트는 개발 난이도 보다는 기획, 마케팅 난이도가 아닐까 싶다. 카피캣 말고는 뭘 만들어야 돈이 되는지를 모른다는게 함정. https://x.com/BenjaminKim_/status/1630407630257807360

재호님 의견대로 인공지능을 포함해 개발 지원 도구들이 너무 좋아져서 역설적이게도 코딩 능력보다는 마케팅, 기획 능력이 훨씬 더 희소해진것 같은 느낌. 1인 개발이란게 옆에서 보면 쉬워보여도 막상 시작해서 마켓에 올려보면 좌절스러운 현실을 직면하는 경우가 많지 않나 싶다.

2023-02-28

#26

빙ai를 써봤다. 챗지피티를 경험해서 그런지 그때 그 감흥은 없다. 역시 뭐든 첫느낌이 강렬하다.

2023-02-28

[일상] 2023년 1월의 잡담

Tue, 31 Jan 2023 15:33:03 GMT

#0

와우 ms미쳤. Bing신이 드디어 재탄생 하는건가?! https://x.com/GeekNewsHada/status/1610808562388987905

2023-01-05

#1

이건 진짜 킹정, 더불어 21세기에 cmake가 천하통일 하고 있다는거에 몹시 큰 자괴감이... https://x.com/junghyun_nam_/status/1610636943578259461

2023-01-05

#2

php 웹서버 코드를 러스트로 컨버팅해보았다. 벤치를 돌렸는데 14배가 빨라졌다. 속도도 속도지만 진가는 네이티브 언어임에도 php나 파이썬만큼 작성하기 편리한 프레임워크가 존재한다는게 아닐까 싶다.

2023-01-16

#3

Url리다이렉션 시키는 코드로 30분 넘게 헤맸다. 엉뚱한 경로로 리다이렉션 되는 문제. 암만봐도 모르겠고 검색을 해봐도 딱히 답이 없었다. 혹시나 해서 chatgpt에 물어봤더니 3초만에 답을 알려주었다. http://www...을 http:://www로 쓴 것. 니가 모를거라고 생각한 나의 거만에 3초간 묵념.

2023-01-19

#4

근래에 발견한 가장 유익한 블로그, 세상은 넓고 용자는 많다... https://x.com/_jeyraof/status/1616117059913658368

2023-01-20

#5

그것이 알고싶다. 빌라왕편을 보고 든 생각. 동일 집주인이 3년이상 소유한 건물만 계약해도 저런 사기는 상당수 피할듯한. 신축이라 매매가가 불명확하고 그래서 전세가가 뻥튀기된걸 세입자가 알 수 없다는 게 문제의 본질. 뻥튀기가 불가능하면 애초에 나눠가질게 없어서 사기꾼들이 붙지를 못함.

2023-01-24

#6

코딩봇이라며 아두이노로 진행하는 코딩 교육이 늘고 있는데 갠적으론 반대. 코드랑 회로랑 동시에 잘 만들어야해서 더 어려움. 걍 고전적인 gw베이직으로 원넓이, 삼각형 높이 구하는거 시키는게 더 나았다는 생각. Chatgpt 이후론 과연 코딩 교육이 얼만큼 의미있을지도 의문.

어쩌면 시작부터 chatgpt와 협업하는 걸 가르치는게 더 나을지도. 어떻게 잘 부려먹는가가 대세가 되는 시대가 될지도 모르니까. 20년 후에 얘들은 뭐해먹고 살지 몹시 궁금. 그런거보면 부모 세대나 우리 세대나 미래에 대해 무지하기는 똑같다. 닥공부 외치던 세대나 영어, 코딩 시키는 세대나.

2023-01-25

#7

자녀 코딩 교육으로 고민하는 인문과 친구에게 chatgpt의 존재를 알려주었다. 아바타2 관련 질문을 하고는 답변하지 못하는걸 통쾌해한다. 대다수 사람들의 반응은 얼추 비슷한듯.

2023-01-25

#8

실력있고 인간안된 개발자나, 성실하고 착한데 실력 없는 개발자나 둘다 함께하기는 힘들다는 생각. 돈받고 하는 일이니 개발력이 기본 허들은 넘어야 하고, 함께 하는 일이니 인간성도 기본은 갖춰야 하는게 아닐지.

2023-01-27

#9

신입 키워놓으면 딴 회사 간다는 말은 정말 난센스. 조건 좋은데 생기면 이직하는게 인지상정 아닌가? 노사관계는 계약 관계 이상도 이하도 아니다. 거기에 더 많은 의미를 넣으면 피차 피곤해진다. 그리고 요즘 it 바닥에서 키운다 만다도 엔지. 경력보다 잘하는 신입이 부지기수다.

2023-01-27

#10

구글과 메타가 챗지피티 수준의 것을 가지고 있지만 비지니스에 득이되지 않아 공개를 못한다는 얘기와 관련해서 구글은 인정이가지만 메타는 뭐가 있었나 싶다. 공개하는 ai 모델마다 다 망하지 않았나 싶은?!

번외로 챗지피티를 쓰면 쓸수록 장기적으로 구글엔 정말 치명적일거 같은 느낌. 나만해도 벌써 선챗지피디. 거의 대부분 해결. 안된건 걔가 알려준 내용 중에 키워드 뽑아 구글 검색으로 대체로 바뀐듯. 그런 점에선 openai에 돈 들이붓는 ms가 위너일지도...

2023-01-29

#11

간만에 밀리 들어갔더니 ai tts가 추가됐다. 진짜 요즘 세상이 미친듯이 바뀌는 중인듯. 사람이 한다는 것에 관한 생각들이 많이 바뀔거 같다. 난 신년사를 ai가 써도 무방하다고 생각한다. 지금은 인간이 가이드라인이라도 주지만, 나중에는 그마저도 없겠지. 유발하라리가 말한 것처럼.

그 결과 직업시장 또는 결혼시장에서의 성공이 점점 더 코타나의 자질에 따라 판가름날 것이다. 그래서 최신 버전의 코타나를 소유한 부자들은 구버전을 소유한 가난한 사람들보다 결정적 우위를 점할 것이다. - 호모데우스, 유발하라리

2023-01-29

#12

간단한 자바스크립트 작성할 일이 있어 데이터 10개 중에 2개 정도 코드만 작성하고 나머지는 인턴한테 시켜야지 했는데. 챗지피티에게 보여주고 짜라고 하자 나머지 코드를 완전하게 다 작성해 주었다. 이제 인턴이 할 일은 검수 또는 2021년 이후 데이터를 조사하는 일 밖에는 없는 걸까?

2023-01-31

#13

챗지피티 수학 기능 업데이트 됐데서 2022년 수학능력시험 수학 문제 하나 넣어봤는데 정답을 맞췄 ㄷㄷㄷ

2023-01-31

[일상] 2022년 12월의 잡담

Wed, 28 Dec 2022 01:14:36 GMT

#0

한국 16강... 와 진짜 미쳤,,, ㅎㅎㅎ

3인 사업장에서 병특으로 경력을 시작한 입장에서, 여건이 안되서 그런데라도 취직하는 사람이 대부분이지 않을까 싶다. 물어볼 곳은 없지만 내멋대로 다 만들 수 있다는 점은 장점. 바보 선임이 엉뚱한 답변 주는 곳보다는 없는게 낫다. 스택오버플로 깃헙 코파일럿 챗지피티가 있는 세상이니. https://x.com/backendMew/status/1601485448245022720

지나고보니 경력만큼 케바케도 없다. 갈 수 있는 곳 중에선 제일 좋은 곳으로 가야겠지만, 후진 곳에서 시작했다고 딱히 좌절할 필요도 없다. 어디가 됐든 장점도 있고 단점도 있으니. 그리고 올라탈 열차가 없는 상황에서는 어디가 됐든 일단 올라타는게 먼저라는 생각.

2022-12-11

#7

인터뷰보면서 실력만큼 인성도 대단하다 생각했는데, 아버지도 레전드였,,, https://x.com/museun_happen/status/1601505751058599937

2022-12-11

#8

2022-12-20

#17

부트캠프 비판하는 글들이 많이 보이는데, 뭐라도 시켜서 열심히 했다면 나쁘진 않다는 생각. 특히나 시작할때는 질만큼이나 양도 중요하다고 생각하는 입장이라.

2022-12-20

#18

문제를 해결할 수 있음에 기뻐할지, 문제가 벌어진 상황에 절망할지 한끗 차이지만, 전자처럼 생각하는게 쉽지 않은 것 같다. 어릴때 했던 고민들을 지금 보면 시시해 보이는 것처럼 지금 내가 하는 고민도 더 나이가 들었을땐 귀엽게 느껴지기를. 이번 생은 첨이라, 참 어렵다.

2022-12-27

#19

재택이 회사와 동등한 수준의 개발 환경이 있다고 가정할경우 기술적으로 업무 효율이 떨어질 이유는 1도 없다고 생각하지만 막상 전사적으로 실시해보면 회사 전체적인 업무 능력이 많이 떨어졌다. 해서 신뢰 문제가 커 보임. 가능한 사람이 있겠지만 모두가 가능하진 않다는 머스크 관점이 맞을지도.

2022-12-28

#20

코파일럿이나 챗지피티가 채용 시장과는 무관할거란 의견이 많이 보이는데 난 반대. 서버관리를 보면 클라우드가 생기고 한명이 관리할 수 있는 서버 대수가 늘어나면서 자리가 없어지진 않았지만 티오는 전보다 줄었다. 비슷한 전개가 되지 않을까라는 느낌. 심지어 지금은 초기 버전인걸 감안해야.

2022-12-28

[일상] 2022년 11월의 잡담

Sun, 27 Nov 2022 22:57:45 GMT

#0

브라질, 일본 개발자를 채용헤서 수년간 같이 일해본 결과 나쁘지 않았다. 독자적으로 업무를 처리할 수 있는 사람만 채용하고, 의사 소통은 영어로 진행하면 개발 관련된 부분은 딱히 문제가 없었다. 근무 태만이 큰 문제인데 이는 낮은 수준의 급여와 계약해지 옵션으로 어느 정도 보완된다고 생각. https://x.com/Alisvolatprop12/status/1596816722727927808

워낙 비용 메리트가 커서 추가 채용하고 싶은 생각도 있고, 실제로 브라질 개발자의 경우 주변에 아는 사람 추천해 달라고 요청해서 몇 명 면접을 보기도 했으나 최종 계약까지 진행되지는 않음. 면접은 다 통과 했으나 이후 연락 두절. 재택이 가속화 되는만큼 글로벌 채용도 가속화 될거라 생각한다.

브라질은 시차도 기가 막힌게 퇴근할때 업무 할당하면 출근할 때 확인되는 신세계를 경험할 수 있음. 물론 열심히 일할 때 기준으로,,,

2022-11-27

#1

벨 부등식 아이디어 소오름,,, 이 우주를 만든 설계자가 있다면 리버싱 당하는걸 좋아할까? 싫어할까? https://youtu.be/6QPcmMa052s

2022-11-27

#2

생각보다 다들 짧은데? 2) 넷플이 1등? 3) 우버 지못미. https://x.com/golbin/status/1555869700768550912

2022-08-06

#3

딴건 모르겠지만 인터넷 검열 없애자는 생각은 몹시 칭찬함,,,

2022-08-13

#4

현실 세계에서 존 카맥이 말하는걸 처음 봤는데 말 엄청 잘하는 사람이었,,, 질답 정리 내용도 몹시 공감됨. 괜히 레전드가 아니넹. 진심 리스펙,, https://x.com/sm_park/status/1558341832328691712

2022-08-13

#5

구현이야 벤더 맘이겠지만 이게 꼭 룩업 테이블이 필요할거 같지는 않은뎅, 4바이트를 더 할당하고 앞에다 사이즈 기록해 두도록 구현하면 굳이 룩업 테이블이 없어도 되는거 아닌가 싶은... https://x.com/sanxiyn/status/1558719133843263488

2022-08-14

#6

일본 불매 운동으로 철수한 미루가메제면이 땡기는 날. 그나마 한번씩 찾아먹던 곳이었는데 몹시 안타깝다. 부러 오키나와까지 가기는 ㅠㅜ 백종원옹께서 똑같은 프렌차이즈를 만들어줬으면 좋겠다...

2022-08-14

#7

나도 hwp 이력서는 열지 않는 주의인데. 그냥 상식적으로 pdf와 hwp가 그냥 열릴 확률을 비교해 본다면 pdf를 전달하는게 일반적이지 않나 싶은. alz, egg도 마찬가지,,

2022-08-15

#8

프롬프트 엔지니어링 인상적,, 저런 고급진 용어가 있었다뉘 ㅋㅋ https://x.com/wapj2000/status/1559362123993858048

2022-08-16

#9

인공지능이 그린 그림으로 만든 게임. 프로그래머만 밥줄 걱정할때가 아니구나. 웃픈 현실 ㅎㅎ https://x.com/Nao_u_/status/1558595111147425792

2022-08-17

#10

ms가 만든 안드로이드 서브시스템도 대단하지만 그걸 또 magisk로 루팅하는 인간들도 보통은 아니네. 멋진 신세계,,,

2022-08-26

#11

의존명사 '등'이 우리 사회에서 이렇게 중요했었던 적이 있었던가 ㅋ 웃프네,,,

2022-08-26

#12

러스트 입문, 튜토리얼 괜츈한뎅... https://rinthel.github.io/rust-lang-book-ko/foreword.html

2022-08-27

#13

본의 아니게 러스트로 실전 프로젝트를 진행하고 있는데 딴 건 모르겠는데 cargo는 진짜 편하다. 디펜던시 한줄로 어디서든 완벽하게 찾아서 빌드해내는 시스템이란. 경이롭군,,

2022-08-29

#14

존잘이 존잘인 이유,,, 형님 이젠 좀 쉬엄쉬엄 하셔도. 몰랐는데 메타도 계속 일하는 거였,, https://x.com/GeekNewsHada/status/1564108844568961024

2022-08-29

#15

http://m.yes24.com/Goods/Detail/110368348 러스트 인 액션, 러스트를 첫 프로그래밍 언어로 익히는 사람들한테 추천. 이미 시스템 프로그래밍을 많이 해봤고 러스트를 배우려는 사람들에겐 좀 산만한 느낌이 있다. 처음 배우는 사람들에겐 저자가 선택한 고급진 예제들이 찰지게 다가올듯.

2022-08-31

계획된 적자를 낸다는 기업들의 면면을 들여다 보고 있자면 사람들의 그릇, 내지는 깜냥 차이가 확실하게 느껴진다. 미래에 대한 확신이 있기에 가능한 거겠지. 또한, 새삼 100원 투자에서 101원 벌기가 얼마나 어려운 일인지 깨닫는다.

2022-07-12

#12

설렘 주의보 발령 !! 드디어 나왔구낭, 번역이 자비롭기를. https://www.aladin.co.kr/m/mproduct.aspx?ItemId=297834576

2022-07-13

#13

푸앵카레는 습관을 정확하게 지키는 사람이었으며, 아침 10시부터 정오까지 오후5시부터 7시까지, 정확하게 하루에 네시간씩 수학을 연구했다. - 기하학 세상을 설명하다, 조던 엘렌버그

기하학은 아름다울까? 그렇다. 하지만 맨몸은 아니다. 기하학자들은 작업복을 입은 미인을 본다. 당췌 먼소리야 싶어 찾아본 원문은. Is it beautiful? Yes, but not bare. Geometers see Beauty with its work clothes on. 이 책 번역 별로다.

2022-07-16

#14

하, 스타필드. 신세계 상품권 안되는 거였... 애들 장난감 사러 왔다가 눈탱이 맞음. 깊은 빡침이 ㅠㅜ

2022-07-16

#15

http://m.yes24.com/Goods/Detail/101354429 만약 시간이 존재하지 않는다면에 관한 이야기보다 저자의 연구 여정에 관한 이야기가 더 많아 보이는 책. 무튼 요즘은 협업을 잘하는 분들의 연구 성과가 좋은거 같다는 느낌. 단순 시간 관련 물리적인 내용은 동저자의 시간은 흐르지 않는다가 좋아보임.

2022-07-18

#16

블랙의 신부라는 넷플릭스 드라마를 보다 새삼 it 개발자의 거품을 느낀다. 그 옛날 이찬진 대표가 결혼하던 시절 느낌이랄까. 카이스트 출신의 재계 30위 모바일 게임 개발사 대표란 ㅎㅎ

2022-07-18

#17

헤어질 결심에서 젤 신박했던 장면은 배우들이 파파고로 음성 대화하는 장면. 그리고나서 네이버 웨일 번역이 좋다는 얘기가 있어서 깔아봤는데. 중국어 번역 한정 개인적인 느낌은 크롬 > 엣지 >>> 웨일인듯. 그럼에도 국내에서 진짜 인공지능 하는 업체는 네이버 킹정.

2022-07-19

#18

과연 개발자들이 스택오버플로 코드를 복붙하면서 오픈소스 라이선스 걱정을 얼마나 할까? 코파일럿 라이선스 논란에 부쳐... https://www.google.com/amp/s/fossa.com/blog/analyzing-legal-implications-github-copilot/amp/

2022-07-19

#19

모게임사 김밥 꼬다리 사건이 생각나는. 김밥을 줬더니 꼬다리를 왜주냐고 머라해서 꼬다리를 빼고 줬더니, 꼬다리가 맛있는데 왜 뺐나고 또 머라해서 김밥이 없어졌다는 슬픈 전설. 모두를 만족시키기란 무척 어렵고, 무임승차한 인원을 솎아내도 그런 사람은 계속 나온다는게 함은정,, https://x.com/markkimmulgrew/status/1550570341658988545

2022-07-23

#20

코드나 일에 지나치게 에고를 투영하는건 좋지 않다는 생각. 일은 일이고, 코드는 코드고, 나는 나다. 일과 나를 하나로 생각하고, 코드가 곧 본인이라고 생각하는 사람과 일하는 건 몹시 피곤.

2022-07-25

#21

탐라에 코드리뷰 글이 보여서 한마디. 1) 해당 방법론은 생각보다 과대 평가된 것 같다는 느낌적인 느낌 2) 구성원들이 코드에 대한 에고를 빼는게 젤 중요 3) 리뷰 운운하기 전에 제발 잘 작성된 코드를 좀 읽자, 오픈소스 같은...

2022-07-26

#22

리눅스 커널 코드를 보면서 아 난 졸라 코딩을 잘해, 라고 생각하는 사람은 거의 없다. 그러니 실력이 없다는 생각에 그만둘 필요는 없는거 같다. 난다긴다 해봐야 알파고한테 지는 건 똑같다. 실력 없는 거 같아서 그만뒀다는 얘기에,,, 존버 정신을 기억하자. http://www.jiniya.net/ng/2016/06/about-genius/

2022-07-26

#23

https://googleprojectzero.blogspot.com/2018/10/injecting-code-into-windows-protected.html?m=1 ppl 인젝션 쉬운게 아니었군. Ms형님들이 니들 쓰라고 만든 기능은 확실히 아닌데,, 하앍...

2022-07-28

#24

https://www.deepmind.com/blog/alphafold-reveals-the-structure-of-the-protein-universe 인간을 겸허하게 만드는인공지능의 업적, 알파코드는 과연?

2022-07-29

[일상] 2022년 6월의 잡담

Wed, 29 Jun 2022 13:41:25 GMT

#0

나의 해방 일지 정주행. 추앙, 해방, 그리고 지겨운이란 단어가 인상적이 드라마. 생각을 하게 만드는 대사가 많았다. 워낙 잔잔해서 호불호가 갈릴듯. 나의 해방은 인연을 끊음에 있다고 생각되지만 그러기엔 인생이 또 너무 재미 없을듴. 고로 해방은 몹시 어렵다.

2022-06-06

#1

우리가 태어나서 죽을 때까지 맺는 온갖 관계 중에서 단 하나만이 진정으로 평생 이어집니다. 바로 우리 자신과 맺는 관계입니다. - 내가 틀릴 수도 있습니다, 비욘 나티코 린데블라드

정말 이상하지 않아? 16년 동안 온갖 교육을 받았는데, 삶이 힘들 때 뭘 어떻게 해야 하는지에 대해서 배운 건 하나도 없다니!’

17년 동안 깨달음을 얻고자 수행에 매진한 결과, 머릿속에 떠오른 생각을 다 믿지는 않게 되었습니다. 그게 제가 얻은 초능력입니다.

여자친구와 헤어지고 스님이 되어 20년 가까이 깨달음을 얻는 수행 생활을 하던 우연히 벌레에 물려 혈소판 관련 희귀 질환이 생겨 스님을 그만두고 속세로 돌아온 남자, 이후 사랑하는 여자를 만나 결혼했지만 루게릭 병이 생겨 이른 나이에 세상을 떠나게 된다.

메멘토 모리가 떠오르는 책. 시한부 판정을 받지 않았을 뿐 사실은 우리 모두 시한부 인생이다. 그걸 잊고 살아갈 뿐.

2022-06-11

#2

저런 실험을 실제로 하다뉘 ㅋㅋ 반전 ㅎㅎ https://x.com/idgmatrix/status/1536579785505538049

2022-06-14

#3

파인만옹이 저럴진데,, 하물며... https://x.com/my_own_bookclub/status/1536722129210658818

2022-06-15

#4

1993 이후 가장 인기있는 웹사이트 탑10, 가장 놀라운 반전 야후가 아직도 10위권에 있다니 ㅋㅋㅋ https://youtu.be/hNDILCdZmRo

2022-06-17

#5

어쩌다 소프트스킬, 하드스킬이 탐라를 도배하게 된 것인가? 뭣이 중헌지보다 진원지가 어딘지가 더 궁금한..

2022-06-19

#6

의외로 종이접기가 엄청난 두뇌 활동을 요한다. 유툽 0.5배속까지 동원해도 집중 안하면 쫓아가기 어려움. 당췌 이걸 처음 발명한 사람은 뇌구조가 어떤건지,, 겸손함을 배우기 좋은 취미. 자만심이 있다면 마스터 종이접기부터 시작하길 강추. http://m.yes24.com/Goods/Detail/93960272

2022-06-20

#7

강신주님의 메달린 절벽에서 손을 뗄 수 있는가를 다 읽었다. 대중강연하던 때의 그를 다소 가볍게 생각했으나 앞으로는 존경하기로 했다. 세상의 모든 철학자가 대단하게 느껴지는 책. 주인으로 산다는것, 나의 본래면목은 무엇인지를 생각해봤다. http://m.yes24.com/Goods/Detail/13465632

2022-06-20

#8

https://github.com/features/copilot/ 연봉 100불짜리 인공지능 프로그래머, c++ 3분 테스트 후 감탄과 놀라움을 금치 못하겠... 채용의사 확실함 ㅋㅋ 와 진짜 이제 하산할때가 된 것인가 ㅎㅎ

2022-06-22

#9

깃헙 코파일럿과 오늘 첫 실전 코딩을 함께 해보았다. 안드로이드 네이티브 c++ 개발. 진짜 미쳤다. 이세돌이 느낀 감정을 이땅의 모든 프로그래머가 느낄 날이 머지 않은듯. 혁신이란 이런 것인가, 와 진짜 얼척이 없다.

코타나가 권한을 얻으면 주인의 이익을 위해 상대의 코타나를 교묘히 조종하기 시작할 것이고,그결과 직업시장 또는 결혼시장에서의 성공이 점점 더 코타나의 자질에 따라 판가름날 것이다.그래서 최신 버전의 코타나를 소유한 부자들은 구버전을 소유한 가난한 사람들보다 결정적 우위를 점할 것이다.

더 비싼 최신 버전의 코파일럿을 구독하는 개발자가 코딩을 더 잘할 날이 머지 않은 느낌적인 느낌. 그리고 온라인 코딩 테스트의 의미를 다시 생각해본다. 우리 회사 코딩 테스트는 코파일럿이 몇초도 안되는 시간에 만점으로 통과했다.

2022-06-24

#10

https://youtu.be/xdfmhWQyp_8 21세기형 나귀,, 데리고 다니면 엄청 팬시하긴 하겠당. 만원 지하철, 엘베만 아니면. 성능좋은 블투 스피커와 구글 어시스턴트 탑재하면 1000불 더 받아도 지금보다 잘 팔릴듴. 보스턴 다이나믹스 이후로 디자인은 저게 최선인지 의문.

2022-06-26

#11

코파일럿 다 좋은데 주석이 극혐하는 스탈로 달리는 경향이 있다. fopen... // open file. 코멘트 주도 개발이라 어쩔 수 없는듴...

2022-06-27

#12

아마존 인공지능 코딩 도구. 코드 위스퍼, 코드 구루. 깃헙 코파일럿 보다 지원 언어는 제한적인듯함. 개발에도 이제 바둑처럼 ai류가 나오게 될 것인가? https://aws.amazon.com/ko/blogs/korea/how-to-improve-software-development-productivity-ml-based-aws-cloud-services/

2022-06-28

#13

"AI 주도 개발" https://shinyoungjin.life/dev/ai-driven-development/

2022-06-29

[ai] AI 주도 개발

Tue, 28 Jun 2022 12:00:01 GMT

최근 Github Copilot 출시 소식을 접했다. 소개 페이지를 보면 월 10불, 년 100불에 Python, JavaScript, TypeScript, Ruby, Go, C#, or C++ 코딩을 도와주는 도구라고 나와있다. 알파고가 등장하기 전이었다면 쳐다보지도 않았겠지만 알파고의 위력을 알았기에 설치를 해보았다. 결과는 실로 놀라웠다. 처음 3분간 테스트 해 본 코드를 첨부하면 다음과 같다. ai+라고 주석이 달린 부분은 모두 인공지능이 작성해서 추가한 부분이다. 살펴보면 대체로 함수 원형만 작성하면 나머지는 모두 코파일럿이 작성했다는 것을 알 수 있다. 사실 여기까지만 보고도 많이 놀랐다.

int plus(int a, int b) {
	return a + b; // ai+
}

int IsPrime(int n){
	if (n <= 1) { // ai+
		return 0; // ai+
	} // ai+
	for (int i = 2; i < n; i++) { // ai+
		if (n % i == 0) { // ai+
			return 0; // ai+
		} // ai+
	} // ai+
	return 1; // ai+
}


int GetFactorial(int n)
{
	if (n == 0) // ai+
		return 1; // ai+
	else // ai+
		return n * GetFactorial(n - 1); // ai+

}

int GetFactorialWithoutRecursion(int n)
{
	int result = 1; // ai+
	for (int i = 1; i <= n; i++) // ai+
	{ // ai+
		result *= i; // ai+
	} // ai+
	return result; // ai+
}

int GetFibonacci(int n)
{
	if (n == 0) // ai+
		return 0; // ai+
	else if (n == 1) // ai+
		return 1; // ai+
	else // ai+
		return GetFibonacci(n - 1) + GetFibonacci(n - 2); // ai+
}

int GetFibonacciWithoutRecursion(int n)
{
	int a = 0; // ai+
	int b = 1; // ai+
	int c = 0; // ai+
	for (int i = 0; i < n; i++) // ai+
	{ // ai+
		c = a + b; // ai+
		a = b; // ai+
		b = c; // ai+
	} // ai+
	return c; // ai+
}

bool IsPalindromeString(const char* s){
	int len = strlen(s); // ai+
	for (int i = 0; i < len / 2; i++) { // ai+
		if (s[i] != s[len - i - 1]) { // ai+
			return false; // ai+
		} // ai+
	} // ai+
	return true; // ai+
}

int GetMaxValue(int* a, size_t cnt)
{
	int max = a[0]; // ai+
	for (int i = 1; i < cnt; i++) { // ai+
		if (a[i] > max) { // ai+
			max = a[i]; // ai+
		} // ai+
	} // ai+
	return max; // ai+
}

void SortData(int *data, size_t cnt)
{
	for (int i = 0; i < cnt; i++) { // ai+
		for (int j = i + 1; j < cnt; j++) { // ai+
			if (data[i] > data[j]) { // ai+
				int tmp = data[i]; // ai+
				data[i] = data[j]; // ai+
				data[j] = tmp; // ai+
			} // ai+
		} // ai+
	} // ai+
}

typedef struct _STUDENT
{
	std::string name;
	int score;
} STUDENT, *PSTUDENT;

int FindStudentScore(PSTUDENT students, int cnt, std::string name){
	for (int i = 0; i < cnt; i++) { // ai+
		if (students[i].name == name) { // ai+
			return students[i].score; // ai+
		} // ai+
	} // ai+
	return -1; // ai+
}

void QuickSortData(int* data, size_t cnt){
	if (cnt <= 1) // ai+
		return; // ai+
	int pivot = data[cnt / 2]; // ai+
	size_t i = 0; // ai+
	size_t j = cnt - 1; // ai+
	while (i <= j) // ai+
	{ // ai+
		while (data[i] < pivot) // ai+
			i++; // ai+
		while (data[j] > pivot) // ai+
			j--; // ai+
		if (i <= j) // ai+
		{ // ai+
			int tmp = data[i]; // ai+
			data[i] = data[j]; // ai+
			data[j] = tmp; // ai+
			i++; // ai+
			j--; // ai+
		} // ai+
	} // ai+
	QuickSortData(data, j + 1); // ai+
	QuickSortData(data + i, cnt - i); // ai+
}

테스트 하면서 웃긴 장면이 하나 있었다. 다음 함수다. 중괄호 매치가 끝나지 않은 지점에 인공지능 코딩이 끝난 것이다. 사실 인간 입장에서 여기에서 코드가 종결된 것인지, 아니면 코드를 더 작성해야 하는지 알기가 쉽지 않겠다는 생각이 들었다.

void QuickSortDataWithoutRecursion(int* data, size_t cnt) {
	std::stack<int> stack; // ai+
	stack.push(0); // ai+
	stack.push(cnt - 1); // ai+
	while (!stack.empty()) { // ai+
		int right = stack.top(); // ai+
		stack.pop(); // ai+
		int left = stack.top(); // ai+
		stack.pop(); // ai+
		int pivot = data[(left + right) / 2]; // ai+
		int i = left - 1; // ai+
		int j = right + 1; // ai+
		while (true) { // ai+
			do { // ai+
				i++; // ai+
			} while (data[i] < pivot); // ai+

		// 이 시점에 인간 프로그래머의 심정
		// 1) 다 짠걸까? 2) 더 있는걸까? 3) 맞는걸까?

여기까지 샘플 코드를 살펴보면 저건 단순하고 많이 테스트되는 코드들이니까 인공지능이 잘 작성했다고 생각할 수 있다. 어쨌든 나는 여기에서 가능성을 보았다. 그리고 이후 몇일간 실질적으로 회사 코딩을 하는데 적용해서 함께(?!) 코딩을 해보았다. 결과는 실로 놀라웠다.

내가 테스트한 개발 방식은 총 3가지였다. 안드로이드 C++ 개발, 윈도우 C++ 개발, 윈도우 커널모드 C 개발. 안드로이드와 윈도우 C++ 개발은 굉장히 편리하게 사용할 수 있는 수준이었다. 윈도우 커널모드 C 개발의 경우 주석을 굉장히 디테일하게 작성해야 사용할 수 있는 코드가 도출되었다. 결론부터 총평하자면 무조건 써라. 회사에서 사주지 않으면 개인 비용으로라도 쓰길 추천한다.

써보면서 가장 편리했던 부분은 끊임없이 레퍼런스를 참고하면서 작업해야 하는 반복적인 코딩이었다. 예를들면 Java 호출 코드를 JNI로 컨버팅하는 류인데 이런 경우 안드로이드 문서와 JNI 스펙 문서를 찾아보면서 일일이 타입, 시그니처를 찾고 생성해서 테스트를 해야 한다. 그렇게 일일이 수작업으로 생성해도 세미콜론이나 달러 기호가 빠져서 정상 동작하지 않는 경우가 많다. 하지만 코파일럿을 사용할 경우 주석만 적당히 입력하면 마법처럼 완벽한 코드를 생성해 냈다. 이게 몇 개 쌓이자 나중에는 일일이 확인을 하지도 않았다. 그냥 얘가 생성한거는 똑바로 생성했겠거니 하는 생각이 들었다.

두번째로 놀란 부분은 주석이 없어도 인공지능이 문맥을 어느 정도 파악한다는 점이다. 예를들면 내가 특정 조건을 실패로 리턴하면 다음부터는 그 함수 내에서는 그런 류의 판단은 자기가 알아서 성공/실패를 결정한다. 이건 진짜 웃긴데 내가 함수를 작성하다 구조가 마음에 안 들어서 위에서 한두개를 바꾸면 나머지는 다시 알아서 재추천을 해준다. 진짜 얘가 나와 상호작용을 하고 있다는 생각이 절로 든다. 나는 페어 프로그래밍은 시간 낭비라 생각해 많이 해보진 않았지만 그간 일반적인 신입 프로그래머와 코딩 작업이나 코드 리뷰를 해 본 경험에 비추어보자면 코파일럿이 보통의 신입 프로그래머보다는 훌륭하다는 생각이 들었다.

세번째로 놀란 부분은 완벽하진 않지만 힌트를 제공하면 마법처럼 내 의도를 알아차린다는 점이었다. 예를들면 다음과 같은 코드였다.

void CombineValue(uint8_t* buf, size_t buf_size, uint64_t msb, uint64_t lsb)
{
	uint64_t value = (msb << 32) | lsb; // ai+
	for (int i = 0; i < buf_size; i++) // ai+
	{ // ai+
		buf[i] = (value >> (8 * i)) & 0xFF; // ai+
	} // ai+

이건 아니지라는 생각에 AI가 추가한 코드를 지우고 memcpy(까지 치고 기다리면 다음처럼 올바른 코드를 생성해 낸다.

void CombineValue(uint8_t* buf, size_t buf_size, uint64_t msb, uint64_t lsb)
{
	memcpy(buf, &msb, sizeof(msb)); // ai+
	memcpy(buf + sizeof(msb), &lsb, sizeof(lsb)); // ai+

함수가 리턴 값이 있어야 할 거 같아서 다음과 같이 bool 형으로 바꾸고 if까지 입력하고 대기하면 다음과 같은 코드를 생성해 준다. 물론 완벽하진 않지만 내가 뭘 체크하려고 if를 입력했는지를 캐치했다는 점은 놀랍다. 함께 코딩해보면 이런 적이 제법 많다. 실질적으로 내가 의도한 바는 buf_size < 16이다. 그럼에도 주석 한 줄 없이 이 정도 코드를 추천했다는 것은 놀랍다.

bool CombineValue(uint8_t* buf, size_t buf_size, uint64_t msb, uint64_t lsb)
{
	if(buf_size < 8) // ai+
		return false; // ai+

	memcpy(buf, &msb, sizeof(msb)); // ai+
	memcpy(buf + sizeof(msb), &lsb, sizeof(lsb)); // ai+

	return true; // ai+

회사 작업을 하면서 코파일럿이 추가한 코드는 여기에 올린 것처럼 ai+라는 주석을 달았다. 실질적으로 얼만큼 실용적인지를 보고 싶었다. 하지만 이제 더는 달지 않는다. 몇일 작업하면서 이미 코파일럿은 그 자체로 존재 가치를 충분히 증명했기 때문이다.

나는 코파일럿이 제공하는 프로그래밍 언어를 다 다룰 줄 안다. 다만 주력으로는 파이썬, C++이고 나머지는 서브로 사용하고 있다. 그래서 해당 언어의 라이브러리 코드 등을 세세하게 다 기억하지 못해서 구글을 통해서 검색해가면서 개발하는 경우가 다반다사. 이런 경우에도 코파일럿은 굉장히 큰 도움이 되었다. 왜냐하면 그런 언어로 하는 작업은 실질적으로 아주 간단한 샘플 코드인 경우가 많아서 코파일럿 추천을 받기가 훨씬 쉽기 때문이었다.

class Test
{
	public String GetFileText(String path){
		String text = ""; // ai+
		try { // ai+
			FileInputStream fis = new FileInputStream(path); // ai+
			BufferedReader br = new BufferedReader(new InputStreamReader(fis)); // ai+
			String line; // ai+
			while ((line = br.readLine()) != null) { // ai+
				text += line + "\n"; // ai+
			} // ai+
			br.close(); // ai+
		} catch (IOException e) { // ai+
			e.printStackTrace(); // ai+
		} // ai+
		return text; // ai+
	}

	public void RequestPermission(String permission){
		ActivityCompat.requestPermissions(this, new String[]{permission}, 1); // ai+
	}
}

예전에 나는 이런 도구에 대해서 조금은 부정적인 의견이 있었다. 이런 도구들이 발전할수록 개발자가 점점 멍청해지지 않을까라는 생각이 있었던 것이다. 그러나 이제는 생각이 좀 바뀌었다. 인공지능이 진화할수록 결국 나를 100% 대체할 것은 자명한 사실이다. 하지만 100% 대체가 되기 전까지는 어쨌든 인공지능의 도움을 받는 것이 다른 사람들과 경쟁을 하는데 도움이 된다는 생각이다. 그리고 코파일럿을 써 본 입장에서 생산성 차이는 엄청나다. 최신형 사이보그 의족을 달고 우샤인 볼트와 대결할 수 있게 된 것이다. 아직도 코파일럿을 안 쓰는 개발자도 많을 것이다. 그런 점에서 사용하는 사람은 비교우위에 설 수 있다는 게 내 생각이다.

그리고 조심스레 예측해 본다. 앞으로 코파일럿에 적응한 개발자가 늘어날수록 함수명이나 변수명, 주석 등을 코파일럿이 적절하게 추천할 수 있도록 작성하는 것이 능력이 될 것이란 점이다. 아직까지는 주는 사람이고, 보조가 인공지능이지만 인공지능이 주가 될 날도 머지 않았다는 생각이 든다. 인공지능이 추천한 코드를 사용하다, 인공지능에게 코드 리뷰를 받다가, 결국에는 인공지능이 모두 다 작성하게 될 세상. 그런 세상에서 아마도 우린 이런 얘기를 하겠지? 라떼는 사람이 직접 프로그램을 입력하는 시절도 있었다고 말이다.

진짜 정말 놀라운 세상이다.

충분히 발달한 과학 기술은 마법과 구별할 수 없다.

-- 아서 C. 클라크

[일상] 2022년 5월의 잡담

Sun, 22 May 2022 20:18:05 GMT

#0

만약 우리가 전체 그림을 볼 수 있다면, 전체 이야기를 안다면, 지금의 막힌 길이 언젠가는 선물이 되어 돌아오리라는 것을 알게 될까? 그것이 삶의 비밀이라는 것을. 우리의 가슴을 뛰게 하는 것은 지나간 길이 아니라 지금 다가오는 길이다. - < 좋은지 나쁜지 누가 아는가, 류시화 지음 > 중에서

2022-05-07

#1

불교 철학에 관심이 있다고 하니 아는 동생이 강신주님이 요즘 불교 강좌를 한다는 이야기를 전해 주었다. 화두란 무엇인가? 우리는 매달린 절벽에서 손을 뗄 수 있을까? https://youtube.com/playlist?list=PL5WMTtfpXrft7m-zCOjeckIA_PM66_-fA

2022-05-07

#2

가능한 한 일찍 결혼하는 것은 여자의 비즈니스이고, 가능한 늦게까지 결혼하지 않고 있는 것은 남자의 비즈니스이다. ― 조지 버나드 쇼, 이 아저씨는 정말 촌철살인...

2022-05-10

#3

배우자 심사 시 고려해야 할 조건, 배우자의 집안, 결혼 시기, 결혼 자금, 신혼여행, 신혼집 가구 배치, 출산 및 육아 계획, 부부 생활을 원만하게 유지하는 법 등에 대해서는 과도하게 신경 쓰는 반면, 대체 결혼을 왜 해야 하는지에 대해서는 진지하게 생각해보지 않는다는 뜻이다 -결혼의 종말

http://m.yes24.com/Goods/Detail/90701972 굉장히 흥미로운 책이었다. 코 파기의 즐거움 만큼이나 특이한 주제로 심도 있는 글을 쓴 책인듯. 대체로 저자의 생각에 동의한다. 결혼 제도를 지탱하는 근간이 양육이라 생각되는데 그에 대한 논의는 별로 없는게 옥의 티라면 티?

결혼은
혼자 있었으면 있지도 않았을 문제들을
둘이서 함께 해결하려는 시도다.

― 에디 캔터 Eddie Cantor

2022-05-11

#4

우주는 생명을 만들었고 생명은 의식을 창조했고 의식은 영속한다. 그 말을 믿고 싶어지는 순간이다. - < 작별 인사, 김영하 > 중에서

김영하님 소설은 첨 읽어봤는뎅 쏘쏘. 인공지능에 관한 소설인지 뭘 말하고 싶은건지는,,, 인공지능 메타버스 전뇌화 등등 수많은 떡밥을 버무려서... 결론은 버킹검 ㅎㅎ

나는 말년의 아빠에게, 뇌를 백업하고 영생하지 않겠느냐고, 이미 많은 인간이 그렇게 하고 있다고 말했다. 아빠는 단호히 거부했었다. 육신이 없는 영생을 바라지 않는다고, 인간의 존엄성은 죽음을 직시하는 데에서 온다고 말했다. 그리고 육신 없는 삶이란 끝없는 지루함이며 참된 고통일 거라고도.

2022-05-18

#5

뼈 때리는 짤 ㅎㅎㅎ https://x.com/dungdungwee/status/1528283179651436544

2022-05-22

[일상] 2022년 4월의 잡담

Sat, 30 Apr 2022 06:26:45 GMT

#0

가끔 왜 보안 프로그래머가 됐냐는 질문을 받는데, 병특 전직 기간 중 합격한 유일한 회사가 보안 솔루션 개발하는 곳이었다. 그때 게임 회사에 합격했다면 게임 개발자가 됐을지도 모른다. 돌아보면 개발엔 진심이었지만 분야에 관해서는 1도 생각을 안했구나 싶다. 첫 직장은 생각보다 중요하다.

2022-04-16

#1

경관의 피, 뜨거운 피, 야차. 최근에 본 국내산 범죄 영화. 하나같이 별로였다. 뭔가 k영화가 뒷걸음질 치는거 같은 느낌적인 느낌...

2022-04-16

#2

콕스 엔데버 35g 추천. 리얼포스 품절이라 사봤는데 나쁘지 않다. 키감 비슷하고, 더 저렴하고, 더 예쁘고, 심지어 마감도 싸구려같지는 않음. http://m.danawa.com/product/product.html?code=8345919&cateCode=112782

2022-04-17

#3

코딩테스트가 산으로 가고 있다는덴 공감. 반면에 큰 회사들 입장에서 그거보다 싸고 손쉽고 객관적인 변별력 지표를 찾기도 어렵다는 생각. 세상이 그렇게 돌아가는데에는 다 이유가 있지 않나 싶다.

2022-04-18

#4

pe 파일 구조 보는 툴. 회사 직원이 알려준 툴인데 몹시 칭찬할만한 툴. pe viewer는 빠잉... https://hshrzd.wordpress.com/pe-bear/#:~:text=PE%2Dbear%20is%20a%20freeware,works%20for%20windows%20and%20Linux).

2022-04-19

#5

[일상스케치] 누가 성장했을까? - YoungJin Shin http://www.jiniya.net/ng/2022/04/who-has-grown-up/

2022-04-19

#6

사무실이 덥다. 여름이 오는 중인듯. 누가 뭐래도 지구는 하루에 한바퀴, 일년에 한바퀴 돌 긴 하나보다.

2022-04-20

#7

https://brunch.co.kr/@fbrudtjr1/44 논문급 분석글. 대단하다. 그와중에 배민이 적자 전환했다는 사실이 다소 충격적임. 쿠팡의 미래는 과연?

"2022 쿠팡, 과연 아마존이 될 상인가?" https://shinyoungjin.life/invest/coupang-20022/

2022-04-21

#8

"내가 오늘 교통사고를 당할 확률은?" written by YoungJin Shin(@codemaru) https://shinyoungjin.life/life/traffic-accident-probability/

2022-04-22

#9

가뭄에 단비같은 느리지만 조금씩이라도 세상이 좋아지는거 같은 늬우스... https://x.com/inventeam/status/1517315861828186113

2022-04-22

#10

처벌 또한 비슷한 관점에서 가능하다는 생각. 자유의지가 없다 하더라도 공동체에 피해를 준다면 사회로부터 격리가 가능하지 않을까? 감금하는 정신병원같이...

2022-04-22

#11

자녀가 공부를 안해서 화가 난다는 친구 이야기를 들으며 공부는 스스로 해야지 시킨다고 되는게 아니니 마음쓰지 말라고 했다. 끝내 입장차를 좁히지 못했는데 지나서 생각해보니 난 주변에서 공부를 못했지만 성공한 케이스를 너무 많이 봤고, 그 친구는 그런 사례가 없었던게 차이라는 생각.

잘하면 좋겠지만 안되는걸 억지로 시키면서 스트레스 받을 필요는 없다고 본다. 정치인들만 봐도 자식 교육이 얼마나 힘든지를 알 수 있다. 하물며 일반인들이야. 건강하고 착하면 된거다. 물론 그마저도 욕심이겠지만. 이런거보면 무자식이 상팔자라는 옛말이 하나 틀린게 없다.

2022-04-23

#12

http://m.yes24.com/Goods/Detail/108890677 철학자의 불교공부 노트, 크게 이론편 수행편 나눠져 있다. 수행편은 그대로 노출된 한자어가 많아 마냥 읽기 편하진 않음. 그럼에도 보통 철학자들은 수행 관련 내용은 논하지 않았던 점을 고려한다면 새로웠당. 관연 평안에 이를수 있을까?

2022-04-23

https://youtu.be/veRuWVimnOE 허태균 교수, 김정운 교수 이후로 비슷한 컨셉으로 방송가에서 뜨는 교수님인듯한 느낌적인 느낌. 공통점. 일단 웃김,,,

2022-04-24

#17

경험하지 않고 얻은 해답은 펼쳐지지 않은 날개와 같다. 삶의 문제는 삶으로 풀어야 한다. - < 좋은지 나쁜지 누가 아는가, 류시화 지음 > 중에서

2022-04-30

[소고] 내가 오늘 교통사고를 당할 확률은?

Fri, 22 Apr 2022 12:00:01 GMT

출근길, 이렇게까지 막힐 길이 아닌데 터무니 없게 차들이 막혀 있다. 한참을 지나오니 3차선 길에 교통사고가 나서 2개 차로가 막혀 있었다. 그렇게 사고를 지나 한참을 달려 톨게이트를 지나는데 또 거북이가 된 차선. 멍밍? 톨게이트 위 표지판에 전방에 사고로 1, 2차선이 막혀 있다는 글귀가 스크롤 된다. 비도 오지 않고, 눈도 오지 않고, 단지 조금 흐린 날씨인데 왜케 사고가 많은 것일까?, 라는 생각도 잠시. 사고가 나지 않아서 다행이란 생각이 오버랩됐다. 그러자 마음이 한결 편해진다.

그렇게 또다시 막힌 길을 지나 열심히 달려서 상습 정체 구간에 도착했다. 느림보가 된 차안에서 갑자기 궁금증이 밀려온다. 오늘 내가 교통사고를 당할 확률은 얼마일까, 라는 생각. 어댑티브 크루즈를 켜두고 "교통사고 확률"같은 키워드로 포풍 검색을 해본다. 대체로 우리나라 사람이 평생 교통사고를 1번이라도 당할 확률은 나오지만 오늘 내가 교통사고를 당할 확률이 얼마인지는 나오질 않았다. 그래서 한번 역산을 해보기로 했다.

이어지는 모든 내용은 나의 부족한 수학 지식에 기반한 것이므로 오류 및 잘못된 내용이 포함되어 있을 수 있다는 점 명심해주길 바라면서 계산을 한 번 시작해보자. 이 기사에 따르면 우리나라 국민이 일평생 1번이라도 교통사고를 당할 확률은 35.2%라고 한다. 우리나라 국민의 평균 수명은 이 자료에 따르면 83.3세라고 한다. 계산의 편의를 위해서 80년이라고 가정한다.

일평생 한번이라도 교통사고를 당할 확률이 35.2%라는 말은 일평생 교통사고를 한번도 당하지 않을 확률은 64.8%라는 말이 된다. 일평생 교통사고를 한번도 당하지 않을 확률은 오늘 내가 교통사고 당하지 않을 확률을 사는 기간 만큼 곱한 것이 된다. 결국. 0.648의 80제곱근을 구한다면 한해동안 내가 교통사고를 당하지 않을 확률, 29200(80*365)제곱근을 구한다면 오늘 내가 교통사고를 당하지 않을 확률이 나온다. x의 n제곱근은 x^(1/n)으로 구할 수 있다고 한다. 그렇게 계산을 해보면 0.648^(1/29200) = 0.999985가 나온다. 마침내 내가 오늘 교통사고를 당하지 않을 확률에 도달했다. 99.9985%, 교통사고를 당할 확률은 그 반대이니 0.0015%가 될 것이다.

0.0015%라, 생각보다 확률이 너무 낮은 느낌적인 느낌. 인구가 5천만이라고 가정하면 하루에 확률적으로 750명 가량이 교통사고를 경험할 수 있게 되고, 그런 사람들 중 최소 4명을 내가 오늘 아침에 목격한 셈이 된다.

오늘 하루, 교통사고 없이 무사히 출근하게 되어 억세게 운이 좋다고 생각하려고 하였으나 그렇게 생각하기에는 무리가 있어 보이는 확률 같다. 확률을 본다면 퇴근길에도 난 교통사고를 겪지 않을 것 같다. 그렇게 오늘도 보통 사람이 보통의 확률로 하루를 살아간다.

[소고] 2022 쿠팡, 과연 아마존이 될 상인가?

Thu, 21 Apr 2022 13:00:01 GMT

쿠팡은 왜 적자를 탈출할 수 없는걸까?

이런 글을 보면 정말 애널리스트도 힘들겠구나 하는 생각이 든다. 반도의 흔한 블로거의 분석글 수준이 정말 넘사벽이다.

쿠팡은 몇년전부터 개인적으로 몹시 미래가 궁금했던 기업 중 하나였다. 왜냐하면 저 사업 모델이 성공할까? 하는 생각도 있었고, 소비자로써는 너무나 지나치게 편리했기 때문이다. 상장전에는 실패할 확률이 높다고 생각했지만 보란듯이 나스닥에 성공적으로 상장해서 어마어마한 밸류에이션을 받는 걸 보고 나의 예측이 빗나갔음을 인정해야 했다.

최근에 멤버십 가격을 올리고, 반품 정책을 변경하는등 서서히 비용 지출에 신경을 쓰는 모습으로 변신하고 있는 쿠팡. 과연 그들은 흑자 전환을 할 수 있을까? 안타깝게도 난 위 분석글과 같은 이유로 쉽지 않을거라 생각한다. 아래는 분석글 내용 요약.

쿠팡은 2021년 매출 22조, 영업손실 1조8700억을 기록
국내 소매시장 온라인 침투율 28.9%로 거의 포화상태, 플레이어 너무 많음, 흑자 거의 없음
물류센터 자동화가 추후 규모의 경제를 달성하는데 중요함, 징동닷컴 85%, 슥 80%, 쿠팡 10% 수준
멤버십은 흑자지만 거기서 나오는 비용은 조족지혈
캐시카우 부재
신규 사업은 모두 돈먹는 하마
번외) 배민이 2019년부터 적자전환, 퀵커머스 진출로 유추 (충격)

그리고 원글에는 없는 개발자라면 모두 아는 아마존과의 결정적 차이, 아마존은 AWS를 팔고, 쿠팡은 AWS를 쓴다는 거. 심지어 베조스 다음 사장이 AWS 수장이 되었다. 그리고 다른 하나는 직고용 중인 천문학적 수준의 택배기사들. 규모가 커질수록 직고용이 늘고, 그렇게 늘어난 인원은 쿠팡이 바라는 규모의 경제를 달성하는데 거대한 허들이 되지 않을까 싶다.

이 모든 이야기에도 불구하고 로켓배송, 사랑한다.
쿠팡의 적자만큼 소비자에겐 혜자라는 의미가 되기도 한다.

대한민국 유니콘 신화가 계속 이어지기를...

[일상] Begin Again

Wed, 20 Apr 2022 12:00:01 GMT

2000년도 인터넷 수업 과제로 시작한 홈페이지가 이렇게 오랜 기간 이어질 줄은 몰랐다. 그러고보니 20년간 줄기차게 이어진 나의 유용한 취미 중 하나가 공개된 장소에 글을 쓰는 건 아니었나 싶다. 뜸한 시절도 있었고, 열정적으로 올린 시절도 있었지만 어쨌든 중요한 건 아직까지 이어지고 있다는 사실일 것이다.

그간 자작 게시판, phpBB, 태터툴즈, 워드프레스, 지킬을 거쳐서 이번에는 개츠비로 정했다. 요즘 유행하는 github 저장소, cloudflare 배포 방식을 사용해보려고 도메인도 새로 만들어봤다. 이제부터 얼만큼 남아 있을지 모를 나의 인생 후반전의 기록을 여기에 남겨볼까 한다.

가장 훌륭한 시는 아직 씌어지지 않았다.
가장 아름다운 노래는 아직 불려지지 않았다.
최고의 날들은 아직 살지 않은 날들.
가장 넓은 바다는 아직 항해되지 않았고,
가장 먼 여행은 아직 끝나지 않았다.
불멸의 춤은 아직 추어지지 않았으며,
가장 빛나는 별은 아직 발견되지 않은 별.
무엇을 해야 할지 더 이상 알 수 없을 때
그때 비로소 진정한 무엇인가를 할 수 있다.
어느 길로 가야 할지 더 이상 알 수 없을 때
그때가 비로소 진정한 여행의 시작이다.

– 진정한 여행, 나짐 히크메트

지금이 비로소 내 인생의 진정한 여행을 시작할 때인 것 같은 느낌...
아직 오지 않은 최고의 날들을 기다리며 비긴 어게인...

[소고] 누가 성장 했을까?

Tue, 19 Apr 2022 12:00:01 GMT

회사를 시작하고 직원을 채용하고 그들과 함께 일을 하면서 가장 많이 들은 불만 사항중에 하나는 방목이다. 나는 꼰대라 그렇게 생각을 하지 않지만 직원들은 회사가 본인들을 충실하게 교육시켜서 연차에 알맞게 총총 성장을 시켜주길 바라는 것 같다. 물론 나도 그런 생각을 안해본 사람은 아니다. 창업을 했던 초창기에는 어렸고, 열정이 있었다. 밤을 새면서 A부터 Z까지 알려주려고 해본 적도 있었다. 응당 개발 속도는 달팽이보다 느려졌다. 그때마다 빨리 가려면 혼자 가고, 멀리 가려면 함께 가라는 말을 주문처럼 되내이면서 자기 위안을 삼았다.

하지만 현실은 녹록치 않았다. 그 속도로 가다간 멀리는 고사하고 당장 한두달만돼도 굶어죽을 것 같았다. 속도도 느렸지만 품질도 문제였다. 충실하게 A부터 Z까지 교육을 받고 만든 친구는 성장했을지 모르겠지만 회사는 제자리였다. 아 이렇게 해서는 달은 고사하고 대기권 통과도 힘들겠구나 하는 생각이 절로 들었다. 결국 나는 방목을 택했다. 할 수 있는 것들만 시켰고, 못한다는 것은 할 수 있는 다른 사람들에게 부탁했다.

그렇게 개발 속도가 올라갔고 몇해가 지났다. 사내 이슈 트래커는 해결되지 않은 문제들로 가득찼고 제법 오래 일한 직원들과 이야기를 했다. 돌아온 답은 방목. 교육을 받지 못해서 직원들이 성장을 못했다는 이야기였다. 그리고 주된 문제점은 쉬운 문제들은 연차가 쌓인 사람들이 다 빨리 해버리고 나니 어려운 문제만 남아서 아무도 해결을 못한다는 이야기들이 많았다. 그래서 쉬운 이슈들을 처리하면서 배울 수 있도록 해야 한다는 솔루션이 나왔다. 그래? 그럼 그렇게 해볼까? 회사가 그렇게 배고픈 시절은 아니었기에 해볼만한 시점이기도 했다.

쉬운 일감들이 할 수 있을만한 사람에게 스스로 배정되었고, 그들은 차곡차곡 문제를 해결하고 코드를 제출했다. 나는 빨간펜 선생님처럼 리뷰를 하고 머지를 했다. 당연한 소리겠지만 과정은 아름다웠지만 속도는 거의 그린란드 상어가 성장하는 속도만큼 느려졌다. 그래도 이 시기만 거친다면 직원들이 충분히 성장할거란 기대를 해보았다. 그렇게 제법 오랜 시간을 우리는 아주 느려터졌지만 개발 교과서에 나오는 우아한 방식으로 업무를 진행해 보았다. 결과는 당황스러웠다. 내가 봤을 때는 방목일때나 빨간펜일때나 성장의 속도와 범위는 비슷한것처럼 보였다. 더 안타까운 사실은 그 아름다운 시기를 함께 경험한 직원들 중 지금까지 근무하는 사람이 별로 없다는 사실이다.

그렇게 오랜 시간을 지켜보고 이 방법 저 방법 해보고 내린 결론은 이렇다. 누가 성장했을까? 1) 회사 업무와 관련된 도메인에 관심이 있는 사람 2) 자기 동기부여가 되는 사람 3) 주도적으로 업무 처리가 가능한 사람 4) 열린 마인드를 가진 사람 5) 긍정적인 사고를 하는 사람들이 성장했다.

우리는 게임 보안 회사다. 입사 후에 가장 많은 성장과 기여를 한 친구들을 보면 대체로 입사 전부터 게임 보안에 관심이 있거나 그런 쪽의 작업을 한 친구들이 많았다. 사전에 관심이 많았다는 이야기는 스스로 학습할 가능성이 높다는 것을 담보하기도 하고, 입사 시점부터 경력직과 비슷한 효과를 가지기도 한다. 역대 입사한 직원들을 모두 나열해놓고 기여도가 높은 순서대로 정렬을 해본다면 거의 이 순서와 동일한 순서가 나온다. 그러니 애초에 도메인에 관심이 있다는 건 그 사람이 입사 후 성장할 가능성이 높이다는 가장 강려크한 지표 중에 하나라 할 수 있겠다.

칭찬은 고래도 춤추게 한다지만 현실은 그리 녹록치 않다. 회사란 공간은 칭찬은 인색하고, 평가는 냉혹하다. 이런 환경에서 버티기 위해서는 자기 동기부여가 되는 사람들이 유리하다. 우쭈쭈해줘야 뭔가 에너지를 받을 수 있는 사람들은 오래 버티기가 힘들다. 또한 계속 우쭈쭈하기도 힘들다. 칭찬은 고래도 춤추게 한다는 생각으로 그런 걸 남발하면 종국에는 고등학교 써클의 축제 출품작 같은 결과물을 마주하게 될 가능성이 농후하다. 그러니 스스로 동기부여가 되는 사람들을 찾는 것이 여러모로 유리하다.

주인 의식을 가지자는 말도 꼰대의 대표적인 언어가 된 요즘이다. 하지만 안타깝게도 성장하는 직원들은 대체로 주도적인 업무 처리를 하는 경우가 많았다. 우리 회사에 남겨진 대부분의 좋은 유산들은 회사에서 어떤 어떤 업무를 강제로 시켜서 남겨진 것은 거의 없다. 실무자들이 업무를 진행하면서 본인이 불편을 느끼거나, 다른 사람들이 업무 진행하는 것을 보면서 답답한 마음에 만든 것들이 남겨진 경우가 대부분이다. 주도적인 업무 처리를 하지 않는 사람들은 대체로 시킨대로 하거나, 현재 상태에서 개선을 하려는 의지가 없기 때문에 성장 기회를 얻을 가능성이 제한적이다.

요즘 개발자 면접을 보면 이런 말을 꼭한다. 우리 회사는 이것도 하고, 저것도 하고, 심지어 지금은 말은 안했지만 나중에는 이만저만한 업무도 해야 할 수 있다. 구직자들이 극혐한다는 풀스택 이야기다. 나는 그들을 혹사시키려고 이런 구질구질한 이야기를 하는 것은 아니다. 작은 회사라는 것이 언제 어떤 업무를 하게될지 모르기 때문에 애초에 이야기를 하는 것이다. 입사 후 성장한 친구들도 살펴보면 대체로 열린 마인들을 가진 친구들이 많았다. 나는 테스터니까 테스트만 하겠다 라든지, 나는 C++ 개발자니까 C++만 하겠다는 친구들은 그렇지 않은 친구들보다 성장 범위가 제한되는 경우가 많았다. 또한 개인적인 경험에서도 다양한 개발을 해보는 것이 도움이 됐다. 왜냐하면 다른 분야나 시스템에서 좋은 것들을 배우게되면 원래 알던 분야에도 적용할 수 있기 때문이다. 그리고 이제는 제법 유명한 이야기지만 깊이 파기 위해서는 애초에 넓게 파기 시작해야 한다. 물론 레이저는 예외다.

끝으로 긍정적 사고다. 긍정의 배신과 같은 책들도 있지만 어쨌든 긍정적 사고는 본인 내부에 가진 에너지를 보다 오래 보존시키는데 중요한 역할을 한다. 보안이라는 업무를 오래 하다보면 현타가 오는 시점이 있게 마련이다. 매번 대응 한다고 해도 해킹툴은 쏟아지고, 고객들의 불만은 미어터지고, 지원팀의 압박은 거세다. 나에게 감사한 사람은 아무도 없는 것 같은 순간이 찾아온다. 사실 그런 일들은 입사 시점부터 있어 왔겠지만 현타가 오는 시점은 본인에게 있던 긍정성이 고갈되는 순간인 경우가 많았다. 성장은 고통을 수반하고, 고통의 과정을 이겨내기 위해서는 결국 긍정 에너지가 어느 정도 필요 조건이 아닐까 싶다.

이제 방목과 교육을 다시 생각해본다. 도메인에 대한 관심, 자기 동기부여, 주도적 업무처리, 열린 마인드, 긍정적 사고와 같은 것들이 교육될 수 있는 것일까? 나는 그렇지 않다고 생각한다. 왜냐하면 이것들은 개인의 취향, 성격, 태도, 기질과 굉장히 밀접한 관련이 있는 것들이기 때문이다. 따라서 불행하게도 이런 종류의 것들은 입사 전부터 결정된 것들이고, 입사 후에도 변할 가능성은 별로 없다. 달리 말하면 어이없게도 성장할 사람은 입사 시점에 이미 거의 다 결정되어 있다는 말이다. 방목을 하든, 교육을 하든, 애자일을 하든, 코드리뷰를 하든, TDD를 하든, 세미나를 하든 하지 않든 말이다. 그 모든 것들을 하든지 하지 않든지 진짜 성장하는 사람은 그런 것들과는 상관이 없을 확률이 높다. 물론 애초에 좋은 기질을 가진 사람들에게 적절한 환경이 주어진다면 부스터가 될 수는 있을 것이다. 하지만 그 또한 미치는 영향력은 이러한 기질적 특성보다는 작은것처럼 보였다.

결국 인사가 만사고 채용이 중요하다는 관점에서 이 사실을 역으로 적용하면 이렇다. 도메인에 관심이 있어 보이는 똑똑한 사람을 뽑는게 최선이다. 나머지 것들은 알아낼 수 있다면 좋겠지만 면접 과정에서 알아내기란 몹시 어려운 부분에 속한다. 반면에 수습 기간에는 알아낼 확률은 높아지겠지만 3년도 아닌 3개월로도 실상 알기가 어렵다. 어쨌든 면접 및 수습 과정을 통틀어 최대한 이 5가지 항목을 잘 관찰하는 것이 중요하다고 할 수 있겠다.

개인의 관점에서 이 사실에서 한가지 교훈을 얻자면 똑같은 개발을 하더라도 관심있는 도메인이 어디인지는 한번쯤 생각해 보는게 도움이 된다는 점일 것이다. 평생 게임이라곤 한번도 안해본 사람이 게임 회사에 취직하는 것도, 주식은 도박이라고 생각하는 사람이 HTS 개발하는 업체에 취직하는 것도 고역일 것이고, 거기서 본인이 성장하기는 정말 어려울테니 말이다. 딜러, 힐러가 뭔지도 모르고, 이동평균선이 뭔지도 모르는 사람과 입사 전부터 딜힐 사이클과 각종 계산 방식 및 그것들이 가진 문제점에 대해서, 볼린져 밴드가 뭔지 P/E가 뭔지, 또 각종 지표의 문제점과 한계에 대해서 이미 모두 다 꿰고 있는 사람의 차이란 당신이 생각하는 것보다 클 수 있다.

노력은 해야겠지만 애쓰지 마. 될 일은 되고 안될 일은 안된다.
— 시지프스 EP.06

당신의 채용에, 당신의 입사에 성장 열매가 가득 하기를…
건투를 빈다.

[소고] 제갈량은 과연?

Fri, 15 Apr 2022 12:00:01 GMT

삼국지는 정말 흥미로운 책이다. 온갖 사람들이 등장해서 펼치는 활극도 대단하지만 그게 또 일부는 실화라는 점은 더 말문이 막히게 만든다. 그런 삼국지 인물 중에서도 최애하는 한명을 꼽으라면 단연 제갈량이다. 유비와 함께 가장 많은 사람들이 사랑하는 캐릭터가 아닐까 싶다.

와이프 미모 빼고는 모든 걸 다 가졌다는 제갈량을 보면서 항상 궁금한게 있었다. 그렇게 똑똑하고 세상 이치를 잘 아는 그가, 왜 하필 유비를 따라 갔을까? 삼고초려해서? 결국 천하통일에 실패 했다는 관점에서 생각해 보자면, 1) 모르고 따라 갔다면 그의 수읽기가 부족한 것이고, 2) 어짜피 실패할 걸 알고 따라 갔다면 왜 따라간 것일까? 하는 의문들 가지지 않을 수 없다.

그리고 또 한 장면, 출사표… 그는 줄기차게 출사표를 내고 사마의에 도전하지만 결국 하늘과 시간은 무심하게도 그를 버렸다. 1) 그는 질 걸 알면서도 줄기차게 출사표를 던지고 도전한 것일까? 2) 아니면 진심으로 이길 생각으로 나섰지만 패배한 것일까?

자신의 사후 세계 전략까지도 지시할만큼 대단했던 그는 자기 운명을 알면서도 겁없이 도전한 것일까? 아니면 그냥 생각보다 멍청했던 것일까? 제갈량을 보면 항상 그런 스타크래프트 게임이 생각난다. 템플러 드랍해서 일꾼 테러하고, 리버 드랍해서 재미보고, 다크템플러로 씐나게 테러하고, 신은 있는대로 다 내고 재미있게 즐겼지만 결국 물량에 밀려서 패배하는 게임… 전 인생의 관점에서 바라본다면 과정이 재밌었던 프로토스가 이긴 게임일까? 꾸역꾸역 막고 버텨서 역전한 테란이 이긴 게임일까? 우리는 어떤 게임을 하고 있는 것일까?

따뜻한 동남풍이 불어온다…

[소고] 21세기 게임 보안 프로그래머의 변천사

Thu, 14 Apr 2022 12:00:01 GMT

세상이 MS와 MS가 아닌 것들로 양분되던 시기에 개발을 시작했던 나는 참 편했다. MS가 워낙 독점적이었기에 MS가 아닌 것들은 사실 거들떠 볼 필요도 없던 시절이었다. 단지 MS것 내에서 이거냐 저거냐에 따라 차이가 있을 뿐. 그렇게 20년의 세월이 지난 요즘은 MS가 너무 초라해졌고 개발자는 넘나 피곤해졌다. 재미로 정리해보는 시대별 변천사…

2002

windows 95/98만 없으면 세상 편해질 것 같았던 시절, VxD는 인간이 코딩하라고 만든 것일까?

IsWindows9x()

2008

windows 2000에는 뭐가 이렇게 부족한게 많은 건지. 2000만 제거할 수 있다면 제품의 일관성을 유지하기가 한결 편할 것 같았던 시절.

IsWindows2k()
IsWindows9x()

2015

어느덧 XP는 구시대의 유물이 되었고, 지원 안되는 기능은 너무나 많고, 심지어 시스템 고유 기능들 조차도 지원 안되는 것들이 많았던 시절. 슬슬 컴파일러들도 XP를 손절각을 보던 시기.

IsWindowsXP()
IsWindows2k()

2016

64비트 운영체제가 일반화 되는 시기. 하지만 아직 대부분의 프로그램은 32비트. wow64처리가 안드로메다로 가는 시절. MS가 만든 에뮬레이팅 레이어를 벗어나기 위한 처절한 몸부림. 왜 이런게 생겼을까? 그냥 32/64만 있었으면 세상 편하겠구만…

IsWow64()
IsWindowsXP()
IsWindows2k()

2017

누군가 wow64에 존재하는 천국의 문을 발견하면서 32비트 프로그램에서 64비트 코드를 직접 구동하는 것이 가능해진 시기. 진짜 64비트 시스템인지 판별하는 코드들이 삽입되고, 32비트 프로그램이 메모리 상에서 64비트 코드를 직접 실행하면서 32/64 포인터 변환 헬게이트가 열림.

IsNative64()

IsWow64()
IsWindowsXP()

2020

wow64는 양반이었다. arm이라뉘. chpe는 또 무엇. 심지어 이건 당연한 소리겠지만 천국의 문 따윈 없다. 대중화되지 않았지만 실리콘 맥으로 대중화의 물꼬가 트일거 같은 느낌적인 느낌. 인텔만 있을때가 꿀이었던 것인가??

IsWindowsOnArm()

IsNative64()
IsWow64()
IsWindowsXP()

2022

윈도우만 있던 시절은 세상 편했다. 온갖 윈도우 포트 레이어 wine, proton, 네이티브 리눅스, 맥, 안드로이드, iOS가 난무하는 세상이란. 2022년의 게임 보안 개발자는 월요일은 온갖 윈도우 인텔/암/32/64/wow64/xp, 화요일은 리눅스와 각종 포트 레이어 linux/proton/wine, 수요일은 안드로이드, 목요일은 iOS/macOS를 개발해야 하는 세상이 돼 버렸다. 여기에 더 무서운 건 윈도우는 인사이더 빌드로 수시로 내부 구조체와 함수 구조를 바꾸고, 안드로이드와 iOS는 빼먹지 않고 매년 대규모 업데이트를 단행한다는 것…

IsWine()
IsProton()
IsMacOS()
IsLinux()
IsAndroid()
IsiOS()

IsWindowsOnArm()
IsNative64()
IsWow64()
IsWindowsXP()

금요일은? 놀 순 없지. 어서와 LLVM은 처음이지… Xcode가 이렇게 자주 업데이트 되는 줄 몰랐어? LLVM 애플 버전은 업스트림에 반영하지 않는 거도 몰랐어? 그럼 지금부터 LLVM 지옥문을 맛보도록 하자.

IsTripleAndroid()
IsTripleiOS()
IsTripleMacOS()

주말은? 새나라의 게임 보안 프로그래머라면 콘솔 개발해야지…

IsXbox()
IsPS()
IsNSW()

20년간 우리가 버릴 수 있었던 if문은 IsWindows9x와 IsWindows2k 단 두 개 밖에 없었다. 새로 추가된 if문들을 보면 눈물이…

그럼에도 긍정적으로 바라보자면 우리에겐 github, slack, aws가 생겼다는거…

[시스템] 커널 모드 드라이버 삭제에 부쳐

Wed, 13 Apr 2022 12:00:01 GMT

최근에 드라이버 코드를 개발하면서 새로 들어온 개발자와 다소 의견 차이가 있었다. 내가 드라이버 파일이 삭제된 경우에는 어떻게 할거냐고 물었는데 그 친구는 계속 로드된 드라이버 파일이 삭제되지는 않는다는 이야기를 했다. 아니? 뭐지? 일반적으로 커널 모드 드라이버 파일은 로딩을 완료한 후에는 자유롭게 삭제가 된다. 특수한 처리 방식이 있는 게 아니고 아래와 같은 코드로 간단하게 구현할 수 있다.

LoadDriver(path);
DeleteFile(path);

그래서 혹시 그 친구가 테스트를 안해본게 아닌가 해서 이만저만하게 해서 테스트를 해보라고 했더니 테스트 했는데 삭제가 안된다고 한다. 아니? 그럴수가? 그래서 나도 테스트 해봤는데 삭제가 되지 않았다. 이 무슨 시츄레이션이지…

해서 Windows 7에서 테스트를 해봤다. 역시나 삭제가 잘됐다. ~~그래서 혹시나 해서 Windows 10 TH1에서 테스트를 해봤다. 역시나 삭제가 잘 됐다.~~ TH1 이후 어딘가부터 윈도우 구조가 바뀌면서 드라이버 파일이 삭제가 되지 않도록 변경된 것으로 보였다.

그 친구는 개발을 배울 당시가 해당 윈도우 버전이라 파일이 삭제된다는 걸 본적이 한번도 없었고, 나는 Windows XP부터 개발을 했던 사람이라 삭제가 안된다는 걸 최근에 테스트한 적이 없었던 것이다. 그래서 혹시나 해서 드라이버 개발을 전문적으로 하는 사람한테 물어봤더니 역시나 몰랐다. 고인물들이란 ㅎㅎ^^

그럼에도 이 모든 걸 뚫고 최신 버전 윈도우에도 파일이 없는 드라이버가 상주한 것들이 몇 개 있었다. 당췌 얘들은 뭐지 해서 검색해봤더니 레이몬드 첸 아저씨가 2016년에 이미 다 알려준 내용들.

https://devblogs.microsoft.com/oldnewthing/20160913-00/?p=94305

고인물들의 지식은 업데이트된지 너무 오래 되었고, 새로 배우는 친구들은 역사를 알기가 어렵다. 그와중에 MS 개발자들은 너무 열일하신다는거…

덧) windows 10 th1 부터 변경된 것으로 보여집니다. feat KINUX

[cpp] strcpy_s에서 예외가 잡히지 않는 이유

Tue, 12 Apr 2022 12:00:01 GMT

어제 직원이 strcpy_s를 사용하면 예외가 잡히지 않는다며 코드를 보내왔다. 아래 코드다. 어떻게 컴파일하든 catch가 출력되는 것을 볼 수 없다. strcpy_s대신 strcpy를 하면 잘 된다는 이야기.

#include <Windows.h>

int main()
{
    __try
    {
        strcpy_s(0, 10, "aaaa");
    }
    __except(EXCEPTION_EXECUTE_HANDLER)
    {
        printf("catch\n");
    }
}

그래서 알아보기로 했다. 왜 예외가 잡히지 않는지를… strcpy_s는 다음과 같이 구현되어 있다.

extern "C" errno_t __cdecl strcpy_s(
    char*       const destination,
    size_t      const size_in_elements,
    char const* const source
    )
{
    return common_tcscpy_s(destination, size_in_elements, source);
}

common_tcscpy_s로 들어가보면 다음과 같다.

// _strcpy_s() and _wcscpy_s()
template <typename Character>
_Success_(return == 0)
static errno_t __cdecl common_tcscpy_s(
    _Out_writes_z_(size_in_elements) Character* const destination,
    _In_                                 size_t const size_in_elements,
    _In_z_                     Character const* const source
    ) throw()
{
    _VALIDATE_STRING(destination, size_in_elements);
    _VALIDATE_POINTER_RESET_STRING(source, destination, size_in_elements);

    Character*       destination_it = destination;
    Character const* source_it      = source;

    size_t available = size_in_elements;
    while ((*destination_it++ = *source_it++) != 0 && --available > 0)
    {
    }

    if (available == 0)
    {
        _RESET_STRING(destination, size_in_elements);
        _RETURN_BUFFER_TOO_SMALL(destination, size_in_elements);
    }
    _FILL_STRING(destination, size_in_elements, size_in_elements - available + 1);
    _RETURN_NO_ERROR;
}

_VALIDATE_STRING 매크로에서 destination이 NULL인 경우 체크가 들어간다는 것을 알 수 있다.

/* validations */
#define _VALIDATE_STRING_ERROR(_String, _Size, _Ret) \
    _VALIDATE_RETURN((_String) != NULL && (_Size) > 0, EINVAL, (_Ret))

#define _VALIDATE_STRING(_String, _Size) \
    _VALIDATE_STRING_ERROR((_String), (_Size), EINVAL)

_VALIDATE_RETURN 매크로는 _INVALID_PARAMETER 호출로 이어진다.

#define _VALIDATE_RETURN(expr, errorcode, retexpr)                             \
    {                                                                          \
        int _Expr_val = !!(expr);                                              \
        _ASSERT_EXPR((_Expr_val), _CRT_WIDE(#expr));                           \
        if (!(_Expr_val))                                                      \
        {                                                                      \
            *_errno() = (errorcode);                                           \
            _INVALID_PARAMETER(_CRT_WIDE(#expr));                              \
            return (retexpr);                                                  \
        }                                                                      \
    }

_INVALID_PARAMETER는 릴리즈 버전에서 _invalid_parameter_noinfo 호출로 이어진다.

#ifdef _DEBUG
    #define _INVALID_PARAMETER(expr) _invalid_parameter(expr, __FUNCTIONW__, __FILEW__, __LINE__, 0)
#else
    #define _INVALID_PARAMETER(expr) _invalid_parameter_noinfo()
#endif

_invalid_parameter_noinfo는 최종적으로 _invalid_parameter_internal 호출로 이어진다.

extern "C" void __cdecl _invalid_parameter_noinfo()
{
    _invalid_parameter(nullptr, nullptr, nullptr, 0, 0);
}

extern "C" void __cdecl _invalid_parameter(
    wchar_t const* const expression,
    wchar_t const* const function_name,
    wchar_t const* const file_name,
    unsigned int   const line_number,
    uintptr_t      const reserved
    )
{
    __crt_cached_ptd_host ptd;
    return _invalid_parameter_internal(expression, function_name, file_name, line_number, reserved, ptd);
}

_invalid_parameter_internal을 살펴보면 다음과 같다. _thread_local_iph 핸들러가 있는 경우 해당 핸들러를, 없는 경우 글로벌 핸들러를, 그마저도 없는 경우에는 _invoke_watson으로 이어진다. 일반적으로 핸들러 설정이 되어 있지 않기 때문에 _invoke_watson 호출로 진행된다.

extern "C" void __cdecl _invalid_parameter_internal(
    wchar_t const*     const expression,
    wchar_t const*     const function_name,
    wchar_t const*     const file_name,
    unsigned int       const line_number,
    uintptr_t          const reserved,
    __crt_cached_ptd_host&   ptd
    )
{
    __acrt_ptd * const raw_ptd = ptd.get_raw_ptd_noexit();
    if (raw_ptd && raw_ptd->_thread_local_iph)
    {
        raw_ptd->_thread_local_iph(expression, function_name, file_name, line_number, reserved);
        return;
    }

    _invalid_parameter_handler const global_handler = __crt_fast_decode_pointer(__acrt_invalid_parameter_handler.value(ptd));
    if (global_handler)
    {
        global_handler(expression, function_name, file_name, line_number, reserved);
        return;
    }

    _invoke_watson(expression, function_name, file_name, line_number, reserved); <== null 인경우 이쪽으로 도달
}

_invoke_watson은 다음과 같이 구현되어 있다. 일반적으로 PF_FASTFAIL_AVAILABLE 플래그가 설정되어 있어서 __fastfail 호출로 이어진다.

extern "C" __declspec(noreturn) void __cdecl _invoke_watson(
	wchar_t const* const expression,
	wchar_t const* const function_name,
	wchar_t const* const file_name,
	unsigned int   const line_number,
	uintptr_t      const reserved
	)
{
	UNREFERENCED_PARAMETER(expression   );
	UNREFERENCED_PARAMETER(function_name);
	UNREFERENCED_PARAMETER(file_name    );
	UNREFERENCED_PARAMETER(line_number  );
	UNREFERENCED_PARAMETER(reserved     );

	if (IsProcessorFeaturePresent(PF_FASTFAIL_AVAILABLE))
	{
		__fastfail(FAST_FAIL_INVALID_ARG);
	}

	// Otherwise, raise a fast-fail exception and termintae the process:
	__acrt_call_reportfault(
		_CRT_DEBUGGER_INVALIDPARAMETER,
		STATUS_INVALID_CRUNTIME_PARAMETER,
		EXCEPTION_NONCONTINUABLE);

	TerminateProcess(GetCurrentProcess(), STATUS_INVALID_CRUNTIME_PARAMETER);
}

__fastfail은 아래 문서를 참고하면 int 0x29로 구현된 컴파일러 함수다.
https://docs.microsoft.com/en-us/cpp/intrinsics/fastfail?view=msvc-170

결국 strcpy_s는 최종적으로 int 0x29로 이어진다. fastfail이란 말에서 알 수 있듯이 해당 인터럽트는 예외에 잡히지 않는다. 결국 strcpy_s 내부적으로 널체크를 해서 특수한 처리를 했기 때문에 예외에 잡히지 않는다. strcpy_s((char*)0x123, 10, "aaaa"); 등과 같이 호출하면 정상적으로 예외 처리가 이루어진다.

int main()
{
    __try
    {
        asm int 0x29
    }
    __except(EXCEPTION_EXECUTE_HANDLER)
    {
        printf("catch\n");
    }
}

strcpy_s 입장에서는 NULL이면 프로그램을 종료시켜버리는 게 안전한 구현일 수 있다. 하지만 경우에 따라서는 오바하는 함수가 될수도 있겠다. 내가 알아서 할건데 왜 고작 문자열 복사하는 기능만 하면 될 함수가 릴리즈 버전에서 널체크까지 해가며 멋대로 강종시키지? 프로그램을? 예외처리도 안되게?

[리뷰] 미드나잇 라이브러리

Sat, 29 Jan 2022 13:00:01 GMT

저자

매트 헤이그, 영국 소설가. 우울증과 불안 장애로 자살 시도를 하고 극복한 경험이 있음. 그래서 관련된 내용에 관한 저술이 많아 보인다. 미드나잇 라이브러리도 그런 연장선상의 책이다.

줄거리

주인공 노라는 되는 일이 없다. 재능은 많았지만 많은 것들을 포기했다. 게다가 우울증과 불안장애 증상까지 있다. 키우던 고양이가 죽고, 직장을 잃으며 삶의 나락으로 몰린 주인공은 자살 시도를 한다. 그리고 자살 시도 과정에서 삶과 죽음의 중간 단계에 있는 미드나잇 라이브러리에 간다.

미드나잇 라이브러리에서는 노라가 사는 동안 후회했던 것들을 바꾼 다양한 삶을 경험해 보게 된다. 그 경험한 삶이 마음에 든다면 그곳에서 살아도 되고, 마음에 들지 않는다면 다시 라이브러리로 돌아올 수 있다. 노라는 올림픽 메달리스트가 되기도 하고, 성공한 록밴드 작곡가 겸 보컬이 되기도 하고, 빙하학자가 되기도 한다.

이런 온갖 다양한 삶을 경험하면서 역설적이게도 노라는 삶의 이유를 깨닫는다 그리고 다시 원래의 삶으로 돌아오고 거기서 아직 쓰지 못한 자신의 인생 이야기를 계속 써내려 간다.

인상 깊은 구절

모든 게 달라진 이유는 이젠 그녀가 단지 다른 사람의 꿈을 이뤄주기 위해 존재하지 않기 때문이었다. 상상 속 완벽한 딸이나 동생, 애인, 아내, 엄마, 직원, 혹은 무언가가 되는 데서 유일한 성취감을 찾아야 한다고 생각하지 않기 때문이었다. 이제는 그저 한 인간으로서 자신의 목표만 생각하며 자신만 책임지면 그만이었다.

노라는 자신이 블랙홀이 아니라는 결론을 내렸다. 그녀는 화산이었다. 그리고 화산처럼 그녀는 자신에게서 달아날 수 없었다. 거기 남아서 그 황무지를 돌봐야 했다.
역설적이게도 화산은 파괴의 상징인 동시에 생명의 상징이다. 용암이 흘러내리는 속도가 느려지고 열이 식으면, 용암은 응고되었다가 시간이 흐르면서 부서져 흙이 된다. 비옥하고 영양가가 풍부한 토양이 된다.
자기 자신 안에 숲을 가꿀 수 있었다.

“이번 판은 선생님이 이기겠는데요.” 노라가 말했다.
엘름 부인의 눈동자가 갑자기 생기를 띠며 반짝거렸다. “그게 체스의 미덕 아니니? 어떻게 끝날지 모른다는 거.”
노라는 아직 체스판에 남아 있는 자신의 기물을 내려다보며 미소 짓고, 다음 수를 어떻게 둘지 생각했다.

노라는 다이아몬드에 대한 닐의 잘못된 지식을 바로잡아주지 않았다. 석탄과 다이아몬드는 둘 다 탄소이기는 해도 석탄은 불순물이 너무 많이 섞여서 아무리 압력을 가해도 다이아몬드가 될 수 없다. 광물학에 따르면 한 번 석탄은 영원한 석탄이다. 어쩌면 그게 현실적인 교훈일 것이다.

그녀가 둔 모든 수는 실수였고, 모든 결정은 재앙이었으며, 매일 자신이 상상했던 모습에서 한 걸음씩 멀어졌다.
수영 선수. 뮤지션. 철학가. 배우자. 여행가. 빙하학자. 행복하고 사랑받는 사람.
그중 어느 것도 되지 못했다.
심지어 ‘고양이 주인’이라는 역할조차 제대로 해내지 못했다. 혹은 ‘일주일에 한 시간짜리 피아노 레슨 선생님’도. 혹은 ‘대화가 가능한 인간’도.

난 올림픽에 출전하지 못했어. 빙하학자가 되지 못했어. 댄의 아내가 되지 못했어. 엄마가 되지 못했어. 라비린스의 리드 보컬도 되지 못했어. 정말로 좋은 사람 혹은 행복한 사람이 되지 못했어. 볼테르도 제대로 보살피지 못했어.
그리고 이제 마지막으로 제대로 죽지도 못했다.

“모든 삶에는 수백만 개의 결정이 수반된단다. 중요한 결정도 있고, 사소한 결정도 있지. 하지만 둘 중 하나를 선택할 때마다 결과는 달라져. 되돌릴 수 없는 변화가 생기고 이는 더 많은 변화로 이어지지. 이 책들은 네가 살았을 수도 있는 모든 삶으로 들어가는 입구야.”

“걱정 마라. 화장지는 인생과 같아. 늘 더 있는 법이야.”

댄에게는 장점이 훨씬 많았다. 아픈 노라의 엄마에게 극진히 대했고, 어떤 주제에 관해서든 편안히 이야기할 수 있었고, 미래에 대한 꿈으로 가득 찼으며, 매력적이고 함께 있으면 편안했다. 또한 예술을 열렬히 사랑했고, 길에서 노숙자를 보면 늘 걸음을 멈추고 얘기를 나눴다. 세상에 관심을 가졌다. 사람은 도시와 같아서 마음에 덜 드는 부분이 몇 개 있다고 해서 전체를 거부할 순 없다. 위험해 보이는 골목길이나 교외 등 마음에 안 드는 부분이 있을지라도 다른 장점이 그 도시를 가치 있게 만들어준다.

“왜냐하면 노라, 때로는 살아봐야만 배울 수 있으니까.”

읽은 후

읽기는 굉장히 편한 책이다. 서사 구조가 복잡하지 않고 단조롭고 교훈적이다. 그리고 한 100페이지쯤 읽으면 책 내용이 어떻게 전개될지는 대충 예측이 된다. 심지어 마지막에 현재 삶을 의미하는 책을 찾겠다는 것까지.

다만 소설적인 재미를 떠나 소설이 제공하려는 교훈을 끌어내는 측면에서 바라보자면 너무 급진적인 측면이 있는 건 아닌가라는 생각이 든다. 많은 인생을 경험하고 후회를 되돌려본 인생이 자기 생각과 달랐다는 측면이 있었다는 것까지는 이해가 된다. 하지만 그런 다양한 인생 경험을 토대로 블랙홀로 생각했던 내 인생이 화산이었다고 바라보는 시각을 변경하는 과정은 개연성이 충분한가 라는 생각이 든다.

살아봐야만 배울 수 있는 것들이 있다. 또 아직 끝나지 않았다면 인생은 끝날 때까지 어떤 게임이 될지는 알 수 없다. 어떤 게임이 되었든 그것도 멋진 한 판의 바둑이었을 것이다. 다만 현실적인 생각을 조금 해보자면 게임이 진행될수록 경우의 수는 급격히 줄어든다는 점이다. 바둑판에 돌이 많이 있을 수록 경우의 수는 점점더 제한된다. 체스판의 기물이 줄어들수록 경우의 수 또한 급격하게 줄어든다. 그래서 시작은 무한한 가능성을 가진 한판의 게임이 펼쳐질 가능성이 있겠지만 중반을 넘어서면 사실상 경기의 궤도는 어느 정도 정해진 경우가 대다수다. 따라서 끝날 때까지 끝난 건 아니고, 어떤 게임이 될지 알 수 없다는 말처럼 희망이 있을 수 있겠지만 현실적으로는 게임이 진행될 수록 삶이 진행될수록 선택할 수 있는 선택지와 그 선택으로 벌어질 수 있는 희망의 가능성은 줄어든다.

저자와 달리 나는 시뮬레이션 우주론과 결정론적 세계관을 가지고 있고, 자유의지는 없다고 믿는 편이다. 그런 나에겐 테드 창의 조언이 조금 더 현실적이란 생각이 많이 들었다.

자유의지가 있는 것처럼 행동하라. 설령 사실이 아님을 알고 있어도, 스스로 내리는 선택에 의미가 있는 듯이 행동하는 것이 가장 중요하다. 무엇이 현실인지는 중요하지 않다. 정말로 중요한 것은 당신이 무엇을 믿느냐이며, 이 거짓말을 믿는 것이야말로 깨어 있는 혼수상태에 빠지는 것을 피할 수 있는 유일한 방법이다. 문명의 존속은 이제 자기기만에 달려 있다. 어쩌면 줄곧 그래 왔는지도 모른다.

-- 숨(우리가 해야 할 일) | 테드 창

이책과 비슷한 내용으로 훨씬 극적으로 삶의 의지를 불태우게 해주는 컨텐츠로 K드라마 “나의 아저씨”를 추천하고 싶다. 어쩌면 복잡한 내용을 떠나서 우리 모두가 듣고 싶은 이야기는 결국 이 한 마디가 아닐까. 괜.찮.아...

[리뷰] 호모 데우스

Tue, 25 Jan 2022 13:00:01 GMT

간단한 소개, 동기, 저자에 관하여

유발 하라리는 사피엔스라는 책으로 일약 스타덤에 오른 역사학자다. 사피엔스는 호모 사피엔스가 어떻게 다른 호모 종들을 제치고 이 세상을 지배하는 종이 되었는지에 대한 그의 충걱적인 가설 및 서사를 들려주는 책이다. 아마도 그의 가설과 서사가 굉장히 그럴듯하고 충격적이었기에 많은 사람들의 공감과 관심을 받지 않았을까 싶다.

호모 데우스는 그런 그가 호모 사피엔스의 다음 단계, 즉 앞으로 펼쳐질 미래 세상에 대한 이야기를 하는 책이다. 흔히들 미래를 알기 위해서는 과거를 알아야 한다는 말을 한다. 과거를 충실히 연구했고 호모 종이 지배종이 될 수 있었던 충격적인 서사를 들려준 그가 바라보는 미래는 어떤지 궁금해서 이 책을 선택하게 되었다.

인상 깊은 내용

오늘날 정설에 따르면 유기체는 알고리즘이고, 알고리즘은 수학 공식으로 표현할 수 있다. 자판기가 차 한 잔을 만들기 위해 밟는 일련의 단계들 그리고 우리의 뇌가 사자의 접근에 촉각을 곤두세울 때 밟는 일련의 단계들을 우리는 숫자와 수학 기호를 사용해 적을 수 있다. 그렇다면, 그리고 의식적 경험들이 어떤 중요한 기능을 한다면, 그 경험들 역시 수학적으로 표현할 수 있어야 한다. 왜냐하면 경험은 알고리즘의 필수적 부분이기 때문이다. ‘두려움 알고리즘’을 적고 ‘두려움’을 일련의 정확한 계산식으로 쪼개면 이렇게 말할 수 있다. ‘계산 과정의 93단계, 바로 이곳이 두려움이라는 주관적 경험이 개입하는 곳이다!’ 하지만 수학이라는 거대한 영역에 주관적 경험을 포함하는 알고리즘이 존재할까? 우리가 알기로 그런 알고리즘은 없다. 수학과 컴퓨터 과학 분야의 방대한 지식을 총동원해봐도, 우리가 창조한 데이터 처리 장치 가운데 그 어떤 것도 작동을 위해 주관적 경험이 필요한 것은 없고, 그 어떤 것도 고통, 쾌락, 분노, 사랑을 느끼지 않는다.

유기체가 알고리즘이고 주관적 경험은 실질적으로 필요 없다는 그의 주장은 파격적으로 들린다. 하지만 많은 최신 연구에 따르면 자유의지가 없다는 진영이 승리하는 것은 맞는 것처럼 보여지고 있다. 우리는 어떤 선택을 의식하기 전에 뇌는 이미 결정을 끝냈으며, 의식은 마치 그 끝낸 결정에 대한 그럴듯한 보충 설명을 해주는 것에 지나지 않는다고 한다. 또한 현재까지는 의식의 존재 자체가 미스테리이긴 하지만 인공지능 기술이 발전하면서 일정 수준의 복잡도를 넘어서는 순간 인공지능에서도 의식이 발현될 것으로 예측하고 있다. 어쨌든 유기체는 알고리즘이라는 정설을 받아들이는 순간 나는 무엇인가라는 생각이 저절로 따라오게 된다. MMORPG 게임 존재하는 NPC와 내가 다를 게 무엇일까?

그러면 구글은 이렇게 대답할 것이다. "나는 네가 태어난 날부터 너를 알고 있었어. 네 이메일을 모두 읽었고, 네 통화를 모두 기록했고, 네가 좋아하는 영화들, 네 유전자 정보, 네 심장 기록도 모두 갖고 있어. 네가 데이트한 정확한 날짜도 보관하고 있으니, 존이나 폴과 만날 때마다 네 심장박동, 혈압, 혈당수치를 초 단위로 기록한 그래프를 원한다면 보여줄 수 있어. 필요하다면 네가 그들과 가진 모든 성관계의 정확한 순위도 제공할 수 있어. 그리고 당연히 나는 너를 아는 것만큼 그들도 잘 알아. 이 모든 정보, 내 뛰어난 알고리즘, 수많은 관계에 대한 수십 년에 걸친 통계자료를 토대로, 나는 너에게 존을 선택하라고 권해. 장기적으로 그와 함께할 때 더 만족스러울 확률이 87퍼센트야."

"나는 너를 잘 아는데, 너는 이 답변이 마음에 들지 않을 거야. 존보다 폴이 훨씬 더 잘생겼지. 너는 외모를 중시하니까, 내가 '폴'이라고 말해주기를 내심 바랐을 거야. 물론 외모는 중요하지. 하지만 네가 생각하는 것만큼은 아니야. 수만 년 전 아프리카 사바나에서 진화한 네 생화학적 알고리즘은 배우자감을 전반적으로 평가할 때 외모에 두는 비중이 35퍼센트야. 하지만 최신 연구와 통계를 바탕으로 하는 내 알고리즘은 외모가 사랑하는 관계에 장기적으로 미치는 영향은 14퍼센트에 불과하다고 말해. 그러니 폴의 외모를 고려한다 해도 네가 존과 함께하는 게 더 낫다고 생각해."

이런 충실한 상담 서비스를 받는 대가로 우리가 포기해야 하는 것은 인간은 분할할 수 없는 존재이며 각 개인은 무엇이 선이고 무엇이 아름다움이고 무엇이 인생의 의미인지 결정할 자유의지를 갖고 있다는 개념뿐이다. 인간은 더 이상 이야기하는 자아가 꾸며내는 이야기들의 지시를 따르는 자율적 실체들이 아니라, 거대한 전 지구적 네트워크의 필수불가결한 일부가 될 것이다.

미래 세계에 대한 그의 묘사 중 일부지만 내용이 다소 충격적인 것과 동시에 몇년 내에 저런 세상이 올지도 모른다는 생각에 굉장히 인상 깊었다. 구글 나우라는 기술은 지금도 켜두기만 하면 내가 자료를 입력하지 않아도 내 회사가 어디있고, 집이 어디있으며, 내가 수요일 저녁 시간에 어떤 공간에 있을 확률이 높고, 내가 좋아하는 음악이 무엇인지 등을 알려준다. 유발 하라리가 전개한 것과 같은 기술은 어쩌면 우리가 개인 정보 동의를 하는 순간부터 계속 진행되고 있는지도 모른다.

과연 저런 세상이 펼쳐졌을때 우리는 인공지능의 선택에 저항할 수 있을까? 내 생각은 쉽지 않다는 생각이다. 왜냐하면 지금도 사람들은 초행길을 갈 때에 아무 생각없이 네비게이션이 우회전을 하라면 믿고 우회전을 하기 때문이다. 심지어 초행길이 아닌 길도 우회전을 하라고 하면 이 길이 더 빨라서 그런가? 하고는 생각없이 우회전을 한다. 주차를 할 때에도 본인의 느낌보다는 센서의 삑삑 소리에 더 의존하고 있다. 이런 세상은 가속화 될 것이고 우리는 점점 더 자유의지가 없는 것 같은 존재가 될지도 모른다. 그 시대가 된다면 과연 나란 무엇인지? 우리의 자유의지가 존재하긴 하는 것인지? 인공지능이 모든 선택을 대체한다면 삶의 의미는 무엇인지가 궁금해지는 대목이다.

코타나가 신탁에서 대리인으로 진화하면 주인들 대신 자기들끼리 직접 이야기하기 시작할 것이다. 처음에는 내 코타나가 당신의 코타나에게 연락해 약속 장소와 시간을 잡는 것과 같은 단순한 일로 시작할 것이다. 하지만 어느 순간 정신을 차리고 보면, 내가 입사 지원한 회사의 인사팀장이 나에게 이력서를 보낼 필요 없이 자신의 코타나가 내 코타나를 면접 볼 수 있도록 해달라고 말한다. 또는 나에게 관심 있는 이성의 코타나가 내 코타나에게 접근해 서로 정보를 교환하며 두 사람이 좋은 짝인지 결정한다. 물론 이 모든 일은 그들의 주인들이 전혀 모르는 상태에서 이루어질 것이다.

코타나가 권한을 얻으면 주인의 이익을 위해 상대의 코타나를 교묘히 조종하기 시작할 것이고, 그 결과 직업시장 또는 결혼시장에서의 성공이 점점 더 코타나의 자질에 따라 판가름날 것이다. 그래서 최신 버전의 코타나를 소유한 부자들은 구버전을 소유한 가난한 사람들보다 결정적 우위를 점할 것이다.

장자의 호접지몽 이야기가 생각나는 대목이다. 나비 꿈을 꾸고 깨어보니 지금이 현실인지, 나비가 꾸는 꿈인지 구분이 되지 않는다는 이야기. 코타나가 대리인이 되는 순간 코타나가 나인지, 내가 코타나인지 구분할 수 있을까? 모든 선택과 결정을 코타나가 한다면 과연 그가 나의 인공지능 비서일까? 내가 그의 아바타일까?

자유주의가 직면한 세 번째 위협은, 일부 사람들은 업그레이드되어 필수불가결한 동시에 해독 불가능한 존재로 남아 소규모 특권집단을 이룰 거라는 점이다. 이런 초인간들은 전대미문의 능력과 전례 없는 창의성을 지닐 것이고, 그런 힘을 이용해 세계적으로 중요한 대다수의 결정들을 계속 내릴 수 있을 것이다. 그들은 시스템의 유지보수를 담당할 것이고, 시스템은 그런 사람들을 이해하고 관리할 수 없을 것이다. 그러나 대부분의 사람들은 업그레이드되지 않을 것이고, 그 결과 컴퓨터 알고리즘과 새로운 초인간 양쪽의 지배를 받는 열등한 계급이 될 것이다.

인간은 항상 계층을 나눠왔다. 누가 힘이 센지와 같은 유전자에 의해서 나누다가, 누구의 아들 딸인지 같은 출신 성분에 의해서 나누다가, 누가 시험을 통과했는지와 같이 능력에 의해서 나누다가, 누가 자본을 더 가졌는지와 같이 돈에 의해서 나누는 등. 문명이 시작된 이후 인간이 실질적으로 평등했던 순간은 없었다는 생각이다. 그의 예측대로라면 그렇다면 앞으로는 시스템을 이해하고 설계할 수 있는 계층과 그렇지 않은 계층으로 나뉘게될까?

첫째, 의학은 중대한 개념적 혁명을 겪고 있는 중이다. 20세기에 의학의 목표는 병에 걸린 사람을 치료하는 것이었다. 하지만 21세기에 의학의 목표는 건강한 사람의 성능을 높이는 쪽(업그레이드)으로 가고 있다. 병든 사람을 치료하는 것은 평등주의적 목표였다. 왜냐하면 모두가 누릴 수 있고 누려야 하는 육체적ㆍ정신적 건강의 표준이 존재한다는 전제에서 출발했기 때문이다. 만약 어떤 사람이 그 표준 밑으로 떨어지면, 문제를 고쳐서 그 사람이 ‘다른 모든 사람들과 같아지게’ 만드는 것이 의사의 본분이었다. 반면 건강한 사람을 업그레이드하는 것은 엘리트주의적 목표이다. 모두에게 적용되는 보편적 표준이라는 개념을 거부하고, 일부 개인들에게 우위를 제공하려는 일이기 때문이다. 사람들은 뛰어난 기억력, 평균 이상의 지능, 최고의 성적 능력을 원한다. 만일 어떤 형태의 업그레이드가 저렴하고 흔해져서 누구나 접근할 수 있는 것이 된다면, 그것이 새로운 기준점이 되어 그것을 능가하는 차세대 치료법이 개발될 것이다.

유전자 가위 기술은 상당히 발전해 있다. 인공지능을 통한 업그레이드가 되지 않더라도 우리가 유전자 코드를 해독하면 할수록 더 뛰어난 유전자 코드를 스스로 만들어 내는 길을 선택할지도 모른다.

읽은 후...

흔히들 미래를 인공지능, 사이보그의 세상이 될 것이라 얘기한다. 그리고 마치 그 세상은 모든 인류가 공통으로 그 혜택을 누리는 판타지 같은 세상일 것이라 얘기한다. 하지만 유발 하라리가 예측한 세상은 그렇지 않았다.

전체적으로 그는 1) 유기체로써의 인간의 진화는 지금이 끝이다. 2) 그 이후 단계는 인공지능과, 사이보그 기술을 이용해 일부 인간들이 초인간으로 업그레이드 될 것이다. 3) 그 초인간들의 업그레이드가 완료되면 기존의 인간들은 더이상 쓸모 없는 잉여 인간이 될 것이다. 4) 그 초인간들 조차도 상당수가 인공지능의 도움으로 스스로 결정할 것이 없는 세상이 될 것이다. 5) 유기체로써의 모든 부분이 제거되고 나면 우주로 나갈 수 있는 진정한 초인간의 시대가 열린다고 말한다.

디스토피아적 미래지만 상당히 그럴듯한 전개라고 생각한다. 엘론 머스크는 벌써 뉴럴 링크를 통해서 뇌에 인공지능 칩을 심는 실험을 하고 있다. 아마 그 실험이 성공적으로 끝난다면 우리는 머지 않아서 영어 기능을 제공하는 칩을 몇 백 달러에 사게 될지도 모른다. 그리고 각종 기능들이 칩으로 제공될 것이고 그것은 점점 더 그 칩을 가진 사람들과 못 가진 사람들의 격차를 벌리게 될 것이다. 이렇게 초인간과 불필요한 인간으로 나뉘는 세상이 오게 된다면 우리는 어떻게 대처해야 할까? 아직 그런 세상이 오지 않았고 내가 사는 기간 동안에는 안전할 것 같으니 괜찮은 것일까? 아니면 어떻게든 아등바등 그 초인간의 무리에 끼기 위해서 달려야 하는 것일까?

미래에 대한 선명한 지도같은 책이었지만 역설적이게도 이 책은 나에게 엄청난 질문 덩어리만 안겨준 책이었다. 그리고 그 중간에는 사람, 인간이 있었다. 과연 그 수많은 잉여 인간의 존재 가치는 무엇이 될까?

당신의 생각은?

유기체로써의 진화가 지금이 끝일지와 이유. 유전자 가위 vs 사이보그
초인간으로 진화되어 인간이 두 부류로 나뉘게될지와 이유.
저자의 생각대로 인간이 자체적으로 업그레이드해서 초인간이 된다고 했을 때 잉여 인간은 생존할까? 또 존재 가치는?
텍스트에 나온 존과 폴 중 인공지능의 선택대로 존을 선택할까? 아니면 마음이 끌리는 잘생긴 폴을 선택할까?
인공지능이 복잡한 의사 결정의 상당수를 대체한다고 했을때 인간의 존재가치는? 그리고 지금 현재 상태에서 자유의지가 있다고 믿는지? 아닌지? 그 이유는?
대체로 이런 이야기 끝에 불멸의 존재가 되기 위해 전뇌화, 또는 마인드 업로딩으로 불리는 뇌를 네트워크에 업로드 하는 이야기가 나온다. 만약 본인이 그런 업로드를 통해 영생을 누릴 수 있다면 업로드 할지 말지와 그 이유.
미래 방향 예측의 큰 갈래가 인간이 우주로 확장할 것이다와 메타버스 세계로 확장할 것이다로 나뉜다. 둘중 어떤 세상으로 확장할 가능성이 크다고 생각하는지와 그 이유.

[cpp] 버퍼로써 vector가 적합하지 않은 이유

Tue, 25 Jan 2022 12:00:01 GMT

C언어에서 동적 버퍼를 사용하던 코드를 C++로 포팅할 때 흔히 vector를 사용한다. 가장 편리하기 때문이다. 하지만 반복적으로 호출되는 코드일 경우 의외로 해당 코드 때문에 부하가 발생할 수 있다. 왜 그런지 살펴보고 더 적합한 C++ 객체가 없는지도 알아보자.

고정 버퍼

dir에 name을 붙여서 파일을 생성하는 흔한 C언어 코드다. 흔히들 이렇게 작성하기도 한다. 하지만 MAX_PATH가 왠지 걸린다. MAX_PATH면 충분할까? 제한도 없어진다는데? 더 긴 경로가 오면 어떻게 될까, 하는 불안감이 든다.

void CreateTempFile(const char* dir, const char* name)
{
	char path[MAX_PATH];

	StringCbCopyA(path, sizeof(path), dir);
	StringCbCatA(path, sizeof(path), name);

	CreateFileA(path, ...);
}

동적 버퍼

길이를 런타임에 계산해서 필요한 만큼 공간을 확보하도록 만들 수 있다. 아래 코드는 dir과 name에 어떤 길이의 문자열이 오더라도 잘 동작한다. 메모리만 있다면 말이다.

void CreateTempFile(const char* dir, const char *name)
{
	char *path;
	size_t size;
	
	size = strlen(dir) + strlen(name) + 1;
	path = malloc(size);
	if(!path)
	    return;
	
	StringCbCopyA(path, size, dir);
	StringCbCatA(path, size name);
	
	CreateFileA(path, ...);
	
	free(path);
}

vector

동적 버퍼를 요하는 코드를 C++로 바꿀 때 흔히 사용하는 객체가 벡터다. 간단하고 깔끔하고 사이즈 관리되고, 나무랄 때가 없는 것이다. 대체하기도 너무 심플하다. resize와 &vector[0]만 사용하면 만사 OK다.

C의 저급함과 C++의 고급함 사이의 가장 적절한 수준을 보여주는 것 같기도 하다. 하지만 한가지 문제가 있다. 이 코드가 그렇게 빠르지는 않다는 점이다. 왜냐하면 벡터는 내부적으로 공간을 확장할 때 모두 초기화를 시키기 때문이다. 사실상 우리는 초기화가 필요 없음에도 resize를 하는 순간 모든 공간이 초기화된다. 낭비다.

void CreateTempFile(const char* dir, const char *name)
{
	std::vector<char> path;
	
	path.resize(strlen(dir) + strlen(name) + 1);
	
	StringCbCopyA(&path[0], path.size(), dir);
	StringCbCatA(&path[0], path.size(), name);
	
	CreateFileA(path.get(), ...);
}

shared_ptr

벡터의 초기화를 피할 수 있는 한가지 대안은 shared_ptr이다. 다만 배열 해제를 위한 메모리 해제 코드를 별도로 작성해야 하는 불편함이 있다. 물론 사이즈도 별도로 트래킹을 해야 한다. 하지만 더이상 벡터가 가지고 있는 개별 아이템 초기화에 대한 부담은 없다. 하지만 또 포인터 소유권과 관련된 레퍼런스 카운트 체크에 대한 부담이 늘어난다.

void CreateTempFile(const char* dir, const char *name)
{
	size_t size;
	
	size = strlen(dir) + strlen(name) + 1;
	std::shared_ptr<char> path(new char[size], [](const char* p) { delete [] p; } );
	
	StringCbCopyA(path.get(), size, dir);
	StringCbCatA(path.get(), size, name);
	
	CreateFileA(path.get(), ...);
}

unique_ptr

또 다른 대안으로 unique_ptr을 사용할 수 있다. unique_ptr<[]>은 특수화가 되어 있어 사용하기도 무척 편리하며 vector와 같이 초기화 코드가 없기 때문에 빠르다. 게다가 레퍼런스 카운트 체크와 관련한 부하도 없기 때문에 더 빠르다. 지역 버퍼 용도로 쓰기에 가장 문안한 형태로 볼 수 있다.

void CreateTempFile(const char *dir, const char *name)
{
	size_t size;

	size = strlen(dir) + strlen(name) + 1;
	std::unique_ptr<char[]> path = std::unique_ptr<char[]>(new char[size]);

	StringCbCopyA(path.get(), size, dir);
	StringCbCatA(path.get(), size, name);
	
	CreateFileA(path);
}

[정보] 재테크 관련 유튜브

Mon, 24 Jan 2022 13:00:01 GMT

바야흐로 재테크 시대. 특히나 2020은 투자한 사람과 그렇지 않은 사람 사이의 자산 갭이 많이 발생한 한 해가 아니었나 싶다. 뭐라도 투자한 사람들은 수익률 올리기에 바쁘고, 들어서지 못한 사람들은 놓친 기회가 아쉬워 난리다. 하지만 기회는 언제든 다시 온다. 다가올 기회를 놓치기 싫다면 운전하면서 또는 심심할 때 보면 크게 도움될만한 재테크 채널들. 순서는 랜덤.

슈카월드

내일은 투자왕 - 김단테

삼프로TV_경제의신과함께

dp - Investor Unknown D.P.

박종훈의 경제한방

[소고] 코딩의 시대, 배움의 방식

Wed, 21 Jul 2021 12:00:01 GMT

올초 넥슨이 전직원 연봉을 일괄 인상하면서 인재 전쟁의 서막을 알렸다. 이후 각종 거의 모든 소위 잘나간다는 게임 업체들이 연봉 인상 러시에 동참하면서 코딩의 시대가 절정을 향해 가고 있음을 느끼게 해줬다. 그런 분위기를 반영하듯 페북에는 게임회사 직원을 대상으로 과외 선생님을 모신다는 광고가 연신 팝업된다.

일자리가 없어서 난리인 시대에 아이러니하게도 주변에서는 개발자를 못 구해서 난리다. 김국현님의 자바 두명 타세요를 보면서 암울한 미래를 예견했던 우리 세대에게 지금의 현실은 다소 생경하기도 하다. 어쨌든 이런 모든 혼란스러움을 뒤로 하고 현재를 정의한다면 프로그래머 전성 시대다. 직무를 불문하고 삼성전자의 입사 시험 과목으로 파이썬이 들어갔다니 두말하면 입아픈 것 같기도 하다.

그런만큼 요즘 사람들은 꿀 떨어지는 이 분야에 관심이 많다. 자연스레 그에 관한 비전공자들의 여러가지 질문을 받는다. 클래스101 이거 들으면 코딩할 수 있어? 유튜브 이거 보면 나도 프로그래머로 취직할 수 있을까? 거의 대부분 어디서 무엇으로 어떻게 공부하면 프로그래머가 된다거나 코딩을 할 수 있느냐는 질문이다. 그래서 주변을 둘러보며 이미 프로그래머가 된 다른 이들은 어떻게 배웠는지를 한 번 살펴봤다.

#0

A는 게임 테스트 아르바이트로 입사했다. 테스트 아르바이트라는 것이 대체로 그러하듯 컴퓨터로 게임을 할 줄 알면 입사 요건이 충족된다. 내가 알기로 A는 이쪽 전공이 아니고 교육을 받은 적도 없다. A가 코딩을 공부한 건 유튜브와 블로그였다. 테스트를 하면서 코딩 유튜브를 틀어놓고 보면서 공부를 했고, 그런 장면이 내부 툴 개발자 B의 눈에 띄었다. B는 A와 같이 개발을 해보고 싶다는 얘기를 했고, 내가 잃을 거라곤 깃헙 슬롯 비용 밖에는 없을것 같아서 그러라고 했다. 그렇게 A는 깃헙 권한을 획득했다.

최근에 A의 작업과 관련한 얘기들이 나와서 그가 커밋한 코드를 몇개 보았다. 유튜브로 공부한 거라고 생각하기에는 제법 필요한 코드를 필요한 장소에 올렸다. 물론 전공자가 아니라서 전공자도 어려워하는 스레딩 같은 것들과 관련해 잘못 이해하는 부분도 있는듯 보였지만 우리끼리 사용하는 내부 툴이라 크게 중요하진 않아 보였다. 어쨌든 A가 퇴근 후에도 얼마나 많은 시간을 공부에 할애했는지는 모르겠지만 아르바이트로 근무하면서 유튜브와 블로그로 코딩을 공부해서 실무에 써먹을 수준이 되었다는 건 제법 인상적이었다.

#1

C는 A가 개발을 할 수 있도록 만들어준 B의 후임이다. B는 병특이 끝나고 게임을 개발하고 싶다고 퇴사를 했다. 그래서 그의 후임을 뽑게 됐다. 병특이 가능해 제법 여러 친구를 면접 봤다. 걔중에는 소위 스카이 대학에 재학중인 친구도 두명 정도 있었다. 하지만 최종 합격한 친구는 다소 이 분야와는 인연이 없을 것 같은 이력의 C다.

C는 고등학교를 졸업하고 다양한 일을 했다. 그의 이력 중 가장 인상 깊었던 건 롯데리아 매니저였다. 어쨌든 그렇게 이일저일 하다가 그는 최근에 개발 관련 일자리가 많다는 걸 알고 국비 지원 자바 교육 과정을 5개월 이수했다. 그리고 지원한게 우리 회사였다. 아이러니하게도 그가 배운건 자바였지만 그가 지원한 포지션은 C#과 파이썬을 사용하는 자리였다. 파이썬은 면접 보기 전에 조금 공부했다고 했다. 그럼에도 그는 그 면접을 진행한 모든 사람을 통틀어 면접 문제를 다 푼 2명에 포함됐고 롯데리아 경력을 높게 평가받아 채용됐다.

C는 국비 지원 과정을 하기 전에 컴퓨터 관련 교육을 받은 적도 혼자 공부한 적도 없다고 했다. 물론 교육 과정 동안은 정말 치열하게 공부했다고 한다. 예전엔 사실 정부에서 웹프로그래머 일만명 키운다고 국비 교육 과정 만들고 할때에는 회의적인 생각이 많았지만 C를 보면서 생각이 좀 바뀌었다. 교육의 영향력과 밀도는 모두에게 다를 수 있고 기회가 제공될 수 있다는 측면에서 긍정적인 효과가 있다고 생각하게 됐다.

자바를 5개월 동안 공부했던 그는 선생님에게 하나를 잘 하면 다른 거도 금방 배운다는 얘기를 들었다고 했다. 틀린 말이 아니다. 어쨌든 좋은 선생님에게 배워서 그런지 그는 오늘도 C#으로 내부 툴을 고치고 업그레이드 한다. C는 어리다. 그래서 스펀지처럼 많은 것들을 흡수한다.

#2

E는 한국이 아닌 다른 아시아 국가 출신이다. 그는 고등학교를 중퇴했다. 대신 그 기간동안 독학으로 프로그래밍, 리버싱 등에 관한 공부를 했다고 한다. 그가 회사로 보낸 건 간단한 이력서와 깃헙, 블로그 링크였다. 그의 깃헙 링크는 그가 얼마나 훌륭한 코드를 쓸 수 있는지를 보여 주었고, 블로그는 그가 체계적인 글을 쓰는 능력이 있다는 걸 증명할만큼 충분했다. 그렇게 그의 기술 면접은 바이패스 됐다. 3년 정도 독학으로 공부했다는 그에게 특별한 공부 방법이 있었냐고 물어보자 그저 관심이 있어서 빨리 배울 수 있었다고 했다.

학부 시절 친한 후배에게서 정말 강려크한 인상을 받은 적이 있었다. 그 후배의 레드블랙 트리를 카피하던 순간이었다. 카피하다 말고 너무 잘 작성된 소스 코드 앞에서 눈물을 훔쳤다. 오프로 아는 다른 이의 코드를 보고 울었던 적은 그때가 처음이었고, 그 다음으로도 없었다. 그런 그가 공동 창업한 회사는 올해 카카오 모빌리티에 인수됐다. 오늘 E가 제출한 풀리퀘스트 코드를 보면서 그때가 떠올랐다. E는 20살이고, 고등학교 대신 3년을 독학한게 전부고, 그의 교재는 인터넷이다. 경력의 허무함과 신입의 가능성을 동시에 보여주는 그는 다소 신비한 존재다.

#3

F는 몇해전 회사에 근무했던 직원이다. 그는 특성화 고등학교를 졸업했고, 학창 시절부터 게임 해킹에 관심이 있어서 이것 저것 해보다 졸업과 동시에 입사를 했다. 그가 입사할 때 우리 회사의 손코딩 문제는 지금보다 어려웠음에도 그는 잘 풀었다. 선생님과 함께 회사를 왔었던 기억이 난다. 처음에는 서툴렀지만 그나이 사람들이 그렇듯 그는 금방 배웠고 에이스 자리를 꿰찾다. 우리는 그를 여포라 불렀다.

F는 특성화 고등학교를 졸업했지만 정규 교육 과정을 통해서 관련 지식을 배운 건 아니었다. 그도 거의 모든 걸 독학으로 배웠는데 특이하게도 그 경로에는 네이버 카페가 있었다. 비슷한 또래의 네이버 카페에서 난다 긴다하는 애들과 경쟁하다 보니 더 빨리 배우게 된 게 아닐까라는 추측을 해본다. 네이버 카페는 조금 재미난 특징이 있는데 모르는 애들끼리 모여서 말도 안되는 소리를 하는거 같은데 그 와중에 집단 지성이 동작해서 뭔가 발전이 일어난다는 점이다. 보통의 다른 커뮤니티나 사이트는 가르치는 사람이 있고 배우는 사람이 있는데 네이버 카페는 모르는 애들끼리 모여서 자기가 알아낸걸 각자 자신만의 방법으로 한마디씩 하다가 짠하고 종국에는 답이 나온다. 보고 있으면 황당하기도 하도 신기하기도 하고 그렇다.

그렇게 배운 F는 지금은 국내에서 이름만대면 아는 유명한 IT 회사에 근무한다.

#4

G는 이 이야기에 등장하는 유일한 컴퓨터 공학 전공자다. 그는 대학을 졸업하고 입사했다. 병역특례를 하지 않았다. 너무 평범한 일반적인 케이스가 아닌가? 그렇다. 다만 그가 입사에 있어 특이했던 점은 게임 보안 솔루션을 만들어서 제출을 했다는 것이다. 그는 이력서에 깃헙 링크를 함께 보냈고 거기엔 그가 만든 동작이 가능한 게임 보안 솔루션이 있었다. 뽑지 않을 이유가 없다. 동작하는 게임 보안 솔루션을 직접 생각해서 다 만들었다니…

면접 때 그에게 이걸 어떻게 만들었나 물었던 기억이 있다. 그는 자주 했던 게임에서 비슷한 걸 봤고 재밌어 보여서 직접 만들었다고 했다. 동아리나 그런 곳에서 함께 만든 거냐고 물었더니 혼자 만들었다고 했다. 오프에서 이쪽 분야에 관심이 있는 사람들을 만나기 힘들어 혼자서 공부했다는 얘기를 덧붙였다. 그는 지방에서 나고 그곳에서 대학을 졸업했다. 그가 만든 작품은 오버워치에 적용된 이후로 제법 업계에서 핫한 기법이었고 나는 몇가지 질문을 더했다. 그리고 이어진 그의 답변. 그 속에는 그가 얼마나 많은 시간을 날밤새며 사고실험과 삽질을 했는지가 오롯이 담겨 있었다.

#5

유튜브, 블로그, 책, 국비 지원 교육 과정, 커뮤니티 사이트, 웹사이트, github, 네이버 카페, 대학교, 사고실험, 삽질 등 다양한 경로로 배움의 과정을 거친 이들을 봤다. 경로는 다양했지만 그들은 하나같이 그일을 하기에 차고도 넘칠 정도로 충분한 지식을 기지고 있었다. 물론 그런 실력을 가지기 위해서 그들이 얼마나 많은 시간과 노력을 투입했는지는 알 길이 없다. 하지만 어쨌든 한가지는 분명하다 관심과 취향이 맞고 노력이 더해진다면 어떤 경로를 택하든 당신이 원하면 당신은 직업 프로그래머가 될 수 있을 거라는 점이다.

바야흐로 코딩의 시대, 당신이 배우는 단계에 있다면 응당 의문이 많을 수 밖에 없다. 이 방법이 맞을까? 남들도 이렇게 하는걸까? 이렇게해서 취직할 수 있을까? 어떤 길이든 지속할 수 있다면 틀린 길은 아니라고 감히 말할 수 있을 것 같다. 당신의 배움에 건투를 빈다.

우리 때에는 김국현님의 자바 두명 타세요라는 괴담이 난무했다. 요즘은 업그레이드 된 인공지능 괴담이 난무하는 것 같다. 인공지능이 개발자를 모두 대체한다는 얘기 말이다. 하지만 김국현님의 괴담이 그랬듯 너무 겁낼 필요는 없을 것 같다. 인공지능이 언젠간 개발자를 모두 대체하겠지만 그때는 다른 직업도 상당수는 대체되었을테니 사회적으로 뭔가 다른 솔루션이 나왔을 가능성이 높다. 그리고 그 시간은 생각보다 오래 걸릴 수 있고, 전혀 엉뚱한 방향으로 전개될지도 모른다. 당신의 미래에도 지금 세대 개발자들이 누린 행운이 조금이나마 함께하길 바란다.

[리뷰] 의천도룡기 2019

Fri, 29 Jan 2021 12:00:01 GMT

넷플릭스를 방황하다 우연찮게 틀게 된 "의천도룡기 2019"가 내 인생 첫 중드가 되었다. 이상하게 중드는 그간 잘 보지 않았던 기억이 있다. 물론 어렸을 적 이연걸의 광팬이었고, 홍콩 무협 영화를 좋아했었던 것을 보면 딱히 중드를 안 볼 이유도 없는데 그저 이상하게 중드면 시작조차 하지 않았던 기억이 많았다. 그럼에도 의천도룡기를 정주행 할 수 있었던 가장 큰 힘은 아무래도 여캐들의 훈훈한 비주얼 탓이 아닌가 싶다. 그간 한중일중 미모는 한국이 원탑이라 생각했었는데 의천도룡기를 보고 생각이 다소 바뀌게 되었다. 여튼 각설하고,...

김용의 소설 원작을 읽지 않았지만 의천도룡기 또한 그의 다른 소설과 비슷하게 몹시 재미있다. 시대를 초월해서 바뀌지 않는 인간상, 그리고 고뇌할 수 밖에 없는 인생사를 그리고 있어서 그런 것 같다. 이루어질 수 없는 사랑, 가질 수 없는 것들에 대한 욕망, 그리고 이루고 싶은 것에 대한 집요하고 끊질기며 처절하게 이어지는 집착, 그런 모든 면에서 이 드라마는 많은 것들을 담고 있다고 할 수 있다.

내가 조민이다.

그 모든 스토리 중에서도 단연 돋보였던 캐릭터는 다름아닌 조민이었다. 물론 그녀가 여주이면서 가장 예뻐서 그랬다는 점도 부인은 못하겠지만 그것 외에도 그 캐릭터가 보여주는 태도는 많은 것들을 느끼게 해주었다. 이루어질 수 없는 사랑, 그것을 위해서는 엄청난 희생이 따를 것이라는 것을 알면서도 그녀는 처절하고 끊질기고 집요하게 그 사랑을 얻기 위해 모든 것을 걸었다. 그녀 출신 성분 자체가 그것을 통해 얻을 것 보다는 잃을 것이 더 많다는 점은 그 과정을 더욱 납득하기 힘들게 만들었지만 반대로 또 더 애절해 보이게 만드는 효과가 있었다.

드라마 3대 빌런을 꼽자면 나는 아미파의 멸절사태, 대사저, 지약을 꼽겠다. 작가가 남자라 그런지 악역을 여자 무림파에 몰아 넣은 감이 없잖아 있는 것 같다. 자신의 주장을 죽음을 앞에 두고도 굽히지 않으며 의미 없게 죽어서 여러사람 피곤하게 만드는 고집불통 빌런 멸절사태, 그리고 본인의 알량의 권력을 믿고 위로는 굽신거리며 아래 사람들에게는 끊임없이 막대하는 대사저, 그리고 우유부단 빌런의 끝판대장 지약.

이 드라마는 시작부터 끝까지 인간의 처절한 고뇌를 담고 있다. 이루어지면 안 되는 정파와 사파의 사랑, 자신의 복수를 위해 한 평생을 바치며 온갖 악행을 저지르는 한 남자, 그들 사이에서 출생부터 복잡하게 꼬여버린 주인공, 삶과 죽음의 경계에서의 처절한 사투, 대업과 사랑 사이의 갈등 같은 우리가 살면서 겪을 수 있는 시대를 초월한 온갖 고뇌와 인간 군상들을 닮고 있기에 이 드라마는 재밌었고 유익했다.

[ai] 너와 나의 인공지능이 멍청한 이유

Wed, 15 Jul 2020 12:00:01 GMT

모든 사람이 그렇듯 내가 머신러닝에 관심을 갖게 된 시점은 알파고가 이세돌을 무참히 격파하던 그 즈음이었다. 대국이 시작되기 전 나는 당연히 이세돌의 전승을 점쳤고, 1국이 끝나고 세상이 바뀌었다는 사실을 깨달았다. 그리고는 봇물처럼 머신러닝 자료와 강연들이 이어졌다. 그덕에 구글의 제프딘을 실제로 보기도 하는 호사를 누리기도 했다 (텐서플로 홍보차 국내에 옴)

그때 제프딘이 발표한 내용 중에 이미지 인식(이게 고양이인지, 강아지인지, 나팔꽃인지, 장미인지, 등등을 판단) 분야에서는 기계가 인간을 뛰어 넘은지가 제법 됐다는 이야기를 했다. 그리고 얼마 지나지 않아 각종 렌즈앱들이 나오기 시작했고, 그 렌즈앱이 우리 엄마보다 더 정확하게 각종 식물의 이름을 나열하는 것을 보면서 2차 충격을 받았다. 그렇게 머신러닝의 르네상스는 시작되었고, 요즘 IT쪽 사람들을 만나서 뭐 하는지 물어보면 분야를 안 가리고 머신러닝 한다는 대답이 돌아오는 세상이 되었다.

어쨌든 그맘때 이미지 인식을 그렇게 기계가 잘 한다면 바이너리 인식도 잘하지 않을까라는 생각이 들었다. 컴퓨터한테야 이미지든 바이너리든 결국은 숫자일 뿐이니 말이다. 그런 선상에서 그당시 유행하던 머신 러닝 라이브러리로 해킹툴 바이너리를 분류해서 몇 개 학습시켜 보고 결과를 체크해 보았다. 샘플에서는 너무 완벽하게 동작했지만 각종 정상 바이너리를 집어 넣자 오진이 무지하게 많이 났다.

그당시 MS에서도 바이너리 분류와 관련한 컨테스트를 진행하고 있었다. 심지어 결과물도 공개가 되어 있었다. 테스트 안해볼 이유는 없기에 거기 1등한 사람들의 방법을 가져와서 우리도 테스트를 해보았다. MS 대회의 1위 답게 그냥 우리가 막 이미지 인식 시킨 것 보다는 훌륭했다. 그래서 본격적으로 돌려보자고 했는데, 회사 장비로는 한계가 있고 AWS에서 돌리면 수백만원 정도의 비용이 지출될 것 같다는 얘기를 했다. 될지 안될지도 모르는 일에 그 정도를 투자한다는게 쉽지 않은 일이라 거기까지 하고 말았던 기억이 난다.

그 1등의 방식도 재미있었는데 각종 팩터를 넣어서 학습시키는데 그 중에 하나가 바이너리 앞부분 200바이트 해시를 사용한다거나(200이란 숫자는 정확한 건 아님) 하는 것이 있다. 그래서 왜 300도 아니고, 400도 아니고 200이지라는 의문을 가지고 그들이 쓴 논문을 봤는데, 그 논문 왈, 200바이트가 왜 잘되는지는 우리도 모르겠지만 여러 테스트 결과 그게 좋아서 그렇게 했다는 다소 충격적인 답변. 아, 이런게 머신러닝 이구나 라는 느낌만 가지고 기억속 한편으로 사라졌다.

그렇게 잊고 있었던 머신러닝 관련해서 최근 지인 한 명이 그때 그 생각이 틀린 건 아닌 거 같다면서 MS에서 발표한 링크 를 보내줬다. 소오름. 내 생각이 바로 저거였는데 저게 된다니 ㄷ ㄷ ㄷ 그리고 우리가 머신러닝알못이라 그렇지 구현을 제대로 했으면 그때부터 잘됐을까라는 생각도 들었다.

그렇게 다시금 인공지능에 대한 연구 의지가 불타오름과 동시에 교보문고에서 인공지능 책들을 마구 질렀다. 친구가 심지어 2권은 선물까지 해줬으나 서평은 요원한 단계. 어쨌든 그 책들을 읽고 이미지 분류에 그렇게 좋다는 CNN으로 이미지를 좀 분류해보려고 돌렸으나 결과는 썩 좋지 않았다. 인공지능 쪽에 다소 조예가 있는 주변인들에게 물어보면 대다수가 그게 교과서에 나오는 건 잘 되는데 실질적으로 현실 세계 데이터로 뭐를 해보려면 잘 안 된다는 이야기를 했다. 그 이야기와 함께 다시금 광속으로 연구 의지는 마이너스 무한대로 발산하게 되었다.

#0

그런 기억이 희미해질만했던 6월 말 회사에서 병역특례로 근무하던 DevOps 친구가 그만두는 일이 있었다. 여러모로 똑똑한 친구였는데 헤어지는 자리에서도 다소 충격적인 이야기를 들려주었다. 머신러닝을 하기 위해서 무.려. 4400만원짜리 컴퓨터를 질렀다는 이야기.

그 이야기의 여러 요소에서 다중 충격을 받았는데, 1) 머신러닝을 하기 위해서 개인 돈으로 컴퓨터를 사는 투자를 한다는 데 놀랐고, 2) 그것도 무려 4400만원짜리를 샀다는 데 두 번 놀랐고, 3) 그 엄청난 비용의 상당수가 최근 유행하는 T 코인(테슬라)에서 충당됐다는 사실에 놀랐다. 어쨌든 그 머신은 제온씨퓨에 타이탄을 무려 4개나 달았다고 했다.

머신러닝을 하려면 그 정도 장비가 필요한 거냐고 물어봤더니 자기도 잘은 모르는데 제대로 해보려고 좋은 장비를 샀다는 이야기를 했다. 그와 더불어 요즘 AI 대회가 많아서 그런 곳에서 상금을 받으면 투자금 회수가 가능하다는 이야기도 덧붙였다.

#1

그 친구가 퇴사한 이후에 회사에 인공지능 하는 친구들이 현장실습을 왔다. 그당시 하다가 포기한 이미지 분류 작업을 진행하기 위해서 왔는데 그들은 학교에 있는 1080TI가 몇 개 있는 장비를 사용할 수 있는 상태였다.

출근한 날 같이 저녁을 먹을 시간이 있어서 이런 저런 얘기를 하다가 애니를 좋아한다는 이야기를 듣게 되었고, 추천작을 물어봤더니 고스트 바둑왕을 꼽았다. 나는 만화책으로 봤는데 끝이 너무 허했다는 이야기를 전했다. 작가가 히트 좀 하자 끝낸 용비불패같은 느낌. 그 친구가 애니는 그래도 괜찮다는 이야기를 했고 마침 스트리밍 서비스에 올라와 있길래 사이와 히카루의 대국을 애니로 몇 편 보게 되었다. 모든 만화가 그렇지만 보면 뿜뿜하게 된다. 바둑 기사 존멋~

#2

히카루와 사이의 바둑에 빠져서 애니를 보다보니 자연스레 바둑을 배우고 싶다는 생각이 들었고, 예전에 프로 기사를 준비했던 동생이 알파고 이후에 제로 시리즈 인공지능 바둑이 많이 나왔다는 이야기를 들었던 기억이 많이 났다. 그래서 집에 설치해보고 돌렸는데 자기들끼리 두게 해도 제법 모양이 나오게 두었다. 나는 바둑을 둘 줄 몰라 실력을 알 수 없어서 온라인 바둑에 들어가서 몇 판 둬봤는데 지는 법이 없었다. 그리고 유튜브를 찾아보니 프로 기사들도 3점 놓고 둬야 이기고, 2점은 힘들다는 이야기들이 올라와 있었다.

간략하게 인공지능 바둑에 대해서 이야기하자면 알파고가 시초고, 알파고 제로가 나오고 그들이 연구 방식을 논문으로 공개해서 유사한 종류의 인공지능이 많이 나오게 됐다. 제로의 특징은 인간의 기보를 사용하지 않고 자기 스스로 게임을 반복(self play)하면서 기량을 향상시켜 나가는 기법을 쓴다. 따라서 바둑의 룰만 넣어주고 돌리면 스스로 점점 더 강해진다는 알고나면 다소 단순해 보이는(?!) 컨셉이다.

그 이후에 등장한 것 중에는 릴라제로의 경우 개인이 오픈소스로 만들어 대중의 참여로 분산 학습시켜 나가는 구조로 진행되고 있다, 페이스북에서도 엘프고라는 프로젝트로 야심차게 진행했으나 현재는 퇴물, 그리고 가장 최근에 나온 게 카타고다. 카타고의 특징은 기존 알파고가 바둑이란 게임의 특징을 별로 활용하지 않았다면 카타고는 바둑에 특화된 특징을 많이 사용해서 학습 속도가 빠르고 승률 외의 다른 종류의 예측들을 더 가지고 있다고 한다. 개인 컴퓨터에서 각종 인공지능들끼리의 대국을 펼쳐 보았는데 카타고가 제일 강했다. 심지어 생각하는 시간을 차이를 두어도 카타고가 이기는 경우가 많았다.

대체로 프로 기사들 사이에서는 알파고 제로 > 텐센트 절예 > 카타고 > 릴라 제로 정도로 판단되고 있는 것 같았다. 이런 걸 보면 궁금증이 생기게 마련이다. 비슷한 셀프 플레이란 방식으로 학습을 시켰음에도 그들 사이에서 큰 기량 차이가 생기는 이유는 뭘까? 심지어 페이스북도 나름 똑똑할텐데 왜 엘프고는 순위에도 끼지 못할까라는 생각을 하면서 릴라제로 소개 페이지를 보다가 신기한 사실을 알게 되었다.

Recomputing the AlphaGo Zero weights will take about 1700 years on commodity hardware.

알파고 제로의 가중치 데이터를 재계산하는데에는 상용 하드웨어로 1700년이 걸린다는 이야기. 요는 이렇다. 제로 방식은 셀프 플레이를 토대로 가충치 파일을 만들어 추후 탐색을 할 때 더 적절하고 빠르게 하는 형태로 사용을 한다. 즉, 대다수 제로 방식 봇의 알맹이는 이 가중치 파일이란 것이다. 릴라제로 개발자는 1080ti 그래픽 카드 한 장으로 개발을 하는데 본인이 생각하는 추정치로는 그 그래픽 카드 하나로 알파고만큼의 수준을 계산하기 위해서는 1700년이 걸린다고 말한 것이다. 그걸 극복하기 위해서 릴라제로는 개인의 컴퓨팅 자원을 지원 받아 클라우드 형태로 계산해서 학습하는 구조로 진화를 하고 있다. 그냥 숫자만 보고 역시 구글이라는 생각을 하면서 카타고 자료도 살펴보게 되었다.

KataGo’s latest run used about 28 GPUs, rather than thousands (like AlphaZero and ELF), first reached superhuman levels on that hardware in perhaps just three to six days, and reached strength similar to ELF in about 14 days. With minor adjustments and some more GPUs, starting around 40 days it roughly began to match surpass Leela Zero in some tests with different configurations, time controls, and hardware. The run continued for a total of about five months of training time, reaching several hundred Elo stronger than Leela Zero and likely other open-source bots. The run has ended for now, but we hope to be able to continue it or begin another run in the future!

여기는 조금 구체적인데 28개의 GPU로 학습을 시켰고, 인간을 뛰어넘는데 3-6일이 걸렸고, 14일에 엘프고 수준에 도달했다. 여기에 조금의 조정을 하고 GPU를 몇개 더 추가해서 40일 정도 되니까 릴라 제로의 수준에 도달했고, 총 5개월 정도가 지나서는 릴라제로에 비해서 Elo 점수가 수백점 차이가 났고 학습을 중단시켰다는 이야기. 내용이 재밌어서 그들의 논문도 찾아서 읽어보았다. 도입부가 무척 흥미로웠는데 다음과 같이 정리돼 있었다.

In 2017, DeepMind’s AlphaGoZero demonstrated that it was possible to achieve superhuman performance in Go without reliance on human strategic knowledge or preexisting data [18]. Subsequently, DeepMind’s AlphaZero achieved comparable results in Chess and Shogi. However, the amount of computation required was large, with DeepMind’s main reported run for Go using 5000 TPUs for several days, totaling about 41 TPU-years [17]. Similarly ELF OpenGo, a replication by Facebook, used 2000 V100 GPUs for about 13-14 days, or about 74 GPU-years, to reach top levels of performance [19].

알파고 제로의 경우 5000 TPU로 몇일 계산을 했다고 나와 있다. 총 41년 TPU 시간이 사용되었다. 엘프고의 경우 2000개의 V100 GPU를 사용해서 13-14일 계산을 했고, 총 74년 GPU 시간이 사용되었다.

결국 당연한 소리겠지만 동등한 설정이라면 결국 연산 시간에 따라서 인공지능의 강함이 결정된다고 할 수 있겠다. 그런데 그 연산 시간이라는 것이 생각보다 천문학적이라는데 놀랐다. 릴라제로 개발자는 1080TI GPU 한장으로 개발을 하고 있고, 카타고는 V100 28장에서 몇 장을 더썼고, 엘프고는 V100 2000장, 알파고제로는 TPU 5000개를 사용했다.

FP32벤치 마크 자료를 살펴보면 1TPU를 1.0으로 계산 시에, V100이 0.9정도, 1080TI가 0.4 정도 되는 것으로 추정된다. 이 데이터를 토대로 연산에 사용된 비용을 계산해보면 다소 충격적이다.

카타고의 경우 줄여서 V100 28개 5개월로 계산할 경우 (28 x 5 x 30) / 365 = 11.5년에 해당하는 GPU 시간을 사용했다고 볼 수 있다. aws에서 v100을 8개 탑재한 p3.16xlarge의 경우 시간당 사용 비용이 24.48불이다. 단순 계산할 경우 5개월간 총 308,448불이 사용되었다고 볼 수 있다. 1200원 환율로 계산할 경우 3억 7천만원에 해당하는 금액이다.

엘프고의 경우 동일한 장비로 74년 GPU 시간을 썼다고 나와 있기 때문에 계산해보면 1,983,614불을 썼고, 한화로 23억 8천만원 정도를 썼다고 볼 수 있다.

구글 TPU의 경우 선점형 v2 8코어가 시간당 1.35불이다. 이걸 토대로 41년 TPU시간을 계산해보면 60,608불, 7300만원 가량 사용한걸로 보여진다. 선점형이 아닌 주문형으로 할 경우 시간당 가격이 4.45로 올라가기 때문에 계산해보면 199,782불, 한화로 2억 4000만원 가량이 된다. 1대 0.9로 GPU 환산 계산시 45.51년 GPU 시간이 나오고 aws 비용으로 환산해 보면 1,219,922불, 한화로 14억 6400만원 가량이다.

아마 이건 최적화된 경로로 계산을 하는 걸 밝힌 것이기 때문에 실질적으로 테스트에 사용되거나 폐기되거나 한 걸 감안한다면 훨씬 더 천문학적인 비용이 지출된다는 걸 알 수 있다. 그리고 왜 학습을 멈추는지도 이해할 수 있다.

#3

우리가 바둑 인공지능을 만든다고 한다면 적어도 사람과는 대등하거나 잘 두는 수준이 되어야 쓸 만 하다고 인정을 해 줄 것이다. 이를 카타고 데이터를 토대로 최적화 시켜서 3일 걸린다고 가정을 하더라도 최적화된 계산 비용만 49,351불 한화로 6000만원 가까이를 써야 가능하다. 물론 이 또한 실패는 전혀 없는 모든 게 아마도 완벽한 상태에서의 계산 시간만을 가정했을 때 그렇다는 이야기일 것이다.

재미삼아 또는 가능성만 보고 하기에는 쉽지 않은 분야라는 답이 나온다. 그리고 너와 나의 인공지능이 왜 그렇게 바보같은지도 어느 정도 이해가 된다. 구글이 왜 TPU를 만들었는지도 답이 나온다. 카타고가 더 강하게 만들지 않는 이유도 알 수 있고, 언제 새로 돌리기 시작할지도 예측해 볼 수 있다. 알파고 제로 가중치 파일을 공개하지 않는 이유도 추측해 볼 수 있고, 절예의 최신 가중치 파일을 왜 중국 프로 기사에게만 제공하는지도 납득이 된다. 심지어는 똑똑한 사람들이 돈을 많이 넣어도 결과가 좋지 않을 수 있다는 사실도 참고할 수 있다. 끝으로 몇년전 우리가 몇 백만원에 망설였던 게 얼마나 조족지혈인지도 알게 되었다.

[정보] 웰비아닷컴은 채용 중~

Tue, 12 May 2020 12:00:01 GMT

이 채용 공고에 관심이 있고 해당 자격 요건을 갖추었다고 판단되시는 분은 codewiz 앳 wellbia 닷 com으로 이력서와 자기소개서를 메일 주시면 됩니다.

자격 요건

C/C++ 시스템 프로그래머
윈도우, 리눅스 둘 중 하나는 잘 알아야 합니다. CreateThread와 fork 둘 중 하나는 제대로 호출할 줄 아는 분이면 좋겠습니다.
리버스 엔지니어
윈도우 시스템에 대한 이해가 있는 분석가를 모집 중입니다. 가상 메모리 구조, 실행 파일 구조, x86/64 어셈블리어에 대한 이해가 있는 분을 채용 중입니다.

장점

(주)웰비아닷컴은 세계적으로 얼마 안되는 상용 게임 보안 제품을 만드는 회사입니다. a) 대체로 이쪽의 커리어를 쌓기 위해서는 한국, 독일, 핀란드 중에 한곳에 연고가 있는 것이 유리합니다. 한국에 계시다구요? 네 그러시면 저희와 함께 일하는 것이 좋을 것 같습니다. b) 저희는 전세계적으로 가장 인기있는 게임을 제작하는 게임 벤더들과 작업하고 있습니다. 그렇기에 최신의 최고급 해킹 테크닉과 방어 메커니즘을 가장 빠르게 배울 수 있습니다. 또한 그만큼 성장할 기회도 많다는 걸 의미하기도 합니다. c) 저희는 열린 회사입니다. 여러분이 접근할 수 없는 소스 코드는 없습니다. 모든 걸 볼 수 있고, 모든 걸 바꿀 수 있습니다. d) 야근이 없습니다. 99.478% 이상의 확률로 칼퇴근을 보장합니다. e) 직원을 어린이 취급하지 않습니다. 모두 똑같은 성인으로 존중합니다. 언제 쉴지 언제 일할지는 충분히 본인이 결정할 수 있다고 판단하고 그 의사를 존중합니다. 다른 것들도 마찬가지입니다.

단점

30명 미만의 작은 기업입니다. 연봉이 높지 않습니다. 박봉이라고 생각하지는 않지만 배달의민족 채용 공고처럼 그걸 강점으로 내세울 수 있는 수준은 아닙니다. 폭발적으로 성장하는 기업은 아닙니다. 물론 그렇다고 정체된 회사는 아니지만 쿠팡 채용 공고처럼 압도적으로 높은 성장률을 강점으로 내세울 수준은 아닙니다.

사족

덧1) 긍정적인 분만(!!) 채용합니다. 부정적인 성격이시면 저희와는 잘 맞지 않을 수 있습니다. 기본적으로 세상이 더 나은 방향으로 발전하고 있다고 확고하게 믿는 분들과 함께 일하는 것을 선호합니다.

덧2) 관련 경력이 15년 이상인 올드스쿨 멤버들도 채용하고 있습니다. 이쪽 분야의 아주 오래된 고유 경력을 가지고 계시고 본의 아니게 경력을 이어나가기가 힘들어진 엔지니어 분이라면 언제든지 연락 주시면 좋겠습니다. 저희는 해당 경력을 완전하게 존중합니다. RESPECT!

[일상] 2019-06-26

Wed, 26 Jun 2019 12:00:01 GMT

지난 4년을 회고한다.

어쩌다 여기까지 오게 되었나?
무엇이 문제였나?
앞으로 어떻게 살아야 하는가?

내가 나를 몰랐다.

미래

[소고] 책임진다는 말...

Thu, 08 Nov 2018 12:00:01 GMT

오래전 일이다. 먹고 살기 힘들어 인건비 따먹기 SI 사업을 하던 때였다. 당연한 얘기지만 SI 사업에는 적은 리소스를 투입하고 최고의 효과를 얻어야 하던 시절이기도 했다. 그래야 시간이 생기고 그래야 우리 솔루션도 돌 볼 수 있기 때문이다. 그 당시 과제의 한 모듈을 담당했던 개발자가 자꾸 직접 구현해서 될 일이 아닌 것을 직접 구현하려고 했다. 문자열 인코딩을 처리해야 하는 모듈이었다. 문자열 인코딩만 본다면 개발자가 직접 구현해도 될 것 같지만 온갖 코드페이지를 다 처리해야 했기에 또 그렇게 간단하진 않은 모듈이었다. 그래서 왠만하면 오픈소스를 쓰라고 검토해서 알려주었다. 다소 C++ 중2병 환자가 만든 소스 코드 같아 보였지만 코드 내부를 봤을 때 온갖 코드페이지를 잘 처리할 수 있을 만큼 충분히 복잡하게 만들어져 있었다. 안타깝게도 문제의 개발자는 온몸으로 거부했다. 스스로 직접 구현할 수 있고, 그 소스는 너무 복잡하다고 했다. 그러고 덧붙였다. 잘못되면 책임지겠다.

뭐 뻔한 결말이지만 그 친구가 만든 코드가 잘 되지도 책임을 지지도 못했다. 직접 만든 코드는 우리가 실시한 간단한 테스트는 통과 했지만 의뢰한 업체의 온갖 테스트에는 속속 문제가 발생했다. 러시아어에서 비롯된 문제는 온갖 if문을 달아가며 언어 하나가 나올 때마다 땜빵을 해봤지만 잘 되지 않았다. 결국 처음부터 그 오픈소스 코드를 가져다 쓰는 코드로 바꾸고서야 문제가 해결됐다. 하지 않아도 될 고생을 한 것도 화가 났지만, 우리에게 천금같았던 시간을 낭비했다는 데 더 많은 울화가 치밀었다.

책임진다는 말을 우리는 너무 쉽게 하는 경향이 있다. 아마도 그 직원은 두 가지 의미에서 책임진다는 말을 했을 가능성이 높다. 1) 책임지고 그만두겠다. 2) 잘못되면 내가 그 돈을 메꾸겠다. 대체로 1번의 의도로 말하는 경향이 많지만 그건 그 어떤 것에 대한 책임도 되지 않는다. 회사 입장에서 책임이란 말은 그저 문제가 없는 상태로 일이 잘 처리되는 것 외에는 어떠한 방법도 없기 때문이다. 그런 맥락에서 2번도 해법은 아니다. 금전적 손실은 메꿀 수 있겠지만 일을 맡긴 업체와의 관계는 보상이 불가능하니 말이다. 사실 돈을 메꾼다는 것도 불가능한 상황이긴 했다. 그 친구가 숨도 안 쉬고 5년을 일해도 메꿀 수 없는 규모였다.

시간이 많이 흘렀다. 이 어리고 서툴렀던 시절의 추억담이 종종 떠오른다. 그 친구 입장에 내가 서 있다는 생각이 들어서다. "방향이 틀리면 속력은 아무런 의미가 없다"라는 간디의 말도 다시금 생각나는 요즘이다. 아주 사소한 나의 잘못된 생각 하나에 시간과 속력이 더해져 우리는 완전 엉뚱한 장소에 도착해 버렸다. 이제는 내가 잘못 생각한 일들을 책임지고 바로 잡아야 하는 시간인 것 같다는 느낌. 사실 앞서도 말했지만 책임진다는 건 그 어떤 형태로도 불가능하다. 그 말을 꺼낸 순간 우리는 책임질 수 없는 상황에 도달한 경우가 더 많이 때문이다. 그럼에도 최선을 다해야 한다. 그게 그나마 나의 잘못을 조기에 알려준 현명한 사람들에 대한 예의일테니까… 머리가 나쁘면 손발이 고생이고, 똥인지 된장인지 먹어봐야 안다.

[소고] 재현 가능한 빌드, 재현 가능한 시드

Mon, 23 Jul 2018 12:00:01 GMT

#0

최근에 덤프 파일 심볼이 맞지 않는 문제가 있었다. wow64 프로세스 덤프를 뜬 건데 .reload를 해봐도 심지어 다운로드 받은 심볼을 지우고 다시 받아도, windbg를 업그레이드 해봐도 소용 없었다. 항간에 windows 10 rs4에서 심볼이 잘 안 맞춰진다는 이야기도 있어서 그런건가 싶어서 포풍 검색을 해봤지만 뾰족한 수가 없었다. 증상은 심플했는데 wow64 프로세스임에도 ntdll이 하나만 있었고, 로드된 dll 목록의 타임스탬프가 invalid라고 나왔다. 그리고 ntdll의 함수를 디스어셈블 하면 이상한 코드들이 나왔다. 여튼 그런 증상… 그렇게 퇴근 시간은 다가오고 오늘의 일을 내일로 미루고 퇴근을 했다…

#1

다음날. 덤프를 다시 열어서 방망이 깎는 노인이 그랬듯 출력되는 메시지를 한줄 한줄 꼼꼼히 쳐다 보았다. 그랬더니 이상한 점이 보였다. 덤프를 열면 통상적으로 운영체제 버전이 표기되는데 64비트 운영체제가 아니라 32비트 운영체제로 나오는 것이었다. 순간, 많은 정황을 고려해 보았을 때 덤프를 64비트 PC에서 32비트 덤프 생성 도구로 덤프를 뜬 것이 아닐까라는 생각이 들었다. 덤프를 생성한 직원에게 물어보자 그렇게 생성했다고 하길래 64비트로 다시 생성해 달라고 했다. 새롭게 만들어진 덤프은 기다렸다는 듯이 잘 동작했다.

#2

뭐 이 즈음에는 대체로 내가 원한 모든 문제는 다 해결이 되었지만 그럼에도 불구하고 찜찜한 점이 하나 있었는데, 그건 여전히 dll들의 타임스탬프가 invalid라고 나오는 문제였다. 다른 모든 것은 기대한대로 동작했지만 타임스탬프 값은 여전히 오리무중… 다시 포풍 검색을 했다. 나에게 항상 해답을 주시는 레이몬드 첸 횽님께서 벌써 올해 1월에 관련 질문에 대한 답을 올려 놓으셨다. 이렇게 바지런 하시니 몸둘 바를…

해당 글을 통해 알게 된 썰은 이렇다. 윈도우 10부터 재현 가능한 빌드(reproducible builds)로 방향을 정했고, 그 정책의 일환으로 타임스탬프를 타임스탬프가 아닌 해시 값으로 변경했다는 것이다. 재현 가능한 빌드라는 건 한 마디로 정리하면 동일 소스 코드로 컴파일을 하면 동일 바이너리가 생성된다는 것을 보장한다는 개념이다. 즉, 니가 소스 코드를 한 줄도 안 고쳤다면 넌 어디에서건 다시 컴파일해도 동일한 바이너리를 가지게 된다는 의미다. 이렇게 하는 이유는 당연히 버그에 보다 빠르게 대응하기 위함이겠거니… 내지는 높으신 분의 개취…

#3

여기까지 오자 몇 해 전 우리에게 혁신적인 개념을 소개했던 직원의 아이디어에 대한 이름을 이제야 붙이 수 있게 되었다. 그 이름은 다름아닌 재현 가능한 시드(reproducible seed) 정도가 되겠다. 적어도 4-5년은 거슬러 올라가야 하는 이야기다. 우리는 당시 아주 난해한 버그를 마주하고 있었다. 100번 정도에 한 번씩 게임이 시작 시점에 크래시가 나는 문제였다. 지금에 비하면 아주 단촐했던 테스트 인력을 가지고 있던 당시로써는 문제를 발견해 낸 것만 해도 대단한 것이었다. 하지만 그 문제를 해결하는 것은 발견하는 것 이상의 노력이 필요했다. 재현을 하려면 100번을 실행해야 했기 때문이다. 어쨌든 그 당시 테스트 인력의 도움으로 어렵사리 덤프를 확보했다. 하지만 아무도 문제를 찾지 못했다. 딱 미제(미해결 과제)가 되기 좋은 사안이었는데 어디선가 혜성같이 등장한 구원 투수가 마법같이 문제의 원인을 알아냈다. 랜덤이 문제였다. 랜덤 결과가 특정 값이 될 경우 메모리가 오버래핑되는 문제가 있었던 것이다. 그 확률이 1/100정도 됐던 모양이다.

그때 그 덤프에서 문제를 찾은 직원은 우리가 업무 특성상 랜덤을 많이 사용한다면 재현 가능한 시드 시스템을 도입해야 한다는 것을 주창했다. 그 메커니즘은 재현 가능한 빌드와 동일한데 시작 시에 랜덤 시드를 지정하면 프로그램 전체가 그 시드에 동기화되어서 동작하는 것을 보장하는 것을 의미한다. 이렇게 말하면 어려운데 그냥 쉽게 코드로 말하면 전역 의사 난수 시스템을 사용하고 시작 시에 시드를 고정할 수 있는 방법을 제공해야 하는 것을 말한다.

이렇게 할 경우 어쩌다 한 번 크래시 났을 때, 시드를 알고 있다면 그 다음에는 굳이 100번 실행할 필요가 없다. 해당 시드를 넣고 실행하면 동일한 실행 결과를 보장하기 때문이다. 랜덤이 문제라면 똑같이 문제가 발생할 것이다. 즉, 버그를 찾기가 엄청 쉬워지는 장점이 있다. 여기에 플러스 퍼징 테스트를 하기가 아주 쉬워진다. 그 시드 값만 순차적으로 증가시켜 가면서 쭉 실행을 시키면 문제가 있는지 없는지 손쉽게 찾을 수 있으니 말이다.

찾아낸 것도 대단하지만 그런 문제를 두 번 다시 겪지 않기 위해서 재현 가능한 시드라는 것을 주창했다는 것 또한 더 대단한 일이 아닐 수 없다 하겠다. 하지만 현실은 언제나 바쁘기에 그의 의견은 아직도 구현되진 못했다. 조선 최고의 천재라 일컬어지는 율곡 이이 선생의 십만양병설이 떠오르는 시점이 아닐 수 없다.

윈도우 10도 재현 가능한 빌드를 사용하는 마당에 오래 전 그 직원이 주창했던 아이디어를 반성하는 의미에서 구현해야 겠다는 생각이 든다. 구슬이 서 말이라도 꿰어야 보배고, 아이디어가 아무리 많아도 구현이 없으면 공허한 메아리일 뿐이니 말이다.

#4

다시 다음날. 반성하는 의미에서 우리가 사용하는 랜덤의 호출 경로를 추적하는 작업을 해 보았다. 그러다보니 이 문제가 생각보다 쉽지 않다는 것을 알게 되었고, 똑같은 짓을 몇 년 전에도 했다는 사실을 알게 되었다. 메멘토 같은 상황…

전말은 이렇다. 일반적으로 사용하는 rand 함수는 시드를 가지고 있고 멀티스레드 환경에 최적화하기 위해서 해당 시드를 스레드 로컬 스토리지에 저장한다. 이 말은 이걸 전역으로 한 번 초기화 한다고 해서 해당 값에 바인딩된 rand를 호출하는 모든 상황에 적용되는 것은 아니라는 것을 의미한다. 즉, 제대로 돌아가게 만들기 위해서는 모든 스레드의 시작 시점에 해당 시드로 초기화를 하는 루틴을 삽입해야 한다는 것을 의미한다. 응당 그게 쉽지 않으니 달리 생각할 수 있는 방법은 의사 랜덤 생성 함수를 새롭게 만드는 방법을 생각해 볼 수 있다. 이렇게 구현할 경우 스레드 안정성을 보장하기 위해서는 락을 쓰거나 락리스한 방법으로 좁혀진다. 그런데 랜덤 값 하나 만들겠다고 락을 쓰는 것은 뭐 빈대잡겠다고 초가삼간 태우는 격이니 결국은 락리스한 랜덤으로 방법은 더 좁혀진다. 그럼 그런 것을 내가 직접 만들 수는 없으니 구글에 검색을 하게 된다. 그렇게 나온 결과물을 쳐다 보고 있으면 그런 결론에 도달한다. 아~ 다른 일부터 해야겠구나…

[일상] 송도 지열군 스튜디오 돌상 사진 촬영기

Mon, 14 May 2018 12:00:01 GMT

송도(인천)는 살기에 정말 거의 단점이 없는 동네인데 그 중에도 특히 최고의 강점 중에 하나가 거의 모든 인프라가 굉장히 잘 갖춰져 있다는 점이다. 홈플러스, 오네스타, 현대 프리미엄 아울렛, 트리플 스트리트로 이어지는 몰들의 향연에 한 번 빠지면 도대체 여긴 어딘가 싶다. 특히나 평일에는 사람도 많이 없어서 정말 좋다. 돈많은 아줌마가 살기에는 정말이지 최고의 동네라 할 수 있다.

스튜디오도 그렇다. 네이버 검색 결과 송도 내에 스튜디오가 몇 개 있는 것으로 보였다. 그 중에서 다른 블로그를 보다 보니 지열군 스튜디오 사진이 괜찮고, 집과도 가까워서 장모님 칠순 가족 사진을 지열군에서 찍기로 했다. 가족 사진 찍으니 서비스 컷을 두 컷 주신다고 하셔서 한 컷을 애들 돌상 촬영을 해봤다. 첫째 애도 돌잔치는 집에서 하고 사진은 분당에 있는 스튜디오에서 전통 돌상 사진으로 찍었었다. 왠지 돌은 전통이 더 어울리는 듯한 느낌이다.

첫째 아이 사진을 강남, 이태원, 마포, 분당 등지에서 찍어 봤는데 대부분의 스튜디오가 굉장히 열악하기 그지 없었다. 네비를 찍고 가도 찾기 어려운 건 기본이고, 주차 공간은 거의 제로에 가까워서 근처에 불법 주차를 해야 하는 경우가 대부분이었다. 그렇지 않은 경우는 발렛을 제공해 주기는 했는데 이 경우에는 발렛비를 별도로 내야 했다. 건물도 일반 가정집을 개조한 경우가 많아서 사진 촬영을 하다 보면 아래 위층을 왔다 갔다 해야 하는 경우가 많아서 아직 잘 걷지 못하는 애들을 데리고 사진을 찍기란 여간 어려운 일이 아니었다. 찍다가 부모도, 아이도 파김치가 되는 건 일상적인 풍경…

하.지.만. 지열군 스튜디오는 이런 모든 불편함이 없었다. 일단 아파트형 공장 같은 건물의 한 호실에 모든 스튜디오가 갖춰져 있어서 계단 사용할 일이 없다. 애들 안고 이동을 하지 않아도 된다는 의미다. 인테리어도 요즘 새로 한 것 같아서 상당히 깔끔하다. 특히 창가쪽 벽면 전체에 인테리어 형태의 쇼파가 쫙 붙어있는데 정말 좋았다. 앉아서 쉬기도 좋고, 애들 뭔가 뒷정리 해줄때도 상당히 유용했다. 아파트형 공장 같은 건물이기 때문에 주차 문제는 애시당초 없다. 게다가 무려 300만원에 달하는 디트로네를 타 볼 수 있다. 물론 사장님께서 허락해 주셔야 하는데 애들이 칭얼 거리면 사장님께서 흔쾌이 탈 수 있도록 배려해 주셨다. 우리도 두바퀴를 탔는데 첫째가 참 좋아했다. 집에 있는 30만원짜리 싸구려 아우디 전동차와는 뭔가 격이 다른 느낌 ㅋㅋㅋ~ 이런 모든 장점을 가진 스튜디오가 무려 우리 집에서 5분 거리. 이러니 송도를 사랑하지 않을 수 없다.

아직 정신 못차리는 애들이 둘이나 있기에 사진 촬영은 정말 쉽지 않았음에도 인내심을 가지고 촬영을 잘 해 주셨다. 특히 돌상 찍을 때는 애들 컨디션이 나락 상태였음에도 최선을 다해서 찍어 주셔서 고마울 따름이었다. 전통 돌상 촬영은 사실 별반 특별할 것이 없다. 돌상 아이템이 얼마나 잘 갖춰져 있느냐와 때깔 좋은 한복이 얼마나 갖춰져 있느냐의 승부인데, 사장님 말씀으로는 새로 시작하는 세트라 특별히 신경써서 고급 한복을 많이 가져다 놓을 예정이라고 했다. 그리고 요즘 시작하는 세트니 당연히 색감이나 이런 것들이 오래된 스튜디오에 있는 한복보다 곱다. 실제로 서비스 컷으로 찍은 한복 때깔이 첫애 때 분당서 돈 주고 촬영한 한복보다 훨씬 더 고급져 보였다.

전통 돌상 촬영의 다른 한 부분은 세트 장이 얼마나 다양하게 꾸며져 있느냐가 있는데 지열군 스튜디오는 아직까지는 일반 돌상이 전부다. 전통 가옥으로 된 스튜디오 장은 없다. 하지만 아.마.도. 돌상 촬영을 하게 되는 경우에는 일반 스튜디오에서 다른 사진을 함께 찍을 수 있을 것으로 추정된다. 그리고 중요한 가격 정보는 와이프가 모두 얘기해서 알 길이 없다. 아마 친절하신 사장님 마인드를 봐서는 가격도 많이 착할 것으로 예상된다. 어쨌든 송도나 송도 근처 인천에 계신 분들이라면 애들 사진 찍기에 강추할만한 스튜디오다. 서울에서 오기에도 괜찮다. 위에서 언급한 홈플러스, 오네스타, 현대 프리미엄 아울렛, 트리플 스트리트 바로 옆이기 때문에 사진 찍고 몰에 가서 쇼핑도 하고, 맛난 것도 먹고, 애들 데리고 놀기도 좋다. 애들 사진은 가급적 인터넷에 안 올리는 것이 좋다고 생각하지만 사진이 넘나 잘나와서 몇 장 올려본다. 어서어서 무럭 무럭 자라라. 얘들아…

Figure 1. 둘째, 사장님 포스, 잘 찍고 있지? ㅋ

Figure 2. 첫째랑, 둘째랑 함께, 어서어서 무럭 무럭 자라길…

Figure 3. 첫째 짬컷, 이러니 딸바보 안 될래야 안 될 방법이 없다…

아, 지열군 스튜디오를 처음 방문한다면 주차장 찾는데 조금 난항을 겪을 수 있다. 네비가 알려주는 곳에 주차장 입구가 없기 때문이다. 정확한 주차장은 아래 위치에 있다. 워낙 건물이 길어서 모르면 다소 헤맬 수 있다. 아래 그림의 빨간 부분이 주차장 입구다.

Figure 4. 빨간데가 주차장 입구다.

[소고] 완벽한 회사...

Mon, 19 Feb 2018 12:00:01 GMT

설 연휴에 SBS 스페셜 다큐를 한 편 봤다. "검색 말고 사색, 고독연습"이라는 제목의 다큐였다. 제목 그대로 현대인들은 너무나 고독한 시간이 없고, 스스로 생각을 안 하고 산다는 그런 내용이다. 그리고 고독한 시간 속에서 진정한 내면의 문제를 해결할 수 있다는 아주 교훈적인 내용의 다큐. 뻔한 이야기긴 한데 내가 감탄한 부분은 다른데 있었다. 그건 다름 아닌 해당 내용과 같이 소개된 회사였다. 아래 멘트로 소개되는 회사. 특히 소프트웨어 회사라 어떤 회사인지 더 궁금하기도 했다.

건설 설계 소프트웨어 분야 세계 1위, 무스펙, 무징벌, 무상대평가, 무정년, 이른바 4무 경영, 5성급 호텔 쉐프가 매일 아침, 점심, 저녁 제공, 1인당 연간 식비만 1천만원 이상 지출, 회사에서 운영하는 20일의 자아성찰 프로그램 (제주도에서 20일간 묵으며 자아 성찰을 하는 프로그램, 유급)

몇몇 인상 깊었던 대표의 멘트, "제 인생으로 온 사람들이잖아요. 모두 행복했으면 좋겠습니다.", "개나리는 개나리대로, 진달래는 진달래대로 각자 자신의 꽃을 아름답게 피울 수 있도록 만들어 주는 회사가 됐으면 좋겠습니다." (대충 기억나는 대로 적은 거라 다를 수도 있음)

당연한 얘기지만 다큐에서는 회사명이 직접 거론되지는 않았다. 오늘 궁금해서 검색해보니 금방 나온다. 판교에 있는 마이다스아이티라는 회사. 궁금해서 한 번 찾아봤다. 세상에 완벽한 회사는 존재하지 않는다. 양쪽의 입장 사이에는 너무나 극명한 차이가 있기 때문인 것 같다. 서로 약간씩 물러나 상대의 입장을 이해하기란 여간 쉬운 일이 아닌 것 같다.

몇 해 전 구글 코리아에서 제법 오래 근무하다 그만 둔 형이 한 이야기가 떠올랐다. 입사할 때 그 회사는 정말 좋은 회사였는데, 그만둘 때에는 그런 장점들이 많이 퇴색해진 것 같다고. 그리고 이어서 떠오르는 최근에 이슈가 된 페이스북에서 CEO 개인에 관한 여론을 조사하는 직원을 고용했다던 기사가 생각나기도 했다. 아이언맨으로 칭송되는 엘론 머스크의 테슬라와 스페이스엑스도 말도 안 되게 높은 업무 강도로 유명하다는 이야기도 자주 들린다. 아마존 대표 베조스의 막말은 언급하면 입 아픈 정도.

회사는 회사고, 나는 나다. 직원들에게는 그저 다니는 회사가 블랙 회사가 아니면 만족하고 다닐 법 하다는 이야기를, 대표님들에게는 그저 일 적게 시키고 돈 많이 주면 그게 좋은 회사라는 이야기를 해주고 싶다.

엄마가 늘 하시던 말씀이 생각나는 시점. 물 좋고, 정자 좋은 곳은 세상에 없단다…

[소고] 트레이드 오프

Fri, 26 Jan 2018 12:00:01 GMT

전산학에서 배운 개념 중에서 일상에 가장 쓸모 있는 개념이 있다면 바로 트레이드 오프다. 트레이드 오프는 간단히 말하면 두가지를 동시에 추구하기란 쉽지 않다는 개념이다. 속도를 빠르게 하려면 공간을 더 써야 하고, 공간을 줄이려면 속도를 희생해야 한다는 것과 같이 두 가지 목표를 동시에 추구하기가 쉽지 않은 문제에 쓰인다. 즉, 하나를 선택하면 다른 하나는 일정 부분 포기해야 함을 의미한다. 물론 고상한 전산학까지 가지 않아도 초중등 교과서에도 이 내용이 나온다. 두마리 토끼를 잡지 못한다는 이야기다. 트레이드 오프는 그것보다는 조금 더 확장된 개념이긴 하다. 두마리 토끼를 잡을 수 없다고 한다면 한 마리만 잡을 수 있다는 이야기처럼 들리지만 트레이드 오프는 반반을 추구할 수도 있기 때문이다. 더 내려가서 초등학교 때에도 이 개념을 배우긴 한다. 사탕 항아리에 아이가 사탕을 꺼내려고 손을 넣고 있다. 사탕을 집고 있어서 손이 나오지 않는다. 아이가 사탕을 적당히 포기해야 손을 뺄 수 있다는 이야기가 그것이다. 그렇게 인생 전반에 걸쳐서 우리는 트레이드 오프란 개념을 배운다. 그만큼 중요한 개념이기 때문일 수도 있고, 그만큼 사람들이 쉽게 잊어버리는 내용이기 때문일지도 모르겠다.

인생은 B(Birth)와 D(Death)사이의 C(Choice)라고 얘기한 철학자의 말처럼 인생은 선택의 연속이고, 그 선택이란 것이 결국은 트레이드 오프를 조율하는 과정이다. 연봉을 많이 주는 회사에 입사하면 돈은 더 벌 수 있겠지만 개인 시간은 더 많이 희생할 수 밖에 없다. 작은 회사에 다니면 보다 많은 사사로운 자유로움은 누릴 수 있겠지만 어디 가서 이야기할 때 그 회사를 아는 사람이 없을 수 있다. 아이를 놓으면 아이가 커 가는 것을 지켜 보는 기쁨은 누릴 수 있겠지만 자신의 인생 중 중요한 시간 대부분을 아이를 위해서 희생해야 한다. 유명해지면 많은 사람들이 알아보기 때문에 좋겠지만 그 사람의 사생활은 없어진다. 인생 전반에서 우리를 향해 달려오는 많은 일들이 사실은 트레이드 오프적인 성격의 것들이고 우리는 그 사이에서 어떤 것을 얼만큼 추구할지 결정해야 한다.

사람들이 가장 많이 잊어버리는 내용 중 하나는 바로 항아리에서 손을 못 빼고 있는 아이처럼 그런 종류의 많은 문제들이 트레이드 오프적인 성격의 것이라는 것을 인지하지 못한다는 사실이다. 아이를 놓고 기르면서도 그 전과 같은 평범한 일상을 누릴 수 있다고 생각한다거나, 연봉을 많이 주는 회사에 들어가도 일은 조금 해도 된다고 생각한다거나, 유명한 연예인이 되어도 그 전과 같은 사소한 일상을 누릴 수 있을 것이라고 생각한다. 현실은 그렇지 않은데 말이다.

예전에 친구의 죽음으로 충격을 받은 모 프로그래머가 만든 게임이 생각난다. 그 게임은 간단하다. 시작은 직사각형 모양의 왼쪽 상단에서 한다. 한번에 우리는 네 방향 중 한 칸만큼 움직일 수 있다. 우리가 게임 내에서 움직일 수 있는 최대 횟수는 정해져 있다. 그 프로그래머가 말하고 싶었던 것이 바로 트레이드 오프다. 우리가 오른쪽으로 많이 움직인다면 상대적으로 위나 아래, 왼쪽으로는 적게 움직일 수 밖에 없다. 우리는 그 제한된 횟수 내에서 우리가 선택한만큼 경험하게 되고 죽음을 맞이하게 된다는 것이다.

세상 모든 것을 다 가질 순 없다. 하나를 더 많이 가지기 위해서는 다른 하나는 그만큼 포기해야 한다. 보통 사람들이 무엇을 더 가질지는 잘 선택하지만 무엇을 포기할지는 망설이는 경우가 많다. 하지만 중요한 것은 무엇을 더 가질지 보다는 무엇을 포기해도 되는지를 먼저 정하는 것이다. 그래야 비로소 어떤 방향으로 가야 하는지가 명확해지기 때문이다. 당신은 오늘 무엇을 트레이드 오프 하고 있는가? 또 무엇을 얻고, 무엇을 포기했는가?

[정보] 서피스 프로 LTE

Wed, 08 Nov 2017 12:00:01 GMT

그러하다. 하드웨어 명가 MS가 드디어 완벽한 껍데기를 만들었다.

팬리스, i5, LTE가 달린 서피스. 내가 원하는 바로 그것. 지름신 강림… ㅋㅋㅋ

지금 사용하는게 서피스 프로4 M3 버전인데, 지금껏 써 온 그 어떤 노트북보다 만족한다….

쓰면서 딱 불편한게 M3의 약한 파워, 태더링의 불편함… 그런데 이 모든 문제점을 해결한 버전이 나온 것이다…

12월 출시라는데 한국도 제발 출시해주길…

이런 거 들고 발리가서 서핑하면서 코딩하면 한 2천배쯤 생산성이 향상될 거 같은 느낌적인 느낌…

[cpp] 윈도우 x64 호출 규약 리뷰

Tue, 07 Nov 2017 12:00:01 GMT

윈도우 x64 호출 규약은 굉장히 심플하다. 파라미터가 첫번째부터 rcx, rdx, r8d, r9d를 통해서 전달되고 그 다음 추가 파라미터는 스택을 통해 전달된다. 스택 정리는 호출한 쪽에서 수행한다. 그런데 여기서 한 가지 주의해야 할 것이 홈 공간이다. 홈 공간이란 파라미터가 레지스터를 통해서 전송되더라도 그걸 저장하기 위한 스택 공간을 호출하는 쪽에서 제공해야 한다는 것을 의미한다.

void Func1(int param1);

위 코드를 보자. 위의 파라미터 전송 설명대로라면 Func1(3)은 아래와 같이 호출하면 될 거 같다.

mov rcx, 3
call Func1

하지만 그렇지 않다. 홈 공간이 필요하기 때문이다. 그래서 아래와 같이 값을 저장하지는 않더라도 공간은 확보해 주어야 한다. sub rsp, 8을 통해서 Func1이 param1 저장을 위해서 사용할 공간을 확보한 후에 호출해야 한다. 이게 홈 공간이다.

sub rsp, 8
mov rcx, 3
call Func1
add rsp, 8

조금 복잡하게 파라미터가 5개인 함수를 살펴보자.

void Func2(int p1, int p2, int p3, int p4, int p5); Func2(1, 2, 3, 4, 5)를 호출한다고 생각해보자. 그러면 아래와 같이 호출하면 된다. push 5를 통해서 스택에 마지막 값을 기록한다. 이후 앞에 4개의 값을 기록할 공간을 확보한 후, rcx, rdx, r8d, r9d에 변수를 지정하고 Func2를 호출하면 된다.

push 5
sub rsp, 32
mov rcx, 1
mov rdx, 2
mov r8d, 3
mov r9d, 4
call Func2
add rsp, 40

실제로 컴파일러는 매 함수 호출마다 이렇게 스택을 조작하지는 않는다. 여유 있는 스택 공간을 함수 도입부에 확보해놓고 지속적으로 사용한다. 어쨌든 우리가 기억해야 할 사항은 이것이다. 앞에 4개는 레지스터로 뒤에꺼는 스택으로, 그리고 파라미터 개수만큼 스택 공간은 항상 확보해 주어야 한다는 점이다. 호출 규약에 관한 더 자세한 내용은 호출의 예술을 참고하자.

[py] 주차를 알고 싶을 땐 isocalendar

Sun, 05 Nov 2017 12:00:01 GMT

일주일씩 묶어서 통계를 내고 싶을 때가 있다. 그런데 이게 날짜를 기준으로 하기도 애매하고 위크데이를 기준으로 해도 영 뭔가 계산하기가 쉽지 않다. 이럴 때 isocalendar를 사용하면 편리하다. 해당 날짜가 1년의 몇 번째 주차인지 반환해 준다. 사용법은 아래와 같이 심플하다.

Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:18:55) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> n = datetime.datetime.now()
>>> n.isocalendar()
(2017, 45, 1)
>>> n = datetime.datetime(2017, 11, 5)
>>> n.isocalendar()
(2017, 44, 7)
>>>

isocalendar의 반환 값은 튜플인데 차례대로 ISO 연도, ISO 주차, ISO 요일 번호다. 오늘이 벌써 올해 45주차라뉘… 일년이 52주라 그랬던거 같은데 이렇게 또 일년이 흘러가려고 하나보다. 여튼 이렇게 일주일 단위로 묶은 통계를 낼 때에는 isocalendar가 참 편리하다.

[cpp] 정규 표현식

Wed, 01 Nov 2017 12:00:01 GMT

C++11부터 정규 표현식이 표준 라이브러리에 포함됐다. 문자열 다루기 힘든 C++에서 이런게 되다니 정말 기가 찰 노릇이다. 구슬이 서말이라도 꿰어야 보배이듯이 표준 라이브러리에 있어도 사용법을 모른다면 의미가 없다. 간략하게 사례별로 어떻게 사용하는지 살펴보도록 하자. 일단 코드를 먼저 보고,…

#include <stdio.h>
#include <string>
#include <regex>

int main()
{
	std::string s = "123";
	std::regex number("[0-9]+");

	if(std::regex_match(s, number))
	{
		printf("number\n");
	}
	else
	{
		printf("not number\n");
	}

	return 0;
}

정규 표현식을 이용해서 문자열이 숫자인지 아닌지를 판단하는 프로그램을 만들어 본 것이다. s의 값을 변경해가면서 출력 값을 체크해보면 대략 어떻게 쓰는 것인지 알 수 있다. std::regex_match 함수를 사용하면 특정 문자열이 정규 표현식에 부합하는지 아닌지를 체크할 수 있다는 사실을 알면 되겠다. 한 가지 주의해야 할 점은 std::regex_match 함수의 경우 재귀 호출을 사용한다는 점이다. 따라서 정규 표현식에 따라서 문자열이 길면 스택 오버플로로 크래시가 발생할 수 있다. Visual Studio 2015에서는 이러한 문제점을 없애기 위해서 재귀 호출의 최대 깊이를 상수로 지정할 수 있도록 되어 있다. regex를 포함하기 전 _REGEX_MAX_STACK_COUNT를 특정 값으로 선언해 주면 된다. 기본적으로 64비트는 600, 32비트는 1000으로 설정돼 있다. 그 크기를 늘려주면 더 긴 문자열도 오류 없이 매치할 수 있다. 물론 너무 높게 설정하면 스택 오버플로로 크래시가 발생할 수 있다.

#include <stdio.h>
#include <string>
#include <regex>

int main()
{
	std::string s = "123 456 789";
	std::regex number("[0-9]+");

	std::sregex_iterator it(s.begin(), s.end(), number);
	std::sregex_iterator end;

	while(it != end)
	{
		std::smatch m = *it;

		printf("%s\n", m.str(0).c_str());

		++it;
	}

	return 0;
}

위 예제는 특정 문자열에서 정규 표현식에 부합하는 요소만 추출해서 출력하는 예를 보여주고 있다. std::sregex_iterator를 사용해서 부합하는 요소만 열거할 수 있고, std::smatch 객체를 이용하면 부합한 내용이 무엇인지 출력할 수 있다. 위 프로그램의 출력 결과는 123, 456, 789가 된다. std::smatch의 str 함수의 첫번째 파라미터로 넘어간 숫자가 애매한데 그건 매치한 대상 중에 어떤 것을 출력할지를 결정한다. 위 예에서는 매치 대상이 별도로 구분되어 있지 않기 때문에 0번 밖에는 없다. 아래 예제를 살펴보자.

#include <stdio.h>
#include <string>
#include <regex>

int main()
{
	std::string s = "123 456 789";
	std::regex number("([0-9])([0-9])([0-9])");

	std::sregex_iterator it(s.begin(), s.end(), number);
	std::sregex_iterator end;

	while(it != end)
	{
		std::smatch m = *it;

		printf("%s\n", m.str(1).c_str());

		++it;
	}

	return 0;
}

위 프로그램의 출력 결과는 1, 4, 7이 된다. 정규 표현식이 ([0-9])([0-9])([0-9]) 이와 같이 구성되어 있기 때문에 123이 이 표현식에 매치되면 std::smatch의 str 함수의 0번은 123을, 1번은 1을 2번은 2를, 3번은 3을 나타낸다. 그렇다면 정규 표현식 전체를 괄호로 한 번 더 묶으면 어떻게 될까? "(([0-9])([0-9])([0-9]))" 이렇게 말이다. 이러면 0은 123을 1도 123을 2는 1을, 3은 2를, 4는 3을 반환한다.

[소고] 봇 트레이딩 체험기...

Wed, 25 Oct 2017 12:00:01 GMT

어쩌다 올초에 비트코인에 투자를 했다. 처음에 재미삼아 1비트를 사봤는데 계속 떨어져서 물타기를 하다가 금액이 커져서 그냥 냅두게 됐었다. 그게 4, 5월 엄청 폭등하는 바람에 수익을 좀 봤다. 이런 사실을 아는 출판사 다니는 친구 녀석이 자기 회사에서 주식 자동매매 책이 잘 팔린다고 암호화폐 자동매매 책을 써 볼 생각이 없냐는 제안을 했다. 그렇게 어쩌다보니 봇 거래를 해보게 됐다.

사실 전업 프로그래머 입장에서 투자 전략이야 천차만별이지만 시스템 트레이딩 코드를 만드는 건 너무 쉽다. 게다가 포인터를 다뤄야 하는 C/C++도 아니고 파이썬이면 충분하기 때문에 뻥 좀 보태서 한 시간이면 봇을 만들 수 있다. 요는 코딩이 어려운 건 아니고 전략이 어렵다는 의미다. 어쨌든 30분 정도 REST API를 훓어보고 봇으로 거래를 해보게 됐다. 당연한 얘기지만 된다. 거기에 내가 생각한 한 가지 아이디어를 넣어서 거래를 해보게 했더니 수익이 발생하는게 아닌가? 긴 추석 연휴 기간 동안 봇을 조금 다듬었다. 그렇게 25일이 됐고 봇이 나에게 월급을 줘야 하는 시점에 봇의 성적표는 다음과 같다. 각각 날짜, 비트코인봇 수익, 비트코인봇 거래회수, 이더리움봇 수익, 이더리움봇 거래회수, 토탈 수익, 토탈 거래회수, 누적 수익이다.

BOT 트레이딩 수익

bot result

생각보다 많을 수도 있고, 적을 수도 있는데 나는 이 봇의 이름을 최저임금봇이라 명명했다. 시급 만원 정도를 추종하도록 설계됐다. 물론 시장 상황이 좋으면 더 벌기도 하고, 나쁘면 덜 벌기도 하는데 대략 그 정도 수준에서 24시간 돌면서 거래를 한다. 재미난 건 상수 값 몇 개 바꾸면 저 단위가 10배가 될 수도 있다는 점이다. 물론 내가 쪽빡찰 확률은 100배가 되겠지만 말이다. 여기까지만 쓰면 단순 자랑질 이상도 이하도 아닐 것이다. 그래서 트레이딩 봇을 만들면서 알게된 점 몇 가지를 정리해 본다. 분명 이런 시스템을 만드려는 금융 쪽 종사자가 아닌 프로그래머가 있다면 도움이 되리라 확신한다.

삼위일체

처음에 봇을 만들고 가동시키자 봇이 엉뚱한 실수를 계속 했다. 분명 50원에 샀으면 100원에 팔라고 코딩을 해놨는데 계속 40원에 팔면서 수익을 내고 있다고 착각하고 있는 것이었다. 나같은 프로페셔널한 프로그래머가 if문 따위를 잘못 코딩할리도 없는데 말이다. 부랴부랴 Ctrl + C를 눌러서 봇을 껐지만 제법 손실이 난 후였다. 이 버그 아닌 버그를 찾는데 가장 많은 시간이 들었는데 원인은 다름아닌 트랜잭션에 있었다.

내가 상상한 퐌타지한 세계는 그랬다. 거래소에서 나에게 제공하는 모든 데이터는 수직 동기화가 되어 있을 줄 알았다. 즉 그 사이게 시간 차가 존재할 줄 몰랐다는 의미다. 하지만 현실 세계는 그렇지 않았다. KRW 잔고가 먼저 반영되기도 하고, BTC 잔고가 그 다음에 움직이기도 하고, 거래 트랜잭션 데이터는 몇 십초가 있다가 확정되기도 했다. 즉 이 사이에는 어느 정도 시간적인 불일치가 있었다. 이걸 한쪽 데이터만 보고 판단해서 거래를 하면 나처럼 낭패를 볼 수 밖에 없다. 검산을 해야 한다. KRW 잔고와 BTC 잔고와 거래 내역이 모두 일치하는 삼위일체의 상태에 있을 때에 수익을 계산하고 베팅을 해야 한다.

부동소수점?

이 오류가 정확하게 부동소수점 때문인지 아니면 내 계산 방식 때문인지는 모르겠지만 위 삼위일체 검산 로직을 추가해도 정확하게 데이터가 일치하지 않았다. 나는 그냥 편하게 부동소수점 때문이라고 판단했는데 1사토시 근처에서 오류가 있는 경우가 많았다. 그래서 그냥 0.00000001 정도의 차이는 동일하다고 간주했다.

하락장을 고려해야 한다

상승만 한다면 바보 같은 봇들도 모두 수익을 낼 수 있다. 그리고 어렵게 봇을 만들 필요도 없다. 사두고 장기 보유하면 되기 때문이다. 하지만 시장은 항상 그렇듯이 오르기도 하고 내리기도 한다. 암호화폐 시장은 그 변동성이 더 크다. 그래서 봇 거래가 수익을 내기 좋은 환경이기도 하다. 어쨌든 하락장을 고려해야 한다.

처음 만든 봇은 그저 오른다는 가정하에 만들었고 시장 상황이 계속 올라서 참 쉬웠다. 그러다 하락장이 왔는데 봇은 어쩔줄을 몰라 했다. 출구전략이 필요했다. 그런데 이론적으로 주구장창 하락한다면 일반 거래로 수익을 얻을 방법은 없다. 여기서 일반 거래란 공매도 같은 장치가 없음을 의미한다. 따라서 출구 전략은 단순할 수 밖에 없다. 더 사서 물타기를 할지 아니면 손절을 할지를 판단하는게 전부다. 여러가지 전략이 있을 수 있는데 나도 5가지 정도의 전략을 테스트 해보았다. 갈수록 산수에서 수학으로 가는 내용들이 도입됐고 코드도 복잡해졌다. 그런데 아니러니 하게도 수익률은 두번째 방법이 가장 좋았다. 그래서 그냥 그걸로 적용해 두었다.

인간은 개입하지 말지어다

위에서 말한 하락장에서 봇의 손실이 제법 커졌다. 사람은 당연히 불안해질 수 밖에 없다. 봇은 사지도 팔지도 못하고 있었다. 그러다 코인 가격이 반등되어 적당한 가격이 왔다. 봇은 아직 팔 때가 아니라서 거래를 하고 있지 않았다. 사람인 나는 조급해질 수 밖에 없었다. 봇이 사들인 코인의 대부분을 이 시점에 손절해 버렸다. 봇은 회복할 수 없는 타격을 입었다. 봇은 내가 저지른 만행을 복구할 수가 없는 지경이 됐다. 결국 나는 봇의 수익률 추종치를 리밸런싱할 수 밖에 없었다. 이게 비트코인 봇인데 원래 비트코인 봇이 이더리움 봇 보다는 수익률이 월등했는데 이 당시의 내 개입으로 인해서 구려졌다.

봇이 어쩔 줄 몰라 하면 봇을 고쳐서 대응하면 된다. 절대 수동 트레이드로 개입할 필요가 없다. 왜냐하면 내가 느끼는 감성적인 수치와 봇이 정확하게 계산한 수치 사이에는 항상 간극이 존재할 수 밖에 없기 때문이다. 감정적인 대응의 결과는 손실 밖에 없다.

거래 수수료 트레이프오프

봇 트레이딩의 가장 큰 리스크는 다름 아닌 거래 수수료다. 봇이라서 엄청나게 많은 회수의 거래를 하는데 그때마다 수수료가 발생하기 때문이다. 상당수는 거래 볼륨으로 커버가 가능한데 대부분의 거래소가 거래 볼륨이 커질 수록 수수료가 낮아지도록 책정되어 있기 때문이다. 거래소에 따라서 일정 수준을 넘어서면 수수료 없이 거래하는 것도 가능하다. 그런데 문제는 그 수수료가 한 가지가 아니라 두 가지란 점에 있다. 모든 거래소 시스템이 비슷한 방식의 수수료를 책정하고 있는데 일명 메이커, 테이커 비용이다.

시장에 유동성을 공급하는 거래에는 메이커, 유동성을 없애는 거래에는 테이커 비용을 물린다. 이게 거의 수수료가 없는 쪽은 메이커 비용이고, 테이커 비용은 수수료가 높다. 테이커 비용에 물리게 되면 사실상 단타 매매로 수익을 내기가 굉장히 어려워진다. 문제는 이 테이커 비용을 최대한 덜 내게 하는 방법인데 이게 쉽지가 않다. 그런 API가 존재하면 좋겠지만 거래소 수익 때문인지 그런 API를 제공하지 않는다. 내가 주문을 낼 때에는 멀쩡한 메이커 주문이었는데 그게 거래소 트랜잭션 시스템에서 직렬화 되면서 테이커 비용을 물게 되는 경우가 왕왕있다.

당연한 얘기겠지만 되도록 이 테이커 비용을 피하면서 거래를 성사시키는 것이 중요하다. 그런데 문제가 그렇게 간단하지는 않은 것이 거래를 성립시키려면 테이커 비용을 무는 쪽으로 다가 가야 하기 때문이다. 즉, 이 사이에는 트레이드 오프가 있다. 거래를 잘 성립하게 만들다보면 테이커 비용을 무는 경우가 많고, 그렇다고 완전 회피하려면 유동성만 공급할 뿐 거래가 성사되지 않기 때문이다. 즉, 최대한 원활하게 거래를 성립시키면서 테이커 비용은 최대한 피하는 그런 방법을 만드는 것이 중요하다.

두려움을 넘어서

이 모든 봇 거래의 가장 큰 어려움은 두려움이다. 이 단순한 봇도 내 전재산의 무시 못할 수준의 금액을 가지고 도박을 한다. 내가 자는 동안에 위에서 말한 삼위일체 문제 같은게 발생한다면 거지되는 것이다. 그 두려움이 처음 3일 정도는 있었던 것 같다. 이제는 어느 정도 봇을 믿게 됐다. 특히 내가 한 수동 거래가 병신짓으로 판명난 이후에는 봇을 더 신뢰하게 됐다. 어쨌든 자신이 만든 버그가 현실 세계에서 어떻게 발현될 수 있는지 확인해 보고 싶은 프로그래머라면 도전해 볼 만한 영역인 것 같다. 물론 수익은 덤이다. 재미삼아 시작했는데 결과가 나쁘지 않아 누적 수익이 0이 될 때까지는 봇 실험을 계속해 볼 생각이다.

[소고] 코딩은 어려워

Sun, 22 Oct 2017 12:00:01 GMT

판교, 커피숍. 앉아서 간만에 회사 일이랑은 관련 없는 코딩을 좀 하고 웹서핑을 하고 있다. 옆에 여자 아이도 한 명 앉아서 뭔가를 만들고 있다. 그렇게 한참 지났을 무렵, 그 여자의 남자 친구가 왔다. 어딘가 면접을 보고 온 것 같다. 바로 옆자리 — 전원 있는 자리가 한정적이다 — 들으려고 듣는건 아닌데 말 소리가 커서 귀에 쏙쏙 꼽힌다. 흥분한 남자의 첫 마디. "넌 링크드 리스트, 요이땅 하면 바로 짤 수 있어?" 못짜지라는 말을 기대하고는 묻는 질문처럼 들린다. 여자가 링크드 리스트는 기본 아니냐는 말을 하자, 남자는 재차 말한다. "기본인데, 요이땅 하면 바로 만들 수 있냐고?" … 그렇게 한참을 입사 시험 문제에 대한 이야기들이 오간다. 판교 어딘가에 있는 회사의 코딩 시험을 방금 보고 나온 것 같다. 첫번째 문제가 링크드 리스트를 만들어서 그걸로 스택을 구현하라는 문제였던 것 같다. 다음 문제는 피보나치 수열, 팩토리얼 … 대화 내용으로 추정컨데 남자 보다는 여자가 프로그래밍을 잘하는 것으로 보인다.

면접도 많이 보고 프로그래머 채용도 더러 해봐서 그런지 대화 내용이 납득이 가기도 하고 일견 또 이해가 되지 않기도 한다. 과연 프로그래머로 일을 하는데 얼마만큼의 지식이 필요한걸까? 프로그래머라는 직업을 가지는 데 필요한 최소 수준의 지식이라는 게 있을까? 라는 생각을 해봤다. 링크드 리스트를 못 만들어도 요즘은 문제가 없다. 잘 만들어진 링크드 리스트는 정말 많다. 스택을 못 만들면 또 어떤가? 푸시, 팝 하면 기똥차게 동작하는 코드들이 널려 있다. 피보나치 수열, 팩토리얼이 뭔지 몰라도 상관 없지 않을까? 재귀호출을 모르면 또 어떤가? 사실 실전에서 그리 사용 빈도가 높지도 않은데 말이다. 그런데 또 반대로 생각해 보면 그렇다. 링크드 리스트도 요이땅 하면 못 만드는 친구가 더 복잡한 건 어떻게 만들 수 있을까? 푸시는 어떻게든 구현했는데, 팝을 구현 못했다는데 팝을 어떻게 만들어야 하는지도 모르는 친구가 현업에서 작성할 코드가 있을까? 재귀호출은 또 어떤가? 그 정도의 복잡함을 시뮬레이션 할 수 없다면 과연 더 복잡한 추상적인 구조는 어떻게 머리속에서 떠올릴 수 있을까?

하지만 세상 일이 그리 단순하진 않을 것이다. 예전의 나라면 단호하게 말했겠지만 지금의 나는 그러지는 못하겠다. 세상이 얼마나 넓은지 예전보다는 조금 더 알게 되었기 때문이다. 유명한 오픈소스 개발자가 트리를 못 뒤집어서 구글에서 떨어졌다는 일화가 한 때 유행했었다. 그때도 비슷한 생각을 했다. 과연 프로그래머로 일을 하는데 필요한 기본적인 지식이라는 게 무엇일까? 나도 구글이든 페북이든 큰 회사들의 코딩 시험에 나오는 문제들을 못 푼다. 예전에 회사에서 그런 시험에 대비하는 책을 사서 본 적이 있었는데 생각보다 문제가 어려웠다. 우리 회사의 시험 문제도 그럴지도 모른다. 문자열 복사 함수를 구현하는 일이 누군가에겐 쉬워도 누군가에겐 '=' 하나로 되는 일이기도 하고 또 누군가에겐 'strcpy’로 되는 일이기도 하니 실제로 포인터를 조작하면서 구현하는게 어려울 수도 있다. 그래도 한 가지 바램이 있다면 그런 생각이 있다. 적어도 요이땅 하면 링크드 리스트를 구현할 수 있는 프로그래머랑 같이 일하고 싶다는 바램… 트리를 뒤집는 문제는 좀 더 생각해보고…

이랬든 저랬든 코딩은 어렵다. 입사 시험에 나오는 코딩도 이렇게 어려운데 현실 세계의 복잡한 문제들을 해결하는 코드들을 작성하는 일은 또 얼마나 어렵겠는가? 알파고 제로가 하루빨리 코딩을 마스터 하는 날이 오기를 희망해 본다. 너무 어려워서 사람이 하기에 적합한 일이 아닌 것 같다. 코딩이 말이다. 물론 이건 나 혼자만의 생각은 아닌 것 같다. 세계에서 손꼽히는 석학인 Knuth 노교수도 자신이 해 본 어떤 일보다 프로그래밍이 어렵다는 이야기를 했었다.

In fact, my main conclusion after spending ten years of my life working on the TEX project is that software is hard. It’s harder than anything else I’ve ever had to do.

TEX 프로젝트에서 10 년을 보낸 후 내가 내린 주요 결론은 소프트웨어가 어렵다는 것입니다. 내가 이제까지 했던 그 어떤 일보다 더 어려워요.

[py] 파이썬으로 김프 계산하기

Wed, 05 Jul 2017 12:00:01 GMT

requests 패키지가 있으면 편리하다. 아래 명령어로 requests 패키지 설치가 가능하다.

pip install requests

거래소가 많기 때문에 일단 기준 거래소를 정해야 가격 비교가 쉽다. 거래소가 비교를 위한 REST API를 제공하지 않으면 힘들다. 만약 제공하지 않으면 그냥 과감하게 그런 거래소는 빼도록 하자. 개념이 있는 대부분의 거래소는 REST API를 제공한다. 우리는 거래량이 많은 Bittrex와 Coinone의 가격을 토대로 김치 프리미엄을 계산해 보자.

Bittrex거래소의 API는 여기 설명 페이지를 참고하면 어떤 REST API를 제공하는지 알 수 있다. Coinone은 여기 설명 페이지를 참고하면 된다. REST API라는게 별 거 없다. 그냥 get이나 post 방식으로 명령을 주면 주로 json 형태로 응답을 주는게 전부다.

우리가 가격 비교를 위해서 사용할 Bittrex API를 알아보면 다음과 같다.

https://bittrex.com/api/v1.1/public/getticker?market=USDT-BTC

위 쿼리를 날리면 비트트렉스에서 가격 정보를 JSON 형태로 날려준다. 응답에서 우리가 참고할 부분은 success필드가 true인가 하는 것과 result의 Last 값이다.

Coinone API는 다음과 같다.

https://api.coinone.co.kr/ticker/?currency=BTC

위 쿼리 응답의 result가 success인지 체크하고 last 값을 사용하면 된다.

이제 프리미엄을 계산할 달러 환율만 있으면 된다. 달러 환율은 아래 사이트를 통해서 구할 수 있다. 똑같이 REST API 형태의 쿼리로 결과를 얻을 수 있다. 결과의 USD_KRW 필드의 val 값을 참조하면 된다.

https://free.currencyconverterapi.com/api/v5/convert?q=USD_KRW&compact=y

이제 준비물이 모두 모였다. 파이썬 코드를 작성해보자.

import requests
import json

resp = requests.get('https://free.currencyconverterapi.com/api/v5/convert?q=USD_KRW&compact=y').text
usd_krw = float(json.loads(resp)["USD_KRW"]["val"])

resp = requests.get('https://bittrex.com/api/v1.1/public/getticker?market=USDT-BTC').text
btc_usd = float(json.loads(resp)["result"]["Last"])

resp = requests.get('https://api.coinone.co.kr/ticker/?currency=BTC').text
btc_krw = float(json.loads(resp)["last"])

fprice = btc_usd * usd_krw
print('Bittrex: %d Coinone: %d KP: %.2f%%' % (fprice, btc_krw, btc_krw / fprice * 100 - 100))

각각 Bittrex 가격, Coinone 가격, 김치 프리미엄이 표기된다. +면 한국이 비싼거고, -면 한국이 싼 거라고 생각하면 된다. +면 Bittrex에서 사서 Coinone에서 팔고, -면 Coinone에서 사서 BIttrex에 파는 전략을 구사하면 완벽하다. 물론 거래 수수료와 전송 속도에 따른 불확실성을 헷징할 방법은 각자 찾는 걸로…

[정보] C++ 프로그래머 채용합니다.

Wed, 29 Mar 2017 12:00:01 GMT

Figure 1. 이 정도 유머는 이해할 수 있는 C++ 프로그래머를 찾고 있습니다.

C++ 프로그래머 채용합니다. 학력, 경력, 출신, 나이, 종교, 성별, 정치성향, 외모, 성격 따지지 않습니다. C++ 코드를 읽을 수 있는지, 또 C++ 코드를 쓸 수 있는지만 봅니다. 파이썬을 할 줄 알면 더 좋구요. 몰라고 크게 상관은 하지 않습니다. 데드락 유머들 이해할 수 있다면 충분하다는 생각입니다. 윈도우/리눅스/BSD/macOS 중 하나 이상 시스템 프로그래밍 경험이 있다면 금상첨화지요.

하는 일은 심플합니다. 저희가 11년째 해오고 있는 게임 해킹툴 박멸 작업에 참여하는 일입니다.

병역특례 전직, 보충역 신규 편입 가능합니다.

참고할만한 과거 채용 공고들… http://www.jiniya.net/wp/archives/12367 http://www.jiniya.net/wp/archives/7276 http://jiniya.net/tt/694

하는 일은 동일합니다.

환경은 많이 변했습니다. 좋은 쪽으로…

관심 있는 분들은 codewiz 앳 wellbia.com으로 이력서, 자기소개서 보내 주세요.

[소고] 실험 주도 프로그래밍

Sun, 19 Feb 2017 12:00:01 GMT

신입 프로그래머들이 자주 사용하는 기법 중에 하나로 실험 주도 개발이 있다. 정식 용어는 아니고 그들이 프로그래밍 하는 과정이 일종에 물리 법칙에 관한 실험을 하는 것과 유사해서 나는 그렇게 부른다. 잘 사용한다면 빠르게 결과물을 도출할 수 있는 방법이지만 잘못 사용된다면 아주 위험할 수 있는 방법이기에 간단하게 그 방식에 관한 생각을 정리해 본다.

실험 주도 프로그래밍

int BadFunc()
{
#ifdef PLATFORM_A
    some code
#else
    some other code
#endif

    return 1;
}

위와 같은 코드에서 PLATFORM_A 환경에서만 크래시가 발생한다. 어떻게 해야 할까? 이때 우리가 대처할 수 있는 방법은 크게 두 가지 방법이 있다. 1) 덤프 파일을 분석해서 정확하게 왜 크래시가 발생했는지를 알아낸다. 2) 위 코드가 정확하게 어떤 동작을 하는 코드인지 이해하고 무엇이 잘못되었는지 생각해서 잘못된 원인을 찾아낸다. 그런데 여기에 이 두가지 방법이 아닌 전혀 새로운 방식의 접근 방법이 있다. 바로 실험 주도 프로그래밍이다.

실험 주도 프로그래밍은 물리적 현상을 추론해 내는데 사용하는 가설, 검증 방식의 실험과 유사하게 코드를 고쳐 나가는 것을 말한다. 전체적인 시나리오는 이렇다. 1) 가설을 세운다. 2) 실험을 한다. 3) 결과를 관찰한다. 아주 심플하다. 그러면 간단한 가설을 세워보자. PLATFORM_A에서만 크래시가 나니 some code의 문제일 수 있다. some code를 주석처리 한 다음 컴파일을 해본다. 이제 결과를 관찰한다. 잘 동작한다면 가설이 맞은 것이니 주석을 풀고 그 코드 내부에 대한 추가적인 세부 가설을 세우고 실험을 진행한다. 가설이 맞지 않다면 주석을 풀고 return 1 부분에 관한 가설을 세우고 다시 테스트를 한다.

이 방식은 관찰된 현상에 따라서 가설만 잘 세운다면 본질적인 구조를 모르고도 굉장히 빠르게 문제를 수정할 수 있다는 장점이 있다. 그래서 대체로 다른 이들이 작성한 코드를 유지보수해야 하는 신입 프로그래머들이 많이 사용하는 것 같다.

가설, 검증 구조가 가지는 함정

앞선 실험 주도 프로그래밍의 가설, 검증 방식의 함정은 잘 동작하는 결과를 가졌을 때 발견된다. 예를들어 보자. 앞선 코드에서 가설, 검증 과정을 통해서 return 뒤의 1을 0으로 바꾸니 크래시가 발생하지 않고 잘 동작했다고 생각해보자. 그러면 이제 거기서 1을 0으로 바꾸고 끝을 내도 되는 것일까? 만약 끝을 내도 된다고 생각한다면 다음 우스개에 나오는 과학자와 비슷한 오류를 범하는 꼴이 된다.

옛날에 한 과학자가 있었다. 파리에 관한 연구를 하던 과학자는 한날 박수를 치니 파리가 날아가는 것을 보고는 파리에게도 분명 귀가 있을 거라는 생각을 한다. 그리고 그 귀가 어디에 달려 있을까를 알아내기로 했다. 과학자는 가설을 세운다. 처음에는 파리의 귀가 다리에 붙어 있을 거라고 생각했다. 그래서 다리를 뜯었다. 그리고는 옆에서 박수 소리를 들려줬다. 그러니 파리가 날아서 도망을 갔다. 다리에 귀가 있다면 박수 소리를 못 들어 도망 가지 못했을테니 과학자는 다리는 아니라고 생각한다. 다음은 날개에 귀가 있다는 가설을 세운다. 그리고는 날개를 뜯고 실험을 했다. 그러자 이번에는 박수를 쳐도 파리가 도망 가지 않고 가만히 있었다. 과학자는 당당하게 실험 결과를 토대로 파리의 귀는 날개에 달려 있다는 논문을 쓴다.

사실 위의 우스개는 과학이 가지는 본질적인 문제점을 풍자한 것이다. 요즘 발표되는 많은 논문들이 사실은 위와 다름이 없다. 어느 날은 비타민 과다 복용이 좋다고 했다가 어느 날은 과다 복용은 위험하다고 한다. 어느 날은 운동이 건강에 좋다고 했다가, 어느 날은 운동하다 죽는 사람이 더 많다고 한다. 과학이 이러니 프로그래밍도 이렇게 하면 되는 것일까? 하지만 거기엔 엄청난 차이가 있다. 가장 큰 차이는 과학이 탐구하는 대상인 자연, 인간, 우주 같은 것들은 본질적으로 우리가 만든 것이 아니다. 그러니 우리는 그 원리를 알 수 없기 때문에 귀납적 추론을 할 수 밖에 없다. 반대로 프로그래밍은 아주 사소한 약속 하나부터 모두 우리가 정한 것이다. 그러니 이 세계는 본질적으로는 귀납적으로 추리할 필요가 없다. 모두 우리가 만든 약속을 쌓아 올려서 만든 것이니 당연히 그 모든 것을 연역적인 방식으로 설명할 수 있어야 하는 것이다.

앞선 return으로 돌아가 보자. 1을 0으로 바꾼 결과 정상 동작하는 것을 관찰했다면 그 다음은 무엇을 해야 할까? 왜 1이면 동작하지 않고, 0이면 동작하는지에 대한 설명을 할 수 있어야 한다. 만약 그걸 설명하지 못한다면 원인을 찾은 것도 아니고 코드를 이해한 것도 아니다. 이 단계에서 완전한 설명이 가능하고 그것을 다른 프로그래머에게 이야기를 했을 때에 똑같이 동의를 한다면 그것은 어느 정도 올바른 해결책을 찾은 것으로 간주해도 될 것이다.

완전한 이해

신입 프로그래머들이 실험 주도 프로그래밍의 함정에 빠지는 것은 그들이 이해해야 하는 어떤 대상에 대해서 완전한 이해를 하지 않기 때문인 것 같다. 완전한 이해의 대상은 기존에 작성된 코드일 수도 있고, 특정 프로그래밍 언어일 수도 있고, 특정 라이브러리나 프레임워크일 수도 있고, 특정 운영체제일 수도 있다. 심지어는 특정 표준에 대한 스펙일 수도 있다. 그런 대상에 대한 이해가 부족하기 때문에 어느 지점에서 문제가 발생한다는 것을 관찰했을 때에도 느낌표가 없고 계속 물음표만 존재하는 것이다.

그렇다면 많은 신입 프로그래머들이 실력 향상을 원한다고 이야기를 하면서도 정작 중요한 문제 해결에 필요한 완전한 이해를 하지 않는 것일까? 아마도 그 과정이 시간이 오래 걸리고 고통스럽기 때문일 것이다. 따분하고 지루한 공부가 필요하다는 의미다. 하지만 안타깝게도 현실 세계에서 내가 관찰한 대부분의 경우는 공부가 부족한 경우가 많았다. 일단 대체로 절대적으로 공부하는 시간이 부족하다. 앞선 이해의 대상 중 어떤 것이든 간단하게라도 살펴보기 위해서는 상당히 많은 시간이 필요하다. 하지만 많은 신입 프로그래머들은 그런 연속된 시간을 투자하는 것을 시간 낭비라고 생각한다. 심지어는 퇴근 후에 컴퓨터를 본다는 것은 뭔가 손해보는 일이라고 생각하기까지 한다. 다음으론 검색의 지나친 발달로 인한 폐해를 들 수 있다. 대체로 거의 모든 문제에 대해서 구글 검색을 하면 결과가 나오기 때문이다. 그러니 복잡하고 원론적인 이해 보다는 단편적인 현상에 대한 답만 알고 넘어가려는 경향이 강하다. 그렇게 빈약하게 이해를 하더라도 문제가 해결되니 말이다.

검색으로 얻는 파편적인 지식으로는 한계가 있다. 잘 쓰여진 좋은 책을 통해서 한 점이 아닌 전체적인 선 모양이 어떤지를 알 수 있는 공부를 해야 한다. 또 일주일에 한두시간 공부하는 것으로도 한계가 있다. 아마 환갑 잔치 때가 되서야 목표에 도달할 수 있을 것이다. 훨씬 더 많은 시간을 투자해야 한다. 물론 취미로 프로그래밍을 하거나 직업의 영속성이 크게 중요하지 않은 사람들에겐 이런 조언이 별로 중요하지 않을 수 있다. 하지만 반대로 해자를 구축하고 장기적으로 살아 남아야 하는 사람이라면 그래야 하지 않을까라는 생각을 해본다.

여기서는 제자리에 머물기 위해서라면 아주 빨리 달려야 해.
만약 다른 곳에 가려면 지금보다 두 배는 빨리 뛰어야 하지.

-— 거울 나라의 앨리스

[정보] 샌프란시스코 음식점들...

Fri, 17 Feb 2017 12:00:01 GMT

기억을 위해 샌프란시스코에서 가 본 음식점을 정리해 본다. 또 누군가에겐 도움이 되지 않을까 싶은 마음에…

산라쿠

일식집. 초밥, 사시미, 롤, 우동, 튀김 등을 판다. 일식이 대체로 그렇지만 기본은 하는 집. 쏘쏘하다. 생각보다 손님이 많다. 식사 시간에 간다면 예약하고 가는 게 정신 건강에 좋을듯.

수퍼 두퍼

이쪽 동네에 있는 햄버거 체인. 패티 두개 들어간 수퍼 버거를 먹었는데 약간 느끼했다. 토핑을 추가할 수 있는데 모두 추가한다는게 잘못돼서 그냥 일반 버거로 먹었다. 기름기가 많다. 피클을 나눠주는데 나눠주는 이유가 있는듯. 갠적으론 쉑쉑이 더 맛있었다. 첨 나오면 조그맣게 생겨서 양이 별로 안 되는 것 같은데 이동네 음식들이 다 그렇지만 먹고 나면 그런 생각이 싹 사라진다. 네이버 검색에 의하면 미니 버거에 이것 저것 추가해서 먹어보는 사람이 많은 것 같다.

닉스 라이트하우스

피어에 위치한 해산물 집. 랍스터와 만찬 세트(?!)를 먹어봤다. 아줌마가 장사를 잘한다. 랍스터는 진짜 큰 걸 먹었는데 그닥 취향은 아니었다. 만찬 세트도 그저 그런 정도. 와 맛있어서 찾아가야겠다 할 정도는 아님. 맥주는 맛있다.

39번 피어 쪽에서 구경도 하고 가게를 찾아가는게 조금 더 현명한듯한 느낌적인 느낌.

크랩 하우스 앳 피어 39

크랩집. 나쁘지 않았다. 배고플 때 한 번 가봐서 정확한 느낌은 아닐 수 있다.

존스 그릴

진짜 가지 말아야 할 집. 저주할 지어다. 스테이크 집인데 스테이크가 별로다. 비싸다. medium rare와 medium well을 시켰는데 medium well은 거의 태운 상태 medium rare는 색깔은 그런대로 맞춰 구어진 것 같은데 육즙이 제로였다. 스테이크가 아니라 고무 씹는 느낌. 역사가 오래된 느낌이어서 가봤는데 역사만 오래된 집이었다. 먹고 나서 yelp에 가봤더니 투어리스트 트랩이라는 평이 인상적이었다. 심지어 추리소설에 나온 적이 있는 집이라고 했다. 정말 돈 값 못하는 집… 참고로 함께 간 일행 모두 보통 뭔들 먹고 나서 맛없다는 이야기를 안 하는데 모두가 최악이라 평했다.

너무 빡쳐서 나오면서 다른 사람들이 시킨 것도 살펴봤는데 죄다 육즙이 없기는 마찬가지. 손님은 정말 많아서 마치 진짜 맛집같은 느낌인데… 투어리스트 트랩이라는 평이 딱 맞다. 애피타이저까진 나쁘지 않았는데…

미스 사이공

미스 사이공, 베트남 쌀국수 집. 샌프란시스코에 왔을 때 첨 가 본 쌀국수 집. 이후에 다른 쌀국수 집도 몇 군데 가봤는데 이곳이 그나마 나은듯한 느낌. 블루보틀 근처라 나오면서 블루보틀에서 라떼 한 잔 하기 좋은 위치.

고수를 싫어한다면 주문전에 노 실란트로 외워갈 것. 대체로 그렇지만 디폴트로 탑재해서 나온다.

꼬꼬방

한국식 포차. 온갖 메뉴를 다 판다. 치맥을 주로 했는데 갈비가 먹을만 했다. 라면도 괜츈하다. 늦게까지(새벽 2시?!) 하는게 장점이다. 힐튼 쪽에 호텔이면 가깝다는 것도 큰 장점. 그래서 그런지 늦은 시간에 손님이 많다.

이번에 길을 잘못 들어서 꼬꼬방 간다는게 aria라고 다른 곳을 갔는데 거기는 테이블이 별로 없고 주로 포장해서 가는 집인듯 했다. yelp 보고 찾아가면 대략 낭패.

이자카야 닌자

이자카야. 그냥저냥 먹을만하다. 시킨 거 먹기만 해서 그닥 무슨 메뉴가 있었는지 잘 기억이 안남.

고려정

한식 고기집. 삼겹살과 갈비를 먹어봤는데 쏘쏘하다. 10시에 문을 닫는다는게 술을 많이 마시는 사람 입장에서는 다소 부담스러울 수도 있다.

산왕반점

중국집. 한번쯤 가서 먹기에 괜찮다. 짬뽕 국물도 괜찮고 다른 요리 메뉴도 대체로 다 괜찮은듯.

블루보틀 커피

샌프란시스코의 명물이라고 했는데 그 출발점이 다소 불분명하다. 여튼 샌프란시스코에 파는데가 있다. 처음 가보면 간판에 이름도 없고 파란병만 그려 있는 것이 다소 황당하다. 라떼가 맛있다. 탁월한 부드러움, 적당한 온도, 고소함이 특징. 사실 다른 라떼랑 섞어 놓고 고르라면 고를 자신은 의문…

블루보틀 앞에 푸드 트럭이 있는데 의외로 현지인들에게 인기있는 듯 하다. 보울드 아사이라고, 기회되면 한 번 먹어 보고 싶었다. 현지인들이 많이 먹는 것으로 봐서는 먹을만한 것 같은 느낌적인 느낌. 한국으로 치면 일종의 컵밥 같은?! 단점이라면 근처에 홈리스가 많아서 잊을만하면 한번씩 온다는 점.

태드네 스테이크

스테이크만 달랑 나온다. 싸고 양이 많은 게 장점인듯. 그냥저냥 먹을만 하다. 존스 그릴 보다는 백만배쯤 맛있다.

테일러 커피숍

아침을 판다. 엄청 좁다. 아침에 가면 사람이 좀 있다. 재수 없으면 엄청 오래 기다려야 함. 그냥 미국식 아침 메뉴를 판다. 베이컨, 에그, 뭐 그런. 먹을만 하다.

진미순두부

순두부집. 샌프란시스코에는 BCD 북창동 순두부는 없는 듯 하다. 왤까? 해물순두부만 먹어봤는데 그럭저럭 먹을만하다. 아침 식사 가능하다.

더 스피나커

다운타운에 있는 집은 아니다. 금문교 건너 소살리토라는 동네에 위치한 집. 바다에 완전 접해 있어서 전망이 예술이다. 간다면 꼭 창가 자리로 예약할 것. 스테이크를 먹었었는데 맛있었다. 소살리토도 구경하기 좋은 동네. 다운타운이랑은 분위기가 천지차이다. 일단 홈리스와 지린내가 없다.

[일상] RSA 2017 DAY #2

Fri, 17 Feb 2017 10:00:01 GMT

1일차는 노스관 2일차는 사우스관을 봤다. 사우스 쪽은 우리랑 비슷한 일을 하는 업체는 없는 것으로 보였다. 1, 2일 모두 쭉 돌아보면서 많이 본 키워드를 뽑아 보면 breach, endpoint, malware, NGAV(Next Generation Anti-Virus), mobile, virtual 정도 인 듯. 대략 그런 일을 하는 업체들이 많은 것 같다. 백신 업체도 더이상 백신 이야기를 많이 하지 않는 느낌적인 느낌. 메이저 백신 업체들의 타겟팅은 이제 일반 PC 보다는 IoT 쪽이 많은 것 같아 보였고, 심지어는 국가 기간망을 대상으로 영업 활동을 전개하는 곳도 있어 보였다.

이런 쇼 오면 꼭 하나 살펴보는 게 빨때 꼽는 업체들을 찾아본다. 보안 쪽은 로그 서비스와 라이브러리 정도가 전부인 것 같다. 보안 업체 특성 상 또 외부 솔루션을 잘 사용하지 않기 때문인 것 같아서 그런 것 같기도 하다. 직원 보호 솔루션이라 쓰고 감시(?!)하는 솔루션도 더러 있었는데 약간 무섭기도 했다.

대체로 대다수 업체가 센서를 통해서 온갖 정보를 수집하고 인공 지능이나 머신 러닝 같은 기술을 사용해서 마이닝을 하여 뭔가 찾아낸 다음 그걸 알흠답게 고객에게 뷰잉해주겠다는 방향으로 달려가는 것 같은 느낌…

또하나 인상적인 것은 미국 국가 기관 부스가 많이 있었다. 대체로 홍보나 기술 전시 보다는 채용에 목적을 둔 것으로 추정되는데 신기한 점이긴 했다. 한국 업체 중에서는 파수가 그나마 부스를 멋들어지게 만들었다. 부스만 보고는 한국 업체 아닌줄… ㅋㅋㅋ~

[일상] RSA 2017 DAY #1

Thu, 16 Feb 2017 10:00:01 GMT

Figure 1. RSA 2017 엑스포 배지

세계 최대 보안 컨퍼런스인 RSA에 처음으로 참관했다. 뭐 배우러 온것은 아니고 세상이 어찌 돌아가는지 구경하는게 목적이라 엑스포만 참관했다. 그간 다녀본 게임 관련 쇼나 컨퍼런스랑은 다소 다른 분위기였다. 보안이라 그런지 대체로 거의 모든 사람이 정장을 입고 있다는데 적응이 되지 않았고, 보안이라 비주얼이 약해서 보는 재미가 별로 없었다. 대부분의 부스가 그럼에도 액티브하게 보이려고 노력을 했지만 한계가 있어 보였다. 말이 많이 필요했고, 부스도 대체로 수많은 텍스트로 꾸며진 경우가 많았다.

어쨌든 참관하면서 관심 있게 본 유사 분야 업체를 간단히 정리해 본다. 별로 없을 줄 알았는데 생각보다 없지는 않았다. 알리바바가 특히 의외였다. 마윈 회장이 자율 주행 자동차도 만든다고 얘기하는 걸 티비에서 본 적이 있었는데 정말 안 하는게 없는 것 같다.

GuardSquare 안드로이드에서 많이 사용되는 난독화 도구인 ProGuard, DexGuard의 제작사. DexGuard 플러그인으로 DexGuard NDK와 Secure Keyboard, Device Fingerprinting이 있다는 것을 새롭게 알게 됐다. 그리고 iOS 버전으로 새롭게 출시한 iXGuard가 있다는 것도. 부스에서 iXGuard를 그닥 홍보하고 있지는 않았다. 왤까?

AlibabaCloud Mobile Security 알리바바에서 클라우드를 하는 업체인 알리바바클라우드에서 모바일 보안 서비스도 제공하고 있는 것으로 보여진다. Alibaba JAQ Security Solution으로 불리는 것으로 애플리케이션 하드닝으로 표현하는 기술이 기존에 난독화 솔루션이 대체로 제공하는 기능으로 보여진다. 브로셔를 보면 SO, DEX 난독화 기능을 SO shelling, DEX shelling으로 표현한게 인상적. 껍데기를 씌우는거라 그렇게 표현한 것으로 추측된다. 인상적인 부분은 Java execution simulation 자바단의 코드를 덤프하는 것을 막기 위해서 별도의 환경에서 코드를 돌리는 기술을 말하는 것으로 보여졌다.

알리바바가 이런 것도 한다는게 다소 신기했다. 대기업들이 돈되는 건 다하는 세상인 것 같아 조금은 씁슬한 면도 없잖아 있었다. 불과 몇년만에 알리바바를 스타트업에서 대기업으로 표현하는 게 좀 웃기긴 하지만. 어쨌든 이제는 대기업이니…

ARXAN 기술적인 진화 보다는 시장을 분류해서 마케팅하는 방법이 인상적이었다. 게임을 위한 제품(for Gaming), 모바일 결제 및 뱅킹을 위한 제품 (for Mobile Payment & Banking), 헬스케어 장비를 위한 제품 (for Healthcare IoT), 자동차 장비를 위한 제품(for Automotive IoT)으로 나눠서 제품을 만들었다. 물론 근간이 되는 기술은 크게 다르지 않은 것으로 보여진다. 사실 자동차까지는 많이들 얘기하지만 의료 장비는 다소 의외였다. 보안이 필요 없는 분야가 있겠냐만은, 의료장비 레퍼런스가 있는지가 조금 궁금하긴 했다.

AllthatSoft 쉴딩 형태의 제품으로 보여지는 모바일 코드 보호 제품인 App Servo를 홍보하고 있었다. 제품의 기술적인 특이점은 흔히 스톨른 바이트(Stolen Bytes)라고 불리는 기법을 적용한 제품이라는 것. 원본 코드를 분리하고 특정 코드를 외부에 보관한 다음 필요한 시점에 동적 결합 또는 원격 실행을 하는 구조인 것으로 보여진다. 해당 회사는 그 기능을 Self-Randomization으로 소개하고 세부 주요 구현 기술로 CODE-SPLITTING, SELF-MODIFYING이라고 설명했다. 어쨌든 스톨른 바이트에 기반한 앱 보호 제품은 첨 본 것 같다.

적용 분야로 모바일 결제, 모바일 뱅킹, 자동차 공유, 모바일 게임을 들고 있다. 자동차 공유 서비스를 타게팅한 것도 다소 의외였다.

intertrust whiteCryption의 Code Protection 기능이 하드닝, 난독화 기능을 제공하는 것으로 보여진다. 대체로 브로셔에서 설명하는 개념은 ARXAN이랑 비슷한 것으로 보여졌다. 단지 ARXAN은 가드라고 부르고 intertrust는 체커라고 부르는 게 차이점인듯.

덧) 구경하는데 왜 이렇게 줄이 길지 하는 곳이 있었다. 뭐 나눠 주나보다 했는데 케빈 미트닉 옹께서 "The Art of Invisibility"라는 본인의 저서에 사인을 해주고 사진을 같이 찍어주는 행사를 하고 있었다. 첨에는 케빈 미트닉이 아닌 줄 알았다. 줄이 길고 피곤해서 사인북을 받지는 않았는데, 나중에 나와서 검색해보니 매년 오시는 것 같다.

[일상] 광고, 예술이 되다.

Fri, 10 Feb 2017 12:00:01 GMT

어쩌다 유튜브 보는데 나온 광고. 차에 관심 1도 없는데 살짝 심쿵했다. 간지 멘트하며, 그 멘트들의 절묘한 전개, "The balance isn’t found. It’s created"에서는 이래서 이빨에 넘어가는 구나 했다. 저 느린듯 템포 있게 조화로운 배경 음악 하며. 저 차 사면 진짜 막 용에 올라타는 그런 느낌일거 같고… 급기야 무슨 브랜드인지를 몰라서 심지어 정지시켜 놓고 검색해보게 만드는 위엄. 이래서 광고가 돈이 되는구나 싶다. 하지만 결정적으로 차 디자인은 내 스타일은 아니긔… ㅋㅋㅋ

정반대 느낌의 기아차 슈퍼볼 광고, 재미는 있다. 아니 재미만 있다.

[소고] 당신의 연말 정산 이야기

Mon, 06 Feb 2017 12:00:01 GMT

연말 정산 시즌이다. 이맘때면 한숨과 고성이 오간다. 13월의 급여를 받는 사람도 있고, 한달치 급여가 사라진 사람들도 있다. 연말 정산의 아픔이 잊혀질만한 4월이 되면 건보료 폭탄이 또 한 번 때린다. 대체로 급여가 오른 만큼 건보료도 정산해서 토해낸다. 그때는 다들 한숨만 깊어진다. 나이가 들고 연봉이 오르고 하다보면 결국 알게 되는 건 세금 밖에 없다.

토해내는 입장에서는 도대체 돌려 받는 사람들은 왜 돌려받는지가 무척 궁금해진다. 그리고 무지에 의해서 마치 엄청난 비밀이 숨어 있는 것처럼 음모론들을 제기해 보지만 거기에 음모 따위는 없다. 그저 여러분이 국가가 장려하는 활동을 많이 하면 혜택을 많이 주고, 국가가 싫어하는 활동을 많이 하면 세금이 많아지고 하는 것이다. 각설하고 이 말도 많고 탈도 많은 연말 정산이 어떤 구조로 이루어지는지 살펴보도록 하자.

연말 정산은 말 그대로 일년 동안 내야할 세금을 최종적으로 확정짓는 과정이다. 대한민국은 급여소득자에게 세금을 미리 원천 징수하고 나중에 다시 정산 과정을 통해서 원천 징수한 금액이 많으면 돌려주고, 적으면 더 받아내는 시스템을 사용한다. 흔히 직장인 급여를 유리 지갑이라고 하는 이유가 여기 있다. 애초에 받을 때 국가에 신고가 들어가고 세금은 공제하고 남은 차액만 받기 때문이다. 당신의 급여 명세서 항목 중에서 소득세와 지방세라는 것이 국가가 이렇게 미리 뜯어가는 비용이다.

그러면 그냥 원천 징수만 하고 끝내면 될텐데 왜 연말 정산이라는 것을 할까? 원천 징수는 표준 모형에 의한 것이기 때문에 원천 징수를 얼마 할지는 급여가 정해지면 일괄적으로 책정된다. 하지만 국가가 그리 나쁜 놈들은 아니다. 아니면 더 나쁜 놈일수도 있다. 어쨌든 그런 이유로 국가는 사람들이 그 급여를 몽땅 다 써버리길 원하지 않는다. 그들의 미래를 위해서 쓰기를 바라기도 하고 자신들의 세금 계산을 위해서 현금이 아닌 카드를 사용하기를 원하기도 한다. 또 부양 가족이 있어서 돈이 많이 필요한 사람들에게는 세금을 감면해 주기도 한다. 결국 국가는 최종적으로 개개인들에게 그들의 돈을 어떻게 사용해야 할지에 대한 인센티브를 세금을 통해서 제공한다고 보면 된다.

그럼 먼저 소득세를 어떻게 계산하는지에 대해서 간단히 살펴보자. 대한민국의 소득세는 누진적 구조로 이루어져 있다. 즉 많이 벌면 세금을 더 많이 내도록 된 구조다. 살펴보면 1200만원 이하는 6%의 세금을, 그 다음 4600만원 이하는 15%의 세금을 그 다음 8800만원 이하는 24%의 세금을, 그 다음 1억 5000만원 이하는 35%의 세금을, 그 다음 5억 이하는 38%의 세금을, 5억을 초과하면 40%의 세금을 낸다. 자, 통크게 내 연봉이 10억이라고 가정해보자. 그럼 얼마를 세금으로 내야 할까? 1200만원까지는 72만원 4600만원까지 510만원, 8800만원까지 1008만원, 15000까지 2170만원, 5억까지 13300만원, 끝으로 10억까지 20000만원을 세금으로 낸다. 다 더하면 72 + 510 + 1008 + 2170 + 13300 + 20000 = 37060만원을 세금으로 낸다. 여기에 10% 지방세가 붙는다. 3706만원을 지방세로 납부하니 최종적으로는 10억을 벌면 국가에 4억 하고도 766만원을 세금으로 내야 한다. (계산하고 공제하는 더 간편한 방법이 있다. 단지 어떻게 세금이 누진되어 가는지를 보여주기 위해서 불편한 방법을 썼다.)

다음으로는 이제 이렇게 산정된 소득세에 대해서 어떤 방식으로 인센티브를 제공하는 살펴보자. 인센티브를 제공하는 방식은 크게 두 가지 방식이 있다. 하나는 소득 공제이고 다른 하나는 세액 공제다. 소득 공제는 전체 소득에서 정해진 만큼 빼고 세금을 계산하는 방식이고, 세액 공제는 최종 확정된 세금에서 정해진 만큼 빼는 구조다. 이 둘의 차이는 쉽게 말하면 이렇다. 소득 공제는 세금 계산 전에 빼기 때문에 혜택이 차등적이고, 세액 공제는 균등하다. 다시 말하면 소득 공제는 배율을 확정짓기 전에 빼기 때문에 고소득자일수록 유리하다. 최고 세율인 40%인 사람들의 경우 100만원 소득 공제가 되면 40만원을 돌려 받는 것과 동일한 효과를 가진다. 반면 소득세율이 15%인 사람은 15만원을 돌려받는데 그친다. 똑같이 100만원 쓴 것에 대한 혜택을 받는데 고소득자가 더 유리한 제도인 것이다. 반면 세액 공제는 최종 금액에서 차감하기 때문에 동일한 활동을 했을 때 고소득자와 저소득자가 받는 차이는 크게 없다.

여기서 조삼모사가 나온다. 예를 들면 연금저축을 들 수 있다. 이게 원래 400만원까지 소득 공제 항목에 있었다. 그러면 40% 세금을 낸다면 연 160만원을 돌려받을 수 있고, 20% 세금을 내는 사람은 80만원을 돌려 받는 구조였다. 그런데 정부에서 이를 세액 공제로 변경했다. 그리고는 400만원을 납입하면 연 100만원을 세액 공제 해준다고 한 것이다. 40% 세금을 내던 사람은 이제는 60만원을 덜 돌려 받게 되었고, 20% 세금을 내던 사람은 20만원을 더 돌려받게 된다. 즉, 대체로 세액 공제로 바뀌면 없는 사람에게 더 유리해 지는 것이다. 그럼에도 정부가 그때 개욕을 먹었던 것은 저 세액 공제율을 잘못 선정하는 바람에 고소득자든 저소득자든 다 손해보는 구조를 만들어서 그런 것이었다. 물론 그것조차도 계획된 것일 수 있지만… (참고로 여기에 제시된 수치들은 가상적인 수치다)

자 이게 연말 정산의 모든 비밀이다. 국가가 세금을 미리 계산해서 가져갔고, 연말 정산을 할 때에는 이제 국가가 장려하는 활동에 얼마를 썼느냐에 따라서 세금을 다시 조정할 것이다. 국가가 좋아하는 일을 했다면 세금을 많이 돌려받을 것이고, 국가가 싫어하는 일을 했다면 그닥 못 돌려 받을 것이다.

2017년 대한민국은 어떤 활동에 인센티브를 제공하는지 살펴보자. 소득 공제 항목을 살펴보면 이렇다. 부양 가족. 최고로 갑이다. 벌이가 없는 부모님, 자식 등을 부양가족으로 올리면 일정 수준 소득 공제를 해준다. 더불어 그 부양 가족이 사용한 모든 비용도 내가 사용한 비용으로 인정해준다. 일정 조건에 합당한 무주택자가 집 산다고 빌린 돈. 님들이 집을 사도록 국가가 유도하는 것이다. 어쨌든 이를 갚은 것들은 국가가 비용으로 인정해주고 일정 수준 세금을 감면해 준다. 신용카드 사용액, 이는 최초에는 현금이 아닌 신용카드 사용을 장려하기 위해 생긴 제도였다. 지금은 많이 퇴색되어 수명이 오늘 내일 하는 소득공제 항목 중에 하나다. 여기에 관해 생긴 가장 큰 오해 중에 하나가 연말 정산에서 많이 쓰면 많이 돌려받는 다는 것이다. 그런데 신용 카드 사용에 관해서는 아주 복잡한 공식이 존재하지만 결론만 말하면 쓰는 금액 대비 공제해 주는 양이 아주 적기 때문에 이를 위해서 지출을 늘리는 것은 정말 바보 같은 행위다. 기부금. 이는 사실 소득공제로 보긴 힘들다. 기부한 금액보다는 적게 소득 공제를 해주기 때문이다. 주택마련 저축 납입금. 집 산다고 통장을 만들어 납입하면 정해진 한도 내에서 소득 공제를 해준다. 그리고 일반인들에게는 잘 알려지지 않았지만 지금 최고의 소득 공제 항목으로는 벤처 기업 투자가 있다. 조건에 해당하는 벤처기업에 투자할 경우 파격적인 소득 공제 혜택을 준다.

세액 공제 항목을 살펴보면 이렇다. 보장성 보험을 가입하면 연간 100만원 한도 내에서 일정 수준 세액 공제를 해준다. 일년에 여유되면 100만원 정도는 보장성 보험에 돈을 투자하라는 예기다. 연금저축 연간 400만원 한도 내에서 일정 수준 세액 공제를 해준다. 이는 말이 많은 항목인데 더 맡이 많아지게 되었다. 왜냐하면 정부의 안대로 지금 당장 납입하면 세액 공제를 받을 수 있지만 나중에 연금을 받을 때 다시 세금을 납부하기 때문에 실제로는 정말 조삼모사같은 상품이기 때문이다. 이는 실상은 과세 이연이지 혜택이라고 보기는 힘들다. 그래도 어쨌든 국가는 여러분의 미래를 위해서 연금을 들기를 희망하고 있다. 퇴직 연금 또한 연에 300만원 한도로 세액 공제를 해준다. 의료비, 교육비도 일정 수준 공제를 해준다. 또 정치 기부금의 경우 10만원까지는 전액 세액 공제가 된다. 좋아하는 국회의원이 있다면 10만원 기부하면 10만원을 돌려받게 된다. 참으로 신박한데 법을 누가 정하는지 알게되면 왜 이런 신박한 제도가 생겼는지 절로 이해가 된다. 월세에 대한 세액 공제도 해준다. 일정 수준의 조건이 맞아야 하지만 월세로 납부한 금액의 일부를 세액 공제로 돌려준다.

자 종합해보면 그렇다. 정부는 여러분이 결혼을 해서(+부양가족) 빚을 내서(+대출) 집을 산(+부동산) 다음에도 여유가 있다면 기부를 하기를 희망한다. 자신의 소득의 일정 수준 이상은 신용카드로 사용하기를 희망하고, 신용카드 보다는 체크카드 사용을 더 장려하고 있다. 보장성 보험을 연간 100만원 정도 내기를 바라고, 개개인의 미래를 위해서 연금 저축을 400만원, 퇴직 연금을 300만원 정도 매년 투자하기를 바란다. 국회 의원에게는 매년 10만원 정도 무조건 기부를 했으면 하고, 여러분이 그나마 월세에서 고통 받는 것을 조금은 덜어주고 싶어한다. 그리고 여러분이 이 모든 활동을 넘어서 돈이 너무 많은 자산가라면 벤처 기업에 투자하기를 희망한다.

조금 더 현실적인 조언을 해보자. 여러분이 일반적인 급여 수준의 미혼 남성이라면 어떤 활동을 하는 것이 좋을까? 일단 영혼까지 끌어모아 부양가족 수를 늘린다. 청약 저축을 만들고 매달 10만원씩 납부한다. 보장성 보험이 없다면 만들고 매달 9만원 정도 납부하고, 연금 저축을 개설하고 매달 34만원씩 납부하고, 퇴직 연금이 된다면 매달 25만원씩 납부하고, 12월에 한 번 그 해 제일 맘에 드는 국회의원에게 10만원 기부를 하면 대체로 정부가 원하는 대로 행동했다고 볼 수 있겠다. 물론 월세를 살고 있다면 월세 비용도 공제 받으면 금상첨화.

끝으로 최근 들어 생긴 조삼모사 끝판 대장 중에 하나를 소개하고 마칠까한다. 바로 원천 징수율을 결정하는 것이다. 80%, 100%, 120% 중에 선택할 수 있다. 적게 내고 적게 돌려 받을 지, 사전에 많이 떼고 많이 돌려받을지 결정하는 것이다. 대체로 자금 관리에 자신이 있는 사람이라면 80%가 유리하다. 왜냐하면 시간 가치가 있기 때문이다. 이자도 없이 정부가 일년간 묵혔다가 주는 돈을 받는 것 보다는 먼저 많이 받고 그 돈을 투자해서 불리는 것이 유리하기 때문이다. 모두가 이상적인 사람으로만 구성되었다면 사실상 100%와 120%는 의미 없는 선택지다. 하지만, 여러분이 비자금이 필요한 유부남이라던가, 자금 관리에는 젬병인 사람이라면 120%를 선택하는 것도 나쁘진 않다. 어쨌든 미리 많이 뗐기 때문에 돌려 받을 돈이 많을 수 밖에 없다. 강제 비자금 통장, 강제 적금 통장으로 국세청을 이용하는 셈이된다.

[소고] 서울 유동인구 어디가 많을까?

Mon, 06 Feb 2017 10:00:01 GMT

2003년에 처음 구로공단에 내렸을 때가 생각난다. 병역특례 전직 업체를 찾아서 온 서울, 그 전 면접은 최악이었다. 스마트폰도 없던 시대. 주소 하나 가지고 건물을 찾아가야 하는 상황, 뭔가 이상해서 길을 물어보면 아무도 길을 몰랐다. 그렇게 서울은 20대의 나에겐 차가운 도시였다.

병역특례를 마치고는 영원히 인연이 없을것 같았던 구로디지털단지에 10년이 훌쩍 넘는 내 청춘의 시간을 갈아 넣었다. 그나마 조금의 위안이 있다면 2003년과 지금은 상전벽해라는 말이 어울릴 정도로 많이 변했다는 것 하나. 온통 공사중이던 빌딩들은 이제 더 이상 지을 공간이 부족할 정도로 빼곡이 들어섰고, 그 사이 호텔이 두개나 지어졌고, 최근 들어 국내에서 돈을 제일 잘 번다는 게임사도 본사를 두고 있다. 가끔 지인들과 근처에서 술을 마시면 이런 얘기들을 하곤 한다. 여기가 요즘 서울에서 유동인구로는 순위권에 드는 동네라고 말이다. 뭐 사실 근거 있는 얘기는 아니었다. 그냥 먹자 골목에 사람이 많다는 것, 그리고 우리가 들어간 식당에 대기가 너무 길다는 것 같은 추상적인 현상을 토대로 하는 말들어었다.

문득 갑작스럽게 그 말이 진짜인지 궁금했다. 구글 검색을 해보았지만 예전 데이터 뿐이었다. 이럴 때는 프로그래머라는 직업이 다소 편리하다. 디지털 데이터는 도처에 널려있고, 프로그래머는 그것들을 아주 손쉽게 입맛에 맞게 가공할 수 있기 때문이다. 다양한 방법이 있겠지만 나는 그 지역 대중 교통을 사용하는 사람의 인원으로 유동인구를 측정해 보기로 했다. 서울 시에서 제공하는 공공 원시 데이터를 가공해서 수치를 뽑아 보았다.

먼저 지하철이다. 2016년 12월 승하차 데이터를 대상으로 집계한 순위다. 데이터 내용은 순번, 만단위 승하차인원, 지하철역이다. 2호선 강남역이 1등으로 12월 한달간 562만명이 그 역에서 승하차를 했다. 2등은 잠실역으로 480만명, 3등은 홍대로 473만명이 이용을 했다. 회사가 있는 구로디지털단지역은 5등으로 357만명이 승하차를 했다. 다음 역들을 보아도 대체로 우리가 알고 있는 유명한 역들이 상위권에 랭크돼 있는 것을 확인할 수 있다.

001 562 2호선_강남
002 480 2호선_잠실(송파구청)
003 473 2호선_홍대입구
004 399 2호선_신림
005 357 2호선_구로디지털단지
006 350 2호선_신도림
007 347 2호선_삼성(무역센터)
008 326 3호선_고속터미널
009 315 1호선_서울역
010 301 2호선_을지로입구
011 297 경부선_영등포
012 288 2호선_선릉
013 287 2호선_서울대입구(관악구청)
014 285 2호선_신촌
015 274 1호선_종각
016 271 2호선_역삼
017 270 2호선_강변(동서울터미널)
018 270 4호선_혜화
019 267 2호선_건대입구
020 263 2호선_사당
021 253 4호선_명동
022 252 4호선_수유(강북구청)
023 251 5호선_광화문(세종문화회관)
024 241 경부선_수원
025 240 3호선_양재(서초구청)
026 233 3호선_연신내
027 227 경인선_부천
028 227 7호선_가산디지털단지
029 223 경인선_부평
030 221 2호선_교대(법원.검찰청)

다음은 버스를 기준으로 살펴보았다. 같은 기간 2016년 12월 데이터로 순번, 정류장ID, 만단위 승하차 인원, 역이름이다. 정류장ID는 네이버 지도를 이용하면 해당 역의 위치가 어디인지 검색된다. 버스는 미아사거리와 수유역이 1, 2등을 차지했다. 강남역은 3등에 54만명, 11위에 46만명이, 구로디지털단지는 4등에 53만명, 6등에 51만명이 랭크됐다.

001 09012 064 미아사거리역
002 09004 061 수유역.강북구청
003 22012 054 지하철2호선강남역
004 17014 053 구로디지털단지역환승센터
005 22020 051 고속터미널
006 21001 051 구로디지털단지역
007 09011 049 미아사거리역
008 22019 048 고속터미널
009 06015 047 청량리역환승센타
010 24146 046 잠실역.롯데월드
011 22011 046 지하철2호선강남역
012 09013 045 수유(강북구청)역
013 08008 045 돈암사거리.성신여대입구
014 19112 044 경방타임스퀘어.신세계백화점
015 14015 043 홍대입구역
016 21148 040 신림사거리
017 08010 039 삼선교.한성대학교
018 24138 037 잠실역.롯데월드
019 06019 037 청량리역환승센터
020 21350 037 신림사거리.신림역
021 14016 036 홍대입구역
022 11283 035 석계역1번출구A
023 17001 035 신도림역
024 21916 034 신림역4번출구
025 17002 034 신도림역
026 21117 034 신림사거리.신림역
027 08007 033 돈암사거리.성신여대입구
028 02140 032 롯데백화점
029 24132 032 잠실역8번출구
030 13028 032 홍제역

상기 데이터로 볼 때 우리가 얘기했던 구로디지털단지가 강남, 홍대 수준의 유동인구를 가지고 있다는 말은 실제 사실인 것으로 보인다. 압구정과 신촌이 죽었다는 것도 어느 정도 사실인 것으로 보인다. 번외로 신기했던 점은 전혀 몰랐던 수유역이 사람이 많다는 점과 신림역은 알았지만 생각외로 많다는 점 정도인 것 같다. 시간 나면 장기 데이터를 토대로 추계를 뽑아보면 더 재밌을거 같기도 하다.

[일상] CES 2017 DAY #3

Wed, 04 Jan 2017 12:30:01 GMT

미국시간 2017.01.06 14:00 pm - 20:00 pm

전날의 여파로 모두가 늦잠을 잤다. 그나마 S만 일찍 일어났다. S가 네 번 Y와 J를 깨웠지만 그들은 너무 깊이 잠든 상태였다. TKS가 먼저 CES를 구경하로 떠났다. S는 먼저 간다고 일어나면 연락 달라는 라인 메시지를 남기고 떠났다. Y와 J가 그것을 본 것은 오후가 되어서였다.

오후에 일어난 Y와 J는 어짜피 늦었다는 생각에 급하게 굴지는 않았다. 씻고 준비한 다음 1층에서 아점으로 라면을 먹기로 했다. 컵라면이 없어 끓인 라면 두개를 했다. 계란도 있어 두 개를 넣었다. 햇반도 두 개 데우고, 김과 참지를 꺼냈다. Y는 차려진 한 상을 보면서 여기가 베가스인지 판교인지 알기가 힘들다는 생각을 했다. 라면을 먹고 J가 우버를 불렀다. 도착한다고 해서 밖에서 기다렸는데 기사가 취소를 해버렸다. 다시 부른 사이 가스 아저씨가 와서 그 집 가스 미터기를 보여줄 수 있냐는 말을 건낸다. 대략 무슨 말인지는 알겠지만 그에게 우리 상황을 설명하기는 쉽지 않았다. 버벅대는 영어로 힘들게 이것 저것 이야기한다. 결국 그는 포기하고 돌아간다. 조금 있다 우버가 도착했고, 그걸 타고 컨벤션 센터로 이동했다.

Figure 1. 어제 아껴 놓았던 사우스 관

이미 너무 늦었기 때문에 사우스 관을 다 보기는 힘들어 보였다. 그래서 애초에 다 보는 것은 포기하고 볼 수 있는 만큼만 보겠다는 생각으로 돌아 다녔다. DJI 부스가 컸다. 드론계의 애플이라 불리는 중국 회사. 하지만 부스가 크게 감흥은 없었다. 그저 접어지는 들고다니기 편한 드론이 있다는 정도? 그렇게 부스를 보다가 M을 만났다. M을 만나 조금 더 구경을 하고는 밖으로 나왔다. M은 DJI 보다 달걀 모얌으로 생긴 드론 팜플렛을 보여주며 이게 더 인상 깊었다는 이야기를 했다. 그러면서 오늘 아침 이야기를 했는데 정말 황당했다. 그가 타고오는 모노레일의 같은 칸을 T와 K와 S가 탔다는 것이었다. 그러면서 만나도 어떻게 그렇게 만나냐며 너스레를 떤다.

Figure 2. DJI의 접히는 드론. 접어서 들고다니기가 편하다.

J와 M과 Y가 기다리고 있는 장소는 어제 그곳이다. 버스정류장 벤치. J가 라인으로 위치를 보낸다. 조금 있다 S가 도착했다. K와 T를 물으니 중간에 헤어져서 모르겠다고 한다. 조금 있다 메시지가 하나 더 왔다. KT는 샤오미 부스에 있는데 조금 더 보다가 이동하겠다는 내용이다. JYMS는 모노레일을 타고 이동한다. 어제와 다르게 너무나 사람이 많고 줄은 개미가 기어가는 속도로 줄어들었다. 마칠 시간에 사람이 몰려서 그런 것 같다. 힘들게 들어가서 그들이 내린 곳은 센터에서 한 정거장 옆에 있는 LINQ 역이었다. Y는 이상한 생각이 든다. LINQ 호텔인데 자꾸 프로그래밍 할 때 만난 LINQ가 떠올랐기 때문이다.

Figure 3. LINQ 역과 카지노 입구 사이에 있던 NOOK, 나름 단열처리된 컵이다.

LINQ 역에 내려서 호텔로 이동하는 연결 지점에 있는 NOOK 커피숍에 잠시 앉는다. 아메리카노를 시킨다. 그즈음 KT도 나왔다는 메시지를 보냈다. 하지만 JYMS가 있는 곳은 로밍 인터넷이 터지지 않는 지점이다. J가 멀리 돌아가서 인터넷 되는 곳에서 NOOK 커피숍 위치를 알려주고 돌아온다. 커피 잔에 두르는 골판지를 가지러 갔던 M이 돌아오면서 커피잔이 특수 처리돼서 필요 없다는 이야기를 들었다며 이래서 미국 촌놈이라는 이야기를 듣는다며 수줍어 한다. 그제서야 J, Y, S도 커피잔을 다시 만져본다. 잔이 이중으로 되어 있다. 그리고 그 사이에 공기가 들어가 있다. 어떤게 효과적인지는 모르겠지만 Y는 골판지 만큼 그 이중 공기 단열이 효과적인 것은 아니라는 생각을 한다.

잠시후 KT가 도착했다. 똑같이 커피를 시킨다. 둘러앉아 남은 일정에 대해서 이야기를 한다. J와 M이 베가스에 왔으니 카지노를 한 번 하고 가자고 한다. Y도 그러자고 한다. 하지만 KTS는 신통찮은 분위기다. 마지못해 동의해서 차가 있는 플라밍고 근처에서 카지노를 하기로 한다. 그렇게 플라밍고에 도착할 무렵 K는 T와 S에게 대관람차를 타자는 제안을 한다. 그리고 JYM에게는 카지노를 하고 만나자고 제안한다. JYM도 동의한다. J, Y, M은 플라밍고 카지노로 들어갔다. J가 카지노로 들어가며 우리만 노름꾼이 된 것 같다는 불평을 한다. 잠시 방황하다 빈 자리가 있는 룰렛 테이블에 앉았다. 각자 100불씩 칩을 바꾸고 플레이를 한다. 모두가 처음이기에 베팅 실수가 조금 발생한다. 특히 Y가 딜러의 잔소리를 많이 듣는다. 3번 정도 실수 후에 룰을 완전히 알 수 있었다. 룰렛의 인과 아웃이 있는데 인은 개별 숫자가 있는 곳에 베팅을 아웃은 숫자 덩어리에 (홀짝 같은) 베팅을 하는 것이었다. 인, 아웃은 각각 최소 베팅 금액이 10불이었다. 인에서는 10불을 나눠서 여러개의 숫자에 걸 수 있고, 아웃은 무조건 한 칸에 10불 이상을 걸어야 했다. 이게 룰의 전부였다. 물론 걸쳐서 놓는 것들도 있었는데 그런 고급 베팅을 사용하지는 않았다. 다 초보였기 때문이다.

크게 JYM의 전략은 세가지로 나뉘었다. J는 매턴 10불울 두개씩 쪼개어 다섯 군데의 개별 숫자에 걸었다. 이렇게 하다 하나가 걸리면 35배를 받게 된다. 즉 5군데 중에 한 곳이 맞으면 72불을 받게 된다. 10불얼 베팅했으니 이득이 62불이 된다. 베팅에 실패하면 10불을 잃는다. 가능성은 룰렛 숫자가 38개라 5/38이다. Y는 어제 본 사람과 유사한 전략을 택했다. 아웃의 세 덩어리로 나뉜 지점의 두 곳에 10불씩 베팅을 하는 것이다. 이렇게 해서 한 곳이 걸리면 3배인 30분을 준다. 베팅하지 않은 곳이 걸리면 20불을 잃는다. 당첨 확률은 24/38이다. M은 무작위 전략을 썼다. 홀짝에도 걸었다가, 검빨에도 걸었다가 개별 숫자에도 걸었다.

생각보다 그 과정은 단순했다. Y는 처음에는 20불씩 거는 것에 약간 긴장했으나 몇 턴이 지나서는 더이상 돈을 의식하지 않았다. 그저 장난감 칩을 가지고 논다는 생각이었다. 의외로 J가 잘 맞춘다. M은 어떻게 맞추냐며 부러워한다. 그의 칩이 가장 빠른 속도로 사라졌기 때문이다. Y의 베팅은 큰 이득도 없지만 큰 손해도 없는 그런 전략이었다. Y는 대체로 차곡차곡 경기를 했고 이득이 생겼을 때 개별 숫자에 베팅해 칩을 불렸다. 그렇게 한시간 넘게 게임을 했고 Y는 150불 가량을 땄고, J와 M은 잃었다. 결국 카지노는 Y가 딴 돈보다 더 따서 손해는 아니었다. 다 아는 사실이지만 결국은 모두 카지노가 딴다. 룰렛의 경우 0과 00 때문에 대체로 많은 베팅이 카지노에게 유리하게 세팅돼 있다.

미국 시간 2017.01.06 20:00 pm - 2017.01.07 03:00 am

Figure 4. 저녁을 먹은 야드 하우스 입구

K가 라인을 보내왔다. 배고프다고 밥 먹자는 이야기였다. JYM 모두 약간 아쉬워 하는 분위기였지만 늦지 않게 나왔다. 나와서 KTS가 있는 곳으로 왔더니 식당 앞에서 대기하고 있었다. JYM은 괜히 일찍 나왔다는 생각을 한다. 몇 판 더 할껄. Y는 그래서 도박이 무섭다고 느낀다. 사람은 의외로 쉽게 중독된다. 저녁은 야드 하우스라는 체인점에서 먹었다. 에일 맥주가 다양하게 있는 집이었다. KT가 주문을 했는데 많이 와 본 사람들 답게 일반적으로 좋아하는 메뉴로 식탁을 가득 채웠다. 배고픈 일행은 허겁지겁 먹기 시작한다. 그렇게 30분 가량 먹고 나니 이제는 모두 배가 불러 더이상 못먹는 상태가 되었다. 하지만 남은 음식은 아직도 많다. 화제 거리가 떨어질 무렵 티비 켜진 농구경기에 모두 집중했다. 멤피스와 다른 곳이 하고 있는 경기였는데 10점차가 넘게 나는 경기를 멤피스가 역전했다. 몇초 남지 않은 사이에 승부가 바뀌는 경기라 보고 있으면 짜릿한 맛이 있었다. K가 오늘은 타이밍이 좋은 것 같다는 이야기를 한다.

Figure 5. 야드 하우스의 시그니처 하프 야드 맥주, 길이가 하프 야드다.

밥먹고 나오니 모두 배가 불렀다. 뭘하지라고 잠시 고민하던 시점에 J와 M이 룰렛을 하자는 이야기를 한다. K는 처음에는 내키지 않는 분위기 였으나 이내 따라 나선다. 구경을 하다 테이블이 없어서 카지노를 나가려던 즈음 빈 테이블이 하나 생겼다. 그게 시작이었다. JMK가 앉아서 플레이를 하고, YTS는 구경하다 방해될까봐 여기저기를 돌아다녔다. 앉을 때가 없어 카지노 안에 있는 이상한 펍 같은 곳을 들어갔다. 음악이 나오고 춤추는 사람도 더러 있었다. 자리는 많이 비어 있었다. Y는 음악이 너무 시끄러웠다. 그리고 T와 S가 자신이 없는게 더 편할거라는 생각을 했다. Y는 괜히 방해꾼이 된듯한 느낌이다. 그저 기다리고 있어야 하는 그들이 안스럽기도 했다. 그래서 JMK가 플레이하는 곳에 가서 TS가 놀다 오겠다는 이야기를 전한다. K는 그러라고 한다. Y는 라인으로 T에게 그렇게 전한다. 그리고 Y도 그 룰렛 판에 앉는다. 이미 JMK 모두 상당량을 잃은 상태였다. Y는 100불을 교환하고 아까와 같은 전략으로 플레이를 한다. 하지만 이번엔 광속으로 모두 잃는다. 다시 100불을 교환한다. 조금씩 따기 시작했다. 그즈음 100불 칩은 옆으로 분리해서 두고 딴 칩으로만 플레이를 한다.

한참 시간이 지났다. T와 S가 왔다. 기다리다 지친 분위기다. K와 J가 T와 S에게 같이 하라며 100불씩을 준다. 각자 그걸 칩으로 바꿔서 참가한다. Y는 아직도 기계적으로 베팅하며 잃었다 땄다를 반복한다. 그즈음 M은 약간 잃었고, J는 제법 잃었고, K는 더 잃었다가 다시 따는 중이었다. T와 S가 칩을 바꿔 베팅을 시작한다. T가 처음 몇 판을 크게 딴다. Y는 옆에서 땄을 때 잃어나는게 용자라는 말을 전한다. 그는 아직도 본전을 힘겹게 되찾고 있는 중이었다. S는 광속으로 칩을 잃었다. J, M, S는 추가로 칩을 더 바꾸었다. 그렇게 하기를 한참. T가 칩을 캐시로 바꾼다. 별로 남지 않아서 Y가 아까 바꾸면 용자였다고 이야기를 하자 손에 비싼 칩을 보이며 그래도 조금 땄다는 이야기를 한다. 그즈음 K는 제법 크게 따고 있었다. S는 칩을 거의 다 잃어갈 무렵 Y를 따라 베팅하기 시작했다. M은 여전히 무작위로 베팅했다. 칩이 덜 줄어들기 위해서 그는 베팅을 잘 하지 않고 구경하는 판이 많았다. 조금 있다 J도 칩을 모두 잃고 일어났다. S가 그 뒤를 이었다. K, Y, M이 남았다. Y는 거의 본전을 찾아가고 있었다. Y가 본전이 되었을 때 K가 기다리는 사람도 지치니 5판만 하고 가자고 했다. Y는 사실 그때 멈추고 싶었지만 그러기도 쉽지 않았다. 그즘 M은 Y를 따라 베팅해야 겠다는 이야기를 한다. 그렇게 마지막 5판이 시작된다. M은 Y를 따라 베팅하다 달아 세번을 잃는다. 그는 크게 베팅했기에 손실이 훨씬 컸다. 그러다 Y가 딴 네번째 판에 같이 땄고 그는 크게 걸어서 크게 딴다는 이야기를 했다. 하지만 그건 옳은 이야기는 아니었다. 그가 3판에 잃은 칩은 120불이었고, 그가 4번째 판에 딴 칩은 60불이었기 때문이다. 그는 결국 60불을 잃은 것이었다. 마지막 5판 Y는 손실을 줄이기 위해 개별 칩에 10불만 베팅했다.

칩을 정산해서 나왔다. 그때가 벌써 새벽 3시였다. K는 250불을 땄고, Y는 150불을 땄다가 50불을 잃어서 100불을 땄고, T는 50불을 땄다. 하지만 나머지 세 사람이 카지노에서 잃은 돈은 그보다는 훨씬 많았다. 결국은 당연하게도 하우스가 이기는 게임이다. 즐기러 간 자리였지만 즐기는 비용은 그리 싸진 않았다. 아무렇게나 플레이한다면 정말 10분만에 100불을 잃은 것은 아무것도 아니었다. 하지만 K는 반대로 자신감이 붙었다. 한 번 해서 이겼기 때문이다. 돈을 걸고 한다는 것이 묘한 흡입력이 있었다.

집에 도착해서 T와 S는 광속으로 셧다운 되었고, K와 J가 담배피는 사이 Y는 옷을 갈아 입었다. 출출하던 그는 K와 J에게 라면을 먹겠냐고 물었고 K는 콜을, J는 다이를 했다. 공교롭게도 남은 라면은 너구리 컵라면 하나에 끓이는 참깨라면과 신라면이 하나씩 있었다. K는 참깨와 신라면을 섞어서 끓이자고 했다. 섞어서 끓이고 남은 계란까지 모두 넣었다. 햇반 두개에, 김 하나, 참치 하나까지 그 새벽에 Y와 K는 그걸 나눠먹고는 잠들었다.

[일상] CES 2017 DAY #2

Wed, 04 Jan 2017 12:20:01 GMT

미국 시간 2017.01.05 08:00 am - 2017.01.05 21:00 pm

잠에서 가장 먼저 깬 것은 S였다. 전날 다른 일행들이 8시 즈음 일어나서 준비를 하자는 얘기를 곧이 곧대로 믿었기 때문이다. 심지어 더욱 놀라운 사실은 그녀는 다른 사람들이 일어나지도 않았는데 아침으로 라면을 준비했다는 점이다. 안타깝게도 그녀를 제외한 다른 사람들은 모두 꿈나라를 헤매고 있었기에 그 라면은 변기가 모두 먹어치웠다. 그녀는 단톡방에 푹 주무시라는 이야기를 올리고는 본인도 다시 잠을 청했다.

Y가 잠에서 깬 시간은 9시였다. 화장실을 갔다와서 S의 메시지를 본 Y는 다시 잠에 들었다. 일행이 실제로 일어난 시간은 10시가 지났을 무렵이었다. 아침을 먹을지를 잠시 고민하다 K가 배고픈 사람이 없으면 그냥 커피나 먹자는 이야기를 했다. 자연스럽게 근처 스타벅스로 이동했다. K가 앱으로 주문을 받았다. Y가 먼저 아메리카노를 불렀고, J도 그걸 먹겠다고 했고, T도 동참했다. S는 라떼를 선택했다. K는 라떼가 어느 메뉴에 있냐며 운전 중이던 T에게 물었고 T는 몇 가지 추측성 답을 했다. 어렵게 메뉴를 찾은 K는 라떼를 시키고 본인의 아메리카노도 추가했다. 하지만 안타깝게도 주문은 큰 의미가 없었다. 왜냐하면 우리가 간 스타벅스는 드라이브 스루가 있었기 때문이다. 결국 앱 주문은 무시하고 드라이브 스루로 주문했다. 최종적으로 T가 주문한 메뉴는 아메리카노 셋, 라떼 둘이었다. T의 속마음을 조금 알 수 있는 대목이다.

T가 원래 베가스는 주차가 무료였는데 최근 변경되어서 MGM 계열은 주차료를 받는다는 이야기를 한다. 그래서 MGM계열이 아닌 플라밍고 주차장에 차를 세우고 모노레일을 타자고 K에게 묻는다. K는 그러라고 한다. 주차장에 차를 세우고 모노레일을 타러 가는 사이 잠시 길을 헤맸다. T가 호텔 가드에게 물어서 정확한 방향을 알아낸다. 모노레일에 도착해 일행 모두 2일치 모노레일 프리패스를 끊었다. 베가스 모노레일 정거장은 몇 개 없었다. 그들은 2정거장 다음에 있는 컨벤션 센터역으로 향했다.

Figure 1. CES 2017 입구, 사람 진짜 많음

센터에 내려서 CES 입구에서 담배를 피우며 서 있었다. J가 CES에 참관한다는 이야기를 듣고 미국에 있던 M도 합류하겠다고 했기 때문이다. 둘은 CES 입구에서 보기로 했다. M이 도착하지 않아 J의 일행은 적지 않은 시간을 입구에서 보냈다. 한참 후에 M이 도착했고 일행은 모두 M과 인사했다. J를 제외한 모든 사람이 M을 처음 보는 자리였다. Y는 J에게서 M 이야기를 여러번 들었지만 실제로 만나는 것은 이번이 처음이었다.

CES 입구에서는 표와 짐을 검사하고 있었다. 총기 소지가 자유로는 미국은 대부분의 전시회 입구에서 가방 검사를 한다. 폭탄이나 총같은 것들이 있는지 체크하는 것 같다. 하지만 대체로 형식적인 검사다. 가방 검사를 하던 사이 Y는 잠시 일행과 떨어졌다. 다른 일행은 모두 먼저 검사하고 입구에 들어간 상태였고 Y는 늦게 들어갔다. 약간 헤대마 일행이 모여있는 곳이 합류했다. 그쪽 입구에 가장 먼저 위치한 것은 LG 부스였다. LG 부스인만큼 사람이 정말 많았다. 자연스럽게 일행은 둘로 쪼개졌다. K와 T는 K의 관심사가 있는 곳으로 같이 이동했고, J, M, Y, S는 붙어서 LG관 구경을 시작했다.

사람이 너무 많아서 제대로 볼 수 없었다. 사람들이 TV 앞에서 연신 사진을 찍고 있었다. 베스트 오브 베스트에 선정된 그 초박형 TV였다. 어찌나 얇은지 아크릴판에 붙여 놓았는데 진짜 거짓말 좀 많이 보태서 껌딱지 두께 수준이었다. S가 대단한 것을 발견한 것처럼 소리친다. 와 이거 진짜 얇아요. 정말 소리칠만큼 얇았다.

Figure 2. 우리가 낚인 보쉬 솜사탕 로봇. 솜사탕 만들어서 사람들에게 준다.

그렇게 JYMS 일행은 노스관가 센터관을 쭉 훓어 보기 시작했다. 삼성 부스도 구경을 했다. J는 작년에 왔었기에 올해도 LG가 이긴 거 같다는 이야기를 했다. 일행이 가장 많은 시간을 보낸 곳은 어처구니 없게도 보쉬의 로봇이 있는 코너였다. 가정용 로봇은 아니고 산업용 로봇이었다. 보쉬의 전략에 낚인 것일 수도 있었다. 처음 그들이 본 로봇은 솜사탕을 만들어 주고 있었다. 솜사탕이 나온다는게 신기해서 쳐다보다 로봇이 만든다는 것에 더 놀라웠다. 그러고 이동을 하려고 했으나 마지막 즈음에 주문을 받아서 커피를 타주는 로봇에 재차 낚였다. 거기서 가장 많은 시간을 보냈다. S는 직접 주문을 하기도 했다. 주문하는 곳에 이름을 적고 완료 버튼을 누르면 로봇이 컵을 가져와 서 프린터 앞에서 주문자가 쓴 이름을 프린트하고 커피 머신의 커피가 내려오는 곳에 놓았다. 그리고는 머신으로 커피가 내려오도록 한 다음 다 내려오면 그 컵을 옆에 있는 완료 지점에 위치 시켰다. 그러면 사람이 그 컵을 다시 구경꾼이 있는 테이블위이 올려주면 주문한 사람이 찾아가는 그런 구조였다. 그 산업용 로봇의 핵심 기능 중에 하나로 보쉬는 인간과의 자연스러운 협업이 가능하다는 것을 강조 했기에 사람을 억지로 끼워 넣은 것처럼 보였다. 실상 그 로봇은 사람 없이도 주문자가 있는 테이블에 컵을 가져다 놓을 수 있었기 때문이다. 대체로 그러하듯 JYMS 일행은 모두 일자리가 없어지는 우울한 미래를 상상했다. 우리는 무엇을 해야 할까? 우리의 아이들은 어떤 세상에 살게 될까, 라는 생각을 하면서 나머지 것들을 구경했다.

그렇게 JYMS 일행은 노스와 센터에 있는 부스를 모두 구경했다. 밖에서 담배를 피우며 버스 정류장에 잠시 앉았다. KT 일행이 어디에 있는지 몰랐기 때문이다. 라인을 보낸다. KT는 벌써 사우스 관이라고 했다. J는 그것도 오늘 보면 내일은 할 것이 없기에 내일 사우스 관을 보자고 했다. YMS도 그러자고 한다. JYMS 일행이 정류장에 앉아서 각자 핸드폰을 하면서 기다리길 한참. KT 일행이 도착했다. 이후 모두 모노레일을 타러 이동했다. M이 표가 없었기에 M이 표 끊기를 기다려 모노레일을 탔다.

Figure 3. 쉑쉑 버거 입구. 뉴욕꺼라고 뉴욕뉴욕에 있다.

베가스가 처음이 Y와 S를 위해서 메인 스트리트 구경을 하기로 했다. 아침을 먹지 않아 출출한 일행은 점심으로 쉑쉑 버거를 먹기로 했다. MGM 역에서 내려 뉴욕뉴욕으로 걸어갔다. 가는 중간 중간 베가스에 관한 것들이 나오면 K가 설명을 해줬다. MGM의 카지노를 지날 때 J가 사람이 별로 없다는 이야기를 한다. M은 그것도 분위기가 있는 것 같다고 오래된 곳보다는 새로운 곳으로 많이 가서 그런 것 같다는 답변을 한다. 그렇게 이런 저런 이야기를 하며 쉑쉑버거 앞까지 걸어갔다.

Figure 4. 우리가 주문한 버거. 쫀득한게 맛있었다.

T가 주문을 받았다. 잘 몰라서 모두 K가 추천해 주는 메뉴로 통일해서 먹는다. M이 음료로 스트로베리 쉐이크를 시킨다. 그걸 들은 다른 사람도 콜라가 아닌 쉐이크를 시키자 T가 걱정하며 말린다. 엄청 달아서 별로 입에 안 맞을 수 있으니 하나씩 시켜 맛만 보라는 이야기였다. 그렇게 하기로 했다. 이후 메뉴가 나왔을 때 Y는 감탄했다. T가 정말 대단하다는 생각이 들었기 때문이다. 스트로베리는 지나치게 달았다. 한모금 이상 마시기가 어려웠다. T와 같은 잔을 먹는 K도 마찬가지였다. K는 미국 애들은 여기 감자튀김을 찍어 먹는다고 그렇게 먹자고 했다. 그렇게 먹어도 달았다. 결국 Y와 K는 쉐이크를 거의 다 버렸다.

쉑쉑버거를 먹으면서 어쩌다가 M이 세금 이야기를 꺼냈고 대체로 K와 Y는 관심이 많은 주제였기에 집중해서 이야기가 이어졌다. K는 한국 회사에 근무하지만 미국에서 일하는 관계로 세금을 두 군데에 모두 내고 있다고 한다. 조세 협정이 맺어져서 미국에는 한국에 낸 세금을 제하고 나머지 세금만 낸다고 한다. M이 꺼낸 이야기는 양도 소득세에 대한 근로 소득세 이중 과세에 관한 이야기다. K는 그건 이치에 합당하지 않다는 말을 한다. 왜냐하면 이중 과세가 되기 때문이란다. M은 배당도 똑같이 이중 과세라며 국세청에서 관리하는 리스트에 올라가면 일단 세금을 물리고 그걸 나중에 개인에게 소명하라고 이야기 한다는 말을 한다. 실제로 자기 친구가 그렇게 당했다는 이야기를 붙인다. K 또한 다른 이유로 국세청에 가서 소명한 적은 있지만 지금까지 양도세와 근소세의 이중 과세를 당해서 간 적은 없다고 주장한다. 중간 중간에 최대 주주 및 비상장 법인에 대한 양도세 강화 등이 나왔고 Y는 네이버에 그런 것들을 찾아본다. K가 결과가 어떻게 되었냐고 Y에게 묻는다. Y는 K 말도 일부 맞고 M 말도 일부 맞는 것 같다는 답을 한다. 이중 과세 부분은 K의 말이 맞았고, 최대 주주 및 양도세 강화와 관련된 주장은 M의 말이 맞았다. S와 T는 딴나라 이야기를 듣는 듯한 표정이다.

K는 세금을 지나치게 걷는 것은 나쁘다는 주장을 피력한다. 그러면 누가 사업을 하겠냐는 이야기다. 상당수 비상장 법인에 대한 투자 및 인수 합병에 세금이 많은 걸림돌이 된다는 이야기를 붙인다. 요는 세금이 투자 및 인수 비용을 상향 시키는 역할을 하기 때문에 일정 크기가 넘어가면 투자자와 피투자자 인수자와 피인수자 상호 간에 딜을 방해하는 허들 작용을 한다는 것이었다. Y는 그런 경험은 없었지만 K의 말도 일리 있다는 생각을 한다. 그러면서 또 한편으로는 모두가 각자의 입장에 맞는 주장을 한다는 생각을 해본다. 서는 데가 달라지면 풍경도 달라진다는 말처럼 말이다.

쉑쉑버거는 맛있었다. 치즈는 쫀득쫀득했고, 패티는 부드러웠다. 굉장히 단촐한 햄버거인데 맛있었다. Y에게 약간 느끼하긴 했지만 버거가 크기 않아 부담스럽지는 않았다. 쉑쉑 버거를 처음 먹어보는 J와 S도 대체로 맛에 만족했다.

M이 아리아 호텔에 아마존 부스가 있다는 이야기를 해서 일행은 그쪽 부스를 구경하러 아리아 호텔로 출발했다. 쉑쉑 버거에 들어갈때는 환했지만 나올 때는 약간씩 해가 지고 있었다. 보안 검사를 마치고 아마존 부스를 찾아 갔다. 하지만 거기엔 일행이 기대한 것은 없었다. B2B 관이었기 때문이다. 전시는 거의 없었고 B2B 룸만 잔뜩 있었다. 실망한 일행은 호텔을 나왔다. 드디어 밤이 됐다. 당연한 이야기지만 베가스는 이제 시작이었다. 낮보다 밤이 훨씬 화려했다.

Figure 5. 벨라지오 호텔. 이 거대한 분수에서 분수쇼가 펼쳐지려 했으나 바람 관계상 ㅠㅜ~

일행은 벨라지오 호텔에서 하는 분수쇼를 보러 출발했다. 가는 길에 있는 메인스트리트에 대한 설명을 K가 해주었다. Y는 이제야 베가스에 온 것 같은 느낌이 들었다. 영화나 드라마에 등장하는 그 베가스가 이제야 나타났기 때문이다. 일행이 벨라지오 앞에 도착한 것은 분수쇼를 하기 15분쯤 전이이었다. 정각이 되면 분수쇼가 시작될 예정이었다. 바람이 많이 불고 날씨는 쌀쌀했지만 멋진 분수가 나타나길 일행은 기다렸다. 그사이 다스베이더가 나타났고 S는 그와 사진을 찍었다. 그리곤 1달러를 그에게 건냈다. 사진은 광속으로 찍었지만 가방에서 돈을 찾지 못해 다스베이더가 한참을 기다렸다. 급기야 헬맷을 벗기까지, Y가 대신 주러 다가갈 즈음 S는 가방에서 돈을 찾아서 그에게 주었다.

정각이 다 되갈 즈음 레이디스 앤 젠틀맨이라며 방송이 나왔다. J는 자연스레 이제 시작하는 것 같다는 이야기를 했고, Y도 그런 것 같다고 했다. 사실 방송 내용은 너무 작았고 잘 들리진 않았다. 하지만 정각이 지나도 분수는 없었다. 일행은 포풍 검색을 했고, S가 바람 불면 안 하는 것 같다는 얘기를 했다. 5분 정도 더 기다려도 분수가 나오지 않아 일행은 포기하고 베가스 메인 스트리트를 걷기 시작했다. 우리의 구글 역할을 한 T가 화장실을 가고 없었다. 나중에 T가 전화를 해서 확인을 했는데 바람이 불어 취소된 것이 맞다고 했다.

베가스의 호텔은 모두 각각의 특징이 있다. 파리를 테마로 한 호텔, 뉴욕을 테마로 한 호텔, 베니스를 테마로 한 호텔 같은 식이다. 괜찮은 생각 같았다. 한참을 길을 걸으며 내려갈 때 J가 허름한 숙소 한 곳을 가르키며 저기 2001년에 놀러왔었다는 이야기를 했다. 그때와 지금 많은 것들이 달라졌지만 그 숙소는 여전히 그 자리에 그대로 있었다. J는 아련한 생각에 잠시 빠진다.

Figure 6. 베네치안 호텔. 밖은 밤이지만 여긴 하늘이 별도 구현되어 있다. 곤돌라까지, 서프라이즈.

그렇게 구경을 하면서 하염없이 걷는다. T는 한국 사람들이 베가스를 처음 오면 명동이랑 비슷하다는 말을 했다는 이야기를 한다. Y는 속으로 명동이라기엔 사람이 너무 없는데 라는 생각을 했다. 하지만 코너를 돌자 그 생각은 없어졌다. 사람들이 물밀듯이 쏟아졌기 때문이다. 일행이 미자막으로 도착한 곳은 베네치안 호텔이었다. 앞서도 말한 것과 같이 그곳은 베니스를 옮겨둔 곳이었다. Y는 처음 들어갈 때 깜짝 놀랐다. 왜냐하면 깜깜한 밤길을 걷다가 실내로 들어갔는데 갑자기 대낮이 되었기 때문이다. 대낮이 환하다는 의미가 아니라 그냥 아침이 된듯한 느낌이었다. 나중에 안 사실이지만 천정에다 하늘 그림을 자연스럽게 그린 다음 불을 켜 두어서 그런 착시를 일으키는 것이었다. Y는 정말 신박하다는 생각을 한다. 물길이 있고 곤돌라가 있다. 진짜 베니스라는 생각이 절로 든다.

너무 걸어서 모두가 피곤했다. 모두 앉을 곳을 찾았지만 마땅치 않았다. 그러다 T가 푸드코트 같은 곳을 발견했고 음료수를 시켜 모두가 앉았다. 바로 옆이 카지노였다. 이후 일정에 대한 이런 저런 이야기를 한다. 어디를 갈거냐 이곳 저곳 전화를 해서 예약이 되는지를 묻는다. 당첨된 곳은 일식집이었다. 21시에 예약이 된다고 했다. 아직 두시간 가량 남은 시간이다. 피곤했지만 또 심심하기도 했다. J는 카지노에서 시간을 떼우다 가자는 이야기를 한다. 일행은 그러기로 한다. 하지만 K는 탐탁지 않아 하는 분위기다. 결국 K와 S는 밖으로 나가 바람을 쏘이기로 하고 T는 플라밍고에서 차를 찾아서 이쪽 호텔 입구로 가져오기로 한다. JYM만 남아서 카지노를 구경한다. 이곳저곳 구경을 하는데 대부분 싸지 않다. 블랙잭은 대체로 25불씩이다. 섣불리 하기엔 비싼 금액. 1불짜리 슬롯머신을 J가 잠깐 했지만 진짜 금방 끝이 난다. JYM은 룰렛 옆에서 다른 사람들이 하는 것을 구경한다. 사실 JYM 모두 대체로 처음이라 카지노를 아는 사람이 없다. 그래도 룰렛은 워낙 간단해서 옆에서 보자 대체로 룰이 이해가 된다. 구경하는 테이블은 혼자서 플레이 하고 있었는데 Y가 보기에 그 전략은 수학적으로 상당히 합당한 전략 같아 보였다. 플레이어는 따기도 하고 잃기도 했지만 혼자서 오랜 시간 플레이를 하고 있었다.

카지노를 구경하니 시간은 금방 간다. 결국 JYM은 그날 카지노를 하지는 못하고 구경만 하다 밖으로 나간다. S가 했냐고 묻는다. Y는 케이스 스터디를 하고 왔다고 너스레를 떤다. K는 호텔 입구에서 큰 기업 회장으로 보이는 사람이 지나가는 것을 두 번 봤다며 한국의 의전 문제를 이야기 한다. 저런 문화는 좋지 않다고 비판한다. 그러면서 그나마 IT 업계는 그런 것은 덜한 것 같다는 이야기를 덧붙인다. Y는 IT 업계도 실상 조금만 커지면 똑같지 않냐는 반론을 이야기 해본다. M은 오늘 근처에 현대 정의선 부회장이 왔다는 이야기를 들었다는 말을 한다.

미국 시간 2017.01.05 21:00 pm - 2017.01.06 05:00 am

T가 플라밍고에서 차를 가지고 일행이 기다리는 호텔 입구로 오고 있었다. 거의 비슷한 시간에 도착해서 JYM은 많이 기다리지 않고 곧바로 차를 탈 수 있었다. 도착한 곳은 이자카야 분위기의 일식집. 어제 먹었던 A18 보다는 훨씬 좋다. 서빙을 하는 아가씨가 한국말을 참 잘한다. 그런데 옆 테이블에 가서는 또 유창한 일본어로 주문을 받는다. 일행은 서빙 하는 친구가 3개국어를 한다며 여러가지 추측을 쏟아낸다. 결국 물어서 알게 된 사실은 한국 사람이고 근처 간호 학교에 다니고 있다고 한다. 안주도 괜찮았고 술도 나쁘지 않다. 술자리가 길어지기에 금상첨화인 상황.

분위기가 무르익을즈음 M이 핵폭탄 화두를 던진다. 한국의 회사 운영 시스템이 좋지 않다는 것이다. 어쩌다보니 또 어제처럼 M은 공격하고 K는 수비하는 입장이 된다. M의 주된 논지는 한국 회사는 너무 대표 독단으로 운영되는 경우가 많다며 대표를 견제할 시스템이 없는 것이 문제라는 것이다. 특히나 중소 회사의 경우 대표가 최대주주인 경우가 많기 때문에 문제가 더 심각하다고 한다. 하지만 미국 회사의 경우에는 이사회라는 시스템을 통해서 운영되기 때문에 그런 문제가 없다고 한다. K는 다양한 방법으로 자신을 수비한다. 자신은 공정하다, 그렇게 운영하지 않는다는 이야기를 수차례. M이 그냥 돌직구를 날린다. 그래서 그 회사의 대표는 누가 견제할 수 있어요? K의 말문이 막힌다. Y가 대신 대답한다. 없죠.

K는 자신의 회사 사람들은 대표 의견에 반대하는 것이 있으면 직설적으로 말한다는 이야기를 여러차례 근거로 들었다. 그말에 Y가 M을 거든다. 그래도 결국 진짜 중요한 결정은 다 대표님 생각대로 되는 것 아니냐는 대답이다. K도 어쩔 수 없다는 이야기를 한다. M은 그게 문제라며 공격을 이어 간다. 이번엔 반대로 Y가 K를 도와준다. 미국 또한 이사회가 오염되면 똑같다는 이야기였다. 결국은 정치 문제로 귀결된다는 말이다. 이사회가 존재하지만 이상하게 운영되는 미국 회사들의 예는 수도 없이 많다며 콕 찝어 보자면 회사가 적자가 나도 대규모 인센티브를 받는 CEO들을 지적한다. M도 완벽한 시스템은 없다고 시인한다. 하지만 견제 세력이 있는 것과 없는 것은 천지 차이라는 말을 덧붙인다. Y는 소규모의 경우는 합의에 낭비하는 시간 보다는 빠른 결정을 통한 효율 추구가 더 좋을 수도 있다는 이야기로 맞불었다. 실제로 그도 창업 초기에 그런 경험을 했었기 때문이다.

이 이야기는 길게 길게 무럭 무럭 이어졌다. 안주도 좋았고 술도 좋았기 때문이다. T와 S는 많이 힘들어 하는 분위기다. 재밌는 주제도 아니고 그들이 거들 말도 별로 없었기 때문이리라. 2시까지 하는 가게가 거의 마칠 즈음에 그들은 나왔다. T는 다시 운전대를 잡는다. M이 묵고 있는 호텔에 그를 데려다주고 나머지 일행은 에어비앤비로 예약한 집으로 향한다. 집에 도착하니 거의 3시가 다 된 시각. 정말 늦었고 술도 취했다. 하지만 K는 아직 끝이 아니었다. S를 두고 JYKT는 한잔 더 하기 위해 베가스로 우버를 타고 나왔다. K는 진짜 베가스의 밤은 지금부터라며 호기롭게 말했다. 모두가 피곤했지만 K를 말릴수는 없는 노릇이었다. 결국 그들은 베가스의 가장 화려한 곳으로 출동해서 베가스의 밤을 즐겼다. 다시 집에 도착했을 때 시간은 5시였다. Y는 속이 쓰려 컵라면에 햇반을 하나 먹고 잠들었다. 나머지 일행은 광속으로 셧다운 됐다.

[일상] CES 2017 DAY #1

Wed, 04 Jan 2017 12:10:01 GMT

미국 시간 2017.01.04 09:30 am - 2017.01.04 12:00 pm

LA 공항에 도착했다. 베가스행 비행기를 갈아타는데 셋에게 허락된 시간은 한시간 남짓이다. 그마저도 J가 랜덤 체크에 걸리는 바람에 티케팅까지 해야하는 상황. 비행기에서 거의 다섯 손가락에 꼽힐만큼 빨리 내려서는 "Express Connection" 이라고 적힌 종이를 받아들고는 달리기 시작했다. 그나마 급행이라 그런지 입국 심사는 간단하게 넘어갔다. S가 조금 오래 걸렸지만 그래도 일반적인 미국 입국 심사보다는 간소했다. 짐들도 일등석 태그가 붙어 있어서 먼저 나왔다. 대한항공 티켓팅 직원이 환승 시간이 짧다고 발휘한 센스였다. 다시 달리기 시작. 세관 신고도 급행으로 하고 갸방을 다시 베가스행으로 보내고 델타 항공이 있는 게이트로 달리기 시작했다. J와 Y가 앞서고 S는 힘들게 쫓아온다. 델타가 있는 게이트는 5번 달려도 달려도 나오질 않는다. 4번이 무지 길다. Y는 잠시 이거 원래 뛰는게 아니라 교통 수단을 이용하는 것이 아닌가라는 생각을 해봤다. 그즘에 5번 게이트가 나왔다. 셋 모두 잽싸게 올라가서 티켓팅을 했다. 출력하고 다시 검색대 앞. 미국이라 그런지 보안 검사가 까다롭다. Y는 신발을 신고 있다가 지적질을 받았다. 짐을 검색대 안으로 넣지 않는다는 지적을 또 한 번 받는다. Y는 속으로 까탈스럽다는 생각을 한다.

그렇게 검색대를 통과해 이제는 조금 여유롭게 걸어서 게이트 앞에 섰다. 그리고는 긴 줄 끝에 비행기에 올랐다. 셋 모두 안도했다. J는 50분에 이게 가능하네라며 허탈 웃음을 짓는다. 그리곤 이내 J, S, Y 모두 깊은 꿈나라로 빠져든다. 한시간 조금 넘는 비행 시간 동안 셋 모두 기절했다.

미국 시간 2017.01.04 13:00 pm - 2017.01.05 03:30 am

Figure 1. 베가스 공항의 첫 장면, 벌써 카지노 머신들이 즐비하다.

비행기 소리에 Y가 깬다. 그래도 한숨 붙여서 다행이라고 생각한다. 그즈음 비행기가 베가스 공항에 도착했다. Y가 공항에 내린 첫 느낌은 여기가 베가스구나, 라는 생각이었다. 공항에는 벌써 슬롯 머신들이 즐비했다. 웰컴 투 라스베가스라는 푯말을 지나 가방을 찾으러 간다. 가방이 나오는 곳에 도착했을 때 가방은 모두 나와 있는 상태. 가방을 찾자 J가 예매한 CES 티켓을 공항에서 찾아가면 된다며 사람들이 기다리고 있는 줄을 가리킨다. 셋 모두 거기 줄을 섰다. 줄은 길었고, 티켓 발매 직원은 한 명이었다. 시간이 제법 걸렸다. J는 작년은 이렇지 않았다며 올해 사람이 많이 온 것 같다는 얘기를 건낸다. Y와 S는 아직도 어리둥절한 상태라서 그러려니 하고 있다. 한참을 기다려서는 셋 모두 티켓을 받고 공항을 빠져 나왔다. 담배 피는 곳에서 J는 담배를 태우고 Y와 S는 기다린다.

Figure 2. CES 2017 티켓

J가 라인으로 합류하기로 한 다른 일행의 위치를 점검한다. K와 T가 LA에서 베가스로 셋을 마중나오기로 했는데 아직 도착하지 않았기 때문이다. 담배를 달아서 몇 개비를 피웠을 때 K와 T가 도착했다. 그들도 CES 티케팅을 위해 기다려야 했다. 20분 넘게 걸렸다. 밖에서 담배를 피우며 점심으로 무엇을 먹을지를 이야기를 한다. K가 곰탕이 좋다며 이조곰탕으로 가자고 했다. 모두 그러자고 한다. CES 티켓을 끊고 K와 T가 타고온 차를 이용해서 곰탕 집으로 향했다.

Figure 3. 베가스 곰탕 맛집, 이조곰탕

ces 2017 d01 04 Figure 4. 이조곰탕에서의 거한 점심 이조곰탕, 베가스에서 나름 잘하는 집이다. 벌써 주차장은 가득 차고 웨이팅 종이는 모두 써서 더 적을 공간이 없었다. Y가 함께한 일행 보다 먼저 온 일행이 있다. 얘기하는 폼새가 삼성전자 직원 같았다. 그걸 모르고 늦게 온 K가 담배를 태우며 작년 CES와 올해 CES를 예상하며 올해도 LG가 이길 것 같다는 이야기를 한다. 이내 대기하는 사람들이 삼성 직원이라는 것을 알고는 조용해졌다. K의 팀이 늦게 왔지만 삼성 일행은 인원이 훨씬 많아 K팀 일행이 먼저 들어간다. 도가니 셋, 살코기 하나, 섞어 하나를 시킨다. 불고기 안주에 소맥으로 낮술이 시작된다. 그렇게 거하게 먹고는 에어비밴비로 예약한 집으로 이동했다.

Figure 5. 에어비앤비로 예약한 집. 헤니의 그 집이랑 흡사하다.

집에 짐을 풀고 잠시 집 구경을 했다. 다니엘 헤니가 사는 그런 일반적인 미국 집이다. 이층 집으로 방이 5개, 화장실 3개, 뒷마당에 수영장이 있는 그런 집. 대충 집의 상태가 파악될즈음 T와 S는 생필품을 사러 마트에 갔다. 출장 막내의 삶은 그렇게 피곤하다. Y는 그사이 배정받은 방에서 쓰러졌다. 한시간쯤 잤을까? 북적거리는 소리에 Y가 잠을 깨고는 내려간다. K가 새로산 블루투스 오디오를 자랑한다. 삼성이 인수한 하만카돈의 제품이라며 저렇게 조그마한 스피커에서 이렇게 웅장한 소리가 난다고 너스레를 떤다. Y가 생각해도 소리가 빵빵하긴 했다. 잠시 음악을 들으며 마트에서 사온 짐 정리를 대충 마칠때쯤 우버X를 불러서 저녁을 먹으로 출동했다.

Figure 6. 첫 저녁 A18, 절대 피하길…

T가 찾은 집은 A18이라는 치킨 집이었다. A18을 보는 순간 T를 제외한 모든 사람은 웃기다는 생각을 했다. T는 18이 에이틴으로 보이는 영어가 더 편한 교포였기 때문에 솔직히 무슨 말들을 하는지 잘 이해할 수 없었다. 잠시 바람을 쏘이고 가게로 올라갔다. 치맥으로 시작한다. 시키는 메뉴마다 양은 어마어마 했다. 하지만 맛은 그닥이었다. 한국식 영계 치킨에 익숙한 이들에게 다자란 노계로 만든 듯한 치킨은 살이 퍽퍽하고 맛이 별로였다. T도 그런 표정이다. 그나마 그 사이 섞여있는 감자 튀김이 제일 괜찮은 것 같다는 이야기를 한다. 안타깝게도 맥주 또한 별로였다. 김빠진 맥주는 정말이지 그들을 좌절시키기에 충분했다. 이것저것 바꿔가며 시켜봤지만 모든 맥주가 맛이 형편 없었다. 화제는 S의 연애사였다. 유부남 셋이서 S의 연애사에 관한 이야기를 한마디씩 거드니 이야기가 끝이없이 이어진다. Y는 속으로 남녀의 차이는 정말이지 시대와 나이와 성별과 인종을 막론하고 통하는 주제라는 생각을 했다. 한참 이야기를 하고 있을 무렵 J가 라인으로 연락하던 B가 합류했다. 혼자가 아이었다. G가 함께왔다.

G는 나름 업계에서 유명한 사람이기에 Y는 신기하다는 생각을 했다. 비유를 들자면 술집에서 맥주를 마시고 있는데 연예인이 온 것과 비슷한 상황. Y는 G에 관한 웃지 못할 에피소드를 하나 들어서 알고 있었고, 과거 술자리 안주로 그 이야기를 많이 했었다. 그래서 그런지 G가 어떤 사람인지 더욱 궁금했다. 그런데 G는 Y가 생각한 것과는 다소 상반된 사람이었다. 그리고 생각보다 재미난 사람이었다.

베가스 답게 G가 처음 한 얘기는 겜블링이었다. 안타깝게도 G와 B를 제외한 나머지 사람들인 Y의 일행 중에는 도박을 하는 사람이 없었다. 대체로 명절 고스톱 정도 치는 사람들이었다. K는 심지어 그마저도 하지 않는 사람이었다. 나름 뼈대 있는 집안의 자손인 그는 집안 대대로 내려오는 집안의 룰이 있었기 때문이다. 그 중에 하나가 도박을 하지 말라는 것이었다. 여튼 그렇게 도박에는 하등 관심 없는 사람들을 상대로 G는 구구절절 도박 예찬론을 늘어놨다. G의 논지는 이랬다.

일단 카지노의 슬롯 머신 룰렛 따위는 겜블이 아니다. 그건 그저 돈을 카지노에 가져다 바치는 행위다. 그가 겜블이라고 말하는 것은 포커와 블랙잭이었다. 일종의 마인드 스포츠로써 어느 정도 실력에 따라 승부가 결정되는 게임이라고 그는 주장했다. 그러면서 특히 포커에 대해서 많은 이야기를 했다. 그는 기업가는 반드시 겜블링을 해야 하는데 그 이유는 흥망성쇠를 간접적으로 짧은 시간에 느낄 수 있기 때문이라고 했다. 그가 포커를 하면서 배운 가장 큰 교훈은 상황이 좋지 않을 때 견디는 방법, 또 상황이 좋을 때 자만하지 않는 법이라고 했다. 그리고 특히나 포커를 하면서 한없이 패가 계속 좋지 않아서 하염없이 돈을 잃으면서 이 상황이 언제 끝날까, 라는 생각을 하며 게임을 할 때. 그때 그는 가장 많이 배웠다고 했다. 그 상황을 견뎌 내는 것이 사업에서 좋지 않은 상황이 계속 이어질 때 견뎌내는 것과 같다는 지론이었다. 그러면서 우리에게 꼭 겜블을 해볼 것을 권했다.

겜블 이야기 다음은 연예인 이야기가 이어졌다. Y가 바라본 G는 정말 신기한 사람이었다. 그렇게 바쁘고 시간이 없을 것 같은 사람이 알고 봤더니 아이돌 전문가였기 때문이었다. 뒤쪽 스크린에 나오는 아이돌의 이름을 줄줄이 꿰고 있었다. 정말이지 신기했다. 그리고 드라마 이야기가 이어졌다. 역시 줄줄꿰고 있는 G. 그 자리에 있던 어린 친구들보다 훨씬 더 많은 연예인 정보를 알고 있었다.

그렇게 이어지던 가십 이야기가 끝나고 CES 이야기가 나왔다. 그러다 VR 이야기가 테이블에 올라왔다. G는 요즘 사업들이 모두 초거대기업들의 문샷 배틀을 제외하고는 돈이 될만한 사업 아이템이 없다는 이야기를 했다. 그러면서 VR 또한 그런 것 중에 하나라는 이야기를 한다. K는 반대다. 그는 VR에 기회가 있을 거라는 입장이었다. G는 아직 기술이 덜 무르익었다는 생각이고, K는 지금부터 준비해야 하는 입장. G의 집요한 공격이 이어졌다. 그래서 뭐할거냐? 특정 분야를 제외하고 VR이 의미 있는 경우를 설명해 보라. 그래서 지금 사업에서 VR 쪽에 어느 정도 비율로 투자하고 있는가? G는 면접관이자 심판이었고, K는 면접자이자 플레이어였다. 하지만 K도 말빨로 어디가서 딸리는 사람은 아니기에 그렇게 이어지는 공격을 주구장창 막아냈다. 이야기가 길어지고 있었다.

그들이 담배 피러 나간 사이 대화에 끼지 못하고 듣고 있던 S와 T와 Y는 잠시 서로 대화를 나눌 수 있었다. 셋의 마음은 똑같았다. 언제 끝날까? 우리는 언제쯤 침대에 누울 수 있을까? K를 다년간 수행한 T가 예언을 했다. 우리가 오늘 잘 시간은 3시라는 예언이었다. S는 소스라쳤고, Y는 정확하다는 생각을 했다.

VR에 대한 열띤 토론이 끝나고 잠시 최순실 박근혜 얘기가 나올 즈음 1차가 끝이났다. 많이 아쉬워하는 G를 뒤로한체 J의 일행은 다시 집으로 돌아왔다.

Figure 7. 뒷마당에서의 술자리, 불이 있어 몽환적인 분위기. 애어비앤비 집의 유일한 장점이었다.

도착한 K는 뒷마당에 있는 파이어 스테이션에 불을 붙이고 블루투스 스피커로 노래를 틀었다. 하지만 그의 핸드폰 인터넷이 불안정했다. 결국 S의 로밍 인터넷으로 음악을 들었다. 그의 취향에 적합한 거미의 목소리가 백야드에 울려퍼졌다. 불이 있고, 술이 있고, 음악이 있는 약간 몽환적인 분위기의 술자리가 이어졌다. 심지어 의자도 제법 편했다. 그렇게 일행은 거미의 노래가 수도 없이 이어져서 결국은 도저히 알 수 없는 거미의 노래가 나올때까지 맥주를 마셨다. 그리고는 라면으로 지친 속을 달래고 각자 방으로 갔다. Y는 방에 누워 시계를 보았다. T의 예언은 정확했다. 침대에 누운 그 시간이 새벽 3시 30분이었기 때문이다.

[일상] CES 2017 DAY #0

Wed, 04 Jan 2017 12:00:01 GMT

내가 본 것들, 경험한 것에 대한 기억을 보존하기 위해서 이 기행을 남긴다.

한국시간 2017.01.04 12:00 - 15:00 pm

그들이 탈 비행기는 LA행 3시 출발 대한항공 KE0017편이다. A380 기종이다. J와 Y는 11시쯤 회사에서 택시를 타고 출발해 인천 공항에 열두시쯤 도착했다. S는 집에서 바로 공항으로 오기로 했다. J와 Y가 공항에서 10분 남짓 기다리자 S가 왔다. 한국은 영하의 겨울이지만 LA는 봄날씨다. 이런 사실을 잘 알고 있는 J는 공항에서 패딩 점퍼를 간절기의 가벼운 옷차림으로 갈아 입었다. Y와 S에게도 갈아 입을지 물었지만 둘은 괜찮다는 답변을 한다.

J의 트렁크를 다시 정비하고 티켓팅을 하러 갔다. 줄이 길다. 약간 지루해지는 찰나 그들의 차례가 됐다. 티켓팅 중에 사소한 문제가 생겼다. J가 SSSS라는 일명 랜덤 체크에 걸린 것이다. J는 제법 여러차례 미국을 다녔지만 이런 것을 당해보기는 처음이다. Y와 S도 처음 보긴 마찬가지다. 티켓팅을 하는 직원이 친절하게 설명해주면서 난처해 한다. 그도 그럴것이 그들은 LA 공항에서 다시 베가스행 비행기로 갈아타야 하는데 그 시간이 무척 촉박했기 때문이다. Y와 S의 베가스행 티켓은 미리 발권해 주었지만 J는 랜덤 체크라 그러지 못했다. 1시간 남짓한 시간 안에 입국 심사를 마치고 다음 비행기를 타야 하는데 이제는 현지 티켓팅 작업까지 추가된 것이다. 업친데 덮친격. SSSS에 대한 네이버 검색 결과는 그들을 더 멘붕에 빠트리기에 충분했다. 모두가 약간 긴장했다.

J와 Y는 로밍을 하고 보조 배터리를 받았다. J는 필요가 없다며 배터리를 S에게 건낸다. J의 기업인 카드 덕분에 공항의 빠른 검색대를 사용할 수 있었다. 인천 공항의 가장자리에 있는 검색대였다. 기업인 카드를 가진 사람과 그 일행은 해당 검색대를 사용할 수 있다. 공항은 엄청난 인파로 붐볐지만 빠른 검색대는 놀라울만큼 한산했다. 검색대를 지나 J와 Y가 출국 심사대 줄을 선다. S는 자동 심사대로 향했다. 그가 그것을 통과할즈음 J와 Y도 이제 더이상 사전 등록을 하지 않아도 자동 심사대를 쓸 수 있다는 사실을 알게 되었다. 그들도 줄을 떠나 자동 심사대로 빠르게 통과했다.

J가 면세점 쇼핑을 할 것인지를 묻는다. Y, S 모두 그닥 살게 없다는 표정을 짓는다. 칼라운지로 직행한다. Y는 작년 GDC 갈때에도 이곳을 왔다. 작년 보다는 조금 더 사람이 많다고 느꼈다. 셋이 자리를 찾아 헤매다 결국 의자를 돌려서 테이블을 마주보고 앉도록 한 후에 음식을 가지러 간다. Y는 이것 저것 떠와서 먹었지만 음식 품질이 작년보다 덜하다고 느꼈다. 빵들이 지나치게 오래된 느낌이었기 때문이다. 셋다 빵을 조금씩 먹었고, S와 Y는 추가로 컵라면도 하나씩 끓여 먹었다. 정신 없이 오느라 모두 점심을 먹지 못해 배가 고팠다. 대충 끼니를 때우고 J는 담배를 피우고, S는 핸펀을 하고, Y는 노트북을 켜서 메일 확인을 하고 중요한 메일에 회신을 한 통 해주었다. 골치아픈 문제의 답을 알려주는 반가운 메일이었다.

라운지에서의 시간은 금방 간다. 2시 10분 즈음에 내려와서 게이트 앞에 섰다. J는 그사이 담배를 사왔다. 곧이어 탐승한다. 프레스티지란 말이 무색하게 줄이 길었다.. 불행중 다행은 셋다 일찌감치 줄을 섰기에 빠르게 탈 수 있었다는 점이다. 옆에 일등석 손님이 한 명 있다. 평소 Y는 어떤 사람들이 일등석을 타나 궁금했기에 그를 면밀히 살펴본다. 지나칠정도로 너무나 평범한 사람이었다. 정말 평범하다는 생각을 했다. 비행기로 올라타는 길목에서는 J는 정밀 검색을 받으러 갔다. S와 Y는 먼저 탄다.

한국시간 2017.1.4 15:00 pm - 미국시간 2017.1.4 09:00 am

A380는 이층으로 되어있다. 스튜어디스가 Y에게 이층으로 가라고 안내했다. S도 따라간다. Y는 스튜어디스가 안내해 준 11E 자리에 앉았다. 비행기는 뭔가 산만한 분위기다. 스튜어디스가 S와 Y의 외투를 받아서 걸어준다. 이내 J가 도착했다. 걱정했던 것만큼 심각하진 않았던 것 같다. 다들 자리에 앉아 실내화로 갈아 신고 USB를 연결한다. 스튜어디스가 안전 설명을 하는 사이 Y는 잠이 들었다. 어제 먹었던 소주의 숙취 때문인지 피곤했다. 이내 비행기가 이륙한다.

J와 S는 모니터를 꺼내서 둘러본다. Y는 주구장창 볼거라 핸펀을 꺼내서 책을 읽는다. 조금 있다 스튜어디스가 식사 메뉴를 묻는 질문을 한다. Y는 스테이크를 J와 S는 불고기 비빔밥을 선택했다. 프레스티지석의 식사 시간은 지나칠 정도로 장황하다. 스테이크는 이랬다. 전채가 나오고 빵이 나오고 수프가 나오고 와인이 나오고 스테이크가 나오고 치즈. 과자. 과일이 나오고. 이어서 커피와 차가 나왔다. 다 먹는데 거의 꼬박 한 시간이 걸렸다. Y는 시험한다는 생각으로 죄다 달라고 해서 모두 먹어 본다. 치즈가 세 종류가 나왔는데 말랑말랑한 젤 맛있게 생긴 녀석의 반전에 당했다. 말랑한게 달달하게 생겨서는 엄청 역한 맛을 내는 치즈였기 때문이다. 이름이 궁금했지만 물어보진 않았다.

식사가 끝나고 스튜어디스가 물과 세관 신고서를 나눠준다. J와 S가 먼저 작성하고 Y는 S의 펜과 신고서를 받아 베꼈다. 이내 다들 모니터 삼매경이 빠진다. 여기 영화를 죄다 섭렵할즈음 도착하리라, 라고 Y는 생각했다. Y는 "잭 리처"라는 톰 크루즈 주연의 영화를 틀었다. 뻔한 내용의 뻔한 전개지만 재미있다. 그즈음 기내에 불이 꺼진다. 자는 사람도 한둘 보인다.

Y가 보던 영화가 끝났다. 탑승한지 꼬박 다섯 시간이 지난 시점, J와 S는 여전히 모니터 삼매경에 빠져있다. Y는 찌뿌둥한 몸을 좀 풀러 밖으로 나간다. 바가 있는 곳에 드러 눕는다. 세상 편하다고 그는 생각한다. 그 상태로 다시 핸펀 책읽기를 시작한다. 결국 가벼운 책을 완독했다. 난기류가 있으니 안전 벨트를 착용하라는 방송이 나온다. 흔들리지도 않는데 계속 방송은 나오는 상황이었다. Y는 버텨보다가 비행기가 조금 흔들리자 잽싸게 자세를 고쳐 앉아서는 벨트를 맨다.

벨트를 하고 있기를 십여분 좀이 쑤신다. Y는 반대편 끝 칵테일 바가 있는 곳까지 걸어가서 스트레칭을 하고는 자리로 돌아왔다. S가 헤드셋을 빼고 앉아 있다. 영화를 많이 봤냐고 묻자 라면을 시키고 기다리는 중이라는 대답을 한다. Y는 수면 자세로 자리를 조정했다. 조금 있다 S의 라면이 왔다. 냄새가 향기롭다. 아까 비빔밥을 많이 안 먹더니 배가 고팠던 것 같다. 라면도 많이 먹지는 않는 눈치다. Y도 따라 시키려다 속이 좋지 않을 것 같아서 참는다.

Figure 1. 아침으로 나온 기내식 죽

J는 두번째 CES 참관이고, S와 Y는 처음이다. S는 생애 처음 미국을 가보는 것이고, Y는 미국은 가봤지만 베가스는 처음이다. 이래저래 설레는 새해 첫 비행이다. 항상 그렇지만 모든 여행은 그 출발의 설레임이 좋다.

[cpp] VS 2015의 magic statics 구현 세부 사항

Thu, 24 Nov 2016 12:00:01 GMT

최근에 좀 골치 아픈 문제를 겪어서 여기에다 정리해 놓는다. 컴파일러를 업그레이드하면서 알게 된 문제인데 정적 지역 변수의 초기화와 관련이 있었다. 문제의 발단은 이랬다. 컴파일러 업그레이드 후 이상하게 싱글턴 등을 구현하기 위해서 사용된 static 지역 변수 코드가 정상적으로 동작하지 않는 문제가 있었다. 구글 형님들께서도 POD를 제외하고 전역 객치를 만들지 말라는 조언을 하셨기에 우리가 만든 코드는 대체로 포인터를 사용하도록 변경했다. 그러다 급기야 어제는 부스트 라이브러리 코드를 디버깅 하기에 이르렀다. 잘 알겠지만 부스트 같은 템플릿 라이브러리는 쓰기는 편리하지만 디버깅은 지옥이다. 문제는 property_tree에서 발생했다. property_tree가 내부적으로 사용하는 rapidxml을 쓰면 잘 동작했는데 property_tree 코드만 쓰면 xml을 정상적으로 파싱하지 못했다. 여기저기 printf를 추가해서 따라간 마지막 장소에는 static 객체가 있었다.

여기까지만 읽고 마치 새로운 컴파일러가 문제가 있다고 생각할 사람들이 있을까봐 노파심에 이야기를 하자면 컴파일러가 생성한 코드를 그냥 그대로 사용하면 문제가 되지 않는다. 우리가 그대로 사용하지 않고 별도의 처리를 해서 사용하면서 발생하는 문제였다.

이 문제의 원인은 지역 static 객체 생성과 관련이 있었다. C++11 부터는 지역 static 객체 생성이 스레드 안전하게 보장하도록 표준에 추가되었다. 이 기능을 magic statics라 부르는 듯하다. 그간에는 이 기능에 대한 지원이 되지 않다가 VS2015에서 이 기능을 구현하면서 문제가 된 것이다. 그러면 VS2015가 내부적으로 스레드 안전한 초기화를 보장하기 위해서 어떻게 구현을 했는지 살펴보도록 하자. 그래야 왜 문제가 발생했는지도 알 수 있고, 어떻게 고칠 수 있는지도 알 수 있을테니 말이다. VS2015가 static 지역 객체 초기화를 스레드 안전하게 하기위해서 사용하는 전략은 단순하다. 락과 TLS다.

int const Uninitialized    = 0;
int const BeingInitialized = -1;
int const EpochStart       = INT_MIN;

// Access to these variables is guarded in the below functions.  They may only
// be modified while the lock is held.  _Tss_epoch is readable from user
// code and is read without taking the lock.
extern "C"
{
    int _Init_global_epoch = EpochStart;
    __declspec(thread) int _Init_thread_epoch = EpochStart;
}

static CRITICAL_SECTION   _Tss_mutex;
static CONDITION_VARIABLE _Tss_cv;
static HANDLE             _Tss_event;

static decltype(SleepConditionVariableCS)* encoded_sleep_condition_variable_cs;
static decltype(WakeAllConditionVariable)* encoded_wake_all_condition_variable;

컴파일러가 동기화를 위해서 사용하는 자원이다. 크리티컬 섹션으로 동기화하고 조건 변수나 조건 변수를 지원하지 않는 시스템이면 이벤트를 통해서 초기화 완료를 알리겠다는 생각이다. 위에 적힌 전역 변수는 모두 DLL이나 EXE가 실행될 때 최초에 초기화 된다. 위와는 별개로 정적 지역 객체가 존재하면 컴파일러는 해당 객체의 초기화 상태를 트래킹하기 위한 전역 변수를 추가한다. 이제 간단한 싱글턴 객체를 만들어보자.

class Single
{
private:
	Single() { printf("ctor\n"); }

public:
	~Single() { printf("dtor\n"); }

	static Single& Instance() { static Single s; return s; }
};

핵심은 멀티스레드에서 Single::Instance를 미친듯이 호출한다고 할 때 그 내부에 있는 s 객체의 초기화를 단 한번만 하도록 만드는 것이다. VS2015는 다음과 같은 형태로 코드를 만든다. 여기서 우리에게 문제가 된 부분은 최초 락 없이 생성됐는지를 체크하는 조건문 if(g_single_once > _Init_thread_epoch)에 있었다. g_single_once는 단순히 0으로 초기화 되지만 _Init_thread_epoch은 0x80000000으로 초기화 된다. 문제는 이게 TLS 변수라는 점에 있다. VS2015는 이를 위해서 __declspec(thread)를 사용해서 암시적 TLS로 처리했는데 이를 정상적으로 지원하지 않아서 _Init_thread_epoch이 0으로 함께 초기화됐고 그러면서 생성도 되지 않은 객체가 생성됐다고 판단이 이루어진 것이었다.

int g_single_once = Uninitialized;

static SIngle&
Single::Instance()
{
	if(g_single_once > _Init_thread_epoch)
	{
		_Init_thread_header(&g_single_once);

		if(g_single_once == BeingInitialized)
		{
			// 생성자 호출
			Single::Single();

			// 종료 시에 소멸자 호출되도록 등록
			atexit(Single::~Single);
			_Init_thread_footer(&g_single_once);

		}
}

동기화 구현의 핵심은 _Init_thread_header와 _Init_thread_footer에 있다. 해당 함수의 구현은 다음과 같다.

// Control access to the initialization expression.  Only one thread may leave
// this function before the variable has completed initialization, this thread
// will perform initialization.  All other threads are blocked until the
// initialization completes or fails due to an exception.
extern "C" void __cdecl _Init_thread_header(int* const pOnce)
{
    _Init_thread_lock();

    if (*pOnce == Uninitialized)
    {
        *pOnce = BeingInitialized;
    }
    else
    {
        while (*pOnce == BeingInitialized)
        {
            // Timeout can be replaced with an infinite wait when XP support is
            // removed or the XP-based condition variable is sophisticated enough
            // to guarantee all waiting threads will be woken when the variable is
            // signalled.
            _Init_thread_wait(XpTimeout);

            if (*pOnce == Uninitialized)
            {
                *pOnce = BeingInitialized;
                _Init_thread_unlock();
                return;
            }
        }
        _Init_thread_epoch = _Init_global_epoch;
    }

    _Init_thread_unlock();
}
// Called by the thread that completes initialization of a variable.
// Increment the global and per thread counters, mark the variable as
// initialized, and release waiting threads.
extern "C" void __cdecl _Init_thread_footer(int* const pOnce)
{
    _Init_thread_lock();
    ++_Init_global_epoch;
    *pOnce = _Init_global_epoch;
    _Init_thread_epoch = _Init_global_epoch;
    _Init_thread_unlock();
    _Init_thread_notify();
}

이 모든 구현을 살펴보고 나면 의문이 든다. 왜냐하면 암시적 TLS를 사용하는 엄청난 결정을 한 반면 그 암시적 TLS가 가져다주는 이점은 Single::Instance 구현의 첫번째 조건문 if(g_single_once > _Init_thread_epoch) 앞에 메모리 장벽이 없어도 된다는 것 밖에는 없어 보이기 때문이다. Interlocked 함수 하나 안 쓰겠다고 암시적 TLS 지원이 정상적으로 안 되는 XP 시스템을 포기한 셈이다. 실제로 이 구현을 사용한 DLL을 XP 시스템에서 LoadLibrary 등으로 동적 로딩하면 정상적으로 동작하지 않는다.

그러니 더 고민이 되었다. 이 신박한 구현에는 내가 생각하지 않은 다른 이유가 있을거야. Interlocked 함수 하나 안 쓰겠다고 이렇게 만든 것은 아닐거야. 뭔가 다른 이유가 있을거야 라면서 엄청 고민을 해봤다. 심지어 실행 카운트를 추적하는 기법 같아 보여서 이게 혹시 ABA 문제 등과 연관된 것은 아닐까 싶어 이것 저것 예외 케이스를 많이 생각해 보았지만 그 또한 아닌 것 같았다. thread local storage, lock optimizing, double checked 등과 같은 키워드로 겁나 검색했지만 걸리는 건 아무것도 없었다.

그렇게 이틀을 고민하며 보낸 끝에 어이없는 곳에서 이 구현의 원본을 찾게 되었다. Mike Burrows라는 구글에 계신 형님께서 A Fast Implementation of Synchronized Initialization 이름으로 전파한 복음이었다. 그 상세한 알고리즘 분석 내용에는 내가 찾던 정답 또한 들어 있었다. "The technique is useful only if such an access is faster than a memory barrier." 이 테크닉은 TLS 접근이 메모리 배리어보다 빠를 때에만 의미가 있다는 말.

lock cmpxchg 보다는 mov 몇 개 더 있는게 더 빠르겠지? 아마도? 하지만 여전히 남는 의문은 그 차이가 XP를 포기할만큼 그리 컸을까 싶은 생각… 지원 중단된 과거 보다는 미래를 더 중요하게 생각해서 내린 결정인지도 모르겠다. 어쨌든 XP에서 돌릴 수 있도록 해당 기능을 끌 수 있는 플래그는 존재하니 말이다.

참고한 것들

There is a way to access thread-specific data or thread-local storage. The technique is useful only if such an access is faster than a memory barrier. For the disassembly above, the compiler used its ability to access thread-local storage using variables declared with __thread, so the thread-local access is a normal "mov" instruction with a different segment register.

-- http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2660.htm#Appendix

This is a known limitation with Windows XP and thread-safe local static initialization. The thread-safe local initialization code relies on thread-local storage for efficient lock-free checking in many cases. Unfortunately, XP contains bugs that prevent loading DLLs with thread-local storage variables from working correctly when the DLL is loaded through LoadLibrary. Since XP is out of its service lifetime these bugs are unlikely to be fixed.

As a workaround, you can compile the program with /Zc:threadSafeInit-, which disables the thread-safe implementation. The old implementation does not rely on thread-local storage and will work on XP even in the presence of LoadLibrary, but is, of course, not thread-safe. If the function containing the local to initialize may be called from multiple threads you will need to handle appropriate synchronization manually when using /Zc:threadSafeInit-.

-- https://connect.microsoft.com/VisualStudio/Feedback/Details/1941836

Starting in C++11, a static local variable initialization is guaranteed to be thread-safe. This feature is sometimes called magic statics. However, in a multithreaded application all subsequent assignments must be synchronized. The thread-safe statics feature can be disabled by using the /Zc:threadSafeInit- flag to avoid taking a dependency on the CRT.

-- https://msdn.microsoft.com/en-us/library/y5f6w579.aspx

[시스템] WSL 환경에서 asciidoctor-pdf 설치하기

Tue, 01 Nov 2016 12:00:01 GMT

윈도우 bash 환경에서 asciidoctor-pdf를 설치해서 asciidoc 파일을 pdf로 변환하는 방법을 알아보자. 우선 설치를 위해서는 cmd에서 bash 치고 들어가서 아래 명령어를 순서대로 입력해 주면 된다.

$ sudo apt-get install software-properties-common
$ sudo apt-add-repository ppa:brightbox/ruby-ng
$ sudo apt-get update

$ sudo apt-get install ruby2.1
$ sudo apt-get install ruby2.1-dev

$ sudo gem install asciidoctor
$ sudo gem install coderay pygments.rb
$ sudo gem install --pre asciidoctor-pdf
$ sudo gem install asciidoctor-pdf-cjk-kai_gen_gothic
$ sudo asciidoctor-pdf-cjk-kai_gen_gothic-install

설치가 모두 성공했다면 아래 명령어를 통해서 adoc 파일을 pdf로 변환할 수 있다. 아래 명령을 실행하면 example.adoc을 변환해서 example.pdf 파일이 생성된다.

$ asciidoctor-pdf -r asciidoctor-pdf-cjk-kai_gen_gothic -a pdf-style=KaiGenGothicKR example.adoc

작업에 참고한 고마운 페이지들…

http://stackoverflow.com/questions/39011459/how-to-change-versions-of-ruby-1-9-to-ruby-2-0-in-the-new-windows-10-bash-shell http://java.ihoney.pe.kr/430

그냥 윈도우 환경에서도 설치가 잘 되는데 마지막 폰트 설치 작업에서 SSL 에러가 나서 폰트를 다운로드 받지를 못했다. 귀찮아서 그냥 bash에다 설치하는걸로…

[cpp] MSVC 왜 wprintf는 되고 printf는 되지 않는 것일까?

Thu, 13 Oct 2016 12:00:01 GMT

아래와 같은 간단한 코드를 살펴보자. 1252 코드페이지로 '안녕’을 변환해서 출력하는 예제다. 출력을 해보면 printf는 begin까지만 출력되고 wprintf는 end까지 모두 출력된다. 이를두고 printf는 안시 함수라 유니코드 문자열을 정상적으로 출력하지 못하고, wprintf는 유니코드 함수라 정상적으로 출력한다면 오산이다. 왜냐하면 둘다 출력은 틀렸기 때문이다. wprintf가 출력한게 한글 "안녕"이 아니라는 의미다. 한글은 우리가 잘 아는 문자라 이런 오류를 쉽게 인지할 수 있지만 모르는 문자 속에 섞여 있으면 자칫 wprintf는 제대로 출력한다는 오해를 할수도 있다. 그렇다면 왜 printf는 실패하고, wprintf는 끝까지 출력할까?

int main()
{
	// windows-1252	ANSI Latin 1; Western European (Windows)
	// 한글 변환이 불가능한 코드 페이지

	setlocale(LC_ALL, ".1252");

	wchar_t *msg = L"안녕";

	printf("printf begin %ls end", msg);
	printf("\n");
	wprintf(L"wprintf begin %ls end", msg);
	printf("\n");

	return 0;
}

이유는 간단하다. 그렇게 만들었기 때문이다. 먼저 printf부터 살펴보자. 결국 아래 코드로 들어간다. _WCTOMB_S가 변환에 실패하면 루프를 제어하는 변수 charsout이 -1로 설정되고 루프가 종료되어 더 이상 출력이 진행되지 않는다.

_output_l(...)
{
	// ...

	while ((ch = *format++) != _T('\0') && charsout >= 0)
	{
                    while (count--) {
                        e = _WCTOMB_S(&retval, L_buffer, _countof(L_buffer), *p++);
                        if (e != 0 || retval == 0) {
                            charsout = -1;
                            break;
                        }
                        WRITE_STRING(L_buffer, retval, &charsout);
                    }

	}

	// ...

}

반면 wprintf는 아래와 같이 전개되고, 변환에 실패하면 ?를 출력하고 성공인 척 하도록 되어 있다. 즉, wprintf라고 정상 출력을 해내는 것이 아니다.

_output_l()
{
	// ...

	while ((ch = *format++) != _T('\0') && charsout >= 0)
	{
		WRITE_STRING(text.wz, textlen, &charsout);
	}

	// ...

}

LOCAL(void) write_string (
    _TCHAR *string,
    int len,
    FILE *f,
    int *pnumwritten
    )
{
    if ( (f->_flag & _IOSTRG) && f->_base == NULL)
    {
        (*pnumwritten) += len;
        return;
    }
    while (len-- > 0) {
        write_char(*string++, f, pnumwritten);
        if (*pnumwritten == -1)
        {
            if (errno == EILSEQ) // 변환 실패로 빠지면 ?를 출력하고 성공인척 한다.
                write_char(_T('?'), f, pnumwritten);
            else
                break;
        }
    }
}

위 코드에는 변환하는 부분이 나와 있지 않은데 write_char 함수를 따라가보면 결국 _fputwc_noblock으로 이어지고 콘솔인 stdout은 텍스트 모드라 printf와 동일하게 wctomb_s로 변환을 시도한다. 다만 여기서 실패해도 위쪽에서 살펴본 if문에 의해서 ?를 출력하고 계속 출력을 이어가도록 만들어둔 것이다.

wint_t __cdecl _fputwc_nolock (
        wchar_t ch,
        FILE *str
        )
{
	// ...


        if (!(str->_flag & _IOSTRG))
        {
            if (_textmode_safe(_fileno(str)) == __IOINFO_TM_UTF16LE
                    || _textmode_safe(_fileno(str)) == __IOINFO_TM_UTF8)
            {
                /* binary (Unicode) mode */
                if ( (str->_cnt -= sizeof(wchar_t)) >= 0 ) {
                    return (wint_t) (0xffff & (*((wchar_t *)(str->_ptr))++ = (wchar_t)ch));
                } else {
                    return (wint_t) _flswbuf(ch, str);
                }
            }
            else if ((_osfile_safe(_fileno(str)) & FTEXT))
			{
				// stdout은 이쪽으로 빠진다.
				// 결국 wctomb_s 함수로 printf와 동일하게 변환을 시도한다.

                int size, i;
                char mbc[MB_LEN_MAX];

                /* text (multi-byte) mode */
                if (wctomb_s(&size, mbc, MB_LEN_MAX, ch) != 0)
                {
                        /*
                         * Conversion failed; errno is set by wctomb_s;
                         * we return WEOF to indicate failure.
                         */
                        return WEOF;
                }

	// ...
}

간혹 깨진 문자열을 보고 UTF-16으로 바로 출력됐다는 소리를 하는 황당한 경우도 있다. UTF-16으로 바로 출력하고 싶다면 printf와 같은 텍스트 계열 함수가 아닌 fwrite 같은 바이너리 계통의 함수를 사용해야 한다. 아래와 같이 출력하면 UTF-16으로 출력된다.

fwrite(msg, sizeof(*msg), wcslen(msg), stdout);

(사족) 가끔 느끼는 거지만 자기가 지금 짜고 있는 코드가 정확하게 무슨 일을 하고 있는지 알고 있는 프로그래머가 생각보다 드문 것 같다. 토이 프로그램만 만들게 아니라면 자기가 짠 코드나 라이브러리가 정확하게 무슨 일을 하는지 알고 있는 것은 무척 중요하다. 컴퓨터는 복잡하고 코드는 추상적이기 때문에 프로그래머는 공부를 열심히 해야 한다. 내가 생각하는 프로그래머라는 업의 본질은 그런 것 같다.

[cpp] 마이크로소프트는 왜 setlocale에서 UTF-8을 지원하지 않을까?

Thu, 13 Oct 2016 12:00:01 GMT

지난 글에서 우리는 setlocale에서 UTF-7이나 UTF-8을 지정할 경우 실패한다는 것을 알게 되었다. 하지만 여전히 의문은 남는다. 왜 MS는 setlocale에서 흔해빠진 UTF-8 따위를 지원하지 않을까? 도대체 무엇이 우리를 가로 막는 것일까? 안 될 이유가 없는게 안되면 한번쯤은 내부가 궁금해지게 마련이다. 그래서 이런 간단한 코드를 디버깅 해보기로 했다.

int main()
{
    printf("%p\n", setlocale(LC_CTYPE, "Korean_Korea.65001"));
    return 0;
}

디버깅 결과 총 세 지점에 우리를 가로막는 허들이 존재한다는 사실을 알게 되었다. 첫번째는 아래 지점이다. 대놓고 CP_UTF7과 CP_UTF8은 안 된다는 소리다. 재미난 사실은 if 문에 이 코드가 들어간 것이 Visual Studio의 특정 버전 부터라는 점이다. Visual C++ 6.0에는 CP_UTF7과 CP_UTF8을 검사하는 코드가 없다. 단지 IsValidCodePage로만 체크한다.

BOOL __cdecl __get_qualified_locale(const LPLC_STRINGS lpInStr, LPLC_ID lpOutId,
                                    LPLC_STRINGS lpOutStr)
{

    // ...

    //  verify codepage validity
    if (!iCodePage || iCodePage == CP_UTF7 || iCodePage == CP_UTF8 ||
        !IsValidCodePage((WORD)iCodePage))
        return FALSE;

    // ...
}

다음 허들은 아래 지점이다. 현재 코드페이지로 변환 되는 최대 글자 개수가 MB_LEN_MAX보다 크면 안 된다는 소리다. MB_LEN_MAX의 경우 Visual Studio 2015는 5로 정의되어 있다. 따라서 이 코드는 넘어간다. 반면에 Visual C++ 6.0에서는 MB_LEN_MAX가 2고 CP_UTF8은 이 구문을 넘지 못하고 실패한다.

int __cdecl __init_ctype (
        pthreadlocinfo ploci
        )
{
    // ...

        if (lpCPInfo.MaxCharSize > MB_LEN_MAX)
            goto error_cleanup;

    // ...
}

마지막 허들은 아래 지점이다. MultiByteToWideChar 함수를 통해서 버퍼가 얼마나 커야 하는지 구하는 부분이다. code_page에 CP_UTF8이 들어 있으면 플래그로 0이나 MB_ERR_INVALID_CHARS가 전달되어야 하지만 여기에서는 MB_PRECOMPOSED가 합쳐서 전달된다. MSDN 페이지에 나와 있는 것처럼 ERROR_INVALID_FLAGS로 실패한다.

static BOOL __cdecl __crtGetStringTypeA_stat(
        _locale_t plocinfo,
        DWORD    dwInfoType,
        LPCSTR   lpSrcStr,
        int      cchSrc,
        LPWORD   lpCharType,
        int      code_page,
        int      lcid,
        BOOL     bError
        )
{
    // ...

        /* find out how big a buffer we need */
        if ( 0 == (buff_size = MultiByteToWideChar( code_page,
                                                    bError ?
                                                        MB_PRECOMPOSED |
                                                        MB_ERR_INVALID_CHARS
                                                        : MB_PRECOMPOSED,
                                                    lpSrcStr,
                                                    cchSrc,
                                                    NULL,
                                                    0 )) )
            return FALSE;

    // ...
}

여기까지 따라오면 대충 뭔가 감이 잡힌다. 마지막 MSDN의 주석에 있던 코드페이지를 넘기면 setlocale은 죄다 실패한다. 그리고 그 코드 페이지가 가지고 있는 대체적인 특징은 한 글자가 2바이트가 넘는 3바이트, 4바이트 등으로 변환되는 코드페이지라는 점이다.

For the code pages listed below, dwFlags must be set to 0. Otherwise, the function fails with ERROR_INVALID_FLAGS.

50220
50221
50222
50225
50227
50229
57002 through 57011
65000 (UTF-7)
42 (Symbol)

Note For UTF-8 or code page 54936 (GB18030, starting with Windows Vista), dwFlags must be set to either 0 or MB_ERR_INVALID_CHARS. Otherwise, the function fails with ERROR_INVALID_FLAGS.

— MultiBytesToWideChar MSDN

다시 setlocale의 MSDN 페이지를 살펴보자. UTF-7과 UTF-8을 넣으면 실패한다는 앞 문장에 의미심장한 설명이 있다. 한 글자당 두 바이트를 넘게 사용하는 코드 페이지는 예외라는 설명이다. 예외~ 즉, UTF-8이 안 되는 것이 아니라 한 글자에 두 바이트를 넘게 쓰는 코드페이지는 죄다 setlocale로 지정할 수 없고, wcstombs나 mbstowcs 함수로 변환할 수 없다는 것을 의미한다.

The set of available locale names, languages, country/region codes, and code pages includes all those supported by the Windows NLS API except code pages that require more than two bytes per character, such as UTF-7 and UTF-8.

— setlocale MSDN

그렇다면 MS는 왜 한 글자당 두 바이트 이상을 사용하는 코드페이지는 예외 처리를 했을까? 이 페이지에 약간의 힌트가 나와 있다. 수많은 레거시 코드가 멀티바이트에서 한 글자에 사용할 수 있는 저장 공간이 최대 두 바이트라고 가정하고 작성했기 때문이란다. 말 그대로 레거시 코드와의 호환성을 위해서 MS는 setlocale로 UTF-8을 지정할 수 없도록 만들었다. 미래 세대의 불편함 따위보다는 과거 세대와의 호환성 유지가 더 중요했기 때문이리라…

[cpp] printf와 유니코드 출력

Wed, 05 Oct 2016 12:00:01 GMT

wchar_t msg[] = L"안녕하세요.";
printf("%ls 끝.", msg);

이 코드는 유니코드 문자열 "안녕하세요. 끝."을 출력한다. 단순한 이 출력 속에도 복잡한 변환이 숨겨져 있다. printf는 내부적으로 유니코드 문자열을 멀티바이트 문자열로 변환을 시도한다. 이 변환에는 wcstombs와 같은 계열의 함수들이 사용된다. 이 함수는 현재 설정된 로케일을 참조한다. 해당 로케일은 setlocale 등으로 지정할 수 있다. 해당 로케일 정보에 포함된 코드 페이지로 변환한다. 특정 유니코드 문자가 해당 코드페이지로 적절하게 변환이 되지 않을 수도 있다. 그런 일이 발생하면 printf 함수는 실패하고 "안녕하세요" 다음에 있는 "끝"은 출력되지 않는다.

따라서 printf로 유니코드 문자열을 출력할 때에는 로케일이 굉장히 중요하다. 해당 로케일은 앞서도 살펴보았듯이 setlocale로 지정할 수 있다. 일반적으로 UTF-8로 변환해서 출력하기 위해서는 다음과 같이 사용한다.

setlocale("en_US.UTF-8");
wchar_t msg[] = L"안녕하세요.";
printf("%ls 끝.", msg);

하지만 안타깝게도 Visual Studio를 사용한다면 위 코드를 통해서 UTF-8 출력을 사용할 수 없다. setlocale MSDN 페이지를 참고하면 다양한 형태로 로케일을 지정할 수 있는 것을 볼 수 있다. 그리고 en_US.UTF-8은 해당 페이지에서 언급하는 규칙에도 부합하는 것으로 보여진다. 혹시나 하는 마음으로 UTF-8에 해당하는 코드페이지인 65001을 사용해서 en_US.65001을 전달해 보아도 setlocale은 실패한다. 그리고 MSDN 페이지를 좀 더 꼼꼼하게 읽어보면 왜 그런지가 나와 있다.

If you provide a code page value of UTF-7 or UTF-8, setlocale will fail, returning NULL.

— setlocale MSDN

Visual C++을 사용해서는 setlocale을 통해서 UTF-8을 코드페이지로 지정할 방법은 없는 것으로 추정된다. 이뭐병?

[cpp] Visual Studio 2015에서 stdio 라이브러리 오류 해결 방법

Sat, 06 Aug 2016 12:00:01 GMT

Visual Studio 2015를 사용해서 오픈 소스를 빌드해보면 종종 링크 단계에서 vsnprintf를 찾을 수 없다거나 황당하게 printf를 찾을 수 없다는 링크 오류가 발생한다. 해당 문제는 해당 함수들이 Visual Stduio 2015에서 인라인 구현으로 변경되었기 때문이다. <stdio.h>나 <conio.h>를 포함하고 관련 함수를 사용하면 상관이 없는데 해당 헤더를 인클루드 하지 않고 컴파일한 다음 링크를 하면 심벌을 찾을 수 없다는 오류가 발생한다.

해결 방법은 두 가지인데 1) 파일을 일일이 뒤져서 헤더 파일을 추가해주는 방법 2) legacy_stdio_definitions.lib을 링크 단계에서 포함시켜주는 방법이 있다. 당연지사 그 많은 소스 파일을 수정할 수 없기 때문에 legacy_stdio_definitions.lib을 추가해 주는 것이 편리하다.

이것 외에도 Visual Studio 2015에서 호환성을 저해하는 변경 사항이 궁금하다면 아래 페이지를 참고하도록 하자.

https://msdn.microsoft.com/en-us/library/bb531344.aspx

[cpp] Visual Studio 2015 명령줄에서 XP 타겟 사용하기

Fri, 05 Aug 2016 12:00:01 GMT

Visual Studio 2012부터 XP 타겟을 사용하기 위해서는 툴체인을 XP가 들어간 것을 선택해야 한다. Visual Studio 2015는 v140_xp를 선택하면 된다. IDE에서는 그렇게 사용하면 되는데 명령 프롬프트에서 직접 빌드 해야 할때에는 어떻게 해야 할까? 컴파일러에 주는 뭔가 옵션이 있는 것일까, 아니면 CRT 라이브러리를 다른걸 선택하면 되는건가, 라는 여러가지 의문이 생긴다. 당황하지 않게 어떡하는지 살펴보도록 하자.

우선 Visual Studio 2012부터 생긴 XP 타겟이 해주는 역할은 크게 두 가지다. 1) XP 호환되는 플랫폼 SDK를 사용해서 컴파일한다. 7.1A 버전이 마지막 호환되는 SDK다. 2) XP 호환되는 플랫폼 SDK를 사용해서 링크한다. 마찬가지로 7.1A에 포함된 라이브러리를 말한다. 3) 링크 옵션으로 실행 가능한 운영체체를 XP 버전으로 지정한다. 이걸 하지 않으면 6.0으로 선택되서 Vista부터 실행 가능한 이미지가 생성된다.

XP 타겟이 하는 일을 알았으니 결론은 간단하다. 1은 cl에다 옵션을 주면 되는 것이고, 2, 3은 link에다 옵션을 추가하면 된다. 이미 만들어진 빌드 스크립트를 사용한다면 빌드 옵션을 조정하는 것도 일이기 때문에 환경 변수를 이용하면 편리하다.

cl에 추가되는 옵션을 조정하기 위해서는 아래 환경 변수를 추가하면 된다.

set INCLUDE=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Include;%INCLUDE%
set PATH=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Bin;%PATH%

link에 사용되는 라이브러리를 변경하기 위해서는 아래 환경 변수를 추가하면 된다. 32비트 빌드라면 아래 환경 변수를 추가하면 된다.

set LIB=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Lib;%LIB%

64비트라면 아래 환경 변수를 추가한다.

set LIB=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Lib\x64;%LIB%

32비트 콘솔 프로그램을 빌드하면 아래와 같이 환경 변수를 추가한다. 윈도우 프로그램이라면 subsystem을 windows로 지정하면 된다.

set LINK=/SUBSYSTEM:CONSOLE,5.01 %LINK%

64비트 콘솔 프로그램을 빌드하면 아래와 같이 추가하면 된다.

set LINK=/SUBSYSTEM:CONSOLE,5.02 %LINK%

그런데 여기까지 하고 나면 함정이 하나 있다. Visual Studio 2015는 과거 버전이 그랬던것처럼 빌드 가능한 명령 프롬프트를 시작 메뉴에 등록하지 않는다는 점이다. 어디서 빌드를 시작해야 난감해진다. 당황할 필요 없다. 배치 파일은 동일한 경로에 있다. 아래와 같이 실행하면 각각 32비트 64비트 빌드 환경으로 진입할 수 있다.

C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat x86
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat amd64

전체적인 메커니즘에 대해서 더 궁금한 분은 여기 글을 참고하도록 하자. 해당 글을 보면 CL 옵션으로 USING_V110_SDK71 매크로 정의를 추가하는 것을 볼 수 있는데 그건 잘못된 SDK가 빌드되는 것을 막기 위한 용도로 현재는 사용되지 않는다.

[시스템] Linux 서브 시스템, 윈도우 대격변의 서막

Fri, 05 Aug 2016 11:00:01 GMT

윈도우를 배울 때 누구나 그러하듯이 서브시스템이란 것이 존재하고, OS/2, POSIX, WIN32가 있다고 배운다. 하지만 그 존재를 알아채기란 쉽지 않다. 그저 그런가 보다 한다. 왜냐하면 그나마 명맥을 유지하는 거라곤 WIN32밖에 없기 때문이다. 그러다 윈도우의 역사를 좀 알게되고 데이비드 커틀러란 걸출한 프로그래머를 인식하게 되면 개발 초기에는 WIN32보다 OS/2를 지원하는 것이 무척이나 중요했다는 사실을 그나마 알게 된다. 그랬거나 말거나 OS/2는 역사의 뒤안길로 사라졌고 남은건 WIN32 밖에 없다. Windows NT가 출시되고 거의 20년간 그랬다.

그랬던 거의 존재조차 유명무실했던 서브시스템이란 존재가 20년 만에 다시 재조명되고 있다. WIN32 밖에 보지 못해 있는거야 없는거야 라고 느꼈던 많은 프로그래머들도 이제는 그것이 단지 역사가 아닌 실제 존재한다는 사실을 온몸으로 느낄 수 있게 됐다. 바로 8/2일자로 진행된 윈도우 10 1주년 업데이트로 말이다. 20년 만에 윈도우가 리눅스를 품었다. 바로 리눅스 서브시스템이 생긴 것이다. Cygwin 정도를 상상했다면 잊어도 괜찮다. ELF 바이너리가 네이티브로 돌아가는 신세계가 펼쳐지니 말이다.

인사이더 빌드 때부터 꾸준히 말이 많았지만 나이가 들어서 그런지 그래도 어느 정도 완성된 다음에 구경하고 싶은 마음에 정식 출시 하기를 기다렸다. 하지만 정식 출시에서도 베타 딱지는 아직 떼지못한 것으로 보여진다.

윈도우 10 1주년 업데이트는 여기서 다운로드 받아서 설치하면 된다. bash쉘을 활성화하는 법은 정성태 님의 글을 참고 하자. 그저 여기서는 맛배기로 대격변의 서막이 어떻게 진행되고 있는지만 살펴보기로 하자.

#0

Figure 1. 프로세스 트리

우선 프로세스 트리다. bash.exe가 일종의 게이트를 하는 것으로 보여진다. 윈도우 실행 파일인데 이 녀석을 실행하면 동시에 svchost.exe 밑에 init, bash가 같이 실행된다. 화면은 쉘에서 vi를 실행시켜서 bahs의 자식으로 vim.basic까지 실행된 것을 볼 수 있다.

#1

Figure 2. 실행된 vim.basic의 기본 정보

실행된 vim.basic 프로세스의 기본 정보를 살펴보자. 기본 정보가 표시되어야 하는 곳에 아무 정보도 표시되지 않는 것을 알 수 있다. 고로 우리는 망했어요 ㅠㅜ~

Figure 3. 실행된 vim.basic의 메모리 정보

메모리 정보를 살펴보자 vim.basic이 0x400000에 매핑되어 있는 것을 볼 수 있다. 어떤 이유에서인지 MS는 역사적으로 0x400000을 좋아하는 것으로 보여진다.

Figure 4. vim.basic의 매핑된 메모리 영역

그럼 최종적으로 0x400000 메모리를 열어보면 이와 같다. 7f 45 4c 46, ELF 실행 파일이 그대로 매핑된 걸 볼 수 있다. 망했어요2 ㅠㅜ~

#2

ps Figure 5. ps -A 결과 서브시스템 내의 세계는 어떨까? ps -A를 해보면 우리가 bash 쉘에서 실행한 것만 출력된다는 것을 알 수 있다.

그렇다면 새로운 bash 쉘은 새로운 리눅스를 의미할까? bash 쉘을 여러개 띄워서 실행해본 결과 동일한 init의 자식으로 생성되는 것을 알 수 있었다. 더불어 격리된 bash 쉘들에서 실행된 내용은 접근할 수 있는 것으로 보여졌다.

ps -A에서 출력된 pid는 원래 윈도우에서 보여지는 pid와 일치할까? 확인결과 일치하지 않는 것으로 보여진다.

이 정도 결과를 토대로 알 수 있는 것은 리눅스 서브시스템에서는 윈도우로의 접근이 불가능한 샌드박스 같은 구조인 것으로 유추해 볼 수 있겠다. 은막 뒤에서 펼쳐지는 마법의 보다 자세한 사항은 여기를 참고하자. 피코 프로세스라뉘… 그리고 이 핫한 기능의 가장 핫한 지점은 깃허브로 추정된다.

#3

WSL(Windows Subsystem for Linux)의 존재를 우리가 처음 알게 됐을 때 가장 우려한 것은 WSL을 이용한 윈도우 세계로의 접근이었다. 하지만 잠깐 살펴본 바에 의하면 기본적으로는 막혀 있는 것으로 보여진다. 하지만 WOW64를 토대로 보건데 뭔가 강을 건너는 숨겨진 문이 있을지도 모를 일이다. 어쨌든 판도라의 상자 밖으로 나와 버린 PEB도 없는 이 애들을 어떡할지 걱정이다.

번외 얘기긴 하지만 CEO 한 명 바꼈을 뿐인데 MS 참 열심히 일한다. 이 작품을 감상하면서 다시금 느꼈다. 이러니 저러니 해도 MS가 명실상부한 지구상에서 소프트웨어를 제일 잘 만드는 기업 중에 하나긴 하다는 사실을 말이다. 그런 의미에서 이제 안드로이드도 네이티브로 돌려주는 신기원을 열어주기를 ㅋㅋㅋ~

[시스템] FreeBSD에서 BOM 제거를 위한 삽질기

Fri, 29 Jul 2016 11:00:01 GMT

각 메이저 진영은 모두 마치 약속이나 한 것처럼 미묘한 차이로 우리를 괴롭힌다. 마이크로소프트와 오픈소스 진영 간의 차이는 역사적으로 더 골이 깊다. UTF16과 UTF32, 파라미터를 UTF16으로 변경하는 것과 기존 함수에 UTF8 변환 기능을 추가하는 것, 64비트 지원을 위해서 LLP64냐 LP64냐 등의 차이는 유명하다. 여기에 또 하나의 골치아픈 차이가 있다. UTF8 소스에 대한 BOM이다. msvc는 BOM이 있는 것만 컴파일을 해주고, gcc는 BOM이 없는 것만 컴파일을 해준다. 둘이서 짜고 우리를 괴롭히는 것 같다. 어떤걸 선택해도 우리는 양쪽 다 만족시킬 수가 없다. 결국 양쪽 다 만족시키기 위해서는 한쪽에다 변환기를 설치해야 한다. 우리는 gcc를 위해서 BOM을 제거하기로 결정했다.

#0

find . -type f -exec sed -i '1 s/^\xef\xbb\xbf//' {} \;

우리는 이 명령어를 이용해서 UTF8 BOM을 제거했다. 한동안 잘 사용했는데 이게 유닉스 진영에서도 문제가 될지는 몰랐다. FreeBSD를 만나기 전까지는 말이다. FreeBSD에서는 위 명령어가 제대로 동작하지 않았고 그 미묘한 차이로 인해 결국 나는 몇 시간을 허비했다.

#1

find . -type f -exec sed -i .bak '1 s/^\xef\xbb\xbf//' {} \;

처음 구글 신이 나에게 알려준 것은 sed의 -i 옵션이 리눅스와 BSD가 다르다는 것이었다. BSD는 -i의 옵션 다음에 원본을 저장할 확장자를 지정해야 한다는 것이었다. 위의 커맨드는 그렇게 변경한 것이다. .bak 파일에 원본을 백업하고 편집된 파일을 원본에다 덮어씌우는 기능을 한다. 명령어 오류가 없이 잘 돌아가는 것 같았다.

#2

find . -type f -exec sed -i .bak '1 s/^\xef\xbb\xbf//' {} \; -exec rm {}.bak \;

1차 시도에 백업 파일을 제거하는 기능을 덧붙인 것이다. 여기까지 하고는 이제는 빌드가 잘 되겠지 하고는 돌렸다. 하지만 빌드는 여전히 되지 않았다. 파일을 열어보니 BOM은 그 자리에 그대로 존재했다. 여기서 가장 많은 시간을 허비했다. 도대체 왜 BOM 제거가 안 되는 것이지? 구글님도 딱히 뾰족한 답을 주지 않았다. 삽질 끝에 알아낸 사실은 FreeBSD에 포함된 sed가 \xef등의 16진수 표현을 지원하지 않는다는 것이었다. \xef등이 아닌 멀쩡한 문자를 넣으면 잘 제거됐다. 구글님은 너가 8진수를 쓰면 될지도 모를껄 이라고 알려줘서 \oNNN을 사용한 표기로 변경해 보았으나 소용이 없었다.

#3

find . -type f -exec sed -i .bak $'1 s/^\xef\xbb\xbf//' {} \; -exec rm {}.bak \;

bash핵을 사용한 변칙 방법이다. bash에서 $'' 안에 포함된 문자를 변환시킨다는 것을 이용한 방법이다. 여기서 깔끔하게 끝낼 수 있었는데 나는 이때까지 이 명령어를 makefile에 결합해서 사용하는 방법을 몰랐다. 그래서 16진수 표현을 지원하는 awk로 돌아섰다.

#4

find . -type f -exec awk 'NR==1{sub(/^\xef\xbb\xbf/, "")}{print}' {} \;

위 명령은 앞선 우리의 sed와 동일한 기능을 한다. 단지 파일에 저장하는 것이 아니라 변경된 내용을 화면에 출력할 뿐이다. awk에서 제자리 편집(in-place edit)를 하는 방법을 찾아 보았다. -i 옵션이 있었지만 FreeBSD에서는 응당 지원하지 않았다. 출력물을 결국 리다이렉션 시켜서 저장하는 방법 밖에는 없었다.

#5

find . -type f -exec awk 'NR==1{sub(/^\xef\xbb\xbf/, "")}{print > {}}' {} \;

find가 엮여 있어서 그냥 리다이렉션 시키기는 쉽지 않았다. 그러다 발견한 것이 awk의 위와 같은 문법이다. print 안에서 리다이렉션 구문을 쓸 수 있었다. 하지만 이렇게 하자 뭔가 잘 동작하지 않았다.

#6

find . -type f -exec awk -v out={} 'NR==1{sub(/^\xef\xbb\xbf/, "")}{print > out}' {} \;

그러다 -v를 사용해서 변수 값을 지정해서 사용하면 정상 동작한다는 것을 알아냈다. 여기서 FreeBSD를 정복하는 줄 알았지만 여전히 문제가 있었다. 정확한 원인은 모르겠지만 이렇게 저장된 파일은 원본의 전체가 아니라 일정한 길이 이후로 파일이 잘렸다. 전체 버퍼가 다 저장되지 않는 것처럼 보였다.

#7

find . -type f -exec sh -c "awk 'NR==1{sub(/^\xef\xbb\xbf/, \"\")}{print}' {} > {}" \;

결국 다시 쉴이다. 진작 알았으면 좋을 뻔 했다. "sh -c"로 특정 명령을 쉴로 실행할 수 있다는 사실이었다. 그래서 위와 같은 것을 생각해냈지만 결과는 참혹했다. 빈 파일만 덩그러니 남았다.

#8

find . -type f -exec sh -c "awk 'NR==1{sub(/^\xef\xbb\xbf/, \"\")}{print}' {} > {}.tmp" \;

임시 파일로 리다이렉션 시킬 수 밖에 없었다. 이 명령은 정확하게 동작했다.

#9

find . -type f -exec sh -c "awk 'NR==1{sub(/^\xef\xbb\xbf/, \"\")}{print}' {} > {}.tmp; mv {}.tmp {}" \;

임시 파일을 원본으로 덮어씌우는 것을 추가한 이 명령은 완벽했다. 이제 빌드 할 수 있게 되었다.

#10

몇 시간의 삽질 끝에 동작하는 두 가지 명령어를 알아냈다.

find . -type f -exec sh -c "awk 'NR==1{sub(/^\xef\xbb\xbf/, \"\")}{print}' {} > {}.tmp; mv {}.tmp {}" \;

이 명령은 bash가 필요하지는 않다. 다만 매칭된 파일 개수만큼 sh, awk, mv가 실행된다.

bash -c "find . -type f -exec sed -i .bak $'1 s/^\xef\xbb\xbf//' {} \; -exec rm {}.bak \;"

이 명령은 bash가 필요하다. 다만 sed, rm만 실행되기 때문에 sh가 추가로 실행되는 앞선 명령 보다는 효율적이다.

[cpp] Visual Studio 2008로 nss 빌드 하기

Fri, 29 Jul 2016 10:00:01 GMT

오픈 소스가 없었다면 우리같이 작은 소프트웨어 기업은 시작도 못했을 것이다. 모든 것을 다 만드려면 사람이 많아야 하고, 필요한 것들을 다 사려면 돈이 많아야 하기 때문이다. 어쨌든 우리같이 작은 기업에게 오픈 소스는 축복이다. 하지만 늘 그렇듯이 버튼 하나 누르면 마법처럼 동작하는 상용 소프트웨어와는 다르게 오픈 소소는 시키는대로 해도 뭔가 안 되는 경우가 많은 것 같다. 물론 요즘은 정확하게 시키는 대로 하면 대체로 비슷한 결과를 얻을 수 있지만, 항상 사람 일이란게 시키는 대로만 하고 살수는 없는 노릇이다. 최근에 mozilla nss를 윈도우에서 빌드하면서도 비슷한 경험이 있었다. Visual Studio 2008을 이용해서 정적 CRT로 빌드를 하려고 했으나 몇 가지 이유로 쉽지 않았다. 여기에 그 기록을 남겨 본다.

#0

여기서 MozillaBuild를 받아서 설치한다. 그러면 기본 설치 경로인 mozilla-build에 가보면 start-shell-msvc2013.bat 파일이 존재한다. 해당 파일을 복사해서 2008으로 변경해준다. 해당 파일을 내용을 아래와 같이 수정하면 된다. 64비트를 빌드하고 싶으면 MOZ_MSVCBITS를 64로 변경해주면 된다.

@ECHO OFF

SET MOZ_MSVCBITS=32
SET MOZ_MSVCVERSION=9
SET MOZ_MSVCYEAR=2008

REM Switch CWD to the current location so that the call to start.shell-bat
REM doesn't fail if invoked from a different location.
pushd "%~dp0"

CALL start-shell.bat

수정했으면 배치파일을 실행한다. 명령 프롬프트가 뜬다. 소스를 다운로드 받을 폴더로 이동한다.

#1

해당 소스 파일 폴더에서 아래 명령어를 입력하면 최신 nspr과 nss 소스 코드를 클론할 수 있다.

$ hg clone https://hg.mozilla.org/projects/nspr
$ hg clone https://hg.mozilla.org/projects/nss

디버그, 정적 CRT를 사용하기 위해서는 아래와 같이 환경 변수를 선언해 준다.

$ export USE_DEBUG_RTL=1
$ export USE_STATIC_RTL=1

그 다음 nss 폴더로 이동해서 아래와 같이 입력하면 nspr과 동시에 빌드를 진행해 준다.

$ cd nss
$ make nss_build_all

#2

우리가 정적 라이브러리를 사용해서 빌드를 하면서 한 가지 문제가 있었다. 아직 수정되지 않은 문제로 보여진다. 이 함수가 문제였다. 전체적으로 아래와 같은 코드 흐름이다. 문제는 output_file이라는 변수가 PL_strdup와 PR_Malloc에 의해서 할당되는데 해제는 항상 PL_strfree로 한다는 점에 있다. 물론 PL_strdup와 PR_Malloc이 동일한 DLL에 있거나 정적으로 이 프로그램과 결합한다면 문제가 되지 않는다. 심지어 DLL 형태의 CRT를 사용해도 문제가 되지 않는다. 우리 케이스에서는 이게 문제였다. PL_strdup와 PR_Malloc은 서로 다른 DLL에 있는 함수였고, 이는 서로 다른 힙에 할당된다는 것을 의미했다. PL_strfree에서 크래시가 발생했다.

static char *
mkoutput(const char *input)
{
	char *output = PR_Malloc(...);

	return output;
}

int main()
{
	char *output_file = NULL;

	if(some_cond)
		output_file = PL_strdup(optstate->value);

	if(output_file == NULL)
		output_file = mkoutput(input_file);

	if(output_file) /* allocated by mkoutput function */
		PL_strfree(output_file);
}

코드를 아래와 같이 수정해주면 된다. 결국 PL_strdup만 할당한 변수를 사용하도록 통일해 주는 것이다.

static char *
mkoutput(const char *input)
{
    char *result = NULL;
    int in_len = strlen(input);
    char *output = PR_Malloc(in_len + sizeof(SGN_SUFFIX));
    int index = in_len + 1 - sizeof("." SHLIB_SUFFIX);

    if ((index > 0) &&
        (PL_strncmp(&input[index],
                    "." SHLIB_SUFFIX, sizeof("." SHLIB_SUFFIX)) == 0)) {
        in_len = index;
    }
    memcpy(output, input, in_len);
    memcpy(&output[in_len], SGN_SUFFIX, sizeof(SGN_SUFFIX));

	result = PL_strdup(output);
	PR_Free(output);

    return result;
}

#3

하지만 여기까지 수정을 하면 대체로 빌드가 상당히 진행이 되는데 테스트 빌드를 하는 도중에 오류가 발생한다. 대체로 C11, C14 기능들을 활용한 부분인데 Visual Studio 2008에서 그런걸 기대하기는 힘드니 아래와 같이 환경 변수를 선언해서 해당 부분은 빌드를 하지 않도록 한 다음 빌드를 하면 모두 성공시킬 수 있다.

$ export NSS_DISABLE_GTESTS=1
$ build nss_build_all

[일상] 자존심

Thu, 21 Jul 2016 10:00:01 GMT

하이고. 내 자슥인데 얼굴 보믄 모르것나. 영욱아. 내 말 잘 들으래이. 자존심은 미친년 머리에 꽂아놓은 꽃하고 같은 기다. 그 와, 마을마다 미친 아가 하나씩 안 있었나. 머리에 꽃을 꽂고 댕깄다 이가. 그칸데 희한하제? 얼굴을 만지고 때리고 밀고 그캐도 헤헤 거리고 웃던 아가, 머리에 꽃만 만지믄 살쾡이처럼 변해가 덤비는 기라. 지한테는 머리에 꽃이 지 몸보다 더 중요한기라. 사람들은 저기 미치가 저라는갑다 요라지만은, 내가 볼 때는 다 똑같데이. 사람들은 다 지 머리에 꽃 하나씩 꽂고 사는 기라. 아무 쓸모 없는 건데도, 지 몸보다 더 중하다고 착각하고 사는 기 있는 기라. 영욱가, 니한테는 그기 자존심이데이. 니는 가마이 있어도 서동환이 아들이고, 한오그룹 회장이 될 끼다. 동윤이 점마가 아등바등 기가 와도 대통령이 되고 뭐가 되도, 니 발꿈치도 못 따라오는 기다. 그카이 영욱아. 인자 마음 가라앉히고…

-- 드라마 추적자

종종 사람들이 정말 엉뚱한 거래를 할 때가 있다. 손해 볼 것이 뻔한 상황에서도 불나방처럼 달려드는 상황. 대체로 그때 이유는 한결같다. 자.존.심. 아무것도 아닌 그거 하나 지키려고 너무 피곤하게 사는 건 아닌지하는 생각이 절로 든다. 머리에 꽂은 꽃은 꽃이고 나는 난데 말이다. 그 꽃에 지나치게 에고를 투영하면 투영할수록 투영하는 본인만 피곤해질 뿐이다.

[일상] 리디북스 PC용

Mon, 18 Jul 2016 10:00:01 GMT

여렸을 적에는 컴퓨터 책을 많이 읽었었다. 새뱃돈으로 내가 부린 거의 유일한 사치는 컴퓨터 책을 사는 것이었고, 여자 친구랑 영화를 보러 가서도 컴퓨터 책을 끼고 보면서 눈총을 받기도 했었다. 그 책은(The Art Of Unix Programming) 눈물 없이는 볼 수 없다는 항변을 하는 바람에 더 욕을 먹기도 했었다. 어쨌든 그랬던 나도 언제부턴가 기술 서적을 많이 읽지 않게 되었다. 그러면서 기술 서적에 대한 취향도 다소 바뀌었는데 어렸을 때에는 특정 기술에 대한 세부 사항을 설명하는 책을 많이 읽었다면 지금에서는 그런 책보다는 실용주의 프로그래머, 조엘 온 소프트웨어, 프로그래밍 심리학, Old New Thing, 이펙티브 프로그래밍 등의 이념서나 에세이 류로 분류되는 책을 더 많이 선호한다. 물론 새로운 기술을 접할 때면 개요를 정리한 튜토리얼 성격의 책을 읽기는 하지만 최근에 딱히 새로운 기술이랄만한 것을 접한 기억은 없는 것 같다.

여튼 자랑은 아니지만 고백컨데 기술 서적을 읽은지가 제법 오래된 것 같다. 간간히 아마존에서 영어 공부한답시고 원서 사서는 조금 보다 말고 한게 전부라 마지막으로 감동적으로 읽은 기술 서적이 뭐였는지도 까마득하다. 배꼽잡고 반성을 많이 해야 하는 상황인 것이다. 그랬던 차에 오늘 우연히 삘이 확 꼽히는 책 제목을 보게 되었다. "7가지 동시성 모델"이라는 책이다. 벌써 제목에서 뭔가 반드시 읽어야 할 것 같은 강한 냄새를 풍긴다. 거기다 번역을 무려 임백준님께서 하셨으며, 목차마저도 깨알같았다. 벌써 나는 리디북스에서 구매하기 버튼을 누르고 있었다. PDF라는 표기가 다소 나를 찜찜하게 하긴 했었다. 그리고 구매해서는 폰으로 책을 열었는데 PDF였다. 폰에서 보기에는 너무 조악한 화면.

시원시원하게 27인치 모니터로 흡입해 버리겠어, 라는 마음과 함께 PC용 리디북스 버전을 설치했다. 설치하고 계정 로그인을 했다. 하지만 난 곧 실망할 수 밖에 없었다. 그 책은 아래 화면과 같이 어떠한 이유(아마도 저작권이나 유출등의 문제)로 PC용 버전은 지원이 되지 않는다고 나왔기 때문이다. 이뭐병 ㅠㅜ~ 혹시나 하는 마음에 단 한 차례도 들어가 보지 않았던 윈도우 스토어를 들어가 보았다. 그리고 거기다 리디북스를 쳤지만 그런 앱은 존재하지 않았다.

Figure 1. 리디북스 PC용 버전

그나마 옆에 있는 7인치 태블릿에 리디북스를 설치했다. 폰보다는 볼 만하지만 여전히 만족스럽지는 않다. 그러다 리디북스 페이퍼를 잠깐 살펴봤는데 6인치, 역시 조악할게 뻔하다. 이참에 PDF에 최적화된 태블릿을 사야하나 고민중… 리디북스가 윈도우 스토어를 어서 빨리 지원해 줬으면 하는 바램이다. 애매하긴 하다. 윈도우 스토어도 PC인가?…

심심해서 킨들에서 원서 샘플 다운로드 받아봤는데 퐌타스틱하게 보여진다. 기냥 원서를 샀어야 하는건가? PDF가 만악의 근원인건지 그걸 제대로 보여주지 않는 리디북스 뷰어가 만악의 근원인건지. 내가 그걸 깔끔하게 볼 디바이스를 가지지 않은게 잘못된건지 킁. 여튼 간만에 컴퓨터 책 한 번 읽으려다 심히 좌절중 ㅠㅜ~

[소고] Visual Studio Developer Assistant 플러그인

Wed, 13 Jul 2016 10:00:01 GMT

MS에서 Developer Assistant 플러그인이 이제 C++도 지원한다고 발표했다. Developer Assistant 뭐 이름 그대로 개발자 보조 도구 정도지만 그 녀석이 제공하는 기능을 보면 약간 섬뜩하기도 하다. 기본저인 컨셉은 알려진 접근 가능한 모든 소스 코드의 정보를 토대로 우리가 어떤 일을 Visual Studio에서 코딩하면 되는지 알려주겠다는 것이다. 거창하게 설명하면 이런데 좀 더 쉽게 말하자면 Visual Studio랑 크롬이랑 같이 쓰던거 Visual Studio만 쓰면 되도록 하주겠다는거다. 거기다 크롬에서 검색하는 것보다 좀 더 편하고, 유용하고, 카피하기 편하게 알려주겠다는 취지다.

크롬, 정확하게는 구글이 우리를 대신해서 코딩하기 시작한지는 제법 됐다. 최근에 들어온 한 신입 직원은 거침없이 "구글에 다 있잖아요"라는 이야기를 했었다. 사실 틀린 말은 아니다. 솔직히 까놓고 말해서 구글의 한계가 우리의 한계인 경우가 다반사다. 그런 지경에서 이제와 크롬 대신 그저 IDE에서 조금 편하게 조금 더 씹어먹기 좋게 결과를 보여주겠다는 것 뿐인데 뭐가 대수인가, 라고 생각할지도 모르겠다. 그런데 내가 나이가 들어서 그럴수도 있겠지만 막연한 느낌인데 마냥 좋아보이진 않는다.

내 프로그래머로 경력 초기에는 Visual Studio 버전이 6.0이었다. 지금 생각하면 아주 투박한 프로그램이었다. 거기다 윈도우의 온갖 구조체는 많은데 그놈에 IDE는 점(.)을 찍어도, 화살표를 붙여도(→) 제깍제깍 나에게 어떤 것들이 그 다음에 존재하는지를 알려주지를 않았다. 그 당시에도 Visual Basic은 인텔리센스가 광속이었다. 점을 찍기가 무섭게 너가 그럴줄 알았다는 듯이 목록이 떴었다. 하지만 C++은 달랐다. 마치 C++ 프로그래머는 모든 걸 다 외우라는 MS의 계시처럼 느껴졌다. 그래서 그 당시에 나는 흔한 신입 프로그래머들이 그러듯이 VisualAssist라는 도구를 사용했다. 어시스트를 설치하면 인텔리센스가 그나마 좀 똑똑해졌던 것이다. 게다가 파랑과 검정 밖에 없는 단조로운 Visual Studio의 문법 강조 기능도 훨씬 풍부한 색상으로 변했다.

나는 VisualAssist에 굉장히 만족했었고 내가 작업하는 어떤 환경이든 그걸 설치해서 사용했다. 하지만 회사라는 생태계는 그리 녹록치 않았다. 그시절 그런 툴을 달갑지 않게 바라보는 팀장님이 계셨던 것이다. 그분은 주구장창 나와 같은 프로그래머에게 비난의 화살을 보냈다. 그 편리함에 익숙해지다가 넌 아무것도 모르는 바보 프로그래머가 될 거라고 말이다. 그러면서 자신은 그런 도구 없이 vim, 아니 노트패드로 코딩해도 모든 것을 다 외워서 타이핑 할 수 있다는 이야기를 덧붙였다. 물론 팀장님은 나에게 그리 강력하게 말하진 않았다. 하지만 직속 학교 후배가 몇 분 회사에 있었는데 그 후배들에게는 학교때부터 엄청난 갈굼을 했다는 이야기를 전해들었다. 그때나 지금이나 나는 철학적으로 그 생각에 동의하지 않기에 그러거나 말거나 VisualAssist를 썼다. 그러다 2008 정도 부터는 Visual Studio IDE도 그럭저럭 괜찮은 인텔리센스를 보여줘서 굳이 외부 도구를 설치하진 않는다.

앞선 일화에서 내가 그 팀장님에게 동의하지 않았던 기본 전제는 그것이었다. 외워서 그것을 통째로 타이핑 할 수 있는 능력이 프로그래밍의 본질이 아니라는 것이다. 나는 그것보다는 그 근간에 흐르는 논리적 사고가 더 중요하다고 생각했다. 구조체 멤버를 외우는 것과 외우지 않는 것이 중요하지 않다. 하지만 그 구조체 멤버를 통해서 무엇을 할 수 있을지, 없을지를 판단하는 것이 더 중요하다고 생각했다. 물론 기본적인 사고 회로를 동작시키기 위해서 암기는 필수다. 아무것도 외우지 않고서는 어떠한 사고도 할 수 없을테니 말이다. 즉, 그 팀장님과 나의 결정적 견해 차이는 엄밀하게 말해서 필수적으로 암기해야 하는 것의 범위에 대한 차이였다고 볼 수 있겠다.

그랬던 내가 Developer Assistant를 보면서는 이제 꼰대가 되나보다, 라는 생각을 무척 많이 하게 됐다. 캡처 화면 중에 "How do I …"이란 창을 보고는 말이다. 이제는 프로그래머가 IDE에게 뭘 어떻게 해야 하는지를 물어봐야 하는 세상이 열리려는 순간인 것처럼 보였기 때문이다. 신입 프로그래머들은 그럴지도 모르겠다. 구글에서 검색하던 것이 조금 편리해졌을 뿐이라고. 물론 나는 지금 거기 동의하지만 뭔가 위험한 냄새가 나는 것을 감출 수는 없다. 내 경력 초기에 그 팀장님이 그랬던 것처럼 말이다. 너무 편리한 도구가 프로그래머들의 생각하는 법을 빼앗아갈까봐 두려운 것이다.

전화가 발명됐을 때 사람들은 그랬다. 이제 사람들은 마주보고 이야기하는 법을 까먹게 될거야. 이메일이 발명됐을 때 사람들은 그랬다. 이제 사람들은 서로 음성으로 대화하는 법을 까먹게 될거야. 메신저가 등장했을 때 사람들은 그랬다. 이제 사람들은 뭔가를 기다리는 법을 까먹게 될거야. 하지만 아직 우리는 살아남았고, 더 편리한 세상에서 살고 있다. Developer Assistant를 사용하는 지금의 프로그래머들이 10년 후에는 나랑 비슷한 글을 쓰고 있기를 바란다. 물론 아마도 그때 그들은 알파고에 대한 우려를 표명하고 있겠지만 말이다 ㅋㅋ~

여담이지만 앞선 기술의 진보에 대한 우려가 전혀 기우였던 것은 아니다. 우리는 살아남았지만 어느 정도 그 걱정이 반영된 세상에서 살고 있다. 지금 사람들은 과거 사람들보다 덜 마주보고 이야기하며, 덜 음성으로 대화하고, 덜 기다린다. 그리고 분야에 따라서는 완전히 우리의 기능을 마비시키고 있는 것들도 있다. 큰 누나는 후방 카메라가 없으면 후방 주차를 하지 못한다. 나는 네비게이션 없이는 낮선 장소를 정확하게 찾아갈 수 없다. 그리고 내 가족을 넘어서 우리 모두가 느끼고 있는 분명한 사실은 이제 더이상 그 누구도 전화번호를 기억하지 않는다는 사실이다. 예전에 2-30개씩은 외우고 다니던 것이랑은 정말 대조적이다. 우리는 기술의 혜택을 받았지만 동시에 일정 부분 기계가 대신해 주는 부분에 대해서는 불능 상태가 되고 있다. 그런 점에선 10년전 그 팀장님도 우리가 외우는 걸 양보하는 순간 생각하는 법까지 양보하게 될거라 생각한 것인지도 모르겠다.

언젠가 회사 부장님께서 운전은 장기적으로 승마와 같은 스포츠가 될 것이라는 이야기를 하셨다. 미래 세대는 지금 우리가 승마를 즐기는 것처럼 운전은 서킷에서나 하는 활동에 지나지 않을 것이라는 말씀이었다. 지나가는 농담처럼 한 말이었지만 나는 굉장히 통찰력 있는 이야기라고 생각했다. 또 아마도 그렇게 될 것 같은 느낌이다. 그런 점에서 우리가 기계가 대신해주는 모든 것을 포기했을 때 과연 우리는 무엇을 하고 있을지가 궁금해졌다. 우리 세대는 승마가 없어지고 운전이 생겼다면, 미래 세대는 운전이 없어지고 비행이 생길까? 지금 분위기로 봐서는 그럴 가능성은 별로 없어 보인다. 그저 월e의 한 장면처럼 모두 아무런 활동도 하지 않고 그저 주어진 삶을 사소한 쾌락으로 채우고 있을 것 같다는 느낌 밖에는…

[일상] 봇 전성시대

Fri, 10 Jun 2016 15:00:01 GMT

일전에 조환규 교수님의 칼럼을 굉장히 인상적으로 읽었던 적이 있었다. 로봇을 사람에게 맞추기 보다는 사람을 로봇에게 맞추는 것이 훨씬 쉽다는 관점. 그리고 우리가 조만간 로봇들에게 잘 보여야 할 시대가 올지도 모른다는 이야기. 어쩌면 조금 무시무시한 담론이다. 그러나 어쩌겠는가? 세상이 그렇게 변해가는 것을…

오늘은 또 김창준님의 감동적인 글을 한토막 읽게 되었다. 어쩌면 지금부터 준비해야할지도 모르겠다는 생각이 팍팍 들었다. 그래서 봇 전성시대를 대비해서 나도 몇 자 끄적여 보려고 한다.

서버 공간이 부족한 관계로 자세한 내용은 다음에 서버 공간 늘리고 차차 채우는걸로 ㅠㅜ~

[py] pip 환경 배포하기

Wed, 08 Jun 2016 15:00:01 GMT

파이썬을 사용하면 귀찮은 작업 중에 하나가 환경 바뀌면 라이브러리를 일일이 수동으로 설치해줘야 한다는 점이다. 운영체제를 새로 설치해도 그렇고, 다른 사람에게 알려줄 때에도 그렇다. 그래서 도커를 써야 하나 싶다가도 뭔가 모기 잡으려고 화염방사기 쓰는 것 같은 느낌도 들고, 결정적으로 도커를 모르기도 하고 ㅋㅋ~

물론 이런 경우만 있는 것은 아니다. 이번에 2.7에서 3.5로 갈아타는 것과 같이 다른 환경으로 이동하는 경우도 있다. 이때에는 진짜 정말 찾아서 설치하는 수 밖에 없다. 그래서 스크립트 돌려보고 오류가 발생할 때마다 찾아서 설치하고 있었다. 그런데 "~ 수 밦에 없다"는 나의 착각이었다. pip는 이미 퐌타스틱한 기능을 내장하고 있었다. 잠시 살펴보도록 하자.

pip freeze > requirements.txt

위와 같은 커맨드를 날리는 순간 pip로 설치된 모든 라이브러리의 목록이 requirements.txt에 저장된다. 내가 갈아탄 3.5에서 실행해보니 아래와 같이 나왔다.

click==6.6
Flask==0.11.1
itsdangerous==0.24
Jinja2==2.8
MarkupSafe==0.23
pycrypto==2.6.1
PyExcelerate==0.6.7
PyMySQL==0.7.5
requests==2.10.0
six==1.10.0
slackclient==1.0.0
websocket-client==0.37.0
Werkzeug==0.11.10

이제는 이 requirements.txt만 있으면 일일이 그걸 설치하고 있을 필요가 없다. 바로 "install -r"이라는 마법같은 커맨드가 있기 때문이다. 아래와 같이 입력하면 일괄 설치된다. 넘나 편한것. pip 설치 지원 안 하는 라이브러리는 버려도록 해야겠다.

pip install -r requirements.txt

[py] Python 3.5에서 MySQL 사용하기

Tue, 07 Jun 2016 15:00:01 GMT

파이썬에서 대체로 오라클에서 공개한 mysql.connector라는 것을 사용해서 MySQL 처리를 했었다. 이번에 파이썬 2.7.x에서 3.5로 갈아타면서 라이브러리 설치할 일이 있어서 다운로드를 받으러 갔다. 어랏. 3.3버전용, 3.4버전용은 있는데 3.5버전용이 없다. 뭐 3.4 버전용으로 되겠지라는 안일한 생각으로 그걸 받으려고 하는데, 로그인에 내 개인 정보까지 요구하는 오라클. 순순히 모든 정보를 바쳐가며 다운로드를 받았건만 그건 3.5를 지원하지 않았다. 괜히 3.3, 3.4 이런식으로 세부적으로 있는게 아니었다. 괜한 시간 낭비…

그래서 검색을 좀 해봤더니 오라클 따위거를 쓰지 않아도 대체제가 있었다. 그 중에 하나가 pymysql이다. 설치도 넘나 간단하다. pip에 다음과 같이 입력하면 끝.

pip install pymysql

사용 방법은 뭐 mysql.connector와 거의 유사하다. 아니 똑같다고 생각하면 될 정도? 아래와 같은 느낌으로 사용하면 된다.

import pymysql

conn = pymysql.connect(host='호스트', port=포트, user='유저', password='비번', database='디비')
cursor = conn.cursor()
cursor.execute('sql 쿼리')
res = cursor.fetchall()
conn.close()

[py] Python 3.5의 pycrypto 임포트 문제 해결

Mon, 06 Jun 2016 15:00:01 GMT

파이썬에서 암호화를 하려면 pycrypto 라이브러리를 사용하면 된다. pip install pycrypto 하면 문제없이 설치되는데 사용하는데 약간의 문제가 있다. Python 3.5가 설치된 환경에서 pip로 인스톨을 하고 아래와 같이 Random을 임포트 하려면 winrandom을 찾을 수 없다는 오류가 발생한다. 파이썬3로 변경되면서 모듈 포함하는 규칙이 바뀌어서 그런 것 같은데 수정하는 방법은 간단하다.

# c:\Python35>python
# Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:18:55) [MSC v.1900 64 bit (AMD64)] on win32
# Type "help", "copyright", "credits" or "license" for more information.
>>> from Crypto import Random
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "c:\Python35\lib\site-packages\Crypto\Random\__init__.py", line 28, in <m
odule>
    from Crypto.Random import OSRNG
  File "c:\Python35\lib\site-packages\Crypto\Random\OSRNG\__init__.py", line 34,
 in <module>
    from Crypto.Random.OSRNG.nt import new
  File "c:\Python35\lib\site-packages\Crypto\Random\OSRNG\nt.py", line 28, in <m
odule>
    import winrandom
ImportError: No module named 'winrandom'
>>>

우선 문제가 된 위치의 파일을 찾아간다. c:\Python35\lib\site-packages\Crypto\Random\OSRNG\nt.py 이 파일이다. 해당 파일을 열면 아래와 같이 임포트를 하고 있는 것을 볼 수 있다.

import winrandom

위 코드 앞에 "from . "을 붙여주면 된다. 고치면 아래와 같은 코드가 된다. 수정된 내용을 저장하고 다시 임포트시켜 보면 잘 되는 것을 알 수 있다. 배터리는 준비돼 있지만 자질구레하게 손이 가는 곳이 많다. 그래도 배러뤼가 있는게 어딘가?

from . import winrandom

[소고] 천재성에 관한 통찰

Sun, 05 Jun 2016 15:00:01 GMT

회사를 시작한지 한 10년 되다보니 만난 직원이 이제는 제법 된다. 그 중에서도 엔지니어로 일하는 직원들에게는 동병상련같은 감정을 많이 느낀다. 나도 그들과 같은 길을 지나왔고, 어쩌면 지금도 그 길을 가고 있기에 비슷한 생각을 많이 하고 또 유사한 고민도 많이 했기 때문이리라. 그런 직원들의 흔한 고민 거리 중에 하나가 주위의 똑똑한 사람과 자신을 비교하면서 생기는 자괴감이다. 한 직원은 이렇게 말하기도 했었다. 한달 내도록 주위를 보면서 '나는 뭔가’라는 생각에 멘탈이 탈탈 털리다가 그나마 입금되는 월급보고 충전된다고…

사실 누구나 쉽게 예상하겠지만 우리 회사에는 다들 고만고만한 사람들이 모여서 일을 한다. 물론 경쟁 업체보다는 많이 똑똑한 엔지니어들을 가려 뽑았다는 자부심은 있다. 하지만 대다수가 비슷비슷하지 크게 다르지 않다. 그런데도 직원들의 상당수, 예외적인 사람 일부를 제외한 거의 대부분은 그 사이에서 비교를 하고 그 과정에서 자연스레 발생하는 불필요한 열등감으로 자신을 갉아 먹는다. 나는 대체로 김난도 선생의 비유를 들어 저마다의 시간이 있으니 굳이 비교할 필요 없이 각자의 길을 가면 된다는 조언을 당당하게 해주지만 어쩌면 이 또한 위선적인 모습인지도 모르겠다. 왜냐하면 나도 제법 프로그래밍을 했을 무렵 비슷한 고민에 빠졌었기 때문이다.

최근에 "사피엔스" 이후로 엄청난 감탄을 하면서 읽은 책이 있었는데 "틀리지 않는 법"이라는 수학 책이다. 그 책의 천재성에 관한 저자의 견해 일부가 워낙 감탄스러워 여기 발췌해 본다. 아마 저자의 말처럼 이 교훈은 분야를 막론하고 비슷한 고민을 하는 거의 모든 사람들에게 적용되는 조언인 것 같다.

수학을 오래 하다 보면 깨닫게 되는 것은(그리고 나는 이 교훈이 훨씬 더 폭넓게 적용될 것이라고 생각한다) 당신보다 앞선 사람은 늘 있다는 사실이다. 당장 같은 교실에 있든 아니든 말이다. 이제 막 시작한 사람은 좋은 정리를 증명한 사람을 바라보고, 좋은 정리를 증명한 사람은 좋은 정리를 많이 증명한 사람을 바라보고, 좋은 정리를 많이 증명한 사람은 필즈상을 받은 사람을 바라보고, 필즈상을 받은 사람은 수상자들 중에서도 〈핵심〉에 속하는 사람을 바라보며, 그런 사람은 또 언제나 죽은 사람들을 바라볼 수 있다. 거울을 보면서 〈인정하자, 나는 가우스보다 똑똑해〉라고 중얼거리는 사람은 세상에 한 명도 없다. 그런데도 가우스에 비하면 전부 바보인 사람들이 지난 백 년 동안 힘을 합쳐 노력함으로써 역사상 가장 풍성한 수학 지식을 일구어 냈다.

수학은 대체로 공동 사업이다. 공통의 목표를 추구하는 거대한 지적 네트워크가 만들어 낸 산물을 각자가 조금씩 더 발전시킨다. 비록 아치를 완성하는 최후의 돌을 얹은 사람이 특별한 영예를 누리기는 하지만 말이다. 마크 트웨인은 이 점을 다음과 같이 잘 표현했다. <전신이나 증기 엔진이나 축음기나 전화처럼 중요한 물건을 발명하는 데는 천 명의 사람이 필요했지만, 공은 마지막 사람이 다 차지하고 우리는 나머지 사람들을 잊어버립니다.

이것은 풋볼과도 비슷하다. 물론 한 선수가 경기를 완전히 장악하는 순간이 있기는 하다. 우리가 이후 오래도록 기억하고 기념하고 회상하는 것은 그런 순간들이다. 그러나 그것은 풋볼에서 보통의 상태가 아니고, 이기는 경기라도 대부분은 그런 순간 때문에 이기는 게 아니다. 쏜살같이 달려 나가는 와이드 리시버에게 쿼터백이 눈부신 터치다운 패스를 하는 데 성공했을 때, 우리는 많은 사람들의 협동 작업을 보는 것이다. 쿼터백과 리시버뿐 아니라 수비팀이 뚫고 들어오는 것을 막아서 쿼터백이 제대로 자세를 잡고 던지도록 시간을 벌어 준 공격팀 라인맨들이 있었고, 그 방어는 또 결정적인 순간에 수비팀의 주의를 흩뜨리기 위해서 핸드오프를 하는 척했던 러닝백 덕분에 가능했으며, 그 밖에도 경기를 조직한 공격팀 감독, 클립보드를 든 그의 많은 조수들, 선수들이 잘 뛰고 던질 수 있도록 돌봐 준 훈련 스태프들… 우리는 이 사람들을 다 천재라고 부르진 않는다. 그러나 그들은 천재성이 벌어질 수 있는 조건을 만들었다.

테리 타오는 이렇게 썼다.

흔히 떠올리는 고독한(게다가 약간 미쳤을 수도 있는) 천재의 이미지, 즉 기존 문헌을 비롯한 관습적인 지혜들을 무시한 채 남에게 설명할 수 없는 영감에 따라(어쩌면 듬뿍 가해진 고통이 그 영감을 더욱 강화할 수도 있다) 모든 전문가가 골머리를 썩였던 문제에 대해서 놀랍도록 독창적인 해답을 찾아내는 사람의 이미지는 매력적이고 낭만적이지만, 한편으로는 터무니없이 부정확하다. 적어도 현대 수학의 세계에서는 그렇다. 우리는 물론 수학에 대해서 근사하고 심오하고 놀라운 결과들과 통찰들을 갖고 있지만, 그것은 많은 훌륭하고 위대한 수학자들이 수 년, 수십 년, 심지어 수백 년에 걸쳐서 착실히 연구하고 발전시켜 온 끝에 힘들게 얻어낸 누적적 성과이다. 이해의 한 단계에서 다음 단계로 넘어가는 발전은 굉장히 중대한 사건일 수도 있고 심지어 누구도 예상하지 못했던 사건일 수도 있지만, 그래도 그것은 완전히 새롭게 시작된 작업이 아니라 이전 연구들의 토대 위에 구축된 작업이다. …나는 오늘날 수학 연구의 현실이, 즉 직관과 자료와 약간의 행운에 따라 열심히 노력한 결과로 발전이 자연스럽게, 또한 누적적으로 생겨나는 현실이 내가 학생 때 품었던 낭만적 이미지, 즉 수학은 주로 희귀한 〈천재들〉의 신비로운 영감에 따라 발전한다는 이미지보다 훨씬 만족스럽다고 느낀다.

힐베르트를 천재라고 부르는 건 틀린 말이 아니다. 그러나 그보다는 힐베르트가 해낸 일이 천재적이었다고 말하는 게 더 옳다. 천재성은 어떤 발생한 사건이지, 어떤 종류의 사람이 아니다.

-- 틀리지 않는 법

조금 실용적인 관점에서 다른 분야에 관한 조언이지만 조엘의 이야기도 곁들여 보면 좋겠다. 조엘은 작은 회사를 운영하는 것에 관해서 쓴 것이지만 나는 개인적으로 이 견해가 개인의 발전과 성장에 관한 것이어도 무관하다고 생각한다. 오늘 하루 아주 조그마한 것이라도 새로운 것을 알아냈다면 그걸로도 만족할만한 일이다. 굳이 거창할 필요도 없고, 조급할 필요도 없다. 안그래도 짧은 인생, 스트레스 받으면서 살지는 말자.

저처럼 작은 회사를 운영한다면, 쏘면서 움직이는 방법은 두 가지 사항을 의미합니다. 장기적인 안목을 키워야 하며, 매일 조금씩 앞으로 나아가야 합니다. 이렇게 하다보면 조만간 당신이 이길 것입니다. 어제 하루동안 제가 한 일이라고는 FogBUGZ에서 컬러 정책을 조금 개선한 사항뿐입니다. 이 정도면 충분합니다. 조금씩 발전해 나가는 겁니다. 날이 갈수록 우리 소프트웨어는 점점 더 좋아지며, 더 많은 고객을 확보할 수 있다는 점을 노릴 뿐입니다. 오라클 정도로 큰 회사가 되고 난 다음에 거대한 전략을 생각해도 늦지 않습니다. 매일 아침 출근해서 에디터를 여는 것만으로도 충분합니다.

-- 조엘 온 소프트웨어

[시스템] 엑셀의 한계

Sat, 04 Jun 2016 15:00:01 GMT

대체로 잘 짜여진 프로그램의 많은 부분들의 한계는 대체로 메모리 한계로 주어지는 경우가 많다. 심지어 스와핑해가며 메모리 한계보다 더 많은 데이터를 처리할 수 있도록 해주는 프로그램들도 있다. 그래서 그랬는지 늘 그저 엑셀은 잘 만든 프로그램이니까 행의 개수나 셀에 들어간 글자수 따위에는 제한이 없을거야, 라는 생각을 많이 했었다. 최근에 회사에서 사용하는 엑셀 시트 생성 파이썬 스크립트의 문제를 수정하면서 나는 내 가설이 옳지 않다는 것을 알게 되었다. 생각보다 엑셀에는 제약이 많았다.

여기를 참조하면 MS에서 발표한 엑셀의 공식 한계치들을 알 수 있다. 별 대수롭지 않게 생각할 수 있는데 우리 시트가 깨지는 문제의 원인은 행의 개수때문이었다. 행 개수 제한이 대략 105만개인데 실제로 테스트 해 본 바에 의하면 이것보다 적은 데이터도 엑셀이 정상적으로 열지 못하는 경우가 있어서 100만개로 제한을 걸어두었다. 그 다음으로 다소 황당했던 제한은 셀에 포함될 수 있는 글자수다. 이는 32767개로 제한하고 있다. 그런데 지금 해당 페이지에서 보여주고 있는 제약 사항은 그마나 최신 엑셀 프로그램의 제약 사항들이다. 신뢰할 수 있는 자료인지는 모르겠으나 이 페이지를 보면 과거 버전은 더 많은 제약 사항을 가지고 있었던 것 같다.

사족: 대략 생성된 엑셀 파일은 80메가 정도 크기였다. 정상이라면 통상적으로 엑셀 실행 시에 데이터가 손상되었다는 메시지가 뜨는데, 테스트 과정 중에 이 메시지 만큼이나 자주 엑셀이 잘못된 연산으로 종료되는 것을 목격했다. 지구상에서 소프트웨어를 가장 잘 만드는 회사 중 하나인 MS 제품도 이 정도다. 소프트웨어 개발은 실제로는 우리가 생각하는 것보다 훨씬 어려운 것 같다.

[py] retr에서 발생한 line too long 예외 처리하기

Fri, 03 Jun 2016 15:00:01 GMT

파이썬에서 poplib을 사용해서 POP3로 메일을 받아올 때 retr 함수를 사용한다. 보통은 잘 되는데 어쩔 때 이 함수에서 웃기게도 "line too long"이란 예외가 발생한다. 찾아가보면 아래와 같은 지점에서 예외를 던지는 것을 발견할 수 있다. 이 경우에 옵션은 두 가지다. 하나는 그냥 그 메시지를 무시하거나 다른 하나는 라인을 더 늘리거나.

def _getline(self):
	line = self.file.readline(_MAXLINE + 1)
	if len(line) > _MAXLINE:
		raise error_proto('line too long')

서버가 던져주는 메시지를 무시하기는 힘들다. 그래서 라인을 늘리려고 찾아가보면 아래와 같이 자뻑형 주석과 함께 있는 상수 선언 부분을 찾을 수 있다. RFC 1939는 512글자로 제한하고 있지만 우리는 더 안전하게 하기 위해서 2048을 택했지라는 ㅋㅋㅋ 하지만 행님들 현실 세계에서는 2048로는 부족하긔~ 나는 대인배니까 값을 그냥 20480으로 변경했다 ㅋㅋㅋ~ 당연한 얘기겠지만 고치고 나자 서버로부터 모든 메시지를 안전하게 수신할 수 있었다. 지금으로썬 딱히 이 상수를 변경하는 것 외에는 방법이 없는 것 같다.

# maximal line length when calling readline(). This is to prevent
# reading arbitrary length lines. RFC 1939 limits POP3 line length to
# 512 characters, including CRLF. We have selected 2048 just to be on
# the safe side.
_MAXLINE = 2048

[py] 이메일 시간(Date) 타입 다루기

Thu, 02 Jun 2016 15:00:01 GMT

파이썬에서 email.message_from_bytes(데이터)로 획득한 메시지의 시간을 다루는 방법을 알아보자. message_from_bytes로 메일 객체를 msg에 저장했다고 가정한다.

우선 시간은 msg['Date']에 들어있다. 늘 그렇듯이 RFC 형식에 맞춰진 필드 정보지만 바로 datetime으로 바꾸기는 쉽지가 않다. 이때 쓸 수 있는 함수들이 email.utils에 있다. 바로 parsedate_tz와 mktime_tz다. 조합해서 만들어보면 msg 객체의 Date를 안전하게 datetime으로 변환하는 방법은 다음과 같다.

from email.utils import parsedate_tz, mktime_tz
timestamp = mktime_tz(parsedate_tz(msg['Date']))

이렇게 획득한 타임스탬프 갚은 datetime의 fromtimestamp로 변환해서 사용하면 된다.

[cpp] UTF-8 INI 파일 다루기

Wed, 01 Jun 2016 15:00:01 GMT

A/W 함수

윈도우 API는 문자열을 다루는 경우에 크게 두 종류의 함수를 제공한다. A/W 함수가 그것이다. A 함수는 멀티바이트로 문자열을 처리하는 함수를 의미하고, W 함수는 UTF-16 방식으로 문자열을 처리하는 함수를 의미한다. A 함수는 파라미터 타입으로 char를 W 함수는 wchar_t를 사용하기 때문에 크게 헷갈릴 일도 없고 직관적이다.

윈도우는 기본적으로 제공하는 ini 파일 조작 API 관련해서 아래와 같이 이런 두 종류의 API를 제공하고 있다.

WINBASEAPI
DWORD
WINAPI
GetPrivateProfileStringA(
    __in_opt LPCSTR lpAppName,
    __in_opt LPCSTR lpKeyName,
    __in_opt LPCSTR lpDefault,
    __out_ecount_part_opt(nSize, return + 1) LPSTR lpReturnedString,
    __in     DWORD nSize,
    __in_opt LPCSTR lpFileName
    );

WINBASEAPI
DWORD
WINAPI
GetPrivateProfileStringW(
    __in_opt LPCWSTR lpAppName,
    __in_opt LPCWSTR lpKeyName,
    __in_opt LPCWSTR lpDefault,
    __out_ecount_part_opt(nSize, return + 1) LPWSTR lpReturnedString,
    __in     DWORD nSize,
    __in_opt LPCWSTR lpFileName
    );

그렇다면 ini 파일의 포맷은?

GetPrivateProfileStringA 함수를 사용하면 멀티바이트 형태로 내가 원하는 값들을 지정하고 거기에 해당하는 결과 값을 멀티바이트 형태로 받을 수 있다. 반대로 GetPrivateProfileStringW 함수를 사용하면 UTF-16 형태로 지정하고 결과를 받을 수 있다. 여기까지만 생각하면 심플하고 복잡할 것도 없지만 조금만 더 호기심을 가져보면 뭔가 애매모호한 것들이 많다. 바로 파일의 형태다.

lpFileName으로 지정하는 파일은 어떤 형태여야 할까? 어떤 코드페이지로 작성된 멀티바이트 ini 파일도 딱딱 맞춰서 읽을 수 있을까? UTF-8 UTF-16 등으로 작성된 유니코드 파일도 마법처럼 인식해줄까? 아니면 A 함수는 멀티바이트 ini 파일에만 써야 하고 W 함수는 UTF-16 ini 파일에만 써야 할까? 등등의 무수히 많은 질문이 올 수 있다.

아마 대부분의 프로그래머가 해당 API를 사용하면서 그런 의문을 품지는 않았을 것 같다. 왜냐하면 대충 쓰면 적당히 동작하기 때문이다. 그래서 그런지 MSDN에도 lpFileName으로 지정할 수 있는 파일의 형태에 대해서는 어떠한 언급도 없다. 하지만 컴퓨터의 세계에서 적당히 대충은 항상 문제를 일으킨다. 그래서 조금 깊이 있게 살펴보자.

윈도우에서 제공하는 ini 파일을 다루는 API는 딱 두 종류의 파일에 대해서만 처리할 수 있도록 설계되어 있다. 하나는 시스템 코드페이지로 작성된 멀티바이트(ANSI) ini 파일이고, 다른 하나는 UTF-16으로 작성된 ini 파일이다. 이는 A/W 함수에 상관 없이 사용된다. ini API 내부적으로 파일을 열 때에 RtlIsTextUnicode를 사용해서 파일에서 읽은 내용이 UTF-16인지 아닌지를 판별한다. UTF-16인 경우에 A 함수를 호출하면 파라미터를 RtlAnsiStringToUnicodeString 함수를 사용해서 변환해서 사용하고, 멀티바이트 파일이 인 경우에 W 함수를 호출하면 반대로 RtlUnicodeStringToAnsiString 함수를 사용해서 파라미터를 내부적으로 변환한다.

UTF-8 ini 파일을 다루는 방법

그렇다면 윈도우 ini API를 사용해서 UTF-8 ini 파일을 다룰 수는 없는 것일까? 결과론적으론 그렇다. 왜냐하면 API 내부적으로 UTF-8 변환을 지원하지 않기 때문이다. 하지만 대체로 많은 경우에 섹션 이름이나, 키 이름 같은 경우는 영어를 사용하는 것이 관례이고, 키에 해당하는 값에만 ANSI 문자가 아닌 다른 문자가 포함되는 경우가 많다. 이렇게 한정된 조건을 가진 UTF-8 ini 파일의 경우에는 윈도우 ini API를 사용해서 조작하는 것이 가능하다.

사용하는 방법은 간단하다. W 함수를 사용하면 안 된다. 왜냐하면 내부적으로 UTF-8로 인코딩 된 것을 UTF-16으로 디코딩하려고 시도할 것이기 때문이다. 그러니 무조건 A 함수를 사용하고 받은 멀티바이트 결과 값을 MultiBytesToWideChar 등의 함수로 UTF-8을 디코딩해서 UTF-16 문자열로 처리하면 된다.

요약하면 저장할 때에는 유니코드 문자열을 UTF-8로 인코딩한 다음 ini A계열 함수를 사용해서 저장하면 되고, 읽을 때에는 ini A계열 함수를 사용해서 읽은 값을 UTF-8로 디코딩해서 유니코드 문자열로 변환해서 사용하면 반쪽짜리 UTF-8 ini 파일을 처리할 수 있다.

[정보] XIGNCODE에 관한 오해 2

Mon, 28 Mar 2016 15:00:01 GMT

듀얼 프로텍션

게임사의 고유 보안 프로그램과 외부 보안 프로그램을 같이 쓰는 것은 어느 한 쪽의 성능이 나쁘기 때문만은 아닙니다. 당연한 일이겠지만 여러분이 집을 보호한다고 할 때 보안은 여러 단계에 걸쳐서 이루어지면 이루어질수록 좋기 때문입니다. 대문에도 경비를 두고, 거실 입구에도 경비를 두고, 안방 문 앞에도 경비를 둘 때, 단순히 대문 앞에만 경비를 둔 것 보다는 도둑이 침입하기 더 어려운 것과 같은 이유입니다. 거기다 외부 보안 솔루션의 경우 게임 내부를 볼수는 없기 때문에 일정 수준 게임 내부와 밀접하게 연계된 부분을 검사하는데에는 한계가 있을 수 밖에 없습니다. 이런 부분에 대해서는 게임사 내부에서 직접적으로 보안 코드를 작성하는 것이 효율적이기 때문에 두개의 보안 장치를 만들어서 사용하고 있는 추세입니다.

스팀 연동

XIGNCODE3는 스팀 게임과 연동을 지원합니다. 과거에 스팀에 연동된 게임이 있으며 현재에도 연동해서 사용하는데에 아무런 문제가 없습니다. 현재에도 스팀에서 서비스 중인 게임이 있습니다. 스팀 연동이 불가능하다는 것은 사실이 아닙니다.

게임을 삭제해도 xhunter1.sys는 계속 상주한다?

xhunter1.sys 드라이버는 게임을 켜면 로드되고 게임을 종료하면 언로드 됩니다. 해당 사실은 driverview 등의 프로그램을 이용하면 손쉽게 확인할 수 있습니다. 게임 실행 후에 목록을 보면 xhunter1.sys가 로드돼 있고, 게임 종료 후에 보면 xhunter1.sys가 시스템에서 언로드 됩니다. 시스템에 지속적으로 남아서 모니터링을 하거나 CPU 자원을 소모하거나 하지 않습니다.

차단 근거 미표시

지난 글에서도 적었지만 현재 서비스 중인 게임 중에도 아래와 같이 차단 근거가 표시되도록 설정된 게임도 존재합니다. 따라서 차단 근거를 무조건적으로 표시하지 않는다는 사실은 잘못된 사실입니다. 해당 사항은 옵션으로 처리돼 있으며 표시할 수도 있고, 하지 않을 수도 있는 사항입니다.

se Figure 1. CheatEngine이 차단된 경우의 표시 화면 윈도우 10 지원 윈도우 2000을 제외한 윈도우 XP부터 윈도우 10까지 모든 윈도우 버전을 정식 지원하고 있습니다. 따라서 XIGNCODE3 때문에 윈도우 10에서 게임을 정상적으로 구동할 수 없다는 것은 사실이 아닙니다.

스플래시 이미지

스플래시 이미지는 고객사에서 설정할 수 있는 옵션 사항입니다. 홈페이지에 소개된 상당수 이미지가 고객사에서 직접 제작한 스플래시 화면입니다. 스플래시 화면을 지정하지 않을 경우 기본 이미지가 출력되며, 고객사에서 스플래시 이미지를 설정을 원하는 경우 해당 이미지를 사용하고 있습니다. 이 또한 옵션 사항입니다. "대표 이미지 채택 이벤트"라는 이벤트는 진행된적이 없습니다.

출시일?

XIGNCODE는 2007년 2월에 개발 시작하였으며, 2008년 3월에 1.0 버전이, 2009년 3월에 2.0 버전이, 2010년 6월에 지금의 XIGNCODE3 버전이 출시되었습니다. 2013년 3월에는 안드로이드 제품인 "XIGNCODE for Android"가 출시되었습니다.

[정보] XIGNCODE 디지털 서명에 관한 오해

Mon, 28 Mar 2016 14:00:01 GMT

커널 모드 드라이버 개발을 하는데에 디지털 서명은 필수적입니다. 왜냐하면 64비트 운영체제 부터는 합법적으로 서명이 되지 않은 드라이버는 동작하지 않기 때문입니다. 즉, 아무리 잘 만들어 놓은들 디지털 서명을 받지 않았다면 컴퓨터에서 로드해서 사용할 수 없다는 이야기입니다. 그러니 응당 디지털 서명은 기본 중의 기본이겠지요. 저희가 제공하는 파일 중에 사용자가 접할 수 있는 모든 파일은 VeriSign 인증서를 통해서 서명이 된 후에 배포됩니다. 그러니 적합하지 않은 형태로 디지털 서명이 되어 있다거나 디지털 서명이 되어 있지 않다거나 하는 이야기는 사실이 아닙니다.

Figure 1. xhunter1.sys 파일의 등록 정보

Figure 2. xhunter1.sys 디지털 서명 정보

Figure 3. xhunter1.sys 디지털 서명 인증 경로

더욱이 64비트 윈도우 부터는 오브젝트 필터링 콜백이라는 것을 사용하기 위해서는 마이크로소프트에 용도를 통보한 후에 고도를 할당 받아서 사용해야 합니다. 이것은 상기 디지털 서명처럼 반드시 해야 하는 일은 아니지만 정상적인 업체라면 해야 하는 그런 일 입니다. 당연히 저희 또한 마이크로소프트 측에 드라이버의 용도에 관한 통보를 했고 해당 고도를 할당 받아서 사용하고 있습니다. 이는 마이크로소프트 홈페이지를 참고하시면 아래와 같이 정보가 노출되는 것을 알 수 있습니다.

Figure 4. xhunter1.sys 오브젝트 필터링 콜백 고도

추가로 인증서 유효 기간에 대해서 말씀 드리면 인증서의 동작 방식은 인증서가 유효한 기간 내에 서명이 된 것인지를 체크하는 구조입니다. 따라서 아래 파일을 보면 인증서가 2014.1.23부터 2016.3.24까지 유효한데 파일은 2015.6.4에 인증되었다는 것을 나타냅니다. 이 파일의 경우 인증서 유효 기간이 지난 후에도 정합성을 인정 받는 파일입니다. 따라서 드라이버 코드가 변경되지 않는 이상 인증서 때문에 새로운 파일을 배포 하거나 할 필요는 없습니다. 더 자세한 내용이 궁금하신 분들은 마이크로소프트 설명 페이지를 참고하시면 됩니다.

Figure 5. xhunter1.sys 디지털 서명 인증서 유효기간

그리고 더 많은 기술적인 설명이 필요한 내용인데 드라이버를 정상적인 방식으로 로드하기 위해서는 반드시 레지스트리에 그 값을 기록해야 합니다. 그래야 윈도우에서 그 정보를 알고 드라이버를 로드해 주기 때문입니다. 더 자세한 내용을 설명하기 위해서는 너무 많은 기술적인 내용을 설명해야 하기에 이쯤에서 줄이도록 하겠습니다.

그러니 더 이상 디지털 서명이 잘못된 파일이라던지 드라이버가 잘못된 형태로 운용되고 있다는 오해는 가지지 않았으면 하는 바램입니다.

[정보] XIGNCODE 요구 권한에 관한 오해

Sat, 26 Mar 2016 14:00:01 GMT

권한에 관해서 궁금해 하시는 분들이 많이 계신 것 같습니다. 도대체 왜 일게 서드파티 보안 프로그램이 그것도 시스템의 모든 곳에 접근할 수 있는 "관리자 권한"을 요구하는지에 대해서 의문이 없다면 그게 더 이상한 일일 겁니다. 저라도 당연히 의문을 가졌을 것 같습니다. 그래서 오늘은 그런 권한에 얽힌 오해를 조금 풀어보려고 합니다.

권한이란 무엇이고 왜 필요할까?

이 글을 컴퓨터에 관한 전문 지식이 없는 분들도 보실 수 있기에 권한 이라는 것이 정확하게 어떤 것이고 왜 필요한지에 대해서 먼저 설명을 드려야겠습니다. 권한은 쉽게 말하면 방문을 여는 키와 같다고 보시면 됩니다. 집에 방이 세 개 있다고 가정해 봅시다. A, B, C라는 방이죠. 여기에서 아빠는 A, B, C에 모두 들어갈 수 있는 키를 가지고 있고, 아들은 C 방에 들어가는 키만 가지고 있습니다. 이 상황에서 모든 방을 다 들어가 볼 수 있는 사람(여기에서는 아빠)를 관리자 권한이라고 부르며, 일부 제한된 자신의 접근 구역에만 접근할 수 있는 사람(여기에서는 아들)을 사용자 권한이라고 통상적으로 부릅니다. 집에서는 아빠는 잠겨 있는 모든 방에 접근할 수 있지만, 아들은 C에만 접근할 수 있습니다. A, B가 궁금해도 키가 없으니 접근을 하지 못하는 것이죠. 컴퓨터에서도 마찬 가지입니다. 어떤 파일을 읽기 위해서는 권한이 필요합니다. 거의 대부분의 파일을 읽을 수 있는 권한이 관리자 권한, 자신의 파일만 읽을 수 있는 것이 사용자 권한이죠.

자 이제 앞의 상황에서 도둑이 들어서 어떤 방에 숨어있다는 다소 엉뚱하면서도 황당한 상상을 해 봅시다. 도둑이 A나 B 방에 숨고, 문을 잠궈버렸다면 아들은 도둑을 발견할 수 있을까요? 없을까요? 당연히 없을 겁니다. 반대로 C 방에 숨었다면 아들도 발견할 수 있습니다. 하지만 아빠의 입장은 다릅니다. 도둑이 어디에 숨어있든지 방문을 열고 볼 수 있기 때문에 도둑을 찾을 수 있습니다. 결국 권한이 높다는 것은 더 많은 것을 찾고 발견할 수 있다는 것을 의미합니다.

게임 보안 솔루션이 권한을 요구하는 것도 동일합니다. 매크로나 해킹툴을 사용하여 게임 경험을 해치는 불법 사용자를 가려내는 것이 저희의 임무입니다. 권한이 낮다면 앞에서 아들과 같이 불법 사용자가 C방에 숨은 경우만 찾아낼 수 있습니다. 반대로 관리자 권한을 가졌다면 어디에 숨어있든지 찾아낼 수 있을 겁니다.

빈대 잡으려다 초가삼간 태우는게 아닌가?

이런 권한의 메커니즘을 이해한 다음의 문제는 조금 철학적입니다. 높은 권한이 있다면 더 많은 부분을 검사해서 발견해 낼 수 있다는 건 알겠지만 그게 과연 옳은 결정이냐는 것입니다. 여기에 대한 가치 판단은 저마다 다르고 상황마다 다를 수 있습니다.

일반적으로 해킹툴이 별로 없고 거의 대다수 사용자가 정상 플레이를 하고 있는 게임이라면 당연히 권한을 최소한으로 요구하는 것이 맞을 겁니다. 왜냐하면 게임 플레이를 하면서 해킹툴 사용자를 만날 일도 별로 없는데 높은 권한으로 많은 검사를 할 필요가 없기 때문입니다. 반면에 해킹툴이 너무 많고 거의 대부분의 사용자가 어떻게든 불을 켜고 해킹툴을 사용하려는 게임이라면 관리자 권한을 요구할 수도 있을 겁니다. 물론 관리자 권한을 요구한다고 그런 모든 것을 발견하고 막을 수는 없겠지만 어쨌든 발견할 수 있는 확률은 높아지니까요.

결국 요약하면 이런 겁니다. 높은 권한은 해킹툴을 발견할 가능성이 높아지지만 사용성이 떨어지고, 낮은 권한은 해킹툴을 발견할 가능성은 낮아지지만 사용성은 높아지는 겁니다. 즉, 이는 어떤 한 가지를 일방적으로 고수할 문제가 아니라 그 사이에서 게임 운영자가 자신들의 게임에 맞게 적당히 절충하면 되는 문제입니다. 음, 우리 게임은 해킹툴 사용자가 너무 많으니까 지금 당장은 높은 권한을 유지해서 발견 가능성을 높이자라던지, 아니면 우리 게임은 거의 대부분이 선량한 사용자니까 낮은 권한으로 하돼 추후 문제가 생기면 다시 조정하겠다는 것과 같이 말이죠. 결국 여기에는 절대적으로 옳은 정답은 없으며 각각의 상황에 맞춰서 해킹툴 발견 가능성과 사용성 중에서 어느 것을 더 중시할지를 고르면 되는 문제입니다.

옵션

결국 앞의 절충의 문제라는 것 까지 이해했으면 솔루션 개발자 입장에서의 정답은 무엇일까요? 옵션입니다. 게임 운영자가 자신의 게임 특성에 맞춰서 적절하게 설정해서 사용할 수 있도록 만들어 주는 것이죠. 고정해 놓는 것이 아니라 변동 가능하도록 구성하는 겁니다. XIGNCODE3도 마찬가지 입니다. 다양한 고객사들의 입맞에 맞추기 위해서 권한 레벨을 아래와 같이 세 분류로 조정해서 적절하게 설정해서 사용할 수 있도록 가이드를 해드리고 있습니다. 낮음으로 사용하시길 원하는 경우에는 게임 권한 설정에 따라서는 아예 "관리자 권한"을 요구하지도 않으며 "커널 모드 드라이버"를 설치 및 로드하지도 않습니다. 보통 단계는 얻을 수 있는 상황인데 얻지 못하면 페널티가 주어지는 것이며, 높음 단계는 항상 "관리자 권한"을 요청하는 단계입니다. 그러니 저희가 무조건적으로 "관리자 권한"을 요구한다는 것은 정확한 사실이 아니라는 점 꼭 기억해 주셨으면 좋겠습니다.

XIGNCODE3 권한 범위

[정보] XIGNCODE에 관한 오해들

Fri, 25 Mar 2016 15:00:01 GMT

최근 게임 커뮤니티에서 저희 제품에 대한 오해가 많이 생기고 있는 것 같습니다. 게이머들이 좋아하는 보안 제품을 만드려고 했는데 오해만 잔뜩 키운것 같아서 한 명의 게이머로써 착찹한 생각이 많이 듭니다. 건설적인 비판은 새겨 들어야겠지만 원색적인 비난이나 잘못된 사실로 인한 오해는 바로 잡을 필요가 있다고 생각됩니다. 특히나 최근 제 개인 메일이나 블로그 댓글로 문의가 많이 와서 여기에 최근 게이머들 사이에서 유통(?!)되고 있는 대표적인 몇 가지 오해에 대한 해명을 해볼까 합니다.

SSD 수명을 단축시킨다.

일반적으로 SSD의 경우 재기록 가능 회수가 한정되어 있습니다. 재기록 가능 회수란 쉽게 말하면 점토판에 쓰여진 내용을 지우고 다른 내용을 기록하는 것을 말합니다. 그 회수가 10번이라면 지우고 새로운 내용을 기록하는 것을 10번하고 나면 새 점토판을 사야 한다는 의미입니다. 여기에서 중요한 것은 내용을 지우고 새로 기록하는 회수가 한정되어 있다는 의미입니다. 따라서 적혀져 있는 내용을 읽는 것과 수명은 크게 상관이 없습니다.

일반적인 보안 프로그램의 경우 디스크에 존재하는 프로그램의 정체(?!)를 파악하기 위해서 해당 파일의 내용을 읽습니다. 단순히 읽기 동작만 있을 뿐 랜섬웨어처럼 해당 파일의 내용을 변경하고 새로 기록하는 등의 행위를 하지는 않습니다. 따라서 이는 앞선 비유에 따르면 순수하게 점토판의 내용을 읽는 것과 동일하므로 SSD의 수명과는 크게 상관이 없습니다.

요약해보면 여러분이 사용하는 SSD의 수명은 토렌트나 랜섬웨어, 다운로드 프로그램에 의해서 단축될 수 있지만 파일의 내용을 주로 읽기만 하는 보안 제품 때문에 수명이 일반적이지 않은 수준으로 단축되는 일은 없습니다. 저희 제품도 마찬가지구요. 그러니 안심하셔도 됩니다.

동영상 파일에 접근 하고 심지어는 그 파일을 외부 서버로 전송한다.

여러분의 동영상 파일이나 개인 데이터 파일에 아무 이유 없이 접근하지는 않습니다. 일부 조건들이 충족될 경우 해당 파일들이 검사 대상 목록에 추가되기도 합니다. 하지만 이렇게 말해도 여전히 실행 파일도 아닌 동영상 파일에 접근하는 이유가 이해가 되지 않으실 수 있습니다. 아이러니하게도 저희가 동영상 파일을 읽은 이유는 해당 파일이 진짜 동영상 파일이 맞는지 확인하기 위함입니다.

일반적으로 avi, mp4 등의 확장자는 동영상이라고 생각하지만 사실 해당 파일들의 내용물이 동영상이 아닌 실행 가능한 코드인 경우도 존재합니다. 그리고 그런 것들이 탐색기에 의해서는 실행되지 않지만 특수한 목적으로 제작된 프로그램에 의해서는 실행이 가능해 지기도 합니다. 따라서 파일의 확장자가 아닌 진짜 파일의 정체를 알아내기 위해서는 해당 파일의 일부를 읽는 동작을 할 수 밖에 없습니다. 이는 로컬 PC에 존재하는 파일의 형태를 파악하기 위함이지 다른 목적은 전혀 없습니다. 더욱이 많은 사용자 분들께서 오해하고 있는 것처럼 해당 파일을 외부 서버로 전송하거나 하는 일은 없습니다.

개인 정보를 유출시킨다.

인터넷을 통해서 연결이 가속화될수록 개인 정보는 점점 더 중요한 이슈로 부각됩니다. 연결을 위한 욕망 만큼이나 개인 정보를 보호하고 싶은 욕망도 강하지요. 어쨌든 이런 이유로 많은 국가에서 다양한 형태로 개인 정보에 대한 법적 규제를 가지고 있습니다. 잘 아시겠지만 우리가 즐기고 있는 게임도 더 이상 주먹구구식 코흘리게 사업이 아닙니다. 그말인즉 개인 정보에 관한 법적 규제를 엄격하게 받고 있다는 의미입니다.

게임에 함께 포함되는 서드파티 제품도 동일한 규제를 적용 받습니다. 개인 정보 보호에 관한 감사를 받으며, 제품 도입 시에 서비스 지역에서 시행되고 있는 개인 정보 보호법에 부합하는지에 대한 법률 검토 또한 함께 받습니다. 따라서 여러분께서 우려하시는 것처럼 개인 정보를 무단 수집하거나 함부로 유출하는 일은 없습니다. 게임이 서비스 되는 지역의 개인 정보 보호법과 게임 내에서 출력되는 최종 사용자 라이선스 계약(EULA)을 엄격하게 준수하고 있습니다. 안심하셔도 됩니다.

듀얼 클라이언트를 차단한다.

VMWare, VirtualBox, SandBoxie 등의 정상 프로그램이 탐지된다.

게임에 특정 키보드, 마우스를 사용할 수 없다. (게임사 정책에 의해 사용이 제한된 하드웨어)

차단 근거를 표시하지 않는다. 저희는 게임사에 게임 보안에 사용할 수 있는 도구를 제공할 뿐 정책을 제공하지는 않습니다. 위와 같은 내용들은 모두 게임사의 정책에 기인한 것이지 저희가 임의로 설정하는 내용이 아닙니다. 저희가 하는 일은 게임사에서 수립한 정책대로 동작하는 프로그램을 공급하는 것이 전부입니다. 나머지는 모두 저희 권한 밖의 일이랍니다.

윈도우 커널 모드 드라이버를 설치한다. 따라서 루트킷이다.

보안 제품이 완전한 검사를 수행하기 위해서는 관리자 권한이 필요합니다. 당연한 이야기이겠지만 권한이 낮은 상태에서 권한이 높은 대상을 검사할 수는 없기 때문입니다. 그냥 단순 비유를 들자면 선생님이 학생을 검사할 수는 있지만, 학생이 선생님을 검사하기는 힘든 뭐 그런 것이라고 이해하시면 됩니다. 이러한 완전한 권한을 가지기 위해서 저희 제품 또한 커널 모드 드라이버를 설치하여 로드하고 있습니다.

여기에 대해서는 기술적인 많은 이야기들이 필요하지만 몇 가지 사실들만 나열하겠습니다. 1) 여러분께서 알고 계시는 거의 모든 게임 보안 제품은 커널 모드 드라이버를 설치합니다. 2) 해당 제품들 중의 일부는 프로세스를 숨기거나 강제 종료를 막거나 키보드 후킹을 하는 등의 루트킷스러운 기능을 가지고 있기도 합니다. XIGNCODE3의 드라이버는 일반적인 윈도우 사용자 경험을 위배하는 이와 같은 기능은 전혀 포함하고 있지 않습니다. 3) XIGNCODE3에 포함된 커널 모드 드라이버 또한 앞서 기술한 것과 마찬가지로 게임사의 정책을 따르고 있습니다. 커널 모드 드라이버 설치를 원하지 않는 게임의 경우에는 게임 실행 시점에 커널 모드 드라이버를 설치 및 로드 하지 않습니다.

게임이 끝나도 남아서 계속 모니터링한다.

해외 게임 보안 제품 중에 일부 이러한 제품이 있습니다. 하지만 저희 제품은 아닙니다. 여러분이 게임을 종료하는 순간 저희의 모든 기능은 중단됩니다. 남아서 모니터링을 한다거나 시스템 자원을 소모 한다거나 하지 않습니다. 자동 재시작 프로그램으로 등록되지도 않습니다. 저희 제품의 생명 주기는 게임과 완전히 동일합니다. 여러분이 게임을 구동하면 XIGNCODE3가 함께 구동되며 게임을 종료하면 XIGNCODE3도 함께 종료됩니다.

해외에서는 사장되었다.

이 글을 작성하는 현 시점을 기준으로 저희 제품은 국내보다 해외에 더 많이 공급되어 있습니다. 아프리카를 제외한 거의 모든 지역에서 서비스되는 게임에 탑재되어 있습니다. 따라서 해외에서 사장되었다는 이야기는 정확한 사실이 아닙니다.

[시스템] 신뢰할 수 있는 루트 인증서 자동 업데이트

Fri, 26 Feb 2016 14:00:01 GMT

윈도우에서 신뢰할 수 있는 루트 인증서를 삭제 했음에도 마법처럼 루트 인증서가 계속 생기는 경우가 있다. 신뢰할 수 있는 루트 인증서와 없는 인증서에 대한 업데이트가 자동으로 이뤄지기 때문에 발생하는 현상이다. 테스트를 위해서 이 기능을 꺼버려야 하는 경우가 있는데 그때는 레지스트리에서 설정을 변경해주면 된다. 아래 레지스트리 값들을 이용하면 해당 기능을 오프시킬 수 있다.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot\DisableRootAutoUpdate
값 1은 신뢰할 수 있는 CTL의 Windows 자동 업데이트를 사용하지 않도록 설정합니다.
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot\EnableDisallowedCertAutoUpdate
값 1은 신뢰할 수 없는 CTL의 Windows 자동 업데이트를 사용하도록 설정합니다.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\AutoUpdate\RootDirUrl
공유 위치(HTTP 또는 FILE 경로)를 구성합니다.

더 자세한 설명이 필요하다면 아래 페이지를 참고하면 되겠다.

https://technet.microsoft.com/ko-kr/library/dn265983.aspx

[일상] 빈 배

Mon, 15 Feb 2016 14:00:01 GMT

한 사람이 배를 타고 강을 건너다가
빈 배가 그의 작은 배와 부딪치면
그가 비록 나쁜 기질의 사람일지라도
그는 화내지 않을 것이다.

그러나 그 배 안에 사람이 있으면
그는 그에게 피하라고 소리칠 것이다.
그래도 듣지 못하면 다시 소리칠 것이고
마침내 욕설을 퍼붓기 시작할 것이다.

이 모든 일은 그 배안에 누군가 있기 때문에 일어난다.
그러나 그 배가 비어 있었다면
그는 소리치지 않을 것이고 화내지도 않을 것이다.

세상의 강을 건너는 그대 자신의 배를
그대가 빈 배로 만들 수 있다면
아무도 그대와 맞서지 않을 것이다.
아무도 그대를 상처 입히려 하지 않을 것이다.

— 장자, 빈 배

오늘 발견한 울림이 있는 장자의 글. 장자는 진짜 천재임에 틀림이 없다. 어떻게 저런 생각을 한거지 ㅋㅋ~ 부딪힌 배를 비었다 생각하면 화낼 일도 없고, 내 배를 비우면 싸울 일도 없겠지… 하지만 비어 있지 않은걸 비었다 생각하고, 가득 차 있는 것을 비우는 것이 참 쉽지 않다는 게 함은정 ㅋ~ 또 반대로 생각하면 무관심이면 싸울 일도 없겠지만, 애정이 있으니 그나마 치고 박는 건 아닐까라는 생각도 들공… 인생 살이라는게 참 쉽지는 않다. 맘대로 되지도 않공.

[cpp] PIC 옵션의 정체

Mon, 04 Jan 2016 14:00:01 GMT

gcc에 보면 -fPIC이란 옵션이 있다. PIC 코드를 생성한다는 옵션이다. PIC라는건 Position Independent Code, 직역하면 위치 독립적인 코드 정도로 나온다. 난 지금껏 이 옵션이 재배치에 관한 옵션인줄 알았다. 즉, -fPIC을 지정하면 재배치 정보가 있어서 아무 주소에나 로드할 수 있고, 지정하지 않으면 고정 주소로 로드되는 뭐 그런걸 상상한 것이다. 한동안 그렇게 잘못된 지식을 가지고도 별 문제 없이 지냈는데 최근에 한 업체와 일을 하면서 잘못 알고 있었다는 것을 깨닫게 되었다. 반성하는 차원에서 PIC 옵션에 관한 내용을 정리해 놓는다.

우선 PIC라는건 재배치랑은 상관이 없다. gcc에서 so로 모듈을 생성하겠다고 하면 기본적으로 재배치 정보를 포함해서 아무 주소에나 로드할 수 있도록 모듈을 만들어 준다. 그럼 재배치랑 연관 있어 보이는 위치 독립적인 코드란 무엇일까? 결론만 말하면 재배치가 필요 없는 코드라고 보면된다. 그렇다면 재배치가 필요 없는 코드는 어떻게 만들까라는 의문을 가질 수 있다. 그건 바이러스 라는 글의 재배치 섹션에 나와 있는 것과 같은 방법을 사용한다고 보면 된다. 컴파일러가 그 일을 대신해 주는 것이다. RealOffset 같은 함수가 절대 주소 참조 시마다 들어가야 하기 때문에 -fPIC 옵션을 지정할 경우 코드가 커지는 것이다.

여기까지 읽고 도대체 뭔 소리야, 라고 할지도 모르겠다. 더 자세한 설명은 아래 글을 참고하자.

http://eli.thegreenplace.net/2011/08/25/load-time-relocation-of-shared-libraries
http://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries
http://eli.thegreenplace.net/2011/11/11/position-independent-code-pic-in-shared-libraries-on-x64

[일상] 더 행복한 한 해를 꿈꾸며...

Mon, 04 Jan 2016 12:00:01 GMT

난 내가 하고 싶은 것만 한다. 하기 싫은 건 하지 않는다.

25년 그리 긴 시간은 아니지만… 내가 살아오면서 지킨 단 한가지의 원칙이 있다면 저것일 것 같다. 난 하고 싶은 것만 했다. 재밌는 일들만 했고, 재미없는 것들은 하지 않았다.

거기에 특별한 가치관이나 판단 기준은 없었다. 단지 하고 싶고 재밌으면 하는 것이고, 그렇지 않으면 하지 않는 것이다.

하지만 오늘 문득 든 생각은 점점 하루하루 더해질수록 저러한 나의 생활 방식에 많은 가치관이 더해진다는 점이다. 하기 싫지만 xx때문에 해야 하고, 하고 싶지만 yy때문에 못하는 일들이 점점 늘어나는 것이다.

이런 생각이 들자 순간 기분 나빴다. 그래서 난 과감하게 14만원, 계절학기 6학점을 머릿속에서 지워버렸다. 없던 일로 하기로 했다. 재미없는 수업이고 그다지 하고 싶지 않아서였다.

포기하면 이렇게도 마음이 가벼워 지는 것을 왜 굳이 꼭 쥐고 있었나 모르겠다… 그 일 외에도 즐길만한 일들이 산더미 처럼 쌓여 있는데… ㅡ.ㅡ#

— 사탕... 2005

25살에 당차게 저런 생각을 했던 나의 35살, 2015년은 그때와는 사뭇 달랐다. 이유가 붙어서 어쩔 수 없이 해야만 하는 일이 줄기차게 늘어났고 나를 위한 시간은 정말 쥐꼬리만큼도 없었다. 게다가 그 모든 일들은 계절학기처럼 쉬이 포기할 수 있는 일들도 아니었다. 더러 잠깐 포기하는 경우에는 주변에서 엄청난 비난과 원망을 들어야 했다. 그런 시간이 오래되니 나중에는 마치 내가 무얼 좋아하는지도 모르는 사람처럼 돼 버렸다. 무엇을 할 때 행복한지도 기억하지 못하는 좀비처럼 말이다. 그런 내가 측은해 보였다. 남이야 뭐라든 나라도 재밌어야 주변 사람도 재밌게 해줄 수 있지 않을까? 내가 호흡기를 해야 내 아이도 해 줄 여유가 생기는 법처럼 말이다. 그래서 새해 벽두엔 모든 핀잔과 원망을 뒤로한체 드라마 정주행을 했다. 물론 상당한 외압이 있었지만 나는 행복했다.

리멤버: 아들의 전쟁

포토닉메모리(본 것은 죄다 기억하는)를 가진 주인공이 알츠하이머에 걸린 아버지의 누명을 풀기 위해서 변호사가 되어서 복수를 하는 내용의 법정 드라마다. 포토닉메모리를 가진 주인공으로 훈훈한 유승호 나와 주시고, 히로인으로 더 훈훈한 박민영씨가 출연해 주신다. 일단 주연 배우들의 비주얼이 훈훈해서 먹고 들어가는데 내용 또한 그렇게 구리진 않다. 퍼즐 조각을 엮기 위한 억지스러운 설정으로 보여지는 부분들도 있지만 대체로 개연성있게 스토리가 진행된다. 스토리 진행이 엄청 빠르다는 건 덤. 거기다 와이프 말마따나 코리안 멜로 코드가 아직까지는 많지 않다. 끝으로 최신 유행하고 있는 베테랑 흥행 코드가 깔려 있다. 유승호가 싸우는 세력이 재벌2세다. 그리고 조연으로 나오는 박성웅씨 의상, 연기가 압권이다, 황정민삘난다. 여튼 이런 전차로 1회 보고 나서 냅다 6회까지 정주행했다. 7회 분이 이번주 수욜 방영하는데 본방 사수할 것 같은 드라마…

블러드

뱀파이어 + 의학물 정도의 드라마. 주연 배우는 알 수 없는 하이틴 스타로 추정되는 남자 배우고 악역으로 지진희씨가, 히로인으로 구혜선이 나온다. 왠만하면 지진희씨가 나오는 드라마는 피하는 편인데 구혜선이 나와서 봤다는 썰이 있다. 1회 보고는 접을려고 하다가 본게 아까워서 몇 편 더 봤는데 냅다 정주행하게 되었다. 그 여파로 와이프에게 캐갈굼, 캐욕, 급기야 네번째 50일 촬영에 끌려가는 비극이 있었지만 최선을 다해서 20회까지 사수했다. 끝에는 지루해서 빨리감기를 좀 많이 했다.

스토리 설정이 참신한데 한 감염학자(의학자)가 해외 어딘가에서 뱀파이어 이야기를 듣고 시체를 발굴해서 뱀파이어 바이러스를 만들어 낸다는데서 출발한다. 그 바이러스에 감염되면 뱀파이어가 되는데, 뱀파이어는 뭐 우리가 익히 알고 있는 그 뱀파이어다. 밝은거 못 보고, 체온 낮고, 심박 빠르고, 피 보면 환장하고, 20대의 젊음을 한 250년 정도 유지하다가 죽는 그런… ㅋㅋ~ 그렇게 연구를 하던 랩실의 3명이 감염자가 되는데 다른 사람들은 이걸 폐기하자 그러고 지진희는 세상 밖으로 꺼내야 한다고 하면서 싸움이 난다. 늘 그렇듯이 악역이 교수와 친구 2명을 모두 죽이고 독차지 하면서 이야기가 시작된다. 그런데 그 죽인 친구 둘은 캠퍼스 커플이고, 감염된 뱀파이언데 그 사이에서 자식이 태어났으니 그게 주인공이다. 그렇게 둘이서 세월이 흘러 흘러 한국의 한 병원에서 만나서 지지고 볶는 그런 썰이다.

첨에는 의학물적인 내용이 더러 나와서 우왕 내가 안 본 의학 드라마도 있었넴, 게다가 액션까지 했는데,… 가면 갈수록 코리안 멜로와 알 수 없는 뱀파이어 호러물로 변질되면서 쩜쩜점했다. 끝은 이미 뻔했지만 본 게 아까워서 끝까지 정주행하는 예를 갖췄다.

행복의 기원

새해 벽두를 그냥 드라마만 냅다 정주행한것처럼 보이지만 와이프의 눈총과 육아를 병행해야 했던 시간에는 책도 읽었다. 한권은 행복에 관한 how보다는 why에 대한 답을 담고 있는 "행복의 기원"이란 책이다. 그냥 단순한 싸구려 자기계발서의 주장을 담고 있는 책은 아니고 과학적인 연구 결과를 바탕으로 써진 책이다. 그래서 그런지 내용이 팍팍 와 닿았다. 성격이 중요하고 유전이 상당한 영향을 미친다는 것에 다소 충격을 받았지만 말이다.

그리고 책에서 밝히는 또 하나의 충격적인 사실 중에 하나가 있다. 윤종신씨인지 유희열씬지가 방송에서 음악 열심히하고 그러는게 다 여자한테 잘 보이려고 하는거라고 했었던 말이 팩트라는 것이다. 진화론적 근거가 있는 이야기라는 사실. 공작새의 꼬리처럼 생존과는 별 상관 없어보이지만 이성에게 어필하기 위해서 그러는게 맞다는 다소 어이없지만 황당한 이야기. 인생 뭐 별 거 없다. 베토벤도 모짜르트도 여자한테 잘 보이려고 밤을 새며 작곡했다는 썰~ 그럼 혹시 토발즈와 카맥도? ㅋ~

유학 시절, 지도 교수가 쓴 논문을 읽은 적이 있다. 제목은 '행복은 기쁨의 강도가 아니라 빈도다'. 나는 이것이 행복의 가장 중요한 진리를 담은 문장 중 하나라고 생각한다.

지금 나는 왜 이모양으로 살고 있는가? 우리는 이런저런 이유를 떠올린다. 부모를 잘 만나서, 혹은 잘못 만나서, 대학 전공 때문에, 기타 등등. 조금씩은 모두 관련이 있겠지만 무엇을하며 어떤 인생을 사느냐를 결정하는 데 상당히 큰 몫을 차지하는 것은 바로 자신의 성격이다.

다시 말하지만 행복의 원인 중 사람들이 가장 과대 평가하는 것이 돈과 같은 외적 조건이다. 이 챕터에서는 반대로 행복에 절대적인 영향을 미치지만, 대부분이 미처 생각지 않는 요인에 대해 살펴보려 한다. 어떤 것이 그렇게 중요할까? 오랫동안 행복을 연구한 석학들을 한 자리에 모아놓고 그 질문을 한다면 대답은 거의 비슷할 것이다.
"유전. 더 구체적으로는 외향성."

행복의 핵심을 한 장의 사진에 담는다면 어떤 모습일까? 이 책의 내용과 지금까지의 다양한 연구 결과들을 총제적으로 생각했을 때, 그것은 좋아하는 사람과 함께 음식을 먹는 장면이다. 문명에 묻혀 살지만, 우리의 원시적인 뇌가 여전히 가장 흥분하며 즐거워하는 것은 바로 이 두가지다. 음식, 그리고 사람.

행복은 거창한 것이 아니다. 모든 껍데기를 벗겨내면 행복은 결국 이 한 장의 사진으로 요약된다. 행복과 불행은 이 장면이 가득한 인생 대 그렇지 않은 인생의 차이다. 한마디 덧붙인다면 "The rest are details." 나머지 것들은 주석일 뿐이다.

-- 행복의 기원, 서은국

가끔은 겪하게 외로워야 한다

김정운 교수의 신간이다. 왠만하면 자기계발서는 읽지 않는 편인데, 김정운 교수가 쓴 책이라 재미 삼아 읽었다. 내용도 그냥 가볍게 읽기 좋은 책으로 보여진다. 김정운 교수 팬이긴 한데 그의 "에디톨로지"는 정말 읽기 힘들어서 읽다 말았었다. 가볍게 개념만 편식하는 걸로 ㅋㅋ~ 근데 이 책은 그냥 심심풀이로 읽기 좋다. 김정운 교수는 이런 책이 어울린다는 개인적인 생각…

행복하자~

할아버지는 주당이셨다. 평생 반주를 하셨는데, 나중에는 술이 주고 밥이 부가 될 지경이었다. 노환으로 병원에 입원해 계섰을 때 엄마가 첨으로 와인을 사드렸는데 이런 술이 있냐며, 왜 진작 자신에게 사주지 않았냐는 이야기를 했다고 한다. 병원에서도 노환이니 좋아하시면 그냥 드리는 것도 괜찮다고 해서 와인을 종종 드시면서 마지막 병원 생활을 하셨다.

아빠는 내기 바둑과 장기, 고스톱에 빠져서 평생을 살았다. 돌아가시고 엄마한테 들어서 안 사실이지만 아빠의 도박 편력이 장난이 아니었다. 그렇게 평생을 좋아하더니 마지막 까지도 집 앞 공원에서 내기 장기를 두고는 가셨다. 병원에서 칼륨 수치를 관리해야 한다고 짠 걸 드시지 말라고 하셨을 때 한 말씀이 생각난다. 죽으면 죽었지 먹고싶은건 먹어야겠다고 말이다. 여튼 그렇게 아빠는 자기가 하고 싶은 걸 다 하시고 가셨다.

어떤게 정답인지는 모른다. 당장의 쾌락을 따르며 사는게 좋은건지, 아니면 근엄하게 사는게 좋은건지 말이다. 하지만 이것 저것 따질것 없이 그냥 지금 행복하게 사는게 중요한 건 아닐까? 얼마간 더 사는 것보다 오늘 재미난 일을 하고 행복하게 사는게 더 소중하지 않을까? 내일은 오지 않을 수도 있으니 말이다. 당장 가진 오늘을 더 재미있고 행복하게 영위하는게 훨씬 더 좋지 않을까라는 생각. 생각이 여기까지 미치니 참으로 유전이란 걸 무시못하는건가 싶기도 하다. 여튼 2016년은 행복한 일로 가득한 한 해가 되길 소망해 본다. 맛집블로그로 전환될지도 모르겠다 ㅋㅋㅋ~

블로그 이동

Mon, 04 Jan 2016 12:00:01 GMT

어느날 갑자기 워드프레스가 너무 복잡한 것 같은 생각이 들어서 블로그를 옮겼습니다.

링크가 이곳으로 돼 있어서 이곳으로만 오는 분들이 계신 것 같아서 포스팅합니다.

새로운 주소는 http://www.jiniya.net/ng입니다.

혹시 즐겨찾기를 사용하시는 분이라면 http://www.jiniya.net을 추가해 두시면 됩니다.

해당 주소로 가시면 알아서 새로운 주소로 이동시켜 준답니다.

늦었지만 새해 복 많이 많이 받으세요 !!!

[cpp] 모던 C++에서 훅 코드란?

Wed, 30 Dec 2015 15:00:01 GMT

다른 블로그 구경하다가 재미난 코드를 발견해서 옮겨봅니다. 훅 루틴인데요. 모던 C++을 사용하니 정말 간결하네요. C++의 르네상스가 다시 오는건지 ㅋㅋ~ 신세계군요. 망할 XP만 없다면 빨리 넘어갈텐데 ㅠㅜ~

decltype(&timeGetTime) HooktimeGetTime = []() -> DWORD { return 0; };

decltype(A)는 A의 타입을 반환합니다. 예전에 훅 루틴 만들때마다 원형 복사해서 함수 포인터 다시 typedef하던 때를 떠올리면 정말 심플합니다.

" {}"는 람다 함수입니다. " -> DWORD {}"는 파라미터는 없고 리턴 값은 DWORD인 람다 함수라는 말이죠.

[cpp] 윈도우에서 llvm-obfuscator 사용하기

Fri, 18 Dec 2015 15:00:01 GMT

Clang은 LLVM을 백엔드로 사용하는 C 계통의 언어를 컴파일해주는 컴파일러다. LLVM을 백엔드로 사용하기 때문에 컴파일 타임에 뭔가를 해줄 수 있다는 장점이 있다. 그런 것 중에 하나로 난독화를 들 수 있다. obfuscator-llvm은 LLVM에 난독화 기능을 추가한 버전이라고 보면 된다. 소개 페이지에 나와 있는 것처럼 LLVM IR레벨에서 작업하고 있기 때문에 LLVM을 백엔드로 사용하는 언어와 타겟 머신을 모두 지원한다는 장점이 있다. 제작자들이 첨에는 학교에서 논문으로 쓰다가 아이디어가 괜찮아서 스타트업을 차린 것으로 보여진다. 어쨌든 이걸 쓰면 컴파일 타임에 나의 코드에 난독화를 적용할 수 있는 것이다. 응당 사용하지 않을 이유가 전혀 없다. 그럼 한 번 살포시 시작해보자.

우선은 Clang을 윈도우에서 어떻게 쓸지부터 알아야 한다. 정말 많은 글들이 있지만 이 글에 나와있는 방법이 가장 좋았다. Clang에다 런타임라이브러리와 링커는 mingw-w64껄 쓰는 방법이다. 글에 나와 있는 방법대로 하면 대체로 모두 잘 된다. 내가 조금 골탕먹은 것은 mingw-w64를 선택할 때 스레딩 모델을 Win32로 선택했던 것이었다. Win32로 선택하면 C++11부터 추가된 스레드 기능을 사용하지 못한다. 그러니 POSIX로 선택하는 것이 바람직하다 하겠다. 예외의 경우 64는 SEH로 32는 Dwarf를 받아서 썼다. 그렇게 했더니 아래 코드가 깔끔하게 컴파일이 되었다. "clang++ -std=c++14 hello.cpp -lpthread"라는 명령어로 아래 코드가 깔끔하게 컴파일이 되었다.

#include <thread>
#include <chrono>
#include <stdio.h>

void PrintMsg(const char *msg, int try_cnt, int sec)
{
	for(int i = 0; i < try_cnt; ++i)
	{
		printf("[%03d] %s\n", i, msg);
		std::this_thread::sleep_for(std::chrono::seconds(sec));
	}
}

int main()
{
	std::thread thread1(&PrintMsg, "dog", 10, 1);
	std::thread thread2(&PrintMsg, "cat", 10, 2);
	std::thread thread3(&PrintMsg, "monkey", 10, 3);

	thread1.join();
	thread2.join();
	thread3.join();

	return 0;
}

이렇게 컴파일한 결과물을 사용하면 별 문제는 없는데 덕지덕지 온갖 이상한 DLL을 많이 임포트하는 경향이 있다. 그래서 용량이 큰 C++ 라이브러리를 제외하고 정적으로 컴파일하고 싶으면 "clang++ -std=c++14 hello.cpp -static -static-libgcc -lpthread -Wl,-Bdyanmic -lstdc++"와 같이 입력하면 된다. 여튼 뭐 컴파일은 그렇다. 그렇다면 이제 llvm-obfuscator를 써보자.

난독화 함수를 찾기 쉽도록 아래와 같이 익스포트 되도록 함수를 선언해주자. 뒤에 속성으로 따라 붙는 것이 fla, bcf, sub 난독화 기법을 이 함수에 적용하겠다는 것을 의미한다. 오픈소스 버전은 세 가지 기능만 제공하고 있다.

__declspec(dllexport)
void PrintMsg(const char *msg, int try_cnt, int sec)
__attribute((__annotate__(("fla"))))
__attribute((__annotate__(("bcf"))))
__attribute((__annotate__(("sub"))))
;

난독화가 적용되지 않은 PrintMsg 함수. 코드만큼 어셈도 단순하다.

난독화가 적용된 PrintMsg 함수. 함수가 점프 코드로 분산되고 길고 어려워진다.

내가 사용한 버전은 llvm-3.6.1 브랜치 코드를 기준으로 작업했다. 사용해보면 윈도우에서 /dev/random을 찾을 수 없다는 버그가 있는데 lib/Transform/Obfuscation/CryptoUtils.cpp 파일의 prng_seed 함수를 아래와 같이 수정해주면 정상 동작하도록 만들 수 있다.

#ifdef _WIN32
#define _WIN32_LEAN_AND_MEAN
#include <Windows.h>
#include <Ntsecapi.h>
#endif

void CryptoUtils::prng_seed()
{

#ifdef _WIN32

	LLVMContext &ctx = llvm::getGlobalContext();

	HCRYPTPROV prov;

	if (CryptAcquireContext(&prov, 0, 0, PROV_RSA_FULL, CRYPT_VERIFYCONTEXT | CRYPT_SILENT))
	{
		if(!CryptGenRandom(prov, 16, (BYTE *) key))
			ctx.emitError(Twine("CryptGenRandom fail"));

		CryptReleaseContext(prov, 0);

		memset(ctr, 0, 16);

		// Once the seed is there, we compute the
		// AES128 key-schedule
		aes_compute_ks(ks, key);

		seeded = true;
	}
	else
	{
		ctx.emitError(Twine("CryptAcquireContext fail"));
	}

#else

	// ... 기존 코드 ...

#endif
}

[cpp] API 세트 DLL 이름 바인딩하기

Thu, 17 Dec 2015 15:00:01 GMT

윈도우 7이 등장하면서 kernel32.dll을 살펴보면 이상한 부분이 하나 생겼습니다. 바로 IAT 부분인데요. api-ms-win-core-console-l1-1-0.dll 같은 이상한 DLL로 부터 우리가 원래 익히 알고 있는 API들을 임포트 하고 있는 것이죠. 그런데 api-ms-win-core-console-l1-1-0.dll 같은 것에 실제 코드가 포함돼 있냐하면 그것도 아닙니다. 헐~ 멍밍하게 되는데요. 그 당시에 발견한 문서에서 기본적인 메커니즘을 알게 되어서 해당 문서에 나와 있는 DLL 이름들만 하드 코딩해서 사용을 했었습니다.

이후에 윈도우 8이 나왔고, 8.1이 출시됐고, 윈도우 10이 나오고, 이제는 윈도우 10 TH2까지 나왔습니다. 저 문서에 있는 내용 만으로 뭔가가 정상 동작하기에는 뭔가 한참 모자랄만큼 운영체제가 많이 나왔죠. 어제 해킹툴을 테스트하다가 코드가 정상적으로 동작하지 않는 것을 발견했습니다. 바로 위에서 우리가 하드 코딩한 DLL 말고도 온갖 요상한 DLL이 많이 생긴게 원인이었습니다. 그래서 이 많은 DLL 이름을 어쩌지 하는 찰나에 관련 설명을 담고 있는 MSDN 문서를 발견하게 되었습니다. 목록이 엄청 길죠. API 세트에 사용되는 온갖 DLL 이름이 다 나와있습니다. 이 테이블을 기초로 DLL 이름을 매핑해주는 함수를 확장시켰더니 마법같이 잘 동작했습니다. 역시 MSDN ㅋㅋ~ 그런데 뭔가 좀 아쉽죠. 모두 입력 시켜서 동작하게는 만들었지만 도대체 이 이름들은 어디서 오며 운영체제는 어떻게 그걸 매핑시키는지 궁금한거죠~ 은막 뒤의 비밀이 궁금하다랄까요.

자동으로 될 일은 없고, 운영체제도 어디에선가는 매핑을 시킬텐데 그 자료를 알게 되면 굳이 이걸 일일이 입력하고 있지 않아도 되지 않을까라는 생각이었습니다. 그 생각으로 오늘 LoadLibrary 코드를 좀 살펴봤는데요. 비밀을 알아냈습니다. LoadLibrary 내부에서 PEB에 저장된 ApiSetMap이란 자료 구조를 참조해서 DLL 이름을 리다이렉트 시키고 있었습니다. 풉. 역시 마법은 없었습니다. ApiSetMap이란 걸 알게 되었으니 관련 키워드로 검색을 해봤습니다. 자료가 많지는 않은데 친절하게 리버싱해 둔 자료가 있었습니다.

전체적인 메커니즘은 런타임 DLL 이름 해석 Part 1, Part 2에 잘 나와 있습니다. 관련 자료를 토대로 만든 실제 코드는 위키 글을 참고하면 됩니다.

간략하게 전체 구조를 리뷰해보면 모든 데이터의 근간은 apisetschema.dll에 있습니다. 윈도우는 부팅할 때 그 DLL의 .apiset 섹션 데이터를 토대로 메모리에 API 세트 이름 매핑 자료를 로드합니다. 그리고 이후 프로세스가 생성되면 PEB의 ApiSetMap에다가 해당 자료를 참조할 수 있도록 데이터를 매핑시켜줍니다. 이제 LoadLibrary를 호출하면 PEB의 ApiSetMap을 뒤져서 매칭되는 DLL이면 이름을 리다이렉트 시켜주는 것이죠. 결국 하드코딩한 테이블을 사용할 것이 아니라면 ApiSetMap을 어떻게 뒤지는지 알아야 합니다.

앞선 위키 글의 경우 윈도우 7을 기초로 작성해서 제가 사용하는 윈도우 8.1에서는 동작하지 않는 문제가 있었습니다. 그래서 윈도우 8.1에서 동작하도록 코드를 한 번 만들어 보았습니다. 런타임 DLL 이름과 매핑되는 실제 DLL 이름을 출력해 줍니다. 위키 글에 있는 코드는 ApiSetMap 구조체 버전이 2인 환경입니다. 아래는 버전이 4인 환경일 때의 구조체 정보랍니다. 윈도우 10은 또 업그레이드가 되었겠죠?

덧) 현재까지 알려진 ApiSetMap 자료 구조 버전은 총 세 개입니다. 윈도우 7에 포함된 구조가 2버전이고, 윈도우 8에 포함된 구조가 4버전입니다. 윈도우 10에는 6버전 구조로 변경이 되었네요. 아래 코드는 윈도우 8의 ApiSetMap 버전 4를 출력하는 기능을 합니다. 당연히 2나 6에서는 정상 동작하지 않습니다.

#include <windows.h>
#include <stdio.h>

#define ADD_PTR(a, b) ((PVOID)((ULONG_PTR)(a) + (ULONG_PTR)(b)))

#pragma pack(1)

typedef struct _API_SET_MAP_DATA_ENTRY
{
	ULONG flags;
	ULONG name_offset;
	ULONG name_length;
	ULONG value_offset;
	ULONG value_length;
} API_SET_MAP_DATA_ENTRY, *PAPI_SET_MAP_DATA_ENTRY;


typedef struct _API_SET_MAP_DATA
{
	ULONG flags;
	ULONG count;
	API_SET_MAP_DATA_ENTRY entries[ANYSIZE_ARRAY];
} API_SET_MAP_DATA, *PAPI_SET_MAP_DATA;


typedef struct _API_SET_MAP_ENTRY
{
	ULONG flags;
	ULONG name_offset;
	ULONG name_length;
	ULONG alias_offset;
	ULONG alias_length;
	ULONG data_offset;
} API_SET_MAP_ENTRY, *PAPI_SET_MAP_ENTRY;



typedef struct _API_SET_MAP
{
	ULONG version;
	ULONG size;
	ULONG flags;
	ULONG count;
	API_SET_MAP_ENTRY entries[ANYSIZE_ARRAY];
} API_SET_MAP, *PAPI_SET_MAP;


#pragma pack()

int main()
{
	PVOID name_ptr;
	ULONG_PTR api_set_map;

	PAPI_SET_MAP pasm;
	PAPI_SET_MAP_DATA pasmd;

	WCHAR name[MAX_PATH];

	api_set_map = __readfsdword(0x30);
	api_set_map = *(ULONG_PTR *)(api_set_map + 0x38);


	pasm = (PAPI_SET_MAP) api_set_map;

	for(ULONG i = 0; i < pasm->count; ++i)
	{
		name_ptr = ADD_PTR(pasm, pasm->entries[i].name_offset);

		memset(name, 0, sizeof(name));
		memcpy(name, name_ptr, pasm->entries[i].name_length);

		pasmd = (PAPI_SET_MAP_DATA) ADD_PTR(pasm, pasm->entries[i].data_offset);

		printf("%ls => [%d]", name, pasmd->count);

		for(ULONG j = 0; j < pasmd->count; ++j)
		{
			name_ptr = ADD_PTR(pasm,  pasmd->entries[j].value_offset);

			memset(name, 0, sizeof(name));
			memcpy(name, name_ptr, pasmd->entries[j].value_length);

			printf(" %ls", name);
		}

		printf("\n");

	}

	return 0;
}

[시스템] 블록 암호화의 연산 모드란?

Sat, 12 Dec 2015 15:00:01 GMT

암호는 용어도 많고 알고리즘도 어렵고, 구조도 복잡합니다. 그런 암호 중에서도 블록 암호화를 공부하면 연산 모드란 것을 만나게 됩니다. 어떤 거냐구요? 바로 이런 겁니다. 이런 상수를 만나면 으례 그냥 아무거나 넣거나 디폴트 값을 사용하곤 하지만 오늘은 한 걸음 더 파헤쳐보는 시간을 가져보도록 하겠습니다.

블록 암호화는 기본적으로 블록 단위로 특정 키를 사용해서 암호화를 하는 것을 의미합니다. 특별한 언급이 없는한 대칭키를 사용하는 구조가 대부분이죠. 암호화를 수행한 키를 암호를 해독할 때에도 사용한다는 겁니다. 그렇다면 이런 대칭형 블록 암호화 기법의 가장 큰 문제점은 무엇일까요? 네, 맞습니다. 똑같은 블록, 똑같은 키라면 결과물이 똑같다는 거죠. 어느 정도 패턴이 드러날 수 밖에 없다는 이야깁니다. 아래 이미지를 보면 이해가 빠릅니다. 세 가지 그림이 있는데 왼쪽이 원본, 가운데가 연산 모드 없이(ECB) 블록 암호화를 수행한 것, 오른쪽은 ECB가 아닌 연산 모드를 선택해서 블록 암호화를 수행한 겁니다. 어떤가요? 기본적인 ECB의 경우 이미지가 변형되었지만 우리는 이 이미지가 펭귄이란 것을 인식할 수 있습니다.

기본인 ECB 연산 모드가 왜 위험한지를 보여주는 짤. 암호화를 했지만 우리는 펭귄을 볼 수 있다는거~

이렇게 패턴이 드러나는 문제를 해결하기 위해서 나온 것이 연산 모드입니다. 거창하게 설명했지만 대단한 건 아니고 블록 암호화의 연산 전후에 규칙적으로 변형을 가하는 것을 의미합니다. 아래는 많이 사용하는 CBC 연산 모드에 대한 이미지 입니다.

보면 일반적인 블록 암호화보다 입력 파라미터가 하나 더 있습니다. IV라는 건데요. 직역하면 초기 벡터로 암호에 영향을 주는 또다른 팩터라고 이해를 하면 되겠습니다. CBC 모드를 보면 그냥 블록 암호화를 하는 것이 아니라 암호화를 하기 전에 IV와 XOR을 수행한 다음 그 결과물을 블록 암호화를 시킵니다. 다음 블록의 경우에는 IV가 그 전 블록의 암호화한 결과 값이 됩니다. 따라서 블록 별로 어떤 컨텍스트에서 암호화가 되느냐에 따라 동일한 소스에 동일한 키로 암호화를 하더라도 결과 값이 달라집니다. 그말은 궁극적으로 기본적인 블록 암호화 기법보다 패턴을 알아내기가 훨씬 어려워진다는 걸 의미합니다.

연산 모드를 설명한 위키 페이지를 참고하면 다양한 연산 모드가 소개되어 있으니 한번 살펴보도록 합시다. 연산 모드 설명 옆에 병렬 처리, 랜덤 읽기 지원 여부를 비교해 둔 표도 같이 있으니 함께 살펴보면 더 많은 공부가 될 것 같기도 합니다.

[cpp] 부스트 라이브러리 CRC32 계산하기

Thu, 10 Dec 2015 15:00:01 GMT

부스트에는 참 많은 기능이 있죠. CRC 계산하는 루틴도 포함되어 있습니다. 그것도 사용하기가 너무 너무 쉬워요. 그럼 일반적으로 많이 사용하는 32비트 CRC를 계산 루틴을 한 번 살펴볼까요 ㅋ~

#include <stdio.h>
#include "boost/crc.hpp" (1)

int main()
{
	boost::crc_32_type crc; (2)

	char bytes[] = "hello world!";
	crc.process_bytes(bytes, strlen(bytes)); (3)

	printf("%08x\n", crc.checksum()); (4)

	return 0;
}

crc.hpp 일단 인클루드 해 주시구요.
crc_32_type이 우리가 계산할 32비트 CRC를 계산하는 클래스 타입입니다.
process_bytes로 CRC 계산할 버퍼를 계속 공급해 주시면 됩니다. 버퍼 포인터와 크기라는 건 뭐 그냥 아시겠지요?
참고로 한번에 넘기기 큰 데이터는 분할해서 process_bytes를 호출하면 됩니다.
checksum 메소드를 사용하면 계산된 32비트 CRC 값이 넘어 옵니다.

[cpp] 16진수 헥사 인코딩의 정석

Thu, 26 Nov 2015 15:00:01 GMT

최근에 퍼지 해시(fuzzy hash), 롤링 해시(rolling hash), 지역 민감 해시(Locality-sensitive hash) 등으로 불리는 코드를 좀 찾아보고 있었습니다. 대체로 ssdeep을 많이 사용하는 것 같은데 ssdeep의 경우 안타깝게도 GPL 이더군요. 그래서 다른 종류는 뭐가 있나 하고 알아보던 중에 트렌드마이크로에서 공개한 TLSH를 찾았습니다. 위키피디아에는 TLSH란 보안과 디지털 포렌직 프로그램을 위해 설계된 지역 민감 해싱 알고리즘이라고 나와 있습니다. 그쵸. 바로 우리가 찾던 그 녀석이죠. 걔다가 착하게도 아파치 2.0 라이선스라는 ㅋㅋㅋ~

형님들이 작성한 코드를 좀 보다가 재미난 부분이 있어서 올려봅니다. 바이너리 데이터를 16진수 헥사 코드로 인코딩하는 코드입니다. 아래처럼 작성되어 있습니다.

void to_hex( unsigned char * psrc, int len, char* pdest )
{
    static unsigned char HexLookup[513]= {
	"000102030405060708090A0B0C0D0E0F"
	"101112131415161718191A1B1C1D1E1F"
	"202122232425262728292A2B2C2D2E2F"
	"303132333435363738393A3B3C3D3E3F"
	"404142434445464748494A4B4C4D4E4F"
	"505152535455565758595A5B5C5D5E5F"
	"606162636465666768696A6B6C6D6E6F"
	"707172737475767778797A7B7C7D7E7F"
	"808182838485868788898A8B8C8D8E8F"
	"909192939495969798999A9B9C9D9E9F"
	"A0A1A2A3A4A5A6A7A8A9AAABACADAEAF"
	"B0B1B2B3B4B5B6B7B8B9BABBBCBDBEBF"
	"C0C1C2C3C4C5C6C7C8C9CACBCCCDCECF"
	"D0D1D2D3D4D5D6D7D8D9DADBDCDDDEDF"
	"E0E1E2E3E4E5E6E7E8E9EAEBECEDEEEF"
	"F0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF"
    };
    unsigned short* pwHex = (unsigned short*)HexLookup;
	unsigned short* pwDest= (unsigned short*)pdest;

	for (int i=0; i<len; i++ ) {
		*pwDest= pwHex[*psrc];
		pwDest++; psrc++;
	}
	*((unsigned char*)pwDest)= 0;  // terminate the string
}

사실 뭐 특별할 건 없지만 00부터 FF까지 테이블을 작성한 형님들의 노고에 박수를 ㅋㅋㅋ~ 통상적으로 배열을 만들면 "0123456789ABCDEF" 정도 만들어서 사용하기 마련인데요. 한땀한땀 성능을 생각하신 형님들께서는 친히 00부터 FF까지를 모두 테이블에 담아버렸습니다.

테이블을 룩업 하는 과정은 더 C언어 스러운데요. 문자열 테이블을 USHORT 포인터로 변환해서 2바이트씩 한번에 복사해 버림으로써 불필요한 연산을 최소화해주셨습니다. 0을 넣는 부분에는 깨알같이 "terminate the string"이란 주석까지 ㅋ~ 장인 정신이 묻어나는 코드가 이닐수가 없네요. 코드를 보면서 "0123456789ABCDEF"만 만들어서는 쉬프트와 더하기를 남발했던 저는 배꼽 반성을 했습니다.

TLSH GitHub 저장소를 보면 코드와 함께 발표한 논문 자료와 다른 알고리즘(ssdeep, sdhash)과의 비교 자료도 함께 있는데요. 굉장히 인상적입니다. 이런게 바로 리서치가 아닐까 싶네요. 사족을 하나 더 달자면 그간 트렌드마이크로를 그닥 의미 없는 백신 제품이라 생각했는데 이 코드 하나로 저에게는 기업 이미지가 굉장히 좋아졌습니다. 물론 그렇다고 트렌드마이크로 백신을 산다는 소리는 아닙니다 ㅋㅋㅋ

[일상] 출산 이모저모

Wed, 11 Nov 2015 15:00:01 GMT

#0

여긴 어디? 난 누구?

지난주 할머니와 음력 생일이 똑같은 기염을 토하면서 어여쁜 딸이 세상 밖으로 나왔다. 누나들에게 매번 애들한테 왜그리 집착하며 사는지 점쩜쩜이라고 말을 하면, 누나들은 항상 니 애 낳아 보라는 대꾸를 했었다. 아직 일주일도 안 된 딸을 보면서 그말이 틀리지 않았음을 실감한다. 세상의 모든 부모들이 왜 그런지 말이다. 아이와 자식은 다른 느낌이다. 그냥 자고 있는 것만 보고 있어도 열심히 살아야겠다는 생각이 절로 든다. 뭔가 잘해줘야 할 거 같다는 느낌이 팍팍든다. 위험한 생각이 들때면 와이프랑 그래도 우린 맘충이, 빠충이는 되지 말자며 다짐한다.

#1

출산은 정말 시트콤 같았다. 와이프가 점심 때쯤 진통이 온다며 병원에 전화를 했다. 대략 5-10분 간격으로 온다고 말을 하고는 남편 퇴근하고 가도 되냐고 물으니 간호사가 지금 당장 오라고 했다는 것이다. 와이프의 콜을 받고 부리나케 병원으로 달려갔다. 원래 검사를 하던 의사는 없어서 다른 의사가 태동 검사를 하고 내진을 했는데, 뭐 자궁이 하나도 안 열렸고 진통도 별로 없는거 같다며 아직 한참이나 남았을 거 같은데 왜 왔냐는 늬앙스로 이야기를 했다.

누구나 한번쯤 겪는다는 빠꾸를 맞고는 앞에서 항정살에 7분 김치찌게를 먹었다. 밥을 먹는데도 와이프는 연신 배가 아푸다고 했다. 의사가 하도 완강하게 이야기해서 설마 벌써 그렇겠냐며 5분 간격으로 정확하게 오면 가자고 했다. 그리고는 내심 오늘은 아니라는 생각을 많이 했었다. 엄마는 눈이 뒤집힐정도로 아플 때 병원을 가야 한다는 말을 했었다. 그런데 와이프는 너무 평온해 보였다. 진통이 올때 아파했지만 눈이 뒤집힐 지경은 아니었다.

회사 들어가기도 애매하고 혹시 몰라 집에 있었다. 앱으로 계속 시간 측정을 했다. 5분 내로 진통은 계속 왔지만 우리는 아니라고 생각했다. 설마 의사가 그랬는데 불과 2-3시간 지났는데 시작됐겠어? 이건 아닐꺼야 그런 생각이었다. 저녁 먹을즈음에도 진통은 3-4분 간격으로 계속 왔다. 엄마가 뭐라도 먹어야 애도 낳는다는 말에 일단 밥을 먹자고는 배달 음식을 시켰는데, 그 배달 음식이 딱 도착하기가 무섭게 양수가 터졌다.

병원을 향해 달려갔다. 퇴근 시간인데다 서울대입구 4거리는 늘 헬게이트, … 와이프는 정말 눈이 뒤집히고 있었다. 눈물을 흘렸다. 어쨌든 병원에 도착했고 바로 분만실로 갔다. 간호산지 조산산지 뚱땡이가 왜 이제 왔냐며 뭐라고 했다. 아침에 있었던 일을 이야기 했지만 의미는 없었다. 벌써 자궁이 5cm이나 열렸다고 했다. 30분쯤 지나자 7cm, 한시간 좀 넘어서는 8cm가 열렸다고 했다. 무통은 의미가 없다고 했다. 일찍 와야 맞을 수 있는데 이미 다 지나가서 지금은 맞을 수가 없다는 이야기. 와이프는 절규를 했다. 무통과 제왕절개를 욕과 함께 미친듯이 요구했지만 그저 바라볼 수 밖에 없었다.

뚱땡이 간호사는 정말 불친절했다. 틱틱거리며 와이프에게 시종일관 명령과 지시의 태도를 보였다. 아픈데 그러니 말이 통할리가 없다. 난감한 상황. 하지만 3시간쯤 지나 출산이 임박했을 때 해결사가 들어왔다. 벌써 사람 다루는 폼새가 남달랐다. 특히나 목소리가 너무 좋았는데 마치 최면에 걸려서 그 말을 꼭 따라야 할 것 같은 그런 목소리였다. 와이프는 어렵지 않게 그 사람의 말을 따라했고, 몇 분 지나지 않아서 아이가 나왔다. 병원온지 3시간 50분 만에 순산했다. 의사가 오고 아기가 너무 쉽게 나와 좀 어이가 없었다. 힘주세요. 한 번 더 하는데 나왔다. 엉겹결에 탯줄을 끊었다. 채린이가 그렇게 태어났다.

어서와, 이런 세상은 처음이지

의사가 그랬다. 상위 10% 들 정도로 순산했다고. 물론 거기 순위를 메긴다는게 우습긴 하지만 정말 쑨풍 나온 것 같긴 했다. 와이프 한테도 채린이한테도 고맙다. 옆에서 지켜보는 것도 보통 고통이 아니기 때문이다. 무통과 제왕절개를 외치는 것을 가슴으로는 백번도 더 시켜주고 싶지만 머리로 말려야 한다는게 결코 편하지는 않기 때문이다. 나도 힘들었는지 그날 새벽 옷을 갈아 입으로 집으로 가서는 씻겠다고 욕조에 물을 받아놓고 그 안에서 잠이 들어버렸다 ㅋㅋㅋ~

#2

사실 난 대한민국 복지에 대해서 크게 느낀 바가 없다. 내 급여에서 상당한 금액의 의료보험료와 고용보험료가 나가지만 크게 병원을 간 적도, 실업 급여를 받은 적도 없다. 더 많은 국민연금을 내지만 그 연금을 잘 수령할지는 미지수다. 더 (체감상) 천문학적인 소득세를 내고 있지만 정말 이렇게까지 뜯어가야 하나 싶은 생각만 있었다. 그나마 약간 느낀게 엄마가 암 수술을 했을 때 중증 환자로 5%의 비용으로 치료를 받는 걸 보고는 의료보험은 그나마 제구실을 한다는 생각을 했었던게 전부였다.

그런데 이번에 아이를 낳고 보니 생각보다 우리나라가 그리 구리지는 않다는 생각이 많이 들었다. 우선 부탁한적도 없는데 자연분만에 드는 일체의 비용을 국가에서 부담해 주었다. 거기다 청각 검사와 대사 증후군 검사를 무료로 해주고, 그것도 모자라 결핵 예방접종도 해줬다. 병실료와 영양제 값만 나온 청구서를 보고는 참 고맙다는 생각을 했다. 관악구에 출생신고를 하러 가서는 선물을 안 줘서 조금 실망했지만 육아수당을 준다는 이야기를 듣고는 좋다는 생각이 들었다. 그것도 소득수준에 관계없이 준다는 데 감사한 마음이 많이 들었다. 물론 여기서 끝이 아니다. 아이를 어린이집에 보낼 경우 모든 비용을 국가에서 부담한다. 그것도 초등학교 입학할때까지 모든 비용을 말이다.

보건소도 나쁘지 않다. 임신 중에도 각종 검사와 약을 지원해주고, 출산 후에도 상당히 많은 신생아 예방 접종을 지원해준다. 그것도 보건소에 가서 맞아야 된다고 생각을 했었는데 대부분의 큰 병원이 모두 제휴가 되어 있어 그냥 병원에서 맞아도 비용을 다 국가에서 지불해준다. 참 편리한 시스템이라는 생각이 들었다.

#3

프로그래머는 숙명적으로 무엇인가의 이름을 지으며 살아간다. 언젠가 인터넷 설문조사에서는 프로그래머가 느끼는 고충 중에 당당하게 1위로 이름짓기(Naming)가 올라와 있었다. 어쨌든 그렇게 이름을 수도 없이 지으며 산다. 그래서 그랬을까? 와이프의 임신 소식을 들었을 때 이름이 뙇 떠올랐다. 딸이면 채린이라 짓고, 아들이면 태성이라 지으리라. 심지어 아들 이름은 한자까지 떠올랐다. 클 태에 이룰 성으로 지어야지 ㅋ~

병원에서 퇴원하는 날 난 엘티이급으로 출생신고를 했다. 하지만 이름을 가지고 잡음이 좀 있었다. 엄마가 어디서 지었냐는 출처를 계속 캐물었기 때문이다. 어디서 지었냐? 그렇다 우리나라 사람들은 이름을 대체로 스스로 짓지 않는다. 어딘가에 위탁한다. 철학관, 작명소 같은 곳 말이다. 사주도 풀고 그런단다. 내가 지었다는 말을 결코 신뢰하지 못할 우리 엄마를 위해서 월정사 명월스님에게 지었다는 이야기를 했다. 그러자 엄마가 조금 안심을 한다. 대기업 회장님들도 찾아가는 유명한 스님이라고 하자 더욱 신뢰를 하셨다. 우습지만 그게 현실이었다.

결혼을 하는 날짜도, 이사를 가는 날짜도, 이사를 가는 방향도, 애 이름도, 사업을 할지 말지도, 유학을 갈지 말지도, 우리 나라 사람들은 대체로 스스로 뭔가를 결정하지 못하는 것 같다. 다 좋은게 좋은거고 조심해서 나쁠건 없다는 이야기를 한다. 그렇게 잡은 결혼 날짜에는 미친듯이 비가 왔다. 그제야 하는 말. 비 오는 날 결혼하면 잘산다는 이야기. 이건 뭐 피할 수가 없다 ㅠㅜ~

이것도 좋고, 저것도 좋고, 다 좋은데 이름 하나쯤은 내가 지어주고 싶었다. 내가 생각하는 딸에 대한 애정이랄까? ㅋ~

#4

산후조리원과 산후도우미, 어린이집에 관해서도 할 이야기가 많지만 시간 관계상 이쯤에서 마치는 걸로 ㅋ~

[일상] 100인 기업은 얼마나 많을까?

Fri, 30 Oct 2015 15:00:01 GMT

언젠가 모 회사 분과 이야기를 하다 그런 말을 들었다. 회사가 어려운데 구조조정을 하지 않는 이유 중에 하나가 대표의 욕심 때문이라는 이야기였다. 대표가 일정 수준 이상이 되는 규모로 회사를 유지하려는 욕심이 있다는 말이었다. 100인 기업, 100억 매출 이런 상징적인 이미지를 가지고 싶어한다는 말이었다. 난 상징적인 이미지보다는 실속을 더 따지는 편이라 100명이서 100억 버는 회사 보다는 2명이서 3억 버는 기업이 더 좋을텐데라는 생각을 했었다. 그리고 막연하게 100명, 100억 하는 회사가 흔하지는 않아도 자부심을 가질만큼 귀하지는 않을 것 같다고 상상했다.

그런데 현실은 아니었다. 어제 팩트 체크를 보다가 우연히 아주 충격적인 사실을 알게 되었기 때문이다. 사업 분야를 불문하고 우리나라에 존재하는 모든 기업 중에 100인 이상의 종업원을 고용한 기업이 무려, 당황스럽게도 0.8%밖에 되지 않는다는 사실이었다. 아래 그림처럼 말이다. 8%도 아니고, 무려 0.8%다. 소프트웨어 기업은 일반적인 기업보다 보통 작은 규모인 경우가 많으니 100인 기업은 비율이 훨씬 더 낮을지도 모른다. 더 충격적인 사실은 10명 이상 고용한 사업체도 전체 기준으로 봤을 때는 상위 15% 안에 포함된다는 사실이다. 30인 이상은 상위 4%에 포함된다. 헐~

JTBC 팩트 체크

팩트 체크니까 구라 자료는 아닐꺼라 생각했지만 0.8%는 다소 충격적이었다. 그리고 화면에는 나오지 않은 30-49인, 50-99인의 세부적인 비율도 궁금해서 좀 찾아봤는데 아마도 JTBC의 자료는 고용노동부에서 발표한 아래 자료에 기반하고 있는 것으로 보였다. 아래 자료 수치대로하면 30-49인은 전체 사업체 중에 2%를, 50-99인은 전체 사업체 중에 1.25%를 차지한다.

고용노동부 2013 기업 규모별 사업체수 통계

그런데 뭔가 좀 이상하다. 100인 이상 기업이 전체의 0.8% 밖에 되지 않는데 내 주변 사람들은 거의 대다수가 100인 이상 기업에 다니기 때문이다. 그건 사업체 수가 아닌 해당 사업체에서 근로하는 근로자수를 비교해야 비로소 의문이 풀린다. 옆에 있는 상용 근로자를 기준으로 데이터를 뽑아보면 아래와 같이 나온다. 100인 이상 기업체 수는 전체 기업체에서 0.8%를 차지하지만 해당 업체에 근무하는 상용 근로자 수는 전체 근로자에서 27%를 차지한다. 그러니 100인 이상 기업에 근무하는 사람은 쉽게 찾을 수 있는 것 같다.

기업 규모별 종사자수 계산

다시 앞으로 돌아와 보면 몇 해 전 내가 했던 상상은 현실이 아니었다. 100인 이상 종업원을 가진 기업은 나의 상상보다 훠얼씬 더 작았다. 0.8%라니, 거기다 그 인원으로 100억 매출을 하는 회사는 훠얼씬 더 작을지도 모른다. 대표 입장에서는 충분히 가지고 싶을 만한 상징적인 이미지라는 생각이 들었다. 물론 회사 외형이나 규모가 전부는 아니지만 말이다.

[cpp] 실시간 자식 윈도우 크기 조정

Tue, 18 Aug 2015 15:00:01 GMT

#define    SC_SZLEFT           (0xF001)              // resize from left
#define    SC_SZRIGHT          (0xF002)              // resize from right
#define    SC_SZTOP            (0xF003)              // resize from top
#define    SC_SZTOPLEFT        (0xF004)              // resize from top left
#define    SC_SZTOPRIGHT       (0xF005)              // resize from top right
#define    SC_SZBOTTOM         (0xF006)              // resize from bottom
#define    SC_SZBOTTOMLEFT     (0xF007)              // resize from bottom left
#define    SC_SZBOTTOMRIGHT    (0xF008)              // resize from bottom right
#define    SC_DRAGMOVE         (0xF012)              // move by drag

위에서 정의된 상수들은 WM_SYSCOMMAND의 WPARAM으로 전달될 때 그 진가가 발휘됩니다. 상수가 의미하는 바는 위의 주석에 잘 나와있습니다. 위에서부터 표준 윈도우의 8방향에서 사이즈를 변경하는 것과 마우스 이동 시 사용할 수 있는 메시지입니다.

그럼 도대체 위 메시지를 윈도우에 전달하면 어떤 일이 일어나는지 살펴봅시다.

SendMessage(hwnd, WM_SYSCOMMAND, SC_DRAGMOVE, 0);

만약 위와 같이 메시지를 보낸다면, hwnd라는 핸들을 가진 윈도우의 위치는 그때부터, 마우스를 드래그 하는 방향으로 위치가 변경됩니다. 윈도우가 자식이든 아니든 상관 없습니다. 단지 메시지를 받은 윈도우는 마우스의 변화에 맞게 저절로 위치가 변경되는 겁니다.

이러한 방법은 자식 윈도우의 위치를 제어할때에도 유용하지만, 캡션과 프레임을 없앤 스킨이 들어간 다이알로그를 제어할때에도 유용하게 사용할 수 있습니다. 제공되는 샘플 소스에는 실행 시간에 8방향에서 사이즈를 변경하는 것과 마우스 드래그에따라 움직이는 Static 윈도우를 보여주고 있습니다.

//! Static에서 WM_LBUTTONDOWN이 발생했을때 오는 통시 메시지
//! \param wParam 은 컨트롤 아이디 이다.
//! \param lParam 은 사용되지 않는다.
LONG CdynresizeDlg::OnMsgStLBDn(WPARAM wParam, LPARAM lParam)
{
    switch(wParam)
    {
    case IDC_MOVE:
        ReleaseCapture();
        // 드래그하면서 움직이는 메시지를 날린다.
        SendMessage(WM_SYSCOMMAND, SC_DRAGMOVE, 0);
        break;

    case IDC_RESIZERB:
        ReleaseCapture();
        // 오른쪽 아래를 드래그 하면서 사이즈가 변경되는 메시지를 날린다.
        SendMessage(WM_SYSCOMMAND, SC_SZBOTTOMRIGHT, 0);
        break;
    }
    return 0;
}

[시스템] 엄격함과 느슨함 그 사이 어디쯤...

Mon, 29 Jun 2015 15:00:01 GMT

몇 해 전 지인이 앱스토어 카테고리 1등을 먹어서 아주 수입이 짭짤했다는 이야기를 들었다. 사촌이 땅을 사면 배가 아프게 마련이고, 주변에서 누군가 뭔가를 이루면 자연스레 나도 할 수 있을 것 같다는 근자감에 불타오르게 된다. 야심차게 앱스토어 개발자 등록을 했었다. 소녀시대 퍼즐 앱을 만들겠다는 포부를 가지고는 자료를 수집하기 시작했는데 딱 거기서 끝났다. 한줄의 코딩도 없었고, 공부도 하지 않았다. 내가 개발자 등록을 하고 유일하게 한 거라곤 iOS 베타 버전을 먼저 설치해 보는 정도였다. 돈이 아까워서 설치한 베타 버전이었다. 하지만 엎친 데 덮친 겪으로 베타 버전에 버그가 많아서 그마저도 계륵같은 존재였다. 돈이 아까웠지만 맥북을 사지 않았다는데 마지막 위안을 삼았다. 그렇게 앱 개발은 레드오션이라며 여유가 신포도를 다루듯 나의 머릿속에서 영영 멀어졌다.

그렇게 영원히 잊혀질 것 같았던 앱 개발을 작년 말부터 친구 녀석이 나에게 다시 세뇌시키기 시작했다. 자기 주변에서는 다 앱 개발을 해서 대박을 쳤다는 이야기였다. 처음 한두번은 그냥 웃어 넘겼지만 녀석의 집요한 이야기 끝에 난 세뇌돼 버렸다. 그러던 한 날 밤이었다. 핸드폰을 만지작 거리며 침대에서 다큐를 보고 있는데, 이놈에 다큐 홈페이지 네비게이션 시스템이 당췌 어이가 없을 정도로 불편한 것이었다. 평소 좋아하던 다큐였기에 그날 코딩에 들어갔다. 그래 이 다큐를 나처럼 편하게 보고 싶어 하는 사람이 얼마나 많겠어 하면서 코딩을 했고 몇 일 사이 베타 버전이 나왔다. 풉, 혼자 만족해 하면서 스토어에 올렸다. 반응은 냉랭했다.

친구 녀석한테 하소연을 했더니 그런건 너같은 사람이나 보는 거고, 게임 동영상을 보는 게 훨씬 잘 될 거라는 이야기를 했다. 똑같은 앱에 컨텐츠만 바꿔서 올렸다. 다큐가 게임으로 바뀐 앱이었다. 어랏, 그런데 제법 사람들이 다운 받기 시작했다. 광고 수입도 올라온다. 노트북을 질렀다. 설 연휴에 본격적으로 개발해 보겠다는 심산이었다. 그런데 거기서 끝났다. 생각보다 잔손이 너무 많이 갔고, 좀 하다 보니 재미가 없어졌다. 재미난 사실은 그렇게 앱 업데이트를 끊은지가 어언 몇 달이 지났는데도 지금도 꾸준히 광고 수입이 발생한다는 점이다. 이대로 계속 간다면 손익 분기점은 40개월 남았다. 올레, 핡~

#0

돈은 못 벌었지만 안드로이드 앱 프로그래밍은 나에게는 신선한 충격이었다. 충격이었다는 말은 배울 것도 많았고, 생각할 거리도 여럿 제공을 했다는 말이다. 그 중에 한 가지를 이야기 하려고 한다. 최근에 페북 앱이 링크를 브라우저로 돌리지 않고 직접 내장 웹뷰에서 보여주는 방식으로 변경해서 테스트를 해보았는데 페북 웹뷰에도 이 처리는 포함되지 않은 것으로 보여진다.

거창하게 말했지만 사실 요는 간단하다. 아래 페이지처럼 페북 내장 웹뷰에서 제대로 렌더링이 되지 않는 페이지가 있다는 것이다. 지금 모바일 환경이라면 여기서 테스트를 해볼 수 있다.

웹뷰에서 인벤 동영상 링크는 어디로 사라진 것일까???

원래 저 비어있는 자리에는 유튜브 동영상이 나와야 함에도 나오지 않고 있는 것이다. 아마 첨에 이런 일을 당하면 아 모바일을 지원하지 않나 보구나 라고 생각하기 쉽상인데, 크롬으로 들어가보면 기가막히게 보인다. 도대체 왜? 그래서 웹뷰는 뭐 한계가 있나보다 하고 넘어가려고 해도 뭔가 찜찜하다. 왜냐하면 오페라나 파이어폭스에서도 정상적으로 보이지 않기 때문이다. 그렇다면 크롬이 무슨 특수한 처리를 해주고 있다는 것인데… 도대체 크롬은 무슨 짓을 하고 있는 것일까?

그냥 크롬이 외계인과 접촉했다고 넘어가기에는 용납이 되지 않았다. 난 너무 장인이니까 ㅋㅋㅋ~ 거기다 누구도 신경쓰지 않았지만 경쟁 앱에게 보여주고 싶었다. 난 웹뷰에서 인벤 동영상 페이지도 렌더링 하지롱, 이라고 말이다. 하지만 집요하게 검색했으나 관련 글을 찾기가 쉽지 않았다. 그렇게 한동안 이 문제에 대해서 제법 고민을 했는데 신이 가엽게 여기셨는지 어느날 갑자기 계시가 내리듯이 어떤 생각이 머리를 스쳤다. 그리곤 그 상상대로 만들어 봤는데 얼추 크롬과 비슷하게 동작하는 것을 볼 수 있었다. 하지만 그 결과는 날 재차 의문에 빠트렸다. 이게 과연 옳은 길일까라는 생각이 들었기 때문이다.

#1

우선 인벤의 동영상 링크를 보면 아래와 같은 구조로 소스가 코딩되어 있다. 플래시 플레이어를 사용하는 유튜브 링크다. 지금 유튜브 링크는 모두 iframe 형식으로 변경이 되었다. 즉, 인벤이 만든 이 코드는 예전 유튜브 코드로 모바일 환경에서는 적합하지 않은 코드다. 그러니 응당 보이지 않는 것이 정상일 것이다. 그러면 도대체 크롬은 어떻게 보여주고 있는 것일까?

<embed allowscriptaccess="never" width="650" height="366"
pluginspage="http://www.macromedia.com/go/getflashplayer"
src="http://www.youtube.com/v/l9yD5r1AsNo?version=3&amp;hl=ko_KR&amp;rel=0"
type="application/x-shockwave-flash" wmode="transparent" allowfullscreen="true"
allow&#83;criptaccess="never" style="width: 650px; height: 366px;">

내가 생각해 본 방법은 저걸 그대로 보여주는 건 말이 안 되니 저걸 통째로 고쳤을거란 생각이 들었다. 왜냐하면 어차피 저 코드에 렌더링할 페이지 주소는 모두 나와 있기 때문에 iframe으로 대체 시키는 것이 어렵지 않기 때문이다. 바로 아래와 같이 말이다. 아래 코드는 문서에 있는 embed를 죄다 찾아서 iframe으로 변경하는 일을 한다. 실제로 안드로이드 웹뷰에서 인벤 페이지를 로딩한 다음 아래 자바스크립트를 샤샥 돌려주면 깔끔하게 비디오 화면이 출력되고 재생도 된다.

var elem = document.getElementsByTagName('embed');
for(var i=0; i < elem.length; ++i)
{
	var obj = document.createElement('iframe');
	obj.style.width = elem[i].style.width;
	obj.style.height = elem[i].style.height;
	obj.frameBorder = '0';
	var url = elem[i].src.replace('/v/', '/embed/');
	obj.src = url;
	elem[i].parentNode.replaceChild(obj, elem[i]);
}

#2

그냥 단편만 살펴본다면 크롬의 이 재치있는 생각은 나쁠게 없어 보인다. 모바일 준비가 되지 않은 유튜브 링크를 포함한 거의 모든 사이트를 정상적으로 렌더링할 수 있게 만들어주니까 말이다. 하지만 다른 한편으론 나빠 보이기도 한다. 페이지 제작자가 자신이 실수했다는 사실을 인지하기까지 시간을 오래 걸리도록 만든다는 점을 첫번째 문제로 들 수 있다. 왜냐하면 잘못됐다는 사실을 즉각 알려줘야 빨리 고칠 수 있는데 저런 식으로 내부적으로 변형시키는 과정을 통해서 페이지가 정상적으로 렌더링돼 버리면 제작자 입장에서는 문제가 없는 것으로 오해할 수 있기 때문이다. 두번째 문제는 더 심각한데 이런 문제들이 심화되면 사용자들이 특정 브라우저에 강하게 종속될 수 있다는 점이다. 에고가 강한 페이지 제작자가 크롬에 최적화 됐고 다른 브라우저가 이상하다고 말하는 상황을 예로 생각해 볼 수 있겠다. 그렇다면 그 페이지를 꼭 이용해야 한다면 크롬을 사용할 수 밖에 없다. 어디서 많이 본 장면 같지 않은가? 맞다. 인터넷 익스플로러의 몇 년전 모습이다. 그때도 IE는 모질라에서 주구장창 오류를 뿜어대는 스크립트들도 무슨 재준지 기가 막히게 오류 없이 돌려주곤 했었다. ActiveX는 말할 것도 없다. 이제는 그 자리를 크롬이 메우고 있는게 아닐까라는 생각이 잠시 들었다.

가용성과 하위호환성을 위해서 얼마만큼 느슨해져야 하는 것일까? 또 표준을 지키기 위해서 얼마만큼 엄격해져야 하는 것일까? 물론 여기에 답은 없다. 어떤 사람들은 가용성과 하위호환성에 더 높은 가치를 두기도 하고, 또 어떤 사람들은 순결한 상태에 더 높은 가치를 두기도 한다. 다만 프로그래머 입장에서 한 가지 바램이 있다면 업계를 주도하는 키 플레이어들은 좀 엄격해졌으면 하는 바램이다. 왜냐하면 그들만이 사용자를 변화시킬 힘이 있기 때문이다. 하지만 실상은 메이저 업체들은 계속 알 수 없는 파편화를 주도하고 정작 힘없는 오픈소스들만 표준을 잘 지키는 형국인것 같아 씁쓸한 기분이 든다.

-- 2014.06.20

다행이도 이 글을 쓰는 사이 (적어도 12개월+) 인벤은 페이지를 고쳤다.

[cpp] MmProbeAndLockPages/MmMapLockedPages 함수에 관한 고찰

Fri, 26 Jun 2015 15:00:01 GMT

일반적으로 커널 모드 드라이버에서 사용자 영역의 주소를 고정시키기 위해서는 아래와 같은 함수 호출을 사용한다.

mdl = IoAllocateMdl(address, size, ...);  
MmProbeAndLockPages(mdl, UserMode/KernelMode, ...);  
kptr = MmMapLockedPages(mdl, UserMode/KernelMode, ...);  
  
// kptr을 통해서 유저 메모리 address에 접근할 수 있음  
  
MmUnmapLockedPages(kptr, mdl);  
MmUnlockPages(mdl);  
IoFreeMdl(mdl);

MmProbeAndLockPages/MmMapLockedPages 두 함수 모두 인자에 KernelMode/UserMode가 들어간다. 그런데 그 친절한 MSDN 조차도 이 값을 어떻게 지정해야 하며, 그게 어떤 효과를 가져오는지에 대해서 자세히 설명을 해주지 않고 있다. 단지 MmMapLockedPages의 두 번째 인자는 드라이버라면 대체로 KernelMode를 지정하면 된다 정도의 코멘트만 있다. 심각한 문제는 설명이 이렇다보니 블루스크린이 발생하면 이 값을 막 바꿔주다 발생하지 않는 값이 있다면 아 이렇게 쓰는거구나 하면서 엉뚱하게 변경해 버리는 일이 생긴다는 점이다. 헐~ 대박… 여튼 그래서 각 함수의 KernelMode/UserMode의 의미에 대해서 살펴보는 시간을 가져볼까 한다.

MmProbeAndLockPages에 두번째 인자는 mdl이 가리키는 영역이 사용자 주소 공간인지 커널 공간인지를 판별하기 위해서 사용된다. UserMode를 넣게 되면 MmProbeAndLockPages 함수가 실질적인 동작을 하기 전에 mdl이 가리키는 영역이 사용자 영역을 벗어나는지 벗어나지 않는지를 점검하는 코드가 추가적으로 실행된다. 만약 사용자 접근 공간(일반적으로 4G 32비트 시스템에서 2G까지)을 벗어나는 영역을 포함하고 있으면 실질적인 동작을 수행하지 않고 ACCESS_VIOLATION 예외를 발생시킨다.

MmMapLockedPages 함수의 모드 파라미터는 MmProbeAndLockPages와는 다른 목적이다. 이 함수에서 KernelMode/UserMode가 결정하는 일은 최종적으로 생성될 kptr이 유저 영역에 매핑될지 커널 영역에 매핑될지 결정하는 역할을 한다. 즉, 이 파라미터는 mdl이 가리키는 메모리 공간과는 전혀 상관이 없다. 최종적으로 우리가 사용할 포인터를 어느 영역 주소로 정할 것인지를 지정하는 역할을 한다. 그러니 드라이버라면 응당 KernelMode를 쓰는 것이 일반적일 것이다.

여기서 벌어지는 BSOD의 관전 포인트는 MmProbeAndLockPages 함수로 커널 영역을 가리키는 쓰레기 포인터가 넘어간 경우에 발생한다. 이 경우에 KernelMode가 인자로 넘어갔다면 논페이지드 영역에서 잘못된 참조가 발생할 수 있고 그랬다면 BSOD로 이어진다. 반면에 쓰레기 포인터가 넘어오더라도 UserMode를 지정했다면 커널 영역을 가리키는 포인터이기 때문에 ACCESS_VIOLATION 예외가 발생하고 __try/__except로 예외를 잡아서 동작을 지속시킬 수 있다. 이 경우에 설명이 부실하다보니 쓰레기 포인터가 넘어온 걸 고쳐야 함에도 UserMode로 파라미터를 바꾸고는 아주 이상한 경우에 발생하는 커널 모드 문제를 해결했다며 커밋을 하는 어처구니 없는 경우가 발생한다. 뉴요커 프로그래머라면 이런 실수를 하지 않도록 주의하자~~~ @.@

의외로 이런 경우가 많다.

[시스템] 변태 패커, Upack

Fri, 26 Jun 2015 14:00:01 GMT

PE 포맷의 각종 잘(?!) 사용되지 않는 Size 필드들을 가지고 장난쳐서 파일을 오버레이 시키곤 하는 변태 패커 중에 Upack이 있다. 자세한 설명은 이 글을 참고하도록 하고,… 언젠가 나도 한 번 당했었는데 웬만한 필드는 다 계산해서 사용하기에 문제가 없다고 생각했는데 섹션 헤더를 구하는 부분에 문제가 있었다. 흔히 별 생각 없이 아래와 같은 코드를 사용하고 있었는데 이게 Upack으로 패킹된 파일에는 문제가 된다.

PIMAGE_NT_HEADERS nt = 적절한 NT 헤더 포인터;  
PIMAGE_SECTION_HEADER sec;  
sec = (PIMAGE_SECTION_HEADER) GetPtr(nt, sizeof(*nt));

OptionalHeader에 SizeOfOptionalHeader 필드가 있는데 그 값이 일반적인 값이라면 위 코드는 큰 문제 없이 동작한다. 그런데 Upack은 다르다. SizeOfOptionalHeader를 가지고 장난질을 치기 때문에다. 그래서 아래와 같이 해당 필드 값을 토대로 계산을 해 주어야 정확한 섹션 헤더 위치를 얻을 수 있다.

#define \  
GetSectionHeaderFromNt(nt) \  
((PIMAGE_SECTION_HEADER) \  
GetPtr(&(nt)->OptionalHeader, (nt)->FileHeader.SizeOfOptionalHeader))

덧) 자매품 UPX의 함정도 있다 ㅋㅋ~

[소고] 시작하는 프로그래머를 위한 10원짜리 조언 몇 개…

Mon, 22 Jun 2015 15:00:01 GMT

개인적인 경험에 기반에 쓴 것이니 너무 심각하게 받아들이진 말자. 모든 글이 그렇지만 취할건 취하고 버릴건 버리면 된다. 직접 해보니 도움이 된 것들도 있고, 지금 시점에 돌아보니 했었으면 더 좋았을 것 같다고 느낀 것들도 있고 그렇다. 참고로 태생적으로 머릿속에 포인터와 재귀 호출 스택 프레임이 내장된 프로그래머들을 위한 글은 아니라는 점 명심하자!!! (자매품 개발자를 위한 드래곤볼)

#0

연애를 하자. 일반적으로 프로그래머들의 커뮤니케이션 스킬이 다른 직종 사람들에 비해서 떨어지는 것은 사실이다. 인정할 건 인정하자. 그런 점들을 보완해주는데 연애만큼 좋은게 없다. 자신의 바닥도 보고 겸손해지기도 한다는 점에서 여러 좋은 점들이 있으니 프로그래밍 공부만큼 연애에도 관심을 가지고 꼭 해보기를 추천하고 싶다. 특히 요즘은 돈 든다고 안 하는 추세도 있는것 같은데 그 돈 투자해 보는게 손해는 아닌 것 같다.

#1

빨리 시작하는 편이 유리한 건 어쩔 수가 없다. 대학교때 컴퓨터 학원에서 C언어를 일년정도 가르친 경험이 있다. 그때 난 어른과 어린 학생들 사이의 명백한 차이가 있는 걸 알게 되었다. 어른들은 무엇인가 자신이 납득할 수 있는 이유가 없다면 잘 받아들이지를 못하고, 또 지루한 과제를 반복하지 못한다는 특징이 있다. 천재 프로그래머인 리누스 토발즈도 그의 자서전에서 밝혔지만 처음 작성한 프로그램은 Hello, World였다. 어린 학생들은 그 단순한 Hello, World 조차도 글자를 바꿔가면서 만드는 과정에서 재미를 느끼는데 어른들은 그렇지가 않다. 그래서 연습이 부족해질수밖에 없고 그러니 당연히 진도가 더디다. 어리다는 것은 지루한 것도 반복할 만큼 호기심이 많다는 것을 의미하기 때문에 지루한 초반 과정을 버티는데 정말 좋다. 더불어 시간이 많다는 것도 장점이다.

#2

늦게 시작했더라도 체력이 좋다면 다행이다. 고등학교 때 알던 녀석 중에 한 명이 2년 내도록 놀다가 3학년 때 일년 바짝 공부 해서 의대를 갔었다. 사실 그 누구도 그 친구가 의대에 진학할 것이라고는 생각지도 못했었기에 다소 충격이었다. 물론 같이 놀았던 친구 녀석들은 부러워 한 정도로 끝났지만 3년 내도록 공부하고 수능을 망친 친구들의 상실감은 이루 말할 수가 없었다. 그 의대에 간 녀석의 장점은 강철 체력이라는 점이었다. 남들이 하루 밤샐 수 있다면 녀석은 3일쯤은 거뜬히 멀쩡하게 밤샐 수 있었다. 대학교 때에도 비슷한 선배가 있었다. 늦게 프로그래밍을 시작했는데 전산소에서 일주일씩 밤새는건 기본인 선배였다. 이상엽씨가 쓴 Visual C++ 6.0 바이블 한글 파일을 들고 다니면서 하루종일 전소에 앉아서 코딩을 하곤 했었다. 난 다소 의아했었는데 지금은 MIT에 유학을 갔던 정말 똑똑한 형이 옆에서 그랬다. 저렇게 체력이 좋은 아이들은 이길 수가 없다고… 그러니 체력 관리가 중요하다.

#3

책을 많이 읽는 것이 여러모로 도움이 된다. 책을 읽는다는 사실이 여러분을 더 똑똑하고 유능한 프로그래머로 만들어준다는 것을 의미하진 않는다. 하지만 적어도 바보같은 프로그래머가 되지 않도록은 만들어 준다는 점에 50원 정도는 걸 수 있을 것 같다. 그러니 책을 부지런히 읽자.

책을 많이 읽지 않는 사람들이 하는 흔한 실수 중에 하나가 이해가 되지 않는다고 계속 1장만 보는 것이다. 모든 것은 유기적으로 연결되어 있으니 당장 이해가가지 않는 부분이 있더라도 냅두고 끝을 향해 달려가자. 끝을 보고 나면 자연스레 1장은 저절로 이해가 되기 마련이다. 참고로 그때도 이해가 되지 않으면 한번더 끝까지 보면된다.

#4

영어를 잘하는 것이 막판 광역 버프를 받는 지름길이다. 직업 프로그래머를 하면서 다양한 프로그래머들을 만났다. 그중에 더러는 늦게 프로그래밍을 시작한 사람도 있었고, 나보다 훨씬 더 일찍 시작한 사람도 있었다. 그런데 한 가지 신기한 사실은 처음에는 실력 차이가 많이 나는데 한 3년 정도가 지나면 거의 실력이 비슷해진다는 점이었다. 그때부터는 누가 언제 시작했는지 보다는 해당 도메인 지식을 누가 더 빨리 습득할 수 있는가가 실력을 결정짓는 주요한 요소가 된다. 안타깝게도 거의 모든 프로그래밍 자료는 영어인 경우가 대부분이다. 따라서 나중에 줄창나게 버프를 받기 위해서는 영어는 필수적으로 할 수 있어야 한다.

#5

대학 교육을 받은 프로그래머들 중 상당수가 기본적인 전산 지식을 중요하게 여기고 도메인 지식을 가볍게 여기는 경향이 있다. 하지만 아이러니하게도 대부분의 경우에는 기본적인 전산 지식보다는 도메인 지식이 중요하다. MS나 구글같은 회사에서 도메인 지식보다 기본 지식을 가진 똑똑한 직원을 뽑는다는 소리를 듣고 그게 중요하다고 생각하는 경우가 많다. 그런데 정말 아주 많이 안타까운 사실은 우리 대부분은 그런 똑똑한 사람들이 아니라는 것이다. 현실을 직시하자. 평범한 우리에겐 기본적인 전산 지식만 가지고 있는 상태에서 도메인 지식을 스펀지처럼 빠르게 빨아들이는 능력이 없는 경우가 상당수다. 그러니 자신이 하고 싶은 도메인을 일찍 정하고 해당 지식을 빨리 습득하는 것이 중요하다. 백신 업체에 취직하고 싶은데 그림판만 매일 만들고 있는건 도움이 되지 않는다는 말이다. 물론 이 말이 기본 지식이 중요하지 않다는 것을 의미하진 않는다. 컴퓨터 공학과에서 열심히 공부한 대다수 졸업생의 기본적인 전산 지식은 도찐개찐인 경우가 많기 때문에 그게 여러분을 돋보이게 만들어주지 않는다는 의미다.

#6

코드를 많이 읽는 것이 중요하다. 대학을 졸업한 대부분의 프로그래머가 오픈소스 프로젝트 코드를 수정하는 것은 둘째치고 읽지도 못하고 심지어는 빌드도 못하는 경우가 많다. 이는 정말 큰 문제다. 적어도 여러분이 직업 프로그래머를 하려고 한다면 기본적인 코드는 읽고 이해하고 수정하는 것이 가능해야 한다. 여러분의 경력 대부분의 시간 동안 새로운 코드를 쓰는 시간보다는 다른 사람이 이미 만들어둔 코드를 수정하고 고치는 작업을 하는 경우가 많기 때문이다. 남이 작성한 코드를 읽고 이해하는 능력이 없다면 직장 생활 자체가 매우 힘겨워질 수 있다. 자신이 주력하는 분야의 오픈 소스 코드를 매일 일정 분량 이상씩 읽도록 하자. 물론 참여하기까지 한다면 금상첨화다.

#7

코드를 읽는 것 만큼이나 쓰는 것도 중요하다. 많은 사람들이 생각을 잘 하면 코딩도 잘 할거라 전제하는데 생각하는 것과 코딩하는 것은 조금 다른 측면이 있다. 머리보다 손이 기억한다는 말이 있다. 그러니 알고 있는 것이라도 반복적으로 구현해 보는 것이 좋다. 그리고 심심할 때 유용하진 않더라도 작은 프로그램을 직접 많이 만들어 보도록 하자. 코딩도 연습할 수 있고 전체 프로젝트를 기획부터 릴리즈까지 해볼 수 있는 좋은 훈련이 된다.

#8

블로그나 위키를 만들자. 그리고 그곳에 자신이 공부한 것들을 정리해서 올려놓자. 이건 정말이지 여러가지 장점이 있는데 1) 세상 사람들이 내가 무슨 일을 했는지 알 수 있게 해준다, 2) 긴 글을 작성하는 훈련을 할 수 있다, 3) 나만의 지식 기반을 구축할 수 있다, 등등 장점은 수도 없이 많다. 그러니 꼭 이 활동을 지속적으로 하자. 보는 사람이 없어도 꾸준히 하는 것이 중요하다. 그리고 본인 생각에 정말 보잘것 없는 것들도 무조건 올리도록 하자. 우리가 구글링해서 알 수 있는 대부분의 지식은 다른 사람들이 그렇게 별 볼 일 없다고 생각하면서 올려둔 지식인 경우가 대다수다. 하찮다 생각하지 말고 꾸준히 정리하고 공개하는 습관을 들이도록 하자.

#9

다양한 문화 생활을 경험해 보자. 드라마도 보고, 영화도 보고, 미술관도 가고, 뮤지컬도 보고, 음악회도 가고, 콘서트도 가고, 만화책도 보고, 게임도 하자. 다 피가 되고 살이 된다. 개그콘서트와 웃찾사를 보는게 꼭 시간 낭비만은 아니다. 오히려 컴퓨터만 주구장창 하는 사람들보다 더 넓은 시각을 가질 수 있게 만들어 준다는 점에 100원은 걸 수 있다. 파이썬 개발자 귀도 반 로섬도 몬티 파이썬의 팬이었다. 그러니 맘놓고 보자. 스트레스 해소도 하고… ㅋㅋㅋ~

#10

컴퓨터 공학과를 졸업한다고 모두 프로그래머가 되어야 하는 것은 아니다. 컴퓨터를 좋아한다고 프로그래머가 되어야 하는 것도 아니다. 그리고 심지어는 프로그래밍이 좋다고 직업 프로그래머가 될 필요가 있는 것도 아니다. 직업 프로그래머가 되는 것에 관해서 진지하게 생각해보자. 그리고 학교에서 시간이 있을 때 아르바이트던 인턴이던 직업 프로그래머로써의 경험을 조금은 가져 보는 것이 좋을 것 같다. 돈을 받고 프로그래밍을 한다는 것이 어떤 느낌인지에 대해서 약간은 알아둘 필요가 있기 때문이다. 아마도 재미삼아 만들때와는 사뭇 다른 느낌인 경우가 많을 것 같다.

[소고] 와우와 롤은 불법 프로그램이 없을까?

Fri, 19 Jun 2015 23:59:59 GMT

SNS에 모 분이 게임업계 `불법 프로그램`과의 전쟁 선포라는 링크와 함께 와우나 롤처럼 앵벌이 아닌 게임을 만들라는 조언을 붙여놨다. 와우나 롤처럼?! 문득 든 생각이 와우나 롤 해보시긴 하셨나요, 라는 질문을 팍 던지고 싶었다.

요즘 와우는 몰라도 예전 와우의 경우는 정말 오토 돌리기 좋은 게임이었다. 난 것도 모르고 매번 레이드 갈 때 마다 낚시를 손수 꼬박 꼬박 했는데 오토를 돌리고 나서는 신세계를 경험했다. 자고 나니 가방에 물고기가 넘쳐났기 때문이다. 이래서 오토, 오토 하는구나 싶었다. 그간의 그 상대적 박탈감이란 ㅋㅋㅋ~

블리자드도 이를 모르진 않는다. 그래서 봇 제작사에 소송을 걸기도 한다. 하지만 이런 경우는 널리 널리 퍼진 봇인데다 영리성을 추구하는 경우만 해당하는 것이고, 사용자들끼리 만들어서 공유하는 것까지 근절하기는 상당히 힘든 실정이다. 직접 개발한 warden이란 보안 솔루션도 탑재하고 있지만, 성능은 물음표(?) 정도로…

롤은 전략/액션 게임이니 덜할 것 같지만 더하다. 원래 사용자끼리 승패를 가르는 게임에 핵이 더한 법이다. 왜냐하면 승부에 집착하게 되기 때문이다. “롤 핵”으로만 검색해도 절찬리 성업중인 다양한 불법 프로그램들이 나온다. 절망적인 사실은 롤은 스킨/캐릭을 팔아서 돈을 버는 구존데, 그걸 봉인 해제시키는 무료 툴도 존재한다. 물론 유료로 사는 핵들은 기능이 훨씬 강력하다. 거의 반자동 게임이 가능할 지경인 수준… 롤 커뮤니티에서도 관련된 불만은 수도 없이 제기됐고, 라이엇도 이를 모르진 않는 것 같다. 어떻게 대응을 하는지는 지켜볼 문제지만 말이다.

워크래프트2 모뎀 플레이 시절엔 디스컨넥트에게, 디아블로1을 즐기던 때에는 트레이너에게, 스타크래프트가 유행하던 시기엔 맵핵에게 고통 받았습니다. 월드 오브 워크래프트에 빠져 있던 시기에는 오토봇에게 상대적 박탈감을 느낄 수 밖에는 없었습니다. 블리자드 키드를 자처할 만큼 게임에 푹 빠져 살았지만 온라인 게임 속에는 항상 해킹이 공존했습니다.

무턱대고 일단 까고 보고 외산 게임이라고 괜찮을 거 같다는 생각은 좀 버리는 게 좋지 않을까라는 생각이다. 이런것도 일종의 사대주의가 아닌가라는 생각까지 들 지경이다. 회사 홈페이지에 나와 있는 그 블리자드 키드가 나인데, 진짜 블리자드 게임만 줄창나게 했지만 “불법 프로그램”이 없었던 시점은 단 한 차례도 없었다. 이 세상에 존재하는 온라인 게임치고 불법 프로그램으로부터 자유로운 게임은 없다는 생각이다. 만약 있다면 그 누구도 불법 프로그램을 제작할 만큼의 값어치를 못 느끼는 게임일 가능성이 높지, 보안이나 게임성이 우수해서라고 보기는 힘든 것 같다. 범죄와 마약이 없는 국가를 찾기가 힘든 것과 같은 이치 아닐까나?!

덧) 게임 내 불법 프로그램 근절에 관심이 많으신가요? 그럼 이 글도 함께 읽어보시길 감히 추천드립니다.

[소고] 물리적인 한계들…

Fri, 19 Jun 2015 23:59:58 GMT

초등학교 때 였다. 요즘은 PC방에 거의 자취를 감춰 버렸지만 그 당시만 해도 아케이드 게임을 들여놓은 오락실이 동네마다 엄청 많이 있었다. 100원 짜리 동전 한두개를 가지고 오락실을 가면서 난 항상 고민에 빠지곤 했다. 그 부족한 자원을 가지고 오락실에서 가장 오래 시간을 때울 수 있는 방법을 찾아야 했기 때문이었다. 인기 있는 게임을 하는 것은 재미는 있었지만 위험 부담이 너무 컸다. 중학생이나 고등학생 형들이 연결하기 일쑤였고, 나의 황금같은 100원은 순식간에 하늘 나라로 증발해 버리기 때문이었다. 그래서 구석 한켠에 아무도 하지 않는 오래된 RPG 게임을 하면서 시간을 죽이기도 했다. 나름 최적화된 투자였다.

세월이 흘렀고, 세상은 많이 변했다. 그때는 G.O.D 가사에 나오는 것처럼 대부분의 집들에서 자장면이 외식 메뉴였지만 요즘은 웬만한 가정에서는 집밥 보다도 못한 메뉴로 전락해 버렸다. 거리에 차도 늘었고, 고급 레스토랑도 늘었고, GDP도 눈에 띄게 늘었다. 그런데 아이러니 하게도 모든게 풍족해 보이지만 여전히 우리는 늘 리소스 부족에 시달린다. 컴퓨터도 그렇다. 난 486 컴퓨터에서 C 프로그램을 짤 때에도, 펜티엄에서 짤 때에도, 듀얼코어에서 짤 때에도, 항상 리소스는 부족했다. 게임보안 제품을 만들면서는 더 심해졌다. 게임이란 것이 원체 헤비 프로그램이기 때문에 동시에 돌아갈려면 CPU 점유율 0.01%에도 쩨쩨하게 굴어야 하고, 메모리를 아끼기 위해서 고속 서칭 알고리즘을 포기해야 하기도 한다. 그래도 이런 것들은 비교적 귀여운 축에 속하는 고민이었다는 것을 난 최근에야 깨달았다. 물리적인 한계가 있다는 사실을 속속 깨달았기 때문이다.

#0

최근에 GIT 저장소를 UTF-8로 업그레이드 하는 작업을 단행했다. 이전 버전의 GIT의 경우에는 UTF-8을 지원하지 않아서 일부 한글 파일들이 제대로 저장소에 업로드가 되지 않는 문제가 있었다. UTF-8로 된 저장소로 변경하고 나서는 그런 일이 없었다. 업그레이드 작업은 무척이나 간단한 명령어 몇 개로 가능했지만 안타깝게도 이 작업은 애꿏은 나의 하루를 모두 소비해 버렸다. 문제는 이랬다. 우리는 4-5년 전에 구매한 델 서버를 소스 저장소로 사용하고 있었다. 뭐 델 서버라고 하는데 뭔가 엄청난 건 아니고 그냥 좀 더 견고하게 만들어진 그런 하드웨어일 뿐이다. 성능이 특별히 뛰어나거나 하지는 않다. 그간 이 서버는 단 한 차례도 문제를 일으킨 적이 없어서 잘 사용하고 있었다. 그런데 저장소를 업그레이드 하고 나서는 이상하게 저장소를 클론하는데 지나치게 오랜 시간이 걸렸다. 도대체 문제가 무엇인지 알 수 없었다. 당연히 내가 바꾼 거라곤 GIT 저장소 뿐이니 그 부분을 의심할 수 밖에는 없었다.

하지만 문제는 서버에 있었다. 우리가 구매한 델 서버는 4년이란 시간을 감안하더라도 놀랍게도 고작, 고작 1기가 바이트의 메모리가 달려 있었다. 그런데 더 놀라운 사실이 있다. 난 뭐 1기가 바이트라고 한들 GIT 저장소를 운영하는데는 충분한 메모리라고 생각했던 것이다. 그런데 그건 터무니 없는 나의 생각이었다. GIT 클론 명령은 오브젝트를 압축하는 작업을 하는데 그 작업 과정에서 엄청나게 많은 메모리를 요구했다. 문제의 그 저장소를 클론하려면 1기가에 육박하는 메모리가 필요했다. 만약 재수없게 동시에 두 사람이 클론하는 경우에는 시스템은 메모리 부족으로 그 어떤 서비스도 동작하지 않는 엄청난 사태가 발생했다.

그래 메모리 그 까이꺼 얼마한다고 늘리면 되는 것 아닌가, 라는 생각에 델 서버를 뜯었다. 하지만 현실은 그리 녹록치가 않았다. 뭔가 호환도 되지 않는 이상한 메모리가 하나 달려 있었기 때문이다. 다른 메모리를 끼우면 동작하지 않았다. 뜯어본 델 서버는 더 가관이었다. 보드부터 시작해서 당췌 확장 가능한거라곤 아무것도 없었다. 말 그대로 재앙이었다. 그냥 조립 피씨를 한 대 구매해서 옮겨야 겠다는 생각을 했다.

#1

XIGNCODE3는 별도 옵션 없이 로그 서버를 무상으로 제공한다. 고로 고객님들께서는 적용하는 그 순간부터 발생하는 모든 로그와 통계 정보를 실시간으로 볼 수 있는 아름다운 신세계를 경험할 수 있다. 그런데 후발 주자로써 제품의 차별성을 두기 위해서 시작한 이 정책이 생각보다 골치아픈 존재가 되었다. 왜냐하면 고객에겐 공짜로 제공되지만 우리는 공짜로 사용할 수 있는 것이 아니기 때문이다.

우리가 사용하는 서버는 IDC에 10Mbps에 물려있는데, 사실 이제껏 한번도 트래픽에 대해서 생각을 해본 적이 없었다. 그것도 이유인 즉슨 몇십만되는 동접 게임도 큰 문제 없이 로그를 받았기 때문이다. 그래서 와 웹서버는 짱짱맨 이러면서 트래픽은 기억의 저편으로 날려 보냈다. 그런데 그게 아니었다. 지난 주에 대규모 게임을 런칭하면서 웹 서버가 다운되는 어처구니 없는 상황을 경험했기 때문이다. 10Mbps에서 우리 웹 서버는 이 지경이었다. 남부순환로로 출퇴근을 해 보았다면 이래서는 안 된다는 걸 일찍 알았어야 할 일이다.

인간적으로 10Mbps 라인에 이게 무슨 짓이냐고 가비아에서 따질만도 하다.

일단 10Mbps라는 말은 10메가 비트를 일초에 전송한다는 말이다. 그러니 8로 나누면 초당 꼴랑 1.25메가 바이트를 전송할 수 있다는 결론에 도달한다. 60을 곱하면 분당 75메가 바이트를 전송할 수 있다. 우리 로그가 서버가 요구하던 용량은 게임에 따라 다르지만 헤비 게임을 기준으로 기존에 210메가 바이트 정도였던 거 같다. 그런데 75메가를 전송할 수 있는 라인에 그 정도는 버벅대면서 그럭저럭 돌아갔던 것이다. 이번에 추가된 게임은 트래픽 기준으로 분당 340MB메가 바이트를 필요로 했다. 그 지경이 되니 웹서버가 정지했다. 많은 고민을 했지만 피같은 돈을 들여 더 대역폭이 높은 라인을 사용하는 것 외에는 딱히 방법이 없었다.

#2

퇴근하러 나갔다가 배란다에서 커피를 마시는데, 새로 들어온 분석팀 직원이 담배를 피우러 와서는 묻는다.

너님: 서버 메모리 좀 올려주시면 안되요?

나님: 왜요?

너님: 계속 메모리 폴트 나요 ㅠㅜ~

나님: 2번 서버 아직도 그래요?

너님: 아뇨. 거의 전부 다 그래요.

나님: 헉. 그래도 메모리 추가는 안 되요. 서버 한 대당 메모리 1기가 추가하면 월에 만원 추가되거든요.

나님: 스크립트 새로 고쳐 놓을께요.

-- 2012. 07. 03.

지금도 가난하지만 정말 가난했던 시절 이야기다. 델 서버는 조립식 서버로 교체됐고, 올초에는 저장소를 github으로 변경했다. 가비아는 모두 클라우드 서비스로 옮겼고 더 이상의 회선 문제는 없다. 물론 트래픽 비용이 발생한다는 점은 추가됐다. 로그 서버 인스턴스도 겁 없이 하이엔드를 사용하기도 한다. 월 만원 때문에 파이썬 코드 최적화 시킨답시고 메모리 해제를 강제로 하는 방법을 찾지 않아도 되니 개발자 입장에서 많이 편해졌다. 물리적 한계에 봉착해 보면 돈이 있으면 많이 편하다. 그러니 일단 많이 벌고 볼 일인듯 ㅋㅋ~

[리뷰] 불편한 경제학

Thu, 18 Jun 2015 23:59:57 GMT

통상적으로 또 역사적으로 모든 이들이 같은 거래에 동의할 때 투자자들은 우려할 필요가 있다. – 오펜하이머펀드 수석 전략가 p167

친구가 부자가 되는 모습을 옆에서 지켜보는 것만큼 사람들의 안락과 판단력을 혼란스럽게 만드는 것은 없습니다. 차라리 친구 말고 다른 사람이 부자가 되는 것이 속 편합니다. – p227

과거를 공부하지 않는 사람들은 똑같은 오류를 되풀이하고, 과거를 공부하는 사람들은 오류에 빠지는 다른 길을 찾아낸다 – 찰스 울프 p291

세계 경제 차원에서 보면 환율의 자동조절기능을 통해서 어느 한 나라가 지속적으로 너무 많은 무역흑자를 독식하는 일이 방지되는 것입니다. – p441

국가의 진정한 부는 치러낸 고통의 크기에 비례한다. – p457

공황에서 살아남기 위해서는 다른 자산이 아니라 유일한 부인 화폐를 보유해야 합니다. – p586

“부채의 상환은 (실질) 부채잔액의 증가를 따라잡지 못하며, 부채를 갚을수록 더 많은 (실질) 부채가 쌓인다”고 했던 무서운 부채의 역설이 현실로 나타나고 있는 것입니다. – p582

– 불편한 경제학, 세일러

[cpp] PE 파일에서 매니페스트 추출하기

Thu, 18 Jun 2015 23:59:56 GMT

PE 파일의 매니페스트에는 많은 정보가 담겨 있다. 주요하게는 해당 실행 파일이 어떤 CRT와 바인딩이 되는 것인지, 또 해당 실행 파일을 실행하기 위해서 필요한 권한은 무엇인지 등의 정보가 담겨 있다. 그 외에도 실행 파일을 실행하는데 각종 필요한 정보가 계속 추가되고 있다. 매니페스트 파일을 지원하지 않는 컴파일러를 사용하던 시절에는 아래와 같은 매니페스트 xml 파일을 직접 작성해서 실행 파일의 리소스로 포함시켜줘야 했지만 요즈음 Visual Studio는 매니페스트 파일 생성을 도와 주고 있기 때문에 프로젝트 설정에서 각종 세부 사항을 설정하면 된다.

<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level='asInvoker' uiAccess='false' />
      </requestedPrivileges>
    </security>
  </trustInfo>
</assembly>

보안 프로그램을 만드는 경우에는 종종 이러한 매니페스트 파일의 내용의 추출이 필요할 때가 있다. PE 파일에서 직접 매니페스트 XML을 추출하기 위해서는 리소스 섹션을 참고하면 된다. 매니페스트 XML 파일의 PE 파일에 RT_MANIFEST 타입의 1번 리소스로 추가되기 때문이다. 로드된 모듈의 경우에는 FindResource 함수를 사용해서 손쉽게 해당 항목을 찾을 수 있지만 로드되지 않은 모듈의 경우에는 이 작업이 쉽지 않다. 이 경우에는 직접 PE 파일에서 리소스 섹션을 뒤져서 항목을 찾아야 한다. 아래 FindResourceDirectoryEntryWithId 함수는 rd 리소스 블록에 포함된 블록 중에 ID가 넘어온 id 파라미터와 일치하는 블록 정보를 찾아서 반환하는 역할을 한다. 해당 함수를 사용해서 루트 블록에서 RT_MANIFEST를 찾고, 그 다음 해당 블록의 1번 리소스를 찾으면 매니페스트 정보를 추출할 수 있다.

PIMAGE_RESOURCE_DIRECTORY_ENTRY
FindResourceDirectoryEntryWithId(PVOID root, PIMAGE_RESOURCE_DIRECTORY rd, USHORT id)
{
	PIMAGE_RESOURCE_DIRECTORY_ENTRY entry;
	entry = (PIMAGE_RESOURCE_DIRECTORY_ENTRY) GetPtr(rd, sizeof(*rd));

	ULONG cnt = rd->NumberOfNamedEntries + rd->NumberOfIdEntries;

	for(ULONG i = 0; i < cnt; ++i)
	{
		if(!entry[i].NameIsString)
		{
			if(id == entry[i].Id)
				return &entry[i]; 
		}
	}

	return NULL;
}

아래 GetManifestStringFromBuffer 함수는 PE 파일을 읽어들인 버퍼에서 매니페스트 문자열을 추출하는 방법을 보여주고 있다. 리소스 섹션을 찾은 다음 해당 섹션에서 RT_MANIFEST 블록을 찾고, 다시 1번 ID 블록을 찾은 다음 정보를 복사한다. 실행 파일에서 매니페스트 문자열을 추출하는 전체 프로젝트 소스 코드는 여기에서 다운로드 받을 수 있다.

BOOL
GetManifestStringFromBuffer(LPCVOID abuffer
								, SIZE_T buffer_size
								, LPSTR manifest
								, SIZE_T manifest_size
								, PSIZE_T required_size)
{
	ULONG sec_cnt = 0;
	PIMAGE_SECTION_HEADER sec = NULL;
	PIMAGE_DATA_DIRECTORY dd = NULL;
	PUCHAR buffer = (PUCHAR) abuffer;

	PIMAGE_NT_HEADERS32 nt32 = GetNTHeaders32(buffer, buffer_size);
	if(nt32)
	{
		sec_cnt = nt32->FileHeader.NumberOfSections;
		sec = GetSectionHeaderFromNT(nt32);
		dd = &nt32->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_RESOURCE];
	}
	else
	{
		PIMAGE_NT_HEADERS64 nt64 = GetNTHeaders64(buffer, buffer_size);
		if(nt64)
		{
			sec_cnt = nt64->FileHeader.NumberOfSections;
			sec = GetSectionHeaderFromNT(nt64);
			dd = &nt64->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_RESOURCE];
		}
	}

	if(!sec || !dd)
		return FALSE;

	PVOID rptr = GetPtr(buffer, dd->VirtualAddress);

	for(ULONG i = 0; i < sec_cnt; ++i)
	{
		PVOID sptr = GetPtr(buffer, sec[i].VirtualAddress);
		PVOID eptr = GetPtr(sptr, sec[i].Misc.VirtualSize);

		if(rptr >= sptr && rptr < eptr)
		{
			PIMAGE_RESOURCE_DIRECTORY root;
			
			ULONG diff = GetOffset(sptr, rptr);
			root = (PIMAGE_RESOURCE_DIRECTORY) &buffer[sec[i].PointerToRawData + diff];

			// RT_MANIFEST 리소스 블록을 찾는다.

			PIMAGE_RESOURCE_DIRECTORY_ENTRY entry;
			ULONG_PTR man_id = (ULONG_PTR) RT_MANIFEST;
			entry = FindResourceDirectoryEntryWithId(root, root, man_id);
			if(!entry)
				return FALSE;

			// RT_MANIFEST 리소스 블록 아래 ID가 1인 리소스를 찾는다.

			PIMAGE_RESOURCE_DIRECTORY rd;
			rd = (PIMAGE_RESOURCE_DIRECTORY) GetPtr(root, entry->OffsetToDirectory);
			entry = FindResourceDirectoryEntryWithId(root, rd, 1);
			if(!entry)
				return FALSE;

			rd = (PIMAGE_RESOURCE_DIRECTORY) GetPtr(root, entry->OffsetToDirectory);
			entry = (PIMAGE_RESOURCE_DIRECTORY_ENTRY) GetPtr(rd, sizeof(*rd));

			PIMAGE_RESOURCE_DATA_ENTRY data;
			data = (PIMAGE_RESOURCE_DATA_ENTRY) GetPtr(root, entry->OffsetToData);

			PVOID pdata;
			pdata = GetPtr(root, data->OffsetToData - sec[i].VirtualAddress + diff);

			if(required_size)
				*required_size = data->Size + 1;

			if(manifest_size < data->Size + 1)
			{
				SetLastError(ERROR_INSUFFICIENT_BUFFER);
				return FALSE;
			}

			memcpy(manifest, pdata, data->Size);
			manifest[data->Size] = '\0';
			return TRUE;
		}
	}

	return FALSE;
}

[리뷰] 돈, 뜨겁게 사랑하고 차갑게 다루어라

Thu, 18 Jun 2015 23:59:55 GMT

나는 이제 수단을 갖게 되었으므로 편안한 삶을 즐기고자 했다. 그러나 나는 내 기쁨을 마음껏 누릴 수가 없었다. 나의 철학적 현실주의와 뛰어난 증권 감각 덕택으로 나는 갑부가 되긴 하였으나 그 대신 다른 많은 것을 잃어버렸다. 내 소원은 성취되었지만 내 눈앞에 펼쳐진 세상은 너무도 슬펐다. 내가 좋아했던 친구들은 대부분 파멸했다. 그들은 공황을 거치면서 돈과 지위를 잃어버렸으며 앞으로 어떻게 살아가야 할지도 막막했다. 그와 반대로 나는 내가 꿈꿔 왔던 호화스러운 것을 모두 가질 수 있었다. 멋진 호텔, 레스토랑, 자동차, 이 모든 것을 누릴 수 있을 정도로 내 지갑은 항상 두둑했다. 그러나 그것을 같이 즐길 사람이 없었다. 화기애애한 분위기는 식었고, 즐거운 웃음이 사라진 그 자리에는 고통과 음침한 분위기만이 자리했다. 나는 정말 외톨이가 되었다. 어디든 살 수 있는 것 천지였지만 난 살 마음이 생기지 않았다. 친구들이 단 한 잔의 커피로 만족해야만 할 때 나는 샴페인과 귀한 상어 알을 먹을 수 있다는 사실이 내게 행복을 주지 않음을 그제야 알았다. 내 상황은 그 전보다 훨씬 나빠졌다. p227

…

이 전략은 오늘날에도 젊은 머니매니저들에게 매우 인기 있는 방법으로, 그들은 이것을 일컬어 포트폴리오 보험이라고 칭한다. 참 말도 안 되는 소리다. 왜냐하면 이 보험은 마치 화재로부터 집을 보호하기 위해 집을 판다는 식이기 때문이다. 나는 경험많은 사람들조차 어떻게 그럴 수 있는지 이해할 수 없다. p179

…

아주 열정적인 투자자였으나 런던 공황 때 재산을 몽땅 잃어버린 아이작 뉴턴 경은 이러한 분위기에 대해 다음과 같이 말한 바 있다.

“천체 운동은 센티미터와 초 단위로 측량할 수 있으나, 정신 나간 군중이 시세를 어떻게 끌고 갈지는 정말 알 수 없다.” p172

…

주가지수 선물거래를 위한 증거금 비율이 아주 낮았기 때문에 1987년 이 시장은 고삐 풀린 망아지처럼 뛰어다녔다. 시카고에서 하루에 거래된 S&P 500 지수 선물 계약이 뉴욕 증시에서 거래된 주식의 가치보다 많은 적도 있었다. 선물시장이 주도권을 쥐게 됨에 따라, 개가 꼬리를 흔드는 것이 아니라 꼬리가 개를 흔드는 상황이 연출된 것이다. p176

…

주식 투자자들은 성공하면 자기가 잘났기 때문이라고 하고, 실패하면 남의 탓으로 돌리기를 좋아한다. 가해자가 누구인지 바로 결정되었다. 프로그램 매매를 주도하던 컴퓨터에게 모든 죄가 돌아갔다. 불쌍한 컴퓨터가 가해자가 되어 버렸다. 만약 사람들이 신선하지 못한 생선을 포크와 나이프로 먹어 복통이 일어나면 그것을 포크와 나이프 탓으로 돌릴 것인가? 잘못된 것은 신선하지 못한 생선이듯, 이 문제는 사실 증권시장의 골든보이들이었다. p180

– 돈, 뜨겁게 사랑하고 차갑게 다루어라, 앙드레 코스톨라니

[cpp] 작업 영역 정확하게 구하는 방법

Thu, 18 Jun 2015 23:59:54 GMT

일반적으로 작업 영역을 구할때는 아래와 같은 코드를 많이 사용합니다. SystemParametersInfo의 SPI_GETWORKAREA를 사용하여 작업 표시줄을 제외한 작업영역을 구하는 방법입니다.

RECT rc; 
SystemParametersInfo(SPI_GETWORKAREA, 0, &rc, FALSE);

위 방법에는 한가지 단점이 있습니다. 작업표시줄의 자동 숨김 옵션을 활성화하면 전체 화면을 작업 영역으로 구하는 것이죠. 자동 숨김으로 하더라도 작업 표시줄이 완전히 사라지는 것이 아니라 미세하게 두께를 차지하기 때문에 약간의 높이가 있습니다. 때로는 이 미세한 영역도 정교하게 처리해 주고 싶을 때가 있습니다. 그럴 땐 SPI_GETWORKAREA를 사용할 수 없습니다.

GetWorkArea는 자동 숨김 옵션을 활성화한 경우에도 항상 정확하게 작업 표시줄 영역을 구해주는 함수입니다. lprc로 RECT 구조체의 포인터를 넘겨주면 절대적인 작업 영역을 구해서 넘겨줍니다. 별로 중요하다거나 어려운 부분은 없습니다. 단지 한가지 알아두면 유용한 것은, 작업 표시줄이 어떤 위치에 바인딩 되어 있는지를 구하기 위해서는 SHAppBarMessage API를 사용한다는 점 입니다.

GetWorkArea 함수 코드 소스 코드 다운로드

void GetWorkArea(LPRECT lprc) 
{ 
    SIZE    szScreen; 
    HWND    hShell = FindWindowW(L"Shell_TrayWnd", NULL); 
    
    szScreen.cx = GetSystemMetrics(SM_CXSCREEN); 
    szScreen.cy = GetSystemMetrics(SM_CYSCREEN); 
    SetRect(lprc, 0, 0, szScreen.cx, szScreen.cy); 
    
    if(!hShell)
		return;

    RECT        rcTaskbar; 
    SIZE        szTaskbar;      
    APPBARDATA  AppBarData; 
    POINT       pt = {0,0}; 
    POINT       ptMouse; 
        
    GetWindowRect(hShell, &rcTaskbar); 
    szTaskbar.cx = rcTaskbar.right - rcTaskbar.left; 
    szTaskbar.cy = rcTaskbar.bottom - rcTaskbar.top; 
        
    AppBarData.cbSize = sizeof AppBarData; 
    SHAppBarMessage(ABM_GETTASKBARPOS, &AppBarData); 
        
    switch(AppBarData.uEdge) 
    { 
    case ABE_TOP: 
        lprc->top += szTaskbar.cy; 
        break; 
            
    case ABE_BOTTOM: 
        lprc->bottom -= szTaskbar.cy;            
        break; 
            
    case ABE_LEFT: 
        lprc->left += szTaskbar.cx;          
        break; 
            
    case ABE_RIGHT: 
        lprc->right -= szTaskbar.cx; 
        break; 
    } 
}

아래와 같은 테스트 코드로 두 가지 방법을 비교해 보면 작업 표시줄의 항상 숨김 옵션을 끈 경우에는 결과 값이 동일하지만 해당 옵션을 활성화한 경우에는 GetWorkArea가 구한 영역이 조금 더 작다는 것을 보실 수 있습니다.

int main()
{
	RECT rc; 
	SystemParametersInfo(SPI_GETWORKAREA, 0, &rc, FALSE); 
	printf("%d %d %d %d\n", rc.left, rc.top, rc.right, rc.bottom);

	GetWorkArea(&rc);
	printf("%d %d %d %d\n", rc.left, rc.top, rc.right, rc.bottom);

    return 0;
}

[cpp] 동적 연결 라이브러리 동작 원리

Thu, 18 Jun 2015 23:59:53 GMT

항공기 사고의 74%는 이륙후 3분간, 착륙전 8분간 동안 발생한다고 한다. 이를 두고 ‘마의 11분’이란 표현을 쓰기도 한다. 이는 크리티컬한 작업에 있어서 시작과 끝이 얼마나 중요하고 위험한지를 나타내는 부분이라고 볼 수 있다. 윈도우 DLL을 사용할 때에도 대부분의 오류가 항공기 사고와 유사하게 DLL을 메모리에 적재하는 시점이나 해제하는 시점에 발생한다. 이는 윈도우가 DLL 목록을 관리하는 방식의 특수성에 기인한다. 이번 시간에는 이런 특수성에 대해서 살펴보고 이륙이나 착륙 과정에서의 사고를 피하기 위해서는 어떤 부분에 신경 써야 하는지 알아본다.

로더 락(Loader Lock) 윈도우는 로드된 DLL을 PEB(Process Environment Block)의 Ldr 필드를 통해서 관리한다. Ldr 필드는 <리스트 1>에 나와 있는 _PEB_LDR_DATA32 구조체를 가리킨다. _PEB_LDR_DATA32 구조체에는 현재 로더의 동작 상태를 나타내는 플래그와 로드된 DLL의 목록을 저장하고 있는 3개의 리스트(InLoadOrderModuleList, InMemoryOrderModuleList, InInitializationOrderModuleList)로 구성되어 있다.

리스트 1 _PEB_LDR_DATA32 구조체

typedef struct _PEB_LDR_DATA32
{
    ULONG Length;
    BOOLEAN Initialized;
    PVOID32 SsHandle;
    LIST_ENTRY32 InLoadOrderModuleList;
    LIST_ENTRY32 InMemoryOrderModuleList;
    LIST_ENTRY32 InInitializationOrderModuleList;
    PVOID32 EntryInProgress;
    BOOLEAN ShutdownInProgress;
    PVOID32 ShutdownThreadId;
} PEB_LDR_DATA32, *PPEB_LDR_DATA32;

LoadLibrary와 같은 DLL을 로드하는 함수나 로더 내부적으로 DLL을 로딩하는 경우에 로더는 해당 DLL을 로딩하고 _PEB_LDR_DATA32의 리스트에 해당 DLL의 정보를 추가한다. 마찬가지로 DLL이 메모리에서 언로드되는 경우에는 리스트에서 요청한 DLL을 제거한다. GetModuleHandle과 같이 특정 DLL을 찾는 경우에는 모듈 리스트를 순회하면서 들어온 정보와 매치되는 DLL이 있는지를 찾는다.

이와 같이 DLL의 관리에는 _PEB_LDR_DATA32라는 프로세스 내부의 유일한 구조체가 사용되며, 해당 구조체의 정보는 다양한 윈도우 API에 의해서 수시로 변경된다. 이 말은 해당 구조체에 대한 접근은 직렬화될 필요가 있다는 것을 의미한다. 구조체에 대한 접근이 동기화 되지 않는다면 다중 스레드에서 구조체의 내용을 변경할 경우에 구조체 내용물이 오염되는 현상이 발생할 수 있기 때문이다. 윈도우에서는 _PEB_LDR_DATA32 구조체에 대한 접근을 직렬화 시키기 위해서 로더 락이라는 것을 사용한다. 로더 락은 PEB 내부에 존재하며 크리티컬 섹션으로 구현되어 있다. 따라서 _PEB_LDR_DATA32를 사용하는 모든 API들은 로더 락을 획득한 다음 작업을 한다고 생각하면 된다.

<리스트 2>와 <리스트 3>에는 이러한 로더 락의 특징을 보여주는 예제를 담고 있다. 두 개의 스레드를 생성해서 각각의 스레드가 a.dll과 b.dll을 로드한다. 각각의 DLL은 <리스트 3>에 나와 있는 것과 같이 DLL이 초기화 되는 부분에서 자신의 이름을 출력한다. 만약 DLL이 로드되는 것이 직렬화 되지 않는다면 메시지 박스 두 개가 동시에 화면에 출력될 것이다. 하지만 DLL이 로드되는 작업은 직렬화가 이루어지기 때문에 절대로 두 개의 메시지 박스가 동시에 화면에 나타나는 법은 없다. 항상 하나의 메시지 박스를 닫아서 작업을 완료해야 다음 DLL의 메시지 박스가 출력된다. LoadLibrary 부분을 MessageBoxW 함수로 바꿔가면서 예제를 실행해보면 그 차이를 보다 쉽게 알 수 있다.

리스트 2 실행 파일 소스 소스 코드 다운로드

#include "windows.h"

ULONG
CALLBACK
ThreadProc(PVOID param)
{
    LPCWSTR name = (LPCWSTR) param;
    LoadLibraryW(name);
    return 0;
}

int _tmain(int argc, _TCHAR* argv[])
{
    LoadLibraryW(L"user32.dll");

    HANDLE threads[2];

    threads[0] = CreateThread(NULL, 0, ThreadProc, (LPVOID) L"a.dll", 0, NULL);
    threads[1] = CreateThread(NULL, 0, ThreadProc, (LPVOID) L"b.dll", 0, NULL);

    WaitForMultipleObjects(ARRAYSIZE(threads), threads, TRUE, INFINITE);
    
    return 0;
}

리스트 3 DLL 소스 소스 코드 다운로드

#include "windows.h"

BOOL APIENTRY DllMain( HMODULE m, DWORD reason, LPVOID reserved)
{
    switch(reason)
    {
    case DLL_PROCESS_ATTACH:
        MessageBoxW(NULL, L"a.dll", L"a.dll", MB_OK);
        break;
    }

    return TRUE;
}

DllMain에서 주의할 점 앞서 프로세스 내부의 DLL 정보를 관리하기 위해서 _PEB_LDR_DATA32라는 구조체를 사용한다는 것과 해당 구조체에 대한 접근을 로더 락을 통해서 직렬화 시킨다는 것을 배웠다. 이 단순한 사실이 DllMain을 작성하는 데에는 상당한 제약 사항을 불러온다. DllMain은 로더 락을 획득한 상태에서 호출되기 때문에 사소한 함수 호출도 데드락이나 크래시로 이어질 수 있다. <표 1>에는 이러한 관점에서 DllMain에서 피해야 할 작업들의 목록이 나와 있다. 해당 작업들은 특수한 가정이 적용되는 상황이 아니라면 가급적 사용하지 않는 것이 좋다.

DllMain에서 피해야 할 작업들

LoadLibrary, LoadLibraryEx 호출
해당 함수들은 의존성 루프를 생성할 수 있고 의존성 루프는 데드락이나 크래시를 유발할 수 있다.
다른 스레드와 동기화
데드락을 유발한다.
로더 락을 획득하려는 코드가 가지고 있는 동기화 오브젝트를 획득하려는 시도
데드락을 유발한다.
CoInitializeEx를 사용한 COM 스레드 초기화
특정 조건이 충족될 경우 CoInitializeEx는 LoadLibraryEx를 호출한다.
레지스트리 관련 함수들
이 함수들은 advapi32.dll에 구현되어 있다. advapi32.dll이 초기화 되지 않았다면 크래시가 발생할 수 있다.
CreateProcess 호출
프로세스 생성은 다른 DLL을 로드할 수 있다.
ExitThread 호출
DLL_PROCESS_DETACH 과정 중에 스레드를 종료하면 로더 락을 다시 획득하도록 만들 수 있다.
네임드 파이프나 네임드 오브젝트 생성
윈도우 2000에서 네임드 오브젝트 생성은 터미널 서비스 DLL에서 구현되어 있다. 해당 DLL이 초기화 되어 있지 않다면 크래시가 발생할 수 있다.
CRT에 포함된 메모리 관리 함수 사용
DLL 버전의 CRT를 사용한다면 해당 DLL이 초기화되어 있지 않을 수 있다.
user32.dll이나 gdi32.dll에 포함된 함수 사용
일부 함수들은 다른 DLL을 로드할 수 있고, 이 때문에 크래시가 발생할 수 있다.

그럼 좀 더 세부적으로 왜 이런 금기 사항들이 생겼는지에 대해서 알아보도록 하자. 첫 번째 금기 사항은 LoadLibrary의 호출이다. LoadLibrary의 호출은 새로운 DLL을 로딩하는 일이기 때문에 당연히 로더 락을 획득하는 시도가 발생할 수 있다는 것을 알 수 있다. 하지만 앞서 로더 락은 크리티컬 섹션으로 구현되어 있다고 했다. 윈도우에서 크리티컬 섹션은 재귀적으로 획득하는 것이 가능하도록 설정돼 있기 때문에 현재 스레드가 로더 락을 획득한 상태에서 LoadLibrary를 호출하는 것은 일견 문제가 없어 보이기도 한다. 실제로 DllMain에서 LoadLibrary를 사용해보면 큰 문제 없이 정상 동작하는 것을 볼 수 있다.

이렇게 잘 동작하는 LoadLibrary를 왜 굳이 호출하지 않도록 권고하는 것일까? 이유는 해당 호출을 인정할 경우에 특수한 상황에서 발생하는 문제들을 잠재적으로 같이 허용하는 셈이 되기 때문이다. 대표적인 예가 의존성 루프를 생성하는 것을 들 수 있다. 예를 들면 이런 상황이다. P라는 프로그램이 A.DLL을 로드한다. A.DLL은 DllMain에서 B.DLL을 로드한다. B.DLL은 DllMain에서 A.DLL을 로드한 다음 A.DLL의 Func라는 함수를 사용한다. 이때 이 Func라는 함수는 A.DLL이 초기화가 다 완료되지 않은 상태에서 호출되기 때문에 문제가 발생할 수 있다. <리스트 4>에는 이 경우에 대한 소스 코드가 나와 있다. 해당 예제를 수행해 보면 <화면 1>에 나타난 것과 같이 Func 실행 부분에서 msg 값이 초기화가 완료되지 않아서 NULL 값이 출력되는 것을 볼 수 있다.

이 예제의 경우에는 의존성 루프가 2단계이고 모든 DLL을 우리가 만들었기 때문에 원인을 쉽게 찾을 수 있다. 하지만 이런 의존성이 여러 곳에서 긴 단계에 걸쳐서 발생하는 경우에는 찾기도 힘들뿐더러 예측하지 못했던 동작들이 발생할 수 있다. 따라서 가급적 DllMain에서는 LoadLibrary 호출을 피하는 것이 좋다.

리스트 4 의존성 루프로 인한 오류 발생 예제 소스 코드 다운로드

// P 소스 코드
#include "windows.h"

int main()
{
	LoadLibraryW(L"a.dll");
	return 0;
}

// A.DLL 소스 코드
#include "windows.h"

LPCWSTR msg;

BOOL APIENTRY DllMain(HMODULE m, DWORD reason, LPVOID reserved)
{
	switch(reason)
	{
	case DLL_PROCESS_ATTACH:
		{
			printf("a.dll DLL_PROCESS_ATTACH\n");
			HMODULE m = LoadLibraryW(L"b.dll");
			msg = L"Init Complete";
			printf("a.dll DLL_PROCESS_ATTACH 완료\n");
		}
		break;
	}

	return TRUE;
}

extern "C" __declspec(dllexport) void Func()
{
	printf("MSG => %ws\n", msg);
}


// B.DLL 소스 코드
#include "windows.h"
typedef void (*FuncT)();

BOOL APIENTRY DllMain(HMODULE m, DWORD reason, LPVOID reserved)
{
	switch(reason)
	{
	case DLL_PROCESS_ATTACH:
		{
			printf("b.dll DLL_PROCESS_ATTACH\n");

			HMODULE m = LoadLibraryW(L"a.dll");
			FuncT func = (FuncT) GetProcAddress(m, "Func");
			func();
		
			printf("b.dll DLL_PROCESS_ATTACH 완료\n");
		
		}
		break;
	}

	return TRUE;
}

화면 1 P 실행 화면 두 번째 시나리오인 다른 스레드와 동기화를 생각해보자. DllMain에서 T라는 스레드를 종료 시키기 위해서 T의 종료 이벤트를 시그널 하고 WaitForSingleObject로 T를 대기한다고 가정해보자. 이 경우에 T는 종료 이벤트가 시그널 되었기 때문에 스레드 종료를 위해서 ExitThread가 호출될 것이다. ExitThread가 호출되면 DLL_THREAD_DETACH 이벤트를 호출하기 위해서 일부 DLL에 대해서는 DllMain이 호출되어야 한다. 이는 바로 로더 락 획득을 의미한다. 그런데 a.dll의 DllMain에서 로더 락을 획득한 상태에서 T가 종료되길 대기하고 있기 때문에 T의 ExitThread는 로더 락을 획득할 수가 없다. 따라서 데드락에 빠지게 된다. <리스트 5>에는 이러한 시나리오를 통해서 데드락에 빠지는 예제가 나와 있다. 해당 DLL을 로딩하는 프로그램은 자동으로 데드락에 빠진다.

리스트 5 스레드 동기화로 인한 데드락 발생 예제 소스 코드 다운로드

#include "windows.h"
HANDLE exit_event;

ULONG
CALLBACK
ThreadProc(PVOID)
{
    WaitForSingleObject(exit_event, INFINITE);
    return 0;
}

BOOL APIENTRY DllMain( HMODULE m, DWORD reaspm, LPVOID reserved)
{
    switch (reason)
    {
    case DLL_PROCESS_ATTACH:
        {
            exit_event = CreateEvent(NULL, FALSE, FALSE, NULL);
            HANDLE thread = CreateThread(NULL, 0, ThreadProc, NULL, 0, NULL);
            SetEvent(exit_event);
            WaitForSingleObject(thread, INFINITE);
        }
        break;
    }

    return TRUE;
}

간단하게 두 가지 경우에 발생하는 문제만 살펴보았지만 다른 경우의 문제점들도 동일하게 모두 로더 락을 획득한 상태라는 특수성 때문에 발생하는 문제들이다. 숙련된 윈도우 프로그래머의 경우에도 이러한 제약 사항들에 대해서 단지 정상 동작한다는 이유로 크게 신경을 쓰지 않기도 한다. 하지만 이는 바람직한 자세가 아니다. 언제든지 해당 코드들은 문제를 발생시킬 수 있기 때문이다. 특수한 가정이 덧붙여지는 상황이 아니라면 해당 코드들을 DllMain에서 사용하는 일은 반드시 피하도록 해야 한다.

초기화 지연 전략 DllMain에서 피해야할 많은 작업들에 대해서 배웠다. 그렇다면 만약 DLL의 초기화에 반드시 피해야 할 작업이 있다면 어떻게 해야 할까? 그럴 때는 DllMain에서 초기화를 시키는 것이 아닌 초기화를 지연시키는 방법을 사용해야 한다. 일반적으로 가장 좋은 방법은 <리스트 6>에 나와 있는 것과 같이 DLL 초기화, 클린업 함수를 익스포트 시키는 방법이다. DLL을 사용하는 프로그래머가 DLL 로딩 후에 해당 함수를 명시적으로 호출해서 초기화와 클린업을 수행하도록 만드는 것이다. 하지만 후킹 DLL과 같은 경우에는 이러한 방법을 사용하기가 까다로운 경우가 많다. 그런 경우에는 DllMain에서 초기화 코드를 담고 있는 스레드를 생성해서 나중에 초기화가 수행되도록 만드는 것이 좋다.

리스트 6 초기화/종료 함수를 사용한 초기화 지연

__delcspec(dllexport) HRESULT InitDLL()
{
    // 실제 DLL 초기화 작업
}

__declspec(dllexport) void CleanupDLL()
{
    // 실제 DLL 클린업 작업
}

DLL_PROCESS_DETACH에 관한 오해 DLL_PROCESS_DETACH는 DLL이 메모리에서 해제되는 시점, 그러니까 FreeLibrary가 호출되서 해당 DLL의 레퍼런스 카운트가 0이 되는 시점과 프로세스가 종료되는 시점에 호출된다. 이러한 특성 때문에 상당히 많은 윈도우 프로그래머가 DLL_PROCESS_DETACH에 대해서 도시전설 같은 믿음을 가지고 있다. 하나는 TerminateProcess로 종료되는 경우에는 DLL_PROCESS_DETACH 이벤트가 발생한다는 것이고, 다른 하나는 DLL_PROCESS_DETACH가 프로세스 종료 처리에 적합한 위치라고 생각한다는 점이다. 하지만 이는 둘 다 심각하게 잘못된 믿음이다.

프로세스 종료를 만들어내는 두 가지 API, ExitProcess와 TerminateProcess의 구현을 살펴보면 <리스트 7>에 나타난 것과 같다. 코드에 나타난 것처럼 두 함수 모두 궁극적으로는 NtTerminateProcess를 호출해서 작업을 완료한다. 둘의 차이라면 ‘shutdown process’의 진행 여부에 있다. 이 ‘shutdown process’의 진행 과정의 일환으로 호출되는 것이 DLL_PROCESS_DETACH다. 따라서 TerminateProcess로 종료될 때에는 당연히 DLL_PROCESS_DETACH 이벤트가 발생하지 않는다.

리스트 7 ExitProcess와 TerminateProcess의 구현

ExitProcess(...)  
{  
    NtTerminateProcess(NULL, ExitCode);  
    // shutdown process  
    NtTerminateProcess(GetCurrentProcess(), ExitCode);  
}
  
TerminateProcess(...)  
{  
    NtTerminateProcess(Process, ExitCode);  
}

우리가 ExitProcess의 구현에서 눈치채야 할 다른 중요한 시사점은 바로 NtTerminateProcess를 호출한 다음 ‘shutdown process’를 진행한다는 점입니다. 여기에는 굉장히 중요한 점이 내포되어 있다. 바로 우리 DLL이 FreeLibrary가 아닌 프로세스 종료 때문에 DLL_PROCESS_DETACH가 호출된다면, 그 시점에는 그 어떠한 스레드도 살아 있지 않다는 점이다. NtTerminateProcess(NULL, ExitCode)를 거치는 순간 해당 프로세스의 모든 스레드는 강제로 터미네이트(Terminate)되기 때문이다.

결론을 다시 정리해보면 이렇다. DLL_PROCESS_DETACH는 TerminateProcess로 종료되는 경우에는 이벤트가 발생하지 않으며, 모든 스레드가 강제로 종료된 다음에 호출될 수 있기 때문에 종료 작업을 하는 위치로는 적절하지 않다는 점이다.

DllMain에서의 예외 DLL_PROCESS_ATTACH 이벤트에서 DllMain이 FALSE를 리턴한다면 윈도우는 DLL_PROCESS_DETACH 이벤트를 사용해서 DllMain을 다시 호출한 다음 해당 DLL을 메모리에서 제거한다. 반면에 DLL_PROCESS_ATTACH 수행 과정 중에 DllMain에서 예외가 발생한다면 운영체제는 DLL_PROCESS_DETACH 이벤트 통보 없이 해당 DLL을 즉시 메모리에서 제거한다.

윈도우는 DllMain의 실패 처리와 관련해서 기본적으로 위와 같은 입장을 가지고 있다. 이 부분이 표면적으로는 FALSE를 리턴하면 DLL_PROCESS_DETACH가 호출되고, 예외가 발생하면 메모리에서 바로 제거된다는 내용을 담고 있는 것처럼 보여지지만 사실상 이 내용은 DllMain에서 절대로 예외를 발생시켜서는 안 된다는 이야기를 담고 있다. 그 이유는 CRT 때문이다.

CRT는 멀티스레드 환경을 지원하기 위해서 FLS(Fiber Local Storage)라는 것을 사용한다. CRT 초기화 루틴에서 FlsAlloc(_freefls)를 호출해서 FLS 공간을 할당한다. 물론 이렇게 할당된 공간은 DLL_PROCESS_DETACH 이벤트에서 CRT가 직접 제거한다. 코드로 살펴보면 <리스트 8>에 나타난 것과 같은 구조가 된다. 실제 DLL의 시작은 CrtDllMain이라는 CRT 코드에서 시작되고 해당 코드에서 각종 초기화를 한 다음 우리가 작성한 OurDllMain을 호출해 주는 것이다.

리스트 8 DllMain 호출 구조

BOOL CALLBACK CrtDllMain(HINSTANCE instance, ULONG reason, PVOID reserved)  
{  
    if(reason == DLL_PROCESS_ATTACH)  
    {  
        flsindex = FlsAlloc(_freefls);  
        return OurDllMain(instance, reason, reserved);  
    }  
    else if(reason == DLL_PROCESS_DETACH)  
    {  
        BOOL r = OurDllMain(instance, reason, reserved);  
        FlsFree(flsindex);  
        return r;  
    }  
  
    return TRUE;  
}

그런데 이 구조에서 OurDllMain에서 예외가 발생한다면 CRT가 할당한 FLS 공간이 문제가 된다. 왜냐하면 우리가 만든 OurDllMain에서 예외가 발생하면 CRT에서는 FlsAlloc을 사용해서 FLS 공간을 할당했지만 DLL_PROCESS_DETACH가 호출되지 않아서 그 공간을 회수할 기회를 가지지 못하기 때문이다.

“몇 바이트 메모리 누수가 일어나는 것이 큰 문제일까?”라고 생각할 수 있다. 하지만 이 문제는 단순히 FLS 공간에 대한 메모리 누수만 일어나는 것으로 마무리되는 문제가 아니다. 윈도우 운영체제는 FLS에 등록된 것들을 프로세스 종료 시점에 모두 다시 회수하려고 시도한다. 이는 FlsAlloc에 지정된 콜백 함수를 호출해서 이루어진다. <리스트 8>의 코드에서는 _freefls 함수가 그것이다. 즉, 우리가 예외를 발생시켜 DLL이 메모리에서 즉시 제거되고 나면 엉뚱하게 프로세스 종료 시점에 운영체제가 사라진 메모리 번지를 가리키는 _freefls를 호출하려고 하다가 크래시가 발생할 수 있다.

DllMain에서는 절대로 예외를 발생시켜서는 안 된다. 왜냐하면 그 예외가 앞서 설명한 것과 같이 CRT의 코드에 영향을 미칠 수 있기 때문이다. <리스트 9>에 나타난 것과 같이 DllMain에서 수행하는 작업 과정에서 발생할 수 있는 모든 예외를 봉쇄하고 예외가 발생한 경우에는 그냥 FALSE를 리턴하는 것이 현명하다. 그러면 적어도 다른 프로그램에 민폐는 안 끼칠 수 있다. 그렇지 않다면 민폐를 끼치고 엉뚱한 지점에서 크래시가 발생하는 문제가 생길 수 있다.

리스트 9 예외 처리기를 통해서 DllMain에서 발생하는 예외를 차단하는 코드

// /Eha 옵션으로 컴파일해야 모든 예외를 잡을 수 있다.
BOOL APIENTRY DllMain( HMODULE m, DWORD reaspm, LPVOID reserved)
{
    try
    {
        // .. DllMain에서 처리해야 할 작업들

        return TRUE;
    }
    catch(...)
    {
    }

    return FALSE;
}

lpreserved의 용도 끝으로 DllMain의 마지막 파라미터인 lpreserved에 대해서 알아보자. DllMain의 세 번째 인자는 void 포인터 타입의 lpreserved다. 흔히 그냥 추후 사용을 위해서 예약돼 있다고 막연하게 생각할 수 있는데 이 값은 윈도우 내부적으로 사용되는 값이다. 그리고 그 의미는 다음과 같다.

DLL_PROCESS_ATTACH 시점에는 지금 로드되는 DLL이 LoadLibrary와 같은 함수를 사용해서 동적으로 로딩된다면 NULL을, 그렇지 않고 임포트 테이블을 사용해서 정적으로 로딩된다면 NULL이 아닌 값을 가진다.

DLL_PROCESS_DETACH 시점에는 FreeLibrary 호출로 인해서 메모리에서 제거되는 경우에는 NULL을, 그렇지 않고 프로세스 종료로 인해서 DLL이 제거되는 경우에는 NULL이 아닌 값을 가진다.

이런 파라미터는 DLL의 로딩을 최적화하는 용도로 사용된다. <리스트 10>의 코드는 CRT의 DLL_PROCESS_DETACH 코드의 일부를 발췌한 것이다. 이 코드를 살펴보면 lpreserved 값을 조사해서 NULL일 때만 클린업 코드를 호출하는 것을 볼 수 있다. 이유는 NULL이 아닌 경우에는 프로세스가 종료되는 시점이고 우리가 일일이 리소스를 파괴하지 않아도 운영체제가 알아서 모든 리소스를 제거할 것이기 때문이다. 해당 클린업 호출을 하지 않음으로써 보다 빠르게 DllMain이 완료될 수 있도록 만들어주는 것이다.

리스트 10 CRT의 DLL 클린업 코드

#ifndef _DEBUG  
    if ( lpreserved == NULL )  
    {  
#endif  /* _DEBUG */  
        /* 
         * The process is NOT terminating so we must clean up... 
         */  
        /* Shut down lowio */  
        _ioterm();  
  
        _mtterm();  
  
        /* This should be the last thing the C run-time does */  
        _heap_term();   /* heap is now invalid! */  
#ifndef _DEBUG  
    }  
#endif  /* _DEBUG */

[리뷰] 위대한 기업에 투자하라

Thu, 18 Jun 2015 23:59:52 GMT

중세 시대는 서구 세계 대부분이 생존에 필요한 물자조차 부족했고, 인간의 삶이 무척 고달팠던 시절이었다. 그 무렵 고급 두뇌의 상당 부분이 쓸데없는 문제에 몰두했던 것도 중요한 이유였다. 당시 이 세상에 천사의 숫자가 얼마나 되는지 따위의 논쟁을 하느라 허비했던 노력의 절반만이라도 굶주림과 질병, 궁핍과 싸우는 데 돌려졌더라면 어떤 일이 벌어졌을지 한번 상상해보라. 오늘날 주식 투자와 관련된 일을 하고 있는 고급 인력들이 향후 경기 동향을 예측하기 위해 바치고 있는 노력의 단 얼마만이라도 보다 생산적인 목적에 사용한다면 정말로 놀라운 결과를 가져올 수 있을 것이다.

위대한 기업에 투자하라, 필립 피셔

맞는 말이다. 생산자는 없고 죄다 빨대 꽂으려는 놈들만 있으니…

맘같아선 진짜 광합성을 배우던지 해야지 ㅋ~

[정보] 빌게이츠의 인생 충고 11가지

Thu, 18 Jun 2015 23:59:51 GMT

RULE 1
Life is not fair – get used to it.
인생이란 원래 공평하지 못하다. 그런 현실에 대하여 불평할 생각하지 말고 받아들여라.

RULE 2
The world won’t care about your self-esteem. The world will expect you to accomplish something BEFORE you feel good about yourself.
세상은 네 자신이 어떻게 생각하든 상관하지 않는다. 세상이 너희들한테 기대하는 것은 네가 스스로 만족하다고 느끼기 전에 무엇인가를 성취해서 보여줄 것을 기다리고 있다.

RULE 3
You will NOT make 40 thousand dollars a year right out of high school. You won’t be a vice president with car phone, until you earn both.
대학교육을 받지 않는 상태에서 연봉이 4만 달러가 될 것이라고는 상상도하지 말라.

RULE 4
If you think your teacher is tough, wait till you get a boss. He doesn’t have tenure.
학교선생님이 까다롭다고 생각되거든 사회 나와서 직장 상사의 진짜 까다로운 맛을 한번 느껴봐라.

RULE 5
Flipping burgers is not beneath your dignity. Your grandparents had a different word for burger flipping they called it Opportunity.
햄버거 가게에서 일하는 것을 수치스럽게 생각하지 마라. 너희 할아버지는 그 일을 기회라고 생각하였다.

RULE 6
If you mess up,it’s not your parents’ fault, so don’t whine about your mistakes, learn from them.
네 인생을 네가 망치고 있으면서 부모 탓을 하지 마라. 불평만 일삼을 것이 아니라 잘못한 것에서 교훈을 얻어라.

RULE 7
Before you were born, your parents weren’t as boring as they are now. They got that way from paying your bills, cleaning your clothes and listening to you talk about how cool you are. So before you save the rain forest from the parasites of your parent’s generation, try delousing the closet in your own room.
당신이 태어나기 전에는 부모님의 인생도 괜찮았다. 그들의 인생이 재미없게 된 건 당신의 재미있는 인생을 뒷바라지해야 했기 때문이다. 부모님 세대가 열대우림을 망친다고 분노하기 전에 자기 방의 옷장 안이나 제대로 정리할 일이다.

RULE 8
Your school may have done away with winners and losers, but life has not. In some schools they have abolished failing grades and they’ll give you as many times as you want to get the right answer. This doesn’t bear the slightest resemblance to ANYTHING in real life.
학교는 승자나 패자를 뚜렷이 가리지 않을 지 모른다. 어떤 학교에서는 낙제제도를 아예 없애고 쉽게 가르치고 있다는 것을 잘 안다. 그러나 사회 현실은 이와 다르다는 것을 명심하라.

RULE 9
Life is not divided into semesters. You don’t get summers off and very few employers are interested in helping you find yourself. Do that on your own time.
인생은 학기처럼 구분되어 있지도 않고 여름 방학이란 것은 아예 있지도 않다. 네가 스스로 알아서 하지 않으면 직장에서는 가르쳐주지 않는다.

RULE 10
Television is NOT real life. In real life people actually have to leave the coffee shop and go to jobs.
TV는 현실이 아니다. 현실에서는 커피를 마셨으면 일을 시작하는 것이 옳다.

RULE 11
Be nice to nerds. Chances are you’ll end up working for one.
공부 밖에 할줄 모르는 “바보” 한테 잘 보여라. 사회 나온 다음에는 아마 그 “바보” 밑에서 일하게 될지 모른다.

빌게이츠가 하지 않았는데 한 걸로 유명해진 것 같은 충고…

[정보] 세이노칼럼: 장사꾼보다는 사업가가 되라

Thu, 18 Jun 2015 23:59:50 GMT

새벽마다 아파트단지에서 세차를 대행해준다는 독자가 나에게 “어떻게 하면 수입을 더 늘릴 수 있느냐”는 질문을 한 적이 있다. 사람들은 세차 차량의 수를 늘리는데만 관심을 갖는다. 그러나 일의 대가를 육체가 움직이는 시간 만큼만 비례하도록 만들게 되면 평생 가난을 못 벗어난다.

내 답변은 “세차만 하면 안된다”는 것이다. 세차 차량의 숫자를 늘리는 것은 두번째 문제이다. 나라면 우선 “저에게 일을 주셔서 감사합니다. 정성껏 세차했지만 혹시라도 불만이 있으시면 전화해 주십시오”라고 적힌 명함을 돌린다. 새벽에 세차를 하고 낮에는 세차방법과 차량정비에 대해 공부할 것이다. 몇개월 후 “경비실에 키를 맡기시면 냉각수와 세척액 오일 체크는 무료로 해 드립니다”라는 선전지를 돌린다. 다시 몇개월 후 냉각수와 세척액 오일교환 서비스를 실시하고 좋은 제품을 싼 가격에 판다. 가짜나 유사품이 많은 세상이므로 반드시 어느 회사 제품을 사용했는지를 고객에게 눈으로 확인시킨다. 타이어의 공기압도 확인하여 준다. 고객별로 모든 내용을 기록하는 것은 물론이다.

겨울철에는 “염화칼슘이 차를 부식시킨다고 합니다. 제가 알아보니 차량 세척 비용은 얼마라고 합니다만 세차장까지 일부러 시간을 내셔서 다녀오셔야 합니다. 선생님의 귀중한 시간을 아껴드리고자 출근하시기 전 혹은 퇴근하신 뒤에 제가 세차장에 차를 맡기고 찾아오는 서비스를 해 드립니다. 다만 세차비에 얼마를 더 주시면 됩니다”라는 내용의 선전지를 뿌린다.

물론 인근 세차장과 협의해 가격 할인을 받아 놓는다. 또 “밧데리가 방전되어 당황해 하시는 분들을 위하여 제가 밧데리 한 개를 준비했습니다. 동네 정비업체에 전화를 걸어 밧데리를 갖고 오라고 하실 때의 절반 가격에 빌려드립니다”라는 선전지도 배포한다. 무료로 1회 광택 서비스를 해주고 “계속 원하시면 얼마입니다”라고 알린다. 눈이 오면 출근전 앞창 유리를 닦아주기도 한다.

나의 목표는 고객들의 신뢰를 받고 고객이 조그마한 불편이라도 느끼는 것을 눈치 빠른 머슴처럼 대신하여 주되 대가는 받겠다는 것이다. 이점은 중요한 사실이므로 꼭 기억하라. 고객이 많아지면 사람을 고용하고 철저히 감독한다. 그리고 다른 아파트 단지를 찾아 나선다. 신청하는 사람이 많아 감당 못할 서비스 부분은 해당 가격을 인상시키고 주머니가 얇은 고객은 떨어내 고객의 수를 조정한다. 욕심이 앞서 감당 못할 수의 고객을 받아들이는 짓은 절대 하지 않는다.

여기서 독자들은 내가 1년 후를 생각하며 구조체를 만드는 과정에 주목해야 한다. 오늘 수입이 많았다고 좋아하는 사람은 장사꾼이고 오늘은 손해가 났어도 1년후를 생각하며 고객에게 한 약속과 신뢰를 지키는 사람은 사업가이다. 물론 나는 사업가이다. 장사꾼은 작은 돈은 벌 수 있어도 큰 돈은 못 번다. 무슨 일을 하든지 장사꾼이 되지 말고 사업가 정신을 가져야 한다.

– 세이노

[일상] 일요일의 단상…

Thu, 18 Jun 2015 23:59:49 GMT

매번 그냥 늘어지게 쉬고 싶다는 말을 입버릇처럼 달고 다녔다. 그래서 오늘은 그냥 늘어지게 쉬었다. 얼마만인지 ㅋㅋ~

#0

어제는 정말 기분이 꿀꿀한 날이었다. 하루 종일 기분이 좋다가 막판에 아주 꿀꿀해진 그런 날. 기분 좋지 않은 반전이 있었던 날. 어쨌던 정말 현진건의 “운수 좋은 날” 같은 그런 느낌의 하루였다. 지나고보니 그런 생각이 들었다. 결국은 내 탓이다. 기분이 좋은 것도 내 탓이고, 기분이 나쁜 것도 내 탓이고 말이다.

주식을 하면서 배운 한 가지 사실은 높은 수익을 얻는 것보다는 손실을 보지 않는 것이 훨씬 크다는 점이다. 일종의 방어적 프로그래밍과 같은 그런 원리다. 실컷 신나게 수익을 올려도 한번 실수를 하면 물거품 되는 것은 시간 문제다. 그런데 그 물거품 된 것을 복구하기 위해서는 곱절의 노력이 필요한 셈이다. 어쨌든 어제 내가 느낀 점은 좋은 선택을 고심하기 보다는 나쁜 선택을 하지 않도록 주의해야 겠다는 거? ㅎㅎ~

#1

꿀꿀한 기분에 푹 자고 났더니 오후다. 일어나기가 싫어서 침대맡에 머리를 파묻고는 한참을 더 잤다. 그래도 침대에서 기어나오기 싫어서 엊저녁에 보다만 책을 집어 들었다. 에쿠니 가오리의 “냉정과 열정 사이”. 한참된 책인데 내가 산 건 아니고, 아마 우리 누나가 산 책인듯 싶다. 집에 있길래 읽어 보려고 집어왔다. 에쿠니 가오리를 제법 좋아한다고 생각하면서도 이 책은 읽어보질 못했었다.

소설은 제법 낭만적이었다. “사람이 있을 곳이란, 누군가의 가슴속밖에 없는 것이란다.”

#2

나에게 자기애의 가장 극한 표현은 요리다. 뭔가 집밥을 해먹고 나면 나 자신에게 그래도 쪼금은 덜 미안해진다. 한동안 요리하는 거에 취미가 들려서 한창 해먹다가 요즘은 좀 뜸했다. 바쁘기도 했고. 어쨌든 오늘은 근사한 집밥을 해먹고 싶어서 간만에 밥을 했다. 된장을 끓이고 갈치를 굽고, … 결국 뭐 다 엄마표 협찬 제품이지만 다 늘어놓고 보니 간만에 제법 진수성찬이다. 실컷 먹고는 잽싸게 치웠다.

입가심용 아이스크림이 다 떨어져 버린 것을 한탄하다가 오래된 꿈틀이와 짱셔요를 발견했다. 잽싸게 먹었다. 꿈틀이는 괜찮았는데 짱셔요는 하나도 안셨다. 오래되서 그런지 애가 상태가 좀 메롱이 된 듯한 느낌. ㅎㅎ~

— 2010. 11. 14.

[소고] 가르쳐라. 그리하면 배울 것이다.

Thu, 18 Jun 2015 23:59:48 GMT

Q:
만약 회사에서 신입이 들어 왔는데, 저에게 그 신입의 기술을 올려 주라는…(한마디로 하루 1 시간씩 과외 비스무리) 임무를 준다면…그걸 해야 할까요?…말아야 할까요?… 제가 꼭 그일을 해야 하는지요…회사에서 그 일을 할줄 아는 사람이 저 밖에 없는데… 회사 입장에서는 후일을 대비한 것 같고요…저는 제 나름대로 회사에서 제 장점이 있으니 유리한 입장인데…

A:
저도 처음 회사를 다닐 때 사수분이 그런 마인드를 가지고 계셔서 아주 고생했던 기억이 나는군요. 저한테 가르쳐주고 나면 자신은 뭐 먹고 사냐고 그런 말씀을 하셨더랬죠. 그래서 늘 컴파일러나 소스를 줄 때 계속 파일 하나를 빼고 주던지 하는 식으로 해서 아주 골탕을 먹었습니다. ㅎㅎㅎ^^ 물론 지금은 사이 좋게 지냅니다~

사람의 머리에서 머리로 전달될 수 있는 기술 몇 가지를 가르쳐 줬다고 자신의 밥줄을 걱정해야 할 정도라면 많이 반성해야 한다고 봅니다. 저도 프로그래머로 몇 해 동안 일했지만, 제가 가진 경쟁력은 제가 알고 있는 win32 api개수도, 제가 만들어 논 라이브러리 코드도, 제가 알고 있는 윈도우 시스템 지식도 아니라고 봅니다. 제가 신입 사원에 비해 가지는 가장 큰 경쟁력은 경험이겠죠. 몇 해 동안 일한 경험.

만약 회사에서 그러한 경험과 노하우를 전부 무시하고 기술이 전수되었다고 퇴사를 권고한다면 그런 회사는 오래 다닐 필요가 없다고 봅니다.

물론 저도 오래 일한 것은 아니지만 일하면서 느낀 점은 기술이라는 것은 정말 별것 아니라는 점이었습니다. 기술보다는 사람을 얻는 것이 훨씬 더 값어치 있는 일이라 생각되네요. 지금 밑에 들어온 신입 사원에게 성심 성의껏 가르쳐 주세요. 혹시 나중에 그 분한테 도움을 청할 일이 생길지도 모르니까요~

끝으로 덧붙여 기술이라는 것은 자신의 머릿속에 묶어둬 봤자 아무 쓸모 없습니다. 그것을 활용하고 알리고 할 때 효용이 생기는 것이죠~ 만약 모두가 자신의 머릿속에 가둬 놓았다면, 아마 지금도 동굴 속에서 추위에 떨면서 살고 있었겠죠~~~

http://groups.google.com/group/microsoft.public.kr.vc.qna/browse_thread/thread/e58e4cf0d44a9c96

**가르치는 행위는 가장 좋은 학습 방법이다.**

[정보] 놀라운 비디오 세상

Wed, 17 Jun 2015 23:59:47 GMT

93년인가 94년엔가? 리눅스를 처음 접했을 때 가장 답답한 마음은 제대로 된 튜토리얼이 없다는 것이었습니다. 책대로 그대로 했는데도 되는 것은 정말 하나도 없었습니다. 처음 X-window 화면을 봤을 때는 감동이었죠. 이후에도 저는 리눅스 환경에서 여러 가지 일을 다양한 문서를 따라하면서 해 봤지만 늘 뭔가 잘 안되었죠. 아마 제가 글을 제대로 이해하는 능력이 부족하거나 저의 시스템이 특이해서 그랬다고 생각하지만, 아마도 다른 사람이 제대로 하는 것을 한 번이라도 TV에서 봤다면 저의 시행착오는 극적으로 줄지 않았을까란 생각을 해봅니다. 물론 요즘이라고 이런 일들이 벌어지지 않는 것은 아닙니다. 아주 문서화가 잘되어 있고, 그대로 따라해도 안되는 경우는 많습니다. 이런 것들이 텍스트의 한계라고 봅니다. 아무리 친절한 캡쳐 화면도 전부를 다 보여줄수는 없죠. 그런 점에서 비디오는 정말 큰 장점을 가지고 있습니다. 또한 인프라의 발전으로 그런 것들이 점점 다가오고 있습니다. 더욱 놀라운 사실은 프로그래밍 분야에도 성큼 다가왔다는 겁니다. 물론 주옥같은 웹캐스트야 오래전부터 있었지만 이렇게 HOWTO 같은 시리즈의 비디오가 잘 정리된 페이지는 첨 본 거 같네요. 역시 MS ㅋㅋㅋ~

http://msdn2.microsoft.com/en-us/visualc/bb496952.aspx

[cpp] ARP 테이블 열거하기

Wed, 17 Jun 2015 23:59:46 GMT

프로그램 내에서 ARP 테이블을 뒤져야 할 때가 있다. ARP란 주소 해석 프로토콜로 IP의 실제 MAC 어드레스를 구하기 위해서 사용되는 프로토콜이다. 반대로 RARP라는 것도 있다. ARP는 네트워크의 아주 하부에 존재하는 레이어로 굉장히 중요한 역할을 한다. 실제로 네트워크 레이어를 구축할때에도 아마도 제일 먼저 만들어야 하는 부분이다.

매번 ARP를 요청하는 것은 시스템으로 봐서는 굉장히 멍청한 짓이다. 왜냐하면 IP에 해당하는 MAC 어드레스가 매번 바뀌지는 않기 때문이다. 그래서 시스템은 ARP 요청 정보를 일정 시간동안 캐시에 저장해 놓고 캐시에 저장된 요청이 오면 캐시에 있는 정보를 그대로 보내준다. ARP 캐시를 부려면 커맨드 창에서 arp -a를 입력하면 된다. 이 목록을 구하는 함수를 만들어 보도록 하자~

아래는 ARP 테이블을 열거하는 함수를 보여준다. 첫번째 인자로 열거 콜백 함수를 두번째 인자로 콜백함수에 포함될 사용자 정의 파라미터를 넣어주면 된다. 그러면 함수는 ARP 테이블의 한 행마다 fCallback함수를 호출해 준다.

ARP 테이블 열거 함수 소스 코드 다운로드

typedef BOOL (CALLBACK *CBENUMARPTBL)(MIB_IPNETROW *, PVOID );

NPDUTILAPI
BOOL WINAPI EnumArpTbl(CBENUMARPTBL fCallBack, PVOID pUserData)
{
    DWORD       cbBuffer = 0;
    char        *pBuffer = NULL;
    DWORD       result = 0;
    MIB_IPNETTABLE  *pTable;
    DWORD       i;
    MIB_IPNETROW    *row;

    while((result = GetIpNetTable((MIB_IPNETTABLE *) pBuffer, &cbBuffer, TRUE))
              == ERROR_INSUFFICIENT_BUFFER)
    {
        delete [] pBuffer;
        pBuffer = new char[cbBuffer];
        result  = GetIpNetTable((MIB_IPNETTABLE *)pBuffer, &cbBuffer, TRUE);
    }
    
    if(result != NO_ERROR)
        return FALSE;       
    
    pTable = (MIB_IPNETTABLE *)pBuffer;
    for(i = 0; i < pTable->dwNumEntries; ++i)
    {
        row = &(pTable->table[i]);
        
        if(fCallBack(row, pUserData) == FALSE)
            break;
    }
    
    delete [] pBuffer;
    return TRUE;
}

CBENUMARPTBL 함수의 첫번째 인자로 넘어오는 MIB_IPNETROW는 다음과 같이 정의된 구조체다.

typedef struct _MIB_IPNETROW {
  // 어댑터의 인덱스 번호 
  DWORD dwIndex; 

  // 물리 주소의 길이. 통상적으로 6이 된다. 왜냐하면 mac 주소는 6바이트이기 때문이다. 
  DWORD dwPhysAddrLen;

  // 물리 주소. 보통은 mac 주소가 된다. 
  BYTE bPhysAddr[MAXLEN_PHYSADDR];

  // ip 주소 
  DWORD dwAddr;

  // 다음과 같은 값을 가질 수 있다. (4 Static,3 Dynamic,2 Invalid,1 Other) 
  DWORD dwType; 
} MIB_IPNETROW, *PMIB_IPNETROW;

[cpp] 윈도우8 관리자 권한으로 프로그램 실행 시키기

Wed, 17 Jun 2015 23:59:45 GMT

윈도우8에 많은 것들이 변경됐습니다. 그 중에 하나가 UAC 정책입니다. 예전에 UAC를 끄면 UAC가 없는 것과 동일했는데 윈도우8 그게 변경됐습니다. 아예 없는 것이 아니라 관리자 권한 요구가 매니페스트에 포함된 프로그램에게는 사라지는 것과 동일한데 그렇지 않은 프로그램의 경우 UAC를 꺼도 그 프로그램은 일반 권한으로 실행됩니다. 프로그래밍이나 테스트 작업을 하는 사람에게는 조금 불편합니다. 완전히 꺼버리는 방법도 있는데 보안상 그닥 권해 드리고 싶지 않습니다. 관리자 권한으로 자주 사용하는 프로그램의 등록 정보에서 아래 항목을 체크하면 그 프로그램만 관리자 권한으로 실행할 수 있습니다.

종종 반대로 실행된 프로그램 입장에서 현재 실행된 프로세스가 관리자 권한으로 실행됐는지 아니면 일반 권한으로 실행됐는지를 체크할 필요가 있는 경우가 있는데요. 이때는 아래 코드에 나와 있는 것과 같이 프로세스 토큰을 사용해서 관리자 권한인지를 조회해 보면 됩니다.

관리자 권한 체크 코드 소스 코드 다운로드

typedef std::shared_ptr<void> vsptr;

BOOL
IsProcessUserAdmin(HANDLE process, BOOL *is_admin)
{
	HANDLE token;
	if(!OpenProcessToken(process, TOKEN_QUERY, &token))
		return FALSE;

	vsptr token_closer(token, ::CloseHandle);

	ULONG gsize = 0;
	if(!GetTokenInformation(token, TokenGroups, NULL, gsize, &gsize))
	{
		if(GetLastError() != ERROR_INSUFFICIENT_BUFFER)
			return FALSE;
	}

	std::vector<UCHAR> gbuffer;
	gbuffer.resize(gsize);

	PTOKEN_GROUPS ginfo = (PTOKEN_GROUPS) &gbuffer[0];

	if(!GetTokenInformation(token, TokenGroups, ginfo, gsize, &gsize))
		return FALSE;

	PSID admin;
	SID_IDENTIFIER_AUTHORITY auth = SECURITY_NT_AUTHORITY;

	if(!AllocateAndInitializeSid(&auth
									, 2
									, SECURITY_BUILTIN_DOMAIN_RID
									, DOMAIN_ALIAS_RID_ADMINS
									, 0, 0, 0, 0, 0, 0
									, &admin))
	{
		return FALSE;
	}

	vsptr sid_closer(admin, ::FreeSid);

	for(ULONG i = 0; i < ginfo->GroupCount; ++i)
	{
		if(EqualSid(admin, ginfo->Groups[i].Sid))
		{
			*is_admin = TRUE;
			return TRUE;
		}
	}

	*is_admin = FALSE;
	return TRUE;
}

int main()
{
	BOOL is_admin = FALSE;
	if(!IsProcessUserAdmin(GetCurrentProcess(), &is_admin))
		return 0;

	printf("%s\n", is_admin ? "admin" : "not admin");
	return 0;
}

[소고] 강력한 언어란? …

Wed, 17 Jun 2015 23:59:44 GMT

Rica님 블로그를 구경하다가 알게 된 페이지입니다. 학생들이 쓴 에세이를 모아둔 페이지인데 재미있는 글들이 많이 있네요. 처음에 읽은 글이 제법 재밌어서 금방 다 읽겠지, 라는 생각으로 덤볐는데 한번에 다 읽기가 생각보다 좀 빡쎄군요. ㅋㅋ~ 다음에도 읽을 요량으로 링크를 저장해 놓습니다.

http://ropas.snu.ac.kr/~ta/4190.310/essays/

2009년 2번째 에세이 부분을 전부 읽었는데요. <해커와 화가>의 저자 폴 그레이엄 아저씨가 쓴 글들을 바탕으로 에세이를 적어오는 것이 과제였다고 추측됩니다. 주로 좋은 프로그래밍 언어란 무엇인가에 대한 것들을 논하고 있죠. 폴 그레이엄 아저씨의 글들을 읽어 보신 분들은 아시겠지만 그레이엄 아저씨는 Lisp 애호가 입니다. 그가 창업한 Viaweb도 Lisp를 사용해서 성공할 수 있었다고 <해커와 화가>에 나와 있죠.

제가 2009년 2번째 에세이를 전부 읽고 느낀 점은 딱 두가지 였습니다. 1) 국내 최고 학부답게 학생들이 글을 잘 쓴다, 2) 원문에 대한 딴지를 거는 글은 거의 없다는 겁니다. 결론은 대부분 함수형 언어의 칭찬으로 끝이 납니다. 근데 읽고나니 뭔가 좀 쎄한 느낌이 드네요.

[소고] 인과관계

Wed, 17 Jun 2015 23:59:43 GMT

언젠가 워크샵 술자리에서 이사님께서 해주신 우스개 소리 중에 이런 이야기가 있었습니다.

한 과학자가 파리를 가지고 실험을 하고 있었습니다. 한 날은 파리의 청력을 실험하기 위해서 파리를 앉혀 두고는 옆에서 손뼉을 쳤다고 합니다. 그러자 파리가 그 소리에 놀래서 달아났습니다. 과학자는 이어서 파리의 날개를 떼고는 다시 파리 옆에서 손뼉을 쳐서 소리를 냈습니다. 그러자 이 번에는 파리가 날아서 도망을 가지 못하고 그 자리에 그대로 있었습니다. 이를 본 과학자는 그 날 노트에 이렇게 적었다고 합니다. “파리의 귀는 날개에 달려 있다.”

이 이야기를 들은 사람들은 멍청한 과학자를 생각하지만 실상은 우리는 멍청하지 않다고 생각하지만 저런 실수를 곧잘합니다. 많은 사람들이 우울증에 걸린 사람들이 알콜 중독에 걸리기도 쉽다고 생각합니다. 하지만 연구 결과에 의하면 사람들이 우울증에 걸려서 알콜 중독에 걸리기 보다는 알콜 중독에 걸려서 우울증에 걸린다고 합니다. 또 우리는 기분이 좋아서 웃는다고 생각하지만, 반대로 웃으면 기분이 좋아지기도 한답니다.

애매한 문제도 많이 있습니다. 생각의 속도가 빨라서 책을 빨리 읽는 건지, 아니면 책을 빨리 읽다 보면 생각의 속도가 빨라지는건지. 인식이 개선되면(중요한 일을 하고 있다고 판단되면) 처우가 개선되는 것인지(연봉이 올라가는 것인지) 아니면 처우가 개선되면 인식이 개선되는 것인지 같은 것들 말이죠. 찾아보면 더 있을 수도 있겠죠. 여튼 인과관계를 정확하게 판단하는 일은 생각처럼 쉬운 일은 아닌 것 같습니다. 많은 경우에 우리는 농담에 등장한 과학자처럼 행동하고 있는지도 모르겠습니다.

2011년 5월 7일…

Wed, 17 Jun 2015 23:59:42 GMT

#0

집에서 사용하는 마우스가 또 고장이 났다. 증상은 똑같다. 왼쪽 마우스 버튼. 그냥 클릭을 해도 더블 클릭으로 인식되는 경우가 종종 발생한다. 별로 불편할 것 같지 않은 이 고장은 사람을 좀 미치게 만든다. 결국 늘 그랬던 것처럼 지금은 오른쪽, 왼쪽 버튼을 바꿔서 쓰고 있다. 매번 이런 고장이 발생하는 걸 보니 내가 마우스 쓰는 패턴이 이상하다는 생각도 좀 든다. 예전에는 집에 굴러 다니는 것들이 MS 마우스였는데, 지금은 어디 하나 마땅하게 대체해서 사용할 마우스도 없다. A/S를 보내야 하나 심하게 고민하고 있다.

#1

집에 사용하던 모니터가 고장나서 얼마전에 27인치 모니터를 새로 질렀다. 신세경이다. 24인치와 27인치의 차이란 ㅋㅋ~ 한 3년 사용한 것 같은데 무상 A/S가 안될것 같아서 그냥 바꿨다. 원래 사용하던 것도 만족스럽게 사용했는데 이번 것이 더 좋은 것 같다. 단지 강화 유리 처리가 돼서 집에서 사용하면 좀 반들거린다는 단점이 있지만.

#2

4월 이었나 회사 사람이 mp3 파일을 줬다. 그런데 그 중에 몇개가 소리통에서 플레이 되지 않는 문제가 있었다. 특히 이소라의 바람이 분다가 플레이가 제대로 되지 않는게 안타까웠다. 알송은 참 잘도 플레이를 하는데 말이다. 그래서 몇 일 전부터 이 문제를 고쳐야 겠다고 생각하고는 작년에 덮어둔 소스 코드를 꺼내서 보게 되었다. 그리고 고쳐서 릴리즈를 하였다.

언젠가 회사 직원이 그런거 뭐하러 만드냐고 물어본 적이 있었다. 그 친구는 여행 다니고, 술 마시는 걸 좋아하는데 여행은 왜 가고, 술은 왜 마시냐는 질문을 해주고 싶었다. 세상 일이 모두 어떤 목적이 있어서 하는건 아닌데 말이다. 재미삼아 만들어 보는 거지 ㅋㅋㅋ~

#3

난 제법 책 읽는 것도 좋아하고 글을 쓰는 것도 좋아하는데 요즘은 도통 글 쓰는 일을 하고 싶지가 않다. 왜 그런지를 곰곰히 생각해 봤는데 작년 말부터 올초까지 너무 재미없는 글쓰기를 회사에서 너무 많이 해버린 탓인것 같다.

[cpp] 윈도우 종료시키기

Wed, 17 Jun 2015 23:59:41 GMT

프로그램을 작성하다 보면 종종 윈도우 시스템을 종료 시켜야 하는 상황이 발생합니다. Windows 9x의 경우에는 단순히 ExitWindowsEx API를 호출함으로써 윈도우를 종료 할 수 있으나, NT 계열에서는 그게 되지 않습니다. 그 이유는 NT 계열에서 도입된 권한 체계 때문입니다. 시스템을 종료시키는 API를 사용하려면 Shutdown 권한을 가지고 있어야 합니다. 아래 코드는 NT 계열에서 Shutdown 권한 획득후 윈도우를 종료 시키는 방법을 보여주고 있습니다.

ExitWindowsExHelper 함수 소스 코드 다운로드

void ExitWindowsExHelper() 
{ 
    HANDLE hToken; 
    TOKEN_PRIVILEGES tkp; 

    // Get a token for this process. 
    if (!OpenProcessToken(GetCurrentProcess()
                         ,TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, &hToken)) 
        return; 


    // Get the LUID for the shutdown privilege. 
    LookupPrivilegeValue(NULL, SE_SHUTDOWN_NAME, &tkp.Privileges[0].Luid); 

    tkp.PrivilegeCount = 1;  // one privilege to set 
    tkp.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED; 

    // Get the shutdown privilege for this process. 
    AdjustTokenPrivileges(hToken, FALSE, &tkp, 0, (PTOKEN_PRIVILEGES)NULL, 0); 

    // Cannot test the return value of AdjustTokenPrivileges. 
    if (GetLastError() != ERROR_SUCCESS) 
        return; 

    ExitWindowsEx(EWX_POWEROFF, 0); 
}

올빼미형 인간

Wed, 17 Jun 2015 23:59:40 GMT

고백하건데 나는 올빼미형 인간이다. 난 이제껏 내가 그냥 태어날 때 부터 올빼미형 인간이었다고 생각했다. 그런데 내가 올빼미형 인간이 된 것은 다름 아닌 진화에 의한 것이 아닐까란 생각이 들었다. 내가 올빼미가 된 사연은 다름아닌 컴퓨터 때문이다. 난 14살 때 처음으로 내 컴퓨터를 가지게 됐다. 그때 내가 컴퓨터를 할 수 있는 시간은 학교를 마치고 집으로 돌아온 다음 밖에 없었다. 그렇게 학창 시절을 보내고는 대학을 들어갔다. 이제는 더 올빼미가 될 수 밖에 없다. 일단 낮 시간은 여자 친구도 만나야 하고 엄마가 청소도 하고 시끄럽다. 집중이 되지 않으니 일을 할 수가 없다. 자연스럽게 내가 컴퓨터를 할 수 있는 시간은 고스란히 새벽 시간 밖에는 없다. 여친느님도 엄마도 잠드는 바로 그 시간, 황금 시간. ㅋㅋ~ 자연스럽게 나는 새벽에 일을 할 수 밖에 없었다. 이렇게 10년이 넘는 시간을 일을 했다. 이제는 어쩔 수 없이 올빼미가 될 수 밖에 없는 것이다.

회사를 와도 사정은 다르지 않다. 회사의 낮 시간은 사실 진득하게 코딩을 할 수 있는 시간이 아니다. 특히 보안 업체의 하루는 전쟁터와 같다. 여기저기 해킹툴이 나오고 업데이트 요청이 있고, 사용자 로그가 접수되고, 업데이트가 있고, … 한마디로 헬이다. 무한 인터럽트는 자연스런 현상이다. 그나마 우리 회사는 연구실이 분리되어 있어서 소란스럽지는 않은데 그래도 안에 사람이 많이 있다보니 자연스럽게 집중하기는 힘들다.

각종 소음들. 한번은 기계식 키보드를 개발자가 샀길래 집에 가서 쓰라고 돌려보낸 적이 있다. 또각 또각 하는 소리에 당췌 코딩을 할 수 없었기 때문이다. 물론 나도 내가 쓸 때에는 기계식 키보드를 사용하는 걸 좋아한다. 그 손맛과 함께 그 소리마저 뭔가 경쾌하게 들리는 법이다. 요즘은 핸드폰을 두고 가는 개발자들이 있어서 전쟁 중이다. 자리에 두고 갔을 때 전화가 오면 다른 사람들이 피곤하니 좀 들고 다니라고 해도 당췌 들고 다니질 않는다. 물론 다 그런건 아니고 말 안듣는 한 명이 있다. 물론 난 상황이 좀 나은 편인데 회사를 시작했기 때문에 이러한 결정을 내가 컨트롤할 수 있기 때문이다. 즉, 내가 대장이다. 그렇게 모든 변수들을 통제해도 사실 낮 시간은 코딩을 진득하게 하거나 디버깅을 하기에는 소란스럽다. 시끄럽고, 인터럽트가 많이 걸리기 때문이다. 자연스럽게 회사에서도 나는 새벽에 일을 할 수 밖에 없다. 0시에서 7시. 내가 가장 많은 코드를 작성한 시간이고, 가장 많은 버그를 잡은 시간이다.

한번은 이런 일이 있었다. 레거시 코드가 도저히 관리가 되지 않아서 전체를 새롭게 작성한 일이 있었다. 세명이 한 일주일 작업했는데 도저히 진도가 나가지 않았다. 코드가 크지는 않았다. 다해서 3만 라인이 조금 안되는 컴포넌트였다. 그렇게 진도가 나가지 않았다. 그렇게 지지부진 하다 일주일이 지나고 안되겠다 싶어서 작성하던 코드를 다 버리고 밤에 혼자서 작업을 새로 했다. 그러자 이틀만에 동작하는 결과물을 얻을 수 있었다. 물론 밤시간 이틀을 말한다. 그때 느꼈다. 아. 내가 이래서 올빼미가 됐구나.

[일상] 황당 옵션 이야기…

Wed, 17 Jun 2015 23:59:39 GMT

XIGNCODE3에는 현재 대략 160개의 옵션이 있다.

초기에 황당했던 경우가 있었는데 한 업체에서 스플래시를 꺼달라는 요청에 스플래시는 끄는 옵션을 만들었는데 스플래시를 보여주는 옵션이 있었던 것이다. 이 옵션이 황당한 이유는 끄는 옵션을 오프로 켜는 옵션도 오프로 하는 경우에는 옵션이 충돌하는 일이 발생하기 때문이다. 물론 이 또한 릴리즈를 담당하는 직원의 질문으로 알게 되었다. 그 이후로 옵션은 긍정 성향의 옵션만 만들겠다고 다짐했는데 여전히 우후죽순이다.

어제 내일부터 CBT를 시작하는 업체에서 새로운 기능이 필요하다면 이런 저런 옵션을 만들어 달라는 이야기를 했다. 그래서 해당 옵션을 만들어 주고는 코드 정리를 하는데 예전에 그것과 똑같은 옵션을 이미 만들어 놓은 것이 보이는 게 아닌가? 사실 이제 나도 어떤 옵션이 정확하게 어떤 범위에 영향을 미치는지 예측하기가 힘들때도 있다. 핡~

[cpp] GetProcAddress를 편리하게 사용하는 방법

Wed, 17 Jun 2015 23:59:38 GMT

윈도우의 경우 9x와 NT 계열의 함수 세트가 틀린 경우가 있다. 9x에만 존재하는 함수가 있는가 하면, NT에만 존재하는 함수도 있다. 이러한 경우 한 프로그램이 두가지 환경에서 모두 동작해야 하는 경우에 주로 LoadLibrary를 사용해서 해당 함수들을 동적으로 불서서 사용한다. 물론 그 외에도 동적으로 불러쓰는 경우는 매우 많다.

이렇게 LoadLibrary를 통해서 함수를 불러 쓸 때 가장 불편한 점은 함수 포인터를 반환받는 과정이다. 함수 하나하나 마다 모두 GetProcAddress로 함수 포인터를 받아야 하기 때문이다. 이러한 과정을 좀 더 간소화 시킬 수 없을까? 여기에 대한 답이 www.codeproject.com에 나와있다. 바로 가변 인자를 사용한 방법이다. 아래 함수는 실제 원문에 있던 함수를 약간 수정한 버전이다. 출구를 하나로 통일하고, 함수 로드에 실패한 경우에는 항상 DLL을 언로드 하도록 변경했다. 실제 원문은 http://www.codeproject.com/dll/dllease.asp 에서 확인할 수 있다.

GetProcAddresses 소스 코드 다운로드

BOOL GetProcAddresses( HINSTANCE *hLibrary, LPCSTR lpszLibrary, INT nCount, ... )
{
    BOOL bRet = TRUE;
    va_list va;
    va_start( va, nCount );
    
    if ( ( *hLibrary = LoadLibrary( lpszLibrary ) ) 
        != NULL )
    {
        FARPROC * lpfProcFunction = NULL;
        LPSTR lpszFuncName = NULL;
        INT nIdxCount = 0;
        while ( nIdxCount < nCount )
        {
            lpfProcFunction = va_arg( va, FARPROC* );
            lpszFuncName = va_arg( va, LPSTR );
            if ( ( *lpfProcFunction = 
                GetProcAddress( *hLibrary, 
                lpszFuncName ) ) == NULL )
            {
                lpfProcFunction = NULL;
                bRet = FALSE;
                break;
            }
            nIdxCount++;
        }
    }
    else
    {
        bRet = FALSE;
    }
    va_end( va );
    
    if(bRet == FALSE && *hLibrary != NULL)
        FreeLibrary(*hLibrary);
    
    return bRet;
}

사용하는 방법은 무척이나 간단하다. 첫번째 인자로 리턴받을 DLL인스턴스 핸들을, 두번째 인자로 DLL 파일명을, 세번째 인자로 로드할 함수 갯수를, 그 다음부터는 함수 포인터의 포인터와, 함수명을 교대로 적어주면 된다. 말로하니 매우 복잡한데, 실제 사용예를 보면 금방 알 수 있다. 아래는 kernel32.dll에서 CreateFileW와 CloseHandle 함수를 로드하는 방법을 보여준다.

HINSTANCE hinst;
GetProcAddresses(&hinst, "kernel32.dll", 2, 
                 &fnCreateFileW, "CreateFileW", 
                 &fnCloseHandle, "CloseHandle");

기억1

Wed, 17 Jun 2015 23:59:37 GMT

이제는 흐릿해진 기억인데 아마도 초등학교 3-4학년 정도 였던 것 같다. 그 해 여름 난 우리 동네에 있는 갈비집 형들과 놀았던 기억이 있다. 신기한 사실은 난 그 형들을 그 전에도 알았고, 그 후에도 알았지만 그 해 여름 말고는 친하게 놀았던 기억이 거의 없다. 근데 무슨 이유였는지 그 해 여름에는 퍽이나 붙어 다니면서 자주 놀았다.

갈비집 아저씨는 자식이 세 명 있었다. 아들, 아들, 딸이었는지 아들, 딸, 아들이었는지 잘 기억이 나질 않는데 아무튼 아들이 둘이었고 딸이 하나였다. 셋 다 나보다는 나이가 많았다. 그 당시 우리 동네에는 두만이라는 전설적인 깡패가 있었다. 내가 한글을 배우던 무렵부터 동네 녀석들한테 듣게 된 전설인데 사실 초등학교를 졸업할 때까지 그 전설의 깡패를 실제로 마주한 적은 없었다. 그런데 소문에는 그 전설의 깡패를 대적할 수 있는 유일한 사람이 갈비집 큰 형이라는 이야기가 있었다.

갈비집은 제법 컸다. 큰 마당이 있었고 그 속에 건물이 대략 세 개 정도 있었다. 주인 아저씨는 장사가 잘되서 나중에는 호텔 뒷편 건물에 분점을 내기도 했었다. 그 해 여름을 나는 매일같이 그 형들과 갈비집 마당에서 의미없는 장난을 하고 놀았다. 우리가 가장 많이 한 장난은 개미를 잡아서 싸움을 붙이는 것이었다. 마당에는 큰 개미들이 정말 많았다. 우리는 그 중에 두 마리를 잡은 다음 더드미를 뜯어서 싸움을 붙였다. 왜 그런 장난을 했는지는 모르겠지만 우리는 그게 재밌다고 생각했다. 사실 난 그 때나 지금이나 왜 더드미를 뜯으면 개미들이 싸우는지 모른다. 그런데 형들이 그렇게 싸움을 붙였고, 그러면 실제로 개미들은 싸우는 것처럼 보였다.

무던 덥던 날이었다. 약간은 꿉꿉하기도 했다. 난 어김없이 갈비집으로 갔고 형들과 의미없는 장난질을 치고 있었다. 그러다 그 큰 형이 오늘은 진짜 재미있는 걸 보여주겠다며 따라오라고 했다. 거미가 싸우는걸 구경시켜 준다고 했다. 우리는 그 마당의 구석진 곳으로 이동했고 거기엔 실제로 거미가 있었다. 거미집을 아름답게 쳐놓고 있었다. 형은 그 평화로운 거미집에 개미를 넣었다. 그리고 난 티비가 아닌 현실 세계에서 거미가 어떻게 먹이를 잡는지 구경할 수 있었다. 거미집에 떨어진 개미는 아무런 저항도 하질 못했다. 시종일관 열세였다. 내가 받았던 가장 큰 충격은 거미가 그 개미를 실을 풀어서 칭칭 감는 장면이었다. 배가 불러서 나중에 먹으려고 그러는지는 알 수 없었지만 진짜 와우에나 나오는 것처럼 거미는 흰 실을 풀어서 개미를 칭칭 감았다. 거의 다 감길 무렵 그 형은 안되겠다며 성냥에 불을 붙여서 거미집에 던졌다. 지금도 생생하게 기억날만큼 굉장히 쇼킹한 장면이었다. 그 사건을 끝으로 아마도 난 그 갈비집에 더는 놀러가질 않았던 것 같다.

내가 그 형제의 소식을 마지막으로 들은 건 고등학생 때였다. 부모님께서 우연찮게 그 갈비집 이야기를 했는데, 얼마 전에 작은 아들이 오토바이를 타다가 교통 사고로 죽었다는 이야기였다.

예비군 퇴소 풍경~

Wed, 17 Jun 2015 23:59:36 GMT

월요일부터 수요일까지 예비군 동미참 훈련을 받고 있습니다. 처음엔 와 3일씩이나 이걸 어케 받으라고 하는 기분으로 갔는데 첫 째날, 둘 째날 갔다 오니 생각보다 할만하네요. 예비군 훈련장 경치가 너무 좋아서 사실 좀 놀랬습니다. 맨날 사무실에 틀어박혀서 바깥 세상에 단풍이 드는지, 하늘이 저렇게 높은지 보지도 못하고 지냈는데 거기 가서 실컷 보고, 멍때리고 하니 그것도 나름 좋네요. 뭐니뭐니해도 최고는 도시락먹고 벤치에 드러누워 자는 오침인 것 같습니다. 양지바른 곳에 자리잡고 누워 자니 그것만한 신선 놀음이 없더군요. ㅋ 평소 일상에 치여 놓치고 있던 많은 것들에 대해서 생각해볼 수도 있는 좋은 기횐 거 같습니다.

저는 3년찬데, 2년을 학교에서 받았습니다. 그래서 사실 동미참 훈련은 처음 받는 거나 다름 없죠. 훈련장에서 훈련 마치고 나올 때 부러운 사람이 많더군요. 신분증받고 걸어 나가면서는 집 가까운 사람들이 부럽습니다. 주차장 즈음을 지날 때에는 차를 가지고 온 사람들이 부럽더군요. 그리고 정문을 나서면 애인이 데리러 온 사람이 젤 부럽습니다. 예비군 훈련 마쳤다고 데리러 오는 사람들도 있더군요. 차 가지고 데리러 온 사람들은 그나마 이해가 되는데 어제는 날씨도 추훈데 아리따운 아가씨께서 초미니 스커트를 곱게 차려입으시고는 누군가를 기다리고 있더군요. 좀 황당했습니다. 사실은 부러운 ㅋㅋㅋ~

— 2007.10.30

김태희 얼굴 사수하기

Wed, 17 Jun 2015 23:59:35 GMT

CAP201008161239

"CAP201008161237"

맛폰을 처음 샀을 때 이러고 놀았다. 지금은 그 어떤 설정도 변경하지 않지만 말이다. 그때는 의욕에 넘쳐서 루팅하고 패치하고 그랬던 것 같은데. 그때나 지금이나 여전히 느린건 마찬가지… 제발 내가 사용하는 모든 걸 제외하고 그 어떤 것도 백그라운드로 돌지 않았으면 좋겠다. 내가 산 하드웨언데 왜 그게 기본적으로 안될까낭? 잡스가 관리자 권한에 대한 설정을 애시당초 제대로 설계하지 않았다에 진짜 백만표 던지고 싶다. 내가 산 하드웨어 내가 관리자가 아니면 누가 관리자란 말인가? 팀쿡인가? 아님 이재용인가? ㅠㅜ~

[py] 파이썬 문자열 0 채우기…

Wed, 17 Jun 2015 23:59:34 GMT

시작

회사 웹 시스템 소스 코드를 보다가 다른 사람이 다음과 같이 코드를 작성해 놓은 것을 보았다.
뭔가 께림칙한 이 느낌. 일단 삭제.

s = '1234'
for i in range(7 - len(s)):
    s = '0' + s

내 생각

다음과 같이 고쳤다.

s = '%07d' % (int(s))

zfill

그런데 이미 있었다.

s = s.zfill(7)

블랙 기업

Wed, 17 Jun 2015 23:59:33 GMT

얼마 전 들은 직원들의 불만 사항 중에 하나가 “고객 복지도 중요하지만 노동자 복지도 중요하다고 생각한다”는 것이었다. 그러면서 떠오른 동영상 하나. 그리곤 드는 생각. 열심히 한다고 했지만 잘하진 않았던 것 같다. 우린 아니겠지, 라고 생각하지만 그 어떤 기업도 이 잣대로부터 자유로울 수도 없다는 생각도 들었다. 퐁티의 말처럼 신체를 가지고 있는 한 폭력은 숙명인 것처럼 기업을 하는 한 착취도 숙명이 아닌가라는 생각이 들었다. 구조가 그렇고, 시스템이 그렇다. 그냥 뭔가 이상한것 같다는 생각이 계속 든다.

Your browser does not support the video tag.

우리는 순진무구함과 폭력을 선택하는 것이 아니다.

폭력의 종류를 선택하는 것이다.

우리가 신체를 가지고 있는 한 폭력은 숙명이다.

– 휴머니즘과 폭력, 메를리 퐁티

한창 와우를 할 때 였다. 그당시 너무 심취해서는 거의 와우에 빠져 살다시피 했었다. 그러던 어느날 어려운 던전 보스를 잡고 우리는 뭉쳤다. 모임에 나가 보니 대다수가 대학생이었고, 내가 두 번째로 나이가 많았다. 새파란 대학생들이 그런다. 형 그래도 우리는 게임 폐인은 아니잖아요. 그 당시 나는 밥 먹을 시간도 없어서 짜장면을 먹으며 게임을 했었고, 그 친구들은 나보다 더 많은 시간을 접속해 있는 아이들었다. 그만큼 우리는 자신과 관련된 것들에 대해서는 정당한 평가를 하지 못하는 것 같다. 그 대학생 공대장을 비웃을 일이 아니었다.

오해

Wed, 17 Jun 2015 23:59:32 GMT

출처: 위키피디아

1993년 뉴욕 타임즈에 한 장의 사진이 게재됐다. 수단의 한 아이가 죽어가고 있고, 그 옆에는 독수리가 그 아이가 죽기만을 기다리고 있는 사진. 독수리는 죽은 고기만 먹기 때문에 아이가 죽기를 기다리고 있었던 것이다. 이 사진이 게재된 뉴욕 타임즈에는 항의 전화가 빗발쳤다. 도대체 이 사진을 찍은 사진 작가는 뭐하는 놈이냐? 저 상황이 사진이나 찍고 있을 때냐? 아이를 구하는게 먼저 아니냐? 누구나 사진을 보고 느낄 법한 항의들. 그만큼 사진은 많은 이들에게 충격적이었다. 이듬해 사진을 찍은 사진 작가 케빈 카터는 그 공로를 인정받아 퓰리처상을 수상했고, 그 후 얼마뒤 자살했다. 물론 사람들의 비난 때문인지 아닌지는 모르겠지만 말이다…

진실은 이렇다. 케빈은 수단 내전의 참상을 알리기 위한 사진을 촬영하기 위해서 수단에 있었다. 한날 그는 보호소를 떠난 좀 먼곳의 실제 상황을 알기 위해 떠나서는 위 장면을 목격했다. 잽싸게 사진을 찍고는 독수리를 쫓아냈다. 하지만 아이는 구하지 못했다. 전염병이 많아서 구호 활동을 하러 온 사람들과 현지인의 직접적인 신체 접촉은 차단되어 있었기 때문이다. 뉴욕 타임즈는 그가 찍은 사진을 잘 알아봤고 수단 내전의 참상을 알리기 위해서 신문에 게재했다. 사람들은 뉴욕 타임즈의 의도대로 엄청난 감정의 폭풍을 경험하고 내전의 참상을 알게 됨과 동시에 사진에 대한 온갖 비난들을 쏟아냈다. 그런 상황을 지켜본 퓰리처 재단은 퓰리처 상을 수여했다. 그리고 얼마뒤 사진 작가 케빈은 자살했다.

그 사진을 찍은 작가, 게재한 뉴욕 타임즈, 분노한 사람들, 상을 수여한 퓰리처 재단…

사실 누구도 잘못하지 않았다. 하지만 사진 작가는 자살을 했다.

오해 – 법정

‘나는 당신을 죽도록 사랑합니다’라는 말의 정체는

‘나는 당신을 죽도록 오해합니다’일지도 모른다.

누가 나를 추켜세운다고 해서

우쭐댈 것도 없고,

헐뜯는다고 해서 화를 낼 일도 못 된다.

그건 모두가 한쪽만을 보고 성급하게 판단한

오해이기 때문이다.

오해란 이해 이전의 상태가 아닌가.

문제는 내가 지금 어떻게 살고 있는가에 달린 것이다.

실상은 말 밖에 있는 것이고

진리는 누가 뭐라 하든 흔들리지 않는다.

온전한 이해는 그 어떤 관념에서가 아니라

지혜의 눈을 통해서만 가능하다.

그 이전에는 모두가 오해일 뿐이다.

의사와 환자

Wed, 17 Jun 2015 23:59:31 GMT

Breaking AV Software

회사 생활을 하다보면 참 재미난 일이 많이 있는데 그 중에 젤 황당한 일이 의사와 환자가 뒤바뀌는 경우다. 보통은 의사가 환자를 진단하고, 환자는 의사의 처방전을 받아 들이기 마련이다. 그런데 주객이 전도되서는 의사가 환자에게 처방전을 물어보고, 환자가 의사에게 처방을 지시하는 경우들이 종종 있다. 황당하게도 말이다. 그리고 말미엔 꼭 탈이 난다. 내가 의사인지 환자인지, 내가 처방전을 쓰는 입장인지 받아야 하는 입장인지를 잘 판단하는 게 회사 생활의 기본인 것 같은데도 어려운것 같기도 하고 그렇다.

세상의 모든 문제가 그렇게 틀리면서 배우기 때문이란다

Wed, 17 Jun 2015 23:59:30 GMT

우진아,

12번 수학문제를 틀리는 것을 두려워하지 마라

몇 번의 시험

몇 번의 만남

그리고 몇 번의 헤어짐

몇 번이 될지 모르는 입사 면접

너는 앞으로도 수많은 문제들을 만나고

결정해야 될지도 모른단다

수학은 틀려야 한다

그것도 용감하게 틀려야 한다

세상의 모든 문제가

그렇게 틀리면서 배우기 때문이란다

숫타니파타

Wed, 17 Jun 2015 23:59:29 GMT

집착 없이 세상을 걸어가고

아무것도 가진 것 없이

자기를 다스릴 줄 아는 사람

모든 속박을 끊고

괴로움과 욕망이 없는 사람

미움과 잡념과 번뇌를 벗어 던지고

맑게 살아가는 사람

거짓도 없고 자만심도 없고

어떤 것을 내것이라 집착하지도 않는 사람

이미 강을 건너 물살에 휩쓸리지 않는 사람

이 세상이나 저 세상이나 어떤 세상에 있어서도

삶과 죽음에 집착이 없는 사람

모든 욕망을 버리고 집 없이 다니며

다섯 가지 감각을 안정시켜

달이 월식에서 벗어나듯이 붙들리지 않는 사람

모든 의심을 넘어선 사람

자기를 의지처로 하여 세상을 다니고

모든 일로부터 벗어난 사람

이것이 마지막 생이고 더 이상 태어남이 없는 사람

고요한 마음을 즐기고

생각이 깊고

언제 어디서나 깨어 있는 사람

– 숫타니파타 490-503

여유에 관한 발칙한 생각

Wed, 17 Jun 2015 23:59:28 GMT

**Let it be**

#0

회사 직원과 둘이 점심을 먹으면서 이런 저런 이야기를 했다. 그 친구 왈 요즘은 너무 여유가 없다는 이야기를 했다. 그도 그럴것이 인원은 한정돼 있고 사이트는 계속 늘어나니 예전엔 조금씩 있던 여유가 지금은 한톨도 없다는 이야기를 한다. 그러면서 뭔가 새로운 일을 하고 싶어도 여유가 없으니 당장 코앞에 벌어진 일만 할 수 밖에 없다는 푸념을 했다. 조곤 조곤 하는 이야기를 듣고 있노라니 많이 공감이 갔다. 단지 시키는 입장에서는 왜 이것도 안되고 저것도 안되냐고 닥달하기 쉽지만 직접 일을 하는 입장에는 사소한 거 하나를 처리하는 데에도 시간이 걸리는 게 일이 아닌가라는 생각을 왜 못했나 싶었다. 난 메모리 액세스 속도를 기대했는데 사실 I/O는 SSD도 아닌 하드디스크도 아닌 플로피디스크였던 것이다. 섹터 찾는데도 시간이 걸리는 물리적인 한계가 있었던 것이다.

여유가 많이 없어졌군. 이런 생각을 하면서 회사로 복귀했다.

#1

저녁 무렵. 집 근처에 사는 후배 녀석을 만났다. 집 앞 콤마라는 커피숍에 앉아서는 이런 저런 이야기를 하는데 녀석도 비슷한 이야기를 한다. 의료 정보쪽 회사에서 프로그래머로 일하고 있는데 일이 쉽지가 않은 것이다. 사실은 회사 정책을 탐탁치 않아 하는 분위기 였다. 그 회사는 규모도 크고 매출도 제법 되는 회산데 회사에서 후배가 하는 프로젝트에 돈을 쓰기 보다는 다른 신사업에 돈을 쏟아 붓는다는 것이었다. 현재 그 회사의 캐시카우는 후배가 하는 프로젝트임에도 말이다.

그래서 난 그런 말을 했다. 경영자가 미래 사업 방향을 그 신사업으로 정했다면 그건 어느 정도 납득이 되는 이야긴거 같다고. 그래서 진짜 네가 힘든게 뭐냐고 물었더니 회사 직원과 똑같은 이야기를 한다. 여유가 없다는 것이다. 이건 뽑아 먹어도 적당히 뽑아 먹어야 하는데 정말 토나오는 상황이라는게 그 친구의 말. 예를들면 이런 식이었다. 그 친구가 일주일에 통상적으로 처리해야 하는 레드마인 이슈가 10개라면 의욕도 있고 회사에서 어느 정도 인정도 받고 있어서 15개 정도를 처리하겠다고 열심히 하는데 그 중간 중간에 하나도 아니고 시도 때도 없이 인터럽트와 추가 이슈가 들어온다는 이야기였다.

듣고 있는데 참 남 일 같지 않다는 생각이 들었다. 특히나 점심 때 그런 이야기를 들었으니 ㅠㅜ~ 회사 생활이라는게 참 쉽지 않구나라는 생각. 녀석은 들어가면서 그랬다. 남의 돈 버는게 어디 쉽나요…

#2

지난번 블로그에 코드의 색깔을 찾아서라는 글에 문제를 냈었다. 몇 분이 답을 보내주었는데 모르는 분이 한 분 포함돼 있었다. 관심가져 주신게 고맙기도 하고 어떤 분인지 만나 보고 싶기도 해서 연락을 해서는 만났다. 만나서 통성명을 하고 인사를 하는데 큰 형님이셨다. 그러면서 이런 저런 좋은 이야기를 많이 했었다. 게임 업계에 있다가 지금은 제조 쪽에서 프로그래밍을 하고 계시다고 했다. 재밌는 문제 푸는 걸 좋아해서 한번 해봤다는 이야기를 했다.

그 이야기 중간에 이런 이야기가 있었다. 그래도 연구소장 정도 되니까 블로그에 코드 색깔 스크립트나 짜서 올리고 하는 여유가 있는 것 같다고. 직원들 입장에서는 그런 걸 할 시간이 없지 않겠냐는 이야기. 형의 그 이야기를 나도 반박하지는 않았다. 내가 봐도 우리 회사 직원들은 바빠서 그런 일을 할만한 시간이 없다고 생각됐기 때문이었다. 그래서 내가 생각해도 회사 직원 입장에서는 바빠서 아마 그럴 시간은 없는게 맞는것 같다는 이야기를 했다.

#3

비오는 오후 사무실에 의자에 앉아서 창밖에 내리는 비를 물끄러미 바라보며 커피를 한 잔 하고 있는데 갑자기 그런 생각이 들었다. 이 여유란 것도 어떻게 보면 빈익빈 부익부가 심할 수도 있겠다라는 생각. 나는 사실 여유가 많은 편이다. 커피를 한 잔 하고 싶으면 쉴 수도 있고, 코드 쓰다가 머리 아프면 잠시 나갔다 올 수 도 있고, 집에서 일하고 싶으면 집에서 일한다. 그러니 어쩌면 직원 입장인 친구들보다는 새로운 것들이나 문제점을 찾기가 훨씬 더 쉬운 위치에 있는지도 모른다. 그리고 그런 일들이 쌓이면서 내가 훨씬 더 여유를 많이 가질 수 있는 위치에 있게 되고 말이다. 결국 선순환과 악순환인 두 개의 피드백 루프가 있다면 어쩌다보니 난 재수가 좋아서 선순환의 피드백 루프에 들었던게 아닌가라는 생각이 들었다.

지금 당장 문제를 해결할 시간도 없는데 go, rust, f# 같은 언어를 주목할 필요가 있다는 이야기는 그 친구들에게는 어쩌면 밥이 없으면 빵을 먹으라는 말처럼 들리지 않았을까? 내리는 빗방울만큼 생각도 많아지는 오후…

40대 개발자는 뭐 먹고 사나요?

Wed, 17 Jun 2015 23:59:27 GMT

김종득님이 얘기 하시는 것처럼 제가 대학교 다닐 때에 선배들이 30살 되면 프로그램 못짠다고 이런 얘기를 하셨고요. 근데 보니까 그 얘기 하시던 선배들은 프로그램 못짜던 선배였어요. 제가 30살 되니까 40살 되면 프로그램 못짠다고 이런 얘기를 많이 하시는데 근데 그 얘기 하시는 분들이 또 프로그램 못 짜던 분들이 그런 얘기 하셨던 것 같구요.

– 송재경

30대 중반까지 코딩하는 입장에서 전적으로 틀린 말은 아니라고 생각한다. 그런데 반전은 한살 한살 먹으면서 느끼는게 점점 더 똑똑해지기 보다는 멍청해지기가 쉽다는 점이다. 예전보다 똑똑함이나 총명함을 유지하기가 정말 쉽지 않은 것 같다. 20대 때 프로그램 좀 짠다고 했던 사람이 30까지 그 실력을 유지하거나 발전시키기가 생각만큼 녹록치 않다는 말이다. 그러니 그 나이 또래 때 그럭저럭 한다고 생각해도 나이들면 쉽게 쉽게 추락하고 도태돼 버리는 게 아닐까라는 생각. 물론 신입만큼 하기야 쉽겠지만 말이다. 해외에는 나이든 엔지니어가 많다고 해도 그래프를 보면 쭉쭉 줄어들기는 마찬가진거 같다. 그나마 인력 풀이 크니깐 살아남는 사람이 상대적으로 많은 게 아닐까라는 생각이 많이 든다.

대체로 출연자들이 대박 욕 먹은 동영상이긴 하지만 찬찬히 한 번 들어볼 필요는 있는 내용이 아닐까 싶다. 욕해도 그게 현실이기도 하고…

애플, 맥, OS X, iOS 관련 내용들…

Wed, 17 Jun 2015 23:59:26 GMT

기본적으로 윈도우와 HOME/END 키 동작 방식이 다름

HOME/END 키 동작 방식 변경 방법

http://mwholt.blogspot.kr/2012/09/fix-home-and-end-keys-on-mac-os-x.html

컨트롤 대신 대부분 단축키가 윈도키에 조합됨

ctrl + c => win + c

ctrl + tab => win + tab

ctrl + p => win + p

ctrl + z => win + z

다윈 커널 소스

http://opensource.apple.com/source/xnu/xnu-2422.90.20/

top 소스 코드

http://opensource.apple.com/source/top/top-89.1.2/

[소고] 우공이산의 지혜

Wed, 17 Jun 2015 23:59:25 GMT

나에게 20살은 자유를 의미했다. 경제 활동을 시작하면서 난 부모님에게서 독릴할 수 있었고, 모든 결정을 내 멋대로 할 수 있었다. 대학도 그랬다. 난 1년 동안 거의 학교에 가지 않았다. 물론 학교는 갔었지만 수업을 듣지 않았다. 사실 내 수업보다 여자친구 수업을 더 많이 들었었다. 당연히 나의 성적표는 대부분 F로 채워졌다. F가 아닌 과목은 거의 대부분 내 앞에 있었던 신명진이란 여자 아이가 출석을 부를 때 내 이름을 자기 이름으로 잘못 들어서 대출한 과목이었다. 학사경고였다. 시쳇말로 쓰리고면 제적이었기에 두번째 학사경고를 받았을 때 귀댁의 자녀가 위기에 처했다는 전화가 집으로 왔다. 내가 받았다면 난 제적을 당했을지도 모른다. 다행이 엄마가 받았고 집에는 난리가 났다. 그 등살에 난 2학년 부터는 수업을 조금씩 듣기 시작했다.

그렇게 참가한 기초 전자 전기 실험에서 그 형을 처음 만났다. 당시 난 병특을 준비하고 있었고, 그 형은 병특을 마치고 학교를 복학한 상태여서 우리는 금방 친해졌다. 가끔 술도 한잔 하면서 이야기를 많이 했었는데 영어를 잘했으면 좋겠다는 이야기를 하는 나에게 형은 병특을 시작하면 영어 단어를 하루에 하나씩 외우라는 판에 박힌 조언을 해줬다. 진짜 정말 너무 어처구니가 없어서 형한테 욕을 할 뻔 했다. ㅋ~ 난 당현하게 형은 영어를 못할 거라는 생각을 가지고 있었다.

우리는 더 많은 실험을 했고, 더 많이 친해졌고, 더 많은 사실을 알 수 있었다. 그러다 약간 놀랄만한 사건이 하나 있었다. 한날은 형이 실험을 하러 오면서 뭘 보고 있기에 뭐냐고 하니깐 아이트리플이라고 했다. 난 IEEE를 그렇게 읽는다는 걸 그때 처음 알았다. 그리고 학교에서 무료로 볼 수 있는 잡지를 직접 구독하는 사람이 우리과에 있다는 사실에 두 번 놀랬다. 형은 나에게 싸게 구독할 수 있는 요령을 알려주었지만 난 받아들이지 않았다. 그리고 얼마되지 않아서 더 놀라운 사실을 접했다. 나에게 하루에 영어 단어를 하나씩 외우라고 조언했던 그 형이 학교 신문에 났기 때문이었다. 그것도 무려 ACM 대학생 논문 경진대회 대상을 수상했다는 명목으로 말이다.

난 놀래서 형한테 왜 그런 이야기를 안했냐니 대단한게 아니라서 말을 안했다는 허무한 대답을 들었다. 그러면서 어떻게 그런 대회에서 상을 탔냐고 도대체 어떤 논문이었냐고 어떻게 그런 생각을 해내게 됐냐고 꼬치꼬치 캐물었다. 형은 답했다. 그냥 앉아있다 이렇게 하면 더 좋지 않을까라는 생각에 써서 냈다고. 학비가 없어서 좀 더 간절했다는 더 어처구니 없는 대답. 멘붕~

난 병특을 시작했다. 영어를 잘하고 싶다는 생각은 있었지만 형의 조언은 상콤하게 씹었다. 사실 생활하는데 영어가 그닥 필요하지 않았기 때문이다. 그때나 지금이나 난 영어 라이팅을 배우고 싶은데 쉽지가 않다. 그러면서 그냥 형은 원래 타고날 때부터 머리가 좋았겠지, 엄마 뱃속에서 영어를 배웠다고 생각했다.

국방부 시계는 간다고 나의 병특도 어느새 끝이났다. 사실 돌아보니 너무 금방 끝이 났다. 난 영어 단어를 하나도 외우지 않았다. 형은 졸업을 했고 카이스트에 석사로 갔다. 학교 앞에서 한 번 만날 일이 있었다. 난 복학하면서 잔뜩 유학 거품이 들어 있었던터라 GRE를 준비한답시고는 겉멋에 찌들어 살고 있었다. 그날도 그랬다. 난 워드 스마트를 보면서 이런 단어를 내 평생에 한 번은 쓸까라면서 멘붕에 빠져있는데 형이 들어왔다. 옆에 책을 한 권 끼고 있었는데 날 좌절하게 만들기에 충분했다. 내가 중딩인지 고딩인지 그때 보던 능률 보카를 끼고 온 것이다. 당시 형은 GRE를 준비하는 게 아니라 실제로 GRE를 치던 시점이라 너무 어처구니가 없었다. 그리곤 형이 단어를 하나씩 외우라고 한 조언이 빈 말이 아님을 알 수 있었다. 능률 보카에 형광펜을 칠하면서 보고 있었기 때문이다.

복학 이펙트는 오래가지 않았다. 한 학기 반짝하고는 난 또 그냥 그런 학교 생활을 했다. 난 학점을 메꾸지도 못했고, 유학을 가지도 못했다. GRE는 한 번 쳐보지도 못했다. 그만큼 빨리 포기했다. 반대로 형은 GRE에서 상당한 수준의 점수를 받았고, MIT로 유학을 떠났다.

이런 이야기를 하면 많이들 그 형은 원래 천재였고, 1학년부터 착실히 공부를 했으며, 그래서 그런 엄청난 결과를 얻었을 거라는 이야기를 한다. 하지만 웃긴 사실은 그 형도 학사경고를 받았으며, 1학년 때에 술을 많이 마시고는 모텔을 간적이 있었다고 했다. 모텔에 가서도 술판이 한창 벌어졌는데 같이 술을 마시던 선배가 너무 술을 마니 마셔서 수영을 하자는 제안에 모텔 바닥에서 수영을 한적이 있었다고 했다. 차마 무엇과 함께 수영했는지는 상상에 맡기겠다.

너무나 많은 시간이 지났다. 난 여전히 우공이산의 지혜를 머리로만 이해한다. 회사에 2년만에 신입 개발자가 첫 출근을 했다. 난 제프리 리처의 Windows via C/C++을 건내며 앞으로 한달간 이 책만 씹어먹어도 위대한 시스템 프로그래머가 될 수 있다는 이야기를 해 주었다. 이 똑같은 이야기를 난 몇 차례 했었는데 그 어떤 신입 개발자도 그 책을 씹어먹진 않았다. 너무 시시하다는 반응이 대부분이었다. 참 안타까운 일이 아닐 수 없다. 난 이 바닥에서 10년을 일했고, 그래도 나름 못한다기 보다는 잘한다는 평을 받으면서 일했다. 개인적으로도 경쟁력은 있다고 생각해 왔었다. 그런데도 난 여전히 100번도 더 읽었던 Windows via C/C++에서 힌트를 얻고 제프리 리처가 1999년도에 쓴 글을 읽으면서 감탄한다. 촌스럽다고 느끼지만 현실은 그렇다.

형을 마지막으로 본게 9년전 카이스트였던 것 같다. 그때 우리는 10년 후를 이야기 했었다. 같이 간 형은 입사한 대기업 부사장이 되겠다고 했고, 난 벤처기업을 차리겠다는 이야기를, 그리고 형은 미국에 가서 자리를 잡겠다는 이야기를 했다. 내년 초여름이면 꼭 10년이 된다. ㅎㅎ~ 같이 갔던 형은 여전히 그 대기업에 다니지만 부사장이 되기에는 아직 힘들어 보이고, 나는 그때 말한 것처럼 성공하진 못했지만 벤처를 시작하긴 했다. 형은 MIT 연구소로 스카웃되서 갔고, 여전히 MIT에 있다. 형의 안부가 궁금해지는 새벽녘이다. 그 옛날 400원짜리 캔커피 뽑아서는 전소 앞에 쪼롬히 앉아서 조교 씹던게 엊그제 같은데 시간이 이리도 빨리 흘렀다. 하루는 더디 흘러도, 10년은 훌쩍 가버리는 게 세월이 아닌가 싶다.

쉬워 보이는 것도 꾸준히 하는 일은 우리가 생각하는 것보다 훨씬 더 효과적인 방법인지도 모른다. 왜냐하면 거의 모든 사람들이 빠른 길을 찾는다는 명분 아래 정작 아무 것도 하지 않고 시간을 보내기 때문이다. 마치 병특 때의 나처럼 말이다.

재미난 게 없어요…

Wed, 17 Jun 2015 23:59:24 GMT

나이 들어 친구든 지인이든 주변에서 제일 많이 듣게 되는 말 중에 하나가 “재미난 게 없어요”라는 말인 것 같다. 근데 그런 말 하는 사람들 대부분이 실상은 아무 것도 하지 않으면서 저절로 재미있어 지기를 바란다는 점이다. 그런 사람들에게 꼭 보여주고 싶은 테드 영상. 내가 느끼는 기분을 더 잘 표현한 왕멀님의 블로그 글…

[일상] 화…

Tue, 16 Jun 2015 23:59:23 GMT

회사를 경영하는 형이 일 처리를 제대로 하지 못한 팀장에게 화를 냈다며 자책하는 이야기를 했다. 그러면서 뭐가 정답인지도 잘 모르겠다는 이야기도 덧붙인다. 세상에 뭐 그리 딱 떨어지는 정답이 있기야 하겠는가만은… 잘못된건 잘못됐다고 지적할 수 있어야 발전이 있지 않을까라는 생각이 들었다. 나는 완벽하지 않더라도 말이다…

생존한다는 건 장난이나 놀이가 아니다. 생각보다 훨씬 복잡하고 어렵고 힘든 일이다.

일단 성공하면 다 용서되는 불편한 진실…

[리뷰] 회사원

Tue, 16 Jun 2015 23:59:22 GMT

넌 일이 좋냐?

오늘 진짜 이상하시네. 아까도 사고 내고.

과장님은 싫으세요?

나야 그냥 하는 거고. 오래했으니까.

일인데요. 뭐. 좋고 싫고가 어딨어요?

저 고등학교도 짤렸잖아요. 어디가서 이만큼 벌어요?

불만 없어요, 저는. 위에 말이나 잘해줘요. 월급 좀 제대로 받게.

부족해? 지금 받는 거?

네. 불안정 하자나요. 언제 짤릴지도 모르고.

야, 너 이제 스무 살이야.

네.

넌 뭐 되고 싶은 거 없냐고?

부자요. 떼부자.

한 5년 바짝 벌어가지고 미국으로 뜰라구요.

마이애미, LA 이런데 가서 백인 여자들 두세 명씩 끼고…

과장님은 어땠는데요? 과장님 스무 살 때요?

나?

가수 되고 싶었지.

왜 안 하셨는데요?

안 하긴. 못한거지.

가수 별거 없어요. 인기 떨어지면 안 한 것만 못하지.

꼭 해본 것처럼 말한다.

아는 사람이 했어요. 가수.

그래. 누군데?

[cpp] 실수 랜덤 값 생성하기, 2001

Tue, 16 Jun 2015 23:59:21 GMT

C 표준 랜덤함수는 정수의 랜덤값만 생성합니다. 일반적으로 실수 랜덤값은 아래와 같은 나눗셈을 통해서 취득할수 있습니다. 아래 코드는 low에서 high사이의 실수 랜덤값을 생성하는 함수입니다.

double drand(double low, double high) 
{ 
    double d; 

    d = (double) rand() / RAND_MAX;
    return (low + d * (high - low)); 
}

참고로 한가지 더 적으면 터보씨에 있는 랜더마이즈(randomize)함수는 아래와 같은 매크로를 통해 동일하게 정의할 수 있습니다.

#define randomize() srand((int) time(NULL))

—

실수 랜덤 값은 도대체 뭐에 쓸려고 생성한걸까? 사고 실험인가?

[cpp] 10진수를 16진수로 변환하는 함수, 2002

Tue, 16 Jun 2015 23:59:20 GMT

직 로더를 만들면서 제작한 함수 중에 하나입니당. 테이블을 사용하면 깔끔하게 된다는 점이 돋보이는 소스 입니당. 그럼 다들 한번 찬찬히 뜯어 보세염.

int dec2hex(int d, char *h) { 
   int i = 0; 
   char buf[10]; 
   char code[] = {'0','1','2','3','4','5','6','7','8','9','A','B','C','D','E','F'}; 

   do { 
      buf[i++] = code[d % 16]; 
   } while((d /= 16) > 0); 

   buf[i] = '\0'; 
   ReverseStr(h, buf); 
   return 0; 
}

—

13년 지나서 보니 그다지 돋보이진 않는 것 같은데…

[cpp] freeaddrinfo 사용 시 주의해야 할 점

Tue, 16 Jun 2015 23:59:19 GMT

http://msdn.microsoft.com/en-us/library/ms737931(VS.85).aspx

The freeaddrinfo function was added to the Ws2_32.dll on Windows XP and later. To execute an application using this function on earlier versions of Windows (Windows 2000, Windows NT, and Windows Me/98/95), then you must include the Ws2tcpip.h file and also include the Wspiapi.h file.

간단번역: freeaddrinfo는 Windows XP 이후에 추가 했으니, 그전 운영체제에서 사용하려면 ws2tcpip.h는 물론 wspiapi.h를 포함시키렴.

[cpp] 다시보는 assert, 2002

Tue, 16 Jun 2015 23:59:18 GMT

다들 C언어를 처음 배울때 ASSERT라는 매크로를 배우게 된다.별로 의미없이 지나치게 되는 매크로의 하나인데, 사실 알고보면 저것 만큼 디버깅 시간을 줄여주는 매크로는 없다는 생각이 요즘 든다. 버그의 대부분의 근거는 함수 파라미터의 실수나 리턴값의 오류에 기인한다고 할 수 있다. 그런 버그를 원천 봉쇄할 수 있는 방법이 바로 위의 ASSERT 매크로를 사용하는 것이다. 예를 들어 아래 함수를 보도록 하자.

char next_char(char *str) { 
  return *str + 1; 
}

위 함수의 입력값으로는 NULL포인터가 절대로 들어가서는 안된다. 그런 에러를 원천 봉쇄 할 수 있는 방법이 바로 아래와 같은 방법이다.

char next_char(char *str) { 
  ASSERT(str != NULL); 
  return *str + 1; 
}

이제 만약 위의 코드에 NULL값이 입력값으로 들어오면 함수는 동작하지 않고 프로그램은 오류메세지를 출력하면서 종료될 것이다.

[cpp] 입력 버퍼에 관한 진상, 2001

Tue, 16 Jun 2015 23:59:17 GMT

그동안 잘못 알고 있었던 상식중에 입력버퍼에 관한 내용이 있어서 올려봅니다. 제 홈페이지를 통해서도 잘못 전파된 내용이 많을 것 같다는 생각이 드네염. 보통 scanf를 통해서 입력을 받을때 엔터 한번에 쭈루룩 다음 scanf함수까지 넘어가는 것을 본 적이 있을 겁니다. 그런 것들을 보면 보통 scanf하기전에 입력 버퍼를 비우기 위해서 fflush함수를 사용하라고 하는데, 이 fflush라는 놈이 표준안에 정의를 보면 표준 출력에 대해서만 정의되어 있고, 표준 입력에 대해서는 아무런 동작을 하지 않는다는 것입니다. 따라서 fflush(stdin)하는 것은 undefined behavior, 즉 정의되지 않은행동. 따라서 사용하지 말아야 할 행동입니다.

그러면 scanf가 쭈루룩 넘어가는 진상은 과연 어디에 있는가? 입력 버퍼를 비우는 방법은 없는 것인가? 하는 두가지 의문이 드실 겁니다. 일단 첫번째 문제에 대해서 한번 살펴보도록하죠^

scanf는 특성상 개행문자를 입력받지 않는다고 합니다. 따라서 \n을 입력버퍼에 그대로 남겨두게 되고, 다음 번 scanf가 그놈때문에 자동으로 넘어가는 현상이 생기게 되는 것입니다. 따라서 scanf다음에 getchar()등으로 개행문자를 소비해주는 입력함수를 넣어주면 그런 문제를 막을 수 있습니다.

int a;

scanf("%d", &a);
getchar();

그럼 두번째 질문인 입력버퍼에 대해서 알아보도록 하죠. 일반적으로 키보드의 입력 버퍼를 비우는 행동은 표준함수로 제공되지 않습니다. 따라서 그런 행동들은 운영체제나 컴파일러 제조사에 따라 다르다는 이야기입니다. 일반적으로 dos시절에는 아래 함수를 사용해서 입력 버퍼를 비울 수 있었습니다.

while(!kbhit())
    getch();

그리고 gcc를 사용하는 경우에는 stdio.h에 정의된 flushall함수를 사용해서 입력 버퍼를 비울 수 있습니다.

일반적으로 scanf의 경우 입력받은 값이 잘못된 경우 이전 상태로 복원시키는 방법을 전혀 제공하지 않습니다. 따라서 보통의 경우 입력은 문자열로 fgets등을 통해서 입력받은후 sscanf내지는 자신이 직접 제작한 입력함수를 통해서 파싱해 내는 것이 일반적입니다.

—

참 내가 썼지만 깜찍했네 ㅋㅋㅋ~

[cpp] 윈도우8 취약점 완화 관련 API

Tue, 16 Jun 2015 23:59:16 GMT

윈도우 8하면 보통 현란하게 바뀐 시작 화면을 떠올린다. 인터넷을 접한 사람들은 시작 버튼이 없어졌다는 사실 또한 떠올릴 것이다. 그만큼 윈도우 8의 UI 변화는 많은 사람들에게 충격적이었다. 그 UI 변화를 두고 호불호가 많이 나뉘기도 한다. 하지만 윈도우 8의 모든 변화가 단지 표면적으로 드러나는 앱 월드와 데스크톱 월드의 통합 내지는 UI 표현의 변화, 또는 사라진 시작 버튼에만 있는 것은 아니다. 우리에게 직접 나타나지 않는 내부에도 상당히 많은 변화가 있었다. 이런 내부의 경우 굉장히 혁신적인 변화임에도 관심을 가지고 살펴보지 않으면 잘 알기 힘든 부분이라 크게 평가되고 있지 못한 점이 안타깝다.

윈도우 8은 내부에도 엄청난 변화가 있었다. 하지만 윈도우 8을 만든 개발자들은 비스타에서 충분히 많은 교훈을 얻었기 때문에 그 엄청난 변화를 우리가 직접 느낄 수 있도록 만들지는 않았다. 즉, 내부 구조의 변화도 겉으로 드러나는 표면적인 부분의 변화는 극히 제한적이라는 의미다. 하지만 상당히 많은 부분이 개선되었고 또 기존 것들과 충돌을 일으키지 않는 범위 내에서 실험적인 다양한 기능들이 추가되었다. 그런 변화 중에서도 보안과 관련되어 있으면서도 데스크톱 응용 프로그래머들이 알아두면 도움이 될 만한 UAC 정책 변화와 새롭게 추가된 프로세스 보안 정책에 대해서 살펴보도록 하자.

사용자 계정 컨트롤(UAC) 정책 변경 사용자 계정 컨트롤은 윈도우 비스타부터 도입된 개념으로 프로그램이 관리자 권한이 필요한 작업을 수행할 때에 사용자에게 그 행위를 보고함으로써 위험한 작업이 은밀하게 발생하는 것을 방지하는 것을 의미한다. 원래 권한 개념이 크게 부각되지 않은 윈도우에서 그나마 택할 수 있는 정책이었지만 권한을 줬다가 다시 가져오는 작업은 그리 수월하지 않았다. UAC는 비스타를 가로막는 가장 강한 허들이 되었고, 그로 인해서 시장에서 비스타는 실패한 운영체제로 낙인 찍히게 되었다. 윈도우 7은 그런 교훈을 바탕으로 UAC를 좀 더 다듬어서 사용자를 덜 귀찮게 만들어서 내놓는 형태로 사용자와 타협했다.

하지만 사실상 타협했다는 표현은 좀 어폐가 있다. 그도 그런 것이 거의 대부분의 윈도우 7 사용자는 UAC가 기본적으로 켜져 있음에도 굳이 옵션을 조정해서 UAC를 끈 상태로 운영체제를 사용하기 때문이다. 그래서 윈도우 8에서는 UAC 기능을 끄는 것과 관련해서 아주 미세하게 설정을 조율했다.

기존의 윈도우 비스타와 윈도우 7에서는 사용자 계정 컨트롤을 가장 낮은 단계로 설정하는 경우에는 UAC가 없는 것과 동일하게 되었다. 즉, 가장 낮은 단계는 UAC를 끄는 것과 같은 맥락이었다. 하지만 윈도우 8부터는 더 이상 그런 상식이 통용되지 않는다.

윈도우 8에서 사용자 계정 컨트롤을 가장 낮은 선택할 경우에 경고창은 출력되자 않지만 프로그램의 권한 컨트롤은 여전히 적용된다. 이 말이 무슨 의미냐 하면 기존의 윈도우의 경우 UAC가 가장 낮은 단계인 경우에는 오른쪽 버튼을 눌러서 관리자 권한으로 실행 메뉴를 전혀 사용할 필요가 없었다. 왜냐하면 매니페스트에 상관 없이 UAC가 꺼지면 모든 프로그램이 자동으로 관리자 권한으로 실행되었기 때문이다. 하지만 윈도우 8부터는 UAC가 가장 낮은 단계로 설정하더라도 여전히 관리자 권한으로 실행 메뉴를 사용해야 한다.

이를 직접 확인해 보기 위해서는 UAC를 가장 낮은 단계로 설정한 다음 실행 메뉴를 통해서 명령창을 실행하고 관리자 권한을 필요로 하는 명령어를 입력해보면 알 수 있다. <화면 1>나타난 것과 같이 권한이 없어서 명령어가 실패하는 것을 볼 수 있다. 이런 문제 때문에 윈도우 8의 탐색기에는 <화면 2>에 나타난 것과 같이 관리자 권한으로 명령창을 실행하는 메뉴가 추가돼 있다. 이 메뉴를 통해서 관리자 권한으로 실행된 명령창에서 동일한 명령어를 입력하면 정상적으로 수행되는 것을 볼 수 있다.

화면 1 UAC가 꺼진 상태에서 관리자 권한이 필요한 작업을 수행하면 실패한다.

화면 2 탐색기에는 관리자 권한으로 명령창을 실행하는 메뉴가 생겼다.

UAC를 끄더라도 권한 컨트롤이 여전히 수행된다는 것은 프로그램을 그냥 실행시켰을 때 매니페스트에 관리자 권한을 요구하는 표시가 되어 있다면 경고창 없이 그 프로그램을 관리자 권한으로 실행시켜 주지만 그렇지 않은 경우에는 UAC가 가장 낮은 단계로 설정돼 있더라도 일반 권한으로 해당 프로그램을 실행시킨다는 것을 의미한다.

UAC 설정은 HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System 경로에 있는 일부 키 값을 통해서 조정된다. 윈도우 8에서는 UAC에서 가장 낮은 단계를 선택하더라도 <화면 3>에 나타난 것과 같이 EnableLUA 값이 0이 아닌 1로 설정돼 있는 것을 볼 수 있다. <표 1>에는 사용자 계정 컨트롤 설정 값에 따른 UAC 관련 레지스트리 값의 변화가 나와 있다. 표를 살펴보면 다른 부분은 모두 같지만 가장 낮은 단계를 선택한 경우에는 EnableLUA 값이 달라진 것을 볼 수 있다. 이 값을 윈도우 7과 똑같이 조작하면 UAC가 완전히 꺼지도록 만들 수 있다.

화면 3 UAC 설정 관련 레지스트리 키

표 1 UAC 설정에 따른 레지스트리 키 값


설정	윈도우 7	윈도우 8
항상 알림	ConsentPromptBehaviorAdmin: 2 PromptOnSecureDesktop: 1 EnableLUA: 1	ConsentPromptBehaviorAdmin: 2 PromptOnSecureDesktop: 1 EnableLUA: 1
설정 변경 시에만 알림	ConsentPromptBehaviorAdmin: 5 PromptOnSecureDesktop: 1 EnableLUA: 1	ConsentPromptBehaviorAdmin: 5 PromptOnSecureDesktop: 1 EnableLUA: 1
설정 변경 시에 알림 화면 흐리게 하지 않음	ConsentPromptBehaviorAdmin: 5 PromptOnSecureDesktop: 0 EnableLUA: 1	ConsentPromptBehaviorAdmin: 5 PromptOnSecureDesktop: 0 EnableLUA: 1
알리지 않음	ConsentPromptBehaviorAdmin: 0 PromptOnSecureDesktop: 0 EnableLUA: 0	ConsentPromptBehaviorAdmin: 0 PromptOnSecureDesktop: 0 EnableLUA: 1

이 사소한 변화를 통해서 시작 버튼도 없애버린 마이크로소프트가 우리에게 얼마나 UAC를 강요하고 싶어하는지를 엿볼 수 있다고 생각한다. 보안을 생각했을 때 이런 변화가 결코 나쁜 변화는 아니다. 하지만 관리자 권한 매니페스트가 없는 프로그램을 자주 관리자 권한으로 실행해야 하는 사용자에게는 분명 예전보다는 불편해진 점이기도 하다. 이 때에는 프로그램의 호환성 속성을 사용하면 도움이 된다. <화면 4>에 나타난 것과 같이 호환성 설정 부분에서 항상 관리자 권한으로 실행하도록 만들어주는 옵션을 선택하면 해당 프로그램은 매니페스트에 관리자 권한 요구 속성이 없어도 관리자 권한으로 실행시켜 준다.

화면 4 항상 관리자 권한으로 실행하도록 설정

우리가 만드는 프로그램도 사용자가 알아서 저렇게 설정해 주기를 원할 수 있지만 사용자 친화적인 프로그램이라면 이러한 설정을 메뉴를 통해서 옵션으로 제공하는 것도 나쁘지 않다. 프로그램으로 해당 옵션을 조정하는 방법은 간단한 레지스트리 조작으로 할 수 있다. 호환성 플래그를 설정하는 레지스트리 키는 아래 경로를 살펴보면 된다. 해당 경로를 이동하면 <화면 5>에 나타난 것과 같이 호환성이 설정된 프로그램의 목록이 나타난다. 키 값은 해당 프로그램의 경로가 되고, 데이터는 설정된 값을 나타낸다. 관리자 권한으로 실행을 하기 위해서는 RUNASADMIN이라는 문자열을 추가해 주면 된다.

HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers

HKLM\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers

화면 5 항상 관리자 권한으로 실행 기능이 켜진 프로그램의 AppCompatFlags 레지스트리 값

취약점 완화 방안 예전에 스타크래프트란 게임을 한창 즐기던 시절 게임 잡지에 “스타크래프트 상에서 최고의 수비는 상대를 공격하는 것”이란 기사가 실린 것을 본 적이 있다. 그 당시만 해도 우주방어테란만 고집했던 터라 내심 그 기사를 좀 무시했었다. 하지만 이후 임요환 선수가 등장하면서 모든 것이 달라졌다. 고질적으로 공격이 느리던 테란의 단점을 드랍쉽으로 커버하면서 정말 최고의 수비는 방어가 아닌 공격에서 나온다는 것을 온몸으로 보여줬기 때문이었다. 시시한 게임 이야기라고 생각하면 오산이다. 이 전략은 게임 속뿐만 아니라 현실 세계에서도 얼마든지 통용되는 전략이기 때문이다.

모든 프로그래머들은 버그가 없는 프로그램, 보안 취약성이 없는 프로그램을 만들고 싶어한다. 하지만 안타깝게도 현대 프로그램은 그 규모와 복잡도가 너무나 커져 버려서 사실상 그런 프로그램을 만든다는 것은 거의 불가능에 가까워졌다고 할 수 있다. 매일같이 보고되는 수많은 취약점, 제로데이 공격들이 그 근거라고 할 수 있겠다. 이러한 이슈가 발생할 때 마다 프로그래머는 빠르게 관련 문제를 수정하지만 수정한 것을 배포할 때쯤엔 또 다른 버그와 취약점이 기다리고 있다. 이미 속도에서 경쟁이 안 되는 상태가 돼 버린 것이다.

그래서 임요환 선수같이 똑똑한 프로그래머들이 조금 다른 생각을 하기 시작했다. “왜 우리만 항상 이렇게 당해야 하지? 우리도 똑같이 해커를 공격할 방법은 없는 것일까?”라는 생각에서 출발한 전략이 바로 취약점 완화 방안이다. 이 방법의 전략은 단순하다. 어차피 늘 상 있는 버그, 취약점은 인정하겠다는 것이다. 하지만 그런 것들을 알고 있는 해커라고 하더라도 그걸 공격하는 코드를 만드는 것은 어렵도록 만들겠다는 취지다. 그래서 모든 취약점 완화 방안은 근본적인 대책은 아니다. 하지만 이런 사소한 것들이 여러 개 모이면 공격자 입장에서는 다양한 환경에서 항상 정상적으로 동작하는 코드를 만드는 일이 예전보다 훨씬 어려워지기 때문에 공격의 속도가 늦어지고 악성 코드를 만드는 데에 더 많은 비용이 투입되도록 만드는 장점이 있다.

시스템 프로그래머가 아니라면 이러한 방법이 있었다는 것을 모르는 경우가 많지만 사실 윈도우가 취약점 완화 기능을 만들기 시작한지는 제법 오래됐다. 많이 알려진 기능으로는 2002년에 처음 소개된 VIsual C++의 /GS 기능이 있다. 이 기능을 사용하면 스택 오버플로 공격을 통해서 임의의 코드를 실행하는 것을 억제할 수 있다. 2003년에는 SafeSEH라는 기능이 개발됐다. 이미지에 기록된 예외처리 핸들러만 실행하도록 운영체제에서 제한한 것이다. 2004년에는 데이터 실행 방지(DEP) 개념이 소개됐다. 이 기능은 프로그램 내의 스택과 힙과 같은 영역에서 코드가 실행될 수 있는 것을 제한한 기능이다. 윈도우 비스타가 출시되던 2006년에는 주소 공간 배치를 랜덤화 하는 ASLR이라는 기술이 소개됐다. 이 기술은 /DYNAMICBASE 플래그가 지정된 DLL의 로드 주소를 랜덤하게 결정하는 기술이다. 이 기술과 함께 윈도우 핵심 DLL들은 모두 이 플래그를 사용하도록 변경됐기 때문에 윈도우 비스타 이후에는 주소가 하드 코딩된 형태로 시스템을 공격하는 코드는 더 이상 동작하지 않게 되었다. 윈도우 8에는 이런 기존의 취약점 완화 기능들을 보다 향상시키는 한편 새로운 취약점 완화 기능들이 대거 추가했다. 새롭게 추가된 기능에 대해서 하나씩 살펴보도록 하자.

PROCESS_CREATION_MITIGATION_POLICY_FORCE_RELOCATE_IMAGES_ALWAYS_ON
이 정책이 적용된 프로세스는 로드되는 모든 DLL에 대해서 강제로 주소 공간 배치 랜덤화(ASLR) 기능을 적용한다. /DYNAMICBASE가 지정되지 않은 구형 DLL 또한 강제로 랜덤한 주소에 로드하도록 만든다는 의미다.
PROCESS_CREATION_MITIGATION_POLICY_FORCE_RELOCATE_IMAGES_ALWAYS_ON_REQ_RELOCS
이 정책은 앞서 설명한 강제로 ASLR을 적용하는 것에 더불어 재배치 정보가 없어서 랜덤한 주소에 로드할 수 없는 모듈의 경우에는 DLL의 로드를 실패 처리한다. 이 정책이 지정된 프로세스에는 재배치 정보가 포함되지 않은 DLL은 아예 로드 자체가 불가능해진다는 의미다.
PROCESS_CREATION_MITIGATION_POLICY_HEAP_TERMINATE_ALWAYS_ON
이 정책이 지정되면 힙이 손상되는 경우에는 자동으로 해당 힙을 파괴한다. 힙 오버플로나 힙의 메타 정보를 사용한 공격이 발생하는 과정에서 공격자 코드의 결함으로 힙의 정보가 손상되는 경우에는 해당 힙을 바로 파괴해 버리도록 만든다.
PROCESS_CREATION_MITIGATION_POLICY_BOTTOM_UP_ASLR_ALWAYS_ON
스택을 포함한 bottom-up 할당기가 적용되는 메모리 할당에 ASLR을 적용한다.
PROCESS_CREATION_MITIGATION_POLICY_HIGH_ENTROPY_ASLR_ALWAYS_ON
bottom-up 할당기의 할당 범위를 1테라 바이트 주소 공간까지 확장한다. 네이티브 64비트 프로그램에만 적용된다.
PROCESS_CREATION_MITIGATION_POLICY_STRICT_HANDLE_CHECKS_ALWAYS_ON
잘못된 핸들을 사용하는 경우에 즉시 예외가 발생한다. 이 플래그가 설정되지 않은 프로세스에서는 실패 값이 반환된다.
PROCESS_CREATION_MITIGATION_POLICY_WIN32K_SYSTEM_CALL_DISABLE_ALWAYS_ON
win32 서브시스템과 관련된 코드는 유저 모드와 커널 모드에 모두 코드가 존재하면서 상호 정보를 교환하기 때문에 윈도우 구조상 가장 취약한 부분이라고 할 수 있다. 이 정책이 적용된 프로세스는 win32 서브시스템과 관련된 API 호출이 원천적으로 봉쇄된다. 이 말은 쉽게 말하면 user32.dll에 있는 API를 호출할 수 없도록 만드는 옵션이라고 생각하면 된다.
PROCESS_CREATION_MITIGATION_POLICY_EXTENSION_POINT_DISABLE_ALWAYS_ON
높은 수준의 보안성을 유지해야 하는 프로그램에 있어서 AppInit이나 윈도우 훅과 같은 알려진 시스템 루트를 통한 침투는 굉장히 취약한 부분이다. 이러한 기능은 일반적인 프로그램에서도 많이 사용하기 때문에 악의적인 목적의 공격인지를 판단하는 것이 더욱 어렵다. 이 정책이 적용된 프로세스는 이러한 알려진 시스템 루트를 통해서 DLL이 로딩되는 것을 원천적으로 차단된다.

프로세스 취약점 완화 정책 설정

윈도우 8에서 추가된 다양한 취약점 완화 정책들을 살펴보았다. 그렇다면 도대체 이 정책들은 어떻게 설정할 수 있는 것일까? 윈도우 8에서는 그런 목적을 위해서 2개의 함수가 추가됐다. 취약점 완화 정책을 설정하기 위해서 SetProcessMitigationPolicy, 취약점 완화 정책을 조회하기 위해서 GetProcessMitigationPolicy 함수가 추가됐다. 각 함수의 원형은 <리스트 1>에 나와 있는 것과 같다.

리스트 1 SetProcessMitigationPolicy/GetProcessMitigationPolicy 함수 원형

BOOL WINAPI SetProcessMitigationPolicy(
PROCESS_MITIGATION_POLICY MitigationPolicy
, PVOID lpBuffer
, SIZE_T dwLength
);

BOOL WINAPI GetProcessMitigationPolicy(
    HANDLE hProcess
    , PROCESS_MITIGATION_POLICY MitigationPolicy
    , PVOID lpBuffer
    , SIZE_T dwLength
);

함수 사용방법은 간단하다. SetProcessMitigationPolicy의 경우 현재 프로세스에 대해서만 적용되며, GetProcessMitigationPolicy 함수의 경우에는 첫 번째 인자로 넘어간 프로세스의 정책을 구한다. MitigationPolicy에는 <표 2>에 나타난 것과 같은 상수 각을 사용할 수 있다. buffer에는 MitigationPolicy에 지정한 상수에 맞는 구조체의 포인터를, dwLength에는 해당 구조체의 크기를 넘겨주면 된다.

표 2 MitigationPolicy 값

MitigationPolicy 값	설명
ProcessDEPPolicy	데이터 실행 방지(DEP) 정책을 설정한다. buffer에는 PROCESS_MITIGATION_DEP_POLICY 구조체 포인터를 전달한다.
ProcessASLRPolicy	주소 공간 배치 랜덤화 정책을 설정한다. buffer에는 PROCESS_MITIGATION_ASLR_POLICY 구조체 포인터를 전달한다.
ProcessStrictHandleCheckPolicy	엄격한 핸들 체크 정책을 설정한다. buffer에는 PROCESS_MITIGATION_STRICT_HANDLE_CHECK_POLICY 구조체 포인터를 전달한다.
ProcessSystemCallDisablePolicy	시스템 호출 금지 정책을 설정한다. buffer에는 PROCESS_MITIGATION_SYSTEM_CALL_DISABLE_POLICY 구조체 포인터를 전달한다.
ProcessExtensionPointDisablePolicy	프로세스 확장 포인트 금지 정책을 설정한다. buffer에는 PROCESS_MITIGATION_EXTENSION_POINT_DISABLE_POLICY 구조체 포인터를 전달한다.

<리스트 2>에는 ProcessStrictHandleCheckPolicy 정책을 구하고 설정하는 예제가 나와 있다. 프로그램을 살펴보면 첫 번째 VirtualAllocEx는 ProcessStrictHandleCheckPolicy 정책이 설정되기 전에 호출되었기 때문에 일반적인 호출과 같이 함수 실패로 처리된다. 하지만 두 번째 VirtualAllocEx의 경우에는 해당 정책이 설정된 다음에 잘못된 핸들을 사용해서 호출하고 있기 때문에 예외가 발생해서 프로그램이 크래시 되도록 만든다.

리스트 2 PROCESS_CREATION_MITIGATION_POLICY_STRICT_HANDLE_CHECKS_ALWAYS_ON 테스트 소스 코드 다운로드

#define _WIN32_WINNT 0x0602
#include "Windows.h"

int main()
{
    HANDLE process = (HANDLE) 0x4444;

    VirtualAllocEx(process, NULL, 4096, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);
    printf("First VirtualAllocEx Call\n");

    PROCESS_MITIGATION_STRICT_HANDLE_CHECK_POLICY splc1;
    if(GetProcessMitigationPolicy(GetCurrentProcess()
                                    , ProcessStrictHandleCheckPolicy
                                    , &splc1
                                    , sizeof(splc1)))
    {
        printf("DisallowWin32kSystemCalls: %d\n"
                 , splc1.RaiseExceptionOnInvalidHandleReference);
    }

    PROCESS_MITIGATION_STRICT_HANDLE_CHECK_POLICY splc2 = {0,};

    splc2.RaiseExceptionOnInvalidHandleReference = TRUE;
    splc2.HandleExceptionsPermanentlyEnabled = TRUE;
    if(!SetProcessMitigationPolicy(ProcessStrictHandleCheckPolicy
                                     , &splc2
                                     , sizeof(splc2)))
        printf("SetProcessMitigationPolicy fail %d\n", GetLastError());

    PROCESS_MITIGATION_STRICT_HANDLE_CHECK_POLICY splc3;
    if(GetProcessMitigationPolicy(GetCurrentProcess()
                                    , ProcessStrictHandleCheckPolicy
                                    , &splc3
                                    , sizeof(splc3)))
    {
        printf("DisallowWin32kSystemCalls: %d\n"
                , splc3.RaiseExceptionOnInvalidHandleReference);
    }

    VirtualAllocEx(process, NULL, 4096, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);
    printf("Second VirtualAllocEx Call\n");
    return 0;
}

<리스트 2>의 예를 살펴보면 프로그램이 정책을 설정하기 전에는 여전히 해당 정책으로 금지하려는 동작이 수행 가능한 것을 알 수 있다. 이를 보면 당연히 공격자 입장에서 정책이 설정되기 직전에 공격을 한다면 타이밍 공격이 가능하다는 것을 알 수 있다. 더불어 앞서 살펴보았던 정책 중에 ASLR과 같은 것들은 주소 공간의 변화에 대한 것들이라 프로그램이 실행된 이후에 설정하는 것은 아무 의미가 없다. 왜냐하면 이미 프로그램이 실행됐다는 것은 프로그램 실행에 필요한 DLL이 거의 다 로드됐다는 의미이기 때문이다. 따라서 사실상 이런 정책은 앞서 소개한 API를 통해서 설정하는 것 보다는 프로세스 생성시에 지정하는 것이 가장 큰 효과를 가질 수 있다.

<리스트 3>에는 프로세스 생성 시에 정책을 설정하는 것을 보여주고 있다. 실행하면 PROCESS_CREATION_MITIGATION_POLICY_WIN32K_SYSTEM_CALL_DISABLE_ALWAYS_ON 정책을 설정한 다음 파라미터를 추가해서 자기 자신을 다시 실행한다. 다시 실행되면 if문의 코드는 수행되지 않고 뒤쪽의 현재 정책을 출력하고 user32.dll을 로드하는 코드가 수행된다. 이 경우에는 시작 시점에 이미 win32k 시스템 호출 금지 정책이 적용됐기 때문에 user32.dll의 로드가 실패해서 모듈 주소가 0으로 출력되는 것을 확인할 수 있다.

리스트 3 PROCESS_CREATION_MITIGATION_POLICY_WIN32K_SYSTEM_CALL_DISABLE_ALWAYS_ON 정책 테스트 소스 코드 다운로드

int _tmain(int argc, _TCHAR* argv[])
{
    if(argc == 1)
    {
        STARTUPINFOEXW si = {0,};
        PROCESS_INFORMATION pi;
        WCHAR cmd[MAX_PATH];

        StringCbPrintfW(cmd, sizeof(cmd), L"\"%s\" dummy_args", argv[0]);

        UCHAR buffer[4096];
        LPPROC_THREAD_ATTRIBUTE_LIST attr = (LPPROC_THREAD_ATTRIBUTE_LIST) buffer;
        SIZE_T size = 0;
        if(!InitializeProcThreadAttributeList(NULL, 1, 0, &size))
        {
            if(GetLastError() != ERROR_INSUFFICIENT_BUFFER)
                return 0;
        }

        attr = (LPPROC_THREAD_ATTRIBUTE_LIST)  new UCHAR[size];
        if(!InitializeProcThreadAttributeList(attr, 1, 0, &size))
            return 0;

        ULONG policy 
        = PROCESS_CREATION_MITIGATION_POLICY_WIN32K_SYSTEM_CALL_DISABLE_ALWAYS_ON;
        if(!UpdateProcThreadAttribute(attr
                                        , 0
                                        , PROC_THREAD_ATTRIBUTE_MITIGATION_POLICY
                                        , &policy
                                        , sizeof(policy)
                                        , NULL
                                        , NULL))
        {
            DeleteProcThreadAttributeList(attr);
            return 0;
        }

        si.StartupInfo.cb = sizeof(si);
        si.lpAttributeList = attr;

        if(!CreateProcessW(NULL
                            , cmd
                            , NULL
                            , NULL
                            , FALSE
                            , EXTENDED_STARTUPINFO_PRESENT
                            , NULL
                            , NULL
                            , &si.StartupInfo
                            , &pi))
        {
            DeleteProcThreadAttributeList(attr);
            return 0;
        }

        WaitForSingleObject(pi.hProcess, INFINITE);
        DeleteProcThreadAttributeList(attr);
        return 0;
    }

    PROCESS_MITIGATION_SYSTEM_CALL_DISABLE_POLICY plc;
    if(GetProcessMitigationPolicy(GetCurrentProcess()
                                    , ProcessSystemCallDisablePolicy
                                    , &plc
                                    , sizeof(plc)))
    {
        printf("DisallowWin32kSystemCalls: %d\n"
                    , plc.DisallowWin32kSystemCalls);
    }

    printf("user32.dll => %p\n", LoadLibraryW(L"user32.dll"));
    getchar();

    return 0;
}

<리스트 3>의 코드에 MessageBoxW와 같은 win32 서브시스템을 사용하는 함수를 정적으로 호출하는 코드를 추가한 다음 프로그램을 다시 실행하면 <화면 6>에 나타난 것과 같이 정상적으로 응용 프로그램을 시작할 수 없다는 메시지가 출력되고 프로그램이 실행되지 않는다. 이는 해당 함수가 정적으로 바인딩 됐기 때문에 운영체제 로더가 user32.dll을 로드해야 하는데 그 또한 정상적으로 수행할 수 없기 때문이다.

화면 6 응용 프로그램 시작 실패 메시지

[cpp] 윈도우 찾기

Tue, 16 Jun 2015 23:59:15 GMT

HWND FindWindow(LPCTSTR lpClassName, LPCTSTR lpWindowName);

FindWindow 함수는 탑레벨 윈도우 중에서 원하는 윈도우를 찾는 기능을 한다. 탑레벨 윈도우란 desktop 윈도우를 부모로 갖는 윈도우를 말한다. 첫 번째 인자에는 찾고자 하는 윈도우의 클래스 이름을 넣어주면 된다. NULL을 지정할 경우에는 윈도우를 찾을 때 클래스 이름은 무시하고 찾는다. 두 번째 인자로 찾고자 하는 윈도우의 윈도우 이름을 넣어준다. 첫 번째 인자와 마찬가지로 NULL을 넣을 경우 이 항목은 무시된다. 윈도우의 핸들이 리턴 된다. 윈도우가 없다면 NULL이 리턴 된다. FindWindow(“#32770″, “TEST”)와 같이 사용할 경우 클래스 이름이 #32770이고 캡션이 TEST인 윈도우를 찾는다. FindWindow(“#32770″, NULL)과 같이 사용할 경우엔 캡션에 관계없이 클래스 이름이 #32770인 윈도우를 찾는다.

HWND FindWindowEx(HWND hwndParent
                  , HWND hwndChildAfter
                  , LPCTSTR lpszClass
                  , LPCTSTR lpszWindow);

FindWindowEx는 특정 윈도우의 자식 윈도우 중에서 원하는 윈도우를 찾아준다. 첫 번째 인자로 찾고자 하는 윈도우의 부모 핸들을 넣어준다. 만약 NULL을 넣게 되면 FindWindow와 마찬가지로 Top 윈도우를 찾는다. 두 번째 인자로 검색 시작이 될 자식 윈도우를 넣어준다. 일반적으로 윈도우는 많은 자식 윈도우를 가지고 있다. 그 중에서 특정 자식 윈도우 다음부터 검사하고 싶은 경우 이 인자를 사용하면 된다. NULL을 지정할 경우 처음부터 검사한다. 세 번째, 네 번째 인자는 FindWindow의 인자와 같은 의미를 가진다. 리턴 값도 FindWindow와 동일하다. 아래 코드는 위에서 찾은 다이알로그의 자식 중에 확인 버튼을 찾는 것을 보여준다.

HWND hwnd = FindWindow("32770", "TEST")
HWND button = FindWindowEx(hwnd, NULL, "BUTTON", "확인");

위의 두 함수 외에도 직접적으로 윈도우를 찾는 함수는 아니지만 도움이 되는 함수가 있다. GetNextWindow와 GetWindow가 그것이다.

HWND GetNextWindow(HWND hWnd, UINT wCmd);

GetNextWindow는 z-order 상에서 다음에 있는 윈도우나 이전에 있는 윈도우를 찾는 기능을 한다. 첫 번째 인자로 검색 대상이 될 윈도우를 넣어주면 된다. 두 번째 인자는 GW_HWNDNEXT나 GW_HWNDPREV중에 하나를 넣으면 된다. GW_HWNDNEXT를 넣을 경우 z-order 상에서 다음에 존재하는 윈도우를 리턴 하고, GW_HWNDPREV를 넣을 경우 z-order 상에서 이전에 존재하는 윈도우를 리턴 한다.

HWND GetWindow(HWND hWnd, UINT uCmd);

GetWindow는 대상 윈도우로부터 특정한 관계에 있는 윈도우를 찾는 기능을 한다. GetNextWindow의 일반화된 버전이라고 생각할 수 있다. 첫 번째 인자로는 대상이 되는 윈도우를 넣으면 된다. 두 번째 인자로는 다음 목록에 있는 것 중에 하나를 넣어주면 된다.

GW_CHILD
대상 윈도우의 자식 중에서 z-order가 가장 위에 있는 윈도우를 리턴 한다. 만약 대상 윈도우의 자식이 없다면 NULL을 리턴 한다.
GW_ENABLEDPOPUP
Windows 2000/XP이상에 적용되는 값이다. 대상 윈도우 다음윈도우 중에서 팝업 윈도우를 찾아서 리턴 한다. 팝업 윈도우가 없는 경우엔 NULL을 리턴 한다.
GW_HWNDFIRST
같은 계층의 윈도우 중에서 가장 높은 z-order를 가지는 윈도우를 리턴 한다. 만약 대상 윈도우가 Top 레벨 윈도우라면 Top 레벨 윈도우 중에서 가장 높은 z-order를 가지는 윈도우를 리턴 한다. 만약 대상 윈도우가 자식 윈도우라면 형제 윈도우 중에서 가장 높은 z-order를 가지는 윈도우를 리턴 한다.
GW_HWNDLAST
같은 계층의 윈도우 중에서 가장 낮은 z-order를 가지는 윈도우를 리턴 한다. 만약 대상 윈도우가 Top 레벨 윈도우라면 Top 레벨 윈도우 중에서 가장 낮은 z-order를 가지는 윈도우를 리턴 한다. 만약 대상 윈도우가 자식 윈도우라면 형제 윈도우 중에서 가장 낮은 z-order를 가지는 윈도우를 리턴 한다.
GW_HWNDNEXT
대상 윈도우의 다음 z-order를 가지는 윈도우를 리턴 한다. GetNextWindow의 두 번째 인자에 사용되는 의미와 동일하다.
GW_HWNDPREV
대상 윈도우의 이전 z-order를 가지는 윈도우를 리턴 한다. GetNextWindow의 두 번째 인자에 사용되는 의미와 동일하다.
GW_OWNER
대상 윈도우의 소유자 윈도우를 리턴 한다.

HWND GetDesktopWindow(VOID);

Desktop 윈도우를 구하는 함수다. 모든 Top 레벨 윈도우는 이 윈도우의 자식이다. 또한 Spy++에서 가장 위에 표시되는 윈도우 이기도 하다. 인자는 없고 리턴 값이 Desktop 윈도우 핸들이다.

HWND GetShellWindow(VOID);

Shell 윈도우를 구하는 함수다. Shell 윈도우는 작업 표시줄 윈도우를 말한다. 인자는 없고 리턴 값은 Shell 윈도우 핸들이다.

HWND GetForegroundWindow(VOID);

Foreground 윈도우 핸들을 구하는 함수다. Foreground 윈도우란 사용자와 상호 작용을 하고 있는 윈도우를 말한다. Windows가 멀티태스킹 시스템 이지만 사용자와 상호 작용을 하는 윈도우는 하나밖에 없다. 인자는 없고 리턴 값이 foreground 윈도우 핸들이다. Foreground 윈도우가 없는 경우 NULL을 리턴 한다.

HWND GetParent(HWND hWnd);

부모 윈도우를 구해주는 함수다. 인자로 대상 윈도우 핸들을 넣어주면 부모 윈도우 핸들을 리턴 한다. 만약 대상 윈도우가 top 레벨 윈도우 이거나 함수 수행에 실패한 경우 NULL을 리턴 한다.

HWND GetTopWindow(HWND hWnd);

첫 번째 자식 윈도우(자식 윈도우 중에서 z-order가 가장 높은 것)를 구하는 함수다. 인자로 윈도우 핸들을 넣어주면 첫 번째 자식 윈도우를 리턴 한다. 자식이 없거나 동작이 실패한 경우 NULL을 리턴 한다.

HWND GetAncestor(HWND hwnd, UINT gaFlags);

조상 윈도우를 구하는 함수다. 첫 번째 인자로 윈도우 핸들을, 두 번째 인자로 다음 목록에 있는 값 중에 하나를 넣어주면 된다. 리턴 값은 첫 번째 인자로 전달된 윈도우에 대한 조상 윈도우 핸들이다. 전달된 윈도우가 탑 레벨 윈도우일 경우 NULL이 리턴 된다.

GA_PARENT

부모 윈도우를 리턴 한다.

GA_ROOT

최 상단 부모 윈도우를 리턴 한다.

GA_ROOTOWNER

최 상단 부모 윈도우를 소유한 윈도우를 리턴 한다.

끝으로 앞서 배운 함수를 통해서 특정 윈도우의 하위에 존재하는 모든 윈도우를 열거하는 방법을 알아보자. GetWindow 함수와 재귀 호출 함수를 사용하면 손쉽게 구현할 수 있다. 아래 이렇게 구현해 본 ScrabWindow 함수가 있으니 참고해 보도록 하자.

모든 자식 윈도우를 수집하는 ScrabWindow 함수 소스 코드 다운로드

typedef BOOL (CALLBACK *ScrabWindowCallback)(HWND hwnd);

BOOL
ScrabWindow(HWND hwnd, ScrabWindowCallback cb)
{

	try
	{
		if(!cb(hwnd))
			return FALSE;
	}
	catch(...)
	{
		return FALSE;
	}

	HWND c = GetWindow(hwnd, GW_CHILD);
	if(!c)
		return TRUE;

	for( ; c; c = GetWindow(c, GW_HWNDNEXT))
	{
		if(!ScrabWindow(c, cb))
			return FALSE;
	}

	return TRUE;
}

BOOL
CALLBACK
PrintWindow(HWND hwnd)
{
	printf("%08x\n", hwnd);
	return TRUE;
}

int main()
{
	ScrabWindow(GetDesktopWindow(), PrintWindow);

    return 0;
}

[cpp] 초간단 암호화, 2001

Tue, 16 Jun 2015 23:59:14 GMT

자신의 데이터에 어떤 기준으로 락을 걸고 싶을때가 있습니다. 하지만 막상 금방 코드를 작성하려면 방법이 잘 떠오르지 않는것이 이런 암호와 관련된 것들이죠. 몇가지 간단한 방법들을 여기서 소개해 드리도록 하겠습니다. 실질적으로 높은 수준의 보안을 유지할 수는 없는 방법들입니다. 간단하고 이해하기 쉬우며 암호의 원리를 알아보도록 하죠.

암호는 기본적으로 상대방과 나와의 약속입니다. “내가 이렇게 원래 데이터를 바꿀테니 너는 이러이러케해서 원본데이터를 봐라”라고 하는 것들이 암호의 핵심입니다. 그런데 요즘 비번같은 암호의 경우는 비복원 방식을 사용하는 경우가 대부분입니다. 비복원이라는 말은 데이터가 암호와만 되고 역으로 추출해 내기는 힘들다는 이야기 입니다. 즉 abc가 zdsalkfj223으로 바뀌었을때, 이 바뀐 zds…이 abc로 돌아올 수는 없다는 이야기입니다. 반대로 복원 가능한 암호는 암호화 된 데이터로부터 원본 데이터를 그대로 복원해 낼 수 있습니다.

가장 간단한 암호와 기법으로는 고전적인 방식의 시저 암호가 있습니다. 즉 데이터를 상대방과 약속을 하고 일정한 수를 가감하거나 가산하는 방식을 말합니다. a=>b가 되면, c=>d가 되는 식입니다.. 코드의 구현은 아주 간단하겠죠.

#define SEED 2 

void Encrypt(char *data) 
{ 
    for(; *data; ++data) 
       *data += SEED; 
} 

void Decrypt(char *data) 
{ 
    for(; *data; ++data) 
       *data -= SEED; 
}

다음으로는 더욱 간단한 방법으로 암호라고 하기는 힘들지만 데이터를 반전시키는 방법을 사용할 수 있습니다. 이런 경우의 암호는 주로 텍스트 파일 등을 에디터로 봐서는 보기 힘들게 하는 정도의 보안 수준에 사용하면 좋겠죠. 암호화와 복원이 한 함수로 이루어 집니다.

void EncDecrypt(char *data) 
{ 
    for(; *data; ++data) 
       *data = ~(*data); 
}

끝으로는 사용자가 지정한 패스워드에 기반한 암호 알고리즘입니다. 소스 설명은 생략하도록 하겠습니다. 간단해서 보시면 금방 아! 하실수 있을것 같네염. 위 홤수와 마찬가지로 암호화와 복원이 한 함수로 이루어 지며, pwd에는 비번을 입력해 주시면 됩니다.

void EncDecrypt(char *data, char *pwd) 
{ 
   int i, size; 
   // 아래 맵은 256개의 문자로 초기화 시켜 주시면 됩니다... 
   char map[256] = "acvkjasewr23478cxvlkjdflk2349ds8fxcv,masfkjer234"; 

   size = strlen(pwd) - 1; 
   for(i=0; i<256; ++i) 
   { 
       map[i] = pwd[i % size] & map[i]; 
   } 

   for( ; *data; ++data) 
      *data ^= map[*data]; 
}

일반적으로 실질적인 보안을 생각한다면 위와 같이 직접 만든 암호화 알고리즘을 사용하는 것은 좋지 않습니다. 수학적으로 검증된 기존 알고리즘을 사용하는 것이 안전합니다. 하지만 기존 암호화 알고리즘을 공부하고 또 그것을 코드로 직접 구현하는 일이 그리 쉽진 않지요. 그럴때에는 기존에 만들어둔 라이브러리를 사용하면 손쉽게 암호화, 복호화를 하실 수 있습니다. 아래는 윈도우에 포함된 암호화 API를 사용해서 RC4 알고리즘을 이용해서 암, 복호화를 수행하는 코드를 보여주고 있습니다.

RC4 암호화 함수 소스 코드 다운로드

//////////////////////////////////////////////////////////////////////////
//
//! RC4를 사용한 암호화 함수
//! \param pbKey 는 암호화 하는데 사용되는 키 버퍼
//! \param dwKeySize 는 암호화 하는데 사용되는 키 버퍼의 크기
//! \param pbPlaintText 는 암호화 하는데 사용되는 원문
//! \param pbCipherText 는 암호화 된 문장이 저장될 버퍼(원문의 크기 이상이어야 함)
//! \param dwHowMuch 는 암호화 하는데 사용되는 원문의 크기
//! \return GetLastError의 반환값, 성공한 경우 0 리턴
//! \remark 모든 버퍼는 문자열이 아닌 바이트 스트림으로 간주해야 함.

DWORD Encrypt(UCHAR *pbKey, 
              DWORD dwKeySize, 
              UCHAR *pbPlaintext, 
              UCHAR *pbCipherText, 
              DWORD dwHowMuch)
{
    HCRYPTPROV  hProv = NULL;
    HCRYPTKEY   hKey = NULL;
    HCRYPTHASH  hHash = NULL;

    DWORD       dwBuff = dwHowMuch;

    BOOL        dwRet = 0;
    
    memcpy(pbCipherText, pbPlaintext, dwHowMuch);

    try
    {
        if(CryptAcquireContext( &hProv, 
                                NULL, 
                                NULL, 
                                PROV_RSA_FULL, 
                                CRYPT_VERIFYCONTEXT) == FALSE)
            throw GetLastError();

        if(CryptCreateHash(hProv, CALG_MD5, 0, 0, &hHash) == FALSE)
            throw GetLastError();

        if(CryptHashData(hHash, pbKey, dwKeySize, 0) == FALSE)
            throw GetLastError();

        if(CryptDeriveKey(hProv, CALG_RC4, hHash, CRYPT_EXPORTABLE, &hKey) == FALSE)
            throw GetLastError();

        if(CryptEncrypt(hKey, 0, TRUE, 0, pbCipherText, &dwBuff, dwHowMuch) == FALSE)
            throw GetLastError();
    }
    catch(const DWORD dwLastError)
    {
        dwRet = dwLastError;
    }
    
    if(hKey)
        CryptDestroyKey(hKey);

    if(hHash)
        CryptDestroyHash(hHash);

    if(hProv)
        CryptReleaseContext(hProv, 0);

    return dwRet;
}

RC4 복호화 함수

//////////////////////////////////////////////////////////////////////////
//
//! RC4를 사용한 복호화 함수
//! \param pbKey 는 암호화 하는데 사용되는 키 버퍼
//! \param dwKeySize 는 암호화 하는데 사용되는 키 버퍼의 크기
//! \param pbCipherText 는 암호화된 버퍼
//! \param pbPlaintText 는 암호가 해독된 원문(암호화된 버퍼 크기 이상이어야 함)
//! \param dwHowMuch 는 암호화된 버퍼 크기
//! \return GetLastError의 반환값, 성공한 경우 0 리턴
//! \remark 모든 버퍼는 문자열이 아닌 바이트 스트림으로 간주해야 함.

DWORD Decrypt(UCHAR *pbKey, 
              DWORD dwKeySize, 
              UCHAR *pbCipherText, 
              UCHAR *pbPlaintext, 
              DWORD dwHowMuch)
{
    HCRYPTPROV  hProv = NULL;
    HCRYPTKEY   hKey = NULL;
    HCRYPTHASH  hHash = NULL;
    
    DWORD       dwBuff = dwHowMuch;
    DWORD       dwRet = 0;
    
    memcpy(pbPlaintext, pbCipherText, dwHowMuch);
    
    try
    {
        if(CryptAcquireContext(&hProv, 
                               NULL, 
                               NULL, 
                               PROV_RSA_FULL, 
                               CRYPT_VERIFYCONTEXT) == FALSE)
            throw GetLastError();
        
        if(CryptCreateHash(hProv, CALG_MD5, 0, 0, &hHash) == FALSE)
            throw GetLastError();
        
        if(CryptHashData(hHash, pbKey, dwKeySize, 0) == FALSE)
            throw GetLastError();
        
        if(CryptDeriveKey(hProv, CALG_RC4, hHash, CRYPT_EXPORTABLE, &hKey) == FALSE)
            throw GetLastError();
        
        if(CryptDecrypt(hKey, 0, TRUE, 0, pbPlaintext, &dwBuff) == FALSE)
            throw GetLastError();
    }
    catch(const DWORD dwLastError)
    {
        dwRet = dwLastError;
    }

    if(hKey)
        CryptDestroyKey(hKey);
    
    if(hHash)
        CryptDestroyHash(hHash);
    
    if(hProv)
        CryptReleaseContext(hProv, 0);

    return dwRet;
}

RC4를 이용한 암, 복호화 테스트 코드

//////////////////////////////////////////////////////////////////////////
//
//! 바이트 버퍼를 헥사값으로 출력하는 함수
//! \param pbText 는 출력될 바이트 버퍼
//! \param dwLength 는 출력될 바이트 버퍼 크기
//! \return 은 없음
//! \remark 이 함수는 출력을 완료한 후 개행함

void PrintByte(UCHAR *pbText, DWORD dwLength)
{
    DWORD   i;
    CHAR    *szHexaMap = "0123456789ABCDEF";
    
    for(i = 0; i < dwLength; ++i)
	{
        putchar(szHexaMap[pbText[i] & 0x0f]);
		putchar(szHexaMap[pbText[i] >> 4]);
        putchar(' ');
    }
    
    putchar('\n');
}

int main(int argc, char* argv[])
{
    UCHAR   szPlainText[] = "Hello World!";
    UCHAR   szChipherText[MAX_PATH];
    UCHAR   szDecryptText[MAX_PATH];
    UCHAR   szKey[] = "pohang";

    DWORD   dwBuffSize = sizeof szPlainText;
    DWORD   dwKeySize = sizeof szKey;

    PrintByte(szPlainText, dwBuffSize);
    Encrypt(szKey, dwKeySize, szPlainText, szChipherText, dwBuffSize);
    PrintByte(szChipherText, dwBuffSize);
    Decrypt(szKey, dwKeySize, szChipherText, szDecryptText, dwBuffSize);
    PrintByte(szDecryptText, dwBuffSize);
    return 0;
}

[소고] 극과 극은 통한다: 위대한 기업과 블랙 회사는 어쩌면 같은 건지도…

Fri, 22 May 2015 23:59:13 GMT

작년인지 제작년인지 알리바바가 미국 증시에 상장을 했다. 시총은 아마존을 제꼈고, 알리바바 회장인 마윈은 세계에서 손꼽히는 거부가 되었다. 걸출한 성공을 거둔 잭 마, 자본주의 사회답게 거대한 부를 축적한 그를 동경하는 눈들이 많다. 매스컴에서는 그에 관한 다큐를 제작해서 방영하기도 했다. 얼마전 페북에서는 그의 명함을 받았다고 자랑스럽게 공개하는 사람도 있었다. 그 명함 한 장이 무엇이라고… 여튼 이쯤하면 기업가치고는 스타덤에 올랐다고 할 수 있겠다.

그런 그의 위대함을 조금이나 배우고자 그에 관한 다큐를 꼼꼼히 살폈다. 그러다 다소 놀라운 장면을 목격하게 되었는데 다름아닌 아래 동영상이었다. 아래 영상은 알리바바 초창기인 1999년에 마윈이 직원들에게 이야기하는 것을 녹화한 화면이다. 첫째는 뭐 나름 비전 제시라고 할 수 있겠다. 하지만 두 번째 부분에서는 정말 뿜찌 않을 수 없었다. 어떻게 저런 이야기를 얼굴 표정 하나 변하지 않고 저리도 진지하게 이야기 할 수 있을까?

second, we need to learn the hard working spirit of Sillicon Valley. If we go to work at 8am and go home at 5pm, this is not a high tech company and Alibaba will never be successful. If we have that kind of 8am-to-5pm spirit, then we should just go and do something else.

둘째, 우리는 실리콘 밸리의 워크홀릭 정신을 배울 필요가 있습니다. 만약 우리가 8시에 출근해서 5시에 퇴근한다면, 그건 높은 기술력을 가진 회사라 할 수 없습니다. 그리고 알리바바는 결코 성공하지 못할 겁니다. 만약 우리가 8시 출근, 5시 퇴근 따위의 정신을 가지고 있다면 그만두고 다른 일을 하는 것이 옳을 겁니다.

위대한 기업과 블랙 회사, 사기꾼과 위대한 기업가는 같은 건지도 모른다. 진실과 거짓의 차이는 누가 더 뻔뻔하냐와 덜 뻔뻔하냐 정도의 차이밖에, 위대한 기업가와 사기꾼은 성공했냐 실패했냐 정도의 차이밖에는 없는게 아닐까라는 위험한 생각이 머릿속을 뱅뱅 헤집고 다닌다. 정말 요지경속이다.

실리콘밸리도 도찐개찐, 마윈 회장이 잘 배운 건지도 ㅋㅋ~

[cpp] 윈도우 10 버전 구하기

Thu, 23 Apr 2015 23:59:12 GMT

윈도우 XP 시점인가를 기점으로 VerifyVersionInfo라는 함수가 생겼다. 등록 정보에서 호환성 모드를 설정한 경우에 GetVersion/GetVerionEx 함수가 페이크 값을 리턴하면서 원본 값을 구하기 위해서 생긴 함수였다. 근데 이게 윈도우 10 되면서 또 무용지물이 되었다.

윈도우 10부터 매니페스트에 윈도우 10을 타겟으로 컴파일되지 않은 바이너리는 GetVersion/GetVersionEx/VerifyVersionInfo 모두 페이크 값을 전달하도록 변경됐기 때문이다. 이뭐병 ㅠㅜ~

Applications not manifested for Windows 8.1 or Windows 10 Technical Preview will return the Windows 8 OS version value (6.2). Once an application is manifested for a given operating system version, GetVersionEx will always return the version that the application is manifested for in future releases. To manifest your applications for Windows 8.1 or Windows 10 Technical Preview, refer to Targeting your application for Windows.

– https://msdn.microsoft.com/en-us/library/windows/desktop/ms724451(v=vs.85).aspx

원본 값을 구하고 싶은 경우에는 VersionHelpers.h에 포함된 IsWindows10OrGreater 함수를 사용하면 된다. 결국은 RtlGetVersion 이라는 함수를 사용해서 버전을 구하는 꼼수를 보여주고 있다. 이 무슨 병신같은 시츄에이션인지 ㅠㅜ~

[시스템] 슬랙 윈도 네이티브 애플리케이션 폰트 변경하기

Thu, 26 Mar 2015 23:59:11 GMT

그간 윈도 환경에서 슬랙은 네이티브 앱이 없고 크롬 확장으로 사용해야 해서 다소 불편함이 있었습니다. 그런 불편함을 알았는지 드디어 슬랙에서 윈도 네이티브 프로그램을 절찬리 배포하기 시작했습니다. 반가운 마음에 깔아보았는데 시작부터 이건 비주얼에 큰 실망을 안겨주는 군요 ㅠㅜ~ 안타깝게도 폰트 설정을 찾아보았으나 쉽게 찾을 수가 없었습니다.

폰트 이건 아니잖아~

혹시나 방법이 있나 싶어서 구글신에게 물어보았더니 친절한 일본 블로그에서 해결 방법을 찾을 수 있었습니다. 아래 방법대로 하면 폰트를 변경하실 수 있습니다.

node-js깔고 아래 명령어를 치면 app.extract 디렉터리에 소스 코드가 풀립니다.

npm install -g asar
cd %LOCALAPPDATA%/slack/app-1.0.0/resources
asar e app.asar app.extract

압축 풀린 디렉터리에 가서 “/src/ssb/app.js” 파일을 열어 보면 아래와 같은 부분이 있습니다. ko-KR이 아니라 ja-JP로 되어 있습니다. 그 부분을 아래와 같이 고쳐주면 됩니다. MS PGothic 찾아서 죄다 앞에다 원하는 폰트를 적어주면 됩니다. 저는 Malgun Gothic으로 설정했습니다.

if (layouts.indexOf("ko-KR") < 0) {
  return;
} // Figure out what the default font family for messages currently is

var fontFamily = cssom.fontFamily.replace("'Lato'", "Lato")
                       .replace("Lato,", "Lato, Malgun Gothic, MS PGothic,");

수정 다 했으면 "asar p app.extract app.asar" 명령어를 입력해서 파일을 다시 패키징해주면 됩니다. 그리고 슬랙을 껐다 키면 아름답고 미려한 폰트를 구경하실 수 있습니다.

바로 이거죠~

[일상] 좋은 날

Fri, 13 Feb 2015 23:59:10 GMT

#0

2014. 12. 19. FRI, 회사 창업하고 처음으로 직원들에게 인센티브가 지급됐다. 만으로 꼭 8년 하고도 3개월 정도가 된 시점. 생각보다 오래 걸렸고, 생각보다 오래 걸렸다. 26살에 처음 창업 대열에 끼어들던 나는 한 3년 하면 성공할 줄 알았었다. 지금 대표를 하고 있는 형은 처음 대표로 취임하던 날 2년만 해보자는 이야기를 했었다. 우리는 너무 어렸고, 너무 쉽게 생각했다. 그래서 그런지 예측은 다 빗나갔다. 3년이 지났을 땐 5년 정도 하면 성공할 줄 알았다. 5년이 지났을 땐 더 이상 날짜를 기약하지 않게 되었다. 나이도 들었고, 목표 보다는 과정을 보는 눈도 생겼기 때문이다. 어쨌든 그런 희망고문 같은 판타지가 우리를 버티게 해주었는지도 모를 일이다. 우리는 매일같이 쪽팔리지 말자, 좋은 날이 올거야, 라는 말을 주문처럼 외우면서 살았다.

인센티브가 지급되던 장면은 나에겐 약간 아이러니하게 느껴졌다. 왜냐하면 그 자리에서 인센티브를 받고 기분 좋아하는 직원들이 아닌 그 자리에 있었어야 할, 하지만 있지 못하는 사람들이 떠올랐기 때문이다. 짧은 의식같은 행사가 끝났을 무렵 내 머릿속에 가장 먼저 떠오른 것은 안나 카레니나의 첫 문장이었다. 왠지 이 문장이 지금의 모든 분위기를 대변하는 것 같다는 느낌이 들어서였다.

All happy families are alike; each unhappy family is unhappy in its own way.

행복한 가정은 서로 닮았지만, 불행한 가정은 모두 저마다의 이유로 불행하다.

– 안나 카레니나, 톨스토이

#1

회사를 하면서 내가 기억하는 핵심 장면들이 몇 있다. 첫 번째 장면은 2007년 초, 우리가 처음 게임 보안 제품을 만들기로 한 날이었다. 모 게임사에서 펀딩을 해서 시작하게 된 사업이었는데 지금도 별볼일 없는 우리를 믿고 투자해준 그 회사가 신기할 따름이다. 나는 이 일을 우리 회사에 있어서 가장 큰 빅딜이었다고 생각하는 편이다. 지금 대표인 형이 그 계약을 성사시켰는데, 그 공로를 인정 받아(?!) 이듬해 우리 회사의 두 번째 대표가 되었다.

두 번째 장면은 2008년 중순, 우리가 만든 제품으로 처음 매출을 올린 날이었다. 지금 생각해보면 참 조촐한 첫 매출이었지만 통장에 외화가 꽃혔다는 이유로 우리는 즐거워하며 회식을 했었다.

세 번째 장면에 오늘을 포함시키기로 했다. 얼마가 됐든 약속한 것보다 조금이라도 더 줄 수 있다는 게 쉬운 일이기도 하고, 어려운 일이기도 하다. 그러나 어쨌든 그런 일이 처음이기도 하고 회사가 여기까지 잘 도착했다는 사실이 대견하기도 한 것 같아 포함시키기로 했다.

#2

이상하게도 이 좋은 날 옛날 생각이 많이 떠올랐다. 제품 소개차 나간 미팅 자리에서 제품이 엣지 없다는 소리를 들었던 날도 있었고, 제품은 좋은데 검증이 안 된 것 같다며 레퍼런스를 확보하고 오라는 이야기를 들었던 날도 많았다. 회사가 망하면 어쩌냐는 소리를 들었던 수많은 자리가 있었고, 세번씩이나 똑같은 업체에 미팅을 하고는 돌아오는 차 안에 난데없이 거미가 나타난 적도 있었다. 더 어처구니없게도 우린 그걸 보며 이게 아침 거미인지 밤 거미인지 하면서 미신을 뒤적거리며 그 업체와 계약이 될지 안 될지를 점치기도 했었다. 정말 좋은 기회라고 싱글벙글하면서 나간 미팅 자리가 우리를 음해하는 세력이 꾸민 장례식 자리가 됐었던 어처구니 없는 상황도 있었다. 참 많은 일들이 있었다.

향수에 젖어서는 예전 일기장을 뒤적거려 보았다. 난 특이하게도 힘들면 일기를 쓰는 습관이 있는데, 회사를 하면서는 2010년, 2011년 일기가 많다. 회사를 하고 제법 시간이 흐르기도 한데다 그 당시에는 마치 모든 일이 멈춰버린 것 같은 상황들이 많았기 때문이었다. 꿈틀거릴수록 뭔가 점점 더 나빠지는 느낌들이 나를 엄습했던 시기이기도 했다. 어쨌든 그래서 그 당시에는 제법 부지런히 일기를 썼었다. 다시 살펴보니 회사도 나도 귀엽기도 하고 깜찍하기도 하고 그렇다.

2010. 01. 27. WED

그날 밤을 새며 M과 둘이서 HACK.DLL을 분석했지만 답을 찾지 못했다. 사실 분석에 있어서는 우리 둘 다 초보였다. 우리는 Themida로 패킹된 프로그램을 디버깅 하는 방법도 Yoda Crypter로 패킹된 DLL을 언팩하는 방법도 몰랐다. 닥치고 초보였던 것이다. 그러면서 사내에 이런 교육이 절실하다는 사실을 깨닫게 되었다. 게임 보안 제품을 만드는 회사에서 해킹툴 DLL을 분석할 수 있는 사람 한 명 없다니, 이 얼마나 아니러니 한 사실인가? 좀 쪽 팔리는 사실이기도 했다.

2010. 01. 28. THU

저녁에는 K가 첫 월급 턱이라고 밥을 샀다. 개발팀, QA팀 합해서 7명이 가서 순두부를 먹었다. 3명이었던 팀원이 갑자기 이렇게 늘어나니 관리가 통 안된다는 생각이 들었다. 물론 이제는 회식을 한 번 하기에도 부담스러운 인원이 된 것은 두말할 필요도 없다. 팀이 점점 나의 손을 떠나는 느낌이 많이 든다.

요즘은 회사의 느낌이 죽 끓이는 것 같다는 생각을 많이 한다. 마치 사인 곡선처럼 좋았다, 나빴다를 반복하는 것이다. 어쩌면 나 스스로 점점 더 자신감을 잃어가는 과정은 아닌지 모르겠다.

2010. 01. 30. SAT

거의 밤을 새우다 싶이 하고는 오후 2시에 퇴근을 했다. H도 밤샘 작업이 있다고 그때 마친다고 했기 때문이었다. 결국 HACK.DLL 분석 작업 마무리를 못했다. 월요일에 T에게 헬프 메일을 보내야겠다. 찜찜한 기분으로 집으로 왔다.

엉망진창인 집. 내 생활의 한 조각, 아니 전부를 보여주는듯 했다. 내 방은 엉망진창이고, 그건 내 생활 또한 엉망진창이라는 것을 나타내기 때문이다. 일주일을 돌아본다. 내가 이 방에서 한 일이라곤 쓰러져 몇 시간 잠을 자고 씻고 출근하는 것이 전부였다. 온통 양말과 수건으로 널부러진 방을 보기만 해도 머리가 아팠다. 정리가 필요했다. 이 방에도, 내 삶에도…

2010. 02. 21. SUN

느즈막히 출근을 했다. 어제 작업하던 V 모듈 마무리 작업이 있었다. CDN에서 N 코드를 다운로드 받아서 실행하는 부분을 추가할 계획이었다. 작업을 하려고 PC를 켜고 Visual Studio를 정리했다. 그러고는 늘상 하듯이 브라우저를 켜고 모니터링 사이트를 방문해 보고는 했다. 그러다 엄청난 사실을 알게 되었다. XIGNCODE로 영문 위키 페이지가 생성되어 있는 것이었다. 물론 내용은 안습이었다. 최악의 보안 프로그램이다. 막는게 하나도 없다와 같은 이야기였다. 조금 충격적이었다. 사실 많이 충격적이었다. 나중에 다시 보니 페이지는 지워지고 없었다.

최고의 보안 제품을 만들겠다는 일념으로 3년을 넘게 달려왔다. 그런데 ‘worst anti cheat’라는 수식어라니. 자존심이 좀 상하기도 하고, 좀 얼떨떨 하기도 하고 그랬다. 한동안은 코딩도 못했다. 이내 마음을 다잡았다. 아직 갈 길이 많이 남았다는 생각을 했다. 그래도 유저들이 우리 제품을 인식하고 있다는 긍정적인 신호로 받아들이기로 했다.

2010. 02. 23. TUE

엄청난 하루였다. 어제 수정한 V 모듈이 오늘 패치된 것이다. 패치는 정말 감동 그 자체였다. 커뮤니티에는 핵이 완전히 사라졌다고 좋아하는 글들이 올라왔고 핵의 숙주인 DG에는 빨간불이 들어왔다. N 코드는 의외로 별 문제 없이 잘 동작했다. 그런데 문제는 V 모듈에 있었다. 새롭게 추가한 DirectX 훅 체크 코드의 if문이 엉뚱하게 붙어 있었던 것이다. else if가 되어야 하는데 독립 if문으로 해버린 사소한 실수였다. 그 덕분에 게임 스트리밍 서비스를 사용하는 많은 정상 유저가 끊기는 일이 발생했다. 코드를 고치는 것은 간단했지만 실제 업데이트에 적용 되러면 얼마간 시간이 걸릴 것으로 보인다. 다시한번 실시간 업데이트의 필요성을 절감했다.

![](./x3beta4.png) **가장 힘들었던 그해 6월, 우리의 세번째 판올림 XIGNCODE3 베타 버전이 나왔다.**

근 2년간 700번의 새로운 엔진 빌드. 우리는 거의 매일 새로워졌다.

그리고 우리가 얻은 것: ‘worst anti cheat’에서 조금은 자부심을 가질 만한 평가들

세상에 훨씬 더 좋고 훨씬 더 대단한 회사들이 많이 있다. 대단하지 않은 작은 성취지만 기분 좋은 마음에 몇 자 끄적여 봤다. 왜냐하면 난 용뼈를 먹고도 뛸듯이 좋아했던 사람이니까… 거기에 비하면 이건 훨씬 더 대단한 일 아닐까낭?!…

![](./wow.png) **이 별거도 아닌 아이템 하나 먹고 난 세상을 다 가진 줄 알았었다.**

와우에 적용될 그 날을 기다리며…