'R&D'에 해당되는 글 20건

 

 

 

이번에 다룰 개발문화 이야기는 '빨리빨리 문화'다. 

 

일을 빨리 하자는게 나쁜 건 아니다. 오히려 이런 '빨리빨리 문화' 덕분에 우리나라가 짧은 기간에 성장했을지도 모른다. 더 짧은 시간에 똑 같은 일을 해낼 수 있다는 것은 경쟁력이 있는 것이다. 우리는 그동안 많은 산업분야에서 '빨리빨리 문화'의 혜택을 입었고, 관련 노하우도 많다. 

 

그런데, 이런 '빨리빨리 문화'가 소프트웨어 분야에서는 독이 되는 경우가 많다. 실제로 독이 되는 경우를 많이 보았다. 시제품은 빨리 만드는데 본제품을 완성하는데는 시간이 훨씬 오래 걸리며 품질도 떨어지고 시간이 흐를수록 유지보수가 무척 어려워져서 제품을 포기하는 경우도 흔하다. 상황을 수습하지 못해, 회사의 종말로 이어질 때도 있다. 

 

유독 왜 소프트웨어 분야에서 '빨리빨리 문화'가 문제가 되는 것일까?  원인은 세가지로 요약할 수 있다. 

 

첫째, 소프트웨어는 훨씬 복잡하다. 다른 분야에는 미안하지만 소프트웨어는 가장 복잡한 지식산업이다. 빨리 개발해야 한다고 열심히 코딩부터 시작해서 으쌰으쌰 개발하면 아키텍처는 뒤죽박죽 되고 개발 기간도 오래 걸린다. 그렇다고 차근차근 모든 설계서를 만들고 설계서대로 개발하면 좋겠지만 그렇게 하면 웬만한 프로젝트를 마무리는데 10년쯤 걸릴 것이다. 절묘한 절충이 가장 어렵다. 

 

둘째, 소프트웨어는 예술이다. 소프트웨어 아키텍처를 만들어 가는 과정은 예술과 비슷하다. 예술은 재촉한하거나 야근을 한다고 해서 빨리, 더 좋은 결과가 나오는 것은 아니다. 수많은 요구사항과 비즈니스 전략 등을 종합하여 가장 적합한 아키텍처를 만드는데 시간이 부족하면 부실한 아키텍처가 되고 개발에 들어갔거나 유지보수시 이를 바꾸려면 비용은 100배, 1000배가 더 든다. 

 

셋째, 소프트웨어는 생명체와 같다. 소프트웨어는 건축에서 개념을 가져온 것도 많고 실제 비슷한 것도 많다. 하지만 빌딩은 일단 완공되면 100년동안 기본 구조가 거의 안바뀌지만 소프트웨어는 보통 출시되도 계속 성장한다. 소프트웨어는 출시 후부터 초기 개발비용보다 약 4배의 돈이 더 드는 것으로 알려져 있다. 하지만 아키텍처가 부실하다면 4배가 아니라 40배의 비용을 더 들이고도 업그레이드 및 유지보수가 어려울 수 있다. 

 

 

 


 

그럼, '빨리빨리 문화'가 문제니 차근차근 천천히 개발을 해야 할까? 그건 전혀 아니다. 수많은 성공한 글로벌 소프트웨어 회사들은 천천히 개발을 해서 성공한 것이 아니다. 소프트웨어 개발의 최대 미덕은 소프트웨어를 빨리 개발하는 것이다. 소프트웨어 개발을 조금이라도 느리게 하는 모든 방법론, 규칙, 제약, 프로세스는 잘못된 것이다. 

 

'빨리빨리 문화'가 소프트웨어 개발을 오히려 더 느리게 하고 다른  문제들도 일으키기 때문에 문제라는 것이다. '빨리빨리 문화'는 소프트웨어 개발 프로젝트에서 다음과 같은 것들을 유발한다. 

 

-프로젝트 지식, 정보, 자료 공유의 부재 
-부실하고 확장성이 떨어지는 아키텍처 
-특정 개발자에게 종속됨 
-수많은 중복된 코드 
-개발자의 인간다운 삶과 성장 포기 
-점점 증가하는 유지보수 비용 

 

이런 현상은 개발 방법론과는 상관없이 벌어진다. SRS(Software requirements specification) 형태로 스펙을 제대로 쓰던 TDD를 하던 이는 모두 소프트웨어를 빨리 개발하기 위한 방법이다. 문서작성, 코드리뷰, 프로세스 등 모든 것은 소프트웨어를 빨리 개발하려는 것인데 이런 것들이 개발을 느리게 하니 그냥 개발하자고 하는 것은 완전히 착각이다. 

 

물론 이런 방법들이 소프트웨어를 빨리 개발하는데 도움이 되려면 뛰어난 아키텍트도 필요하고 회사의 개발문화 성숙도도 높아야 한다. 

 

빌딩을 빨리 만들겠다고 벽돌부터 서둘러 쌓아야 한다고 생각하는 사람은 없을 것이다. 기초공사와 설계가 잘되어야 어떤 방식으로든 빌딩을 빨리 만들 수 있다. 소프트웨어도 견고하고 확장성이 있는 아키텍처가 있어야 요구사항 변경에 대응이 잘되고 협업이 용이하며 개발 기간을 단축하고 비용도 절약할 수 있다. 

 

사실 무리한 일정 압박이 아키텍처에 큰 문제를 일으킨다는 것을 개발자 대부분은 잘 알고 있다. 그럼에도 '빨리빨리 문화'를 가속화시키는 주범은 따로 있다. 바로 경영자와 고객이다. 

 

대부분의 경영자에게 단기 성과는 생존 문제다. 회사 오너라면 조금 낫지만 많은 경영자들은 2년, 3년 단기 계약을 한다. 그 기간 안에 가시적인 성과를 내지 않으면 재계약이 어려워질 수 있다. 소프트웨어에 대한 깊은 이해도 부족하지만 미래를 고려할 시간은 더욱 없다. 6개월, 1년안에 성과를 내는 것이 가장 중요한 경영자는 영업이 가장 중요하고 단기 매출에 집착하며 아키텍처는 신경 쓸 여유가 없다. 

 

제대로 된 CTO가 있다면 CEO가 그렇게 마음대로 할 수는 없지만 우리나라에서는 CTO가 제대로 역할을 하기 어렵다. 

 

고객도 문제다. 우리나라 고객들은 이중적이다. 우리나라 개발사에는 버그를 당장 내일 고쳐줄 것을 요구하지만 글로벌 회사는 6개월 후에 고쳐주는 것을 고마워한다. 글로벌 회사는 아무리 얘기를 해도 빨리 고쳐주지 않는 다는 것을 알기 때문이다. 

 

우리나라 고객들은 개발자가 고객 회사에 들어와서 일해주기를 원한다. 스펙을 제대로 정리하고 효율적인 커뮤니케이션을 통해서 개발하는데 익숙하지 않기 때문에 옆에 앉혀놓고 종을 부리듯이 개발하기를 원한다. 

 

국내에서는 그런 고객의 입맛에 맞춰줘서 성공한 사례가 꽤 있다. 이런 문화는 국내 시장의 진입장벽이 되기도 한다. 그렇게 해서 우리나라에서는 1위에 등극했지만 이를 바탕으로 글로벌 시장으로 나아가는데는 큰 문제가 있다. 

 

개발문화가 비효율적이고 아키텍트의 역량이 떨어져서 세계 시장에서 패하는 경우가 많다. 그럼 외국 고객은 어떨까? 다는 아니지만 대부분 버그를 내일 고쳐 준다고 하면 의아하게 생각한다. 특히 매우 중요한 시스템이라면 이런 개발사의 신속한 대응은 오히려 개발사에 대한 신뢰를 떨어뜨리기도 한다. 

 

우리나라 개발사끼리는 이러한 고객 요구사항에 서로 잘 맞춰주겠다고 진흙탕싸움을 하고 있기 때문에 모두 다 힘들어지고 그 폐해는 고스란히 개발자에게 돌아간다. 개발자는 인간다운 삶을 포기해야 하기도 하고 그런 개발 환경에서는 개발자로서 성장하기도 힘들어진다. 

 

'빨리빨리 문화'가 바뀌기 어려운 것은 사실이다. 고객도, 경영자도, 개발자도 바뀌어야 한다. 내가 어떻게 세상을 바꾸겠는가? 하지만 세상을 바꾸는 첫걸음은 내가 바뀌는 것이다. 내가 바뀌는 것의 시작은 깨닫는 것이다. 지금은 당장 나만 바뀌면 나만 손해를 볼 것이다. 

 

하지만 내가 바뀌고 동료가 바뀌지 않으면 '빨리빨리 문화'는 영원히 바뀌지 않을 것이다. 회사에서 아키텍처의 중요성을 깨닫고 아키텍트를 키우고 영업과 개발의 균형을 유지하는데 노력하고 급하게보다는 제대로 빨리 개발하기 위한 방법들을 강구해야 한다. 

 

기반시스템, 방법론, 프로세스 모두 적절히 필요하다. 다른 여러가지 개발문화의 성숙도를 높여가는 것도 '빨리빨리 문화'를 고치는데 도움이 된다. 결국 우리가 바꿔 나가야 한다. 

 

'닭이 먼저냐 달걀이 먼저냐' 이슈와 비슷하지만 개발문화 성숙도 문제를 깨닫는 것만으로도 의미가 크다. 문화란 글이 아니라 경험을 통해서 배워야 하고 경험자에게 배워야 시행착오를 줄일 수 있다. 꾸준히 관심을 가지고 익히는 자세가 필요하다.


출처 : 소프트웨어 경영/공학 컨설턴트의 소프트웨어 개발 이야기
by 전규현

 

 

 

 


 

블로그 이미지

(주)싸이크로스

(주)싸이크로스 www.sycros.com

댓글을 달아 주세요

 

 

 

 

 

본격적으로 소프트웨어 개발 문화에 대해서 얘기해보자.  첫번째는 ‘공유의 문화’다.


 회사마다  차이는 있지만  소프트웨어  회사에서  부실한  공유 문화는  많은  부작용의  원천이다. 여러 사람과 정보를 공유하는 것에 따른 장점은 여러가지다.  다양한 시각을 가진 이들의 의견이 반영되면서 프로젝트 리스크가 감소되는 건 물론 개발자는 자신이 해왔던 과거업무의 속박에서 벗어날 수 있다.


반대로 공유문화가 부실한 회사는 왜곡된 의사결정으로 프로젝트 리스크가 커지고, 아키텍쳐나 제품은 뒤죽박죽이 되는 경우가 많다. 개발자는 자신이 과거부터 해온 일들에 발목이 잡혀 고참이 되도 유지보수에 바쁘고 신참에게 일 시키기도 어렵다. 본인 스스로 고급개발자로 성장하기 어려운 구조라고 하겠다.


개발자가 수백명, 수천명인 회사나 개발자가 10명인 회사나 효율적인 공유없이 각자 일하는 것은 매한가지이다. 개발자가 수천명인 회사내부에서는 팀이 수백개가 아니고 회사가 수백개 있는 것 같은 현상이 벌어지기도 한다. 팀 내부 인원끼리는 서로 내용을 좀 아는데 다른 팀과는 공유가 매우 어렵다. 이를 개선하고자 개발 프로세스를 점점 복잡하게 만들기도 하지만 문화와 균형을 이루지 않은 개발 프로세스는 형식적으로 작동해서 효율도 떨어지고 개발자들에게는 짐이 될 뿐이다.


 겉으로는 공유를 주장하면서도 속으로는 공유를 꺼리는 개발자가 은근히 많다. 개발 내부의 아키텍처 문제나 골치 아픈 이슈들을 숨기고 시한폭탄으로 놔두는 경우도 있고, 바쁘다는 핑계로 또는 다른 사람은 이해하지 못할 정도로 어렵다는 이유를 대고 정보를 꼭 쥐고 있는 경우도 있다.


 전반적으로 공유문화가 부실하게 된 것은 현재 개발자들의 책임은 아니다. 원래 문화라는게 우리의 선조, 선배들이 만들어 놓은 것을  따르면서 아주 약간씩 바뀌는 것이다. 개발문화도 그렇다. 지금까지 선배들이 그런 환경에서 그렇게 일해 왔기 때문에 그런 문화가 형성되었고 우리도 거기에 적응해서 일하고 있는 것이다.


 문화가 바뀌기 어려운 이유는 나 혼자 노력해서는 안되기 때문이다. 다른 사람들은 공유를 위해서 노력하지 않고 나 혼자 애를 쓰면 나만 두배로 손해를 본다. 이는 ‘죄수 딜레마’와 비슷하다.


두 명의 사건 용의자가 체포되어 서로 격리되어 심문을 받으면 서로 간의 의사소통은 불가능하다. 이들은 자백 여부에 따라 다음의 선택이 가능하며 용의자들은 이를 알고 있다.


둘 중 하나가 배신하여 죄를 자백하면 자백한 사람은 즉시 풀어주고 나머지 한 명이 10년을 복역해야 한다.

둘 모두 서로를 배신하여 죄를 자백하면 둘 모두 5년을 복역한다.

둘 모두 죄를 자백하지 않으면 둘 모두 6개월을 복역한다.

 이 경우 서로를 믿고 협동하면 서로 이익이 되지만 대부분 서로 배신을 선택함으로써 나쁜 결과를 초래한다. 공유문화도 마찬가지다. 혼자서 공유한다고 애를 써도 다른 사람이 공유를 하지 않으면 혼자 고생만 하는 것이기 때문에 결국 서로 공유를 하지 않음으로써 서로 손해를 보는 결과를 선택한다는 것이다.

 

 


 

 공유문화는 소프트웨어 개발에 너무 중요하기 때문에 포기할 수는 없다. 그렇다고 노력하지 않고 효율적인 공유문화를 가질 수는 없다. 그냥 흘러가는 대로 놔두면 ‘죄수딜레마’는 어김없이 찾아온다. 개발자 입장에서는 능동적이고 주도적으로 공유문화를 만들어가기 어렵다. 일단은 습관이 되지 않은 상태에서 공유를 하려면 매우 어렵고 혼자만 공유를 잘하면 개발에 있어서 자신에 대한 의존도가 떨어지기 때문에 고민을 하기도 한다.


반대로 공유를 안하면 자신에 대한 의존도는 높아지지만 본인이 한 일에 발목이 잡혀서 성장이 어렵다. 여기까지 생각하는 개발자는 그리 많지 않다. 경영진이나 개발자나 모두 서로를 위해서 필요성을 깨닫고 제도적으로 의식적으로 오랫동안 각고의 노력을 해야 한다. 일단 문화가 자리잡고 나면 의식하지 않아도 저절로 공유를 하게 된다.


그러면 이제부터 많은 사람들이 왜 노력을 해도 공유에 실패를 하는지 2% 차이는 무엇인지 알아보자.


 첫째, 말로 하는 것보다 글로 적는데 익숙해져야 한다.


말로 대화하면서 개발하는 것이 더 효율적이라고 믿는 사람이 많지만 필자는 글로 적는 것이 더 효율적이라고 믿고 있다. 말은 오해도 많고 매번 다른 사람에게 다시 설명해야 하고 시간이 지나면 잊어버린다. 글로 써야 많은 사람에게 공유가 되고 리뷰가 가능하며 도움을 받을 수 있다. 글로 하는 커뮤니케이션은 기본적으로 공유의 준비가 다 되어 있는 것이다.


대화는 가장 비싼 수단이며 휘발성이 강하다. 대화가 아니면 해결하기 어려운 꼭 필요할 때와 대화가 가장 효율적일 때만 사용해야 한다. 글을 쓰는데 익숙하지 않은 개발자는 무조건 장황하게 쓰거나 개발자만 아는 어려운 용어를 사용해서 다른 사람이 이해하기 어렵게 만든다. 또 외계인의 언어처럼 도저히 이해가 안되는 문장구조를 사용하기도 한다.


