1. 유지보수를 고려한
SW 개발
KTH, 분산기술Lab
임도형
2012/03/30

2. 본 문서에 대하여
• 유지보수를 용이하게 하기위하여 소프트웨
어 개발 환경과, 패키징, 배포에 대한 이러
저러한 내용들을 설명합니다.
• 소프트웨어 개발자, 프로젝트 관리자가 대
상입니다.
2

3. 왜,
굳이,
이런 문서를...

4. 유지보수를
위하여
4

5. 유지보수의
비용을 줄이기
위하여
5

6. 유지보수로 지친
개발자를
구하기 위하여
6

7. 배포와 유지보수, 그리고 책임

8. 배포
• 배포, 그 지옥의 시작.
• 피할 수 없는 책임이 지워집니다.
8

9. 배포
• 배포란 고객에게 우리가 개발한 것이 전달
되는 것을 의미합니다.
• 완벽한 소프트웨어는 없습니다. 버그는 있
을 수 밖에 없습니다.
• 고객의 마음은 변합니다. 바꿔 달라고 요청
합니다. 거절 할 수 없습니다.
9

10. 배포와 유지보수
• 일단 배포 했으면 유지보수 해야 합니다.
• 한번 팔고 회사 접을 거라면 몰라도 유지보
수 해야 합니다.
• 배포한 소프트웨어를 버그픽스하고 기능개
선하는 유지보수를 반드시 해야만 합니다.
10

11. 그냥 유지보수 하면 되지 않나요?
• 뭐 별거 있겠어요?
• 그냥 하면 되지…
• 지금껏 잘해 왔는데…
11

12. 행복한 상황
• 개발 조직은 오로지 그 한 분 만을 상대합니
다.
• 만약 우리의 소프트웨어가 업데이트 된다
면, 고객은 흔쾌히 운영환경에 적용하겠다
고 합니다.
• 하지만 아시죠? 현실은 그렇지 않다는 것.
12

13. 일반적인 상황
• 다수의 고객
• 각 고객마다 상이한 버전을 사용
• 고객은 웬만하면 업데이트 하려 하지 않음
13

14. 버그 픽스

15. 필수 조건
• 고객과 똑같은 환경을 구축할 수 있어야 한다.
• 해당 버전의 소스를 확보하고 있어야 한다.
• 해당 버전의 종속적인 라이브러리를 확보하고
있어야 한다.
• 그 이후에야 버그 재현을 시도해 볼 수 있다.
15

16. 개발 환경 구축
• 버그를 재현할 개발 환경 구축이 한방으로
되어야 한다.
• 버그 픽스 보다 어려운 것이 개발 환경 구축
이다. 이리 저리 손으로 구축해야 하는 것은
참으로 어렵다. 특히 물어물어 하는 것은 절
대 피해야 한다.
16

17. GUIDE
• 개발환경을 한방으로 구축되게 하라.
17

18. 소스 버전 관리
• 일반적으로 소스 버전은 관리 된다.
• 그리고 설치된 것의 버전을 확인할 수 있어야 한다.
• 방법은 다양하다.
– 로그에 찍을 수도 있고
– 폴더 이름에 명시할 수도 있고
– 프로그램 help에서 볼 수도 있고
– 별도의 명령어를 써서 볼 수도 있고
• 하여간에 버전을 확인할 수 있어야 한다.
18

19. GUIDE
• 설치된 버전을 확인할 수 있도록 패키징 하
라.
19

20. 라이브러리 버전 관리
• 필요한 외부 라이브러리도 보통 같이 배포된다.
• 버그 재현을 하려면 그 라이브러리의 버전도 관리
되어야 한다.
• 누가 관리? 어떻게 관리?
• 하여간에 버그 재현을 위해 고객에 설치된 것과 동
일한 소스와 라이브러리를 확보하고 있어야 한다.
20

21. 외부 라이브러리
• 외부 라이브러리는 언제 어떻게 될지 모른다.
• 라이브러리 설치본을 확보하고 있어야 한다.
• 실제 설치되는 파일의 리스트를 알고 있어야
한다.
– 그래야만 라이브러리 자체를 업데이트 할 수 있다.
21

