소프트웨어 개발과 테스트 - 조대협의 서버 사이드 - Technical Debt

 

소프트웨어 개발과 테스트 국내도서 저자 : 조대협 출판 : 프리렉 2015.01.15 상세보기

1. Technical Debt 이란 무엇인지 내용을 설명하고, Technical Debt가 생기는 주요한 원인 8가지와 각 내용을 부연설명 하시오. 그리고 Technical Debt에 대해 오해하지 말아야 할 점은 무엇인지 설명하시오. 또한 학습자가 생각하는 Technical Debt가 주는 '긍정적 요소'는 무엇인지 내용을 설명하시오.  

1. Technical Debt이란 무엇인지 내용을 설명하시오.

Technical Debt는 직역하자면 '기술적인 빚'이라는 뜻입니다. 은유적인 표현으로, 개발 단계에서 제대로 개발을 해 놓지 않게 되면 그게 빚이 되고 나중에 이자가 붙어서 더 많은 일을 해야 한다는 것이지요. 쉽게 예를 들어서, 개발 단계에서 문서화를 제대로 해놓지 않은 경우 개발이 끝난 후 기능 개선이나 기타 수정을 하려고 했을때 문서가 없기 때문에 코드를 분석하고 구조를 다시 분석하는 작업을 한 후에 다시 개발을 해야 하므로 더 많은 노력이 든다는 겁니다. 즉 문서로 만들어놓지 않은 것이 '빚'이 되는 것입니다. 

2. Technical Debt가 생기는 주요한 원인 8가지와 각 내용을 부연설명 하시오.

1) 비즈니스 조직으로 부터의 무리한 압박

- 시장출시를 맞추기 위해서 무리한 일정이나 무리하게 적은 예산으로 진행한 경우, 소프트웨어의 품질에 문제가 생기고 결국 나중에 이 부분을 다시 보강해야 한다.

2) 부정확한 요구 사항이나 잦은 변경

- 요구 사항이 정확하지 않게 정의되면 시스템의 기능이 제대로 개발되지 않고 프로젝트 후분에 집중되는 경항이 있으며 이는 심각한 일정과 품질 문제로 연결된다.

3) 잘못된 의사 결정 프로세스

- 비즈니스 쪽에서 일정 변경이나 요구 사항 변경에 대한 Implication(영향도)를 인지하지 못하고 일정이나 비용 등에 없이 변경을 하면 결국 문제가 발생하고 이것이 Technical Debt의 원인이 된다. 이는 잘못된 의사 결정 프로세스에서 기인한다.

4) 부족한 협업

- 팀 간의 협업 부족으로 서로 정보가 공유되지 않거나 정보가 오역되는 경우에 발생하기 쉽다.

5) 부족한 테스트

- 테스트 부족으로 말미암아 소프트웨어의 품질이 심각하게 저하되는 경우에 발생하기 쉽다.

6) 부족한 문서화

- 문서화의 부족으로 향후 참고할 자료가 없는 경우에 발생하기 쉽다.

7) 리팩토링 지연

- 리팩토링을 미루다가 소프트웨어 품질이 저하된 경우에 발생하기 쉽다.

8) 낮은 수순의 아케텍처 설계 

- 아키텍처 설계가 유연하지 않아 향후 요구 사항에 대한 반영이 어려운 경우, 또는 용량이나 성능에 대한 부분이 충분히 고려되지 않아서 향후 용량 초과시 문제가 될 때에 발생하기 쉽다.

요약하자면, 개발단계에서 제대로 개발을 하지 않으면 그 부분은 빚이 되고, 그 빚은 빠른 시일 내에 처리하지 않으면 이자가 붙어서 나중에 그 빚을 갚아야 할 시기에 더 많은 노력을 들이게 된다는 내용입니다.

3. Technical Debt에 대해 오래하지 말아야 할 점은 무엇인지 설명하시오.

