[AWS 써보니]이상현 '빙글' 테크리드, "마이크로서비스아키턱처 매력에 푹"

[도안구 테크수다 기자 eyeball@techsuda.com] 모처럼의 인터뷰였다. 스타트업들이 클라우드를 어떻게 활용하고 있는지 궁금하던 차에 빙글(Vingle) 이상현 테크리드를 만났다. 그는 4월 19일~20일 서울에서 개최된 AWS 서밋 서울 2017에서 마이크로서비스 아키틱처에 대해서 발표자로 나섰다.

이상현 테크리드는 "저희가 경험한 내용을 발표하면서 공유하고 싶었습니다"라고 참석 이유를 밝혔다.

빙글은 이야기와 사진, 비디오, 음악 등을 공유하는 소셜 미디어다. 다른 소셜 미디어와 달리 빙글은 스쿠버 다이빙 커뮤니티, 여행 커뮤니티, 패션 커뮤니티 등 관심사가 같은 사람들끼리 서로 쉽게 만날 수 있는 커뮤니티 플랫폼이다.

관심사 기반 소셜 미디어인 빙글은 2012년도 6월에 베타 서비스를 시작했다. 국내 기준으로 매월 500만 이상이 방문하고 있고, 전세계 26개국에서 매월 220만 명 이상의 순방문자가 찾아오는 글로벌 서비스로 성장했다.

빙글에서 마이크로서비스 아키텍처에 관심을 가지고 이를 구현했다. 이상현 테크리드는 "다른 스타트업처럼 모놀리식(monolithic)으로 운영하다가 AWS의 여러 기능을 사용해 마이크로서비스로 쪼개서 6개월간에 걸쳐 옮기게 되었습니다"라면서 "프론트엔드와 백엔드 별로 각각 배포해야 간편한데 모놀로식이다보니 그렇지 못했습니다. 그래서 이런 구조를 바꾼 것이죠"라고 설명했다.

크게 보면 2가지 이유 때문이다. 하나는 실무적으로 어려움이 있던 것이 프론트에서 하나를 바꾸면 백엔드 측에서도 다 바꿔야 했다.  서로 다른 기능이고 따로 배포되어야 하는 것인데 그렇지 않다보니 어려움이 컸다. 프론트엔드는 CPU를 많이 쓰고 백엔드는 메모리를 많이 쓴다. 그리고 컴포넌트마다 사용하는 리소스 형태가 다르다. 프론트에 몰리면 프론트 스케일링을 별개로 스케일링 하는 것이 아니기 때문이다. 하나의 컴퓨터에서 하기에는 오토스케일링을 하긴 해도 자원 낭비가 되고 확장성 확보가 어려웠다. 확장성, 배포 관련 문제가 있었다.

또 하나는 기술적 혁신이 어려웠다. 저희는 백엔드를 모두 루비온레이즈로 개발했다. 최근 머신러닝 분야에서 파이썬 진영이 많이 치고 나가는데 이를 적용하려면 쉽지 않았다. 그래서 근본적으로 기술적으로 창의적인 사고를 하고 시도하는 기회가 없는 것 같아 해결책을 생각해보다가 마이크로서비스를 적용해야겠다고 생각했다. 우리의 필요에 의해서 마이크로서비스 아키텍처를 활용했지 유행이기 때문에 따른 건 아니다.

AWS를 사용한 건 그 전이다. 빙글은 일정 주기로 사용자가 관심을 가질 만한 콘텐츠를 푸시(Push) 방식의 알람으로 전달하곤 했다. 이 경우 순식간에 몰리는 트래픽으로 인해 서버 접속 불가 현상이 자주 발생했다. 불피룡한 유지보수 시간과 성능 개선을 위한 추가적인 비용이 늘었다. 피트타임을 예측하기도 여의치 않았다. 그래서 선택한 것이 AWS다.

