화면의 흐름을 이해하고, 서버까지 연결하는 개발자

WORK EXPERIENCE · DEVELOPMENT SCOPE

프론트엔드서버관리자

개발 참여 기간: 6개월; 2025.10–2026.04
개발 범위: 3개 시스템; 프론트엔드 · 서버 · 관리자
서비스 리뉴얼: V2; 셀럽 탐색 → 캠페인 → 협업 제안

개인 개발 범위와 실무 참여 기간

팀 프로젝트 · 풀스택2026.07

YouthPick

사용자 조건에 맞는 청년 정책
추천·비교 서비스

풀스택

정책 비교·추천 API 구현 · 매칭 규칙 설계 · FSD 구조 정리

ReactZustandJava 21Spring Boot

창업팀 · 실제 서비스 운영2023.10–2024.06

ReadyVery

카페에서 교내 축제까지 확장한
모바일 주문·결제 서비스

프론트엔드

주문·쿠폰·결제 흐름 · 축제 주문 환경으로 확장

ReactRecoilaxiosToss Payments

팀 프로젝트 · 풀스택2025.05–06

Prolog

기술 글과 지식을 공유하는
개발자 블로그 서비스

풀스택

게시글·댓글·북마크 구현 · 유스케이스 권한 검증

Next.jsTypeScriptPrisma

팀 프로젝트 · 프론트엔드2025.01–03

Coedu

교육 과정의 소통과 학습을 연결하는
실시간 교육 플랫폼

프론트엔드

개발 환경·CI · 인증·테마 · 화면 이동 오류 해결

TypeScriptEmotionTanStack QueryGitHub Actions

COLLABORATION

팀의 진행 상황이 보이도록
학습·리뷰의 흐름을 정리했습니다

UMC 학교 대표·파트장 경험 · 2022–2024

경험에서 배운 점

초기 프로젝트에서 파트별 진행 공유 부족으로 일정 문제 경험
자신의 작업뿐 아니라 팀 전체의 연결 상태를 확인할 필요 인식

다음 활동에서 실천

학교 GitHub 조직·저장소로 주차별 과제와 진행 상태 공유
GitHub 사용 가이드와 파트장 코드 리뷰 운영
질문과 피드백을 주고받을 수 있는 학습 과정 지원

TEAM PRACTICE진행을 공유하고,
막힌 지점을
함께 확인하기

가이드 → 과제 공유 → 리뷰 → 질문

BACKGROUND / TIMELINE

이력 · 활동

교육·경력·커뮤니티의 경험을 웹 개발 역량으로 연결

2026.09.11
정보처리기사자격증
국가기술자격 취득
2026.06
SQLD · ADsP자격증
SQL 개발자 · 데이터분석 준전문가 취득
2026.05–11
청년취업사관학교 SeSAC교육 · 수강 중
AWS와 AI를 활용한 MSA 기반 웹 서비스 개발
2025.10–2026.04
알리고에이아이경력
개발팀 웹 개발자 · Celevu V2 리뉴얼
2025.06–09
청년취업사관학교 SeSAC교육 · 수료
AI 시대의 자바 백엔드 개발자 양성 과정
2025.03–06
KDT 멋쟁이사자처럼교육
프론트엔드 부트캠프 플러스 4기
2025.02–03
KDC 항해99교육
실무에 바로 쓰는 Next.js
2024.10–11
구름(goorm)개발 검수
HTML5 콘텐츠 window.postMessage API 개발 검수
2024.07–2025.02
구름톤 유니브운영
가톨릭대학교 3기 교내 운영진
2023.10–2024.06
창업팀 ReadyVery창업
고객용·점주용 웹 개발 · 주문·결제 화면 구현
2023.10
ACM-ICPC 가톨릭대 예선수상
은상
2023.06–08
창업동아리 MATCH동아리
홈페이지 MVP 제작
2022.08–2024.08
UMC 3–6기동아리
Android·Node.js 파트장 · 6기 학교 대표
2021–2022.08
알고리즘 소모임 ALCUK소모임
주니어 · 시니어 · 시니어 심화

