팀에서 자기계발 과제로 작성한 ‘NoSQL 정의와 사례 정리’를 블로그에 공개합니다.

NoSQL 정의

No SQL? Not Only SQL?

NoSQL은 관계형 데이터베이스의 한계를 극복하기 위한 데이터 저장소의 새로운 형태로 수평적 확장성을 특징으로 한다.
관계형이 아니기 때문에 join이 없고 고정된 스키마를 갖지 않는다.

대표적인 NoSQL 제품은 Google의 BigTable, Amazon의 Dynamo이 있고, 이외에 비롯해 다양한 오픈소스 제품이 소개되어 있다.

Why NoSQL?

데이터 규모의 확대

• 저장할 데이터가 많아지면서 읽고/쓰기에 있어서 RDB가 제약 요소가 되었다.
• RDB의 수평적 확장성 한계로 새로운 해결책이 필요했다.

웹 서비스의 구조 변화

• 저장할 데이터의 형태가 계속 변화한다.
• 사용자의 데이터 요구가 일관적이지 않고 다양하다.

NoSQL 선택

BigTable, Dynamo, Cassandra, CouchDB, MongoDB, Hbase, Riak, Voldemort 등 20개 이상의 NoSQL 제품이 있고,
자신의 목적에 맞는 NoSQL 제품을 선택하기 위해서는 각각의 특징을 정확히 파악해야 한다.

CAP 이론

CAP이란?

• Consistency: 각각의 사용자가 항상 동일한 데이터를 조회한다.
• Availability: 모든 사용자가 항상 읽고 쓸 수 있다.
• Partition tolerance: 물리적 네트워크 분산 환경에서 시스템이 잘 동작한다.

CAP 이론과 NoSQL

데이터 저장소는 CAP 중에서 2가지만 선택할 수 있다. 예를 들어 RDB는 CA에 특화되어 있기 때문에 분산 환경에 적용이 어렵다.
NoSQL 제품은 CAP 중에서 C 또는 A를 일부 포기함으로써 분산 확장이 가능하다. 일반적으로 NoSQL 시스템은 관계형을 포기하거나 트랜잭션 구조를 느슨하게 함으로써 수평 확장이 가능하도록 한다.

CAP과 데이터 모델에 따른 구분 (각각의 구분은 설정에 따라 변경될 수 있다.)

RDB 대안

RDB 대안에 NoSQL만 있는 것은 아니다.

RDB cluster

• Oracle RAC, MySQL cluster
• 분산 확장과 안정성을 강화한 RDB 솔루션
• 단점)
  • 확장 비용이 비싸고 적용 및 관리에 고급 기술이 필요하다.
  • 읽기 성능만 향상된다.
• 장점)
  • 최소한의 개발 비용으로 도입이 가능하다.
  • 비용 예측이 가능하다.
  • 상용화된 지원이 가능하다.

Memory Cache

• memcached, Coherence, Santa
• RDB 앞단에 메모리 캐시를 두고 읽기 또는 읽기/쓰기를 캐싱한다.
• 단점)
  • 메모리 비용이 비싸다.
  • 메모리 크기에 제약이 있다.
  • RDB를 저장소로 사용하지만 장애시 일부 데이터가 손실될 수 있다.
• 장점)
  • 가격대비 효율성이 disk보다 훨씬 높다.
  • 읽기/쓰기 성능을 크게 향상시킬 수 있다.
  • 읽기/쓰기 수평 확장이 가능하다.

NoSQL

• 디스크 기반의 수평 확장이 뛰어난 데이터 저장소
• 단점)
  • Persistence Layer를 새로 개발해야 한다.
  • 사용화된 지원이 어려울 수 있다.
• 장점)
  • 읽기/쓰기 성능 및 확장성이 뛰어나다.
  • 일반 저가 장비를 사용할 수 있다.

NoSQL 교체 비용, 가치, 특징 비교

API, Data Model

• Interfaces- REST (HBase, CouchDB, Riak, etc.), MapReduce (HBase, CouchDB, MongoDB, Hypertable, etc.), Get/Put (Voldemort, Scalaris, etc.), Thrift (HBase, Hypertable, Cassandra, etc.), Language Specific APIs (MongoDB).

• Logical Data Models-Key-Value oriented (Voldemort, Dynomite etc.), Column Familiy oriented (BigTable, HBase, Hypertable etc.), Document oriented (Couch DB, MongoDB etc.), Graph oriented (Neo4j, Infogrid etc.)

• Data Distribution Model- Consistency and Availability(HBase, Hypertable, MongoDB etc), Availability and Partitionality (Cassandra etc.).

• DataPersistence-Memory Based (e.g. Redis, Scalaris, Terrastore), Disk Based (e.g., MongoDB, Riak etc.), Combination of both Memory and Disk(e.g., HBase, Hypertable, Cassandra).

NoSQL 제품 특징 비교

사례

해외사례

