본문 바로가기
검색
  • 홈으로
  • 지식마당
  • 알기쉬운SW공학배우기
  •  

알기쉬운SW공학배우기

게시글 상세 보기
제목 [SW공학 동영상 42화] Technical Debt as a Core Software Engineering Practice 작성일 2017.04.17
첨부파일
조회수 453



Technical Debt as a Core Software Engineering Practice

참석자

Ipek Ozkaya - At the SEI she is the deputy lead for the Architecture Practices initiative.

요약

기술 채무 (Technical Debt)

소프트웨어 개발 프로젝트를 진행할 때, 초기에 제대로 처리하지 않은 일이 반복 주기에서는 문제점으로 나타나고, 이러한 문제점이 다른 수정사항이나 또 다른 문제를 나타낼 수 있어 원금에 이자까지 지불해야 하는 상황이 온다는 개념


이번 이야기는 기술 부채와 소프트웨어에서의 의미에 관한 것입니다. 수년에 걸쳐서 우리는 레거시 현대화, 애자일 적용, 아키텍처가 충분히 많은지, 어떤 것을 바꿔야 기술이 바뀌는지 문제를 겪은 많은 고객과 함께 했습니다.

다양한 고객과 다양한 문제에 걸쳐 한 가지 사실은 있습니다. 실제로 시스템에 남는 것을 표현할 수 없다는 것입니다. 예를 들어, 정말로 레거시를 업그레이드 해야 합니까? 정말로 아키텍처를 다시 만들어야 합니까? 그리고 어떻게 트레이드-오프를 결정해야 합니까? 결국 마지막에는 비즈니스 결정만 아니라 디자인 결정을 해야 한다는 것입니다. 하지만 일단 비용 측면을 고려하면서 트레이드-오프를 이야기하면 계속 반복될 겁니다. 그것은 커뮤니케이션 메커니즘뿐만 아니라 연관된 여러 연구 과제에서 기술적 부채를 찾는 시작입니다. 이것이 프로젝트의 착수 방법입니다.

기술과 비용을 결합해 생각한다는 것은 가슴에 와 닿는 사실입니다. 의사결정을 할 때 아키텍처의 역할입니다. 아키텍처를 만들고 아키텍처가 발전하는 모습을 이해할 수 있습니다.

기술적 부채는 긍정적 측면과 부정적 측면이 있습니다. 긍정적 측면은 누구하고나 공감할 수 있다는 것입니다. 특정 기술의 세부 사항을 잘 이해하지 못하는 관리자도 공감할 수 있고 개발자와도 공감합니다. 일관되게 공감할 수 있어야 트레이드-오프 할 수 있는 가장 어려운 기술적 부채를 알아낼 수 있습니다.

소프트웨어는 너무 빨리 변화합니다. 변화된 기술을 기업은 어떻게 대처할지 잘 모릅니다. 그것들은 아주 잘 만들어진 소프트웨어 아키텍처를 비즈니스뿐만 아니라 기술 분야 사이에서 가져옵니다.

뉴욕 증권 거래소와 다른 예들은 진행되고있는 많은 문제들이 있는데 모른 척 할 수 없습니다. 그 것은 기술적인 부채와 마이너한 에러, 아키텍처의 수정입니다. 꽤 많은 사람, 프로세스, 의사 결정이 있습니다. 그러나 긍정적인 측면에서 계속 무언가 진행되고 있다는 것을 알고 있는데 일부는 기술 결정, 측정, 모니터링을 하지 않고 도구를 사용하지도 않습니다. 분명히 올바른 방법입니다. 기술적 부채에서 모두 이익을 얻을 수는 없기 때문에 주의해야 한다. 합법적이거나 긍정적인 기술적 부채도 있기 때문에 해를 끼칠 수 있는 경우도 있습니다.