또 스타트업 특성상 적은 인원으로도 빙글 서비스의 새로운 기능 개발과 서버 관리를 효과적으로 병행할 수 있는 방법을 찾고 있었다. 소수의 인력으로 안정적인 서비스 유지 및 관리를 하기 위해서는 서버 관리에 드는 시간 소모적인 작업량을 최소화하고 서비스 개발에 보다 집중하는 것이 필요했다. 빙글은 기존 호스팅 서비스을 대체할 수 있는 방안이 필요하다고 판단했다. 피크 타임에 생기는 서버 과부하로 인해 문제가 많았기에 확장성, 성능, 그리고 안정성 측면을 크게 고려했다. 이 세 가지 기준을 모두 만족시킨 것이 AWS 였다.

AWS로 이전 후 모바일 사용자에게 알림 메시지를 보냈을 때 메세지 발송 직후 약 10분 동안 평소보다 600% 이상 늘어나는 대량의 트래픽을 감당하는 것이 가능해 졌다. 또한 웹 서버의 응답 속도 역시 62% 가량 개선되었다.

빙글의 경우 하루동안 트래픽이 거의 없을 때와 많을 때가 10배 이상 차이가 나는 서비스이다. AWS 클라우드를 통해 트래픽에 따라 서비스를 유기적으로 스케일링 함으로써, 많은 비용 절감을 할 수 있었다.

또한 인프라 관리 시간 단축으로 핵심 업무에 집중이 가능해 졌다. AWS에서 제공하는 다이나모DB(DynamoDB)와 람다(Lambda) 같은 다양한 매지니드 서비스를 적극 이용해 확장성에 필요한 시간을 줄이고, 회사의 핵심 가치인 서비스 개발에 집중할 수 있었다.

빅데이터 분석 플랫폼 구축에도 많은 변화가 생겼다. 이상현 테크리드는 "지난 2016년 말 AWS가 발표한 빅데이터 분석 엔진인 아테나(Athena) 서비스 덕분에 저희가 더 이상 빅데이터 플랫폼 구축을 위해 리소스를 많이 투자하지 않아도 됩니다. 패러다임 쉬프트라고 감히 말할 수 있습니다"라며 "저희는 아파치 드릴를 가져다가 빅데이터 플랫폼을 만드는데 활용했는데 이제 그런 작업을 하지 않아도 됩니다"라고 말했다.

빙글은 여전히 스타트업이다. 조직이 크지 않기 때문에 내부 인원들이 새로운 기술이 등장하면 발빠르게 대응해야 한다. 계속해서 학습하는 조직으로 성장할 수 있는 문화를 만드는게 핵심이라고 이상현 테크리드는 전했다. 다음은 이상현 테크리드와 진행한 일문 일답이다.

질문: 자기소개를 부탁한다.

빙글(Vingle)에서 테크리드를 맡고 있는 이상현이다. 빙글에서 4년 정도 있었고 주요 업무는 백엔드 아키텍처를 맡고 있다.

질문. 스타트업으로 커리어를 시작했는가?

현재 4년 차이다. 백엔드가 처음에는 쉽지 않았지만 개발자로써 계속 성장해 나가는 서비스를 배우기가 쉽지 않기에 운이 좋았다. 대기업이 아니라 처음에 시작하면 동시 접속자가 100명 넘어가는 것도 의미있었다. 그때부터 배워서 했기에 지금은 어려움이 없다.

질문: 이번 AWS Summit Seoul 2017 행사에서 발표 했는가마이크로서비스 아키텍처에 대해 발표했다.

질문: AWS Summit Seoul 2017 행사 발표에 대해서 반응은 어땠는가?

좋았다. 발표 후에 개인적으로 질문도 많이 받았고 한국 스타트업 중에 비슷한 고민을 하는 스타트업이 많다는 것을 알았다.

질문: 어떤 내용이었는가

다른 스타트업처럼 모놀리식(monolithic)으로 운영하다가 AWS의 여러 기능을 사용해 마이크로서비스로 쪼개서 6개월간에 걸쳐 옮기게 되었다. 그와 관련해 그 동안 배운 것을 공유하는 자리를 가졌다.

질문: 마이크로서비스 아키텍처로 옮긴 배경은 무엇인가?

