직접과 간접, 그 사이의 절충

민주주의에 대한 해석과 정의는 무척이나 많지만, 가장 기본은 ‘그 성원이 주권을 행사하는 이념과 체제’라는 사실이다. 그리고, 이를 구현하기 위해 합의를 거쳐 규칙을 정한다. 이를 제도라고 한다. 즉, 민주주의 제도는 그 성원이 주권을 행사하기 위해 만들어진 제도다.

많은 제도들이 있겠지만 거칠게 직접민주제와 대의민주제로 분류할 수 있다. 모든 사안에 대해서 투표라는 행위를 통해 성원들이 직접 주권을 행사하는 것이 직접민주제라면, 투표를 통해 대의자를 선출하여 그 대의자에게 권력을 위임하는 방식이 대의민주제다. 직접민주제는 전문성을 보장하지 못한다는 것과 사회적 비용이 크다는 점이 문제고, 대의민주제는 총의의 반영을 보장하지 못한다는 것과 주권자의 정치적 무관심이 나타날 수 있다는 점이 문제다.

기본적으로 현대사회는 정보기술의 발달에 의해 온라인 투표라든지 빠른 의견교환-소통의 특징을 가지고 있고, 이에 의해 직접민주제적인 요소를 구현하기 용이해진 사회다. 하지만, 개인이 모든 문제에 대해 관심을 갖고 판단을 내리기에는 어려울 정도의 복잡도를 가지고 있는 사회이기도 하다. 그런 이유로, 대의제에 대한 부정보다는 직접민주제의 특성을 반영한 풀뿌리 민주주의, 참여민주주의 같은 절충형 이론들이 21세기 초에 언급된바 있다. 이러한 절충은 주로 대의민주제의 기본요소인 대의자의 역할과 전문성에 대한 존중과 함께 주권자의 역할을 키워 이를 보완하는 형태의 방안이다.

민주주의에 대한 이야기를 늘어놓는 이유는 최근 노동당 내부정세가 흥미롭기 때문이다. 노동당은 당직선거를 통해 대표단(당대표1인, 부대표4인)과 전국위원회(당권자 150인당 1명), 당대회(당권자 30인당 1명)을 선출하고 이를 통한 대의민주제를 구현하고 있다. 기본적으로 대표단은 당의 사업과 정책을 집행하는 집행기구이고, 전국위원회는 일상적으로 열리는 의결기구, 당대회는 최고의 의결기구다. 국가로 치자면, 당대표는 행정부의 수반인 대통령이고 전국위원회와 당대회는 국회라고 보면 되겠다.

흥미로운 점은 대표단과 전국위원회/당대회의 구성이 다르다는 사실이다. 대표단은 ‘진보결집전국당원모임’이란 의견그룹이 과반을 점유하고 있고, 전국위원회와 당대회는 어느 한 그룹도 과반을 차지하지 못한 상태에서 ‘신좌파 당원회의’와 ‘당의 미래’가 ‘진보결집전국당원모임’과 진보결집에 대한 논의를 두고 선을 긋고 있는 상황이다. 즉, “여소야대”의 상황이다. 이 상황에서 지난 6월 4일 발표된 ‘새로운 대중적 진보정당 건설을 위한 4자 공동선언’을 두고 갑론을박이 벌어지고 있다.

정치적 합의를 통해 잘 풀어 나갈 수 있다면 좋겠지만, 당의 진로를 놓고 벌어지는 논쟁인지라 흔히 말하는 ‘통합파’와 ‘사수파’의 평행선 달리기가 계속되고 있다. ‘진보결집전국당원모임’은 당직선거때부터 당원들의 의사를 당원총투표를 통해 묻고, 이에 기반하여 최고의 의결기구인 당대회를 통해 당의 진로를 결정짓자는 주장을 하고 있고, ‘당의 미래’는 꽤나 높은 가결요건(재적과반, 전체 유권자의 50%이상의 찬성)을 가진 당원총투표를 통해 직접 결정짓자는 주장을 하고 있다. ‘신좌파 당원회의’는 결집자체에 대해 반대하고 있다.

반대하는 ‘신좌파 당원회의’는 그렇다 치더라도, 나머지 두 그룹은 전혀 다른 당원총투표를 이야기하고 있다. 노동당의 당헌에 보면, 당원총투표를 ‘당대회는 당원총투표를 부의할 수 있다.’라고 딱 한줄로 정의하고 있다. 당헌이 미비한 것일 수도 있고, 집행기구와 의결기구에서 이를 잘 활용할 수 있도록 열어두었다고 해석할 수도 있다. 어찌되었든 현재의 규칙으로는 당대회에서 당원총투표를 부의할 수 있다. 이 규정을 두고 한 그룹은 이를 잘 활용해서 의결기구가 당원들의 대의를 잘 반영할 수 있도록 하자라고 주장하는 것이고, 한 그룹은 규정이 미비하니 규정을 잘 고쳐서 최고의 의결권으로 만들고 이의 판단을 따르자고 이야기하고 있는 것이다.

과연, 경기를 앞두고 규정을 고치는 것이 맞을까? 아니면 현재의 규정을 가지고 좋은 경기를 만드는 것이 옳을까? 기존의 당헌에 따르면, 당 대의원들은 당의 진로에 대한 권한을 당직선거를 통해 당원들에게서 위임받았다. 그런데 이 권한을 당 대의원들에 의한 당헌개정을 통해 당원총투표로 이관하자는 것은 권한을 위임한 당원들과 위임받은 대의원사이에 맺힌 합의를 깨는 행위다. 당헌에 대한 개정권한이 당대회에 있다 하더라도, 당원들과 대의원사이에 맺힌 합의를 깨는 것은 정치적으로 옳은 선택이 아니라고 본다. 선거를 통해 이루어진 계약을 한쪽에서 일방적으로 수정하는 꼴이지 않은가? 만약, 수정하고자 한다면 당헌 개정권한을 통해 당헌을 개정하고 당대회를 해산한 이후 다시 변경된 계약내용을 기반으로 재구성하는게 옳지 않을까?

