기술 부채와의 전쟁: 완벽하지 않아도 출시하는 용기

제가 기술 부채를 처음 실감한 때는 2021년 3월, 중고 거래 앱의 주문 관리 화면을 맡았을 때였습니다. 당시 팀은 6주 안에 베타 버전을 공개하겠다고 약속했고, 저는 시작부터 구조를 깔끔하게 만들겠다는 욕심을 부렸습니다. 공통 컴포넌트부터 다시 설계하고 예외 처리 규칙도 통일하려다 보니 첫 2주 동안 화면 하나를 완성하지 못했습니다. 회의 때마다 “조금만 더 다듬고 보여주자”고 말했지만, 그 말이 출시를 미루는 핑계로 바뀌고 있다는 사실을 뒤늦게 알아차렸습니다.

1. 코드의 흠보다 늦어진 출시가 더 아팠다

그 프로젝트에서 제가 만든 첫 버전은 테스트 커버리지 82%를 기록했고, 함수 이름도 팀 규칙에 맞췄습니다. 그런데 예정일인 2021년 4월 16일에 실제로 배포된 기능은 당초 계획의 절반뿐이었습니다. 경쟁 서비스가 비슷한 주문 알림 기능을 먼저 공개하면서 우리 팀은 사용자 인터뷰 기회를 잃었습니다. 나중에 회고해 보니 장애가 발생한 것도 아니고 보안 문제가 있었던 것도 아니었습니다. 제가 내부 구조를 다듬는 동안 사용자가 기다릴 이유를 하나도 만들지 못했던 셈입니다.
더 아쉬웠던 장면은 출시 뒤에 찾아왔습니다. 어렵게 완성한 필터 기능의 사용률은 일주일 동안 전체 주문의 3%에도 못 미쳤지만, 제가 간단한 오류 메시지 개선을 미뤄 둔 탓에 문의 전화는 하루 평균 18건씩 들어왔습니다. 사용자는 세련된 추상화보다 주문 상태를 제대로 이해하길 원했습니다. 그때 저는 기술 부채를 코드에 남은 흠집으로만 생각했는데, 실제로는 의사결정을 늦추고 사용자의 불편을 키우는 시간의 부채이기도 하다는 점을 배웠습니다.

2. 출시 범위를 줄이는 과정에서 배운 것

이후 2022년 7월, 동료 한 명과 사내 식당 예약 도구를 만들게 됐습니다. 처음 기획서에는 메뉴 추천, 알레르기 기록, 자동 결제, 대기 순번 알림까지 11개 기능이 적혀 있었습니다. 저는 이전 실패를 떠올리며 일주일 동안 직원 14명을 인터뷰했고, 그중 11명이 “예약이 됐는지 한눈에 보고 싶다”고 답한 사실을 확인했습니다. 그래서 첫 배포에는 로그인, 좌석 예약, 예약 취소 세 가지만 넣기로 했습니다. 화려하지 않았지만 3주 만에 실제 직원에게 건넬 화면이 생겼습니다.
첫 버전에는 일부러 남겨 둔 불편도 있었습니다. 예약 변경은 기존 예약을 취소한 뒤 다시 신청해야 했고, 알림도 이메일 한 종류뿐이었습니다. 대신 제가 매일 오전 11시와 오후 1시에 사용 기록을 확인하고, 사내 메신저로 불편 사항을 받았습니다. 출시 10일 뒤 37명이 남긴 의견 중 23건이 예약 변경과 관련돼 있다는 사실을 보고 우선순위를 바꿨습니다. 처음부터 모든 기능을 넣었다면 이런 반응을 놓쳤을 가능성이 큽니다. 덜 만든 덕분에 무엇부터 고쳐야 할지 눈앞에 드러났습니다.

3. 실패한 기능은 개발자의 자존심을 건드렸다

