설계가 필요할까?

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

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

우리에게 지금 필요한 것은? 바로 이것

우리나라 대부분의 소프트웨어 회사들에게 가장 시급하게 필요한 것은 "기초 체력"이다.

히딩크가 우리나라 국가대표 축구팀을 처음 맞았을 때 강조한 것이 기초 체력이었다.

그전까지 우리는 국가대표 축구팀이 체력은 세계 어디를 내놔도 뒤지지 않을만큼 뛰어나지만 골결정력 등 섬세한 고급 기술들이 부족하다고 생각했었다.

하지만 히딩크는 이를 전면 부정하고 고등학교 축구팀처럼 기초 체력 훈련에 집중했다. 주변의 반대가 심했지만 강행했다.

그리고 월드컵에서 그 결과를 보았다. 경기 후반 다른 나라 선수들이 지쳤을 때 우리 선수들은 한발 더 뛸 수 있었고 승리로 이어졌다.

우리나라 개발자들은 개인기들은 뛰어나다. 즉, 코딩을 잘하는 개발자도 많고 온갖 지식도 많이 안다.

솔직히 이 정도로 많이 아는 개발자들은 전세계적으로 찾아보기 어렵다. 그럼에도 세계적인 소프트웨어 회사가 우리나라에 없고, 세계적인 제품을 찾아보기 어려운 것은 기초 체력이 부족하기 때문이다.

개발자들이 많이 아는 지식은 혼자서 배우고 익힐 수 있는 것들이다. 이것은 노력하는 개발자라면 누구나 다 잘 한다.

하지만 기초 체력은 혼자서는 절~대로 배울 수 없는 것들이다. 대부분 잘 갖춰진 개발문화를 가진 SW회사에서 몇년씩 일하면서 자연스럽게 배울 수 있는 것들이다. 그렇게 쌓은 기초 체력을 갖춘 개발자들이 버글버글 해야 그들이 뭉쳐서 좋은 소프트웨어도 만들고 그중에서 세계적인 소프트웨어도 나올 수 있다.

그런 좋은 환경에서 배울 수 있는 기초 체력은 코딩도 아니고 Domain 지식도 아니다.

아래와 같은 것들이다.

• 소프트웨어 개발에 있어서의 개방의 문화
• 리뷰 문화
• 공유 문화
• 협업 문화
• 신뢰의 문화
• 효율적인 개발 프로세스
• 소스코드 관리 기법
• 이슈 관리 기법
• 빌드/릴리즈 기법
• 테스트

이런 것들이 몸에 베어 있어야 한다. 몸에 베이지 않고 지식으로만 알고 있는 것은 막상 시행하려고 할 때 제대로 실행하기 어렵다. 엉뚱한 방향으로 흘러가서 이상하게 되어 버린다.

또 기초 체력에 해당하는 것들은 비싼 툴을 쓰고 정교한 세계 최고의 방법론, 프로세스를 도입한다고 해서 나아지지 않는다. 오히려 방해가 되는 경우가 많다.  그런 비싼 툴과 정교한 프로세스를 그것을 필요로 하는 곳이 따로 있는데 맞지도 않는 것을 쓰게 되면 반감만 커지게 된다.

툴은 꼭 필요하지만 환경에 맞게 필요한 툴과 적절한 프로세스가 필요한 것이다. 그 기반하에서 문화가 꾸준히 쌓이게 된다. 

이런 기초 체력이 뒷받침 되어야 다음과 같은 고급 역량이 생기기 마련이다.

• 분석 역량
• 설계 역량
• 기술 전략 수립

단어만 놓고 보면 우리도 다 하는데라고 생각할지 모른다.

이는 태권도 10급이 태권도 9단에게 나도 태권도 할 줄 안다고 하는 것과 비슷하다.

Global 하게 경쟁 좀 하려면 4,5단은 되어야 하는데 우리나라에서 유단자 찾기 어려운 이유가 기초 체력을 먼저 갖추기 어려운 환경에서 일하기 때문에 이런 고급 기술은 닦을 시간도 없고 방법도 모르기 때문이다.

그래서 내가 중요하게 생각하는 것이 개발 환경을 먼저 바꿔 놓는 것이다.

기본적으로 이슈관리시스템, 소스코드관리시스템만 제대로 사용해도 반쯤은 바뀐 것이다.

이런 시스템들을 쓰면 우리가 눈치 채지 못하지만 여러가지 원칙, 프로세스를 저절로 배우게 된다. 수십년간 수많은 SW회사들의 성공하는 방법이 녹아 있는 것이 그런 시스템, 툴 들이다.

따라서 이들을 원칙 그대로 사용만 해도 많은 것을 얻게 된다. 기존의 방법과 다르다고 툴을 무시하고 또는 이상하게 변형하면 99.9% 잘못된 방향으로 가고 있는 것이다.

그리고 빌드, 테스트, 리뷰 등등을 하나씩 갖춰나가면 어느덧 꽤 효율적인 조직의 모습을 갖출 것이다.

이때 나타나는 조직의 모습은 다음과 같다.

