[에스넷시스템 부트캠프] TIL Day 49~51 - 프로젝트 기획

Day 49 - 팀 결성 & 주제 선정

자기소개 및 팀장/팀명 정하기 

오늘은 앞으로 한 달 반 동안 함께 프로젝트를 진행하게 될 팀원들과의 첫 만남이었다.

간단한 자기소개를 나누고, 팀명과 팀장을 정했다.

 

figma로 자기소개 적기

자기소개는 Figma를 활용하여 진행했다.

내가 이전에 참여한 프로젝트에서 PM, 디자이너, 개발자 모두가 Figma를 통해 브레인 스토밍을 진행했었는데, 

• 실시간 동기화
• 댓글 기능을 통한 피드백
• 넓은 작업 공간
• 다양한 컴포넌트와 시각화 요소

같은 기능들이 협업 생산성에 큰 도움이 되었다. 그런 경험을 바탕으로 이번에도 자기소개를 Figma로 해보자고 제안했고, 팀원들도 흔쾌히 동의해주었다. 앞으로의 브레인스토밍이나 기획에서도 유용하게 쓸 수 있을 것 같다. 

 

팀명은 다섯명의 MBTI가 모두 I형이라는 사실에 착안해 아이오아이(IOI)로 결정했다. 아이돌인가

팀장은 모두가 가능하다는 의견이 나와 사다리 타기로 공평하게 선정했다. 난 아님!

 

프로젝트 주제 선정

프로젝트 주제는 제공된 다섯 가지 중에서 선택했는데, 팀원들과의 논의를 거쳐 “Auto Scaling: 클라우드 PaaS 구축”을 선정했다. 사실 모두가 인프라 구축 경험이 없어서 이 주제가 조금 낯설게 느껴졌다. 나 또한 인프라에 대해 아는 부분은 있지만, 직접 구성해본 경험은 부족한 편이라 처음엔 막막함이 컸다.

 

그래도 지금까지 배운 것을 되짚어가며 큰 틀을 나눠봤다.
네트워크 구성, Auto Scaling, CI/CD, 보안, 모니터링 정도로 정리되었고, 그중에서도 네트워크와 Auto Scaling에 더 집중하기로 했다.

이야기를 나누다 보니, 단순히 기능을 구현하는 프로젝트가 아니라 아키텍처 설계 중심의 프로젝트가 될 것 같았다. 개발 중심의 프로젝트와는 또 다른 성격이라 새롭고 기대도 된다.

---

Day 50 - 서비스 기획 & 브레인스토밍

서비스 방향 리서치 

오늘은 본격적인 서비스 기획에 들어갔다. 우리 팀은 뉴스 플랫폼을 주제로 잡았다. 각자 어떤 형태로 서비스를 만들지 고민하고 리서치하는 시간을 가졌고, 나는 뉴스 데이터를 어떤 방식으로 가져올 것인지에 집중했다.

 

생각해본 수집 방식은 다음 3가지였다. : 

• 더미 데이터로만 구성
  • 인프라에만 집중 가능
  • 서비스가 단조로워서 기본적인 인프라만 구성 
• 크롤링을 통해 특정 뉴스 사이트에서 데이터 가져오기
  • 뉴스 사이트에서 크롤링 가능 여부 확인 필요
  • 구현 난이도가 높을 것으로 예상
• 네이버 API를 이용해 특정 키워드를 정해 뉴스 URL 리스트 보여주기
  • 네이버 API 하루 호출 최대 2.5만회
  • 뉴스 원문 대신 제목, 요약, URL 만 가져오는 형태
  • 인프라와 연결해서 운영하기에 안정적인 형태로 보임

이 중에서 네이버 API를 활용하는 방식이 가장 적합하다고 판단했다.

 

일정 및 협업 관리 

Jira

프로젝트 경험이 있는 나는 일정과 협업 관리를 위한 툴 사용을 제안했다.

가장 대표적인 Jira를 추천했다. 그 이유는 채용 공고에 협업 툴 부분에 Jira가 자주 나오기도 하고, 이전 소프티어 부트캠프에서 다른 프로젝트 팀이 Jira를 다루는 것을 보고 한 번 배워보고 싶었기 때문이다. 

팀원들도 내 제안에 동의하여 결론적으로 Jira를 사용하기로 했다. 

 

브레인 스토밍

브레인 스토밍 과정

 

