나쁜 습관

소프트웨어 회사가 프로세스를 제대로 정립하고 좋은 툴을 도입하고 개발문서도 잘 써보려고 노력하고 코딩 실력이 뛰어난 개발자들을 보유하고 있어도 넘기 힘든 벽이 있다.

우리나라 개발자들이 코딩 실력이 좋다는 것은 부정하고 싶지 않다. 처음에는 주먹구구식으로 시작을 했다가 회사가 커지고 고객이 많아지면서 문제가 있음을 깨닫고 프로세스도 만들고 기반시스템도 도입하지만 좋아지기는 하지만 기대만큼 큰 효과를 못보는 경우가 많다. 

그 이유는 개발자들의 몸에 베인 나쁜 습관들은 쉽게 고쳐지지 않기 때문이다. 나쁜 습관이 몸에 베인 개발자들도 교과서적으로는 그렇게 하면 안된다는 것을 알고 있어도 한번 몸에 베인 습관은 쉽게 고쳐지지 않는다.

나쁜 습관에 몸에 베인 것도 개발자들 탓은 아니다. 개발자들도 좋은 개발문화를 가진 회사에서 처음부터 일했다면 그런 나쁜 습관들은 경험해보지도 못했을 것이다. 

여기서 가장 중요한 개발문화는 바로 "협업"의 문화이다. "협업"을 생각하지 못하고 행동하는 하나하나가 모두 나쁜 습관들이다. 우리나라 개발자들은 협업을 해볼 기회가 별로 없다. 개발자들 스스로는 몇명씩 팀을 이뤄서 개발들을 해봤으니 "협업"을 해봤고 지금도 "협업"을 하고 있다고 말할 것이다. 하지만 그건 대부분 또하나의 주먹구구식의 일종일 뿐이다. 따라서 그런 팀은 4~5명이 한계이고 그보다 더 커지면 커지나 마나 하고 오히려 효율성이 더 떨어지는 경우도 많다.

그럼 협업의 핵심은 무엇일까요?

첫째, 문서를 통한 협업이다.

우리는 대부분 여럿이 모여서 서로 의논하면서 개발을 하면 협업을 하는 줄 안다. 하지만 그렇게 해서는 커뮤니케이션 비용이 너무 많이 들어간다. 90%는 문서로 말하고 문서로 안되는 나머지 10% 정도만 말로 설명하면 된다. 하지만 대부분 그 반대다. 문서로 10%, 말로 90%를 커버한다. 
여기서 말하는 문서는 "SRS"(스펙문서), "설계문서", "코드"를 모두 포함한다. 또한 이슈관리시스템과 같은 시스템도 포함된다. 
스펙문서를 보고 문서 작성자 외에 다른 개발자들이 설계를 하고 구현을 할 수 없다면 아직 갈 길이 먼 것이다. 
설계문서를 보고 여러 개발자들이 일을 나줘서 흩어져서 일을 할 수 없다면 부족한 설계문서다.
코드에는 Doxygen등의 주석이 달려 있어서 해당 함수나 Class를 사용하는 동료들이 주석만 보고 사용할 수 있어야 한다. 또한 Doxygen등을 통해서 체계적으로 함수나 Class를 검색할 수 있어야 한다.
코드에 의미를 알 수 없는 숫자나 널려 있고 Public 함수들이 수시로 바뀐다면 협업을 제대로 하고 있다고 볼 수 없다. 
잘 설계가 되어서 Public interface들이 한번 정해지면 이에 대한 설명이 잘 달리고 끝까지 바뀌면 안된다.
이러한 것들이 남의 나라 얘기처럼 생각되면 아직 협업은 갈길이 멀다. 

둘째, Peer review이다.

 Peer review를 빼고는 소프트웨어 개발을 얘기할 수 없다. Peer review하면 흔히 코드리뷰를 떠올리는데 코드리뷰는 그 중 일부이다.
Peer review에서 가장 중요한 것은 SRS(스펙) 리뷰이다. 스펙이 있어야 설계가 있고 그래야 코드리뷰도 의미가 있다.
SRS(스펙)는 프로젝트 모든 관련자가 참여하고 리뷰를 하여 완성해 나간다. SRS에는 프로젝트에 관련된 모든 내용이 들어가기 때문에 혼자서는 완성할 수 없고 리뷰를 거쳐서 모든 관련자가 검토를 해야 한다. 그리고 나면 이렇게 잘 완성된 SRS를 가지고 각자 흩어져셔 일을 할 수 있게 된다.
설계는 혼자서 하는 것보다는 여러 개발자와 리뷰를 하면서 좀더 좋은 아키텍쳐를 찾아낼 수가 있다. 개발자 개인이 가지고 있는 지식은 한계가 있어서 여러 사람과 머리를 맞대야 한다. 
설계 시 다른 사람들의 다양한 의견을 받아들일 준비가 되어 있지 않다면 아직 리뷰 문화에 익숙하지 않은 것이다. SRS와 설계는 리뷰를 통해서만 완성도 있게 작성된다.
그리고 코드리뷰이다. 
이렇게 리뷰를 잘 해야만 제품의 버그나 재작업을 획기적으로 줄일 수 있다. 또한 리뷰를 통해서 서로의 지식과 경험이 공유가 되고 각 개발자들이 훨씬 빠르게 성장한다.

협업 문화가 잘 되어 있는 회사는 다른 분야의 개발자들이 입사를 해도 빠른 시간 안에 적응해서 같이 일할 수 있다.
또한 개발자 한두명이 퇴사를 해도 회사가 망할 정도로 휘청이지는 않는다. 
결정적으로 프로젝트를 더 빨리 끝낼 수 있다.

사실 문화라는 것을 말로 설명하는 것은 어렵다. 또한 말로는 다 알 것 같지만 몸에 베이지 않으면 아는 것도 아니요. 모르는 것도 아닌 어중간한 상태가 된다. 그럴 때는 회사에서 중요한 것들을 강제로 시행하는 제도도 필요하다. 물론 핵심을 모르고 무조건 강제로 하면 부작용이 더 클 수 있으므로 현재 가능하고 중요한 것부터 차근차근 해나가야 한다.

확실한 것은 이런 협업의 문화가 없이는 소프트웨어 회사가 즐겁게 일하면서 오래 살아남지 못한다는 것이다.

개발자는 글을 잘 쓰지 못한다?

개발문서 작성은 항상 개발자를 따라다니면서 괴롭힌다.

체계적으로 개발을 하려면 개발문서를 적절하게 작성해야 한다고 다들 이론적으로는 알고 있다. 실제 그렇게 하지 않아도 이를 부정하는 개발자는 그렇게 많지 않다.

물론 핑계는 있다. 워낙 바빠서 문서를 만들 시간이 없다. 다 아는 내용이라서 문서를 작성하는 것은 시간 낭비다.

그럼에도 불구하고 회사에서 문서 작성을 강제로라도 시키면 개발자들은 MS Word를 열어 놓고 코딩할 때 처럼 진도가 나가지 않는다. 이때 주로 하는 얘기가 "머리 속에는 잔뜩 있는데 글을 잘 작성하지 못해서 문서를 작성하기 어렵다"라는 것이다.

이렇게 되다보니 문서만 작성하라고 하면 거부 반응을 보이게 된다.

하지만 이는 개발문서 작성을 피해보려는 핑계에 불과하다.
개발문서를 작성하는데 있어서 의외로 "글쓰는 재주"는 별로 필요하지 않다.