• Google Bigtable
  • 모든 URL 기반의 문서 정보 수집 (Key/Value 기반의 Bigtable에 저장)
  • 수집한 정보를 Map/Reduce로 색인 (색인 데이터도 Bigtable에 저장)
  • Document에서 사용하는 정보가 계속 추가될 수 있다. (URL, title, 본문, meta tag 등)
• Amazon’s Dynamo
• Digg.com Cassandra
  • 내 친구가 추천한 정보를 보여주기 위해서 NoSQL이 필요해짐
• Twitter Cassandra
  • 모든 사용자의 글을 하나의 DB에 저장할 수 없다면 내가 팔로우하는 timeline은 어떻게 보여줄 수 있을까?

NHN 인증 플랫폼

• 요구사항
  • backend DB 점검 시에도 read가 가능한 시스템
  • 로그인 사용자 세션 정보를 저장 및 조회
• 구현
  • MySQL 클러스터링으로 세션 정보 저장 – MySQL을 메모리 DB로 사용
  • in-house 메모리 DB로 사용자 정보 저장 – Oracle 로그 기반으로 메모리 리플리케이션

Daum view 추천 플랫폼 (예정)

• 사용자의 추천을 모두 수집한다.
• 소셜 네트워크를 저장한다.
• 추천 정보를 추천 히스토리와 소셜 네트워크 기반으로 Map/Reduce 분석
• 신뢰도 높은 추천 기반으로 문서 랭킹 부여

Daum Cafe

• ‘최근 방문 카페’ 기능에 Cassandra 적용

Reference

• Should Web Apps “Just Say No” to SQL?
• NoSQL in the Enterprise
• Visual Guide to NoSQL Systems
• NoSQL Ecosystem
• Designing a Scalable Twitter with Space-Based Architecture
• 기술적인 욕심 때문일까? 제대로 된 방향일까?

내부 팀들간의 인재채용 경쟁이 치열해서 그런 것일까? 현재 Daum view 공식 블로그에서도 안내를 하고 트위터에서도 알렸지만 생각보다 많은 분들이 관심을 갖고 지원을 하고 있지는 않다. (‘많은 지원’이 충분조건은 아니지만 아무래도 정말 딱~ ‘이 사람이야’ 하는 사람을 찾기가 쉽지 않다.) 결국은 한분 한분 지원자를 꼼꼼히 살펴보고 관심을 갖고 좋은 점을 놓치지 않게 주의를 기울일 수 밖에 없는데,이런 과정이 결국은 나와 내 서비스가 부족해서 초래된 것은 아닐까 생각되기도 한다.

사실 같이 일할 사람을 찾는다는 건 쉽지 않다. 개인적으로 구글에 면접을 봤을 때도 느꼈지만, 실력과 문화(성향) 둘 다 회사가 원하는 높은 기준을 충족시켜야 하고, 동시에 좋은 사람을 찾는 것보다 팀에 맞지 않는 사람을 뽑지 않도록 주의를 기울여야 한다. 인재에 등급을 부여하는 것이 옳은 생각인지는 모르겠지만 , 매우 뛰어난 A, 괜찮은 B, 부족한 C로 나눠보았을 때, A 인재를 뽑으려는 노력을 포기해서는 안된다. A는 같이 일할 동료로 A를 선택하기 때문에 회사의 문화가 유지될 수 있으나, 회사나 팀에서 어떤 이유로 B 인재를 뽑는다면 그 사람은 다음번에 C를 뽑을 확율이 높고 이로 인해 한순간에 뛰어난 회사가 평범한 회사가 될 수 있다.

사실 국내에 A만 뽑는 회사가 있을 것 같지는 않지만 적어도 팀에서는 그럼 노력을 해야하는 것이 아닐까? 아마 내가 이 팀의 문화를 중요하게 생각하기 때문에 이런 것에 더 집착하는 듯 싶지만 그래도 포기하고 싶지는 않다. ‘급하게 생각하지 말고 정말 좋은 사람을 찾자.’ 이것이 지금 나의 생각이다. 짧지만 내가 경험한 바로는 열정이 부족하고 스스로 배우지 않으며 효율성보다는 반복을 좋아하는 사람이 있기에, 대화보다는 고립을 선택하는 개발자가 있기에 조심스러울 수 밖에 없다.

다른 회사나 팀에서는 원하는 사람을 어떻게 찾고 있을까? 궁금하다.

대부분 알려준 방법으로 설치가 잘 되는데, 몇 군데 고생한 것들만 기록으로 남겨둔다.

1. 부트캠프는 기본으로 맥이 제공한다. 응용프로그램-유틸리티-부트캠프 지원에서 윈도우를 설치할 수 있다. 나는 32GB 파티션을 생성해서 설치를 진행했다. (오피스를 설치하고 있는 지금 남은 하드 용량은 19GB 정도)

2. 설치 도중 재부팅될 때 CD가 헛돌면서 멈추는 증상 발생. CD를 제거하기 위해서는 option 키를 누른 상태로 리스타트 해주면 OS 선택 화면이 뜬다. 이때 CD 꺼내기 키를 눌러주면 되는데, 이것도 잘 안될 경우 맥으로 부팅해서 시스템환경설정을 통해 윈도우로 부팅을 하면 된다.

