AI Wiki - 100-hours-a-week/6-nemo-wiki GitHub Wiki

목차

• 1. 모델 API 설계
• 2. 모델 추론 성능 최적화
  • MVP용 Gemini API
  • 텍스트 생성 로컬 모델
  • 임베딩 로컬 모델
• 3. 서비스 아키텍처 모듈화
  • V1 상세 보기 (MVP 기반 구조)
  • V2 상세 보기 (RAG + Guardrail 구조)
  • V3 상세 보기 (최적화 + 캐싱 구조)
• 4. LangChain 기반 멀티스텝 AI 구현 검토
• 5. RAG 적용 설계
• 6. MCP (모델 컨텍스트 프로토콜) 활용 설계
• 7. 서비스 인프라 확장성과 모니터링 설계
  • Version 1 (MVP)
  • Version 2
  • Version 3
• 8. 최종 통합 설계 및 회고
  • 최종 통합된 서비스 아키텍처 다이어그램 및 설명
  • 모델 선정 및 최적화
  • LangChain 기반 멀티스텝 구현
  • RAG 설계
  • MCP 설계 (미사용)
  • 회고
    • 회고 - lillian
    • 회고 - romi

---

1. 모델 API 설계

설계 과제:

팀의 서비스 요구사항에 맞는 머신러닝 모델 API를 설계하고 구현하라. 예를 들어 RESTful API를 이용하여 모델 예측 기능을 호출하기 위한 엔드포인트를 정의하고, 입력 데이터 형식과 출력 결과 구조를 명확히 문서화한다. 필요한 경우 오류 처리 방안(예: 잘못된 입력에 대한 대응)과 인증/권한 관리도 고려하라. API 설계 시 본 모델 API가 팀의 기존 서비스 아키텍처와 어떻게 연계되는지를 설명하여, 해당 API를 통해 서비스의 어떤 기능이 강화되거나 구현되는지 논리적으로 드러내라.

제출 항목:

1. 설계한 API의 엔드포인트 목록과 각 엔드포인트의 기능 설명 (예: /predict: 입력을 받아 모델 추론 결과 반환).
2. API의 입력(JSON 혹은 Proto 메시지 등)과 출력 형식에 대한 명세서 (스키마, 예시 포함).
3. 해당 API가 서비스 전체 구조에서 차지하는 역할과 연동 관계에 대한 설명 (다이어그램이 있다면 첨부).
4. API 호출 예시와 예시 응답 (테스트를 통해 확인한 결과).

---

2. 모델 추론 성능 최적화

설계 과제:

현재 사용 중인 AI 모델의 추론 성능을 분석하고, 서비스 요구사항에 부합하는 최적화 기법을 적용하라. 먼저, 모델 추론 단계의 프로파일링을 수행하여 주요 병목 요소(예: 모델 크기로 인한 CPU/GPU 부하, 불필요한 연산, I/O 지연 등)를 식별하라. 그런 다음, 문제에 적합한 최적화 방안을 선택하여 적용하라. 예시 방안으로는 모델 경량화(quantization, knowledge distillation), 배치 처리 및 캐싱을 통한 처리량 향상, 하드웨어 가속(CUDA/TensorRT 등) 활용, 사전 연산 결과 캐싱 등. 선택한 기법은 반드시 팀 서비스의 특성과 트래픽 패턴에 어울리는 것이어야 하며, 왜 해당 최적화가 자기 서비스에 효과적인지 서비스 맥락에서 설득력 있게 설명하라. 최적화 전후의 성능(추론 속도, 응답 시간, 자원 사용량 등)을 측정하여 개선 결과를 검증하고, 그 수치를 근거로 최적화의 효용성을 뒷받침하라.

제출 항목:

1. 기존 모델 추론의 성능 지표 (최적화 전 지연 시간, CPU/GPU 사용률, 메모리 사용량 등 측정 결과).
2. 식별된 성능 병목 요소와 그 원인에 대한 분석 내용.
3. 적용할 최적화 기법의 구체적 계획 (어떤 알고리즘이나 도구를 사용했는지).
4. 최적화 적용 후의 기대 성능 지표 (동일한 조건에서의 지연 시간 감소, 처리량 향상 등 개선된 수치).

