LG CNS AM INSPIRE 프로그램의 마지막 멘토링 시간에 단위 테스트 케이스 작성 및 관리 방법 및 발표에 대한 피드백을 받았습니다.

1. 단위 테스트 대상 선정 구조

멘토님께서는 체계적인 테스트 관리를 위해 3단계 계층 구조를 제안해주셨습니다.

Level 1 (대분류)
  └─ Level 2 (중분류)
      └─ 화면 단위 (최종 테스트 단위)

이 구조를 통해 다음과 같은 정보를 관리할 수 있습니다:

• 각 레벨별 기능 분류
• 화면별 한글명 및 영문명
• 테스트 대상 여부 (Y/N)
• 단위테스트 ID
• 담당자 지정

예시 구조:

• Level 1: Data Exploration (데이터 탐색)
  • Level 2: Data Sets (데이터셋)
    • 화면: Data Sets (데이터셋 탐색) - WEB-002 - 담당: 팀원1
    • 화면: Data Details (데이터 상세) - WEB-003 - 담당: 팀원2

2. 화면 단위 테스트 케이스 작성

각 화면별로 구체적인 테스트 케이스를 작성하는 방법도 안내받았습니다.

테스트 케이스 구성 요소:

1. No. - 테스트 케이스 번호
2. 내용 - 테스트 시나리오 설명
3. Input Data - 입력 데이터
4. Expected Data - 예상 결과
5. Result - 실제 테스트 결과 (1st, 2nd 등)

실제 예시 (로그인 화면):

💡 얻은 인사이트

체계적인 테스트 관리

• 대분류-중분류-화면 단위로 나누어 관리함으로써 전체 시스템의 테스트 커버리지를 한눈에 파악할 수 있습니다
• 각 화면별 담당자를 명확히 지정하여 책임 소재를 분명히 할 수 있습니다

Positive & Negative 테스트 케이스

• 정상 케이스(Positive)뿐만 아니라 비정상 케이스(Negative)도 반드시 포함해야 합니다
• 예외 상황 처리가 제대로 되는지 확인하는 것이 중요합니다

반복 테스트 결과 관리

• 1st, 2nd 등으로 여러 차례 테스트 결과를 기록할 수 있어 버그 수정 후 재테스트 이력을 관리할 수 있습니다

3. PPT 구성에 대한 피드백

멘토님께서는 발표 자료(PPT)에 대해서도 중요한 조언을 해주셨습니다.

"프로젝트에 너무 많은 내용이 들어가 있네요. 시연 영상에서 표현할 내용과 PPT에서 표현할 내용을 명확히 구분해야 합니다."

PPT vs 시연 영상 역할 구분

PPT에 담아야 할 내용:

• 프로젝트 개요 및 목표
• 핵심 기능 소개 (간단명료하게)
• 시스템 아키텍처
• 주요 기술 스택
• 프로젝트 성과 및 인사이트

시연 영상에서 보여줄 내용:

• 실제 기능 동작 모습
• 사용자 시나리오별 플로우
• 상세한 UI/UX 인터랙션
• 각 기능의 구체적인 작동 방식

왜 구분이 중요한가?

1. PPT 과부하 방지: 모든 내용을 PPT에 담으면 청중이 집중하기 어렵고, 발표 시간도 길어집니다
2. 명확한 메시지 전달: PPT는 핵심 메시지 위주로, 시연 영상은 실제 구현 확인용으로 역할을 분리
3. 발표 효율성: PPT는 빠르게 넘기며 설명하고, 시연 영상은 필요한 부분만 재생
4. 청중의 이해도 향상: 개념은 PPT로, 실제 동작은 영상으로 보여주면 더 효과적

앞으로의 계획

1. 테스트 대상 선정 문서 작성

   • Level 1, Level 2 구조에 따라 전체 기능 분류
   • 각 화면별 테스트 대상 여부 결정 및 담당자 배정

2. 화면별 테스트 케이스 작성

   • 각 담당자가 맡은 화면의 기능별 테스트 케이스 작성
   • Positive/Negative 케이스 모두 포함

3. 테스트 실행 및 결과 기록

   • 작성된 테스트 케이스에 따라 실제 테스트 진행
   • 결과를 문서에 기록하고 이슈 발견 시 트래킹

마무리

마지막 멘토링에서 실무에서 바로 적용 가능한 구체적인 테스트 관리 방법을 배울 수 있었습니다. 단순히 테스트를 하는 것을 넘어, 체계적으로 관리하고 추적하는 방법의 중요성을 깨달았습니다.

마지막으로 멘토님께 감사드리며, 이번에 배운 내용을 프로젝트에 잘 적용해보겠습니다!

1. 멘토링 목표

이번 멘토링의 핵심 목표는 HAI(HistoryAI) 프로젝트에서 지금까지 구현한 기능들을 하나하나 단위 테스트(Unit Test)로 검증하는 단계로 전환하는 것이었다.

특히, 단위 테스트는 단순한 연습이 아니라,

• HistoryAI에서 이미 만들어 둔 모듈들(TTS, 음성 처리, AI 응답 흐름 등)을
• 실제 서비스 관점에서 안전하게 조합하기 위한 기반 작업이라는 점을 강조했다.

또한, TTS_RVC 음성변환은 단순한 음성 실험용이 아니라,

🎯 HistoryAI에서 ‘인물 AI와 대화할 때 실제로 사용될 핵심 기능’

이라는 맥락에서 다시 정리했다.

2. 이제는 단위 테스트가 필요한 시점

2.1 HistoryAI(HAI) 관점에서의 필요성

현재 HistoryAI(HAI)는 단순한 데모 수준을 넘어, 여러 기능이 유기적으로 결합된 서비스 형태로 확장되고 있다.

지금까지 구현된 주요 기능 흐름은 다음과 같다.

• 사용자 입력
• 인물 AI의 응답 생성
• 텍스트 결과 출력
• 음성 출력 및 인물화 (TTS + RVC)
• 지도 기반 정보 제공
• 토론 기능
• 주요 사건 및 전쟁 정보 제공

문제는 기능이 많아질수록 전체 시스템을 한 번에 실행해 검증하는 방식이 점점 비효율적이 된다는 점이다.

[기존 방식]
HistoryAI 전체 실행
 → 에러 발생
 → 어떤 기능에서 문제가 발생했는지 추적이 어려움

[개선 방식]
HAI 내부 기능을 모듈 단위로 분리
 → 각 기능을 단위 테스트로 검증
 → 검증된 기능들을 안정적으로 조합

따라서 이번 멘토링에서는 단순히 "기능이 동작하는지"를 확인하는 단계를 넘어,

✔️ "HistoryAI에서 지금까지 만든 기능들을 하나씩 신뢰 가능한 상태로 만들자"

라는 관점에서 단위 테스트의 필요성을 정리했다.

3. 단위 테스트 기준 정리

이번 멘토링에서는 HistoryAI에 맞는 현실적인 단위 테스트 기준을 다음과 같이 정리했다.

3.1 테스트 단위 예시

HistoryAI는 여러 기능 모듈이 결합된 서비스이기 때문에, 단위 테스트 역시 서비스 기능 기준으로 나누어 설계한다.