처음부터 글쓰는 것은 거부하기도 한다. 개발문서는 소설처럼 감동을 줘야 하는 것이 아니기 때문에 잘만 훈련하면 개발자도 충분히 잘 쓸 수 있다. 신입 때부터 문서를 작성하는데 익숙해지면 된다. 그런 기회 없이 이미 고참이 되었다면 지금이라도 시작하면 된다. 깨닫는 것이 어렵지 지금이라도 노력하면 충분히 가능하다.


 둘째, 과도한 프로세스는 오히려 독약이다.


 대기업에서 많이 벌어지는 일인데, 현재 역량이나 문화수준을 훨씬 뛰어넘는 과도한 시스템과 프로세스를 도입해서 강요하곤 한다. 이런 경우 겉으로는 규칙을 지키고 비싼 시스템을 착실히 쓰는 것 같지만 속을 보면 형식적으로 따르고 흉내만 내서 효율은 오히려 더 떨어진다. 이런 일이 벌어지는 이유는 스스로의 역량이나 문화 수준을 과대평가 하기 때문이기도 하다.


제대로 된 CTO의 부재도 한몫 한다. 실전 경험이 부족한 SW 프로세스팀은 밑져야 본전 식으로 프로세스를 복잡하게 만들고 많은 문서를 요구하곤 한다. SW 프로세스팀도 이렇게 밖에 할 수 없는 많은 고충이 있다. 많은 문서 중에서 프로젝트에 실질적으로 필요한 문서는 한두개에 불과한 경우가 대부분이지만 회사에서는 나머지를 쉽게 포기하지 못한다. 이러다 보니 개발자들은 문서 따로 개발 따로 진행을 하고 문서는 개발에 별 도움도 안되고 공유의 목적으로도 의미가 없게 된다. 이런 식으로 문제가 발생하면 프로세스를 더 복잡하게 만드는 악순환이 진행된다.


 해결책은 스스로의 역량과 문화 수준을 정확하게 진단하는 것이다. 그리고 거기에 걸맞는 시스템, 프로세스를 도입해야 한다. 역량에 비하여 프로세스가 단순한 것은 큰 문제가 안되지만 반대의 경우는 더 비효율적이다. 지금처럼 과도한 프로세스를 계속 발전시키면 악순환에서 벗어나지 못하고 결국에는 10배 비효율적으로 개발을 해야 한다. 결코 프로세스로 모든 것을 해결할 수 없다는 것을 명심하자.


 셋째, 개발자 보고 알아서 잘 해보라고 하면 안된다.


 풀뿌리식으로 개선이 될 수 있는 사안이 아니다. 시스템과 프로세스도 필요하고 경영진의 의지와 후원이 절대적이다. 가장 중요한 것은 공유문화를 이끌 리더가 필요하다는 것이다. CTO급의 인물이 있어서 흐지부지 되기 쉬운 공유 문화 개혁에 꾸준한 추진력을 실어줄 수 있어야 한다. 역량 수준에 따라서 여러가지 시스템도 필요하다.


이슈관리시스템, 형상관리시스템, 코드리뷰도구, 위키, 지식관리시스템, 정보포털 등 여러가지가 있지만 모두 필요한 것은 아니다. 그리고 꼭 비싼 제품이 좋은 것은 아니다. 회사의 규모와 개발하는 소프트웨어의 성격에 따라서도 적절한 시스템이 다르다.


전문가의 도움을 받아서 가장 효율적인 프로세스와 시스템을 도입하는 것이 좋다. 프로세스와 시스템이 있다고 다 되는 것은 아니다. 임직원들의 마인드를 바꾸기 위해서 노력도 해야 하고 공유에 익숙하지 않은 직원들에게 효율적인 공유방법을 꾸준히 교육을 시키고 코칭을 해야 한다. 이는 매우 오래 걸리는 일이고 그래서 내부에 공유 문화 리더가 필요한 것이다.


 넷째, 나중에 몰아서 공유하면 실패한다.


 일기를 몰아서 쓰듯이 공유도 몰아서 하면 실패한다. 공유를 위해서 문서를 만들고 시스템에 기록을 하는 것이 목적이 되면 안된다. 이것들은 소프트웨어를 개발하는 과정이고 이렇게 개발을 해야 가장 빨리 효율적으로 개발할 수 있기 때문에 문서를 만들고 공유를 하는 것이다.


공유를 위해서 숙제를 하듯이 정리를 해서 시스템에 지식을 올리고 공유하는 것보다 매 순간 필요한 것들을 즉시 등록하는 것이 좋다. 공유할 것, 물어 볼 것, 의논해야 할 것들을 일단 적당한 시스템에 올려 놓고 진행을 하는 것이다. 그러면 자연스럽게 과정이 공유가 된다. 즉, 공유는 개발의 과정이고 일부이지 산출물, 부산물들이 아니다.


공유를 위해서 산출물을 만들어야 한다고 생각하는 순간 공유는 실패하고 산출물도 제대로 만들어 질리가 만무하다. 이렇게 만들어진 문서는 나중에 유지보수 시에도 활용도가 뚝 떨어진다. 공유목적으로도 실패한 것이다. 개발과정이 자연스러운 공유의 과정이 되도록 해야 한다.


 다섯째, 모든 사람이 다 너무 바쁘면 안된다.


 모든 개발자가 호떡집에 불난 것 같이 바쁜 회사가 많다. 가끔은 신입 개발자는 한가하고 고참들이 더 바쁜 경우도 있다. 이런 회사는 대부분 공유에 실패한다. 불 끄느라고 정신이 없어서 나머지는 눈에 들어오지도 않는다. 시니어 엔지니어가 될수록 시야도 넓어지고 생각도 많이 하고 여기저기 관여도 많이 해야 하기 때문에 정신없이 바쁘면 안된다.


손이 바쁘면 뇌는 느려진다. 코딩하느라고 바쁜 신입 개발자는 많아도 큰 문제가 없지만 고참들은 창의적인 생각도 많이 하고 타부서의 프로젝트도 파악하고 회사의 비즈니스도 알아야 하기 때문에 충분한 시간적 여유가 있어야 한다.고참 개발자는 공유를 가장 많이 하기도 하고 공유의 수혜자이기도 하다. 모든 사람이 모든 정보를 다 알 수는 없다. 자신의 레벨에서 공유하고 알아야 할 정보가 다르다. 고참 개발자의 손이 한가해지려면 이전에 공유를 잘 해왔어야 한다. 즉, 공유의 선순환이 필요하다.


 여섯째, 보안보다 공유가 우선이다.


 소프트웨어는 설계도면이 핵심이 아니다. 구성원들의 지식 공동체가 핵심이며 문서, 시스템, 경험, 지식의 복합체가 소프트웨어 회사 기술의 실체이다. 대부분의 SW회사는 HW분야에서 설계도면 빼돌리 듯 기술을 빼돌릴 수가 없다. 우리나라에서는 빈약한 공유문화 속에서 소수의 개발자가 거의 모든 정보를 독점하기 때문에 종종 기술을 빼돌리는 일이 벌어진다. 이런 상황에서는 보안을 아무리 강조해도 기술이 새나가는 것을 막을 수는 없다.


드물게 보안이 더 중요한 SW회사도 있기는 하지만 극소수에 불과하다. 보안에 대한 과도한 우려 때문에 공유를 너무 불편하게 하는 회사가 의외로 많다. 보안이 별 이슈도 아닌 회사도 공유에 거부감이 있는 직원의 주장에 넘어가서 공유를 포기한 회사도 많다. 훌륭한 오픈소스가 판치는 마당에 소프트웨어 회사에서는 숨길 것이 그렇게 많지 않다. 특수한 분야의 몇몇 회사를 제외하고는 모든 직원에게 모든 정보를 오픈해도 별 문제가 안된다. 보안을 과도하게 강조하여 공유에 제약을 가하기 시작하면 공유는 반쪽짜리가 되어서 효율은 엄청나게 떨어지게 된다.


 공유문화라는 것이 단어는 다들 잘 알고 있으면서 잘 안되는 대표적인 개발문화이다. 경험해보지 않으면 무엇을, 어떻게, 얼마나 자세히, 누구에게 공유하는데 잘 감이 잡히지 않는다. 위 여섯가지 가이드도 실전 적용을 해보고 자세히 들어가보면 아리송한 부분들이 많을 것이다. 그래도 시작이 반이라고 일단 시작을 해보자. 너무 큰 욕심은 경계하자.


회사에서는 꾸준히 투자를 해야 하며 처음에는 제도적으로 시작을 했다가 점점 습관화를 해 나가야 한다. 오래 걸리는 일이니 너무 근시안적으로 보지 말고 꾸준히 노력해야 한다.

 

 

출처 : 소프트웨어 경영/공학 컨설턴트의 소프트웨어 개발 이야기
by 전규현

 

 

 

블로그 이미지

(주)싸이크로스

(주)싸이크로스 www.sycros.com

댓글을 달아 주세요

 

 

 

 우리나라에서 소프트웨어 개발이 3D 취급을 받는 이유는 여러가지다. 끝을 모를 야근과 낮은 대우 등도 포함되겠지만 좀더 근본적인 이유는 따로 있다.  낮은 생산성 때문이다. 소프트웨어를 개발해서 회사가 돈을 많이 벌고 세계적으로 성공하는 소프트웨어가 많이 나온다면 생산성의 핵심인 개발자에게 당연히 높은 대우를 해주게 마련이다.


 하지만 우리나라에서는 크게 성공한 소프트웨어 회사가 많지 않다. 그리고 소프트웨어 회사의 수익률이 별로 높지 않기 때문에 소프트웨어 개발자에게 좋은 대우를 해줄 수 없다. 결국 이런 소프트웨어 개발에 대한 낮은 대우를 극복하기 위해서는 성공하는 소프트웨어, 성공하는 회사가 많이 나와야 한다.


 그럼 성공하는 소프트웨어 회사와 그렇지 못한 회사를 가르는 결정적인 차이는 무엇일까? 판단의 요소는 기술적인 것 외에도 많다. 좋은 아이디어, 적절한 타이밍, 경영, 마케팅 등이 더 중요하지만 이런 것들은 내가 논할 주제는 아니다. 나는 같은 조건에서도 성공하기도 하고 실패하기도 하는 차이가 무엇인지 알아보고자 한다. 성공하는 회사의 특징을 가진 회사가 많다면 성공하는 소프트웨어가 더 많이 나오고 우리나라에서도 소프트웨어 개발이 좀더 좋은 대우를 받을 수 있을 것이다.


 하지만 회사마다 제품이 다르고 환경이 달라서 직접적인 비교는 매우 어렵다. 같은 제품을 만드는 회사라도 다른 요소로 인해서 성공과 실패가 갈렸을 수도 있다. 그런데 필자가 알고 있는 비교하기 좋은 사례가 하나 있어 이를 소개한다.


미국의 유명한 글로벌 소프트웨어 업체가 하나 있다. 이 회사는 여러 나라에 지사를 설립했다. 물론 한국에도 지사를 설립해서 개발자를 채용했다. 한국에서 채용한 개발자들은 본사의 서비스를 지역화(Localization)하거나 한국에 특화된 서비스를 개발했다. 미국 본사에서는 한국에서도 소프트웨어를 개발할 때 본사의 프로세스를 따르도록 종용했으나 한국 개발자들은 이를 따르지 않았다. 한국의 개발자들이 보기에 본사 프로세스는 너무 복잡해 보였다.


이와 관련해 처음에는 본사와 한국 개발자들간 충돌이 있었으나 상황은 곧 바뀌었다고 한다. 본사에서 한국 개발자들의 놀라운 개발 속도에 깜짝 놀라서 더 이상 본사의 프로세스를 강요하지 않았다. 초기에는 척척 빠른 속도로 개발을 하다보니, 모든 상황이 좋았다고 한다. 그런데 몇 년이 지나자 완전히 상황이 또 바뀌었다고 한다. 개발이 너무 느려진 것이다. 그 당시 본사는 호주에도 지사가 있었는데, 한국 지사와 비슷한 일을 하고 있었다.


한국 지사는 호주 지사보다 10배 가까운 개발자를 보유하고 있었고, 개발자들이 야근을 거듭해도 호주지사의 개발속도를 따라가지 못했다고 한다. 자세히 파헤쳐보면 더 많은 사연들이 있겠지만 맥락만 봐도 우리나라에서 소프트웨어를 개발하는 방식의 낮은 생산성을 짐작하게 한다.


 물론 모든 회사가 문제가 있다는 것이 아니다. 우리나라에도 좋은 개발문화를 가진 회사가 많다. 상대적으로 그렇지 않은 회사가 많기 때문에 제기하는 문제로 이해해 줬으면 하는 바람이다.


나는 한국지사의 개발자들이 본사의 개발 프로세스를 따르지 않은 것이 문제의 주된 원인이라고 생각하지 않는다. 이렇게 대응한 한국의 개발자들을 비난하려는 것이 아니다. 한국 개발자들은 몸에 베어 있는 개발문화 때문에 본사 프로세스를 따르기도 쉽지 않다. 그런 개발문화와 습관을 익히게 된 우리의 개발 환경이 문제인 것이다.


한국에서 개발을 하다가 실리콘밸리 소프트웨어 회사에 취직을 한 개발자 중에는 개발 문화와 프로세스에 적응하는데 힘들어하는 사람들이 많다. 하지만 문화란 원래 작은 부분이 큰 부분에 흡수되듯이 한 개인은 모든 사람이 공통으로 행동하는 개발문화에 흡수되기 마련이다. 반대로 실리콘밸리의 아무리 뛰어난 개발자라도 우리나라에 오게 되면 꼼짝없이 한국식 개발문화에 적응해야 한다. 본인의 방법으로는 더 이상 어찌해볼 수 없는 상황이 된다.


필자는 한국적인 개발문화부터 실리콘밸리의 개발문화와 관료화된 거대 개발프로세스까지 직간접적으로 다양한 경험을 한 덕에 이를 서로 비교할 수 있다. 그래서 앞으로 효율적인 개발문화에 대해서 구체적으로 얘기를 해보고자 한다.


문화란 한 사회의 구성원들의 주요한 공통된 행동 양식이다. 개발문화는 소프트웨어를 개발하는 구성원들의 공통된 생각과 행동 양식이다. 프로세스처럼 명문화되어 있지는 않지만 대체로 그렇게 행동을 하는 것을 말한다. 우리나라의 개발문화는 형편없다고 주장하려는 것이 아니다. 우리나라의 문화가 더 훌륭한 부분도 있고 장점도 많다. 사실 문제가 되는 부분은 2%에 불과할 수도 있다.


이런 결정적인 결과의 차이를 만들어내는 주요 개발문화의 차이를 비교해보자.


개발 프로세스와 개발문화는 서로 보완적이며 개발문화 없이 효율적인 개발프로세스를 만들기 어렵다. 개발문화가 있다고 개발 프로세스가 필요 없는 것도 아니다. 반대로 아무리 정교한 개발 프로세스가 있어도 개발문화가 뒷받침되지 않으면 개발프로세스는 방해만 될 뿐이다. 그만큼 개발문화는 개발 프로세스보다 중요하다.


그럼 이런 차이를 만드는 개발 문화에는 어떤 것들이 있을까? 지금은 하나씩 나열만 해보고 다음 회부터 각각의 사항에 대해 좀더 자세히 풀어볼까 한다.


첫째, 공유 문화의 부족이다.


사실 우리나라에도 공유문화가 없는 것은 아니다. 하지만 결정적인 차이가 있다. 그 차이를 앞으로 얘기해보겠다.


둘째, 빨리빨리 문화다.


장기적인 고려 없이 무조건 빨리 하는 것은 단기적으로는 빠른 성과를 낼 수 있어도 장기적으로는 몇배 더 느려진다. 다른 산업분야에서는 톡톡히 효과를 봤어도 소프트웨어는 워낙 복잡한 지식 산업이라 빨리빨리 문화가 종종 큰 문제를 야기한다.


셋째, 전문가 vs. 만능 개발자이다.


소프트웨어 산업에서는 전문가에 대한 인식이 떨어진다. 뭐든지 잘하는 만능 개발자를 선호하며 그러다 보니 뛰어난 개발자도 본연의 업무인 개발에 집중하지 못하고 다른 일에 휘둘리다보니 회사는 효율이 떨어지고 개인의 캐리어는 발전하지 못한다.


넷째, 사람 중심 vs. 시스템 중심이다.


다른 분야도 마찬가지이지만 사람 중심의 개발은 리스크를 증가시키며 대체도 어렵게 만든다. 대체 못하는 개발자는 회사와 개발자 서로가 서로의 발목을 잡는 상황이 된다.


다섯째, 규칙 준수 문화 부족이다.


사회 전반의 문제지만 소프트웨어 회사에서는 규칙을 무시하는 사람들이 많다. 특히 조직의 윗선에서 이러한 현상이 더 심각해진다.