PROJECT 01 · 실무 · V2 리뉴얼

Celevu

셀럽 이미지 라이선싱 기반
광고 제작·섭외 플랫폼

기간: 2025.10–2026.04
담당 역할: 풀스택 개발 · 프론트엔드 중심
기술: Next.js · TypeScript · NestJS · Django

주요 기여

셀럽 상세·캠페인·협업 제안 화면과 API 연동
공통 HTTP·인증 기반 구축과 기능별 계층 분리
통화 변환·추천 이력·다국어 운영 기능 구현

핵심 결과

화면부터 서버·관리자까지 연결하고,
반복되는 통신·인증 처리를 공통 계층으로 정리

개발 참여 기간: 6개월; 2025.10–2026.04
개발 범위: 3개 시스템; 프론트엔드 · 서버 · 관리자
서비스 리뉴얼: V2; 셀럽 탐색 → 캠페인 → 협업 제안

개인 개발 범위와 실무 참여 기간

ARCHITECTURE

화면에 섞인 데이터 처리를
기능별 역할로 분리했습니다

유지보수할 때 확인할 코드의 경계를 명확하게 정리

문제와 판단

비즈니스 처리와 API 접근이 섞이면 변경 영향을 찾기 어려움
도메인별 역할과 공통 통신 기반을 구분할 필요

담당 작업

셀럽·인증·캠페인·추천의 기능별 구조 정리
Repository·Application·Query·Mapper의 역할 분리
API 응답을 화면 모델로 바꾸는 매퍼 분리
공통 HTTP 코드를 infra 영역으로 정리

변화

화면 표시·도메인 처리·통신의 변경 위치를 구분

UI · QUERY화면과 조회 상태

사용자에게 표시할 상태 구성

APPLICATION · REPOSITORY처리 규칙과 데이터 접근

도메인별 기능의 책임 구분

MAPPER · INFRA응답 변환과 공통 통신

화면 모델 변환 · HTTP 기반 재사용

AUTHENTICATION

토큰 만료 처리를
클라이언트와 서버 실행 환경에 맞췄습니다

공통 HTTP 계층 · 자동 갱신 · 요청 재시도

판단

Next.js의 브라우저·서버 요청은 토큰 접근 방식이 다름
컴포넌트마다 인증 오류를 처리하면 정책이 분산

구현

fetch 기반 HTTP 클라이언트와 토큰 주입 래퍼 구성
HttpOnly 쿠키 기반 인증 처리와 서버 액션 연결
401 응답 시 토큰 갱신 후 원 요청을 한 번 재시도

변화

화면에서 반복하던 통신·인증 처리를 공통 계층으로 이동

클라이언트 / 서버 요청실행 환경에 맞는 인증 래퍼 사용

401 → 토큰 갱신갱신 실패는 인증 실패로 전달

원 요청 재시도재시도를 한 번으로 제한

인증 규칙을 화면 밖에서 일관되게 적용

BUG FIX

파일 업로드 실패를
multipart 헤더 처리에서 해결했습니다

화면 증상을 요청 형식까지 추적한 사례

문제와 원인

참고 자료 업로드 시 서버가 요청 본문을 해석하지 못함
공통 HTTP 계층이 FormData에도 Content-Type을 지정
브라우저가 생성해야 할 multipart boundary 누락

수정

FormData 여부를 확인해 Content-Type 헤더 제거
일반 JSON 요청과 파일 요청의 처리 경로 구분

개선 포인트

업로드 화면 대신 공통 전송 계층의 원인 수정

REQUEST FORMAT

if (body instanceof FormData) {
  headers.delete("Content-Type");
}

// 브라우저가 boundary를 포함한
// multipart 헤더를 자동 생성

실제 변경 내용을 설명하기 위한 축약 코드

FULL STACK FEATURE

통화 변환을
서버 API부터 예산 화면까지 연결했습니다

