Technical Debt
기술 부채?
여러 블로그들이나 개발관련 문서를 읽다보니 기술 부채라는 글들을 종종 보게된다. 기술부채란게 무엇인지 알아보도록하자.
기술 부채(technical debt, design debt, code debt)는 현 시점에서 더 오래 소요될수 있는 더 나은 접근방식을 사용하는 대신 쉬운(제한된) 솔루션을 채택함으로써 발생되는 추가적인 재작업의 비용을 반영하는 소프트웨어 개발의 한 관점이다.
위키피디아 - 기술부채
즉, 어떠한 개발을 하는데 있어서의 시간은 오래걸리지만 쉬운 솔루션을 채택했을때 발생되는 추가적인 재작업의 비용이라 할수 있겠다.
조금 더 쉽게 기술부채를 풀어본다면, 기술적인 ‘빚’으로써 아래와 같은 내용이 되겠다.
- 코드의 시간 복잡도가 영 좋지 않지만 우선은 개발 일정이 빡새니 나중에 리팩터링하자.
- 기능을 추가했는데, 뭔가 전반적인 시스템 구조와 컨셉이 맞지않다. 하지만 시간이 없으니 나중에 보자
- 내가 코드를 구현했는데, 급하게 무엇인가 더 할게 있네 급한 불부터 끄자.
- 개발의 막바지에 코드를 확인해 보니 코딩 컨벤션이 엉망이네.. 이번에만 이렇게하지뭐.
- 거의 다 만들었는데 기획이 바뀌어서 다시 코딩을 해야겠네, 일단 기능만 돌아가게 해두고 나중에 리팩터링하자..
지금보니 개발공부와 프로젝트를 함에 있어서 한번쯤은 느꼇던 일인거 같다. 예를들어 일단 다른 개발 공부를 먼저빠르게 해서 포트폴리오 같은 결과물 부터 내놓고 나중에 구멍난 개념들은 매꿔야지 등등..
팀에 소속된다면
실무에 들어가 어느 팀에 소속된다면, 분명 위와같은 상황을 피할수 없는경우가 올것이다. 나는 그렇다면 어떻게 이런 기술 부채를 극복해야할것인가 팀(기획자, 디자이너, 개발자 등)과 의논하고 문제를 구체화 시켜 해결방안을 찾아야 하지않을까 하는생각이다.
결론, 기술 부채는 어떠한 데드라인에 의해 움직여지는 사회구조상 완전히 극복할수는 없지만, 최소화 하기위한 노력 예를들어 각각의 규칙들을 확실히해서 이것을 최소화 하는 방향으로 개발을 해야하지 않을까..? (코딩컨벤션, 리팩터링을 최소화 할수 있는 개발방법론..?)
