태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

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

2011.02.01 11:39 by 전규현


잠시 후 Google blogger로 이동됩니다.






여러 소프트웨어 회사를 분석해보면 소스코드를 공유하는 정도에서 정말 많은 차이가 난다.
여기서 소프트웨어 회사란 소프트웨어를 개발하고 있는 회사로서 흔히 얘기하는 팩키지 소프트웨어 회사가 아니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

공유문화가 정착되지 않은 회사이다. 이런 회사에서 코드리뷰는 별 의미도 없다. 
시도를 해봤자 시간 낭비일 것이다. 내용을 모르는데 코드리뷰를 해도 기껏해야 Syntax 검사밖에 못할 것이다.
SRS리뷰를 먼저 시작하는 것이 좋다. SRS가 리뷰를 해야 할 것도 더 많고 SRS가 제대로 작성되어야 다음 단계인 설계, 구현이 제대로 진행되며 리뷰를 해도 내용을 알고 리뷰를 할 수 있게 된다.

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

 결론

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

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

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

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

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image by Susan NYC

저작자 표시 비영리 변경 금지
신고

전규현 개발문화 SRS, 공유, 리뷰

  1. 비슷한 얘기가 생각나네요. 두 청년이 바둑의 명인이 되기위해 산으로 가서 바둑에만 전념한지 10년째, 자신감에 찬 두 청년은 산을 내려와서 다른사람들과의 대전을했는데, 매번 졌다는 얘기에요;;

    여쭙고 싶은게, 포스팅에 대부분 SRS을 강조하셔서 제 나름대로 개발진행하면서 기능과 이렇게 개발한 이유같은걸 문서로 만듭니다. 근데 혼자하다보니 이게 과연 잘 진행되는건지 의심이 가는건 어쩔수없네요.

    SRS 세미나 혹은 교육같은게 있나요? SRS의 개념을 익히고싶습니다.
    새해복 많이받으세요~

  2. 오산돌구님 안녕하세요.

    개발하면서 기능과 그 이유를 적는다고 한 것으로 봐서 문서를 개발하고 나서 적는 다는 의미 같습니다.

    문서는 원래 개발을 하기 위해서 더 빨리 개발하기 위해서 만드는 것입니다. 지금은 문서가 나중에 필요할 것 같아서 만드시는 거죠? 이런 문서는 용도가 많이 떨어집니다.

    SRS세미나나 교육이 있기는 하지만 SRS를 익히려면 직접 SRS를 직접 쓰고 프로젝트를 진행해 보는 것을 몇년 해봐야 합니다. 그러기 위해서 처음에는 좀 배워야 하는 과정이 필요합니다.

    제 책에 보면 SRS를 배우는 방법에 대해서도 소개가 되어 있습니다.

  3. Blog Icon
    bluemonk

    책을 읽어봤는데 그렇게 하면 되겠구나 라고 하는 느낌까지는 들지 않았습니다.

  4. 안녕하세요. bluemonk님

    그것이 책의 한계인 것 같습니다. 비디오 보고 골프를 배울 수 없듯이 직접 해보면서 경험하지 않으면 알 수 없는 것이 소프트웨어 공학입니다.

  5. Blog Icon
    별의파편

    지금은 좀 덜 하지만 저 같은 경우는 몰래 고치는 게 재미있어서 그런 적도 많아요. 새로운 패턴이나 프레임워크 보면 이전 소스를 고쳐보고 싶은...
    좋게 말하면 리팩토링인데 사실 코드 갖고 놀기....회사 자산 갖고....ㅡ.ㅡ;

  6. 안녕하세요. 별의파편님
    작은 회사에서는 흔히 있는 일이죠.
    회사의 소스코드의 아키텍쳐를 바꾸는 일이라면 여러 개발자와 리뷰를 많이 하면서 더 좋은 방법들을 계속 찾는 작업이 필요할 겁니다.
    소스코드가 변경되면 테스트가 많이 필요하고 코딩 작업 외에도 많은 작업이 필요합니다. 따라서 개인이 혼자서 마음대로 변경하는 것은 나중에 문제가 될 수도 있습니다.
    작은 회사 또는 작은 팀이라서 가능한 걸 겁니다.

  7. SRS가 뭔가요?

  8. 안녕하세요. 중원님
    스펙문서를 말합니다. 제 블로그에서 SRS로 검색을 해보시며 많이 나옵니다.

  9. Blog Icon

    비밀댓글입니다

  10. 감사합니다. ^^

  11. Blog Icon
    ymir

    협업에 관련된 포스트를 읽다가 이 포스트로 넘어왔네요.
    소스를 팀의 산출물로 협업을 통해 관리하는 경우에는 생각보다 투명하게 일이 진행됩니다.
    그러나 중소규모의 회사일수록 그런 경우는 많지 않으며..
    오히려 소수의 인원이 거대 모듈들을 작업하는 경우가 많고, 협업을 하는 케이스가 적습니다.
    그러다 보니.. 소스에 대한 관리 책임이 순전히 개인에게 넘어가버립니다.
    이런 경우 버그가 발생하면 결국 개인의 능력과 실력을 의심당하게 되고..
    회사에 피해를 끼치는 식으로 인식되어 버립니다.
    소위 욕먹고 깨지고 페이에도 문제가 생길수 밖에 없는 구조가 되어 버리죠.
    결국은 책임 회피를 위한 나몰라, 거짓말, 몰래 체크인, 다른 이의 계정으로 체크인 등...
    시스템과 프로세스를 무력화 시킬 수 있는 온갖 방법들이 동원되기도 합니다.
    코드를 대하는 마인드가 변하지 않는 한, 소위 이 '나쁜 습관'들은 쉽게 고쳐지지 않을 것 같습니다.

  12. 안녕하세요. ymir님
    다른 사람 계정으로 체크인은 좀 심하네요. ^^

  13. Blog Icon
    ymir

    다행(?)히도 그런 사례는 서너개의 회사를 거치는 동안 딱 한 번 봤습니다. =)

마이크로소프트, 구글의 소스코드 트리의 비밀?

2010.06.08 11:02 by 전규현


잠시 후 Google blogger로 이동됩니다.






오늘 출근을 해서 메일을 확인하니 독자로부터 메일이 한통 와있더군요.

책에 대한 리뷰의 글이어서 감사히 읽었습니다. 질문도 하나 있어서 답변 겸 블로그에 글을 남깁니다.

