Category: Uncategorized

최근 알고리즘 논쟁을 보고 느낌점…

최근 인터넷에 난데 없이 알고리즘 논쟁이 있었던 모양이다. 뭐 인터넷이라는게 방대하고 거기다 한국이란 곳으로 국한한다고 하더라도 몇몇 커뮤니티를 타고 옥신각신 한 정도밖에 더 될까만은 매우 흥미롭게 지켜보게 됐다.

원래 성격상 흥미가 없으면 ‘별 시덥잖은 이야기’ 정도로 치부하는데, 알고리리즘 논쟁을 보고 흥미가 생긴 이유가 아주 근본적인 사고차이에서 비롯된 것이라 생각했기 때문이다.

발단은 다음의 글에서 출발 했다.

개인적으로 알고리즘 관련 논람에 민감한 이유

알고리즘이 더 이상 모든 분야의 기본 지식이 아니라고 생각하는 이유는 이미 그런 토론을 통해 충분히 이야기했기 때문에, 지금은 왜 제가 이런 문제를 특히 민감하게 느끼는지에 대해 적어볼까 합니다.

제 생각에 자바나 C#, 혹은 자바스크립트 개발자에게도 ‘기초 지식’으로 알고리즘이나 운영체제 등을 공부할 것을 주문하는 것은 대체로 그런 ‘기본’을 배우면 나머지 ‘응용분야’는 쉽게 익힐 수 있을 것이라는 가정에서 출발하는 것 같습니다.

그리고 경우에 따라선 한 걸음 더 나아가 자바 같은 고수준 언어로 다루는 분야는 모두 그런 ‘응용’에 해당하기 때문에 보다 근본적이고 깊이 있는 운영체제나 C언어 등만 제대로 하면 어렵지 않게 익힐 수 있을 것이라는 근거없는 자부심으로 표출되기도 합니다.

https://okky.kr/article/396435

전체적으로 댓글이 우호적으로 달리는데, 개인적으로 적지 않게 놀랐다. 도대체 저런 글에 저렇게 많은 공감을 얻은 이유는 무엇일까? 라는 의문이들게 되면서 이 논쟁을 지켜보게 되었다.

얼마 가지 않아 다른분이 반론글이 올라오기 시작했다.

저주스러운 대한민국의 SI와 6개월짜리 국비지원 학원들 때문에 우리나라는 개발자들에 대한 인식이 형편없어졌는데, 개발자는 노가다꾼이 아니고 공학자에 속하는 직종이다. 자신의 재능이 아무리 비천할지라도 언제나 높은 수준에 오르기 위해 공부하고 자신의 결과물이 완벽에 가까워지도록 노력해야 하는 종류의 사람들이라는 뜻이다. 그런데 지금 소개하는 주장은 대학교에서 배우는 CS Fundamental이 구시대적이기 때문에 대학교의 커리큘럼이 예비 개발자들에게 구현에 대해 능숙해지도록 좀 더 가이드해야 한다고 주장한다. (대학이 직업학교인가?) 그런데 재미있게도 이런 주장을 하는 사람들은 이른바 개발자 커뮤니티의 네임드라는 부류는 될지언정 누구나 인정하는 구글러나 페이스북 개발자, 스타개발자는 아니다. (사실, 그런 사람들은 그런 시시한 커뮤니티를 하지도 않는다. 나도 페친들 링크 타고 가게됐을 뿐이다) 오히려, 인터넷에서 이름을 보는 대가들은 자료구조와 알고리즘을 탄탄이 하기를 당부한다. 그런데 왜 많은 사람들이 이런 말도 안되는 주장에 동조하고 열광하는가?

https://medium.com/@ghilbut/%EC%8B%A4%EB%AC%B4-%EA%B0%9C%EB%B0%9C%EC%9E%90%EC%97%90%EA%B2%8C-%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98%EC%9D%80-%EB%8D%9C-%EC%A4%91%EC%9A%94%ED%95%A0%EA%B9%8C-fcbab7f87074