3. 내 경우는 윈도우 7 설치 후 부트캠프를 설치했을 때 wifi 및 몇 가지 드라이버가 잡히지 않았는데, 이때 Apple Software Update를 통해 부트캠프를 업그레이드 해주면 모든 드라이버가 정상적으로 잡히게 된다. (이를 위해서는 유선랜으로 인터넷을 연결할 필요가 있다.)

부트캠프 3.1에서는 윈도우 7 정식 지원을 하면서 손가락 두개로 스크롤하기, 손가락 두개로 클릭해서 마우스 우클릭하기 기능이 모두 제공되기 때문에 마우스 없이도 큰 불편 없이 윈도우를 사용할 수 있을 것 같다.

NoSQL이란?

• 정의: NoSQL은 비관계형 데이터 저장소로 고정된 테이블 스키마나 조인을 지원하지 않고 수평적 확장에 강하다. 학계에서는 구조적 저장소로 부르기도 한다.  구현 제품으로는 구글의 BigTable, 아마존의 Dynamo가 있고, 아파치 HBase, 페이스북의Cassandra등의 오픈소스 제품도 있다. ( NoSQL is a movement promoting a loosely defined class of non-relational data stores that break with a long history of relational databases and ACID guarantees. These data stores may not require fixed table schemas, usually avoid join  operations and typically scale horizontally. Academics and papers typically refer to these databases as structured storage. Notable production implementations include Google’s BigTable and Amazon’s Dynamo, however there are also many publicly available open source variants including Apache HBase and Facebook’s Cassandra.) from 위키피디어
• NoSQL은 수평확장에 강하다. (strong network partition tolerance)
• 이미 많은 대형 사이트 솔루션이 ‘MySQL + Memcached’에서 NoSQL로 변화 중이다.

NoSQL 선택 기준

(참고: Visual Guide to NoSQL Systems)

CAP 선택

Visual Guide to NoSQL Systems from Nathan Hurst’s Blog

• Consistency: each client always has the same view of the data
• Availability: all clients can always read and write
• Partition tolerance: the system works well across physical network partitions

(참고: Brewer’s CAP Theorem CAP 중에서 2개만 얻을 수 있고 하나는 포기해야 한다는 이론)
ex) RDM (MySQL) = C + A, NoSQL (Cassandra) = A + P, BigTable = C + P

Data Model 선택

• Relational: RDBMS, support ACIDity
• Key-value: 키 기반의 get, put, delete 기능 제공
• Column-oriented: 테이블 기반이지만 조인 미지원, 컬럼기반 (not like row-oriented databases)
• Document-oriented: JSON, XML 형태의 구조적 문서 저장, 조인 미지원

NoSQL 적용 사례

Digg.com

• LAMP 기반에서 NoSQL 기반으로 구조 개편 (참고: Saying Yes to NoSQL; Going Steady with Cassandra)
• 상황
  • 끝이 안보이게 빠르게 증가하는 데이터 때문에 고성능, 쓰기 중심의 어플리케이션 구축이 어려움
  • 수평적, 수직적 확장 전략이 필요함
  • CAP에서 Consistency를 포기할 수 있는 상황 (digg 서비스 특징)
  • consistency는 어플리케이션 레벨에서 구현 가능
  • 복수의 데이터 센터 지원, 수정 작업 시 다운타임 없어야 함
• 오픈소스 Cassandra 선택
  • Cassandra? Dynamo 인프라 위에 BigTable 데이터 모델을 가지고 있는 분산 DB
  • 컬럼기반, 구조적 문서 저장 가능
  • 모든 노드가 개별적(identical)이고 데이터가 여러 노드와 데이터 센터간에 복제되어 안전
  • 수평확장할 경우 읽기, 쓰기 성능이 선형적으로 증가
  • 현재상황
    • full text 인덱싱, relational and graph 인덱싱 추가
    • Cassandra 성능 향상 (오픈소스 프로젝트 참가)
    • atomic counter 기능 추가 (Zookeeper 기반)
  • 그 이후의 자세한 내용 Looking to the future with Cassandra

digg.com 이외 대형 사이트

(참고: Building Scalable Databases: Are Relational Databases Compatible with Large Scale Websites?)

• Google: BigTable
• Amazon: Dynamo
• Linkedin: Project Voldemort
• 트위터도 Cassandra 사용 검토

Digg.com에서는 친구가 추천(digg)한 글을 표시해주기 위해 Cassandra를 선택한 것으로 판단된다.

대량의 데이터를 가공하여 개인화된 정보를 표시해줄 때 기존의 RDB + 캐싱 기법이 한계를 갖고 있는데, 이를 비정규화된 데이터를 분산된 서버에 저장하는 방식으로 해결한 것으로 보인다.

즉, 내가 어떤 글을 추천했을 때 내 친구들의 모든 리스트에 내 추천 기록을 저장해서 해당 글이 친구에 의해 추천받았다는 것을 각각의 사용자에게 보여줄 수 있게 되는 것이다.