2가지 이유가 있었다. 하나는 실무적으로 어려움이 있던 것이 서로 다른 기능이고 따로 배포되어야 하는 것인데 프론트에서 하나를 바꾸면 백엔드 측에서도 다 바꿔야 해서 어려움이 컸다. 프론트엔드는 CPU를 많이 쓰고 백엔드는 메모리를 많이 쓴다. 그리고 컴포넌트마다 사용하는 리소스 형태가 다르다. 프론트에 몰리면 프론트 스케일링을 별개로 스케일링 하는 것이 아니기 때문이다. 하나의 컴퓨터에서 하기에는 오토스케일링을 하긴 해도 자원 낭비가 되고 확장성 확보가 어려웠다. 확장성, 배포 관련 문제가 있었다.

또 하나는 기술적 혁신에 대한 것이었다. 모든 백엔드가 루비온레일즈로 되어있기 때문에 최근 유행하는 머신러닝 알고리즘을 바로 적용하기 힘들었다. 이 부분은 대부분 파이썬 기반이기 때문이다. 그래서 기술적으로 창의적인 사고를 하고 시도하는 기회가 없는 것 같아 해결책을 생각했다. 마이크로서비스를 사용하면 이런 문제를 해결할 수 있을 거 같았다. 이게 화두여서 채택한 것은 아니었다.

질문: 마이크로서비스 아키텍처로 어떠한 기능을 개발하는가?

검색 기능은 다 별도의 서비스로 분리되어 있고 스팸필터도 마찬가지이다. 유저가 카드를 읽었다는 것 트래킹도 별도 서비스. 유저가 보고 있는 피드도 독립적인 서비스이다. 비즈니스 도메인에 관해는 서치, 피드, 트래킹, 스팸 등이 다 독립적인 서비스이다.

질문: 초기에 스터디는 어떻게 하는지? 어떻게 옮길 지 또는 어떻게 팀원을 설득할지도 문제였을 거 같은데

팀 구조가 기본적으로 직급이 없이 R&R 밖에 없다. 한명이 하자해서 할 수 있는 것이 아니다. 담당이 백엔드 아키텍처이긴 하지만 팀원들을 설득해야 했다. 어렵지는 않았다. 기본적으로 다들 겪고 있던 문제였다. 문제가 해결 될 것이라고 설명했더니 다들 찬성했다.

옮기는 것은 기존에 돌아가는 기능은 두고, 주로 새로 만들거나, 수정이 필요한 기능이거나 업데이트 필요한 기능부터 떼어서 옮겼다. 이중화하고 트래픽을 조금씩 옮기고 문제 없으면 한번에 옮기는 식으로 진행했다. AWS 서비스가 제공하는 확장성 확보가 좋았다.

질문: 별다른 어려움은 없었나

마이크로서비스에서 어려운 것이 DB를 분리하는 것이다. 많은 마이크로서비스 아키텍처는 디비도 서비스처럼 분리하는 것을 전제로 한다. 사용자를 다루는 서비스면 사용자를 가지고 있는 디비를 따로 분리해야 한다. 그런 것이 전제가 되어 있다. 데이터를 한 디비에 넣어논 상태에서는 이게 쉽지 않다. 그래서 앱 레이어만 분리해서 디비 공유하고 디비는 나중에 점진적으로 진행했다. 디비는 공유해서 쓰다가 트래픽 보고 분리하는 식으로 진행했다. 처음부터 새로 만드는 기능들(스팸필터)은 (앱의 특성 상 글을 아무나 쓸 수 있어 스팸이 많다. 예를 들어 ‘남성 패션’에 글을 쓰면 모두가 볼 수 있다.) 만들때부터 Amazon DynamoDB 서버 분리해서 만들었다.

질문: Amazon DynamoDB 서비스는 어떠했는가?

마이크로서비스에서 또 하나 어려운 것이 넷플릭스의 예제를 보면 개수가 몇 백, 천개가 되는게 각각의 마이크로서비스가 독립적으로 확장성이 필요하고 독립적으로 배포가 가능해야 하는데 확장성 확보가 힘들다. DB 서비스는 시중에 나와있는 것 중에 무한정 확장할 수 있는 것은 거의 없다. Amazon RDS는 AWS Lambda처럼 늘어나는 것이 아니라 어느 정도가 되면 수동으로 늘려야 한다. 무한정 바로 늘릴 수 잇는 확장성은 매우 의미가 있다.

