‘서둘러 짠 코드가 빚으로 돌아올 때’··· 기술 부채 해결 팁 6가지

세상에 완벽한 것은 없으며, 소프트웨어 코드도 마찬가지다.

사실 대부분의 프로그래머에게는 완벽에 가까운 코드를 만들 시간이 주어지지 않는다. 빠르게 배포해야 한다는 압박감 때문에 나중에 수정해야 한다는 것을 알면서도 문제가 있는 코드를 내놓는 경우가 많다. 이는 기술 부채의 원인이 된다.

디지털 서비스 기업 웨스트먼로의 임원인 네이트 부니바는 “코드 측면에서 많은 기술 부채를 보고 있다. 프로그래머들은 속도와 혁신을 우선시하면서 충분한 품질 검사를 거치지 않은 코드를 구현하고 있다. 이로 인해 향후 문제가 발생하게 된다. 이런 일이 점점 더 많아지고 있다”라고 말했다.

‘기술 부채’라는 용어는 이제 모든 구식 IT 기술에 적용돼 ‘레거시 기술’과 동의어로 여겨지기도 하지만, 원래는 ‘코드 부채’를 의미하는 말이었다. 여전히 많은 기술 분야에서 그 의미로 이해하고 있다.

CIO가 비즈니스 전략에 지장을 주고, 보안에 위험을 초래하며, 예산에 비용을 추가하는 IT 스택의 기존 구성 요소를 제거해야 하는 것처럼, 기술 부채 역시 계속해서 관리해야 한다. 그렇지 않을 경우 엄청난 비용을 초래할 수 있다. 2022년 한 연구에 따르면 열악한 소프트웨어 품질로 인한 비용이 미국에서만 2.41조 달러에 달했다.

이런 현실을 고려할 때, CIO는 기술 부채를 관리하기 위한 방법을 도입해야 한다. 경험 많은 기술 리더들이 기술 부채를 줄이기 위해 사용하는 6가지 전략을 소개했다.

1. 기술 부채 측정에 분석적으로 접근

인포테크 리서치 그룹의 인프라 및 운영 연구 책임자인 앤드류 샤프는 기술 부채를 목록화해야 한다고 조언했다. 그는 IT 리더들이 중요한 기술 부채 목록을 작성하고, 그 부채가 비즈니스에 미치는 영향을 파악하며, 이를 해결하기 위한 과정을 갖춰야 한다고 언급했다. 많은 CIO가 이 3가지 기본 문제에서 종종 부족함을 보인다고 그는 덧붙였다.

샤프는 “핵심 과제는 기술 부채의 범위를 이해하고 정리하는 것이다. 기술 부채가 여러 시스템에 걸쳐 있기 때문에 IT 팀이 기술 부채의 규모와 영향을 파악하는 데 어려움을 겪는다. 이는 연쇄적인 영향을 미칠 수 있다”라고 말했다.

하지만 다른 비즈니스와 마찬가지로, 부채는 측정되지 않으면 제대로 관리할 수 없다. 샤프는 IT 부서가 부채를 식별, 추적 및 측정하는 데 더 능숙해져야 한다고 조언했다.

그는 “IT 부서는 항상 문제가 어디에 있는지, 어떤 식으로 문제를 일으키는지 감을 잡고는 있지만, 공식적인 분석이 없는 경우가 많다. 이를 체계적으로 살펴보면 이전에 생각하지 못했던 것을 발견할 기회가 될 수 있다. 단순히 문제가 있다는 사실을 아는 게 아니라 무엇이 문제인지 알고 그 영향을 이해하는 것이 중요하다. 가시성을 확보해야 한다”라고 설명했다.

하지만 샤프는 모든 기술 부채를 추적하기보다는 해결하려는 부채에 집중해야 한다고 말했다.

2. AI 생성 코드를 방치하지 않기

이제 IT 부서와 기업 전반의 직원들이 코드를 작성하는 데 생성형 AI를 사용하고 있다. 일부 연구에 따르면 생성형 AI가 코드 품질을 약간은 향상시킬 수 있는 것으로 나타났다. 그러나 소트웍스(Thoughtworks)의 최고 AI 책임자인 마이크 메이슨은 대부분의 조직에서 “향후 1~2년 동안 매우 평범한 소프트웨어가 넘쳐날 것”이라고 예상했다.

