효과적인 버그 처리 방법

HannaKim님의 이 버그를 누구에게 넘겨 줄 것인가? 라는 글에 대한 의견을 적어보려고 합니다.

의견이라기 보다는 주욱 해오던 방법입니다. 너무 당연한 얘기일수도 있습니다.

개발자에게 버그를 할당하여 처리하는 방법은 여러가지 형태가 있습니다.

주먹구구식으로 개발자에게 직접 버그가 보고되고 처리되는 형태부터 철저한 Workflow를 따라서 관리자가 담당개발자를 할당해서 처리하는 방법까지 다양합니다.

여기서는 자질구레한 기타 방법은 제외하고 정상적으로 Bug Tracking System를 사용하면서 체계적으로 버그를 관리하고 해결하는 방법 내로 국한을 해서 설명하도록 하겠습니다. 다른 방법을 사용하고 있다면 심각성을 깨달으시고 빨리 방법을 고치셔야죠.

개발팀의 규모나 프로젝트의 종류는 천차만별입니다. 기술을 잘 아는 관리자가 있기도 하고 기술을 잘 모르는 관리자가 있기도 합니다. 하루에 버그가 하나도 보고되지 않을 수도 있고, 하루에 수백개의 버그가 보고되는 경우도 있습니다.

이러한 모든 경우에도 버그는 가장 적절한 개발자에게 신속히 할당이 되어서 신속히 해결을 해야 합니다. 해결이라함은 꼭 버그를 Fix하는 것을 의미하는 것이 아니고 연기할 수도 있고, 수정하지 않기로 할 수도 있고, 버그가 아닌 경우도 있죠. 어쨌든 이런 요구를 항상 만족시키기란 쉽지 않죠.

그래서 사람들이 찾아낸 방법이 "자율"입니다. 완전한 자율은 아니고 "Process"와 적당히 혼합된 "자율"입니다. 소프트웨어 개발에 있어서 "자율"은 매우 자주 등장하니 그리 놀랄 일도 아닙니다.

버그할당의 의무와 역할을 관리자에게만 두는 것이 아니고, 개발자도 그 역할을 조금씩 나눠 갖는 겁니다.

버그가 보고되면 관리자나 관련 개발자나 누구나 먼저 인지를 한 사람이 버그를 할당하는 겁니다. 여기서 버그를 할당했다고 해서 당장 버그를 고친다는 의미는 아닙니다.(이는 버그 관리 정책에 따라서 다릅니다.)

모든 개발자가 모든 버그를 다 감시할 수는 없겠죠. 버그의 카테고리는 기능별, 모듈별로 모두 등록을 해 놓아서 카테고리와 담당개발자의 연관성을 높이고 개발자들은 자신과 주로 관련된 카테고리들만 감시를 해도 충분합니다. RSS Feed를 지원하는 Bug Tracking System이 있으면 이렇게 감시를 하기 편리합니다. 그리고 나면 버그 해결 스케쥴은 시스템을 이용하여 정할 수도 있고, 회의를 하기도 합니다.

버그할당의 최종 책임은 관리자에게 있으므로 이렇게도 할당이 안된 버그는 관리자가 처리를 해야죠.

이러한 방법은 대부분의 경우에 상당히 효율적입니다만, 자율에 의한다는 것은 각 구성원의 성숙도에 많은 영향을 받으므로 이를 감안해서 시행해야 할 것입니다. 

버그의 처리에는 시간이 걸릴 수 있어도 버그의 인지는 신속해야 하고, 버그의 할당도 빠르게 이루어져야 합니다. 버그인지 자체가 일주일 이상 걸리는 상황이라면 그 기간 동안 버그는 완전히 방치가 되고 있는 상황이라고 할 수 있습니다. 그래서 회사에 따라서는 버그 인치와 처리 시간을 줄이기 위해서 KPI에 이 수치를 포함해서 평가의 지표로 삼곤 하는데, 별로 바람직한 시도는 아닙니다. 어차피 자율에 의한 방법이기 때문에 좀더 성숙한 개발 문화와 이를 북돋울 약간의 당근만이 필요할 뿐입니다.

오늘도 밤을 세워야 하는 개발자 (야근 탈출)

옛날부터 내려오는 경영자들이 믿고 있는 미신이 있습니다.

"개발자의 Output은 근무시간의 양에 비례한다."

