최근 새로운 것들을 배우는 재미에 프로그래밍 공부를 하지 못했다. 최근 두 달 동안 흙집 짓기를 배우고 텃밭과 정원 가꾸는 법을 익히면서 대부분의 주말을 보낸 것 같다. 그런데 재미있는 사실은 이 과정 속에서 프로그래밍과 소프트웨어 엔지니어링에 대한 새로운 지식과 깨달음을 얻을 수 있었다는 것이다.

사실 컴퓨터 공학은 초창기부터 건축학에서 많은 메타포를 가져왔고 최근에는 가드닝에서 새로운 공통점들을 발견하고 있다. 아마 내가 경험한 것들도 이와 유사한 것들이라고 생각되어 단편적이지만 간단히 정리해 보려고 한다.

흙집 짓기에서 배운 것들

• 설계는 공학적 지식을 바탕으로 검증된 무너지지 않는 구조를 기반으로 해야한다. 원형 흙집을 설계할 때 28개의 서까래가 마지막에 중앙에 받히는 기둥을 제거했을 때 무너지지 않도록 지붕의 기울기와 무게 분배에 대한 감각과 지식이 필요하다. (소프웨어 공학에서도 기본 데이터 구조나 알고리즘을 기반으로 돌아갈 수 있는 형태의 구조가 미리 그려져야 한다.)
  

  원형 지붕의 서까래를 기둥이 받히고 있는 모습

• 집만으로 기능적으로 완성되거나 아름다울 수 없다. 그곳에 사는 사람, 집 주위의 풍경, 생태적 환경, 기후 등 모든 것들을 고려할 때 하나의 완성된 집을 만들 수 있다. (아무리 잘 만든 프로그램이라고 해도 그 자체만으로는 의미가 없다. 프로그래머가 통합적 디자이너가 되어야 하는 이유)
• 설계도가 있어도 집을 만들어가는 모든 과정에서 그때 그때 다시 결정을 하고 수정을 해야한다. 매번 재료가 다르고 여건이 다르기 때문에 설계도를 참고하면서 창조적 변형과 부분적 재설계를 해야만 한다.
• 보통 목수팀, 미장팀 등 팀으로 일을 하게 되는데 한명이 목수팀의 리더이면서 동시에 미장팀의 보조가 될 수 있다. 또한 각각은 자유롭게 의견을 낼 수 있고 이전의 경험을 바탕으로 최대한 옳은 판단을 하려 노력한다. 집을 짓는 단계별로 필요한 기술의 비중이나 중요도가 달라지는데 이 때 이러한 다중 역할 수행능력이 도움이 된다.
• 보통 품질은 팀원 중 가장 품질 기준이 높은 사람을 따라간다. 아름다움, 정확함, 보이지 않는 부분의 충실함 등 전문가로서 품질은 타협의 대상이 되지 않는다. 물론 상황에 따라 저가의 재료를 사용할 수도 있으나 본인의 기술에 해당하는 부분에 있어서는 선택의 여지가 없다.
• 세세한 부분까지 미리 설계하지 않는다. 집짓기 각 단계에서 창조와 재해석의 여지를 남겨둠으로써 매번 새로운 집을 만들 수 있다.

텃밭에서 배운 것들

