기술부채를 해결하는 것이 돈이 될까?

개발팀에서 기술부채를 해결해야한다고 이야기하더라도 비지니스적 가치가 얼마나 되는지는 자세히 설명하지 않고 기술부채로 인해 생길 수 있는 문제만 이야기한다. 개발팀의 이야기를 들은 결정권자는 그런 문제보다는 비지니스의 성장이 중요하다고 생각하여 새로운 기능개발을 통해 비지니스 확장을 우선시 하게된다. 그렇게 이러한 상황이 계속되어 반복되게 되면 잦은버그와 장애로 개발자들의 불만이 쌓여서 결국 개발팀이 단체로 퇴사해버리거나 심각한 장애로 이어져 회사에 큰 피해가 생기는 경우가 많다.

 

이런 상황들은 개발자 커뮤니티에서 흔히 접하는 이야기들이기 때문에, 개발자들은 이를 특별한 사건으로 보지 않는다. 그러나 이런 상황에 처한 회사들은 비즈니스 연속성에 심각한 위협을 받게 되며, 때로는 큰 재정적 손실을 입거나 프로젝트가 완전히 망가지는 경우도 있다. 이에 대해 나는 왜 이런 심각한 손상까지 감수하면서까지 리스크를 관리하지 않는 것인가에 대해 궁금해졌다. 심도있게 고민한 결과, 제 생각은 이러한 리스크가 정량화되어 보이지 않기 때문에 이런 상황에 이르게 된다는 결론에 도달하였다. 이 글은 그런 리스크를 정량화하여 설명하려는 시도이다.

기술부채가 무엇이길래?

https://www.netsolutions.com/insights/what-is-technical-debt/

IT 분야에서 일하면, 개발자든 아니든 '기술 부채'라는 용어를 한번쯤 들어봤을 것이다. 가장 간단하게 '기술 부채'를 설명한다면, 이것은 '고물 부품'과 비슷하다. 왜 고물 부품이 생겨났을까? 원인은 여러 가지일 것이다. 시간이 흘러 자연스럽게 노후화되었을 수도 있고, 기능을 계속 추가하면서 생긴 일일 수도 있다. 아니면 개발팀의 역량이나 기술이 발전함에 따라 오래된 부분들이 고물이 된 경우도 있을 것이다. 기술 부채는 추상적인 개념이니, 복잡하게 생각하지 말자. 문제를 일으키는 것들, 그것이 바로 기술 부채다. 이제 기술 부채에 대해 어느 정도 이해했으니, 기술 부채로 인한 문제점들을 한번 살펴보자.

 

생산성 저하

IT 산업은 다른 산업과는 달리, 물질적인 자원보다는 인력에 의존하는 경향이 있다. 그 결과로, 다른 산업에 비해 인력에 대한 투자가 더 많이 이루어지며, IT 기업들은 개인의 생산성을 매우 중요하게 여긴다. 대규모의 개발 팀에서는 심지어 생산성을 높이기 위한 엔지니어링 팀이 별도로 구성되기도 한다. 이제 우리는 IT 분야에서 생산성이 어떤 중요성을 가지는지 알게 되었다. 다음으로, 기술 부채가 어떻게 생산성을 저하시키고, 그로 인한 리스크가 어떤 경제적 피해를 초래하는지 살펴볼 필요가 있다. 이를 통해 기술 부채의 경제적 가치를 더욱 명확하게 이해할 수 있을 것이다.

평균적으로 고품질의 코드는 저품질의 코드보다 버그가 15배 적고 개발 속도가 2배 이상 빠르고 일정준수의 불확실성이 9배 낮다고 한다.(물론 이런 평균은 환경, 규모, 사람에 따라 다름) 이제 최소 개발팀 인원을 5명 정도로 잡는다고 가정하고 리드 개발자과 백엔드 팀 3명, 프론트 2명이 존재하고 비중은 시니어(8년) 1명 미드(5년) 2명 주니어(1년) 2명으로 편성되어 있다.

개발자의 연봉 정보를 참조해보면, 각 경력에 따른 대략적인 연봉은 다음과 같다.

신입: 3,405만 원
1년차: 3,621만 원
3년차: 4,161만 원
5년차: 4,746만 원
8년차: 5,731만 원
10년차: 7,241만원