하나의 기능을 사용자 선택 → 계산 → 표시까지 완성

요구사항

해외 사용자가 선택한 통화로 캠페인 예산 확인
화면 이동·새로고침 뒤에도 선택한 통화 유지

담당 구현

서버 환율 조회·통화 변환 모듈 및 JWT 인증 적용
선택 통화 스토어 영속화와 변환 훅 구현
캠페인 생성·상세·협업 제안 화면에 적용

설계 관점

서버의 계산 규칙과 화면의 표시 상태를 구분

사용자 선택통화 선택 상태 저장

인증된 서버 API환율 조회 · 통화 변환

공통 표시 로직여러 예산 화면에 동일하게 적용

프론트엔드와 서버 사이의 계약을 직접 연결

RECOMMENDATION HISTORY

지난 추천 조건과 결과를
다시 활용할 수 있게 만들었습니다

추천 이력 저장·조회 API와 화면 경험 연결

사용자 흐름

과거의 추천 결과를 찾고 같은 조건으로 다시 실행

담당 구현

서버에 추천 이력 저장·목록·상세 조회 구현
커서 기반 페이지네이션과 무한 스크롤 연결
이력 상세에서 이전 프롬프트 재로딩
선택한 셀럽의 추천 사유를 캠페인 메모에 반영

결과

추천 조회가 일회성 화면에서 재사용 가능한 흐름으로 확장

이력 목록커서 기반 추가 조회

이력 상세추천 결과 · 당시 입력 조건 확인

조건 재사용프롬프트 재로딩 → 다시 추천

담당 범위: 추천 이력 API · 결과 화면 · 조건 재사용

MULTILINGUAL OPERATIONS

다국어 표시와 운영 입력을
세 저장소에서 함께 연결했습니다

프론트엔드 · 서버 · Django 관리자

맥락

화면 번역과 데이터 번역이 함께 필요한 해외 대응
운영자가 여러 언어의 정보를 관리할 입력 흐름 필요

담당 구현

프론트엔드 한국어·영어 번역 구조와 화면 적용
요청 언어에 맞는 셀럽명 등 서버 응답 처리
Django Locale 모델과 관리자 다국어 입력 탭 추가
반복되는 콘텐츠 번역 저장 로직을 공통화

관점

사용자 화면뿐 아니라 운영자의 관리 과정까지 고려

ADMIN언어별 정보 입력

운영자가 탭으로 번역 데이터 관리

SERVER요청 언어로 응답

표시할 언어와 데이터 선택

FRONTEND문구 + 콘텐츠 표시

화면 번역과 도메인 데이터 연결

NEXT PROJECTYouthPick

PROJECT 02 · 팀 프로젝트 · 풀스택

YouthPick

사용자 조건에 맞는 청년 정책
추천·비교 서비스

기간: 2026.07
담당 역할: 풀스택 개발
기술: React · Zustand · Java 21 · Spring Boot

주요 기여

정책 비교 API 구현과 비교 화면 연동
자격 조건·평가 항목을 분리한 추천 매칭 설계
FSD 구조 정리·PR 리뷰·비교 대상 누락 수정

핵심 결과

자격 여부와 추천 근거를 화면에 연결하고,
선택한 정책을 비교할 수 있는 흐름 구현

추천 자격 조건: 8개; 연령 · 지역 · 직업 등
추천 평가 항목: 10개; 가중치를 적용한 적합도 점수
한 번에 비교할 정책: 2–3개; 요청 순서 유지 · 중복·누락 검증

직접 구현한 정책 추천·비교 규칙

MATCHING DESIGN

신청 자격과 추천 적합도를
서로 다른 규칙으로 설계했습니다

조건에 맞는 정책 선별 → 상대적인 추천 순서 결정

판단

신청 불가능한 정책과 덜 적합한 정책을 구분해야 함
사용자 입력값과 정책 데이터의 코드 체계가 다름

구현