• 인물 AI 응답 생성

  • 사용자 입력에 대해 응답이 정상적으로 생성되는가?
  • 응답 결과가 빈 문자열이 아닌가?
  • 선택한 인물 컨텍스트가 응답에 반영되는가?

• 지도 기능

  • 사건/전쟁에 대해 위치 정보(위도·경도)가 정상적으로 반환되는가?
  • 지도에 표시할 데이터 구조(JSON 등)가 올바른 형식인가?
  • 존재하지 않는 장소 입력 시 예외 처리가 되는가?

• 토론 기능

  • 두 개 이상의 인물 AI 응답이 순서대로 생성되는가?
  • 각 인물의 관점이 서로 다르게 유지되는가?
  • 토론 턴 수가 제한 조건을 초과하지 않는가?

• 주요 사건 / 전쟁 정보 기능

  • 특정 인물 또는 시대 입력 시 사건 목록이 정상적으로 반환되는가?
  • 사건 정보에 연도, 장소, 설명이 포함되는가?
  • 데이터가 없을 경우 적절한 안내 메시지가 반환되는가?

• 음성 출력 및 인물화 (TTS + RVC)

  • 텍스트 응답이 음성 출력 단계로 정상 전달되는가?
  • 최종 음성 파일이 재생 가능한 상태로 생성되는가?

3.2 핵심 원칙

핵심 원칙

• 외부 API, 모델 호출 구간을 명확히 분리하여 테스트한다
• 파일 기반 작업은 반드시 존재 여부 · 크기 · 포맷을 함께 검증한다
• 실패 상황에서는 단순한 print 출력이 아닌, 원인을 바로 알 수 있는 에러 메시지를 남긴다

4. TTS_RVC 음성변환 전체 구조 (HistoryAI 적용 관점)

4.1 HistoryAI에서의 역할

TTS_RVC 음성변환은 단순히 텍스트를 읽어주는 기능이 아니라,

• 사용자가 질문하면
• 역사 인물 AI가 답변하고
• 그 답변을 해당 인물의 목소리로 들려주는 핵심 인터랙션 요소이다.

즉, HistoryAI에서의 위치는 다음과 같다.

[사용자 질문]
     ↓
[인물 AI 답변 (텍스트)]
     ↓
[TTS_RVC 음성변환]
     ↓
[역사 인물의 목소리로 출력]

5. TTS 단계 설명 (HistoryAI 내부 모듈)

5.1 역할

• HistoryAI에서 생성된 인물 AI의 텍스트 응답을
• 기본 음성(wav)으로 변환

이 단계에서는 아직 특정 인물의 목소리가 아니라,

📌 *"말의 내용이 정확히 들리는 음성"*을 만드는 것이 목적이다.

5.2 HistoryAI 기준 단위 테스트 포인트

- 인물 AI 응답 텍스트가 정상적으로 전달되는가?
- 텍스트 길이가 0이 아닌가?
- wav 파일이 정상적으로 생성되는가?
- HistoryAI 파이프라인에서 다음 단계로 넘길 수 있는 형식인가?

6. RVC 음성 변환 단계 설명 (인물 AI 음성화)

6.1 HistoryAI에서 RVC의 의미

RVC는 HistoryAI에서 인물 AI를 ‘캐릭터로 완성’시키는 단계이다.

• TTS 음성의 발음·억양은 유지
• 역사 인물의 화자 특성(목소리)만 입힘

즉,

🧠 *"AI가 말하는 것" → "그 인물이 말하는 것처럼 느끼게 하는 기술"*

✍️ 마무리

이번 6번째 멘토링은 기능 구현 단계에서 검증 단계로 넘어가는 전환점이었다.

다음 단계에서는 이 단위 테스트들이 모여 안정적인 전체 서비스 파이프라인을 구성하게 될 것이다.

1. 교과서 선정 이유

Q. 여러 교과서가 있는데 왜 ‘미래엔’ 교과서를 사용했는가?

• A. 미래엔 교과서는 현장에서 가장 많이 사용되고 있는 교과서로,
  실제 수업 환경과의 적합성과 활용 가능성을 고려하여 선택하였다.

2. 토론 요약 기능의 필요성 및 레거시 여부

Q. 토론을 요약하는 기능은 기존(레거시)에도 있는 기능 아닌가?

• A. 기존에도 선생님이 요약 가능 하지만, 본 프로젝트에서는
  수업 시간 내 토론을 효율적으로 운영하기 위해
  교실 환경에 맞춘 토론 요약 기능을 설계하였다.

Q. 그렇다면 선생님은 어떤 인사이트를 제공할 수 있는가?

• A. AI는 토론 내용을 정리하고 구조화하는 역할을 수행하며,
  교사는 이를 바탕으로 해석, 확장 질문 제시, 비판적 사고 유도 등
  고차원적인 교육적 인사이트를 제공한다.

3. AI 할루시네이션(오답) 문제 대응 방안

Q. AI 답변은 틀릴 수 있는데, 할루시네이션 문제를 어떻게 해결할 것인가?

• A.
  • AI 인물과의 대화 기능에서는 AI임을 명확히 인지시키는 안내를 제공한다.
  • AI 챗봇 기능에서는 교과서 기반 페이지 및 근거 자료를 함께 제공하여
    답변의 출처를 확인할 수 있도록 한다.
  • 이를 통해 AI 답변에 대한 무비판적 수용을 방지하고
    학습자의 비판적 사고를 유도한다.

4. 교과서 기반 데이터 구축의 한계 및 향후 계획

Q. 교과서 기반 자료를 만들 때 인력 자원이 많이 들 것 같은데, 향후 계획은?

• A.
  • 장기적인 확장 계획은 아직 수립되지 않았다.
  • 이번 프로젝트에서는 범위를 명확히 제한하여
    직접 교과서 기반 데이터를 구축하는 방식으로 진행한다.
  • 프로젝트의 실현 가능성과 교육적 효과 검증에 집중한다.

📝 종합 피드백 요약

• 교과서 선정과 기능 설계 전반에서 수업 현장 중심의 실용성을 고려함
• AI는 보조 도구이며, 교사의 역할과 교육적 판단이 핵심임을 명확히 함
• 할루시네이션 문제를 출처 제공과 인식 유도로 보완하려는 접근이 긍정적

🧑‍🏫 멘토 회고록

1. 토론방 Table 관련 피드백

멘토님께서는 토론방(Table) 설계에 대해 언급하시며,
현재 구조에서 토론 데이터의 역할과 흐름이 명확하게 드러나지 않는 점을 짚어주셨다.
특히 토론방이 어떤 책임을 가지며, 다른 도메인과 어떻게 연결되는지에 대한
구조적 정리가 필요하다는 의견을 주셨다.

2. Backend 구조에 대한 아키텍처 피드백

현재 프로젝트는

• Backend (Spring Boot)
• AI Backend (Spring Boot)

로 분리되어 있는 구조이다.

멘토님께서는 두 백엔드가 모두 Spring Boot 기반임에도 불구하고
역할 분리가 명확하지 않다는 점을 지적하셨다.
특히 이로 인해 User 인증 및 권한 처리 과정에서 이슈가 발생할 가능성이 높다는 점을 강조하셨다.

