전체 피드 목록

예전에 나는 다른 스타트업 창업팀에서 스타팅멤버로 속해있던 상태였었다. 그리고 그 안에서 거의 1여 년간 개인의 삶 없이 내가 곧 팀이라는 생각으로 동고동락하며 살아왔었다. 속해 있던 그 시간 동안, 나의 생각은 무엇이 변화하였고 그 과정 속에서 어떤 배움과 감각을 체득하였길래 팀을 나서서 텐시티로 오게 되었을까? 이제 그 느낀점들을 하나씩 작성해보고자 한다.첫 번째 창업팀을 그만두며 배운 것들...________________________________________ 1. 창업자는 다른 사람의 인생에 관여하게 되는 자리이 이야기는 네이버를 창업한 이해진 의장님이 카울리의 홍준님에게 말한 이야기이며, 나는 다시 홍준님에게 전해 들은 이야기이다. 홍준님께서 다른 분들과 함께 네이버를 나서서 창업을 하게 되었을 때, 이해진 의장님이 홍준님을 집무실로 불러 작별인사와 함께 다음과 같은 말을 전했다고 한다."준아, 창업자는 다른 사람의 인생에 관여하게 되는 자리야"... 당시 홍준님께서는 깊이 생각하지 않았었지만 시간이 흐른 뒤에야 비로소 짧은 말 속에 많은 의미가 내포되어있던 것을 알게 되었다고 한다. 나는 이 이야기를 지난 여름, D.Dicison 프로그램을 통해 홍준님을 만났을 때 전해 들었었는데 듣던 순간 나의 마음이 동요되며 기억 속에 깊게 남아 잊히지 않는다. 내포한 뜻이 많아 다양한 해석을 할 수 있겠지만 내가 내린 해석은 다음과 같다 "다른 사람의 인생까지 책임질 각오가 되어있지 않다면 창업하는 것을 더 고민하라는 뜻"이라고... 이 글을 읽는 분들이 창업을 하게 된다면, 앞으로 함께하게 될 팀원들과 직원들의 인생까지 꼭 고려하여 깊게 생각해주었으면 좋겠다. 지난 창업 때 난 충분히 각오하지 못했던 것 같다. 2. 사람에 대한 의리 그리고 일첫 번째 창업전, 나는 크라우드펀딩 회사에서 인턴으로 근무하고 있었다. 당시 산업이 아직 발전되지 않은 때였지만, 곧 핀테크 바람에 힘입어 산업을 리드할게 분명한 회사였었다. 그리고 입사 후 근무한지 채 얼마 되지 않았을 때, 평소에 은인이자 멘토라고 생각해왔던 고마운 형에게 함께 창업하자고 제안받았었다.제안받았을 때 사업 아이템도 잘 몰랐고 내가 갖게 될 조건, 그리고 수행할 포지션과 성장할 커리어도 알지 못했다. 그런데 나는 덜컥 수락했다. 그 형이 좋았고 고마움에 대한 의리였었다. 지금 생각할 땐 분명 달리 선택했을 텐데 무식하면 용감하다고 했던가... 당시의 나는 졸업한지 얼마 안되고, 사회경험도 부족했던 터라 어리석고 호기(?)로웠던 것 같다.그렇게 나는 의리란 걸 지키기 위해 재직 중이던 회사에 인력공백이란 피해를 주고 나쁜 레퍼런스까지 얻게 되었다. 그때 대표님들과 이사님들이 긴 시간 설득하며 말리셨었는데 너무나 죄송하다. 난 요즘도 자다가 이불킥 한다... 일은 의리로 할게 아니라 모든 사항들을 고려해서 해야 한다는 걸 왜 그땐 몰랐을까... 3. 시각적으로 표현할 수 없는 희망여기서 말하는 '시각적으로 표현할 수 없는 희망’이란, 눈으로 볼 수 있는 수치와 지표를 가지지 못한 근거 없는 희망을 말한다. 창업 후 몇 달 동안이나 제자리 걸음을 하며 이달에는 별로지만 다음달엔 훨씬 나을 거라는 막연한 믿음과 기대를 가지고 창업을 이어갔었다. 긍정적인 시그널을 확인할 수 있는 구체적이고 시각화된 데이터 없이, 불과 몇 마디의 ‘잘될 거야, 잘될 거야'라는 근거 없는 믿음의 대화들 속에서 위기의식이 마비되었던 것 같다. 그리고 이에 더해 내가 공들인 노력과 시간이란 매몰비용이 아까웠던 것도 상황을 장기화하는데 한몫했었었다.어디선가 읽었는데 사람의 뇌는 긍정적으로 생각하게끔 진화했기에 나쁜 시나리오도 의식적으로 생각해볼 필요가 있다고 한다. 그러니 데이터 없는 대화 속이 아닌, 눈으로 수치와 지표를 확인하는 감정이 아닌 이성적인 희망을 가지자. 4. 얇고 넓은 인사이트를 가진 사람들일부 자신을 멘토라고 하는 사람들이 강연을 하고, 또 도와주겠다고 조언을 한다. 처음 지식과 경험이 부족하여 잘 몰랐을 때는 스타트업 생태계를 이해하는데 많은 도움이 되었었다. 그런데 어느샌가 나는 더 이상 그들을 찾지 않게 되었고 오히려 경계하게 되었다. 그들과의 대화 속에서 실망하게 되는 때가 잦아졌기 때문인데, 실망이유는 다음과 같다.첫째, '자신의 백그라운드를 과대하게 포장'한다. 그리고둘째, '깊은 인사이트를 가진 척'한다.백그라운드 과대포장은 아래에서 다루겠고 여기서는 깊은 인사이트를 가진 척 한다는 것만 다루도록 하겠다 물론 그들이 나이도 있으시고 경험이 많으신 분들이기에 많은 지식과 넓은 시야를 가지고 있는 것은 분명하다. 하지만 인사이트 즉, 어느 한 사물의 본질을 꿰뚫어보는 통찰력을 가진 사람은 그리 많지 않았다 그저 대부분 자신의 이익만을 위해 "나 IT전문가요", "나 마케팅 전문가요”라고 말하며 자기 자신을 PR 할 뿐인 것 같다... 그들이 얇고 넓게 알더라도 지식 간 제대로 된 융합을 일으킬 수준까지는 깊이를 가졌으면 좋겠다.(이글에서 말하는 분들은 일부라는 것을 다시 한 번 밝힌다) 5. 그럴듯하고 대단해 보이는 것창업을 처음 시작할 때부터 조언이라면서 들어왔던 말들이 있다. 사업하는 사람은 그럴듯하고 대단해 보여야 한다고... 나는 맞는 말이라며 동의했고 그렇게 보이고 싶어서 여러 가지를 시도했었다. 나이 들어 보이고 싶어서 수염을 기르고 뽀글이 파마도 하고 이병철 회장님 스타일의 안경도 썼었다 어디 가서는 어디 어디 대표였고 이사라고 소개하고 명함도 만들었다. 근데 마치 이건 몸에 맞지 않는 옷을 입은 느낌이란 생각이 점점 들었다 (수염은 만족) 그리고 곧 나와 맞지 않는 모습들은 정리했다.그럴듯한 대단해 보이는 모습이 어쩌면 그 누군가에게는 꼭 맞는 말일지 모른다. 하지만 모든 사람에게 100% 맞는 말은 아닌 것 같다. 알리바바의 거인 ‘마윈’은 무척 왜소한 체격을 지녔으며, 페이스북의 ‘마크 주커버그’는 새내기 대학생 같아 보이는 옷을 매일 똑같이 입는다. 사람은 다 다르고, 살아가는 방식 역시 모두 다르다. 그러므로 대단해 보여야 한다는 강박관념에 사로잡혀 연기할 필요는 없었던 것이다.차라리 그 노력과 에너지를 순수히 자신이 하고 있는 일에 쏟는다면 정말 대단한 사람이 될 수 있을지 모른다. 나에게 있어서 대단해 보이려 노력하는 것은 그저 나 스스로에게 자신감이 생길 정도로만 꾸미면 충분했다.(나에게 있어서이다 나.에.게) 6. 다람쥐 쳇바퀴 같은 비효율무척 열심히 일해왔었다. 주말도 반납은 기본으로 9시에 출근하여 밤 11시가 넘어서 까지 일하며 집에선 잠만 잤었다 아마도 주 90시간 가까이 일했던 것 같다. 하지만 열심히 일한다고 해서 그만큼의 노력이 반드시 돌아오는 것은 아니었다. 수레바퀴가 아닌 다람쥐 쳇바퀴 안에서는 아무리 굴려봐야 제자리일 뿐이라고 노력을 보상받기 위해서는 효율적인 프로세스가 전제되어야 했었다.그렇다면 왜 이런 비효율을 개선하지 않았을까?첫째로, 팀의 인식 부족이 이유인 것 같다.처음 내가 문제를 느꼈을 때 프로세스를 개선하자 건의하고 좋은 아이디어와 사례, 또는 최신의 협업 및 생산성 도구들을 소개해주기도 했었었다. 하지만 돌아오는 반응은 냉소적일 뿐이었다.이후에도 여러 차례 이런 상황이 반복되자 나중에는 좋은 업무방법이나 도구가 있더라도 더 이상 소개하지 않고 나 혼자만 알고 사용하게 되었었다.둘째는, 나의 태도에 있었다.이번에 MBA에서 조직행동을 배우며 이 두 번째 문제점을 인식할 수 있었는데, 설명하자면 사람들은 불확실성이 증가하는 것을 본능적으로 원치 않기 때문에 변화를 꺼려하기 마련이다. 그러므로 변화시키기 위해서는 먼저 선행되어야 할게 있는데 바로 위기감을 심어주고 변화의 필요성에 대해 공유하는 것이다. 그러고 나서 비전을 제시하고 변화를 추진하며 작은 성공을 계속 만들어 나가야 변화와 혁신을 이룰 수 있다고 한다. 이는 변화에 대한 루윈의 3단계 (Lewin's Three Stages)라는 내용이다.나는 이중 첫 번째 단계인 변화의 필요성에 대해 공유하는 것을 생략해버린 채, 바로 변화해야 한다고 주장하기만 했었다. 이러한 나의 일방적인 주장은 타인에게는 아마도 불만 가득한 사람으로만 비쳤으리라...________________________________________나의 첫 번째 창업에서 배웠던, 총 여섯 가지의 배운 점을 정리해서 작성해보았다.위의 내용들은 모두 실패사례에서 뽑아낸 것이지만, 나의 과정 속에서는 성공했던 사례도 많았고 그 속에서도 많은 걸 배웠었다. 실패사례에서만 이야기한 것은 더 극적인 글이 되길 원했기 때문이다.이와 관련해 한 이야기만 더 쓰고 싶다.어느 두 사람의 IT 창업글을 읽은 적이 있는데 한분은 창업에 실패했던 이야기고 한분은 창업에 성공한 이야기이다. 그리고 그 둘은 똑같은 코딩을 모르는 기획자 출신이었다. 글의 내용은실패하신 분은 본인이 코딩을 몰랐기 때문에 개발자들과 원활한 커뮤니케이션을 나누지 못했고 그래서 실패했다는 이야기며,성공하신 분은 코딩을 몰라서 개발은 지인들에게 조금씩 부탁하고 자신은 기획에만 충실히 하여, 3년이나 걸렸지만 결국 성공했단 이야기였다.즉, 같은 사안이라도 어느 분은 ‘원인’ 때문에 실패했고 어느 분은 ‘원인'이 있지만 성공했다고 말한 것이다. 두 분의 상황이 완전히 똑같지 않겠지만, 비슷한 환경 속에서도 다른 결과가 나오게 되었다. 결국 모든 것은 결과에 따른 이야기였던 것이다.마지막 두 분의 이야기를 한 것은 나의 글 속 ‘성공’과 ‘실패’가 어느 ‘원인’ 때문에 발생하는 인과관계가 아니라는 것을 알려드리고 싶어서이다. 나는 아직 20대의 경험 없는 주니어이다. 이 글이 ‘이렇게 하니까 성공하고, 저렇게 하니까 실패하더라’라고 보이는 게 두렵다. 주장하는 글이 아닌 공감되는 글로 보이고 싶다.나의 첫 번째 창업 속 여러 가지 ‘원인’ 들 중에서 ‘성공’ 그리고 ‘실패’는 한 끗 차이 였었고, 직접 컨트롤할 수 있던 것은 ‘배움’ 이었다.#텐시티 #창업 #창업가 #창업자 #인사이트 #성장 #경험공유

