늙긴 늙었나보다.

2013년 5월 18일 at 9:54 am

나는 원래 감기에 자주 걸린다. 1년에 한두번씩은 걸리고 넘어가는데, 증상은 항상 똑같이 매우 심한 기침이다. 그러면서도 20대까지 몸에서 열이 나는 느낌이 무엇인지는 몰랐다. 내 나이 31 살의 연초 겨울날 밤에 자다가 너무 추워서 깨어나 옷을 둘둘 껴입고 잠을 잤던 적이 있었는데 처음엔 이유도 몰랐다가 출근하면서 계속 오한이 들어 이마를 만져보니 몹시 뜨거웠다. “이게 바로 몸살 감기구나!”

며칠 전부터 목이 깔깔해오더니 다시 감기가 찾아왔다. 지난번처럼 아니지만 미열을 동반하면서. 몸에 기운이 없고 약간의 통증이 느껴지는 감기.

뭐 심한 감기도 아니고 금방 낫겠지만, 노쇠기에 접어들었다는 느낌이 들어 좀 서럽긴 하다.

IBK 오픈뱅킹 사용소감

2013년 5월 14일 at 9:14 pm

Safari, Chrome, Firefox 모두 최신버전은 지원 안 해서 Firefox 20.0 을 놔두고 Firefox 14.0 을 추가로 다운로드해서 돌려야 했다. nProtect니 뭐니 하는 프로그램도 똑같이 설치하니 기분 나쁘다. 그러나 맥에서 안전하게 인터넷 뱅킹하니 참 좋다. 그러다가 우리 회사 홈페이지 들어가서 공인인증로그인 하려했더니 ActiveX 설치하라며 안 된다. 아 후졌다..

금융 앱스토어 오픈 기념 이벤트 당첨?

2013년 5월 13일 at 12:02 pm

갑자기 금융앱스토어 오픈기념 이벤트 당첨이라며 카페베네 쿠폰이 왔다. 010-9274-XXXX 에서 발송됐는데, 스미싱인 줄 알고 삭제하려했다. 그러다가 인터넷에서 찾아보니 이런 이벤트가 있긴 하나보네? 하지만 아직 믿을 수 없다. 문자 보는 것도 두려운 세상

https://www.fineapps.co.kr/event/openEventView.do?currPage=1&eventId=0000000010&eventFlag=OPEN

포스코 임원의 대한항공 승무원 폭행 사건에서 느낀 대한항공의 보안의식

2013년 4월 28일 at 11:49 pm

지난 한 주간 가장 이슈가 되었던 사건은 북한의 개성공단 폐쇄니 뭐니보다는 아무래도 포스코 계열사 왕상무의 대한항공 승무원 폭행 사건인 것 같다. 대한항공과 승객, 경찰 사이에 풀어갔어야 했을 이 사건은 대한항공에서 승무원 일지를 외부에 유출하면서 전국민의 공분을 받아 포스코는 상당한 이미지 타격을 입고 폭행한  승객은 회사를 그만두어야 했다.

포스코 왕상무는 물론 잘못을 저질렀다. 그런 사람을 임원으로 임명한 포스코도 물론 잘못했다. 거기에 포스코 왕상무가 어느 직장에나 흔하고 흔한, 권위주의에 쩐, 아랫사람을 막 대하는, 누구나 겪어봤음직한 그런 흔한 진상이라는 점 때문에 그런 진상을 겪어본 사람들 누구나 주변에 있는 다른 누군가를 떠올리며 분노했을 것이다. 하지만, 대한항공의 일지 유출은 정당했을까..?

대한항공만 겪는 문제는 아닐 것이다. 우리 회사에도 굳이 전산실까지 전화해서 욕설을 퍼붓는 고객들도 많이 있다. 그리고 이에 대한 기록도 어떤 형태로든 남기고 있기는 하다. 남겨진 기록은 훗날 우리 회사의 과실이 없음을 증명하기 위한 목적이 클 것이다. 그러나 이렇게 남긴 기록을 외부에 유출하지는 않는다. 이런 문서뿐만 아니라 회사에서 만들어진 어떠한 문서도 기본적으로 외부에 공개하지 않는다.  공개해도 되는가 공개하지 않아야 하는가 판단할 필요 없이 그냥 공개하지 않는다.