22. 외부 라이브러리 관리 사항
• 설치본 확보.
– 설치 파일 자체를 프로젝트에 포함시킨다.
– 혹은 별도의 repository에 보관해야 한다.
• 빌드 시에 프로젝트 내에 설치하도록 한다.
– 시스템에 설치가 아니다.
• 제거 할 수 있도록 한다.
– 리스트를 관리하든
– 각 라이브러리 별로 폴더로 구분하든
• 라이선스 파일과 다운로드 url도 같이 확보해 두어야 한다.
22

23. 관리를 잘 못하면
• 홈페이지에서 다운 링크가 없어졌어요.
• linux의 모든 유저가 동일한 라이브러리를 사용한다
면 버전 별로 업무를 진행할 수 없다.
• 라이브러리 30,40개는 우습다. 시간 흐르면 어느 파
일이 어떤 라이브러리에서 설치되었는지 모른다.
무섭기 때문에 절대 삭제할 수 없다.
• 배포 시에 사용 라이브러리의 라이선스 포함은 당
연하다. 어짜피 확보하여야만 한다. 그냥 라이브러
리 최초 설치 시에만 확보해 두자.
23

24. GUIDE
• 사용하는 외부 라이브러리를 제대로 관리
하라.
– 설치본 확보
– 라이선스 확보
– 다운로드 링크
– 설치된 파일 리스트
24

25. 외부 라이브러리 관련 좀더

26. 라이브러리의 종류
• 사용되는 모든 라이브러리가 전부 같이 배
포되는 것은 아니다.
– 테스트 용
– 설치 플랫폼에서 지원되어 배포 불필요
• 패키징 시에 이런 라이브러리를 제외할 수
있도록 구분할 수 있어야 한다. 보통 폴더로.
26

27. 라이브러리 설치 절차
• 라이브러리 설치 절차도 정의하여야 한다.
• 정의되지 않으면 당연한 것들이 누락된다.
– 다운로드 링크, 라이선스, 설치된 파일 리스트,
목적
27

28. 관리할 라이브러리 파일
• 매 빌드 때마다 라이브러리들을 전부 다시
빌드할 필요는 없다.
• 바이너리 혹은 패키징된 형태의 파일을 저
장소에서 가져올 수 있도록 하자.
28

29. GUIDE
• 프로젝트가 필요한 라이브러리를 보관할
저장소를 마련하라.
29

30. 배포 시 문서

31. 포함시켜야 할 문서들
• 버전
• 설치, 사용, 기타 설명
• 변경 내역(버그 픽스, 기능 추가)
• 하위 호환 관련 설명
– 된다, 안된다.
– 안되면 업그레이드 방법 기술
• 라이선스
31

32. 문서들의 위치?
• 배포에 포함될 문서들도 관리되어야 한다.
• 한방 빌드가 되려면 자동으로 가져올 수 있
어야 한다.
• 프로젝트 내에 포함 되도 좋고, 별도로 관리
되도 좋고.
32

33. 문서의 작성은 누가?
• 아무나 할 수 있어야 한다.
• 이슈관리툴을 보고 작성.
– 이슈관리툴에는 이를 위한 충분한 정보가 입력
되어 있어야 한다.
33

34. GUIDE
• 패키징은 tar 실행이 아니다. 포함할 문서를
반드시 작성하라.
34

35. 브랜치

36. 브랜치가 없다면
• 고객은 v2.0, 현재 최신은 v4.3이다.
• v2.0의 버그를 픽스했다.
• 요것도 관리해야 하는데 어디에다?
– v2.0에 적용하는 순간 이미 v2.0이 아니다.
– 최신 4.3에다 적용할까?
36
2.0 2.1 2.2 4.3. . .
bug fix

37. 배포할 때 마다 브랜치를 만들자
• 배포할 때 v2.0의 브랜치를 만들자.
• 버그 픽스가 적용된 v.2.0.1 버전을 새로 만
들자.
37
2.0 2.0.1
bug fix
main branch
3.0 4.0
merge

38. 모든 브랜치에 버그 픽스 적용
• 보통 버그는 특정 브랜치에만 해당하지는
않는다.
• 적용 가능한 모든 브랜치에 버그 픽스를 적
용한다.
38
2.0 2.0.1
bug fix
main branch
3.0 4.0
merge
3.0.1 4.0.1
bug fix
merge
bug fix
merge

