Hello
I'm Sung Ryul Cho

Skills & Expertise

My Work

• 

  2026.02 – 2026.04 · 4인 팀 · Backend

  DEKK

  다양한 패션 코디를 둘러보고, 마음에 드는 스타일을 모아 다른 사람과 함께 고를 수 있는 서비스입니다. 코디에 나온 상품은 판매 사이트로 이동해 구매할 수 있습니다.

  Java · Spring Boot · PostgreSQL · Redis

  담당 영역

  • 개인/공유 보관함과 링크 공유 기능 개발
  • 회원 관리 기능 인수 및 인증 구조 개선
  • 관리자 기능 개발 및 서버 배포

  문제 해결과 성과 보기

  인증 공통화로 정책의 중복 수정·누락 위험 축소

  문제

  회원 기능을 인수했을 때, 같은 인증 정책을 바꾸려면 사용자와 관리자 코드를 각각 수정해야 했습니다. 한쪽을 빠뜨리면 서로 다른 정책이 적용될 위험이 있었습니다.

  해결 방안 검토

  사용자와 관리자의 권한이 다르더라도, 같은 토큰 생성·검증 로직까지 따로 관리하면 동일한 정책을 반복해서 수정해야 합니다. 다만 중복을 줄이는 과정에서 권한 구분까지 없어져서는 안 됩니다. 따라서 권한 정보는 구분하고, 동일하게 동작해야 하는 토큰 처리만 공통화하기로 했습니다.

  해결·개선

  토큰 생성과 검증을 공통화해 공통 인증 정책의 수정 지점을 모았습니다.

  성과

  공통 토큰 정책을 한곳에서 수정하도록 통합해, 인증 정책의 일관성과 유지보수성을 높였습니다.

  • 인증 통합 PR ↗

  회원·보관함 분리로 변경 영향 범위 축소

  문제

  회원 코드가 가입·탈퇴에 필요한 보관함 처리를 직접 호출해, 보관함 처리 방식이 바뀌면 회원 코드도 함께 검토해야 했습니다.

  해결 방안 검토

  회원 코드에서 보관함 처리를 직접 호출하면 보관함의 변경이 회원 기능에 영향을 줍니다. 그렇다고 두 처리를 독립적으로 완료시키면 회원 처리만 성공하고 필요한 보관함 처리는 실패한 상태가 생길 수 있습니다. 따라서 호출 관계는 이벤트로 분리하되, 두 작업의 성공과 실패는 같은 트랜잭션으로 묶는 방식을 선택했습니다.

  해결·개선

  가입·탈퇴에 따른 보관함 처리는 이벤트 핸들러로 분리하고, 이벤트 처리는 기존 트랜잭션에 참여하도록 구성했습니다.

  성과

  보관함 처리 변경 시 회원 코드를 함께 수정해야 하는 의존성을 줄여, 기능별 유지보수성을 높였습니다.

  • 의존관계 개선 PR ↗

  동시 저장 요청의 중복과 보관함 용량 초과 제어

  문제

  여러 사용자가 같은 보관함에 동시에 저장하면, 각 요청이 모두 ‘아직 저장되지 않은 카드’ 또는 ‘50장 미만’이라고 판단할 수 있었습니다. 이 상태로 저장하면 같은 카드가 중복되거나 50장 제한을 넘을 위험이 있었습니다.

  해결 방안 검토

  카드별로 잠그면 서로 다른 카드의 동시 저장은 제어할 수 없어 보관함 단위의 잠금이 필요했습니다. 앞선 저장이 DB에 확정된 뒤 다음 요청이 카드 수와 중복 여부를 확인하도록, 트랜잭션 종료까지 잠금을 유지하기로 했습니다.

  해결·개선

  보관함 ID를 기준으로 Redisson 분산 락을 적용하고, 잠금을 획득한 요청만 별도 트랜잭션에서 저장 조건을 확인하도록 했습니다. 이미 있는 카드는 추가하지 않고, 50장에 도달한 보관함에는 새 카드 저장을 거절했습니다. DB 커밋 또는 롤백 후 잠금을 해제하도록 구성했습니다.

  성과

  동시 요청에 따른 중복 저장과 용량 초과를 제어해, 공동 보관함 데이터의 정합성을 높였습니다.

  • 동시 저장 제어 코드 ↗
  • 중복 저장 동시성 테스트 ↗

  보관함 미리보기에 필요한 카드만 조회하도록 개선

  문제

  보관함 목록에는 최신 카드 3장만 표시하지만, 전체 카드를 가져온 뒤 애플리케이션에서 정렬하고 3장을 골랐습니다. 저장된 카드가 많아질수록 화면에 쓰지 않는 데이터까지 가져와 처리해야 했습니다.

  해결 방안 검토

  서버의 정렬 방식을 개선하더라도 전체 카드 데이터를 가져오는 부담은 남습니다. 보관함마다 최신 3장만 필요하므로 DB에서 보관함별로 선별하는 방식을 선택했습니다. 전체 카드 수도 표시해야 하므로 기존 집계는 유지했습니다.

  해결·개선

  ROW_NUMBER 윈도 함수로 보관함별 최신 카드 3장만 조회하도록 변경했습니다. 서버의 전체 카드 정렬 코드를 제거하고, 선별된 카드를 보관함별로 묶어 기존 카드 수 집계 결과와 함께 응답하도록 했습니다.

  성과

  미리보기 정보를 유지하면서 불필요한 카드 조회와 서버 정렬을 줄여, 목록 조회에 필요한 데이터 처리 부담을 낮췄습니다.

  • 조회 쿼리 변경 ↗
  • 서비스 처리 변경 ↗

  배포 가이드 작성과 초기 오류 해결로 팀의 개발 기반 마련

  문제

  배포 환경 준비가 지연되고 초기 배포가 실패하면서, 팀이 개발한 기능을 서버에 반영하지 못했습니다. 팀원들이 각자 구현한 기능을 연동하고 확인하는 작업에도 차질이 생겼습니다.

  해결 방안 검토

  여러 설정이 연결되는 배포 작업을 나누어 진행하려면, 팀원이 전체 흐름과 단계별 작업 방법을 이해할 수 있어야 했습니다. 단순히 작업을 분담하기보다, 공통으로 참고할 배포 가이드를 먼저 마련하는 것이 필요하다고 판단했습니다.

  해결·개선

  팀원이 설계한 인프라를 바탕으로 GitHub Actions·S3·CodeDeploy를 연결하는 배포 가이드를 직접 작성해, 동료가 이를 따라 설정 작업에 참여할 수 있도록 했습니다. 진행 중 발생한 설정·배포 문제는 다음과 같이 해결했습니다.

  • 배포 중단: 프라이빗 서브넷의 서버에 접속해 중지된 CodeDeploy 에이전트를 실행하고, 재배포가 정상 완료되는 것을 확인했습니다.
  • 배포 스크립트 보완: 실행 중인 애플리케이션과 새 배포 파일을 올바르게 찾도록 스크립트를 수정했습니다.
  • 운영 설정 반영: GitHub Secrets로 운영 설정 파일을 생성하는 단계를 빌드 전으로 옮기고, JWT 유효기간 등 필요한 설정을 보완했습니다.

  성과

  배포 지연을 해소해 팀원들이 개발한 기능을 서버에서 함께 확인하고, 각자 맡은 기능 개발과 연동 작업에 집중할 수 있는 기반을 마련했습니다.

  • 팀 배포 구성 코드 ↗

  전체 GitHub 저장소 ↗
