AI 추천 기능 설계 원칙 — 예언자 대신 조력자를 만들어라

Q: AI 추천 이유를 보여주려면 개발 비용이 많이 들지 않나요?

전체 모델의 내부 로직을 다 보여줄 필요는 없습니다. 어떤 데이터를 근거로 했는지 한두 줄이면 충분한 경우가 많습니다. "최근 7일 접속 패턴 기준"처럼 단순한 근거 표시만으로도 신뢰도가 크게 달라집니다.

Q: 알림을 얼마나 줄여야 경고 피로를 피할 수 있나요?

정해진 숫자는 없지만, 사용자가 무시하기 시작하는 지점을 관찰하며 조정하는 것이 이 자료의 권고입니다. 중요한 알림과 그렇지 않은 알림을 구분해 등급을 매기고, 낮은 등급은 알림 대신 화면 안에 조용히 표시하는 방식이 실무에서 많이 쓰입니다.

Q: 작은 팀도 이런 협력적 지원 시스템을 만들 수 있나요?

가능합니다. 오히려 완전 자동화보다 개발 부담이 적습니다. 모든 경우의 수를 검증할 필요 없이, 데이터를 정리해서 보여주고 근거를 표시하는 수준으로 시작할 수 있습니다. 이 자료가 제시한 세 분야(헬스케어, 스마트 팩토리, 투자 자문)도 그런 이유로 진입 장벽이 낮다고 설명합니다.

정답을 내리려는 앱은 엣지 케이스에서 반드시 실패합니다. 의사결정 지원 시스템, 베이지안 업데이트, 최소 놀람의 원칙으로 불확실성을 다루는 AI 제품 설계 원칙을 정리했습니다.

2026년 4월 14일에버스톤10분 분량AI · 개발AI 도입 컨설팅

2026년 9월 22일 수정

AI 추천 기능 설계 원칙 — 예언자 대신 조력자를 만들어라 대표 이미지

"모든 걸 정확히 예측하는 앱"은 매력적인 제안이지만, 변수가 무한한 현실에서는 기술적 신화에 가깝습니다. 이 자료는 완벽한 예측 대신 무엇을 설계해야 하는지, AI 제품이 불확실성을 다루는 원칙을 정리합니다.

이 문서는 NotebookLM(노트북 LM)으로 자료를 조사해 만든 문서입니다.

복잡계에서 완벽한 예측 모델은 없습니다. 예언자(Oracle) 앱을 목표로 하면 막대한 비용과 엣지 케이스 실패로 끝납니다
대안은 **의사결정 지원 시스템(DSS)**입니다. 최종 결정과 책임은 사람에게 남겨 둡니다
불확실성은 베이지안 업데이트로 관리합니다. 새 증거가 올 때마다 믿음을 갱신합니다
알림을 남발하면 경고 피로로 무시당합니다. 자연스러운 작업 흐름에 녹여야 합니다
근거 없는 추천은 신뢰받지 못합니다. 설명 가능성이 필수입니다

예언자는 신화다

100% 완벽한 예측은 기술적인 신화에 불과하다는 슬라이드. 의료, 금융, 산업 현장 등 변수가 무한한 복잡계에서는 완벽한 예측 모델링이 불가능하며, 모든 것을 결정하는 예언자(Oracle) 형태의 앱을 개발하려는 시도는 막대한 개발 비용을 초래하고 엣지 케이스에서 치명적인 실패를 겪게 된다는 설명. 왼쪽은 화살이 정확히 과녁을 맞히는 기술적 기대(Expectation), 오른쪽은 어지럽게 얽힌 선들 속에서 결국 흔들리며 빗나가는 현실의 복잡성(Reality)

정답 기계가 아니라 조력자로

정답을 내리는 기계에서 최적의 조력자로 전환해야 한다는 슬라이드. 해결책은 의사결정 지원 시스템(DSS)이며, 앱의 역할은 완벽한 정답을 내리는 것이 아니라 인간 의사결정자의 인지적 부담을 줄여주는 것이고, 최종 결정권과 책임은 항상 시스템 밖의 인간에게 남겨둔다는 설명. 왼쪽은 서버에서 곧바로 최종 결정(원)으로 이어지는 단선 화살표에 사선이 그어져 있고, 오른쪽은 서버가 여러 신호를 사람에게 보내고 사람이 최종 결정을 내리는 구조

