델리 키포스

정말 오래간만에 블로깅합니다. 트위터나 미투데이를 하면서 블로그에 소홀해진 점도 있지만 지난 4월부터 저희 회사에서 만든 리피(liipii)라는 서비스 개발에 집중하다보니 블로그에 글을 적을 시간이 부족했습니다. 사실 리피를 개발하면서 아이폰 및 레일스 관련 글을 몇개 적긴했지만 내용도 부족하고 정리도 안된 상태라 임시 저장 상태로 봉인해버렸습니다 ;;

리피는 채널(channel) 중심의 소셜 서비스(SNS)입니다. 기존의 트위터나 미투데이와 같은 소셜 서비스들이 개인 중심이라면 리피는 채널 중심입니다. 현재 리피는 아이폰 앱으로 먼저 출시되었으며 빠른 시일 내에 웹 및 모바일 웹 버전을 출시할 예정입니다.

요즘은 많은 분들이 트위터나 미투데이를 사용하지만 아직까지 트위터나 미투데이를 어려워 하시는 분들도 있습니다. 트위터나 미투데이의 가장 큰 단점은 처음 가입했을 때 별로 할 일이 없다는 점입니다. 구독자(follower)나 친구가 없으니 당연히 혼자 놀기를 할 수밖에 없습니다. 많은 경우 혼자 놀다 흥미를 잃어버리곤 합니다. 그러나 소셜시대라는 대세를 거스를 수 없다면 팔로우(follow) 또는 친구 신청 열심히 해야 합니다. 모든 일은 비용이 들기 마련이지만 당장 누군가와 대화하고 싶은데 그럴 수 없다는 것은 매우 안타까운 상황입니다. 바로 이 점이 처음 리피를 기획하게 된 이유였습니다.

처음 만나는 사람들이 쉽게 친해질 수 있는 방법은 공통의 관심사를 찾는 것입니다. 우리는 흔히 모르는 사람(이성이든 동성이든)을 처음 만난 경우 이것저것 내용을 바꿔어 가면서 대화를 하다가 공통으로 좋아하는 주제가 나오면 해당 이야기를 이어가면서 서로 동질감을 느끼고 호감으로 발전해갑니다. 이런 패턴을 관찰하면서 채널을 이란 개념을 만들었습니다. 채널이란 특정 주제에 대해서 대화할 수 있는 공간으로 채팅의 채팅방에서 그 모티브를 가져왔습니다. 리피 안에 다양한 주제의 채널이 열려있고 누구든지 그리고 언제든지 관심이 가는 채널만 찾아 들어가면 공통의 관심사를 가진 사람과 바로 대화할 수 있을 것이라고 생각했습니다.

채팅은 실시간 대화인 반면에 트위터나 미투데이와 같은 소셜 서비스는 실시간이라고 보기는 어렵습니다. 물론 블로그와 같은 서비스와 비교해서 실시간 성이 강하며 스마트 폰의 앱들은 알림(push) 기능을 지원하기 때문에 거의 실시간에 가깝다고 볼 수 있습니다. 실시간 성이란 결국 속도감을 의미하며 속도감은 트위터와 같은 단문 대화 서비스의 핵심적인 요소입니다. 그럼에도 불구하고 트위터나 미투데이는 정확한 의미에서 실시간 서비스가 아닙니다. 그리고 실시간이라고 무조건 좋은 것은 아닙니다. 실시간이라는 것은 많은 집중을 요구하기 때문에 그만큼 사용 부담이 크다는 것을 의미하기도 합니다. 사용 부담이 크다는 것은 결과적으로 사용 빈도가 떨어뜨리는 요인이 됩니다.