39. 언제 새 브랜치?
• 배포 시 마다 새 브랜치를 생성하여야 한다
는데
• 버그 하나 수정한 것도 새 브랜치로?
• 별다른 업그레이드 조치 없이 새것으로 바
꾸어 사용하여도 무방하면 : X
• 하위 호환 안되거나, 굵은 업버전일 경우 :
새 브랜치
39

40. 패키지, 브랜치
• 배포를 위해 패키징하나 할 때 마다 새로운
버전의 패키지가 새로 생긴다.
some-1.2.0.tar.gz
some-1.2.1.tar.gz
some-1.2.2.tar.gz
some-1.3.0.tar.gz
• 보통은 minor version까지 하나의 브랜치로
관리한다.
40
브랜치 1.2
브랜치 1.3

41. GUIDE
• 하위호환 안되는 배포일 때 branch를 만들
라.
41

42. 패키징 절차

43. 패키징 절차
• 컴파일
• 모든 테스트(단위, 통합, 하위호환) 만족
• 배포 문서 작성
• 필요 시, 업그레이드 스크립트 작성, 검증
• 패키징 파일 생성
• 필요 시, 새로운 브랜치 생성
43

44. 절차 정의 필요
• 누구나 패키징을 할 수 있어야 한다.
• 당연한 것들이라 인식되지만, 정의된 절차
가 없으면, 누락되고, 실수하고, 생략되고,
일관성 없이 된다.
– 작성할 문서 목록
– 실행할 테스트 목록
– 버전이나 파일이름 관련 규칙
44

45. 팀 내 프로젝트 간 관계

46. 사 내, 팀 내 프로젝트
• 외부 라이브러리 뿐 아니라, 사내, 팀 내 프로
젝트를 사용하는 경우도 많다.
• 다를 것 없다. 제대로 패키징해서 저장소에 올
리고, 다른 프로젝트는 마치 외부 라이브러리
를 사용하는 것처럼 하면 된다.
• 절대 지양할 예
– 컴파일한 클래스 파일 하나를 메신저로 전달
– 급하다고 운영서버에서 직접 손으로 수정
46

47. 시스템의 독립성

48. 라이브러리 공유 지양
• 각 시스템 별로 실행 환경을 독립되게 한다.
• 공유된 곳에 있는 라이브러리를 2개의 시스
템이 사용할 때, 만약 다른 버전의 라이브러
리를 사용해야 한다면?
48

49. 업그레이드

50. 대상
• 데이터
• 설정
50

51. 데이터 업그레이드
• 절대 소실되어서는 안된다.
• DBMS와 같이 시스템 안에 저장된 경우,
SQL과 같은 방식으로 처리한다.
51

52. 설정 업그레이드
• 일반 데이터와 동일하게 취급한다.
• 파일로 되어 있을 경우 그 내용을 자동으로
업그레이드 할 수 있도록
• 시스템에 있을 경우 시스템의 인터페이스
를 사용하여서
52

53. 스크립트
• 당연히 자동화 되어야 하고, 스크립트로 제
공되어야 한다.
• 업그레이드 실패 시, 복원할 수 있어야 한다.
• 업그레이드 스크립트 자체만 별도로 패키
징하길 권장.
53

54. 업그레이드 체인
• 각 배포 버전마다 업그레이드 스크립트를
제공하고, 각 스크립트를 연속적으로 적용
한다.
• 이를 위해서는 매 배포 시마다 업그레이드
스크립트를 제공해야 한다.
54
2.2 2.2.1 2.3 2.3.1 2.3.2
업그레이드 업그레이드 업그레이드 업그레이드

55. 하위 호환

56. 하위 호환 되려면
• 인터페이스 삭제 불가
• 인터페이스 변경도 불가
• 오직 추가, 확장만이 가능하다.
• 초기 인터페이스의 겉모습이 적절하지 않다면,
인터페이스 자체가 일관성 없을 수 밖에 없다.
• 정말 신중히 신중히 신중히 그리고 한번 더 신
중히 인터페이스 형태를 고민하자.
56

