개발자 100명을 더 투입한다면?

소프트웨어 회사에서 프로젝트를 진행할 때 흔히 벌어지는 문제가 "개발자가 부족해서 프로젝트가 늦어진다"는 것이다.

그럼 거꾸로 애플에서 날고 기는 개발자 100명을 투입시켜 줄테니 프로젝트를 제대로 끝낼 수 있냐고 물어보면 대부분 대답은 "글쎄요"다.

벽돌을 쌓거나 땅을 팔때는 사람을 2배 투입하면 대부분 시간이 반으로 줄어든다.

그런데 소프트웨어를 개발하는 프로젝트에서는 왜 그렇게 잘 안될까?

그 이유는 "스펙과 설계"에 있다.
빌딩을 세울 때는 설계가 명확하게 있다. 이 세상에 설계 없이 만드는 빌딩은 없을 것이다. 그리고 협업이 가능하도록 일이 세분화 되어 있고 전문화 되어 있다.

그런데 유독 소프트웨어(특히 우리나라)에서는 스펙과 설계가 땅파고 벽돌 쌓는 것보다 시원찮다. 그런 상태에서 개발을 하다보니 건설현장에서 빌딩 올라가듯이 개발이 되는 것이 아니고 뒤죽박죽이 된다. 이런 환경에 익숙해진 개발자는 뭐가 문제인지 인지하지 못하는 경우가 대부분이다.

스펙과 설계가 제대로 작성되어야 협업이 가능하다. 

여기서 핵심은 컴포넌트다. 컴포넌트가 일을 깔끔하게 나눠서 일할 수 있을 만큼 깨끗하게 나눠져 있어야 한다. 그래서 부서별, 개발자별로 일을 나눠서 할 수 있고 서로 인터페이스 맞추느라고 시간을 허비하지 않는다. 


스펙과 설계가 제대로 되지 않은 상태에서 개발을 하면 컴포넌트 단위로 일을 나눠서 할 수 없기 때문에 "화면"단위로 일을 나눠서 하기도 하고, 적당히 일을 나눠서 하다가 서로 겹치기도 하고 나중에 통합에 엄청난 시간이 걸리게 된다. 또한 어떻게 소프트웨어가 동작은 한다고 하더라도 그 아키텍처는 뒤죽박죽이 되어서 나중에 유지보수도 엄청나게 어렵게 된다.

그럼 스펙/설계 단계에서 어느 정도까지 설계가 이루어져야 할까?

대답은 의외로 간단하다.  스펙/설계의 결과를 가지고 소프트웨어 개발자들이 충분히 구현을 할 수 있을 정도면 된다. 여기서 "충분히"라는 단어는 몹시 애매하다.

문서만 보고 서로 전혀 대화를 하지 않고도 구현을 할 수 있으면 너무 자세히 적은 것이다. 이렇게 자세히 적으면 시간 낭비이고, 개발자에게 너무 자유도를 없앤 것이다. 

그럼 "충분히"는 어느 정도 일까?  개발자가 설계대로 구현을 하면서 약 5% 정도의 내용은 설계자나 관련된 컴포넌트 개발자와 서로 의논하면서 개발할 수 있을 정도면 적당하다고 할 수 있다. 너무 많은 내용을 의논하면서 구현시 결정해야 한다면 적은 내용이 너무 부족한 것이다. 따라서 "충분히"는 상황에 따라 다른 것이다.

설계가 부족하다면 프로젝트리더(테크니컬리더)는 여러 개발자에게 설명하느라고 시간을 보내고 자신이 담당한 개발을 할 시간이 부족해지고, 개발자들에게 설명을 소홀히 하면 개발자들이 제 멋대로 개발을 해와서 문제가 생기곤 한다. 나중에 이를 고치느라고 시간이 몇배로 낭비된다.

설계는 스펙을 작성할 때부터 시작이 되고 설계 단계에서는 컴포넌트가 다 구분되고 인터페이스가 정의가 되어서 소스코드 상에 모두 적히고 컴파일이 가능하도록 해야 한다.

그러기 위해서는 파일이름, Class이름, Public 함수 이름과 parameter, return값이 모두 정해져야 한다. 그리고 그 설명을 문서에 다는 것은 중복이기 때문에 Doxygen이나 Javadoc을 이용해서 소스코드에 주석으로 설명을 하면 효율적으로 설계 정보를 관리할 수 있다.

이렇게 설계가 완료되면 바로 Daily Build가 가능하며 구현 첫날부터 개발자들은 빌드가 가능한 소스코드에 자신이 맡은 컴포넌트의 내용을 채워나가면 되는 것이다. 즉, 첫날부터 이미 통합이 된 상태에서 개발을 하는 것이다.