• 회사의 모든 개발 이슈가 투명하게 Open 된다.
• 모든 업무의 커뮤니케이션이 원활하며 이런 것에 시간 낭비 하지 않는다.
• 모든 소스코드는 공개가 되어 있고, 협업이 원할하다.
• 숨어서 개발하는 개발자는 더이상 존재하지 않는다.
• 경영자와 관리자는 개발 진행 상황을 한눈에 파악하고, 각 개발자들의 업무 진행 상황을 쉽게 파악한다.

대부분은 이쯤에서 만족할 수 있을지도 모르겠다.

하지만 여기까지는 진짜 "기초 체력"이다.

국내 대회에서는 꽤 상위권에 오를 수 있다. 하지만 월드컵에 나가면 한 골 넣기도 어렵다.

이제 "고급 역량"이 필요할 때다.

분석/설계/기술전략 등의 "고급 역량"은 단기간에 배울 수도 없다. 그렇다고 혼자 방법과 길을 알아서 익힐 수도 없다. 그렇게는 너무나 오래 걸려서 은퇴할 때가 될 것이다.

"고급 역량"은 이미 "고급 역량"을 갖춘 선배, 동료들과 진짜 프로젝트를 수행하면서 몸으로 익히는 것이다.

어느정도 방법과 길을 아는데는 몇개월 안걸리지만 진짜 역량이 높아지는데는 5년, 10년이 걸리고 20년이 지나면 또 역량이 올라간다.

우리나라 많은 개발자들이 관리 쪽을 기웃거리다가 또 유지보수에 시달리다가 20년 쯤 지나면 이도 저도 아닌 상태와는 많이 다르다.

기초 체력을 익히는 첫걸음은 기초 체력이 부족하다는 것을 인정하는 것이다. 스스로를 인정하지 않으면 바뀔 수 없다. 이렇게 환경부터 하나씩 고쳐나가야 한다. 

프로토타입을 재활용하면 될까? 안될까?

며칠 전 프로토타입에 관해 올린 글에 대해서 프로토타입 재사용에 대해서 여러 의견이 있어서 이 내용에 대해서 조금더 설명해보려고 한다.

2011/11/03 - [프로젝트/요구사항분석] - 프로토타입이란?

소프트웨어공학의 목적은 가장 적은 비용으로 가장 빠른 시간에 Software를 만들어내는 것이다.
여기에 부합되면 옳은 방법인 것이다. 하지만 우물 안에서 자신의 방법이 가장 좋은 방법이라고 우기는 것은 미숙함일 뿐이다.

여러가지 의견이 있었지만 모두 옳고 그름으로 구분 지을 수는 없다. 여러 답변들을 맞다 틀리다 얘기를 할 수 없으므로 좀더 원칙에 치중해서 얘기를 해보겠다.

필자의 의견은 프로토타입은 만들어 보고 버리는 것이라고 했다. 또한 버리는 코드라고 생각하고 만들어야 하는 것이다. 프로토타입을 버리는 것이 프로젝트를 가장 빨리 끝낼 수 있는 방법이기 때문이다.

그 이유는 다음과 같은 것들이 있다.

• 프로토타입의 목적은 가장 빠른 시간내에 Feaserbility study(실현가능성 검증)을 하는 것이다. 보통 실제 프로젝트에 반영될 때 제대로 적히는 소스코드 양의 20%정도의 코드만 적는다. 
• 보통 에러처리와 약간의 버그는 무시한다.
• 검증된 것은 스펙에 기능으로 포함될 수 있고 이렇게 작성된 스펙을 외주를 줘서 개발할 수도 있고 회사의 다른 개발자들이 설계, 구현을 할 수도 있다.
• 이렇게 검증된 기능들은 모두 제품에 반영되는 것이 아니고 많은 기능은 최종 스펙에서 제외 될 수가 있다.
• 프로토타입은 C언어로 했지만 실제 개발은 Java로 할 수도 있다. 

따라서 재사용 가능하도록 만든다면 낭비가 될 수 있다.
보통 개발자들은 자신이 정성들여서 만들어 놓은 소스코들 버리기 싫어한다. 그래서 어떻게든 소스코드를 재활용해보고자 노력하는 것이 보통이다. 따라서 제품의 비전이나 가치와는 상관없이 자신이 작성해 놓은 코드의 기능을 살려보고자 마케팅의 의견과 반대되게 우겨서 제품에 기능을 포함하기도 한다.

제품의 스펙은 개발자가 일방적으로 정하는 것이 아니고 여러 부서가 같이 정하는 것이지만 특히 개발자보다는 마케팅의 의견이 주가 되는 것이다.

그런데 개발자가 미리 잘 작성해 놓은 코드가 이런 결정에 방해가 되는 경우가 많고 대부분의 소프트웨어 회사의 마케팅은 별 생각이 없기 때문에 그냥 따라가는 경우가 허다하다. 

그럼 프로토타입을 재사용한다는 생각을 하고 만들게 되는 상황은 어떠한가?
이러한 가정들을 사실로 생각하고 개발을 하는 것이다.

