RSS Feed of it from bit.

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

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) 죽기 직전에야 양육권을 다시 조안나에게 돌려주는 문서에 서명한다.

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

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

Sat, 04 Oct 2025 11:00:01 GMT

KOF98을 플레이하는 아드님

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

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

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

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

[일상] 메멘토 모리를 되새기며 (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

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

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

[소고] 인공지능이 생산성 향상으로 이어지지 않는 이유 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

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

[잡기] 조선의 과거 시험 경쟁률은?! (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살의 나이게 과거에 처음 급제했다는 걸 보면 유만주는 너무 일찍 요절한 건 아닌가라는 생각이 든다. 그럼에도 그의 책을 보면 그가 더 살았더라도 아마 과거에 급제하지는 못했을 거란 생각도 든다. 왜냐하면 그 또한 묘하게 반골 기질이 있기 때문이다. 시험을 위한 시험, 공부를 위한 공부가 무슨 의미가 있냐는 한탄을 그의 글 곳곳에서 발견할 수 있다. 실질적으로 그는 과거 시험을 위한 공부 자체에는 별 흥미가 없었을 수 있다.

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

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 호출 다음 라인부터 실행을 계속합니다.

결론:

WndProc 자체는 단일 스레드에서 순차적으로 실행되지만, MessageBox, DialogBox 등 모달(Modal) 상태를 만들고 내부적으로 메시지 루프를 돌리는 함수를 호출하면, 해당 함수가 반환하기 전에도 같은 스레드에서 다른 메시지가 처리되어 WndProc가 재진입(re-entrant) 또는 중첩 호출(nested call)될 수 있습니다. 이는 Windows GUI 프로그래밍에서 매우 흔하며 중요한 개념입니다.

[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주면 다 바닥났기 때문이다. 물론 결제를 더하면 더 늘릴 수 있겠지만 코파일럿이 너무 빨리 따라왔다.

[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++에서 더 안전하고 간결하게 동적 배열을 관리할 수 있습니다.

[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 등)를 사용하는 것이 바람직합니다.
이를 통해 리소스 관리가 예측 가능하고, 코드가 더 견고해집니다.

[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이 대체할 거라 생각한다.

[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!

여기서는, 보시다시피, 같은 자리에 있기 위해 할 수 있는 모든 힘을 다해 달려야 해요.
만약 다른 곳으로 가고 싶다면, 최소한 그보다 두 배는 더 빨리 달려야 해요!

-- 거울 나라의 앨리스

[cs] .net 4.0 레퍼런스 어셈블리 수동으로 설치하기

Thu, 11 Jul 2024 19:35:00 GMT

.net 4.0으로 타겟팅된 프로젝트를 빌드할 때 레퍼런스 어셈블리가 없어서 빌드를 못하는 경우가 있다. 지원이 안되는 버전이라 그런지 공식 설치 파일도 없다. 그런 경우에는 수동으로 설치하면 된다.

아래 페이지에서 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일의 길로 가기엔 부가가치 창출이 너무나 안되는 게 현실이다. 결국 대표님들도 힘들긴 마찬가지. 마치 이건 닭이 먼저냐? 달걀이 먼저냐? 같은 문제가 아닐까 싶다.

[시스템] 윈도우 서버에 도커 설치하기

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

[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]}%`;
    });
  });
});

[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

나는 더는 스타크래프트를 즐기지 않고, 와우를 미친 듯이 하지 않는다. 킹 오브 파이터즈를 하러 오락실을 찾지도 않고, 무한도전이나 러닝맨 같은 예능을 즐겨 보지도 않는다. 일요일 밤을 마감하는 웃찾사나 개그콘서트같은 개그 프로를 안 본지도 오래됐다. 과자를 자주 먹지도 않는다.

긴 세월 만큼이나 나란 사람도 정말 많이 변했다. 하지만 그렇게 많은 세월이 지났어도 나는 여전히 여기에 글을 쓴다. 어쩌면 이게 내가 코딩을 제외하고 본질적으로 거의 유일하게 좋아하는 일인지도 모르겠다는 생각이 들었다.

주춤했던 최근을 넘어서 앞으로는 그래도 종종 글을 남기겠다는 다짐을 해본다.

[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. 클라크

[소고] 내가 오늘 교통사고를 당할 확률은?

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) **이 별거도 아닌 아이템 하나 먹고 난 세상을 다 가진 줄 알았었다.**

와우에 적용될 그 날을 기다리며…

[소고] 방어적 프로그래밍

Thu, 12 Feb 2015 23:59:09 GMT

HRESULT SomeFunc(...)
{
	// ...

	SIZE_T written;

	std::vector<xch> buffer;
	buffer.resize(MAX_BODY_CONTENT);

	HRESULT hr = dn->ToBuffer((PVOID) &buffer[0], buffer.size(), &written);
	if(!SUCCEEDED(hr))
		return hr;

	buffer[written] = '\0';

	// ...
}

위와 같은 코드를 줬더니 그대로 사용해서 “buffer[written] = ‘\0′;” 구문에서 written이 MAX_BODY_CONTENT보다 크면 어쩌냐는 이야기를 했다. 그랬더니 dn->ToBuffer 함수가 실패한 경우에도 written에 값이 저장되냐는 둥, 소스가 더 커도 실제 크기가 written에 넘어오냐는 등의 질문을 한다.

dn->ToBuffer 함수가 어찌 동작하든 간에 if문 하나만 추가하면 안전해지는 문제 아니냐는 말을 했더니 기어코 소스 코드를 찾아내서는 그렇게 반환하는 경우는 없는것 같다고 궁시렁거리는 신입 프로그래머의 패기. dn->ToBuffer 함수가 내일 동작이 바뀌어서 그런 값을 반환하면 어쩔거냐고 했더니 그제서야 if문을 추가한다.

다른 함수에 불필요한 가정을 추가하지 말자. 불필요한 가정이 필요하다면 그 가정이 사실인지 반드시 확인하자 (ASSERT가 됐든 if가 됐든). 그리고 다른 함수가 정상 동작할 거라는 일말의 기대도 하지 말자.

돈을 받고 갈켜줘도 시원찮을 판에 월급 주며 갈켜주는데도 엉뚱 소리를 하니 속에 천불이 ㅠㅜ~

참 갑갑한 현실…

안개가 짙은 길을 주행할 땐 일단 서행하렴. 눈 앞에 갑자기 차가 나타날 수 있단다.

운전이나 코딩이나 방어가 중요하다는 거…

[cpp] 함수 디자인

Wed, 11 Feb 2015 23:59:08 GMT

회사의 신입 개발자가 아래와 같은 함수를 만들었다. URL의 페이지를 긁어 오는 함수다. url에는 긁어올 웹 페이지 주소를 지정해서 함수를 호출하면 해당 웹 페이지를 긁어오는데 성공하면 check에 TRUE가 반환되고 string에는 페이지 내용이, 실패한 경우에는 check에 FALSE가 반환되고, string은 빈 문자열이 넘어온다.

std::string GetPage(WCHAR *url, BOOL *check);

이 디자인의 칭찬할 점은 함수의 리턴 값을 중의적인 내용으로 사용하지 않았다는 점에 있다. 리턴 문자열이 빈 문자열(“”)이면 오류라고 식별하는 것처럼 디자인해서 리턴 값에 성공/실패의 의미와 페이지 내용을 같이 담지는 않았다는 의미다.

하지만 둘 중에 어떤 것을 리턴 값으로 선택하는지에 대해서는 생각이 조금 짧았다. 왜냐하면 함수 내용을 살펴보면 check는 함수의 수행 지점에 상관 없이 항상 덮어쓰기가 일어나지만 리턴 문자열은 성공한 경우에만 덮어쓰면 되기 때문이다. 이런 점을 생각했다면 check를 리턴 값으로 삼는 것이 좋았을 것이다. check를 리턴 값으로 선택하면 실패한 경우에 문자열 복사가 발생하지 않기 때문이다.

일반적으로 개발자들이 많이 사용하는 함수 디자인 패턴이 있다. 그런 디자인 패턴에는 일반적으로 함수를 디자인한 사람의 생각과 그 함수를 사용하는 사람이 전제할 수 있는 내용들이 있다. 많이 사용되는 디자인을 살펴보면 다음과 같은 형태들이 있다.

BOOL GetPage(const WCHAR *url, std::string &buffer);

url에 const가 붙어있기 때문에 입력으로 사용되는 값임을 유추할 수 있다. buffer는 레퍼런스이기 때문에 반드시 값이 지정되어야 한다는 것을 의미한다. BOOL은 함수의 성공 여부를 리턴 한다고 기대할 수 있다. 실패한 경우에는 GetLastError같은 함수나 errno 같은 전역 변수를 사용해서 추가적인 오류 코드를 확인할 수 있도록 설계된 경우가 대부분이다.

HRESULT GetPage(const WCHAR *url, std::string &buffer);

이 경우에 바뀐건 BOOL이 HRESULT가 된 것 뿐이다. GetLastError를 사용할 필요 없이 실패 원인을 직접 반환하겠다는 의도다.

HRESULT GetPage(const WCHAR *url, std::string *buffer);

buffer가 레퍼런스에서 포인터로 변경됐다. 이 값이 필요 없는 경우에는 NULL을 지정해도 된다는 것을 의미한다. 물론 이 관습을 모든 함수가 따르는 건 아니다. 대체로 그렇다는 말이다.

HRESULT GetPage(const WCHAR *url, WCHAR *buffer, SIZE_T size);

buffer가 문자열 클래스에서 문자열 포인터로 변경됐다. buffer는 size 만큼을 담을 수 있다는 것을 의미한다. 이 경우에 size가 문자 개수냐 바이트 수냐는 애매하다. 함수 설명에 어떤 내용을 의미하는지 명시할 필요가 있다.

HRESULT GetPage(const WCHAR *url, WCHAR **buffer);

GetPage란 함수가 메모리를 할당해서 buffer에 반환하겠다는 의도다. 이렇게 디자인 된 함수는 통상적으로 어떤 함수를 사용해서 buffer를 해제해야 하는지를 명시하고 있는 경우가 대부분이다. buffer의 사용이 끝나면 해당 함수를 통해서 메모리 해제를 해주어야 한다.

WCHAR *GetPage(const WCHAR *url);

반환 값이 WCHAR *이 된 함수다. 이 함수 또한 GetPage 내부에서 메모리 할당을 하겠다는 생각이 깔려있다. 실패한 경우에는 통상적으로 NULL이 반한되고 세부적인 원인은 GetLastError등의 별도 함수를 사용해서 알 수 있도록 디자인된 경우가 대부분이다. 또한 앞선 함수와 마찬가지로 반환 값을 어떤 함수를 사용해서 해제해야 하는지를 명시하는 경우가 대부분이다. 반환값 사용이 끝나면 해당 함수를 통해서 메모리 해제를 해주어야 한다.

HANDLE GetPage(const WCHAR *url);

반환 값이 HANDLE이 된 함수다. 이 경우에는 핸들을 통해서 페이지 내용을 조회할 수 있는 함수와 핸들을 닫는 함수가 존재한다는 것을 의미한다. 각각 어떤 함수를 사용해야 하는지를 명시할 필요가 있다.

[소고] 올바른 의사 결정과 조직 구성원의 감정, 그리고 황금알을 낳는 거위

Mon, 12 Jan 2015 23:59:07 GMT

바야흐로 평가의 계절이 돌아왔다. 사람이 사람을 평가한다는 게 참 우습지만 조직의 자원 분배라는 측면을 고려한다면 평가는 필연적일 수밖에 없다는 생각이 들기도 한다. 모두가 평등하게 보상을 받는 사회주의 시스템의 말로를 우리는 똑똑히 보았다. 유토피아적인 퐌타지를 자극하지만 인간의 욕망을 거세한 다음 남는 것은 무기력감밖에 없었다는 사실을 우리는 모두 알고 있다. 조직도 비슷하다는 생각이 든다. 회색 빛깔 조직이 되지 않으려면 아주 단순한 사실, 조직을 위해 더 기여한 사람은 더 나은 보상을 받아야 한다, 라는 사실을 상기할 필요가 있다.

몇 해 전 여기에 관한 글을 하나 적은 기억이 난다. 한 3년 지났는데 지금 읽어봐도 참 공감이 간다. 그사이 내가 깨달은 한 가시 사실이 있다면 황금알을 낳는 거위의 배를 가르지 않기 위해서는 생각보다 엄청난 노력이 필요하다는 점이다. 특히나 조직이 커지면 커질수록 불가능에 가까워지는 것 같다. 지수 함수의 그것처럼 빠른 속도로 말이다. 100명, 1000명, 10000명이 되는 조직에서는 그 일이 얼마나 힘들지 상상조차 되지 않는다.

최근에 나는 황금알을 낳는 거위를 보호하기 위해서 많은 노력을 했다. 다양한 사람들과 많은 이야기를 했고, 황금알을 낳는 거위가 다른 사람들이 보기에도 황금알을 낳는 거위처럼 보이도록 만들기 위한 작업들도 했다. 하지만 그런 작업들이 결코 순탄치는 않았다. 그 과정에서 더러는 유혹도 있었고, 회유도 있었고, 역설득도 있었고, 협박도 있었다. 참 이 조그만 조직 사람들을 설득하기도 쉽지 않다는 생각을 많이 했다. 나 좋자는 것도 아니고 다 잘되자는 건데 말이다. 물론 그 황금알을 낳는 거위가 없어진다고 우리가 망하진 않을 것이다. 단지 엄청나게 불편하고 느려지고 바보 같아질 뿐이겠지만 말이다.

어쨌든 난 최근의 이런 경험을 통해서 한가지 사실을 깨달았다. 대부분의 조직에서 조직 구성원들이 황금알을 낳는 거위의 배를 갈라버리는 이유는 그들이 바보여서도 아니고, 그들이 정치적이어서도 아니고, 단지 배를 찢어버리는 게 그들의 삶을 더 편안하게 만들어주기 때문이란 사실이다. 마치 한약이 몸엔 좋지만 입에 쓴 것처럼 말이다.

“인생은 B와 D 사이의 C다”라고 장 폴 사르트르는 말했다. B는 탄생을(Birth), D는 죽음을(Death), C는 선택을(Choice) 나타낸다. 우리 인생은 매 순간 선택의 연속이고, 그 선택의 합이 누군가의 인생이라는 말이다. 조직도 틀리지 않다. 현재 어떤 조직의 상태는 그 조직의 설립 이후 지금까지의 의사 결정의 총합이다. 그래서 올바른 의사 결정은 조직의 생존을 위해서 매우 중요하다. 특히나 작고 힘없는 조직의 경우에는 더 그렇다. 왜냐하면 여분의 버퍼가 없기 때문에 잘못된 의사 결정 한번으로 몽땅 도루묵이 돼 버릴수도 있기 때문이다.

올바른 의사 결정이 조직의 생사를 결정할만큼 중요하기 때문에 조직 입장에서는 올바른 의사 결정을 내리는 것 자체가 굉장히 중요한 일이다. 따라서 올바른 의사 결정을 내리는 사람들이야 말로 조직의 관점에서는 황금알을 낳는 거위라고 부를 수 있다. 하지만 정말 아이러니하게도 조직 구성원에게는 이 황금알을 낳는 거위가 그다지 매력적으로 비춰지진 않는다. 올바른 의사 결정이 이해 당사자의 입장에서는 그다지 매력적이지 않기 때문이다.

회사에서 새로운 제품을 만들자는 의사 결정을 내렸다고 생각해보자. 새로운 제품을 만들기 위해서 신규 인력을 충원한다면 이야기가 다르겠지만 기존 조직 구성원만으로 새로운 제품을 만든다면 당연히 그 제품을 추가적으로 만들어야 하는 개발팀 입장에서는 반대할 수밖에 없다. 왜냐하면, 당장 자신들의 일이 늘어나기 때문이다. 그들의 시각에서는 새로운 제품 개발이 올바른 의사 결정이라 하더라도 탐탁지 않게 생각되는 것이다.

주말에 인터넷 서핑을 하다가 회사 제품이 탑재된 게임과 관련한 취약점 정보가 공유되는 것을 보게 되었다. 그런데 이미 그 취약점은 패치된 것이었다. 월요일 출근해서는 패치 담당자들에게 패치 요청을 이야기한다. 지극히 당연한 일이 벌어진 것처럼 보인다. 하지만 패치 담당자 입장에서는 일견 기분이 나쁠 수도 있다. 갑자기 추가적인 패치를 해야 하는 일이 생긴 것이기 때문이다. 특히나 이미 패치된 취약점이 반영되지 않았다는 것은 그 사이트의 업데이트가 쉽지 않을 수도 있기 때문에 더 골치아픈 일이 생긴 것이다. 그러니 취약점이 있어서 패치를 해야 한다는 누가봐도 토를 달기 힘든 의사 결정 앞에서도 기분은 썩 좋지 않다.

분석팀에서 해킹툴을 분석하다 취약점을 하나 찾았다. 런 타임에 결정돼야 하는 CRC가 링크 타임에 결정되도록 알고리즘을 만들어 둔 것이다. 물론 그 해킹툴은 이미 다른 로직을 통해서 차단이 되고 있다. 그걸 개발팀 담당자에게 가서 이야기를 한다. 이건 런 타임에 계산되야 효과가 있는데 링크 타임에 결정되니 효과가 없고 그래서 이런 취약점이 생긴다. 이 경우에 개발팀 담당자에 따라서 여러 케이스가 발생할 수 있다. 이 이야기를 이해 못하는 개발팀 담당자가 있을 수 있다. 얘가 또 왜 피곤한 이야기하지, 라고 생각하고 그냥 흘려 넘긴다. 이해는 하는데 그 해킹툴이 막힌걸 아는 담당자라면 이미 막혔는데 왜 그런 소리를 하느냐고 답변하기도 한다. 그 개발자가 문제를 제기한 분석가보다 상급자라면 최악의 경우가 생길수도 있다. 니가 뭘 안다고 이래라 저래라야, 라는 이야기를 할 수도 있다. 이랬든 저랬든 결국 모든 반응은 한 가지 지점을 가리킨다. 왜 나한테 와서 추가적인 일감을 만들어놓느냐는 것이다. 그 이야기의 옳고 그름이 중요한게 아니라 말이다.

이렇듯 대다수 조직에서의 올바른 결정이란 결국 누군가를 불편하게 만드는 것이다. 누군가를 불편하게 만든다는 건 불편해지는 누군가는 그 의사 결정에 좋은 감정을 가지기가 쉽지 않다는 것을 의미한다. 그러니 조직을 위해 지속적으로 올바른 의사 결정을 내리거나 제시하는 어떤 사람이 있다면 그 사람은 광역으로 질타를 받을 가능성이 농후하다. 왜냐하면 다양한 사람들을 불편하게 만들었기 때문이다. 불편한 의사 결정의 희생양이 된 사람들은 그 의사 결정의 옳고 그름을 떠나서 자신의 일이 늘어나거나 상해버린 감정을 먼저 생각하기 때문이다.

서 있으면 앉고 싶고, 앉으면 눕고 싶고, 누우면 자고 싶는게 사람 심리다. 조직도 똑같다. 새로운 변화는 두렵기 마련이고, 굴러 가면 굴러 가던대로 굴러가려는 관성이 생기게 마련이다. 그게 편하기 때문이다. 사람의 본성이 그러니 올바른 의사 결정을 싫어하는 다수를 뭐라고 할 수는 없는 노릇이다. 하지만 분명한 하나는 다수가 외면하기 때문에 올바른 의견을 제시하는 사람을 기피한다면 조직 내에는 그 누구도 좋은 의견을 제시하지 않을 거라는 점이다. 다수가 불편해지더라도, 욕먹을 각오를 하고 그런 이야기를 해주는 사람을 지지하고 보호해 줄 필요가 있다. 그래야 조직도 한걸음 전진할 수 있다.

처음 소스 코드 저장소를 사용하자는 말에 직원들은 자신들의 실수를 감시하려는 목적이 아니냐는 어처구니 없는 이야기를 했었다. 빌드 시스템을 만들 때에는 귀찮게 이런 걸 왜 만드냐는 이야기를 들었다. 웹 지원 시스템을 만들 때에는 이런 게 필요하냐는 이야기를 들었고, 디자인을 바꿔야 한다는 이야기를 했을 땐 니가 하라는 소리까지 들어서 직접 하기도 했었다. 레드마인을 쓰는 과정도 순탄치는 않았고, 최근에 슬랙을 사용하자는 이야기를 했었을 땐 어처구니 없게도 대화를 감시하려는 목적이 아니냐는 이야기를 듣기도 했었다. 안드로이드 버전을 만들 땐 이런 건 돈도 안되잖아요, 라는 이야기를 수도 없이 들었다. 돈을 벌고 안 벌고는 니가 판단할 문제가 아니라는 말을 수도 없이 했었다. 돌아보면 지금은 당연한 것들이지만 그 어떤 것도 쉽지 않았다. 당연한 것들이지만 받아들여지지 않은 것도 수도 없이 많다. 그래도 그나마 나는 권한이 있기에 쉬웠다.

일 더하기 일은 이다. 이렇게 말하든 저렇게 말하든 일 더하기 일은 이다. 여기서 중요한 건 일 더하기 일은 이라는 사실을 말했다는 게 중요하지 그걸 이렇게 말했느냐 저렇게 말했느냐가 중요하지는 않다. 사람에 따라서는 장황하게 말하는 걸 좋아하는 사람도 있을 수 있고, 간략하게 말하는 걸 좋아하는 사람이 있을 수도 있다. 자신의 기호에 맞다 안 맞다가 중요한게 아니다. 그 이야기를 한 사람이 자신보다 직급이 높은지 낮은지가 중요한 것도 아니다. 제일 중요한 건 그 사람이 말한 컨텐츠가 옳으냐 아니냐가 중요하다. 적어도 옳다면 그 사람 말을 진지하게 들어줄 필요가 있다. 지금 당장 실행할 수 없다고 하더라도 말이다. 그래야 하는 가장 큰 이유는 그 불편함을 만드는 바로 그 사람이 당신의 배를 채워주는 부가가치를 창출하는 사람이기 때문이다.

모두가 미리부터 전사하겠노라는 말은 하지만 막상 적의 칼날이 눈앞에 닿으면 목 자르는 형틀이 뒤에 있더라도 도망쳐 버려서 죽을 수 없게 됩니다. 그것은 사와 민이 죽을 수 없어서가 아니라 위에 있는 자가 할 수 없게 했기 때문입니다. 입으로는 상을 준다 하고 주지 않으며 처벌한다고 말하고는 실행하지 않아 상과 벌이 확실치 못하기 때문에 사와 민이 죽어 주지 않는 것입니다.

– 한비자

신의 생각

Thu, 20 Nov 2014 23:59:59 GMT

우리가 생활하는 실제 세계가 이럴지도 모른다.

6월에 상당히 재미난 과학책을 한 권 읽었습니다. “신의 생각”이란 책인데, 심심하신 분들은 한번 읽어보길 권해 드리고 싶네요. 시간 가는 줄 모르고 읽게 되는 묘한 매력이 있는 책입니다. 책의 논지는 결국 모든 출발점에는 정보가 있었고, 그 정보는 아마도 숫자였을꺼라는 뭐 그런 내용입니다. 그런 생각을 가졌던 물리학자들의 발자취를 따라가는 그런 책이지요. 책을 너무 감명 깊게 읽어서 서평을 써야지 하고 있다가 늘 그렇듯이 흐지부지 되었습니다. 그렇게 한동안 잊고 있다가 오늘 Reinhard Vz님께서 공유한 유튜브 동영상을 보는데 잊었던 그 내용들이 다시금 새록새록 머릿속에 떠올라, 내친김에 몇 자 끄적여 봅니다.

결국 테그마크에 따르면 ‘실재계’는 인간의 능력으로는 도저히 이해할 수 없는 심오한 수학적 실재가 인간이 의식할 수 있는 수준으로 투사된 것에 지나지 않는다. 한마디로 그것은 허상일 뿐이다. 흡사 스크린 위에 비춰진 영화의 영상과 음악, 음향이 0 또는 1의 형태로 DVD 홈에 새겨진 심오한 현실과 극명한 차이를 보이는 것처럼 말이다. 그런 의미에서 스크린 위에 투사된 영화를 진정한 ‘현실’로 인식하는 것은 망상이라 하겠다. 스크린 위에 펼쳐지는 영화는 한낱 환영일 뿐, 진정 유일한 실체는 오로지 DVD 안에 정보로만 기록되어 있다.

– 신의 생각, 이고르 보그다노프,그리슈카 보그다노프

물론 아직까지 완전히 증명된 것은 아니지만 오늘날 π는 소위 ‘우주－수’일 가능성이 있다고 여겨진다. 그것이 무슨 의미일까? 아주 기막힌 사실을 의미한다. 한마디로 여러분은 π 속에서 여러분이 원하는 것은 무엇이든 다 찾아낼 수 있다는 말이다! 가령 여러분의 생년월일은 물론, 여러분의 모습이 찍힌 최초의 사진, 혹은 이 순간 여러분이 손에 쥐고 있는 책(커버 사진과 같은 세세한 것을 모두 포함해서)까지도 전부! 사실상 우주－수는 모든 것, 우주에 존재했던 정말 모든 것을 품고 있다. 심지어는 미래에 존재하게 될 모든 것까지도. 그저 우리가 찾고 있는 것을 암호화해놓은 숫자열을 발견할 때까지 그저 멀리, 상상할 수 없을 만큼 멀리 나아가기만 하면 된다.

하지만 미국의 수학자 그레고리 카이틴이 지적한 것처럼 바로 거기에서 모든 역설이 시작된다. “π는 무한수이지만, 동시에 기하학적으로는 직선 위의 한 점에 불과하다.” 지당한 말씀이다! π란 실제 직선 위의 두 점 3.1과 3.2 사이 그 어딘가에 찍힌 작은 점, 그 이상도 이하도 아니기 때문이다.

그럼에도 다른 점과 그리 다를 것도 없는 이 ‘점’은 세계 곳곳에서 열광적인 반응을 만들어냈다. 가령 1980년대에는 ‘파이 데이’라는 기념일까지 만들어져, 매년 전세계 수학자들을 한자리에 불러 모으고 있다. 사실상 π의 탄생을 기념하겠다는 취지에서 만들어진 이 날은 π의 첫번째 세 자리 숫자(3, 1, 4)를 따서 3월 14일로 정해졌다. 흥미롭게도 이 날은 1879년 3월 14일 태어난 아인슈타인의 생일과도 겹친다.

– 신의 생각, 이고르 보그다노프,그리슈카 보그다노프

이쯤 읽고 나면 누구나 그렇듯 정말 파이에 그 모든 것이 다 들어 있을까 궁금해지기 마련이죠. 그래서 얼마나 긴 파이가 계산되었나 찾아보게 되었습니다. 아래 링크가 그런 파이 내용을 담고 있는 사이트 입니다. 그래서 그 안에서 몇몇 분들의 생년원일을 찾아봤는데 약속이나 한 것처럼 모두 그 거대한 파이 속에 있었습니다. 당연히 없는 사람들도 있겠지만 그건 어쩌면 아직 계산되지 않은건 아닐까라는 어처구니 없는 상상의 나래를 펼쳐 보기도 했습니다. 너무 심심해서 미칠 지경인 분들은 아래 사이트에서 자신의 생년월일을 한 번 찾아보는 소소한 재미를 누려 보시는 것도 좋을 것 같아요 ㅋㅋ~

http://piworld.calico.jp/estart.html

http://www.eveandersson.com/pi/digits/1000000

라마누잔의 파이 공식

이게 인간의 머리에서 나올 수 있는 공식이란 말인가? 핡~

파이 하면 또 빼놓을 수 없는 사람이 바로 라마누잔인데요. 꿈 속에서 신이 불러준 내용을 적었다는 그의 말이 진짠지 거짓인진 모르겠지만 정말 사람이 상상해 냈다고 하기엔 공식이 참 뷁스럽지요 ㅋㅋ~

사실상 몇 년 전 괴델은 불완전성 정리를 모든 우주에 적용해보는 연습을 했다. 그때 그는 우주의 의미는 우주만 가지고는 절대 알아낼 수 없다는 논리학적으로 명쾌한 결론에 도달했다. 우주 안의 의미를 발견하려면 반드시 우주 바깥의 원인이 필요했다. 한마디로 괴델은 신의 존재에 대해 자신만의 ‘증명’을 해나가는 과정에서, 요컨대 이 작업이 실은 자신이 기존 연구에서 발견한 것을 순전히 형식적인 차원에서 더욱 보강하는 것에 지나지 않는다는 사실을 깨달았다. 몇 달 뒤 그는 괴델판 ‘존재론적 증명’의 초안을 완성했다. 이 연구서에서 우리는 괴델의 논리전개 과정을 따라가다 마지막에 이런 결론에 도달하게 된다. “고로 신은 존재한다.”

– 신의 생각, 이고르 보그다노프,그리슈카 보그다노프

이런 생각을 괴델만 한 건 아닐겁니다. 논리적으로 증명한건 괴델이겠지만요 ㅋㅋ~ 중학교 땐지 고딩땐지 링이라는 소설이 유행했었는데 그때 링을 읽고는 그런 이야기를 했던 기억이 떠올랐습니다. 그때 그 친구는 우리가 살고 있는 이 세상이 어쩌면 거대한 고래 뱃속인지도 모른다고 했었던 기억이 나네요. 어쨌든 링3편의 “날 그 쪽으로 데려가줘”라는 대사는 당시엔 정말 충격과 공포 그 자체였습니다.

링3 루프: 날 그쪽으로 데려가줘

Digital physics is grounded in one or more of the following hypotheses; listed in order of decreasing strength. The universe, or reality:

is essentially informational (although not every informational ontology needs to be digital)

is essentially computable (the pancomputationalist position)

can be described digitally

is in essence digital

is itself a computer (pancomputationalism)

is the output of a simulated reality exercise

– http://en.wikipedia.org/wiki/Digital_physics

책을 덮고나서 흥미가 생겨 위키 페이지를 살펴봤습니다. 디지털 물리학이라, 네오가 왜 갑인지 알 것 같지 않나요?! ㅋㅋㅋ~ 그리고 아래는 오늘 유튜브에서 보았다는 동영상입니다. 블랙홀의 표면에 정보가 기록된다는 부분에서 쇼름이… 핡~

결국은 다 매트릭스?! ㅋㅋ

[cpp] argc, argv가 필요할 때에…

Thu, 30 Oct 2014 23:59:58 GMT

우리 회사 제품 코드는 크게 커밋 정책이 두 가지로 나뉘어져 있다. 아무나 손쉽게 커밋할 수 있는 공간과 내가 리뷰를 한 다음에 머지 해주는 공간이다. 당연히 전자는 빠르고, 새로운 것들이 손쉽게 추가되는 반면 후자는 더디고 어렵게 작업된다. 프로그래머 입장에서는 후자의 경우 빠꾸(리젝) 당하는 일도 많기 때문에 얼마간 자존심이 상하는 지점이기도 하다. 하지만 난 이런 정책이 우리 제품 코드를 보다 안정적이면서 빠르게 변화할 수 있도록 만들어 준다고 생각한다.

가끔, 대체로 어떤 문제가 발생했을 때, 내가 리뷰하지 않은 코드들에 대해서도 검토하는 일을 하는데 어제도 그런 일이 있었다. 그런데 생각보다 그 부분이 나에겐 다소 충격이었다. 비슷한 상황에 빠질 많은 초보 프로그래머에게 도움이 될 것 같아서 여기에 내용을 조금 옮겨 본다.

첫 번째 부분은 argc, argv였다. 윈도우 창을 띄우는 WinMain을 가진 프로그램이었는데, 프로그램 동작 과정 중에 커맨드라인 파싱 작업이 필요했던 것 같다. 그 프로그래머는 argc와 argv를 얻기 위해서 WinMain의 lpszCmdLine을 파싱하는 코드를 WinMain 내부에 작성해 두었다. 나중에 사용할 곳도 없지만 lpszCmdLine의 부족한 부분을 메우기 위해서 argv[0]는 GetModuleHandle을 사용해서 추가해주는 일도 잊지 않았다.

내가 충격을 받은 점은 다음과 같은 사실이었다. 1) 그 복잡한 파싱 for 문을 왜 함수로 빼지 않았을까, 2) 그 복잡한 파싱 for 문에 왜 커맨드 라인 파싱에 대한 일체의 고려도(따옴표, 역슬래시같은) 되어 있지 않을까? 3) 왜 이렇게 단순화한 버전을 만들면서 이미 다른 사람이 만들어 둔 내용을 사용하지 않았을까?

즉, 결론은 이랬다. 그 파싱 구문들은 굉장히 부적절하고 아주 많은 경우에 잘못된 파싱 결과를 가져오는 코드였다. 실제로 그 프로그램은 argv[1]만 필요로 하기 때문에 심지어는 lpszCmdLine을 직접 평가하는 작업이 더 적절했을 수도 있다. 이런 여러가지 가능성을 제쳐두고 그 프로그래머는 아주 조악한 코드를 자신이 직접 만드는 길을 선택했다.

argc, argv가 필요한 윈도우 프로그램을 만든다면 __argc, __argv, __wargv 같은 좋은 지원 도구들이 있다. 직접 만들 필요가 없다. 이미 검증된 파싱 루틴을 통해서 우리가 원하든 원하지 않든 WinMain이 시작되는 지점에 이미 그 데이터는 우리가 사용할 수 있도록 모두 준비되어 있다. 그러니 그저 가져다 쓰기만 하면 된다. 바퀴를 새로 만들고 이미 다 파싱해 놓은 걸 다시 또 파싱하겠다고 호기를 부릴 필요는 없다.

내가 두번째로 충격을 받은 부분은 한 곳이 더 있었는데 아래와 같은 코드였다.

if(!((__argc == 2) || (__argc == 3)))

도대체 드 모르간의 법칙을 생각나게 하는 이 코드는 무엇일까? 이 코드를 이해하기 위해서는 얼마간 에디터의 도움이 필요했다. 마지막 괄호를 지웠다 다시 썼을 때 에디터가 그 닫기 괄호가 어디에 매핑되는지를 알려주었기 때문이었다. 에디터의 도움이 없었다면 난 다시 스페이스를 사용해서 이 조건문의 실제 의미를 일일이 파악해야 했으리라.

if(__argc !=2 && __argc !=3)

대체로 많은 경우에 괄호가 없도록 조건문을 구성하는 것이 훨씬 읽기 쉬운 코드를 만든다. 위 코드는 에디터의 도움이 없이도 쉽게 의미하는 바를 눈치챌 수 있다.

if(__argc < 2)

의미를 고려한다면 그 조건문은 위와 같이 더 단순화 될 수도 있다. 왜냐하면 그 코드는 argv[1]에 접근 할 수 있는지를 검증하기 위한 용도로 사용되고 있었기 때문이다.

같은 현상을 설명하는 두 개의 주장이 있다면, 간단한 쪽을 선택하라

given two equally accurate theories, choose the one that is less complex

오컴의 면도날

오컴의 면도날이라는 말이 있다. 난 이 말이 프로그래밍에도 적용된다고 생각한다. 대부분의 경우에 간단한 쪽을 선택하는 편이 읽기도 좋고, 단순하며, 안정적인 좋은 코드를 만든다. 그래서 래리 월(펄의 창시자) 아저씨가 최고의 프로그래머 덕목 중 하나로 게으름을 꼽았는지도 모르겠다. 게으른 사람은 적어도 남들이 만든 걸 또 만들거나, 단순한 걸 두고 복잡한 걸 선택하지는 않을 테니 말이다.

반갑다(?!), 윈10

Thu, 02 Oct 2014 23:59:57 GMT

많은 이들의 기대를 저버리고 윈9이 아닌 윈10이 출시됐습니다.

어제 윈도 10이 발표됐습니다. 많은 사람들의 윈 9일거라는 추측을 무너뜨리고 9은 건너뛰고 10이 출시됐습니다. 왜 10인가에 대한 여러가지 억측 유머가 난무한 날이기도 했지요. 티맥스 윈도우 9 때문에 10이 됐다는 설, 8.1이 실제는 9이었다는 설, 맥 운영체제 버전에 맞추기 위해서 10을 했다는 설, 기존에 9이라고 알려진 걸 너무 많이 뜯어고치다 보니 완전 새로운 운영체제가 돼서 10을 했다는 설등 온갖 설들이 난무했습니다. 물론 진실은 안드로메다에 있겠지요. 어쨌든 발표된 윈도 10은 기존의 8 시리즈에서 지적됐던 많은 문제들을 개선했고, 또 새로운 기능이 다수 추가된 아주 혁.신.적.인 운영체제라고 합니다. 흥망은 뚜껑열어봐야 알겠지만요. MS의 발표에 따르자면 그렇다는 겁니다.

MS 말이 사실인지 확인하기 위해서 저도 테크니컬 프리뷰를 설치해 보았습니다. 윈도 10을 먼저 경험해 보고 싶으신 분들은 여기에서 다운받아 설치해 보시면 되겠습니다. 일단 설치하고 가장 눈에 띄는 건 시작 버튼이 돌아온 거네요. 저에겐 크게 필요하진 않았던 부분이지만 인상적이긴 한 것 같습니다.

우리는 또 수많은 비공개 구초체를 한땀한땀 추가해야 할 뿐이고…

시스템 프로그래머 입장에서 새로운 운영체제 발표는 사실 그닥 달갑지는 않은 일입니다. 왜냐하면 운영체제의 비공개된 부분을 사용하기 때문에 그걸 또 죄다 조사해서 맞춰주어야 하거든요. 어려운 작업은 아닌데 단순하고 무식하며 반복적이고 타이핑 실수가 발생하면 엄청나게 골치아파지는 그런 까탈스런 부분이죠. 그래서 설레임보다는 두려움이 앞서기도 합니다. 하지만 포스의 어두운 면과 밝은 면은 항상 공존하는 것처럼 제품을 판매하는 입장에서는 좋은 일이기도 합니다. 허들이 하나 더 추가되는 것이거든요. 왜냐하면 새로 진입하려는 사람들 입장에서는 새로운 운영체제를 추가적으로 지원해야 하는 부담감이 생기게 되는 것이고, 유사 제품을 만드는 회사들에게도 발빠르게 대응하지 않으면 먼저 지원한 제품에게는 차별적인 마케팅 포인트를 내주는 셈이 되기도 하거든요. 아직도 윈 10이 지원되지 않는 보안 제품을 사용하고 계신가요? 뭐 이런거죠? ㅋㅋ~

직업 프로그래머로 있었던 동안에 지원해야 했던 윈도 클라이언트 운영체제는 95, 98, 2000, XP, VISTA, 7, 8, 8.1에 이어서 아홉번째로 10인데요. 어떤 느낌의 운영체제일지 궁금하네요. 제발 내부적으로 크게 바뀌지 않았기를 미리 빌어봅니다. MS개발자느님들 저에게 자비쩜. 1년에 한번은 좀 빡쎄지 않나요(??!!)…

예제의 중요성, 복붙 프로그래밍의 위험성

Mon, 15 Sep 2014 23:59:56 GMT

ExampleSlot의 핸들릭을 가진 해킹툴 프로그램

간만에 해킹툴을 하나 살펴보고 있었습니다. 특징적인 게 메일슬롯을 사용하는데 ExampleSlot이란 이벤트 핸들릭이 있었습니다. ExampleSlot이라고 네임드 이벤트 이름을 지은 것도 웃긴데, 핸들릭도 어처구니 없는 그런 해킹툴이었죠. 메일슬롯으로 아주 중요한 데이터가 오가는 것 같아서 관련 함수를 살펴보고 있었습니다. 그러다 이 모든 시츄에이션을 설명해주는 MSDN 예제를 만나게 되었습니다. 그제서야 해커가 왜 그런 ㅂㅅ같은 짓을 했는지 자연스럽게 이해가 되더군요. MSDN 예제를 그대로 복사, 붙여넣기 했는데 그 예제에 핸들릭이 있었던 것이죠. 아무 생각없이 사용하다 벌어지는 정말 웃픈 상황이었습니다.

CloseHandle은 배고플 때 먹으려고 아껴두었죠.

핸들릭을 가진 MSDN 예제

언젠가 발표자료에서 보았던 이 그림이 생각나더군요. 생각 없이 코딩하는 프로그래머가 너무 많은 것 같습니다. 생각을 합시다. 머리는 폼으로 달려있는 건 아니잖아요. 물론 남 말 할 때는 아니지만 말입니다. 어쨌든 복사, 붙여넣기 할 때에는 그 코드가 어떤 코드든지, 누가 작성한 코드든지 한번 더 꼼꼼히 검토해 봐야 한다는 걸 잊지 맙시다.

생각 없는 프로그래머가 너무 많아요. 머리는 폼이 아니라는거~ ㅋㅋ

MmIsAddressValid와 PTE

Mon, 15 Sep 2014 23:59:55 GMT

다른 메모리에 접근할 일이 많은 보안 드라이버에서 자주 사용되는 함수 중에 하나가 MmIsAddressValid 함수다. MmIsAddressValid 함수는 접근하려는 메모리가 제대로 된 메모리인지 검사하는 코드다. 그런데 이 함수에서 말하는 valid의 의미는 생각보다 많이 좁다. 단순히 할당되서 접근할 수 있는 메모리를 의미하는 것이 아닌 실제로 물리 메모리에 존재하는 것들에 대해서만 valid 하다고 판단하기 때문이다. 즉, 페이지 아웃된 메모리는 접근할 수 있지만 MmIsAddressValid 함수는 FALSE를 리턴한다는 말이다.

그렇다면 페이지 아웃된 메모리까지 넓혀서 접근 가능한 커널 메모리를 체크하려면 어떤 방법이 있을까? 의외로 방법이 없는 것으로 추정(?!) 된다. ProbeForRead 같은 함수를 생각해 볼 수 있는데 해당 함수는 사용자 메모리에 대한 접근 여부를 체크하는 함수다. 커널 메모리를 넣으면 그냥 예외를 발생시키도록 설계돼 있다. 그.래.서. 결국 커널 영역 메모리의 할당 여부를 체크하려면 PDE, PTE를 직접 체크하는 수 밖에는 없다. 아마도…

직접 체크하는 방법을 구현하려면 PDE, PTE 따위의 구조외 윈도우에서 그것들을 어디에다 매핑시키는지 주소 공간 따위를 알아야 한다. 이게 또 처음 접해보면 다소 생소한 부분이다. 그때 참고하면 도움이 될만한 글이 있어서 소개해본다.

PTE 이해하기 1편

PTE 이해하기 2편

PTE 이해하기 3편

가상 함수 테이블 보호하기

Fri, 05 Sep 2014 23:59:54 GMT

클라이언트 코드 보안은 여러모로 복마전 같은 느낌이 강하다. CPU가 최종적으로 코드를 실행 시키기 때문에 사실상 해커가 코드를 분석하는 것을 완전하게 막는 방법은 없다. 게다가 현대적인 프로그램들은 이미 그 규모가 어마어마하게 크기 때문에 어떤 지점에서 어떤 공격이 벌어질지 사실상 예측하는 것이 불가능하다고 할 수 있다. 이런 이유로 클라이언트 코드 보안 영역에서는 줄기차게 해커와 경쟁을 벌일 수 밖에 없는 구조다. 상황이 이렇다보니 사실상 코드 보안에 대한 해법 보다는 해커와의 비용 경쟁으로 귀결되는 경우가 많다. 그래서 여기엔 해법(solution) 보다는 완화 방안(mitigation method)이 주를 이룬다.

최근 몇 년 사이 가장 각광받는 클라이언트 코드 공격 기술 중의 하나가 가상 함수 테이블 후킹 기법이다. 이 기법이 유행하게 된 데는 여러가지 이유가 있겠지만 가장 큰 이유는 공격 대상을 찾기가 쉽다는 것과, 한번 찾으면 쉽게 바뀌지 않는다는 점이라고 할 수 있다. 거대한 소프트웨어를 만들기 위해서는 필연적으로 레고 블록 같은 컴포넌트 기술이 발전할 수 밖에 없다. 그런 컴포넌트 기법 중에 사실상 업계 표준이 된 것은 COM이다. COM의 ABI(application binary interface)가 C++의 가상 함수 테이블의 구조로 이루어졌기에 광범위한 곳에서 C++의 가상함수 테이블과 유사한 바이너리 체계를 사용하게 되었다. 컴포넌트 인터페이스가 가지는 또 하나의 주요한 특징은 한번 정의되고 나면 바꾸기가 쉽지 않다는 점이다. 왜냐하면 여기저기 얽혀있는 경우가 많고, 심지어는 외부의 모듈들이 내부 컴포넌트를 참조하는 경우도 있기 때문이다. 이런 사실은 결국 해커 입장에서는 한번 공격하면 오랫동안 지속시킬 수 있다는 것을 의미하기 때문에 공격 비용이 낮아진다는 것과 같은 말이 된다. 해커 입장에서는 아주 빨대를 꽂기에 좋은 지점이지만 방어하는 입장에서는 한두군데가 아니기 때문에 아주 뼈아픈 지점이다.

그럼 실제로 공격이 어떤 방법으로 이루어지고 그걸 또 어떤 방식으로 방어할 수 있는지 알아보도록 하자. [리스트 1] 에는 간단한 가상 함수 테이블을 후킹하는 코드가 나와 있다. ICharacter 클래스는 체력을 구하는 GetHP 함수와, 체력을 설정하는 SetHP 함수를 가지고 있다. main을 살펴보면 캐릭터를 생성하고 10씩 체력을 감소시켜 가기 때문에 코드가 정상적으로 수행됐다면 90부터 0까지 값이 출력되어야 한다. 하지만 예제에서는 GetHP 함수를 HookGetHP로 대체했기 때문에 체력이 줄어들지 않고 모두 100으로 출력된다. 이런 원리로 게임에서 무적 핵이 만들어지곤 한다.

리스트 1 vftable 후킹 예제 소스 코드 다운로드

#include <windows.h>
#include <stdio.h>

class ICharacter
{
public:
	virtual int WINAPI GetHP() = 0;
	virtual void WINAPI SetHP(int hp) = 0;
};

class Romeo : public ICharacter
{
private:
	int hp_;

public:
	Romeo() { hp_ = 100; }
	virtual int WINAPI GetHP() { return hp_; }
	virtual void WINAPI SetHP(int hp) { hp_ = hp; }
};

int WINAPI HookGetHP(PVOID obj)
{
	return 100;
}

void HookVftable(PVOID obj, int vf_idx, PVOID hook_fn, PVOID *or_fn)
{
	ULONG_PTR *xobj = (ULONG_PTR *) obj;
	ULONG_PTR *vft = (ULONG_PTR *) xobj[0];

	if(or_fn)
		*or_fn = (PVOID) vft[vf_idx];

	ULONG oldp;
	VirtualProtect(&vft[vf_idx], sizeof(hook_fn), PAGE_READWRITE, &oldp);
	vft[vf_idx] = (ULONG_PTR) hook_fn;
	VirtualProtect(&vft[vf_idx], sizeof(hook_fn), oldp, &oldp);
}

int main()
{
	ICharacter *chr = new Romeo();
	HookVftable(chr, 0, HookGetHP, NULL);

	for(int i=0; i<10; ++i)
	{
		chr->SetHP(chr->GetHP() - 10);
		printf("%d", chr->GetHP());
		getchar();
	}

	return 0;
}

앞서도 말했지만 이런 코드 공격은 게임에서만 벌어지는 것은 아니다. 인터페이스가 존재하는 모든 프로그램들이 공격 대상이 될 수 있다. 특히나 웹 브라우저 같은 프로그램은 해커에게 아주 좋은 먹잇감이 되곤 한다. Internet Explorer 10 버전부터는 이러한 가상 함수 테이블 변조를 방지하기 위해서 주요 인터페이스 코드에 VTGuard란 것이 적용되었다.

VTGuard의 원리는 간단하다. 가상 함수 테이블 끝에 추가적인 필드를 붙여서 중간의 함수 메소드 값이 변경되었는지 검사하는 방식이다. [그림 1]에 나와 있는 것과 같이 테이블 끝에 vtguard에 해당하는 값을 넣어서 중간에 값이 변경되었는지 검사할 수 있다. vtguard에 VirtualMethod1, 2, 3, 4, …의 CRC 값이 담겨 있다면 앞선 가상 함수들이 호출될 때 테이블의 무결성을 검증할 수 있다. 물론 그 검증하는 코드는 모든 가상 함수의 앞쪽에 붙어 있어야 할 것이다. 물론 이 VTGuard라는 기법 자체도 가상 함수 변조를 완전히 막는 솔루션은 아니다. 왜냐하면 해커가 가상 함수의 값을 변경하고, 그에 맞춰서 vtguard의 값도 업데이트 한다면 우회할 수 있기 때문이다. 서두에 언급한 것과 같이 가상 함수 변조를 조금 더 어렵게 만드는 취약점 완화 방안이라고 생각하면 될 것 같다.

그림 1 vtguard 구조

가상 함수 테이블 변조가 프로그램의 심각한 취약점이 되면서 많은 컴파일러들이 VTGuard와 유사한 메커니즘을 속속 추가하고 있다. 보안 프로그래머 입장에서는 새로운 방어 기법과 컴파일러 옵션을 이해하는 것도 중요하지만 가장 원론적인 구성 원리를 체득하기 위해서는 그 메커니즘을 직접 구현해 보는 것이 가장 좋다. [리스트 2]에는 VTGuard를 구현할 수 있는 기본적인 매크로를 추가해 두었다. 살펴보면 가상 함수 끝에 엔트리를 추가하기 위해서 DECL_VT_GUARD라는 것을, vtguard 값의 초기화를 위해서 생성자에는 INIT_VT_GUARD를, 그리고 모든 멤버 함수 앞에는 가상 함수 테이블의 무결성을 검증하기 위한 CHECK_VT_GUARD 매크로가 추가됐다. 각각의 매크로를 구현해서 [리스트 1]의 코드와 연결했을 때 프로그램이 정상적으로 실행되지 않도록 만들어 보자.

리스트 2 VTGuard의 구현

class Romeo : public ICharacter
{
private:
	int hp_;

public:
	Romeo() { INIT_VT_GUARD(this); hp_ = 100; }
	virtual int WINAPI GetHP() { CHECK_VT_GUARD(this); return hp_; }
	virtual void WINAPI SetHP(int hp) { CHECK_VT_GUARD(this); hp_ = hp; }

	DECL_VT_GUARD();
};

덧) 여러분의 해법을 기다리고 있답니다. 썩 잘 만들었다고 생각하신다면 codewiz at gmail dot com으로 보내주세요. 함께 할 만한 일이 있을지도 모르잖아요 ^^;;

윈도우 2k: kernel32, ntdll 함수 덤프

Thu, 04 Sep 2014 23:59:53 GMT

MSDN 도움말에서 윈도우 2000이 사라진지 참 오래됐지요. 그럼에도 불구하고 여전히 윈도우 2000에서 돌아가는 프로그램을 만들어야 하는 개발자라면 과연 이 API가 윈도우 2000에 있는건지 없는건지 참 헷갈리는 경우가 많습니다. 그래서 써야 할까 말아야 할까? 동적 바인딩을 해야할까? 그냥 써도 될까? 궁금한거죠. 그러다 까딱 잘못하면 뭐 함수를 찾을 수 없다는 엄청난 오류에 봉착하곤 합니다. 그래서 매번 테스트 해보거나 윈도우 2000에서 dependency walker에 넣어서 보곤 했는데요. 귀찮아서 한번 덤프를 떠봤습니다. 저같은 고민을 하는 개발자라면 도움이 될지도 모르겠습니다. 윈도우 2000에 포함된 kernel32.dll과 ntdll.dll에 포함된 함수 덤프 정보입니다. 다소 스압이 있을지도 모르니 주의하시길 ㅋ~

덧) 특정 DLL의 익스포트 함수 목록을 추출하는 방법이 궁금하신 분들은 dump_eat 프로젝트 소스 코드를 다운로드 받아보세요.

kernel32.dll 정보

// kernel32.dll
   1 0001B65B AddAtomA
   2 0000DF58 AddAtomW
   3 0004639D AddConsoleAliasA
   4 00046366 AddConsoleAliasW
   5 00047187 AllocConsole
   6 000355B2 AllocateUserPhysicalPages
   7 00016C75 AreFileApisANSI
   8 00045AF4 AssignProcessToJobObject
   9 0002B9F6 BackupRead
  10 0002BC52 BackupSeek
  11 0002C5B9 BackupWrite
  12 0002ABAC BaseAttachCompleteThunk
  13 0002C7D7 Beep
  14 000423C9 BeginUpdateResourceA
  15 000421D2 BeginUpdateResourceW
  16 0003C271 BindIoCompletionCallback
  17 00044B59 BuildCommDCBA
  18 00044AE3 BuildCommDCBAndTimeoutsA
  19 00044A90 BuildCommDCBAndTimeoutsW
  20 00044B09 BuildCommDCBW
  21 000374F3 CallNamedPipeA
  22 000028B5 CallNamedPipeW
  23 000382B3 CancelDeviceWakeupRequest
  24 00030DFA CancelIo
  25 0003C4D4 CancelTimerQueueTimer
  26 0000301C CancelWaitableTimer
  27 0003C38F ChangeTimerQueueTimer
  28 0003DF83 ClearCommBreak
  29 0003DF91 ClearCommError
  30 00005C50 CloseConsoleHandle
  31 00009168 CloseHandle
  32 0001F8CB CloseProfileUserMapping
  33 00021580 CmdBatNotification
  34 0003DB27 CommConfigDialogA
  35 0003DA4B CommConfigDialogW
  36 0001076D CompareFileTime
  37 0000D3D4 CompareStringA
  38 0000E2FB CompareStringW
  39 00009A1D ConnectNamedPipe
  40 000040CC ConsoleMenuControl
  41 0002DDC9 ContinueDebugEvent
  42 00004856 ConvertDefaultLocale
  43 00020E6C ConvertThreadToFiber
  44 000146C0 CopyFileA
  45 000324D4 CopyFileExA
  46 00014736 CopyFileExW
  47 00020069 CopyFileW
  48 0004876A CreateConsoleScreenBuffer
  49 000239D8 CreateDirectoryA
  50 0002E0A8 CreateDirectoryExA
  51 0001F9FD CreateDirectoryExW
  52 0001DFF5 CreateDirectoryW
  53 00014CEA CreateEventA
  54 0001B259 CreateEventW
  55 00020D7E CreateFiber
  56 00020D96 CreateFiberEx
  57 000157E2 CreateFileA
  58 0000C8DA CreateFileMappingA
  59 000143E4 CreateFileMappingW
  60 0000C351 CreateFileW
  61 00045CFA CreateHardLinkA
  62 00045D4D CreateHardLinkW
  63 000099CD CreateIoCompletionPort
  64 0004594B CreateJobObjectA
  65 000459B0 CreateJobObjectW
  66 00016DA5 CreateMailslotA
  67 00016CAF CreateMailslotW
  68 0000A4F6 CreateMutexA
  69 0001D584 CreateMutexW
  70 00036D7A CreateNamedPipeA
  71 00022806 CreateNamedPipeW
  72 000206B1 CreatePipe
  73 0001C0A0 CreateProcessA
  74 0001BF86 CreateProcessInternalA
  75 00011BA0 CreateProcessInternalW
  76 00038628 CreateProcessInternalWSecure
  77 0000B252 CreateProcessW
  78 000133C3 CreateRemoteThread
  79 00006890 CreateSemaphoreA
  80 0001EAD5 CreateSemaphoreW
  81 0004583F CreateTapePartition
  82 000095C2 CreateThread
  83 0003C31A CreateTimerQueue
  84 0003C33B CreateTimerQueueTimer
  85 0003C50F CreateToolhelp32Snapshot
  86 00006DC4 CreateVirtualBuffer
  87 00002FE4 CreateWaitableTimerA
  88 00020B94 CreateWaitableTimerW
  89 0002DDFB DebugActiveProcess
  90 0002D9F6 DebugBreak
  91 000303DF DefineDosDeviceA
  92 000148BE DefineDosDeviceW
  93 00057090 DelayLoadFailureHook
  94 0000DFA9 DeleteAtom
  95          DeleteCriticalSection => NTDLL.RtlDeleteCriticalSection
  96 00020E22 DeleteFiber
  97 0001BEEA DeleteFileA
  98 0000D9F9 DeleteFileW
  99 0003C4B0 DeleteTimerQueue
 100 0003C41B DeleteTimerQueueEx
 101 0003C3D0 DeleteTimerQueueTimer
 102 00041972 DeleteVolumeMountPointA
 103 00041B33 DeleteVolumeMountPointW
 104 0001D626 DeviceIoControl
 105 0001C912 DisableThreadLibraryCalls
 106 00009A9D DisconnectNamedPipe
 107 0002D1D3 DnsHostnameToComputerNameA
 108 0002D13B DnsHostnameToComputerNameW
 109 00007B91 DosDateTimeToFileTime
 110 00039A1B DosPathToSessionPathA
 111 00017417 DosPathToSessionPathW
 112 00005C98 DuplicateConsoleHandle
 113 0000E960 DuplicateHandle
 114 00042746 EndUpdateResourceA
 115 000425DA EndUpdateResourceW
 116          EnterCriticalSection => NTDLL.RtlEnterCriticalSection
 117 0004ACB8 EnumCalendarInfoA
 118 0004ACD4 EnumCalendarInfoExA
 119 0004D407 EnumCalendarInfoExW
 120 0004D3EB EnumCalendarInfoW
 121 0004AD06 EnumDateFormatsA
 122 0004AD1E EnumDateFormatsExA
 123 0004D423 EnumDateFormatsExW
 124 0001814F EnumDateFormatsW
 125 0004AEB0 EnumLanguageGroupLocalesA
 126 0004D3A9 EnumLanguageGroupLocalesW
 127 0003695F EnumResourceLanguagesA
 128 00023BC7 EnumResourceLanguagesW
 129 0003673A EnumResourceNamesA
 130 00001530 EnumResourceNamesW
 131 00036545 EnumResourceTypesA
 132 00036ADD EnumResourceTypesW
 133 0004AEE0 EnumSystemCodePagesA
 134 0004D3D9 EnumSystemCodePagesW
 135 0004AE9A EnumSystemLanguageGroupsA
 136 0004D393 EnumSystemLanguageGroupsW
 137 00017BA1 EnumSystemLocalesA
 138 00018127 EnumSystemLocalesW
 139 0004ACF0 EnumTimeFormatsA
 140 00018139 EnumTimeFormatsW
 141 0004AECA EnumUILanguagesA
 142 0004D3C3 EnumUILanguagesW
 143 00045813 EraseTape
 144 0003E1AD EscapeCommFunction
 145 0000E01A ExitProcess
 146 00005F3B ExitThread
 147 000031EF ExitVDM
 148 00017208 ExpandEnvironmentStringsA
 149 0001A0EC ExpandEnvironmentStringsW
 150 0004699E ExpungeConsoleCommandHistoryA
 151 00046990 ExpungeConsoleCommandHistoryW
 152 00035E47 ExtendVirtualBuffer
 153 00039397 FatalAppExitA
 154 00039350 FatalAppExitW
 155 000393DE FatalExit
 156 0000D1B2 FileTimeToDosDateTime
 157 0000EA21 FileTimeToLocalFileTime
 158 000095E2 FileTimeToSystemTime
 159 000045A6 FillConsoleOutputAttribute
 160 0004872D FillConsoleOutputCharacterA
 161 0004874D FillConsoleOutputCharacterW
 162 00016410 FindAtomA
 163 0002EAD1 FindAtomW
 164 0000EE4B FindClose
 165 0001B2CF FindCloseChangeNotification
 166 000249A2 FindFirstChangeNotificationA
 167 0001B6AB FindFirstChangeNotificationW
 168 0001D88F FindFirstFileA
 169 00030748 FindFirstFileExA
 170 0000C96C FindFirstFileExW
 171 00007770 FindFirstFileW
 172 0004048D FindFirstVolumeA
 173 00040738 FindFirstVolumeMountPointA
 174 00040B52 FindFirstVolumeMountPointW
 175 00003F28 FindFirstVolumeW
 176 00023D67 FindNextChangeNotification
 177 00010275 FindNextFileA
 178 0000CCB3 FindNextFileW
 179 000405CC FindNextVolumeA
 180 00040C5F FindNextVolumeMountPointA
 181 00040EB5 FindNextVolumeMountPointW
 182 00021E34 FindNextVolumeW
 183 0001D38D FindResourceA
 184 00014B2C FindResourceExA
 185 0000B82D FindResourceExW
 186 0000B622 FindResourceW
 187 00004052 FindVolumeClose
 188 0001B2CF FindVolumeMountPointClose
 189 000045C3 FlushConsoleInputBuffer
 190 0001C9CC FlushFileBuffers
 191 0001132B FlushInstructionCache
 192 0000E2C6 FlushViewOfFile
 193 0004AD44 FoldStringA
 194 0001AD12 FoldStringW
 195 00016DEF FormatMessageA
 196 00006DA1 FormatMessageW
 197 0004739A FreeConsole
 198 0000A8A4 FreeEnvironmentStringsA
 199 0000A8A4 FreeEnvironmentStringsW
 200 0000DFDA FreeLibrary
 201 0000FFE9 FreeLibraryAndExitThread
 202 0000754C FreeResource
 203 000355D9 FreeUserPhysicalPages
 204 00006E63 FreeVirtualBuffer
 205 00048E8F GenerateConsoleCtrlEvent
 206 0000FE74 GetACP
 207 00023F24 GetAtomNameA
 208 0000DF68 GetAtomNameW
 209 0003EFCA GetBinaryType
 210 0003EFCA GetBinaryTypeA
 211 00020F84 GetBinaryTypeW
 212 0000B732 GetCPInfo
 213 0004AEF2 GetCPInfoExA
 214 00050CF3 GetCPInfoExW
 215 0004A4C6 GetCalendarInfoA
 216 00004EDC GetCalendarInfoW
 217 0003E2AE GetCommConfig
 218 0003E43C GetCommMask
 219 0003E4BA GetCommModemStatus
 220 0003E538 GetCommProperties
 221 0003E5E9 GetCommState
 222 0003E87C GetCommTimeouts
 223 00014B16 GetCommandLineA
 224 0001386F GetCommandLineW
 225 00031D43 GetCompressedFileSizeA
 226 00031D64 GetCompressedFileSizeW
 227 0001631F GetComputerNameA
 228 00001779 GetComputerNameExA
 229 0001C5F7 GetComputerNameExW
 230 0000F7C8 GetComputerNameW
 231 00046505 GetConsoleAliasA
 232 000468F9 GetConsoleAliasExesA
 233 0004663F GetConsoleAliasExesLengthA
 234 00046637 GetConsoleAliasExesLengthW
 235 000468E7 GetConsoleAliasExesW
 236 000464E0 GetConsoleAliasW
 237 000467B3 GetConsoleAliasesA
 238 000465D2 GetConsoleAliasesLengthA
 239 000465C4 GetConsoleAliasesLengthW
 240 0004679D GetConsoleAliasesW
 241 0000465B GetConsoleCP
 242 00049746 GetConsoleCharType
 243 00046C80 GetConsoleCommandHistoryA
 244 00046B0A GetConsoleCommandHistoryLengthA
 245 00046AFC GetConsoleCommandHistoryLengthW
 246 00046C6A GetConsoleCommandHistoryW
 247 00022291 GetConsoleCursorInfo
 248 00049911 GetConsoleCursorMode
 249 000220DB GetConsoleDisplayMode
 250 00048C35 GetConsoleFontInfo
 251 00048D5C GetConsoleFontSize
 252 000479C5 GetConsoleHardwareState
 253 00046D91 GetConsoleInputExeNameA
 254 00046E12 GetConsoleInputExeNameW
 255 00047478 GetConsoleInputWaitHandle
 256 00004710 GetConsoleKeyboardLayoutNameA
 257 000494F7 GetConsoleKeyboardLayoutNameW
 258 0000C0DA GetConsoleMode
 259 00049554 GetConsoleNlsMode
 260 0000C16D GetConsoleOutputCP
 261 0001CEAA GetConsoleScreenBufferInfo
 262 00046D2A GetConsoleTitleA
 263 0000EDB2 GetConsoleTitleW
 264 00049505 GetConsoleWindow
 265 0004AA47 GetCurrencyFormatA
 266 00053056 GetCurrencyFormatW
 267 00048DC4 GetCurrentConsoleFont
 268 00015813 GetCurrentDirectoryA
 269 0001BAC7 GetCurrentDirectoryW
 270 0001E0C8 GetCurrentProcess
 271 0000B8F4 GetCurrentProcessId
 272 00015633 GetCurrentThread
 273 000110D1 GetCurrentThreadId
 274 00017A38 GetDateFormatA
 275 00018893 GetDateFormatW
 276 0003DCE2 GetDefaultCommConfigA
 277 0003DC06 GetDefaultCommConfigW
 278 00055438 GetDefaultSortkeySize
 279 0003824E GetDevicePowerState
 280 0000ACF8 GetDiskFreeSpaceA
 281 0001AE60 GetDiskFreeSpaceExA
 282 0001AE8E GetDiskFreeSpaceExW
 283 0000AD29 GetDiskFreeSpaceW
 284 0000A6B4 GetDriveTypeA
 285 000067A7 GetDriveTypeW
 286 0001092C GetEnvironmentStrings
 287 0001092C GetEnvironmentStringsA
 288 0000733F GetEnvironmentStringsW
 289 0000614F GetEnvironmentVariableA
 290 0000BB88 GetEnvironmentVariableW
 291 0001BC2B GetExitCodeProcess
 292 0001F362 GetExitCodeThread
 293 00015134 GetFileAttributesA
 294 0003112C GetFileAttributesExA
 295 0001DCC7 GetFileAttributesExW
 296 0001B5CE GetFileAttributesW
 297 0000B0C4 GetFileInformationByHandle
 298 0001D0D4 GetFileSize
 299 0001D109 GetFileSizeEx
 300 00005E40 GetFileTime
 301 0001544F GetFileType
 302 00007A45 GetFullPathNameA
 303 00005D07 GetFullPathNameW
 304 000356C0 GetHandleInformation
 305 00048ADF GetLargestConsoleWindowSize
 306 0001278D GetLastError
 307 00055456 GetLinguistLangSize
 308 000106E0 GetLocalTime
 309 0000A132 GetLocaleInfoA
 310 00007786 GetLocaleInfoW
 311 00037D4E GetLogicalDriveStringsA
 312 000029BF GetLogicalDriveStringsW
 313 0000E4DB GetLogicalDrives
 314 00040164 GetLongPathNameA
 315 00021A72 GetLongPathNameW
 316 00035CB6 GetMailslotInfo
 317 00014C44 GetModuleFileNameA
 318 00010FB7 GetModuleFileNameW
 319 0000AB06 GetModuleHandleA
 320 00010182 GetModuleHandleW
 321 00036F92 GetNamedPipeHandleStateA
 322 00037071 GetNamedPipeHandleStateW
 323 00037290 GetNamedPipeInfo
 324 00021179 GetNextVDMCommand
 325 00011191 GetNlsSectionName
 326 0004A825 GetNumberFormatA
 327 00022C57 GetNumberFormatW
 328 000489D7 GetNumberOfConsoleFonts
 329 00048A26 GetNumberOfConsoleInputEvents
 330 00048B85 GetNumberOfConsoleMouseButtons
 331 00011562 GetOEMCP
 332 0001449E GetOverlappedResult
 333 00039573 GetPriorityClass
 334 0000ACAE GetPrivateProfileIntA
 335 00015F45 GetPrivateProfileIntW
 336 0002F005 GetPrivateProfileSectionA
 337 0002EAE1 GetPrivateProfileSectionNamesA
 338 0002EAFA GetPrivateProfileSectionNamesW
 339 00023726 GetPrivateProfileSectionW
 340 0000EC3E GetPrivateProfileStringA
 341 0000D957 GetPrivateProfileStringW
 342 0002EB13 GetPrivateProfileStructA
 343 0002EC24 GetPrivateProfileStructW
 344 0000E6A9 GetProcAddress
 345 000173D7 GetProcessAffinityMask
 346 0000AC86 GetProcessHeap
 347 00016C9C GetProcessHeaps
 348 000398B6 GetProcessIoCounters
 349 00039883 GetProcessPriorityBoost
 350 00039617 GetProcessShutdownParameters
 351 00039692 GetProcessTimes
 352 0001C933 GetProcessVersion
 353 00039705 GetProcessWorkingSetSize
 354 00011538 GetProfileIntA
 355 00016420 GetProfileIntW
 356 0002EF51 GetProfileSectionA
 357 00023710 GetProfileSectionW
 358 0000C905 GetProfileStringA
 359 0000AB2B GetProfileStringW
 360 0000FE7A GetQueuedCompletionStatus
 361 0001A1E1 GetShortPathNameA
 362 0001E1CC GetShortPathNameW
 363 000149DF GetStartupInfoA
 364 00017109 GetStartupInfoW
 365 0000AF0D GetStdHandle
 366 00017B2B GetStringTypeA
 367 000223CA GetStringTypeExA
 368 00017CB0 GetStringTypeExW
 369 00006658 GetStringTypeW
 370 00019A86 GetSystemDefaultLCID
 371 00015150 GetSystemDefaultLangID
 372 0001F14B GetSystemDefaultUILanguage
 373 0000EDED GetSystemDirectoryA
 374 0000FF1C GetSystemDirectoryW
 375 0001AAA4 GetSystemInfo
 376 000207D1 GetSystemPowerStatus
 377 000069F9 GetSystemTime
 378 0002D737 GetSystemTimeAdjustment
 379 000072E5 GetSystemTimeAsFileTime
 380 00019796 GetSystemWindowsDirectoryA
 381 000078B2 GetSystemWindowsDirectoryW
 382 000458A5 GetTapeParameters
 383 0004578F GetTapePosition
 384 00045934 GetTapeStatus
 385 000070D4 GetTempFileNameA
 386 0001D962 GetTempFileNameW
 387 00013B81 GetTempPathA
 388 00006476 GetTempPathW
 389 00003050 GetThreadContext
 390 0000C1C4 GetThreadLocale
 391 0000A545 GetThreadPriority
 392 0003BB69 GetThreadPriorityBoost
 393 0002DFF6 GetThreadSelectorEntry
 394 00020D1E GetThreadTimes
 395 00015594 GetTickCount
 396 0001796C GetTimeFormatA
 397 0001B481 GetTimeFormatW
 398 00015177 GetTimeZoneInformation
 399 000115AD GetUserDefaultLCID
 400 000115AD GetUserDefaultLangID
 401 0001E96D GetUserDefaultUILanguage
 402 0003F3F3 GetVDMCurrentDirectories
 403 0001EB3A GetVersion
 404 00013C2D GetVersionExA
 405 0000E8A7 GetVersionExW
 406 0001199F GetVolumeInformationA
 407 000109E7 GetVolumeInformationW
 408 00040ECB GetVolumeNameForVolumeMountPointA
 409 000076EC GetVolumeNameForVolumeMountPointW
 410 00041E15 GetVolumePathNameA
 411 00041F32 GetVolumePathNameW
 412 00009C00 GetWindowsDirectoryA
 413 0000B810 GetWindowsDirectoryW
 414 00035668 GetWriteWatch
 415 0000E2B6 GlobalAddAtomA
 416 0000727B GlobalAddAtomW
 417 000116B4 GlobalAlloc
 418 0003599B GlobalCompact
 419 0001596E GlobalDeleteAtom
 420 00009F88 GlobalFindAtomA
 421 0000CC0B GlobalFindAtomW
 422 000354A9 GlobalFix
 423 00015B74 GlobalFlags
 424 000132AF GlobalFree
 425 000248EE GlobalGetAtomNameA
 426 0000DF91 GlobalGetAtomNameW
 427 00014344 GlobalHandle
 428 0001E6AF GlobalLock
 429 00009D2A GlobalMemoryStatus
 430 000025DB GlobalMemoryStatusEx
 431 00007416 GlobalReAlloc
 432 00014286 GlobalSize
 433 000354E2 GlobalUnWire
 434 000354BE GlobalUnfix
 435 0000B426 GlobalUnlock
 436 000354D3 GlobalWire
 437 0003C6D1 Heap32First
 438 0003C590 Heap32ListFirst
 439 0003C63F Heap32ListNext
 440 0003C7DD Heap32Next
 441          HeapAlloc => NTDLL.RtlAllocateHeap
 442 000073F4 HeapCompact
 443 0001AE05 HeapCreate
 444 00035A18 HeapCreateTagsW
 445 00014567 HeapDestroy
 446 000359EE HeapExtend
 447          HeapFree => NTDLL.RtlFreeHeap
 448 00035B0E HeapLock
 449 00035A31 HeapQueryTagW
 450          HeapReAlloc => NTDLL.RtlReAllocateHeap
 451          HeapSize => NTDLL.RtlSizeHeap
 452 00035A4D HeapSummary
 453 00035B21 HeapUnlock
 454 00035AA1 HeapUsage
 455 0001B240 HeapValidate
 456 00035B34 HeapWalk
 457 0002EAAA InitAtomTable
 458 0001BE13 InitializeCriticalSection
 459 00015157 InitializeCriticalSectionAndSpinCount
 460 0000A96D InterlockedCompareExchange
 461 0001C23D InterlockedDecrement
 462 00008FBC InterlockedExchange
 463 00013E7C InterlockedExchangeAdd
 464 0001C22C InterlockedIncrement
 465 000488FC InvalidateConsoleDIBits
 466 000150C4 IsBadCodePtr
 467 00006AE2 IsBadHugeReadPtr
 468 0000A4E6 IsBadHugeWritePtr
 469 0000F0F7 IsBadReadPtr
 470 0001BE4B IsBadStringPtrA
 471 000159F3 IsBadStringPtrW
 472 0001A055 IsBadWritePtr
 473 0000CC8D IsDBCSLeadByte
 474 0001871B IsDBCSLeadByteEx
 475 0000191E IsDebuggerPresent
 476 000062D7 IsProcessorFeaturePresent
 477 0003828B IsSystemResumeAutomatic
 478 000060C4 IsValidCodePage
 479 0004BF19 IsValidLanguageGroup
 480 00017D7E IsValidLocale
 481 00017859 LCMapStringA
 482 00019CA1 LCMapStringW
 483          LeaveCriticalSection => NTDLL.RtlLeaveCriticalSection
 484 000105CF LoadLibraryA
 485 00010606 LoadLibraryExA
 486 0001A952 LoadLibraryExW
 487 000152C5 LoadLibraryW
 488 00038FAD LoadModule
 489 0000A63A LoadResource
 490 0001C13B LocalAlloc
 491 0003599B LocalCompact
 492 000163DF LocalFileTimeToFileTime
 493 0002A48E LocalFlags
 494 0001C1C6 LocalFree
 495 0002A594 LocalHandle
 496 000128A2 LocalLock
 497 00014F2B LocalReAlloc
 498 000359B0 LocalShrink
 499 000154D4 LocalSize
 500 000127F8 LocalUnlock
 501 0001E4E4 LockFile
 502 00030C21 LockFileEx
 503 0001154E LockResource
 504 00035600 MapUserPhysicalPages
 505 00035627 MapUserPhysicalPagesScatter
 506 00006533 MapViewOfFile
 507 0001D74A MapViewOfFileEx
 508 0003CE25 Module32First
 509 0003CD6F Module32FirstW
 510 0003CF91 Module32Next
 511 0003CEF1 Module32NextW
 512 0001ED51 MoveFileA
 513 0001274C MoveFileExA
 514 00001CDA MoveFileExW
 515 000166A0 MoveFileW
 516 00010C86 MoveFileWithProgressA
 517 00010CF0 MoveFileWithProgressW
 518 00009BBA MulDiv
 519 000078FF MultiByteToWideChar
 520 00011138 NlsConvertIntegerToString
 521 00019071 NlsGetCacheUpdateCount
 522 0004BEF8 NlsResetProcessLocale
 523 00017658 OpenConsoleW
 524 00019184 OpenDataFile
 525 00014EDA OpenEventA
 526 0001162C OpenEventW
 527 0000BF59 OpenFile
 528 0000C1D1 OpenFileMappingA
 529 0000C222 OpenFileMappingW
 530 00045A17 OpenJobObjectA
 531 00045A84 OpenJobObjectW
 532 0001AFA6 OpenMutexA
 533 0001AFF7 OpenMutexW
 534 000091B9 OpenProcess
 535 0001DB3A OpenProfileUserMapping
 536 0001F491 OpenSemaphoreA
 537 00013D96 OpenSemaphoreW
 538 0003BAC1 OpenThread
 539 0003A5F7 OpenWaitableTimerA
 540 0003A664 OpenWaitableTimerW
 541 00024539 OutputDebugStringA
 542 0002D9FC OutputDebugStringW
 543 00047D60 PeekConsoleInputA
 544 00047D7C PeekConsoleInputW
 545 0003730E PeekNamedPipe
 546 00001B4D PostQueuedCompletionStatus
 547 000457E7 PrepareTape
 548 000166F6 PrivCopyFileExW
 549 000319F6 PrivMoveFileIdentityW
 550 0003CA16 Process32First
 551 0003C960 Process32FirstW
 552 0003CB70 Process32Next
 553 0003CAD0 Process32NextW
 554 0001A355 ProcessIdToSessionId
 555 00020B6D PulseEvent
 556 0003E916 PurgeComm
 557 0001651F QueryDosDeviceA
 558 0000A2A6 QueryDosDeviceW
 559 00045B3C QueryInformationJobObject
 560 0000AA7D QueryPerformanceCounter
 561 00016F20 QueryPerformanceFrequency
 562 000301F1 QueryWin31IniFilesMappedToRegistry
 563 000030AB QueueUserAPC
 564 00020F64 QueueUserWorkItem
 565 0000A48C RaiseException
 566 000220AB ReadConsoleA
 567 0002225C ReadConsoleInputA
 568 00047DB4 ReadConsoleInputExA
 569 00047DD1 ReadConsoleInputExW
 570 00047D98 ReadConsoleInputW
 571 000044D6 ReadConsoleOutputA
 572 0004854A ReadConsoleOutputAttribute
 573 0004850C ReadConsoleOutputCharacterA
 574 0004852B ReadConsoleOutputCharacterW
 575 00048098 ReadConsoleOutputW
 576 00023603 ReadConsoleW
 577 000144DA ReadDirectoryChangesW
 578 00006582 ReadFile
 579 00030D56 ReadFileEx
 580 00030E21 ReadFileScatter
 581 00022AA8 ReadProcessMemory
 582 00049B85 RegisterConsoleIME
 583 000499D5 RegisterConsoleOS2
 584 00004116 RegisterConsoleVDM
 585 0000C6DC RegisterWaitForInputIdle
 586 00020ECB RegisterWaitForSingleObject
 587 0003C1B8 RegisterWaitForSingleObjectEx
 588 000025A2 RegisterWowBaseHandlers
 589 00003243 RegisterWowExec
 590 000117F4 ReleaseMutex
 591 0001565A ReleaseSemaphore
 592 00023D98 RemoveDirectoryA
 593 00023DB0 RemoveDirectoryW
 594 00001EE4 ReplaceFile
 595 0003492C ReplaceFileA
 596 00001EE4 ReplaceFileW
 597 00038295 RequestDeviceWakeup
 598 00038230 RequestWakeupLatency
 599 0000BF41 ResetEvent
 600 0003569A ResetWriteWatch
 601 0000BEE4 ResumeThread
 602          RtlFillMemory => NTDLL.RtlFillMemory
 603          RtlMoveMemory => NTDLL.RtlMoveMemory
 604          RtlUnwind => NTDLL.RtlUnwind
 605          RtlZeroMemory => NTDLL.RtlZeroMemory
 606 000492A5 ScrollConsoleScreenBufferA
 607 000492C2 ScrollConsoleScreenBufferW
 608 0000E540 SearchPathA
 609 00019BA4 SearchPathW
 610 00050B1F SetCPGlobal
 611 0004A5F8 SetCalendarInfoA
 612 0004CB09 SetCalendarInfoW
 613 0003E995 SetCommBreak
 614 0003E9A3 SetCommConfig
 615 0003EA34 SetCommMask
 616 0003EACA SetCommState
 617 0003EDE7 SetCommTimeouts
 618 0002D025 SetComputerNameA
 619 0002D0EB SetComputerNameExA
 620 0002CF5E SetComputerNameExW
 621 0002CA9A SetComputerNameW
 622 00048EF9 SetConsoleActiveScreenBuffer
 623 000493B4 SetConsoleCP
 624 00046C96 SetConsoleCommandHistoryMode
 625 00017814 SetConsoleCtrlHandler
 626 0004776D SetConsoleCursor
 627 00049020 SetConsoleCursorInfo
 628 000498AE SetConsoleCursorMode
 629 00048FC3 SetConsoleCursorPosition
 630 00047871 SetConsoleDisplayMode
 631 000492F5 SetConsoleFont
 632 00047A89 SetConsoleHardwareState
 633 00049352 SetConsoleIcon
 634 00046EA7 SetConsoleInputExeNameA
 635 0001E9B1 SetConsoleInputExeNameW
 636 00047B19 SetConsoleKeyShortcuts
 637 00049808 SetConsoleLocalEUDC
 638 000493A9 SetConsoleMaximumWindowSize
 639 00047BBF SetConsoleMenuClose
 640 00006076 SetConsoleMode
 641 00049699 SetConsoleNlsMode
 642 00046A60 SetConsoleNumberOfCommandsA
 643 00046A4E SetConsoleNumberOfCommandsW
 644 00049A2C SetConsoleOS2OemFormat
 645 000494AE SetConsoleOutputCP
 646 00047C16 SetConsolePalette
 647 00048F66 SetConsoleScreenBufferSize
 648 0000460B SetConsoleTextAttribute
 649 00004073 SetConsoleTitleA
 650 000243A9 SetConsoleTitleW
 651 000490E2 SetConsoleWindowInfo
 652          SetCriticalSectionSpinCount => NTDLL.RtlSetCriticalSectionSpinCount
 653 00010C18 SetCurrentDirectoryA
 654 0000FB16 SetCurrentDirectoryW
 655 0003DE9D SetDefaultCommConfigA
 656 0003DDC1 SetDefaultCommConfigW
 657 0000F2A6 SetEndOfFile
 658 00023650 SetEnvironmentVariableA
 659 00006038 SetEnvironmentVariableW
 660 0001ABA9 SetErrorMode
 661 0000B608 SetEvent
 662 00035795 SetFileApisToANSI
 663 0002040E SetFileApisToOEM
 664 0001B36A SetFileAttributesA
 665 0001B386 SetFileAttributesW
 666 0001D7CC SetFilePointer
 667 00001C2A SetFilePointerEx
 668 0001E638 SetFileTime
 669 0001154E SetHandleCount
 670 00022FBB SetHandleInformation
 671 00045C06 SetInformationJobObject
 672 00049FFE SetLastConsoleEventActive
 673 000148AB SetLastError
 674 00029F44 SetLocalTime
 675 0001F16C SetLocaleInfoA
 676 0001F1D5 SetLocaleInfoW
 677 00013914 SetMailslotInfo
 678 000382D1 SetMessageWaitingIndicator
 679 00009AD9 SetNamedPipeHandleState
 680 00020AA2 SetPriorityClass
 681 0003984F SetProcessAffinityMask
 682 0001F05E SetProcessPriorityBoost
 683 00002F71 SetProcessShutdownParameters
 684 0001DD9F SetProcessWorkingSetSize
 685 0000D089 SetStdHandle
 686 000381E3 SetSystemPowerState
 687 0000183D SetSystemTime
 688 000018EC SetSystemTimeAdjustment
 689 000458FA SetTapeParameters
 690 00045750 SetTapePosition
 691 0003A97F SetTermsrvAppInstallMode
 692 000175AB SetThreadAffinityMask
 693 0003BBEE SetThreadContext
 694 00009655 SetThreadExecutionState
 695 0003C0E9 SetThreadIdealProcessor
 696 0001CDA0 SetThreadLocale
 697 0001B593 SetThreadPriority
 698 0003BB35 SetThreadPriorityBoost
 699 0002D625 SetTimeZoneInformation
 700 0003C45B SetTimerQueueTimer
 701 0000BC57 SetUnhandledExceptionFilter
 702 0003F2C9 SetVDMCurrentDirectories
 703 00037DF1 SetVolumeLabelA
 704 00037E4E SetVolumeLabelW
 705 00041311 SetVolumeMountPointA
 706 0004163C SetVolumeMountPointW
 707 00017546 SetWaitableTimer
 708 0003E0F1 SetupComm
 709 000477CA ShowConsoleCursor
 710 0003A468 SignalObjectAndWait
 711 0001504C SizeofResource
 712 0001AC6E Sleep
 713 0001AC7C SleepEx
 714 0003BC10 SuspendThread
 715 0001F93F SwitchToFiber
 716 0003C15D SwitchToThread
 717 00009B45 SystemTimeToFileTime
 718 0002D788 SystemTimeToTzSpecificLocalTime
 719 00045B18 TerminateJobObject
 720 00038DC3 TerminateProcess
 721 00017584 TerminateThread
 722 0003A96D TermsrvAppInstallMode
 723 0003CC2A Thread32First
 724 0003CCDB Thread32Next
 725 0000D279 TlsAlloc
 726 0000EA53 TlsFree
 727 00015D42 TlsGetValue
 728 0000A8C5 TlsSetValue
 729 0003C927 Toolhelp32ReadProcessMemory
 730 0000AB4F TransactNamedPipe
 731 0003EE87 TransmitCommChar
 732 00035E98 TrimVirtualBuffer
 733          TryEnterCriticalSection => NTDLL.RtlTryEnterCriticalSection
 734 00036D3F UTRegister
 735 00036D77 UTUnRegister
 736 0003BD2B UnhandledExceptionFilter
 737 00010538 UnlockFile
 738 00010570 UnlockFileEx
 739 00006135 UnmapViewOfFile
 740 00049C2E UnregisterConsoleIME
 741 000030D0 UnregisterWait
 742 00020F32 UnregisterWaitEx
 743 00042512 UpdateResourceA
 744 00042428 UpdateResourceW
 745 0004A0CC VDMConsoleOperation
 746 0003F0D8 VDMOperationStarted
 747 00023123 ValidateLCType
 748 00015E41 ValidateLocale
 749 0004C173 VerLanguageNameA
 750 0004C129 VerLanguageNameW
 751          VerSetConditionMask => NTDLL.VerSetConditionMask
 752 00019FF4 VerifyConsoleIoHandle
 753 000027B6 VerifyVersionInfoA
 754 00007304 VerifyVersionInfoW
 755 0001175C VirtualAlloc
 756 00011776 VirtualAllocEx
 757 00035EB1 VirtualBufferExceptionHandler
 758 0001E2DC VirtualFree
 759 0001E2F3 VirtualFreeEx
 760 000025AE VirtualLock
 761 0001C0F8 VirtualProtect
 762 0001C112 VirtualProtectEx
 763 0001A14C VirtualQuery
 764 0001A163 VirtualQueryEx
 765 00016C44 VirtualUnlock
 766 0003EF06 WaitCommEvent
 767 0002DB7E WaitForDebugEvent
 768 0001ABE4 WaitForMultipleObjects
 769 0000BD39 WaitForMultipleObjectsEx
 770 00011B0C WaitForSingleObject
 771 0001C468 WaitForSingleObjectEx
 772 0003757C WaitNamedPipeA
 773 00002962 WaitNamedPipeW
 774 0000A994 WideCharToMultiByte
 775 00009C1D WinExec
 776 0001C3FE WriteConsoleA
 777 00047F26 WriteConsoleInputA
 778 00047C8C WriteConsoleInputVDMA
 779 00047CA8 WriteConsoleInputVDMW
 780 00047F42 WriteConsoleInputW
 781 0004839D WriteConsoleOutputA
 782 000486E1 WriteConsoleOutputAttribute
 783 000486A3 WriteConsoleOutputCharacterA
 784 000486C2 WriteConsoleOutputCharacterW
 785 00048380 WriteConsoleOutputW
 786 0000C0C0 WriteConsoleW
 787 0001C24E WriteFile
 788 00030DA8 WriteFileEx
 789 00030EED WriteFileGather
 790 0000198E WritePrivateProfileSectionA
 791 0002F159 WritePrivateProfileSectionW
 792 0000A869 WritePrivateProfileStringA
 793 0001CCB6 WritePrivateProfileStringW
 794 0002ED41 WritePrivateProfileStructA
 795 0002EE40 WritePrivateProfileStructW
 796 00017303 WriteProcessMemory
 797 0000197C WriteProfileSectionA
 798 0002EF67 WriteProfileSectionW
 799 00023353 WriteProfileStringA
 800 0001CCA0 WriteProfileStringW
 801 00045872 WriteTapemark
 802 00010F74 _hread
 803 0001F332 _hwrite
 804 0000A8F1 _lclose
 805 00022ACF _lcreat
 806 0000997F _llseek
 807 0001CDD5 _lopen
 808 00010F74 _lread
 809 0001F332 _lwrite
 810 0001DF5C lstrcat
 811 0001DF5C lstrcatA
 812 0000A22C lstrcatW
 813 0001D453 lstrcmp
 814 0001D453 lstrcmpA
 815 0001D141 lstrcmpW
 816 00006A6C lstrcmpi
 817 00006A6C lstrcmpiA
 818 0001A18D lstrcmpiW
 819 0001E471 lstrcpy
 820 0001E471 lstrcpyA
 821 00008FFC lstrcpyW
 822 0000FA6D lstrcpyn
 823 0000FA6D lstrcpynA
 824 0000BE4E lstrcpynW
 825 00015D89 lstrlen
 826 00015D89 lstrlenA
 827 0000D20C lstrlenW

ntdll.dll 정보

// ntdll.dll
   1 000213CD PropertyLengthAsVariant
   2 00021336 RtlConvertPropertyToVariant
   3 00021296 RtlConvertVariantToProperty
   4 0003C7B6 RtlUlongByteSwap
   5 0003C7BB RtlUlonglongByteSwap
   6 0003C7B1 RtlUshortByteSwap
   7 00012D38 CsrAllocateCaptureBuffer
   8 0000E6DA CsrAllocateMessagePointer
   9 00009778 CsrCaptureMessageBuffer
  10 0001652A CsrCaptureMessageString
  11 0001BA35 CsrCaptureTimeout
  12 0000917D CsrClientCallServer
  13 000100CA CsrClientConnectToServer
  14 0000E6C6 CsrFreeCaptureBuffer
  15 0001B96A CsrIdentifyAlertableThread
  16 00004BCC CsrNewThread
  17 0001BAA7 CsrProbeForRead
  18 0001BA5F CsrProbeForWrite
  19 0001B999 CsrSetPriorityClass
  20 0002144B DbgBreakPoint
  21 00018C08 DbgPrint
  22 00021504 DbgPrintReturnControlC
  23 0002158D DbgPrompt
  24 0001BD9F DbgSsHandleKmApiMsg
  25 0001BD59 DbgSsInitialize
  26 0001BFDC DbgUiConnectToDbg
  27 0001C1B3 DbgUiContinue
  28 0001C0CC DbgUiWaitStateChange
  29 0002144D DbgUserBreakPoint
  30 00021644 KiRaiseUserExceptionDispatcher
  31 000215CC KiUserApcDispatcher
  32 000215DC KiUserCallbackDispatcher
  33 000215F8 KiUserExceptionDispatcher
  34 00012577 LdrAccessResource
  35 00006A42 LdrAlternateResourcesEnabled
  36 00008A24 LdrDisableThreadCalloutsForDll
  37 000218E7 LdrEnumResources
  38 000216DE LdrFindEntryForAddress
  39 0001640C LdrFindResourceDirectory_U
  40 00007134 LdrFindResource_U
  41 00001278 LdrFlushAlternateResourceModules
  42 00011C8C LdrGetDllHandle
  43 00012B73 LdrGetProcedureAddress
  44 00004AF2 LdrInitializeThunk
  45 00006A6F LdrLoadAlternateResourceModule
  46 00003261 LdrLoadDll
  47 0000679D LdrProcessRelocationBlock
  48 000112C9 LdrQueryImageFileExecutionOptions
  49 0001DF85 LdrQueryProcessModuleInformation
  50 0000DD8E LdrShutdownProcess
  51 0000E42E LdrShutdownThread
  52 0000CBAE LdrUnloadAlternateResourceModule
  53 0000B5DF LdrUnloadDll
  54 0001DDF5 LdrVerifyImageMatchesChecksum
  55 000465B4 NPXEMULATORTABLE
  56 0004FF22 NlsAnsiCodePage
  57 0004F314 NlsMbCodePageTag
  58 0004F318 NlsMbOemCodePageTag
  59 0000F610 NtAcceptConnectPort
  60 00016066 NtAccessCheck
  61 00005E52 NtAccessCheckAndAuditAlarm
  62 0001650E NtAccessCheckByType
  63 0000F9C8 NtAccessCheckByTypeAndAuditAlarm
  64 0001AFDD NtAccessCheckByTypeResultList
  65 0001AFEB NtAccessCheckByTypeResultListAndAuditAlarm
  66 0001AFF9 NtAccessCheckByTypeResultListAndAuditAlarmByHandle
  67 0000E50B NtAddAtom
  68 0001B007 NtAdjustGroupsToken
  69 00008816 NtAdjustPrivilegesToken
  70 0001B015 NtAlertResumeThread
  71 0000CD6F NtAlertThread
  72 0001558D NtAllocateLocallyUniqueId
  73 0001B023 NtAllocateUserPhysicalPages
  74 0001B031 NtAllocateUuids
  75 00015459 NtAllocateVirtualMemory
  76 0001B03F NtAreMappedFilesTheSame
  77 0001B04D NtAssignProcessToJobObject
  78 0000CD99 NtCallbackReturn
  79 0001B06C NtCancelDeviceWakeupRequest
  80 0001B05E NtCancelIoFile
  81 00008C51 NtCancelTimer
  82 0000C6A4 NtClearEvent
  83 00004D93 NtClose
  84 00003679 NtCloseObjectAuditAlarm
  85 0000F61E NtCompleteConnectPort
  86 0000E57A NtConnectPort
  87 00008553 NtContinue
  88 0001B486 NtCreateChannel
  89 0001B07D NtCreateDirectoryObject
  90 00009FFD NtCreateEvent
  91 0001B08B NtCreateEventPair
  92 0000F9BA NtCreateFile
  93 00005EB6 NtCreateIoCompletion
  94 0001B099 NtCreateJobObject
  95 00007E08 NtCreateKey
  96 000024B1 NtCreateMailslotFile
  97 00007E16 NtCreateMutant
  98 0001651C NtCreateNamedPipeFile
  99 0001B0A7 NtCreatePagingFile
 100 00005EC4 NtCreatePort
 101 00003B9E NtCreateProcess
 102 0001B0B5 NtCreateProfile
 103 000135BF NtCreateSection
 104 0000B153 NtCreateSemaphore
 105 0000FA3D NtCreateSymbolicLinkObject
 106 000127AE NtCreateThread
 107 000169D5 NtCreateTimer
 108 00016BCD NtCreateToken
 109 0001B0C3 NtCreateWaitablePort
 110 00023AC7 NtCurrentTeb
 111 00009153 NtDelayExecution
 112 000037D5 NtDeleteAtom
 113 0001B0D1 NtDeleteFile
 114 000077CA NtDeleteKey
 115 000010A5 NtDeleteObjectAuditAlarm
 116 00009D81 NtDeleteValueKey
 117 000150D4 NtDeviceIoControlFile
 118 0001B0DF NtDisplayString
 119 00007724 NtDuplicateObject
 120 00015AE8 NtDuplicateToken
 121 0000C394 NtEnumerateKey
 122 00014A5A NtEnumerateValueKey
 123 0001B0ED NtExtendSection
 124 0001B0FB NtFilterToken
 125 0000EBA6 NtFindAtom
 126 0001570D NtFlushBuffersFile
 127 00014940 NtFlushInstructionCache
 128 000023B5 NtFlushKey
 129 0000A419 NtFlushVirtualMemory
 130 0001B109 NtFlushWriteBuffer
 131 0001B115 NtFreeUserPhysicalPages
 132 0000EC81 NtFreeVirtualMemory
 133 00007126 NtFsControlFile
 134 00016BDB NtGetContextThread
 135 0001B123 NtGetDevicePowerState
 136 000024BF NtGetPlugPlayEvent
 137 0001B131 NtGetTickCount
 138 0001B13D NtGetWriteWatch
 139 0001B14B NtImpersonateAnonymousToken
 140 00009D39 NtImpersonateClientOfPort
 141 00004DA1 NtImpersonateThread
 142 0001B159 NtInitializeRegistry
 143 0001B167 NtInitiatePowerAction
 144 0001B175 NtIsSystemResumeAutomatic
 145 0001B494 NtListenChannel
 146 0001B181 NtListenPort
 147 0001B18F NtLoadDriver
 148 0001B19D NtLoadKey2
 149 00016BE9 NtLoadKey
 150 0000BF81 NtLockFile
 151 000010B3 NtLockVirtualMemory
 152 000087DC NtMakeTemporaryObject
 153 0001B1AB NtMapUserPhysicalPages
 154 0001B1B9 NtMapUserPhysicalPagesScatter
 155 0000AE4F NtMapViewOfSection
 156 00006C1A NtNotifyChangeDirectoryFile
 157 00006CFA NtNotifyChangeKey
 158 00016BF7 NtNotifyChangeMultipleKeys
 159 0001B4A2 NtOpenChannel
 160 00009D8F NtOpenDirectoryObject
 161 0001149E NtOpenEvent
 162 0001B1C7 NtOpenEventPair
 163 00015337 NtOpenFile
 164 0001B1D5 NtOpenIoCompletion
 165 0001B1E3 NtOpenJobObject
 166 000061CC NtOpenKey
 167 00014AA4 NtOpenMutant
 168 00005B01 NtOpenObjectAuditAlarm
 169 000023C3 NtOpenProcess
 170 0000E717 NtOpenProcessToken
 171 00008AEC NtOpenSection
 172 0001255F NtOpenSemaphore
 173 00006151 NtOpenSymbolicLinkObject
 174 000024CD NtOpenThread
 175 00001EB3 NtOpenThreadToken
 176 0001B1F1 NtOpenTimer
 177 00001F74 NtPlugPlayControl
 178 00016C05 NtPowerInformation
 179 000165D5 NtPrivilegeCheck
 180 0001B1FF NtPrivilegeObjectAuditAlarm
 181 000010C1 NtPrivilegedServiceAuditAlarm
 182 0000BFC4 NtProtectVirtualMemory
 183 00016C13 NtPulseEvent
 184 00009FEF NtQueryAttributesFile
 185 0000E964 NtQueryDefaultLocale
 186 000051D0 NtQueryDefaultUILanguage
 187 00005510 NtQueryDirectoryFile
 188 00016C21 NtQueryDirectoryObject
 189 0001B20D NtQueryEaFile
 190 0001285D NtQueryEvent
 191 0001346B NtQueryFullAttributesFile
 192 000148F0 NtQueryInformationAtom
 193 0000F6AF NtQueryInformationFile
 194 00003BAC NtQueryInformationJobObject
 195 0001B21B NtQueryInformationPort
 196 00013351 NtQueryInformationProcess
 197 00008571 NtQueryInformationThread
 198 00005B0F NtQueryInformationToken
 199 0000455F NtQueryInstallUILanguage
 200 0001B229 NtQueryIntervalProfile
 201 0000BD4F NtQueryIoCompletion
 202 00007EBB NtQueryKey
 203 0001B237 NtQueryMultipleValueKey
 204 0001B245 NtQueryMutant
 205 000107D8 NtQueryObject
 206 0001B253 NtQueryOpenSubKeys
 207 000152DD NtQueryPerformanceCounter
 208 0001B261 NtQueryQuotaInformationFile
 209 000112BB NtQuerySection
 210 000038C7 NtQuerySecurityObject
 211 0001B26F NtQuerySemaphore
 212 00005EA8 NtQuerySymbolicLinkObject
 213 0001B27D NtQuerySystemEnvironmentValue
 214 00007D11 NtQuerySystemInformation
 215 000148E2 NtQuerySystemTime
 216 00011775 NtQueryTimer
 217 0000CBA0 NtQueryTimerResolution
 218 000062D2 NtQueryValueKey
 219 00015AA3 NtQueryVirtualMemory
 220 0000E588 NtQueryVolumeInformationFile
 221 0000366B NtQueueApcThread
 222 00014B92 NtRaiseException
 223 0001B28E NtRaiseHardError
 224 0000C552 NtReadFile
 225 0001B29C NtReadFileScatter
 226 0000F6A1 NtReadRequestData
 227 0000DEE6 NtReadVirtualMemory
 228 00004BB2 NtRegisterThreadTerminatePort
 229 00015475 NtReleaseMutant
 230 00008E81 NtReleaseSemaphore
 231 0000BEA7 NtRemoveIoCompletion
 232 0001B2AA NtReplaceKey
 233 0000E596 NtReplyPort
 234 00009161 NtReplyWaitReceivePort
 235 000039BC NtReplyWaitReceivePortEx
 236 0001B2B8 NtReplyWaitReplyPort
 237 0001B4B0 NtReplyWaitSendChannel
 238 0001B2C6 NtRequestDeviceWakeup
 239 00005290 NtRequestPort
 240 0000916F NtRequestWaitReplyPort
 241 0001B2D4 NtRequestWakeupLatency
 242 00016C2F NtResetEvent
 243 0001B2E2 NtResetWriteWatch
 244 0001B2F0 NtRestoreKey
 245 00008FB7 NtResumeThread
 246 00016C3D NtSaveKey
 247 0001B2FE NtSaveMergedKeys
 248 0000808A NtSecureConnectPort
 249 0001B4BE NtSendWaitReplyChannel
 250 0001B4CC NtSetContextChannel
 251 00016C4B NtSetContextThread
 252 0001B30C NtSetDefaultHardErrorPort
 253 0001B31A NtSetDefaultLocale
 254 0001B328 NtSetDefaultUILanguage
 255 0001B336 NtSetEaFile
 256 00008563 NtSetEvent
 257 0001B344 NtSetHighEventPair
 258 0001B352 NtSetHighWaitLowEventPair
 259 0000EE28 NtSetInformationFile
 260 0001B360 NtSetInformationJobObject
 261 0001B36E NtSetInformationKey
 262 000107E6 NtSetInformationObject
 263 00013B6D NtSetInformationProcess
 264 0000A1E0 NtSetInformationThread
 265 00016C59 NtSetInformationToken
 266 0001B37C NtSetIntervalProfile
 267 000086C0 NtSetIoCompletion
 268 00016C67 NtSetLdtEntries
 269 0001B38A NtSetLowEventPair
 270 0001B398 NtSetLowWaitHighEventPair
 271 0001B3A6 NtSetQuotaInformationFile
 272 00011F97 NtSetSecurityObject
 273 0001B3B4 NtSetSystemEnvironmentValue
 274 000010CF NtSetSystemInformation
 275 0001B3C2 NtSetSystemPowerState
 276 000010DD NtSetSystemTime
 277 0000C1DA NtSetThreadExecutionState
 278 00008C5F NtSetTimer
 279 00018958 NtSetTimerResolution
 280 0001B3D0 NtSetUuidSeed
 281 0000AA1B NtSetValueKey
 282 0001B3DE NtSetVolumeInformationFile
 283 0001B3EC NtShutdownSystem
 284 0001B3FA NtSignalAndWaitForSingleObject
 285 0001B408 NtStartProfile
 286 0001B416 NtStopProfile
 287 0001B424 NtSuspendThread
 288 0001B432 NtSystemDebugControl
 289 0001B440 NtTerminateJobObject
 290 0000DD80 NtTerminateProcess
 291 0000DFC2 NtTerminateThread
 292 00004BC0 NtTestAlert
 293 0001B44E NtUnloadDriver
 294 00016C75 NtUnloadKey
 295 00010312 NtUnlockFile
 296 000024DB NtUnlockVirtualMemory
 297 0000A3D8 NtUnmapViewOfSection
 298 00016C83 NtVdmControl
 299 00013233 NtWaitForMultipleObjects
 300 00014086 NtWaitForSingleObject
 301 0001B45C NtWaitHighEventPair
 302 0001B46A NtWaitLowEventPair
 303 000023A7 NtWriteFile
 304 0001B478 NtWriteFileGather
 305 0000816A NtWriteRequestData
 306 0000815C NtWriteVirtualMemory
 307 00012445 NtYieldExecution
 308 00023C36 PfxFindPrefix
 309 00023ACE PfxInitialize
 310 00023AE2 PfxInsertPrefix
 311 00023BBA PfxRemovePrefix
 312 0004A215 RestoreEm87Context
 313 00016E81 RtlAbortRXact
 314 0000A2E0 RtlAbsoluteToSelfRelativeSD
 315 0000C258 RtlAcquirePebLock
 316 00008098 RtlAcquireResourceExclusive
 317 00008D24 RtlAcquireResourceShared
 318 00009C9C RtlAddAccessAllowedAce
 319 000170C1 RtlAddAccessAllowedAceEx
 320 000249B3 RtlAddAccessAllowedObjectAce
 321 000014A2 RtlAddAccessDeniedAce
 322 00024938 RtlAddAccessDeniedAceEx
 323 000249F9 RtlAddAccessDeniedObjectAce
 324 000025A9 RtlAddAce
 325 000241C4 RtlAddActionToRXact
 326 00014D6D RtlAddAtomToAtomTable
 327 00016EBA RtlAddAttributeActionToRXact
 328 00024955 RtlAddAuditAccessAce
 329 00024982 RtlAddAuditAccessAceEx
 330 00024A40 RtlAddAuditAccessObjectAce
 331 000246B6 RtlAddCompoundAce
 332 0004D817 RtlAddRange
 333 000027E1 RtlAdjustPrivilege
 334 000042B0 RtlAllocateAndInitializeSid
 335 000089B1 RtlAllocateHandle
 336 0004C2AD RtlAllocateHeap
 337 000148FE RtlAnsiCharToUnicodeChar
 338 000286AD RtlAnsiStringToUnicodeSize
 339 000114AC RtlAnsiStringToUnicodeString
 340 00001739 RtlAppendAsciizToString
 341 00028C4F RtlAppendStringToString
 342 0000BEB5 RtlAppendUnicodeStringToString
 343 00011E2C RtlAppendUnicodeToString
 344 000241FE RtlApplyRXact
 345 00016FDA RtlApplyRXactNoFlush
 346 0000551E RtlAreAllAccessesGranted
 347 00025434 RtlAreAnyAccessesGranted
 348 0002948B RtlAreBitsClear
 349 00006B32 RtlAreBitsSet
 350 000298DD RtlAssert
 351 0001E7BA RtlCallbackLpcClient
 352 0002B0B6 RtlCancelTimer
 353 0002B447 RtlCaptureStackBackTrace
 354 0000E5A4 RtlCharToInteger
 355 00021448 RtlCheckForOrphanedCriticalSections
 356 0002C841 RtlCheckRegistryKey
 357 0001742C RtlClearAllBits
 358 00006AE0 RtlClearBits
 359 00010701 RtlCompactHeap
 360 0000529E RtlCompareMemory
 361 00011961 RtlCompareMemoryUlong
 362 00028B57 RtlCompareString
 363 0000AF43 RtlCompareUnicodeString
 364 0002ECEC RtlCompressBuffer
 365 000091F2 RtlConsoleMultiByteToUnicodeN
 366 00016D07 RtlConvertExclusiveToShared
 367 000169FA RtlConvertLongToLargeInteger
 368 00016CC8 RtlConvertSharedToExclusive
 369 0000A6D5 RtlConvertSidToUnicodeString
 370 0001F770 RtlConvertToAutoInheritSecurityObject
 371 0001F9A8 RtlConvertUiListToApiList
 372 0003C97E RtlConvertUlongToLargeInteger
 373 0000B5BC RtlCopyLuid
 374 00025231 RtlCopyLuidAndAttributesArray
 375 0004E0BE RtlCopyRangeList
 376 0001F333 RtlCopySecurityDescriptor
 377 00009CB8 RtlCopySid
 378 00025114 RtlCopySidAndAttributesArray
 379 00002949 RtlCopyString
 380 0000EC8F RtlCopyUnicodeString
 381 0000F857 RtlCreateAcl
 382 0001F462 RtlCreateAndSetSD
 383 0000AABF RtlCreateAtomTable
 384 000179CA RtlCreateEnvironment
 385 0004B425 RtlCreateHeap
 386 0001E5A9 RtlCreateLpcServer
 387 00003CCB RtlCreateProcessParameters
 388 0001FFBA RtlCreateQueryDebugBuffer
 389 0002C867 RtlCreateRegistryKey
 390 0000F96F RtlCreateSecurityDescriptor
 391 00011388 RtlCreateTagHeap
 392 0000FE89 RtlCreateTimer
 393 000174C0 RtlCreateTimerQueue
 394 000125AB RtlCreateUnicodeString
 395 000110F0 RtlCreateUnicodeStringFromAsciiz
 396 0002F2BC RtlCreateUserProcess
 397 0001F6FE RtlCreateUserSecurityObject
 398 0002F671 RtlCreateUserThread
 399 00022EA5 RtlCustomCPToUnicodeN
 400 0002F788 RtlCutoverTimeToSystemTime
 401 00003F82 RtlDeNormalizeProcessParams
 402 0002AEF4 RtlDebugPrintTimes
 403 0002ED40 RtlDecompressBuffer
 404 0002ED85 RtlDecompressFragment
 405 0001F78E RtlDefaultNpAcl
 406 0001886A RtlDelete
 407 00001445 RtlDeleteAce
 408 00014EB2 RtlDeleteAtomFromAtomTable
 409 00007BF9 RtlDeleteCriticalSection
 410 000188AF RtlDeleteElementGenericTable
 411 0002FC28 RtlDeleteNoSplay
 412 0004DE5D RtlDeleteOwnersRanges
 413 0004DD1C RtlDeleteRange
 414 0002C88D RtlDeleteRegistryValue
 415 000011DE RtlDeleteResource
 416 0000CD4E RtlDeleteSecurityObject
 417 0000437C RtlDeleteTimer
 418 00029CE6 RtlDeleteTimerQueue
 419 00029D7E RtlDeleteTimerQueueEx
 420 0000721E RtlDeregisterWait
 421 0000722C RtlDeregisterWaitEx
 422 00024AFA RtlDestroyAtomTable
 423 00003CAB RtlDestroyEnvironment
 424 00027AE7 RtlDestroyHandleTable
 425 0004B16C RtlDestroyHeap
 426 00003CAB RtlDestroyProcessParameters
 427 0002009B RtlDestroyQueryDebugBuffer
 428 00006BD6 RtlDetermineDosPathNameType_U
 429 000289BB RtlDnsHostNameToComputerName
 430 00003454 RtlDoesFileExists_U
 431 00011982 RtlDosPathNameToNtPathName_U
 432 0000ED36 RtlDosSearchPath_U
 433 00005480 RtlDowncaseUnicodeString
 434 0001ECF3 RtlDumpResource
 435 00024BD4 RtlEmptyAtomTable
 436 0001ED36 RtlEnableEarlyCriticalSectionEventCreation
 437 0003C84D RtlEnlargedIntegerMultiply
 438 0003C863 RtlEnlargedUnsignedDivide
 439 0003C858 RtlEnlargedUnsignedMultiply
 440 00009103 RtlEnterCriticalSection
 441 0002DA86 RtlEnumProcessHeaps
 442 0002FED7 RtlEnumerateGenericTable
 443 0002FF76 RtlEnumerateGenericTableWithoutSplaying
 444 00009AD9 RtlEqualComputerName
 445 000030E8 RtlEqualDomainName
 446 00025211 RtlEqualLuid
 447 000107F4 RtlEqualPrefixSid
 448 0000810F RtlEqualSid
 449 0000A18F RtlEqualString
 450 00015523 RtlEqualUnicodeString
 451 0002506A RtlEraseUnicodeString
 452 00009DA4 RtlExpandEnvironmentStrings_U
 453 0002D70D RtlExtendHeap
 454 0000361D RtlExtendedIntegerMultiply
 455 0001854E RtlExtendedLargeIntegerDivide
 456 0000BDA7 RtlExtendedMagicDivide
 457 0003C7C4 RtlFillMemory
 458 00018538 RtlFillMemoryUlong
 459 00008903 RtlFindClearBits
 460 0000897A RtlFindClearBitsAndSet
 461 0002962D RtlFindLastBackwardRunClear
 462 00029796 RtlFindLeastSignificantBit
 463 000293CA RtlFindLongestRunClear
 464 00006226 RtlFindMessage
 465 000296F8 RtlFindMostSignificantBit
 466 00029542 RtlFindNextForwardRunClear
 467 0004E30C RtlFindRange
 468 00028E18 RtlFindSetBits
 469 000290BF RtlFindSetBitsAndClear
 470 0000F93B RtlFirstFreeAce
 471 000161BC RtlFormatCurrentUserKeyPath
 472 00009F47 RtlFormatMessage
 473 0001329F RtlFreeAnsiString
 474 000037E3 RtlFreeHandle
 475 0004C7D3 RtlFreeHeap
 476 0000F7B4 RtlFreeOemString
 477 0004E181 RtlFreeRangeList
 478 00004332 RtlFreeSid
 479 0001329F RtlFreeUnicodeString
 480 0002F726 RtlFreeUserThreadStack
 481 00030329 RtlGUIDFromString
 482 000304D4 RtlGenerate8dot3Name
 483 000117E4 RtlGetAce
 484 0002B0F2 RtlGetCallersAddress
 485 0002ECA8 RtlGetCompressionWorkSpaceSize
 486 00005F92 RtlGetControlSecurityDescriptor
 487 0000B385 RtlGetCurrentDirectory_U
 488 00013241 RtlGetDaclSecurityDescriptor
 489 00018B4D RtlGetElementGenericTable
 490 0004E485 RtlGetFirstRange
 491 0000C127 RtlGetFullPathName_U
 492 00011712 RtlGetGroupSecurityDescriptor
 493 0001526E RtlGetLongestNtPathLength
 494 0004E4D9 RtlGetNextRange
 495 0000495C RtlGetNtGlobalFlags
 496 00008058 RtlGetNtProductType
 497 000116D9 RtlGetOwnerSecurityDescriptor
 498 00002ACA RtlGetProcessHeaps
 499 0002539B RtlGetSaclSecurityDescriptor
 500 00027AA0 RtlGetSecurityDescriptorRMControl
 501 00010F8A RtlGetUserInfoHeap
 502 00003034 RtlGetVersion
 503 00017193 RtlIdentifierAuthoritySid
 504 00012237 RtlImageDirectoryEntryToData
 505 000101F2 RtlImageNtHeader
 506 00013146 RtlImageRvaToSection
 507 00031150 RtlImageRvaToVa
 508 0001E7A7 RtlImpersonateLpcClient
 509 0000F7C9 RtlImpersonateSelf
 510 0000FFC3 RtlInitAnsiString
 511 000059D6 RtlInitCodePageTable
 512 00003B15 RtlInitNlsTables
 513 00010F30 RtlInitString
 514 0001566D RtlInitUnicodeString
 515 00003C9D RtlInitializeAtomPackage
 516 00005A97 RtlInitializeBitMap
 517 000311C0 RtlInitializeContext
 518 00015749 RtlInitializeCriticalSection
 519 000047F3 RtlInitializeCriticalSectionAndSpinCount
 520 0002FE18 RtlInitializeGenericTable
 521 0000421E RtlInitializeHandleTable
 522 00023E8C RtlInitializeRXact
 523 0004D800 RtlInitializeRangeList
 524 0000CA94 RtlInitializeResource
 525 0000E4E1 RtlInitializeSid
 526 00017AD2 RtlInsertElementGenericTable
 527 0002BC00 RtlInt64ToUnicodeString
 528 00013B7B RtlIntegerToChar
 529 00005CAB RtlIntegerToUnicodeString
 530 0004E653 RtlInvertRangeList
 531 000030C2 RtlIsDosDeviceName_U
 532 00018B3F RtlIsGenericTableEmpty
 533 00017C10 RtlIsNameLegalDOS8Dot3
 534 0004E1BC RtlIsRangeAvailable
 535 00013E34 RtlIsTextUnicode
 536 00010688 RtlIsValidHandle
 537 0001507C RtlIsValidIndexHandle
 538 0003C83A RtlLargeIntegerAdd
 539 0003C92E RtlLargeIntegerArithmeticShift
 540 000313B9 RtlLargeIntegerDivide
 541 0003C959 RtlLargeIntegerNegate
 542 0003C8E0 RtlLargeIntegerShiftLeft
 543 0003C907 RtlLargeIntegerShiftRight
 544 0003C96B RtlLargeIntegerSubtract
 545 0002B826 RtlLargeIntegerToChar
 546 00009134 RtlLeaveCriticalSection
 547 0000C68E RtlLengthRequiredSid
 548 00008FF6 RtlLengthSecurityDescriptor
 549 0000E2CB RtlLengthSid
 550 0002FA9A RtlLocalTimeToSystemTime
 551 0000C837 RtlLockHeap
 552 000026A7 RtlLookupAtomInAtomTable
 553 0002FE82 RtlLookupElementGenericTable
 554 0000A1EE RtlMakeSelfRelativeSD
 555 0000BE24 RtlMapGenericMask
 556 0004E572 RtlMergeRangeLists
 557 00001C66 RtlMoveMemory
 558 000078A1 RtlMultiByteToUnicodeN
 559 00004C66 RtlMultiByteToUnicodeSize
 560 0001F193 RtlNewInstanceSecurityObject
 561 0001F202 RtlNewSecurityGrantedAccess
 562 00001256 RtlNewSecurityObject
 563 0000FA4B RtlNewSecurityObjectEx
 564 00003A8A RtlNormalizeProcessParams
 565 0000D02E RtlNtStatusToDosError
 566 0002FF6C RtlNumberGenericTableElements
 567 000293FA RtlNumberOfClearBits
 568 00029440 RtlNumberOfSetBits
 569 000286AD RtlOemStringToUnicodeSize
 570 000052E6 RtlOemStringToUnicodeString
 571 00005361 RtlOemToUnicodeN
 572 0000313E RtlOpenCurrentUser
 573 00031526 RtlPcToFileHeader
 574 00024E99 RtlPinAtomInAtomTable
 575 00018980 RtlPrefixString
 576 0000ACE6 RtlPrefixUnicodeString
 577 0002CBC5 RtlProtectHeap
 578 00014F83 RtlQueryAtomInAtomTable
 579 0000B181 RtlQueryEnvironmentVariable_U
 580 0000253A RtlQueryInformationAcl
 581 00020363 RtlQueryProcessBackTraceInformation
 582 0002015F RtlQueryProcessDebugInformation
 583 0002055A RtlQueryProcessHeapInformation
 584 00020A3E RtlQueryProcessLockInformation
 585 0002C420 RtlQueryRegistryValues
 586 0001EF7F RtlQuerySecurityObject
 587 0002D5A2 RtlQueryTagHeap
 588 0002C939 RtlQueryTimeZoneInformation
 589 00013D6F RtlQueueWorkItem
 590 000316C8 RtlRaiseException
 591 00031780 RtlRaiseStatus
 592 00001B06 RtlRandom
 593 00012025 RtlReAllocateHeap
 594 0002FD08 RtlRealPredecessor
 595 0002FCD7 RtlRealSuccessor
 596 00007150 RtlRegisterWait
 597 0000C268 RtlReleasePebLock
 598 0000857F RtlReleaseResource
 599 00031275 RtlRemoteCall
 600 00003BBA RtlResetRtlTranslations
 601 000027A9 RtlRunDecodeUnicodeString
 602 00002741 RtlRunEncodeUnicodeString
 603 0002FA6A RtlSecondsSince1970ToTime
 604 0002FA33 RtlSecondsSince1980ToTime
 605 00024427 RtlSelfRelativeToAbsoluteSD2
 606 0000130F RtlSelfRelativeToAbsoluteSD
 607 00017453 RtlSetAllBits
 608 000252B2 RtlSetAttributesSecurityDescriptor
 609 00004EED RtlSetBits
 610 000252ED RtlSetControlSecurityDescriptor
 611 0000DD34 RtlSetCriticalSectionSpinCount
 612 00004F72 RtlSetCurrentDirectory_U
 613 0002EE40 RtlSetCurrentEnvironment
 614 00009CE4 RtlSetDaclSecurityDescriptor
 615 0000AFDB RtlSetEnvironmentVariable
 616 00002035 RtlSetGroupSecurityDescriptor
 617 0002461C RtlSetInformationAcl
 618 00029BD9 RtlSetIoCompletionCallback
 619 00001FF2 RtlSetOwnerSecurityDescriptor
 620 000028AE RtlSetSaclSecurityDescriptor
 621 00027AC3 RtlSetSecurityDescriptorRMControl
 622 0001EF3C RtlSetSecurityObject
 623 0001EF5D RtlSetSecurityObjectEx
 624 0000BC20 RtlSetThreadPoolStartFunc
 625 0002CA5A RtlSetTimeZoneInformation
 626 0002AFEB RtlSetTimer
 627 00021448 RtlSetUnicodeCallouts
 628 0002D260 RtlSetUserFlagsHeap
 629 00001EC1 RtlSetUserValueHeap
 630 0001E694 RtlShutdownLpcServer
 631 0004B906 RtlSizeHeap
 632 00018859 RtlSplay
 633 00016E35 RtlStartRXact
 634 00017BA1 RtlStringFromGUID
 635 00008154 RtlSubAuthorityCountSid
 636 000153A5 RtlSubAuthoritySid
 637 0002FCBC RtlSubtreePredecessor
 638 0002FCA1 RtlSubtreeSuccessor
 639 00004C87 RtlSystemTimeToLocalTime
 640 0000349A RtlTimeFieldsToTime
 641 0002F9AB RtlTimeToElapsedTimeFields
 642 00016629 RtlTimeToSecondsSince1970
 643 00005E60 RtlTimeToSecondsSince1980
 644 000081FE RtlTimeToTimeFields
 645 00031953 RtlTraceDatabaseAdd
 646 000317A8 RtlTraceDatabaseCreate
 647 000318BB RtlTraceDatabaseDestroy
 648 00031CE1 RtlTraceDatabaseEnumerate
 649 00031981 RtlTraceDatabaseFind
 650 00031C87 RtlTraceDatabaseLock
 651 00031C93 RtlTraceDatabaseUnlock
 652 00031913 RtlTraceDatabaseValidate
 653 0000A130 RtlTryEnterCriticalSection
 654 0002868F RtlUnicodeStringToAnsiSize
 655 0001335F RtlUnicodeStringToAnsiString
 656 000284D5 RtlUnicodeStringToCountedOemString
 657 0001246E RtlUnicodeStringToInteger
 658 0002868F RtlUnicodeStringToOemSize
 659 000031E2 RtlUnicodeStringToOemString
 660 0002308E RtlUnicodeToCustomCPN
 661 0000C6B2 RtlUnicodeToMultiByteN
 662 000102D8 RtlUnicodeToMultiByteSize
 663 00012EEA RtlUnicodeToOemN
 664 00006341 RtlUniform
 665 0000C872 RtlUnlockHeap
 666 0000EA4A RtlUnwind
 667 0000CC2C RtlUpcaseUnicodeChar
 668 0000B2AD RtlUpcaseUnicodeString
 669 000283DD RtlUpcaseUnicodeStringToAnsiString
 670 0001735D RtlUpcaseUnicodeStringToCountedOemString
 671 00003739 RtlUpcaseUnicodeStringToOemString
 672 00023235 RtlUpcaseUnicodeToCustomCPN
 673 00015788 RtlUpcaseUnicodeToMultiByteN
 674 00010320 RtlUpcaseUnicodeToOemN
 675 00002078 RtlUpdateTimer
 676 00012451 RtlUpperChar
 677 00028C07 RtlUpperString
 678 0002DB14 RtlUsageHeap
 679 0000F8A7 RtlValidAcl
 680 0002794F RtlValidRelativeSecurityDescriptor
 681 00005ED2 RtlValidSecurityDescriptor
 682 0000ED77 RtlValidSid
 683 00001C9F RtlValidateHeap
 684 0002D9C0 RtlValidateProcessHeaps
 685 00013C7F RtlVerifyVersionInfo
 686 0002B4E9 RtlWalkFrameChain
 687 0002E076 RtlWalkHeap
 688 0002C7EC RtlWriteRegistryValue
 689 0004E7E1 RtlZeroHeap
 690 0003C7F5 RtlZeroMemory
 691 00031E7F RtlpNtCreateKey
 692 00031EED RtlpNtEnumerateSubKey
 693 00031EE1 RtlpNtMakeTemporaryKey
 694 0000A05A RtlpNtOpenKey
 695 0000A077 RtlpNtQueryValueKey
 696 00031EBC RtlpNtSetValueKey
 697 000123AA RtlpUnWaitCriticalSection
 698 00012313 RtlpWaitForCriticalSection
 699 000286AD RtlxAnsiStringToUnicodeSize
 700 000286AD RtlxOemStringToUnicodeSize
 701 0002868F RtlxUnicodeStringToAnsiSize
 702 0002868F RtlxUnicodeStringToOemSize
 703 0004A1EC SaveEm87Context
 704 00013D37 VerSetConditionMask
 705 0000F610 ZwAcceptConnectPort
 706 00016066 ZwAccessCheck
 707 00005E52 ZwAccessCheckAndAuditAlarm
 708 0001650E ZwAccessCheckByType
 709 0000F9C8 ZwAccessCheckByTypeAndAuditAlarm
 710 0001AFDD ZwAccessCheckByTypeResultList
 711 0001AFEB ZwAccessCheckByTypeResultListAndAuditAlarm
 712 0001AFF9 ZwAccessCheckByTypeResultListAndAuditAlarmByHandle
 713 0000E50B ZwAddAtom
 714 0001B007 ZwAdjustGroupsToken
 715 00008816 ZwAdjustPrivilegesToken
 716 0001B015 ZwAlertResumeThread
 717 0000CD6F ZwAlertThread
 718 0001558D ZwAllocateLocallyUniqueId
 719 0001B023 ZwAllocateUserPhysicalPages
 720 0001B031 ZwAllocateUuids
 721 00015459 ZwAllocateVirtualMemory
 722 0001B03F ZwAreMappedFilesTheSame
 723 0001B04D ZwAssignProcessToJobObject
 724 0000CD99 ZwCallbackReturn
 725 0001B06C ZwCancelDeviceWakeupRequest
 726 0001B05E ZwCancelIoFile
 727 00008C51 ZwCancelTimer
 728 0000C6A4 ZwClearEvent
 729 00004D93 ZwClose
 730 00003679 ZwCloseObjectAuditAlarm
 731 0000F61E ZwCompleteConnectPort
 732 0000E57A ZwConnectPort
 733 00008553 ZwContinue
 734 0001B486 ZwCreateChannel
 735 0001B07D ZwCreateDirectoryObject
 736 00009FFD ZwCreateEvent
 737 0001B08B ZwCreateEventPair
 738 0000F9BA ZwCreateFile
 739 00005EB6 ZwCreateIoCompletion
 740 0001B099 ZwCreateJobObject
 741 00007E08 ZwCreateKey
 742 000024B1 ZwCreateMailslotFile
 743 00007E16 ZwCreateMutant
 744 0001651C ZwCreateNamedPipeFile
 745 0001B0A7 ZwCreatePagingFile
 746 00005EC4 ZwCreatePort
 747 00003B9E ZwCreateProcess
 748 0001B0B5 ZwCreateProfile
 749 000135BF ZwCreateSection
 750 0000B153 ZwCreateSemaphore
 751 0000FA3D ZwCreateSymbolicLinkObject
 752 000127AE ZwCreateThread
 753 000169D5 ZwCreateTimer
 754 00016BCD ZwCreateToken
 755 0001B0C3 ZwCreateWaitablePort
 756 00009153 ZwDelayExecution
 757 000037D5 ZwDeleteAtom
 758 0001B0D1 ZwDeleteFile
 759 000077CA ZwDeleteKey
 760 000010A5 ZwDeleteObjectAuditAlarm
 761 00009D81 ZwDeleteValueKey
 762 000150D4 ZwDeviceIoControlFile
 763 0001B0DF ZwDisplayString
 764 00007724 ZwDuplicateObject
 765 00015AE8 ZwDuplicateToken
 766 0000C394 ZwEnumerateKey
 767 00014A5A ZwEnumerateValueKey
 768 0001B0ED ZwExtendSection
 769 0001B0FB ZwFilterToken
 770 0000EBA6 ZwFindAtom
 771 0001570D ZwFlushBuffersFile
 772 00014940 ZwFlushInstructionCache
 773 000023B5 ZwFlushKey
 774 0000A419 ZwFlushVirtualMemory
 775 0001B109 ZwFlushWriteBuffer
 776 0001B115 ZwFreeUserPhysicalPages
 777 0000EC81 ZwFreeVirtualMemory
 778 00007126 ZwFsControlFile
 779 00016BDB ZwGetContextThread
 780 0001B123 ZwGetDevicePowerState
 781 000024BF ZwGetPlugPlayEvent
 782 0001B131 ZwGetTickCount
 783 0001B13D ZwGetWriteWatch
 784 0001B14B ZwImpersonateAnonymousToken
 785 00009D39 ZwImpersonateClientOfPort
 786 00004DA1 ZwImpersonateThread
 787 0001B159 ZwInitializeRegistry
 788 0001B167 ZwInitiatePowerAction
 789 0001B175 ZwIsSystemResumeAutomatic
 790 0001B494 ZwListenChannel
 791 0001B181 ZwListenPort
 792 0001B18F ZwLoadDriver
 793 0001B19D ZwLoadKey2
 794 00016BE9 ZwLoadKey
 795 0000BF81 ZwLockFile
 796 000010B3 ZwLockVirtualMemory
 797 000087DC ZwMakeTemporaryObject
 798 0001B1AB ZwMapUserPhysicalPages
 799 0001B1B9 ZwMapUserPhysicalPagesScatter
 800 0000AE4F ZwMapViewOfSection
 801 00006C1A ZwNotifyChangeDirectoryFile
 802 00006CFA ZwNotifyChangeKey
 803 00016BF7 ZwNotifyChangeMultipleKeys
 804 0001B4A2 ZwOpenChannel
 805 00009D8F ZwOpenDirectoryObject
 806 0001149E ZwOpenEvent
 807 0001B1C7 ZwOpenEventPair
 808 00015337 ZwOpenFile
 809 0001B1D5 ZwOpenIoCompletion
 810 0001B1E3 ZwOpenJobObject
 811 000061CC ZwOpenKey
 812 00014AA4 ZwOpenMutant
 813 00005B01 ZwOpenObjectAuditAlarm
 814 000023C3 ZwOpenProcess
 815 0000E717 ZwOpenProcessToken
 816 00008AEC ZwOpenSection
 817 0001255F ZwOpenSemaphore
 818 00006151 ZwOpenSymbolicLinkObject
 819 000024CD ZwOpenThread
 820 00001EB3 ZwOpenThreadToken
 821 0001B1F1 ZwOpenTimer
 822 00001F74 ZwPlugPlayControl
 823 00016C05 ZwPowerInformation
 824 000165D5 ZwPrivilegeCheck
 825 0001B1FF ZwPrivilegeObjectAuditAlarm
 826 000010C1 ZwPrivilegedServiceAuditAlarm
 827 0000BFC4 ZwProtectVirtualMemory
 828 00016C13 ZwPulseEvent
 829 00009FEF ZwQueryAttributesFile
 830 0000E964 ZwQueryDefaultLocale
 831 000051D0 ZwQueryDefaultUILanguage
 832 00005510 ZwQueryDirectoryFile
 833 00016C21 ZwQueryDirectoryObject
 834 0001B20D ZwQueryEaFile
 835 0001285D ZwQueryEvent
 836 0001346B ZwQueryFullAttributesFile
 837 000148F0 ZwQueryInformationAtom
 838 0000F6AF ZwQueryInformationFile
 839 00003BAC ZwQueryInformationJobObject
 840 0001B21B ZwQueryInformationPort
 841 00013351 ZwQueryInformationProcess
 842 00008571 ZwQueryInformationThread
 843 00005B0F ZwQueryInformationToken
 844 0000455F ZwQueryInstallUILanguage
 845 0001B229 ZwQueryIntervalProfile
 846 0000BD4F ZwQueryIoCompletion
 847 00007EBB ZwQueryKey
 848 0001B237 ZwQueryMultipleValueKey
 849 0001B245 ZwQueryMutant
 850 000107D8 ZwQueryObject
 851 0001B253 ZwQueryOpenSubKeys
 852 000152DD ZwQueryPerformanceCounter
 853 0001B261 ZwQueryQuotaInformationFile
 854 000112BB ZwQuerySection
 855 000038C7 ZwQuerySecurityObject
 856 0001B26F ZwQuerySemaphore
 857 00005EA8 ZwQuerySymbolicLinkObject
 858 0001B27D ZwQuerySystemEnvironmentValue
 859 00007D11 ZwQuerySystemInformation
 860 000148E2 ZwQuerySystemTime
 861 00011775 ZwQueryTimer
 862 0000CBA0 ZwQueryTimerResolution
 863 000062D2 ZwQueryValueKey
 864 00015AA3 ZwQueryVirtualMemory
 865 0000E588 ZwQueryVolumeInformationFile
 866 0000366B ZwQueueApcThread
 867 00014B92 ZwRaiseException
 868 0001B28E ZwRaiseHardError
 869 0000C552 ZwReadFile
 870 0001B29C ZwReadFileScatter
 871 0000F6A1 ZwReadRequestData
 872 0000DEE6 ZwReadVirtualMemory
 873 00004BB2 ZwRegisterThreadTerminatePort
 874 00015475 ZwReleaseMutant
 875 00008E81 ZwReleaseSemaphore
 876 0000BEA7 ZwRemoveIoCompletion
 877 0001B2AA ZwReplaceKey
 878 0000E596 ZwReplyPort
 879 00009161 ZwReplyWaitReceivePort
 880 000039BC ZwReplyWaitReceivePortEx
 881 0001B2B8 ZwReplyWaitReplyPort
 882 0001B4B0 ZwReplyWaitSendChannel
 883 0001B2C6 ZwRequestDeviceWakeup
 884 00005290 ZwRequestPort
 885 0000916F ZwRequestWaitReplyPort
 886 0001B2D4 ZwRequestWakeupLatency
 887 00016C2F ZwResetEvent
 888 0001B2E2 ZwResetWriteWatch
 889 0001B2F0 ZwRestoreKey
 890 00008FB7 ZwResumeThread
 891 00016C3D ZwSaveKey
 892 0001B2FE ZwSaveMergedKeys
 893 0000808A ZwSecureConnectPort
 894 0001B4BE ZwSendWaitReplyChannel
 895 0001B4CC ZwSetContextChannel
 896 00016C4B ZwSetContextThread
 897 0001B30C ZwSetDefaultHardErrorPort
 898 0001B31A ZwSetDefaultLocale
 899 0001B328 ZwSetDefaultUILanguage
 900 0001B336 ZwSetEaFile
 901 00008563 ZwSetEvent
 902 0001B344 ZwSetHighEventPair
 903 0001B352 ZwSetHighWaitLowEventPair
 904 0000EE28 ZwSetInformationFile
 905 0001B360 ZwSetInformationJobObject
 906 0001B36E ZwSetInformationKey
 907 000107E6 ZwSetInformationObject
 908 00013B6D ZwSetInformationProcess
 909 0000A1E0 ZwSetInformationThread
 910 00016C59 ZwSetInformationToken
 911 0001B37C ZwSetIntervalProfile
 912 000086C0 ZwSetIoCompletion
 913 00016C67 ZwSetLdtEntries
 914 0001B38A ZwSetLowEventPair
 915 0001B398 ZwSetLowWaitHighEventPair
 916 0001B3A6 ZwSetQuotaInformationFile
 917 00011F97 ZwSetSecurityObject
 918 0001B3B4 ZwSetSystemEnvironmentValue
 919 000010CF ZwSetSystemInformation
 920 0001B3C2 ZwSetSystemPowerState
 921 000010DD ZwSetSystemTime
 922 0000C1DA ZwSetThreadExecutionState
 923 00008C5F ZwSetTimer
 924 00018958 ZwSetTimerResolution
 925 0001B3D0 ZwSetUuidSeed
 926 0000AA1B ZwSetValueKey
 927 0001B3DE ZwSetVolumeInformationFile
 928 0001B3EC ZwShutdownSystem
 929 0001B3FA ZwSignalAndWaitForSingleObject
 930 0001B408 ZwStartProfile
 931 0001B416 ZwStopProfile
 932 0001B424 ZwSuspendThread
 933 0001B432 ZwSystemDebugControl
 934 0001B440 ZwTerminateJobObject
 935 0000DD80 ZwTerminateProcess
 936 0000DFC2 ZwTerminateThread
 937 00004BC0 ZwTestAlert
 938 0001B44E ZwUnloadDriver
 939 00016C75 ZwUnloadKey
 940 00010312 ZwUnlockFile
 941 000024DB ZwUnlockVirtualMemory
 942 0000A3D8 ZwUnmapViewOfSection
 943 00016C83 ZwVdmControl
 944 00013233 ZwWaitForMultipleObjects
 945 00014086 ZwWaitForSingleObject
 946 0001B45C ZwWaitHighEventPair
 947 0001B46A ZwWaitLowEventPair
 948 000023A7 ZwWriteFile
 949 0001B478 ZwWriteFileGather
 950 0000816A ZwWriteRequestData
 951 0000815C ZwWriteVirtualMemory
 952 00012445 ZwYieldExecution
 953 000382C5 _CIpow
 954 000467F7 __eCommonExceptions
 955 00046000 __eEmulatorInit
 956 00049A66 __eF2XM1
 957 00048335 __eFABS
 958 00046DD7 __eFADD32
 959 00046DFF __eFADD64
 960 00046E4A __eFADDPreg
 961 00046E4F __eFADDreg
 962 00046E51 __eFADDtop
 963 00048346 __eFCHS
 964 00048526 __eFCOM
 965 00048449 __eFCOM32
 966 00048472 __eFCOM64
 967 00048517 __eFCOMP
 968 00048432 __eFCOMP32
 969 0004845B __eFCOMP64
 970 000484FB __eFCOMPP
 971 000490CE __eFCOS
 972 00049F37 __eFDECSTP
 973 00047216 __eFDIV32
 974 0004722A __eFDIV64
 975 000472E3 __eFDIVPreg
 976 00047220 __eFDIVR32
 977 00047234 __eFDIVR64
 978 0004723E __eFDIVRPreg
 979 00047243 __eFDIVRreg
 980 00047245 __eFDIVRtop
 981 000472E8 __eFDIVreg
 982 000472EA __eFDIVtop
 983 00048356 __eFFREE
 984 00046D87 __eFIADD16
 985 00046DAF __eFIADD32
 986 000483F7 __eFICOM16
 987 00048420 __eFICOM32
 988 000483E0 __eFICOMP16
 989 00048409 __eFICOMP32
 990 000471EE __eFIDIV16
 991 00047202 __eFIDIV32
 992 000471F8 __eFIDIVR16
 993 0004720C __eFIDIVR32
 994 00047AF8 __eFILD16
 995 00047B09 __eFILD32
 996 00047B13 __eFILD64
 997 00046F64 __eFIMUL16
 998 00046F98 __eFIMUL32
 999 00049F54 __eFINCSTP
1000 00046000 __eFINIT
1001 000481A0 __eFIST16
1002 000480AE __eFIST32
1003 0004819B __eFISTP16
1004 000480A9 __eFISTP32
1005 00048253 __eFISTP64
1006 00046CC6 __eFISUB16
1007 00046D93 __eFISUB32
1008 00046D79 __eFISUBR16
1009 00046DA1 __eFISUBR32
1010 00048708 __eFLD1
1011 00047A79 __eFLD32
1012 00047ACF __eFLD64
1013 00047BC9 __eFLD80
1014 00049ED0 __eFLDCW
1015 0004A071 __eFLDENV
1016 00048773 __eFLDL2E
1017 00048795 __eFLDLN2
1018 000487A6 __eFLDPI
1019 00048744 __eFLDZ
1020 00046FDA __eFMUL32
1021 0004701E __eFMUL64
1022 0004706B __eFMULPreg
1023 00047070 __eFMULreg
1024 00047072 __eFMULtop
1025 00046A66 __eFPATAN
1026 00046A2A __eFPREM
1027 00046A50 __eFPREM1
1028 000491DB __eFPTAN
1029 0004738D __eFRNDINT
1030 0004A0AB __eFRSTOR
1031 00049FFE __eFSAVE
1032 00046A5F __eFSCALE
1033 00049173 __eFSIN
1034 0004A2CA __eFSQRT
1035 00047C84 __eFST
1036 00047F22 __eFST32
1037 00047D4D __eFST64
1038 00049F16 __eFSTCW
1039 00049F82 __eFSTENV
1040 00047C2A __eFSTP
1041 00047F1D __eFSTP32
1042 00047D48 __eFSTP64
1043 000482DA __eFSTP80
1044 00049F22 __eFSTSW
1045 00046DBB __eFSUB32
1046 00046DE3 __eFSUB64
1047 00046E0B __eFSUBPreg
1048 00046DC9 __eFSUBR32
1049 00046DF1 __eFSUBR64
1050 00046E26 __eFSUBRPreg
1051 00046E2B __eFSUBRreg
1052 00046E2D __eFSUBRtop
1053 00046E10 __eFSUBreg
1054 00046E12 __eFSUBtop
1055 0004869A __eFTST
1056 000484F1 __eFUCOM
1057 000484E2 __eFUCOMP
1058 00048484 __eFUCOMPP
1059 00048674 __eFXAM
1060 0004835C __eFXCH
1061 00048A03 __eFXTRACT
1062 00046A87 __eFYL2X
1063 00046A8E __eFYL2XP1
1064 0004A18D __eGetStatusWord
1065 000386DE __isascii
1066 00038730 __iscsym
1067 000386F3 __iscsymf
1068 000386EB __toascii
1069 0000C5A8 _alldiv
1070 00007A9F _allmul
1071 000160D6 _alloca_probe
1072 000387F1 _allrem
1073 000388A3 _allshl
1074 000388C2 _allshr
1075 0003891A _atoi64
1076 0000DB68 _aulldiv
1077 0000DB91 _aullrem
1078 00007D61 _aullshr
1079 000160D6 _chkstk
1080 00051028 _fltused
1081 00002CDA _ftol
1082 00038AB4 _i64toa
1083 00038BD4 _i64tow
1084 000189D2 _itoa
1085 00001B59 _itow
1086 00038A8A _ltoa
1087 00038B78 _ltow
1088 00038C05 _memccpy
1089 00038C58 _memicmp
1090 00038CF0 _snprintf
1091 00008E0E _snwprintf
1092 00038D65 _splitpath
1093 00011634 _strcmpi
1094 00011634 _stricmp
1095 00017DD3 _strlwr
1096 00004DE6 _strnicmp
1097 00002D01 _strupr
1098 00038F4F _tolower
1099 00038F6A _toupper
1100 00038B5D _ui64toa
1101 0000FE10 _ultoa
1102 00038BA6 _ultow
1103 00018D01 _vsnprintf
1104 00001FA5 _wcsicmp
1105 00038F98 _wcslwr
1106 00012DD7 _wcsnicmp
1107 00038FC2 _wcsupr
1108 00038FEC _wtoi
1109 0003900F _wtoi64
1110 00038FEC _wtol
1111 000393F2 abs
1112 00039032 atan
1113 0001673E atoi
1114 000166E3 atol
1115 000390E9 ceil
1116 000391B5 cos
1117 0003924F fabs
1118 00039304 floor
1119 0003862C isalnum
1120 0003853D isalpha
1121 000386B6 iscntrl
1122 00002C85 isdigit
1123 00038688 isgraph
1124 00038593 islower
1125 0003865A isprint
1126 00038604 ispunct
1127 00002CA3 isspace
1128 0003856B isupper
1129 000393D0 iswalpha
1130 0000C629 iswctype
1131 00007FA3 iswdigit
1132 000393E1 iswlower
1133 00018AE8 iswspace
1134 00017DF6 iswxdigit
1135 000385C9 isxdigit
1136 000393F2 labs
1137 000393FD log
1138 00001B87 mbstowcs
1139 000394E2 memchr
1140 00039583 memcmp
1141 0003962F memcpy
1142 0001109B memmove
1143 00039950 memset
1144 000382DE pow
1145 000399A8 qsort
1146 00039B6A sin
1147 00017E20 sprintf
1148 00039C16 sqrt
1149 00039CBC sscanf
1150 00039D62 strcat
1151 00005B1D strchr
1152 00039E02 strcmp
1153 00039CF6 strcpy
1154 00039E83 strcspn
1155 00039EC0 strlen
1156 00039F37 strncat
1157 00002D4E strncmp
1158 00008824 strncpy
1159 0003A084 strpbrk
1160 00017EC0 strrchr
1161 0003A0BD strspn
1162 00017EE7 strstr
1163 0003A10C strtol
1164 000180CD strtoul
1165 0000423D swprintf
1166 0003A271 tan
1167 00002D26 tolower
1168 00015A1E toupper
1169 0003A30F towlower
1170 000180E4 towupper
1171 0003A32A vsprintf
1172 000121E4 wcscat
1173 00012544 wcschr
1174 0000972D wcscmp
1175 0000C23F wcscpy
1176 0000CA53 wcscspn
1177 000152EB wcslen
1178 00006459 wcsncat
1179 0000EBD1 wcsncmp
1180 0000BCE6 wcsncpy
1181 0000DF7B wcspbrk
1182 0000F661 wcsrchr
1183 00016A11 wcsspn
1184 0000456D wcsstr
1185 00008B39 wcstol
1186 0003A446 wcstombs
1187 0001815A wcstoul

MFC 위성 DLL 취약점

Wed, 03 Sep 2014 23:59:52 GMT

MFC 7.0부터 위성 DLL이란게 추가된 것 같습니다. 이게 머 위성 DLL하니 말이 거창한데 리소스 DLL을 분리시켜 놓고 시스템 언어에 맞게 리소스 DLL을 로드하는 것을 의미하나 봅니다. 상세 기능은 여기 링크를 참고하시면 됩니다. 근데 안타깝게도 MFC 개발팀에서 이 기능을 만들면서 초기에 소소한 실수(?!)를 하는 바람에 취약점이 생겼나 보네요. 머 대단한 취약점은 아니고 LPK.DLL이나 USP10.DLL 같이 임의의 코드가 리소스 DLL에 감염돼 있으면 실행되는 취약점입니다. 그럼 왜 생겼는지 한 번 살펴볼까요?

아래는 VS 2008의 위성 DLL 로드 부분 코드입니다. MFC에 포함된 appcore.cpp의 _AfxLoadLangDLL 코드의 일부입니다. 보면 리소스 DLL을 LoadLibraryEx를 통해서 로드하는데 안타깝게도 마지막 인자가 0입니다. 0이라는 말은 그냥 일반 DLL 처럼 로드하겠다는 의미죠. 리소스 DLL에 악성 코드가 감염되어 있었다면 같이 실행될 수 있다는 것을 의미합니다.

if (pfnFindActCtxSectionString &&
	pfnFindActCtxSectionString(0, NULL, ...))
{
	// Load using the dll name only...
	hInstance = ::LoadLibraryEx(pszFilename, NULL, 0);
}
else
{
	// Load using the full path...
	hInstance = ::LoadLibraryEx(szLangDLL, NULL, 0);
}

취약한 VS 2008 위성 DLL 로드 부분 아래는 VS 2013의 appcore.cpp의 _AfxLoadLangDLL 함수 부분을 발췌한 내용입니다. 살펴보면 LoadLibraryEx를 할 때 마지막 인자에 LOAD_IMAGE_AS_DATAFILE을 넣어서 DllMain이 실행되지 않도록 하고 있습니다. 악성 코드에 감염되어 있다고 하더라도 해당 코드가 실행되지는 않는다는 것을 의미하죠.

hInstance = ::LoadLibraryExW(szLangDLL
           , NULL
           , LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE | LOAD_LIBRARY_AS_IMAGE_RESOURCE);

if (hInstance == NULL)
{
	// if library load failed using flags only valid on Vista+, ...
	hInstance = ::LoadLibraryExW(szLangDLL, NULL, LOAD_LIBRARY_AS_DATAFILE);
}

안전한 VS 2013 위성 DLL 로드 부분 #1

이런 사실을 알게 된다면 굳이 위성 DLL 기능이 필요 없다면 기능을 사용하고 싶지 않을 수도 있는데요. 위성 DLL은 MFC DLL의 DllMain에서 아래와 같은 코드에 의해서 로드됩니다. 보시면 알겠지만 일반적인 상황이라면 제어할 수 있는 제어 플래그가 없습니다. 그도 그럴것이 뭐 DllMain이니깐염.

DWORD dwLen = GetModuleFileName(NULL, rgchFullModulePath, ...);
if (dwLen > 0)
{
	TCHAR *pszFilename = ::PathFindFileName(rgchFullModulePath);
	if (pszFilename > rgchFullModulePath)  // filename portion of path ...
	{
		*pszFilename = 0;
		// the buffer passed to AfxLoadLangResourceDLL is filled with the path ...
		g_fLoadingResourcesForMFCDLL = TRUE;
		hLangDLL = AfxLoadLangResourceDLL(_T("%s") _T("MFC") ...);
		g_fLoadingResourcesForMFCDLL = FALSE;
	}
}

AFX_MODULE_STATE* pState = AfxGetModuleState();
pState->m_appLangDLL = hLangDLL;

VS 2013 MFC DLL DllMain 부분 #2

이 MFC 취약점에 얽혀 있다면 빠져 나가는 방법으로는 1) VS를 업그레이드 한다. 2) MFC DLL을 새로 빌드해서 사용한다. 3) MFC DLL 바이너리를 패치 한다, 정도가 있겠습니다. 바이너리를 패치하는 게 가장 쉬워 보일 수도 있습니다. 플래그 값만 교정해주면 되니까요. 아래처럼 리소스 DLL을 LoadLibraryEx 해서 로드하는 부분을 찾아서 0을 2로 변경해 주면 됩니다. mfc71.dll을 사용하신다면 일이 조금 골치아파질수도 있겠네요.

mfc100.dll을 사용하신다면 LoadLibraryEx에 사용되는 마지막 플래그를 0에서 2로 변경해 주시면 됩니다.

mfc71.dll을 사용하시나요? 일단 눈물 좀 닦고. 상상력을 발휘해 보세요.

뉴스타파 전국 유해 물질 데이터 지도

Thu, 28 Aug 2014 23:59:51 GMT

주거지에 유해물질 유출… 세월호 이후도 안전대책은 제자리

내 집 주변에 위험물질이? 전국 유해물질 데이터 지도 공개

뉴스타파에서 전국 유해물질 데이터 지도를 공개했습니다. 참, 잘했어요. 짝짝짝. 심심해서 좀 살펴봤는데요. 씁쓸한 뒷맛만 남는군요. 지도가 궁금하신 분은 여기서 살펴보시면 됩니다. 집 주변 한 번 확인해 보세요. 하나라도 유해물질 보관하는 곳이 있다면 포풍민원질로 공무원들을 쪼으도록 합시다. 그래야 그나마 조금이라도 철저하게 관리되겠지요.

하루가 멀다하고 무슨 사건 사고가 이리 많이 터지는지 참 어처구니가 없는 시절이네요. 다들 몸조심 하세용 ^^;;

강남, 유해물질이 뭔가요? 씹어먹는 건가요?

구로, 생각보단 작은뎅?

송도, 이건 뭔가요?

유출지, 개수가 중요한 건 아니라는거…

유해물질 청정지역, 강원도로 오세염!!!

RPC를 APC로 구현하면 망하는 이유

Tue, 26 Aug 2014 23:59:50 GMT

어제 새 기능 버그를 잡고 있었는데 생각보다 일이 커졌다. 결국 RPC가 필요하다는 결론에 도달했다. RPC를 뭐로 만들지 고민을 한참했다. 어떤게 제일 손 안데고 코풀 수 있는 방법일까(?!) 고민한 끝에 APC를 사용한 꼼수로 구현하기로 했다. 메커니즘은 완벽했다. 마치 APC는 나에게 RPC 구현을 위해서 만들어 둔 통로처럼 느껴졌다. 둘다 procedure call이니 뭐 도찐개찐이기도 하고. 여튼 그렇게 지루한 코드를 제법 쓰고는 얼추 만들어서 테스트를 하는데 이건 뭐지?! 주구장창 크래시!!! 그러다 찾아본 QueueUserAPC 도움말. 설명을 해놔도 안 읽은 내 잘못이 컸다 ㅠㅜ~

Note Queuing APCs to threads outside the caller’s process is not recommended for a number of reasons. DLL rebasing can cause the addresses of functions used by the APC to be incorrect when the functions are executed outside the caller’s process. Similarly, if a 64-bit process queues an APC to a 32-bit process or vice versa, addresses will be incorrect and the application will crash. Other factors can prevent successful function execution, even if the address is known.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms684954(v=vs.85).aspx

믿을거라곤 이벤트와 뮤텍스, 그리고 파일맵 밖엔 없는듯… 아님 파이프가 나을래나?

뭔가 일이 쉽게 풀린다 했지… ㅠㅜ

오늘은 장사 접고 낼 해야겠다…

윈도우 스토어 앱 개발하긔~

Thu, 31 Jul 2014 23:59:49 GMT

iOS가 판도라의 상자를 연 이후로 요즘만큼 개발자들이 피곤한 시대가 또 있었을까 싶다. 초창기 윈도우 프로그래머로 일하던 시절에는 윈도우 9x만 없다면 뭐든지 다할수 있을 것 같다는 말들이 유행했었다. 그렇게 영원이 악몽같이 존재할 것 같던 윈도우 9x도 윈도우 비스타와 윈도우 7의 출현으로 역사의 뒤안길로 사라졌다. 그렇게 잠시나마 태평성대가 오나 싶더니만 iOS와 함께 온갖 종류의 플랫폼이 우후죽순 등장해 버렸다. 이제는 차라리 비슷했던 9x를 지원하는게 좋았다는 생각마저 들 정도다. 갈라파고스도 진짜 이보다는 상태가 나았지 싶다. iOS, 안드로이드, 윈폰, 블랙베리 같은 온갖 종류의 디바이스가 세상 밖으로 출몰해 버렸고 똑똑한 프로그래머라는 소리를 들으려면 그 온갖 종류의 디바이스에서 동작하는 프로그램을 다 만들 줄 알아야 하는 시대가 도래한 것이다. API 세트도 다르고, 언어도 다르며, 심지어는 OS, 더 나아가서는 CPU까지 다른 환경에 익숙해져야 하는 골치아픈 세상이 돼 버렸다.

이쯤되니 요즘엔 윈도우가 PC 시장에서 그랬던 것처럼 누군가가 그냥 독점해 버렸으면 좋겠다는 마음마저 든다. 사용자에게는 선택권이 제한되고 개발 생태계에도 좋지 않은 일이란 걸 알지만 이런 온갖 종류의 디바이스에 들어가는 프로그램을 만들어야 하는 프로그래머의 고충도 보통 일은 아니기 때문이다. 하나 하기에도 바쁜데 하나 배우면 또 하나가 튀어나오는 식이다. 그.래.서. 요즘 개발자들은 정말 피곤하다.

그런 피곤한 개발자들에게 윈도우 스토어 앱이라는 신세계가 또 열리고 있다. 지금은 시장 지배력이 낮지만 영원히 낮으라는 법은 없고, 아직까진 경쟁자가 별로 없는 블루오션 시장이라는 매력도 있는 그 윈도우 스토어 말이다. 남들보다 조금 일찍 배에 올라타려는 프로그래머를 위해서 스토어 개발에 관한 이야기를 몇 자 끄적여 보려고 한다. 모든 플랫폼이 그렇겠지만 기본적인 환경을 구축하고 돌아가는 메커니즘을 이해하고 나면 나머지는 그저 소소하게 변경된 API와 언어 뿐이라 생각보단 금방 접근할 수 있다. 그럼 이제 윈도우 스토어 프로그래밍에 관해서 한 번 알아보도록 하자.

백문이 불여일견이랬다. 일단 한 번 만들어보자. Visual Studio 2013을 사용하길 추천한다. 그리고 영문판으로 설치하길 권장한다. 이번에 컴퓨터를 새로 사면서 한글 윈도우를 설치했는데 내가 한 일 중에 가장 병신같은 짓이었던 것 같다. 프로그래머라면 영문판을 쓰자. 그게 검색하기도 편하고 문제 해결하기도 수월하다. Visual Studio 2013을 설치하고 Project, New를 선택하면 아래와 같은 깜찍한 다이알로그가 출력된다.

윈도우 스토어 앱 프로젝트

Visual C++, Store Apps 아래에 우리가 선택할 수 있는 프로젝트 형태가 있다. 유니버셜 앱이라고 표기된 것은 PC 윈도우, 윈도우 폰 환경에서 모두 동작하는 앱을 개발하는 것을 의미한다. Windows Apps는 PC 윈도우에서 동작하는 앱을, Windows Phone Apps는 윈폰에서 돌아가는 앱을 개발하는 것을 의미한다. 유니버셜 앱이라고 특별한게 있는 건 아니고 공통 코드가 Shared로 빠져 있고, 각각 디바이스에 맞는 프로젝트 두 개가 생성되는 것을 볼 수 있다.

프로젝트 종류도 여러가지가 있는데 Blank App은 그냥 비어있는 앱을, DLL은 네이티브 DLL 코드를, Static Library는 정적 라이브러리 코드를, Windows Runtime Component는 윈도우 런타임을 사용하는 DLL을 만드는 것을 의미한다.

유니버셜 앱의 Blank App을 선택하고 프로젝트명을 halo로 만들어 보자. 만들고 나면 솔루션 탐색기가 아래와 같이 구성된 것을 볼 수 있다. CTRL + F5를 눌러서 실행해 보자. 윈도우8 환경이라면 그냥 실행될 것이다. 개발자 환경 등록이 되지 않았으면 뭐 자질구레하게 묻는데 MS 계정으로 로그인해서 인증을 해주도록 하자.

스토어 앱 솔루션 탐색기

CTRL + F5를 눌러서 앱을 실행하면 어디서 실행되는 것일까? 센스 있는 프로그래머라면 알아차렸겠지만 CTRL + F5를 눌렀을 때 시스템에 설치되거나 해서 실행되지는 않는다. 아래와 같이 디버그 빌드된 폴더에서 실행된다는 것을 알 수 있다.

Debug 빌드 폴더

그렇다면 여기에서 의문이 생긴다. 스토어에는 무슨 파일을 올리는 거지? 릴리즈로 빌드하면 뭔가 패키지 파일이 나올까? 하지만 그렇게 해봐도 패키지 파일은 나오지 않는다. 패키지 파일을 만들기 위해서는 Visual Studio 2013의 프로젝트 메뉴 아래 있는 스토어 메뉴를 활용해야 한다. 메뉴를 선택하면 아래와 같이 나오는데 여기서 Create App Packages 메뉴를 선택하면 된다.

스토어 메뉴

종종 스토어 메뉴 자체가 활성화가 되어 있지 않은 경우도 있다. 그런 경우에는 솔루션 탐색기의 Package.appxmanifest 파일을 선택해서 연다. 그럼 아래와 같은 화면이 출력될 것이다. 거기서 Packaging 항목에 있는 버전 정보를 수정해주면 활성화 된다. Packaging 항목에 보면 Publisher 항목이 있는 그 부분이 디지털 서명을 선택하는 항목이다. 시스템에 설치된 인증서가 있다면 거기서 선택해주면 해당 인증서로 서명이 된다.

Package.appxmanifest

Create App Package 메뉴가 활성화되면 선택해서 패키지 파일을 만들 수 있다. 처음 물어보는 항목이 MS 계정과 연동해서 업로드 하겠냐는 질문인데 연동 작업을 할게 아니라면 NO를 선택해 주면된다. 그렇게 앱 패키지를 생성하면 마지막에 어떤 폴더에 생성이 되었는지 알려주는 화면이 출력된다. 클릭해서 해당 폴더로 이동해보면 아래와 같이 패키지 파일이 생성된 것을 볼 수 있다. halo.Windows_1.0.0.1_Win32_Debug.appxupload 파일을 스토어에 업로드하면 된다. halo.Windows_1.0.0.1_Win32_Debug_Test 폴더에 들어가보면 halo.Windows_1.0.0.1_Win32_Debug.appx 파일이 존재한다. 그 파일을 통해서 시스템에 직접 설치해 볼 수도 있다.

생성된 앱 폴더

스토어에 올리지않고 appx 파일을 시스템에 설치하기 위해서는 윈도우 그룹 정책을 변경해 주어야 한다. 실행 프롬프트에서 gpedit.msc를 실행하자. 그럼 아래와 같이 그룹 정책 편집기 화면이 출력된다.

gpedit.msc 실행

여기서 로컬 컴퓨터 정책 => 컴퓨터 구성 => 관리 템플릿 => Windows 구성 요소 => 앱 패키지 배포 항목으로 이동해보자. 그럼 “Allow all trusted apps to install (모든 신뢰할 수 있는 앱을 설치할 수 있음)” 함목이 있는 것을 볼 수 있을 것이다. 기본적으로 비활성화 돼 있다. 그걸 선택해서 활성화시킨 다음 재부팅을 하면 appx 패키지를 설치할 수 있다. 정책을 바꾼 다음 재부팅을 해보자.

재부팅을 했으면 앱을 명령 프롬프트에서 설치하기 위해서는 파워쉘의 add-appxpackages를, 제거하기 위해서는 remove-appxpackages를 사용하면 된다. “add-appxpackages appx파일명”을 입력하면 해당 앱이 설치되는 것을 볼 수 있다. 아래는 그렇게 앱을 설치하는 화면을 보여준다. 디버그로 실행해서 이전에 설치된 인스턴스가 있기에 제거후에 다시 설치시키는 장면이다.

파워쉘을 통해 앱 설치 및 제거

파워쉘을 통해서 시스템에 직접 설치하면 아래 화면에 나오는 것처럼 Program Files 폴더의 WindowsApps 폴더에 빌드한 앱이 설치된 것을 볼 수 있다. WindowsApps 폴더는 기본적으로 관리자 권한을 가져도 들어가 볼 수 없다록 권한 설정이 되어 있다. 내부를 살펴보기 위해서는 해당 폴더의 소유자를 관리자로 변경해 주어야 한다.

WindowsApps 폴더

이렇게 개발한 appx 패키지를 친구한테 주고, gpedit 설정을 변경하는 것 까지 알려주어도 친구는 앱이 실행되지 않는다는 문제를 호소할 수 있다. 이벤트 로그를 살펴보면 0x80073CFC 오류가 발생하는 것을 볼 수 있다. 개발자 라이선스 갱신이 되지 않아서 발생하는 문제다. 관리자 권한으로 파워쉘을 실행한 다음 Show-WindowsDeveloperLicenseRegistration 명령어를 입력해서 개발자 라이선스를 갱신해 주면 문제가 해결된다.

지금까지 앱 설치 및 배포에 관한 기본적인 방법들을 살펴보았다. 이제 개발적인 측면을 살펴보도록 하자. Windows 8이 출시되면서 아래 그림과 같이 앱을 위한 WinRT API가 추가되었다. 앱 개발은 그 API를 사용해서 쪼물닥 거리는 것이라 생각하면 된다.

윈도우 8 개발 아키텍처

마이크로소프트 공식 페이지를 살펴보면 C++ 개발자를 위해서는 두 가지 종류의 API가 제공되고 있는 것을 볼 수 있다. 하나가 그림에 있는 Windows Runtime이고 다른 하나가 Win32 and COM API다. Win32 and COM API가 지원된다늬? 그럼 그냥 다 쓸 수 있는건가? 라고 생각하면 천만의 말씀이다. 앱을 위해서 지원되는 API 목록을 보면 알겠지만 굉장히 제한적으로 지원되는 구조다. GetProcAddress는 있지만, GetModuleHandle은 없고, LoadLibrary는 없지만 LoadPackagedLibrary는 있는 것과 같은 식이다. CreateProcess는 당연히 없을 수도 있겠다고 생각이 들지만 CreateThread 마저도 없다. 결국 스레드를 쓰려면 Windows Runtime에 있는 Windows.System.Threading에서 지원해 주는 것을 사용할 수 밖에 없다. 이말은 기존 코드를 100% 재활용할 수는 없다는 것을 의미한다. 어떠한 형태로든 일정 수준 이상의 포팅 작업이 필요하다는 것을 의미한다. 물론 그렇다고 모두 다 새로 만들 필요는 없다. 이미 우리를 대신해 CraeteThread를 포팅해 주신 감사한 분들이 있기에 우리는 선검색 후포팅 하면 되겠다.

오픈 소스를 활용해 개발을 진행하고 있다면 기존의 코드가 문제가 될 수 있다. 대다수 오픈 소스들이 _WIN32 전처리기가 있으면 윈도우 환경으로 인식하고 기존의 윈도우 API를 사용해서 코딩한 부분이 많이 존재하기 때문이다. 이런 경우는 범용적으로 컴파일되게 만들기 위해서는 좀 더 세분화해서 조건을 판단할 필요가 있다. 예를들어 아래와 같은 오픈 소스 코드가 문제가 될 수 있다는 것을 의미한다.

#ifdef _WIN32
#include <windows.h>

void MyFunc()
{
    VirtualAlloc(... param ...);
}
#endif

이 코드의 경우 데스크톱 프로그램으로 컴파일 할 때는 VirtualAlloc이 존재하기 때문에 문제가 되지 않지만, 스토어 앱으로 개발할 때에는 VirtualAlloc이 없기에 문제가 된다. 당연히 윈도우 헤더부터 시작해서 MS에서도 이런 문제들을 겪었을 것이다. 그래서 이 상황을 판단할 수 있는 전처리기 매크로가 추가됐다. 아래 전처리기들이 그것이다. 위에서부터 PC앱, 폰앱, PC앱+폰앱, 데스크톱 애플리케이션 개발을 구분할 수 있는 전처리기다.

#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_PC_APP)
#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_PHONE_APP)
#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_APP)
#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)

전처리기를 통해서 앞선 코드를 고쳐보면 다음과 같이 고칠 수 있다. 앱 개발 환경이면 malloc을 사용해서 컴파일하도록 만들어주는 것이다.

#ifdef _WIN32
#include <windows.h>

void MyFunc()
{
#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_APP)
    malloc(... param ...);
#else
    VirtualAlloc(... param ...);
#endif
}
#endif

당.연.한. 소리겠지만 그 많은 소스 코드에 API 호출을 다 찾아서 이런 쌩쑈를 하고 있을 수는 없다. 좀 더 편리하게 문제를 해결하기 위해서는 API 자체를 포팅하는 것이 좋다. 다음과 같이 헤더를 만들어서 앱 개발 환경일 때에도 그 API가 존재하는 것처럼 만들어 주는 것이다.

//windows_app.h
#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_APP)

static
inline
LPVOID
WINAPI
VirtualAlloc(...)
{
    return malloc(...);
}

#endif

위와같이 존재하지 않는 API를 포팅한 헤더를 만든 다음에는 그 헤더를 프로젝트에 포함시켜 주면 된다. 전체 참조 되는 헤더에 같이 추가해주면 데스크톱과 앱 개발 환경에서 모두 빌드 문제가 없도록 손쉽게 만들 수 있다.

BSOD: 신호와 소음

Tue, 22 Jul 2014 23:59:48 GMT

2008 베이징 올림픽 개막식을 장식한 화려한 블루스크린

드라이버 개발자 10명을 불러다 놓고 어떤 말을 제일 싫어하십니까, 라고 물어보면 10명 모두 BSOD를 제일 싫어한다고 대답할 것이다. 그만큼 BSOD는 드라이버 개발자에게는 제일 듣기 싫은 말이다. 자다가도 경기를 일으키고, 소리만 나와도 소스라치게 놀라며, 화면에 파란 도트만 보여도 커널 개발자를 겁에 질리게 만들어 버리는 녀석이 바로 BSOD다. BSOD는 Blue Screen Of Death의 약자로 우리말로 번역하면 죽음의 블루스크린 정도 되겠다. 2008년 베이징 올림픽 개막식에서 발생한 블루스크린이 전세계 공중파를 타면서 이제는 일반인들도 블루스크린이 뭔지를 알게 되었다.

커널 개발자가 극혐하는 블루스크린이 출력된 티

BSOD에 대한 두려움을 경계한 개발자들은 BSOD 화면 보호기를 만들어서 담력을 키우기도 하고, 여자친구에게 블루스크린이 출력된 티셔츠를 선물해 보기도 하지만 큰 소용은 없다. 급기야 MS 개발자들은 윈도우 8부터는 블루스크린 이미지를 아주 친근한 형태로 변경했다. 색상을 파스텔톤의 파란색으로 바꾸었고, 화면에는 이모티콘도 넣었다. 블루스크린이 떴지만 쫄지말고 웃으라는 MS 개발자의 패기를 보여준다고 할 수 있겠다. 이런 노력에도 불구하고 커널 개발자들은 여전히 BSOD를 무서워 한다.

윈도우 8은 블루스크린 이미지를 친근하게 개선했다.

이렇게 설명하니 블루스크린이 뭔가 대단한 것처럼 보이는데 사실은 그냥 커널 영역에서 발생하는 프로그램 오류에 불과하다. 일반 응용 프로그램이 오류를 발생시키면 “잘못된 연산을 수행하였습니다”같은 아주 친절한 메시지를 뿜꼬는 프로그램이 종료되는 정도로 끝이 난다. 그런 똑같은 일이 커널 영역에서 발생하면 드라이버 하나가 죽고 끝나는 것이 아니라 블루스크린이 발생하고 시스템은 정지된다. 동일한 오류지만 파급 효과가 다른 것이다. 하나는 프로그램만 죽고 끝나고, 다른 하나는 시스템 전체가 죽는…

윈도우 9x 시절에는 블루스크린이 너무나 자주 발생해서 사람들은 블루스크린이 발생하는 줄도 몰랐다. 그저 또 껐다 켜야 하는구나라고 생각했다. 하지만 윈도우 2000이상부터 NT 커널이 도입되면서 블루스크린은 생각보다 보기 힘든 일이 되었다. 이후에도 다양한 보안 프로그램에서 많은 블루스크린을 발생시키곤 했지만 이 또한 MS의 꾸준한 노력으로 요즘은 정말 블루스크린 보기가 쉽지 않아졌다.

거창하게 썰을 풀었는데, 요는 이렇게 마주하기 싫은 블루스크린을 최근 다시 마주하게 되었다는 이야기를 하고 싶었던 것이었다. 따끈따끈한 신작 게임에 적용을 진행하면서 발생한 문제인데 당.연.히. 원인은 나의 어처구니 없는 멍청함에 있었다. 나의 멍청함을 인식하는데 다소 시간이 걸렸는데, 그 과정에 문제 해결을 방해하는 소음이 한 몫 했다.

첫번째는 어째서 그 게임에서만 밥 먹듯이 블루스크린이 발생하냐는 점이었다. 그런 문제라면 적어도 이전에 수도 없이 적용된 게임에서 응당 발견되었어야 하지 않았을까라는 생각이었다. 결과론적으로 그 게임에서만 발생하는 이유가 있었고, 그 문제가 그 전에는 전혀 발견될 수 없는 종류의 문제였다. 둘째는 블루스크린에 출력된 함수 파라미터와 관련한 데이터들이 우리의 생각을 오염시켰다. 실제로 우리가 참고한 글에 나온대로 파라미터를 수정하면 블루스크린이 발생하지 않았기 때문이었다. 하지만 이는 최종적으로 함정같은 존재였다.

이런 이유로 크래시 덤프 문제를 해결하는 과정이 생각보다 복잡 다단했다. 최종적으로는 정말 아주 사소한 문제에서 이 모든 것이 비롯됐다는 것을 알게 되었고, 그 도화선이 된 부분은 정말 실소를 금할 수 없을 정도로 어처구니 없는 내용이었다. 그래서 여기에 그 내용을 소개하면 다소 도움이 되지 않을까라는 생각에 글을 써본다.

덤프의 내용은 다음과 같다. 논페이지드 영역에서 페이지 폴트가 발생해서 블루스크린이 발생한 것이다. 콜스택을 살펴보면 MmProbeAndLockPages라는 함수에서 참조하려고 한 논페이지드 영역이 존재하지 않는 영역이라 발생했다는 것을 알 수 있다. 이 문제와 관련된 내용을 다음 몇 차례의 글을 통해서 살펴볼 생각이다. 혹시 관심있는 독자 분들이 있다면 여기에서 관련 파일을 받을 수 있다. 64비트 시스템에서 conan_ldr을 관리자 권한으로 실행하면 블루스크린이 발생하는 것을 재현할 수 있다. conan.dmp는 그렇게 생성한 미니덤프 파일이다.

kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced.  This cannot be protected by try-except,
it must be protected by a Probe.  Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: ffffffff825f0000, memory referenced.
Arg2: 0000000000000000, value 0 = read operation, 1 = write operation.
Arg3: fffff80002af3798, If non-zero, the instruction address which referenced the bad memory
	address.
Arg4: 0000000000000005, (reserved)

Debugging Details:
------------------


Could not read faulting driver name

READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80002d0f100
 ffffffff825f0000 

FAULTING_IP: 
nt!MmProbeAndLockPages+118
fffff800`02af3798 410fb601        movzx   eax,byte ptr [r9]

MM_INTERNAL_CODE:  5

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x50

PROCESS_NAME:  conan_ldr.exe

CURRENT_IRQL:  0

TRAP_FRAME:  fffff8800454f6d0 -- (.trap 0xfffff8800454f6d0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000001 rbx=0000000000000000 rcx=0000000000000000
rdx=0000000000000001 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002af3798 rsp=fffff8800454f860 rbp=fffff8800454fca0
 r8=fffffa8001cd5cf0  r9=ffffffff825f0000 r10=0000000000000001
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz ac pe nc
nt!MmProbeAndLockPages+0x118:
fffff800`02af3798 410fb601        movzx   eax,byte ptr [r9] ds:5480:ffffffff`825f0000=??
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff80002b545b3 to fffff80002ad7bc0

STACK_TEXT:  
fffff880`0454f568 fffff800`02b545b3 : 00000000`... : nt!KeBugCheckEx
fffff880`0454f570 fffff800`02ad5cee : 00000000`... : nt! ?? ::FNODOBFM::`string'+0x43801
fffff880`0454f6d0 fffff800`02af3798 : fffffa80`... : nt!KiPageFault+0x16e
fffff880`0454f860 fffff880`04baf04f : fffffa80`... : nt!MmProbeAndLockPages+0x118
fffff880`0454f970 fffffa80`01cd5cc0 : 00000000`... : conan+0x104f
fffff880`0454f978 00000000`00000000 : 00000000`... : 0xfffffa80`01cd5cc0

덤프를 살펴보면 알겠지만 크래시 시점에 주요하게 관여된 함수로 MmProbeAndLockPages, MmMapLockedPages가 있다. 덤프를 제일 먼저 분석한 엔지니어는 아래 내용을 토대로 드라이버의 코드의 함수 파라미터를 고쳐야 한다는 이야기를 했었다. 덤프 분석에 떡밥 내지는 힌트 정도로 살펴보면 좋을 것 같다. 앞으로 차차 살펴보겠지만 여러분이 MmProbeAndLockPages와 MmMapLockedPages 함수에 사용되는 AccessMode의 용도에 관한 아래 글들의 내용에 대해서 충분히 상세히 알고 있다면 그것만으로도 자부심을 가져도 될 것 같다.

The better idea would be to pass Irp->RequestorMode as the second parameter to MmProbeAndLockPages. In this case, if the requestor is UserMode and the buffer is a kernel address the API will immediately raise an exception instead of potentially crashing. Calling ProbeForWrite yourself would basically give you the same effect (it also checks to make sure the buffer supplied is a user address), which is why I asked if you were making this call earlier as it would point to this being a different type of bug.

– http://osronline.com/ShowThread.cfm?link=236232

If AccessMode is KernelMode and MmMapLockedPages cannot map the specified pages, the system issues a bug check. (For this reason, drivers should use MmMapLockedPagesSpecifyCache when available; that routine returns NULL on failure, rather than causing a bug check.) If AccessMode is UserMode and the specified pages cannot be mapped, the routine raises an exception. Callers that specify UserMode must wrap the call to MmMapLockedPages in a try/except block. For more information, see Handling Exceptions.

– http://msdn.microsoft.com/en-us/library/windows/hardware/ff554622(v=vs.85).aspx

앞으로 추가적인 몇 개의 글을 통해서 이 덤프의 정확한 원인을 추적하는 작업을 해 볼 생각입니다. 그전에 덤프에 대한 나름의 의미 있는 해석을 내렸다고 생각하는 분들은 codewiz at gmail.com으로 메일 주세요. 함께 할만한 일들이 있을지도 모르잖아요 ㅎㅎ~

드라이버 개발 환경 설정

Wed, 16 Jul 2014 23:59:47 GMT

시스템 설치할 때마다 여기 저기 검색해서 찾기 귀찮아서 정리한 페이지!!!

NTSTATUS 코드표

https://msdn.microsoft.com/en-us/library/cc704588.aspx

windbg 심벌 경로

srv*C:\WebSymbols*http://msdl.microsoft.com/download/symbols

윈도 XP 커널 디버그 설정

boot.ini 편집

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=”Debugging with Cable” /fastdetect /debug /debugport=COM1 /baudrate=115200

윈도 Vista+ 커널 디버그 설정

msconfig 들어가서 Advanced에서 디버그 옵션을 켜면됨

virtualbox 이미지

미리 구워논 이미지가 없으면 아래 사이트에서 다운로드 받아서 사용하면 편리함

https://www.modern.ie/en-us/virtualization-tools

WDk 7.1.0

http://www.microsoft.com/en-us/download/details.aspx?id=11800

Windows Vista+ Debug Filter 설정

설정 안 하면 DbgPrint 출력안뎀. 귀찮으면 레지 파일 다운받기.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Debug Print Filter]

“DEFAULT”=dword:0000000f

virtualbox 커널 디버깅용 파이프 설정

직렬포트, 호스트 파이프, 생성, \.\pipe<name>

windbg pipe 체크, 포트에 \.\pipe<name>

우분투에서 네트워킹 안될때

Thu, 10 Jul 2014 23:59:46 GMT

VM 같은 거 복사했을 때 우분투에서 네트워킹 안되면 아래 파일을 지우고 재부팅해 봅시다.

rm -rf /etc/udev/rules.d/70-persistent-net.rules

shutdown -r now

랜카드 맥어드레스가 변경되서 그런걸로 추정되는데…

어쨌든 파일 지우고 나면 인터페이스가 정상적으로 인식됩니다.

by accident

Fri, 04 Jul 2014 23:59:45 GMT

#0

점심 먹고 커피를 마시고 있었다. 이런 저런 이야기를 하다가 어쩌다가 나왔는지 by accident에 관한 이야기가 나왔다. 별 일 아닌 일이었지만 뭔가 재미있는 구석도 있는 것 같아서 여기다 옮겨 적어 본다. 사건의 전말은 이렇다. 한 독일 업체에서 우리쪽으로 아래와 같은 내용의 문장이 포함된 메일을 한 통 보냈다.

we found out by accident that Xigncode is writing logs on the Live Server.

우리는 XIGNCODE가 라이브 서버에서 로그를 기록하는 것을 우연히 발견했다.

그걸 본 우리쪽 커뮤니케이션 담당자가 accident 부터 끊어서는 아래와 같은 질문을 보냈다. 이게 사고/사건이라니 무슨 의미냐고 재차 질문을 한 것이다.

accident that Xigncode is writing logs on the Live Server.

XIGNCODE가 라이브 서버에서 로그를 기록하는 사건(?!)

그랬더니 업체쪽에서는 사고가 있었다는 말이 아니라 by accident를 구글 번역기를 돌려서는 이게 우연히라는 영어 표현이라는 답장을 아래와 같이 보내왔다.

“By accident” is an expression in English language. Google translation says it means임의in Korean language.

“by accident” 영어에 있는 표현(숙어)이다. 구글 번역기는 그것의 의미가 한국말로 임의라고 나에게 말해주었지.

커피를 마시다 이 이야기를 전해 들은 나는 핸펀으로 그 메일을 검색해서 살펴보고는 이걸 어떻게 이렇게 해석해서 재차 질문할 수 있지라는 생각을 했다. 그리곤 이 이야기를 전해준 직원에게 네이버 영어 사전에서 by accident를 찾아서 보여주며 이거 아니냐는 말을 건냈다. 그걸 들은 친구는 동료를 보호하기 위해서 accidently라고 썼어야 명확했을 거라는 힘겨운 실드를 쳤다. 한참을 듣고 계시던 사장님께서 한 말씀 덧붙인다. 야, 그게 표현이 뭐가 그리 중요하니 적당히 알아듣고 해달라는대로 처리해주면 되는 거잖아. 신택스가 아니라 시맨틱에 집중하라는 말씀.

#1

커피 마시고 올라와서는 친구 녀석이랑 톡질을 하다가 이 이야기가 다시 올라왔다. 영어 선생님을 하는 그 친구한테 우리 회사에서 이런 일이 있었다는 이야기를 하는데 그 친구는 내가 하는 말을 잘못 알아들어서는 내가 “we found out by accident that Xigncode is writing logs on the Live Server.”라는 문장을 썼다고 이해를 했다. 친구왈 “맹구야, 동사하고 목적어 사이에 부사가 있잖아”라는 이야기를 한다. “we found out that Xigncode is writing logs on the Live Server by accident.”라고 써야 한다는 말이다. 그래서 다시 네 말이 무슨 말인지 알겠는데 블라블라블라 긴 이야기를 돌고 돌아 사건의 전말을 전달했다. 친구왈 독일애들 그렇게 안 봤는데, 똑똑하지 않은 것 같다는 이야기를 한다. 난 걔들 입장에서도 외국어라는 말을 덧붙였다.

#2

부사의 위치. 어렵지? 아마 어려울거야?

심심해서 부사의 위치를 찾아봤다. 머 당연한 이야기겠지만 영어 선생님인 놈이 틀릴 일은 없다. 부사는 동사와 그 동사의 목적어 사이에는 쓰지 않는 거란다라고 친절히 알려준다. 돌고 돌고 돌아서 다시 실드를 쳤던 직원 말을 재차 실드를 쳐보자면 “we accidently found out that Xigncode is writing logs on the Live Server.”라고 썼어야 한다는 말이었을 것이다.

명확해야 한다는 관점만 놓고 본다면 업체간 공식적인 커뮤니케이션에서는 그냥 부사 형용사 따위는 없는게 더 좋지 않을까라는 생각이 든다. 우연히 발견했든, 면밀히 뒤지다 발견했든, 발견한 사실이 중요하지 그걸 한정짓는 한정 문구는 그닥 중요한 내용은 아니니 말이다.

#3

별 일 아닌 이 사건이 재미있게 느껴졌던 이유는 동일한 사건을 바라보는 관점이 사람마다 너무나 극명하게 차이가 나타났기 때문이었다. 나는 어떻게 by accident를 모르고 accident that이라고 끊어서 해석할 수 있냐는 관점을, 담당자를 실드 치던 직원은 by accident가 아니라 accidently를 썼으면 명확했을 거라는 입장을, 사장님은 by accident든 accidently든 알아들었으면 적당하게 조치를 취해주면 되지 문법 그거 따져서 무엇하겠느냐는 말씀을, 영어 선생님인 친구는 미개인도 아닌 우리가 21세기에 어떻게 동사와 목적어 사이에 부사 따위를 쓸 수 있지라는 반응을 보였다. 하나 같이 다 틀린 말도 아니고, 딱 하나를 집어서 이게 정답이라는 입장도 없다.

#4

임백준씨는 한 칼럼에서 “버그는 프로그래머의 숙명이다. 김밥을 마는 손에 밥풀이 묻는 것처럼, 비트와 바이트를 만지는 손에는 버그가 달라붙는다.”라는 이야기를 했었다. 퍽이나 멋진 표현이라는 생각을 했었는데 이 말이 비단 프로그래머에게만 적용되는 이야기는 아닌 것 같다. 영어로 커뮤니케이션을 하는 직원들도 소통을 하다보면 실수를 할 수 있는 것이다. 하루에도 몇 통씩 영어로 메일을 읽고, 쓰고, 영어로 메신저질을 하다 보면 자연스레 실수할 때도 있는 법이다. 그걸 두고 by accident를 모르고 accident that으로 끊어서 해석을 하냐고 뭐라고 한 건 아닌지라는 생각에 괜스레 미안해졌다.

언어는 불완전하고 커뮤니케이션은 어렵다. 상황은 복잡하고 입장은 다양하다. 이런 생각들이 머리속을 파고드니 그냥 우리가 죽자살자 집착하는 모든 일이 위에서 쳐다보면 죄다 우스워 보일수도 있겠다는 생각이 들었다. 그러다 떠오른 법정 스님의 시 한 수.

오해 – 법정

‘나는 당신을 죽도록 사랑합니다’라는 말의 정체는

‘나는 당신을 죽도록 오해합니다’일지도 모른다.

누가 나를 추켜세운다고 해서

우쭐댈 것도 없고,

헐뜯는다고 해서 화를 낼 일도 못 된다.

그건 모두가 한쪽만을 보고 성급하게 판단한

오해이기 때문이다.

오해란 이해 이전의 상태가 아닌가.

문제는 내가 지금 어떻게 살고 있는가에 달린 것이다.

실상은 말 밖에 있는 것이고

진리는 누가 뭐라 하든 흔들리지 않는다.

온전한 이해는 그 어떤 관념에서가 아니라

지혜의 눈을 통해서만 가능하다.

그 이전에는 모두가 오해일 뿐이다.

비행운

Thu, 03 Jul 2014 23:59:44 GMT

─ 신기해요. 어떤 음악을 들으면, 그 곡을 제게 처음 알려준 사람이 생각나요. 그것도 번번이요. 처음 가본 길, 처음 읽은 책도 마찬가지고요. 세상에 그런 게 있다는 걸 알려준 사람이 떠올라요. ‘이름을 알려준 사람의 이름’이라고 해야 하나? 그런 건 사물에 영원히 달라붙어버리는 것 같아요.

나는 ‘아니, 내가 이렇게 멋있는 말을 하다니!’ 하고 혼자 감탄했다. 하지만 ‘선배의 쪽지’는 더 근사했다.

─ 우리가 신을 잊을 수 없는 이유도 아마 그 때문일 거야.

– 비행운, 김애란

김애란의 소설을 좋아한다. 달작지근한 문장으로 글을 읽는 재미를 흠뻑 느끼게 해주기 때문이다. 평범한 문장도 그녀의 글 속에서는 힘을 발한다. “우리가 신을 잊을 수 없는 이유도 아마 그 때문일 거야”라는 이 평범한 문장도 김애란이 만들어 낸 장면 속에서는 기가 막힌다. 아마 그 누구라도 소설 속에서 그 문장을 만난다면 해머로 머리를 한 대 맞는 느낌일거라는데 500원은 걸 수 있다. 그렇다고 그녀가 단지 언어의 연금술사이기 때문에 팬을 자처하는 것은 아니다. 소설 속 이야기들이 묘하게 소설이 아니라 진짜 우리 이야기 같다는 생각이 들기에 그녀의 소설을 더 좋아하는 것 같다. 주인공의 현실에 격하게 공감하면서도 이상하게 마음이 조금은 편해진다. 그래서 책을 덮을 즈음엔 신묘하게도 힐샤워를 받은 느낌이 드는 오묘한 마력이 있다.

비행운도 그런 소설 중에 하나다. 이야기 하나하나가 모두 남의 일 같지 않은 그런 소설이다. 바로 옆에 있는 친구나 가족, 학교 선배나 후배, 또는 직장 상사나 동료들의 이야기라는 생각이 절로 든다. 달달한 문장에 취했다가도 주인공의 씁쓸한 현실을 보면 마음이 그리 편하진 않다. 우리 모두에게 이제는 행운이 함께 했으면 좋겠다는 생각이 드는 소설. 소설 속 주인공 모두에게, 그리고 또 지구에서 2014년을 보내고 있는 사람들 모두에게, May the Force be with you.

[시스템] 저수준 API 후킹 시에 유의할 점

Tue, 01 Jul 2014 23:59:43 GMT

저수준 API를 후킹할 때에는 해당 훅 대상이 되는 함수에 대해서 면밀하게 살펴야합니다. 그렇지 않을 경우에는 엉뚱한 부분 때문에 디버깅에 상당히 많은 시간을 잡아먹을 수 있습니다.

흔히 저지르는 실수는 훅 함수 내에서 후킹 대상 함수보다 높은 수준의 API를 호출하는 것입니다. 뭔소린가 싶은데 그냥 쉽게 설명하면 RtlAllocateHeap 따위의 함수를 후킹해놓고 해당 후킹 함수 내에서 동작을 살피기 위해서 OutputDebugStringW 따위를 호출하는 행위를 조심해야 한다는 것을 의미합니다. OutputDebugStringW 함수는 내부적으로 유니코드 문자열을 멀티바이트 문자열로 변경하기 위해서 힙을 할당하는 함수를 사용하는데 그러면 다시 후킹 함수가 호출되고, 그러면 다시 OutputDebugStringW가 호출되고, 다시 후킹 함수가 호출되고, 다시 OutputDebugStringW가 호출되고 하는 무한 재귀 루프에 빠져버립니다. 결국 스택을 다 소진할 때까지 반복하다 크래시가 발생하는 것이죠.

위와 같은 단순한 경우 외에도 좀 복잡한 경우도 있습니다. 후킹을 하는 대상 함수가 특정한 시스템 락을 획득한 상태에서 호출되는 함수이고, 후킹 함수 내에서 호출하는 API가 그 락을 다시 요청하는 경우에 문제가 발생할 수 있습니다. 락이 재귀적으로 획득할 수 있도록 구성된 경우에는 문제가 없지만 재귀적으로 획득할 수 없도록 구성된 경우에는 문제가 발생할 수 있습니다.

그래서 저수준 API를 후킹하는 함수를 작성할 때에는 해당 후킹 함수 내부에서 호출하는 함수 중에 혹시나 다시 후킹 함수를 호출하게 될 가능성이 있는건 없는지를 꼼꼼히 살펴야 합니다. 물론 함수를 본다고 해당 함수가 어떤 내부 함수를 호출하는지를 다 알수는 없는 법이죠. 결론은 그냥 후킹 함수는 최대한 간단하게 작성하는 것이 좋습니다. 없는듯이 작성하고, 복잡한 연산은 훅 함수가 아닌 다른 곳에서 처리하도록 보류 시키는 것이 좋은 전략입니다. 당연한 소리지만 그것보다 더 좋은 전략은 후킹을 사용하지 않는 겁니다.

[소고] 메일 메트릭

Thu, 19 Jun 2014 23:59:42 GMT

난 엄마 뱃속부터 테일러리즘을 싫어했다고 느낀다. 2008년 여름 처음 팀장이 되면서 약간의 관리 업무를 맡게 될 당시에도 그런 생각은 확고했다. 자유와 여유, 그 모든 것이 주어진다면 인간은 무한대의 창조성을 발휘할 것이라 믿었다. 동일한 환경이 주어진다면 모두 공평하게 노력할 것이라 생각했다. 그렇게 몇년이 흘렀다. 안타깝게도 나의 가설은 틀린 것처럼 보였다. 2011년 10월에 작성한 아래 노트는 그런 생각 변화를 보여준다.

2011년 10월에 작성한 노트

물론 난 지금도 테일러리즘을 싫어한다. 그리고 인간이 인간을 관리한다는 생각 자체도 너무 우습다고 생각한다. 똑같은 인간끼리 뭘 관리한다는 말인가? 하지만 기존의 생각과는 다른 몇 가지 생각은 확실하게 변했는데, 그 중 하나가 일등은 일등대로의 방식이 있고, 꼴찌는 꼴찌의 방식이 있다는 생각이다. 많은 교과서에서 말하는 좋은 기업의 조건이나 관리 방식은 사실상 내가 생각했을 때에는 일등의 방식이다. 최고의 인재를 모아서 물쓰듯 자본을 쓸 수 있는 환경에서나 가능한 일들이란 이야기다. 동일한 사항을 그렇지 않은 환경에 적용한다면 당연히 여러가지 문제점이 발생할 수 밖에 없다.

어쨌든 그맘때부터 난 한 가지 생각은 뚜렸했다. 1) 사람은 관리할 수 없지만 업무는 관리할 수 있다. 2) 측정 불가능한 업무는 관리 불가능하다. 3) 자동화된 측정이 아닌 사람을 통한 측정은 효과가 불투명하다. 이런 전제 아래에서 나는 업무와 관련된 상당히 많은 데이터를 수집하고 분석하기 시작했다. 일부는 직원들에게 공유하기도 했고, 일부는 그냥 혼자 데이터를 보고 넘기기도 하는 형태다. 이런 내용을 토대로 한 가지 발견한 사실은 직원들의 업무에는 종류를 불문하고 엄청난 양의 불균형이 존재하고, 그것에 대해서 대부분의 직원들은 자각하지 못한다는 사실이다. 그런 데이터 중에 하나가 메일 메트릭이다. 우리 회사 지원 업무의 상당수는 메일을 통해서 이루어지는데 그 업무 회수를 측정한 자료다.

7명의 직원이 근 한달간 메일 업무를 한 내용을 정리한 그래프다. 일반이라고 표시된 것은 업데이트가 아닌 일반 메일로 주로 업체에서 특정 사항에 대한 문의나 요청을 한 것에 대한 회신의 회수를 의미하고, 업데이트는 우리 제품의 새로운 업데이트 안내 메일을 발송한 회수를 표시한 것이다. 그러니 일반은 약간 (업체에 의해서 강제된) 비자발적 메일, 업데이트는 자발적 메일 발송이라고 볼 수 있다. 물론 업데이트 또한 요청에 의해서 발송되는 경우도 있기 때문에 100% 자발적 메일 발송이라고 보기에는 무리가 있다.

이 그래프를 살펴보면 눈에 확 들어오는 것은 당연 1번 직원이다. 이 직원이 지난 한 달간 발송한 모든 메일은 3번 직원부터 7번 직원까지의 메일을 다 합친 것 보다 많다. 자발적 메일 발송이라 볼 수 있는 업데이트의 경우는 그 정도가 더 심한데 1번 직원을 제외한 나머지 직원을 다 합친 수치와 맞먹는다는 점이다. 얜 뭐지? 슈퍼맨인가 하는 생각이 절로 들게 마련이다.

위 그래프는 해당 기간 동안에 하루 평균 몇 통의 메일을 보냈는지를 나타내는 그래프다. 1번 직원의 고충이 좀 더 선명하게 드러나는데 나머지 직원과의 비교는 둘째 치더라도 이 직원이 하루 평균 7통의 메일을 보낸다는 사실에서 심각한 격무에 시달리고 있음을 알 수 있다. 8시간 근무라고 가정했을 때 통상적으로 한 시간에 한 통의 메일을 보냈다는 점이다. 업무 일수가 아닌 단순 기간으로 나눈 통계이기 때문에 업무 일수로 나눈다면 그 정도가 훨씬 심해질 것이다. 실제로 1번 직원은 “요즘 정말 정신없이 바빠서 뭔가 다른 걸 생각할 엄두가 나지 않는다”라는 이야기를 했다. 그말이 그저 하는 엄살은 아니라는 걸 보여주는 그래프인 것 같아 더 씁쓸하다.

이쯤되면 몇 가지 생각이 들게 마련이다. 왜 이 친구들은 동일한 업무를 수행함에 있어서 이 정도로 심각한 불평등 상황에 직면했는데 이 상황을 개선하려고 하지 않을까가 그 첫번째 의문이다. 이 정도면 사실 데이터를 뽑지 않아도 1번 직원이 과도하게 격무에 시달린다는 생각을 할 법하고 업무 배분을 좀 더 새롭게 할수도 있을 것 같은데 그러지 않는다는 점이다. 두번째는 왜 다른 직원들은 1번 직원의 이런 초과 업무에 대해서 도와주지 않을까라는 생각이 들기도 한다. 옆에 동료가 평균 한 시간에 한통의 메일을 써야 할 정도로 정신이 없다면 옆에서 보기 딱해서라도 몇 개 정도는 내가 도와줄게요라고 말할수도 있지 않을까하는 점이다. 그런데 대부분의 경우 그런 일은 거의 벌어지지 않는다. 물론 그렇다고 사이가 좋지 않은 것은 아니다. 옆에서 보기엔 참 화기애애해 보인다.

이런 모든 걸 차치하고서라도 내가 생각하기에 더 재미난 사실은 저 업무에 참여한 모든 직원이 다들 우린 똑같이 힘들다고 말한다는 점이다. 3, 4, 5번 직원은 비슷한 수준의 업무 강도를 느끼고 있다고 생각할 수 있지만 그들이 1, 2번 직원과 똑같이 힘들다고 한다면 그건 분명 공평한 일은 아니다. 그런데 이상하게도 보상에 아주 근소한 차이가 있다면 3, 4, 5, 6, 7번 직원은 불만을 느끼거나, 불공평하다고 느끼거나, 내가 개인적인 친밀감 같은 것을 토대로 잘못된 판단을 내리고 있다고 생각한다. 그러니 이 상황에서 공정한 보상이 주어진다면 1, 2번 직원은 다소 실망할 것이고, 불균등한 보상이 주어진다면 3, 4, 5, 6, 7번 직원이 실망할 것이다. 벤담의 공리주의를 따른다면 균등한 보상이 주어지는 것이 맞는 상황인 것이다. 하지만 쳐다보는 입장은 또 그게 마음이 편하진 않다. 그래서 다른 부분에서 그들이 더 보상을 받을 수 있도록 기회적인 요소를 추가해서 균형을 맞추고 싶어한다. 그런데 또 웃긴것은 기회적인 요소를 여기에다 추가를 하면 그 기회에서 제외된 나머지 직원들은 내가 친밀감 따위를 토대로 기회를 제공하는 사람이라고 생각해 버린다는 것이다. 그러니 모두가 공평하게 행복한 상황은 애초에 만들 수가 없다.

상황을 좀 더 세밀하게 이해하기 위해서는 결과만 바라볼 것이 아닌 원인도 같이 고려해야 한다. 그런 이면을 보여주는 것이 이 그래프다. 그래프는 지난 한달간 우리에게 적어도 1회 이상 요청 메일을 보낸 업체를 보여주고 있다. 60여개 정도의 업체에서 1통 이상의 요청이나 문의 메일을 보냈는데 살펴보면 데이터가 좀 재미있다. 바로 요청의 대부분을 자주 요청하는 업체에서 거의 독식하고 있다는 점이다. 특히나 1위를 기록한 업체는 근 100여번의 요청을 했는데, 전체에서 차지하는 비중이 무려 16%에 이른다. 당연한 이야기겠지만 그 업체 담당자가 1번 직원이다. 이 업체는 일 평균 2.43통의 요청 메일을 보냈는데, 내가 생각하기에 거기에 병목 지점이 있다. 즉, 그 업체가 지속적으로 뭔가를 요청하는 메일을 보낸다는 것은 상황이 좋지 않다는 것을 의미하기 때문이다. 우리에게 요청을하지 않아도 문제를 해결할 수 있도록 개선된다면 100통의 메일을 처리할 필요가 없어진다는 점이다. 그리고 실제로 그 업체에서 요청하는 상당수 메일을 살펴보면 개선할 여지가 있는 요청 메일이다.

물론 1번 업체의 요청 메일 하나를 개선한다고 1번 직원의 격무가 사라지는 것은 아니다. 어느 정도 완화되겠지만 그 요청 메일을 차치하더라도 다른 직원과의 격차는 굉장히 크다. 당연히 유능한 관리자라면 그 격차가 줄 수 있도록 방향을 제시해 주어야 한다. 가장 이상적인 상태라면 저 모든 직원들이 일 평균 3통 정도의 메일을 처리하는 상태라 할 수 있을 것이다. 그 이상이 넘어간다면 추가 인원 투입이 필요한 시점이라고 할 수 있다. 하지만 테일러 할아버지, 아니 고조 할아버지가 와도 저 상황을 개선할 수는 없다. 아주 잠깐 동안의 평형 상태는 만들 수 있어도 한달만 지나면 딱 지금의 그래프와 똑같은 상황이 만들어지기 때문이다. 실제로 과거 데이터가 그것을 말해주고 있다. 이 업무가 균등해지기 위한 유일한 길은 업무에 참여하는 모든 사람이 불균등함이 존재한다는 사실을 인정하고 그걸 개선하려고 노력할 때에만 가능하다.

종종 직원들한테 하는 이야기 중에 하나가 체인이 빠진 자전거 바퀴를 돌리고 있는 것 같다는 말이 있다. 우리 회사 직원들은 다들 열심히 일한다. 옆에서 보기 안스러울 정도로 열심이다. 그런데 가끔 그 이면을 살펴보면 체인이 빠진 자전거 바퀴를 열심히 돌리고 있는 것 같아서 씁쓸할 때가 많다. 조금만 변화를 주어도 극적으로 상황을 개선할 수 있음에도 그런 변화를 아무도 만들려고 하지 않는다. 그저 바퀴를 더 열심히 굴리는 일에만 집중할 뿐이다. 현실에 치여서 그러질 못한다는 이야기를 많이 하는데 그래서는 전투에선 이길 수 있을지 몰라도 전쟁에서는 패할 수 밖에 없다.

작은 업체는 항상 모든 게 부족하다. 돈도 부족하고, 사람도 부족하고, 시간도 부족하다. 예전에 우리가 1.0 버전을 만들고 있을 때 회사에 같이 계셨던 분은 그랬었다. 우리는 돈도 없고 사람도 없으니 1.0을 만드는 것 외에는 할 수 있는게 없다. 그때 난 모든게 부족해도 2.0을 설계하고 만들어야 한다는 이야기를 했었다. 아마 그때 우리가 1.0만 만들고 있었다면 지금도 1.0만 있거나 아니면 망했을 것이다. 현실이 아무리 각박하고 초라해도 미래를 위해서 일정 시간을 떼어내서 투자해야 한다. 다윗이 골리앗을 이기는 유일한 길이 바로 거기에 있기 때문이다.

언젠간 우리 회사 직원들도 다들 이런 생각을 가졌으면 좋겠다는 생각을 해본다. 스스로 자신의 업무를 측정하고, 분석해서 문제점을 찾고, 개선해 나갈 수 있는 방향을 토론하는 그런 분위기가 된다면 더할 나위 없이 좋겠다는 생각도 해보지만 한편으론 너무 많은 것을 바라는 건 아닐까라는 생각에 조심스럽기도 하다.

Allman Style

Wed, 18 Jun 2014 23:59:41 GMT

Allman vs K&R

답없는 종교 전쟁을 또 다시 시작하자는 이야기는 아니구요. 페북에 재미난 그림이 있어서 퍼왔습니다. Allman과 K&R 스타일을 비교한 것 같은데요. 전 개인적으론 Allman 스타일을 선호합니다. 이유는 위키 페이지에 나와 있는 아래 코드와 같은 장점들 때문입니다.

//while (x == y)
{
    something();
    somethingelse();
}

//for (int i=0; i < x; i++)
//while (x == y)
if (x == y)
{
    something();
    somethingelse();
}

    char c;
#ifdef HAS_GETCH
    while ((c = getch()) != EOF)
#else
    while ((c = getchar()) != EOF)
#endif
    {
        do_something(c);
    }

결국 이 이야기 끝에는 블록 단위로 복사, 붙여넣기 편하다는 장점이 위치할 것 같습니다. K&R 스타일을 사용할 경우 블록 단위 복사, 붙여넣기를 하려면 결국 셀 선택을 해야하는 불편함이 있거든요. 물론 이런 이야기를 하면 사이비 프로그래머니까 창조성 없는 복붙 프로그래밍이나 하는것 아니냐는 반론을 감수하긴 해야겠지요. 창조적인 프로그래머 아저씨, 리누스 토발즈옹은 K&R에 대한 신념을 언급한 적이 있었지요.

C 스타일과 관련돼서 항상 튀어나오는 다른 이슈는 괄호를 어디다 위치시키냐 하는 것이다. 인덴트 사이즈와 다르게, 다른 것을 배제하고 한 가지 배치 전략을 선택하는 것은 아주 조금의 기술적인 이유밖에 없다. 그러나 좋아라 하는 방법은 열기 괄호는 라인 끝에 위치시키고, 닫기 괄호는 라인의 처음에 위치시키는 것이다. 이러한 방법은 커닝헌과 리치와 같은 선지자들이 우리에게 보여준 것이기도 하다. 아래와 같이 될 것 이다.

if (x is true) {

we do y

}

그러나, 거기에는 함수라는 한가지 특별한 경우가 있다. : 그것들은 다음과 같이 열기 괄호를 다음 줄의 시작에 위치시킨다.

int function(int x)

{

body of function

}

전세계에 분포한 이단자들은 이것은 모순이다... 음 불완전하다...,라는 주장을 펼친다. 그러나 바르게 생각하는 모든 사람은 (a) K&R은 올바르며 (b) K&R도 옳다는 것을 알고 있다. 게다가, 함수는 어쨌든 특별하다 (C에서 함수는 중첩이 불가능하다).

리눅스 커널 코딩 스타일, 리누스 토발즈

여러분은 어떤 스타일을 선호하시나요? 특별한 이유가 있으신가요?

[소고] 분급

Tue, 17 Jun 2014 23:59:40 GMT

정동진, 이곳이 해가 뜨는 곳이기에…

부디 좋은 곳에서 편히 쉬시길…

정동진에서 서른네 살의 노동자가 자살했다. “이곳이 해가 뜨는 곳이기에”라는 말을 유서에 남겼다. “더 이상 누구의 희생도 아픔도 보지 못하겠으며 조합원들의 힘든 모습도 보지 못하겠기에 절 바칩니다”라는 말도 유서에 적혀 있다. 막 꽃피어야 할 한창나이의 젊음이 자신의 최후로 선택한 정동진엔 오늘도 변함없이 해가 뜬다. 그가 전하고 싶었던 소망과 절망감을 다시 또 알려주기라도 하는 듯이.

삼성전자서비스 직원인 그의 지난달 월급은 45만원 정도였다고 한다. 그 전달에는 70여만원이었다. 분당으로 받는 급여를 뜻하는 ‘분급’에 의해 지급된 것이라 한다. 분급이라는 말. 근래 들어본 가장 끔찍한 단어이다. 이런 임금체계를 현실로 시스템화하는 곳이 바로 삼성이다. 이동시간, 고객에게 설명하는 시간, 수리 준비 시간 등을 다 빼고 오직 제품 고치는 시간만 계산해 1분당 225원을 받는 노동자라니. 이런 끔찍한 착취 앞에 저항하지 못한다면 우리는 대체 누구이며, 내일은 또 무엇을 할 수 있을까. 무노조 경영의 악착같은 착취를 ‘초일류기업’의 세련된 이미지로 포장하는 이건희 일가의 재산 13조원을 만들어준 노동자들 중 누구는 백혈병과 희귀병으로 죽어가고 누구는 견디다 못한 자살로 죽어간다.

전세계 139개 나라 중 한국의 노동권이 최하위인 5등급으로 분류되었다는 뉴스가 흘러나온다. 여기가 대한민국호가 서 있는 자리다. 해 뜨는 곳 정동진으로 노랗게 해가 진다.

-- 한겨레, 김선우 시인·소설가

얼마 전 “코딩 호러가 들려주는 진짜 소프트웨어 개발 이야기”란 책을 사러 서점을 가는 길에 서점에 책이 없을 수도 있겠다 싶어서 지하철 앞에서는 핸펀으로 재고 검색을 하다 핸펀을 떨어뜨렸다. 핸펀을 바닥과 접촉시키는 일이야 늘상 벌어지지만 그날은 재수가 없었는지 액정이 깨져 버렸다. 갤럭시 S4 LTE-A, 산지도 얼마 안된 핸펀 액정이 또 깨지다뉘. 절망하면서 핸펀을 다시 켜는데 어랏. 액정이 아예 켜지지도 않았다. 진짜 액정이 깨진 것이다. 액정 앞에 강화유리(?!)가 깨진게 아니라. 고약한 일이 벌어진 것이다.

이를 어쩌지 하면서 삼성전자 서비스 센터를 갔다. 서비스 센터 앞에서는 전형적인 블랙 컨슈머 흉내를 낸다. 천연덕스럽게 액정이 안 나와서 왔다며 바보 코스프레에 들어갔다. 센터 직원 아저씨가 친절하게 안경 닦는 천으로 닦더니 안이 깨져서 화면이 나오질 않는다고 외부에서 충격을 가한 것 같다는 설명을 덧붙였다. 모르겠다는 표정을 지으니 오른쪽 모서리에 스크래치가 난 자국을 문제 삼으며 이쪽으로 충격이 가해지면서 안에 있는 액정이 깨졌을 것이란 놀랍도록 정확한 추론을 펼쳤다. 난 여전히 모르겠다는 표정을 지으며 오른쪽 모서리는 원래 그랬고, 충격을 가한 적도 없으며, 그 충격을 가해서 안쪽 액정이 깨졌다는 것을 내가 증명해야 하는 문제냐고 했다. 증명이란 단어에 아저씨는 머리가 조금 아파하는 표정을 짓더니 안에다 물어보고 오겠다고 했다. 그리곤 잠시 후 나오더니 원래 공짜로 되지 않는 것인데 애매한 상황이라 공짜로 해주는 것이라며 10만원 상당의 액정 모듈 교체를 공짜로 해주었다. 친절 사원 쓰는 곳에 난 센터 직원 아저씨 이름 옆에 짱짱맨을 적어주며 기분 좋게 나왔다.

난 삼성이란 기업을 그다지 좋아하지 않았다. 그런데 그 공짜 수리 사건으로 급 호감이 갔다. 담에도 삼성 폰을 사야지 이러면서. 더 부끄러운 사실은 이 쪽팔린 공짜 수리 사건을 무슨 무용담이라도 되는양 의기양양하게 주변에 떠벌리고 다녔다는 점이다. 당연한 이야기겠지만 그 무용담에서 삼성이란 기업은 철저하게 착한 기업으로 각색돼 있었다. 물론 이런 행위에 드는 비용 일체가 핸드폰 가격에 포함돼 있고, 그래서 우리가 호구처럼 비싼 가격에 핸드폰을 사야한다는 사실을 모르지도 않는 사람이 그랬다는 사실이 더 창피할 뿐이다. 분급이란 기사를 보니 있으니 이런 나의 어리석은 행동이 더 민망하게 느껴졌다. 다음엔 꼭 LG 폰을 사야겠다. 옵지3가 잘 빠졌다.

죽은 고기만 먹기에 소녀가 죽기를 기다리는 독수리

내가 바라보는 자본주의의 민낯

난 자본주의를 딱 저 사진처럼 느낀다. 따스함이란 없는 무자비한 약육강식의 세계, 일말의 공정함도 기대하기는 힘든 시스템. 이건 비단 사용자와 노동자 사이의 관계에서만 그런 것은 아니다. 기업이 제품을 파는 일도 똑같다. 좋은 제품을 만들면 잘 팔릴 것 같지만 꼭 그렇지도 않다. 그 중간에 온갖 정치, 음해, 공작 같은 것들이 있고, 시장을 비정상적으로 왜곡시키는 광고나 마케팅 효과도 있기 때문이다. 지금 한껏 주가를 올리고 있는 그 표절 게임만 해도 그렇다. 지나가는 게임 개발자 100명에게 물어보면 100명 모두 그 게임이 그렇게 매출 순위가 높은 게임이 되는 건 공정하지 않다고 말할 것이다. 하지만 시장에서 그 게임은 엄청난 매출을 올리고 있다. 내가 바라보는 자본주의 시장은 그렇다. 제 아무리 좋은 걸 만들어도 하나도 못 팔 수도 있고, 쓰레기를 만들어도 날개 돋친 듯 팔릴 수도 있다.

가끔 직원들과 이야기를 하다보면 깜짝 놀랄때가 있는데, 그들이 나와는 정반대의 세계관을 가지고 있을때다. 자본주의 시스템에 대해서 굉장한 퐌타지와 이데아를 가지고 있는 경우라 할 수 있겠다. 난 그런 이야기를 들을 때마다 내가 세상을 너무 냉소적으로 바라보고 있거나 잘못 알고 있었던 것일까, 라는 생각을 했다. 왜냐하면 그들 말에 따르자면 구조조정이란 단어는 세상 밖으로 나오지도 않았을 것이고 전 지구를 협동조합이라는 가장 우수한 조직 시스템이 장악했을 것이기 때문이다. 그런데 현실은 뉴스에 감기처럼 달고 나오는 게 구조조정이고, 주식회사라는 시스템이 전 지구를 뒤덮었다.

이런 묘한 아이러니 속에서 난 도대체 왜일까라는 의문이 생겼고 자본주의를 좀 더 제대로 알아야 겠다는 생각에 얼마 전 “자본주의 이해하기”라는 책을 샀다. 이 책을 통해서 난 자본주의 시스템에 대해서 충격을 더 받게 되었는데 그 이유는 내가 무엇을 상상하든 그 이상으로 자본주의는 냉정하고 차갑고 비정하며, 또한 무기력한 시스템이었기 때문이었다. 그 중에 하나가 실업 문제에 대한 결론이었다. 사실 분급이라는 게 따지고 따지고 따지고 또 따지고 들어보면 좋은 일자리가 많이 없다는 결론으로 더 파고 들면 실업 문제로 귀결된다고 할 수 있다. 책에서는 실업에 대해서 아래와 같이 너무나도 냉혹한 결론을 너무나도 논리 정연하게 기술하고 있기에 일말의 반박을 할 여지조차 주지 않고 있었다. “고용주도 노동자들도 이러한 상황을 개선할 수 없다”라는 결론은 정말이지 떨떠름할 따름이다.

케인스는 이 논리를 거부했다. 그에 따르면 실업은 임금이 너무 높아서 생기는 문제가 아니라, 노동이 생산한 재화에 대한 수요가 너무 적기 때문에 발생하는 것이다. 그리고 “문제가 생산물에 대한 대한 수요가 불충분하기 때문이라면 해결책은 임금을 낮추는 것이 아니라 높이는 것”이라고 케인스는 말했다. 그는 사람들이 물건을 사기 위해 지불하는 소득의 근원이 임금이고 경제의 산출물에 대한 수요의 상당 부분이 바로 임금에 의해 뒷받침되므로, 고임금은 수요의 증가를 낳고, 수요의 증가가 이번에는 산출의 증가로, 고용의 증가로, 그리고 실업의 감소로 이어질 것이라고 생각했다.

케인스의 이론이 보여주는 것은 1) 자본주의는 실업을 해결할 수 있는 자동적 메커니즘을 갖고 있지 못하며, 2) 자본주의 경제에서 실업은 비자발적인 것이며 임금이 낮아진다고 해도 실업은 사라지지 않을 것이라는 점이다.

