💪

트다(Training Diray)

생성일
2024/08/19 00:08
태그
비고
프로젝트 설명
PT 예약, 트레이닝 세션과 식단 관리를 한 곳에서 해결하세요!

Overview

트레이너의 효율적인 트레이니 관리 플랫폼 - Training Diary

PT 예약, 트레이닝 세션과 식단 관리를 한 곳에서 해결하세요!

  여러 회원과의 일정을 관리해주는 PT 예약
  트레이니 혼자서도 할 수 있도록 운동 기록 작성
  트레이니의 신체 변화를 추적할 수 있는 대시보드
  꾸준한 식단 관리 피드백을 받을 수 있는 공간

직접 사용해 보세요: training-diary.co.kr

트다: 트레이닝 다이어리
https://training-diary.co.kr/

Backend Github Repository

GitHub - TrainingDiary/training-diary-backend: 트레이닝 다이어리 백엔드
트레이닝 다이어리 백엔드. Contribute to TrainingDiary/training-diary-backend development by creating an account on GitHub.
https://github.com/TrainingDiary/training-diary-backend

Frontend Github Repository

GitHub - TrainingDiary/training-diary-frontend: 트레이닝 다이어리 프론트엔드
트레이닝 다이어리 프론트엔드. Contribute to TrainingDiary/training-diary-frontend development by creating an account on GitHub.
https://github.com/TrainingDiary/training-diary-frontend

Performance Video

Project

프로젝트 아키텍쳐

기술 스택

Frontend

•
Typescript
•
React
•
Vite
•
axios
•
react-query
•
zustand
•
react-router-dom
•
react-hook-form
•
Firebase Cloud Messaging
•
CSS
◦
styled-components
◦
framer-motion
•
TEST
◦
jest
◦
React Testing Library
◦
Mock Server Worker
•
CALENDAR
◦
FullCalendar
◦
date-fns
◦
react-datepicker
•
CHART
◦
React-chartjs-2
◦
chart.js

Backend

•
Java 17
•
Springboot
•
DB
◦
MariaDB
◦
Redis
•
Gradle
•
JWT
•
Lombok
•
Spring Security
•
Spring Data JPA
•
Swagger
•
Google Mail Sender
•
Caffeine Cache
•
Cloudfront CDN
•
AWS S3
•
Imgscalr
•
FFMPEG Encoding
•
Firebase Cloud Messaging
•
QueryDSL
•
Test
◦
JUnit
◦
Mockito
◦
Postman

CI / CD

•
Deploy
◦
Github Actions
◦
AWS CodeDeploy
◦
Netlify
•
Communication
◦
Slack
◦
Discord
◦
Github

ERD

주요 기능

Search

화면

소개

트레이니 및 트레이너의 회원가입 및 로그인 담당하는 페이지입니다. 회원가입

구현한 기능

FE

react-hook-form을 사용하여 회원가입 폼에서 실시간 유효성 검사 후, 각 폼에 맞는 에러 메세지를 보여주고 불필요한 리렌더링을 방지합니다.
 버튼에 의해 동작하는 이메일 인증, 인증코드 확인 등의 기능은 애니메이션을 적용한 별도의 알림 메세지를 구현하여 눈에 띄기 쉽게 중앙 집중적으로 주목성을 높입니다.
 회원가입 및 로그인에 성공하면 zustand를 사용하여 애플리케이션 전반에 걸쳐 일관된 유저 상태를 유지합니다. protected route와 public route에서 유저 정보를 판별하여 페이지 이동시키거나, 유저 role에 따라 분기처리하여 페이지를 렌더링합니다.
 Firebase Cloud Messaging을 사용하여 푸쉬 알림 수신에 대한 동의를 얻고, FCM token을 발급하여 이벤트에 따라 포그라운드와 백그라운드 상태에서 푸쉬 알림을 받습니다.

BE

이메일 중복 체크 및 인증 코드 보내기

•
중복 체크: 이메일 중복 여부를 확인합니다. 중복이 있으면 에러 메세지를 표시합니다.
회원 가입 & 로그인

화면

소개

PT 수강이 시작되면 트레이너가 여기서 트레이니를 등록하고, 관리를 시작합니다. 1. 트레이니 목록 조회 트레이너에게 현재 등록되어 있는 트레이니 목록을 조회합니다. 2. 트레이니 등록 PT 수강을 시작하면, 트레이너가 트레이니를 등록하고, 그때부터 회원 관리를 시작할 수 있습니다.

