6.5생애주기 단계 지원과 인계

단계를 나누는 목적은 일정을 그리기 위해서가 아니라 넘어가도 되는지 판정하기 위해서입니다. 종료 기준이 없으면 앞 단계의 미해결 항목이 뒤로 밀려 인계 시점에 한꺼번에 터집니다.

단계	이 단계에서 확정하는 것	종료 기준
디스커버리	성공 기준, 오류 비용, 범위	측정 가능한 기준 세 개와 제외 목록이 합의됨
설계	아키텍처, 모델·통합 방식, 관측 지표	결정 기록에 기각 사유와 재검토 조건이 있음
인계	운영 주체, 권한, 대응 절차	인계 팀이 평가셋을 스스로 돌려 점수를 냄
모니터링	지표 수집과 경보	나빠졌을 때 누가 무엇을 하는지 문서에 있음
반복	개선 우선순위와 변경 절차	변경이 회귀 평가를 거쳐 반영됨

인계 단계의 종료 기준을 눈여겨보십시오. 문서를 넘긴 것이 아니라 인계 팀이 스스로 점수를 낸 것이 기준입니다. 이 차이가 실무에서 크게 갈립니다. 문서 전달로 인계를 끝내면 문제가 생겼을 때 결국 원래 팀이 다시 불려 옵니다.

각 단계에서 다음 단계 사람을 미리 참여시키는 것도 중요합니다. 설계 단계에 운영팀이 없으면 관측할 수 없는 시스템이 만들어지고, 인계 단계에 처음 만나면 이미 늦습니다. 최소한 관측 지표를 정하는 자리에는 운영팀이 있어야 합니다.

인계는 문서 부족보다 권한과 능력의 공백에서 더 자주 실패합니다.

첫째, 평가를 돌릴 수 없습니다. 평가 스크립트가 원래 팀의 개발 환경에만 있거나, 평가에 필요한 데이터 접근 권한이 없는 경우입니다. 인계 팀은 변경할 때마다 원래 팀에 확인을 요청하게 되고, 그 부담 때문에 결국 아무것도 바꾸지 않게 됩니다. 아무도 손대지 않는 시스템은 조용히 낡습니다.

둘째, 프롬프트를 고칠 권한이 없습니다. 프롬프트가 코드 저장소에 있으면 배포 권한 문제로, 설정 저장소에 있으면 승인 절차 문제로 막히는 경우가 많습니다. 인계 시점에 "무엇을 누구 승인 없이 바꿀 수 있는가"를 명시적으로 정하지 않으면, 사소한 수정에도 며칠이 걸립니다.

셋째, 장애 시 판단 기준이 없습니다. 지표가 나빠졌을 때 롤백할지, 지켜볼지, 상위에 보고할지 정해져 있지 않으면 대응이 늦습니다. 다음 세 가지를 숫자로 정해 두십시오.

• 즉시 롤백: 안전 관련 지표가 통과선을 벗어남, 오류율이 기준의 몇 배를 넘음
• 관찰: 품질 지표가 통과선 근처에서 흔들림. 관찰 기간과 재평가 시점을 정함
• 보고: 비용이 예산의 몇 %를 넘음, 같은 유형 신고가 며칠 안에 몇 건 이상

인계 체크리스트로 정리하면 다음과 같습니다. 각 항목은 문서 존재 여부가 아니라 인계 팀이 실제로 해 보았는지로 판정합니다.

1. 인계 팀이 평가셋을 직접 돌려 현재 점수를 냈다
2. 인계 팀이 프롬프트를 한 줄 고쳐 배포까지 해 보았다
3. 인계 팀이 롤백을 한 번 실행해 보았다
4. 경보가 실제로 인계 팀에게 도달하는 것을 확인했다
5. 롤백·관찰·보고의 기준선이 숫자로 문서에 있다

운영 지표가 나빠졌을 때 어느 단계의 문제인지 구분하는 것이 아키텍트의 판단입니다. 같은 증상이라도 되돌아갈 지점이 다릅니다.

신호	함께 확인할 것	가리키는 단계
사람 수정률 상승, 지표·비용은 그대로	최근 입력 유형 분포	디스커버리 (범위·기준 재합의)
평가셋 점수 하락, 입력 분포는 그대로	모델 버전, 프롬프트 변경 이력	설계 (회귀 원인 추적)
특정 시간대에만 지연 급등	트래픽 패턴, 동시성 한도	설계 (용량·구성)
신고는 많은데 평가셋 점수는 정상	평가셋이 그 유형을 담고 있는지	반복 (평가셋 갱신)
비용만 상승	입력 길이 분포, 캐시 적중률	설계 (구성 최적화)

네 번째 줄이 특히 자주 놓치는 경우입니다. 신고와 지표가 어긋날 때는 평가셋을 먼저 의심해야 합니다. 지표가 정상인데 사용자가 불만이라면, 대개 평가셋이 현재 문제를 담고 있지 않습니다. 이때 시스템을 고치려 들면 엉뚱한 곳을 만지게 됩니다.

첫 번째 줄도 판단이 갈리는 지점입니다. 시스템이 그대로인데 수정률이 올랐다면 시스템이 나빠진 것이 아니라 들어오는 일이 달라진 것일 수 있습니다. 이 경우 필요한 것은 모델 교체가 아니라 범위와 기준의 재합의입니다. 새 유형을 지원 범위에 넣을지, 넣는다면 기준을 어떻게 조정할지가 논의 대상입니다.

되돌아가는 것을 실패로 취급하지 않는 문화가 중요합니다. 되돌아가는 경로를 문서에 미리 그려 두면, 되돌아가는 일이 예외적 사건이 아니라 정상적인 절차가 됩니다.

운영 단계에 들어간 뒤의 변경은 개발 단계와 다른 규율이 필요합니다. 핵심은 모든 변경이 회귀 평가를 거치는 것입니다.

변경 유형별로 필요한 절차를 나눠 두면 과도한 절차로 개선이 막히는 일을 피할 수 있습니다.

변경 유형	필요한 절차	근거
어조·문구 조정	평가셋 재측정만	품질 지표에 영향이 작다
프롬프트 구조 변경	재측정 + 실패 사례 확인	과거에 막던 실패가 되살아날 수 있다
모델 교체	재측정 + 회귀 평가 + 롤백 준비	전 항목이 균일하게 좋아지지 않는다
검색·인덱스 변경	재측정 + 재인덱싱 검증	되돌리는 비용이 크다

모델 교체는 특히 조심스럽게 다뤄야 합니다. 새 모델이 전체 점수를 올리면서도 특정 유형에서는 내려갈 수 있습니다. 그래서 전체 점수만 보지 말고 유형별 점수를 함께 비교해야 합니다. 유형별로 쪼갠 표에서 크게 내려간 칸이 있으면, 전체가 좋아졌더라도 그 유형에 대한 대응을 함께 준비해야 합니다.

개선 우선순위는 신고 건수가 아니라 건수 곱하기 건당 비용으로 정하십시오. 자주 일어나지만 사소한 문제보다, 드물지만 비용이 큰 문제가 먼저인 경우가 많습니다. 디스커버리에서 잡아 둔 오류 비용이 여기서 다시 쓰입니다.

마지막으로 평가셋 자체의 관리를 반복 주기에 넣으십시오. 시스템이 평가셋에 과하게 맞춰지면 점수는 오르는데 실제 품질은 그대로인 상태가 됩니다. 분기마다 최근 운영 사례로 일부를 교체하되, 이전 판본을 보관해 두 판본의 점수를 함께 보십시오. 두 판본의 격차가 벌어지면 평가셋에 과적합되고 있다는 신호입니다.