- Technical Debt가 없는 것이 좋은 프로젝트가 아니라는 점입니다. 실제 사업에서도 그렇듯이 적정 비율을 부채를 유지하면서 그 비용을 다른 곳에 투자하는 것이 오히려 많은 이익을 낼 수 있습니다. 소프트웨어 개발에서도 Technical Debt를 발생시키면서 남는 잉여 리소소를 다른 곳에 투자함으로써 좋은 효과를 낼 수 있습니다. 중요한 것은 이 Technical Debt의 비율을 어느 정도로 유지할 것이냐입니다. 이러한 Technical Debt는 금융 부채와는 다르게 수치화가 어려운데, 근래에 이를 수치하 하는 노력이 이루어 지고 있습니ㅏ.

4. 학습자가 생각하는 Technical Debt가 기업에 주는 '부정적'요소는 무엇인지 내용을 설명하시오.

내가 생각하는 Technical Debt의 기업에 주는 부정적인 요소는 시각화가 어렵다는것다. 기업에서 Technical Debt이 얼마나 있는지 수치적,시각적으로 어려우므로 관리자 입장에서 보고하거나 문서화 하기도 힘들다.

1. Technical Debt 이란 무엇인지 내용을 설명하시오. 

: Technical Debt는 직역하자면 '기술적인 빚'이라는 뜻이다. 은유적인 표현으로, 개발 단계에서 제대로 개발을 해놓지 않게 되면 그게 빚이 되고 나중에 이자가 붙어서 더 많은 일을 해야 한다는 것이다.

쉽게 예를 들어서, 개발 단계에서 문서화를 제대로 해놓지 않은 경우 개발이 끝난 후 기능 개선이나 기타 수정을 하려고 했을 때 문서가 없기 때문에 코드를 분석하고 구조를 다시 분석하는 작업을 한 후에 다시 개발을 해야 하므로 더 많은 노력이 든다는 것이다. 즉 문서로서 만들어놓지 않은 것이 '빚'이 되는 것이다.

2. Technical Debt가 생기는 주요한 원인 8가지와 각 내용을 부연설명 하시오. 

: Technical Debt가 생기는 원인은 여러 가지를 들 수 있는데, 주요한 원인은 다음과 같다.

1)비즈니스 조직으로부터의 무리한 압박

: 시장 출시를 맞추기 위해서 무리한 일정이나 무리하게 적은 예산으로 진행한 경우, 소프트웨어의 품질에 문제가 생기고 결국 나중에 이 부분을 다시 보강해야 한다.

2)부정확한 요구 사항이나 잦은 변경

: 요구 사항이 정확하지 않게 정의되면 시스템의 기능이 제대로 개발되지 않고 프로젝트 후반에 집중되는 경향이 있으며 이는 심각한 일정과 품질 문제로 연결된다.

3)잘못된 의사 결정 프로세스

: 비즈니스 쪽에서 일정 변경이나 요구 사항 변경에 대한 영향도를 인지하지 못하고 일정이나 비용 등을 없이 변경을 하면 결국 문제가 발생하고 이것이 Technical Debt의 원인이 된다. 이는 잘못된 의사 결정 프로세스에서 기안한다.

4)부족한 협업

: 팀 간의 협업 부족으로 서로 정보가 공유되지 않거나 정보가 오역되는 경우에 발생하기 쉽다.

5)부족한 테스트 : 테스트 부족으로 말미암아 소프트웨어의 품질이 심각하게 저하되는 경우에 발생하기 쉽다.

6)부족한 문서화 : 문서화의 부족으로 향후 참고할 자료가 없는 경우에 발생하기 쉽다.

7)리펙토링 지연 : 리펙토링을 미루다가 소프트웨어 품질이 저하된 경우에 발생하기 쉽다.

8)낮은 수준의 아키텍처 설계 : 아키텍처 설계가 유연하지 않아서 향후 요구사항에 대한 반영이 어려운 경우, 또는 용량이나 성능에 대한 부분이 충분히 고려되지 않아서 향후 용량 초과시 문제가 될 때에 발생하기 쉽다.