개발자들이 가장 흔히 작성하는 개발문서는 스펙과 설계 문서이다. 사용자 메뉴얼을 쓴다면 "글쓰는 재주"가 아주 많이 필요할 것이다. 하지만 스펙과 설계 문서를 작성하는데는 글쓰는 재주보다는 내용이 더 중요하다. 스펙과 설계 문서의 독자는 대부분 프로젝트 관련자와 개발자이기 때문에 잘 적힌 문장이 아니더라도 필요한 내용만 적히면 문제가 없다.

결론을 말하면 개발자들은 글쓰는 재주가 없어서 개발문서를 잘 작성하지 못하는 것이 아니고 분석을 못해서 "스펙"문서를 작성하지 못하고 설계를 못해서 "설계"문서를 잘 작성하지 못하는 것이다. 

문서는 분석과 설계의 결과물일 뿐이다. 스펙문서는 SRS Template을 보면 적어도 어떠한 내용이 적혀야 하는지 약간의 도움을 받을 수 있다. 설계문서는 Template이나 툴이 중요하다기 보다는 창의력을 발휘하여 설명할 수 있어야 한다.

문서가 잘 작성되었는지의 판가름은 문서작성자 외의 다른 개발자들이 이 문서를 받아서 일을 할 수 있나 보는 것이다. 물론 본인이 혼자서 분석, 설계, 구현을 하는 경우라도 상세도만 약간 줄이면 되며 내용은 빠짐없이 적어야 한다.

다른 사람이 보고 일을 하려면 화려하고 멋진 문장보다는 정확한 내용을 전달하기만 하면 된다. 기본적으로 주어, 목적어 등을 빼먹어서 애매하게 만드는 일은 없어야 한다. 또한 내용도 정량적으로 기술할 수 있어야 한다. 애매하게 "빨라야 한다"라든가 "편리해야 한다"등의 표현은 절절하지 않다. 이정도는 글쓰는 재주가 없어도 조금만 신경쓰면 되는 내용이다.

과거에 잘작성된 문서를 받아서 개발을 해본 경험이 몇번이라도 있으면 본인이 그러한 문서를 작성해서 다른 사람에게 넘기는 일은 어렵지 않을 것이다. 하지만 우리나라에서는 이러한 개발 문화가 없기 때문에 이런 경험을 가진 개발자를 보기란 정말 어렵다. 그래서 스스로 분석, 설계 방법을 터득해야 하는데 정말로 어려운 일이 아닐 수 없다. 간접적인 경험으로 인터넷의 글이나 책을 보곤하는데 이를 통해서는 너무 많은 정보를 접해서 핵심을 놓치고 오히려 방해가 되곤 한다.

결론은 원칙을 잘 생각하는 것이다. 자신이 작성한 문서를 다른 개발자가 보고 개발을 할 수 있게 해야 한다는 것을 잊지 말자 물론 개발뿐만 아니라 QA, Tech pub, Marketing, Sales 등 모든 부서가 일을 할 수 있어야 한다.

글재주가 없어서 문서를 잘 작성하지 못하는 것이 아니라는 것을 받아드리면 개발문서에 한단계 다가간 것이다. 일단 긍정적인 마음으로 시작하는 것이 중요하다. 그러면 메모 한장이라도 작성하는 것이 더 빠르게 개발하는 길이라는 것을 차츰 알게 될 것이다.

경영진이 너무 촉박한 일정을 제시합니다.

나는 프로젝트 일정에 대해서 항상 "일정은 개발자가 산정해야 한다"고 얘기를 해왔다.

그런데 많은 개발자들과 얘기를 해보면 자신들은 도저히 그렇게 할 수 있는 상황이 아니라고 한다. 일정은 위에서 확정이 되어서 내려오기 때문에 개발자가 정할 수 없다고 한다. 또한 항상 촉박한 일정을 지시하기 때문에 스펙이나 설계는 작성할 수도 없고 코딩부터 한다고 한다. 자신들도 체계적으로 개발을 하고 싶지만 도저히 그럴 시간이 없다고 한다.

경영진이 일정을 제시하는 것과 개발자가 일정을 산정하는 것은 완전히 상반된 얘기가 아니다.

경영진은 어떤 프로젝트를 진행하기 위해서는 일정이 필요하다. 경영진이 일정을 정했다고 해서 불가능한 일정이 가능해지는 것은 아니다. 프로젝트는 들어가야 할 시간은 다 들어간다. 자칫 서두르다가 더 느려질 수 있다.

경영진이 지시한 일정은 경영자의 입장에서 필요한 일정을 제시한 것이다. 이 일정은 변경해도 되는 경우도 있고 절대 변경하면 안되는 경우도 있다.

어떠한 경우라도 이 일정을 지키는 가장 좋은 방법은 개발자가 일정을 산정하는 것이다.

일정을 산정하기 위해서는 스펙을 제대로 쓰고 1,2일 단위로 상세 일정을 개발자가 산정해야 한다. 이쯤되면 전체 일정에서 20~30%의 시간이 지난 시점이 된다.

이때 상당히 정확한 일정이 나오면 경영진이 지시한 일정을 지키기 위한 방법을 강구할 수 있다. 이 일정이 경영진이 제시한 일정과 차이가 없다면 다행이지만 촉박한 일정이라면 스펙을 조정하거나, 개발자를 더 투입할 수 도 있다. 아직 설계, 구현이 본격적으로 시작되지 않았기 때문에 스펙 조정이 가능하고 개발자를 추가 투입해도 상당히 효과가 있다. 

스펙도 조정이 안되고 개발자 추가투입도 어렵고 무조건 밤을 새가면서 일하는 수밖에 없다면 그것도 하루이틀이지 어차피 불가능한 일을 하고 있는 것입니다. 불가능하다는 것을 일찍 알아내는 것도 중요합니다. 불가능한 일을 밀어 붙인다고 가능한 일로 바뀌지는 않습니다. 기적은 일어나지 않습니다.

스펙이 끝날 때까지 손놓고 있는 것이 아니고 스펙을 쓰는 도중에도 일정이 촉박할 것으로 예상이 되면 리스크관리를 통해서 미리 대비를 할 수 있다. 

경영진이 촉박한 일정을 지시했다고 해서 이것을 돌판에 새긴 절대불변의 지시사항으로 생각하고 코딩부터 시작하면 나중에 할 말은 다음과 같은 것들 밖에 없다.

• 매일 밤새면서 일했는데 못 지켰습니다. 원래 불가능한 일정이었어요.
• 코딩은 끝났는데, 테스트는 못했습니다.

이런 핑계를 대도 사실 코딩도 안 끝난 경우도 많다. 코딩은 가능하면 늦게 시작해야 기능을 빼거나 변경하기 쉽고 더 일찍 끝낼 수 있다.

경영진은 개발자들이 합리적인 방법을 제시하고 일정을 지켜주기를 원한다. 그래야 비즈니스를 할 수 있기 때문이다.

시간이 부족해서 스펙을 적을 수 없는 것이 아니고 시간을 절약하기 위해서 스펙을 적어야 일정을 지킬 수 있는 방법이 나온다.

경영진이 6개월의 시간을 제시했다면 앞만보고 마구 달리는 것보다는 가장 빠른 시간에 6개월안에 프로젝트를 끝내는 방법을 마련해야 한다. 경영진은 이런 합리적인 방법을 제시하는 개발팀을 후원할 것이다. 가장 빠른 기간에 프로젝트를 일정에 맞게 끝낼 수 있게 방법을 마련하는 방법이 바로 적절한 스펙을 작성하는 것이다.

내가 소스코드를 몰래 고치는 이유

여러 소프트웨어 회사를 분석해보면 소스코드를 공유하는 정도에서 정말 많은 차이가 난다.

여기서 소프트웨어 회사란 소프트웨어를 개발하고 있는 회사로서 흔히 얘기하는 팩키지 소프트웨어 회사가 아니다.

