소프트웨어 엔지니어링과 Slack: 러브 스토리

Slack이 처음부터 현재의 엔지니어링 모범 사례까지 개발자의 성공을 지원하기 위해 구축된 방식을 살펴보겠습니다.

와, 정말 빠르네요

2009년에 우리는 Glitch라는 이름의 멀티플레이어 게임을 구축하던 소규모 소프트웨어 엔지니어팀에 불과했습니다.

모두가 지속적으로 동일한 정보를 공유하기 위해 Internet Relay Chat(IRC를 기억하시나요?)을 사용하기 시작했죠. 게임 개발이 진행됨에 따라 IRC 채널이 기본 커뮤니케이션 외의 추가 기능을 제공할 수 있었으면 좋겠다고 생각하게 되었어요. 그래서 우리는 직접 이를 수정하고 기능을 추가했고, 작업을 더 빠르게 완수할 수 있는 새로운 방법을 구축하게 되었죠.

그러다 게임이 실패로 끝나게 되었죠. 그래서 우리가 개발했던 이 새 협업 도구에 집중하기로 결정했어요. 그게 좋은 선택이었죠. 매우 효율적인 팀 협업을 지원하는, 시장에 적합한 최상의 제품을 개발하게 되었으니까요.

어쩌면 우리가 무언가를 "설계"하려 들지 않았기 때문일 수도 있습니다. 딱히 자부심을 느끼지도 않았고, 가상의 사용자를 추측하지도 않았죠. 우리가 사용자였으니까요. 이것이 Slack이 탄생하게 된 배경입니다.

오늘날 Slack은 우리가 상상했던 것보다 훨씬 성장했습니다. Slack이 모든 규모의 개발팀에 도입된 것이 주요한 성장 원인이죠. 그렇습니다. Slack은 거의 모든 부서 및 분과에서 사용되고 있지만, 그중에서도 소프트웨어 엔지니어링팀이 이 모든 것이 시작된 곳입니다. Slack은 여전히 엔지니어링 분야의 수많은 사용자에게서 호평을 받고 있고, 이들의 호평 덕분에 우리는 항상 행복하게 일할 수 있죠. 개발자들의 일상적인 업무에 직접적인 영향을 미치는 무언가를 만들 수 있다는 것은 대단히 보람된 일입니다.

이 가이드에서는 Slack이 개발자들을 돕는 방법을 간단하게 소개합니다. 특히 이를 통해 소프트웨어 엔지니어들이 Slack을 좋아하는 이유를 이해할 수 있게 되기를 바랍니다.

Slack이 소프트웨어 엔지니어링에 특히 적합한 이유

Slack은 비기술 분야의 다양한 팀들이 매일 사용하는 도구입니다. Slack은 이러한 팀이 지원하는 업무에 맞게 유기적으로 적응하죠.

하지만 무엇보다도 Slack은 소프트웨어 엔지니어링 분야에 꼭 맞는 제품입니다. 어쨌든, 소프트웨어 엔지니어링은 상당히 전문화된 분야입니다.

생각해보면 모든 업무가 점점 더 이와 같아지고 있습니다. 하지만 소프트웨어 엔지니어링은 이상적인 사용 사례입니다. 이 분야에는 이메일과 미팅으로는 이루어질 수 없는 유형의 협업이 필요합니다. 따라서 이러한 업무에는 새로운 유형의 협업이 필요하죠.

Slack: 채널 기반 메시징 플랫폼

Slack을 사용해 본 적 없는 사람들은 Slack을 메시징 앱이라고 생각합니다. 그러나 Slack은 메시징 앱 그 이상이죠. Slack은 다양한 팀이 선호하는 업무 방식과 기존 소프트웨어 선택, 그리고 변화에 따라 적응합니다.

  • 채널 기반 메시징

이 기능을 이용하면 팀이 특정 작업, 프로젝트 또는 문제에 대한 전용 채널을 실행할 수 있습니다. 모든 개발자가 새 웹사이트를 구축하기 위해 모이는 #devel-new-site 채널처럼 말이죠. 또는 팀이 모바일 앱의 버그를 잡기 위해 협업하는 #triage-mobile-app 채널도 있죠.

채널에서는 적합한 사람들이 적절한 시점에 적합한 주제에 대해 논의하기 위해 모일 수 있으므로, 채널은 일대일 메시지나 폐쇄적인 이메일 스레드보다 훨씬 효율적입니다.

  • 검색 가능한 지식 저장소

