스마트폰 생태계가 성숙되어가면서 액티비티 트래커, 구글 글래스, 스마트 워치류의 웨어러블 디바이스들이 쏟아져 나오고 있다. 초기의 낙관적인 시장전망과는 다르게 시장은 빠르게 변화하고 있고, 기존의 플레이어들은 역사뒤로 사라지고, 또 새로운 플레이어들이 나타나면서 역사는 반복되고 있다[1]. 여전히 사용자관점에서는 그 필요성에 대해 회의가 많다. 진정한 웨어러블의 빅뱅은 시기상조이며 웨어러블의 성공적인 시장을 만드는 것도 요원해 보인다.  우리가 놓치고 있는 진정한 웨어러블의 본질은 무엇인가?웨어러블의 본질웨어러블이 확산되는데 있어 가장 큰 장벽은 무엇인가를 착용한다는 것에 대한 불편함이다. 사람의 몸은 익숙하지 않은 것을 받아들이기까지 참아내야 할 시간이 필요하다. 하지만 웨어러블이 그 인내를 가질만큼 사람들에게 가치가 있는 것인가? 인내를 가질만큼의 가치를 줄 수 없다면 선택되지 못하거나 선택되어도 사람들 곁에 지속될 수 없다. 그래서 요즘 많은 사람들이 예전에 구매했던 액티비티트래커나 스마트워치라 불리우는 것들을 책상 서랍에 넣고 잊어버린 지 오래이다.   1. 첫 번째 가치: 불편함을 넘어 습관이 되거나 대체불가능한 본연의 기능성안경을 착용한 사람들중에 안경을 끼고 세수를 한 경험이 있는 사람들이 있을 것이다. 안경을 써보지 않은 사람들은 믿지 않겠지만 오랫동안 착용하다보면 몸의 일부처럼 체화되어 마치 없는 듯 느껴지기 때문이다. 하지만 처음에 쓸때는 어떠할까? 매우 불편하다. 귀도 아프고 코도 아프고, 눈도 따끔거린다. 하지만 그걸 참을 만한 단하나의 기능이 있다. 안경을 써야 보인다는 것이다. 안경없이는 칠판도 안보이고 간판글씨도 잘 안보이는데 안경을 착용하는 순간 세상이 밝아지고 환해진다. 그래서 불편함을 무릅쓰고라도 쓸만한 가치가 있다. 그런데 쓰다보면 불편함이 느껴지지 않는 순간, 즉 습관이라는 것이 만들어지는 때가 온다. 이렇게 안경, 썬글래스, 콘택트렌즈 모두 그것을 착용하지 않을 때와 착용 할 때의 기능적 차이가 명확하다. 보청기도 마찬가지이다. 이 명확한 기능성덕에 사람들은 눈이 부실때는 썬글래스를, 스키탈때는 고글을, 수영할때는 수경을, 오토바이탈때는 헬멧을 착용할 수 있다.2. 두 번째 가치: 보는 것이 아닌 나를 보여주는 것시간을 보기 위해 시계를 착용한다고 하는 사람들이 많이 있다. 하지만 그들에게 있어 시계는 악세서리의 가치가 훨씬 크다. 시간보는 것을 원하는 소비자들은 쉽게 대체제를 찾아 이미 시계를 벗어버렸다. 모바일폰이나 삐삐가 있기전에 많은 사람들이 시계를 차고 다녔다. 그 때는 진짜 시간을 보기 위해서였다. 하지만 모바일폰으로 쉽게, 더 정확하게, 알람기능도 편하게 볼수 있게 되면서 그 불편하던 시계를 벗어버린 사람들이 많다. 지금 시계를 착용하고 있는 사람들은 패션으로서의 가치가 크기 때문에 그 불편한 시계를 차고 다니는 것이며 정확하게는 차고 있기 때문에 시간을 보는 것이다. 물론 100%라고 일반화 할 수는 없다. 지금도 시계를 착용하는 많은 사람들은 새로 멋지고 좋은 브랜드의 시계를 선물받았거나 구매했기에 차기 시작한 사람들도 있지만, 대부분은 대체제가 나타났을 때도 관성에 의해 계속 시계를 차고 있었던 덕에 습관이라는 행동패턴이 생긴 소비자들인 경우일 것이다. 습관이 되어 버린 이들에게는 시계를 착용하는 불편함은 더 이상 인지되는 문제가 아니다.이는 신발이나 모자, 옷과 같이 패션과 기능이라는 면에 있어 너무도 확고한 의류(wear 웨어)가 가지고 있는 것과 동일한 가치이다. 여기서 웨어(wear)와 웨어러블(wearable)의 차이는 본질적인 속성의 차이이다. 이미 입고 있는 웨어와 입거나 찰 수 있는 웨어러블은 인간에게 있어 수십, 수백년의 역사속에서 만들어진 습관을 극복 할 가치의 차이에 있는 것이다. 웨어러블은 이 두가지 본질적 가치를 줄 수 있을 때 비로소 인간에게 선택될 수 있는 티핑이 시작 될 것이다.거부하지 않는 소비자들웨어러블은 그래서 거부하지 않는 소비자에 집중해야 한다. 거부하지 않는 소비자란, 불편함을 참아야 할 기능적 니즈를 가지고 있거나, 이미 사용하고 있는 습관을 가지고 있는 사람들이다. 안경을 착용하고 있거나, 시계를 차고 있는 소비자는 이미 웨어러블을 사용하고 있는 사람들이다. 이들에게 필요한 기능과 디자인, 그리고 가치에 집중해야 하며 웨어러블이 포스트스마트폰이 될 거라는 고정관념을 버려야 한다. 스마트폰은 인간을 정보의 중심으로 만들어 준 컴퓨터의 속성이 본질이기에 웨어러블은 사람과의 인터페이스의 관점에서 접근해야 한다. 궁극적으로 컴퓨터를 담을 수 있는 미래가 오겠지만 그전까지는 인터페이스가 가장 중요한 본질로 소구될 것이다. 이에 더해서 VR/AR 헤드셋이나 정보축적을 위한 QS(Quantified Self)의 영역에서 많은 버티컬 케이스들이 만들어 질 것이다.두번째 거부하지 않는 소비자는 자신의 의지를 표현할 수 없지만 많은 케어가 필요한 유아와 건강을 집중적으로 관리해야 할 중증환자와 실버세대이다. 이들의 공통점은 타인의 케어가 필요한 대상들이며 특별한 목적과 기능을 가진 웨어러블이 적용되어야 할 주요 소비자이다. 이들은 불편함을 참아가면서 케어 해야 할 니즈가 있고 시대의 변화는 이러한 니즈를 충족시켜 줄 기술을 가능하게 만들어가고 있기 때문에 큰 비용을 기꺼이 지불하는 연계 서비스까지도 적극적으로 수용 할 대상이다. 이들에겐 생명이나 건강과 직결되어 있는터라 웨어러블이 가진 불편함은 기꺼이 참을만한 트레이드오프(Trade-off) 일 뿐이다.또 하나 거부하지 않는 소비자는 반려동물을 기르는 사람들이다. 반려동물 역시 타인의 케어와 관심이 필요하며 사람들이 점점 더 많은 비용을 지불하게 될 대상이다. 웨어러블을 선택하는 대상과 사용하는 대상이 다른 경우인데, 반려동물 역시 불편함을 거부하는 의사표현을 하지 않기 때문에 반려동물의 소유자에게 가치가 있다면 잠재성이 큰 시장으로 성장 할 것이다. 이미 많은 제품과 서비스가 출시되었고, 반려동물의 건강을 모니터링하며 반려동물과 소유자가 인터랙션을 할 수 있게 도와주는 웨어러블과 함께 다양한 서비스들이 바인딩될 것이며 사물인터넷이 케어인터넷으로 진화하는 그 시작점이 될 것이다.지금은 웨어러블 시장이 양극화되고 경쟁도 심화되고 있지만 결국 다양성을 담는 방향으로 계속 진화를 할 것이며 웨어러블이 웨어가 될 수 있는 본질적 가치를 가지게 될 때 자연스럽게 이들은 우리의 습관이 되어 인간의 삶에 한 부분이 될 것이다.[1] 역사뒤로 사라진 페블에게서 배우는 교훈이미지출처: https://www.flickr.com/photos/keoni101/7069578953 CC-BY#라이프스퀘어 #스타트업 #창업자 #창업가 #마인드셋 #조언