이는 Daum view에서 내가 구독하는 사용자가 발행한 최신글, 인기글을 보여주거나, 추천 LIVE, 추천평 LIVE를 보여주는 것과 유사하다고 할 수 있는데,

재미있는 사실은 view에서는 전혀 다른 방식으로 이를 해결했다는 것이다.

view에서는 기존 MySQL 기반의 데이터 영역을 Lucene 기반의 검색엔진으로 상당부분 대체했고 서비스가 검색을 기반으로 발전하고 있다.

내가 5명의 블로거를 구독하고 있을 때 이들이 추천한 정보를 가져오기 위해서 SQL 쿼리를 MySQL로 요청하는 것이 아니라,

검색 쿼리를 Lucene으로 요청하게 된다.

예를 들어 RDB 쿼리가 다음과 같다면,

SELECT * FROM recommend_table r

JOIN user_mapping_table um ON r.userid = um.userid

ORDER BY r.id desc;

검색 쿼리가 다음과 같이 만들어 질 수 있다.

(daumid:id1 OR daumid:id2 OR daumid:id3 OR daumid:id4 OR daumid:id5) type:recent

만일 구독 글 안에서 검색을 하고 싶으면 검색엔진의 이점은 더욱 분명히 드러나게 된다.

SELECT * FROM recommend_table r

JOIN user_mapping_table um ON r.userid = um.userid

JOIN news_table n ON r.news_id = n.id

WHERE n.title like ‘%검색어%’ OR n.summary like ‘%검색어%’

ORDER BY r.id desc;

(daumid:id1 OR daumid:id2 OR daumid:id3 OR daumid:id4 OR daumid:id5) type:recent 검색어

물론 Lucene 기반의 데이터 영역이 가지는 구조적 단점이 있겠지만

현재까지는 이런 변화가 기존에 생각하지 못했던 서비스들을 만들어낼 수 있는 기술적 기반이 되었다고 할 수 있다.

그리고 view 서비스는 사용자의 추천 행위를 검색 랭킹에 반영할 수 있는 소셜 검색의 새로운 도전 무대라고 생각한다.

기존에 서비스 기획과 검색 기획이 별도로 진행됐다면 검색이 바로 서비스인 새로운 모습이 구현되고 있는 것이다.

사용자가 참여하는 서비스가 검색의 품질에 직접 기여하게 되고, 검색 랭킹의 영향으로 다시 사용자 참여를 이끌어내는 새로운 생태계가 만들어지기를 기대해 본다.

최근 소셜 검색은 다시 새롭게 정의되고 있으며 한마디로 정의하기 힘든 영역이라 할 수 있다. 하지만 구글에서 시도한 실험들을 따라가다 보면 소셜검색의 실체가 드러난다.

1. 사용자가 컨텐츠를 평가

구글이 Digg.com을 인수하려는 시도를 하다 결국 자체적으로 구글 검색 결과에 대해 사용자가 직접 평가를 하는 시스템을 도입했다. 하지만 서비스 컨셉의 충돌로 의미있는 결과를 만들어내지 못한 것으로 알고 있다. 이를 통해 알 수 있는 것은 사용자 추천이 검색 결과에 잘  융합되지 못한다면 오히려 별도의 서비스로 사용자 추천을 수집하는 방식이 효과적이라는 것이다.

사용자 평가를 활용하면 범용적인 PageRank보다 더 의미있는 개인화된 랭킹, 그리고 사회적 환경에 따라 변하는 동적 랭킹을 제공하는 것이 가능할 것이다.  이를 위해서는 해당 컨텐츠를 누가 추천했는지 추천자를 분류하는 것이 중요하고 내가 신뢰할 수 있는 추천자의 역할이 중요해진다.

2. 소셜 네트워크 내에서의 검색

최근에 구글에서 발표한 소셜검색은 자신의 소셜 네트워크 안에서 검색을 해주는 기술이다. 내 친구가 작성한 블로그, 사진, 트위터 등을 모두 검색해주기 때문에 나름 의미가 있지만 이것만으로는 의미있는 가치를 만들어주지는 못할 것이다.

Daum과 같은 포털에서는 포털 내의 사용자가 생산한 컨텐츠 검색을 제공해 줄 수 있으나 오픈 플랫폼을 기반으로 외부 네트워크를 확장하고 컨텐츠를 확보해야만 진정한 소셜 검색이 될 수 있다고 생각한다.

3. 아이덴티티 통합

구글 버즈가 새로 오픈했는데 버즈의 가장 강력한 기능은 사용자의 아이덴티티를 묶어 주는데 있다. 구글은 이미 전세계의 모든 웹페이지를 인덱싱하고 있지만 각각의 글이 누구의 소유인지 추측만 할 뿐 정확히 알지 못한다. 그런데 구글 버즈를 통해 사용자들이 스스로 자신들의 트위터, 블로그, 플리커와 같은 웹에 흩어져 있는 자신의 아이덴티티를 묶어 주고 있는 상황이 되었다.

