디자인과 예술의 차이를 물으면대부분 클라이언트가 있느냐 없느냐의 차이라고답하는 경우가 많다.내 작품인가? 고객의 작품인가?틀린 말은 아니지만,이 말에 순응하는 순간, 디자이너의 생각은수동적인 모드로 전환되기 시작한다.디자인이라는 업태가 고객의 요구를 기반으로디자인 역량과 해결책을 제공하여 수익을 얻는 구조라는 것을 인정하더라도 이 프레임에 빠져서는 안된다.여러차례 얘기하지만디자이너의 핵심 역량은 그림을 잘 그리거나멋지게 표현하는 것이 아니다.남들이 미처 보지 못하는 것을 발견하고,눈에 보이지 않는 것을 상상하고,자신의 생각을 남들이 이해할 수 있게  표현하는 능력이다.  남들이 보지 못하는 것을 표현하는 능력많은 디자이너들이 이런 유형의 클라이언트를접해봤을 것이다."요즘 그런 스타일이 괜찮던데...""그 브랜드처럼 해주세요""요런 느낌 좀 살려주면 좋겠는데요"눈에 보이는 것만 볼 수 있는 사람들은눈으로 본 것만을 믿는다.그리고 봤던 것 중에 선택할 수 밖에 없다.그 이상을 상상하거나, 받아들이지도 않는다.자신이 볼 수 있는 해상도로만 사고한다.그래서 좋은 creativity를 가진 디자이너도창의성을 수용할 클라이언트를 만나지 못한다면고객의 눈높이로 평준화될 수밖에 없다.때로는 고객의 사고를 확장시켜야 하고경험 너머의 risk를 감내할 수 있도록 설득해야 한다.디자이너가 yes man이 되는 순간 그들과 같이 망하게 되는 것이다.무조건 부정하라는 의미가 아니다.기획력이 필요하다는 것이다.기획력이 필요하다아무도 해보지 않은 것을 시도한다는 것은,누구도 경험하지 않았던 리스크를 감내시키는 것은고도의 전략이 필요하다.보지 못한 것을 볼 수 있게 해줘야 한다.상상하지 못한 것을 한걸음씩 상상할 수 있게 해줘야 한다.기획력이라는 것은논리적이어야 한다는 의미만은 아니다.치밀한 데이터로 설득하는 보고서를 쓰라는 의미도 아니다.상상력은 데이터로 입증할 수도 없다.다만, 클라이언트가 사고의 영역을 확장할 수 있게유도하는 과정을 기획하라는 것이다.많은 인터랙션과 교감과 교류가 있어야 한다.때론 논쟁하고 인정하고 생각의 빈틈을 파고들어야 한다.자주 이야기하고 확신을 줘야 한다.사례를 들고, 시뮬레이션하고, 구체적이어야 한다.상상력을 작동할 수 있게 긴장과 집착을 풀도록 해야한다.시간이 필요하고 신뢰가 필요하다.관계가 만들어져야하고 호감을 생성되어야 한다.그래서 어려운 것이다.그래서 순응하게 되는 것이다.디터람스가 브라운에서 그랬던 것처럼,나오토 후카사와가 무인양품에서 했던 것처럼,조나단 아이브가 애플에서 그랬던 것처럼,시키는 것을 잘하는 것이 아니라,주도하는 것이어야 한다.거들기만 할 뿐이 아니라,앞장서야 한다.기회를 기다리는 것이 아니라,주인이 되어야 한다.다행스러운 것은점점 그런 세상이 다가오고 있다는 것이 느껴지고,그런 능력을 요구하는 목소리가 커지고 있다는 것을체감하고 있다는 것이다.상대방을 움직이는 역량,클라이언트를 성장시키는 능력이 필요하다.언제까지나고집세고 개성강한 독불장군 디자이너로는세상을 바꿀 수 없다.사람을 움직이는 능력아티스트가 아니라디자이너이기 때문이다.

대략적인 방향이 설정되고 나자 리더의 역할에는 구체적으로 어떤 것들이 있고 그것들을 어떻게 나눌지에 대한 고민을 시작했다. 역할 중심 문화를 원래의 의도에 맞게 운영하기 위해서는 그냥 나누는 게 아니라 의미 있는 단위로 ‘잘’ 나누는 것이 중요했다. 잘 나눈 역할을 적합한 사람에게 부여하고 이를 구성원들에게 이해시키는 작업도 함께 진행됐다.어떻게 나눌까고민의 단위로 역할 쪼개기"팀장의 역할을 어떻게 쪼갤 수 있을까?"대부분의 회사들은 팀이 커지면 리더의 역할을 나누기보다 팀을 관리 가능한 단위로 쪼갠다. 프로젝트별로 팀을 쪼개거나(프로젝트 A 개발팀, 프로젝트 B 개발팀 등) 기능별로 쪼갠 후(클라이언트개발팀, 서버개발팀, 인프라개발팀 등) 각 팀에 팀장을 둔다. 하지만 이렇게 프로젝트 또는 기능별로 팀을 쪼갤  경우 팀의 단위가 작아질 뿐 팀장에게 권한과 책임이 몰리는 문제를 해결하기는 어렵다. 또한 소단위로 팀을 쪼개버리면 거시적인 노하우 공유가 어렵고 각자가 수행하는 ‘기능’에만 집중할 가능성이 높다. 에이스프로젝트는 역할을 효과적으로 나누기 위해 먼저 기존의 리더들이 본질적으로 어떤 부분들을 고민하며 리딩하고 있었는지 구체화했다. 대략적으로 팀장은 스케줄을 효율적으로 관리하거나 팀원들을 코칭하거나 팀에서 만들어내는 아웃풋의 퀄리티를 향상하는 일을 해왔다. 개별적인 역할을 잘 수행하기 위해 혹은 각 역할들이 가진 가치 충돌을 조율하기 위해 고민한다. 어떻게 하면 야근을 줄이고 적절한 스케줄 관리를 할 수 있을까. 마감기한이 얼마 안 남았으니 퀄리티를 약간 포기해야 할까 혹은 출시가 늦어지더라도 퀄리티업을 해야 할까. 팀원의 퍼포먼스가 저조할 때 강하게 업무지시를 해야 할까 아니면 면담을 통해 감정적인 동기부여를 해야 할까. 이런 고민의 단위로 큰 덩어리의 역할을 나누고 한 사람이 한 가지 역할을 더 본격적으로 수행할 수 있는 구조를 구성하기로 했다. 역할이 정해지면 이에 따라 자신이 권한과 책임을 갖고 해야 하는 구체적인 업무가 무엇인지가 드러난다. 기존에 해오던 업무만 하는 게 아니라 자신의 역할을 잘 수행하기 위한 새로운 업무들을 만들어내거나 시도해볼 수 있다. 팀장이 하던 업무들을 리스트업 해서 단순하게 업무 단위로 역할을 나누지 않은 이유가 여기에 있다. 자신이 맡은 역할의 시선에서 보면 팀이나 프로젝트가  잘 돌아가기 위해 있어야 했지만 그동안 없었던 업무를 찾아낼 수 있다. 마찬가지로 관습적으로 수행되어 왔지만 별 효용은 없는 업무를 삭제하거나 개선할 수 있다. 리더의 전문화는 더 일을 잘 하기 위한 고민에서 시작되었다. 역할 부여하기나눈 역할을 누구에게 줄까에이스프로젝트는 역할 중심 문화가 도입되기 이전에도 한 팀에 한 명의 팀장만 있는 구조가 아니었다.기획팀에도 두 명의 팀장이 있었고 그래픽팀에는 무려 세명의 팀장이 있었다. 신규 입사자들은 팀은 하나인데 팀장은 여러 명 있는 조직구조를 당혹스러워하기도 했다. 본격적으로 조직문화에 대해 고민하기 전부터 팀장 혼자서 팀을 이끄는 것이 실질적으로 불가능하거나 불합리하다는 생각을 하고 있었던 것 같다.이것도 하고 저것도 하는 팀장이 둘이나 셋씩 있는 것보다는 하나의 역할을 담당하는 직책자가 여러 명 있는 것이 팀을 이끌고 역할을 전문화하는 데에 도움이 된다. 규모가 작은 팀의 경우 한 사람이 여러 가지 역할을 겸하기도 하지만 팀장이 여러 명 있었던 팀의 경우에는 각 팀장의 성향과 장단점, 역량을 파악해 적합한 역할을 부여했다. 막상 부여받은 역할을 맡아보니 적성에 맞지 않은 경우 다른 역할을 부여하기도 했고 역할을 맡기보다는 실무에 집중하고 싶어 한 사람에게서는 역할을 회수하기도 했다. ‘팀장’이라는 직책을 줄 때보다 역할의 부여와 회수가 가벼워졌고 상황에 맞는 유연한 조직구조를 만들 수 있었다.역할 중심 문화를 도입하면서 새롭게 역할을 맡게 된 구성원들도 있었다. 어느 정도 두루두루 하는 사람보다는 특정 부분에 두각을 나타내 자기가 맡은 부분을 스스로 결정하고 책임질 수 있는 사람이 주로 역할을 맡았다.역할 명확화누가 어떤 역할을 하고 있는지 알려주자역할 부여 후에는 현재 누가 어떤 역할을 맡고 있고 역할의 정의가 무엇인지 명확히 공유했다. 에이스프로젝트에는 ‘서포터’라는 역할이 있다. 서포터는 신규 입사자가 새로운 환경에 잘 적응할 수 있도록 생활 면에서 도움을 주는 사람이다. 서포터가 된 사람은 신규 입사자 및 구성원 모두에게 공지된다. 공지 없이 누군가 신규 입사자에게 자꾸 말을 거는 경우 신규 입사자도, 다른 팀원들도 “왜 저렇게 오지랖이지?”하고 부담스럽게 여길 수 있다. 그러나 서포터 역할을 명확하게 공지하고 나면 서포터가 신규 입사자에게 적극적으로 관심을 갖고 도움을 주려고 하는 것을 아무도 이상하게 생각하지 않는다. “회사까지는 어떻게 오세요?” “점심은 뭐 먹을까요?” 와 같은 질문을 해도 이상한 시선으로 보는 사람이 없다. 신규 입사자 입장에서도 역할을 맡은 사람에게는 더 자연스럽게 궁금한 것들을 물어볼 수 있다.이렇듯 역할에 대해 명시하고 다른 사람들에게도 누가 해당 역할을 맡았는지를  ‘알게’ 하는 것이 중요하다. 명시적이지 않은 권한을 행사하거나 역할을 수행하는 경우 다른 구성원들이 업무적으로 혼란스러워하거나 커뮤니케이션 상의 오해가 생길 수 있기 때문이다. 각각의 역할을 누가 맡았는지 정확히 알게 되면  어떤 문제가 생겼을 때 나에게 도움을 줄 수 있는 사람이 누구인지 확실히 알 수 있다. 에이스프로젝트는 프로젝트 단위, 팀 단위로 각각 세분화된 리딩 역할을 명시하고 역할이 바뀔 경우 내용을 즉시 공유한다.그래서 에이스프로젝트에는 어떤 역할이 만들어졌나?4편에 계속.

