프로젝트 소개

제니스는 광고 운영, 이벤트 관리, 사용자 관리, 내부 협업 업무를 하나의 관리자 시스템 안에서 처리할 수 있도록 만든 CodeIgniter 4 기반 사내 운영 도구입니다. 여러 광고 매체를 따로따로 운영하는 대신, 운영자가 실제로 사용하는 업무 흐름을 기준으로 광고 리포트 확인, 상태 변경, 자동화 실행 결과 조회, 이벤트 실무 처리, 내부 협업 연동이 한 서비스 안에서 이어지도록 설계했습니다.

이 프로젝트는 외부 공개용 제품이라기보다 실무자가 매일 쓰는 백오피스입니다. 광고 운영 현황을 보고 바로 상태를 조정하고, 자동화 조건을 관리하고, 이벤트 업무와 광고주/블랙리스트/변경 이력 같은 운영 데이터를 함께 다루는 쪽에 초점을 두었습니다.

현재 저장소는 공개 가능한 범위만 정리한 스냅샷입니다. 민감한 SQL, 외부 연동 키, 일부 설정 파일, 모델/라이브러리의 세부 구현은 제외되어 있지만, 포함된 컨트롤러와 뷰, 정적 자산 구조만으로도 전체 서비스가 어떤 업무를 다루는지와 운영 방향은 충분히 읽히도록 구성했습니다.

핵심 기능

• Facebook, Google, Kakao, Naver 등 여러 광고 매체를 한 관리자 안에서 운영
• 홈 화면에서 매체별 리포트 수집 및 운영 현황 확인
• 조건 기반 자동화 실행, 상태 변경, 예산 조정, 실행 결과/로그 조회
• 광고주 관리, 블랙리스트, 변경 이력, 엑셀 업로드, 매체 관리 등 이벤트/운영 실무 지원
• Jira 이슈 상태 변화 연동과 Slack 사용자 알림 발송으로 내부 협업 연결
• 로그인, 매직 링크, 비밀번호 변경 및 변경 주기 체크 등 계정/인증 관리
• 회계, 인사, 회사 정보, 캘린더, 사용자, 통합 관리 같은 공통 관리자 기능 포함
• `public/health.php`를 통한 JSON 헬스체크 응답 제공

구현 포인트

이 프로젝트에서는 광고 운영만 따로 떼어 놓은 도구를 만드는 대신, 사내 운영자가 실제로 같이 쓰는 업무 흐름을 한 백오피스 안에 묶는 방향으로 작업했습니다. 광고 매체 운영, 자동화 실행, 이벤트 실무, 사용자 인증, 외부 협업 도구 연동이 각각 따로 노는 구조가 아니라 하나의 관리자 안에서 이어지도록 정리한 것이 핵심입니다.

구조도 업무 기준으로 나눴습니다. `Accounting`, `Advertisement`, `AdvertisementManager`, `Api`, `Auth`, `Calendar`, `Company`, `EventManage`, `HumanResource`, `Integrate`, `User` 영역으로 나뉘어 있고, 로컬 스냅샷 기준으로 PHP 컨트롤러 36개, View 템플릿 87개 규모로 구성돼 있습니다.

세부적으로는 `HomeController`에서 로그인 사용자의 비밀번호 변경 시점을 확인하고, AJAX 요청에서만 리포트 응답을 내려주며, 예외 발생 시 API 에러 응답을 처리하도록 구성했습니다. `ExampleController`에서는 뷰 이름 화이트리스트 패턴 검증과 존재하지 않는 뷰 접근 차단을 넣었고, `PasswordChangeController`에서는 Shield 비밀번호 정책과 강제 재설정 해제를 다뤘습니다. 단순 화면 나열이 아니라 실무 운영에 필요한 제어 포인트가 컨트롤러 단에서 바로 드러나도록 정리한 프로젝트입니다.

기술 스택

백엔드는 PHP + CodeIgniter 4, 인증은 CodeIgniter Shield, 데이터와 외부 연동은 MySQL, Slack, Jira, 광고 매체 API를 기준으로 구성했습니다. 프론트 정적 에셋은 Bootstrap 5, Bootstrap Icons, jQuery, jQuery UI, DateRangePicker, DataTables, JSZip, pdfmake 기준으로 구성되어 있어, 사내 운영 도구 특유의 테이블 중심 화면과 폼 중심 화면을 빠르게 다룰 수 있도록 맞춰져 있습니다.

저장소 구조

php_ci4_zenith-my-commits/
├── README.md
└── zenith-project/
    ├── .github/
    │   ├── COMMIT_CONVENTION.md
    │   ├── pull_request_template.md
    │   └── workflows/php-lint.yml
    ├── app/
    │   ├── Controllers/
    │   └── Views/
    ├── public/
    │   ├── health.php
    │   └── static/
    ├── composer.json
    └── spark

이 저장소는 공개 가능한 범위만 정리한 버전입니다. 민감한 연동 설정, 일부 모델과 라이브러리, 환경 파일은 제외되어 있어 내부 운영 환경을 그대로 재현하는 용도보다는, 실제 서비스가 어떤 구조와 화면, 컨트롤러 설계, 운영 도메인으로 구성돼 있는지 보여주는 용도에 가깝습니다.

운영 화면

아래 이미지는 제니스 관리자 화면 일부입니다. 통합 광고관리, 운영 데이터 관리, 자동화 목록처럼 운영자가 실제로 자주 사용하는 화면 위주로 정리했고, 좌측 사이드바와 테이블 중심 레이아웃을 통해 사내 운영 도구의 성격이 바로 드러나도록 구성했습니다.

공개 범위와 운영 규칙