여섯째, 서열 중심 문화이다.


전통적으로 수직적인 조직문화가 소프트웨어 개발에는 문제가 된다. 어떻게 해야 이를 극복할 수 있을지 알아보겠다.


일곱째, 낙후된 토론 문화이다.


요즘은 토론 위주의 교육에 신경을 많이 쓰면서 개선되고 있지만 여전히 토론문화는 많이 부족하다.


우선 생각나는 것은 이 정도이며 앞으로 이것들을 포함하여 개선해야 할 여러 개발문화 대해서 하나하나 구체적으로 얘기를 해보고자 한다. 새로운 내용이 있으면 계속 추가해 나갈 계획이다.


그런데 이런 얘기를 시작하면 종종“우리도 해봤는데 안되더라는 얘기를 많이 듣는다. 우리도 공유해보려고 했는데 잘 안 안된다. 우리와는 안맞는다, 그렇게 피해의식을 가진 선배개발자들이 많아서 새로운 시도가 처음부터 막히는 경우가 많다. 대부분은 잘못 시도했거나 의지가 부족해서 실패한 경우가 많다. 이렇게 피해의식이 가득찬 회사는 바뀌기 어렵고 그 끝은 뻔하다. 그렇지 않고 개발문화를 조금씩 바꿔가고 싶은 사람들에게는 도움이 되길 바란다.


개발문화는 조직 전체를 바꿔야 하는 것이기 때문에 한명의 개발자가 몸부림친다고 쉽게 바뀌지는 않는다. 경영자나 중간관리자가 움직여줘야 한다. 회사를 움직일 수 있는 경험과 힘이 있어야 변화를 시켜 나갈 수 있다. 이런 분들에게도 많이 공유가 되면 좋겠다.


워낙 광범위한 주제이기 때문에 독자 여러분들과 많은 의견을 나누면서 얘기를 발전시켜나가면 좋겠다. 구체적인 얘기가 시작될 다음 칼럼에도 많은 관심 부탁드린다.

 

 

출처 : 소프트웨어 경영/공학 컨설턴트의 소프트웨어 개발 이야기
by 전규현

 

 

 

 

블로그 이미지

(주)싸이크로스

(주)싸이크로스 www.sycros.com

댓글을 달아 주세요

 

 

 

 

최근에 국내 유수의 소프트웨어 회사들의 구조조정 회오리를 보면 착찹한 생각이 든다. 척박한 우리나라 소프트웨어 환경에서 참신한 개발문화를 도입하고 새로운 모습을 보여주려고 했던 회사들이어서 더욱 안타깝다.


필자는 이런 현상의 결과와 겉모습만 말고 다른 시각에서 좀 더 근본적인 원인을 살펴보고자 한다.


3D 취급을 받고 있는 국내 소프트웨어 개발자들은 잘나가는 실리콘밸리의 소프트웨어 회사들과 높은 연봉을 받는 소프트웨어 개발자들이 부럽지 않을 수 없다. 종종 그런 회사들의 끝내주는 개발 환경이 부러움을 사곤 한다.


공짜 점심, 자유 출퇴근 제도, 공짜 커피, 편안한 사무실, 환상적인 휴게실/오락실/수영장, 선택 가능한 재택근무 등이 그것이다. 물론 회사마다 다르기는 하다.


우리도 개발자들에게 이런 공짜 점심 등의 혜택과 환경을 제공하면 개발자가 행복해질까? 회사는 더욱 성과를 낼 수 있을까? 뛰어난 개발자들이 모여들까? 





단순히 겉모습만 따라 하는 것은 단기적으로 효과가 있을지 모르지만 장기적이고 근본적으로는 해결책이 아니다.


여기서 우리는 착각하는 것이 있다. 그들이 제공하는 끝내주는 개발환경은 공짜가 아니다. 개발자가 예뻐서 주는 것이 아니다. 그들의 환경, 개발 문화, 개발 프로세스에 맞게 가장 성과를 잘 낼 수 있는 환경을 제공하고 있는 것이다. 


사무실 주변에 식당이 널려 있는 우리나라와는 다르게 실리콘밸리에서는 차를 타고 점심을 먹으러 가거나 샌드위치를 사다 먹어야 한다. 매번 차를 타고 점심을 먹으러 가는 것은 엄청난 시간 낭비이기 때문에 회사에서 공짜 점심을 제공하는 것이 회사에 더 이익이다. 실리콘밸리 회사들은 공유의 문화를 기반으로 수많은 리뷰가 있고 얼굴을 보지 않고도 효율적으로 일할 수 있는 프로세스와 시스템이 갖춰져 있다. 재택근무와 자유 출퇴근을 통해서 뛰어난 개발자를 효율적으로 활용할 수 있다. 이런 끝내주는 환경은 개발문화와 프로세스가 맞물려 나온 결과물이지 목적은 아니다. 


우리나라에서는 환경은 전혀 그렇지 않은데 그 결과나 겉모습만 따라 하면 회사가 잘 되기는커녕 자칫 악화를 초래할 수도 있다.


내가 생각하는 개발자가 진정으로 행복하게 일할 수 있는 환경은 좀 다르다. 개발자가 합리적으로 일할 수 있는 환경이 행복한 개발자가 될 수 있는 환경이라고 생각한다.


합리적인 커뮤니케이션이 가능하고, 개발자의 기술적인 의견이 존중되고, 적절한 개발 일정이 믿어지고 보장되며, 필요한 적절한 리소스가 제공되며, 빈번한 요구사항 변경으로 수많은 야근과 아키텍처가 산으로 가는 일이 없고, 개발자의 노력에 대한 적절한 보상이 이루어지고, 개발자 경력이 보장되는 환경이다. 물론 개발자도 그렇게 할 수 있는 역량이 있어야 한다.


좋은 복지 조건은 뛰어난 개발자를 유치하는데 도움이 되지만 아무리 뛰어난 개발자가 있다고 하더라도 비합리적인 환경에서 일한다면 효율적으로 개발이 되지 않을뿐더러 회사가 어려워 지면 좋은 복지가 오히려 회사의 발목을 잡는다.


나는 공짜 점심을 주는 것보다 경영진이 소프트웨어에 대해 좀더 이해를 하고 아무 때나 함부로 요구사항을 바꾸지 않고 합리적인 개발일정이 받아들여지면 좋겠다. 나는 공짜 커피보다 더 빠른 PC와 개발에 꼭 필요한 기반시스템에 투자를 해줬으면 좋겠다. 그것이 개발자인 나를 더 행복하게 만든다.


실리콘밸리 회사를 따라 가려면 겉모습보다는 그들의 개발 문화를 먼저 따라 하자. 공짜 점심은 약간의 돈만 있으면 쉽게 제공할 수 있지만 개발 문화를 따라 하는 것은 그보다 10배 100배 더 어렵다. 결실을 보는데 시간도 훨씬 오래 걸린다. 개발 문화를 따라 하는 방법은 책을 보고 배우기 어렵기 때문에 제대로 하더라도 5년, 10년 이상 걸릴 일이다. 그들이 50~60년 걸쳐서 쌓아온 문화를 단시간에 따라 잡기는 어렵다.


많은 회사들이 중요한 개발 문화 중 하나인 공유 문화를 따라 하려고 했지만 대부분은 겉모습 흉내만 내다가 정착에 실패를 했다. 또한 문화의 핵심은 모른 채 겉으로 드러나는 기법들만 쫓다가 회의에 빠져들기도 한다. 이렇게 실패한 경우에는 시도하지 아니한 만 못한 경우도 많다. 이도 저도 아니고 어중간해서 더 혼란스럽게 된다.


나름대로 깨어 있다는 개발자들도 의욕은 넘치지만 자수성가로 성장한 탓에 동료들을 이끌어서 효율적인 개발문화를 정착시키기에 한계를 느끼고 좌절하기 일쑤다.


제발 겉멋들어서 겉모습과 기법만 따라 하지 말고 진짜로 개발자가 행복해 할 수 있는 환경을 만들어 보자. 그것이 처음에는 힘들고 더 오래 걸리더라도 제대로 될 길일 것이다.


가끔 왜 두루뭉술하게 얘기를 하고 구체적인 방법을 알려 주지 않냐고 하는 사람들이 있다. 이런 짧은 글로는 방법을 구체적으로 알려주는 것은 불가능하다. 태권도를 글로 알려줄 수 없듯이 개발문화도 실전 경험을 많이 한 선배들의 코칭을 받아 직접 몸으로 부딪혀 보고 경험해 봐야 하는 것이다.

 

 

출처 : 소프트웨어 경영/공학 컨설턴트의 소프트웨어 개발 이야기
by 전규현

 

 

 

블로그 이미지

(주)싸이크로스

(주)싸이크로스 www.sycros.com

댓글을 달아 주세요

 


 

"거의 다 만들어서 2주후에 개발이 끝나요"


이 말을 이해할 수 있는가? 우리 주변에서 소프트웨어를 개발할 때 흔히 들을 수 있는 말이다.

개발자들도 이렇게 얘기하고 관리자나 경영자도 대충 알아듣는다.


하지만 이런 대화는 여러 오해를 양산한다.


영업 담당자는 2주후면 고객에게 소프트웨어를 제공할 수 있는 것으로 착각하기도 하고, 경험이 좀 있는 관리자는 아직 충분히 안정적이지 않거나 테스트가 남아 있다는 것도 알기도 한다. 하지만 정확하게 언제 고객이 쓸 수 있는 제품이 나오는지는 알 수가 없다.


그래서 우리는 좀더 전문적으로 제대로된 용어를 사용해서 커뮤니케이션을 할 필요가 있다.


우선 개발 단계별로 정확한 용어를 사용하는 것이 필요하다.


"개발"이라는 말은 너무나 모호하다. 사실 스펙을 쓰는 일부터 유지보수 까지 모두 개발이다.

그래서 분석/설계/구현/테스트 등 단계별로 세분화된 단어를 쓰는 것이 좋다.


따라서 "개발이 끝나요"보다는 "구현이 끝나요"가 좋다.


그 다음에는 개발팀에서 만들어내는 버전이 어느 정도 수준인지 표현할 필요가 있다. 내부 테스트를 진행할 수 있는 수준인지 필드테스트를 할 수 있는 수준인지 알려줘야 한다.


일반적으로 이런 수준을 표시하는 용어는 많이들 들어봤겠지만, 알파/베타/RC 등이 있다.

 

 

알파버전이란 모든 기능의 구현이 완료되었고 버그는 많지만 Show stopper가 없는 수준을 말한다. 주변에서

 

 

"개발이 다 됐어요"라고 말할 때도 자세히 살펴보면 알파

 수준도 안되는 경우 많다. 기능이 99% 완료 되었으면

알파가 아닌 것이다. 예를 들어 설치 프로그램은 아직

개발을 안했다던지 간단한 기능의 일부가 미 구현상태면

알파가 아닌 것이다. 


따라서, 미국이나 인도나 어디에서도 알파버전이라고

하면 이 수준으로 이해를 하면 된다. 


그리고 알파버전 테스트에서 발견된 버그를 대폭 수정

해서 버그를 많이 줄인 버전을 베타버전이라고 한다.

베타버전은 내부테스트를 하기도 하고 고객을 대상으로

외부 테스트를 하기도 한다. 베타버전은 버그는 있지만

꽤 쓸만한 버전이다.


RC버전은 Release Candidate의 약자로 테스트를 해보고 출시를 결정할 후보 버전이다. 따라서 대부분의 경우 아주 안정적이다. 출시가 결정되면 바로 고객이 사용하는 버전이다. 물론 버그가 없는 것은 아니지만 충분히 안정적이다.


따라서 알파/베타/RC등의 용어를 적절하게 사용해서 개발팀에서 만들어낸 버전이 정확하게 어느 정도 수준인지 전달을 해야 한다.


"2주후에 개발이 끝나요"보다는 "2주후에 알파버전 구현이 끝나요"가 좋다.


좀더 자세히 말하면 "2주후 금요일 오후3시 정각에 알파버전 소스코드 프리즈가 있습니다."라고 하면 좀더 정확한 의미가 전달된다.

개발자들은 3시까지 모든 소스코드를 Commit해야 하고,

빌드팀은 3시가되면 소스코드를 내려받아서 빌드를 하고

테스트팀은 3시쯤 되면 알파테스트를 시작할 준비를 하고 기다리고 있을 것이다.


관리자나 경영자는 당연히 테스트 일정을 알고 있고 언제 출시 예정인지 알고 있다.

이슈관리시스템을 보고 있으면 거의 실시간으로 발견되는 버그와 고쳐지는 버그의 현황을 볼 수 있다. 


하지만 아직도 대부분의 개발 현장에서는 이런식으로 커뮤니케이션이 이루어지지 않고 있는 것이 현실이다. 


알파/베타 등의 용어를 들어봤거나 사용하고 있어도 그 의미를 정확하게 사용하지 않고 있는 경우가 많고 개발자와 영어/관리자/경영자가 그 의미를 똑같이 공유하고 있는 않다. 서로 다르게 생각하고 있으면 커뮤니케이션에 문제가 자주 생긴다.


세계적으로 표준으로 사용하는 용어들이니 표준에 맞게 사용하고 모든 직원이 똑같이 공유를 해야 한다.


그래야 좀더 합리적인 일정으로 개발이 진행된다. 

 

 

출처 : 소프트웨어 경영/공학 컨설턴트의 소프트웨어 개발 이야기
by 전규현

 

 

 

 

블로그 이미지

(주)싸이크로스

(주)싸이크로스 www.sycros.com

댓글을 달아 주세요

 

 

 

개발자는 소프트웨어 회사의 가장 중요한 자산이면서 서로 상반된 2가지 가치를 가지고 있다.


첫 번째는 ‘과거의 가치’이고

두 번째는 ‘미래의 가치’이다.


나는 과거의 개발자일까? 미래의 개발자일까? 스스로 판단하기는 어려울 것이다. 동료나 경영진에게 내가 퇴사를 하면 어떻게 될까?라는 질문을 해보면 짐작할 수 있다.


내가 퇴사를 하면 과거에 개발해 놓은 제품들을 어떻게 하지?라는 생각이 가장 먼저 들면 ‘과거의 개발자’에 가깝다.


반대로 내가 퇴사를 하면 과거에 개발해 놓은 제품들은 문제가 없는데 미래에 개발할 제품은 누가 개발하지?라는 생각이 들면 ‘미래의 개발자’라고 볼 수 있다.


회사나 개발자 입장에서 권장되는 개발자 타입은 미래 가치를 많이 지닌 “미래의 개발자”이다. 미래의 개발자가 지금은 가치가 적은데 미래에 가치가 높다는 의미가 아니다. 미래에 가치가 더 있고 시간이 흐를수록 점점 가치가 높아진다는 의미다.


과거의 가치를 더 많이 가지고 있는 ‘과거의 개발자’는 본인이 아니면 유지보수가 어렵게 소프트웨어를 개발해 놓았고, 대부분의 지식이 머리 속에 있기 때문에 동료나 신입개발자와 지식을 공유하기 어렵다. 본인이 의도해서 그렇게 한 것은 아니지만 결과적으로 자신이 과거에 만들어 놓은 소프트웨어를 인질삼아 회사와 인질극을 벌이고 있는 것과 같다.


물론 이런 개발자가 퇴사를 한다고 회사가 망하는 것은 아니지만 적게든 많게든 타격을 입게 되고 심한 경우 회사는 퇴락의 길을 걷기도 한다. 따라서 회사는 이런 개발자에게 질질 끌려 다니곤 한다. 이런 상태의 개발자는 스스로도 상황의 피해자일 뿐이다.


미래의 가치를 가진 ‘미래의 개발자’는 자신이 과거에 만들어 놓은 소프트웨어들은 후배들이 유지보수를 수월하게 할 수 있도록 개발 과정에서 적절히 문서화를 해 놓았고, 아키텍처를 깨끗하게 만들었으며 모든 이슈는 이슈관리시스템에 기록으로 남겨 놓았다. 그리고 Peer review를 통해서 이미 많은 지식을 동료들과 공유를 한 상태다.


이런 합리적인 개발 과정을 통해서 본인은 분석, 설계 능력이 꾸준히 향상되어 왔으며, 회사도 성장에 걸맞게 프로세스와 개발문화가 발전되어 왔다. 유지보수에 허덕이지 않으므로 신기술에 대한 연구에 소홀하지 않아서 미래에는 과거 제품들보다 한 단계 수준 높은 제품을 만들어 낼 것이다.