요즘은 데이터 분석이 스타트업, 대기업 가릴 것 없이 유행입니다. VCNC도 비트윈 출시 때부터 지금까지 데이터 분석을 해오고 있고, 데이터 기반의 의사결정을 내리고 있습니다.데이터 분석을 하는데 처음부터 복잡한 기술이 필요한 것은 아닙니다. Flurry, Google Analytics 등의 훌륭한 무료 툴들이 있습니다. 하지만 이러한 범용 툴에서 제공하는 것 이상의 특수하고 자세한 분석을 하고 싶을 때 직접 많은 데이터를 다루는 빅데이터 분석을 하게 됩니다. VCNC에서도 비트윈의 복잡한 회원 가입 프로세스나, 채팅, 모멘츠 등 다양한 기능에 대해 심층적인 분석을 위해 직접 데이터를 분석하고 있습니다.빅데이터 분석 기술큰 데이터를 다룰 때 가장 많이 쓰는 기술은 Hadoop MapReduce와 연관 기술인 Hive입니다. 구글의 논문으로부터 영감을 받아 이를 구현한 오픈소스 프로젝트인 Hadoop은 클러스터 컴퓨팅 프레임웍으로 비싼 슈퍼컴퓨터를 사지 않아도, 컴퓨터를 여러 대 연결하면 대수에 따라서 데이터 처리 성능이 스케일되는 기술입니다. 세상에 나온지 10년이 넘었지만 아직도 잘 쓰이고 있으며 데이터가 많아지고 컴퓨터가 저렴해지면서 점점 더 많이 쓰이고 있습니다. VCNC도 작년까지는 데이터 분석을 하는데 MapReduce를 많이 사용했습니다.주스를 만드는 과정에 빗대어 MapReduce를 설명한 그림. 함수형 프로그래밍의 기본 개념인 Map, Reduce라는 프레임을 활용하여 여러 가지 문제를 병렬적으로 처리할 수 있다. MapReduce slideshare 참조MapReduce는 슈퍼컴퓨터 없이도 저렴한 서버를 여러 대 연결하여 빅데이터 분석을 가능하게 해 준 혁신적인 기술이지만 10년이 지나니 여러 가지 단점들이 보이게 되었습니다. 우선 과도하게 복잡한 코드를 짜야합니다. 아래는 간단한 Word Count 예제를 MapReduce로 구현한 것인데 매우 어렵고 복잡합니다.MapReduce로 단어 갯수를 카운트하는 간단한 예제 (Java). 많은 코드를 작성해야 한다.이의 대안으로 SQL을 MapReduce로 변환해주는 Hive 프로젝트가 있어 많은 사람이 잘 사용하고 있지만, 쿼리를 최적화하기가 어렵고 속도가 더 느려지는 경우가 많다는 어려움이 있습니다.MapReduce의 대안으로 최근 아주 뜨거운 기술이 있는데 바로 Apache Spark입니다. Spark는 Hadoop MapReduce와 비슷한 목적을 해결하기 위한 클러스터 컴퓨팅 프레임웍으로, 메모리를 활용한 아주 빠른 데이터 처리가 특징입니다. 또한, 함수형 프로그래밍이 가능한 언어인 Scala를 사용하여 코드가 매우 간단하며, interactive shell을 사용할 수 있습니다.Spark으로 단어 개수를 카운트하는 간단한 예제 (Scala). MapReduce에 비해 훨씬 간단하다.Spark과 MapReduce의 성능 비교. I/O intensive 한 작업은 성능이 극적으로 향상되며, CPU intensive 한 작업의 경우에도 효율이 더 높다. (자료: RDD 논문)Apache Spark는 미국이나 중국에서는 현재 Hadoop을 대체할만한 기술로 급부상하고 있으며, 국내에도 최신 기술에 발 빠른 사람들은 이미 사용하고 있거나, 관심을 갖고 있습니다. 성능이 좋고 사용하기 쉬울 뿐 아니라, 범용으로 사용할 수 있는 프레임웍이기에 앞으로 더 여러 분야에서 많이 사용하게 될 것입니다. 아직 Spark를 접해보지 못하신 분들은 한번 시간을 내어 살펴보시길 추천합니다.기존의 데이터 분석 시스템 아키텍처기존의 데이터 분석 시스템 아키텍처기존의 시스템은 비용을 줄이기 위해 머신들을 사무실 구석에 놓고 직접 관리했으며, AWS S3 Tokyo Region에 있는 로그를 다운받아 따로 저장한 뒤, MapReduce로 계산을 하고 dashboard를 위한 사이트를 따로 제작하여 운영하고 있었습니다.이러한 시스템은 빅데이터 분석을 할 수 있다는 것 외에는 불편한 점이 많았습니다. 자주 고장 나는 하드웨어를 수리하느라 바빴고, 충분히 많은 머신을 확보할 여유가 없었기 때문에 분석 시간도 아주 오래 걸렸습니다. 그리고 분석부터 시각화까지 과정이 복잡하였기 때문에 간단한 것이라도 구현하려면 시간과 노력이 많이 들었습니다.Spark과 Zeppelin을 만나다이때 저희의 관심을 끈 것이 바로 Apache Spark입니다. MapReduce에 비해 성능과 인터페이스가 월등히 좋은 데다가 0.x 버전과는 달리 1.0 버전에서 많은 문제가 해결되면서 안정적으로 운영할 수 있어 비트윈 데이터 분석팀에서는 Spark 도입을 결정했습니다.Apache Zeppelin은 국내에서 주도하고 있는 오픈소스 프로젝트로써, Spark를 훨씬 더 편하고 강력하게 사용할 수 있게 해주는 도구입니다. 주요한 역할은 노트북 툴, 즉 shell에서 사용할 코드를 기록하고 재실행할 수 있도록 관리해주는 역할과 코드나 쿼리의 실행 결과를 차트나 표 등으로 시각화해서 보여주는 역할입니다. VCNC에서는 Zeppelin의 초기 버전부터 관심을 가지고 살펴보다가, Apache Spark를 엔진으로 사용하도록 바뀐 이후에 활용성이 대폭 좋아졌다고 판단하여 데이터 분석에 Zeppelin을 도입하여 사용하고 있고, 개발에도 참여하고 있습니다.또한, 위에서 언급한 하드웨어 관리에 드는 노력을 줄이기 위해서 전적으로 클라우드를 사용하기로 함에 따라서1 아래와 같은 새로운 구조를 가지게 되었습니다.새로운 데이터 분석 시스템 아키텍처새로운 데이터 분석 시스템 아키텍처새로운 데이터 분석 시스템은 아키텍처라고 하기에 다소 부끄러울 정도로 간단합니다. 애초에 전체 시스템 구성을 간단하게 만드는 것에 중점을 두었기 때문입니다. 대략적인 구성과 활용법은 아래와 같습니다.모든 서버는 AWS 클라우드를 이용수 대의 Zeppelin 서버, 수 대의 Spark 서버운영Spark 서버는 메모리가 중요하므로 EC2 R3 instance 사용로그는 별도로 저장하지 않고 서비스 서버에서 S3로 업로드하는 로그를 곧바로 가져와서 분석함중간 결과 저장도 별도의 데이터베이스를 두지 않고 S3에 파일로 저장Zeppelin의 scheduler 기능을 이용하여 daily batch 작업 수행별도의 dashboard용 Zeppelin을 통해 중간 결과를 시각화하며 팀에 결과 공유이렇게 간단한 구조이긴 하지만 Apache Spark와 Apache Zeppelin을 활용한 이 시스템의 능력은 기존 시스템보다 더 강력하고, 더 다양한 일을 더 빠르게 해낼 수 있습니다.기존현재일일 배치 분석코드 작성 및 관리가 어려움Zeppelin의 Schedule 기능을 통해 수행 Interactive shell로 쉽게 데이터를 탐험 오류가 생긴 경우에 shell을 통해 손쉽게 원인 발견 및 수정 가능Ad-hoc(즉석) 분석복잡하고 많은 코드를 짜야 함분석 작업에 수 일 소요Interactive shell 환경에서 즉시 분석 수행 가능Dashboard별도의 사이트를 제작하여 운영 관리가 어렵고 오류 대응 힘듦Zeppelin report mode 사용해서 제작 코드가 바로 시각화되므로 제작 및 관리 수월성능일일 배치 분석에 약 8시간 소요메모리를 활용하여 동일 작업에 약 1시간 소요이렇게 시스템을 재구성하는 작업이 간단치는 않았습니다. 이전 시스템을 계속 부분적으로 운영하면서 점진적으로 재구성 작업을 하였는데 대부분 시스템을 옮기는데 약 1개월 정도가 걸렸습니다. 그리고 기존 시스템을 완전히 대체하는 작업은 약 6개월 후에 종료되었는데, 이는 분석 성능이 크게 중요하지 않은 부분들에 대해서는 시간을 두고 여유 있게 작업했기 때문이었습니다.Spark와 Spark SQL을 활용하여 원하는 데이터를 즉석에서 뽑아내고 공유하는 예제Zeppelin을 활용하여 인기 스티커를 조회하는 dashboard 만드는 예제결론비트윈 데이터 분석팀은 수개월에 걸쳐 데이터 분석 시스템을 전부 재구성하였습니다. 중점을 둔 부분은빠르고 효율적이며 범용성이 있는 Apache Spark, Apache Zeppelin을 활용하는 것최대한 시스템을 간단하게 구성하여 관리 포인트를 줄이는 것두 가지였고, 그 결과는 매우 성공적이었습니다.우선 데이터 분석가 입장에서도 관리해야 할 포인트가 적어져 부담이 덜하고, 이에 따라 Ad-hoc분석을 수행할 수 있는 시간도 늘어나 여러 가지 데이터 분석 결과를 필요로 하는 다른 팀들의 만족도가 높아졌습니다. 새로운 기술을 사용해 본 경험을 글로 써서 공유하고, 오픈소스 커뮤니티에 기여할 수 있는 시간과 기회도 생겼기 때문에 개발자로서 보람을 느끼고 있습니다.물론 새롭게 구성한 시스템이 장점만 있는 것은 아닙니다. 새로운 기술들로 시스템을 구성하다 보니 세세한 기능들이 아쉬울 때도 있고, 안정성도 더 좋아져야 한다고 느낍니다. 대부분 오픈소스 프로젝트이므로, 이러한 부분은 적극적으로 기여하여 개선하여 나갈 계획입니다.비트윈 팀에서는 더 좋은 개발환경, 분석환경을 위해 노력하고 있으며 이는 더 좋은 서비스를 만들기 위한 중요한 기반이 된다고 생각합니다. 저희는 항상 좋은 개발자를 모시고 있다는 광고와 함께 글을 마칩니다.연관 자료: AWS 한국 유저 그룹 - Spark + S3 + R3 을 이용한 데이터 분석 시스템 만들기↩저희는 언제나 타다 및 비트윈 서비스를 함께 만들며 기술적인 문제를 함께 풀어나갈 능력있는 개발자를 모시고 있습니다. 언제든 부담없이 [email protected]로 이메일을 주시기 바랍니다!

