[SECTION 5] <Final Project> 프로젝트 개요

# 학습 목표

• 팀 목표
  • 실무와 가까운 클라우드 아키텍처를 구현할 수 있다. (팀)
  • 실무의 커뮤니케이션과 흡사하게 롤플레잉을 통해 의뢰인으로부터 자세한 요구사항을 이끌어낼 수 있다. (팀/개인)
  • 클라우드 아키텍처에 대한 그림을 그리고 설명할 수 있다. (팀)
• 개인 목표
  
  • 실무의 커뮤니케이션과 흡사하게 롤플레잉을 통해 의뢰인으로부터 자세한 요구사항을 이끌어낼 수 있다. (팀/개인)
  • 낯선 기술스택과 요구사항에 대해서 스스로 학습하여 적용할 수 있다. (개인)
  • 구현의 디테일에 대한 질문을 받을 때 답변할 수 있다. (개인)

 

# 프로젝트 운영 기조

프로젝트 운영 기조 1: 요구사항 구체화

- 실무에서는 모든 요구사항이 구체적이지 않을 수 있으며 이때 요구되는 소프트 스킬이 존재

1. 첫 번째는, 요구사항의 목적을 확인하는 일
2. 두 번째는, 요구사항을 구체화하는 일
3. 세 번째는, 커다란 요구사항을 잘게 쪼개는 일

“시스템A → 시스템B로 가는 과정에서 메시지를 다른 시스템에도 전파하려면 SNS가 중간에 추가가 되어야 하겠군”
“이 부분의 빌드 자동화를 위해서는 CodeBuild나 GitHub Action을 써야겠군”

- 이러한 요구사항 구체화는 프로젝트의 성공과 실패를 결정짓는 중요한 단계임

- 또한 이러한 과정을 문서로 남겨서, 각자 개인의 커뮤니케이션 스킬에 대한 증거 자료로도 남길 수 있음

- 요구사항이 구체화되면, “멀고 버겁게만 느껴졌던 큰 문제”가 “여러 개의 작은 문제”가 됨. 이러한 “문제 쪼개기”는 엔지니어의 기본 소양이 되며 문제를 쉽게 푸는 지름길이 됨

 

프로젝트 운영 기조 2: 롤플레잉

1. 서로가 “CTO”(교육 엔지니어)와 “신입 클라우드 엔지니어”(수강생)라고 생각하고 커뮤니케이션
2. 의뢰인으로부터 디테일한 요구사항을 최대한 많이 이끌어내야 함
   • CTO는 요구사항을 세네 줄 정도로 전달하며 세부 내용에 대한 궁금증은 반드시 먼저 질문해야 함
3. 모르는 부분에 대해 스스로 공부하기를 바라나 한편으로는 적극적으로 질문하기를 기대
   • 어떤 이론적인 배경이 필요하면 안내가 가능하나 알만한 내용을 직접 가르쳐주지는 않을 것이며, 대신 각자의 이해를 확인하는 과정은 적극 지원
4. 한 문제에 대해 너무 오래 붙잡지 말 것
   • 회사는 결국 일이 되게 하는 것이 목적
   • 하루 이상 고민하는 문제가 있다면 그때가 바로 질문해야 하는 시기

 

프로젝트 운영 기조 3: 취업 시장에서의 스스로의 역량 증명

기업에서 요구하는 역량

• 기업이 요구하는 기술 스택을 프로젝트에서 구현하였는가
• 리눅스 환경에서 개발 및 운영 경험이 있는가
• AWS 환경에서 인프라 운영 경험이 있는가
• 컨테이너 기반의 서비스 운영 경험이 있는가

- 파이널 프로젝트는 위의 경험을 결과로 증명해내야 하며 이러한 것들은 앞서 언급한 요구사항 구체화를 통해 이뤄짐

- 파이널 프로젝트는 결과뿐만 아니라 과정 역시도 중요한 증명 도구라는 사실

• (git 사용 기록, 칸반 보드 사용 등과 같이) 프로젝트 기간 커뮤니케이션 스킬을 증명할 만한 기록이 있는가

- 이는 커밋한 코드가 각 개인 및 (코드를 리뷰한) 팀의 책임임을 의미

- 또한 제대로 git을 사용하고, 기록으로서의 의미가 있는지를 확인한다는 말이기도 함

- 코드 커밋이나 칸반 보드 사용도 전략적으로 하시길 바람

- 엔지니어는 파이널 프로젝트 곳곳에서 힌트를 드릴 수는 있어도, 구현에 있어서 직접적인 개입은 없으므로 이 시간을 통해 스스로의 역량을 시험하는 기회로 삼을 것

 

# 팀 발표 방식

목표

- (영업일 기준) 프로젝트 마감 D-2에는 팀 발표가 진행됨

- 이에 앞서 팀은 의뢰인의 요구사항을 바탕으로 클라우드 아키텍처를 구현해야 하며 발표 진행에 대한 롤 모델은 다음과 같음

AWS Korea Youtube - This is My Architecture (한국 고객 사례)

 

예시1: 직방 아키텍처 발표

예시2: 위버스 아키텍처 발표

 

발표에 포함해야 하는 내용

• 아키텍처를 통해서 달성하고자 하는 목표를 먼저 설명
• 고객의 시나리오를 기반으로 설명
• 아키텍처 중 “우리 모두가 알만한” 서비스에 대한 자세한 소개는 간략하게 이야기해도 좋으나 처음 써보는 서비스에 대해서는 디테일하게 설명할 것
• 서비스와 서비스 간의 연결의 의도를 설명하고, 어떤 데이터가 오고 가는지를 설명하는 것이 필요
• 필요하다면 코드를 설명해도 좋지만 코드가 주 발표 내용은 아님

 

# 개인 평가 방식

진행 방식

• 평가는 프로젝트 결과물과 기술 블로그 작성 내용을 바탕으로 한 인터뷰 형식으로 진행
• 결과물은 프로젝트 내용을 바탕으로 한 기술 블로그 작성 및 발행

기술블로그 작성에 포함해야 하는 내용

• 아키텍처 구성 중 가장 어려웠던 점
• 새롭게 알게 된 지식

 

# 프로젝트 마일스톤

날짜	일정 상세
Day 1	프로젝트 인트로
Day 1	프로젝트 주제 선정
Day 2 ~ 3	프로젝트 이해
Day 2 ~ 3	프로젝트 요구사항 정리 미팅 w/ CTO
Day 4	아키텍처 다이어그램 완성
Day 4	아키텍처 다이어그램 확인 및 점검 w/CTO
Day 5	AWS 요금 결재서 제출
Day 6 ~ 9	아키텍처 콘셉트 증명 및 구현
Day 8 ~ 9	프로젝트 요구사항 중간 미팅 w/CTO
Day 10	아키텍처 IaC 코드 구현
Day 11 ~ 12	아키텍처 구현 완료 및 팀 발표 준비
Day 13	팀 발표
Day 14 ~ 15	문서화 및 개인 평가