소프트웨어를 만드는 일은 마치 대중 앞에서 공연을 하는 것처럼 느껴질 수 있습니다. 인터넷은 출시, 스크린샷, 그리고 변경 사항(changelog)의 불렛 포인트에 열광합니다. 그래서 개발자가 프로젝트에 온종일 매달렸음에도 눈에 보이는 성과가 없을 때, 그날을 허비했다고 생각하기 쉽습니다. Food Blog Platform의 최신 개발 로그는 그 반대를 증명합니다. 새로 보여줄 레시피도, 재설계된 카드도, 사용자가 클릭할 추가 버튼도 없었습니다. 그저 코드를 해체하고, 검토하고, 이전보다 더 나은 상태로 다시 조립했을 뿐입니다.
이것이 장기 프로젝트를 지속시키는 보이지 않는 작업입니다.
기능은 영광을 얻지만, 리팩터링은 시스템을 유지합니다
음식 블로그 플랫폼을 유지 관리할 때, 겉모습은 단순해 보입니다. 사용자는 레시피를 게시하고, 사진을 업로드하며, 카테고리별로 둘러봅니다. 하지만 그 이면에서는 이미지 파이프라인, 재료와 조리법 사이의 데이터베이스 관계, 검색 인덱스, 캐싱 레이어 등을 조율해야 합니다. 시간이 흐르면서 임시방편적인 수정 사항들이 쌓여갑니다. 세 개의 서로 다른 파일에 복사된 헬퍼 함수, 게시물이 10개일 때는 괜찮았지만 1,000개가 되면 느려지는 데이터베이스 쿼리, 처음에는 정리되어 있었으나 다섯 번의 긴급 패치를 거치며 미로가 되어버린 CSS 같은 것들 말이죠.
리팩터링이란 그러한 혼란에 정면으로 맞서는 것을 의미합니다. 레시피 편집 양식과 관리자 대시보드가 별도의 버전을 유지하는 대신 동일한 검증 레이어를 사용하도록 중복 로직을 통합하는 것일 수도 있습니다. 페이지가 새로 고침될 때마다 실행되는 대신 압축 루틴이 한 번만 실행되도록 이미지 처리 방식을 단순화하는 것일 수도 있습니다. 또는 나중에 새로운 콘텐츠 유형을 추가할 때 서로 관련 없는 6개의 디렉토리를 뒤질 필요가 없도록 코드베이스를 재구성하는 작업일 수도 있습니다.
이 중 어느 것도 사용자 인터페이스에는 나타나지 않습니다. 사이트에 방문한 사용자는 "쿼리 최적화됨" 또는 "컴포넌트 분리됨"이라고 적힌 배너를 볼 수 없습니다. 하지만 사이트 로딩 속도가 빨라졌을 때 그 차이를 느낄 것입니다. 새로운 기능이 요청된 지 3주가 아니라 3일 만에 나타날 때 그들은 알아차릴 것입니다. 개발자가 오늘 새로운 기능을 추가한 것은 아닙니다. 코드베이스와 싸우지 않고도 기능을 추가할 수 있도록 길을 닦아 놓은 것입니다.
클린 코드는 미래의 실패를 막기 위한 투자입니다
한 달 이상 지속되는 모든 프로젝트에는 마찰이 쌓입니다. 아이디어를 테스트하기 위해 빠른 프로토타입을 만듭니다. 그러다 실제 사용자가 나타납니다. 그다음에는 인증 레이어가 필요하고, 중재 큐가 필요하며, 모바일 레이아웃도 필요해집니다. 이러한 추가 사항들은 기존에 존재하는 구조 위에 하나씩 덧붙여집니다. 정기적인 유지보수가 없다면, 아키텍처는 평면도를 한 번도 본 적 없는 서로 다른 사람들이 방을 하나씩 설계해 나간 집처럼 변하기 시작합니다.
기술 부채는 규율의 실패가 아닙니다. 실제 결과물을 내놓기 위해 타협하는 과정에서 발생하는 자연스러운 부산물입니다. 위험한 것은 코드가 불완전하다는 사실 그 자체가 아닙니다. 변수 하나를 바꿨는데 관련 없는 기능 세 개가 망가질 정도로 오랫동안 불완전한 상태로 방치하는 것이 위험한 것입니다. 지난번에 검색창을 건드렸다가 태그 시스템이 망가진 적이 있어, 검색창을 만지는 것조차 두려워하게 됩니다. 데이터베이스 스키마가 풀기 위해 몇 시간이 걸릴 만큼 엉망으로 꼬여 있다는 것을 알기에 식단 계획 위젯 추가를 미루게 됩니다.
하루를 리팩터링에 쓰는 것은 이자가 감당할 수 없을 만큼 불어나기 전에 그 부채를 갚는 것과 같습니다. 이는 작은 문제들이 커다란 문제로 굳어지는 것을 방지합니다. Food Blog Platform이 마침내 다음 주요 기능을 추가할 때, 개발자는 깨지기 쉬운 코드 주변을 조심스럽게 피해 다닐 필요가 없을 것입니다. 새로운 로직을 작성하고, 이를 깔끔한 인터페이스에 연결한 뒤 다음 작업으로 넘어갈 수 있습니다. 그것이 바로 투자 대비 수익(ROI)입니다.
작은 발걸음, 진정한 배움
소프트웨어 개발에는 진보란 천재적인 돌파구나 하룻밤 사이에 모든 것을 다시 쓰는 마라톤 코딩 세션처럼 보여야 한다는 신화가 있습니다. 현업 개발자 대부분은 그것이 환상이라고 말할 것입니다. 진정한 진보는 화요일 오후의 diff(차이점)와 같습니다. 세 개의 함수가 짧아지고, 불필요한 의존성 하나가 제거되며, 다음 읽는 사람이 코드가 무엇을 하는지 실제로 이해할 수 있도록 혼란스러운 변수 이름을 변경하는 것 말이죠.
Food Blog Platform의 개발 로그는 이러한 리듬을 완벽하게 담아냅니다. 소프트웨어를 만드는 것은 작고 꾸준한 개선의 과정입니다. 모든 도전으로부터 배웁니다. 오늘은 특정 모듈이 왜 다른 모듈에 그토록 의존하게 되었는지 이해하는 것이 도전이었을 수도 있습니다. 혹은 2주 전에 택한 지름길이 이미 절약한 시간보다 더 많은 시간을 잡아먹기 시작했다는 사실을 깨닫는 것이 도전이었을 수도 있습니다. 모든 커밋은 프로젝트를 더 낫게 만듭니다. 설령 그 커밋이 생성하는 것보다 삭제하는 것이 더 많을지라도 말입니다.
이 접근 방식은 동기 부여를 유지하는 데에도 도움이 됩니다. 대규모 재작성은 매우 소모적이며 위험합니다. 기존의 버그를 해결하는 과정에서 새로운 버그를 유발하기도 합니다. 점진적인 리팩터링을 수행하면,