Talk - 새로운 기능과 기술 부채의 딜레마
들어가며
사내 타운홀 미팅 중, 발표자이신 임원분께서 다음과 같은 질문을 주셨습니다.
“앞으로 우리 제품의 방향성 대해 궁금한 것이 있나요?”
잠깐 곱 씹은 끝에 엔지니어로서 가장 궁금한 것을 여쭈었습니다.
“비즈니스의 확장과 기술 부채에 대한 우선 순위가 궁금합니다.”
네, 제품의 비전에 대한 질문을 드릴 수도 있었지만…
낭만 없게도 실무자로서 제품 개발의 방향성에 대한 질문을 드렸습니다.
이에 대한 답변은 “현재 우리는 비즈니스의 확장이 더 높은 우선 순위를 가진다” 였습니다.
애니메이션과 성능 개선 등의 고도화나 문서화 등을 좋아하는 저로썬 약간의 아쉬움이 있었지만 당연한 결과라고 생각하였습니다.
왜 비즈니스 확장이 더 우선될까요?
비즈니스 확장을 위해 새로운 기능을 개발하는 가장 큰 이유는 적절한 시기에 걸맞는 적절한 서비스를 제공하기 위함입니다.
시기를 놓쳐 나와 같은 서비스를 제공하는 경쟁사에게 고객을 빼앗긴다면 어떨까요?
식당에 비유해 보면 음식이 제 때 나오지 않아 손님이 다른 식당으로 떠나는 것과 같습니다.
다음에 또 올게요.
제품을 시장에 빠르게 출시하면 경쟁 우위를 점할 수 있고, 이는 곧 매출 증가와 시장 점유율 확대라는 결과로 이어집니다. 즉, 비즈니스의 성장은 빠른 기능 출시와 밀접하게 연관되어 있습니다.
그렇다고 기술 부채를 고려하지 않는다면 어떻게 될까요?
기술 부채란?
일반적으로 부채는 이자를 내고 돈을 쓰는 시점을 앞당기는 것이며, 기술 부채도 이와 크게 다르지 않습니다.
기술 부채는 소프트웨어 개발 과정에서 흔히 발생하는 문제로, 일시적인 해결책을 통해 빠르게 기능을 구현하지만 장기적으로 시스템 유지보수와 확장성에 문제를 일으킬 수 있는 상태를 말합니다.
새로운 기능을 빠르게 출시하면 단기적인 성과를 얻을 수 있지만, 기술 부채가 누적되면 장기적으로는 시스템의 안정성과 효율성이 저하될 수 있습니다.
반면, 기술 부채를 해결하는 데 집중하면 당장의 성과는 느릴 수 있지만, 장기적으로 더 견고하고 효율적인 시스템을 구축할 수 있습니다.
하지만 비즈니스에서 필요한 타이밍에 맞춰 서비스를 제공하는 것은 최우선적으로 중요합니다. 어떤 상황에서 기술 부채가 쌓이는지를 파악하고 이를 어떻게 관리할 수 있는지에 대해 알아보겠습니다.
기술 부채, 왜 발생할까요?
필연적 기술 부채
필연적 기술 부채는 새로운 기능을 빠르게 출시하기 위해 성능보다는 솔루션에 집중하는 경우 발생합니다. 제한된 기간과 자원 내에서 프로젝트를 완료해야 할 때 주로 나타납니다.
- 제공 프로세스 속도를 높이기 위해 코드 검토, 테스트 또는 문서화를 생략하는 경우
- 프로젝트 마감일을 맞추기 위해 임시방편의 코드를 작성하는 경우
우발적 기술 부채
우발적 기술 부채는 개발자가 기술, 지식 또는 경험 부족으로 인해 소프트웨어에 무의식적으로 결함을 도입하는 경우 발생합니다.
- 잘못된 디자인 패턴이나 원칙을 적용하는 경우
- 코드 리뷰로 팀 내에서 검토되지 않은 코드들이 반영되는 경우
기술 부채 관리 전략
기술 부채를 효과적으로 관리하기 위해서는 체계적인 접근이 필요합니다. 다음은 몇 가지 주요 전략입니다.
출처: https://melv1n.com/what-is-technical-debt/
1. 코드 리뷰 및 테스트 강화
코드 리뷰와 테스트는 기술 부채를 예방하는 데 중요한 역할을 합니다. 코드 리뷰를 통해 잘못된 코드가 반영되는 것을 방지하고, 자동화된 테스트를 통해 새로운 기능이 기존 시스템에 미치는 영향(ex. 사이드 이펙트 등)을 최소화할 수 있습니다.
코드 리뷰:
- 팀 내에서 서로의 코드를 검토하여 오류를 사전에 방지합니다.
- 일반적으로 Git을 활용한 브랜치 전략이 보편적입니다.
자동화 테스트:
- 코드의 변경이 기존 기능에 미치는 영향을 최소화하기 위해 자동화된 테스트를 실시합니다.
TDD까지 적용하면 더할 나위 없겠지만 일정을 고려하여Git Actions를 통해lint,type-check정도는 적용하는 것이 좋아 보입니다.
2. 지속적인 리팩토링
리팩토링은 기존 코드를 보다 효율적으로 재구성하는 과정입니다. 정기적인 리팩토링을 통해 누적된 기술 부채를 해소하고, 코드의 가독성과 유지보수성을 향상시킬 수 있습니다.
특히, 프론트엔드는 시간이 조금만 지나도 레거시한 코드가 많기 때문에 더욱 중요한 부분이라 생각합니다.
정기적 코드 정리:
- 일정 주기로 코드를 점검하고, 불필요한 부분을 제거하거나 개선합니다.
- 사내에서는 블랙헤드 청소의 날을 정하여 낮은 우선 순위로 미루어진 이슈들을 해결하는 정기적인 일정이 있습니다.
최적화:
- 성능 향상과 유지보수를 위해 코드를 최적화합니다.
- 개발자가 스스로 학습해야 하는 가장 큰 분야라고 생각합니다.
3. 기술 부채 모니터링
기술 부채를 모니터링하고 관리하기 위한 도구와 프로세스를 도입하는 것이 중요합니다. 정기적인 코드 분석과 품질 검토를 통해 기술 부채의 상태를 파악하고, 필요할 때 즉각적인 조치를 취할 수 있습니다.
사실 가장 어려운 부분이라고 생각합니다. 피드포워드가 가장 좋지만 특정 테스트 중 발견되거나 VoC에 대한 피드백으로 대응하는 경우가 많습니다.
코드 분석 도구:
- 소프트웨어의 품질을 분석하고 문제점을 찾아내는 도구를 활용합니다.
정기적 품질 검토:
- 주기적으로 코드 품질을 검토하여 문제를 조기에 발견하고 해결합니다.
4. 우선순위 설정
기술 부채를 해결하는 데 필요한 작업들을 우선순위에 따라 정리하고, 단계적으로 접근하는 것이 효과적입니다. 비즈니스 요구사항과 기술적 요구사항을 균형 있게 고려하여 계획을 수립해야 합니다.
우선순위 목록 작성:
- 해결해야 할 기술 부채를 우선순위에 따라 목록화합니다.
단계적 접근:
- 가장 중요한 문제부터 순차적으로 해결해 나갑니다.
마치며
새로운 기능을 빠르게 개발하여 시장에 출시하는 것과 기존 시스템의 품질을 개선하고 기술 부채를 관리하는 것 사이에는 항상 딜레마가 존재합니다.
비즈니스의 확장이 더 중요하더라도 “비즈니스에 있어 기술 부채 해결의 우선 순위는 낮을지라도 소홀하지 않아야 한다.”가 이번 글의 아젠다입니다.
또한, 기술 부채를 집중적으로 다루더라도 새로운 기능 개발이 멈추지 않는 이상 끊임 없이 나타나게 됩니다.
기술 부채는 다 갚을 수 없어요.
따라서 장기적으로 성공적인 시스템을 유지하기 위해서는 적절한 선에서 효과적으로 관리하는 것이 필수적입니다.
코드 리뷰, 테스트 강화, 지속적인 리팩토링, 기술 부채 모니터링, 우선순위 설정 등 정말 많은 전략이 있었는데요, 이를 통해 이 딜레마를 극복할 수 있습니다.
시스템에 대해 관심을 가지고 해결에 대한 호기심이 있다면 기술 부채를 효율적으로 관리할 수 있을 것입니다 :)