제13화. 개발 일정에 쫓겨 품질을 포기하는 순간, 재앙은 시작된단다
아들아, 프로젝트 후반부에 접어들면 모두가 예민해진단다. 오픈 날짜는 다가오는데 할 일은 산더미 같지. 이때 누군가 유혹의 말을 건넬 거야. "일단 기능만 돌아가게 하고 오픈한 다음에 고치죠." 하지만 명심해라. 품질과 타협하는 순간, 네 프로젝트는 성공이 아니라 '끝나지 않는 재앙'의 시작이 될 뿐이란다.
일정을 맞추기 위해 대충 짠 코드는 당장은 시간을 벌어주는 것 같지만, 결국 '기술 부채(Technical Debt)'라는 이름으로 돌아온단다. 사채 이자가 무섭게 불어 나듯, 초반에 방치한 작은 버그와 엉성한 로직은 나중에 수정하려면 몇 배의 시간과 비용을 요구하지.
오늘 아낀 한 시간의 대가는 내일의 열 시간으로 돌아온다는 사실을 명심하렴.
아빠의 노하우: 아빠는 일정이 부족할 때 '기능의 범위'를 줄였지, 결코 '품질의 기준'을 낮추지는 않았단다. 10가지 기능을 부실하게 만드는 것보다, 핵심 기능 5가지를 완벽하게 만드는 것이 고객의 신뢰를 지키는 길이란다.
오픈 후에 고치겠다는 약속은 지켜지기 어렵단다. 시스템이 오픈되는 순간, 운영 업무와 새로운 요구사항이 쏟아지기 때문이지. 결국 대충 만든 부분은 시스템이 수명을 다할 때까지 '시한폭탄'처럼 남아 모두를 괴롭히게 돼.
개발 단계에서 해결하지 못한 숙제는 운영 단계에서 반드시 사고로 터지게 되어 있단다.
아빠의 노하우: 아빠는 "오픈 후 보완"이라는 말을 믿지 않았어. 개발 단계에서 해결하지 못한 문제는 운영 단계에서 반드시 사고로 터진단다. 지금 1시간이면 고칠 문제를, 나중에는 시스템 전체를 세우고 밤을 새우며 고쳐야 할 수도 있다는 사실을 잊지 마라.
시간이 없다는 이유로 단위 테스트나 통합 테스트를 생략하자고 할 때가 있을 거야. 하지만 테스트는 단순히 오류를 찾는 과정이 아니라, 네가 설계한 로직이 안전하다는 것을 증명하는 '보증서'란다.
테스트에서 발견되지 않은 버그는 반드시 고객의 눈앞에서 가장 치명적인 순간에 나타난단다.
아빠의 노하우: 아빠는 아무리 바빠도 핵심 프로세스에 대한 '결함 제로' 원칙은 고수했단다. 그렇게 테스트를 진행해도 완벽한 프로그램은 없단다. 고객은 사용자 매뉴얼대로 사용하지 않아, 그런 부분에서 정말 생각지도 못한 버그가 나오는데… 최소한 매뉴얼 기반의 테스트는 반드시 진행하여 ‘결함 제로’를 목표로 해야. 나중의 문제를 최소화할 수 있단다.
빠르게 만드는 것도 실력이지만, 제대로 만드는 것이 진짜 실력이란다. 일정을 맞추기 위해 품질을 포기하는 PM은 고객에게 끌려다니는 '관리자'일뿐이지만, 품질을 위해 일정을 조율하는 PM은 프로젝트를 리드하는 '전문가'로 인정받게 된단다.
속도에 눈이 멀어 기초를 허물지 마라. 튼튼한 집만이 거친 폭풍우를 견뎌낼 수 있단다.
아빠의 노하우: 고객이 일정을 압박할 때 아빠는 "품질을 포기하고 날짜를 맞출 것인지, 기능을 조정하고 안정성을 택할 것인지"를 숫자로 보여주며 설득했어. 기술적 팩트를 근거로 품질의 마지노선을 지키는 태도가 결국 너와 네 팀을 지켜줄 거란다.
한 마디
"품질은 타협의 대상이 아니라, 네 이름 석 자를 걸고 지켜야 할 마지막 자존심이란다. 속도에 눈이 멀어 기초를 허물지 마라. 튼튼하게 지은 집만이 거친 폭풍우를 견뎌낼 수 있는 법이니까."
프로젝트가 위험한 속도로 달리고 있다면 다음 5가지를 점검해 보렴.
[코드 리뷰 생략] 개발자들이 서로의 코드를 확인하지 않고 일단 'Push' 하기에 급급한가?
[결함 재발생] 고쳤다고 보고된 버그가 다음 날 다시 나타나는 '회귀 결함'이 빈번한가?
[테스트 데이터 부실] 실제 데이터가 아닌 단순한 'asdf' 식의 테스트 데이터로만 확인하고 있는가?
[예외 처리 미비] 정상적인 흐름(Happy Path) 외에 잘못된 입력이나 상황에 대한 방어 로직이 빠져 있는가?
[문서화 부재] 바쁘다는 핑계로 변경된 로직이 기획서나 설계서에 반영되지 않고 개발자 머릿속에만 있는가?