자율 에이전트 (Autonomous agents)를 설계하는 것은 독특한 좌절감을 안겨줍니다. 우리는 AI에게 복잡한 작업을 맡기고, AI는 30초(또는 30분) 동안 사라졌다가 결과와 함께 돌아옵니다. 우리는 화면을 응시합니다. 제대로 작동했을까요? 환각 (Hallucination)을 일으키지는 않았을까요? 컴플라이언스 (Compliance) 데이터베이스를 확인했을까요, 아니면 그 단계를 건너뛰었을까요?

우리는 보통 이러한 불안감에 대해 두 가지 극단적인 방식 중 하나로 대응합니다. 단순함을 유지하기 위해 모든 것을 숨기는 블랙박스 (Black Box) 방식을 취하거나, 아니면 공황 상태에 빠져 모든 로그 라인과 API 호출을 사용자에게 스트리밍하는 데이터 덤프 (Data Dump) 방식을 취합니다.

두 방식 모두 사용자에게 이상적인 수준의 투명성을 제공하는 데 필요한 미묘한 차이를 직접적으로 해결하지 못합니다.

*블랙박스 (Black Box)*는 사용자가 무력감을 느끼게 만듭니다. *데이터 덤프 (Data Dump)*는 알림 피로 (Notification blindness)를 유발하여, 에이전트가 제공하기로 약속했던 효율성을 파괴합니다. 사용자는 무언가 고장 날 때까지 끊임없이 흐르는 정보를 무시하며, 막상 문제가 발생했을 때는 이를 수정할 수 있는 맥락 (Context)이 부족하게 됩니다.

우리는 균형을 찾기 위한 조직적인 방법이 필요합니다. 저의 이전 기사인 “에이전트형 AI를 위한 설계 (Designing For Agentic AI)”에서 우리는 AI의 의도된 행동을 사전에 보여주는 것(의도 미리보기, Intent Previews)이나 AI가 스스로 수행하는 작업의 양을 사용자가 조절할 수 있게 하는 것(자율도 조절 다이얼, Autonomy Dials)과 같이 신뢰를 구축하는 인터페이스 요소들을 살펴보았습니다. 하지만 어떤 요소를 사용할지 아는 것은 과제의 일부일 뿐입니다. 디자이너에게 더 어려운 질문은 '언제' 그것들을 사용해야 하는지를 아는 것입니다.

30초짜리 워크플로우(Workflow) 중 어떤 특정 시점에 의도 미리보기 (Intent Preview)가 필요하고, 어떤 시점에 단순한 로그 항목 (Log entry)으로 처리할 수 있는지 어떻게 알 수 있을까요?

이 기사는 그 질문에 답하기 위한 방법을 제공합니다. 우리는 의사결정 노드 감사 (Decision Node Audit) 과정을 살펴볼 것입니다. 이 프로세스는 디자이너와 엔지니어가 한자리에 모여 백엔드 로직 (Backend logic)을 사용자 인터페이스 (User interface)에 매핑하도록 합니다. 여러분은 사용자가 AI가 무엇을 하고 있는지에 대한 업데이트를 필요로 하는 정확한 시점을 찾아내는 방법을 배우게 될 것입니다. 또한 어떤 의사결정 노드를 표시할지 우선순위를 정하는 데 도움이 되는 **영향/리스크 매트릭스 (Impact/Risk matrix)**와 해당 의사결정과 결합할 수 있는 관련 디자인 패턴에 대해서도 다룰 것입니다.

투명성 시점: 사례 연구 예시

Meridian(가명)이라는 보험사를 예로 들어보겠습니다. 이 회사는 초기 사고 청구(accident claims)를 처리하기 위해 에이전트형 AI (Agentic AI)를 사용합니다. 사용자가 차량 파손 사진과 경찰 보고서를 업로드하면, 에이전트는 약 1분 동안 사라졌다가 위험 평가 (risk assessment) 및 제안된 지급 범위와 함께 다시 나타납니다.