질문: 새로 나오는 기능들은 계속 모니터링을 하고 있는가?

AWS re:Invent 행사에 참가했다. 업무 영역은 백엔드 개발 및 그 이상으로 새로운 기술 모니터링 하고 팀에서 어떤 기술을 적용할 수 있을지 살펴보는 것이 업무이다. 새로운 기능 출시를 계속 모니터링 하고 있다. AWS코리아의 유저 그룹에도 나가고 있고 정보를 얻고 있다.

질문: 오토스케일링에 변수가 많다고 들었다. 속도와 시점의 문제들이 있을 수 있을텐데.

시행착오도 많이 겪었다. AWS 람다(Lambda)와 Amazon API Gateway는 상관 없지만 Amazon EC2는 시행착오를 겪었다. 지금도 가끔 문제가 있으며 매직넘버를 찾아야한다. CPU의 %화가 아닌 로드라는 개념(CPU를 몇 개 쓰고 있는지)에 집중했다. CPU를 4개 사용한다고 했을 때, CPU 사용률이 3.1 넘어가면 일단 오토스케일링을 가동하는 식으로 진행했다.

또한 AWS의 서비스 CPU 사용률이 3.0이 3번 5분 이상, 즉 15분동안 넘어가면 오토스케일링을 가동한다고 설정이 가능한 서비스가 있다. 지금 쓰면 트래픽이 일정 이상 넘어가면 컴퓨터 3대 키고 내릴 때 5분에 하나씩 내리는 그런 방식을 채택했다. 이것도 답답했다. CPU가 놀게 되기에 어떻게 처리할지 고민이 되었다.

AWS Lambda는 사용량만큼만 호출되어서 상관 없지만 Amazon EC2는 켜 두어야했기에 자원 낭비였다. AWS Lambda 출시 이후에는 비용 절감이 있다. 사용하는 만큼만 지불하기에 전체 가격이 저렴하다. 조금씩 옮기자라는 전략이었다.

질문: 서비스 운영하는 입장에서 보면 AWS도 많이 바뀌었나?

처음에는 헤로쿠에서 사용했다. 그때는 AWS는 개발자 친화적인 플랫폼은 아니었다. 개발자가 충분히 있는 엔터프라이즈가 개발 인력을 투자해서 리서치 해야지 사용할 수 있었다. 하지만 현재는 일반적인 스타트업이 이용할 수 있는 서비스를 많이 만들었다. 아이디어만 있으면 쉽게 구현해서 할 수 있게 되었다.

초반에는 fully managed 서비스가 훨씬 쉬웠을 것이다. 가격 경쟁력도 좋고, AWS Elastic Beanstalk도 있고. 지금은 혼자 창업해도 사용할 것이다.

클라우드 업계 자체가 스타트업 위주로 보았을 때는 AWS의 경쟁력을 잘 몰랐지만 지금은 스타트업을 만나보면 다 AWS를 사용한다.

질문: 왜 AWS를 채택했는가?

미국 유저들을 고려해서 시작한 서비스이기에 미국 동부 리전을 사용한다. 따라서 이전부터 AWS 사용이 자유로웠다. 미국 동부 리전에서는 서비스 다 제공 된다.

질문: 레이턴시 문제는 없었는지?

큰 문제는 못 느꼈다. 우리가 익숙해진 것도 있겠지만 최적화 하려고 하기도 하였기에 크게 문제는 못 느꼈다. 지금도 모든 인프라가 동부 리전 상에서 운영된다.

질문: 서울, 도쿄 리전 생겨도 글로벌 서비스를 제공하기 위해 미국 동부 리전을 사용하는가?

리전 간에 데이터를 옮기기 힘들기도 하다. 하지만 결과적으로 지금 한국 시장 유저가 더 많긴 하지만 글로벌 진출을 위해서 미국 동부 리전을 계속 사용할 것 같다.

질문. 미국 동부 리전에 문제는 없는가?

문제 겪은 적이 있다. 몇 달 전 디도스 공격이 있었다 다운되었을 때 등등 하지만 이는 자연재해라고 생각한다. 다른 이들이 하는 말이 다른 서비스에 대한 디펜던시는 없지만 AWS가 죽으면 답이 없다고들 한다. 하지만 대안이 없다. 미국 동부 리전이 다운되면 서부 리전으로 복구를 하기도 했다.