많은 사람들이 이글을 보았을 텐데, 웃기게도 ‘글이 너무 격양되어 있다’, ‘논리적인 글보다 욕하는 글’이라는 씹선비질 하는데 웃음이 났다. ㅋㅋ 격양된 글이긴 하지만 나름대로 논지가 있었기 때문에 그 논지에 대한 말들은 없고 그져 글이 어떠내 저쪄네… ㅋㅋ

위 글은 1부, 2부로 나뉘는데 이 글을 쓴 사람의 논지는 ‘알고리즘은 문제를 해렬하기 위한 방법으로 기능적 유효성이 있다’ 정도로 보인다.

 

알고리즘=문제해결 능력

개발자도 아닌 나 같은 사람은 알고리즘을 몰라도 된다. 탐색트리가 어쪄네 뭐가 어쩌네 하는 골치아픈 것들은 개발자들이나 하는 것이지 나 같은 밑바닥 인생을 사는 사람과 거리가 먼 이야기다.

이렇게 말을 하면 첫번째 글에 동조하는 듯하지만, ‘알고리즘’ 이라는 전형적인 전산학이 의미를 버리고 ‘문재 해결 방법’ 이라는 의미를 부여하면 두번째 글이 더 설득력이 있게 된다. 나 또한 두번째 글쓴이에 말에 동의 하는 바이고 그가 주장하고 비토했던 것에 전적으로 동의한다.

개발이 아니라 시스템을 운영하다보면 별의별 사건사고가 발생한다. 흔히 ‘장애’ 가 발생하면 최대한 빠르게 문제를 해결해야 한다. 그렇지 않으면 고객으로부터 손해배상을 제기하겠다는 서슬퍼런 이야기를 듣게 될테니까.

전부 다 그렇게 일하는 것은 아니겠지만 시스템 운영측면에서 장애 발생하면 대부분의 사람들은 ‘경험’ 에 의존하게 된다. 과거에 유사한 장애가 발생한 경험을 기반으로 문제를 해결하는 것이 가장 빠른 방법이기 때문이다. 시간은 자꾸가는데 운영체제론이 어쩌고 컴퓨터이론이 어쩌고 떠들어대봤자 답이 안나온다.

문제는 이러한 경험을 문제를 해결하고 난 다음이 문제가 된다. 반드시 장애 처리 후에 복기를 해보는데, 이게 정말 제대로된 문제해결이였는지를 평가해 향후 같은 장애가 발생하지 않도록 하는 회의를 진행한다.

바로 이 회의에서 ‘알고리즘’ 이 나온다. 웽? 시스템 장애 대응 회의때에 개발자 알고리즘이 나온다고?

ㅋㅋㅋ 알고리즘을 문제해결 능력이라는 측면으로 본다면 시스템 장애 대응 회의는 알고리즘이 회의가 된다. 개발자들이라는 시각으로만 좁게 보다보니 알고리즘이라고 하면 전산학 이론의 알고리즘만을 생각하지만 그 시각을 좀 더 확대 해보면 알고리즘이라는 말 자체는 문제를 해결하는 방법론을 전부 총칭한다.

결국 알고리즘을 잘 하냐 못하냐는 문제를 해결할 능력이 있는냐 라는 말과 같은 것이다. 이렇게 보면 알고리즘이라는 것 자체는 우리가 살면서 매일매일 생각하고 해결하는 것들과 다를바 없다.

그래서 두번째 글의 글쓴이가 예를들었던 면접 관련 이야기가 알고리즘이 무엇인지를 정확하게 보여준거라 생각한다.