풀스택 개발자라는 용어가 가끔 등장한다. 죄송하지만, 한국에서는 이 용어가 정말 잘못 이해된 상태로 사용되고 있다. 처음에 만들어진 의미와 뜻이 한국에 들어오면서 변한 것을 보는 것이 이번만도 아니다.언제나처럼, 이 '단어'가 의미하는 뜻은 '귤이 회수를 건너면서 언제나 탱자가 되는' 한국적인 환경에서는 매우 이상하게 와전된 의미로 사용되고 있다. 특히나 비개발자들인 경영진들이 그러하고, 개발자들도 가끔 잘못된 의미로 사용한다.와전된 의미의 '풀스택 개발자(Full Stack Developer)'는 프런트엔드와 서버 엔드를 넘나드는 모든 것을 다 아는 전지전능한 개발자인 것처럼 쓰인다. 죄송하지만, 풀스택 개발자의 의미는 프런트-엔드부터 서버-엔드까지 모든 것을 다룰 줄 아는 개발자를 의미하는 것이 아니다.이 '용어'가 쓰이는 분야를 조금은 국한시켜야 할 필요가 있다.그것은 '웹'환경의 프론트 영역으로 국한시키는 것이 매우 현명할 것이다. 다음의 링크를 참조하기를 권한다.http://www.sitepoint.com/full-stack-developer/위의 사이트에 있는 이미지와 단어를 차용한다. 아래의 그림을 살펴보라.[이미지출처 : http://www.sitepoint.com/full-stack-developer/ ]OS부터 Database, WebServer, Server Side Code, Browser, Client Side Code를 아우르는 능력을 가진 사람을 Full-Stack Developer라고 부를 수 있다.좀 더 쉽게 이야기하자면, 'Web'환경은 서버사이드 코드와 클라이언트 사이드 코드를 모두 이해하고 작성되어야 한다. 브라우저( 특히나 변덕스러운 호환성 문제들.. )의 스크립트 환경이 효과적으로 가동되기 위해서는 웹서버의 API를 적절하게 디자인하고 구현된 상태에서 동작되어야 하며, 대부분의 코드들은 직접 Database에 영향을 주는 경우가 많다. 더군다나, 소프트웨어 개발을 하려면 형상관리부터 배포 처리를 위한 기술도 할 줄 알아야 한다.맞다. 'Web'개발 환경에서는 Full-Stack Developer가 되지 않으면 제대로 된 개발이 어렵다. 그래서, '웹'에서는 풀스택 개발자를 지향해야 하고, 매우 당연하게 해당 스킬들을 익숙하게 다루어야 한다.풀스택 개발자는 Web의 개발환경에서는 어쩔 수 없이 매우 당연한 기술적인 한계이고 해야 할 업무를 위해서는 필연적인 형태 인 것이다.이렇게 '웹 환경에서의 풀스택 개발자'는 한국에도 많이 존재한다. 상당수의 PHP개발자 분들이 그러한 '풀스택 개발자'인 경우가 많다.그렇지만, 이 풀스택 개발자의 용어는 '개발'이나 '소프트웨어'를 잘 모르는 경영자의 머릿속으로 잘못 들어가서 마치, iOS나 Android APP도 개발하고 Rest API 디자인이나 구현도 하면서, AWS의 분산 환경에 대한 이해나 개발도 모두 가능한 '전지전능한 개발자'와 같은 의미로 잘못 사용되기도 한다.( 더군다나, 디자인능력이 극도로 필요한 자바스크립트나 능동형 웹-UI를 만들어 내는 능력은 전혀 다른 능력이다 )원래 의미의 '풀스택 개발자'는 '혼자서 웹서비스 하나를 만들 수 있는 개발자'라는 좁은 의미로는 맞다. 하지만, 이를 과도하게 해석하거나 아전인수격으로 해석하는 것은 매우 곤란하다. 그것은 바로 한국적인 특수한 환경 때문에 그러하다.슬프지만, 한국적인 의미의 풀스택 개발자가 존재하기는 하고 있다.프로그래머가 기획도 하면서, 서버 구입부터 설치까지 다진 행하고, DB도 일부 다룰 줄 알면서, 웹이나 클라이언트 프로그래밍의 일부도 할 줄 아는 매우 한국적인 풀스택 개발자가 존재하기는 한다. ( 근데, 그런 개발자들을 풀스택 개발자라고 표현하지 않는다. 거의 기업의 잡부(?)처럼 부려지는 경우다. )노가다 - dokata, 土方 -'막일'을 하는 노가다를 하는 잡부가 한국형 풀스택 개발자라고 표현하겠다.하지만, 그런 테크트리로 형성된 한국형 풀스택 개발자들의 실력은 매우 볼품이 없는 경우가 대부분이다. 필자가 공공 SI현장에서 만난 수많은 한국형 풀스택 개발자들이 그러했다.그들은 컴파일러가 만들어내는 에러 메시지에 대한 이해는 없지만, 10년 넘게 업무를 배운 경험과 대충 Linux나 Windows Server의 기본적인 경험과 온통 스파게티 식으로 구성되어진 소스로 만들어진 더 이상 시장이 커지지 않는 한계가 다다른 시장에서 소프트웨어 개발을 하고 있다.태생적으로 '잡부'가 될 수밖에 없는 작업현장에서 진정한 의미의 풀스택 개발자는 거의 형성되기 어렵다. 이런 한국형 풀스택 개발자들은 실제 하나하나의 스킬들을 확인하거나 체크해본다면 거의 대부분 매우 부족하거나, 특정 기능에만 적합한 일반적으로 쓸모없는 기술들이 대부분일 가능성이 크다고 단언하겠다.이런 경향은 게임업계도 비슷하다. 한국형 풀스택 게임 개발자는 게임 기획부터 스프라이트의 2D부터, 포토샵이나 일러스트레이트도 다룰 줄 알며, 3D Max로 3D도 만들고, Auto-Cad로 도면 데이터도 다루고, DirectX에 Unity도 다루며, 서버나 iOS의 앱까지 만들 줄 안다고 하지만, 정작 그 어느 하나도 제대로 못 다루는 경우가 태반이다.물론, 전부 다루는 사람이 없는 것은 아니다. 있기는 있지만... 그분들 굉장히 유명하거나 특정 기술하나 가 대가의 수준이기 때문에 자신이 가진 다른 기술들을 포함해서 자신을 '풀스택 개발자'라고 포장하지 않는다.하지만, 한국에서 유독 '개발자 구인 광고'를 보면 '풀스택 개발자'를 찾는 곳이 많은 이유는 무엇 때문일까?그것은, 무지한 경영진이나 무지한 비즈니스 모델, 무지한 리소스 활용이 난무하는 헬게이트의 주인들이나 그런 단어들을 주로 사용한다고 보면 된다.100% 단언컨대 한 사람의 개발자가 완벽한 풀스택 개발자라고 하더라도, 요구사항이 발생하고 유지보수업무가 존재하는 업무를 하드웨어적인 서버 관리부터 서버 API, 앱 프로그래밍, 웹 프로그래밍을 하기 위한 스킬은 알 수 있다고 하더라도 그 복잡하고 어지러운 업무량은 모두 다룰 수 없다.만일 그런 것이 가능하다고 이야기하는 경영진이 있거나 무지한 영업맨이 있다면 정신 차리라고 조언해주자. 심지어 그렇게 만들 수 있는 서비스는 존재하지 않고, 존재한다고 하더라도.. 어마어마한 '기술적 부채'가 존재하며, 대부분의 가장 비싼 개발자의 리소스를 그 기술적 부채를 해결하기 위해서 사용되고 있을 것이라고.물론, 그렇게 동작하는 허접하고 쓰레기 같은 코드라고 하더라도, 특정 조건과 특정 환경에서는 서비스가 가능한 경우가 한국에는 많이 존재한다. 경영진이나 영업, 기획은 고객들을 설득하고 고객들이 해당 제품과 서비스를 사용하기 위해서 일부를 희생할 것이다. 그리고, 분명 다른 영역에서 누수가 발생하거나 희생되고 있는 것을 잊지 말자.특히나 경쟁이 없는 제품이거나 더 이상 리소스를 투입하기 어려운 소프트웨어나 서비스의 경우에는 이런 형태로도 동작은 할 것이다. 하루에 한두 번 서버의 Oracle 커넥션을 모두 종료하는 유지보수 행위를 하는 전산실의 업무가 그러한 경우 때문에 벌어진다.중견기업이거나 제조업체, 병원의 전산실에 '야간 당직'업무가 있고, 시스템 모니터링에 민감하다면 대부분 '기술적 부채'를 안고 허접하게 만들어진 것뿐이라고 판단하면 된다.말 그대로, 헬조선의 헬게이트, 헬(!)한 업무환경으로 소프트웨어 개발자로서 비전이 없는 영역이라고 생각하면 된다. 하지만, 그럼에도 불구하고... 스타트업 경영진이나 대기업, 중소기업 경영진들은 '풀스택 개발자'의 환상에 대해서 이야기한다.'모든 것을 다 하는 개발자'가 있으면, 복잡한 커뮤니케이션 비용도 안 들고, 인건비도 적게 들것이라는 착각을 한다. 다만, 이 부분만큼은 명쾌하게 이야기하겠다. '그런 회사 가지 말라'는 것이다.'풀스택 개발자'를 구인하고 있는 회사는 개발자의 무덤이라는 것이다. 대부분 그러하다. 그 이유를 다음과 같이 정리하겠다. 그들이 '풀스택 개발자'를 뽑고 싶은 이유는 간단하다. '돈'이 없어서다. 그리고, 다음의 이유들이 있는 경우이다.하나. 경영진이 요구사항 정의도 제대로 못하므로 개발자와 의사소통에 자신이 없다. 그래서, 풀스택 개발자를 구하려고 한다. 한 명 하고만 이야기하면 될 것이라고 착각한다.둘. 개발자의 인력이 몇 명이 투입되는지에 대해서 평가나 정의가 불가능하므로, 풀스택 개발자를 구하려 한다.셋. 개발자가 두 명, 세명이 있다면 팀 리더도 있어야 하고, 관리자도 있어야 하므로 그 비용을 줄이기 위해서 풀스택 개발자가 필요하다. 한마디로, 돈이 없다.넷. 현대의 웹서비스들을 가동하기 위해서는 최소한의 비용과 인건비가 투여된다. 이 비용을 투자할 정도로 비즈니스 모델에 가치가 없기 때문에 여러 명의 개발자를 고용할 수 없기 때문에 풀스택 개발자를 구하려 한다.다섯. 풀스택 개발자라면 막연하게 다 해줄 것 같은 환상을 가진 경영진이 있는 경우이다. 슬프지만, 전설의 개발자인 '제프 딘'을 고용한다고 하더라도, 삽질을 할 것이다.물론, 스타트업에 초기에 합류하면서 CTO의 역할을 부여받았다면 조금은 입장이 달라진다. 정당한 지분을 받고, 미래의 가치에 대해서 나눌 수 있다면, 해당 롤을 가진 사람은 알아서 '풀스택 개발자'가 될 가능성이 크다. 그러므로, 매우 당연하지만 CTO는 풀스택 개발자에 근접되면 좋기는 할 것 같다. 하지만, 현실적으로는 그렇게 세팅하지 못하는 경우가 대부분이다.그리고, 냉정하게 초기 개발이나 Lab수준, 시리즈 A를 투자받기 전의 '소프트웨어'나 '서비스'는 대부분 비즈니스 모델을 증명하는 수준에서 끝내는 것이 바람직하다. 굳이, 환상의 개발자나 풀스택 개발자가 아니라도 비즈니스 모델을 검토하고 증명하는 모델을 구현하는 것은 충분하게 가능한 경우가 대부분이다.사용자가 수백만 명도 아니고, 구현된 기능들도 수백 가지가 아니며, 아직은 스파게티 식으로 구성하더라도 무방하기 때문이다. 해당 기술적 부채는 서비스의 증명 후에 해당 코드는 버려지고, 다시 개발팀을 제대로 세팅하여 구현하면 되기 때문이다. 더군다나, 대부분의 스타트업은 고속 개발을 해야 하기 때문에 '풀스택 개발'이 가능한 '웹'만으로는 모든 것을 커버하기 어려울 것이다.좌우지간, 간단하게 이야기해서 '풀스택 개발자'타령하는 구인광고를 보게 된다면, 그 회사나 팀은 무언가 잘못 생각하고 있거나, '돈'이 없는 조직이라고 생각하면 된다. 거기에, '기술'이나 '개발'에 대해서는 아무것도 모르는 사람이 사장이 존재하는 곳이라고 생각하면 된다.헬게이트에 입성하고픈 개발자라면 '풀스택 개발자'를 구인하는 곳으로 가면 된다. 엄청난 '일'의 쓰나미를 경험하고, 인성이 피폐해지는 것을 경험할 것이다.필자는 국내 최고의 개발자들을 여럿 알고 있다. 하지만, 그분들은 자신들을 '풀스택 개발자'라고 이야기하지 않는다. 그 용어가 의미하는 것 자체가 '날림'이라는 것을 너무도 잘 알고 있기 때문이다. 물론, 10년 20년을 소프트웨어 개발을 하다 보면 얻어지는 경험과 지식들이 있다.궁극적으로는 풀스택 개발자가 이야기하는 비슷한 테크트리를 대부분 알고는 있게 된다. 하지만, 경력 20년 되고 하나의 도메인에 익숙하며, 특정 분야의 대가인 분들을 스타트업에서 고용한다는 것은 거의 불가능에 가깝다. 간혹, 그런 분들이 직접 스타트업을 하는 것이라면 모를까 말이다.이제 이야기를 마무리하겠다.'웹 개발'을 하려면 '풀스택 개발'을 지향하는 것은 맞다. 하지만, 그것 자체가 완벽한 풀스택 개발을 의미하는 것이 아니라는 것을 생각하기 바란다. 그리고, 경영진이나 비개발자들에게도 다시 한번 이야기한다. '풀스택 개발자'를 구인하겠다는 환상을 버리기 바란다.그런 사람 없고, 있다고 하더라도... '풀스택 개발자'를 구인하겠다는 발상으로는 절대 초빙하거나 모실 수 없다는 것을... 깨몽 하기 바란다.물론, '풀스택 개발자'처럼 이것 저것 다하는 정성스럽고, 일에 애정 넘치는 개발자들을 제대로 대우해주시기를... 기술로써의 풀스택 개발자가 아니라, 그 기업이 원하는 일을 풀스택 개발자처럼 일할 뿐이다. 그들에 대한 애정 넘치는 말한마디... 경영진들에게 부탁드린다.갑자기, '풀스택 개발자'에 대한 환상에 대해서 정리하고 싶어서 한 번에 글을 써 내려갔다. ~.~