한편으로 당원총투표가 단순히 당원들의 총의를 묻는 여론조사라면, 굳이 당대회에서 의결하지 말고 집행부차원에서 여론조사를 하라는 의견도 있다. 하지만, 당대회에서 결의한 당원총투표의 의미란 이 의사결정을 하기 위해 당원들의 대의를 확인할 필요가 있음을 그리고 그 대의를 의사결정에 반영할 것임을 당대회의 대의원들의 결의한다는 뜻이다. 따라서, 대표단이 관장하는 집행부에서 시행하는 여론조사와는 다른 것이다.

그리고, 당원총투표에 대한 왈가왈부가 나오는 가장 큰 이유는 자신들이 당원들의 대의를 반영하지 못하고 있다는 대의자들의 인식과 그에 따른 불안일 것이다. 대의제의 특성상 대의자의 개인적인 의지가 반영되는 것은 당연한 일이겠지만, 당원들의 의지를 공개적으로 확인하고 이를 (자신의 의지와는 다르게) 의사결정에 반영해야 한다는 사실이 압박으로 다가올 것이다. 하지만, 대의자가 지닌 권한이 어디서 출발한 것인지를 생각한다면 이는 당연히 감수해야 하는 일이다.

+1. 무엇보다, 당원협의회 레벨에서는 단선으로 이루어지는 선거가 대다수인 지금의 당직선거가 얼마나 당원들의 대의를 잘 반영할 수 있는지는 무척이나 의문이다.

+2. 자꾸 민주주의의 원칙을 이야기하며 당헌을 개정하자고 지긋지긋하게 이야기해서 투닥투닥.

노트20150206: 적록포럼, 서울의 밤.

“서울의 밤”, 그러니까 불이 꺼지지 않는 도시에서의 생활이란 주제에 대해서 노동과 환경의 관점에서 접근하는 일은 사실 익숙하면서도 익숙하지 않은 무엇이다. 익숙함은 노동과 환경이라는 주제의식에서 오는 것일테고, 그 반대의 느낌은 그 논의의 대상이 주로 다루어지는 ‘낮’이 아닌 ‘밤’이라는데에 있다. 익숙치 않은 부분에 대해 하나의 가치로 예단하는 것이 얼마나 무서운 일인지는 굳이 언급하지 않아도 넘어갈 수 있는 부분이라 믿고, 정리를 시작해보기로 했다. 물론, 아이디어 정리이니 투박하고 거칠 것으로 예상된다.

도시라는 존재는 많은 것들을 흡수하며 커져간다. 많은 것들이 있겠지만, 이번에 다룬 주제에서는 사람과 에너지가 핵심이다. 서울에 인구가 몰려있다는 사실은 대한민국에 발붙이고 사는 사람이라면 다들 아는 내용일테고, 에너지는 사실 좀 의외였다. 에너지 자립도가 6%에 불과한 서울은 외부에서 생산된 에너지에 단단하게 의존한다. 그리고, 현대사회에서 에너지는 전기란 형태로 유통된다. 화석연료의 형태로 공급되는 에너지는 연소라는 과정을 통해 (주로) 열에너지로 변환된 이후 다른 에너지로 변환되지만, 전기로 공급되는 에너지는 전기상태에서 열/빛/운동에너지로 변환이 가능하기 때문에 이는 어찌보면 당연한 일일 수 있다. 발제하신 김현수님은 화석=>열=>전기=>열의 변환과정을 거치면서 발생하는 손실에 주목하셨지만, 사실 변환손실과 화석연료 유통에서 발생하는 추가적인 에너지 부담을 계산해봐야 정확한 평가가 가능해지는 일이다. 그리고, 그 평가와는 별개로 다른 에너지로 쉽게 변환이 가능한 전기라는 매개체는 굉장히 매력적이다.

현재 대한민국에서 사용중인 에너지의 대부분 가정에서 소모되는 것이 아니라, 산업 및 일반에서 사용하는 에너지다. 즉, 기본적인 생활을 하는데 소모되는 에너지가 아니라, 자본이 경제활동을 하기 위해 소모되는 에너지라는 이야기다. 김한울님이 언급하신 외국IT기업의 한국 데이터 센터 설립은 단적인 사례라고 할 수 있는데, 그들이 한국에 아시아지역을 담당할 센터를 설립하는 가장 큰 이유는 “저렴한 전기세”이기 때문이다. 그렇다. 한국은 자본에게는 비정상적일 정도로 저렴한 가격에 에너지를 공급하고 있다. 그리고, 그 에너지는 지금의 서울을 불이 꺼지지 않는 도시로 만드는 가장 큰 지반이다.

자본에게 무척이나 저렴한 이 에너지가 지반이라면, 그 지반 위에 불야성을 세우는 것은 사람이다. 갈수록 늘어가는 야간/심야 노동은 그 증거인데, 이춘희님은 이 문제를 편의점과 야간버스에서 출발하여 풀어내었다. 편의점은 두말할 나위 없이 야간/심야 노동의 아이콘이고, 야간버스-다산콜센터로 대표되는 운송/행정서비스는 그 범위가 공공까지 진입했다는 증거다. 후자를 밀어붙인 박원순 서울시장에 대한 비판은 잠시 접어두고, 나는 전자에 집중하기로 했다.

편의점은 상품을 매개로 ‘편리함’을 판매하는 가게다. 처음에는 신기하기만 했던 24시간 운영하는 이 시스템이 어느새 정착해 내렸다는 사실을 토대로 생각해보면, 거칠긴 하지만 사람들의 ‘밤’이 짧아졌다는 결론에 도달할 수 있다. 노동-자본간의 투쟁의 역사는 기본적으로 노동이 자본에게서 ‘밤’을 확보하기 위한 싸움이었다. ‘밤’은 휴식과 재충전의 시간이다. 잘 지켜지지 않고 있다 하더라도, 법적 근로시간인 8시간이 늘어난 것은 아니다. 그렇다면, 짧아진 ‘밤’의 잉여는 어디로 갔을까?

