- 중요한 시스템이 제공업체 한 곳에 묶여 있으면, 그 업체가 가격을 올리거나 서비스를 종료하는 날 회사에는 선택지가 없습니다.
- 처음부터 여러 업체를 쓸 필요는 없습니다. 다만 때가 오면 옮길 수 있도록 시스템을 설계해 두어야 합니다.
- 실제로 옮길 수 있게 해 주는 것은 회사 자체 데이터로 만든 테스트 세트입니다. 새 업체도 전과 같은 수준으로 일한다는 것을 이 세트로 증명합니다.
1. AI의 종속(Lock-in)은 일반 소프트웨어와 다릅니다
예전에는 회계 프로그램을 바꾸려면 데이터를 옮기느라 고생했지만, 적어도 결과는 그대로였습니다. AI는 그렇지 않습니다. 업체를 바꾸면 답도 달라질 수 있습니다. 그래서 새 업체가 여전히 전과 같은 수준으로 일한다는 것을 증명할 방법이 있어야 합니다.
개발팀 참고 · 기술 세부 사항
AI Workflow는 모델의 동작, Prompt, Tool Calling, Embedding, Safety Filter, Output 가격과 얽혀 있습니다. 모델을 바꾸면 API가 비슷해도 결과가 달라질 수 있습니다. Evaluation이 없는 회사는 품질이 나아졌는지 망가졌는지 알 수 없어서, 다시 테스트하기가 두려워 기존 Vendor에 머무는 경우가 많습니다.
지식 데이터(Knowledge), 대화 기록, 에이전트 정의, 로그가 내보내기 어려운 형식으로 저장되거나, 팀이 도구 하나만 익혀 온 경우에도 종속이 생깁니다. 초기에는 속도를 위해 한 업체에 기대는 편이 맞을 수 있습니다. 다만 출구 계획(Exit Plan)까지 세워 두고 내린 결정이어야 합니다. 가격이 오르거나 서비스가 멈춘 뒤에야 한 업체에 묶여 있었다는 사실을 알게 되면 늦습니다.
2. 업무 유형별로 모델 포트폴리오 짜기
모든 업무에 가장 비싼 것을 쓸 필요는 없습니다. 답이 정해진 업무는 단순한 규칙으로 충분하고, 틀리면 피해가 큰 업무에만 가장 좋은 모델을 쓰고 사람이 검토하게 하면 됩니다.
개발팀 참고 · 기술 세부 사항
Classification, Extraction, 간단한 Draft에는 Small/Fast Model을, 복잡한 분석에는 Reasoning Model을, 이미지·음성·특정 Domain에는 Specialized Model을 씁니다. 데이터나 Latency 요건이 있으면 On-prem/Private 모델을 씁니다. 가장 비싼 모델을 Default로 정하지 마십시오.
| 작업 | 주요 기준 | 라우팅 |
|---|---|---|
| 분류 | 가격/지연 시간 | 소형 모델 + 규칙 기반 대체 경로 |
| 중요한 요약 | 원문 충실도/출처 표시 | 중형 모델 + 검증 |
| 복잡한 판단 | 품질/추론 능력 | 최상위 모델 + 사람 승인 |
| 민감정보 | 개인정보 보호/통제 | 승인된 비공개 경로 |
개발팀 참고 · 기술 세부 사항
Risk, Complexity, Language, Budget에 따라 Routing합니다. Policy 없이 Agent가 모델을 마음대로 고르게 두지 마십시오. Provider가 멈추거나 Rate Limit에 걸릴 때를 위한 Fallback을 두고, Outcome마다 어떤 모델을 썼는지 기록합니다.
3. 기술을 바꿀 수 있도록 계층 나누기
개발팀 참고 · 기능 목록
Business Workflow, Prompt/Instruction, Model Gateway, Knowledge, Tools, Observability를 분리합니다. 공통 Interface는 꼭 필요한 기능에만 씁니다. 특수 Feature를 전부 감추면 그 이점까지 잃을 수 있으니, Vendor-specific Feature는 Adapter 안에 가둬 두십시오.
개발팀 참고 · 기술 세부 사항
Source Document, Metadata, Evaluation, Business Rule은 모델 시스템 밖에 보관합니다. Export에는 Open Format을 쓰고, Prompt/Agent Config는 Version Control로 관리합니다. Credential은 Workflow에 박아 넣지 말고 Secret Manager에 둡니다.
개발팀 참고 · 기술 세부 사항
Authentication, Routing, Rate Limit, Logging, Redaction, Cost를 처리하는 Model Gateway를 만듭니다. Provider를 부분별로 바꾸는 데 도움이 되지만, Gateway가 새로운 Lock-in이 되지 않게 조심해야 합니다. 그러려면 Config를 Export할 수 있어야 하고 사내 API 표준이 있어야 합니다.
4. 평가(Evaluation)는 모델을 바꿔도 된다는 허가증입니다
개발팀 참고 · 기술 지표
표준 사례, 예외, 태국어, 위험 사례를 모두 담아 실제 사례로 Dataset을 만듭니다. Accuracy, Completeness, Citation, Policy, Latency, Cost 같은 Metric을 정합니다. 판단이 필요한 부분은 Human Review로, 규칙으로 확인할 수 있는 부분은 Automated Check로 검사합니다.
개발팀 참고 · 기술 세부 사항
바꾸기 전에 Candidate 모델을 Shadow로 돌려 Production과 비교합니다. 평균 점수 하나에 기대지 말고 Segment별로 결과를 나눠 봅니다. 적은 Traffic으로 Canary를 돌리고 Rollback할 Version을 남겨 둡니다. 모든 Change에는 왜 골랐는지 적은 Decision Record가 있어야 합니다.
5. 토큰 가격보다 성과당 비용으로 관리하기
개발팀 참고 · 기술 세부 사항
싼 모델이라도 Retry나 Review가 너무 많아 오히려 더 비쌀 수 있습니다. Model, Tool/API, Infrastructure, Human Review, Error, Downtime을 모두 합산해 Cost/Successful Outcome과 Cost per Business Unit을 계산합니다.
개발팀 참고 · 기술 세부 사항
Budget per Workflow, Cache, Batch, Prompt/Context Optimization을 활용합니다. Cost/Outcome이 Drift하면 Alert를 띄웁니다. 조금 아끼려고 중요한 업무의 품질을 낮추지 마십시오. Agentic Workflow는 거래 한 건에 모델을 여러 번 호출할 수 있으므로, 처리량이 10배가 되는 Scenario도 만들어 둡니다.
6. 갖춰야 할 계약 조건과 출구 계획
- 데이터, 프롬프트, 에이전트, 로그, 평가 자료를 내보낼 권리와 내보내는 형식
- 학습용 데이터 사용 정책, 보존 기간, 계약 종료 후 삭제
- 모델 지원 종료(Deprecation), 가격 변경, 동작 변경 시 사전 통지
- 하위 처리업체(Subprocessor), 데이터 리전, 보안, 사고 통지
- 전환 지원(Transition Assistance)과 해지 후 접근 가능 기간
- 중요한 워크플로에 맞춘 SLA와 서비스 크레딧
개발팀 참고 · 기술 세부 사항
Credential과 Billing은 회사 명의로 관리하고, 개발 Vendor가 전부 통제하는 계정을 거치지 않게 합니다. Model/Open-source의 License와 상업적 이용 제한을 확인합니다. Critical Workflow는 1년에 한 번 Exit Drill을 합니다.
7. 모델이나 제공업체가 멈췄을 때의 업무 연속성
개발팀 참고 · 기술 세부 사항
Criticality에 따라 Tier를 나눕니다. 중요도가 낮은 업무는 기다려도 됩니다. 고객 업무에는 Fallback Provider나 Manual Route가 있어야 합니다. 금융 업무는 Fail Closed로 처리해, 기준을 통과하지 못한 모델의 답을 내보내지 않습니다. 서비스가 복구될 때를 대비해 Queue와 Idempotency를 유지합니다.
개발팀 참고 · 기술 세부 사항
Failure Mode를 테스트합니다: Timeout, Partial Output, 잘못된 Tool Call, Price Spike, Region Outage. Dashboard는 Provider Issue와 Data/Workflow Issue를 구분해 보여 줘야 합니다. 서비스 수준이 떨어지면 고객에게 투명하게 알립니다.
8. 선택권을 확보하는 12개월 로드맵
- 1분기: 모델, 워크플로, 데이터, 계약 목록을 만들고 심각한 종속 지점 찾기
- 2분기: 지식과 규칙을 분리하고 중요한 워크플로의 평가 체계 만들기
- 3분기: 게이트웨이와 라우팅을 도입하고 예비 모델을 섀도 모드로 시험하기
- 4분기: 실제 데이터를 근거로 비용 최적화, 출구 훈련(Exit Drill), 공급업체 협상 진행하기
요약: 멀티 모델 전략(Multi-model Strategy)의 목적은 선택권을 지키는 데 있습니다. 여러 업체를 쓰는 것 자체가 목적이 되면 복잡해지기만 합니다. 사업 자산을 모델과 분리하고, 평가, 라우팅, 성과당 비용 관리, 출구 계획을 갖추십시오. 그러면 각 공급업체의 강점을 충분히 활용하면서도 기술이 바뀔 때 발이 묶이지 않습니다.
시스템 전체를 뜯어고치지 않고 AI 제공업체를 바꿀 수 있게 설계합니다
어떤 업무에 어떤 모델을 쓸지 고르려면 기술 지식과 함께, 그 업무가 잘못되면 무엇에 영향을 주는지 알아야 합니다. 뒤쪽 질문에는 현업 부서가 더 잘 답합니다. DNA Maker는 업무를 위험도와 품질, 비용, 속도 요구에 따라 분류하고, 분류마다 통과 기준을 정하도록 돕습니다. 기준이 분명하면 모델을 바꿀지 말지를 짐작이나 뉴스에 휩쓸려 정하지 않고 데이터로 정하게 됩니다.
협상력을 지켜 주는 중간 계층
기술적으로는 업무 시스템과 모델 제공업체 사이에 중간 계층을 두고, 프롬프트, 규칙, 데이터를 회사 쪽에 보관합니다. 회사의 실제 데이터로 여러 제공업체를 시험하는 표준 테스트 세트를 함께 두어 품질과 성과당 비용을 있는 그대로 비교하고, 주 서비스가 멈출 때의 대체 계획도 마련합니다. 필요하지 않은데 처음부터 여러 업체를 쓰라고 권하지는 않습니다. 다만 때가 오면 바꿀 수 있도록 설계해 두어야 합니다. 지금 중요한 시스템이 제공업체 한 곳에 묶여 있고 자체 테스트 세트도 없다면, 첫 번째 세트를 만드는 일을 저희가 기꺼이 돕겠습니다.
SOFTWARE ENGINEERING GLOSSARY
소프트웨어 엔지니어링 용어집
시스템을 유연하게, 기술을 바꿀 수 있게 설계하는 일과 관련된 용어입니다.
| 용어 | 의미 | 쉬운 예시 | 개발팀에 물어봐야 할 질문 |
|---|---|---|---|
| Abstraction Layer | 제공업체를 쉽게 바꿀 수 있도록 회사 시스템과 외부 서비스 사이에 두는 중간 계층 | 계층 하나만 고쳐서 모델 제공업체를 바꿉니다. | 제공업체를 바꾸면 시스템에서 몇 군데를 고쳐야 합니까? |
| Evaluation Set | 시스템 품질을 꾸준히 재는 데 쓰는, 정답이 붙은 예시 모음 | 팀이 합의한 답이 붙은 고객 질문 200개 | 이 테스트 세트는 우리 것입니까, 업체 것입니까? |
| Vendor Lock-in | 시스템이 한 업체에 지나치게 의존해서 제공업체를 바꾸기 어려운 상태 | 프롬프트와 데이터가 모두 업체 시스템 안에 있습니다. | 이 업체를 그만 쓰게 되면 무엇을 들고 나올 수 있습니까? |
| Fallback | 주 경로를 쓸 수 없을 때 서비스가 멈추지 않도록 마련한 예비 경로 | 주 서비스가 멈추면 시스템이 자동으로 예비 경로로 전환합니다. | 제공업체가 두 시간 동안 멈추면 사업에 어떤 피해가 생깁니까? |
| TCO | 첫 개발비에 더해 시스템을 쓰는 기간 내내 드는 비용을 모두 합한 총소유비용 | 월 서비스 요금, 유지보수비, 시스템 개선 비용을 모두 합한 금액 | 첫해 이후 유지 비용에는 무엇이 들어갑니까? |