Swifter {Swift Developer}

메뉴

기술적 부채를 줄여보자

프로젝트가 길면 길수록 기술적 부채를 언제 어떻게 갚을지가 과제가 된다. 리팩토링은 어느 시점에 하는지등 이는 프로젝트가 길 경우에 발생하는 문제이지만 나름대로 몇십년간 개발자로 일해오면서 기술적 부채의 종류를 정리해보고 어떻게 대응했었는지를 정리해보고자 한다.

개발은 항상 시간이 부족하다

  • 프로젝트 시작 시점에 모든 요구사항을 모을 수는 없다.
  • 요구사항을 모았다고 해도 그것이 전부라고 반드시 말하기 어렵게 그만큼 변한다.
  • 일은 언제나 주어진 시간과 비용보다 많다.

위와 같이 우리 개발자들의 개발에서는 시간이 없는 것이 일반적이라는 것을 알 수 있다. 실제 기술적 부채가 많은 프로젝트일수록 그런 경향도 강하다고 본다. 그렇다면 기술적인 부채를 줄이는 방법을 찾지 않으면 안되기에 나름대로 정리해본다.

기술적인 부채를 갚아가는 빈도

기술적인 부채를 갚아가는 빈도에 따라 걸리는 시간과 금액은 기술적인 부채를 모아 저축한 시간에 비례한다. 이렇게 쌓인 기술적인 부채라도 리펙토링등의 기술적인 부채를 갚아 나가는 빈도에 따라 한번의 리팩토링 작업으로 인해 걸리는 범위와 시간이 달라진다. 또한 리펙토링등의 간견이 길면 길수록 갚아야할 기술적인 부채도 점점 커지는 경향이 있다.

부채를 갚는 빈도가 많은 것이 좋은가?

리팩토링등의 빈도는 많이 하는 것이 좋다고 본다. 예로 연간 단위로 부채를 쌓았다면 한번의 리팩토링이 수개월이 걸리는 수준이 되어버린다.이렇게 되면 한번할때마다 규모가 커져서 프로젝트 관리자의 최종 승인을 받기 어려워진다. 가능하면 조금씩 자주 채무를 줄여 쌓이지 않도록 리팩토링을 하는 것을 추천한다.

실제로 몇년동안 쌓인 기술적인 부채는 그냥 새로하는 프로젝트정도로 되어 버릴수 있고, 새로운 것을 하려고 해도 기술적인 부채를 해소하지 않으면 아무것도 할 수 없었던 적이 있었다.

기술적인 부채의 종류

기술적인 부채라고 해도 코딩 수준만 보는 것이 아니라 다양한 종류가 존재한다.

  • 코딩 구현의 부채
  • 부하가 생기지 않는 구현에 대한 제약의 부채
  • 버전 업그레이드하려는 언어나 라이브리, 운영체지의 방치로 인한 부채
  • 트렌드가 바뀌어 갈아탈 필요가 있는 경우의 부채
  • 공유가 잘 안되어 구현 내용의 블랙박스화에 의한 부채

코딩 구현의 부채

  • 구현당시의 자신의 기술 수준의 문제
  • 정확한 납기일을 지키지 못한다
  • 처음 사용하는 라이브러리였다

자주 위와 같은 변명을 하는 개발자들이 있는데 그 외 다양한 요인도 있겠지만 전혀 부채가 없는 개발로 끝내는 것은 어렵다고 본다. 어떤 수준의 개발자라도 어느정도 부채를 줄일 수 있지만 그게 어렵기도 할 수 있다.

부채의 종류

  • 하나의 함수 행수가 100행을 넘는다
  • 함수 인수가 4개를 넘었다
  • 하나의 클래스 처리를 모으고 너무 큰 클래스를 만들었다
  • 설계를 잘 하지못해 클래스 관계가 엉망이다

부채를 갚는 방법

세밀한 리펙토링 빈도를 마련하여 개발에 적용하는 경우에는 반드시 리팩토링을 예약하는 등에 의한 갚는 것이 가능하다. 또한 완료일에 맞춰 우선 개발후 리팩토리 기간을 반드시 마련하는 것도 좋다고 본다. 미리 부채를 만들지 않기 위해서라도 팀의 소스코드 검증은 매우 효과적이다. 여러 사람의 검토를 받고 최대한 어설픈 구현을 하지 않도록 개발해 나간다.

 

부하가 고려하지 않았을 경우의 구현에 의한 제약등의 부채

  • 데이터베이스 부하가 올라가거나 서버 부하가 올라가서 부하대책 대응만하고 신규 개발은 완전히 멈춘다.
  • 데이터베이스를 일괄적으로 업데이트하고 싶지만, 인덱스등이 충분히 고려되지 않아 원래 업데이트를 할 수 없다.

부채를 갚는 방법

서버등의 부하대책에 관한 경우, 서비스 운영도 참여하여 부하 수준에 따라 바로 대책을 취한다. 이런 경우 설계 검토등을 통해 실제 코딩에 들어가기 전에 한번 전문가에게 상담받는 것을 추천한다.

 

버전 업그레이드하려는 언어나 라이브러리, 운영체제의 방치에 의한 부채

이는 상당히 작업이 무거워지기 때문에 심적으로 내키지 않는 경우도 있지만 정말 내버려두면 보안상으로 뼈아픈 상황이 올 수 있다. 또한 매번 유지 관리의 규모가 커지는 경향이 있는 것이 버전 업데이트이기 때문에 주의해야한다.

  • 단순한 버전 업그레이드를 하지 않아 버전업그레이드가 순조롭지 않게 되는 경우 (호환성이 없거나 업데이트지원이 안되는 등)
  • 프레임웍과 라이브러리 자체를 수정하여 버전업그레이드를 할 수 없게 된 경우

