πŸ“μ§€μ†μ  톡합

λ°•ν˜•μ„Β·2022λ…„ 3μ›” 24일
0
post-thumbnail

πŸ“Œμ§€μ†μ  톡합

지속적 ν†΅ν•©μ΄λž€ μžλ™ν™”λœ λΉŒλ“œ 및 ν…ŒμŠ€νŠΈκ°€ μˆ˜ν–‰λœ ν›„, κ°œλ°œμžκ°€ μ½”λ“œ λ³€κ²½ 사항을 쀑앙 리포지토리에 μ •κΈ°μ μœΌλ‘œ λ³‘ν•©ν•˜λŠ” 데브옡슀 μ†Œν”„νŠΈμ›¨μ–΄ 개발 방식이닀

πŸ“Œμ§€μ†μ  톡합이 ν•„μš”ν•œ 이유

κ³Όκ±°μ—λŠ” 개발과 운영이 격리된 μƒνƒœμ—μ„œ μž‘μ—…μ΄ μ§„ν–‰λ˜κ³  μž‘μ—…μ΄ μ™„λ£Œλœ 후에 λ§ˆμŠ€ν„° λΈŒλžœμΉ˜μ— λ³‘ν•©ν–ˆλ‹€.

이둜 인해 λ³‘ν•©μ½”λ“œκ°€ μ–΄λ ΅κ³  μ‹œκ°„ μ†Œλͺ¨μ μœΌλ‘œ λ³€ν•˜κ²Œ λ˜μ—ˆκ³  μˆ˜μ •μ—†μ΄ μ˜€λž¬λ™μ•ˆ 버그가 μΆ•μ²™λ˜λŠ” κ²°κ³Όκ°€ λ‚˜νƒ€λ‚˜κ²Œ λ˜μ—ˆλ‹€κ³  ν•œλ‹€.

과거의 개발 방식

ꡬ쑰적 방법둠(Waterfall model)

μš°λ¦¬λŠ” 폭포수 λ°©λ²•λ‘ μ΄λž€ 단어λ₯Ό λ“€μ–΄ λ³Έ 적이 μžˆμ„κ²ƒμ΄λ‹€. μ½”λ“œλ₯Ό μ œν•œλœ κ΅¬μ‘°μ—μ„œ μƒμ„±ν•˜μ—¬ 순차적으둜 μ‹€ν–‰μ‹œν‚€λŠ” 것이 νŠΉμ§•μ΄λ‹€.

μœ„μ—μ„œ μ•„λž˜λ‘œ 폭포가 λ–¨μ–΄μ§€λŠ” 것 처럼 순차적으둜 μ§„ν–‰λ˜λ©° μ™„λ£Œλœ 단계 μ΄μ „μœΌλ‘œλŠ” λ‹€μ‹œ 되돌리기 μ–΄λ €μš΄ νŠΉμ„±μ„ 가진 과거의 개발 방법둠이닀.
크게
μš”κ΅¬μ‚¬ν•­λΆ„μ„->섀계->κ΅¬ν˜„->ν…ŒμŠ€νŠΈ->μœ μ§€λ³΄μˆ˜ 으둜 λ‚˜λˆŒ 수 μžˆλ‹€.

νŠΉμ§•μ€ μ• μžμΌ 방법둠과 같이 ν‘œλ‘œ μ„€λͺ… ν•˜κ² λ‹€.

μ• μžμΌ 방법둠(Agile model)

μ• μžμΌμ€ μ‹ μ†ν•œ 반볡 μž‘μ—…μ„ 톡해 μ‹€μ œ μž‘λ™κ°€λŠ₯ν•œ μ†Œν”„νŠΈμ›¨μ–΄λ₯Ό κ°œλ°œν•˜μ—¬ μ§€μ†μ μœΌλ‘œ μ œκ³΅ν•˜κΈ° μœ„ν•œ μ†Œν”„νŠΈμ›¨μ–΄ 개발 방식이닀

