스타일쉐어는 패션 전문 소셜미디어 서비스를 표방하는 곳이다. 모델이 입은 패션 사진이 아니라 일반인이 직접 개인 일상 스타일에서 브랜드 신상 정보까지 패션의 모든 걸 나누는 소셜미디어를 지향하는 것. 지난 2011년 10월 문을 연 이 회사는 빠른 성장을 거듭해왔다. 지난해에는 네이버를 이긴 다윗으로 이름을 알리기도 했다. 네이버가 스타일쉐어를 모방한 패션 공유 서비스인 워너비를 내놨다가 결국 서비스를 접고 스타일쉐어와 상생협약을 맺은 것. 이 회사는 공개소프트웨어(오픈소스, 이하 공개SW)로 거의 모든 서비스를 구축했다.

스타일쉐어는 올해 5월에는 LB인베스트먼트 등에서 25억 원을 투자 유치하는 데 성공했다. 그 뿐 아니라 국내 50개 대형 패션 브랜드와 손잡는 건 물론 글로벌 진출도 서두르는 등 국내를 대표하는 종합 패션 플랫폼으로의 진화를 꿈꾸고 있다.

이를 반영하듯 회원 수는 벌써 100만 명에 육박하고 회원에 등록한 월간 액티브 유저 수는 30만 명에 달한다. 스타일쉐어를 찾는 패션 트렌드세터는 매일 12만 명에 이른다.

이런 폭발적인 성장을 뒷받침하는 홈페이지와 서버 등 개발 과련 부분은 모두 공개SW가 맡고 있다. 스타일쉐어가 사이트를 구축하기 시작한 건 지난 2011년 4월. 6개월 동안 당시 CTO를 포함해 내부 개발팀 2명이 사이트 개발에 나섰고 모바일앱 등은 파트타임 개발자가 참여해 완성했다. 당시 프로토타입 제작을 시작해 가을 미국 보스턴에서 열린 스타트업 경진대회에서 본선을 진출하는 바람에 오픈 일정을 앞당겼다고 한다.

◇ “공개SW, 성능과 안정성 모두 뛰어나다”=김현준 개발팀장은 스타일쉐어가 처음부터 공개SW를 이용해 구축했다고 말한다. 이후 기술적으로 추가된 건 있지만 기본 골격 자체는 공개SW로 대부분 완성했다는 것. 물론 가장 큰 이유는 경제성이었다. 당시만 해도 투자를 받은 상황도 아니어서 더더욱 절실했다는 것.

하지만 김 팀장은 “비싼 걸 쓸 수도 없었지만 공개SW 품질도 충분히 좋다는 게 중요했다”고 말한다. 사실 공개SW를 왜 사용하냐는 질문을 받는다면 돈 내고 쓰는 것보다 오히려 공개SW가 더 성숙하고 성능이 좋은 게 많다는 점을 강조한다고. “사실 사용하 수 있는 툴 중에서 찾다보면 공개SW인 경우가 많다”는 설명이다.

이런 안정성을 확보하게 된 데에는 대기업의 공도 무시할 수 없다. 오라클 DB를 쓴다면 그것 자체가 지속적인 고정비, 그러니까 라이선스 비용이 나가는 것인 만큼 사실 큰 기업 입장이라도 나가는 비용이 더 커지는 만큼 페이스북 같은 경우에도 마이SQL을 쓰는 등 큰 기업이 공개SW를 발전시키기 위해 더 노력하고 있다는 설명이다. 이런 노력이 공개SW 프로젝트도 성능이나 안정성 면에서 충분한 경쟁력을 확보하는 데 도움이 된다는 것.

스타일쉐어는 앞서 설명했듯 구축 자체는 거의 공개SW를 이용한 것이다. 사이트와 서버 등은 모두 파이썬(Phthon)으로 짜서 만들었다. 김 팀장은 4년 전부터 파이썬을 다뤄왔다고 한다. 그는 파이썬의 가장 큰 장점으로 생산성과 기술적인 면에서 훌륭하다는 점을 들었다. 기존 웹 서비슬을 만들 때 주로 쓰는 PHP나 ASP 등은 웹에 보이는 것과 안쪽에 있는 로직이 섞여 있다. 하지만 파이썬으로 구축하면 프론트엔드와 로직이 완전히 레이어를 분리하는 등 모듈화가 되어 있다. 덕분에 좀더 중복 작업을 하든 코드 관리 같은 것에서 득이 많다. 김 팀장은 그 뿐 아니라 “성능 향상을 꾀할 때에도 중복되는 로직이 없고 모듈화가 되어 있어서 훨씬 유리하다”고 설명했다.

