💡 해당 포스팅은 실패한 경험들을 기반으로, '나라면 이렇게 시도해볼 것 같다'라는 내용의 주제를 담고 있습니다.
성공의 경험이 아닙니다.
4번의 장기 프로젝트 런칭 실패의 경험을 기반으로 같은 실수를 번복하지 않기 위한 전략이며,
정답이 아닌 개인적인 주관이 가득 찬 글일 뿐입니다.
1. Introduction
📌 4번의 장기 프로젝트 실패의 경험
졸업 전에 반드시 실사용자 트래픽을 받는 서비스를 받고자 하는 목표가 있었다.
그렇게 총 4번의 장기 프로젝트를 진행했으나, 모두 런칭 실패로 끝나고 말았다.
대체 이유가 무엇이었을까?
4개의 이유는 모두 제각각이었다.
- 너무 부족한 개발 지식으로 인한 실패 (6개월)
- 현직자들하고 프로젝트를 하다보니, 작업이 계속 지연되면서 팀원 이탈 (6개월)
- 디자이너와의 의견 충돌로 인한 최종 런칭 무산 (1년)
- iOS 앱 정책을 준수하기 위한 비용이 너무 커서 무산 (1년)
1의 실패를 번복하지 않기 위해 미친듯이 공부를 했고,
2의 실패를 번복하지 않기 위해 일정이 맞는 팀원들과 지속적인 미팅을 가졌으며,
3의 실패를 번복하지 않기 위해 기획과 프로젝트 관리를 보다 철저하게 했다.
그럼 4번 째 프로젝트 시작 전에 앱 심사 규정을 더 잘 살펴보았다면 프로젝트는 성공했을까?
아마 서버 유지비가 감당이 안 돼서 접었을 가능성이 크다.
즉, 위 모든 전략들은 그저 근시안적으로 바라본 문제를 완화했을 뿐, 근본적으로 뭔가 잘못되어 있다는 말이었다.
그러다 문득, 최근에 영어 회화 모임에서 사용할 목적으로 아주 간단한 웹 사이트 2개를 만들었다.
센터에도 이야기를 해놓아서 생각보다 사용자가 조금 있었고, 피드백을 받아서 몇 가지 기능을 덧붙이기도 했다.
그러다 문득, 갑자기 머리를 세게 한 대 얻어맞은 듯한 느낌이 들었다.
1년을 투자한 프로젝트는 실사용자 한 명 못 받고 끝났는데, 발로 만든 1일짜리 프로젝트는 실사용자 트래픽을 받고 있던 것이다.
여기서 나는 근본적인 원인에 대해 깨달음을 얻게 되었다.
그리고 나같이 실패하는 사람이 조금은 줄어들길 바라는 마음에서 포스팅을 작성하기로 했다.
📌 프로젝트 목적
🤔 우리는 왜 프로젝트를 하는가? 개발자로서, 공학도로서 프로젝트에서 무엇을 얻어가야 하는가?
프로젝트를 진행하기 전에 반드시 하나 짚고, 팀원 모두가 공통의 이해를 갖는 시간을 가져야 하는 것이 있다.
바로 프로젝트의 목표와 목적이다.
학생 프로젝트의 특성 상, 수익화를 크게 노리지 않는 경우가 많다.
그러다 보니 대부분은 다음의 이유일 것이다.
- 기술적인 심화
- 실사용자 트래픽 받기
- 배포 경험 쌓기
결국 수익성보다는 공부를 목적으로 한 프로젝트를 진행하게 되는데, 이는 자칫 두 가지 잘못된 늪에 빠질 우려가 있다.
- 공부에 너무 집중하는 나머지 정작 개발 진행이 더뎌짐
- 실사용자 대비 과한 기술을 사용하게 됨으로써, 서버 유지비 증가와 유지/보수 어려움 (수익성은 고려도 안 했음에도 불구하고)
- 기술적으로 완벽하지 않다는 불안감에 런칭을 자꾸만 보류함.
공부를 목적으로 잡지 말라는 말이 아니다.
다만, 우리가 IT 전공자이기 이전에 공학도라는 사실을 잊지 않았으면 좋겠다.
우리가 왜 클린 코드를 위해 고민하고, 최선의 기술을 사용하기 위해 공부하고, 원활한 협업 환경을 만들기 위해 노력하는가?
그리고 왜 사용자 트래픽을 받고자 하며, 다들 이것이 진정한 개발자로 성장하는 길이라고 말하는가?
간단하다.
이것들이 결국 돈과 직접적인 관련이 있기 때문이다.
유지/보수에 들어가는 자원들이 주는 만큼 다른 곳에 투자할 자원이 늘어나는 효과를 가져오는 것이고,
이론에서 벗어난 실세계의 운영 환경에서 실용적인 솔루션을 고민하는 과정을 경험할 수 있기 때문이다.
그런 공학도에게 있어 최악의 공부법은 이론에 갇히는 것이라 생각한다.
실제 사용자를 받아보지도 못 했으면서, 최신 IT 트렌드 뉴스를 읽고, MSA 서비스를 구축할 능력이 되고, 다양한 풀 스택 역량을 갖추고 있으면 뭐하나. (간지나긴 해~)
언제, 어떤 상황에서 해당 기술이 적재적소에 쓰이는 지 알 지도 못하기 때문에 초기 투자 비용이 과하게 산정되고, 프로젝트는 시작하자마자 막대한 적자를 달성하고 시작한다.
그렇다면 다시 한 번 생각해보자.
프로젝트의 목표를 공부로 잡았으니, 기술적인 극한을 연구하는 것이 개발자의 미덕인가?
그럴리가.
결국 프로젝트의 목표는 수익화가 됐건, 공부가 됐건, 배포 경험이 됐건,
나 자신을 로컬 호스트에서 강제로 끄집어 내는 상황을 만드는 것이 최우선 시 되어야 한다.
기술적인 극한을 연구하는 건 연구자가 할 일이거나, 그런 상황이 필요해졌을 때 할 일이지, 로컬 호스트에 머문 개발자 따위가 할 일이 아니다.
돈과 공학적 지식은 로컬 호스트에서 나오지 않는다.
2. 프로젝트의 규모 산정
📌 기술 주도 이론 vs 수요 견인 이론
기획이나 창업에 조금이라도 관심있는 사람이라면 한 번쯤 들어본 단어일 것이다.
과거의 대부분 회사는 기술 주도 이론을 따랐다.
산업 혁명 이후 대규모 생산이 가능해지면서, 사람들은 그저 기성품들을 소비했기 때문이다.
기업의 결정과 성장 방향이 곧 시장을 주도했었다. (애플은 여전히 이러고 있다.)
그러나 사람은 본질적으로 끊임없이 남들과 나 자신을 비교해댄다.
그런 사람의 본질을 따지고 봤을 때, 점차 그들은 자신만의, 자신에게 특화된 상품들을 원하게 된다.
기업에서 수십 억, 수십 조를 쏟아부어 기술의 집약체를 만들어 내더라도, 소비자에게 외면당하면 끝이다.
이 이야기를 한 이유는 공학도들의 주요 실패 원인 중 하나를 이야기 하기 위함이다.
공학도들은 흔히 기술적 성공이 프로젝트의 성공이라 착각한다.
자신의 밑천을 드러내고 싶어하지 않아서, 서비스는 겉으로 굉장히 화려한 기능들이 즐비해야 하고 기술적으로 완벽하길 바라기 때문에, 장기간에 걸쳐 서비스 하나를 간신히 구현해낸다.
그리고 성대하게 실패한다. (내 얘기다. 쓰면서 눈물 흘림.)
우리는 이런 식으로 접근해선 안 된다.
대기업보다 우리가 압도적으로 유리한 포지션이 두 가지가 있는데,
- 사용자와 소통이 쉽다.
- 우리는 약간의 수익만 생겨도 서비스 운영에 큰 보탬이 된다. (수익 발생까진 몰라도, 서버 유지비 정도는 벌 수 있다.)
그렇다면 우리가 해야할 건 무엇인가?
우선 사용자와 소통을 해봐야 한다.
어차피 1년 공들여서 개발했다고 사람들이 고생했다며 사용해주지 않는다.
그럼 그냥 1~2주 투자해서 서비스 하나 내보고, 반응이 좀 있으면 운영하고, 없으면 그냥 버리는 게 낫다.
반응이 있다면 사용자와의 상호작용이 발생함을 의미하고, 여기서부터 진짜 개발자로서의 공부를 할 수 있게 된다.
📌 최소 기능 제품(Minimum Viable Product, MVP)
💡 욕심 부리지 말자
한창 애자일이 무엇인가 고민하던 때에 MVP 라는 용어를 처음 접했었다.
MVP는 소비자가 원하는 최소한의 기능만을 갖춘 상품을 의미한다.
물론 난 여전히 뭐가 최소 기능인지 모르겠지만, 적어도 그 의미를 어렴풋이 이해했다.
예를 들어보자, 나는 작년에 지출 관리 SNS 플랫폼 서비스를 만들고자 했다.
여기서 MVP 1.0으로 생각한 기능은 인증과 지출 관리 서비스였다.
- 인증 기능
- 사용자는 일반 로그인, OAuth(카카오, 구글, 애플) 로그인이 가능하다.
- 지출 관리 서비스
- 사용자는 임의의 날짜에 특정 지출 내역을 등록할 수 있다.
- 사용자는 자신만의 지출 카테고리를 만들 수 있다.
- 사용자는 매일 저녁 지출 알림을 받을 수 있다.
- 사용자는 매월 목표 소비액을 설정할 수 있다.
- 사용자는 매월 첫 접속 시, 목표 금액을 설정하는 추천을 받을 수 있다.
- 사용자는 월별, 캘린더별 지출 내역 리스트를 확인할 수 있다.
이 정도면 충분히 MVP 모델이라고 볼 수 있지 않겠냐고 생각했지만 잘못된 판단이었다.
다시 한 번 생각해보자.
내가 만들려던 MVP 1.0은 그저 지출 관리에 대한 서비스다.
그런데 굳이 일반 로그인 기능이 필요했을까?
자체 인증 서비스는 고려해야 할 것들이 너무나도 많다.
이 과정에서 보안 이슈가 발생할 여지가 너무 많고, 보안 취약점을 발견하는 것도, 고치는 것도 쉬운 일이 아니다.
(물론 모범적인 인증 기능 구현 절차가 존재하지만, 솔직히 학생만 실수하는 것도 아니지 않는가)
또한, 최근 사용자들은 애초에 일반 로그인 기능을 잘 사용하지도 않는다.
실제로 한 달이면 다 만들 수 있을 것이라 생각했던 기능이 3개월이나 소요되는 사태가 벌어졌다.
서비스 핵심 가치를 보여주는 기능에 대한 개발 기간은 그만큼 축소될 수밖에 없었고, 프로젝트는 지연되었다.
차라리 OAuth 로그인만을 도입하는 것이 더 나았을 것이고, 서비스 핵심 가치에는 아무런 문제가 되지 않는 부분이었다.
현재 만들려는 기능이 서비스의 비즈니스 가치를 창출하는 요소인지, 그렇진 않지만 필수적인 요소인지 잘 생각해보자.
그렇지 않은 부분들은 나중에 추가해도 늦지 않는다.
단, 가치를 창출하는 핵심 기능에 있어서는 반드시 요구되는 사양에 부합한 성능을 보이도록 구현해야 한다.
3. 협업이 언제나 최선인가?
📌 맨 먼스 미신(The Mythical Man-Month)
지체되는 소프트웨어 개발 프로젝트에 인력을 더하는 것은 개발을 늦출 뿐이다.
맨 먼스(Man/Month)는 SW 프로젝트 비용 산정 단위를 말한다.
쉽게 말해, 사람 1명이 1개월 동안 작업할 수 있는 일의 양을 말한다.
- 1MM: 1명이 1개월 동안 작업하는 일의 단위
- 2MM: 1명이 2개월 동안 작업 or 2명이 1개월 동안 작업하는 일의 단위
그러나 사람이 많다고 작업량이 끊임없이 비례해서 증가하지 않는다.
그 이유는 아이러니하게도 우리가 사람이기 때문이다.
사람과 협업을 하기 위해서는 의사소통이라는 추가 비용이 발생하는데, 이는 프로젝트 운명을 좌우할 수도 있는 큰 비용이다.
혼자서 결정했으면 될 일을 둘이서 의논해야 하고, 둘이서 의논하면 될 일을 4명이서 의논해야 한다.
의논하기 위한 시간과 장소를 마련해야 하고, 만족스러운 합의가 도출되기 전까지 작업은 멈출 수도 있다.
도중에 갈등이 생기기라도 하면 문제는 더 골치 아파진다.
물론 갈등을 잘 해결해서 포트폴리오에 쓸 스토리가 생겨서 이득이라고 생각할 수도 있지만, 실패하면 진짜 터질 수도 있다.
(난 잘 해결했는데 왜 터진 거냐고)
📌 혼자하는 걸 고려해보라.
예전만큼 웹이나 앱 개발에 큰 흥미가 없는 만큼, 최근 안드로이드 개발은 내게 지루한 영역 중 하나다.
그렇지만 분명한 건, 협업을 할 때보다 압도적으로 빠른 속도의 개발이 가능하다.
MVP 얘기를 먼저 꺼낸 것은 이를 위한 빌드업이었다.
처음부터 어마무시한 규모의 애플리케이션을 꿈꾸는가?
그러지 말고, 정말 단순한 애플리케이션 여러 개를 런칭해보는 것은 어떤가?
3주 동안 투자해서 런칭해서 사용자 받아보고, 이 과정을 계속 반복하다보면 살아남는 서비스가 하나는 생기기 마련이다. (물론 홍보, 마케팅을 어느정도 필요로 한다.)
이런 빠른 속도의 개발은 차라리 혼자서 하는 것이 낫다.
나도 현재는 지금 만들고 있는 서비스의 규모가 어느정도 커지면, 그 때 팀원을 모집해보려 생각하고 있다.
4. 기술과 아키텍처 선정
📌 그걸 왜 사용하려고 하시는 건데요?
지금까지 정말 많이 받았던 질문인데, 어떤 기술을 배우고, 어떤 아키텍처로 서비스를 구축해야 하는지에 관한 것이었다.
- "MSA로 서비스를 구축하려고 하는데요~"
- "Redis를 처음 사용해보려고 하는데요~"
- "Hateoas 꼭 공부해야 하나요?"
그럼 항상 되묻는 건, "그걸 대체 왜 도입하고 싶어하시는 건가요?"였다.
내가 그 기분을 이해하지 못하기 때문이 아니다.
기업에선 뭔가 자꾸 더 알아오길 요구하고(이젠 하다하다 쿠버네티스가 인턴 필수 요건에 나온다), 개인적으로 이런 것들에 욕심이 생겨서 더 공부하고 싶은 마음은 누구보다 공감할 수 있다.
(요새 뭐만하면 MSA~MSA~ 거리는 게 한 몫한 거 같긴 한데, 이거 공부해본 사람은 알겠지만 학생이 배울 이유도 없고, 애초에 저 서버 굴리는 돈이 장난아니게 많이 깨진다. 러닝 커브도 엄청 높고, 돈은 돈대로 깨지는데, 내 서비스에 써먹을 일은 결코 없는 미친 개념이다.)
문제는 그게 개인 공부 목적이면 상관 없는데, 프로젝트 도입을 위해서라면 신중해져야 한다.
- "MSA로 서비스를 구축하시겠다구요? 혹시 서비스에 핵심 기능이 적어도 4~5개에 관련 개발팀이 다 따로 배치될 수 있을 만큼 규모가 크신가요? 모든 개발자 혹은 팀의 주축이 되는 개발자가 모두 동일한 MSA의 지식 수준을 가지고 있나요?"
- "Redis를 사용해야 할 정도로 해당 기능이 빠른 성능을 요구하나요? 애초에 캐싱의 목적으로 사용하시려는 것은 맞나요?"
- "Hateoas의 정의와 존재 이유는 알고 계시고 있나요? 본인 프로젝트에서 어떻게 사용하려고 하시는 건가요?"
정말 필요로 하더라도, 아래와 같이 추가 비용들을 감내할 수 있는 지 생각해보라.
- 도구에 따라 러닝 커브가 매우 높을 수 있다.
- 팀원들이 새로운 도구 도입에 찬성하지 않거나, 이해도가 떨어진다면 갈등이 생길 수도 있다.
- 도구가 내가 예상하는 동작대로 움직일 것이라 보장하는가? 이를 위한 테스트 전략은 구비해두었는가? 장애가 생기면 대처할 방법이 있는가?
- 새로운 도구를 도입하기 위한 돈은 확보할 경로가 있는가?
만약, 위 항목 중 보장이 안 되는 무언가가 있다면, 좀 더 심플한 방법이 없었는지 고려해볼 필요가 있다.
(이게 진정한 한정된 자원 내에서 최선의 솔루션을 고민하는 과정 아닌가.)
기술은 필요에 의해 사용하는 것이지, 기술에 끌려다니면 부적절하다.
예상 트래픽 수 대비 성능 요구 지표가 떨어져서 개선이 필요하다거나, 시스템이 장기적으로 유지/보수가 어려워질 것 같다거나 하는 문제가 없다면, 굳이 남들이 한다고 해서 따라할 이유가 없다.
(만약 포폴용 프로젝트면 기술을 최우선으로 다루면 된다. 배치 작업 데이터 1,000만 개까지 늘어날 일 없으므로, 현재 성능으로 충분하다고 했는데, 납득 안 해주시는 분들이 꽤 많았다.)
📌 아키텍처는 단순하게 시작해서, 리팩토링으로 개선하라
소프트웨어 개발 3대 원칙으로 KISS, YAGNI, DRY라는 게 있다.
- Keep It Simple Stupid!: 소프트웨어를 설계하는 작업이나 코딩을 하는 행위는 되도록 간단하고 단순하게 만들어라.
- You Ain't Gonna Need It: 필요한 작업만 해라.
- Do not Repeat Yourself: 반복되는 코드를 없애라.
개발을 하다보면, 자꾸만 미래의 최악의 상황을 산정하게 되는 경우가 잦다.
그러나 당장 내 앞 날도 모르겠는데, 서비스의 앞 날을 정확하게 맞추는 경우는 드물다.
경험과 데이터에 따른 신뢰성 있는 위험 감지라면 모를까, 개인의 불안에 의한 디자인 패턴, 아키텍처들은 오히려 소프트웨어 유지 보수성을 저하시킨다.
내 일련의 사례들을 보여주면 다음과 같은 경우가 있었다.
- 싱글 모듈로 진행을 하다가, 여러 서버가 동일한 기능들을 공유해야 하는 경우가 생겨서 멀티 모듈로 마이그레이션 했었다.
- MVVM으로 애플리케이션을 개발하던 iOS 팀에서 이슈가 자꾸 발생하여, 전체 아키텍처를 재설계하고 바로잡음으로써 문제를 완화했다.
물론 리팩토링이 필요한 시기를 늦게 알아채서 비용이 많이 잡아 먹히기도 하지만,
쓸 데 없이 복잡한 설계의 코드를 작성했다가 추후 기능 수정이나 확장에 어려움을 겪는 것보단 훨씬 할만 했었다.
5. Conclusion
📌 요약
뭔가 쓸 건 많은데, 글이 너무 장황해지길래 쓰다가 지워버렸다.
이번 글에서는 꼭 전달하고 싶었던 핵심 키워드만 쓰는 게 오히려 낫다고 판단했다.
- 일단 작은 서비스로 런칭해라. 욕심을 버려라.
- 큰 실패 한 번보다, 작은 실패 여러 번하는 게 리스크도 적고 성공 확률도 높다.
- 팀원 많다고 좋진 않다.
- 기술과 아키텍처는 적당히, 필요하다고 판단될 때 잘 고려해서 사용하고 개선하는 게 좋다.