구현한 기능

FE

트레이니 관리
유저 경험 향상을 위한 로딩 상태 관리 및 에러 처

BE

트레이니 목록 트레이니가 많아질 경우를 대비해 페이지네이션을 사용해 데이터를 반환합니다.
트레이니 관리

화면

소개

트레이니 및 트레이너의 대시보드 페이지 트레이니의 대시보드

구현한 기능

FE

트레이니 대시보드 관리
트레이니 정보 수정 기능
인바디 데이터 관리
Chart.js를 사용한 데이터 시각화

BE

 트레이니 상세 정보 조회

•
트레이너: PT 계약이 맺어진 트레이니만 조회할 수 있습니다.
•
트레이니: 본인 정보만 확인할 수 있습니다.
트레이니 대시보드

화면

소개

트레이너가 트레이니에게 제공할 수 있는 운동 종류를 관리합니다. 1. 운동 종류 생성 트레이너는 제공할 운동 종류를 생성합니다. 운동의 이름, 타깃 부위, 주의사항을 필수로 입력해야 하며 운동 종류에 따라 무게, 횟수, 세트 수, 속도, 시간 5가지 속성 중 해당하는 속성을 중복 선택합니다. 2. 운동 종류 수정 트레이너는 운동 종류를 수정할 수 있습니다. 5가지 속성값을 제외한 운동의 이름, 타깃 부위, 주의사항을 수정할 수 있으며 이때도 3개의 값들은 필수 입력 사항입니다. 3. 운동 종류 삭제 트레이너는 더 이상 트레이니에게 제공하지 않을 운동 종류를 삭제합니다. 4. 운동 종류 조회 트레이너는 자신이 생성한 운동 종류의 목록을 확인할 수 있습니다.

구현한 기능

FE

모달을 통한 CRUD 작업
운동 데이터의 페칭 및 로딩 상태 관리

BE

다양한 어노테이션을 사용해 입력받은 값들에 대해 유효한 데이터들만 저장하도록 했습니다.
무게, 세트 수 등의 boolean 타입의 속성 값들은 수정할 수 없도록 정했기 때문에 수정이 필요한 필드의 값만 바꿀 수 있도록 @Builder의 toBuilder 속성을 사용했습니다.
해당 운동 종류를 관리하는 트레이너의 정보와 운동 종류의 식별 번호를 이용해 삭제하고 싶은 운동 종류를 삭제할 수 있도록 했습니다.
운동 종류는 항상 최근에 등록한 순서대로 정렬하기로 했기 때문에 데이터베이스에서 조회할 때부터 등록 최신순으로 조회하고 페이지 네이션을 통해 한 번에 특정 수의 데이터만 반환할 수 있도록 했습니다.
트레이니에게 제공할 운동 종류

화면

소개

여러 수강생들의 일정을 한곳에서 관리할 수 있는 기능입니다. 트레이너가 직접 일정을 등록하거나, 트레이니의 신청을 받아 예약할 수 있습니다. 1. 일정 열기 & 닫기 트레이너가 자신이 가능한 일정을 자유롭게 열고 닫을 수 있습니다. 1시간 단위로 오픈 일정을 만들 수 있습니다. 열려 있는 일정에 트레이니가 신청할 수 있습니다. 대량의 일정을 받아 한번에 열도록 할 수 있고, 기존의 일정과 겹치지 않게 검사 후 오픈합니다. 2. 일정 신청 & 수락 & 거절 트레이니가 원하는 일정을 신청하고, 트레이너가 수락하거나 거절할 수 있습니다. 3. 일정 일괄 등록 예약하지 않고도, 트레이너가 직접 트레이니의 일정을 등록할 수도 있습니다. 예를 들어, 10회의 일정을 화, 목 저녁 7시와 같은 식으로 등록해놓을 수 있습니다. 중간에 일정이 변경되면 트레이니는 하루전까지 취소할 수 있고, 다른 일정을 신청할 수 있습니다. PT 시간이 하루 미만으로 남은 상태에서는 트레이너가 직접 취소할 수 있습니다. 4. 일정 조회 트레이너와 트레이니는 각자의 일정을 확인할 수 있습니다. 트레이너 입장에서는 자신이 열어놓은 일정들과 다른 트레이니들의 일정을 확인합니다. 트레이니 입장에서는 트레이너의 열어놓은 일정들과 자신의 일정을 확인합니다. 5. 알림 기능 트레이너와 트레이니의 일정에 변동이 생기면 서로에게 알림을 보냅니다. 일정 시작 1시간 전에 알림을 보냅니다.