저장소에는 커밋 규칙, PR 템플릿, PHP 문법 검사를 위한 GitHub Actions 워크플로우가 함께 들어 있습니다. `.env`, `vendor`, 로그/세션/업로드 파일, `node_modules`, 외부 API 설정 파일, 광고 연동용 비공개 키/설정 파일은 버전 관리에서 제외되도록 정리돼 있어, 운영 환경을 그대로 공개하지 않으면서도 협업 규칙과 코드 구조는 확인할 수 있게 만들었습니다.

제니스 랜딩 운영 모듈

제니스 프로젝트에는 백오피스 외에 광고/이벤트 캠페인용 랜딩 페이지를 실제로 운영하는 별도 PHP 모듈도 함께 있었습니다. 이 모듈은 여러 도메인에서 방문자를 받아 랜딩 페이지를 출력하고, 신청 데이터를 수집한 뒤 중복 검증, 상태 분류, 외부 제휴 전송, 완료 페이지 이동까지 처리하는 실행 계층입니다.

역할을 나누면, 제니스 백오피스가 이벤트, 광고주, 매체, 전송 조건 같은 운영 데이터를 관리하고, 랜딩 운영 모듈은 그 설정을 바탕으로 실제 방문 요청을 받아 처리하는 구조였습니다. 즉 관리자에서 운영 기준을 만들고, 랜딩 모듈이 현장에서 그 기준을 실행하는 형태로 맞물려 있었습니다.

zenith_core.php            # 랜딩 라우팅, 페이지 렌더링, 신청 처리, 완료 페이지 이동
zenith_check_proc.php      # 신청 데이터 검증, 상태 분류, 저장 후처리
zenith_interlock.php       # 외부 제휴 연동 결과 기록 및 재전송 처리
zenith_encryption.php      # 신청 데이터 암복호화
zenith_ip.php              # 방문자 IP 확인, 내부망/차단 처리
zenith_cookie.php          # 운영 쿠키 생성 및 조회
interlock_resend.php       # 특정 실패 건 재전송
interlock_resend_all.php   # 조건 기반 일괄 재전송
zenith_test.php            # 연동/요청 테스트 스크립트
zenith_test_form.php       # 폼 전송 테스트 화면

프로젝트 소개

EventsPack은 학술대회, 정부 행사, 기업 이벤트처럼 일정과 페이지 구성이 자주 바뀌는 행사 사이트를 빠르게 구축하기 위한 웹 솔루션입니다. 템플릿과 레이아웃 리소스를 기반으로 행사 사이트를 조립하고, 사용자 인증과 OAuth 연동을 통해 여러 외부 사이트에서도 동일한 계정 흐름을 사용할 수 있도록 설계했습니다.

제가 맡은 영역은 그중 사용자 인증과 API 연동 계층입니다. 단순 CRUD 서버가 아니라, 외부 서비스가 EventsPack 계정을 통해 인증을 위임받고 API 서버가 사용자 토큰과 리소스 접근 권한을 검증하는 구조를 구현한 것이 핵심이었습니다.

즉 프론트엔드나 외부 사이트 빌더는 이 API를 호출해 로그인 상태와 서비스 리소스 접근 가능 여부를 판단하고, API 서버는 회원/토큰/OAuth client/접근 권한을 책임지는 구조로 역할을 나눴습니다.

핵심 기능

• 회원가입 및 로그인 API 제공
• Laravel Passport 기반 access token 발급
• OAuth client 생성/조회 프록시
• 외부 앱 로그인 상태 확인과 bearer token 기반 강제 로그인 처리
• 요청 컨트롤러/액션 기준 서비스 리소스 접근 권한 확인
• 사이트/레이아웃/내비게이션 정보 API 제공
• 허용 Origin 기반 CORS 처리

구현 포인트

이 프로젝트에서 중요했던 부분은 외부 서비스와 인증 서버 사이의 경계를 명확히 잡는 것이었습니다. EventsPack 계정을 기준으로 외부 사이트에서도 같은 사용자 인증 흐름을 사용할 수 있어야 했기 때문에, Passport 기반 OAuth와 토큰 검증 흐름, OAuth client 프록시, bearer token 기반 강제 로그인 처리까지 한 API 안에서 일관되게 정리했습니다.

접근 권한도 단순 로그인 여부에서 끝나지 않도록 구성했습니다. 요청이 들어온 컨트롤러와 액션 기준으로 서비스 리소스 접근 가능 여부를 판단하게 했고, 프론트나 외부 사이트 빌더는 이 결과를 기준으로 실제 화면 접근과 서비스 사용 가능 여부를 결정할 수 있게 만들었습니다.

인증을 외부 서비스에 위임할 수 있는 구조와 리소스 권한 검증 흐름까지 함께 구현한 점이 이 프로젝트의 핵심입니다.

기술 스택

프로젝트 구조

app/
├── Helper/                 # 메시지, 접근 권한 helper
├── Http/
│   ├── Controllers/Auth/   # 회원가입, 로그인, OAuth client API
│   └── Middleware/         # CORS, 강제 로그인, 권한 확인
├── Providers/
config/                     # Laravel 및 외부 서비스 설정
database/                   # migration, factory, seed
routes/
├── api.php                 # API endpoint
└── web.php                 # Passport/OAuth web route

보완한 부분

