왜 소프트웨어인건가?

소프트웨어의 중요성

우리나라에 소프트웨어 산업은 어떤 의미일까요?

"왜 소프트웨어가 세상을 먹어 치우나?" 라는 글에도 나오지만 소프트웨어 산업은 전 세계적으로 정말 중요한 산업이 되었습니다.

게다가 더 중요한 점은 이것이 이제 겨우 시작이라는 것입니다. 구글의 CEO 래리 페이지는 "우리가 할 수 있는 것의 단지 1% 만을 이루었을 뿐이다. (We’ve only hit about 1 percent of what we’re capable of producing.)" 라고 했죠.

예를 들어 무인 자동차가 세상에 나온다면 어떻게 될까요? 그럼 더 이상 차를 소유할 필요가 없고, 필요할 때만 휴대폰으로 불러서 탈 수 있습니다. 주차 또한 필요 없이 내리면 차가 알아서 한적한 곳에 알아서 가서 주차를 합니다. 따라서 현재 도심에 있는 수많은 주차장들이 필요가 없어지게 됩니다 (Leave the Driving to the Car, and Reap Benefits in Safety and Mobility). 자동차 산업 뿐만 아니라 사회전체에 엄청난 변화가 일어날 것입니다.

무인 자동차 기술은 현재 어느 정도 수준일까요? 구글 무인 자동차의 경우, 2011년에 이미 30만 킬로미터를 무사고로 주행을 했다고 합니다.

무인 자동차와 소프트웨어가 무슨 관계일까요? 무인 자동차에를 만드는 데는 기계 공학, 전자 공학 등도 중요한 부분입니다. 하지만 가장 중요한 부분을 꼽으라면 컴퓨터 비젼 (Computer vision), 인공 지능 (Artificial Intelligence) 등 소프트웨어 기술입니다. 그것이 이 분야에 종사하는 엔지니어 중 소프트웨어 엔지니어가 가장 많은 이유이고, 구글이 이 분야에서 가장 앞서 나가는 이유이기도 합니다.

소프트웨어가 바꾸어 갈 세상에는 무인 자동차를 타고 배달해 주는 로봇, 가사 도우미 로봇 등도 포함됩니다. 시리(Siri)나 구글 보이스 같은 음성 인식, 인공 지능 기능은 이제 시작에 불과 합니다. 그리고, 생명 과학, 뇌과학 등에서도 기계 학습 (machine learning), 인공 지능 (Artificial Intelligence) 등을 통해서 거대한 혁신이 일어 나고 있습니다.

앞으로 소프트웨어 산업의 발전 없이는 선진국으로 진입하는 것이 상당히 어려울 것입니다.

한국의 소프트웨어 기술 수준

그럼 우리나라의 소프트웨어 기술 수준은 어느 정도 일까요?

가장 앞서 있는 미국에 비해 한참 떨어져 있고, 유럽 국가에 비해서도 떨어집니다. 그리고 인도에 비해서 떨어지고, 중국에 비해서도 떨어집니다. 일본에 비해서도 떨어지는 것 같습니다. 결국 우리가 앞서는 나라는 동남아, 아프리카, 중남미 국가 정도 인 것 같습니다.

그럼 이 정도 수준이라면 포기해야하는 걸까요? (그런데 포기 하기에는 앞서 얘기한 대로 너무나 중요한 분야 입니다.)

가능성

현실은 이렇지만 어떤 면에서 우리나라 만큼 소프트웨어를 잘 할 수 있는 환경을 갖춘 나라도 별로 없습니다.

첫째, 소프트웨어 산업에서 가장 중요한 교육열이 거의 세계 제일입니다.

둘쨰, 소프트웨어 산업에서 중요한 학생들의 수학 실력이 세계에서 상위 몇 번째 입니다.

셋째, 국민들의 근면 성실함, 하고자 하는 의욕이 거의 세계 제일입니다.

넷째, 우리나라 소프트웨어 엔지니어들 만큼 일을 열심히 일하는 전 세계에 없습니다.

문제점

이렇게 소프트웨어를 잘 할 수 있는 많은 요소들을 갖추었는데, 왜 잘 하지 못하는 것일까요? 잘 하지 못하는 이유도 무척이나 많습니다만 제도적인 문제가 큰 부분을 차지하고 있습니다. 예를 들어 공인 인증서, 엑티브 엑스 문제만 해도 소프트웨어 산업 발전에 큰 걸림돌이 되어 왔습니다. 그래서 수 많은 소프트웨어 관련 종사자들이 몇 년째 고치자고 얘기를 해 왔습니다. 아마 소프트웨어 관련 업계 종사자들을 대상으로 설문 조사를 하면 없애자는 쪽이 80~90%는 나오지 않을까 싶습니다. 그런데도 아직도 고쳐지고 있지 않습니다. 이거 하나 고치는게 왜 이렇게 어려울까요?

저는 박정회 정권에 많은 문제가 있다고 생각하지만, 적어도 산업을 발전시키기 위해서는 뭐든 한다는 정권과 공무원들의 집중력에는 많은 점수를 주고 싶습니다. 현재의 공무원, 정치인, 그리고 언론인, 소프트웨어 관련 기업인들께서도 소프트웨어 산업의 중요성을 공감하고, 소프트웨어 산업이 일어설 수 있도록, 그래서 우리나라가 선진국으로 진입할 수 있는 초석이 될 수 있도록, 제도적인 문제들을 해결해 주시길 간절히 바랍니다.


※ 다른 문제점들과 해결 방안에 대해서는 "실리콘 밸리를 망하게 하는 방법" 같은 제 다른 글들을 참고해 주세요.

코드 리뷰는 어떻게 하나요?

후배가 구글에서는 코드 리뷰를 어떻게 하면 좋을지를 물어보는 이메일을 보내 왔습니다. 저도 평소에 꼭 공유하고 싶었던 주제여서 여기에 답글을 남깁니다.

질문은 구글에서 어떻게 하느냐인데, 답글은 구글에 국한된 부분은 아니고 실리콘 밸리 회사들이 주로 어떻게 하는지 설명 드리겠습니다.