초기에 Meridian의 인터페이스는 단순히 '청구 상태 계산 중 (Calculating Claim Status)'이라고만 표시했습니다. 사용자들은 점점 좌절감을 느꼈습니다. 사용자는 여러 상세 문서를 제출했음에도 불구하고, AI가 참작 사유 (mitigating circumstances)가 포함된 경찰 보고서를 제대로 검토했는지조차 불확실하다고 느꼈기 때문입니다. 이러한 블랙박스 (Black Box) 현상이 불신을 초래했습니다.

이를 해결하기 위해 디자인 팀은 의사결정 노드 감사 (Decision Node Audit)를 실시했습니다. 그 결과, AI가 수많은 작은 단계들을 포함하여 세 가지의 뚜렷한 확률 기반 (probability-based) 단계를 수행한다는 것을 발견했습니다.

이미지 분석 (Image Analysis)
에이전트는 수리비를 추정하기 위해 파손 사진을 전형적인 자동차 사고 시나리오 데이터베이스와 비교했습니다. 이 과정에는 신뢰도 점수 (confidence score)가 포함되었습니다.

텍스트 검토 (Textual Review)
AI는 책임 소재 (liability)에 영향을 미치는 키워드(예: 과실, 기상 조건, 음주 여부)를 찾기 위해 경찰 보고서를 스캔했습니다. 이 과정에는 법적 지위 (legal standing)에 대한 확률 평가가 포함되었습니다.

보험 약관 교차 참조 (Policy Cross Reference)
AI는 예외 사항이나 보장 한도를 찾기 위해 청구 세부 사항을 사용자의 특정 보험 약관과 대조했습니다. 이 과정 역시 확률적 매칭 (probabilistic matching)을 포함했습니다.

팀은 이러한 단계들을 투명성 시점 (transparency moments)으로 전환했습니다. 인터페이스 시퀀스는 다음과 같이 업데이트되었습니다.

파손 사진 평가 중 (Assessing Damage Photos): 500개의 차량 충돌 프로필과 비교 중.
경찰 보고서 검토 중 (Reviewing Police Report): 책임 관련 키워드 및 법적 판례 분석 중.
보험 보장 범위 확인 중 (Verifying Policy Coverage): 귀하의 플랜 내 특정 제외 사항 확인 중.

시스템 소요 시간은 이전과 동일했지만, 에이전트의 내부 작동 방식에 대한 명시적인 커뮤니케이션(Explicit Communication)을 통해 사용자의 신뢰를 회복했습니다. 사용자들은 AI가 설계된 대로 복잡한 작업을 수행하고 있음을 이해하게 되었고, 최종 평가가 부정확해 보일 경우 정확히 어느 부분에 주의를 기울여야 하는지 알게 되었습니다. 이러한 설계 선택은 불안의 순간을 사용자와의 연결의 순간으로 변화시켰습니다.

영향/리스크 매트릭스 (Impact/Risk Matrix) 적용: 우리가 숨기기로 선택한 것들

대부분의 AI 경험에는 처리 과정 중에 표시될 수 있는 이벤트와 결정 노드(Decision Nodes)가 부족하지 않게 존재합니다. 이번 감사(Audit)의 가장 중요한 결과 중 하나는 무엇을 보이지 않게 유지할지 결정하는 것이었습니다. Meridian의 사례에서 백엔드 로그는 청구 건당 50개 이상의 이벤트를 생성했습니다. 우리는 UI의 일부로서 각 이벤트가 처리될 때마다 표시하는 것을 기본값으로 설정할 수도 있었습니다. 대신, 우리는 리스크 매트릭스(Risk Matrix)를 적용하여 이를 가지치기했습니다.

로그 이벤트 (Log Event): 중복성 확인을 위해 Server West-2에 핑(Pinging) 보내는 중.
필터 판결 (Filter Verdict): 숨김 (Hide). (낮은 이해관계, 높은 기술적 복잡성).