달리기는 인기 스포츠가 아니다. 남자들끼리는 첫 만남에 으레 무슨 운동을 좋아하는지 묻곤한다. 축구나 농구, 야구는 단골손님 격인 대답이고, 직장인이 되서는 간혹 골프나 테니스를 좋아한다는 대답도 듣는다. 하지만 아직 달리기를 좋아한다는 대답을 들은 기억은 없다. 나 또한 달리기를 처음부터 좋아했던 것은 아니다. 어린 시절 나도 조던의 광팬이었고 농구도 사랑했다어린시절 나는 스포츠 경기 보는 것을 즐겨했다. 인기종목은 말할 것도 없고, 핸드볼이나 배드민턴, 탁구와 같은 종목도 밤을 새며 세계선수권 대회를 챙겨보는 스포츠 마니아였다. 당연히 올림픽이나 아시안게임과 같은 스포츠대회도 사랑했다. 하지만 수많은 스포츠 경기 중 마라톤, 그 중에서도 남자마라톤만은 영 호감이 가지 않았다. 2시간 넘게 똑같은 자세로 달리는 모습을 보고있는 것은 여간 지루한 일이 아니었다. 게다가 올림픽은 항상 남자마라톤을 끝으로 폐막을 하니, 나에게 남자마라톤은 대회의 끝을 알리는 우울한 소식 이상도 이하도 아니었다. 가끔은 올림픽을 보면서 왜 많은 사람들이 좋아하지 않는 마라톤이 행사의 대미를 장식해야하는지 의문이 들었다. 축구나 농구로 바꾸면 더 많은 사람들이 즐기며 축제를 마무리할 수 있지 않을까? 지금 생각해보면 그 당시 달리기는 나에게 확실한 비호감 종목이었다.이대로 2시간을 뛰는데 왜 봐야할까그런 내가 달리기에 처음 재미를 붙이기 시작한 것은 군대에서였다. 남들이 다 축구나 족구를 열심히 할 때 달리기에 재미를 붙인건 달리기에서, 정확히 말하면 '오래 달리기'에서 나도 모르는 재능을 발견했기 때문이다. 사실 학창시절 밤새 각종 스포츠 경기를 챙겨볼 정도면 직접 몸을 쓰며 운동을 하는 것도 좋아할 만하다. 하지만 나에게 스포츠가 '그저 보는 것'에 머물렀던 이유는 나의 몹쓸 운동신경 덕분이다. 친구들과 스포츠 이야기를 하면 정확한 선수 이름과 성적까지 대며 아는체를 했던 나는 경기장에만 들어서면 '구멍' 신세를 벗어나기 어려웠다. 축구를 하면 내가 맡는 지역에서 항상 골 찬스가 생겼고, 농구를 하면 나의 상대가 늘 득점왕이 됐다. 그러다보니 직접 뛰는 스포츠와 자연스레 거리가 멀어졌다. 학창시절 대부분 스포츠가 반대항이나 팀대항 성격을 띄었던 것도 운동과 작별하는 데에 한몫했다. 운동 자체를 즐기면서 할 수 있는 환경은 없었고, 잘하는 사람과 못하는 사람의 구분만 있을 뿐이었다. 군대에서는 운동을 잘하고 못하고를 떠나서 그냥 해야했다. 아침마다 달리기를 하는건 예외없는 의무였다. 아침 달리기에서는 대개 3-5km 를 뛰었는데, 이 정도의 거리는 사실 대단한 운동신경이 필요하지 않다. 그냥 꾀부리지 않고 열심히 뛰기만 하면 누구나 완주할 수 있다. 나는 몸무게가 과하게 나가는 것도 아니고 흡연을 했던 것도 아니라 달리기를 하면 곧잘 선두 그룹에 속해서 골인을 하곤했다. 그렇게 처음으로 '못하지 않는 운동' 을 발견했다. 늘 한두가지 정도 잘하는 운동을 갖고 싶었는데, 처음으로 적성에 맞는 운동을 찾게된 것도 반가웠다. 자연히 달리기를 더 잘하고 싶어졌다.군대에서의 시간을 의미있게 보내는 것은 많은 남자들의 화두다. 나 또한 똑같은 2년이라도 이왕이면 시간을 '보내는 것'이 아니라 '의미있게 쓰고' 싶었다. 영어공부를 하는 사람도 있고 책을 읽는 친구도 있었다. 그 때 나는 뭐에 홀렸는지 중앙일보 마라톤 대회를 신청했다. 마라톤을 하는 사람들에게는 두개의 큰 국내 메이저 대회가 있는데, 3월의 동아일보 대회와 10-11월의 중앙일보 대회다. 나는 제대를 앞둬 시간이 많을 것 같은 중앙일보 대회를 택했다. 마라톤 대회를 신청하고나니, 그제서야 달리기를 좋아하는 사람들이 꽤 많은 사실이 보이기 시작했다. 마라톤 대회는 전국에서 매주 열리는 행사였고, 심지어는 50km 나 100km 를 완주해야하는 울트라 마라톤 대회도 있었다. 국내 메이저 대회는 참가자수만 2-3만명을 넘기는 대규모 행사라는 사실도 이 때 처음 알았다. 역시 경험하지 않은 무언가를 지레 짐작하는 건 꽤나 위험한 일이다.인기 마라톤 대회는 2만명 이상이 참가하는 대규모 행사다마라톤 대회에 접수를 하고 기분 좋게 새옷을 사들고 달리기를 나갔다. 평소 5km 를 가뿐하게 뛰기에 오늘은 한번 되는데까지 달려보자는 심산으로 달리기를 시작했다. 하지만 막상 대회를 나간다고 생각하니 근육도 경직되고 생각만큼 달리기가 쉽지 않았다. 10km 를 넘어서면서 부터는 종아리랑 허벅지 근육이 금방이라도 끊어질 것처럼 통증을 호소해왔다. 12km 나 뛰었을까, 나는 마라톤의 높은 벽을 처음으로 실감하고 공부와 유경험자의 조언을 바탕으로 훈련계획을 다시 짜기 시작했다.마라톤 완주를 위해서 가장 중요한 것은 대회 참가 2주전까지 40km 이상을 뛰어 보는 것이다. 사실 풀코스 대회에 참가한다고 하는 사람중에 호흡이 차는 것을 걱정하는 사람은 많지 않다. 달리기를 완주할 수 있고 없고는 다리 근육의 지구력에서 판가름이 난다. 이 지구력을 길러주는 가장 좋은 방법은 매번 달리는 거리를 계속 높여서 40km 이상까지 한번에 뛸 수 있는 몸 상태를 만드는 것이다. 달리기를 해보면 자신의 기록대비 한번에 10km 이상 거리를 늘리는 것은 거의 불가능하다. 10km 를 1시간에 뛰었으니 20km 면 2시간이면 뛸 수 있겠다고 생각한다면 정말 큰 착각이다. 12km 쯤 지나면 다리에 흡사 쇠라도 달린 것 처럼 허벅지와 종아리가 무거워진다. 15km 정도까지 버텼다면 다리에서 이 이상은 도저히 버틸 수가 없다는 강력한 신호를 보내온다. 나는 매주 5km 씩 달리는 거리를 늘리는 연습을 했다. 대회 2주전까지 40km 를 뛰어야 하니 역으로 계산하면 최소한 대회 2달 전부터는 제대로 연습을 해야한다. 게다가 20km 이상을 뛸 때는 회복시간도 고려를 해야하기 때문에 적어도 대회 3달 전부터 스케줄을 잡고 연습을 했다. 이런 연습 스케줄을 고려한다면, 대회 참가 2달전쯤 하프마라톤을 한번 뛰어보는 것이 좋다.마라톤 완주가 목표라면 3달 전부터는 제대로 준비해야 한다 대회 준비에 돌입했다면 꾸준한 연습외에 지켜야 할 것이 또 있다. 바로 이 기간동안 술과 담배를 끊는 것이다. 술이야 가볍게 마시는 것은 괜찮다고 하지만, 담배는 장거리 달리기에 정말 좋지 않다. 많은 애연가 마라토너들도 대회 준비에 돌입하면 무섭게 담배를 멀리한다. 경험자들의 말에 따르면, 담배 한모금이라도 호흡에 엄청난 영향을 줘서 다리를 무겁게 한다고 하니 초심자들로서는 새겨들어야 할 필요가 있다. 반면, 마라톤을 준비하는 사람들에게 추천하고 싶은 습관은 등산이다. 등산은 허벅지부터 종아리까지의 다리 힘을 길러주는 데 효과가 좋다. 다리 힘을 기르기 위해서는 가파른 산을 오르는 것도 좋지만 경사가 급하지 않은 산을 뛰어가듯 오르는 것도 좋다. 막상 풀코스를 뛰어보면 내가 계속 다리힘을 강조하는 이유를 느낄 수 있을 것이다. 나 역시 위의 방법으로 대회 3개월전부터 꾸준히 운동을 했고 습관들을 조절해왔다. 어차피 군대에 있어서 술도 먹지 못하는 최상의 환경에 있어 나로서는 대회 준비가 수월했다. 이렇게 준비를 잘 해두었다면 사실 완주는 어느정도 눈에 보이는 목표가 된다. 하지만 대회 당일의 컨디션도 완주에 영향을 미치다보니 또 한가지 준비할 것이 있다. 중앙일보나 동아일보와 같은 대회는 대회 당일 날씨가 많이 춥다. 몸이 차가운 상태로 달리기를 시작하면 근육이 쉽게 경직되기 때문에 몸을 따뜻하게 할 장갑과 큰 비닐봉지를 준비하는 것이 좋다. 큰 비닐봉지는 목이 들어갈 구멍을 뚫어서 입는 용도다. 달리기를 시작할 때는 날씨가 많이 춥지만 이내 몸에 열이 발생하면 긴팔이나 두꺼운 옷은 거추장스럽다. 이럴 때를 위해 달리다가 벗어서 버릴 수 있는 헌옷이나 비닐봉지를 미리 준비하면 매우 좋다.  세탁소 비닐봉지를 강력하게 추천한다.이렇게 갖은 준비를 하여 2006년 11월 5일 드디어 나는 이봉주 선수와 함께 잠실의 도로를 함께 달렸다. 물론 내가 15키로 지점을 통과할때 빛의 속도로 35키로를 통과하던 이봉주 선수의 모습을 잠깐 봤을뿐이다. 어쨋든 나는 생애 처음으로 풀코스를 완주했다. 개인적인 목표는 42.195km 를 말 그대로 걷지 않고 '완주' 하는 것이었다. 너무나도 힘들어서 달리는 도중에 솔직히 욕도 많이했지만, 철저한 준비 덕분에 개인적인 목표를 달성했다. 3시간 43분 28초. 첫 풀코스 치고는 꽤나 좋은 성적으로 완주할 수 있었다.함께 뛰었다는 것을 강조하고 싶은 이봉주 선수사실 달리기 전, 풀코스를 완주하고 골인하는 순간의 감정에 대해 많은 생각을 했다. 입대 당일 부모님께 절을 드릴 때만큼 강렬한 감정이 오지 않을까. 혹시 누구도 느끼지 못한 행복감을 맛보는 것은 아닐까. 이런 궁금증을 갖는 분에게 얄밉지만 나는 답을 드릴 생각이 없다. 죽어라 4시간을 뛰고 난 후에 느끼는 감정이니만큼, 한 번 연습해서 직접 그 기분을 느껴보라고 권하고 싶다.끝으로, 특별한 운동신경 없이도 성실함만 가지고 누구나 도전해 볼 수 있는 마라톤을 많은 사람들에게 추천하고 싶다. 인생에서 잊지 못할 큰 추억과 경험이 될 것이다. by 꾸준한 운동에 관심있는 30대초 남자 직장인챌린저스 - 확실한 목표달성 꾸준한 습관형성 앱www.chlngers.com

