고객이 SW를 망친다

우리나라는 고객이 소프트웨어와 개발사를 망치는 경우가 많다. 외국 소프트웨어 회사와는 다른 잣대로 우리 소프트웨어 회사를 대하는 이중성 때문에 우리나라 소프트웨어 회사는 더욱 어려움을 겪는다. 물론 이런 현상이 꼭 고객 탓만은 아니다. 

우리나라 소프트웨어 회사들이 미래는 생각하지 않고 당장 눈앞의 이익만 쫓다 보니 고객들은 여기에 길들여진 측면도 있다.

이렇게 고객이 소프트웨어 환경을 망치고 있는 실제 사례들을 알아보자. 

A사 고객들은 참을성이 없다. 

소프트웨어에 버그가 발견되면 당장 고쳐달라고 막무가내 식으로 요구한다. A사는 팩키지 소프트웨어를 만들기 때문에 개별 고객의 요구사항을 다 들어주지는 않는다. 하지만 이렇게 무리한 요구를 하는 고객이 많기 때문에 당장 고쳐주지 않을 수 없다. 

이렇게 계획되지 않는 급한 수정을 핫픽스(Hotfix)라고 한다. A사는 특정 몇몇 고객 때문에 핫픽스를 과도하게 많이 만드느라 계획된 개발 일정에 지장이 생겼고 소스코드도 지저분해졌다. 

하지만 A사 고객들도 외국 소프트웨어를 사용하면서는 그런 무리한 요구를 하지 않는다. 외국 소프트웨어 회사들은 대부분 그런 요구는 들어주지도 않기 때문이다. 

B사는 소프트웨어 버그로 인해서 개발자가 고객사에 방문 사과를 한적이 있다. 

B사 고객들은 소프트웨어 버그가 발견되면 개발자를 죄인 취급한다. 가끔은 심각한 버그가 발생하면 개발자의 방문사과를 요구한다. 이런 말도 안되는 요구에 B사는 상황을 쉽게 모면해 보려고 개발자에게 고객을 방문해서 사과할 것을 지시했다. 

개발자는 어쩔 수 없이 사과 방문을 했고 개발자로서 회의를 느꼈다. 사실 버그 없는 소프트웨어는 없고 버그가 개발자만의 책임도 아니다. 개발에 참여한 모든 사람의 공동 책임인데 아직도 버그의 모든 책임은 개발자에게 있다고 생각을 하는 경향이 있다. 

자동차를 타면서 문제가 발생하면 자동차 만든 사람이 와서 사과를 하라고 하는 경우는 없다. 개발자에게 버그에 대한 사과를 요구하는 일은 대한민국에서만 벌어지는 현상이 아닐까? 

C사는 개발자들이 고객 옆에서 개발을 해야 한다. 

C사는 솔루션 회사다. 자사 솔루션을 이용해서 고객 요구대로 커스트마이징해서 개발을 해준다. 그런데 주로 고객들은 자사 담당자 옆자리에서 개발을 할 것을 요구한다. 사실 개발자들은 다니는 회사에서 개발하는 것이 훨씬 더 효율적이다. 여러 동료의 도움을 받을 수도 있고 환경도 더 좋다. 

그런데 고객이 방문해서 개발을 할 것을 강력하게 요청하기 때문에 어쩔 수가 없다. 스펙도 정하지 않고 옆에 앉혀 놓고 이러쿵저러쿵내키는대로 요구사항을 말하면서 소프트웨어를 개발한다. 요구사항이 많이 바뀌어서 지우고 다시 만들기를 수없이 반복했다. 

물론 외국 경쟁회사는 이런 요구에 콧방귀도 안뀌기 때문에 C사는 이런 방문 개발 방식을 강점으로 내세워서 국내 시장에서 상당한 성공을 이뤄냈다. 하지만 성장은 한계에 다다랐고 과거의 방식을 버려야 더 점프를 할 수 있다는 것을 알아도 방식을 바꾸기에는 너무 늦어버렸다. 고객보다도 개발자들이 이 방식에 익숙해져서 내부 개발문화를 바꾸지 못하는 것이 더 큰 걸림돌이 되고 있다. 

D사도 고객사에 방문해서 개발을 해야 한다. 