… 중략 …

셋째, 고용주의 입장에서 임금을 낮추는 것이 이윤 극대화에 도움이 되지 않을 수도 있다는 것이다. 최적 임금 w’보다 임금이 낮으면 단위 노동비용은 오히려 상승한다. 임금을 낮추어 비용을 절감할 수 있지만 그 결과 노동강도(e)가 낮아지고 산출량이 감소해 임금 하락으로 얻은 비용 절감분보다 노력 지출량 저하에 따른 손해가 더 커지기 때문이다. 즉 고용주는 임금을 w’이하로 낮출 유인을 갖지 않는다. 현재 임금수준 w’보다 낮은 수준에서도 기꺼이 일할 용의가 있는 사람들이 있더라도 이들을 낮은 임금으로 고용하려고 하지 않는다. 임금을 낮춤으로써 단위 노동비용이 상승할 것을 우려하기 때문이다. 이 결론은 중요하다. 바로 우리가 4장에서 본 케인스의 주장, 즉 실업자들이 현재보다 낮은 임금수준을 받아들일 용의가 있음에도 실업은 사라지지 않을 것이고, 바로 이 때문에 자본주의 경제에서 비자발적 실업은 보편적인 현상이라는 주장과 일맥상통하기 때문이다.

실업 상태에 놓여 있는 사람들이 현행 임금보다 낮은 임금을 받아들일 용의가 있음에도 일자리를 찾지 못한다는 사실은 자본주의사회에서 실업이 항구적일 수 있다는 것을 의미한다. 더 나아가 노동시장에서 초과 공급이 존재하는 상황에서도 임금이 더는 하락하지 않을 것임을 말해준다. 초과 공급이 존재하고 더 낮은 임금을 받아들일 준비가 되어 있음에도 아무도 이들을 데려가려고 하지 않는다. 고용주도 노동자들도 이러한 상황을 개선할 수 없다.