물론 구글은 이미 url 기반으로 모든 정보를 수집하고 있기 때문에 이런 통합된 아이덴티티를 기준으로 내 버즈를 쉽게 생성할 수 있고, 이 방식은 API를 활용한 FriendsFeed와는 전혀 다른 방식이며 비동기적으로 수집이 수행된다.

4. 관심별로 사용자 그룹핑

소셜 검색에서 사용자별로 개인화된 검색 결과를 보여주는 것은 기술적으로 불가능해 보일 수 있다. 하지만 이는 사용자 클러스터로 해결이 가능하다. Daum view에서는 이미 키워드 기반으로 사용자를 묶어주는 서비스를 준비하고 있으며, 사용자의 아이덴티티를 통합할 수 있다면 그 데이터를 기반으로 사용자의 관심을 알 수 있고, 이 관심을 기반으로 사용자를 분류할 수 있다.

또한 추천자도 이와 동일한 관심에 따라 분류됐을 때 개인에게 의미있는 컨텐츠를 찾아줄 수 있는 가능성이 커진다.  이런 세분화된 추천은 소셜 랭킹에 반영될 수 있는 중요한 요소이다. 즉, 내가 관계를 맺고 있는 사람들의 추천, 좀 더 넓은 의미로 내가 생성한 글들, 내가 구독하는 글들로 판단된 관심과 동일한 관심을 갖고 있는 사람들의 추천을 통해 그 사람이 원하는 정보를 찾아줄 수 있다면 이것이 새롭게 가치를 창조하는 미래의 소셜 검색이라고 할 수 있다.

참고: 소셜 검색 알고리듬 찾기

어제 발표가 끝난 후 소그룹으로 모여 회고 시간을 가졌는데요, 제가 속한 그룹은 캐빈 회고법으로 진행해봤습니다. 서로 포스트잇과 펜을 나눠가진 후 각자가 느낀 것을 5분 동안 적어냅니다. 포스트잇 한장에 한가지 생각을 적고, 한사람은 여러장의 포스트잇을 사용할 수 있습니다. 이렇게 모인 포스트잇의 내용을 소리내어 읽으면서 비슷한 그룹별로 분류를 합니다. 그리고 각각의 포스트잇에 적힌 내용을 토대로 서로의 생각을 듣는 시간을 갖게 됩니다.

어제 회고에서 나온 생각들을 이곳에 적어볼까 합니다. 아마 이를 통해서 Xper 모임에서 갖게 되는 느낌이나 경험을 조금이나마 알 수 있지 않을까 싶네요.

• 더 잘 하게 하는 방법이 있다.
• 고민이 다시 처음으로.
• 포기했던 부분이 도전과제로.
• agile 우리(cage) 안.
• 비슷한 생각을 하는 사람들
• 실제 여러 사례를 들으니 좋다.
• 같이 와서 좋다.
• 동료들의 성향(각자의 개성)과 동료들이 필요한 것을 어떻게 알 수 있을까?
• 좀 더 ‘주위 공기’를 잘 읽는 능력이 필요할텐데…
• 안보이는 것이 많다.
• 시간이 필요해
• 역시 사람이 중요하다.
• 사람이 문제다.
• 다칠 수 있음을 감수하는 자세(태도), 책임을 자기 것으로 끌어오는 자세.
• 조직이 추구할 가치와 원칙? 민주주의…
• 나를 공개하고 얘기하고 이해시키고.
• Google, NHN, Daum 어느 조직이 성공할 수 있을까? (조직? 문화? 목표?)
• 잉여가 되기 싫어 ㅠㅠㅠㅠ
• 베타 날짜 어떻게 맞추나 ㅠㅠㅠ (사운드 담당자 미워)

회고를 통해 ‘코칭’, ‘신뢰’, ‘공개’, ‘도움청하기’ 등등의 얘기들을 나눴던 것으로 기억되네요. 그리고 돌아오는 길에 제 발표에 대한 피드백을 들어보니, ‘~같아요’ 라는 표현이 지나치게 많았다고 하더군요. 변신철님은 자신의 대화를 녹음해서 다시 살펴보는 작업을 하셨던데 저도 그런 노력을 통해 개선할 부분이 많이 있는 것 같네요. ㅋㅋ ‘~같아요’라는 표현이 저의 어떤 심리상태에서 기인한 것인지 좀 더 살펴봐야겠습니다.

올해 초, Daum 블로거 뉴스의 기획자와 개발자의 TFT가 만들어졌고, 1년 안에 구체적인 성과를 내야 했습니다.

우리는 캐빈이라는 독립된 공간에서 같이 일하며, 행복한 일터를 만들고 싶었습니다. 그래서, 그 동안 개발팀에서 쌓아온 경험들을 새로운 조직에 적용했습니다.

9개월여 동안 공동 작업, 빠른 피드백, 회고 등의 방법을 전체 직군에 확대 적용했습니다. 그 결과 새로운 비지니스 모델 창출, 유연한 서비스 개선, 직군의 재정의가 성공적으로 이루어졌습니다. 반면, 권한 위임 잘하기, 조직이 팽창될 때에도 문화 유지 잘하기가 해결해야할 과제로 남았습니다.

