2015.02.20 13:00

this 라는 개념을 이해하기 위해서는 먼저 컨텍스트(context, 맥락 혹은 상황)라는 개념을 먼저 언급해야 할 듯 합니다. 컨텍스트(context)라는 용어는 컴퓨터 소프트웨어에서 많은 분야에서 활용되는 개념인데, 프로그램을 컴파일(인터프리트)하거나, 실행할 때 현재 어느 지점의 코드가 실행되는가.. 실행(혹은 컴파일)하는 당시의 각종 변수의 존재 유무라거나, 자원의 상태 등 코드의 주변 환경 전체를 일컫는 표현입니다.


컨텍스트가 중요한 것은 this 같은 추상적인 키워드 때문입니다. context와 this 개념을 따로 나누어 설명하는 것이 오히려 이해에 도움이 되지 않기 때문에 함께 묶어서 설명 드리겠습니다.


<script>
// 이벤트를 연결합니다.
$(document).ready(function () {
    // 이벤트를 연결합니다.
    $('h1').hover(function () {
        // 색상을 변경합니다.
        $(this).css({
        background: 'red',
        color: 'white'
    });
}, function () {
    // 색상을 제거합니다.
    $(this).css({
        background: '',
        color: ''
       });
    });
});
</script>


위에 예시된 코드에서 this는 2번 나타납니다.

그런데, 코드를 해석(이해)하기에 앞서 전제를 두어야 할 것은 this 를 해석하는 주체가 프로그래머가 아니라는 것입니다. javascript는 인터프리트(interpret) 방식의 언어이기 때문에 스크립트 엔진(혹은 브라우저)가 this를 해석합니다. 그리고, 브라우저는 this 라는 키워드를 만나는 시점에 context를 참조해 this를 찾습니다. (혹은 선택합니다.)


이야기를 좀 더 풀어 보겠습니다. $(document).ready(function () { ... }); 코드는 HTML 페이지가 로딩되고 화면에 출력되는 시점 (사용자에게 보여질 준비가 된 상황)에서 fuction() {...} 블럭의 코드를 실행하겠다는 것입니다.


그 중에서 $('h1').hover(function() { ... }) 블록은 h1 태그에 마우스를 가져가면 색상을 변경하는 이벤트를 등록한다는 의미입니다. 그리고, 브라우저가 $(this) 블록을 만나게 되면, this 를 해석하는 시점 혹은 컨텍스트에서 현재 선택(혹은 사용중인) HTML 객체(정확히는 DOM 객체)를 찾고, 그것을 this 에 연결합니다. 위 코드에서 this는 HTML 문서 내에 존재하는 모든 h1 태그 입니다.


즉, this 라는 키워드가 위치한 코드를 감싸고 있는 어떤 객체(코드를 실행하거나 컴파일 하는 시점에 스크립트 엔진이나 컴파일러가 찾아낸..)가 this가 되므로 일정한 객체를 일컫는 것이 아니기에 추상적인 객체라고 표현합니다.


그리고, 한국어로 번역하는 과정에서 this 를 자기 자신이라고 해석하니 문제가 되는 것이고... 정확한 의미는 컴파일러/스크립트 엔진이 코드를 해석하는 시점에 동작 중인 - 혹은 감싸고 있는 - 객체를 의미합니다.


굳이 풀어보자면 this = object in this context 입니다.


Posted by 善 곽중선
2015.02.20 12:58

요즘 '컴퓨터/네트워크 보안 분야'가 참 핫(hot)한 아이템인 듯 하다. 어줍잖은 경험과 어깨 너머 배운 지식 몇가지로 보안 관련 질문에 답하다 보면... 내가 보안 전문가인줄 알고 이리저리 물어보며, 한 수 배우겠다고 친구 신청하는 야심찬 젊은이들이 있다. 허나, 나는 전혀 보안 전문가가 아니다. 여러가지 일을 해오면서 자연스럽게 보안 쪽 기술과 각종 정보를 습득했을 뿐이다.


다들 보안 쪽이 배우기는 어렵지만, 유망한 직종이라고 생각하는 듯 하다. 맞는 말이다. 큰 꿈을 목표 삼고 나아가는 것이 당연한 듯 하지만 아무나 그 목표에 이르는 것은 아니다. 성공에 대한 낭만과 목표는 있지만, 과연 실패에 대한 각오도 함께 지니고 있는 것일까? 의문이 들어 몇 자 남긴다.


며칠 전, 신년을 맞이해 고문으로 있는 모교 컴퓨터 동아리의 후배들과 술자리를 가졌다. 다들 페이스북에 내가 올리는 다양한 글들과 댓글을 보면서 만능 개발자 같다며 감탄을 한다. 처음부터 수퍼맨이 되고자 했던 것이 아니다. 내 능력의 태반은 실패의 과정에서 얻은 부산물이다. 실패하고도 또 일어섰기 때문에 가능했던 것이다.


