멘탈 모델을 전달하는 도구나 기법은?

• 시스템이나 제품을 이해하는 멘탈 모델을 다른 사람에게 전달하고 함께 키우는 데 효과적인 도구와 기법을 묻는 질문임
• 멘탈 모델을 키우는 방법으로 시스템을 직접 만들고 유지보수하는 경험이 거론됨
• 전달 방식은 냅킨 낙서, 옆에서 몸짓으로 설명하기, 함께 고민하며 말로 풀어내기 같은 비공식적 설명에 가까움
• 기능 목록이나 표면 영역을 빠짐없이 정리한 문서는 포괄적일 수 있지만, 주제의 멘탈 모델을 만들거나 전달하기에는 부족할 수 있음
• 잘 설계된 도구나 제품을 직접 써보는 경험은 멘탈 모델을 키우고 전달하는 과정을 동시에 도울 수 있음

---

질문의 초점

• 어떤 도구나 기법이 멘탈 모델을 전달하고 성장시키는 데 효과적인지가 핵심임
• 질문은 두 가지 방향을 함께 다룸
  • 멘탈 모델을 키우는 방법
  • 멘탈 모델을 다른 사람에게 전달하는 방법

예시와 문제의식

• 멘탈 모델을 키우는 예시로 시스템을 만들고 유지보수하는 방식이 나옴
• 멘탈 모델을 전달하는 방식은 다음처럼 현장에서 함께 이해를 맞추는 형태임
  • 냅킨에 낙서하기
  • 옆에서 몸짓으로 설명하기
  • 함께 고민하는 상황에서 설명하기
• 기능을 나열하거나 표면적 범위를 카탈로그화한 문서는 포괄적일 수 있음
• 하지만 이런 문서가 해당 주제의 멘탈 모델을 만들거나 전달하는 데까지 이어지지는 않을 수 있음
• 잘 설계된 도구나 제품을 직접 사용하는 경험은 멘탈 모델의 성장과 전달을 모두 달성할 수 있는 방식으로 다뤄짐
• 마지막 질문은 각자 효과를 본 도구와 기법, 그리고 그것이 왜 효과적인지를 묻고 있음

[GN⁺]

Lobste.rs 의견들

• 온톨로지 로그는 온톨로지를 전달하는 데 좋은 형식주의임
  내부 상태가 많은 장기 실행 프로세스라면 상태도와 상태 차트가 시스템 문서화에 유용함
  시스템 사용자는 보통 실제 시스템 구조를 지각하지 못함. 한 이유는 Nakatomi space가 시스템을 오용하는 사용자에게만 보이기 때문이고, weird machines 같은 의도치 않은 동작을 위한 상태 공간 영역이 따로 있기 때문임
  또 다른 이유는 the purpose of a system is what it does라는 관점처럼, 사용자는 시스템이 자신에게 해주는 일만 보고 개인적인 존재 이유를 만들 수 있지만, 설계자와 유지보수자가 의도한 전체 목적은 알아차리지 못할 수 있음

• 책을 쓰고, 편집자를 고용하면 됨

• 이건 교육의 핵심 문제에 가깝지 않나 싶음. 해보면서 배우기와 전문가의 지도라는 두 범주를 들었고, 세 번째는 가르치기임
  더 중요한 질문은 비슷한 원리와 설계를 재사용해 가면서 더 쉽게 습득되는 모델을 만들 수 있느냐, 또는 추상화를 통해 완전히 습득할 필요를 줄일 수 있느냐임. 다만 추상화가 어디서 새는지는 잘 정의되어 있어야 함

  • 맞는 말임. 자기 정신 모델을 다른 사람에게 효과적으로 전달하거나, 다른 사람이 자기 모델을 만들도록 돕는 분야가 바로 “교육”이라고 부름
    관련해서 Felienne Hermans의 The Programmer's Brain이 흥미로움. 어린아이에게 수학 등을 가르칠 때 “내가 여러 예제를 풀어줄 테니 봐라” 방식이 프로그래밍 교육에도 꽤 잘 먹힌다는 점이 인상적이었음
    업무 환경에서 온보딩한다면 “이 버그를 내가 어떻게 조사하는지 봐라” 또는 “한동안 안 만진 이 하위 시스템을 내가 어떻게 다시 파악하는지 봐라” 같은 형태가 될 듯함

