TIL: 2023-04-25

⚙️ 오늘 학습한 내용

소프트웨어 개발 방법론

🐹 오늘의 기분

짚고 넘어간 적은 있지만 두 방식의 차이를 어렴풋이 알고 있는 것 같아 소프트웨어 개발 방법론에 대해 정리해보았다. 팀 프로젝트를 하면서 요구사항이 변하는 경우가 많았어서 처음부터 기획을 꼼꼼히 했어야 하는건가 하고 후회를 했었는데, 애자일을 보니 오히려 요구사항이 변하는 것이 당연한 것이었겠다는 생각을 다시 해보게 되었다.

🗝 키워드

워터폴, 애자일, 스크럼, 트렁크

🗣 스스로에게 설명

소프트웨어 개발 방법론에 관한 내용은 전부 '커리어 스킬' 329p를 참고하였음

워터폴 waterfall

소프트웨어를 한 번에 한 단계씩 개발해나가는 방식

포함 개념

• 소프트웨어 개발 생명주기 (Software Development Life Cycle, SDLC) - 설계, 구현, 테스트, 배포, 유지 보수로 끝나는 일련의 과정을 일컫는다.

워터폴 방식의 SDLC는 순차적이며, 뒤로 가지 않는다.
따라서 이 방식에서는 요구사항의 변화가 문제가 된다.

애자일 Agile

애자일의 사전적 의미는 '날렵한, 민감한'이다.
애자일은 정확히 말하면 소프트웨어 개발 방법론으로 보기 어렵다고 한다.

애자일 선언문에 정의된 12가지 원칙 (출처: https://medium.com/hgmin/agile-principles-%EC%95%A0%EC%9E%90%EC%9D%BC-12%EA%B0%80%EC%A7%80-%EC%9B%90%EC%B9%99-d3f386bd9839)

주요 특징

• 개발 도중 요구사항이 변경될 수 있고, 변경되는 것이 마땅하다.
• 조직의 커뮤니케이션과 팀의 가치를 중시한다.
• 소프트웨어를 빠르게 지속적으로 제공하여 고객을 만족시키는 것을 목표로 한다.
• 서로 얼굴을 보고 하는 소통을 중시한다.
• 지속 가능한 개발을 장려한다.

다음은 애자일 방법론 중 대표적인 몇 가지이다.

1. 스크럼

소프트웨어 개발을 스프린트라고 부르는 작은 반복 주기로 나눈 것.

주요 직책

• 제품 책임자 - 고객과의 소통, 작업 우선순위 결정
• 개발팀
• 스크럼 마스터 - 스크럼이 문제없이 진행될 수 있도록 하는 코치 역할

스프린트로 정해둔 기간 내에 해야 할 일의 양을 정해둠 -> 각 스프린트를 마칠 때마다 나오는 결과물을 고객에게 전달
개발해야 할 모든 기능을 백로그에 넣어두고 우선순위를 정한다.
스프린트를 시작할 때 계획 회의를 열고 매일 스크럼 회의를 하며, 스프린트가 끝나고 나면 회고 회의를 연다.

2. 칸반

스크럼과 유사하지만 조금 더 느슨한 방법론
핵심: 프로젝트에서 해야 하는 일을 시각화하고, 동시에 진행하는 업무의 양을 제한한다.
피드백 루프를 통해 끊임없이 더 나아지는 것에 집중한다.

Github Project의 칸반 보드나 Jira가 이런 형태이다.

3. 익스트림 프로그래밍

1996년 경 만들어졌으며, 당시의 모범 사례들을 많이 가져와 차용한 방법
규범이 매우 까다롭고 빡빡하다.
실제 코드를 작성하기 전에 코드가 다양한 상황에서 해야 할 일을 정확히 정의하는 단위 테스트를 만든다.
페어 프로그래밍에 의존한다.
미래보다는 현재의 시점에서 기능을 최대한 단순하게 설계해서 구현하는 것이 목표다.
중요 개념: 코드의 공동 소유와 코딩 표준
제대로 따르면 좋지만 그게 쉽지 않음.

트렁크 기반 개발 (git branching 전략 중 하나)

면접 스터디에서 처음 알게 된 방식인데 잘 몰라서 이번 기회에 정리해보려고 한다.

트렁크 혹은 마스터 브랜치에서 모든 작업을 진행하는 전략
단, 몇 가지 원칙을 지켜야 한다.

• 페어 프로그래밍
• 코드 베이스가 항상 릴리즈 가능한 상태임을 확신할 수 있어야 한다. 그러기 위해서는 테스트 설계가 잘 되어있어야 한다.
• 작업이 완료되지 않은 부분은 Branch by abstraction이나 feature flags를 이용한다.
• 작업 단위를 잘게 쪼갠다.
• 빌드 및 테스트 프로세스가 빨라야 한다.

기존 feature branch 방식에서 50개의 기능을 나눠서 개발한다고 가정할 경우, 각자의 코드가 서로에게 영향을 끼치지 않는다는 이점이 있지만 코드를 합병하는 과정에서 conflict가 날 수도 있으며, 그 코드가 프로덕션에서도 잘 작동할 것이라 확신할 수 없다.
트렁크 기반 개발 방식에서는 하나의 브랜치에서 작업이 이루어지기 때문에 모든 개발자가 항상 프로덕션에서 실행되는 최신 버전의 코드를 갖게 된다. (브랜치를 아예 안 쓰는 것은 아니라고 한다.) 또 feature branch 방식에서는 PR로 코드의 책임이 개인에게 향했던 반면에 이 방식에서는 코드가 공동 소유의 개념으로 확장되어 더 높은 수준의 협업이 가능해진다. 다른 장점은 아래 출처에 더 설명되어 있다.

 

참고

트렁크 기반 개발(Trunk-Based Development)