AI 기반 관계 기억 서비스 — 프로젝트 문서

프로젝트계획서

1. 프로젝트 개요

배경

• 현대인은 만나는 사람과 기억해야 할 대화가 계속 늘어나지만, 뇌의 용량은 그대로다. 지난 대화는 흐릿해지고, 같은 질문을 반복하고, 관계의 맥락이 끊어진다.
• 기존 도구(메모 앱, 회의록, 채팅 기록)는 정보를 문서 단위로 저장한다. 정보가 사람을 따라 축적되지 않아, 필요할 때 찾아내는 일은 여전히 사람의 몫이다.
• 이 문제는 기억력의 문제가 아니라 구조의 문제다. 해결 방향은 정보를 사람 기준으로 구조화하는 것이다.

핵심 컨셉

• 기록의 기본 단위가 다르다: 기존 서비스는 회의/문서 단위, 우리는 사람 단위
• 주 사용 장면은 1:1 대화 (영업 미팅, 커피챗, 상담, 인터뷰)
• 입력은 녹음 단일 채널: 1:1 대화 녹음 + 개인 녹음(본인 단독 음성 메모) 2가지 (기록 부담 최소화)

2. 경쟁 지형과 차별점

• 해외 AI 네이티브 CRM은 이메일 등 디지털 채널의 자동 수집에 집중한다. 한국의 관계 형성은 대면·전화·커피챗 비중이 높아 디지털 흔적에 남지 않는 영역이 크다. 음성 우선 + 대면 1:1 + 사람 단위 축적이 본 서비스의 포지션이다.
• 주의할 통념: 기록 도구가 죽는 첫 번째 이유는 기능 부족이 아니라 입력 부담이다. 녹음 시작을 얼마나 무의식적으로 만드느냐가 리텐션의 핵심 변수다.

3. 목표와 성공 기준

1. MVP 출시 — 1:1 대화 녹음 → AI 요약 → 사람별 타임라인 축적이 동작하는 모바일 앱
2. 클로즈드 베타 운영 — 30~50명 규모, 유지율과 녹음 빈도 측정
3. 모두의 창업 프로그램 산출물 제출 — P-S-S-D 사업계획서, 활동보고서

4. 범위

MVP 범위 (In Scope)

• 인물 등록/관리 (수동)
• 1:1 대화 녹음 (상대방 동의 절차 포함)
• 개인 녹음 (상대방 없이 본인 단독 음성 메모 — 동의 절차 불필요)
• STT (음성 → 텍스트 변환)
• AI 요약 및 키워드 추출
• 사람별 타임라인 축적 및 조회
• 회의(다자 대화)는 별도 항목으로 기록하여 1:1 구조를 해치지 않음

확장 범위 (Out of Scope — MVP 이후 백로그)

• 캘린더·메신저·연락처 연동 (자동 기록)
• 스마트워치 앱 (녹음 시작 편의성)
• 스마트글래스 (실시간 정보 표시), 안면 스캔
• 장소 저장 기능 (미팅 장소, 함께 간 곳)
• 회의록 전용 기능 고도화, 화자 구분
• 다국어 지원 (영어/일본어/중국어)
• 유료 플랜 (인물 수 제한, STT 분량 제한 기반)

5. 리스크 관리

산출물

• 본 문서 6종 (프로젝트계획서, 요구사항정의서, 아키텍처정의서, 화면기능정의서, 백엔드작업일정, 기술스택)
• P-S-S-D 사업계획서 (문제 인식 → 실현가능성 → 성장전략 → 향후 발전방안)
• 활동보고서 (프로그램 양식)
• MVP 앱 및 소스코드 저장소 (저장소 분리 예정, 팀 결정 필요)

요구사항정의서

1. 사용자 정의

핵심 타겟 (Primary)

사람과의 대화 및 관계 관리가 업무 성과와 직접 연결되는 직군.

• 회의가 많은 직군 (PM, 기획자)
• 영업 및 고객 미팅 직군
• 인터뷰어 / 상담사 / HR 담당자

확장 타겟 (Secondary)

• 다양한 사람을 자주 만나는 사용자
• 이전 대화를 기억하고 자연스럽게 이어가고 싶은 모든 개인

유저 스토리

2. 기능 요구사항 (Functional Requirements)

우선순위: 필수 MVP 출시 조건 · 권장 MVP 내 포함 목표 · 선택 여유 시

인물 관리

대화 기록 (입력)

변환 및 AI 처리

타임라인 및 조회

계정 및 데이터 관리

3. 비기능 요구사항 (Non-Functional Requirements)

4. 제약사항 및 용어

제약사항

• 타인이 포함된 대화의 동의 없는 녹음 기능은 제공하지 않는다 (제품 원칙이자 리스크 관리). 개인 녹음(본인 단독, FR-207)은 상대방이 없으므로 예외
• MVP는 개인 사용 목적으로 한정한다. 제3자 공유·조직 단위 기능은 법적 재검토 전까지 구현하지 않는다
• 지원 기기: 스마트폰 (태블릿/워치/글래스는 확장 범위)