• Laravel 실행에 필요한 `bootstrap/` 구조 복구
• `.gitignore`가 `bootstrap` 전체를 제외하던 문제 수정
• Composer/NPM 메타데이터를 프로젝트명 기준으로 정리
• PHP 요구 버전을 lock 파일과 맞게 `7.3+`로 정리
• CORS 허용 Origin을 `.env` 기반 설정으로 분리
• 외부 EventsPack API URL 하드코딩 제거
• `logoutRequest`의 잘못된 HTTP method 수정
• 회원가입 validation 실패 후에도 생성 로직이 진행될 수 있던 흐름 수정
• 라우트에서 호출되는 `register` 메서드 접근 제어자를 public으로 수정
• bearer 검증 실패나 사용자 미존재 시 401로 명확히 차단

실행과 환경 설정

실행 흐름은 Laravel 표준에 Passport 초기화가 추가된 구조입니다. `composer install`, `npm install`, `.env` 복사, `php artisan key:generate`, `php artisan migrate`, `php artisan passport:install`, `php artisan serve` 순서로 구동할 수 있게 정리했고, 주요 환경변수로는 `APP_URL`, DB 계정 정보, `EVENTSPACK_API_BASE_URL`, `EVENTSPACK_ALLOWED_ORIGINS` 등을 사용했습니다.

화면 예시

아래 화면은 EventsPack 사용자 서비스 화면입니다. 행사 사이트를 빠르게 구성할 수 있도록 인증과 권한 검증을 담당한 API 서버를 구현했고, 사용자 경험 뒤에서 계정 흐름과 리소스 접근 제어를 처리했습니다.

관련 저장소

관리자 저장소는 `php_laravel_EventPack_admin`, 사용자 API 저장소는 `php_laravel_EventsPack_dev1` 기준으로 운영했습니다. 사용자 API 계층에서는 OAuth와 서비스 리소스 권한 검증 흐름을 중심으로 구현했습니다.

이벤츠팩 관리자

EventsPack에는 사용자 인증/API 계층과 별도로 운영 데이터를 관리하는 Laravel 관리자 콘솔도 함께 있었습니다. 이 관리자 콘솔은 행사 단위 프로젝트, 사이트 기본 정보, 레이아웃 템플릿, 상단/내비게이션/중단/하단/기타 조각, 기능 팩을 관리하는 백오피스이며, 실제 행사 사이트를 구성하기 위한 기준 데이터를 만드는 역할을 맡았습니다.

역할을 나누면, 사용자 API가 회원/토큰/OAuth/접근 권한 검증을 담당하고, Admin은 사이트를 조립하기 위한 운영 데이터와 템플릿 리소스를 관리하는 구조였습니다. 즉 운영자는 여기서 프로젝트를 만들고 레이아웃과 기능 팩을 조합하며, 이후 사용자 API나 사이트 빌더가 이 데이터를 참조해 실제 행사 사이트를 구성할 수 있도록 준비하는 계층입니다.

app/
├── Http/
│   ├── Controllers/Admin/
│   │   ├── Work/               # 프로젝트 관리
│   │   ├── Layout/             # 레이아웃 및 섹션 관리
│   │   └── Pack/               # 기능 팩 관리
│   ├── Controllers/Auth/       # 관리자 로그인/회원 인증
│   └── Middleware/             # 인증 및 super 권한 검사
├── Layout*.php                 # 레이아웃 관련 모델
├── Pack*.php                   # 팩 관련 모델
├── Site.php                    # 사이트 모델
├── User.php                    # 관리자/사용자 모델
└── Work.php                    # 프로젝트 모델
resources/views/
├── project/                    # 프로젝트 관리 화면
├── template/layout/            # 레이아웃 관리 화면
├── template/pack/              # 팩 관리 화면
└── users/                      # 사용자 관리 화면
database/migrations/
└── 2021_01_01_000001_create_eventspack_admin_tables.php
routes/
└── web.php                     # 관리자 콘솔 라우트

프로젝트 소개

백락온은 건강식품 판매를 위한 Laravel 기반 쇼핑몰 프로젝트입니다. 일반 상품 판매, 정기배송 상품, 연계상품 주문, Toss Payments 결제, 회원/배송지/주문 관리, 관리자 백오피스를 하나의 서비스 흐름으로 구성한 커머스 애플리케이션입니다.

이 프로젝트는 단순 상품 진열 페이지가 아니라 회원가입과 소셜 로그인, 장바구니, 주문 생성, 결제 콜백, 주문 상태 관리, 상품 이미지 업로드, 관리자 CRUD, SMS 알림 기록까지 포함한 실서비스형 쇼핑몰이라는 점이 핵심입니다. 사용자 구매 흐름과 운영 백오피스, 외부 결제와 알림 연동을 하나의 Laravel 프로젝트 안에서 함께 처리하는 구조로 정리했습니다.

핵심 서비스 흐름

1. 사용자가 일반 상품, 정기배송 상품, 연계상품 페이지를 탐색
2. 로그인 사용자 기준으로 장바구니 또는 바로주문 흐름 진행
3. 주문 생성 후 Toss Payments 결제 시도
4. 결제 성공/가상계좌 콜백이 들어오면 주문 상태와 이력 갱신
5. 필요 시 Aligo SMS로 운영 알림을 전송하고 이력 저장
6. 사용자는 마이페이지에서 주문/배송지/회원정보 관리
7. 운영자는 `/admin` 이하 백오피스에서 상품, 주문, 정기배송, 연계상품, 문의, 회원 관리

주요 기능

• 회원가입, 로그인, 이메일 인증, Kakao/Naver 소셜 로그인
• 상품 목록/상세, 장바구니, 일반 주문 생성과 저장
• 정기배송 상품 목록/상세/주문과 일반 주문 모델 분리
• 연계상품 별도 목록/상세/주문 흐름 운영
• Toss Payments 결제 성공 콜백과 가상계좌 입금 상태 처리
• Aligo SMS 운영 알림 전송과 기록 저장
• 마이페이지에서 일반 주문/정기배송/연계상품 주문, 배송지, QnA 관리
• 관리자 백오피스에서 회원/상품/카테고리/주문/문의 통합 관리

