Swimming

Swimming은 쏟아지는 정보와 해야 할 일 속에서, 생각을 정리하고 목표를 향한 첫 행동을 시작하기 어려운 사람들을 위한 서비스입니다. 해야 할 일이 많아 어디서부터 시작해야 할지 막막할 때, 머릿속의 생각을 꺼내 실행 가능한 단위로 정리하고 목표에 집중할 수 있는 환경을 제공합니다.

🚀 서비스 둘러보기

설치 없이 실제 서비스를 열거나, 직접 만든 Arcade 데모를 따라가며 Swimming의 주요 흐름을 먼저 살펴볼 수 있습니다.

🌊 작동 방식

1. Capture	2. Organize	3. Focus
떠오른 생각은 메모로, 다시 볼 자료는 링크로 먼저 남깁니다.	AI의 제안을 확인하고 다음 할 일을 고릅니다.	공간과 시간을 선택하고, 한 가지 일에 집중한 기록을 남깁니다.

이 흐름에는 네 가지 원칙이 있습니다.

• 수집할 때 판단하지 않기 — 생각을 놓치지 않는 것이 먼저입니다.
• 결정을 한 번에 하나씩 하기 — AI는 할 일을 제안하고 선택은 사용자가 합니다.
• 다음 행동만 선명하게 보기 — 오늘 시작할 일을 먼저 계획합니다.
• 해낸 것을 축적하기 — 압박형 경고 대신 완료와 집중 기록을 보여 줍니다.

✦ 주요 기능

01. 할 일을 오늘로 가져오기

해야 할 일이 떠오르면 어디에 둘지 고민하지 않고 먼저 적습니다. 나중에 여유가 생겼을 때 폴더와 상태를 정리하고, 지금 시작할 일은 캘린더로 가져옵니다.

• 아직 분류하기 어려운 일도 미분류 상태로 남겨 생각을 놓치지 않습니다.
• 폴더와 캘린더를 오가며 할 일을 다시 입력하지 않고 이어서 정리합니다.
• 오늘 하기로 고른 일은 그대로 집중 세션으로 연결합니다.

02. 정리하지 않은 생각을 AI와 할 일로 바꾸기

떠오르는 내용을 형식 없이 노트에 적어 두고 할 일로 정리를 선택합니다. AI가 노트 전체를 읽어 실행 가능한 할 일과 어울리는 기존 폴더를 제안하며, 사용자가 확인하기 전에는 아무것도 저장하지 않습니다.

• 이어지는 생각은 하나로 모으고 여러 행동은 나누어, 시작하기 쉬운 할 일 제목으로 정리합니다.
• 미리보기에서 제목과 폴더를 직접 바꾸거나 원하지 않는 항목을 제외하며 최종 결정을 내립니다.
• 승인한 항목만 할 일로 만들고, 원하는 날짜의 계획에 연결하거나 나중을 위해 남겨 둡니다.

03. 많은 할 일 사이에서 지금 할 한 가지 고르기

할 일이 길게 쌓여도 전부를 한꺼번에 판단할 필요는 없습니다. Task Matrix에서 즉시와 중요를 기준으로 일을 나누어 보고, 지금 손을 댈 한 가지를 고릅니다.

• 네 영역을 비교하며 급한 일과 중요한 일을 구분합니다.
• 카드를 옮기는 것만으로 판단과 실행 순서를 함께 정리합니다.
• 마우스나 키보드로 원하는 위치를 조정하며 자신에게 맞는 우선순위를 만듭니다.

04. 나에게 맞는 환경에서 한 가지에 몰입하기

오늘 하기로 한 일에서 한 가지를 고르고, 집중 시간과 공간, 음악을 내 리듬에 맞게 정합니다. Dive Session에 들어가면 필요한 정보만 남아 다른 판단을 줄이고 선택한 일에 머물 수 있습니다.

• 화면을 잠시 벗어났다가 돌아와도 흐르던 집중 시간을 그대로 이어 봅니다.
• 배경과 음악을 조절하고, 필요하지 않은 위젯은 접어 몰입 환경을 단순하게 만듭니다.
• 세션을 마치며 실제 집중 시간과 끝낸 일, 짧은 기록을 남겨 오늘의 성취를 쌓습니다.

