심리학자가 알려주는 모든 기획자와 프리젠터가 알아야할 사람에 대한 100가지 사실 독서모임 후기

서론

잠깐 모임이 중지되었던 독서토론 모임이 다시 열렸다. 원래는 개발과 커뮤니케이션 관련 주제였는데, 이번에는 서비스(제품)라는 확장된 주제였다. 회사에서 개발자들과 소통만 하는게 아니라, 다른 직군의 동료들과도 소통 하기 때문에 오히려 좋다고 생각했다. 한가지 아쉬운(?)점은 나는 이제 제품 개발자가 아니라 플랫폼 개발자다. 뭐 이것도 좋게 생각하면 독서토론을 하면서 제품에 대한 감을 잃지 않을 수 있다.

 

본론

이번 모임은 사람이 너무 많았다.. 그래서 좀 부담되었다. 확실히 나는 친하지 않은 많은 사람들 앞에서 얘기하는게 부담된다. 자리도 빈자리 없이 꽉꽉 채워 앉아야했다.

 

아이스브레이킹

이번에도 역시나 아이스브레이킹이 있었다. 이번에는 6명?정도로 조를 나누고 왼손으로 30초씩 돌아가면서 한명의 얼굴을 그렸다. 모든 조원들의 얼굴을 30초동안 자세히 보면서 그림을 그리면서 자연스럽게 긴장이 풀리는 그런 원리라고 한다. 덕분에 내 초상화도 얻을 수 있었다. IT 대기업일수록 아이스브레이킹을 진심으로 한다고 느꼈다. 사람이 많고 팀 이동도 많다보니 자연스럽게 그런 것 같다. 나는 작은 스타트업에 다니다보니 이런 아이스브레이킹을 하는 일 없이 자연스럽게 팀에 적응하는 경험이 많다. 조직마다 다른 선택을 해야하는건 맞지만 한번쯤은 나도 기회가 오면 이런걸 시도해봐야겠다는 생각이 들었다.

 

자기소개

사람이 너무 많다 보니 회사이름을 말하는 것도 조금 부담이 되었다. 회사 이름을 말해서 영업을 했어야했는데 약간 아쉽다.

"통신 도메인의 스타트업에 다니는 프론트엔드 개발자다. 원래는 제품팀에 있었는데 최근에 개발자들의 생산성을 올려주는 플랫폼 팀으로 이동했다. 커뮤니케이션 역량을 올리기 위해 지원했고 모임장이 경력 많은 프론트엔드 개발자라서 신청했다." 정도로 얘기했다.

예전에 스피치 학원에 다닐때 자신감있게 청중들 눈을 보면서 대화해야된다고 했는데 못했다.. 컴퓨터만 보면서 했다. 원형의 테이블이라 시선처리가 어려운 것도 있었고 그냥 부담되어서 그런것도 있었다.

 

이 책에서 꼭 공유하고 싶은 한 줄

아무도 얘기를 안하길래 내가 용기내서 먼저 얘기를 했다. 확실히 처음에 누군가가 뚫어줘야 다른 사람도 편하게 대화할 수 있다. 나는 먼저 나서는 편은 아니지만 누군가 해야된다면 먼저 나서는 편이다.

 

나는 다음 두가지 문장을 얘기했다. 독후감에 적었기 때문에 간단히만 설명을 덧붙이겠다.

 

1. 사람들은 당신이 말한 내용은 잊어버릴지 몰라도 어떤 기분이 들게 했는지는 절대 잊지 않는다.

내가 잘못했던 경험들이 생각나서 너무 두렵다. 앞으로는 더 잘 해야지..

 

2. 사람들은 자기가 실제 처리할 수 있는 것보다 더 많은 선택권과 정보를 원한다.

(제품 관련해서)고객들은 자신들이 원하는게 뭔지 모른다. 원래는 연애, 삶까지 조금 더 확장해서 생각했지만 처음보는 사람들에게 이런 얘기를 하기에는 조금 부끄러웠다. 아마 이런 얘기는 훨씬 가까운 사이에 소수의 사람들과 할 수 있을 것 같다. 아닌가.. 다시 생각해보니 이런것도 부끄러움없이 얘기할 수 있게 바뀌어야하나 싶기도 하다. 내향적이여도 본인의 솔직히 이야기는 할 수 있다. 그리고 솔직함은 내 장점이기도 하다. 나는 커뮤니케이션이라는 단점을 그동안 많이 개선해왔고 이제는 장점으로 가져가려고 한다. 그리고 솔직함이라는 장점을 커뮤니케이션과 연결시켜서 더욱 시너지를 낼 수 있을 것 같다. 어렵지만.. 다음 모임에는 이런 기회가 있으면 시도해봐야겠다.

 

슬렉 예시

모임장님이 슬렉의 특정 케이스의 ui ux에 대한 예시를 들었다. 다이렉트 메세지에서 x를 누르면 left panel에서 사라지는데 특정 메세지를 입력하고 보내지 않은 경우는 x버튼이 노출되지 않고 입력중 버튼이 노출된다. 그래서 dm을 지우기가 너무 불편하다고 했다.

