태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

나는 한달 동안 휴가를 갈 수 있을까?

2014.08.30 15:38 by 전규현


잠시 후 Google blogger로 이동됩니다.






내가 만약 한달 동안 휴가를 간다면 회사에서는 무슨 일이 벌어질까? 각자 한번 상상을 해보자.

 

내가 있던 없던 상관없이 회사는 돌아갈까? 아니면 내가 관련된 일들이 진행되지 않아서 회사가 마비가 될까? 내가 없으면 회사가 돌아가도 문제지만 내가 있으나 없으나 회사가 아무 없이 돌아가도 불안하다. 혹시 내가 없어도 되는 사람이 아닌가 걱정이 되기도 한다.

 

유지보수가 어렵게 코딩하는 방법이란 책도 있다. 원제는 “How to write unmaintainable code : Ensure a job for life ;-) This essay is a joke!”이다. 책은 조크이지만 내가 없으면 유지보수가 몇배, 몇십배 어려워지는 온갖 다양한 방법을 소개하고 있다. 사실 본인도 유지보수가 어려워지는 방법들이다.

 

년에 한번씩 강제로 한달 동안 휴가를 가야 하는 회사가 있다. 휴가기간 한달 동안 원격지에서 일을 있다는 것이 아니다. 진짜 휴가를 가야 한다. 이런 강제 휴가제도를 만든 이유는 어느 직원이던지 직원이 없어도 회사가 돌아가야 하기 때문이다. 업무의 특수성 때문에 한달 동안 자리를 비울 없는 직원이 있다면 회사의 조직을 바꾸던지 프로세스를 바꿔서 다른 사람으로 대체가 가능하거나 보완이 가능하도록 한다. 누구든지 한달간 휴가를 떠나도 아무런 문제가 없이 해놔야 한다.

 

이런 회사에서는 직원들이 언제든지 짤릴 있다는 불안감을 가져야 할까?

 

가상의 이야기가 있다. 원자력 발전소에서 일하는 홍길동은 절대로 3 이상 휴가를 없다. 홍길동은 오랜 노하우로 적절하게 원자로의 온도를 조절하는 특수한 능력을 가지고 있고 홍길동 외에는 그런 기술이 없다고 하자. 홍길동은 수동으로 온도 제어장치 조절이 가능한데 자동 처리 시스템을 갖추려면 엄청난 비용과 많은 추가 인력이 필요하다고 한다. 회사 입장에서는 비용을 투자 하는 것보다 홍길동만 유지하면 적은 비용으로 발전소 운영이 가능하고 홍길동은 자신이 없으면 발전소가 돌아가지 않는 상황에 자부심을 가지고 있다. 하지만 홍길동은 격무에 시달려서 회사를 그만두거나 불의의 교통사고를 당할 수도 있다. 나라의 발전소에서 높은 연봉으로 데려갈 수도 있다.

 

나는 강연이나 세미나를 자주 묻는다. “지금 당장 퇴사를 해도 회사에 문제가 없는 사람”. 그러면 거의 대부분 손을 드는 사람이 없다. 실제로 퇴사를 해도 문제가 없는 사람이 없을 수도 있고 다른 사람들 눈치를 보기도 한다.

 

반대로 그럼 당장 퇴사하면 회사가 돌아가는 사람손을 들라고 하면 사람들이 당당하게 손을 번쩍 든다. 사람은 떠밀려서 손을 든다. 그러면서 주변에서는 웅성웅성 말들이 많아진다. 약간의 빈소적인 말도 들려온다. 대부분의 회사에서 공통적인 현상이다.

 

우리 주변의 소프트웨어 회사들 중에는 개발자 한두명만 퇴사를 해도 영향을 받는 회사가 많다. 회사의 경영진은 문서화도 잘되어 있고 공유도 되어 있어서 문제 없다고 하는 경우도 있지만 속을 들여다 보면 유지보수에 쓸모도 없는 문서에 공유는 형식적으로 되어 있어서 실제로는 문제지만 쉬쉬하는 경우가 많다. 개발자들도 자신이 없을 회사가 돌아가는 상황을 그렇게 나쁘게만 보지 않기 때문에 이슈로 생각하지 않는다.

 

