본문 바로가기

정보처리기사/2과목 소프트웨어 개발

[정보처리기사] Chapter 03. 소프트웨어 개발: 제품 소프트웨어 패키징

1. 소프트웨어 패키징 (중요도: B)

 소프트웨어 패키징이란 모듈별로 생성한 실행 파일들을 묶어 배포용 설치 파일을 만드는 것을 말한다. 소스 코드는 향후 관리를 고려해 모듈화하여 패키징하며, 다양한 환경에서 소프트웨어를 손쉽게 사용할 수 있도록 일반적인 배포 형태로 패키징한다. 사용자의 편의성 및 실행 환경을 우선적으로 고려해야 하며, 따라서 개발자가 아닌 사용자 중심으로 패키징을 진행해야 한다.

 

1.1. 패키징 시 고려사항

 사용자의 시스템 환경, 즉 OS, CPU, 메모리 등에 필요한 최소 환경을 정의한다. UI는 시각적인 자료와 함께 제공하고 매뉴얼과 일치시켜 패키징한다. 

 소프트웨어를 패키징해 배포한 이후, 하드웨어와 함께 관리될 수 있도록 Managed Service (고객이 사용 중인 소프트웨어를 24시간 모니터링하면서 문제 발생시 대처 ) 형태로 제공하는 것이 좋으며, 패키징의 변경 및 개선에 대한 관리를 항상 고려해야 한다. 또한 고객의 편의성을 고려한 안정적인 배포가 중요하다.

 

1.2. 패키징 작업 순서 (기능 식별 → …. → 배포)

기능 식별

작성된 코드의 기능을 확인한다.

모듈화

확인된 기능 단위로 코드들을 분류한다.

빌드 진행

모듈 단위별로 실행 파일을 만든다.

사용자 환경 분석

웹, 모바일, PC 등 소프트웨어가 사용될 환경이나 운영체제, CPU, RAM등의 최소 운영 환경을 정의한다.

패키징 및 

적용 시험

빌드된 실행 파일들을 정의된 환경에 맞게 배포용 파일 형식으로 패키징한다. 

정의된 환경과 옹일한 환경에서 패키징 결과를 테스팅한 후 소프트웨어에 대한 불편사항을 사용자 입장에서 확인한다.

패키징 변경 개선

확인된 불편 사항을 반영하기 위한 패키징의 변경 및 개선을 진행한다.

배포

배포 수행 시 오류가 발생하면 해당 개발자에게 전달하여 수정을 요구한다. 

 

 패키징 주기는 소프트웨어 개발 기법에 따라 달라지는데, 짧은 주기의 애자일의 경우 2~4주 내로 패키징 주기를 지정한다. 일반적으로 각 주기가 끝날 때마다 패키징을 수행하고 테스트 및 개선 후에 배포를 진행한다. 

 

*패키징을 진행하는 목적이 배포에 있기 때문에, 개발 주기가 빠른 애자일의 경우, 예측되는 날짜를 기준으로 설정이 가능한 것이다.

 

 


2. 릴리즈 노트 작성 (중요도: B)

 릴리즈 노트(Release Note)는 개발 과정에서 정리된 릴리즈(개발이 완성된 소프트웨어를 출시, 배포하는 것 ) 정보를 소프트웨어의 최종 사용자인 고객과 공유하기 위한 문서이다.

 소프트웨어에 포함된 전체 기능, 서비스의 내용, 개선 사항 등을 사용자와 공유할 수 있고, 테스트 진행 방법에 대한 결과와 소프트웨어 사양에 대한 개발팀의 정확한 준수 여부를 확인할 수 있다.

 소프트웨어의 초기 배포 시 또는 출시 후 개선 사항을 적용한 추가 배포 시에 제공하고, 개발팀에서 제공하는 소프트웨어 사양에 대한 최종 승인까지 얻은 후 문서화 되어 제공된다. 

 릴리즈 노트는 소프트웨어의 버전 관리나 릴리즈 정보를 체계적으로 관리할 수 있다는 장점을 가진다. 

 