역할도 정해지지 않았고, 주제도 막연하고, 인프라 관련 프로젝트 경험도 없고, 온라인 환경이다보니 회의 진행이 굉장히 더뎠다. 

나도 개인적으로만 리서치하고 있다가 더이상 진행이 늦어지면 안되겠다는 생각에 우선 내가 생각하고 있는 내용들을 Figma에 두서없이 적어봤다. 그렇게 적어내려가다 보니 팀원들도 하나씩 살을 덧붙이고 의견을 내주어서 조금씩 진행이 되었다. 

 

이렇게 브레인스토밍을 위해 여러 메시지 블록을 생성하여 적다보니 누가 쓴 글인지 인지하기 어렵다는 점을 발견했다.

그래서 각자만의 색을 정해 글 배경을 바꾸도록 제안했다. 나는 연한 보라색을 선택했다.

이렇게 색으로 관리하다보니 좀 더 눈에 띄고 누구에게 질문해야 할지가 명확해졌다.

Day 51 - 프로젝트 시나리오

이전 기수 프로젝트 분석 

이전 기수 프로젝트 분석

 

오늘은 진행이 느린 기획을 억지로 끌고 가기보다는, 전날 받은 이전 기수의 프로젝트 자료를 정리하는 데 집중했다.

특히 어떤 주제를 선택했고, 역할 분담은 어떻게 했는지를 중심으로 살펴보면서 우리 팀이 참고할 수 있는 기본 뼈대를 잡는 데 집중했다. 또 이전 프로젝트의 공통점들을 추려보며, 인프라 중심 프로젝트가 가져야 할 최소 단위의 구성 요소들을 감을 잡을 수 있었다.

 

하이브리드 시나리오 고려

하이브리드 클라우드

기존에 정한 주제에서는 온프레미스 환경이 빠져 있어 아쉽다는 생각이 들었다. 그래서 온프레미스와 클라우드를 함께 다루는 하이브리드 형태의 시나리오도 논의해봤다. 

 

이상적으로 생각하는 전체 시나리오는 다음과 같다. : 

1. 단순한 뉴스 페이지만 먼저 구성

    -> 서비스 초기에는 기본적인 웹 화면과 정적 데이터 제공

2. 외부 뉴스 수집 기능 추가

    -> 네이버 API 등을 활용해 데이터 수집

3. AI 요약 기능 도입

    -> AWS Bedrock 또는 직접 구축한 요약 서버 연동

 

다음 주 계획

다음주 계획

마무리로 다음주 계획을 간단하게 적고 끝!

 

주간 회고

이번주 Figma

 

원래는 매일매일 업로드하려고 했지만, 이번 주는 기획 단계라 작업량이 많지 않아 하나의 포스트로 정리하기로 했다.
이미 여러 번 경험해봤던 개발 프로젝트와는 달리, 인프라 중심의 프로젝트는 처음이라 낯설고 어렵게 느껴진다.
그렇지만 팀원들과 함께 고민하며 방향을 잡아가는 과정 자체가 의미 있고, 점차 익숙해지고 있다는 걸 느낀다.

 

이번 주를 통해 새삼 느낀 것은, “생각만 하지 말고 바로 기록하고 공유하자”는 것이다. 특히 기획 진행이 더딘 우리 팀에 가장 필요한 태도인 것 같다. 생각한 것을 정리 해볼 수 있고, 또 내 의견이 선택되지 않는다 하더라도 다른 팀원에게서 좋은 아이디어가 나오게 해주는 매개체가 될 수도 있다.

 

또 하나, 경험이 많다고 해서 내 방식만 고집하지 말자.
개발 경험을 바탕으로 아이디어를 낼 수는 있지만, 팀원과 함께 방향을 잡는 게 더 중요하다. 특히 어떤 걸 제안할 때는 다른 방법도 찾아보고 제안하는 습관을 갖자. 

 

Keep	Problem	Try
- 아이디어를 정리한 뒤 바로 Figma나 Slack에 공유하는 습관 유지하기	- 경험에서 오는 확신이 때로는 독단이 될 수 있음 -> 팀 의견 수렴 부족 가능성	- 제안할 때는 명확한 이유와 함께 설명하고, 다른 대안도 제시하기 - Jira 기능 공부해서 다음 주 업무에 적극 활용해보기

 

실은 사진 첨부하면서 내용이 다 날라갔다... 정말이지 이번엔 메모리도 충분했는 데 왜 ㅠㅠㅠㅠ 
방심하지 말자... 자주 자주 세이브하자....