맨위로가기

소프트웨어 구성 관리

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

소프트웨어 구성 관리(SCM)는 소프트웨어 개발 과정에서 구성 요소 식별, 제어, 기록, 감사, 빌드 관리, 프로세스 관리, 환경 관리, 팀워크, 결함 추적 등을 통해 효율성과 품질을 향상시키는 것을 목표로 한다. 1950년대 하드웨어 개발에서 시작되어 소프트웨어 개발에 적용되었으며, 초기에는 수작업으로 이루어지다가 소프트웨어의 복잡성이 증가하면서 도구와 방법론이 발전했다. SCM은 다양한 용어로 불리며, ISO/IEC TR 15846:1998과 같은 국제 표준이 존재했으나, 현재는 폐지되었다. 구성 관리 도구는 PUSH형과 PULL형으로 나뉘며, Ansible, Chef, Puppet, Salt 등 다양한 도구가 사용된다.

더 읽어볼만한 페이지

  • 소프트웨어 공학 - 통합 개발 환경
    통합 개발 환경(IDE)은 코드 편집, 빌드, 디버깅 등 소프트웨어 개발에 필요한 여러 기능을 통합적으로 제공하는 응용 프로그램이다.
  • 소프트웨어 공학 - 소프트웨어 개발
    소프트웨어 개발은 요구사항 분석, 설계, 코딩, 테스트, 배포, 유지보수를 포함하는 컴퓨터 프로그램 및 관련 데이터를 만드는 과정으로, 다양한 방법론과 도구가 사용되며, 개발자 외에도 다양한 전문가들이 참여한다.
  • IEEE 표준 - IEEE 754
    IEEE 754는 부동소수점 숫자를 표현하고 처리하기 위한 국제 표준으로, 다양한 형식과 연산, 반올림 규칙, 예외 처리 등을 정의한다.
  • IEEE 표준 - IEEE 802.2
    IEEE 802.2는 데이터 링크 계층의 LLC 서브레이어를 정의하는 IEEE 802 표준의 일부로, 비연결 및 연결 지향 모드를 지원하며, LLC 클래스 I, II, III, IV를 통해 다양한 서비스 유형을 제공하고, DSAP, SSAP 주소 및 제어 필드로 구성된 헤더와 필요에 따라 SNAP 확장을 사용해 네트워크 통신을 관리한다.
소프트웨어 구성 관리
개요
유형소프트웨어 공학
설명소프트웨어 변경을 추적하고 제어하는 프로세스
IEEE 소프트웨어 문서 (소프트웨어 라이프 사이클)
관련 문서소프트웨어 프로젝트 관리
소프트웨어 품질 보증
소프트웨어 요구사항 명세
소프트웨어 구성 관리
소프트웨어 설계 설명
소프트웨어 테스트 문서
소프트웨어 검증 및 확인
소프트웨어 사용자 문서
소프트웨어 검토 및 감사
소프트웨어 개발 프로세스
관련 주제소프트웨어 개발

2. 목적

소프트웨어 구성 관리(SCM)는 소프트웨어 개발 및 유지보수 과정 전반에 걸쳐 다음과 같은 다양한 목표를 추구한다.

목적설명
구성 식별소프트웨어 구성 요소, 구성 항목, 베이스라인을 식별하고 정의한다. 수정해야 할 코드를 명확히 식별한다.
구성 제어변경 관리 프로세스를 구현한다. 변경 제어 위원회를 구성하여 베이스라인에 대한 변경 요청을 승인하거나 거부한다.
구성 상태 기록개발 프로세스 상태에 대한 정보를 기록하고 보고한다. 구성 요소의 상태, 결함 대처 상황, 코드 수정 사항 등을 기록한다.
구성 감사구성 항목이 의도한 부분을 모두 포함하고, 요구사항, 아키텍처 사양, 사용자 설명서 등과 일관성을 유지하는지 검증한다.
빌드 관리빌드에 사용되는 프로세스와 도구를 관리한다.
프로세스 관리조직의 개발 프로세스 준수를 보증하여 개발 효율성과 품질을 향상시킨다.
환경 관리시스템 운영에 필요한 소프트웨어 및 하드웨어 환경을 관리한다.
팀워크팀 간의 상호 작용을 촉진한다.
결함 추적모든 결함의 원인을 추적하고, 코드 수정과 연관시킨다.