시스템에는 누적된 모든 결함이 있는데 어쩌면 그것이 어떻게 시작되었는지 조사하는 것이 낫습니다. 아니면 돌아가서 리팩토링을 해야 하는데 그것은 트레이드-오프 하려는 기술적 부채입니다. 실제로 돌아가서 트레이드-오프를 할 수 있지만 그 순간에 어떤 가치를 부여해야 합니다.

예를 들어 시스템에서 충돌이 나서 오류가 나타납니다. 살펴보니 오버플로우 문제입니다. 그리고 그것을 패치 합니다. 그것이 반복해서 나타나는데 실제로 외부 API인 것으로 밝혀졌고 이 API는 계속 문제를 일으킵니다. 결론적으로 이 외부 AP를 사용하는 아키텍처를 선택하고 리소스에서 찾고 패치 하는 방법 때문에 복잡해지지만 개발자가 결함으로 말하지 않는데 관리자는 문제라고 말합니다.

개발자들은 교육을 받지 못했습니다. 왜냐하면 새로운 개념이기 때문입니다. 개발자가 현재의 관리 방법으로 작업을 수행하기 때문에 개발자와 의견이 일치하지 않는 것처럼 보입니다. 이러한 교육은 개발팀이 재작업, 다른 결함, 다른 부작용의 관점에서 인식하고 명확하게 의사 소통하도록 돕는데 도움이 됩니다. 최고의 교육 체계는 그들이 이미 사용하고 있는 것을 사용하도록 하는 것입니다.

개발팀은 스프린트 관리, 반복 관리 도구를 사용하고 있습니다. 이미 결함 관리 메커니즘을 사용하고 있습니다. 두 번째는 자신이 만들고 있는 트레이드-오프 건을 이해하고 버그인지 시간이 오래 걸리는지 시스템의 부작용인지 상황을 파악하는 것입니다. 이미 개발자들이 다루고 있는 것들 입니다.

기술적 부채 관리가 요구 공학 및 관리, 소프트웨어 아키텍처 등을 갖추는 것을 소프트웨어 엔지니어링의 관행으로 간주합니다. 그것을 다른 차원에서 다룰 필요가 있습니다. 학부 수준에서 반드시 기술적 채무를 다룰 필요는 없습니다. 대규모 시스템이나 개발팀에서 사용할 수 있습니다. 복잡성이나 수정 가능성 위반과 같이 시스템에서 발생할 수 있는 문제를 인식하는 데 도움이 될 수 있습니다. 이러한 프로젝트를 통해 학생들이 상충 관계를 관리하는 방법에 대해 이해할 수 있습니다.

많은 조직이 기술적 부채 관리를 구체적으로 다루지는 못하지만 상당수의 사람들이 적절한 시기에 의사 소통할 수 있도록 해주고 있습니다. 산업 기반 시스템은 대형 시스템이기 때문에 외부 고객 및 소유자와 정보를 교환할 수 있어야합니다.

IEEE 의 최근 논문 중 "Future of Software Engineering"에서는 기술적 부채 관리가 조직이 더 많은 것을 지불해야하는 핵심 영역으로 나타냅니다. 경제적 관점과 기술적 관점에서 절충안을 생각할 때 아키텍처 생각, 관리자의 생각, 개발자의 생각에서 두드러지는데 항상 단기간 대 장기간의 트레이드-오프입니다. 수십 년 동안 알고 있는 내용이지만 우리가 제대로 의사 소통 할 수 있는 도구가 부족하기 때문에 계속해서 반복되는 것입니다.

이 포드 캐스트는 SEI 웹 사이트 sei.cmu.edu/podcasts 및 Carnegie Mellon University의 iTunes U 사이트에서 제공됩니다. 질문이 있으시면 info@sei.cmu.edu로 이메일을 보내주십시오.



댓글쓰기

등록

댓글보기 (총0 개)

홈페이지 내 게시된 정보 문의
  • 담당자 : 유봉식 책임
  • 전화번호 : 02-2132-1367
  • 이메일 : krystal78@nipa.kr