본문 바로가기

Home > 정보마당 > 공개SW 활용 성공사례

공개SW 활용 성공사례

네이버 이긴 다윗의 선택은 공개SW

스타일쉐어는 올해 5월에는 LB인베스트먼트 등에서 투자를 받아 25억 원을 유치하는데 성공했다. 뿐만 아니라 국내 50개 대형 패션 브랜드와 손잡은데 이어 글로벌 진출도 서두르는 등 국내를 대표하는 종합 패션 플랫폼으로의 진화를 꿈꾸고 있다. 지난해에는 네이버를 이긴 다윗으로 이름을 알리기도 했는데 네이버가 스타일쉐어를 모방한 패션 공유 서비스인 워너비를 내놨다가 결국 서비스를 접고 스타일쉐어와 상생협약을 맺은 것. 이 회사는 공개SW로 거의 모든 서비스를 구축했다.

- 기     관 스타일쉐어
- 수행년도 2011년
- 도입배경 스타트업 초기부터 비용절감과 기능구현이 가능한 공개SW를 우선 도입
- 솔 루 션 Phthon, Nginx, Gunicorn, Varnish cache, PostgreSQL, pgBouncer, Memcached 등
- 도입효과 : 파이썬 등을 이용해 중복되는 로직이 없고 모듈화를 해서 성능 향상 등에서 훨씬 용이함
바니시 캐시 등을 도입, 기존 장애를 상당 부분 해결, 부하 분산 효과 얻음
PostgreSQL를 DB로 채택해 원활한 2.0 버전 서비스 구현

스타일쉐어(www.stylesha.re)는 패션 전문 소셜미디어 서비스를 표방하는 곳이다. 모델이 입은 패션 사진이 아니라 일반인이 직접 개인 일상 스타일에서 브랜드 신상 정보까지 패션의 모든 걸 나누는 소셜미디어를 지향하는 것. 지난 2011년 10월 문을 연 이 회사는 빠른 성장을 거듭해왔다. 이를 반영하듯 회원 수가 벌써 100만 명에 육박하고 회원 등록한 월간 액티브 유저 수는 30만 명, 매일 스타일쉐어를 찾는 방문자들도 12만 명에 이른다고 하니 패션 트렌드세터 사이에서는 ‘쏘 핫’한 사이트가 됐다.

 

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

 

공개SW, 성능과 안정성 모두 뛰어나...

김현준 개발팀장은 스타일쉐어가 처음부터 공개SW를 주축으로 구축했다고 말한다. 이후 기술적으로 상용SW가 추가된 점이 있지만 기본 골격 자체는 공개SW로 대부분 완성했다는 것. 물론 가장 큰 이유는 경제성이었다. 당시만 해도 투자를 받은 상황도 아니어서 더더욱 절실했다는 것이다.
하지만 김 팀장은 “비싼 걸 쓸 수도 없었지만 공개SW 품질도 충분히 우수하기 때문에 우선적으로 적용했다”고 말한다. 사실 공개SW를 왜 사용하느냐는 질문을 받는다면 돈 내고 쓰는 것보다 오히려 공개SW가 완성도 높고 성능이 좋은 게 많다는 점을 강조하고 싶다고. “기능적인 면에서 사용이 가능한 툴을 찾다보면 공개SW인 경우가 많다”는 설명이다.

 

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

 

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

 


▲ 스타일쉐어 사이트

 

최대한, 가능한 공개SW로

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

 

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

 

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

 

전 세계 트렌드세터를 공략할 준비 순항중...

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

 

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

 


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

 

부하문제도, 유지보수도 문제없어...

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

 

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

 

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

 

회사의 가장 큰 고민과 과제는 트래픽이 계속 늘면서 생기는 문제다. 어떻게 하면 데이터베이스에 부하를 안 주면서 앞쪽에서 캐시를 더 할 수 있을까 하는 것이다. 이를 위해 한 달 전쯤 바니시 캐시(Varnish cache)를 도입했다. 바니시 캐시는 기본적으론 공개SW지만 물론 프리미엄 기능을 쓰려면 돈을 내는 유료 버전도 선보였다. 하지만 공개SW 버전에서 제공하는 기능도 스타일웨어에게 적합했다고 한다. 김 팀장은 바니시 캐시를 도입한 후 이전에 잦았던 장애가 확 줄었다며 만족감을 표했다.

 

다각적인 비즈니스 모델 확장에도 공개SW가 파트너

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

 

[인터뷰]


“공개SW에 대한 인식변화 놀라워”

스타일쉐어 김현준 개발팀장


스타일쉐어 김현준 개발팀장
▲ 스타일쉐어 김현준 개발팀장

 

Q. 공개SW를 도입해서 얻은 가장 큰 장점은 뭔가?

A. 가장 좋은 건 경제성이다. 오라클 같은 DB를 썼을때 아무리 성장 가능성이 높아도 투자를 받았다면 모를까 아니라면 벌써 망했을 것이다. 공개SW를 활용했기 때문에 가능했던 것이다. 공개SW사용으로 얻는 이점이 많다. 개발자들도 이미 공개SW를 다뤄본 경험이 있는 경우도 많고, 실무 교육 효과는 물론 이해도도 훨씬 높다.

 

Q. 단순히 경제적인 장점 밖에 없나?

A. 당연히 아니다. 개인적으로 공개SW에서 가장 중요한 건 공짜냐 이런 것보다 사실은 문제가 있을 때 내가 직접 수정할 수 있느냐가 아닐까 싶다. 더 많은 사람들이 쓰는 공개SW일수록 문제 발견이 빠르고 문제에 대한 개선도 빠르다. 피드백과 패치 속도, 개선 속도가 정말 신속하다. 공개SW는 스스로 커뮤니티 등을 통해 개선되어 가기 때문에 가만히 있어도 상용보다 얻는 퍼포먼스 이득이 굉장히 많다.

 

Q. 공개SW 추가 계획은 있나?

A. 카우치베이스라는 DB가 요즘 많이 쓰인다. 요즘 흔히 말하는 NoSQL(Not Only SQL), 비관계형 데이터베이스의 한 종류다. 넥슨 같은 곳에서도 많이 쓴다. 안정성이 굉장히 높고 분산이 쉽다고 알려져 있다. 적용 계획을 갖고 있다. 기존 DB를 대체하는 게 아니라 분산에 초점이 맞춰져 있는 부분, 접속기록이나 세션 등에선 이런 게 더 적합할 수 있다. 기존 RDB의 부하를 좀더 줄일 수 있을 것으로 기대하고 있다.




- 공개SW 역량프라자
맨 위로
맨 위로