이번 주에 당신의 팀에 필요한 것은 더 나은 AI 모델이 아닙니다
새로운 AI 모델을 찾아 헤매는 것을 멈추십시오. 당신에게 정말 필요한 업그레이드는 워크플로우입니다.
대부분의 팀은 어떤 모델이 더 똑똑해 보이는지에 집중합니다. 새로운 모델을 벤치마킹하고 지능에 대해 논쟁합니다. 하지만 LLM으로 서비스를 구축하고 있다면, 진짜 고통이 무엇인지 알고 있을 것입니다. 문제는 나쁜 코드가 아닙니다. 문제는 잘못된 실행(execution)입니다.
당신은 다음과 같은 문제들을 목격합니다:
- 작업 중간에 멈춰버리는 에이전트 루프.
- 사람들을 혼란스럽게 만드는 승인 프롬프트.
- 재시도 중에 끊어지는 컨텍스트 체인.
- 자동화 프로세스가 상태(state)를 잃어버려 사람이 직접 뒷수습을 하는 상황.
지능은 높아지고 있지만, 운영 제어 능력은 뒤처지고 있습니다. 우리는 '오케스트레이션 비용(orchestration tax)'의 시대에 진입하고 있습니다. 이에 대비하지 않으면, 서비스 중단이나 소리 없는 실패(silent failures)로 그 대가를 치르게 될 것입니다.
AI의 출력물은 최종 제품인 경우가 거의 없습니다. 그것은 더 큰 시스템 내의 중간 단계일 뿐입니다. 당신은 반드시 다음 질문들에 답할 수 있어야 합니다:
- 타임아웃 발생 후 작업을 재개할 수 있는가?
- 모든 승인 내역을 감사(audit)할 수 있는가?
- 중복 작업 없이 단계를 다시 실행할 수 있는가?
- 작업 도중에 사람이 개입하여 제어권을 넘겨받을 수 있는가?
시니어 엔지니어들은 이미 수년 전 결제 시스템이나 백그라운드 작업에서 이러한 문제들을 해결했습니다. 우리는 멱등성 키(idempotency keys), 체크포인트(checkpoints), 트랜잭션 로그(transaction logs)를 사용했습니다. AI가 이러한 문제를 새로 만든 것이 아닙니다. 단지 그 문제들이 더 빠르게 발생하도록 만들었을 뿐입니다.
실행 계약(execution contract)을 정하기 전에 모델부터 고르지 마십시오. 그것은 브레이크 없는 자동차에 레이싱 엔진부터 다는 것과 같습니다.
다음 단계들을 통해 신뢰할 수 있는 워크플로우를 구축하십시오:
AI 작업을 작은 단계로 나누십시오 거대한 프롬프트 하나를 사용하지 마십시오. 컨텍스트 수집, 변경 사항 제안, 검증 실행, 승인 요청, 변경 사항 적용 등으로 세분화하십시오.
지속 가능한 저장소(durable storage)를 사용하십시오 데이터베이스를 사용하여 상태, 단계, 시도 횟수를 추적하십시오. 워커(worker)가 충돌하더라도 메모리가 아닌 상태(state)로부터 복구할 수 있어야 합니다.
멱등성(idempotency)을 강제하십시오 데이터를 변경하는 모든 작업에는 안정적인 키가 필요합니다. 단계가 두 번 실행되더라도 결과는 동일해야 합니다.
티어(tier)별로 권한을 관리하십시오 끊임없이 승인을 요청하는 것을 멈추십시오. 다음과 같이 티어를 나누십시오:
- Tier 0: 읽기 전용 작업 (자동 승인).
- Tier 1: 저위험 쓰기 작업 (일괄 승인).
- Tier 2: 고영향 작업 (사람의 체크포인트).
- 운영 지표를 추적하십시오 지연 시간(latency)과 비용만 보지 마십시오. 타임아웃 발생률, 재시도 성공률, 롤백 빈도를 추적하십시오.
최고의 AI 팀은 마법 같은 프롬프트를 자랑하지 않습니다. 그들은 지루하지만 지속 가능하고 관찰 가능한(observable) 파이프라인을 운영합니다. 그들의 경쟁력은 모델이 아닙니다. 그들의 경쟁력은 규율 있는 시스템 엔지니어링입니다.
Source: https://dev.to/chrisbuildsonline/your-team-doesnt-need-a-better-ai-model-this-week-29l4
Optional learning community: https://t.me/GyaanSetuAi