📌 제품 소프트웨어 패키징 - 릴리즈 노트 작성

 

 

목차

 

💡 주요 키워드 ? 소프트웨어 패키징, 릴리즈 노트, DRM, 소프트웨어 설치 매뉴얼, 소프트웨어 사용자 매뉴얼, 형상 관리, Subversion, Git, Jenkins, Gradle

 

소프트웨어 페키징의 개요

📌 소프트웨어 패키징이란 모듈 별로 생성한 실행 파일들을 묶어 배포용 설치 파일을 만드는 것을 말한다.

 

• 개발자가 아니라 사용자를 중심으로 진행한다.
• 소스 코드는 향후 관리를 고려하여 모듈화하여 패키징한다.
• 사용자가 소프트웨어를 사용하게 될 환경을 이해하여, 다양한 환경에서 소프트웨어를 손쉽게 사용할 수 있도록 일반적인 배포 형태로 패키징한다.

 

💡 일반적으로 패키징(Packaging)이란 관련된 것들을 하나로 묶는 것을 말하며, 소프트웨어 패키징이란 기능별로 생성한 실행 파일들을 묶어 배포용 설치 파일을 만드는 것을 의미한다.

💡 모듈화 ? 소프트웨어의 성능을 향상시키거나 시스템의 수정 및 재사용, 유지 관리 등이 용이하도록 시스템을 각 기능별로 나누는 것을 말한다.

 

 

패키징 시 고려사항

• 사용자의 시스템 환경, 즉 운영체제(OS), CPU, 메모리 등에 필요한 최소 환경을 정의한다.
• UI(User Interface)는 사용자가 눈으로 직접 확인할 수 있도록 시각적인 자료와 함께 제공하고 매뉴얼과 일치시켜 패키징한다.
• 소프트웨어는 단순히 패키징하여 배포하는 것으로 끝나는 것이 아이라 하드웨어와 함께 관리될 수 있도록 Managed Service 형태로 제공하는 것이 좋다.
• 사용자에게 배포되는 소프트웨어이므로 내부 콘텐츠에 대한 암호화 및 보안을 고려한다.
• 다른 여러 콘텐츠 및 단말기 간 DRM(디지털 저작권 관리) 연동을 고려한다.
• 사용자의 편의성을 위한 복잡성 및 비효율성 문제를 고려한다.
• 제품 소프트웨어 종류에 적합한 암호화 알고리즘을 적용한다.

 

💡 Managed Service ? 고객이 사용 중인 소프트웨어를 24시간 모니터링 하면서 문제 발생 시 현장에 바로 출동하여 필요한 점검을 수행하는 등의 체계적인 운영 관리와 유지 보수를 수행하는 서비스를 의미한다.

 

 

패키징 작업 순서

📌 패키징 주기는 소프트웨어 개발 기법에 따라 달라지는데, 짧은 개발 주기를 반복하는 애자일 기법인 경우에는 보통 2~4주 내에서 지정하며, 각 주기가 끝날 때마다 패키징을 수행한다.

 

• 프로젝트 개발 과정에서 주기 별로 패키징한 결과물은 테스트 서버에 배포한다.
• 마지막 개발 과정을 거쳐 최종 패키징한 결과물은 고객이 사용할 수 있도록 온라인 또는 오프라인으로 배포한다.
  • 온라인 배포 : 별도로 마련한 운영 서버에 설치 및 사용 매뉴얼과 함께 배포 파일을 등록하여 고객이 직접 다운받아 사용할 수 있도록 한다.
  • 오프라인 배포 : CD-ROM이나 DVD, USB 등에 설치 및 사용 매뉴얼과 함꼐 배포 파일을 담는다.

 

💡 최근에는 Eclipse, Visual Studio, Xcode, Android Studio 등의 IDE 도구가 프로그램 코딩부터 배포까지 대부분의 고정을 지원하며, 별도의 버전 관리 프로그램을 연동하면 버전 관리 작업까지도 지원하기 때문에 별도의 패키징 도구를 사용하지 않는다. 패키징 된 소프트웨어는 사용자가 직접 다운받아 설치할 수 있도록 웹 사이트나 앱 스토어 등에 등록되어 배포된다.

 

 