이 전환이 이 자료 전체의 핵심입니다. 결정을 대신 내려 주는 제품이 아니라, 결정하기 쉽게 만들어 주는 제품을 목표로 잡으라는 것입니다.

불확실성을 다루는 기술

불확실성은 베이지안 업데이트를 통해 관리된다는 슬라이드. 정적인 알고리즘 대신 사용자의 상호작용을 증거로 삼아 앱의 믿음을 지속적으로 갱신한다는 설명. 사전 지식(Prior, 초기 기본 설정) → 새로운 데이터(Evidence, 사용자의 선택과 행동) → 사후 모델(Posterior, 개인화되고 정교해진 맞춤형 지원)로 이어지는 지속적 피드백 루프

예측할 수 없는 상황일수록 UI는 최소 놀람의 원칙을 따라야 한다는 슬라이드. 예측 부호화(Predictive Coding) — 인간의 뇌는 끊임없이 환경을 예측하고 놀람을 최소화하려 함. 최소 놀람의 원칙(POLA, Principle of Least Astonishment) — 앱은 UI나 구문이 암시하는 것과 정확히 일치하게 작동해야 함. 알고리즘의 불확실성이 높을수록 조작 방식은 가장 익숙한 관습을 따라야 사용자의 혼란을 막을 수 있다는 설명. 사용자의 기대와 앱의 실제 출력이 겹치는 부분이 최소 놀람의 원칙

결과가 불확실할수록 인터페이스는 더 익숙하고 예측 가능해야 한다는 것이 역설적이지만 핵심입니다. 모델이 불안정한데 UI까지 낯설면 신뢰가 두 배로 떨어집니다.

사례 — 의료 현장의 CDSS

성공 사례 의료진의 직관을 돕는 임상 의사결정 지원 시스템(CDSS) 슬라이드. CDSS는 의사를 대체하지 않으며, 환자 데이터를 분석해 약물 상호작용을 경고하거나 잠재적 진단을 제안한다는 설명. 기계의 방대한 데이터 마이닝 능력과 인간의 고도의 전문적 직관이 결합하여 최적의 결과를 도출한다는 설명. 환자 데이터와 의학 지식 베이스가 합쳐져 앱의 진단/처방 제안으로 이어지고, 그것이 의사의 최종 판단으로 연결되는 흐름

조심할 것 — 경고 피로

주의할 점 과도한 예측과 경고는 경고 피로를 유발한다는 슬라이드. 앱이 모든 것을 예측하고 경고하려 들면 사용자는 점차 모든 알림을 무시하게 되며, 알림은 별도의 화면이 아닌 사용자의 자연스러운 작업 흐름 내에 매끄럽게 통합되어야 한다는 설명. 오른쪽 그래프는 앱의 개입·경고 횟수가 늘수록 사용자 신뢰·이용률이 상승하다가 경고 피로 발생 지점을 지나면 급격히 하락하는 곡선

통제하지 않고 보여주기

통제하지 않고 보여주는 수동적 지원의 강력함 슬라이드. 스마트 팩토리의 이상 징후 대시보드나 항공 의사결정 시스템은 데이터 시각화와 가상 시나리오(What-If)만을 제공하며, 기계가 행동을 강제하지 않고 트렌드만 제시할 때 관리자는 시스템을 더 깊이 신뢰하고 유연하게 대처한다는 설명. Smart Factory, Aviation, Infrastructure 세 영역의 데이터 시각화 카드 예시

이유를 보여줘야 신뢰받는다

블랙박스는 버리고 설명 가능한 맥락을 제공해야 한다는 슬라이드. 결과를 100% 확신할 수 없는 분야에서 이유 없는 추천은 버림받으며, 앱은 반드시 왜 이 선택지를 추천하는가(XAI, 설명 가능한 AI)에 대한 근거를 시각적으로 제공해야 하고, 그래야만 인간이 지원의 타당성을 평가하고 최종 결정을 내릴 수 있다는 설명. 왼쪽은 사선이 그어진 블랙박스에서 바로 Output으로 이어지는 구조, 오른쪽은 Data → Rule → Output 이 투명하게 쌓여 보이는 구조

협력적 지원이 더 나은 이유