05. 저장한 링크를 의미와 맥락으로 다시 보기

다시 보고 싶은 링크는 제목이나 분류를 고민하지 않고 폴더에 저장합니다. AI가 정리한 요약과 개념, 활용 목적을 따라가며 문서의 의미를 빠르게 되짚고 다음 생각으로 확장합니다.

• 목록에서는 저장한 자료를 차분히 읽고, 그래프에서는 같은 개념과 목적을 공유하는 자료를 발견합니다.
• 문서 제목이나 저장 위치가 기억나지 않아도 무엇을 다뤘는지, 왜 저장했는지를 단서로 다시 찾습니다.
• 읽은 자료를 표시하고 필요하면 다시 정리하거나 삭제하며 지식 공간을 계속 다듬습니다.

⚡ 빠르게 시작하기

JDK 21, Node.js 22, Docker와 Docker Compose가 필요합니다. AI 기능에는 OpenAI API key가 필요하며, Google 로그인을 확인하려면 Google OAuth Web Client ID를 준비해야 합니다.

1. 로컬 설정과 PostgreSQL

cp backend/.env.example backend/.env.local
docker compose up -d

복사한 파일의 OPENAI_API_KEY, PLACE_CDN_BASE_URL을 로컬 환경에 맞게 설정합니다. Google 로그인에는 frontend와 backend가 같은 Client ID를 사용해야 합니다.

2. Backend

cd backend
./gradlew bootRun

Backend는 http://localhost:8080에서 실행됩니다.

3. Frontend

새 터미널에서 실행합니다.

cd frontend
npm ci
npm run dev

Frontend는 http://localhost:5173에서 실행됩니다. Vite는 /api와 /ws 요청을 localhost:8080으로 전달합니다.

4. 동작 확인

curl http://localhost:8080/api/health

• Swagger UI: http://localhost:8080/swagger-ui/index.html
• OpenAPI JSON: http://localhost:8080/v3/api-docs

🏗 아키텍처

Frontend와 Backend는 독립 프로세스로 배포되는 모노레포입니다. Backend는 도메인별 Controller → UseCase → Service → Repository 구조를 사용하고, Flyway가 PostgreSQL 스키마 변경을 관리합니다.