기술 스택

프로젝트 구조

100rakon_com/
├── app/
│   ├── Http/Controllers/        # 쇼핑몰, 주문, 결제, 관리자 컨트롤러
│   ├── Http/Middleware/         # 관리자 권한, 배포 모드 검사
│   ├── Product.php              # 일반 상품 모델
│   ├── Subscrib*.php            # 정기배송 관련 모델
│   ├── Outstand*.php            # 연계상품 관련 모델
│   ├── Order*.php               # 일반 주문 관련 모델
│   ├── PayTossTransaction.php   # Toss 결제 이력
│   └── SmsSend.php              # SMS 발송 이력
├── config/
├── database/
│   ├── migrations/
│   ├── factories/
│   └── seeds/
├── public/
├── resources/
│   ├── views/                   # mall, auth, admin Blade 화면
│   ├── sass/
│   └── js/
├── routes/
│   ├── web.php
│   └── api.php
├── storage/
└── bootstrap/

데이터 모델 관점

이 프로젝트는 단일 주문 테이블만 있는 단순 쇼핑몰이 아니라, 일반 주문, 정기배송, 연계상품을 각각 다른 모델 묶음으로 분리해 관리하는 구조가 특징입니다. `User`, `UserAddress`, `Product`, `ProductCategory`, `Order`, `OrderItem`, `OrderBasket`, `OrderHistory`, `SubscribGood`, `SubscribOrder`, `SubscribOrderHistory`, `Outstand`, `OutstandOrder`, `OutstandHistory`, `PayTossTransaction`, `SmsSend`, `Qna` 등으로 나뉘어 있어 구매 유형별 흐름과 이력을 별도로 다룰 수 있게 정리했습니다.

외부 연동과 운영 포인트

결제와 운영 알림이 실제 운영 흐름에 직접 연결돼 있다는 점이 이 프로젝트의 중요한 포인트였습니다. Toss 결제 성공 및 가상계좌 콜백이 들어오면 주문 상태와 주문 이력을 함께 갱신하고, 필요 시 Aligo SMS 운영 알림 기록까지 남기도록 구성했습니다. 관리자 기능도 별도 프로젝트가 아니라 같은 앱 내부 `/admin` 네임스페이스 안에서 함께 운영되며, `check.admin` 미들웨어가 로그인 여부와 `super === 'Y'` 권한을 같이 검사하도록 정리했습니다.

보완한 부분

• Laravel 실행에 필요한 `bootstrap/`과 `config/` 구조 복구
• `.env.example`과 `.gitignore` 추가
• 관리자 접근 미들웨어에서 비로그인 사용자 null 접근 오류 방지
• 관리자 권한이 없는 사용자는 `403`으로 차단
• 허용 IP 환경변수를 `APP_ALLOW_IPS`로 통일
• 상품 상세 조회를 `findOrFail`로 변경해 없는 상품 접근 시 `404` 처리
• 주문 페이지 진입 라우트에 인증 미들웨어 적용
• Toss 가상계좌 콜백에 `secret` 검증 추가
• 잘못된 resource parameter(`oscdx`, `sgcdx`, `sgdx`) 정리
• 중복 등록되던 연계상품 주문 관리자 라우트 제거
• SMS API Key, 운영자 전화번호, 입금 계좌 하드코딩 제거
• README 인코딩 깨짐 수정 및 실행 방법 재작성

화면 예시

메인 화면, 장바구니, 주문조회 흐름을 함께 넣었습니다. 일반 주문, 정기배송, 연계상품, 결제, 백오피스를 하나의 Laravel 커머스 구조로 연결해 구현했습니다.

운영 환경과 주의 사항

이 저장소에는 운영 DB, 실제 결제 키, SMS 계정 정보가 포함되어 있지 않습니다. `public/`에 빌드 결과물이 들어 있어도 수정 개발은 `resources/`와 Laravel Mix 기준으로 진행하는 것이 맞고, Laravel 6 기반 프로젝트이기 때문에 최신 Laravel 관례와는 디렉터리/설정 방식이 일부 다릅니다. 결제와 SMS는 외부 서비스 연동 정보가 있어야 실제 동작합니다.

현재 상태

방치형 게임 템플릿 구조를 먼저 정리하고 있으며, 핵심 루프와 화면 구성을 순차적으로 붙이고 있습니다.

의도한 방향

• 방치형 성장 구조를 빠르게 붙일 수 있는 템플릿 형태로 정리
• 반복 자원 획득, 업그레이드, 성장 수치 루프를 실험하기 위한 기반 준비
• UI와 게임 로직을 분리해 이후 시스템 추가가 쉬운 구조로 확장 예정

진행 방향

전투, 성장, 재화, 업그레이드 루프를 붙일 수 있는 기반 구조를 먼저 잡고 있으며, 실제 시스템이 쌓이는 순서대로 템플릿을 확장할 예정입니다.

저장소

https://github.com/xowlsakffl/idle_game_template

프로젝트 소개

Bithumb RSI Auto Buyer는 빗썸 KRW 마켓을 대상으로 동작하는 자동 매수 봇입니다. 거래대금 상위 마켓을 조회하고, 이동평균과 RSI 조건을 만족하는 종목을 찾아 일일 예산 범위 안에서 매수 시도를 기록하도록 만들었습니다.

이 프로젝트의 핵심은 외부 거래소 API 연동, 주문 전 검증, 예산 제한, 상태 기록, 실거래 안전장치까지 포함한 자동화 구조를 구현한 점입니다. 기본값을 `PAPER=true`로 두고 실제 주문이 발생하지 않도록 설계했으며, 실거래 전 검증 가능한 구조로 정리했습니다.

