[inter-face]프로젝트 기획 마무리 회고록 (1)

2024.11.1(금) 프로젝트 기획 1차 회의를 시작으로 기획한 프로젝트에 대해서 다시 한 번 짚고 넘어가고자 한다.

아직 프로젝트가 완벽하게 기획되었다고는 할 수 없지만, 할 수 있는 만큼 기획하였다. 추후 부족한 부분에 대해서는 개발을 진행하면서 수정하고 보완하고자 한다.

한달 동안 팀원들과 거의 평일 동안은 매일 조금씩이라도 프로젝트에 대해 회의하였던 것 같다. 그 과정에 대해서 정리해보겠다.

1. 프로젝트 방향성, 목적 확실히 하기.
2. 프로젝트 이름 정하기.
3. 프로젝트 진행 방식, git 규칙 정하기.
4. 요구사항 정리
5. 기술 스택 정하기(+근거)
6. ERD 그리기.
7. Figma 그리기.
8. 역할 분배

---

1. 프로젝트 방향성, 목적 확실히 하기.

각자 생각한 프로젝트의 방향성과 목적에 대해 이야기 해보았다.

• 기획 배경
  • 다수의 사람들이 모인 공간에서 서로를 소개하고 기억하는 것이 쉽지 않아서 팀 빌딩을 할 때 어려움을 겪을 수 있다.(우리는 이 어려움을 goorm deep dive 백엔드 1회차 첫 OT 날 50명이 모인 자리에서 경험하였다.)
  • 개발자가 자신을 소개하는 페이지로 사용되는 페이지가 너무 많아서 명확하게 어필하기 어렵다. (깃허브, 노션, 백준, 블로그 등등)
  • 개발과 관련하여 사람들이 추가적으로 관계 지속을 할 수 있는 사용하기 편한 서비스가 있으면 좋겠다.
• 목적
  • 단기간에 서로의 정보(프로젝트 경험, 기술 스택 등)을 파악하고 최선의 팀을 꾸릴 수 있게 한다.
  • 특정 이벤트 종료 후에도 채팅 및 라이브 방송을 통해서 지속적으로 연결을 유지할 수 있는 기능을 제공함으로써, 장기적 관계 형성이 가능하게 한다.
  • 사용자는 자신의 기술 스택, 프로젝트 경험, GitHub, 블로그 링크 등 자신을 표현할 수 있는 정보를 요약하여 디지털 명함을 제작하여 상대방에게 쉽게 어필할 수 있도록 한다.

개발 직군의 사람들이 서로를 확실히 인식하고 자신을 효과적으로 어필할 수 있는 특색 있는 디지털 명함 및 커뮤니티 서비스

 

---

 

2. 프로젝트 이름 정하기.

inter-face(인터-페이스)

인터페이스는 아래와 같이 정의한다.

- 전기 신호의 변환(變換)으로 중앙 처리 장치와 그 주변 장치를 서로 잇는 부분. 또는, 그 접속 장치.
- 키보드나 디스플레이 등처럼 사람과 컴퓨터를 연결하는 장치.

 

 

"inter-face" 서비스는 개발 직군의 사람들이 서로 연결되고 소통할 수 있는 접점이 되고자 하는 의미를 담고 있다.

이름에 포함된 "face"는 사람을 대표하는 중요한 요소로, 서비스 내에서 사용자가 자신의 정체성을 소개할 수 있는 명함의 역할을 상징한다. "inter"는 '사이'라는 뜻을 내포하며, 사람과 사람 사이의 관계와 연결을 강조한다.

또한, 이름 사이에 "-"를 추가함으로써, 'interface(인터페이스)'라는 기술적 개념과 사람 간의 상호작용을 의미하는 인간적 요소를 모두 포함한다.

 

---

 

3. 프로젝트 진행 방식, git 규칙 정하기.

우린 여러가지 기능을 구현하고, 빠르게 요구사항 변경에 맞추어 개발하기 위해 agile 기반 gitflow 방식으로 진행하기로 하였다.

우리팀에서는 코드와 프로젝트 관리는 jira, github를 통해 진행한다.

우리 팀이 사용할 깃 브랜치 전략은 Gitflow으로 정했다. (Gitflow는 기능 브랜치와 여러 기본 브랜치를 사용하는 대체 Git 브랜치 모델이다.) 각자 기간을 정하여 여러 기능을 개발하고 합치는 과정을 거쳐 점점 서비스 크기를 키워나갈 생각이기 때문에 gitflow가 적합할 것이라고 생각하였다.