로그 이벤트 (Log Event): 수리 견적액을 BlueBook 가치와 비교하는 중.
필터 판결 (Filter Verdict): 표시 (Show). (높은 이해관계, 사용자의 지급액에 영향).

불필요한 세부 사항을 제거함으로써, 보장 범위 확인(Coverage Verification)과 같은 중요한 정보가 더 큰 영향력을 가질 수 있었습니다. 우리는 개방형 인터페이스를 만들었을 뿐만 아니라, 개방형 *경험 (Experience)*을 설계했습니다.

이 접근 방식은 사람들이 수행 중인 작업을 볼 수 있을 때 서비스에 대해 더 긍정적으로 느낀다는 아이디어를 활용합니다. 구체적인 단계(평가 중, 검토 중, 확인 중)를 보여줌으로써, 우리는 30초의 대기 시간을 걱정되는 시간(“고장 난 건가?”)에서 가치 있는 무언가가 만들어지고 있다는 느낌을 주는 시간(“생각 중이구나”)으로 바꾸었습니다.

이제 명확한 정보가 필요한 핵심 순간을 식별하기 위해, 우리 제품의 의사 결정 프로세스를 어떻게 검토할 수 있는지 자세히 살펴보겠습니다.

결정 노드 감사 (The Decision Node Audit)

투명성 (Transparency)은 이를 기능적 요구 사항이 아닌 스타일의 선택으로 취급할 때 실패합니다. 우리는 *“UI가 어떻게 보여야 하는가?”*를 묻기 전에, *“에이전트가 실제로 무엇을 결정하고 있는가?”*를 먼저 물어야 하는 경향이 있습니다.

결정 노드 감사 (The Decision Node Audit)는 AI 시스템을 더 이해하기 쉽게 만드는 간단한 방법입니다. 이는 시스템의 내부 프로세스를 주의 깊게 매핑함으로써 작동합니다. 주요 목표는 시스템이 설정된 규칙을 따르는 것을 멈추고, 대신 확률이나 추정 (Estimation)에 기반하여 선택을 내리는 정확한 순간을 찾아 명확하게 정의하는 것입니다. 이러한 구조를 매핑함으로써, 제작자는 이러한 불확실성의 지점들을 시스템을 사용하는 사람들에게 직접 보여줄 수 있습니다. 이를 통해 시스템 업데이트는 모호한 진술에서 AI가 어떻게 결론에 도달했는지에 대한 구체적이고 신뢰할 수 있는 보고로 변화합니다.

위의 보험 사례 연구 외에도, 저는 최근 조달 에이전트 (Procurement Agent)를 구축하는 팀과 함께 작업했습니다. 이 시스템은 공급업체 계약을 검토하고 리스크를 식별했습니다. 원래 화면에는 *“계약서 검토 중”*이라는 단순한 진행 표시줄 (Progress bar)만 표시되었습니다. 사용자들은 이를 매우 싫어했습니다. 저희의 조사 결과에 따르면, 사용자들은 조항 누락이 가져올 법적 영향에 대해 불안감을 느끼고 있었습니다.

저희는 결정 노드 감사 (Decision Node Audit)를 실시하여 이 문제를 해결했습니다. 이 감사를 수행하기 위한 단계별 체크리스트를 이 글의 결론 부분에 포함해 두었습니다.

저희는 엔지니어들과 세션을 진행하며 시스템이 어떻게 작동하는지 개괄했습니다. 그리고 AI가 두 가지 좋은 옵션 사이에서 선택해야 했던 순간인 “결정 지점 (Decision Points)”을 식별했습니다.

표준 컴퓨터 프로그램에서 프로세스는 명확합니다. A가 발생하면 항상 B가 발생합니다. 하지만 AI 시스템에서 프로세스는 종종 확률에 기반합니다. AI는 A가 아마도 최선의 선택이라고 생각하지만, 그 확신은 65%에 불과할 수도 있습니다.

계약 시스템에서 저희는 AI가 회사 규칙에 따라 책임 조항 (Liability terms)을 확인하는 순간을 발견했습니다. 완벽하게 일치하는 경우는 드물었습니다. AI는 90%의 일치율이 충분한지 결정해야 했습니다. 이것이 바로 핵심적인 결정 지점이었습니다.

