짧은 일정 속 맥락을 이해하고, 실제로 필요한 할 일을 제안하는 관계 기반 일정 관리 서비스
TRYNA는 사용자가 입력한 짧은 일정 속 맥락을 이해하고, 일정 전후에 실제로 필요한 할 일을 제안하는 일정 관리 서비스입니다.
같은 "회의"라는 일정이라도 전공 팀플 회의와 동아리 네트워킹 회의는 사용자가 준비해야 하는 일이 다릅니다.
TRYNA는 이러한 차이를 단순 키워드 매칭으로 처리하지 않습니다.
일정과 행동 사이의 맥락 관계를 구조화하고, 관계 기반으로 후보를 탐색한
뒤 사용자의 기존 정보와 DB 정보를 바탕으로 실제로 필요한 할 일만
선별합니다.
사용자는 추천된 할 일을 그대로 사용할 수도 있고, 필요 없는 항목을 삭제하거나 새로운 항목을 직접 추가할 수도 있습니다.
| BE | BE | BE | BE | BE |
|---|---|---|---|---|
 |
 |
 |
 |
 |
| 김태현 @taehyeon1998 |
김태림 @taerimiiii |
윤예림 @yeremeee |
서동훈 @hoondongseo |
유다현 @Ubokchi |
| Type | Tool |
|---|---|
| Language |  |
| Framework |  |
| ORM |  |
| Security |  |
| Database |  |
| API Documentation |  |
| In-Memory Store |  |
| Build Tool |  |
| Version Control |   |
| Collaboration |  |
| 담당 영역 | 담당자 | 담당 기능 |
|---|---|---|
| 인증/사용자 | 사이먼/서동훈 | 회원·비회원 인증, 사용자 계정 관리, 외부캘린더 연동 |
| 일정/캘린더 | 곤/김태현 | 일정 CRUD, 캘린더 조회, 자연어 일정 입력 |
| 분석/추천 | 레미/윤예림 | 일정 맥락 분석, 관계 기반 추천, LLM 후보 정제 |
| 준비/실행 항목 | 유복치/유다현 | 추천 항목 관리, 태스크 완료 처리, 라벨, 일정·캘린더 연동 |
| 알림/외부연동/공통 | 라포/김태림 | 일정 및 준비/실행항목 알림, 인프라 |
사용자 일정 입력
│
▼
Rule Based Parser + Kiwi
│
│ 일정 정보 구조화
▼
Neo4j
│
│ 관계 기반 할 일 후보 탐색
▼
Upstage LLM
│
│ 중복 통합 및 불필요한 후보 제거
▼
사용자 맞춤 할 일 제안
사용자가 짧은 일정 제목을 입력합니다.
트라이나 전체 미팅
Rule Based Parser와 Kiwi를 사용하여 짧은 일정 속 정보를 구조화합니다.
트라이나 → 프로젝트 또는 그룹 맥락
미팅 → 일정 유형
전체 → 미팅의 범위
구조화된 데이터는 다음 단계의 추천 과정에서 활용됩니다.
{
"title": "트라이나 전체 미팅",
"eventType": "meeting",
"contextTags": [
"group_meeting",
"people_meeting"
],
"project": "tryna",
"date": null,
"time": null,
"location": null
}구조화된 일정 정보는 Neo4j 그래프 데이터베이스로 전달됩니다.
TRYNA는 일정과 행동 사이의 관계를 그래프로 관리하고, 현재 일정과 연결된 할 일 후보를 탐색합니다.
예를 들어 미팅 일정에서는 다음과 같은 후보가 탐색될 수 있습니다.
안건 정리
공유 자료 준비
회의록 준비
장소 확인
이동 시간 확인
교통편 확인
식당 후보 찾기
카페 후보 찾기
참석자 확인
그래프에서 탐색한 모든 후보를 사용자에게 그대로 보여주지는 않습니다.
Upstage LLM이 다음 정보를 바탕으로 후보를 정제합니다.
- 사용자가 입력한 일정 정보
- 사용자가 기존에 입력한 정보
- DB에 저장된 정보
- Neo4j에서 탐색된 할 일 후보
이 과정에서 의미가 겹치는 항목을 묶고, 현재 일정에 불필요한 항목을 제거합니다.
최종적으로 사용자가 실제로 활용할 가능성이 높은 몇 개의 할 일만 제안합니다.
☑ 미팅 안건 정리하기
☐ 장소 및 이동시간 확인
☐ 주변 식당 후보 선정
추천 결과는 자동으로 강제 저장되지 않습니다.
사용자는 추천된 할 일을 자유롭게 수정할 수 있습니다.
- 추천 항목 사용
- 필요 없는 항목 삭제
- 새로운 할 일 직접 추가
TRYNA는 추천을 정답으로 제시하는 것이 아니라, 사용자가 부담 없이 받아들이고 수정할 수 있는 가벼운 제안으로 제공합니다.
| Step | Technology | Responsibility |
|---|---|---|
| 1 | Rule Based Parser | 일정에서 규칙 기반 정보 추출 |
| 2 | Kiwi | 한국어 형태소 분석 및 일정 맥락 구조화 |
| 3 | Neo4j | 일정과 행동의 관계를 기반으로 후보 탐색 |
| 4 | Upstage LLM | 중복 후보 통합 및 불필요한 후보 제거 |
| 5 | TRYNA | 최종 할 일을 수정 가능한 형태로 제공 |
- 캘린더 메인 조회
- 일정 상세 조회
- 일정 생성
- 일정 수정
- 일정 삭제
- 사용자별 일정 관리
- 짧은 자연어 일정 입력
- 일정 유형 및 맥락 분석
- 프로젝트 및 그룹 정보 추출
- 날짜, 시간, 장소 정보 구조화
- 일정과 행동 사이의 관계 모델링
- Neo4j 기반 관련 할 일 후보 탐색
- 일정 맥락에 따른 후보 확장
- 단순 키워드 매칭을 넘어선 관계 기반 추천
- 사용자의 기존 정보 반영
- DB 정보 기반 후보 정제
- 의미가 겹치는 추천 통합
- 불필요한 추천 제거
- 실제 활용 가능성이 높은 할 일 선별
- 추천된 할 일 사용
- 불필요한 추천 삭제
- 할 일 직접 추가
- 추천 결과 수정
- 사용자 변경 정보 기록
- 회원 사용자 인증 및 식별
- 비회원 사용자 식별
- 인증 정보를 기반으로 한 일정 조회 및 저장
- 회원·비회원 공통 일정 API 사용
Client
│
▼
Controller
│
▼
Service
│
├── 일정 관리
├── 사용자 관리
├── 추천 결과 관리
└── 피드백 관리
│
├───────────────┐
▼ ▼
Relational DB Recommendation Pipeline
│
▼
Rule Based Parser
+ Kiwi
│
▼
Neo4j
│
▼
Upstage LLM
│
▼
할 일 제안
프로젝트의 기본 패키지 구조는 global과 domain으로 구분합니다.
src/
└── main/
├── java/
│ └── ...
│ ├── global/
│ │ ├── config/
│ │ ├── exception/
│ │ ├── response/
│ │ ├── security/
│ │ └── util/
│ │
│ └── domain/
│ └── {domain}/
│ ├── controller/
│ │ └── docs/
│ ├── service/
│ ├── repository/
│ ├── entity/
│ ├── enums/
│ └── dto/
│
└── resources/
├── application.yaml
├── application-local.yaml
├── application-prod.yaml
└── application-test.yaml
각 계층은 다음 역할을 담당합니다.
Layer Responsibility
Controller 요청 및 응답 처리 ControllerDocs Swagger API 문서 작성 Service 비즈니스 로직 및 트랜잭션 처리 Repository 데이터 접근 Entity 도메인 데이터 표현 DTO API 요청 및 응답 데이터 전달
TRYNA는 인증 정보를 기반으로 사용자를 식별합니다.
Authorization: Bearer {token}회원과 비회원 모두 인증 정보를 통해 사용자를 식별하며, 일정 API에서는 인증된 사용자 정보를 기준으로 데이터를 조회하고 저장합니다.
API 경로는 다음 형식을 사용합니다.
/api/v1/{resources}
리소스명은 복수형 명사를 사용하며, 동작은 URL이 아닌 HTTP Method로 표현합니다.
Method Purpose
GET 조회 POST 생성 PATCH 일부 수정 DELETE 삭제
{
"success": true,
"code": "COMMON_200",
"message": "요청에 성공했습니다.",
"data": {}
}{
"success": false,
"code": "COMMON_400",
"message": "잘못된 요청입니다.",
"data": null
}응답 데이터가 없는 경우 data는 null로 반환합니다.
API 문서는 Swagger와 OpenAPI를 기반으로 관리합니다.
실제 요청을 처리하는 Controller와 API 문서를 담당하는 ControllerDocs를 분리합니다.
domain/
└── {domain}/
└── controller/
├── XxxController
└── docs/
└── XxxControllerDocs
API가 변경되면 Controller와 ControllerDocs를 함께 수정합니다.
환경별 설정 파일은 다음과 같이 관리합니다.
application.yaml # 공통 설정
application-local.yaml # 로컬 환경
application-prod.yaml # 운영 환경
application-test.yaml # 테스트 환경
민감 정보는 환경 변수 또는 별도의 로컬 설정 파일을 통해 관리하며 Git에 커밋하지 않습니다.
⚠️ .env, 인증 정보, API Key, 데이터베이스 비밀번호 등의 민감 정보는 저장소에 커밋하지 않습니다.
type/nickname/issueNumber-task
feat/nickname/1-create-event
bug/nickname/2-calendar-response
docs/nickname/3-api-docs
type: subject
feat: 일정 생성 API 추가
bug: 캘린더 조회 오류 수정
docs: README 작성
refactor: 일정 서비스 구조 개선
feat/* ─┐
bug/* │
docs/* │
style/* ├──> develop ──> main
refactor/* │
chore/* ─┘
hotfix/* ──> main
└─> develop
main 브랜치에는 직접 작업하지 않으며, PR은 AI 코드 리뷰 확인
후 병합합니다.