이 글은 "기능 성공"과 "제품 성공"이 다르다는 점을 강조하며, 현업에서 제품이 실패하지 않도록 거치는 13단계 개발 프로세스를 설명합니다. 코드를 짜기 전부터 출시 후 회고까지, 각 단계에서 겪는 고민과 결정들을 통해 비개발자나 초보 개발자들이 놓치기 쉬운 실제 개발의 복잡성과 중요성을 쉽고 친절하게 알려줍니다. 특히, 기획과 설계 단계에서 리스크를 파악하고, 데이터 기반으로 기능을 검증하며, 실패를 인정하고 개선하는 용기가 제품 성공에 필수적임을 강조하고 있습니다.
1. 제품 방향성을 잡고 아이디어를 구체화하는 기획 단계 💡
현업에서 코드를 한 줄도 쓰지 않는 시기임에도 불구하고, 프로젝트의 전체 공정 중 가장 치열하게 고민해야 하는 구간이 바로 이 기획 단계입니다. '무엇을 만들지'에 대한 근본적인 질문에 답하고, 잠재적인 실패 요인을 미리 제거하는 것이 중요하죠.
1.1. Step 1. PF (Prioritized Features): 우선순위 기능 정하기
이 단계에서는 PO(Product Owner)가 비즈니스 가치와 사용 가능한 리소스를 고려해서 프로젝트의 우선순위를 논의하고 결정해요. 아이디어는 항상 넘쳐나지만 리소스는 부족하기 마련이죠. 가장 중요한 질문은 "지금 가장 비싼 문제는 무엇인가?"입니다. 예를 들어, '신규 가입 이벤트'와 '결제 오류 개선' 중에 고민해야 한다면, 결제 단계 이탈률이 28%라는 로그 데이터를 바탕으로 결제 오류 개선이 더 시급한 문제라는 결론을 내릴 수 있어요. 기획의 시작은 가장 아픈 곳을 찾아내는 것부터 시작됩니다.
1.2. Step 2. FBS (Feature Being Specified): 기능 상세 요구사항 정의하기
여기서 팀의 실력이 확연히 갈린다고 해요. 단순히 "어떤 기능 넣자"고 나열하는 것은 누구나 할 수 있지만, 진짜 실무에서는 목표(North Star)와 함께 실패 기준(Kill Metric)과 보호 지표(Guardrail Metric)를 함께 정해야 합니다. 만약 전환율이 올랐다고 좋아했는데 환불률이 폭증하거나 고객센터 문의가 두 배가 됐다면, 그 기획은 실패한 것이기 때문이죠.
1.3. Step 3. RFD (Ready for Design): 디자인 준비 및 기획안 리뷰
상세 명세가 나왔다고 해서 바로 디자인에 들어가는 것이 아니에요. 이 단계에서는 기획안(1-Pager)을 PO와 함께 다시 한번 리뷰하면서 디자인의 범위와 방향성을 최종적으로 확정합니다. 치열한 논의 끝에 기능 자체가 아예 엎어지는 경우도 있는데, 이것은 아주 건강한 신호라고 볼 수 있어요.
출시하고 나서 수천만 원의 매몰 비용을 쓰는 것보다 여기서 한 번 접는 게 백배 천배 싸게 먹히거든요ㅋㅋ 제때 멈출 줄 아는 용기가 제품을 살립니다.
2. 비즈니스와 기술의 접점을 맞추는 설계 단계 🏗️
기획 단계에서 '무엇을 만들지' 결정했다면, 이제는 "이대로 만들어도 정말 괜찮은가?"를 치열하게 검증하는 단계입니다. 이 단계에서 리스크를 제대로 잡지 못하면 나중에 큰 문제가 발생할 수 있어요.
2.1. Step 4. FBD (Feature Being Designed): UX 디자인 및 사용성 테스트
UX 디자이너가 기획안을 바탕으로 실제 유저가 보게 될 화면과 경험을 설계하는 단계입니다. 단순히 디자인이 예쁜지보다는 유저가 헷갈리지 않는지가 훨씬 중요해요. 디자인 시안으로 사용성 테스트를 진행하다가 유저가 "근데 이 버튼은 뭐예요?"라고 묻는 순간, 그 디자인은 실패한 것으로 간주하고 처음부터 다시 그려야 합니다. 출시 후에 유저들에게 비난받는 것보다 이 단계에서 고치는 것이 훨씬 낫습니다.
2.2. Step 5. RFE (Ready for Engineering): 엔지니어 및 QA 킥오프 미팅
기획과 디자인이 완성되면 엔지니어와 QA 담당자들이 모여 본격적인 개발 시작을 알리는 킥오프(Kick-off) 미팅을 가집니다. 이 단계가 정말 중요한 분기점인데요, 개발자가 설명을 듣고 "네, 이 정도면 문제없습니다."라고 무심코 말하는 순간, 그 기능에서 발생하는 모든 리스크는 개발자 본인의 책임이 됩니다. 그래서 이 단계에서는 '까칠한 시니어'가 되어야 해요.
"네트워크 끊겼을 때 처리는요?" "환불 케이스는 기획에 반영됐나요?" "법적으로 개인정보 이슈는 없나요?"
이처럼 불편한 질문들을 던져야 출시 후 고객센터 전화 폭탄이나 새벽 서버 장애 같은 더 큰 문제를 막을 수 있습니다. 변수의 90%는 이 단계에서 잡고 가야 제품이 망하지 않습니다.
3. 실제 결과물을 만들어내는 개발 및 검증 단계 🛠️
기획과 리스크 체크라는 큰 산을 넘었다면, 이제는 진짜 결과물을 만들어내는 '전쟁터'에 들어설 차례입니다. 이 단계는 단순히 코드를 짜는 정적인 시간이 아니라, 최선의 선택을 위한 치열한 협상의 연속이라고 볼 수 있어요.
3.1. Step 6. FUE (Feature Under Engineering): 기능 구현 및 시스템 구축
담당 엔지니어가 기획과 디자인을 바탕으로 실제 기능을 구현하고 시스템을 구축하는 단계입니다. 여기서 API 협의는 예상보다 치열한 전쟁터가 될 수 있습니다. 프론트엔드와 백엔드는 같은 기능을 두고도 서로 다른 관점을 가질 때가 많거든요.
프론트: "응답에 이 필드 하나만 추가해 주세요." 백엔드: "그거 뽑으려면 DB 조인 세 번 더 해야 하고, 캐시 구조까지 다 바꿔야 합니다."
이처럼 '한 줄 추가'처럼 보이던 요청이 아키텍처 전체를 흔드는 큰 의사결정으로 이어지기도 합니다. 심지어 새 기능을 붙였는데 앱 실행이 0.4초 느려진다면, MAU(월간 활성 사용자)가 수백만 명인 서비스에서는 곧바로 매출 하락으로 이어질 수 있어요. 그래서 기능을 미루고 성능부터 잡는 설계 싸움이 벌어지는 곳이 바로 이 단계입니다.
3.2. Step 7 & 8. RFQ (Ready for QA) & FUQ (Feature Under QA): QA 준비 및 검증
개발이 완료되면 QA팀의 검증을 받을 준비를 마칩니다(RFQ). 그리고 QA팀이 UI 디테일부터 기능적 세부 사항까지 철저하게 체크하는 단계(FUQ)로 넘어갑니다. QA는 적이 아니라 아군이에요. 여기서 QA에게 세게 맞을수록 출시 후에 유저에게 덜 맞게 됩니다. 네트워크가 끊기거나 수만 명이 동시에 접속하는 상황 등 온갖 엣지 케이스(Edge Case)를 QA가 찾아내면, "이 정도면 되겠지"라는 안일한 생각은 산산조각 나죠. 하지만 여기서 문제점을 발견하고 고치는 것이 백배 낫습니다. 꼼꼼한 QA는 결국 개발자의 편안한 밤잠을 지켜주는 유일한 방패입니다.
4. 데이터 기반의 최종 검증과 출시 결정 📊
QA까지 무사히 마쳤다고 해서 축배를 들기에는 아직 이릅니다. 이제부터는 개발자의 주관이나 노력이 아니라, 냉정한 데이터의 심판을 받아야 하는 시간이기 때문이죠. 이 단계에서는 멘탈 관리가 정말 중요합니다.
4.1. Step 9. RFT (Ready for Testing): 테스트를 위한 기술적 준비
QA를 통과한 기능을 실제 운영 환경에 배포하기 전, A/B 테스트나 점진적 배포(Canary Release)를 위한 모든 기술적 준비를 마치는 단계입니다. 절대 바로 모든 유저에게 전원 배포하지 않아요. 항상 먼저 묻는 질문은 "망하면 어떻게 되돌리지?"입니다. Feature Flag나 점진 배포, 즉시 롤백 전략이 준비되지 않았다면 실험 자체를 시작하면 안 됩니다. 만약 에러가 터졌는데 되돌릴 방법이 없으면 개발자에게는 재앙이니까요.
4.2. Step 10. FUT (Feature Under Testing): A/B 테스트 및 데이터 분석
실제 유저의 일부를 대상으로 A/B 테스트를 진행하면서, 기획 단계에서 세웠던 가설이 맞는지 데이터를 수집하고 분석하는 단계입니다. 여기서 멘탈이 많이 흔들릴 수 있습니다. 예를 들어, "버튼 색을 바꾸면 전환율이 오른다"는 가설을 세웠는데, 결과는 "클릭은 늘었지만 결제 완료는 줄었다"로 나올 때가 있어요. 이때 팀 전체가 조용해지곤 하죠. 데이터는 결과를 주지만 '이유'는 알려주지 않기 때문에, 클릭은 늘었는데 왜 구매는 줄었는지 우리가 치열하게 찾아야 합니다. 이때 자존심을 세우면 안 됩니다.
내가 한 달 동안 공들여 만든 기능이 지표를 깎아먹고 있다는 걸 인정하는 것, 그게 실무에서 제일 어렵지만 중요한 자세입니다.
4.3. Step 11 & 12. FL (Feature Launched) & FNL (Feature Not Launched): 기능 출시 또는 폐기 결정
A/B 테스트 결과를 바탕으로 기능이 정식으로 전체 유저에게 출시되거나(FL), 가설이 틀렸다고 판단되면 출시하지 않기로(FNL) 결정하는 단계입니다. 지표가 좋으면 웃으며 배포하지만, 나쁘면 과감히 지워야 합니다. 한 달 밤새워 만든 기능이라도 데이터가 아니라고 말하면 과감히 버릴 줄 알아야 해요. 진짜 무서운 것은 실패했는데도 계속 남아있는 기능입니다. 그런 기능은 코드를 복잡하게 만들고 다음 개발을 계속 느리게 만드는 기술 부채가 되거든요. 쓰레기통에 넣을 줄 아는 용기가 제품을 살립니다.
4.4. Step 13. Post-Mortem (사후 회고): 문제 분석 및 개선책 마련
프로젝트의 모든 과정이 종료된 후, 발생한 문제와 성공 요인을 분석해서 다음 프로젝트를 위한 개선책을 마련하는 단계입니다. 실무에서 장애는 언제든 발생할 수 있어요. 하지만 장애가 났을 때 누가 실수했는지 찾는 것은 하수입니다. 진짜 실무팀은 "왜 시스템이 이 실수를 막지 못했나"를 집요하게 파고들어요.
"알람은 왜 늦게 울렸지?" "롤백하는 데 왜 이렇게 오래 걸렸지?" "테스트 케이스에서 이건 왜 빠졌을까?"
이런 질문들을 반복하다 보면 팀은 조금씩 더 단단해집니다. 실수는 사람이 하지만, 그것을 막는 것은 시스템이어야 하니까요.
결론 🚀
현업에서 가장 비싼 비용은 개발자의 연봉이 아니라, 잘못된 방향으로 세 달 동안 전력 질주하는 것입니다. 그래서 기능 하나를 내보낼 때도 이렇게 촘촘하고 지루한 과정을 거치는 것이죠. 학교에서는 '돌아가는 코드'를 가르치지만, 실무는 '망하지 않는 제품'을 만드는 법을 가르칩니다.
이러한 13단계 프로세스는 주로 규모가 큰 기업에서의 이야기지만, 지난 13년간 시니어 개발자로 일하며 체득한 저자의 경험이 담겨 있어요. 1인 개발을 할 때는 많은 공정을 단축하더라도, 이 전체적인 맥락을 이해하고 체화하면 단순히 코드만 잘 짜는 것을 넘어 '성공하는 제품'을 만드는 빌더가 될 수 있을 것입니다. 여러분도 이 프로세스를 통해 더욱 단단한 개발자로 성장하시길 바랍니다! 💪