Editor. 스켈터랩스에서는 배경이 모두 다른 다양한 멤버들이 함께 모여 최고의 머신 인텔리전스 개발을 향해 힘껏 나아가고 있습니다. 스켈터랩스의 식구들, Skeltie를 소개하는 시간을 통해 우리의 일상과 혁신을 만들어가는 과정을 들어보세요! 스켈터랩스의 잡학다이너마이트 변규홍 님을 만나보세요:)사진1. 스켈터랩스의 SW Engineer, 변규홍님규홍님의 인터뷰는 2개 파트로 나뉘어져 있습니다. 에서는 인공지능 대화 엔진을 개발에 관한 스켈터랩스 업무 이야기를 담았습니다. 을 아직 읽지 않은 독자들이라면, 먼저 ‘스켈티 인터뷰 w.Kyuhong’을 읽고 오시기를 추천합니다.’PART2. About Kyuhong Byun.Q. 자기 소개에 ‘20년 전부터 컴퓨터 공부를 시작한 컴퓨터 덕후'라는 얘기를 했다. 컴퓨터를 좋아하게 된, 그리고 개발자의 길을 선택한 계기가 따로 있나.A. 초등학교 2학년 때 컴퓨터에 대한 만화책을 우연히 선물받았다. 만화책에서 ‘GW 베이직(GW-BASIC)’언어로 작성된 컴퓨터 프로그래밍 코드가 딱 한 줄 적혀있더라. 그 한 줄을 컴퓨터가 실행하는 과정을 몇 페이지에 걸쳐 설명하는 책이었다. 책을 읽으며, ‘이걸 익힌다면 나도 게임을 만들 수 있지 않을까'란 생각을 했다. 당시 나는 일본의 컴파일(COMPILE)이라는 회사에서 제작한 PC용 게임 잡지인 디스크 스테이션(Disc Station)에 푹 빠져있었다. 그래서 GW베이직을 공부한다면 컴파일 사에 입사해서 아기자기하고 재밌는 게임을 만들 수 있겠다는 꿈을 꾸게되었다.Q. 어렸을 적의 꿈을 현실로 만들기가 쉽지 않지 않나. 어떻게 컴퓨터 공부를 이어갈 수 있었나.A. 어머니를 통해 상업계 고등학교 교과서인 ‘전자계산일반'을 구할 수 있었다. 그 책을 보면서 컴퓨터에 퀵베이직(Quick-Basic) 코드를 하나씩 입력해 보니 신기하게도 전부 그대로 실행이 되더라. 교과서를 따라 만들어보니 간단한 사칙연산을 실행하는 것에 멈추는 컴퓨터 계산기보다 훨씬 똑똑한 복합 연산 계산기까지 만들 수 있었다. 이러한 관심이 자연스럽게 한국정보올림피아드 대회 준비로 이어졌다. 대회를 준비하며 더욱 다양한 프로그래밍 언어를 배웠고, 복잡한 문제를 해결하는 알고리즘과 자료구조 구현법에 대하여 하나씩 접근해갈 수 있었다. 당시 <컴과 대화 맥스>라는 프로그램이 있었는데, 지치지 않고 나와 수다를 떨어주는 프로그램이었다. 사실 맥스는 그닥 똑똑한 프로그램은 아니었다. 툭 하면 무슨 말인지 모르겠다는 응답만 반복했지만, 그렇게 끈덕지게 대답을 이어가고 지치지 않는 다는 점이 재밌었다. 맥스와 대화하면서 맥스보다 더 똑똑하고 흥미롭게 대화를 이어갈 수 있는 프로그램을 만들고 싶은 욕심이 생겼다.Q. 어라, 그렇다면 컴파일 사의 게임프로그래머가 되는 꿈은 접은건가.A. 안타깝게도 2000년대 초에 컴파일 사는 도산했다. 그러나 컴파일 사를 이끌었던 니이타니 마사미츠 회장이 20여년 만에 컴파일마루라는 회사를 세워 게임 개발자로 돌아왔더라. 68세의 나이에 게임 개발은 물론 홍보를 위해 인터넷 방송까지 진행하고 있다. 다시 일어서는 니아티니 회장의 행보를 보면서 자극을 많이 받고있다.Q. 개인적으로 최근 가장 뿌듯함을 느낀 순간을 말한다면.A. 스켈터랩스는 자율출퇴근제를 운영하고 있다. 여기서 ‘자유'가 아닌 ‘자율'이라는 점에 주목해야 한다. ‘자율'이란 자신이 최선의 퍼포먼스를 낼 수 있도록 스스로 알맞은 규칙을 정해서 동료들과 협업함을 뜻한다고 생각한다. 사실 엄격한 출퇴근 시스템을 갖춘 이전 직장에서 스켈터랩스로 넘어오면서 한동안 자기 관리 문제를 겪었다. 체중도 많이 불었다. 건전한 몸에 건전한 정신이 깃든다고 하지 않나. 그래서 회사 근처의 헬스장에 등록하고 PT(Personal Training)을 시작했는데, 입사 초기만 해도 97킬로에 달한 몸무게를 현재는 20킬로 이상 감량한 상태다. 처음에 PT를 받기 시작했을 때 몸은 정말 힘든데, 체중도 변하지 않는 상태가 몇 주간 지속되었다. 스트레스 받고 지치기만 하더라. 그런 시기를 인내하고 견디니, 그제서야 몸에 변화가 온 것을 느낄 수 있었다. 그것도 엄청난 변화를 말이다. 이렇게 나름의 다이어트 성공 가도를 달리고 있는 것이 최근 느낀 뿌듯한 경험 중 하나다.Q. 네임카드(Name Card)에 독특한 자기소개를 발견할 수 있다. 네이버 웹툰 <공대생 너무만화>를 자문했는데, 어떻게 시작하게 되었나.A. 4년 전 카이스트에서 아티스트 레지던시 프로그램에 참여중이셨던 최삡뺩 작가와 인연을 맺게 되었다. <공대생 너무만화>의 자문으로 친구를 소개하는 과정에서 자연스럽게 친구와 함께 자문을 맡게 되었다. 사실 자문이라고 해서 거창한 것은 아니다. 공대 개그에 현실성을 불어넣는다거나 디테일을 살리는 정도다. 예를 들어 기절해 있던 공대 남학생이 이런 말을 들으면 너무 깜짝 놀라 눈을 번쩍 뜰 것 같은 대사를 요청받았다. 마침 당시에 전문연구요원 제도 존폐에 대한 얘기가 오가고 있었고, 이에 ‘전문연구요원 폐지됐대'라는 대사를 만들었다. 이 웹툰은 컷툰 형식으로 구성되어있는데, 해당 컷에 수많은 댓글이 달리는 것을 확인할 수 있었다.Q. 웹툰을 자문하면서 재미있는 일도 많았을 것 같다. 예상하지 못한 독자의 피드백을 받는 재미도 있을텐데, 에피소드를 소개해 줄 수 있나.A. 재미있는 에피소드야 굉장히 많다. <공대생 너무만화>의 이야기는 주인공이 대학에 입학하면서 시작된다. 주인공이 입학할, ‘토목공학과'지만 ‘토목공학과스럽지 않은' 학과 이름이 필요했다. 그래서 ‘사회에코시스템디자인과'라는 이름을 만들어냈다. 그런데 공교롭게도 독자들 사이에서 엉뚱한 오해가 시작되더라. <공대생 너무만화>가 교육부의 프라임 사업(산업연계 교육활성화 선도대학, PRIME) 홍보용 기획이라고. 학과를 통폐합하여 융합학과를 만드는 프라임 사업 때문에 비슷한 이름의 학과들이 생겼으니 그렇게 오해할 만은 했다. 작품이 진행되면서 오해가 풀린 일부 독자들은 아예 <공대생 너무만화>가 프라임 사업 비판 웹툰이라는 창의적인 해석을 내놓기도 하였다. 이런 저런 다양한 오해 속에서도 묵묵히 작업하는 작가분들에 대한 존경심까지 들었다.  사진2. <공대생 너무만화> 15화, 1화, 6화, © 최삡뺩웹툰의 첫 컷에 각종 수학, 과학, 혹은 프로그래밍 관련 문제를 출제하기도 했는데 문제를 받아보는 독자들의 반응이 정말 재미있다. 열심히 문제를 풀기도 하지만 엉뚱한 반응이 나오기도 한다. 한번은 ‘<발받악에 땀 망희 났어>를 아희 프린터로 실행하면 ?이다’라는 문제를 냈다. 딱 보면 발바닥에 땀이 많이 났다는 한국어 문장을 외계어처럼 적은 것처럼 보이지 않나. 그렇지만 사실 ‘아희'라는 프로그래밍 언어로 된 코드다. ‘발받'이라는 코드가 숫자 3과 5를 뜻하고 ‘땀'은 곱셈, ‘망'은 출력이라는 뜻이다. 다시 말해 ‘3과 5를 곱셈하여 출력하시오'라는 코드다. 이 컷의 베스트 댓글은 ‘그냥 한글이라길래 왠지 모르게 순간 설렌 문과입니다'더라. 이외에도 기막히게 재밌는 댓글들이 쏟아졌다. 나중엔 몇몇 아희 인터프리터의 개발자들이 테스트 케이스로 이 문제를 넣어주더라.Q. PT부터 웹툰 자문까지 다양한 활동을 하고있다. 평소의 취미는 무엇인가, 취미 부자로 보인다.A. 일단 서사, 즉 이야기라는 게 담긴 것이라면 뭐든 좋아한다. 만화부터 영화, 소설, 드라마, 연극까지 서사가 있는 콘텐츠는 다양하게 보는 편이다. 일본 스타일의 롤플레잉 게임도 서사가 풍부해서 즐겨 하고있다. SF소설 작성 특강을 듣고 꾸준히 소설도 쓰고 있다. 최근에는 컴퓨터의 기술 표준에 대한 논의에 관심을 갖고 있다. 한국인터넷거버넌스포럼(Kr-IGF, Korean Internet Governance Forum)이라는 행사에 패널로 참여했고, 인터넷 도메인 주소 규칙을 제정하는 KGP(Korean Generation Panel) 회의도 정기적으로 참관하고 있다. 깊은 논의를 거쳐 인터넷 생태계가 건강하고 발전적인 방향으로 운영되기를 바라고 있다.Q. 개발자이지만 다방면에 관심을 갖고 있는 것으로 보인다. 최근에 관심을 가지고 있는 이슈가 특별히 있는지.A. 얼마 전, 소프트웨어 마에스트로(SW Maestro) 과정 홈커밍 데이를 다녀왔다. 과학기술 정보통신부에서 매년 컴퓨터 분야에서 기술이 우수하거나 발전 가능성이 높은 100여명의 연수생과 산업계의 시니어 엔지니어 멘토를 을 선발하고 산업계의 시니어 엔지니어를 멘토로 선정하여 뛰어난 엔지니어로 성장하도록 독려하고 있다. 2010년 선발된 1기 연수생으로 홈커밍데이에 찾아가 보니 8기 연수생까지 폭넓은 연령층의 개발자 선, 후배들과 하루 종일 업계 동향, 최신 기술은 물론 다양한 주제로 이야기를 나눌 수 있었다. 이렇게 개발자로서 성장할 수 있는 기회와 개발자들이 교류할 수 있는 네트워크가 더 풍성해지고 넓어졌으면 좋겠다. 현재도 여러 기업과 비영리조직에서 다양한 캠프, 기술 컨퍼런스를 개최하는 등 다양한 성장과 교류의 장이 만들어지고 있는데, 이를 더욱 활성화하고 지원하여 양질의 개발자 네트워크가 형성되는 데 정부가 할 수 있는 일이 더 있지 않겠나.인공지능 대화 엔진 개발에도 정부의 도움이 절실하다. 다른 언어와 달리 한국어는 특히 엔진 개발을 위한 기초 자료가 너무나 부족한 게 현실이다. 자연언어처리 분야에서는 각 언어마다 이 언어에서 사람들이 실제로 쓰는 문장들을 폭넓게 모아둔 ‘말뭉치’(Corpus)가 기술 발전에 큰 영향을 준다. 특히 문장의 성분을 자세히 분석하여 함께 정리된 말뭉치가 풍성하면 풍성할수록, 머신러닝을 비롯한 다양한 기술에 힘입어 컴퓨터 스스로 사람의 언어를 스스로 학습함은 물론 이를 활용한 더 많은 가능성을 열 수 있다. 그러나 현재는 공개된 말뭉치가 너무 적고, 시대에 따라 개선되는 것도 미약하다. 그나마 안심하고 쓸 수 있는 신뢰도 있는 자료는 2000년대 초반에 구축되고 더 이상 개선이 없는 국립국어원의 ‘21세기 세종 계획’이 전부다. 많은 개발자들이 공통적으로 이 문제를 토로하는데, 어떻게 해야 메시지를 잘 전달하고 개발자끼리도 협업하여 기술 전반을 발전시킬 수 있는지에 대해 고민하고 있다.사진3. 소프트웨어 마에스트로 과정, 과학기술정보통신부가 프로그램을 운영하고 있다. 출처: SW Maestro 과정 페이스북Q. 개발자를 꿈꾸는 이들에게 하고싶은 말이 있다면.A. 수학에는 왕도가 없다고 한다. PT를 받으며 체중을 조절하는 것도 인내의 과정이었다. 개발자의 길도 마찬가지라고 생각한다. 지금 당장 눈 앞에 멋있는 결과를 내기 위해 튜토리얼(Tutorial)만 따라한다면, 단기간 내에 성과를 볼 수는 있지만 새로운 문제에 직면했을 때 스스로 해결책을 찾기 어려워진다. 때문에 튜토리얼을 따라하더라도 그 과정을 세심하게 들여다보고 원리를 이해하기 위해 인내심을 갖고 공부하면 좋겠다. 내가 구현한 코드, 내가 실행시킨 명령이 어떤 가정, 어떤 제반 환경, 어떤 원리에서 작동하는지 궁금해하고 깊이 파다 보면, 자연스럽게 같은 걸 두 번 세 번 공부하지 않고 한번에 깊게 이해할 수 있다.또한 혼자 공부할 경우 다른 사람이 이해하기 좋은 코드를 짜는 것을 소홀히 하게 되는 경향이 있다. 다른 사람이 작성한 코드를 읽어보고, 어떻게 하면 동료들이 이해하기 쉬운 코드를 짤 수 있는지 생각할 수 있을 때 폭넓은 발전을 할 수 있다. 좋은 동료와 함께 공부하는 것을 추천한다. 학생 신분이라면 소프트웨어 마에스트로 과정과 같은 기회를 적극 활용하는 것도 한 방법이다. 실제로 스켈터랩스에도 나를 비롯해 소프트웨어 마에스트로 과정을 거친 엔지니어들이 여러 명 있다.Q. 변규홍님 개인의 꿈은 무엇인가.A. 나와 하루 종일 재미있게 대화하는 챗봇을 개발하고 싶다. 일본어로 된 만화책을 집어넣으면 한국어 번역본이 바로 나오는 컴퓨터 프로그램도 만들고 싶다. 이 꿈을 위해서는 자연언어처리 기술과 머신러닝 발전에 기여하는 것이 우선이라고 생각한다. 그리고 이런 꿈을 함께 꿀 수 있는 좋은 동료를 스켈터랩스에서 더욱 많이 만나고 함께 나아가고 싶다.Q. 마지막으로 하고싶은 말은.A. 내가 가장 동경하는 개발자 중 한 분이 후배들에게 꼭 들려주고 싶은 이야기가 무어냐는 질문에 이렇게 답했다. ‘시간에 쫓겨 살지 말아요. 서두르지 않아도 괜찮아요. 넘어지거든 울어도 돼요. 아무렇지 않은 척 굴지 말고 자기 자신을 좀 더 아껴요.’ 내 생각에 우리 시대의 개발자들은 그 어느 때보다 강도 높은 경쟁 속에 살고 있다. 그 경쟁에서도 이 말을 잊지 말고 자신을 아끼고 돌아보며 살아가면 좋겠다.#스켈터랩스 #사무실풍경 #업무환경 #사내복지 #기업문화 #개발팀 #팀원인터뷰 #팀원소개 #팀원자랑

