MCP서버를 만들기전 시나리오를 수립해보자.

 

k6 Tool 사용 시나리오

  • 특정 API endpoint에 대해 지정된 부하(초당 요청 수, 가상 유저 수, 지속 시간)로 테스트 실행 및 결과 요약
  • 동일 endpoint에 대한 과거 테스트 결과 비교(성능 트렌드, 최대 TPS, 에러율 등)
  • 다양한 HTTP 메소드(GET, POST, PUT, DELETE)별 부하 테스트.
  • 인증이 필요한 API에 대해 토큰 발급 및 헤더 자동 세팅
  • Swagger/OpenAPI 문서를 파싱하여 자동으로 k6 스크립트 생성.
  • 여러 API endpoint를 조합한 시나리오 테스트(사용자 플로우 시뮬레이션).
  • 테스트 실패(에러율 급증, 응답 지연) 시 자동 알림/이슈 생성.

cli나 스크립트 사용

 

 

 

argocd Tool 사용 시나리오

 

  • 배포 실패시 자동으로 로그도 가져와주기. ( 해결 방안 추천도 해주면 좋을것 같음)
  • 배포 자동화
  • 현재 out-of-sync인 app 요청
  • 배포 히스토리 물어보기
  • 전체 pod진단
  • project생성
  • project리스트 검색
  • project기반 검색
  • app생성
  • app검색
/api/v1/applications (GET) 전체 애플리케이션 목록 및 상태 조회
/api/v1/applications/{appName} (GET) 특정 앱의 상세 정보 및 sync 상태 확인
/api/v1/applications?syncStatus=OutOfSync Out-of-sync 상태인 앱 목록 필터링
/api/v1/applications/{appName}/sync (POST) 특정 앱 강제 동기화 트리거
/api/v1/applications/{appName}/operation 앱에 대한 롤백, 중단 등 연산 실행
/api/v1/projects (GET) 프로젝트 단위로 앱 관리
/api/v1/session (POST) 인증 토큰 발급
 

 

 

챗봇에서 가능한 시나리오:

  • "my-app 어플리케이션 지금 sync상태 어때?" → /api/v1/applications/my-app 호출 후 status.sync.status 반환.
  • "지금 out-of-sync인 서비스들 쭉 알려줘" → /api/v1/applications?syncStatus=OutOfSync로 조회.
  • "my-app을 강제로 동기화해줘" → /api/v1/applications/my-app/sync POST.
  • "오늘 배포된 앱 목록 알려줘" → /api/v1/applications?createdAfter=YYYY-MM-DD 등(필터링 지원 시).
  • "특정 앱의 리소스 트리 보여줘" → /api/v1/applications/{appName}/resource-tree.
  • 특정 프로젝트 내 앱의 동기화 상태 집계 및 리포트.

Agentic AI라는게 정말로 가능한 것인가라는 생각이 든다. 

아직까지 챗봇형태로 할루시네이션이 어느정도 발생하여도 용인이 되는 서비스는 충분히 가능해 보인다. 마누스와 같은...

 

하지만 기업이 서비스를 연동하려면 많은 부분들이 필요해 보인다.

가전제품처럼 오작동이 있어서는 안되는 서비스에서는 re-check과정이 타이트하게 들어가야 하는데 LLM 자체가 생성형이기때문에 항상 우리가 생각하는 일관된 답변을 주지 않아서 re-plan과정이 들어갈수밖에 없다. 이럴수록 시간이 늘어나기 때문에 고객 경험 측면에서 좋지 않음. 근데 이 시간을 줄이기 위해서는 단계를 줄이거나 프롬프트를 엄청나게 잘 짜거나, json형식으로 잘 관리해서  LLM으로 검증하는게 아닌 코드기반으로 빠르게 검증을 해야한다.

 

또한 LLM 호출을 타이트하게 제어해야한다. 돈을 무한정 낼 수 없다.

 

멀티 에이전트간 흐름제어가 굉장히 어렵다. 프롬프트만으로는 불가능해 보이며 결국에는 검증코드들이 많이 들어가야 한다. 

 