--------

선배님께 이렇게 메일을 보내는 이유는 한 가지 여쭤볼게 있어서 입니다.
요즘 회사일을 하든, 친구들과 서비슬 개발을 준비하든, 학교와는 달리 다른사람과 협업해서 코드를 짜야하는 경험을 하고 있습니다.
그래서 동료들 간에 코딩 컨벤션을 정하거나, 코드 리뷰를 할 필요성을 느끼게 되었고, 최고의 팀웍을 위해서 잘하고 싶은데 말처럼 쉽지가 않습니다. 예를 들면 리뷰어가 리뷰를 할 때 리뷰를 받는 사람은 왜 그게 더 좋은지 인지를 못하거나 혹은 쌍방 감정싸움으로 이어지지 않게 하려다 보니 대충대충 넘어간다거나 하더라구요...ㅠㅠ


그래서 질문은 다음과 같습니다.


1. 구글에서는 내부 구성원 사이에 코딩컨벤션을 어떻게 전달하고 공유하나요?
(위키 정리, 내부 스터디, 토론형 학습...등)

구글 코딩 컨벤션은 Java를 제외한 왠만한 언어는 아래 사이트에 공개 되어 었습니다.

https://code.google.com/p/google-styleguide/

그냥 그대로 쓰거나, 필요에 맞게 조금 고쳐 쓰면 될 것 같습니다.

(한가지 특이한 부분은 대부분의 회사들은 4 space indentation을 쓰는데 구글을 2 space indentation을 씁니다. 장단점이 있구요. 개인적으로는 python같이 ending brace가 없는 언어에서 depth가 깊고 block이 길 경우 좀 불편한 것 같습니다.)

2. 코드 리뷰 전체 프로세스가 어떤식으로 진행되나요?
(리뷰신청 -> 주로 언제까지 리뷰 완료 등등, 따로 리뷰 시간을 가지는 지 등)

CL (Change List)이 준비되면 "p4 mail"이나 gerrit 같은 코드 리뷰 시스템으로 리뷰를 신청합니다. 그러면 reviewer에게 이메일로 notification이 가게 되고, reviewer가 리뷰 시스템에 들어 가서 review comment를 작성하게 됩니다.  1차 review를 완료하면 이 사실에 CL 작성자에게 이메일로 notification이 가게 되죠. 이런 식으로 왔다 같다 하면서 CL이 submit 할 수준이 되면 reviewer가 approve를 하고, 그러면 작성자가 submit을 합니다.

가끔 의견차이가 잘 좁혀 지지 않을 때나, 상대방의 말이 잘 이해가 안 될 때 만나서 얘기 하는 경우도 종종 있습니다. 글로 잘 대화가 안 되는 경우, 말로 하는 것이 훨씬 효율적이고 빠릅니다. 작성자이던 reviewer이던, 조금 이라도 막힌다는 느낌이 있으면 찾아 가서 직접 얘기하세요. 그게 훨씬 효율적입니다. 단 이 경우에도 반드시 리뷰 시스템에 "만나서 이렇게 합의를 봤고, 결론에 도달한 이유"를 간단히 적어 놓아야 합니다. 그래야 차후에 그 CL을 참조하는 사람이 왜 그렇게 했는지를 알 수 있으니까요.

구체적인 안건에 대한 의견 조율을 위해 offline으로 얘기하는 경우는 많지만, 따로 같이 리뷰 시간을 가지지는 않는 것 같습니다.

리뷰어는 가급적이면 CL을 받으면 최대한 자기일 보다는 리뷰를 먼저 해 주는 것이 좋습니다. CL 작성자의 입장에서는 리뷰를 얼마나 빨리 받는지에 따라 업무 효율이 많이 좌우 되니까요. 이건 CL을 처음으로 받았을 때도 그렇고 업데이트된 CL (보내준 review에 따라 수정한)을 받았을 때도 마찬가지 입니다.

보통 일반적인 규칙은 (처음이든 update한 버젼이든 상관 없이) CL을 받으면 24시간안에는 리뷰를 보내준다 입니다. 하지만 이건 hard deadline에 가깝고, 대개는 그날 받은 CL은 그날 리뷰해 주는 것이 좋습니다. (오후 늦게 받은 건 그 다음날 오전에 리뷰 해 줘도 괜찮습니다.)

reviewer가 어뗜 이유로 - 아주 급한 일이 있다던지, CL이 너무 크고 이해하기 어렵다든지 해서 - 24시간안에 리뷰를 못 보내줄 것 같으면, 이메일이나 offline으로 그 사정을 CL작성자에게 얘기를 미리 해 주는 것이 좋습니다. 예를 들어 "이런 저런 사정으로 x일까지 리뷰 해 줄 수 있는데 괜찮겠냐?"고.

반대로 CL작성자가 리뷰를 받고 언제까지 수정 버젼을 보내줄 것인지에 대한 규칙은 없습니다. 이게 늦어지면 대체로 CL 작성자가 손해를 보는 쪽이니까요. 그래도 아주 극단적으로 늦어지는 경우 (1~2주?) reviewer가 문맥(context)를 잊어 버리니까, "늦게 보내서 미안하다" 정도는 적어 주는 것이 좋습니다.

3. 코드 리뷰는 어느 정도까지 하나요?
(테스트 코드 여부, 로직 검토, 변수 네이밍, 공백 등등)

이 질문에 대한 답은 상황에 따라 많이 다릅니다. 예를 들어 이미 대규모로 서비스 되고 있거나 곧 서비스 될 경우, 또는 큰 과제여서 많은 사람들이 공동 작업하는 코드, 중요한 과제여서 코드가 향후 오랫동안 사용될 경우 등에는 code quality가 아주 중요합니다. 따라서 리뷰도 더 깐깐하게 해야 합니다. 또한 주요 로직에 대해서는 unit test가 다 있어야겠죠. 때문에 "이런 저런 테스트를 추가해 주세요"는 상당히 당연한 리뷰 comment 입니다.