알고리즘 인터뷰가 시작되면, 면접관은 데이터와 해결해야 할 문제를 포함한 몇 가지 조건들을 준다. 다만, 이 조건들은 대부분 완벽하지 않다. 대부분은 필수 요소 몇 가지가 빠져있으며, 때로는 아무 쓸모없는 조건들이 함께 있을 때도 있다. 이 조건들을 질의응답을 통해 문제 정의 가능한 수준으로 정리해야 한다. 그리고 나면 그 문제를 해결하기 위해 어떤 전략을 사용할 것인지를 설명한다. 면접관과 문제 해결 전략과 솔루션의 공간복잡도 및 시간복잡도 등에 대해 토론한 뒤 정리가 되면 구현을 시작한다. 이 때, 면접관이 내가 생각하지 못한 예외 케이스들을 자꾸 제시해서 코드 수정이 잦아지면 인터뷰는 200% 망했다고 보면 된다. 합격하려면 일반적으로 코드가 한번에 완성되어야 하고, 그렇기 때문에 구현 전에 토론과 함께 주의 깊게 전략을 완성해야 한다. 일반적으로는 그렇게 문제 풀이가 끝나지만, 구글은 종종 해당 문제에서 데이터셋의 스케일이 매우 커졌을 때에 대한 질문을 던진다. 현재 솔루션으로 확장된 데이터 규모에 대응 가능한지, 그렇지 않다면 이유가 무엇인지, 그럼 어떤 방식으로 더 큰 규모의 데이터를 처리할 수 있는지에 대해 솔루션을 요청한다. 이 때, 인터뷰 내용은 구글 내부에서 실제로 처리하는 업무의 인터뷰 버전일 가능성도 있다. 다시 강조하지만, 알고리즘 인터뷰는 절대 당신이 얼마나 아름다운 알고리즘을 외우고 있는지 보려는 것이 아니라 당신의 커뮤니케이션 능력과 논리적 사고력을 보고 싶어하는 것이다.

구글이라는 회사의 예제인데, 당연히 구글은 컴퓨터 회사이고 우리가 알고 있는 전산학의 알고리즘쯤은 줄줄이 꽤고 있어야 하며 그것을 기반으로 구글이 문제를 풀어야 한다. 문제는 두번째 글쓴이가 예를든 글을 자세히 읽어보면 면접시에 단순하게 면접자에게 알아서 풀어봐식은 하지 않는다는 것이다.

개인적으로 외국계회사에 면접도 몇몇보고 느낀 것이 바로 두번째 글쓴이가 이야기한 구글의 면접과 비슷했다. 면접관이 문제를 주는데, 문제자체가 문제가 있는 경우가 많았다. 그것을 캐취해서 자신이 의견을 피력하고 면접관과 토론을 벌여야만 했다.

겁나, 아니 존나 힘들었다. 면접관가 토론을 한다고 ??? ㅅㅂ 그냥 화이트보드에 알고리즘 기술하고 ‘맞죠?’ 하고 말지… 면접관은 화이트보드에 마커를 집어들기 전까지 ‘니가 문제를 어떻게 할지 설명해봐~’ 를 계속 요구했다. 이미 내 머리는 김이나기 시작했고……

그런다음에 Python 으로 문제 해결을 구현해야하는데, 이때부터도 난제들이다 . Python 을 얼마나 알고 있는지를 테스트하기 위해서 코딩하는 내내 ‘이건 왜 일케 코딩했지?’ 라는 질문이 계속 쏟아졌다. ‘Python 은 글케 하면 비효율적이다’, ‘문자열 처리는 일케 하면 어케하냐?’ 식의 비난과 비판.. ㅋㅋ 물론 팁도 준다. ‘이건 이렇게 해야 더 좋아~’ 식인데, 문제는 그게 왜 좋은건지 모르면 답 없는 거지.. ㅋㅋㅋ (내가 그랬음.. ㅋㅋ 왜 글케 해야하는지 몰랐음.. ㅋㅋㅋ 그냥 면접관이 그게 좋다니까 그걸로 했지.. ㅋㅋ)

내가 봤던 외국회사에 면접에서는 전산학 알고리즘은 단 한줄도 나온적이 없다. 그렇다면 내가 그 면접에서 알고리즘을 사용한적이 없는가? 전혀 그렇지 않다. 면접관과 토론하고 문제에 어떤 문제가 있으며 조건을 어떻게 만족해야 하며 Python 이라는 언어적 특성을 살리고 이렇게 구현하면 컴퓨터의 Compute, Memory 를 적게 차지하면서도 많은 일을 하게 할 것인가? 이것을 풀어나가고 최종적인 완성품을 만든것이 모두 다 알고리즘 문제라고 보면 된다.

