2017년, 핀테크 스타트업 초기 멤버로 합류했을 때의 일입니다. “나중에 고치자”며 if-else 문을 15번 중첩시킨 ‘괴물’을 만들어냈죠. 서비스는 대박이 났지만, 기능 하나를 추가할 때마다 버그가 3개씩 터지는 지옥이 시작되었습니다.
그때 깨달았습니다. 코드는 건축물이 아니라 ‘정원’과 같다는 사실을요. 한 번 짓고 끝나는 게 아니라, 끊임없이 잡초를 뽑고 가지를 쳐줘야 생명을 유지합니다. 오늘 이 글은 그 ‘가지치기(Refactoring)’의 고통을 즐거움으로 바꾸는 가이드입니다.
1. 고통: “왜 건드려서 일을 키우나”
리팩토링이 고통스러운 이유는 ‘보이지 않는 가치’를 위해 ‘보이는 위험’을 감수해야 하기 때문입니다.
경영진이나 기획자 입장에서 리팩토링은 달갑지 않습니다. “기능 추가된 거 있어요?”라고 물으면 “아니요, 내부는 깨끗해졌습니다”라고 답해야 하니까요. 게다가 잘 돌아가던 코드를 건드려 버그라도 생기면 그 책임은 온전히 개발자의 몫입니다. 이 압박감, 마치 시한폭탄 해체 작업과 비슷하죠.
“솔직히 고백하자면, 저도 주니어 시절엔 ‘돌아가면 건드리지 마(If it works, don’t touch it)’라는 명언을 신봉했습니다. 하지만 그건 게으름에 대한 변명이더군요. 썩은 부위를 도려내지 않으면 결국 프로젝트 전체가 괴사합니다. 두렵더라도 칼을 대야 합니다.”
2. 즐거움: 더 적은 코드, 더 많은 자유
그럼에도 우리가 밤새워 코드를 고치는 이유는 명확합니다. ‘통제감’ 때문입니다.
- ✅ 삭제의 미학: 100줄짜리 중복 코드를 함수 하나로 묶어 10줄로 줄였을 때의 그 짜릿함. 개발자만이 아는 최고의 도파민입니다.
- ✅ 가독성의 발견: 내가 짠 코드를 동료가 읽고 “와, 이거 구조 진짜 깔끔한데요?”라고 말해줄 때, 우리는 예술가가 된 듯한 기분을 느낍니다.
💡 코드캠의 실전 TIP: 보이스카우트 규칙
거창하게 날 잡고 리팩토링하지 마세요. 그럴 시간은 영원히 오지 않습니다.
“머물렀던 자리를 왔을 때보다 더 깨끗하게 치우고 떠난다.”
버그를 수정하러 들어간 파일에서 딱 변수명 하나, 함수 하나만 정리하고 나오세요. 이 작은 습관이 1년 뒤 거대한 기술 부채를 막아줍니다.
3. 절대 하지 말아야 할 실수: ‘완벽주의’
“이 구조는 디자인 패턴에 안 맞으니까 싹 다 갈아엎자.” 위험한 생각입니다.
우리는 학자가 아니라 엔지니어입니다. 비즈니스 가치를 창출하지 않는 리팩토링은 ‘자기만족’일 뿐입니다. 완벽한 코드는 존재하지 않습니다. 현재의 요구사항을 충족하고, 다음 사람이 이해할 수 있는 수준(Good Enough)이라면 거기서 멈추는 용기가 필요합니다.
4. 코드는 당신의 얼굴입니다
리팩토링은 미래의 나, 그리고 함께 일하는 동료에 대한 ‘배려’입니다.
오늘 작성한 그 코드가 6개월 뒤 누군가의 야근을 유발할 수도, 혹은 칼퇴를 선물할 수도 있습니다. 완벽하지 않아도 좋습니다. 어제보다 조금 더 깔끔한 코드를 작성했다면, 당신은 이미 훌륭한 아키텍트입니다.
지금 쳐다보기도 싫은 ‘레거시 코드’가 있으신가요? 어떤 부분이 가장 골치 아픈지 댓글로 털어놓아 보세요. 욕하면서 스트레스라도 풀어봅시다!
