오래된 SW 엔지니어의 평생 공부

개요

이 글은 한글로 번역된 책[1]의 내용을 읽고 난 글이다. 이 책은 여러 글을 모은 것이고, 여기서는 2장인 "성장과 시장"의 내용을 주로 하여 정리한다. 이 책은 이 2장 이외에도 해커 문화라고 하는 Open Source의 역사에 대해서도 설명하고 있다. 이러한 Open Source의 역사는 [2]에서도 만화로 잘 설명되어 있어서 틈이 나면 읽어 보는 것도 좋겠다.

성당 모델 vs 시장 모델

책에서는 2가지 소프트웨어를 개발 방식을 소개 한다.

• 상용 소프트웨어의 '성당" 모델
• 리눅스 세계의 '시장' 모델

사실 성당 모델은 상용 뿐만 아니라, Open Source 혹은 자유 소프트웨어 (Free Software)를 만드는 초기에도 적용되었다. 초기 Unix 기반의 Open Source들도성당을 건축하듯이 만들어 져야 한다고 믿었다. 특히, Emacs등은 그렇게 만들어 졌다. 

성당 모델에는 다음과 같은 특징으로 만들어 졌다.

• 몇몇의 도사 프로그래머 혹은 작은 모임의 뛰어난 프로그래머에 의해서 조심스럽게 만들어 진다.
•  때가 되기 전에 발표되는 베타판도 없이 만들어 진다. 

이와는 다르게 시장 모델은 Linux가 만들어지면서 다음과 같은 방법으로 만들어 졌다.

• 일찍, 그리고 자주 발표 한다.
• 다른 사람에게 위임할 수 있는 것은 모두 위임한다.
• 뒤 범벅이 된 부분까지 공개한다.

파트타임으로 해킹하면서 인터넷이라는 가느다란 선만으로 연결된 전 세계 수천명의 개발자에 의해서 만들어 진다. 리눅스는 '충분히 많은 사람이 있다면, 찾을 수 없는 버그란 없다'라는 생각으로 만들어 졌다. 그러면서, 리눅스 아카이브 사이트가 이것을 시장 같은 개발 모습을 보여준다 

Open Source 프로젝트도 처음 부터 시장 방식으로 개발할 수 없다는 것은 자명하다. 테스트, 디버깅, 그리고 개선은 시장 방식으로 할 수 있다. 개발자 공동체는 초기에 실행하고 테스트할 수 있는 장난감이 필요하다. 초기에 해야 할 것은 잠재적인 공동 개발자들에게 이것이 머지 않은 미래에 정말 괜찮은 무언가로 진화할 수 있다는 것을 이해 시키는 일이다

격언들

저자도 fetchmail이라는 Open소스를 만들면서, 시장 모델을 도입하였고, 거기서 발견한 격언들을 아래와 같이 정리하였다.