결국 알고리즘은 모든 것의 기본이라고 봐야 한다. 시스템 운영을 하던 개발을 하던 수많은 문제에 직면하게 되는데, 알고리즘이 없다? 자바스크립트를 배우는데 있어서 복잡 다단한 알고리즘보다는 라이브러리를 아는게 더 중요하다? 그런 다음에 수 많은 문제들을 어떻게 해결할 것인가? 라이브러리를 끼워 넣으면서 해결할 건가? 물론 이진트리, 정렬등을 다 알고 있어야 한다는 건 아니다. 그렇다 라이브러리를 많이 안다고 문제 해결 능력이 저절로 생겨나나?

시스템 운영이라는 직군에서 면접에서도 마찬가지다. 외국의 경우에 어떤 장애 발생시에 어떻게 문제를 해결했는지에서 관심이 있지 몇분만에 그것을 해결했는지에는 아무런 관심도 없다. 문제를 인식하고 니가 그 문제를 바라본 관점이 무엇인지를 설명하라고 하는데, 그 바라본 관점이란게 당연히 컴퓨터 이론을 기반으로 한 것이여야 했다. 그러다보면 당연히 컴퓨터 강의실의 토론처럼 변하는 경우가 많았다.

알고리즘이라는 말 자체가 ‘현실세계에서 발생한 문제를 컴퓨터라는 도구를 이용해서 어떻게 해결할 것인가?’ 라는 것 아닌가?

문제해결은 고사하고 검색하기 바쁨.

내가 왜 이런 글을 장황하게 쓰냐하면 SI 에서 밥벌이를 하다보니 느끼는게 많이 있었기 때문이다. 그중에 하나가 ‘문제 해결능력 없는 인간들이 너무나 많다’ 라는 거다.

내가 알고 있던 한 사람은 개발 경력만 15년정도 였는데, 그가 들고 다닌 컴퓨터에는 그가 그동안 했던 프로젝트의 소스코드들이 들어 있었다. 그는 그것을 자신이 프로젝트를 할때마다 활용한다고 자랑스럽게 이야기를 하곤 했다.

내가 보기에 그것은 자랑거리가 못된다. 그 사람은 구글를 이용한 검색을 하지 않을뿐, 자신이 했던 과거의 코드를 기반으로 모든 프로젝트를 수행하고 있는 것 뿐이다. 과거의 코드가 현 시점의 문제해결에 부합한다면 사용하는데 아무런 문제가 없겠지만 시간을 흐르고 문제해결의 관점도 바뀌는 경우가 많다.  과거의 코드를 재활용할 생각이 였다면 그것을 현시점의 문제해결에 적합한지 정도는 테스트해야 하는게 맞지만 뭐 그렇게 하는 인간을 본적이 없으니… 도대체 자신이 한 프로젝트의 소스 코드를 왜 들고 있는거냐? 그것도 이해 못할 일이다.

뭐가 문제냐? 문제 될 것은 없다. 문제는 이후에 벌어지는데, 적어도 구글이나 github 에서 따온 코드라면 적어도 그것을 이용할때에 테스트라도 한번 했어야 했다. 테스트 하는 인간 못봤다. 그냥 Copy&Paste 지.. ㅋㅋㅋ   그리고 문제 생기면 서버 안좋데.. -_-;;

구글 검색을 활용하는 것에 뭐라하는게 아니다. 활용을 잘 했으면 한다는 거다. 특히나 시스템 운영에서도 구글 검색을 많이 이용하는데, 구글 검색한 내용이 이미 10년전이나 몇년이 지난 내용들을 가져다 실무에 적용하는 인간들 적지 않다.

한국의 SI 산업에 가장 큰 문제는 문제 해결 능력이 없다는데 있다. 문제 해결 능력은 많은 프로젝트를 수행하고 경력이 많다고 쌓이는게 아니다. 문제 해결을 잘할려면 이론도 많이 알아야 하고 문제가 시사하는 관점을 정확하게 파악하고 문제 해결을 위한 기획, 설계를 잘 해야한다. 하지만 SI 산업에 그렇게 일을 하는 인간 없다고 봐야 한다.

이런 측면에서 알고리즘 논쟁은 흥미로운 것이다. 개발자만의 논쟁거리가 못된다. 알고리즘을 그져 트리, 정렬문제로만 축소해보면 답이 없다는 것이다. 그런 관점이 잘 들어난 것이 첫번째 글쓴이의 글로 보인다. 그나마 두번째 글쓴이 정도가 알고리즘의 대한 관점을 잘 제시했다고 본다.