질문은 다음과 같습니다.
나는 마이크로소프트 같은 커다랗고 프로세스가 잘 정립된 회사의 형상 관리툴의 소스트리를 보고 싶다. 그들이 모듈을 어떤 식으로 분리하고 어떤 구조로 트리를 구성하는지, 중복되는 코드들을 어떤 식으로 제거하고 또 공유하는지, 체크인 되는 코드의 코멘팅은 어떤 규칙으로 하는지 등이 너무 너무 궁금하다. 1시간 만이라도 들어가서 차근차근 살펴볼 수 있다면 내 실력은 훨씬 나아질 것이다.

사실 책에서는 이러한 내용은 구체적으로 설명되어 있지는 않지만 전체 맥락을 이해하고 경험이 있다면 질문에 해당하는 내용이 책에 포함 되어 있다는 것을 알 수 있을 겁니다. 

결론부터 먼저 말씀드리자면 최종 결과물인 "소스코드 트리"만 보면 배우기 어렵다는 겁니다. 잘 작성된 SRS를 몇개 보고 SRS를 제대로 작성하는 법을 배우기 어려운 것과 비슷합니다. 따라서 소스코드 트리를 보는 것이 큰 도움이 안된다는 것을 말씀드립니다. 하나의 사례를 보는 것에 족할 겁니다. 자칫 그 방법이 가장 좋은 방법인 줄로 착각을 하게 되면 시각이 굳어져서 손해를 볼 수도 있습니다.

좀더 쉽게 설명하면 타이거우즈(요즘 조금 부진하지만)가 골프치는 모습을 보고 골프를 배우기는 어렵고, 김연아가 스케이트 타는 것을 보고 따라하기 어렵다는 겁니다. 어떻게 해서 이러한 결과물이 나오는지 그 과정과 훈련 방법을 알아야 하겠지요. 

그런 과정에 관련된 내용이 책에서 상당히 많이 언급하려고 노력했습니다.

그 과정이라는 것도 각자의 수준에 따라서 보이는 것이 다릅니다. 수준을 1~10정도로 정의할 때 수준이 '1'인 사람은 아무리 설명해도 '2'나 '3'의 내용만 이해가 가능합니다. 수준이 '5'인 사람은 '6'이나 '7'정도가 이해할 수 있습니다. 그래서 올바른 방법으로 꾸준히 차근차근 훈련(경험)을 해 나가야 성장합니다. 

그외의 끝내주는 방법은 없습니다.

위 질문의 요지를 보면 다음과 같습니다.
  1. 모듈을 어떤식으로 분리하는지?
  2. 소스트리를 어떻게 구성하는지?
  3. 중복되는 소스코드를 어떻게 제거하는지?
  4. 공통모듈은 어떻게 공유하는지?
  5. 코멘트는 어떤 규칙으로 작성하는지?
결론부터 말씀드리면 다음과 같습니다.

 구체적인 방법은 회사마다 다르지만 원리는 똑같다.

이것을 모두 이해하려면 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에서 헤매고 있는 겁니다. 그래도 다른 개발자들보다 용어도 많이 알고 말싸움에서 이기고 잘 안되는 것은 다른 사람들 탓을 하곤 합니다. 이것이 제가 여러 현장에서 겪는 현실입니다.
차근 차근 노력해 가는 것이 올바른 방법이고 전문가의 도움을 통해서 제대로 된 길로 가장 빠르게 가는 것이 유일한 방법입니다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
Image by Justin Pfister


저작자 표시 비영리 변경 금지
신고

전규현 기반시스템/소스코드관리 SRS, 소스코드관리시스템, 소스코드트리, 소스트리, 피어리뷰

  1. 주석처리에 대해서 말이 많이 오가는데
    음.. 확실히 소스에 넣으면 코딩시에 지저분 해지는거 같고
    그렇다고 해서 별도의 문서로 하기에는 관리가 쉽지가 않은거 같더라구요.


    오늘도 좋은 글 감사합니다 ^^

  2. 구차니님 안녕하세요.
    누구는 "소스코드를 주석처럼 자세히 작성해라", "주석은 필요없다.", "있다" 말들이 많지만, 어느것도 정답이 아닙니다. 회사에 알맞게 규칙을 스스로 정하면 됩니다. 그리고 따라야지요.

  3. Blog Icon
    galsys

    규칙을 정한데로 따른다라. 그렇군요.

  4. 은총알은 없다이군요.
    그럼에도 불구하고 계속 은총알을 찾아 해메게 되네요.

    마지막 코멘팅에 대한 질문은 소스코드 코멘트는 아니고 형상관리툴에 체크인할 때 코멘팅 규칙을 여쭤본 것이었습니다. 저는 귀찮아서 코멘트를 종종 빼먹고 체크인하는데, 책에서 이 때의 코멘팅 규칙을 가지고 있어야 한다고 했던 것 같아서요. 혹시 그게 소스코드 코멘트 규칙이었던가요? 집에 가서 책을 다시 뒤져봐야겠어요^^;
    다시 읽어보니 제가 질문을 아주 애매하게 드렸네요.

    좋은 글 잘 읽어보았습니다.
    감사합니다.

  5. 제가 달 곳은 아닌듯 하지만 주제넘게 리플을 달아봅니다.

    개인적으로 doxygen 등의 comment documenting application의 문법대로 생성해주는 것이 가장 무난하지 않을까 생각을 해봅니다. 프로그램 작동원리와 같은 세부 주석은 headrer 파일쪽으로 몰아주는 식으로 말이죠.

    라고는 하지만.. 저도 생각만 해봤지 직접 실행을 안해봐서 잘 모르겠어요 ㅠ.ㅠ

  6. Commit할 때 코멘트는 "Commit message"라고 통일해서 부르면 됩니다. 정확한 용어를 사용하는 것도 자신의 내보이는 중요한 요소가 됩니다. ^^

    Commit Message에서 빠지지 않고 꼭 입력하기를 권장하는 2가지가 있습니다.
    바로 BugID(Issue ID)와 Reviewer입니다.

    BugID가 꼭 포함되는 이유는 버그관리시스템에 등록되지 않은 변경은 없다는 전제하에 작업을 해야 하기 때문에 물론 알파 이전에는 예외이지만, 이후에는 소스코드 한줄을 수정해도 버그관리시스템에 등록을 해야 합니다. 그래서 엑셀에 버그를 관리하는 회사에서는 불가능한 것이지요.

    그리고 누가 리뷰를 했는지 꼭 적게 합니다. 이는 Peer Desk Check을 한다는 전제하에 시행할 수 있습니다. Peer Desk Check은 Commit전에 간단히 동료와 리뷰를 하는 것으로 가장 효과적인 방법중 하나입니다. 이를 도와주는 툴도 있기는 하지만 툴 없이도 할 수 있습니다. Review를 하지 않았으면, None이라고 적고 소스코드를 책임지면 됩니다. 추후 여기서 버그가 나오면 진짜 민망해집니다.

    그리고는 간단한 Message를 포함하면 됩니다. 이미 버그관리시스템에 많은 정보가 있으므로 간단히 적으면 됩니다.

    Commit Message는 절대로 빼먹으면 안됩니다. 버그 등록하지 않고 마음대로 고치면 안됩니다. 이러한 작은 것들이 큰 차이로 나타나게 됩니다.

    나중에는 여기에 관련된 Post로 해야 겠네요.

    감사합니다.

  7. 안녕하세요, '소프트웨어 개발의 모든 것'을 구입하여 읽는 도중에 책에서 언급한 commit시의 로그
    메시지 표준이라는게 어떤식으로 쓰는 것인지 궁금하여 블로그에 들르게 되어 있는데 위 댓글에
    언급이 되어 있는 것 같네요.
    책에서도 좋은 내용 많지만 블로그에서도 많이 얻네요. 좋은 책과 블로그 감사합니다.

  8. 윤연식님 반갑습니다.
    좋은 인연이 되길 바랍니다.