뜨거운 여름 오후, ZOYI 사무실에서 폭염보다 뜨거운 토론이 벌어졌다.‘채널팀 신입 개발자 ‘후드'의 닉네임의 의미는 뭘까?’세상 기발한 추측들이 쏟아져 나왔다. 로빈후드, 패스트후드, 후드티, 후드득, 후드리챱챱, 후드염(?)까지...다양한 추론드립들로 화이트보드가 꽉 차버렸다사무실에서 이런 (우리끼리만) 재밌는 놀이를 하게 된 건 ‘웰컴런치보드 (Welcome Lunch Board)' 가 생긴 후부터다. 신규 입사자와 점심 약속을 조율하기 위해 화이트보드를 활용하기 시작한 것이다. 생긴지 몇 달 되지 않았지만, ZOYI 사무실에 놀러왔다가 아이디어가 맘에 들어 내부에 도입한 회사도 생겼다고 한다. 장난으로만 가득해보이는 이 게시판은 어떻게 탄생했을까.역삼동 프리덤🤟ZOYI는 근무 분위기가 자유로운 편이다. 업무 능률을 높일 수 있도록 출퇴근 시간이 꽤 탄력적이며 부분적인 원격 근무도 가능하다. 쉬는 시간이면 탕비실 소파에 앉아 수다를 떨고, 팔굽혀펴기를 하기도, 기타 치며 노래를 하기도 한다.요즘 핫한 팔굽혀펴기 소모임(?)🏋🏻‍♀️ 활동중여유가 있을 땐 보드게임 한판 🎲누구나 시작은 어려워즐겁게 함께 어울리는 분위기가 ZOYI의 매력이지만, 신규 입사자 분들과 이야기하다 보니 이 자유가 조금 불편하게 느껴질 수 있다는 사실을 발견했다. 너무 자유로워서 점심시간에는 언제 엉덩이를 떼고 일어서야 할지도 모르겠고, 이미 친하게 지내는 기존 멤버들 사이에 갑자기 끼어들기도 어색하단 것.끄잉 부끄러...우리의 따뜻한 분위기가 이런 소외감을 낳을 수 있다니! 물론 혼자서 시간을 보내는 게 더 편한 사람들도 있지만, 자발적인 아싸와 인싸가 되지못한 아싸는 다른 법.운영팀 회의시간, 고민이 시작되었다. 어떻게 하면 신규 입사자들이 자연스럽고 즐겁게 회사에 적응할 수 있을까?운영팀 멤버 중 가장 최근에 입사했던 나의 경험을 회고하며 함께 실마리를 풀어 나가 보았다. 나 또한 ZOYI에서의 처음이 있었지만 적응이 크게 어렵진 않았다. 회사 안의 모든 팀과 두루두루 일을 하게되는 운영팀 특성상, 초반에 미리 다양한 팀원들과 점심 약속을 잡아 두었던 운영팀 동료들의 배려가 있었기 때문이다.입사 초기 1~2주간 나의 캘린더는 점심 약속으로 든든하게 채워져 있었다. 그 시간 동안 함께 밥을 먹으며 발견한 사소한 공통점이나 이야깃거리는 관계가 자라는 씨앗이 되었고, 잠깐이라도 얼굴을 익혔던 시간이 빠르게 회사에 적응하는 데 큰 도움이 되었다.반겨주셔서 감사합니다 (꾸벅)(_ _)밥이 답이다밥 얘기를 나누다보니, 신규 입사자의 어려움을 해결할 실마리가 보였다. 다른 신규 입사자들도 초반에 이와 같은 경험을 한다면 좀 더 편안하게 회사에 적응할 수 있지 않을까 하는 생각이 들었다. 일주일 정도, 회사가 신규 입사자와 함께 식사하는 사람들의 점심 식대를 지원해 주면 좋지 않을까? 그렇게 회사에서 신규 입사자의 일주일 약속을 미리 잡아주는 '웰컴런치(Welcome Lunch)'가 시작되었다.실행, 또 다른 고민신입 멤버를 환영하며 함께 식사하는 일주일(게다가 법카 지원도 된다!), 마다할 이유가 있을까? 하지만 기대와 달리, 예상치 못한 문제들이 발견되었다.우리는 웰컴런치 일정 조율을 호스트(신입 멤버가 회사에 잘 적응할 수 있도록 돕는 멤버) 멤버에게 요청했었다. 호스트가 다른 팀 멤버들과 일주일 간 점심 약속을 짜도록 한 것이다. 하지만 이렇게 하자 업무가 많았던 개발팀의 한 호스트 분이 부담감을 표출했다. 생각보다 일일이 점심약속을 잡는 것이 어렵다는 것이다.점심약속을 잡는게 이렇게 힘들 줄이야비즈팀에서도 설득력있는 이유(?)를 들고왔다. 자고로 비즈니스맨이라면, 동료들에게 먼저 연락하고 친해지는 것도 능력이라는 것이라 말했지만 역시나 호스트가 스케줄 짜는 데 부담을 느끼는 듯 했다.피드백을 받으니 내심 서운한 맘이 들었다. 함께 일할 동료를 환영하자는데, 이렇게 협조를 안해주다니!. 하지만 운영팀 동료들의 반응은 달랐다. 아무리 좋은 취지의 제도라도, 누군가에게 강요를 하거나 스트레스를 주면 지속가능한 제도가 될 수 없다(단호박)는 거였다.다시, 더 좋은 방법을 찾기로 했다.Welcome, Lunch Board!신입 멤버를 맘껏 환영해 주면서, 호스트도 부담을 느끼지 않을 수 있는 방법은 없을까? 고민을 거듭하다 모두가 오가며 볼 수 있는 화이트보드를 활용해 웰컴런치보드를 만들어 보기로 했다.날짜만 써놓으면 이렇게 알아서 약속이 잡힐터이니...점심시간을 맞추기 위해 호스트가 일부러 수십 개의 메시지를 보낼 필요 없이, 각자 식사하고 싶은 날짜에 자기 이름을 적으면 끝. 약 2주 동안 하루에 서너 명씩, 원하는 ZOYI 멤버 누구나 참여할 수 있게 했다. 화이트보드에 날짜를 쓰자마자, 관심이 생긴 멤버들이 우르르 다가와 이름을 남기기 시작했다. (어머 이렇게 빨리 흥할 줄이야🤗🤗🤗)화이트보드를 활용하니 이외의 이점도 생겼다. 원래는 이메일이나 채널로 내부에 공유하던 신규 입사자의 자기소개글과 사진을 화이트보드에 붙여놓으니, 자연스레 글도 읽고 얼굴도 보게 되면서 그 옆에 환영메시지도 적고 호기심이 발동한 드립까지 쏟아내기 시작했다.처음 들어와도, 다시 돌아와도 격하게 환영해요 :D호스트의 맘은 덩달아 가벼워졌다. 다른 팀 직원들과 식사할 일이 늘어난 기존 멤버들도 즐거워했다. 다음 웰컴런치에 대한 기대감이 생기면서 신규 입사자에 대한 기대감과 관심까지 올라갔다.웰컴런치는 진화중세번째 웰컴런치가 끝나갈 무렵, 겉으로 보기에는 반응이 나쁘지 않은 것 같은데 실제로도 제도가 잘 운영되고 있는지 궁금해졌다. 그래서 몇몇 팀원들에게 웰컴런치보드 제도에 대한 피드백을 들어보니 신규 멤버의 빠른 적응을 돕는다는 본래의 취지는 잘 지켜지고 있는 것 같았다.다만 직접 겪어보기 전에는 예상하기 어려웠던 문제점도 보였다. 하나는 입사 첫 2주 내내 다른팀 직원들과 밥을 먹다보니 정작 같은팀 직원들과는 초반에 친해질 기회가 적었다는 점. 우린 바로 의견을 반영해 처음 2~3일은 같은 팀원들과 식사하는 '팀런치'를 만들었다.편하게 지내던 기존 멤버들끼리 이야기하느라 신입 멤버를 제대로 챙기지 못했다는 고백도 나왔다. 이 문제에 대해 기존 멤버들과 부드럽게 의논을 해보고 있으며, 새로운 동료와 어떻게 대화를 해 나가야 할지 막막할 경우를 대비해 활용 가능한 대화 주제 세트나 미션(!)도 고민 중이다.나름대로 고민을 해가며 나온 결과물이지만, 여전히 완벽한 제도는 아닐테다. 앞으로도 동료들의 리얼생생후기를 양식 삼아 웰컴런치를 조금씩 더 성장시켜 나갈 예정이다. 솔직한 의견들은 언제나 웰컴!계속해서 발전하는 ZOYI를 꿈꾸며인사파트를 담당하고 있지만, 웰컴런치가 개선되는 과정을 경험하며 ZOYI의 조직문화를 맡으려면 아직 배울 점이 참 많다는 생각이 들었다. 우리가 원하는 건 포퓰리즘이 아니기에 모든 의견을 무조건적으로 반영할 수는 없겠지만, 이번처럼 내부에서 끊임없이 멤버들을 관찰하고 목소리를 들으며 즐겁게 일할 수 있는 ZOYI를 더 단단하게 다져나갈 계획이다.아, 혹시 ‘후드'의 의미가 궁금한 분이 계실까봐 알려드리자면, 닉네임을 정할 때 마침 후드티를 입고 있어서 그렇게 이름을 지었다고 한다^-^ (쿨해서 얼어버릴 뻔^_^;;;)후드처럼 우리의 궁금증을 막 자극하고 싶다면, ZOYI의 모든 사람들과 따뜻한 밥 한 끼 해보고 싶다면, 점심시간에 같이 운동하고 게임하면서 놀고 싶다면, 여러분도 과감하게 ZOYI의 문을 두드려보길!

우리는 비투링커 두번째 주인공 "들" 을 소개합니다! 지난 1월 2일, 두근두근 설레이는 마음으로 비투링크에 입사한 직무체험새싹 비투링커 인턴 4명을  소개합니다 :)중국사람보다 중국음식을 더 좋아한다는 소정님, 피부가 개복치스러워서 아주 순~한 화장품을 좋아한다는 신영님, 해외가서 좋아하는 화장품 사재기를 즐긴다는 주희님,CSR을 잘하는 착한기업의 화장품 브랜드를 좋아한다던 지선님 까지!!!(왼쪽부터) 주희님, 지선님, 소정님, 신영님 :) 여대생느낌 파릇파릇하다 ㅋㅋ1달동안의 짧은 시간이었지만, 비투링커로써 '주도적'으로 각자의 업무에서 '집착' 하며,배운게 정말 많았다는 우리 인턴들 :) 첫 인사를 나누던 때가 엊그제같은데...................각자 느낀 게 많은 새싹 비투링커 인턴들의 이야기를 들려 드립니다 :)이하 4명의 인턴들과 일문일답 입니다!각자 간략한 자기소개 부탁 드립니다!신영님: 안녕하세요, 저는 인하대학교에서 프랑스어와 물류학을 복수전공하고 있는 박신영 입니다!소정님: 저는 경제학을 전공하고, '중국언어문화학' 을 부전공 하고 있습니다 :)제 부전공 이름이 길고 어려운데, 관련 수업을 들으면서 중국과 스타트업에 대해 많이 관심을 가지게 된거 같아요! 이 후, 제가 비투링크에도 관심을 가지게 되었다죠!!지선님: 저는 경영학을 전공하고 있습니다. 평소 해외 직구에 관심이 많았는데, 비투링크 미국진출 관련해서 마켓 리서치를 담당하면서, 시장을 바라보는 시야가 넓어졌습니다.주희님: 저는 소비자학을 전공하고 있습니다! :) 1달이라는 짧은시간동안 비투링크에서 직무체험 인턴을 경험했는데요.한달 전과 현재 달라진게 있다면 어떤게 있을까요?신영: 저는 회사생활이 정말 처음이었어요!  그러다보니, 막연히 '회사' 하면 떠오르는 이미지가 딱딱했어요. 그래서 조금 많이 긴장을 했었죠... 근데 처음 출근했는데, 모든 사람들이 '-님' 호칭을 쓰는데 정말 어색했어요. 원래 대부분 직급으로 호칭을 부르니까요. 얼마전에는 대표님을 소형님이라고 해야하는데, 아무 생각없이 사장님이라고 불렀어요 ㅋㅋㅋ(소형님도 당황, 저도 당황 했습니다)IR관련 리서치를 담당했었는데, 처음에는 문서정리 카테고리를 어떻게 짜야하는지, 실수하면 어떻하지 하면서 별 걱정을 다했어요. 단순히 업무를 하는게 아니라, 스스로 많이 고민했던 거 같아요. 또 제가 한 업무에 대해 최대한 디테일하게 피드백을 주셔서 제가 고민했던 부분에 더해서 그 이상을 배운거 같아요 :)소정: 전 이전에 대기업에서 하는 대외활동에 참여한 경험이 있습니다! 그때 본사직원들과 함께 근무를 했었어요. 그 후로 처음 인턴을 하는건데, 와서 신기했던 건 팀원끼리 정말 사이가 좋다는 거 였어요.저희팀에 어떤 한 분이 몸이 안좋으셔서 병가를 냈는데, 다른 팀원분이 그 분의 업무를 대신 하고, 달력에 아프지말라며 귀여운 그림을 그리고는 사진 찍어서 보내시더라구요! 그걸 보면서 같이 일하는 팀원이기도 하지만, 같은 비전을 가지고 함께 일하는 동료애를 강하게 느꼈습니다. 비투링크의 5개 행동강령 중에 '함께 일하고 싶은 역량을 가진 동료가 된다' 라는 부분이 있는데, 이 부분을 제대로 느꼈습니다 :) 지선: 저는 한달동안 비투링크에서 일하면서, 저만의 기준이 명확히 생긴 거 같아요!  사실 저는 이전에 공기업에서 인턴을 한 경험이 있어요. 이전에는 공기업에 취직해서 편하게 일하고싶다 라는 생각을 많이 했었는데, 막상 인턴을 하다보니 발전이 없는 기분이 들었어요. 그때 당시, 제 가치관에 혼란이 컸었죠.하지만 지난 1달동안 비투링크 내부 직원들이 어떻게 일을 하는지 직접 눈으로 보고 들으면서, 앞으로 내가 무슨일을 하든 배우고 발전할 수 있는 곳으로 가야겠다 라는 생각을 했습니다. 사실 저도 여자지만, 비투링크 내 여성직원분들이 정말 멋지게 일하는 거 같아 동기부여가 되었습니다!(그렇다고 남성 직원분들이 안 멋지다는 게 아니에요!! )주희:  비투링크에 처음 지원했을때, 네이버에 검색부터 해봤어요. 2년 반이라는 짧은 시간동안 많이 성장했고, 창업스토리가 재밌었어요. '스타트업' 이라는 거 자체가 굉장히 흥미롭게 다가왔죠. 하지만 일을 시작하고는 멘붕이 왔어요. '인턴' 이지만, 저에게 담당업무를 주셨고, 이를 주체적으로 진행해야했습니다. 이 과정에서 단순히 업무를 '배운다' 가 아니라, 주체적으로 업무를 진행하는 '담당자'가 되었던 거 같아요! 이래서 직무체험/ 인턴 경험이 중요하다고 하는거구나 를 느꼈습니다 :) 마지막으로 한달은 정말 아쉽네요 ㅠㅠㅠ 짧아요 정말!!  비투링크 전직원들의 꿈이 적혀있는 꿈방인턴 콧바람 쐬기 프로젝트날 :) 콧바람 쐬러 가요~~마지막 질문이에요!비투링크에 '꿈방' 보셨죠? 비투링커라면 피해갈 수 없는 질문!앞으로 어떤 꿈을 가지고 있는지 말씀해주세요 :)신영: 저는 아프리카가 가서 일하고 싶어요! 왜 아프리카냐구요? 특별한 이유는 없어요. 그냥 끌리는?대학교 2학년때, 유럽에서 1년동안 살았던 경험이 있어요. 그때 정말 다양한 인종의 사람들을 만났는데, 그때만났던 아프리카 친구에 대한 기억이 참 좋아요. 자연스럽게 그 나라가 궁금해졌고, 가보고 싶다는 생각이 들더라구요:) 하루는 부모님한테 흑인 사위 어떻냐고 물어본적이 있어요. 아직은 쉽게 받아들여지지 않는 정서적인... 게 있잖아요. 그래도 전 한번 만나보고 싶어요! YOLO 잖아요! :)지선: 저는 앞으로 제 분야에서 영향력있는 사람이 되서 김연아와 친해지고 싶어요!'김연아와 친해진다' 는 게 단순히 김연아랑 친해져서 뭐하게? 라고 할 수 있는데요. 그런 의미라기 보단, 김연아는 '피겨 스케이팅' 이란 분야에서 대표적인 인물이잖아요. 저도 그만큼  제 분야에서 영향력있는 대표적인 인물이 되고싶어요! 주희: 저는 제 화장품 브랜드를 런칭해보는 게 꿈입니다! 막연히 관심을 가졌었는데, 직접 업무를 경험해보니, "와!!! 진짜 하고싶다." 가 되었어요ㅋㅋ 디자인 업무도 하고싶어서 다음달 부터 디자인 툴을 배우려구요. 나중에 제 화장품 브랜드 런칭하면 비투링크와 같이 일하고 싶다는 꿈을 꾸게 되었습니당.소정: 독립해서 외국에서 일을 해보고 싶어요. 한국도 좋지만, 언젠가는 전혀 다른나라에서 일을 해볼거에요. 분명 고생 할거도 잘 알지만, 도전해보고싶은...? 사실 저는 사서 고생하는 거 좋아하거든요!작년엔 국토대장정가서 아킬레스건 끊어지고, 방광염도 걸리고 엄청 고생했었는데, 전 그 과정에서 배운게 많았어요. 안해보면 절대 알 수없는 것들이 있으니까요. (사람들이 저 변태라고....ㅎ)이렇게 사서 고생하면서 제 자신에 대해서도 많이 고민하고 몰랐던 모습을 발견하게 된 거 같아요. 잘 못해도 한번 시작하면 정말 열심히 끝장을 보는 성격이에요. 그러니까 뭘 하든 그 상황에 최선을 다할 제 자신을 누구보다도 잘 아니까, 해외 업무도 제대로 부딛혀보고 싶어요 :)"끝이다!!!!!" (웃고있지만, 아쉽고 아쉽다......)한번 비투링커는 영원한 비투링커 :) 1달동안의 비투링크 인턴경험으로, 앞으로 더 큰 꿈을 꾸는 비투링커가 되길 바라며!항상 응원합니다 ♥#비투링크 #인턴 #인턴소개 #팀원 #팀원소개 #팀원자랑 #회사자랑 #기업문화 #조직문화