말은 아니라고 하면서도 밤에 사무실이 텅 비어 있으면 개발자들이 군기가 빠졌다고 생각하고 주말에 누가 나와서 일하나 확인하러 가끔 사무실에 들르는 사람들이 경영자입니다.

실제로 근무시간에 성과가 비례하는 개발자들이 있다면 공장에서 벽돌 찍어내는 것과 다를 바가 없겠지요.

이 미신은 믿기 싫지만 자꾸 저절로 손이 가는 새우깡처럼 믿게 되고, 회사 조직에서 위로 올라갈수록 더 맹신하게 되나 봅니다.

이러한 이유로 어쩔 수 없이 또는 습관적으로 야근을 하는 개발자가 있다면 십중팔구 미혼이거나 결혼을 했어도 아이가 없겠죠.

이런 정상적이지 않은 생활을 하며 10, 20, 30년간 소프트웨어 엔지니어 일을 할 수는 없겠죠.

나는 "개발은 창의적인 작업으로 그 성과는 충분한 재충전에 나온다"고 믿고 있습니다.

그렇게 합리적인 시간에 개발을 하려면 소프트웨어 개발은 좀더 체계적이고 효과적으로 진행해야 합니다.

지금의 일반적인 경우처럼 일단 프로젝트를 시작해서 개발자들이 능력껏 그럭저럭 진행하는 방법으로는 또 개발자의 야근은 피할 수 없고, 별로 빠르게 끝나지도 제품의 품질이 좋지도 않게 됩니다.

그래서 소프트웨어 개발에 소프트웨어 공학을 적용하는 것이지요.

말은 거창한 것 같지만, 소프트웨어 공학이라는 것이 소프트웨어를 최소비용으로 최단기간에 개발하기 위한 온갖 방법들을 말하는 겁니다. 결코 교과서의 내용이 아니고 현실에서 수많은 회사들이 경험을 통해서 내려오는 방법이고 여러분들도 상당부분은 익히 알고 있는 방법들입니다. 이 블로그의 주제이기도 하고요.

다시 개발자들이 밤을 세지 않기 위한 방법으로 되돌아 와서 그 방법을 알아봅시다.

일단, 경영자의 인식이 바뀌어야 하는 것은 당연한 일인데, 어떻게 손을 델 수가 없는 일입니다.

그리고 나면 아래와 같이 개발자들과 프로젝트팀이 행할 수 있는 3가지 방법이 남습니다.

• 정확한 일정 예측
• 체계적인 개발 방법 
• 합리적인 일정 복구 

첫째, 정확한 일정 예측입니다. 이는 모순된 문장입니다. 어떻게 예측을 정확하게 하나요? 하지만 예측이란 그때 상황에서 최선을 다해 정확하게 예측을 해야지요. 

당연히 프로젝트가 시작하자마자 정확한 예측은 불가능합니다. 아직 스펙이 정해지지 않았거든요.

그래서 프로젝트가 시작할 때는 대충을 일정을 가지고 시작을 하다가 스펙 작성이 완료되면 스펙을 근거로 1,2일 단위의 정확한 WBS를 작성하여 소요일정과 투입인력을 따져서 프로젝트 일정을 작성해야 합니다.

회사의 모든 관련자들은 프로젝트가 시작할 때 정해진 일정을 진짜 일정으로 봐서는 안됩니다. 스펙 완료 후 작성된 일정을 진짜 일정으로 봐야지요. 이것을 당연히 이해 할 수 있어야 얘기가 되지요.

그리고도 일정은 개발중간에 지속적으로 점검하며 일정이 틀어지면 대응을 해야 합니다. 1,2일 단위로 작성된 일정은 조금만 늦어져도 금방 문제를 파악할 수 있습니다.

둘째, 체계적인 개발 방법입니다. 

이 부분은 책 한 권을 써도 될 만큼 많은 양이고 앞으로 블로그에서 지속적으로 다룰 내용이니 간단히 소개만 하겠습니다. Stage를 따라서 개발을 하거나, Daily Build를 하고, 소스코드관리/버그관리시스템을 사용하고, 피어리뷰/코드리뷰를 하고, 모든 이슈를 투명하게 Open하고, Build를 자동화하는 등 수많은 방법들을 당연히 사용해야 할 것 입니다.

셋째, 합리적인 일정 복구입니다.

프로젝트는 어쨌든 늦어지게 마련입니다.  