1. 기능 식별 : 작성된 코드의 기능을 확인한다.
2. 모듈화 : 확인된 기능 단위로 코드들을 분류한다.
3. 빌드 진행 : 모듈 단위별로 실행 파일을 만든다.
4. 사용자 환경분석 : 웹, 모바일, PC 등 소프트웨어가 사용될 환경이나 운영체제, CPU, RAM 등의 최소 운영 환경을 정의한다.
5. 패키징 및 적용 시험
   • 빌드된 실행 파일들을 정의된 환경에 맞게 배포용 파일 형식으로 패키징 한다.
   • 정의된 환경과 동일한 환경에서 패키징 결과를 테스팅한 후 소프트웨어에 대한 불편사항을 사용자 입장에서 확인한다.
6. 패키징 변경 개선 : 확인된 불편 사항을 반영하기 위한 패키징의 변경 및 개선을 진행한다.
7. 배포 : 배포 수생 시 오류가 발생하면 해당 개발자에게 전달하여 수정을 요청한다.

 

💡 빌드(Build) ? 빌드는 소스 코드 파일들을 컴퓨터에서 실행할 수 있는 제품 소프트웨어로 변환하는 과정 또는 결과물을 말한다.

💡 사용자 환경 분석 ? 사용자 실행 환경은 운영체제(OS), 시스템 사양, 사용 방법 등을 최대한 자세하게 구분하여 미리 정의해 놓아냐 하며, 실행 환경이 다양한 경우에는 각 환경 별로 배포본을 만들기 위해 여러 번의 패키징을 수행해야 한다. 예를 들면 Windows 10 운영체제는 32비트와 64비트를 선택하여 설치할 수 있도록 Win10_32bit.msi 와 Win10_64bit.msi 두 가지 버전으로 패키징하여 배포된다.

💡 주요 배포용 파일 형식 
- msi : Windows 용 패키지 형식
- dmg : Mac OS 용 패키지 형식
- jar : Java 응용 소프트웨어나 라이브러리를 배포하기 위한 패키지 형식
- war : Java Serlet, Java Class, xml 및 웹 애플리케이션 서비스를 제공하기 위한 패키지 형식
- ear : jar와 war를 묶어 하나의 애플리케이션 서비스를 제공할 수 있는 패키지 형식
- apk : 안드로이드용 앱 패키지 형식
- ipa : iOS 용 앱 패키지 형식

 

 

릴리즈 노트(Release Note)의 개요

📌 릴리즈 노트는 개발 과정에서 정리된 릴리즈 정보를 소프트웨어의 최종 사용자인 고객과 공유하기 위한 문서이다.

 

• 릴리즈 노트를 통해 테스트 진행 방법에 대한 결과와 소프트웨어 사양에 대한 개발팅의 정확한 준수 여부를 확인할 수 있다.
• 소프트웨어에 포함된 전체 기능, 서비스의 내용, 개선 사항 등을 사용자와 공유할 수 있다.
• 릴리즈 노트를 이용해 소프트웨어의 버전 관리나 릴리즈 정보를 체계적으로 관리할 수 있다.
• 릴리즈 노트는 소프트웨어의 초기 배포 시 또는 출시 후 개선 사항을 적용한 추가 배포 시에 제공한다.
• 소프트웨어의 초기 배포 시 제공되는 릴리즈 노트에서는 소프트웨어에 포함된 기능이나 사용 환경에 대한 내용을 확인할 수 있다.
• 소프트웨어 출시 후 개선된 작업이 있을 때마다 관련 내용을 릴리즈 노트에 담아 제공한다.
• 릴리즈 노트에 정리된 정보들은 철저한 테스트를 거친 것이며, 개발팀에서 제공하는 소프트웨어 사양에 대한 최종 승인을 얻은 후 문서화 되어 제공된다.

 

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

