IT's Fun/Slack2016.09.21 18:26

# 정말 이메일이 최고야?

 

회사 업무 등 공적인 영역에서의 의사 소통은 전자 메일이 중심이고 메시징 서비스가 보완해주는 형태가 많습니다. 전자 메일은 인터넷 서비스 중 가장 오래된 축에 속하며 여전히 의사소통의 중심에 있습니다. 거기에는 여러 이유가 있겠지만 기업이나 이해 당사자 간에 기록을 남길 수 있다는 것이 가장 큰 이유입니다. 이는 단일 기업 내에서도 적용되어, 흩어져 있는 지사/사무실 간의 기본적인 정보 교환 방법으로 자리 잡으면서 그 사용량이 지속적으로 증가하고 있습니다. 

 

하지만 이메일은 기술적, 태생적 제약 사항으로 “효과적인 의사 소통 수단인가”의 관점에서 많은 질문과 도전을 받고 있습니다. 

 

전자메일은 수신자, 참조자, 비밀 참조자와 같은 항목으로 메일 콘텐츠를 받을 사람을 지정하는데, 여기에서부터 효율성의 문제가 생깁니다. 콘텐츠를 받는 사람은 발신자에 의하여 임의로 지정됩니다. 보통은 개인 메일 주소가 나열되겠지만 때로는 그룹 메일 주소가 추가되기도 합니다. 발송된 메일은 메일을 받은 사람이 다시 회신(Reply)하거나 포워딩(Forwarding)하면서 급격하게 퍼집니다. 

 

이렇게 메일을 여러 번 재생산하면 사람들은 “읽지 않은 메일”의 홍수에 휩쓸리게 됩니다. 정작 중요한 일이 무엇인지 어떤 작업을 누가 해야 하는 것인지 모호해지는 것입니다. 누군가 나서서 “자, 지금까지 나온 내용을 정리하자면…” 하고 요약하지 않는다면 길게 늘어진 메일을 처음부터 읽으면서 히스토리를 정리하고 이해해야 하는 상황에 빠집니다. 

 


 

이런 문제가 발생하는 이유는 전자 메일이 애초부터 무언가를 정리하고 이력을 관리하고 하는 목적에는 적당하지 않은 방식이기 때문입니다. 회신과 포워딩은 왠지 멋있어 보이는 말이지만 실상은 그렇지 않습니다. 이전의 콘텐츠를 밑에 붙이고 그 위에 새로운 콘텐츠를 얹어서 새로운 콘텐츠를 하나 더 만드는 방법에 불과합니다. 불행하게도 누군가 전체 회신으로 메일을 쓰는 동안 또 다른 사람이 전체 회신으로 메일을 보냈다면 메일 스레드는 두 개가 됩니다. 물론 혼란도 두 배가 되는 것이지요. 

 

다양한 도구로 의사소통하는 목적은 소통에 드는 비용을 줄이고 의사 결정과 행동을 빨리하기 위함입니다. 그런데 전자 메일을 과도하게 사용하면 그런 목적에 어긋나게 됩니다. 이런 상황에서 정보 공유를 신속히 하겠다며 메시징 서비스까지 곁들여 놓으면 메시지로 주고받은 내용을 메일에 붙여 넣고, 다시 메일을 파일로 추출한 뒤 메시징 서비스로 공유하는 웃지 못할 상황에 이르기도 합니다. 시간 외 업무와 개인 프라이버시 이슈까지 겹치면서 바야흐로 사람들은 이런 상황을 해소해줄 수 있는 무언가를 찾기 시작했습니다.

 

 

# 게임은 망했으나 슬랙은 남았다

 

슬랙 창업자 - 스튜어드 버터필드 (출처 : 비즈니스 인사이더)


 