3. 개선 방향 제안

멘토님께서는 다음과 같은 구조가
아키텍처적으로 더 적합하다는 의견을 주셨다.

• Backend를 하나의 Spring Boot 서버로 통합
  • 사용자 인증 및 인가를 단일 지점에서 관리
  • 도메인 책임을 명확히 분리하되, 서버는 통합
• AI 처리를 담당하는 FastAPI 서버는 유지
• 추후 필요 시 FastAPI 서버를 Django 기반으로 변환
  • 서비스 확장성과 유지보수성을 고려한 단계적 전환

4. 회고 및 느낀 점

이번 멘토링을 통해
단순히 기능을 분리하는 것보다 역할과 책임이 명확한 아키텍처 설계가 중요하다는 점을 다시 한번 인식하게 되었다.
특히 인증과 같은 핵심 공통 기능은 분산시키기보다
중앙에서 관리하는 것이 안정성과 확장성 측면에서 유리하다는 점을 배울 수 있었다.

이번 멘토링에서는 프론트엔드 / 백엔드 / 클라우드 각 파트에서 진행 상황과 개선 방향을 공유받고,
“교과서 기반 History AI 서비스”를 더 현실적으로 만들기 위한 다음 액션 아이템을 정리했다.

1) 이번 주 멘토링 핵심 요약

• 프론트: 교과서 PDF 처리 방식 재검토 (용량 이슈로 S3 구조 변경 필요)
• 백엔드: ERD 피드백 반영 및 데이터 구조 정리 필요
• AI: Bedrock 컬렉션 관리로 비용 절감 + AI Agent(네비게이션/이동 기능) 설계 아이디어 제안
• 클라우드: 이중화(HA) 전략을 더 고민하고, EKS 학습 + 실습으로 운영 관점 이해 강화

2) 프론트엔드: 교과서 PDF 저장/로딩 전략

문제

• 현재 교과서 PDF가 크기가 너무 커서 기존 방식으로 다루기 어려움
• 로딩/다운로드/렌더링이 느려지고, 배포/운영 관점에서도 부담이 큼

개선 방향

• 교과서 PDF를 새로운 S3 버킷(또는 새로운 경로 구조) 에 담아 관리하는 방향이 적절해 보임
• (추가로 고려할 점)
  • PDF를 페이지 단위 이미지(PNG/JPG) 또는 분할 PDF로 쪼개서 제공하면 UX/성능에 유리
  • 교과서 페이지 이동 기능(목차/페이지 점프)과 연결하기 쉬움

3) 백엔드: ERD 피드백 반영

받은 피드백 포인트(요지)

• DB 설계에서 테이블 관계/정규화/핵심 엔티티가 더 명확해야 함
• 서비스 기능(교과서, 토론, 유저, 학습 기록 등)에 맞춰 ERD를 더 탄탄하게 다듬는 단계가 필요

다음 액션

• 멘토링에서 받은 피드백을 기준으로 ERD를 업데이트하고,
• API 설계와 연결되는 형태로 엔티티 책임/관계를 명확히 정리하기

4) AI: Bedrock 비용 절감 + AI Agent 아이디어

(1) Bedrock 비용 절감: “컬렉션 관리”

• Bedrock 지식베이스/컬렉션을 정리하고 관리하는 방식을 통해 비용을 줄일 수 있다는 방향을 공유받음
• 불필요한 데이터 중복/동기화 빈도/인덱싱 범위를 줄이는 관점에서 점검 필요

(2) AI Agent 기능 제안: “바로 이동하는 에이전트”

멘토링에서 나온 가장 인상적인 아이디어는 Agent를 ‘네비게이션 도우미’로 쓰는 것이었다.

예시 기능:

• 사용자가 “삼국시대로 가줘”라고 하면 → 바로 해당 시대 화면/연표로 이동
• 사용자가 “교과서 123페이지 보여줘”라고 하면 → 해당 페이지로 점프
• 즉, Claude(LLM)가 단순 답변을 넘어 UI 이동/상태 전환을 트리거하는 도우미 역할을 수행

정리하면, “질문 답변” + “화면 이동/컨텍스트 전환”을 결합한 형태로 사용성을 크게 올릴 수 있다.

5) 클라우드: 이중화와 EKS 학습 방향

이중화(HA) 관점

• 서비스 운영을 고려하면 장애 대응/가용성을 더 진지하게 설계해야 함
• 단일 인스턴스/단일 AZ 구조에서 벗어나,
  • 서비스 레벨(서버)
  • DB 레벨
  • 네트워크/로드밸런서 레벨 각각의 이중화 포인트를 점검할 필요가 있음

EKS 학습/실습 목표

• “EKS를 공부한다”에서 끝내지 않고, 직접 실습해보는 것까지 진행하면 좋겠다는 피드백
• 실습을 통해:
  • 배포 단위(Deployment/Service/Ingress)
  • 오토스케일링(HPA)
  • 운영 관점(롤링 업데이트/장애 대응) 같은 실제 운영 이슈를 체감할 수 있음

6) 다음 주까지의 To-Do(액션 아이템)

• 교과서 PDF를 S3에 어떻게 적재/분할/서빙할지 프론트 전략 확정
• ERD 피드백 반영해서 DB 구조 개선 및 API 설계와 연결
• Bedrock 컬렉션 운영/관리 전략으로 비용 절감 포인트 정리
• Claude 기반 Agent 네비게이션 기능(시대 이동, 페이지 점프) 설계 초안 작성
• 이중화(HA) 체크리스트 작성 + EKS 실습(간단한 배포라도) 진행

마무리

이번 멘토링은 단순히 “기능 개발”이 아니라,
운영/비용/사용성(네비게이션)까지 고려한 설계 방향을 잡는 데 도움이 됐다.
특히 AI Agent를 UI 이동 도우미로 활용하는 아이디어는 사용자 경험을 크게 개선할 수 있는 핵심 포인트라서, 다음 단계에서 우선순위를 높게 두고 구체화해볼 예정이다.