SRS에 대한 인식의 변화

2009.11.13 23:46 by 전규현


잠시 후 Google blogger로 이동됩니다.




 
그 동안 본 블로그를 통해서 소프트웨어 개발에서 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, 스펙, 분석역량 향상에 대한 글을 종종 올려보려고 합니다. 블로그를 통한 지식전달이 얼마나 효과가 있겠는지 의문은 들지만, 필요성에 대한 인식만 생기더라도 글을 올린 보람을 있을 것으로 생각됩니다.

이와 관련된 궁금증, 의견, 경험, 고민거리, 정보, 아이디어 등 어떤 것이라도 같이 교환하고 싶습니다. 댓글이나 방명록, 메일로 얼마든지 보내주세요. 제가 해결해드릴 수 있는 것은 해결해드리죠.
그리고 교육을 받고 싶으신 개발자나 회사라면 연락 주시기 바랍니다. 제가 여건이 되는 한도내에서는 많은 소프트웨어 개발자들에게 전달하고 싶습니다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.

저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/요구사항분석 SRS, 분석, 스펙, 요구분석, 정부과제

  1. 최근 프로젝트 진행하면서, 요건정의서 / 주요화면 정의서만 가지고 프로젝트를 수행했었습니다. 유사 경험이 있으니 잘 되겠지라구 약간은 자만하면서요..

    하지만 관련 분야 업무를 처음 해보는 사람들과의 협업/구현하면서 문제가 하나둘씩 생겨나기 시작하고, 주기능 보다는 당연히 될거라고 생각했던 부기능에서의 생각의 차가 너무 컸고, 결국 Rework을 하게 되더군요.
    확실히 일은 정석대로 해야한다고 SRS 로 시작했으면 좋았겠다는 후회가 나중에 들더라구요...

    좀 부끄러운 경험담이지만.. SRS 중요성/초기 설계의 중요성을 깨닿게 했던 중요한 교훈이었던 것 같습니다.
    전규현 수석님.. 블로그글 잘 공감하고 있습니다. 감사합니다.

  2. Peter님 안녕하세요.
    실제로 제가 다른 개발자들이 작성한 여러 SRS를 검토해보면 비기능요구사항이 주로 부실하게 작성되어 있더군요. 하지만 비기능요구사항이 SRS에서 더 중요하다는 것을 잘 인식하지 못합니다. 기능이 하나 잘못적힌 것은 일반적으로 해당 모듈만 수정하면 되지만, 비기능요구사항 하나 누락되거나 잘못 적힌 것은 시스템 전체를 다 뜯어 고쳐야할 정도로 큰 사건일 수 있습니다. 앞으로 블로그에서 이와 관련된 다양한 내용들을 다룰 계획입니다.

  3. 개발자들도 이러한 개발의 효율을 위한 절차를 받아 들여야 하지만
    그에 못지 않게 개발을 위탁하는 사람도 개발에 대한 이해가 널리 퍼졌으면 좋겠다는 생각이 듭니다.

    이러한 프로세스 없이, 중간에 계속 수정을 요구하고 이에 따른 추가기간을 정산하지 않으면
    개발자 역시 무상으로 계속 지치게 되니 말이죠. 물론 인간이라 처음부터 완벽하게 SRS를 만들어내서
    한번에 만들수는 없기에 어느정도 변경사항이 생기겠지만, 디자인이 마음에 안들어요 이렇게 바꾸어 주세요
    라고 하는건 개발 위탁하는 사람역시 이러한 개발의 과정중 하나로 넣어 교육을 시켜야 하지 않을까?
    라는 생각마저 들게 합니다.

  4. 구차니님 안녕하세요.
    말씀 하신 것처럼 처음부터 스펙을 완벽하게 다 정하고 프로젝트 끝날 때 까지 절대 바꾸지 않을 수는 없습니다. 그래서 어차피 바뀌니 대충 시작하는 것은 더 문제가 크죠.
    개발자나 고객이나 모두 스펙에 대한 이식의 변화가 필요하겠죠. 또한 교육, 훈련과 경험 모두가 필요하고 1,2년에 해결될 문제는 아니라고 봅니다.

  5. Blog Icon
    김경록

    좋은 글 잘 읽고 갑니다.
    ^^

  6. 김경록님 오랫만입니다.
    댓글 남겨주셔서 감사합니다. 항상 건강하세요.

  7. IT 관련 무엇인가를 찾다보면 이 블로그로 들어오게 되는 듯 합니다. ^^; 새로운 프로젝트를 하는데 아무래도 불가능에 도전해보아야 할 것 같습니다. 갈수록 괜찮은 SRS가 나오겠지요. 혹시 괜찮은 Template 있으시면 하나 던져주시면 고이 잘 받아먹겠습니다. 굽신굽신~

  8. Google에서 Software Requirements Specification으로 검색을 하면 여러 Template를 찾을 수 있을 겁니다. 하지민 Template 만 보고 제대로 적는 다는 것은 불가능합니다. 타이거우즈 골프채만 보고 타이거우즈처럼 골프치는 것을 흉내내려는 것과 같습니다.
    소프트웨어에서 가장 어렵고도 중요한 것이 바로 무엇을 개발할지(스펙)을 적는 것이지요.

  9. 좋은 글 잘 읽고 갑니다 ^^ 현재 컴퓨터공학 전공하는 3학년 학생입니다~
    소트프웨어 공학 과목을 공부하면서 요구사항 분석 부분에 어려움이 있어
    관련 자료를 찾다가 방문하게 되었네요!
    종종 들러서 좋은 글 자주 읽도록 노력하겠습니다.

  10. 안녕하세요. 임수빈님
    소프트웨어 공학은 배울수 없다고들 합니다. 즉 경험을 통해서 익힐 수 밖에 없다는 뜻. 하지만 배우는 것은 나중에 경험을 할 때 큰 도움이 됩니다.
    그중에서도 가장 어려운 분야가 요구사항 분석입니다.
    이론적인 것 만 가지고 실제 프로젝트에서 제대로 적기는 정말 어렵습니다.
    열심히 배우시고 실전에 적용하시기 바랍니다.

  11. Blog Icon
    이해승

    안녕하세요. SI 분야에서 일한지 15년이 넘어가면서 제대로 된 SRS 작성해 본 기억이 별로 없습니다.
    어디서 배워야 할지도 모르겠구요...소프트웨어 공학, 다양한 프로젝트 관리 기법 등등 안해 본 경험이
    별로 없음에도 불구하고 여전히 제대로 된 SRS 작성하는 것에 목 말라 하고 있습니다.
    어떻게 시작해야 좋을까요?

  12. 이해승님 안녕하세요.

    가장 어려운 질문 중 하나입니다. "어떻게하면 SRS를 잘 쓰는 법을 배울 수 있을까?" 어떻게 하면 SW를 잘 개발할 수 있을까와 거의 동격의 질문이기도 합니다.
    또는 어떻게 피아노를 배울 수 있을까?와 비견되기도 합니다.
    오랫동안 SW를 개발해왔던 개발자라고 하더라도 SRS를 작성하는 것, 즉 스펙을 작성하는 것은 여전히 어려운 과제입니다.

    제일 좋은 것은 스펙을 잘 작성하고 있는 회사에 가서 일하면서 자연스럽게 배우는 것입니다. 우리나라에는 그런 회사가 별로 없으니 실리콘밸리로 가야합니다. 현실성은 없죠.

    다른 방법으로는 전문가나 경험자에게 배우고 직접 작성을 해보고 리뷰받고 이런 과정을 반복하면서 배우는 방법입니다.

    그렇지 않고 책을 보고 스스로 해보는 방법은 시행착오를 많이 겪어야 하고 영원히 제대로 작성하믄 방법은 못배울 가능성이 거의 100%입니다.

    가장 좋은 방법은 회사에서 전문가를 데려와 주는 것이겠죠.

    우선은 제가 쓴 "소프트웨어 개발의 모든 것"이라는 책을 먼저 보세요. 이해를 돕기 위한 설명이 좀 되어 있습니다.