2.1. 릴리즈 노트 초기 버전 작성 시 고려사항

 개발 과정에서 정리된 릴리즈 정보를 소프트웨어의 최종 사용자인 고객과 공유하기 위한 문서이다. 테스트 진행 방법에 대한 결과와 소프트웨어 사양에 대한 개발팀의 정확한 준수여부를 확인할 수 있고, 전체 기능, 서비스의 내용, 개선 사항등을 사용자와 공유할 수 있다. 릴리즈 노트에 정리된 정보들은 철저한 테스트를 거친 것이며, 개발팀에서 제공하는 소프트웨어 사양에 대한 최종 승인을 얻은 후 문서화되어 제공된다. 소프트웨어의 초기 배포시 또는 소프트웨어의 업데이트 후 추가 배포시에 제공한다

 소프트웨어 초기 배포시 제공되는 릴리즈 노트에는 소프트웨어에 포함된 기능이나 사용 환경에 대한 내용을 확인할 수 있어야 하고, 출시 후 개선된 내용이 있을 때마다 릴리즈 노트를 갱신하여야 한다. 릴리즈 노트는 소프트웨어의 버전 관리나 릴리즈 정보를 체계적으로 관리 할 수 있다는 장점을 가진다. 

2.2. 릴리즈 노트 추가 버전 작성 시 고려사항

 소프트웨어의 테스트 과정에서 베타 버전이 출시되거나 긴급한 버그 수정, 업그레이드와 같은 자체 기능 향상, 사용자 요청 등의 특수한 상황이 발생하는 경우 릴리즈 노트를 추가로 작성한다.

 중대한 오류가 발생해 긴급하게 수정하는 경우에는 릴리즈 버전을 출시하고, 버그를 포함한 모든 수정 내용을 담는다. 소프트웨어의 기능이 업그레이드 된 경우에는 릴리즈 버전을 출시하고 릴리즈 노트를 작성한다.

 사용자로부터 접수된 요구사항에 의해 추가나 수정된 경우에는 자체 기능 향상과는 다른 별도의 릴리즈 버전으로 출시하고 릴리즈 노트를 작성해야 한다.

 

2.3. 릴리즈 노트 작성 순서

 


3. 디지털 저작권 관리(DRM) (중요도: A)

 저작권은 창작자가 가지는 배타적 독점적 권리로 타인의 침해를 받지 않을 고유한 권한을 말한다. 창작물을 비롯한 대부분의 지적 재산은 저작권을 보장받는데, 인터넷 혹은 소프트웨어를 사용하는 사용자와 개발자 또한 이러한 저작권을 보장받아야 한다. 특히, 컴퓨터 프로그램들과 같이 복제하기 쉬운 저작물에 대해 불법 복제 및 배포 등을 막기 위한 조치가 필요하고 이러한 기술을 저작권 보호 기술이라고 한다. 

 

3.1. 디지털 저작권 관리 (DRM; Digital Right Management) 개요

 저작권자가 배포한 디지털 콘텐츠가 저작권자가 의도한 용도로만 사용되도록 디지털 콘텐츠의 생성, 유통, 이용까지의 전 과정에 걸쳐 사용되는 디지털 콘텐츠 관리 및 보호 기술이다.

 

◍ 원본 콘텐츠가 아날로그인 경우에는 디지털로 변환한 후 패키저(Packager)에 의해 DRM 패키징 (아날로그 → 디지털)을 수행한다.

◍ 콘텐츠의 크기에 따라 크기가 작으면 실시간으로 패키징을 수행하고, 크기가 큰 경우에는 미리 패키징을 수행한 후 배포한다.

◍ 패키징을 수행하면 콘텐츠에는 암호화된 저작권자의 전자서명이 포함되고 저작권자가 설정한 라이선스 정보가 클리어링 하우스(라이선스의 중개발급 하는 곳)에 등록된다.

◍ 사용자가 콘텐츠를 사용하기 위해서는 클리어링 하우스에 등록된 라이선스 정보를 통해 사용자 인증과 콘텐츠 사용 권한 소유 여부를 확인받아야 한다.

