3차 멘토링 회의 정리 – HAI(History AI)
1. 멘토링 개요
- 프로젝트명: HAI(History AI)
- 목적
- 작성한 User Story를 멘토님께 설명
- 각 Story에 대해 피드백 및 리뷰 진행
- 기술 스택·아키텍처·기능 범위에 대한 방향성 정리
2. User Story & 서비스 컨셉 피드백
- User Story 구성 및 방향은 전반적으로 긍정적인 평가를 받음.
- 다만, 아이디어가 많기 때문에
- 게임(테마) 요소는 일단 제외하고
- 핵심 기능(MVP) 위주로 먼저 개발 시작하는 것이 좋다는 조언.
- 게임적인 요소(캐릭터, 스토리, UI 연출 등)는
→ 추후 안정화 후에 확장 요소로 고민하기로 함.
3. 교과서 & 이미지 처리 방안 논의
3.1 교과서 질문 처리 방식
- 사용자가 교과서에 대해 질문할 때, 교과서 정보를 어떻게 저장하고 검색할지 논의.
- 교과서를 단순 텍스트가 아니라 이미지 + 페이지 구조까지 고려해야 함.
3.2 이미지/페이지 처리 전략 (옵션)
-
Vector DB + 이미지 메타데이터 방식
- 교과서를 섹션/단원/단락 단위로 분할하여 텍스트를 Vector DB화
- 이미지는 별도로 저장하고,
해당 이미지의 URL/경로를 메타데이터로 함께 저장 - 검색 결과에서:
- 관련 텍스트와 함께
→ 해당 페이지/이미지 URL을 사용해 이미지를 함께 노출 가능
- 관련 텍스트와 함께
-
페이지 단위 뷰어 방식
- 이미지를 따로 떼어 저장하지 않고,
- 검색 시 문제가 있는 페이지 전체를 바로 보여주는 형식
- 교과서 뷰어처럼 “현재 페이지”를 보여주고
질문과 연결된 부분을 표시하는 UX도 고려 가능.
결론: 두 가지 방식 모두 장단점이 있어,
서비스 UX/난이도/개발 리소스를 고려해 선택하기로 함.
4. 기능 및 화면 기획 관련 논의
4.1 관리자 & 강사 기능
- 관리자 페이지는 가능하면 초기부터 고려하는 것이 좋다는 의견.
- 강사용 기능:
- 강사가 사용하는 교과서를 변경/선택할 수 있도록 설계
- 추후 여러 교과서를 관리할 수 있는 구조를 염두에 둘 것.
4.2 퀴즈 & 캐릭터/게임 요소
- 캐릭터/일러스트/게임화 요소는
- 제작 난이도와 리소스가 크기 때문에
- 초기 버전에서는 최소화하는 방향.
- 단원 마무리용 퀴즈는:
- 텍스트 박스에 퀴즈/답안을 올리는 정도의 간단한 형태로 시작
- 이후 여유가 생기면 객관식, 드래그앤드롭 등 확장 가능.
4.3 로그인 기능
- 로그인 기능을 넣을지 여부는 아직 결정 X
- 계정 기반 저장/히스토리/진행도 관리가 필요하다면 필수
- 초기 PoC 단계에서는 비로그인/간단한 세션 기반으로 갈 수도 있음
- 추후 요구사항에 맞춰 결정하기로 함.
4.4 기술 검토 표시
- 기술 스택·도입 여부 검토가 끝난 것들은
→ FigJam에 “기술 검토 완료” 등으로 명시해서,- 팀원 모두가 현재 상태를 한눈에 볼 수 있도록 관리하기로 함.
5. 기술 스택 & 아키텍처 논의
5.1 백엔드 & AI 역할 분리
- 백엔드 메인 프레임워크:
- Spring Boot vs Python 중 Spring Boot를 메인 백엔드로 사용하는 방향 추천
- AI 기능:
- 모델 호출, 임베딩 생성, Vector DB 연동 등 AI 관련 로직은 Python에 집중
- 구조 예시:
- Spring Boot: 인증/권한, 비즈니스 로직, API Gateway 역할
- Python: AI 서버, 모델 인퍼런스, 임베딩 생성, 검색 API 제공
5.2 DB & 검색 스택
아직 최종 결정 전, 후보군 논의:
- 관계형 DB (메인 데이터 저장소)
- MariaDB
- PostgreSQL (Vector 확장 기능을 활용할지를 포함하여 고려)
- 검색/Vector DB/기타
- PostgreSQL + Vector 확장
- 또는 Elasticsearch를 도입해서 검색 기능 강화
- 현재는:
- 메인 트랜잭션 DB와
- 검색/유사도 기반 Q&A용 Vector DB or 검색 엔진
→ 역할 분리하는 방향으로 고민 중.
5.3 파일/이미지 저장소
- 교과서 원본, 이미지, 첨부 파일 등은
- S3 같은 오브젝트 스토리지에 저장하는 방향이 적합하다는 의견.
- DB에는 파일 경로/URL, 메타데이터만 저장.
5.4 인프라, 캐시, CI/CD
- CI/CD
- 다양한 옵션 중에서 GitHub Actions 사용을 추천
- 저장소 기반, Workflow 관리가 편하고 학습 자료도 많음.
- 캐시
- 세션/토큰/간단한 캐시 및 큐잉 용도로 Redis 도입을 검토.
- 아키텍처
- 가능하다면 MSA 구조에 도전해 보는 것을 권장.
- 다만, 개발 시작 전에:
- 어떤 서비스를 나눌지
- 서비스 간 통신 방식
- 각 서비스의 책임 범위
→ 명확히 정의하고 시작하는 것이 중요하다는 조언.
6. 부하 테스트 & 비용 이슈
- nGrinder를 활용해 부하 테스트를 진행할 예정이라면,
- 테스트 시 AI 호출(토큰 사용량)을 반드시 주의할 것.
- 부하 테스트에서 무분별하게 모델을 호출하면
- 비용이 심하게 증가할 수 있음.
- 해결 방향:
- 테스트 전용 Mock 서버 또는
- 특정 구간에서만 실제 AI 호출,
- 혹은 토큰 사용량을 제한한 시나리오를 설계하는 방안 고려.
7. 다음 액션 아이템 (TODO)
- 교과서 & 이미지 처리 방식(옵션 1 vs 옵션 2) 최종 결정
- 백엔드(Spring Boot)와 AI(Python) 역할 분리 아키텍처 초안 작성
- 메인 DB(MariaDB vs PostgreSQL) 및 검색/Vector DB 구성 확정
- 파일 저장소로 S3 사용 여부 확정 및 버킷 구조 설계
- MSA로 나눌 서비스 경계(예: auth, content, quiz, ai 등) 정의
- FigJam에 기술 검토 완료/보류 상태 표시 체계 정의
- 로그인 기능 도입 여부 및 요구 기능(진행도 저장, 히스토리 등) 정리
- nGrinder 부하 테스트 시 AI 토큰 사용 전략(Mock, 제한 등) 설계(나중에 검토)
- spring Boot를 쓴다면 어떤 라이브러리를 쓸지
- frontend에서 어떤 UI를 쓸지
- Docker로 Vector DB띄워서 하는 방법 찾기
8. 용어 정리
아래는 멘토링/설계에서 언급된 주요 인프라/메시징/IaC 용어 정리입니다.
8.1 Route 53
- 무엇?
AWS에서 제공하는 DNS 서비스 - 역할
history-ai.com같은 도메인 이름을 실제 서버/서비스와 연결- 지연 시간 기반, 지역 기반 등 다양한 트래픽 라우팅 정책 지원
- 언제 사용?
- 나만의 도메인으로 서비스 접속
api.history-ai.com,admin.history-ai.com같은 서브도메인 구성
8.2 CloudFront
- 무엇?
AWS의 CDN(Content Delivery Network) 서비스 - 역할
- S3/EC2/ALB에 있는 콘텐츠를 전 세계 엣지 서버에 캐싱해서 빠르게 전달
- 이미지, JS/CSS, 교과서 파일 뷰어 등을 사용자와 가까운 위치에서 제공
- 언제 사용?
- 정적 리소스를 전 세계에 빠르게 제공하고 싶을 때
- 트래픽 많을 때 응답 속도와 비용 최적화
8.3 S3 (Simple Storage Service)
- 무엇?
AWS의 오브젝트 스토리지 - 역할
- 이미지, PDF, 동영상, JSON 같은 파일 저장소
- 버킷(bucket) 단위 관리, 버전 관리, 정적 웹 호스팅 가능
- 언제 사용?
- 교과서 원본, 페이지 이미지, 첨부파일 저장
- Vector DB 메타데이터에서 이미지/파일 URL로 연결할 때
8.4 AWS Lambda
- 무엇?
서버를 직접 관리하지 않고 코드만 실행하는 서버리스 함수(Function as a Service) 서비스 - 역할
- S3 업로드, API 요청, 스케줄 등 이벤트 기반으로 짧은 로직 실행
- 인프라 신경 안 쓰고 함수 단위로 코드 배포
- 언제 사용?
- 교과서 업로드 시 자동으로 썸네일/메타데이터 생성
- 간단한 API, 배치/스케줄러성 작업 처리
8.5 Kafka
- 무엇?
대용량 실시간 데이터 처리를 위한 분산 메시지 스트리밍 플랫폼 - 역할
- 서비스 간 이벤트를 토픽(topic) 단위로 발행/구독
- 로그, 클릭 이벤트, 문제 풀이 기록을 모아서 분석 시스템으로 전달
- 언제 사용?
- HAI에서 학생 행동 로그를 쌓고 추천/통계/분석에 활용할 때
- MSA에서 비동기 이벤트 기반 통신 구조 설계할 때
8.6 VPC (Virtual Private Cloud)
- 무엇?
AWS 안에서 만드는 나만의 가상 네트워크(사설망) - 역할
- 공개/비공개 서브넷, 라우팅, 보안 그룹 등을 구성해
네트워크 구조와 보안 경계를 설계 - 외부 노출 리소스(ALB 등)와 내부 리소스(DB, 내부 API 서버) 분리
- 공개/비공개 서브넷, 라우팅, 보안 그룹 등을 구성해
- 언제 사용?
- 백엔드, DB, Redis 등을 안전한 사설망 안에서 운영할 때
- 실무 수준의 네트워크/보안 구조를 갖추고 싶을 때 필수
8.7 Terraform
- 무엇?
HashiCorp에서 만든 오픈소스 IaC(Infrastructure as Code) 도구 - 역할
.tf파일(HCL 언어)로 클라우드 인프라 구조를 코드로 선언
→terraform apply로 실제 인프라를 생성/변경- 멀티 클라우드 지원: AWS, Azure, GCP, Kubernetes 등 다양한 프로바이더
terraform plan으로 변경 내용을 미리 확인(일종의 diff)
- 언제 사용?
- AWS 외에도 여러 클라우드/서비스를 한 번에 관리하고 싶을 때
- 인프라 구성을 Git으로 버전 관리하고, CI/CD와 연동하고 싶을 때
- HAI 인프라를 코드로 관리하면서, 나중에 다른 클라우드도 고려할 수 있는 구조로 가고 싶을 때
8.8 AWS CloudFormation
- 무엇?
AWS가 제공하는 AWS 전용 IaC 서비스 - 역할
- YAML/JSON 템플릿으로 VPC, EC2, RDS, S3, IAM 등
AWS 리소스를 정의하고 스택(Stack) 단위로 배포/관리 - AWS 내부 서비스들과 깊게 연동 (CDK, SAM 등이 결국 CloudFormation 템플릿을 생성해서 사용)
- YAML/JSON 템플릿으로 VPC, EC2, RDS, S3, IAM 등
- 언제 사용?
- 인프라가 거의 AWS 안에서만 구성될 때
- “AWS 공식” 도구로 인프라를 정의/관리하고 싶을 때
- HAI가 AWS에만 올인하고, 멀티클라우드 계획이 크지 않다면
CloudFormation(+CDK)도 후보가 될 수 있음
Terraform vs CloudFormation 감각 정리
- Terraform:
→ “여러 클라우드를 포함하는 범용 IaC 툴”- CloudFormation:
→ “AWS에 특화된 공식 IaC 서비스”
화이팅