다음 그림을 보면 현재 프로젝트 진척이 계획보다 늦어지고 있습니다. 이럴 때 다음 4가지의 방법이 있습니다.

A. 더 낮은 우선순위의 요구사항은 다음 버전으로 연기한다. 

B. 개발자를 추가로 투입한다. 

C. 시간외 근무를 단기간 동안 강제로 시킨다. 

D. 일정을 연기하여 추가된 기능을 수용한다. 

여기서 대부분의 회사가 C를 주로 선택하고 가끔 B를 선택합니다.

C는 단기적으로는 효과가 있지만, 이 기간이 길어지면 별로 효과도 없을 뿐더러 개발자 사기만 떨어지고 회사의 경쟁력도 잃고 개발자도 잃게 되는 방법입니다. 

B는 효과가 거의 없는 것으로 익히 잘 알려져 있습니다. 프로젝트 후반에 개발자를 투입하는 것은 기존에 열심히 개발하고 있는 다른 개발자들에게 방해만 되는 경우가 허다합니다. 기존 개발자들은 이들을 가르치느라고 시간을 허비해야 하고, 새로 투입된 개발자는 별로 성능을 발휘하지 못하며 버그도 많이 만들어내는 경우가 허다합니다.

프로젝트가 늦어지고 있는지 전혀 신경을 쓰지 않다가 프로젝트 막바지에 가서야 한참 늦어지고 있다는 보고를 받고 부랴부랴 대책을 세울 때 선택하는 방법이죠.

가장 좋은 방법은 A입니다.

여기서 중요한 점은 모든 프로젝트를 시작할 때 프로젝트가 늦어질 수 있다는 것을 미리 생각해야 한다는 것입니다.

그래서 스펙의 각 기능은 Priority(우선순위)를 정해줘야 합니다. 그래서 일정이 늦어지면 우순선위가 낮은 기능을 연기하고 프로젝트를 종료하는 것입니다. 그러기 위해서는 개발 순서도 우선순위가 높은 기능부터 개발이 진행되어야 합니다.

이러한 모든 것들이 체계적으로 합리적으로 진행이 되어야 중요한 프로젝트를 하더라도 퇴근 후에 가족과 식사를 하고 아이들과 놀 수 있는 시간이 생깁니다.

위와 같이 합리적이고 체계적인 절차에 의한 데이터를 근거로 경영층에 보고가 되고 투명한 개발진행이 경영층에 신뢰를 준다면 하루 8시간 근무하는 날이 점점 늘어 날 수 있을 것입니다.

개발자 혼자서 할 수 있는 일은 결코 아니고, 회사가 조직, 프로세스, 시스템등 모든 것이 바뀌어 나가야 가능한 일입니다.

이미지출처 : Microsoft Office Online

우리 개발자는 뭐든 뚝딱 잘 만들어요.

소프트웨어를 개발하기 위해서는 기본적으로 갖춰야 할 인프라스트럭쳐시스템(Infrastructure System, 기반시스템)에 대해서 이미 본 블로그에 글을 올린 적이 있습니다.

그런데 여러 회사를 만나보니 이러한 시스템 중에서 일부를 직접 만들어서 사용하려는 경우를 종종 접하게 됩니다.

이런 회사를 "Tool company"라고 부릅니다.

자신들의 주력 제품이 아니고 개발하기 위해서 필요한 툴들을 만들어서 사용하려는 회사를 말합니다.

물론 워낙 특수한 형태의 툴로서 세상에 존재하지 않거나 구할 수가 없는 예외적인 경우도 있습니다.

하지만 개발 프로세스에 일반적으로 필요한 시스템들은 직접 만들어서 사용한다는 것은 큰 문제입니다.

특히, 버그관리시스템이나 프로젝트관리시스템을 만들어서 사용하거나, 만들려고 시도하는 회사가 많습니다.

그런 회사들은 이렇게 말합니다.

• 우리회사는 다른 회사와 다르다. 우리는 임베디드 소프트웨어를 개발한다. 우리는 금융회사다. 우리는 게임회사다. 우리는 포탈이다. 이유도 많습니다.
• 상용제품의 우리회사만의 요구사항을 만족할 수 없다.
• 우리가 만들면 사용제품보다 더 잘 만들 수 있다. 
• 우리 입맛에 딱 맞게 만들 수 있다. 그리고 필요할 때 언제든지 수정해서 사용할 수 있다.