참 다양한 기술을 경험했다. 그 동안 해왔던 일들을 간략히 정리하면 다음과 같다.


- 객체지향 데이터베이스 연구 및 기술지원
- CGI 기반의 웹 서비스 개발
- 델파이 기반의 클라이언트 서버 시스템 개발
- ActiveX, Livewire (server-side javascript), DB 를 연계한 전자결재 솔루션
- 자바 기반의 EDMS 솔루션 개발
- 웹 에이전시에서 프런트엔드 및 서버 개발 총괄
- N-screen 을 위한 QT 기반의 멀티 플랫폼 위젯 서비스
- TV 플랫폼 상에 플래시 엔진 이식(porting)
- 아이폰 및 안드로이드 앱 개발 총괄
- 스프링 기반의 기업용 프레임워크 설계 및 개발
- 그리고 아마존 웹 서비스(AWS) 아키텍쳐 설계


이러한 경험들은 어찌보면 화려해 보이지만, 우리나라 사람들의 보편적인 시선으로는 다 실패한 경험이다. 대박 친 비즈니스가 없었으니까... 게다가 이런 경험을 다 해보고도 보안은 꿈도 못 꾼다. 보안이야 말로 IT 기술의 끝판왕이며 종합예술이기 때문이다.


목표와 꿈은 큰 것 일수록 좋다. 허나, 중도에 실패했을 때 어떻게 다시 일어설 것인가 라는 생각을 해보아야 한다.


이 시대의 가장 멋진 CEO, 아이언맨의 실존 모델인 엘런 머스크 - 정확한 발음은 일런 머스크에 가깝다고 한다 - 조차 단 일주일 정도의 운영자금만 남아서 하마터면 파산할 뻔 했다고 한다. 너무 일에 미쳐서... 첫번째 부인과도 이혼하고, 좌절에 사로잡혔을 때 위로해준 사람이 지금의 두번째 부인이라고 한다. 구글이 처음부터 성공했을까? 투자자를 얻기 위해 동분서주한 이야기는 찾아 보았기를 바란다. 스티브 잡스의 와신상담 이야기는 유명하지 않은가... 이런 이야기 보다 중요한 것은 실리콘밸리에서 창업에 성공하고 계속 사업을 이어가는 사람들보다 실패한 사람들이 몇 배 많다는 사실이다.


Plan B를 염두에 두고 살자. 노력한다고 다 되는 것은 아니다. 노력해도 다 얻지 못하더라도 그 과정에서 의미를 찾고, 실패하고도 또 나아갈 각오를 다졌으면 한다. 인생의 대부분을 파랑새를 찾다가 허비하는 것 또한 불행한 일이다. 그 과정에서도 즐겁고 행복할 수 있었으면 한다. 무엇보다... 목표를 얻기 위해 자신의 현재를 희생하려 들지 마라. 성공을 위해 고통을 감내한다는 말은 영화나 드라마에서나 가능한 얘기다.


그저 남들에게 으시대기 위해서, 남들에게 자랑할 수 있고 멋져 보이는 목표가 아니라, 배우는 즐거움, 작은 결과에도 어제 보다 더 많이 알아가는 것에서 느끼는 희열을 알았으면 한다. 꼭대기는 결코 모두가 닿을 수 있는 자리가 아니다. 나는 아니라고 끝까지 믿어도, 당신의 희망이 당첨되지 않은 로또 처럼 휴지조각이 될 확률이 높다는 것도 알고 있지 않은가 말이다. 애써 남의 성공을 위한 불쏘시개가 되기보다, 과정을 즐기며 사는 것이 나을수도 있다.


쓸데없이 길어졌다. 타인의 꿈을 폄하하지 않는다. 큰 꿈을 가지는 것은 좋다, 다만 실패할 각오를 하라, 그리고 그 과정도 즐겨라. 그래야 멀리 오래 가고, 또 돌이켜 행복할 수 있을 것이다.


Posted by 善 곽중선
2015.02.20 12:30

옛날 사람들은 한자를 공부하면서 한글 표기도 없이 계속 읽고 또 읽었습니다. 그렇게 무식하게 외우기만 한다고 익혀질까 라는 의문을 가진 적도 있지만... 아예 틀린 것도 아니라는 생각을 하게 됩니다. 사실 인간이 활자를 발명한 게 수천년 이라는데 진화의 관점에서 인류가 태어난 것 그 시간의 수백배가 넘죠. 즉, 언어, 활자, 논리라는 게 쉽게 뇌에 받아들여지지 않을 거라는 얘기입니다.