사실.. 나는 해당 케이스에는 슬렉처럼 하는게 맞다고 생각했다. 근데 왜 거기서 불편함을 느꼈는지는 알 수 있었다. 나는 dm을 자주 사용하지 않고 모임장님은 dm을 자주 사용한다. 거기서 사용성의 차이가 나타났다. 뭐 물론 입력중과 x버튼을 둘다 노출시켜주면 해결되는 문제긴 하다. 근데 그건 또 다른 문제를 야기한다. 정답이 뭐라고 정의할수는 없다.

그래서 ux가 어렵다. 사람들마다 좋고 나쁜 사용성이 다르다. 모든 사람의 니즈를 충족시킬수는 없다.

 

모임장님은 여기서 3가지 원칙을 얘기했다.

 - 내가 틀릴수있다.

- 완벽한 이유가 있어야한다.

- 최대한 빨리 원복할 수 있는 방법을 만들어라.

 

원복에 대한 얘기를 할 때는 카나리배포를 얘기했는데 AB테스트는 왜 얘기를 안했을까? 라는 생각이 들었다. 버그가 문제되는 경우라면 카나리배포를 하는게 맞는데 ui ux 관련된 거라면 AB 테스트 비율을 조정하는거로도 충분하지 않나? 뭐 어쨋든 두가지는 how to 에 대한 영역일뿐이다. 그렇게 얘기한다면 피쳐플래그 등의 개념까지 확장할 수 있다.

 

공리주의

조금 더 나아간다면 나는 공리주의에 대한 생각도 든다. 어차피 모든 유저가 원하는 최선의 UI UX를 보여줄 수는 없다. 그래서 AB테스트로 전환율을 확인하고 높은 전환율을 보이는 기능을 선택한다. 물론 이해관계에 대한 문제가 있을 때는 소수의 편의를 선택하기도 한다.

요즘엔 UI를 유저가 원하는대로 직접 커스텀할 수 있게 만들어줘야한다는 얘기도 나오는 것 같다. 내 생각엔 대다수의 일반 유저들은 그렇게 복잡한 설정을 원하지 않는다.(B2B는 조금 얘기가 다르다.) 결국 UI 커스텀도 많아야 2,3가지 레이아웃정도고 결국 누군가는 만족하지 못하는 UI UX를 선택해서 찍고 가야한다. 소수를 존중하지 않겠다는 얘기는 아니지만 여전히 공리주의는 유의미한 것 같다.

90%의 유저들은 10%만큼 편해졌고 10%의 유저들은 30%만큼 불편해졌다고 가정하자. 그리고 90%의 유저들은 전환율이 7%올랐고 10% 유저들은 전환율이 30%떨어졌다. 이러면 전체 유저로 봤을 때는 이득일 수 있다. 이후에 10% 유저들을 챙기기 위한 개선 작업을 할 수도 있지만 세상에는 양자택일로 선택할 수 밖에 없는 순간들이 있다.

 

AI는 통계고 평균이다. 잘하지 않는다.

모임장님이 지라같은 서비스를 개발한걸 보여줬다. 꽤 페이지가 많았는데 얼마나 걸렸게? 라고 물어봤다. 프롬프트를 가다듬는데는 하루정도 걸렸지만 실제 그 이후 개발은 2시간?정도 걸렸다고 했다. 사실 아주 놀랍지는 않다. 단순히 기능 개발한건 아무 의미 없다. 그게 유지보수 가능한 아키텍쳐인지, 사용자에게 wow할 포인트, 취향을 저격할 부분이 있는지 이런것들이 더 중요하다. AI는 이미 너무나도 발전했다. 사내에서도 비개발자들이 꽤 멋진 개발 결과를 보일때가 있다. 그리고 모임장님도 얘기했다. 평균정도를 하는거지 잘하지는 않는다고. 매우 공감한다. 몇시간만에 개발했는지도 중요하지만 그걸로 어떤 가치를 줄 수 있는가, 수익을 낼 수 있는가가 뒷받침되지 않는다면 무의미하다.

 

기능은 넣는것보다 빼는게 어렵다.

책에서 "상실의 두려움이 획득의 기대보다 크다." 라는 얘기가 나온다. 거기서 한 멤버(?)분이 기능은 넣는것보다 빼는게 어렵다는 얘기를 했다. 지금 회사에서 엄청 크게 느낀 부분이다. 넣는건 어렵지 않은데 빼는건 정말 어렵다.. 여러 이해관계자들을 설득해야하고 고객들의 불편함까지 감수해야한다. 빠르게 AB테스트로 검증하고 배포하고 이후에 불필요해진다면 빠르게 다시 제거하는게 이상적인 그림인줄알았다. 그런데 배포까지는 쉬운데 제거가 어렵다. 이걸 잘 하려면 어떻게 해야할까? 반대로 너무 고민하면 속도가 느려진다. 결국엔 결정의 문제다. 현재 팀의 상황에 맞는 온도감으로 속도와 안정성을 결정해야한다.

 