부채를 갚는 방법

최근 다양한 버전관리 도구가 나온 것으로 관리도 어느정도 쉬워진 환경이 되고 있기 때문에 도입하지 않는 경우 도입을 하자. 또한 구성관리도구등으로 구성을 관리하고 환경을 만들어 버전관리를 가급적 쉽게 테스트할 수 있는 환경을 만들어 둔다. stackoverflow등의 문서 자료등은 참고만 하되 필수로 적용하지는 않는다.

 

트랜드가 바뀌어 갈아탈 필요가 나온 경우의 부채

  • 프론트엔드 개발도구의 변화가 심하고 마이너리티가 되어 버릴 때 (Gulp와 Grunt같은)

부채를 갚는 방법

따라잡기 위해 적극적으로 할 수 있는 프로젝트라면 비교적 기술선택의 폭이 쉽다. 필자의 지인들이 어떤 기술을 선택하는 사람을 비난하지 않으며 초기에 적극적으로 도입하려는 문화가 팀에 없으면 그것은 큰 손실이다.

 

공유가 잘 안되어 구현 내용의 블랙박스화에 의한 부채

잦은 퇴사와 공유의식에 대한 부족으로 구현내용에 대한 블랙박스화는 어느정도 막을 있을지에 대한 이슈가 있는데 아무래도 많은 개발자가 바뀌면 어쩔수 없는 경우도 많다.

  • 문제가 발생한 부분의 사양을 모르기 때문에 그만큼 시간도 걸린다.
  • 새로운 기능 개발시 몰랐던 기능이 나오고 그에 대한 대응으로 인해 일정도 지연된다

부채를 갚는 방법

개발 담당자가 있다면 개발담당자에게 맡겨 조언을 받는다. 설계시 가능한 많은 사람들에게 검토를 받고 예방책으로는 설계단계에서 많은 사람들과 소통하고 리뷰를 요청한다. 여러 사람이 사양에 대해 알고 있는 상태에서 최대한으로 만든다.

부채를 갚기 위한 협상

기술적인 부채를 갚기 위해 필요한 것은 사실 시간이다. 시간은 한정되어 있기 때문에 다음으로 원하는 이슈를 위해 부채를 갚기 위한 시간을 확보하는 노력이 필요해지고 있다. 아무리 조심하더라도 부채라는 것은 반드시 발생하는 것이기 때문에 부채를 갚기 위해 프로젝트 담당자는 이를 갚기 위한 시간보장을 협상을 해야 한다.

 

프로젝트 담당자와의 협상

대부분의 프로젝트에서 관리자나 담당자가 엔지니어가 아닌 경우가 많다. 보안적인 부분의 시간은 상대적으로 결정하기 쉽지만 리팩토링을 위한 시간을 달라는 협상은 좀처럼 엔지니어입장에서는 어렵다. 그래서 개인적으로는 협상 방법으로는 여러 사람과 같이 협의해서 처리하는 방법을 추천한다.

엔지니어중 기술적인 부채를 줄이기 위함에 대한 소중함을 아는 사람에게 문의하기

담당자와 최대한 대등하게 말할 수 있는 엔지니어와 상담한다. 이 때 부채를 갚기 위해 같은 의견을 가진 엔지니어를 모으는 것도 좋다. MTG형식, 그냥 잡담하듯하는 것도 좋다고 본다. 이는 각각의 팀에 맞는 방식을 상담해 본다. 엔지니어도 똑같이 말해줄 수 있다면 기술적인 부채를 갚기 위해 시간 확보가 더 쉬워진다.

결국은 다시 담당자(책임자)에게 돌아간다

그렇게 해도 기술적인 부채를 갚기 위함을 인정하지 않는 경우 마음대로 해버리거나 신규개발일정에 포함하는 방법도 있다고 본다. 그러나,이런 상황이 계속된다면 엔지니어의 동기부여에는 악영향을 준다. (보통 개발자는 자기개발을 고려하기 때문이다)

결국은 점점 팀 개발은 기술적인 부채부분이 매번 빈번해져 제품출시는 늦어지고 개발이 좀처럼 진행되지 않는다.

velocity-table

이런 상황이 계속되면 결국은 우수한 개발자는 팀에 남아 있지 않게 된다.

 

기술고문으로써의 부채 절감

CTO 및 기술 관리자와 같은 입장에 있는 사람은 이런 문제에 적극적으로 마주해야 한다. 이런 분들이 이를 마주하지 않으면 내부적으로 누가 기술적인 부채를 갚을려고 할지 프로젝트 담당자와 협상이 가능할까? 또한 회사의 주요 프로젝트등에서는 개발안건이 특히 활발하다. 그런 프로젝트에 마지막으로 개발이 진행되지 않거나 엔지니어가 퇴사해버리는등 위험 회피를 위해서라도 적극적으로 임해야 한다.

 

기술적인 채무를 갚기 위한 것은 혼자서는 불가능하다. 우리는 개발단계에서 설계검토나 코드리뷰등 출시되기 전에 가능한 채무를 만들지 않는 방법도 있기 때문에 이를 적극적으로 도입하여 부채를 만들지 않도록 팀전체가 올바른 길을 가고 있는지를 생각해야 한다.

Facebook Comments

카테고리:   Swift 3.0

댓글

죄송하지만 댓글은 닫혀 있습니다.