# 프로젝트 회의록

## 회의 정보
- **회의명**: 프로젝트 회의
- **일시**: 2025.11.24
- **장소**: 강의실 372
- **회의 유형**: 기획회의

## 참석자
- **진행자**: 모인지
- **참석자**: 
  - 강소현
  - 국영규
  - 김세희
  - 모인지
  - 윤종윤
  - 이유진
  - 임성현
  - 이상호
- **불참자**:
  - 최대현

## 회의 안건
1. 스크럼 및 인프라(Kubernetes) 구성 방향 재점검
2. MSA 적용 시 기능 분할 기준 논의
3. Git 브랜치 전략 및 코드 리뷰 플로우, 작업 버전 관리 방식
4. API·AI 사용 정책 및 용량 테스트 필요성 검토
5. RagFlow 테스트 요청

## 회의 내용

### 안건 1: 스크럼 & 인프라(Kubernetes) 구성
- **논의 내용**:
  - WBS는 최대한 세분화만 잘 되면 이후 인력 배치로 마무리할 수 있다는 의견
  - 스크럼 일지는 스프레드시트로 관리 중이며, 이전에 “스크럼 구조를 애자일 프로세스에 맞게 재정리할 필요가 있다”는 코멘트가 있었음
  - 인프라 측면에서는 Kubernetes를 실제로 설정·테스트해 보고, 팀 역량과 난이도를 고려해 도입 여부를 결정하기로 함
  - 현 단계에서 Kubernetes는 ‘필수 도입’이 아니라 ‘도입 검토 대상’ 상태

### 안건 2: MSA 분할 기준
- **논의 내용**: 
  - MSA 도입의 핵심 이슈는 “어떤 기준으로 기능을 분리할 것인가”임
  - 현재 기능이 크게 3개 축으로 나뉘어 있으나, 이 중 핵심 기능 5개를 기준으로 서비스 단위를 나누는 방안이 논의됨
  - MSA를 적용한다는 것은, 이 5개 핵심 기능을 각각 독립된 서비스로 분리할지 여부를 결정한다는 의미로 정리됨
  - 분할 전, 각 기능의 경계·의존 관계를 다이어그램이나 표로 정리할 필요가 있음
  
### 안건 3: 브랜치 전략 및 코드 리뷰 플로우, 작업 버전 관리 방식
- **논의 내용**:
  - 현재 코드 시작점이 기존 main에서 직접 작업된 부분, 별도의 개인 브랜치에서 시작된 부분 이렇게 두 갈래로 나뉘어 있음
  - 소연이 작업한 브랜치를 포함하여, 앞으로는 개인 브랜치 → develop 브랜치 → (필요 시 staging) → main 순으로 반영하는 흐름을 사용하기로 논의함
  - 장기적으로는 DB 구조와 쿼리 성능 분석에 대한 기본 지식이 필요
  - 의도된 전체 플로우:
    1)	각자 개인 브랜치에서 기능 개발
    2)	1차로 develop 브랜치에 merge/push
    3)	필요 시 staging에서 main에 반영할 후보 코드만 올려 테스트
    4)	문제가 없는 코드만 main 브랜치에 merge/push
  - 같은 기능에 대해 이어서 작업할 때 branch명_v1, v2 작업 단위 사용

### 안건 4: API·AI 사용 정책 및 용량 테스트
- **논의 내용**:
  - 현재는 GPT API를 사용하고 있으나, 향후에는 외부 API(특히 외부 LLM)에 대한 의존도를 줄이거나, 가능하다면 사용하지 않는 방향을 검토 중
  - 보안·비용 관점에서 외부 LLM 호출을 최소화하고, 가능한 경우 내부 인프라/모델을 활용하는 구조가 바람직하다는 의견
  - 다만, 내부 인프라만 사용했을 때 성능·용량이 충분한지는 별도 테스트가 필요하다는 점이 언급됨

### 안건 5: RagFlow 테스트 요청
- **논의 내용**:
  - RagFlow를 실제로 사용해보기 위해 참고할 수 있는 코드 샘플(레그 코드 샘플)은 없으며, RagFlow는 문서 전처리·청킹·임베딩 등을 웹 UI에서 설정하고, 파일(PDF/Word/텍스트 등)을 업로드해서 처리하는 도구
  - 즉, import ragflow처럼 코드로 직접 불러다 쓰는 라이브러리 형태가 아니라, UI에서 파서(parser), 청킹(chunking) 전략, 임베딩 방식 설정 후 파일 업로드 등을 통해 동작
  - RagFlow는 UI 기반 RAG 전처리·청킹 툴이므로, 우리 프로젝트에서는 RagFlow 자체를 코드로 붙이기보다는, RagFlow를 어떻게 설정하고 어떤 파일을 올려 어떤 결과를 얻는지에 대한 사용 시나리오/화면 캡처를 문서화하는 것이 현실적
  - 차후에 코드 기반으로 RAG 파이프라인을 만들 필요가 생기면, 그때는 RagFlow가 아닌 다른 라이브러리(LangChain, LlamaIndex 등)의 예제 코드를 참고

- **결정 사항**: 
  - MSA 분할: 핵심 기능 5개를 기준으로, 어떤 기능을 어디까지 독립 서비스로 분리할지 MSA 서비스 단위 후보를 정의 (BE/기획) (2025-11-22~2025-11-26)
  - 인프라(K8s): Kubernetes 도입 여부를 판단하기 위해, 간단한 설정·배포 테스트(PoC)를 진행할지 검토하고 필요 시 최소 PoC를 수행 (Infra) (2025-11-23~2025-11-27)
  - 브랜치 전략: 개인 브랜치 → develop → (필요 시 staging) → main으로 merge/push하는 Git 브랜치 전략과 머지 규칙 정의 (BE) (2025-11-22~2025-11-24)
  - 작업 버전 관리: branch명_v1, v2와 같이 기능별로 이어지는 작업을 버전명으로 구분하는 규칙을 정하고, 작업 단위 관리 원칙 정의 (BE/기획) (2025-11-23~2025-11-25)
  - API/AI 정책: 외부 GPT/API 사용을 최소화한다는 방향을 전제로, 내부 인프라(모델/서버)의 용량·성능 테스트 계획을 수립 (AI/Infra) (2025-11-24~2025-11-28)
  - 문서 전처리: RagFlow 테스트 요청 (AI/BE) (2025-11-24~2025-11-29)

## 다음 회의
- **일시**: 2025-11-25

## 기타 사항
- 모든 회의록은 GitHub의 docs/meeting-notes/ 디렉토리에 저장
- 회의록은 회의 종료 후 24시간 내에 공유

---
**작성자**: 이유진  
**작성일**: 2025-11-24