반면, 실험적인 코드, 1~2명이 작업하는 코드, 향후 버려질 가능성이 높은 코드는 code quality 보다는 속도가 더 중요할 수 있습니다. 이 경우 리뷰를 너무 깐깐하게 하면 얻는 것보다 비용이 더 많이 들 수도 있습니다. 때문에 약간 리뷰를 느슨하게 하는 것도 괜찮습니다. 극단적인 경우 - 완전히 실험적인 코드 - 는 아예 리뷰를 안하는 경우도 있습니다. 단 이 경우는 repository 나 디렉토리를 완전히 분리하고, 거기에는 리뷰 안 한 코드가 들어있다는 것을 사전에 팀 전체가 공유 해야 합니다. (이런 코드는 리뷰를 하는 코드가 들어 있는 디렉토리에서 불러 써도 안되죠.)

위의 두 가지 경우의 리뷰 모두,  스타일 가이드는 기본적으로 따라야 합니다.  일단 lint 같은 툴로 대부분의 문제는 다 걸러 내고, lint로 안 잡히는 문제는 reviewer가 comment를 줍니다. 단 이 경우 너무 style guide를 바이블처럼 따를 필요도 없고, 그래서도 안됩니다. style guide를 100% 지킬려고 하다 보면 너무 많은 에너지가 들 수 있거든요. 하지만 reviewer는 style guide에 안 맞는 것이 보이면 comment를 달아 주는 것이 맞고, 작성자도 그런 comment는 다 따라 주는 것이 좋습니다. 왜냐 하면 보통 style guide 관련 comment들은 고치는데 별로 시간이 많이 안 걸리니까요.

불필요한 공백(extra whitespace)은 다 없애는게 맞습니다. 안 그러면 나중에 리뷰 시스템에서 diff로 볼 때 바뀌지 않은 라인이 바뀐걸로 나오니까요. editor에서 "저장할 때 extra whitespace 없애는" 옵션을 항상 켜두면 편합니다.

comment를 달 때, 반복적인 문제들에 대해 다 comment를 달 필요는 없고, "이 라인에 이런 문제가 있고 다른 곳에도 반복되니까 모두 고치세요" 라고 하면 됩니다.

변수, 함수 이름은 코드를 이해하는데 중요하죠. 따라서 "지금 이름보다 이 이름이 더 명확할 것 같은데 어떠세요?"라고 충분히 얘기할 수 있습니다. 하지만 현재의 이름도 꽤 괜찮다면 너무 완벽하게 하기 위해서 고쳐 주세요 할 필요는 없습니다. 반면 외부에 공개 되는 API라던지, 외부에 공개 되지는 않지만 내부적으로 아주 많이 쓰일 것 같은 API는 조금이라도 더 좋아질 여지가 있으면 고치는 게 낫습니다.

review를 할 때, 중요한 것 중 하나는 CL의 전체적인 디자인이 괜찮은지를 보는 것입니다. 더 단순한 디자인은 없는지, 이해하기 쉬한 구조인지, 확장성, 유연성은 좋은지, 테스트는 쉬운지 등을 잘 보셔야 합니다. 특히 테스트가 쉬운 구조인지 (Testability)는 특히 중요한 항목입니다. 설령 당장 unit test가 없더라도 중요합니다. 나중에 테스트를 추가할려고 할 때 쉽게 할 수 있어야 하니까요. 그리고 일반적으로 Testability 가 안 좋은 코드는 다른 문제도 많이 가지고 있으니까요.

4. 코드 리뷰를 할 때 어떤 식으로 코멘트를 달아주나요?
("이건 이 방식으로 하시오", "이 라이브러리를 쓰시오", "이 이름이 더 좋아" 등등)

말씀 하신 것과 내용은 동일한데 훨씬 부드럽게 쓰는 경우가 많은 것 같습니다. 예를 들어, 영어로 "Could you ...", "How about ...", "Please ... "이런 표현도 많이 씁니다.

스타일 가이드에 안 맞거나, 더 좋은 라이브러리, 디자인을 제안하는 경우에는 관련 설명이 되어 있는 문서의 링크를 넣어서 왜 그렇게 생각하는 지를 알려주는 것도 좋습니다. (작성자도 알 것 같은 것은 굳이 이렇게 안 해도 됩니다.)

5. 코드 리뷰에 대한 사람들의 인식, 태도, 문화가 어떻나요?
(서로 배운다는 인식을 가진다, 선배 뜻을 따른다... 등)

실제로 코드 리뷰를 통해서 가장 많이 배웁니다. 코드 리뷰를 통해서 나보다 더 나은 엔지니어로 부터 구체적인 코드에 대해서 더 나은 디자인이 어떤 것이고, 또 더 나은 코드는 어떤 것인지 바로 바로 배울 수 있으니까요.

그리고 코드 리뷰를 통해서 code quality가 유지 되어야 내가 쉽게 그 코드 기반에서 작업할 수 있으니까요.

6. 기타 코드 리뷰와 관련해서 노하우 같은 게 있으신가요?

• 주위에 나 보다 뛰어난 엔지니어가 있으면, 그 분들한테 리뷰를 많이 받으세요. 그러면 실력이 일취월장하게 됩니다.

• 나와 비슷하거나 나보다 좀 못하는 엔지니어에게 코드 리뷰를 받더라도 보는 관점이 다르기 때문에 항상 배우는 점이 있습니다. 그런 열린 마음이 중요합니다.

• 리뷰시에는 나만의 스타일을 고집하면 안 됩니다. 스타일 가이드에 있는 것은 잘 따라야지만, 그 이외의 부분에 대해서는 사람마다 다 스타일이 다르기 때문에 스타일에 관한 comment는 하시면 안 됩니다. 내가 할려는 comment가 code quality를 향상 시키려는 것인지, 스타일 문제인지를 잘 생각해 보세요.

