슬랙: 4가지 애자일 가치와 방법

해외 유명 IT 기업은 각자 자신들의 블로그를 운영해 개발 방법과 기업 문화 등을 소개하고 있습니다. 요즘IT는 이러한 IT 기업 블로그의 콘텐츠를 번역해 소개하는 시리즈를 준비했습니다. 이들은 어떻게 사고하고, 어떤 방식으로 일하는 걸까요?

이번 글은 클라우드 기반의 업무 협업 툴로 알려진 슬랙(Slack)의 ‘The Four Agile Values and Slack’을 번역했습니다. 슬랙이 중요하게 생각하는 애자일 가치는 무엇일까요? 아래의 글을 통해 그들의 애자일 개발 원칙과 방법에 대해 살펴보겠습니다.

애자일 개발 방식은 팀 문화를 강화하고 고객 가치를 지속적으로 제품에 더하며, 프로젝트가 올바르고 빠르게 나아갈 수 있는 길을 제시합니다. 끊임없이 변화하는 비즈니스 환경에서 유연성은 프로그램 관리자, 게임 개발자, 시스템 설계자, 마케팅 기획자 모두에게 요구되는 덕목이며, 애자일 접근 방식이 여기에 큰 역할을 합니다. 

다양한 애자일 프레임워크가 있지만 서로 비슷한 개발 원칙을 공유하고 있습니다. 여기서 가장 중요한 것은 어떻게 애자일 팀을 만들 것인가입니다. 본 글에서는 4가지 애자일 가치에 대해 알아보고, 슬랙(Slack)에서 우리가 성공적인 애자일 팀 구축을 위해 자사의 제품을 어떻게 사용하고 있는지 알아볼 것입니다.

1. 상호작용이 프로세스와 도구보다 중요하다.

슬랙의 기술 프로그램 관리(TPM, Technical Program Management)의 핵심 원칙은 프로세스보다 사람을 우선하는 것입니다. TPM은 도구, 프로세스, 기술을 혼합하여 사람과 그들의 요구사항을 충족합니다. 우리는 기술의 발전을 주도하고 회사의 성공적인 미션 달성을 위해 슬랙을 사용하여 고유한 솔루션을 개발하고 있습니다. 

TPM은 슬랙을 통해 태스크를 자동화하고 팀 간의 활발한 정보 공유를 촉진합니다. 예를 들어, TPM에는 다음으로 구성된 자동화 프로세스가 있습니다.

• Roadmapbot: 채널의 프로젝트 소식을 요약하여 공유함
• Bugbot: 심각도가 높은 문제를 강조함
• Decisionbot: 의사결정 내용을 실시간으로 포착함

이러한 프로세스는 가볍게 동작하며 프로젝트의 가시성과 투명성을 높이고, 원활한 진행을 돕습니다.

또 다른 사람 중심의 프로세스 중 하나로 회고가 있습니다. 회고(retrospective 혹은 줄여서 retro)는 팀이 생산한 산출물을 되돌아보고 개선할 부분을 도출하는 것으로 애자일 개발에 필수적입니다. 일반적으로 회고는 팀원들이 만나 솔직한 피드백을 주고받으며 프로젝트가 어떻게 진행되고 있는지 평가하는 자리입니다. 

IT 환경의 변화에 맞춰 슬랙 TPM 역시 디지털 퍼스트 방식을 채택했으며, 이러한 활동 대부분을 슬랙으로 가지고 왔습니다. 우리는 슬랙에서 회고 전용 채널을 만들고, 브레인스토밍을 위해 가상 포스트잇을 활용했습니다. 동기/비동기 토론을 위해 비디오를 활용하고 디지털 투표로 사람들의 적극적인 참여를 유도합니다. 이러한 애자일 활동을 슬랙에서 수행함으로써 일관된 방식으로 팀 활동을 모니터링하고, 구성원의 더욱 활발한 참여를 유도하며 한번 수행한 활동을 재사용할 수 있게 되었습니다. 

2. 소프트웨어의 동작이 수많은 문서보다 중요하다. 

슬랙은 문서 작업보다 개발에 무게를 둡니다. 일반적으로 엔지니어링 팀은 개발 대상을 문서화하기보다 동작하는 프로토타입을 최대한 빨리 만드는 것을 선호합니다. 우리에게 있어 슬랙은 그 자체가 문서화 도구이며, 제품과 관련한 수많은 논의가 채널에서 이루어집니다. 우리에게 가장 중요한 것은 고객에게 가치를 제공하는 것이지 거기에 도달하기 위한 모든 단계를 추적하는 것은 아닙니다.

이러한 원칙을 프레임워크와 결합한 스프린트 데모(Sprint Demo)는 새롭게 개발된 결과물을 검토하는 인기 있는 애자일 도구입니다. 빠르고 확장 가능한 데모를 위해 슬랙의 많은 팀은 반복적인 디지털 동기화를 통해 프로젝트 진행 상황과 방향을 확인합니다. 시간대, 지역, 근무 시간 기준으로 구성된 팀의 경우, 채널에 음성과 비디오 메시지를 게시합니다. 그리고 허들에 참여하여 채팅하고 실시간으로 화면을 공유하면서 개발된 내용을 모두에게 공유합니다. 