지식은 검색할 수 있어야만 가치가 있는데, 이메일 첨부 문서는 보통 참조로 받은 사람을 제외한 사람들에게는 보이지 않죠. 하지만 Slack은 누구나 제품 사양 또는 새 기능에 대한 논의 등 모든 관련 문서, 대화, 의사결정을 찾을 수 있는 단일 공간입니다.

  • 통합 레이어

Slack을 사용하면 직원들이 대부분의 시간을 보내는 소프트웨어(예: GitHub, Jira, Jenkins 및 Trello)가 일상적으로 업무가 논의되는 곳으로 통합됩니다. 이러한 통합을 통해 수많은 다양한 앱을 이용해 일하는 경우 끊임없이 앱 사이를 전환해야 할 필요성이 최소화됩니다.

참고: 이러한 세 가지 기능을 한 자리에 모으면 각 기능이 훨씬 더 강력해집니다. 플랫폼은 포함된 기능을 합친 것보다 훨씬 강력한 힘을 발휘합니다.

소프트웨어 엔지니어링팀이 누리는 이점

적절한 채널 기반 메시징 플랫폼은 모든 엔지니어링 팀이 가장 중요하게 생각하는 요소(예: 개선된 코드, 더 빠른 구현, 개선된 서비스 신뢰성, 향상된 개발자 경험 등)에 직접적으로 영향을 미칩니다(따라서 인재들을 만족시킬 수 있음). 이 모든 것을 실현하는 데 도움이 되는 소프트웨어를 주의 깊게 살펴볼 가치가 있을 겁니다.

“Slack은 살아 있는 문서 허브이며 Slack에서는 모든 것을 검색할 수 있죠.”

Malika Rajvanshy수석 엔지니어, Slack

IDC는 당사의 주장에 근거를 마련해 주었습니다. 엔지니어링팀은 Slack을 사용하여 더 많은 업무를 수행하고 있습니다.

Slack으로 전체 소프트웨어 엔지니어링 프로세스를 간소화하는 방식

개발팀은 Slack을 소프트웨어 개발에 사용하는 데 있어서 가장 숙련된 사용자들입니다. 모든 개발팀이 Slack에 상주하고 있죠. 하지만 여전히 매일 새로운 사용 사례와 소프트웨어팀이 배포하고 있는 흥미로운 앱과 통합 앱에 대한 이야기를 듣습니다.

그중 몇 가지를 소프트웨어 개발 주기 단계별로 정리하여 소개해 드리겠습니다.

계획

Slack은 제품 관리자, 설계자 및 엔지니어가 구축할 대상과 그 이유에 대해 합의할 수 있도록 지원합니다.

Slack 채널 세부정보
앱 사용자를 위한 피드백 양식을 논의하는 Slack 스레드
  • 새로운 제품이나 기능에 대한 단일 채널을 이용해 전체 프로세스를 시작합니다.

이러한 채널을 featurenew-app 등으로 부를 수 있겠죠. 이제 프로젝트를 자세히 살펴보고, 기능 요구사항을 수집하고, 대안을 논의하고, 기능 및 UX에 대한 기본적인 요청을 할 수 있는 단일 공간이 마련되었습니다.

  • 여기에 문서를 공유하면 모든 것을 검색할 수 있습니다.

Slack은 Google Docs와 매끄럽게 통합되므로 기여자와 새 참여자가 모든 문서를 클릭해서 확인할 수 있습니다.

  • 궁금한 점이 있나요? 질문을 채널에 포스트하세요.

토론을 시작하고 도출된 해결책을 모두가 볼 수 있습니다. 이제 영구적인 기록이 생긴 것이죠.

코드

Slack은 개발자가 대규모 코드베이스의 수많은 움직이는 구성 요소를 조정하고, 개발 속도를 높이고, 품질을 개선할 수 있도록 지원합니다. 코딩을 시작할 때가 되면 전체 팀이 Slack의 다음 기능을 이용하여 협업할 수 있습니다.

  • 모든 것의 홈으로 이용되는 #devel-product-name 채널

여기에서는 엔지니어링 및 QA팀의 일상적인 업무, 풀 리퀘스트, 코드 병합, 설계 수정, 일일 스탠드업, 토론 등이 이루어집니다.

  • 코드 리뷰를 위한 중앙 허브

Slack은 버전 분기, 기능 분기를 개발하는 것이든, 병합된 마스터에서 나온 것이든 관계없이, 코드의 분기, 병합, 리뷰 및 릴리스를 위해 사용하는 모든 프로세스를 지원합니다.