구현한 기능

FE

달력이 넘어가거나 날짜가 선택될 때, 동일한 요청에 대해 서버에 반복적으로 데이터를 요청하지 않고 React Query의 캐싱 기능을 사용합니다. 네트워크 트래픽과 응답 시간을 줄입니다.
FullCalendar 라이브러리를 사용하여 월별 캘린더를 트다에 맞게 커스텀하고, Date click 이벤트와 다양한 상황의 인터랙션을 연동해서 사용자 경험을 향상시킵니다.
주별 캘린더에서 date-fns 라이브러리를 사용하여 가로 무한 스크롤을 구현했습니다. 달력의 양쪽 끝에 도달할 때 추가적인 날짜를 로드하여 확장하고, 유저는 스크롤과 드래그를 통해 연속적으로 날짜를 탐색합니다.

BE

일정 등록 및 신청, 수락, 거절 일정을 신청하거나 등록하면 PT 잔여횟수가 차감되고, 다른 트레이니가 같은 일정에 다시 신청할 수 없도록 일정의 상태를 변경합니다. 잔여횟수 차감과 일정 상태의 변경이 동시에 일어나도록 Transactional을 사용해 하나의 실행 단위로 묶었습니다.
PT 예약

화면

소개

트레이너는 PT 수업이 끝난 후 그날 진행했던 수업에 대한 기록을 남겨 이후 트레이니가 스스로 운동할 때 참고할 수 있습니다. 1. 운동 일지 생성 트레이너는 PT 수업이 끝나면 운동 일지를 작성합니다. PT 수업 일자와 회차, 수업의 특이사항, 그날 진행한 운동을 기록하게 됩니다. 운동 일지는 PT 수업의 회차별로 한 개만 작성할 수 있습니다. 2. 운동 일지 수정 회차별로 일지를 한 개만 작성할 수 있기 때문에 트레이너는 PT 수업 회차를 제외한 나머지 내용들을 수정할 수 있습니다. 3. 운동 일지 삭제 4. 운동 일지 이미지 업로드 트레이너는 해당 수업에서 촬영한 트레이니의 운동 자세에 대한 이미지를 업로드할 수 있습니다. 이미지는 한 번에 여러 장 업로드가 가능하고 각 일지별로 10장까지 업로드 할 수 있습니다. 5. 운동 일지 동영상 업로드 트레이너는 해당 수업에서 촬영한 트레이니의 운동 자세에 대한 동영상을 업로드할 수 있습니다. 동영상은 한 번에 하나씩만 업로드 가능하며 각 일지별로 5개까지 업로드할 수 있습니다. 6. 운동 일지 목록 조회 트레이너와 트레이니는 운동 일지의 목록을 확인할 수 있습니다. 이곳에서는 업로드했던 자세 사진들과 일지들의 목록을 확인할 수 있습니다. 일지는 가장 최근에 작성한 일지가 위로 정렬되며 목록에는 PT 수업 날짜와 회차가 표시됩니다. 7. 운동 일지 상세 조회 트레이니는 트레이너가 작성해 준 PT 수업에 대한 일지를 회차별로 상세하게 조회할 수 있습니다. 목록에서 원하는 일지를 선택하면 트레이너가 업로드한 특이사항, 운동 내용, 자세 사진, 영상 등을 확인할 수 있습니다.

구현한 기능

FE

세션 관리 및 목록 표시
세션 추가 기능
세션 상세 정보 및 편집
운동 사진 및 비디오 관리

BE

사진과 동영상 같은 미디어 파일의 관리를 위해 AWS S3를 사용했습니다.
각 미디어 파일의 이름은 접두사(thumb_/original_)를 통해 어떤 종류인지 나누고 UUID를 이용하여 중복되지 않도록 하였습니다. 또한 원래 미디어 파일의 확장자를 다시 붙여주어 어떤 타입의 미디어인지 알 수 있도록 하였습니다.
그날의 운동 기록

화면

소개

트레이니의 식단을 관리하는 페이지입니다. 트레이니의 식단 추가

구현한 기능

FE