용어 정의

아키텍처정의서

1. 설계 원칙

1. 사람 단위 데이터 모델. 모든 기록은 Person에 귀속된다. 회의/문서 단위 구조를 만들지 않는다 (제품 차별점을 스키마 수준에서 보장).
2. 입력 유실 금지. 녹음 원본은 AI 처리 파이프라인과 분리 저장한다. AI 처리는 실패·재시도 가능한 비동기 작업으로 취급한다.
3. 동의 우선. 동의 확인은 클라이언트 UX가 아니라 도메인 규칙이다. 1:1 대화 유형에서 동의 플래그 없는 녹음 세션은 서버가 거부한다 (개인 녹음은 본인 단독이므로 예외).
4. 확장 기능은 스키마만 열어둔다. 캘린더 연동, 장소, 워치 등은 MVP에 구현하지 않되, 데이터 모델이 막지 않도록만 설계한다.
5. 외부 AI 서비스 교체 가능. 외부 AI API(STT·LLM·임베딩·리랭커)는 전부 어댑터 뒤에 두어 공급자 교체가 코드 한 곳 수정으로 끝나게 한다 (지원 API 종료 대비 + 비용 협상력 확보).

2. 시스템 구성도

3. 핵심 파이프라인

• 각 단계 실패 시 상태를 FAILED_*로 기록하고 원본을 보존, 재시도 가능 (FR-306, NFR-08)
• 개인 녹음은 동의 확인 단계만 건너뛰며, 2단계 이후 파이프라인은 1:1 대화와 동일
• 장시간 녹음 대비: STT API는 실행 시간 제한(504)이 있으므로, 일정 길이 이상의 오디오는 분할(청킹) 후 전사하고 결과를 이어 붙인다 (BE-14에서 기준 확정)

시맨틱 검색 흐름 (FR-405)

임베딩 + 리랭커로 "그때 여행 얘기했던 사람" 같은 자연어 검색을 지원한다.

• 벡터 저장은 PostgreSQL pgvector 확장 사용 — 별도 벡터 DB 불필요 (DB 단독 운용 원칙 유지)
• 임베딩 생성은 확정 시점의 비동기 잡으로 처리 (실패해도 기록 자체는 유효)
• 임베딩·리랭커 어댑터도 STT와 동일하게 교체 가능 구조로 (지원 종료 후 대체 확정 전까지)

4. 데이터 모델 차후 재정리

기획 문서의 데이터 구조(Person → 기본 정보/역할/관심사/Timeline/관계 맥락)를 정규화한 것.

관계: USER 1—N PERSON · PERSON 1—N CONVERSATION · CONVERSATION 1—1 RECORDING · CONVERSATION 1—1 SUMMARY · PERSON 1—N PERSON_KEYWORD

설계 메모

• 타임라인은 별도 테이블이 아니라 CONVERSATION.occurred_at 기준 조회 뷰다 (상태 CONFIRMED만 노출)
• type = ONE_ON_ONE이면서 consent_confirmed = false인 생성 요청은 서버가 거부한다 (설계 원칙 3). PERSONAL(개인 녹음)은 동의 플래그 불필요
• SUMMARY.summary_original을 보존해 사용자 수정본과 AI 원본을 구분한다 (품질 개선 데이터로 활용)
• 확장 대비 여지: PERSON에 연락처/장소 컬럼 추가 가능, CONVERSATION.type에 값 추가 가능. MVP에서는 구현하지 않는다

5. 기술 스택

6. 보안 및 개인정보 설계

7. 결정 대기 목록 (ADR 백로그)

화면기능정의서

1. 화면 목록

2. 핵심 플로우

1:1 대화 녹음 플로우

개인 녹음 플로우

상대방이 없는 본인 단독 음성 메모. 동의 확인(SCR-05)을 거치지 않는 것이 1:1 플로우와의 유일한 차이다.

다음 만남 전 조회 플로우

3. 화면별 상세 정의

4. 공통 UI 규칙

• 처리 중 상태는 항상 보인다. AI 처리(STT/요약)는 수 초~수 분 걸릴 수 있다. 사용자가 "내 녹음이 사라졌나?"라고 느끼는 순간 신뢰가 깨진다. 처리 중/실패/재시도 상태를 타임라인에서 숨기지 않는다.
• 처리 완료 알림: 앱이 백그라운드일 때 AI 처리 완료를 푸시 알림으로 알릴지 여부 팀 결정 필요. 알림 없이는 사용자가 결과 확인(SCR-07)에 진입할 계기가 없다는 점을 고려할 것.
• 파괴적 동작은 2단계 확인. 인물 삭제, 기록 삭제, 탈퇴.
• 오프라인 허용 범위: 녹음은 오프라인 가능 (로컬 보관 후 업로드), 조회는 온라인 필수 (MVP 기준, 캐시 전략은 팀 결정 필요).
• 디자인 시스템 (색상, 타이포, 컴포넌트): 팀 결정 필요 — 별도 디자인 문서로 분리 권장.