이렇게 스펙과 설계를 작성하면 일정 산정의 정확도도 훨씬 올라가고 개발자를 더 투입하더라도 도움이 된다. 또한 외주로 개발하는 것도 가능하다.

물론 외주를 줄 경우에는 "설계"도 외주를 주는 경우가 많으므로 이런 경우는 "스펙"까지를 제대로 작성하면 된다.

이렇게 일을 효과적으로 나눠서 할 수 없다면 스펙/설계를 제대로 작성한 것이 아니다. 개발 시간과 비용도 줄일 수 있다. 가장 중요한 것은 프로젝트가 관리 가능한 상태가 된다는 것이다. 일정과 비용이 상당히 정확하게 예측 가능해지고 일정이 지연 상태를 빠르게 파악할 수 있고 대처를 할 수 있다.  스펙과 설계를 제대로 작성할 수 없다면 온갖 프로젝트 관리 기법은 다 소용없다. 결국 야근 밖에 남지 않는다.

"일을 나눠서 할 수 있다."는 것은 결국 개발자가 행복하게 일할 수 있도록 해준다.

설계가 필요할까?

최근에 Software Architect의 정체에 대해서 혼란을 겪고 있는 것 만큼 Software 설계에 대해서도 혼동스러운 것은 마찬가지인 것 같다.

그래서 설계에 대해서도 깔끔하게 정의를 해보자.
흔히 설계에 관한 다음과 같은 궁금증을 가지고 있다.
 

1. SW를 개발하는데 설계는 과연 필요할까?
2. 설계서는 작성할 필요가 있을까? SW는 설계서 없이 개발하는 것이 더 빠르지 않나?
3. 설계는 어떤 기법을 이용하는 것이 좋을까?
4. 설계툴은 UML을 꼭 이용해야 하나? 

일단, 설계를 하는 행위와 설계서를 작성하는 행위를 분리해서 생각하는 것이 좋다.

첫째, 우리는 설계서를 작성하든 하지 않든 "Hello world"를 제외하고는 설계 없이 개발하기 어렵다. 단지 단순한 것은 설계를 머리 속으로 할 뿐이다.

복잡하거나 여러 사람들이 서로 나눠서 개발을 해야 하는 경우는 머리 속으로만 설계를 하기란 거의 불가능하다. 천재라도 복잡한 시스템을 머리로 설계를 할 수 있지만 두뇌를 꺼내서 다른 사람에게 보여줄 수는 없는 일이다. 그래서 설계서를 작성하게 된다.

설계서 없이 개발이 가능한 경우는 극소수일 뿐이다. 

그럼 주변에서 보는 설계서 없이 개발하는 수많은 프로젝트는 무엇인가? 

대충 머리 속으로 설계를 해서 코딩을 하면서 서로 맞춰가는 것이다. 이런 식으로라면 재작업하는 일이 여러번 발생하게 되어서 오히려 시간이 더 많이 걸린다. 재작업 문제만 있는 것이 아니다.

설계는 필요한 만큼 해야 하고 거의 대부분은 문서화를 해야 한다.

즉, "Hello world"보다 복잡하거나 다른 사람과 나눠서 일을 하거나 다른 시스템과 인터페이스가 있을 경우는 설계를 적어야 한다.

설계 없이 만들어보려고 하는 것은 Software밖에 없을 것이다. 집, 빌딩, 전자부품, 애들 장난감 모두 설계가 있다. 

둘째, 설계는 어디에 적히는 것일까?

많은 설계는 소스코드와 중복이 되게 된다. 소프트웨어를 개발하는데 있어서 중복은 2배가 아니라 10배의 문제를 야기한다.  따라서 최대한 중복은 피해야 한다.

일단, 설계의 시작 부분은 스펙(SRS)에 적히게 된다. 시스템의 조망과 구조는 스펙의 가장 중요한 부분 중 하나이다. 이렇게 스펙에 설계를 적기 시작하면 스펙과 설계의 경계가 모호해지게 된다. 스펙과 설계의 경계는 따로 정해져 있는 것이 아니고 상황에 맞게 판단하면 된다.

라이브러리를 개발하는냐,  웹서비스를 개발하느냐,  게임을 개발하느냐에 따라서 그 경계는 달라질 수 있다.

보통의 경의 스펙에는 상위 설계 언저리 까지 적히는데 많은 프로젝트에서 설계는 이 정도만 적혀도 충분하다.