• 내가 스펙을 쓰고 설계를 하고 구현까지 모두 나 혼자 다한다.
• 프로토타입을 해본 것들은 제품에 모두 포함될 기능들이다.
• 프로토타입 해본 그 기능 그대로 제품에 반영될 것이다.
• 프로토타입을 해본 개발 언어 그대로 제품을 개발할 것이다.
• 프로토타입을 하기 전에 이미 아키텍처도 다 정해서 재 사용하는데 전혀 문제가 안된다.

 사실 아주 작은 제품이나 소수의 팀이 개발하는 제품이 아니라면 위의 모든 것을 가정하기는 대단히 어렵다.

스펙을 작성하는 과정에서 수많이 기능이 추가되고 제거되며 무슨 개발 언어로 개발을 할 것인지 보통 스펙을 작성할 때는 정하지도 않는다. 

어떠한 프로토타입은 개발언어를 정해야 하는 경우도 있고, 라이브러리도 정해야 하는 경우도 있다. 이런 경우라면 프로젝트에 또 제약사항이 생긴 것이다. 물론 프로젝트에 따라서는 스펙단계부터 개발언어와 특정 프레임워크를 사용하도록 정하는 경우도 있다.

스펙을 제대로 작성해야 하는 이유가 이러한 가능성이 있는 수많은 요소들과 제약사항, 가정들을 모아놓고 스펙을 정하는 것이다. 이런 것들을 정하지도 않고 코딩부터 시작하는 것이 흔히 개발하는 방식이다.

이런 프로젝트는 개발자 의지대로 그냥 개발이 되던가 나중에 뒤엎는라고 비용가 시간을 낭비하던가 제품이 점점 뒤죽박죽이 되어서 못써먹게 되는 경우가 많다.

프로토타입을 재활용할지 말지 하나의 이슈만 보면 원칙은 재활용하지 않는 것이 맞다.
하지만 위에서 말한 것들을 모두 알고 스펙도 제대로 쓰고 설계도 제대로 하고 개발을 하는데 재활용하는 것이 옳다고 생각한다면 프로토타입재사용도 틀린 방법은 아니다.

단, 적은 경험과 미숙함을 기반으로 기존에 하던 방식을 그냥 따라하는 것은 주먹구구의 연장선이 될 수 있다.

프로토타입이란?

프로토타입 (경제/경영)

양산(量産)에 앞서 제작해보는 원형(原型)을 '프로토타입'이라 하는데, 프로토타이핑이란 개발자들과 사용자들의 의사소통상의 효과를 증진시키기 위하여 취하는 시스템개발상의 기법이다. 일반적인 분석방법을 취할 경우 양자간에 서로 다른 이해를 가져올 수 있으므로 프로토타입이라는 의사소통도구를 만들자는 것이다. 프로토타이핑은 그 목적에 따라 여러가지 형태가 있다.