• 지속적인 관찰을 통해 지금 무엇을 해야하는지 알 수 있다. 그리고 농사는 때를 알아야 하고 그 때를 놓쳐서는 안된다. (서비스도 하나의 생명과 같아서 사용자의 성격, 서버의 안정성, 경쟁 서비스 등을 항상 관찰해야 한다. 또한 서비스들의 생명주기를 이해해서 지금 물이 필요한지, 특정 영양소가 필요한지, 그리고 그 필요한 때를 놓치지 않아야 한다.)
• 건강한 토양에서 영양가 많은 작물을 재배할 수 있다. 과다한 비료와 농약을 사용하는 단기적 처방은 결국 악순환의 고리에 빠지게 된다. (팀의 능력을 향상시키기 위해서는 팀문화에 대한 고민이 필요하다. 결국 건강한 토양이란 다양성이 확보되고 지속성이 있으며 외부 충격으로부터 자율적으로 회복될 수 있는 능력을 의미한다.)
• 경험으로 쌓인 지식도 그 배경이 되는 과학적 원리가 뒷받침되어야 한다. 숲을 관찰하고 토양 미생물을 연구함으로써 세균과 균류의 역할과 이상적인 토양의 조건이 밝혀졌다. 그리고 이를 기반으로 더 다양한 대처법과 활용법이 소개되었다.
• 결국 하는 일이 좋고 같이 하는 사람이 좋아야 한다. 공동 텃밭을 경영할 경우 텃밭이 아니라 사람의 관계에만 신경을 쓰면 본래 목적과 다른 일에 에너지를 쏟게 된다. 텃밭에 더 관심을 갖고 작물을 공부하고 농사법을 고민하면 자연스럽게 생각이 같은 사람들이 모여 발전적인 모임을 만들 수 있다. 소소한 사적인 네트워크보다는 본인의 업무 분야에서 같이 고민을 나누는 사람들이 늘어갈 때 하나의 지식 공동체가 만들어질 수 있지 않을까?
  

  해안초교 텃밭에 지주대를 세운 모습

아직 경험한 것이 적어서 글로 잘 정리되진 않지만 건축학은 무엇인가를 만드는 행위라면 텃밭은 무엇인가를 만들기 위해 준비하고 관찰하고 꾸준히 노력하고 지속시키는 과정이라 생각된다. 그리고 여러 분야의 전문가들이 각자의 영역에서 정말 많은 고민을 하고 있는데 이런 경험들이 좀 더 폭넓게 공유될 필요가 있을 것 같다.

“애자일 개발방법론은 환경에 따라 다르게 적용해야 한다.”

길지는 않지만 6년 전 XP를 처음 접한 후 지금까지 애자일을 경험하면서 얻은 지식이라면 이것 하나가 있을 것 같다.

최근 새롭게 팀을 옮기면서 이런 고민을 다시 한번 하게 되었다. “이 팀에 애자일 방식을 적용할 수 있을까?”

그렇다면 먼저 새로운 환경에 대해서 분석을 해야 하는데, 내가 보기에 이곳은 대학원 연구실과 유사한 모습이라고 할 수 있을 것 같다. 각자 뭔가 데이터를 분석하고, 새로운 모델링 기법을 고민하고, 논문을 살펴보고, 서로 자유롭게 의견을 나눈다.

주위의 조언을 구해보니, 서로 다른 일을 하고 있고 서로 상대방의 일에 대해서 잘 모를 때 일일미팅은 어려울 것이라 했고, 그래서 우선 XP에 대해서 설명을 하고 주간회의에 회고를 도입하는 것으로 애자일 적용을 시작했다.

그 후에 새로운 접근방법을 찾지 못하고 있었는데, 10월 CACM에 연구실에 애자일을 도입한 사례가 설명되어 있어서 여기서 내용을 간단하게 요약해 보려고 한다.

SCORE: Agile Research Group Management

[도입배경]

조교로서 대학원 연구실의 주된 일은 대학원생들과 같이 일을 하고 이들을 멘토링하는 것입니다. 처음에는 일반적인 방법으로 학생들을 관리했는데, 우리의 시간이 점점 단편화되고 비효율적으로 쓰이면서 어렵게 배운 교훈들이 효과적으로 공유되지 못하고 연구실이 응집되지 못하는 문제를 겪게 되었습니다. 그러던 중 2006년 9월 Scrum에 대해서 알게 되고 이를 연구실에 적용해 보기로 하였습니다.

이 방법을 SCORE(SCrum FOr REsearch)라 부르며, 몇 년 동안 SCORE를 적용해서 좋은 결과들을 얻었기 때문에 이 경험을 많은 사람들과 나누고 싶습니다. 다만, 각자가 처한 환경이 모두 다르기 때문에 형식이 아니라 아이디어를 배우기를 바랍니다. (in idea if not in form)

[SCORE]

SCORE의 가장 중요한 요소는 미팅 구조이고 이에는 두 가지 방식이 있습니다.