질문: 서비스 업체 입장에선 클라우드 서비스 업체가 백업을 추천하거나 고가용성의 인프라를 추천하는 것에 대해 어떻게 생각하는가?

우리가 잘하는 서비스를 만드는 것이지 인프라 관리는 우리가 할 일이 아니라고 생각한다. 인프라를 관리할 사람을 뽑았겠지 AWS를 사용하지 않았을 것이다. 이를 위해 AWS를 사용하는 것이다.  

질문: AWS 클라우드로 이전 후 문제 되었던 것은 다 해결되었는가?

옮기기 시작한 것은 2016년 10~11월 정도부터 였다. 실제 작업은 그보다 살짝 짧아 4,5개월 진행했다. 작업 진행 방법에 관해서 이미 케이스 스터디를 보고 알 고 있던 것은 마이크로서비스는 만들면 몇 십개, 몇 백개가 필요하다는 것을 알았다. 그를 안정적으로 만들 수 있는 템플릿이 필요하다고 생각했다. 마이크로서비스 찍어내는 템플릿 만들기를 먼저 했다. 그때 만든 것이 AWS Lambda, Amazon API Gateway, Amazon DynamoDB를 사용해서 무한 확장성과 코드 업로드하면 자동으로 되는 기능, 스팸 필터 기능 등을 개발했다. 넷플릭스는 AWS의 로우 레벨 리소스를 묶어서 자기들의 시스템을 만들었다.

하지만 우리는 AWS가 다양한 서비스를 이미 만들었으니 우리는 서버리스 아키텍처를 유지하면서 우리가 원래 필요한 확장성, 구축 확보를 손쉽게 하는 것만 사용하자고 했다. 그러다가 나온 최적의 조합이 AWS Lambda, Amazon API Gateway, Amazon DynamoDB를 묶어서 서버리스 아키텍처를 유지하는 것이었다.

질문: 이렇게 다 공개하면 타 개발자들이 다 따라하지 않겠나?

서로 기술적으로 핵심가치가 아니면 나누자고 생각한다. 오픈소스 정신이다. 핵심 로직은 공개하지 않지만 핵심 경쟁력은 우리의 서비스에서 나온다고 생각해서 이는 공개해도 된다고 생각한다.

질문: 대기업 IT 조직에서는 서비스 개발자가 한 언어로만 개발하도록 제한하기도 한다. 그래서 데브옵스에 따라가지 못하는 경우도 있는 것 같은데..

써밋에서 애드리안 콕크로프트가 말했던 넷플릭스, AWS 등 잘 되는 회사의 특징은 회사들이 어떤 일을 해라고만 알려주고 어떻게 만들지, 그에 대한 가이드라인은 주지 않는다고 들었다. 최선의 방법을 찾으라고 한다. 이런 기능을 만들라는 청사진 만들고 그 향후는 8명 정도 구성원의 팀이 알아서 하게 한다고 한다. 저희가 추구하는 방향도 어떤 도구를 쓰느냐가 문제가 아니라 핵심은 유저가 쓰기 좋은 서비스 만드는 것이기 때문에, 어떤 도구를 사용하는지, 어떻게 만드는지는 실제 개발자가 선택하면 된다.

질문: 만약 머신러닝을 개발하려 한다면..

예를 들어 피드 알고리즘을 개선하려하면 팀이 모두 모여 알고리즘도 찾아보고 한다. 빙글은 개발 분위기가 자유롭고. 공부하는 것도 당연시한다. 백엔드 팀에 머신러닝 만들어오라하면 다 만들 수 있을 정도의 실력을 갖추고 있다. 내부 공유도 많이 한다. 오픈된 마인드를 가지고 있다.  

머신러닝에 관해선 내부적으로 쓰고 있기도 한다. 성별 예측하는 기능에 AWS의 머신 러닝 서비스를 사용하고 있다. Fully managed 서비스여서 쉽게 하고 있다.

질문: 직접 만든 것과 AWS 서비스를 활용하는 것, 무엇이 다른가?