• CL 작성자가 고집이 세서, 분명히 타당한 comment인데도 받아들이지 않는다면, 한두번 얘기해 보고 안 되면 포기 하세요. code quality는 떨어지겠지만, 그게 팀원들끼리 감정 상하는 것보다는 훨씬 낮습니다. 그리고 이런 일이 특정 작성자와 반복되면 직접 만나서 허쉼탄회하게 얘기를 해 보는 것도 괜찮습니다. 단 감정이 상하지 않게 잘 해야 합니다. 그리고 너무 기대를 마세요. 사람은 안 바뀌니까요.

• 같은 말도 "아" 다르고 "어" 다르듯이, 상호 코멘트를 달 때 예의를 갖추고 해야 합니다. 그리고 상대가 잘한 부분에 대해서는 칭찬하는  comment를 많이 달아 주세요. 예를 들어 "이 CL 정말 대단한데요.", "이 CL 정말 있었으면 좋겠다고 항상 생각해 왔는데 이거 만들어 주셔서 정말 감사합니다.", "이 디자인은 ....해서 정말 훌륭하군요.", "이 테스트는 정말 coverage가 대단 하네요.", "제안해 주신 디자인은 .. 해서 훨씬 낫군요" 등등.

• 역지사지 - 작성자편: reviewer가 쉽고 빨리 리뷰 할 수 있는 CL을 만들도록 노력하세요. 내 시간이 중요한 만큼 reviewer의 시간도 중요합니다. 한가지 방법은 CL을 가능한 작게 만들는 것입니다. CL 하나에는 하나의 기능만 담으세요. 그래야 리뷰가 쉽고 빨리 리뷰를 할 수 있습니다. 이렇게 하면 나중에 코드 history를 살펴볼때도 편하고 여러 가지로 좋습니다. 또 한 가지 방법은 CL 보내기 전에 자신이 리뷰어가 됐다고 생각하고 리뷰 시스템에서 한 번 훑터보고 보내는 것입니다. 자신의 에디터에서 볼 때 못 보았던 문제를 많이 발견하게 될 겁니다. 반면 가장 안 좋은 자세는 대강 CL을 만들어서 리뷰 보내고, reviewer가 comment를 보내면 그걸 고치면서 CL을 완성하겠다는 자세입니다. 내 시간이 중요한 만큼 reviewer의 시간도 중요합니다. 최대한 완성된 CL을 보내세요.

• 역지사지 - reviewer편: 리뷰시 해서 안되는 것 중에 하나는 CL의 범위가 아닌것을 이것 저것 고치라고 하는 겁니다. 예를 들어 현재 리뷰하는 CL 이전부터 기존에 갖고 있는 코드의 문제를 이번 CL에서 고치라고 하는 겁니다. 또 다른 해서는 안되는 것은 너무 무리한 것을 강요하는 것입니다. 예를 들어, "현재 CL에서 빠진 unit test가 있는데, 이걸 추가를 하면 좋지만 추가 하는데 너무 노력이 많이 든다"면, 일단 현재 CL에서는 TODO로 남기고 그 다음 CL에서 하는 것도 방법입니다. 작성자가 이렇게 하자고 하는데도, "unit test 추가 안 하면 approve 안 해 주겠다" 이런 것은 좋은 태도가 아닙니다. 반면, 비용이 많이 들지만 code quality가 중요한 과제이고, 제안하는 테스트가 중요한 것이라면, 이번 CL에서 하는 것이 맞는 경우도 분명 있습니다. 

• 인간 관계에서도 첫인상이 중요하듯이 코드 리뷰 역시 첫인상이 중요합니다. 자신의 코드를 처음 리뷰하는 reviewer에게 CL을 보낼 경우 조금 더 신경을 쓰세요. 처음 보내는 CL quality가 낮아서 여러 가지 지적을 받게 되면, 그 reviewer가 작성자에 대해 잘못된 선입관을 가질 수 있고, 이후의 CL들에 대해서도 불필요하게 더 깐깐하게 리뷰할 수도 있습니다.

• 아직 제품이 시장에서 검증이 안 된 스타트업의 경우, 전략적으로 상당한 기술적 빚 (technical debt)를 안고 가는 것도 괜찮은 방법입니다. 이 경우 code quality는 어느 정도 포기하고, 코드 리뷰에 들어가는 노력을 작게 가져 갑니다. (린스타트업이란 책을 참고 바랍니다.)

길게 글을 썼는데 적다 보니, 코드 리뷰를 배우는 가장 좋은 방법은, 리뷰를 잘 하는 사람에게 리뷰를 받는 것이라는 생각이 계속 드네요. 주변에 리뷰를 잘 하는 분이 있으면 그 분에게 리뷰를 받으면서 디자인, 코딩 실력도 키우시고, 동시게 리뷰 실력도 키우시기 바랍니다.

학생이라면 방학 때 실리콘 밸리 회사에서 인턴을 하는 것도, 코드 리뷰를 배우는 좋은 방법입니다 (그 밖에도 많은 것들을 배울 수 있지요). 구글 같은 큰 회사는 비행기표, 숙박 제공하고 월급도 상당히 높답니다. 우리 나라 회사라도 코드 리뷰를 제대로 하는 회사나 팀에서 인턴을 하는 것도 괜찮습니다. 코드 리뷰를 제대로 한다면 전반적으로 꽤 괜찮은 기술력을 가지고 있을 거라서 다른 것도 많이 배울 수 있구요.

실리콘 밸리가 한국에 있었다면?

부제: 잃어버린 한국의 실리콘 밸리를 찾아서

역사에 가정은 없다지만, 재미(?) 삼아 실리콘 밸리가 한국에 있었다면 어떻게 됐을까 생각해 봅시다. 이를 통해서 야사에서 흘러다니는 한국에 사실 실리콘 밸리가 있있는데 망했다는 설 (네 맞습니다. 제가 만든 설입니다 ㅎㅎ) 에 대해 조망해 봅니다.

자 그럼, 한국에 실리콘 밸리가 있었다면, 애플, 구글, 아마존 같은 새로운 대기업들이 많이 생겨서 한국 경제가 많이 발전 했을까요?

다음은 제가 생각하는 시나리오 입니다. (이하 편의상 높임말 생략)

1. 애플 (Apple)