μ§€λ‚˜μΉ˜κ²Œ κ³„νšκ³Ό μ ˆμ°¨μ— μ˜μ‘΄ν•˜λŠ” μ›Œν„°ν΄ λ°©λ²•λ‘ μ˜ λ¬Έμ œμ μ—μ„œ μ• μžμΌ 방법둠이 λŒ€λ‘ λ˜μ—ˆλ‹€.

μ• μžμΌ 방법둠은 고객과의 ν˜‘λ ₯을 μ€‘μ‹œν•˜κ³  ν”„λ‘œμ„ΈμŠ€λ‚˜ 도ꡬ에 μΉ˜μš°μΉ˜μ§€ μ•ŠλŠ” 자기 적응적 방식을 μ μš©ν–ˆλ‹€. μΌμ •ν•œ μ£ΌκΈ°λ₯Ό 가지고 νŠΈλ‘œν†  νƒ€μž…μ„ λ§Œλ“€μ–΄ λ‚΄κΈ° λ•Œλ¬Έμ— 고객이 μ›ν•˜λŠ” 사항을 λ°˜μ˜ν•˜κΈ°λ„ 쉽고 지속적인 변화에도 λΉ λ₯΄κ²Œ λŒ€μ²˜ν•  수 μžˆλ‹€.

