소프트웨어가 말을 배우다

Source: Dev.to

Introduction

사람들은 기술에 반하지 않는다.
사용자 온보딩 세션에 실제로 앉아보면—슬라이드 덱을 대충 보는 것이 아니라—특정한 리듬을 발견하게 된다.

• 사용자가 클릭한다.
• 멈춘다.
• 다시 클릭한다.
• 머뭇거린다.

성인이 뭔가 명백한 것을 놓쳤는지 확신이 서지 않을 때 보이는 그 망설임이다. 그러고는 작은, 사과 섞인 미소가 나온다. 트레이너가 나서서 근육 기억처럼 부드럽게 설명한다. 그리고 사용자는 고개를 끄덕인다. 갑자기 이해했기 때문이 아니라, 앞으로 나아가고 싶어서다.

충분히 오래 머무르면 이러한 순간들이 어떻게 쌓이는지 보게 된다.

• 여기서 작은 수정 하나.
• 저기서 명확해진 버튼 라벨 하나.
• 다시 약간 다른 말로 설명되는 오해된 흐름 하나.

극적인 일도 아니고, 대시보드에 뜨는 일도 아니다. 단지 마찰일 뿐. 거의 눈에 보이지 않지만 지속적이다.

나중에 지원 대기열에서 이런 말을 듣게 된다:

“잠깐 통화할 수 있을까요?”
“어디서 찾을 수 있나요…?”
“이게 이렇게 된다고 생각했는데…?”

내부 Slack 채널에서도 들린다. 그리고 그 길을 충분히 걸어가면 결국 실제 비용에 도달한다.

한 번 보게 되면 놀라운 점은 이 패턴이 얼마나 보편적인가이다. 모든 벤더, 모든 도구, 모든 플랫폼은 제품 주위에 평행 우주의 설명을 만든다. 왜냐하면 제품 자체가 자신이 무엇인지, 무엇을 하는지, 사용자가 다음에 무엇을 해야 하는지를 설명할 수 없기 때문이다. 그래서 우리는 방대한 문서 포털, 온보딩 비디오, 지식 베이스, AI 채팅 창, 그리고 매일 같은 문장을 반복하는 인내심 강한 트레이너들을 갖게 된다—우리가 거의 인정하지 않는 단 하나의 사실을 둘러싼 전체 설명 생태계: 대부분의 엔터프라이즈 애플리케이션은 스스로 말할 수 없다.

The Silence of Self‑Unexplaining Systems

시스템이 스스로 설명할 수 없다는 침묵을 눈치채기 시작하면, 그 침묵을 무시할 수 없게 된다. 어디서든, 거대 기업들 사이에서도 그것을 인식하게 된다.

SAP

수십 년간 비즈니스 소프트웨어를 만들어온 그런 규모의 기업이라면 설명을 애플리케이션 자체에 녹여 넣었을 것이라 기대할 수 있다. 하지만 그들의 최신 인터페이스조차도 부담을 외부로 밀어낸다: 도움 포털, 오버레이, 문서 허브 등.

Salesforce

Salesforce도 비슷한 패턴을 보이지만, 다른 색깔을 띤다. 제품이 자체 구조를 설명할 수 없기 때문에 설명 생태계가 필요하다.

Atlassian

Atlassian의 문서는 사실 자체 중력장을 가지고 있다. 그래도 누군가가 Jira 안에 들어가 팀 전용 워크플로를 이해하려 할 때, 설명은 다른 곳에 있다—다른 탭, 다른 공간, 누군가가 한 번 적어 두고 다른 누군가가 계속 업데이트하려 애쓰던 이야기.

각 기업은 거대한 자원과 전혀 다른 전략으로 같은 문제에 접근했다.

A Glimpse from the Past: Eclipse RCP

오늘날 SaaS 물결, 클라우드, 모듈식 프론트엔드 프레임워크가 등장하기 전, 누군가 거의 깨달음에 가까워진 순간이 있었다. 플러그인 기반 엔터프라이즈 툴링의 선구자 Eclipse RCP는 한때 도움을 일급 시민으로 대우했다. 이는 소프트웨어가 자체적으로 말할 수 있는 세계가 될 수 있었던 가능성을 보여줬다. 그러나 산업은 다른 길을 갔다. 웹 앱이 장악했고, 소프트웨어가 스스로 설명한다는 아이디어는 여정조차 못했다.

Rethinking Help as Architecture

우리는 그 부재의 잔재와 함께 살아간다. 어쩌면 도움은 문서가 아니라 인프라일지도 모른다.

만약 우리가 사후 생각으로 여겨온 도움이 언제나 아키텍처의 일부가 되도록 설계되었다면 어떨까? 그 생각은 조용히, 마치 방금 지나온 모든 것의 잔상처럼 떠오른다:

• 온보딩 세션의 망설임.
• 트레이너가 반복하는 말.
• 제품을 둘러싼 포털, 가이드, 튜토리얼, AI 어시스턴트라는 정교한 생태계가 마치 자체 중력을 유지하지 못하는 행성 주위의 달처럼 맴돈다.

만약 도움이 단순히 콘텐츠—단어, 다이어그램, 답변—에 불과했다면 지금쯤 더 많은 콘텐츠가 문제를 해결했을 것이다. 그러나 마찰은 남아 있고, 그 끈적임도, 조용하고 지속적인 비용도 여전히 존재한다.

The Missing Meta Layer

거의 모든 다른 아키텍처적 관심사는 자체 레이어를 가진다:

• Data → models
• Logic → services
• Boundaries → APIs
• State → stores
• Layout → components
• Communication → events
• Execution → pipelines
• Navigation → routers

하지만 인간이 시스템을 이해하도록 돕는, 화면이 의미하는 바, 기능이 하는 일, 행동이 큰 그림에 어떻게 맞는지 등을 설명해야 할 때는 레이어가 없다. 단지 산업이 단어로 메우는 공백일 뿐이다. 그래서 설명은 언제나 애플리케이션 밖에 머문다.

이것을 깨달으면, 앞서 언급한 순간들—사용자 망설임, 지원 전화, 방대한 지식 베이스—이 다른 시각으로 보인다. 커뮤니케이션 실패나 교육 부족이 아니라 아키텍처적 누락의 증상이다. 제품의 침묵은 콘텐츠 문제였던 것이 아니다.

Envisioning a Structural Help Layer

도움을 보조가 아니라 구조적인 것으로 생각하기 시작하면, 부재의 형태가 더 명확해진다. 시스템은 이미 자신에 대해 많은 것을 알고 있다:

• 현재 어떤 모듈에 있는지.
• 어떤 고객, 청구서, 티켓, 워크플로를 보고 있는지.
• 개요 화면인지 상세 화면인지.
• 어떤 행동이 가능하고 어떤 것이 비활성화되어 있는지.
• 어떤 필드가 필수인지, 어떤 상태가 유효한지, 어떤 전이가 의미 있는지, 그리고 어떤 전이가 비즈니스 규칙을 깨뜨리는지.

이 모든 지식은 애플리케이션 내부에서 조용히 흐르며, 시스템이 할 수 있는 일과 할 수 없는 일을 알려준다. 그러나 그 어느 것도 화면 반대편에 있는 인간에게 설명하는 데 활용되지 않는다. 애플리케이션은 내부적으로 완전한 명확성을 가지고 살아가고, 사용자는 외부의 추측 속에서 살아간다. 그 사이에 레이어가 하나 빠져 있다—UI 프레임워크만큼이나 애플리케이션 구조를 깊이 이해하는 레이어가.

What This Meta Layer Would Do

• Describe 현재 컨텍스트: “여기에 있습니다. 이 위치가 하는 일은 이것이며, 다음에 할 수 있는 일은 이것입니다.”
• Travel 코드와 함께 이동하고, 각 릴리스마다 업데이트되며, 설정에 맞게 적응한다.
• Speak 파일과 폴더가 아닌 모듈과 기능의 언어로 말한다.
• Provide 시스템이 사용자에게 부드럽게 방향을 제시하고 안심시킬 수 있는, 런타임에 통합된 네이티브 방식을 제공한다: “당신이 어디에 있는지 압니다. 이것이 무슨 의미인지 압니다. 보여드릴게요.”

이는 트레이너, 지원팀, 온보딩 전문가를 대체하는 것이 아니라, 시스템 자체에 목소리를 부여한다—외부에서 수동으로 유지되는 문서에 의존하지 않고 사용자를 안내할 수 있는 능력을 제공한다.

Conclusion

소프트웨어에 이런 레이어가 있다고 상상하면, 그 아이디어는 거의 자명해 보인다. 기능에 대한 가장 정확하고 가까운 설명은 그것을 구현하는 코드 안에 살아 있어야 하며, 별도의 우주에 존재해서는 안 된다. 그러나 우리는 아직 그런 시스템을 만들지 못했다—아직은.

누락된 메타 레이어가 부담을 인간, 즉 트레이너, 지원팀, 온보딩 전문가에게 떠맡기게 만든다. 이들은 소프트웨어가 자동으로 수행할 수 있었던 작업을 수동으로 수행한다. 구조적인 도움 레이어를 도입하면 그 부담을 시스템으로 되돌려, 소프트웨어가 스스로 말하고, 결국 사용자가 스스로를 이해하도록 돕는 능력을 갖게 된다.