1. 모든 좋은 소프트웨어는 개발자 개인의 가려운 곳을 긁는 것으로 부터 시작된다.
2. 좋은 프로그래머는 어떤 프로그램을 만들어야 할지 안다. 위대한 프로그래머는 어떤 프로그램을 다시 만들어야 할지 그리고 재사용해야 할지 안다.
3. '갖고 있는 것을 버릴 계획을 세우라. 언젠가는 버리게 될 것이다." (프레더릭 브룩스, "맨먼스 미신" 11장 중에서)
4. 절절한 태도를 갖고 있으면, 흥미로운 문제가 당신을 찾아갈 것이다.
5. 프로그램에 흥미를 잃었다면, 프로그램에 댛나 당신의 마지막 의무는 능력있는 후임자에게 프로그램을 넘겨주는 것이다.
6. 사용자를 공동개발자로 생각하면 코드가 다른 어떤 방법보다 빠른 속도로 개선되며 효율적으로 디버깅할 수 있다.
7. 일찍 발표하고 자주 발표하라. 그리고 사용자의 소리에 귀를 기울여라.
8. 충분하게 많은 베타 테스터와 공동 개발자가 있으면, 거의 모든 문제는 빠르게 파악될 것이고 쉽게 고치는 사람이 있게 마련이다. ('보는 눈이 충분하게 많으면, 찾지 못할 버그는 없다.' - "Linus's Law")
9. 자료구조를 훌륭하게 만들고 코드를 멍청하게 만드는 것이 그 반대 경우보다 훨씬 잘 작동한다.
10. 베타 테스터를 가장 종요한 자원으로 여긴다면 그들은 정말 가장 중요한 자원이 되어 준다.
11. 좋은 아이디어를 생각해 내는 것 다음으로 중요한 일은 사용자가 알려준 좋은 아이디어를 깨닫는 것이다. 때로는 이편이 나을 수도 있다.
12. 종종 가장 충격적이고 혁신적인 해결 책은, 당신 자신이 문제에 대해서 가지고 있는 개념이 잘못돼 있다는 것을 깨닫는 것에서 나온다.
13. "설계에서 완벽함이란 더 이상 추가할 것이 없을 때 이루어지는 것이 아니라 더 이상 버릴 것이 없을 때 이루어진다."
14. 어떤 도구든지 기대하는 방법으로 쓸모가 있어야 하지만 정말 위대한 도구는 사용자가 전혀 기대하지 않았떤 용도에 알맞게 된다.
15. 어떤 종류든 게이트웨어 소프트웨어를 만들려고 한다면 데이터 스트림에 가능한 한 최소의  조작만 가하라. 그리고 수신자가 강제로 하게  하지 않는다면 정보를 '절대로' 잘라 버리지 마라.
16. 언어가 '튜링-완전(Turing-complete)'하지 않다면 구문상의 유연성이 필요하다.
17. 보안 시스템은 그것이 보호하려는 비밀만큼만 안전하다 가짜 비밀에 주의 하라
18. 재미있는 문제를 풀어보고 싶다면, 자신에게 재미있는 문제를 찾아 나서는 것부터 시작하라.
19. 개발 조정자가 최소한 인터넷만큼 좋은 매체를 갖고 있으면 강제력을 사용하지 않고 어떻게 이끌어야 할 지 알고 있따면, 한 명보다는 여러 명의 지도자가 필연적으로 더 낫다.

마치며...

이미 많은 상용 Software도 Open Source를 기반으로 만들어 지고 있고, 위와 같은 시장 모델도 채용하고 있다. 어떤 개발 모델이던지, 그대로 받어 들이는 것 보다는 왜 그런지 어떻게 다르게 할 수 있는지를 고민하면서 채용해야 한다. 결국, 개발 조직이나 개발 프로세스도 이전과는 다르다. Agile이 그 하나이고, 상용 Software에 대한 Beta Testing도 이와 일맥 상통하고 있다.

References

[1] 에릭 레이먼드 지음, 정직한 외 옮김, "성당과 시장", 한빛 미디어

[2] 만화로 나누는 자유/오픈소스 소프트웨어 이야기, http://joone.net/

개요

 

 

 

이와 같은 비유처럼 고객의 요구 사항을 잘 이해하기 위해서 요구 사항 분석(Requirement Analysis)가 Software Engineering의 주요 부분을 차지하고 있다. Architecture Design에서도 이에 필요한 요구 사항 분석을 이야기 한다.

 

요구 사항 분석(Requirement Analysis)

 

이전 글에서도 살펴보았듯이, Architecture Design에서는 기능 요구 사항(Functional Requirement), 품질 요구 사항(Quality Attribute)와 제약 조건(Constraint)를 요구 사항으로 나눌 수 있다[2]. 여기서는 Functional Requirement에 대해서 자세히 살펴 본다.

 

 

Use Case Diagram

Functional Requirement는 Software System이 제공해야 하는 요구 사항으로 크게는 Use Case Diagram으로 표시 될 수 있다. 아래 그림은 [3]에서 예로 보여주는 Use Case Diagram으로 Software System의 경계(Boundary)와 개별 Use Case를 보여 준다.

Structured Language Specification

