안녕하세요! 프론트엔드 개발자 코디(Kody)입니다. 👋🏻
스타트업에서 일하다 보면, 환경이 끊임없이 변화하는 걸 몸소 경험하게 되는데요. 특히 새로운 팀원이 합류하면, 기존 방식이 자연스럽게 바뀌고, 때로는 예상치 못한 문제들이 발생하기도 합니다.
저희 팀도 비슷한 경험을 했어요.
저희 팀은 초기에 원래는 개발자들끼리만 있는 팀이었고, 빠른 대화와 즉각적인 코드 수정으로 빠르게 기능을 만들어내던 팀이었습니다.
이후 서비스 확장을 위해 기획자분과 디자이너분을 새롭게 모시게되면서 저희의 개발 프로세스에도 변화가 생겼었는데요!
📌 결과는?
체계적인 프로세스 덕분에 디자인 퀄리티가 높아지고, 기능 기획도 더 촘촘하게 진행할 수 있게 되었어요.
하지만… 속도가 확연히 느려졌습니다. 🫠
기존 방식은 너무 자유로웠고, 새 방식은 뭔가 느렸던 상황.
이대로 가도 괜찮을까? 🤔 고민이 깊어진 끝에, 결국 우리 팀만의 해결 방법을 찾아 제안하게 되었어요.
이번 글에서는.
✔️ 기존 방식과 새 방식의 차이점
✔️ 속도가 느려진 이유
✔️ 어떻게 개선했는지
✔️ 개선 후 어떤 변화가 있었는지
이야기해 보려고 해요. 비슷한 고민을 하고 있는 스타트업 팀이라면, 도움이 되길 바랍니다! 🙆🏻♂️
💨 원래는 이렇게 개발했었다! (개발자만 있었던 시절)
우리는 원래 기획자와 디자이너 없이 오직 개발자들끼리만 있는 팀이었습니다.
그때는 “기획”이라는 개념이 따로 있지도 않았어요.
📌 기존 방식 (개발자끼리만 있을 때의 프로세스)
- 아이디어가 떠오르면, 바로 팀원에게 공유 → “이거 이런 기능 만들면 괜찮지 않을까?”
- 간단한 대화 후, 바로 개발 착수 → “오케이, 내가 백엔드 API 만들게.”, “그럼 나는 프론트 작업할게.”
- 서로 개발하면서 필요한 사항이 생기면 실시간 논의 → “이 버튼 클릭하면 이 페이지로 이동할까?”. “응, 그렇게 하고 UI는 일단 이렇게 만들자.”
- 기능이 얼추 완성되면, 서로 직접 테스트 → “일단 로컬에서 돌려봤는데 괜찮아 보인다!”
- 바로 배포 & 운영하면서 문제 생기면 즉시 수정 → “배포했는데 사용자 반응 괜찮네!”, “오, 근데 이 부분 좀 불편한데 바로 고쳐야겠다!”
이렇게 빠르고 가볍게 일하는 방식이었고, 속도는 꽤나 빨랐습니다. 🚀
✔ 회의는 거의 없고, 다 대화로 해결!
✔ UI는 빠르게 만들고 나중에 다듬는 방식
✔ 빠르면 하루 만에 기능이 추가됨
근데… 문제도 있었습니다.
📌 기획자와 디자이너가 합류! 체계는 잡혔지만… 속도가 줄었다.
개발자끼리 빠르게 진행하는 방식은 장점도 많았지만, 점점 서비스가 커지면서 단점도 점점 더 뚜렷해졌어요.
- UI/UX가 제각각이라 일관성이 없었음 → 사용자 경험이 불안정
- 기획이 부족해 개발 중간에 방향이 바뀌는 일이 많았음 → 개발 낭비 발생
- 문서화가 없어서 나중에 유지보수가 어려워짐
이 문제들을 해결하기 위해, 우리 팀에 기획자와 디자이너가 합류하게 되었습니다. 그리고, 새로운 프로세스가 생겼어요.
📌 새로운 방식 (기획자 & 디자이너 합류 후 프로세스)
1️⃣ 아이디어 도출
2️⃣ 아이디어 회의 (다 같이 기능 정리)
3️⃣ 기획 단계: 세부 기획, 와이어프레임, 기능 명세서 작성
4️⃣ 디자인 단계: 피그마 디자인 진행
5️⃣ 백엔드 개발: API 개발
6️⃣ 프론트엔드 개발: 화면 개발
7️⃣ QA 단계: 테스트 후 배포
📌 장점
✅ 일관된 UI/UX를 유지할 수 있음
✅ 체계적인 기획 덕분에 중간에 방향이 흔들리는 일이 줄어듦
✅ 문서화가 되니, 나중에 유지보수가 훨씬 쉬워짐
📌 문제점
❌ 속도가 확연하게 느려졌다!
❌ 기능 하나 만들 때마다 논의할 게 너무 많음
❌ QA 단계에서야 실제 테스트가 이루어지다 보니, 수정하는 데 리소스 낭비가 심함
📌 결론
✔ 이전 방식은 너무 자유로웠다.
✔ 새 방식은 너무 무겁다.
✔ 그러면… 중간 단계를 만들면 되지 않을까? 🤔
🚀 해결책: LAB 방식 도입!
그래서 나온 해결책이 “LAB 방식” 입니다!
✔ 기획과 디자인을 촘촘히 하는 건 유지하되,
✔ 새로운 아이디어나 기능은 먼저 실험해보고 확정하는 과정을 만들었어요.
우리는 이 실험 공간을 “랩(Lab)” 이라고 부르기로 했어요.
📌 LAB 방식 (개선된 프로세스)
1️⃣ 아이디어 도출
2️⃣ 빠르게 개발 & 테스트 → “부텐 랩”에서 실험
3️⃣ 랩에서 직접 테스트 & 판단
→ 🤔 별로면 빠르게 폐기
→ 👍 괜찮으면 → 데모 버전으로 확장 & 유저 피드백 받기
4️⃣ 정식 서비스 확정되면, 기존 프로세스(기획 & 디자인)로 촘촘히 개발
5️⃣ QA 단계 - 정식 서비스 수준으로 테스트
6️⃣ 서비스 배포 🚀
📌 이 방식의 장점
✔ 빠르게 실험하고 결정할 수 있다!
✔ 괜찮으면 정식 프로세스로 가져가고, 아니면 바로 폐기!
✔ 기획과 디자인의 장점도 유지하면서, 스타트업다운 속도도 살릴 수 있다!
🎉 변화 후 팀의 반응은?
✅ 기획자 & 디자이너: “불필요한 기획 낭비가 줄었어요!”
✅ 개발자: “속도가 확실히 빨라졌어요!”
✅ 팀 전체: “필요 없는 기능을 만들지 않게 됐어요!”
이제는 기능을 기획부터 개발까지 완벽하게 만들려 하기보다,
🚀 빠르게 실험하고, 좋은 것만 선택적으로 발전시키는 방식으로 바뀌었어요!
💡 마무리: 작은 팀은 작은 팀답게!
완벽한 기획보다는 빠른 실험과 검증이 훨씬 더 중요하다는 걸 다시 한번 깨달았습니다.
혹시 여러분의 팀에서도 비슷한 문제를 겪고 있다면, 이런 방식도 한 번 고려해보세요!
긴 글 읽어주셔서 감사합니다! 🙆🏻♂️
'개발 일기' 카테고리의 다른 글
Next.js 정리 - React와 Next.js, 서버컴포넌트와 클라컴포넌트, CSR과 SSR (0) | 2025.03.03 |
---|---|
광고 배너 데이터가 뒤섞였다? 실수에서 배운 테스트 코드의 중요성 (0) | 2025.02.09 |
이벤트루프와 캐싱을 활용한 데이터 필터링&정렬 성능 최적화 (0) | 2025.01.27 |
스타트업 프론트엔드 개발자의 사내 디자인시스템 구축기 (1) | 2025.01.26 |
검색 기능 간단한 개선/리팩토링 과정 (1) | 2025.01.14 |