언뜻 보기에는 과거의 엄청난 폭풍 코딩을 통해서 짧은 시간에 많은 제품을 만들어내는 성과를 낸 ‘과거의 개발자’가 영웅처럼 보이지만 미래의 가치를 지닌 ‘미래의 개발자’가 진정한 영웅이다.


필자는 대기업부터 작은 소기업까지 여러 소프트웨어 회사를 다니면서 개발자와 경영진을 대상으로 소프트웨어 개발에 대해서 강연이나 세미나를 많이 한다. 그럴 때 이런 질문을 하곤 한다.


“오늘 회사를 그만둬도 당장 큰 문제가 발생하지 않는 사람 손들어 보세요”.

“오늘 회사를 그만두면 회사가 당장 큰 일 나는 사람 손들어 보세요”.


이 두 가지 질문 중에서 두 번째 질문에 손을 드는 사람이 상당히 많다. 특히 주변에 특정인을 가리키며 손을 들라고 하는 경우가 많다. 이런 사람은 십중팔구 ‘과거의 개발자’이다.


과거에 엄청나게 많은 일을 해냈지만 대부분은 유지보수에 치여 본인도 발전 못하고 격무에 시달리고 있는 경우이다. 수많은 문제와 이슈는 본인만 알고 있어서 수시로 불려 다니고 정작 본인은 개발할 시간이 없고 발전도 어렵다.


물론 ‘과거의 개발자’양산이 개발자에게 책임이 있는 것은 아니다. 소프트웨어 개발 환경이 회사에서 제공하는 프로세스, 시스템이 열악한 상태에서 전적으로 개발자의 내공에 의존을 하기 때문에 개발자도 어쩔 수 없이 ‘과거의 개발자’가 되어 버리는 것이다.


‘과거의 개발자’가 주도하는 회사는 엄청난 개발자 Risk를 안고 있는 것이다. 뛰어난 개발자가 많지만 이들이 한두 명만 나가도 회사가 휘청대며, 유지보수에 발목을 잡혀서 앞으로 나가기 어려운 상태인 경우가 많다.


회사는 개발자가 개발에 전념할 수 있고 개발 과정에서 꾸준히 성장할 수 있도록 환경을 제공해야 한다. 개발자 경력을 보장하는 것은 물론이고 프로세스와 기반시스템을 제대로 갖추고 개발문화 구축에 제도적인 노력해야 한다. 그렇게 해서 개발자 내공에 의존하는 개발이 아닌 시스템에 의존한 개발이 되어야 한다. 그런 환경에서야 개발자가 최고의 활약을 할 수 있다.


그래야 개발자도 행복하게 개발을 할 수 있고 회사도 개발자 Risk가 줄어든다. 이런 환경에서 성장하는 개발자는 신참때는 주로 코딩을 하지만 고참이 되어 갈수록 설계, 분석에 집중하고 문서를 통한 협업에 능숙해진다. 이런 방법이 개발자와 회사 모두에게 좋은 방법이다.


여전히 개발자의 내공에 의존한 개발 환경을 가진 회사에서 유지보수에 허덕인다고 개발자를 탓하지는 말자. 지금이라도 ‘미래의 개발자’를 위한 환경에 대해서 고민해보자.


책에도 다 있고 이론은 많지만 현실에서 실천이 어려운 것이다. 이론으로는 배울 수 없고 경험에 의해서 밖에 배울 수 없기 때문이다. 책과 이론은 약간의 도움을 줄 뿐이다.

 

 

출처 : 소프트웨어 경영/공학 컨설턴트의 소프트웨어 개발 이야기
by 전규현

 

 

 

 

 

블로그 이미지

(주)싸이크로스

(주)싸이크로스 www.sycros.com

댓글을 달아 주세요

 

 

 

소프트웨어를 개발하는데 있어서 꼭 알아야 할 규칙이 하나 있다. 바로 "1:10:100 rule"이다.


성숙한 개발문화를 가지고 있는 회사는 전 직원들이 진정으로 그 의미를 알고 있고 실행하고 있다. 하지만 우리나라의 크고 작은 대부분의 소프트웨어 회사 임직원들은 그 의미를 모르거나 알고 있어도 단어의 의미로만 알고 있고 진정으로 깨우치고 있지는 못하다.


소프트웨어를 개발하면서 발생하는 많은 비효율과 문제들이 바로 여기서 출발하는 것이다.


그 1:10:100 rule을 설명한 그래프가 아래에 있다.

 

 



 

 

요구사항이 스펙을 작성하면서 바뀌면 "1"이라는 비용이 들지만 고객에게 전달된 다음에 바뀌면 "368"배의 비용이 들어간다.

요구사항이든 설계든 한단계 뒤에서 고치게 될 경우 2~5배의 비용이 들어가서 시간이 흐를수록 비용은 기하급수로 증가를 한다.


따라서 기획이 제대로 되어야 하고 분석 설계가 적절하게 잘되어야 하며 한창 개발중에 기획이 바뀌거나 요구사항이 바뀌면 그 수정 비용은 엄청나다는 것을 알야 한다.


말은 쉽지만 이를 진정으로 꺠닫고 실천하는 회사나 개발자를 만나는 것은 쉬운 일이 아니다. 


사실 개발자들은 기획에서 정확한 요구사항을 주지 않는 다거나 나중에 요구사항을 바꾼다고 불평이 많다. 하지만 많은 경우 불평은 하지만 그것을 현실로 받아들이고 스스로 이를 개선하려는 노력은 별로 하지 않는다. 오히려 상황이 그러니 분석, 설계를 제대로 하지 않고 대충 개발하다가 나중에 바꿔달라고 하면 또 대충 받아들여서 개발하고 이런 악순환을 반복하곤 한다.


이런 것을 극복하기 위해서 여러 방법론이 나오기도 하고 최근에는 Agile이 각광을 받고 있지만, 이런 방법론이나 기법으로는 이를 해결할 수는 없다. 정공법외에는 방법이 없다. 기획을 제대로 하고 분석 설계를 효율적이고 적절하게 하는 것이다. 또한 그 과정에서 모든 관련자가 책임을 지고 검토를 해서 문제가 없게 해야 하면 나중에 딴소리를 하거나 바꿔달라고 하면 안된다. 정말 중요한 변경 요청이 아니면 다음 버전으로 미루는 것이 좋은 전략이다.


전 임직원이 1:10:100 rule을 진정으로 깨닫고 있다면 글로벌 소프트웨어 회사가 될 수 있는 잠재력이 충분히 있다고 할 수 있다.


 

 

출처 : 소프트웨어 경영/공학 컨설턴트의 소프트웨어 개발 이야기
by 전규현

 

 

 

 

 

블로그 이미지

(주)싸이크로스

(주)싸이크로스 www.sycros.com

댓글을 달아 주세요

 

 

 

우리나라에서는 소프트웨어 개발자로 일을 하면서 부딪히는 큰 걸림돌이 있습니다.


"Technical career path가 없다"는 겁니다.

이 말에 바로 무슨 뜻인지 팍 와 닿지 않는 사람은 우리나라의 소프트웨어 환경에 이미 익숙해지신 겁니다.
소프트웨어 개발자들은 일을 열심해도 위로 올라갈 데가 없는 경우가 대부분입니다.
그래서 팀장도 되고, 관리자도 되고 다른 직종으로 점점 옮겨가게 됩니다.
그러다 보면 기술과는 점점 멀어지게 됩니다.
뛰어난 기술자들의 보석과 같은 실력을 썩히는 거지요.
대부분의 소프트웨어 회사에서는 Technical Track과 Management Track를 구분해야 한다는 사실을 인식하지 못하고 있습니다. 두 Track은 완전히 다른 것이고 서로 잘 호환 되지도 않습니다.

지금까지 수많은 회사의 소프트웨어 컨설팅을 하면서 Technical career path가 제대로 있는 회사를 거의 접하지못했습니다. Technical career path가 제대로 있다고 하면 CTO급, 이사급까지 차례대로 거쳐 올라갈 수 있는 단계가 정의가 되어 있어야 합니다.

우리나라의 경영자들은 개발자가 고참이 되면 팀장이 되고 여러 개발자를 거느리고 나중에 부서장이 되고 하는 것이 문제라는 생각을 하고 있는 경우는 많지 않습니다.

개발자는 개발을 잘하는 것이고, 관리자는 관리를 잘하는 것이지요.
그래서 개발자는 개발을 관리자는 관리를 해야지요.

그런데, 수평적인 미국의 조직구조에 비해서 수직적인 우리나라의 조직구조에서는 개발자들조차도 고참이 되어서 관리자가 되어서 개발자들을 거느리고 싶어 하기도 합니다. 그래서 힘도 생기고 여태 일한 보람이 있다고 생각하는 경우도 있습니다. 이것은 개발자의 탓이 아니고 "Technical Career Path"가 없기 때문입니다. 그래서 관리자가 되지 않고서는 파워를 가질 방법이 없게 됩니다.
이는 Technical Leading하고는 다릅니다. 일반 관리자가 점점 되어가는 거지요.

Technical career path가 보장된 회사에서 엔지니어들은 관리적인 파워가 아닌 기술적인 파워를 갖습니다. 회사의 기술적인 결정에 대한 파워를 가지고 신참엔지니에게서는 기술적인 존경을 받죠. 미국에서는 연봉도 관리자 path보다 더 높은 것이 일반적입니다.

미국의 소프트웨어 회사에서 채용을 할 때는  엔지니어와 매니저가 완전히 구분되어 있습니다. 엔지니어는 아무리 나이가 먹어도 엔지니어입니다. 엔지니어들은 HR(Human Resource)이슈는 신경쓰지 않습니다. 언제 그런 이슈를 신경쓰고 개발할 시간이 있겠습니다. 누가 아프고, 휴가가야 하고, 엔지니어 새로 채용해야 하고 그런 것들을 신경쓰고 기술에 집중하기는 어렵겠죠. 엔지니어들은 기술적인 이슈가 개발에 필요한 비즈니스 이슈만 신경씁니다. 사람 다루고 평가하고 하는 귀찮은 일들은 관리자 트랙에 있는 사람들이 해줍니다.

외국의 컨퍼런스에 가보셨지요? 저는 할아버지 엔지니어도 만나봤습니다. 정말 재미있지요. 그런 분도 최신 기술동향 다 알고 정말 엔지니어입니다. 

외국에서는 소프트웨어 회사에서 정말로 파워를 가지고 있는 사람들은 이러한 고참개발자들입니다. 이들을 Chief Engineer, Fellow Engineer, Chief Scientist라고 부르며 회사가 구조조정을 해도 관리자들을 잘라도 이러한 핵심 개발자들은 손을 못 댑니다. 다시 회사가 좋아지면 관리자는 다시 뽑으면 되지만, 이러한 개발자를 다시 키우려면 몇 년이 걸릴지 모르기 때문이지요.

소프트웨어 엔지니어의 실력이 한 10년 일하면 완전히 바닥나는 것도 아닙니다. 사실 10년 정도까지는 개발은 잘하는 개발자가 될 수 있죠. 그리고 10년 이상이 되면 시야도 넓어지고, 회사의 전략적인 결정이나 중요한 아키텍처를 결정할 수 있는 실력과 경험을 고루 갖추게 됩니다. 그런데, 그런 사람을 우리나라에서는 관리자로 만들어버리는 경우가 허다하지요. 

내 옛날 직장에서는 "백발이 휘날리도록 개발을 할 수 있는 개발자"를 뽑은 적이 있습니다. Technical career path를 평생 보장하겠다는 것이지요. 이 문구에 감동을 받아서 지원한 개발자도 꽤 많았습니다. 그만큼 많은 개발자들이 관리자로 가기 싫어 한다는 반증이기도 합니다.

이것이 개발자 혼자 몸부림 친다고 해결될 일이 아닙니다. 경영자가 Technical career path를 보장하는 것이 회사에 왜 이익인지를 깨닫고 회사에서 제도적으로 만드는 것 밖에 없습니다. 물론 직원이 4,5명 이하인 회사에서는 다들 멀티플레이어이기 때문에 이러한 제도가 의미가 없겠죠. 하지만 조직이 조금만 커지면 분명히 Technical career path를 명확히 해서 최고의 개발자를 키워내야 합니다.


(아래 분들은 Software Engineer들입니다.)

 

 

 

 

출처 : 소프트웨어 경영/공학 컨설턴트의 소프트웨어 개발 이야기
by 전규현
 


블로그 이미지

(주)싸이크로스

(주)싸이크로스 www.sycros.com

댓글을 달아 주세요

   

 

리나라의 Customer Service(A/S) 정신은 정말로 환타스틱합니다.

TV가 고장나서 전화하면 수리기사가 바로 달려와서 고쳐주고 갑니다.
핸드폰이 고장나서 서비스센터에 가면 바로 고쳐줍니다.
뭐든지 바로바로 해결이 되죠. 

하지만 미국에서는 좀 다릅니다. 노트북이 고장나면 바로 해결이 안됩니다. 서비스센터에 맡겨도 서비스센터는 단순히 포장만해서 수리공장으로 보내는 경우가 대부분이고 오래 걸리면 한달이 걸리기도 하고 재수 좋으면 그보다는 빨리 받아 볼 수 있죠.
미국은 땅덩어리가 워낙 커서 가 도시마다 전문서비스기사를 둘 수도 없습니다.
부른다고 쪼르륵 달려갈 수도 없습니다. 비행기타고 몇시간 날아가서 차 랜트해서 또 한참 가야지만 고객을 만날 수 있거든요. 또 고객이 비행기타고 핸드폰 수리하러 갈 수는 없죠.
소프트웨어도 마찬가지입니다. 고객이 소프트웨어를 구매하고 나서 수시로 개발사의 엔지니어를 불러서 이거 봐줘라, 저거 봐줘라, 이렇게 바꿔달라, 이런 요청을 할 수 없습니다.
물론 Enterprise Solution들은 유지보수 계약을 맺고 서비스를 받지요. 그 종류도 다양하고 서비스도 시스템화 되어 있지요. 물론 그 대가를 지불해야 하구요.
엔지니어를 부르는 것은 매우 비싸지요. 그리고 유지보수 건으로 개발자를 부른다는 것은 상상하기 힘들죠.
하지만 우리나라에서는 장애 시 사과 차원에서 개발자가 가서 인사를 해야 하는 어처구니 없는 경우도 있더군요. 문제를 만든 사람이 와서 사과를 하라는 거죠.
미국에서는 이러한 환경이 제품을 만드는 마인드부터 달라지는 것 같습니다.
일단 미국 어디에 파나, 전세계 어디에 파나 컨셉은 거의 같구요. 제품은 문제 생기면 쪼르륵 달려가서 해결해야 하는 형태로 만들지는 안죠. 제품의 품질을 떠나서 마인드가 다르니 접근을 다르게 합니다. 제품의 기능이나 UI에 그러한 마인드가 묻어나고, 개발 문서도 제대로 만들고, White paper도 만들죠. 문제가 생겼는데, 거의 모든 정보가 개발자의 머리 속에 있으면 안되거든요.
물론 고객도 이거 저거 바꿔달라는 요구는 잘 못하죠. 요구가 있다고 해서 다음 버전에 꼭 넣어 달라고 강요도 못하고 그건 개발사가 알아서 할 일이죠.

우리나라의 경우는 사정이 좀 다릅니다. 전국 어디서나 부르면 개발자나 Technical Support Engineer가 달려갈 수 있죠. 오랫동안 그런 서비스에 익숙해져서 고객은 아무 때가 개발사의 Engineer를 부르고, 제품의 기능이나 업그레이드 일정도 좌지우지 합니다. 개발자를 제 종 부리듯 하는 고객도 있습니다. 또 유지보수 댓가는 제대로 받기가 어렵죠. 개발사는 단기적인 이익에 쫓겨서 어쩔 수 없이 고객의 요구를 들어주다 보면 장기적으로 제품의 경쟁력이 떨어지게 됩니다. 그러다보니 이런 환경에 적응된 제품을 생각하고 만드는 경우가 많아지는 것 같습니다. 당연히 Global mind가 떨어지지요.

또 아이러니 한 것은 이러한 고객이라도 외국 제품을 쓰면서는 국내 소프트웨어 회사 대하듯 못한다는 겁니다.