Creative Commons License
최근 알고리즘 논쟁을 보고 느낌점… by Voyager of Linux is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

한국에서 시스템 엔지니어로 산다는거.

한국에서 가장 큰 병폐가 무엇일까? 자주자주 그리고 오랫동안 생각해온 문제였고 사회생활을 비롯한 각종 활동에서도 이러한 물음에 대한 답을 찾기위한 약간의 실험같은 것을 했었다.

이에 대한 물음에 적절한 또 다른 물음은 ‘당신 곁에서 나약해보이고 없어보이는, 능력이던 재력이던간에, 사람이 있을 경우에 어떻게 대할 것인가?’ 라는 것이 있다. 한국에서 ‘없어보인다’ 라는 말은 굉장히 많은 의미를 담아낼 수 있는 말이다. 능력이 없을수도 있고 재력이 없을수도 있고 외모가 없을수도 있고 전체적으로 풍기는 이미지가 못미더울 수도 있는 가져다 붙이면 다 되는 말이라고나 할까.

내 직업은 시스템 엔지니어다. 아니, 정확하게 말하면 시스템 엔지니어도 아니고 그렇다고 개발자도 아니다. 궃이 말하자면 소프트웨어 엔지니어라에 더 근접한다. 그런데도 일단은 서버 시스템을 더 많이 다룬다. 뭔가를 설치하고 설치한 프로그램이 제대로 동작하는지를 모니터링하고 시스템을 튜닝하고 보안 업데이트를 하고 하는 일이 주다.

그런데, 지금 내가 하는 직업이 한국에서는 별로 좋은 직업이 아닌게 분명해지고 있다. 여기서 별로 좋은 직업이 아니다라는 말에 의미는 앞에서 말한 ‘없어보이는 직업’이라는 뜻과 같다.

IT 산업은 거대하다. 그 속에는 각종 직업군들이 존재한다. 프로그래머, 시스템 엔지니어, 네트워크 엔지니어등등 다양하다. 그런데, 시스템 엔지니어를 수년간하면서 느낀점은 제일 없어보이는 직업군이라는 거다.

잘 동작하던 서버 프로그램이 오류를내거나 응답반응을 하지 않을 경우에 제일 먼저 누구를 찾을까? 시스템에는 몇달간 변경사항이 없었지만 서버 프로그램에서 돌리는 소프트웨어에는(예를들면, Python, php, Java등등) 많은 변경이 있었다. 그런데도 문제가 생기면 시스템 엔지니어를 먼저 찾는다. 왜? 프로그래머는 자신이 변경한 코드에 대해서 발생되는 문제에 대해서 1차적 책임을 지지않는가?

시스템 엔지니어는 고달픈 직업이다. 예를들어, LAMP 시스템을 운영한다고 한다면 시스템 엔지니어는 리눅스만 알아서는 안된다. Apache, MySQL, PHP 에 대한 설정과 그러한 설정이 시스템에 어떠한 영향을 미치는지도 함께 알아야 한다. 더 나가서는 PHP, MySQL 개발 경력도 필요로한다.

실제로 시스템 엔지니어를 뽑는다는 구직조건들을보면 다음과 같은 것들을 자주 보게 된다.

SM – Java 개발경력 3년차, Tomcat, Spring, Hibernate 시스템 운영.

시스템엔지니어 – LAMP 시스템. PHP개발자 경험자 우대. L4 스위치 및 네트워크 운영.

그런데도 이러한 사람들의 경력 5년차의 경우에 국내 연봉이 얼마정도 일까? 잘나간다는, 다섯손가락에 꼽는 회사들을 빼고는 거의 대기업 신입초봉과 비슷한 정도다.

더욱 심각한 문제는 사공이 많은 것이다. 시스템을 구축할때에 이래라 저래라하는 인간들이 너무나 많다. IT 산업내 직업군중에서 자신의 소관도 아닌데도 타인에게 감놔라 배추놔라를 직업군이 있다면 그게바로 시스템엔지니어들이다.

