다음 캘린더 서비스 개발 비하인드 스토리

이 글은, 다음 캘린더 서비스 개발자가 개인적으로 적은 뒷이야기입니다. 오래전 부정확한 기억에 기반했기에 사실과 다른 주관적인 내용이 포함돼 있을 수 있으니, 심각하게 읽지는 않으셨으면 좋겠습니다. 관련해서 떠오르는 다양한 주제의 산만한 생각을 정리했습니다. 일관된 주제 없이 개인적 회고에 불과하지만, 다른 서비스 개발자분들에게 도움이 될만한 경험이 전달되기를 기대합니다.

캘린더 서비스와의 인연

얼마 전 다음 캘린더 서비스 종료 소식을 접했다. 카카오와의 합병 이후, 정리할 서비스 목록에 포함된 것 같고, 사실 카카오의 색채와는 잘 어울리지 않는 것 같기도 하다. 자세한 내막은 난 이제 외부인이니까 알 수가 없고, 사실 알아봐야 뭐하겠는가? 그저 사실은 서비스가 종료됐다는 것이다.

캘린더 서비스와의 인연은 어쩌면 그 누구보다 깊을지도 모르겠다. 다음에 근무하면서, 여러 서비스 개발에 관여했지만, 캘린더 만큼은 아마도 “내가 만들었다”라고 말하는데 그 무게가 크게 실릴 서비스였다. (물론 혼자 만들었다는 뜻은 아니다.)

개발에 참여했던 다른 서비스들은, 카페처럼 이미 많이 만들어진 상태에서 참여해 몇몇 추가 기능을 구현하며 운영에 참가하거나, 아니면, 마이피플처럼 아주 초기에 프로토타입 개발에 참여하고 정식 개발팀에 넘기고 빠지는 식이라서, 상대적으로 그 주인 의식이 약한데, 캘린더의 경우 아주 초기 개발부터, 어느 정도 한계선에 이를 때까지를 주도적으로 참여할 수 있었기에 느낌이 남다르다.

인제 와서 뭔가를 적어 봤자, 지나가 버린 날의 구차한 뒷얘기들을 추억하는 궁상스런 일이겠지만, 그래도 한 번쯤은 회고를 해보는 것도 좋을 것 같다는 생각이 든다. 당시에 경험으로 배웠던 몇 가지 일들을 공유하는 데에 모종의 가치가 있을지도 모르고 말이다.

캘린더 프로젝트의 시작과 오픈

프로젝트가 시작된 시기는, 일본 지사에서 1년 반 근무 후 멘붕된 후 본사에 복귀해서 이대로 계속 회사를 다녀야 하나 고민하던 즈음이었으니까, 2006년이었던 것 같다. (아, 벌써 그렇게 오래 되었나?)

당시 CTO 직속으로, 다른 개발자 A와 함께 웹2.0 시대에 맞춘 신규 프로젝트를 고민하던 차였는데, 해외의 서비스들을 참고해서(라고 쓰고 베낀다고 해석한다) 기획자 없이 직접 기획해 개발하기로 했고, 물망에 올랐던 서비스는 RememberTheMilk라는 할일 관리 서비스와, 구글 캘린더였다. 지금은 기본이자 당연한 AJAX가 당시에는 막 선보인 시점이라, 웹페이지를 리프레시하지 않고, 화면이 유지된 상태로 사용자와 인터랙션하는, 바야흐로, 웹 “애플리케이션” 시대의 시작이었다.

중간 과감하게 생략해서, 구글 캘린더를 목표로 한 서비스를 베타 오픈을 했고, 한메일 익스프레스와 함께, 다음 최초의 웹2.0서비스로 공개됐다. 게다가 Daum에서 최초로 (그리고 아마도 마지막으로) RubyOnRails로 개발해 공개한 서비스다. (그 때문에 이후에 두고두고 욕을 먹게 된다.)

알고리즘(?)이 필요했던 서비스