◍ 종량제 방식을 적용한 소프트웨어인 경우 클리어링 하우스를 통해 서비스의 실제 사용량을 측정하여 이용한 만큼의 요구를 부과한다.

 

3.2. 디지털 저작권 관리의 흐름도

① 클리어링 하우스(Clearing House) : 저작권에 대한 사용 권한, 라이선스 발급, 사용량에 따른 결제 관리 등을 수행하는 곳

② 콘텐츠 제공자(Contents Provider) : 콘텐츠를 제공하는 저작권자

③ 패키저(Packager) : 콘텐츠를 메타 데이터(데이터에 대한 데이터, 즉 데이터에 대한 속성 정보 등을 설명하기 위한 데이터)와 함께 배포 가능한 형태로 묶어 암호화하는 프로그램

④ 콘텐츠 분배자(Contents Distributor) : 암호화된 콘텐츠를 유통하는 곳이나 사람

⑤ 콘텐츠 소비자(Customer) : 콘텐츠를 구매해서 사용하는 주체

⑥ DRM 컨트롤러(DRM Controller) : 배포된 콘텐츠의 이용 권한을 통제하는 프로그램

⑦ 보안 컨테이너(Security Container) : 콘텐츠 원본을 안전하게 유통하기 위한 전자적 보안 장치

 

3.3. 디지털 저작권 관리의 기술 요소

 디지털 저작권 관리를 위해 사용되는 기술은 다음과 같다.

 

구성요소 

설명 

암호화 (Encryption) 

콘텐츠및 라이선스를 암호화하고 전자 서명을 할 수 있는 기술 

키 관리 (Key Management) 

콘텐츠를 암호화한 키에 대한 저장 및 분배 기술 

암호화 파일 생성 (Packager) 

콘텐츠를 암호화된 콘텐츠로 생성하기 위한 기술

식별 기술 (Identification)

콘텐츠에 대한 식별 체계 표현 기술 

저작권 표현 (Right Expression)  

라이선스의 내용 표현 기술 

정책 관리 (Policy Management )

라이선스 발급 및 사용에 대한 정책 표현 및 관리 기술 

크랙 방지 (Tamper Resistance)

크랙에 의한 콘텐츠 사용 방지 기술 

인증 (Authentication) 

라이선스 발급 및 사용의 기준이 되는 사용자 인증 기술 

 


4. 소프트웨어 설치 매뉴얼 작성 (중요도:C)

 소프트웨어 설치 매뉴얼은 개발 초기에서부터 적용된 기준이나 사용자가 소프트웨어를 설치하는 과정에서 필요한 정보를 기록한 설명서와 안내서이다. 사용자가 설치하기 위한 정보이므로 설치 시작부터 완료 될 때까지의 전 과정을 빠짐없이 순서대로 설명하고, 사용자 기준으로 작성한다. 

 소프트웨어 설치 매뉴얼에는 목차 및 개요, 서문, 기본 사항이 기본적으로 포함되어야 한다. 

 

4.1. 서문

 

서문에는 문서 이력, 설치 매뉴얼의 주석, 설치 도구의 구성, 설치 환경 체크 항목을 기술한다.

 

◍ 설치 매뉴얼의 주석: 주의 사항(SW 설치시 사용자가 반드시 알아야 할 내용)과 참고 사항(설치에 영향을 미칠 수 있는 사용자의 환경 및 상황 내용)을 기술한다.

◍ 설치 도구의 구성: 설치 관련 파일, 설치 과정 및 결과가 기록되는 log 폴더, 폴더 및 설치 프로그램 실행 파일에 대해 설명한다. 

◍ 설치 도구 체크 항목: 사용자 환경(CPU, OS, Memory 등), 응용 프로그램(설치 전 다른 응용 프로그램 종료), 업그레이드 버전(업그레이드 이전 버전에 대한 존재 유무 확인), 백업 폴더 확인(데이터 저장 폴더를 확인하여 설치 시 폴더를 동기화 시킴)

 