특히, 개발자들이 이런 주장을 하는 경우가 흔합니다. 개발자들은 이런 것을 만드는 일을 만만하게 보는 경우가 많습니다. 경험이 적은 개발자들은 단순히 코딩해서 동작하도록 구현하는 것만 생각하는 경우가 흔합니다. 그 뒤에서 수십배의 일과 문제가 기다리고 있다는 것은 잘 모릅니다.

당장 원하는 기능의 툴을 만드는 것은 어려운 것이 아닙니다.

일단 툴을 만들어서 사용하기 시작하면 개미지옥에 빠져든 개미처럼 점점 빠져들며 헤어나오기 어려워집니다.

이렇게 만들어진 툴도 하나의 소프트웨어로서 유지보수가 필요해집니다. 기존의 버그도 잡아야겠고, 사용하다가 불편하면 계속 수정사항을 요구합니다. 

만들 때는 간단해 보였는데, 쓰면 쓸수록 손 볼일이 많아집니다.

본연의 개발업무에 집중해야 할 개발팀이 내부 툴 유지보수 하느라 시간을 낭비하고 쓸수록 기능도 만족스럽지 않다는 것을 알게 됩니다.

일단 우리회사는 다른 회사와 다르다고 생각하는 것은 좁은 시야와 경험의 부족에서 오는 착각입니다. 그리고 상용제품이 우리회사의 요구사항을 만족할 수 없는 것이 있다면 회사가 바뀌는 것이 좋습니다. 이 경우 회사의 프로세스가 잘못되어 있을 확률이 99%이상입니다. 사소하게 보아 넘기는 기능 하나하나에 깊은 의미가 있다고 생각하고, 좋은 툴이라면 거기에 맞추겠다는 생각으로 회사의 프로세스나 조직, 문화 등을 먼저 다시 생각해보는 것이 좋겠습니다.  

좋은 툴을 도입하는 것은 단순히 비용을 절약하는 것을 떠나서, 회사의 개발 프로세스까지 선진화된 형태로 바꿀 수 있는 힘이 있습니다. 반대로 말하면 이러한 툴이 없이 제대로 된 개발 프로세스로 개발을 하는 것이 불가능하다는 의미이기도 합니다.

이러한 것을 만들어서 쓰려는 "Tool Company"가 되어서는 안되고 좋은 툴을 찾아서 전사적으로 사용하면서 선진적인 개발프로세스와 문화를 받아들이는 자세가 필요합니다.

고객중심의 서비스 마인드가 소프트웨어 산업을 망친다.

부제 : Global mind를 가져라.

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

TV가 고장나서 전화하면 수리기사가 바로 달려와서 고쳐주고 갑니다.

핸드폰이 고장나서 서비스센터에 가면 바로 고쳐줍니다.

뭐든지 바로바로 해결이 되죠. 

하지만 미국에서는 좀 다릅니다. 노트북이 고장나면 바로 해결이 안됩니다. 서비스센터에 맡겨도 서비스센터는 단순히 포장만해서 수리공장으로 보내는 경우가 대부분이고 오래 걸리면 한달이 걸리기도 하고 재수 좋으면 그보다는 빨리 받아 볼 수 있죠.

미국은 땅덩어리가 워낙 커서 가 도시마다 전문서비스기사를 둘 수도 없습니다.

부른다고 쪼르륵 달려갈 수도 없습니다. 비행기타고 몇시간 날아가서 차 랜트해서 또 한참 가야지만 고객을 만날 수 있거든요. 또 고객이 비행기타고 핸드폰 수리하러 갈 수는 없죠.

소프트웨어도 마찬가지입니다. 고객이 소프트웨어를 구매하고 나서 수시로 개발사의 엔지니어를 불러서 이거 봐줘라, 저거 봐줘라, 이렇게 바꿔달라, 이런 요청을 할 수 없습니다.

물론 Enterprise Solution들은 유지보수 계약을 맺고 서비스를 받지요. 그 종류도 다양하고 서비스도 시스템화 되어 있지요. 물론 그 대가를 지불해야 하구요.

엔지니어를 부르는 것은 매우 비싸지요. 그리고 유지보수 건으로 개발자를 부른다는 것은 상상하기 힘들죠.

