구글(:12)을 통해 배우는 효과적인회의

비지니스가 주제이든지 개발(:12)이 주제이든지 간에 의도하지 않았음에도 불구하고 회으는 "지긋지긋한", "끝이 없는 마라톤 경주"가 되는 일이 많다. 그나마 업무시간내에 끝나면 천만다행이련만, 업무시간을 훌쩍 넘겨서 진행되면 정말 짜증이다. 더욱 문제는 무슨 이유에서인지는 모르겠지만 이 회의란 것이 업무시간 끝나기 10분 전에 시작된다는 점이다. 아마도 회의를 업무시간에 하는건 낭비라고 생각하기 때문이 아닐까 ?

어쨋든 지긋지긋 하다고 하지만 회의는 반드시 필요하다. 개발자가 하는 회의는 프로젝트의 방향을 명확히 해주고, 일어날수 있는 문제를 미리 파악하도록 도와주며, 서로의 의사소통을 원할히 함으로써 더 좋은 해법을 더 빨리 찾도록 도와준다. 안타깝게도 회의가 진행되는 도중에 반상회가 되어버리는게 문제지, 회의는 반드시 필요하다. 그렇다면 회의를 회의답게 만들어야 할 것이다. 그래서 구글에서 사용하고 있는 회의의 6가지 원칙에 대해서 살펴보기로 했다.

1. 주제를 명확히 하라.

회의는 중요한 업무중 하나다. 모든 업무가 그렇듯이 회의를 하기전에 분명한 계획을 세운다. 이 계획표에는 회의에서 다루어질 주제와 참석인원 시간을 명시하며, 계획표는 참가자 전원이 공유해서 미리 준비할 수 있도록 한다.

2. 필기할 사람을 정한다.

구글은 회의를 진행할때 회의 내용을 필기할 사람을 지정한다. 필기자는 회의 내용을 필기하는데, 그 내용은 프로젝터를 통해서 모두가 볼 수 있도록 한다. 중요한 내용이 빠지거나, 의도를 잘못 이해하고 내용을 적을 수 있기 때문이다. 기껏 회의를 끝마치고 났더니, 중요한 내용을 서로 공유하지 못하거나, 의도를 잘못 이해해서 프로젝트가 산으로 가는 일을 막을 수 있다.

회의가 끝난 후에는 필기된 내용을 간단하게 리뷰한다.

3. 작은 미팅을 가진다.

주요 주제를 가지고 미팅을 하기전에 독립적으로 진행할 수 있는 작은 주제들에 대해서 5분이나 10분이내의 짧은 회의를 가진다. 이 정도의 회의는 짜투리 시간을 내는 정도로 끝낼 수 있으므로 업무흐름에 방해를 주지 않는다. 또한 주요 주제에 대해 더 많은 이해를 가질 수 있으므로, 주요 회의에 대한 더 좋은 계획이 가능해 진다.

4. 업무시간을 지킨다.

말이 필요없다. 업무시간을 넘겨서 회의를 하게 될경우, 집중력이 떨어지고 산만해진다. 배도고프고, 약속도 있고, 친구도 만나고 싶고, 얼렁 집에 가고 싶은 마음들 때문이다. 그런데도 왜 대부분의 회의는 업무시간 끝날 즘에 시작되는 걸까.!!

5. 데이터를 활용하라.

주제에 대해서 토론하는데, 주관적인(혹은 정치적인) 호불호를 배제하고, 데이터를 활용하라. 이렇게 하는게 좋은거 같다 식의 막연한 주장에는 회사의 정치적 구도, 특정 개인에 대한 감정등이 개입될 수 있다. 이런 시스템 구성을 할경우 10%의 성능향상을 기대할 수 있습니다. 라는 식으로 데이터를 제시하도록 한다.

6. 시간을 정하라.

구글은 모든 회의실 벽에 커다란 타이머가 부착되어 있다. 회의가 시작되면 타이머가 작동 한다. 회의 참가자들은 시간에 부담을 가지게 되므로 주제에 집중하게 된다. 잡담으로 시간을 보내거나, 별로 중요하지 않는 문제로 감정싸움까지 가는 문제를 피할 수 있다. 첨언하자면 회의 시간을 줄이기 위해서는 원탁에 동일한 수준의 의자를 배치해야 한다. 리더를 위한 특별한 의자는 안락한 환경에서 거드름을 피우며 잡담을 하게되는 빌미를 주게된다.


