🎮 좋은 개발 문화, SpaceONE이 일하는 방식

👩🏻‍💻 SpaceONE 기존 개발 문화 엿보기

SpaceONE은 Cross-Functional 팀으로 쉽게 말해서 애자일 조직이라고 볼 수 있어요. 기획, 디자인, 프론트엔드/백엔드 개발, DevOps, 사업 파트가 하나의 조직으로 이루어져 자기 완결적으로 개발이 가능한 팀이랍니다. 기존 SpaceONE에서는 오픈소스 릴리즈 주기에 맞춰 3주 단위 스프린트를 진행하며 라이프 사이클을 맞추고 있었습니다.

스프린트가 시작되면 팀원 모두 모여 업무를 나누고 일정을 조율해서 전체적인 개발의 질과 속도를 높일 수 있었습니다. 또한, 스프린트가 종료되면 이를 기반으로 토론하며 최적의 코드 컨벤션을 구축해 전체적인 개발의 질과 속도가 향상하는 모습을 볼 수 있었는데요.

최근 기존 개발 문화를 확 뒤바꾸어 퀘스트 형 새로운 개발 문화를 도입하여 실행하고 있습니다. 과연 어떠한 개발 문화와 함께 SpaceONE의 성장을 지속하고 있을지, 또 그 과정에서 무엇을 배웠는지 이번 SpaceONE의 변경된 개발 문화를 이번 글을 통해서 살펴보도록 하겠습니다.

🤏🏻 스프린트 단위 개발 문화의 문제점 꼬집어 내기

SpaceONE은 론칭 이후 기존 개발 프로세스대로 스프린트 위주로 열심히 달리기만 했습니다. 이를 통해 조직 자체적인 라이프 사이클은 맞추었지만, 사용자의 니즈는 커져만 가는 상황에서 기존 스프린트 릴리즈 단위의 개발 문화를 지속적으로 수행함에 있어서 몇 가지 문제점이 도출되기 시작했습니다.

1. 사용자의 요구 사항을 빠르게 대처하지 못하는 문제
   스프린트 기준으로 개발을 진행하다 보니, 적은 인원으로 사용자의 요구사항을 즉각적으로 대처하기 어려움이 있었습니다. 스프린트 특성상 미래의 개선 아이템을 사전에 준비하고 있다 보니 고객의 니즈를 바로 처리하기에는 미흡한 부분이 있었습니다.
   
2. 잦은 릴리즈로 인한 버전 관리의 어려움
   3주 단위의 스프린트로 패키징 하며 시간 이내에 처리하지 못한 개발 아이템들은 지속적으로 쌓일 수밖에 없었습니다. 이러한 아이템들은 추후 설치 가이드에 버전 명세 및 변경 작업에 대한 업데이트가 되어야 했으며, 이는 곧 오픈소스에 대한 설치 및 운영의 어려움으로 다가올 수 있었습니다.
   
3. 개발 외적인 업무에 대한 처리
   런칭 이후 SpaceONE에 대한 사용자가 증가하면서 기술 지원 및 트러블 슈팅, 상용 환경 배포 및 운영, 기타 사무 지원 업무 등 개발 외에 투입되어야 하는 업무가 증가하게 되었습니다.
   

이외에도 수많은 이슈들이 하나씩 생겨나기 시작하면서 배움을 얻고 즐거워야 할 업무가 점차 버거워지고 있었습니다. 모든 팀원들의 고민이 더해질 즘, 선택과 집중이 필요한 시기라고 생각이 들었습니다.

변경된 개발 프로세스는 일명 퀘스트 격파라고 불리는 프로세스입니다. 기존 3주 단위 스프린트 개발에서 탈피하고 모든 개발 아이템을 프로젝트화하여 독립적인 개발 및 배포 주기를 갖게 했습니다. 비교적 업무를 게임처럼 재미있고 즐겁게 다가가기 위한 노력인데요. 이슈가 발생하는 아이템 단위에서 모집공고를 통해 참여자를 받고 프로젝트 별 독립적인 개발과 배포를 진행하고 있습니다. 기존 스프린트 단위의 프로세스에서 전혀 다른 프로젝트 단위의 프로세스로 변경된 것입니다.

이러한 변화 가운데서 각각의 멤버들이 어떠한 프로젝트를 진행하는지, 다른 프로젝트는 어떻게 진행하고 있는지 궁금증과 의문점을 가질 수 있는데요. 매주 진행되는 Weekly Scrum 회의를 통해 프로젝트 진행 상황과 설명을 조직 내에 설명할 수 있는 시간도 마련하여 커뮤니케이션을 원활하게 진행하고 있습니다. 또한, 프로젝트에 관심은 있지만 실제 업무 수행은 하지 않는 사람들은 관찰자로 참여하여 프로젝트 진행 상황을 확인할 수 있습니다.

👉 SpaceONE 공식 홈페이지 놀러 가기

👉 문의 하기 spaceone-support@megazone.com

👉 개발자 문서 바로 가기

공유하기