에이전틱 ai는 결국에 사람처럼 생각하는 사고방식을 가져야한다. 사람이 과거를 기억하고, 할일의 우선순위를 정하고, 할일을 기억하는 등 이러한 과정을 시스템에 녹여내야 하는데,,,,굉장히 어렵다. 

 

또한 단일 워크플로우만 잘 처리하도록 에이전트를 개발하면 안된다. 아쉬운 점은 현재 대부분의 강의들이 이러한 형태뿐이다. 당연히 그럴수밖에 없는게..아직 국내에서 에이전틱 시스템을 해본사람도 극소수일 것이기에...

 

앞으로는 집중할 부분은 "사람처럼 생각하게하기" , "output검증", "보안이나 오작동을 최소화 하기위한 가드레일 기능" 이다.

TCP 핸드셰이크 주요 플래그

약어전체 명칭설명트러블슈팅 활용 예시
SYN Synchronize 연결 시작 시 시퀀스 번호 동기화 tcp.flags.syn==1로 초기 패킷 필터링
ACK Acknowledgment 데이터 수신 확인 tcp.analysis.ack_rtt로 지연 분석
FIN Finish 정상 연결 종료 요청 비정상 FIN 패킷은 연결 리셋 의심
RST Reset 긴급 연결 종료/재설정 tcp.flags.reset==1로 이상 종료 감지
PSH Push 수신 측에 즉시 데이터 전달 요청 스트리밍 서비스에서 빈번히 사용
URG Urgent 긴급 데이터 표시(현대 프로토콜에서 거의 사용 안 함) tcp.urgent_pointer 값 확인

플래그(약어)의미많이 보일 때 위험 징후 및 설명

RST Reset 연결이 비정상적으로 즉시 종료될 때 사용. 대량의 RST 패킷이 보이면 네트워크 장애, 방화벽 차단, 서비스 거부 공격(DDoS) 등 의심
ALL ALL TCP Flags 모든 플래그가 동시에 켜진 패킷(예: Xmas Flood). 정상적이지 않은 패킷으로, DDoS 공격이나 방화벽 우회 시도일 수 있음
ACK Acknowledgment 단독 ACK(특히 SYN/ACK 없이 ACK만 오는 경우)은 비정상적인 핸드셰이크 흐름, 방화벽/보안장비의 세션 차단, 도중 연결 끊김 등 문제 신호
FIN Finish 정상 연결 종료 플래그이나, FIN과 RST가 반복적으로 섞여 나오거나 비정상적으로 많이 보이면 연결 불안정, 세션 문제 가능성

 

와이어샤크에서 많이 보이면 위험한 패턴

  • RST 플래그 다수:
    • 서버 또는 클라이언트가 강제로 연결을 자주 끊는 경우, 서비스 장애, 방화벽 차단, 포트 스캔 등 공격 징후일 수 있음
  • ALL TCP Flags(0x3F):
    • 정상적인 상황에서는 거의 나타나지 않음. 대량 출현 시 DDoS(Xmas Flood) 공격, 방화벽/IPS 우회 시도 가능성
  • ACK만 반복:
    • SYN/ACK 없이 ACK만 계속 보이면 정상적인 3-way handshake가 이루어지지 않는 상태. 방화벽, NAT, 세션 테이블 문제, 비정상 트래픽 의심
  • FIN, RST 혼합 다수:
    • 정상 종료(FIN)와 강제 종료(RST)가 반복적으로 섞여 나오면, 세션 불안정, 네트워크 장비의 세션 관리 문제, 또는 애플리케이션 오류 가능성
  • Bad TCP, Out-of-Order, Retransmission:
    • 와이어샤크에서 빨간색으로 표시되는 Bad TCP, 재전송, 순서 뒤바뀜 패킷이 많으면 패킷 손실, 네트워크 혼잡, MTU 불일치 등 네트워크 품질 저하 신호

+ Recent posts