주요 기능

• `ccxt` 기반 빗썸 연동
• 기본 페이퍼 트레이딩 모드
• `PAPER=false`와 `LIVE_CONFIRM=true`를 동시에 요구하는 실거래 안전장치
• RSI와 이동평균을 조합한 매수 필터
• KRW 마켓 거래대금 상위 종목 스캔
• 일일 KRW 예산 제한
• 주문당 최대 매수 금액과 쿨다운 옵션
• 중복 매수 방지를 위한 로컬 JSON 상태 관리
• 일시적인 네트워크/거래소 오류에 대한 재시도 처리

전략 개요

봇은 거래대금 상위 KRW 마켓을 순회하면서 최근 종가가 이동평균선보다 높고, RSI가 설정한 매수 기준값보다 낮은 종목을 찾습니다. 조건을 만족하는 후보가 여러 개라면 RSI가 가장 낮은 종목을 우선 선택합니다.

전략 자체는 의도적으로 단순하게 유지했습니다. 이 프로젝트에서 중요했던 부분은 고급 매매 로직이 아니라, 실거래로 이어질 수 있는 자동화 코드에서 주문 전 검증과 예산 제한, 상태 저장, 실거래 차단 로직을 어떻게 넣을지였습니다.

기술 스택

프로젝트 구조

실행과 안전장치

기본 실행 모드는 페이퍼 트레이딩입니다. `PAPER=true`와 `RUN_ONCE=true`로 한 번만 실행하는 방식으로 테스트할 수 있고, 실거래는 `PAPER=false`, `LIVE_CONFIRM=true`, API Key/Secret이 모두 설정된 경우에만 동작하게 해 실수로 실제 주문이 나가지 않도록 했습니다.

PAPER=false
LIVE_CONFIRM=true
BITHUMB_API_KEY=your-api-key
BITHUMB_API_SECRET=your-api-secret

상태는 `state.json`에 저장합니다. 오늘 사용한 KRW 금액, 오늘 이미 매수한 심볼, 마지막 매수 시각을 기록해 중복 매수와 예산 초과를 막고, 쿨다운 체크까지 가능하도록 했습니다.

테스트와 주의 사항

테스트는 `requirements-dev.txt`와 `pytest` 기준으로 구성했고, 실거래 전에는 반드시 `PAPER=true` 상태로 충분히 검증해야 한다는 점을 전제로 했습니다. 또한 빗썸 최소 주문 금액, API 권한, 수수료 정책을 먼저 확인해야 하며, API Key와 Secret은 절대 Git에 커밋하지 않도록 구조를 분리했습니다.

현재 코드는 매도 로직, 리밸런싱, 변동성 기반 포지션 사이징, 백테스트, 손실 제한 로직까지 포함한 완성형 트레이딩 시스템이 아니라, 실거래 안전장치와 상태 관리까지 포함한 매수 자동화 구조를 보여주는 프로젝트입니다.

저장소

https://github.com/xowlsakffl/auth-bithumb-buyer

프로젝트 소개

GameHub는 디스코드형 게임 파티 운영을 위한 멀티 모듈 기반 웹 서비스입니다. 사용자 인증, 친구 기능, 파티 모집/참가, 실시간 채팅, 음성채널 상태, 권한/초대/뮤트 관리, 프론트엔드 번들 통합까지 포함한 Spring Boot + React 모노레포로 구성했습니다.

이 프로젝트의 핵심은 단일 백엔드가 아니라 `domain / core / user-api / admin-api / front-end`로 역할을 나눈 상태에서 JWT 인증, WebSocket(STOMP) 실시간 이벤트, 파티 멤버 권한 정책, 초대코드 기반 진입 흐름, 프론트 빌드 산출물의 백엔드 통합까지 실제 서비스 구조로 연결했다는 점입니다.

핵심 서비스 흐름

1. 사용자가 `/api/auth/signup`, `/api/auth/login`으로 가입하거나 로그인
2. JWT 기반 인증 상태로 친구, 파티, 채팅, 음성채널 API 호출
3. 사용자는 파티를 생성하거나 초대코드/참가 요청을 통해 파티 입장
4. 멤버 권한(`LEADER`, `MANAGER`, `MEMBER`)에 따라 수정, 승인, 강퇴, 위임, 뮤트 적용
5. 채팅은 REST 조회와 STOMP 실시간 송수신을 함께 사용하고 읽음 상태를 별도로 관리
6. 음성채널 이벤트는 파티 토픽과 사용자 전용 큐로 브로드캐스트
7. 프론트엔드는 Vite로 빌드되고, 결과물은 `onion-user-api` 정적 리소스로 복사되어 함께 서빙

주요 기능

• 회원가입, 로그인, 이메일/닉네임 중복 확인과 JWT 발급
• 친구 요청, 수락, 거절, 친구 목록 관리
• 파티 생성/수정/삭제/상태 변경과 목록/상세 조회
• 자동참가/승인참가 방식의 파티 참여 흐름
• 파티 멤버 강퇴, 방장 위임, 운영진 권한 관리, 뮤트/해제
• 채팅 메시지 조회, 읽음 상태 관리, STOMP 기반 실시간 채팅 송수신
• 음성채널 입장/퇴장/이동 상태 브로드캐스트
• 사용자 전용 큐(`/user/queue/notifications`) 실시간 푸시 알림
• 초대코드 조회/재발급/코드 입장 흐름

기술 스택

주요 화면

프로젝트 구조