by 다음 백과사전 (http://100.daum.net)

소프트웨어 개발을 할 때 프로토타입은 여러 용도로 사용된다. 특히 고객과 스펙을 의논할 때 고객의 이해를 돕기 위해서 UI프로토타입을 만든다. 

이외에도 기술적인 검증을 위해서 프로토타입을 만들어 보는 경우도 있다.
스펙을 작성하다보면 이것이 가능할지 불가능할지 잘 모른 경우가 있다. 스펙이 이렇게 불분명한 부분이 가득하다면 십중팔구 프로젝트는 산으로 갈 것이다.
그래서 스펙을 쓰면서 나중에 코딩에 들어가기 전에 미리 한번 만들어보는 것이다. 이렇게 만드는 프로토타입은 되는지 안되는지만 검증을 하는 것이므로 최대한 간단하게 만든다.

회사의 코딩 규칙을 따르지도 않고
에러 처리도 제대로 하지 않고
주석도 달 필요가 없다.

제대로 개발하려면 1주일 이상 걸릴 것도 몇시간에 걸쳐서 되는지만 확인해보는 것이다.
그렇기 때문에 이때 작성한 소스코드는 버리는 것이다. 절대 재활용하면 안된다. 규칙도 따르지 않고 에러처리도 안되고 주석도 없는 코드를 재활용하는 것은 대단히 불안한 일이다.

이렇게 검증을 해나가면서 스펙을 적으면 프로젝트가 계획된 시간에 끝날 가능성이 점점 높아지게 된다.

그렇다고 모든 내용을 다 검증해가면서 스펙을 적을 수는 없다. 어떤 항목은 된다는 감을 믿고 그냥 적어야 할 때도 있다. 모든 것을 다 검증하면 비용과 시간이 너무 많이 들기 때문이다. 따라서 검증할 것을 적당히 조율하면서 어느정도 Risk도 감수를 하면서 프로젝트를 진행해야 한다. 이때 발생한 Risk는 별도의 Risk 관리를 통해서 제어를 해야 한다.

프로젝트는 "해봤더니 안되더라"가 아니다.
그렇다고 모든 것을 검증하면서 할 수는 더욱 없다.
적절한 프로토타입을 통한 검증과 적절한 Risk관리를 병행하는 것이 가장 효율적이다.

같이 일하려면 적어라.

"협업은 말로 하는 것이 아니라 문서로 하는 것이다."

동서고금을 막론하고 개발자들은 적는 것을 싫어하고 또 잘 적지 못한다.

우리나라 개발자들은 그 정도가 훨씬 심하다.

우리나라에서는 회사가 크던 작던 상관없이 대부분 5년, 10년 개발한 제품도 변변한 문서가 하나 없는 것이 현실이다. 이것만 보더라도 협업의 수준이 얼마나 낮은지 알 수 있다.

협업이란

1. 여러 사람들이 가지고 있는 지식과 경험의 도움을 받고
2. 서로 머리를 더해서 더 좋은 생각을 이끌어내 내고 
3. 일을 서로 나눠서 하는 것을 말한다.

이런 협업을 하는데 있어서 Template은 중요하지 않다. 협업이 필요한 내용이 공유를 할 수 있을 만큼만 적히면 된다. 적힌 것이 있어야 서로 공유를 하고 도움을 받을 수 있다. 만약 적히지 않고 머리 속에 있는 내용을 공유하려면 매번 말로 설명하는 수밖에 없다. 얼마나 피곤한 일인가. 또한 본인도 기억하지 못하는 사태가 벌어진다.
대표적으로 스펙과 설계는 협업이 매우 중요하다.
스펙과 설계를 제대로 적지 않고 리뷰를 하면서 계속 발전시켜나갈 수 없다. 한사람의 머리속으로 기억을 하면서 말로 공유를 하면 일을 서로 나눠서 개발하기도 어렵다.

하지만... 우리나라에서는 소프트웨어 개발을 할 때 변변한 문서도 없이 여러명이서 나눠서 개발을 잘도 한다. 물론 효율적으로 협업이 되지 않는다. 스펙과 설계가 불명확하여 개발자들이 코딩할 때 다 알아서 하고 나중에 통합도 잘 안된다. 스펙과 설계를 적기가 어려워서 최근에는 Agile 방법론이 인기를 끌고 있지만, 이것도 하나의 방법일 뿐이다. 

뭔가 적어야 할 때 Template을 꺼내놓고 틀에 맞춰서 적으려고 고민하기 보다는 서로 협의하고 확인을 받아야 하고 도움을 받아야 할 내용들을 적어서 수시로 리뷰를 하면서 진행을 해보라. Text 에디터로 Plain text로 적어도 아무 상관이 없다. 이렇게 효과적으로 적고 협업을 자주 하다보면 스펙과 설계를 어떻게 적어야 효과적으로 프로젝트가 진행이 될지 조금씸 감을 잡을 수 있을 것이다.

우리 식대로

"우리 식대로" 마치 북한에서 하는 얘기 같지만, "우리 식대로"를 주장하는 소프트웨어 회사는 의외로 많다.

 

체계가 하나도 없이 완전 주먹구구 방식의 소프트웨어 회사가 있는가 하면 "우리 식대로"를 주장하여 정말 많은 일을 해 놓은 회사도 있다. 

이 "우리 식대로"라는 것이 표준적이고 일반적인 방법과는 사뭇 달라서 어떻게 보면 기발하기도 한 것들을 많이 이룩해 놓은 경우가 있다.

 

소스코드 관리, 버그관리, 빌드, 분석, 설계, 테스트 등 전반에 걸쳐서 아주 독특하고 비효율적인 방법들은 너무나도 많이들 만들어 놓았다.

결론부터 말하면 주먹구구인 회사보다 "우리 식대로" 회사가 문제가 더 크다. 주먹구구인 회사는 백지와 같아서 하나씩 배워나가고 바꿔나가면 되는데, "우리 식대로" 회사는 바뀌기가 더욱 어렵다. 

"우리 식대로"는 충분한 경험과 통찰력 없이 나름대로의 방식으로 만들어 놓은 것들이라서 잘 적응해서 사용하고는 있지만, 효율이 높지도 않을 뿐더라 프로젝트의 규모가 커지거나, 개발 분야가 확대 되거나 Global한 Business를 할 때 꼭 문제가 발생한다.

 

이렇게 문제가 발생해도 "우리 식대로"에 익숙해진 사람들은

• 기존 방식이 익숙해져서
• 새로운 방식이 더 좋다고 믿을 수가 없어서
• 그 동안 투자한 것(Sunken cost)이 아까와서
• "우리 식대로"를 구축한 사람들이 정치적으로 방해해서
• 제대로된 새로운 방식 도입에 상당히 어려움을 겪게 된다.

그래서 나름대로 방식으로 뭘 해보려고 하면 나는 "하지 말라"고 한다. 소프트웨어를 개발하는 기본적인 원리와 체계는 대부분 표준적인 방법이 있고, 이를 먼저 익히고 경험한 후에야 "나름 대로 방식"으로 응용이 가능하다. 그러기 위해서는 남들은 또 외국에서는 어떻게 하는지 항상 관심을 가지고 있어야 한다. 

요상망측한 툴들을 만들어 놓고 뿌듯해 하지 말자. 나중에 발목 잡힌다.

문서는 얼마나 적어야 할지?

소프트웨어 개발 프로젝트에서 문서는 적게 적어야 한다.

다시 말하면 "보통의 회사에서는 문서는 필요한만큼만 가장 적게 적어야 한다."

물론 문서를 많이 적으면 여러 각도에서 상세히 적기 때문에 중복은 많이 발생하지만 잘못된 가능성을 충분히 줄여준다.

예를 들어서 스펙문서를 제대로 하나를 효과적으로 적으면 95%를 커버하는데 이를 99.9%까지 커버하도록 적으려면 10배의 비용을 더들여서 수십개의 문서를 만들어야 한다.

절대 문제가 생기면 안되는 원자력 발전소, 우주선, 생명유지장치는 이렇게 할 수도 있다. 실제로는 이런 경우도 다 그렇게 하는 것은 아니다.

문서를 아무리 많이 적어도 완벽을 기해야 하는 경우는 여러 문서를 적어야 하지만 보통의 SW 개발 프로젝트에서 이러한 경우는 거의 없다. 대부분의 SW 개발 프로젝트는 가장 적은 비용으로 가장 빨리 끝내야 한다. 그러기 위해서는 문서를 가장 적게 또한 효과적으로 적어야 한다.

아래에 문서를 만드는 4가지 경우가 있다.

• 문서 거의 없이 개발하는 경우 (쓸모 없는 문서, 개발중에 안보는 문서, 나중에 문서를 만드는 경우도 여기 해당) 
• 스펙문서를 포함해서 한두개의 문서를 효과적으로 적는 경우 
• 각 단계에서 수십개의 문서를 철저히 만드는 경우 (거대 방법론)
• 거대 방법론을 흉내 내지만 문서는 거의 안보는 경우. 문서따로 개발따로 (우리 주변에서 흔히 보는 경우)
• 최종 결과물만 거대 방법론 흉내내는 경우. 나중에 제출용으로 문서를 만든다. (이것도 친근하다)

이중에서 당연히 권하는 것은 1번이고 다음은 2번이다.
3,4,5번 보다는 차라리 2번이 낫다.

문서를 많이 적는 것은 중복이 많아지고 결국에 서로 Conflict가 나고 업데이트도 안되며 정작 개발시 거의 쓸모없어진다. 하지만 문서를 가장 효과적으로 적게 적는 것은 수십개의 문서를 적는 것보다 훨씬 더 어렵다.

일단 많이 적어보고 줄여나가는 것보다는 문서를 거의 적지 않는 경우라면 꼭 필요한 것부터 조금씩 늘려가는 것이 좋을 것이다.

SVN보다 Git가 더 좋을까?

요즘 SVN을 써야하나 Git를 써야하나? 또는 Mercurial을 써야하는 사람들이 많이 눈에 띈다.
또 누구는 아직도 ClearCase를 선호하고 Perforce가 좋다는 사람도 있고 혼란스럽기 그지 없다.
마치 골프를 치는데 골프채 뭐가 좋다고 서로 주장하는 것과도 같다. 아무리 좋은 골프채도 몸에 맞지 않으면 무용지물이다.

그럼 이런 애매한 것들을 깨끗하게 정의해 주겠다. ^^ 애정남 처럼

결론부터 말하면 다음과 같다.

1. 분산된 환경에서 일을 하는 경우가 잦다면 Git를 써라.
2. Github를 써야 한다면 Git를 써라.
3. 그외에는 모두 SVN을 써라.

기타 의견)
혼자 개발한다면 내키는 것을 써라.
회사에서 강제를 한다면 시키는대로 해라.
다른 툴에 완전히 익어서 바꾸기 싫으면 마음대로 해라.

