여러 직원이 있지만, 이 중 소프트웨어 개발자를 존중하는 방식에 나름의 특별함이 있다. ‘직원 경험’이라는 개념이 있는 것처럼 ‘개발자 경험’이라는 개념도 있다. 그러나 개발자 경험에 공감하지 못하는 비개발자 직원이 꽤 많다. 사람 중심 문화와 개발자 경험의 방법론과 인사이트를 결합하면 ‘개발 능력자’를 유지할 수 있는 끈끈한 기업 문화를 조성할 수 있다. 개발자가 계속 남고 싶어 하는 회사를 만들기 위한 8가지 기본자세와 방법에 대해 알아본다.
1. 개발자 경험을 진정으로 이해하라
개발자 경험을 진정으로 이해하며 개발자에게 가지는 의미를 아는 리더가 앞서 나갈 수 있다. 가장 기본적인 수준에서 개발자 경험(DX)은 개발자 당사자가 쓰는 툴이나 기업 시스템에 대한 만족도를 말한다. 개발 언어가 프로그래밍을 다루는 방식의 차이 같이 매우 구체적인 사항부터 클라우드 플랫폼의 사용성 같은 전반적인 경험을 모두 포함할 수 있다. 더 나아가 DX는 결국 개발자 라이프스타일을 포괄한다. 개발 문화와 태도를 말한다. 따라서 DX는 개발자, 특히 경력 개발자가 회사에 대해 생각하는 방식에 큰 영향을 끼친다.사람을 먼저 생각하는 일터문화의 핵심은 자율적 책임성이다. 직원들에게 목표를 주고 성과에 대한 책임을 지도록 하는 동시에, 가능한 한 많은 권한을 부여하는 업무 방식이다. 담당자만이 자신이 하는 일이 잘되고 있는지, 문제가 있는지 알 수 있으며, 권한이 있어야 끊임없이, 신속하게 수정할 수 있다는 믿음을 전제로 한다. 이는 이상적인 개발 방식과도 일치한다.
2. DX가 왜 중요한지 공감하라
사실 개발자는 개발자 경험과 자급자족의 관계에 있다. 필요한 도구를 직접 만드는 경우가 많다. 수많은 도구를 공유하는 개발자 커뮤니티에 돌려주려는 마음이 선순환된다.이런 창조의식과 호혜성은 소프트웨어 커뮤니티를 발전시킨다. 공유 메인프레임 초창기부터 개발자들은 자신이 원하는 프로젝트를 만들고자 함께 했다. IT 프로젝트에 대한 개발자의 관심과 이해는 이제 수많은 프로젝트에 자금을 지원하고 모두와 공유하는 핵심 동력이 됐다. 이 과정에서 각 프로젝트가 선사하는 개발자 경험이 결정적인 기준이 된다. 프로젝트의 장기적 성공 여부에도 큰 영향을 끼친다.
퓨전오쓰의 개발자 관계 책임자인 댄 무어는 DX에 대해 다음과 같이 말하면서 유용한 구분법을 제시했다. 그는 "개발자 경험은 내부와 외부 개발자 경험으로 나눌 수 있다. 전자는 내부적으로 개발팀에게 알맞은 프레임워크와 도구를 셀프서비스 툴링과 함께 제공해 일관성 있고 안전하며 빠른 방식으로 구축할 수 있도록 하는 것이다. 후자는 매출을 높이고 조직 외부의 개발자들이 오래 머물 수 있는 플랫폼을 구축하기 위한 것이다”라고 말했다. 이러한 결과를 보장하기 위해 IT 리더는 기업에서 개발자가 된다는 것의 의미를 계속 묻고 개선할 방법을 찾아야 한다.
3. 데브옵스에서 '데브엑스'로 그리고, 또 반대로
데브옵스가 널리 퍼지면서 개발자가 전체 제품 라이프사이클에 참여하고 전체적인 방식으로 그 라이프사이클에 영향을 미칠 수 있게 됐다. 아직 데브옵스를 도입하지 않았다면, 이제부터 시작하라.DX는 데브옵스를 다음 단계로 끌어올린다. 버셀(Vercel)의 CEO이자 설립자인 길레르모 로치는, "기업은 이제 데브옵스에서 데브 익스페리언스로 이동할 것이다. 우수한 개발자 경험은 개발자 생산성 향상과 개발자 속도 향상으로 이어져 눈에 보이는 수익 창출 효과를 낸다. 모든 기업은 '개발자가 애플리케이션 및 제품 레이어에 더 많은 시간을 할애하면서 백엔드 및 인프라 레이어에 최소한의 시간을 할애할 수 있도록 하려면 어떻게 해야 할까?'라고 생각해봐야 한다”라고 말했다.
개발자 관점에서 DX는 개발자에게 더 많은 권한을 부여하는 일이다. 특정 데브옵스 관행과 절차를 따르라고 지시하는 대신 개발자가 직접 자신에게 가장 적합한 프로세스와 기술을 고안할 수 있도록 권한을 줘야 한다. 결국, 프로세스를 자유자재로 맞춤화할 권한을 부여받은 팀은 변화하는 상황에 대응하여 바로 작업에 필요한 툴을 더 잘 설계하고 구축할 수 있다. 달리 말하면, 훌륭한 데브옵스는 훌륭한 DX의 자연스러운 결과이며, 그 반대도 마찬가지이다.
4. DX 전담팀을 꾸려라
개발자가 쓸 도구와 프레임워크를 정하는 의사결정 과정에 당사자인 개발자와 IT 팀원을 포함시키는 일은 유용한 피드백 루프를 만든다. 또한 개발자가 자신의 목소리를 듣고 있다고 느끼도록 하여 프로젝트에 몰두할 가능성을 높인다. 비즈니스 직원과 IT 직원 간의 선순환 구조를 육성하려면 중간 다리 역할을 할 사람이나 팀이 필요하다. 개발자의 경험을 대변하면서 비즈니스 측면에 이해하는 사람을 찾아 권한을 줘야 한다. 구체적으로 특정 직원이나 팀이 DX를 전담하도록 해야 한다. 기업 규모나 상황에 따라 한 개인일 수도 있고 팀일 수도 있다.5. 개발자에게 코드 완성도를 타협하라고 강요하지 말아라
개발자는 사용자뿐만 아니라 다른 개발자를 위한 소프트웨어를 만들기도 한다. 개발용 소프트웨어가 그렇다. 사용자에게는 편의성이 가장 중요하다. 그러나 개발자에게는 겉으로 보이지 않는, 코드적, 기술적 완성도가 기타 개발자용 기능이 중요할 수 있다. 이는 기업 전체에 영향을 미칠 수 있는, 사소하지 않은 사항이다. 코드의 품질은 DX의 한 측면이기도 하다.여기서 비즈니스 연관성은 두 가지다. 첫째, 좋은 DX를 가진 시스템은 유지 및 확장이 더 쉬우며, 소프트웨어 품질에 프로젝트의 성패가 갈릴 수 있다. 둘째로, DX가 뛰어나면 개발자들, 특히 상급 개발자들은 프로젝트 작업에 더 만족한다. 코드 품질이 비즈니스와는 관계없이 그저 개발자들이 부리는 욕심이라는 견해가 틀린 이유이며, 개발자를 닦달하면 안 되는 이유다.
6. 학습, 교육, 공유 기회를 제공하라
학습, 교육 및 공유는 개발자에게 주요한 인센티브다. 개발자가 더 많이 성취하고, 열정적으로 일할 뿐만 아니라 동료와 협력하는 자세를 갖추도록 하는 데 중요하다. 모든 개발자가 좋은 개발자 경험을 조상하는 데 참여하고, 다른 사람이 DX의 가치를 알 수 있도록 서로 서로 상기시켜주는 문화를 조성하는 것이 목적이다. 오픈소스 프로젝트 기여한 코드를 회사 제품에 포함시키는 개발자가 좋은 모범 사례다. 실제로 많은 기업이 제품에 오픈소스 구성요소를 쓴다. 이는 개발자가 자기 창작물을 전사적으로 드러낼 수 있는 창구가 된다.7. DX를 망치는 불필요한 행정을 줄여라
기업은 항상 소프트웨어 개발팀의 속사정을 알고 싶어 한다. 측정 기준과 가시성을 확보하려 한다. 그러나 개발자 워크플로우에 너무 많이 참견하는 것은 DX를 망치는 지름길이다. 불필요한 회의와 보고를 최소화하고, 무엇이 가장 효율적으로 작동하는지에 집중하는 것이 낫다. 개발자는 리더십이 이를 전략적으로 고민하고 있다는 느낌만 받아도 크게 감명받을 것이다. 능력 있는 소프트웨어 개발자일수록 자신이 가장 잘하는 일, 즉 소프트웨어 구축에 집중할 수 있는 환경에서 진가를 발휘하며 대부분 시간을 가치 있다고 느끼는 활동에 할애하고 싶어 한다.8. 배포 과정을 자동화하라
최근 연구에 따르면 개발자 열 명 중 일곱은 배포에 대한 스트레스 때문에 프로젝트를 그만둔다고 한다. 소프트웨어를 구축하는 데 필요한 세세한 활동 하나하나에 부담이 크고, 모든 것이 완벽하게 개발되고 출시되어야 한다는 압박감에 시달리기 때문이다. 최선의 노력을 다하고 있음에도 불구하고, 언제나 충분하지 않다는 느낌이 있다.이 문제를 해결하는 가장 좋은 방법은 신뢰할 수 있는 자동화 시스템을 구축하는 것이다. 지속적인 통합 및 전달, 자동화된 테스트 등이 오늘날 개발 프로세스의 표준이 되고 있지만, 이는 단지 일부에 불과하다. 개발자가 도움을 받을 수 있는 곳이 있어야 한다. 어려움과 불확실성이 있는 시기에 개발자가 어떻게 대우받는다고 느끼는가에 따라 DX가 크게 달라진다.
ciokr@idg.co.kr