[목표]
14주차 발표를 진행합니다.
아마존 내용을 정리합니다.
아이디어 회의를 합니다.
코치님과 아이디어 관련 이야기를 합니다.
시놀로지 배정
21시에 발표자료 작성
아마존 크래딧 IAM 설정
GPT 등 팀 AI 사용 여부
담당자 선정(기능별은 하겠지만, 신경 분산체계를 위함이다.)
일정 관리
10:00 ~ 12:00
14주차 발표를 진행합니다.
SSR과 CSR → 서버사이드 렌더링은 서버 자원을 많이 사용한다.
12:00 ~ 13:00
식사를 했습니다.
코치님 한마디
관점을 바꿔야한다.
기능구현이 관점이 되어야한다. 학습은 기능 구현을 위해서 학습을 한다는 느낌으로 가야한다.
발표자료 재제출 완료
14주차 배포 전체 구성 구조
저의 시놀로지 배포 순서를 정리해보았습니다.
[사용자 브라우저]
↓ ([https://yourdomain.com](https://yourdomain.com/))
[Web Station or Reverse Proxy (nginx)]
↓
[React App (정적 파일, Port 3000)]
↓ API 요청
[Spring Boot API 서버 (Port 8080)]
↓ DB 접근
[MySQL 컨테이너 (Port 3306)]전체 동작 로직 요약
1. 사용자가 웹사이트 접속
- 브라우저에서
https://securebigserver.synology.me으로 접속 - Web Station 또는 nginx가 Reverse Proxy 역할 수행
- React 앱의 정적 HTML/CSS/JS 파일이 서빙됨
2. React 앱이 초기 화면을 렌더링
- React 앱은 프론트엔드 로직 실행
- API 요청이 필요한 경우 (예: 로그인, 게시글 목록 불러오기 등)
axios.get("/api/posts")
3. API 요청 → /api 경로를 Web Station이 Spring으로 전달
- Web Station(또는 nginx)은
/api/*경로를localhost:8080의 Spring Boot 서버로 프록시
4. Spring Boot가 API 요청 처리
/api/posts→@RestController가 처리- 내부 로직에서 DB 조회:
List<Post> posts = postRepository.findAll(); - JSON 형태로 결과 반환
5. React가 API 응답 받아 화면 업데이트
axios.get()으로 받아온 데이터를useState()등으로 렌더링- 사용자에게 최신 화면 표시
6. Spring → MySQL DB 연결
- Spring Boot는
application.properties또는.yml을 통해 MySQL에 연결:
spring.datasource.url=jdbc:mysql://mysql-db:3306/mydb
spring.datasource.username=user
spring.datasource.password=pass- Docker 내부에서
mysql-db는 컨테이너 이름 (Docker network로 통신됨)
HTTPS 처리 로직
- 외부에서 HTTPS 접속 → DSM의 Web Station 또는 nginx가 인증서 적용
- React에서 API 요청 시
https://yourdomain.com/api/...로 요청하므로 CORS 문제 없음 - 보안 연결 상태 유지됨
한 줄 요약
사용자가 HTTPS로 접속 → React 앱이 실행 → Spring API 호출 → MySQL에서 데이터 조회 → React가 결과 렌더링 → 전체 HTTPS로 암호화된 안전한 통신
예시 파일 흐름
| 구성 | 위치 | 역할 |
|---|---|---|
| React 앱 | /frontend/build → nginx에서 서빙 | UI |
| Spring Boot | /backend/target/app.jar → 컨테이너에서 실행 | API |
| MySQL | Docker 내부 | 데이터 저장소 |
| Reverse Proxy | Web Station 또는 nginx | HTTPS 처리 및 경로 연결 |
CORS란?
CORS는 Cross-Origin Resource Sharing의 약자입니다.
즉, 다른 출처(도메인, 포트, 프로토콜)의 리소스를 웹 브라우저에서 요청하는 것을 허용할지 정하는 보안 정책입니다.
상황(예시)
React 프론트엔드가 https://myfrontend.com:3000에 배포되어 있고, Spring 백엔드가 https://myapi.com:8080에 배포되어 있다고 해보겠습니다.
이때 React가 Spring API로 데이터를 가져오려고 하면:
fetch("https://myapi.com:8080/api/posts")이 요청은 다른 출처(Cross-Origin)로 보내는 요청입니다. 그래서 브라우저는 보안상 자동으로 막습니다.
필요한 이유
웹 브라우저는 보안을 위해 다음 조건이 다르면 “다른 출처”로 간주합니다.
| 조건 | 예시 |
|---|---|
| 도메인이 다르면 | example.com ≠ api.example.com |
| 포트가 다르면 | 3000 ≠ 8080 |
| 프로토콜이 다르면 | http ≠ https |
다른 출처에 요청을 하려면, 서버(SPRING)가 "이 출처의 요청은 허용한다"는 것을 명시적으로 밝혀야 합니다.
그게 바로 CORS 설정입니다.
요약
CORS는 내 웹사이트가 다른 도메인의 서버에 요청할 수 있도록 서버 측에서 허락해주는 보안 규칙입니다.
나만무 발제 (12:00 ~ 13:00)
매일 팀원들이랑 스크럼을 해야한다.
이번주 총 3번 발표한다.
- 내일 기획 발표 (오후 1시부터 3시까지 306호에서)(팀별로 2~3개씩)
- 다음주에 프리뷰 (다음주 월요일 1시부터)(아이디어 1개 또는 2개)
- 아이디어 최종전 발표 (다음주 수요일 10시에 발표)
→ 추후 추가 공지 예정
→ 아키텍처(보류 가능), 기술적 챌린지(보류 가능), 인트로, 시연, 데모, 마무리.
데모를 하지 않을거면, 아키텍처와 기술적 챌린지를 조금 잘 써야한다. 템플릿은 꼭 모두 안채워도 된다.
데모가 없으면 다른 팀이 이해할 수 있을정도로 설명해야한다.
아키텍처는 기획단계에서 시간을 쏟지 않기.
발표시간은 정확하게 지켜야한다. 최종발표를 위해서 하는것이다. 접미어나 말투, 지식들을 모두 피드백해줄 것이다.
다른 팀이랑 아이디어가 겹치면 이야기 해서 합의를 보던가, 시점이 다르면 그냥 진행해도된다.
역할군
기술 스택 별로 나누는 수평보다, 기능별로 구현하는(풀스택) 수직적인 역할 분배가 좋을 것 같다.
일정
1주차: 주제 선정 및 기획
2,3주차: MVP
4,5 주차: 폴리싱(리팩토링), 발표 준비, 동영상 만들기, 사실상 개발 못하는 기간이다.
최종발표회: 7월26일 토요일
이전기수 사례집은 참고해서 사용하자. 리더는 크레딧이 있지만 IAM 계정을 통해 모두 쓸 수 있도록 하자.
11월31일 까지는 크래딧이 유지된다.
정글 컴퍼스 내용 잘 확인하기.
KDT 교육을 증빙하기 위해 요구사항은 모두 들어가야한다.
아이디어 관련: 기술적으로 매력적인 아이디어야한다. 게임도 가능하지만 추천하진 않는다.
정글 캠퍼스를 빠지지말고 정확하게 읽어보기.
마지막에 포스터를 제작을 할것이다. 포스터는 마지막주차에 인쇄업체에 보낸다.
오후 1시부터 오후 10시까지는 교육장에서 있어야한다. 코칭실이나 2층 못감.
멘토 매칭 예정, 다음주에 멘토의 선택으로 매칭된다. 나만무는 미니프로젝트랑 비교해서 규모나 기술적 규모를 생각해보기. 미니프로젝트에 몇배의 퀄리티가 요구될것 같다.
컴퍼스에 주제선정, 기획 관련된 제출 링크가 있는데, 그것들을 제출해야한다. 1차는 오늘, 2차는 최종적으로 1개만 선정 및 멘토 선정(1차 기반)할 예정.
13:00 ~ 15:20
나만무가 본격적으로 시작함에 따라 자리를 바꾸고 전체적인 정리를 했다.
15시 20분에 있을 코치님 아이디어 피드백을 위해 팀원들의 아이디어를 종합하고 각자의 아이디어를 설명했다.
15:20 ~ 15:40
설명하고 피드백 받느라 시간이 정신없이 지나갔다.
15:40 ~ 16:30
총 다음과 같은 9개의 아이디어가 있었습니다.
- 트러블 슈팅 기록기
블라인드형 에브리타임해킹 정보 서비스건강 식단 및 운동 분석 서비스게임 리뷰 커뮤니티구독 목록 조회 사이트면접 정보 포털 사이트투자 가계부- 한국의 타베로그
코치님의 엔지니어링적으로 특출난 아이디어를 기준으로 팀 주제를 두개로 설정했다.
위의 아이디어중에 두가지의 아이디어로 진행하기로 했다. 그래서 현재 아이디어 알고리즘 구현 방법에 대해서 고민(자료 탐색)을 해보고있다. 자세한 내용은 나만무 노션 참고
- 유윤선 코치님 아이디어 피드백
유윤선 코치님 아이디어 피드백[6.19]
나만무 프로젝트의 의미
엔지니어링 실력이 있다. 를 알려주기 위함이다. 코치님의 우선순위는 다음과 같다.
1. 엔지니어링적으로 특출남을 원한다.
2. 서비스적으로 재밌거나 풍성한것을 만들자.
본격적인 아이디어 피드백
사실대로 말하자면 별로인건 다음과 같다.
해킹정보, 블라인드, 게임리뷰 커뮤니티, 면접정보 → 정보만을 보여주기 때문에 2순위이다.
엔지니어링적으로 좋은것은 다음 주제이다.
이슈트레킹시스템: (간단히 → 어떻게? 기록을 하게 해줄 것인가?) 엔지니어링적으로
1~4주차에 알고리즘을 짜봤고, 그걸로 해결. 기술적인 설득으로 왜 빠른지 필요하다.
건강 식단: 이것도 정보전달 그이상도 아니라고 생각한다. 뭔가 더 다른 무언가가 있어야한다. 개인화나 CRUD로 느껴진다. 식단정보와 운동정보에 둘의 조합을 엔지니어링을 통해 의미있는 정보를 전달할 수 있는 서비스를 제공해야한다.
구독목록 조회사이트: 목록을 API로 받아와야함에는 기술적인건 있지만 어떻게 참신하게 정보를 받아와야한다. 구독목록을 가져와야한다. 시청 시간을 분석해서 구독의 정보데이터 분석쪽으로 의미가 있지않을까…
맛집 리뷰: 우리가 사업하는게 아니기 때문에 나만무를 하는건 상황가정을 하는 것이다. 꼭 실제 데이터가 아니어도된다. 데이터가 충분하다고 가정해서 분석과 가정을 통해 좋은 데이터를 가져오는 것도 좋을 것 같다.
→ 리뷰의 신뢰성을 어떻게 찾을 것인가? 사람마다의 신뢰성을 어떻게 판단을 할 것인가?
16:30 ~ 18:00
나는 지금까지 이야기한 것들을 노션에 정리하고 알고리즘을 구상하기 위해 검색을 해보았다.
18:00 ~ 19:20
식사로 개풍냉면이라는 식당을 갔다왔습니다. 더운데 시원한거 먹으니 좋습니다…
19:20 ~ 20:20
클로바 노트를 공유하여 코치님의 생각을 분석해보았습니다. 효과적인 의사소통과 파일공유를 위해서 시놀로지 시스템에 모든 팀원의 계정을 추가했습니다.
회의록 내용을 추가했습니다.
20:20 ~ 22:00
22시 회의전에 트러블슈팅 기록 서비스에 대한 로직과 알고리즘 기획을 잡아봤다.
22:00 ~ 23:30
회의를 진행하면서 지금까지 진행한 아이디어 구체화에 대해서 두 아이디어를 설명했다. 여러가지 피드백을 통해서 프로젝트 기획읜 완성도를 조금더 올렸다.
23:30 ~ 02:30
아이디어 정리 템플릿을 작성하면서 지금까지의 아이디어를 정리하고 설명을 달았다.
PPT 또한 작성하면서 발표자료를 구상하고 있다.
아이디어 정리 템플릿에 두 아이디어에 관련된 내용을 정리했습니다.
최종 정리된 초안 내용은 다음과 같습니다.
간편한 트러블슈팅 기록기
GitHub 커밋 기반 코드 변경 이력을 추적하고, 중요도를 계산해 AI 분석을 거친 뒤, 자동으로 트러블슈팅 문서를 Markdown 또는 Notion 형식으로 생성하는 서비스.
기획 배경
착안된 이유는 정글에 있으면서 트러블슈팅을 기록해야 의미있는 경험이되기도하고 팀원이 참고할 수 있는데, 개발한다고 정리할 시간이 많이 없습니다. 그래서 트러블 슈팅내용을 깃허브 커밋 내역을 통해 간편하게 처리를 해주는 서비스를 구상하게 됐습니다. 기존의 Jira같은 이슈트래킹 시스템은 있지만 프로젝트에 도입하기엔 사용법도 어렵고, 라이트하게 트러블슈팅을 자동 문서화해주는 서비스는 없는것으로 알고 있습니다. 그래서 자동화된 트러블 슈팅 기록 서비스를 만들고 싶습니다.
상세설명(로직)
먼저 트러블슈팅을 하면서 커밋을 충실히 합니다. 커밋 메시지를 디테일하게 적으면 정확도가 올라가서 좋습니다. 가중치 알고리즘을 통해 코드들의 중요도와 // 로 시작하는 주석에 대해서 추가적인 가중치를 부여합니다. (기술적 챌린지) 또한 확장자 파일, 예를 들어 css, html등의 형식을 확인하여 프론트엔드 부분인지, 벡엔드 부분인지 판단할 수 있습니다. 코드의 로직을 알기 위해 해당 가중치를 파일 변경 내역인 커밋 로그와 함께 LLM Ai를 통해 각 코드에 대한 분석만 수행합니다. 완료가 되면 Markdown Renderer와 Notion SDK를 통해 변환을 하여 사용자가 원하는 문서화를 해줍니다.
주요기능
- Git 연동을 통한 트러블슈팅 문서 자동화 기능(GitHub API)
- 사용자 입맛에 맞는 수정 내용 사용자화 기능
- LLM Ai를 통한 본인의 파일 변경내역 추적 기능
(GPT-4 API via OpenAI SDK) - 노션과 Github에 바로 문서화할 수 있게끔 두가지 형식 제공
(Markdown Renderer + Notion SDK 사용)
해당과정에서 Ai가 들어가는게 흠이긴하다.
기술적 챌린지
- 어떻게 로직을 구상할 것인지?
- 판단기준을 가름하는 알고리즘을 구현할 방법
- 전처리와 후처리를 어떻게 대응할 것인지.
→ 결과적으로 Jira 같은 헤비한 서비스가 아닌 어떤 개발자나 가볍게 사용하기 좋은 트러블슈팅 기록기를 만드는 것이다.
벤치마킹
Jira
흔히 업계 표준이라하는 트러블슈팅과 비슷한 이슈트래킹 시스템이 있다.
해당 프로그램의 문제는 헤비한다는것.
02:30 ~ 03:30
노션 내용 정리 및 PPT 발표 내용 설정을 했다.
너무나 피곤한 날이었다. 아까 아이디어 9개를 코치님께 설명하고 피드백을