지난 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)에 대한 대비를 시작하게 되었습니다.장애를 단순히 피해라고만 생각한다면, 서로를 비난하고 책임을 전가하는 상황이 펼쳐질 것입니다. 하지만 고객의 불편함과 맞바꾼 매우 비싼 경험이라고 생각한다면, 보다 튼튼하고 회복탄력적인 시스템을 갖추기 위해 노력하게 될 것입니다. 그러다 보면 언젠가는 데이터센터 전체에 문제가 생겨도 버틸 수 있는 모습으로 진화할 것이라고 생각합니다.#리디북스 #장애복구 #역경돌파 #개발 #개발후기 #개발자 #서버개발 #서버

스마트워킹,  스마트오피스, 스마트 툴 등등 요즘 일하는 공간에서 "스마트"하다는게, "스마트" 해진다는 게 중요한 트렌드로 자리 잡았습니다. 빠르게 진화하고 있는 기술을 어떻게 우리의 일과 접목시켜 업무 생산성을 올리고, 보다 효율적으로 일할 수 있을지. 함께 고민하고, 해결하고 싶은 사람들이 그만큼 많다는 것이겠죠?한편으론 "스마트하다"는 것이 업무 프로세스든 오피스 환경이든, 툴이 되었든 간에그것이 일종의 새로운 돌파구로서 기존 사업과 조직에 변화를 불러일으킬 것이란 기대에 스마트워킹에 대한 관심이 더욱 뜨거워지고 있다고 생각합니다.대표적으로 은행권의 스마트워킹제도 도입이 그렇습니다.스마트워킹센터 운영 중인 신한은행...인터넷 은행 출범 이전부터 기존 은행권들이 일종의 거점 근무지인 스마트워킹센터를 통해 자유로운 출퇴근과 유연근무제를 시행함으로써 창구 직원과 점포를 줄여가며 인터넷 은행에 대비했습니다.은행처럼 고객 대면 업무가 많은 호텔, 리조트 등 숙박업에서도 다양한 시도들이 이뤄지고 있는데요, 한 리조트 기업의 경우 스마트워킹 환경을 조성하기 위해 "페이퍼리스 문화"를 도입했다고 합니다.스마트폰 덕분에 피처폰 쓸 때보다 더욱 스마트해졌느냐 …투숙객의 정보를 종이가 아닌 태블릿 PC에 저장함으로써 불필요한 리소스(인력, 시간, 비용)는 줄고, 보다 쉬운 정보 활용과 공유가 가능해지겠죠? 하지만 스마트환경만 조성됐다고 해서 실제 현장에서 일하는 사람들의 업무 생산성이 올라가는 건 아닙니다. 그래서 플로우는 '플로우'라는 스마트워킹 툴, 즉 협업툴이 회사와 조직에서 어떻게 하면 잘 활용될 수 있을지 항상 고민합니다.  플로우 사용자들이 서비스를 사용해 일하는 과정에서 느끼는 불편/개선 요구사항이 플로우팀에게는 고민해결의 실마리입니다.스마트하게 업무 도구 활용하기(이미지 출처 : 플로우)결국 도구를 활용할 사람들의 마인드셋, 새로운 도구를 조직에 도입할 만한 영향력을 갖춘 관리자의 마인드셋이 가장 중요한 것일텐데요.그렇기 때문에 “스마트함”의 핵심은 업무 도구를 활용해서 조직을 스마트하게, 업무 프로세스를 혁신적으로 바꿔나갈 수 있는 조직 Key man 들의 자세와 실행력이 조직을 "스마트"하게 진화시켜 나가는 것이라고 생각합니다. 여러분이 생각하시는 "스마트함"은 어떤 것인가요 ?협업툴 플로우 바로가기

인상이 좋은 비결은.. 원래 이렇게 생겼어요 (찡긋)오디오 랩 팀의 막내, 알고 보니 세상 모든 매력을 덕지덕지 붙이고 다니는 Jason을 인터뷰해보았습니다.근데 대체 왜 이렇게 인상이 좋은 거예요? 출처: 알파카 월드 - 제이슨 닮은꼴"그냥 정말 원래 이렇게 생겼어요 하하. 웃는 상이예요. 사실 어릴 땐 눈이 좀 더 찢어지고(?) 올라가 있어서 좋은 인상이 아니었는데, 좋은 인상으로 변하더라고요..(나이 탓인가..) 웃는 게 습관이 되어버렸어요"인싸도 아싸도 아닌 '그럴싸'"인싸요? 아니에요 인싸. 그냥 저는 좀 알고 보면 반전도 많고 '모순덩어리' 일뿐이에요. 그래서 저를 표현하는 한 마디도 저는 '모순덩어리'라고 할래요. 예를 들면, 저는 해병대 출신인데 수영을 못하고요. 이성적인 것 같은데 또 되게 감성적이에요. 발라드를 되게 좋아하는데 제 노래방 18번은 '거꾸로 강을 거슬러 오르는 저 힘찬 연어들처럼'이에요. 사색하는 거 좋아하는데 또 가만히 있는 건 싫어요. 시간 아깝더라고요. (빵긋) 사내 제이슨 feat. 카이와 헤이든 듣고 싶은 당신의 스푼 라이프오디오 랩팀은 어떤 부서인가요?"오디오 랩팀은 스푼 라디오에서 오디오 방송 통신 기술을 연구하고 개발하는 부서입니다. 저희의 궁극적 목표는 세계 최고 오디오 기술 플랫폼이 되는 것이에요. 그리고 오디오 랩에서 제가 하고 있는 업무는 안드로이드 OS 클라이언트에 오디오 기술 개발하는 업무를 맡고 있어요. 오디오 랩팀에 막내이긴 한데.. 재간둥이 역할은 제가 맡고 있지 않아요 하하.. 저희 팀의 재간둥이 역할은 Ben님께서 하고 계십니다"스푼에 입사하기까지"제 입으로 말해도 되나요? 저는 수학을 좋아하진 않았는데, 잘했어요. 국어랑 사회 같은 문과계열 과목을 싫어했는데 이공계 쪽이 저와 적성에 맞더라고요. 수학 1등급 나왔는데 메가스터디 박 XX 선생님께 이 자리를 빌려 감사드립니다. 인강이 저를 만들어주셨어요.저의 원래 장래희망은 항공기 정비사였어요. 언제부터 비행기를 좋아했는지 모르겠지만 초등학교 때부터였던 것 같아요. 고3 때 진로를 정해야 하는데 항공정비과와 전자공학과와 고민을 했었어요. 그러다가 결국엔 전자 공학과 에 진학하게 되었고 자연스럽게 꿈 하고 멀어지게 되더라고요. 사실 항공 소프트웨어 쪽으로 일을 하게 될 줄 알았는데 다른 쪽으로 방향이 틀어지다 보니 어느덧 30대가 되어 있었어요. 사실 처음에 저는 스타트업에서 일하게 될 줄 몰랐어요. 이직을 준비하던 차에 제가 직접 스푼 라디오를 사용해보고, 기사도 읽게 되었고 Neil(대표)의 세바시 강연을 보고 이곳에서 일하고 싶다! 비전이 있다!라고 생각해서 오게 되었어요"내가 함께 일하고 싶은 사람서글서글한 사람을 좋아해요. 제가 그렇게 잘 못하는 편이라서요. 낯을 좀 많이 가리는데 저와는 다른 성향인 사람이라면 시너지 효과가 날 것 같아요파일럿 제이슨알고 싶은 Jason의 이야기해병대 출신부터 비행기 조종사까지"제가 안 그래 보이지만.. 사실 해병대 출신이에요. 해병대 왜 갔냐고 물어보신다면, 멋있어 보여서 가게 되었어요. 그게 전부예요. 복식 호흡하는 게 멋있어 보이더라고요. 원래 하고 싶은걸 다 하면서 살자라는 위주인지라, 꼭 무엇이든 하고 말거든요. 원래 꿈이 비행기 조종사였는데 꿈을 못 이루었으니 취미로도 해보자!라는 생각이 들어서 시작하게 되었어요. 한국에서도 할 수 있는데 제약이 너무 많아서 회사를 그만두고 미국에 갔어요. 여태 모아둔 돈 다 쓰고 왔어요. 4개월 정도 미국에서 하루 10시간씩 비행을 했었는데, 정말 행복했어요. 고등학교 때는 사실 실용음악도 준비했었어요. 아카펠라 중창단에 속해있었는데 2학년이 되고 이걸 진로로 결정하기엔 아니라고 판단이 들어서 그만두긴 했지만요. 그래서 대학교에 들어가고 밴드부에 들어가서 보컬을 맡았었어요. 저 점심시간에 혼자 코노가요. 같이 가기엔 부끄러워서.. 혼자 갑니다"유노윤호의 열정, 최강창민의 쿨함"제가 원래 자소서에 경청을 잘하는 사람이라고 적었는데 사실 가끔 듣는 것도 귀찮아요 하하.. 그리고 본인 이야기하는 것도 민폐라고 생각해서 잘하지 않는데 인터뷰하다 보니 엄청 많이 하게 되었네요. 근데 또 제가 남한테 지는 거 안 좋아해서 벤이랑 운동 누가 더 많이 하나 내기해서 요즘 매일 아침 출근 전에 수영 배우고 있고 화, 목은 영어학원을 다니면서 자기 계발을 하고 있어요. 목표가 없으면 안 되는 것 같아서 늘 목표를 일부러 세워요. 그래서 예전엔 사진도 배우러 다녔어요. 아 참! 수영을 배우다 보니 요즘 새로운 목표는 '라이프 가드'를 하고 싶어 졌어요. 이렇게 하고 싶은걸 하면서 열정적이게 살게 된 계기는 아마 아버지의 영향이 큰 것 같아요. 아버지가 매일 이렇게 말씀해주셨거든요"꿈을 꾸고 살아라, 돈은 따라온다! 반려견 '나무'의 아빠 Jason"저희 집 강아지 이름이 '나무'인데요. 식목일이 생일이라서 나무라고 지었어요. (나무 이야기할 때 눈빛이 초롱초롱해지면서 나무의 사진 보여주시던 제이슨) 나무는 귀엽고요. 비가 오나 눈이 오나 항상 저를 반겨줘요. 그래서 고마운 친구예요. 회사랑 집이 거리가 좀 멀어서 자취를 할까 생각했는데, 그러면 강아지가 혼자 집에 있어야 하니 안쓰러워서 하고 싶지 않았어요. 제가 없더라도 다른 가족들이 나무를 보살펴 줄 수 있어서 다행이라고 생각해요.팀원들이 Jason을 한마디로 표현한다면?Ian: JSON - "가볍고 빠르고 효과적이어서"*JSON [JavaScript Object Notation] :경량의 DATA교환 형식Ben: 알파카계의 알파치노 - "알파카처럼 온순한 외모의 소유자이지만 속엔 야망과 강한 카리스마를 가진 남자라서"