“내 사내 문서/교재/매뉴얼을 LLM이 똑똑하게 참고하면서 대답해 주게 만들고 싶다”
이걸 AWS 매니지드 서비스만으로 해결해 주는 게 바로 Amazon Bedrock Knowledge Bases(지식 기반) 입니다.
(https://docs.aws.amazon.com/bedrock/latest/userguide/kb-how-it-works.html?utm_source=chatgpt.com)

이 글은 Bedrock 지식 기반을 처음 쓴다는 가정으로,

1. 개념 이해
2. 사전 준비 사항 (Root User vs IAM User 분리)
3. 데이터 소스(S3 등) 연결 & 동기화(Sync)
4. Test

을 한 번에 따라갈 수 있게 정리했습니다.

1. Bedrock Knowledge Bases 개념 정리

1-1. RAG + 지식 기반이 뭐야?

RAG(Retrieval-Augmented Generation) 는 한 줄로 말하면:

“답변하기 전에 내 문서에서 관련 내용을 먼저 찾아서 그걸 근거로 답변하게 하는 방식”

작동 흐름은 보통 이래요:

1. 사용자의 질문을 임베딩(벡터화)
2. 내 문서 벡터 DB(벡터 스토어) 에서 관련 문서 조각(chunk) 검색
3. 검색 결과를 프롬프트에 끼워 넣고 LLM이 답변 생성

Amazon Bedrock Knowledge Bases는 이 과정을 AWS에서 “자동으로” 묶어둔 서비스예요.

• 문서 → chunk → 임베딩 → 벡터 스토어 저장
• 질문 → 검색 → 답변 생성(출처 포함)

즉, “RAG 파이프라인을 직접 조립하지 않아도 되게 해주는 서비스”라고 보면 됩니다.

1-2. 기본 구성 요소(지식 기반을 만들면 생기는 것들)

지식 기반을 하나 만들면 보통 아래 4가지가 핵심입니다.

Amazon Bedrock 지식 기반 데이터의 사전 조건
https://docs.aws.amazon.com/ko_kr/bedrock/latest/userguide/knowledge-base-ds.html

• 데이터 소스
  • 예: S3 버킷에 올린 PDF/HTML/텍스트, Confluence, SharePoint, Salesforce, Kendra, Neptune, RDS/Redshift 등
• 임베딩 모델(Embedding Model)
  • 예: amazon.titan-embed-text-v1
  • 문서를 “벡터(숫자)”로 바꿔서 검색 가능하게 만듦
• 벡터 스토어(Vector Store)
  • 예: Amazon OpenSearch Serverless(기본), 또는 Redis/Pinecone 같은 외부 벡터 DB
• LLM / Inference Profile
  • 검색된 문서 조각을 바탕으로 “답변”을 만들어주는 모델
  • 예: global.anthropic.claude-sonnet-4-20250514-v1:0 같은 inference profile ID

2. 사전 준비 사항 (Root User vs IAM User 분리)

AWS에서 Bedrock 지식 기반을 쓰기 전에,
루트 계정으로 한 번만 할 일과 IAM 사용자로 계속 할 일을 분리해 두면 운영이 진짜 편해져요.

루트 계정으로는 지식 기반 Bedrock 기능을 사용 할 수 없습니다!

2-1. Root User(루트 계정)로 “한 번만” 할 일

루트 계정은 결제·보안·최초 설정용으로만 쓰는 게 베스트 프랙티스입니다.
실제 Bedrock 작업은 전부 IAM 사용자/역할로 하는 걸 권장합니다.

1) 결제/리전 확인

• Bedrock, OpenSearch Serverless, S3에서 요금이 발생할 수 있어요.
• 결제 수단 등록 + 예산/청구 알림 설정(가능하면 꼭)
• 사용할 리전(예: ap-northeast-2, Seoul)을 미리 정해두기

2) 관리자용 IAM 사용자(또는 IAM Identity Center) 만들기

• 루트 계정을 매일 쓰지 않기 위해 “관리자 계정”을 만들어요.
• 예: AdministratorAccess 권한 부여
• MFA(다중 인증) 설정도 추천

3) 루트 계정은 최소 사용 원칙

• 루트로 하는 일:
  • 비밀번호/MFA 관리
  • 결제/계정 관련 작업
• 그 외 Bedrock/리소스 작업은 IAM 사용자로만 진행

➡️ 여기까지는 “계정 만들고 한 번만” 하면 됩니다.

2-2. IAM User(관리자/개발자)로 “실제 작업”하기

이제부터가 진짜 Bedrock 지식 기반 만드는 단계예요.

2-2-1. 권한 구분(운영이 편해지는 방식)

• 관리자(Admin)
  • S3, OpenSearch, IAM Role, Knowledge Base 생성·설정 담당
• 개발자(Developer)
  • 만들어진 지식 기반을 질의/테스트/API 호출 담당

처음에는 “관리자 / 개발자” 2개로만 나눠도 충분합니다.

2-2-2. 관리자 IAM 사용자로 할 일 (세팅 담당)

1) 사용 리전 확정

• Bedrock + 사용할 모델이 지원되는 리전을 확인하고 통일
• 예: ap-northeast-2 (Seoul)

2) Bedrock 모델 사용 허용(Access 요청/Enable)

• Bedrock 콘솔에서 사용할 모델(Claude, Titan 등)을 “사용 가능” 상태로 설정
• 관리자 계정 권한(초기 편의상 넓게):
  • bedrock:* (초기에는 편함, 운영 안정화 후 최소 권한으로 줄이기 권장)

3) 데이터 소스(S3) 준비

• PDF/문서/이미지 등을 담을 전용 S3 버킷 준비

• 참고: S3생성 및 권한 설정 블로그

• 폴더 구조 예시

  • raw/ : 원본 PDF/이미지
  • processed/ : 정리된 텍스트/Markdown
  • kb/ : 지식 기반이 실제로 읽을 경로
    • 예: kb/textbook/middle/grade1/

• S3 권한(최소)

  • s3:ListBucket, s3:GetObject, s3:PutObject

4) 벡터 스토어(OpenSearch Serverless) 준비(선택)

• Bedrock이 자동으로 만들게 할 수도 있고,
• 직접 만든 OpenSearch Serverless 컬렉션을 연결할 수도 있어요.
• 필요 권한 예:
  • aoss:* 또는
    • aoss:CreateCollection, aoss:BatchGetCollection
    • aoss:UpdateAccessPolicy, aoss:CreateIndex

5) 지식 기반용 IAM Role 생성

• Bedrock이 S3/벡터스토어에 접근하려면 서비스 역할(Role)이 필요해요.
• Trust Policy에 bedrock.amazonaws.com 허용
• Permission Policy 예:
  • S3 읽기(s3:GetObject, s3:ListBucket)
  • OpenSearch Serverless 접근 권한
• 콘솔에서 “새 역할 생성”으로 자동 생성해도 OK

2-2-3. 개발자 IAM 사용자로 할 일 (사용/호출 담당)

1) Bedrock 지식 기반 접근 권한

• 최소 권한 예:
  • bedrock:ListKnowledgeBases, bedrock:GetKnowledgeBase
  • bedrock:Retrieve, bedrock:RetrieveAndGenerate
  • (필요 시) 모델 호출 bedrock:InvokeModel
• 출처 문서를 S3에서 직접 열어야 하면:
  • 해당 버킷 s3:GetObject

2) 콘솔에서 Knowledge Base 생성 & Sync

• Bedrock 콘솔 → Knowledge bases → Create knowledge base
• S3 경로 + IAM Role + 벡터 스토어(자동/수동) 선택
• 생성 후 Sync 버튼을 눌러 문서 인덱싱(임베딩/저장)

3) 콘솔에서 Test knowledge base로 질의 테스트

• “Test knowledge base”로 질문해보고
  • 답변이 나오는지
  • 출처(footnote)가 붙는지 확인

4) 코드에서 RetrieveAndGenerate 호출 준비

• 로컬/서버에 AWS SDK 설치(boto3 등)
• bedrock-agent-runtime 클라이언트로 호출
• Access Key 또는 Role에 아래 권한이 있어야 정상 동작:
  • bedrock:RetrieveAndGenerate
  • bedrock:InvokeModel