소모임

시간이 부족해서 소모임할시간이 조금 부족했다. 커뮤니케이션 관련 이슈에 대해 발표를 해야했다.

우리조에서는 회의가 길다, 업무 기대가 다르다 등의 얘기가 나왔다. 이슈 정의가 한줄이면 하나로 명확히해야되는데 여러가지를 포괄하려다 보니 이슈 정의가 명확하게 되지 않았다고 느꼈다. 뭔가 더 잘 해보고 싶은데 처음 보는 사람들이기도 하고 나도 뾰족하게 하나를 확정하기가 어려워서 조금 어려움이 있었다. 

 

그에 비해 내일 할일, 다음달에 할일은 꽤 쉽게 정할 수 있었다. 왜냐면 나는 이 정답을 알고 있었으니까 ㅎㅎ

체크리스트를 만들고 이걸 템플릿화하면 된다. 이전 독서토론에서 체크리스트에 대한 얘기를 하기도 했고, 사내에서도 이런 체크리스트 기반의 템플릿을 자주 사용해서 쉽게 떠올릴 수 있었다.

 

결정이 이루어지지 않은 상황에서 발표를 해야됐는데 어쩌다보니 다른 멤버가 처음에 발표를 하다가 자연스럽게 나에게 넘겨줬다.. 다행히 내가 제시한 템플릿, 체크리스트 관련 내용이라서 그럭저럭 나쁘지 않게 발표를 했다. 좀 즉흥적으로 해서 기록된 내용도 없고 시간이 지나서 잘 기억이 안나지만 기억나는 정도로만 적어보겠다.

 

"회의가 길어지는 경우는 명확합니다. 딴 얘기로 흘러가는 경우, 사전 준비를 안해온 경우 등등. 시작전에 읽을 체크리스트, 종료후에 회고할 체크리스트 정도만 있어도 같은 실수를 반복하지 않습니다. 그리고 이걸 템플릿화하면 모든 회의를 효율적으로 할 수 있습니다.

한 달 후에 이 템플릿이 어떤 점이 좋았고 어떤 문제가 있었는지 회고하는 피드백 루프를 돌리면 점점 좋은 회의를 할 수 있게 됩니다."

 

모임장님의 조언

모임장님은 우리들의 발표를 듣고 다 잘 말해서 크게 할말이 없다고 했다. 특히 내가 얘가한 체크리스트와 템플릿 관련해서도 좋은 방법이라고 얘기했다. 그리고 회의 목적을 똑바로 정하면 좋다고 했다.

목적 없는 회의가 필요할때가 있지 않을까? 라고 생각을 했는데 조금 더 생각해보니 아닌 것 같다. 모호한 회의라고 하더라도 목적은 있어야한다. 밑에서도 얘기하지만 결정하지 않아도 좋다. 하지만 목적만큼은 명확해야한다.

 

1. 설명하는건지, 결정하는건지 명확히 해라.

나를 되돌아봤는데 이걸 제대로 못한 경험이 있다. 설명하면 설명만하고, 결정해야하면 결정을 해야했다. 그리고 둘 다 필요하다면 설명후에 결정해야한다고 말하면 된다. 객관적인 사실과, 나의 주관적 의견을 얘기한 이후에 팀원들과 공동의 결정을 해야하는 경우도 있다. 이런 경우는 어떻게 해야할까? 나라면 섹션별로 명확히 끊어서 얘기할 것 같다. 책에서 현재 프레젠테이션의 진행도를 알려주면 좋다고 했는데 회의도 똑같다. 그리고 모임에서 얘기하진 않았지만 내 의견을 명확히 하는 것도 도움이 될 것 같다. 이것도 좋고 저것도 좋아요는 결정을 힘들게 한다. 특히 회의 주최자가 해당 안건에 대해 가장 잘 알기 때문에 주최자가 망설이면 다른 동료들은 더 결정하기 힘들다.(사실 예전에 관련된 내용을 피드백받은 경험이 있다.)

 

2. 오래걸리는 건지.

책에서도 나오는데 정해진 시간내에 끝내는게 가장 좋다. 여기서부터는 모임장님의 얘기가 기억이 안나서 내 생각이다. 긴 회의는 기본적으로 좋지 않다. 다만, 아무리 잘 진행되어도 길어질 수 밖에 없는 회의들이 있기 마련이다. 이럴땐 잠깐의 휴식이 도움이 될 수 있다.

 

오늘의 멤버

오늘의 멤버라는걸 뽑았는데 공동 1등에 뽑혔다. 그리고 가위바위보에 이겨서 모임장님에게 책도 한권 받았다. 그냥 한마디씩 했는데 오늘의 멤버에 뽑힌걸 보니 나쁘지 않았나? 라는 생각도 든다. 아직 커뮤니케이션이 아쉬운 부분이 많은데 그래도 이제는 어느정도는 올라왔나 싶은 생각이 들기도 한다. 다음에도 오늘의 멤버에 뽑힐 수 있게 열심히 해봐야겠다!