AI 도입의 진짜 비용은 ‘판단’이다: 판단을 공정으로 만드는 팀의 방법
회의가 길어지는 날에는 공통점이 있다.
코드가 어려워서가 아니다.
“이게 맞냐”가 안 끝나서다.
누군가는 “대충 괜찮지 않아요?”라고 하고, 누군가는 “이건 위험한 느낌인데요”라고 한다.
그 사이에서 PM은 결정을 미루고, 엔지니어는 추가 로그를 붙이고, 디자이너는 시안을 더 만든다.
그리고 이상하게도, AI를 붙인 뒤에 이 회의는 더 길어지기도 한다.
모델이 일을 빨리 하면 할수록, 사람이 확인해야 할 후보가 늘어나기 때문이다.
그래서 나는 요즘 AI 도입 비용을 이렇게 적는다.
진짜 비용은 모델 호출 비용이 아니라 ‘판단하는 시간’이다.
이 시간을 줄이는 방법은 모델을 바꾸는 게 아니라, 판단을 공정으로 만드는 것이다. “누가 감으로 결정했는지”가 아니라 “어떤 절차로 판단이 재현되는지”를 제품처럼 만드는 일.
라벨을 만드는 순간, 모델은 도구가 된다
검색/랭킹에서 AI를 쓴다는 말을 들으면, 많은 팀이 “모델이 순위를 정해준다”를 상상한다.
하지만 현실에서 더 중요한 건 순위가 아니라 라벨이다. 어떤 쿼리에 어떤 결과가 더 관련 있는지, 팀이 합의할 수 있는 판단의 단위.
Apple이 앱스토어 랭킹에서 LLM이 만든 relevance judgment로 라벨 부족을 메우고, 랭커 개선을 A/B 테스트로 변화가 있는지 확인했다는 사례가 내게 준 힌트도 그거였다. (참고자료)
여기서 모델은 ‘판단자’가 아니라 ‘라벨을 만드는 공장’처럼 쓴다. 그리고 공장이 찍어낸 라벨은 실험으로 다시 검증된다.
내 경험상 “모델부터” 얘기하면 회의가 길어진다. 판단 단위부터 잡아야 한다.
이 과정을 밟으면, AI 도입이 “기능 추가”가 아니라 “결정의 속도를 올리는 공정 개선”이 된다.
샘플을 만드는 순간, 디자인은 탐색이 된다
생성형 AI를 디자인에 붙이면 흔히 생기는 착각이 있다. “이제 시안은 무한히 만들 수 있겠네.”
무한히 만드는 건 쉽다. 문제는 그 다음이다. 무엇을 고를지.
Apple의 Celestial 연구가 UI 컴포넌트 인스턴스를 ‘구분되는 변형’으로 만들어 탐색을 구조화하려는 시도는, 결국 이 선택 문제를 정면으로 다룬다. (참고자료)
내 결론은 이거다. 회의가 길어지면 선택이 망가진다.
생성은 “더 많이”가 아니라 “더 빨리 고르게” 만드는 쪽이어야 한다.
샘플이 늘어날수록 판단 비용은 폭증한다. 그래서 샘플링에는 원칙이 필요하다.
- 무엇이 ‘구분되는 차이’인지
- 어떤 변형은 허용되고 어떤 변형은 금지인지
- 무엇을 바꾸면 사용자 경험이 흔들리는지
이걸 정리하지 않으면, 팀은 결국 “감이 좋은 사람”에게 의존하게 된다. AI 도입이 오히려 의존성을 키운다.
민감한 순간의 판단은 ‘제품’이다
제일 불편한 건 이 장면이다. 민감한 대화, 위험 신호, 도움 요청.
이때 판단은 취향이 아니다. 제품의 책임이다.
OpenAI가 정신건강 관련 작업 업데이트에서 신뢰할 수 있는 연락처(trusted contact) 같은 안전 기능과, 긴 대화에서의 평가 방법을 이야기하는 건 “모델이 잘 답한다”보다 “판단이 안전하게 작동한다”에 투자하는 방향으로 읽혔다. (참고자료)
민감한 순간에는 판단을 ‘자동화’할수록 더 큰 설계가 필요해진다.
- 무엇을 위험 신호로 볼지
- 위험일 때 어떤 톤으로 어디까지 말할지
- 사용자를 어떤 경로로 연결할지
여기서 판단 공정이 없으면 팀은 선택지가 두 개밖에 남지 않는다.
“아무 것도 안 하자” 또는 “너무 과하게 막자.”
둘 다 사고로 이어진다.
회의에서 내가 먼저 던지는 질문들
나는 이걸 체크리스트로 만들면 바로 문서가 되어버려서, 회의에서 쓰는 말로 적어둔다.
- “이걸 맞다고 부르려면, 어떤 라벨이 있어야 하죠?”
- “라벨은 누가 만들죠—사람이 만들고 AI가 확장하나요, 아니면 AI가 만들고 사람이 샘플링 검토하나요?”
- “샘플이 늘어날수록 결정이 느려지는데, 어떤 축을 고정하면 선택지를 줄일 수 있죠?”
- “민감한 상황에서는 ‘정답’보다 ‘다음 행동’을 먼저 제시해야 하지 않나요?”
결국 오늘 회의 산출물은 이거 하나다: “라벨 1개 + 변형 축 2개 + 민감 대응 버튼 1개”.
결정 기준: 모델을 바꿀 때가 아니라 판단 공정에 투자할 때
모델 교체가 먼저인 팀은 보통 “더 똑똑해지면 해결될 거야”라고 말한다.
아래 말이 회의에서 자주 나오면, 모델 얘기보다 공정 얘기부터 해야 한다.
- “이게 좋아진 건지 모르겠는데요”라는 말이 반복된다면, 평가 공정이 먼저다.
- “결과가 너무 많이 나와서 못 고르겠어요”가 반복된다면, 샘플링/선택 공정이 먼저다.
- “이건 민감해서 무서워요”가 반복된다면, 보호 공정이 먼저다.
- “사람마다 판단이 달라요”가 반복된다면, 판단을 재사용 가능한 형태로 고정해야 한다.
참고자료
- Apple Machine Learning Research — Scaling Search Relevance: Augmenting App Store Ranking with LLM-Generated Judgments
- https://machinelearning.apple.com/research/augmenting-app
- Apple Machine Learning Research — The Way We Notice, That’s What Really Matters: Instantiating UI Components with Distinguishing Variations (Celestial)
- https://machinelearning.apple.com/research/we-notice
- OpenAI — An update on our mental health-related work
- https://openai.com/index/update-on-mental-health-related-work
- OpenAI — Joint Statement from OpenAI and Microsoft
- https://openai.com/index/continuing-microsoft-partnership
- Google Blog — Get more context and understand translations more deeply with new AI-powered updates in Translate
- https://blog.google/products-and-platforms/products/translate/translation-context-ai-update/
실전 적용
“판단이 비싸다”는 말을 실제로 체감하는 순간은, 결과가 모자랄 때가 아니라 너무 많을 때다. 후보가 쏟아지면 팀은 빨리 지치고, 지치면 ‘감 좋은 사람’에게 결정이 몰린다. 그래서 실전에서는 모델을 더 붙이기 전에, 판단을 흘려보낼 배수로부터 만든다. 아래는 내가 킥오프나 주간 회의에서 바로 꺼내는 방식들이다. 문서로 예쁘게 남기기보다, 다음 주에도 같은 결정을 같은 속도로 하게 만드는 쪽에 가깝다.
- “맞다”의 정의를 한 문장으로 고정한다: 누구의 눈으로, 어떤 상황에서, 무엇을 만족하면 ‘통과’인지.
- 샘플링을 습관으로 만든다: 전체를 보려 하지 말고, 매번 같은 비율/같은 시간대로 일부만 뽑아 리뷰한다(그래야 비교가 된다).
- 후보를 줄이는 축을 먼저 합의한다: 길이/톤/위험도/사용자군 같은 ‘거르는 기준’을 정하고, 생성은 그 기준을 만족한 것만 가져오게 한다.
- 리뷰는 “좋다/나쁘다” 대신 “왜” 한 줄을 남긴다: 다음 번에 같은 이유로 싸우지 않게 만드는 최소 기록.
- 민감 케이스는 결과를 막지 말고 다음 행동을 준다: 연결/상담/사람 호출 같은 버튼을 우선순위로 둔다(판단을 제품에 묶는 느낌).
- 릴리스 전엔 ‘반례’만 모아본다: 잘 된 예시는 이미 다들 믿는다. 안 되는 사례 10개가 공정을 바꾼다.
흔한 함정도 두 개만 적어둔다. 둘 다 열심히 할수록 더 깊게 빠진다.
- 함정 1) “일단 돌려보고 나중에 평가하자”: 나중이 오기 전에 사용이 퍼지고, 그때부터는 되돌리기보다 변명이 된다.
- 함정 2) 후보를 늘리면 결정이 좋아질 거라는 착각: 결정 속도가 무너지면, 결국 선택 기준이 아니라 사람 컨디션으로 뽑게 된다.
댓글
댓글 쓰기