2-3. 권장 권한 패턴 한 줄 요약

• Root User
  • 결제/보안/계정 초기 설정만
• Admin IAM
  • S3/OpenSearch/IAM Role/Knowledge Base 생성·설정
• Dev IAM
  • 지식 기반 테스트 + API 호출(RetrieveAndGenerate) 위주

이렇게 나누면,

• “루트 계정으로 실수”를 막고
• 팀원마다 할 수 있는 범위를 명확히 나눌 수 있어요.

3. 데이터 소스(S3) 연결 & 동기화(Sync)

이번 파트는 “내 문서를 Bedrock 지식 기반이 읽게 만드는 과정”입니다.
핵심은 딱 2가지예요.

1) S3(데이터 소스)를 Knowledge Base에 연결
2) Sync(동기화)를 눌러서 인덱싱(Chunk → Embedding → Vector store 저장)

데이터 소스/형식 사전 조건 참고
https://docs.aws.amazon.com/ko_kr/bedrock/latest/userguide/knowledge-base-ds.html

BedRock 지식 기반 생성시 참고 블로그 : https://dobby-isfree.tistory.com/241

3-1. S3에 문서 업로드 준비

1) S3 버킷/폴더 구조(예시)

• raw/ : 원본(그대로 보관)
• processed/ : 전처리된 텍스트/마크다운(선택)
• kb/ : 지식 기반이 읽을 “최종” 경로 (여기만 연결하는 걸 추천)

예:

• s3://my-kb-bucket/kb/manual/
• s3://my-kb-bucket/kb/textbook/middle/grade1/

2) 업로드

• PDF, txt, md, html 등 문서를 kb/ 아래로 업로드합니다.

3) 주의(자주 막히는 포인트)

• 파일명이 너무 길거나 특수문자가 많으면 관리가 어려워서,
  • 한글 파일명도 가능은 하지만, 문제나면 영문/숫자/언더바로 정리 추천
• 같은 문서를 여러 번 올리면 “중복 chunk”가 생길 수 있으니
  • 폴더 버전(v1/, v2/)로 관리하면 좋습니다.

3-2. Knowledge Base 생성 시 S3 데이터 소스 연결

Bedrock 콘솔에서 아래 순서대로 진행합니다.

1) Bedrock 콘솔 접속

• Amazon Bedrock → Knowledge bases → Create knowledge base

2) Knowledge Base 기본 설정

• Name: my-kb 처럼 구분 가능한 이름
• IAM role: (2장에서 만든 Bedrock 서비스 역할 선택)

3) Data source(데이터 소스)로 S3 선택

• Data source type에서 Amazon S3 선택
• S3 URI에 kb/ 경로를 정확히 입력
  예: s3://my-kb-bucket/kb/manual/

4) Embedding 모델 선택

• 예: amazon.titan-embed-text-v1 등
  (문서 → 벡터로 바꿔서 검색 가능하게 만듦)

5) Vector store 선택

• 대부분은 기본값(예: OpenSearch Serverless 자동 구성)으로 진행해도 OK
• 이미 만들어둔 벡터 스토어가 있다면 선택해서 연결

6) Create

• 생성 완료 후 Knowledge base 상세 화면으로 이동합니다.

3-3. 동기화(Sync)란 무엇이고, 언제 누르나?

Sync = “S3 문서를 읽어서 지식 기반에 반영하는 과정”입니다.

Sync를 누르면 내부적으로:

• S3 문서 읽기
• 문서를 chunk(조각) 로 나누기
• 각 chunk를 임베딩(벡터화)
• 벡터 스토어에 저장
• 이후 질문이 들어오면, 관련 chunk를 검색해서 답변에 사용

즉, S3에 문서를 올렸다고 바로 반영되는 게 아니라, Sync를 해야 반영됩니다.

3-4. 최초 1회 Sync(인덱싱) 실행 방법

1) Bedrock 콘솔 → Knowledge base 선택 2) Data sources 탭 이동 3) 연결된 S3 데이터 소스 선택 4) Sync 버튼 클릭

확인할 것

• Sync status가 In progress → Completed로 바뀌는지
• 실패하면 Failed로 뜨면서 원인(권한/파일형식 등)이 나옵니다.

3-5. 문서 업데이트할 때 운영 방식(추천)

현업에서는 보통 아래처럼 운영합니다.

• 새 문서 추가/수정/삭제 → S3 kb/ 경로에 반영
• 변경 후 Sync 실행
• 큰 업데이트는 폴더 버전으로 분리
  • kb/manual/v1/ (운영)
  • kb/manual/v2/ (준비)
• 검증 완료 후 v2를 연결하거나, v1을 교체

3-6. Sync가 실패할 때 가장 흔한 원인 TOP 5

1) IAM Role 권한 문제

• Bedrock 서비스 역할에 S3 읽기 권한이 부족함
  • s3:ListBucket, s3:GetObject 확인

2) S3 경로 오타

• s3://bucket/kb/manual/ 처럼 prefix가 정확한지 확인

3) 지원하지 않는 파일 형식/손상된 파일

• 문서 형식이 조건에 맞는지 확인
  https://docs.aws.amazon.com/ko_kr/bedrock/latest/userguide/knowledge-base-ds.html

4) 리전(Region) 혼용

• S3/Knowledge Base/벡터 스토어 리전이 섞이면 문제가 될 수 있어요.
• 가능하면 같은 리전으로 통일 추천

5) 너무 큰 문서/너무 많은 문서

• 처음엔 테스트용으로 파일 몇 개만 넣고 Sync 성공부터 확인한 뒤, 점진적으로 전체 문서를 넣는 방식이 안전합니다.

3-7. (체크) Sync 이후 제대로 들어갔는지 확인

• Bedrock 콘솔 → Knowledge base → Test knowledge base
• “문서에 있는 문장을 그대로” 물어보기
• 답변에 출처(footnote) 가 붙으면 정상적으로 검색이 되는 상태입니다.

4. 콘솔에서 테스트(지식 기반 Test knowledge base)

지식 기반을 만들고 Sync까지 완료했다면, 이제 콘솔에서 바로 질문을 던져서

• 검색이 잘 되는지(문서를 제대로 찾는지)
• 답변이 근거(출처)와 함께 나오는지 를 확인할 수 있습니다.

아래 화면처럼 Amazon Bedrock → 지식 기반 → (내 Knowledge base 선택) → 지식 기반 테스트로 들어가면 됩니다.

4-1. 테스트 화면 구성(왼쪽: 설정 / 오른쪽: 대화)

테스트 화면은 크게 2부분입니다.

• 왼쪽: 구성(설정)

  • 검색 방식 선택
  • 사용할 모델 선택(Claude 등)
  • 소스 청크(검색 결과 개수) 등 옵션 조정

• 오른쪽: 테스트

  • 질문 입력
  • 답변 생성 결과 확인
  • 출처(원문) 확인

4-2. 꼭 선택해야 하는 옵션 (가장 많이 하는 실수 방지)

✅ (1) “검색 및 응답 생성” 선택