하지만 우리나라에서는 장애 시 사과 차원에서 개발자가 가서 인사를 해야 하는 어처구니 없는 경우도 있더군요. 문제를 만든 사람이 와서 사과를 하라는 거죠.

미국에서는 이러한 환경이 제품을 만드는 마인드부터 달라지는 것 같습니다.

일단 미국 어디에 파나, 전세계 어디에 파나 컨셉은 거의 같구요. 제품은 문제 생기면 쪼르륵 달려가서 해결해야 하는 형태로 만들지는 안죠. 제품의 품질을 떠나서 마인드가 다르니 접근을 다르게 합니다. 제품의 기능이나 UI에 그러한 마인드가 묻어나고, 개발 문서도 제대로 만들고, White paper도 만들죠. 문제가 생겼는데, 거의 모든 정보가 개발자의 머리 속에 있으면 안되거든요.

물론 고객도 이거 저거 바꿔달라는 요구는 잘 못하죠. 요구가 있다고 해서 다음 버전에 꼭 넣어 달라고 강요도 못하고 그건 개발사가 알아서 할 일이죠.

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

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

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

결국 마인드를 바꿔야만 됩니다.

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

우리나라에서

처음부터 글로벌 마인드를 가지고 시작하는 제품이 좀더 많아지면 좋겠습니다.

이러한 글로벌 마인드를 가진 개발자와 회사가 많아지면 좋겠습니다.

작더라도 전세계 사람들이 사용하는 제품이 많아지면 좋겠습니다.

고객이 부른다고 쪼르륵 달려가지 않아도 되는 제품이 많아지면 좋겠습니다.

고객서비스가 비싼 상품이라고 인식하는 고객이 많아지면 좋겠습니다.

개발자 불러다가 이거 저거 고쳐달라고 해도 된다는 인식이 적어지면 좋겠습니다.

우리나라 개발자들이 많은 수많은 제품이 세계를 호령하는 날이 오면 좋겠습니다.

우리나라에는 전지전능한 슈퍼 개발자가 있다.

여러 소프트웨어 회사를 컨설팅하다보면 아주 많은 개발자들을 만나게 됩니다. 

그 중에는 전지전능한 슈퍼 개발자를 만나게 됩니다.

코딩, 설계, 분석, 테스트, 기획, 고객 전화응대, 고객 지원, 프로젝트 관리, 일반 관리, 아키텍처 등등 엄청나게 많은 일을 하는 개발자들을 보게 됩니다.

이들은 대부분 팀장 쯤 됩니다.

어떻게 생각하시나요? 

바람직해 보입니까?

"나도 그런 전지전능한 개발자야 돼야지"라는 생각이 드십니까?

혹시 지금 이렇게 모든 분야의 일을 다 하고 계시나요?

이것은 One man company 얘기가 아닙니다. 

개발자가 100명이 넘는 회사도 이러한 경우를 여럿 봤습니다.

대부분은 회사가 성장과정에서 적당한 때에 조직을 변화시키지 못하고 그냥 달려온 경우입니다.

이런 경우 전지전능한 개발자가 대부분의 기술과 이슈를 꽤 뚫고 있어서 조직이 그럭저럭 굴러갑니다. (개발자들은 몰라도 사장님은 고민 많으실 겁니다.)

모든 길은 로마로 통하듯 모든 기술적인 이슈도 이 전지전능한 개발자를 통해야 해결됩니다.

이런 개발자가 나가면 회사는 망할 것만 같습니다.

이러한 상황이 정상일까요?

어떤 사람도 서로 완전히 다른 Skill set들을 필요로 하는 일들을 동시에 다 잘 수행해 낸다는 것은 불가능합니다. 아주 작은 회사라면 그렇게 해야지요. 다른 대안이 없으니까요.

이렇게 모든 일을 다하는 전지전능한 개발자는 그 모든 업무를 다 잘 못하고 있다고 봐야 합니다. 그건 애초에 불가능합니다.

이들은 예전에는 뛰어난 개발자였습니다. 하지만, 개발 이외의 일들을 하나씩 떠 맡으면서 각 분야의 일들의 전문성이 점점 떨어지게 됩니다. 그리고 각 일의 Switching cost가 만만치가 않습니다. 이일하다 저일하다하면 그냥 시간이 지나가버리지요. 톰 디마르코는 몰입에는 15분의 시간이 필요하다고 했습니다. 전화한번만 받아도 15분은 그냥 추가로 까먹는거죠.