이번에 시스템 구축할때 우리도 AWS 로하면 안되요?

AWS 로 하면 AutoScaling, Provisioning 도 되게 준비를 다해줬으면 좋겠습니다. 아, 거기다 자동배포도 되게 해주세요.

시스템엔지니어들이 언제부터가 개발자들을 고객으로 맞이했는지는 모르겠다. 저런걸 구축해주면 AWS 모니터링부터 AutoScaling, Provisioning 등에 유지보수등을 도맞아서 해줄건가? 거기다 안타갑게도 대부분의 국내시스템에서 AutoScaling, Provisioning 을 할만큼 예측불가능한 전체 시스템 스케일을 가진 경우는 거의 없다. 바꿔 말하면 대략적으로 몇대정도 시스템이 필요한지 다 예측가능한 시스템이다.

그런데도 어디서 주워들었는지 트랜드를 쫓아가고 싶어서인지 이것저것 간섭하는 이들이 적지 않다. 그런 간섭은 거의다 개발자들이 였다.

개발자들이 보기에 시스템엔지니어는 없어보이는 직업군이다. 자신들은 개발자들이기에 TCP 서버도 개발해보고 C도 개발해보고 더나가 C로 짜여진 리눅스 시스템을 시스템엔지니어들보다 더 잘 이해한다고 생각하고 그래서 개발하고는 거리가 먼 시스템엔지니어를 한단계 낮게 본다.

그래서 뭔가 시스템엔지니어가 시스템에 뭔가를 바꾼다라고 공지를하면 자신이 개발한 경험 TCP/IP 개발이나 시스템개발을 한 지식을 기반으로 ‘니들이 시스템 내부를 잘 모르나본데, 그거 바꾸는 이유는 알고 하는거냐?’ 식의 핀잔이나 ‘개발자가 갑이지 시스템엔지니어는 무슨… ‘ 식의 면박을 받기 쉽상이다. 개발자들은 그냥 시스템을 다루는 명령어 사전만 모를뿐이고 그러한 명령어 사전은 별 의미가 없다는 인식이 팽배하다.

자, 다시 글의 처음으로 돌아가보자. 한국 사회의 병폐가 무엇이라 보는가? IT산업내에 많은 직업군내에서 존재하는 서열. 개발자 갑, 시스템엔지니어 을, 네트워크 엔지니어 별동대. 이글을 읽는 개발자들은 ‘니만 경험한 세계’, ‘소수일뿐이다’ 따위의 생각은 ‘당신은 경험이 없다’는 걸 반증하는 것밖에 안된다. 자신은 고결한 경력을 쌓아서 주변에 그렇지 않았다가 아니라 그런한 문제를 피했다라는걸 말하는거밖에 안된다. 마치 사회문제에 무감각한것처럼..

한국 사회의 병폐는 ‘없어보이는자’ 위에 올라서서 이래라 저래라하는 사고체계에 있다. 한국인이 이해하려고 하지 않는 단어

Respect

개발자들은 시스템엔지니어를 Respect 합니까? 아니 더나가 각종 타 직업군들에 대해서 Respect 합니까?

Creative Commons License
한국에서 시스템 엔지니어로 산다는거. by Voyager of Linux is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

IT 산업의 이익창출 공식

여러해 동안 회사생활, 특히나 IT회사에 다니면서 느낀것들이 많았다. 그러한 느낌들은 시간이 지나서 되돌아보면 좀 더 선명하게 다가오는 것들이 적지 않은데, IT 산업의 이익창출 공식 또한 그런 종류중에 하나다.

보통 어떻게 회사 성장할까? 가장 중요한 것이 아이디어(Idea)일 것이다. IT회사의 경우 이른바 돈이 되는 아이디어를 생각하고 그것을 구체화시키는 기술을 찾게 된다. 구체화시키는 기술을 만들어내기 위해서 대부분의 초기 창업회사들은 R&D Center 와 같은 조직을 만들고 개발자, 시스템 엔지니어, 기획자등을 채용한다. 그리고 이어지는 월화수목금금금….