왼쪽 검색 및 응답 생성에서 아래 둘 중 반드시 이걸 선택합니다.

• 검색 전용: 데이터 소스
  → 문서 검색 결과만 보여주고, 답변 생성은 안 함

• 검색 및 응답 생성: 데이터 소스 및 모델 ✅
  → 검색 + LLM 답변 생성까지 한 번에 수행

📌 보통 우리가 원하는 건 “RAG 답변”이라서 검색 및 응답 생성이 맞습니다.

✅ (2) 모델(Model) 선택

캡처처럼 Claude 3.5 Sonnet 등 원하는 모델이 선택되어 있어야 합니다.
(모델 접근 허용이 안 되어 있으면 목록에 안 뜰 수 있음)

4-3. 질문 입력 & 실행

오른쪽 미리 보기(채팅 영역)에 질문을 입력합니다.

예:

• 고려 건국 과정 설명해줘
• 후삼국 통일 과정의 핵심 사건을 정리해줘

실행:

• Enter: 전송/실행
• Shift + Enter: 줄바꿈

4-4. “출처가 붙는지”로 성공 여부 판단하기

정상적으로 지식 기반이 동작하면 답변에 출처 표시(footnote / [1] 같은 번호) 가 뜹니다.
캡처에서도 답변 중간에 [1][2] 같은 형태로 출처가 붙는 걸 확인할 수 있습니다.

추가로 왼쪽 또는 하단의 소스 청크(Source chunk) 영역에서

• 어떤 문서 조각이 검색되었는지
• 그 조각이 답변에 어떻게 사용됐는지 확인할 수 있습니다.

✅ 결론:

• 답변이 나오고
• 출처(각주)가 함께 붙는다
  → Sync + 검색 + 생성이 정상 동작 중입니다.

4-5. 테스트가 이상할 때(짧은 체크)

• 출처가 안 뜬다 → Sync가 안 되었거나, 검색 설정이 “검색 전용”으로 되어 있을 수 있음
• 질문이 문서랑 상관없는 일반 답변만 나온다 → 관련 문서가 S3에 없거나, chunk로 잘 안 잘렸을 수 있음
• 답변이 아예 안 나온다 → 모델 권한/리전/역할 권한(S3 읽기) 문제 가능성

1. 멘토링 개요

• 프로젝트명: HAI(History AI)
• 목적
  • 작성한 User Story를 멘토님께 설명
  • 각 Story에 대해 피드백 및 리뷰 진행
  • 기술 스택·아키텍처·기능 범위에 대한 방향성 정리

2. User Story & 서비스 컨셉 피드백

• User Story 구성 및 방향은 전반적으로 긍정적인 평가를 받음.
• 다만, 아이디어가 많기 때문에
  • 게임(테마) 요소는 일단 제외하고
  • 핵심 기능(MVP) 위주로 먼저 개발 시작하는 것이 좋다는 조언.
• 게임적인 요소(캐릭터, 스토리, UI 연출 등)는
  → 추후 안정화 후에 확장 요소로 고민하기로 함.

3. 교과서 & 이미지 처리 방안 논의

3.1 교과서 질문 처리 방식

• 사용자가 교과서에 대해 질문할 때, 교과서 정보를 어떻게 저장하고 검색할지 논의.
• 교과서를 단순 텍스트가 아니라 이미지 + 페이지 구조까지 고려해야 함.

3.2 이미지/페이지 처리 전략 (옵션)

1. Vector DB + 이미지 메타데이터 방식

   • 교과서를 섹션/단원/단락 단위로 분할하여 텍스트를 Vector DB화
   • 이미지는 별도로 저장하고,
     해당 이미지의 URL/경로를 메타데이터로 함께 저장
   • 검색 결과에서:
     • 관련 텍스트와 함께
       → 해당 페이지/이미지 URL을 사용해 이미지를 함께 노출 가능

2. 페이지 단위 뷰어 방식

   • 이미지를 따로 떼어 저장하지 않고,
   • 검색 시 문제가 있는 페이지 전체를 바로 보여주는 형식
   • 교과서 뷰어처럼 “현재 페이지”를 보여주고
     질문과 연결된 부분을 표시하는 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 템플릿을 생성해서 사용)
• 언제 사용?
  • 인프라가 거의 AWS 안에서만 구성될 때
  • “AWS 공식” 도구로 인프라를 정의/관리하고 싶을 때
  • HAI가 AWS에만 올인하고, 멀티클라우드 계획이 크지 않다면
    CloudFormation(+CDK)도 후보가 될 수 있음

Terraform vs CloudFormation 감각 정리

• Terraform:
  → “여러 클라우드를 포함하는 범용 IaC 툴”
• CloudFormation:
  → “AWS에 특화된 공식 IaC 서비스”

지난 주 멘토링 시간에는 교육 도메인에 적용할 수 있는 인공지능 기술인 RAG, Tool Calling, Vector DB에 대해 배웠다. 이를 바탕으로 "AI가 개인 맞춤형 IT 로드맵을 제공하는 서비스"라는 주제를 설정했고, 지난 일주일간 Agile 방식으로 프로젝트를 진행했다.

📋 일주일간의 작업 과정

1. Vision Board 작성

프로젝트의 방향성과 최종 목표를 시각화하며 팀원들과 같은 그림을 그리기 위한 첫 단추를 끼웠다.

2. User Story와 Scenario 작성

가장 먼저 집중한 것은 사용자 관점에서 서비스를 정의하는 것이었다. "누가, 왜, 무엇을 원하는가?" 라는 질문에 답하며 User Story를 작성했고, 실제 사용 시나리오를 구체화했다. 단순히 기능을 나열하는 것이 아니라, 실제 사용자가 겪을 문제와 그 해결 과정을 상상하며 작성하니 서비스의 방향성이 명확해졌다.

3. Theme Epic과 Feature 정리

큰 주제(Theme Epic)를 설정하고, 이를 구현 가능한 Feature 단위로 쪼개는 작업을 진행했다. GitHub Issues에 Feature 태그를 붙여가며 9개의 이슈를 오픈했고, 각각에 우선순위와 담당자를 배정했다. AX 조사, 학습 주제 선정, 환경설정 기능 구현 등 다양한 작업이 동시다발적으로 진행되었다.

4. Agile 전체 프로세스 체험

이번 주는 'Agile 에자일 전체'라는 이슈명 그대로, 애자일 방법론의 전 과정을 경험한 주였다. 스프린트 계획, 일일 스탠드업(비록 비동기로 진행되었지만), 진행 상황 공유, 그리고 회의 태그가 붙은 작업들을 통해 팀원들과 끊임없이 소통했다.

🎯 기존 서비스들과의 차별점

1. AI와 함께 개발 목표 직접 설정

사용자가 AI와 대화하며 자신의 상황과 목표에 맞는 학습 계획을 능동적으로 설계할 수 있도록 한다.

2. 화면 모니터링 기반 트러블슈팅 기능

학습 중 발생하는 오류를 실시간으로 감지하고 해결책을 제시하는 기능을 구상했다.