Git 통합 앱(GitHub, Bitbucket 또는 선택한 저장소와의 통합)은 모든 변경 알림을 Slack으로 가져옵니다.

  • 새로운 유형의 스탠드업

스탠드업 미팅은 애자일 개발의 중요한 부분이지만, 꼭 대면 미팅일 필요는 없죠. 개발팀은 Slack을 사용해 매주 또는 매일 아침 등 언제든지 스탠드업 미팅을 열고, 필요한 경우에만 동기식 미팅이나 비디오 통화를 할 수 있습니다(개발팀에 최고의 미팅은 취소된 미팅임).

Standuply 등의 소프트웨어와의 통합 앱은 자동으로 요약 보고서를 Slack으로 푸시해줍니다. 따라서 팀은 목표와 작업을 공유하고, 비즈니스 지표를 추적하고, 미팅 참고 사항을 포스트하고. 팀의 진행 상황과 좋은 소식을 모니터링할 수 있습니다.

채널에 풀 리퀘스트를 포스팅하는 Slack의 Checkpoint 통합

코드 재사용 촉진: 코드 재사용은 효율적인 엔지니어링팀이 따르는 핵심 원칙이지만, 수백 명의 개발자가 수많은 다양한 제품에 기여하고 있을 경우에는 따르기 쉽지 않습니다. 개발자는 새 코드를 작성하기 전에 모든 Slack 채널 전반에서 코드를 검색해 다른 누군가가 이미 유사한 코드를 구축했는지 확인할 수 있습니다. 다음 단계: 적합한 채널에서 "날짜 선택기를 만들었던 분 계신가요?"라고 물어보세요. 같은 것을 다시 코딩하는 악순환을 멈추세요.

코드조각을 이용한 코드 작성 및 공유: 코드조각을 이용하면 코드, 구성 파일 및 로그 파일을 Slack에서 바로 손쉽게 공유할 수 있습니다. 동료는 이를 다운로드하고, 원시 파일을 확인하고, 코멘트를 남길 수 있습니다.

Slack의 실제 작동 모습

핵심적인 활용 가능성

Slack은 팀이 이미 사용하고 있는PagerDuty, GitHub 또는 Jenkins 등의 소프트웨어의 역할을 하려고 하지 않습니다.

대신 Slack은 이러한 모든 앱을 통합하고, 그러한 앱에서 작업이 실제로 논의되고 있는 채널로 관련 정보를 가져옵니다. (또한 그러한 애플리케이션에서 동작이 일어나도록 Slack 내부에서 트리거할 수 있죠.)

“언제든지 제가 설정한 Slack 통합을 확인할 수 있죠. ... “Slack은 정말 많은 가치를 제공할 뿐만 아니라 프로세스에서 많은 부가 단계를 줄일 수 있도록 도와주었어요.”

Thomas Lawless수석 소프트웨어 엔지니어, IBM

이러한 통합 앱은 개발자가 하고 싶은 일, 즉 제대로 작동하는 시스템을 만드는 일에 몰두할 수 있도록 도와줍니다. 이 가이드에서 공유되는 사례는 예시에 불과합니다. Slack을 사용하는 소프트웨어팀의 수 만큼이나 수많은 Slack 사용법이 존재하죠.

테스트

테스트는 최신 개발/배포 프로세스에 통합되어 있습니다. Slack은 동적이고 협력적이며 투명한 테스트 접근 방식을 지원합니다.

연속 통합 앱은 새로운 코드 덩어리가 병합될 때마다 테스트 도구 모음을 실행합니다. Slack은 크고 작은 수많은 방식으로 이 프로세스를 간소화합니다.

  • QA를 조정하는 #testing–feature 채널

여기서는 QA 팀이 개방된 포럼에서 개발팀과 협업할 수 있습니다.

  • 테스트 워크플로를 자동화하는 Jira 통합 앱

Slack에서 캡처한 문제를 자동으로 파이프라인에 넣습니다. 사용자 지정 가능한 알림을 Jira에서 채널로 보냅니다. 문제를 신속하게 담당자에게 할당하고, 어디에 기록되는지 파악합니다.

일부 팀은 Slack을 사용하여 변경 요청을 새 채널로 자동으로 이동시키고 동시에 Trello 또는 Asana를 업데이트합니다.

  • 각 클라이언트를 위한 채널 분류

iOS, Android 및 웹을 위한 전용 테스트 채널을 운영할 수 있습니다.