3. Technical Debt에 대해 오해하지 말아야 할 점은 무엇인지 설명하시오.

: Technical Debt에서 오해하지 말아야 하는 점은 Technical Debt가 없는 것이 좋은 프로젝트가 아니라는 점이다. 실제 사업에서도 그렇듯이 적정 비율을 부채를 유지하면서 그 비용을 다른 곳에 투자하는 것이 오히려 많은 이익을 낼 수 있다.

소프트웨어 개발에서도 Technical Debt를 발생시키면서 남는 잉여 리소스를 다른 곳에 투자함으로써 좋은 효과를 낼 수 있다. 중요한 것은 이 Technical Debt의 비율을 어느 정도로 유지할 것이냐이다. 이러한 Technical Debt는 금융 부채와는 다르게 수치화가 어려운데, 근래에 이를 수치화하는 노력이 이루어지고 있다.

 

 

---

 

 

 

 2. 커버리지 분석과 코드 인스펙션이란 무엇인지 각각 설명하고, 교재에서 소개한 CI 도구 9가지를 작성하고 각각 내용을 설명하시오. 또한 학습자가 생각하는 CI의 장점은 무엇인지 한 가지 작성하고 내용을 설명하시오. 

1. 커버리지 분석에 대해 설명하시오.

- 커버리지 분석은 테스트의 대상 주엥 테스트에 해당하는 부분 중에 어느 부분이 테스트가 수행되었는지를 체크하는 과정이다. 개발 과정에서의 테스트 커버리지 분석은 일반적으로 코드 커버리지로 분석한다. 코드 커버리지란 테스트가 전체 소스 코드 중 어느 부분을 수행했는지를 검토하는 것이다. 코드 커버리지를 측정할 때 가장 중요한 것은 목표 커버리지율을 결정하는 것이다. 코드 100%를 테스트하는 것이 좋겠지만, Exception, If 문에 대해서 100% 테스트가 불가능하다. 또한, Setter와 Getter만 있는 ValueObject의 경우 테스트를 작성하기도 쉽게 테스트 자체가 의미가 없나 커버리지율은 많이 올릴 수 있다. 만약 커버리지율을 강제적으로 높이고자 하면 개발팀에서 VO 등 테스트가 필요하지 않고 테스트가 쉬운 곳에만 테스트를 집중할 수 있기 때문에 컴포넌트의 우선순위를 정해서 중요한 컴포넌트에 대해서 커버리지를 관리하는 것이 필요하다. 커버리지율을 잘 만든 테스트라도 50~70% 내외이고, 고 가용성 시스템도 80%를 넘기기 어려우므로 컴포넌터의 중요도별로 목표 커버리지율을 융통성이 있게 결정하는 것이 필요하다. 대표적인 오픈소스 도구로는 EMMA와 Cobertura 등이 있고, 상용도구로는 아틀란시아안사의 Clover 등이 있다.

2. 코드 인스펙션에 대해 설명하시오.

- 코드 인스펙션이란 완성된 코드에 대한 검토를 통해서 코드 상에 존재하는 잠재적인 문제를 발견하는 과정이다. 흔히 '정적 분석' 이라는 이름으로도 불리는데, 이 과정에서 Deadlock에 대한 검출, Lock Contention과 같은 병목 구간에 대한 검출, Memory Leak이나 Connection Leak과 같은 자원 누수에 대한 검출과 코딩 스타일(변수명이나 메서드명 규칙 등)에 대한 가이드를 수행한다. 보통 이런 도구들은 규칙 세트를 추가하여 Inspection을 각 팀의 스타일에 맞춰서 커스터마이징할 수 있으며 대표적인 오픈소스 도구로는 PMD, FindBugs 등이 있다.

3. 교재에서 소개한 CI 도구 9가지를 작성하고 각각 내용을 설명하시오.