내가 서비스를 받으면서 행하는 행동들이 외부에 공개된다면? 내가 길거리에서 연인(아내)과 함께 하는 행동들(포옹이 됐건 키스가 됐건)이 CCTV 에 찍혀 인터넷에서 볼 수 있다면? 내가 은행에 가서 대출을 받고자 상담한 내역들이 인터넷을 통해 공개가 된다면? 아, 이건 공개가 되고 있는 것 같다. 예전에 마이너스 통장 만들려고 은행 몇 군데 방문해서 상담 좀 했더니 그날부터 당장 엄청난 전화/문자들이 오기 시작했으니까. 어쨌거나 우리가 잘했건 잘못했건간에 우리의 행동은 불필요하게 공개될 필요가 없다. 법에 따라 재판을 받으면 되지 인민재판을 받을 필요는 없다.

대한항공이 그렇다고 해서 모든 것을 공개하는 투명한 회사일까? 과거 나는 뉴욕에서 대한항공 비행기에 탑승하여 한국으로 돌아올 때 황당한 경험을 했던 적이 있다. 정상적으로 비행기표를 발급받아 비행기에 탑승하다가, 내 티켓을 본 어느 승무원이 내 앞에서 다른 여승무원에게 무언가 험하게 말하고, 나를 그냥 탑승시키면 안 된다고 하고, 그 여승무원은 나에게 저쪽 검색대로 가라고 하고, 검색대에 가서 상황을 얘기했더니 다시 공항 밖으로 나가라고 하고, 공항 밖으로 나갔더니 대항항공 부스는 철수하고 없고. 어쩌란 소린가? 나중에 알고 보니 내 티켓이 좀 더 강화된 보안이 필요한 티켓인 것 같고, 그래서 뭔가 다른 절차가 필요했던 것 같긴 한데, 어떤 설명도 없이 나를 내보내니 내가 어떻게 알겠는가. 아무튼, 그 건은 나와 대한항공 사이에 풀었다. 한국에 돌아와서 대한항공 사이트에 민원을 넣었고, 거기에 대해 대한항공은 이런 케이스를 문서화하여 사내에 배포했다는 응답을 주었다. 항공사 입장에서는 당연히 외부에 공개될 사안이 아니고, 외부에 공개되면 항공사측의 이미지만 갉아먹을 것이다.

아마도 해당 비행기의 승무원 중 한 명, 혹은 관계자 중 한 명이 화가 나서 인터넷을 통해 유포했을 것이다. 경찰이 유포하기에는 매우 빨랐으니까. 그런 일은 항공사와 승객, 경찰 사이에 풀면 안 되나? 꼭 그런 일들 하나 하나를 인터넷이라는 공개적인 장으로 끌고 나와서 인민재판을 해야 하나? 인터넷이라는 게 그런 분노 폭발의 바다는 아니지 않은가.

안드로이드 모바일 백신 애플리케이션, 앱에 내장 or 외부 다운로드?

2013년 4월 24일 at 3:32 pm

안드로이드는 구글 플레이에서 다운받는 방법 외의 방법으로 애플리케이션을 설치할 수 있으며 아이폰에 비해 폰의 기능을 관대하게 애플리케이션에 허용하는 편이기 때문에 많은 멀웨어와 유통경로가 존재한다. 그리고 멀웨어 중 일부는 폰의 exploit을 이용하여 자신의 권한을 상승시키고(루트 권한 획득) 이를 이용해 타애플리케이션의 활동을 감시한다.