이러한 현상 때문에 아버지가 돌아가셨는데 상중에도 회사를 나와서 일을 했다는 경우를 들기도 하고 신혼여행도 제대로 못가는 경우도 발생한다.

 

그럼 이런 현상이 회사에는 불리하지만 개발자에게는 유리한 현상일까? 단기적으로는 그렇게 생각할 있지만 장기적으로는 얘기가 완전히 달라진다.

 

나는 당장 퇴사하면 회사가 돌아가는 사람 하루 빨리 정리를 해야 하고, “지금 당장 퇴사를 해도 회사에 문제가 없는 사람 회사에 필요한 사람이라고 얘기한다. “당장 퇴사하면 회사가 돌아가는 사람 많다면 회사가 갑자기 망해도 이상하지 않은 상황이다. 이렇게 망한 회사들은 이런 이유 때문에 망한 것이라는 것을 알아채기는 쉽지 않다.

 

지금 당장 퇴사를 해도 회사에 문제가 없는 사람중에는 정말로 하는 일이 없어서 있으나 마나 사람이 있을 수도 있지만 그건 주제에서 벗어난 얘기고 대부분 동안 해왔던 일들이 문서화가 되어 있고, 공유가 잘되어 있으며 다른 사람이 이어 받아서 처리하는데 문제가 없는 경우다. 이런 사람은 회사의 미래의 프로젝트를 위해서 필요한 사람이다.

 

반대의 경우는 동안 저질러 놓은 일이 많고 자신이 아니면 유지가 된다. 하나 해결하려고 해도 개발자에게 물어봐야 하고, 다른 사람들은 시스템에 대해서 이해하기도 어렵고 개발자가 한두 시간이면 뚝딱 해결할 있는 것을 유지보수 개발자에게 시키면 며칠이 걸려도 해결이 어렵고, 해결을 했다고 해도 다른 문제를 만들어 냈을까봐 두렵다. 회사입장에서는 리스크가 아닐 없없다. 하지만 회사에서는 이런 개발자를 핵심 개발자라고 착각하고 질질 끌려 다닌다.

 

물론 개발자가 일부러 이런 경우는 흔치 않다회사의 문화, 프로세스가 엉망이니 그냥 열심히 하던 대로 개발을 하다 보면 이런 현상은 십중팔구 일어난다. 특히나 개발 능력이 뛰어난 개발자들에게서 이런 현상이 일어난다. 혼자서 많은 양의 코딩을 해내지만 같이 공유하고 리뷰를 해줄 개발자가 없고, 혼자서 제품 하나를 뚝딱 만들어도 유지보수에서 발을 빼기 어렵게 된다. 일부러 유지보수가 어렵게 코딩하는 사람은 없겠지만 작성해놓은 코드를 보면 유지보수가 어렵게 코딩하는 방법이란 책을 공부한 사람처럼 코딩하는 경우도 있다.

 

이렇게 자신의 과거 업무에 발목이 잡혀있는 개발자들은 앞으로 나아가면서 성장하기 어렵다. 회사의 미래 프로젝트, 좀더 어렵고 재미있는 일을 못하게 된다. 새로운 기술이나 지식을 익힐 기회는 점점 줄어들고 매일 하던 반복적인 유지보수에 매달리거나 과거에 해놓은 일의 기억을 헤집는 일을 주로 하게 된다. 자신의 과거의 업무에서 자유로워지는 일은 자신의 가치를 좀더 높이는 일이다.

 

물론 우리나라 회사에서는 이런 것이 통하지 않는다고 주장하는 사람도 있을 것이다. 개발자를 부품으로만 생각하는 회사는 개발자가 없어도 문제없게 만들어 놓은 개발자는 언제든지 자를 있다. 실제 이런 회사도 많이 있고 이런 회사에서 일하는 개발자라면 유지보수가 어렵게 코딩하는 방법 공부하기를 바란다.

 

개발자가 자신이 없어도 회사가 문제 없이 돌아가게 하려면 공유를 해야 한다. 문화적으로 성숙되고 프로세스를 갖춘 회사라면 모든 개발업무가 진행되면서 자연스럽게 공유가 되는 시스템을 갖추고 있다. 중간 중간 리뷰 과정을 거치고 문서화가 되며 지식과 경험이 자연스럽게 여러 사람과 공유가 된다. 이런 프로세스를 뒷받침할 기반시스템도 적절히 갖추고 있다. 공유를 위한 공유가 아니기 때문에 훨씬 자연스럽고 부담도 없다.

 