이 노드(node)를 식별한 후, 우리는 이를 사용자에게 노출했습니다. 인터페이스는 단순히 *“계약서 검토 중”*이라고 표시하는 대신, *“책임 조항이 표준 템플릿과 다릅니다. 리스크 수준을 분석 중입니다.”*라고 업데이트되었습니다.

이러한 구체적인 업데이트는 사용자에게 확신을 주었습니다. 사용자들은 에이전트가 책임 조항을 확인했다는 사실을 알게 되었습니다. 그들은 지연이 발생하는 이유를 이해했으며, 백엔드(back end)에서 원하는 작업이 수행되고 있다는 신뢰를 얻었습니다. 또한 에이전트가 계약서를 생성한 후 어디를 더 깊이 파고들어야 할지도 알 수 있었습니다.

AI가 어떻게 결정을 내리는지 확인하려면 엔지니어, 제품 관리자(product manager), 비즈니스 분석가(business analyst), 그리고 AI 도구의 기능에 영향을 미치는 (종종 숨겨진) 선택을 내리는 핵심 인력들과 긴밀히 협력해야 합니다. 도구가 취하는 단계들을 그려보세요. 확률(probability) 조건이 충족되어 프로세스의 방향이 바뀌는 모든 지점을 표시하세요. 이곳들이 바로 더 높은 투명성을 확보하는 데 집중해야 할 지점들입니다.

아래 그림 2(Figure 2)에서 보여주는 바와 같이, 결정 노드 감사(Decision Node Audit)는 다음 단계들을 포함합니다:

팀 소집하기: 제품 소유자(product owner), 비즈니스 분석가, 디자이너, 주요 의사 결정자, 그리고 AI를 구축한 엔지니어들을 참여시키세요. 예를 들어, 복잡한 법률 계약서를 검토하도록 설계된 AI 도구를 만드는 제품 팀을 생각해 보십시오. 이 팀에는 UX 디자이너, 제품 관리자, UX 리서처, 주제 전문가(subject-matter expert) 역할을 하는 현직 변호사, 그리고 텍스트 분석(text-analysis) 코드를 작성한 백엔드 엔지니어가 포함됩니다.

전체 프로세스 그리기: 사용자의 첫 번째 행동부터 최종 결과에 이르기까지 AI가 수행하는 모든 단계를 문서화합니다. 팀은 화이트보드 앞에 서서, AI가 복잡한 계약서 내에서 책임 조항 (liability clause)을 검색하는 핵심 워크플로우 (workflow)의 전체 시퀀스 (sequence)를 스케치합니다. 변호사가 50페이지 분량의 PDF를 업로드합니다 → 시스템이 문서를 읽을 수 있는 텍스트로 변환합니다. → AI가 페이지를 스캔하여 책임 조항을 찾습니다. → 사용자가 대기합니다. → 몇 초 또는 몇 분 후, 도구가 사용자 인터페이스 (user interface) 상에서 찾은 단락들을 노란색으로 강조 표시합니다. 이들은 도구가 지원하는 다른 많은 워크플로우에 대해서도 이 작업을 수행합니다.

불분명한 지점 찾기: AI가 완벽하게 일치하는 항목이 없는 옵션이나 입력을 비교하는 모든 지점을 프로세스 맵 (process map)에서 찾아봅니다. 팀은 화이트보드를 살펴보며 모호한 단계들을 찾아냅니다. 이미지를 텍스트로 변환하는 것은 엄격한 규칙을 따릅니다. 하지만 특정 책임 조항을 찾는 것은 추측 (guesswork)을 수반합니다. 모든 법무법인은 이러한 조항을 서로 다르게 작성하므로, AI는 정확한 단어 일치를 찾는 대신 여러 옵션을 검토하고 예측 (prediction)을 수행해야 합니다.