SI회사, 가전회사, 산업로봇회사, 반도체장비회사, 인터넷회사, 게임회사, 금융회사 등의 다양한 회사를 모두 말한다.

이들 회사 중에서는 개발자가 소스코드를 몰래 고치고 공유도 하지 않는 회사들이 의외로 많다.

개발자가 소스코드를 몰래 고치는 이유에는 이건 것들이 있다.

내 소스코드는 나만 알아야 회사에서 나의 파워가 유지된다.

일부 일리가 있는 이론이다. 내가 없으면 내가 작성한 소스코드를 이해하지도 고치지도 못하면 나는 절대로 짤릴 수가 없다. 문제가 있을 때마다 나에게 달려와서 이것 좀 고쳐달라고 하면 내가 좀 대단한 사람이 된 것 같은 생각도 든다. (이전에 블로그에 포스트한 글 참고)

2009/04/28 - [사람과 기술] - 과거의 개발자 vs. 미래의 개발자

실제로 실력이 있는 개발자들이 이런 행동을 하기도 한다. 하지만 이런 행동은 본인의 성장에 방해가 된다. 더 어렵고 가치있는 해야 할 사람이 과거의 소스코드에 발목잡혀서 휴가도 마음대로 못가게 된다. 개발자의 파워 및 가치는 과거에 있는 것이 아니고 미래에 회사에 필요한 가치에 있다는 것을 알아야 한다. 그것이 회사와 개발자의 상생의 기초이다.

내가 작성한 소스코드의 품질이 형편없어서 보여주기 창피하다.

어떤 천재 개발자도 공유하지 않고 혼자 개발을 해서는 좋은 코드를 작성하기 어렵다. 꾸준히 공유를 하면서 다른 사람들과 의견 교환을 통해서 점점 나아진다. 혼자 개발한 코드는 이상한 코드로 가득차 있기 마련이다. 

세 사람이 걸어가면 그 중에는 꼭 스승이 있듯이 신입사원과 코드 리뷰를 해도 배울 것이 나오게 된다.

소스코드를 보여주는 것을 창피해 할 것이 아니라 자꾸 보여주고 교류를 해야 나아진다.

엄청 어려운 것을 개발하고 있는 것처럼 행동했는데 소스코드를 보면 별 것 아니라는 것이 들통날 것 같다.

종종 접하는 문제다. 심지어는 오픈소스코드를 가져다가 동료들에게는 자기가 개발한 것 같이 자랑하는 경우도 있다. 이것은 회사입장에서 더 큰 문제가 될 수도 있다. 오픈소스 라이센스 규정을 어겨서 소송을 당할 수도 있다.

스펙을 적절하게 작성하고 설계를 하는 과정들에서 서로 리뷰를 적절하게 한다면 서로 어떤 컴포넌트를 어떤 Technology를 이용해서 개발하는지 다들 알게 된다. 어떤 것은 어렵고 어떤 모듈은 신입사원이 구현해도 될 만큼 쉬운 것인지 모두 알게 된다. 

SRS를 제대로 작성하게 된다면 모든 프로젝트 관련자가 프로젝트가 어떻게 구성되어 있고 어떻게 진행되고 있는지 훤히 할게 된다.

너무 바빠서 공유할 시간도 없다.

이미 불끄기 모드로 들어간 회사는 단기적인 해결책이 없다. 이런 회사에서는 서로 자기일 하기 바빠서 점점 서로 더 단절되게 된다. 또 다시 악순환이 진행된다.

2011/01/03 - [개발문화] - 매일 불난 호떡집 같은 회사 (중요한 일 vs. 시급한 일)

시간이 좀 걸리겠지만 악순환의 고리를 끊어야 한다.

공유를 해봤자 관심도 없다. 다들 바쁜데...

공유문화가 정착되지 않은 회사이다. 이런 회사에서 코드리뷰는 별 의미도 없다. 

시도를 해봤자 시간 낭비일 것이다. 내용을 모르는데 코드리뷰를 해도 기껏해야 Syntax 검사밖에 못할 것이다.

SRS리뷰를 먼저 시작하는 것이 좋다. SRS가 리뷰를 해야 할 것도 더 많고 SRS가 제대로 작성되어야 다음 단계인 설계, 구현이 제대로 진행되며 리뷰를 해도 내용을 알고 리뷰를 할 수 있게 된다.

이렇게 되면 "바쁜데..."라는 핑계가 조금씩 줄어들만큼 시간을 절약할 수 있게 된다.

결론

개발자가 작성하는 모든 소스코드는 기록이 남아야 하고 남게 된다. 물론 분석, 설계도 마찬가지이다.

Baseline에 포함되는 소스코드와 문서들은 소스코드 관리시스템에 들어갈 때 설명을 적절하고 충실하게 달아야 한다. 이때 이 소스코드를 누가 리뷰했는지 기록을 남기기를 권장한다. 리뷰를 했다는 의미는 소스코드 작성자와 같이 이 소스코드에 대해서 공동책임을 진다는 의미이기도 하다. 이것이 부담스러워서 리뷰를 하지 않는다면 아무도 리뷰를 하지 않을 것이다. 서로 리뷰를 해주는 것은 모두에게 도움이 되는 것이다. 이것은 규칙으로 강요를 해서는 효과가 없고 분위기가 조성되어서 오랫동안 시행을 하여 문화로 자리를 잡아야 한다.

소스코드관리시스템에 소스코드를 올릴때는 버그ID(이슈ID)가 꼭 있어야 한다. 개발자가 원한다고 아무때나 마음대로 소스코드를 고치면 안된다. 개발자가 스스로 발견한 버그를 고칠 때도 버그관리시스템에 등록을 하고 고쳐야 한다.

이렇게 개발자가 생성한 모든 소스코드는 투명하게 모두가 볼 수 있게 한다면 이 혜택은 회사 뿐만 아니라 모든 개발자 그리고 본인에게도 돌아한다.

SRS에 대한 인식의 변화

그 동안 본 블로그를 통해서 소프트웨어 개발에서 SRS(Software Requirements Specification)가 얼마나 중요한 역할을 하는지에 대해서 수 차례 역설한 적이 있습니다.

2009/08/03 - [프로젝트/요구사항분석] - 이건 기능이 아닌데
2009/07/30 - [프로젝트/요구사항분석] - 고객이 요구사항을 너무 자주 바꿔요.
2009/05/04 - [프로젝트/요구사항분석] - Track me, if you can
2009/04/22 - [프로젝트/요구사항분석] - 개발자들이 바글바글한 외딴섬에 떨어진다면
2009/02/12 - [프로젝트/요구사항분석] - 요구사항 분석의 출발점
2009/02/04 - [개발프로세스] - 소프트웨어 개발 단계에서 가장 중요하다고 생각하는 것은?
2009/01/29 - [소프트웨어이야기] - Head First Software Development 리뷰
2009/01/21 - [프로젝트/요구사항분석] - UI Mock-up
2009/01/20 - [프로젝트/요구사항분석] - 샘플만 보여주세요.
2009/01/19 - [프로젝트/요구사항분석] - 그냥 쓸 수 있겠네요.
2008/11/19 - [프로젝트/요구사항분석] - SRS(Software Requirements Specification)의 중요성2008/11/03 - [소프트웨어이야기] - 프로젝트 산출물을 프로젝트 종료 후에 만들고 있나요?

지금까지는 SRS라는 용어조차 한번도 들어본 적이 없는 소프트웨어 개발자나 관련자들이 많았었습니다. 하지만 이제는 조금씩 SRS라는 용어에 대해서 알기 시작하는 것 같습니다. 또 소프트웨어 개발에서 있어서 요구분석이 왜 중요한지에 대해서 조금씩 인식해가는 것 같습니다.