자신은 어떤가 생각을 해보자. 한달간 휴가를 있을까? 회사의 모든 직원이 각자 한달간 휴가를 있을까? 그렇지 않다면 무엇을 바꿔야 할지 생각해보자.

 

저작자 표시 비영리 변경 금지
신고

전규현 소프트웨어이야기 개발문화, 유지보수, 휴가

  1. 잘 보고 가요. 좋은 하루 되세요. ^^

  2. 글을 읽고 나니 생각이 바뀌는군요 ㅎㅎ

  3. 나 없으면 회사가 안 돌아간다는 자신있게 얘기한 제가 부끄러워지네요^^;;

고객이 SW를 망친다

2014.02.11 23:59 by 전규현


잠시 후 Google blogger로 이동됩니다.






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

 

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

 

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

 

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에 기고한 칼럼입니다.

저작자 표시 비영리 변경 금지
신고

전규현 소프트웨어이야기 고객, 고객지원, 유지보수

  1. 완전 공감하는 글입니다~!!

    고객분들을 무시하는 것은 아니지만 그래도 너무한 경우가 많습니다 ㅠㅠ

  2. Blog Icon
    min

    지금당장 원하는 입맛대로 안해주면 경쟁사제품 및 솔루션을 쓴다고 협박하는데. . . 갑중의갑 절대갑은 정말 조폭입니다.

  3. Blog Icon
    kalms

    client와 customer 또는 consumer는 다른데
    이 경우는 client가 SW를 망치는 거였군요.
    용어부터가 망치도록 만들어져 있죠.

  4. 근데 보면 고객이 버그 수정을 요청하지 않으면 그 문제가 계속 방치되는 경우도 매우 흔합니다. 고객도 처음 버그를 발견하고 제공사에서 알아서 버그를 해결해 주기를 바라지만 시간이 지나도 여전히 버그는 수정되지 않고 방치되는 경우가 많습니다. 고객은 그때 제공사에 문제점 해결을 강력하게 요구하게 되는데 자잔한 문제는 그냥 참고 넘어갈 수 있는 문제지만 어떤 건 치명적인 문제인데도 수정이 안되는 경우가 있습니다. 제가 봤을 땐 개발사들이나 제공사들이나 충분한 테스트를 하지 않고 버그리포트를 고객에게만 의존하는 습성이 존재하기 때문이라고 생각합니다.

    고객이 개발을 망친다는 포스트를 읽으니 전 이런 생각들이 떠오르네요.

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

2014.02.06 23:39 by 전규현


잠시 후 Google blogger로 이동됩니다.








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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

저작자 표시 비영리 변경 금지
신고

전규현 소프트웨어이야기 유지보수

  1. 좋은 내용 고맙습니다.

  2. 버그를 고치는데 문제가 없다. 어차피 경험한 개발언어를 보고 개발자를 뽑은 것이 아니고 기초가 튼튼하고 문제 해결 능력이 뛰어난 개발자들을 채용했기 때문이다.

    이건 무책임한 생각 아닌가요?
    결국 똑똑한 사원 뽑았기때문에 버그 문제없이 고칠 수 있었다고 읽혀지는데요.

    이정도로 f회사가 잘돌아간다고하면 위의 문제회사들도 똑똑한 사원뽑으면 다 해결될수있을겁니다.

    자기가 하지않았던 프로젝트에 투입되어도 전혀 문제될게 없다. 어차피 기본이 튼튼한 사람을 뽑았기 때문이다.

  3. 개발자의 역량을 특정 언어에 대한 경험의 양에 기대기보단, 어떠한 문제를 분해하여 해결할 수 있는 능력과 신입도 체계적으로 프로젝트의 과거 이력에 접근할 수 있는 시스템과 이를 구축하게 만드는 회사 문화에 주목해야 하는게 이 글의 취지가 맞는게 아닐까 하는 생각이 듭니다.

    똑똑한 개발자를 뽑아야 하는건 맞지만, 그 똑똑한 개발자를 더욱 잘 성장시킬 수 있는 힘도 회사 문화에 있다고 봅니다

  4. Blog Icon
    csh7963

    음... 버그를 고치는 일의 범위가 어디까지인가요? 해당 언어에 대한 지식이 있어야 버그도 찾고 그러는거 아닌가요? 실제 개발된 설계스펙을 보고 잘못된 곳이 어디인지 찾아내는 것까지가 버그를 고치는 일로 정의된다면 윗 글이 맞겠지만, 문제의 원인을 찾고 잘못된 코드를 고치는 일까지 버그를 고치는 일이란 것에 포함시킨다면 이야기가 다르지요. 거기에 대한 설명 없이 그냥 저렇게 쓰면, 읽는 사람에 따라서 문제를 지적할 수도 있습니다.

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