SW개발과 Teamwork, 그리고 Review

2009.10.19 11:29 by 전규현


잠시 후 Google blogger로 이동됩니다.




거의 모든 SW개발은 팀으로 진행됩니다. 종종 혼자서 기획하고 개발, 테스트, 영업까지 모두 다하는 경우도 있기는 하지만, 이는 워낙 작은 규모의 회사에서 있는 일이고, 대부분은 팀을 이뤄서 일을 해야 효과적으로 SW를 개발해 낼 수 있습니다. 

그 팀의 규모는 2명에서부터 수천 명에 이르기까지 다양합니다.
하지만, 주변에서 대규모 프로젝트 팀을 보기란 그렇게 쉽지 않습니다. 5~6명 안팎의 소규모 팀은 아주 흔하게 볼 수 있고, Teamwork도 꽤 좋은 편입니다. 하지만, 규모가 몇 십 명만 넘어가도 효과적으로 관리를 해내지 못하는 경우가 흔합니다. 그래서 팀이 규모가 커지면 프로젝트가 오히려 늦어진다는 얘기도 있습니다.

이런 경우라면 소규모의 팀은 제대로 된 Teamwork를 갖춘 것이 아니라 워낙 작아서 서로 인간적으로 잘 통하고 서로 커뮤니케이션을 왕성하게 하면서 프로젝트를 진행하기 때문에 문제가 없는 것이고 수십 명 규모의 팀은 똑같은 방법으로 커뮤니케이션이 잘 되지 않기 때문에 문제가 많을 가능성이 더 높습니다.

팀을 이뤄서 소프트웨어를 개발할 때 가장 중요한 것은 Review입니다.
Review에 익숙하지 않은 개발자들이 모여서 개발을 하는 것은 서로 따로 개발하는 개발자들을 한데 모아 놓은 것과 별반 다르지 않습니다. 이런 팀은 개발을 하면서 서로 다른 목표를 가지고 개발을 하기도 하고, 아키텍처
에 대한 오해를 하고 통합 시 인터페이스가 안 맞고, 일정이 서로 어긋나곤 합니다.

물론 각 개발자들이 서로 개발하는 모든 내용을 다 Review하고 공유할 수는 없습니다. 프로젝트의 규모에 따라서 또, 서로의 역할에 따라서 Review하는 범위와 대상이 달라집니다. 그럼 소프트웨어 개발팀에서 리뷰를 해야
 하는 것들은 어떤 것이 있는지 알아보겠습니다.

1. SRS(스펙) 작성 및 리뷰 (중요도 : 매우 높음)
제가 여러 차례 강조했지만 SRS는 SW개발에 있어서 가장 중요하며 프로젝트 기간을 단축하고 비용을 절약하는데 가장 핵심입니다. SRS작성시는 개발팀 뿐만 아니라 프로젝트의 모든 관련자와 수 차례 리뷰를 합니다. 모든 관련자가 SRS의 모든 항목을 다 리뷰하는 것이 아니고 본인들이 책임지는 부분만 리뷰를 하면 됩니다. 예들 들어 Marketer인 경우는 프로젝트 목표와 비전, 주요 기능 등과 같이 마케팅에 필요한 부분만 리뷰를 하면 됩니다. 이렇게 SRS를 철저히 리뷰를 해야 모든 관련자가 프로젝트에 대하여 동일한 생각을 가지게 되고 프로젝트가 끝
날 때까지 스펙 변경을 최소한으로 유지하게 됩니다. 또한 이런 SRS리뷰가 일상적으로 반복적으로 일어나야 자연스러운 관행으로 자리잡고, 개발자들의 분석 능력을 향상하는데도 도움이 됩니다. 참고로 SRS(스펙, 요구분서)는 SW개발에서 약 40%의 비중을 차지한다고 합니다. 