💡 멘토님 피드백
계속 모니터링하는 방식은 기술적으로 구현이 어렵고 사용자 경험 측면에서도 부담스러울 수 있다. 사용자가 특정 버튼을 눌러 현재 화면을 캡처하고, 그것을 바탕으로 트러블슈팅을 제공하는 방식이 더 현실적일 수 있다.

3. 맞춤형 로드맵 생성 및 진행 관리

사용자의 현재 수준과 목표, 가용 시간 등을 고려한 개인화된 학습 로드맵을 생성하고, 그 로드맵을 따라갈 수 있도록 지속적으로 가이드한다.

4. 개발 환경 설치 자동화

초보자들이 가장 어려워하는 개발 환경 구축 과정을 자동화한다.

💡 멘토님 피드백
PC의 모든 권한을 부여받아 한 번에 설치하는 방식은 보안상 위험할 수 있다. 사용자가 안전하게 느낄 수 있는 단계적 접근이 필요하다.

🔍 다음 단계를 위한 과제

📌 참고 자료: https://blog.naver.com/sayment/223733261853

멘토님께서 11개의 교육 테마 서비스 중 우리 아이디어가 어디에 포함되는지 명확히 정의하고, 아이디어를 재설계해보라는 피드백을 주셨다.

*"기능들은 구상했지만, 서비스의 정체성과 포지셔닝을 더욱 명확히 해야 할 시점이다."*

다음 주에는 이 부분에 집중하며 아이디어를 정교화할 계획이다. 새로운 아이디어를 제시하기 위한 방법으로는 AI와 함께 대상과 기능을 엮어 아이디어를 제시하고 구체화하는 방향으로 다시 아이디어를 제시하는 방법을 알려주셨다.

⚙️ 아이디어 결정 후 진행 계획

✔️ 1) 아이디어 구체화 • 대상(취준생/개발자/학생 등) + 기능 조합 • POC를 통해 기능 검증 진행

✔️ 2) 기능 정리 • 핵심 기능(MVP) 선정 • 구현 가능 범위 및 우선순위 설정

✔️ 3) 기술 스택 결정 • Frontend / Backend / DB / CI/CD 전체 구조 설계 • Python or Java 중 AI 로직 개발 언어 선택 • PostgreSQL Vector DB vs OpenSearch Vector DB 비교 후 선택

✔️ 4) 역할 분담 • 팀원별 Front/Back/AI/Infra 역할 분담 • 업무 로드맵 제시

✔️ 5) POC(Proof of Concept) 일정 초기에 배치 • 기능이 실제 가능한지 빠르게 검증 • 실패 시 Plan B 아이디어로 회귀

✔️ 6) 프로젝트 구조 정립 • FrontEnd 폴더 구조 (React/Next.js Best Practice 참고) • BackEnd 폴더 구조 (Spring Boot/FastAPI Best Practice 참고) • 구조 확정 후 개발 시작

API 라우팅 패턴은 클라이언트 요청이 어떤 서비스로 전달될지 명확하게 정의하는 규칙입니다.

1. 서비스 경로를 표준화하기 위해

서로 다른 팀이 개발한 서비스가 뒤섞이면 /users, /user, /api/v1/user, /v1/users 같은 비일관적 경로들이 발생합니다.

API 라우팅 패턴을 적용하면 다음처럼 모든 서비스가 같은 규칙을 따르게 된다.

/api/v1/users
/api/v1/orders
/api/v1/auth

2. API Gateway가 요청을 올바른 서비스로 라우팅하기 위해

MSA 구조는 프론트엔드 → API Gateway → Microservices Gateway는 요청이 들어왔을 때 이렇게 해야 합니다.

/api/v1/users → user-service  
/api/v1/auth  → auth-service  
/api/v1/routine → routine-service

3. 버저닝을 통한 서비스 변경 관리

API는 시간이 지나면 변경되기 마련이다. 하지만 기존 앱은 옛버전을 여전히 호출할 수 있기 때문에, 버전 관리(v1, v2, v3 …) 해야 서비스 업그레이드가 용이합니다

/api/v1/users  ← 기존 앱 유지
/api/v2/users  ← 새로운 Response 제공

4. 보안·인증 정책을 서비스별로 다르게 적용 가능