스튜어드 버터필드(Stewart Butterfield)는 유명한 사진 공유 서비스인 플릭커(Flickr)를 만들고 야후(Yahoo!)에 매각했던 것으로 유명합니다. 그는 게임사 타이니 스펙(Tiny Speck)을 설립해 글릿치(Glitch)라는 게임을 개발하고 있었습니다. 여기저기 흩어져 있는 개발자가 원격으로 협업하면서 게임을 개발하고 있었기 때문에 정보 공유, 의사소통이 중요할 수밖에 없었습니다. 

 

메시징 서비스가 제공하는 인스턴트 메시징 기능도, 개발한 코드를 전달하고 자료를 공유하는 기능도 필요했습니다. 그러면서도 불필요한 커뮤니케이션을 줄일 필요도 있었습니다. 하지만 널리 사용되는 도구와 애플리케이션을 이용해 보았지만 썩 마음에 들지 않았습니다. 결국 스스로 필요한 기능들을 만들어 내부 도구로 활용하기 시작했습니다. 안타깝게도 개발하던 게임은 성공하지 못했지만 내부 커뮤니케이션 도구를 별도의 서비스, 애플리케이션으로 진화시키기 시작했습니다. 이렇게 탄생한 도구가 바로 슬랙(Slack)입니다. 


이 글은 "한빛출판네트워크"의 "기획연재"에 기고중인 NoPD 의 글입니다.

연재중인 글은 [이곳에서] 확인하실 수 있습니다!



저작자 표시 비영리
신고
Posted by 노피디

세상에 있는 직업들을 나누는 방법은 여러가지가 있을 수 있다. 그 어떤 직업이 끊임없는 노력 없이 쉽게 얻을 수 있겠냐만은, ‘지속적인 학습이라는 관점에서 직업을 나누어 보자면 개발자는 죽는 그 날까지 공부해야만 하는 직업에 속하지 않을까? 매일 아침 눈을 떠 보면 어제 없던 수많은 프로그래밍 언어 기술들이 인터넷을 장식하고 있는가 하면 그 동안 있는 힘을 다해 갈고 닦은 코딩 스킬이 조용히 사람들의 관심에서 멀어져 가는 것도 심심치 않게 볼 수 있다는 것은 개발자의 직업 분류가 아주 적절(?)하다는 반증이다.

 

끊임없는 스킬업, 개발자의 숙명

 

이렇듯 상황이 결코 쉽지 않다 보니 눈을 뜨고 있는 동안 정신없이 새로운 것을 받아들이고 따라가는 게 일상이 되버린지 오래다. 새로운 프로그래밍 스킬에 대하여 지인과 토론을 하고 블로그 스피어 에서 갑론을박을 거듭하면는 과정을 통해 어느새 새로운 테크닉에 심취해 있는 나를 발견하곤 한다. 새로운 프로젝트의 시작은 그 동안 강호에서 갈고 닦은 스킬을 시험해 볼 수 있는 좋은 테스트 배드라고 생각되는 건 어찌보면 당연한 일인지도 모르겠다.

이러한 프로그래밍 스킬을 업그레이드 하기 위한 기본은 바로 자신이 다루는 프로그래밍 언어의 동작 원리를 이해하고 아키텍쳐를 내것으로 만드는 것이다. 우리가 바라보는 프로그래밍 언어의 기교적인 측면보다 이면에 깔려있는 기본을 제대로 이해하는 것이 필요하다는 이야기이다.

 

의사소통의 중요성

 

그런데, 헤아릴 수 없이 많은 시간과 노력을 통하여 고수 혹은 준고수에 이른 개발자들에게도 부족한 언어 스킬이 있으니, 이는 바로 사람의 언어이다. 개발자가 아름다운 로직만 만들고 다양한 기술을 이용하여 효과적이고 탄탄한 코드만 만들면 되지 사람의 언어까지 잘 해야 한다는 것은 무슨 궤변이냐고 하고 싶은 사람이 참 많을 것이다. 하지만, 아무리 뛰어난 무림의 고수라 할지라도 결국 고객 혹은 협업하는 사람과의 의사소통에 실패하면 결코 고수가 아니라고 생각한다. IT 라는 것이 사람이 편하기 위한 도구이고 현실의 사람과 동떨어져 생각할 수 없는 것이라는 점을 생각해 보면 왜 의사소통이 중요한지는 두 번 이야기 하지 않아도 알 수 있다.

 

