개발 프로젝트는 어떻게 진행되는가

아이디어는 바로 서비스가 되지 않는다

개발 프로젝트는 "이런 서비스를 만들고 싶다"는 생각을 실제로 작동하는 결과물로 바꾸는 과정이다. 겉으로 보면 개발자가 코드를 쓰는 시간이 가장 중요해 보이지만, 실제 프로젝트는 그보다 넓다. 무엇을 만들지 정하고, 어떤 화면이 필요한지 설계하고, 데이터를 어떻게 저장할지 정하고, 만든 기능이 제대로 작동하는지 확인한 뒤, 사용자에게 공개하고 계속 고치는 일까지 포함한다.

예를 들어 "동네 빵집 예약 서비스를 만들자"는 아이디어가 있다고 하자. 이 말만으로는 개발을 시작하기 어렵다. 사용자는 회원가입을 해야 하는지, 비회원도 예약할 수 있는지, 예약 가능한 시간은 누가 등록하는지, 결제는 필요한지, 취소는 언제까지 가능한지 정해야 한다. 사장님이 보는 관리 화면도 필요할 수 있다. 사용자가 보는 화면과 가게가 보는 화면은 다르고, 저장해야 할 데이터도 다르다.

그래서 개발 프로젝트는 아이디어를 잘게 나누어 확인하는 일에서 시작한다. 이 과정을 알면 개발자와 협업하거나 외주를 맡길 때 불필요한 오해를 줄일 수 있다. "그냥 버튼 하나 추가하면 되는 것 아닌가요?"라는 말이 왜 가끔은 큰 작업이 되는지도 이해할 수 있다.

AI 생성 이미지

기본 흐름: 요구사항에서 운영까지

개발 프로젝트의 흐름은 보통 요구사항 정리, 화면 설계, 개발, 테스트, 배포, 운영으로 이어진다. 프로젝트마다 이름과 방식은 다를 수 있지만, 큰 흐름은 비슷하다. 다만 실제 현장에서는 이 단계들이 한 번씩만 지나가는 직선처럼 진행되지는 않는다. 테스트하다가 화면 설계로 돌아가기도 하고, 운영 중에 발견한 문제 때문에 요구사항을 다시 정리하기도 한다.

요구사항 정리는 무엇을 만들지 정하는 단계다. 요구사항은 서비스가 반드시 해야 할 일과 지켜야 할 조건을 뜻한다. "회원은 상품을 장바구니에 담을 수 있다", "관리자는 주문 상태를 배송 중으로 바꿀 수 있다", "비밀번호는 8자 이상이어야 한다" 같은 문장이 요구사항이 된다. 이 단계에서는 기능 목록뿐 아니라 사용자 유형, 권한, 예외 상황도 함께 정리해야 한다.

화면 설계는 사용자가 어떤 순서로 화면을 보고 행동할지 정하는 단계다. 버튼 위치나 색상만 정하는 일이 아니다. 사용자가 처음 들어오면 어떤 정보를 보는지, 입력을 잘못했을 때 어떤 메시지를 보여 줄지, 결제 실패 후에는 어디로 이동할지 같은 흐름을 정한다. 화면 설계가 부족하면 개발 중간에 "이 경우에는 어떤 화면이 나오나요?"라는 질문이 계속 생긴다.

개발은 설계한 내용을 실제로 작동하게 만드는 단계다. 앞에서 본 것처럼 화면은 프론트엔드가, 서버와 데이터 처리는 백엔드가 주로 맡는다. 여기에서 데이터베이스 구조를 만들고, API를 연결하고, 로그인과 권한 확인 같은 규칙을 코드로 구현한다.

테스트는 만든 기능이 기대한 대로 작동하는지 확인하는 단계다. 정상적인 사용만 확인해서는 부족하다. 빈칸으로 제출하면 어떻게 되는지, 이미 예약된 시간에 또 예약하면 어떻게 되는지, 결제 도중 인터넷이 끊기면 어떻게 되는지도 확인해야 한다. 테스트는 실수를 찾기 위한 과정이지, 누군가를 탓하기 위한 과정이 아니다.

배포는 만든 서비스를 실제 사용자가 쓸 수 있는 환경에 올리는 일이다. 웹서비스라면 서버에 반영하고, 앱이라면 앱스토어 심사나 업데이트 배포 과정이 필요할 수 있다. 배포 후에는 끝이 아니다. 실제 사용자가 들어오면 예상하지 못한 오류가 생기고, 속도 문제가 드러나고, 새로운 요구가 생긴다. 그래서 운영이 이어진다. 운영은 서비스를 계속 안정적으로 유지하고 개선하는 일이다.

