대부분의 버그는 방지하는 데 드는 비용보다 고치는 데 더 큰 비용이 든다. 아래 그래프에 개발 사이클에 따른 버그 고침의 비용을 지표로 잘 나타냈다. - Requirements/Architecture - Coding - Integration/Component Testing - System/Acceptance Testing - Production/Post-release 1️⃣ 코딩하는 단계에서 버그를 찾아내는 것이 훨씬 더 적은 비용이 들고 고치기도 쉽다. 이때는 개발자가 코드베이스를 잘 파악하고 있는 단계이기 때문에 복잡한 문제를 고치는 것도 손쉽게 처리할 수 있다. 시간이 지날수록 손에 익었던 코드베이스에서 멀어져서 나중에 문제가 생기면 다시 기억해내야 하는 어려움이 생긴다. 2️⃣ 일단 소프트웨어가 테스트 단계에 들어가면, 개발자의 로컬 환경에서 버그를 재현하는 것은 많은 시간을 소모한다. 또한 통합된 시스템에서 근본적인 버그를 찾아내기는 매우 어렵다. 3️⃣ 소프트웨어가 론칭된 후 버그 찾기는 어려울 뿐만 아니라 매우 위험하다. 결함으로 인해 실시간 사용자가 영향을 받게 되고, 서비스의 가용성을 보장하는 것은 비즈니스에 매우 중요하다. 4️⃣ 따라서 개발자가 조기에 버그를 찾고 많은 버그를 자주 찾아낼 수 있는 프로세스를 구현하는 것은 아주 중요하다. 기본적으로 개발 워크플로우는 가능한 한 개발 단계 초기에 버그를 찾을 수 있도록 해야 한다. 📌 덧붙여서 시스템 설계 단계(Requirements/Architecture)에서 많은 시간을 투자해서 결함을 찾아내고 방지하는 것이 가장 좋습니다. 이미 구현된 시스템 내에서 버그를 찾고 고치는 건 설계 단계에서 고치는 것보다 큰 비용이 발생하며, 최악의 상황에는 코드 전체를 리펙토링까지 해야 할 수도 있어요. 시스템 설계 단계에서 가능한 시니어 엔지니어와 꼼꼼하게 설계를 검토하고, 규모가 큰 서비스를 구축한다면, 내가 잘 소통하지 않았던 팀이 소유하고 있는 시스템에 영향을 미칠 가능성이 있습니다. 따라서 자기 조직과 팀 내에 있는 시니어 엔지니어와 검토하는 것 외에도 조직 외에 영향을 미칠 수 있는 팀에 속한 엔지니어와 소통하고 검토하는 것이 좋습니다. 코딩 테스트와 시스템 설계 면접할 때도 자주 하는 실수인데, 사람들은 보통 설계 단계를 건너뛰고 무작정 문제 풀이부터 시작합니다. 처음에는 면접관과 문제의 범위에 대해서 조율하고 명확하게 한 다음, 문제 풀이를 하는 것이 훨씬 더 좋습니다. 이미 코드를 몇 줄 쓰고, 문제를 반 이상 풀고난 후 문제를 잘못 접근했다는 것을 알아차리면 그때는 이미 늦었을 가능성이 큽니다. 출처: https://deepsource.io/blog/exponential-cost-of-fixing-bugs/ 🪴 함께 읽으면 좋은 글: 좋은 개발자가 되기 위해 알아야 할 Threat Modeling https://careerly.co.kr/comments/73799 새로운 코드베이스 빨리 학습하는 법 https://careerly.co.kr/comments/73148 소프트웨어 공학 스킬과 개념 빨리 익히는 법 https://careerly.co.kr/comments/75803