다들 아시다시피 원래 역사는 거의 망해 가던 애플을 우리의 영웅 스티브 잡스가 1996년 복귀해서 내 놓은 iMac이 대 히트를 치면서 기사 회생하게 된다. 이후, 아이튠스 (iTunes), 아이팟 (iPod), 아이폰(iPhone), 아이패드(iPad) 등이 대성공을 하면서 제국을 이룬다.

만약 애플이 한국에 있었다면 iMac을 포함한 매킨토시 컴퓨터들이 엑티브 엑스 (Active X), 공인 인증서를 지원하지 않기 때문에 iMac이 아주 미미한 판매량에 그치고, 그 시점에 그냥 망함. 누가 은행, 신용 카드도 못 쓰고, 전자 상거래도 안되고, 정부 사이트에서 등본 같은 것도 발급 받지 못하는 컴퓨터를 사겠는가? 그리고 그 밖의 사이트들도 사파리 브라우저로 보면 다 깨져서 보이는데 말이다. (현재 한국에서 맥 시장 점유율을 보면 쉽게 알 수 있습니다.)

천하의 애플이 망해가는 걸 정부가 보고 있을까 생각할 수도 있고, 천하의 스티브 잡스가 정부를 잘 설득할 수 있지 않았을까 생각할 수도 있지만, 애플이 그 당시에는 이미 거의 망해가고 있던 별 볼일 없는 회사여서 정부에서 방향을 안 틀었을 가능성은 거의 없음.

결론: iMac 나오고 망함. 아이폰 따위 역사에 없음.

2. 아마존 (Amazon.com)

아마존의 주요 성공 요인 중 하나는 원 클릭 (One Click) 서비스 (아마존에서 특허를 가지고 있음)라는 말 그대로 한 번의 클릭으로 구매, 취소, 변경등의 모든 온라인 상거래를 아주 편리하게 할 수 있는 서비스이다. 이렇게 너무나 간단한 서비스 때문에 컴퓨터를 잘 못 다루는 저학력 계층, 할머니, 할아버지들까지 포함해서 많은 사람들이 아마존을 통해 온라인으로 물건을 산다. 또한 사용 자체가 워낙 쉬워서 몇 천원짜리 싼 물건들도 아마존을 통해서 많이 팔림.

아마존이 한국에 있었다면,  각종 엑티브 엑스 깔기 신공에 지쳐 온라인으로 물건 사기를 포기하는 사람들 많이 생김. 게다가 한국에서는 카드 정보를 온라인 사이트가 저장하고 있는 것이 불법이어서 원 클릭 서비스 따위 당연히 안 됨. 매번 물건 살 때마다 카드 정보 입력 해야 함. 귀찮아서 물건 구매량이 줄고, 또한 싼 물건들은 귀찮아서 더더욱 많이 안 팔림.

결론: 성공 했겠지만 지금처럼 아주 크게 성공하지는 못함 (현재 한국의 전자 상거래 활성화 정도를 보면 알 수 있음)

3. 페이팔 (PayPal)

제
페이팔의 가장 큰 성공 요인 역시 손 쉬운 결제에 있다 (아이디, 비밀 번호 넣으면 끝. 엑티브 엑스, 공인 인증서 같은 것 전혀 필요 없슴.)

페이팔이 한국에 있었으면 쉬운 결제 따위 불가능하기 때문에 그리 크게 성장하지 못함 (미국과 한국의 전자 상거래 활성과 정도를 보면 알 수 있다).

게다가 금융 회사가 아닌데 결제 업무를 처리할 수 있게 허가가 날지도 의문임.

어쨌던, 원래 역사는 페이팔 마피아라고 불리는 페이팔로 엄청난 부를 거머쥔 페이팔 멤버들이 좋은 스타트업에 투자를 함으로서 많은 스타트업들이 실리콘밸리에서 성공을 하게 됨.

페이팔이 한국에 있었으면 별로 성공을 하지 못했을 거라서, 페이팔 마피아에 의해 생겨난 수 많은 회사들 (페이스북, 링크드인, 테슬라, 옐프 등)도 없었을 가능성이 높음.

결론: 성공 했겠지만 지금처럼 아주 크게 성공하지는 못함. 페이팔 마피아 들이 세운 수 많은 회사들은 없을 가능성 높음.

4. 스퀘어 (Square)제

스마트폰으로 신용 카드를 쉽게 결제할 수 있는 조그만 장치로 대히트.

한국에 있었으면 공인 인증서 등의 이유로 쉽게 결제가 안 됨 (사용자가 꼼수로 스마트폰에 공인 인증서를 깔아야 함. 더군다나 아이폰에서는 꼼수도 어려움.)

결론: 별로 성공 못 했거나, 망했을 가능성 많음.

5. 민트닷컴 (Mint.com)

본인의 각종 은행, 신용 카드사 등 정보를 한 사이트에서 모아서 관리할 수 있는 사이트. 편리함 때문에 미국에서 대 히트.

공인 인증서 때문에 당연히 안 됨. 또한 한국에서는 은행 정보를 한 곳에 모으는 자체가 불법임. 실제로 10년도 전에 한국에 모네타라는 거의 같은 서비스가 있었는데, 법이 허용하지 않아 문 닫음.

결론: 한국에서는 만들 수 없는 회사

6. 포스퀘어 (Foursquare)

친구들과 자신의 위치를 공유하는 서비스로 미국에서 대히트.

한국에서는 프라이버시 때문에 이런 위치 정보 서비스는 허가 받는 것이 거의 불가능 하다고 함.

결론: 한국에서는 만들 수 없는 회사

7. IBM

90년대 메인프레임 시대에서 PC 시대로 넘어가면서 메인프레임에 집중하던 회사가 어려운 상황까지 갔다가, 서비스, 솔루션 제공 업체로 변신에 성공하여 지금은 아주 잘 나감.

한국에 있었다면 개발한 서비스들이 공인 인증서, 엑티브 엑스에 맞추어서 개발될 수 밖에 없었음. 따라서 솔루션을 해외 시장에 수출하는데 큰 애로 사항이 따름.