심지어는 테스트, 고객 전화응대, 고객 지원까지 한다는 것은 100원의 돈을 받으면서 20원짜리 일을 하는 것과 같습니다. 그런 일은 싸게 고용할 수 있는 사람을 시켜야지요. 그리고 기획 같은 일은 전문성이 부족하여 제대로 수행하지도 못합니다. 

결국 이 개발자는 다른 소프트웨어 회사에 가면 별로 가치 없는 개발자가 되고 맙니다. 분야가 달라지면 Domain Knowledge에 의한 경쟁력을 잃고, 개발 실력도 경력에 걸맞지 않게 떨어지고 어느 것 하나 특출난게 없게 됩니다. 관리자로 가야 할까요? 그래서 회사에 꼭 붙어 있으려고 하고, 정치를 하면서 세력을 키우고, 회사의 개혁이나 변화를 반대하고, 골치덩어리 영웅이 되고 맙니다.

회사는 이들에 의존도가 커져서 리스크를 감당할 수 없는 수준에 이르게 됩니다.

이들이 등돌리면 회사는 휘청합니다. 

이것이 개발자 탓일까요? 아니면 회사 탓일까요? 

네, 회사 탓입니다. 회사는 개발자가 실력을 발휘할 수 있도록 여건을 조성해주고 훈련도 시켜줘야죠.

그런데 맨땅에 개발자가 북치고 장구치고 다 하다 보니까, 어쩌다보니 그렇게 된 것이지요.

그럼 어떻게 해야 할까요?

조직이 작을 때부터 나중에 커질 때를 대비해야 합니다.

조직이 커지면 언제든지 분리하기 쉬운 업무부터 띄어낼 수 있도록 말입니다.

이렇게 하려면 갖춰야 할 것이 3가지 있습니다.

이는 "프로세스"와 "기반시스템" 그리고 "문서"입니다.

이 3가지가 있어야 개발 조직이 전문적으로 움직일 수 있습니다.

단 제대로 갖춰야지요. (제대로의 의미는 너무 많이 설명해야 하니 앞으로 계속 올리는 글에서 설명하도록 하죠, 그리고 사실 문서는 프로세스에 포함된 것입니다.)

혼자 일을 하더라도 "스펙"을 작성하고 "설계문서"도 작성하고 "Test Case"도 만들어 놓습니다. 물론 남에게 일을 시키는 것보다는 간소화 할 수 있습니다.

인도에 외주를 줄만큼 자세히 작성하는 것은 낭비죠.

그리고 적절한 개발 프로세스를 만들어서 조직이 커질 때마다 그에 알맞게 계속 발전시켜나가야 합니다.

그리고 "소스코드관리시스템"과 "버그(이슈)관리시스템"은 무조건 제대로 갖추고 있어야 합니다.

이전 포스트 참조하세요(기반시스템(Infrastructure System)을 사용하고 계신가요?)

이 모든 것은 혼자 소프트웨어 회사를 한다고 해도 갖추고 있어야 합니다.

프로세스, 문서 얘기가 나오니까 오히려 개발이 늦어질 것 같은가요?

혼자 개발을 해도 이것들은 꼭 필요합니다. 개발이 더 빨라지고, 제품의 품질도 올라가죠.

왜?

지금 이해가 가지 않는 분이라면, 여기서 납득을 시켜드릴 수는 없습니다. 

제 책(소프트웨어개발의 모든 것)을 읽어보시거나 저를 찾아오시면 친절하게 설명드리겠습니다.

각설하고..

그렇게 준비가 되고 나면 회사 커지면 직무를 하나씩 전문화시켜야 합니다.

우선 "테스트팀"을 만드십시오. 회사가 작다면 이들이 Technical Support(고객지원)도 병행할 수 있을 겁니다. 

물론 테스트 직무도 전문화를 시키십시오. Random Test가 아닌 제대로 된 절차에 의한 테스트를 할 수 있도록 훈련시켜야 합니다. 그 방법은 제 책을 포함해서 시중에 좋은 책들이 얼마든지 있습니다.

그리고 개발자가 많아지면 관리자를 나누고, 기획, 프로젝트 관리자, 빌드/릴리즈 역할을 나눠 나갈 수 있을 겁니다. 