IntersectionObserver와 useInfiniteQuery를 이용하여 무한스크롤을 구현하여 식단 사진 목록을 끊김없이 부드럽게 보여줍니다. 사용자 기기 크기에 따라 뷰포트가 변경되어도 유연하게 동작하고, react-query에서 필요한 데이터만 페칭하여 성능을 최적화합니다.
이미지가 사용되는 곳의 뷰포트 너비를 고려하여 다양한 크기의 이미지를 적절히 사용하고, loading: lazy 속성을 적용하여 이미지 최적화를 통해 렌더링 속도를 향상시킵니다.
createObjectURL을 사용하여 업로드한 이미지를 서버에 전송하지 않고 로컬에서 직접 URL을 생성하여 미리보기 이미지를 표시합니다. 서버 리소스를 절약하고 사용자 경험을 개선합니다.

BE

트레이니의 식단 추가

•
이미지 파일 올리기 - AWS S3 저장소에 이미지를 업로드합니다. JPEG 또는 PNG 형식의 파일만 허용되며, 원본 이미지와 썸네일 이미지를 모두 저장합니다. 잘못된 파일 형식을 업로드할 경우, 에러 코드가 반환됩니다. AWS S3을 사용하는 이유는 높은 가용성과 확장성, 데이터 내구성, 그리고 비용 효율성 때문입니다. 이를 통해 대량의 이미지를 안전하게 저장하고 관리할 수 있습니다.
•
썸네일 생성 - 이미지 리사이징에 최적화된 라이브러리인 imgscalr을 사용하여 썸네일을 생성합니다. 썸네일의 크기는 150px로 1:1 비율로 조정하였으며, 파일 크기를 크게 줄일 수 있었습니다.
트레이니 식단 공유

트러블 슈팅

Search

Problem

배포된 서버에서도 로컬과 동일하게 ffmpeg가 작동되어야 하는데 업로드가 되지 않았습니다.

How to solve

Cannot run program "ffprobe": error=2, No such file or directory 에러를 해결하기 위해 배포된 서버도 로컬과 동일하게 ffmpeg를 설치해주었습니다.
배포된 서버에서 ffmpeg 이용해서 동영상 업로드

Problem

http cookie가 배포된 환경에서는 잘 동작했는데, 로컬에서 동작을 안합니다.
이런 형태로 에러가 나왔습니다.
에러메세지: This Set-Cookie header didn't specify a "SameSite" attribute and was defaulted to "SameSite=Lax", and was blocked bacause it came from a cross-site response which was not the response to a top-level navigation. The Set-Cookie had to have been set with "SameSite=None" to enable cross-site usage.

SameSite 옵션이란?

•
SameSite 쿠키 속성은 웹 애플리케이션이 크로스 사이트 요청으로부터 보호하기 위해 사용하는 보안 기능입니다. 이 속성을 통해 웹 브라우저는 쿠키를 전송할지 여부를 결정할 수 있습니다.

SameSite 속성 값

1.
Lax: 기본 설정으로, 쿠키는 사용자 이동에 따른 GET 요청에서만 전송됩니다. 다른 모든 요청(예: POST, PUT, DELETE)에서는 전송되지 않습니다.
2.
Strict: 가장 엄격한 설정으로, 사용자가 사이트를 탐색할 때만 쿠키가 전송됩니다. 다른 모든 크로스 사이트 요청에서는 전송되지 않습니다.
3.
None: 쿠키가 모든 요청에 대해 전송됩니다. 이 설정을 사용하려면 쿠키에 Secure 속성이 함께 설정되어야 합니다.

에러 발생 이유

•
에러 메시지에서 언급된 것처럼, SameSite 속성이 명시되지 않은 쿠키는 기본적으로 Lax로 설정됩니다. 이는 크로스 사이트 요청에서 쿠키가 차단될 수 있음을 의미합니다. 특히 배포된 환경에서는 크로스 사이트 요청이 많기 때문에, SameSite 속성을 None으로 설정하고 Secure 속성을 추가해야 쿠키가 제대로 전송될 수 있습니다.
http cookie가 클라이언트 배포에서는 동작하지만 로컬에서 동작하지 않음

Problem

EC2 앞에 CloudFront를 넣어서 인프라를 구성했습니다. CloudFront에 SSL 인증서를 설정하기가 EC2에 직접 설정하는 것보다 더 수월하다는 이유에서 넣었습니다. ALB를 넣을 수도 있었겠지만, 비용상 CloudFront를 설정했습니다. 시간이 지난 후, 영상 업로드 기능을 만들면서 CloudFront의 에러를 내보냈습니다.
CloudFront의 에러 응답

How to solve