4.2. 기본 사항

 소프트웨어와 관련하여 기본적으로 설명되어야 할 항목이다. 

 

◍ 소프트웨어 개요(SW 주요 기능, UI 설명), 설치 관련 파일(파일 확장자 및 설치에 필요한 필수 파일), 설치 아이콘(아이콘 설명), 프로그램 삭제(삭제 방법), 관련 추가 정보(기타 설치 프로그램 정보, 제작사 등의 추가 정보)

 

4.3. 설치 매뉴얼 작성 방법

 설치 매뉴얼은 사용자가 설치 과정을 이해하기 쉽도록 설치 화면을 누락 없이 캡쳐하고 순서대로 상세히 설명한다. 

 

설치 화면 및 UI

설치 실행과 메인 화면 및 안내창에 대한 내용을 기술한다. 

설치 이상 메시지

설치 방법이나 설치 환경이 잘못된 경우 표시될 수 있는 메시지에 대해 설명한다. 

설치 완료 및 결과

설치 완료 화면을 수록하여 설치가 정상적으로 마무리되었음을 사용자에게 최종적으로 알려준다.

FAQ

설치 과정에서 사용자가 직면할 수 있는 문제 상황에 대비할 수 있도록, 설치 시 발생할 수 있는 다양한 상황을 FAQ로 정리하여 수록한다.

설치 시 점검 사항

설치 전 사용자의 설치 환경에 따라 점검해야 할 사항들이 무엇인지 설명한다. 

설치에 필요한 사용자 계정 및 설치 권한에 대해 확인할 수 있도록 설명한다.

Network 환경 및 보안

네트워크 오류로 인해 설치 시 문제가 발생하지 않도록 사전에 필요한 네트워크 연결 상태를 점검하도록 안내한다. 

고객 지원 방법

설치와 관련하여 기술 지원이나 SW에 대한 서비스를 원할 경우, 국가, 웹 사이트, 전화번호, 이메일 등 문의할 수 있는 연락처를 안내한다.

준수 정보 및 제한 보증

Serial 보존, 불법 등록 사용 금지 등에 대한 준수 사항을 안내한다. 

▶ 설치 매뉴얼: Chrome 설치

 

4.4. 설치 매뉴얼 작성 순서

 


5. 소프트웨어 사용자 매뉴얼 작성 (중요도: C)

 소프트웨어 사용자 매뉴얼은 사용자가 소프트웨어를 사용하는 과정에서 필요한 내용을 문서로 기록한 설명서와 안내서이다. 사용자 매뉴얼은 개별적으로 동작이 가능한 컴포넌트(독립적인 업무 또는 기능을 수행하는 단위 ) 단위로 매뉴얼 작성하고, 컴포넌트 명세서(컴포넌트의 개요 및 내부 클래스의 동작, 외부와의 통신 명세등을 정의한 문서 )와 컴포넌트 구현 설계서(컴포넌트 구현에 필요한 컴포넌트 구조도, 목록, 명세, 인터페이스 명세로 구성된 설계서 )를 토대로 작성한다. 

 사용자 매뉴얼에는 목차 및 개요, 서문, 기본 사항 등이 기본적으로 포함되어야 한다. 목차는 매뉴얼의 전체 내용을 순서대로 간략하게 기입하고, 개요는 SW의 특징, 구성과 실행 방법, 사용법, 항목별 점검 기준 등에 대한 내용을 기술한다.

 

5.1. 서문

 서문에는 문서 이력, 사용자 매뉴얼의 주석, 기록 보관을 위해 필요한 내용을 기술한다. 

◍ 사용자 매뉴얼의 주석: 주의 사항과 참고 사항 기술한다.

◍ 기록 보관 내용: 필요한 기술 지원이나 추가 정보를 얻기 위한 소프트웨어의 등록 정보 기술한다.

 

5.2. 기본 사항

 소프트웨어와 관련하여 기본적으로 설명되어야 할 항목들이다. 

◍ 소프트웨어 개요: SW 주요 기능 및 UI 설명한다.