2010.02.09 13:58 by 전규현


잠시 후 Google blogger로 이동됩니다.





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


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

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

긍정적인 측면

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

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

부정적인 측명

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

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

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

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

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

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

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

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

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

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image by Mykl Roventine
저작자 표시 비영리 변경 금지
신고

전규현 소프트웨어이야기 개발자, 대박, 문화, 버그관리, 소스관리, 스마트폰, 스펙, , 앱스토어, 유지보수, 중박

  1. Blog Icon
    지니랜드

    수구대토 -> 수주대토 로 수정해주세요

  2. 감사합니다. 블로그 글은 종종 오타가 생기더군요. 좀더 꼼꼼히 적어야 하는데요...

  3. Blog Icon
    ㅎㅎㅎ

    제 생각엔 스마트폰 초창기(아이폰으로 인해 시장이 커지는)라서
    거품에 있고 사람들이 스마트폰에 대한 환상을 가지고 있는 것같습니다.
    손바닥만한 화면으로는 분명 한계가 있는데요...
    결국 단지 개인의 필요에 따라 몇몇 특정한 기능으로만 사용하게 될거고
    꼭 이동시 사용해야하는 사람만 사용할텐데
    꼭 만능기기인것처럼 여겨지는 분위기네요.
    PMP있지만 돌아다니며 영화보는 사람 별로 없고요
    네비있지만 네비들고 다니며 걸어가는 사람 없습니다.
    전화기로 엠피스리 들을수있지만
    따로 엠피스리를 가지고 다니는 사람들이 대부분이죠.
    만능기기는 불편하고 이동기기도 또한 불편하죠.
    이동하며 사무를 볼 수있다지만
    이동하면서 까지 사무보고 싶은 사람이 몇이나 있겠어요.
    오히려 전화기능과 카메라기능을 첨가하고
    터치기능을 넣은 OS를 가진 스펙이 강화된
    타블렛식으로 LCD를 뒤집을수있는
    10인치내의 화면을 가진 노트북이 나오면
    스마트폰 시장은 죽을 것같네요.ㅣ

  4. 제 생각은 좀 다릅니다.

    스마트폰의 파급효과는 생각보다 클 것 같습니다. 지금은 거품이라고 얘기하지만 거품이 꺼지면 실체가 보일겁니다.
    지금은 인터넷 없는 세상 생각하기 힘들죠? 스마트폰은 인터넷을 들고다니게 되는 세상입니다. 한단계 업그레이드 되는 겁니다. 기존에도 이동중에 인터넷을 사용할 수 있었지만, 편리함이 다르죠.
    스마트폰이 화면이 작기는 하지만 새로운 UX가 불편함을 감소시킬 것이고, 자연스럽게 생활속으로 파고들 것으로 예상하고 있습니다.
    인터넷(웹)이 나오고나서 일상 생활속을 들어오는데까지는 6,7년이 걸렸습니다. 스마트폰이 나온지는 꽤 됐지만, 전 아이폰과 안드로이드 폰이 나오고 완전히 생활속으로 들어오는데, 3,4년이면 충분하리라고 봅니다. 그사이에 사람들을 편리하게 해주는 앱들이 쏟아져 나오겠죠.

    누가 옳든 간에 이쪽 밥 먹고 사는 사람들은 남들보다 빨리 알아채야 겠죠. 버스 떠난 다음에 손흔들면 안되니까요... 일반 사용자라면 자신이 좋은 것 그냥 선택하면 될거구요. ^^

  5. 저도 '현혹'의 성격이 짙은 글을 보면 비판적인 시각으로 바라보려 하고 있습니다.
    이슈에 대해 여과 하지 않고 우르르 몰렸다, 우르르 파했다~ 하는 것만 봐도 매우 급변하는 IT정세와,불안정한 시국을 그대로 나타내주는 것이니까요. 이런 정세에 본질을 파악하기란 매우 어렵겠지만.. 지금 우리에게 필요한 것은 비판적인 시각이 아닐까 합니다. 예를들어.. 전규현님이 말씀하신 것처럼 요즘 모바일 쪽의 구인란을 보면 모바일 개발 경험이 有인 사람에 국한되어 있더군요. 참 안타까운 일입니다. 매우 좁게 시장이 형성되는 것도 문제이고, 장기적인 안목이 아닌 '언 발에 오줌누기 식'의 인력들만 채용하고 있으니까요. 본질을 따져서 설계와 구조에 중점을 둔다면 당연히 OO나 OOP관련 경험,또는 공학방법론을 사용해봤던 인재 위주로 형성이 되어야 하는 것이 맞다고 봅니다. 그 밑에 코딩할 인재들도 필요한 것이구요.
    이 단면에서 돈만 되면 한다는 식의 불안정한 정세를 다시 한번 엿볼 수 있었습니다.
    (요즘 스마트폰 애플을 취미삼아 해 보고 있습니다.--단지 취미입니다. 주업은 아니죠. 전에 GUI방식의 소프트웨어를 개발한 경험이 있다면, 예전 방식과 매우 닮아 있다는 것을 느끼고 맙니다.)

    팀과 인력조화에 대해서도 한가지 문제점을 제시하자면.. 서로 잘 아는 팀을 만들 수 없는 문화가 한 몫하는 것 같습니다. 회사마다 계약 체제가 다르고 관리제도가 다르니 문화가 다를 수밖에 없고, 하청구조가 이미 뿌리박힌 데다가 같은 회사사람이 누군지도 모른 체 프로젝트가 진행되고 있는 곳도 상당히 많습니다. 어떤 회사는 갑 측에 같은 비용으로 50만 제공해주어도 되지만, 어떤 회사는 같은 비용에 200을 요구하는 곳이 있더군요.

    얼마 전에 선임연구원으로 혼자 들어갔었던 프로젝트가 바로 이것과 비슷했습니다. 돈을 더 많이 주니 더 많은 아웃풋을 내야 한다는 묵시적, 강제적 계약조건이더군요. 설계,구조.. 전혀 신경을 안 쓰고 제품의 품질과는 전혀 상관없이 높은 비용(그렇게 높지도 않지만)을 주니 설계 제외하고 더 많은 아웃풋을 내라..라는 SI특유의 병폐를 또 다시 한번 경험했습니다.(아웃풋에 계약조건으로 차등을 주니 사실상 팀웍이란 잠점을 발휘할 수도 없을뿐더러 활용할 수도 없는 문화가 되어버립니다.)

    사실 노하우있는 기술자를 쓰는 이유는
    소프트웨어가 필요한 곳에 경험과 노하우,설계,구조론,방법론을 오히려 배우기 위한 것으로 생각합니다. 그것이 경험 있는 기술자들을 쓰는 이유가 아닐까 합니다.
    5년 차가 10장찍어내고 10년 차가 같은 시간에 20장을 찍어내라는 식이니..원..(이런 곳 정말 많습니다.) 상식적으로 매우 미달인것이죠.

    전 지금 병원에 입원해 있는데도.. 규현님의 글은 읽어 봅니다.:)

  6. moova님 안녕하세요.

    병원에 입원해계시고 수술이 필요하신 것 같은데 쾌차하시기 바랍니다.
    우리나라의 대부분의 회사에서는 고급개발자를 키울지도 모르고 구분할줄도 모르고 고급개발자가 무슨 일을 하는지도 모릅니다. 그만큼 낙후되어 있습니다.

    소프트웨어 개발에 있어서 무슨일이 싼일이고 어떤게 비싼 일인지 구분도 못합니다. 그래서 비용과 시간이 더 많이 들며서도 날밤까면서 일해도 좋은 제품이 안나오죠.

    또 무엇이 필요한 문서인지 어떤 것은 형식적이고 필요가 없는 것인지도 구분하지 못합니다. 이는 프로젝트마다 달라서 선임급(고급)개발자가 이런 것들을 프로젝트 성격에 맞게 합리적으로 결정해야 하는데 그렇게 하지도 못하게 하는 것이 현실입니다.

    moova님도 고생이 많겠습니다. moova님 글들을 보면 어떤 생각과 경험을 가지고 있는지 알 수 있거든요. 저는 언제나 미래에 기회가 되어서 제 블로그를 찾아주시는 분들 중에서 뛰어난 분들과 일해보는 것을 꿈꿔 보곤 합니다.

    감사합니다. 다시 한번 쾌차를 기원합니다.

  7. 스마트 폰이 상당부분 생활을 바꾸긴 하겠지만, 그렇다고 해서 삶을 스마트하게 바꾸어 줄꺼라고 생각하지는 않습니다. 상당 부분 거품도 있고 허세도 있기 때문이죠.

    문득 지하철에서 보이는 아이폰 유저들을 보면
    "게임", "동영상" 정도 밖에 안보이더군요.
    일부 헤비유저일 것으로 예측되는 증권이나 금융 개발쪽 분들이 눈에 띄지 않는 걸지는 모르겠지만
    결국에는 PMP + PSP + NDS 를 통합한 그 이상도 그 이하도 아닌 딱 게임기+휴대폰 이라는 느낌이 강합니다.
    단지 인터넷이 될뿐이고, 외부에서도 편하게 할수 있을 가능성이 있기 때문에 사용자들이 끌리는거겠죠

    솔찍히 말해서 저도 쓸모는 없지만 가지고는 싶습니다.
    '필요'하지도 않고 '용도'도 정해지지 않았지만 가지고는 싶습니다.
    아마도 이러한 경우에 단지 새로 나온 스마트 폰이고 다들 아이폰 아이폰 하니까 얼리어탑터 기분으로
    대세(?)를 따라 나도 스마트하게 스마트폰! 하는게 아닐까 생각이 됩니다.

    결론만 말하자면, 지금보다 상당부분 거품이 심하게 끼어있고, 비록 어느정도 삶을 변화 시킬지라도 생각보다 큰 변화를 일으키지는 못할것이라는 겁니다. 원더키디가 나올때까지 10년도 채 안남았고, SF영화에서 그리던 2000년은 차들 대신에 무빙워크 에 서서 다니는 그런 환상적인 세상이었는데 실질적으로 변한 삶의 패턴은 극히 드물듯이 말이죠.

  8. 구차니님 안녕하세요.

    현재 거품이 꺼지고 좀 차분해져야 실체가 나올 것 같습니다.
    "알고 봤더니 별거 아니더라"라는 말도 많이 나오겠죠. 그러면서 서서히 생활속으로 들어와서 조금씩 생활패턴을 바꾸겠죠. 이게 뭐 엄청난 변화냐? 라고 할 수도 있어도 지금도 인터넷(특히 웹) 없이도 사는 사람이 엄청나게 많지만 많은 사람은 인터넷 없는 세상은 상상하기 힘듭니다.
    처음에 웹이 나왔을 때 되는게 없었습니다. 이걸로 뭐를 할 수 있을지 제대로 상상한 사람도 별로 없었습니다. 그때는 기껏해야 회사 소개하는 홈페이지와 인터넷 신문정도 였습니다. (여담이지만 95년에 제가 세계 최초 상용 Webmail 시스템을 만든 사람이지만 이를 기억하는 사람은 아무도 없습니다. 세계최초 별거 아닙니다. - -; 저는 별로 크게 성공하지도 못했구요. 제가 만든 Webmail을 컨셉과 원형을 따라서 만든 D사는 크게 성공했죠)

    94년에 웹이 처음 나왔을 때는 이것이 생활을 바꿀 것이라고 생각한 사람은 극소수였습니다. 그런데 스마트폰은 얼마 되지도 않았는데 난리네요. 그래서 거품이 꺼져야 한다는 얘기입니다. 반대급부로 이쪽 개발에 종사하는 개발자들은 거품이 더 좋은 기회가 되기도 합니다만...

    스마트폰이 바꾸는 생활의 변화를 가져오는 것의 주역은 하드웨어가 아닌 소프트웨어라고 생각합니다. 얼마나 좋은 소프트웨어가 더 많이 나오냐에 따라서 결론이 달라질 것 같습니다. 이는 소프트웨어 개발자들이 몫이겠죠. 구차니님 같은 분들이 바꾸는 것이라고 생각합니다.

    설령 기대에 못미칠 수는 있어도 소프트웨어 개발자라면 과소평가보다는 창조자의 마인드로 동참하는 것이 필요하다고 생가가합니다.

  9. 스마트폰에 대해서 갖는 부정적인 시각은, 사용자가 아닌 개발자의 시선에서 바라봐서가 아닌가 싶습니다.
    제가 느끼는 스마트폰은 저에게 있어서는 혁명이었습니다.
    96년부터 PC통신 하이텔을 통해서 커뮤니티에 입문했는데요, 그 이후로 제 삶속에는 항상 인터넷이 있었습니다.
    어딜가도 컴퓨터가 있으면, PC통신에 접속하고, 그 이후에는 인터넷에 접속해서 현재 저의 동호회, 카페, 홈페이지, 블로그 등을 보며 실시간으로 글을 게시하고, 댓글놀이를 즐겨왔는데요, 스마트폰은 이런 소셜 네트워크에 한층 가깝게 다가갈 수 있도록 해주는 중요한 역할을 해주고 있거든요.
    인터넷이 연결되어 있지 않았을 때의 불안감이나 답답함을 한번에 해결해주고 있습니다.

    집전화가 있고, 공중전화가 있지만, 누구나 휴대폰을 가지고 다니듯이, 요즘 우리 생활에 있어서 인터넷이 그렇게 변하고 있습니다. 스마트폰은 걸어다니는 인터넷 기능때문에 중요한 것이죠.
    다만 인터넷 기능이 필요하지 않으신 분들께서, 스마트폰을 필요해서 자발적으로가 아닌 뜬다고 하니까 공부하시려는 분들께서 부정적인 시각으로 말씀해주시는 것 같은데요, 크게... 변화를 줄 것 같아요.

    자다가 일어나서 갑자기 말이 많았습니다. 또 놀러올겠습니다. ^^

  10. Blog Icon
    샘성맨

    회사를 그만두고 앱 개발 창업을 준비하고 있는 사람으로서 research 도중 오랜만에 좋은 글을 발견한것 같아 기쁩니다.
    진입장벽이 낮은 앱 개발은 정말 개발자의 한사람으로서 전업으로 뛰어들기전에 가장 생각이 많아지는 부분입니다. 그리고 유지보수얘기를 쓰셨던데, 시장조사도중 많은 대다수 앱개발자들이 개발은 해놓고 테스트 및 유지보수같은건 신경쓰지 않는걸 볼 수 있더군요. 정말 공감가는 부분입니다. 이런 부분을 고려한 비즈니스 모델도 생각중입니다. 그리고 혼자개발하는것에 대한 한계성 또한 매우 공감갑니다. 몇몇의 인재와 함께하면 좋겠는데, 우리나라같이 대기업만 밝히는 분위기에서 벤처에 누가 쉽게 열정을 쏟으려고 할까요 솔직히 아직 회사를 그만둔건 아닌데(저도 분위기상 대기업을 왔습니다만..), 이 부분에 대해서 상당히 두렵네요. 하지만, 돈만을 위한 개발이 아닌 첫사랑을 다시 만나 연애하는 기분으로서 다시 개발을 시작한다면 어느정도의 생활은 가능할꺼라 점점 확신이 듭니다. 그 첫사랑을 지금 시대흐름이 아니면 다신 볼 수 없을것도 잘 알고 있습니다. 또한 스마트 TV 라는 블루오션시장도 보이고요. 아직 절망보다는 희망이 많아보입니다. 첫걸음부터 큰걸음을 내딪지말고 3번의 시련을 각오하고 희망을 향해 몸을 던지렵니다.

  11. 안녕하세요. 샘성맨님
    도전은 항상 아름답니다. ^^ 도전이 소프트웨어 발전의 힘입니다.
    혼자 소프트웨어를 개발하는데는 많은 어려움이 따릅니다.
    앱센터를 이용하면 도움이 좀 될 수 있을 것 같습니다.
    앞으로 도전하시는데 도움이 필요하면 부담없이 연락주세요.
    도움을 드릴 수 있으면 기쁘겠습니다.

