기술 부채 관리를 위한 DX와 AI

모든 회사, 크고 작은 회사, 기술 부채에 대해 걱정합니다. Gartner estimates에 따르면 약 40%의 인프라 시스템이 이 문제를 가지고 있습니다. CIO들을 대상으로 한 McKinsey의 조사에 따르면, 거의 3분의 1이 새로운 제품 예산의 20% 이상이 기술 부채 관련 문제를 해결하는 데 사용된다고 느꼈습니다. 그러나 많은 사람들이 생각하는 것과 달리, 이것은 단순히 코딩 문제가 아닙니다. 개발자 경험(DX) 문제이기도 합니다. 개발자가 불充分한 아키텍처, 구식 도구, 개발 워크플로우와 함께 작업해야 할 때, 생산성, 성능, 그리고 사기는 저하됩니다.

기술 부채를 개발자 중심으로 관리하고, 그들이 어떻게 작업하는지, 어떤 도구를 사용하는지, 그리고 어떤 경력 개발을 할 수 있는지에 초점을 맞추면, 팀이 집중하고 더 빠르게 출하할 수 있습니다. 이것이 회사들이 기술 부채를 관리하는 방식이 DX와 AI 기반 도구에 대한 관심 증가로 변화하고 있는 이유입니다.

DX를 위한 챔피언

개발자가 온보딩되는 방식은 종종 바람직하지 않습니다. 누군가 프로젝트에 기여하기 시작하는 데 몇 주가 걸릴 수 있습니다. 그들이终于 작은 기능이나 패치에 기여할 수 있게 되면, CI 서비스가 그들이 작업한 변경과 관련이 없는 이유로 실패하는 것을 볼 수 있습니다. 이것은 기본적으로 테스트 스위트가 품질 문제로 인해 실패하는 것입니다. 개발자는 테스트 스위트를 깨뜨리기 위해 변경을 제출하지 않았습니다. 이것은 90%의 시간에만 작동하는 불안정하고 잘못 작성된 테스트입니다. 기존 팀은 이것에 익숙해질 수 있지만, 외부인에게는 도구가 구식이고 демор얼화될 수 있습니다.

DX를 방해하는 많은 예 중 하나입니다. 이를 방지하는 한 가지 방법은 소프트웨어 엔지니어링 및 개발 팀에 지정된 챔피언을 두는 것입니다. 많은 작은 회사에는 DX 리더가 없지만, 큰 회사에는 있습니다. 이러한 전문가들은 새로운 개발자가 환경을 설정하는 데 걸리는 시간과 같은 것을 추적합니다. 그리고 2주가 너무 길면, 그 시간을 반으로 줄이는 방법을 찾습니다.

도움이 되는 도구도 있습니다. 예를 들어, CircleCI는 테스트 스위트의 불안정성을 추적하는 네이티브 기능을 가지고 있습니다. 필요한 것은 DX를 더 좋게 만들고 싶은 리더가 있습니다. 이를 위해, DX를 더 좋게 만들고 싶은 선임 엔지니어와 새로운 직원이 함께 일할 수 있습니다.

IDC는 AI 기반 소프트웨어 테스트 자동화 시장은 2027년까지 연평균 31.2%의 성장률을 유지할 것으로 예상합니다. 따라서 이 기술을 최대한 활용해야 합니다.

경고 신호와 메트릭

기술 부채가 팀에 미치는 영향을 평가할 때 추적할 수 있는 많은 메트릭이 있습니다. 기본적인 메트릭 중 일부는 “수정 시간” 또는 “기능 시간”입니다. 버그를 발견하고 수정하는 방법을 알고 있습니다. 일부 도구는 코드 작성에서 생산까지 시간을 추적할 수 있습니다. 예를 들어, 아주 작은 패치가 2个 영업일이 걸렸고, 팀은 몇 시간 안에 이를 해결해야 한다는 것을 알 수 있습니다. 또한 버그 수정 수와 완성된 기능의 비율과 같은 비율을 추적할 수 있습니다.

또한 팀의 성능에 영향을 미치는 사기 문제를 식별하는 방법도 있습니다. DX 리더는 개발자가 프로젝트나 프로젝트의 일부에서 작업하는 데 얼마나 행복한지 알아보기 위해 사분기에 한 번 설문조사를 실시할 수 있습니다. 그들은 CI 프로세스와 같은 특정 영역에 대해 질문할 수 있습니다. 또한 팀의離職률이나 이직률을 추적할 수 있습니다. 사람들이 계속해서 떠나는 경우, 그들은 자신의 우려가 듣지 않는다고 느낄 수 있습니다.

AI와 함께하는 도구