57. 보장하여야 한다
• 테스트로 검증할 수 밖에 없다.
• QA 인력에 의해 수작업으로 검증되기도 하지
만, 바람직하지 않다.
• 자동으로 실행될 수 있어야 한다.
• 수작업으로 진행될 경우 패키징의 피드백이
오래 걸린다. 최소 하루 이상. 더욱이 QA팀과
같이 역할이 분리된 경우 더 오래 걸린다. 자
동화 된 경우 즉각 결과를 보고 수정이 가능
57

58. 하위 호환 테스트
• 하위호환 테스트는 별도의 프로젝트로 관리하자.
– 특정 버전의 프로젝트에 포함되어 있는 테스트 케이스
가 다른 버전을 테스트?
– QA 담당자가 QA를 위한 프로젝트로 취급하자.
• 특히 하위호환이 안되어 업그레이드 해야 할 경우
테스트에는 2개의 버전이 동시에 사용된다.
58
2.2.0 2.2.1
업그레이드
테스트 셑
test test

59. 네임스페이스
• 하위 호환을 위해 기존 코드를 그대로 두고 한 벌
을 더 작성하기도 한다.
• 이 경우 새로운 코드의 네임스페이스만을 변경해
서 사용하는 것이 가장 편이.
• python과 같은 코드에도, 이후의 유연성을 위해
네임스페이스를 적용하자.
59

60. 하위호환이 정말 어렵다면
• 호환 포기를 선언한다.
• 새로운 버전은 새로운 프로젝트로 취급한다.
60

61. 개발과 유지보수

62. 유지보수 담당
• 배포를 하면, 어쩔 수 없이 유지보수 업무
담당자가 있을 수 밖에 없다.
• 하지만 전담으로 유지보수를 하는 인력이
있게 되는 순간부터 개발 외적인 관리의 어
려움이 발생한다.
62

63. 어두운 유지보수 업무
• 동기 부여가 어렵다.
• 창의성있는 업무가 아니기에 의욕을 두기 어
렵다.
• 타 개발자에 의해 작성된 것을 받아서 시작한
다.
• 신규 개발업무와 차별되었다고 느낀다. 혹은
진짜 차별 받고 있다.
• 아무리 잘해도 돋보이기 힘들다.
• 역량 인력의 확보가 힘들고, 이탈이 쉽다.
63

64. 유지보수 비용
• 유지보수에 소프트웨어 개발 전체의 2/3 혹
은 3/4 비용이 소요된다.
• 배포가 많아 질수록 비용이 더 커진다.
• 정말 1인당 매출액을 늘리려면 요 부분의
비용을 줄여야 한다.
64

65. 유지보수를 조금 밝게 하려면
• 개발 자체가 유지보수를 고려해야 한다.
• 모든 것을 자동화 한다.
• 브랜치를 최소로 한다.
• 디버깅을 쉽게 한다.
• 문서가 중요하다.
65

66. 유지보수 고려한 개발
• 개발되어 건네어진 것을 대상으로 하기에,
그 건네어진 것 자체가 엉망이라면, 어떻게
해볼 여지가 거의 없다.
66

67. 자동화
• 업그레이드 스크립트가 없다면? 매 고객을 찾
아가 손으로 업그레이드를 해야 한다.
• 개발환경 구축을 매번 손으로 해야 한다면?
구축 자체가 까다롭고 어렵다. 역시 비용이다.
• 자동화 되지 않을 경우 테스트는 제대로 할 수
있을까?
• 자동화하지 못했다는 것은 단순 반복 업무를
손으로 해야 한다는 것. 비용이 커지고, 업무
를 지치게 한다.
67

68. 최소 브랜치 유지
• 브랜치 개수 만큼 업무의 양이 비례한다(비
용이다).
• 쉽게 브랜치를 따지 말자(즉 하위호완 안되
는 새로운 배포를 심각하게 고려하자)
• 특히 고객별로 커스터마이징 하는 경우 답
이 없다. 다른 회사 알아 보자.
68

69. 쉬운 디버깅
• 운영환경에서 활용할 수 있는 것은 오직 로
그이다.
• 개발 시의 당연하고 쉬운 로직 흐름이라도,
유지보수 시에는 일일이 코드를 보며 다시
파악해야 한다(비용이다).
• 로그만으로도 문제를 파악할 수 있게 해야
한다.
69

