유지보수를 고려한 SW 개발
•Descargar como PPTX, PDF•
46 recomendaciones•6,971 vistas
개발자를 불행하게 하는 유지보수를 고려한 개발에 대한 얘기들입니다. 개인적인 경험에 근거한 주관적인 내용입니다. 논의의 꺼리로서 정도의 의미입니다.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a 유지보수를 고려한 SW 개발
Similar a 유지보수를 고려한 SW 개발 (20)
Más de 도형 임
Más de 도형 임 (20)
Último
Último (7)
유지보수를 고려한 SW 개발
- 1. 유지보수를 고려한 SW 개발 KTH, 분산기술Lab 임도형 2012/03/30
- 2. 본 문서에 대하여 • 유지보수를 용이하게 하기위하여 소프트웨 어 개발 환경과, 패키징, 배포에 대한 이러 저러한 내용들을 설명합니다. • 소프트웨어 개발자, 프로젝트 관리자가 대 상입니다. 2
- 4. 유지보수를 위하여 4
- 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