좋은 개발자 경험

좋은 글이 있어 공유합니다.
원문은 여기서 확인할 수 있습니다.

한 줄 요약

개발자를 행복하게 만들고 행복을 유지하는 것을 잊지 마세요.

좋은 개발자 경험(Developer Experience, DX)이란 무엇인가

개발자 경험은 개발자가 제품을 사용하거나 개발하는 동안의 경험을 말합니다.
하지만 많은 회사에서는 UX(User Experience)보다 우선순위에 밀려나 있습니다. 개발자도 유저이고, 제품을 사용합니다.
그들의 만족과 행복은 프로젝트의 성공에 매우 중요합니다. 행복한 개발자는 뛰어난 소프트웨어를 만들고 팀을 떠날 가능성을 줄여줍니다.
우리는 아래 4가지 요소로 좋은 개발자 경험을 정의합니다.

1. 적절한 아키텍쳐
   아키텍쳐가 단순하면 나중에 고통받고, 복잡하면 지금 고통스럽습니다.
   프로젝트와 팀 규모를 고려하여 아키텍쳐를 선정해야 합니다. 좋은 아키텍쳐는 깨지기 어렵고, 짧은 피드백 주기를 가진데다가 내성이 좋습니다.
2. 좋은 툴
   가능한 부분은 자동화를 권장합니다. 반복적인 작업은 피곤합니다.
3. 개발 이후를 보완해주는 프로세스
   이 프로세스는 자동화된 체크 리스트로 작동해야하며 일관된 단계를 제공합니다. 정의된 프로세스는 팀 훈련에 도움이 됩니다.
   충분히 큰 회사라면 QA, 배포, 피드백, 온보딩 등의 프로세스를 사용하세요.
4. 해롭지 않은 팀 문화
   회사의 목적을 정의하세요. 돈을 버는 것이 유일한 목표가 되어서는 안됩니다.
   문화는 당신이 회사와 팀에 설치할 수 있는 가장 중요한 브레인웨어(머리에서 실행되는 소프트웨어)입니다.
   개발자가 내리는 모든 결정은 설치된 브레인웨어를 통해 걸러집니다.
   그들이 브레인웨어에 동의하지 않으면 무시합니다.

놀랍게도(저 혼자 놀람) 전 개발자 경험이라는 단어를 이렇게 접하기 전에 먼저 사용하고 있었습니다. 왜 UX만 있고 DX는 없냐고 항상 말하고 다녔고, 제가 생각한 DX는 위 내용 뿐만 아니라 FE, BE간에 API를 제공할 때, BE 팀 내에서 라이브러리를 제공할 때도 충분히 전달할 수 있는 개념이라고 여겼었습니다. 그리고 현재 회사의 임원면접을 볼 때도 "DX를 중시한다"는 말로 큰 호응을 이끌어냈던 경험이 있습니다.

좋은 개발자 경험이 필요한 이유

좋은 개발자 경험을 가진 팀은 생산성이 높으며 다음과 같은 특성을 나타냅니다:

1. 영향력에 대한 감각
   그들은 그저 돈을 버는 것만이 아님을 이해합니다. 자신의 일이 중요하고 다른 사람의 삶을 개선한다는 것을 알고 있습니다.
2. 주인의식 및 책임감
   그들은 성공에 대한 책임이 있습니다. 모든 팀 멤버는 회사의 성공에 대한 책임감을 느껴야 합니다.
3. 공통 목표
   팀 부서 및 회사 전체가 공통적인 목표를 가집니다.
4. 친절과 정직
   우리는 이것을 'hey bro' 문화라고 부릅니다. 우리는 큰 존경심을 가지고 성실을 강조합니다
5. 실패의 허용
   개발자는 용감해야 하고 위험을 감수해야 합니다. 그러나 리스크는 언제나 계산되어야 하며, 개발자는 모든 작업이 얼마나 많은 문제를 일으킬 수 있는지 알고 있어야 합니다.

나쁜 개발자 경험을 가진 문화의 특성:

1. 손가락질
   팀 멤버는 서로 잘못된 작업에 대해 비난합니다. 이것은 매우 해로운 일이지만 자주 발생합니다.
2. 실패에 대한 큰 처벌
   예를 들면, 마감 기한을 지키지 않으면 해고될 수 있다고 말하는 상사라던가..
3. 변하지 않는 크런치 타임 및 팀의 지속적인 과부하
4. 적대감과 불확실성
   팀 간의 불건전한 경쟁. (예를 들면, 이 사람이 나보다 잘해서 승진함)
5. 희석된 책임감
   대기업에서는 아무도 책임지지 않는 것처럼 느껴질 수 있습니다. '미안해, 내가 망쳤어'라고 말하려면 용기가 필요합니다. 책임을 질 수 있는 것이 중요합니다.

좋은 개발자 경험이 해결할 수 있는 문제들

• 지식 축적
• 잘못된 제품-시장 적합성
• 의욕없는 팀
• '내 문제가 아니야' 사고방식
• 실패한 제품
• 불행한 클라이언트
• 비즈니스와 IT의 연결 단절
• 해로운 팀 문화
• 불량한 코드 품질
• 비용 증가
• 무의미한 일

좋은 개발자 경험을 구현하는 방법

1980년대 중반에 Dr. Martin Barnes가 만든 'Scope Triangle'이 있습니다. 이것은 세 가지 기본적인 힘 사이의 관계를 보여줍니다.

시간, 돈, 품질

이 삼각형은 품질을 늘리려면 돈이나 시간을 조절해야 함을 의미합니다. (역자:이해가 쉽도록 원문을 살짝 변경) 다만 우리는 그것이 현실에서 작동하는 방식이 아니라고 생각합니다. 저 삼각형에 정서적 비용을 추가해야 합니다.

개발자가 작업을 완료하기 위해 늦게까지 머물러야 하는 경우 투자해야 하는 것은 시간뿐만이 아닙니다. 이 투자의 또 다른 부분은 정서적 비용입니다. 훌륭한 개발자 경험을 갖는 것은 이러한 정서적 비용을 통제하는 데 도움이 됩니다. 개발자를 행복하게 하려면 정서적 비용을 낮게 유지하세요.

좋은 개발자 경험의 일반적인 함정

1. 너무 빠른 타이밍에 개발자에게 지나치게 많은 정보를 제공합니다.
2. 더 많은 정보가 필요할 때 개발자에게 너무 적은 정보를 제공합니다.
3. 프로세스를 과도하게 사용하면 '모든 것이 적합하다'는 사고방식이 나타날 수 있습니다.
4. 과잉 엔지니어링 경향
5. 애자일 = 개발자들에게 더 많은 일을 시킬 핑계