https://leerob.io/blog/developer-experience-examples
https://leerob.io/blog/dx
- Lee Robinson

개발의 세계에서 기술들은 빠르게 발전하고 있어 개발자들이 알아야 할 것도 많아지고 있습니다.

우리가 더 나은 사용자 경험을 위해 제품과 서비스에 적용할 수 많은 기술들이 그렇습니다.

그렇다면 우리는 더 나은 사용자 경험을 만들기 위해 이 세계 에서 어떤 경험을 통해 좋은 결과를 이루어 낼 수 있을까요?

다시 말해 어떤 개발자 경험이 더 나은 결과물을 만들어 낼까요?

Vercel의 DevRel를 리딩하는 Lee Robinson이 개발자 경험에 관한 짧은 블로그 글을 썼습니다.

이 글을 통해서

• 좋은 팀, 회사에서 어떤 개발자 경험을 지향하는지?
• 추상적으로 느꼈던 좋은 개발자 경험이 무엇인지?
• 내가 만든다면? 내가 사용한다면? 관점에서 개발자 경험이라고 하면 무엇이 있는지?

라는 궁금증과 호기심에 이렇게 글을 옮겨봅니다.

들어가면서

개발자는 생산성을 원하지만 복잡한 개발 툴 때문에 오히려 더 낮은 결과를 낼 때가 있습니다.

여러분들도 개발하면서 느끼시겠지만 툴에는 끌어당기는 힘이 존재합니다. 설명할 수 없는, 눈에 보이지 않는, 특별한 끌어당김이 있습니다.

바로 이 힘이 바로 개발자 경험(DX)입니다.

개발자 경험(DX)는 자기력(magentic force)과 같아서 밀어내거나 끌어당깁니다. 훌륭한 개발자 경험을 가진 제품은 개발자에게 매우 중요합니다.

좋은 개발자 경험을 만드는 것은 무엇일까요?

개발자 경험은 소프트웨어 아키텍처의 일부입니다.

• 프레임워크 및 라이브러리
• 문서화
• APIs

프레임워크 및 라이브러리

• 가능한 빠르게 Onboard: 신박한 아이디어를 최대한 빠르게 시작할 수 있게 하는 것. 프레임워크와 라이브러리가 이 일을 빠르게 시작할 수 있도록 최적화 하는것. 예를 들어, npx create-next-app 또는 brew install bat. 개발자에게 빠른 반복, 빠른 피드백 루프를 위해 최적화하세요.
• 간편한 업그레이드: 메이저 버전을 변경할 때 변경 사항의 "폭발 반경"을 제한하여 사람들이 종속성을 쉽게 업데이트 할 수 있도록 합니다. 이상적으로는 변경 사항이 메이저 버전에 도달하기 몇 개월 전부터 동의를 구하기 시작해야합니다. 그런 다음 메이저 버전에는 codemods(코드를 마이그레이션 하고 주요 변경사항을 수정하는 스크립트)를 포함해야합니다.
• 유용한 에러 메시지: 오류 메시지에 하이퍼링크를 포함하여 에러를 해결할 수 있는 방법을 제공합니다. 툴을 입력할 때 피드백을 제공해야 합니다. 런타임 오류 또는 컴파일 오류 전에 빠를 수록 더 좋습니다.(ex: type check, lint). Don't make me think
• 강력한 defaults와 컨벤션: 소프트웨어를 만드는데 "올바른 방법"에 대한 의견이 있습니다. 예를 들어 라우팅 설정에 대해 생각하지 말고 Next.js의 파일 시스템 기반 라우팅을 사용하세요. 컴파일과 번들링을 구성하게 하지 말고 webpack/swc/vite/esbuild를 사용하여 적절한 default 구성을 설정하세요.
• 탈출 구멍을 제공: 강력한 defaults에 대한 반대로 default 구성에 벗어날 경우 탈출 구멍이 있는지 확인하는 것입니다. Next.js가 처음에 성공한 이유 중 하나는 프레임워크를 벗어나지 않고 웹팩을 쉽게 재정의할 수 있었기 때문입니다. 반면 CRA는 eject하거나 craco 같은 것이 있어야만 웹팩을 재정의할 수 있습니다.
• 디펜던시에 대한 위험을 감소하세요: npm i next를 하면 오직 13개 디펜던시만 설치됩니다. 나머지 디펜던시는 Next.js에 인라인됩니다. 미래에는 Next.js를 설치할 수 있는 single binary로 되길 기대합니다.

문서화(Documentation)