활용해보고 싶었던 Ruby와 Rails와 Git, Nginx등을 도입해서 실 서비스에 활용했던 점도 개인적인 개발 경력에서는 큰 자신감이 되었고, 또 한편, 처음으로 알고리즘다운 것을 실용한 기회였다.

무슨 얘기냐 하면, 사실 포털에서 웹서비스 개발자로 근무하면서 개발한 거의 모든 일이, 학창시절의 알고리즘 수업과는 거의 무관하게, 거의 DB에 값 넣고 빼고 하는 일이 전부인 것으로 요약할 수 있었다. 엔지니어링의 측면에서, OS나 다른 소프트웨어를 잘 조절하고, 가져다 쓰고, 조절해서 쓰고, 문제가 되는 것을 우회해서 피해가며, 대용량 서비스에 대비하며, 문제가 생기면 문제점을 파악하고 해결하고 하는 일들이 메인이지, 뭔가 책 속에서 나온 이론적 알고리즘을 적용할 필요는 없었던 것.

비슷한 얘기로, 후에 동료 개발자 K가, “난 그저 입력받아서 DB에 넣고 빼고 하는 CRUD밖에 할 줄 모른다.”라고 말하기에, “음, 그럼 전부 할 줄 아는 거네요?”라고 답한 적이 있을 정도로, 사실 웹 개발자의 전부는 그게 다일지도 모른다. 수준 높게 개발하시는 분들이야 통계도 도입하고, 머신 러닝도 들어가고 수학적 모델도 필요하고 그러겠지만, 내가 머문 좁은 세계는 그러했던 것.

그 와중 캘린더 서비스에는 조금 고민이 필요했던 것이, 월간/주간/일간 일정을 보여주는 화면에서 여러 날이나 시간에 걸친 일정들을 막대 형태로 화면에 보여줄 때, 그 일정들이 겹쳐 보이지 않게 잘 배치하고, 차곡차곡 잘 쌓여 보이게 하는 문제가 있었다. 나름 잘 배치하고, 구글 캘린더에서는 깨져 보이는 상황조차도, 제대로(?) 렌더링하는 내(!) 서비스를 보며 혼자만 흐뭇해 했던 기억이 있다. 내부 기획팀을 비롯한 대다수 사람들은 그게 뭔지 관심도 없었다. 관심도 없었으니 별다른 인정도 없었고.

그 누구도 인지하지 못했지만, 스스로 아직도 즐겁고 뿌듯한 기억으로 남아있으니, 어쩌면 남들의 인정보다, 개인적으로 작으나마 성취감을 느낄 수 있는 보이지 않는 일들이 더 중요할지도 모르겠다.

경쟁사의 서비스 오픈

비슷한 사업분야를 펼쳤던 N사의 행보가 흥미로웠는데, 당시의 추세는 뭐랄까, 다음이 1위인 N사와 격차가 큰 2위 업체인 상황에서 어떻게든 추격을 꾀했고, 그런 처지에서 더 도전적이고 진취적인 서비스를 먼저 오픈하는 사례가 더러 있었다. 그걸 살짝 한발 뒤에서 지켜보던 N사는, 다음이 오픈한 서비스의 가능성이 보이면, 그보다 더 많은 인력과 자금을 활용해 후발로 따라서 만들어 오픈하고는 했다. 이른바 전문용어로 “패스트 팔로워 전략”이라나? 캘린더도 마찬가지였는데, 이미 다음 캘린더 서비스를 개발해서 오픈하기 전에도, N사에서도 개발팀이 꾸려졌다는 얘기를 듣고는 했다.

때로는, 이런 경쟁이나 카피 제품에 대한 도덕적 반감을 갖게 되기도 하지만, 어쩌면 그런 논쟁은 무의미할 수도 있다. 어차피 완전 무에서 창조하는 서비스는 없을뿐더러, 캘린더 서비스의 경우에는, 구글 캘린더, iCal, 아웃룩 일정등의 서비스를 베끼지 않고 만들었다고 하기 어려운 면이 크니 말이다.

