“그냥 OpenAI API 붙이면 되지 않나요?”
이런 질문을 자주 받습니다. Foundry에 이미 데이터가 다 있는데, 왜 굳이 AIP라는 걸 또 배워야 하냐는 겁니다. 답은 API를 붙이는 것 자체는 쉽지만, 그다음에 따라오는 세 가지 문제 — 권한, 감사, 모델 교체 — 를 누가 책임지느냐에 있습니다.
AIP는 별도 챗봇이 아니다
AIP(AI Platform)는 Foundry와 Gotham에 내장된 생성형 AI 계층입니다. 새로운 챗봇 제품이 아니라, 이미 있는 파이프라인과 온톨로지 위에 다양한 LLM을 직접 연결하는 통합 환경입니다.
범용 API 직접 연동 vs AIP, 세 가지 장면으로 비교
장면 1. 권한이 있는 사람만 봐야 하는 데이터. 인사 데이터를 다루는 챗봇을 만든다고 해봅시다. 범용 API를 직접 붙이면, “이 사용자가 이 데이터를 볼 권한이 있는가”를 매번 별도로 구현해야 합니다. 깜빡하고 하나라도 빠뜨리면 권한 없는 사람이 민감 데이터를 보게 됩니다. AIP는 Foundry의 기존 접근권한, 마킹, 감사 로그를 그대로 물려받습니다. 별도로 구현할 필요가 없습니다.
장면 2. “이 답이 왜 나왔는지” 나중에 추적해야 할 때. 범용 API로 만든 챗봇에서 이상한 답이 나왔다면, 그 답이 어떤 근거로 나왔는지 추적하는 로직을 별도로 만들어둬야 합니다. 안 만들어뒀다면 추적이 불가능합니다. AIP는 감사 추적과 AIP Evals라는 품질 평가 도구가 내장되어 있어서, 이 부분을 따로 구축할 필요가 없습니다.
장면 3. 지금 쓰는 모델을 다른 모델로 바꿔야 할 때. 범용 API로 직접 연동했다면, 모델을 바꾸는 순간 관련 코드를 전부 수정해야 합니다. AIP는 OpenAI, Anthropic, Google, xAI, Meta 등 다중 LLM을 지원하도록 설계되어 있어서, 관리자 콘솔에서 모델을 전환하는 것만으로 교체가 끝납니다.
| 구분 | 범용 API 직접 연동 | AIP |
|---|---|---|
| 데이터 컨텍스트 | 프롬프트에 수동으로 입력 | 온톨로지 기반으로 구조화되어 자동 제공 |
| 권한 관리 | 별도로 구현 | 기존 ACL을 그대로 상속 |
| 감사·추적 | 별도로 구축 | 감사 추적 내장 |
| 모델 교체 | 코드 수정 필요 | 관리자 콘솔에서 전환 |
| 품질 검증 | 별도 파이프라인 구축 | Evals 자동 제공 |
AIP를 이루는 다섯 가지 설계 축
- 원활한 통합: 기존 파이프라인과 온톨로지를 그대로 활용, 데이터를 별도로 복제하지 않음
- 보안·거버넌스 상속: Foundry의 접근권한과 감사 로그를 물려받음
- 모델 관리: 여러 공급사의 LLM을 하나의 콘솔에서 관리
- 확장성: 분산 컴퓨팅 기반으로 대규모 워크로드 처리
- 투명성: 감사 추적과 AIP Evals로 출력 품질을 지속적으로 검증
AIP를 구성하는 애플리케이션들
| 이름 | 기능 |
|---|---|
| Assist | 데이터 탐색, 코드 작성, 문서 질의응답 |
| Logic | 자연어와 블록 인터페이스로 LLM 워크플로우 구성 |
| Chatbot Studio | 커스텀 챗봇 설계·배포 |
| Evals | 출력 품질 평가 및 회귀 방지 |
| Threads | 다단계 상호작용에서 맥락 유지 |
| MCP | 외부 AI 클라이언트와의 연결 |
보안 관련 특성
AIP는 특정 모델에 종속되지 않는 구조(model-agnostic)입니다. 고객 데이터를 저장하지 않고, 명시적으로 배제하지 않는 이상 모델 재학습에도 사용되지 않습니다. 제3자 모델 제공업체가 프롬프트 내용에 접근하지 못하도록 차단되어 있습니다.
흔한 실패 패턴 3가지
온톨로지 구축 없이 AIP부터 도입한다. AIP의 강점은 온톨로지 기반의 구조화된 데이터 접근에서 나옵니다. 온톨로지가 부실하면 AIP도 범용 API 수준으로 힘이 빠집니다.
모델을 한 번 고르고 그대로 고정한다. 모델 시장은 계속 변합니다. 관리자 콘솔에서 쉽게 바꿀 수 있다는 이점을 살리려면, 주기적으로 다른 모델과 성능을 비교해보는 게 좋습니다.
Evals 없이 배포한다. 품질 평가 도구 없이 배포하면, 모델이나 프롬프트를 바꿨을 때 품질이 나빠졌는지조차 알 수 없습니다.
정리하면
범용 API를 붙이는 건 하루면 끝납니다. 하지만 그 뒤에 권한 관리, 감사 추적, 모델 교체라는 세 가지 숙제가 남습니다. AIP가 하는 일은 이 숙제를 온톨로지 기반 구조 안에서 미리 해결해두는 것입니다. “데이터 흐름과 권한, 감사 이력을 함께 가져온다”는 게 범용 API와의 결정적 차이입니다.
자주 묻는 질문
Q. AIP를 도입하려면 온톨로지가 반드시 먼저 있어야 하나요? 필수는 아니지만 강력히 권장됩니다. 온톨로지가 없는 상태에서 AIP를 붙이면 범용 API와 큰 차이가 없어집니다.
Q. 여러 LLM을 동시에 쓸 수 있나요? 네. 작업 성격에 따라 다른 모델을 배정하는 것도 가능합니다. 예를 들어 단순 요약은 가벼운 모델, 복잡한 추론은 더 강력한 모델로 나눠 쓸 수 있습니다.