• 모두가 참가하는 정기 상황 보고 미팅 (Regular all-hands status meetings) – 화, 수, 금 늦은 오전에 연구실 모든 사람이 15분 동안 모입니다. (스크럼의 일일 스탠딩 미팅과 유사합니다.) 이 시간에 각자 지난 번 미팅 이후 변경된 사항, 무슨 문제가 있었는지, 그리고 다음 미팅까지 무슨 일을 할지 얘기합니다. 만일 미팅에 참가할 수 없으면 컨퍼런스 콜로 참가해도 되지만 가급적 직접 참가할 것을 강하게 권장합니다.

  회의를 간소화시키기 위해 이 시간 동안 모두 서서 미팅을 진행합니다. 간단한 미팅이지만 상황 보고 미팅은 매우 많은 정보를 얻을 수 있습니다. 학생들은 코드 구현, 실험 진행, 논문 읽기 등의 폭넓은 활동에 대해서 보고하고 이 보고를 교수진이 아니라 연구원들에게 하도록 권장합니다.

• 연구 미팅 요구 (On-demand research meetings) – 학생이나 조교가 더 심층적인 미팅이 필요하다고 생각하면, 연구 미팅을 요구해서 관련된 사람들을 소집합니다. 보통 당일 오후에 필요한 시간만큼 미팅을 계획할 수 있습니다.

그리고 진행중인 연구 프로젝트에 대해 발표하는 컨퍼런스 스타일의 “연구 리뷰 데이”와 함께 SCORE를 시작했습니다. 이를 통해 각자가 정기 상황 보고 때 다른 사람의 프로젝트의 상황을 이해할 수 있게 되었고, 매주 한번 점심 식사를 같이 하고 일주일에 한번 독서 모임을 가짐으로써 그룹 정체성을 키웠습니다. (increase group spirit)

[Why It Works for Us]

단순하지만, SCORE는 인상적인 결과를 가져왔는데, SCORE 적용 후 9개월 후에 조사를 했을 때 매우 긍정적인 대답을 들을 수 있었습니다. 우리 학생들과 이를 적용한 다른 많은 기관에서 받은 피드백을 종합했을 때 SCORE의 이점은 다음과 같습니다.

• 교수진이 시간 효율성 향상 (More efficient time use for faculty) – 보통 미팅 시간을 잡는 것이 상당히 어렵습니다. 일반적인 예약 방식으로는 미팅 시간(meeting slot)이 남거나 부족할 수 있고, 미팅 시간을 잡기 어렵다는 이유로 진행이 느려지기 쉽습니다. 또한 단편화된 많은 미팅으로 업무 전환 (context-switching) 비용이 많이 발생합니다. SCORE는 빠른 상황 보고와 기술적 심층 토론을 분리함으로써 이 문제를 해결하며, 심층 모임의 목적이 분명하기 때문에 더 생산적인 결과를 얻을 수 있습니다.
• 학생들의 생산성 향상 (Improved productivity for students) – 학생과 조언자가 자주 만남으로써 SCORE 상황 보고 미팅은 학생들의 사기와 생산성을 높여줍니다. 한 예로 정기적 미팅은 점진적인 프로젝트 진행을 독려하고 프로젝트 방향을 조정하는데 도움을 줍니다.

  많은 대학원생이 어려움을 겪는 시기가 있기 마련인데 일주일에 세번 진행하는 상황 보고 미팅은 이런 문제를 빨리 찾을 수 있게 해줍니다.

• 그룹 정체성 향상 및 정보 공유 (Improved group identity and shared knowledge) -  다른 사람들의 활동을 봄으로써 참가자들은 다른 사람들의 성공과 실패로부터 배우게 되고, 이를 통해 그룹의 추진력과 성취감을 높일 수 있습니다. 또한 프로젝트 진행 방식 등을 배울 수 있고 나의 진행 속도와 생산성을 비교해 볼 수 있습니다. 또한 소속감이 강해져서 동료의 성공에 즐거움을 느끼고 자신의 일에 더 큰 동기부여를 할 수 있습니다.  물론 동료의 실패를 통해서 위안과 동질감을 얻을 수도 있습니다. 결국 이를 통해 연구실에서의 시간을 더욱 가치있게 느끼게 됩니다.

  마지막으로 그룹 미팅은 교수진이 병목이 되는 것을 막아주고 학생이 스스로 조언을 주고 협업을 할 수 있도록 도와줍니다.

