전체 피드 목록

비트윈에서는 HBase를 메인 데이터베이스로 이용하고 있습니다. 유저 및 커플에 대한 정보와 커플들이 주고받은 메시지, 업로드한 사진 정보, 메모, 기념일, 캘린더 등 서비스에서 만들어지는 다양한 데이터를 HBase에 저장합니다. HBase는 일반적인 NoSQL과 마찬가지로 스키마를 미리 정의하지 않습니다. 대신 주어진 API를 이용해 데이터를 넣기만 하면 그대로 저장되는 성질을 가지고 있습니다. 이런 점은 데이터의 구조가 바뀔 때 별다른 스키마 변경이 필요 없다는 등의 장점으로 설명되곤 하지만, 개발을 쉽게 하기 위해서는 데이터를 저장하는데 어느 정도의 규칙이 필요합니다. 이 글에서는 비트윈이 데이터를 어떤 구조로 HBase에 저장하고 있는지에 대해서 이야기해 보고자 합니다.비트윈에서 HBase에 데이터를 저장하는 방법Thrift를 이용해 데이터 저장: Apache Thrift는 자체적으로 정의된 문법을 통해 데이터 구조를 정의하고 이를 직렬화/역직렬화 시킬 수 있는 기능을 제공합니다. 비트윈에서는 서버와 클라이언트가 통신하기 위해 Thrift를 이용할 뿐만 아니라 HBase에 저장할 데이터를 정의하고 데이터 저장 시 직렬화를 위해 Thrift를 이용합니다.하나의 Row에 여러 Column을 트리 형태로 저장: HBase는 Column-Oriented NoSQL로 분류되며 하나의 Row에 많은 수의 Column을 저장할 수 있습니다. 비트윈에서는 Column Qualifier를 잘 정의하여 한 Row에 여러 Column을 논리적으로 트리 형태로 저장하고 있습니다.추상화된 라이브러리를 통해 데이터에 접근: 비트윈에서는 HBase 클라이언트 라이브러리를 직접 사용하는 것이 아니라 이를 래핑한 Datastore라는 라이브러리를 구현하여 이를 이용해 HBase의 데이터에 접근합니다. GAE의 Datastore와 인터페이스가 유사하며 실제 저장된 데이터들을 부모-자식 관계로 접근할 수 있게 해줍니다.트랜잭션을 걸고 데이터에 접근: HBase는 일반적인 NoSQL과 마찬가지로 트랜잭션을 제공하지 않지만 비트윈에서는 자체적으로 제작한 트랜잭션 라이브러리인 Haeinsa를 이용하여 Multi-Row ACID 트랜잭션을 걸고 있습니다. Haeinsa 덕분에 성능 하락 없이도 데이터 무결성을 유지하고 있습니다.Secondary Index를 직접 구현: HBase에서는 데이터를 Row Key와 Column Qualifier를 사전식 순서(lexicographical order)로 정렬하여 저장하며 정렬 순서대로 Scan을 하거나 바로 임의 접근할 수 있습니다. 하지만 비트윈의 어떤 데이터들은 하나의 Key로 정렬되는 것으로는 충분하지 않고 Secondary Index가 필요한 경우가 있는데, HBase는 이런 기능을 제공하지 않고 있습니다. 비트윈에서는 Datastore 라이브러리에 구현한 Trigger을 이용하여 매우 간단한 형태의 Secondary Index를 만들었습니다.비트윈 HBase 데이터 구조 해부페이스북의 메시징 시스템에 관해 소개된 글이나, GAE의 Datastore에 저장되는 구조를 설명한 글을 통해 HBase에 어떤 구조로 데이터를 저장할지 아이디어를 얻을 수 있습니다. 비트윈에서는 이 글과는 약간 다른 방법으로 HBase에 데이터를 저장합니다. 이에 대해 자세히 알아보겠습니다.전반적인 구조비트윈에서는 데이터를 종류별로 테이블에 나누어 저장하고 있습니다. 커플과 관련된 정보는 커플 테이블에, 유저에 대한 정보는 유저 테이블에 나누어 저장합니다.각 객체와 관련된 정보는 각각의 HBase 테이블에 저장됩니다.또한, 관련된 데이터를 하나의 Row에 모아 저장합니다. 특정 커플과 관련된 사진, 메모, 사진과 메모에 달린 댓글, 기념일 등의 데이터는 해당 커플과 관련된 하나의 Row에 저장됩니다. Haeinsa를 위한 Lock Column Family를 제외하면, 데이터를 저장하기 위한 용도로는 단 하나의 Column Family만 만들어 사용하고 있습니다.각 객체의 정보와 자식 객체들은 같은 Row에 저장됩니다.또한, 데이터는 기본적으로 하나의 Column Family에 저장됩니다.이렇게 한 테이블에 같은 종류의 데이터를 모아 저장하게 되면 Region Split하는 것이 쉬워집니다. HBase는 특정 테이블을 연속된 Row들의 집합인 Region으로 나누고 이 Region들을 여러 Region 서버에 할당하는 방식으로 부하를 분산합니다. 테이블을 Region으로 나눌 때 각 Region이 받는 부하를 고려해야 하므로 각 Row가 받는 부하가 전체적으로 공평해야 Region Split 정책을 세우기가 쉽습니다. 비트윈의 경우 커플과 관련된 데이터인 사진이나 메모를 올리는 것보다는 유저와 관련된 데이터인 메시지를 추가하는 트래픽이 훨씬 많은데, 한 테이블에 커플 Row와 유저 Row가 섞여 있다면 각 Row가 받는 부하가 천차만별이 되어 Region Split 정책을 세우기가 복잡해집니다. RegionSplitPolicy를 구현하여 Region Split 정책을 잘 정의한다면 가능은 하지만 좀 더 쉬운 방법을 택했습니다.또한, 한 Row에 관련된 정보를 모아서 저장하면 성능상 이점이 있습니다. 기본적으로 한 커플에 대한 데이터들은 하나의 클라이언트 요청을 처리하는 동안 함께 접근되는 경우가 많습니다. HBase는 같은 Row에 대한 연산을 묶어 한 번에 실행시킬 수 있으므로 이 점을 잘 이용하면 성능상 이득을 얻을 수 있습니다. 비트윈의 데이터 구조처럼 특정 Row에 수많은 Column이 저장되고 같은 Row의 Column들에 함께 접근하는 경우가 많도록 설계되어 있다면 성능 향상을 기대할 수 있습니다. 특히 Haeinsa는 한 트랜잭션에 같은 Row에 대한 연산은 커밋시 한 번의 RPC로 묶어 처리하므로 RPC에 드는 비용을 최소화합니다. 실제 비트윈에서 가장 많이 일어나는 연산인 메시지 추가 연산은 그냥 HBase API를 이용하여 구현하는 것보다 Haeinsa Transaction API를 이용해 구현하는 것이 오히려 성능이 좋습니다.Column Qualifier의 구조비트윈은 커플들이 올린 사진 정보들을 저장하며, 또 사진들에 달리는 댓글 정보들도 저장합니다. 한 커플을 Root라고 생각하고 커플 밑에 달린 사진들을 커플의 자식 데이터, 또 사진 밑에 달린 댓글들을 사진의 자식 데이터라고 생각한다면, 비트윈의 데이터들을 논리적으로 트리 형태로 생각할 수 있습니다. 비트윈 개발팀은 Column Qualifier를 잘 정의하여 실제로 HBase에 저장할 때에도 데이터가 트리 형태로 저장되도록 설계하였습니다. 이렇게 트리 형태로 저장하기 위한 Key구조에 대해 자세히 알아보겠습니다.Column Qualifier를 설계할 때 성능을 위해 몇 가지 사항들을 고려해야 합니다. HBase에서는 한 Row에 여러 Column이 들어갈 수 있으며 Column들은 Column Qualifier로 정렬되어 저장됩니다. ColumnRangeFilter를 이용하면 Column에 대해 정렬 순서로 Scan연산이 가능합니다. 이 때 원하는 데이터를 순서대로 읽어야 하는 경우가 있는데 이를 위해 Scan시, 최대한 Sequential Read를 할 수 있도록 설계해야 합니다. 또한, HBase에서 데이터를 읽어올 때, 실제로 데이터를 읽어오는 단위인 Block에 대해 캐시를 하는데 이를 Block Cache라고 합니다. 실제로 같이 접근하는 경우가 빈번한 데이터들이 최대한 근접한 곳에 저장되도록 설계해야 Block Cache의 도움을 받을 수 있습니다.비트윈에서는 특정 커플의 사진이나 이벤트를 가져오는 등의 특정 타입으로 자식 데이터를 Scan해야하는 경우가 많습니다. 따라서 특정 타입의 데이터를 연속하게 저장하여 최대한 Sequential Read가 일어나도록 해야 합니다. 이 때문에 Column Qualifier가 가리키는 데이터의 타입을 맨 앞에 배치하여 같은 타입의 자식 데이터들끼리 연속하여 저장되도록 하였습니다. 만약 가리키는 데이터의 타입과 아이디가 Parent 정보 이후에 붙게 되면 사진 사이사이에 각 사진의 댓글 데이터가 끼어 저장됩니다. 이렇게 되면 사진들에 대한 데이터를 Scan시, 중간중간 저장된 댓글 데이터들 때문에 완벽한 Sequential Read가 일어나지 않게 되어 비효율적입니다.이렇게 특정 타입의 자식들을 연속하게 모아 저장하는 묶음을 컬렉션이라고 합니다. 컬렉션에는 컬렉션에 저장된 자식들의 개수나 새로운 자식을 추가할 때 발급할 아이디 등을 저장하는 Metadata가 있습니다. 이 Metadata도 특정 Column에 저장되므로 Metadata를 위한 Column Qualifier가 존재합니다. 이를 위해 Column Qualifier에는 Column Qualifier가 자칭하는 데이터가 Metadata인지 표현하는 필드가 있는데, 특이하게도 메타데이터임을 나타내는 값이 1이 아니라 0입니다. 이는 Metadata가 컬렉션의 맨 앞쪽에 위치하도록 하기 위함입니다. 컬렉션을 읽을 때 보통 맨 앞에서부터 읽는 경우가 많고, 동시에 Metadata에도 접근하는 경우가 많은데, 이 데이터가 인접하게 저장되어 있도록 하여 Block Cache 적중이 최대한 일어나도록 한 것입니다.Datastore 인터페이스비트윈에서는 이와 같은 데이터 구조에 접근하기 위해 Datastore라는 라이브러리를 구현하여 이를 이용하고 있습니다. HBase API를 그대로 이용하는 것보다 좀 더 쉽게 데이터에 접근할 수 있습니다. GAE의 Datastore와 같은 이름인데, 실제 인터페이스도 매우 유사합니다. 이 라이브러리의 인터페이스에 대해 간단히 알아보겠습니다.Key는 Datastore에서 HBase에 저장된 특정 데이터를 지칭하기 위한 클래스입니다. 논리적으로 트리 형태로 저장된 데이터 구조를 위해 부모 자식 관계를 이용하여 만들어 집니다.Key parentKey = new Key(MType.T_RELATIONSHIP, relId); Key photoKey = new Key(parentKey, MType.T_PHOTO, photoId); // 특정 커플 밑에 달린 사진에 대한 키 Datastore는 Key를 이용해 Row Key와 Column Qualifier를 만들어 낼 수 있습니다. Datastore는 이 정보를 바탕으로 HBase에 새로운 데이터를 저장하거나 저장된 데이터에 접근할 수 있는 메서드를 제공합니다. 아래 코드에서 MUser 클래스는 Thrift로 정의하여 자동 생성된 클래스이며, Datastore에서는 이 객체를 직렬화 하여 HBase에 저장합니다.MUser user = new MUser(); user.setNickname("Alice"); user.setGender(Gender.FEMALE); user.setStatus("Hello World!"); Key userKey = new Key(MType.T_USER, userId); getDatastore().put(userKey, user); user = getDatastore().get(userKey); getDatastore().delete(userKey); 또한, Datastore는 Key를 범위로 하여 Scan연산이 할 수 있도록 인터페이스를 제공합니다. Java에서 제공하는 Try-with-resource문을 이용하여 ResultScanner를 반드시 닫을 수 있도록 하고 있습니다. 내부적으로 일단 특정 크기만큼 배치로 가져오고 더 필요한 경우 더 가져오는 식으로 구현되어 있습니다.try (CloseableIterable> entries = getDatastore().subSibling(fromKey, fromInclusive, toKey, toInclusive)) { for (KeyValue entry : entries) { // do something } } Secondary Index 구현 방법HBase는 데이터를 Row Key나 Column Qualifier로 정렬하여 저장합니다. 이 순서로만 Sequential Read를 할 수 있으며 Key값을 통해 특정 데이터를 바로 임의 접근할 수 있습니다. 비트윈에서는 특정 달에 해당하는 이벤트들을 읽어오거나 특정 날짜의 사진들의 리스트를 조회하는 등 id 순서가 아니라 특정 값을 가지는 데이터를 순서대로 접근해야 하는 경우가 있습니다. 이럴 때에도 효율적으로 데이터에 접근하기 위해서는 id로 정렬된 것 외에 특정 값으로 데이터를 정렬할 수 있어야 합니다. 하지만 HBase에서는 이와 같은 Secondary Index 같은 기능을 제공하지 않습니다. 비트윈 개발팀은 이에 굴하지 않고 Secondary Index를 간단한 방법으로 구현하여 사용하고 있습니다.구현을 간단히 하기 위해 Secondary Index를 다른 데이터들과 마찬가지로 특정 타입의 데이터로 취급하여 구현하였습니다. 따라서 Index에 대해서도 Column Qualifier가 발급되며, 이때, Index에 해당하는 id를 잘 정의하여 원하는 순서의 Index를 만듭니다. 이런 식으로 원하는 순서로 데이터를 정렬하여 저장할 수 있으며 이 인덱스를 통해 특정 필드의 값의 순서대로 데이터를 조회하거나 특정 값을 가지는 데이터에 바로 임의 접근할 수 있습니다. 또한, Index에 실제 데이터를 그대로 복사하여 저장하여 Clustered Index처럼 동작하도록 하거나, Reference만 저장하여 Non-Clustered Index와 같이 동작하게 할 수도 있습니다. Datastore 라이브러리에는 특정 데이터가 추가, 삭제, 수정할 때 특정 코드를 실행할 수 있도록 Trigger 기능이 구현되어 있는데, 이를 통해 Index를 업데이트합니다. 데이터의 변경하는 연산과 Index를 업데이트하는 연산이 하나의 Haeinsa 트랜잭션을 통해 원자적으로 일어나므로 데이터의 무결성이 보장됩니다.못다 한 이야기각 테이블의 특정 Row의 Column들에 대한 Column Qualifier외에도 Row에 대한 Row Key를 정의 해야 합니다. 비트윈에서는 각 Row가 표현하는 Root객체에 대한 아이디를 그대로 Row Key로 이용합니다. 새로운 Root객체가 추가될 때 발급되는 아이디는 랜덤하게 생성하여 객체가 여러 Region 서버에 잘 분산될 수 있도록 하였습니다. 만약 Row Key를 연속하게 발급한다면 특정 Region 서버로 연산이 몰리게 되어 성능 확장에 어려움이 생길 수 있습니다.데이터를 저장할 때 Thrift를 이용하고 있는데, Thrift 때문에 생기는 문제가 있습니다. 비트윈에서 서버를 업데이트할 때 서비스 중지 시간을 최소화하기 위해 롤링 업데이트를 합니다. Thrift 객체에 새로운 필드가 생기는 경우, 롤링 업데이트 중간에는 일부 서버에만 새로운 Thift가 적용되어 있을 수 있습니다. 업데이트된 서버가 새로운 필드에 값을 넣어 저장했는데, 아직 업데이트가 안 된 서버가 이 데이터를 읽은 후 데이터를 다시 저장한다면 새로운 필드에 저장된 값이 사라지게 됩니다. Google Protocol Buffer의 경우, 다시 직렬화 할 때 정의되지 않은 필드도 처리해주기 때문에 문제가 없지만, Thrift의 경우에는 그렇지 않습니다. 비트윈에서는 새로운 Thrift를 적용한 과거 버전의 서버를 먼저 배포한 후, 업데이트된 서버를 다시 롤링 업데이트를 하는 식으로 이 문제를 해결하고 있습니다.