그 예로 최근에는 정부에서도 소프트웨어 기업들의 경쟁력 강화, 특히 해외 시장 진출 시 경쟁력 확보를 위해서SRS 작성을 중요한 요소로 보고 정부 지원 과제에 포함을 하고 있습니다.

이러한 과제에 평가위원으로 참석을 해보니 아직은 많은 소프트웨어 회사들이 분석능력을 제대로 갖추고 있고, SRS를 잘 쓸 수 있는 역량을 갖췄다고 보기는 어렵습니다. 하지만 제대로 된 소프트웨어를 짧은 시간에 개발하기 위해서는 분석을 제대로 하여 SRS를 작성하고 SDP를 만들어야 한다는 것을 인지한 것만으로도 큰 변화라고 볼 수 있습니다. 필요성을 인식하는 것이야 말로 변화가 가능하게 하는 원동력입니다.

다만, 문제는 분석을 잘해야 한다는 것, 즉 SRS를 잘 써야 한다는 것을 인식하고도 SRS를 잘 적는 방법을 배울 곳이 없다는 것입니다. Software 선진국에서는 수십년 간 개발자들이 SRS를 써 왔기 때문에 서로 Template는 조금씩 달라도 개발자로서 일을 하는 동안에 계속 접해 왔고, 써왔기 때문에 따로 배우고 말 것도 없이 SRS를 쓸 줄 알게 되었습니다. 물론 모든 개발자가 SRS를 다 제대로 쓸 줄 아는 것도 아니고 그럴 필요도 없지만, 소프트웨어 프로젝트를 시작할 때 누군가가 SRS를 작성하고 관련자들과 리뷰를 하는데 전혀 문제가 없습니다. 

하지만 이제 시작인 우리나라는 배울 곳도 없고, 스스로 연구하고 공부해서 작성하기에는 요구분석이라는 분야 자체가 너무 어렵습니다. 그 동안 여러 회사에서 스스로 작성했다고 하는 SRS를 분석해보면 합격점을 줄 수 있는 것은 거의 전무했다고 해도 과언이 아닙니다. 그렇다고 미국 회사에 가서 몇 년 배우고 오기도 어려운 실정입니다. 또, 국내에서는 학교나 학원에서 배울 수 있는 환경도 되지 않습니다. 그렇게 배운다고 해도 몇몇 기법만 배우고 핵심은 파악하지도 못하게 됩니다. 그 이유가 대부분의 교수나 강사가 소프트웨어 프로젝트에서 실제로 SRS를 써본적이 거의 없이 이론적으로 배운 정도이기 때문입니다. 실제 프로젝트에서 SRS를 제대로 써본 경험을 많이 가지고 있는 경험자와 같이 SRS를 써보면서 꾸준히 배워 나가는 것이 가장 적절한 방법입니다.

물론 몇몇 개발 방법론에서는 SRS를 작성하지 않습니다. 하지만 이러한 방법론에서도 스펙이 필요 없다고 하는 것은 아닙니다. 다만 스펙을 바라보는 관점과 적는 방법이 다를 뿐입니다. 따라서 스펙의 개념을 정확하게 알고 SRS를 잘 작성할 줄 아는 개발자들이라면 스펙의 형태가 테스트케이스가 되든 어떤 다른 형태가 되든 문제는 없습니다. 즉, 소프트웨어 분석역량이 문제입니다. 

분석역량의 부족은 부실한 스펙문서를 만들게 되고 이는 설계, 구현 기간에 많은 혼란과 재작업을 초래하고 출시 후에도 유지보수 비용을 크게 증가시킵니다. 그 동안 우물 안 개구리처럼 내수시장에서 소수의 개발자를 데리고 고객이 원하는 대로 뚝딱 만들어서 장사를 했는데, 소프트웨어 볼륨이 커지고 해외 시장에 진출을 하려니까 딱 벽에 부딪히는 겁니다. 이 과정에서 무리하게 해외 진출을 추진하다가 유명을 달리한 회사들이 상당히 많습니다. 그렇다고 세계 시장의 1%밖에 안되는 국내 SW시장에서만 놀기에는 국내 시장은 너무나 작습니다. 왠만큼 성장한 회사라면 해외 시장 진출의 유혹을 떨처버리기 어렵습니다.  

물론 SRS, 스펙, 분석능력이 이 모든 것을 해결해주지는 않습니다. 하지만, 가장 중요하고 핵심적인 요소라 확신합니다. 이는 저만의 주장이 아니고 제가 존경하는 수많은 실전 소프트웨어 전문가들의 주장이기도 합니다. 그러한 맥락으로 앞으로 SRS, 스펙, 분석역량 향상에 대한 글을 종종 올려보려고 합니다. 블로그를 통한 지식전달이 얼마나 효과가 있겠는지 의문은 들지만, 필요성에 대한 인식만 생기더라도 글을 올린 보람을 있을 것으로 생각됩니다.

이와 관련된 궁금증, 의견, 경험, 고민거리, 정보, 아이디어 등 어떤 것이라도 같이 교환하고 싶습니다. 댓글이나 방명록, 메일로 얼마든지 보내주세요. 제가 해결해드릴 수 있는 것은 해결해드리죠.

그리고 교육을 받고 싶으신 개발자나 회사라면 연락 주시기 바랍니다. 제가 여건이 되는 한도내에서는 많은 소프트웨어 개발자들에게 전달하고 싶습니다.

개발자 부품화 vs. 만능 개발자

개발 프로세스를 너무 따지만 개발자가 부품화 되고 창의성이 줄어든다고 합니다.

또 분석, 설계, 구현, 테스트를 나눠서 하게 되면 부품화되고 비인간적이라고 하기도 합니다.

그래서 개발자가 이것 저것 다하는 만능의 역할을 수행하게 합니다.

투수는 공만 던지고, 골키퍼는 골만 막는 것은 부품화일까요?

이렇게 전문화되지 않고 모두 만능으로 잘하는 동네 축구를 해서 어떻게 세계적인 소프트웨어와 경쟁할 수 있을까? 잘 하고 싶어도 동네축구를 계속 하는 이유는 제대로 된 방법을 경험해 본적이 없어서 그렇습니다. 개발자가 한명인 회사나 개발자가 50명인 회사가 개발하는 방법은 크게 다르지 않습니다. 개발자가 개발 전반의 모든 일을 다 알아서 하고 프로젝트는 개발자의 역량과 의지에 달려있습니다. 

동네 축구를 벗어나기 위해서는 소프트웨어를 개발하는 전체 프로세스를 이해해야 합니다. 이에 따라서 프로세스를 체계화 하고 각 역할별 전문화된 조직을 갖춰나가고 설령 인원이 매우 적어서 한명의 개발자가 여러가지 일을 수행하더라도 업무의 구분이 필요합니다. 나중에 조직이 커지면 일을 떼어 줄 수 있어야 합니다.

만능 개발자는 자칫하면 정작 개발자로서의 가치 있는 성장에 지장을 초래할 수 있습니다. 

우리는 다르다.

"우리는 다르다"

"우리는 너무 바빠서 문서를 쓸 시간이 없다."

"우리는 고객이 요구사항을 너무 자주 바꿔서 스펙을 작성할 필요가 없다."

"우리가 개발하는 시스템의 업무는 너무 복잡해서 문서로 만들 수도 없고 개발자도 몇 년 일해야 제대로 일할 수 있다."

"우리 고객은 문제가 생기면 당장 고쳐주지 않으면 큰일 난다."

"우리의 기술은 너무 어려워서 설명할 수가 없다."