기존에 VSS를 쓰던 사람들은 CVS를 써보면 신천지 였다. 

CVS를 쓰던 사람들에게 SVN은 놀라움 그 자체였다.

그럼 Git는 어떨까? 

일단 소스코드관리시스템에 대해서 좀 알 필요가 있다.

소스코드관리시스템은 크게 3종류로 나눌 수 있다.

• Folder공유 타입 - RCS, SCCS
• Client/Server 타입 - Subversion(SVN), CVS, Perforce, ClearCase, TFS
• 분산 저장소 타입 - Git, Mercurial, Bitkeeper, SVK, Darcs

폴더공유타입은 써보신 분이 있을지 모르겠지만 그래도 옛날에는 훌륭했다.C/S타입과 분산타입의 가장 큰 차이는 Repository가 중앙에 하나가 있나, 분산되어 여러개가 있나이다.

SVN과 Git는 1:1로 비교하기는 어렵다. 형태가 다르고 장단점이 있을 뿐이다.

물론 SVN을 가지고 하던 것은 Git로 거의 다 된다.

또한 SVN에서 안되던 것도 Git에서 되는 것도 많다.

그러면 Git가 SVN보다 좋은 것인가?

SVN에서 제공하지 않지만 Git에서 제공하는 기능이 꼭 필요한 경우라면 Git를 쓰는 것이 유리할 수 있다.

