“해결됐나요?”가 하루 종일 반복되는 팀에서, 지표는 회계다
오전 10시. 팀 채널에 질문이 올라온다. “해결됐나요?”
누군가는 PR 링크를 던진다. 다른 누군가는 CI 캡처를 붙인다. 또 다른 누군가는 “내 쪽에선 재현 안 돼요”라고 답한다.
점심 무렵엔 같은 질문이 다른 톤으로 돌아온다. “그럼 지금은 정상이에요?”
여기서부터 분위기가 바뀐다. ‘정상’의 정의가 사람마다 다르고, 증거가 흩어져 있어서 결론이 안 난다.
오후 3시. 매니저가 묻는다. “오늘 안에 닫히나요?”
대답이 길어진다. 누구도 “예/아니오”로 말하지 못한다. 대신 설명이 나온다. 설명은 보통 회의로 이어진다.
회의가 끝나면 또 질문이 남는다. “그럼 왜 이렇게 됐죠?”
그날은 결국 기능을 고친 게 아니라 설명을 했고, 설명을 하느라 하루가 갔다.
나는 이 장면을 ‘기술 문제’라고 부르지 않는다. 설명 비용이 폭발한 날이라고 부른다.
지표는 기술이 아니라 ‘설명 비용’이다
지표를 좋아하는 사람은 없다. 특히 개발자는 더 싫어한다. 숫자를 붙이면 일이 늘고, 감시처럼 느껴지고, 또 다른 문서가 생긴다.
그런데 지표를 안 붙이면 더 비싼 게 생긴다. 설명 비용이다.
- 같은 질문에 같은 답을 매번 새로 만들어야 하고
- 서로 다른 “정상”을 합의하느라 회의를 하고
- 책임 공방이 생기면, 코드는 멈추고 말만 남는다
그래서 지표는 기술팀의 자존심이 아니라 회계다. 줄이는 건 GPU 비용만이 아니다. 회의 시간, 재작업, 분쟁 같은 ‘눈에 안 보이는 비용’이다.
(이 관점은 “확률적 모델 + 결정적 워크플로우”를 이야기하는 엔터프라이즈 자동화/통제 논의에서도 자연스럽게 나온다. 결국 조직은 ‘설명 가능한 상태’에서만 움직인다. 참고자료)
2주차에 딱 4개만 본다(나머지는 다음 달)
지표를 많이 붙이면 다시 설명 비용이 늘어난다. 그래서 2주차에는 네 개만 본다. 이 네 개가 안 잡히면, 나머지 지표는 사실상 장식이다.
1) TTFT p95
TTFT(첫 토큰까지 시간) p95는 체감의 근육이다. 여기서 p95가 흔들리면, 사람은 “느려졌네”로 끝내지 않는다. “뭔가 잘못됐나?”로 넘어간다. 그때부터 질문이 쏟아진다.
AWS LMI 쪽에서 말하는 long-context/캐시 이슈는 결국 이 숫자로 드러난다. 반복 컨텍스트가 많아질수록 첫 토큰이 늦어지고, 분산이 커지기 쉽다. 그래서 p95가 기준선을 넘으면 바로 알림을 걸고, 프롬프트의 ‘반복 덩어리’를 먼저 줄인다(캐시든 링크든 파일 분리든). (참고자료)
시작값 예시: p95가 2.5초를 10분 이상 넘으면 알림. 첫 조치는 모델 교체가 아니라 “반복 컨텍스트 줄이기(파일 분리/링크/캐시)”로 고정.
2) 게이트 실패율
사람이 가장 빨리 지치는 건 “일이 안 끝나는 느낌”이다. 게이트 실패율은 그 느낌을 숫자로 만든다. 테스트가 자주 깨지거나, 평가 기준(룰/테스트/검증)을 못 넘는 변경이 쌓이면, PR은 늘고 결론은 안 난다.
RFT 얘기를 굳이 끌어오는 이유는 하나다. “예쁜 답변”이 아니라 “통과 조건”을 가르치는 게 핵심이라는 점. 게이트 실패율이 오르면, 모델을 탓하기 전에 통과 조건이 무엇인지(그리고 그 조건이 현실적인지)를 먼저 손본다. (참고자료)
시작값 예시: 게이트 실패율이 20%를 넘으면 “새 작업 시작 금지(큐 정리)” + 실패 유형 3개만 라벨링해서 규칙부터 손본다.
3) 근거 로그 누락률
여기서 ‘근거’는 철학이 아니라 메모다. 내가 이 결론을 왜 냈는지, 어디를 보고 그렇게 말했는지, 최소한 한 줄로 남기자는 얘기다.
누락률이 올라가면 “해결됐나요?”가 “왜 그렇게 말해요?”로 바뀐다. 그리고 그 질문은 보통 더 오래 간다. 그래서 나는 누락률에 알림을 건다. 누락률이 일정 수준을 넘으면, 결과물이 아니라 ‘설명 가능한 흔적’부터 요구한다.
근거 필드 예시: (근거: PR#123 / 문서ID:SPEC-45 / 링크 1개). 이 셋 중 하나라도 비면 ‘누락’으로 친다.
4) 비용 상한 초과 횟수
비용은 늦게 터진다. 하지만 한 번 터지면 대화가 바뀐다. “좋은 기능”이 “이걸 계속 돌려도 돼?”로 변한다.
그래서 비용은 총액보다 ‘상한 초과 횟수’를 본다. 상한을 넘긴 순간이 곧 운영 이벤트다. 넘기면 자동으로 모드를 내린다: 컨텍스트 상한을 50%로 줄이고, 고급 도구 호출을 막고, 재시도는 0으로 만든다(사람 호출). 자동이 없으면 다음날 회의로 돌아간다.
결론: “해결됐나요?”를 줄이는 유일한 방법
그 질문을 없애는 방법은 없다. 사람은 묻는다. 특히 바쁠수록 더 묻는다.
다만 그 질문이 하루를 잡아먹지 않게 만들 수는 있다.
질문이 왔을 때, 누군가 PR 링크를 던지고 끝나는 게 아니라 이렇게 말할 수 있으면 된다.
“TTFT p95는 기준선 아래로 내려왔고, 게이트는 다시 통과 중이에요. 근거 로그는 빠진 게 없고, 오늘 비용은 상한 안 넘었습니다. 지금은 ‘정상’이라고 말할 수 있어요.”
이 한 문장이 가능한 팀은, 기능이 아니라 운영 속도가 빨라진다.
참고자료
- AWS Machine Learning Blog — Large model inference container: capabilities & performance enhancements
- https://aws.amazon.com/blogs/machine-learning/large-model-inference-container-latest-capabilities-and-performance-enhancements/
- AWS Machine Learning Blog — Reinforcement fine-tuning for Amazon Nova: Teaching AI through feedback
- https://aws.amazon.com/blogs/machine-learning/reinforcement-fine-tuning-for-amazon-nova-teaching-ai-through-feedback/
- Computerworld — ServiceNow plans automation of L1 Service Desk roles
- https://www.computerworld.com/article/4138040/servicenow-plans-automation-of-l1-service-desk-roles-promises-more-ai-specialists-to-come-2.html
댓글
댓글 쓰기