컨설팅을 하면서 만나본 많은 회사들은 국내에서는 꽤 많은 매출을 일으켰는데, 외국에는 팔기가 어려운 제품을 많이 봤습니다. 설치는 꼭 엔지니어가 가서 해줘야 하고, 주기적으로 점검도 해줘야 하고, 고객마다 커스트마이징을 해야 하기 때문에 외국에 팔 경우 그 나라에 서비스조직을 상당히 갖춰야 하는 경우가 많습니다. 국내에서는 커스트마이징을 경쟁력으로 내세워서 외국제품과 경쟁했는데, 그로 인해서 더 큰시장으로는 못나가는 거죠. 

결국 마인드를 바꿔야만 됩니다.
고작 이 작은 땅덩어리에서 경쟁해서는 구멍가게 밖에 되지 못합니다. 좀 큰 구멍가게는 매출액이 몇백억씩 되기도 하지만, 유지보수에 발목을 잡혀서 수익이 악화되고 회사가 고꾸라지기도 합니다. 구멍가게를 알차게 꾸려가든가,그렇지 않다면 Global하게 경쟁할 수 있는 마인드를 가지고 소프트웨어를 개발해야 합니다.

우리나라에서
처음부터 글로벌 마인드를 가지고 시작하는 제품이 좀더 많아지면 좋겠습니다.
이러한 글로벌 마인드를 가진 개발자와 회사가 많아지면 좋겠습니다.
작더라도 전세계 사람들이 사용하는 제품이 많아지면 좋겠습니다.
고객이 부른다고 쪼르륵 달려가지 않아도 되는 제품이 많아지면 좋겠습니다.
고객서비스가 비싼 상품이라고 인식하는 고객이 많아지면 좋겠습니다.
개발자 불러다가 이거 저거 고쳐달라고 해도 된다는 인식이 적어지면 좋겠습니다.
우리나라 개발자들이 많은 수많은 제품이 세계를 호령하는 날이 오면 좋겠습니다.

 

출처 : 소프트웨어 경영/공학 컨설턴트의 소프트웨어 개발 이야기
by 전규현

 

 

 

블로그 이미지

(주)싸이크로스

(주)싸이크로스 www.sycros.com

댓글을 달아 주세요

=

Windows Vista가 나온지 얼마 되지도 않은 시점에서 Windows7이 나온다고 하더나 이제는 Windows8이 출시될 것이라는(지금은 출시되었습니다.) 얘기가 떠돌고 있습니다.

아이폰4도 출시된지 알마 안된 시점에서 아이폰5가 출시될 것이란 얘기가 나왔습니다. 어쩔 때는 이것이 진짜인지 그냥 루머인지 구분이 안되기도 합니다.

소프트웨어 개발을 제대로 이해하고 있는 사람들이라면 Windows7이 출시됨과 동시에 또는 이미 그 이전에 Windows8은 시작이 되었다는 것을 알 수 있습니다.

소프트웨어는 끊이 없이 업그레이드가 되어야 합니다. 그러다보면 새로운 요구를 더이상 담을 수 없는 시점이 오게 됩니다. 그래서 소프트웨어의 아키텍쳐도 끊이 없이 발전하게 됩니다.

지금의 소프트웨어가 새로운 요구를 더이상 담을 수 없는 그릇이 되게 되면 이미 상당히 늦었다고 볼 수 있습니다.
미래에 생길 요구사항을 미리 예상하여 그 구조를 만드는 것이 소프트웨어 아키텍쳐링입니다. 물론 예언자처럼 미래의 모든 상황을 예측할 수는 없지만 상당부분 예측을 해야 하며 여기서 성공을 하느냐, 실패를 하느냐에 따라서 비즈니스의 성공이 달려있습니다.

그런데 현실에서 보면 소프트웨어 아키텍쳐를 바꿔야할 시점을 놓친 회사들이 매우 많습니다. 이런 회사의 특징은 다음과 같습니다.
  • 소프트웨어에 기능을 추가하거나 버그를 수정하려고 해도 기존의 소스코드가 워낙 복잡해서 분석도 어렵고 고치는데 시간이 많이 들어간다.
  • 버그를 수정해도 이전에 없었던 문제가 자꾸 다시 생겨난다.
  • 유지보수에 바빠서 신규 제품 개발은 꿈도 못 꾼다.
  • 기존 제품을 잘 알고 경험이 많은 개발자들은 유지보수하느라고 바빠서 새로운 아키텍쳐를 연구할 시간이 없다. 그래서 신규 개발자를 투입했는데 진도가 안나간다.
뻔히 다 알다시피 우리나라 대부분의 소프트웨어 회사들은 초창기에 뛰어난 몇몇 개발자들이 주먹구구식으로 상당히 좋은 소프트웨어를 개발해서 좋은 평가를 받으면서 성장해왔습니다. 그런데 회사가 커지고 소프트웨어가 커지면서 작은 조직일 때는 드러나지 않은 주먹구구 방식 때문에 효율성이 급격히 떨어지게 됩니다. 그러다보니 항상 유지보수에만 매달리고 신규 개발에는 투자를 못하게 됩니다. 대부분의 경우 소프트웨어 아키텍쳐가 4~5년 넘어가게 되면 더이상 버티기 어려운 상황에 닥치게 됩니다.

이미 마지막 기회를 놓친 회사들은 끊임 없는 유지보수에 매달리면서 회사의 쇠락을 지켜볼 수 밖에 없습니다. 수많은 회사들이 지금이 마지막 기회라는 것을 인지하지 못하고 지나쳐 버리는 것을 보면 안타깝습니다. 그나마 영업이 잘되는 회사는 막대한 인원과 자금을 투입하여 점점더 되돌아 오기 어려운 길로 가버리기 때문에 회생하기 더 어려워 집니다. 이렇게 침몰하는 거대한 여객선 같은 소프트웨어 회사들이 상당히 많고 경영진들이 이를 알지 못하는 경우도 매우 많습니다. 경영진들은 개발에서 구멍이 났다는 것을 알아도 그 구멍을 어떻게 매워야 하는지 정확하게 모르는 경우가 대부분입니다. 그래서 이런 저런 시도를 하다가 침몰만 가속화 시키곤 합니다. 그래도 시도를 안할 수는 없겠죠.

그럼, "언제 다시 만들어야 하는지?" 질문으로 돌와와 보죠.
회사마다 제품의 성격과 규모마다 다르지만 대부분은 첫번째 제품이 개발되면서 이미 두번째 제품의 기획도 시작이 되어야 합니다. 또한 두번째 제품을 누가 개발을 할지 언제 개발을 할지 계획을 미리 가지고 있어야 합니다.
첫번째 제품은 개발 후에 유지보수는 어떻게 진행을 하고, 누구는 두번째 제품에 투입이 되어야 하는지 등의 계획을 미리 가지고 있어야 한다는 뜻입니다.
이 얘기는 무슨 뜻이냐면 처음부터 개발을 체계적으로 하면 된다는 뜻입니다. 분석이 제대로 되고 설계가 제대로 되어야 해결이 된다는 얘기 입니다.

그럼 이미 첫번째 제품을 주먹구구식으로 개발을 한 회사는 어떻게 해야 할까요? 지금이라도 두번째 제품을 체계적으로 다시 기획을 해야겠죠. 주먹구구의 결과로 필요한 상당히 많은 자료는 개발자들의 머리속에 들어 있습니다. 이것들을 끌어내서 문서화 하면서 두번째 제품을 기획하고 분석을 해내야 합니다. 개발자들은 이미 기본의 제품이 가지고 있는 문제점과 개선점을 아주 잘 알고 있습니다. 문제는 이것들이 문서화가 되어 있지 않고 리뷰가 안되었다는 겁니다. 이것들을 문서로 끌어내는 것만으로도 두번째 제품의 상당한 스펙이 됩니다. 또한 업계 동향과 신기술도 끊임 없이 조사를 해야 합니다.

그럼 이미 두번째 제품을 만들 마지막 기회를 놓친 회사들은 어떻게 해야 할까요?
늦었다고 생각할 때가 가장 빠른 때입니다. 쉽지는 않겠지만, 큰 고통이 따른 변화가 필요합니다. 기존의 영업의 손실을 감수하고라도 유지보수 정책의 전면적인 변화가 필요하며 새로 투자를 더 해야 할 수도 있습니다. 회사의 조직과 프로세스의 전면적인 개혁도 필요할 것입니다. 즉, 다시 원칙에 충실해야 한는 거죠. 이 과정에서 개발자나 회사 모두 고통이 따르겠지만 이렇게 해서 성공할 것 같으면 시도를 할 수도 있고 그런 확신이 없다면 그냥 지켜보는 수 밖에 없을 겁니다.

귀사의 소프트웨어는 어느 시점에 와 있나요? 곰곰히 생각해보시기 바랍니다.

 

출처 : 소프트웨어 경영/공학 컨설턴트의 소프트웨어 개발 이야기
by 전규현

 

 

 

 

블로그 이미지

(주)싸이크로스

(주)싸이크로스 www.sycros.com

댓글을 달아 주세요

 

NIH(Not invented here) 신드롬이란?

카츠와 알렌(Katz & Allen)은 기업연구에서 “선진 기업의 연구조직은 흔히 자신들이 직접 개발하지 않은 기술이나 연구 성과에 대해 배타적 성향으로 보인다”고 주장하며 이러한 현상을 NIH 신드롬이라고 정의했다.

소프트웨어를 개발하는데 있어서도 NIH신드롬과 유사한 현상이 많이 발생합니다.
개발하는데 필요한 라이브러리나 개발 방법, 개발툴들을 모두 입맛에 맞게 직접 만들어서 쓰는 경우를 말하는 겁니다.

우리나라의 개발자들이나 소프트웨어 회사들은 특히나 더 자신만의 방법들을 선호하는 경향이 있는 것으로 생각됩니다. 여러가지가 이유가 있겠지만 몇가지만 나열해보면 다음과 같습니다.
    • 라이브러리를 구매하는 비용을 비싸다고 생각한다. 특히나 회사에서 개발에 필요한 라이브러리는 잘 안사준다.
    • 더 좋은 방법이나 라이브러리, 툴이 있을 수도 있지만 이것들을 찾을 시간이 없이 바쁘거나 귀찮다.
    • 관련 자료들이 대부분 영어로 되어 있는데 영어가 딸려서 영어로 된 자료는 꺼려한다.
    • 외부의 기술이나 방법은 자신이나 회사의 상황에 맞지 않는다고 생각한다.
    • 자신의 기술과 실력이 더 우월하다고 생각한다.
    • 주변에 경험이 많은 선배들이 적어서 자문을 구하기가 어렵다.
이러한 현상은 집을 만들어야 하는 사람이 나에게 알맞은 망치는 내가 더 잘 만든다고 생각하고 망치도 직접 만드는 것과 비교할만 합니다.

상용 라이브러리는 비싸다.

흔히들 상용라이브러리는 너무 비싸다고 생각하고 직접 만들어 쓰는 경향들이 있습니다. 하지만 직접 만들어 쓸 때 발생하는 유지보수 비용은 미처 생각하지 못하고 이런 결정을 하는 경우들이 많습니다. 아니 이런것들을 고려하는 것은 커녕 개발자들이 무슨 라이브러리를 만들었는지 회사에서는 또는 동료들은 잘 모르는 경우도 있습니다.
물론 세상에 이전에는 없었던 라이브러리던가 진짜 그 회사만의 독특한 상황을 반영한 라이브러리나 툴이 없는 경우는 예외일 것입니다. 경계할 것은 이런 경우는 그렇게 흔하지 않기 때문에 착각하면 안될 것입니다.

일단 직접 만들고 나면 유지보수 비용이 상용 라이브러리를 썼을 때보다 비용이 몇배 더 드는 경우가 아주 흔합니다. 이때 직접 개발한 것이 훨씬 비싸다는 것을 깨달았어도 이쯤되면 다시 되돌리기가 매우 어렵습니다. 앞으로도 비용이 계속 더 들 것이지만 이를 되돌리는데도 너무 비용이 많이 들기 때문에 그냥 계속 가는 수밖에 없는 경우가 많습니다.

요즘은 오픈 소스 라이브러리가 매우 많으므로 선택의 폭이 매우 넓습니다. 이때 오픈 소스를 수정해서 쓰게 되면 나중에 오픈 소스가 업그레이드 되었을 때 머지(Merge)하는 것이 어려울 수 있으므로 이에 따른 비용도 감안해서 검토해야 합니다.

직접 만들 시간은 있어도 남이 만든 좋은 것을 찾을 시간은 없다.

사실 대한민국의 개발자들은 항상 바쁜 것처럼 보입니다. 그래서 차분하게 검토할 여유가 없습니다. 이는 매우 안타깝게 생각합니다. 또한 뭔가 계속 코딩을 해야 일한 것 같은 분위기는 검토하는데 시간을 쏟는 것을 어렵게 만듭니다.

라이브러리를 무작정 직접 만들기보다는 쓰기 적합한 좋은 상용라이브러리가 없는지 미리 검토하는데 시간과 노력을 투자하는 것이 대충 만들어 놓고 나중에 후회하는 것보다는 훨씬 효율적입니다. 물론 모든 검토 결과 직접 만들어 쓰거나 오픈 소스를 수정해서 사용하는 것이 더 좋다는 결론이 날 수도 있습니다. 하지만 이런 결정을 하기 위해서 쏟은 노력과 시간은 그렇게 아깝지 않습니다.

영어자료는 꺼려진다.

이 부분에 대해서는 할 말이 별로 없습니다. 영어는 소프트웨어 개발자를 평생 따라다닙니다. 꾸준히 공부하는 수 밖에 없을 겁니다.

 
이건 우리에게는 맞지 않다.

"우리회사는 다르다."라고 생각하는 것은 착각입니다. 우리에게 필요한 것의 99.99%는 이미 다 나와 있다고 생각하면 됩니다. 즉, 있을 것은 다 있고 문제는 가격, 배우는 비용 등입니다.
그리고 프로세스나 툴을 보면 특히나 자신의 회사가 독특하다고 생각하는 사람들이 많습니다. 물론 이 세상에 똑같은 회사는 하나도 없습니다. 하지만 소프트웨어를 개발하는 방법은 거의 모든 회사가 별로 다르지 않습니다. 유명한 툴이나 흔히 사용하는 프로세스가 자신의 회사와는 맞지 않다면 자신의 회사에 딱 알맞은 것을 무조건 만들기보다는 회사의 프로세스가 잘못된 것이 아닌가 먼저 검토해보는 것이 좋습니다. 회사의 프로세스가 잘못된 경우가 99%입니다.
거꾸로 말하면 세계적인 툴이나 프로세스를 쓰면서 이에 적응해 가는 것이 개발을 더욱 효율적으로 만드는데 도움이 될 수 있습니다.

내가 더 잘한다.

지금 내가 가지고 있는 지식은 99%이상 선각자들이 이룩해 놓은 것들입니다. 모짜르트도 제대로된 방법으로 훈련을 받지 못했으면 지금같이 위대한 작곡가가 되지 못했을 겁니다.
99%의 것을 배우는데 노력하고 거기에 내가 1%를 더하는 것이 올바른 방법일 겁니다.

물론 특정 분야에서 이전의 모든 선각자보다 뛰어난 사람이 있을 수 있습니다. 이렇게 뛰어난 개발자라면 그 실력을 망치를 만드는데 쓰기 보다는 빌딩을 만드는데 쓴다면 더 뛰어난 빌딩이 만들어 질 겁니다.
물론 망치를 제일 잘만드는 사람은 망치를 만들어서 팔면 될 것입니다.

물어보고 싶은데 물어볼 사람이 없다.

이 부분도 안타깝습니다. 대분의 개발자들의 경험담을 들어보면 회사에 입사에서 별로 배우지 못했다고 합니다. 회사를 입사해서 스스로 거의 모든 것을 만들어야 했고 선배들이 별로 없는 경우가 많았고, 회사가 커진 다음에 입사를 한 경우에도 선배들도 유지보수에 바빠서 각자 개발하느라고 정신이 없어서 선배들에게 별로 배울 기회가 없었다고들 합니다.
다행이라면 요즘은 인터넷을 통한 소셜 커뮤니티가 발달해서 정보를 공유하기 훨씬 수월해졌습니다. 이런 다양한 외부 자원들을 활용하는 것도 좋은 방법입니다.

결론