‘OOPSLA 2007 공유 모임’ 이후 거의 2년만에 xper 모임에 참가하게 되었네요. 그때도 즐거운 경험을 많이 할 수 있었는데 이번 모임도 기대됩니다. 기회가 되면 이번 서울 방문 때 NHN 동료들도 만나고 농구도 같이 할 수 있으면 좋겠네요.

이번 모임에서 1시간 정도 발표를 해야하는데 어떤 방식으로 발표하는 것이 좋을지 고민이 됩니다. 지금 생각으로는 ‘페어 기획’, ‘주간회고’, ‘캐빈’, ‘Daum view’, ‘권한위임’, ‘조율하기’, ‘직군 재정의하기’ 등의 주제를 미리 정하고 그날 참가자들이 듣고 싶은 주제를 선택할 수 있게 해볼까 합니다.

관심있는 분들은 xper 모임에 참가해주세요. 그리고 댓글로 질문을 적어주시면 도움이 많이 될 것 같습니다.

캐빈 문화는 Daum에서도 제주에서, Daum 제주 GMC에서도 옥상에 따로 방 하나가 마련된 캐빈이라는 특정 공간의 문화를 뜻한다. 전체 Daum의 DNA와 일맥상통하는 부분도 있지만 그보다는 좀 더 작고 특별한 집단의 이야기이다.

올해 시작과 함께 Daum view 개발자와 기획자가 모두 캐빈에 모여 일을 같이 하기 시작했다. 그전에는 각자의 팀에서 따로 떨어져 일하던 사람들이였고 일부는 새로 합류하거나 다시 Daum view로 돌아온 사람들이였다. 회사에서는 TFT로 조직을 꾸려주었고 우리는 새롭게 전략안을 세우면서 우리만의 문화를 만들어가기 시작했다.

캐빈 문화가 만들어지기까지는 크게 두가지 변화가 선행되었다. 하나는 팀장의 열정이였는데 팀의 목표와 전략을 사내의 다양한 사람들에게 이해시키고 도움을 이끌어냈으며 TFT 내부적으로는 계속해서 권한을 위임하고 자율성을 부여했다. 또 하나는 개발파트의 애자일 문화를 강화하고 이를 팀 전체에 확장시킨 것이다. 협업, 투명성, 피드백, 여유 등 다양한 시도를 개발파트의 주도로 시작했고 팀 전체에 조금씩 적용시켜 나갔다.

Daum view의 미래에 대해 묻는 분들에게 난 항상 이렇게 대답했다. ‘인터넷, 특히 Daum view가 가는 길은 변화가 매우 빠른 곳이다. 그래서 미래를 예측할 수는 없지만 나는 캐빈의 독특한 문화가 성공을 보장할 것이라 믿는다. 실험과 피드백을 통한 점진적 발전, 수평적 의사소통을 통해 발전하는 유연한 전략안, 그리고 여유를 통한 창조적 활동과 도전이 불가능한 것을 가능하게 해줄 것이다.’

캐빈 문화에서 실행한 실험을 몇가지 정리하면 다음과 같다.

• 직군 파괴: 기획자, 개발자, 편집자, UI 개발자, 디자이너, 컨텐츠 운영자, 시스템 운영자 등등 팀원들의 역할은 사내의 규정에 의해 직군이라는 벽에 갇혀있었다. 몇번의 의견을 나눈 끝에 현재는 편집파트, 개발파트 두가지로 역할을 나누고 기획은 모두가 참여하고 프로젝트는 아이디어를 낸 사람이 리딩할 수 있는 구조로 만들었다. 개발자들 사이에서는 ‘개발자는 기획회의에 참가하고 기획 활동을 같이 하는데 왜 기획자는 개발을 안하지?’라고 하는데 작게는 이런 모순을 해결했고 구성원 모두가 주인의식을 같고 서비스에 좀 더 관심을 갖게 하는 더 큰 변화를 끌어냈다.
• 여유와 실험: Daum에는 공식(?)적으로 CTime이 있어서 업무시간의 일부를 창조적 활동에 사용할 수 있는데 실질적으로 이 시간을 활용하는 곳은 매우 적은 것으로 알고 있다. 캐빈의 개발파트에서는 새로 팀을 꾸리면서 금요일 오후를 CTime으로 결정했고, 한때는 매일 오후 5시 이후 시간을 모두 CTime으로 쓰기도 했다. 이 CTime을 통해서 개발자 블로그, 랭킹, 추천 LIVE, URL 기반 추천, XUL 뷰어, 아이폰용 view 등 다양한 프로토타입과 서비스가 탄생했다. 아쉬운 것은 편집파트는 과도한 업무로 이런 여유를 잘 활용하지 못하고 있는데 팀내의 풀어야할 숙제라고 생각한다.
• 애자일의 확산: 개발파트를 새로 꾸리면서 PP를 활성화해서 개발자들간의 코드에 대한 이해도를 동등한 수준으로 올렸고, 피드백과 투명성을 높이는 노력을 기울였다. 매주 금요일 주간회고를 통해 그 주에 받은 각자의 느낌을 공유함으로써 공통적으로 느끼는 문제는 해결책을 마련하고 잘 한 것은 서로 칭찬해주고 변화는 격려해주는 시간을 갖고 있다. 또한 업무 진행상황이나 새롭게 떠오르는 아이디어는 팀내 쪽지를 통해 모두에게 공유하며 개발파트 위주로 실험되는 다양한 실천방법을 편집파트에도 확산시켜 나가고 있다. 그 한 예로 서비스 기획을 할 때도 두 명의 기획자가 한 컴퓨터 앞에 앉아 기획하는 페어 기획을 하고 있으며 주간회고에도 점점 많은 구성원을 참가시키고 있다. 실패하긴 했지만 편집파트에서도 일주일 단위의 이터레이션 회의와 백로그를 작성하는 시도를 통해 무엇 때문에 업무 부하가 많고 시간 관리는 어떻게 할 수 있는지에 대한 통찰을 얻기도 했다.

