loading...

‘코드 리뷰’ 없는 코드는 ‘기술 부채’를 가중시킬 수 있다

코드 리뷰 없는 코드는 기술 부채를 가중시킬 수 있다

이 글은 IDG의 아티클을 전재하여 제공합니다.
[원문보기] : https://www.itworld.co.kr/t/62082/IT

기술 부채는 성능 및 코드 가독성, 기타 지원 요소 개선에 드는 비용처럼 규모가 작을 수도 있지만, 곧 사용이 중단될 API나 CI/CD가 부족한 애플리케이션, 자동화된 테스트가 거의 없는 서비스, 혹은 운영에 영향을 주는 구형 시스템은 대규모 기술 부채를 낳을 수 있다.

소스와 크기, 영향에 관계없이 IT팀은 기술 부채를 측정하고 관리하며, 줄여야 한다. 또한, 추가 기술 부채 방지 및 제한 조치를 취하며 베스트 프랙티스를 시행하는 것도 중요하다.

액스웨이(Axway)의 부사장 루비 레일리는 오늘날 기술 부족과 심각한 재정 상태 때문에 무엇보다도 기술 부채를 줄이고 해결하는 것이 더 중요하다고 강조했다. 레일리는 “기술 부채를 줄이는 것이 CIO에게 가장 우선시될 것이다. 현재 인플레이션과 대퇴직, 직원 퇴사에 따른 인력난에 직면한 CIO는 새로운 프로젝트에 자금을 댈 운영 효율성을 찾아야 한다. 유지보수에 드는 지출을 줄이기 위한 기술 통합이 한 가지 방법이 될 수 있다”라고 말했다.

필자는 레일리에 동의한다. 항상 어려운 작업이지만, 개발팀은 기술 부채를 줄이기 위해 충분한 시간을 할애하고 새로운 소스 도입을 최소화하는 조치를 취해야 한다. 민첩한 개발팀 및 데브옵스(DevOps)를 따르는 기업은 이런 관행을 검토하고 고려해야 한다.

개발팀의 기술 부채 예방 관행

런치다클리(LaunchDarkly)의 CTO인 존 코두멀은 “소프트웨어 개발에서는 어쩔 수 없이 기술 부채가 발생하지만, 시간이 지나면서 기술 부채 감소 비용을 상환하는 정책과 관행, 프로세스를 수립함으로써 기술 부채를 방지할 수 있다. 다른 작업을 멈추고 산더미처럼 쌓인 빚에서 벗어나려고 애쓰는 것보다 훨씬 더 나은 방법이다”라고 말했다.

코두멀은 타사 종속성에 대한 업데이트 정책 및 주기 수립, 워크플로우 및 자동화를 사용해 기능 플래그의 라이프사이클 관리, 서비스 수준 목표 설정과 같은 몇 가지 관행을 추천했다.

새로운 기술 부채의 발생 가능성을 줄이려면 다음과 같은 베스트 프랙티스를 검토할 필요가 있다.

 • 명명 관행, 문서화 요건, 참조 다이어그램 표준화
 • CI/CD 및 테스트 자동화를 통해 릴리즈 횟수 증가 및 품질 개선
 • 개발자가 많이 사용하는 기술과 패턴으로 리팩토링 개발
 • 개발자가 데이터와 논리 및 경험을 코드화할 위치를 알 수 있도록 아키텍처 정의
 • 개발자의 코딩 관행 개선을 위한 정기적인 코드 검토 수행

데브그래프(DevGraph)의 최고책임자 라비 두두쿠루는 소프트웨어 개발 관리자가 베스트 프랙티스를 만들기 위해서는 개발자와 일대일로 협력해야 한다고 주장했다. 두두쿠루는 “개발자 코칭은 기술 부채를 줄이는 데 가장 중요하다. 개발자가 똑같은 실수를 반복하면 QA는 매번 우회 해결책을 마련한다. 개발자가 새로운 코드를 만들수록 안 좋은 코드는 유지되거나 증가한다”라고 말했다.

또한, 두두쿠루는 “훌륭한 관리자는 개발자의 코드를 분석해 패턴을 발견하고 이들과 함께 변경함으로써 현재 코드와 미래의 모든 코드를 개선해 기술 부채를 크게 줄일 수 있다”고 조언했다.

더 나은 계획 및 측정으로 새로운 부채 감축

나인투쓰리디지털벤처스(NineTwoThree Digital Ventures)의 CEO 앤드루 아만은 기술 부채를 줄이는 것과 관련해 “첫 번째로 해야 할 일이자 가장 중요한 것은 적절한 계획을 세우고 측정하는 것이다. 그다음에는 정리에 소요되는 시간은 제한하고, 실행에 더 많은 시간을 할애하도록 허용하는 절차를 표준화하는 것이다”라고 설명했다.