-- 자본주의 이해하기, 새뮤얼 보울스, 리처드 에드워즈, 프랭크 루스벨트

언젠가 친구네 회사가 회식비와 경비 일체에 대해서 3개월간 시험적으로 제한을 없앴다는 이야기를 했다. 즉, 회식 때 마음껏 먹고 마시고 놀아도 된다는 것이다. 니들이 한강에서 요트를 타고 선상 파뤼를 하며 회식을 하더라도 다 처리해 주겠다는 대인배적 마인드라 할 수 있겠다. 이 사건과 몇 가지 행동을 두고 친구 녀석은 회사 대표가 착한 사람 같다는 표현을 썼었다. 그때 난 그 사람이 절대 착하지 않다고 이야기를 했다. 그 사람이 그렇게 제한을 풀고 복지를 늘리고 하는 것도 다 이유가 있기 때문일거라는 막연한 소리만 했었다. 그런데 “자본주의 이해하기”라는 책을 보면 그 대표가 왜 그런 행동을 하는지를 너무나도 논리 정연하게 설명해 놓고 있다. 두 글자로 그 대표가 취하는 행동에 대해서 기술하고 있는데 단어가 너무 언짢아서 차마 여기다 옮겨 적기는 좀 그런 것 같다. 궁금하신 분들은 책을 사서 읽어 보도록 하자.