• Offline에서 자주 개발을 해야 할 때
• Git 기반의 Open source를 이용한 개발을 해야 할 때
• Git 기반의 Open source 프로젝트에 참여할 때
• Github을 써야 할 때

이런 경우가 아니라면 SVN을 쓰는 것도 좋다. SVN가지고 안되는 것이 있다거나 불편하다고 생각하는 사람들은 SVN의 막강한 기능을 극히 일부만 쓰고 있어서 그럴 수 있다.

Git는 기본적으로 SVN보다 복잡하다. Git는 명령어가 SVN보다 몇배 많다. 컨셉을 배우기도 복잡하다.

SVN을 쓰는 회사에서도 대부분의 개발자들은 SVN의 기능도 극히 일부만 쓰고 있다. 그런 상황에서 Git는 배우기 훨씬 어렵다. 따라서 Git 특유의 기능이 필요하지도 않는 상황이면 SVN이 더 낫다.

Git를 잘 모르고 쓰면 혼란이 가중될 수 있다. 소스코드 Conflict가 자주 일어날 수 있다.
공부도 훨씬 많이 해야 하며 전략을 잘 짜야 한다. 

물론 혼자서 또는 두세명이 개발을 하고 있다면 뭘 써도 별로 혼란스러울 것이 없지만, 수십명 또는 수백명의 개발자가 동시에 일하는 환경이라면 Git는 좀더 정교해야 한다.

Git는 브랜치 머지가 더 손쉽고 Local에서 일하는 것에 대한 자유도가 훨씬 높다. 하지만 이러한 장점들이 Git를 쉽게 쓸 수 있게 해주지는 않는다.

SVN과 Git는 누가 더 좋은 것이라고 비교하기 어려운 것이니 엄마가 좋아? 아빠가 좋아? 고민은 하지 말자. 

하지만 이 블로그를 읽은 정도의 개발자라면 개인적으로 SVN뿐만 아니라 Git에 대해서도 빠삭하게 알고 남들이 물어볼때 조언을 해 줄 정도는 되어야 할 것 같다. ^^

2020년 7월에 추가한 내용

이 글을 작성한지 9년이 지났다. 그래서 주변 환경이 많이 바뀐만큼 결정의 기준도 바뀌었다. 9년 전인 2011년에는 git를 쉽게 지원하는 client도 시원치 않았다. 하지만 지금까지 많은 기술의 변화가 있었다. 그래서 SVN을 쓸지 Git을 쓸지 결론을 말하지만 다음과 같다.

• 회사에서 이미 SVN을 쓰고 있어서 Git으로 마이그레이션이 어렵다면 SVN을 써라.
• 발주사에서 SVN을 써야 한다고 하면 SVN을 써라.
• 그외에는 모두 Git을 써라.
• 회사를 새로 시작한다면 Git을 써라.
• SVN을 쓰고 있어도 Git으로 마이그레이션을 하고 싶으면 해라.
• SVN에서 Git으로 바뀐다면 Repository 전략을 바꾸어야 한다.

추가 의견으로 Git을 쓴다면 Cloud 서비스를 이용하는 것을 권장한다. 서버를 직접 관리하는 것보다 시간, 비용면에서 효율적이다. Github, GitLab, Bitbucket, Azure Repos 등이 있다.

같은 조건이라면 Git을 사용하기를 권장하지만, SVN을 사용한다고 큰 문제가 있는 것이 아니다. SVN을 잘 쓰고 있다면 계속 사용해도 문제가 없고, 시간과 비용을 들여서 Git으로 옮겨가고 싶다면, 시도해볼만 하다.

SW개발자 블랙홀

중소기업, 심지어는 중견 기업들도 SW개발자를 뽑기 정말 힘들다.

신입은 물론 경력직도 구하기 어렵다.

몇년전부터 소프트웨어 경쟁력이 이슈화되면서 대기업들이 SW개발자들을 블랙홀처럼 빨아드리고 있는 것이 그 중요한 원인 중 하나이다.

이러한 현상은 비단 중소기업 뿐만 아니라 장기적으로 보면 SW생태계에도 좋은 영향을 끼치지 못하고 SW개발자들에게도 별 도움이 안된다.

그 이유는 대기업들이 SW 경쟁력 확중을 인원 확충과 같은 것으로 착각하고 있기 때문이다. 심지어는 중소기업 밥그릇을 뺏기 위해서 중소기업들이 주력하던 분야에 진출해서 관련된 개발자들을 데려가서 중소기업을 고사시켜서 시장을 뺏어 오기도 한다. 

중소기업, 중견기업을 다니는 많은 개발자들은 어려운 근무여건과 불안한 미래 때문에 대기업으로 옮기기를 선호하는 경향이 많다. 또한 대기업에 가면 체계적인 프로세스와 뛰어난 방법론 등 SW 개발에 대해서 뭔가 더 배울 수 있지 않을까 착각들을 한다.
하지만 막상 대기업으로 자리를 옮겨보면 자신들의 기대는 큰 착각이었다는 것을 깨닫곤 한다. 대부분의 대기업 SW조직은 작은 회사가 여러개 있는 것과 별반 다르지 않고 SW공학적인 능력은 중소기업보다 뒤쳐지는 경우도 많다. 