자격 조건 8개: 연령·지역·직업·학력·혼인·전공·특수조건·소득
평가 항목 10개로 점수 계산 · 가중치 합계 100
입력값을 정책 코드로 매핑하고 허용 값 검증
matchedAxes를 반환해 화면에서 추천 근거 표시

개선

클라이언트 임시 점수를 서버 매칭 결과로 교체

01 · ELIGIBILITY자격 조건 · 8개

필수 조건을 충족하는 후보 선별

02 · RELEVANCE평가 항목 · 10개

적합도를 계산해 추천 순서 결정

추천 결과 + 매칭 근거

선택 이유를 사용자에게 설명

DATA BOUNDARY BUG

선택한 정책이 목록 밖에 있어도
비교할 수 있도록 조회 방식을 바꿨습니다

현재 화면의 데이터 범위와 사용자의 선택 범위를 구분

문제

비교 대상 정책을 최신 100개 목록에서만 탐색
선택한 ID가 목록에 없으면 비교 데이터 누락

수정

선택한 정책 ID로 상세 데이터를 별도 조회
useQueries로 여러 대상 조회를 연결
서버 비교 API에서 2–3개 대상·중복·존재 여부 검증

결과

목록에 노출되는 범위와 비교 가능한 범위를 분리

BEFORE최신 목록 안에서 찾기

선택 ID → 최신 100개 목록 검색
목록 밖이면 상세 정보 누락

AFTER선택 ID로 직접 조회

선택 ID → 상세 API 조회
현재 목록과 관계없이 비교 구성

STRUCTURE & REVIEW

큰 화면 파일을 나누고,
리뷰 기준으로 구조를 유지했습니다

AI 생성 초안의 활용과 팀 개발 기준 정리

출발점

Lovable 기반 UI 초안의 App.tsx에 2,094줄 집중
화면·상태·API 코드가 섞여 수정 경계가 불분명

실행

Claude Code를 활용해 FSD 기준으로 코드 분리
pages·widgets·features·entities·shared 역할 정리
프론트엔드 PR 리뷰에 도구를 활용해 경계·중복 확인

협업

Git 사용 지원과 리뷰로 팀원이 구조에 맞춰 개발하도록 안내

pages

페이지 조합

widgets

독립된 화면 영역

features

사용자 행동

entities

도메인 모델

shared

공통 기반

도구의 초안·제안에 프로젝트 기준을 적용하며 리뷰

NEXT PROJECTReadyVery

PROJECT 03 · 창업팀 · 실제 서비스 운영

ReadyVery

카페에서 교내 축제까지 확장한
모바일 주문·결제 서비스

기간: 2023.10–2024.06
담당 역할: 프론트엔드 개발
기술: React · Recoil · axios · Toss Payments

주요 기여

가게·상품 옵션·장바구니·쿠폰·주문 상태 구현
Toss Payments 연동과 할인 결제 금액 정합성 수정
axios 훅 분리·피드백 기반 UI 개편·축제 흐름 확장

핵심 결과

카페 주문 서비스를 축제 환경으로 확장해
학생의 주문과 주점 운영을 지원

축제 결제액 · 팀 성과: 약 1,200만 원; 서비스를 거친 주문·결제
협업 주점 · 팀 운영: 약 10개; 교내 축제 주점과 협업
축제 운영 기간: 2일; 카페 주문 흐름을 축제로 확장

축제 수치는 팀 서비스 운영 성과 · 개인 경험 기록 기준

PAYMENT BUG

쿠폰 적용 뒤의 결제 금액을
위젯에도 동일하게 반영했습니다

사용자에게 보이는 금액과 결제 요청 금액의 일치

문제

주문 가격·할인 상태가 바뀌면 결제 위젯 금액도 갱신 필요
초기 금액과 변경 금액에 서로 다른 계산이 적용될 위험

수정

초기 렌더링과 updateAmount에 같은 할인 계산 적용
price와 salePrice를 useEffect 의존성에 반영

핵심 관점