[Can SCORE Work for You?]

SCORE에 대해서 알게 됨으로써 이를 유용하게 적용해 보거나 다른 프로세스에 영감을 얻기를 바랍니다. 정기적 미팅은 교수진이 학생들과 같은 공간에 있거나, 비공식적 커피 타임을 갖는 등의 방식으로 변형이 가능합니다. 또한 SCORE는 지속적인 발전이 필요합니다. 예를 들어 아이디어를 만들고 토론하는 방식을 정립하지 못했습니다. 또한 심층 토론 때 나온 아이디어를 더 많은 사람들에게 공유하는 방식도 고민을 해야합니다.

대부분 공감이 가는 내용이고 실제 적용하는데 도움이 될 것 같다. 마지막에 아이디어를 만드는 방식은 ‘저자 워크샵(Writers’ Workshop)’이 좋을 것 같고, 서로 업무에 대해 대략적으로 공유하고 구체적인 진행에 있어서 스스로 도움을 줄 수 있는 구조가 중요한 것 같다.

참고)

SCORE 사이트: http://www.cs.umd.edu/projects/PL/score/

SCORE 전문(pdf): http://www.cs.umd.edu/~mwh/papers/score-short.pdf

팀에서 자기계발 과제로 작성한 ‘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: 물리적 네트워크 분산 환경에서 시스템이 잘 동작한다.

Availability와 Partition tolerance가 추상적 정의만으로 이해가 힘들 수 있어서 설명을 추가합니다. (용어 때문에 오히려 이해가 어려울 수 있는데 둘 다 파티션에 대한 특성으로 접근해야 합니다.) Availability and Partition Tolerance 글과 댓글을 참고하면 A, P에 대한 정의 및 기능이 좀 더 이해가 쉬울 수 있습니다.

• 장애 때문에 특정 노드들이 기약 없이 대기해야 한다면 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
• 기술적인 욕심 때문일까? 제대로 된 방향일까?
• Availability and Partition Tolerance

현재 Daum view 개발자를 채용중이다. Daum 인재채용 사이트에서 확인이 가능한데 최근 Daum에서 공격적으로 채용을 해서인지 개발직군만 10 몇 팀에서 채용을 진행중이다. 게다가 제주 근무 가능자가 제약조건이 되는지 생각보다 지원자가 많지 않은 상태이다.

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

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

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

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

어제 맥북에 윈도우 7을 설치했다. 설치방법을 찾아보니 잘 되면 ‘1시간’, 꼬이면 ‘5시간’이 걸린다고 하던데, 결국 8시부터 1시까지 딱 5시간만에 설치를 완료했다.

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

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

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

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

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

최근 NoSQL 관련 소식이 많이 들려서 나름 정리를 해보았다.

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에서는 이미 키워드 기반으로 사용자를 묶어주는 서비스를 준비하고 있으며, 사용자의 아이덴티티를 통합할 수 있다면 그 데이터를 기반으로 사용자의 관심을 알 수 있고, 이 관심을 기반으로 사용자를 분류할 수 있다.

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

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

어제 서울에서 열린 Xper 모임에서는 변신철님의 ‘존재하기와 발전하기’, 그리고 저의 ‘캐빈문화 소개’ 발표가 있었습니다. 애자일이 당연한 방법론으로 모든 곳에서 사용되고 있지는 않지만 여러곳에서 여러 사람들을 통해 꾸준히 확장되고 있음을 사례를 통해 느낄 수 있는 시간이였습니다.

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

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

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

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

캐빈문화 소개 – 즐거운 일터 만들기

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

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

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

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

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

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

BlogTalk와 Lift Asia에서 많은 사람들을 새롭게 만났다. 그들 중 몇 분에게 캐빈 문화에 대해 얘기할 기회가 있었는데 이곳을 통해서 좀 더 많은 분들에게 캐빈 문화를 소개하려고 한다.

캐빈 문화는 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(사명감)도 열정과 같은 의미가 아닐까? 난 가끔 여유를 열정보다 우선시하는 것은 아닐까? 글을 쓰면서 오히려 더 많은 생각들을 하게 된다.