지난 8월 26일에는 약 21분간 리디북스 서비스 전체가 중단되는 장애가 있었습니다.사실 서버 스택 일부에만 영향을 주는 장애는 눈에 잘 띄지 않지만 꽤 흔하게 발생하는 일입니다. 기기 1대당 외부적인 요인으로 인한 장애가 평균 2년에 1번 발생한다고 가정하면, 서버가 100대 있을 때는 대략 1주일에 1번꼴로 장애가 발생하는 셈입니다.이런 형태의 장애는 서버 스택의 한 곳에서만 발생하므로, 이중화 혹은 클러스터링을 통해서 극복하곤 합니다. 또한 원인이 명확하므로 해당 기술에 대한 이해도가 높다면 비교적 빠른 시간 내에 복구가 가능합니다.그러나 이번에 리디북스가 경험한 장애는 달랐습니다. 현재 리디북스는 2개의 데이터센터와 클라우드에 인프라가 분산되어 있는데, 이 중에서 1차 데이터센터의 전원 공급에 문제가 생겨 특정 서버 랙에 있는 서버 17대가 동시에 내려간 것입니다. 즉, 소프트웨어나 머신의 물리적인 장애가 아닌, 데이터센터의 장애였습니다. AWS로 비유를 하자면 가용 영역(Availability Zone)의 장애라고 할 수 있겠습니다.원인에 대해이번 장애의 근본적인 원인은 데이터센터가 전원을 정상적으로 공급해주지 못한 것입니다. 물론 데이터센터 혹은 클라우드 서비스(IaaS)는 고객사에게 전원과 네트워크를 안정적으로 제공해주어야 하는 의무가 있습니다.하지만 이들 역시 천재지변이나 사람의 실수에 대한 대비가 100% 완벽할 수는 없습니다. 따라서 이러한 점을 사전에 고려하고 인프라를 설계하지 못한 것이 2차적인 원인입니다.이번 계기를 통해 데이터센터 이중화를 계획하게 되었고, 사용 중인 클라우드 역시 지역(Region) 전체에 장애가 생길 경우에 대한 대비가 되어있지 않아, 이번 계기로 복제 계획(Geo-Replication)을 세우게 되었습니다.구체적인 상황당시 전원이 차단되어 강제 종료된 서버들은 아래와 같습니다.데이터베이스 프록시 x 2메인 리버스 프록시 x 1읽기 분산용 MySQL 슬레이브 x 1서점용 웹 서버 x 3추천 알고리즘 API 서버 x 1알림센터 API 서버 x 2메인 스토리지 서버 x 2출판 플랫폼용 데이터베이스 x 2테스트 및 배치 작업용 서버 x 3그림으로 표현해 보자면, 대략 아래와 같은 상황에서… 아래와 같은 상황이 된 셈입니다.서버 스택의 여러곳에 순간적으로 장애가 발생한 상황공인 IP가 할당된 메인 프록시 서버 중 1대가 내려갔지만, 실제로는 아래와 같이 가상 IP로 구성을 한 상태였기 때문에 대기 중인(stand-by) 프록시가 동작하여 곧 서점에 장애 공지를 띄울 수 있었습니다.[이미지 출처: DigitalOcean™]공지 이후의 움직임우리는 데이터센터의 복구 시점을 명확히 알 수 없어서 신규 구축(provisioning)을 시작함과 동시에, 서버들의 물리적인 위치 이동을 고려하고 있었습니다. 그러나 다행히 10분이 지난 시점에서 전원 문제는 해결되었고, 서버들은 순차적으로 부팅이 완료되었습니다.일부 서버들은 부팅 과정에서 예상치 못한 지연이 발생하기도 하였지만, 모든 서버의 부팅이 완료된 이후에도 서비스는 완전히 정상으로 돌아오지 않았습니다. 당시 우리가 겪었던 문제와 해결책은 아래와 같습니다.A. 읽기 분산용 MariaDB 슬레이브의 복제 지연(replication lag) 문제슬레이브 서버의 부팅이 완료되자 데이터베이스 프록시(HAProxy)는 해당 서버를 정상으로 간주하여 라우팅 대상에 포함하게 되었고, 애플리케이션 서버들은 정상적으로 커넥션을 맺기 시작하였습니다. 하지만 해당 슬레이브는 수십 분간 마스터를 따라잡지 못한 상태였기 때문에 최신 데이터가 보여지지 않는 문제(stale data)가 있었습니다. 우리는 즉시 해당 슬레이브를 제거하였고 지연이 사라진 이후에 다시 서비스에 투입하였습니다.B. 읽기 분산용 슬레이브의 웜업(warm-up) 문제복제 지연은 사라졌지만 서버의 CPU 사용량이 크게 높은 상태가 한동안 유지되었고, 응답속도는 정상적인 슬레이브에 비해서 많이 느렸습니다. 왜냐하면 캐시가 비워진 상태에서 바로 서비스에 투입되어, 캐시 미스가 휘몰아치는 현상(cache stampede)이 발생하였기 때문입니다. 따라서 간단한 쿼리도 평소보다 오래 걸렸고, 그대로 둔다면 커넥션풀이 꽉 차는 현상이 발생할 것으로 예상되었습니다.곧 우리는 HAProxy로 해당 서버의 가중치를 10%로 낮추어 인입되는 쿼리의 양을 조절하였으며 응답속도는 정상 수치로 돌아오게 되었습니다. 이후 스크립트를 작성하여 수동으로 캐시를 채워나감과 동시에 점차 가중치를 높여 처리량을 정상화하였습니다.프로덕션에서 사용하는 서버는 innodb_buffer_pool 이 100G 이상으로 매우 크게 설정되어 있으며, 재시작 시 캐시가 날아가는 현상을 해결하기 위해 innodb_blocking_buffer_pool_restore 옵션을 적용하고 있습니다. 하지만 지금처럼 메모리를 덤프하지 못하고 비정상 종료가 된 상황에서는 해당되지 않았습니다.C. 인메모리 데이터의 보존 문제알림센터는 다양한 프로모션과 개인화된 정보를 전달해주는 공간입니다. 알림센터의 특징은 데이터의 영구 보존(persistency)이 필요하지 않고, 매일 수백만 건의 개인화된 메시지가 기록된다는 것입니다. 이러한 특징은 인-메모리 데이터베이스에 적합하므로 우리는 Redis를 마스터/슬레이브로 구성하여 저장소로 사용하고 있었습니다.어떠한 이유로든 Redis를 재시작해야 할 경우가 생기면, 메모리 상의 데이터가 날아가는 것을 방지하기 위해 주기적으로 스냅샷을 남기고 있습니다만, 이번에는 로그가 마지막까지 기록되지 못한 상태에서 메모리의 데이터가 날아가 버렸습니다.다행히 알림 발송과 관련된 메타정보는 모두 MariaDB에 기록하고 있으므로, 우리는 이를 기반으로 소실된 시점부터의 알림을 순차적으로 재발송할 수 있었습니다. 물론 모든 알림이 신규 상태로 간주되어 아이콘이 잘못 노출되는 문제가 있었지만, 고객님들은 너그럽게 이해해 주신 것 같습니다. 😅그래서 앞으로는?리디북스 DevOps 멤버들은 이번 데이터센터 장애를 통해 현재 인프라의 한계점을 실감하였고, 앞으로의 개선 방향에 대해 고민하게 되었습니다.몇 가지를 정리하면 다음과 같습니다.랙 단위로 장애가 발생할 수 있음을 인지하고 대비하자.같은 기능을 하는 서버를 하나의 랙이나 같은 가용 영역에 두지 말자.2차 데이터센터는 더 이상 옵션이 아닌 필수다.낙뢰나 지진으로 인해 데이터센터에 문제가 생길 수도 있다.긴급하게 프로비저닝이 필요한 상황에 대비하자.문서화가 되어 있더라도 경험이 없다면 동일한 구성에 많은 시간이 소요된다.모든 구성요소들에 대한 Ansible 스크립트를 작성하여두자.캐시 웜업 스크립트도 작성하여 두자.백엔드 구성요소들 간의 불필요한 의존 관계를 끊자.단 한 줄의 코드라도 참조하고 있다면 이는 독립적인 것이 아니다.언제나 서비스 지향적인 설계를 추구하자.Uptime을 관리하자.최대 180일을 기점으로 무조건 리부팅을 하자.재시작 과정에서 다양한 문제와 개선점이 발견될 것이다.커널 패치, 보안 패치를 할 수 있는 것은 덤이다.아래와 같은 긍정적인 면도 발견하였습니다.장애 상황이 실시간으로 Slack 채널을 통해 전파되었음진행 상황에 대해 모두가 동일한 수준으로 이해할 수 있었다.모니터링 연동(integration) 기능 때문에라도, Slack은 유료로 구매할만한 값어치가 충분하다.같은 기능을 하는 서버들이 다른 랙에 많이 분산되어 있었다.인프라가 확장될 때마다 빈 공간에 필요한 서버를 추가했을 뿐이지만, 자연스럽게 물리적인 위치가 분산되는 효과가 있었다.이 외에도 특정 클러스터를 구성하는 노드들을 분산하여 배치시키자.서버별로 오너쉽이 부여되어 있어서 빠르게 복구가 된 점여러 명의 백엔드 개발자들이 병렬적으로 복구를 진행할 수 있었다.마지막으로넷플릭스의 엔지니어들은 무질서한 원숭이(Chaos Monkey)라는 프로그램을 만들어서 운영한다고 합니다. 이 원숭이는 서비스 인스턴스들을 무작위로 중단시키는 역할을 합니다. 다소 황당하게 들리지만, 넷플릭스에는 일부 서비스에 장애가 발생하더라도 나머지 부분은 문제없이 운영되어야 한다는 원칙이 있으므로, 이를 수시로 시뮬레이션하는 과정을 통해 복구 능력을 높여둔다는 것입니다.실제로 이렇게 급진적인 아이디어를 실천할 수 있는 회사는 매우 드물 것입니다. 하지만, 우리는 이번 계기를 통해 무질서한 원숭이의 필요성을 절감하였고, 이로 인해 서버를 주기적으로 리셋하는 정책을 만들게 되었으며 모든 단일 장애점(SPoF)에 대한 대비를 시작하게 되었습니다.장애를 단순히 피해라고만 생각한다면, 서로를 비난하고 책임을 전가하는 상황이 펼쳐질 것입니다. 하지만 고객의 불편함과 맞바꾼 매우 비싼 경험이라고 생각한다면, 보다 튼튼하고 회복탄력적인 시스템을 갖추기 위해 노력하게 될 것입니다. 그러다 보면 언젠가는 데이터센터 전체에 문제가 생겨도 버틸 수 있는 모습으로 진화할 것이라고 생각합니다.#리디북스 #장애복구 #역경돌파 #개발 #개발후기 #개발자 #서버개발 #서버