2. SW아키텍처 리뷰 (중요도 : 높음)
웬만한 규모의 SW의 아키텍처는 한 명의 머리 속에 나올 수가 없습니다. 아키텍처는 정답이 있는 것이 아니라서 생각을 많이 할 수록 좋아 질 수 있습니다. 개발자들은 설계 단계에서 이런 아키텍처 리뷰를 여러 차례 반복하게 됩니다. 그러면서 아키텍처를 점점 구체화 해나가고 개량해나갑니다. 규모가 큰 SW인 경우에는 상,하위 아키텍
처를 구분해서 설계를 하기도 하고 각 컴포넌트간에는 인터페이스만 정하게 되고 그 내부는 또 각 개발자들이 설계를 하고 리뷰를 하게 됩니다. 이 때 UML을 사용하건, Flow chart를 사용하건, DFD를 쓰던 큰 상관은 없으며 각자 익숙한 툴로 현재의 아키텍처를 가장 잘 표현할 수 있는 것으로 작성하면 됩니다. 이러한 과정 또한 선배 개발자들이 후배 개발자들에게 지식과 경험을 전달할 수 있는 좋은 기회가 됩니다.

3. 소스코드 리뷰 (중요도 : 중간)
소스코드 리뷰가 중요하기는 하지만 SRS와 아키텍처리뷰보다 중요하지는 않습니다. SRS와 아키텍처가 잘못되면 엄청나게 많은 재 작업을 해야 하지만, 소스코드가 잘못된 것은 버그로 발견되고 또, 상대적으로 쉽게 고칠 수 있습니다. 그렇긴 하지만 소스코드 리뷰는 좋은 관행이며 꾸준히 노력해서 정착해야 합니다. 소스코드 리뷰 방법은 매우 다양하지만, 저는 가장 간단한 방법은 Peer desk check을 권합니다. 소스코드 관리시스템에 Commit하기 전에 동료와 같이 리뷰를 하는 겁니다. 간단히 Diff툴을 실행해서 바뀐 소스코드를 볼 수도 있습니다. 그리고 소스코드를 등록할 때 누가 리뷰를 했는지도 꼭 기록하게 하는 정책도 소스코드리뷰를 확산하는 좋은 방법 중 하나입니다.

소프트웨어 개발에 있어서 Teamwork은 서로 사이가 좋은 팀을 말하는 것은 아닙니다. Teamwork에 있어서 서로 간의 신뢰는 중요한 요소이지만 필요충분조건은 아닙니다. 각자 전문가로서의 자신의 일들을 제대로 수행하면서 리뷰 등의 커뮤니케이션이 적절히 원활하여 동일한 목표와 비전을 가지고 SW를 개발해야 합니다.

우리는 흔히 혼자서는 일을 정말 잘하는데 뭉쳐 놓으면 삐걱대는 개발자들을 많이 보아 왔습니다. 이는 그 개발자만의 탓도 아닙니다. 서로들 Teamwork이 부족한 것이지요. 즉, 팀을 이뤄서 일하는 방법에 서툰 것입니다. 가장 좋은 방법은 제대로 되어 있는 회사에서 몇 년 일해보는 것입니다. 그런 환경이 안 된다면 SRS(스펙)리뷰부터 조금씩 활성화 해나가는 것이 좋습니다. 제대로 된 SRS(스펙)을 써보지 않는 개발자들에게는 SRS(스펙)을 쓰는 것도 큰 도전이지만, 어차피 SW를 제대로 개발하기 위해서는 피해 갈 수 있는 것이 아니기 때문에 시도를 해봐야 합니다. 

좋은 Teamwork를 갖추지 못한 개발팀에서는 아무리 뛰어난 개발자라고 하더라도 제대로 실력을 발휘할 수 없습니다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image by tim ellis

저작자 표시 비영리 변경 금지
신고

전규현 개발문화 review, SRS, Teamwork

  1. Blog Icon
    김경록

    좋은 글 잘 읽었습니다. Agile에서 pair programming이 생각나네요..
    저희 회사에서도 Source Review가 점점 중요해져서 전문 Reviewer까지 새로 뽑고 했는데 잘 되면 좋겠네요ㅎㅎ

  2. 김경록님 안녕하세요.
    전문 Reviewer가 있습니까? 음~~ 회사 규모가 엄청나게 크나보죠? 제가 전에도 지적했지만, 차근차근 접근하여 개발자들 몸에 자연스럽게 베어들게 해야 하는 일들을 너무 형식적으로 접근해서 프로세스에 얽메이게 되면 벽에 부딪혀서 실패할 수도 있습니다.
    전문Reviewer는 Review전문가이고 채용이 된 이상 가시적인 성과를 내어야 하기 때문에 무리한 시도를 할 수도 있고 관료화 될 수도 있습니다. 또한 소스코드리뷰보다 스펙/설계 리뷰가 더 중요한데, 이런 것이 시도 또는 정착되지 않은 상태에서 소스코드리뷰만 너무 강조하면 개발에 도움이 되기보다는 번거롭기만 하다는 인식이 생길 수도 있습니다. 따라서 좋은 시도가 성공하려면 현재 역량과 상황에 맞게 조심스럽게 차근차근 접근하는 것이 필요합니다.
    기우일수도 있으나 잘못 접근하면 아니한만 못한 경우가 워낙 많아서 조심스럽게 말씀드립니다.

외주를 주면 된다고요?

2009.03.30 22:07 by 전규현


잠시 후 Google blogger로 이동됩니다.



"우리가 못하면 외주를 주면 된다."

이렇게 생각하십니까? 아니면 인력이 모자라거나 시간이 부족하여 외주를 주십니까?
대부분의 개발자라면 외주에 대한 쓰라린 기억이 있을 겁니다.

한 포탈업체가 인도에 포탈 시스템 외주를 줬다가 통째로 버리고 국내 업체에 다시 외주를 줘서 개발한 적이 있습니다. 그리고도 국내 업체에 질질 끌려 다녔었지요.

인도에 외주를 줄 때는 스펙을 제대로 전달 하지 못했고, 개발 기간에도 전혀 관리와 리뷰를 하지 않고 최종 결과물만 받아 본 사례입니다. 이런 케이스 많죠?

그리고 국내 업체에 외주를 줄 때도 자체적으로 기술을 보유하지 못하고 외주에 의존하다 보니 지속적으로 문제가 됩니다.

결국 스스로 만들 능력이 없는데, 외주를 주는 것은 성공할 확률도 낮고, 경험있는 외주 업체를 만나면 개발은 제대로 되더라도 질질 끌려다니기 일쑤입니다. 또한 외주를 주기 위해서는 분석능력과 관리 능력이 필수 입니다. 특히 해외 업체에 외주를 줄 때는 대단히 정교한 스펙문서(SRS 등)가 필요합니다. 따라서 대다수의 업체는 외주를 줄 능력이 없다고 볼 수 있습니다. 그래서 외주가 아니고 사람만 빌려오는 거죠. 옆에 앉혀놓고 같이 의논해가면서 개발하는 방법이 유일한 방법입니다. 소프트웨어 개발 생산성이 아직도 매우 낮은 수준에 머물러 있는 원인이기도 합니다. 