일반적인 언어로는 요구 사항을 설명하면, 일반적인 언의의 특징 상 모호성이 증가한다. 그렇기 때문에 이를 줄이기 위해서 Structured Format을 많이 사용한다. 대표적인 예로는 IEEE 830 SRS가 있다. 여기에는 아래와 같은 표[4]로서 요구 사항에 정리해야 하는 항목들을 가지고 있어 이에 따로 요구사항의 모호성을 줄일 수 있다.

상기 내용들이 항상 필요한 것은 아니지만, 위와 같이 기술해야 하는 항목을 요구 사항별로 설명할 수 있다. 다른 형태로는 [5] 아래와 같은 표도 가능하다.

위와 같이 구조화된 양식에 요구 사항을 기술하는 방식으로 자연어(Natural Language)로만 기술하는 것 보다는 모호성을 줄일 수 있는 효과가 있다.

결론

여기서는 기능적 요구 사항에 대해서 분석하였다. 이는 Use Case로 표시 되기도 하고 상세 내용은 Structured Language Specification으로 기술 될 수 있다. 이렇게 하는 이유는 고객 혹은 다른 Stakeholder들이 가지고 있는 요구 사항이 모호하기 때문에 이를 좀 더 명확하게 하기 위한 목적이 있다. 

요구 사항에는 이 뿐 아니라, 품질에 대한 요구 사항(Quality Attribute)들도 중요하다. Quality Attribute들은 Stake Holder들에게서 주어질 수도 있고 Business Goal과 연계될 수도 있다. 이는 Architecture Design을 수행하면서 혹은 추가 혹은 우선 순위가 바뀔 수 있다. 이와 같은 요구 사항들을 가지고 Architecture Design이 수행 될 수 있다는 것은 다른 글로 설명하였다. 

References

개요

Architecture와 요구 사항(Requirement)

Software System의 요구 사항(Requirement)은 텍스트 요구 사항(Textual Requirement), 모형(Mockup), 기존 시스템(Existing System), 유즈 케이스(Use Case), 유저 스토리(User Story) 등 다양한 형태로 제공된다. 요구 사항이 어디서 왔든 상관없이 모두 다음과 같이 구분된다. [1]

1. 기능 요구 사항(Functional Requirement FR): 이러한 요구 사항은 시스템이 수행해야하는 작업과 런타임 자극에 어떻게 반응하거나 반응해야 하는지를 설명합니다.

2. 품질 속성 요구 사항(Quality Attribute Requirement, QA): 이러한 요구 사항은 기능 요구 사항(FR) 또는 전체 제품에 대한 자격 확인(Qualification)이다. 기능 요구 사항의 자격은 기능이 얼마나 빨리 수행되어야하는지, 오류 입력에 대해 얼마나 탄력적이어야하는지 등의 항목입니다. 전체 제품의 자격은 제품을 배포하는 데 걸리는 시간 또는 운영 비용의 제한과 같은 항목입니다.

3. 제약 조건(Constraint): 이는 자유도가 0 인 설계 결정이다. 즉, 이미 결정이 나 있는 디자인 결정이다. 예를 들어, 특정 프로그래밍 언어를 사용하거나 특정 기존 모듈을 재사용하거나 시스템 서비스가 기반으로 해야 하는 경영층의 지시를 포함한다. 이러한 선택은 아마도 건축가의 관점에서 볼 수 있지만, 새로운 언어로 직원을 양성 할 수 없거나, 소프트웨어 공급 업체와 비즈니스 계약을 맺었거나, 서비스 상호 운용성이라는 비즈니스 목표를 추진할 수 밖에 없는 등의 광범위한 요인으로 인해 이러한 설계 결과를 강제하게 된다.

 

[2]에서는 이러한 Requirement들을 Architectural Driver로 이야기 하고 있다. 그리고 이런 것들이 결국 Architecture에 영향을 미친다고 볼 수 있다.

 

 

 

 

이러한 종류의 요구 사항 각각에 대한 아키텍처의 "대응"은 무엇인가?

