📌 목차
본 문서는 TECH!T BACK-END SCHOOL의 훈련생들의 프로젝트 온보딩을 위해 제공되는 문서입니다. 백엔드스쿨 내에서만 활용 가능하며 무단 복제 또는 유출시 법적 조치를 받을 수 있습니다.
<aside> 💡 본 문서는 KDT 백엔드 스쿨 5기의 훈련생 분들이 프로젝트를 진행하는데 필요한 기본적인 정보들을 담은 문서입니다.
꼼꼼히 살펴보아 주세요!
</aside>
일반적으로 프로젝트를 진행하는데 필요한 과정은 '기획', '설계', '구현', '개선'이라는 4가지 단계로 나눌 수 있으며,
개발 방법론에 따라 순차적으로 진행할 수도 있고, 일부 구간을 몇 번 씩 반복하여 진행할 수 있습니다.
본 문서에서는 프로젝트 진행 시 각 단계에서 해야 할 일들과 고려 사항들을 설명합니다.
기획 및 설계 단계에서는 아래와 같은 일을 수행합니다.
프로젝트를 진행하기에 4주는 생각보다 빠듯하기 때문에 만족스러운 취업을 위한 프로젝트를 진행하기 위해선 선택과 집중이 필요합니다.
팀의 역량과 일정에 따라 주제 선택을 자유롭게 할 수 있으나, 본인의 결과물을 통해 면접관들에게 어필할 수 있는 점을 얼마나 만들 수 있는 지 고려하여 전략을 짜는 것이 중요합니다.
<aside> ✅ [주제 선택 시 가장 중요하게 고려해야 할 사항] (택 1)
특히 기업의 면접관들은 ‘기술 사용의 넓이’ 보다 ‘경험의 깊이’에 더 주목하는 편입니다.
따라서 처음부터 다양한 아이디어나 기술을 접목 시키는 계획을 세우는 것 보다는,
간단한 주제를 기반으로 기본 기술들을 확실하게 활용하여 ‘백엔드 개발자’라면 알아야 할 지식(예. HTTP, RDB, NoSQL, API, Caching 등)에 대한 역량을 먼저 보여주고,
이후 팀의 역량이 허락된다면 프로젝트를 개선할 수 있는 기술들을 점진적으로 적용하는 방향으로 계획하는 것을 권장합니다.
팀원들과 논의하여 주제를 결정했다면, 만들어낸 결과물이 어떤 형태로 나와야 하는지(요구사항) 구체화해야 합니다.
요구사항을 도출할 때는 아래와 같은 질문들로 세부 사항을 정해갑니다.
회의를 하며 자유롭게 필요한 것들을 도출해낼 수 있겠지만, 논의한 내용들을 (어느 정도) 체계를 갖춰 정리하는 것도 필요합니다.
이 때 활용할 수 있는 방법으로 요구사항 명세서, 이벤트 스토밍, User Story 등을 들 수 있습니다.
각각의 방법에 대한 상세한 내용은 아래의 토글을 열어 확인할 수 있습니다.
처음부터 모든 요구사항을 빠짐 없이 도출하는 것은 현실적으로 불가능합니다.
따라서, 정한 주제의 가장 중요한 핵심 요구사항을 먼저 도출하고 개발을 진행하면서 기존의 요구사항을 점검하며 필요할 경우 추가하거나 수정하여 발전시켜 나가는 방법을 권장합니다.
또한, 도출해낸 요구사항은 이후 개발할 때 검증을 해야 하기 때문에 요구사항을 도출하면서 검증할 테스트 케이스도 함께 작성해야 합니다.
앞선 단계를 거치면서 해야 할 일들의 윤곽이 나오면 WBS를 작성하여 개발 일정 계획을 세울 수 있습니다.
<aside> ✅ WBS란, Work Breakdown Structure의 약자로 프로젝트 작업을 할 때 업무를 카테고리로 구분하고 각각의 카테고리는 세부적인 작업으로 나누어서 일정 및 진행 상황을 체크하는 기법이다.
</aside>
계획을 세울 때는 프로젝트의 큰 단계에 대한 일정을 세우고, 각 단계에서 팀 전체, 혹은 팀원 각 개인이 프로젝트 개발에 투자할 수 있는 시간이 얼마나 되는지 파악하고 공유하며 중간 마일스톤을 수립하고 업무를 분담합니다.
다만 개발을 하다 보면 예상하지 못한 기술적 문제가 발생하거나 기획이 수정되는 일이 빈번하기 때문에, 통상적으로 개발 일정은 이러한 예외 상황들을 겪어본 경험에 기반하여 산출합니다.
따라서 개발 경험이 적을수록 첫 예상 일정의 2배까지 설정해도 되며, 최소한의 핵심 기능을 최대한의 여유를 두고 개발하되, 개인의 역량과 열정에 따라 일정보다 작업을 빨리 완료했을 때 추가 기능 개발, 성능/아키텍처 개선을 진행하길 추천합니다.
기획과 설계를 모두 마치고 본격적인 개발에 들어가기에 앞서 팀 내 기본적인 규칙을 정하는 것이 좋습니다.
이 규칙은 같은 팀원들끼리 일하는 방식에 대한 합의, 결과물을 통해 간접적으로 남기는 커밋 메시지, 그리고 코드에 대한 규칙들도 포함될 수 있습니다.
이렇게 정해진 규칙들은 서로 협업 하는 중 불확실성을 줄이고, 의사소통을 하거나 결과물을 이해하는데 드는 시간을 줄일 수 있습니다.
프로젝트를 진행할 때 리소스는 팀원의 시간 뿐만 아니라 개발을 진행하면서 마주칠 수 있는 문제 상황 대비 이를 해결할 수 있는 역량까지 포함합니다.
따라서 프로젝트를 진행하면서 지속적으로 리소스를 관리하는 것이 가장 중요합니다. 이를 실천할 수 있는 대표적인 방법은 스탠드업 회의를 진행하는 것입니다.
<aside> ✅ 스탠드업 회의란, 매일 오전 또는 특정 시간을 정해 매일 이루어지는 짧은 회의입니다.
</aside>
개별 리소스 뿐만 아니라 프로젝트의 전반적인 진행 상황과 문제 상황들을 관리하는 것도 필요합니다.
이는 단순한 문서를 통해서 관리를 할 수도 있겠지만, 문서를 수정하는 공수가 들고 전체적인 상황을 한눈에 보기 어렵습니다.
따라서 프로젝트 관리를 위한 도구를 도입하여 기능 개발 업무와 이슈, 그리고 앞서 언급한 마일스톤까지 등록하여 체계적으로 관리하는 것을 권장합니다.
🤖 프로젝트/이슈 관리 도구 예시: Notion, Jira, Trello, Github …
각 도구에서는 수행해야 할 개별 업무를 업무의 유형과 상태에 따라 분류하여 프로젝트의 전반적인 업무 현황을 한눈에 파악할 수 있습니다.
👉🏻 프로젝트 관리와 관련하여 이미지와 참고자료를 보고싶다면 클릭해 보세요!
개발을 진행할 때에는 개발한 결과물이 기획 단계에서 도출해낸 요구사항에 부합하는지, 그리고 함께 작성한 테스트 케이스를 통과하는 지를 검증하면서 개발하게 됩니다.
이를 수작업으로 진행하는 방법도 있지만, 반복적으로 수행할 경우 시간이 오래 걸리고 휴먼 에러(Human Error)가 발생할 수 있는 여지가 있습니다.
따라서 시간이 조금 더 걸리더라도 애플리케이션 코드를 작성할 때 테스트 코드도 함께 작성해나가며 개발 중인 프로그램의 안정성을 점진적으로 확보해두는 것을 강력히 권장합니다.
코드를 작성하는 것 만큼이나 개발 문서를 작성하는 것도 중요합니다. 앞서 언급한 요구사항 정리, WBS(혹은 다른 차트), 그리고 회의록까지 프로젝트를 진행하며 만들어내는 다양한 문서들을 잘 정리해야 합니다.