빛을 담고 세상 넓히기

비슷한 분야의 회사를 여럿 경험하다 보면 그 회사가 그 회사 같을만도 한데 여전히 새로운 것들을 많이 배우게 된다. NHN에서는 새로운 기술과 시스템을 배웠다면 다음에서는 새로운 문화를 많이 배우게 되는 것 같다.

NHN에 속해 있을 때 한게임 웹 개발 랩의 내부 제도로 ‘이할 프로젝트’라는 프로젝트를 만들고 참여했었다. 업무 시간의 20%를 자유롭게 사용할 수 있도록 제도적으로 뒷받침해주는 것인데, 이를 통해 몇 가지 잼있는 개발 경험도 했던 기억이 난다. 하지만 시행 초기여서 그런지 업무 부담이 커서 그런지 아쉽게도 개발자의 참여가 활발하지는 않았다.

다음에는 이와 유사한 ‘C Time’이라는 제도가 있다. 정확한 기원이나 의미는 모르지만 내가 속한 파트에서는 매주 수요일 3시 ~ 6시에 하고 싶은 것을 자유롭게 개발하는데 활용하고 있다. (일주일에 3시간이면 10%가 안되는군요.) 처음에는 이 시간에 무엇을 할지 잘 몰랐는데 지금은 하고 싶은게 길게 줄서 있다. CI, BTS 환경 구축, 서비스 분석 툴 개발, 기획서 버젼관리 시스템(?)개발 등등. 물론 여기서도 업무가 과중한 시기에는 C Time에 참가하지 못하는 경우가 있지만 그래도 좀 더 문화적으로 정착되어 있는 것 같고 나름 의미있는 결과물들도 나오고 있는 것 같다.

또 하나 평범하면서도 이전에는 경험해 보지 못한 것이 ‘당직제도’이다. 웹 서비스를 개발하는 과정은 개발 주기가 매우 짧고 제품 릴리즈 후에도 지속적으로 유지/보수를 해야하는 특징을 갖고 있다. 결국 유지/보수 업무와 신규 프로젝트 참여가 서로에게 부담을 주는 경우가 많이 발생한다. 즉, 프로젝트를 개발하다가 긴급한 버그 패치 요청을 처리해야 하기 일수고, 또한 다음 프로젝트에 투입된 경우 이미 개발된 서비스의 튜닝 및 개선에 집중하기 힘든 구조이다.

다음 미디어 개발팀은 이 문제를 해결하기 위해 ‘당직제도’를 활용하고 있다. 프로젝트 담당 개발자가 3명이면 일주일에 한명씩 돌아가면서 당직이 되고, 당직은 버그 패치 및 장애 대처를 일차적으로 책임지게 된다. 당직제도를 통해 나머지 2명은 프로젝트에 집중할 수 있고, 당직은 서비스 개선에 집중할 수 있다. 이번 주에 첫 당직이 되었는데 새로 개편된 ‘블로거뉴스‘ 시스템을 튜닝하거나 새로 발생한 버그를 수정하고 서비스를 모니터링 하고 있다. (주말에 이러고 있으니 부작용이라고 해야할 것도 같네요.)

여전히 지나친 커뮤니케이션이 발생하는 노이즈를 어떻게 해결해야할지 고민이 되긴 하지만 다음의 이러한 열린 문화가 제도적 최적화 방식보다 더 생산적인 조직을 만들 수 있음을 경험하고 있다. 조직적으로 유지보수팀과 프로젝트 개발팀을 분리할 수도 있지만 프로젝트 일관성 유지와 효율성 강화에는 짧은 주기의 당직제도가 더 효과적인 것 같다.

지난 주 2박 3일 동안 ‘다음 개발자 컨퍼런스’가 홍천에서 열렸다. 4개의 키노트와 8개의 세션을 듣는 강행군이였지만 다양한 분야의 최신 기술 동향과 경험을 들을 수 있는 좋은 기회였다.

첫날 Pecha Kucha 형식(20장의 슬라이드를 20초씩 발표)으로 진행된 ‘아고라와 촛불’이라는 발표에서 아고라 담당 엔지니어는 ‘개발자는 시스템을 통해서 사회와 소통한다’라고 얘기했다. 지금도 촛불 정국을 떠올리면 약간의 가슴 떨림을 느낄 수 있는데, 그 당시 아고라 서비스를 정상적으로 운영하는 것은 결코 쉬운 일이 아니였을 것이다. 장비를 투입하고 쿼리를 튜닝하고 장애 대처를 하면서도 사용자들의 데이타를 보호하고 정확한 정보를 전달하기 위해 노력했던 것이다. 이러한 시스템을 통해 사용자들은 서로 소통할 수 있고 다양한 정보를 생산하고 공유할 수 있었을 것이다.

