✅ TIL

---

솔로 프로젝트란?

앞으로 5일 동안 솔로 프로젝트라는 것을 진행하게 된다.

솔로 프로젝트는 앞으로 지원하고자 하는 회사에 제출하게 될 과제형 프로젝트와 비슷한 형태이며,
프로젝트 요구사항 명세서라는 게 사전에 주어지게 된다. 명세서 내에 기술된 요구사항에 맞춰 스크럼 보드를 이용해 자신의 개발 진척도를 관리하며 프로젝트를 개발하는 경험을 하게 된다.

또한 몇 차례의 코드 리뷰도 받게 된다.
교육 엔지니어들로부터 코드 리뷰를 받아 코드를 점진적으로 개선하면서 프로젝트를 완료시킬 수 있다.

여기서 과제형 프로젝트 형식의 솔로 프로젝트는
사전 과제라는 형태로 일부 프론트엔드 개발자를 채용하는 회사에서 제시한다.

보통 지원자에게 약 일주일 정도의 시간을 주고 소규모 프로젝트를 진행하게 하는데, 회사는 사전 과제를 내줌으로써 해당 프로젝트를 진행하는 지원자의 여러 역량을 폭넓게 체크할 수 있다는 장점이 있다.

프로젝트 요구사항 명세서

---

Github과 Git Flow

---

솔로 프로젝트 관리에 활용할 수 있는 Github 기능

Issue

Issue는 프로젝트에 새로운 기능을 제안하거나, 버그를 찾아 제보하는 등 프로젝트의 이슈를 의미한다.
솔로 프로젝트에서는 Issue를 하나의 스크럼 티켓처럼 사용하게 된다.

Pull Request

Pull Request는 내가 작업한 내용을 중요 git branch에 합칠 수 있는지 확인하는 요청이다.

Github에서는 Pull Request를 통해 commit한 코드를 따로 선택하여 해당 부분에 코멘트를 달 수 있다.

현장에서도 Pull Request를 통해 코드를 보면서 코멘트를 남기는 방식으로
코드 리뷰를 진행하기 때문에, 이 Pull Request 과정에 익숙해지는 것이 중요하다.

Project

Project는 Github 내에서 업무 관리를 해줄 수 있게 돕는 새로운 기능이다.

솔로 프로젝트에서는 이 Project 기능을 이용하여 스크럼 보드를 생성하고,
스프린트 기간 동안 솔로 프로젝트의 스윔레인(SwimLane)을 관리한다.

Git Flow

git flow, 즉 git 전략을 고려하면서 프로젝트를 진행하기 위해서는
몇 가지 알아야 하는 git command와 git 기능이 있다.

Git branch

브랜칭(branching)은 기존 개발 중인 메인 개발 코드를 그대로 복사하여
새로운 기능 개발을 메인 개발 코드를 건드리지 않고 할 수 있는 버전 관리 기법이다.

첫 main 브랜치에서만 작업을 하다가 새로운 기능 개발을 위해 feature 브랜치를 새로 생성하는 경우,
기존 main 브랜치에서의 작업은 유지하고 새로운 feature 브랜치에서 자유롭게 코드를 추가 및 삭제할 수 있다.

브랜치 생성하기 / 변경하기 (git switch)

이때, 새로운 브랜치로 Git이 바라보는 곳, HEAD를 변경하는 작업을 switch라고 부른다.

브랜치를 생성할 때는 생성(create)의 의미로 -c 옵션을 붙여줘야 하고,
기존에 있는 브랜치로 옮길 때는 붙이지 않아도 된다.

브랜치 합치기 (git merge)

기능 개발이 끝나면 브랜치를 main 브랜치와 합칠 수 있다.

Pull Request

실제 프로젝트 개발 시에는 브랜치를 로컬에서 합치기보다는 Github의 Pull Request 기능을 이용하여 변경 내역을 충분히 확인하고 난 다음에 merge 하는 경우가 더 많기 때문에, 로컬에서 merge 하지 않고 feature 브랜치를 push 하여 Pull Request를 요청하는 것을 권장한다.

브랜치 삭제하기 (git branch -d)

merge 된 feature 브랜치는 이미 dev 브랜치에 기록이 완벽하게 남아있기 때문에,
굳이 남겨둘 이유가 없어 삭제해 브랜치를 깔끔하게 관리하는 편이 좋다.

원격 리포지토리에서 pull request가 성공적으로 마무리되면,
위의 이미지처럼 브랜치를 삭제하는 버튼을 눌러 쉽게 삭제할 수 있다.

✨ Git Flow 커맨드 정리

// 새로운 브랜치 만들기

git switch -c []
git checkout -b []


// 브랜치 옮기기

git switch []
git checkout []

 
// 현재 브랜치 확인하기