난 더 많은 사람들이 이런 책을 읽고 자본주의 시스템이 돌아가는 기본적인 원리나 생리에 대해서 알아야 한다고 생각한다. 현실을 사는데는 퐌타지나 이데아 보다는 이러한 차가운 진실들이 더 도움이 된다고 믿기 때문이다. 게임의 법칙을 알아야 게임에서 이길 확률이 올라갈 것이고, 적어도 지더라도 왜 졌는지 원인 분석은 될 테니까 말이다. 그런데 진짜 아이러니 한 사실은 이런 책을 읽지 말아야 할 사람들은 더 꼼꼼하게 밑줄 쳐가면서 읽고 정작 읽고 이해해야 할 사람들은 막연하게 퐌타지만 가지고 세상을 살아간다는 점이다.

1890년 촬영된 이 사진은 높다란 마천루 안에 은밀하게 숨겨진 뉴욕 빈곤층의 생활을 보여주고 있다.

노동자의 노령 연금과 의료비를 보장하려는 기업은 없었다.

법원 역시 작업 중 입은 재해는 노동자가 책임져야 하며 근로기준법은 위헌이라고 판결했다.

미국 노동자들은 거대한 기업 권력에 관해 이렇게 밝혔다.

우리는 투표를 통해 그들을 쓰러뜨릴 수 있지만 투표함은 그들이 점유하고 있죠.