그래서, 전통적인 이야기인 ‘소비’의 착취를 끄집어내보았다. 자본은 노동이 소비로부터 받아야 할 잉여를 갈취한다. 그리고, 많은 경우 소비는 노동이 한다. 즉, 노동은 생산과 소비 양쪽에서 자본에게 착취를 당한다는 언젠가 주워들었던 이론이다. 이 구조를 갖다 써보면, 자본은 노동이 되찾은 ‘밤’의 시간에 ‘소비’의 시간을 끼워넣음으로 해서 자신의 몸집을 부풀릴 또 하나의 빨대를 만들어낸 것으로 보인다.

밤에 무엇인가가 소비된다면, 그 소비의 대상 재화가 있어야 한다. 이 대상 재화는 낮의 소비에서 채 소진되지 못한 잉여재화인 것은 아닐까? 이 잉여재화가 소비되어야 자본은 이윤이란 이름의 살을 얻어 몸집을 불릴 수 있다. 이를 위해 시장을 더 키울 필요가 있고, 그렇다면 ‘밤’을 빼앗아야 한다. 그렇게 빼앗긴 밤은 소비의 시간으로 탈바꿈한다. 이 논리구조에서 문제는 잉여재화가 발생하는 원인일 것인데, 크게 보면 맞벌이 부부로 대표되는 노동의 변화와 저출산률이 증명하는 인구감소를 통해 추론할 수 있는 시장의 축소가 한 축일 것이고, 다른 하나는 갈수록 강화되는 노동강도와 기술의 발전으로 논해볼 수 있는 생산성의 증가를 고려해봄직하다.

야간/심야노동은 이 순환고리의 결과물이다. 그리고, 이 순환고리는 저렴하게 공급되는 에너지를 그 기반으로 삼아 ‘서울의 밤’을 밝히고 있는 것은 아닐까? 그리고, 이 연결관계는 적과 녹이 함께할 수 있는 지점이 되는 것은 아닐까 조심스레 생각해본다.

어디에서 일할 것인가?

물론 이 글은 살면서 쌓인 지극히 편협한 경험에 근거하고 있다.

얼마전, 아는 분의 부탁으로 한 대학에 특강을 나갈 일이 있었는데, 이때 가장 난감했던 질문이 ‘어디에서 일하는게 좋을까요?’였다. 아마 건설 업계나 자동차 업계였다면, ‘그냥 대기업가면 다 똑같아요.’ 라고 쉽게 답할 수 있었겠지만, 아쉽게도 IT업계고, 이 바닥은 IT업계로 퉁친다는게 신기할 정도로 분야별로 다른 산업이라 보아도 무방할 정도로 다양성이 넘쳐난다. 이런 상황에서 선택한 답변은 -자뻑일지 몰라도- ‘패키지 업체에서 일하세요.’ 였다. 왜 이런 대답을 했을까?

사실, IT업계에서 일한다는 것, 조금 더 좁혀서 IT업체의 R&D부서에서 일한다는 것은 엄밀하게 말해서 어떤 직장상사를 만나느냐의 문제다. 직장상사의 성향에 따라 야근의 비율이 달라지기 마련이니까. 다만, 그 업체가 어떤 성격을 가지고 있느냐에 따라 확률은 좀 달라질 수 있다.

IT업계라고 부르는 “바닥”은 업무 성격으로 보면, 패키지 업체, SI업체, 포탈업체, 게임업체로 볼 수 있다. 패키지 업체는 쉽게 말해 건물 다 지어놓고 분양받는 후분양을 주무기로 삼는 건설업체고, SI업체는 주문받아 건물짓는 업체다. 포털업체는 자기 돈으로 건물지어서 임대료 받는 업체다. 게임업계는 포털과 비슷하지만, 건물 대신에 리조트라고 생각하면 크게 다르지 않을듯 하다.

순서대로 패키지 업체부터 짚어보면, 패키지는 상대적으로 다른 분야에 비해 편하다. 한 회사에서 다루는 제품이라고 해봐야 많아야 5~6개 수준이고, 성향상 비슷비슷한 제품을 다룰 가능성이 농후하다. 사용하는 기술이 그렇게 다양하지도 않다. 제품이 성숙기에 다다르면, 고객의 요구사항을 수용하는 것 보다, 자체 개발을 하는 경우가 더 많기 때문에, 요구사항의 변동도 그렇게 크지 않은 편이다. 다만, 유사한 제품을 만드는 다른 회사와 경합이 붙는 경우가 많으며, 이때 업무 스트레스가 높아질 가능성이 있다. 이런 경우만 제외하면, 업무량의 변화가 크지 않기 때문에, 본인이 컨트롤만 잘한다면 야근없는 한해를 보내는 것도 가능하다. 다만, 패키지 업체의 특성상 개인이 성장하기는 쉽지 않다. 그냥 개발자로 남을 가능성이 크다. 대신, 자신이 담당한 소프트웨어를 계속 가져갈 가능성이 높기 때문에, 개발자가 갖는 자기만족은 높은 편이다.

SI업체를 보자면, 아마 가장 빡센 분야가 아닌가 싶다. 인력파견업체라고 보아도 무방하며, 주로 고객사에서 원하는 시스템을 만드는 역할을 한다. 주로 제품화하기 힘든 시스템을 다루거나, 제품화 시키는 과정에서 많은 인력을 요구하는 작업이 대부분이다. 매번 프로젝트때마다 요구사항 분석부터 다시 시작하는 경우가 많으며, 비용을 아끼기 위해 금액을 깎고 기간을 단축하는 경우가 많다. IT업계에서 자살하는 개발자들이 사회적인 이슈가 된 적이 있었는데, 전부 이쪽 바닥이었던 것으로 기억한다. 빡세다. 야근은 필수다. 하지만, 프로젝트를 진행하며 쌓이는 인맥은 무시하지 못할 정도고, 이 인맥이 나중에 꽤나 큰 자산이 될 수 있다. 이런게 장점이라면 장점이겠지만, 이 단계까지 가는게 너무 가시밭길이랄까…