"스스로 잘 할 수 없다면 외주는 더 어렵다."

이미지출처 : Microsoft Office Online

저작자 표시 비영리 변경 금지
신고

전규현 소프트웨어이야기 SRS, 스펙, 외주

  1. 날로 글이 간결하면서 핵심을 전하는군요. 대단하십니다.
    외주의 기본 요건을 다룬 이 글은 현장에서 질리도록 보는 우울한 장면을 담아내서 씁쓸하기도 하고, 계도하려는 노력에 반갑기도 합니다.

    그나저나 조 아래.. RSS 구독 아니콘을 보니 구독자 하위 호환성(?)을 유지하시는 모습이 인상적입니다. :)

  2. 영회님 안녕하세요. 과찬의 말씀입니다. 수많은개발자와 경영자들이 착각속에 살고 있는 듯합니다. 저는 그뒤로 또 새로운 바이러스의 감기에 걸려서 캑캑대고 있습니다. 바이러스가 없는 세상에서 살고 싶어요. 나중에 하와이로 이민가고 싶습니다.

  3. 요구사항에 대한 잦은 피드백이 필요한것은 인도나 한국이나 동일하다고 생각합니다. 제 경험으로 정교한 스펙을 주는것보다 성근 스펙에 잦은 피드백이 더 효과 있었던거 같습니다. 다만 커뮤니케이션을 위한 가혹한 피드백은 각오해야...^^

  4. 황상철님 안녕하세요.
    요구사항은 계속 변하기 마련이지요. 한번에 제대로된 스펙을 만들어서 소프트웨어를 개발하는 것은 불가능합니다. 당연히 지속적인 피드백과 변경관리는 필수입니다.

  5. Outsourcing과 Offshoring의 차이점에 대해서 잘 못 이해하시는 분들도 있으신 것 같습니다. 특히 테스트부분에 Outsourcing이 아닌 Offshoring을 진행한 일을 개선하러 해외 출장을 나왔는데...
    와서 보니 넘 우울하네요. Test에 대한 Offshoring은 저희 회사에서는 100% 실패할 것이라 생각하고 아니라고 말씀을 드렸는데... 흑...
    어찌해서 진행은 되었고 시간이 꽤 지난 지금 어떻게든 개선?을 하라고 하시네요.
    이 부분은 제가 나중에 다시 한 번 정리해서 블로그에 올려보겠습니다. ^^;

    테스트에 대한 생각이 많이 바뀌었더라도 아직 테스트에 대해서 너무 쉽게 보시는 분들이 넘 많습니다. 안타깝습니다. Offshoring이라니... ㅡㅡ;

    *회사 상황을 자세히 못 적으니 말이 좀 이상하고 이해하기 힘들 것 같네요... 그래도 속상해서... 장기 해외출장은 참 힘드네요... ㅎㅎ

  6. 정의의소님 안녕하세요.
    테스트부분은 개발의 한부분으로 개발 초기부터 참여를 해야하는데, 테스트를 너무 기계적으로 생각하는 분들이 많이 있습니다. 그냥 자신들의 경험에 비춰서 생각하는 것이지요. Offshoring할 수 있는 분야는 따로 있지요. 무슨 뜻인지 충분히 알고 있습니다. 이와 유사한 사례들도 알고 있고요. 자칫 준비도 안되었고 내부적으로도 제대로 못하는데, 비용절감을 위해서 Outsourcing이나 offshoring을 시도하는 회사들을 보면 100이면 100실패할 것이기 때문에 안타깝고 말리고 싶습니다.

샘플만 보여주세요.

2009.01.20 18:20 by 전규현


잠시 후 Google blogger로 이동됩니다.



소프트웨어 개발에서 가장 어려운 것이 "요구사항분석"이라고 여러 차례 언급한 바가 있습니다.

그런데 SRS는 샘플이나 Template을 보고 잘 적는 것은 거의 불가능합니다.

개발자들은 원래 샘플 소스코드를 보고 많은 것들을 배워왔기 때문에 스펙도 샘플을 보면 잘 적을 수 있을 것 같은 착각을 하는 경우가 흔합니다. 샘플 소스코드가 도움이 되는 이유는 개발자들인 소스코드에 대해서는 이미 상당한 지식과 경험이 있기 때문입니다.

샘플만 보고 잘하려고 하는 것은 피아노를 잘 치고 싶다고 유명 피아니스트가 친 것을 몇 번 보고 피아노를 잘 치려 하는 것과 비슷합니다. 심지어는 지금 듣고 있는 피아노 연주가 잘 하는 것인지 못하는 것인지 판단하기도 어렵죠.

그래서 인터넷에서 구한 샘플이 별 도움이 안되거나 심지어는 방해가 되는 이유가 그것입니다. 좋은 샘플을 보여주면 일부 도움이 될 수는 있어도 큰 도움은 되지 못합니다. 나쁜 샘플을 만날지 어떻게 알겠습까? 아마 인터넷에서는 좋은 샘플을 구한다는 것은 거의 불가능할 겁니다.

타이거우즈 골프 스윙을 100번 보는 것보다 자신이 실제로 연습을 많이 하고 배우는 것이 더 빨리 배우는 길 일겁니다. 그렇지 않고 배우는 방법은 이미 선배들이 다 겪었던 시행착오를 자신도 그대로 겪는 방법이 있습니다. 자신은 시행착오를 겪지 않고 한번에 제대로 적을 수 있다고 생각하는 것은 자신의 능력에 대해서 대단히 너그럽게 생각하는 심리학적인 오류에 빠지는 것입니다.

비단 스펙을 적는 일뿐만 아니라 스키를 배우던, 발레를 배우던 모든 인생사가 다 비슷하지만 누구에게도 시행착오를 겪지 않는 행운은 찾아오지 않습니다. 책을 보고 공부를 하는 것도 많은 도움이 되지만 주변에서 경험자를 찾아서 도움을 받으세요. 주변에 자신을 도와줄 전문가가 있다면 그것이 행운입니다.
저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/요구사항분석 SRS

SRS(Software Requirements Specification)의 중요성

2008.11.19 10:32 by 전규현


잠시 후 Google blogger로 이동됩니다.