사실 좀 그 도가 지나친 부분이라면, 경쟁사 서비스의 웹소스를 열어보니 우리 회사의 js소스를 그대로 가져다가 활용한 경우가 있었는데, 주석이라도 좀 바꾸지, 참 뻔뻔하게 주석이나 제작자 이름이 남아있는 채로 보인 적도 있어서 황당해 했던 적이 있다. 당시에는 욕을 하며 흥분했지만, 지금 생각해보면 참 재밌는 일이다. 그렇게 그냥 가져다가 넣은 개발자는 무슨 생각이었을까? 어쩌면 서로 베끼고 베끼는 그렇고 그런 현실을 제대로 직시하고 맘속 깊이 받아들여 깨우친 현자는 아니었을까? ㅎㅎㅎ

아니면, “옛다, 크레딧은 남겨주마” 뭐 이런 건가?

동종 업계에서는 기획자들도 서로 인맥이 닿고 연결되기 때문에, 우리가 뭘 하거나 거기서 뭘 하면, 사실 적지 않은 부분이 공공연히 서로 공유되고는 했다. 베타 오픈을 하고 한창 개발하고 있던 시절에도, N사의 개발팀 구성 소식을 들었다. 우리보다 열 배 정도의 인원이 킥오프에 들어갔다는 소식을 들었으나, 서비스 방향에 대한 얘기를 듣고는, 내심 크게 안심했다. 무슨 말도 안 되게 이상적으로 N사의 모든 서비스에 걸쳐서 캘린더를 연동하는 야심 찬 기획에, 혀를 끌끌 찰 수밖에 없었다.

“그게 될 것 같은가?”

우리 기획팀은 곧 N사의 훨씬 뛰어난 일정 서비스가 오픈될 거라며 호들갑을 떨며 우리 개발팀을 압박해 왔지만, 난 그 일정은커녕 구현 목표가 달성되지 않을 거로 생각했다. 제발 처음 서비스를 오픈할 때는 작게 시작하자. 큰 그림 잘 그리는 위대한 사람이 되고 싶겠지만, 실상은 작은 그림도 실현하지 못하는 허울뿐인 경우가 될 수 있으니 조심하자. 큰 그림을 갖고 장기적으로 추구하는 것이 맞겠지만, 구현의 시작은 차근차근 단계적으로 해야 한다.

결국, 한 1년여의 시차를 두고, 원래의 원대한 포부는 거품이 꺼진 N사의 캘린더 서비스가 공개됐고, 살펴보면서 또 한 번 실망한 것이, 우리 서비스를 너무도 그대로 베껴서 오픈 한 것이었다. 당시 캘린더 기획자였던 동완짱이 나름 구글 캘린더와의 차별점을 두고 디자인한 내용이 너무 뻔하게 거의 그대로 드러난 점이 실망스러웠다. 아무리 서로 베끼고 베끼는 그런 현실이었지만, 도무지 별다른 고민이 느껴지지 않았달까.

어쩌면, 뭐 그냥 똑같이 만들어도, 더 많은 고객 수를 바탕으로 자연히 경쟁 우위를 점할 것이라고 여겼을지도. 이러니저러니 해도 결국 따져보면, 다음의 캘린더 서비스는 종료했고, N사의 서비스는 아직도 멀쩡하게 운영되고 있으니, 이렇게 무어라 얘기해봤자, N사의 결과적 승리일 뿐이다. 조금 씁쓸하지만, 그게 현실인걸.

프로세스와 가이드의 효용과 한계

한 회사의 서비스로 오픈하려면, 당연히 한 회사 색채에 맞게, 로고나 디자인을 비롯한 UI/UX의 일관성이 중요하겠다. 큰 회사이니만큼 그 가이드와 프로세스가 정해져 있었는데, 예를 들면 이런 식이다. 화면 상단의 네비게이션은 반드시 몇 px높이이며 하단의 푸터에는 어떤 내용을 반드시 포함한다는 식의 구체적인 내용이다.

프로세스와 가이드가 잘 정리돼 있으면, 그 후 시점의 일정 기간 동안 효용이 증가한다. 전체 프로젝트의 일관성이 유지되며, 불필요한 고민이 줄어들어 효율적인 작업이 가능한 것이다.