게임업체는 빡세기로 치면 SI와 맞먹을 것이다. 100% 자체개발일 수 밖에 없음에도 패키지업체와는 달리 빡센 이유는 게임자체의 순환주기가 빠른 편이라서, 패키지보다 업데이트 주기가 빠르다는데 있다.업데이트는 요구사항의 변동을 의미하고, 업무량을 의미한다. 업무량의 변화는 크지 않지만, 그냥 업무가 계속 많다고 보면 된다. 요즘은 많이 좋아져서 덜 빡세졌다고는 하지만, 여전히 IT바닥에서 가장 빡센 부분중 하나라는건 확실하다. 그럼에도 불구하고 사람들이 가는데는 다 이유가 있다. 돈을 많이 준다. 연봉킹.

포탈업체는 어찌보면 업계의 대기업이라고 볼 수 있다. 유행을 심하게 타는 것도 아니고, 연봉도 무난한 편이다. 100% 자체개발에 게임처럼 업데이트가 잦지도 않다. 포털로 한번 들어가면 사람들이 잘 나오지 않는 것으로 보아서, 근무조건도 좋은 편이다. 돈도 게임업체 만큼은 아니지만 꽤 준다. 단점이 있다면, 모 포털의 사례에서 보듯이 잘못 들어가면 줄줄이 목이 날아가는 경우가 생긴다. 게임과는 다르게 기술적 난이도가 그렇게까지 높은 편은 아니라서, 사측에서도 사업을 접을때 그냥 부서를 통으로 날리는 경우가 종종 있는 것으로 보인다. 기본은 블랙홀인데 어느 순간 화이트홀이 된달까. 사실 간지는 난다. 그게 외국계 포털이라면 더더욱. 아, 최대의 단점. 업계중에서 가장 들어가기 힘들다.

이런 업체의 성향은 보스의 성격에도 영향을 주기 마련이다. 확률의 문제긴 하지만, 야근 안시키는 보스를 만날 확률은 역시 패키지 아니면 포털이 높다. 하지만, 알아둘 점이 하나 있는데, 야근 안시키는 보스는 결과물에 더 민감하기 마련이다. 결국, 야근안한다고 널널하다는 이야기라기 보다는 야근 안하는 만큼 근무시간에 더 빡세다는 이야기란 말씀.

사실 어느 쪽을 가든 열심히 하면 장땡이란 부류의 결론을 내리기는 힘들다. 한국 IT의 기본 노동강도가 높은 편이고, 이에 기반해서 생각해보면, SI나 게임에서는 업무에 치여서 자신의 삶을 갖기 힘든 경우가 너무 많다. SI의 장점인 인맥에 기반한 미래나, 게임에 대한 재능이나 희망이 아니라면, 가급적 이 두 업체는 피하는게 좋지 않을까 싶다.

ps. 고백하자면, 자신이 엄청나게 개발을 잘해서 버그가 별로 안난다면, SI를 제하면, 어느 쪽에 가든 진짜로 크게 상관 없다. 일이 빡세지는 가장 큰 이유중 하나가 버그문제니까.

리팩토링: Avoid return statement with value if you can.

영어로 제목을 쓰려던 것은 아니었으나, “Catch me if you can”을 의식하다보니, 이런 제목이 되었습니다. 사실 영어는 종종 의도를 드러내는데 유리하기도 하구요. 🙂

프로그래밍 언어에서 return문은 아주 중요한 역할을 합니다. 프로그래밍을 수학적 모델로 표현하는데 있어서, 함수라는 개념은 핵심적인 역할을 하고 있으며, 함수의 출력을 받는다는 면에서 매우 중요하지요. 하지만, return문은 독입니다. 왜냐구요? 중요한데 왜 독이냐구요? 이야기를 한번 풀어보도록 하겠습니다.

소프트웨어는 개발 기간이 길어지면, 복잡해지기 마련입니다. 처음 개발할때의 요구사항이 그대로 유지되는 경우는 없다고 보아도 무방하며, 늘어난 요구사항은 처음에 짜둔 아름다운 흐름을 망가뜨리기 시작합니다. 소프트웨어의 구조가 무너집니다. 코드는 점점 스파게티가 되어갈 것이고, 문제라도 생겨서 디버깅이라도 하려고 하면 지옥이 따로 없죠.

이런 코드들을 고통을 감내하며 Sequence Diagram을 그려보면, 왜 복잡한지 드러나는 경우가 많습니다. 클래스별로 호출이 들어갔다가 나오고, 그 결과에 따라서 새로운 분기가 발생하는 사태가 벌어지죠. 그리고, 이 분기의 수가 많아지면, Sequence Diagram은 읽기 힘든 선들의 난잡한 리좀이 되어버립니다. 들뢰즈가 극찬했던 리좀이지만, 각 클래스별의 자유로운 결합과 소통이 아닌 서로를 점점 더 구속하는 꼬인 실이 되어버리죠. 그냥 이정도면 모르겠는데, 반환값이 여러개여야 하는 경우에는 return문을 쓰지 못하고, reference나 pointer를 이용한 억지스러운 반환을 하는 경우까지 발생합니다. 점점 더 복잡해져만 갑니다.

갑작스런 이야기 전환이지만, 전투기에 탑승해서 미사일을 쏜다고 생각해봅시다. 미사일은 날아가고 있고, 그 미사일이 격추 결과를 반환하고, 그 결과에 따라 제어를 해야한다면.. 네, 생각만해도 복잡합니다. 반면에, 그냥 미사일을 쏘고 뭐가 어찌되든 알아서 해결된다고 하면, 편안하죠. fire-and-forget입니다. call-site에선 신경쓰지 않는겁니다. callee쪽에서 알아서 하겠죠 뭐.

