[6단계] 표준화된 도구 통합 및 외부 API 활용 설계

혼잡도

• LLM API는 OpenAI API를 채택함.

  • 이유 :
    1. [4단계]에서 채택한 gpt-5.6-luna가 OpenAI API로 제공되는 모델이며, 구조화 출력을 지원하고 GPU 서버 운영 없이 바로 호출할 수 있음.
    2. 신호 판정에 필요한 건 정형화된 JSON 출력 하나뿐이라 별도의 API 추상화 계층 없이 직접 호출로 충분함.

• 사전 분류기로 Jev API 도입을 검토 중이며 아직 도입하지 않음.

  • 장점 :

    1. 별도 학습 없이 글이 혼잡 관련인지 1차로 빠르게 걸러낼 수 있음.

  • 단점 :

    1. 호출마다 추가 비용이 발생함.
    2. 정확도를 아직 실측하지 않아 [4단계]에서 검토 중인 사전 분류기(TF-IDF + Linear SVM) 대비 우위를 확인하지 못함.

  • 결론 : 게이트웨이로 앞단에 추가했을 때 LLM 호출 수나 처리 시간이 유의미하게 줄어드는지부터 측정해야 함. 그 전까지는 전체 신호를 그대로 [4단계]의 LLM 분석 단계로 보냄.

• MCP는 연결하지 않음.

  • 이유 :

    1. MCP는 여러 외부 도구·리소스를 런타임에 동적으로 탐색해 호출하는 표준임. 기능 3은 스레드당 LLM 호출 1회로 끝나고 호출 대상도 OpenAI API 하나로 고정돼 있어 동적으로 도구를 골라야 할 상황이 없음.
    2. 필요한 외부 연동(OpenAI API)은 이미 고정된 코드로 직접 호출하고 있어, MCP가 제공하는 표준화·탐색 계층이 새로 풀어주는 문제가 없음.

  • 추후 검토 : 신호 판정 외에 다른 외부 도구를 동적으로 조합해야 하는 기능이 생기면 그때 다시 판단함.