하지만, 그게 다가 아니다. 이 프로세스와 가이드가 굳어져 버리면, 판이 흐름이 바뀌었을 때, 걸림돌이 되곤 한다. 캘린더 서비스도 마찬가지였다. 한 페이지 웹애플리케이션의 시작이다 보니, 한 화면에 많은 정보를 담아야 하는데, 가이드에 정리된 헤더와 푸터등을 맞춰 넣으면, 정작 보여줘야 할 중요한 정보를 담을 공간이 부족한 것. 가이드는 전통의 웹페이지 방식이었기 때문에, 그 가이드에 맞추자면 맞지 않는 옷을 입게 되는 꼴이 된다. 이런 일들은 늘 벌어진다. 웹 2.0시대가 와도 그렇고, 모바일 디바이스의 세상이 와도 그러하고, 앞으로 또 무슨 환경에 변화가 생겨도 같은 상황은 일어날 것이다. 그리고 환경의 변화는 계속 일어난다.

결국, 해당 가이드의 예외 조항 등이 생겨서 우회해 갈 수 있었지만, 적잖은 시간을 지체하며 여전히 우리 서비스가 보이고자 했던 완전한 정보에는 부족한 지점에서 타협할 수밖에 없었다. 프로세스와 가이드도 시대의 변화 시점에 대응해 업데이트 되어야한다.

UI 가이드뿐 아니라 개발 프로세스도 마찬가지였다. 갖가지 프로세스가 실 서비스 오픈 후의 빈번한 문제들을 예방해주는 데 도움이 되었지만, 이미 전통적인 방식의 PV 측정 인프라나, 스트레스 테스트 등을 기존 스타일로 진행해야 해서, 몇 가지 작은 걸림돌이 있었고, 사실 서비스의 본질에는 큰 영향이 없는 허들일 뿐이 아니었나 싶다.

대용량 트래픽에 대한 고민

국내의 대부분의 인터넷 이용자가 아이디를 가진 회사에서 서비스를 개발할 때에는 응당, 대용량 트래픽에 대한 고민을 하게 된다. 그것도, 습관적이고 무의식적으로 모든 프로세스에 고민이 녹아들어 간다. 많은 사용자가 몰렸다고 장애가 나고 진땀을 흘리게 되는 경험을 해보고, 그 여파가 적지 않은 상황을 만나게 되면, 직접 경험한 사람이나, 옆에서 지켜본 간접경험자도 기대 반 두려움 반의 대비를 하게 되는 것.

캘린더 서비스도, 대한민국 모든 지식근로자의 책상에서 탁상달력을 제거하자는 원대한 비전을 갖고 나아갔으므로, 목표 사용자 수도 클 수밖에 없었고, 그에 대비하지 않을 수 없었다.

베타서비스 오픈 초기에 사용자 DB를 master-slave 한 세트를 통으로 관리하고 있었고, 대용량 서비스의 기본으로 DB샤딩(sharding)을 고려하기 시작했다. 이미 단일 세트로 구현한 서비스를 샤딩 분리하는 것은 나름 복잡하고 시간이 필요한 일이다. 여기에 시간을 꽤 허비했는데, 결과적으로는, 하나 쓸데없는 고민이자 시간낭비였다.

왜냐하면, 대한민국의 온라인 캘린더를 사용할 사용자의 수를 다 모아 봤자, DB 샤딩이 필요할 만큼의 엑세스가 필요하지 않기 때문이다. 게다가 캘린더 DB는 그 액세스가 매우 단순하다. 한마디로 요약해, 대용량 트래픽 고민을 할 필요자체가 없었다. 약간의 캐싱 처리와 몇 가지 성능 고려 작업만으로도 충분히 처리할 수 있고, 샤딩 처리를 위한 애플리케이션 서버 레벨의 복잡도를 높이기보다는, 단순히 처리하고 더 나은 기능을 구현하는 것이 나은 선택이었다.

