멘토링코드 리뷰 / 개발 진척 확인BEswagger I/F로 빼는 건 아주 좋아 보인다.toParam, from 같은 건 AOP(Argument Resolver) 제안FE스크린 리더 시나리오 - 장애인 입장) 매칭 게시글 목록 조회 ~ 채팅로그/모니터링성능 테스트 시 참고를 위해 중앙 모니터링(Prometheus, Grafana)은 구축 필요성능 테스트JMeter, K6, nGrinder 등 활용 부하테스트후기부족한 부분을 다시 한 번 확인할 수 있던 시간이었다. 개발, 인프라, 테스트까지 열심히 해야 겠다.

1. 중간발표 진행중간 발표의 기술 파트 발표자를 담당했다. 학생들과 멘토님의 피드백을 통해 한층 더 성장할 수 있는 시간이었다.2. 멘토링남은 일정에 대한 관리와 서비스의 부족한 부분에 대해 이야기하는 시간을 가졌다.3. 후기개발, ppt, 발표까지 바쁜 한 주였다. 남은 기간동안 열심히 해야겠다.

1. 인프라 아키텍처 구조멘토님 피드백현황: 현재 RDB를 논리적인 DB로만 분리하여 사용하고 있음. (단일 물리 서버)멘토님 피드백:RDB 서버를 논리적 분리를 넘어 물리적으로 여러 서버를 두어야 한다.주요 목적:나중에 부하 테스트 및 장애 복구 테스트를 위해 미리 RDB 리소스를 확보해야 한다.2. 요구 사항 기반 백로그 작성작업: 요구 사항 정의서 및 기능 정의서를 바탕으로 백로그를 상세하게 작성결과: 백로그를 작성하고 마감기한을 정함3. 후기이번 멘토링을 통해 인프라 아키텍처에 부족한 부분을 피드백을 받았고, 인프라의 전반적인 플로우를 잡을 수 있었다. 작성된 백로그와 마감기한을 철저히 준수하여 다음 단계 개발을 진행해야겠다.

멘토링을 통해 일주일간 진행한 내용에 대한 보고 및 피드백을 진행했으며, 서비스 플로우 다이어그램을 기반으로 기능적 흐름과 기술적 고민을 중점적으로 다루었습니다.결제 관련 피드백 및 조치환불: 환불의 기술적인 가능성을 검토할 필요성이 제기되었습니다.수수료: 수수료 관련 법적 자료를 확인해야 함을 피드백 받았습니다.채팅 기능 통일기존: 도우미 입장에서 게시글에는 채팅 기능이 없었으나 지도에서는 채팅 기능이 있었습니다.결정: 기능 통일을 위해 둘 다 채팅 기능이 없도록 통일했습니다.기술적인 고민 및 해결책피드백: 기존 채팅, 결제, 알림, 위변조 검증 외에 기술적으로 특별한 점이 부족하다는 피드백을 받았습니다.해결책: 우리 팀이 선택할 수 있는 최선으로 메시지 기반 백엔드 설계를 도입하여 기술적 깊이를 확보..

2025년 11월 15일 2차 멘토링 후 작성 후기입니다.기존 아이디어 보고멘토님께 팀 회의에서 정한 '대학교 캠퍼스 장애 - 도우미를 매칭할 수 있는 서비스/플랫폼" 아이디어를 말씀드렸다. 장애인 대학생으로 한정지으면, 대상 사용자가 너무 적어 서비스 규모적인 측면에서 문제가 있다고 의견을 주셨다.새로운 아이디에이션서비스 타겟을 장애인 대학생으로 한정하는 것이 아닌 전국 장애인으로 확장하는 방식으로 진행했다.처음에는 장애인/도우미 매칭 서비스 라는 큰 주제로 자유롭게 의견을 내는 방식으로 진행을 했다.서비스 플로우 정리아이디에이션 후 서비스 플로우를 대략적으로 정리했다. 느낀 점멘토님께 설명을 할 때 말로만 설명하는 것은 비효율적이라는 생각이 들었다. 시각적인 자료의 필요성을 느꼈고 다음 멘토링 때는 ..

2025년 11월 8일 공공 도메인 김홍철 멘토과의 멘토링에 대한 내용이다.주제 선정피그잼을 통하여 공공 도메인 관련된 여러 주제에 대한 고민하는 시간을 가졌다.여러 아이디어가 나왔고 주제의 방향성은 "청년 주거난 해결"에 대한 pain point를 해결하기 위한 서비스가 될 것 같다. 실제로 우리 팀이 해결할 수 있는 문제인지, 기술을 가지고 있는 지 앞으로 고민을 할 필요가 있다.서비스 이름 선정서비스 이름는 "비버"로 결정되었다. 비버는 집을 지을 때 집 짓는 위치 선정부터 건축까지 체계적으로 설계하는, 집 짓기에 진심인 동물이다. 청년들의 주거 문제에 대한 불안정성 및 고민을 해결할 수 있게 돕고자 "비버" 라는 이름을 빌렸다.후기프로젝트 기획(주제 선정 등) 하는 과정이 내가 좋아하는 분야가 아..

목표Spring Cloud Gateway 와 Spring Eureka 를 통해 MSA 환경 구축한다.과정Spring Cloud Gateway 리소스(프로퍼티) 설정 변경... routes: - id: user-route uri: lb://user-service predicates: - Path=/userseureka: client: register-with-eureka: true fetch-registry: true service-url: defaultZone: ${EUREKA_SERVICE_URL}docker compose 파일 변경 scg-proxy: image: lgcns-sc-gateway:1.2.4 ports: -..

목표스프링 게이트웨이를 활용한 MSA 환경을 구축해본다.과정nginx 서버를 유지한 상태로 spring 서버 두기스프링 서버 도커 이미지 준비도커파일FROM amazoncorretto:17-alpine AS builderWORKDIR /appCOPY gradlew ./COPY gradle ./gradleCOPY build.gradle settings.gradle ./RUN ./gradlew dependencies --no-daemon || trueCOPY src ./srcRUN ./gradlew clean bootJar -x test --no-daemonFROM amazoncorretto:17-alpineWORKDIR /appCOPY --from=builder /app/build/libs/*.jar ap..

목표게이트웨이(GW) 와 로드밸런서(LB)를 활용하여 무중단 배포(업데이트)를 실습한다.과정초기 구성 변경nginx-proxy 직접 배포 실습에서 뒷 단의 서버를 한 대에서 두 대로 늘린 후 해당 실습을 진행한다.nginx 설정 파일 변경upstream blog\_servs{ server awsgoo-blog-1:80; server awsgoo-blog-2:80; # 이 부분 추가 }도커 컴포즈 파일 변경deploy: mode: replicated replicas: 2 # 1에서 2로 변경현재 아키텍처 구성$ docker container lsCONTAINER ID IMAGE COMMAND CREATED STATUS ..

목표nginx-proxy 이미지 없이 docker compose 를 활용하여 직접 MSA 구성한다.과정docker compose 구성기존 docker compose 을 복사하기cp compose.yaml ../manual_lb/docker compose 파일 수정version: '3.8'name: awsgooservices:nginx-proxy: # image: nginx/nginx-proxy: 기존 이미지 제거 build: ../../docker_file/nginx # volumes: 도커 데몬과 통신할 수 있는 소켓 마운트 X -> 내가 직접 만든 이미지는 docker gen 의 프로그램이 없기 때문에 필요 없음 # - /var/run/docker.sock:/tmp/docker.sock:ro po..