지난 9월 2일 화요일, 하반기 롯데 신입사원 공채 모집이 문을 열었습니다. 롯데에 입사하고 싶은 취업 준비생은 9월 16일까지 서류전형에 지원할 수 있습니다.이 소식을 보고 많은 취업 준비생들이 반가워했을 텐데요. 분명 이번 롯데 하반기 채용에 대한 궁금증도 많고, 또 어떻게 준비해야 할지 막막하실 거예요. 그래서 롯데가 취업 준비생인 여러분들의 고민을 시원하게 해결해 줄 ‘롯데 잡 카페’를 오픈했습니다. 그 자세한 정보를 지금부터 L군이 소개해 드리겠습니다. 롯데 잡 카페, 알찬 취업 정보가 쏙쏙!롯데에서는 오는 9월 12일 금요일 하루 동안, 롯데 입사에 관심 있는 취업 준비생을 상대로 잡 카페를 운영합니다. 이날은 서울과 광주, 부산 내의 대학 밀집 지역에 있는 크리스피크림도넛 매장에서 취업 진로에 대한 컨설팅이 준비되는데요. 서울은 신촌점과 청량리점에서, 광주는 광주상무점에서, 그리고 부산은 서면점에서 멘토링의 기회를 잡을 수 있습니다.롯데 잡 카페에는 오전(10시~13시)과 오후(14시~18시)로 분할 운영되며 서울 청량리점의 경우, 오전 10시 30분부터 시작합니다. 사전 신청은 받지 않고 해당 점포에 방문하면 선착순으로 상담받을 수 있습니다. 상담 인원이 많을 경우, 대기 시간이 길어질 수 있다는 점을 꼭 참고해주세요.한편, 잡 카페에 방문하면 롯데 채용에 대한 자세한 설명과 상담을 받을 수 있는데요. 오전과 오후, 운영 시간에 따라 상담해주는 롯데 계열사가 다르니, 운영 스케줄표를 반드시 확인하시길 바랍니다. 방문하시는 분들께는 도넛과 커피, 그리고 채용 브로슈어가 제공됩니다.세계 속에 우뚝 선 롯데의 꿈에 동참할, 취업 준비생 여러분들의 많은 참여 바랍니다.#Featured #lotte #Lotte Group #롯데 #롯데 신입사원 #롯데 잡 카페 #롯데 채용 #롯데건설 #롯데그룹 #롯데마트 #롯데면세점 #롯데백화점 #롯데시네마 #롯데연구소 #롯데월드 #롯데제과 #롯데주류 #롯데카드 #롯데캐피탈 #롯데케미칼 #롯데푸드 #롯데하이마트 #롯데호텔 #롯데홈쇼핑 #세븐일레븐 #진로 #취업 #칠성

 이게 웬 보기만해도 맛깔나는 사진이냐고요?바로바로 크몽팀의 점심 식탁이랍니다.사내에 조리기구가 따로 있어서 주기적으로 일주일에 2-3번은 함께 지지고 볶아(?) 한 테이블에 모여 점심을 먹는 크몽팀!주로 조리 담당은 크몽의 계란말이 전문가 다니엘 님(2X세, 개발자)과 손맛의 일인자 마리 님(2X세, 디자이너)이고요,테이블 셋팅과 설거지 등등 다른 팀원들도 역할을 나눠 즐거운 점심 시간을 가진답니다. 그런 의미에서(!) 오늘은 2014년 10월 현재 크몽팀이 서식하고 있는 환경을 조금 더 자세히 들여다 볼까 해요. :)드루와~ 드루와~    후다다닥 열심히 일하다 보면 자주 갈증이 나기 마련! 크몽팀이 컴퓨터 다음으로 자주 마주보고 있는(?) 냉장고를 열면,팀원들의 기호에 맞춘 닥터페퍼와 콜라, 핫식스, 탄산수가 마련되어 있습니다. 보기만 해도 시원~하네요ㅎㅎ 점심, 그리고 야근을 대비해 사내에서도 간단하게 식사를 할 수 있도록 구비되어 있는 메뉴들 사진도 보이네요.여사원들의 다이어트를 위한 닭가슴살, 흑미와 발아현미 햇반, 각종 라면에 과자까지..사진에는 보이지 않지만 기본 밑반찬인 김치에 만두, 샐러드 심지어 견과류도 차곡차곡 쌓아두고 있답니다.(이쯤되면 너... 사무실이 맞는가...?)     회의 중에, 업무 중에, 브레인 스토밍과 내용 정리를 좀 더 효율적으로 하기 위해크몽 사무실 내 대부분의 벽은 화이트 보드화 되어 있답니다. 사진을 보시면 크몽팀의 생각이나 가치관, 해야 할 일, 진행 중인 일 등등 다양한 내용들이 적혀 있네요.(아직 정식으로 공개 되지 않은 내용들은 일부 블러 처리를 좀 했습니다ㅎㅎ)반드시 기억해야 할 일정이나 다른 팀멤버들에게 짤막하게 남기는 메세지들, 귀여운 그림들이 남겨지는 경우도 있어요.그래서 팀원들은 아침에 출근을 하면 꼭 한 번씩 벽에 적힌 내용들을 쭈욱 스캔하곤 합니다.    지금까지 짤막하게나마 크몽팀이 하루 중 가장 긴 시간을 보내고 있는 곳에 대해 소개해 드렸습니다! 크몽팀은 진중하지만 즐겁고 편안한 환경에서 일을 해야긍정적인 가치관을 가진 아이디어들을 만들어 낼 수 있고,그 아이디어들이 더 좋은 서비스와 더 나은 재능 거래 문화 형성을 가능하게 한다는 점을 믿고 느끼며 일하고 있답니다. #크몽 #팀문화 #기업문화 #조직문화 #사내복지

“세상 모든 광고영상을 누구나 쉽게 만들 수 있게 한다.”영상광고는 사업의 규모와 업종을 막론하고 모든 분야에서 필수적인 요소로 자리잡고 있습니다. 잘 만든 영상광고가 매출로 이어진다는 사실은 검증되었고, 그 중요성은 나날이 증가하고 있습니다.하지만, 영상제작 전문기술 없이 광고영상을 제작한다는 것은 시간과 비용적인 측면에서 매우 어려운 일입니다. 광고영상을 SNS에 업로드 하고 싶은 마케터나 창업가들은 영상 전문가나 디자이너가 되는 것을 꿈꾸지 않습니다. 단지 자신의 서비스와 제품이 멋지게 홍보될 영상을 원하고 있습니다.더브이플래닛은 전문기술 없이도 누구나 쉽고 빠르게 광고영상을 제작할 수 있는 브이플레이트를 통해 많은 마케터들과 창업가들이 겪는 시간과 비용에 대한 어려움을 해소할 것입니다.“더브이플래닛”에서 영상광고 생태계의 흐름을 바꿀 iOS개발자를 모집합니다.광고영상을 누구나 쉽게 만들 수 있도록 함께 고민하고 시장을 주도해나갈 분을 애타게 찾고 있어요.우리는 한사람 한사람의 소중한 능력들이 맘껏 발휘될 수 있도록 존중과 배려로 서로를 응원하고 있어요. 우리와 함께 소중한 능력을 맘껏 발휘하실 분들의 많은 지원 부탁드려요.

OverviewAWS Rekognition은 딥 러닝 기반의 이미지, 동영상 분석 서비스입니다. Rekognition API를 사용하면 서비스에서 객체, 사람, 텍스트, 장면 및 동작을 식별하고 부적절한 콘텐츠를 탐지할 수 있습니다. Rekognition은 딥 러닝 기술을 기반으로 하고 있기 때문에 지금 이 순간에도 새로운 데이터를 통해 끊임없이 학습하고 있고, AWS에서도 새로운 레이블과 얼굴 인식 기능을 추가하고 관리합니다. 이번에는 AWS S3 Bucket에 업로드한 이미지로 이미지 분석 결과를 볼 수 있는 예제 사이트를 통해, Rekognition과 친해지는 시간을 갖도록 하겠습니다. 저는 예제 사이트를 개발하기 위해 PHP 프레임워크인 CodeIgniter 3, MAMP, Bootstrap을 사용했습니다.1. AWS Rekognition SDK 설치하기1-1) AWS Rekognition 사이트에 접속해 Download SDKs 를 클릭합니다.1-2) AWS 에서 제공하는 다양한 언어의 SDK를 확인할 수 있습니다. 저는 PHP를 사용할 것이므로 PHP 의 Install을 클릭하겠습니다.1-3) AWS SDK 를 설치할 수 있는 방법은 여러가지가 있습니다. 이 중에서 저는 Composer를 이용해 설치했습니다.curl -sS https://getcomposer.org/installer | php php -d memory_limit=-1 composer.phar require aws/aws-sdk-php 1-4) 짠! 짧은 명령어 2줄로 SDK 설치가 완료되었습니다 :)2. AWS S3 Bucket 에 업로드된 이미지를 분석하기2-1) 여기에 임의로 만든 예제 사이트가 있습니다. [이미지 선택] 과 [S3에 이미지 업로드하기] 를 통해 이미지 파일을 등록하면, 백단(Back-end) 에서는 해당 파일을 특정 S3 Bucket 에 업로드 한 후 Rekognition 에게 이미지 분석을 요청하도록 짜여있습니다. 관련 코드는 아래와 같습니다.{     "Image": {         "S3Object": {             "Bucket": "bucket",             "Name": "input.jpg"         }     },     "MaxLabels": 10,     "MinConfidence": 80 } 위의 코드 블록은 AWS Rekognition 개발자 안내서에 나와있는 예제 포맷이고, 아래의 코드는 예제 포맷을 PHP 에서 요청할 수 있는 방식으로 코딩한 것입니다.detectLabels 메소드 를 이용해 분석할 이미지가 저장되어 있는 S3 Bucket 과 이미지의 Name 을 전달해줍니다. 1) MaxLabels : 응답 받을 최대 Label 수 2) MinConfidence : Label 에 대한 최소 신뢰성 여기서 Label 이란 ‘이미지에서 발견되는 객체, 장면 또는 개념’ 이라고 생각하면 됩니다. 예를 들어 해변에 있는 사람들을 촬영한 사진에는 ‘사람’, ‘물’, ‘모래’ (객체) 및 ‘해변’ (장면) 그리고 ‘야외’ (개념) 등이 Label 이 될 수 있습니다. 자, 우주 사진을 한 번 분석해볼까요? array(3) {     ["Labels"]=>     array(8) {       [0]=>       array(2) {         ["Name"]=>         string(9) "Astronomy"         ["Confidence"]=>         float(96.8987350464)       }       [1]=>       array(2) {         ["Name"]=>         string(5) "Earth"         ["Confidence"]=>         float(96.8987350464)       }       [2]=>       array(2) {         ["Name"]=>         string(5) "Globe"         ["Confidence"]=>         float(96.8987350464)       }       [3]=>       array(2) {         ["Name"]=>         string(11) "Outer Space"         ["Confidence"]=>         float(96.8987350464)       } ...     } Rekognition이 업로드한 우주 사진을 분석하여 정확히 연관된 Label들만 반환한 것을 확인할 수 있습니다. 이 Label을 가지고 이미지 태그를 간단하게 구현했습니다.참 쉽죠 ?Conclusion이번 시간에는 AWS Rekognition 을 이용하여 기본적인 이미지 분석을 해보는 시간을 가져봤습니다. 다음 시간에는 ‘얼굴 감지 및 분석’ 기능을 응용하여 Collection 을 생성해보고, 얼굴 검색을 해보는 시간을 갖겠습니다. 참고놀라운 무료 이미지 · Pixabay핀터레스트 스타일 레이아웃 만들기 (masonry) - 생활코딩이미지에서 레이블 감지 - Amazon Rekognition글김우경 대리 | R&D 개발1팀[email protected]#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유