설계가 충분하지 아닌지 판단은 이 설계를 가지고 다른 개발자들이 나눠서 각자 개발을 할 수 있는지 생각해보면 된다. 그렇다면 스펙에도 어느 정도로 적히는지를 상상할 수 있을 것이다.

따라서 시스템의 크다고 하더라도 설계서가 별도로 없이 UI만 있어도 개발이 가능한 Web 등의 시스템은 스펙에 적히는 정도만 가지고도 개발이 가능하다.

이것으로도 부족하면 별도의 설계 문서를 만들기도 한다. 개발자가 수십명이상 참여하는 프로젝트에서는 대부분 별도의 설계서가 따로 있어야 할 만큼 시스템이 크다.  그런 경우는 설계서를 따로 만드는 것이 좋다.

셋째, 설계는 어떻게 해야 하는가? 무엇을 고려해야 하고 무엇을 적어야 하는가?

설계를 하는 방법에 대해서 고민을 하는 개발자는 매우 많다. 막상 회사에서 설계서를 만들라고 하면 막막하고 많은 경우 코딩을 다 하고 형식적으로 만드는 경우가 많다.

이런 경우는 설계도 제대로 한 것이 아니고 설계서도 엉망이다. 거의 쓸모 없는 문서를 시간을 더 들여서 만든 것이다. 나중에 유지보수에 필요하다고 하는데 유지보수에서 가장 많이 필요한 것은 소스코드와 스펙이다.

설계는 해당 프로젝트를 제대로 짧은 시간 안에 끝내기 위해서 하는 것이다. 또한 잘 된 설계는 미래에 발생할 여러가지 환경을 반영해야 한다. 이렇게 작성된 설계서라야 시스템과 일치를 하며 유지보수 시에도 유용하다.

설계의 기준이 되는 것은 스펙이다. 즉, 스펙이 제대로 적히지 않으면 좋은 설계가 나올 수 없다.

스펙이 없거나 기껏해야 기능명세만 적었다면, 설계는 아무리 잘해도 현재의 요구 기능이 동작하는 것에만 머물 것이다.

이 부분이 가장 중요하다. 수많은 회사들이 여기서 다 망쳐서 지금 그 고생들을 하고 있는 것이다.
스펙에 기능명세 뿐만 아니라 미래의 비즈니스 전략과 비기능 요구사항들이 모두 적혀야 있고 이를 설계에 반영해야 한다.

스펙이 이러한 내용들이 누락이 되어 있으면 설계가 어떻게 될지 상상해보라.

• 지금은 고객이 10개 회사인데 5년 안에 1,000개의 고객사를 확보할 것이다.
• 지금은 국내 판매를 대상으로 하는데 1년 후 부터는 세계 200개 회사를 대상으로 마케팅을 할 것이다.
• 현재의 시스템은 내년에 회사의 다른 시스템들과 통합하는 작업이 진행 될 것이다.
• 현재는 C/S 구조인데 2년 안에 Web을 지원해야 한다.
• 현재는 Windows만 지원하는데 1년 안에 MacOS, 2년 안에 iPhone과 Android 폰을 지원해야 한다.
• 지금은 모델이 3개지만 내년까지 100개의 모델이 5년 안에 5,000개의 모델이 생산될 것으로 예상된다. (사업이 잘 될 경우)
• 지금은 카메라 모듈을 한 가지만 지원하지만 5년 안에 100개 이상의 카메라 모듈을 지원해야 할 가능성이 80%이다.
• 현재 만든 Framework로 2년 안에 사내의 모든 TV의 Firmware를 교체할 예정이다.

위 예는 실제 현장에서 발생할 수 있는 수백만개 경우 중 몇 개일 뿐이다.

이러한 내용들이 설계에 적절히 고려되지 않는다면 미래에 큰 댓가를 치루게 된다. 이러한 것을 SW에 잘 반영하도록 설계를 하는 사람들을 Architect라고 부른다.

이런 것을 고려하지 않고 마구 어질러 놓고 인력만 많이 투입해서 엄청 비효율적으로 일을 하고 있으면 그 원인과 방법도 모른체 계속 똑같은 시행착오를 계속 반복할 가능성이 99%이다.

넷째, 특별한 툴을 이용하는 것이 좋은가?

 나는 설계를 위해서 특별한 툴이나 방법론을 선호하지 않는다. 하지만 툴가 방법론을 팔아먹는 사람들이 만병통치약처럼 선전을 한다.

좋은 워드프로세스를 쓴다고 좋은 소설이 안나오고 비싼 붓 쓴다고 그림 잘 그리는 것이 아니듯이 설계를 가장 잘 표현할 수 있는 툴을 알아서 쓰면 된다. 혼자만 이상한 것을 써서 다른 동료들이 편집하지 못하게 해서도 안된다.