블로그 호스팅을 Google Blogger로 이전합니다.

최근에 블로그에 보안 문제가 발생하여 좀더 안정적으로 블로그를 운영하기 위해서 Google Blogger로 이전합니다. 기존에 http://allofsoftware.net 과 http://www.allofsoftware.net..

한국어(한글) 코드 이야기 (8)

유니코드에 대해서 좀더 알아보기 전에 한국어 코드(문자세트)와 인코딩에 대해서 좀더 알아보자. 1991년에 유니코드가 탄생한 후에 유니코드는 점점 많은 개발자들이 사용하기 시작해서 영역을 넓혀가고 있다. 물론 언젠가는 유니코..

유니코드 영토 전쟁의 승리자는? (7)

이번에는 유니코드의 코드 체계에 대해서 간단하게 알아보고자 한다. 소프트웨어 국제화를 필요로 하는 개발자라면 자주는 아니지만 유니코드 내부 코드 체계를 알아야 할 때가 있다. 다양한 플랫폼에서 개발을 할 때 폰트 등과 관련하..

유니코드는 어떻게 탄생했을까? (6)

소프트웨어 국제화를 이해하기 위해서는 유니코드에 대해서 필수적으로 잘 알아야 한다. 유니코드란 말을 들어보지 않은 개발자는 없지만 관련 용어가 매우 많아서 종종 헷갈린다. 게다가 유니코드가 탄생한지 20년도 더 넘었지만 아직..