5. 미결 검토 항목

백엔드 작업 정리 (스텝 순서 기준)

1. 운영 방식과 전체 지도

날짜·기간이 아니라 작업 순서와 완료 기준으로 관리한다.

• STEP은 순서대로 진행한다. 다음 STEP은 이전 STEP의 의존 작업이 끝나야 시작한다.
• 같은 STEP 안의 작업들은 서로 독립적이라 순서 자유 (나눠 맡아도 되고 혼자 차례로 해도 됨).
• 작업마다 완료 기준(DoD)이 있다. "대충 됨"은 완료가 아니다.
• 규모는 상대 크기: S 반나절감 M 며칠감 L 제일 큼 — 시간 약속이 아니라 우선순위 감각용

⚠️ 시간 제약이 있는 유일한 작업

STT를 어댑터 인터페이스 뒤에 두는 이유가 이것이다 (BE-14). 어댑터만 지키면 전환은 구현체 교체로 끝난다.

2. STEP별 작업 목록

STEP 0 — 선행 결정·셋업

코드보다 먼저 끝내야 하는 것들.

STEP 1 — 공통 기반

STEP 2 — 도메인·입력

STEP 3 — AI 파이프라인

STEP 4 — 확정 플로우 완성

파이프라인과 도메인 API가 여기서 만난다.

STEP 5 — 마감 품질·배포

3. 운영 규칙

1. 스코프 동결. 이 목록에 없는 기능(워치, 캘린더 연동, 회의 유형 등)은 STEP 5가 끝나기 전에 추가하지 않는다. 아이디어는 백로그에 적어두고 지나간다.
2. STEP 3 완료가 첫 번째 축배. 녹음이 요약으로 변하는 순간이 이 서비스가 처음으로 "존재"하는 순간이다. 여기까지 최단 경로로 간다.
3. BE-24(AI API 전환)만 달력을 본다. 나머지는 순서대로, 이것만 8월말 전에.
4. 작업 시작/완료 시 문서(05-백엔드작업일정.md)의 해당 행에 담당자와 날짜를 기록한다.

기술스택 정리

1. 한눈에 보기

1.1 선정 이유

2. 백엔드 (Spring Boot / Java)

언어·프레임워크 버전

주요 의존성

테스트

3. 모바일 앱 (Flutter)

핵심 패키지 후보

앱 개발 착수 전에 확정한다. 녹음 관련 두 개가 이 앱의 생명선이므로 가장 먼저 기술 검증(PoC)할 것.

4. AI API

구성

AI API 오마카세 스펙 요약 (지원 API, aiapi.kogrobo.com)

원문: 서비스 Docs 페이지 (2026-07-08 캡처 기준). 인증은 전 엔드포인트 공통 Authorization: Bearer <API_KEY> — 키는 서버에서만 사용, 앱(클라이언트)에 절대 포함 금지.

에러 코드 공통: 400 요청 필드 오류 → 필드명/Content-Type 확인 · 401/403 API 키 문제 · 429 일일 한도/usage limit · 500/502 업스트림 실패 → 재시도 로직 · 504 시간 제한 → 입력을 줄이거나 분할 처리

확인 필요 (BE-01에서)

• ⚠️ 문서상 베이스 URL이 http://(평문) — 대화 음성·전사문을 암호화 없이 전송하면 NFR-01(전송 TLS) 위반. HTTPS 엔드포인트 제공 여부를 지원사에 확인하고, 없으면 리스크로 기록 후 팀 판단
• 입력 데이터의 학습 활용 여부 약관 확인 (STT·임베딩·리랭커 전부)
• STT 실행 시간 제한의 실측값 — 몇 분짜리 녹음까지 한 번에 처리되는지 (청킹 기준 결정)
• STT 파라미터가 beam_size/vad_filter인 것으로 보아 업스트림이 Whisper 계열로 추정 — 9월 Whisper API 전환 시 파라미터 호환 이점 예상

5. 인프라·개발 환경

6. 버전 고정 기록과 남은 결정

프레임워크·주요 라이브러리 버전은 BE-04(스캐폴드) 완료 시점에 아래 표에 기록하고, 이후 변경 시 갱신한다.

남은 결정

• Gradle vs Maven / Lombok 사용 여부 — BE-04 전
• 로컬 S3 대체 (MinIO vs LocalStack vs 실 S3 개발 버킷) — BE-10 전
• 지원 API의 HTTPS 제공 여부 확인 (4절 확인 필요) — BE-01
• 지원 종료(8월말) 후 임베딩·리랭커 대체 공급자 — BE-24와 함께
• Flutter 상태관리 (Riverpod vs Bloc) — 앱 착수 전
• 녹음·백그라운드 패키지 PoC — 앱 개발에서 가장 먼저 (여기서 안 되면 화면 설계가 흔들림)
• CI 도입 시점 — BE-04에서 같이 할지