[초안] Dependabot 도입기

[sounmind]

Dependabot 도입기: DaleUI 사례로 보는 의존성 관리 자동화

Dependabot이란?

Dependabot은 GitHub에서 제공하는 자동화된 도구로, 프로젝트의 패키지 및 의존성을 지속적으로 모니터링하고 업데이트합니다. 특히 오래된 버전이나 보안 취약점을 가진 패키지를 자동으로 감지하여 풀 리퀘스트(PR)를 생성하므로, 개발자의 시간과 노력을 절약하고 프로젝트의 보안성과 안정성을 향상시킵니다.

초기 설정 시도와 깨달음

처음 DaleUI에서 Dependabot을 도입할 때 저는 모든 설정을 한 번에 완벽하게 넣으려는 욕심이 있었습니다. 초기 설정 초안은 다음과 같이 상세하고 구체적이었습니다.

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"

  - package-ecosystem: "github-actions"
    directory: "/.github/workflows"
    schedule:
      interval: "daily"

하지만 프로젝트 멤버 중 한 명인 달레님의 피드백이 제게 새로운 관점을 제공했습니다.

"기본값을 써보고 나중에 필요할 때 설정해도 늦지 않을까요? Convention over configuration! 😉"

이 의견을 통해 저는 다음 두 접근법을 생각하게 되었습니다.

1. 모든 것을 처음부터 세부적으로 설정
2. 최소한의 설정에서 시작해 점진적으로 확장

점진적인 변화의 과정

저희 팀은 결국 두 번째 방식을 선택했고, 그 결정에 따라 Dependabot 설정이 다음과 같은 과정을 통해 진화했습니다.

• Chromatic 충돌 문제 해결
  • Dependabot의 자동 PR이 Chromatic과 충돌하여 이를 수정했습니다.
• bun.lock 파일 업데이트 문제 해결
  • bun을 사용하는 프로젝트에서 bun.lock 파일의 자동 업데이트 문제를 해결했습니다.
• 패키지 그룹핑
  • 관련 패키지를 그룹화해 Dependabot이 생성하는 PR의 수를 줄이고 관리가 쉬워지도록 했습니다.
• 업데이트 주기 조정
  • 프로젝트 상황에 맞추어 업데이트 주기를 조정했습니다.

이러한 변경 과정에서 생성된 PR의 예시 이미지를 첨부하여, 구체적인 이해를 돕습니다.

최소 설정의 장점과 단점

DaleUI 프로젝트에서 최소한의 설정으로 시작한 덕분에 팀원들은 직접 문제에 부딪히면서 해결책을 찾는 과정을 통해 의존성 관리에 대한 이해도를 높일 수 있었습니다. 이는 특히 경험이 부족한 팀원들에게 큰 학습 기회였습니다.

하지만 처음부터 더 구체적이고 철저한 설정을 했다면 중요한 업무에 시간을 더 많이 할애할 수도 있었겠다는 생각도 듭니다. 다만 당시에는 프로젝트 초기였고 개발자들의 여유가 있었기 때문에 점진적 방식이 적합했습니다.

결론: 상황에 맞는 전략적 선택

결국 의존성 관리 전략에 절대적으로 옳거나 틀린 방식은 없습니다. 각 프로젝트의 상황과 구성원의 경험에 따라 적절한 방식을 선택하는 것이 중요합니다.

마무리하며

Dependabot과 같은 자동화 도구는 프로젝트 관리의 효율성을 크게 높여줍니다. DaleUI에서의 경험을 바탕으로 여러분의 프로젝트에 가장 적합한 설정 전략을 고민해보길 권장합니다.

---

참고자료:

• Dependabot 공식 문서

[hyoseong1994]

글 잘 읽었습니다.

1. 저는, 저희팀은 이런 단어는 빼면 좋을 것 같습니다. 블로그 글 자체가 팀 github에 올라가는거며 작성자 또한 에반님으로 명시 되어있는 특정된 글에서 저는 혹은 저희팀이라는 단어는 읽는 독자에게 불필요한 단어로 느껴질수있으며 이는 글을 읽을때 피로감을 줍니다. 많이 안들어가서 피로감을 느낄정도는 아니긴 했습니다.
2. 문제 해결 과정이 너무 간결합니다. 좀 더 내용을 붙여서 작성하면 좋을 것 같습니다.
   크로매틱 충돌은 어떻게 발견했으며 스크린샷이 있다면 로그 스크린샷을 첨부해서 어떤 오류가 발생했는지도 적으면 좋을것 같습니다.

[yolophg]

잘 읽었습니다, 몇 가지 생각나는 코멘트 남겨봐요! 초안에 도움이 되면 좋겠습니다 :)

• 도입 배경이 살짝 아쉬웠어요. 어떤 계기나 필요 때문에 Dependabot을 도입하게 됐는지, 간단하게라도 서두에 짚어주면 글의 흐름이 더 자연스럽게 이어질 수 있지 않을까 하는 생각이 들었어요.
• 도입 과정에서 어떤 고민이 있었고, 실제로 어떤 시행착오를 겪었는지에 대한 묘사가 조금만 더 들어가면 좋을 것 같아요. 예를 들어 설정을 시도해봤는데 어떤 부분이 예상과 달랐는지 등, 그런 서사들이 글에 밀도를 더해줄 수 있을 것 같아요!
• 변화 과정을 잘 정리해주셨는데, 각 항목이 조금 더 맥락이 붙으면 좋을 것 같아요. 예를 들어 "Chromatic 충돌 문제 해결"이면 구체적으로 어떤 충돌이었고 어떻게 대응했는지 간단히라도 덧붙여주시면, 읽는 입장에서 더 생생하게 와닿을 것 같아요.

[RiaOh]

에반님! 초안 잘 읽었습니다!

제 개인적인 의견 남기겠습니다!

• 저도 @yolophg 님과 도입부분에 대해서 같은 생각입니다. Dependabot의 도입배경이 간단하게 언급되면 좋을 것 같아요.
• Dependabot이 무엇인지 간단하게 언급되어서 좋았습니다 :)

이 의견을 통해 저는 다음 두 접근법을 생각하게 되었습니다.

1. 모든 것을 처음부터 세부적으로 설정
2. 최소한의 설정에서 시작해 점진적으로 확장

• => 그리고, 여기서 두번째 방식으로 선택하셨다고 하셨는데, 이 방식을 선택하게 된 이유가 궁금했습니다. 아니면 그 이유를 아래 내용으로 언급하신걸까용?

다만 당시에는 프로젝트 초기였고 개발자들의 여유가 있었기 때문에 점진적 방식이 적합했습니다.

• 이건 제 개인취향(?)이고, 지극히 사소한 부분이긴한데 '최소한의 설정에서 시작해 점진적으로 확장' 이렇게 언급이 먼저 되었으면 이 접근법에 대해서 용어가 통일?되면 좋을 것 같다는 생각입니다! 여기서는 '점진적으로 확장' 이지만 다음 줄에서는 '점진적인 변화의 과정'이렇게 다른 단어가 사용되었는데 똑같이 '점진적인 확장의 과정' 이렇게 되면 해당 접근법에 대한 이야기구나, 라고 직관적으로 알 수 있지 않을까?하는 개인적인 의견입니다 ㅎㅎ

• 글을 읽고 나서 이 블로그 글의 핵심주제가 'Dependabot'에 대한건지, 'Dependabot의 설정전략'에 대한건지 약간 헷갈립니다.

수고많으셨습니다 :)