화면 표시와 외부 결제 위젯의 상태를 함께 확인

PAYMENT AMOUNT

const amount = price - salePrice;

// 위젯 초기 금액에도 동일 계산 적용
useEffect(() => {
  paymentMethods.updateAmount(amount);
}, [price, salePrice]);

실제 변경 내용을 설명하기 위한 축약 코드

SERVICE OPERATIONS

카페 주문 흐름을
교내 축제의 주문 환경으로 확장했습니다

사용 환경 변화에 맞춘 기능 개발과 팀 서비스 운영

상황과 기여

축제기획단 제휴로 교내 주점 주문·결제에 서비스 활용
축제 부스 탐색·검색 등 관련 프론트엔드 기능 구현
학생·운영진의 사용 피드백을 팀과 공유

배운 점

새 사용 환경에서는 주문 맥락·이동 흐름도 함께 확인
자신의 화면 외에 운영·기획의 제약을 이해하며 협업

팀 서비스 운영 성과10개 주점

약 1,200만 원

축제 이틀 동안 서비스를 거친 결제액
팀 서비스 운영 수치 · 개인 경험 기록 기준

NEXT PROJECTProlog

PROJECT 04 · 팀 프로젝트 · 풀스택

Prolog

기술 글과 지식을 공유하는
개발자 블로그 서비스

기간: 2025.05–06
담당 역할: 풀스택 개발
기술: Next.js · TypeScript · Prisma

주요 기여

게시글 상세를 실제 DB 조회와 서버 렌더링으로 연결
댓글 CRUD·개수 표시·북마크 API와 UI 구현
유스케이스·저장소 분리와 작성자 권한 검증

핵심 결과

게시글 삭제 시 현재 사용자와 작성자를 대조해
유스케이스에서 데이터 소유권을 검증

담당 기능 영역: 3개; 게시글 상세 · 댓글 · 북마크
댓글 처리: 4가지; 생성 · 조회 · 수정 · 삭제
게시글 상세 렌더링: SSR; Next.js 서버 렌더링 활용

개인 담당 기능과 구현 방식

AUTHORIZATION

게시글 삭제 권한을
유스케이스에서 검증했습니다

사용자 인터페이스의 표시 조건과 서버의 권한 규칙 분리

판단

삭제 버튼을 숨기는 것만으로 요청을 제한할 수 없음
다른 진입 경로에서도 작성자 검증이 적용되어야 함

구현

유스케이스에서 게시글과 현재 사용자 확인
currentUserId와 post.userId 비교 후 삭제 수행

결과

화면 표시와 무관하게 서버 처리의 소유권 규칙 적용

삭제 요청현재 사용자 식별

게시글 소유권 검증현재 사용자 ID = 작성자 ID

조건 충족 시 삭제검증 실패는 삭제를 수행하지 않음

권한 규칙의 위치를 실행 경로보다 안쪽에 배치

BEFORE & AFTER

같은 삭제 기능, 달라진 검증 기준

MoCha → Prolog · 로그인 확인에서 데이터 소유권 검증까지

BEFORE · MoCha · 2025.04

사용자 식별에서 멈춘 검증

토큰을 검증해 사용자 ID 추출
삭제 유스케이스에는 대상 ID만 전달
유스케이스에 작성자 대조 과정이 없음

const { user } = verifyAccessToken(token);

await usecase.execute(transactionId);

AFTER · Prolog · 2025.06

유스케이스에서 작성자까지 확인

현재 사용자 ID를 유스케이스로 전달
게시글을 조회해 작성자 ID와 대조
불일치하면 예외 처리 후 삭제 중단

if (post.userId !== currentUserId) {
  throw new Error('권한이 없습니다.');
}
await repository.deletePost(postId);

이후의 개발 기준

로그인 여부와 데이터 소유권을 구분하고, 핵심 권한 규칙은 유스케이스에서 검증

각 프로젝트의 실제 구현을 비교 · 코드는 핵심 처리만 축약

NEXT PROJECTCoedu