IT 기술조직이 월화수목금금금일 지속해야하는 여러가지 이유는 나중에 논의하고, 아이디어와 기술력을 바탕으로 상품을 어떻게 다룰것인가에 대해 생각해보자. 기술직에 있는 IT회사의 경우에는 개발자, 시스템 엔지니어와 같은 사람들은 만들어진 상품들이 어떻게 사람들에게 다루어질 것이지에 대한 생각을 않하는 경우가 많다.

예를들어, 빅 데이터(Big Data) 시스템 및 가상화 시스템(Virtual System)이 트랜드이다 보니 묻지도 따지지도 않고 그것을 해야하는 사람들이 많다. 그들은 그러한 기술적인 구현에만 신경을 쓰다보니 정작 그것을 만들고 난 후에 사람들에게 어떻게 다루어지고 보여지는지에 대해서는 별 관심이 없다. 그들의 관심사는 이력서에 최신기술을 다루었었다는 커리어(Career)를 넣는데 있다. 또, 그들은 최고의 기술이 시장을 이끌수 있다라고 굳게 믿는다.

어쨌든 다시 주제로 돌아와서 돈과 기술력을 가지고 IT 상품을 만들었다면 그것을 어떻게 다룰것인가에 대한 생각을 하게되고 할 수밖에 없다. 회사가 초창기에 성장을 위해서 구체화된 상품을 만들어내는데 전력을 다했다면 더 큰 성장을 위해서 그러한 상품을 어떻게 판매할지에 대해서 고민할 시점이 반드시 온다.

어떻게 사람들을 불러모아서 그들의 호주머니를 털것인가…  이에 대한 느낌은 늘 있어왔지만 지금에야 시간이 가면 갈수록 더 선명해지는 것같다.

다른 산업과는 달리 IT 산업의 두드러지는 특정은 일반론적인 시장경제 이론을 적용할 수 없다는 것이다. 아니 고전적인 시장경제 이론을 확장해 생각해야 한다. 이를 두고 어떤 사람은 시장경제가 아니라 공유경제라는 말을 쓰기도하지만 완전하게 이익을 배제하는 경제이론을 바탕으로 IT산업이 발전한게 아니다보니 공유경제를 적용하기에는 무리가 있다.

대부분의 IT 제품들을 보면 초창기에는 무료로 서비스, 상품들을 제공한다. 그러다고 특정한  기능이 더 필요한 사람들, 추가적인 수요가 필요한 사람들에게 유료화 정책을 쓴다. 이러한 예는 무수히 많다. 애플의 iCloud 시스템은 기본 5GB를 제공하고 더 필요하다면 돈을 내야한다. 세계적인 언론사들은 , 뉴욕타임즈나 이코노미스트, 기사를 무료로 제공하지만 특정 기사와 관련된 심도있는 분석을 보기위해서는 돈을 내야한다.

이는 과거의 전통적인 시장경제 논리에 맞춰진 ‘데모(Demo)’ 상품과 차별되는 특징이다. 데모 상품의 경우에는 짧막하게 상품을 경험해보는데 그치지만 지금의 IT상품들은 무료화 전략을 앞세워 유료화상품 사용으로 유도하는 일종의 마케팅 전략으로 변모한 것이다.

무료화를 앞세워 유료화상품 사용으로 유도하도록 하는 이러한 기법이 하필 많고 많은 산업중에서 IT산업에 집중되는 이유는 무엇일까.

IT산업은 생활의 일부가 되고 있다. 수많은 IT기기들을 사람들은 매일, 매시간, 매분 다룬다. 그 기기에서 동작하는 또 수많은 소프트웨어들은 어떻고. 수많은 IT상품들이 사람들의 생활 깊숙히 들어와있고 그러한 것들이 사람들을 지배하는 특성을 가지고 있다. 그것이 없으면 사람들이 생활에 불편을 끼칠 만큼 심리적으로 사람에게 차지하는 비중은 대단하다.

이러한 것을 보면 어떤 IT상품을 만드는 것이 성공하는 것인지를 알수 있다. 사람들에게 필수적인 상품이 되도록 만들면 된다. 그리고 무료로 일정부분을 풀고 더 많은 기능과 정보를 제공하는 것에는 유료화정책을 세운다. 이미 자신의 삶의 깊숙히 파고든 그러한 IT상품을 버릴수는 없기 때문에 유료화를 사용할 수밖에 없게된다.