그는 “AI로 코드를 빠르게 작성할 수 있지만, 사람들은 코드를 수정하기보다 새 코드를 만드는 데 더 잘 적응하는 것 같다”라며, 이렇게 만들어진 평범한 코드 중 너무 많은 부분이 전문 개발자의 검토나 자동화된 품질 보증 검사 없이 생산 단계로 옮겨지고 있다고 지적했다.

메이슨은 이어 “조직들이 더 많은 기능을 빨리 구현하겠지만, 코드가 비대해지고 기술 부채와 레거시 코드가 늘어나 문제에 직면할 수 있다”라고 진단했다.

그렇다고 직원들이 코딩에 AI를 사용하지 말아야 한다는 뜻은 아니라고 메이슨은 말했다. 그는 오히려 품질이 낮은 코드가 너무 많이 통과되지 않도록 프로세스와 도구(AI 지원 도구 포함)를 갖추고 있는지 확인해야 한다고 덧붙였다.

3. 기술 부채에 거버넌스 적용

부니바는 대부분의 조직이 소프트웨어 개발 프로그램에 대한 거버넌스를 어느 정도 갖추고 있다면서도, 그중 상당수는 팀이 속도와 품질의 균형을 맞출 방법을 알려줄 만큼 충분히 강력하지도, 상세하지도 않다고 지적했다. 이런 상황은 AI 지원 코드 생산 속도가 빨라지면서 더 분명해지고 있다.

부니바는 “거버넌스가 생성형 AI의 속도를 따라가지 못하고 있다. 생성형 AI에 맞는 거버넌스, 즉 혁신을 늦추지 않으면서도 많은 기술 부채를 만들지 않는 거버넌스가 필요하다”라고 말했다.

그는 좋은 거버넌스라면 테스트와 품질 보증에 대한 요구 사항을 설정하고, 자동화된 품질 검사 대신 사람이 참여해야 하는 시기를 명시해야 한다고 언급했다. 또한 코드를 개발하는 모든 사람이 표준에 대해 교육받을 수 있도록 교육 요구 사항도 다뤄야 한다고 말했다.

4. 갚을 부채의 우선순위 지정

레거시 기술과 마찬가지로 코드 부채는 현실이다. 따라서 완전히 갚기는 불가능할 수 있다. 엔트러스트의 CIO인 리시 카우샬은 이를 완전히 갚으려고 노력하기보다는 가장 문제가 되는 부분, 즉 회사에 많은 비용을 초래할 수 있는 부분을 우선적으로 해결하고 있다.

카우샬은 “오랜 시간과 많은 비용을 들여 수정해도 별 가치가 없는 기술 부채에 집중하고 싶지 않다”라고 말했다. 대신 그는 보안 리스크를 초래하거나 사용자 경험에 불편함을 주는 기술 부채를 해결하는 데 집중하고 있다. 이는 레거시 기술 전반에도 적용되는 방법이다.

그는 “일부 기술 부채는 갖고 있어도 괜찮다. 다른 요소를 개선하는 동안 감당할 수 있는 기술 부채가 무엇인지 결정해야 한다”라고 조언했다.

전문 서비스 기업 KPMG의 글로벌 기술, 미디어 및 통신 책임자인 마크 깁슨도 비슷한 전략을 제시했다. 그는 코드 부채를 포함한 모든 레거시 기술을 다룰 때 “매우 목표가 분명한 선제적 투자와 빠른 방향 전환이 필요하다”라고 조언했다.

깁슨은 대부분의 CIO가 문제점이 어디에 있는지 알고 있다고 말했다. 그가 언급한 KPMG의 2024년 글로벌 기술 보고서에 따르면, 조직 리더의 57%가 기본 IT 시스템의 결함으로 인해 매주 일상적인 업무에 지장을 받는다고 응답했다.

