아틀라시안 방식:
Atlassian은 개발자의 업무 마찰을 줄이고 개발의 본질적인 즐거움을 회복하는 ‘developer joy’를 개발자 경험의 새로운 기준이자 회사 차원의 핵심 목표로 삼았다. 도구와 프로세스를 정비하고 개발자에게 개선 ownership을 부여한 결과, 개발자 만족도와 배포 빈도, 풀 리퀘스트 처리 속도가 크게 향상됐다. 이 사례는 개발자 만족을 단순한 복지나 감정의 문제가 아니라 장기적인 사업 성과로 측정하고 관리할 수 있음을 보여준다. ## Developer joy의 의미 - 기존의 developer experience가 개발자의 전체 업무 흐름, 프로세스, 제품의 사용성을 다룬다면, developer joy는 개발이라는 직업의 본질과 장인정신, 개발자가 중요하게 여기는 기준과 가치를 강조한다. - 핵심은 개발자가 좋아하는 일에 집중할 수 있도록 불필요한 마찰과 인지 부하를 제거하는 것이다. - Atlassian의 조사에 따르면 개발자는 비효율 때문에 매주 8시간 이상, 전체 업무 시간의 약 20%를 잃고 있었다. - Stack Overflow 조사에서는 개발자의 25%가 문제 해결이나 답을 찾는 데 하루 한 시간 이상을 사용한다고 나타났다. - 개발 외에도 디자인 협업, 부서 간 조율, 기획과 같은 활동에 업무 시간의 20~30%가 소요되며, 이런 마찰이 개발의 즐거움을 떨어뜨렸다. ## 생산성 위기에서 출발한 변화 - 2022년 Atlassian은 공개 로드맵의 대부분을 제때 달성하지 못했고, 개발자 만족도도 50% 미만이었다. - 문제의 원인은 개인의 역량이 아니라 중복되거나 비효율적인 도구와 시스템, 복잡한 프로세스에 있었다. - 정보를 찾고 다른 팀과 조율하는 데 드는 시간이 누적되면서 개발자의 핵심 업무 집중력이 약화됐다. - Atlassian은 단순히 더 빨리 일하도록 압박하는 대신, 업무 환경 자체에서 불필요한 장애물을 제거하는 방향을 택했다. ## Developer joy를 운영 체계로 만들기 - Atlassian은 문제를 조직 전체에서 찾고 해결하기 위해 여러 직군이 참여하는 ‘champions’ 프로그램을 시작했다. - 개선 작업은 크게 시스템과 문화라는 두 영역으로 나뉘었다. - **시스템:** 기존 도구와 프로세스를 점검하고 표준화하거나 불필요한 항목을 제거했다. - **문화:** 코딩 표준, 조직의 가치, 성과 측정 기준을 정해 개발의 품질과 장인정신을 업무 방식에 반영했다. - 여러 팀이 비슷한 도구를 각각 보유한 상태를 Matt Schvimmer는 ‘도구의 노아의 방주’라고 표현했다. - 모든 엔지니어링 팀이 업무 시간의 10%를 개발자 생산성 개선에 사용하도록 했다. - 개발자들이 개선의 대상이 아니라 해결 과정의 주체가 되면서 조직 전체에 ownership이 생겼다. - 이후 developer joy는 전사 OKR로 채택됐고, 각 팀이 매월 관련 성과를 보고하게 됐다. ## 즐거움의 사업적 가치 측정 - developer joy를 회사 차원의 OKR로 삼으려면 단기 매출보다 참여도와 업무 환경 개선을 우선하는 선택이 필요했다. - Atlassian은 이를 장기적으로 복리 효과가 발생하는 투자에 비유했다. - 성과를 감정적 만족도에만 의존하지 않고 정량·정성 지표를 함께 측정했다. - 몇 달 만에 다음과 같은 변화가 나타났다. - 개발자 만족도 50% 증가 - 풀 리퀘스트 처리 사이클의 중앙값 50% 감소 - 배포 빈도 3배 증가 - 고객 로드맵의 모든 항목을 계획대로 전달 - 내부 고객 만족도(CSAT) 50% 미만에서 80%로 상승 - 도구를 개선하고, 프로세스 문제를 해결하며, 측정할 지표를 명확히 한 것이 성과로 이어졌다. ## Team joy로 확장되는 개념 - 개발자 만족도와 생산성 개선이 실제 성과로 확인되면서, Atlassian은 developer joy를 더 넓은 ‘team joy’의 관점으로 확장하려 했다. - 처음에는 ‘joy’라는 표현을 가볍거나 측정하기 어려운 개념으로 받아들이는 사람도 있었지만, 구체적인 지표와 사업 성과가 개념의 신뢰성을 뒷받침했다. - 개발자 개인의 경험을 개선하는 데서 나아가 팀 전체의 협업 방식과 조직 문화를 개선하는 방향으로 논의가 확대됐다. 도입할 때는 먼저 중복 도구와 불필요한 프로세스를 조사하고, 개발자들이 개선 과제에 직접 참여할 수 있는 시간을 보장하는 것이 현실적이다. 이후 만족도뿐 아니라 PR 처리 시간, 배포 빈도, 로드맵 달성률처럼 업무 흐름과 사업 결과를 함께 측정해야 developer joy를 지속 가능한 조직 목표로 만들 수 있다.
원문 읽기(새 탭에서 열림)