---

3. 서비스 아키텍처 모듈화

설계 과제:

팀 서비스의 전체 시스템 구조를 검토하고, AI 모델 관련 기능을 별도의 모듈이나 서비스로 분리하는 리팩토링/설계를 수행하라. 예를 들어 현재 단일 애플리케이션에 모델 추론 코드가 섞여 있다면, 이를 모델 서빙 전용 모듈 혹은 독립된 마이크로서비스로 분리하는 것을 고려하라. 모듈 간 인터페이스(예: API 호출, 메시지 큐, 함수 호출 등)를 정의하여 데이터 입력, 모델 추론, 결과 후처리의 흐름이 명확히 분리되도록 설계한다. 이 때 팀의 서비스 도메인에 맞게 어떤 경계(boundary)로 모듈을 나눌지 결정해야 하며, 선정한 모듈화 방식이 서비스 구조에 적합한 이유를 설계 관점에서 명시하라. (예: "실시간 추론 부분을 마이크로서비스화하여 다른 기능 배포와 분리함으로써 안정성을 높였다"). 각 모듈은 독립적으로 개발/배포/스케일링이 가능해야 하므로, 이에 대한 고려사항(예: 데이터 교환 방식, 호환성)도 함께 정리한다.

제출 항목:

1. 모듈화 적용 후 새롭게 설계된 서비스 아키텍처 다이어그램 (모델 모듈/서비스와 다른 구성 요소를 명확히 표시).
2. 각 모듈의 책임(domain)과 기능에 대한 설명 (어떤 기능을 담당하며 왜 해당 모듈로 분리했는지).
3. 모듈 간 인터페이스 설계 내용 (API 명세, 데이터 포맷, 통신 방식 등).
4. 모듈화로 기대되는 효과와 장점에 대한 정리 (팀 서비스의 개발 및 운영 측면에서의 이점).
5. 모듈화된 설계가 팀의 서비스 시나리오에 부합함을 설명하는 근거 (예: 변경 요구사항 발생 시 영향 범위가 줄어드는 모습 등 구체 사례).

---

4. LangChain 기반 멀티스텝 AI 구현 검토

Why:

복잡한 AI 응용에서는 하나의 모델 호출만으로 끝나지 않고, 여러 단계의 추론 또는 외부 도구와의 연계가 필요할 수 있다. LangChain과 같은 프레임워크는 LLM(거대 언어 모델)의 응답을 체인으로 연결하거나, 중간에 도구(API, 검색 등)를 활용할 수 있게 해준다. 이를 통해 모델이 단순 질의응답을 넘어, 맥락에 따라 **연속적인 추론 또는 행위(Agent)**를 수행하는 시스템을 구축할 수 있다. 예를 들어 사용자의 질문에 대해 먼저 내부 지식을 검색하고, 그 결과를 토대로 모델이 답변하게 하는 식의 다단계 처리가 가능하다. 하지만 이러한 복잡성이 모든 서비스에 필요한 것은 아니며, 불필요하게 도입하면 과설계(over-engineering)가 될 수 있다. 따라서 자신의 서비스에 이러한 LangChain 스타일의 멀티스텝 접근이 유의미한지 판단하고, 가치가 있다면 설계에 포함하는 것이 중요하다.

설계 과제:

팀의 서비스 맥락에서 에이전트 혹은 체인(chain) 방식의 AI 구성이 필요한지 검토하라. 만약 사용자 요청을 처리하는 데 여러 단계의 추론이나 외부 정보 조회가 필요하다면, LangChain과 같은 프레임워크를 활용하여 그 흐름을 설계하고 구현한다. 예를 들어, "질문 -> 데이터베이스 조회 -> 답 생성"과 같은 흐름이 있다면 이를 체인으로 구조화한다. LangChain을 사용할 경우 어떤 체인(Sequence chain, Retrieval chain 등)을 구축할지 결정하고, 각 단계에서 어떤 프롬프트나 도구를 사용할지 설정한다. 한편, 팀 서비스가 이러한 다단계 프로세스를 요구하지 않고 단일 모델 호출로 충분하다면, 현재 구조를 유지하되 왜 추가 체인이 불필요한지를 논리적으로 설명하라. 어떤 선택을 하든, 그 결정이 서비스의 요구사항에 부합함을 명확히 밝혀야 한다. (즉, 채택한다면 서비스에 어떤 향상이 있는지, 채택하지 않는다면 현 접근으로 충분한 이유를 제시.)

제출 항목:

• LangChain이나 유사 프레임워크를 활용하여 설계한 AI 추론 흐름도 (체인의 각 단계와 작동 방식 설명).
• 체인 내에서 사용된 도구나 외부 리소스(예: 위키백과 검색, 계산기 API 등)가 있다면 무엇을 어떻게 활용했는지 명시.
• 실제 구현한 코드의 일부 (프롬프트 구성 또는 LangChain 체인 정의 부분 등) 또는 의사코드.
• 서비스를 위해 멀티스텝 체인을 도입한 경우, 그에 따른 장점 (예: 답변 정확도 향상, 복잡한 작업 자동화 등)과 서비스 기능과의 연관성에 대한 설명.
• 체인을 도입하지 않기로 한 경우, 현재 단일 단계 모델 호출로도 서비스 요구를 충족할 수 있는 근거와, 향후 필요 시 어떻게 확장할 수 있을지에 대한 언급.

---

5. RAG 적용 설계

Why: **Retrieval Augmented Generation (RAG)**은 대형 언어 모델의 한계를 보완하기 위해 외부 지식 저장소에서 관련 정보를 검색한 후, 이를 활용해 응답을 생성하는 기법이다. 모델이 최신 정보나 방대한 도메인 지식을 필요로 하는 서비스라면, RAG를 통해 모델이 미리 학습하지 않은 내용도 활용하여 더 정확하고 풍부한 답변을 제공할 수 있다. 예를 들어 제품 추천 서비스라면 최신 재고 정보나 사용자 프로필 데이터를 검색해와서 모델 응답에 반영할 수 있다. 반면 서비스 요청이 모델 내부 지식만으로 충분히 처리된다면, 복잡한 RAG 구조는 불필요할 수 있다. 중요한 것은 팀 서비스의 데이터 특성과 요구에 따라 RAG의 도입이 성능이나 정확도 향상에 기여하는지 판단하는 것이다.

설계 과제: 팀의 서비스에서 외부 데이터 또는 지식베이스 활용이 필요한지 평가하고, 필요하다면 RAG 아키텍처를 설계하라. 우선 서비스 도메인에서 자주 묻는 질문이나 기능을 살펴보고, 모델 단독 응답으로 부족한 부분이 있는지 분석한다. 만약 최신 정보나 전문 지식이 요구되어 모델이 그 내용을 알지 못한다면, 관련 데이터를 검색/조회할 수 있는 솔루션을 통합한다. 예를 들어 사내 DB, 위키, 또는 벡터 데이터베이스로 구축된 문서 임베딩 검색 등을 활용하여 사용자 질의에 맞는 정보를 가져온다. 그런 다음 모델 입력(prompt)에 이 검색 결과를 포함시켜 응답을 생성하도록 모델 호출 방식을 개선한다. 설계 시, 어떤 데이터소스를 어떻게 구축/활용할지, 추출된 정보가 얼마나 신뢰할 만한지 검증 방안까지 고려한다. 한편, RAG가 특별히 필요하지 않은 서비스라면 그 이유를 설명하고, 현재 모델만으로 서비스 요구사항을 충족하는 방법이나 데이터 최신화 전략(필요시 주기적 모델 재학습 등)을 제시한다. 모든 경우에, 선택한 접근이 팀 서비스의 데이터 및 기능 요구사항에 적합함을 분명히 하라.