주변을 둘러보면 ‘생산성’이 뛰어난 사람이 한 명씩은 있다. 그들은 동시에 여러가지 것들을 진행하는데 결과마저 좋다. 심지어 커뮤니케이션 능력도 뛰어나기 때문에 그 팀은 팀워크도 최상이다. 옆에서 보고 있노라면 그렇게 많은 프로젝트와 커뮤니케이션을 성공시키는 ‘비결’이 궁금해진다. 그들은 정말 DNA가 다른 걸까? 아니면 후천적으로도 가능한걸까. 회사에서 동료들에게 좋은 평가를 받는것은 결코 중요하다. 지금부터 모두의 이익이 최상이 되는 방법, 모두의 피해를 최소화 하는 지혜로운 해결책을 도출 할 수 있는 1% 협업러의 커뮤니케이션 스킬 5가지를 공개한다. 1. 열정 에너지를 가진 매력적인 동료가 되자.이름만 떠올려도 같이 일하기 불편한 동료가 있는가 하면, 이름만 떠올려도 같이 일하고 싶게 만드는 동료가 있다. 그리고 방금 떠올린 같이 일하고 싶은 동료들의 공통점을 뽑자면 ‘열정’이라는 키워드가 잘 어울리는 사람일 것이다. 매사에 ‘열정’적인 에너지를 가진 사람이라면, 누구든 같이 일하고 싶게 만드는 매력과 이끌림을 가진 사람이라고 볼 수 있다.“열정은 나도 모르게 전염된다.” 재미있는 사실은 열정이 부족한 사람도, 열정이 넘치는 사람을 보면 끌리게 되어 있다고 한다. 무의식적으로 자신이 잊은 걸 상기시켜 주기 때문이다. 열정은 전염이 아주 강해서 주변인들에게 뜨거운 자극이 되고, 결국 조직의 분위기를 바꾸는 가장 큰 원동력이 된다고 볼 수 있다. 현재 내 열정이 조금 부족하다고 느껴진다면 열정 충만한 동료와 에너지를 함께 부딪히는 것도 좋다.“열정이 있는 사람에게는 매일이 천국이다.” 상위 1% 협업러들은 ‘열정’ 은 내가 가진 능력보다 더 큰일을 해낼 수 있게 만드는 힘이라고 한다. 그리고 그 열정을 지속적으로 유지할 수 있는 비결은 언제나 내가 하고 있는 일에서 가치를 찾는다고 답한다. ‘내가 하고 있는 일에서 가치를 찾는다 = 하고 싶은 일을 한다.’라는 말이 아니다. 나에게 어떤 일이 주어지던지 누군가가 시켜서 억지로 하는 것이 아니라 잘 해야 하는 이유를 스스로 찾으면서 그 업무를 해결하는 과정을 즐기라는 말이다. 2. 공감은 오아시스를 만든다.회사 내에서도 포식자가 들끓는 정글 같은 팀과 사막 속 오아시스 같은 팀의 차이는 무엇일까?그 해답은 공감에 있다.업무의 대부분은 분업되어 있다. 일을 하기 위해서는 다른 구성원과의 협업이 필수라는 얘기다. 협업은 구성원이 각자의 아이디어를 보태어 더 좋은 결과물을 만들어가는 과정을 거쳐가게 되는데. 이때 어떤 의견에 대해 공감하지 않고, 비판이나 무시를 거듭하면, 말해봐야 소용없다는 것을 학습한 구성원들은 새로운 아이디어를 내지 않게 된다. 이렇듯 업무와 공감은 땔 수 없는 것이다.공감이 없으면 커뮤니케이션도 없다.커뮤니케이션이 없으면 협업도 없다.취업포털 잡코리아가 직장 내 소통을 주제로 직장인 2860명을 대상으로 실시한 설문조사에 따르면 직장인 79.1%가 직장 내 소통장애를 경험한 적이 있다고 답했다. 소통 장애가 겪으면 근로 의욕이 꺾인다는 응답이 44.0%에 달했다. 하지만 이 설문에서 더 집중해야 되는 부분은 바로 다음이다. 소통을 위해 가장 중요한 것을 묻는 질문에 설문자들은 공감 능력(28.4%)을 1위로 꼽았다.한국은 멕시코에 이어 OECD 국가 중 두번째로 노동시간이 긴 나라이다. 우리는 하루의 대부분의 시간을 회사와 일에 묻혀 산다. 워라벨이 강조되는 이 시대에도 여전히 회사생활은 우리 시간의 많은 부분을 차지한다. 얼굴에 웃음을 띄며 만나는 사람은 친구가 되고, 노기를 띄우며 만나는 사람은 적이 된다는 말이 있다. 전하는 말에 공감을 담아 자신과 상대 모두 잠시나마 힐링되는 회사 생활이 될 수 있기를 바란다. 3. ‘발전적 피드백’으로 팀의 업무 완성도를 S급으로 높이자.팀 단위로 공동 목표를 가지고 업무를 수행할 때 피드백을 하는 사람도 피드백을 받는 사람도 서로의 감정과 시간에 대한 소모가 크기 때문에 스트레스로 여기는 경우가 많다. 그러나 상위 1% 협업러들은 피드백으로 작업 완성도를 높이는 것을 일련의 업무 과정으로 여긴다. 발전적 피드백은 리더가 팀원에게 일방적으로 조언을 전달하는것이 아니라 직책을 떠나 서로 조언과 정보를 나눌 수 있는 상호 커뮤니케이션의 기회가 되어야 한다. 팀의 무한한 성장을 위해 피드백을 즐기는 상위 1% 협업러들은 피드백은 하는 사람도, 받는 사람도 즐거워야 한다고 말한다.2-1) 수정 피드백을 하는 입장일 때, 나는 A / B / C 중 어떤 모습일까?‘일 잘하는 사람 = 피드백을 잘하는 사람’이라는 공식이 성립되는 것은 아니다. 종종 일을 잘하는 사람 중에 본인의 능력이 타인보다 출중하다고 생각하여 기고만장한 태도를 가진 사람들은 대체로 팀원들을 존중하지 못하고 가혹한 피드백을 하는 경우가 많다. 같이 일하는 직원들의 자존감을 떨어뜨리는 피드백은 동기부여를 잃게 하는 독설일 뿐이다. 피드백은 ‘할 것인가, 말 것인가’보다 ‘어떻게 잘 할 것인가’를 고민하는 것이 더 중요하다고 한다. 작업자의 결과물이 부족하다고 느껴 수정 피드백을 할 때는, 작업 수행자의 의도를 간단하게라도 듣고 공감을 표시한 후 내 생각을 전달하는 것이 좋다. 1분 1초가 빠르게 돌아가야 하는 치열한 업무 시간에 C와 같이 긍정적 피드백의 힘을 기르는 것은 말처럼 쉬운 일은 아니다. 때문에 우리는 대부분 A or B와 같은 모습일 것이다. 그러나 태도가 차이를 만든다는 것을 명심하라. 피드백 사냥꾼이 될 것인지 상위 1% 협업러의 차이를 만들 것인지는 본인의 선택에 달려있다. 2-2) 부정적 피드백을 받았을때, 나는 A / B / C 중 어떤 모습일까?내 결과물에 부정적 피드백을 받았을 때 기분 좋게 수용할 수 있는 사람은 극히 드물다. 대부분 방어적인 태도를 보이거나 내 생각이 옳음을 증명하기 위해 피력하는데 급급하여 ‘갑분싸’ 상황이 발생하기도 한다. 이러한 상황이 반복되다 보면 서로 피드백을 주고받는 것이 부담스러워서 결국 더 좋은 조언을 주고받을 수 있는 무한한 기회를 잃게 된다. 내 결과물이 언제나 칭찬과 인정을 받을 수 있으면 좋지만 그렇지 못하더라도 피드백은 무조건 환영하는 태도를 가져라. 내가 잘하고 있는 것인지 확인받고 싶어도 수년 직장 생활 중에 제대로 된 피드백을 받지 못한 직원들도 수두룩하다. 피드백은 돈 한 푼 들이지 않고 내 결과물을 객관적인 시선에서 발전시킬 수 있는 절호의 기회다. 타인의 피드백을 내 것으로 만들어 ‘질적인 전환’을 즐기는 것이 상위 1% 협업러의 특급 노하우다.4. 신뢰의 기본은 약속을 잘 지키는 사람.회사에서 같이 협업하고 싶은 동료를 떠올려 보자. 대부분의 사람들은 ‘업무 능력이 뛰어난 동료’가 아닌 주어진 ‘업무 약속’을 성실히 잘 지키고 신뢰할 수 있는 직원을 떠올릴 가능성이 높다. 그렇다면 내가 동료들에게 신뢰를 받는 사람일까?라는 질문은 스스로에게 해보자. 평범한 직장인이라면 대부분 이런 생각을 거의 해본 적이 없을뿐더러, 자신 있게 ‘Yes’라고 대답할 수도 없을 것이다. 상위 1% 협업러들은 동료들에게 신뢰를 얻는 것이 기본 덕목이라고 말한다.■ 업무 마감일 하루 전, 나는 A / B / C 중 어떤 직원의 모습일까? 업무 약속의 가장 기본이 되는 요소 바로 ‘일정 관리’다. 회사에서 일정이라는 것은 단순히 날짜가 아니다. 조직이 목표로 한 기간 내에 원하는 프로젝트를 끝내기 위한 수단이다. 내가 일정 관리를 놓쳐 일이 늘어지는 만큼 함께 일하는 동료 또한 시간적 여유를 잃는 악순환이 반복된다. 일정은 상호 커뮤니케이션의 기본이 되는 약속이기에 기획자도 디자이너도 개발자도 정해진 일정 내에 약속한 수준의 결과물을 전달해 주어야 전사적으로 업무가 원활히 이루어질 수 있다. 아무리 뛰어난 업무 능력을 가지고 있더라도, 매번 마감일을 준수하지 못한다면 직원들은 모두들 당신과의 프로젝트에서 불안함을 느끼기 마련이다. 업무의 시작일과 마감일을 잘 지키는 것, 그것이야말로 회사의 동료들에게 신뢰받는 1순위라는 것을 명심하자.5. 평일은 ‘프로’답게, 주말은 ‘프리’하게상위 1% 협업러들은 평일과 주말의 균형, 즉 일과 개인 삶의 균형을 조화롭게 이루는 것이 매우 중요하다고 말한다. 평일 ‘프로’답게 일하고, 주말은 업무에서 해방되어 ‘프리’한 상태를 즐기는 것이 그들의 공통점이다. 즉, 일을 잘하는 사람은 노는것도 잘 논다는 말이 맞는 셈이다.5-1) 평일은 프로답게 : 금요일을 찝찝하게 퇴근하지 마라. 두 상황에서의 주말은 극과 극이다. 전자는 주말 리프레시를 위한 힐링의 출발선이라면, 후자는 몸은 집에 마음은 회사인 억울한 주말의 출발선이다. 주말을 주말답게 리프레쉬 해야 상쾌한 월요일 출근이 가능한데 해결하지 못한 업무들을 마음에 담아둔 상태로 주말을 업무 지옥으로 보낸다면 마치 14일 연속 출근하는 기분이 들지도 모른다. 금요일에 일을 완벽하게 마무리하고 퇴근 하기 위해서는 아래와 같은 3set 공식으로 일한다고 하니 참고해보자.월,화요일은 그 주에 가장 중요한 업무의 70% 이상을 몰입해서 다 처리한다고 한다. 월,화에 가장 중요한 업무를 빠르게 해결 해야 비교적 한 주가 여유로워지기 때문이다. 이때는 업무 몰입을 위해 회의, 미팅을 최소화 시기기도 하다. 수,목요일은 후 순위 남은 업무를 처리하면서 좀 더 여유를 가지고 마음으로 다양한 사람들과 회의도 하고 아이디어를 나눈다. 그리고 월+화 업무를 좀 더 디벨롭 시키면 더할 나위 없이 좋다. 마지막 금요일은 한 주를 돌아보는 가장 중요한 시간이다. 그 주의 good & bad를 정리하고 더 나은 차주 업무 계획을 세운다. 5-2) 주말은 프리하게 : 일 스트레스를 날리고, 더 재미있게 일하는 에너지!나에게 주어진 일만 잘 수행한다고 10년, 20년 인정받으며 롱런하는 직장인이 될 수 있을까요? 비즈니스 세계에서 더 인정 받기 위해서는 ‘협업’ 시너지를 잘 내는 것이 매우 중요하다고 생각합니다. 서로의 부족함을 채우고 장점을 극대화 하여 1+1 = 3을 만들 수 있는 1% 협업러가 되길 바랍니다. 마지막으로 최근 협업툴 플로우에서 1,429명 직장인 대상으로 진행했던 의미있는 설문조사 결과 리포트를 공유드리며 본 글을 마무리 하겠습니다.플로우 사용을 경험한 응답자 1,429명은 플로우 사용 전·후 ‘팀 협업’ 만족도와 ‘개인 업무 관리’ 만족도가 크게 개선됐다고 평가했다. 플로우를 사용을 통해 동료와의 협업 만족도는 22점 상승했다. 팀간 실시간 업무 진행 사항 한눈에 파악된다는 점이 긍정적으로 작용된 것으로 판단된다. 개인 업무 관리 만족도는 무려 31점이 상승했다. 응답자 1,429명은 이메일, 단톡방 사용 대신 플로우를 통해 하루 55분의 비효율적인 시간을 단축할 수 있었다고 대답했다.직장인 1,429명의 디지털 업무 경험 결과가 궁금하시다면지금 바로 신청하세요!👉선착순 신청하기

스토리 홈

인터뷰

피드

뉴스

Connecting the Dots

다양한 형태를 지원하는 리스트 UI, 잘 그리고 계신가요?

스타트업이 성공하는 1가지 이유?

우리는 모두 외롭다

[사무실 이야기] 답답해서 해 봤다!! 사무실 셀프 인테리어

스타트업 이야기를 시작하며

스트레스를 주는 상사와 함께 살아가는 법

[모바일 앱분석] Step1. MARKETING (마케팅 분석)

트위터의 이메일 디자인 원칙 3가지

비트윈의 HBase 스키마 해부 - VCNC Engineering Blog

[번역] LEAN 종이비행기 접기 시뮬레이션

그렇게 여행이 시작된다 : 서서울예술교육센터 TA 윤윤상작가

마케터의 일기

[인턴일기] #2. 출근 1달 차

자신만 모르는 자신의 비밀

1% 협업러의 커뮤니케이션 스킬 5가지