/api/v1/auth/* → 인증 제외 (login 필요 없음)
/api/v1/users/* → JWT 인증 필요
/api/v1/admin/* → 관리자 Role 필요

일관된 라우팅 구조가 있어야 Gateway, Spring Security, Role 기반 접근 제어를 쉽게 설정할 수 있다.

호스트 이름 라우팅

https://api.myservice.com/users
https://admin.myservice.com/dashboard
https://m.myservice.com/home

이런식으로 요청이 들어오면 각각의 도메인이 다르기에 Gateway가 Service를 다르게 보낸다.

1) 기능별로 도메인을 분리할 수 있음 (서비스 경계 명확)

    •    api.example.com → API 서버
    •    admin.example.com → 관리자 웹
    •    cdn.example.com → 정적 파일
    •    openapi.example.com → 외부 개발자용 API

2) URL 구조를 깔끔하게 유지할 수 있음

Path-based Routing (경로 기반)

example.com/api/users
example.com/admin/dashboard

Host-based Routing (도메인 기반)

api.example.com/users
admin.example.com/dashboard

3) MSA + API Gateway와 궁합이 최고임

Nginx, AWS ALB, Spring Cloud Gateway, Envoy 모두 지원하는 패턴.

예: Spring Cloud Gateway에서 Host 라우팅

routes:
  - id: user-service
    uri: http://user-service:8080
    predicates:
      - Host=api.example.com

  - id: admin-service
    uri: http://admin-service:8080
    predicates:
      - Host=admin.example.com

호스트 이름 라우팅 패턴은 도메인을 기준으로 요청을 서로 다른 백엔드 서비스로 라우팅하는 패턴이다. MSA 환경에서 서비스 경계를 명확하게 하고, 인증/보안/트래픽 정책을 도메인 단위로 분리하여 적용할 수 있다는 장점이 있다. 또한 API Gateway(Nginx, ALB, SCG 등)에서 광범위하게 지원되며, 규모가 커질수록 Host 기반 분리가 API 설계와 운영 효율을 크게 향상할수있다.

AWS API 라우팅 패턴 https://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/cloud-design-patterns/api-routing.html

ACL은 서로 다른 언어를 쓰는 두 시스템 사이를 통역해 주는 "통역사" 입니다! 업스트림 팀 : 기존에 이미 있던 레거시 모놀로식 시스템 다운스트림 팀 : 새로 만든 마이크로서비스 업스트림, 다운스트림은 같은 곳에 있지만 서로 다른 언어와 구조를 사용합니다.

업스트림(모놀로식)은 "직원"을 Employee라고 하고 다운스트림(마이크로서비스)은 "직원"을 Worker로 라고 하면 서로의 데이터를 이해하기 위한 통역사(ACL)이 필요합니다!

ACL 작동 방식 STEP

1️⃣ 데이터 수신 – 업스트림 시스템으로부터 데이터를 받습니다. 2️⃣ 데이터 변환 – ACL이 다운스트림에서 이해할 수 있도록 모델 변환을 수행합니다. 3️⃣ 데이터 활용 – 마이크로서비스는 자신의 모델을 유지한 채 외부 데이터를 안전하게 사용합니다.

업스트림 시스템 (기존 모놀리스) 다운스트림 시스템 (마이크로서비스) 통합된 ACL 구조 [출처: AWS Cloud Design Patterns]

🔗 AWS 공식 문서 ACL(Anti-Corruption Layer) https://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/cloud-design-patterns/acl.html 🔗 AWS 구현 ACL https://github.com/aws-samples/anti-corruption-layer-pattern

아이디어에 대해 생각하기 이전에 프로젝트 안에 들어가야는 핵심 요소부터 알아봤다.

첫번째 멘토링에서는 최근 인공지능 분야에서 핵심적으로 다뤄지는 개념인 RAG(Retrieval-Augmented Generation), Tool Calling, 그리고 Vector DB(Vector Database) 에 대해 배웠다. 이 세 가지 요소는 오늘날 생성형 AI 시스템의 기본 구조를 이루는 중요한 기술로, AI가 단순히 “대답하는 존재”를 넘어 스스로 필요한 정보를 찾고, 활용하며, 더 정확한 결과를 만들어내는 과정을 가능하게 한다.

RAG

검색 증강 생성(RAG)이란? https://aws.amazon.com/ko/what-is/retrieval-augmented-generation/

RAG는 단순한 검색(Search) 기술이 아니라, AI가 스스로 ‘정보를 찾아 활용하는 능력’을 부여하는 구조이다. 일반적인 생성형 AI 모델은 학습 시점 이후의 데이터에 접근할 수 없기 때문에, 새로운 정보나 기업 내부 문서를 다루는 데 한계가 있다. 하지만 RAG는 질문을 받아 의미적으로 관련된 문서를 Vector DB에서 검색한 후, 그 결과를 LLM에게 전달해 답변을 생성함으로써 이 문제를 해결한다. 즉, 모델이 “모르는 것을 아는 척하지 않고”, 실제 근거가 있는 정보를 바탕으로 대답할 수 있게 만드는 것이다.

Tool Calling

Tool Calling은 AI가 스스로 “검색이 필요하다”라고 판단하면 자동으로 RAG 시스템이나 외부 API를 호출해 결과를 받아오는 기능이다.

VECTOR DB

vector DB 예시

{
  "id": "chunk_0001",
  "document_id": "doc_123",
  "text": "RAG는 외부 지식을 검색해 LLM의 답변 정확도를 높이는 아키텍처이다.",
  "embedding": [
    0.0321, -0.1147, 0.2890, 0.0573, -0.0418, 0.1025, -0.2206, 0.0159
  ],
  "dimension": 8,
  "metadata": {
    "source": "notion",
    "title": "RAG 개요",
    "language": "ko",
    "tags": ["RAG", "VectorDB", "LLM"],
    "created_at": "2025-11-11T09:20:00+09:00",
    "uri": "https://example.org/rag-overview"
  }
}

1️⃣ id 와 document_id • id: 벡터 데이터베이스 내에서 이 조각(chunk)을 구분하는 고유 식별자입니다. → 하나의 문서를 여러 조각으로 나눠 저장하기 때문에, 각 조각마다 고유한 ID가 필요합니다. • document_id: 이 벡터가 속한 원본 문서의 ID입니다. → 예를 들어, 한 문서를 10개 조각으로 나눴다면 document_id는 같고 id는 각각 다릅니다.

2️⃣ text • 실제 원문 텍스트입니다. • 이 내용이 벡터로 변환(embedding) 되어, 의미 기반 검색을 가능하게 합니다.

3️⃣ embedding • embedding 은 문장을 수학적으로 표현한 숫자 벡터입니다. • 실제로는 보통 384, 768, 1536차원 등 훨씬 길어요. • 각 숫자는 문장의 의미적 특징을 압축 표현한 값이에요. • dimension 은 벡터의 차원 수를 명시합니다.

➡️ 예를 들어, “RAG는 AI 검색 구조다” 와 “LLM이 정보를 검색한다” 이 두 문장은 의미가 비슷하므로, embedding 공간에서 서로 가까운 위치에 저장됩니다.

4️⃣ metadata • metadata 는 검색된 결과를 더 풍부하게 활용하기 위한 부가 정보입니다. • source: 데이터의 출처 (예: notion, pdf, github 등) • title: 문서 제목 • language: 언어 코드 • tags: 주제 분류 • created_at: 데이터가 생성된 시점 • uri: 원문에 접근할 수 있는 링크

➡️ RAG 시스템은 검색된 벡터의 metadata를 이용해 “이 문장은 어디서 왔는지, 어떤 문서의 일부인지”를 함께 보여줄 수 있습니다.

BEDROCK

AWS Bedrock 서비스란? https://docs.aws.amazon.com/ko_kr/bedrock/latest/userguide/what-is-bedrock.html https://mozzi-devlog.tistory.com/73

아이디어 회의

1. *청각장애인을 대상으로 시각 기반 영어 발음 교정 서비스 *
   • 기존에는 입모양을 기준으로 판별 → 대충 느낌으로
   • 소리를 듣지 않아도 발음의 형태, 강세 등을 이해할 수 있도록 시각적 자료(그래프) 및 피드백 제공
   • 음성 분석, TTS, 발음 규칙 엔진, LLM 피드백 생성
   • 생성형 AI 기술 활용해 개인화된 발음 교정 학습 지원
   • 입술 모양 시각화 / blender / 모션캡쳐가 더 낫더라? / 안되면 빼버리는게 좋을듯

2. *IT 개발자를 위한 로드맵 생성기 *
   • 내가 직접 만든 로드 맵
   • 블로그, 깃허브 소스 크롤링
   • 학습 관련데이터 시각화
   • IT 트랜드 시각화

멘토님 피드백

1. 1번 아이디어(청각장애인을 위한 시각 기반 영어 발음 교정 서비스)
•    흥미롭고 사회적 가치가 높은 주제지만, 기술적 난이도가 높음
•    발음 분석 기법(음소 단위, 강세, 입모양, 리듬 등) 을 다양하게 연구해야 함
•    프로젝트 내에서 1~2명이 발음 분석 기법과 시각화 파트를 집중적으로 담당해야 효율적일 것으로 조언
•    단기간에 완성하기는 어려우므로 PoC(Proof of Concept, 개념 검증) 단계로 범위를 축소해 진행하는 것이 현실적
•    Blender나 모션캡처 등 입술 모양 시각화 기술은 선택적 요소로, 기술 구현이 어렵다면 과감히 제외해도 무방

2.    IT 개발자를 위한 로드맵 생성기
•    이미 비슷한 서비스들이 존재하지만, 기존 서비스의 단점을 보완하거나 시각화를 다양한 방면으로 발전시키는 방향으로 개선할 수 있음.
•    단순히 로드맵을 자동 생성하는 것보다는 다른 방향을 제시해보는 것이 좋을 것 같다.
•    예를 들어, GitHub와 블로그 데이터를 분석해 실제 개발자의 학습 경로를 반영하거나, 최신 기술 스택의 트렌드 시각화 대시보드를 제공하는 방향이 유용할 것이라고 조언하심.