왜 협력적 지원이 더 나은 전략인가 비교표. 완전 자동화 앱(High Risk)은 법적·결과적 책임이 기계에 집중되고 개발 부담으로 천문학적 데이터 검증 비용이 들며 불투명성으로 인한 불신이 생기고 예외 상황에서 치명적 마비가 발생한다. 협력적 지원 앱/DSS(Low Risk)는 인간이 최종 책임을 지고 데이터 기반의 맥락 제공 수준으로 비용이 절감되며 투명한 근거 제시로 신뢰가 상승하고 인간의 유연한 판단으로 예외를 극복한다

어디에 적용해야 성공 가능성이 높은가

성공 가능성이 가장 높은 타겟 반구조적 영역 도식. 성공적인 앱은 데이터는 존재하지만(구조적) 최종 판단에는 인간의 직관이나 맥락이 필요한(비구조적) 교집합 영역을 노린다는 설명. 정답을 내는 대신 데이터를 집계하고 트렌드를 시각화하며 대안을 제시하는 방향으로 리소스를 집중하라는 조언. 완전 구조화(단순 반복)와 비구조적(순수 예술/창작) 사이에 반구조적 문제 영역이 놓인 동심원 도식

조력자 모델의 도입 부담이 적고 유망한 3대 분야. 디지털 헬스케어 — 원격 모니터링 및 자가 검진 데이터 기반의 사전 진단 지원. 스마트 팩토리 — 공정 연계 분석 및 이상 징후 알림을 통한 설비 유지보수 지원. 로보어드바이저 — 고객 투자 성향 알고리즘 분석 및 자산운용 시나리오 자문

앱 기획자와 개발자를 위한 5가지 체크리스트. 1 예언자를 만들지 말고 유능한 조력자를 설계하라. 2 베이지안 루프를 적용하여 사용자의 행동으로부터 지속적으로 학습하라. 3 과도한 알림을 피하고 사용자의 자연스러운 작업 흐름에 녹아들어라. 4 알고리즘이 복잡할수록 UI는 최소 놀람의 원칙을 엄격히 지켜라. 5 블랙박스를 치우고 모든 추천의 이유(근거)를 시각적으로 투명하게 제공하라

마무리 슬라이드. 기술적 완벽함이 불가능한 곳에서 가장 완벽한 앱은 인간의 직관을 가장 잘 돕는 앱이라는 결론

자주 묻는 질문

우리 서비스가 예언자형인지 조력자형인지 어떻게 판단하나요? "이 기능이 틀렸을 때 누가 책임지는가"를 물어보면 됩니다. 앱이 자동으로 실행하고 결과가 틀리면 앱의 책임이 되는 구조라면 예언자형이고, 사람이 최종 확인 후 실행하는 구조라면 조력자형입니다. 후자가 리스크와 개발 비용 모두에서 안전합니다.

AI 추천 이유를 보여주려면 개발 비용이 많이 들지 않나요? 전체 모델의 내부 로직을 다 보여줄 필요는 없습니다. 어떤 데이터를 근거로 했는지 한두 줄이면 충분한 경우가 많습니다. "최근 7일 접속 패턴 기준"처럼 단순한 근거 표시만으로도 신뢰도가 크게 달라집니다.

알림을 얼마나 줄여야 경고 피로를 피할 수 있나요? 정해진 숫자는 없지만, 사용자가 무시하기 시작하는 지점을 관찰하며 조정하는 것이 이 자료의 권고입니다. 중요한 알림과 그렇지 않은 알림을 구분해 등급을 매기고, 낮은 등급은 알림 대신 화면 안에 조용히 표시하는 방식이 실무에서 많이 쓰입니다.

작은 팀도 이런 협력적 지원 시스템을 만들 수 있나요? 가능합니다. 오히려 완전 자동화보다 개발 부담이 적습니다. 모든 경우의 수를 검증할 필요 없이, 데이터를 정리해서 보여주고 근거를 표시하는 수준으로 시작할 수 있습니다. 이 자료가 제시한 세 분야(헬스케어, 스마트 팩토리, 투자 자문)도 그런 이유로 진입 장벽이 낮다고 설명합니다.

저희가 이 이야기를 하는 이유

에버스톤은 게임과 앱을 만들면서 예측이나 추천 기능을 넣을 때 이 원칙을 그대로 따릅니다. 완벽히 맞히는 기능을 약속하기보다 참고할 근거를 보여주고 최종 선택은 유저에게 남기는 방식이 결과적으로 신뢰를 더 얻습니다. AI 기능을 넣을수록 이 균형이 중요해진다고 느낍니다.

인용한 개념과 사례는 원 자료 기준이며, 저희가 검증한 내용이 아닙니다.