이런 실험과 변화를 통해 지금의 캐빈 문화가 형성됐고 이를 통해 지속적인 혁신을 꿈꾸고 있다. 하지만 조금은 아쉬운 점들이 있는데 대부분은 조직적인 이슈인 것 같다. 가장 큰 아쉬움은 자원의 유연한 이동이 불가능한 구조여서 좀 더 속도를 내지 못하고 있다는 것이다. 또한 좀 더 조직원의 학습을 지원하고 조직내 투명성과 피드백을 높일 수 있다면 캐빈 문화가 Daum의 DNA로 녹아들 수 있지 않을까 생각해본다. (상대적으로 NHN의 스터디 지원과 도서 구매 지원은 확실한 명시적 효과가 있었던 것 같다.)

지금까지 이야기한 내용들 중에 현재 읽고 있는 ‘경영의 미래’의 내용과 일치하는 곳이 있어 일부 인용해보았다.

유연하지 못한 자원배분
때로는 혁신의 진짜 장애물은 대안의 부족이 아니라 자원을 배분하는 유연함의 부족에서 오기도 한다. … 대부분의 회사에서 관리자의 힘이란 자신이 관리하고 있는 자원과 직접적으로 관련되어 있다. 즉, 자원을 잃는 것은 바로 영향력을 잃는다는 뜻이다. 게다가 개인의 성공은 종종 자신의 팀이나 프로젝트의 성과에 달려 있다. 그 결과 프로그램 관리자는 새로운 사업이 얼마나 매력적인가에 상관없이 자기 팀의 자원과 인재를 새로운 프로젝트에 재분배하는 시도에 반대하기 마련이다. …

여유에서 오는 혁신
효율성을 추구하기 위해 기업은 한 치의 느슨함도 없는 완벽한 운영을 하고자 끊임없이 노력해왔다. 물론 이는 좋은 일이다. … 그러나 당신이 회사의 모든 느슨함과 여유를 쥐어짠다면, 혁신의 여지도 그만큼 사라진다는 것이 문제다. 혁신은 상당한 시간을 필요로 한다. 즉, 꿈을 생각하고 이를 반영하며 배우고 또 개발하고 실험할 시간들이 주어져야 한다는 것이다. 그리고 이는 당신이 책상 위에 발을 얹고 허공을 응시할 수 있을 만큼 방해받지 않는 연속적인 시간이여야 한다. …

이 책에서는 경영 혁신에 가장 필요한 것으로 ‘열정’을 뽑았는데 나 또한 이에 깊게 동의한다. 하지만 가장 큰 문제는 기업 내에서 열정을 발휘하는 것과 내 자신을 위해 열정을 발휘할 때 보상의 차이가 매우 클 수 있다는 것이다. 결국 열정이 있다면 내 사업을 해야하지 않을까? 켄트벡의 Responsibility(사명감)도 열정과 같은 의미가 아닐까? 난 가끔 여유를 열정보다 우선시하는 것은 아닐까? 글을 쓰면서 오히려 더 많은 생각들을 하게 된다.

켄트 벡의 신기한 점은 고민을 구체화시키고 정리하고 단순화하는 능력인 것 같다. 자신이 코딩을 하면서 디자인을 하는 순간들을 인덱스 카드에 바로 바로 적은 후 그 카드들을 종류별로 분류를 했더니 다음과 같은 4가지 선택이 있었다고 한다. (이에 대해 정리된 글은 쉽게 찾아볼 수 있을텐데, 노파심으로 링크 하나 추가해 본다. Xper 메일링 리스트에 남긴 창준님 의견)

• Leap – 도약
• Parallel – 병렬
• Stepping Stone – 징검다리
• Simplification – 단순화

그래서 난 인덱스 카드에 적어보진 않았지만 내가 프로그래밍을 하거나 시스템 구조를 설계할 때 어떤 고민을 하고 어떤 행동을 취했는지 되돌아 보았다.