1. 기능 요구 사항(Functional Requirement)은 설계 전반에 걸쳐 적절한 책임(Responsibility)을 순차적으로 부여함으로써 만족된다. 즉, 아키텍처 요소에 책임을 할당하는 것은 아키텍처 설계의 기본적인 결정이다.

2. 품질 속성(Quality Attribute) 요구 사항은 아키텍처에 설계된 다양한 구조와 해당 구조를 채우는 요소의 동작 및 상호 작용에 의해 충족됩니다. 

3. 설계 결정(Design Decision)을 수락하고 영향을받는 다른 설계 결정(Design Decision)과 조화를 이루면 제약 조건(Constraint)이 충족됩니다.

Architectural Significant Requirement

어떤 요구 사항은 다른 것보다 Architecture에 훨씬 더 큰 영향을 미친다. 이러한 구조적 중요 요구 사항 (Architecturally Significant Requirement, ASR)은 이와 같이 아키텍처에 큰 영향을 주는 요구 사항이다. ASR을 모른다면 성공적인 아키텍처를 설계 할 수는 없다. ASR은 아키텍처가 시스템에 제공해야하는 품질 속성(Quality Attribute) 요구 사항의 형태를 취한다. Architecture에 사용할 패턴(Architecture Pattern, Architecture Style) 또는 전술(Tactics)을 선택할 때마다 품질 속성(Quality Attribute) 요구 사항을 충족해야하므로 Architecture가 변경됩니다. 그러므로 QA 요구 사항이 더 어렵고 중요할수록 아키텍처에 큰 영향을 미쳐 ASR이 될 가능성이 커진다. 다음은 ASR을 추출하는 방법들이다[2]. 필요한 경우, 이후에 상세히 살펴 보도록 한다.

• Requirement 문서에서 ASR을 추출
• Stakeholder 인터뷰를 통해 ASR을 추출
• 비즈니스 목표(Business Goals) 이해를 통한 ASR 수집
• Utility Tree를 통한 ASR의 추출
• 여러 방법의 연결

Architecture와 Quality Attribute 

선택된 ASR인 Quality Attribute들과 다른 요구 사항들을 기반으로 Architecture 설계하는 방법을 [2]의 17장에서 설명한다. 이는 아키텍처를 설계하기 위한 전략(Design Strategy)와 이러한 아이디어를 하나로 패키징하는 방법, 즉 속성 중심 설계(Attribute Driven Design, ADD)을 설명한다.

디자인 전략은 아래와 같은 절차를 포함한다

• Decomposition: 충분히 시스템 내의 모듈을 분해 해야 한다. 
• ASR에 대한 설계: 도리어 다른 Requirement들에 영향이 없는지 확인해야 한다.
• 가설(Hypothesis) 생성과 테스트를 통한 확인

속성 중심 설계, ADD는 5 단계 방법이다.

1. 디자인 할 시스템 요소를 선택한다.
2. 선택된 요소에 대한 ASR을 식별한다.
3. 선택한 요소에 대한 설계 솔루션을 생성한다. : 여기서 여러 솔루션들에 대해서 비교가 필요하다.
4. 나머지 요구 사항을 재고하고 다음 반복을위한 입력을 선택한다.
5. 모든 ASR이 충족 될 때까지 1-4 단계를 반복한다.

위의 방법, 특히 ADD는 실재 예를 보면서 이해하는 것이 필요하다. 특히, 위의 절차는 지속적으로 반복하여 요구 되는 요구 사항들과 Quality Attribute들을 만족할 때까지 반복하여 최종 Architecture가 설계 되도록 해야 한다.

마무리 하며...

구조 설계에는 명확한 답이 있어 보이지는 않는다. 하지만, 새로운 방법들이 제안되고 있다. 이런 것들은 추후 검토하고 추가하기로 한다. 예를 들자면, 

ADD 3.0 및 예제 문서들[3]이 그 예이다. 위에 예들을 이해하기 위해서는 예를 많이 살펴 보는 것이 좋고, 그 후에 실재로 설계를 진행해 보는 것이 좋다.

References