AWS가 더 편하다. 기본적으로 pay as you go 모델로 트레이닝 한번 해두면 그 모델에 대해서 예측 한 번당 돈을 받기에 서버 관리 필요 없고 모니터링도 필요 없어서 편하다. 단순 사용 예제에 유저가 빨리 스케일링 신경 안쓰고 할 수 있도록 최적화되어 있어 성별 예측 기능에 잘 활용하고 있다.

직접 만들면 일이 많지만. 커스터마이징은 가능하다.

질문: 새로운 서비스가 너무 많이 나오는 것 같다.

그렇다. 내부적으로도 없어서 직접 만들었다가 얼마 후 AWS 서비스로 출시가 된 적이 있다. Amazon Athena외 비슷한 역할을 하는 서비스를 만들었었다. Amazon S3 데이터 쿼리 가능한 아파치 드릴을 활용해서 만들었었는데 얼마 안돼 출시가 되었다.  

질문: 아테나의 장점은 무엇인가?

패러다임 쉬프트가 있었다. 빅데이터 분석에서 Amazon Athena 서비스 이후로는 더 로우 레벨 툴은 필요가 없을 것 같다. 데이터 분석은 두 단계로 나눌 수 있다. 하나는 데이터를 안정적으로 크게, 많이 모아 둘 것인지이고, 두 번째는 모아놓은 데이터를 얼마나 자유롭게 쿼리할 수 있는지. 원하는 형태로 정리해서 볼 수 있는지이다. AWS가 제공하는 것은 모으는 것은 Amazon S3, 분석은 Amazon EMR 등이 있었다. 빙글은 Amazon Redshift를 사용했다. 이는 데이터를 많이 넣어서 분석은 가능하지만 (PB단위), 그 양이 Amazon S3 만큼 무제한은 아니고 수동으로 스케일링 해줘야 했다. 반면 Amazon S3는 넣는 것은 쉽지만 분석하려면 Amazon Redshift로 옮기던지 로컬로 덤프해서 하둡으로 돌린다던지 했어야했다. 이것은 일반 기업이 풀기엔 어려운 문제였다.

빙글은 최소 테라바이트, 그리고 PB 단위도 나오기도 한다. 그래서 Amazon Redshift도 힘들기도 했다. Amazon Athena는 데이터를 어떻게든 Amazon S3 에 넣으면 다 Amazon Athena로 볼 수 있고 비용은 사용자가 데이터를 읽은 만큼만 내면 된다. 복잡한 툴을 쓸 필요 없이 Amazon S3에만 넣으면 쿼리 등 그 다음 단계는 문제가 없다. Amazon Athena는 fully managed 서비스이다.

Amazon Athena에 대한 테스트 했고 부분적으로 사용하기도 했다. 장기적으로는 해당 서비스를 더욱 활용할 계획도 있다.

질문: 데브옵스 이야기가 많이 나온다. 어떻게 생각하는가?

애초부터 스타트업은 데브옵스 환경이다. 코드를 만들고 운영도 하고 개선하고 전부 다 하기에 개발과 운영을 분리한다는 개념이 잘 이해가 가지 않는다. 만약 제가 개발하고 운영팀이 운영하면 운영팀이 고칠 수가 없기에, 분리된 팀에서는 어떻게 하는지 경험이 없어서 무어라 언급 못하겠다. 개인적으로는 데브옵스라는 개념밖에 없다고 보면 된다.

또한 요즘에는 데브옵스가 당연하다고 생각한다. 넷플릭스, AWS 등도 그러하지만, 개발팀이 데브옵스가 합쳐진 8명 정도로 꾸려져 있는 것이 기본적 팀 단위다.

만약 분리가 되어있다면 회사의 혁신의 속도가 느려진다고 생각한다. 팀 전체가 자율적인 소규모 팀 수 백개일때와 비교해 팀 전체가 큰 팀 하나이면 혁신 속도가 다르다. 그래서 손해볼 것이라고 생각한다. 장점은 다 같은 것을 쓰면 빨리 찍어낼 수 있다고 생각한다. 시대적인 트렌드는 조그만 팀 단위로 혁신을 이루는 것이라고 생각한다.