프로젝트 안의 역할들

개발 프로젝트에는 여러 역할이 함께 참여한다. 작은 프로젝트에서는 한 사람이 여러 역할을 맡기도 하지만, 역할의 성격은 구분해서 이해하는 편이 좋다.

기획자는 서비스의 목적과 기능을 정리한다. 사용자가 누구인지, 어떤 문제를 해결할 것인지, 어떤 기능이 먼저 필요한지 판단한다. 요구사항 문서, 화면 흐름, 정책 정리 등을 맡는 경우가 많다. 여기서 정책은 서비스가 따르는 규칙이다. 예를 들어 "예약 취소는 방문 3시간 전까지 가능하다" 같은 내용이다.

디자이너는 사용자가 보기 쉽고 사용하기 편한 화면을 만든다. 단순히 예쁘게 꾸미는 역할로만 보면 부족하다. 중요한 버튼이 눈에 잘 띄는지, 글자가 읽기 좋은지, 모바일 화면에서도 불편하지 않은지, 사용자가 다음 행동을 쉽게 알 수 있는지 고민한다.

프론트엔드 개발자는 사용자가 직접 보는 화면을 구현한다. 버튼을 눌렀을 때 화면이 바뀌고, 입력값을 확인하고, 서버에서 받은 데이터를 목록이나 그래프로 보여 주는 일을 맡는다. 웹에서는 브라우저에서 작동하는 부분, 앱에서는 사용자의 기기에서 보이는 부분과 가깝다.

백엔드 개발자는 서버와 데이터 처리를 맡는다. 로그인 확인, 데이터베이스 저장, 주문 계산, 권한 검사, 외부 API 연동처럼 화면 뒤에서 일어나는 처리를 담당한다. 사용자는 백엔드 코드를 직접 보지 못하지만, 서비스의 안정성과 정확성에 큰 영향을 준다.

QA는 Quality Assurance의 줄임말로, 품질을 확인하는 역할이다. 만든 기능이 요구사항과 맞는지, 사용 중 오류가 없는지, 여러 기기와 상황에서 문제가 없는지 점검한다. QA가 따로 없는 작은 팀에서는 기획자, 개발자, 운영자가 함께 테스트를 나누어 하기도 한다.

이 밖에도 프로젝트 매니저, 데이터 담당자, 보안 담당자, 인프라 담당자 등이 참여할 수 있다. 중요한 것은 누가 더 중요하냐가 아니라, 각 역할이 서로 다른 문제를 보고 있다는 점이다. 기획자는 목적과 정책을 보고, 디자이너는 사용 경험을 보고, 개발자는 작동 구조와 안정성을 보고, QA는 놓친 문제를 본다.

'간단한 기능'이 간단하지 않을 때

개발 프로젝트에서 자주 생기는 오해가 있다. 겉으로 보기에 작아 보이는 기능은 실제 작업량도 작을 것이라고 생각하는 것이다.

예를 들어 "회원 등급별 쿠폰 기능을 추가해 주세요"라는 요청을 생각해 보자. 화면에는 쿠폰 하나가 보일 뿐일 수 있다. 하지만 개발 관점에서는 여러 질문이 생긴다.

회원 등급은 어디에 저장되어 있는가? 등급은 언제 바뀌는가? 쿠폰은 한 번만 쓸 수 있는가? 다른 할인과 중복되는가? 주문을 취소하면 쿠폰은 다시 살아나는가? 관리자는 쿠폰을 직접 발급할 수 있는가? 잘못 발급된 쿠폰은 회수할 수 있는가? 사용자는 쿠폰이 왜 적용되지 않았는지 알 수 있는가?

이 질문들은 화면, 데이터, 권한, 예외 처리와 연결된다. 화면에는 쿠폰 목록과 적용 결과를 보여 줘야 한다. 데이터에는 쿠폰의 종류, 유효기간, 사용 여부, 대상 회원 정보를 저장해야 한다. 권한에서는 일반 회원과 관리자가 할 수 있는 일이 달라야 한다. 예외 처리에서는 만료된 쿠폰, 이미 사용한 쿠폰, 결제 실패, 주문 취소 같은 상황을 다뤄야 한다.

