이 바닥을 못 벗어난다.

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

처음에 게임회사에서 일을 시작한 개발자는 계속 게임회사에서 일하고, 금융회사, 보안회사, 장비회사, 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지식에 의존하기보다는 적절한 개발 프로세스 및 시스템을 기반으로 개발을 해야 합니다.

나는 혼자가 아니다.

지금 내가 생각하고 행동하는 것은 나 스스로의 힘이 아닙니다. 과거의 수많은 대가들이 이룩해 놓은 지식, 경험과 지혜를 간접적으로 배우면서 자라온 내가 있고 그 바탕 위에 내가 존재 합니다.

이런 성현들의 지식이 없다면 지금의 내가 존재 할 수 있을까요? 원시인과 별 차이 없는 내가 있겠죠.

소프트웨어를 개발하다 보면 수많은 문제에 부딪히는데 그 대부분은 이미 과거에 소프트웨어 개발의 대가들이 다 겪은 후에 그 해결책을 다 만들어 좋은 것들입니다. 그렇지 않고 소프트웨어 역사상 처음 발생하는 이슈는 거의 없습니다.

그런데 많은 개발자들의 개발 행태를 보면 마치 최초의 선구자 같이 행동을 합니다. 과거에서 배우지 않고 자신의 지식과 경험 테두리 안에서 별 희안한 방법들을 생각해 냅니다.

피아노를 배우려고 하는데, 모짜르트도 모르고 그냥 혼자 피아노를 연습하는 것 같습니다. 지금의 피아노 연주 기술은 과거의 수많은 음악가들이 없었다면 존재 할 수 없죠. 또 그 기술은 혼자서 인터넷 보고 익힐 수 있는 것이 아니고 스승에게 배우고, 혼자서 또 부지런히 연습을 해야 합니다.

문서를 왜 써야 하는지? 

Peer review를 왜 해야 하는지? 

소스코드를 어떻게 관리해야 하는지? 

빌드는 어떻게 해야 하는지? 

고객이 요구사항을 자주 바꾸는데 어떻게 해야 하는지?

테스트는 어떻게 해야 하는지?

Internationalization은 어떻게 해야 하는지?

버그 관리는 어떻게 해야 하는지?

개발 시간을 어떻게 단축할 수 있는지?

이외에도 수천가지 소프트웨어 개발 이슈들은 이미 과거의 대가들이 다 고민하고 방법들을 제시해 놓은 것들입니다. 하지만 이를 배울 스승이 부족하고, 책만 보고 배우기는 어렵기 때문에 나름대로의 방법들을 사용하고 있습니다. 그래서 결국에는 한계에 부딪히게 됩니다.

이러한 지식들을 총칭해서 소프트웨어 공학이라고 합니다. 과거의 대가들에게서 간접적인 도움을 받으면서 소프트웨어를 효과적으로 제대로 개발을 하려면 소프트웨어 공학에 관심을 가져야 합니다. 책을 보면서 간접 경험을 하고 전문가나 스승을 만날 기회가 있다면 최대한 많이 배우려고 노력하고, 가장 좋은 방법은 그런 대가들이 바글바글한 회사에 취직해서 직접적인 경험을 하는 것이지요. 

Peer review의 혜택

"Peer review를 해야 하는데 바빠서 못하고 있다"라는 말을 종종 듣게 됩니다.

이 말을 들으면 Peer review를 해야 한다는 필요성을 사실은 알지 못하고 있다는 것을 알게 됩니다.

다들 Peer review를 해야 한다고 하니까 거기서 Peer review를 할 필요 없다고 하면 혼자 이상한 사람이 되니까 그냥 그렇게 얘기를 하는 것이지요.

정도는 다르지만 소프트웨어를 개발하고 있다면 기본적으로 Peer review는 꼭 필요합니다.

Peer review의 기본적인 2가지 목적은 다음과 같습니다.

1. 결함의 발견

2. 정보의 공유

Peer review를 말하면 Code review를 먼저 생각하는 사람들이 많은데, 사실 Code보다도 문서 Review가 더 필요합니다. 그 중에서도 스펙(SRS)의 리뷰가 가장 중요한 문서 중에서 하나지요. 문서가 코드보다 결함이 있을 경우 더 심각하고 나중에 고치려면 더 많은 비용이 들고, 개발 기간을 단축하고 효과적으로 일하려면 문서를 제대로 만들고 리뷰를 해야 합니다.