본 블로그에서 소프트웨어 개발, 소프트웨어 공학에 대한 여러 주제에 대해서 다루겠지만, 
특히 나는 요구사항 특히 SRS에 대해서 많이 다루려고 합니다.
"소프트웨어개발의모든것"이라는 책에서도 요구사항에 대해서 가장 중요하게 다루고 있지만 지면의 한계와 다양한 독자층의 눈높이를 맞추기 위해서 욕심보다는 많이 설명하지 못하는 측면이 있습니다.
그래서 소프트웨어 개발단계에서 가장 중요한 "요구사항"에 대해서 천천히 여러분들과 의견을 주고 받으면서 심도있게 다뤄볼까 합니다. 제가 세상의 모든 경우의 요구사항 분석 기술 및 경험이 있는 것이 아니니 여러분들과 토론을 하면서 또 많이 배울 것을 기대하고 있습니다.

먼저 제가 책에서 요구사항에 대해서 설명한 내용을 앞부분을 약간 소개할까 합니다.

 요구사항 분석

소프트웨어 프로젝트에 있어서 가장 흔한 실수 중의 하나가 요구사항이 불명확한 상태에서 급하다는 이유로 일단 설계, 구현을 시작하는 일이다. 어떤 경우는 스펙문서가 아예 없는 상태에서 프로젝트를 진행하는 경우도 있다. 또는 간단한 요구사항 목록을 가지고 스펙이라고 착각하는 경우도 많다.
제대로 된 요구사항 개발 없이 프로젝트를 성공적으로 수행하는 것은 거의 불가능하다. 고객의 요구사항을 상세히 기술하였다고 해서 좋은 요구사항은 아니다. 고객도 자신이 원하는 것을 자세히 모르는 경우가 아주 흔하기 때문이다. 고객의 요구사항을 단순히 기술한 정도의 요구사항은 프로젝트 후반에 많이 바뀔 수 있는데, 요구사항 개발 시 간단히 해결할 수 있는 것을 프로젝트 후반이나 유지보수 시까지 와서야 처리함으로써 수십 배의 비용을 추가로 치르는 경우도 있다.
요구사항 개발은 단순히 요구사항을 옮겨 적는 일이 아니다. 요구사항을 수집하고, 분석하고, 정리하고, 리뷰하는 일을 반복하여 완성도를 높여가는 일이다.
책을 보고, 샘플을 보고, 템플릿을 이용해서 독학함으로써 SRS를 잘 쓰는 것은 거의 불가능하다. 책이 도움은 될 수 있으나, SRS를 제대로 쓰려면 제대로 된 회사에 가서 몇 년 동안 일하면서 배워야 한다. 때에 따라서는 전문가에게 컨설팅을 받는 것도 좋은 방법이다. SRS는 기능공처럼 기법에 따라 작성하면 되는 것이 아니라 인간의 판단이 핵심인 문서이기 때문에 작성이 생각처럼 간단하지 않다.

 요구사항의 중요성

요구사항 문서는 프로젝트에서 작성하는 산출물 중에서 가장 중요하다. 요구사항 문서인 SRS는 소프트웨어 프로젝트의 기둥이다.
소프트웨어 시스템 구축에서 가장 어려운 부분은 무엇을 구축할 것인지를 정확하게 판단하는 것이다. 그러나 구현을 시작하기 전에 요구사항을 완벽하게 파악하는 것이 불가능한 경우가 많다. 그렇다고 해서 요구사항 개발에 소홀해서는 안 된다. 시간이 허락하는 한 최대 한도로 많은 정보를 파악하는 것이 좋다. 
잘못된 요구사항은 많은 재작업 비용을 필요로 한다. 재작업 비용은 일반적으로 전체 개발 비용의 30~50%에 이르는 것으로 알려져 있다. 요구사항 오류로 인한 재작업 비용은 전체 재작업 비용의 70~85%에 이른다. 잘못된 요구사항, 부족한 요구사항은 일정을 지연시키며 많은 추가 비용을 발생시킨다. (출처, Software Requirements, Karl E. Wiegers, Microsoft Press)
완벽하게 상세한 요구사항이 가장 좋은 요구사항은 아니다. 요구사항은 이해하기 쉽게 간결함을 추구해야 한다. 간결하지만 충분히 설계, 구현할 수 있어야 한다. 그리고 요구사항 문서는 모든 관련자가 충분히 검토해야 한다.



요구사항 오류는 개발 단계가 지나가면 갈수록 그 수정 비용이 기하급수로 증가한다. 유지보수 단계에서 요구사항 오류를 바로 잡으려면 요구분석 단계에서 바로 잡는 것보다 200배의 비용이 더 드는 것으로 알려져 있다. 충분히 검토하여 오류가 없는 요구사항을 만드는 것이 프로젝트를 성공으로 이끄는데 가장 필요한 핵심이다.

SRS란?

요구사항 분석 문서의 종류는 수없이 많다. 개발 방법론에 따라서 제시하는 요구사항 문서가 다르고, 그 개수도 다르다. 여기서 소개할 문서는 SRS이다. SRS는 이 책 전체에서 소개하는 많은 문서 중에서 가장 중요하다. 프로젝트를 성공으로 이끄는데 가장 중요한 핵심이기 때문이다. 만약 소프트웨어 프로젝트에서 문서를 딱 하나밖에 만들 시간이 없다고 하면 SRS를 만드는 것이 좋을 것이다.



SRS는 IEEE에서 만든 가이드와 표준 Template이 있다. 회사들마다 사용하는 Template이 약간씩 다르지만 문서이름, 목적, 취지는 전세계적으로 표준이라고 보면 된다. 소프트웨어 개발 회사라면 회사에 맞게 각자 커스트마이즈 된 SRS Template을 가지고 있어야 한다.


