워터폴을 애자일로. 하나.

as-is.

14년된 우리 회사는 12년 동안 수없이 많은 구조 변화를 시도했음에도, 워터폴 + 기능 조직 구성의 프로덕트 팀 체계를 유지하고 있어요. 왜 2025년인 지금까지도 그랬냐고 물어볼 수도 있는데, 우린 워터폴 방식으로도 잘 해왔다고 생각했거든요.

기획팀 + UI팀 + 개발팀(Full-Stack)으로 구성된 초기 모델. 기획팀 대신 UX/UI팀이 기획 업무까지 수행하던 UX/UI + Full-Stack 개발팀 모델. 신사업 기반으로 목적조직을 신설해 운영해본 TF 모델. 기획 업무를 UX/UI 팀 대신 개발자가 리드하는 Dev-Driven 조직. 여러가지를 수행해보았다고 생각하지만, 각각의 장단점이 명확할 뿐, 장점만 있는 방법은 없다라고 느꼈었어요.

결국, 기존 구성원들에게 제일 익숙한 워터폴 방식. 그리고 워터폴 방식이 편한 기능 조직 구조를 계속 활용하게 됬죠. 😒 개발 조직도 BE+FE 구조가 아닌 풀스택 개발자만을 채용하는 방식을 지속적으로 유지했어요. 워터폴의 특성상 하나의 기능조직이 더 생겨버리면 제품의 변화까지 너무 오랜 시간과 너무 많은 커뮤니케이션이 필요했었거든요.

But.

채용이 힘들어질 줄은..

Python을 주 언어로 사용하는 Full-Stack 개발자를 채용하는 건 2020년까지 그렇게 어려운 일이 아니었어요. 기존에 ruby 등으로 Full-Stack 역량이나 지식을 갖추고 있으면서 Python을 다룬 분들도 많았고, data 분석 붐으로 Python을 주 언어로 사용하려는 주니어 개발자분들도 많았었죠. 당시에 상당히 많은 프로그래밍 학원에서 Python을 많이 밀었고, Python 데이터 분석 혹은 Python Web 개발 with Flask 와 같이 가볍게 비전공자분들도 시작할 수 있는 강의로 개발자 커리어를 시작하는 분들이 지원도 많이 해주셨어요.

하지만, 2021년을 넘어서며 코로나, 개발자 포화 단계, 많은 수의 스타트업이 폐업하는 등 여러 요소가 겹치면서 주니어 개발자부터 수요보단 공급이 많아지기 시작했고, 2022년 말 즈음엔 0~3년차 공고에 지원하는 5년차 이상 개발자 분들이 전체에 35%를 차지했어요. 시니어 개발자도 공급이 많아지는 시점으로 전환됬죠. 기업들이 개발자의 연봉을 높게 주며 모셔가던 분위기에서, 개발자 연봉이 너무 높다는 이야기가 나오기 시작한 시기기도 했던것 같아요.

그러다보니 오히려 채용이 어려워지기 시작했어요. 😳

• 개발자를 직업으로 삼으려는 신규 유입이 줄어들고, 비전공자의 개발자 전향이 줄어들면서 자연스럽게 Python을 배우려는 신입 개발자가 줄었어요..
  • 🧐 국내 개발자 시장은 Java가 우선인데, 비전공 개발자가 줄고 전공 개발자만 남는다면, Python을 좋아하는 사람 비율이 낮아지겠네..
  • 🧐 커뮤니티 활성화가 잘되어있던 Python이 코로나 몇번 맞으며 커뮤니티 행사가 온라인/연기 되는 등...
  • 🧐 특히 Django, Flask 쓰던 스타트업들이 많이 망했고.. 행사 후원이 줄었고.. 취업이 안되니 학원들도 강의를 내리고..
• 경력있는 개발자들은 워터폴 방식의 개발 문화에 대한 부정적인 인식으로, 거부감이 컸고요.
  • 🧐 네카라쿠배당토의 안정적인 채용과 좋은 개발문화에 대한 소문 덕분에, 경력 개발자들에게 워터폴 방식의 구시대적인 개발 문화는 고려 대상이 아니었던것 같아요.
  • 🧐 Python을 사용하는 기업들이 줄어들면서 특히 Python을 풀스택 개발 환경의 베이스로 쓰는 기업들은 더 많이 줄었어요. DRF 기반의 BE + FE 구조의 기업들은 많았지만, Django 기반의 Web Full-Stack은 당시 채용공고 리스트에서 우리만 올려놨던..
  • 🧐 지금이야 시니어 개발자들도 AI 덕분에 Python에 대한 관심도가 있지만, 22년도에는 정말 우리회사의 채용 암흑기였죠.