제가 가장 오래 붙잡았던 기능은 2023년 2월에 추가한 자동 추천 모듈이었습니다. 두 명이 4주 동안 사용자의 과거 주문을 분류하고 추천 문구를 만드는 작업을 진행했습니다. 시연 날에는 꽤 그럴듯해 보였지만, 공개 후 한 달 동안 추천 버튼을 누른 사람은 412명 중 29명뿐이었습니다. 그중 7명은 추천 결과가 마음에 들지 않아 바로 화면을 닫았습니다. 저는 회의에서 이 기능을 계속 개선하자고 주장했지만, 실제 사용 흐름을 다시 확인한 뒤에는 그 주장을 거둬야 했습니다.
저는 그 모듈을 폐기하는 데 사흘이 걸렸습니다. 이미 작성한 코드와 회의 자료, 야근 기록이 아까워서 쉽게 삭제 버튼을 누르지 못했습니다. 결국 추천 영역을 숨기고, 같은 개발 시간을 검색 속도 개선에 배정했습니다. 그 뒤 평균 응답 시간이 1.8초에서 0.7초로 줄었고 고객 문의도 주당 31건에서 12건으로 감소했습니다. 이 경험은 기술 부채를 줄인다는 말이 무조건 큰 리팩터링을 뜻하지 않는다는 점을 알려줬습니다. 쓰이지 않는 기능을 내려놓는 것도 빚의 이자를 끊는 행동이었습니다.

4. 기술 부채를 목록이 아니라 약속으로 관리하기

예전에는 버그나 임시 코드를 발견할 때마다 이슈 tracker에 “나중에 수정”이라고 적었습니다. 2023년 9월에 확인해 보니 그런 항목이 96개나 쌓여 있었고, 누구도 어떤 문제가 실제 장애로 이어지는지 알지 못했습니다. 저는 팀원들과 세 시간 동안 목록을 다시 읽으며 사용자 영향, 수정 예상 시간, 재발 가능성을 기준으로 네 묶음으로 나눴습니다. 결제 실패와 연결된 4건은 즉시 처리했고, 관리 화면의 색상 통일처럼 영향이 작은 27건은 당분간 보류했습니다.
그 뒤부터는 매주 금요일 배포 회의에서 기술 부채 항목 하나를 반드시 골랐습니다. 다만 “이번 주에 리팩터링하자”처럼 두루뭉술하게 말하지 않고, 담당자와 종료 조건을 함께 적었습니다. 예를 들어 “주문 조회 함수 개선” 대신 “시간대 조건을 분리하고 기존 테스트 18개가 통과하면 완료”라고 기록했습니다. 이 방식으로 6주 동안 15개 항목을 없앴고, 신규 기능을 추가할 때 같은 코드를 세 번씩 수정하던 일이 눈에 띄게 줄었습니다. 작은 약속을 지키는 과정이 팀의 신뢰를 다시 쌓는 데 도움이 됐습니다.

5. 제가 지금 출시 전에 확인하는 기준

현재 저는 출시 전날 코드가 아름다운지부터 보지 않습니다. 먼저 사용자가 해결하려던 한 가지 문제가 실제 화면에서 풀리는지 확인하고, 실패했을 때 되돌릴 방법이 있는지 점검합니다. 2024년 5월 파일 업로드 기능을 공개했을 때도 전체 사용자의 10%에게만 먼저 열고, 오류 로그와 문의 내용을 48시간 동안 관찰했습니다. 첫날 파일 크기 제한 안내가 부족해 오류가 23건 발생했지만, 안내 문구를 고친 뒤 같은 문제가 4건으로 줄었습니다. 작게 공개하고 빠르게 고치는 편이 긴 준비 기간보다 덜 위험하다는 판단이 제 경험에서 나왔습니다.
제가 얻은 실용적인 기준은 단순합니다. 출시를 미룰 만한 문제가 보안, 결제, 개인정보, 복구 불가능한 손실과 관련됐다면 일정을 다시 잡아야 합니다. 반대로 문구가 어색하거나 구조가 아직 투박하거나 나중에 교체할 모듈이 남은 정도라면, 담당자와 기한을 기록한 뒤 작은 범위로 공개합니다. 출시 후에는 일주일 안에 사용자 반응을 확인하고, 매주 한 건씩 부채를 갚습니다. 독자 여러분도 다음 배포 전에 모든 것을 고치려 하기보다, 미뤄도 되는 문제와 미루면 안 되는 문제를 먼저 나눠 보시기 바랍니다. 그 구분과 짧은 실행 주기가 완벽함보다 오래가는 제품을 만드는 출발점이 됩니다.