JungHoon Control Center backend-portfolio.local
← Projects
PRODUCT · 26.04 ~ 앱 테스트 중

WorKey

점주가 매달 반복하는 근무표 작성 부담을 줄이는 근무 스케줄 자동 생성 서비스입니다. AI Agent를 기획 검토·API 계약 확인·화면 비교·QA에 활용해 기획·백엔드 API·프론트엔드 앱·품질을 혼자서 체계적으로 관리했고, 운영 인프라(Docker Compose·Traefik·HTTPS·Infisical)는 직접 구축해 로컬 개발을 넘어 실제 운영 가능한 형태로 만든 1인 풀사이클 프로젝트입니다.

{ } API 규격서 보기 OpenAPI 3.1 · 69 endpoints ↗
Java 21Spring Boot 3.5React NativeAI Agent 활용Self-hosted Infra

Role & Scope

WorKey는 점주가 매달 반복하는 근무표 작성 부담을 줄이는 근무 스케줄 자동 생성 서비스입니다. 단순 입력 캘린더가 아니라 매장 운영 조건·직원별 근무 가능 시간·휴무 요청·역할별 필요 인원을 바탕으로 실제 운영에 쓸 수 있는 근무표를 생성·관리하는 것을 목표로 했고, 기획·디자인 프로토타입부터 백엔드 API, 앱 연동 검증, 배포 인프라까지 직접 담당했습니다.

PRODUCT 26.04 ~ 앱 테스트 중
기간
2026.04 ~ 앱 테스트 중
역할
기획 · 백엔드 · 프론트 연동 검증 · 배포 인프라
형태
개인 제품 · 풀사이클 단독 구성
기술 스택
Java 21 · Spring Boot 3.5 · jOOQ · MySQL 8 · React Native · Docker Compose · Traefik · HTTPS · Infisical · OpenAPI
  • 서비스 기획 문서·화면 프로토타입 기준 MVP 범위 정리
  • Spring Boot 백엔드 API 설계 및 OpenAPI 계약 관리
  • Clean Architecture · Hexagonal 의존 방향 고정
  • 카카오 OAuth/JWT 인증과 store-scoped 인가 설계
  • React Native 앱과 백엔드 API 연동 범위 검증
  • Docker Compose · Traefik · HTTPS 배포 서버 구성
  • 자체 호스팅 Infisical 기반 민감정보·환경변수 관리
  • AI Agent 활용 작업 분리 및 진행 관리

Architecture

React Native 앱과 Spring Boot API를 중심으로, Docker Compose가 Traefik·Infisical을 함께 묶어 배포·운영하는 구조입니다.

기획·프로토타입 → React Native 앱 → Spring Boot API → DB · 그리고 Compose·Traefik·Infisical 배포 인프라

flowchart TB
  subgraph Client[사용자 채널]
    App[React Native App]
    Proto[Design Prototype]
  end
  subgraph AppLayer[애플리케이션 계층]
    API[Spring Boot API]
    OpenAPI[OpenAPI Contract]
  end
  subgraph Infra[배포 인프라]
    Compose[Docker Compose]
    Traefik["Traefik<br/>Domain Routing / HTTPS"]
    Infisical["Self-hosted Infisical<br/>Secrets"]
  end
  subgraph Data[데이터 계층]
    DB[(Application DB)]
  end
  App --> API
  Proto -. 화면 기준 .-> App
  API --> OpenAPI
  API --> DB
  Traefik --> API
  Compose --> API
  Compose --> Traefik
  Compose --> Infisical
  Infisical -. 환경변수 / 민감정보 .-> API

AI Agent 활용 · 개발 프로세스로서의 AI

AI Agent를 코드 생성 도구로만 쓰지 않고, 기획부터 검증까지 개발 프로세스의 여러 단계에 활용했습니다.

기획 검토 구현 범위 정리 API 계약 확인 화면 비교 QA 항목 도출 작업 분리

  1. 작업 실행 도구가 아니라 개발 프로세스의 일부로 활용

    코드 작성에만 쓰지 않고 기획 검토, 구현 범위 정리, API 계약 확인, 화면 비교, QA 항목 도출에 AI Agent를 활용했습니다.

    백엔드·프론트엔드·디자인 작업을 각각 독립된 작업 단위로 나누고, 각 Agent에 목적·범위·완료 기준을 명확히 전달해 실행할 수 있도록 정리했습니다.

  2. 문서·계약 기반으로 AI 작업을 통제

    AI가 임의로 기능을 만들지 않도록 기획서·디자인 문서·백엔드 문서·프론트엔드 문서를 기준으로 작업을 지시했습니다.

    API 작업은 live OpenAPI 문서를 기준으로, 프론트엔드 작업은 실제 호출 여부와 타입 반영 여부를, 디자인 작업은 프로토타입 기준 화면 일치도를 기준으로 검증했습니다.

  3. AI 결과를 사람이 다시 검증하는 구조 유지

    AI Agent의 결과를 그대로 신뢰하지 않고 실제 코드·OpenAPI·화면 구현·문서 상태를 다시 확인했습니다.

    완료 여부도 "작업했다"가 아니라 API 호출자 존재 여부, 화면 상태 반영 여부, 실행 증거 여부로 판단해 누락된 연결·문서와 구현의 불일치·MVP 범위 밖 기능을 찾아 후속 작업으로 정리했습니다.