◍ 소프트웨어 사용 환경: SW 사용을 위한 최소 환경 설명한다. 구동되는 PC 사양의 정보와 SW사용 시 발생할 수 있는 프로그램 충돌이나 개인정보, 보안 관련 주의 사항을 알려야 한다.

◍ 소프트웨어 관리: 소프트웨어의 사용 종료 및 관리 등에 관한 내용 설명한다.

◍ 모델, 버전별 특징: 모델 및 버전별로 UI 및 기능의 차이점을 간략하게 요약한다.

◍ 기능, 인터페이스의 특징: 제품의 기능과 인터페이스 특징을 간략하게 요약한다. 

◍ 소프트웨어 구동 환경: 개발에 사용한 언어 및 호환 가능성 운영체제에 대해 설명한다. 

 

5.3. 사용자 매뉴얼 작성 방법

 사용자 매뉴얼은 사용자가 사용 방법을 이해하기 쉽도록 작성해야 한다. 때문에 상황별로 누락 없이 캡쳐하여 순서대로 상세히 설명한다. 

사용자 화면 및 UI

주의 사항과 참고 사항을 기술한다. 

주요 기능 분류

기능이 실행되는 화면을 순서대로 캡쳐하여 기능에 대한 사용법을 설명한다. 또한 기능이 구현되는 과정에서 참고할 사항이나 주의할 사항에 대한 메모를 추가한다.

응용 프로그램 및 설정

SW 구동 시 함께 실행해도 되는 응용 프로그램, 또는 함께 실행하면 안되는 응용 프로그램에 대해 설명한다. 만약 SW 구동될 때 먼저 실행되어야 할 응용 프로그램이 있다면 설명하여야 하며, SW가 정상적으로 구동하기 위한 설정이나 기본값을 고지한다.

장치 연동

SW가 특정 장치에 내장되는 경우 연동되는 장치에 대해 설명한다.

Network 환경

네트워크에 접속되어 사용되는 SW인 경우 정상적인 연결을 위한 설정값 등을 설명한다.

Profile 안내

Profile은 SW 구동 환경을 점검하는 파일로, 사용자가 Profile의 경로를 변경하거나 위치를 이동하지 않도록 안내한다. 

Profile과 같이 SW 구동에 필수적인 파일에 대해 설명한다. 

고객 지원 방법

사용과 관련하여 기술 지원이나 SW에 대한 서비스를 원할 경우, 국가, 웹 사이트, 전화번호, 이메일 등 문의할 수 있는 연락처를 안내한다.

준수 정보 및 제한 보증

Serial 보존, 불법 등록 사용 금지 등에 대한 준수 사항을 안내한다. 저작권자 소유권 정보, SW 허가권 정보, 통신 규격, 개발 언어, 연동 프로그램, 문서 효력, 지적 소유권 정보 등과 관련된 내용을 안내한다.

▶ 사용자 매뉴얼: 충남대학교 APP 사용자 매뉴얼

 

5.4. 사용자 매뉴얼 작성 순서 (기능 식별 → …. → 최종 매뉴얼 적용)

기능 식별

소프트웨어의 개발 목적과 사용자 활용 기능을 흐름 순으로 정리하여 기록

사용자 화면 분류

사용자 화면을 메뉴별로 분류해 기록

사용자 환경 파일 확인

폴더 위치, 사용자 로그 파일 등의 개별적인 기능을 확인해 기록

초기화 절차 확인

프로그램을 사용하기 위한 초기화 절차를 확인, 그 단계를 순서대로 기록

이상 Case 확인

소프트웨어 사용과정에서 발생할 수 있는 다양한 이상 Case를 만들어 확인, 해당 Case에 대한 대처법을 상세히 기록

최종 매뉴얼 적용

사용과 관련된 문의 답변을 정리해 기록/ 완성 매뉴얼 검토 및 고객 지원에 대한 기록

 


6. 소프트웨어 버전 등록 (중요도: B)