질문. 오픈소스는 운영하다 보면 계속해서 업그레이드 되는 경우가 있다. 이런 경우 업그레이드를 하자고 팀 내에서 논의를 하는가?

팀에서 업그레이드 하자고 논의한다. 이는 회사 문화, 경력의 문제라고 생각한다. 저는 커리어 시작부터 오픈소스만 사용해왔다. 상용 솔루션은 안 써봤다. 개인적으로 그런 환경에서 작업을 해보지 않았기에 오픈소스가 당연하다. 오픈소스 사용한다는 것이 팀 내에서 역량을 쌓아야 하기 때문에 팀에서 당연히 받아들인다.

팀 구조에 대해 덧붙인다면, 마이크로서비스로 옮긴 다는 것이 기술 적 변화이면서 팀의 변화이기도 하다. 팀 안의 사람들이 각자 맡은 파트에 대해서는 전적인 위임권이 있다는 것이다. AWS나 넷플릭스는 구현 방식에 대해 팀에게 자율권을 준다. 그 자체가 조직의 문화의 문제라고 생각한다. 과연 각각 소규모 팀에게 자율권을 주는가에 대해 보수적인지, 좀 더 젊은 기업인가에 따라 그 갭이 크다고 생각한다.

빙글은 자율권을 많이 주는 것이 좋다고 생각한다. 개개인이 잘하는 역할을 하는 것이지 직급이 높아서 하는 것이 아니다.

아키텍처링 하는 것이 제 역할이고. 팀원의 매니징은 다른 분이 하시고 IoS는 아키텍처 따로 있다. 각자 롤이 있다. 각자 파트의 역할은 전적으로 위임된다.

질문: 주류, 비쥬류 기술이 있을텐데 개인별로 기술에 대한 선호도가 갈리지는 않는지?

그에 대해 객관적으로 판단할 수 잇는 사람이 필요하다고 생각한다. 팀원 중에서도 고를 좋아한다 하면 마이너해서 못쓰기보단 우리가 선택해야하는 기술이 무엇인지에 대해선 팀원이 동의해야 한다. 처음 마이크로서비스 아키텍처를 고민할 때 여러 후보를 논의했다. 의사 판단에 있어 팀원들이 객관적으로 판단을 잘 해주는 편이다.

우리 팀의 역량이 중요하다. 어떤 기술이 좋을지 선택할 때에 있어서. 그래서 팀이 잘 할 수 있는 것을 하자고 결정한다.

질문: 컨설팅을 받기도 하는가?

우리는 우리가 계속 직접 공부한다. 팀 내부적으로 조사한다. 저희가 채용시에 중요시 하는 점이 새로운 지식을 계속 혼자서 공부하는 사람인지도 중요하게 본다.

질문: 최근 우리나라 스타트업들은 다 인공지능을 한다고 한다.

다 하는 것 같다. 경력이 긴 SI 개발자 위주로 자바기반으로 만드는 스타트업들이 있다. 하지만 이들 보다는 경력이 비교적 젊고 애초에 시작 기반이 자바가 아닌 루비올렛, 플라스크 등 새로운 프레임워크 기반으로 하는 분들이 비슷한 고민을 많이 하는 것 같다.

질문: 왜 스타트업에 합류했는가.

내 손으로 만들고 싶다고 생각했다. 대기업에 다니면 연수 받고, 사원으로 일하고.. 이렇게 인생이 가겠구나 하는 생각이 있었다. 개인적으로는 그보단 좀 더 당장 기여할 수 잇는 것을 하자라고 생각했다. 당장 유저에게 서비스할 수 있는 회사를 가자고 해서 스타트업을 찾아보다가 빙글로 오게 되었다.

질문: 팀원은 몇 명인가?

개발팀은 12명이다. 대부분 젊은 개발자들이다.

질문: 다국어 서비스도 개발자에겐 힘든가?

애초부터 다국어 서비스였다. 운이 좋았다.

질문: 다른 클라우드는 검토해본 적 없는가?

AWS가 선두주자이다. 클라우드는 안정적인 곳을 사용해야 한다고 생각한다. <테크수다 Techsuda>