결론: 한국 내수 시장 장악 하는 걸로 그치는, 한국에서 잘 나가는 SDS 규모 정도 되었을 것임 (세계적인 회사 안 됨).

7. 구글

1에서 애플이 아이폰을 만들기 한참전에 망했기 때문에, 안드로이드폰이 안 나오거나 지금 같이 크게 성공 못 했을 가능성 높음.

그리고 요즘 잘 나가는 크롬 브라우저는 엑티브 엑스가 안 되서 한국 시장에서 망함.  (브라우저는 국가간 시장 장벽이 낮으므로) 외국에서는 여전히 지금처럼 히트 했을 가능성은 높다고 생각할 수 있으나, 한국 정부 였다면 마이크로 소프트의 인터넷 익스플로어 (Internet Explorer) 끼워 팔기 제제를 안 했을 거라서 모질라 브라우저나 크롬 브라우저를 위한 시장 자체가 없음.

요즘 아마존에서 가장 잘 팔리는 노트북이 크롬북 (Chromebook)이라고 크롬 브라우저만 되는 노트북인데, 한국 시장에서는 엑티브 엑스 안되서 바로 망함. 크롬 브라우저가 성공 못 했기 때문에 이것도 망함.

결론: 요즘 잘 나가는 안드로이드, 크롬, 크롬북들 크게 성공 못 함.

요약

위에서 살펴본 대로 실리콘 밸리에서 잘 나가는 많은 회사들이, 한국에 있었다면 망했거나 지금 보다는 적게 성공했을 가능성이 다분하다.

바꾸어 말하면 한국의 제도들이 실리콘 밸리와 비슷했다면 지금쯤 정말 잘 나가는 회사들이 꽤 있었을 가능성도 있다는 얘기다. 예를 들어, 90년대만 해도, 전자 상거래, 은행 전산화, 정부 사이트 구축 등 한국이 전세계 어디 보다 빨랐던 부분이 상당히 많다. 만약 우리가 구축한 시스템들이 세계적으로 통용되는 방식으로 개발 되었다면, 세계 시장으로 훨씬 쉽게 나갈 수 있지 않았을까?

예를 들어 은행 전산 시스템이나 정부 사이트들이 공인 인증서, 엑티브 엑스를 사용하지 않는 방식으로 개발 되었다면, 이런 시스템들이 세계에서 가장 빨리 개발 되었기 때문에, 손쉽게 턴키 방식으로 여러 나라에 수출할 수 있지 않았을까? 그러면 IBM 같은 세계적인 회사가 생겼을 수도 있지 않았을까?

또 다른 예로, Mint.com이 나오기 10년도 전에 나온 모네타 서비스가 문을 안 닫고 계속 발전했다면 미국 시장으로 진출할 수도 있지 않았을까?

이런 가능성의 한 단면을 세계적으로 통용되는 안드로이드라는 시스템 위에 구축함으로써 손쉽게 세계 시장으로 나갈 수 있는 카카오 톡이나 라인에서 보게 된다.

솔루션

이 블로그는 친절한 블로그이기 때문에(ㅎㅎ) 해결책도 제시하도록 하겠습니다.


1. 지금이라도 공인 인증서, 엑티브 엑스를 완전히 걷어 내고 (제발 이상한 꼼수로 하지 마시기를), 세계에서 통용되는 방식으로 가야 한다.

2. 그 밖의 현재 존재하는 많은 규제들에 대해서 처음 부터 다시 생각해 본다. 즉 규제가 있다고 가정 하고 없앨가 말가를 고민하는 방식이 아니라 - 이런 방식은 많이 해 봤지만 효과가 없었다 - 모든 규제들이 아예 없다고 가정하고, 그 때 과연 우리가  그런 규제들을 다시 만들 필요가 있을지 고민하는 방식이어야 한다. 이 때 중요한 기준은 "정말 그 규제가 필요한 것인지", "규제가 없다면 산업이 더 활성화 될 수 있을지", "다른 나라에도 있는 규제인지"가 될 것이다.

예고

다음 글에서 실리콘 밸리가 한국에 있었다면, 구글, 빙 (Bing.com), 울프람 알파 (Wolfram Alpha), 쿠오라(Quara), 옐프(Yelp), 워드프레스 (Wordpress) 가 왜 망할 수 밖에 없는지에 대해 쓰겠습니다. 구글이 망한다구요?? 예, 망합니다^^

우리나라 소프트웨어 엔지니어 구(출)하기

에스티마님의 "프로야구 선수와 소프트웨어 엔지니어" 라는 글에 200% 공감한다.

많은 분들이 우리나라의 소프트웨어 산업을 육성해야 한다고 얘기하면서도, 우리나라 소프트웨어 엔지니어들의 열악한 현실에 대해서는 그 중요성에 비해서는 그다지 많은 얘기가 되고 있는 것 같지는 않다. 그런데 이 부분이 해결되지 않고는 소프트웨서 산업 육성이라는 것이 이루어 질 수 없다. 왜냐하면 이름에서도 알 수 있듯이 "소프트웨어 산업"의 핵심은 "소프트웨어 엔지니어"이니까. 좋은 야구 선수가 없으면서 그 야구 리그가 성공하기를 바랄 수 있을까?

많은 분들이 아이폰의 성공을 스티브 잡스에게 돌린다. 나도 그 부분에는 충분히 동의한다. 하지만 한 가지 간과된 부분은 애플에는  iOS를 만들 수 있는 실력의 소프트웨어 엔지니어들이 있었다는 것이고, iOS의 기반이 된 Mac OS를 만들 수 있는 실력의 소프트웨어 엔지니어들이 있었다는 것이다.

iOS나 Mac OS를 만드는 것이 얼마나 어려울까? 나로호 같은 위성 로켓만 만들기 어려운 것이 아니다. 위성 로켓보다 제대로 된 OS 만드는 것이 더 어렵다. 때문에 iOS나 Mac OS를 만들 수 있는 나라가 그리 많지 않다. 천하의 스티브 잡스라도 동남아시아의 어떤 나라나 아프리카의 어느 나라에서는 Mac OS나 iOS를 만들기 어려웠을 것이다. 우리나라였더라도 어려웠을거라 생각한다.