함수를 호출하는데 있어서 그 결과값에 신경써야 한다는 것은 상당한 위험성을 내포하고 있습니다. 단순한 수학 연산이나, 문자열 검색같은 피할수 없는 반환값이라면 모르겠지만, 소프트웨어가 구현하는 Business Logic이라면, 그 결과값에 따른 논리구조의 분기는 피할 수 없습니다. 결과값이 존재한다는건, 그 결과값에 따라 무언가 다르게 하려고 했기 때문일테니까요. 그리고, 그 분기는 요구사항이 늘어나면 늘어날수록 두고두고 당신을 괴롭히겠죠.

Sequence Diagram을 생각해봅시다. return문이 없다면, 함수호출을 의미하는 화살표만 있으면 됩니다. 반환값에 따른 분기도 없을테고, 분기가 일어나는 시점은 바로 그 분기조건을 확인하는 그 순간입니다. 더욱 간단해지죠. 그래봐야 Sequence Diagram이 복잡해지는건 매한가지 아니냐? 라고 생각할 수 있겠지만, 원래 복잡한 논리구조를 표현하는데 복잡한건 당연하겠죠. 다만 그 복잡함을 따라가는데 얼마나 더 쉬운가를 이야기하는 겁니다.

이렇게 짜다 보면, 어떤 객체의 상태변화에 대해서 반응하는 코드를 구현하기가 어려워집니다. 이때 사용하는 기법이 Callback이고, Callback을 사랑하는 이유죠. Callback은 대부분의 경우, 직관적이지 못하다는 이유로 배척당하곤 하는데, 간단한 소프트웨어의 경우엔 그렇습니다. 하지만, 복잡해지면 복잡해질수록 그 진가를 발휘하곤 하죠. 특히, 복잡해지면서 유사한 상태변화가 늘어날 경우에 더더욱 심해집니다. Callback기법을 적절히 사용하고 있다면, 해당 상태변화가 감지되었을때, 그 감지에 대한 분기를 추가하는 것이 아니라, 미리 지정된 Callback을 호출하기만 하면 되니까요. 이렇게 하면, 소프트웨어의 실행흐름을 Input Layer -> Business Layer -> Reaction Layer로 나누게 됩니다. 그리고, Reaction Layer를 만들때 Callback을 활용하게 되죠.

이는 객체지향 패러다임의 원칙중 하나인 Encapsulation과도 관계가 있습니다. Encapsulation이 필요한 데이터만 노출해서 소프트웨어를 간단하게 만든다면, 이번에 제시하는 이 원칙은 대부분의 분기를 감추는 것으로 소프트웨어를 간단하게 만든다고 볼 수 있지요. 또한, Callstack을 보는 것 만으로 분기가 어떻게 일어났는지 확인할 수 있다는 장점도 있습니다. 재현가능한 버그라면 모르겠지만, 소프트웨어가 비정상종료 되면서 남긴 제한적인 Callstack정보로 디버깅을 하는 경우에는 더더욱 유리해집니다.

이게 뭔소리냐. 하실 수 있겠지만, 제목에 if you can이 붙은건 가급적이면 피하라는 이야기입니다. 반환값을 가진 return문은 결국 호출측에서의 분기를 유발하게 되고, 그 분기는 소프트웨어를 복잡하게 만들 가능성을 내포하고 있으니까요.

 

개인정보의 관리책임

개인정보 보호 전문기업에서 일한지 12년이다. 그리고, 그 짧지 않은 기간 동안 이렇게 전 국민적인 관심을 몰아받는 보안사고도 없었다. 단언컨데, 이건 최악의 “개인정보 유출 사고”다. 보는 관점에 따라서는. 이를 한 하청업체 직원이 작심하고 개인의 금전적 이익을 위해 빼돌린 범죄 사건이라고 볼지, 아니면 금융당국의 허술한 보안 체계에 의해 발생한 사고인지는 사건을 바라보는 사람에 따라 각양각색이겠지만, 보안전문가 입장에서는 단연코 사고다. 아직까지는.

사건의 개요를 잠시 되짚어보자면, 코리아 크레딧뷰로(이하 KCB)가 농협, 국민카드, 롯데은행에 가서 외주 프로젝트(카드 분실, 유실, 위변조 관계 시스템 개발)를 수주했고, 이 프로젝트를 진행하기 위해 파견된(!!!) KCB의 직원이 위의 3개 금융사에서 정보를 빼돌렸다는 것이 주된 골자다. 그 과정에서 어떻게 이렇게 쉽게 그 정보가 빠져 나갈수 있느냐! 라고 일갈하기는 쉽겠지만, 보안이라는 것도 생각보다 복잡하다.

정보와 관련된 보안은 보통 외부침입과 내부유출로 나뉜다. 이번의 농협말고, 2011년의 “농협”사건은 외부침입이다. 물론, 외주직원이 매개체가 되었지만, 그 외주직원의 의지가 아니었다. 북한의 소행이네 어쩌네 하는 말이 많았지만, 진실은 저 너머에 있으니 차치해두고 이야기하자면, 해당 정보를 관리하는 조직 내에 속한 사람이 아닌, 외부의 누군가가 용케 쳐들어와서 정보를 들고 날랐다는 소리다. 더 쉽게 말하자면, “강도질”. 반면에, 이번의 사건은 내부유출이다. 관계자가 내부의 개인정보를 들고 빼돌렸다는 이야기다. 즉, “배임행위”다.

헌데, 외부침입과 내부유출의 스케일을 비교해보면 이건 압도적으로 내부유출의 승리다. 놀라울 정도로 금융쪽 사고들과 닮아있다. 은행강도와 배임행위를 비교해보면 된다. 은행강도는 쳐들어와도 끽해야 몇억정도 털어가고 금고부숴지는 정도지만, 배임행위는 그 액수가 기본 수십억에서 수백억에 이른다. 스케일이 다르다. 개인정보쪽도 마찬가지다. 수십만건이 털렸으면, 그건 외부침입일 가능성이 크고, 이번 건처럼 수천만건이 털렸으면 내부유출일 가능성이 높다.