Kubernetes에서 컨테이너에 Persistent Volume을 붙이는 방법은 몇가지 있다. 여기서는 Kafka 서비스를 예로 삼아 주요 접근방법을 간단히 알아본다.Kubernetes v1.4.0를 기준으로 문서를 작성한다.Static말이 Static이지 수동 마운트를 뜻한다. 기본적으로 관리자가 EBS 볼륨을 만들고특정 Pod에 그 볼륨을 붙이는 작업을 한다. Volumes 문서에 나오는대로 하면 간단하다.apiVersion: v1 kind: Service metadata: name: kafka1 labels: app: kafka1 tier: backend spec: ports: # the port that this service should serve on — port: 9092 name: port targetPort: 9092 protocol: TCP selector: app: kafka1 tier: backend — - apiVersion: extensions/v1beta1 kind: Deployment metadata: name: kafka1 spec: replicas: 1 template: metadata: labels: app: kafka1 tier: backend spec: containers: — name: kafka1 image: wurstmeister/kafka imagePullPolicy: Always volumeMounts: — mountPath: “/kafka” name: kafka1volume ports: — containerPort: 9092 volumes: — name: kafka1volume awsElasticBlockStore: volumeID: vol-688d7099 fsType: ext4여기서 핵심은 다음의 두 줄 뿐이다.awsElasticBlockStore: volumeID: vol-688d7099Dynamic수동으로 볼륨을 붙이는 방법은 간단해서 좋다. 하지만 Autoscaling하는 서비스에 넣기에는 아무래도 무리다. 서비스가 뜰 때 요구사항에 맞는 볼륨을 스스로 만들어 붙이는 방법도 있다. Kubernetes Persistent Volumes를 참고해 작업해본다.우선 Kubernetes 생성할 EBS 볼륨의 사양을 정한다.# storages.yaml apiVersion: storage.k8s.io/v1beta1 kind: StorageClass metadata: name: default1a provisioner: kubernetes.io/aws-ebs parameters: type: gp2 zone: ap-northeast-1a iopsPerGB: “10” — - apiVersion: storage.k8s.io/v1beta1 kind: StorageClass metadata: name: default1c provisioner: kubernetes.io/aws-ebs parameters: type: gp2 zone: ap-northeast-1c iopsPerGB: “10”default1a를 선택하면 ap-northeast-1a Availablity Zone에 기가바이트당 IOPS는 10인 General SSD EBS 볼륨을 생성한다. 이제 다시 Kafka의 돌아가면apiVersion: v1 kind: Service metadata: name: kafka1 labels: app: kafka1 tier: backend spec: ports: # the port that this service should serve on — port: 9092 name: port targetPort: 9092 protocol: TCP selector: app: kafka1 tier: backend — - apiVersion: extensions/v1beta1 kind: Deployment metadata: name: kafka1 spec: replicas: 1 template: metadata: labels: app: kafka1 tier: backend spec: containers: — name: kafka1 image: wurstmeister/kafka imagePullPolicy: Always volumeMounts: — mountPath: “/kafka” name: kafka1volume ports: — containerPort: 9092 volumes: — name: kafka1volume persistentVolumeClaim: claimName: kafka1volumeclaim — - kind: PersistentVolumeClaim apiVersion: v1 metadata: name: kafka1volumeclaim annotations: volume.beta.kubernetes.io/storage-class: “default1a” spec: accessModes: — ReadWriteOnce resources: requests: storage: 300Gi이제 awsElasticBlockStore가 아닌 PersistentVolumeClaim을 통해 볼륨을 할당받는다. kafka1volumeclaim은 default1을 기준으로 스토리지 정책을 정하므로Availablity Zone: ap-northeast-1aIOPS: 기가바이트당 10General SSD300Gi 이상인 스토리지를 원한다는 요구사항을 기술한다. 위의 설정은 이러한 스토리지에 부합하는 EBS 볼륨을 생성하여 kafka1 Pod에 할당한다.분석Dynamic은 Autoscaling에는 적합하나 kubectl delete [service] 또는 kubectl delete [deployment] 등의 명령을 수행하여 서비스를 내렸다가 다시 올린 경우에 기존에 쓰던 볼륨을 마운트하지 않고 새 볼륨을 만드는 문제가 있다. 물론 delete를 하지 않고 서비스를 업데이트만 하는 경우에는 볼륨이 유지되지만 이래선 아무래도 문제의 소지가 많다.그래서 또다른 시나리오를 고민해볼 수는 있다. 짧게 설명하자면관리자가 Volumn Pool을 만들어놓고 Autoscaling 서비스가 이 풀 안에서 볼륨을 할당받게 한다. 이러면 앞서 본 두 가지 방식의 장점을 골고루 흡수할 수 있다.flocker 또는 glushterfs 같은 스토리지 관리 서비스를 활용해도 좋다. 하지만 배보다 배꼽이 큰 것 같은 느낌이 들지도 모르겠다.#데일리 #데일리호텔 #개발 #개발자 #개발팀 #인사이트 #꿀팁