git branch
git log --oneline --decorate


// Pull Request - 커밋 -> 푸시 -> PR

1. git commit -m "기능1의 세부 기능1"

2. git push origin feat/todo

3. Github에서 Pull Request를 합니다.


// 브랜치 삭제하기

git branch -d feat/todo
git branch -D feat/todo - 강제 삭제

소프트웨어 개발 방법론

---

소프트웨어 개발 방법론의 일반적 단계

1. 요구사항 분석

   • 소프트웨어가 해결해야 할 문제와 고객의 요구사항을 파악하고 정의하는 단계이다.
   • 다양한 이해관계자 간에 상충할 수 있는 요구사항을 고려해, 새로운 제품이나 변경된 제품에 부합하는 요구와 조건을 결정하는 단계이다.
   • 개발할 소프트웨어의 기능과 제약 조건, 목표 등을 소프트웨어 사용자와 함께 명확히 정의하는 단계이다.
   • ex) 기능 요구사항, 비기능 요구사항

2. 설계

   • 소프트웨어의 구조와 기능, 인터페이스, 알고리즘 등을 대략적으로 설계하는 단계이다.
   • ex) 시스템 구조 설계, 프로그램 설계, 사용자 인터페이스 설계

3. 구현 또는 코딩

   • 설계한 내용을 프로그래밍 언어로 작성하여 실제로 동작하는 소프트웨어를 만드는 단계이다.
   • 프로그래밍 언어 선택, 기법, 스타일, 순서 등을 결정하는 단계이다.
   • ex) 인터페이스 개발, 자료구조 개발, 오류 처리

4. 테스트

   • 구현 단계에서 만들어 낸 소프트웨어가 오류나 결함 없이 예측했던 대로 동작하는 지 검증하는 단계이다.
   • ex) 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트

5. 유지보수

   • 시스템이 인수되고 설치된 후에 일어나는 모든 활동을 의미한다.
   • 배포된 소프트웨어의 성능을 개선하거나 새로운 기능 및 요구사항을 정의하고, 변화에 대응해 수정 및 업데이트하는 등 배포 이후에 일어나는 모든 과정을 일컫는다.
   • ex) 예방, 완전, 교정, 적응 유지보수

대표적으로 사용 되는 소프트웨어 개발 방법론의 종류

• 폭포수 모델(Waterfall Model)

  • 가장 전통적이고 오래된 모델이다.
  • 타당성 검토 → 계획 → 요구사항 분석 → 설계 → 구현 → 테스트 → 유지보수 순으로 단계가 진행 된다.
  • 각 단계는 순차적으로 진행되며, 이전 단계가 완료되어야 다음 단계로 넘어갈 수 있는 모델이다.
  • 모델의 적용 사례와 성공 사례가 가장 많다.
  • 단계별 정의와 산출물이 명확하다.
  • 요구사항 변경에 대한 대처가 어렵다.
  • 계획이 명확하고 변경이 적은 프로젝트에 적합하다.

• 애자일 모델(Agile Model)

  • 고객의 피드백을 빠르게 반영하며, 잦은 변화에 유연하게 대응하는 모델이다.
  • 작은 단위로 개발하고 테스트하며 지속적으로 개선하는 모델이다.
  • 사용자의 요구사항 일부분 혹은 제품의 일부분을 반복적으로 개발하여 최종 시스템으로 완성하는 모델이다.
  • 요구사항이 자주 바뀌고 협업이 많이 필요한 프로젝트에 적합하다.

소프트웨어 개발 방법론 선택 시 고려할 사항

• 프로젝트의 특성

  • 프로젝트의 목적, 규모, 복잡도, 기간, 예산 등을 모두 고려하여 적절한 모델을 선택해야 한다.
  • 명확하고 안정적이며, 변화할 여지가 적은 요구사항이 있는 단순한 프로젝트라면 폭포수 모델이 적합할 수 있다.
  • 불확실하고 요구되는 기능에 변화가 일어날 가능성이 높거나, 잦은 변화가 일어나는 복잡한 프로젝트라면 애자일 모델이 적합할 수 있다.

• 고객 참여도

  • 고객이 프로젝트에 얼마나 관여하고 피드백을 제공할 수 있는지 고려해야 한다.
  • 고객이 최초 목표 수립과 요구사항 제시 이후에는 프로젝트와 밀접하지 않거나, 상대적으로 소극적으로 참여하는 상황에서 최종 결과물을 제공해야 한다면 폭포수 모델이 적합할 수 있다.
  • 고객이 프로젝트와 아주 밀접하게 있거나, 빠르고 잦은 피드백을 원한다면 애자일 모델이 적합할 수 있다.