이로 인해 조심해야 할 부분 중 하나가, 금융거래 애플리케이션이 공인인증 로그인을 하는 과정이 감시당하지 않도록 하는 것이다. 공인인증 로그인 절차를 멀웨어가 감시할 경우 공인인증서와 함께 패스워드를 유출시킬 수 있다(꼭 감시해야만 패스워드를 알아낼 수 있다고 말하진 않겠다). 이 때문에 공인인증 로그인이 들어갈 경우 앱의 위변조 체크 외에도 해당 앱에서 멀웨어가 동작중인지, 폰이 루팅되지 않았는지 등의 확인 작업이 필요하다(강제사항이라고 말하진 않겠다).

이때 앱에 모바일 애플리케이션을 내장하기 위한 방법으로 앱 자체에 백신 엔진을 포함하는 방법과 앱 최초 실행시 구글 플레이 스토어에서 다운 받는 방법이 있다. 이 두 가지 방법을 비교해보자.

 

백신 엔진 내장 방식
장점 단점
  • 백신을 별도로 다운 받을 필요가 없다.
  • 백신의 엔진이 업데이트될 경우 그 엔진을 내장한 애플리케이션도 함께 업데이트하여 스토어에 업로드해야한다.
  • 앱 로딩시 백신이 함께 구동될 필요가 없어 시작 시간이 단축된다.
  • 백신 엔진 업데이트시마다 애플리케이션을 다시 (자체) 검수해야 한다.
 
  • 백신의 엔진 업데이트 후 애플리케이션 업데이트까지는 시간이 걸린다. 이 시간차를 이용한 공격(zero-day attack)에 속수무책이 된다.

 

마켓 다운로드 방식
장점 단점
  • 애플리케이션이 백신과 API 를 통해서만 연계되므로 백신 업데이트로 인한 유지보수가 불필요하다.
  • 애플리케이션 최초 구동시 구글 플레이스토어로 이동, 백신 다운로드 및 설치 과정이 필요하다.
 
  • 고객이 백신을 삭제했을 경우 다음번 구동시 구글 플레이스토어로 이동, 백신 다운로드 및 설치 과정이 필요하다.

이외에도 국민은행 앱처럼 백신을 구글 플레이가 아닌 자체 사이트에서 다운로드받도록 하는 방법이 있는데, 이는 구글 플레이의 가이드라인에 위배되니 참고하자. 이유는 아마 보안상의 이유가 주일 것이며, 그 외에도 부분유료 앱의 결제경로 등 몇몇 문제가 얽혀있을 것이다.

페이스북과 블로그 from 직장동료s

2013년 4월 11일 at 8:47 pm

나는 두 개의 페이스북 계정과 하나의 블로그를 가지고 있다.

하나의 페이스북 계정은 몇몇 회사 사람들과 몇몇 지인들이 있는 본명 계정,  또 하나의 페이스북 계정은 회사 사람들 없이 많은 지인들이 – 주로 대학 친구들을 중심으로 – 있는 익명 계정이다.

이 블로그는 1999년부터 운영해온, 제로보드 게시판과 함께 해왔지만, 중간에 잊혀지기도 했던, 오늘날에 오기까지 우여곡절이 많았던 익명의 블로그.

회사 사람들이 있는 페북은 물론 회사 사람들이 보아도 될 만한 글만 게시한다. 회사 사람들이 보면 도움 될 정보도 올린다. 내 블로그에 올린 정보성 글을 요약해서 올리기도 한다.

회사 사람들이 없는 페북은 격의없이 떠드는 페북이다. 회사 사람들이 봐선 안 될 이야기도 많이 한다.

이 블로그는 회사 사람들이 보지 않는, 그러나 보아도 큰 상관은 없는 블로그다. 개인 신상에 대한 이야기를 올리기도 하고, 긴 정보성 글을 올리기도 한다. 삽질기도 많이 올린다.

나는 이렇게 쏘셜을 운영하고 있다.

블로그 클라우드로 옮기기 프로젝트

2013년 4월 5일 at 11:29 pm

The cloud is the answer to joomoney.net ?

