[소프트웨어공학] 소프트웨어 개발 생명주기 SDLC: 유지보수(2) 형상 관리

소프트웨어 형상 관리 Software Configuration Management, SCM

• 소프트웨어 형상? 
  개발 각 단계 또는 프로세스마다 만들어지는 산출물들의 집합 (우리가 생산된 sw라고 부르는 대상)
• 소프트웨어 형상 관리?
  개발 주기 동안 생성된 문서를 관리하고 sw 시스템/컴포넌트의 상태를 추적하는 작업
  • 개발 및 유지보수 과정에서 발생하는 각종 결과물들에 대해 형상을 만들고, 형상에 대한 변경을 관리, 제어한다. 
  • 소스코드, 문서, 인터페이스 등의 버전, 최종 업데이트 관리자 기록 등. 
• ex. GitHub
• 필요성
  자주 수정하기 때문에. 수정 이력이 관련자들에게 통보되지 않는 경우, 변화가 누락되거나 이중 작업이 이루어질 수 있음. 
• 여러 개의 버전을 만드는 것은 문제가 되지 않지만, 불필요한 작업이나 중복 작업 또는 일부 수정 사항 누락과 같이 혼란이 생기면 안된다. 

 

형상 관리 절차

1. 형상 식별

• 형상 관리 대상을 구분, 베이스라인의 기준, 항목을 정함
• 형상 관리 대상 및 항목 식별
  • 형상 항목 선정, 베이스라인 기준 선정 순서로 이루어짐. 
• 형상 항목 선정
  • 변경사항을 통제할 필요가 있는 산출물이 무엇인지 정하기.
  • 다양한 문서 - 계획서, 요구사항 명세서, 설계/인터페이스 명세서, 소스코드, 테스트 설계서, 테스트 결과지 등
  • 소프트웨어를 특정 시점에 재현하기 위해 필요한 기록, 도구 등 - 언어 버전, 컴파일러 버전, 개발 툴, 시뮬레이터 버전, OS 버전, IDE 등 (ex. 사용한 os 버전이나, c 프로그램의 버전)
• 형상 식별자 규칙 선정
  • 약자도 일관성 있게. 
  • 표준 버전 관리 표기법
    va.b.c - a: 큰 구조 변경 또는 대규모 개선, b: 기능 추가, c: 오류 수정
    v1.2.3 - 초기 버전 기준 2번의 기능 추가와 3번의 오류 수정(패치)가 이루어짐

형상 식별자 규칙 선정

• 베이스라인 기준 선정
  • 베이스라인? 소프트웨어 개발 과정 중 특정 시점에 만들어진 산출물의 집합 
  • 개발(유지보수) 중 통제의 대상으로 현재로서는 목표이자 미래의 출발점이 되기 때문에 정해야 한다. 
    베이스라인은 각 항목들을 어떤 버전까지 개발할 것인지 중간 목표가 되기도 한다. 
  • 프로젝트 관리의 기준선. 
  • 베이스라인의 종류:  어떻게 기록하여 기준선을 만드는지? 기준선의 기준을 무엇으로 할까?
    • 기능적 기준선 - 프로젝트 수행 계획서, 요구사항 관리대장, UML 등
    • 분배적 기준선 - 엔티티 정의서, 데이터 흐름도, 용어집 등
    • 설계 기준선 - 인터페이스, UI 정의서 등
    • 시험 기준선 - 소스코드, 단위 테스트 기록 등
    • 제품 기준선 - 테스트 계획서, 테스트 케이스 선정문서 등
    • 운영 기준선 - 사용자 메뉴얼, 개발자 메뉴얼, 최종 산출물(실제, 특정 시점에 만들어진 제품들)

2. 형상 통제

• 소프트웨어 형상변경 요청을 검토 및 승인하여 현재의 베이스라인에 반영될 수 있도록 통제.
• 형상 통제 위원회(Configuration Control Board, CCB)에서 이루어짐. 
• 변경 요청 > 변경 심사 > 변경 실시 > 변경 확인
  • 변경요청 - 변경 사항이 생겼을 때 변경 요청서를 작성해 변경 관리 담당자에게 제출
  • 변경심사 - 통제위원회는 변경 요청서를 검토(승인 or 거절 결정 / 이유의 타당성, 변경 범위, 미치는 영향)
  • 변경실시 - 수락한 작업을 수행. 보관중인 항목을 가져와 변경 & 이력 관리
  • 변경확인 - 변경 완료 시 개정 이력과 함께 새로운 버전 번호 부여. 
  • 변경이 잘 되었는지, 승인되지 않은 내용도 들어가진 않았는지, 영향을 받는 다른 항목들에도 제대로 반영되었는지 확인해야 한다. 