Full-Stack을 BE+FE로

Full-Stack 팀이던 우리도 Django + jQuery 만으로는 답이 없다 싶어, 중간에 Angular.js 도 시도해봤고(물론 3년 잘 쓰고 다시 없앴지만..), 내부 시스템부터 Next.js 기반의 환경으로 전환하는 작업을 시작했어요. Full-Stack 팀에서 자연스럽게 FE+BE로 분리하는 계획도 조금씩 준비했죠. 완전한 워터폴 대신 제품 기획과 UX+UI를 담당하는 UX 조직 -> 이후 BE+FE 병렬 개발을 진행하는 방법으로 변경해봤어요. Full-Stack 팀에서 FE-BE 중 원하는 조직을 선택해 팀원들의 전환도 진행하고, 좋은 FE 리더도 모셔온 후에 채용에도 힘썼죠.

기존 시스템을 FE+BE 환경으로 전환하는 작업도 서비스 단위로 조금씩 조금씩 이루어졌어요. 우리 회사의 코어인 계정 서비스, 월 1.5M PV의 Owned Media 서비스도 옮기고, 기존 신사업들의 독립 서비스들도 옮겼죠. 그러면서 기존 서비스의 기능 개선과 확장도 Full-Stack 환경에서 지속해왔어요.

그랬더니, FE와 BE에 속한채로 기존 서비스의 기능 개선을 담당하던 팀원들은 변화없는 구조에 괴로움을 느꼈고, 급하고 중요한 프로젝트를 기존 서비스에 구현하다보니 FE 조직은 팀의 효용성을 낮게 생각하고.. 기획부터 UX, UI 까지 담당하던 UX 조직은 기존 서비스와 FE+BE 환경에 필요한 디자인 시스템 부터, 기존 서비스의 마이그레이션 디자인까지하다 정신과 몸이 피폐해졌죠.

UX/UI

• 기획자 역할까지 수행하는 UX/UI 조직인데, 워터폴이라고? 우리가 욕은 다먹네.. 우리가 바꾼거 아니라고요.. PO한테 가세요..
• 기껏 디자인 시스템으로 구상해놓으면 왜 기존서비스에서 구축한대요? 간격, 디자인 방식, 레이아웃 달라서 다시 해야된단말이에요. 화면 가로폭도 다르잖아요!!
• 워터폴이라 이후에 UX/UI 개선도 못하는데, FE+BE는 자꾸 배포먼저 하자그러고, PO랑 QA도 우리가 하는데, 앞 뒤로 너무 치여...
• 아 개발자 채용 어려운거 모르겠고 우리도 기획하는 디자이너 채용하기 힘들어요.. 6달 걸려서 1명 뽑았는데..

BE

• 기존 서비스랑 FE+BE 로 만든 신규 서비스랑 각 서비스간에 유기적인 기능 개발하는 거 너무 힘들어..
• 기존 서비스 로직들 우리도 이제 몰라.. 그만 찾아와..
• 인프라 통제가 안돼.. 기존 서비스 빨리 끄고싶어.. 제발..

FE

• 거 죄다 기존 서비스에서 할거면 우린 왜 뽑아놧대유? 그냥 풀스택 개발자 뽑지?
• 디자인 시스템 빨리 완성해야 우리한테 일 줄거 아니에요.. 디자인팀 왜 이거 안해줘요..
• QC, QA 때 디테일한 간격, 패딩, 폰트 크기까지!!! 이게 진짜 중요해요???

그래서.

집단 퇴사가 일어나기 전에, 제품 조직 전체의 구조를 변경하게 되었다 이말입니다. 너무 늦어서 팀원들에게 미안하고, 더 좋은 환경으로 출발하지 못해 안타깝지만.. 워터폴 + 기능 조직을 애자일 + 매트릭스 조직으로 전환하는 그 과정을 어떻게 고민하며 준비했는지 기록을 남겨봅니다.