스타트업에서 개발자가 효율을 챙기면?
스타트업에서 협업 효율화 하기
스타트업에서 시간은 생존과 연결된다. 모든 스타트업에게 동일하게 주어지는 시간속에서 많은 회사, 사람들이 업무를 하지만 시간을 어떻게 쓰느냐에 따라 회사의 성장, 매출이 달라지게 된다.
딜라이트룸은 2주 스프린트 단위로 업무를 진행하고 있다. 2주 단위로 업무를 진행했을 때 공휴일과 휴가가 없다면 우리에게 주어지는 가용 시간은 80시간(1일 x 8시간)이다. 이 중 회의와 버퍼시간(가용 시간 중 25%를 버퍼시간으로 잡는다. )을 제외하면 평균적으로 가용 시간이 40시간정도로 계산된다.
40시간 어떻게 써야할까?
우리에게 주어지는 2주 단위의 스프린트는 작업시간이 짧기 때문에 모두가 최고의 효율을 내야 최고의 퍼포먼스를 낼 수 있다.
즉, 주어진 시간을 얼마나 효율적으로 사용하느냐가 우리의 퍼포먼스를 결정한다.
시간을 효율적으로 사용하는 것이 아닌
시간을 효율적으로 사용하게 만들기
작업자 개인의 효율보단 협업의 효율이 훨씬 더 중요하다.
쓴이는 딜라이트룸의 구독관련 작업을 하는 섭스 스쿼드(섭스쿼드) 소속 iOS개발자이다.
개발자 입장에서 어떤 시점에 협업이 많이 일어나는지 알기위해 스프린트 업무 프로세스를 순서대로 나열하였다.
01. MVP 혹은 A/B 테스트 실험 작업 할당
02. 업무의 우선순위에 따라 개발 시작
03. 개발 완료 시 QA
04. QA 완료 후 배포작업에 포함
위의 작업 순서 중 협업이 반드시 필요한 단계는 작업 할당을 위한 1번, 작업이 완료된 것에 대하여 올바르게 동작하는지 확인이 필요한 3번이 있다.
두 개의 작업 단계 중 협업을 많이 하는 단계이면서 어려움이 많은 순서가 3번 개발 완료 시 QA 요청이다.(MVP에 따라 다를 수있지만 우리팀은 데이터 관련 이 많기 때문에 보통 3번이다.)
이 단계는 QA를 진행하는 팀원과 협업이 가장 활발하며, 동일한 작업에 대하여 여러번 확인하기도 한다. 그렇기 때문에 시간을 비효율적으로 사용하는 일이 빈번하게 일어난다.
비효율에서 오는 답답함
우리는 그로스팀이기 때문에 데이터를 굉장히 중요시 여긴다.
때문에 데이터를 분석하고 수많은 A/B 테스트를 진행하는데 이를 위한 이벤트 설계와 A/B테스트 실험을 적용해야한다.
모든 스프린트에 위의 두 가지를 실행하며 이를 위한 데이터 관련 QA를 진행할 때 여러가지 병목현상이 발생하였다.
(어쩌면 데이터 분석 툴은 우리에게 불친절할지도…)
개발자는 콘솔 로그를 통해서 쉽게 확인할 수 있지만 QA를 하는 팀원 입장에서는 그렇지 않다. (컴퓨터를 믿을 순 있지만 작업자는 항상 자기 자신을 의심해야한다. 그렇기 때문에 QA 시점에서의 확인이 중요하다.)
개발을 진행할 때 개발자가 하는 QA가 어려웠다면, 이를 확인하는 PO 혹은 디자이너는 더 힘들다고 생각한다.
데이터 관련 QA 시 비효율적인 시간을 효율적으로 만들기
앞서 데이터 QA시점에 우리 스쿼드는 아래 두가지를 매번 확인한다.
- 이벤트가 특정 시점에 잘 보내지는지 확인
- 대조군 / 실험군이 잘 할당됐는지 확인
여기서 병목현상이 발생하면 모든 스프린트마다 비효율적으로 사용되는 시간은 누적된다. 따라서 여기서 발생하는 비효율적인 시간을 줄이면 팀의 퍼포먼스가 올라간다고 생각하였다.
위의 두 시점에 발생하는 병목현상이 어떤것이 있었고, 이를 개선하기위해 어떤것을 했는지 경험을 공유하고자 한다.
이벤트가 특정 시점에 잘 보내지는지 확인
이 시점엔 어떤 병목이 있었는가 ?
유저의 액션에 대하여 이벤트를 보냈을 때, 우리는 분석 툴을 통해서 확인하는데 이 시점에 병목현상이 발생한다.
- 분석툴에서 클라이언트의 이벤트가 확인될 때까지의 대기시간
Real-time data stream을 지원하는 툴도 있지만 지원하지 않는 툴도 있고, 네트워크에 영향을 많이 받는다.
대기시간을 5분 ~ 10분정도 걸린다고 하면, 스프린트 마다 여러개의 작업을 하기때문에 평균적으로 인당 20분정도의 대기시간을 비효율적으로 사용하게 된다.
한달에 2개의 스프린트, 일년에 24개의 스프린트를 진행하게된다면 대기시간이 불러오는 비효율의 스노우볼은 엄청 클것이다.
대기시간 줄이기
대기시간을 줄이기 위해서 이벤트를 앱에서 바로 확인할 수 있도록 개발하였다. (Swift AsyncStream을 사용해보고 싶었는데 마침 사용하기 적절한 기능이었다.)
이벤트 콘솔의 기능은 다음과 같다.
- 왼쪽 화살표를 통해 이벤트 콘솔 로그를 표시/숨김 처리
- 이벤트 실시간 확인
- 특정 이벤트를 선택하여 이벤트에 대한 상세정보 확인
- A/B 테스트 대조군 / 실험군 할당 확인
이 기능을 사용하면 개발자 뿐 만 아니라 이벤트 확인이 필요한 동료들 모두 대기시간을 줄일 수 있었다.
대조군 / 실험군이 잘 할당됐는지 확인
이 시점엔 어떤 병목이 있었는가 ?
대조군과 여러 실험군들에 대하여 동작을 확인하기 위해서 여러번의 앱 재설치를 해야하는 상황이 발생하는데, 실험 할당을 위한 재설치 시점에 병목현상이 발생한다.
- 앱 설치 -> 대조군 / 실험군 할당 확인
실험군이어야 하는데 대조군으로 할당되면서 앱을 재설치하게된다.
혹은 분석툴에서 대조군 100%, 실험군 100%로 변경해야하는 번거로움이 발생한다.
재설치 시간 줄이기
앱에서 대조군/실험군을 바로 변경할 수 있는 기능을 개발하였다.
enum ABTest: String {
case control_none = "대조군 키값"
case variant = "실험군 키값"
}
extension ABTest: ABTestable {
var key: String { "abtest" /* 실험 식별자 */ }
var id: String { rawValue /* 대조군 혹은 실험군의 키값 */}
}- 실험 식별자와 대조군/실험군에 대한 키값을 갖는 구조체 혹은 Enum 타입이 ABTestable이라는 프로토콜을 채택한다.
- Sourcery를 이용하여 현재 진행중인 실험들에 대하여 Auto-Generate 된 배열 객체를 만든다.(개발자는 실험 설계만 만들면 Sourcery가 자동으로 디버그 모드에서 변경가능한 객체로 만들도록 개발하였다.)
- 디버그 모드에서 현재 실행중인 실험의 목록과 실험에 대한 대조군/실험군을 변경할 수 있다.
이 기능을 통하여 개발자 그리고 실험이 올바르게 동작하는지 확인해야하는 동료들의 시간을 아낄 수 있었다.
기능 개발외에도, 프로세스 개선을 통해서 팀의 효율을 높이는 것을 생각하는 것이 좋은 팀이다.
‘나' 보다는 ‘우리'의 시간
대기시간과 재설치 시간을 줄이기 위해서 2가지 기능을 만드는데 투자한 시간은 3시간 미만이다.
개발자의 3시간은 ‘우리'의 시간이 지날수록 더욱 더 큰 스노우볼이 되어 10시간, 20시간, 100시간을 효율적으로 사용하게 할 수 있다.
시간은 스타트업에서 생존과 연결되기에 이를 효율적으로 사용하기 위해 만든 작은 기능은 회사의 성장에 도움이 되는 나비효과 불러일으킨다.
일이 되게 만드는 동료들과 함께 하실 분! 🙋♂
⏰ 딜라이트룸에서 알라미와 함께 아침을 바꿀 분들을 모십니다 🙌
- 👉 딜라이트룸에 어떤 포지션이 있는지 궁금해요(+ 입사 축하금 100만원💸)
- 👉 딜라이트룸 미디엄 팔로우하기 (카테고리 섹션 오른쪽의 ‘Follow’ 버튼 클릭)
- 👉 딜라이트룸 일상을 엿볼 수 있는 인스타그램 구경하기