• 팀의 역량과 문화

  • 팀의 인원 수, 역할, 책임, 기술 수준, 협업 방식 등을 고려해 적절한 모델을 선택해야 한다.
  • 팀의 규모가 크고 계층 구조를 갖고 있고, 상대적으로 낮은 기술 수준과 협업이 중요하지 않은 환경을 갖고 있다면 폭포수 모델이 적합할 수 있다.
  • 팀의 규모가 작고 자율적이며, 상대적으로 높은 기술 수준과 협업이 잦은 환경이라면 애자일 모델이 적합할 수 있다.
    
    

소프트웨어 개발 방법론을 선택해 적용하는 것은
프로젝트의 성공과 실패에 큰 영향을 끼치는 아주 중요한 결정이다.

소프트웨어 개발 방법론을 최초에 선택한 이후에도 변경할 수는 있다.
하지만 이후에 변경하는 과정은 쉽지 않고 비용 또한 많이 들 수 있다.

예를 들어 폭포수 모델에서 애자일 모델로 변경하게 된다면
팀의 구성과 각자의 역할, 작업 방식, 문화, 그리고 도구와 기법 등을
모두 바꾸고 팀원 모두 새롭게 교육을 해야 한다.

또한 고객과의 일정이나 계약 또한 조정이 필요할 수 있다.

따라서 프로젝트의 특성과 규모, 고객의 참여도와 팀의 역량, 문화 등을
충분히 분석하고 비교해 최적의 모델을 선택해야 한다.

애자일 방법론

---

애자일 방법론은 요구사항이 변화하는 것을 당연한 전제로 두고,
변화하는 요구사항에 민첩하게 대응하며 개발을 수행하는 소프트웨어 개발 방법론으로,
문서에 의존하기보다는 코드 지향적으로 효율적인 개발을 지향하는 목적에서 탄생했다.

애자일 방법론은 특정 방법론을 가리키는 것이 아니라 뒤에서 살펴볼 스크럼(Scrum), 익스트림 프로그래밍(XP), 칸반(Kanban) 등 좋은 것을 빠르고 낭비 없게 만드는 다양한 방법론 전체를 일컫는다.

정리하자면 애자일 방법론은 절차보다는 사람이 중시되어 변화에 유연하고 신속하게 대처하면서 효율적으로 빠르게 시스템을 개발할 수 있는 방법론이다. 작업 단위를 세분화해 개발 기간이 짧고 산출물 확인이 신속하게 이루어지며, 개발 완료 시 바로 피드백을 받기 때문에 개발과 피드백에 유연하게 대응할 수 있다.

폭포수 방법론과 애자일 방법론의 차이

애자일 방법론과 대비되는 폭포수 방법론은 요구분석부터 기획, 개발, 테스트, 출시까지
순차적으로 진행하여 마치 폭포가 떨어지는 식으로 순차적인 단계를 밟는 전통적인 개발 방법론이다.

폭포수 방법론은 기획단계에서 프로젝트 전체를 대상으로 플래닝을 진행한 후
프로젝트 전체에 대한 기획문서가 나온 후 일괄적으로 개발에 들어가는 진행방식을 띄고 있어,
개발을 진행하면서 발생하는 기획단계에서 예측할 수 없는 이슈들에 대해 유연하게 대응하기 어렵다.

이렇듯 폭포수 방법론의 문제점은 요구분석, 기획 단계에서 진행했던
일련의 과정들이 고객의 요구를 100% 충족하기 힘들다는 것이다.

대응하지 못한 이슈들이 엉키게 되면 아래와 같은 문제점들이 발생하여
프로젝트에 참여한 모든 구성원들이 어려움을 겪게 된다.

• 코드 품질 저하
• 요구사항이 충족되지 않음
• 기대 이하의 산출물
• 시간 지연
• 프로젝트 종료에 관한 낮은 예측 정확도

이처럼 폭포수 방법론과 같은 기존 방법론은 문서 및 절차 위주로 진행되기 때문에,
변화에 민감하게 대응하지 못하고 개발 주기가 빠르지 못하다는 단점이 있다.

빠르게 변화하는 시장에 민감하게 대응해야 하는 시장 적시성과 잦은 배포의 중요성이
점차 대두되면서 애자일 방법론이 폭포수 방법론을 대체하기 시작했다.

전통적인 개발 방법론인 폭포수 방법론과 애자일 방법론의 차이를 정리해 보겠다.

폭포수 방법론은 요구분석, 기획등 전체 프로젝트에 대한 모든 문서를 만들고, 해당 작업들이 모두 끝난 이후 개발에 들어간다. 문서와 절차의 중요성이 큰 방법론이다. 그러나 고객의 요구에 민감하게 반응하기 어렵다는 단점이 있다.