"우리 소스코드는 너무 중요해서 아무에게도 보여 줄 수 없다."

"우리 제품의 시장은 너무 경쟁이 치열해서 고객이 원하는 것은 다 들어 줘야 한다."

"우리 프로젝트는 항상 너무 촉박해서 제대로 된 프로세스를 밟을 수 없다."

"우리는 도저히 리뷰할 시간이 없다."

"우리는 프로젝트 기간이 항상 너무 짧아서 테스트는 대충하고 출시해야 한다."

"우리 시스템은 너무 복잡해서 설계자가 구현까지 하지 않을 수 없다."

"우리 시스템은 너무 복잡해서 개발자가 테스트를 해야 한다."

다들 가장 까다로운 고객을 가지고 있고, 너무 어려운 기술이고, 업무도 너무 복잡하고, 항상 시간이 없다라고 말합니다. 

이 얘기는 거의 모든 SW회사들에게서 듣는 별로 특별할 것도 없는 얘기들입니다.

결국 SW 회사들의 근본은 별반 다를 것이 없습니다. 소프트웨어를 제대로 개발하기 위해서 거쳐야 할 프로세스, 문서 작성, 리뷰 등은 크게 차이가 없습니다. Detail한 부분은 서로 다를 수 있지만, 기본 원리는 같습니다. 하지만 자신의 회사는 대단한 도전을 하는 것과 같은 착각을 하고 있는 경우가 너무나 많습니다. 오히려 제대로 하고 있지 못하고 있기 때문에 환경이 더욱 열악하게 느껴지는 것을 알고 있지 못하는 경우가 더 많습니다.

세상에 시간이 너무 넉넉한 SW프로젝트는 거의 없습니다. 

세상에 마음 착하게 문제 해결을 개발회사가 원하는 만큼 넉넉하게 기다려 주는 고객은 거의 없습니다.

대부분의 회사가 다루고 있는 기술은 크게 특출 날 것도 어려운 것도 별로 없습니다. 대단히 소수의 SW회사들만 그런 어려운 기술을 다루고 있습니다.

결국 현재의 문제를 자신의 부족함에서 찾지 않고 환경의 열악함으로 돌리는 것은 나아질 수 있는 기회를 잃어버리는 결과를 초래할 수도 있습니다.

정말 열심히 일하고 있는데, 개발은 점점 복잡해지고, 야근은 점점 늘어가고, 고객의 요구는 점점 까다로워 진다면 내부를 돌아봐야 합니다. 회사가 제대로 SW를 개발하고 있는 것인지 심각하게 고민해 봐야 합니다.

한방에 빌드

Visual Studio나 Eclipse를 실행해야만 빌드를 할 수 있습니까?

"Yes"라고 대답하는 개발자들은 대부분은 이것이 무슨 문제인지 모르고 있는 상황입니다. 

Joel Test 12개 항목 중 하나를 차지할 정도 한방에 빌드를 만들어 내는 것은 중요합니다. Visual Studio나 Eclipse에서 버튼 하나만 누르면 빌드가 된다고 이것을 한방에 빌드를 만들어 내는 것이라고 착각하면 곤란합니다. 일단 Command line이 아니고 빌드를 위해서 사람의 손을 통해서 무슨 프로그램을 실행해야 한다면 한방의 빌드와는 거리가 먼 겁니다.

그럼 왜 한방에 빌드를 만들어 낼 수 있을까요? 

빌드는 반복적인 작업이며 대단히 귀찮은 작업이면서 전문적인 작업이기도 하고 실수하기 쉽기도 하며 개발에서 많은 시간을 소모하는 작업입니다. 한번의 빌드는 큰 시간 소모가 아니라고 생각할지 몰라도 개발 프로젝트 전체를 놓고 보면 아주 큰 시간과 비용입니다.

그래서 빌드는 자동화되어야 하고, 전문화 되어야 하고, 통제가 되어야 하며, 별도의 담당자가 할당되게 됩니다. 빌드의 효율성을 높이기 위해서 전과정을 자동화 하기 위해서는 Build Technology에 대한 연구가 이루어져야 합니다. 빌드는 일반 개발자가 개발도 하면서 매우 잘 해내기 힘든 전문 분야입니다. 

한방에 빌드란 개발자들이 해당 빌드에 추가될 모든 기능을 구현해서 소스코드 관리시스템에 등록을 한 상태에서 단 한번의 명령어 실행으로 빌드 전과정을 자동으로 실행해서 최종 마스터가 마스터 보관소에 저장이 되는 것을 말합니다. 이 빌드 전과정은 회사마다 제품마다 상당히 다르며 어떤 제품은 5분이면 끝나고 어떤 제품은 24시간이 넘게 걸리는 것도 있습니다. 또 어떤 제품은 수십개가 넘는 OS에서 빌드를 해야 하고, 어떤 제품은 빌드를 위해서 수십개의 빌드시스템을 동시에 실행하기도 합니다. 

5분짜리 빌드만 해본 개발자들이라면 한방에 빌드와 IDE를 통한 수동 빌드가 별로 차이가 없어 보이지만, 규모가 커지고 빌드가 복잡해지기 시작하면 그 차이는 확연히 드러납니다. 사실 5분짜리 빌드도 자동화의 잇점이 상당으로 작기는 하지만 자동화를 하는 것이 더 유리하죠. 그래야 자동화의 필요성도 깨닫게 되구요.

개발자가 분석, 설계, 구현하는 작업 외에 다른 작업에 많은 시간을 소모하고 있다면 그런 작업은 최대한 자동화하고 개발자들은 개발에 집중할 수 있도록 해야 합니다. 한번의 자동화가 귀찮다고 조금씩 갉아 먹는 시간은 대단히 큰 비용입니다.

아직 빌드 자동화에 대한 경험이 부족하다면 막상 시작하려면 막막한 경우들이 있습니다. 궁금하신 내용들이 있아면 제게 메일을 보내주세요. 제가 아는 한 최대한 성심껏 답변드리겠습니다.

이 바닥을 못 벗어난다.

우리나라 소프트웨어 개발자들은 자신이 처음부터 일해온 바닥을 못 벗어나는 경향이 있습니다.

처음에 게임회사에서 일을 시작한 개발자는 계속 게임회사에서 일하고, 금융회사, 보안회사, 장비회사, SI회사 등 쉽게 그 바닥을 못 벗어나곤 합니다. 

이러다 보니 개발자가 이직 시 선택의 폭이 좁아지고, 분야가 조금만 바뀌어도 자신의 Value가 확 줄어드는 현상이 일어나곤 합니다.이런 일이 비일비재하게 일어나는 것을 보면 개발자의 전문성이란 어디에 있는 것인지 궁금하지 않을 수 없습니다.

금융에 대한 전문지식을 많이 가지고 있고, 게임에 대한 많은 지식을 가지고 있는 것을 개발자의 전문성이라고 볼 수도 있습니다. 또 그러한 Domain 지식이 없으면 개발을 할 수 없다고 단정적으로 얘기를 하는 개발자도 많습니다.

소프트웨어 엔지니어가 소프트웨어를 개발하기 위해서는 크게 2가지의 지식이 필요합니다.

그 중 하나는 이미 앞에서 언급한 Domain 지식입니다.

그리고 또 하나는 Software Engineering 지식입니다.

Domain 지식은 개발 분야가 바뀌면 거의 쓸모가 없는 산업 지식이고, Software Engineering 지식은 개발 분야가 바뀌어도 항상 사용되는 지식들입니다.

Domain 지식은 너무 광범위해서 나열을 할 수는 없습니다.

하지만 Software Engineering 지식은 무엇인지 설명할 수 있습니다.