즉, 논리적인 사고를 하기에 앞서 오랜 시간 문자에 익숙해지는 시간이 필요한 것이고, 그 다음에 차츰 논리을 연습하고, 또 어휘와 지식체계를 늘리는 수련이 필요하다고 생각합니다.

나아가서 프로그래밍을 처음 배우는 과정에서도 소프트웨어적으로 생각하는 자세(습관)를 익히는데도 상당한 노력과 시간이 필요한 것이죠. 왜 노력하는 만큼 늘지 않는지 물어보시는 분들이 계신데, 프로그래밍 또한 외우고, 용어에 익숙해지고 그 이후에 프로그래밍 논리적 사고에 적응하는 시간이 필요한 것입니다.

스택 이해하고 코딩하는데 대학까지 들어온 머리와 프로그래밍 언어 한두개 배워 본 경험 가지고도 며칠 걸렸다는 얘기를 듣고 몇 자 적어봤습니다.


Posted by 善 곽중선
2015.02.20 12:29

.소프트웨어(software)라는 단어는 하드웨어(hardware)의 반대말이다. 하드웨어의 뜻에 대해 위키피디아를 인용하자면, "역사적으로 하드웨어는 나무 제품을 더 강하게, 더 기능성 있게, 더 오래 지속되도록, 조립하기 쉽게 만드는 데 사용되는 금속 부분과 부속품을 뜻하였다." 달리 말해서 '단단한, 튼튼한, 잘 고장나지 않는 부품"을 의미한다. 물론 컴퓨터 기술에 한정한 하드웨어의 의미는 "물리적이거나 실질적으로 만질 수 있는 장비의 부품"을 말한다.


소프트웨어라는 단어의 정확한 정의는 "컴퓨터 시스템, 프로그램, 데이터에 의해 처리된 모든 정보"이다. 달리 말해서 명령어와 명령에 의해 처리되는 데이터의 집합(프로그램)이라고 말할 수 있을 것이다.


그런데, 이상하게도 컴퓨터 프로그래머들 조차... 소프트웨어에 대한 시각이 어느 정도 왜곡되어 있다는 것을 자주 느끼게 된다. 좀 더 구체적으로 말하자면, 소프트웨어가 하드웨어의 반대말이라는 사실에 대해서는 동의하지만, 하드웨어가 '변경 불가능한 기능'을 제공하는 것이며, 소프트웨어는 '기능이 변경'될 수 있는 것이라고 생각한다는 점이다. 굉장히 위험한 인식이 아닐 수 없다. 소프트웨어는 업그레이드, 기능 개선, 버그 수정 등의 방식으로 언제라도 간편하게 고쳐질 수 있는 것이라는 위험천만한 인식을 가지고 있다.


좋은 제품 - 그것이 앞서 나열하고 설명한 하드웨어와 소프트웨어에 대한 모든 정의를 망라해서 - 은 '신뢰'할 수 있어야 한다. 즉, 도구 혹은 제품을 사용하는 사람은 해당 제품의 기능을 직관적으로 이해할 수 있어야 하고 - 칼을 보면 어떤 용도로 써야 할지 바로 알 수 있다, 자동차를 보며 우리는 그 용도에 대해 고민하지 않는다. -, 한 번 정해진 기능은 제품이 폐기될 때까지 유지되어야 한다. 당연하지 않은가?


그런데 왜 소프트웨어의 기능 변경에 대해서는 '관대함'을 넘어 '당연한 것'이라고 생각하는 것일까? 과연 기능이 변경되는 것이... 소프트웨어를 위대하게 만드는 속성일까? 찬찬히 되짚어 보자. 우리가 소프트웨어에 대해 잘못 생각하고 있거나, 혹은 소프트웨어를 제작하는 실력에 문제가 있는 것이리라... 난 단언컨데.. 많은 사람들이 잘못 생각하고 있다고 생각한다.


좋은 소프트웨어를 만들기 위해서는 좋은 부품(컴포넌트, 함수)가 필요하다. 좋은 부품이란 무엇인가? 앞서 말한대로 고장하지 않고(버그가없고), 단단하며(외부의 조건에 의해 변경되지 않는), 튼튼한(오래도록 사용되는) 것이 신뢰할 수 있는 부품(컴포넌트)이다. 신뢰할 수 있는 부품은 어떻게 만들어야 하나? 단순하게 만들어야 한다. '어린 왕자'의 작가 생 떽쥐베리의 말을 인용해 본다. "완벽함이란 더 이상 추가할 것이 없을 때 이루어지는 것이 아니라 더 이상 버릴 것이 없을 때 이루어진다."


