개발팀은 어떻게 일하는가 — 애자일, 스프린트, MVP

개발팀과 일하다 보면 익숙하지 않은 단어들이 회의에 자주 등장합니다. “이번 스프린트에 넣을게요”, “일단 MVP로 가시죠”, “백로그에 쌓아 두겠습니다” 같은 말입니다. 모두 개발팀이 일하는 방식, 흔히 애자일이라 부르는 흐름에서 나온 표현입니다.

지난 글에서 간단해 보이는 기능도 생각보다 오래 걸린다고 했습니다. 바로 그 불확실함에 대응하려고 다듬어진 일하는 방식이 애자일입니다. 이번 글에서는 애자일, 스프린트, MVP가 무엇인지 코드 없이 풀어 보겠습니다.

애자일은 짧게 끊어 만들고 고치는 방식입니다 #

소프트웨어를 만드는 옛 방식은 처음에 모든 것을 빠짐없이 계획한 뒤, 그 계획대로 끝까지 만들어 마지막에 한 번 내놓는 흐름이었습니다. 문제는 다 만들고 나서야 “이게 우리가 원하던 게 아니었네"를 깨닫는 일이 잦았다는 것입니다. 몇 달을 들인 뒤 방향을 트는 비용은 너무 큽니다.

애자일은 정반대로 접근합니다. 한 번에 완성하려 하지 않고, 작게 만들어 빨리 보여 주고, 피드백을 받아 고치기를 반복합니다. 완벽한 계획보다 빠른 확인과 방향 수정을 더 중요하게 여기는 것입니다. 지도를 다 그린 뒤 출발하는 대신, 한 걸음 걷고 방향을 확인하며 나아가는 방식에 가깝습니다. 무엇이 나올지 미리 다 알 수 없는 소프트웨어 작업에 잘 맞아서 널리 자리 잡았습니다.

스프린트는 짧게 반복되는 작업 주기입니다 #

애자일을 실제로 운영하는 단위가 스프린트입니다. 보통 1~2주 정도의 짧은 기간을 한 주기로 정해 두고, 그 안에서 정해진 분량을 만들어 마무리합니다. 그리고 다음 주기에 또 다음 분량을 만듭니다.

스프린트가 시작될 때 팀은 이번 주기에 무엇을 할지 함께 정하고, 끝날 때는 만든 것을 점검하고 다음을 계획합니다. 이렇게 짧게 끊으면 진행 상황이 자주 드러나서, 일정이 어긋나도 빨리 알아채고 방향을 고칠 수 있습니다. “이번 스프린트에 넣을게요"라는 말은 이번 작업 주기 안에 그 일을 하겠다는 뜻이고, “다음 스프린트로 넘기죠"는 이번 주기에는 넣지 않겠다는 뜻입니다.

여기서 자주 함께 나오는 말이 백로그입니다. 백로그는 앞으로 해야 할 일을 우선순위에 따라 쌓아 둔 목록입니다. 매 스프린트마다 이 목록의 위쪽에서 할 일을 꺼내 옵니다. “백로그에 쌓아 두겠습니다"는 지금 당장은 아니지만 목록에 넣어 두고 나중에 다루겠다는 뜻입니다.

MVP는 핵심만 담은 첫 버전입니다 #

애자일의 정신을 한 단어로 보여 주는 것이 MVP입니다. 우리말로 최소 기능 제품이라고 옮깁니다. 처음부터 모든 기능을 갖춘 완성품을 만드는 대신, 핵심 가치를 확인할 수 있는 최소한의 형태로 먼저 내놓는 것입니다.

예를 들어 음식 배달 서비스를 만든다면, 화려한 추천 기능이나 포인트 적립은 미뤄 두고 “주문하고 결제하면 음식이 온다"는 핵심만 먼저 만들어 사용자에게 내놓습니다. 이렇게 하면 사람들이 정말 이 서비스를 쓰는지, 어디서 막히는지를 빠르게 확인할 수 있습니다. 큰돈과 시간을 다 쏟기 전에, 작은 형태로 시장의 반응을 먼저 듣는 것입니다.

MVP를 “대충 만든 것"으로 오해하기 쉽지만, 그렇지 않습니다. 기능의 가짓수는 줄이되 그 핵심은 제대로 동작해야 합니다. 빼는 것은 곁가지이지 품질이 아닙니다.

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

• 회의 언어를 따라갈 수 있습니다. 스프린트, 백로그, MVP가 오가는 대화에서 지금 무엇을 정하고 있는지 또렷하게 들립니다.
• 요청을 우선순위로 전할 수 있습니다. 모든 기능을 한 번에 요구하기보다, 핵심부터 MVP로 내놓고 나머지는 백로그에 쌓는 식으로 함께 계획할 수 있습니다.
• “이번엔 못 넣어요"를 이해합니다. 다음 스프린트로 넘긴다는 말이 거절이 아니라 우선순위 조정이라는 점을 알면, 일정 협의가 한결 수월해집니다.

마무리 #

오늘은 개발팀이 일하는 방식을 애자일, 스프린트, MVP라는 세 단어로 살펴봤습니다. 애자일은 짧게 끊어 만들고 고치는 흐름이고, 스프린트는 그 흐름을 운영하는 짧은 작업 주기이며, MVP는 핵심만 담아 먼저 내놓는 첫 버전입니다. 셋 다 “한 번에 완벽하게"가 아니라 “빠르게 확인하고 고친다"는 같은 생각에서 나왔습니다.

왜 기능 하나에도 시간이 드는지가 더 궁금하다면 왜 간단해 보이는 기능이 오래 걸릴까를, 이 일을 실제로 누가 하는지 궁금하다면 개발자는 실제로 어떤 일을 하는가를 함께 읽어 보시길 권합니다.