• 코드로 안내: 개발자는 코드를 작성하기를 원합니다. 시작을 위해 코드 예제를 주세요.
• 문제를 해결(aka: 질문에 답변): 개발자는 질문에 대한 답변, 챌린지, 해결하고자 하는 문제를 배우기 위해 문서를 찾습니다. 다양한 방법(비디오, 텍스트, 튜토리얼, 가이드, 등등)을 통해서 답변을 제공하세요. 그래서 자신에게 적합한 방식으로 솔루션을 학습하도록 안내합니다.
• 자동화된 문서화: API를 문서화할 때 문서가 동기화 상태를 유지하도록 소스를 원천으로 문서를 생성하는게 좋습니다. 예를 들어 Vercel의 API 문서는 API의 OpenAPI spec에서 자동으로 생성됩니다.
• happy path뿐만 아니라: 문서는 작업을 완료하려는 개발자를 위한 참조가이드입니다. 그래서 오류에 대한 검색을 하고 복사/붙여넣기 할 수 있는 솔루션을 찾는 것을 의미합니다. 해결 방법과 해킹을 문서화 하는 것도 중요합니다. 오히려 제품의 차이를 인정하고 개발자를 좌절시키지 않고 unblock하고 싶습니다.
• 훑어보기에 최적화: 진실을 말해보자면. 우리 모두는 훑어봅니다. 특히 개발자 문서를 읽을 때 말이죠. 문제에 대한 솔루션을 찾으려고 코드 블록을 뛰어다닙니다. 최고의 DX를 제공하려면 코드 스니펫에 유용한 코드 주석을 추가하고, 원하는 기능/API의 여러 옵션 또는 순서를 보이도록 하세요.
• 정확하게: 전문용어와 관용구를 피하세요. 줄임말을 사용하는 경우 독자가 그것이 무엇인지 알고 있다고 가정하지 마세요. 문서는 초보자와 전문가 모두가 접근할 수 있어야 합니다. Happy Path는 아니지만 접고 펼침이 가능한 "deep dive" 영역을 두어 전문가에게 도움이 되도록 하세요.
• 복잡함은 점진적으로 드러내세요: 처음 경험을 선명하게 하면서 개발자가 제품을 계속 사용하면서 복잡한 기능에 대해 점진적으로 알립니다. 개발자가 처음부터 플랫폼 전체에 대해 배우기를 기대하는 것은 현실적이지 않습니다.

개발자 경험의 4가지 인터페이스: API, CLI, GUI 그리고 문서.
각각을 제품으로 다루고 해당 제품이 개발자를 고객으로 상대할 수 있도록 하세요.

APIs

• API 워크플로우를 깨지 마세요: API 버전 관리는 매우 명시적이어야 합니다. 개발자들에게 새로운 버전으로 업데이트를 위한 충분한 시간을 주세요. 개인적으로 Stripe API 버저닝이 좋았습니다. AWS에서는 수년간 안정적이었던 API에 대한 사용 중단 이메일을 보내고 몇 년의 업그레이드 시간을 제공하는 경우를 본 적이 있습니다.
• API를 빠르게 사용해 볼 수 있게 하세요: 좋아하는 API 문서들 중 몇몇은 API key를 생성하고 몇 초안에 endpoint를 시험해볼 수 있습니다. 일부는 이미 로그인되어 있다는 것을 인식하고 계정 정보를 기반으로 페이지를 개인화합니다. Square가 아주 좋은 예입니다. 또한 전체 graph 스키마를 볼 수 있고 request를 만들고 mutation을 수행하고 코드를 format하고 등등을 제공하는 GraphiQL도 좋은 예입니다.

API는 설계가 필요합니다.

• 의식적인 언어와 일관된 컨벤션
• Standard auth
• 페이징처리
• 잘 만들어진 에러 코드와 메시지
• 버전 관리

Investing in DX (Vercel)

DX는 고객에게만 중요한 것이 아니라 제품 주도 성장(product-let growth)에도 중요합니다. Vercel의 제품 및 도구의 세계적 수준의 개발자 경험을 제공함으로써 다음과 같은 엄청난 성장을 이루었습니다.

