Step 2 - 프로젝트 시작하기
본격적으로 Pre-Project 프로젝트 제작하기 전에, 이번 유닛에서는 프로젝트 시작을 위해 필요한 내용을 학습합니다. 이번 유닛에서는 Todo App을 제작한다고 가정하고, Todo App을 제작하기 위해서 필요한 것에 대해서 차근차근 학습해보겠습니다.
[그림] Todo App 제작 예상본 예시
프로젝트 Github
이번 챕터에서는 개발 프로젝트 제작을 위해 Github를 다루는 방법에 대해서 소개합니다.
Chapter1-1. Github 리포지토리
- 개념학습: 프로젝트 Github 리포지토리에 꼭 필요한 요소에 대해서 학습합니다.
- 튜토리얼: 프로젝트 Github 리포지토리를 함께 만들어봅니다.
Chapter1-2. Github Project 칸반
- 개념학습: 칸반이 무엇인지 학습합니다.
- 퀴즈: 학습한 개념의 이해도를 확인합니다.
- 튜토리얼1: Github 이슈, 마일스톤 기능을 활용하여 프로젝트 할 일을 나눠보고 기한을 설정해봅니다.
- 튜토리얼2: Github Project 기능을 활용하여 칸반 뷰로 업무를 시각화합니다.
학습 목표
- 개발 프로젝트 Github 리포지토리에 꼭 필요한 요소를 이해한다.
- 칸반이 무엇인지 이해한다.
- 칸반 원칙과 실천 방안에 대해서 이해한다.
- Github Project, 이슈, 마일스톤 기능을 이용하여 칸반 보드를 제작할 수 있다.
- 칸반 보드로 업무 시각화를 할 수 있다.
Chapter1-1. Github 리포지토리
지금까지는 Github 리포지토리를 코드를 공유하고 과제를 클론 받는 단순한 원격 코드 저장소로써 사용해왔습니다. 이번 Pre-Project부터는 Github 리포지토리를 하나의 완성된 개발 프로젝트에 대한 코드와 주요 정보를 공유하는 수단으로 사용하는 방법에 대해서 안내합니다.
Github 리포지토리에 꼭 필요한 파일
Github는 개발자의 SNS라고 불릴 정도로 다양한 종류의 오픈소스 프로젝트가 공유되어 있습니다. 오픈소스 프로젝트에 들어가면, 가장 먼저 확인할 수 있는 정보가 바로 이 README.md 파일입니다. 기본적인 마크다운 사용법을 잘 숙지하고 있으면 간단한 소개 페이지처럼 제작할 수 있습니다. README.md 파일을 적는 양식은 따로 존재하지 않지만, 대체로 어떻게 하면 해당 오픈소스를 활용할 수 있는지에 대한 상세한 정보가 작성되어 있습니다.
Pre-Project Github 리포지토리 README.md 파일은 아래 정보를 꼭 포함해야 합니다.
- 프로젝트 이름
- 프로젝트 핵심 기능 소개
- 팀원 소개
- 잘 작성된 README.md 살펴보기
.gitignore
gitignore dotfile은 git으로 관리하지 않는 파일 모음입니다. 여기에는 개인이 따로 관리해야 하는 중요한 secret token이나, 다른 동료와 공유할 필요가 없는 설정 파일, 그 외 공유할 필요 없는 파일을 기록하면 git이 이를 파악하지 않고, push 할 때도 github 리포지토리에 push되지 않습니다.
LICENSE
해당 코드의 라이센스를 표기합니다. 깃허브에 public하게 공개된 리포지토리도 라이센스에 따라서 사용을 할 수도 있고, 하지 못 할 수도 있으니 사용할 때 라이센스를 잘 보고 사용해야 합니다. 회사에서 사용하는 코드는 private으로 관리하고, 외부에 공개하지 않아 라이센스 정보를 따로 표기하지 않기도 합니다. 하지만 모종의 이유로 회사에서 작성하는 코드가 public으로 공개된다면, LICENSE를 명확하게 표기해야 합니다.
프로젝트 관리에 활용할 수 있는 Github 기능
Issue
Issue는 말 그대로 프로젝트에 새로운 기능을 제안하거나, 버그를 찾아 제보하는 등 프로젝트의 이슈를 의미합니다.
Project에서는 Issue를 하나의 칸반 티켓처럼 사용합니다.
Milestone
Milestone은 이정표 역할을 하며, 태스크 카드(Issue)를 그룹화하는 데 사용합니다. Milestone에 연결된 태스크 카드(Issue)가 종료되면 Milestone마다 진행 상황이 업데이트되는 것을 볼 수 있습니다. 이 Milestone 기능을 통해 연관된 이슈의 추적과 진행 상황을 한눈에 파악할 수 있는 장점이 있습니다.
Project에서는 Bare Minimum, Advanced Challenge, Nightmare를 표시하기 위해 사용합니다.
Pull Request
Pull Request는 내가 작업한 내용을 중요 git branch에 합칠 수 있는지 확인하는 요청입니다. Github에서는 Pull Request에서 커밋한 코드를 따로 선택하여 해당 부분에 코멘트를 달 수 있습니다. 현장에서도 Pull Request를 보면서 코멘트를 남기면서 코드 리뷰를 진행하기 때문에 Pull Request 과정에 익숙해지는 것이 중요합니다.
Project
Project는 Github 내에서 업무 관리를 해줄 수 있게 돕는 새로운 기능입니다.
Pre-Project에서는 이 Project 기능을 이용하여 칸반 보드를 생성하고, 칸반으로 Pre-Project의 업무 흐름을 관리합니다.
Chapter1-2. Github Project 칸반
팀 개발 프로젝트는 여러 인원이 함께 업무를 처리합니다. 취미로 만드는 사이드 프로젝트는 혼자 기획하고 개발해도 문제가 없으나, 타겟 사용자가 있고 해당 사용자가 돈을 지불할 만한 상용 웹 애플리케이션을 만들려면 많은 사람이 함께 모여서 일해야 합니다. 이렇게 여러 직군이 모여서 함께 개발을 하다 보니 자연스럽게 협업 방식이나 업무 관리 방식에 대한 많은 논의가 생겨났습니다. 칸반도 이런 논의 중 생겨난 하나의 업무 관리 방식 중 하나입니다.
칸반이란?
칸반은 팀과 조직이 작업을 시각화하고, 업무의 병목 현상과 리소스 낭비를 해결하는 업무 관리 방법입니다.
칸반 보드를 통한 시각화
칸반의 대표적인 특징은 칸반 보드를 통한 업무 시각화입니다. 칸반 보드는 아래 사진처럼 업무를 하나의 티켓으로 표현하고, 업무 단계를 하나의 열로 표현합니다. 새로운 업무가 생기면 가장 왼쪽 열에 업무가 쌓이고, 업무가 잘 진행되면 가장 오른쪽으로 전달되어 쌓이는 방식입니다. 어떤 업무가 현재 어느 업무 단계에 있는지 한눈에 파악할 수 있습니다.
[그림] 칸반 보드
이렇게 한눈에 업무를 파악할 수 있게 되면 각 팀원이 다른 팀원이 어떤 일을 하고 있는지 투명하게 확인할 수 있고, 문서 파일에 쌓여있는 업무 현황보다 훨씬 더 종합적이고 빠르게 업무 흐름을 파악할 수 있습니다.
Work In Progress(WIP)로 진행중인 업무 제한 및 흐름 관리
WIP는 현재 진행하고 있는 작업을 의미합니다. 칸반에서는 각 업무 단계에 WIP 제한(WIP limit)을 둘 수 있습니다. WIP 제한이 2이면, 두 개 이상의 카드가 해당 열에 위치할 수 없게 됩니다. 아래 예시의 경우 하나의 업무를 추가할 수 있습니다.
[그림] 칸반 보드의 WIP 제한
업무 흐름 관리
WIP를 두는 이유는 무엇일까요? 업무가 과도하게 쌓이지 않는 원활한 업무 흐름을 위해서입니다. 모든 팀원이 100%의 리소스를 사용하고 있는 상태에서 계속 새로운 업무가 쌓이게 되면, 업무가 과부하되어서 업무 효율이 나지 않게 됩니다. 막히는 고속도로에 계속해서 차가 진입하여 속도가 더 느려지는 현상에 비유할 수 있습니다. 즉, WIP 제한은 고속도로 진입로에서 종종 볼 수 있는 신호등과 같은 역할을 합니다.
진행중인 업무 제한
특히 개발 프로젝트는 타 업무와 달리 맥락 전환(context switching)이 없이 집중할 수 있어야 업무 효율이 증가합니다. 제조업 업무는 어떻게 해서든 기계 가동률을 높이거나 일부 생산을 아웃소싱하면 더 짧은 기간 내에 산출물을 만들 수도 있습니다. 하지만 개발 업무는 지식 업무에 해당하기 때문에 밤새 야근하거나 인원을 더 많이 투입한다고 해서 더 좋은 퀄리티의 산출물이 더 빠른 시간 안에 나오지는 않습니다. 특히 소통이 많이 필요한 개발 프로젝트의 경우 인원수가 늘어난다고 해서 소요 기간이 드라마틱하게 증가하지는 않습니다.
즉, WIP 제한은 한 번에 처리하는 업무의 양을 최소화하여 팀원이 한 번에 여러 업무를 동시에 진행해서 생기는 맥락 전환의 문제를 방지할 수 있고, 업무 흐름을 적당하게 유지시켜 업무가 차근차근 처리될 수 있도록 합니다.
명확한 팀 정책을 설정
칸반을 잘 활용하기 위해서는 정책을 설정해야 합니다. 칸반의 열을 정의하고 WIP limit을 세우는 것부터, 언제 회의를 하고 어떻게 의사결정을 할지 명확한 정책을 수립해야 합니다. 정책 수립 시에는 팀원이 모두 모여서 합의를 이뤄야 합니다. 그리고 이렇게 합의한 정책은 향후 업무 진행 상황에 따라서 팀원들이 모여서 언제든지 다시 조정할 수 있습니다.
프로젝트가 본격적으로 시작하기 전에 정하면 좋을 정책은 아래와 같습니다.
- 회의 시간 및 해당 회의에서 논의할 내용
- 팀원 간 소통 원칙
- 칸반 티켓을 언제, 어떻게, 누가 추가할지
- WIP 제한
회의와 리뷰를 통해 함께 업무를 개선합니다.
보통 칸반을 사용하는 경우, 데일리 칸반 회의와 주간 보충 회의를 진행합니다.
데일리 칸반 회의는 업무의 상태 및 흐름을 관찰하고 추적합니다. 어떻게 하면 구현하고자 하는 기능을 좀 더 빠르게 구현할 수 있을지, 업무가 끝난 인원이 다른 업무를 당겨올 수 있는지 등을 정할 수 있습니다. 예를 들면, 프론트엔드 개발자 A가 게시판 CRUD 사용자 인터페이스를 모두 다 구현해서 시간이 충분한 경우, 백로그에 있는 다른 프론트엔드 작업을 가져와서 하거나, WIP에 있는 다른 프론트엔드 개발자 B의 업무를 도와 집중하여 끝낼 수 있게 돕는다던지의 의사결정을 할 수 있습니다.
주간 보충 회의에서는, 칸반 보드에 추가할 만한 업무가 있는지 확인하고, 다음 주에는 어떤 업무를 할 것인지 정할 수 있습니다. 예를 들면, 프로젝트 진행 상황이 매우 원활하여, 추가로 구현하기로 했던 기능을 구현할 수 있게 된 경우에는 주간 보충 회의를 통해 해당 기능 구현 티켓을 칸반 보드에 추가할 수 있습니다.
추가로 격주, 혹은 월간으로 KPT 회고를 진행할 수도 있는데, 지금까지의 진행 상황에 대해서 솔직하게 회고하고, 어떻게 하면 좀 더 잘할 수 있을지 개선점을 찾을 수도 있습니다.
칸반 실천법
지금까지 칸반에 대한 설명은 칸반의 6가지 실천법을 풀어서 설명했습니다. 정리하면 아래와 같습니다.
- 업무 시각화
- 진행 중인 업무 제한
- 흐름 관리
- 명확한 프로세스 정책
- 피드백 루프 구현
- 협력적인 개선, 실험적인 발전
칸반 원칙
위에서 언급한 칸반 실천법은 모두 칸반 원칙을 잘 지키기 위해서 만들어졌습니다. 즉, 해당 구성 요소를 기계적으로 충족시키려고 하기보다는, 종종은 칸반 원칙으로 되돌아와서 지금 하고 있는 작업이 칸반 원칙에 잘 맞는지 고민을 해봐야 합니다.
하던 업무를 칸반 보드에 올려두는 것부터 시작합시다.
당장 하고 있던 업무를 칸반 보드에 올려두는 것부터 시작입니다. 앞으로의 Project도 당장 할 일부터 칸반 보드에 올려두고 시각화하는 것부터 시작해봅시다.
점진적인 변화를 추구합니다.
칸반은 당장의 업무 내용이나 방향성을 갑자기 뒤엎고 화려하고 멋진 기획을 만들기 위한 수단이 아닙니다. 현재 하고 있던 일이나 업무를 잘 수행하기 위한 하나의 수단입니다. 칸반을 위해서 갑작스럽게 업무 방식을 극적으로 변화시키지 말아야 합니다. Project에서도 칸반을 적용하는 게 어려울 수 있습니다. 당장 내가 할 일부터 하나씩 칸반에 올려두는 것부터 시작하세요.
직위에 관계 없이 리더십을 발휘합니다.
칸반은 팀장만 관리하는 것은 아닙니다. 각 팀원도 칸반을 보고 WIP 제한을 늘리거나 줄이는 것을 제안할 수 있고, 새로운 업무 티켓을 발행하거나 기존 업무 티켓의 진행을 도울 수 있습니다. Project에서도 팀원 모두가 합심해서 리더십을 발휘해야 합니다. 아쉽게도 프론트엔드 개발자와 백엔드 개발자가 개발 단계에서는 직무 간 도움을 주기는 쉽지 않습니다. 다만 API 설계나 요구사항 명세서를 적는 기획 단계에서는 서로 어떤 기능을 더 구현하고 덜 구현할지 충분히 제안하고 의견을 나눌 수 있습니다.
현장에서도 신입 개발자에게 시키는 것을 잘하기를 기대하지만, 또한 작은 리더십을 발휘하여 현재 업무 흐름을 개선하기를 기대하기도 합니다. Project의 작은 리더십이 쌓여서 큰 리더십을 발휘할 수 있게 성장하기를 기원합니다.
프로젝트 Git flow
이번 챕터에서는 개발 프로젝트 관리에 꼭 필요한 Git flow에 대해서 학습합니다.
Chapter2-1. Git branch 다루기
- 개념학습: Git branch를 다루는 방법에 대해서 학습합니다.
- 퀴즈: 학습한 개념의 이해도를 확인합니다.
- 예제: Git branch를 다루는 여러 예제를 소개합니다.
Chapter2-2. 프로젝트 Git Flow 학습
- 개념학습: 프로젝트 Git flow에 맞게 브랜치 다루는 방법을 배웁니다.
- 퀴즈: 학습한 개념의 이해도를 확인합니다.
- 튜토리얼: 프로젝트 Git flow에 맞게 Pull Request를 해봅니다.
- 예제: 프로젝트에서 Git을 사용하다가 문제가 생기는 경우 대체법에 대해서 다룹니다.
학습 목표
- Git으로 브랜치를 다루는 방법에 대해 이해한다.
- 브랜칭 전략 중 간소화된 Coz’ Git flow에 대해서 이해하고 적용한다.
- Pull Request와 간단한 코드 리뷰 하는 방법에 대해서 이해한다.
- Git을 다루다가 어려움에 처했을 때, 어떻게 대처하는지에 이해한다.
Chapter2-1. Git branch 다루기
Git branch
브랜칭(branching)은 기존 개발중인 메인 개발 코드를 그대로 복사하여 새로운 기능 개발을 메인 개발 코드를 건드리지 않고 할 수 있는 버전 관리 기법입니다. 처음에 Git 리포지토리를 생성하면 나오는 main 브랜치에서만 작업을 하다가 새로운 기능 개발을 위해 feature 브랜치를 새로 생성하는 경우, 기존 main 브랜치에서의 작업은 유지하고 새로운 feature 브랜치에서 자유롭게 코드를 추가 및 삭제할 수 있습니다.
브랜치 생성하기 / 변경하기 (git switch)
이 때, 새로운 브랜치로 Git이 바라보는 곳, HEAD를 변경하는 작업을 switch라고 부릅니다. 브랜치를 생성할 때는 생성(create)의 의미로 -c 를 붙여줘야 하고, 기존에 있는 브랜치로 옮길 때는 붙이지 않아도 됩니다.
# feature라는 브랜치를 새로 생성하는 경우, -c를 붙입니다.
git switch -c feature
# checkout이라는 명령어도 사용할 수 있습니다.
git checkout -b feature
# 기존에 있던 main 브랜치로 HEAD를 변경하려면, -c를 붙이지 않습니다.
git switch main
git checkout main
브랜치 합치기 (git merge)
기능 개발이 끝나면 브랜치를 main 브랜치와 합칠 수 있습니다.
# 기능 개발이 진행되었습니다.
git commit -m "기능1의 세부 기능1"
git commit -m "기능1의 세부 기능2"
git commit -m "기능1 개발 완료"
# 머지를 위해 main 브랜치로 전환
git switch main
# main 브랜치로 feat/todo 브랜치를 병함
git merge feat/todo
실제 프로젝트 개발 시에는 브랜치를 로컬에서 합치기 보다는 Github의 pull request 기능을 이용하여 변경 내역을 충분히 확인하고 난 다음에 머지하는 경우가 더 많기 때문에, 로컬에서 머지하지 않고 feature 브랜치를 push하여 pull request를 요청하는 것을 권장합니다.
# 기능 개발이 진행되었습니다.
git commit -m "기능1의 세부 기능1"
git commit -m "기능1의 세부 기능2"
git commit -m "기능1 개발 완료"
# Github 리포지토리로 푸시합니다.
git push origin feat/todo
# Github에서 Pull Request를 합니다.
아래 스크린샷에서 유명한 오픈소스 toast UI의 pull request와 코드 리뷰를 참고하실 수 있습니다.
브랜치 삭제하기 (git branch -d)
머지된 feature 브랜치는 이미 dev 브랜치에 기록이 완벽하게 남아있기 때문에 굳이 남겨둘 이유가 없어 삭제를 권장합니다. 원격 리포지토리에서 pull request가 성공적으로 마무리되면, 아래 스크린샷처럼 브랜치를 삭제하는 버튼을 눌러 쉽게 삭제할 수 있습니다.
로컬 리포지토리에서 브랜치 삭제는 git branch -d <브랜치명> 으로 할 수 있습니다.
git branch -d feat/todo
Git은 원활한 버전 관리를 위해서, 브랜치가 합쳐지지 않으면 삭제하지 못하도록 설정이 되어있습니다. 하지만 종종 다 만들지 못한 기능의 기록을 삭제하고 싶을 수 있습니다. 이 때 -D 옵션을 쓰면 삭제할 수 있습니다.
git branch -D feat/todo
다만, 머지되지 않은 브랜치 삭제는 버전 기록 시스템의 사용 목적과는 잘 맞지는 않습니다. 잘 못 만들었던 기능이지만, 해당 기능으로 돌아가고 싶을 수도 있기 때문에 돌아갈 여지를 만들어두는게 좋을 수도 있습니다. 이런 경우는 팀 및 회사 정책에 따르는 것을 권장합니다.
Chapter2-2. 프로젝트 Git flow 학습
브랜칭 전략
브랜칭 전략은 보다 효율적인 개발 프로젝트 코드 관리를 위해 브랜치의 종류를 나눠서 관리하는 전략을 말합니다. Git이 널리 퍼지게 되면서 몇몇 유명한 브랜칭 전략이 생겨나게 되는데, 그 중 가장 유명한 브랜칭 전략이 Git flow입니다.
Git flow
Git flow는 2010년 Vincent Driessen의 블로그 글로부터 시작되었고, 이후 많은 개발자의 사랑을 받아온 Git 브랜칭 전략입니다. Git flow는 대규모 개발 프로젝트를 제작하여 하나의 소프트웨어의 릴리즈 버전을 명확하게 나누고, 다양한 버전을 배포해야 하는 당시의 개발 환경과는 적합했지만, 빠르게 제작하고 배포하고 고객의 피드백을 받는 애자일한 개발 팀에 적용하기는 다소 복잡했습니다. 원문에도 아래와 같은 조언이 담겨있습니다.
Web apps are typically continuously delivered, not rolled back, and you don't have to support multiple versions of the software running in the wild. 웹 애플리케이션은 대개 보통 지속적으로 배포되고, 배포를 되돌일 일이 없다. 또한 여러 버전을 배포하지 않아도 된다.
This is not the class of software that I had in mind when I wrote the blog post 10 years ago. If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.
이런 소프트웨어(웹 애플리케이션)는 내가 2010년 작성했던 블로그에서 생각했던 타입의 소프트웨어가 아니다. 당신의 팀이 지속적 배포를 원한다면, Github flow와 같은 간단한 워크플로우 도입을 제안한다. 굳이 애써 git-flow를 우겨넣지 않아도 된다.
If, however, you are building software that is explicitly versioned, or if you need to support multiple versions of your software in the wild, then git-flow may still be as good of a fit to your team as it has been to people in the last 10 years. In that case, please read on. 만약 당신의 소프트웨어가 엄격한 버저닝이 필요하고, 여러 버전을 배포해야 하는 경우에는 git-flow는 당신의 팀에 잘 맞을 수 있고, 계속 읽어주길 바란다.
위 설명처럼, 주어지는 개발 현장의 상황에 맞게 Git flow를 정하는게 중요합니다. 당장 복잡한 Git flow가 필요 없는데, 애써서 Git flow를 복잡하게 만들 필요는 없습니다. 물론, 꼭 필요하다면 아래 Git flow를 써보는 것도 좋을겁니다. 상황에 맞게 팀원 간 논의가 필요한 부분입니다.
Simple Git flow
이에 “원조" Git flow에서 파생된 여러 Git flow가 있는데, 대표적인 Git flow는 Github flow, Gitlab flow가 있습니다. 우리는 위 Git flow를 단순화한 Simple Git flow를 제안합니다. Pre-Project에서는 가능하면 Simple Git flow에 맞게 진행해보고, 향후 Main-Project에서는 팀원 간 상의를 통해 적절한 Git flow를 정하시기 바랍니다.
핵심 브랜치
Simple Git flow는 중요 브랜치 두 개를 가지고 있습니다. main 브랜치와 dev 브랜치입니다.
main 브랜치
사용자에게 언제든 제품으로 출시할 수 있는 브랜치
main 브랜치는 사용자에게 언제든 배포할 수 있는 브랜치입니다. 회사에 따라서 master, prod, production등 다양하게 불립니다. “언제든 배포할 수 있다"의 의미는 회사 별로, 팀 별로 다를 수 있습니다. 다만, 최소한의 기준을 세워볼 수 있습니다.
- 대표적인 기능이 완성되었다.
- 기존 기획했던 레이아웃이나 전체적인 디자인이 얼추 완성되었다.
- 클라이언트, 서버, 데이터베이스가 공개된 웹에서 정상적으로 통신할 수 있다.
- 최소한의 보안이 마련되었다.
- [ ] 브라우저에서 개발 버전에서 사용하던 secret이나 유저의 비밀번호가 노출되는가?
- [ ] 유저의 기밀 정보 조회를 위해 인증 토큰, 세션이 꼭 필요한가?
이렇게 일정 기준을 충족했고, 핵심 기능이 완성되었으면 main 브랜치로 배포를 할 수 있습니다.
dev 브랜치
다음 버전 배포를 위한 "개발 중!" 브랜치
dev 브랜치는 다음 버전 배포를 위한 "개발 중!" 브랜치입니다. main 브랜치에서부터 브랜칭을 하는게 보통이며, 가능하면 프로젝트 팀원과 프론트엔드와 백엔드의 결과를 합쳐서 확인해볼 수 있을 정도로 준비가 되어야 합니다. CI/CD 파이프라인이 잘 구축되어 있다면 dev 브랜치의 코드도 배포를 해두고 수시로 확인할 수도 있습니다.
main 브랜치와 dev 브랜치는 Github 리포지토리에 늘 업데이트 되어있어야 하며, 팀원의 코드 리뷰를 받고 진행하는 것이 정석입니다. 엄밀한 코드 리뷰가 어렵다면, 같이 모여서 코드에 대해서 이야기를 나누고, 배포 상황을 점검하는 스텐드업 회의를 열어도 좋습니다. 너무 격식이 있을 필요는 없지만, 가능하면 모든 팀원이 확인 가능하게 “어떤 코드의 어디를 왜 이렇게 바꿨으면 좋겠다.”라는 코멘트를 Github Pull Request에 남기는 것을 권장합니다.
보조 브랜치
feature 브랜치
feature 브랜치는 기능 개발, 리펙토링, 문서 작업, 단순 오류 수정 등 다양한 작업을 기록하기 위한 브랜치입니다. 분류를 세세하게 나누기를 원하는 회사에서는 refactor, fix, docs, chore와 같이 세세하게 커밋 메시지나 브랜치 명에 prefix를 달기도 합니다. 아래는 feature 브랜치 이름과 커밋 메시지의 예시입니다. 더 많은 사례는 Conventional Commits 에 대해서 확인하실 수 있습니다.
hash (브랜치 명) 커밋 메시지
2f85eea (feat/create-todo) feat: Todo 추가 기능
2ad0805 (fix/var-name) fix: 변수 네이밍 컨벤션에 맞게 변수명 변경 (ismale => isMale)
e7ce3ad (refactor) refactor: 불필요한 for 루프 삭제
feature 브랜치는 보통 각 개인의 로컬 리포지토리에서 만들고 작업합니다. feature 브랜치는 기능 개발을 위한 브랜치이기 때문에 2명 이상 같이 작업하는 경우가 드물어서, 브랜치 생성이나 삭제에 대해서 너무 두려워 할 필요는 없습니다. 작은 기능이라도 브랜치를 새로 만들고, 자주 커밋하고, 자주 원격 Github 리포지토리에 push하여 팀원들과 결과를 공유하는 것이 바람직합니다. 개인 로컬 리포지토리에서 너무 오래 작업을 하다보면, 쉽게 발견할 수 있는 오류도 발견이 되지 않곤 합니다. 더 나은 코드를 위해 피드백 받는 것을 두려워하지 맙시다.
회사에 따라서 커밋 기록을 남기는 일반적인 rebase-and-merge, 기능마다 깔끔하게 커밋을 남기기를 원해서 커밋 기록을 정리하는 squash-and-merge등 다양한 merge 전략이 있습니다. 이번 Pre-Project에서는 squash-merge 전략을 사용해보고, Main-Project에서는 팀원간 상의를 통해 merge 전략을 세우길 바랍니다. 많은 경우 feature 브랜치는 머지하고 나서 삭제하지만, 복원해야 할 필요성이 있는 경우는 남겨두기도 합니다.
Framework 선택 및 개발환경 구성
프레임워크 선택 및 설치 (FE)
Chapter3-1. 개발환경 구성 (FE)
- 개념학습: 신규 프로젝트를 생성하면서 개발환경을 구성합니다.
Chapter3-2. 프레임워크 선택 및 설치 (FE)
- 튜토리얼: 실제 간단한 React 싱글 페이지 애플리케이션을 제작할 수 있는 준비를 해본다.
학습 목표
- 프로젝트를 위한 프론트엔드 개발환경을 정의하고 학습한다.
- 간단한 React 싱글 페이지 애플리케이션을 제작할 수 있는 준비를 할 수 있다.
Chapter3-1. 개발환경 구성 (FE)
본격적으로 프론트엔드 개발을 시작하기 전에 개발환경 구성을 위해서 필요한 기술 스택이 무엇인지 알아보겠습니다.
프론트엔드 개발은 독자적인 전문 영역으로 인정받은지 얼마 되지 않았고, 변화가 무궁무진한 분야입니다. 특히 JavaScript의 특유의 다재다능(versatile)함 때문에 선택할 수 있는 기술 스택의 조합도 많습니다. 다만, 처음 프론트엔드 개발을 학습하는 초심자에게 있어 이 다재다능함은 오히려 단점이 되기도 합니다. 특히 프론트엔드 개발자에게 아래와 같은 사례가 자주 발견됩니다.
- 하나의 프레임워크를 제대로 학습하지 못했는데, 다른 프레임워크를 어설프게 학습해서 둘 다 제대로 알지 못함
- 어떤 기술 스택을 사용할지 고민만 하다가 개발 기획을 제대로 시작하지도 못함
- 개발 프로젝트에 별로 필요하지 않은 과도한 기술 스택 설치
지금까지 학습한 프론트엔드 지식은 이미 신입 개발자로서 충분합니다. 이제 이 지식을 충분히 활용해 남은 기간 동안에는 실제 애플리케이션을 기획하고 제작하는데 더 많은 시간을 들여야 합니다.
수강생 여러분이 위와 같은 안타까운 사례 중 하나가 되지 않고, 애플리케이션 제작에 더 많은 고민을 할 수 있기를 바랍니다. 이에 꼭 정하고 시작해야 하는 필수 기술 스택과, 코스 내에서 학습한 것 이외에 필요 없는 기술 스택을 구분하여 제안합니다.
필수 항목
- Node.js
- Node.js 패키지 매니저
- 버전 관리 시스템 / 형상 관리 시스템 + 원격 리포지토리 서비스
- 프론트엔드 프레임워크(라이브러리)
- CSS
- CSS 프레임워크(라이브러리)
- CSS 네이밍 컨벤션
- Create React App
- 린터
Node.js
Node.js는 JavaScript를 브라우저를 벗어나 다양한 운영체제에서 실행할 수 있는 JavaScript 런타임입니다. Node.js 덕분에 JavaScript로도 백엔드 개발이 가능해졌고, 실제로 많은 회사에서 이미 Node.js로 백엔드 개발까지 진행하고 있습니다. 특히, 배포 전 개발 단계에서 JavaScript로 번들링이나 최적화 등 많은 개발 작업을 JavaScript로 할 수 있게 되었습니다. 다른 Node.js 오픈소스 소프트웨어와의 호환성 보장을 위해 Node.js LTS 버전 사용을 권장합니다.
패키지 매니저
패키지 매니저는 여러 소프트웨어를 한꺼번에 모아 설치, 업그레이드, 설정, 삭제 등을 할 수 있는 소프트웨어 툴입니다. Node.js에서 대표적인 패키지 매니저는 npm과 yarn입니다. 코스에서는 좀 더 역사가 오래된 npm으로 학습했지만, 무엇을 사용해도 무관합니다. 향후 Pre-Project, Main-Project에서도 팀원 간 합의 후 결정하기 바랍니다.
버전 관리 시스템 + 원격 리포지토리 서비스
버전 관리 시스템은 Git을 주로 사용하고, Github와 같은 원격 리포지토리 서비스도 함께 사용하는 추세입니다. Pre-Project, Main-Project에서는 버전 관리와 원격 리포지토리 서비스로 Git과 Github를 사용합니다.
프론트엔드 프레임워크
프론트엔드 프레임워크(라이브러리)는 코스에서 학습했고, 가장 널리 사용되는 React를 사용합니다. 코드스테이츠에서는 create-react-app에서 지원하는 최신 버전인 React 18 버전 사용을 권장합니다.
CSS
React에서 CSS를 적용하는 방법으로는 코스에서 일반 CSS파일을 import하는 방법과 CSS-in-JS 라이브러리인 Styled-Components를 사용하는 방법 두 가지를 학습했습니다. 다만, CSS는 개발자나 회사에서 적용하는 방법이 각기 다르기 때문에 어떤 방식이 더 우월한지 아닌지 구분하기가 어렵습니다. 아래 다양한 라이브러리를 소개하니, 각자 니즈에 맞게 사용하기를 권장합니다.
- CSS 네이밍 컨벤션
- BEM
- Utility-First (Tailwind,
Bootstrap)
- CSS 관리 방법
- CSS-in-JS 라이브러리를 사용하여 컴포넌트로 묶어 관리: Styled-Component, Emotion
- Utility-First CSS: Tailwind CSS,
Bootstrap - CSS 파일 따로 관리
- SASS 사용
UI 프레임워크 사용 (비추천): Material UI, Chakra UI, Radix UI- UI 프레임워크는 실제 개발에서 많이 사용하고, 개발 생산성에 도움이 됩니다. 다만, CSS를 충분히 학습할 수 없어서 Pre-Project, Main-Project에서의 사용은 추천하지 않습니다.
Create React App
Creat React App은 React 개발진이 쉽고 빠르게 React SPA를 개발할 수 있도록 여러 오픈소스를 묶어 제공하는 툴 체인입니다. 번들링이나 배포, 테스트를 위한 기본 설정이 모두 되어있기 때문에 개발 환경 설정을 큰 공을 들이지 않고 시작할 수 있어 Pre-Project, Main-Project에서 사용을 권장합니다.
린터
린터는 문법 에러나 코드 스타일 규칙에 맞지 않는 코드를 찾아주는 툴입니다. JavaScript에서는 eslint, prettier가 가장 유명하고 많이 쓰이는 툴입니다. FE 코드 베이스에서는 가능하면 FE 개발자 간 합의된 코드 스타일링 규칙을 사용하여 코드 변화를 최소화하고 가독성 높은 코드를 작성하도록 합니다.
- eslint
- prettier
선택 항목
선택 항목의 경우 필요가 없다고 판단하면 사용하지 않아도 좋습니다.
- HTTP 요청
- 상태 관리
- TypeScript
- 번들러
- 테스트 프레임워크
HTTP 요청
코스에서는 HTTP 요청을 위해 Fetch API를 학습했습니다. Fetch API로도 모든 API 요청/응답을 처리할 수 있지만, 여러 부가기능이 추가된 라이브러리를 사용하기도 합니다. 아래 중 어떤 방법을 사용해도 상관 없으나, FE 개발자 간 혼용하지 않고 하나만 사용합니다.
- Fetch API & isomorphic-fetch
- Axios
- React Query (TanStack Query)
- SWR
상태 관리
React의 props-drilling 문제 및 상태의 효율적인 관리를 위해서 다양한 라이브러리가 개발되었습니다. 아래 라이브러리 중 어떤 라이브러리를 사용해도 상관 없으나, FE 개발자 간 혼용하지 않고 하나만 사용합니다.
- Redux
- Recoil
- Zustand
- React Context API
- Mobx
TypeScript
JavaScript는 동적으로 타입이 정해지는 프로그래밍 언어입니다. 처음 학습할 때는 배워야 하는 지식의 양이 적어서 입문하기는 좋지만, 향후 개발이 고도화되면 될 수록 변수의 타입을 아예 정하거나, 타입 검사를 할 수 있는 툴이 필요해집니다. 그래서 TypeScript가 고안되었습니다. 정적 타입 언어처럼 사용할 수 있게 변수나 함수의 리턴값에 타입을 지정하여 해당 타입이 아니면 TypeScript를 JavaScript로 컴파일하지 않게 하고 에러를 내어 견고한 개발을 돕습니다. 다만, 일반 라이브러리와는 다르게 TypeScript는 초기 설정도 어렵고 학습에도 시간이 오래 걸립니다. Pre-Project에서는 사용을 권장하지 않고, Main-Project에서도 FE 개발자 간에 충분한 협의를 거치고 사용하는 것을 권장합니다.
번들러
React는 대부분의 경우 JSX로 작성하기 때문에 따로 JavaScript로 컴파일 하는 과정이 필요합니다. 또한, 쉽게 CSS를 import 할 수 있는데, 이 기능도 다른 라이브러리를 적용해서 가능했습니다. 코스에서는 이런 복잡함에서 벗어나기 위해 React 개발진에서 제공하는 create-react-app을 사용하여 쉽게 React 개발을 시작할 수 있었습니다. SPA를 제작한다면 create-react-app은 이미 충분히 좋은 툴이고, 굳이 다른 번들러를 사용하지 않아도 됩니다. 다만, 필요에 따라서 따로 번들링이 필요하다면 아래 번들러를 사용할 수 있습니다. 어떤 번들러를 사용해도 상관 없으나, FE 개발자 간 혼용하지 않고 하나만 사용합니다.
- webpack
- esbuild
- vite
- parcel
테스트 프레임워크
코스 과제에서는 create-react-app에 내장되어있는 Jest와 React Testing Library를 사용했습니다. 추후에 E2E 테스트를 위해서 Cypress를 추가하면 React에서 필요한 대부분의 테스트를 진행할 수 있습니다. 다만, 테스트 프레임워크는 익히는데 상당한 시간이 소요되고, 특히 프론트엔드 테스트 작성은 백엔드 테스트보다 난이도가 더 높기 때문에 Pre-Project나 Main-Project에서 사용을 권장하지는 않습니다.
- Jest, React Testing Library
- Cypress
Chapter3-2. 프레임워크 선택 및 설치 (FE)
이번 튜토리얼에서는 프로젝트 시작을 위해 기본적인 프레임워크를 설치해봅니다.
Create React App
create-react-app으로 Todo App 개발을 시작합니다.
npx create-react-app {원하는 디렉터리 경로}
Redux
Redux 공식문서의 Quick Start를 참고하여 create-react-app에 Redux를 추가하고 잘 작동하는지 확인합니다.
npm install @reduxjs/toolkit react-redux
Styled Component
Styled Component의 Getting Started를 참고하여 Styled Component를 추가합니다.
npm install --save styled-components
ESlint, Prettier
ESlint와 Prettier를 설치하고, React에서 ESlint를 사용할 수 있게 돕는 관련 플러그인을 설치합니다.
npm install -D eslint-plugin-import eslint-plugin-jsx-a11y eslint-plugin-react eslint-plugin-react-hooks eslint-plugin-prettier eslint-config-prettier
권장 .eslintrc.json , .prettierrc.json 설정을 적용합니다. 아래와 같이 새로운 파일 ( .eslintrc.json , .prettierrc.json) 을 생성하고, 아래 코드를 참고하여 기본 설정을 적용합니다.
// .eslintrc.json
{
"env": {
"browser": true,
"es2021": true
},
"extends": [
"eslint:recommended",
"plugin:react/recommended",
"plugin:import/recommended",
"plugin:jsx-a11y/recommended",
"plugin:prettier/recommended"
],
"parserOptions": {
"ecmaFeatures": {
"jsx": true
},
"ecmaVersion": "latest",
"sourceType": "module"
},
"rules": {
"react/react-in-jsx-scope": 0,
"react/jsx-uses-react": 0
}
}
// .prettierrc.json
{
"singleQuote": true
}
ESLint, Prettier VSCode Extention을 설치합니다. 아래 사진의 빨간 박스와 같이 생긴 버튼을 누르고, ESLint와 Prettier를 검색하여 설치합니다.
설정이 정상적으로 완료되면, 간단한 코드 스타일링도 코드 에러로 인식되어서 ESlint로 검사가 가능합니다. 에러가 있는 코드는 빨간색 물결 밑줄이 쳐집니다. 이후 VSCode 설정으로 이동하여 editor.codeActionsOnSave설정을 아래와 같이 조정하면, 저장할 때 마다 ESlint가 고칠 수 있는 에러와 코드 스타일링을 자동으로 고쳐주기 때문에 편리하게 개발할 수 있습니다.
아래와 같이 저장을 하면 코드의 오류나 잘못된 코드 스타일링을 찾아 자동으로 수정해줍니다. 향후에는 자신이 선호하는 린트 설정을 스스로 더 추가해나가길 바랍니다.
Todo App에 FE 프레임워크 적용
이번 과제는 간단한 Todo App을 만들기 위해 필요한 준비를 해봅니다. 학습했던 내용을 참고하여 과제를 진행해주세요.
Bare Minimum Requirement
- 직접 Github 리포지토리를 만들고, 아래 항목을 제작합니다.
- 아래 파일을 포함합니다.
- README.md
- .gitignore
- LICENSE
- Github Project 칸반
- Todo App을 직접 만든다고 생각하고 이슈, 마일스톤을 스스로 정해봅니다.
- Github Project 칸반을 만들고, 이슈와 마일스톤을 연결하고 칸반 뷰로 변경합니다
- Simple Git flow
- 직접 제작한 Github 리포지토리에 main, dev 브랜치를 만듭니다.
- dev 브랜치에서 main 브랜치로 Pull Request를 최소 1회 시도합니다.
- 아래 파일을 포함합니다.
- Create React App을 활용해 프론트엔드 개발에 유용한 프레임워크를 설치해봅니다.
- Styled-Component
- ESLint, Prettier
- npm run start 가 에러없이 시작하는 코드를 원격 main 브랜치로 push 합니다.
- 아래와 같이 npm run start 로 리액트 개발 서버가 켜져있는 브라우저 화면을 캡쳐합니다.
프레임워크 선택 및 설치 (BE)
Chapter4-1. 개발환경 구성
- 개념학습: 신규 프로젝트를 생성하면서 개발환경을 구성합니다.
Chapter4-2. 통합개발환경에서 Git 사용하기
- 개념학습: 통합개발환경에서 Git을 연결하여 사용 준비를 마칩니다.
학습 목표
- 프로젝트를 위한 백엔드 개발환경을 정의하고 학습한다.
- 구현된 코드를 Git으로 관리하기 위해 통합개발환경에서 Git과 연결하는 방법을 학습한다.
개발환경 구성
통합개발환경(Integrated Development Environment, IDE) 선택
통합개발환경의 결정은 매우 중요합니다. 운전자에 비유하자면 어떤 종류의 차를 운전할지, 어느 제조사의 차를 구매할지와 같은 개념입니다. 자동차에 따라 세금, 보험료, 옵션에 따른 운전자의 습관등이 변할 수 있는 것 처럼 개발자는 어떤 통합개발환경을 선택하는가에 따른 영향을 받게 됩니다. 실제로 팀 단위로 개발 업무를 진행하다보면 통합개발환경을 맞추고 개발을 진행하는 경우가 대부분입니다. 다만 어떤 통합개발환경이 더 좋은가에 대한 객관적인 답은 없습니다. 선택 요인은 개발자의 툴 학습 정도에 따른 생산성이나 기타 여러 요인들이 종합적으로 검토되기 때문입니다. 그러나 우리는 대부분 Jetbrains사의 IntelliJ를 사용해 왔으므로 앞으로 이 툴을 사용하여 프로젝트를 진행한다고 가정하겠습니다.
Jetbrains사의 IntelliJ는 상용 프로그램으로 최근 전세계적으로 많은 사용자를 모으고 있습니다. 이전까지는 무료로 제공되는 Eclipse를 많이 사용했으나 무료라는 강점 이외에 프로그램이 무겁고 개발에 따른 구현 항목이 많아지면 속도가 느려지는 등의 불만이 많았습니다. IntelliJ는 Eclipse의 여러 문제를 해결하고 더 강력한 사용 경험을 제공하며 개발자들에게 좋은 평을 얻고 있습니다. 물론 IntelliJ는 무료로 제공되기도 합니다. 무료로 제공되는 커뮤니티 버전은 학습 수준의 개발을 경험하는데 크게 무리가 없습니다. 다만, 상용 버전의 전체 기능을 제공하지 않으며 일부 제한된 기능만을 사용할 수 있습니다. 제조사 홈페이지에 유료 프로그램 사용에 대한 라이선스 정책이 자세하게 나와 있으므로 시간이 남을때 한번정도 방문하여 라이선스 플랜을 살펴보고 통합개발환경을 어떻게 제공하는지 알아보는 것도 좋습니다.
JDK(Java Development Kit) 선택
JDK는 자바 언어로 자바 프로그래밍을 할 수 있게하는 자바 개발 도구입니다. JDK를 설치하지 않으면 자바 언어로 개발 할 수 없습니다. 예전에는 이러한 JDK가 무료로 제공되었지만 Oracle 기업에서 JDK를 관리하면서 유료 도구로 전환되었습니다. 이에 전 세계 수많은 개발자를 비롯하여 자바 기반으로 개발된 시스템을 사용하는 기업이나 기관에서는 개발 및 유지보수에 대한 고민을 하기도 했습니다. 수익을 내는 상용 소프트웨어를 개발하는 기업이나 개발자는 유지보수의 편의성을 위해 유료 JDK를 구매하여 사용하지만 학습이나 소규모 자바 프로젝트를 경험할 라이트 유저에게는 부담스러운것이 사실입니다. 이에 OpenJDK라는 무료 버전의 자바 개발 도구가 제공되고 있으며 여러 벤더들이 있습니다.
<벤더별 OpenJDK 목록 - 출처 : Stackoverflow>
일반적으로 AdoptOpenJDK를 많이 사용합니다. 하지만 표준은 아니기 때문에 평소 자주 사용하거나 사용해 보고 싶은 벤더의 JDK를 선택해도 됩니다. JDK의 버전은 팀 별 기준을 맞추기 위해 11 버전으로 지정합니다. 그 이상의 버전 선택은 지양해주시고 11 버전이 마음에 들지 않는다면 최소 JDK 1.8 버전까지는 괜찮습니다. 하지만 기존 레거시 시스템을 유지보수 하거나 특별한 제약사항이 없으므로 11 버전으로 선택함을 권장합니다.
프레임워크(Framework) 선택
프레임워크는 이번 단원에서 크게 고민할 필요가 없습니다. Spring-boot를 선택합니다. 단, Spring-boot의 버전은 고민해 볼 필요가 있습니다. 이 부분 또한 JDK 버전과 마찬가지로 Spring-boot 2.7.1 버전으로 지정합니다.
빌드 방식 선택
최근 빌드 방식은 크게 두가지로 나뉩니다. Maven과 Gradle입니다. 우리는 이번 프로젝트에서 Gradle 방식으로 빌드를 하도록 하겠습니다. 프로젝트를 진행하다 보면 우리가 구현하는 코드 외에 많은 외부 라이브러리들을 참조해서 개발합니다. 이때 위와 같은 빌드 툴을 사용하지 않으면 외부 라이브러리들을 모두 직접 관리해야 하고 프로젝트 빌드 시에도 빌드에 대한 표준을 설정하여 빌드 해야 합니다. 이러한 툴을 사용하면 개발 속도를 높이고, 생산성을 증대시킬 수 있습니다.
이전에는 Ant라는 것을 많이 사용했지만 Maven이 Ant를 넘어서 더 많은 개발자들이 사용하게 되었습니다. 최근까지도 여전히 많은 시스템들은 Maven을 사용하고 있습니다. 그러나 우리가 Gradle을 선호하는 이유는 Maven보다 더 나은 점들이 분명히 존재하기 때문입니다. Maven은 빌드의 요소를 XML로 정의하고 있는데 XML은 사람의 시각에서 보기 편한 스타일이 아닙니다. 또한 여러 라이브러리들이 의존 관계를 형성하는데 이때도 어려움을 겪을 수 있습니다. 이에 반해 Gradle은 Groovy라는 것을 사용하기 때문에 동적인 빌드시에 여러 골치아픈 문제들을 Groovy 스크립트 등을 통해 해결할 수 있습니다. 그리고 무엇보다 처리 속도가 월등히 빠르기 때문에 최근들어 Gradle의 선호도가 매우 높습니다.
형상관리(Software Configuration Management) 방법 결정
Git과 같은 형상관리 방법을 사용하지 않으면 개발자는 개발을 진행함에 있어 여러가지 어려움을 경험하게 됩니다.
첫번째는 내가 개발중인 코드가 예상치 못한 사고로 인해 통째로 날아갈 수 있습니다. 최악의 상황이며 무조건 일어나서는 안될 경우입니다.
두번째는 버전 관리가 어려운 점입니다. 이전까지 잘 짜놓은 코드를 수정해야 할 일이 있을 수 있습니다. 한번에 완벽하게 수정이 완료된다면 문제 없지만 개발자도 사람이므로 좋지 못한 방향으로 수정될 수 있습니다. 이럴때 이전 버전의 코드로 돌아가야 할 일이 생길 수 있습니다. 형상관리 툴은 버져닝(버전관리)을 할 수 있기 때문에 단순히 소스 코드를 원격지에 백업해두는 용도 외에도 내 코드의 히스토리를 기록하여 원하는 버전으로 대체할 수 있는 강점이 있습니다.
세번째는 협업을 하기에 용이합니다. 작은 프로젝트라면 문제 없겠지만 규모가 큰 프로젝트를 진행한다면 개발자 혼자서 모든 것을 구현하는데 무리가 따를 수 있습니다. 따라서 여러 사람들이 함께 모여 하나의 큰 프로젝트를 협업하여 진행하는데, 소스코드가 중복되거나 혹은 같은 부분을 다르게 수정하여 소스 코드간에 ‘충돌' 현상이 발생할 수 있습니다. 또한 동일한 소스 코드의 업무별 분리와 취합이 힘들고 장소의 제약을 받을 확률도 매우 높습니다. 형상관리를 활용하면 이러한 문제를 해결할 수 있습니다. 여러 사람이 함께 공통의 코드를 관리하고 취합하며 용도별로 저장소를 구분하여 ‘충돌(Conflic)'과 ‘병합(Merge)'의 문제로부터 해방됩니다.
형상관리 서비스는 많은 제품이 있습니다. 우리가 잘 알고 있는 Git 외에도 이전에는 SVN이라는 형상관리 방식을 많이 사용했습니다. SVN은 아직까지도 많은 개발자와 기업에서 사용하고 있습니다. Git으로의 전환을 늦추는 이유는 비용과 시간을 고려한 업무 효율성 때문입니다. 하지만 우리는 새로운 프로젝트를 시작하기 때문에 SVN을 고집할 이유가 없습니다. Git은 또한 Github이라는 강력한 서비스를 통해 전 세계에서 가장 유명한 형상관리 서비스가 되었습니다. 따라서 우리는 Github을 통해 쉽게 관리할 수 있는 Git을 형상관리 방법으로 선택하도록 하겠습니다.
통합개발환경에서 Git 사용하기
(IntelliJ 기준) 테스트할 신규 프로젝트를 하나 생성합니다.
<신규 프로젝트 생성 후 의존 라이브러리 다운로드 중>
GitHub: Where the world builds software
Github 계정이 없다면 신규로 만들고 Github에 로그인하여 새로운 Repository를 만듭니다. 간단히 테스트 할 목적이므로 Public / Private 여부는 크게 상관 없습니다.
방금 생성한 Github repository의 주소가 나타납니다. 해당 주소를 복사하여 클립보드에 보관합니다.
<생성된 Github의 Repository 주소를 확인한다.>
다시 IntelliJ로 돌아와서 Preferences 화면을 엽니다. 그리고 Version Control > Github 항목으로 이동합니다.
그리고 상단의 + 버튼을 눌러 Log In Via Github를 선택하고 브라우저에 생성한 Github 계정으로 로그인하여 아래 그림과 같이 로그인한 계정이 등록되도록 합니다. (아래 이미지는 2개의 Github 계정이 등록된 것입니다. 하나의 계정을 등록하면 하나만 등록되는 것이 맞습니다.)
오픈된 IntelliJ의 프로젝트에서 VCS > Enable Version Control Integration 을 눌러 신규 생성한 프로젝트에 저장소를 연결합니다.
새 창에서 Git을 선택하고 OK를 누릅니다.
Git > Commit 을 선택하면 IntelliJ의 화면 구성이 변하고 Commit to main이라는 탭이 나타납니다. Github Repository에 최초의 소스코드를 등록할 예정이므로 프로젝트 생성시 만들어진 모든 파일들이 업로드 되어야 합니다. 따라서 Unversioned Files를 체크하여 Commit 대상을 모두 선택합니다.
이후 아래 ‘Commit Message’ 항목에 커밋 내용을 initial 이라고 적고 ‘Commit and Push’ 버튼을 눌러 Github Repository에 등록합니다.
Github 계정에는 연결되어 있지만 어떤 Repository에 연결할지는 설정하지 않았기 때문에 Commit and push 전 해당 프로젝트가 연결될 Repository를 지정해야 합니다. Define remote를 누르고 Github에서 생성한 Repository의 주소를 적습니다.
Repository가 연결되고 난 뒤 push 버튼을 눌러 원격지에 내보냅니다.
Github에 접속하여 신규로 생성한 Repository에 반영되었는지 확인합니다.
Todo App에 BE 프레임워크 적용
이번 과제는 간단한 Todo App을 만들기 위해 필요한 준비를 해봅니다. 학습했던 내용을 참고하여 과제를 진행해주세요.
Bare Minimum Requirement
- 직접 Github 리포지토리를 만들고, 아래 항목을 제작합니다.
- 아래 파일을 포함합니다.
- README.md
- .gitignore
- LICENSE
- Github Project 칸반
- Todo App을 직접 만든다고 생각하고 이슈, 마일스톤을 스스로 정해봅니다.
- Github Project 칸반을 만들고, 이슈와 마일스톤을 연결하고 칸반 뷰로 변경합니다
- Simple Git flow
- 직접 제작한 Github 리포지토리에 main, dev 브랜치를 만듭니다.
- dev 브랜치에서 main 브랜치로 Pull Request를 최소 1회 시도합니다.
- 아래 파일을 포함합니다.
- 신규 프로젝트를 생성하고 ‘To-do Application !’라는 문자열을 출력할 수 있는 간단한 API를 만들고, 원격 main 브랜치로 push 합니다.
- ‘To-do Application !’라는 문자열을 응답할 수 있는 개발 서버와 IDE가 켜져있는 화면을 캡쳐합니다. 아래는 예시입니다.