이상 구글에서 사용되고 있는 회의의 6원칙에 대해서 알아보았다. 다들 알만한 그러 내용들이지만, 역시 지켜지지 않는게 문제다. 당장 모든 원칙을 적용하긴 힘들겠지만 몇개씩 적용하기위해서 노력하면서 회의문화를 만들어가 보도록 하자.

교양있는 바보가 회의시간에 정치를 논한다.

유닉스의 각 설비에서 데이터 seek효율성

간단한 데이터 베이스를 만든다고 가정했을 때, 원하는 데이터의 위치를 찾기 위한 seek 과정은 프로그램의 속도성능을 결정짓는 중요한 요소다.

그래서 이에 대한 테스트를 해보기로 했다. 테스트는 유닉스 설비별로 이루어질 것이다.

1. 메모리
2. 메모리맵(MM)
3. 파일
4. 공유메모리

상식적으로 생각해 봤을 때, 메모리에서 연산하는게 가장 빠르겠지만, 이 경우 많은 메모리를 사용해야 한다는 단점이 있다. 파일 같은 경우는 저장이 용이하고 메모리 사용이 상대적으로 적다는 장점이 있지만 Disk I/O가 문제가 될것이다. 공유메모리의 경우 커널에서 관리하므로 빠르게 사용할 수 있다는 장점이 있을 거 같지만, 커널 메모리를 사용할 경우 다른 자원에 비해서 제약이 크다는 단점이 있을 것이다. 메모리 맵도 마찬가지로 장단점을 가지고 있을 것이다.

결 국 속도 우선인지, 메모리 우선인지 그리고 각 방법을 선택했을 때, 다른 방법을 선택했을 때보다 그만큼의 이익을 얻을 수 있는지에 대한 판단을 해야 하고, 이 문서는 이러한 판단에 근거를 만들기 위한 데이터의 수집을 목적으로 작성되었다.

테스트 시나리오

다음과 같은 고정된 크기를 가지는 구조체를 포함하는 배열을 만든다.

struct data { int did; int score; };

배열의 크기는 10,000,000개로 9Mbyte 정도의 크기를 가지게 될 것이다. 이렇게 만들어진 데이터를 파일, 메모리, 공유메모리(:12), 메모리맵에 적재하고 seek(2)에 걸리는 시간을 검사한다.

Memory 우선 사용 테스트

malloc(:3)을 이용해서 천만개의 메모리를 할당하고 여기에서 값을 읽어들이는데 걸리는 시간을 테스트 했다. 10000*1, 10000*2, 10000*3,..., 10000*n으로 데이터를 읽어들였다.

#include
#include
#include
#include
#include
#include
#include
#include

struct data
{
int did;
int score;
};

const int dsize = 10000000;

int main(int argc, char **argv)
{
struct data *ldata;
struct data dumy;
int i,j,n;
clock_t stime, etime;
int offset = 10000;
ldata = (struct data *)malloc(sizeof(struct data) * dsize);
memset((void *)ldata, 0x00, sizeof(struct data)*dsize);

n = dsize/offset;
for (i = 0; i < n; i++)
{
stime = clock();
for (j = 0; j < offset * (i+1); j++)
{
dumy = ldata[j];
}
etime = clock();
//printf("%d : %.3fsn", offset * (i+1), (double)(etime-stime)/CLOCKS_PER_SEC);
printf("%d %.3fn", j, (double)(etime-stime)/CLOCKS_PER_SEC);
}
}

다음은 테스트 결과를 gnuplot(:12)를 이용해서 출력한 화면이다.

파일우선 테스트

파일에서 읽을 때 걸리는 시간을 측정해 보았다. 측정방식은 Memory방식과 동일하며, 이를 위해 다음과 같은 프로그램을 만들었다. *8 하는 것만으로 데이터의 위치를 구할 수 있을 것임으로 굳이 seek함수를 이용하진 않았다. 다음은 테스트를 위해 작성한 코드다.