AgileWater fall
μž₯μ κ°œλ°œκ³Όμ •μ΄ λΉ λ₯΄κ³  μœ μ—°νŒ€ 규λͺ¨μ— 상관없이 λ”°λ₯΄κΈ° 쉬움
짧고 반볡적인 μŠ€ν”„λ¦°νŠΈλ‘œ ꡬ성(λΉ λ₯΄κ²Œ 결함 식별 및 μˆ˜μ •κ°€λŠ₯κ°œλ°œμ£ΌκΈ°κ°€ μ •ν•΄μ Έ 있기 λ•Œλ¬Έμ— μƒˆλ‘œμš΄ ν”„λ‘œμ νŠΈλ₯Ό μ•ˆμ •μ μœΌλ‘œ μ‹œμž‘ κ°€λŠ₯
μ†Œκ·œλͺ¨ νŒ€λ“€μ΄ μ—¬λŸ¬κ³Όμ œλ₯Ό 각각 ν• λ‹Ήλ°›μ•„ μ²˜λ¦¬κ°€λŠ₯μš”κ΅¬μ‚¬ν•­μ΄ μ •μ˜λ˜μ–΄ 있기 λ•Œλ¬Έμ— μ‹€ν–‰ν•˜κΈ°κ°€ μˆ˜μ›”ν•˜λ©° λͺ©ν‘œλ₯Ό 자주 λ³€κ²½ν•˜μ§€ μ•Šμ•„λ„ 됨
개발 과정쀑에 μ‹ μ†ν•˜κ²Œ μ œν’ˆ λ³€κ²½ κ°€λŠ₯ν•„μš”ν•œ λ‘€μ‚°κ³Ό μžμ›μ΄ μ΄ˆκΈ°μ— ν™•μ •λ˜κΈ° λ•Œλ¬Έμ— μ˜ˆμƒκ²°κ³Όμ™€ 리슀크λ₯Ό ν†΅μ œν•˜κΈ° 쉬움
단점빠λ₯Έ 반볡 μž‘μ—…μ— μ΅μˆ™ν•œ μˆ™λ ¨λœ μ‚¬λžŒμ΄ ν•„μš”κ°œλ°œμ†λ„κ°€ 느리며 μœ μ—°μ„±μ΄ 떨어진닀.
μˆ˜λ§Žμ€ 변경사항이 μžˆμ„ 수 μžˆμœΌλ―€λ‘œ λ²ˆκ±°λ‘œμ›€ λ°œμƒκ°œλ°œ μš”κ΅¬μ‚¬λž‘μ΄ μ΄ˆκΈ°μ— 정해지기 λ•Œλ¬Έμ— 변경이 μžμœ λ‘­μ§€ λͺ»ν•¨

πŸ”Žμ§€μ†μ  톡합 λ„μž…μœΌλ‘œμ¨ κΈ°μ‘΄ 개발 방식 문제 ν•΄κ²°

기쑴의 개발 λ°©μ‹μ˜ 단점듀을 정리해 보자면

  • 반볡적인 μž‘μ—…μ„ λΉ λ₯΄κ²Œ μ²˜λ¦¬ν•˜κΈ° μœ„ν•΄μ„œ μˆ™λ ¨λœ 인λ ₯ ν•„μš”
  • μˆ˜λ§Žμ€ λ³€κ²½μ‚¬ν•­μ˜ λ²ˆκ±°λ‘œμ›€ λ°œμƒ
  • 개발 속도가 느리고 μœ μ—°μ„±μ΄ 떨어짐
  • 개발 μš”κ΅¬μ‚¬ν•­μ˜ 변경이 μžμœ λ‘­μ§€ λͺ»ν•¨

κ³Ό 같은 단점듀이 μ‘΄μž¬ν•œλ‹€.

μ—¬κΈ°μ„œ μš°λ¦¬κ°€ ν•„μš”ν•œ 것은 μžλ™ν™”μ΄λ‹€
이런 μžλ™ν™”λœ 지속적 ν†΅ν•©μ˜ λ„μž…μœΌλ‘œ λ‹€μŒκ³Ό 같은 이점이 μ‘΄μž¬ν•œλ‹€.

  • 개발자 생산성 ν–₯상
    지속적 톡합을 μ‚¬μš©ν•˜λ©΄ 개발자의 μˆ˜λ™ μž‘μ—…μ— λŒ€ν•œ 뢀담을 덜고 버그 수λ₯Ό μ€„μ΄λŠ” 데 도움이 λœλ‹€.
  • λΉ λ₯Έ μ—…λ°μ΄νŠΈ 제곡
    지속적 톡합을 μ‚¬μš©ν•˜λ©΄ νŒ€μ΄ μ’€ 더 λΉ λ₯΄κ³  μ’€ 더 λΉˆλ²ˆν•˜κ²Œ κ³ κ°μ—κ²Œ μ—…λ°μ΄νŠΈλ₯Ό μ œκ³΅ν•  수 μžˆλ‹€.
  • 문제 μ‘°κΈ° 진압
    μžλ™ν™”λ₯Ό 톡해 μˆ˜μ‹œλ‘œ 톡합할 수 있으며, 이λ₯Ό 톡해 문제λ₯Ό 쑰기에 λ°œκ²¬ν•˜κ³  μ‘°μΉ˜ν•  수 μžˆλ‹€.
  • λΉŒλ“œμ™€ ν…ŒμŠ€νŠΈλ₯Ό λ…λ¦½μ μœΌλ‘œ ꡬ성
    κ°œλ°œμžκ°€ μ½”λ“œλ₯Ό λΉŒλ“œν•˜κ±°λ‚˜ μˆ˜μ •ν–ˆμ„λ•Œ 개인 ν™˜κ²½μ—μ„œλ§Œ μ‹€ν–‰λ˜λŠ” 문제λ₯Ό 쑰기에 μˆ˜μ •ν•  수 μžˆλ‹€.

μ΄λŸ¬ν•œ 이점이 지속적 톡합을 λ„μž…ν•΄ κΈ°μ‘΄ 단점듀을 ν•΄μ†Œν•˜κ³  반볡적이고 μˆ˜λ™μ μΈ μž‘μ—…μ„ μžλ™ν™” ν•˜μ—¬ 더 λΉ λ₯΄κ³  고객 μš”κ΅¬μ‚¬ν•­μ„ λ°˜μ˜μ‹œν‚¨ μ„œλΉ„μŠ€λ₯Ό κ°œλ°œν•  수 μžˆλ‹€.

πŸ”Žμ§€μ†μ  톡합 κ³Όμ •μ—μ„œ λ°˜λ“œμ‹œ μžλ™ν™”κ°€ 이뀄져야 ν•˜λŠ” λΆ€λΆ„

μš°λ¦¬λŠ” 데브옡슀 λ¬Έν™”λ₯Ό λ°°μšΈλ•Œ CI/CDλΌλŠ” 것을 μ•Œκ²Œ λœλ‹€.

CI/CD νŒŒμ΄ν”„λΌμΈμ„ κ΅¬μΆ•ν•˜κΈ° μœ„ν•΄μ„œ 지속적 톡합과 지속적 전달이 κ΅¬μΆ•λ˜μ–΄μ•Ό ν•œλ‹€.

κ·Έλ ‡κ²Œ ν•˜κΈ° μœ„ν•΄μ„œλŠ” CI/CD νŒŒμ΄ν”„ 라인 전체가 μžλ™ν™”κ°€ λ˜μ–΄μ•Ό μ§„μ •ν•œ λ°λΈŒμ˜΅μŠ€κ°€ μ™„μ„±λœλ‹€κ³  μƒκ°ν•œλ‹€.

κ·Έ 쀑 지속적 톡합(Continuous Integration)의 μš”μ†Œμ—λŠ” Code Pushing -> Building -> Testing
의 μ „ 과정이 μžλ™ν™”κ°€ λ˜μ–΄μ•Όλ§Œ 지속적 전달이 μ›ν™œν•˜κ²Œ 될 것이닀.

μˆ˜λ™μ μ΄κ³  반볡적인 μž‘μ—…μ„ μžλ™ν™” νˆ΄μ„ μ΄μš©ν•΄ 쑰기에 문제λ₯Ό ν•΄κ²°ν•˜κ³  후에 μžˆμ„ λ¦΄λ¦¬μ¦ˆμ™€ 배포λ₯Ό μžλ™ν™” ν•  수 μžˆλ‹€.

그의 ν•œ μ˜ˆμ‹œλ‘œ κΉƒν—ˆλΈŒ μ•‘μ…˜μ„ ν†΅ν•˜μ—¬ μ½”λ“œ 푸쉬가 됨에 따라 λΉŒλ“œμ™€ ν…ŒμŠ€νŠΈλ₯Ό .yml νŒŒμΌμ„ μ΄μš©ν•΄ μžλ™μœΌλ‘œ 싀행이 될 수 μžˆλ‹€.
μ½”λ“œ 버전관리 μ‹œμŠ€ν…œμ„ 톡해 ν‘Έμ‹œλœ μ½”λ“œμ˜ 병합을 μžλ™ν™”ν•˜κ³  λ³‘ν•©λœ μ½”λ“œλ“€μ΄ λΉŒλ“œμ™€ ν…ŒμŠ€νŠΈλ₯Ό μžλ™ν™” ν•¨μœΌλ‘œμ¨ κ°œλ°œμžμ—κ²ŒλŠ” κ°œλ°œμ— μ§‘μ€‘λœ ν™˜κ²½μ„, μš΄μ˜νŒ€μ—κ²ŒλŠ” 버그관리, 고객의견 반영 λ“±μ˜ 이점을 κ·ΉλŒ€ν™” ν•  수 μž‡λ‹€.

레퍼런슀 λͺ¨μŒ

  1. μ• μžμΌ λ°©λ²•λ‘ μ΄λž€?
  2. μ§€μ†μ ν†΅ν•©μ΄λž€?
  3. μ†Œν”„νŠΈμ›¨μ–΄ 개발 방법둠
  4. Agile과 Waterfall의 차이
  5. 개발 λ°©λ²•λ‘ μ˜ ν˜„μž¬μ™€ 미래
profile
Better Than Yesterday

0개의 λŒ“κΈ€