Slack의 Jira 슬래시 명령어

Jenlins를 이용한 작업

수많은 팀이 Jenkins를 연속 통합 앱 서버로 사용하고 있습니다. 모든 종류의 일상 개발 작업을 자동화하기 위해 Jenkins와 Slack을 통합시키는 새로운 방식을 고안해내는 데에는 그리 오랜 시간이 걸리지 않았죠.

한 가지 예: 개발자가 풀 리퀘스트를 열 때마다 대규모 테스트 도구 모음을 실행하는 Jenkins 서버를 가동시키는 소프트웨어팀의 사용자 지정 Slack 통합 앱이 있습니다.

테스트가 실행되면 적합한 Slack 채널에 알림이 표시됩니다. 코드가 테스트에 실패하면 개발자에게 알림이 전송됩니다.

릴리스

지속적 배포에는 항상 자주 배포되는 수많은 소규모 코드 릴리스가 필요합니다. Slack은 워크플로와 알림을 자동화하여 엔지니어링팀이 그 일부를 간소화할 수 있도록 지원합니다.

한 가지 예: 당사 소프트웨어팀 중 하나가 Ops와 통합되고 채널에서 코드 상태를 전달하는 Deploy Wizard라는 이름의 앱을 작성했습니다. 먼저 "카나리아" 단계(갑작스러운 오류를 포착하기 위한 초소규모 릴리스)로 시작한 후에 사용자 기반의 10%, 25%, 75% 및 100% 범위로 확장됩니다.

스테이징 업데이트를 포스팅하는 Slack의 Deploy Wizard 통합

Deploy Wizard는 배포가 진행됨에 따라 적합한 개발자와 Slack의 채널에 ping을 보냅니다. 전체적인 사항은 근무 중인 배포 책임자(숙련된 엔지니어, 3시간 교대 근무)에 의해 관리됩니다.

개발자가 스테이징 환경에서 코드를 테스트하려고 하는 경우, 병합 요청과 함께 코드를 지정합니다. 개발자가 #deploys 채널에 코드 테스트를 마쳤음을 보고할 때까지는 배포가 스테이징 단계에서 중단됩니다.

일부 개발팀은 슬래시 명령어(예: / deploy_productname_staging)를 사용해 Slack에서 바로 배포를 트리거합니다. 배포에 성공하면 이동 후 확인할 수 있는 링크(또는 프로덕션으로 푸시하기 위한 버튼)와 함께 자동화된 메시지가 표시됩니다.

운영

개발팀은 Slack을 사용해 문제 티켓을 심사하고, 기록 시간 내의 장애를 감지하고, 문제에 대해 논의합니다.

  • 모든 문제가 논의되는 #triage product-name 채널

고객지원팀의 보고서도 포함됩니다(수동 또는 Zendesk 등의 도구와의 통합 앱을 통해).

  • 통합 앱이 모든 알림을 한곳에 전송

개발자가 이메일을 모니터링하거나 대시보드를 확인하기를 기다리는 대신, 가장 적합한 응답자가 알림을 확인할 수 있는 단일 공간인 Slack을 활용할 수 있습니다.

PagerDuty 이벤트 또는 Asana 티켓을 취합하고 이를 적합한 채널에 포스트하면, 장애 해결 시간이 단축되고 심사 내역이 생성됩니다. 팀 멤버들은 서로 협력하여 Slack에서 바로 장애를 심사, 열람, 승인 및 해결할 수 있습니다.

이와 유사하게, Slack은 빠른 응답을 위해 모든 웹, 트랜잭션, 서버 및 모바일 알림을 New Relic에서 Slack 채널로 끌어올 수 있습니다. 장애에 관해 궁금해하는 모든 사용자는 채널에 참여해 관련 내용을 읽어볼 수 있습니다. 이렇게 하면 지속적인 업데이트를 위해 관리자가 장애 담당자의 업무를 방해하는 일을 줄일 수 있습니다. 이 모든 기능이 Slack에 포함되어 있습니다.

이모티콘과 리액티콘을 이용해 문제를 심사하고 워크플로를 트리거할 수 있습니다.

리액티콘은 팀 멤버의 응답을 포착할 수 있는 효율적인 방법이지만, 자동화된 워크플로를 트리거하는 방법이기도 합니다. 앱을 이용해 이러한 정보를 수집해 취합하고 플래그를 지정해 조치를 취할 수 있습니다. 진행 중인 모든 문제(눈 이모티콘이지만 체크 표시 없음)는 PagerDuty에 표시됩니다.