• 

  2025.12 – 2026.02 · 7인 팀 · Backend

  LearnFlow

  AI 요약으로 강의 내용을 미리 확인하고, 원하는 강의를 선택해 수강하며 학습 진도를 관리하는 온라인 학습 플랫폼입니다.

  Java · Spring Boot · MySQL · GCP

  담당 영역

  • 강의 승인부터 AI 요약 제공까지 서버 처리 구현
  • 수강생 리뷰와 강사 답글 기능 개발
  • 서버 배포 및 오류 추적 환경 구성

  문제 해결과 성과 보기

  강의 승인을 기다리게 하지 않는 AI 요약 작업 처리

  문제

  강의 승인과 AI 요약을 연결할 때, 관리자가 분석 완료까지 기다리는 상황과 승인된 강의의 분석 작업이 누락되는 상황을 피해야 했습니다.

  해결 방안 검토

  승인 요청 안에서 분석하면 관리자가 기다려야 하고, 승인 이후 별도로 호출하면 호출 실패 시 작업이 누락될 수 있었습니다. 승인 대기와 작업 누락 위험을 함께 줄이기 위해, 승인 정보와 작업 기록은 같은 트랜잭션으로 저장하고 실제 분석은 분리하는 Outbox 방식을 선택했습니다.

  해결·개선

  강의 승인과 영상별 분석 작업 등록을 하나의 트랜잭션으로 묶고, 분석 서버가 작업을 가져가 결과를 전달하는 API를 구현했습니다. 작업은 대기, 처리 중, 완료, 실패 상태로 관리하고 중복 등록을 제한했습니다.
  
  분석 서버가 실패를 알린 작업은 1분, 5분, 60분 뒤에 다시 가져갈 수 있도록 최대 3회의 재시도 기준을 마련했습니다.

  성과

  AI 분석과 승인을 분리해 관리자의 승인 대기 부담을 줄이고, 승인과 분석 작업을 함께 저장해 작업 연결의 안정성을 높였습니다.

  • 초기 AI 작업 처리 PR ↗

  리뷰마다 반복하던 작성자 정보 조회 개선

  문제

  리뷰 목록에 닉네임을 표시하려고 리뷰마다 회원 정보를 따로 조회했습니다. 같은 작성자의 정보도 반복해서 가져와, 리뷰가 늘어날수록 DB 조회가 함께 늘어나는 구조였습니다.

  해결 방안 검토

  줄여야 할 것은 리뷰 조회 자체가 아니라, 각 리뷰에 닉네임을 붙이면서 반복되는 회원 조회였습니다. 현재 페이지의 리뷰에서 필요한 작성자 ID를 모두 알 수 있으므로, 리뷰마다 회원을 조회하는 대신 작성자 ID를 모아 한꺼번에 조회하는 방식을 선택했습니다. 기존 페이지 처리를 바꾸지 않고도 같은 작성자의 정보를 여러 리뷰에서 재사용할 수 있기 때문입니다.

  해결·개선

  현재 페이지의 리뷰에서 작성자 ID를 모아 중복을 제거한 뒤 회원 정보를 일괄 조회했습니다. 조회 결과를 ID별 닉네임으로 연결해 각 리뷰의 응답을 구성했습니다.

  성과

  리뷰 10개 조회 처리 시간을 11.32ms에서 8.68ms로 약 23% 단축하고 SQL 실행을 24회에서 15회로 줄여, 수강 전 리뷰 확인에 필요한 서버 처리와 DB 조회 부담을 낮췄습니다.

  측정 조건: 로컬 환경 · 전체 리뷰 1만 개 · 작성자가 서로 다른 리뷰 10개 · 서비스·DB 처리 및 응답 객체 조립 구간 · 각 방식 120회씩 5회차 측정한 평균의 중앙값

  • 리뷰 조회 개선 PR ↗
  • 조회 처리 측정 기록 ↗

  배포 스크립트의 중복 실행 제거와 백업 관리

  문제

  배포 스크립트가 같은 애플리케이션의 실행을 중복으로 시도했습니다. 백업 파일에도 보관 기준이 없어 배포를 반복할수록 오래된 파일이 쌓였습니다.

  해결 방안 검토

  실행 명령을 하나로 줄이더라도 필요한 환경 설정은 빠짐없이 전달돼야 했습니다. 따라서 설정을 전달하는 명령을 기준으로 통합하기로 했습니다. 백업은 모두 보관하면 계속 쌓이고, 모두 삭제하면 이전 버전으로 복구할 수 없습니다. 그래서 복구에 사용할 최근 버전은 남기면서 보관 개수를 제한하는 기준을 선택했습니다.

  해결·개선

  중복된 실행 명령을 제거하고 필요한 설정을 전달하는 명령 하나로 통합했습니다. 백업은 최신 3개만 남기도록 오래된 파일을 정리하는 절차를 추가했습니다.

  성과

  중복 실행을 제거하고 백업을 최신 3개로 관리해, 배포 절차를 단순화하고 백업 파일 관리 부담을 줄였습니다.

  • 배포 스크립트 개선 PR ↗

  전체 GitHub 저장소 ↗