'최선의 추측' 단계 식별하기: 불분명한 각 지점에 대해, 시스템이 신뢰도 점수 (confidence score, 예: 85% 확신 여부)를 사용하는지 확인합니다. 이 지점들이 바로 AI가 최종 선택을 내리는 지점입니다. 시스템은 어떤 단락이 표준 책임 조항과 밀접하게 유사한지 추측(확률 제공)해야 합니다. 시스템은 자신의 최선의 추측에 신뢰도 점수를 할당합니다. 그 추측이 바로 결정 노드 (decision node)입니다. 인터페이스는 변호사에게 확정적인 조항을 찾았다고 단정하기보다는, 잠재적인 일치 항목을 강조 표시하고 있음을 알려주어야 합니다.

선택 사항 검토하기: 각 선택 시점(choice point)에 대해 수행되는 구체적인 내부 수학 연산 또는 비교 작업(예: 계약서의 일부를 정책과 매칭하거나, 파손된 차량 사진을 파손 차량 사진 라이브러리와 비교하는 작업)을 파악합니다. 엔지니어는 시스템이 다양한 단락을 과거 로펌 사례의 표준 책임 조항 데이터베이스와 비교한다고 설명합니다. 시스템은 확률에 기반하여 일치 여부를 결정하기 위해 텍스트 유사도 점수(text similarity score)를 계산합니다.

명확한 설명 작성하기: AI가 선택을 내릴 때 발생하는 구체적인 내부 동작을 사용자에게 명확하게 설명하는 메시지를 생성합니다. 콘텐츠 디자이너는 바로 이 순간을 위한 구체적인 메시지를 작성합니다. 문구는 다음과 같습니다:

잠재적인 책임 리스크를 식별하기 위해 문서 텍스트를 로펌의 표준 조항과 비교하는 중.

화면 업데이트하기: *“계약서 검토 중”*과 같은 모호한 메시지를 대신하여, 이러한 새롭고 명확한 설명들을 사용자 인터페이스(UI)에 반영합니다. 디자인 팀은 일반적인 “PDF 처리 중” 로딩 스피너(loading spinner)를 제거합니다. 대신 AI가 생각하는 동안 문서 뷰어 바로 위에 위치한 상태 표시줄(status bar)에 새로운 설명을 삽입합니다.

신뢰도 확인하기: 새로운 화면 메시지가 대기 시간이나 결과에 대해 사용자에게 단순한 이유를 제공하는지 확인합니다. 이는 사용자가 더 큰 확신과 신뢰를 느낄 수 있도록 해야 합니다.

영향/리스크 매트릭스 (Impact/Risk Matrix)

AI의 프로세스를 면밀히 살펴보면, AI가 선택을 내리는 지점을 많이 발견하게 될 것입니다. AI는 단 하나의 복잡한 작업을 수행하기 위해 수십 개의 작은 선택을 내릴 수도 있습니다. 이 모든 것을 다 보여주는 것은 불필요한 정보 과잉을 초래합니다. 따라서 이러한 선택들을 그룹화해야 합니다.

AI가 취하는 행동의 유형에 따라 이러한 선택들을 분류하기 위해 **영향/리스크 매트릭스 (Impact/Risk Matrix)**를 사용할 수 있습니다. 영향/리스크 매트릭스의 예시는 다음과 같습니다:

먼저, 이해관계가 낮고(low-stakes) 영향력이 적은(low-impact) 결정부터 살펴봅니다.

낮은 이해관계 / 낮은 영향력 (Low Stakes / Low Impact)

예시: 파일 구조를 정리하거나 문서의 이름을 변경하는 작업.
투명성 필요도: 최소 수준. 미묘한 토스트 알림(toast notification)이나 로그 기록(log entry)만으로도 충분합니다. 사용자는 이러한 작업을 쉽게 되돌릴 수 있습니다.

그다음, 이해관계가 높고(high-stakes) 영향력이 큰(high-impact) 결정들을 식별하십시오.

이해관계가 높고 영향력이 큰 결정 (High Stakes / High Impact)