설계의 핵심은 컴포넌트와 인터페이스를 적절히 나누고 표현하는 것이기 때문에 이것을 그릴 수 있으면 된다. 그냥 워드프로세서로 정리를 하는 경우가 많다.

하지만 설계를 하는 중간 과정에는 툴을 가지고 깔끔하게 정리를 하는 것은 시간 낭비이다. 설계가 끝날 때까지 설계는 전체를 뒤엎는 과정을 수차례 겪으므로 정리를 해 놓은 낭비이다.  큰 종이나 칠판에 적고 지우고를 반복하는 것이 좋다. 그렇게 거의 완성이 되면 옮겨 적으면 된다. 

심지어는 사진을 찍어서 이미지를 문서에 첨부하기도 한다. 이런 경우는 나중에 편집이 안되므로 적절히 사용해야 한다. 그래서 나는 조그만한 화이트보드에 설계를 하고 지우지 않고 관리를 하다가 나중에서 조금씩 수정하기도 한다.

그 외에 필요한 것은 설계자가 적절히 판단해서 시스템을 표현할 수 있는 그림이나 다이어그램을 그리거나 글로 적기도 한다. 여기서 창의성을 발휘해야지 규칙을 정해 놓고 따라하면 오히려 비효율적으로 변하게 된다.

디자인패턴 하나 배워서 모든 곳에 써먹는 것은 태권도 정권지르기 하나 배워서 그걸로만 싸우는 격이다. 분명히 도움은 되지만 상황에 맞게 적절한 방법을 창의적으로 생각해 내는 것이 가장 좋다. 그러기 위해서는 먼저 많이 알아야 하고 경험도 많아야 한다.

하위 설계는 소스코드와 중복이 되므로 그냥 소스코드로 작성하는 것이 좋다. Doxygen이나 JavaDoc을 이용하면 소스코드에서 필요한 설계 문서를 거꾸로 만들어 낼 수 있다.

결론

설계는 필요한 만큼 적절하게 꼭 해야 한다.

하지만 흔히들 문서화의 부담 때문에 아예 안하거나 적는 방법을 몰라서 너무 많이 적는다.
설계문서는 꼭 필요한 만큼만 적절하게 적어야 한다. 가장 어려운 말이지만 이 이상으로 표현하기는 어렵다.

설계서는 한 페이지가 될 수도 있고 수천 페이지가 될 수도 있다. 스펙이 이를 결정한다.

만약 제대로 된 스펙이 없다면 차라리 스펙을 제대로 적는데 먼저 신경을 써야 한다. 설계는 스펙 다음이다.

Software Architect를 양성하는 나라

우리나라에서는 종종 SW Architect를 양성한다고 한다. 
정부에서 막대한 예산이 지원도 되며 SW Architect를 양성하는 학원도 생기고 야단법석이다.

그럼 도대체 SW Architect는 무엇인가?

 SW Architect 교육을 받아야 Archtect인가? 설계 방법론을 알아야 하는가? 설계 툴을 다룰 수 있어야 하는가?
이런 접근은 SW Architect에 대한 왜곡된 시각을 유발할 수 있다.

SW Architect는 "고참 개발자"이다. 외국에서 SW Architect 양성 학원이 있나 물어보라. 개발자들이 스스로 SW Architect라고 강조하는지 알아봐라. 

그냥 Software를 오래 개발하면서 경험이 쌓이고 고참 개발자가 되면 그냥 SW Architect인 것이다.

그런데 왜 우리나라는 SW Architect에 대해서 열을 올리고 있는 것일까?

아마, 많은 고참 개발자들이 일반적인 기준의 SW Architect에 미치지 못해서 쓸만한 사람이 부족하기 때문일 것이다. 물론, 그 원인이 개발자에게 있다고 전적으로 말할 수는 없다. 환경적인 요소가 크고 그런 환경에서 자란 개발자들은 피해자라고 볼 수도 있다.

그럼, SW Architect라고 말할 수 있으려면 어떤 일을 해야 할까?
SW Architect는 한마디로 Software 설계를 할 줄 아는 사람이다. 물론 설계만 하는 것이 아니고 코딩도 한다. 때로는 스펙도 적는다.

SW Architect라고 불리려면 설계를 제대로 해야 한다. 제대로 된 설계는 현재 뿐만 아니라 미래에 발생할 수많은 요구사항을 유기적으로 고려하여 가장 합리적인 구조를 만드는 것이다. 
그리고 설계를 머리 속으로만 하는 것이 아니고 문서로 만들 수 있어야 한다. 이렇게 작성된 설계 산출물을 가지고 설계자 본인이 아닌 다른 사람들이 코딩을 할 수 있어야 한다.