• 

  2026.01 · 3인 팀 · Backend & AI

  Vench AI

  말로 남긴 하루를 일기와 위로 문구로 정리하고, 지난 기록과 감정 통계를 확인할 수 있는 AI 일기 서비스입니다.

  Python · FastAPI · MySQL · llama.cpp

  담당 영역

  • 음성 인식, 감정 분석, 일기 생성 흐름 연동
  • 일기 기록과 누적 감정 통계 조회 API 개발
  • AI 처리 진행 상태와 서비스 이용 현황 제공

  문제 해결과 성과 보기

  AI 처리 단계 안내와 생성 실패 시 대체 결과 제공

  문제

  음성 인식부터 일기 생성까지 여러 단계를 거치는데, ‘처리 중’만 표시하면 사용자는 어디까지 진행됐는지 알 수 없었습니다. 본문이나 위로 문구 생성에 실패했을 때, 이미 인식한 원문까지 결과로 제공하지 못하는 상황도 피해야 했습니다.

  해결 방안 검토

  긴 AI 처리 중에도 접수 여부와 진행 단계를 확인할 수 있도록, 접수 응답과 실행을 분리하기로 했습니다. 후속 생성 단계의 예외로 전체를 실패 처리하면 이미 확보한 원문도 제공하지 못하므로, 해당 단계만 원문이나 기본 문구로 대체해 기록을 남기는 방식을 선택했습니다.

  해결·개선

  음성과 일기 정보를 저장한 뒤 HTTP 202 응답과 일기 ID를 먼저 반환하고, BackgroundTasks로 AI 처리를 이어갔습니다. 단계가 바뀔 때마다 진행 안내를 DB에 기록했습니다.
  
  일기 본문 생성 중 예외가 발생하면 인식한 원문을 사용하고, 제목과 위로 문구는 각각 본문 첫 줄과 기본 문구로 대체했습니다.

  성과

  처리 단계 안내로 사용자의 진행 상황 파악을 돕고, 본문 생성 실패 시에도 인식한 원문을 제공해 기록을 다시 작성해야 하는 부담을 줄였습니다.

  • 단계별 처리 코드 ↗
  • 생성 실패 대체 처리 코드 ↗

  음성 인식 오류에 대응한 전처리·모델 설정 변경

  문제

  일부 녹음에서 사용자가 말한 내용이 텍스트로 정확하게 변환되지 않았습니다. 당시 입력 처리는 파일 형식만 변환하고, 녹음 파일마다 다른 음량은 보정하지 않는 구조였습니다.

  해결 방안 검토

  인식 모델과 입력 음성 양쪽을 개선 대상으로 잡았습니다. 파일 형식을 맞춰도 음량 차이는 남기 때문에, 모델 설정 변경과 함께 음량 정규화를 추가하기로 했습니다.

  해결·개선

  기존 16kHz 모노 WAV 변환 과정에 음량 정규화를 추가했습니다. 인식 모델은 small에서 medium으로 변경하고, 이전 구간의 인식 결과를 다음 구간의 조건으로 사용하는 옵션을 껐습니다.

  성과

  음성 인식 전에 녹음 파일의 음량 편차를 줄였습니다.

  • 음성 입력 처리 개선 내역 ↗

  대표 감정 하나만 집계하던 통계 개선

  문제

  한 일기에 기쁨과 슬픔이 함께 분석돼도 통계에는 대표 감정 하나만 집계됐습니다. 저장된 다른 감정 점수가 빠져, 사용자는 분석된 감정 분포를 통계에서 확인할 수 없었습니다.

  해결 방안 검토

  대표 감정별 일기 수를 세면 한 일기에서 함께 분석된 다른 감정은 통계에 반영되지 않습니다. 대표 감정뿐 아니라 함께 분석된 감정도 보여주기 위해 감정별 점수를 합산하는 방식을 선택하고, 리포트와 운영 대시보드의 집계 기준을 맞췄습니다.

  해결·개선

  처리가 완료된 일기의 감정별 점수를 합산하고, 집계 값이 없는 감정은 0으로 표시했습니다. 리포트 API와 운영 대시보드를 동일한 점수 누적 방식으로 맞췄습니다.

  성과

  대표 감정 외의 점수도 집계해, 사용자가 기록에 함께 나타난 여러 감정의 분포를 파악하도록 개선했습니다.

  • 감정 통계 개선 내역 ↗

  전체 GitHub 저장소 ↗

Education & Qualifications