All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.
RSS Feed
오늘 출근을 해서 메일을 확인하니 독자로부터 메일이 한통 와있더군요.
책에 대한 리뷰의 글이어서 감사히 읽었습니다. 질문도 하나 있어서 답변 겸 블로그에 글을 남깁니다.
질문은 다음과 같습니다.
| 나는 마이크로소프트 같은 커다랗고 프로세스가 잘 정립된 회사의 형상 관리툴의 소스트리를 보고 싶다.
그들이 모듈을 어떤 식으로 분리하고 어떤 구조로 트리를 구성하는지, 중복되는 코드들을 어떤 식으로 제거하고 또 공유하는지, 체크인 되는 코드의 코멘팅은 어떤 규칙으로 하는지 등이 너무 너무 궁금하다. 1시간 만이라도 들어가서 차근차근 살펴볼 수 있다면 내 실력은 훨씬 나아질 것이다. |
사실 책에서는 이러한 내용은 구체적으로 설명되어 있지는 않지만 전체 맥락을 이해하고 경험이 있다면 질문에 해당하는 내용이 책에 포함 되어 있다는 것을 알 수 있을 겁니다.
결론부터 먼저 말씀드리자면 최종 결과물인 "소스코드 트리"만 보면 배우기 어렵다는 겁니다. 잘 작성된 SRS를 몇개 보고 SRS를 제대로 작성하는 법을 배우기 어려운 것과 비슷합니다. 따라서 소스코드 트리를 보는 것이 큰 도움이 안된다는 것을 말씀드립니다. 하나의 사례를 보는 것에 족할 겁니다. 자칫 그 방법이 가장 좋은 방법인 줄로 착각을 하게 되면 시각이 굳어져서 손해를 볼 수도 있습니다.
좀더 쉽게 설명하면 타이거우즈(요즘 조금 부진하지만)가 골프치는 모습을 보고 골프를 배우기는 어렵고, 김연아가 스케이트 타는 것을 보고 따라하기 어렵다는 겁니다. 어떻게 해서 이러한 결과물이 나오는지 그 과정과 훈련 방법을 알아야 하겠지요.
그런 과정에 관련된 내용이 책에서 상당히 많이 언급하려고 노력했습니다.
그 과정이라는 것도 각자의 수준에 따라서 보이는 것이 다릅니다. 수준을 1~10정도로 정의할 때 수준이 '1'인 사람은 아무리 설명해도 '2'나 '3'의 내용만 이해가 가능합니다. 수준이 '5'인 사람은 '6'이나 '7'정도가 이해할 수 있습니다. 그래서 올바른 방법으로 꾸준히 차근차근 훈련(경험)을 해 나가야 성장합니다.
그외의 끝내주는 방법은 없습니다.
위 질문의 요지를 보면 다음과 같습니다.
- 모듈을 어떤식으로 분리하는지?
- 소스트리를 어떻게 구성하는지?
- 중복되는 소스코드를 어떻게 제거하는지?
- 공통모듈은 어떻게 공유하는지?
- 코멘트는 어떤 규칙으로 작성하는지?
결론부터 말씀드리면 다음과 같습니다.
| 구체적인 방법은 회사마다 다르지만 원리는 똑같다. |
이것을 모두 이해하려면 1~10 정도의 수준에서 '7'~'8' 이상은 되어서 합니다. 그렇지 않고 아직 소스코드관리시스템의 일부기능만 간신히 쓰고 있고 SRS도 아직 제대로 작성하지 않고 있고 리뷰도 하지 않고 있다면
수천명의 개발자들이 어떻게 뒤죽박죽 되지 않고 소프트웨어를 개발할 수 있는지 이해가 가지 않을 겁니다.
그게 소프트웨어 공학입니다. 어떠한 상황에서도 가장 짧은 시간에 적은 비용으로 소프트웨어를 개발하기 위한 실전적인 방법으로 진화를 해온 것입니다.
조금더 구체적으로 들어가보도록 하겠습니다. 모든 사람들이 이해를 하고 동의할 것으로 생각하지 않습니다. 왜냐하면 각자의 경험과 수준이 있기 때문에 보이는 것이 다르기 때문입니다.
1. 모듈은 어떤 식으로 분리를 하는지?
천차만별이지만 원리는 있습니다. 책에서도 원리에 대해서 설명하기 위해서 노력을 했습니다.
책이 있으니 한번 더 보시면 되겠지만 한번더 설명을 하면 "컴포넌트"와 "인터페이스"를 어떻게 나누느냐가 핵심인데, 어떤 툴이나 방법을 쓰냐는 중요하지 않습니다. 생각하는 방법도 서로 다르지만 대체로 설계단계에서 개발자들끼리 서로 모여서 종이나 칠판에 "컴포넌트"와 "인터페이스"를 그려가며 가장 깨끗하게 나오는 구조를 그려갑니다. 문제가 있으면 다시 지우고 그리고를 여러번 반복합니다.
이때 SRS가 없다면 모든 기능을 다 고려할 수 없기 때문에 제대로 아키텍쳐를 작성할 수 없습니다. SRS가 그냥 있기만 한다고 되는 것도 아니고 제대로 작성이 되어야죠. 아키텍쳐에는 회사의 미래전략도 모두 포함되기 때문에 단순히 기능만 다 있다고 되는 것도 아닙니다. SRS이슈로 넘어가면 또 하루 종일 설명을 해야 합니다.
아키텍쳐에 많은 영향을 미치는 사람들은 주로 선임 개발자들이고 개발팀 규모가 엄청나게 크면 한사람이 전체 모든 컴포넌트와 인터페이스를 분리할 수 없기 때문에 수직적으로 나뉘게 됩니다. 개발자들은 서로 여러 설계 리뷰에 참석을 하게 되고 리뷰자들은 서로 중첩이 됩니다. 선임개발자들은 최상위 아키텍쳐 리뷰에 참석도 하고 자신이 맡은 컴포넌트의 아키텍쳐 회의를 주도하고 여기에는 하위 개발자들도 참석을 합니다.
아키텍쳐 리뷰도 실제로 여러번 해보지 않으면 책을 아무리 봐도 어떻게 진행하는지 알기 어렵습니다.
2. 소스트리를 어떻게 구성하는지?
이 부분이야 말로 회사마다 천차만별입니다. 회사마다 제품의 특성이 다르고 프로세스가 다르기 때문에 같을 수가 없습니다. 소스트리를 구성할 때 고려해야 할 것들은 정말로 많고, 그 회사의 경험이 많은 고참 개발자가 아니면 좋은 결정을 할 수가 없습니다.
소스트리는 한번 제대로 구성을 해놓으면 10년이상 지속될 수 있는 것이기 때문에 상당히 신중해야 합니다.
제품의 성격, 각 제품간의 관계, 사용하는 개발언어, 공통모듈 현황, 미래의 개발계획, 빌드 프로세스, 테스트 프로세스 등이 모두 고려되어야 합니다.
일반적으로 한번에 제대로된 소스트리를 만드는 것은 거의 불가능에 가깝습니다. 대부분은 몇년 해보다가 뒤엎는 경우를 수차례 반복합니다.
그렇다고 Google이나 Microsoft의 소스트리를 흉내낸다고 제대로 되지는 않습니다. 아마 100% 실패할 것입니다.
3. 중복되는 소스코드를 어떻게 제거하는지?
완벽한 제거란 있을 수 없습니다. 최소화 하는 것이지요. 이것을 이해하려면 SRS, Architecture Design, Peer Review를 모두 잘 이해하고 있어야 하는데 쉽지 않습니다.
우리나라와 같이 각 개발자들이 모두 슈퍼맨에 되어서 알아서 개발하는 구조에서는 해결이 불가능한 이슈입니다.
책에서도 꽤 설명을 하고 있지만 다시 설명을 해보겠습니다. Peer Review를 한다고 가정을 하고 SRS, Architecture, Source Code 모두를 Review한다고 가정을 해보죠. 일단 Review를 충분히 한다는 것이 중요합니다. 개발자들은 이미 상당히 많은 내용을 서로 공유하고 있습니다. 보통 개발하는 시간의 20%는 Review를 위해 사용한다고 합니다. 그리고 고참이 될 수록 더 많은 시간을 Review에 할애 합니다.
대부분은 개발할 시간도 없는데 언제 Review를 할 시간이 있냐고 합니다. 또한 "SRS는 언제 쓰고 있느냐, 빨리 개발해야지"라고 주장합니다. 그러면 "SRS쓰고 Review할 시간은 없어도, 개발하고 고치고, 개발하고 또 고치고 할 시간은 있느냐?"라고 반문을 하죠.
Review를 적절하게 하는 것이 개발을 가장 빨리 하는 방법이기 때문에 소프트웨어공학에서 주장하는 것이지요.
이런 리뷰를 거친 설계과정에서 중복되는 모듈은 컴포넌트로 빠지고 코딩과정에서도 서로 중첩된 리뷰를 하기 때문에 중복된 코드가 발생할 가능성도 적어지고 있다고 하더라도 쉽게 발견되고 공통 모듈화 할 수 있습니다.
4.공통모듈은 어떻게 공유하는지?
이또한 회사마다 다릅니다. 하지만 공통모듈이 없는 회사를 본적이 있습니다. 아니 많습니다. 각 개발자들이 다 알아서 개발을 하고 있어서 어디에 중복된 모듈이 있는지 알지도 못합니다.
공통모듈은 분석, 설계 과정을 통해서 잘 분리가 되어야 하고 당연히 이를 담당한 개발자나 개발팀이 별도로 존재합니다. 공통모듈이 이를 사용하는 개발자나 개발팀에서 잘 사용할 수 있도록 적절한 프로세스를 갖추고 있어야 합니다. 공통모듈은 소스코드 수준에서 공유하는 회사도 있고, Static library 또는 Dynamic library형태로 공유하기도 합니다. 그에 따른 적절한 공통모듈 Release프로세스를 가지고 있어야 하며 절적한 스케쥴도 유지를 해야 합니다.
회사의 공통모듈은 한개가 아닙니다. 수십개, 수백개가 될 수도 있습니다.
컴포넌트간의 공통모듈이 있고, 제품간의 공통모듈이 있고, 회사 전체 공통모듈이 있을 수 있습니다. 공통모듈은 소스코드가 될 수도 있고, Text파일일 수도 있고, 이미지파일일 수도 있습니다.
이런 공톰모듈을 적절하게 잘 사용할 수 있는 소스트리 구성이 중요합니다. 따라서 최고의 고참이 아니면 소스트리 구성이 어렵습니다.
5.코멘트는 어떤 규칙으로 작성하는지?
이부분도 회사마다 다르지만 규칙은 있다는 겁니다.
아무것도 제대로 갖춰지지 않은 회사에서 코멘트는 정말 중요합니다. 달랑 소스코드 하나 있는 것이기 때문에 코멘트가 없으면 소스코드를 파악하기 정말 어렵습니다. 특히 해당 개발자가 퇴사를 하고나면 정말로 난감합니다.
하지만 제대로 된 소프트웨어 회사에서는 모든 것이 서로 얽혀 있고 정보들이 서로 중첩되어 있어서 코멘트만이 유일한 정보는 아닙니다. 모든 소스코드의 History는 소스코드관리시스템에 등록이 되어 있어서 Blame을 해보면 누가 언제 등록을 한 소스코드이고 해당하는 Message와 관련된 Issue의 번호를 가져올 수 잇습니다. 그리고 왠만한 소스코드는 서로 중복되어서 리뷰가 되었고, 소스코드관리시스템에 누가 리뷰를 했는지 기록이 되어 있습니다.
즉, SRS - Architecture - SCCM - Issue Track - Source Code - Brain(뇌, 리뷰) 들이 서로 관련이 있고 얽혀 있어서 코멘트에 목숨거는 상황은 아니게 됩니다.
그래도 코멘트는 작성을 하고 규칙은 각 회사마다 별도로 가지고 있어야 합니다.
우리나라 같은 경우 영어로 작성을 해야 하는지 한글로 작성을 해야 하는지 정해야 하고, 파일주석, 함수주석, 라인 주석에 대한 규칙을 정해야 하고, 내용, 형식에 대해서도 정의를 해야 합니다.
하지만 너무 복잡한 규칙과 지키기 어려운 엄격한 규칙은 없느니만 못하기 때문에 적절히 규칙을 정해야 합니다.
위의 모든 것을 한꺼번에 할 수는 없습니다. 회사의 규모에 따라서 3~5년 이상 걸릴 것들도 있습니다. 결코 계단 10개를 한걸음에 뛰어오를 수는 없습니다. 용어만 알고 있거나 한번씩 경험해 봤다고 아는 척해서도 안됩니다. 회사 전체가 같이 움직일 수 있어야 합니다. 현실은 많은 의욕이 넘치는 개발자들이 머리속의 지식과 이상은 level 10인데 실제 실력과 경험은 level 2에서 헤매고 있는 겁니다. 그래도 다른 개발자들보다 용어도 많이 알고 말싸움에서 이기고 잘 안되는 것은 다른 사람들 탓을 하곤 합니다. 이것이 제가 여러 현장에서 겪는 현실입니다.
차근 차근 노력해 가는 것이 올바른 방법이고 전문가의 도움을 통해서 제대로 된 길로 가장 빠르게 가는 것이 유일한 방법입니다.
전규현
기반시스템/소스코드관리
SRS,
소스코드관리시스템,
소스코드트리,
소스트리,
피어리뷰
전규현님 덕분에 개발에있어 다른 시각으로 접근하는 시야를 갖게되었습니다 감사합니다.
svn사용이익숙해지면 Git도 한번 사용해봐야겠네요
오산돌구님 안녕하세요.
그렇게 생각해주시니 고맙습니다. 개발자분들이 좀더 좋은 환경에서 일하게 되는 것이 제 바람입니다.
안녕하세요. rss추가 해놓고 맨날 눈팅 하던중 주옥 같은 글을 발견 하였네요.
감사합니다. ^^
안녕하세요. 이승철님
반갑습니다.
음.. 문득 다른분들은 svn 서버를 어떻게 구성해서 사용하는지가 궁금해지네요
http / https / svn / svn+ssh 이런 여러가지 설정방법이 있다 보니 말이죠 ^^;
안녕하세요. 구차니님
SVN 서버를 구성하는 방법은 간단하기도 하지만, 제대로 하려면 매우 복잡합니다.
1. 말씀하신 것과 같이 Protocol을 정해야 합니다.
2. Repository를 어떻게 나눌 것인지 정해야 합니다.
3. Repository 내의 디렉터리를 어떻게 구축해야 하는지 정해야 합니다.
4. 각 Repository내의 디렉터리에서 권한을 어떻게 부여해야 할지 정해야 합니다.
이 중에서 가장 어려운 것이 2,3번입니다. 특히 3번은 잘못 구축하는 경우가 태반이고, 한번 잘못 구축하면 다시 복구하는 것은 대단히 어렵습니다.
디렉터리의 구조는 빌드 스크립트와 연관이 있어서 다시 고치는데는 대단히 노력과 비용이 듭니다.
디렉터리 구조는 회사마다 다르며 잘못 구축하면 비효율성이 계속되며 비용을 지불해야 합니다.
제대로 디렉터리를 구축하려면 SVN의 사용방법도 제대로 알아야 하고 회사의 미래 개발 전략도 어느정도 이해를 해야 가능합니다.
이중에서 1번인 프로토콜은 꽤 쉬운 편입니다. 왜냐하면 나중에 요구사항이 바뀌면 바꾸기가 쉽기 때문입니다.
SVN은 기본적으로 자체서버에서 svn://을 지원합니다. 그리고 웹서버와 연동해서 http:// https://를 지원합니다.
그리고 ssh에 svn을 얹어서 쓸 수도 있습니다.
웹브라우저로 보기도 원하는지? 철저한 보안을 원하는지? 편리하고 간단하게 쓰고 싶은지? 속도가 매우 중요한지?에 따라서 정하면 됩니다.
저도 개인 피씨에 보관하던 사람이었죠 ㅎㅎ
블로그 글 덕분에 버전 시스템을 알게 되었고, 설치하여 프로젝트에 많은 도움이 되고 있습니다.
하지만, 스포츠에 비유한다면, 이제 겨우 기초 체력을 갖추기 시작한 거라 해야 할까요
진짜 경쟁은 지금부터겠죠
여하튼 앞으로도 좋은 글 많이 부탁 드립니다.
안녕하세요. csj님
맞습니다. 기본적인 시스템을 갖추지 않고 개발을 하는 것은 사냥을 맨몸으로 하는 것과 같습니다. 창이나 활, 총을 갖춰야죠.
이제 무기는 생겼습니다. 무기를 갖추는 것은 시간이 얼마 안걸립니다. 하지만 무기를 잘 쓰는데는 시간이 좀 걸립니다.
또한 사냥을 더 잘하려면 무기를 잘 쓰는 방법 뿐만 아니라 자연을 이해야 하고 동물의 습성등 다른 기술들도 필요하고 팀웍도 필요합니다.
이제 기초를 갖추신 겁니다. 비록 요소기술이 뛰어나다고 해도 소프트웨어 공학에서 다루는 프로세스, 툴, 분석, 리뷰, 설계 등의 실력을 갖추지 않으면 소프트웨어를 개발하기가 점점 어려워 집니다.
앞으로 좋은 정보를 많이 공유하도록 하죠.
전규현님 안녕하세요. 이번주에 git에 대해서 팀내 발표를 하게 되었습니다.
제가 어떻게 하는지에 따라서 팀내 적용을 할지 말지 정하는 상황입니다.
현재 팀내 분위기는 git을 사용하기 위해 배우는 비용과 git 사용함으로써 생기는 이득을 따져서 적용해보자~ 하는분위기입니다.
근데 한가지 문제점은 제가 git이나 svn을 사용하는데 저 혼자만 사용해서 여럿이 사용할때의 이점을 제대로 깨닫지 못한 상태입니다. 그저이론적으로만 알고있죠. . .
사용하면서 어떤 예로 이득을 보는지 알고싶습니다. 아직 처음 단계라 경험이 부족해이런 질문 드린거 죄송합니다;;
오산돌구님 안녕하세요.
제가 쓴 "소프트웨어 개발의 모든 것"의 개정판에 중앙집중식SCM과 분산SCM의 비교가 있으니 참조하시면 좋을 것 같습니다.
특별히 분산 관리의 목적이 아니라면 SVN이 더 관리하기 편합니다.
서로 연동도 되니 필요에 따라서 연동해서 사용하는 방법도 있습니다.