📌 릴리즈 노트의 초기 버전은 다음의 사항을 고려하여 작성한다.

 

• 릴리즈 노트는 정확하고 완전한 정보를 기반으로 개발팀에서 직접 현재 시제로 작성해야 한다.
• 신규 소스, 빌드 등의 이력이 정확하게 관리되어 변경 또는 개선된 항목에 대한 이력 정보들도 작성 되어야 한다.
• 릴리즈 노트 작성에 대한 표준 형식은 없지만 일반적으로 다음과 같은 항목이 포함된다.

Header(머릿말)	릴리즈 노트 이름, 소프트웨어 이름, 릴리즈 버전, 릴리즈 날짜, 릴리즈 노트 날짜, 릴리즈 노트 버전 등
개요	소프트웨어 및 변경사항 전체에 대한 간략한 내용
목적	해당 릴리즈 버전에서의 새로운 기능이나 수정된 기능의 목록, 릴리즈 노트의 목적에 대한 간략한 개요
문제 요약	수정된 버그에 대한 간략한 설명 또는 릴리즈 추가 항목에 대한 요약
재현 항목	버그 발견에 대한 과정 설명
수정/개선 내용	버그를 수정/개선한 내용을 간단히 설명
사용자 영향도	사용자가 다른 기능들을 사용하는데 있어 해당 릴리즈 버전에서의 기능 변화가 미칠 수 있는 영향에 대한 설명
SW 지원 영향도	해당 릴리즈 버전에서의 기능 변화가 다른 응용프로그램들을 지원하는 프로세스에 미칠 수 있는 영향에 대한 설명
노트	SW/HW 설치 항목, 업그레이드, 소프트웨어 문서화에 대한 참고 항목
면책 조항	회사 및 소프트웨어와 관련하여 잠조항 사항  예) 프리웨어, 불법 복제 금지 등
연락처	사용자 지원 및 문의 응대를 위한 연락처 정보

 

 

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

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

 

• 중대한 오류가 발생하여 긴급하게 수정하는 경우에는 릴리즈 버전을 출시하고 버그 번호를 포함한 모든 수정된 내용을 담아 릴리즈 노트를 작성한다.
• 소프트웨어에 대한 기능 업그레이드를 완료한 경우에는 릴리즈 버전을 출시하고 릴리즈 노트를 작성 한다.
• 사용자로부터 접수된 요구사항에 의해 추가나 수정된 경우 자체 기능 향상과는 다른 별도의 릴리즈 버전으로 출시하고 릴리즈 노트를 작성한다.

 

💡 베타 버전(Beta Version) : 베타 버전은 소프트웨어를 정식으로 출시하기 전에 테스트할 목적으로 지정된 일부 사용자들에게만 배포하는 시험용 소프트웨어이다.

 

 

릴리즈 노트 작성 순서

📌 릴리즈 노트는 일반적으로 다음과 같은 순서로 작성한다.

 

1. 모듈 식별 : 모듈별 빌드 수행 후 릴리즈 노트에 작성될 내용들을 확인한다.
2. 릴리즈 정보 확인 : 릴리즈 노트 이름, 소프트웨어 이름, 릴리즈 버전, 릴리즈 날짜, 노트 날짜, 노트 버전 등을 확인한다.
3. 릴리즈 노트 개요 작성 : 소프트웨어 및 변경사항 전체에 대한 간략한 내용을 작성한다.
4. 영향도 체크 : 버그나 이슈 관련 내용 또는 해당 릴리즈 버전에서의 기능 변화가 다른 소프트웨어나 기능을 사용하는데 미칠 수 있는 영향에 대해 기술한다.
5. Header(머릿말), 개요 영향도 체크 항목을 포함하여 리리즈 노트에 작성될 기본 사항들을 작성한다.
6. 추가 개선 항목 식별 : 추가 버전 릴리즈 노트 작성이 필요한 경우 추가 릴리즈 노트를 작성한다.