왜 간단해 보이는 기능이 오래 걸릴까 — 개발 일정과 기술 부채

기획자와 개발자 사이에서 가장 자주 부딪히는 순간이 있습니다. “이거 버튼 하나 추가하는 건데, 왜 2주나 걸려요"라는 질문입니다. 묻는 쪽은 화면에 버튼 하나가 늘어나는 작은 변화로 보고, 답하는 쪽은 그 뒤에 줄줄이 엮인 일을 떠올립니다. 둘 다 틀린 말을 하는 게 아니라, 같은 일을 서로 다른 각도에서 보고 있을 뿐입니다.

이 글에서는 왜 간단해 보이는 기능이 생각보다 오래 걸리는지, 그리고 개발 일정을 이야기할 때 빠지지 않는 기술 부채가 무엇인지 코드 없이 풀어 보겠습니다. 이 그림을 알면 일정을 두고 벌어지는 답답한 대화가 한결 수월해집니다.

화면의 작은 변화 뒤에는 여러 층이 함께 움직입니다 #

예를 들어 “주문 내역 화면에 취소 버튼을 하나 추가해 주세요"라는 요청을 생각해 보겠습니다. 화면만 보면 버튼 하나입니다. 하지만 그 버튼이 실제로 동작하려면 보이지 않는 여러 층이 함께 움직여야 합니다.

먼저 버튼을 누른 사용자가 정말 그 주문을 취소할 권한이 있는지 확인해야 합니다. 이미 배송이 시작된 주문이라면 취소를 막아야 하고, 결제를 되돌리는 처리도 필요합니다. 취소된 주문은 데이터베이스에 그 사실이 남아야 하고, 재고도 다시 늘려야 합니다. 사용자에게는 취소가 완료됐다는 안내가 보여야 하고, 중간에 오류가 나면 어떻게 알릴지도 정해야 합니다.

웹사이트가 프론트엔드, 백엔드, 데이터베이스라는 여러 층으로 이루어진다는 이야기를 비개발자를 위한 IT 상식 #1에서 다뤘습니다. 버튼 하나를 더하는 일은 이 층들을 모두 건드리는 경우가 많습니다. 눈에 보이는 것은 맨 위의 버튼 하나지만, 그 아래에서 손봐야 할 곳이 줄줄이 딸려 옵니다.

보이지 않는 일이 보이는 일보다 훨씬 많습니다 #

기능을 만드는 일은 코드를 새로 쓰는 시간만으로 끝나지 않습니다. 오히려 코드를 쓰는 시간은 전체의 일부입니다.

새 기능을 붙이기 전에 기존 코드의 어디를 건드려야 하는지, 그 변경이 다른 기능을 망가뜨리지는 않는지 살펴야 합니다. 만들고 나서는 제대로 동작하는지 시험하고, 동료가 코드를 검토하는 코드 리뷰를 거치고, 실제 서비스에 반영하는 배포까지 가야 비로소 사용자 손에 닿습니다. 여기에 휴대폰과 데스크톱처럼 화면 크기가 다른 환경, 느린 인터넷, 예상치 못한 사용자 행동까지 고려하면 확인할 거리가 더 늘어납니다.

빙산이 딱 맞는 비유입니다. 물 위로 드러난 부분이 화면에 보이는 버튼이라면, 물 아래 잠긴 더 큰 덩어리가 그 버튼을 떠받치는 보이지 않는 일입니다. 요청하는 사람은 물 위만 보고, 만드는 사람은 물 아래까지 봅니다. 같은 기능을 두고 체감하는 무게가 다른 이유가 여기에 있습니다.

기술 부채는 빠른 길이 남긴 빚입니다 #

여기에 개발 속도를 좌우하는 또 하나의 사정이 있습니다. 바로 기술 부채입니다.