형상 통제

3. 형상 감사 

• 형상 항목 변경이 요구사항을 만족했는지 확인하는 과정
• 승인된 변경 요청이 적절히 반영 되었는지
• 승인되지 않은 내용이 추가되지는 않았는지
• 영향을 받는 다른 항목들에도 제대로 반영 되었는지 검증

4. ⭐ 형상 기록/보고

• 베이스라인으로 설정된 형상 항목의 구조와 변경 상태를 기록
• 관련된 사람들에게 보고
  형상 상태 보고서를 활용
  • 변경 이력
  • 최종 도달 상태 (베이스라인의 상태)
  • 변경 제어 상태 등

 

역공학 Reverse Engineering

이미 만들어진 시스템을 역으로 추적하는 기법

처음에 있었던 문제나 설계 기법 등의 자료를 얻어내는 일

프로그램 추상 수준을 점증적으로 복구해 나가는 과정

역공학이 왜 필요한가?

유지보수가 어려운 코드를 쉽게 이해할 수 있는 형태로 누적된 변경들로 시스템의 효율성이 저하된 경우, 해소하기 위해. 
프로그램을 이해하기 위해. 

↓  Refactoring: 높은 결합도의 해소
↓  불필요한 코드 찾아 제거 등 
↓  역공학에 의해 생성된 다이어그램은 sw의 구조, 기능 동작의 이해를 용이하게 함.

 

• 블랙박스 형태 리버싱
  • 연산 i/o를 분석하여 내부 구조를 이해 
  • (sometimes) 리버싱 후 동일한 기능을 갖는, 내가 이해할 수 있는 형태의 코드로 재생성
  • 조립식 부채널을 활용한 리버싱도 가능. 
    알고 있는 사실을 바탕으로 내부 구조 리버싱. 
• 화이트박스 형태 리버싱이 가능한 경우
  • 라이브러리 내부 구조 이해, 논리 흐름도(CFG, DFG)등을 그려 이해하기
  • 각 모듈별 어떤 기능을 하는지 이해할 수 있음. 

장점과 단점

• 장점
  • 역공학은 놓쳤던 문제들이 누적되다가 snowball이 되어 크게 영향을 미치는 것을 완화하는 것을 돕는 것.   
  • 프로그램의 내부 동작과 설계 개념을 추적하여:
    • 잘못 작성된 명세서 수정
    • 누락된 설명 추가 (불명확한 명세서 보완, 전임자가 갑자기 떠난 경우 등)
  • 레거시 시스템에 대한 이해도를 높일 수 있음. 
• 단점: 내 sw를 다른 사람이 리버싱할 때
  
  • 소스코드를 비롯한 전체적인 작동원리를 알아낸다면, 의도적인 공격이 가능해짐. 
  • IP 유출
  • 2차 피해: 리버싱 결과를 응용/활용해서 다른 기능에 악용

 

역공학을 방지하는 방법

• 난독화 Circuit/Code Obfuscation
  • 회로/코드 구조를 알아볼 수 없도록 난독화
  • (문제) 필요없는 코드를 지우기로 했는데, 불필요한 코드를 추가한 셈
• Logic Locking
  • 특수 keyset을 입력해야만 올바른 동작을 하도록 만듦
  • 해당 keyset은 하드웨어에 직접 두고, 다중 anti-tempering 기술을 사용해서 알아보지 못하도록 조치 
  • (문제) 하드웨어를 만든 사람들은 신뢰할 수 있을까? 
• Digital Watermarking
  • 코드에 일종의 전자 기록(taint)를 남기는 것
  • 종류
    • Strong Watermark - 혹시 내 코드 중 일부를 훔쳐가서 자기 코드에 활용한 것을 잡을 수 있음. 
    • Weak Watermark - 내 코드를 강제로 리버싱하는 과정에서 남아 있어야할 워터마크가 변조되었음을 탐지하기 위해
• 2차 피해 예방법 - Integrity check, Attestation
  • 내가 만든 코드가 '그대로' 동작하는지 확인함으로써, 리버싱을 통한 코드 수정 방지가능 (ex. 게임에서)
• 가장 쉬운 방법? 내 환경에서 돌리자! 
  자사 클라우드에서 돌리자! 

 

역공학을 방지하는 방법들이 기존에 지양했던 부분과 일치하기 때문에, 
정답이라고는 볼 수 없다. 

난독화 표 등을 통한 방지법 적용 과정을 기록해두는 것이 중요하다. 
효율성과 유효성에 대해 고민해봐야 한다. 
주어진 상황에 맞게, 방지 비용 등을 고려해서 선택 적용하는 것이 좋은 방법이다.