그래서 개발자에게 "간단하죠?"라고 묻기보다 "어떤 부분까지 포함해서 봐야 하나요?"라고 묻는 편이 좋다. 같은 기능이라도 보여 주기만 하는 수준인지, 실제 결제와 정산에 영향을 주는 수준인지에 따라 난이도와 책임이 달라진다.

일정이 지연되는 대표 원인

개발 일정은 처음 계획대로만 흘러가지 않는 경우가 많다. 이는 개발자가 느리기 때문만은 아니다. 프로젝트에는 처음에 보이지 않던 변수가 많다.

첫째, 요구사항 변경이다. 개발 중간에 기능의 방향이 바뀌면 이미 만든 화면, 데이터 구조, 서버 로직을 다시 고쳐야 할 수 있다. "회원가입에 휴대폰 인증도 넣자"는 요청은 화면 한 칸을 추가하는 것처럼 보이지만, 인증번호 발송, 인증 시간 제한, 재시도 제한, 외부 문자 발송 서비스 연동까지 이어질 수 있다.

둘째, 숨은 오류다. 코드는 한 부분을 고치면 다른 부분에 영향을 줄 수 있다. 특히 오래 운영된 서비스일수록 기능들이 서로 연결되어 있다. 검색 조건을 바꾸었더니 관리자 통계가 달라지거나, 주문 상태를 수정했더니 알림 발송이 중복될 수 있다. 이런 문제는 개발 전에는 완전히 알기 어렵고, 테스트 과정에서 드러나는 경우가 많다.

셋째, 외부 연동 문제다. 결제, 지도, 소셜 로그인, 배송 조회, 문자 발송처럼 외부 API를 사용하는 기능은 상대 서비스의 규칙과 상태에 영향을 받는다. 문서와 실제 동작이 다르거나, 심사 절차가 필요하거나, 호출 제한 때문에 테스트가 막히는 일이 생길 수 있다. 우리 팀이 코드를 잘 작성해도 외부 서비스의 승인이나 장애 때문에 일정이 밀릴 수 있다.

넷째, 결정 지연이다. 개발은 수많은 선택을 필요로 한다. 어떤 문구를 보여 줄지, 어떤 정책을 적용할지, 예외 상황에서 환불을 어떻게 처리할지 결정되지 않으면 개발도 멈춘다. 작은 결정처럼 보여도 서비스 규칙과 데이터 구조에 영향을 줄 수 있다.

좋은 협업은 질문을 줄이는 것이 아니라 질문을 드러내는 것이다

좋은 개발 프로젝트는 처음부터 모든 것을 완벽히 아는 상태에서 출발하지 않는다. 중요한 것은 모르는 부분을 빨리 드러내고, 결정해야 할 내용을 기록하며, 변경이 생겼을 때 영향을 함께 확인하는 것이다.

외주나 협업을 맡길 때는 "쇼핑몰을 만들어 주세요"보다 "회원가입, 상품 목록, 장바구니, 결제, 주문 내역, 관리자 상품 등록까지 필요합니다"처럼 범위를 나누어 말하는 편이 좋다. 여기에 "첫 버전에서는 쿠폰과 리뷰는 제외합니다"처럼 하지 않을 일도 정해 두면 더 좋다. 개발 범위는 할 일을 정하는 것만큼 하지 않을 일을 정하는 것도 중요하다.

일정도 하나의 날짜만 보는 것보다 단계별로 보는 편이 현실적이다. 요구사항 정리 기간, 화면 설계 확인일, 1차 개발 완료일, 테스트 기간, 배포 예정일을 나누면 중간에 문제가 생겼을 때 조정하기 쉽다. 테스트 기간을 일정에서 빼면 결국 배포 직전에 오류를 발견하고 더 큰 혼란을 겪는다.

개발 프로젝트는 코드를 쓰는 사람만의 일이 아니다. 아이디어를 가진 사람, 사용자를 이해하는 사람, 화면을 설계하는 사람, 서버와 데이터를 다루는 사람, 품질을 확인하는 사람이 함께 만드는 과정이다. 이 흐름을 이해하면 개발자에게 더 정확히 요청할 수 있고, 개발자의 질문도 방어적으로 들리지 않는다. 그 질문들은 일을 복잡하게 만들기 위한 것이 아니라, 실제로 작동하는 서비스를 만들기 위해 필요한 확인이다.