클라우드 컴퓨팅과 DevOps의 도입으로 SCM 도구의 목적은 일부 경우에 병합되었다. SCM 도구는 가상 머신으로 인스턴스화하고 상태 및 버전으로 저장할 수 있는 가상 어플라이언스가 되었다. 이 도구는 가상 어플라이언스, 저장 장치 및 소프트웨어 번들을 포함하여 클라우드 기반 가상 리소스를 모델링하고 관리할 수 있다. 개발자가 가상 서버 및 관련 리소스를 동적으로 인스턴스화할 수 있게 되면서 역할과 책임도 병합되었다.[3]

2. 1. 구성 식별

소프트웨어 구성 요소, 구성 항목, 베이스라인을 식별하고 정의한다.[7] 수정해야 할 코드를 명확히 식별하는 작업이 포함된다.

2. 2. 구성 제어

구성 제어는 변경 관리 프로세스를 구현하는 것을 의미한다. 이는 일반적으로 변경 제어 위원회를 구성하여 이루어지는데, 이 위원회는 베이스라인에 대해 제출된 모든 변경 요청을 승인하거나 거부하는 것을 주된 기능으로 한다.[7] 변경 제어 위원회의 심의를 거쳐 승인된 변경 사항만 소프트웨어에 반영되도록 통제함으로써, 소프트웨어의 무결성과 안정성을 유지한다.

2. 3. 구성 상태 기록

개발 프로세스 상태에 필요한 모든 정보를 기록하고 보고한다. 구성 요소의 상태를 기록하고 보고하며, 모든 결함에 대한 대처 상황을 추적 가능하게 하고 코드 수정과 연관시킨다.[7]

2. 4. 구성 감사

구성 감사는 구성 항목이 의도한 모든 부분을 포함하고 있는지, 그리고 요구사항, 아키텍처 사양, 사용자 설명서 등과 일관성을 유지하는지 검증한다.[7]

2. 5. 빌드 관리

소프트웨어 빌드에 사용되는 프로세스와 도구를 관리한다.

2. 6. 프로세스 관리

소프트웨어 구성 관리(SCM)에서 프로세스 관리는 조직의 개발 프로세스 준수를 보증하여 개발 효율성과 품질을 향상시킨다.[7] 이는 조직이 개발 방식을 엄수하도록 돕는다.[3]

2. 7. 환경 관리

시스템을 운영하는데 필요한 소프트웨어 및 하드웨어 환경을 관리한다.[7]

2. 8. 팀워크

소프트웨어 구성 관리 프로세스와 관련한 팀 간의 상호 작용을 촉진한다.[7]

2. 9. 결함 추적

모든 결함의 원인을 추적할 수 있게 하고, 코드 수정과 연관시킨다.[7]

3. 역사

SCM은 본래 하드웨어 개발 및 생산 관리를 위한 구성 관리(CM)에서 유래하여 1950년대 소프트웨어 개발에 적용되기 시작했다.[8] 초기에는 수작업으로 관리되었으나, 언어와 소프트웨어의 복잡도가 증가함에 따라 소프트웨어 공학은 일정, 예산, 품질 등의 문제에 직면하게 되었다. 이를 해결하기 위해 수년에 걸쳐 절차와 도구들이 정의되고 확립되었으며, 소프트웨어 변경을 관리하는 시스템으로 발전했다.[8] 이러한 시스템은 개방형 또는 사유형 솔루션(버전 관리 시스템)으로 제공되었다. 컴퓨터 활용 증가와 함께 요구사항 관리, 디자인 변경, 품질 관리 등 더 넓은 범위를 관리하는 시스템들이 등장했으며, 이후 SEI(Software Engineering Institute)의 능력 성숙도 모델 같은 조직 가이드라인을 따르는 도구들이 개발되었다.