저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/요구사항분석 Requirement, spec, SRS, 스펙, 요구사항

  1. Blog Icon
    똘똘마리

    좋은 글 읽었습니다. 궁금한 점

    1. SRS가 독학으로 거의 불가능하다고 하셨는데 처음 누군가가 SRS를 작성했을 때는 누구에게 배웠을까요? 물론 처음 누군가는 폰 노이만이나 앨런 튜닝같이 천재겠죠? 그래도 완전 불가능한 것이 아니니까 연습하다보면 조금씩은 발전해 나갈 수 있겠죠.

    2. SRS의 단위가 궁금합니다. 예를 들면 화면마다 하나씩 만든다라든지 모듈마다 하나씩이라든지 아니면 시스템마다 하나인지?

  2. Blog Icon
    똘똘마리

    거의 3년된 포스팅 글이라 답변이 달릴지 궁금했는데 자세한 답변 감사합니다. SRS를 읽으니 이것이야말로 생존의 돌파구가 아닐까 싶은 생각과 막 배우고 싶은 생각이 듭니다. 지방의 SI를 하고 있어 기회가 없는 것 같아 안타깝네요. 친절하고 꼼꼼한 답변 감사합니다. 포스팅 된 글과 책 열심히 읽어 보겠습니다.

  3. 안녕하세요. 똘똘마리님

    정말 재미있는 의문이네요. 골프나 피아노도 독학은 불가능합니다. 그럼 처음에 골프나 피아노를 친 사람은 누구에게 배웠을까요? 그 분야도 100년 넘게 진화를 해 온겁니다. 한사람이 정립한 것이 아닙니다. 이제 기술은 거의 완성이 되어서 과거나 지금이나 큰 차이가 없습니다. 배우는 방법이나 장비가 계속 발전하고 있을 뿐입니다.

    SRS는 60년 소프트웨어 역사에서 소프트웨어 공학이 발전하면서 가장 중요한 것이 스펙이라는 것을 알아내면서 정립된 것이고 거의 완성된지 20년이 지났습니다. 20년동안 기술이 발전하면서 조금씩 바뀌었지만 큰 틀은 변화가 없습니다.
    SRS의 틀은 혼자 만든 것이 아니고 20~30년 이상의 최고의 소프트웨어 개발자 수십명이 10년 이상 발전시켜나가면서 완성해 놓은 것입니다. 즉 소프트웨어를 개발할 때 꼭 정의해야 할 것들을 모두 적을 수 있는 틀을 만들어 놓은 겁니다.
    폰 노이만이나 앨런 튜닝 같은 천재가 아니고 실제 소프트웨어 프로젝트를 많이 진행 해봤던 실전파 전문가들입니다.
    몇가지 SRS Template들이 있지만 큰 틀은 같습니다.

    SRS단위는... SRS는 기능명세도 아니고 화면정의서도 아니고 설계서도 아닙니다. 스펙입니다.
    그래서 변역을 하지 않고 SRS라고 얘기를 해야 의미가 왜곡되지 않습니다. 외국 개발자들에게 SRS라고 하던가 스펙이라고 해야 의미가 통합니다.
    소프트웨어의 스펙은 화면, 인터페이스, 기능, 비기능 등 모든 것을 포함합니다. 그래서 보통 프로젝트에서 하나를 작성합니다. 하지만 프로젝트가 매우 거대하면 쪼개서 작성하기도 합니다만 왠만해서는 그런 정도로 큰 프로젝트를 보기는 힘듭니다.
    500MM 넘게 들어가는 프로젝트도 SRS하나면 됩니다.

    궁금증이 해결 되셨나요? ^^

블로그 호스팅을 Google Blogger로 이전합니다.

최근에 블로그에 보안 문제가 발생하여 좀더 안정적으로 블로그를 운영하기 위해서 Google Blogger로 이전합니다. 기존에 http://allofsoftware.net 과 http://www.allofsoftware.net..

한국어(한글) 코드 이야기 (8)

유니코드에 대해서 좀더 알아보기 전에 한국어 코드(문자세트)와 인코딩에 대해서 좀더 알아보자. 1991년에 유니코드가 탄생한 후에 유니코드는 점점 많은 개발자들이 사용하기 시작해서 영역을 넓혀가고 있다. 물론 언젠가는 유니코..

유니코드 영토 전쟁의 승리자는? (7)

이번에는 유니코드의 코드 체계에 대해서 간단하게 알아보고자 한다. 소프트웨어 국제화를 필요로 하는 개발자라면 자주는 아니지만 유니코드 내부 코드 체계를 알아야 할 때가 있다. 다양한 플랫폼에서 개발을 할 때 폰트 등과 관련하..

유니코드는 어떻게 탄생했을까? (6)

소프트웨어 국제화를 이해하기 위해서는 유니코드에 대해서 필수적으로 잘 알아야 한다. 유니코드란 말을 들어보지 않은 개발자는 없지만 관련 용어가 매우 많아서 종종 헷갈린다. 게다가 유니코드가 탄생한지 20년도 더 넘었지만 아직..

직원을 잠재적인 도둑 취급하는 회사

필자는 몇 년 전 A그룹에 강연을 하러 갔다가 곤란한 일을 겪은 적이 있다. 한국 대부분의 대기업이 그렇듯이 보안이 매우 엄격한 회사였다. 나는 직원들의 안내대로 메모리, 외장하드를 모두 빼놓고 회사로 들어갔다. 하지만 강연..

외국에서 팔리는 소프트웨어의 아키텍처 디자인 원칙 (5)

김과장은 그 동안 한국어만 지원하는 소프트웨어 A를 개발해 왔는데 최근에 사장님이 A의 일본어 버전을 만들라고 했다. 그리고 개발 기간도 한달 밖에 주어지지 않았다. 그래서 기존 소스코드를 복사해서 한국어가 들어 있는 모든 ..

소프트웨어 개발자 성장에 꼭 필요한 리뷰

우리나라 개발자들은 프로그래밍은 잘 하는데 대접을 못 받는다는 얘기가 있다. 또, 머리는 좋은데 환경이 나쁘다는 얘기도 있다. 젊은 개발자들은 외국의 개발자들에 전혀 뒤지지 않는데 나이를 먹을수록 실력이 떨어진다는 얘기도 있..

외국에 출시한 소프트웨어가 날짜 때문에 낭패 본 사연 (4)

10년차 개발자인 김과장(가상의 인물)은 최근에 소프트웨어를 영어를 지원하도록 만들었다. 어플리케이션에서 표시되는 모든 메시지(메뉴, 버튼, 다이얼로그 등)를 영어로 번역했다. 그렇게 해서 영어버전을 출시했는데 얼마 안 가서..

독일어 버전 소프트웨어란 말이 잘못된 이유 (3)

본 시리즈는 차례대로 읽으면 소프트웨어 국제화가 전체적으로 이해가 되어서 소프트웨어 개발자에게 도움이 되는 방향으로 진행하려고 하고 있다. 개발자마다 지식과 경험이 천차만별이라서 초급 개발자를 기준으로 작성하고 있다. 경영자..

소프트웨어를 외국에 출시 하면서 흔히 빠지는 함정 (2)

우리나라 소프트웨어 중에서 외국에서 크게 성공했다고 하는 소프트웨어가 있는가? 온라인 게임을 제외하고는 거의 없다. 사실 게임은 국제화, 지역화를 잘 못하더라도 큰 흉이 안 된다. 하지만 그 외의 많은 소프트웨어들은 제품이든..

티스토리 툴바