브랜딩을 하다보면 디자인을 겁나 해야합니다. 회의실에서 나온 모든 얘기를 거의 다 만들어낸다고 생각하면 되죠. 로고부터 슬로건, 컬러, 제안서, 소개서, 리플렛, 브로슈어, 책자, 굿즈, 컨텐츠, 배너, 옥외광고 뭐 수도 없습니다. 그러니 브랜딩작업과 디자인은 사실상 뗄레야 뗄 수가 없습니다. 생각에서 시작되서 눈으로 확장되고 경험으로 끝나야 하는 것이 브랜딩이니까요. 이뻐보이지? 난 눈물이 나요..하아...ㅠㅠ얼마나 힘들어쓰꼬그래서 디자이너들이 일 좀 해보려고 의자에 앉았는데 이건 뭐 디자인이 너무 안되는 거야. 갑자기 의자가 너무 푹신하다거나, 뭔가 불편하다거나, 디자인요정이 어느 순간 사라져버리거나 또는 급똥악마가 찾아온다거나 뭐 여러가지 이유가 있겠죠. 디자인 할 줄 몰라서 안되는 게 아닙니다. 우리는 모두 능력자죠. 모두 머릿속에 크리에이티브 요정 한 마리 정도는 지니고 있는 똘똘이들입니다. 그럼에도 불구하고 도대체가 디자인을 할 수 없는 상황들이 있단 말입니다. 이런 상황들이 닥쳐버리면 데드라인 직전까지 육신과 나의 소중한 마이헐트가 만신창이가 되면서 머리만 쥐어뜯고 하염없는 공허속으로 빨려들어가기도 합니다. 사실 우스운 것들이지만 무시무시한 것들이죠.  지금 제가 이 글을 쓰는 이유도 디자인이 안되기 때문이죠. 그래서 도대체 왜 디자인이 안되는 지 냉정하게 생각해보았습니다. 그리고 그것을 정리해보았죠. 오늘은 우리의 크리에이티브 요정을 속박하는 잔혹한 현실들을 알아보겠습니다.하아....디자인 개자식1. 의자가 너무 불편해읏챠갑자기 의자가 불편해 집니다. 사실 의자의 탓이 아닙니다. 어제까지 편했던 의자가 왜 갑자기 불편해졌을까요. 물론 날 자꾸 째려보는 옆 자리 대리님의 의자바꿔치기 공격이 있었을지도 모릅니다. 하지만, 그럴 가능성은 매우 적어요. 그럼 혹시 내가 하룻밤만에 뭔가 체형이 바뀐 걸까요? 아니요. 일이 시작되었기 때문입니다. 아침에 입고왔던 팬티조차도 불편해질 수 있습니다.해결책 : 일이 끝나면 다시 편해집니다.2. 침대가 너무 가까워위허매침대는 위험한 존재입니다. 인간에겐 등센서라는 것이 있습니다. 신생아때부터 간직하고 있는 것이죠. 무언가가 등에 눕혀지거나 엄마등에 매달려있어야 잠이 오는 것입니다. 당연히 무언가가 등에 기대지는 순간 나른해지는 것이 양서류가 지상에 올라온 이래 생물의 DNA에 새겨진 본능인데, 그것을 거스른다는 것은 거대한 자연의 섭리를 이겨내야 한다는 것이죠. 그런 일은 우리에게 있을 수 없습니다.해결책 : 카페로 갑시다. 카페에서 일이 잘되는 이유는 누울 수 없기 때문입니다.3. 핀터레스트가 너무 재밌어그건 악마같은 사이트야. 볼수록 재밌다고. 심지어 예전에 봤던 거 또 봐도 재밌음. 레퍼런스 찾으러 갔다가 헤어나오지 못하는 광활한 네트워크가 허락한 유일한 마약이죠.해결책 : 와이파이신호가 2개정도 뜨는 곳에서 작업을 합시다. 이미지로딩이 답답해지도록.4. 배가 고파먹고만있어..디자인은 극도의 크리에이티브 작업이므로 수많은 당을 필요로 합니다. 인간의 당은 간과 허벅지 단일근육 하부에 저장되어 있는데, 두뇌활동이 활발해지기 위해선 이 당을 분해해서 원료를 만들어야합니다. 그러니 일을 할 때 '당이 떨어진다' 라는 말은 일리가 있는 얘기입니다. 근데 디자인할 땐 그냥 시도때도 없이 배가 고프다는 것이 문제입니다. 제 생각엔 그냥 일을 하기 싫어서인 것 같습니다. 해결책 : 참쌀선과, 참쌀선과를 먹읍시다.5. 음악이 맘에 안들어노동요는 필수임디자인할 때 음악은 중요합니다. 물론 케바케지만, 대부분은 자신만의 노동요를 가지고 있기 마련이지요. 하지만 카페에서 자꾸 시끄러운 음악, 싫어하는 종류(저는 주로 아이돌음악..)등이 꾸준히 나오면 아주 환장하겠습니다. 이어폰이나 헤드셋을 끼고 일하는 것도 1,2시간이지 나중에는 귀가 아리고 땀차서 못끼고 있겠더라구요. 노동요의 선정과 청취는 크리에이티브 요정을 편케 해줍니다.해결책 : 노이즈캔슬링 헤드셋을 삽시다. 놀라움을 경험할 수 있습니다. 팀장님 얘기도 안들림.6. 조명이 맘에 안들어눈부셧!조명이 노래서, 조명이 하얘서, 조명이 밝아서, 조명이 어두워서... 모든 조명이 다 거슬립니다.햇빛이 강하면 노트북이 잘 안보이고, 햇빛이 약하면 졸리고..해결책 : 노란 카페!!..노란 카페가 좋습니다. 노란 불빛은 크리에이티브 요정의 양식과도 같죠.7. 사진을 못 찾겠어대부분 디자인은 이미지 찾는데에 시간을 많이 쏟게 되더군요. 환장합니다 정말. 내가 원하는 그 사진을 찾아야 하는데 외국 저작권프리 사이트를 겁나 뒤지는 것은 못잡아도 1,2시간 이상이 걸립니다. 딴 짓하고 있는게 아니라 진짜 이미지를 못 찾겠습니다. 나중엔 막 합성도 하고, 보정도 해보지만 원본자체가 개똥인데 이쁘게 반죽한다고 똥이 아닌게 되는 건 아니죠. 해결책 : 어쩌다 맘에 드는 사진을 찾으면, 워터마크. 결국 돈인가...8. 폰트를 못 찾겠어예쁜 폰트를 찾아야 하는데 도대체 이 폰트 저 폰트 다 찾아봐도 맘에 안듭니다. 보통은 디자이너들이 사랑하는 몇 개의 폰트가 있긴 합니다. 그래서 일반적인 텍스트는 보통 그것만 쓰죠. 하지만 종종 아트웍을 해야할 때는 아웃라인 따서 이래저래 편집해야 하는 경우가 있단 말입니다. 그것에 어울리는 폰트를 찾는 것은 참으로 고역입니다. 해결책 : 유료폰트9. 훈수쟁이의 출현몇 시간 동안 자간 맞추고, 그리드 맞춰서 아트웍해놓으니 스윽 지나가던 훈수쟁이님이 '그거 좀 잘 안보이지 않겠어?' 라고 슥 지나갑니다. 아쉽게도 훈수쟁이는 대부분 나의 윗사람들입니다. 해결책 : 아주 현수막을 만들어서 방에 붙여드립시다.10. 방망이깎는 노인이 오셨다!!!장.인.정.신가끔 그 분이 오십니다. 그 분이 오시면 사실 모든 것이 끝난거야. 바로 장.인.정.신 이죠. 이 분이 마음속에 방문하시면, 사륜안을 개안하면서 픽셀단위의 오점들이 눈에 보이고 누끼의 완성도가 거의 크로마키 사진급으로 상승합니다. 그 댓가로 시력과 손목, 시간을 날려먹을 수 있습니다. 해결책 : 디자이너에게 방망이 깎는 할아버지는 랜덤하게 찾아오시므로, 막을 수 없습니다.11. 아이디어 요정이 오셨다!!!안녕?다 만들고 나면 아이디어 요정이 백색의 간달프마냥 헬름협곡 동쪽에서 찾아오십니다. 왜 시안을 구상할 땐 그게 생각나지 않았을까. 하지만 이 요정을 그냥 지나치기에는 너무 큰 대군을 몰고 오셨기에, 우리는 또 새로운 시안을 만들기도 합니다.해결책 : 대부분은 처음 만든 것이 컨펌됩니다.12. 자료를 안줌그것만 오면 되는데 그게 안옵니다.해결책 : 오후 약속을 취소합니다.13. 뭔 말인지 모르겠어.존나 모르겠다.이해 할 수 없는 비지니스모델이나 전문용어들이나 복잡한 개념들이 가득한 경우가 있습니다. 철골구조 중 H형강의 접합 시 문제점을 해결하기 위한 단방향체결식 볼트라던지... 그런것들.(실제로 만들어 봤었는데 토목공사의 프로세스를 공부해야했습니다.)해결책 : 오유에 이게 뭔 말이냐고 올려봅시다.생각보다 쉽게 잘 알려주더군요. 신뢰도는 반반14. 하얗게 타버렸어주화입마사람마다 다르지만 보통 한 번 방망이 할아버지가 오시거나, 또는 훈수쟁이가 와서 영혼을 불태우다 보면 몇 시간 내로 하얗게 재만 남은 육신을 발견할 수 있습니다. 이 육신은 당분간 제 정신으로 일을 할 수 없으며, 일의 속도가 급격하게 느려지고 사고능력이 저하되는 등 심리적 무정부상태 또는 주화입마와 비슷한 상태가 됩니다. 더 이상 뭐가 생각나지도 않고 생각하기도 싫은 지경이 됩니다.해결책 : 내일의 나를 믿어봅시다.15. 누군가 똥을 싸놓고 갔다..개똥같은...협업은 말은 아름답지만 현실은 잔혹한 경우가 많습니다. 누군가가 대략 시안잡아서 넘겨줄테니 툴작업만 해달라기래 오후6시에 온 시안을 손에 쥐어봤더니 나에게 왠 이 세상의 것이 아닌 듯한 무의식의 청사진같은 것이 쥐어져 있습니다. 해결책 : 그냥 내가 양식을 만들어 주고 빈칸을 채우라고 합시다.16. 해가 떨어지지 않았다.낮엔 디자인이 잘 안됩니다.해결책 : 24시간 카페는 시험기간 대학생과 디자이너를 타켓팅으로 한 공간입니다.17. 화장실에 그 분을 버리고 나옴보통 크리에이티브 요정은 머리나 마음속에 있다고 하는데, 제 생각엔 대장이나 방광 정도에 존재하는 것 같습니다. 한참 소변 참아가며 죽도록 집중해서 디자인하고 있다가, 이제 더 이상은 안되겠다 싶어서 화장실에 다녀오면 그 분이 사라져있습니다. 아마 물과 함께 쓸려내려가신 듯 합니다. 그 분이 떠나신 뒤엔 속도가 엄청나게 떨어지면서 귀찮음이 그 빈자리를 채웁니다.해결책 : 어쩔 수 없지 뭐..18. 컴터가 꼬졌음기회는 이 때다. 새로 사자크게 두 가지 종류가 있습니다. 저장 시에 메모리문제로 튕기는 경우와, 그냥 이것저것 함께 켜놓고 하다가 작동이 중지되는 경우죠. 우리에게 애시당초 선택권이 없는 '온라인으로 해결 방법을 확인하고 프로그램을 닫습니다.' 따위의 선택지를 주지만 어차피 뭘 눌러도 넌 망했다는 얘기입니다. 해결책 : 메모리 문제라면 가상메모리를 늘려서 일시적으로 해결은 가능합니다. 링크참조해보세요. http://imrich.tistory.com/981 / 그냥 작동이 중지되는 경우는 대부분 망할 안랩과 베라포트 등의 백신프로그램이 리소스를 엄청 잡아먹고 있는 탓도 있고, 다양한 프로그램을 한꺼번에 돌리고 있는 경우에 자주 발생합니다. 일단 빌어먹을 백신은 다 지워버리고, 인터넷창이나 쓸데없는 것들은 일단 꺼둡시다. 아니면 그냥 이 참에 다 부셔버리고 좋은 것을 삽시다.19. 저장을 안함뭐라 할 말이없다..침.통해결책 : 절레절레.. 컨트롤에스를 소중히 하지 않았군..20. 그냥 일이 많음사실 이겁니다. 디자인은 이렇게 해줘요! 해서 30분만에 뚝딱 만들어지지 않습니다. 이미지 가져다 붙이고 텍스트 정렬만 하는데 뭐 그렇게 시간이 걸려??? 라는 말은 매우 창피를 당할 수 있으니 삼가도록 합시다. 보통 그렇게 우스워보이는 심플단순한 시안이 나오려면 그 이전에 몇 개의 시안을 갈아엎고 다시 만들었는지 모를 일입니다. PPT 한 장을 장당 10분으로 계산한다거나, 포스터 하나 그냥 2시간정도? 로 생각하시는 분들이 21세기에도 현존하시며 디자이너에게 그냥 생각나는 대로 마구 오퍼를 주시는데... 도덕적으로 옳지 못한 일입니다.해결책 : 곧 이것을 해결하기 위해 책이 나옵니다. 제 책. (헤헤헤헤..)