그럼, Peer review(스펙, 설계, 소스코드, 테스트 문서)를 하면 실제적으로 어떠한 혜택이 있는지 알아보도록 하겠습니다.

개발자

재작업 시간을 감소시켜 줍니다.
개발 생산성을 높여줍니다.
선배들로부터 많은 기술을 습득할 수 있습니다. 또 개발자간의 정보를 공유합니다.
디버깅 및 단위 테스트 시간이 줄어듭니다.

유지보수개발자

기술 지원 이슈가 감소하고, 기술지원이 손쉬워 집니다.
소프트웨어의 구조를 쉽게 파악할 수 있습니다.
유지보수가 용이해 집니다.

테스터

테스트 기간이 단축됩니다.
심각한 버그가 감소합니다.
테스트 케이스를 만들기 용이해 집니다.

분석가

잘못된 요구사항을 조기에 발견할 수 있습니다.
요구사항이 개발가능 해지고, 테스트가 가능해 집니다.

프로젝트 관리자

프로젝트 일정일 지키기가 더 용이해 집니다.
프로젝트의 리스크를 조기에 발견할 수 있습니다.
범위의 변경이 줄어듭니다.
협업이 개선됩니다.

위의 혜택 중에 더 많은 부분이 문서리뷰에서부터 비롯되며, 만약에 Peer review를 전혀 하지 않는다면, 위의 혜택들이 NOT이 되는데, 그런 프로젝트는 상상하기가 어렵네요. 

리뷰 문화가 아직 정착이 되지 않았다면, 일단 스펙을 작성할 때는 꼭 모든 관련자가 리뷰를 해야 한다는 규칙을 정해서 조금씩 리뷰에 적응하는 것이 어떨까요?

Peer review는 규칙에 의한 강제에 의해서도 자율만에 의존해서도 정착시킬 수 없습니다. Peer review에 필요한 기초 역량등 제반 여건이 되어 있어야 하고(이 정도도 안되면서 Peer Review를 한다고요?), 처음에는 어느정도 강제화를 하면서 점점 업무속에 파고들게 해야 합니다.

개발자 여러분~ 문서 만들기 싫죠?

흔히들 소프트웨어를 개발하는데 문서를 만드느라고 시간이 더 오래 걸린다고 생각합니다. 문서가 필요한 것은 알고 있는데, 만들기는 싫다고들 합니다. 이러한 생각을 깨기 전에는 문서의 필요성에 대해서 이해하기가 어렵습니다. 

소프트웨어를 개발하는데 문서를 만들어서 더 오래 걸렸다면 잘못된 것입니다.

필요도 없는 문서를 잔뜩 만들고 있거나, 문서를 작성하는 실력이 없어서 낑낑대고 시간만 잡아먹는 경우 일겁니다. 두번째 경우야 그러면서 실력이 늘 수도 있지만, 필요 없는 문서를 잔뜩 만들고 있다면 정말 헛고생하고 있는 겁니다.

문서를 만드는 이유는 소프트웨어를 더 빨리 만들기 위해서 입니다.

거꾸로 문서도 안 만들고 어떻게 더 빨리 만들 수 있냐고 반문하고 싶습니다.

모든 내용을 머리 속으로 모두 기억하고 있다?
2명 이상이 개발을 할 경우 모든 정보는 대화로 공유하나?
모든 것을 혼자서 결정할 수 있나? 리뷰는 안 하나?
이런 궁금증이 생깁니다.

결론은 혼자 모든 것을 마음대로 결정해도 좋고 

협업 없이 혼자서 개발을 하고
천재일 경우는 가능하네요.

이런 경우가 아니라면 크든 작든 문서가 필요할 것입니다.

간단한 문서만 있어도 되는데 장황하게 많은 문서를 만든다면 오히려 이것이 잘못된 것일 겁니다.

충실하고 자세한 문서가 필요한데 문서가 없거나 너무 간단하다면 개발이 더 오래 걸릴 겁니다. 

이 판단이 프로젝트마다 다르다는 겁니다.

