백엔드 개발자 박채린입니다.

빠르고 안정적인 API 개발로 사용자 경험을 향상시키는 데 집중합니다.

효율적인 데이터 처리와 최적화를 통해 높은 성능의 서비스를 제공하는 데 열정을 가지고 있습니다.

소통과 협력을 통해 팀원들과 함께 성장하며 성공적인 프로젝트를 이끄는 개발자입니다. 다양한 팀 프로젝트에서 팀장을 맡아 원활한 커뮤니케이션과 목표 달성에 중점을 두었습니다.

✉ alicx991117@naver.com

📞 010-2679-3482

💻 Github

📗 Velog

학력

동패고등학교(인문계)

2015.03~2018.02

상명대학교(서울) 컴퓨터과학과

2018.03~2023.08

  • 공학인증, AI 전공 트랙 이수
  • 학점 : 3.7/4.5

자격증

2021

2023

2024

2024

2025

네트워크관리사2급

SQLD

토익스피킹 IH(150)

토익 805

정보처리기사

CAREER

NC소프트

2022.05~2022.09

  • 소프트웨어중심대학 사업의 프로젝트 인턴십으로 재직하였습니다.
  • 파이썬을 이용한 문자 정규화를 통한 기계번역 QA를 담당하였습니다.
  • 아이돌 소통 플랫폼인 유니버스 관련 언어 정제 보조업무를 진행했습니다

소프트웨어 마에스트로 16기

2025.04~2025.11

  • 소프트웨어 마에스트로에서 아이돌 포토카드 교환 관련 플랫폼을 개발중입니다.
  • 팀원으로서, 전체적인 기획과 백엔드를 맡고있습니다.

리드마이사주

2026.01~

  • 리드 마이 사주에서 어플리케이션과 웹 개발을 풀스택으로 단독 개발자로 CTO를 담당하고 있습니다.
  • AWS 환경세팅과 전반적인 인프라를 담당중입니다.

프로젝트

💃아이돌 오프라인 포토카드 교환 플랫폼 DOTS

소프트웨어 마에스트로 프로젝트로서, 오프라인 행사장에서 포토카드 교환을 돕는 어플리케이션

개발기간: 2025.06~

Frontend 1명, Backend 2명 (* 7월부터 백엔드 1명이서 진행)

  • 링크 : https://duckonthespot.com
  • Apple, Android 어플 출시

성과

  • 최대 DAU 200명 이상
  • 현재까지 활성 사용자수 1200명 이상
  • 7/25~7/27 기간 포토카드 교환 등록 80명 이상

내가 기여한 부분

백엔드 : 50%

서버 배포 : 50%

기획 : 90%

회원 관련 API 제작

  • OAuth 로그인 구현
    • 각각 Google, Apple, X(구 TWITTER)의 로그인을 구현하였습니다.
    • Google 로그인은 Spring Framework를 이용하여 구현하였습니다.
    • Apple 로그인은 Apple OAuth의 jwt토큰 발급을 하여 요청하였습니다
    • X 로그인은 pkce를 이용하여 요청하였습니다
  • JWT
    • JWT 토큰을 이용하여 사용자 인증을 진행하였습니다.

채팅 Redis PUB/SUB 연결

  • 오토스케일링 다중서버 환경에서 웹소켓 통신간의 채팅 다중 서버 연결 문제를 해결하기위해 Redis PUB/SUB을 연결하였습니다
  • AWS ElastiCache Valkey 서버리스로 배포해 비용을 절감하였습니다.

파일 업로드 Presigned URL API 제작

  • AWS S3로 사진 파일을 올리기 위해 업로드가 가능한 링크를 프론트로 넘기는 API를 제작하였습니다

포토카드 교환 관련 API 제작

  • 포토카드 교환 등록 API
  • 사용자 위치 업데이트 API
  • MVP 버전에서 1:1 교환을 매칭해주었습니다.
    • 거리순, 그 다음 접속순으로 나열하여 매칭리스트를 나열합니다.
    • QueryDSL을 이용하여 복잡한 조회쿼리를 작성하였으며, MySQL이 지원해주는 거리 계산 함수를 사용하였습니다.

나눔 관련 API 제작

  • * 나눔이란 ? 아이돌 팬 문화중 팬이 직접 비공식 굿즈를 만들고 이를 무료로 다른 팬들에게 나눠주는 행위
  • 나눔 검색 API
    • QueryDSL을 이용한 AND LIKE 연산 확장방식
  • 나눔 좋아요 API

