채팅 스레드 출시!

말씀을 시작하기에 앞서, 채팅형 커뮤니케이션을 소비하는 누구에게나 다소 상식적인 사실을 인정하고 싶습니다. 바로 채팅은 매우 주관적이며, 수많은 옵션 중 하나를 고르는 경우라면 '정답’을 찾는 것은 사실상 불가능하다는 점입니다.

저는 채팅 스레딩을 두 가지 범주로 나눕니다: 서브스페이스(sub-spaces)와 인라인(inline).

서브스페이스 형식을 따르는 플랫폼은 누군가 메시지를 답글로 달면 '포켓’을 생성하며, 모든 답글은 이 포켓 안에 유지됩니다. 누군가가 클릭하여 참여하지 않는 한 화면에 표시되지 않습니다. 많은 사람들이 Slack에서 이 방식을 익혔을 것이며, 저는 Discourse의 채팅 기능에 내장된 솔루션도 이 범주에 속한다고 분류합니다.

인라인 답글은 모든 응답을 메인 채팅 스레드에 유지하고, 링크/앵커를 통해 이전 메시지를 가리킵니다. 여기에는 두 가지 변형이 있습니다: 인용 텍스트가 있는 경우와 없는 경우입니다. 인용 텍스트가 있는 예로는 Discord(전체 인용이 아닌 발췌문을 사용)나 Apple 기기의 Messages가 있습니다. Discord는 현재 형식으로 전환하기 전에 인용 없는 인라인 답글을 사용했습니다. 인용 없는 인라인 답글의 다른 예로는 Stack Exchange / Stack Overflow의 Chat 기능이 있습니다.

두 방식 모두 유효하며 각자 용도가 있고, 서로가 만드는 문제를 서로가 어느 정도 '해결’하는 경향이 있습니다.

  • 저는 서브스페이스 포켓이…
    • + 측면적인 사고의 흐름을 포함하거나, 메인 토론에서 벗어나지 않으면서 특정 주제에 대해 깊이 파고들 수 있는 훌륭한 방식이 될 수 있다고 생각합니다.
    • + 이러한 분산된 논의를 깔끔하게 유지하여 따라가기 쉽게 하지만,
    • - 포켓은 채팅이 이미 다른 주제로 넘어간 후에도 쉽게 놓칠 수 있습니다.
    • - 분기된 내용을 봐야 할 사람들을 꼭 태그(ping)하도록 하는 것이 더 중요합니다.
  • 인라인 채팅의 경우 반대입니다…
    • - 모든 것이 인라인으로 표시되므로, 분산된 논의로 인해 채팅이 어긋나기 쉽습니다.
    • - 동시에 여러 가지 논의 흐름을 따라가기 혼란스러울 수 있습니다.
    • + 모든 것이 인라인으로 표시되므로, 서브스페이스에서 일어나는 일을 놓칠 일이 없습니다.
    • + 사용자가 특정 사람에게 답글을 태그하도록 해야 한다는 점을 크게 고민하지 않아도 됩니다.

수년간 Slack과 Discord를 사용해 온 사용자로서, 저는 '정답’은 아마도 어떤 개발자도 듣고 싶어 하지 않는 것일 거라고 주장합니다. 바로 두 가지를 모두 갖추는 것입니다. 제가 선호하는 방식을 결정하는 가장 큰 요인(제 기준에서)은 다음과 같습니다:

  1. 채팅에 몇 명의 사람이 관여하는지, 또는 얼마나 바쁜지.
    • 한 사람과 채팅 중이거나 활동이 많지 않을 때, 제가 원하는 것은 인라인 답글뿐입니다. 2~3명의 다른 사람과 함께 있어도 서브스페이스는 필요하지 않습니다. 두 사람 사이의 Slack DM에서 서브스페이스를 사용할 때 얼마나 짜증이 났는지 헤아릴 수 없을 정도입니다.
    • 많은 참여자가 있고 메시지가 빠르게 오가는 공간에 있으면, 특히 사람들이 답글 기능을 대충 사용할 때, 인라인 대화를 따라가기 훨씬 더 어려워집니다.
  2. 모든 것을 보고 싶거나 알아야 할 필요가 얼마나 큰지.
    • Slack 채널에서 지원 역할을 맡고 있다면, 서브스페이스는 채널을 정리하여 빠르게 훑어볼 수 있게 해줍니다.
    • 스레드에 묻혀 있는 것을 놓치면 안 되는 공간에 있다면, 인라인 답글을 선호합니다. FOMO(놓칠까 봐 두려운 마음)는 실재합니다, 친구들이여!
  3. 스레드가 얼마나 ‘깊어지는지’.
    • 질문 뒤에 수십 개 또는 심지어 수백 개의 응답이 따르는 경향이 있는 채널은 서브스페이스여야 합니다.
    • 메시지당 응답이 매우 적은 경향이 있는 채널은 보통 인라인으로 작동하는 것이 더 좋습니다.
  4. 내가 누구인지/무엇에 익숙한지.
    • 서브스페이스를 싫어하는 정도가 심해서 이를 제거하는 Slack 스크립트를 만든 사람을 알고 있습니다.
    • 팀이 Slack 채널에서 매번 서브스페이스 스레드를 사용해야 한다고 엄격하게 주장하고, 그렇지 않을 때 약간 투덜거리는 사람들을 알고 있습니다.

이 모든 것은 일률적인(또는 대부분에게 맞는) 해결책이 없다는 것을 의미합니다. 저는 다른 Discourse 인스턴스에서 1:1 채팅을 하다가 스레딩 방식의 선택을 보고 놀랐으며, 정말로 스레드를 피할 수 있기를 바랐기 때문에 이 메타 포스트를 찾게 되었습니다.

두 옵션을 모두 제공하기를 고려하신다면 몇 가지 아이디어를 제안합니다:

  • 사용자가 전역적으로 또는 채팅별로 선호하는 스타일을 선택할 수 있는 사용자 설정을 고려해 보세요.
  • ‘자동으로’ 어떤 형식을 사용할지 결정할 때 채팅 공간의 사용자 수, 메시지 빈도, 평균 답글 깊이를 고려해 보세요. 예를 들어, 체인 내 답글이 특정 숫자에 도달하거나 사용자가 "답글을 스레드로 변환"을 표시할 때까지 인라인을 사용하는 것입니다.
  • "어제/지난주 무언가에 대한 새 답글 스레드를 만들고 있다"는 상황을 고려하고, 답글을 표시하는 것이(또는 Slack처럼 응답자가 답글을 인라인으로 게시하도록 허용하는 것이) 합리적인지 생각해 보세요.

현재 가지고 있는 것은 괜찮다고 생각하지만, 이 기능이 앞으로 나아가면서 이 두 가지 명확한 방법론 사이의 장벽을 흐리게 하는 것을 Discourse가 고려해 주기를 바랍니다.

7개의 좋아요