우리는 법원에서 정의를 찾을 수 있지만 법원은 그들이 세운 겁니다.

… 중략 …

1903년 2월 대로우는 이렇게 변론했다.

미국의 문명이 광부와 노동자들의 굶주림으로 이루어졌고

겨우 열두서너살 된 아이가 먼지 날리는 무연탄 광산에서 석탄을 주워 생활을 영위한다면

빨리 이 문명을 포기하고 새로운 문명을 시작하는 것이 인류에게 좋을 것이다.

-- 기업의 힘 E04

자본주의 역사가 정확하게 어떻게 되는지는 모르겠지만 100년 전에도 지금과 비슷했던 것은 틀림이 없는 것 같다. 인간은 역사로부터 아무것도 배우지 못하는 존재라고들 한다. 그래서 역사는 반복되는지도 모르겠다. 불평등이 극에 달했던 시스템은 모두 파괴되고 붕괴되었다. 자본주의 시스템이 아슬아슬한 줄타기를 하며 계속 유지될지 아닐지는 모르겠지만 부디 힘을 가진 높으신 분들이 바리케이드의 역사를 잊지 않는 지혜를 가졌으면 하는 바램이다.

최고의 시절이자 최악의 시절, 지혜의 시대이자 어리석음의 시대였다. 믿음의 세기이자 의심의 세기였으며, 빛의 계절이자 어둠의 계절이었다. 희망의 봄이면서 곧 절망의 겨울이었다. 우리 앞에는 모든 것이 있었지만 한편으로 아무것도 없었다. 우리는 모두 천국으로 향해 가고자 했지만 우리는 엉뚱한 방향으로 걸었다. 말하자면, 지금과 너무 흡사하게, 그 시절 목청 큰 권위자들 역시 좋든 나쁘든 간에 오직 극단적인 비교로만 그 시대를 규정하려고 했다.