하지만 이유가 약간 다르다. 고객이 보안을 너무 강조하다 보니까 고객사에 방문해서 개발할 수 밖에 없다. 고객사에서 아무것도 가지고 나올 수 없다. 개발은 모두 고객사에서 해야 하고 고객사를 나올 때는 몸밖에 빠져나올 수 밖에 없다. 사실 이 회사도 외국 소프트웨어 회사와는 이렇게 일하지 않는다. 고객의 이중성은 여기서도 드러난다. 

E사는 유지보수 비용을 제대로 받지 못했다. 

E사는 솔루션 회사인데 납품 후에도 지속적인 유지보수 비용이 들어간다. 버그 수정 및 기능 개선이 꾸준히 이루어진다. 하지만 고객은 무상 유지보수를 요구해서 유지보수 비용을 제대로 받지 못한다. 심지어는 버그를 고치는데 왜 돈을 받냐는 주장을 하기도 한다. 

E사의 고객들도 외국의 소프트웨어를 쓸 때는 군말 없이 유지보수 비용을 지불한다. 외국 소프트웨어를 쓸 때는 패키지 소프트웨어라 하더라도 워런티 계약을 따로 한다. 워런티 비용은 소프트웨어마다 다르지만 매년 소프트웨어 구매 비용의 10%~50%를 지불한다. 

1년간 아무런 요청을 하지 않아도 비용은 지불해야 한다. 3년간 워런티 계약을 하지 않다가 4년째 문제가 발생해서 지원을 요청하려면 4년치 워런티 비용을 모두 지불해야 한다. 이렇게 외국의 소프트웨어 회사에는 유지보수 비용을 지불하지만 대한민국의 소프트웨어 회사에는 매우 인색한 것이 현실이다. 

F사 고객이 말도 안되는 문서를 수십 종 요구한다. 

F사는 SI회사다. 대부분은 실제 소프트웨어 개발에 꼭 필요한 문서는 아니다. 단지 고객이 제시하는 방법론에서 필요한 문서일 뿐이다. F사는 실제로는 고객 프로세스대로 소프트웨어를 개발하지도 않는다. 그런 식으로는 소프트웨어를 주어진 시간에 개발할 수 없기 때문이다. 

개발은 그냥 평소대로 하면서 문서만 추가로 따로 만든다. 문서를 반복적으로 만들어내다보니 너무 번거로워서 나중에는 문서를 자동으로 생성하는 프로그램을 만들기도 했다. 이렇게 만들어진 문서는 프로젝트 도중에도 프로젝트 후에도 아무도 보지 않는다. 

그냥 검수를 통과하기 위한 조건일 뿐이고 검수 시에도 소프트웨어와 문서가 일치하는지 확인할 방법도 없다. F사는 고객의 이러한 과도한 문서 요구에 프로젝트 비용이 훨씬 많이 들어가고 정작 개발할 시간이 줄어 들고 있다고 하소연을 하고 있다. 

G사는 패키지를 수정해달라는 고객의 요구로 인해서 회사가 어려워졌다. 

G사 고객들은 패키지 소프트웨어를 바꿔달라는 요구가 많다. G사도 이런 고객의 요구사항에 빠르게 대응하다 보니 소스코드가 여러 벌이 생겼다. 소스코드도 그냥 복사를 해서 고객별로 관리를 해서 시간이 흐를수록 개발 속도는 점점 늦어졌다. 기능 하나를 수정해도 여러 벌의 소스코드에 적용을 해야 했다. 

이렇게 소스코드를 통합(Merge)하는 시간이 점점 길어졌고 나중에는 개발하는 시간보다 소스코드 통합에 더 많은 시간이 소요되었다. 결국 G사는 문을 닫았다. 이는 고객 탓만은 아니고 눈앞의 이익만 쫓는 G사의 무분별한 단기 대응도 문제였다. 

요즘 정부도 민간도 소프트웨어 환경을 개선해보고자 많은 노력을 기울이고 있지만 정작 돈을 내고 있는 고객들은 바뀌지 않고 있다. 물론 고객만의 탓은 아니다. 수십 년간 우리나라 개발회사들에 길들여진 것뿐이다. 

이렇게 소프트웨어 환경이 망가지면 결국 고객들도 손해를 본다. 우리나라 소프트웨어 회사들이 많이 망가지고 나면 제대로 쓸만한 국산 소프트웨어가 줄어들고 울며 겨자먹기 식으로 비싸고 문화도 잘 맞지 않는 외국의 소프트웨어를 써야 한다. 