이 정보를 바탕으로, 8년차 서버 개발자는 월 4,775,833원, 5년차 개발자는 월 3,955,000원, 1년차 개발자는 월 3,017,500원을 인건비로 지출한다고 가정하자. 그럼 총 개발팀의 인건비는 달마다 약 1억 2천만원이라는 소비가 발생한다.

 

여기서 새로운 요구사항이 주어지고 이를 30일 동안 개발해야 한다고 가정해보자. 만약 저품질의 코드로 개발을 진행하면, 고품질 코드에 비해 개발 속도가 2배 느리다. 이는 인건비로 따지면 추가적인 1억 2천만원의 비용을 뜻한다. 또한, 고품질 코드의 프로젝트에서 버그 수정에 걸리는 시간을 하루라고 가정했을 때, 저품질 코드는 버그 발생률이 15배 많으므로 추가로 15일이 소요된다. 이는 약 6000만원의 추가 비용을 의미한다.

 

따라서, 고품질의 코드를 작성하는 것은 초기에 비용이 들어가더라도, 장기적으로 보면 더욱 효율적인 투자라는 것을 알 수 있다. 저품질의 코드는 추가적인 시간과 비용이 들게 되므로, 높은 품질의 코드 작성에 투자하는 것이 경제적으로도 이롭다는 주장이 합리적으로 느껴진다.

 

품질에 따른 인건비 차이

하지만 실제 비지니스에서는 더 복잡하기 때문에 비용보다 더 많을 수도 적을 수도 있다. 하지만 대략적으로 계산했을 때 인건비가 이정도 차이나는 것을 생각해보면 생산성 저하로 늘어나는 리소스에 대해 대해 깊이 생각해 볼 수 있을 것 같으니 넘어가겠다.

참조

https://codescene.com/blog/measuring-the-business-impact-of-low-code-quality

https://blog.greetinghr.com/for-hr-salary-example/#4-%EC%A7%81%EA%B5%B0-%EB%B0%8F-%EC%97%B0%EC%B0%A8%EB%B3%84-%ED%8F%89%EA%B7%A0%EC%97%B0%EB%B4%89

 

버그와 시스템 장애