-- 두 도시 이야기, 찰스 디킨스

iOS 입문

Thu, 05 Jun 2014 23:59:39 GMT

Android 78.1%, iOS 17.6%, Windows Phone 3.0%, From IDC

아이폰 하면 무슨 느낌이 드시나요? 제가 처음 쓴 맛폰이 갤s였고, 그 담에 아이폰4를 썼습니다. 갤s 쓰다가 아이폰4를 쓰니 신세계였죠. 갤s는 좀 아니었거든요. 아이폰4는 그랬습니다. 견고하고 빈틈없고 단단했습니다. 된다고 약속한 기능은 확실하게 동작했습니다. 아이폰4를 쓰면서 음악이 튀는 현상을 저는 경험해 본 적이 없었습니다. 쓸만한 스마트폰이었습니다. 하지만 결정적인 단점이 있었는데 바로 제 폰이 아니라 잡스횽 폰 같다는 느낌이었습니다. 저는 폰에 있는 파일들이나 시스템 설정들 또는 제가 필요한 데이터를 알아서 잘 관리할 수 있음에도 아이폰은 저에게 그런 여지를 허락하지 않더군요. 윈도용 아이튠즈는 정말 가관이었습니다. 다시 안드로이드 폰으로 갈아탈 수 밖에 없었죠. 그렇게 안드로이드 입문을 한지도 일년 넘는 시간이 지났습니다.