요구분석, 설계, 구현, 테스트, 소스코드 관리, 버그 관리, 프로세스 등 소프트웨어를 개발하기 위한 일련의 지식들입니다.

물론 소프트웨어를 개발하기 위해서는 Domain 지식과 Software Engineering 지식 모두가 필요합니다. 하지만 흔히 접하는 현상을 보면 개발자들이 점점 Domain 지식이 치중하는 경향이 있습니다. Software Engineering에 대한 전문성을 떨어진 상태에서 Domain 지식만 점점 늘어가니 당장 일은 잘하고 있는 것 같아도, 동료나 후배들과 협업이 잘 안되고, 프로젝트 규모가 조금만 커져도 문제가 있고, 이직 시에는 심각한 가치 하락이 발생합니다.

그럼 어떻게 해야 할까요? 소프트웨어를 개발하면서 자연스럽게 얻게 되는 Domain 지식에만 의존해서는 안됩니다. Software Engineering 지식을 꾸준히 발전시켜서 소프트웨어 전문가가 될 수 있도록 해야 합니다. Software Engineering에 능통한 소프트웨어 전문가가 된다면, 어느 소프트웨어 회사를 가더라도, 여전히 전문가로서 높은 가치를 가지고 개발을 할 수 있습니다. 새로운 분야로 이직을 하더라도 Domain 지식은 일을 하는 과정에서 차츰 배워 나갈 수 있습니다. 

그리고 Domain 지식에 능통한 개발자에게만 의존해서 개발이 진행되는 소프트웨어 회사는 매우 큰 리스크를 안고 있는 겁니다. 그런 개발자가 한 명만 퇴사를 해도 회사는 큰 위험에 봉착합니다.  

결국, 회사를 위해서도, 개발자들을 위해서도 개발 개발자들의 머리 속에 들어 있는 Domain지식에 의존하기보다는 적절한 개발 프로세스 및 시스템을 기반으로 개발을 해야 합니다.

우리는 개발자가 테스트해요.

주변의 소프트웨어 회사들을 보면 개발자가 테스트를 하는 회사를 정말로 많이 접하게 됩니다.

물론 개발자도 구현을 하면서 Unit테스트는 일상적으로 하지만, 제품의 기능이 정상적으로 동작하는지 확인하는 시스템 테스트도 개발자가 테스트하는 것을 보는 것은 그리 어려운 일이 아닙니다. 오히려 전문 테스트 인력이나 테스트팀이 있는 회사를 보는 것이 더 어렵습니다. 있다고 하더라도, 테스트팀이 전문적으로 테스트를 수행한다기 보다 개발자의 손을 좀 덜어주는 경우가 흔합니다.

이렇게 개발자가 테스트를 하는 이유는 다양하지만 다음과 같은 것들이 있습니다.

• 우리는 인력이 너무 적어서 테스터를 별도로 둘 수 없어요.
• 프로젝트 기간이 너무 짧아서 별도의 테스트 단계를 둬서 테스트를 할 수 없어요.
• 개발자만이 기능을 속속들이 알아서 테스트를 할 수 있고, 이것을 테스터에게 알려줄 시간이 없어요. 그렇게 하면 중복 낭비예요.
• 사람들이 테스터를 하기 싫어해서 전부 개발하고 같이 테스트 해요. 테스터는 뽑기도 어렵고, 기존의 개발자중에서 자원자가 없어요.
• 테스터를 왜 별도로 둬야 하죠원래 개발자가 해도 되는 거 아닌가요?

개발자가 테스트를 하게 될 경우 아래와 같은 큰 문제가 있습니다.

• 개발자는 제품의 내부 동작 방식을 속속들이 알기 때문에 자신도 모르게 정상적으로 동작하는 방식으로면 테스트를 하려고 합니다.
• 개발자는 일반 사용자와 비슷한 패턴으로 제품을 사용하지 못합니다.
• 개발자는 테스트의 전문성이 없기 때문에 테스트를 잘 하지도 못합니다.
• 체계화된 테스트를 못하기 때문에 테스터를 더 투입하여 테스트 기간을 줄이는 등의 전략은 꿈도 못 꿉니다.
• 테스트는 항상 대충 이루어지면 나중에 사용자가 버그를 많이 발견합니다.
• 회귀(Regression)테스트는 무시되면 적당히 수정한 것만 테스트 하여 고쳤던 버그가 다시 살아나기도 합니다.
• 개발자는 테스터보다 연봉을 더 줘야 하는데, 잘하지도 못하는 테스트를 시키느라고 비싼 돈을 낭비합니다.
• 테스트 자동화 등의 테스트에 대한 전문적인 연구 및 개선이 이루어지지 않습니다.

한마디로 비싼 돈 주고 개발자는 개발자대로 고생하고 제품의 품질은 떨어지는 겁니다.

설령 1명짜리 회사라고 하더라도, 테스트는 제대로 해야 합니다. 그리고 개발자가 3,4명만 되어도 별도의 테스트를 두는 것이 효율적입니다. 예외적으로 특수한 프로젝트라면 모를까 일반적으로 별도의 테스트를 두는 것이 더 빠르고 적은 비용으로 높은 품질의 소프트웨어를 만드는 한 방법입니다.

물론 무조건 별도의 테스트팀을 두기만 하면 위 문제들이 해결되는 것은 아닙니다. 잘 해야죠. 추가적인 얘기는 다음에 하기로 하죠.

프로젝트 시작부터 개발자가 바글바글

소프트웨어 개발 프로젝트가 시작되면 바로 개발팀이 구성되어서 개발자들이 바글바글 한가요?

그렇다면 뭔가 개발 체계에 잘못된 것이 없는지 검토를 해봐야 합니다.

개발을 단계(Stage)구분 없이 마구잡이로 하고 있지 않은지?

개발 업무(분석, 설계, 구현)의 구분 없이 섞여서 하고 있지 않은지?

개발자가 별도의 전문성 없이 모든 업무(분석, 설계, 구현, 빌드, 테스트)를 다 하고 있지 않은지?

프로젝트의 각 단계에 따라서 투입되는 인력이 달라집니다. 

소프트웨어 개발 프로젝트에서 흔히 저지르는 실수 중 하나가 프로젝트가 시작되자마자 모든 프로젝트 인력을 한꺼번에 투입해 놓고 프로젝트 끝날 때까지 그 인원으로 계속 진행하는 경우입니다. 

각 단계 별로 필요한 인력과 인원 수가 달라지는데 프로젝트 초기부터 많은 인원이 투입되면, 개발자들이 별로 할 일이 없게 됩니다. 그렇게 되면 요구분석이 완료되지도 않은 시점에 특별한 계획도 없이 코딩도 해보고 설계도 해보고 이것저것을 개발하기 시작하기도 합니다.

위 그래프의 핵심은 초기부터 많은 개발자를 투입하지 않는다는 것입니다. 요구분석 단계에 투입되는 개발자는 SRS 작성에 필요한 정보를 제공하는 개발자들입니다. 요구사항의 타당성을 점검하고, 필요 시 프로토타입을 만들어 볼 수도 있습니다. 그런 다음, 설계 단계에서는 설계에 참여하는 인원만 추가로 투입하면 됩니다.

 

테스터가 프로젝트 초기부터 테스트에 참여하는 점을 눈 여겨 봅시다. 테스터 역시 SRS작성에 참여하고, 테스트 요구사항을 제시하고, 각 요구사항이 테스트 가능한지 검토합니다. 요구분석단계에 테스터는 실제로 테스트 계획서를 작성하기도 하고 이를 준비만 하기도 합니다. 