다음은 SCM 도구의 발전을 시간 순서대로 정리한 표이다.

시기내용
1950년대 후반 ~ 1960년대 초IBM UPDATE영어
1970년대 초UNIX의 make
1970년CDC update영어
1972년경벨 연구소의 논문에서 원래의 diff 알고리즘 소개
197x년Pansophic의 PANVALET영어 (메인프레임용 소스 코드 관리 시스템)
1975년SCCS가 C 언어로 재작성되어 UNIX에 대응 (파일 비교에 diff 명령 사용)
1980년대patch (래리 월)
1984년Aide-de-Camp(ADC, 후에 [http://www.mccabe.com/cm.htm TRUEchange]로 개칭, 리처드 하터(Richard Harter))


3. 1. 초기 (1950년대 ~ 1970년대)

컴퓨팅에서 소프트웨어 구성 관리(SCM)의 역사는 본래 하드웨어 개발 및 생산 제어를 위한 구성 관리(Configuration Management, CM)가 소프트웨어 개발에 적용된 1950년대 초로 거슬러 올라간다.[8] 초기 소프트웨어는 카드, 테이프 등의 물리적인 매체에 담겼으며, 최초의 소프트웨어 구성 관리는 수작업이었다.[8]

1960년대 후반부터 1970년대 초, 캘리포니아 대학교 산타바바라의 레온 프레서(Leon Pressor)는 변경 및 구성 제어에 관한 논문을 발표했는데, 이는 미국 해군에 항공기 엔진을 제공하던 군수 기업으로부터 위탁받은 연구의 일환이었다. 1972년, 벨 연구소의 마크 로크킨드(Marc Rochkind)는 OS/360 상의 SNOBOL 언어로 SCCS를 개발했다.

3. 2. 발전기 (1970년대 ~ 1990년대)

1950년대 후반 ~ 1960년대 초 IBM UPDATE영어가 등장한 이후, 소프트웨어 구성 관리(SCM) 도구들이 발전하기 시작했다. 1960년대 후반 ~ 1970년대 초, 캘리포니아 대학교 산타바바라의 레온 프레서(Leon Pressor)는 미국 해군에 항공기 엔진을 제공하던 군수 기업의 위탁을 받아 변경 및 구성 제어에 관한 논문을 발표했다.[8]

1975년, 프레서의 연구 성과를 바탕으로 SoftTool사에서 상용 제품인 change and configuration control영어(CCC)가 출시되었다.[8] 1980년대에는 RCS(발터 티히(Walter Tichy))가 개발되어 현재 GNU 프로젝트의 일부로 제공되고 있다.[8] 1986년에는 협업 개발을 지원하는 CVS가 등장했다.[8]

3. 3. 현대 (2000년대 이후)

2000년대 초, 비트키퍼나 arch와 같은 분산 버전 관리 시스템이 실용적인 수준으로 발전했다.[8]

4. 용어

SCM은 다양한 용어로 표현되며, 시스템 및 표준에 따라 차이가 있고 논쟁의 대상이 되기도 한다. 연구자나 툴 벤더들은 고객을 묶어두기 위해 고의로 다른 용어를 사용하거나, 두문자어의 의미를 다른 단어의 약자로 사용하기도 한다.


  • software configuration management영어: IBM의 일부가 된 래셔널(이전에는 Atria)이 사용하던 용어이다.
  • software change and configuration management영어 (SCCM): 가트너에서의 용어이다. 변경 관리를 포함한 광의의 소프트웨어 구성 관리를 가리킨다고도 생각할 수 있다.
  • source configuration management영어
  • revision control영어
  • version control영어 (버전 관리 시스템)
  • source control영어

4. 1. 주요 용어

소프트웨어 구성 관리(SCM)를 의미하는 용어는 매우 다양하며 시스템에 따라 다르고, 논쟁의 대상이 되기도 한다. 연구자나 툴 벤더들이 고객을 묶어두기 위해 고의로 다른 용어를 사용하거나, 두문자어의 의미를 다른 단어의 약자로 사용하기도 한다.

  • software configuration management영어: 현재는 IBM의 일부가 된 래셔널 (더 이전에는 Atria)이 사용하던 용어이다.
  • software change and configuration management영어 (SCCM): 가트너에서의 용어이다. 단, 단순히 변경 관리를 포함한 광의의 소프트웨어 구성 관리를 가리킨다고도 생각할 수 있다.
  • source configuration management영어
  • revision control영어
  • version control영어 (버전 관리 시스템)
  • source control영어


국제 표준에서는 ISO/IEC TR 15846:1998 Information technology -- Software life cycle processes -- Configuration Management가 표준 기술 문서(technical report)로 1998년에 발행되었다. 하지만 사용 후, 2007년에 폐지되었다. 군 관련 소프트웨어 개발 부문에서의 이용은 있었지만, 다른 분야에서는 너무 상세하여 맞춤(tailoring)의 출발점으로는 너무 무겁다는 배경이 있었다.

4. 2. 국제 표준

국제 표준에서는 ISO/IEC TR 15846:1998 Information technology -- Software life cycle processes -- Configuration Management영어가 1998년에 표준 기술 문서(technical report)로 발행되었다. 하지만 사용 후, 2007년에 폐지되었다. 군 관련 소프트웨어 개발 부문에서의 이용은 있었지만, 다른 분야에서는 너무 상세하여 맞춤(tailoring)의 출발점으로는 너무 무겁다는 배경이 있었다.

5. 구성 관리 도구

구성 관리 도구는 작동 방식에 따라 "PUSH형"과 "PULL형"으로 구분된다. PUSH형은 도구에서 장비로 설정을 수행하며, 장비에 에이전트라 불리는 특별한 프로그램이 없어도 된다(에이전트리스). PULL형은 장비가 도구에서 정보를 가져와 자체 설정을 수행하며, 에이전트가 필요하다.[1]

5. 1. PUSH형

PUSH형은 구성 관리 도구에서 장비로 설정을 수행하는 방식이다. 장비 측에 에이전트라고 불리는 특별한 프로그램을 필요로 하지 않고 작동(에이전트리스)하므로, 지원 대상 장비가 제한되기 어렵다는 장점이 있다.[1]

5. 2. PULL형

PULL형은 "설정 대상 장비가 소프트웨어 구성 관리 도구에서 정보를 가져와 자체 설정을 수행"하는 방식이다. 장비 측에 구성 관리 도구와 통신하는 "에이전트"가 필요하기 때문에, 에이전트가 작동하지 않는 장비는 지원되지 않는다. 또한, 에이전트 기능을 외부 서버에서 실행하고, 외부 서버에서 대상 장비에 PUSH형으로 설정을 수행하는 "외부 에이전트" 방식도 있다.

6. 주요 SCM 도구 (예시)


  • Ansible
  • CFEngine
  • Chef
  • LCFG
  • NixOS
  • OpenMake Software
  • Otter
  • Puppet
  • Salt
  • Rex

참조

[1] 기타 Gartner and Forrester Research
[2] 서적 Software Engineering: A Practitioner's Approach McGraw-Hill
[3] 간행물 Develop cloud applications with Rational tools https://www.ibm.com/[...] IBM 2012-06-05
[4] 기타 Atria (later Rational Software, now a part of IBM)
[5] 서적 Software Engineering: A Practitioner's Approach McGraw-Hill
[6] 기타 Gartner and Forrester Research
[7] 간행물 Develop cloud applications with Rational tools https://www.ibm.com/[...] IBM 2012-06-05
[8] 서적 A Guide to Understanding Configuration Management in Trusted Systems https://books.google[...] National Computer Security System 1988


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com