왜냐? 이유는 간단하다. 최근의 IT시스템들은 굉장히 복잡하다. 쉽게 말하자면, 책이 엄청나게 많이 꽂혀있어서 사서의 도움없이는 책을 찾을 수 없는 도서관을 생각하면 된다. 그 도서관에 불을 내고 몇권 훔쳐가는거랑, 그 도서관의 사서가 굉장히 비싼 일부 서적만 빼돌리는 것의 차이는 명확하다. 그렇다. 바깥에서 들어오는 도둑놈 막는 것도 중요하지만, 내부자들을 단속하는 것도 중요하다. 내부자는 비싼게 어디에 얼마나 있는지 정확하게 알고 있을테니까.

그런 이유로, 최근 기업들이 도입하는 수많은 보안솔루션들의 초점도 내부유출방지에 있다. 만약, 새로 설계하는 시스템들이라면, 설계단계에서 이미 개인정보에 대한 접근 가능성부터 관리부분까지 전부 신경써서 만들고, 이를 보조하는 형태로 보안 솔루션을 도입하고, 그게 아닌 기존의 시스템이라면, 기존 시스템의 유출 가능 경로들을 분석해서, 그 경로에 맞는 보안 솔루션을 도입하는 것이 일반적이다.

그리고, 정부에서는 각 기업에서 보안 솔루션을 도입할때 반드시 갖추어야할 기본 사항들에 대해서 법으로 지정하고 있다. 주로, 개인정보보호법과 정보통신망법인데, 이 두 가지 법안은 개인정보를 취급하는 기업에서 이를 처리하는 시스템에 대해 어떤 보안조치를 해야하는지에 대해 기본적인 사항들을 명시하고 있다. 이런 법안은 사실, 일부 잘나가는 기업들이 보안솔루션을 도입해서 사용하고 있는 상황에서, 개인정보 유출 사고들이 터지기 시작하니, 만들어진 법안이다. 그리고, 각 기업/기관들은 이 법안에서 명시한 사항들을 지키기 위해 솔루션을 도입하고 있다. 이런 상황이다보니 이제야 도입하는 기업/기관들은 이게 잘 될리가 없다. 왜냐? 처음에 사용하던 잘나가는 기업들과는 도입이유가 다르니까.

잘 나가는 기업들이 도입한 이유는 자신들의 기술자산을 보호하기 위해서다. 더 정확히는, 기술자산에 접근 가능한 인력들이 다른 생각을 못하도록 하기 위해서다. “우리는 기술자산에 이렇게 신경써서 보안적 조치를 하고 있다. 만약, 네가 이를 유출한다면, 이하 생략이다”라는 이야기를 하는거다. CCTV가 있는 곳의 범죄율이 낮다는 이야기와 동일한 논리적 구조다. 실제로 역할도 비슷하고.

하지만, 법을 준수하기 위해 기업/기관들이 도입한 내부정보 유출방지 솔루션들은 법에 정의된 항목을 만족시키기 위해 도입한 시스템이다. 내부유출방지에 도움이 되냐고? 당연히 된다. 잘 나가는 기업들에게 엄청나게 두들겨 맞으면서 만든 제품들인데, 도움이 안되는게 이상하지 않을까? 문제는 그 시스템들을 운영하는 주체-주로 보안팀-에게 있다. 반복적이고 지속적으로 내부자들을 귀찮게 하면서, 이런 정보를 함부로 다루면 안된다고 이야기해야하는데, 이게 말처럼 쉽지 않다. 내부정보 유출방지 솔루션들이 설치되면 당연히 인터넷도 불편하고, PC활용도 불편해진다. 이렇다보니, “일 못해서 손해나면 당신이 책임 질거야?” 류의 항의들이 들어오고, 유출방지 솔루션들은 하나 둘씩 무기력해진다. 그리고, 내부자들은 일을 더 중요하게 생각하게 되고, 개인정보에 대한 중요도를 잊게 된다. 그리고, 배고프면… 뭐… 게!다!가! 이번 사건으로 돌아와보면, 무려 외주직원이다. 더 이상 무슨 말이 필요한지…

이래서 사고라는 거다. 내부정보 유출방지를 위해 해야할 것들이 다 이루어지지 않은 상태에서, 일어난 일이니 사고라는 거다. 만약, 잘 나가는 기업에서 기술자산이 2014년에 유출되었다면 이는 사건이다. 필요한 보안 조치들과 이에 대한 문화적기반(?)이 모두 구축이 되어있으니까. 하지만, 2013년 6월의 유출은 사고다. 미리 대비하지 못한 사람들이 만들어낸 인재.

ps. 비현실적인 이야기라고 할 수 있겠지만, 대부분의 유출사고는 결국 배고파서 일어난다. 은행 직원들 월급 많이 받는다고 말이 많지만, 월급이 적으면, 은행들 다 털리고 난리도 아니겠지. 개인정보도 비슷하다. 민감한 정보를 외주업체들한테 그만 맡기고, 필요한 인력은 직접 채용해서들 쓰시라.

 

Macbook Pro 레티나: 라인업이 복잡해진 이유

사실, 이번 WWDC에서 발표된 Macbook Pro Retina는 11/13인치의 Macbook Air와 13/15/17의 Macbook Pro를 통합해서 11/13/15의 맥북라인으로 재정립할거라고 예상했던 것과는 달리 단지 15인치 모델만 나왔다.  Foxconn이 노동력 부족으로 개고생했다는 이야기를 보면, 단지 레티나 디스플레이의 수율문제는 아닌 것으로 보인다.

new iPad의 두께 및 중량증가를 생각해보면 어느정도 답이 보이는데, 11/13인치의 Macbook Air에 레티나를 탑재하게 될 경우 배터리가 걸리게 된다. 레티나는 자체로도 소비전력이 더 높을 것이고, 구동하는데 필요한 CPU/GPU자원도 일반 디스플레이에 비해서 크기에 더더욱 소비전력이 높을 것으로 생각해 볼 수 있다. 배터리가 딱히 발전한게 없다면, Macbook Air에 레티나를 탑재하면 지금의 두께와 무게를 유지할 수 없게 된다. (SSD도입등의 무게감소 테크닉들은 이미 Air엔 적용이 되어있으므로.)