사실 이 발표를 듣고 개인적으로 느끼는 점이 많았다. 최근 다음으로 이직을 하고 새로 담당하게 된 서비스는 ‘블로거 뉴스‘라는 대안적 미디어 서비스였고, SNS가 무엇인지, 미디어의 역할은 무엇인지, 그리고 블로거 뉴스가 서비스적으로 어떤 가치를 가지고 있는지 많은 고민을 하고 있었다. 하지만 이런 고민보다 먼저 사용자가 원하는 (또는 기획자를 통해 투영된) 서비스를 어떻게 구현할 수 있을지 더 근본적인 해결책을 찾아야 하는 것은 아니였을까.

‘Social Network - 웹을 통해 구현되는 사회적 연결’은 정보의 생산과 유통을 사회적 활동을 통해 보다 활성화시킴으로써 가치를 창출하는 것이다. 사용자들이 블로그를 작성하고, 글을 올리고, 또한 글을 읽고 추천하는 모든 행동들을 통해 보다 가치 있는 글을 노출시키고 또한 정보 생산의 가치를 (실질적으로) 공유할 수 있는 구조를 만들기 위해서는 서비스 기획과 함께 시스템의 깊은 고민이 수반되어야 한다.

정보 생산자와 소비자, 그리고 이를 위한 장을 마련하는 서비스가 모두 함께 성장할 수 있는 생태계를 만들기 위해 개발자로서 사회적 역할을 찾고 싶다.

NHN에서 받은 마지막 YES24 쿠폰으로 책을 4권 샀다.

여러 곳에서 최고의 프로그래밍 책으로 뽑힌 ‘Alice’s adventures in Wonderland & Through the Looking-glass’를 읽으면 나는 무엇을 볼 수 있을까? 아마도 언어의 제약을 뛰어넘는 언어의 사용을 통한 상상력을 볼 수 있어야 할텐데 외국어의 한계로 겉만 핥는 것은 아닐지…

그 외에 ‘이기적인 유전자’를 읽고 다시 찾은 또 하나의 진화론에 관한 책 ‘풀하우스’, ‘엘러건트 유니버스’ 이후의 이야기를 쓴 ‘우주의 구조’, 그리고 최근에 번역된 또 하나의 애자일 시리즈 ‘스크럼‘을 샀다.

아직 책을 읽지는 않았지만 스크럼에 읽고 적용해 보고 싶은 것이 있어서 이 글을 쓰게 되었다. (물론 스크럼을 적용하는 것이 목적이여서는 안되고 프로젝트의 성공을 위해 팀에 맞는 방법을 사용하는 것이 중요하다.) 스크럼은 ‘일일 스탠딩 회의’, ‘번다운 차트’, ‘짧은 반복 주기’ 등 그 원리는 단순하지만 이를 적용하려는 조직의 특성에 맞춰 새롭게 적용 방법을 고민해야 한다.

그렇다면 결국 현재의 조직의 특징을 파악해야 하는데, 내가 한달 동안 경험한 B 파트의 모습은 다음과 같다.

• PP(페어 코딩?)는 아니지만 페어 작업을 선호한다. 매우 유연한 또는 덜 엄격한 PP
• 매일 아침 그날 할 일을 계획한다. TASK 형태로 할 일과 예상 작업 시간을 포스트 잇에 정리한다.
• TO DO, DOING, DONE, QUEUE, SOMEDAY 로 나눠진 커다란 화이트 보드를 사용한다.
• 프로젝트 구성원, 파트원, 관련자(기획자)와 자주, 많이 의사소통한다. (메신져, 미팅 등)
• 중요한 안건은 아이디어 회의를 통해 결정한다. 결정은 유연한 편이다. (외부 조직의 압력이 적다.)
• 당직 제도를 통해 상시적 업무는 매주 돌아가면서 처리한다. (context switching 비용이 적다.)

전체적인 느낌은 ‘열린 사고’, ‘커뮤니케이션’을 중시하고 ‘협업’의 이점을 잘 살리고 있다는 것이다. 하지만 개인적으로 이전에 애자일 방법론을 도입하면서 항상 부딪혔던 ‘타성화’의 문제라던가 열린 커뮤니케이션의 노이즈 같은 문제를 개선할 필요는 있을 것 같다. 즉, PP를 하면서 서로 배우는 것이 없다거나, 일일 스탠딩 회의가 친목 활동과 혼재되는 경우라 하겠다.

그래서 스크럼을 통해 다시 한번 간단한 규칙을 통해 팀 효율화를 크게 향상시킬 수 있는 방법을 찾아보고자 한다. 그리고 이 방법을 통해 ‘웹 개발’ 직군이 지향해야 하는 모습을 그려 보고자 한다. (이전에 ‘미들웨어’에 관한 글을 썼었는데, 웹 개발은 UI 개발과 인프라, QA, 모듈화(OSGi) 등을 통해 세분화되고 전문화되고 있다. 그렇다면 ‘코어 웹 개발자의 역할’은 무엇일까? 이에 대해서는 다음에 다시 정리해 보면 좋을 것 같다.)