flowchart LR
    U[사용자 브라우저]

    subgraph Web[Frontend]
        CF[CloudFront]
        SPA[React SPA · S3]
    end

    subgraph App[Backend]
        NG[Nginx · EC2]
        SB[Spring Boot REST API]
        LR[Lambda Page Renderer]
    end

    subgraph Data[Data & AI]
        PG[(PostgreSQL 17<br/>pgvector)]
        OA[OpenAI API]
        WEB[외부 문서]
    end

    U --> CF
    CF --> SPA
    CF -->|/api/*| NG
    NG --> SB
    SB --> PG
    SB --> OA
    SB -->|정적 HTML 수집| WEB
    SB -. JavaScript 렌더링 폴백 .-> LR
    LR --> WEB

JavaScript로 본문을 만드는 문서는 선택적으로 Lambda에서 렌더링합니다. 이 경로는 기본적으로 비활성화되어 있으며, 정적 HTML 수집이 먼저 실행됩니다.

핵심 데이터 관계

아래 다이어그램은 전체 ERD에서 서비스의 핵심 관계만 추린 것입니다.

erDiagram
    USERS ||--o{ FOLDERS : owns
    USERS ||--o{ TASKS : owns
    USERS ||--o{ NOTES : owns
    USERS ||--o{ SESSIONS : runs
    USERS ||--o{ KNOWLEDGE_NODE : owns

    FOLDERS o|--o{ TASKS : contains
    TASKS ||--o{ DAILY_PLAN_ITEMS : plans
    SESSIONS ||--|{ SESSION_TASKS : contains
    TASKS ||--o{ SESSION_TASKS : focuses

    FOLDERS o|--o{ NOTES : contextualizes
    SESSIONS o|--o{ NOTES : contextualizes

    FOLDERS ||--o{ KNOWLEDGE_SOURCE : collects
    KNOWLEDGE_NODE ||--o| KNOWLEDGE_SOURCE : details
    KNOWLEDGE_NODE ||--o{ KNOWLEDGE_BRANCH : structures
    KNOWLEDGE_NODE ||--o{ KNOWLEDGE_RELATION : connects

• 사용자는 폴더, Task, 메모, 세션과 지식 노드를 소유합니다.
• Task는 폴더 없이 미분류로 둘 수 있고, 캘린더와 세션에서 재사용합니다.
• 개인 세션은 여러 Task와 연결되며 종료 시 실제 집중 시간과 Task별 완료 여부를 보존합니다.
• Knowledge Source는 하나의 폴더에 속하며 여러 Subject와 하나의 Topic에 연결됩니다.
• Subject는 사용자 범위에서 재사용하고 Topic은 Source마다 별도로 생성합니다.

실제 DDL은 Flyway migration, 설계 결정은 Architecture에서 확인할 수 있습니다.

🛠 기술 스택

Backend

기술	적용 영역	채택 이유
Java 21 · Spring Boot 4.1	REST API와 도메인 로직	객체지향의 캡슐화·다형성과 정적 타입 안정성을 활용해 도메인의 상태와 행위를 구조적으로 모델링하고, 인증·검증·데이터 접근을 Spring 생태계 안에서 통합
Spring Data JPA	영속성 계층	단건 변경 감지와 Repository 기반 데이터 접근을 일관된 방식으로 구성
PostgreSQL 17 · pgvector	관계형 데이터와 임베딩 저장	트랜잭션 데이터와 벡터 검색 데이터를 하나의 저장소에서 관리
Flyway	DB 스키마 버전 관리	애플리케이션 배포와 스키마 변경 이력을 재현 가능한 마이그레이션으로 관리
Spring Security · JWT · Google OAuth	인증·인가	무상태 API 인증과 Google 로그인을 동일한 보안 계층에서 처리
Caffeine	공휴일 데이터 캐시	과거·현재·미래의 변경 가능성에 따라 TTL을 다르게 적용해 반복되는 외부 API 호출을 줄임
jsoup · Readability4J	링크 본문 수집	정적 HTML 파싱과 본문 추출을 우선 수행하고 필요한 경우에만 Lambda 렌더링 사용

Frontend

기술	적용 영역	채택 이유
React 19 · TypeScript 6	SPA 화면과 기능 컴포넌트	기능별 UI를 컴포넌트로 분리하고 API·상태 모델의 타입 안정성 확보
Vite 8	개발 서버와 프로덕션 빌드	빠른 개발 환경과 /api, /ws 프록시를 단순한 설정으로 제공
Zustand	클라이언트 상태 관리	인증·폴더·Task·세션 상태를 기능별 store로 나누고 필요한 상태만 구독
React Router	클라이언트 라우팅	로그인 상태와 기능 화면에 따른 SPA 라우팅 구성
Axios	API 통신	공통 API 클라이언트에서 인증 헤더와 오류 처리를 일관되게 적용
React Flow	지식 그래프	Source·Subject·Topic 관계를 탐색 가능한 노드 그래프로 시각화
CSS Modules · Design Tokens	화면 스타일	컴포넌트별 스타일 범위를 격리하면서 색상·간격·폰트를 공통 토큰으로 관리

Infrastructure

기술·서비스	적용 영역	채택 이유
Terraform	AWS 인프라 관리	네트워크·컴퓨팅·스토리지·권한 구성을 코드로 관리하고 변경 전 plan 검증
CloudFront · S3	Frontend 배포	정적 SPA를 비공개 S3에 저장하고 CloudFront OAC를 통해서만 제공
EC2 · Docker Compose · Nginx	Backend 운영	현재 규모에서 단일 호스트 배포 구조를 유지하면서 컨테이너 실행과 TLS 종단 처리
RDS for PostgreSQL	운영 데이터베이스	애플리케이션과 분리된 private subnet에서 암호화·백업·삭제 방지 적용
AWS Lambda	JavaScript 페이지 렌더링 인프라	브라우저 워크로드를 Backend 컨테이너에서 격리하고 필요한 요청에만 실행
ECR	컨테이너 이미지 저장	변경 불가능한 커밋 SHA 태그와 push 시 이미지 스캔으로 배포 이미지 관리
IAM · SSM · Secrets Manager	접근 및 비밀 관리	장기 Access Key와 SSH 포트 없이 역할 기반 배포·운영 접근 구성
CloudWatch	로그와 운영 관측	애플리케이션·Lambda 로그와 EC2·RDS 주요 지표 및 알람 통합

AI & Tools

기술·도구	적용 영역	채택 이유
Asset Generation Pipeline · Gradio	몰입형 세션 배경 자산 제작	OpenAI 이미지 생성 또는 로컬 이미지 선택부터 입력 검수·사용자 승인·Runway 영상 생성·MP4 다운로드·선택적 S3 업로드까지 독립형 UI에서 연결
Spring AI	LLM·Embedding 연동	OpenAI와 로컬 Ollama 모델의 설정과 호출 구조를 Spring 애플리케이션에 통합
OpenAI	Task 정리·링크 요약·Embedding·이미지 생성	자연어 기반 구조화와 지식 노드 탐색에 필요한 채팅·Embedding·이미지 API를 제공
Google Stitch	UI 디자인	서비스의 주요 화면 시안을 제작하고 레이아웃과 사용자 흐름을 구체화
Playwright	JavaScript 페이지 렌더링	정적 HTML로 본문을 수집하지 못하는 문서를 Lambda에서 브라우저로 렌더링

swimming/
├── backend/                    # Spring Boot API와 도메인 로직
│   └── src/
│       ├── main/java/...       # auth, folder, task, plan, session, note, knowledge
│       ├── main/resources/     # 설정, 프롬프트, Flyway migration
│       └── test/               # 계층별 Backend 테스트
├── frontend/                   # React SPA
│   └── src/
│       ├── api/                # 공통 API 클라이언트
│       ├── features/           # 기능별 화면·상태·API 연동
│       ├── store/              # Zustand 전역 상태
│       └── styles/             # 디자인 토큰과 전역 스타일
├── infra/                      # Lambda, 배포 스크립트와 Terraform
├── docs/                       # PRD, Architecture, ERD와 기능 정의
├── .github/workflows/          # CI와 배포 워크플로
├── docker-compose.yml          # 로컬 PostgreSQL·선택적 renderer
└── compose.production.yaml     # 운영 Backend 컨테이너

✓ 검증

cd backend
./gradlew test
./gradlew build
./gradlew postgresCheck  # 로컬 PostgreSQL 필요

cd frontend
npm run lint
npm run build

기본 Backend 테스트는 H2를 사용하며 실제 네트워크가 필요한 LLM 평가·웹 수집·PostgreSQL 태그 테스트는 제외합니다. Frontend CI는 lint와 TypeScript/Vite production build를 실행합니다.

☁️ 시스템 아키텍처

배포

• Frontend: Vite build → 비공개 S3 → CloudFront
• Backend: Docker image → immutable ECR tag → SSM을 통한 단일 EC2 배포
• Database: private PostgreSQL 17 RDS와 Flyway migration
• Runtime secret: AWS Secrets Manager
• 관측: CloudWatch log와 EC2/RDS alarm

main 브랜치 변경 시 GitHub Actions가 변경 경로에 따라 Frontend, Backend와 page renderer를 각각 배포합니다. Terraform 변경 Pull Request에서는 format, validate와 plan을 실행하고 실제 apply는 로컬 승인 절차로 남겨 둡니다.

현재 운영 구성은 단일 EC2·단일 AZ이며 ALB, WAF와 무중단 배포는 포함하지 않습니다. 초기 구축, TLS, state와 장애 대응은 AWS 인프라 가이드를 따릅니다.