onion/
├── onion-domain/                  # Entity, Enum, Repository
├── onion-core/                    # DTO, Service, Security, Exception
├── onion-user-api/                # 사용자 REST API, WebSocket, 정적 리소스 서빙
├── onion-admin-api/               # 관리자 API 확장 모듈
├── front-end/                     # React + Vite 프론트엔드
├── postman/                       # Postman 컬렉션
├── build.gradle                   # 루트 Gradle 설정
└── settings.gradle                # 멀티 모듈 구성

모듈별 역할

`onion-domain`은 엔티티와 Enum, Repository를 담당하고, `onion-core`는 서비스 로직, DTO, JWT 보안 구성, 공통 예외 처리, ModelMapper 기반 매핑을 담당합니다. `onion-user-api`는 인증/친구/파티/채팅/음성 API와 WebSocket 설정, 프론트 정적 리소스 서빙까지 맡고, `onion-admin-api`는 운영 기능을 확장하기 위한 관리자 API 모듈입니다. `front-end`는 React 라우팅과 파티 카드, 친구 패널 UI, Axios 기반 API 호출을 담당합니다.

구현 포인트

이 프로젝트에서 중요했던 부분은 REST API만 구현하는 데서 끝나지 않고, JWT 기반 인증과 실시간 이벤트를 서비스 흐름에 자연스럽게 연결하는 것이었습니다. 파티 멤버 권한을 `LEADER`, `MANAGER`, `MEMBER`로 나누고, 수정/승인/강퇴/위임/뮤트 정책을 세분화해 운영 기준이 코드 구조에 직접 드러나게 정리했습니다.

WebSocket 쪽도 단순 채팅 푸시가 아니라, 실시간 채팅과 읽음 상태 저장/조회 API, 음성채널 접속 상태, 파티 브로드캐스트, 사용자 푸시 알림까지 연결했습니다. 특히 WebSocket JWT 인증 인터셉터와 인바운드 채널 보안을 추가해 실시간 계층도 REST와 같은 인증 기준으로 관리되도록 보완했습니다.

배포 구조 역시 포인트였습니다. `onion-user-api`가 Gradle `node` 플러그인을 통해 `front-end`의 `npm run build`를 수행하고, 결과물을 `src/main/resources/static`으로 복사하도록 구성해 프론트 별도 개발 서버와 백엔드 통합 배포 두 방식을 모두 지원하도록 정리했습니다.

보완한 부분

• 프론트 산출물 복사 경로를 `build`에서 `dist`로 정정
• 사용자 API 정적 리소스 산출물 추적 정책 정리
• 파티 상태 변경 시 잘못된 status 입력 `500` 오류를 `400` 처리로 보완
• 파티/친구/파티 쓰기 API 인증 정책 강화
• 파티 생성/참가 요청 입력값 검증 추가
• 참가 요청 중복 검사 로직을 존재 쿼리 기반으로 최적화
• WebSocket JWT 인증 인터셉터 및 인바운드 채널 보안 추가
• 실시간 채팅 + 읽음 상태 저장/조회 API 추가
• 음성채널 접속 상태 + 파티 브로드캐스트 + 사용자 푸시 알림 추가
• 권한 체계 확장(`LEADER` / `MANAGER` / `MEMBER`) 및 강퇴 정책 세분화
• 파티 뮤트/해제 기능 및 뮤트 시 채팅/음성 차단 적용
• 파티 초대코드 조회/재발급/입장 흐름 추가

운영과 실행 관점

현재 핵심 실행 모듈은 `onion-user-api`입니다. `onion-admin-api`는 관리자 API 확장 지점 성격이 강하고, 테스트 태스크는 각 모듈에서 `enabled = false`로 비활성화되어 있습니다. JPA 설정은 `ddl-auto: update`, `show-sql: true` 기준이며, 프론트엔드 `dist` 산출물은 이미 `onion-user-api/src/main/resources/static` 아래에도 반영되는 구조입니다.

이 프로젝트는 멀티 모듈 백엔드와 React 프론트가 결합된 게임 파티 허브형 웹 서비스 모노레포입니다.

저장소

https://github.com/xowlsakffl/gameHub-multi-module-

프로젝트 소개

`SNS Service`는 게시글 기반 소셜 피드, 댓글, 좋아요, 알림, 신고 처리까지 포함한 풀스택 SNS 프로젝트입니다. 백엔드는 Spring Boot로 인증/도메인/API를 담당하고, 프론트엔드는 React로 피드 경험을 제공하도록 구성했습니다.

프론트 UI는 Instagram 웹/모바일 피드 구조를 참고한 클론형 인터페이스로 정리했습니다. 브랜드를 그대로 재사용한 것이 아니라, 피드 카드, 스토리, 하단 탭, 단일 컬럼 소비 흐름 같은 UI 패턴을 참고해 구현했고, 현재는 PC에서도 모바일과 같은 단일 컬럼 레이아웃으로 동작합니다.

인증, 실시간 이벤트, 콘텐츠 관리, 프론트 UI 흐름까지 한 번에 포함한 통합 레포지토리입니다.

핵심 서비스 흐름

1. 사용자가 회원가입 또는 로그인 후 JWT를 발급받아 인증 상태를 유지
2. 단일 컬럼 피드 UI에서 게시글 목록을 무한 스크롤로 소비하고, 상세/댓글/알림 화면까지 같은 흐름으로 이동
3. 인증 사용자는 게시글 작성/수정/삭제, 댓글 작성, 좋아요 같은 쓰기 API를 호출
4. 좋아요와 댓글 이벤트가 발생하면 SSE 구독 사용자에게 알림을 전송
5. 사용자는 부적절한 게시글을 신고할 수 있고, 신고 누적 임계치에 따라 자동 블라인드 처리
6. 관리자는 신고 목록을 검색하고 승인/반려 및 집계 API로 운영 현황을 확인