이렇듯 각 단계 별로 인원을 효과적으로 투입해야만 비용을 절감할 수 있으며, 성급하게 프로젝트 후반부에 해야 할 일들을 앞에서 미리 함으로써 발생하는 수많은 문제를 방지할 수 있다. 미리 작성해 놓은 코드가 아까워서 어떻게 하든 프로젝트에 사용해보려고 하지 않겠습니까?

그 외에도 고참 개발자나 신입 개발자나 특별한 구분 없이 모두 모여서 서로 비슷한 일들을 나눠서 일을 하고 있다면 개발 조직의 효율성 및 생산성이 떨어지는 경우라고 볼 수 있습니다. 아직 주먹구구 단계를 벗어나지 못한 상태입니다. 이런 경우에도 프로젝트를 시작하면 모두 모여서 그냥 개발을 시작하죠.

이렇게 개발자들이 프로젝트 초기부터 모두 투입되는 경우는 비용이나 개발 인력 활용 면에서 대단히 불리합니다. 프로젝트가 진행되는 단계에 따라서 인원을 적절하게 투입해야 합니다. 물론 그렇게 하기 위해서는 각 기능조직의 전문성이 갖춰져야 하고, 개발에 필요한 시스템과 프로세스가 필요하며, 개발자들이  문서 작성 능력을 필수적으로 갖추고 있어야 합니다.

그냥 쓸 수 있겠네요.

소프트웨어를 개발하면서 가장 어려운 일은 고객의 요구사항을 파악하는 일이라고 알려져입니다.

고전적인 Waterfall 방식부터 Agile까지 요구사항에 대해서 다양한 방법으로 상당히 신경을 쓰고 있습니다.

특히나 우리나라에서는 고객이 요구사항을 잘 가르쳐 주지 않습니다. 물론 자신의 요구사항을 완벽하게 자세히 알고 말해주는 고객은 전세계 어디서도 찾아보기 어려운 것이 사실입니다. 정도의 차이가 있을 뿐이죠. 그만큼 요구사항 파악은 어려운 일입니다.

우리나라에서 요구사항 파악 시 고객이 이렇게 얘기하는 경우가 흔합니다.

"자세한 요구사항은 나중에 알려줄 테니 일단 구현을 시작해주세요."

그래서 일단 제품을 다 만들어 놓고 고객에게 시연을 하면 그 때서야 고객이 "여기는 이렇게 고쳐달라", "이 기능을 넣어달라", "저 기능은 빼달라" 주문을 하기 시작하죠. 그렇게 제품을 고치고, 시연하고 하면서 고객의 요구사항을 만족시켜 가는 방법이 우리나라에서는 그리 드문 일이 아닙니다. 심지어는 요구사항 분석에 경험이 적은 개발자들은 그냥 그렇게 하는 방법에 익숙해져 있기도 합니다.

이 방법은 대단히 비효율적이고 비용이 많이 드는 방법입니다.

고객의 말 한마디에 몇 주간 노력해서 만든 기능이 빠질 수도 있습니다. 그리고 황당한 요구사항이 갑자기 추가될 수도 있고, 도저히 초기에 일정을 예측할 수도 없죠. 

개발자들이 고객의 요구사항을 너무 잘 알고 있고, 오히려 개발자가 고객을 리드하는 경우라면 일부 효과가 있을 수 있어도, 대부분의 경우 비싼 방법입니다.

이와 같이 자세한 스펙을 쓰기 전에 미리 만들어서 보여주는 방법을 "Prototyping"이라고 합니다. 그 중에서 고객의 요구사항을 파악하고 요구사항을 명확하게 하기 위한 방법은 "1회용 Prototyping"이라고 합니다. 왜 "1회용"이냐 하면 이는 요구사항을 파악하기 위한 것이기 때문에 Fix된 요구사항이 아닙니다. 제품에 기능으로 추가될지 빠질지 알 수 없고, 기능이 어떤 형태로 변하게 될 수 예측할 수 없으므로 제대로 만들면 비용과 시간이 많이 들기 때문에 아주 간단하게 만들어 보는 겁니다. UI에 대한 요구사항을 명확하게 하고 싶으면 UI만 동작하도록 해서 고객과 의논할 수 있고, 특정 기능에 대해서 자세히 알고 싶으면 그 기능이 어떻게 동작하는 지만 간단히 만들어 보는 겁니다.

이때는 제대로 제품을 만들듯이 에러처리를 꼼꼼히 하지도 않고, 회사의 코딩 규칙을 지키기 위해서 주석을 제대로 달지 않아도 되며 속도를 위해서 코드를 개선하지 않고, 메모리 최적화도 필요 없습니다. "1회용 Prototyping"은 요구사항을 얻고 명확하게 하기 위한 것이 목적이므로 최단시간에 최소한의 비용으로 만들면 됩니다. 

이렇게 만들어진 "1회용 Prototype"을 고객이나 영업부에 보여주면 "다 됐네?", "그냥 쓸 수 있겠군요."라고 하는 경우가 많습니다. 이는 마치 모델하우스를 보고 거기에 들어가서 살겠다고 하는 거와 비슷합니다. 

"1회용 Prototype"은 요구사항을 명확하게 하기 위한 활동이고, 이를 통해서 요구사항이 정해졌으면, "1회용 Prototype"은 버리고 다시 만드는 겁니다. 하지만 개발자들은 이를 다시 써먹으려고 하는 경우가 많습니다. "Prototype"에 너무 많은 노력을 들였거나, 시간이 촉발할 때 그냥 쓰고 싶을 수도 있는데, 이는 나중에 제품의 품질에 영향을 주기 때문에 "1회용 Prototype"은 참조는 할 수 있지만, Copy & Paste해서 쓰면 안 됩니다.

"1회용은 1회용일 뿐"

Prototype을 만드는 도중에 Project는 중단이 되는 것이 아니고, 요구사항 분석을 계속해 나가면서 1명의 개발자나 소수의 인원이 Prototype을 만들어 보는 겁니다. 물론 Prototype을 만드는 일도 계획되어야 하며, 적절한 Prototype 작성은 프로젝트의 시간과 비용을 절약해줍니다. 또한 나중에 생길 가능성이 있는 요구사항의 변화를 줄여줘서 Risk도 감소시켜주는 효과도 있습니다. 모든 기능을 다 Prototype을 만들어야 하는 것은 아니고 꼭 필요한 부분만 Prototype을 만들어서 확인할 수 있도록 적절히 판단하는 것도 경험이 필요합니다.

개발자 채용 시 코딩테스트를 하시나요?

연기자나 가수를 뽑을 때 오디션을 보듯이 개발자를 채용할 때는 코딩테스트가 꼭 필요합니다.

하지만 코딩테스트를 하지 않고 채용하는 경우가 매우 흔합니다.

이력서를 통해서 그 개발자가 과거에 참여했던 프로젝트가 무엇인지 보고 인터뷰에서 이거 저거 물어보는 것만 가지고는 개발자의 실력을 평가하기는 아주 부족합니다.

코딩 테스트는 다음과 같이 3가지 타입으로 진행할 수 있습니다.

첫째, 인터뷰를 하기 전에 E-mail을 통해서 코딩테스트 과제를 전달할 수 있습니다. 

이때는 시간이 반나절이나 하루 정도 걸리는 과제를 줄 수 있고 꽤 많은 내용을 점검할 수 있습니다.

단순히 로직 뿐만 아니라 코딩 습관, 최적화 시도, 소스트리, 빌드 스크립트 등 다양한 실력을 엿볼 수 있습니다.

1차에 끝나는 경우도 있고, 시험대상자가 너무 많으면 1,2차에 걸쳐서 1차에서는 기본적인 과제로 기본 이하의 개발자를 거르고 2차 과제에서 진짜 문제를 낼 수도 있습니다.