스타일쉐어는 그 뿐 아니라 러시아 개발자가 만들어 전 세계 상위 1,000개 사이트 사용률에서 1위를 기록하기도 한 엔진엑스(NginX)를 비롯한 G유니콘(Gunicorn), 바니시 캐시(Varnish cache) 등 웹서버를 채택했다. 엔진엑스의 경우 페이스북과 네이버가 써서 유명해지기도 했다. 네이버 측은 엔진엑스를 채택한 이후 물리적 서버를 30% 줄이고 메인페이지 가용성을 3배 이상 높였다고 밝혀 공개SW의 안정성과 성능을 증명한 바 있다.

김현준 스타일쉐어 개발팀장은 “공개SW는 결국엔 상용보다 얻는 퍼포먼스 이득 더 많다”고 강조했다.

또 데이터베이스로는 포스트그레스큐엘(PostgreSQL)을, 여기에 데이터베이스와 웹서버 커넥션 중 너무 많은 커넥션을 잡으면 DB에 부하가 걸릴 수 있는 만큼 이 사이에 예를 들면 커넥션을 10개만 잡은 다음 다시 이를 100개로 분산해주는 식의 역할을 하는 피지바운서(pgBouncer)를 배치했다. 커넥션 쪽만 이곳으로 부하를 대리하도록 한 것이다. 그 밖에 분산 캐시 기술인 Memcached 등을 곁들였다.

웹서버 구현에 이용한 라이브러리도 모두 공개SW다. 웹서버 형태를 위한 웹 프로토콜 응답을 주고받는 역할을 하는 플라스크(Flask), 예를 들어 서비스 쪽에서 수많은 사용자에게 이메일을 발송하거나 알림을 하는 등 오래 걸리는 작업 등을 분산 처리할 때 이용하는 셀러리(Celery), 데이터베이스를 더 쉽고 편하게 다룰 수 있게 해주는 도구인 SQL알케미(SQLAlchemy), 이미지 관련 작업 처리를 위한 Wand 등이 그것이다.

스타일쉐어는 워낙 빠르게 급성장을 한 탓에 지속적으로 개선을 거듭해야 했다. 100명이 쓰는 걸 500명이 쓰는 건 어느 정도 흔히 쓰는 부하분산기법으로 처리할 수 있지만 그 이상이라면 아키텍처가 달라져야 한다고 말한다. 여기에는 서버가 지역적으로 한 곳에 위치할 수밖에 없는데 스타일쉐어는 글로벌 사용자를 염두에 두고 있는 만큼 아마존웹서비스(AWS)를 이용하는 점도 고려해야 했다. 이를 위해 스타일쉐어 서버는 일본 도쿄에 위치하고 있다. 다른 지역에 서버가 있는 만큼 같은 스타일쉐어 사이트를 방문해도 미국이나 유럽에선 서비스가 느리게 느껴지는 등 지역차가 발생할 수 있다.

현재 스타일쉐어에 매일 방문하는 고객 중 10% 정도가 해외 사용자라고 한다. 물론 많지 않다고 생각할 수도 있지만 내부에선 해외 시장에 아직 직접 마케팅을 한 번도 하지 않은 상태라는 점을 감안하면 앞으로 성장가치는 상당할 것으로 기대하고 있다. 어쨌든 김 팀장은 이런 국내에서의 폭발적인 트래픽 상승, 글로벌 서비스 2가지를 염두에 둬야 하기 때문에 사이트의 개발 방향은 늘 “트래픽과 부하와의 전쟁”이라고 표현한다. 이를 위한 첨병 역할을 하는 게 바로 공개SW다.

◇ 올 2월 2.0 서비스도 공개SW 덕 톡톡히 봐=스타일쉐어는 올해 2월 2.0 버전 서비스를 시작했다. 주제별로 패션 콘텐트를 모아서 보는 콜렉션 기능이나 취향에 따라 콘텐츠를 받아볼 수 있게 해주는 개인화 기능 등을 추가했다. 당시 김 팀장은 개발팀 입장에선 글 하나를 올릴 때 이전까지만 해도 사진은 하나만 가능했지만 페이스북처럼 사진을 여러 장 올릴 수 있게 바꾸고 사용자에 따라 취향껏 볼 수 있는 카테고리 기능을 부하 없이 구현하는 데 중점을 뒀다고 말한다. 스타일쉐어는 2.0 버전에서 국가별, 인기별, 최신별, 카테고리별 등은 물론 다시 이런 조건 체크를 여러 개를 눌렀을 때 복수로 나오게 하는 개인화 기능을 더했다. 개발자 입장에선 이런 건 모두 부하다. 캐시를 해놔도 몇 분마다 바뀌어야 한다. 김 팀장은 이를 위해 인기 알고리즘의 경우 자체를 아예 바꿔버렸고 실시간으로 더 많은 방문이 이뤄져도 좀더 견딜 수 있도록 사이트를 개선했다고 밝혔다.