무엇을 AI에 맡기고 무엇을 직접 책임졌는지 — 위임할 영역과 직접 쥐고 있을 영역을 명확히 나눈 것 자체가 이 프로젝트의 운영 방식입니다.

AI에 위임한 영역DELEGATED
  • 기획 검토 · 구현 범위 정리
  • API 계약 확인 · 화면 비교
  • QA 항목 도출 · 작업 분리
직접 책임진 영역BY HAND
  • 제품 문제 정의 · MVP scope-in / scope-out 판단
  • 도메인 · 백엔드 아키텍처 설계 결정
  • 운영 인프라 (Compose · Traefik · HTTPS · Infisical)
  • 완료 기준 판단 · 최종 품질 게이트

What I Did · 무엇을 어떻게 했는지

기획-구현-배포로 이어지는 흐름을 직접 구성하면서, 도메인 설계와 운영 인프라를 한 사이클로 다뤘습니다.

  1. 문제 정의와 MVP 범위 설계

    점주가 매달 반복하는 근무표 작성을 핵심 문제로 정의하고, 전체 기능을 한 번에 구현하기보다 실제 서비스 사용에 필요한 흐름을 MVP 단위로 나눠 우선순위를 정했습니다.

    기획서·디자인 프로토타입·백엔드 API·프론트엔드 구현 상태를 함께 보면서, 기능이 늘어나도 범위가 흐려지지 않도록 구현 대상을 계속 정리했습니다.

  2. 도메인 설계와 백엔드 아키텍처 정리

    자동 휴무 분배, confirmed day-off, 근무 교환, 스케줄 멤버십, 직원 삭제 후 복구 흐름을 유스케이스 중심으로 분리했습니다.

    Clean Architecture · Hexagonal 구조로 Presentation / Application / Domain / Infrastructure 의존 방향을 고정하고, 회원·직원·사업장 경계를 유스케이스 단위로 나눴습니다.

  3. 계약 중심 연동과 화면-API-상태 검증

    live OpenAPI를 기준으로 백엔드 API 존재 여부와 요청/응답 구조를 확인하고, 프론트엔드에서는 API 호출자 존재 여부·타입 반영·화면 상태 반영까지 점검했습니다. 카카오 OAuth/JWT 인증과 store-scoped 인가는 API 레이어에서 검증했습니다.

    문서상 완료·코드상 구현·실제 실행 확인을 구분해 완료 기준을 보수적으로 관리하고, API는 있지만 화면에 연결되지 않은 기능은 MVP 포함 여부를 판단해 후속 작업으로 정리했습니다.

  4. 프로토타입 기준 화면 품질 관리

    디자인 프로토타입을 단순 참고가 아니라 화면 구현의 기준으로 삼아, React Native 화면이 다른 방향으로 구현되지 않도록 화면별 차이를 비교했습니다.

    색상·간격·컴포넌트 구조뿐 아니라 화면의 의도와 사용자 흐름이 유지되는지까지 확인해, "있어 보이지만 서비스 흐름과 연결되지 않은 화면"이 되지 않도록 했습니다.

  5. 운영 가능한 배포 환경 구성

    Docker Compose로 애플리케이션과 인프라 도구를 서비스 단위로 구성하고, Traefik으로 도메인별 라우팅·HTTPS를 설정해 외부에서 접근 가능한 운영 환경을 마련했습니다.

    민감정보와 환경변수는 코드·서버 설정에 직접 노출하지 않고 자체 호스팅 Infisical로 관리해, 개인 프로젝트에서도 실서비스에 가까운 배포·시크릿 구성을 적용했습니다.

Impact · 성과

면접에서 강조할 핵심 어필 포인트입니다.

  • 개인 프로젝트임에도 문제 정의·MVP 범위·기획·디자인 프로토타입·백엔드 API·프론트엔드 앱·배포 환경까지 하나의 제품 개발 흐름으로 관리했습니다.
  • AI Agent를 단순 코드 생성 도구가 아니라 작업 분리·기획 검토·API 계약 확인·화면 품질 비교·QA 항목 도출에 다방면으로 활용해 개발 생산성을 높였습니다.
  • live OpenAPI·프로토타입·실제 프론트엔드 호출 여부를 기준으로 기능 완료를 검증해 백엔드와 프론트엔드 간 불일치를 줄였습니다.
  • "구현했다"에서 끝내지 않고 실제 화면 연결·상태 반영·MVP 포함 여부·출시 가능성 기준으로 품질을 점검해 진행 상황을 과장하지 않았습니다.
  • 카카오 OAuth/JWT 인증, store-scoped 인가, 알림 인박스, TestContainers 통합 테스트로 제품 백엔드 완성도를 확보했습니다.
  • Docker Compose · Traefik · HTTPS · Infisical 기반 배포 환경까지 직접 구성해 로컬 개발을 넘어 운영 가능한 서비스 형태로 확장했습니다.
Action completed