그리고, Macbook Pro 13인치의 경우 Macbook Air 13인치와의 팀킬을 방지하기 위해서 낮은 해상도를 유지하고 있었는데, 13인치 레티나가 나올 경우 Macbook Air가 타격을 입게 된다. (사실 Macbook Air 13인치가 땡기는 이유는 무게도 무게지만 해상도가 높다는게 크다. 13인치 액정에 15인치급 해상도를 때려박아놨으니..) 그런고로 Macbook Pro 13인치도 나오지 않은 것으로 보인다.

Macbook Pro Retina를 주문하면서 체크해본 바로는, Macbook Air와 마찬가지로 메모리와 SSD가 보드에 납땜되어있다. 이런걸 보면 사실 Macbook Air 15인치라고 봐도 무방할 정도. 즉, 레티나를 탑재해야하는 입장에서 기술적, 시장상황으로 봤을때 현실적으로 손질할만한 모델은 15인치 Macbook Pro였던 것. 어찌보면, 당연한 결과라고 하겠다.

문제는, 앞으로 라인업이 어찌될것인가인데 배터리가 개선되어 Macbook Air가 기존의 사용성을 유지할 수 있게 되어 레티나 탑재가 가능해진다면, 기존의 Macbook Pro라인이 정리되고, 전부 레티나 디스플레이를 가진 모델로 정리될 가능성이 있다. 혹은, 3분기에 나온다는 799달러 Macbook Air가 현실화 된다면, 레티나를 가진 Pro라인과 엔트리급의 Air라인으로 정리될 가능성도 농후하다.

뭐. 이렇게 이야기해봤자. 쿡아저씨 마음대로겠지만.

ps. 그런데, 슬슬 개발 포스팅도 해야할건데 (.. )a

iPad 2 vs. new iPad: 레티나를 위한, 레티나에 의한, 레티나의 iPad

1. 들어가며

본 포스팅은 레티나 디스플레이를 채용하고 2012년 3월에 공개되어 4월하순에 한국에서 발매된 Apple의 new iPad에 대한 포스팅이다. 이미 공개된지 3개월, 한국에서 발매된지 2개월이 지난 시점이기 때문에, new iPad 자체의 스펙이나 기능성보다는 Apple이 어찌보면 단순한 디스플레이의 교체만으로 내놓은 이 신제품이 갖는 전략적인 위치와 그 의미, 그리고 이를 가능하게 한 Apple의 능력에 대한 분석이 주가 될 것이다.

2. new iPad vs. iPad 2 & iPad: 이게 다 레티나 때문이다.

Apple은 2010년 4월, 소문만 무성하던 태블릿형 컴퓨터인 iPad를 세상에 내놓았다. 최초의 태플릿형 컴퓨터는 아니었지만, 기존의 데스크톱용 운영체제가 아닌 애플의 Mac OS X을 기반으로 만든 iOS를 채용하면서, 컴퓨터로서의 위치보다는 새로운 “태블릿” 혹은 “패드”라는 전자기기의 영역을 구축하였다. 이는 Android 3.0 – HoneyComb의 등장으로 이 클래스의 전자기기가 하나의 시장이 되었음이 증명되었으며, 현재 많은 제품들이 iPad를 따라잡기 위해 노력하게 되었다. 더 보기 “iPad 2 vs. new iPad: 레티나를 위한, 레티나에 의한, 레티나의 iPad”

클래스는 영원하다: 범용 컴퓨팅 장치의 크기.

“클래스는 영원하다.”

빌 샹클리라는 축구감독의 발언에서 유래한 최근의 이 유행어는 스마트폰, 7인치 탭, 10인치 패드의 ‘클래스’에도 정확하게 적용된다. 이 ‘클래스’는 성능같은 geek한 속성에 의해 좌지우지 되는 것이 아니라, 단 한가지의 속성에서 결정된다. 그건 바로.

크기

크기! 크기! 크기! 무게나 성능, 두께같은 다른 속성은 부차적일 뿐이고, 가장 중요한 것은 크기. 화면 크기다. 화면 크기는 상당히 많은 것을 내포하고 있는데, 크기는 무게나 두께를 동반하고, 이렇게 도출된 물리적 스펙은 이동성을 결정짓는다. 이 이동성은 배터리의 성능과 연결되어, 탑재가능한 CPU를 결정짓고 성능을 도출한다.

크기가 가장 중요한 요인인 또다른 이유는 인간의 시력에 있다. 인간이 볼 수 있는 글자의 최소 크기는 정해져 있다. 개인별로 차이는 있겠지만, 최소 10pt이상은 되어야 편안하게 읽는 것을 보통이라고 가정할때, 장치별 화면의 크기는 해당 장치에서 한번에 볼 수 있는 정보의 양이고, 그 정보의 양은 장치의 사용성을 결정짓기 마련이다.

물론, 역으로 생각해보면, 사용성에 맞추어 그 크기를 결정지었다고 할 수 있다. 현재 눈앞에 놓여진 클래스는 ‘화면 크기’다. 정보를 ‘읽는’다는 측면에서 접근해보면 좀 간단할 것 같다. 흥미롭게도 책장의 책을 유심히 살펴보면 비슷한 분류의 책들은 그 크기도 비슷하다는 걸 알 수 있다. 컴퓨터 관련 서적들의 크기는 다 비슷하고, 소설책들의 크기 역시 다 비슷하다. 소설책을 A4로 내지는 않으며, 레퍼런스를 문고판으로 내지는 않는다. 컨텐츠가 요구하는 사용성에 맞게 크기가 결정된 것이다. 논리의 앞뒤가 바뀐다고 해도 결국 크기가 중요하다는 사실은 변하지 않는다. 실제로 아이패드가 처음 나왔을때 덩치큰 아이팟 터치라고 비웃음을 샀지만 (필자도 그 비웃음에 동참했었다.) 실제로 써보니 전혀 다른 경험이었다.