6.1. 소프트웨어 패키징의 형상 관리

 형상 관리는 소프트웨어의 개발 과정에서 소프트웨어의 변경 사항을 관리하기 위해 개발된 일련의 활동이다. 소프트웨어 변경의 원인을 알아내고 제어하며, 적절히 변경되었는지 확인하여 해당 담당자에게 통보한다. 

 형상 관리는 소프트웨어 개발의 전 단계에 적용되는 활동이며, 관리를 목적으로 하는 활동이므로 유지보수 단계에서도 수행된다. 

 형상 관리는 개발의 전체 비용을 줄이고, 개발 과정의 여러 방해 요인이 최소화되도록 보증하는 것을 목적으로 한다. 

 

▶ 형상: 소프트웨어 개발 단계의 각 과정에서 만들어지는 프로그램, 프로그램 설명 문서, 데이터 등을 통칭

 

6.2. 형상 관리의 중요성

 지속적인 소프트웨어의 변경사항을 체계적으로 추적하고 통제할 수 있다. 제품 소프트웨어에 대한 무절제한 변경을 방지할 수 있다. 제품 소프트웨어에서 발견된 버그나 수정 사항을 추적할 수 있다. 소프트웨어는 형태가 없어 가시성이 결핍되므로 진행 정도를 확인하기 위한 기준으로 사용될 수 있다.

 

6.3. 형상 관리 기능

 형상 관리는 품질 보증을 위한 중요한 요소로서 다음과 같은 기능을 수행한다. 

 

형상 식별: 관리 대상의 이름과 관리 번호를 부여하고, 계층(Tree)로 구분해 수정 및 추적이 용이하도록 하는 작업이다.

버전 제어: 소프트웨어의 업그레이드와 유지보수 과정에서 생성된 버전의 형상 항목을 관리하고, 이를 위해 특정 절차와 도구를 결합시키는 작업이다.

형상 통제: 식별된 형상 항목에 대한 변경 요구를 검토하여 현재의 기준선이 잘 반영될 수 있도록 조정하는 작업이다.

형상 감사: 기준선의 무결성(결점이 없는 상태, 기준에 만족한 정도)을 평가하기 위해 확인, 검증 과정을 통해 공식적으로 승인하는 작업이다.

형상 기록: 위의 절차에 따른 내용을 기록하고 보고서를 작성하는 작업이다.

 

6.4. 소프트웨어의 버전 등록 관련 주요 용어

저장소(Repository): 최신 버전의 파일들과 변경 내역에 대한 정보들이 저장되어 있는 곳 

가져오기(import): 버전 관리가 되고 있지 않은 아무것도 없는 저장소에 처음으로 파일을 복사

체크아웃(Check-Out): 프로그램을 수정하기 위해 저장소에서 파일을 받아옴, 소스 파일과 함께 버전 관리를 위한 파일들도 받아옴

체크인(Check-In): 체크아웃 한 파일의 수정을 완료한 후 저장소의 파일을 새로운 버전으로 갱신

커밋(Commit): 체크인을 수행할 때 이전에 갱신된 내용이 있는 경우에 충돌을 알리고 diff 도구(비교 대상이 되는 파일 들의 내용을 비교하여 서로 다른 부분을 표시해주는 도구 )를 이용해 수정한 후 갱신을 완료

동기화(Update): 저장소에 있는 최신 버전으로 자신의 작업 공간을 동기화 함

 

6.5. 소프트웨어의 버전 등록 과정

 


7. 소프트웨어 버전 관리 도구 (중요도: A)

7.1. 공유 폴더 방식

 공유 폴더 방식은 버전 관리 자료가 로컬 컴퓨터의 공유 폴더에 저장되어 관리되는 방식이다. 개발이 완료된 파일을 약속된 공유 폴더에 매일 복사하고, 담당자는 컴파일하여 이상 유무를 확인한다. 만약 이상 유무 확인 중 파일의 오류가 확인되면, 해당 파일을 등록한 개발자에게 수정을 의뢰한다.

 파일을 잘못 복사하거나 다른 위치로 복사하는 것에 대비하기 위해 파일의 변경 사항을 데이터베이스에 기록하여 관리한다. 대표적인 종류에는 SCCS, RCS, PRVCS, QVCS가 있다.

 