비트윈에는 커플들이 서로에게 감정을 더욱 잘 표현할 수 있도록 스티커를 전송할 수 있는 기능이 있습니다. 이를 위해 스티커 스토어에서 다양한 종류의 스티커를 제공하고 있으며 사용자들은 구매한 스티커를 메시지의 첨부파일 형태로 전송을 할 수 있습니다. 저희가 스티커 시스템을 구현하면서 맞딱드린 문제와 이를 해결한 방법, 그리고 프로젝트를 진행하면서 배운 것들에 대해 소개해 보고자 합니다.스티커 시스템 아키텍처¶비트윈에서 스티커 기능을 제공하기 위해 다양한 구성 요소들이 있습니다. 전체적인 구성은 다음과 같습니다.비트윈 서버: 이전에 소개드렸었던 비트윈의 서버입니다. 비트윈의 채팅, 사진, 기념일 공유 등 제품내의 핵심이 되는 기능을 위해 운영됩니다. 스티커 스토어에서 구매한 스티커는 비트윈 서버를 통해 상대방에게 전송할 수 있습니다.스티커 스토어 서버: 스티커를 구매할 수 있는 스토어를 서비스합니다. 스티커 스토어는 웹페이지로 작성되어 있고 아이폰, 안드로이드 클라이언트와 유기적으로 연동되어 구매 요청 등을 처리합니다. 처음에는 Python과 Flask를 이용하여 구현하려 하였으나 결국엔 서버 개발자들이 좀 더 익숙한 자바로 구현하기로 결정하였습니다. Jetty와 Jersey를 사용하였고, HTML을 랜더링하기 위한 템플릿 엔진으로는 Closure Template을 이용하였습니다. ORM으로는 Hibernate/JPA, 클라이언트와 웹페이지간 연동을 위해서 Cordova를 이용하였습니다. EC2에서 운영하고 있으며 데이터베이스로는 RDS에서 제공하는 MySQL을 사용합니다. 이미 존재하는 솔루션들을 잘 활용하여 최대한 빨리 개발 할 수 있도록 노력을 기울였습니다.스티커 다운로드 서버: 스티커는 비트윈에서 정의한 특수한 포맷의 파일 형태로 제공됩니다. 기본적으로 수 많은 사용자가 같은 스티커 파일을 다운로드 받습니다. 따라서 AWS에서 제공하는 CDN인 CloudFront을 이용하며, 실제 스티커 파일들은 S3에서 호스팅합니다. 그런데 스티커 파일들은 디바이스의 해상도(DPI)에 따라 최적화된 파일들을 내려줘야하는 이슈가 있었습니다. 이를 위해 CloudFront와 S3사이의 파일 전송에 GAE에서 운영중인 간단한 어플리케이션이 관여합니다. 이에 대해서는 뒷편에서 좀 더 자세히 설명하도록 하겠습니다.구현상 문제들과 해결 방법들¶적정 기술에 대해 고민하다¶스티커 스토어 서버를 처음 설계할때 Flask와 SQLAlchemy를 이용하여 구현하고자 하였습니다. 개발팀 내부적으로 웹서버를 만들때 앞으로 Python과 Flask를 이용해야겠다는 생각이 있었기 때문이며, 일반적으로 Java보다는 Python으로 짜는 것이 개발 효율이 더 좋다는 것은 잘 알려진 사실이기도 합니다. 하지만 Java에 익숙한 서버 개발자들이 Python의 일반적인 스타일에 익숙하지 않아 Python다운 코드를 짜기 어려웠고, 오히려 개발하는데 비용이 더 많이 들어갔습니다. 그래서 개발 중에 다시 웹 서버는 자바로 짜게 되었고, 여러가지 스크립트들만 Python으로 짜고 있습니다. 실제 개발에 있어서 적절한 기술의 선택은 실제 프로젝트에 참여하는 개발자들의 능력에 따라 달라져야한다는 것을 알게되었습니다.스티커 파일 용량과 변환 시간을 고려하다¶사용자는 스티커 스토어에서 여러개의 스티커가 하나로 묶인 스티커 묶음을 구매하게 됩니다. 구매 완료시 여러개의 스티커가 하나의 파일로 압축되어 있는 zip파일을 다운로드 받게 됩니다. zip파일내의 각 스티커 파일에는 스티커를 재생하기 위한 스티커의 이미지 프레임들과 메타데이터에 대한 정보들이 담겨 있습니다. 메타데이터는 Thrift를 이용하여 정의하였습니다.스티커 zip파일 안에는 여러개의 스티커 파일이 들어가 있으며, 스티커 파일은 다양한 정보를 포함합니다카카오톡의 스티커의 경우 애니메이션이 있는 것은 배경이 불투명하고 배경이 투명한 경우에는 애니메이션이 없습니다. 하지만 비트윈 스티커는 배경이 투명하고 고해상도의 애니메이션을 보여줄 수 있어야 했습니다. 배경이 투명한 여러 장의 고해상도 이미지를 움직이게 만드는 것은 비교적 어려운 점이 많습니다. 여러 프레임의 이미지들의 배경을 투명하게 하기 위해 PNG를 사용하면 JPEG에 비해 스티커 파일의 크기가 너무 커집니다. 파일 크기가 너무 커지면 당시 3G 환경에서 다운로드가 너무 오래 걸려 사용성이 크게 떨어지기 때문에 무작정 PNG를 사용할 수는 없었습니다. 이에 대한 해결책으로 투명 기능을 제공하면서도 파일 크기도 비교적 작은 WebP를 이용하였습니다. WebP는 구글이 공개한 이미지 포맷으로 화질 저하를 최소화 하면서도 이미지 파일 크기가 작다는 장점이 있습니다. 각 클라이언트에서 스티커를 다운 받을때는 WebP로 다운 받지만, 다운 받은 이후에는 이미지 로딩 속도를 위해 로컬에 PNG로 변환한 스티커 프레임들을 캐싱합니다.그런데 출시 된지 오래된 안드로이드나 iPhone 3Gs와 같이 CPU성능이 좋지 않은 단말에서 WebP 디코딩이 지나치게 오래 걸리는 문제가 있었습니다. 이런 단말들은 공통적으로 해상도가 낮은 디바이스였고, 이 경우에는 특별히 PNG로 스티커 파일을 만들어 내려줬습니다. 이미지의 해상도가 낮기 때문에 파일 크기가 크지 않았고, 다운로드 속도 문제가 없었기 때문입니다.좀 더 나은 주소 포맷을 위해 GAE를 활용하다¶기본적으로 스티커는 여러 사용자가 같은 스티커 파일을 다운받아 사용하기 때문에 CDN을 이용하여 배포하는 것이 좋습니다. CDN을 이용하면 스티커 파일이 전 세계 곳곳에 있는 엣지 서버에 캐싱되어 사용자들이 가장 최적의 경로로 파일을 다운로드 받을 수 있습니다. 그래서 AWS의 S3와 CloudFront를 사용하여 스티커 파일을 배포하려고 했습니다. 또한, 여러 해상도의 디바이스에서 최적의 스티커를 보여줘야 했습니다. 이 때문에 다양한 해상도로 만들어진 스티커 파일들을 S3에 올려야 했는데 클라이어트에서 스티커 파일을 다운로드시 주소 포맷을 어떻게 가져가야 할지가 어려웠습니다. S3에 올리는 경우 파일와 디렉터리 구조 형태로 저장되기 때문에 아래와 같은 방법으로 저장이 가능합니다.http://dl.sticker.vcnc.co.kr/[dpi_of_sticker]/[sticker_id].sticker하지만, 이렇게 주소를 가져가는 경우 클라이언트가 자신의 해상도에 맞는 적절한 스티커의 해상도를 계산하여 요청해야 합니다. 이것은 클라이언트에서 서버에서 제공하는 스티커 해상도 리스트를 알고 있어야 한다는 의미이며, 이러한 정보들은 최대한 클라이언트에 가려 놓는 것이 유지보수에 좋습니다. 클라이언트는 그냥 자신의 디스플레이 해상도를 전달하기만 하고, 서버에서 적절히 계산하여 알맞은 해상도의 스티커 파일을 내려주는 것이 가장 좋습니다. 이를 위해 스티커 다운로드 URL을 아래와 같은 형태로 디자인하고자 하였습니다.http://dl.sticker.vcnc.co.kr/[sticker_id].sticker?density=[dpi_of_device]하지만 S3와 CloudFront 조합으로만 위와 같은 URL 제공은 불가능하며 따로 다운로드 서버를 운영해야 합니다. 그렇다고 EC2에 따로 서버를 운영하는 것은 안정적인 서비스 운영을 위해 신경써야할 포인트들이 늘어나는 것이어서 부담이 너무 컸습니다. 그래서, 아래와 같이 GAE를 사용하기로 하였습니다.GAE는 구글에서 일종의 클라우드 서비스(PaaS)로 구글 인프라에서 웹 어플리케이션을 실행시켜 줍니다. GAE에 클라이언트에서 요청한 URL을 적절한 S3 URL로 변환해주는 어플리케이션을 만들어 올렸습니다. 일종의 Rewrite Engine 역할을 하는 것입니다. 서비스의 안정성은 GAE가 보장해주고, S3와 CloudFront의 안정성은 AWS에서 보장해주기 때문에 크게 신경쓰지 않아도 장애 없는 서비스 운영이 가능합니다. 또한 CloudFront에서 스티커 파일을 최대한 캐싱 하며 따라서 GAE를 통해 새로 요청을 하는 경우는 거의 없기 때문에 GAE 사용 비용은 거의 발생하지 않습니다. GAE에는 클라이언트에서 보내주는 해상도를 보고 적당한 해상도의 스티커 파일을 내려주는 아주 간단한 어플리케이션만 작성하면 되기 때문에 개발 비용도 거의 들지 않았습니다.토큰을 이용해 보안 문제를 해결하다¶실제 스티커를 구매한 사용자만 스티커를 사용할 수 있어야 합니다. 스티커 토큰을 이용해 실제 구매한 사용자만 스티커를 전송할 수 있도록 구현하였습니다. 사용자가 스티커 스토어에서 스티커를 구매하게 되면 각 스티커에 대한 토큰을 얻을 수 있습니다. 스티커 토큰은 다음과 같이 구성됩니다.토큰 버전, 스티커 아이디, 사용자 아이디, 유효기간, 서버의 서명서버의 서명은 앞의 네 가지 정보를 바탕으로 만들어지며 서버의 서명과 서명을 만드는 비밀키는 충분히 길어서 실제 비밀키를 알지 못하면 서명을 위조할 수 없습니다. 사용자가 자신이 가지고 있는 스티커 토큰과 그에 해당하는 스티커를 비트윈 서버로 보내게 되면, 비트윈 서버에서는 서명이 유효한지 아닌지를 검사합니다. 서명이 유효하다면 스티커를 전송이 성공하며, 만약 토큰이 유효하지 않다면 스티커의 전송을 허가하지 않습니다.못다 한 이야기¶비트윈 개발팀에게 스티커 기능은 개발하면서 우여곡절이 참 많았던 프로젝트 중에 하나 입니다. 여러 가지 시도를 하면서 실패도 많이 했었고 덕분에 배운 것도 참 많았습니다. 기술적으로 크게 틀리지 않다면, 빠른 개발을 위해서 가장 익숙한 것으로 개발하는 것이 가장 좋은 선택이라는 알게 되어 스티커 스토어를 Python 대신 Java로 구현하게 되었습니다. 현재 비트윈 개발팀에서 일부 웹사이트와 스크립트 작성 용도로 Python을 사용하고 있지만 Python을 잘하는 개발자가 있다면 다양한 프로젝트들를 Python으로 진행할 수 있다고 생각합니다. 팀내에 경험을 공유할 수 있는 사람이 있다면 피드백을 통해 좋은 코드를 빠른 시간안에 짤 수 있고 뛰어난 개발자는 언어와 상관없이 컴퓨터에 대한 깊이 있는 지식을 가지고 있을 것이기 때문입니다.네 그렇습니다. 결론은 Python 개발자를 모신다는 것입니다.저희는 언제나 타다 및 비트윈 서비스를 함께 만들며 기술적인 문제를 함께 풀어나갈 능력있는 개발자를 모시고 있습니다. 언제든 부담없이 [email protected]로 이메일을 주시기 바랍니다!