70. 문서의 중요성
• 모든 개발 업무에 ‘왜, 어떻게, 그래서’라는
문서를 작성하자. 코드만으로 그것들을 파
악하기는 극히 어렵다(비용이다).
• 업무를 순환해도 개발이 진행될 수 있어야
한다. 즉 아무나 그 업무를 진행할 수 있어
야 한다. 신규개발 하던 개발자가 유지보수
하고, 유지보수 하던 개발자가 신규 개발할
수 있어야.
70

71. 다시, 유지보수 고려한 개발
• 제시된 모든 방법은 개발 시에 적용되어야 한
다.
– 자동화, 최소 브랜치, 쉬운 디버깅, 문서
• 그 적용 하나 하나가 개발의 더디게 한다. 하
지만 무시하면 그것은 고스라니 유지보수 비
용으로 전가된다.
• 개발된 결과에 대하여 책임을 져야 한다. 치고
빠지면 안 된다. 배째면 안 된다. 책임 자신 없
으면 배포하면 안된다.
71

72. 유지보수가 어렵지 않다면
• 개발과 유지보수의 업무 담당을 구별하지 않
아도 된다.
• 그렇다면 그 부작용을 최소화 할 수 있다.
• 이상적으로는 유지보수 인력을 따로 두지 않
아도 된다.
• 와! 이상적인 경우 그 비용이 엄청 감소한다.
72

73. 좀 편중된 관점

74. 솔루션 개발의 관점
• 본문서의 내용은 솔루션 개발이란 관점에
편중된 내용입니다.
• 실제 상황은 많이 다를 수 있습니다. 하지만
유지보수를 좋게 하겠다는 똑같은 목표라
면 과장되지는 않았다 봅니다.
74

75. 다시 정리

76. 배포의 책임감
• 제대로 배포하지 못하면, 모두가 불행해 진
다. 돈.
76

77. 패키징 절차
• 반드시 정의되어야 한다.
77

78. 하위 호환 보장
• 테스트로 하위 호환을 보장해야 한다.
78

79. 브랜치
• 하위호환이 안될 경우 새로운 브랜치를 생
성 하라. 하지만 새로운 브랜치는 곧 비용이
다.
79

80. 자동화
• 모든 걸 자동화 해야 한다. or 돈
80

81. 유지보수를 고려한 개발
• 유지보수의 비용은 개발과정에서 기인한다.
81

82. 저장소
• 라이브러리를 관리할 저장소를 둔다.
• 패키징한 패키지도 저장소에 올린다.
• GitHub, 좋습니다.
82

83. 사족. 소프트웨어 품질

84. 3가지
• 동적 테스트 : 각종 테스트들
• 정적 테스트 : 커버리지, 잠재 버그 검출
• 문서 : 사용, 유지보수를 위한
84

85. 품질과 절차
• 절차가 정의되어야 합니다.
• 앞에서 테스트 자동화는 말했지만, 충분한 그
리고 적절한 테스트인지는 어떻게 보장?
• 정적 검사는 단지 검사툴의 자동 실행만 적용
해도 됩니다.
• 충분한 그리고 적절한 문서인지는 어떻게 보
장?
85

86. 사족. 그 한방에 대하여

87. 한방
• 이래 저래 수작업 필요 없다는 것이죠.
• 자동화 되었다는 얘기입니다.
• 그 한방의 대상은?
– 빌드와 테스트는 너무나도 당연하죠.
– 이 조차도 안되고 있다면 심각한 거 입니다.
• 이 외 개발환경 구축, 패키징, 시스템 테스트,
성능 테스트까지 지향해야 합니다.
87

88. 한방과 CI
• 프로젝트가 CI에 적용되지 않았다면, 한방
못하고 있는 겁니다.
• CI에 적용하기 어려운 이유가 있다면, 프로
젝트 구조를 개선해야 합니다.
• 한방을 검증하는 유일한 형식적인 방법은
CI입니다. CI 없이 한방 되었다고 말할 수
없습니다. 그리고 자동화 없이는 유지보수
어렵습니다.
88