Back-end Engineer 장태현

리틀뱅크 ⭐

아이들의 학습동기 부여 어플

기간 : 2025/03~2025/07

팀 구성 : App(PM) 1, Backe-end 2, Design 1

담당역할 : #Back-end, #PL

사용 기술 & 라이브러리 :

GitHub :

littlebank-server - GitHub

팀에서의 역할

1. PL을 맡아, 팀원의 코드를 피드백하고 깃허브를 활용하여 코드를 병합하는 업무를 담당했습니다.

기여한 부분

1. GitHub Actions + CodeDeploy 기반 CI/CD 파이프라인 구축 ⇒ 배포 과정 자동화 및 운영 편의성 개선

2. 채팅방 정렬·읽음 상태를 클라이언트에서 처리하던 구조 ⇒ BFF 관점의 API로 분리, 클라이언트는 렌더링만 담당하는 구조로 전환

3. Toss Payments API 기반 결제 로직에서 [결제 전 정보 서버에 저장 ⇒ 승인 후 비교 검증] 을 통한 위변조 방지 플로우 구현

앱 화면

홈

한눈에 보는 대시보드 스크린

채팅

실시간 1:1 채팅, 그룹채팅 기능

챌린지

전체 유저와 같이 동기부여 챌린지

1:1 경쟁

1:1 경쟁을 통한 동기부여 시스템

랭킹

전체 유저 랭킹 시스템

피드

학습인증, 일상 글 등 소통창고

결제

토스페이, 카카오페이 등 결제가능

혜택

2주무료 구독권등 마케팅 혜택

보안

계좌 2차 핀번호 보안 시스템

약관

서비스 이용약관 및 동의

홈

한눈에 보는 대시보드 스크린

채팅

실시간 1:1 채팅, 그룹채팅 기능

챌린지

전체 유저와 같이 동기부여 챌린지

1:1 경쟁

1:1 경쟁을 통한 동기부여 시스템

랭킹

전체 유저 랭킹 시스템

피드

학습인증, 일상 글 등 소통창고

결제

토스페이, 카카오페이 등 결제가능

혜택

2주무료 구독권등 마케팅 혜택

보안

계좌 2차 핀번호 보안 시스템

약관

서비스 이용약관 및 동의

홈

한눈에 보는 대시보드 스크린

채팅

실시간 1:1 채팅, 그룹채팅 기능

챌린지

전체 유저와 같이 동기부여 챌린지

1:1 경쟁

1:1 경쟁을 통한 동기부여 시스템

랭킹

전체 유저 랭킹 시스템

피드

학습인증, 일상 글 등 소통창고

결제

토스페이, 카카오페이 등 결제가능

혜택

2주무료 구독권등 마케팅 혜택

보안

계좌 2차 핀번호 보안 시스템

약관

서비스 이용약관 및 동의

DEVHUB

프로젝트 형상관리 기능을 활용하기 어려워하는 초보 개발자들을 위한 프로젝트 형상관리 서비스

기간 : 2024/07~2024/10

팀 구성 : Front-end 2, Backe-end 3

담당역할 : #Back-end, #PL

사용 기술 & 라이브러리 :

GitHub :

devhub-server - GitHub

프로젝트 자세히 살펴보기 :

프로젝트 형상관리 서비스 DEVHUB - Notion

팀에서의 역할

1. PL을 맡아, 팀원들의 코드를 피드백하고 깃허브를 활용하여 코드를 병합하는 업무를 담당했습니다.

2. 프로젝트의 핵심 서비스인 형상관리 기능을 설계하고 개발하는 일을 담당했습니다.

기여한 부분

1. 이메일 발신 기능 성능 개선

• 이메일 발신 기능이 동기 방식으로 처리되는 것은 실제 서비스에서 치명적인 문제가 될 것이라고 판단했습니다.

• 비동기 방식으로 처리되도록 바꾸고나서 결과적으로 1초 동안 각 요청으로부터 소요된 응답 시간을 평균 4.159초(4159ms) → 0.017초(17ms)로 개선하였습니다.

• 이메일 발신 기능의 성능 개선 과정에 대한 자세한 내용을 기술 블로그에 기록해 두었습니다.

이메일 발신 기능 성능 개선 과정 - Tistory

고민한&학습한 부분

1. 형상관리 전략 (”snapshot” VS “Git”)

• 프로젝트 형상관리 기능을 제공하기 위해 서버에서 어떤 방식으로 유저의 프로젝트를 저장하고 형상관리 해야할지에 대해서 많은 고민이 있었습니다.

◦ 디스크 용량 부족 문제 : 유저가 업로드하는 프로젝트 파일을 서버 디스크에 그대로 저장할 경우, 매번 새로운 버전을 업로드할 때마다 동일하거나 비슷한 용량의 파일이 반복적으로 저장되게 됩니다. 이런식으로 파일이 계속 저장된다면 서버의 디스크 용량이 빠르게 소진되어 결국 저장 공간 부족 문제가 발생할 것이라고 생각했습니다.

• 초기에는 “snapshot“ 기법을 활용하여 형상관리 전략을 설계 했지만 문제가 존재하여 결론적으로 Git 시스템을 이용하게 되었습니다.

• 형상관리 전략을 결정하기까지의 자세한 과정을 노션에 기록해 두었습니다.

형상관리 전략 결정 과정 - Notion

2. 팀 저장소 내에서 여러 팀원이 동시에 파일을 업로드할 경우

• 처음에는 하나의 프로젝트를 관리하는 팀 저장소 내에서 여러 팀원이 동시에 파일을 업로드했을 때 서버에는 최초 한 팀원의 파일만이 저장되는 것을 의도했습니다.

• 하지만 의도와 달리 여러 팀원이 동시에 업로드한 파일이 서버에 모두 저장되었고 이 부분을 어떻게 해결할지 많은 고민이 있었습니다.

• 결론적으로 DB 락을 걸어 우회적인 방법으로 해결하였으며 그 과정을 기술 블로그에 기록해 두었습니다.

파일 저장 로직의 동시 요청에 의한 동시 저장을 방지하는 방법 - Tistory

3. AWS + Docker를 이용한 프로젝트 배포 과정

• 이전에 AWS EC2 서버에 스프링부트 프로젝트를 배포해 본 적이 있지만 이번 프로젝트에서는 Docker를 이용하여 EC2 서버에서 스프링부트 프로젝트를 배포한다는 점에서 차이가 있습니다.

• RDS에 데이터베이스 생성하고 연동하는 과정을 기술 블로그에 기록해 두었습니다.

스프링부트 프로젝트와 AWS RDS를 연동하는 과정 - Tistory