슬랙에서 진행되는 내용을 음성, 비디오, 화면 녹화 등으로 공유함으로써 다른 팀원들의 피드백과 호응을 얻을 수 있으며, 이를 반복하고 작업에 반영하며 앞으로 나아갈 수 있습니다. 슬랙을 사용하는 팀은 빠르게 방향을 전환하고 노력의 낭비를 방지하여 프로세스에 소모되는 시간과 에너지를 절약할 수 있습니다.

3. 고객과의 협업이 계약 협상보다 중요하다.

고객은 제품 개발의 원동력입니다. 고객이 만족하지 않으면 가치가 없는 제품을 만든 것과 같습니다. 우리는 제품을 개발할 때 고객과 직접, 그리고 자주 협업하며 신속한 피드백 루프를 구축하고자 노력합니다.

이러한 프로세스를 위해 개발팀은 슬랙 커넥트(Slack Connect)를 사용하여 고객, 협력업체, 파트너와 바로 상호작용하고 있습니다. 이를 시작하려면 팀 사이에 공유되는 채널을 구성하고 사람들을 초대하며 대화를 시작하면 됩니다. 이는 한 차원 높은 협업을 가능하게 만들어주며, 개발팀은 더욱 긴밀한 실시간 피드백 루프를 구축하고 보다 빠른 의사결정을 내릴 수 있습니다. 또한 슬랙 커넥트 채널을 사용하면 파트너에게 개발 예정된 기능에 대한 정보와 출시 일정을 공유할 수 있으므로, 모두가 다음 단계에 대해 미리 대비할 수 있습니다. 슬랙 커넥트 공유 채널은 팀 간의 신속한 커뮤니케이션을 가능하게 만들고, 고객과의 직접적인 협업을 제공하는 강력한 도구입니다.

4. 계획을 따르기보다 변화에 유연하게 대응한다.

신속한 피드백은 슬랙이 빠르게 변화에 대응할 수 있게 만들어주는 원동력입니다. 우리는 고객에게 제품을 더 빨리 전달할수록, 더 빨리 피드백을 수집하고 개선할 수 있다고 믿습니다. 슬랙에서의 프로세스 계획은 TPM이 주도하고 있으며, 소프트웨어 개발에서 자주 일어나는 변경 사항에 유연하게 대응할 수 있는 다양한 방법론을 제공합니다. 

여기서 말하는 계획은 제품 로드맵과 작업 범위를 정의하는 것 그 이상을 의미합니다. 서로 다른 역할을 지닌 팀이 협업할 때는 각 팀이 기여할 수 있는 부분을 명확히 정의하고, 이를 자주 재검토하는 것이 좋습니다. 슬랙 TPM은 엔지니어링 팀과 협력해 정기적으로 팀의 역량을 파악하고(자동화 활용), 빠르게 병목 현상을 예측했습니다. 그에 따라 개발 분량을 조정할 수 있는 도구와 프로세스를 개발했습니다. 이렇듯 유연한 프로젝트 계획을 통해 관리자는 팀의 문제점을 쉽고 빠르게 판단할 수 있으며, 슬랙이 제공하는 계획 도구를 통해 각 팀이 수행할 수 있는 작업량을 쉽게 조정할 수 있습니다. 

보다 구체적인 실무 차원에서 변화에 대응하려면 실제로 작업이 일어나는 곳에서 많은 논의를 거쳐야 합니다. 우리가 자주 활용하는 기능은 가벼운 오디오 커뮤니케이션 도구인 슬랙 허들(Slack Huddles)입니다. 허들을 사용하면 누구나 대화에 참여하거나 빠져나올 수 있으며, 모두가 시간을 할애해 한 데 모이는 딱딱한 회의가 필요하지 않습니다. TPM, 제품 관리자, 엔지니어 및 관리자는 슬랙 허들을 사용하여 진행 상황을 빠르게 공유하고, 계획을 조정하며 활발한 의사소통을 수행합니다. 허들은 빠른 의사 결정과 커뮤니케이션을 위한 가볍지만 강력한 도구입니다. 

정리하기

팀은 서로 다른 문화와 업무 방식을 가지고 있습니다. 모든 팀이 자신의 방식을 유지하면서도 다른 팀과 효율적으로 협업할 수 있다면, 이보다 더 좋을 수는 없을 것입니다. 슬랙 TPM은 팀을 연결하는 중요한 역할을 하고 있으며, 서로의 차이점을 포용하며 같은 방향으로 나아가는 데 기여하고 있습니다. 애자일 도구를 활용하여 정기적으로 검토하는 것은 프로젝트의 성공을 위해 중요한 부분으로, 구성원 각자가 서로 연결되어 있다고 느끼는 공유 문화를 위한 가치 있는 투자입니다.