처음엔 영상 업로드와 관련하여 S3도 역시 CloudFront를 사용하고 있었기 때문에 관련 에러라고 생각했습니다. 하지만 생각해보면 영상을 클라이언트로부터 받아 S3에 업로드하는 과정 중에서는 CloudFront를 사용하지 않았습니다.
관련 내용을 찾아보니 CloudFront에는 request timeout이 있었고, 이 timeout을 넘기면 CloudFront가 자동으로 에러로 응답했습니다. timeout의 기본값은 30초였습니다. 클라이언트에서 영상을 업로드 받은 후 파일을 압축하는 과정과 결과물을 S3로 업로드하는 과정에서 시간이 소요되므로 timeout이 걸리는 경우가 있었습니다. 일단은 CloudFront timeout 최대 설정을 보니 60초였고, 그렇게 설정했습니다. 이렇게 기본적으로 에러가 일어날 수 있는 범위는 줄였습니다만, 문제를 완전히 해결한 것은 아닙니다. 같은 Origin 에 있는 다른 API 들도 (원하지 않았지만) 모두 timeout이 60초로 늘어나게 되었고, 여전히 60초 이상 응답을 주지 않는 경우에 대해서는 에러가 발생합니다. 예전에는 30초 고정이었던 적도 있는 것 같습니다. 관련 내용을 더 찾아보니 이 timeout을 늘려서 써보려는 시도들이 있는 것 같습니다. 추가로 알게 된 점 - CloudFront에서 에러 응답을 줄 때 Custom error response를 줄 수 있다는 것을 알았습니다. - AWS에 직접 service quota 요청을 보내서 늘리는 방법도 공식 문서에 안내되어 있었습니다. 하지만 이렇게 단순히 timeout을 늘리는 것이 좋은 것은 아니라고 생각했습니다. API를 분리하거나 다른 구조를 통해서 영상 압축에 걸리는 시간을 가져갈 수 있도록 해야할 것 같습니다.
영상 업로드 시 CloudFront의 실패 메시지가 뜸

Problem