7.2. 클라이언트/서버 방식

 버전 관리 자료가 중앙 시스템(서버)에 저장되어 관리되는 방식이다. 서버의 자료를 개발자별로 자신의 PC(클라이언트)로 복사하여 작업한 후 변경된 내용을 서버에 반영한다. 

 클라이언트/서버 방식의 버전 관리는 모두 서버에서 수행된다. 때문에 하나의 파일을 서로 다른 개발자가 작업할 경우 경고메시지를 출력한다.

 공유 폴더에 비해 자료 이동이나 삭제가 제한되어 비교적 안정성이 높지만, 서버에 문제가 생기면 서버가 복구되기까지 협업 및 버전 관리 작업이 중단된다는 단점이 있다. 종류에는 CVS, SVN, CVSNT, Clear Case, CMVC, Perforce 등이 있다.

 

7.3. 분산 저장소 방식

 버전 관리 자료가 하나의 원격 저장소와 분산된 개발자 PC의 로컬 저장소에 함께 저장되어 관리되는 방식이다. 개발자 별로 원격 저장소의 자료를 자신의 로컬 저장소로 복사하여 작업한 후 변경된 내용을 로컬저장소에 우선 반영한 다음 이를 원격저장소에 반영한다.  때문에 원격 저장소에 문제가 생겨도 로컬 저장소의 자료를 이용해 작업 할 수 있다.

 종류에는 Git, GNU arch, DCVS, Bazaar, Mercurial, TeamWare, Bitkeeper, Plastic SCM이 있다.

 

7.4. Subversion(서브버전, SVN)

 CVS(공동 개발을 편리하게 작업 할 수 있도록 버전 관리를 도와주는 시스템 )를 개선한 것으로 아파치 소프트웨어 재단에서 2000년에 발표했다. 클라이언트/서버 구조로 최신 버전의 파일들과 변경 내역이 관리된다. 서버의 자료를 클라이언트로 복사해와 작업 한 후 변경 내용을 서버에 반영(Commit)한다. 서버는 주로 유닉스를 사용한다. 

 모든 개발 작업은(trunk{몸통,줄기: 가장 중심이 되는 메인 디렉토리} )에서 수행되며 추가 작업은 branches(서브 디렉토리 ) 안에 별도의 디렉토리를 생성해 작업한 후 trunk 디렉터리와 병합한다. 

 커밋할 때마다 커밋의 버전인 리비전이 1씩 증가한다. (리비전의 초기값은 0이다.) CVS의 단점이었던 파일이나 디렉터리의 이름 변경, 이동 등이 가능하다.

 

 

◍ Subversion의 주요 명령어

▸ add : 새로운 파일이나 디렉터리를 버전 관리 대상으로 등록

▸ commit : 버전 관리 대상으로 등록된 클라이언트의 소스 파일을 서버의 소스 파일에 적용

▸ update : 서버의 최신 commit 이력을 클라이언트의 소스 파일에 적용

▸ checkout : 버전 관리 정보와 소스 파일을 서버에서 클라이언트로 받아옴

▸ lock/unlock : 서버의 소스 파일이나 디렉터리를 잠그거나 해제

▸ Import : 아무것도 없는 서버의 저장소에 맨 처음 소스 파일을 저장

▸ export : 버전 관리에 대한 정보를 제외한 순수한 소스 파일만을 서버에서 받아 옴

▸ info : 지정된 파일에 대한 정보 표시

diff : 지정된 파일이나 경로에 대해 전 리비전과의 차이 표시

▸ merge : 다른 디렉터리에서 작업된 버전 관리 내역을 기본 개발 작업과 병합

 