법으로 바꿀 수 있는 것은 바꿔야 한다. 사실 별 뾰족한 답도 없는 문제지만 결국 고객을 바꾸는 것은 개발사들이다. 계획적인 개발을 하려고 해도 경쟁사에서 고객 밀착형 서비스를 한다고 하면 경쟁에서 밀리고 만다. 

결국 이런 소프트웨어 품질보다 노예식 개발을 장점으로 내세우는 전략은 모두를 다 망치는 일이라는 것을 인식하자. 특히 시장을 주도하는 선두 주자들부터 소프트웨어 환경을 건전하게 바꾸어 나가면 고객의 우리나라 소프트웨어에 대한 이중적인 인식을 바꾸는 것이 불가능하지는 않을 것이다.

이글은 ZDNet Korea에 기고한 칼럼입니다.

자신의 코드에 발목 잡힌 개발자들

필자는 국내외 다양한 소프트웨어 회사에 다니는 여러 개발자를 만날 기회가 자주 있고 각 회사의 개발 이야기를 종종 듣는다. 

그 중에서 3가지를 소개할까 한다. 우리나라 개발자들이 다양한 일을 하지 못하고 하던 일만 계속하게 되는 현상에 관한 것으로, 이것이 왜 문제가 되는지 생각해 볼 수 있는 사례이지 싶다.
 
국내 A사는 소프트웨어 개발자만 100명이 넘는 업계 1위 중견기업이다. 이 회사 개발자들은 철저히 자신의 소스코드가 있어서 몇 개 프로젝트를 제외하고는 서로 공동으로 개발하는 경우가 거의 없다. 프로젝트도 거의 혼자서 담당하며 한 사람이 여러 프로젝트를 맡는 경우도 있다. 

이러다 보니 다른 사람의 소스코드를 볼 일이 거의 없다. 소스코드 뿐만 아니라 프로젝트간 정보 교류도 매우 적다. 이슈관리시스템을 사용하지 않고 공유 문화도 매우 취약한 회사다. 

그래서 개발자가 한 명만 아파서 못나와도 프로젝트에 큰 타격이 생기며 다른 개발자가 도와주기도 쉽지 않다. 개발 일이 한쪽으로 몰려도 어차피 소스코드별로 개발자가 정해져 있어 놀고 있는 개발자가 있어도 도와주지 못한다. 

부서마다 조금씩 다르지만 신입 개발자가 입사해 제대로 일하려면 수개월 정도는 공부를 해야 한다고 한다. 기존의 소스코드를 익히고 기반 지식을 공부하는데 수개월이 걸린다. 개발자가 퇴사할 때마다 개발팀은 큰 곤욕을 치르지만 경영진은 개발자를 아끼지 않는 것 같다는 하소연을 한다. 잦은 릴리즈와 고객 밀착형 유지보수 서비스로 개발자들은 이미 지쳐있다. 

우리는 이런 현상을 속된말로 '몸빵'이라고 한다. 개발사가 개발을 주도를 하지 못하고 고객에 끌려 다니면서 그때 그때 대응에 집중하는 것이다. 이런 환경에서는 계획으로 개발을 하지 못하고 격무를 피하기 어렵다. 아키텍처도 깔끔하게 유지하기 쉽지 않다. 

한편으로는 '컴포넌트 오너'라고 하는 현상인데 컴포넌트(Component)별로 주인이 정해져 있어서 다른 사람은 못 건드는 것이다. 이것은 비단 A사만의 얘기가 아니다. 국내 많은 개발자들이 자신이 작성한 소스코드에서 벗어나지 못하고 한 분야에서 계속 땅굴을 파 내려가 경험의 폭이 좁아지고 고급 개발자로 성장하기 어려운 환경에 처해 있다. 한쪽 분야의 숙련공이 될 수 있어도 고급 개발자가 되기는 쉽지 않다. 

국내 B사는 개발자만 수백명에 달하는 누구나 아는 회사다. B사는 이미 이런 문제를 겪었고 이를 타개하고자 개발자풀 제도를 시도했다. 과거에는 개발자를 팀별로 나눠서 팀내에서 주어진 일을 했는데 개발자 풀 제도를 통해 비효율적인 인력운영을 효율적인 체계로 바꾸고자 했다.