현재 주머니닷넷은 운영자의 옷방에 설치된 HP Microserver 36L 에서 구동되고 있다. 이 서버는 AMD 의 Dual Core CPU 와 약 4.5TB의 하드디스크, 8GB의 램으로 운영되고 있는데, 다른 건 충분하나 CPU Power 가 몹시 부족한 것이 흠이다. 게다가 윈도우 2008 R2 를 설치하고 IIS 위에서 wordpress 를 돌리니 속도가 몹시 답답하다. 튜닝을 위해 갖가지 리서치를 다 해보았으나, 차라리 APM 에서 돌리는 게 낫겠다! 라는 것.

그렇다고 TV 에 USB로 물려서 Server Ultimate 앱으로 서버 역할을 하고 있는 안드로이드 기기에서 돌리기는 그렇고.. 처음에는 Xen 이나 VMWARE 의 가상화 솔루션(XenServer 나 VMWARE esxi)등을 고려했다. 하지만 Xen 의 경우 듀얼코어 중 하나를 Xen 을 위해 할당, vmware 도 만만치 않은 부하를 감당하기 힘들어보여 외부에서 제공하는 클라우드 서버를 찾아보았다.

제일 먼저 Google App Engine, 이미 몇차례 사용해 본 적이 있으나, 역시 가장 큰 문제는! Python 과 자바만을 지원하며, DB는 SQL DB 가 아닌 Datastore 를 사용해야 한다는 것이다. JAVA 또는 python 을 사용하는 GAE 용 블로그를 설치하여 돌리는 방법의 고려에 있어서는, 먼저 GAE용 블로그 엔진이 wordpress 만큼 훌륭한 점이 없다는 점, 그리고 기존의 DB 를 모두 새로운 블로그 엔진을 위해 마이그레이션하는 부담이 너무 크다는 점, 그리고 나중에 다시 wordpress 로 옮겨가기 힘들 것이라는 점 때문에 기각했다.

사실, 구글도 유료이기는 하나 MySQL 기반의 DB Service 를 제공한다. Google Cloud SQL 이 그것인데, 무료 서비스가 없다는 것이 단점 작년 말부터는 적은 램과 0.5GB의 스토리지, 조금의 IO 에 대해서는 무료로 Introductory Trial 을 제공한다. PHP 는 Quercus 라는 자바 기반의 PHP 엔진을 돌리는 방법을 생각해볼 수 있을 것이다. 쉽진 않은 길이겠지.

PHP 를 개발한 Zend 사에서 제공하는 RightScale 을 고려해본 것은 구글의 MySQL 서비스가 여전히 유료일 것으로 오해하였기 때문이다. MySQL 과 PHP 를 함께 제공하면서도 믿을만하고 내가 원하는 약간의 서비스를 무료로 쓸 수 있는 곳은 RightScale 정도이리라..고 생각했는데.. 어랏, 그런데 60일만 무료.

또다른 서비스를 찾아보다가 Red Hat 의 OpenShift 를 찾게 되었다. 3 gear 까지 무료. 자세한 정책은 좀 더 탐구해봐야겠다. 가장 고무적인 것은, 약간의 구글링을 해보았더니 wordpress 를 OpenShift 로 옮기는 방법이 많이 나와있으며, 이를 “migrate” 라고 표현하고 있다는 것이다. GAE 와 달리 아주 간단한 작업이 될 것이라는 얘기.

찾다보니 Heroku 에도 MySQL add-on 이 있는 등, 그간 세상이 매우 많은 종류의 PaaS 출시되었음을 알 수 있었다. 리서치할 부분이 너무 많아졌달까.

아무튼, 이 느리고 불안한 블로그, 어서 안정적이고 빠르게 돌아가는 곳으로 옮겨가자!

0 == false

2013년 4월 4일 at 8:24 pm

요새는 삼성SDS멀티캠퍼스에 가서 자바스크립트 교육을 받고 있다. 강사는 나름 깊이 있는 지식을 습득하고 있는 것으로 보였다.