7.5. Git(깃)

 리누스 토발즈가 2005년 리눅스 커널 개발에 사용할 관리 도구로 개발한 이후 주니오 하마노에 의해 유지보수 되고 있다. 

 Git은 분산 버전 관리시스템으로 2개의 저장소, 로컬 저장소와, 원격 저장소가 존재한다. 원격 저장소는 여러 사람들이 협업을 위해 버전을 고동 관리하는 곳으로, 자신의 버전 관리 내역을 반영하거나 다른 개발자의 변경 내용을 가져올 때 사용한다. 버전 관리가 로컬 저장소에서 진행되므로 버전 관리가 신속하게 처리되고, 원격 저장소나 네트워크에 문제가 있어도 작업이 가능하다. 

 브랜치(토픽 브랜치, 피처 브랜치라고도 하며, Git에 저장되는 기본 관리 영역이다.)를 이용하면 기본 버전 관리 틀에 영향을 주지 않으면서 다양한 형태의 기능 테스팅이 가능하다.

  파일의 변화를 스냅샷(영문자와 숫자가 혼합된 40자리 문자열)으로 저장하는데, 스냅샷은 이전 스냅샷의 포인터를 가지므로 버전의 흐름을 파악할 수 있다. 

 

◍ Git의 주요 명령어

▸ add: 작업 내역을 지역 저장소에 저장하기 전 스테이징 영역에 추가

▸ commit: 작업 내역을 지역 저장소에 저장

▸ branch: 새로운 브랜치 생성

▸ checkout: 지정한 브랜치로 이동

▸ merge: 브랜치 병합

▸ init: 지역 저장소 생성

▸ remote add: 원격 저장소에 연결

▸ push: 로컬 저장소의 변경 내역을 원격 저장소에 반영

▸ fetch: 원격 저장소의 변경 이력만을 지역 저장소로 가져옴

▸ clone: 원격 저장소의 전체 내용을 지역 저장소로 복제

▸ fork: 지정한 원격 저장소의 내용을 자신의 원격 저장소로 복제

▶Git의 자세한 내용: Git 학습 

 

 


8. 빌드 자동화 도구 (중요도: B)

 빌드란 소스 코드 파일들을 컴파일 한 후 여러 개의 모듈을 묶어 실행 파일로 만드는 과정이며, 이러한 빌드를 포함하여 테스트 및 배포를 자동화 하는 도구를 빌드 자동화 도구라고 한다.

 애자일 환경에서는 하나의 작업이 마무리될 때마다 모듈 단위로 나눠서 개발된 코드들이 지속적으로 통합되는데, 이러한 지속적인 통합 개발 환경에서 빌드 자동화 도구는 유용하게 활용된다.

 빌드 자동화 도구에는 Ant, Make, Maven, Gradle, Jenkins등이 있으며, Jenkins와 Gradle이 가장 대표적이다.

 

8.1. Jenkins

 JAVA 기반의 오픈소스 형태로, 가장 많이 사용되는 빌드 자동화 도구이다. 서블릿 컨테이너(서블릿은 데이터 저장 체계인데, 이를 관리하는 영역 )에서 실행되는 서버 기반 도구이며, SVN, Git등 대부분의 형상 관리 도구와 연동이 가능하다.

 친숙한 Web GUI을 제공하여 사용이 쉽고, 또한 여러 대의 컴퓨터를 이용한 분산 빌드나 테스트가 가능하다는 장점을 가진다.

 

8.2. Gradle

 Groovy(자바에 파이썬 등의 장점을 결합한 동적 프로그래밍 언어)를 기반으로 한 오픈 소스 형태의 자동화 도구로, 안드로이드 앱 개발 환경에서 사용된다. 플러그인을 설정하면 Java, C, C++, 파이썬 등의 언어도 빌드가 가능하다.

 Groovy를 사용해서 만든 DSL (DBMS 데이터 저장 명령어의 종류 )을 스크립트 언어로 사용한다. Gradle은 실행할 처리 명령들을 모아 Task로 만든 후 태스크 단위로 실행한다.

 이전에 사용했던 태스크를 재사용하거나 다른 시스템의 태스크를 공유할 수 있는 빌드 캐시 기능을 지원하므로, 빌드의 속도 향상이 가능하다.