소프트웨어를 개발하면서 내가 겪는 거의 모든 상황은 이전에도 있었습니다. 그것도 매우 여러번 발생했었고 그에 대한 해결책도 이미 다 나와있습니다. 라이브러리, 툴, 프로세스 거의 모든 것이 이미 나와있고 이중에서 꼭 필요한 것을 제대로 찾아서 사용하는 것이 매우 중요하며 쉽지 않은 일입니다.
뭔가 툴이나 라이브러리를 만들고 싶으시면 한번 더 생각해봅시다.

 

출처 : 소프트웨어 경영/공학 컨설턴트의 소프트웨어 개발 이야기
by 전규현


블로그 이미지

(주)싸이크로스

(주)싸이크로스 www.sycros.com

댓글을 달아 주세요

 

 

필자가 컨설팅을 진행했던 수많은 회사들 중에서 80% 이상은 불난 호떡집처럼 매일 불끄느라고 정신이 없습니다.

  • 너무 바빠서 새로운 기술을 연구할 시간도 없다고 한다.
  • 프로젝트를 진행할 때도 가장 빠른 방법으로 문서도 작성하지 않고 가장 뛰어난 개발자가 바로 코딩부터 한다고 한다.
  • 고객들은 기다려주지 않기 때문에 요구하자마자 바로 며칠 안에 제품에 기능을 반영해야 한다고 한다.
  • 제품에 버그가 발견되면 하루 이틀 안에 버그를 수정해줘야 한다. 그렇지 않으면 고객들이 엄청나게 컴플레인을 한다.
  • 사소한 버그 수정도 빨리 해야 하기 때문에 신입 개발자들에게는 시킬 수가 없다. 고참 개발자가 2시간이면 고칠 것을 신입 개발자를 시키면 2일이 걸릴 뿐더러 고참 개발자가 신입 개발자에게 일을 시키고 검토해주는데 2시간이 넘게 걸린다.
  • 제품의 아키텍처가 취약해서 기능을 추가할 때 아주 애를 먹는다. 언제 시간을 내서 아키텍처를 깨끗하게 새로 만들고 싶지만, 유지보수에 바빠서 도저히 그럴 시간이 나지 않는다.
  • 이러다 보니 수시로 야근이다.
  • 운동할 시간도 없어서 몸이 점점 망가진다.
  • 영어공부도 하고 싶은데 시간이 없다.

이런 회사의 미래는 누구나 짐작할 수 있습니다.
설령 제품이 고객들 입맛에 맞고 영업도 잘되어서 큰 성공을 이뤘다고 하더라도 시간이 흐를 수록 채산성은 악화되고 개발자들의 사기는 떨어지고 있을 겁니다. 자꾸 옛날에 개발이 더 잘되었다고 회상할 것입니다.

매일 불끄기 모드로는 회사가 성장할 수 없습니다.

회사에서 해야 할 일은 4가지로 구분할 수 있습니다.

구분 중요한 일 중요하지 않은 일
시급한 일 A B
시급하지 않은 일 C D

 

A. 중요하고 시급한 일
중요한 계약을 따기 위해서 급하게 해결해야 하는 일

 

일상적으로 제품에 버그를 잡는 일 
고객들의 기능 추가 요청을 들어주는 일

 

B. 중요하지 않으나 시급한 일

 

 

C. 시급하지는 않으나 중요한 일
새로운 기술을 연구하는 일
회사의 개발 프로세스를 꾸준히 발전시켜 나가는 일
새로운 아키텍처를 연구하는 일
차세대 제품을 개발하는 일
회사의 개발 문화를 발전시키는 일

D. 중요하지도 않고 시급하지도 않은 일
이런 일은 영원히 미뤄도 된다. 나중에 중요해지거나 시급해질 때 해도 된다.

이 중에서 회사의 미래를 결정짓는 일들은 "C. 시급하지는 않으나 중요한 일"들입니다.

어차피 "A중요하고 시급한 일"은 누구나 열심히 하게 되어 있습니다. 하지만 "B. 중요하지 않으나 시급한 일"을 처리하느라 "C. 시급하지는 않으나 중요한 일"을 처리 하지 않으면 미래는 없습니다.


제가 만난 수많은 회사들 중 대부분은 C에는 거의 신경을 못쓰고 있습니다. B를 조금이라도 소홀히 하면 회사가 당장 망할 것 같은 생각을 하면서 C는 전혀 손을 못댑니다. 거의 99:1인 경우도 많습니다. 하지만 회사를 망하게 하는 것은 C를 소홀히 하는 것이 장기간 지속되는 경우입니다. 평상시에 B와 C에 균형을 가지고 투자를 해야 합니다. 20%~30%는 C에 꾸준히 투자를 해야 합니다. 꾸준히 투자를 하지 않으면 어느날 갑자기 투자를 할 수 없습니다. 지금은 너무 바빠서 중요한 것을 알지만 지금은 투자를 할 수 없다고 말한다면 영원히 중요한 일에 투자를 할 시간은 생기지 않을 겁니다.

"C. 시급하지는 않으나 중요한 일"에 투자를 하는 방법은 여러가지가 있지만 가장 좋은 방법 중에 하나는 조직을 나누는 것입니다. 일부 조직은 항상 중요한 일을 할 수 있도록 하는 겁니다. 또한 개발자들에게도 중요한 일을 소홀히 하지 않도록 항상 상기를 시켜주는 것이 좋습니다.

당장 어렵다면 해야할 일들을 A, B, C, D로 나누기를 먼저 해보시기 바랍니다.

 

 

출처 : 소프트웨어 경영/공학 컨설턴트의 소프트웨어 개발 이야기
by 전규현

 

 

 

블로그 이미지

(주)싸이크로스

(주)싸이크로스 www.sycros.com

댓글을 달아 주세요

 

 

아이디어 내면 "네가 한번 만들어봐"

 

소프트웨어 업계만큼 아이디어가 넘치는 곳도 찾기 어렵습니다.

Google이 탄생하게 만든 힘도 아이디어이고, Google이 지속 성장하여 지금이 Google이 된 힘도 아이디어입니다. Google에서는 업무시간의 20%는 새로운 아이디어를 생각하거나 준비하는데 사용할 수 있고 좋은 아이디어만 있다면 얼마든지 시도해 볼 수 있습니다. Google이 풍족하기 때문에 그렇게 할 수 있다고 말하는 사람들도 있지만, 이는 닭이 먼저냐? 달걀이 먼저냐?의 이슈입니다.

 

소프트웨어 업계에 종사하고 있는 사람이라면 항상 새로운 아이디어에 대해서 고민하기 마련입니다.

 

하지만, 좋은 아이디어를 내면 "네가 한번 만들어봐"라고 하는 경우가 많습니다. 또는 "뜬구름 잡고 있네"라고 하는 경우도 있죠.

안 그래도 바쁜데 아이디어만 내며 그 책임이 나에게 돌아오고 지금 하고 있는 일에 지장을 초래할 수 있기 때문에 좋은 아이디어가 있어도 쉽사리 얘기하기도 힘들어 집니다..

그러다 보니 자연스럽게 지금 하고 있는 일이나 열심히 하지 "생각은 무슨 생각" 그냥 아무 생각 없이 일이나 하게 됩니다.

 

아이디어가 나오면 아이디어를 더 발전 시키는 일은 회사에서 할 일입니다.

물론 아이디어를 내놓은 사람이 아이디어를 Follow up하는 일을 맡을 수도 있지만, 이를 위한 배려는 해야 합니다. 안 그래도 바쁜데 언제 그러고 있냐고요? 그러다 보면 지금 하고 있는 업무에 지장이 있다고요? 그런 회사는 어차피 현재 일에만 치여서 미래는 준비 못하는 겁니다. R&D에 투자를 못하는 것이고 미래가 없는 것이죠.

SW 회사의 중요한 자산은 개발자의 시간이기 때문에 개발자의 시간을 사용하는 것은 중요한 투자 수단의 하나 입니다. 공짜가 아니죠.

 

아이디어가 나오면 일단 공론화 할 수 있는 창구가 필요합니다.

그래서 누구나 볼 수 있고 토론을 할 수 있어야 합니다. Wiki를 이용하는 것도 좋은 방법이고 주기적으로 아이디어를 발표하게 하는 것도 좋습니다. 사소한 아이디어 하나가 여러 사람의 머리를 거치면서 훨씬 더 멋진 아이디어로 발전하는 경우는 흔합니다.



아이디어를 많이 생각해 낼 수 있는 수단이 필요합니다. 간단한 포상을 해도 되고, 평가에 반영할 수도 있습니다. 또 아이디어가 실현되어서 수익을 내게 되면 그 수익의 일부를 지급하는 방법도 있습니다.

 

꾸준히 아이디어를 내지 않는 SW회사는 용역회사밖에 될 수 없을 겁니다.

아이디어는 10개 나오면 그 중에 하나 쓸만하고, 그 쓸만한 아이디어 10개 수행하면 한 개 정도 성공하고 그 성공한 아이디어 10개 중에서 한 개 정도 대박이 터질까 말까 합니다.

, 아이디어가 1,000개는 나와야 대박이 나올까 말까 한다는 겁니다.

999개의 아이디어가 없으면 대박 아이디어 1개가 나오지 않습니다. 그래서 꾸준히 아이디어를 고민하지 않고 몇 명이 머리 맞대고 대박 아이디어 고민하는 것은 확률이 너무 낮습니다.

 

아이디어는 어느날 갑자기 계시를 받듯이 하늘에서 뚝 떨어지는 것이 아닙니다. 업계 동향도 꾸준히 살펴야 하고, 신기술도 열심히 익혀 놓고, 새롭고 창의적인 생각을 장려하는 기업 문화가 있지 않으면 아이디어가 생기지 않습니다. 좋은 아이디어라고 하더라도 시장의 상황과 맞지 않는 다면 별 효과를 발휘하지 못할 수도 있습니다. 이런 시기 적절하지 못한 아이디어라고 하더라도 잊혀지지 않도록 꾸준히 관리할 수 있는 도구도 필요합니다.

 

아이디어를 먹고 살 수 밖에 없는 Software회사가 아이디어 발굴에 소홀히 한다면 지금은 그럭저럭 살아남을 수 있어도 지속적으로 성장하는 회사가 되기는 어려울 겁니다. 아이디어 없이 영업으로 성장한 회사의 개발자들은 참 고될 수 밖에 없습니다. 그런 회사에서 일하는 개발자를 흔히 "앵벌이"라고 하죠.

 

끊임 없이 아이디어 발굴에 투자하는 기업문화가 개발자들을 더욱 즐겁게 일하고 건전하게 성장하는 소프트웨어 회사를 만들어 줍니다.

 

 

출처 : 소프트웨어 경영/공학 컨설턴트의 소프트웨어 개발 이야기
by 전규현

블로그 이미지

(주)싸이크로스

(주)싸이크로스 www.sycros.com

댓글을 달아 주세요

 

 

 

 

소프트웨어를 개발하는 회사라면 당연히 갖추고 있어야 할 개발 문화는 여러가지가 있지요.

Peer Review, Sharing, 규칙 준수 ...

 

이 중에서 좋은 문화 중의 하나가 일상화된 내부세미나입니다.

 

유수의 소프트웨어 회사들을 보면 회사에 늘상 세미나 공지가 있습니다.

누구나 세미나를 진행할 수 있고,

대부분 직원들이 관심을 가질 만한 주제들이고,

누구나 부담없이 참여를 합니다.

오다가다 들려서 보기도 하고,

관심이 많으면 준비를 해와서 발표자와 토론도 하기도 하기도 합니다.

누가 시켜서 의무적으로 하는 세미나는 아니지요.

 

그러한 과정에서 발표자에게도 지식을 더욱 깊고 굳건히 할 수 있는 기회가 되고,

참가자는 새로운 지식을 쉽게 익힐 수 있는 기회가 되고,

회사는 항상 연구하고 새로운 기술을 추구하는 자연스런 분위기가 됩니다.

 

항상 프로젝트에 치여서 이럴 시간이 전혀 없다면 곤란하지요.

강제로 해야 하고 강제로 참여해야 한다면, 문화로 자리잡을 수가 없지요.

회사에서는 이에 대한 시간적인 공간적인 배려와 약간의 금전적인 지원도 좋죠.


이를 포함한 여러 개발문화들이 뿌리깊게 자리잡지 않고는 Global 경쟁력을 갖춘 소프트웨어 개발 회사가 된다는 것은 불가능하다는 것을 인식해야 하지 않을까요?

 

 

출처 : 소프트웨어 경영/공학 컨설턴트의 소프트웨어 개발 이야기
by 전규현


 

블로그 이미지

(주)싸이크로스

(주)싸이크로스 www.sycros.com

댓글을 달아 주세요

 

신입 개발자가 들어오면 어떻게 하시나요?

회사에서 소프트웨어를 개발하기 위해서는 많은 것을 알아야 함에도 불구하고 딱히 가르칠게 별로 없는 경우를 많이 보았습니다. 체계적인 교육 방법도 마땅치 않고요.

어떻게 신인 개발자를 가르치고 있는지 제가 아는대로 한번 나열을 해보죠.

 

      - 멘토(사수)를 지정해서 맨투맨으로 이거 저거 생각나는 대로 알려준다.

- 회사에 문서는 정말로 많다. 책꽂이로 한 벽 가득이다. 그 중에서 뭘 보라고해야 할지 잘 모르겠다.

- 제품에 관한 변변한 문서가 하나도 없다. 있다 하더라도 부실하거나 옛날 버전이다. 그래서 말로   는대로 설명해준다.

      -개발하는 제품의 메뉴얼을 보여주고 제품의 기능을 익히게 한다.

      -일단 일을 시키고 본다. 물어보는 것이 있으면 그때 그때 알려준다.

      -소스코드를 보게 한다. 소스코드를 분석해서 스스로 제품의 구조를 알아내는 것도 큰 공부다.

 

위와 같은 현상이 소설은 아닙니다. 실제로 주변에서 흔히 있는 일을 적어본 겁니다.

우리는 전혀 다르다라고 하시는 분도 있나요?

아니면 이게 무슨 문제지? 라고 생각하는 분도 있나요? ... 그럼 그렇게 생각하는 것이 또 문제네요. ^^

사실 신입개발자가 들어왔을 때 효율적으로 교육을 시킬 수 있는 역량을 갖추는 일은 쉬운 것이 아닙니다. 그 정도 되면 회사가 소프트웨어 개발 회사로서 왠만한 모든 것은 다 갖추고 있는 것이니까요.

이는 "닭이 먼저냐 달걀이 먼저냐"와 비슷합니다.

그렇게 잘 교육된 신입 개발자는 나중에 고참이 되어서 새로운 신입사원에게 자신이 겪은 대로 할 것입니다.

 

모든 것을 다 갖추어야 한다고 하면 막막하니까 핵심적인 것만 몇 가지 얘기를 해보죠.

내가 어느 소프트웨어 회사에 신입 개발자로 입사를 했습니다.

당연히 그 소프트웨어 회사는 다음과 같은 기본적인 시스템은 갖추고 있어야 합니다.

 

     - 소스코드관리시스템

    - 버그관리시스템

    - 개발 프로세스

    - 코딩컨벤션(프로그래밍 가이드)

 

그리고 입사를 하면 가장 먼저 위의 시스템과 프로세스, 규칙을 익히고 제품에 대한 기본적인 개발문서를 보게 됩니다. 이때 문서가 너무 많거나 아예 없거나 부실해서 있으나마나 하면 소용이 없죠.

그래서 제품의 스펙문서(SRS, Software Requirements Specification)을 먼저 보고 제품을 이해하게 되면 설계서를 보게 되죠. SRS라는 용어가 낯선 분이 있을텐데, SRS는 앞으로 제가 올리는 수많은 글들의 주요 주제가 될 예정이니 지금은 그냥 소프트웨어의 스펙을 정리한 문서라고만 생각해도 됩니다.

이제 저는 소프트웨어 개발에 투입될 기본적인 준비는 된 겁니다.

그리고 나면 버그를 고치는 일부터 할당이 됩니다. 아주 쉬운 버그부터 시작합니다.