주요 기능

기술 스택

프로젝트 구조

sns_service/
├── src/main/java/dev/be/snsservice/
│   ├── configuration/           # Security, Redis, JWT, Local seed
│   ├── controller/              # User/Post/Report API
│   │   ├── request/             # 요청 DTO
│   │   └── response/            # 응답 DTO
│   ├── exception/               # 예외/에러코드/전역 핸들러
│   ├── model/                   # 도메인 모델, enum
│   │   └── entity/              # JPA Entity
│   ├── repository/              # JPA/캐시/SSE Repository
│   ├── service/                 # 비즈니스 로직
│   └── util/                    # JWT/유틸
├── src/main/resources/
│   └── application.yml
├── front-end/                   # React 프론트엔드
│   ├── src/layouts/             # 피드/인증/알림/게시글 화면
│   ├── src/hooks/               # 무한 스크롤 훅
│   ├── src/utils/               # 프로필/이미지 메타, 병합 유틸
│   └── screenshots/mobile/      # README용 모바일 화면 캡처
├── database/                    # DB 도커 설정
├── redis/                       # Redis 도커 설정
└── docker-compose-local.yml

구현 포인트

이 프로젝트에서 중요한 부분은 백엔드 기능 구현만이 아니라, 그 기능이 실제 피드 UI 경험과 자연스럽게 연결되도록 만드는 것이었습니다. 피드 카드, 스토리, 하단 탭, 게시글 상세, 댓글, 알림 화면을 같은 톤으로 묶고, PC에서도 모바일과 같은 단일 컬럼 레이아웃으로 고정해 소비 흐름을 일관되게 만들었습니다.

백엔드 쪽은 JWT 인증을 전제로 쓰기 API를 보호하고, 좋아요와 댓글 이벤트를 SSE 알림으로 연결했습니다. 또한 게시글 수정/삭제 권한 체크를 엔티티 참조 비교가 아니라 ID 비교로 정리하고, JWT/SSE 구독 처리 안정성과 요청 검증 및 전역 예외 응답 구조를 보강했습니다.

신고 기능도 단순 등록에서 끝내지 않고, 누적 임계치 기반 자동 블라인드와 관리자 승인/반려, 검색과 집계 API까지 넣어 운영형 서비스 관점으로 확장했습니다. 즉 사용자 경험은 익숙한 피드 UI 패턴으로, 운영 기능은 실제 관리 흐름으로 연결한 점이 이 프로젝트의 핵심입니다.

보완한 부분

실행과 데모 환경

.\gradlew.bat build
.\gradlew.bat bootRun

cd front-end
npm install
npm run start

docker compose -f docker-compose-local.yml up -d

화면 예시

모든 이미지는 모바일 기준 캡처입니다. 로그인, 회원가입, 피드, 게시글 작성, 내 게시물, 게시글 상세, 알림 화면 순서로 정리했습니다.

저장소

https://github.com/xowlsakffl/sns_service.git

프로젝트 소개

주차장 추천은 사용자가 입력한 주소를 기준으로 주변 주차장을 탐색하고, 거리 기준 추천 결과를 지도와 카드 UI로 보여주는 Spring Boot 기반 웹 솔루션입니다.

핵심은 단순 목록 조회가 아니라, 주소 검색 API(Kakao Local), 거리 계산, 추천 순위, 단축 URL, 길안내와 로드뷰 이동을 하나의 검색 경험으로 연결한 점입니다. 검색 화면에서 반경과 추천 개수를 조절하고, 결과 화면에서는 지도와 추천 카드를 함께 보며 위치와 이동 동선을 바로 비교할 수 있도록 구성했습니다.

프로젝트 포인트

• 주소 검색부터 추천 결과 확인까지 이어지는 웹 솔루션 흐름 구현
• 지도 중심 결과 화면과 추천 카드 UI 구성
• 반경/추천 개수 조절, 정렬 옵션, 추천 이유 배지 제공
• Base62 기반 단축 URL(`/dir/{encodedId}`) 생성
• 길안내 / 로드뷰 / 링크 복사 액션 제공
• 잘못된 단축 URL 접근 시 메인 화면으로 안전하게 복귀

현재 구현 기능

기술 스택

프로젝트 구조

src/
├── main/
│   ├── java/dev/be/parkingmap/
│   │   ├── api/                 # Kakao API 연동 서비스/DTO
│   │   ├── direction/           # 단축 URL, 방향/링크 처리
│   │   ├── parking/             # 주차장 조회/추천 서비스
│   │   └── config/              # Retry, RestTemplate 설정
│   └── resources/
│       ├── static/              # 공통 CSS, JS
│       ├── templates/           # main.hbs, output.hbs
│       └── application.yaml
└── test/
    ├── groovy/
    └── java/

database/
├── init/
└── config/

실행 방법

$env:SPRING_PROFILES_ACTIVE="local"
$env:SPRING_DATASOURCE_DRIVER_CLASS_NAME="org.h2.Driver"
$env:SPRING_DATASOURCE_URL="jdbc:h2:mem:parking-preview;MODE=MySQL;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE"
$env:SPRING_DATASOURCE_USERNAME="sa"
$env:SPRING_DATASOURCE_PASSWORD=""
$env:SPRING_JPA_HIBERNATE_DDL_AUTO="create-drop"
$env:KAKAO_REST_API_KEY="your_kakao_rest_api_key"
$env:PARKING_RECOMMENDATION_BASE_URL="http://localhost:8080/dir/"
.\gradlew.bat bootRun