- 체크아웃, 컴파일, 배포, 테스트 수행, 커버리지 분석, 코드 인스펙션, 소스 태깅, 릴리즈(옵셥), 결과 분석

1) 체크 아웃 : CI 도구는 정해진 시간이나 소스가 커밋이 되었을 때 등 정책에 따라서 빌드를 시작한다. 먼저 소스 코드를 체크 아웃 받는다. 

2) 컴파일 : 체크아웃 반은 코드에 내장된 빌드 스크립트를 기동하여 컴파일을 수행한다.

3) 배포 : 컴파일이 완료된 코드를 테스트 서버에 배포한다.

4) 테스트 수행 : 체크아웃 받은 코드 내에 있는 테스트 코드들을 수행하고 리포팅을 한다.

5) 커버리지 분석 : 테스트 과정 중에 코드 커버리지를 수행한다.

6) 코드 인스펙션 : 다음으로 코드 인스펙션을 수행하고 리포트를 생성한다.

7) 소스 태깅 : 1)~6) 과정이 정상적으로 수행되었을 때, 현재 소스 관리 시스템에 저장된 버전을 안정적인 버전으로 판단하고 소스 관리 시스템에 현재 버전에 대한 이미지를 저장하기 위해 태깅(Tagging)을 수행하여 혀냊 버전을 저장해놓는다.

8) 릴리즈(옵션) : 만약에 빌드나 테스트가 실패하였을 때는 이전에 성공한 빌드 버전으로 소스를 롤백하고, 실패의 원인을 파악한 후에 다시 커밋한다.

9) 결과 분석 : 빌드와 테스트가 완료된 후에 테스트 결과를 통해서 문제가 있는 테스트를 개발자가 수정하도록 하고, 코드 인스팩션 결과를 PM이 검토하여 담당 개발자가 수정하도록 한다. 다음으로, 커버리지 분석 결과를 통해서 테스트가 부족한 부분은 PM이 담당 개발자에게 지시하여 테스트를 보강하도록 한다.

4. 학습자가 생각하는 CI의 장점은 무엇인지 한가지 작성하고 내용을 설명하시오.

내가 생각하는 CI의 장점은 자동화된 빌드를 꼽을 수 있다. 정기적으로 자동 빌드 스크립트를 통해 이해관계자가 협의한 일정에 자동 빌드, 메일 안내가 장점이다.

1. 커버리지 분석에 대해 설명하시오.

: 커버리지 분석은 테스트의 대상 중, 테스트에 해당하는 부분 중에 어느 부분이 테스트가 수행되었는지를 체크하는 과정이다. 개발 과정에서의 테스트 커버리지 분석은 일반적으로 코드 커버리지로 분석한다. 코드 커버리지란 테스트가 전체 소스 코드 중 어느 부분을 수행했는지를 검토하는 것이다.

코드 커버리지를 측정할 때 가장 중요한 것은 목표 커버리지율을 결정하는 것이다. 코드 100%를 테스트하는 것이 좋겠지만, Exception, If 문에 대해서 100% 테스트가 불가능하다. 또한 Setter와 Getter만 있는 ValueObject의 경우 테스트를 작성하기도 쉽고 테스트 자체가 의미가 없으나 커버리지율은 많이 올릴 수 있다. 만약 커버리지율을 강제적으로 높이고자 하면 개발팀에서 VO 등 테스트가 필요하지 않고 테스트가 쉬운 곳에만 테스트를 집중할 수 있기 때문에 컴포넌트의 우선순위를 정해서 중요한 컴포넌트에 대해서 커버리지를 관리하는 것이 필요하다.

커버리지율은 잘 만든 테스트라도 50~70% 내외이고, 고 가용성 시스템도 80%를 넘기 어려우므로 컴포넌트의 중요도별로 목표 커버리지율을 융통성 있게 결정하는 것이 필요하다. 대표적인 오픈소스 도구로는 EMMA와 Cobertura 등이 있고, 상용 도구로는 아틀라시안사의 Clover 등이 있다.