시스템 장애로 발생하는 비용(참조: https://devops.com/real-cost-downtime/)

• 대기업들은 연간 계획되지 않은 시스템 장애로 평균 총 12억 5천만 달러에서 25억 달러의 비용을 지불한다는 사실이 분석에 따라 밝혀져 있다. 
• 인프라스트럭처의 오류에 대한 평균 시간당 비용은 100,000달러이며
• 애플리케이션의 오류로 인해 발생하는 평균 비용은 시간당 500,000달러에서 1백만달러에 이른다.

시스템의 장애나 오류는 기술적으로 불가피한 사항이다. 심지어 가장 안정적인 설계와 구축이 이루어진 시스템이라도 장애는 발생한다. 심지어 전 세계적으로 유명한 IT 기업인 구글조차도 버그와 시스템 장애를 겪는다. 그렇다면, 이러한 장애에 대응하는 유일한 방법은 발생할 때마다 대응하는 것일까? 아니다, 다양한 예방 방법들을 통해 장애가 발생하더라도 피해를 최소화하는 방법들을 활용하고 구축함으로써 서비스의 품질을 유지할 수 있고 고객의 만족도를 높일 수 있다.

겉으로 보이지 않는 것들

개발자들이 왜 기존에 잘 작동하는 기능을 다시 개발하는지, 이해하기 어려울 수 있다. 그래서 나는 이를 음식점의 주방으로 비유해보려고 한다. 자신이 큰 음식점을 운영한다고 상상해보자. 요리, 서빙, 청소, 이 모든 과정이 하나의 방에서 일어난다. 그런데 어느 날, 요리하는 공간에서 화재가 발생했다면 어떻게 될까?

 

요리, 서빙, 청소가 모두 한 방에서 이루어지는 음식점이라면, 그 곳은 큰 피해를 입을 것이다. 하지만 만약 요리, 서빙, 청소 공간이 잘 분리되어 있다면, 화재는 요리 공간에만 한정되고, 서빙과 청소 공간은 상대적으로 안전할 것이다.

 

손님들에게는, 음식점이 한 공간에서 운영되든, 여러 공간으로 분리되어 운영되든 큰 차이가 없을 수 있다. 왜냐하면 그들에게 중요한 건 맛있는 음식을 먹는 것이니까. 하지만 음식점을 운영하는 사람의 입장에서는, 장기적으로 안정적인 운영을 위해 공간을 잘 분리하고, 화재 예방장치를 설치하는 등 여러 방안을 고려해야 한다.

 

개발자들이 기존 기능을 재개발하는 이유도 여기에 비유할 수 있다. 그들은 시스템 내부의 '화재'를 예방하고, 각 기능을 잘 분리하고 관리하기 쉽게 구축하여 시스템의 안정성을 높이려고 노력한다. 사용자 입장에서는 이런 내부 작업이 보이지 않지만, 장기적으로 보면 이러한 작업이 시스템의 품질을 향상시키고, 잠재적인 위험을 줄여준다는 것을 이해해야 한다.

 

고객 관점으로 보는 버그

앱 서비스를 운영하면서 영향을 가장 많이 받는 요소 중 하나는 바로 리뷰이다. 그래서 앱 서비스를 운영하는 기업들은 좋은 리뷰를 받기 위해 갖가지 장치들을 설치해놓고 사용자의 행동 패턴을 분석하여 좋은 리뷰를 남길 수 있도록 유도하기도 한다. 하지만 이러한 장치가 있어도 안좋은 리뷰들은 달리기 마련이다. 구글에서 조사한 바에 따르면 별 1점 리뷰를 남길 때 42%가 앱의 안정성이나 버그를 언급했다. 그외에도 흥미로운 연구 결과들이 있으니 살펴보자.

• 한 연구에서 사용자의 84%가 두 번의 충돌을 본 후 앱을 삭제 했다.
• 또 다른 연구에서 연구원들은 응답자의 70% 이상이 버그가 있는 앱의 가장 큰 문제점으로 정지 및 충돌을 꼽았으며 44%는 앱을 즉시 삭제할 것이라고 밝혔습니다.
• Bain & Company의 한 연구에 따르면 고객 유지율이 5% 증가하면 수익이 25-95% 증가한다는 사실을 발견했다 .

위의 자료들을 보면 충분히 비지니스가 성장하기 위해서는 기능 개발도 중요하지만 서비스의 안정성도 못지않게 중요하다는 것을 알 수 있다. 그렇기 때문에 길게보면 개발팀에서 기술부채들을 잘 관리하는 것은 회사의 최소 25% 이상의 수익을 벌어다 주는 것이라고 말할 수 있을 것이다.

 

참조

https://www.bugsnag.com/blog/how-application-stability-impacts-business-growth/

The one product metric that drives customer acquisition, retention, and revenue

 

개발자 관점으로 보는 버그

개개인 마다 다르겠지만 일반적으로  개발자들은 소프트웨어를 개발하면서 버그와 기술부채가 생기는 것은 당연하게 생각한다. 그럼 이런 문제를 발생하게 방치하는 것인가? 아니다. 개발자들은 버그와 기술부채가 생기는 것을 최소화하기 위해 코드를 테스트하기 위한 코드를 짜거나 서로의 코드를 보면서 리뷰해주는 방법 등 소프트웨어 품질을 일정 수준으로 유지하여 버그와 기술부채를 최소화한다. 여기서 이런 안전장치 역활을 해주는 프로세스나 코드 없이 지속하여 프로젝트를 운영하면 개발팀에게는 얼마나 큰 손실이 될까?

 

IBM Almaden 연구 센터에 따르면 테스트를 작성한 팀이 작성하지 않은 팀보다 15% ~ 35% 오래 걸렸지만 코드 품질은 60%~90% 더 좋다는 연구결과가 나왔다. 현재 하고 있는 프로젝트가 소규모라면 차이가 크게 없다고 느껴질테지만 점점 프로젝트가 커질수록 체감이 될 것이다.

 

이러한 사실을 어느정도 알고 있는 결정권자는 문제가 생길 수 있는 것에 대해 내가 책임 질테니 빠르게 개발해달라고 이야기하는 경우도 종종 있다. 하지만 이러한 이야기는 개발팀에게는 반쪽짜리 책임밖에 안된다고 생각한다. 결국 저품질로 일어나는 버그와 장애들은 피해는 회사가 감당하더라도 해결하는 과정은 결국 개발팀을 통해 대응 해야된다. 그래서 책임을 지겠다는 이야기를 하더라도 퇴근시간이후 긴장상태를 계속 유지해야하고 장애를 대응해야되는 개발팀의 입장을 100% 대변해주지 못한다.

 

참조

https://www.microsoft.com/en-us/research/blog/exploding-software-engineering-myths/?from=https://research.microsoft.com/en-us/news/features/nagappan-100609.aspx&type=exact

 

사람 부채

"기술 부채"라고 하면, 대부분은 코드의 질이나 아키텍처의 설계 같은 기술적인 요소를 생각할 것이다. 하지만 더 중요한 부채는 사람과 관련된 부분이다. 이를 바로 이해하려면 우리가 함께 항해하는 배에 대한 이야기를 생각해보자.

 

자신이 이 배의 선장이라고 상상해보자. 항해사와 선원들이 함께 있고, 모두가 각자의 역할을 수행하며 배는 순조롭게 나아가고 있다. 그런데 어느날, 항해사가 병으로 누워버리고, 일을 할 수 없게 된다면 어떻게 할 것인가? 당연히 새로운 항해사를 구해야 할 것이다. 하지만, 만약 이 항해사가 여태까지 항해의 경로를 제대로 기록하지 않았다면? 새로 온 항해사는 배의 현재 위치를 알아내려고 해도, 이전의 기록이 없기 때문에 위치도 항해의 이상적인 항로 운행 방향도 알 수 없을 것이다. 결국 배는 그대로 멈춰서서 더이상 나아갈 수 없게 될 것이다.

 

소프트웨어 개발도 비슷하다. 좋은 코드와 설계로 품질을 유지하는 것도 중요하지만, 더 중요한 건 프로젝트의 문서화와 도메인 지식 공유, 그리고 프로젝트의 히스토리를 잘 관리하는 것이다. 이런 작업이 잘 되어 있다면, 한 명의 개발자가 아프거나 퇴사하더라도 다른 사람이 그 자리를 채워 프로젝트를 계속 진행할 수 있을 것이다. 이런 부분을 소홀히 하다 보면, 한 사람이 빠져나가면 프로젝트 전체가 흔들리고, 결국엔 큰 손해를 보게 될 수도 있다는 것을 기억해야한다.

 

부채로 인해 드는 비용

회사에서는 개발자 한명이 퇴사하게 되면 새로운 개발자를 채용해야 할 것이다. 예시로 5년차 미들급 개발자를 뽑는다고 가정해보자. 미들급 개발자의 평균 연봉은 4,746만원이다. 채용 플랫폼을 사용한다면 연봉의 7%인 332만원의 수수료를 채용 플랫폼에게 제공해야한다. 여기서 보통 3개월의 수습기간을 가지게 되기 때문에 약 395*3=1185만원을 지출하게 된다. 이건 채용하고 정규직으로 채용하는데 드는 순수 비용만 계산했을 때 1517만원이 들게 되는데 여기서미스매칭까지 발생하게 된다면 1517만원의 추가 비용의 지출하여 3034만원 정도를 더 사용하게 된다. 

 

여기서 기업 입장에서 크게 문제가 되는 것는 채용이 아니라 프로젝트의 진전이 없는 상황에 지속적으로 시간과 비용을 소모한다는 것이다. 개발자를 채용하는데 보통 1달이상의 시간을 소모하게 된다. 그리고 성공적으로 개발자를 채용한다고 해도 최소 한달 이상은 그 프로젝트를 분석하는데 시간을 많이 할애해야 하는 시간이 필요하다. 그렇게 프로젝트는 최소 2달이상의 진행이 멈추게 되고 여기서 프로젝트관리 조차 안되어 있다면 개발 속도는 절반 이상으로 줄어들게 되면서 비지니스의 성장에 브레이크를 걸고 말 것이다.

 

참조

https://help.wanted.co.kr/hc/ko/articles/8054308635417-%EC%9B%90%ED%8B%B0%EB%93%9C%EC%97%90-%EA%B3%B5%EA%B3%A0%EB%A5%BC-%EC%96%B4%EB%96%BB%EA%B2%8C-%EA%B2%8C%EC%8B%9C%ED%95%A0-%EC%88%98-%EC%9E%88%EB%82%98%EC%9A%94-

보안 부채

https://zdnet.co.kr/view/?no=20230322090326

현재 우리나라는 생각보다 보안에 대해 중요하게 생각하지 않고 넘어가는 경우가 많다. 개인적인 생각으로는 보안 부채는 다른 기술부채와 달리 실제 공격을 당하기 전까지는 손해보는 것이 눈에 보이지 않기 때문인 것 같다. 병처럼 눈에 보이지 않는다고 부채를 계속 키워나가다 보면 결국 큰 병으로 돌아와 엄청난 피해를 입게된다.

한국인터넷진흥원의 '사이버 침해사고 피해에 대한 경제·사회적 비용 추정 연구'에 따르면 2020년 사이버 공격을 받은 101개 기업의 비용 손실은 약 7000억원으로 추산됐다.

기업 규모별 피해액은 대기업, 중견기업이 각각 130억원 안팎이었다. 소기업의 피해 규모가 6703억원으로 가장 컸다. 기업당 연간 피해액은 대기업이 4억원, 중견기업이 5970만원, 소기업이 5244만원으로 추산됐다. 소프트웨어(SW), 하드웨어(HW) 대체는 물론, 생산·매출, 데이터 재생산 등 부문에서 손실이 발생했다.

위의 뉴스를 보면 피해액이 대기업, 중견기업 보다 상대적으로 보안이 취약한 소기업의 피해액 규모가 51배 더 큰 것을 알 수 있다. 이를 통해 우리는 해커가 시스템의 규모가 큰 시스템을 공격하지 않고 오히려 취약한 시스템을 먼저 공격함으로써 큰 피해를 입힌다는 것을 알 수 있게된다. 아래의 추가적인 사례를 봐보자

국내 A제약사의 전산시스템이 멈췄다. 영업, 물류 등 바쁘게 움직여야 할 사업 조직이 한순간 마비됐다. 사업 현황을 수기로 관리하는 등 일대 혼선을 빚었다. 전산망을 먹통으로 만든 원인은 랜섬웨어다. 해커는 전산망을 정상화하는 조건으로 300만달러(38억원)를 요구했다. 탈취한 데이터를 외부에 유출하지 않고 보안 취약점 분석보고서 제공하는 데 650만달러, 700만달러를 추가로 요구했다. 협상 기한을 넘기면 몸값을 배로 불리겠다고 협박했다.

위의 기사를 보면 해커는 38억원의 요구에서 그치지않고 총 212억원의 금액을 추가적으로 요구하면서 더 큰피해를 끼친 것을 볼 수 있다. 주기적으로 취약점을 보완하고 보안 시스템을 점검했다면 생기지 않았을 피해가 방치하게 되면서 더 큰 피해로 이어진 것을 볼 수 있다. 이처럼 보안과 관련된 기술 부채는 갚지 않다보면 감당하기 어려운 큰 리스크가 되어 돌아오기 때문에 되도록이면 피해를 입기 전에 갚는 것이 좋다.

 

참조

https://www.etnews.com/20230102000047

[신년기획] 공공기관 해킹시도 118만건…사이버 공격에 멍들어

기술자산과 기술부채

기술 자산과 기술 부채의 차이는 뭘까? 좋은 코드, 좋은 설계, 완벽한 보안과 문서화가 기술 자산일까? 나는 좋지 않은 코드라도 문서가 없는 프로젝트라도 사용하는 사용자들이 존재하고 가치를 창출한다면 기술자산이라고 생각한다. 그렇기 때문에 나는 기술자산과 기술 부채는 따로 떨어져 있는 것이 아니라 하나로 되어 있는 공동체라고 생각을 한다. 그래서 자산을 키우면 부채도 같이 따라오게 되어 있고 부채를 줄이면 자산도 커지게 된다. 아래의 비유를 보면 좀 더 쉽게 이해할 수 있을 것 같다.

 

기술부채를 돈과 비교하자면 금리가 계속 오르는 대출로 비교할 수 있을 것이다. 기술 부채는 지속적으로 이자를 요구하고 그이자들은 일정 리소스를 계속 요구한다. 기술부채는 시간이 지나면 지날수록 더 커지게 되기 때문에 이자만 갚는 것으로는 한계에 도달하게 된다. 그렇기 때문에 주기적으로 원금을 상납해줘야지 지속적으로 유지할 수 있고 더 크게 키울 수 있는 기술 자산이 되는 것이다. 이글을 읽으면서 기술 부채에 대해 비지니스적으로 가치가 충분함을 이해하고 개발팀과 주기적으로 소통하면서 개발팀이 단체로 나가는 상황까지 나오지 않았으면 하는 바램이다.