docker compose -f docker-compose-local.yml up -d

$env:SPRING_DATASOURCE_USERNAME="root"
$env:SPRING_DATASOURCE_PASSWORD="your_password"
$env:KAKAO_REST_API_KEY="your_kakao_rest_api_key"
.\gradlew.bat bootRun

주요 환경변수

개선한 내용

• 입력 DTO에 주소 trim / 옵션 sanitize 추가
• 공백 주소 요청 차단 및 서비스 경계 방어 강화
• 단축 URL 예외 처리 보강
• 결과 화면을 테이블 중심에서 지도 + 카드 UI로 개편
• 정렬 옵션과 추천 이유 배지 추가
• H2 인메모리 DB 기반 프리뷰/테스트 환경 정리
• JDK 21 환경에서도 빌드 가능하도록 toolchain / Lombok 정리

프로젝트 의미

이 프로젝트는 CRUD보다는 검색 경험 설계에 더 가깝습니다. 주소 입력, 거리 계산, 추천 순위, 지도 표현, 링크 이동까지 이어지는 흐름을 웹 UI로 완성했다는 점이 핵심입니다.

특히 결과 화면을 `지도 + 추천 카드 + 정렬 옵션 + 추천 이유` 구조로 정리하면서, 실제 서비스 화면에 가깝게 구성했습니다.

화면 예시

프로젝트 소개

기어허브는 컴퓨팅, 오디오, 게이밍, 모바일 액세서리를 중심으로 한 전자제품 전문 이커머스 서비스입니다. 프론트엔드는 React + Vite 기반으로 사용자 쇼핑몰 화면과 관리자 운영 콘솔을 구성했고, 백엔드는 Spring Boot 기반으로 인증, 상품, 장바구니, 배송지, 주문/결제, 관리자 API를 제공합니다.

핵심은 프론트에서 `shop / admin / components / store / api`, 백엔드에서 `controller / service / repository / model / payload / security`로 역할을 분리하고, JWT 인증 상태를 기준으로 사용자 쇼핑 흐름과 관리자 운영 흐름을 명확히 나눈 점입니다. 사용자단과 관리자단을 모두 갖춘 구조로 구성했습니다.

이 저장소들이 맡는 역할

핵심 서비스 흐름

1. 사용자는 홈 또는 스토어 화면에서 전자제품을 탐색하고 상세 페이지로 이동합니다.
2. 장바구니에서 상품 수량과 결제 예정 금액을 확인한 뒤 체크아웃으로 이동합니다.
3. 배송지를 선택하고 결제 수단을 고른 다음 주문 요약을 확인합니다.
4. 데모 결제에서는 실제 결제 승인 없이 서버 장바구니를 동기화한 뒤 주문을 생성합니다.
5. 주문 완료 후 마이페이지의 주문 내역에서 주문 상태와 상품 구성을 확인합니다.
6. 백엔드는 `/api/auth/signin` 이후 JWT를 발급하고, 이후 요청은 `Authorization: Bearer` 헤더 기준으로 처리합니다.
7. 관리자 계정은 `/admin`과 `/api/admin/**` 경로에서 상품, 카테고리, 주문 상태를 운영합니다.

주요 기능

기술 스택

프로젝트 구조

src/
├── api/                         # Axios 인스턴스, JWT 헤더 주입
├── assets/                      # 정적 에셋
├── components/
│   ├── account/                 # 마이페이지, 주문 내역
│   ├── auth/                    # 로그인, 회원가입
│   ├── cart/                    # 장바구니
│   ├── checkout/                # 배송지, 결제 수단, 주문 요약
│   ├── home/                    # 홈 화면, 배너
│   ├── products/                # 상품 목록, 필터, 상세
│   └── shared/                  # 공통 UI
├── hooks/                       # 상품 필터 훅
├── modules/
│   ├── admin/                   # 관리자 라우트와 화면
│   └── shop/                    # 사용자 쇼핑몰 라우트
├── store/                       # Redux store, reducer, action
└── utils/                       # 가격 포맷, 텍스트 유틸

src/main/java/com/ecommerce/project/
├── config/                      # 공통 설정, 데모 데이터, 정적 이미지 핸들러
├── controller/                  # REST API 컨트롤러
├── exceptions/                  # 공통 예외와 전역 예외 처리
├── model/                       # JPA Entity, Role Enum
├── payload/                     # DTO, API 응답 객체
├── repository/                  # Spring Data JPA Repository
├── security/                    # SecurityFilterChain, JWT 필터, 요청/응답 DTO
├── service/                     # 비즈니스 로직
└── util/                        # 인증 사용자 조회 유틸

src/main/resources/
└── application.properties       # 서버, DB, JWT, CORS, Stripe 설정

구현 포인트

실행 준비

npm install
npm run dev

npm run build
npm run preview

.\mvnw.cmd spring-boot:run

.\mvnw.cmd -DskipTests package

java -jar target/sb-ecom-0.0.1-SNAPSHOT.jar

주요 환경 변수

데모 계정과 데이터

프론트와 백엔드 모두 `demo / password123!`, `admin / admin1234!` 계정을 기준으로 정리했습니다. 백엔드의 `DemoDataInitializer`는 서버 시작 시 사용자 계정, 관리자 계정, 전자제품 카테고리, 데모 상품, 배송지, 장바구니를 보강해 로컬에서 바로 사용자 흐름과 관리자 흐름을 확인할 수 있게 구성했습니다.

보완한 부분

화면 구성

사용자 화면

관리자 화면

관련 저장소

https://github.com/xowlsakffl/Gearhub_react

https://github.com/xowlsakffl/Gearhub_springboot