따라서 제대로된 소프트웨어 회사에서 10명이면 할 수 있는 일을 100명이 하는 경우도 있다. 이렇듯 대기업은 많은 개발자들을 빨아들이지만 개발자들을 효과적으로 활용하지도 못하고 개발자들의 역량을 제대로 키워주지도 못하고 있다. 그렇다고 딱히 다시 돌아갈 작고 좋은 SW회사들이 많지도 않다.
SW산업에 있어서 좋은 생태계는 다음과 같은 것이라고 생각한다.

좋은 토양에서는 대기업에서 체계적인 개발 방법을 배우고 좋은 아이디어가 생기면 창업을 하던지 작은 기업으로 옮겨서 자신의 생각을 펼쳐 보는 것다. 이 과정에서 대기업과 중소기업이 서로 협력하고 전체 파이를 키워야 서로 상생할 수 있다.

이 소스는 건들지마

소프트웨어를 개발하는 회사에서는 소스코드 관련해서 가끔 벌어지는 일들이다.
혹시 해당하는 것들이 있나 확인해보면 소스코드관리시스템을 제대로 쓰고 있나 가늠해 볼 수 있다.

• 이 소스코드는 건들지만 이번주 금요일에 릴리즈할 건데 지금 테스트 중이라서 건들면 헷갈리니까 잠시 건들지 말아줘
• 소스코드를 수정해서 등록하는데 Conflict가 났다. 원래 수정자를 찾아 같이 모여서 소스코드를 머지했다.
• 같은 소스코드를 서로 같이 동시에 수정하면 문제가 많으니 각 모듈마다 담당자를 따로 정해서 소스코드가 충돌하는 경우를 원천 봉쇄했다. 그래서 서로 다른 사람들의 소스코드를 잘 모른다.
• 하나의 소스코드를 가지고 오늘은 내가 내일은 다른 사람이 수정할 수 있도록 서로 일정을 조정했다.
• v1.0 출시 후 v1.0 유지보수와 v1.5로 업그레이드 하는 프로젝트가 동시에 진행하는데 서로 소스코드가 섞여서 소스코드 관리를 잘해야 한다.
• 위 경우 소스코드 충돌 때문에 소스코드 브랜치를 만들어서 따로 6개월간 개발을 했는데 나중에 v1.0의 수정본을 v1.5에 합치는데 워낙 많이 바뀌어서 거의 한달이나 걸렸다. 그 한달동안에 v1.0 소스코드는 또 많이 바뀌어서 Merge하고 테스트하는데 시간이 또 많이 걸렸다. 

위 경우에서 하나라도 해당하는 것이 있으면 문제가 있는 경우다.
기본적으로 거의 모든 소스코드 관리시스템은 위 같은 경우들에서 아주 효과적으로 관리를 할 수 있는 모든 기능이 제공되고 있다. 하지만 또 거의 모든 소프트웨어 회사에서 활용을 못하고 있거나 흉내만 내고 있다. 

그것은 바로 "Baseline"과 "3-way merge"이다.
이 개념을 정확하게 알고 이와 관련하여 제공하는 소스코드관리시스템의 기능을 정확하게 알고 있다면 다음과 같은 일들이 일어난다.

• 언제 릴리즈하는지는 상관없이 언제든지 소스코드를 수정할 수 있다. 
• 소스코드 Conflict가 일어나도 원래 수정자가 없이도 쉽게 Merge할 수 있다.
• 소스코드에서 여러 컴포넌트를 개발했던 원래 개발자는 있지만 서로 상대방의 컴포넌트를 수정할 수 있고 동시에 수정을 해서 충돌이 가끔 일어나지만 문제 없이 Merge가 된다.
• 소스코드를 누가 언제 수정하는지 전혀 신경 쓰지 않고 서로 동시에 수정을 할 수 있다.
• 유지보수 프로젝트와 업그레이드 프로젝트가 동시에 진행을 해도 Merge는 불과 몇시간이 걸리지 않고 대부분 자동으로 해결된다.

Subversion을 포함한 대부분의 소스코드관리시스템은 흔히 알고 있고 사용하는 기능보다 훨씬 막강한 기능을 가지고 있다. 수천명이 동시에 수십만개의 소스코드를 동시에 마구 고치고 여러 프로젝트가 동시에 진행되도 Merge에 따르는 고통없이 효율적으로 소스코드를 관리할 수 있다.

아직 그 기능을 충분히 활용하고 있지 않다면 좀더 소스코드관리시스템에 대해서 공부를 해 볼 필요가 있다. 물론 내가 쓴 "소프트웨어개발의 모든 것"이라는 책에는 그 원리와 방법이 꽤 자세히 나와 있으니 참고가 될 수 있을 것이다.

주석을 달기 어려운 이유

코딩을 하면서 주석을 적절히 잘 달아야 한다는데는 이견이 없을 것이다. 하지만 현실은 주석이 제대로 달린 코드를 찾아보기 어렵다.