한때 방송사에서 ′경영′이라는 단어가 생소했던 시절이 있었습니다. 몇 개의 방송사가 방송 시장을 과점하고 있었기 때문에 재원은 여유가 있었고, 방송사간의 경쟁은 큰 의미를 주지 못했습니다. 당시에는 프로그램을 ′제작′하고 뉴스를 ′보도′하는 것만이 방송사의 활동이었습니다. 그러나 방송 환경이 과거와는 비교되지 않을 정도로 변한 지금, ′경영′을 빼놓고는 방송을 말할 수 없습니다. 종합편성채널, CATV, 위성방송, 인터넷 등 지상파방송의 지위를 위협하는 많은 매체들이 방송시장에서 경쟁을 부추기고 있습니다.KBS 역시 이 경쟁에서 자유로울 수 없습니다.우수한 프로그램이라 하더라도 효율성과 경제성을 바탕으로 제작하지 않으면 누구도 방송사의 생존을 보장하지 않습니다. ′방송사를 경영하는 것′,  다시 말해 ′조직의 비전을 제시하고 자원을 효율적으로 집중하고 배분하는 역할을 하는 것′이 '기획행정'의 존재이유입니다.　우리는 가장 가까이에서 방송을 바라보고 있습니다.KBS는 한국을 대표하는 공영 방송이며 영국의 BBC, 일본의 NHK 등 세계 일류 공영 방송과 어깨를 나란히 할 수 있는 방송입니다. 세계 방송의 흐름을 읽고 국내 방송 환경을 개척하며 한국방송을 굳건히 세우는 일. 또 5년 후, 10년 후의 KBS를 조망하고 바람직한 방송 위상을 확립하는 일. 여러분이 정책을 기획하고 조직과 예산을 관리하는 기획예산국과 같은 곳에서 일하게 된다면 여러분은 KBS의 미래로 밤잠을 설칠 수도 있을 것입니다.　′기획행정′은 방송과 함께 합니다.뛰어난 방송 제작을 위해 재원을 마련하고 인력과 물자를 적절히 배분 하는 일이 그것입니다. 대시청자서비스를 담당하며 시청자 제일주의를 실현하는 시청자권익보호국, 공영방송의 소중한 재원인 수신료를 관리하는 수신료정책국, 업무처리의 타당성을 점검하는 감사실, 인력채용·운영과 제도 전반을 다루며 인재를 육성하는 인적자원실, KBS의 주요 정책을 개발하고 예산 및 계열사·지역국을 관리하는 기획예산국, 광고국, 자산을 관리하고 직원 급여 및 후생복지, 제작비, 결산·세무를 담당하는 총무국 등 한정된 자원으로 최적의 최선의 노력을 기울이고 있습니다. ′기획행정′은 방송 제작의 일선에서도 그 역할을 충실히 수행하고 있습니다.방송국은 물론 방송을 만드는 곳입니다. 하지만 방송의 이면에는 한 컷의 화면을 위해 온갖 정성을 아끼지 않는 엔지니어, 카메라맨, 디자이너, 작가, 세트제작요원, 분장사, 오디오맨, 효과맨 등 수많은 사람들이 함께 하고 있습니다.′기획행정′은 이러한 다양한 분야의 전문가들을 방송이라는 정점에서 어우르는 역할을 하고 있습니다. 편성운영부, 보도운영부, 콘텐츠운영부, 라디오운영부, 제작리소스운영부 등은 방송 현장에서 제작자들과 호흡을 같이 하고 있습니다.  KBS, 디지털 이성과 아날로그 감성이 맞물리는 곳사회는 생산성과 효율성에 입각한 정글의 법칙만이 존재하고 있습니다. 일상에 얽매여 자신보다는 조직의 논리에 갇히기 쉽습니다. 사회인이 된다는 것은 스스로의 생계를 유지하는 것 뿐만 아니라 사회 속에서 자신의 가치를 실현하고 존재의 의미를 확인하는 일입니다. KBS는 최소 투자, 최대 이익의 실현이라는 경영의 논리를 바탕으로 기업을 운영한다는 점에서는 사기업과 같지만 국가기간방송으로서 방송의 이념과 목표를 더욱 소중히 하는 곳입니다. 원리원칙을 지키는 디지털 경영이 KBS의 경영 목표지만, 구성원들이 아날로그의 개성과 장점을 마음껏 구현할 수 있도록 그 토대를 마련해 주는 곳이기도 합니다.　KBS는 여러분을 향해 두 팔을 활짝 펼치고 있습니다!선택은 여러분의 몫입니다.　#한국방송공사 #KBS #KBS공채 #직무정보 #직무소개

