brunch

매거진 IT 20년 썰

라이킷 13 댓글 2

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 야옹이버스 Jul 04. 2016

IT 15년 썰 - 7

파이 서비스 - 이미지 에디터의 신기원

2005년, 전략 프로젝트팀이 되었다.

기획자 몇과 디자이너 몇은 나보다 먼저 뭔가 고민을 시작했다.

그리고 어느 날, 서비스에 대한 설명을 들었고, 그 신규 프로젝트의 개발 총책임을 부여받았다.

(당시 우리 조직에서는 그 역할을 '개발 PL'이라고 불렀는데, 회사마다 조직마다 다 다르다.)

그 서비스는 '파이 (Pie)' 였다.

파이는 한마디로 표현하자면 '소셜 이미지 컬렉팅 서비스' 라고나 할까...

요렇게 생겼다.

파이서비스 - 모자이크형

파이서비스 - 비교형 (이 외에 릴레이형도 있음)

예를 들어 누군가 "기분 좋음을 표현하는 짤방 모아봐요" 라는 판을 만들면,

누구나 들어와서 한 조각 혹은 여러 조각 주제에 맞게 이미지를 채워서 완성을 시키게 되는.

그 당시 붐이 일던 이미지라는 '콘텐츠'와 새로운 방식의 '커뮤니티'를 고민하던 멤버들이 생각해낸 신선한 시도였다.

처음 설명을 들은 후 내가 했던 일은,

서비스의 기획안 중에 코어를 남기고 나머지 부분은 쳐내자는 제안이었다.

- 예를 들면, 처음 구상은 파이판 이외에 팩토리(커뮤니티) 개념도 있었는데,

- 그 부분은 다른 서비스들(예를 들면 카페)에서 커버하면 된다고 생각했다.

제안은 받아들여졌고, 서비스 오픈까지 개발기간을 3달로 잡았다.

그리고 3달 오픈을 위해 어떻게 진행하면 좋을지 고민했는데,

최대한 빨리 팀원들에게 굴러가는 구현체를 오픈하고, 서로 피드백을 받는 게 좋겠다고 생각했다.

그래서, 개발에 착수한지 딱 2주 후, 첫 버전을 팀 오픈했다.

지금 보면 린스타트업이나 MVP 가 떠오를 수도 있겠지만,
이때만 해도 그런 방법론이 딱히 자리 잡혀있지 않았었다.
* 린스타트업 : Eric Ries 가 2008년 처음 제안한 빠른프로토타입+지속적개선 을 주장한 개발방법론
* MVP (Minimum Viable Product) : 최소의 기능만 구현한 제품

여기서 팀 오픈이라 함은, 만들어가고 있는 모든 이 + 조언을 줄만한 사내 사람들에게 오픈인데,

사실 이 시점의 구현된 모습은 내부 사람들에게 조차 쓸만하지 않기 때문에,

팀 외 대부분은 관심도 없고, 팀내에서도 개발자를 제외하고는 쓰지도 않는다.

그럼에도 팀 오픈은 큰 의미가 있는데 그것은,

- 일단 내가 배포 플로우를 정립하게 되고,

- 테스트-스테이지-리얼 서버를 정의&세팅하게 되고,

- 문제 확인을 위한 에러 정리, 자동화 등이 차근차근 저절로 필요하게 되고,

- 무엇보다, 팀 멤버들이 배포 시점에 맞춰 본인들의 작업에 마침표를 한 번씩 찍고,

- 눈에 빤히 보이기 때문에 제일 먼저 필요한 부분부터 모두 알아서 집중하게 된다는 데 있다.

* 테스트 서버 : 마음껏 테스트해보는 서버
* 스테이지 서버 : 실제 서버와 똑같은 셋팅의 테스트 서버, 실제 배포하기 직전 테스트 용도
* 리얼 서버 : 유저들에게 서비스하는 서버

결국 개발은 서비스 오픈 예정일보다 2일 빨리 완료되었고,

서비스 도메인 주소에 대한 접근 권한은 정식 릴리즈 2일 전에 외부에 오픈되었다.

우리는 그렇게 미리 오픈된 상태로,

(도메인을 치고 들어오면 일반 유저도 들어올 수 있었다)

공식 오픈일을 기다렸다.

그 이틀간 우리는 배포도 했고, 로그도 봤고, 점검도 하는 상태로 유저의 인입을 기다리는 입장이었기 때문에, 편한 마음으로 트래픽을 맞이할 수 있었다.

(서비스 공개의 시점의 결정은 주어진 상황에 따라 다르므로 참고만.)

개발시작한지 2주만에 팀오픈 & 일정보다 빠른 개발 완료의 쾌거

파이 서비스는 신선한 서비스 콘셉트로 눈길을 끌었었는데,

내가 볼 때는, 그에 못지않는 더 큰 의미가 있었다.

당시 웹 표준이나 브라우저의 기능에는 한계가 있었는데,

- 파일을 컨트롤하는 기능, 이미지를 다루는 부분

- 인터렉티브 하게 화면을 조작하는 부분

이 두 가지가 쉽게 가능한 상황이 아니었다.

파이 서비스가 선보인 플래시(Flash)로는 이 두 가지 부분에 극복이 가능했고,

어찌 보면 국내 웹서비스의 방향성에 새 장을 열었다.

많은 기획자와 개발자들이 마시마로나 졸라맨에 불과하던 플래시를 다시 보기 시작했고,

파이 서비스 이후에, 많은 서비스의 에디터들은 플래시로 갈아탔다.

이미지 여러개를 다양한 레이아웃으로 한꺼번에 올릴 수 있다

이때만 해도 플래시는 Macromedia Flash 였는데 곧 어도비가 샀다.

플래시는 애니메이션 툴로 시작해서 프로그래밍 플랫폼으로 확장했고, 화려한 RIA(Rich Internet Application) 시대를 이끌었다.
플래시의 언어인 ActionScript 가 좀 더 대중화되고, Flex(개발 툴) 까지 나오면서 플래시는 전성기를 맞이하는데,
곧 이 바닥에서 경쟁 중인 AJAX 와 MS 실버라이트와 피 튀기는-ㅠ- 전쟁을 치렀고,
결과는 모두가 알듯이 javascript(AJAX)가 평정했다.

아마 당시 동료 몇 명이 국내에서는 Flex 로 실무 개발을 해 본 몇 안 되는 사람일 듯하다.
사내에서도 Adobe Flash 파와 MS Silverlight 파가 있었는데 사이좋게 개발 콘퍼런스에서 한 꼭지를 맡아 번갈아 설명하기도 했다.
하~ 이분들 현재 다양한 곳에서 능력들 펼치고 계시다 :)

그밖에 개발적으로는

확장성 & 분산 시스템 구조 고민,

연관파이를 보여주기 위한 키워드 연관성-맵 알고리즘에 대한 고민,

이미지 크랍, 파일 캐싱에 대한 고민,

동시작업(Concurrent Programming)과 효율성 동시 확보 등등에 대한 흥미진진한 도전들도 있었고...

요약컨대,

파이 프로젝트는 나에게 많은 의미를 남긴 경험이었다.

무엇보다, 파이 프로젝트를 진행하면서, '내 동료들을 즐겁게 일하게 해주고 싶다' 라고 강하게 느꼈다.

난 원래 그런 피가 흐르는 것 같긴 하지만, 이 시기에는 그것에 책임감을 느꼈던 것 같다.

오버하게 발랄을 떨었고,

살짝 넋 나간 행동도 여러 가지 했다.

밤이 되면 창문을 보면서 창문에 비치는 나에게 손을 흔들며 대화도 나눴고,