개발, 언제까지 할 수 있는지 묻기 전에 해야 할 일
개발자와 소통하며 일하는 비개발자들을 위한 글
이 개발 언제까지 할 수 있나요?
회사에서 새 프로젝트를 추진하거나 기존 서비스를 개선할 아이디어가 떠오르면, 가장 먼저 “이거 개발 가능할까? 얼마나 걸릴까?”라는 질문을 하게 되곤 합니다. 특히 경영진이나 기획, 비즈니스 부서에서 개발자에게 구두로 아이디어를 설명하며 곧바로 개발 일정을 묻는 상황이 발생합니다. 하지만 이렇게 구두로만 전달되는 아이디어는 핵심 기능이나 기대 효과, 우선순위가 충분히 정리되어 있지 않은 상태일 때가 많습니다.
개발자 입장에서는 기능의 범위, 구체적인 요구사항 등을 알아야만 일정을 어느 정도 가늠할 수 있습니다. 이런 정보가 누락된 상태에서 곧장 “언제까지 가능하냐”라고 물으면, 일정 산정이 부정확해지기 쉽고, 실제로 개발을 진행하는 과정에서도 예상치 못한 부분이 계속 드러나 시간을 더 잡아먹거나 기능이 바뀌는 일이 비일비재합니다.
가령 “새로 론칭한 서비스에 푸시 알림 기능을 넣으면 좋겠다”는 제안은 듣기엔 간단해 보이지만, 막상 구현 단계로 들어가면 '사용자가 알람을 받는 시점은 언제인지’, '사용자의 알림 권한 관리는 어떻게 설정할지', '메시지 내용을 어떻게 저장하고 처리할지', ‘푸시 발송 대상은 어떻게 구분할지’, '메시지 전송 실패 시에는 어떻게 처리할지', ‘예외 상황(앱이 설치되지 않은 경우 등)은 어떻게 대응할지’ 등 다양한 부분을 결정해야 합니다. 이렇듯 요구사항을 자세히 정리하지 않은 채로 일정부터 묻는다면, 당연히 예측이 어긋나고 개발 과정에서 기능이 변경되는 경우가 생깁니다.
이 글에서는 이러한 상황을 피하기 위해, 일정을 물어보기 전에 꼭 해두면 좋은 2가지를 소개하려 합니다. 실제 프로젝트 관리와 프로덕트 매니저로 일하면서 느꼈던 점을 바탕으로, 개발자와 협업해야 하는 비개발자분들에게 도움이 되었으면 합니다.
1. 아이디어(요구사항)를 '글'로 정리해 보기
2. 개발 일정 계산을 위한 시간 만들기
1. 아이디어를 '글'로 정리하기
새로운 아이디어가 머릿속에 떠오를 때 가슴이 두근거립니다. “아, 이 기능만 있으면 우리 서비스가 한 단계 성장할 수 있을 텐데!”라는 확신이 들기도 하고, 당장이라도 개발자에게 달려가서 가능한지 물어보고 싶어질 때가 있습니다. 하지만 이럴 때일수록 잠시 멈춰서 아이디어를 글로 구체화해 보는 습관을 들이면 좋은 것 같습니다.
머릿속의 아이디어는 생각보다 논리적 빈틈이 많고, 무심코 지나칠 수 있는 문제점이 많습니다. 이와 달리 차가운 흰색 페이지에 글을 적게 되면 그 과정에서 생각의 흐름을 면밀히 살펴보면서 미처 생각하지 못했던 부분을 발견하고 보완할 수 있습니다.
왜(Why)부터 생각해 보기
아이디어를 정리할 때 저는 가장 먼저 ‘왜(Why)’라는 질문을 던집니다. 특정 기능이나 이 아이디어가 왜 필요한지, 그리고 구체적으로 어떤 문제를 해결할 수 있는지를 명확히 적어보려고 합니다. 이렇게 이유를 먼저 고민하면 다음과 같은 이점이 있습니다.
우선순위 판단이 쉬워집니다. “이 기능은 꼭 필요한가?” “더 좋은 방식으로도 같은 목표를 달성할 수 있지 않을까?”처럼 의문을 제기하며 더 나은 대안을 생각하게 되고, 기능의 필요성을 좀 더 객관적으로 살펴볼 수 있습니다.
개발자와의 소통이 원활해집니다. “이걸 왜 해야 하는지”에 대해 공유하면, 개발자들은 단순히 ‘해야 할 일’이 아니라 제품에 가치를 더하는 의미 있는 작업으로 인식하게 됩니다. 그만큼 몰입도와 책임감이 높아지고, 필요 이상의 요구사항이 변하거나 불필요한 불필요한 충돌이 생길 가능성이 줄어든다고 생각합니다.
필요한 기능 나열하고, 시나리오 써보기
두 번째 단계에서는 만들고자 하는 아이디어를 위해 어떤 기능이 필요한지를 구체적으로 나열해 보는 것이 좋습니다. 예를 들어, 푸시 알림 기능을 기획한다고 가정해 봅시다. 알림 켜기, 알림 끄기, 시간대 설정, 알림 신청, 메시지 전송, 메시지 발송 시점 설정, 알림 삭제 등 필요하다고 생각되는 기능을 모두 적어둔 뒤, 그중 가장 중요한 기능들부터 우선순위를 정해 정리해 봅니다.
그다음에는 각 기능별로 누가, 무엇을, 언제, 어떻게 할 것인지를 담은 시나리오 형식으로 작성하면 훨씬 구체적인 그림이 떠오릅니다. 예를 들어, ‘푸시 알림 전송’ 기능은 아래와 같이 정리할 수 있습니다.
누가: 패션 쇼핑몰 앱에 로그인해 있는 고객 A
무엇: 장바구니 결제 유도 푸시 알림
언제: 사용자가 장바구니에 상품을 담은 후 24시간이 지났지만 결제를 완료하지 않았을 때
어떻게: 알림을 보내고, 사용자가 해당 알림을 누르면 결제 페이지로 이동하도록 설정
이처럼 기능에 대해 하나하나 글로 정리하는 작업을 거치면 IT 프로젝트의 고질적인 문제인 ‘불완전한 요구사항(Incomplete Requirements)’ 문제를 예방할 수 있습니다. 실제로 Standish Group Report 등 여러 조사 결과를 보면 불명확한 요구사항은 프로젝트 실패의 주요 원인으로 손꼽힙니다. 요구사항이 명확하지 않으면 소통 과정에서 혼선이 발생하고, 나중에 큰 변경 사항이 생기면서 일정이 지연되거나 프로젝트 전체가 위험에 빠지기 때문입니다.
결국, 아이디어를 글로 구체화하는 것은 단순히 “머릿속에 있는 생각을 정리하는 행위” 이상이라고 생각합니다. 팀 전체가 프로젝트의 목적과 방향을 공유하고, 효율적이며 체계적으로 작업을 진행할 수 있도록 해주는 중요한 단계라고 할 수 있습니다.
처음에는 조금 번거롭게 느껴질 수 있지만, 왜(Why) 이 기능이 필요한지와 어떻게(How) 구현할지를 명확히 글로 표현해 두면, 나중에 팀원들과의 소통, 프로젝트 일정 관리, 프로덕트 품질 개선까지 긍정적인 영향을 미친다는 점을 꼭 기억해 주시면 좋을 것 같습니다.
2. 개발 일정 산정을 위해
개발자에게 검토할 시간 주기
아이디어를 글로 잘 정리했다면, 이제 개발 일정을 예측하고 계획을 세우는 것입니다. 그런데 이 단계에서 자주 발생하는 문제가, 아이디어 정리가 끝나자마자 곧바로 "그래서 언제까지 개발할 수 있어?”라고 재촉하듯 물어보거나, 더 좋지 않은 경우 일방적으로 일정을 통보해 버리는 것입니다. 특히 비즈니스 부서나 경영진 입장에선 가능한 한 빠르게 신규 기능을 출시하고 싶어 하다 보니, 이런 일이 자주 벌어집니다.
하지만 정확한 개발 일정을 산출하려면 많은 검토 과정을 거쳐야 합니다. 글로 정리된 요구사항을 꼼꼼히 분석하고, 리스크 요인이나 기술적인 제약을 파악해야 하며, 기존 코드나 데이터베이스 구조를 살펴보거나 다른 팀(디자인, 운영 등)과도 협의도 필요합니다. 이 모든 단계를 면밀히 검토해야 비로소 현실적인 개발 기간을 산정할 수 있습니다.
제 경험상, 급하게 일정을 물어보거나 통보한다고 해서 개발이 빨라지고 좋은 결과물이 나온 적은 거의 없었습니다. 오히려 충분한 검토 없이 일정을 정하면, 막상 실제 작업에 들어갔을 때 일정을 재조정하는 일이 더 잦았습니다. 물론 통보된 일정에 억지로 맞출 수도 있지만, 그 대가로 추가 인력 투입(=야근 등), 기능 범위 축소, 추가 비용 발생 등이 뒤따르게 됩니다. (참고: IT 프로젝트 시간, 범위, 비용의 관계)
따라서 기획자와 비즈니스 담당자라면, 개발자에게 일정 산정을 위해 검토할 시간을 주는 것이 중요하다고 생각합니다. 간단해 보이는 기능이라도 내부적으로 확인해야 할 사항이 많을 수 있기 때문에, 어느 정도의 검토 기간을 보장한 뒤에 일정을 요청해야 개발자도 책임감 있는 답변을 줄 수 있습니다. 또한 개발을 '지시받는 업무'가 아니라 목표 달성을 위해 함께 고민하는 협업으로 인식할 수 있으므로 개발자의 몰입도와 책임감도 자연스럽게 높아집니다.
물론 이러한 과정을 밟아도 프로젝트를 진행하다 보면 계획과 다른 이슈가 발생할 수 있습니다. 그럴 때는 개발자와 함께 회고하며 원인을 분석하고, 다음 프로젝트에는 어떻게 개선할지 논의하면 좋습니다. 모두가 처음부터 완벽할 수는 없으니까요. 이렇게 차츰 합을 맞춰 나가다 보면, 새로운 개발 작업을 시작할 때 더욱 정확하고 원활한 협업이 가능해지는 것 같습니다.
맺으며
지금까지 이야기는 제가 대기업과 스타트업에서 프로젝트 관리자, 서비스 기획자로 일하며 경험해 왔던 점들을 토대로 정리한 것입니다. 물론 프로젝트 특성이나 팀 문화에 따라 다양한 변수가 존재하기 때문에, 여기서 제안한 방식이 100% 정답은 아닐 수 있습니다. 다만, 아이디어를 글로 구체화한 다음, 일정 산정을 위한 검토 기간을 확보하는 것만으로도 많은 문제가 사전에 방지되고 개발자와 소통이 수월해지는 것을 여러 차례 경험했습니다.
개발자와 협업하는 비개발자라면, “개발을 언제까지 할 수 있나요?”라고 묻기 전에 먼저 아이디어를 명료하게 서술하고, 개발자에게 충분한 검토 시간을 주는 문화를 만들어 보는 건 어떨까요? 그렇게 하면 개발 일정에 대한 신뢰도도 높아지고, 협업이 더 부드러워질 것입니다. 혹시 여러분만의 다른 노하우나 비슷한 경험담이 있다면, 댓글로 자유롭게 나눠 주시면 감사하겠습니다. 함께 이야기를 더 풍부하게 만들어 가면 좋겠습니다.