김 팀장은 공개SW를 쓰면서 유지보수도 문제가 전혀 없었다고 말한다. 그는 오히려 “역시나 이게 훌륭하다는 느낌이 들었다”고 말한다. 예를 들어 포스트그레스큐엘만 해도 어레이(배열) 기능을 지원한다. 보통 RDB(Relational DataBase. 관계형 데이터베이스)에선 어레이 기능을 지원하지 않는 것도 많다. 값을 여러 개 넣는 것이야 쉼표 찍어서 해결할 수도 있겠지만 어떤 원소를 포함하고 있는지에 대해선 지원하지 않는 게 많다는 얘기다. 하지만 공개SW인 포스트그레스큐엘은 이를 지원, 카테고리 기능을 새로 2.0 버전에 추가하면서 무리가 전혀 없었다고 한다.

타일쉐어 아키텍처 다이어그램

인기 순의 경우에도 구현할 때 인기라는 걸 최신순, 좋아요 개수, 댓글 개수 등 다양한 조건을 따지게 된다. 이 중에서 부하가 가장 걸리는 건 좋아요가 몇 개인지를 실시간으로 계산하는 것이다. 매번 DB에 요청할 때마다 좋아요와 사진에 대해 조인을 걸게 된다. 애플리케이션 단에서도 가능하겠지만 포스트그레스큐엘은 데이터베이스에서 한 트랜젝션 안에 추가 쿼리를 실행할 수 있게 해주는 트리거 기능을 잘 갖추고 있다. 포스트그레스큐엘이 지원하는 자체 확장 프로시저 언어인 PLPGSQL 덕에 잘 처리할 수 있었다는 것. 데이터베이스가 아닌 곳에서 처리할 수도 있지만 이들 두 로직이 한 트랜젝션 안에 없다면 자칫 좋아요를 눌렀는데 카운터가 안 올라가는 등 문제가 발생할 수도 있다. 김 팀장은 이런 작업은 데이터베이스 단에서 하는 게 좋은데 공개SW가 원하는 대로 처리, 잘 동작한다고 밝혔다.

김 팀장은 굳이 2.0 버전 업그레이드가 아니더라도 평소에서 공개SW의 장점이 많다고 말한다. 앞서 설명했듯 스타일쉐어의 가장 큰 고민과 과제는 트래픽이 계속 늘면서 생기는 문제다. 늘어나는 트래픽을 어떻게 하면 데이터베이스에 부하를 안 주면서 앞쪽에서 캐시를 더 할 수 있을까 하는 것.

스타일쉐어는 이를 위해 한 달 전쯤 바니시 캐시(Varnish cache)를 도입했다. 바니시 캐시는 기본적으론 공개SW다. 물론 재잔에서 프리미엄 서포트, 그러니까 더 많은 기능은 쓰려면 돈을 내는 유료 버전도 선보였다. 하지만 스타일쉐어는 공개용만 도입했다. 만족감은 상당했다. 김 팀장은 바니시 캐시를 도입한 후 이전에 잦았던 장애가 확 줄었다며 만족감을 표했다.

스타일쉐어는 올해 하반기 새로운 비즈니스 모델을 실험적으로 도입할 계획이다. 광고보다는 패션 쪽 분야이다 보니 예쁜 옷 같은 걸 보러 오는 고객이 많다는 점에 착안, 이를 바로 구입할 수 있는 쇼핑몰이나 다른 쇼핑몰 연결 같은 비즈니스 모델을 붙여보려는 것이다. 두 방향 모두 실험을 해보고 결정할 가능성이 높다고 한다. 앞으로도 공개SW를 쓸 예정이냐는 질문에 김 팀장은 “사실 공개SW를 개발하면서 안 쓸 수는 없다”면서 “직접 개발팀이 개발을 한다면 10에 9은 공개SW를 이용한다”는 말로 스타일쉐어 역시 밝힌 내용보다 하나씩 따져보면 훨씬 많은 공개SW를 쓰고 있다고 강조했다.

※ 이번 공개SW 활용 성공사례는 테크홀릭과 정보통신산업진흥원 공개SW 역량프라자가 공동으로 발굴한 기사(http://www.oss.kr/oss_repository10/538421)다.

이석원 기자  lswcap@techholic.co.kr

<저작권자 © 테크홀릭, 무단 전재 및 재배포 금지>