Spring Scheduling의 @Scheduled 어노테이션을 사용해서 예약된 일정 1시간 전에 알림을 주도록 했습니다. 하지만 알림이 정상적으로 도착하지 않고, LazyInitializationException 이라는 에러를 냈습니다. org.hibernate.LazyInitializationException: could not initialize proxy [com.project.trainingdiary.entity.TraineeEntity#1] - no Session

How to solve

에러 로그를 보면 proxy를 읽어올 수 없다고 해서, 연관관계의 lazy fetch type이 생각났습니다. 더 찾아보니 특정 시간에 함수 실행을 등록하지만, 등록하는 시점에 넘겨주는 값들에는 실제 값이 들어있지 않은 상태입니다. 등록 후에 Hibernate의 Session이 끝나게 됩니다. Session이 끝난 후에 엔티티 값을 가져오려고 하면 LazyInitializatioinException 에러를 냅니다. 물론 등록과 동시에 실행이 이루어지는 구조이긴 하지만, 둘(등록과 실행)은 명확히 분리된 단계라는 것을 알았습니다. 등록하는 시점에 사용할 모든 연관관계 값까지 가져와야 합니다. 그러기 위해서 fetch join 을 사용해서 쿼리 하는 시점에 연결된 값들을 가져오도록 하고, 그 상태로 함수 실행을 등록하도록 해서 해결했습니다.
@Scheduled 사용 시 Lazy 로딩 에러

Problem

서버에서는 Firebase admin sdk를 사용해 FCM(Firebase Cloud Messaging) 서비스로 푸시 알림을 보냈습니다. 푸시 알림이 클라이언트에 제대로 도착하는 것을 테스트하고 싶었습니다. 테스트용 토큰 같은 것을 제공하는지 찾아보았지만 찾을 수 없었습니다. 실제 클라이언트에서 발급받은 토큰을 넣지 않으면 테스트 메시지라도 보낼 수가 없는 것 같았습니다.

How to solve

실제 동작하는 것을 테스트하기 위해 클라이언트 웹앱을 만들어서 Token을 발급받아야 했습니다. 찾아 보니 react에서 pwa를 위한 service worker 설정을 해놓은 템플릿을 만들 수 있었습니다. 이 템플릿을 바탕으로 웹앱을 만들고, token을 받아오는 코드만 넣어 클라이언트를 구성했습니다. 그리고 클라이언트를 띄워놓고, 토큰을 발급받아 테스트를 성공했습니다. 같은 토큰으로 며칠 후에 다시 테스트를 해보니 메세지 전송 중에 “Requested entity was not found.” 에러가 나왔습니다. 토큰이 유효하지 않아서 나는 에러인데, 에러 메시지에 토큰 얘기는 없어서 찾아보며 시간을 좀 보냈습니다. 알림 관련된 기능을 개발할 때 클라이언트도 띄워놓고, 개발을 해야하는 게 번거롭긴 했지만, 클라이언트 코드들도 배울 수 있는 기회였습니다.
FCM 푸시 알림이 제대로 갔는지 테스트하기 어려움

 QA 리스트

Search
분류
AS-IS
TO-BE
해결 여부
회원가입
회원가입 시 500 에러 발생
Open
DB 스키마 업데이트 문제로 DB 초기화
해결
회원가입
이메일 중복 확인부터 인증 코드 메일 전송까지 시간이 오래 걸림
Open
@Async 사용하면서 해결
해결
로그인
http cookie가 클라이언트 배포에서는 동작하지만 로컬에서 동작하지 않음
Open
로컬 환경일때 setSecure(false), sameSite: Lax 로 수정, 배포된 환경일 때 setSecure(true), sameSite: None: 으로 수정
해결
로그인
가입한 적 없는 이메일로 로그인 요청시 404 페이지로 이동
Open
굳이 클라이언트한테 이메일이 존재 유무, 비번 틀린 경우를 알릴 필요 없어 에러 코드 400으로 변경
해결
로그인
로그인 후 메인 페이지에서 새로고침 시 현재 페이지를 유지하지 못하고 로그인 페이지로 이동
Open
protectedRoute에서 zustand로 관리 중인 유저 정보 유무에 따라 로그인과 비로그인으로 구분하는데 새로고침 시 zustand 상태관리가 초기화되면서 로그인 페이지로 이동. zustand와 localStorage를 동기화하는 방법으로 수정
해결
로그인
로그아웃 시 redis에 토큰 삭제 안됨
Open
로직 리팩토링하는 동안 뺴먹음, 수정해서 해결
해결
로그인
API 요청할 때마다 인증 권한 쿼리가 무의미하게 나감
Open
Caffeine cache 기능 도입하면서, 유효기간 10분에 들어있는 유저 조회 시 캐시된 정보로 검색하도록 설정
해결
트레이니 관리
없는 이메일로 트레이니 추가 시 404 에러, 별도의 에러 정의 필요
Open
406 에러를 내도록 수정
해결
트레이니 관리
조회 응답의 날짜 시간 표시
Open
전역에서 쓰는 것으로 수정 및 날짜만 표시하도록 수정
해결
트레이니 관리
다른 트레이너와 이미 계약된 트레이니 추가 시 에러 발생
Open
서버 에러 response 추가 및 클라이언트 에러 Alert 추가 (에러코드 410)
해결
Load more

Team

•
매일 빠지지 않고 회의 진행
•
PR, Issue 작성
•
디스코드를 통해 기술 공유 및 토론
•
서로 막히는 부분도 물어가며 빠르게 트러블 슈팅

Member

이규민 | Backend Developer

문제가 생기면 먼저 해결을 시도하는 개발자입니다.
사람과 소통하는 것을 좋아하며, 알고리즘과 프로젝트 최적화에 관심이 많습니다.
특히 그래프 알고리즘을 좋아합니다.

이충경 | Backend Developer

수동으로 하던 일을 자동화하고, 효율적으로 만드는 것을 좋아해 개발자가 되었습니다.
새로운 것을 배우는 것을 좋아하는 개발자입니다.
AWS를 좋아합니다.

이현주 | Backend Developer

깔끔하고 읽기 쉬운 코드를 작성하기 위해 노력하는 개발자 입니다.
효율적인 데이터 처리와 시스템 구축에 대한 관심을 두고 꾸준히 학습하고 성장해 나가고 있습니다.

황수민 | Frontend Developer

동료에게 신뢰를 주고 받는 개발자를 희망합니다.
제가 전달하는 긍정적인 피드백이 동료와 팀을 성장시키고, 결국 저에게 되돌아오는 선순환의 관계를 쌓고 싶습니다.
차근차근 꼼꼼히 배우고 경험을 쌓아가는 것을 좋아하는 개발자입니다.

변정민 | Frontend Developer

프론트엔드 개발자로서의 경험과 역량을 쌓아가고 있는 중입니다.
사용자 경험에 초점을 맞춘 웹 애플리케이션 개발에 관심이 많으며, 지속적인 학습과 실습을 통해 전문성을 높여나가고 싶습니다.