기능 브랜치가 많이 생길 것이고, 병합하는 과정에서 충돌 관리는 정말 신경써서 해야할 것 같다. 그래서 짧은 주기로 기능을 개발하고 빠르게 병합하거나, develop 브랜치의 최신 상태를 정기적으로 feature 브랜치에 리베이스하여 충돌 최소화하는 것을 유의해야할 것 같다.

 

 

gitflow는 크게 main 브랜치가 있고, develop, feature 브랜치가 존재한다.

아래는 브랜치 관련 규칙에 대한 설명이다.

• 각 새로운 기능은 자체 브랜치(feature)에 있어야 하며, develop에서 시작한다. 기능이 완료되면 develop에 병합한다. 그리고 develop 브랜치를 main에 병합한다.

git checkout main
git checkout -b develop
git checkout -b feature_branch
# work happens on feature branch
git checkout develop
git merge feature_branch
git checkout main
git merge develop
git branch -d feature_branch

• release 브랜치는 develop 브랜치에서 릴리스에 필요한 기능을 충분히 확보하면(또는 미리 정해진 릴리스 날짜가 다가오면) 에서 분기를 포크한다. release 브랜치에서 다시 develop 분기를 만들면 다음 릴리스 주기가 시작되므로 이 지점 이후에는 새로운 기능을 추가할 수 없다. 
• “hotfix” 브랜치는 프로덕션 릴리스를 빠르게 패치하는 데 사용된다. 버그 수정을 위한 전담 개발 라인이 있으면 팀이 나머지 워크플로를 방해하거나 다음 릴리스 주기를 기다리지 않고도 문제를 해결할 수 있다. main 브랜치에서 따서 hotfix 브랜치를 만든 후, 수정하면 다시 main 브랜치에 병합하고, develop 브랜치에도 병합하고 삭제한다.

git checkout main
git checkout -b hotfix_branch
# work is done commits are added to the hotfix_branch
git checkout develop
git merge hotfix_branch
git checkout main
git merge hotfix_branch

 

Gitflow의 전반적인 흐름은 다음과 같다.

1. main으로부터 develop브랜치를 생성합니다.

2. develop으로부터 release브랜치를 생성합니다.

3. develop으로부터 Feature 브랜치를 생성합니다.

4. feature 가 완료되면 develop에 병합됩니다 .

5. release 브랜치가 완료되면 develop, main 에 병합합니다.

6. main에서 문제가 감지 되면 hotfix 브랜치를 생성합니다.

7. hotfix 수정이 완료되면 develop, main 에 병합니다.

 

또한, 애자일한 개발을 위하여 jira에서 스크럼을 통해서 진행한다.

스프린트는 팀이 일정량의 작업을 완료하는 시간이 정해진 짧은 기간입니다. 스프린트는 스크럼과 애자일 방법론의 핵심이며, 올바른 스프린트는 애자일 팀이 더 적은 수고를 통해 더 나은 소프트웨어를 제공하는 데 도움이 됩니다.
스크럼이란?
스크럼은 애자일(Agile) 소프트웨어 개발 방식의 한 프레임워크로, 팀 협업, 적응성, 반복적인 개발 주기를 중심으로 합니다.

 

• 스프린트: 일정 기간 동안 작업을 실행하는 주기.
• 데일리 스크럼: 매일 진행되는 15분 이내의 짧은 미팅.
• 스프린트 계획, 리뷰, 회고: 스프린트 내 주요 행사.

 

기능별로 스프린트를 정하고, 브랜치를 파서 진행할 예정이다.

또한 데일리 스크럼을 통해서 짧게 진행사항에 대해 말하는 시간을 가져서 문제가 발생한 상황에 대해 빨리 인지하고자 한다.

마지막으로, 스프린트가 끝나면 리뷰와 회고를 통해서 다음 단계가 더 원활하게 진행되도록 한다.

 

 

 

참고 

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

Gitflow Workflow | Atlassian Git Tutorial

https://www.atlassian.com/ko/agile/scrum

스크럼이란 무엇입니까? [+ 시작하는 방법] | Atlassian

 

 

이후에 요구 사항 정리, 기술스택 선택, erd, figma, 역할 분배에 대해서 이어서 설명하겠다!