이 테스트의 단점은 다른 사람이 도와줄 수 있는 것입니다. 대부분의 경우 본인 스스로의 힘으로 과제를 해결하지만 실력이 좋은 사람이 도와 줄 경우 이를 확인하기 어려우므로 인터뷰 시 몇몇 내용을 확인하는 것이 좋습니다.

예) Caching 알고리즘 구현

둘째, 인터뷰를 하는 날 인터뷰를 하기 전에 코딩테스트를 하는 것입니다. 인터뷰 전에 약 한 시간 정도면 풀 수 있는 과제를 주고 코딩을 하게 하는 것입니다. 노트북을 준비해 오게 해서 인터뷰 전에 코딩을 시키고, 인터뷰 시 발표를 하게 하는 방법입니다. 실력을 적나라하게 볼 수 있는 좋은 방법 중에 하나입니다.

예) Quick sort 알고리즘 구현

셋째, 인터뷰 시 칠판에 간단한 코딩 과제를 풀게 하는 겁니다. 약 10분이면 풀 수 있는 간단한 문제여야 하고, 이 때는 개발자가 최소한 논리적인 사고를 하는지 점검할 수 있습니다. 사실 코딩 인터뷰를 시도해보면 이 10분에서도 각 개발자들이 엄청나게 많은 차이를 보입니다. 일반 인터뷰 질문으로는 확인할 수 없는 수많은 것들을 여기서 파악할 수 있습니다.

예) itoa함수 구현, strtok 함수 구현 

위 3가지 방법은 모두 효과가 있기 때문에 회사의 상황이나 규모 등에 따라서 적절히 선택을 하면 되겠습니다. 

코딩테스트는 추가 비용 거의 없이 개발자의 실력을 구분할 수 있는 좋은 방법입니다. 아주 뛰어난 개발자를 판단하기는 어려울 수 있어도 형편 없는 개발자는 잘 걸러 낼 수 있습니다.

과거의 경험에 대해서 얘기를 들어보면 경력만 보고 채용을 했다가 아주 쉬운 코딩도 믿고 맡기기 어려운 경우가 많더군요. 코딩테스트는 이러한 것을 막아줄 좋은 수단입니다.

다 만들었어요. 이제 테스트만 하면 되요.

소프트웨어를 개발하는 회사에서는 자주 듣는 말입니다.

그런데, 이 테스트가 언제 끝날지 모르는 경우가 많습니다.

소프트웨어 개발 컨설팅을 하면서 정말 놀란 것 중의 하나가 대부분의 회사가 릴리즈 시 "알파", "베타", "RC", "GA", "FCS"와 같은 단계를 거치지 않는 다는 것이었습니다. 

대부분이 알파수준의 소프트웨어를 만들어서 만족스러울 때까지 테스트와 수정을 동시에 병행한다는 것이었습니다. 이는 큰 회사나 작은 회사나 별 차이가 없었습니다. 개발을 단계적으로 진행하지 않는 회사는 업무와 일정에 대한 정교한 구분 없이 일을 진행하다가 적당한 시점에서 한번의 테스트를 통해 제품을 완성하려고 합니다.

이를 빅뱅(Big bang) 테스트라 하는데 이 방법이 운 좋게 개발 기간을 단축시켜 줄지도 모른다는 기대감으로 일을 중구난방으로 진행하는 것입니다. 하지만 이는 전혀 근거가 없는 생각이며, 테스트를 한번에 끝낸다고 프로젝트가 더 빨리 끝나지는 않습니다. 이 방법은 테스트 기간 내내 혼란에 휩싸이게 만들고, 테스트가 언제 끝날지 도저히 예측할 수 없으며, 일정 기간 내에 품질이 얼마나 향상될 수 있을지 추측조차 하기 어렵습니다. 심지어 통합조차 잘 되지 않기 때문에 내포되어 있는 버그가 얼마나 되는지도 파악하기 어렵습니다. 결국 프로젝트 일정이 가시권에서 점점 멀어지게 됩니다. 운이 좋으면 밤을 새면서 일정대로 프로젝트를 마칠 것이고, 그렇지 않으면 프로젝트가 실패하게 됩니다. 

소프트웨어 프로젝트는 개발 단계 별로 관리하는 것이 좋습니다. 단계 별로 진행을 하면 각 단계가 명확해지기 때문에 프로젝트 진행 상황이 눈에 들어오고, 혼란으로 인한 재작업이 줄어 들며, 프로젝트 일정을 단축시키고, 비용을 절약해 줍니다.

특히, 높은 품질의 제품을 출시하기 위해서는 제품 및 프로젝트의 성격에 알맞게 단계 별 릴리즈를 하는 것이 좋습니다. 릴리즈는 알파, 베타, RC(Release Candidate)단계로 나뉘고 각각의 릴리즈 일정은 미리 계획하여 정해 둬야 합니다.

각 단계에는 다음과 같은 의미가 있습니다.

• 프리알파(Pre-alpha): 알파 이전에 만들어내는 빌드들입니다. 개발 버전(Engineering version)이라고 하기도 합니다. 일일빌드(Daily Build)의 결과물도 프리알파에 해당합니다. 아직 기능이 모두 다 구현이 되어 있지 않습니다.
• 알파(Alpha): 기능이 모두 구현되었으나, 버그는 꽤 많은 상태, 설치도 안되어서 기능을 확인해 볼 수도 없는 등의 버그는 없어서 모든 기능을 테스트 해 볼 수는 있습니다. 일부 작동이 안 되는 기능이 있습니다. 일반적으로 알파버전부터 테스트팀의 공식적인 테스트가 시작됩니다. 이를 알파테스트라고 부릅니다.
• 베타(Beta): 중요한 버그는 거의 수정이 되어서 작은 버그들만 남아 있습니다. 베타 버전은 종종 사용자 평가(Evaluation) 및 외부 테스트(Field Test)를 위해서 외부에 배포되기도 합니다. 이런 목적으로 배포되는 버전을 베타 릴리즈라고 부르며 베타 버전을 사용해 보는 사용자를 베타 테스터라고 부릅니다. 베타버전 이전에 프리베타(Pre-beta)를 만드는 경우도 있습니다
• RC(Release Candidate): 출시를 위해서 만들어진 버전입니다. FCS(First Customer Shipment), 감마(Gamma) 또는 델타(Delta)라고 부르기도 합니다.
• GA(General availability): RTM(Release to Manufacturing)이라고 부르기도 합니다. RC 중에서 테스트를 통과하여 출시 할 수 있는 버전입니다. 일반적인 경우 마지막 RC와 동일합니다. 

이런 식으로 테스트팀에 전달하는 버전이 어느 수준인지 알려주어야 합니다. 그렇지 않으면 알파수준의 버전을 가지고 곧 고객에게 전달할 수 있을 것 같은 착각에 빠지기도 합니다.

모든 소프트웨어를 개발할 때마다 이 같은 단계를 전부 다 거쳐야 하는 것은 아닙니다. 제품의 규모와 난이도, 성격에 따라서 단계를 서로 다르게 정해야 합니다. 대규모 제품이거나 복잡한 팩키지 제품은 이 단계들을 거치는 것이 일반적입니다. 이런 제품을 한번에 높은 품질로 만들어 내기는 어렵기 때문입니다.

하지만 소규모 제품이거나, 고객의 수가 아주 적거나, 업그레이드 프로젝트라서 복잡도가 낮을 경우라면 처음부터 원하는 품질 수준에 근접하게 제품을 만들어 낼 수 있습니다. 이런 경우라면 테스트 단계를 간략하게 해서 진행할 수 있습니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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