고참은 고치는데 10분이면 될 일은 나는 반나절은 걸려서 해야 할 겁니다. 그래도 그만한 가치가 있는 일이지요.

 

   - 먼저 버그관리시스템에서 버그를 할당 받습니다.

   - 선배가 어느 파일을 어떻게 고쳐야 하는지도 가이드를 해줍니다.

   - 소스코드관리시스템에서 코드를 내려 받아서 소스코드를 수정합니다.

   - 선배들이 코드리뷰를 해줍니다.

   - 빌드스크립트를 이용해서 빌드도 해봅니다.

   - 개발자 Unit Test도 수행하고요.

   - 버그관리시스템도 갱신합니다.

 

이런 일을 몇 번 하면서 점점 더 어려운 일을 하지만 항상 선배들이 코드리뷰를 해줍니다.

그러고 나면 설계에도 참여를 하고 새로운 모듈이나 제품도 맡게 됩니다.

엄청나게 많은 일을 몇 줄로 작성을 하다 보니 너무 간단해지기는 했지만 기본은 아래 3가지 입니다.

 

   - 제대로된 시스템(Infrastructure system)과 개발 프로세스

   - 최신 버전으로 업데이트된 제대로 적힌 핵심 개발문서(SRS)

   - Code Review, Peer Review

 

사실 이 기본을 갖추는 일은 매우 어려운 일입니다.

어떻게 이러한 기본을 갖춰나가야 할지에 대한 의문이 있다면 저와 계속 의논을 해나가면 어떨까요?

 

출처 : 소프트웨어 경영/공학 컨설턴트의 소프트웨어 개발 이야기
by 전규현

 

블로그 이미지

(주)싸이크로스

(주)싸이크로스 www.sycros.com

댓글을 달아 주세요

  • 요원009 2019.07.23 22:56 신고  댓글주소  수정/삭제  댓글쓰기

    요즘 신입 개발자 구하는 게 되려 경력직 보단 쉽네요.

    https://coderlife.tistory.com/438

    제가 학교 다니고 신입일 땐 오히려 신입 뽑기가 더 힘들다는 이야기 들었습니다. 이제 근 10년 가까이 이 바닥에서 일하는 중인데 천지개벽 수준으로 SW 개발자 인식이 많이 바뀌었습니다.

 

 

소프트웨어 공학은 가르칠 수 없다고 합니다.

단지, 시행착오를 통해서 배우던지, 경험자에게 배우는 방법 밖에 없다고 합니다.
 

그래서 소프트웨어를 잘 개발하는 방법을 배우는 가장 좋은 방법은 잘 되어 있는 소프트웨어 회사에 들어가서 배우는 것입니다. 잘 되어 있는 회사에서 소프트웨어를 개발하다 보면 자연스럽게 몸에 익히게 되는 겁니다.
 
소프트웨어 개발이 전체적으로 어떻게 돌아가는지 자연스럽게 몸에 익히게 되며, 각 기능 조직은 어떻게 구분이 되며, 개발에 꼭 필요한 기반 시스템은 어떤 것들이 있으며 어떻게 사용하는지 배우게 됩니다. 따로 공부한다는 생각으로 배우는 것이 아니며 자연스럽게 몸에 익게 됩니다.
 

그런데 우리의 문제는 여기에 있습니다. 잘 되어 있는 소프트웨어 회사가 별로 없다는 겁니다.
 
제 컨설팅 경험에 의하면 확실합니다. 제 책에 제안하고 있는 소프트웨어 개발 역량 평가표로 평가를 해보면 20점 만점에서 10점이 안되는 소프트웨어 회사가 95%도 넘는 다는 것입니다.
 
즉, 학교 시험 기준으로 50점도 안되는 낙제점수를 받은 학생이 95%이상이라는 겁니다.
 

이러니, 잘 되어 있는 회사에 들어가서 제대로 배우기는 로또 당첨과 비슷하죠.
 

잘 갖춰져 있는 소프트웨어 회사도 처음부터 잘 되어 있었던 것은 아닙니다. 뭐든지 처음은 있었겠지요.
 
뭐가 먼저 일까요? 회사가 먼저 바뀌었을까요? 개발자가 먼저 바뀌었을까요?
 

이는 닭이 먼저냐? 달걀이 먼저냐? 이슈와 비슷합니다. 이 논쟁은 답이 나와 있기는 합니다. 전문가들은 달걀이 먼저라고 합니다. 왜냐하면 달걀이 더 단순하기 때문이라고 합니다. 진화의 돌연변이가 달걀에서 일어 났고, 그 달걀에서 닭의 모습을 한 조류가 나오게 된 것이지요.
 

소프트웨어 회사도 수십년 동안 수많은 개발자와 소프트웨어 공학 전문가들이 소프트웨어 회사들을 조금씩 효율적으로 바꿔 나간 겁니다. 그래서 지금의 모습에 이르게 된 것입니다.
 

그럼, 우리 회사도 효율적인 소프트웨어로 변하고 싶을 때 달걀 전략을 사용해야 할까요? 즉 의식있는 개발자가 회사를 아주 조금씩 서서히 바꿔나가야 할까요?
 

생물의 진화에는 아주 오랜 시간이 걸렸고, 그 와중에 수많은 종이 멸종을 했듯이 달걀 전략은 많은 시간이 필요하며 그 사이에 회사가 망할지도 모릅니다. 멸종된 수많은 종들과 같이요.
 

이 때는 닭의 전략이 좀더 효과적입니다. 회사 자체를 먼저 바꿔야 합니다. 그리고 개발자들이 이를 따라오게 해야 합니다. 조직과 프로세스와 시스템을 회사에 알맞게 바꿔 놓고 개발자들을 교육시키고 훈련시켜야 합니다.
 

밑바닥에서부터의 조용한 개혁을 꿈꾸고 있는 개발자가 계시다면 그 한계를 깨닫고 경영층을 먼저 설득하시기 바랍니다. 그래야 멀지 않은 미래에 효과적인 조직으로 탈바꿈한 개발조직에서 일을 하실 수 있을 겁니다.

 

소프트웨어 경영/공학 컨설턴트의 소프트웨어 개발 이야기
by 전규현

 

금월부터 소프트웨어 경영/공학 컨설턴트로 활동하고 계시는

ABCTech社 수석 컨설턴트 전규현님의 All Of Software 이야기를 게재하게 되었습니다.

소프트웨어 비즈니스 관련 종사자나 관심 있으신 분들께 조금이나마 도움이 되길 바라며

게재를 허락해 주신 전규현 수석님께 다시 한 번 감사의 말씀을 드립니다.

 

 

블로그 이미지

(주)싸이크로스

(주)싸이크로스 www.sycros.com

댓글을 달아 주세요

제이보스(JBoss)

2012. 8. 28. 15:09

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

 

 

 

오픈소스 미들웨어 제이보스(JBoss)

제이보스(JBoss)는 자바를 기반으로 하는 오픈 소스 미들웨어의 총칭으로, 대표적으로는 Java EE 스펙을 지원하는 제이보스 애플리케이션 서버가 있다.

Java EE 서버란 Java Enterprise Edition(EE) 표준에 따라 구현된 서버를 의미하며 흔히 Java EE 서버를 WAS(Web Application Server)라고 부르는데 이러한 서버에는 Oracle WebLogic, IBM WebSphere, Adobe JRUN, JBoss, Apache Geronimo, Tmax JEUS등이 있다.

JBoss는 현재 40개 이상의 다양한 프로젝트가 있으며, Jboss.org 커뮤니티에 의해 개발 및 운영되고 있다.

원래 JBossEJB오픈소스로 개발하기 위해 Mark FleuryEJBOSS(Enterprise Java Beans Open Source Software)라는 이름으로 시작한 프로젝트였지만 SUN과의 상표권 문제 때문에 앞의 E를 빼고 현재 JBoss라는 이름이 되었다.

JBoss는 각 프로젝트의 핵심 개발자를 JBossInc.의 직원으로 고용하고 있으므로 오픈 소스의 프로젝트이면서 직원으로 고용하면서 제품 개발을 계속하는 독특한 형태를 취하고 있다. JBossInc.는 소프트웨어를 프리라이선스로 제공하면서 지원 서비스를 판매하여 수익을 올리고 있다.

2006년에는 상용 리눅스 벤더인 레드헷에서 인수하여 JBoss프로젝트를 운영하고 있다. 2007년부터 레드햇은 각종 컴포넌트의 제공 및 보증 및 통합 품질 테스트를 완료한 JBoss소프트웨어를 JBoss엔터프라이즈 미들웨어로 제공하고 있다.

 

주요 JBoss 프로젝트는 다음과 같다.

 

JBoss Application Server

JBoss Web
JBoss ESB
JBoss Messaging
JBoss jBPM
JBoss Transactions
JBoss Web Services
JBoss Tools
JBoss Cache
JGroups
Mobicents
Hibernate
JBoss RichFaces
JBoss Ajax4jsf
JBoss Portal
JBoss Seam
JBoss EJB3
JBoss AOP
•JAAS

Apache Tomcat과 JBossAS

Apache Tomcat은 Java EE 표준에 포함되어 있는 JSP, Servlet, JSTL 등과 같은 웹 애플리케이션 개발을 위한 표준을 구현한 웹 컨테이너이다. Java EE 표준에는 다양한 컨테이너가 정의되어 있는데 대표적인 컨테이너가 웹 컨테이너와 EJB 컨테이너이다. 웹 애플리케이션을 개발하기 위해서 필요한 웹 컨테이너를 구현한 것이 바로 Apache Tomcat이며, JBossAS는 Java EE 표준에 포함되어 있는 모든 표준을 구현한 완전한 Java EE 서버라고 할 수 있다. 예를 들면 EJB나 JMS를 사용한 애플리케이션을 개발하고자 하는 경우에는 반드시 JBossAS와 같은 Java EE 표준을 모두 구현한 서버를 사용해야 한다. 그러나 단순한 웹 애플리케이션을 구현하는 경우에는 Apache Tomcat을 사용할 수 있다. JBossAS에는 기본적으로 Tomcat이 내장되어 있으므로 Tomcat을 사용했었던 사용자는 손쉽게 JBossAS로 웹 애플리케이션을 이전할 수 있다.

 

 

<JBoss 주요 기술>

 

 

 

JBoss의 커널 : MicroContainer