그간 아이폰의 시장 점유율을 유심히 지켜보았습니다. 내심 속으로는 아이폰의 점유율이 과거 맥이 그랬던것처럼 쪼그라들길 바랬습니다. 하지만 그건 단순한 제 바램일 뿐이었습니다. 아이폰은 너무나 견고하게 자신만의 독자적인 세력과 점유율을 유지하고 있는 것처럼 보여집니다. 네 맞습니다. 아이폰 코딩을 시작할 시점이 됐다는 말이죠. 멀티 플랫폼 시대의 개발자는 정말 피곤한 직업인 것 같습니다. 과거 윈도우만 해도 먹고 사는데 문제가 없었던 시절이 그립네요. ㅋㅋ~

많은 사람들이 아이폰 보안이 좋다고 이야기합니다. 견고하다고 하죠. 안드로이드가 그렇게 두드려 맞는 동안에도 아이폰은 크게 이슈가 없었던 것 같습니다. 전 뭐 엔지니어로써 아이폰이라고 그닥 크게 보안성이 뛰어나다고 생각하진 않습니다. 막아 놓은 것들이 많고 사용자가 안드로이드 대비 적으니 덜 뚫린다고 생각하는 입장입니다. 어쨌든 그렇게 첩첩산중 막고 또 막고, 가리고 또 가리고, 숨기고 또 숨기고 해서 아이폰을 구매한 사용자에게는 제법 안전하다는 인식을 제공하고 있는 것 같습니다. 그렇다면 앱스토에 앱을 올리는 개발자 입장에서는 어떨까요?

알만한 사람들은 다 아는 치트계의 블루오션 iOS

맞습니다. 지옥이죠. 그 잘난 샌드박스 덕분에 여러분이 할 수 있는건 아마 거의 없을 겁니다. 아이폰을 구매한 사용자가 맘먹고 앱을 공격하겠다고 생각하는 순간 앱은 감옥(샌드박스) 속에서 속수무책 당할 수 밖에 없습니다. 요즘 치트 좀 하는 사람들은 다 공공연히 알고 있는 사실이지만 아이폰은 치트계의 진정한 블루오션입니다. 앱을 보호해 줄 그 어떤 보안장치도 없거든요. 여러가지 이유가 있지만 삼성 공화국인 국내에서는 사용자가 많지 않아서 다소 무시 당했다는 점도 한 몫 했다고 봅니다. 하지만 더이상 그렇게 방치하기에는 아이폰 점유율이 무시할 수준은 아닌 것 같습니다. 아이폰이 독점적인 점유율을 누리는 국가들도 있고, 탈옥을 하지 않고도 앱을 위변조해서 사용하는 기법들도 속속 등장하는 지금, 이제는 뭔가 필요할 때가 되긴 한 것 같습니다.

Objective-C도, BSD도, MACH도, 샌드박스도 아니었다. 최고의 진입장벽… 맥 그 자체!!!

치트의 공격에 손가락만 빨고 있는 여린 앱들을 위해서 iOS 연구를 시작했습니다. 맥 미니도 사고, 버렸던 아이폰4도 다시 켜서는 운영체제 업데이트도 했습니다. 애플에 개발자 등록도 하고 드디어 Xcode를 켰습니다. 이제 아이폰의 속살을 좀 들여다 볼까 하는데 난관에 봉착했습니다. 아이폰 개발은 그렇게 바로 시작할 수 있는게 아니더군요. 내 아이폰에 내가 만든 코드를 넣기 위해서는 여러 수십만 단계를 더 거쳐야 한다는 사실을 알게 되었습니다. 헐~ 블로그 검색질로 따라하면서 온갖 인증서를 만들고 온갖 디바이스 정보를 넣어서 등록을 했습니다. 드디어 모든 단계를 마쳤다고 생각했는데 거기가 또 끝이 아니더군요. 맥에서 아이폰을 인식하지 못하는 아스트랄한 상황이 벌어진 것이었습니다. Objective-C를 쳐다보기도 전에 탈진할 것 같은 상황. 모든 iOS 개발자들이 존경스러워지는 순간이었습니다.

장치관리자가 있긴 있는건지?! 이 상황을 어떻게 해야 하는건지 도무지 몰라서 맥 좀 사용한 친구 녀석한테 어케 해야 하냐고 물어봤더니 아이튠즈를 다시 설치하라고 하더군요. 그렇게 몇 번의 재부팅을 거치고 나서야 드디어 마법처럼 인식이 되었습니다. 아이폰4 화면에 텅 빈 Hello, World! 앱이 뜨는데 뻥 좀 보태서 예전 X 윈도우를 처음 띄우고는 X 아이콘을 마주했을 때처럼 눈물이 약간 났습니다.

어떤 시스템에서 동작하는 보안 솔루션을 만들기 위해서 제일 처음 검토해야 하는 것은 당연한 소리겠지만 우리가 할 수 있는 것과 할 수 없는 것을 구분하는 작업입니다. 그래야 그 시스템에서 우리가 만들 수 있는 것과 만들 수 없는 것을 명확하게 알 수 있거든요.

iOS의 속살을 파헤치기 전까지 저는 그저 안드로이드와 유사한 권한 체계를 통해서 운영체제를 구성했다고 생각했습니다. 다만 안드로이드가 읽기 권한을 줬다면 iOS는 읽기 권한 마저 제거했다고 어렴풋이 추측했을 뿐이었죠. 하지만 완전 번지수를 잘못 짚었던 착각이었습니다. iOS는 단지 리눅스/BSD의 기본 권한 체계를 사용한 권한 장난질로 샌드박스를 구현하고 있는 게 아니었습니다. 진짜 샌드박스가 있는 구조더군요. 이 말은 우리가 특정 파일에 접근할 수 있는 모든 권한을 가졌다 하더라도 샌드박스에서 그 파일 접근을 불허하면 파일 열기에 실패한다는 이야기입니다. 그럼 iOS 샌드박스가 어떤 것들을 제한하는지 한 번 살펴봅시다.

iOS — the Sandbox as a jail

Inability to break out of the app’s directory. The app effectively sees its own directory (/var/mobile/Applications/) as the root, similar to the chroot (2) system call. As a corollary, the app has no knowledge of any other installed apps, and cannot access system files.

역주: 너희 영역 말고는 쳐다볼 엄두도 내지 마셈. 백신?! 스캐너?! 만들 수도 없고 만들 필요도 없음.

Inability to access any other process on the system, even if that process is owned by the same UID. The app effectively sees itself as the only process executing on the system.

역주: 다른 프로세스 접근?! 꿈도 꾸지 마셈. 번지수 잘못 짚었음.

Inability to directly use any of the hardware devices without going through Apple’s Frameworks.

역주: 우리가 만들어 준 것만 우리한테 허락 받고 쓰셈. 필요해도 없으면 그냥 손가락만 빨도록…

Inability to dynamically generate code. The low-level implementations of the mmap (2) and mprotect (2) system calls are intentionally modified to circumvent any attempts to make writable memory pages also executable.

역주: 난독화? 그딴거 만들고 싶어도 못만들거임. 정 만들고 싶으면 인터프리터, 트랜슬레이터 정도 고려해보셈.

Inability to perform any operations but a subset of the ones allowed for the user mobile. Root permissions for an app (aside for Apple’s own) are unheard of.

역주: 우리 혼자 짱짱맨. 서드파티가 뭔가요? 씹어먹는 건가요?

– Mac OS X and iOS Internals, Jonathan Levin

말 그대로 감옥이죠. 되는 게 없다고 보는 게 맞는 것 같습니다. iOS는 아니지만 맥 OS의 샌드박스 기능이 궁금하신 분들은 The Apple Sandbox를 같이 참고해 보시면 도움이 될 것 같습니다.

iOS 샌드박스를 보면서 느낀 점은 구글과는 정말 철학 자체가 다르다는 생각이었습니다. 구글의 안드로이드는 아래 크로미움 샌드박스 디자인 원칙에 나와 있는 것처럼 기존의 있는 것을 활용하자는 생각이 강합니다. 바퀴를 새로 만들지 말자는 입장이죠. 그래서 안드로이드도 권한 장난질로 얄팍하게 흉내낸 샌드박스 구조로 되어 있습니다. 물론 세세하게 TrustedBSD까지 올라가서 바퀴를 누가 만들었냐를 따지자는 것도 아니고, 옳다 그르다를 따지자는 것도, 좋다 나쁘다를 가리자는 것도 아닙니다. 그간 애플의 행보를 보자면 바퀴를 새로 만드는 것을 좋아하는 것처럼 느껴졌다는 이야깁니다. 적어도 저한테는요…

Design principles

Do not re-invent the wheel: It is tempting to extend the OS kernel with a better security model. Don’t. Let the operating system apply its security to the objects it controls. On the other hand, it is OK to create application-level objects (abstractions) that have a custom security model.

역주: 기술 부심 부리겠다고 바퀴 따위 새로 발명하지 말자.

– Sandbox, The Chromium Projects

XIGNCODE3의 역사가 iOS에서도 함께합니다.

그닥 쉽지는 않았습니다. 맥을 새롭게 익히는 것도 Xcode에서 Objective-C++ 접착제 코드를 만드는 것도, BSD 시스템 콜을 익히는 것도요. BSD에서 시스템 프로그래밍을 해본 경험은 없고, 맥은 더더욱 새롭기에 이 생경한 시스템에 익숙해지는 것은 생각보다 쉽지 않았습니다. 물론 샌드박스도 한 몫 했지요. 여튼 그런 아주 험난한 과정을 거치긴 했지만 결국 우리가 안드로이드에서 사용했던 대다수 기법들이 거의 모두 아이폰에도 동일하게 적용할 수 있다는 사실을 확인했습니다. 이제 곧 XIGNCODE3 for iOS가 출시된다는 말이죠.

이 글이 재앙이 될 프로그래머 분들을 위해서 초콜렛을 하나 준비했습니다. 애플이 굉장히 폐쇄적인 줄 알았는데 생각보다 거의 오픈 소스에 가깝더군요. BSD 라이선스라 굳이 그럴 필요도 없을 것 같은데 말입니다.

xnu 커널 소스 코드

http://opensource.apple.com/source/xnu/xnu-2422.90.20/

top 소스 코드

http://opensource.apple.com/source/top/top-89.1.2/

ps 소스 코드

http://opensource.apple.com/source/adv_cmds/adv_cmds-153/ps/

일단 폰부터 테스트 하구요. 패드는 그 다음에 하는걸로…

애플빠는 아닙니다. 결코 ㅋ~

iOS 버전도 준비 중이신가요? 그럼 더더욱 XIGNCODE3죠.

느낌아니까… ㅋ~

[소고] 벌써 10년…

Sat, 31 May 2014 23:59:38 GMT

2004년 8월 28일. 병역특례의 끝이 한달여 남짓 남은 그때. 학교 선배가 서울을 왔다며 연락이 왔다. 취직이 잘 안 돼 고민하던 형이었는데 떡하니 대기업엘 붙었다는 이야기를 했다. 자축을 하자며 들떠 있던 우리는 만나서 몇 마디 하다가는 그 분을 보러 가자는 이야기를 했다. 계획도 없었고, 약속도 없었다. 그렇게 고속터미널에서는 대전행 버스를 탔다. 목적지는 KAIST. 우리의 정신적 지주였던 선배가 있던 곳이었다.

깜짝 놀래켜 주자며 출동한 우리는 금새 문제에 봉착했다. KAIST를 왔지만 정작 선배가 어느 건물에서 공부하는지도, 어디에 있는지도 몰랐던 것이다. 물어물어 선배의 연구실이 있는 곳을 찾았지만 문은 잠겨 있고 선배는 연락이 닿질 않았다. 서울에서 여기까지 왔는데 정말 아스트랄한 상황. 하지만 궁하면 통한다 했던가 겨우겨우 선배 본가의 전화 번호를 알아 내서는 연락을 했다. 어머니께서 받으셨는데 집에도 연락을 잘 하지는 않는데 아마 출강 갔을 거라는 이야기를 했다. 그리고는 지금쯤 도착할거라는 이야기를 덧붙였다. 여기까지 왔는데 어쩔 수 없는 노릇. 기다려 보기로 했다. 제법 지루할만큼 시간이 지났을 때였다. 마치 TV는 사랑을 싣고에 나오는 것처럼 멀리서 선배가 걸어오는 모습을 보게 되었다. 그렇게 기적처럼 우리는 KAIST에서 만났다.

우리가 찾아간 선배는 학교에서 기인으로 통하는 형이었다. 기계과로 입학해서는 전자과를 거쳐 컴공까지 왔다. 학교 다닐때 전산실에서 우연히 떠오른 아이디어를 ACM에 제출했는데 그해 최우수 논문상을 받았다. 형은 컴공과에 와서도 취미삼아 다른과에서 개설한 양자역학 수업을 들었다. 난 그당시 양자역학이 그렇게 어려운 학문인지도 몰랐다. 가난한 고학생임에도 IEEE를 정기 구독했었다. 도서관에서 무료로 볼 수 있는데도 말이다. IEEE를 아이트리플이라고 읽는다는 것도 형이 가르쳐줬었다 ㅋㅋ~ GRE를 치러 간다는 사람이 팔짱에는 능률보카를 끼고 있었고, 더 황당한 건 그러고도 GRE에서 상당히 높은 점수를 받았다는 사실이다. 시스템 프로그래밍 수업을 같이 들을 때였다. 내가 온갖 문자열 처리 함수로 SIC/XE 어셈블러를 주먹구구식으로 만들고 있을 때 형은 파스 트리라는 신세계를 나에게 보여줬었다. 형이 테이블에 명령어를 추가하자 마법같이 명령어들이 번역됐다.

컴공과 교수님 한분은 형에게 네 정체가 뭐냐는 질문을 했었고, 다른 교수님은 카멜레온 같다는 이야기를 했었다. 가난했지만 형은 자기 밥값을 털어서는 술값으로 용돈을 다 날려 책을 못사는 후배 책값을 대주는 그런 사람이었다. 말수는 적었지만 필요할때면 후배들에게 정말 멋진 이야기들을 한번씩 해주기도 했었다. 구도에서 공부를 할때면 종종 예쁜 여학생들이 같이 공부하자며 형에게 선물이며 추파를 던지곤 했는데 형은 절대로 넘어가는 법이 없었다. 형의 첫사랑은 고등학교 때였는데 그 여학생이 수녀가 됐다는 진짜 드라마 같은 이야기만 반복했다. 공부하는 머신이라고 놀려대면 형은 태연하게 그랬다. 대학교 1학년때 술마시고 모텔에서 수영한 적이 있었다고…

아무 연락도 없이 찾아온 우리가 귀찮을수도 있을텐데 형은 싫은 내색 하나 없이 KAIST 구석구석을 구경시켜 주었다. 구경하면서 드라마 카이스트와는 정말 다르구나 하는 생각만 연신 하고 있었다. 형은 그 당시 KAIST에서 석사 과정으로 안테나 공부를 하고 있었다. 여기 아이들은 과고 출신이라 빠르게 졸업한 애들이 많아서 어리고 똑똑한 친구가 정말 많다는 이야기를 했다. 우리가 우스개소리로 걔들이 똑똑하긴 한데 형이 1등이죠? 했더니, 형은 아주 해맑은 얼굴로 그렇긴 하다고 했다. 진짜 말 그대로 괴짜였고, 기인이었다.

그날 우리는 KAIST를 돌아다니며 정말 많은 이야기를 했었다. 그도 그럴것이 같이 간 형은 대기업에 입사해서는 이제 사회에 첫 진출을 하는터라 풍운의 꿈을 잔뜩 가지고 있었고, 난 지긋지긋한 병특이 끝나고 학교로 복학할 단꿈에 젖어 있었다. 안테나를 공부하던 선배는 얼른 석사를 마치고 미국으로 유학갈 꿈에 부풀어 있었다. 그렇게 20대의 우리는 모든 걸 가진듯 했고, 모든 걸 가질 수 있을 것 같다는 포부에 가득차 있었다. 이런 저런 이야기를 하다가 KAIST 어딘가에서 각자 독사진을 찍어주며 10년 후에는 뭘 하고 있을지 말해보자는 이야기를 했었다. 그리고 10년 후에 여기서 다시 보자며… (손발이 오그라드는 ㅋㅋㅋ)

나름 장난기 충만해서는, 또 나름 정말 진지하게 우리는 이야기를 했다. 취직한 형은 입사한 그 회사의 부사장이 되겠다고 했다. 왜 사장이 아니라 부사장인지는 좀 의문이다. 아마 그 당시에 사장은 너무 멀고 부사장 정도는 될 수 있다고 자신했던 것 같다. 난 제법 구체적이었는데 20명 정도 규모의 회사에 20-30억 매출하는 그런 벤처를 창업해서 CTO를 하겠다는 이야기를 했다. 내 이야기도 좀 웃긴데 창업을 하겠다고는 CEO가 아닌 CTO를 지목했다는 점이다. 우리의 정신적 지주였던 KAIST 선배는 ARM과 같은 회사를 창업하겠다는 이야기를 했다. 형은 ARM이 칩 설계만 하고 제조를 하지 않는 점과 그 일이 굉장한 고부가가치 사업이라는 점에 집중했었다. 형이 계속 해오던 일도 칩설계 쪽이라 뭔가 잘 맞는 것 같기도 했다. 근데 선배의 이야기에서도 의문인게 칩 설계하면 INTEL을 떠올릴법 한데 ARM을 지목했다는 점이다. 물론 지금에 와서는 ARM이 INTEL을 견제할정도로 컸지만 그 당시는 잘나가는 변방의 벤처 정도였다.

그렇다. 여기엔 한가지 공통점이 있었다. 우리는 모두 약간씩 마이너한 근성을 가지고 있었다는 점이다. 그래서 죽이 잘 맞았는지도 모를일이다. 어쨌든 2004년 8월 28일은 다소 그런 말도 안되는 꿈들을 이야기하고, 서로 그 정도는 할 수 있을거라며 다독거려주는 그런 따뜻한 여름 날이었다.

얼마 전 그때 같이 KAIST로 무작정 떠났던 학교 선배를 만났다. 둘이 마주 앉아서는 양꼬치를 뜯으며 이런 저런 이야기를 한다. 형은 지금까지 그때 입사한 회사를 다니고 있는데 지금은 다소 대기업에 회의적인 입장이 되었다. 거기다 최근에는 고강도의 구조조정이 시작되서 약간 사내 분위기가 살벌하다는 이야기를 했다. 요즘엔 첼로 연주에 한창 빠져 있는데 조금 있으면 연주회를 한다고 했다. 초대할테니 꼭 오라는 말을 덧붙였다. 그런 온갖 이야기 끝에 KAIST 선배 이야기가 또 올라왔다. 마주 앉은 형이 긁는다. 미쿡으로 가자고, 그때처럼 가서 놀래켜 주자고 말이다. 선배의 조언을 들으면 앞으로 10년은 또 문제 없이 헤쳐나갈 수 있을 것 같다고 했다. 그러고는 내가 가겠다면 자기는 갈 수 있다는 최후의 허세 카드를 작렬한다. 나도 질 수 없기에 알겠다고, 내가 연락처를 수소문 해보겠다며, 연락되면 바로 떠나자고 맞불을 놓았다.

헤어지고 집에 돌아와서는 구글에다 KAIST 선배의 영문 이름을 입력한다. MIT 연구소 페이지로 연결됐다. 거기에 형은 내가 아는 메일 주소로 기재돼 있었다. 2-3년 전 연락이 끊긴 그 메일 주소. 다시 메일을 보내볼까? 아니면 연구소에 형의 근황을 물어볼까? 하는 생각을 하다 그냥 관두기로 했다. 메일을 제대로 쓸 수 있는 정신이 아니었다.

진짜 말하는대로, 생각하는대로 되는게 인생이고 꿈이란 사실
10년 사이 내가 배운 한 가지

양꼬치 사건은 한때 호기로 남아 기억의 저편으로 넘어가고 있을 무렵이었다. 어젠가 그제 코드 여기저기를 수정하다 정말 오래된 코드가 Visual Studio에 로딩됐다. 바이너리를 변환하는 유틸리티 코드였다. 막내 녀석이 최근 해커들이 바이너리 파일에 있는 익스포트 이름과 디버그 정보에 있는 pdb 경로로 꿀을 빨고 있다는 제보를 했던 터라 그 부분을 지워버리는 코드를 추가하기 위해서 프로젝트를 열었던 것이다. 코드 수정 작업은 간단했다. 수정하고 테스트 하고 커밋을 하려는데 그 파일에 주석 처리된 함수가 마음에 걸렸다. 지워버릴까 라는 생각과 놔두자는 생각 사이의 갈등이었다. 아주 오래된 코드였지만 그때 기억이 선명하게 났기 때문이었다. 그날이 언제였는지 궁금해서 블로그를 뒤졌더니 날짜가 나왔다. 2008년 11월 19일. 그 주석 처리된 코드는 패딩을 제거하는 코드였다. 압축 효율이 떨어져서는 만들어놓고 주석 처리를 해둔 터였다. 시간이 참 많이 흘렀다는 감상에 잠시 젖었다 결국은 그 코드를 제거하지 않고 커밋했다.

몇년이 지났는지를 머리속으로 곰곰 헤아리다 다시 그 KAIST의 밤이 떠올랐다. 10년이 지났는지 안 지났는지가 궁금해진 것이다. 2004년 인거 같기도 하고 2003년인거 같기도 하고 그랬다. 그러다 그날 찍은 사진의 EXIF 정보에서 정확한 날짜와 시간을 알아냈다. 2004-08-28 21:06. 그랬다. 올해가 꼭 10년이 되는 해였다.

야심한 밤에 10년 전 어린 내가 꾸었던 꿈을 마주한다. 아마 그때는 벤처, CTO 이런 단어에 허세가 가득차 있었던 건 아닐까라는 생각에 웃음이 난다. 그리곤 이내 현재 상황과 그 꿈을 오버랩 시켜본다. 2006년 9월에 창업한 회사의 CTO가 되었고, 회사 규모도 그때 내가 예측했던 범주에 다가가고 있다. 이제는 사실 그 꿈이 불가능보다는 가능이 훨씬 더 쉬운 상황이 돼 버렸구나 하는 느낌이 들었다. 신기한 사실은 그 꿈을 그때 이후로 상기한 적이 거의 없었는데 현재 상황이 그때 내가 말한 상황과 얼추 비슷한 시츄에이션이 됐다는 점이다. 시크릿의 끌어당김의 법칙 같은 말들을 개소리로 치부하면서 사는 입장인데 그 순간 만큼은 진짜 그런게 있는것도 아닐까라는 느낌이 잠시 들었다.

형들도 그날 이야기들을 기억하고 있을지를 추측해본다. 그리곤 이내 우리가 진짜 다시 10년 만에 재회한다면 이번엔 무슨 꿈을 말할지를 곰곰 떠올려본다. 내가 지난 10년간 배운게 있다면 진짜 생각하는대로 말하는대로 이루어진다는 것이다. 그래서 감당하기 힘들만큼 아주 큰 꿈을 말할지 아니면 그저 소박한 꿈을 말하는 것이 좋을지가 고민됐다. 어떤 걸 말하는게 좋을지 정하진 못했지만 진짜 신중하게 말해야 겠다는 다짐은 분명히 했다.

꿈이 없는 시대라고 한다. 이제 더 이상 예전 세대의 영광은 없을 거라는 말들을 한다. 하지만 피끓는 청춘들은 지금 이 순간에도 어디에선가 우리가 10년전 그랬던 것처럼 미래를 꿈꾸며 이런 저런 이야기를 하고 있을 것 같다. 그런 청춘들에게 꼭 하나 보여주고 싶은게 있다. 회사를 같이 창업해서 지금 대표를 하고 있는 형이 몇 해전 우리가 아주 힘든 시기를 지나고 있을 때 메일로 보내준 “‘포기[抛棄]’에 관한 단상[斷想] …” 이라는 웹툰이다. 그 웹툰을 보면서 우린 쪽팔리지 말자는 이야기를 했었다.

모든 꿈이 그렇겠지만 이루어 나가는 과정은 그리 순탄하지도 않고 녹록하지도 않을 수 밖에 없다. 그 험난한 과정을 버티기 위해서 가장 먼저 구비해야 하는 아이템이 있다면 아마 ‘인내’가 아닐까라는 생각을 해본다.

중요한 신제품을 만들어내는 것은 대개 시간이 걸리는 일이다. 프렌드피드는 6년 전의 지메일이 그랬던 것처럼 지속적인 변화와 개선을 필요로 한다. 프렌드피드는 많은 가능성을 보여주고 있지만 아직은 “성장하고 있는 중”이다.

내가 기대하는 바는 커다란 성공이라는 것이 여러 해에 걸친 노력을 요구하는 일이며, 이러한 원칙에 반하는 예는 (아직 제대로 된 수입을 올리지 못하고 있는 유튜브 정도를 제외하면) 거의 없다는 사실이다. 페이스북은 매우 빠르게 성장했지만 사실은 벌써 5년 정도가 지났다. 래리와 세르게이는 구글을 1996년에 시작했는데, 내가 1999년부터 구글에서 근무하기 시작했을 때만 해도 구글을 아는 사람은 별로 없었다.