사용 기술

  • Kotlin + Spring
  • MySQL
  • AWS ECS로 오토스케일링 가능한 구조로 배포
  • 이외에도 AWS Valkey Serverless, RDS, VPC 등 사용

협업 방법

  • Jira로 작업을 스토리 단위로 나누고 스프린트를 관리함
  • 2주 단위로 계획-개발-리뷰를 반복하며 애자일하게 운영
  • 실제 사용자 피드백(“원문 보러가기” 기능 불편)을 바로 다음 스프린트에 반영해 개선

트러블 슈팅 1

⛔ 문제 배경

채팅 시스템에 Redis Pub/Sub을 적용하여 오토스케일링된 다중 서버 간 실시간 통신을 구현하는 과정에서, AWS Valkey Redis Serverless 환경에서 ERR unknown command 'psubscribe' 오류가 발생했습니다. 이는 해당 서비스에서 psubscribe 명령어를 지원하지 않아 기존의 패턴 기반 구독 방식이 동작하지 않는 문제였습니다.

💛 해결 방법

기존에는 채팅방별로 Redis 채널을 패턴 토픽 방식(psubscribe/ppublish)으로 구분해 관리했습니다. 그러나 Valkey 환경 제약을 고려하여 채널 토픽 단일화 전략으로 전환했습니다. 모든 메시지를 하나의 Redis 채널로 발행하고, 메시지에 채팅방 식별자 메타데이터를 포함시켜 백엔드 서버에서 적절한 WebSocket 채널로 라우팅하는 구조로 변경했습니다. 이를 통해 psubscribe 의존성을 제거하면서도 채팅방별 메시지 분리를 보장할 수 있었습니다.

🖥이전 코드와의 비교

변경 전 container.addMessageListener(chatMessageSubscriber, PatternTopic("chat:room:*")) 로 해당 패턴의 토픽을 모두 구독하고 있는 형태에서

변경 후 container.addMessageListener(chatMessageSubscriber, ChannelTopic("chatroom")) 단일 채널로 구독하고 있는 형태로 변경하였습니다.

또한 레디스에 보내주는 메시지에서 roomId를 꺼내와 알맞은 웹소캣 채널 룸에 메시지를 보내주었습니다.

💡해당 경험을 통해 알게 된 점

Redis Pub/Sub은 상황에 따라 패턴 기반 구독과 채널 단일화 방식 등 다양한 채널 전략을 선택할 수 있음을 깨달았습니다. 또한 Serverless 환경에서는 일부 명령어 제약과 같은 클라우드 특유의 제한사항이 존재하므로, 아키텍처를 설계할 때 이러한 제약을 사전에 고려해야 한다는 점을 배웠습니다. 이 경험을 통해 특정 기술에 종속되지 않고 환경 제약을 반영한 유연한 설계가 확장성과 안정성을 보장한다는 교훈을 얻을 수 있었습니다.

메인화면

콘서트 선택

교환 상대 목록

나눔 목록

나눔 좋아요

아티스트 선택

포토카드 선택

거래 채팅

거래 채팅 예약

나눔 검색

트러블 슈팅 2

⛔ 문제 배경

해당 콘서트 날짜에 해당되는 나눔을 받아오는 GET /api/fan-events/{fanevent_id}/giveaway API에 Query parameter을 추가하여 검색도 가능하게 만들려고 했습니다. 하지만 트위터에서 나눔을 검색하는 것보다 차별화되게 편한 것을 원했고, 이를 위해서 여러가지 검색 정책을 설정했습니다.

검색 정책은 다음과 같았습니다

이때 여러가지 검색 기법들을 고려하였습니다.

💛 해결 방법

각 검색 기법을 이용하기 전, 일단 띄어쓰기 기준으로 키워드를 구분해주었습니다.

인메모리 필터링

fulltext boolean search

LIKE 검색 + 인메모리

결론 : AND LIKE 검색 + Query DSL

💝 현재 적용한 방법 및 향후 방향

