이번 주에 당신의 팀에 필요한 것은 더 나은 AI 모델이 아닙니다
당신의 팀에 필요한 것은 새로운 AI 모델이 아닙니다. 더 나은 워크플로우입니다.
최신 모델을 찾아 헤매는 것을 멈추십시오. 실행(execution)을 설계하기 시작하십시오. 대부분의 팀은 동일한 문제에 직면합니다. 에이전트 루프가 작업 도중에 중단됩니다. 승인 프롬프트가 사람들을 혼란스럽게 합니다. 재시도 과정에서 컨텍스트 체인이 끊어집니다. 자동화가 상태(state)를 잃어버리는 바람에 사람이 실수를 바로잡는 데 수 시간을 허비합니다.
문제는 더 이상 지능이 아닙니다. 문제는 실행입니다.
우리는 '오케스트레이션 비용(orchestration tax)'의 시대에 진입하고 있습니다. 이에 대한 대비를 하지 않는다면, 시스템 중단이나 소리 없는 실패(silent failures)를 통해 그 대가를 치르게 될 것입니다. 엔지니어가 늦은 밤까지 봇을 돌보며 지켜봐야 한다면, 그것이 바로 그 대가를 치르는 것입니다.
AI의 출력물은 최종 제품인 경우가 드뭅니다. 그것은 더 큰 시스템 내의 중간 단계일 뿐입니다. AI는 티켓 분류(triage), PR 초안 작성, 테스트 생성 등을 돕습니다.
당신은 다음 질문에 답할 수 있어야 합니다:
- 타임아웃 발생 후 작업을 재개할 수 있는가?
- 누가 변경 사항을 승인했는지 감사(audit)할 수 있는가?
- 중복된 부작용(side effects)을 만들지 않고 작업을 재실행할 수 있는가?
- 처음부터 다시 시작하지 않고 작업 도중에 사람이 개입할 수 있는가?
시니어 엔지니어들은 이미 이 문제를 해결하는 방법을 알고 있습니다. 우리는 이미 수년 전에 결제 시스템과 백그라운드 작업에서 이러한 문제들을 해결했습니다. 우리는 멱등성 키(idempotency keys), 체크포인트, 트랜잭션 로그를 사용합니다. AI는 단지 이러한 실패가 더 빠르게 일어나도록 만들 뿐입니다.
모델의 품질은 방정식의 일부분일 뿐입니다. 망가진 워크플로우에 훌륭한 모델을 올리면 혼란만 초래합니다. 견고한 워크플로우에 괜찮은 모델을 올리면 가치가 창출됩니다.
막연한 느낌(vibes)을 쫓는 대신 실질적인 플레이북을 구축하십시오:
AI 작업을 명시적인 단계로 나누십시오.
collect_context,propose_change,run_checks와 같은 단계를 사용하십시오. 하나의 거대한 프롬프트가 전체 프로세스를 실행하게 두지 마십시오.내구성(durability)을 위해 데이터베이스를 사용하십시오. 워크플로우 상태와 이벤트 로그를 Postgres와 같은 데이터베이스에 저장하십시오. 워커가 충돌하더라도 메모리가 아닌 상태(state)로부터 복구할 수 있습니다.
멱등성(idempotency)을 강제하십시오. 데이터를 변경하는 모든 작업에는 안정적인 키가 필요합니다. 단계가 두 번 실행되더라도 결과는 동일해야 합니다.
계층별로 권한을 관리하십시오. 끊임없이 승인을 요청하지 마십시오. 읽기 전용 작업, 저위험 쓰기, 고영향 변경 사항에 대한 계층을 만드십시오.
운영 지표를 추적하십시오. 지연 시간(latency)과 비용만 추적하는 것을 멈추십시오. 재시도 성공률, 사람의 개입 지점, 롤백 빈도를 추적하십시오.
최고의 AI 팀은 자율 에이전트에 대해 자랑하지 않을 것입니다. 그들은 내구성이 있고 관찰 가능한(observable) 파이프라인을 구축할 것입니다. 그들의 강점은 마법 같은 프롬프트가 아니라, 절제된 시스템 엔지니어링이 될 것입니다.
모델은 매달 더 똑똑해집니다. 당신의 경쟁력은 문제가 발생했을 때 당황하지 않는 워크플로우를 구축하는 데서 나옵니다.
Source: https://dev.to/chrisbuildsonline/your-team-doesnt-need-a-better-ai-model-this-week-2og7
Optional learning community: https://t.me/GyaanSetuAi