대부분 개발팀은 계획에 더 많은 시간을 들이고자 하지만, 제품 소유자나 개발 관리자, 경영진에게는 계획이 구체적으로 어떻게 기술 부채를 줄이고 최소화하는지 잘 와닿지 않을 수 있다. 개발자는 계획을 세울 때 아키텍처와 구현에 대해 논의하는 경우가 많다. 이런 논의는 대개 기술적인 세부 사항에 관한 것이다. 하지만 제품 소유자와 비즈니스 이해관계자는 이같은 기술적인 논의를 이해하지 못하거나 관심 있게 생각하지 않을 수 있다.

따라서 계획에 더 많은 시간을 들이려면, 리더에게 수립한 계획에 대해 피드백을 제공하는 것이 중요하다. 필자는 다음 3가지를 제안한다.

• 제품 소유자 및 비즈니스 이해관계자와의 협업 브레인스토밍 세션 일정을 세운다. 이 세션을 활용해 여러 구현 옵션을 검토하고, 기술 부채를 줄이는 옵션과 유지보수, 지원 및 향후 재작업이 필요한 다른 형태의 부채를 발생시킬 수 있는 것 등을 포함한 절충안을 논의한다.

• 스토리 포인트를 가진 민첩한 사용자 스토리를 측정할 때, 개발자는 복잡성과 노력을 측정치에 반영해야 한다. 새로운 기술 부채를 낳는 스토리에 대해서는 추후 기술 부채 해결에 필요한 복잡성을 반영해 측정치를 더 높게 잡아야 한다.

• 뒤늦게 생각나지 않도록 기술 부채를 측정하고 관리하는 접근법을 식별해야 한다. 일부 기업은 기술 부채가 있는 사용자 사례와 코드, 기타 아티팩트를 태그한 후, 기술 부채 수치를 계산한다. 민첩한 원칙과 거버넌스 모델을 정의해 제품 소유자가 기술 부채를 줄이기 위해 우선순위를 조정하는 기업도 있다.

개발팀은 프로세스와 수치를 정의해 기술 부채를 해결하지 못할 때 처할 위험에 대해 비즈니스 스폰서를 더 쉽게 교육할 수 있다.

아키텍처 부채 감소를 위한 기술 최적화

지난 10년 동안 3계층 웹 아키텍처와 SQL 데이터베이스는 개발팀을 많은 애플리케이션이 제대로 작동하지 않는 제한된 구조로 몰아넣었다. 지금은 SQL, 키 값, 컬럼형, 그래프 및 기타 데이터베이스 아키텍처를 비롯한 여러 클라우드 데이터베이스 중에서 선택할 수 있다. 마이크로서비스에는 서버리스 아키텍처를 포함한 여러 구축 옵션이 있으며, 개발자는 로우코드/노코드 또는 여러 자바스크립트 프레임워크 중 하나에서 사용자 경험을 구현할 수 있다.

너무 많은 아키텍처와 개발 패턴을 선택하면 상당한 개발 기술과 유지 비용이 필요하기 때문에 망하는 지름길이 될 수 있다. 하지만 개발팀을 모든 아키텍처에 적합한 단일 아키텍처로 제한하면 우회 방안을 마련하거나 사용자 환경, 성능, 확장성, 보안을 손상시킬 수 있다.

최적의 기술을 선택하려면 개발팀은 구현 방안에 대해서도 브레인스토밍해야 한다. 최적의 데이터 모델은 무엇이고 개발자가 마이크로서비스로 얼마나 세분화해서 구축해야 하며, 구현 검증에 얼마나 많은 테스트 시나리오가 필요하고, 맞춤형 사용자 경험이 로우코드/노코드 구현 옵션에 비해 충분한 비즈니스 가치를 제공하는 경우는 언제인지 등을 논의할 필요가 있다. 개발팀이 이같은 설계 고려사항을 검토하지 않으면 기술 부채가 발생할 가능성이 더 커진다. 계획 수립에 충분한 시간을 투자하고 적절한 아키텍처를 선택하며, 데브옵스 자동화 구현 및 개발 표준 향상을 통해 새로운 기술 부채의 위험을 줄일 수 있다.



IDG logo

▶   해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자에게 저작권이 있습니다.
▶   해당 콘텐츠는 사전 동의 없이 2차 가공 및 영리적인 이용을 금하고 있습니다.


이 글이 좋으셨다면 구독&좋아요

여러분의 “구독”과 “좋아요”는
저자에게 큰 힘이 됩니다.

subscribe

Isaac Sacolick
Isaac Sacolick 인공지능/애널리틱스 전문가

StarCIO의 CIO이며, Huffington Post와 Forbes로부터 탑 소셜 CIO로 선정된 바 있다.