개발을 하다 보면 시간에 쫓겨 일단 빠르게 돌아가게만 만들어 두고, 깔끔하게 정리하는 일은 나중으로 미루는 경우가 생깁니다. 급할 때는 이 선택이 합리적입니다. 문제는 이렇게 미뤄 둔 정리가 쌓인다는 데 있습니다. 정리되지 않은 코드 위에 새 기능을 또 얹으면, 그 위에 무언가를 더하기가 점점 어려워집니다.

이런 상태를 빚에 빗대어 기술 부채라고 부릅니다. 빚을 내면 당장은 빠르게 움직일 수 있지만, 갚지 않고 두면 이자가 붙습니다. 마찬가지로 미뤄 둔 코드 정리는 시간이 지날수록 새 기능을 만드는 속도를 갉아먹습니다. “예전엔 금방 했던 게 요즘은 왜 이렇게 오래 걸리지"의 뒤에는 이 부채가 쌓여 있는 경우가 많습니다.

그래서 개발팀은 새 기능만 만드는 게 아니라, 종종 시간을 들여 기존 코드를 정리합니다. 겉으로는 아무것도 바뀌지 않는 이 작업을 리팩터링이라고 부릅니다. 눈에 보이는 결과가 없어 설득하기 어렵지만, 부채를 갚아 두어야 앞으로의 속도가 유지됩니다.

그래서 일정 산정은 늘 어렵습니다 #

이쯤 되면 왜 개발 일정이 자주 빗나가는지 짐작이 갑니다. 만들어야 할 일의 상당 부분이 눈에 보이지 않고, 게다가 그 일에는 해봐야 아는 불확실함이 섞여 있기 때문입니다.

소프트웨어는 똑같은 것을 두 번 만들지 않습니다. 한 번도 해보지 않은 일을 추정하는 셈이라, 예상보다 까다로운 문제가 중간에 튀어나오기 쉽습니다. 가져다 쓰는 외부 서비스가 예상과 다르게 동작하거나, 기존 코드의 숨은 제약이 뒤늦게 드러나는 식입니다.

그래서 노련한 개발자일수록 일정을 딱 떨어지는 숫자가 아니라 범위로 이야기합니다. “이틀"이 아니라 “이틀에서 나흘, 중간에 막히면 더"라고 말하는 것은 발을 빼려는 게 아니라, 불확실함을 정직하게 드러내는 것입니다.

왜 비개발자가 알면 일이 편해지는가 #

• 일정 대화가 부드러워집니다. 왜 이렇게 오래 걸리냐고 묻기 전에 화면 뒤에 딸려 오는 일을 함께 헤아리면, 더 정확한 일정 합의에 이를 수 있습니다.
• 요청에 맥락을 담을 수 있습니다. 급한 정도, 꼭 필요한 부분, 나중에 해도 되는 부분을 구분해 전하면 개발팀이 무엇을 먼저 할지 정하기 쉬워집니다.
• 정리하는 시간을 인정할 수 있습니다. 기술 부채를 갚는 리팩터링은 당장 보이는 성과가 없지만, 미루면 결국 모두의 일정이 느려집니다. 이 시간을 일정에 넣는 것이 길게 보면 이득입니다.

마무리 #

간단해 보이는 기능이 오래 걸리는 데는 분명한 이유가 있습니다. 화면에 보이는 작은 변화 뒤에 여러 층이 함께 움직이고, 코드를 쓰는 시간보다 보이지 않는 일이 더 많으며, 그동안 쌓인 기술 부채가 속도를 끌어내립니다. 일정에 섞인 불확실함은 일을 대충 한다는 신호가 아니라, 소프트웨어를 만드는 일의 본래 성질에 가깝습니다.

이 그림을 함께 보고 있으면 일정을 둘러싼 대화는 다툼이 아니라 협업이 됩니다. 개발자가 실제로 하루를 어떻게 보내는지 더 알고 싶다면 개발자는 실제로 어떤 일을 하는가를, 문제가 터졌을 때의 대응이 궁금하다면 버그, 핫픽스, 롤백을 함께 읽어 보시길 권합니다.