판교 구름 스퀘어에서 기술 부채를 바라보는 다른 시각 - 양수열 을 참여하고
세미나 내용을 공유해 드리고자 정리했습니다

기술 부채를 사라지게 할 수 있을까?

💩 NO → 우리는 레거시(💩)를 만드는 기계

우리를 항상 따라다니는 기술 부채에 대해서 부정적인 생각보다는
긍정적인 시각을 가질 수 있도록, 기술 부채에 대해 알아보고
우리는 어떻게 대처할지 생각해보는 시간을 가져보겠습니다.

스타트업에서 서비스 만들기 이상과 현실

이상적인 팀의 개발 플로우

🔄 설계 → 개발 → 회고 및 학습

위 플로우는 모든 개발팀의 이상향이지만 현실적으로 어렵습니다
이것은 어느 개발집단에 참가해도 마찬가지입니다.

현실

우리가 항상 직면하는 여러 사정(리소스 부족)으로 인해서
문서, 테스트 커버리지 등 모든 면에서 부족하지만
지금 해야 할 코딩을 나중으로 미루게 되는 현상이 발생합니다

현실 1 - 그럼에도 달려야한다

페달을 밟는 것이 힘들지만 그런데도 달려야 할 경우가 있다.

현실 2 - DDD (Deadline Driven Development) 데드라인 주도 개발

기술 부채 (후불 코딩)

기술 부채란 앞에서 보았듯이 지금 해야 할 코딩을 나중으로 미루는 것입니다

완성도 VS 적시성

개발자의 시각으로 보았을 때 이 부채는 언젠가는 갚아야 될 빛으로
항상 개발자의 마음속을 맴돌고 우리를 괴롭히죠
그럼 처음부터 기술 부채를 만들지 않는 완벽한 코드를 만드는 것과
아니면 부채가 생기더라도 빠르게 개발하여 코드를 제품화하는 것
둘 중에 무엇이 옳을지 한 이야기를 통해 생각해 보는 시간을 가져보겠습니다

방망이 깍는 노인

"더 깎지 않아도 좋으니 그만 주십시오." 

노인은 퉁명스럽게, "다른 데 가서 사우. 난 안 팔겠소." 

"그럼, 마음대로 깎아 보시오." 

"글쎄, 재촉을 하면 점점 거칠고 늦어진다니까. 물건이란 제대로 만들어야지, 깎다가 놓치면 되나."

깎던 것을 숫제 무릎에다 놓고 태연스럽게 곰방대에 담배를 피우고 있지 않는가. 
나도 그만 지쳐 버려 구경꾼이 되고 말았다. 
얼마 후에야 방망이를 들고 이리저리 돌려 보더니 다 됐다고 내 준다. 
사실 다 되기는 아까부터 다 돼 있던 방망이다.

작품 속 노인은 자신의 신념과 가치관에 맞지 않는 사람에게는 물건을 팔지 않습니다
더 좋은 구조와 완성도 높은 코드를 위해 제품 출시를 미루어 너무 늦게 제품이 제공된다면
그 제품을 기다리던 고객도, 회사도 사라지게 될 것입니다
우리는 장인이 아닌 회사에 고용된 프로그래머입니다
완벽한 코드보다 적절한 시점에 제품이 제공될 수 있는지에 초점을 맞추는 것이 중요합니다
그럼 이에 따라 발생한 기술 부채는 언제 해소할 수 있을까요?

빚을 내려면 주기적인 이자 상환이 가능해야한다

빚을 값을 능력이 되어야 빛을 낼 수 있는 것처럼 기술 부채도 마찬가지이고
원금을 갚는 것(기술 부채 해결)이 이자를 내는 것보다 이득인 시점은 회사가 성장할 때 반드시 오게 됩니다

이자

• 리팩토링
• 페어 프로그래밍 (버스 지수 감소)
• 테스트 커버리지 업

원금 상환

• 구조 개편
  • 비즈니스에 대한 인사이트가 있는 상태로 다시 구조를 설계하기
• 죽은 코드 정리하기
• 지속적인 마이그레이션

기술 부채는 기업마다 기준이 다릅니다

작은 회사라면 조금의 비용 손실(기술 부채)도 치명적이지만
큰 회사라면 어느 정도의 비용 손실(기술 부채)을 감수하고 새로운 사업을 진행하는 경우가 많습니다
결국 기술 부채는 회사 규모, 비즈니스에 따라 범위가 달라집니다

TL;DR

• 우리는 항상 레거시를 만듭니다
  • 레거시를 만들었다고 후회하지 말고 어떤게 문제였는지 경험합시다
• 기술 부채를 해결해야 할 시점이 올 때까지 꾸준히 이자를 내면서 기다립시다.
  • 회사가 성장하면 기술 부채를 해결하는 시점은 반드시 옵니다
• 오버테크놀러지 (방망이 깍는 노인)를 경계합시다
  • 제품은 적절한 시점에 제공되는 것이 중요합니다