#include
#include
#include
#include
#include
#include
#include
#include

struct data
{
int did;
int score;
};

const int dsize = 10000000;

int main(int argc, char **argv)
{
struct data *ldata;
struct data dumy;
int i,j,n;
clock_t stime, etime;
int offset = 10000;
int fd;


fd = open("data.dmb", O_CREAT|O_RDWR);
if (fd < 0)
{
perror("Open errorn");
}
memset((void *)&dumy, 0x00, sizeof(struct data));
for (i = 0; i < 10000000; i++)
{
write(fd, (void *)&dumy, sizeof(struct data));
}
printf("File Create endn");

n = dsize/offset;
for (i = 0; i < n; i++)
{
stime = clock();
for (j = 0; j < offset * (i+1); j++)
{
read(fd, (void *)&dumy, sizeof(struct data));
}
etime = clock();
printf("%d %.3fn", j, (double)(etime-stime)/CLOCKS_PER_SEC);
}
}

측정결과는 gnuplot를 이용해서 그래프로 만들었다.


비교를 쉽게 하기 위해서 하나의 그래프로 만들어 봤다.

블로거가 되다

때늦은 감이 있지만 나도 블로거가 되었다. 그동안 블로그의 필요성을 느끼지 못하고 있는데(사실은 지금도 별로 느끼지는 못한다), 구글 서비스들을 이용하다 보니 어찌어찌해서 블로거의 대열에 합류하게 되었다.

블로그의 필요성을 느끼지 못했던 이유는 아마도 인터넷을 개인미디어의 창구라기 보다는 정보검색과 지식축적의 창고로 인식하고 있었던게 크지 싶다. 그래서 정보를 축적하고 지식화 할 수 있는 위키에 열광했었고, 시간이 지남에 따라 잊혀질 수 밖에 없는 블러그에 별 반응이 없었던거 같다.

사실블로그를 쓰기로 마음 먹은 지금도 꼭 필요하다고 느끼진 않고 있다. 블로그를 쓰느니 그냥 동일한 내용을 위키에 정리하면, RSS등을 통해서 원하는 바도 달성할 수 있을 뿐더러, 카테고리에 분류되어서 필요할 때 쉽게 찾아볼 수도 있기 때문이다.

그럼에도 불구하고 블로그를 쓰게된건 순전히 구글의 서비스들 때문이였다. 특히 구글의 writely 때문인데, wizwig방식의 인터페이스를 통해서 쉽게 문서를 작성할 수 있고, 작성된 문서를 다양한 형태 특히 개인의 구글 블로그 로 바로 post할 수 있다는 점이 맘에 들었기 때문이다. 이렇게 개인 블로그로 post된 문서는 wiki에 간단한 plugin 하나 추가하는 정도로 쉽게 불러올 수 있으니, 쉬운문서작성, 블로그에 대한 경험(시류에 편승한다는 기분이 강하긴 하지만), 거기에 위키를 통한 정보축적 의 3마리 토끼를 동시에 잡을 수 있기 때문이다. 현재로서는 상당히 만족스럽다.

가벼운 개인 문서는 writely로 빠르게 작성해서 블로그로 포스팅하고, 위키로 정리할 필요가 있다고 생각되는건 위키페이지에서 불러오는 방식으로 사용할 계획이다.

구글 네트워크 운영체제를 위한 발걸음?

드디어 writely가 google 도메인으로 들어왔다. 이로써 이터넷 Office구현을 위한 핵심 애플리케이션이라 할 수 있는 워드프로세스, SpreadSheets, 프리젠테이션 프로그램중 워드와 스프레드쉬트 2개의 애플리케이션을 구글 도메인에 넣을 수 있게 되었다. 이제 기존의 gmail 사용자는 한번의 로그인으로 메일, 문서작성기, 표계산기의 서비스를 사용가능 하게 되었다.

아직 전문 워드프로세스에 비할 정도의 기능을 가진건 아니지만, 웹상에서 그리 복잡하지 않은 문서를 작성하기에는 충분한 성능을 보여준다. 데스크탑의 전용 프로그램에 비해서 성능이 떨어진다고는 하지만, 인터넷 특유의 강력한 특성인 어디에서든지 사용가능하다 와 별도의 응용을 설치할 필요가 없다 는 점 때문에 매우 유용하게 사용할 수 있을 것같다.