깁슨은 문제가 있는 시스템을 우선 수정하는 것이 좋은 출발점이라며, CIO가 로그와 IT 직원 설문 조사를 활용해 우선 수정 목록에 포함돼야 할 문제를 찾아낼 수 있다고 말했다. 또한 그는 기술 부채 해결을 위한 경영진의 지원을 얻을 때 기술 부채가 비즈니스 리스크임을 보여줘야 한다고 말했다.

5. 목표를 처음부터 구체화하기

슈나이더 일렉트릭의 북미 지역 수석 부사장 겸 CIO인 바비 케인은 2025년 말까지 레거시 기술을 12% 감축한다는 명확한 목표를 정의했다고 말했다. 그는 구체적인 목표가 시스템을 현대화하고 그 과정에서 문제 있는 코드를 해결해야 한다는 확실한 동기를 준다고 설명했다.

케인은 이 목표를 달성하기 위해 현재 상태를 목록화하고 측정하는 데서 시작했다. 이를 통해 레거시 기술과 기술 부채가 어디에 있는지 파악하고, 이후 우선순위를 정하고 행동 계획을 세우는 다각적인 전략을 마련했다.

이런 작업은 잘 운영되는 IT 부서의 기본 사항이지만, 케인은 명확한 목표가 팀에 지속적인 동기를 부여할 수 있다면서 “강제력 없이는 변화를 이끌 수 없다”라고 말했다.

6. 부채 관리가 지속적인 과정임을 인식

미국 농촌 전기 협동조합 협회(NRECA)의 CIO 겸 IT 수석 부사장인 웨인 F. 맥거크는 기술 부채를 좋거나 나쁜 것으로 보지 않고 “새로운 것이 만들어지기 때문에 발생하는 개발 과정의 자연스러운 결과”로 봤다.

그는 “최소 실행 가능 제품(MVP)을 최대한 빨리 출시하려는 경향이 있다. 처음부터 완벽한 애플리케이션을 만들지는 않는다”라면서, 이를 위해 팀이 절충점을 찾고 있다고 말했다. 다시 말해 MVP에는 작동하지만 솔루션이 확장되면 부족할 것을 알면서도 특정 기술을 선택한다는 것이다.

맥거크는 이런 상황을 개발 주기뿐만 아니라 IT 운영에도 반영하고 있다. 그는 다양한 방법을 활용해 지속적으로 기술 부채를 관리할 수 있는 종합적인 접근법을 개발하고 있다. 그 일환으로, 맥거크의 팀은 새로운 기술 부채가 생길 때마다 문서화하고 상세히 기록한다. 이는 조직의 티켓팅 시스템을 통해 추적되고 있다. 그는 “이렇게 하면 IT 팀이 모든 정보를 불러와서 보고하고 검토할 수 있다”라고 설명했다.

맥거크는 또한 각 기술 부채가 단순성, 유연성, 연속성, 보안 및 투명성이라는 5가지 주요 영역에서 운영에 미치는 영향을 고려한다고 밝혔다. 그는 “기술 부채가 이런 운영 원칙 중 어느 하나라도 방해하기 시작하면, 그때는 해결해야 할 수준에 도달한 것으로 보고 있다”라고 말했다.

맥거크와 팀은 영향 수준, 조직에 대한 리스크, 그리고 조직의 전반적인 전략을 고려해 무엇에 주의를 기울여야 하는지 우선순위를 정한다. 그런 다음 결정을 공유해 조직 전체에 해당 주제에 대한 인식을 높이고 있다.

맥거크는 이 모든 과정이 IT 부서의 업무 흐름에 통합돼 있다고 언급했다. 그래야 기술 부채 관리가 일회성 프로젝트가 아니라 지속적인 방식으로 관리될 수 있다는 설명이다. 예를 들어, 스크럼 팀은 새로운 기술 부채를 식별하고 언제 어떻게 해결할지 결정해야 한다.

그는 “책임과 의무의 문화를 만들어야 한다. 그래야 팀원들이 프로젝트가 전달됐다고 해서 끝난 게 아니라는 걸 알게 된다. 기술 부채는 끝이 없는 여정이다. 따라서 새로운 작업에 대한 수요뿐만 아니라 기존 작업과 기술 부채를 처리하는 것도 수요 관리 전략의 일부가 된다”라고 설명했다.
[email protected]