이렇게 아이디어가 훌륭해서 성공한 것 같은 제품들도 그 이면을 보면 대단한 기술력이 숨어 있는 경우가 많고, 그 기술력은 소프프웨어 엔지니어에서 나오는 경우가 많다.


그럼 우리나라 소프트웨어 엔지니어들의 대우를 어떻게 하면 개선하고, 그럼으로써 좋은 엔지니어들을 많이 확보할 수 있을까?

먼저 안 될 것 같은 방법들.

첫째, 기업들이 이런 문제 의식들을 가지고 자발적으로 개선 한다. 월급 더 안 줘도 대는데 자발적으로 더 많이 준다. 야근 더 시킬 수 있는데 자발적으로 안 시킨다.

둘째, 정부가 기업들에게 대우를 개선하라고 시킨다. 압박한다.


이번에는 될 것 같은 방법들.


첫째, 제대로 된 경쟁 시장을 만든다.

실리콘 밸리에서 소프트웨어 엔지니어들의 대우가 좋은 것은 기업들 간의 경쟁이 아주 심하고, 갈 수 있는 회사가 많기 때문이다. 우리나라에서는 가고 싶은 회사도 적고, 경쟁도 별로 심하지 않다. 그럼 어떻게 경쟁 시장을 만들까? 정부가 나서서 경쟁 기업이라도 많들어 줘야 하나?

정부가 심판의 역할을 제대로 하고, 정책 집행 과정에서도 경쟁 시장 형성의 관점을 우선 순위로 둔다면 경쟁 시장을 만드는데 결정적인 역할을 할 수 있다. ("실리콘 밸리를 망하게 하는 방법 - 첫번째", "잃어버린 한국의 실리콘 밸리를 찾아서"에서도 약간 다루었고, 앞으로도 이 부분에 대해서 좀 더 글을 쓸 예정이다.)

또 다른 부분은, 소프트웨어 회사들에게는 인터넷이라는 것이, 마치 물고기에게는 물과 같이 가장 중요한 환경인데, 이 환경이 우리나라처럼 열악한 곳도 별로 없다. 이 부분도 정부에서 주도적으로 환경 개선을 할 수 있는 것들이 많이 있다. (이 부분에 대해서도 다음에 자세히 쓸 예정이다.)


둘째, 동종 업계 전직 금지 규정을 폐지한다.

실리콘 밸리에서 소프트웨어 엔지니어들의 대우가 좋은 또 다른 이유는, 이직이 쉽기 때문이다. 예를 들어, 구글에는 상당히 많은 전직 마이크로 소프트 엔지니어, 야후 엔지니어들이 일하고 있다. 페이스북에서 가장 많은 비중을 차지하는 것은 아마 전직 구글 출신들일 것이다 (관련 다이어그램). 이렇게 이합 집산이 매일 같이 이루어 지기 때문에, 엔지니어에 대한 대우가 상향 평준화 될 수 밖에 없다. 아니면 더 좋은 조건의 회사로 옮겨 가기 때문에.

우리나라에서는 이런 일이 일어나기 힘들다. 엔지니어들에게 "동종 업계 1년간 전직 금지 규정"이라는 것이 있어서, 퇴직 후 일 년 간 동종 업계로는 이직을 할 수 없다. 그럼 동종 업계에 취직할려면 집에서 일 년간 놀 다 취직을 해야 하나?? (실제로 이런 분들도 있다.) 동종 업계로 이직을 못하면 소프트웨어 엔지니어가 치킨 가게라도 하라는 걸까?

이 규정의 취지는 기업이 열심히 투자해서 기술 개발한 것을 다른 기업이 부당하게 빼앗아(?) 가지 못하게 하자는 나름 좋은 의도를 가지고 있다. 하지만 이런 부분은 특허나 지적 재산권, 문서, 소스 코드 등으로 얼마든지 보호할 수 있다. 문제는 엔지니어가 일하면서 머리속에 쌓은 지식 조차 그 회사의 귀속물로 본다는 것이다. 이게 과연 합당한가? 그러면 변호사나 의사들도 다른 로펌이나 병원으로 갈려면 일 년을 놀아야 하나? 아님 외과 의사가 이직을 할려면 안과로 이직해야 하나?

적어도 미국에서는 엔지니어가 일하면서 머리속에 쌓은 지식, 기술에 대해서는 본인의 것으로 인정한다.

이 규정이 내포하고 있는 또 다른 문제점은 소프트웨어 엔지니어를 전문가로 대하지 않고, 회사의 부속품 정도로 생각하는 마인드가 깔려 있다는 것이다. 과연 의사나 변호사같은 전문가들을 이런 식으로 대할 수 있을까?


셋째, 소프트웨어 개발 발주사 선정시 회사의 역량을 충분히 반영한다.

우리나라 웹사이트들 쓰다 보면, 사용성 안 좋고, 자주 다운 되고, 속도 느린 사이트들을  꽤 접하게 된다. 그럴 때마다 왜 그럴까 항상 궁금했었다. 그러다가 이런 사이트들이 갑을병정을로 이어지는 엄청난 하청, 재하청으로 만들어진다는 것을 알고는 그럴 수 밖에 없겠다는 생각이 들었다.

소프트웨어를 정말 중요하게 생각한다면 이렇게 하청에 재하청을 주겠다는 개발사에 더 싸다는 이유로 일을 맡길 수 있을까? 예를 들어, 중요한 변호 업무를 맡기거나, 중요한 수술을 맡기면서, 하청에 재하청을 주겠다는 로펌이나 병원에 그 업무를 맡길 수 있을까?

이렇게 하청, 재하청을 주는 구조는 소프트웨어 개발자들을 열악한 환경에 빠뜨리니까 문제이기도 하지만, 자본 주의 사회에서 이렇게해서라도 품질이 제대로 나와 준다면 냉정하게 말해서 하지 말아야 한다고 딱히 얘기하기는 어려울 수도 있다. 하지만 이런 하청 방식으로 개발된 우리나라의 많은 사이트들을 보면 사이트들의 질이 상당히 낮다. 우리나라와 미국의 정부 사이트끼리, 은행 사이트들 끼리, 신문사 사이트들 끼리 비교해 보면 쉽게 알 수 있다.