JBoss MicroContainer(http://www.jboss.org/jbossmc) 프로젝트는 JBoss 하부 커널을 담당하는 프로젝트로 WAS를 구성하기 위해 필요한 Servlet/JSP 컨테이너, EJB 컨테이너, Deployer, 트랜잭션 관리 등 다양한 기능을 처리하는 JBoss.org 내의 프로젝트들의 결과물을 결합하여 애플리케이션 서버를 보다 수월하게 생성할 수 있도록 한다

 

대표적인 OR Mapper : Hibernate

Hibernate(http://www.hibernate.org/)는 대표적인 오픈소스 ORM(Object Relational Mapping) 프레임워크이다. 객체 모델링을 통해 도출된 데이터 구조를 저장소(데이터베이스)로 손쉽게 매핑할 수 있다.

 

사용자 인터페이스 기술 : JSP, JSF, AJAX

데이터 모형을 사용자 인터페이스에 효과적으로 연결하기 위한 방법론 설계 방식이자 MVC(Model-

View-Controller) 방식으로 웹 페이지를 개발하기 위하여 만들어진 Struts는 웹 개발에 널리 사용되어 왔지만, 몇 가지의 취약점을 보완하기 위해 Struts를 만든 Craig R. McClanahan은 본격적으로 사용자 인터페이스를 컴포넌트화할 수 있는 JSF(Java Server Faces)라는 JCP(Java Community Process) 표준을 만들어 냈다. JSF는 기본적으로 JSP를 화면 표시용 기술로 사용하지만 XUL(XML User Interface Language)과 같은 다른 사용자 인터페이스 기술을 활용할 수 있다. 또한 자바의 AWT나 Swing과 마찬가지로 완벽한 MVC 모델 기반으로 사용자 인터페이스를 만들 수 있고 컴포넌트화가 가능한 것이 특징이다.

 

Java EE IoC 프레임워크 : Seam Framework(JSR-299)

EJB 3.0과 JSF를 사용하여 개발하면 이전의 작업과 비교하여 많은 단순 반복 작업이 줄어 들지만 영속성 계층(Persistence Layer)과 사용자 인터페이스(JSF)의 연결을 위해서는 여전히 Backing Bean, Controller, DAO 등 단순 반복 작업이 필요하다. 이를 해결하기 위하여 IoC(Inversion of Control) 프레임워크인 Seam(http://seamframework.org/)을 고안하게 되었고 Google의 Guice와 함께 표준화 작업을 진행하여 Java EE 플랫폼을 위한 Java Context와 Dependency Injection(CDI)가 프레임워크 표준(JSR-299)인 Java EE 6 표준으로 채택되었다.

 

 

Seam 프레임워크는 Dependency Bijection이라는 양방향 Injection 기술을 사용하여 EJBJSF를 연결한다. 또한 컨버세이션(Converstaion)이라는 HTTP 세션보다 상세하게 상태를 관리하는 컨텍스트를 제공해 웹 애플리케이션 개발을 쉽게 한다. XML의 사용을 최소화하여 어노테이션 기반의 편리한 프로그래밍이 될 수 있도록 한다. SeamRule 엔진인 Drools, jBPM, JMS, Mail, PDF, AJAX 등 다양한 기술들을 통합하고 있다.

 

대용량 고가용성 서비스 : 분산 캐시

WAS에서는 대용량 서비스 지원 시 여러 WAS 인스턴스, 여러 대의 머신에 부하를 분산하여 서비스한다. 이런 서비스를 위해서는 부하를 분산하기 위한 Load Balancing 기술과 장애 발생 시 타 인스턴스에서 이전 작업을 계속할 수 있도록 상태정보를 복제해 놓는 작업이 필수다. TCP/IP 중 여러 대의 머신에 데이터를 전송하기 위한 기술로 멀티캐스트(Multicast)가 있다. 멀티캐스트 프로토콜은 그룹에 속한 모든 멤버(인스턴스)들에게 동시에 메시지를 전달할 수 있지만 메시지가 유실될 수 있다는 게 단점이다. 이에 대처하기 위해 메시지 유실 시 기본 멀티캐스트 프로토콜에 메시지의 재전송을 명령하고 큰 메시지는 작게 나누어 전송하며, 메시지 순서를 보장하는 등 통신의 신뢰성을 제공하기 위한 프로젝트(Reliable Multicast)JGroups(http://www.jgroups. org/)이다.

 

고성능 네트워크 애플리케이션 개발 : Netty

Netty는 고성능 고확장성 프로토콜 서버와 클라이언트를 신속하게 개발할 수 있도록 해주는 비동기, 이벤트 드리븐 네트워크 애플리케이션 프레임워크이다. 프로토콜 코덱(Codec)에 대한 처리, SSL/TLS 지원, HTTP 프로토콜 지원, Google Protocol Buffers(http://code.google.com/apis/protocolbuffers/) 통합 등 네트워크 애플리케이션 개발을 위한 다양한 기능을 제공하고 있다. Netty 프로젝트는 SMS 서버, 게임서버, 채팅서버, 포스 단말기 서버, RFID 서버 등 다양한 분야에서 활용되고 있다.

 
비동기 메시지 전송 : HornetQ(JMS)

MOM(Message Oriented Middleware)이란 메시지를 비동기적으로 전달하여 처리할 수 있는 특징을 가진 시스템이다. 이런 종류의 제품에는 IBMMQSeries, SonicMQ 등이 있다. 자바에서 이러한 메시징을 처리하기 위한 공통적인 APIJMS (Java Messaging Service)이며, 이는 Queue를 이용, 메시지를 PTP(Peer-to-Peer) 방식으로 전달하거나, 발행/구독(Publish-Subscribe)과 같이 여러 구독자에게 메시지를 동시에 전달하는 방식을 제공한다. 비동기 메시지 전송기능은 Java EE 표준에 포함되어 있어 Jboss 역시 HornetQ라는 프로젝트를 통해 JMS기능을 제공하고 있다. HornetQPOJO기반으로 설계되어 있어 별도의 메시징 서버로 동작할 수 있을 뿐 아니라 JBoss MicroContainer, Spring, Google Guice등 다른 프레임워크나 제품에 Embedded되어서 사용될 수 있다.

 

•엔터프라이즈 서비스 버스 : ESB

ESB(Enterprise Service Bus)는 SOA의 기반이라 할 수 있는 개방형 표준을 기반으로 한 비즈니스 시스템을 연결하기 위한 기술이다. 이 기술은 중앙의 서비스 레지스트리(UDDI)에 서비스 정보를 보관하고 서비스를 활용하여 새로운 서비스를 쉽게 만들어 낼 수 있게 하는데 JBoss ESB는 JMS를 기반으로 메시지 채널을 구성하여 메시지를 처리한다. SOAP, JMS, HTTP, FTP 등의 표준 메시지를 처리할 수 있으며 메시지의 변환이 필요한 경우 Smooks 변환엔진(http://www.smooks.org/)이나 XSLT를 사용한다. 또한 메시지의 라우팅을 위하여 Drools 룰 엔진이나 XPath를 사용할 수 있고 jBPM이나 BPEL을 사용하여 서비스를 오케스트레이션할 수 있다. 웹서비스, JMS 메시지뿐만 아니라 다양한 메시지 포맷을 받아 처리할 수 있도록 최신 버전에서는 Apache Camel(http://camel.apache.org/)을 게이트웨이로 사용할 수 있다.

 

복잡한 규칙 처리를 위한 Rule 엔진 : Drools

Rule 엔진이란 최소한의 지식(Knowledge)만으로 결론을 추론(inferencing)해 낼 수 있는 도구이다. 지식과 추론은 규칙(Rule)으로 정의되며 생성 규칙은 주어진 조건들이 True일 때 실행되는 Action으로 구성된다. 조금 복잡한 이야기인 것 같지만 간단히 말해 프로그램상에 존재하는 if-then-else와 같은 조건문들을 하나의 규칙(Rule)으로 분리하여 처리할 수 있도록 하는 엔진이다. 많은 수학적 기술들이 필요한 엔진이라고 할 수 있다. JBoss Drools는 이런 추론 엔진, 즉 Rule 엔진이며 RETE라는 패턴 매칭 알고리즘을 사용한다. JBoss Drools 프로젝트는 자바로 구현된 룰 엔진으로 이클립스 기반의 룰 개발/디버깅 환경과 웹 기반 률 관리 UI를 제공하며, 이는 규칙이 자주 변경되어 하드 코딩할 경우 유지보수 및 변경이 어려운 보험 업무, 제어 처리 등 다양한 분야에 활용되고 있다. 

 

경량 BPM 엔진 : jBPM

BPM(Business Process Management)은 기업의 비즈니스 프로세스를 체계적이고 효율적으로 관리할 수 있도록 하는 방법이며 이를 지원하기 위한 BPM 소프트웨어들이 있다. JBossjBPM 엔진은 비즈니스 분석가와 개발자 간의 협업을 쉽게 할 수 있도록 하며 오랫동안 실행되는 프로세스들을 비주얼하게 표시하는 데 사용된다. 또한 사람과 애플리케이션/서버 간을 중계하는 역할도 한다. jBPM은 일종의 State Machine이라고 할 수 있으며 언어중립적인 Process Virtual Machine이라는 프로세스 실행 엔진을 가지고 있다. 또한 다양한 프로세스 언어를 지원할 수 있도록 설계되었기 때문에 jPDL, BPEL, BPNM 등을 실행할 수 있다. 또 프로세스의 설계를 위해 이클립스 기반의 프로세스 디자이너를 제공하며 실행 상태를 모니터링하기 위한 웹 기반 콘솔을 제공한다.

 

데이터 통합 : Teiid

EII(Enterprise Information Integration)이란 조직 내의 모든 데이터를 단일한 인터페이스로 사용할 수 있도록 하는 데이터 통합 프로세스이다. 간단히 말해 여러 데이터 소스를 통합하여 마치 가상의 데이터베이스처럼 사용할 수 있도록 하며 JDBC, Web Services와 같은 인터페이스로 사용할 수 있도록 하는 기술이다.

 

 사용자 포털 : GateIn Portal

기업의 애플리케이션들이 개수 및 복잡도가 증가함에 따라 다양한 정보를 사용자에게 통합하여 제공하기 위한 방법이 필요해졌다. 이런 요구에 의해서 포틀릿(JSR 168)이라는 표준이 생겨났고 이 표준을 제공하는 것이 JBoss의 GateIn Portal (http://www.jboss.org/gatein)이다. 통합되는 대상에 따라 EIP(Enterprise Information Portal), KEP(Knowledge based Enterprise Portal), EAP(Enterprise Application Portal)로 구분될 수 있다. 포털은 포틀릿을 이용한 애플리케이션 통합 및 사용자별 개인화 기능을 제공하며 한 번 로그인하여 연결된 사이트를 이용할 수 있도록 하는 SSO(Single Sign ON), 콘텐츠 관리(JCR) 등의 기능을 제공한다.

 

 

 

정리

언급한 프로젝트 외에도 다양한 프로젝트들이 있지만 JBoss.org의 몇 가지 주요 프로젝트들을 살펴보았다. WAS를 구성하는 데 필요한 주요 핵심 컴포넌트들뿐만 아니라 WAS를 기반으로 한 다양한 서비스 프레임워크들도 개발되고 있다는 사실을 알게 되었을 것이다. 이외에도 OSGi, Ruby 언어를 JVM에서 실행할 수 있도록 하는 TorqueBox, VOIP 기술을 위한 Mobicent, Tuxedo같은 TP 모니터링 기능을 하는 BlackTie, 관리 및 모니터링을 위한 RHQ, 클라우드 컴퓨팅을 위한 StormGrind, Byte code 조작을 위한 Byteman, 테스트를 위한 여러 프로젝트들 등등 관심을 가질만한 다양한 프로젝트가 진행 중이다.

JBoss의 프로젝트들은 모두 독립적으로 활용될 수 있으며, JBoss WAS뿐 아니라 타 회사 제품의 WAS에서도 사용될 수 있도록 설계되고 있다. 따라서 각각의 핵심적인 프로젝트 모듈들이 독립적으로 동작할 수 있을 뿐 아니라 이 결과물들을 Seamless하게 묶어 WAS로 만들어 내고 있다.

참조. 위키피디아, 마이크로소프트웨어(2011.06)

 

 

블로그 이미지

(주)싸이크로스

(주)싸이크로스 www.sycros.com

댓글을 달아 주세요

하둡(Hadoop)

R&D/Sycros Road Map 2012. 6. 28. 17:11

Hadoop 모니터링

 

Hadoop에 대한 소개에 이어 Hadoop을 안정적으로 운영하기 위하여 일반적으로 알려진 Monitoring Metric에 대하여 알아본다.

Hadoop NameNode DataNode와 같은 데몬 프로세스 감시와 Heap Memory, Thread, Filesystem 등을 기본 Monitoring Metric으로 가진다.

 

Monitoring Metric

1)  NameNode Capacity: NameNode의 디스크 사용율 정보를 모니터링 한다.

 

Hadoop의 가장 중요한 구성 요소 중 하나는 확장성이 높은 HDFS 파일 시스템이다. 대개의 파일시스템들처럼 Hadoop역시 사용중이거나 남아있는 공간이 얼마나 되는가가 중요한 모니터링 항목이 된다.

 

2)   DataNode Capacity: DataNode의 디스크 사용율 정보를 모니터링 한다.

 

Hadoop 클러스터는 하나 이상의 DataNode로 구성되어 있고 DataNode는 다수의 대용량의 디스크를 가지고 있다. DataNode가 사용할 수 있는 디스크의 전체 사이즈와 사용 가능한 사이즈를 알 수 있다.

 

3)   Files Total: NameNode에서 관리하는 파일의 개수를 모니터링 한다.

 

Hadoop MB, GB, TB 단위의 다중 파일 관리에 적합하지만 NameNode에서는 메모리에서 관리할 수 있는 최대 파일의 개수를 제한하고 있다. 따라서 파일 개수의 감시는 그러한 물리적 제한으로 인한 장애를 예방할 수 있다.

 

4)  Blocks Total

 

Hadoop 파일은 큰 Block들로 이루어져 있다. 일반적인 파일시스템은 Block 하나의 사이즈가 4-16K인데 반해 Hadoop 64MB 또는 그 이상을 지원한다. Block에 대한 정보는 데이터가 HDFS에 최적으로 저장되고 있는지 또 Block Read, Block Written, Block Removed, Block Replicated 등을 통해 DataNode의 성능을 확인할 수 있다.

 

5)  Heap Usage: NameNode DataNode Heap Memory 사용량을 모니터링 한다.

 

 

참조:  JoinTheGrid.com Project Site          http://www.jointhegrid.com

Jaso extends j2ee                      http://www.jaso.co.kr/

 

 

 

 

'R&D > Sycros Road Map' 카테고리의 다른 글

하둡(Hadoop)  (0) 2012.06.28
블로그 이미지

(주)싸이크로스

(주)싸이크로스 www.sycros.com

댓글을 달아 주세요

빅 데이터의 시대 - 하둡(Hadoop)

 

500기가를 59초만에, 100테라바이트를 173분만에 정렬하는 하둡은 상상을 초월하는 데이터 분석 성능을

제공한다. 클라우드 컴퓨팅의 역사를 바꾸는 하둡!


 

최첨단 IT기술이 세상을 지배하고 있는 현재는 데이터 폭증의 시대이다.  

전 세계의 인터넷 사용자 수는 20억명 가량 되며 사용 중인 모바일 디바이스는 이미 46억대를 넘어서고 있다.

또한 전문가들은 현재의 데이터가 2015년까지 약 500% 성장할 것으로 전망하고 있고, 이렇게 매일 2.5퀸틸리언(100, 100만의 6제곱)바이트의 데이터가 생성되고 있는 상황에서 IT업체들은 이토록 엄청난 양의 데이터를 분석해야 하는 과제에 직면하고 있으며 이를 해결하기 위한 방법의 하나로 '하둡(Hadoop)'이 고안되었다.

하둡은 구글파일시스템(GFS)에서 비롯되어 구글이 자사의 서비스 플랫폼을 공개한 후 YAHOO의 개발자 더그 커팅이 만들어낸 빅데이터 처리 기술이다.

구글이 자신들의 검색 서비스를 위해 사용하고 있던 분산 파일 시스템인 GFS와 분산 처리 시스템 MapReduce에 대한 논문을 발표하면서 구글의 분산 시스템 방식이 널리 알려지게 되었다.

당시 오픈 소스 검색 엔진인 넛치(Nutch)를 개발 중이던 더그 커팅(Doug Cutting)은 넛치에서 웹 검색 수준의 대용량 데이터 처리를 위해 여러 대의 컴퓨터를 연결해서 작업을 수행하는 기능을 구현하는데 있어 많은 어려움을 느끼고 있었는데 마침 구글의 논문을 접한 더그 커팅은 여기에 나온 내용을 참고하여 구현한 소프트웨어가 바로 하둡이다.

이렇듯 하둡은 분산처리 시스템인 구글 파일 시스템(GFS)을 대체할 수 있는 하둡 분산 파일 시스템(HDFS)과 데이터를 분산시켜 처리한 뒤 하나로 합치는 기술인 맵리듀스를 구현한 오픈소스 프레임워크다. 아파치 소프트웨어 재단 소속으로 HDFS외 피그, H베이스 같은 프로그래밍 언어를 포함하고 있다.

하둡은 페이스북과 야후, 국내의 네이버 등 인터넷 서비스업체에서 활발히 사용되고 있으며 최근 KT가 유클라우드 서비스를 위해 하둡 전문업체 넥스알 인수를 발표하면서 더욱 인기가도를 달리고 있다.

가상화시스템을 주도하고 있는 클라우드 컴퓨팅은 한 인프라에 존재하는 이용자 정보량도 셀 수 없을 정도로 많으며 이 막대한 데이터를 안정적으로 관리하지 못하면 클라우드 컴퓨팅을 도입한 이유마저 사라져 버리게 된다.

또한 클라우드를 도입하는 기업들은 비용대비 최대 효과를 노리기 때문에 인프라비용을 최대한 줄이게 되고, 클라우드 사업자는 저가 하드웨어로 인프라를 채우면서 오픈소스 SW로 안정성을 높이는 게 일반적이기 때문에 안정성을 높이는 한편 이러한 대용량 정보를 저장, 분석하기 위한 수단으로 하둡을 선호하게 되었다.

2007 11월 마이크로소프트의 CEO인 스티브 발머는 "10년 후에는 사내에서 운용되는 서버는 클라우드로 이행되어 사라진다."라고 말했다. 썬마이크로시스템즈의 CTO인 그렉 파파도폴라스는 "세상에는 단 5대의 컴퓨터만 있으면 된다. 구글, 마이크로소프트, 야후, 아마존, 이베이, 세일즈포스닷컴이다." 라고 말했다. 이는 왜 클라우드 컴퓨팅 시대가 올 수 밖에 없는지를 단적으로 말하고 있는 것이며 앞으로 클라우드 컴퓨팅과 하둡과의 관계가 더욱 긴밀해 질 수밖에 없음 말하고 있는 것이다.

 이렇게 급격한 성장가도를 달리고 있는 하둡에 대해 IDC하둡과 맵리듀스 생태계 소프트웨어 풍경 2012′라는 보고서를 통해 2011 7700만달러 수준인 하둡과 맵리듀스과 관련 시장이 2016년이 되면 81280만달러에 이를 것으로 보인다고 분석했다. 매년 60% 넘게 성장하는 셈이다. 또한 IDC 애널리스트는 보고서를 통해 이번 기회에 말로만 무성했던 하둡과 맵리듀스 시장의 실체와 가능성을 파악하고, 이들이 비구조화된 데이터로부터 기존에는 발견하지 못했던 새로운 가치를 만들어내고 있다는 사실을 깨닫게 됐다라며 지금까지는 하둡에 대한 개념 정리가 주를 이뤘다면, 2013년부터는 하둡을 통해 실제로 가치를 만들어 내는 방향으로 관련 시장이 발전할 것으로 보인다라고 설명했다.

허나 “하둡이 급속도로 성장한 것과 달리 하둡을 다룰 수 있는 개발자 수는 현저히 부족하다라며 이는 앞으로 2~3년 동안은 하둡이 성장하는 데 한계로 작용할 것으로 보인다라는 지적을 받은 것은 하둡의 장미빛 미래 이면에 반드시 풀고 나가야만 하는 여러 가지 과제를 품고 있다는 사실 또한 알려주고 있는 것이다.

 


하둡 기술 요소

 하둡은 분산 파일 시스템인 HDFS(Hadoop Distributed File System)분산 처리 시스템인 MapReduce로 구성되어 있다. HDFS MapReduce는 둘 다 Master/Slave 구조인데 HDFS에서 Master Name node, Slave Data node라고 부르며 MapReduce에서는 각각 JobTracker TaskTracker라고 부른다.

HDFS에서는 Master Name node가 파일의 메타(meta) 정보를 관리하고 실제 데이터는 여러 대의 Data node에 분산해서 저장한다. 이 때, 데이터는 일정 크기(default 64MB)의 블록단위로 나뉘어 관리되며 이 블록들을 여러 대의 Data node에 분산 및 복제해서 저장한다. 이렇게 하는 이유는 일부 Data node에 장애가 발생하더라도 전체 시스템에서 데이터를 읽고 쓰는데 문제가 없도록 하기 위함이다.

MapReduce는 이렇게 HDFS에 분산 저장된 데이터를 여러 대의 TaskTracker에서 병렬로 처리함으로써 대용량의 데이터를 빠르게 처리하고자 만들어진 시스템이다. 특히 MapReduce JobTracker에서 TaskTracker의 상태 및 전체 작업의 진행 상황 등을 지속적으로 감시하며 일시적인 장애에 대해서 자동으로 복구하는 기능을 제공하기 때문에 일부 TaskTracker 장비에 문제가 발생하더라도 전체 작업이 진행되는데 문제가 없도록 설계되어 있다. 또한 JobTracker가 여러 대의 TaskTracker에게 자동으로 작업을 할당하고 결과를 통합해 주기 때문에 사용자는 전체 작업 흐름 및 세부 사항에 크게 신경쓰지 않고 데이터 처리 로직에만 집중할 수 있다.

 

참조.

gimmesilver's blog Hadoop_Guide_ext.pdf  (URL  http://Agbird.egloos.com)

 

※ 빅데이터 관련 기사

핫이슈-분석엔진 `R` 분석시장 판도 바꾼다 - 전자신문 <2012.05.06 일자>

배포 제한없는 오픈소스...하둡과 만나 분석시장 '큰 일 낸다' - 전자신문 <2012.05.07 일자>

 

 

블로그 이미지

(주)싸이크로스

(주)싸이크로스 www.sycros.com

댓글을 달아 주세요