이 문서는 소프트웨어 아키텍처, 컴포넌트, 그리고 재사용의 역사와 발전을 다루며, 특히 과거의 실패로부터 교훈을 얻어 더 나은 소프트웨어 개발 방법론을 모색하는 데 중점을 둡니다. 소프트웨어 컴포넌트와 아키텍처가 객체 지향 시스템및 비즈니스 애플리케이션개발의 핵심으로 부상하는 과정에서 도메인별 소프트웨어 아키텍처(DSSA)와 패턴의 중요성을 강조하고 있습니다.
- 소프트웨어 아키텍처의 소개와 역사 ( ) 소프트웨어 구성요소와 아키텍처는 객체지향 시스템과 비즈니스 애플리케이션개발에 중요한 역할을 함.
약 30년간의 역사 속에서 재사용과 컴포넌트 기술이 발전해 왔으며, 과거의 실수와 성공 사례를 통해 교훈을 얻는 것이 중요함.
1990년대 후반, 비즈니스 정보 시스템의 성장으로 소프트웨어 아키텍처에 대한 관심이 다시 높아졌으며, 기술 발전과 함께 더 나은 해결책이 등장하고 있음.
소프트웨어 아키텍처는 시스템의 높은 수준의 추상화로, 여러 구성요소와 그 상호작용을 설명하는 것임.
1960년대부터 시스템 크기가 커지면서 구조적 설명과 추상화가 자연스럽게 필요하게 되었으며, 군사 프로젝트 등에서는 여러 계층의 설명이 강제됨.
1976년 DeRemer와 Kron은 “대규모 프로그래밍”과 “소규모 프로그래밍”을 구분하며, 시스템을 두 수준에서 설명하는 방법을 제시함.
1980년대에 들어서면서 소프트웨어 아키텍처라는 개념이 본격적으로 자리 잡기 시작했고, Shaw와 Garlan의 저서가 중요한 역할을 함.
소프트웨어 아키텍처의 핵심은, 높은 수준에서 시스템을 여러 독립된 요소와 그 연결, 상호작용으로 설명하는 것임.
- 재사용 가능한 컴포넌트의 발전과 의미 ( ) 1968년, 소프트웨어의 복잡성과 관리 어려움을 해결하기 위해 컴포넌트와 재사용 개념이 처음 등장함.
Doug McIlroy는 소프트웨어 컴포넌트개념을 제시했으며, 이는 이후 시스템을 조립하는 유용한 조각으로 발전함.
1970년대에는 구조적 방법론과 함께 유럽에서는 설계 중심의 연구가 진행됨.
미국에서는 DRACO 프로젝트(1970년대 후반)가 최초의 재사용 프로젝트로, 컴포넌트, 추상 계층, 도메인 분석개념이 도입됨.
1980년대에는 산업적 재사용이 본격화되었으며, Peter Wegner는 소프트웨어 개발을 자본 집약적 산업으로 보고 재사용의 중요성을 강조함.
Cox는 “소프트웨어 집적회로”라는 개념을 도입하여, 플러그 앤 플레이 방식의 소프트웨어 컴포넌트를 제시함.
컴포넌트는 인터페이스(필수, 제공)로 구분되며, 텍스트 또는 도면으로 표현 가능함.
1980년대 후반, 산업계에서는 재사용을 위한 기술적, 조직적 방법이 활발히 연구됨.
그러나, 기술적 진전만으로는 충분하지 않으며, 재사용 성공을 위해 도메인 집중, 작은 라이브러리, 효과적 검색 시스템이 필요함.
- 컴포넌트 재사용의 도전과 교훈 ( ) 재사용은 특정 도메인에 집중하는 것이 효과적임이 증명됨.
예를 들어, HP는 100개 정도의 컴포넌트로 전화 교환 시스템을 성공적으로 개발했으며, 이는 큰 라이브러리보다 작은 도메인에 집중하는 전략이 유리함을 보여줌.
도메인 분석은 개발자가 어떤 소프트웨어를 만들어야 하는지 이해하는 데 도움을 주며, 외부 지식을 문서화하는 방식으로 지식 의존도를 낮춤.
그러나, 재사용 실패의 원인 중 하나는 인간의 저항으로, 개발자들이 기존 소프트웨어를 사용하는 것보다 새로 만드는 것을 선호하는 경향이 있음.
또한, 재사용을 위한 조직적 지원과 인센티브가 필요하며, 유럽과 미국 간의 접근법 차이도 존재함.
성공적인 재사용을 위해서는 기술적 방법뿐 아니라, 조직적, 관리적 해결책도 병행되어야 함.
- 재사용 전략과 도전 과제 ( ) 재사용을 위해서는 도메인에 맞는 컴포넌트 선정과, 효과적인 라이브러리 관리가 중요함.
작은 라이브러리(약 100개 내외)는 기억하기 쉽고, 검색이 간단하여 실용적임.
도메인 분석은 소프트웨어 개발의 핵심이며, 이를 통해 특정 도메인에 적합한 컴포넌트를 선정하고 재사용 가능성을 높임.
다양한 언어와 형식을 통해 컴포넌트와 연결 방식을 표준화하려는 시도들이 있었으며, 예를 들어 LIL, Pi와 같은 언어들이 개발됨.
컴포넌트 검색을 위한 키워드 기반 분류와 계층적 조직이 일반적이나, 이 역시 완전한 해결책은 아님.
기능적 표현을 수학적으로 나타내려는 시도도 있었지만, 일반적인 매칭 알고리즘의 부재로 어려움이 존재함.
기술적 진전에도 불구하고, 재사용 성공은 도메인 이해, 조직 지원, 인간 저항 극복 등 복합적 요인에 달림.
- 현재와 미래의 발전 방향 ( ) 1990년대 이후, 디자인 패턴이 널리 확산되면서 재사용 경험을 체계화하는 방법이 발전함.
패턴은 반복되는 문제와 해결책을 기록하여, 경험을 공유하는 수단으로 활용됨.
패턴은 작은 문제 해결에 초점을 맞추며, 경험적 지식을 명시하는 역할을 함.
패턴과 프레임워크의 차이점은, 프레임워크는 특정 도메인 전체 해결책을 기록하는 반면, 패턴은 작은 문제와 해결책을 기록함.
1990년대 후반, 객체지향과 비즈니스 컴포넌트의 부상으로, CORBA와 같은 분산 기술이 등장함.
현재 개발은 실시간 시스템 경험을 바탕으로 한 산업별 애플리케이션 아키텍처와 산업 모델로 확장되고 있음.
산업별 아키텍처는 특정 산업의 요구를 반영하며, 성공 사례도 보고되고 있음.
소프트웨어 아키텍처연구는, 컴포넌트와 그 연결(‘글루’), 분산 객체, 설계 방법론 등을 포함하는 포괄적 모델 개발로 나아가고 있음.
이와 함께, 아키텍처의 반복적 평가와 개선, 사례 연구를 통한 실용적 접근이 강조됨.
마지막으로, 산업 현장에서의 경험과 교훈을 바탕으로, 재사용과 아키텍처의 실용적 적용이 계속 발전하고 있음.
소프트웨어 아키텍처와 재사용 가능한 컴포넌트: 과거, 현재, 그리고 미래
1. 소프트웨어 아키텍처, 왜 지금 다시 중요해졌을까요?
소프트웨어 개발 분야에서 소프트웨어 아키텍처와 컴포넌트 개념이 다시 주목받고 있어요. 마치 오래된 유행이 다시 돌아오듯이, 이 아이디어들은 약 30년의 역사를 가지고 있답니다 . 특히 1990년대 후반부터 소프트웨어 아키텍처가 매우 중요해졌는데, 이는 객체 지향 시스템과 비즈니스 애플리케이션개발에 필요성이 커졌기 때문이에요 . 물론 과거에도 비슷한 문제들을 겪었지만, 그때 얻었던 교훈과 발전된 기술 덕분에 이번에는 더 나은 해결책을 찾을 수 있을 것으로 기대하고 있답니다 .
2. 소프트웨어 아키텍처의 탄생과 발전: 그림일기에서 설계도로
| 연도/기간 | 주요 개념/사건 | 설명 |
| 1960년대 | 소프트웨어 아키텍처의 시작 | 소프트웨어 공학의 시작과 함께 존재. 시스템이 작아 추상적인 다이어그램으로 디자인 이해 및 소통. |
| 초기 | 다이어그램의 역할 | 처음에는 ‘벽에 붙여놓는 영감을 주는 장식’에 불과. |
| 시스템 성장 | 다이어그램의 중요성 변화 | 시스템이 커지면서 유지보수를 위해 필수적인 요소가 됨. |
| 1976년 | ”프로그래밍 인 더 라지” 등장 | 아키텍처 수준의 설명이 가능해짐. |
| 1980년대 | ’소프트웨어 아키텍처’ 용어 확산 | 용어가 널리 쓰이기 시작함. |
| 핵심 개념 | 소프트웨어 아키텍처의 정의 | 소프트웨어를 독립적인 요소들과 그 연결 및 상호작용으로 설명. |
소프트웨어 아키텍처는 사실 소프트웨어 공학이 시작된 1960년대부터 존재했어요 . 당시에는 시스템이 작아서 설계자들이 디자인을 이해하고 다른 사람들과 소통하기 위해 추상적인 다이어그램을 그리곤 했죠 . 마치 건축가가 건물을 짓기 전에 설계도를 그리는 것처럼요. 초기에는 이 다이어그램들이 ‘벽에 붙여놓는 영감을 주는 장식’에 불과했지만 , 시스템이 점점 커지면서 유지보수를 위해 필수적인 요소가 되었어요 . 1976년에는 “프로그래밍 인 더 라지(programming in the large)“라는 개념이 등장하면서 아키텍처 수준의 설명이 가능해졌고 , 1980년대에는 ’ 소프트웨어 아키텍처’라는 용어가 널리 쓰이기 시작했답니다 . 핵심은 소프트웨어를 독립적인 요소들과 그 연결 및 상호작용으로 설명하는 것이에요 .
3. 재사용 가능한 컴포넌트: 레고 블록처럼 조립하는 소프트웨어
| 연도 | 주요 내용/개념 | 관련 인물/프로젝트 | 비고 |
| 1968년 | 소프트웨어 관리의 어려움으로 재사용 및 컴포넌트 아이디어 등장 | 소프트웨어 공학 컨퍼런스 | 소프트웨어 재사용 논의의 시작 |
| 1970년대 | 컴포넌트, 추상화, 도메인 분석 개념 도입 | DRACO 프로젝트 | - |
| 1980년대 중반 | 소프트웨어 개발의 산업화 논의 활발 | - | - |
| - | 소프트웨어 컴포넌트를 “소프트웨어 집적 회로(ICs)“로 비유 | Brad Cox | 레고 블록처럼 끼웠다 뺐다 할 수 있음을 강조 |
| - | 컴포넌트는 인터페이스를 통해 연결되며 텍스트로 정의 가능 | - | - |
| - | 컴포넌트를 라이브러리에 모아 재사용하는 프로세스 시도 | - | 기술적 접근 방식은 실패로 끝남 |
1968년 소프트웨어 공학 컨퍼런스에서 소프트웨어 관리가 너무 어려워지자, 재사용과 컴포넌트라는 아이디어가 처음 나왔어요 . McIlroy는 마치 수학 라이브러리처럼 유틸리티 라이브러리 형태의 컴포넌트를 이야기했죠 . 1970년대에는 DRACO 프로젝트에서 컴포넌트, 추상화, 도메인 분석개념이 도입되었고 , 1980년대 중반에는 소프트웨어 개발을 산업처럼 만들자는 논의가 활발해졌어요 . 특히 Brad Cox는 소프트웨어 컴포넌트를 마치 끼웠다 뺐다 할 수 있는 레고 블록과 같은 “소프트웨어 집적 회로(ICs)“라고 비유하며 설명했답니다 . 컴포넌트는 인터페이스를 통해 서로 연결되며 , 텍스트로도 정의할 수 있어요 . 이렇게 만들어진 컴포넌트를 라이브러리에 모아두고 필요할 때 꺼내 쓰는 재사용 프로세스도 있었지만 , 안타깝게도 이런 기술적 접근 방식은 실패로 끝났어요 .
4. 재사용의 성공 비결: 좁은 도메인에 집중하고 사람을 이해하기
소프트웨어 재사용이 성공하기 위해서는 좁은 도메인(특정 애플리케이션 영역)에 집중하는 것이 중요해요 . 예를 들어, HP는 100개 정도의 소규모 컴포넌트로 전화 교환 시스템에서 재사용에 성공했지만 , 4000개가 넘는 일반적인 컴포넌트를 모은 대규모 라이브러리는 실패했거든요 . 즉, 무조건 많이 모으기보다는 해당 도메인에서 정말 유용한 컴포넌트만 모으는 것이 핵심이에요 . 또한, 재사용 실패에는 기술 외적인 이유도 있었어요 . 소프트웨어 엔지니어들은 새로운 것을 만드는 것을 좋아하고 , 다른 사람이 만든 소프트웨어를 잘 믿지 않으려는 경향이 있었거든요 . 게다가 재사용을 위한 소프트웨어 개발에 대한 인센티브가 부족했죠 . 이런 문제들은 기술이 아닌 관리적인 해결책이 필요하며 , 요즘에는 많은 회사들이 컴포넌트 라이브러리를 만들고 기여 및 사용에 대한 인센티브를 제공하고 있답니다 .
5. 미래를 위한 아키텍처: 도메인 특화 아키텍처와 패턴
컴포넌트만으로는 충분하지 않고, 어떤 도메인에서 어떻게 사용할지 그리고 관리 프로세스까지 함께 고려해야 해요 . 이러한 아이디어는 **도메인 특화 소프트웨어 아키텍처(DSSA)**로 이어졌어요 . DSSA는 특정 도메인에서 만들 수 있는 모든 애플리케이션을 아우르는 추상적인 요구사항을 식별하고, 문제 해결을 위한 아키텍처와 컴포넌트 컬렉션을 포함한답니다 . 또한, 컴포넌트를 위한 정형화된 아키텍처인 프레임워크도 중요한 개념이에요 . 1990년대 초반부터는 디자인 패턴이 크게 주목받았는데 , 이는 공통적으로 발생하는 문제에 대한 재사용 가능한 경험과 해결책을 제공해준답니다 . 패턴과 프레임워크는 다르지만 , 패턴은 새로운 프레임워크개발에 큰 도움이 될 수 있어요 . 결국 이 모든 논의는 견고한 컴포넌트 모델과 아키텍처의 중요성을 강조하며, 앞으로의 소프트웨어 개발 방향을 제시하고 있답니다 .