2018년에는 VCNC에 큰 변화가 있었습니다. 오랫동안 비트윈 기반의 서비스들을 개발하고 운영했지만 2018년 10월에 기사 포함 렌터카 서비스를 포함한 종합 모빌리티 플랫폼인 타다를 기획하고 출시하였습니다. 변화가 많은 모빌리티 시장에서 신규 서비스를 성공적으로 출시하기 위해 많은 고민을 하였습니다. 이번 글에서는 타다의 시스템 구성과 이를 위해 사용한 여러 기술을 소개하면서, 타다 개발팀의 기술적 결정을 공유해보고자 합니다.타다에서 사용하는 기술들의 로고. 왼쪽부터 Kotlin, Spring Boot, Kubernetes, Terraform, gRPC, Redis.기존과 다른 선택비트윈의 경우 Netty를 이용해 인하우스 네트워크 라이브러리를 만들기도 하였고, 메인 데이터베이스로 NoSQL인 HBase를 사용하는 등 남들이 통상적으로 사용하지 않는 기술 스택을 선택한 경우가 많았습니다. 그 배경에는 나름대로 이유가 있었지만, 서비스 초기에는 안정성에 어려움을 겪기도 하였고 서버 배포 과정이 느리고 복잡하여 쉬운 길은 아니었습니다. 여러 문제를 해결하기 위해 Haeinsa 등 라이브러리와 소프트웨어를 직접 만들기도 하였습니다.타다는 이슈가 많은 모빌리티 시장을 타겟으로 하고 있기 때문에 Time to Market이 특히 중요했습니다. 개발하는 기간 동안 시장 상황에 따라 기능의 우선순위가 변하기도 하였습니다. 이에 따라 서비스를 빨리 출시하고 외부의 변화에 유연하게 대처할 수 있도록, 완성도 있게 만들어져 있는 프레임워크나 라이브러리를 선택하였고, AWS에서 이미 잘 관리되고 있는 서비스를 적극적으로 활용하였습니다.사용 중인 기술들Kotlin: Java는 불편한 점이 많지만, JVM에 대한 경험을 무시할 수는 없어 비교적 새로운 JVM 기반 언어인 Kotlin을 사용하기로 하였습니다. 다른 여러 JVM 기반의 대안 언어들이 있지만, Spring Boot에 쉽게 적용할 수 있고 커뮤니티에서 적극적으로 권장하고 있는 점 등 여러 이유로 Kotlin을 선택하게 되었습니다.Spring Boot: 널리 쓰는 웹 프레임워크이며 이미 지원하는 기능 또한 많기 때문에 보일러 플레이트 코드 작성을 줄이고 서비스 개발에 집중할 수 있습니다. SQS 메시지 처리, HTTP 요청 및 응답으로 Protocol Buffers 메시지 사용 등 프레임워크에서 제공하는 기능을 많이 활용하고 있습니다.Kubernetes: 컨테이너 오케스트레이션 플랫폼으로 배포 자동화와 스케일링 등 여러 가지 운영적인 편의성을 제공합니다. 처음에는 kops를 이용해 클러스터를 직접 띄웠지만, 지금은 EKS를 이용하고 있으며 직접 object를 만들기보다 helm을 이용하고 있습니다.gRPC: 실시간성이 중요한 차량 위치나 운행 상태 변화 등은 Streaming을 이용하여 전달하고 있습니다. 직접 개발할 수도 있었지만, 서비스 개발에 집중하고 앞으로의 관리 오버헤드를 줄이기 위해 gRPC를 이용하기로 하였습니다.Redis: 서버 간 메시징을 위해 Redis의 Pub/Sub 기능을 사용하고 있습니다. 메시지 브로커 기능을 제공하는 RabbitMQ, ActiveMQ, Kafka 등 여러 옵션이 있었지만, 개발을 시작하던 당시에는 Redis만이 ElastiCache를 이용하여 쉽게 띄우고 관리할 수 있어 Redis를 선택하게 되었습니다.Protocol Buffers: gRPC 뿐만 아니라 HTTP/2로 주고받는 메시지를 정의할 때도 이용하고 있습니다. 덕분에 따로 문서화 하지 않고 proto파일을 공유하여 더욱 명확하고 편리하게 API 명세를 공유할 수 있었습니다.Terraform: HCL을 이용해 인프라스트럭처 프로비저닝 및 관리를 편하게 해주는 도구입니다. AWS 서비스의 생성 및 관리를 콘솔에서 직접 하지 않고 Terraform을 이용하고 있습니다.사용 중인 AWS 서비스들AWS는 개발팀이 오랜 기간 사용하여 가장 익숙한 클라우드 플랫폼이기 때문에 큰 고민 없이 선택할 수 있었습니다.EKS: Kubernetes 클러스터의 마스터 노드들을 쉽게 띄우고 관리해주는 서비스입니다. 서울 리전에 EKS가 출시된 후에는 관리 오버헤드를 줄이기 위해 EKS로 옮겼습니다.ECR: 타다 서버를 배포할 때는 Docker Gradle Plugin을 통해 docker 이미지를 만들고 ECR에 푸시합니다. 그 후 helm 명령을 통해 Kubernetes에 배포합니다.SQS: 배차 요청을 처리하기 위해 SQS를 이용합니다. 배차 요청을 구현하는 방법에는 다양한 옵션이 있었지만 AWS 서비스를 최대한 활용하여 빠르게 개발할 수 있었습니다.RDS: 타다의 대부분 데이터는 Aurora에 저장하고 있습니다. RDS를 이용하면 DB의 배포와 관리가 쉬우며, Aurora는 MySQL과 호환될 뿐만 아니라 같은 비용이면 성능이 더 좋습니다.Kinesis: 실시간 차량 위치 정보 및 로그를 수집하기 위해 사용하고 있습니다. 다른 오픈소스 소프트웨어를 직접 이용하기보다는 AWS에서 제공하는 서비스를 최대한 이용하고 있습니다.Firehose: 비트윈에서는 KCL를 활용해 Acheron이라는 프로그램을 직접 만들어 로그들을 S3에 저장하였지만, 이제는 서울 리전에서 Firehose를 사용할 수 있으므로 큰 고민 없이 사용하기로 하였습니다.시스템 구성타다에서는 필요에 따라 서비스를 여러 종류로 분리하여 운영하고 있습니다. 일반적인 모바일 앱 API와 실시간 차량의 위치 정보를 바탕으로 사용자의 요청에 대해 적합한 차량을 배차하는 기능이 필요했습니다. 핵심적인 역할을 하는 일부 서비스와 시스템 구성에 대해 간단하게 소개합니다.라이더 앱: 아이폰은 Swift, 안드로이드는 Kotlin으로 작성하였으며 여러 오픈소스 라이브러리를 적극적으로 활용하였습니다. 서비스 특성상 RIBs라는 아키텍처를 사용하여 개발하였습니다.드라이버 앱: 아이폰과 안드로이드를 모두 지원하려면 기술적, UX적으로 고려해야 할 점들이 많고 불특정 다수의 유저를 대상으로 하는 앱도 아니었기 때문에 안드로이드 버전으로만 개발하게 되었습니다.서버: 모바일 앱의 요청을 대부분 처리하며 Spring Boot로 작성된 HTTP/2 API 서버입니다. Protocol Buffers로 정의된 메시지를 JSON 형태로 주고받습니다.gRPC 서버: 서버에서 발생하는 이벤트를 실시간으로 전달하기 위한 서버입니다. Redis Pub/Sub을 통해 받은 이벤트 메시지들을 클라이언트들에게 전달합니다.Dispatcher: 배차 요청을 처리하는 서버입니다. 주변 차들의 ETA 계산을 위해 외부 API를 이용하는데, Reactor를 이용해 비동기적, 동시적으로 요청하여 쓰레드 점유 없이 효율적으로 처리되도록 구현하였습니다.Tracker: 차량 위치 정보 수집 서버입니다. KCL를 이용해 위치 정보 레코드를 읽어 들여 TrackerDB에 기록합니다.Redis: 서비스 초기에는 차량의 최신 위치 등을 저장하기도 했지만, 지금은 주로 서버 간 메시징을 위해 Pub/Sub 기능을 이용하고 있습니다.DB: 운행 기록, 사용자 데이터 등 대부분 데이터를 기록합니다. 비트윈에서는 HBase를 이용했지만 타다의 경우 아직 절대적인 트래픽이 많지 않기 때문에 트랜잭션 등 다양한 편의 기능을 제공하는 RDB를 이용하고 있습니다.TrackerDB: 차량 운행 정보 및 차량의 최신 위치 등을 저장합니다. Aurora를 이용하며 대부분의 요청이 차량 위치 정보 업데이트이므로 안정성을 위해 별도의 인스턴스를 띄워 사용하고 있습니다.Kinesis Log Stream: 타다의 여러 서비스에서 로깅을 위해 이용합니다. Firehose를 통해 S3에 기록됩니다.Kinesis Tracker Stream: 드라이버의 실시간 위치 정보는 Kinesis를 통해 Tracker로 전달됩니다.서비스 플로우차량 위치 업데이트차량 위치 업데이트는 요금 계산, 차량 위치 제공 등 서비스에서 가장 많이 일어나는 요청입니다. 드라이버 앱에서 안드로이드 Foreground 서비스를 이용해 GPS 정보를 수집하고 일정 주기마다 서버로 현재 위치를 전송합니다. 이렇게 전송받은 GPS 위치 정보는 데이터 크기를 최소화하기 위해 Protocol Buffers로 직렬화되어 Kinesis 레코드로 만들어지게 됩니다. Tracker에서는 전달된 Kinesis 레코드를 읽어 간단한 처리를 한 후에 TrackerDB에 삽입합니다.서비스 초기에는 차량의 마지막 위치에 대한 정보만 Redis에 적었습니다. 그러나 차량의 이동 경로를 효율적으로 조회해야 할 일이 생겼는데, 당시 차량 이동 경로는 로그로만 저장되고 있었습니다. S3 Select나 Athena를 이용해 조회하는 방안도 고려했지만, 일단은 Aurora에 저장하기로 하였습니다. 당분간은 Aurora로도 충분했고 RDB를 쓰는 것이 가장 쉽고 편한 방법이었기 때문입니다.차량 배차차량 배차는 서비스의 가장 기본적인 기능으로 배차 요청에 가장 적절한 주변 차량을 할당하는 플로우입니다. 라이더 앱에서 유저가 배차를 요청하면 서버가 배차 요청 정보를 DB에 기록하고 배차 요청 메시지를 SQS 대기열에 집어넣습니다. Dispatcher가 배차를 처리하는 로직을 수행하여 차량이 매칭되면 드라이버 앱으로 이벤트가 전달됩니다.드라이버가 배차를 수락하면 서버로 수락 요청이 전송되고 서버에서는 DB의 배차 요청 상태를 수락 상태로 변경합니다. 배차 요청이 수락되었다는 이벤트는 결과적으로 gRPC 서버를 통해 해당 이벤트를 구독하고 있던 유저에게 전달됩니다.Dispatcher에서 배차를 처리하는 로직은 여러 옵션이 있었지만 가장 간단하고 효율적으로 개발하기 위해 SQS의 기능을 최대한 활용하였습니다. Dispatcher 수를 늘리는 것만으로도 처리량 확장이 가능하며 Dispatcher가 갑자기 종료되어도 한 대라도 살아있다면 결국에는 잘 처리가 됩니다. Dispatcher가 배차 요청을 받으면 다음과 같은 로직을 수행합니다. 종료 조건을 만족하지 않았다면 일정 시간 후 동일한 로직을 다시 반복합니다.배차가 가능한 상태라면 배차 로직을 수행합니다. 이동 경로와 교통정보를 고려하여 적합한 주변 차량을 찾습니다.만약 적합한 차량이 있다면 배차 요청을 해당 드라이버에게 할당되었다는 정보를 DB에 적고 배차 할당 이벤트를 전파합니다. 드라이버의 수락을 기다리기 위해 일정 시간 후 로직을 재시도합니다.만약 적합한 차량이 없다면 일정 시간 후에 로직을 재시도합니다.배차 요청이 드라이버의 수락을 기다려야 하거나 타임아웃이 남아있는 상태라면 적절한 시간 후 재시도합니다.배차 요청이 수락되어 완료된 상태거나 취소되었거나 타임아웃이 지난 상태라면 SQS에서 메시지를 삭제합니다.못다 한 이야기타다를 런칭하는 날, 기사 간담회에서 쏘카의 VCNC 인수 이후 짧은 기간 동안 타다를 만들 수 있었을 리 없으니, 실제 개발 기간은 어느 정도냐는 질문이 있었습니다. 짧은 기간 내 서비스를 성공적으로 런칭할 수 있었던 것은 상황에 맞는 올바른 기술적 선택들뿐만 아니라 훌륭한 팀원들이 있었기에 가능했던 일이었습니다. 타다는 개선해야 할 부분도 많고 앞으로 새로운 기술적 도전들이 많이 있을 것입니다.네 그렇습니다. 결론은 기술적 난제들을 고민하면서 좋은 팀과 서비스를 함께 만들고 키워나갈 좋은 분들을 기다리고 있다는 것입니다.