위의 트러블슈팅 당시에는 프론트에게 페이지네이션으로 넘겨줘야한다는 제약조건이 있었으나, 나눔을 6회차 이상 정리해본 결과 하루에 다뤄야하는 나눔이 200개 내외인 것을 알게되었습니다. 따라서 프론트가 요구사항을 변경하여 부하를 데이터베이스상이 아닌 프론트단에 주기 위해 해당 회차의 모든 나눔 검색 결과를 넘겨받고, 프론트가 필터링하고있습니다.

하지만, 유사어 검색 등 검색의 퀄리티를 높이기 위해 엘라스틱서치등을 활용할 방안을 세우고있습니다.

💡 해당 경험을 통해 알게된 점

비즈니스적인 요구사항에 따라 사용할 수 있는 기술적 방향이 여러가지라는 것을 알게되었습니다.

🚌 인천광역시 교통 약자 지도

공공데이터포털의 open api를 활용하여 하나의 지도에 통합적으로 인천광역시의 교통약자를 위한 정보를 제공하였습니다.

Github → 산출물 →

개발기간 : 2022.02~2022.10

리팩토링 : 2024.05~2024.06

Frontend 2명, Backend 2명

내가 기여한 부분

백엔드 : 50%

서버 배포 : 100%

지하철 관련 API 제작

  • 지하철 관련 공공데이터 연결 및 목적에 맞게 정보 재가공하여 api 개발
    • 지하철 관련 정보 api 외 6개
  • 지하철 이름과 내부지도 이미지명 파일 연결 최적화
    • 기존 api를 호출할때마다 이름 파일을 새롭게 연결해야 했던 문제 → 함수 호출마다 파일 로드 함수 실행 (시간 지연 문제)
    • 리팩토링시 싱글톤 컴포넌트로 추가하여 이름 파일을 첫 실행시에만 로드하도록 수정

검색 관련 API 제작

  • 티맵 api와 공공데이터포털의 승강기 api를 연결한 api 개발
    • 티맵 통합 검색 api
  • 건물 검색 속도 최적화
    • 기존 반복 동기식 검색을 병렬화시켜 비동기 처리후 최대 80%의 속도 개선

서버 배포

  • 졸업프로젝트의 일환으로 학교의 지원을 받아 담당 교수님 서버로 온프레미스 배포
  • NGINX를 이용하여 배포 및 가비아 도메인을 통해 도메인 연결

사용 기술

  • Java + Spring
  • NGINX
  • Github

트러블 슈팅

⛔ 문제 배경

검색 api 개발 과정에서 공공 데이터 포털이 제공하는 승강기 API의 속도 문제가 발생했습니다.

지도에서 건물을 검색한 후, 각 건물의 주소를 승강기 외부 API로 전송하면 승강기 여부와 상태를 응답받는 방식이었는데, 이 API의 속도가 느려서 여러 건물을 동시에 조회할 때 시간이 과도하게 소요되었습니다.

💛 해결 방법

이 문제를 해결하기 위해 고민해보았지만 외부 api를 이용하는 것이기 때문에 직접적으로 속도를 줄일 방법은 없었습니다.

기존에 10개의 건물을 검색할 때에 반복문을 이용하여 건물이 하나씩 응답이 와야 다음 건물로 넘어갈 수 있는 방식에 문제가 없을까 고민하였습니다 → 이는 전의 호출이 응답이 와야만 다음 코드가 실행되는 형태였습니다.

⇒ 동시에 10개의 건물을 호출하고 응답받는 방법은 없을까 고민하였습니다.

→ 10개의 건물을 병렬로 응답처리할 수 있는 병렬 실행 방식을 이용하여 해결!

🖥이전 코드와의 비교

이전 코드는 for문을 이용하여 이전의 호출의 응답이 와야만 다음 호출로 넘어가는 방식이었습니다.

10개의 건물을 리스트로 만들고 stream API를 이용하여 병렬로 승강기 api를 호출하여 처리하였습니다.

그렇게 서버 컴퓨터 기준 기존보다 80% 빨라질 수 있었습니다.

💡해당 경험을 통해 알게 된 점

이 과정을 통해 기존의 설계 방식에 얽매이지 않고 새롭게 전환하여 생각하는 방법을 배우게 되었습니다.

stream API의 작동방식을 알게되었습니다.

메인화면

승강기 지도 검색

버스 저상버스 여부 표시

교통약자 도보 길찾기 경로

건물 검색 (승강기 표시)

버스 목록

지하철 내부 입체 지도

계단 및 휠체어 충전기 위치