논리적인 의사전달

 

개발 기간이 길고 중요한 데이터를 다루는 프로젝트 일수록 세밀한 테스트와 데이터 점검이 필수적이다. 첫 단추부터 잘못 끼워 프로젝트 말미에 회복이 불가능한 상태로 가지 않기 위해서다. 복잡한 시스템과 어플리케이션을 여러 사람이 함께 디버깅 하다 보면 예상치 못한 결과로 티격태격 하는 일이 왕왕 생기곤 한다. 실력이 출중한 사람이야 어렵지 않게 문제를 해결할 수 있겠지만 협업에서 보다 중요한 것은 다른 사람도 문제의 원인을 정확히 알고 유사한 상황에 대비할 수 있게 케이스를 공유하도록 해야 한다는 점이다. 특히나 고객과 함께 프로젝트를 하는 경우라면 보다 쉽고 논리적인 말로 고객에게 설명하고 상황을 이해시켜야만 한다.

 

사람의 언어스킬을 키우자

 

안그래도 할 것 많은 개발자들에게 대화의 능력까지 키우라는 게 부담이 되는 말이 될지도 모르겠다. 하지만, 옛말에 말 한마디로 천냥 빚을 갑는다라고 하지 않았던가? 어렵사리 구현하는 것보다 프로세스의 개선, 기존 작업 형태의 변경으로 쉽게 해결할 수 있는 일들도 얼마든지 많다. 개발자는 코드로 이야기 해야 한다는 말이 있긴 하지만, 때로는 사람과 사람의 대화로 보다 쉽게 해결할 수 있는 문제도 많다는 것을 인지하고 대화를 위한 사람의 언어스킬을 키우는 것도 우리의 목표로 삼는 것은 어떨까?


* 이 글은 월간 마이크로소프트웨어 2008년 7월호에 기고했던 내용을 편집한 글 입니다

- NoPD -
신고
Posted by 노피디
IT's Fun2008.04.02 13:59
사용자 삽입 이미지
요즘 이런저런 이슈가 많아서 그런가? 한동안 뜨겁게 블로그 스피어를 달구던 마이크로소프트의 OOXML이 ISO 표준으로 승인되었다는 기사들이 여기저기서 보인다. 지난 1주일동안 승인 확실시에 대한 글들과 차니님의 변심(?)에 대한 이런저런 글들이 오가긴 했으나 포기상태로 접어든 것인지 큰 반향은 보이지 않는 것 같다.

사실, 오피스에 대해 큰 관계도 가지고 있지 않고 표준이 무엇이 되든 내가 원하는 자료를 만들고 누군가에게 배포해서 볼 수만 있으면 된다라는 입장인 NoPD는 OOXML이든 ODF든 사용자에게 편리한 환경을 제공해 주기만 한다면 좋다고 본다. 그냥 NOPD에겐 '도구일 뿐' 이기 때문에...

이제 해야할 일은 악법도 법이니 그냥 따른다가 아니라 ODF든 OOXML이든 전 인류가(?) 서로 의사소통을 하는데 있어서 문제가 생기지 않게 더 높은 호환성을 제공하고 내 의사표현이 문제없이 전달할수 있는 "도구"를 만들 수 있도록 지켜보고 째려보고 갈구는(?) 일을 해야한다. MS도 OOXML이 표준으로 채택된 만큼 보다 많은 사람들이 응용할 수 있도록 지속적인 노력에 경주해 주었으면 하는 바램이다.

두개의 태양. 언제까지 지속될지 모르는 두개의 태양.
누군가는 도태되겠지...

- NoPD -
신고
Posted by 노피디

티스토리 툴바