이런 “대용량 트래픽 대응”은 웹서비스 개발자가 흔히 빠지는 함정에 가깝다. 빠르고 튼튼한 서비스를 만들고 싶은 욕심과, 트래픽으로 인한 장애 경험이 만난 시너지로 흔히 저지르게 되는, “성급한 최적화 오류”의 일종이다. 어쩌면, 한때 크게 흥했다가 트래픽 대응 실패로 패망한 아이러브스쿨에 대한 트라우마가 만연해 있는 것은 아닐까?

구체적으로 얘기해보자. 대한민국에 온라인 캘린더를 정기적으로 사용할 사람이 10만 명은 될까? 그래 낙관적으로 10만 명이 된다고 치자. 그렇다고 할때 DB sharding처리까지나 필요한가? 파티셔닝 정도로 충분하지 않을까?

당신의 서비스는 어떠한가? 10만 명의 사용자가 정기적으로 활용할 서비스를 만들고 있는가? 당연히 그렇겠지, 꿈은 그러할 테니까. 그럼 다르게 묻겠다. 당신의 서비스가 10만 명이 될 때까지의 시간은 얼마나 필요할까?

오해를 막자면, 트래픽 대응이 필요하지 않다는 뜻은 아니다. 대용량 트래픽 대응 기술은 어쩌면 내 커리어의 핵심 가치일지도 모르는데, 폄하하려는 의도는 아니다. 그리고 트래픽이라는 것이, 서비스 성공과 즈음에 폭발적으로 증가하는 경향이 있으니까 말이다. 필요한 중요 기술이고 고려해야 할만한 일이지만, “성급히 모든 일에 최선의 대응이 필요하지는 않다”는 점을 강조하고 싶다.

심지어, 사내 개발자가 사용할 서비스를 만들면서도 나도 모르게 대용량 트래픽 대응을 위한 고민을 하며 개발하는 자신을 인지해 우스웠던 상황도 떠오른다. 사내 개발자가 쓰는 웹서비스인데, 고작 수백 명이 접근하는 서비스에, 별도 DB가 필요한가? SQLite처럼의 작고 간단한 임베디드 DB로도 충분하지 않을까?

단계와 목표 수준에 적절한 대응을 고려해야지, 미리부터 모든 대응을 성급히 하지는 말자. 서비스 성공 시 발목을 잡히면 곤란한 것이야 맞지만, 그 모든 고민에 앞서서 서비스 성공이 먼저이다.

비유하자면, 별로 달릴 만한 곳도 없는 도심 도로를 달릴 승용차를 만들고자 하면서, F1 경주용 차량에 들어가는 기술을 구겨 넣느라 애쓰지 말자는 얘기다. 돈도 돈이지만 승차감 구려진다.

큰 기업에서 신규 기술을 도입하는 것에 관해

당시 사내 서비스 개발의 표준은 Java 웹 애플리케이션이었다. 거기에 레일스를 도입해서 쓰겠다는 일은 여러 가지 허들을 만나게 됐고, 결국은 잘 써서 오픈했지만, 두고두고 비합리적인 비판을 듣게 된다.

첫 번째는, 성능이 문제 된다는 태클이었지만, 사실 캘린더 서비스에 성능은 당시 매우 느린 JS엔진을 가진 IE에서 도는 코드가 병목이었기 때문에, 서버 단의 성능은 주안점이 아니었음에도, 막연한 비판을 듣게 된다. 성능이라는 건 사실 무작정 모든 면에서 미리 대응하는 것이 아니라, 암달의 법칙을 고려해, 병목 지점을 찾아서 개선하는 후작업이 중요하다.