팀구분 없이 개발자를 한군데 모아 놓고 프로젝트 관리자가 프로젝트마다 필요한 개발자를 선별해서 개발을 진행하고 프로젝트가 끝나면 개발자는 다시 개발자풀로 돌아가는 방식이다. 잘 활용하면 팀의 구분 없이 최적의 개발자를 투입할 수 있고 한쪽 프로젝트에 일이 쏠려도 개발자들이 도와주기 용이하다. 개발자들은 회사의 여러 프로젝트에 투입되기 때문에 자연스럽게 지식을 공유하게 된다. 

취지는 좋으나 철저한 준비과정 없이 조직만 그렇게 바꿔 놓으니 일이 제대로 진행되지 않았다. 각자 전문분야가 다르니 다른 개발자를 투입해서는 일이 안됐고 결국 해당 일을 하던 개발자를 투입해야 했다. 매트릭스 조직이라 프로젝트 관리자와는 별도로 팀장이 따로 있으니 프로젝트에 특정 개발자가 필요해도 팀에서 개발자를 내놓지 않으면 프로젝트는 진행하기가 어려웠다. 

사람을 아무리 많이 투입해도 원래 개발자의 직접적인 도움 없이는 프로젝트를 수행할 수 없었다. 계속되는 혼란을 한참 겪은 B사는 결국 개발자 풀 제도를 포기하고 말았다. 

조직이나 프로세스만 바꿔서 역량을 향상하거나 효율적인 개발을 기대하기는 어렵다는 것을 경영진이 이해하지 못한 사례라고 할 수 있다. 

미국 F사의 경우는 개발자가 수천명에 달하는 글로벌회사다. 개발자가 새로 입사를 하면 오리엔테이션 기간에 실제 서비스가 되고 있는 시스템 버그를 고쳐야 한다. 입사 첫날부터 개발에 직접 투입되는 것이다. 신규 입사자 중에는 해당 개발언어로 개발을 해본 적이 없는 사람도 있다. 

하지만 버그를 고치는데 문제가 없다. 어차피 경험한 개발언어를 보고 개발자를 뽑은 것이 아니고 기초가 튼튼하고 문제 해결 능력이 뛰어난 개발자들을 채용했기 때문이다. 멘토가 있기는 하지만 옆에 끼고 계속 가르쳐 주는 것은 아니다. 

F사 신규 입사자에게는 소스코드가 저장된 SVN(Subversion) 주소와 버그관리시스템인 Bugzilla 주소를 통해  처리할 버그가 할당된다.  아무도 버그를 고치는 방법과 알아야 할 지식을 가르쳐 주지 않는다. 하지만 시스템 스펙과 설계문서에 접근할 수 있고, Bugzilla를 통해서 기존 개발자에게 도움도 받을 수 있다. 

신규 입사자는 소스코드를 분석해 버그 원인을 찾을 수 있다. 소스코드의 각 라인 별로 언제 누가 수정을 한 코드인줄 즉시 알 수 있고 소스코드를 수정할 당시의 관련된 이슈도 확인이 가능하다.

이후 신규 입사자는 SVN에 고친 소스코드를 등록하기 전에 코드리뷰시스템에 등록을 해서 리뷰를 받아야 한다. 간단한 버그 수정은 아무 문제 없이 코드리뷰를 통과하겠지만 몇몇 이슈는 온라인으로 진행된 코드리뷰의 도움을 받아 수정하기도 한다.

이렇게 버그를 고치거나 작은 기능을 구현하는 일은 신규 개발자들이 처리한다. 실력을 인정 받으면 점점 어려운 일을 할당 받는다. 고참 개발자들은 어려운 일이나 스펙과 설계 작업을 주로 진행한다. 개발자는 언제든지 새로운 프로젝트에 투입되고 물론 자신이 관심 있는 프로젝트에 지원할 수도 있다. 많은 개발자가 퇴사해도 서비스에 별 문제가 없고 대부분 즐겁게 일한다. 

우리가 가야 할 길은 명확하다. 구멍가게를 할 것이 아니라면 컴포넌트 오너식 개발은 금방 한계에 다다른다. 혼자서 시작하는 스타트업도 F사처럼 개발을 하는 것이 더 빠르고 효율적이다. 과거의 나와 현재의 나도 공유를 해야 할 필요가 있다. 

혼자 개발해도 적절한 공유와 문서화를 했을 때 개발이 더 빠른 이유다. 어찌 보면 한 우물을 파는 것이 전문성 향상에 도움이 될 것 같지만 다양한 경험 없이 한 우물만 파내려가면 우물 속 개구리가 되고 말 것이다. 