교육내용 중 자바스크립트 객체나 값의 존재 여부를 확인하는 방법에 대하여 교재(일본인이 쓴 책의 번역서)에는 이렇게 나와있었다.

function test(arg1) {
  if (arg1 == undefined) {
    arg1 = {};
  }
}

하지만, 강사의 설명은, 이와 같이 넘어올 경우 null 을 포함한 모든 경우를 체크해주지 못한다며, 다음과 같이 써야 한다는 것이었다.

function test(arg1) {
  if (!arg1) {
    arg1 = {};
  }
}

하지만 이와 같이 코딩할 경우 arg1 이 0 으로 넘어올 경우에도 없는 것으로 if  에 걸려 초기값으로 셋팅해버린다는 문제점이 있다. 처음에는 강사가 객체 또는 객체의 인스턴스를 받을 경우에만 저렇게 설명하는 것이겠지 하였으나 숫자로 넘어온 값도 마찬가지로 if (!arg1) 의 방법으로 존재 여부를 확인하고 있었다.

“저렇게 체크하면.. 0 이 넘어와도 객체를 못 받은 것으로 판단해버리지 않습니까?”

“아닙니다. 값이 존재여부로 판단해서 값을 넘겨받지 못했을 경우에만 블럭을 수행합니다.”

“0 이 넘어오면 0 도 false 로 판단하여 블럭을 수행할텐데요.”

“그럼 어디 해볼까요..”

결과는.. 0 이 넘어와도 블럭은 수행됐고, 강사는 책의 설명이 맞다며, 잘못 알고 있었다고 얘기했다. 저런 걸 모를 실력의 강사가 아닌데…

그 의문은 다음날 풀어졌다. 현대자동차 연구소에 다니고 있는 신동진과 수요일 저녁 사당역에서 만나 한 잔 하면서였다. 내가 받는 교육에 대해서 얘기하면서 강사의 실수에 대해서도 얘기했다. 그러자 동진이가 하는 말,

“자바에서는 0 이 false 가 아니니까 그렇지..”

“응? 자바도 0 이 false 아님? 아, 아, 맞다. 자바는 boolean 타입이 따로 있었지..!”

“그치, 0 이 false 가 되는 것은 C 언어나 그렇지..”

그렇다. C가 mother tongue 이었던 나는 당연하게도 0 ==  false 라고 알고 있었지만, 자바나 C# 으로 경력을 시작한 프로그래머라면 당연히 if 문 안에 들어가는 것은 논리판단이며, 0 == false 따위의 #define 에 대해서는 알 필요가 없었던 것이다.

이건 그 강사의 잘못도 아니고, 신-구 패러다임의 사이에서 양쪽의 특징을 조금씩 갖고 있는 과도기성의 문제랄까?

사실, 자바스크립트가 저런 문법을 허용하지 않았더라면 모호성이 사라져 더욱 좋았을 것이다.

금융IT의 급격한 변화와 도태

2013년 4월 2일 at 8:02 pm

가끔 은행에서 아직 코볼을 사용한다는 소리를 들으면 이야 저기는 시스템이 정말 구식이구나 한다. 은행에서 차세대를 하는데 기존 직원들이 코볼밖에 몰라 소통이 안 된다는 소리를 들으면 이야 지금 시대가 어느 시댄데 코볼밖에 모르는 사람들이 컴퓨터를 하고 있나.. 생각하기도 한다. 많은 은행들이 코볼을 자바로 옮겨가고 있으며, 오래된 언어와 새로운 언어의 차이보다는 오래된 기술자와 새로운 기술자의 차이 때문에 어려움을 겪는다. 자바가 혜성처럼 등장한 것은 96년, 20세기 초까지만 해도 인터넷에서 아주 간단한 게임 정도나 하기 위한 언어였던 자바가 10여년 지난 지금에 와서는 차세대를 진행한 대부분 은행들의 주력 프로그래밍 언어가 되었다. 그 와중에 밀려나버린 언어는 코볼.