출처 : 구글 이미지 검색Just Hacks지난 몇 주간 저는 I/O의 devops문화 기반을 다지는 작업을 해왔습니다. 여전히 부족한 점이 많지만 그동안 일어난 변화를 지켜보면 첫 걸음은 비교적 잘 뗀듯 합니다. 지금부터는 이 devops문화가 제대로 자리잡는 일이 중요한 단계입니다. 다시말해, devops문화가 튼튼하게 뿌리내릴 수 있게 Hacking하는 것이 저의 당분간의 과제입니다.최근 devops를 연구하고 도입하는데 적잖은 시간과 노력을 쏟았기 때문에 실패할 경우 매몰비용이 만만치 않습니다. 꼭 성공시켜야하는만큼 실증적으로 엔진을 검증하기로했습니다. 그래서 지난 주부터는 저도 devops문화에 소속된 벡엔드 엔지니어로서의 일을 시작했습니다. 당분간 직접 코드를 만들어내야겠지요.설계에 그치지 않고 스프린트를 직접 참여해야만 현재 devops문화가 지닌 문제점이 무엇인지 제대로 볼수 있고 훌륭한 기술조직으로 거듭날 수 있다고 저는 믿습니다. 다시 개발자의 자세로 돌아가기 위해 가장먼저 좋은 코드를 작성하는 공부를 시작하였습니다.좋은 코드 만들기컴퓨터가 인식 가능한 코드는 바보라도 작성할 수 있지만, 인간이 이해할 수 있는 코드는 실력 있는 프로그래머만 작성할 수 있다. -마틴 파울러-SW엔지니어가 되기로한 이상, 제겐 감동까지는 아니지만 코드리뷰를 하는 짝꿍이 쉽게 이해할 수 있는 좋은 코드를 짜야할 의무는 있습니다. 그래서 지금까지 감명 깊게 읽은 고전 책들을 복습하기 시작했습니다. 그 첫 번째 책이 켄트백의 구현패턴입니다. 이 책은 설계나 디자인 패턴과 같은 추상적인 내용보다 키보드로 코드를 짜내는 순간에 고민해야하는 부분에서 교훈을 줍니다. 저는 이 책을 통해 코드를 바라보는 제 관점이 다음과 같이 바뀐듯 합니다.필드(현업)에서 생산된 코드는 코드를 작성하는데 드는 시간보다 읽는 시간이 압도적으로 많기 때문에 이를 감안해 봤을 때 읽기 “좋은 코드”를 짜는 노력이 가장 중요하다.돌이켜보면 학생 시절에는 왜 좋은 코드를 짜야하는지 당연히 모를 수 밖에 없었던 것 같습니다. 프로젝트성격의 코드만 짰기 때문에 종강하고나면 제가짠 코드를 다시는 들여다 볼일이 거의 없었거든요. 만약 대학교가 학생들의 취업경쟁력을 높이기 위해 CS 지식 뿐만아니라 Hacker 소양도 가르치고 싶다면 1학년부터 졸업할 때까지 서서히 발전되는 프로그램 하나를 만드는 4년짜리 과제를 두면 효과적일 것 같습니다.말씀드린 것처럼 필드에서 생성된 코드는 작성 시간보다 유지보수를 위해 읽혀지는 시간이 더 많은 편입니다. 특히 린스타트업을 충실하게 따르는 스타트업이라면 런칭기간이 극단적으로 짧기 때문에 제품(SW) 의 생애주기 중 99%의 시간이 유지보수 단계에 있을 것입니다. 이런 관점에 비춰보면 독자를 고려한 좋은 코드를 짜야한다는 사실은 더욱 중요해집니다.새로운 원칙지금까지 제가 견지하고 있는 좋은 코드를 만드는 원칙은 단순화와 중복제거였습니다. 이번 기회에 이 책을 다시 읽고 제 프로그래밍관에 새로운 원칙을 한 가지 더 추가하였습니다. 일관된 추상화인데요.좋은 코드는 일관된 추상화를 보여줍니다. 아래 예시 코드로 바로 확인하실 수 있습니다.void compute() { input(); flag |= 0x0080; // 나쁜 추상화 output(); }이 간단한 compute라는 함수는 제목처럼 입력(input)을 처리하고 이를 16진수 연산을 거친뒤에 출력(output)과정을 거치면서 마무리 됩니다. 그런데, 함 수 2번째 줄에 드러난 flag변수의 16진수 연산은 조금 쌩뚱 맞습니다. 암호처럼 느껴지네요. comput의 절차를 보여주는 input, output 사이에서 세부 구현사항을 친설하게 알려주려는 작성자의 배려는 되려 독자에게 혼란을 주기만 합니다. 이 혼란스러운 코드를 캡슐화를 통해서 일관된 추상화 수준으로 아래 코드처럼 리팩토링 할 수 있습니다.void compute() { input(); updateFlag(color.Brown); // 좋은 추상화 output(); }16진수 연산대신 의도가 드러나는 함수명과 인자전달을 통해 우리는 input을 처리하고 ouput을 갈색 텍스트로 출력시킨다는 사실을 자연스럽게 받아들일 수 있게 됩니다. 보시는 예제처럼 일관된 추상화는 문제해결 능력, 알고리즘 실력보다 코드를 작성하는 센스에 가깝습니다. 항상 독자를 배려하는 마음을 갖고 상대방에 입장에서 서서 코드를 작성하는 습관을 가져야 겠습니다. 이제 코드를 짜고 리뷰도 받으면서 구린내나는 코드를 신나게 리팩토링 할 일만 남았네요 :-)#스위쳐 #Switcher #DevOPS #데브옵스 #개발 #개발자 #DevOPS도입 #인사이트 #성장

관리선어항2019년 어항관리선 어항정화활동 개시- 청결한 어항환경과 안전한 어항 조성을 위한 어항관리선 활동 개시 -  지난해 어항관리선 12척은 국가·지방어항 229개항을 대상으로 항내의 해양폐기물을 24,771톤을 수거하여 쾌적한 어항환경조성에 노력하였다. 올해에도 한국어촌어항공단의 어항관리선이 쾌적하고 아름다운 어항환경 조성을 위해 어항정화 활동을 개시한다.   어항관리선 12척 (50톤급 9척, 100톤급이상 3척)이 상호연계정화를 통하여 2월부터 11월까지 10개월간 동·서·남해안에서 225개의 국가·지방어항을 중심으로 1척당 120일씩, 해양폐기물 24,780톤 수거를 목표로 정화활동을 실시하여 지속적으로 어업인의 삶의 터전인 어항환경개선을 위해 노력할 예정이다.  이를 위해 지난 1.24~25일 2019년 어항관리선 상반기 업무협의회를 개최하여 △ 청결한 어항환경 조성을 위해 어항관리선 상시수거시스템 구축 △ 어항환경개선효과 측정을 위한 어항환경모니터닝 실시 △ 선박 해난사고 급증 관련 선박 안전관리 강화 등 올해의 운영 중점 추진방향에 대한 업무협의를 진행하였다. 청결한 어항환경 조성을 위해 지자체, 수협 및 어업인의 정화요청 의견을 수렴하여 225개항(국가어항 102개항, 지방어항 123개항)을 선정하고 효과적인 어항정화를 위해 해역별, 항구별 특성에 맞는 정화활동을 하고, 태풍·적조·괭생이 모자반 등 국가재난 발생 시 긴급출동으로 다목적 어항관리선 기능을 최대한 발휘하여 국가재난 해소에도 적극 지원할 계획이다. 또한 어항정화개선효과 측정을 위하여 해역별 5개항(총15개항)을 대상으로 어항정화 전·후 환경개선 효과를 모니터링하여 어항환경변화에 대한 기초자료를 구축하고 있다. 마지막으로 어항오염 사전예방 및 사후관리 활동을 강화하기 위해 지역학교 및 어업인 대상 어항환경 정책교육 및 “쾌적한 항, 다시 찾고 싶은 항” 캠페인 실시 등 어항이용자를 대상으로 어항오염 사전예방활동도 지속적으로 진행할 계획이다.#한국어촌어항공단 #FIPA #기업문화 #업무환경 #직무정보 #어항환경개선 #공공기관

 패션블로그 웹뜰입니다어느새 웹뜰 10주년 워크샵을 다녀온지 한달이란 시간이 지나버렸네요 3월에 다녀온 여름나라 코타키나발루 3박5일 웹뜰 해외워크샵 마지막 이야기를 들고 왔습니다. 둘째날 워크샵을 마치고 세번째날은 오전에는 호텔에서의 자유시간이였습니다. 전날 워크샵으로 늦게까지 달린 웹뜰 직원들이 충분히 휴식을 취할 수 있는 시간이였어요 늦잠도 좋지만 일단 조식은 챙겨서 먹어야 하니깐 일어나 조식뷔페로 갔습니다. ㅎㅎㅎ 역시 어제 달려서인지 어제보다 많은 직원들이 보이지 않네요 식사를 하면서 수영장쪽을 보내 오늘도 날씨가 끝내줍니다. 정말이지 코타키나발루에서 계속 날씨가 좋았던거 같아요 웹뜰의 직원들의 워크샵이라 날씨운이 따라 준 것 같습니다. 날씨도 좋고 수영장도 예쁘고 자유시간이니 조식을 먹고 수영을 해보기로 합니다. :)조식을 먹고 배도 부르겠다 산책 겸 마젤란수트라하버리조트를 돌아 다녀봤습니다. 정말 안 예쁜 곳이 없는 마젤란수트라하버네요 구석구석 어디가도 인생샷스팟!여기저기 돌아다니며 사진찍고 놀다가 다시 리조트 방으로 돌아가서 수영복 갈아입고 수영장으로나왔습니다. 파란하늘에 파란 수영장 물 꺄!! 너무너무 예쁘네요 야자수까지 있으니 이국적인 느낌 물씬 수영장에선 역시 썬베드죠 ㅋㅋㅋ 수영보다 썬베드 썬베드에서 요렇게 요렇게 다들 아시죠? 요 허세샷 다들 찍어보셨을꺼예요 ㅎㅎ 수영장에서 수영도 하고 인생샷도 찍어보고 즐거운 오전시간을 보냈습니다. 마젤란수트라하버 골드카드 혜택으로 리조트 안에서 점심도 해결할 수 있었습니다.점심은 피자또는 파스타 중에 골라서 먹을 수 있었는데요 피자도 파스타도 다 맛있었어요 샐러드와 후식으로 과일까지 나오더라구요 수영하고 먹으니 더 꿀맛! 접시를 싹싹 비웠습니다. 세번째날의 오후 일정은 반딧불 투어였습니다. 반딧불 투어는 묵고 있는 마젤란수트라하버리조트에서 버스로 한참 나가야한다고 하더라구요 호텔로비에서 단체사진 한장 남기고 버스를 타고 갔습니다. 가는 중간에 휴게소라기보단... 음 화장실을 가기위해 잠시 들린 곳이라고 하는게 더 맞을 것 같습니다. 간이 매점같은곳이 있어서 간단하게 요기를 할 수도 있었습니다. 화장실은 좀... 열악했어요 물론 비용도 지불해야하고 비용 지불도 했는데 그다지 깨끗하지는 않았더라는.. 역시 어딜 가봐도 한국이 젤 깨끗한거 같아요  ㅎㅎ제가 좋아하는 옥수수도 있어서 옥수수를 사서 다른 직원과 나누어 먹었습니다. 역시 옥수수는 꿀맛이엿습니다. 넘나 맛있어서 버스에서 냄새 풍기는지도 몰랐네요 그리고 곧 도착한 식당입니다.  이 식당 뒤쪽으로 강이 흐르고 있고 배를 탈수 있는 곳이 있는데 그곳이 바로 이따 저녁에 저희가 반딧불 투어를 할 곳이라고 합니다. 식당 안쪽 인테리어는 이런 모습.. 말레이시아는 중국의 영향을 꽤나 많이 받았다고 하더니 이 식당도 흡사 중국 식당 같은 모습이네요 지금 든든히 먹어야 반딧불투어를 할때 배고프지 않다고 합니다. 반찬의 가지수는 여러가지 나쁘지 않습니다. 다만 양념에 향신료가 너무나도 듬뿍 들어가있어 입맛에 안 맞아 저희 직원들 중 대부분은 식사를 제대로 하지 못했네요 식사를 하는 웹뜰 직원들을 위해서(?) 인지 아니면 원래 시간마다 정기 공연이 있는지는 모르겠지만 막간을 이용해서 공연을 보여주는 원주민들 나름 임팩트있게 공연을 보여주고 홀연히 떠나더라구요 ㅎㅎ식당에서 밥을 다 먹고 또 차로 10분정도 이동해서 저녁노을을 보러 갔습니다. 이름모를 해변가였는데 풀어놓은 소랑 말, 그리고 개까지... 해변에 응가를 싸놓아서 발밑을 정말 조심히 걸어야했습니다. 그래도 노을지는 해변에서 각자의 인생샷과 웹뜰 직원단체로 인생샷을 건질 수 있어 너무 좋았던 곳 이였습니다. 그리고 다시 식당쪽으로 돌아가서 반딧불투어!반딧불이는 빛에 민감하기때문에 사진은 찍지 못하였습니다. 역시 가장 아름다운 자연은 눈으로 즐기는게 가장 아름답게 즐길 수 있더라구요 숲따라 흐르는 강을 배타고 가면서 까만밤 수많은 별들 그리고 크리스마스트리처럼 반짝이던 반딧불이들까지너무나도 낭만적이였던 반딧불이 투어였습니다. 반딧불이 투어를 마치고 다시 숙소로 돌아온 웹뜰 직원들 저녁식사가 부실하여 허기졌을 직원들에게 한국에서 가지고온 컵라면과  맛있는 간식을 준비해주신 대표님 짱짱! 너무나도 감사합니다. 그리고 마무리로 조니워커블루라벨과 시원한 음료까지!셋째날 밤도 불태워 보았습니다. 그리고 넷째날 아침이 밝았습니다. 오늘은 체크아웃을 하기 전까지 자유시간으로 주어진 날각자 시내투어나 키나발루산 트레킹 그리고 마젤란수트라하버 투어 등으로 시간을 보냈습니다. 마젤란수트라하버리조트는 어제 오전에 즐겼으니 오늘은 시내투어를 해보았습니다. 시내로 가는 셔틀버스는 마젤란수트라하버리조트에서 시간마다 있었습니다. 저희는 일찍 서둘러서 조식먹고 10시차를 타는 거루~!셔틀버스는 티켓을 구매해야지 이용이 가능하구요 리조트앞 셔틀버스타는 곳에서 표를 구입할 수 있었습니다. 표는 3.2링깃으로 약 1달러정도의 금액을 내면 됩니다. 조금 기다리자 수트라하버라고 쓰여진 버스가 왔네요 저희말고도 다른 한국인 관광객과 타국의 관광객들이 버스를 많이 이용하더라구요 셔틀버스를 타고 시내로 들어가자마자 젤 처음에 보이는 이마고쇼핑몰에서 내렸습니다. 가장 최근에 지어진 력셔리한 쇼핑몰이라고하네요 약간 백화점 같은 느낌의 쇼핑몰이였어요 시원하고 깨끗하고 좋더라구요 백화점 느낌인 만큼 물건도 좋긴했지만 비싼 기분도 있어서 일단 여기저기 둘러보다가 나갔습니다. 그리고 밖으로 나와서 하염없이 시내를 걷기 시작했습니다. 물론 택시나 그랩등의 교통수단을 이용해도 되었지만 일단 코타키나발루 자체가 크고 넓은 편도 아니고 일단 걸으면서 시내를 구경하는것도 좋을것 같아서였습니다. 날씨는 덥긴했지만 그래도 한국의 한여름 40도를 육박하는 조금만 서 있어도 타 들어가는 듯한 더위는 아니였던 날이여서 걷기 좋았습니다. 걸어 다니며 여기저기 쇼핑몰도 구경하고 이국적인 풍경도 구경하는 재미가 쏠쏠햇습니다. 더워서 시원한 망고쥬스라도 사먹고 싶었는데 길에서 파는 쥬스는 안보이더라구요 어느정도 돌아다니다가 KK플라자 지하로 갔습니다. 지하에 마트에서 기념품을 사기위해서죠 여기가 한국인지 말레이시아인지 ㅋㅋ 한국말로 쓰여진 네이버추천 카야잼이라는 표시 그리고 한국어를 유창하게하는 직원덕에 쇼핑을 잘 할 수 있었습니다. 지인들에게 줄 망고젤리와 달리치약등을 사서 이제 배가 고프니 근처 현지 맛집 식당까지 다녀왔답니다. KK마트에서 거의 근처에 있는 유잇청이라는 코타키나발루 맛집입니다. 네이버에 검색해보면 나오는 맛집이라서 그런지 손님들이 대부분 한국 손님이였답니다. 가게도 넓은 편이고 회전율도 좋아서 살짝 대기하고 바로 자리에 앉을 수 있었습니다.  저희는 국수 카야토스트 그리고 사태라는 말레이시아식 꼬치구이까지! 골고루 시켰습니다. 밖에서 돌아다녀서 시원한 음료가 땡껴 콜라도 시켰구요 현지식 음식이라 향신료 듬뿍이지만 향신료에 대한 거부감 거의 없는 저희는 아주 맛있게 싹싹 먹었답니다. 마젤란수트라하버 리조트로 돌아갈때도 셔틀을 이용해도 되지만 시간이 좀 많이 남아서 택시를 타고 편하게 갔습니다. 택시가 엄청 오래된 차라 에어컨이 안나와서 좀 덥긴했네요 ㅎㅎ 이번엔 키나발루산 트레킹을 한 팀의 사진을 소개시켜드리겠습니다. 키나발루산 트레킹은 막 걸어서 트레킹을 하는 느낌이라기 보단 차를 타고 이동하는 시간이 훨씬 많아서 힘들지는 않았다고 합니다. 키나발루산으로 가는 도중 마을이 있어 시장에 들려 열대과일 구경도 하구요 코타키나발루 까지와서 열대과일중 왕자라는 별명을 지닌 두리안도 안먹어볼수 없겠죠 냄새는 썩은 양파냄새 가 나서 냄새만 맡으면 못먹을 것 같았지만 의외로(?) 너무 맛있어서 다들 잘 먹었답니다. 특히 여직원들이 더 잘먹었다는 소리가 ㅎㅎ 산으로 가는 길에 만난 시원하게 흐르는 계곡물 날이 더워서 계곡물에 풍덩하고 싶은 심정을 뒤로하고 다시 키나발루 산으로 갑니다!가는 길에 히비스커스 꽃도 만났습니다. 히비스커스 꽃 말로만 듣고 말린걸 차로만 마셔봤지 이렇게 눈으로 보는건 다들 처음약간은 무궁화를 닮은 붉은 꽃잎이 너무나도 매력적인 꽃이였답니다. 그리고 울창한 열대 우림까지! 역시 자연이 젤 아름답고 위대한 것 같습니다. 키나발루 산에 올라오지 않았다면 이런 광경을 어디서 볼 수 있었을까요 키니발루산 캐노피 흔들다리도 건넜습니다. 총 4번정도 건너는 거 같은데 흔들흔들요거 은근히 덜덜 떨리더라구요 무서워서 아래를 보지도 못하고 앞만 보고 건넜답니다.  이렇게 자연풍경에 빠져서 길을 열심히 걷는 사이에 키나발루산 정상이 눈앞에 똭~!! 구름위로 보이는 산 정상에 다들 입이 똭~!!어찌나 아름다운 풍경인지 자연은 정말 위대하네요 동남아시아의 최고 높은 산이라고 들었던거 같습니다. 정상까지 갔다오려면 1박2일이 걸린다고 하더라구요 일부러 키나발루산 트레킹을 하려고 오는분들도 있다고 합니다. 저희는 정상까지는 가지 못하고 여기서 기념촬영을 하고 이제 다시 숙소로 돌아갔습니다. 시내투어팀도 키나발루산 트래킹 팀도 모두 숙소에서 잠깐의 휴식을 취하고 이제 짐을 모두 가지고 오후 6시 퇴실을 합니다. 원래 마젤란수트라 하버 퇴실시간은 11시인가 그랬던거 같은데 저희는 골드카드 혜택으로 레이트체크아웃이 가능해서 6시까지 일정을 즐기고 조금이라도 쉬다가 나올수 있어 좋더라구요 퇴실하고 시내에 나와서 야시장 구경을 하는 시간이 주어졌습니다. 야시장에서 가이드님께서 1링깃짜리 코코넛주스나 망고주스를 사주었습니다. 기대하고 먹었는데 시럽이 좀 섞여있는 맛 ㅎㅎㅎ100% 과즙은 아니라 조금 실망했지만 그래도 나름 맛있게 잘 마셨습니다. 이따 몇 시까지 어디로 모이라고 말한 뒤 이제 각자 야시장 구경 오전에 나왔을때의 시내와는 좀 다른 모습이네요 오전은 더워서 였을까요? 오전엔 사람이 많이 보이지 않았는데 오후가 되니 사람들도 많이 보이고 여러가지 장사들이 나와서 인지 좀 더 활기 띈 모습이였습니다. 그래도 위험할 수 있기 때문에 절대 혼자는 다니지 말고 가방은 꼭 앞으로 매고 다녀야 한다고 가이드님께서 신신당부하였답니다. 야시장의 꽃은 역시 열대 과일이죠 ㅎㅎㅎ맛보라고 맛만 보라고 자꾸 말하는 동남아 상인들맛보고 어떻게 안 사냐구요! 저희 밥 먹구 공항가야해서 과일은 못사요 쏘리~야시장구경은 근처의 수공예시장도 구경해봅니다. 우리나라 남대문이나 동대문 시장 정도 되는 느낌의 가게가 빼곡히 자리 잡고 있었구요 여기가 기념품 사기에는 야시장보다 좀 더 볼거리도 많았습니다. 다만 너무너무너무너~~~무 더워서 오래 있지는 못하고 후딱후딱 보고 딱 사야 할 것만 사가지고 나왔네요 저는 여기서 지인에게 줄 드림캐쳐를 샀답니다. 물론 공항에서도 팔지만 여기서는 흥정도 가능하고 더 싸게 살수 있었습니다 :D야시장 구경이 모두 끝나고 이제 저녁먹을 시간 만나는 장소로 다들 시간 맞춰서 잘 와서 식당으로 이동! 무브무브코타키나발루에서의 마지막 저녁식사는 씨푸드였습니다. 뭐 씨푸드 하면 다들 떠올리는 바닷가재 킹크랩 왕새우등의 요리는 아니였지만 생선과 생선탕수, 크림새우, 오징어튀김등 그래도 씨푸드는 맞았네요 마지막 식사이니 만큼 다들 맛있게 잘 먹었답니다. 그렇게 식사를 모두 마치고 이제 공항으로 이동!3박5일간의 짧고도 긴 여행이 끝이났네요 워크샵으로 코타키나발루를 다녀오게 되다니 정말 웹뜰 직원이여서 행복하고 즐거운 시간들이였답니다. 다녀와서 힐링의 시간이 되었던거 같아요 함께한 10년보다 함께할 10년에 더욱 기대감을 가지며 일할 수 있을 것 같습니다. 담번에 또 즐겁고 재밌는 소식으로 찾아뵐께요 웹뜰의 워크샵 첫번째 이야기와 두번째 이야기는 아래 참고하시면 됩니다:)[웹뜰 창립 10주년 해외워크샵] 3월에 다녀온 여름나라 코타키나발루 3박5일 이야기 (1)[웹뜰 창립 10주년 해외워크샵] 3월에 다녀온 여름나라 코타키나발루 3박5일 이야기 (2)#코타키나발루 #워크샵 #해외워크샵 #웹뜰 #웹뜰워크샵 #마젤란수트라하버 #키나발루산 #인천공항 #이스타항공 #시내투어