반면 애자일 방법론은 고객의 요구사항들을 충족하기 위해 시장에 민감하게 반응하며 개발하는 방법론이다. 따라서 애자일 방법론에서는 문서가 아닌 코드로 보여주는 것이 중요시되고, 전체가 아닌 기능 단위의 프로토타입을 기반으로 개발이 진행된다. 좀 더 작은 단위로 개발을 해서, 해당 부분을 직접 고객에게 선보이고 피드백을 빠르게 전달받아 수정이나 이슈처리에 대한 기민한 대응을 하기 위함이다.

애자일 방법론을 구체화하기 위한 도구들

애자일 방법론을 활용하기 위한 도구들은 여러 가지가 있다.
그중 가장 많이 사용하는 두 가지 도구인 스크럼(Scrum)과 칸반(Kanban)을 소개한다.

먼저, 설명에 들어가기 전에 기억하셔야 할 단어가 있다.
스크럼은 “스프린트 기반", 칸반은 “WIP”이다.

스크럼은 스프린트를 기반으로 애자일 방법론을 실행하고,
칸반은 Work In Process(WIP)를 제한하여 애자일 방법론을 실행한다.

스크럼(Scrum)

스크럼은 스프린트 작업 단위를 부여하며 스프린트는 보통 2주를 기준으로 하고, 팀의 특성에 맞춰 줄이거나 늘릴 수 있다.

한 스프린트가 시작하는 월요일 하루에 걸쳐 해당 스프린트 기간 동안 작업할 수 있는 개발자 개개인의 시간들을 모두 합쳐 총 작업시간을 책정하고, 스프린트 동안 할 작업들을 추산하는 플래닝을 진행한다. 매일 오전 약 15분 정도의 데일리 미팅을 진행해 오늘 할 일을 공유하고 어제 한 일을 간단히 리뷰한다. 또한 해당 스프린트가 끝나는 주의 금요일에는 그동안 플래닝을 통해 진행했던 작업들에 대한 회고를 진행한다.

플래닝은 PO(product owner), 스크럼 마스터(Scrum Master), 개발자가 참여하여 플래닝 포커를 통해 진행한다. PO는 고객을 대변하는 비즈니스 담당자이다. 비즈니스의 입장에서 필요한 기능들을 말하는 역할을 담당한다. 스크럼 마스터는 개발의 측면에서 PO가 말한 비즈니스 기능들을 개발 가능한 단위로 쪼개고 조율하는 역할을 한다. 스크럼 마스터는 개발자들이 번갈아 가면서 맡기도 한다.

기능을 분리할 때는 가능한 한 작은 단위로 분리하는 것이 좋다.

예를 들어, 관리자 페이지 개발보다는 관리자 페이지 내 회원가입기능 중
이메일 인증 부분 개발이 더 작은 단위로 분리되었다고 할 수 있다.

칸반(Kanban)

칸반 방식의 핵심은 WIP(Work In Progress) 제한이다.

칸반과 스크럼의 가장 두드러지는 차이는 칸반은 스크럼처럼 스프린트처럼 약속된 업무 종료일이 없다는 것이다.

칸반도 스크럼과 마찬가지로 새롭게 들어온 이슈카드에 대해 시간을 추정하는 작업을 한다. 그러나 스크럼과는 달리 플래닝을 하는 날이 따로 정해져 있지 않고 매일 오전 약 15분 정도 진행되는 데일리 미팅에서 새롭게 들어온 이슈카드의 기능을 구현하기 위한 요구사항을 분석하고 시간이 얼마나 걸릴지 플래닝을 진행한다.

하지만, 앞서 말한 것처럼 해당 이슈카드가 언제 시작되어서 언제까지 기능을 완료할지는 스크럼처럼 정해진 기간이 명확하지 않다. 이슈카드는 정해진 종료 기한 없이 Backlog에 쌓이게 되고, 연속적인 일의 흐름에서 급한 작업단위의 순서대로 In progress에 이슈카드를 넣고 처리한다. 그렇다고 한 명의 개발자가 모든 작업을 가져와 In progress에 동시에 넣고 진행할 수 없으며, 이는 실제 작업하는 방식을 고려하더라도 불가능하다.

따라서, 개발팀의 인원과 특성을 고려하여 In Progress에 넣을 수 있는 이슈카드의 개수가 제한되는데, 이를 WIP(Work In Progress) 제한이라고 부른다. 개발자들은 미리 정한 WIP에 여유가 있을 때에만 백로그에서 이슈카드를 In Progress로 옮겨와 작업을 진행할 수 있다. 칸반 방식은 이러한 WIP 제한을 통해 쏟아져 들어오는 이슈카드들 속에서 허우적거리며 개발이 제대로 진행되지 않을 수 있는 위험을 방지한다.