[목표]
1차 공식 아이디어 발표회를 가집니다.
아마존 내용을 정리합니다.
아마존 크래딧 IAM 설정.
GPT 등 팀 AI 사용 여부.
담당자 선정(기능별은 하겠지만, 신경 분산체계를 위함이다.)
일정 관리.
10:30 ~ 11:30
운동을 하고 왔습니다.
11:30 ~ 12:00
어제 만든 나만무 주제범위 설문(엑셀파일)을 제출했습니다.
PPT에 깃허브 API 커밋 메시지를 가져올 수 있는 캡처를 추가했습니다.
PPT 내용을 복사하고, 맥북으로 옮겼습니다.
12:00 ~ 13:00
식사를 하고 숙소에 들렸다 왔습니다.
13:00 ~ 13:30
PPT 내용을 보강하고, 스크립트를 수정했습니다. 발표 전에 시뮬레이션을 돌려보았습니다. 5분정도의 시간이 걸립니다.
13:30 ~ 18:00
각 조 아이디어 발표회를 하는 시간을 가졌습니다.
각조의 아이디어를 살펴보고, 피드백을 가지는 시간을 가졌습니다.
1조
1안. 옷을 3D 렌더링해서 보여주는 사이트.
아바타를 가져왔고, 어느정도 가능하다고 보는가?
아바타를 생성해서 받을때까지 시간이 오래걸릴 것이다. 사용자의 액션과 아바타 생성과의 시간 간극을 어떻게 해소할 것인지 (동기화 이슈) 기술적 도전과제로 삼을 것. (지연처리를 어떻게 잘할 수 있을까?)
→ 이건 인스타그램 이론을 쓰면 되지 않나?
아바타를 설정하고 렌더링 생성 전까지 미리 렌더링 돌리고 그 사이의 극간을 더 줄이기 위해 추가적인 글쓰기 라던가, 사용자에게 추가적인 액션을 요구하면 좋을 것 같다.
개인화 데이터를 할 수 있는가? 개인별로 다른 정보들을 어떻게 보여줄 것인가?
3조
1안. 게임 트랜드 분석기
데이터를 잘 크롤링해서 잘 보여준다는 느낌이다. 추가적인 기능을 구현해야될 것 같다.
서비스의 양자체가 작은것 같다. 데이터를 CRUD해서 가져오는 느낌이다.
좀더 아이디어 구체화해야되겠다.
4조
1안. 케이크나 주문제작형 케이크 드로잉 서비스
케이크와 같은 업체에서 쓸 수 있는 드로잉 시스템
중개 플랫폼인지? → 중개 플랫폼이다. 마케팅도 들어가야하지 않나?
이게 돈이 되는 사업인가? → 잘 쓰는 사람이 없지 않는가?
배달의 민족을 쓰는 이유가 맛있는 집이 어딧는지 모르니까 쓰는 거 아닌가?
편리함적으로는 아닌것 같다.
기술적 챌리지가 없는 것 같다.
2안. 런닝 페이스 메이커
기존의 나이키 런과 같은 달리기 앱은 달성의 목적성이 거의 없다.
그래서 카트라이더의 과거의 자신과의 속도와 비교를 하면서 목적성을 부여한다.
봇과 사용자의 극간을 설정할 수 있다.
또한 제페토와 같은 캐릭터를 통해 과거의 나와 현재의 나를 AR와 같이 렌더링해서 같이 달리므로써 목적을 도달할 수 있도록 도와준다.
친구 기능이 있어서 다른 친구들과 경쟁할 수 있다. 응원 메시지나 음성을 보낼 수 있다.
풍부한 아이디어이고 도전해볼 과제가 많은 것 같다. 그러나 이걸 모두 구현할 수 있을지 의문이다.
재밌을 것 같지만, 기술적 우선순위를 정하는 것이 좋을 것 같다.
5조
1안. 여행 자동 기록 및 여행 커뮤니티
업로드 기준이 아닌 여행 시점을 기준으로 업로드, 선호도를 조사하여 개인화된 컨텐츠를 가져온다.
지도기반의 음식이나 관광지 추천 기능 제공.
다른 사람의 소통을 통해서 소통을 시작할 수 있다. 자연스러운 만남도 가능하다.
기술적 챌린지?
웹소켓을 통한 DM 기능 구현
추천 시스템 알고리즘 정립 필요
무한 스크롤 → 렌더링 시간을 최적화
위치 정보 공유
상대방을 소통하는 건 좋다. 그러나 상대방을 잘 모르기 때문에 어떻게 평가를 할건지? 내용추적이 필요할 것 같다. 명성이나 평판을 평가하여 다른 사람이 보여줄 수 있어야한다.
단순하게 지도를 표현하기보다 거리를 어떻게 빨리갈 수 있는가? 교통량 정보 등을 종합해서 알려주는 시스템을 추가하는게 좋을 것 같다. → 기술적 챌린지
2안. 음악 관련 플랫폼
음악 동아리를 어디서 찾는가? 뮤지션을 찾는데 어려움이 있다. 네이버 밴드나 캠퍼스 픽 같은 경우 패쇄적, 불친절하다. 음악 악기를 거래할 수 있다. 커뮤니티도 제공한다.
기술적 챌린지
릴스, 숏폼을 어떻게 구현할 것인가?
음악 악기 거래시 정보들을 종합하여 분류를 어떻게 할 것인지
→ 아이디어는 재밌으나, 음악에 대해 잘아야되지 않나… 데이터를 어떻게 정제할 것인가? 채팅은 어떻게 구현할 것인지. 서비스의 양이 좀 큰 것같다.
[Compute]
- Amazon EC2 : 완전 서버 환경
- AWS Lambda : 서버 없이 '서버리스' 방식으로 코드를 실행할 수 있는 서비스 (Amazon API Gateway 와 연동 필요)
- Amazon ECS/EKS : 서버가 아닌 '컨테이너' 기반의 워크로드를 배포하고, 관리해주는 서비스
[Storage]
- Amazon S3 : 다양한 파일을 저장할 수 있는 오브젝트 스토리지
[Database]
- Amazon Aurora : 관리형 MySQL 데이터베이스
- Amazon DynamoDB : 서버가 필요없는 NoSQL 데이터베이스
- Amazon ElastiCache : In-memory 데이터베이스
추가로, 필요로 하시는 기능들이 있다면, 정리해주시면 적합한 서비스를 알려들리수 있을것 같습니다.
2조: 커밋 기록 내용을 어떻게 유의미하게 데이터화할 수 있는가?
기존의 있던 깃허브 이슈가 있는데, 만들려던 문서가 비슷한 형식으로 나올지 우리의 서비스가 강점이 있을지 판단을 해서 경쟁력을 가질 수 있는지 확인해보기.
어떻게 구체화하고 구조화하고 어떻게 디벨롭할지? → 결과론적으로 체계적으로 카테고리화하기.
해당 아이디어에 대해 피드백이 나왔는데, ‘어떻게 해당 커밋 내역을 구체화하고 구조화할지. 디벨롭해주시고, 결과론적으로 체계적으로 카테고리화하거나 인덱싱하는 방법이 뭔가요’에 대해서 질문을 받았는데, 너는 어떻게 생각해?
코치님께 질문사항 추가하기
질문 사항
현업에서는 이슈라는 초점을 어떻게 두는지 알고 싶다. 코치님께서는 문제가 발생하고, 트러블 슈팅에 대한 기록을 깃허브 이슈나 Jira와 같은 서비스에 어떻게 작성하시는지 알고 싶습니다. 그러한 내용을 기반으로 더욱 자세하게 아이디어를 구체화하고 말씀하신것처럼 카테고리화할지 판단해보고 싶습니다.
어디에 가중치를 둬야한다고 생각하시는지?
프레임워크에 대한 고민. 대용량 트레픽을 관리하는데 유리한 Spring을 써보고 싶긴하다. 그대신 LLM 쓰는데 편하기 위해서 자바스크립트를 같이 쓸 것 같다.
깃허브 이슈와 비교
깃허브 이슈의 한계
| 항목 | 설명 |
|---|---|
| 🎯 목적 | 사용자가 명시적으로 작성하는 작업 항목 또는 버그 추적 |
| ✍️ 기록 방식 | 사람이 직접 입력 (이슈 생성, 템플릿 선택, 내용 입력) |
| 📌 사용 방식 | "앞으로 해야 할 일", 또는 "문제 발생 상황"을 수동으로 등록 |
| 📊 연계성 | PR, 커밋, 브랜치 등과 연결 가능하지만 자동 연결은 제한적 |
| 🚫 단점 | 반드시 사람이 이슈를 생성해야 함, 사소한 변경이나 디버깅 내용은 기록되지 않음, 이슈 제목/내용의 품질이 일정하지 않음, 커밋 변경의 맥락은 이슈에 반영되지 않음 |
GitHub Issues와 우리의 트러블슈팅 자동화의 비교
| 항목 | GitHub Issues | 당신의 시스템 |
|---|---|---|
| 생성 방식 | 수동 (사람이 작성) | 자동 (Git + 알고리즘 기반) |
| 내용 품질 | 불균형 (작성자 역량 의존) | 균일함 (포맷 + AI 요약) |
| 발생 시점 | 변경 이전 또는 중간 | 변경 이후에 정리 |
| 자동화 수준 | 낮음 (작성 중심) | 높음 (분석 중심) |
| 분석 범위 | 작업 단위 | 코드, 커밋, 파일 단위 |
| 트러블슈팅 문서화 | 수동 기록 필요 | 자동 생성 (AI + Diff 기반) |
18:00 ~ 18:30
숙소에 정리를 하러 갔다왔다.
18:30 ~ 19:00
식사를 하고 왔습니다.
19:00 ~ 20:45
일단 생각정리를 하면서 무엇을 해야할지 생각을 해보도록 하겠습니다. 아까전에 코치님이 하신말씀을 생각해보았습니다.
사실상 머리가 멍해서 정신이 없었습니다…
20:45 ~ 23:10
칠판에 코치님의 시나리오를 반영하여 작성하였습니다. 이후에 노션을 정리하고 지정해야될 것들에 대해 진행했습니다.
윤호형이 팀 프로젝트 DB 동기화를 위해 My SQL을 쓰고 싶다고 해서 연결했다.
노션의 문서 허브를 삭제하고 해당 내용을 프로젝트 페이지로 바꿔주었다.
오늘 PPT 내용은 보드에 정리 완료 했다.
23:10 ~ 00:20
코치님의 시나리오를 정리하고 있는데 생각보다 구체화하기 쉽지 않다.
흐름은 정리했으니 칠판에 작성해보겠다.
모든 내용을 정리했다. 나중에 팀원 컴펌 받으면서 보충할 예정이다.
00:20 ~ 01:00
진혁이 형이 만든 React 사이트를 다같이 살펴보았다. 깃허브 API(리포지트리, 리포 커밋 내역)를 가져와서 사용자가 보기 쉽게 출력해주는 사이트를 확인했다. 그냥 다 되는것 같다.
01:00 ~ 01:30
라면을 먹고 왔다. 배고픈데 먹을게 없다…
01:30 ~ 03:30
8기 월요일 기획 리뷰 2차에 대해 팀별 프로젝트 정보 시트에 업데이트 했다.
벨로그에 어제 내용을 간단 정리하여 올렸다.
진혁이 형이 완성한 깃허브 커밋 로그에 대한 GPT 피드백 서비스를 확인했다. 정상작동하고 그대로 데모모델로 보여줘도 손색이 없을 정도이다.
정글에서 제공해준 1000달러 크래딧을 계정에 등록했습니다. AWS IAM 계정을 생성하여 팀원들에게 공유했습니다. (팀 노션 통함)
특히나, 기존의 시놀로지를 운영했던 경험이 있어서 IAM 계정을 생성하고 사용자나 그룹별 권한을 부여하는데 능숙하게 해낼 수 있었습니다.
03:30 ~ 04:20
보드 판서를 보면서 변경사항이나 추가적인 의견에 대해 적었다.
담당자를 어떤 형식으로 나눌지 생각했다.
팀노션을 보면서 정글 컴퍼스와 일정을 정리해봤다.