직원을 잠재적인 도둑 취급하는 회사

필자는 몇 년 전 A그룹에 강연을 하러 갔다가 곤란한 일을 겪은 적이 있다. 한국 대부분의 대기업이 그렇듯이 보안이 매우 엄격한 회사였다. 나는 직원들의 안내대로 메모리, 외장하드를 모두 빼놓고 회사로 들어갔다. 하지만 강연..

외국에서 팔리는 소프트웨어의 아키텍처 디자인 원칙 (5)

김과장은 그 동안 한국어만 지원하는 소프트웨어 A를 개발해 왔는데 최근에 사장님이 A의 일본어 버전을 만들라고 했다. 그리고 개발 기간도 한달 밖에 주어지지 않았다. 그래서 기존 소스코드를 복사해서 한국어가 들어 있는 모든 ..

소프트웨어 개발자 성장에 꼭 필요한 리뷰

우리나라 개발자들은 프로그래밍은 잘 하는데 대접을 못 받는다는 얘기가 있다. 또, 머리는 좋은데 환경이 나쁘다는 얘기도 있다. 젊은 개발자들은 외국의 개발자들에 전혀 뒤지지 않는데 나이를 먹을수록 실력이 떨어진다는 얘기도 있..

외국에 출시한 소프트웨어가 날짜 때문에 낭패 본 사연 (4)

10년차 개발자인 김과장(가상의 인물)은 최근에 소프트웨어를 영어를 지원하도록 만들었다. 어플리케이션에서 표시되는 모든 메시지(메뉴, 버튼, 다이얼로그 등)를 영어로 번역했다. 그렇게 해서 영어버전을 출시했는데 얼마 안 가서..

독일어 버전 소프트웨어란 말이 잘못된 이유 (3)

본 시리즈는 차례대로 읽으면 소프트웨어 국제화가 전체적으로 이해가 되어서 소프트웨어 개발자에게 도움이 되는 방향으로 진행하려고 하고 있다. 개발자마다 지식과 경험이 천차만별이라서 초급 개발자를 기준으로 작성하고 있다. 경영자..

소프트웨어를 외국에 출시 하면서 흔히 빠지는 함정 (2)

우리나라 소프트웨어 중에서 외국에서 크게 성공했다고 하는 소프트웨어가 있는가? 온라인 게임을 제외하고는 거의 없다. 사실 게임은 국제화, 지역화를 잘 못하더라도 큰 흉이 안 된다. 하지만 그 외의 많은 소프트웨어들은 제품이든..

티스토리 툴바