소프트웨어 회사 개발팀의 꽃은 아키텍트다. 개발자들이 다같이 각자의 우물을 파내려 가는 환경에서는 뛰어난 아키텍트가 나오기 어렵다. 뛰어난 아키텍트가 없는 회사의 미래는 뻔하다. 2층짜리 집은 근근히 만들 수 있어도 100층짜리 빌딩을 어찌 아키텍트 없이 만들 수 있을까? 

그래서 국내 1등은 가능해도 딱 거기까지가 한계다. 더 심각한 문제는 이런 식의 개발 환경에서는 개발자가 행복하지 않다는 것이다. 야근을 반복해야 하며 고참이 되도 계속 과거의 코드에 발목을 잡혀서 앞으로 나아가기가 어렵다. 

고참이 더 바쁜 회사는 이런 함정에 빠진 경우다. 이직을 하면 고리가 끊어지지만 새로운 회사에서 똑 같은 일이 반복된다. 

이를 해결하는 기가 막힌 한가지 묘수가 있는 것은 아니다. 가장 중요한 공유문화를 비롯해서 성숙된 개발문화가 정착되면 자연스럽게 해결 된다. 개발문화를 소홀히 생각하고 프로세스만 강화해서는 절대로 F사와 같은 상황이 벌어지지 않는다. 이것이 다같이 성숙한 개발문화에 정착에 힘을 써야 하는 이유다. 

스마트폰 앱스토어가 진짜 대박이 아닌 이유

요즘 스마트폰이 IT 이슈의 정점에 있어서 스마트폰 관련 글을 계속 올리게 됩니다.

개발자의 한사람으로서 스마트폰의 급속한 확대는 좋은 징조임이 분명합니다. 하지만 종종 스마트폰 어플리케이션을 만들어서 앱스토어에 올리면 쉽게 대박을 맞을 수 있을 것 같은 기사들이 눈에 띕니다.

"앱스토어에서 대박난 개발자들" [디지털타임즈]

전업주부도 아이폰 어플 개발자 시대 [디지털데일리]

앱스토어 '대박' 변해준 씨 [조선일보]

스마트폰은 '기회의 시장'…개발자들 '신바람'[SBS뉴스]

물론 거품을 경고하는 기사들이 많은 것은 사실이지만 좋은 것만 보인다고 대박 기사가 더 눈에 들어오는 것은 사실입니다. 개발자들은 "실패담은 내 이야기는 아닐거야"라고 자신에게는 관대한 판단을 내기는 것이 일반적입니다.

이런 종류의 기사들을 읽어보면 전문가들이 말을 인용하는 칼럼형식의 기사는 좀 나은데 기자들이 직접 작성하는 누구나 혼자서 쉽게 소프트웨어를 개발해서 성공할 수 있다는 식의 기사가 많습니다. 그래서 현 상황을 좀 냉정하게 바라보고자 합니다.

긍정적인 측면

확실히 앱스토어가 개발자들에게는 기회의 땅입니다. 어플리케이션을 만들기만 하면 바로 전세계 소비자와 바로 만날 수 있는 기회를 제공했습니다. 마케팅을 얼마나 잘하느냐는 다른 이슈이지만, 어마어마한 마케팅 비용을 들이지 않고도 일단 소비자와 접할 수 있다는 것은 엄청난 기회입니다. 정말 좋은 소프트웨어가 마케팅 비용이 없어서 사라지는 것을 막을 수 있습니다.

또한 스마트폰 앱 시장은 계속 커지고 있고 잠재 고객은 점점 늘어가고 있습니다. 

That's it.

부정적인 측명

기회는 균등합니다. 나에게 기회인 것은 전세계 모든 개발자들에게 동일한 기회입니다. 초창기를 제외하고는 소비자와 쉽게 자신의 어플리케이션을 보여줄 수 있는 것이 그리 매력적인 조건이 아닐 겁니다. 정말 좋은 소프트웨어가 아니면 이 장점이 큰 장점이 아닙니다. 또한 스마트폰 앱 시장이 점점 커지면서 메이저 소프트웨어 업체들이 뛰어들 준비를 하고 있습니다. 기존의 시장과 별반 다를바 없는 치열한 전투장이 될 겁니다.

시장은 그렇다 치고, 개발자 입장에서 바라보도록 하죠.