소프트웨어는 결코 소프트해서는 안된다. 이런 원칙을 실천하기 위한 방법론으로 KISS 원칙와 SOLID 원칙, 디자인 패턴, TDD, 리팩토링, 에자일 등의 기술이 연구되어 온 것이다. KISS(Keep It Simple, Stupid!)와 OOP의 5대 원칙인 SOLID에 대해 정리하려던 차에 서론 부분이 길어져 메모 차원에서 적어둔다.


프로그래머 지망생과 개발자들이 SOLID 원칙 등을 익히는데 어려움을 겪는 이유는 자신들이 코딩하는 함수 혹은 클래스를 언제라도 변경할 수 있을 거라 생각하고, 또 그렇게 변형해서 쓰는 것을 당연하게 여기기 때문이다. 당장 하나 하나의 클래스나 메소드를 만드는데 있어서 완벽함을 추구하기 보다는... 나중에 고치면 된다는 생각에 불완전한 상태의 코드를 만들어 내는 것을 당연히 여기고 죄의식을 느끼지 못하기 때문이다. 이것은 미래의 자신에 대한 범죄이며, 자학이고, 만일 기업에서 소프트웨어를 제작하고 있는 프로페셔널이라면 직무유기인 것이다. 또한 이러한 망상적(혹은 왜곡된) 사상을 가진 사람이 guru 혹은 open source commiter가 될 확률은 닭이 독수리를 낳을 확률보다 낮다고 본다.


Posted by 善 곽중선
2015.02.20 12:22

2015년 2월 15일에 쓴 글.


어제 레드햇 주관의 기술 공유 자리에서 있던 일. 레드햇의 다양한 오픈소스 프로젝트 중에서 통합 테스트 자동화를 지원하는 도구에 대한 소개 세션이 있었다. 통합/회귀 테스트는 인간을 대체하기는 아직은 어려운 분야라서 그동안 나온 상용제품들이 적잖이 실망을 안겨준 바 있다. 하여간, 레드햇의 시도 중에도 이런 게 있다는 소개 차원에서 발표한 것인데, 질의 응답 시간에 거친 발언이 나왔다. 발표자 자신이라면 발표한 제품을 실전에 쓰겠냐고 묻더라.


오픈 소스는 무료가 아니다. 그걸 가져다 쓸만하게 만들지, 혹은 쓰지 말지는 사용자(소프트웨어 개발자)가 판단하는 것이다. 이런 자리를 빌어 경험을 공유하고, 명확한 판단을 도와주는 가이드를 얻는다는 것 자체도 감사해야 한다.


남의 노력과 공유는 가치가 없고 내 시간과 노력만 소중한 것인지... 무엇보다 돈 내고 사라고 한 적도 없는 걸 비난하려 하시는 건 좀 오버 아닌다 싶다. 오픈 소스는 절대 무료가 아니다. 제발... 거지 근성은 버렸으면 좋겠다.

Posted by 善 곽중선
2014.04.24 00:25

참으로 역설적인 표현이라 할 수 있겠다. 게을러야 성공한다니....


열심히 사는데도 불구하고 항상 남의 뒤치닥거리 하는 사람들이 있는 반면에,

대충 대충 하는 거 같아도 성과도 내고 인정도 받는 사람들이 있다.


왜 이런 불편하게 느껴지는 상황이 벌어지는 걸까?

단지 약삭빠른 사람들이 열심히 사는 사람들의 성과를 몰래 빼돌리기 때문인가?


조금 다른 시각으로 따져보도록 하자.

아무 먼 옛날부터 도구의 사용, 농경 문화, 철제 농기구 도입, 산업혁명 등의 기술 혁신과 변화에

따른 생산성의 급작스런 증가에 문명은 급격한 속도로 발전하다가, 또 정체하는 시절들이 반복되었다.


인류가 정착하면서 농업을 발명함에 따라 생산성이 크게 발전했고,

증기기관의 발명 역시 엄청난 사회 변혁을 가져왔으며,

IT 혁명 또한 대단한 생산성 증가를 이루어냈다.


이런 현상의 공통점은 열심히 노력하려는 사람들

- 스스로의 땀과 노력으로 땅을 일구는 사람들 - 이 아니라,

손가락만 움직여서 쉽게 일하기를 꿈꾸는 사람들에 의해서 발전되었다 라는 것이다.


마찬가지로 개발자 혹은 엔지니어는 끊임없이, 적게 일하는 방법을 고민해야 한다.

적은 시간을 투자하고 많은 효과를 내는 방법을 말이다.


단지 무언가를 배웠다고 배운 지식을 활용해서 꾸준히 성과를 내려는 우직한 사람은 의외로 성공하기 어렵다.

자동차를 모는 사람과 자전거를 타고 달리는 사람의 차이라고 할 수 있겠다.

둘이서 하루를 달린다면, 대체 누가 이기겠는가? 뻔하지 않은가?


세상은 참 역설적인 면이 많이 있다.

Posted by 善 곽중선