폰트선택과 크기 조절, 링크, 테이블등의 기본적인 기능외에, 이미지, 북마크, 코멘트, 특수문자등의 입력도 가능하다. 만들어진 문서는 웹을 통해서 통합관리 할 수 있으며, Revision 기능을 통해서 문서버전관리도 가능하며, 메일로 보내고, 공동으로 문서작업을 위한 문서공유 역시 가능하다.

일정관리, 검색(논문,웹문서,뉴스,블러그,동영상), 문서작성, 표계산, 메일 까지 몽땅 구글에서 끝낼 수 있는 서비스가 나올지도 모르겠다.

쓸만한 기능의 표계산기

약간 느리고, 그래프나 메크로등의 고급기능이 없긴 하지만, 대부분의 연산을 지원하고 있으며, 매우 쓸만하다. 아주 복잡한 계산을 필요로 하는 곳이 아니라면 부담없이 사용할 수 있을거 같다. 웹의 특성을 살려서 공동작업환경도 지원하고 있다. publish 기능과 writely로의 표 삽입기능까지를 지원한다면 더할나위 없이 훌륭한 프로그램이 될거 같다.

블러거를 위한 최고의 문서편집기

만들어진 문서는 publish 기능을 이용해서 웹문서 형식은 물론이고 자신이 사용하는 블러그로 바로 올릴 수 있는데, 이러한 점 때문에 특히 블러거들에게 유용하게 사용할 수 있을거 같다. 필자가 사용중인 google blog를 상대로 테스트 해봤는데, 성공적으로 post되는걸 확인했다.

웹뿐만 아니라, word, openoffice, RDF, PDF(:12)의 포맷으로 로켓 파일시스템에 저장할 수도 있다.

이 문서는 리눅스(:12) firefox 1.5에서 구글 writely를 통해서 작성되었으며 http://joinc-yundream.blogspot.com 와 http://docs.google.com/View?docid=dgfb53hh_0gg9d56 로 publish 되었다.

Joinc Wiki에서의 사용

joinc에서 사용하는 wiki는 moniwiki을 바탕으로 하고 있다. 그러다 보니 wizwig지원도 되지 않는 열악한 에디팅 환경을 제공한다. google writely를 이용하면 이런 문제를 해결할 수 있다. 필자는 writely로 편하게 문서를 작성하고 wiki페이지에서는 불러서 보여주는 방식을 사용했다. 이를 위해서 googledoc 이라는 wiki 플러그인을 만들어서 doc문서의 id만 넘기면 읽어오도록 했다. 꽁수이긴 문서 인덱스가 필요하지 않은 작은 크기의 문서를 만들 때는 꽤나 편할거 같다.

마치며

데스크탑 어플리케이션의 기능에는 미치지 못하지만(당연한가?) 어차피 데탑에서 사용되는 오피스 도구도 10-20%의 기능만을 사용한다고 하지 않던가. 그렇게 본다면 지금의 google docs도 이미 그정도의 성능은 보여주는거 같다. 무엇보다 만들어진 문서들이 구글의 다른 인터넷 서비스들과 유저에게 공유될 수 있다는 점이 엄청난 장점이라고 생각된다. 한번 문서를 만들면 별다른 작업없이 Blog, Web, Mail, 캘린더, FTP로 공유되고, 구글의 검색엔진을 통해서 검색될 수 있다. 게다가 별도의 무거운 애플리케이션의 설치 필요없이 인터넷에 연결된 PC만 있으면 이러한 일들을 할 수가 있다. 운영체제와 애플리케이션에 따라 문서가 이상하게 보이거나 아예 보이지 않는 그런 걱정도 할 필요 없다(리눅스 OO에서 작성한 문서를 윈도우에서 한번 보기 바란다).


모든 일을 구글에 연결해서 웹브라우저를 통해서 끝내버리는 구글 데스크탑(혹은 구글 OS) 환경이 만들어지는걸 기대해도 될거 같다.