스마트폰이라고 해서 소프트웨어를 개발하기 더 쉬워진 것은 아닙니다. 잘 만들어진 Framework를 보면 개발이 더 쉬운 것처럼 착시현상을 일으키기도 하지만, 이것이 소프트웨어 개발 전체 프로세스에 미치는 영향은 5%도 되지 않습니다. OOP 컨셉이 없는 개발자들은 오히려 뒤죽박죽을 만들어 버리기 일쑤입니다. SDK를 이용한 코딩보다도 스펙을 제대로 정하고 설계를 하고 테스트를 하는게 비중이 더 높습니다. 이는 기존의 다른 소프트웨어를 개발하는 것과 별단 다르지 않습니다. 즉, 기존에 소프트웨어를 잘 개발하던 개발자나 회사가 이또한 잘 할겁니다.

스마트폰 앱이라고 해서 한번 만들고 끝나는 것이 아닙니다. 일반적으로 소프트웨어는 유지보수 비용이 개발비용의 2~5배 정도 들어간다고 합니다. 그래서 한번 만들어놓은 앱을 꾸준히 유지보수를 해야 하는데, 개인이 이를 감당하기에는 어려움이 있을 수 밖에 없습니다. 진짜 전업으로 매달려야 합니다. 또한 버그 관리, 소스관리, 스펙 관리가 그렇게 쉽지 않습니다. 기존의 소프트웨어 회사들도 크나 작으나 이들을 잘 해내지 못하는 것이 현실입니다. 그렇다고 혼자 개발을 한다고 이 이슈가 사라지지 않습니다. 진짜 혼자 다 해야 합니다.

또, 어쩌다 꽤 인기있는 앱을 만들어서 중박정도를 했다고 해도 꾸준히 매출을 유지하기 위해서 업그레이드와 새로운 제품을 계속 만들어내야 합니다. 앱 개발이 전업이 되었다는 얘기는 꾸준히 수익을 창출해야 한다는 얘기입니다. 회사라면 크나 작으나 나름 각 분야의 전문가들이 힘을 합쳐서 일하기 때문에 진짜 자신이 잘하는 분야에 집중할 수 있어서 꾸준히 발전해 나가는 것이 혼자 북치고 장구치고 하는 것보다는 유리합니다. 자칫하면 수주대토(守株待兎)가 될 수 있습니다.

소프트웨어 개발이라는 것의 대부분은 팀으로 일을 했을 때 더 잘 할 수 있는 것들인데, 혼자서 한다는 것은 한계에 부딪히게 됩니다.  아이디어의 한계, 기술의 한계가 그겁니다. 물론 혼자 일하는 것을 좋아하는 개발자들중에서는 팀웍을 이뤄서 제대로 일하는 방법을 모르기 때문인 경우도 있습니다. 어떠한 경우라도 혼자서 1인회사를 해나가는 것은 쉽지 않은 결정입니다.

이미 소프트웨어 개발에 상당한 공력을 가지고 있는 개발자 몇명을 제외하고는 아무리 좋은 아이디어로 좋은 앱을 개발했다고 하더라도 혼자 개발하는 것은 스스로의 성장에도 지장을 줄 수 있습니다. 물론 이런 시도는 도전의식과 비즈니스 경험을 쌓을 수 있어도 소프트웨어 개발자로서의 경험은 상대적으로 놓치게 됩니다. 자칫 평생 혼자 개발해야 편한 개발자가 될 수도 있습니다. 실패에서 얻는 것도 있지만 잃는 것도 크다는 것을 명심해야 합니다.

소프트웨어 개발자로서 사회에 첫발을 디뎠다면 아무리 대학때 소프트웨어를 좀 개발해 봤어도 조직에서 팀을 이뤄서 개발하는 방법과 그 문화를 어느정도 익히는 것이 필요합니다. 물론 좋은 환경의 소프트웨어 회사라야 하겠죠. 그리고 나서도 확신이 선다면 시도해볼 수 있는 도전이라고 생각은 합니다. 하지만 결코 기존의 소프트웨어 환경에 비하여 성공확률이 더 높아졌다고 생각해서는 안됩니다. 이또한 노력하는 사람에게 더 많은 기회를 제공할 겁니다. 자신의 성공확률에서 바뀐 것은 아무것도 없습니다.

이 상황을 너무 부풀려서도 너무 축소해서도 안됩니다. 확실히 기회가 생긴 것은 맞습니다. 하지만 냉철한 가슴으로 생각하고 도전해야 합니다. 또, 이를 이용해서 부추기는 선정적인 기사는 좀 줄어야 하겠습니다.