내가 설계한 것을 내가 코딩 할 밖에 없다면 빌딩을 설계한 사람이 벽돌도 쌓는 격이다. 비용적으로 비효율적일 뿐만 아니라 벽돌은 더 잘 쌓는 사람에게 맡기는 것이 낫다.

설계를 잘하려면 우선 분석이 잘되어야 한다. 즉 SRS가 잘 작성되어야 한다. 분석이 대충 되는 환경에서는 좋은 설계가 나올 수도 없다. 또한 우리나라 대부분의 고참 개발자들은 설계서를 잘 작성해서 다른 개발자들이 개발할 수 있도록 넘기는데 아주 취약한다. 그런 식으로 개발을 안 해봤기 때문에 방법을 잘 모른다.

수많은 설계 방법론이나 툴이 이를 해결해주지 않는다. 설계는 형식에 구애받지 않고 가장 효과적으로 기술하는 것이 좋다. 이러한 역량은 따로 배울 수 있는 것이 아니고 좋은 환경에서 경험과 협업에서 저절로 익히는 것이다.

그럼에도 불구하고 많은 SW Architect 교육이 툴과 방법론이 주류를 이루는 것은 이것 외에는 마땅히 전파할 것이 없기 때문이다.

즉, 단시간 SW Architect 교육을 받는다고 설계 역량이 향상되는 것은 아니다. 지식을 아는 것은 도움이 될 수 있지만, 오히려 위험한 경우가 더 많다.

경험과 실력에 걸맞지 않게 지식들이 들어오면 현실성의 판단이 흐려져서 무리한 적용으로 오히려 낭패를 볼 수도 있다. SW Architecture는 적절해야 하는데 그 적절함을 판단하지 못하는 것이다.

정부에서 SW Architect를 양성하는 것 자체를 반대하지 않는다. 그렇게 효율적이지는 않지만 안하는 것보다는 나을 것이다. 하지만 그런다고 단기적으로 많은 SW Architect가 생겨나는 것은 아니다. 그러니 큰 기대는 하지 말자.

본인이 SW Architect가 되고 싶은 사람은 이런 교육에 기웃거리는 것보다는 스펙을 잘 쓰고, 설계를 해서 다른 팀원들에게 개발을 맡겨보는 일에 좀 더 집중하는 것이 좋다. 이것이 처음부터 잘 될리는 만무하다. 하지만 경험을 여러차례 해보면 점점 나아질 것이다. 

그때서야 외부에서 접하는 여러 지식들이 도움이 될 것이다.

UML전문가가 설계전문가?

종종 "소프트웨어 설계를 잘 하려면 UML을 잘 알아야 합니까?"라는 질문을 받습니다. 

사실 넘치는 기법들이 개발자들을 더 혼란스럽게 하는 것에 종종 화가 날 때가 있습니다.

기법은 기법일 뿐입니다. 내용은 아니죠.

UML은 잘 정리된 모델링, 설계 기법이며 툴이고 많은 장점을 가지고 있다고 생각합니다.

그럼에도 불구하고 소프트웨어 설계라고 하고 UML을 떠올리는 것을 보면 UML이 본의 아니게 나쁜 일도 했다는 생각이 듭니다. 

잘 된 설계는 형식에 구애 받지 않고, 소프트웨어를 구현하기 충분하게 소프트웨어 구조를 잘 설명한 것입니다. UML이 그 중의 하나가 될 수도 있고, 전통적인 Flowchart, DFD, 수도코드나 글로 설명할 수도 있습니다. 설계는 어떠한 다이어그램을 그리고 어떤 툴을 쓰냐에 따라서 잘 되었는지 결정되는 것이 아니고 어떤 식으로 접근해서 설계를 하였고, 리뷰 하였는지가 더 중요하고, 이를 보고 구현을 담당한 개발자(본인일지라도) 충분히 구현할 수 있는 적당한 정도가 좋습니다. 그리고 미래의 비즈니스 비전에 대응할 수 있는 구조여야 합니다.

따라서 나는 설계를 시작할 때 종이와 연필 또는 화이트보드를 가지고 시작합니다. 개발자들이 토론을 하면 깔끔하게 컴포넌트를 나누는 것으로 설계를 시작합니다. 

설계 초기부터 툴을 이용해서 정리를 시작하면 감이 잘 안 오고 잦은 수정 때문에 귀찮을 수가 있습니다.

UML을 아는 것은 좋습니다. 남들이 UML로 작성해 놓은 것을 읽을 수는 있어야 하니까요.