1. 컨테이너 이미지를 만들 때 정말로 Dockerfile이 필요할까요?
•
docker init
◦
프로젝트 자동 분석 → Dockerfile을 작성해줌
▪
약간의 커스터마이징만 하면 됨
▪
기본적으로는 호스트 머신의 운영체제와 아키텍쳐를 따라감
•
—platform과 같은 옵션들을 덧붙여 빌드해주면 됨
◦
MSA에서는 아직 전부 인식 못 함
•
Dockerfile없이 컨테이너 이미지 빌드하기
◦
Java, .NET에서는 현재 가능
▪
자바 → Maven, Gradle 플러그인 이용하면, 이미지 빌드 가능
•
단점) RUN instruction 사용 불가 → 커스텀 베이스 이미지를 생성해서 사용하면 됨
▪
닷넷 → msbuild : dotnet publish
•
단점) RUN instruction 사용 불가 → 커스텀 베이스 이미지를 생성해서 사용하면 됨
•
컨테이너 오케스트레이션
◦
docker network
▪
네트워크 브릿지 생성 : network create + docker run시 네트워크 지정
◦
docker compose
▪
yaml → 정의만 하면, docker compose up 명령어 한 줄 만으로 오케스트레이션 가능
•
dotnet-aspire 오케스트레이션
◦
docker compose → 결국 하나의 코드 → 관리 이슈 → yaml 파일없이 그냥 오케스트레이션 안되나?
◦
관측용이성 + 회복탄력성 + 자동 서비스 디스커버리
▪
배포를 위한 절차를 알아서 해줌
▪
Java, Python, JS 앱 통합 가능
•
AppHost라는, 나머지 디렉터리들을 한 곳에서 참조 관리하는 폴더에서 모든 참조 내용들과 도커 옵션들을 소스코드 레벨에서 작성
◦
빌드 → 대시보드에서 모든 리소스들을 확인 가능
▪
데이터 흐름을 파악 가능
2. 내 AI에 커스텀 임플란트로 날개를 달아보자!
•
대 AI 시대
◦
랭체인 : AI 분야의 보편적으로 사용되는 프레임워크(예 : 리액트, 스프링, 익스프레스..) → RAG + Vector/GraphDB → AI 통합 도구들(예 : cursor, docker, notion…) → ModelContextProtocol
•
AI 에이전트
◦
MCP를 이해하기 위해, AI 에이전트를 알 필요 있음
▪
Monolithic Model ⇒ Compound AI System
1.
Monolithic Model
•
대용량으로 한 곳의 모델에 입힘 → 학습 내용으로 도출된 결과가 옳은지 알 방법 X
•
Query → 답변 생성(LLM) → 오답
2.
Compound AI System(RAG 시스템)
•
Modular System
•
Query → 검색 → HR DB → 답변 생성(LLM) → 정답
◦
디비에서 관련 내용을 조회해서 추론하거나 증강시켜 답변 가능
◦
밑줄 부분 : “Control Logic(제어 로직)”이라고 함
▪
제어 로직 구현 방법
1.
Program화(코드로 절차 정의)
2.
AI Agent(LLM에게 제어로직 마저 맡김)
a.
쿼리(input) → LLM이 먼저 받음 → 자기가 설정한 계획에 대해 수행(추론) → 실패시 재귀 → 만족시 답변 도출(output)
◦
핵심 요소
▪
Reasoning(추론) 기능 + Act(실행) 기능 + Access Memory 기능
•
MCP(Model Context Protocol)
◦
자신이 갖고 있지 않은 정보에 대해 Act 기능을 수행하여 외부 정보를 습득해야할 때, 필요한 표준
▪
등장 배경 : 너무 많은 AI 툴 → 프로토콜을 만들어 표준을 만들 필요가 있다!
◦
MCP 아키텍쳐(MCP Server 이식 패턴)
▪
HOST → MCP Client n개(클로드, IDE들…) 
MCP Protocol MCP Server n개 DataServer n개(로컬 또는 리모트[WebAPI])
MCP Protocol MCP Server n개 DataServer n개(로컬 또는 리모트[WebAPI])•
밑줄 과정을 사용자가 정의하면, 애플리케이션이 동적으로 확장