자동화된 #decisions 채널: 일부 팀은 망치 이모티콘을 이용해 의사결정이 내려졌음을 나타낼 수 있습니다. 그런 다음, 봇이 이러한 모든 의사결정을 #decisions 채널로 푸시합니다. 이 채널에서 경영진은 의사결정의 흐름을 볼 수 있고, 팀 멤버는 손쉽게 내용을 검색할 수 있습니다.

또한 Slack은 이러한 정보를 수집하여 전용 채널에 보고하는 봇을 구축했습니다.

사용자 측

소프트웨어 엔지니어에 대한 수요는 많습니다. 인재를 유지하기 위해서는 최대한 최상의 직원 경험을 제공해야 합니다. 적절한 도구는 업무 마찰을 줄이고, 투명성을 조성하고, 일상적 작업을 자동화하는 데 큰 역할을 할 수 있으며, 팀 전반의 업무를 도울 수 있습니다.

Slack을 사용하는 소프트웨어 엔지니어링팀과 대화를 나눠 보세요. 그들에게 채널, 앱, 통합 앱을 어떻게 사용하고 있는지 물어보세요. 그런 다음, 그런 기능이 없다면 어떻게 할지 물어보세요.

신규 개발자 온보딩

두 명의 신규 개발자가 팀에 합류합니다. 그들이 업무를 익히도록 하려면 어떻게 해야 할까요?

이전 방식: 수많은 온보딩 미팅을 열고 수많은 이메일 스레드를 전달해 그들이 업무를 파악하게 합니다.

새로운 방식: 그들을 #dev–new–product 채널로 초대해 다음과 같은 고정된 포스트를 확인하게 합니다.

  • 제품 사양
  • 기술 사양
  • 설계

Google Docs, Dropbox 또는 OneDrive인 경우 항상 최신 상태로 유지됩니다. 또한 그들은 이전의 모든 대화, 의사결정 및 관계자들을 살펴볼 수 있습니다. 지금까지 새로운 개발 인력을 온보딩하는 방법을 살펴봤습니다.

소프트웨어 엔지니어가 Slack을 사용하는 방법

지금까지 소프트웨어팀이 Slack을 이용해 업무를 간소화, 자동화 및 가속화하는 방법에 대해 간단히 알아보았습니다. 다음과 같은 주요 요점을 이해하셨길 바랍니다.

  • 새롭습니다. Slack은 엔지니어가 새로운 방식으로 작업하도록 도와줍니다. Slack은 매시징 앱 그 이상이죠.
  • 유연성이 탁월합니다. 팀이 선호하는 업무 방식을 반영하는 워크스페이스, 채널, 앱 및 통합 앱을 통해 "원하는 방식으로 만들 수" 있습니다.
  • 기존 소프트웨어를 더 효율적으로 활용할 수 있도록 돕습니다. 개발, 제품, QA 및 지원팀 직원이 GitHub 및 Bitbucket에서부터 Jenkins, Jira, PagerDuty, New Relic, Zendesk에 이르기까지, 어떤 도구를 사용하든 Slack에서 업무를 함께 수행하면서 이러한 도구를 더욱 효율적으로 사용할 수 있습니다. 현재 앱 디렉토리에는 2,200개 이상의 앱이 있습니다.
  • 개발 주기의 모든 단계에 가치를 추가합니다. 계획부터 개발, 테스트, 배포 및 운영까지.

소프트웨어 엔지니어가 선호합니다. 즉, 이들은 Slack을 채택하고 시간이 지남에 따라 용도를 확장한다는 의미입니다.

“우리는 소스 코드에서 시작해 프로덕션 배포에 이르는 ‘엔드 투 엔드 제공 파이프라인’을 갖추고 있습니다. 현재는 해당 프로세스의 모든 중요 단계에 Slack을 통합했습니다.”

Thomas Lawless선임 소프트웨어 엔지니어, IBM

자세한 내용을 알아보려면 데모 일정을 잡거나, 개발팀에 자체 Slack 인스턴스를 보여 달라고 요청해 보세요. 우리는 이를 자랑스럽게 생각하니까요.

이 리소스가 유용했나요?

0/600

훌륭해요!

피드백을 주셔서 감사합니다.

알겠습니다!

피드백을 주셔서 감사합니다.

죄송합니다. 문제가 발생했습니다. 나중에 다시 시도해주세요.