SpaceONE 기존 개발 문화 엿보기
SpaceONE은 Cross-Functional 팀으로 쉽게 말해서 애자일 조직이라고 볼 수 있어요. 기획, 디자인, 프론트엔드/백엔드 개발, DevOps, 사업 파트가 하나의 조직으로 이루어져 자기 완결적으로 개발이 가능한 팀이랍니다. 기존 SpaceONE에서는 오픈소스 릴리즈 주기에 맞춰 3주 단위 스프린트를 진행하며 라이프 사이클을 맞추고 있었습니다.
스프린트가 시작되면 팀원 모두 모여 업무를 나누고 일정을 조율해서 전체적인 개발의 질과 속도를 높일 수 있었습니다. 또한, 스프린트가 종료되면 이를 기반으로 토론하며 최적의 코드 컨벤션을 구축해 전체적인 개발의 질과 속도가 향상하는 모습을 볼 수 있었는데요.
최근 기존 개발 문화를 확 뒤바꾸어 퀘스트 형 새로운 개발 문화를 도입하여 실행하고 있습니다. 과연 어떠한 개발 문화와 함께 SpaceONE의 성장을 지속하고 있을지, 또 그 과정에서 무엇을 배웠는지
SpaceONE의 변화된 개발 문화를 이번 글을 통해서 살펴보도록 하겠습니다.
스프린트 단위 개발 문화의 문제점 꼬집어 내기
SpaceONE은 런칭 이후 기존 개발 프로세스대로 스프린트 위주로 열심히 달리기만 했습니다. 이를 통해 조직 자체적인 라이프 사이클은 맞추었지만, 사용자의 니즈는 커져만 가는 상황에서 기존 스프린트 릴리즈 단위의 개발 문화를 지속적으로 수행함에 있어서 몇 가지 문제점이 도출되기 시작했습니다.
1. 사용자의 요구사항을 빠르게 대처하지 못하는 문제
: 스프린트 기준으로 개발을 진행하다 보니, 적은 인원으로 사용자의 요구사항을 즉각적으로 대처하기 어려움이 있었습니다. 스프린트 특성상 미래의 개선 아이템을 사전에 준비하고 있다 보니 고객의 니즈를 바로 처리하기에는 미흡한 부분이 있었습니다.
2. 잦은 릴리즈로 인한 버전 관리의 어려움
: 3주 단위의 스프린트로 패키징 하며 시간 이내에 처리하지 못한 개발 아이템들은 지속적으로 쌓일 수밖에 없었습니다. 이러한 아이템들은 추후 설치 가이드에 버전 명세 및 변경 작업에 대한 업데이트가 되어야 했으며, 이는 곧 오픈소스에 대한 설치 및 운영의 어려움으로 다가올 수 있었습니다.
3. 개발 외적인 업무에 대한 처리
: 런칭 이후 SpaceONE에 대한 사용자가 증가하면서 기술 지원 및 트러블 슈팅, 상용 환경 배포 및 운영, 기타 사무 지원 업무 등 개발 외에 투입되어야 하는 업무가 증가하게 되었습니다.
이외에도 수많은 이슈들이 하나씩 생겨나기 시작하면서 배움을 얻고 즐거워야 할 업무가 점차 버거워지고 있었습니다. 모든 팀원들의 고민이 더해질 즘, 선택과 집중이 필요한 시기라고 생각이 들었습니다.
업무도 게임처럼, 개발 퀘스트 클리어
이러한 문제점들이 나타나는 가운데 SpaceONE은 어떻게 일하는 것이 효율적이고 성공적일지 고민했습니다. 현재 우리 조직에서 무엇을 가장 중요하게 생각하는지 찾아내어 해당 문제부터 해결하며 변화를 시작했습니다.
SpaceONE의 개발의 목적은 사용자의 클라우드 서비스 운영 효율화입니다. 이에 맞는 목적을 달성하기 위해서는 고객의 니즈를 파악하고 그에 대해 발 빠르게 대응하며 고객 가치를 최우선으로 생각하는 게 선행되어야 한다고 생각했습니다. 이러한 생각을 토대로 다음과 같은 개발 프로세스로 변화했습니다.
변경된 개발 프로세스는 일명 퀘스트 클리어라고 불리는 프로세스입니다.
기존 3주 단위 스프린트 개발에서 탈피하고 모든 개발 아이템을 프로젝트화하여 독립적인 개발 및 배포 주기를 갖게 했습니다. 비교적 업무를 게임처럼 재미있고 즐겁게 다가가기 위한 노력인데요. 이슈가 발생하는 아이템 단위에서 모집공고를 통해 참여자를 받고 프로젝트 별 독립적인 개발과 배포를 진행하고 있습니다. 기존 스프린트 단위의 프로세스에서 전혀 다른 프로젝트 단위의 프로세스로 변경된 것입니다.
이러한 변화 가운데서 각각의 멤버들이 어떠한 프로젝트를 진행하는지, 다른 프로젝트는 어떻게 진행하고 있는지 궁금증과 의문점을 가질 수 있는데요. 매주 진행되는 Weekly Scrum 회의를 통해 프로젝트 진행 상황과 설명을 조직 내에 설명할 수 있는 시간도 마련하여 커뮤니케이션을 원활하게 진행하고 있습니다. 또한, 프로젝트에 관심은 있지만 실제 업무 수행은 하지 않는 사람들은 관찰자로 참여하여 프로젝트 진행 상황을 확인할 수 있습니다.
항목 | 기존 프로세스 (Sprint) | 변경 프로세스 (Project) |
개발 주기 | 3주 단위 Sprint | 프로젝트 별 독립 주기 |
배포 주기 | 3주 Sprint 이후에 배포 | 프로젝트 별 독립 배포 |
Open Source Packaging | 3주 Sprint 이후에 Packing | 6개월 주기로 Release 및 Packing |
QA | Sprint 기간 내 전체 QA | 프로젝트 별 독립 QA (최대한 자동화)
Open Source Release 전에 전체 QA |
고객 지원 | 담당팀에서 고객 커뮤니케이션 및 지원 | 개발 관련 아이템은 개발팀에서 직접 고객 지원 |
배포 및 검증 | 담당팀에서 배포 및 모니터링
개발팀에서 검증 | 프로젝트 멤버들이 직접 배포 및 검증 |
개발 참여 | 팀/파트별 업무 분배 및 파트 내 담당자 지정 | 자율적인 프로젝트 참여 |
퀘스트 프로젝트 정책 살펴보기
퀘스트 프로젝트를 도입함에 앞서, 관련 정책 수립이 우선이었습니다. Jira 보드에 작성되는 프로젝트란 조직 내 모든 업무를 뜻하며 개발 및 사업 지원 외에도 기타 사무 업무까지 포함되어 하나의 퀘스트로 등록하는 형태로 진행됩니다. 따라서 모든 업무는 퀘스트 보드 중심으로 진행되는 것이죠.
최초 고객의 피드백이나, 이슈, 버그, 로드맵까지 전부 프로젝트화하여 등록하고, TSC에 의해 주기적으로 우선순위를 선정하여 분류됩니다. 기존의 로드맵 프로세스와는 달리 조직 내에서도 기술적 호기심과 새로운 시도에 대한 아이디어를 부담 없이 낼 수 있고 ‘내가 잘할 수 있는 일', ‘내가 하고 싶은 일'에 대한 아이템을 선정하여 프로젝트의 멤버로 참여할 수 있다는 장점이 있습니다.
TSC란?
•
각 팀장 및 파트 리더들을 초기 TSC 멤버로 구성하여 Backlog에 작성된 아이템들을 검토 후 프로젝트화 시키고 프로젝트의 우선순위를 조정하는 기술 위원회를 뜻합니다.
(SpaceONE 퀘스트 보드)
함께 만들어가는 개발 문화
수많은 개발 프로세스와 방법론이 존재하는 가운데, 중요한 건 멋진 도구를 사용하는 게 아닙니다. 조직이 목표하고자 하는 바를 생각하며 그에 맞는 방법을 찾아가는 과정과 변화가 중요한 법입니다. SpaceONE은 기존 프로세스를 과감히 버리고 고객의 가치를 추구하기 위해 새로운 프로세스를 찾고 변화하고 있습니다.
조직에 맞는 문화를 끊임없이 생각하고 도입해 보면서 우리가 추구하는 목표에 따라 향해 나가는 게 중요하다고 생각합니다. 물론, 앞으로 계속해서 나타나고 생성될 이슈들에 대해 대처하기 위해서는 계속해서 새로운 시도와 더 좋은 문화를 만들며 발전해 나가야 하겠죠.
‘누가 시켜서 하는 일’이 아니라 ‘내가 하고 싶은 일’로 만들기 위한
SpaceONE의 새로운 개발 문화 프로세스 어떻게 보셨나요?
오늘도 SpaceONE은 퀘스트를 하나씩 클리어하며 업무를 게임처럼 즐겁게 처리하고 있습니다. 새로운 시도와 도전에 두려워하지 않고, 모두가 의견을 내고 실행하며 만들어나갈 수 있는 SpaceONE의 앞으로의 행보를 기대해 주세요!