아무튼 채팅의 채널이라는 개념을 소셜 서비스에 맞게 바꿀 필요가 있었습니다. 우선 채팅의 입장(join)이라는 개념을 빼버렸습니다. 채널이라는 것이 앱 또는 웹 상에 완전히 열려 있기 때문에 폐쇄적이고 번거로운 입장이라는 개념은 필요하지 않았습니다. 대신 구독(follow) 개념을 추가해서 관심 있는 채널의 대화 내용을 모아볼 수 있도록 기획하였습니다. 마찬가지로 채널이 열려 있기 때문에 누구든지 대화를 올릴 수 있도록 했습니다. 극단적인 경우 대화를 올리지만 구독은 하지 않는 경우도 허용하였습니다.

그리고 채널에 유효 시간이라는 개념을 추가하였습니다. 채팅의 채널은 마지작 참여자가 퇴장(quit)하는 순간 채널이 종료됩니다. 하지만 리피에는 입장이라는 개념이 없기 때문에 퇴장이라는 개념 또한 없으며 결국 채널은 계속 지속될 수 밖에 없습니다. 채널이 계속 지속되는 경우 실시간 성이 떨어지고 결국 속도감도 떨어질 수 밖에 없다고 판단하였습니다. 그래서 채널을 만든 시점부터 24시간 동안만 대화를 올릴 수 있도록 기획했습니다. 24시간이 지나면 더이상 대화를 올릴 수 없기 때문에 최신 대화 순으로 보여지는 타임라인 상에서 해당 채널의 대화는 더이상 노출되지 않게 됩니다. 물론 채널은 열려있기 때문에 언제든지 이전 채널을 찾아들어갈 수 있습니다.

지금까지 채널의 제작 의도에 대해서 정리해보았습니다. 개발하면서 이것거것 고민을 많이 했기 때문에 할 말은 많지만 글이 길어지면 적는 사람도 읽는 사람도 힘들어지기 때문에 이쯤에서 마무리하려 합니다. 아직 못다한 얘기는 다른 주제로 다시 포스팅하도록 하겠습니다.

이 글을 읽는 동안 리피에 대해서 관심이 생기셨다면 꼭! 리피를 써보시기 바랍니다. 리피는 아이폰 앱스토어에서 다운받으실 수 있습니다. 만약 아이폰이 없으시다면 조금만 기다려 주시기 바랍니다. 가능한 빨리 웹 및 모바일 웹 버전을 출시하도록 하겠습니다.

더불어 리피 아이폰 앱 등록 기념 이벤트가 진행중입니다. 많은 참여 부탁드립니다~

liipii, SNS, 리피, 미투데이, 소셜, 아이폰, 채널, 채팅, 트위터

요즘 다른 회사의 프로그래머와 협업할 일이 있어서 작업을 같이 진행하고 있는데 결과물을 보면 참 한심스럽다. 그 사람의 프로그래밍 능력도 문제지만 더 큰 문제는 대화 능력인 듯 하다. 요구 사항이 전달되지 않아 결국 제멋대로 넘어온 결과물을 우리 쪽에서 다시 맞추는 작업할 수 밖에 없다.

흔히들 프로그래머들이 소통 능력이 떨어진다고 한다. 기획자나 디자이너는 작업 흐름 상 자신의 작업이 끝나면 다른 사람에게 자신의 작업물을 넘겨주고 자신의 작업물이 최종 결과물에 잘 반영될 수 있도록 뒷 사람에게 소통을 시도한다. 그러나 프로그래머는 최종 결과물을 만드는 사람들이다(물론 그 뒤에 QA가 있기는 하지만 QA는 결과물을 확인할 뿐이지 제품을 만들지는 않는다). 그래서 프로그래머들은 상대적으로 소통의 필요성을 덜 느끼며 결국 다른 작업자들 보다 소통 능력이 떨어진다.