그리고, 흔히 여기서도 20:80 법칙이 적용되는 경향이 있어, 전체 시스템의 20%에서 80%의 시간을 소요하므로, 그 20% 지점에 해당하는 일들을 찾아서 튜닝하는 것이 기본이다. 대부분의 경우도 그렇고, 캘린더 서비스도 그렇고, 웹 애플리케이션 서버가 그 20%에 해당하는 경우는 드물다. 정말, 트래픽이 몰리고, 루비로 도는 애플리케이션 속도가 문제된다면, 그제서야 교체해버려도 되고, 아니면 그 중의 병목을 찾아 C 익스텐션으로 바꿔버리면 되는데도, 그 “인터프리터 언어는 느리다”라는 문장은 늘 듣게 되는 태클이었다. 사실상 그냥 태클인지라 논리와 자신감으로 대응할 수 있지만, 그때마다 일일이 대응해야하는 상황이 피곤한 일임은 어쩔 수 없다.

“트위터도 루비 쓰던 거 다 걷어냈대요.”

“아, 그건 트위터고요! 트위터 만큼의 트래픽을 받을 건가요? 그런 행복한 일이 생기면, 제가 일일이 포팅할게요.” 라고 말하기도 뭐하다.

두 번째는, 루비 개발자를 구할 수가 없어서, 타 팀에 인계하기 어렵다는 점인데, 이 점은 태클이라고 치부하기는 어려웠다. 사실 모태Java 개발자가 대다수인 회사에서 루비 개발자를 찾거나 새로 채용하기는 어려운 점은 부정할 수 없었다. 한 가지 아쉬웠던 점은, 그럼 Ruby를 새로 공부해서 개발하고자 하는 개발자가 그 수많은 개발자 중에 별로 없다는 점은 아쉽다. 프로그래밍 언어의 선택은 기술적이라기보다는 거의 종교적에 가까운 경향이 있으므로, 개발자마다 취향과 선택이 다를 수 있다. 그리고 하나의 새로운 언어나 프레임워크를 배우는 것은 꽤 많은 노력이 드는 것은 사실이지만, 지금 쓸 줄 아는 한가지 언어만을 고집하는 것은 아쉬운 점이다.

어쨌든, 결과적으로, 한 기업에서 만연해있는 기술 기반에서 벗어나는 시도는 여러모로 에너지를 뺏기는 일들이 많이 생긴다는 점을 염두해 두고, 그만한 투자가 필요한 정말로 필요한 일인지는 고민해보고 노력해보는 것이 맞겠다.

그러나, 이런 경험에도 불구하고, 후에 SVN을 주로 쓰던 사내 개발 환경을, 굳이 여러 고생을 사서 하며 Git을 도입하려고 했으니, 난 어쩌면 그런 팔자를 타고 난 것 같기도 하다. 앞으로도 그러고 살겠지.

서비스 종료에 관해

본인이 개발에 참여한 서비스가 망하면, 갖가지 감정이 일게 된다. 아무래도 내 서비스라는 애착을 갖고 열정을 부었던 일이 수포가 되는 것이니 말이다. 몇 번 비슷한 경험을 하면, 중간중간, 애착을 갖지 않으려고 시도하기도 하고, 또 새로 참여하는 프로젝트에서도 “이 서비스도 망하지는 않을까?” 앞선 걱정을 하기도 하고, 또 될성 싶지 않으면 건성으로 참여하게 될 때도 있다.

그러나, 자신의 아까운 젊은 시간을 들여 일하는 것이니만큼, 애착을 갖고 열정을 다하되, 그리고 나서의 서비스의 성패는 내 권한과 능력 밖임을 인정하고 받아들이는 편이 맞겠다.

말처럼 쉬운 일은 아니지만 말이다.

인연은 이어진다

캘린더 TFT를 떠난 지도 근 10년이 지났고, 심지어 서비스도 종료됐지만, 난 오늘 CalDAV 스펙을 다시 보고 있다. 프리랜서로 참여하고 있는 프로젝트에서 관련한 내용이 필요한 것. 애초에 이 프로젝트에 참가할 수 있었던 것도, 오래전이나마 캘린더 서비스를 개발한 경력 때문이기도 하다. 캘린더 서비스는 종료됐지만, 그 경험은 이어지고 있다. 그때의 몇몇 추억도 되새기며 말이다.

9월 1일에 종료했고, 지금은 10월이 다 끝나가지만, 뒤늦게 작별인사를 한다.

“다음 캘린더”, 바이바이.