아직 "프로세스", "기반시스템", "문서", 이런 것들을 갖추고 있지 않은 회사라면은 조직을 어떻게 바꿔도 결국 그 전지전능개발자에게 커뮤니케이션이 다 몰리고 리스크는 여전할 것입니다.

이렇게 회사를 바꾸려면 개발자나 회사나 모두 "성장통"을 감내해야 합니다.

개발자는 현재 자신이 하는 일에만 가치가 있다고 생각하면 안됩니다. 좀더 큰일을 하기 위해서 과감하게 현재의 일을 버리고 자신이 가장 잘하는 일에 집중해서 더욱 가치를 높여야 합니다.

회사는 이 과정에서 임시적을 생산성이 떨어집니다. 이 기간이 짧게는 5,6개월에서 길게는 1년이 갈 수도 있습니다. 부작용을 최소화 하기 위해서 점진적인 변화를 할 수도 있고, 전문가를 영입하여 한번에 바꾸는 방법도 있습니다.

회사 안에 있으면 경영자나 개발자나 이러한 상황을 잘 느끼지 못하는 경우가 많습니다.

개구리를 냄비 안의 찬물에 넣고 서서히 데우면 뜨거워서 견지디 못하는 순간이 될 때까지 잘 느끼지 못하는 것과 같은 거죠.

그냥 익숙해지는 겁니다.

이런 경우 외부의 전문가가 회사를 분석하는 것이 효과적일 때가 많습니다.

궁금하신 내용이 있으면 언제든지 E-mail([email protected])으로 연락주세요. 궁금증을 시원하게 풀어드리지요. 

장문의 글을 읽어주셔서 감사합니다.

우리나라 소프트웨어 회사에는 Technical career path가 없다.

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

"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들입니다.)

소프트웨어 아키텍처는 어디에서 오는 것일까?

오늘은 아키텍처와 비즈니스의 관계에 대해서 적어볼까 합니다.

아키텍처… 비즈니스… 둘간의 무슨 관계가 있을까요?

별 관계도 없어 보이고…

혹시 제품의 아키텍처를 구성하고 설계를 하시고 계시나요? 그렇다면 비즈니스에는 얼마나 관심을 가지고계십니까? 

기술은 기술, 비즈니스는 비즈니스, 별 관계없다고 생각하실 수도 있습니다. 

결론은 말씀 드리면 "소프트웨어 아키텍처는 비즈니스에서 나온다."입니다.

이 글을 쓰게 된 주된 이유는 많은 선임, 고참 개발자들이 기술에만 관심을 가지고 비즈니스에 별 관심이 없는 경우를 많이 봐왔기 때문입니다.

개발자는 상위 개발자가 될 수록 비즈니스를 알아야 합니다. 아키텍처에 대한 대부분의 결정은 단순히기술적인 결정이 아닙니다. 비즈니스를 제외하고 기술적인 결정만 있는 경우는 별로 없습니다.

지금 만드는 제품이 딱 한 회사만 사용할지 100개의 회사가 사용할지 100만개의 회사가 사용할지에 따라서제품의 아키텍처는 완전히 달라집니다.

또 내년에는 100개의 회사만 사용하지만 내 후년에는 10,000개의 고객을 가질 것이라면 또 달라집니다.

한국에서만 팔 것인지, 아시아권에만 팔 것인지, 미국, 유럽에도 진출할 것인지에 따라서 Localization이슈가완전히 달라지고, 1,2년은 한국에서만 팔지만, 추후 유럽에서도 판매할 의도가 있다면 미리 이를 고려하지않으면 안됩니다.

그리고 이러한 아키텍처 관련된 결정은 매우 중요해서 잘못된 결정이 엄청난 손실을 가져옵니다. 코드 좀 잘못 짜고, 버그 좀 만드는 것과는 차원이 다릅니다.

이러한 비즈니스적인 요소를 고려하지 않고, 그냥 기술적으로 기능이 동작하는 정도만 생각하고 소프트웨어를 개발하고 있다면 선임개발자로서의 자격이 부족하다고 할 수 있습니다.

따라서 선임개발자가 되면 비즈니스에 대해서 부지런히 관심을 가지고 공부를 해야 합니다. 회사 내부만 보지 말고 Global한 시장이 어떻게 돌아가는지도 관심을 가져야 합니다.

아키텍트(Software Architect)가 되는 첫 걸음은 기술이 아니고 비즈니스를 알아가는 것입니다.