About Me

소통으로 문제를 찾고, 설계로 해결합니다.

안녕하세요, 공유하는 백엔드 개발자 윤종석입니다.

저는 문제나 버그를 마주했을 때, 현 상황을 빠르게, 구조적으로, 팀원들과 공유하는 것이 가장 중요하다고 생각합니다.

팀 프로젝트를 진행하면서 문제가 발생했을 때, 단순히 스스로 해결하는 데 그치지 않고, 문제를 구조적으로 분석하고 핵심 원인을 시각화하여 도식과 키워드로 정리해 팀원들에게 설명해왔습니다.

특히, 각자 다른 컴포넌트를 개발하는 환경에서는 팀원 간의 정보 격차가 더 큰 문제를 만들 수 있고, 통합과정에서 병목현상을 일으킬 수 있기 때문에, 공유 중심의 협업이 프로젝트 완성도를 좌우한다고 믿습니다.

앞으로도 팀과 함께 일할 때, 기술뿐 아니라 명확한 커뮤니케이션과 책임 있는 공유 문화로 신뢰받는 백엔드 개발자로 성장하고 싶습니다.

윤종석

📞  +82-10-2070-1339

✉️  [email protected]

github: https://github.com/AidenY915

Project

0909

공동구매 웹 서비스 개발 2025

온라인 공동구매 서비스 개발

(2025)

프로젝트 설명

공동구매를 통해 상품을 판매 및 구매할 수 있는 플랫폼을 구축했습니다.

본 프로젝트는 MSA 아키텍처 기반으로 설계되었고, 인증/인가, 상품 추천, 주문·포인트·정산 등 다양한 도메인을 분리하여 운영했습니다.

저는 주로 인증/인가, 회원 도메인 관리, RAG 기반 추천 시스템 개발을 담당했습니다.

시스템 아키텍쳐

주요 개발 내용

1) 인증/인가 아키텍처 설계 및 구현

• Spring Security + JWT 기반 인증 구조
• 인증 인가 중앙화 - Gateway에서 모든 인증 인가를 처리
  • 각 서비스에 산재하는 인증 인가 로직의 통일성을 확보하고, 하나의 지점에서 관련 코드를 관리 → 소스 코드 유지 보수성 향상
• 인가 규칙을 동적으로 관리하기 위해 DB 기반 라우팅/Role 매핑 구조 설계
  • 각 API별 권한이 변경되어도 서비스를 재배포하지 않기 위함 → 정책 변경 시에도 서비스 가용성 확보
• Google OAuth2 로그인 기능 구현
• 내부 API에 대한 외부 접근 차단
  • 최초에는 내부 API는 별도의 문자열로 구성된 내부 토큰을 사용해 외부에서의 내부 API로의 접근을 차단
    • 장점:
      • 일관되게 gateway를 통하므로, 각 서비스 간 의존성 감소
    • 단점:
      • 내부 통신 시마다, 문자열 검증에 의한 오버헤드 발생
      • 각 서비스마다 환경 변수로 내부 API 키를 관리해줘야 함
  • 개선:
    1. EC2 인스턴스들을 하나의 VPC로 묶어서 외부 네트워크로의 유출 차단
       • 외부 백본을 통하지 않으므로, 스니핑 차단
    2. 각 서비스 pod들을 ClusterIP 설정함으로써, 외부의 진입점 차단 + 게이트웨이의 내부 API 매핑 제거
    3. 각 서비스들은 게이트웨이를 거치지 않고 직접 통신
    • 장점:
      • 통신 시마다 문자열 검증 오버헤드 제거
      • 게이트웨이 부하 감소
    • 단점:
      • 하나의 서비스에서 다른 서비스의 IP로 직접 요청을 보내므로, 의존성 증가
    • 변경 이유: 호출 시, 엔드포인트에 대한 정보가 필요하므로, 어느 정도의 의존성은 불가피하며, 5~6개 정도의 서비스 레벨에서는 충분히 관리할 수 있다고 판단

2) RAG 기반 개인화 추천 기능

• 상품의 설명을 기반으로 각 상품들을 임베딩하고 벡터를 저장
• 사용자의 좋아요 및 주문 내역을 기반으로 기존 상품 벡터들을 이용하여 사용자의 선호 상품 벡터를 계산하고 저장
  • 개인 사용자의 선호 상품 벡터는 관련 상품들의 가중평균벡터이다.
• Elasticsearch 벡터 인덱스 기반 유사도 검색
• Spring AI를 활용한 RAG 추천 파이프라인 구성
• 고비용 연산 이슈로 인해 개인 벡터 갱신을 1일 1회 배치 작업으로 전환
  • 문제 : 단일 개인 선호 상품 벡터 생성 시, 수십 건의 단일 사용자 정보 조회 쿼리가 발생
    • 모든 주문 내역과, 좋아요 내역과 연관된, 공동 구매 상품 및, 상품 벡터를 조회해야하기 때문
    • 로그인 시 개인 선호 상품 벡터 생성 시, API 서버의 실시간 부하 증가
  • 해결: 개인 선호 상품 벡터 갱신을 배치로 분리하고 트래픽이 적은 야간에 일괄 시행하여, 서버 안정성 확보
• 캐싱을 통한 추천 검색 시간적 비용적 소요 감소
  • 캐싱 이유:
    • 외부 LLM을 호출하는 추천 검색 특성상, 4 ~ 5초 가량 소요되므로 사용자 경험 저하
    • 매 추천 검색마다 LLM API 호출에 의한 토큰 비용 발생
  • 캐싱 방법:
    • 추천 검색 시, 결과를 redis에 캐싱
    • 추천 검색 시, redis에 캐싱된 검색 정보가 있는 경우, 추천 검색을 실시하지 않고, redis의 정보를 조회
• 장애 격리를 위한 서비스 분리
  • 외부 LLM을 호출하는 도메인 특성상, 예상치 못한 장애가 발생할 수 있으며, 비교적 시간 소요가 큼
  • 별도의 흐름을 갖는 추천 검색 로직을 별도의 서비스로 분리하여 장애 격리를 수행하고, 주문이나 결제와 같은 핵심 비즈니스 로직의 안정성을 확보

3) 분산 트랜잭션에 대한 보상 트랜잭션 설계

• 분산 트랜잭션 발생 지점:
• 서비스가 분리되어 있어 단일 트랜잭션 적용이 불가
• 보상 트랜잭션 적용
• 결과: 부분 실패 시 전체 실패로 전파해 일관성과 데이터 정합성 유지

기술 스택

• Backend: Spring Cloud, Spring Security, Spring Boot, java17, Spring batch, postgresSQL, Elastic-search, Spring AI, Kafka, google OAuth2
• infra : kubernates, github action

Github : https://github.com/AidenY915/0909_BE

Skill