IT's Fun2016.03.09 08:57

근래에 다양한 협업 도구들이 등장하고 있습니다. 업무 환경의 변화에 따라 보다 효율적인 방법을 찾는 사람들이 많아지면서 기존의 이메일이나 개인 사생활 침해의 우려가 있는 메신저보다는 별도의 협업 도구를 이용하는 경우가 많아지고 있습니다. 그 중 단연 가장 많은 사람들에게 관심을 받고 있는 서비스, 도구가 바로 슬랙(Slack)입니다. 슬랙은 태어난지 얼마 되지 않은 서비스이지만 빠른 속도로 사용자를 확보해 나가고 있습니다. 그동안 메세징을 중심으로 팀(Team), 채널(Channel) 단위의 공유(Share) 기능이 제공되 왔는데요, 여기에 보이스 콜(Voice Call) 기능이 추가되며 기존에 다소 아쉬웠던 컨퍼런싱(Conferencing)에 대한 기능 보강이 시작되었습니다.


슬랙이 현재 제공하고 있는 보이스 콜은 모바일 단말에서는 제공되고 있지 않습니다. 윈도우용 클라이언트나 맥용 클라이언트 최신 버전, 그리고 웹 기반으로 슬랙을 이용하는 경우에 이 기능을 활성화하여 사용할 수 있습니다. 본격적으로 보이스 콜이 힘을 발휘하려면 모바일에 대한 지원이 되어야 할텐데요 이 부분들도 현재 로드맵에 잡혀 있기 때문에 조만간 메세징과 보이스를 아우르는 협업툴로 자리메김할 것 같습니다. 참고로 다중 사용자 통화는 유료로 슬랙을 쓰는 경우에만 사용할 수 있습니다. 






먼저 슬랙에서 보이스 콜을 이용하기 위해서는 설명드린 것처럼 최신 버전의 클라이언트가 설치되어야 합니다. 클라이언트의 업데이트과 완료되었다면 슬랙을 실행하고 팀 속성에서 "Team Settings" 메뉴로 진입합니다. Team Settings 는 브라우저 기반이기 때문에 브라우저 탭이 새로 열릴텐데요, 스크롤을 해서 내려가다 보면 "Calls" 라고 표기된 부분을 찾을 수 있습니다. 설명 아랫쪽에 "Enable Calls for this team" 을 활성화하면 해당 팀에 보이스 콜이 활성화 됩니다. 설정을 저장하고 슬랙 클라이언트로 돌아가보겠습니다.




슬랙 협업 공간으로 돌아와보면 슬랙봇이 친절하게도 보이스 콜이 활성화 되었다고 말을 걸어줍니다. 관리자가 보이스 콜을 활성화 했다 하더라도 다른 팀원들은 모를 수 있으니 이에 대한 이야기를 해주라는 깨알같은 가이드에 눈물이 날 지경입니다. 설정이 완료되었으면 이제 실제로 통화 하는 방법을 살펴봐야겠죠? 일반적인 메세징 서비스가 그러하듯 통화는 결국 사용자간에 이루어지게 됩니다. 통화를 하고 싶은 상대방을 선택하고 "Call" 을 누르면 통화를 시도하게 됩니다.








아아 이런. 안타깝게도 제가 통화 품질을 테스트 해보려는 상대방이 아직 최신 버전을 설치하지 않아 통화를 할 수 없다는 메세지를 만나고 말았습니다. 실제 통화 연결을 해보지는 못했지만 협업 도구에 있어서 분명 음성 통화는 중요한 요소가 될 것입니다. 메세징과 자료의 공유로 업무를 진행하고 상황에 대한 이해 수준을 Align 하는 것은 당연히 가능한 일이지만 급박하게 돌아가는 상황에서는 분명 말(Verval)을 이용한 것 만큼 신속한 것도 없을겁니다.


