1. 프로젝트 개요 (Project Overview)

날씨, 취향을 고려해 사용자가 보유한 의상 조합을 추천해주고, OOTD 피드, 팔로우 등의 소셜 기능을 갖춘 서비스 입니다.

2. 담당한 작업 (My Contributions)

• 기상청·카카오 API 연동으로 날씨·위치 조회 기능 구현
  • 좌표 → 행정구역 정보 변환을 Kakao Local API로 처리하고, 사용자 위/경도 기반 KMA Grid를 계산하도록 구현했습니다.
  • 기상청 단기예보 API에서 받은 MAP 데이터를 fcstDate+fcstTime 단위로 묶어 하늘상태/기온/강수 정보를 정규화했습니다.
  • 조회 시 최신 예보가 존재하지 않거나 필수 카테고리가 빠진 경우 사용자 친화적인 예외 메시지를 반환하도록 예외 처리했습니다.
• 피드 생성·관리 기능 구현
  • 피드 생성에서 작성자 권한 확인, 의상 소유 여부 검증, 날씨 참조 등을 모두 통합해 안전하게 저장하도록 만들었습니다.
  • /api/feeds 조회에 커서 기반 페이징, 정렬 옵션, 작성자 필터, 좋아요 상태 플래그 등을 지원해 클라이언트 요구 사항에 맞게 응답을 구성했습니다.
  • 피드 수정·삭제에 작성자 권한 검증을 추가해, 작성자가 아닌 사용자는 변경할 수 없도록 보호 로직을 구현했습니다.

3. 기술적 성과 (Technical Achievements)

• Spring Boot, JPA, QueryDSL, AOP, Lombok, MapStruct, PostgreSQL , Spring Batch , AWS , Google API, Kakao API 등 활용
• 날씨 조회에 Redis를 적용하여 평균 2s → 20 ms 로 대폭 감소

4. 문제점 및 해결 과정

사례 1. 피드 조회 시 컬렉션 fetch join 때문에 페이징이 깨졌던 문제

• S (상황)

  /api/feeds 목록 조회에 QueryDSL을 적용하면서 feed.feedClothes와 그 하위 의상/속성까지 한 번에 fetchJoin()했는데, 페이징(limit)을 걸면 Hibernate가 “컬렉션 fetch+페이징은 지원하지 않는다”고 경고하면서 결과가 중복되거나 예외가 터졌습니다.

• T (과제)

  커서 기반 페이징을 유지하면서도 작성자·의상 등의 연관 데이터를 안정적으로 조인해 내려야 하고, 클라이언트가 요구하는 필터(작성자, 날씨 조건 등)를 모두 적용해야 했습니다.

• A (행동)

  1차 쿼리에서는 조건·정렬·커서를 적용해 Feed ID만 limit+1개 조회하고, 2차 쿼리에서 그 ID들을 대상으로 필요한 연관만 fetch join하는 두 단계 방식으로 쿼리를 재작성했습니다. 동시에 작성자 필터까지 BooleanBuilder에 포함해 조건 누락을 막았습니다.

• R (결과)

  페이징이 안정적으로 동작하면서도 필요한 연관 데이터가 모두 내려오고, 작성자 필터를 사용하면 다른 사람 피드가 섞이지 않는다는 것을 Postman/실서버에서 확인했습니다.

사례 2. 기상청 예보 매핑 오류로 skyStatus가 항상 CLOUDY로 내려왔던 문제

• S (상황)

  /api/weathers 호출 결과에서 skyStatus가 어떤 좌표를 넣어도 항상 CLOUDY로 내려왔습니다. 피드 백엔드에서도 같은 날씨 데이터를 쓰기 때문에, 클라이언트가 “날씨가 전부 흐림으로 표시된다”고 제보했습니다.

• T (과제)

  기상청(단기예보) API 응답을 다시 분석해 SKY 카테고리가 정확히 매핑되도록 하고, 필수 항목(TMP, SKY, PTY, POP 등)이 누락되면 명확한 예외를 반환해야 했습니다.

• A (행동)

  예보 아이템을 (fcstDate + fcstTime)로 그룹핑하는 로직을 재작성해서, 각 카테고리가 올바른 그룹에 들어가도록 수정했습니다. 그리고 SKY, PTY 등이 빠진 경우엔 WeatherNoForecastException으로 명확한 오류 메시지를 내려주도록 예외 처리를 보강했습니다.

• R (결과)

  skyStatus가 CLEAR/MOSTLY_CLOUDY/CLOUDY 등 기상청 코드에 맞게 정상적으로 내려오는 것을 Postman과 프런트 화면에서 확인했습니다. 프런트 팀에서도 “날씨가 제대로 표시된다”고 확인해 주었고, 관련 문의가 더 이상 들어오지 않았습니다.