끝으로, 세 가지를 얘기했지만, 굳이 꽂으라면 첫번째, 경쟁 시장 형성, 생태계 복원이 가장 중요하다. 이 부분에서 그 동안 우리들이 실수한 부분도 많고, 고침으로서 정말 좋아질 부분이 정말 많다.  부디 정책 집행 하는 분들이 혜안을 가지고 해 주시기를 빈다.

그리고 각 분야에서 소프트웨어 엔지니어를 정말 전문가로 생각하고 그에 맞게 대해 주시기를... 이라고 썼으나 다시 생각해 보니 그것까지 바라지도 않고, 한 사람의 인격으로 (한 사람의 가장으로, 누군가의 엄마 아빠로) 대해 주시기를... 이라고 써야 겠네요.

실리콘 밸리를 망하게 하는 방법 - 첫번째

실리콘 밸리를 어떻게 하면 가장 쉽고 빨리 망하게 할 수 있을까?

이런걸 왜 생각 하냐고?^^

이유는 끝에 나옴^^

어쨌던 가장 쉽고 확실한 방법은 미국 연방거래위원회 (FTC, 한국의 공정거래위원회 같은 곳)에서 제대로 일을 하지 않는 것이다.

실리콘 밸리에서는 참 이상한 일이 많이 벌어진다. 구글을 예로 보자.

첫째,  구글은 2006년 유튜브라는 직원 67명의 작은 회사를 무려 1조 6천억원이라는 금액으로 인수를 한다. 더 이상한 것은 그 당시 구글은 Google Video라는 유튜브에 대응하는 자체 서비스가 있었다는 점이다.

둘째, 구글은 2009년에 AdMob 이라는 조그만 모바일 광고 회사를 무려 7천 5백억원이라는 금액으로 인수를 한다. 그 당시에도 AdMob 제품에 대응하는 Google mobile ad라는 자체 제품이 있었다.

셋째, 구글은 Blogger.com 이라는 블로그 서비스를 제공하고 있는데, 이게 Wordpress 블로그 회사에 밀려서 한참 뒤떨어지는 만년 2등을 기록하고 있다. 이게 왜 이상한 일이냐고??

구글의 검색 사이트 (Google.com 또는 google.co.kr) 에서 검색 결과를 보여줄 때,  Wordpress 블로그 보다 Blogger.com의 블로그를 더 상위에 보여 준다면 어떻게 될까?

Wordpress는 그 길로 망한다. 왜냐 하면 많은 블로거들이 Wordpress를 버리고 Blogger.com으로 갈아탈테니까 말이다.

두 번째 경우를 보자. AdMob에 광고를 하는 광고주들에게 자꾸 AdMob과 거래하면 별로 좋을게 없다는 식의 얘기를 슬쩍 흘려 보자. (참고로 구글은 AdWords, DoubleClick 등 인터넷 광고 시장을 지배하고 있다.) 많은 광고주들이 AdMob에 등을 돌릴 것이고, 구글은 AdMob을 헐값에 인수하거나 그냥 망하게 내버려 둘 수도 있을 것이다.

그럼 구글은 이런 식의 편법으로 쉽게 경쟁회사들을 약화 시켜서 싸게 사거나, 망하게 할 수 있는데, 그렇게 하지 않고 엄청난 금액(유튜브 경우 직원 한 명당 238억)을 지불하고 조그만 경쟁사들을 인수한 것일까?

그 비밀이 미국 연방거래위원회나 비슷한 기관들에 있다. 이들 기관들은 위에서 예로 든 불공정 거래에 대해서 감시나 조사를 강도 높게 실시 하고, 처벌의 수위도 상상을 초월한다. 심지어는 회사를 쪼개거나 문을 닫게 만들 수도 있다. 때문에 구글 같은 대기업에서 정말 무서워하는 기관들이다.

만약 미국 연방거래위원회가 제대로 일을 하지 않으면 어떻게 될 지 상상해 보자. 많은 전도 유망한 스타트업들이 대기업의 불법, 편법으로 쉽게 망하게 되고, 그럼 지금과 같은 실리콘 밸리는 없을 것이다.


그럼 한국의 경우는 어떨까?

일부 지배적인 포털의 경우, 자사의 블로그나 자사의 사이트들을 경쟁사 사이트에 비해 검색 결과의 상위에 배치함으로써, 시장에 뒤늦게 뛰어들어도 손쉽에 경쟁사들을 이기는 경우가 많이 있었다. 이런 불법, 편법에 의해 망한 전도 유망한 스타트업들이 많이 있다.

만약 공정거래위원회 등에서 심판의 역할을 제대로 하고, 불법, 편법에 대해 단호히 처리를 했다면 어떻게 됐을까? 앞서 언급한 스타트업들이 망하지 않고, 한국의 WordPress, 한국의 YouTube, 한국의 AdMob 등이 되어 있을지 누가 알겠는가?


요즘 우리 나라 정부에서 스타트업을 키우기 위해 많은 노력과 지원을 하고 있다. 자금 지원을 한다던지, 실리콘 밸리로 연수를 보내 준다든지 다방면의 노력을 아끼지 않고 있다.

물고기들이 잘 살기 위해서는 맑은 물이 가장 중요하다. 물이 맑으면 굳이 먹이를 주지 않아도 자연히 많은 물고기들이 생겨난다. 반면 물이 맑지 않으면 아무리 먹이를 많이 주고, 갖은 애를 써도 별 소용이 없다.

마찬가지로  작은 회사들도 얼마든지 실력으로 큰 회사들과 실력으로 경쟁할 수 있는 공정한 시장을 만드는 것이 가장 중요하다. 이게 안되면 나머지는 별 소용이 없다.


* 다음회에서는 실리콘 밸리를 망하게 하는 두번째 방법에 대해 써 보겠습니다^^