• 소프트웨어 공학에서는 정신 모델을 사용자 스토리와 기술 구현으로 나눠 보는 게 도움이 됨
  보통 사용자 스토리는 1차 요구사항, 즉 달성하려는 가치이고, 기술 구현은 그 목표를 이루기 위해 필요한 2차 요소임
  사용자 스토리는 고객에게 전달하는 가치를 설명하고, 기술 구현은 만든 시스템의 제약이 사용자 스토리를 어떻게 제한하는지 설명함
  때로는 둘이 겹쳐서 사용자 스토리가 기술 구현에 제약받거나, 반대로 사용자 스토리를 달성하기 위해 기술 구현을 선택하게 됨. 하지만 많은 시스템 동작은 둘 중 하나로 틀을 잡을 수 있음
  그다음에는 가장 잘 맞는 도구를 고르면 됨. UML은 개체 지도를 그리기에 좋고, 흐름도는 흐름을 설명하기 좋음. 상태도는 허용·비허용 상태와 전이를 설명하기 좋고, 변수와 상태 표는 가능한 값을 모두 열거하는 데 좋음
  시스템을 그리는 법을 배우는 가장 좋은 방법은 서로 다른 세 사람에게 각자 생각하는 그림을 그려보라고 하는 것임. 같은 생각도 표현 방식이 놀랄 만큼 다양하고, 대부분은 똑같이 타당하지만 주제의 서로 다른 측면을 드러냄. 예술과 비슷함

• 주로 더 형식적인 도식화를 씀. 그래도 화면 공유 중 실시간으로 낙서할 때는 가끔 jspaint를 꺼내고, 나중에 다른 사람이 볼 만한 내용이면 Figjam 같은 것도 씀
  도식화와 가리키기가 잘 통하는 이유는 우리가 가진 가장 오래되고 여전히 유용한 주의 유도 도구이기 때문임. 말하기 전부터 우리는 가리키고 울며, 위치와 탐색에서는 언어보다 가리키기가 훨씬 즉각적이라 레이저 포인터 시장이 계속 남아 있음
  Peter Gårdenfors의 _The Geometry of Meaning: Semantics of Conceptual Spaces_가 이 주제를 꽤 자세히 다룸. Barbara Tversky도 도식화와 인지 공간 구조화 쪽 연구가 많고, Peter Cheng의 “What Constitutes an Effective Representation?”는 효과적인 표현의 기준을 꽤 정량적으로 제시함

• 섀도잉, 페어링, 화이트보드 세션이 좋음. 이때 양쪽 모두 그려야 하고 질문해야 함
  모델을 확장하거나 바꾸는 프로젝트를 함께 고르고 실행하기, 퀴즈, 학습자가 다시 가르치기, 암기하고 손으로 써보기 같은 방법도 있음
  단순 암기는 항상 다른 방법과 함께 써야 하며, 유일한 방법이 되게 하면 안 됨. 화이트보드 밖에서 도식화나 낙서하기, 다른 모델·해결책과 비교하는 간극 분석, 해먹 타임 같은 숙고적이고 반쯤 무의식적인 반성도 도움이 됨

• 전달을 위한 표현과 실제 과업 수행을 위한 표현을 구분해야 한다고 봄. 후자는 여기서 언급되진 않았지만 “실행”에 가까움
  실행 가능한 모델은 전달력이 떨어지는 경우가 많고, 대개 추상화 경계가 나쁘기 때문임. 컴퓨팅에서는 거의 항상 새는 추상화임
  어떤 것이 무엇을 하는지 파악하는 일은, 그것을 효율적으로 하게 만들기 위해 쌓인 노력의 산에 가려질 수 있음. 그래서 냅킨에 끄적이며 “현재 네 정신 모델에 맞는 추상화 수준에서 이 시스템은 이렇게 동작한다”고 설명할 필요가 생김
  문서는 별도의 산출물이라 실행 모델보다 뒤처지는 경향이 있고, 이를 막으려면 매우 공들여 유지해야 함. 더 힘든 방식은 문서를 코드에 직접 결합하거나, 문해 프로그래밍처럼 문서를 코드보다 앞세우는 것임
  그래서 정신 모델을 전달할 때는 대개 최소한의 노력과 유지보수만 들이는 방식, 즉 냅킨 낙서와 시간이 지나며 실제 시스템을 함께 다루는 방식이 맞음
  신입이 설계 문서 작성이 아니라 쉬운 버그 수정으로 시작하는 데는 이유가 있음

  • 이 구분은 Diátaxis가 조금 떠오름. 단순화일 수 있지만, 청중이 시점마다 서로 다른 필요를 가진다는 인식이 핵심이라고 이해함
    신입은 해보면서 배워야 하니 튜토리얼이 가장 알맞을 수 있음. 하지만 어느 정도 손을 댄 뒤에는 몇 가지 오해가 섞여 있을 가능성이 높고, 냅킨 낙서 위의 설명으로 그걸 풀어줄 수 있음
    그래서 튜토리얼을 쓰기로 했다면 “모든 것” 문서를 만들려 하지 말고, 초점이 분명한 좋은 튜토리얼을 써야 함

• 글쓰기가 답임

• 소프트웨어는 개인용 동적 매체라서 꽤 흥미로움
  상호작용 시스템이 도움이 된다고 봄. 예를 들어 Python과 박스 처리된 변수를 가르치는 시각적 디버거 같은 것임