머리 속에서 코딩하기 – 조금 복잡한 문제는 바로 코딩을 하지 않고 머리 속으로 전체 구조를 그려본다. 이때 전체 구조는 거의 코드 레벨로 메소드 또는 그보다 작은 기능 덩어리로 머리 속에서 구체화되고 그 후에 실제 코딩을 시작한다. 이렇게 개발할 때는 이미 정리된 전체적인 모습을 코드로 옮기기만 하면 되기 때문에 TDD를 하지 않는다. 장점은 완결된 형태로 기능이 잘 구현되는 것이고, 단점은 패턴으로 연결된 요소가 아닌 하나의 흐름 덩어리로 코드가 만들어지는 것이다.

한 단계씩 밟아가기 – 무엇을 만들어야 하는지 확실하지 않을 때는 테스트 케이스를 먼저 만들면서 문제 자체를 구체화 해간다. 이때는 TDD를 하게 되는데 보통 PP를 할 때도 TDD를 같이 수행한다. 또는 구현하려는 기능에 대해 구현법 자체가 모호할 때(자주 사용하지 않는 java package를 사용하는 경우)도 한 단계씩 밟아 나가면서 문제를 해결한다.

장애처리 또는 디버깅 하기 – 이때는 일반적인 방법을 활용한다. 가장 최근에 변경된 사항 살펴보기, 문제의 가장 핵심 지점을 찾고 그 원인을 해결하기, 구조적 모순을 찾고 다른 방식으로 이 문제 해결하기 등을 사용한다. 이때 관건은 정확하고 필요한 정보를 어떻게 얻어낼 수 있냐인 것 같다.

재미 없는 개발하기 – 단순한 운영툴이나 외부 연동을 통한 지루한 작업을 할 때는 PP를 선호한다. 뭐랄까 꾸역꾸역 해나가는 맛이 있다고 할까? 이때 만들어야 하는 output(화면, UI)부터 만들어서 server side로 거꾸로 개발을 하면서 개발의 흐름의 끈을 놓치지 않는 것이 중요하다.

이렇게 정리를 해보니 Design 문제가 아니라 개발 practice들이 나열이 된 것 같다. 아마 켄트 벡은 이런 practice를 말하는 것을 조심스러워 하기 때문에 더 원론적인 얘기를 하게 된 것이 아닐까. context 없이, 원칙 없는 실천법은 그 의미를 잃을 수 밖에 없으니까 정제된 원칙에 대한 깨달음을 전달해주고 있는 것 같다.

여하튼 한번쯤은 켄트 벡 방식으로 내 머리속의 흐름을 눈 앞에 꺼내볼 필요가 있다. 그리고 그 속에서 패턴을 찾아 발전시켜 나가면 내 자신에게도 그리고 내 주위의 사람들에게도 도움일 될 것이다.

밴쿠버는 재작년에 OOPSLA에 참가했을 때 한나절 정도 다운타운을 둘러봤던 곳이고 딱히 발표가 필요한 상황도 아니여서 팀내의 다른 분이 참관을 하기로 했다. 이번 컨퍼런스 참가는 열린편집알고리즘의 독창적이고 유용한 기능을 국제적으로 알릴 수 있는 좋은 기회이고 동시에 다른 다양한 Socail Computing 기법들을 배워서 서비스에 접목시킬 수 있는 생각의 바탕이 될 것이다.

그런데 석찬님이 9월에 제주에서 열릴 국제컨퍼런스인 BlogTalk에서 Daum view와 열린편집알고리즘에 대한 발표를 부탁하면서 쉽게 지나갈 것 같았던 컨퍼런스 관련 부담이 급증하게 된 상태이다.

사실 우리말로 어떤 것을 설명하고 발표하는 것은 이미 여러번 경험했었고 내가 잘 알고 있는 분야면 재미있게 받아들일텐데 문제는 영어로 발표를 해야한다는 사실이다. 영문과를 졸업했지만 영어는 여전히 외국이일 뿐 편하게 사용하지 못하고 있고 해외 컨퍼런스에서도 여러명과 동시에 대화할 때는 항상 어려움이 많았기에 부담감이 늘고 있다.

그런데 이런 부담감에 석찬님께 발표가 힘들 것 같다고 사양도 했었지만 이미 컨퍼런스 웹사이트에는 발표자의 사진까지 실렸고 이제는 잘 준비해서 만족스럽게 발표를 하는 것만 남은 것 같다. 점심 영어, 전화 영어로 영어 준비는 계속 하고 있고 매주 금요일 오후의 CTime을 활용해서 발표 내용도 재미있게 만들어봐야겠다.

요즘은 책이나 웹에서 새로운 개발 관련 정보를 얻지 못하고 있는데 오히려 실제 팀에서의 실험들과 이런 기회를 통해 경험이라는 것은 계속 확장되고 있다. 항상 편하고 익숙한 것만 할 수는 없으니 부담감도 즐겁게 받아들여야겠다.