하룻밤 사이에 성공을 거둔다는 개념은 상당히 왜곡된 생각이며, 심지어 위험하기까지 하다. 뭔가 새로운 것을 시작한다면 멀고 긴 여행을 염두에 둬야 한다. 물론 굼뜨게 행동하는 것을 변명하려는 것은 아니다. 그와 반대로 매우 빠르게 움직여야 한다. 그렇게 하지 않으면 그것은 너무나 먼 장거리 여행이라서 목적지에 도달하지 못할 수도 있다! 근검절약 정신이 중요한 것도 같은 이유에서다. 산의 중턱에 도달했을 때 먹을 것이 다 떨어져서 굶어죽기를 바라는 사람은 아무도 없기 때문이다.

– Overnight success takes a long time, Paul Buchheit

불이 켜지지 않는다고 조급해 할 필요는 없다.

**모든 배선이 끝나면 불은 마법처럼 한 순간에 들어온다.**포기하지 않고 한땀 한땀 열심히 배선을 해야 하는 이유가 거기에 있다.

[소고] 증명 하기…

Mon, 26 May 2014 23:59:37 GMT

올초에 경리 면접을 볼 때였다. 대표님과 둘이 회의실에 앉았다. 20대 중반의 대학을 갓 졸업한 파릇파릇한 여학생이 왔다. 면접 전에 이력서를 잠깐 훓어보았는데 굉장히 특이한 이력의 소유자였다. 경리를 채용하는데 무려 국립대학교 컴퓨터 공학과를 우수한 성적으로(?!) 졸업한 친구가 지원한 것이었다. 신기하다는 생각과 함께 면접을 시작했다. 사실 경리를 뽑는데 내가 물어볼 만한 질문이 크게 많지는 않다. 내가 경리 직원이 해야 하는 업무에 대해서 잘 아는 것도 아니고 추후에 업무 지시를 할 일이 많지도 않기 때문이다. 어떤 친구인지 보는 정도가 전부다. 3가지 정도 질문을 했던 것 같다. 우리 회사가 뭐하는 회사인지 아는지, 좋아하는 게임이 있는지, 컴퓨터 공학과를 졸업했는데 경리를 지원한 계기가 뭐냐 같은 것들…

그렇게 면접이 이어지는데 순간 이 모든 상황이 너무 우습다는 생각이 들었다. 왜냐하면 국립대학교 컴퓨터 공학과를 우수한 성적으로 졸업하고, 해외 봉사 활동을 했으며, 토익 성적도 나쁘지 않고, 다른 곳에서 인턴 경험까지 있는 이 친구가 조그만 업체의 연봉도 그다지 높지 않은 경리 자리를 꿰차기 위해서 자신의 이력서에 비어 있는 시간 동안에는 무엇을 했는지, 왜 그런 선택을 했는지를 일일이 답하고 있었기 때문이다. 오버스펙도 이런 오버스펙이 없을텐데. 그 친구는 그 자리에 앉아서는 나름 최선을 다해서 자신의 빈틈을 답변을 통해서 메우고 있었던 것이다.

그 상황이 더욱 아이러니하게 느껴졌던 이유는 그 친구를 선택할지 말지 고민하며 구름위의 심판자처럼 앉아 있는 두 사람이 불과 2-3시간 전에는 그다지 상황도 좋지 않은 중견기업 하청 업체 앞에서 똑같은 과정을 거치고 있었다는 점이다. 물론 그때는 그 두명이 온갖 것들에 대한 답변을 해주면서 자신들의 존재를 온몸으로 증명해야 하는 입장이었다. 그냥 그런 상황 자체가 너무 우습고 어처구니 없게 느껴졌다.

10년 전이었다. 부산에서 병특 자리를 알아보던 나는 부산에서 그나마 괜찮은 GIS 업체 면접실에 앉아 있었다. 임원 중에 포공 출신이 있었는지 면접 대기실엔 유달리 포공 학생들이 많았다. 다들 뭘 그리도 많이 출력해 왔는지 마치 그 많은 서류 더미들이 자신의 존재를 증명해 주기라도 하듯 신주단지 모시듯이 살펴보며 읽고 또 읽고, 외우고 또 외우고 있었다. 그리곤 종이 한 장 없이 뻘쭘하게 앉아 있는 나에게 무슨 프로젝트에 참여해 봤냐는 질문을 했다. 나는 참여해 본 프로젝트가 없다고 했다. 그러다 내 차례가 와서는 면접실로 이동했다. 면접실 그 자리… 나는 80만원 급여의 병특 자리를 얻기 위해 지난 여름 방학에 내가 캐나다 스탠리 파크에서 무얼 했는지까지 이야기를 해야 했다. 최종적으로 한명 뽑는 그 자리에 뽑혔지만, 일주일 정도 다니다 때려쳤다. 아직도 빈정거리는 말투로 질문을 하던 면접관의 인상이 선하다.

글쓰다 궁금해서 찾아봤더니 그 당시 그래도 나름 부산에서 잘 나가던 그 업체, 망했다.

이후에 이직을 하면서 면접을 서너 번 정도 더 볼 기회가 있었다. 그 모든 면접이 전부 그렇게 유쾌한 경험은 아니었다. 자신의 존재를 스스로 증명해야 하는 일이 원래 다 그렇게 비루하고 구차한 법이다. 그러면서 자연스레 나중엔 내가 증명을 하는 입장이 아닌 시키는 입장으로 살아야겠다는 생각을 했다. 당시엔 적어도 그게 편해 보였다.

대학교 4학년 여름 방학. 지인들 덕에 무리에 끼여서 창업을 할 수 있는 기회가 생겼다. 난 그때까지만해도 적어도 이 일이 나를 증명하는 입장에서 증명을 시키는 입장으로 바꿔줄거라 믿었다. 인생을 온통 핑크빛으로 낙관하는 풋내기 20대였던 나는 아무 생각 없이 그렇게 창업에 동참했다.

하지만 사업을 시작한다는 것은 그 어떤 일보다 더 많은 증명을 나에게 요구했다. 스타트업이 제품을 만든다는 자체가 정말 상상도 못할 온갖 증명을 다해야 하는 일이란 걸 미처 몰랐던 것이다. 특히나 B2B 형태의 사업은 그 정도가 더 심하다. 넌더리 날 정도로 많은 증명을 필요로 한다. 이 제품이 실질적으로 효과가 있는지, 안정적인지 등에 관한 건 증명 축에도 끼지 못한다. 3-4년 전까지만 해도 내가 가장 빈번하게 그리고 가장 충격적으로 들었던 증명 요구 중에 하나는 회사가 망하지 않는다는 걸 증명하라는 이야기였다. 사실 그걸 어떻게 증명하겠는가? 미래에 벌어질 일을 내가 신도 아닌데 어떻게 개런티한단 말인가? 정말 터무니 없는 말이고 요구다. 그런데 그런 것들을 증명하고 다독이고 해야 겨우 한 카피 제품을 팔 수 있는게 사업이고, 시장이었다.

이건 여담인데 우리 이야기는 아니지만 모 업체는 외국 회사와 계약하면서 대한민국에 전쟁이 나면 어떻게 하냐는 이야기를 들었다고 한다. 그런데 더 황당한건 그 업체는 그 상황에 대한 대안을 증명함으로써 그 거래를 성사시켰다는 이야기. 이런게 B2B다 ㅠㅜ~

그런 넌더리 나는 요구들에 대해서 때로는 증명하며, 때로는 영업력으로 뛰어 넘으며 몇 년 동안 착실히 일했다. 그 시간 동안 우리는 적어도 두개 정도 제품에 대해서 제품-시장 핏을 달성했다고 생각한다. 그말인 즉슨 그 제품들에 대해서는 더이상 과도하게 불필요한 증명 요구를 받지는 않는다는 이야기고, 제품의 기능적인 측면외의 부차적인 것들이 우리의 발목을 잡는 회수가 많이 줄었다는 의미다. 어쨌든 스스로 뭔가를 증명하지 않아도 알아주는 사람들이 있다는 것은 분명 행복한 일이다.

그렇게 한동안 증명이 뭔지를 잊고 살았던 나에게 오늘 한 장의 페이퍼가 도착했다. 종이에 씌여진 질문들의 면면을 살펴본다. 종이에 씌여진 질문들이 향하는 지점은 한 곳이다. 너네 회사가 얼마나 괜찮은 회사인지, 얼마나 기술력이 있는 회사인지를 증명하라는 이야기다. 잊었던 증명을 또 해야 하는 상황이 왔구나라는 생각. 페이퍼에 소설을 몇 자 끄적이다 다짐했다. 기필코 반드시 몇 년 후에는 이 따위 증명을 다시는 요구 받지 않겠노라고…

면접을 보던 경리, 업체 앞에서 프리젠테이션을 하던 우리, 그리고 그 수많은 제품 판매 과정들을 생각해 본다. 지긋지긋한 증명을 해야 하는 과정은 끝이 없어 보인다. 그러다 불현듯 그런 생각이 들었다. 이 지긋지긋한 증명 요구를 끊을 수 있는 유일한 길은 세상에서 요구하는 그 모든 것에 대해서 미리 다 증명을 해 놓는게 아닌가라는 생각?!

… 생각의 퀀텀 점프 …

많은 프로그래머들이 오픈 소스 활동을 하는 것에 회의적이다. 당장 돈이 되지 않는 일이기도 하고, 현업에 치여서 바쁜데 그런 것까지 할 시간이 있겠냐는 생각이 지배적이다. 하지만 증명이란 관점에서 바라보면 좀 다른 생각이 든다. 오픈 소스 활동을 시작하고 그것이 쌓이는 순간 적어도 우리가 칠판 앞에 서서는 내가 이 바보같은 문제를 풀 수 있는 사람인지 아닌지, 리스트에서 성이 “김”씨인 사람이 몇 명인지 헤아리는 프로그램을 작성할 수 있는 사람인지 아닌지, 멀티스레드 환경에서 동기화 처리를 할 줄 아는 사람인지 아닌지 따위를 증명하기 위해서 시간 낭비를 하지는 않아도 될 것이라는 생각말이다.

github 계정을 만들고 그간 만들어 두었던 조악한 소스 코드라도 업로드를 해야겠다는 다짐을 했다. 적어도 그 작업들이 나중에 혹여나 프로그래머 신영진을 증명해야 하는 일이 생기더라도 그 귀찮은 작업들을 건너뛰게는 만들어줄거란 생각이 들어서였다.

앤디워홀은 이런 말을 했다고 한다.

유명해진다는 건 어쩌면 자신이 앞으로 해야 할 모든 증명을 한순간에 다 해버리는건 아닐까?!

유튜브의 위엄: 구글 프로그래머가 돈을 많이 버는 이유

Wed, 21 May 2014 23:59:36 GMT

이것이 의미하는 것은, 복사본이 원본의 일부분이거나 느린 동작으로 실행되거나 오디오와 영상의 질을 낮춘다 해도 우리는 일치되는 것을 찾아낼 수 있다는 것입니다.

그리고 우리는 이것을 비디오가 유튜브에 등록 될 때마다 하는데 그것은 1분당 20시간 분량이 넘습니다. 이 시스템의 규모와 속도는 정말 엄청난 것입니다.

우리는 겨우 비디오 몇 개를 이야기하고 있는 것이 아닙니다. 우리는 지금 매일 업로드 되는 100년 분량 이상의 비디오들을 새롭게 업로드 되는 것들 및 기존의 비디오와 비교하는 것, 우리가 보통 말하는 사이트의 모든 내용을 스캔 하는 것을 이야기하고 있습니다.

이것은 36,000명의 사람들이 36,000개의 모니터를 매일매일 휴식 시간도 없이 들여다 보고 있는 것과 마찬가지 입니다.

– 유튜브는 저작권에 대하여 어떻게 생각하는가

정말 쩐다는 말 밖에는 안 나오네요. 구글 프로그래머는 분명히 기필코 반드시 외계인과 결탁했을 가능성이 농후합니다. 그렇지 않고서야… 이건 지구인의 기술력이 아니잖아요 ㅋㅋ~ 심심하신 분들은 제프 딘의 진실도 한 번 살펴보세요. 쓰러집니다. (다시 봐도 진짜 욱기네요 ㅋㅋㅋ)

닥터 이방인

Tue, 20 May 2014 23:59:35 GMT

개연성 (蓋然性)[개ː연썽]

[명사] <논리> 절대적으로 확실하지 않으나 아마 그럴 것이라고 생각되는 성질.

드라마 작가가 아직 개연성에 대해서 배우질 못한 듯. 꿈에서 생각나는 대로 써도 이거보다는 더 말이 되는 스토리가 나올것 같은 느낌?! 창작자에 대한 최소한의 존중을 하고 싶어도 이건 뭐 ㅠㅜ~ 의학, 정치, 스릴러, 액션, 히어로, 러브 스토리 다 짬뽕하고 싶었던 욕심이었을까? ㅋㅋ~

하도 기가차서 드라마 작가를 찾아보기는 또 첨인듯…

[소고] 덤프의 색깔을 찾아서…

Thu, 15 May 2014 23:59:34 GMT

덤프 이미지 분석은 내가 갑~ 왼쪽에 그림이 덤프 이미지입니다.

화욜날 간만에 댓글의 reinhard, zoops 횽들을 만나서 술을 한 잔 했습니다. 그러면서 이런저런 이야기를 하는데 reinhard 님께서 드미트리옹께서 크래시 덤프의 이미지를 만들어서 재미를 보고 계셨다는 이야기를 해주시더군요. 제가 또 드미트리옹과 페친 아니겠습니까? 드미트리옹의 책도 다 샀는데 눈 뜬 장님이었더군요. 책 표지 자체가 크래시 덤프 이미지였다는 사실을 알고는 충격과 공포에 빠졌습니다. 역시 사람은 아는만큼 보인다는 옛 이야기가 다 헛말이 아니었습니다. 핡~

그래서 저도 해봤습니다. 제가 가진 게임 덤프 파일 중에 하나를 돌려보았지요. 가운데 텅 빈 공간이 웬지 무한한 우주 공간에서 찰나의 순간을 살다가는 인간이라는 존재의 한없는 고독함을 나타내 주고 있는듯한 느낌입니다 ㅋㅋㅋ~

한 게임의 크래시 덤프

글을 보고는 바이너리를 이미지로 변환을 어떻게 하시는지 궁금해 하시는 분들이 계시는 듯 하여 소스 코드도 같이 올려드립니다. 지난 번에 작업한 스크립트 파일은 앞에 비트맵 헤더 붙이고 귀찮아서 뒤에다 0으로 전부 패딩을 넣었었는데요, 이번 버전은 비트맵 의도대로 중간 중간에 패딩을 넣도록 한 버전입니다. bin2img.py input.tar output.bmp 하시면 됩니다.

'''

	Copyright 2014 YoungJin Shin <codewiz@gmail.com>

	bin2img.py input.tar output.bmp

'''

import math
import struct
import sys

BPP = 24
BPP_BYTES = BPP / 8
BMP_HDR_SIZE = 14
DIB_HDR_SIZE = 40
DPI = 2835

def GetImageFileSize(sz):
	px = int(math.ceil(sz / float(BPP_BYTES)))
	wpx = int(math.ceil(math.sqrt(px)))

	xbytes = int(math.floor((wpx * BPP + 31) / 32.0) * 4)
	return (wpx * xbytes, wpx, wpx, xbytes)

def GetBmpHeader(sz, w, h):
	return struct.pack('=BBLHHLLLLHHLLLLLL'
						, 0x42
						, 0x4d
						, sz + BMP_HDR_SIZE + DIB_HDR_SIZE
						, 0
						, 0
						, BMP_HDR_SIZE + DIB_HDR_SIZE
						, DIB_HDR_SIZE
						, w
						, h
						, 1
						, BPP 
						, 0
						, sz
						, DPI
						, DPI
						, 0
						, 0)

def GetPadBuffer(sz):
	pad = ''
	for x in range(sz):
		pad += struct.pack('=B', 0)

	return pad

def BinaryToImage(bin_path, img_path):
	inf = open(bin_path, 'rb')
	buffer = inf.read()
	inf.close()

	buffer_size = len(buffer)

	fsz, w, h, wbytes_pad = GetImageFileSize(buffer_size)

	hdr = GetBmpHeader(fsz, w, h)

	outf = open(img_path, 'wb')
	outf.write(hdr)

	wbytes = w * BPP_BYTES
	pad_size = wbytes_pad - wbytes

	pos = 0
	for i in range(h):
		remain = buffer_size - pos
		if remain < wbytes:
			pad_size = wbytes_pad - remain

		outf.write(buffer[pos : pos + wbytes])

		outf.write(GetPadBuffer(pad_size))
		
		pos += wbytes

	outf.close()

if __name__ == "__main__":
	BinaryToImage(sys.argv[1], sys.argv[2])

[소고] 당신의 코드는 무슨 색깔인가요?

Sat, 10 May 2014 23:59:33 GMT

언젠가 학교 선배가 자바스크립트 코드 컨테스트에서 누군가가 코드 바이트를 줄이기 위해서 PNG에다 코드를 인코딩해서 사용했다는 이야기를 했습니다. 문득 그 이야기를 곱씹다가 내가 만든 코드는 무슨 색깔일까 하는 생각이 들더군요. 이 거대한 코드를 컬러로 바꾸면 무슨 그림이 나올까, 하는 생각. 그래서 한 번 해봤습니다.

XIGNCODE3 250M

레거시 코드를 제외한 XIGNCODE3 전체 소스 트리를 이미지로 변환한 겁니다. 어떤가요? 처음에 결과를 보고는 적잖게 당황했습니다. 내가 만든 코드가 이렇게 칙칙한 회색 빛깔이었다늬, 이러면서 말이죠. 결과를 보기 전까지 전 총쳔연색의 아주 아름다운 뭔가가 나타날거라 상상했거든요. 늘 상상과 현실은 거리가 있게 마련이죠 ㅋㅋ~ 그래도 뭔가 가로 줄무늬가 나이테 같기도 하고 퇴적암의 퇴적층 같기도 한 그런 느낌도 들긴 했습니다. 풉, 맞습니다. 우리만 당하고 있을 순 없죠. 다른 프로젝트 소스 트리에 대해서도 스크립트를 돌려봤습니다. ㅋㅋㅋ~

boost 150M

chromium 1.5G

XIGNCODE3 프로젝트는 그래도 밝은 편이었습니다. 부스트랑 크로미움 소스 코드에 비하면 말이죠 ㅋㅋㅋ~ 이 그림들을 보고 있노라뉘 이제부터 소스 코드에 대해서는 청사진(blue print)이 아니라 흑사진(black print)이라는 표현을 써야 할지도 모르겠습니다.

XIGNCODE3 250M

우중충한 그림들에 다소 충격을 받았을 여러분을 위해서 조금 희망적인 이야기가 필요할지도 모르겠습니다. 사실 회색빛깔이 전부는 아닙니다. 그 회색빛깔 사이로 무한 확대 작업을 해보면 실질적으로 그 내부에는 이와 같이 총천연색으로 이루어져 있거든요. 이쯤에서 채플린옹의 이야기를 한번 떠올려주면 되겠습니다.

Life is a tragedy when seen in close-up, but a comedy in long-shot.

인생은 가까이서 보면 비극이지만 멀리서 보면 희극이다.

– Charles Chaplin

매직아이같은 이 색깔의 코드는 무엇에 쓰는 물건일까요?

이 코드의 비밀을 알아낸 분은 codewiz at gmail.com으로 메일을 보내 주시면 감사하겠습니다.****같이 할만한 일이 있을지도 모르잖아요 ^^;;

[소고] 책임…

Thu, 08 May 2014 23:59:32 GMT

“제가 남 탓을 할 수 없는 까닭은 제가 최종 책임자이기 때문입니다. 책임은 제게 있습니다.” – 버락 오바마

사고 이튿날, 박근혜 대통령이 실종자 가족이 모여 있는 진도 실내체육관을 찾았다. 이 자리에서 대통령은 이런 말을 한다. “있을 수 없는 일이 일어난 데 대해 철저한 조사와 원인 규명을 해서, 책임질 사람은 모두 엄벌토록 할 것이다.” 많은 언론은 이 발언을 대통령의 단호한 의지를 보여준다는 식으로 보도했다.

하지만 이 발언의 핵심은 다른 데 있었다. 이 결정적 발언으로 대통령은, ‘시스템의 최종 책임자’에서 ‘구름 위의 심판자’로 자신을 옮겨놓았다. 시스템이 무너져내리는 가운데, 최종 책임자는 자신의 책임을 말하는 대신 ‘책임질 사람에 대한 색출 의지’를 과시하는 단죄자의 자리를 자연스럽게 차지했다. 침몰하는 시스템에서, 대통령은 그렇게 가장 먼저 ‘탈출’했다.

– 시사인

[소고] 클라우드의 역습

Sat, 03 May 2014 23:59:31 GMT

몇해전 클라우드에 관해서 깜찍한 글을 하나 썼었다. 제법 당시 상황을 잘 반영했는지 반응이 그리 나쁘지 않았다. 지금 시점에서 생각해보면 정말 깜찍한 글이 아닐 수 없다. 왜냐면 그 사이 우리는 거의 모든 서비스를 죄다 클라우드로 전환했기 때문이다. 더 아이러니한 사실은 세포 덩어리로 옮겼다는 점 ㅋㅋㅋ~ 한치 앞도 모르는게 사람 일이다. 어쨌든 지금 우리는 물리 서버 대비 거의 절반 가격에 서버를 돌리고 있다. 더 큰 대역폭의 네트워크 회선은 덤일뿐 ㅋ~

그간 만족하면서 잘 썼는데 오늘 장애가 발생했다. 처음에는 우리 문젠줄 알았는데 알고보니 클라우드 서비스 자체의 장애 상황인 것 같다. 열심히 고치고는 있는 것 같지만 4시간이 지나도 상황은 개선될 조짐조차 보이질 않고 ㅠㅜ~ 손가락만 빨고 앉아 있을 수 밖에 없는 작금의 사태가 참 안타깝다.

세상에 모든 것이 다 그렇지만 클라우드 또한 양날의 검이다. 편리한 만큼 문제가 생기면 손쓸 방법이 없는건… 거대 기업의 기술력을 믿을 뿐 ㅠㅜ~ 제발 한번만 살려주세요. 담부터는 비싸도 미쿡에다 서버를 만들겠습니다.

오늘의 교훈

**동아시아에는 서버를 만드는게 아니란다…**똑같은 상황이 미쿡과 동아시아에서 발생한다면 어디가 먼저 고쳐지겠니???

덧) 8시간만에 장애는 해결됐다. 그러고도 안 살아나서 초큼 당황했는데 침착하게 파워쉘로 강제 종료하고 켜니 잘 켜졌다. 서버가 다시 살아나서 천.만.다.행… 그래도 매 시간 서비스 상태를 알려주는 페이지를 통해서 작업 진행 상황을 알려줘서 덜 당황할 수 있었다. 역시MS. 우리가 손가락만 빨면서 침묵한건 함정 ㅠㅜ~

역린, 2014

Fri, 02 May 2014 23:59:30 GMT

작은 일도 무시하지 않고 최선을 다해야 한다.

작은 일에도 최선을 다하면 정성스럽게 된다.

정성스럽게 되면 겉에 배어 나오고

겉에 배어 나오면 겉으로 드러나고

겉으로 드러나면 이내 밝아지고

밝아지면 남을 감동시키고

남을 감동시키면 이내 변하게 되고

변하면 생육된다.

그러니 오직 세상에서 지극히 정성을 다하는 사람만이 나와 세상을 변하게 할 수 있는 것이다

– 중용 23장

소문난 잔치에 먹을 거 없다고 했던가? 그렇게 광고를 해댄 것에 비해서는 큰 임팩트는 없었던 영화. 내용이 인상 깊지도 않았고, 액션이 박진감 넘치지도 않았고, 영상이 화려하지도 않았다. 보고 나서 기억에 남는건 중용 23장과 한지민의 미모 정도?!

고전이 괜히 고전은 아니라는 생각. 그 어떤 상황 어떤 시대에 읽어도 의미가 통하는 걸 보면…

한지민은 이뻤다. 이건 팩트 ㅋ~

[소고] 게임 보안: 스프레드, 스프레드, 스프레드

Thu, 24 Apr 2014 23:59:29 GMT

#0

서울에서는 삼성전자 주식이 5만원에 거래되고, 부산에서는 삼성전자 주식이 8만원에 유통된다면 우리는 무엇을 할 수 있을까? 맞다. 채소 가게를 하는 아저씨도 서울에서 삼성전자 주식을 사서는 부산에서 그 주식을 모조리 팔아 버릴 것이다. 한 주를 팔 때마다 3만원의 차익이 생기기 때문이다. 말도 안되는 이야기 같지만 통신이 발달하지 않은 예전에는 흔하게 있었던 일이다. 말 그대로 정보가 돈이던 시절이었다.

하지만 통신이 발달했고 이제 더 이상 이런 말도 안되는 일은 벌어지지 않는다. 머나먼 미쿡 땅의 주식 가격도 소말리아나 대한민쿡이나 그놈이 그놈이다. 물론 요즘이라고 이런 일들이 아예 없는 것은 아니다. 우리가 인지하지 못하는 찰나의 순간을 컴퓨터가 포착해서는 이런 거래들을 성사시키곤 한다. 어쨌든 이렇게 차이가 발생하는 것을 두고 우리는 스프레드가 존재한다는 표현을 쓰곤 한다.

그런데 이 스프레드가 타이밍 만큼이나 게임 보안에서는 아주 중요한 이슈 중에 하나다. 솔루션 업체 입장에서는 스프레드를 제로에 가깝게 만드는 것이 중요하다. 어떻게 이것을 줄일 것이냐를 고민해야 하고, 이 스프레드를 적게 만드는 제품이 좋은 제품이라고 할 수 있다. 기술력이 유사한 제품이라면 이 스프레드 관리가 그 제품 평판의 전부라고 할 수 있을 정도로 굉장히 중요한 요소다.

#1

지금 밤 하늘에 찬란하게 빛나는 것 갈지만 600만년 전의 모습일수도 있다.

우라가 겪는 첫번째 스프레드는 시간 스프레드다. 무슨 이야기냐면 우리가 수집해서 관찰하는 해킹툴과 실제 게임에서 사용되는 해킹툴 사이에 존재하는 시간 차이를 의미한다. 안타깝게도 대부분의 게임 보안 업체는 게임사에서 수집한 내지는 신고 받은 해킹툴을 차단하는 패치를 만들어서 게임사에 전달하는 과정을 따른다. 별 문제 없어 보이는 이 과정속에 엄청난 함정이 숨어있다. 바로 시간이다. 왜냐하면 게임사에서 수집을 해서 게임 보안 업체에 전달을 할 정도면 사실 그 해킹툴은 버얼써 구석기시대 해킹툴일 가능성이 높기 때문이다.

이 정도로 느린 속도로 해킹툴을 추적해서는 답이 없다. 그래서 조금 똑똑한 게임 보안 업체들은 사람들을 고용해서 직접 해킹툴을 찾아 나선다. 처음에는 국내 해킹툴을 수집하기 위한 아르바이트생들을 고용한다. 그러다 사이트가 늘어나면서 어라 중국에서 해킹툴이 제조되는 경우가 많네 라는 생각과 함께 중국어를 하는 친구들을 채용한다. 그런데 중국이 전부가 아니다. 태국 해킹툴을 찾기 위해서 태국어를 하는 사람을, 히브리어 해킹툴을 찾기 위해서 히브리어를 하는 사람을 고용해야 한다는 사실을 깨닫게 된다. 물론 이 모든 것이 안 하는 것보다는 좋겠지만 사실상 이런 방식을 통해서 실질적인 효과를 보기란 쉽지 않다. 더욱이 현재 게임 보안 업체가 벌어들이는 수익으로 이런 짓을 했다가는 단언컨대 곧 망한다. 물론 우리 아빠가 빌게이츤데요 하는 친구들은 예외다.

그럼 어떻게 해야 할까? 백엔드 시스템을 강화해야 한다. “Writing Solid Code”란 책을 보면 저자는 그렇게 이야기한다. 버그를 찾아 나서서는 곤란하다고, 버그가 있는 즉시 우리에게 다가와서는 깜찍하게 저 여기 버그 있어요. 좀 봐주세요. 이렇게 인사를 하도록 만들어야 한다는 것이다. 시간 스프레드를 제어하기 위해서 게임 보안 업체에서 해야 하는 일도 이와 동일하다. 누군가 해킹툴을 제작하면 제가 지금 해킹툴을 제작하고 있거든요. 관심 좀 가져주세요. 이렇게 자동으로 보고가 되는 시스템을 만들어야 한다. 누군가 취약점을 공격하고 있으면 제가 지금 이 취약점을 발견해서 꿀을 빨고 있어요. 이렇게 자동으로 보고가 되고 솔루션 개발자가 적절한 조치를 취할 수 있도록 만들어져야 한다.

물론 이상계에서는 이런 형태의 보고가 아닌 시스템이 자동으로 학습해서 사이트에 대한 제어 수준을 적당히 조절하는 형태로 동작하긴 할 것이다. 하지만 현실 세계에서 그 정도 수준까지 바라기는 힘들다. 그저 자동으로 문제가 있다는 사실이나 해킹툴이 어떤 방식을 통해서 제작되고 있는지만 보고 되어도 시간 스프레드를 줄일 수 있는 유용한 시스템이 된다.

#2

우리는 매 순간 모든 사이트의 보안 수준을 체크한다. 모두 AWESOME이길 바라면서…

게임 보안 업체에서 겪는 두번째 스프레드는 보안 수준 스프레드다. 이는 비단 게임 보안에서만 문제되는 이야기는 아니다. 모든 보안 관련 요소의 가장 중요한 부분 중에 하나다. 윈도우가 왜 보안 업데이트의 디폴트 옵션을 강제 설치로 해 두었는지를 보면 알 수 있다. 허구헌날 보안 패치를 해도 사용자가 설치해서 적용하지 않으니 윈도우는 취약한 운영체제라는 오명을 쓰게 된 것이다. 게임 보안 솔루션도 이와 마찬가지다. 제 아무리 좋은 대응 좋은 기능을 만들어도 고객에게 적절한 속도로 공급되지 않으면 무용지물이다.

이런 이야기를 하면 으레 듣는 소리가 그게 뭐가 힘든가요, 기능 만들기가 어려워서 그렇지 고객에게 공급하는거야 그냥 뿌리면 되는 거 아닌가요, 라는 이야기들이다. 한번도 B2B로 뭔가를 해본 적이 없는 사람들이 하는 소리다. 이게 생각보다 쉽지 않다. 특히나 사이트가 한두군데일때야 쉽겠지만 100개, 200개, 1000개, 2000개가 되면 전혀 다른 문제가 된다. 우선은 그 많은 사이트에 동일하게 기능을 제공하는 것도 어려울 뿐더러 보안 패치를 업데이트 하지 않는 사용자처럼 적용하지 않는 업체들도 많기 때문이다. 이는 정말 어떤 기술적인 문제가 아니라 전적으로 해당 업체를 지원하는 지원 담당자의 역량에 따른다.

그럼 지원 담당자들을 쪼으면 되지 않냐는 이야기도 할 법한데 이게 전혀 다른 문제다. 패치를 전달하는 것과 고객이 그 패치를 적용하게 만드는 것에는 하늘과 땅 만큼의 차이가 있기 때문이다. 패치를 전달하는 거야 누구나 할 수 있지만, 고객이 적용하게 만드는 것은 누구나 할 수 있는 문제가 이니다. 볼펜 하나를 던져주고 그것을 팔아보라는 문제와 동일하다. 팔 수 있는 사람과 그렇지 않은 사람이 있는 것이다. 여튼 이 문제에 있어서는 전적으로 훌륭한 지원 담당자를 채용하는 것 외에는 답이 없다.

그렇다고 결국 지원 담당자의 역량이니 손놓고 있으면 된다는 생각은 곤란하다. 모든 세부 사항이 다 그렇겠지만 추적 관찰 가능한 상태에 있는 것과 그렇지 않은 것에는 천지 차이가 있기 때문이다. 그렇다고 이걸 일일이 사람한테 시켜서 수동으로 만드는 것도 문제가 있다. 백방 오류가 발생하고 수집 시간이 더디기 때문이다. 모든 사항이 자동으로 추적 관찰 되도록 만들어야 한다. 그래야 모두가 현재 우리 서비스 품질 수준에 대해서 정확하게 인지할 수 있고 어떤 곳을 어떻게 더 강화해야 하는지를 판단할 수 있다.

#3

160개가 넘는 옵션들. 이 값들에 따라 깡통이 되기도 하고, 이지스함이 되기도 한다.

마지막 스프레드는 옵션 스프레드다. 우리는 프로그래머가 많지 않고, 코드를 매번 새롭게 컴파일하는 것에는 위험 부담이 따른다는 것을 일찍이 알고 있었기에 대부분의 기능들에 대해서 옵션 처리가 되도록 만들었다. 요즘은 그 정도가 더 심해져서 기능이 있는 곳에 옵션이 있어야 한다는 주의로 만들고 있다. 어쨌든 풍부한 옵션은 프로그래머가 직접 개입하지 않아도 특정 문제들을 빠르게 해결할 수 있는 가능성을 제공한다는 장점이 있다.

하지만 항상 포스의 어두운 면과 밝은 면이 공종하는 것처럼 이 또한 장점만 있는 것은 아니다. 옵션을 제어하는 사람이 충분히 숙련된 엔지니어라면 문제가 없겠지만 옵션 사항의 정확한 동작 구조에 대해서 잘 모르는 담당자라면 문제가 심각해진다. 왜냐하면 그 친구가 패치 생성 시에 옵션을 어떻게 지정했는지에 따라 제품이 깡통이 되기도 하고 이지스함이 될 수도 있기 때문이다. 더욱이 자동화된 추적 장치가 없다면 담당자 입장에서는 자신이 옵션을 변경했었다는 사실을 까먹는 경우도 많다.

옵션 사항에 대해서도 스프레드가 자동으로 관리될 수 있도록 담당자가 패치 빌드를 생성하면 매번 어떤 옵션 설정이 잘못되어 있음을 자동으로 노티해 주는 장치가 필요하다. 더불어 모든 사이트의 옵션 사항들에 대해서 일괄되게 추적할 수 있는 시스템을 가지는 것이 중요하다.

#4

맥도날드가 전 세계에서 가장 유명한 햄버거 가게가 된 비결은 딱 두 가지라고 한다. 하나는 서울의 빅맥과 뉴욕의 빅맥의 맛이 납득할 수 있는 범위 내에서 동일하다는 것, 다른 하나는 어떤 바보가 오더라도 맥도날드의 프로시저대로만 하면 유사한 품질의 빅맥을 만들어 낼 수 있다는 점이다. 분야는 다르지만 맥도날드는 스프레드를 잘 제어해서 균등한 품질의 제품을 생산했기 때문에 성공했다고 할 수 있다. 게임 보안도 다르지 않다.

해킹툴을 어떻게 숨기나요?

해킹툴을 실행하고 XIGNCODE3가 못보게 종이로 가리세요 ㅋㅋ

온라인과 모바일 환경에서 모두 효과성이 검증된 게임 보안 솔루션은 XIGNCODE3가 유일합니다.