“그냥 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 직접 연동 vs AIP
| 항목 | 범용 API 직접 연동 | AIP |
|---|---|---|
| 권한 제어 | 매번 별도 구현 필요 | Foundry 기존 권한·마킹을 그대로 상속 |
| 감사 추적 | 별도 로직 구축 필요 | 감사 로그·Evals 내장 |
| 모델 교체 | 관련 코드 전체 수정 | 관리자 콘솔에서 모델 전환 |
| 초기 구축 속도 | 빠름 (하루 내 가능) | 상대적으로 느림 (플랫폼 학습 필요) |
| 온톨로지 연동 | 직접 구현 필요 | 이미 연결된 온톨로지를 그대로 참조 |
범용 API만으로 충분한 경우도 있다
모든 상황에서 AIP가 정답은 아닙니다. 다음과 같은 경우라면 범용 API 직접 연동이 더 합리적입니다.
- 민감하지 않은 데이터로 하는 일회성 프로토타입: 권한·감사가 중요하지 않은 내부 데모라면, 빠르게 붙여서 검증하는 쪽이 낫습니다.
- Foundry 바깥의 독립 서비스: 애초에 Foundry 온톨로지와 무관한 서비스라면 AIP를 쓸 이유가 없습니다.
- 일시적인 실험: 프로덕션으로 가져갈 계획이 없는 단기 실험이라면, AIP 학습 비용을 들일 필요가 없습니다.
반대로 권한이 걸린 사내 데이터를 다루거나, 장기적으로 운영하며 모델을 교체할 가능성이 있거나, 답변 근거를 나중에 감사해야 한다면 AIP 쪽이 누적 비용 면에서 유리합니다.
정리하면
범용 API를 붙이는 건 하루면 끝납니다. 하지만 그 뒤에 권한 관리, 감사 추적, 모델 교체라는 세 가지 숙제가 남습니다. AIP가 하는 일은 이 숙제를 온톨로지 기반 구조 안에서 미리 해결해두는 것입니다. “데이터 흐름과 권한, 감사 이력을 함께 가져온다”는 게 범용 API와의 결정적 차이입니다.
자주 묻는 질문
Q. AIP를 도입하려면 온톨로지가 반드시 먼저 있어야 하나요? 필수는 아니지만 강력히 권장됩니다. 온톨로지가 없는 상태에서 AIP를 붙이면 범용 API와 큰 차이가 없어집니다.
Q. 여러 LLM을 동시에 쓸 수 있나요? 네. 작업 성격에 따라 다른 모델을 배정하는 것도 가능합니다. 예를 들어 단순 요약은 가벼운 모델, 복잡한 추론은 더 강력한 모델로 나눠 쓸 수 있습니다.
범용 API냐 AIP냐, 정하기 전에 점검할 6가지
- 챗봇이 다루는 데이터에 접근권한 차이가 있는가? 있다면 사용자별 권한을 누가, 어떻게 매번 검증할지 정했는가
- 답이 틀렸을 때 근거를 추적할 로그와 감사 경로가 있는가
- 1년 안에 모델을 바꿀 가능성(비용, 성능, 정책 변화)에 대비해 연동 구조를 분리해 두었는가
- 대표 질문 30~50개로 만든 평가 세트가 있어 모델·프롬프트 변경 전후를 비교할 수 있는가
- 개인정보·민감정보가 외부 모델로 나가는 경로를 문서로 정리했는가
- 실험 단계와 운영 단계에서 요구되는 권한·감사 수준을 구분했는가
추가로 자주 나오는 질문
Q. 소규모 실험도 AIP로 해야 하나요? 권한·감사 요구가 낮은 일회성 실험이라면 범용 API로도 충분합니다. 다만 운영으로 넘어가는 순간 권한, 감사, 모델 교체가 한꺼번에 필요해지므로, 그때의 재작업 비용을 미리 견적해 두세요.
Q. AIP를 쓰면 환각이 사라지나요? 아닙니다. 권한 상속, 감사 추적, 평가 도구는 통제와 검증을 돕는 장치일 뿐 환각 자체를 제거하지는 않습니다. 근거 문서·온톨로지 연결과 평가 세트가 여전히 필요합니다.
Q. 모델을 바꾸면 프롬프트도 다시 손봐야 하나요? 모델마다 지시를 따르는 방식이 달라 같은 프롬프트가 같은 품질을 보장하지 않습니다. 교체 전에 평가 세트로 먼저 비교하세요.