프로그래밍 언어 외에도 은행권의 중요한 기반 시스템인 DBMS(데이터베이스관리시스템)에서 사용하는 SQL 이라는 언어도 언젠가 코볼과 같은 운명이 되지 않을까? 서버실을 가득 채우고 있는 서버들은 현재 개별 관리되고 있지만, 이들은 퍼블릭 혹은 프라이빗 클라우드 형태로 변해갈 것이며 DB 역시 클라우드에 맞는 NoSQL 형태의 DB로 바뀌어갈 것이다. SQL 이 아무리 쉬운 언어라지만 언어의 비구조성과 비정형 데이터 처리의 난해함, 지속적인 관계 설정에서 오는 빠른 대응 불가, 퍼포먼스 이슈에 있어서 확장의 어려움과 비용 등을 극복하기가 쉽지 않다. NoSQL 과 javascript 기반의 DBMS 가 대중화되고 SQL 기반의 DBMS 가 물러날 때가 되면, 새로운 기술자들이 SQL 기술자들을 이해하지 못하겠지. 구글, 페이스북과 떠오른, 앞으로 더욱 발전해갈 NoSQL, 둘의 장단점을 합쳤다고 스스로는 말하는 NewSQL. 이 셋 다 살아남거나, 다 죽거나, 일부만 살아남거나. 어쨌거나 한국 금융회사에서 새로운 시스템으로 옮겨갈 기미는 보이지 않는다. 아마 인원들의 세대교체가 선행되어야 그것이 가능할 것이다. 그때가 되면 말하겠지. “야, 여기는 아직 SQL을 쓰네. 이거 다 갈아엎어야 되는데 아휴.”

변화는 지속적으로 느리게 일어나지만, 어느 순간에는 모든 것을 바꿔버린다. 그 변화에 적응하지 못하는 순간, “요새는 이런 거 쓴다며? 허허 세상 참 많이 변했네~” 하며 변화로부터 스스로를 격리시키겠지. 사람을 늙게 하는 것은 시간이 아니라 사람 자신일 것이다.

엄청나게 바빴던 일주일

2013년 3월 31일 at 11:08 pm
일에 치이다

항복 ㅠㅠ

지난 한 주는 내가 견뎌낸 것이 신기한 일주일이었다. 2007년 이래 계속 유동화 업무만 하면서 업무 범위도 점점 넓어지고 힘든 일만 맡아 왔다. u가 생겨 세간의 관심이 덜해져 잠시 편했던 2011년을 제외하고는 업무에 만족한 적이 없었던 듯 하다. 2012년부터는 u보금자리론 업무를 맡게 되면서 엄청나게 바빠졌고, 왜인지 모르겠지만 우리팀에서 계속 스마트폰 어플 개발을 진행하면서 엎친 데 덮친 격이 되어왔다. 사후관리 업무는 점점 폭증하고, 시스템은 제대로 개발되어있지 않고, 지사의 문의나 요청은 폭주하고..

회사에서 밤 10 시 이전에 퇴근하는 일이 별로 없지만, 지난주에는 11시 이전에 귀가할 수가 없었다. 11시까지도 너무 많은 업무에 어깨가 망가지는 느낌으로 일해왔다. 스마트폰 어플 개발은 시작되었고, u 업무가 계속해서 폭주하는 마당에 은행연합회 신용정보 점검 마감 시기가 도래하고..

어떤 업무든 다른 일을 할 수 있다면.. 부장님이 신입사원 모집에 대해 얘기하시면서 “CISSP 가진 사람을 뽑을 게 아니라 그냥 기존 직원이 배워서 하면 안 되나?” 하셨다. 잠시 생각해보니 4학년때 컴퓨터 보안 과목에서 사용했던 교재가 “CISSP Certification”. 일단 그 책을 비롯하여 각종 보안/해킹 책은 회사에서 갖다두고, 앞으로 CISSP 공부를 해볼까 고민해본다.