그래서 모든 프로젝트에서 기계적으로 모든 문서를 만들어내라고 하면 비효율적이 아닐 수 없습니다. 그리고 이를 프로젝트 기간이나 투입인원에 따라서 또 기계적으로 정할 수 없는 노릇입니다. 결국 경험 있는 프로젝트 팀에서 결정할 일입니다.

프로젝트에 꼭 필요한 문서를 최소한으로 만들고 유지하는 것이 올바른 방법입니다.

Track me, if you can

"요구사항 추적"이라는 말을 들어 보셨을 겁니다.

요구사항, 기능, 컴포넌트(클래스), 파일, 함수들의 연관관계를 추적하여 특정 요구사항에 관련된 컴포넌트나 소스코드들을 추적하고, 거꾸로 함수가 바뀔 때 이 변경에 영향을 받는 요구사항을 알아낼 수 있습니다.

왠지 근사해 보입니다.

실제로 요구사항을 추적하려고 노력하는 회사를 종종 보게 됩니다. 하지만 요구사항을 추적할 필요도 없는 작은 소프트웨어이거나 엉터리로 하고 있는 경우가 대부분입니다. 아니 100%입니다.

요구사항 추적이라는 것이 말만 근사해 보이지, 대부분의 역량으로는 거의 불가능합니다. 또 요구사항 추적툴 없이 엑셀파일에 끄적거려서는 할 수 없는 일입니다. 

요구사항 추적은 사람의 생명을 다루는 소프트웨어이거나 엄청난 비용과 테스트가 불가능한 우주선을 만들 때나 사용하면 됩니다. 이 경우는 감히 비용대비 효과를 논하기가 어려우니까요.

우리가 접하는 대부분의 소프트웨어는 요구사항 추적이 필요 없습니다. 실제로 요구사항 추적이 대단히 어려울 뿐만 아니라 요구사항 추적을 해서 얻는 것이 별로 없습니다. 요구사항 추적을 해보신 분들은 아시겠지만, 실제로 어설픈 문서라도 만들어 놓고 써본 적도 별로 없을 겁니다. 또, 요구사항이나 컴포넌트가 변경이 되어도 요구사항 추적 문서를 갱신하는 것은 대단히 어렵습니다. 오히려 방해 요소가 됩니다.

대부분의 소프트웨어는 요구사항 추적을 하지 않아도 별 문제없을 만큼 작거나 테스트로 충분히 커버가 됩니다.

단 하나, 고객이 요구사항 추적 문서를 꼭 원할 경우 설득을 해보고 안되면, 엉터리 문서라도 만들어 주는 것이 좋겠죠. 이때는 어차피 요구사항 추적 문서를 활용하기 위한 것이 아니니 최소한으로 간단하게 만드는 것이 좋을 겁니다.

이렇게 문서를 꼭 만들어야 하는 상황이 아니라면 근사해 보인다고 괜히 요구사항을 추적해볼 필요는 없습니다. 추적한다고 추적이 되는 것이 아니니까요. 그런 노력을 테스트를 제대로 하는데 들이는 것이 훨씬 더 효율적입니다.

과거의 개발자 vs. 미래의 개발자

개발자는 2가지의 상반된 가치를 가지고 있습니다.

하나는 과거의 가치
또 하나는 미래의 가치입니다.

"이 사람들 나가면 과거에 개발해 놓은 것 어떡하지?"라는 생각이 들면 과거의 가치를 가진 개발자이고

"이 사람들 나가면 미래에 개발은 누가 하지?"라는 생각이 들면 미래의 가치를 가진 개발자입니다.

과거의 가치를 가진 개발자들은 본인이 아니면 유지보수가 어렵게 소프트웨어를 개발해 놓았고, 대부분의 지식은 머리 속에 있기 때문에 자신이 과거에 만들어 놓은 소프트웨어를 인질 삼아서 회사와 인질극을 벌이고 있는 것과 같습니다. 이렇게 된 원인이 상당부분 회사에 있다고 하더라도, 개발자의 가치는 인질범과 별반 다를 바가 없습니다. 기존 소프트웨어를 망칠까봐 대우해줄 수 밖에 없습니다.