2. 코드 인스펙션에 대해 설명하시오. 

: 코드 인스펙션이란 완성된 코드에 대한 검토를 통해서 코드 상에 존재하는 잠재적인 문제를 발견하는 과정이다. 흔히 '정적 분석'이라는 이름으로도 불리는데, 이 과정에서 Deadlock에 대한 검출, Lock Contention과 같은 병목 구간에 대한 검출, Memory Leak이나 Connection Leak과 같은 자원 누수에 대한 검출과 코딩 스타일에 대한 가이드를 수행한다.

보통 이런 도구들은 규칙 세트를 추가하여 Inspection을 각 팀의 스타일에 맞춰서 커스터마이징할 수 있으며 대표적인 오픈소스 도구로는 PMD, FindBugs 등이 있다.

3. 교재에서 소개한 CI 도구 9가지를 작성하고 각각 내용을 설명하시오. 

CI 도구

)체크아웃 : CI 도구는 정해진 시간이나 소스가 커밋이 되었을 때 등 정책에 따라서 빌드를 시작한다. 먼저 소스코드를 체크아웃 받는다.

2)컴파일 : 체크아웃 받은 코드에 내장된 빌드 스크립트를 기동하여 컴파일을 수행한다. 

3)배포 : 컴파일이 완료된 코드를 테스트 서버에 배포한다. 

4)테스트 수행 : 체크아웃 받은 코드 내에 있는 테스트 코드들을 수행하고 리포팅을 한다. 

5)커버리지 분석 : 테스트 과정 중에 코드 커버리지를 수행한다. 커버리지의 기본 원리는 커버리지 분석 대상이 되는 코드 내에 커버리지 분석 코드를 삽입하는 과정을 Code Instrument라고 한다. Instrumented 된 코드는 커버리지 분석 기능으로 말마암아서 성능 저하를 유발할 수 있기 때문에 만약에 테스트 가정에 성능이나 응답 시간에 관련된 테스트가 있을 때는 커버리지 분석을 위해서 테스트를 마친 후에 Instrument를 다시 하여 배포와 테스트 수행 과정을 다시 거쳐서 커버리지 분석을 해야 테스트 과정에서 성능에 대한 요소를 올바르게 추출할 수 있다. 

6)코드 인스펙션 : 다음으로 코드 인스텍션을 수행하고 리포트를 생성한다. 

7)소스 태깅 : 1~6 과정이 정상적으로 수행되었을 때, 현재 소스 관리 시스템에 저장된 버전을 안정적인 버전으로 판단하고 소스 관리 시스템에 현재 버전에 대한 이미지를 저장하기 위해서 태깅을 수행하여 현재 버전을 저장해 놓는다. 

8)릴리즈 : 만약에 빌드나 테스트가 실패하였을 때는 이전에 성공한 빌드 버전으로 소스를 롤백하고, 실패의 원인을 파악한 후에 다시 커밋한다. 이것은 소스 관리 시스템에 저장된 소스는 문제가 없는 소스를 항상 유지하여 개발자들이 문제가 없는 소스로 작업할 수 있게 보장해주며, 릴리즈가 필요한 시기에 언제든지 릴리즈가 가능하도록 지원해준다. 

9)결과 분석 : 빌드와 테스트가 완료된 후에 테스트 결과를 통해서 문제가 있는 테스트를 개발자가 수정하도록 하고, 코드 인스펙션 결과를 PM이 검토하여 담당 개발자가 수정하도록 한다. 다음으로, 커버리지 분석 결과를 통해서 테스트가 부족한 부분은 PM이 담당 개발자에게 지시하여 테스트를 보강하도록 한다.

품질이 낮은 소프트웨어는 이용자에게 불편을 주는 것은 물론, 막대한 재산상의 피해를 입히고, 나아가서는 인명 및 국가 안보에까지도 지대한 영향을 끼칠 수 있기 때문에 보다 완벽한 테스팅이 요구되고 있습니다.