제출 항목:

• RAG를 적용할 경우 전체 데이터 흐름도 (사용자 질의 -> 검색 -> 결과 -> 모델 응답)의 설계도.
• 사용하려는 외부 지식 소스에 대한 설명 (예: 문서 데이터베이스, 벡터 DB, API 등)과 해당 소스를 선택한 이유.
• 검색을 위한 구현 내용 (예: 임베딩 생성과 인덱싱 방식, 검색 쿼리 예시) 및 모델과의 통합 방법 (프롬프트 예시 등).
• RAG 적용 전후의 예상 효과 (예: 특정 질문에 대한 답변 정확도 향상 사례) 및 검증 계획.
• RAG를 적용하지 않는 것으로 결정한 경우, 모델 단독으로 서비스 요구를 충족할 수 있는 근거와 추가적인 데이터 최신성 확보 방안(필요 시 모델 업데이트 전략)을 기술.
• 선택한 방안이 서비스의 목표(정확도 향상, 최신 정보 반영 등)에 어떻게 부합하는지에 대한 설명.

---

6. MCP (모델 컨텍스트 프로토콜) 활용 설계

Why: Anthropic에서 제안한 **모델 컨텍스트 프로토콜(MCP)**은 LLM이 외부 도구나 데이터 소스와 상호작용할 때 표준화된 방식으로 맥락(Context)을 주고받을 수 있도록 하는 프로토콜이다. MCP를 활용하면 다양한 툴 통합이 용이해지고, 에이전트형 AI 시스템을 구축할 때 호환성과 재사용성이 높아진다. 예를 들어 MCP 호환 서버가 제공하는 데이터베이스 질의 도구나 이메일 발송 도구 등을 LLM이 표준화된 방법으로 호출할 수 있다. 팀 서비스에서 여러 외부 API나 도구를 모델과 연결하려는 경우, MCP를 도입하면 개별 통합을 일일이 구현하는 부담을 줄이고 미래의 확장성도 확보할 수 있다. 그러나 서비스가 단순 Q&A 정도로 외부 연계가 적다면 MCP 도입 이점이 크지 않을 수도 있다. 궁극적으로 서비스가 필요로 하는 도구 통합 요구에 MCP가 부합하는지 검토하여 판단해야 한다.

설계 과제: 팀의 AI 모델이 외부 시스템이나 도구와 상호작용하는 시나리오가 있는지 파악하고, 그러한 경우 MCP 표준을 적용하는 설계를 모색하라. 만약 사용자의 요청을 처리하는 데 외부 데이터 조회, 시스템 명령 실행, 타 서비스와의 연계 등이 필요하다면, MCP 아키텍처를 통해 이를 구현한다. 예를 들어 일정 관리 서비스라면 LLM이 사용자의 요청에 따라 캘린더 API를 호출해 일정을 조회/등록할 수 있을 것이다. 이 경우 MCP 서버로 캘린더 API를 연동하고, LLM 측은 MCP 프로토콜을 통해 해당 기능을 호출하도록 설계한다. MCP 적용 설계에서는 **클라이언트(LM 애플리케이션)**와 서버(툴 제공자) 간의 상호작용 흐름, 컨텍스트 교환 방식, 및 보안/권한 고려사항을 명시해야 한다. 한편 외부 연계 수요가 없거나 자체 방법으로 충분히 처리 가능하다면, MCP를 도입하지 않을 수도 있다. 이 경우에도 왜 기존 방식으로 충분한지 또는 미래에 요구 증가 시 어떻게 대응할지 계획을 제시한다. 어떤 선택을 하든, 해당 결정이 팀 서비스의 현재 및 예상되는 요구사항에 적절함을 논증해야 한다.

제출 항목:

• MCP를 도입한 설계도의 예 (LLM 애플리케이션 ↔ MCP 서버 ↔ 외부 도구들의 상호작용 다이어그램).
• MCP를 통해 연동한 외부 도구/서비스 목록과 각 연동 목적 (예: 데이터베이스 조회, 파일 시스템 접근 등).
• MCP 프로토콜 상에서 주고받는 컨텍스트 또는 메시지 포맷에 대한 설명 (예: 예제 요청/응답 포맷).
• MCP 적용 후 기대되는 이점 (예: 통합 표준화로 인한 개발 단순화, 새로운 툴 추가 시 용이함)과 실제 적용상의 어려움 또는 극복 방안.
• MCP를 적용하지 않은 경우, 현행 아키텍처에서 외부 연계 요구를 처리하는 방법과 그 한계, MCP 없이도 되는 이유에 대한 분석.
• MCP 관련 선택이 팀 서비스의 장기적 확장성이나 기능 구현에 미치는 영향에 대한 고찰.

---

7. 서비스 인프라 확장성과 모니터링 설계

Why: 개발 환경에서 성공적으로 동작한 모델 기반 서비스라도, 실제 사용자 트래픽을 처리하려면 확장성과 안정성을 갖춘 인프라 설계가 필요하다. 확장성은 서비스가 증가하는 요청 부하를 감당할 수 있게 하는 능력으로, 이를 위해 컨테이너화, 오토스케일링, 부하 분산(load balancing) 등의 기술을 활용한다. 또한 시스템 안정성을 위해 장애 발생 시 복구 전략과 성능 모니터링 체계를 마련해야 한다. 만약 이러한 인프라 고려 없이 서비스를 운영하면, 소수의 동시 요청에도 응답 지연이나 오류가 발생할 수 있고, 문제 발생 시 원인을 파악하지 못해 장기적인 서비스 운영에 차질을 빚게 된다. 따라서 서비스 운영 단계에서는 배포 환경에서의 구조적인 확장성 확보와 모니터링을 통한 실시간 가시성 확보가 필수적이다.

설계 과제: 팀의 모델 서빙 컴포넌트를 운영 환경에 배포한다는 가정 하에, 높은 트래픽을 처리할 수 있는 인프라 구조와 모니터링 계획을 설계하라. 먼저, 현재 모델 서빙 모듈/서비스를 컨테이너(Docker 등)로 묶거나 패키징하여 일관된 배포 단위로 만든다. 그런 다음, **수평적 스케일링(horizontal scaling)**을 고려하여 동일한 모델 서비스 인스턴스를 여러 개 띄우고, 로드밸런서나 API 게이트웨이를 통해 트래픽을 분산시키는 아키텍처를 구상한다. 클라우드 서비스의 오토스케일링 기능이나 쿠버네티스(Kubernetes)를 활용하는 것도 고려한다. 아울러, 모니터링 및 로깅 부분에서는 주요 지표(모델 응답 시간, 오류율, CPU/GPU 사용률 등)를 수집하고 대시보드나 알림으로 확인할 수 있는 체계를 제안한다. 이에는 Prometheus/Grafana 같은 모니터링 스택 활용이나 간단한 로그 수집 및 분석도 포함될 수 있다. 설계 시 팀 서비스의 예상 트래픽 규모와 특성을 반영하여, 왜 해당 수준의 인프라와 모니터링이 필요한지 설명하라. 예를 들어, 실시간 서비스라서 99퍼센타일 응답속도를 모니터링해야 한다든지, 일별 사용자 수에 따라 몇 대의 서버가 필요하다든지 하는 구체적인 고려를 제시한다.

제출 항목:

• 확장성을 고려한 배포 아키텍처 다이어그램 (예: 여러 모델 서비스 인스턴스와 로드밸런서 구성, 오토스케일링 정책 등).
• 사용한 인프라 기술 및 서비스 명세 (Docker, Kubernetes, AWS/GCP 등 클라우드 자원, 혹은 On-premise 환경 설정 등 구체적으로).
• 모니터링 대상 지표 목록과 수집/시각화 방법 (예: 응답 시간, Throughput, 에러 로그 등과 Grafana 대시보드 구성안).
• 간이 부하 테스트 또는 시뮬레이션 결과 (가능하다면)와 그에 따른 시스템 자원 사용량/응답시간 변화 분석.
• 제안한 인프라/모니터링 설계가 팀 서비스의 향후 성장과 안정적 운영에 어떻게 기여하는지에 대한 설명 (예: "사용자 100배 증가 시에도 대응 가능하도록 OOO를 구성하여 서비스 중단 없이 확장 가능").

---

8. 최종 통합 설계 및 회고

Why: 이제까지의 단계를 통해 개별적으로 추진한 설계와 개선 사항들을 서비스 전체의 통합된 아키텍처로 종합할 필요가 있다. 각각의 단계는 특정 영역의 향상이지만, 최종적으로는 모든 요소가 잘 맞물려 하나의 완성도 높은 시스템을 이뤄야 한다. 또한 각 단계에서 내린 설계상의 결정들이 상호 작용하면서 새로운 고려사항이 생길 수도 있으므로, 이를 조정하고 정리하는 과정이 중요하다. 아울러, 프로젝트 전체를 돌아보며 배운 점이나 한계점을 정리하면 향후 개선 방향을 설정하는 데 도움이 된다. 이 최종 회고 단계에서는 팀의 서비스에 적용된 AI 모델 서빙 아키텍처를 한눈에 볼 수 있도록 정리하고, 설계 의도 대비 실제 결과를 평가하여, 강사나 이해관계자가 보았을 때도 납득할 수 있는 완성도를 갖추었는지 확인한다.

설계 과제: 이전 단계에서 구현한 모든 설계 요소를 통합하여 최종 서비스 아키텍처와 결과물을 정리하라. 팀의 위키에 전체 시스템 구조를 다시 한 번 최신 상태로 다이어그램화하고, 각 구성요소(API, 모델 모듈, 체인/RAG/MCP 적용 부분, 인프라 등)가 어떻게 상호 연동되는지 설명한다. 이 때 각 구성요소를 도입한 이유와 그로 인한 효과를 간결히 정리하여, 단계별 설계의 타당성을 다시 한 번 강조한다 (예: "모델 모듈화로 인해 다른 기능 수정 시 영향을 받지 않고, 독립 배포가 가능해졌다"). 또한 프로젝트 수행 과정에서 얻은 인사이트를 토대로, 현재 아키텍처의 강점과 약점, 추가로 보완해야 할 여지 등을 분석하라. 가능하다면 정량적인 결과(예: 전체 시스템 처리량, 최종 사용자 만족도 향상 등)를 제시하여 성과를 평가한다. 마지막으로, 향후 단계에서 고려할 사항이나 발전시킬 아이디어(예: 모델 추가 개선, 신규 기능 통합 등)를 제안하라. 이를 통해 설계 과제가 실제 서비스 발전으로 이어질 수 있음을 보여주어야 한다.

제출 항목:

• 최종 통합된 서비스 아키텍처 다이어그램 및 설명 (이전에 제안된 설계 요소들이 모두 반영된 그림과 각 요소 설명).
• 단계별 설계 적용 결과 요약표 (각 단계의 주요 변경사항과 그에 따른 성능/품질 향상 요약).
• 현재 완성된 시스템의 성능/품질에 대한 평가 (가능한 경우 정량적 데이터 포함).
• 프로젝트 수행에 대한 회고 및 평가: 무엇을 배웠고 어떤 어려움이 있었는지, 이를 어떻게 해결했거나 해결하지 못했는지.
• 앞으로의 개선 제안 및 계획: 추가 구현하고 싶은 기능이나 필요할 수 있는 최적화, 또는 다음 연구/개발 방향에 대한 제언.
• 전반적인 결론으로서, 현 시점에서 팀의 AI 모델 서빙 아키텍처가 왜 타당하고 적절한지에 대한 종합적인 의견 (전체 설계를 다시 한 번 옹호하는 내용).