"주석이 제대로 달렸다"의 애매한 기준을 명확하게 정리해보면 다음과 같습니다.

• 과도한 주석은 나쁘다. 비용이 너무 많이 들어간다.
• 소스코드를 활용하고 유지보수하는데 어려움이 없어야 한다.
• 업데이트가 되어서 소스코드와 일치되어야 한다. 
• 전체적으로 일관된 표준을 지켜야 한다.  

주석하나 없이 깨끗한 소스코드나 있어도 소용없는 주석은 개발에 보통 어려움이 있는 것이 아니다. 약간의 시간을 투자해서 주석을 달게 되면 투자대비 몇배의 효과를 볼 수 있다.

그럼 가장 효과적으로 주석을 다는 방법에 대해서 알아보자.

회사의 주석 표준을 정한다.

Doxygen이나 Javadoc등의 표준 주석 Notation을 따르면 여러 툴의 많은 도움을 받을 수 있고 가독성이 높아진다. 신입사원이 들어와도 널리 알려진 표준이므로 쉽게 따라할 수 있게 된다.

주석은 소스코드보다 먼저다.

주석은 코딩하면서 짬짬히 다는 것이 아니다. 코딩 이전에 설계 시 Public function을 정의하면서 주석을 먼저 작성한다. 이렇게 설계를 해서 완벽할 때 구현(코딩)에 들어가면 된다.
코딩을 하면서 Public interface가 자주 바뀌면 주석도 바꾸기 매우 귀찮아지게 된다.
하위 설계는 코드와 주석을 적당히 이용하게 되면 문서로 작성할 필요가 없이 대부분 소스코드로 작성할 수 있다.

Public function 위주로 주석을 단다.

모든 소스코드에 주석을 달아야 한다고 하면 헬스클럽 1년 끊어 놓고 일주일 운동하고 포기하는 사태가 발생하게 된다. 당장 바쁜데 언제 시간을 내서 주석을 달 수 있겠는가? 
Public function은 다른 개발자들이 가장 빈번하게 참조를 해야 할 함수들이다. 같은 시간에 주석을 달아서 가장 효율성이 높다. 
하지만 모든 함수가 Public function이라면 효과도 없고 프로그램은 뒤죽박죽이 된다. 미리 Public function을 정하게 되면 최소화를 할 수 있다. 가능하면 거의 모든 함수를 속으로 숨기고 밖으로 최소한의 Interface만 open할 경우 프로그램도 간결하게 되고 유지보수도 쉬워진다. 
Doxygen이나 JavaDoc을 이용하면 API 메뉴얼이 근사하게 나오게 된다. 이 문서만 봐도 개발자들이 개발하는데 대단히 큰 도움을 준다.
이는 소스코드와 주석/설계문서를 지속적으로 일치 시키는데 지대한 도움을 준다.

주석같은 소스코드가 좋다.

복잡한 소스코드를 작성하고 주석으로 설명하는 것보다는 약간 효율이 떨어져도 가독성 높게 소스코드를 풀어서 쓰는 것이 좋다. 따라서 함수의 크기는 작게 유지하면서 읽어 내려가기 쉽게 작성하는 것이 좋다.
성능에 목숨거는 알고리즘을 개발하는 것이 아니라면 가독성 높은 소스코드를 작성하는 것을 높은 우선순위로 두는 것이 좋다. 왜냐하면 소스코드는 개발비보다 유지보수비가 몇배 더 들기 때문이다.

Prototyping 시에는 주석이 필요없다.

Prototyping한 소스코드는 버려야 한다. Prototype은 주석도 없고 에러처리도 안하고 가장 빠르게 검증을 해보는 것이다. 제품화 할 코드는 이것보다 몇배의 시간이 더 걸린다. 따라서 Prototyping을 한 소스코드는 꼭 버리고 제대로 설계를 해서 다시 만들어야 한다. 단, 참조는 가능하다.

처음에는 강제화가 필요하다.

강제화를 위해서는 리뷰가 필수이다. 코드 리뷰보다는 설계 리뷰가 중요하다. 설계 단계에서 대부분의 Public interface의 주석을 미리 완성하고 코딩에 들어가면 협업도 원활하고 재작업도 줄어든다. 그리고나서 코딩단계에서의 주석은 크게 강조하지 않아도 될 것이다.
규칙으로 무조건 주석을 달라고 강제하는 것보다는 정공법으로 분석/설계 리뷰를 통해서 설계가 끝났을 때 주석이 이미 달린 소스코드 헤더가 나오는 것이 좋다.


무조건 코딩부터 달려드는 것보다는 한번 더 생각해보고 Public interface를 먼저 정의하고 주석을 작성해서 리뷰하고 코딩을 하는 것이 전체 개발시간을 현저하게 단축 시켜준다. 시간이 없어서 주석도 없는 코딩만 마구 해대는 것은 핑계에 불과하다. 

효과적으로 주석을 다는 습관을 가지고 있다면 여러 동료들에게 사랑을 받고 후배들의 존경을 받을 것이다.