무료로 사람들을 물러모아 유료로 자신들의 상품을 쓸 수밖에 만드는 전략이 IT산업의 기본이 되가고 있다. 이러한 것을 모른채 처음부터 마진으로 이익을 추구하도록 전략을 짠다면 얼마 못가 이익이 정체되는 현상을 겪게 된다. 초창기에 경쟁자가 없기에 독과점적인 시장지배력으로 이익이 창출되지만 얼마 못가 같은 컨셉의 상품을 판매하는 경쟁자가 나오면 이익이 반토막 나거나 뺏길 수도 있다.

이러한 상황을 가장 잘 보여주는 시장이 O2O 시장이다. 초창기 독과점적 지위에 있을때에 전략은 중간 마진을 챙기는데 있었다. 하지만 지금 경쟁이 치열해지다보니 파이는 점점 줄어들고 있는 실정있는 상태로 O2O 시장에 뛰어든 업체들은 상당한 어려움을 겪고 있다.

전통적인 시장경제 논리를 이용해 이익을 창출하겠다고 한것부터가 문제다. 중간 거래 마진을 챙기는 것은 부동산 중계업과 완전히 똑같다. 애시당초에 고객을 확보를 위해서라도 무료화정책을 채택하고 유료화 정책을 내놓는게 시장을 장악하는 좋은 방법이였다.

유료화정책에는 그들에게 도움이 될만한 고급 정보를 제공하는 형식이 좋은 방법이 될 수 있다. 어짜피 전부다 사업자들이다보니 시장분석 자료, 고객의 트랜드 변동추이등을 사업자들에게 제공하고 돈을 받는 것이다.

이는 결국 O2O 시장에서의 성공은 사업자들을 자신들의 사업파트너로 만들고 그들에게 분석된 데이터를 제공하는 전략이 주요할 수도 있다. 다시말해 O2O 사업체는 빅 데이터 시스템을 기본으로 갖추고 정보를 판매하는 회사로의 변화를 모색하는게 나을 수 있다는 거다.

무료화 정책은 고객을 확보하는 정책이고 그러한 것을 통해서 고객을 붙잡아두게된다. 그 붙잡아두는 시간에 고객의 생활에 밀착하게 되면 유료화를 하더라도 성공을 보장받을 수 있다. O2O 시장의 경우에 무료화로 사업자들을 끌어모으고 그들에게 유료로 그들 사업에 필요한 고급정보를 파는 것도 훌륭한 수익모델이 될 수 있다.

Creative Commons License
IT 산업의 이익창출 공식 by Voyager of Linux is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

차량 정비 할 것들

  1. 연료필터 카트리지 – 점검해서 교체해야겠다면 해주시면 됨. 아무 유상이라고 들었는데, 돈 낼 의향있음.
  2. 브레이크패드 점검, 브레이크액 점검 – 점검 바랍니다. 급정거할때 조금 밀리는듯 하기도 하던데, 부품교체 않하고도 뭘 조정하면 되는건지… 마스터 실린더 압력 세나?
  3. 트렁크 쇼바 – 잘 안올라감. 다른 분과 비교해봐도 문제 있음
  4. 트렁크 재진패드 – 이건 전에 이슈가 되었는데 정비받지 않았음.
  5. 엔진떨림(엔진미미) – 거기다 엔진미미 개선품 나온거 알고 있음. 그리고 문제가 있는게 정차, 저속과 약간 오르막에서 떨림 많음 있음. 저속에서 차량 긁는 소리도 간혹 들림.
  6. 토션빔 점검(타이어 편마모) – 타이어 한쪽만 마모됨..
  7. 흡기호스 브라켓과 간섭여부 확인 – 이거는 뚜껑 열어서 설명 필요..
  8. 제너레이터 – 이건 덤으로 점검바람.
  9. 와이퍼 앞부분 엔진으로 들어가는 곳 플라스틱 엔진으로 물들어가는거 개선한 개선품 나온거 알고 있음 교체바람.
Creative Commons License
차량 정비 내역 by Voyager of Linux is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.