현재 가장 대중적인 클래스인 4인치급의 스마트폰, 7인치급의 탭, 10인치급의 패드, 12인치급의 노트북은 각각의 클래스에서 경쟁하는 제품이지 서로 경쟁하는 제품이 아니다. 즉, 삼성이 내놓은 갤럭시탭은 아이패드의 경쟁자가 아니라, 7인치탭의 시작점에 불과하다.

새로운 개념의 제품이 등장하고 각 클래스에서 패러다임이 바뀌는 현상은 4인치급에서 적나라하게 확인할 수 있다. 언젠가부터 PDA라는 용어가 사라졌으며, 스마트폰이 대세다. Palm과 WinCE로 대표되던 PDA들이 아이폰을 앞세우고 안드로이드가 뒷받침하는 스마트폰에게 처참하게 패배한 것이다. 이런 전례로 비추어 보건데 예상되는 경쟁관계는 7인치급의 네비게이션/PMP와 탭의 경쟁, 그리고 10인치급의 넷북과 패드의 경쟁이 될 것이다. 4인치급의 전쟁을 돌이켜보건데, 획기적이고 파급력있는 제품이 뚫고, 유사한 다종의 제품들이 기반을 다지는 형태의 상황이 될 가능성이 높다. 10인치급은 애플의 iPad라는 에이스가 존재하지만, 7인치급의 갤럭시탭이 그 에이스의 역할을 담당할 수 있을지는 의문이다. 10인치급의 넷북은 iPad가 열어제낀 패드들에게 밀려나갈 가능성이 높으며, 7인치급의 탭은 네비게이션/PMP들이 탭의 기능을 흡수하면서 통합될 가능성이 높다고 본다.

4인치, 7인치, 10인치 등의 화면크기는 손에 “들고” 사용해야하는 상황의 모바일 범용 컴퓨팅 장치에서는 결정적인 factor이며, 당분간 이 클래스는 변동치 않으리라고 본다. 축구에서처럼 클래스는 영원하다.

ps. 적어놓고 보니 당연한 이야기를 어지럽게 풀어버렸다. 이런 산만함이라니. orz

집착하고 있는 것: 흐름

몇몇 지인들은 알고있는 사실이지만, 최근 3년간 집착하고 있는 것은 ‘흐름’이다. 다분히, 들뢰즈적인데, 2004년에 처음 만나서, 가장 많은 영향을 준 사람이니 당연하다면, 당연한 사실이다. 이렇게 쓰면서도 이것이 들뢰즈적이라고 부를 수 있는 것인지 의문스럽다. 공부는 안하면서, 단초만 잡아서 공상만하고 있는 것도 사실이므로.

이런 생각을 하게 된 데에는, 회사에서 밥벌이로 작성하고 있는 소프트웨어가 처절할 정도로 흐름에 기반을 두고 있고, 데이터의 흐름을 어떻게 하면 잘 처리해낼 수 있을 것인가가 관건이기 때문이다. 일반적으로 바라보는 객체지향 프로그래밍의 모델링 사상과는 어느 정도 동 떨어져 있는 것도 사실인데다, 복잡하기 그지없는 인터페이스의 난립에 지쳐있기 때문이기도 하다.

그런가하면, 이 ‘흐름’은 2001년에서 2003년까지 연구하던 주제이기도 하다. 당시에는 Business Process를 연구하고 있었고, BPMS와 Simulation Engine이 주요 과제였다. 이런 면에서 보면, 산업공학이란 전공을 선택한 것이 다행이라면 엄청난 다행이다. ‘흐름’은 절단 가능하고, 연결 가능한 그 무엇이다. BPMS와 Simulation Engine이 그랬던 것처럼. 그리고, 그 흐름에 연결되는 다양한 지반들을 어떻게 모델링 해낼 것인가가 현 시점에서 객체지향주의자로서 갖는 유의미한 과제다.

회사의 일정과 시장에서의 위치덕분에 지금 당장은 구현이 어려운 상황이다. 그런 이유로, 무언가 다른 일이 하나 필요할 듯 싶다. 가능하면, 올해 맞는 내 생일 전에 말이지. 씨익-

언어-사고: 프로그래밍은 왜 어려울까?

프로그래밍을 한다고 하면, 사람들은 종종 안드로메다에 거주하는 외계인으로 간주하는 경우가 있다. 특히, 작업하는 것을 옆에서 보게되면 더더욱 심하다. 영어의 탈을 쓴 알아볼 수 없는 괴악한 텍스트 문서를 만들고, 이상한 프로그램을 돌려서 그들이 사용하는 소프트웨어를 만들어내니 그렇게 생각하는 것도 무리는 아닐 것이다. 그런데, 사실 사람이 쓰는 언어보다 프로그래밍 언어 자체는 쉽다. 애매모호함도 덜하거니와, 기계적으로 맞아 떨어져야하는 언어이기 때문에 쉬운건 사실이다. 그렇다면, 왜 사람들은 프로그래밍을 어려워할까? 답은 사고에 있다.

인간이 사용하는 자연어는 일반적인 사고의 틀내에서 존재하지만, 프로그래밍 언어는 특정한 목적에 의해 특정한 사고의 틀내에 존재한다. 이 사고방식이 절차지향 프로그래밍이라든가 객체지향 프로그래밍이라든가 함수형 프로그래밍같은 거다. 이 사고방식은 컴퓨터라는 기계의 작동방식에 그 근원을 두고 있기 때문에 자연어의 사고방식과 유사하지만 다르다. 그리고, 이 차이가 어려움을 가져온다. 한가지 재밌는 것은, 자연어의 사고방식과 유사한 사고방식의 언어를 접하게 되면, 프로그래머도 난감해한다는 점이다. 기존의 방식과는 다르므로.

쉬운 프로그래밍은 근본적으로 불가능할지도 모른다. 하지만, 프로그래밍을 쉽게 배우려면, 언어나 문법에 집중하는게 아니라 그 사고의 작동방식에 초점을 맞추어야하지 않을까?