미래의 가치를 가진 개발자들은 자신이 과거에 만들어 놓은 소프트웨어들은 후배들이 유지보수 할 수 있도록 충분히 문서화를 해 놓았고, Peer review를 통해서 이미 많은 지식이 전달된 상태입니다. 이러한 개발과정을 거쳐서 본인은 분석, 설계 능력을 더욱 향상시켰고, 신기술들에 대한 연구에 집중하여 미래에는 과거의 제품들 보다 한 단계 높은 수준의 제품들을 만들어 낼 것입니다. 이러한 개발자들이 진정한 영웅이라고 할 수 있습니다.

인질범이 되겠습니까? 영웅이 되겠습니까? 이는 본인의 의지에 달려있습니다.

안타까운 것은 고참 소프트웨어 개발자 중에는 영웅보다 인질범이 더 많다는 겁니다. 물론 이 개발자가 인질범과 다를바가 없다는 것을 본인도 모르고 회사도 모르는 경우가 태반이지만 말입니다.

개발자들이 바글바글한 외딴섬에 떨어진다면

개발자들이 바글바글한 외딴섬에 떨어졌는데 서로 뒤죽박죽으로 개발을 하고 있고,이들을 3개월 안에 훈련시켜서 정예 개발자로 만들어 한다는 미션이 떨어졌다면 무엇을 하시겠습니까?

Language 기초를 다시 가르칠까요?

UML을 가르칠까요?
문서 작성법을 훈련 시킬까요?
개발방법론을 가르칠까요?
팀워크를 키워줄까요?
OOP를 가르칠까요?

어떻게 하시겠습니까?

나는 스펙을 작성하는 방법을 가르치고 3개월간 훈련을 시킬 겁니다. 

즉 Requirement engineering을 익히게 하겠다는 뜻입니다. 그만큼 스펙은 현재 소프트웨어 개발현장에서 가장 많은 실패의 원인이 되고 있고, 배우기도 가장 어려운 분야입니다. 나는 수많은 개발자들이 작성한 스펙문서(다양한 이름의 문서)를 봐 왔지만, Requirement engineering을 제대로 알고 잘 작성한 스펙문서는 별로 접해보지 못했습니다. 또한 그로 인해서 프로젝트나 제품에서는 수많은 문제들이 야기되고 있었습니다.

물론 스펙을 제대로 쓰기만 한다고 소프트웨어를 잘 개발할 수 있는 모든 준비가 된 것은 아닙니다. 스펙을 쓰는 것은 이제 소프트웨어 제대로 된 소프트웨어 개발에 한 걸음 내디딘 것 뿐입니다. 거꾸로 스펙도 쓰지 않고 소프트웨어를 어떻게 개발하냐고 반문할 수 있습니다. 즉, 무엇을 개발할지도 모르고 여럿이서 소프트웨어를 어떻게 개발하냐는 것입니다. 또 영업이나 고객은 정확하게 무슨 제품이 나올지도 모르고 기다리냐는 것입니다.

하지만, 이에 대한 반론을 얘기하는 사람도 꽤 됩니다. 기존에 제대로 된 스펙 없이도 훌륭한 제품을 많이 탄생했고, 성공한 제품도 꽤 된다고 얘기합니다.  물론 예외는 항상 있습니다. 저도 몇몇 그런 사례를 알고 있습니다.

정확하게 따지면, 그렇게 성공한 제품은 별로 많지는 않습니다. 그리고 초창기에 제품의 크기가 작거나 고객 수가 작을 때는 멋진 제품이었으나 매출이 늘고, 소프트웨어 규모가 커지면서 망가진 제품도 꽤 많습니다. 즉, 스펙의 부실로 혼동에 빠져서 실패한 제품이 꽤 됩니다.

제대로 된 스펙도 없는 제품이 성공할 확률은 잘 작성된 스펙을 토대로 개발하고 유지보수 되는 제품의 성공확률의 1/10도 안될 겁니다. 

소프트웨어 개발자라면 스펙이 왜 중요하고, 스펙을 잘 적기 위해서 배우고 많은 노력을 기울여야 한다는 것을 알아야겠습니다.

PS) 가끔 우리나라가 소프트웨어 업계에서는 섬처럼 느껴지곤 합니다.