• 미래는 Edge: 개발자가 몇 초만에 글로벌 애플리케이션을 git push하고, 수 초안에 글로벌 애플리케이션을 받아볼 있도록 함으로써 Vercel은 이제 매 주 250억 건이상의 요청을 Edge에서 처리하고 있습니다. 그리고 그 수는 꾸준히 성장하고 있습니다. Edge Function에서 서버렌더링 SveltKit과 같은 새로운 Edge 컴퓨팅 도구는 이를 더욱 발전 시킵니다.
• 프론트엔드 개발자의 역량 강화: Next.js Discord 커뮤니티의 40,000명 정도의 개발자, 40명의 JavaScript 개발자로 구성된 하이퍼 로컬 그룹, 다음 세대의 개발자를 교육하고 활성화하는데 도움을 주고 있습니다.
• 프레임워크는 개발자를 가능하게 합니다: 서버에서 렌더링된 React 애플리케이션을 만드는 프로세스를 단순화하기 위해 Next.js를 만들었습니다. 프레임워크 개발자 경험에 투자하고 개발자가 최적화된 React 사이트를 신속하게 구축할 수 있도록 함으로써 Next.js는 주간 다운로드 수 270만 이상을 달성했습니다.(그리고 Node.js / Kubernetes 보다 더 많은 Github star 도 달성했습니다.)

DX at Vercel

Vercel에서는 개발자 경험을 위해서 어떤 것을?

훌륭한 개발자 경험을 위해서는 소프트웨어를 만드는데 일상적인 문제에 대한 공감이 필요합니다.

Vercel에서 개발자 경험은 Developer Relations (커뮤니티를 만들고 제품을 홍보하는데 중점) 과 문서의 superset (상위집합체) 입니다.

Vercel DX부서에는 4개의 기둥이 있습니다.

• 교육: 모든 수준의 개발자가 웹을 만들고 기술을 마스터할 수 있도록 합니다.
• 문서: 제품 사용에 대한 명확한 레퍼런스를 제공하고 개발자가 원하는 작업을 완료할 수 있도록 합니다.
• 커뮤니티: 미팅, 컨퍼런스, 커뮤니티를 통해 함께 만들고 배울 수 있는 프론트엔드 개발자 커뮤니티를 육성합니다.
• 템플릿: 성능, 접근성, 디자인에 중점을 두면서 보다 쉽게 구축을 시작할 수 있도록 합니다.

엔지니어링 조직에는 내부 개발자 경험(또는 개발자 생산성) 팀이 있을 수도 있습니다.
테스트를 보다 안정적으로 만들고, 공유된 도구들을 만들고, 빌드 성능을 향상시키고 팀이 코드를 더 빠르게 배포할 수 있도록 돕습니다.

훌륭한 개발자 경험을 구축하는데 도움이 되는 4가지 운영 원칙이 있습니다.

• 노출되는 시간을 늘이기: 개발자와 접촉하는 시간을 늘려서 우리 제품에 어떤 어려움을 겪는지 직접 이해합니다. 우리는 개발자들과 이야기하고 동영상을 보거나 기사를 읽고 실시간 스트리밍에 참여하기도 합니다.
• 만들면서 배우기: 새로운 기능에 대한 알파 테스터가 되어야 합니다. 이는 교육 콘텐츠를 만들 때 도움이 될 뿐만 아니라 제품 피드백과 개선에도 좋은 영향을 줍니다.
• 공감대 형성이 첫번째: 모든 개발자가 양질의 소프트웨어를 빌드할 수 있도록 하려면 일상적인 문제를 이해해야 합니다. 초보자와 전문가 모두에게 공감하는 것이 중요합니다.
• Hell yeah 또는 아니오: 느낌이 좋지 않다면 "hell yeal!" 라고 말하지말고 no라고 말하세요. 이를 우리의 가치와 일치하는 가장 중요한 작업에 집중하는데 도움이 됩니다.

마무리하며

Let's make the Web, faster

Lee Robinson은 개발자 경험에 대한 좋은 영향력을 가진 인물로서 그의 글과 영상은 많은 사람들에게 도움이 됩니다. Vercel 제품, 특히 Next.js를 사용하면서 개발자 경험이 좋다고 느끼지만 그 이유를 명확하게 설명하기 어려웠을지도 모릅니다. 이 글을 통해 개발자 경험에 대한 명확한 이해를 할 수 있게 되었습니다.

개발자 경험은 어려운 주제지만, 이 글을 통해 팀 내에서도 개발자 경험을 향상시키기 위한 관점을 생각해볼 수 있게 되었습니다. 결국, 좋은 개발자 경험은 제품뿐만 아니라 팀 내에서도 중요한 역할을 하며, 이를 통해 개발 과정에서의 만족도와 생산성을 높일 수 있습니다.

굳이 제품이 아닌 작게는 팀 내에서도 개발자 경험을 위해 어떤 관점에서 접근해야될지, 그런 부분도 생각하게 되는 글인 것 같습니다.

reference

• https://leerob.io/blog/dx
• https://leerob.io/blog/developer-experience-examples