AI 도구의 등장으로 개발자와 엔지니어가 더 생산적이고 제품이 더 빠르게 출시될 것으로 예상되지만, 기술 부채는 이를 느리게 만듭니다. GitHub 또는 Copilot와 같은 도구를 사용하여 코드 변경을 도와주고, 풀 리퀘스트를 제출하면, CI가 몇 시간이 걸릴 수 있습니다. 그 동안 개발자는 다른 것을 작업합니까? 이메일을 확인합니까? 이것은 컨텍스트 전환과 생산성 킬러입니다.

개발자는 코드에만 집중할 수 있는 제품에서 작업하고 싶습니다. 도구는 코드를 생산으로 이동하는 데 도움이 되도록 설계되어야 합니다. AI는 시간을 절약할 수 있지만, 엔지니어링 팀이 허용되는 복잡성 수준을 정의해야 합니다. 이를 위해, 메인 브랜치에 추가된 모든 코드가 허용되는 기술 부채 수준을 가지고 있는지 확인합니다. 그 전에, 엔지니어링 팀과 기술 부채 및 코드 품질의 허용되는 임계값에 대한 공개적인 토론을 통해 동의를 얻습니다. 모든 사람이 허용되는 임계값을 넘어서면 즉시 수정이 필요하다는 것을 이해하도록 합니다. 이러한 표준을 정의한 후에, AI가 발挥됩니다.

엔지니어와 함께 작동하는 AI 에이전트의 경우가 있습니다. Capgemini의 1,100명의 경영진을 대상으로 한 조사에 따르면, 82%의 公司이 향후 3년 내에 AI 에이전트를 통합할 계획입니다. 이미 업무의 미래에 영향을 미치고 있습니다. 버그 리포트를 보고, AI 에이전트가 처리할 수 있는 작은 문제를 볼 수 있습니다. 코드 리뷰까지 모든 것을 처리하여 팀의 시간을 절약하고, 더 복잡한 작업을 처리할 수 있도록 해줍니다. 그러나 때때로 이러한 도구를 맹목적으로 따를 때, AI가 고려하지 못하는 트레이드오프가 있습니다.

그것은 인간의 의견이 결정적인 요소가 됩니다.

기술 부채와 목표의 일치

기술 부채 감소를 어떻게 목표와 측정 가능한 결과에 맞출 수 있나요? 허용되는 기술 부채와 때때로 사업에서 빠르게 출하해야 하는 경우로 돌아갑니다. 제품이 확장되지 않고, 시간이 지나면 성능 문제가 있을 수 있습니다. 종종 개발자는 나중에 이 문제를 해결하도록 노트를 남깁니다. 그러나 이러한 나쁨 문화가 지배할 때, 기술 부채의 영향이 명백해집니다.

이것은 스타트업에게는 이해할 수 있지만, 10년 동안 운영된 회사에게는 아닙니다. 기술 부채를 관리하기 위해 문화를 조기에 변경하고, 적극적으로 관리해야 합니다. 그렇지 않으면, 생산 버그를 수정하거나 보안 및 규정 준수를 걱정하는 데 많은 돈을 쓰게 될 것입니다.

마지막으로, 기술 부채를 상환하거나 리팩토링하는 가치를 이해관계자에게 전달하는 데 도움이 되는 메트릭이 있습니다. 시간은 코드 작성에서 생산까지, 또는 풀 리퀘스트를 열어 생산으로 이동하는 데 걸리는 시간일 수 있습니다. 또 다른 것은 평균 수리 시간(MTTR)입니다. 이 경우, 버그나 깨진 빌드를 발견하고, 팀이 이를 수정하는 데 걸리는 시간을 측정할 수 있습니다. 또한 생산에서 버그의 수를 추적할 수 있습니다. 이 숫자가 증가하면, 기술 부채와 관련된 문제가 있을 수 있습니다.

기술 부채와 이자

모든 회사은 기술 부채를 줄이기 위해 DX를 개선하는 데 몇 시간을 할애할 수 있습니다. 그렇지 않으면, 나중에 느린 성능, 개발 속도의 상당한 감소, 또는 보안 문제로 인해 비용을 지불할 수 있습니다. 예를 들어, Ruby on Rails 업그레이드를 10년 동안 연기한 엔지니어와 개발자 팀이 있을 수 있습니다. 갑자기, 프로젝트 비용이 반으로 증가합니다. 이유는 루비 버전이 4세대 이전으로, 코드와 구식 종속성이 많기 때문입니다.

逐渐 업그레이드했다면, 이러한 상황에 처하지 않았을 것입니다. 따라서 소프트웨어 개발 팀을 지원하고, 지불해야 합니다. 그렇지 않으면, 기술 부채가 이자와 함께 돌아올 것입니다.