그러나 모든 프로그래머들의 소통 능력이 떨어지는 것은 아니다. 익스트림 프로그래밍(XP)에서는 프로그래머의 소통 능력을 매우 중요하게 생각한다. 고객과 개발자 간의 소통 능력 뿐만 아니라 프로그래머 간의 소통 능력에 대해서도 매우 중요하게 다루고 있다. 우리 회사에서도 짝-프로그래밍(pair programming)을 하기 때문에 프로그래머의 소통 능력을 매우 중요하게 생각한다. 나아가 짝-프로그래밍을 통해서 프로그래머들의 소통 능력이 많이 향상되고 있다.

대부분의 프로젝트라는 것이 여러 사람의 공동 작업이고 공동 작업에서 가장 중요한 것은 소통이다. 프로젝트 팀 구성원들 간에 얼마나 소통이 원활하냐에 따라 프로젝트 진행 및 결과가 결정된다.

소통을 잘 하는 방법은 간단하다. 잘 듣고 잘 말하면 된다. 우선 상대방이 전달하려는 내용을 잘 들어야 한다. 상대방의 생각을 충분히 이해한 다음 정리된 자신의 생각을 상대방에서 말하면 된다. 우리 팀은 이것을 야구의 캐치볼에 비유하곤 한다. 캐치볼은 2명(일반적으로)이 플레이어가 하나의 공을 주고 받는 행동이다. 공이 하나이기 때문에 내가 공을 받아야 상대방에게 공을 던질 수 있다. 대화도 마찬가지이다. 내가 나의 생각을 말하기 위해서는 상대방의 생각을 들어야 한다.

그리고 공을 던질 때엔 상대방의 가슴을 향해서 던진다. 상대방이 다음 동작을 잘 이어갈 수 있도록 하기 위한 배려이다. 대화도 마찬가지이다. 내가 하고 싶은 말을 아무렇게나 하는 것이 아니라 상대방이 잘 알아들을 수 있도록 최대한 배려해서 말해야 한다. 그러기 위해서 말하기 전에 듣는 사람의 입장을 생각해봐야 한다.

끝으로 상대방이 던진 공이 내 가슴을 향해 날아오지 않으면 내가 움직여야 한다. 상대방이 가슴을 향해서 던지려 해도 사람이기 때문에 원하는 곳을 공이 날아오지 못할 때가 많다. 특히 초보자의 경우엔 더욱 그러하다. 그래서 공을 받는 사람이 움직여야 한다. 만약 움직이지 않으면 캐치볼은 중단된다. 대화도 비슷한다. 상대방의 하는 말이 자신이 것이 아닐 때 감정 상하지 않고 상대방의 생각을 이해하려고 노력해야 한다. 그리고 대화를 계속 이어나아가야 한다.

요즘은 프로그래머들이 블로그나 트위터, 미투데이에서 많은 대화를 시도하고 있다. 하지만 아직까지 내가 경험한 프로그래머 중에는 소통 능력이 떨어지는 사람들이 많다. 인간은 혼자 살 수 없듯이 프로젝트도 혼자할 수 없다.

프로그래머들이여, 오늘부터 캐치볼을 해라!

소통, 익스트림프로그래밍, 캐치볼, 프로그래머

UITableViewCell의 setText 메소드는 아이폰 OS 3.0부터는 비권장(deprecated)하고 있습니다. 따라서 아래의 코드는 3.0 이상인 경우 컴파일은 되지만 경고(warning)이 발생합니다.

1
2
3

UITableViewCell* cell;
// ...
[ cell setText: @"Hello" ];

3.0부터는 textLabel 메소드로부터 반환 받은 UILabel 객체에 텍스트를 설정하도록 변경되었습니다.

1
2
3
4

UITableViewCell* cell;
// ...
UILabel* label = [ cell textLabel ];
[ label setText: @"Hello" ];

이 경우 버전 2.1에서는 컴파일 오류가 발생합니다. 하지만 국내에 출시된 아이폰의 경우 3.1부터 시작하기 때문에 하위 호환 문제는 크게 신경쓰지 않아도 될 듯 합니다.

iphone, 아이폰