실제로 슬랙을 이용해서 프로젝트를 수행하면서 다자간 음성 통화에 대한 니즈를 해결하기 위하여 라인(LINE)에서 내놓은 팝콘(Popcorn) 서비스를 팀원들과 같이 이용하고 있습니다. 하지만 이제는 슬랙에서 메세징과 파일을 공유하면서 동시에 보이스 콜까지 할 수 있게 되었으니 굳이 다른 서비스를 별도로 이용해야 하는가 라는 생각이 듭니다. 물론 팝콘의 경우 다자간 통화에 최적화 된 서비스이고 무료라는 장점이 있기 때문에 유료로 제공되는 슬랙의 다자간 통화에 대한 약간의 진입 장벽은 없다고 말하진 못할 것 같습니다!



저작자 표시 비영리
신고
Posted by 노피디
짧은 5년의 사회생활을 통해서 제가 배운 것 중 하나가 "너무 완벽하려고 하지마라" 입니다. IT 직종이고 개발과 관련한 일을 하다보니 만들어진 프로그램이 완벽하지 않으면 엔드 유저들로 부터 컴플레인도 많이 받고 높으신 직위에 있는 분들로 부터 협박성(?) 메일도 가끔 받곤 합니다만, 머릿속에는 늘 완벽이라는 글자를 지우려고 노력하는 편입니다.

완벽을 추구하는 것이 절대 나쁜일은 아닙니다. 새로운 프로그램을 설치하거나 서비스를 사용할 때, 아주 세세한 부분까지 적절하게 에러처리가 잘 되어 있고 생각치 못한 부분들에서 친절한 메세지를 만날 때 사용자는 무척 흐뭇함을 느낄겁니다. 흠잡을 곳 없는 완벽한 프로그램을 쓰는 사용자들이 불만을 제기하지는 않겠지요.

시스템을 만들고 구축하다 보면 모든 일은 나 혼자, 내가 만든 시스템이 독립적으로 일하는 경우보다 아닌 경우가 훨씬 많습니다. 다수의 시스템에서 넘어오는 데이터를 합쳐내야 하는 일도 있고, 다시 그런 데이터들을 여러개의 시스템으로 적절히 나누어 주는 일도 심심치 않게 일어납니다. 이러한 대규모의 구축 작업을 할 때는 제 나름의 원칙이 있습니다.

메인 스트림을 먼저 잡자!! 잔탱이들은 품질 향상의 과제이다!!

썩 훌륭해 보이는 문장은 아닙니다. ^^; 헛점이 있는 프로그램을 만든 개발자의 변명처럼 보이기도 하지요? 하지만 전 이게 맞다고 봅니다. 물론 전제조건은 " 잔탱이는 정말 잔탱이스러운 녀석들만 잔탱이인 것이다 " 지만요. 시스템의 큰 흐름이 무리없이 돌아가는지를 먼저 보고, 치명적인 오류처리가 마무리 되면 그 때 부터는 남은 것들은 품질 향상의 과제로 봐야 한다고 생각합니다.

프로젝트는 지켜야 할 것들이 참 많습니다. 개발자 입장에서만 본다면 잘 돌아가는 산출물이 가장 중요한 것이겠지만 매니저 입장에서 보면 일정준수가 아주 중요한 요소입니다. 한정된 일정이라면 "품질" 이라는 것을 더 쪼개어 필수적으로 만족해야할 품질과 우선순위를 좀 미뤄도 괜찮은 품질로 나누는 것이 맞습니다.

말이 참 길어지니 요점이 흐려지는 군요. 정리하겠습니다.

완벽을 위한 완벽은 프로젝트에 약보다는 독이될 수 있습니다. 완벽한 결과가 나오면 참 좋겠지만 여러가지 여건을 고려해서 유도리 있게 하는 것이 더 옳은 방법입니다. 완벽한 결과물을 만들라고 한없이 시간을 주는 사람도 없을 것이고, 사람의 마음이란 늘 조금더, 보다더 완벽한 것을 원하기 때문에 마음에 쏙 들기도 힘듭니다. 최악의 경우는 오랜 노력으로 내 마음에 쏙 드는 완성품이 나왔을 지라도, 보는 사람 마음에 들지 않을 수도 있는 것입니다.

- NoPD -

신고
Posted by 노피디

티스토리 툴바