모든 개발작업이 그러하듯 본 과정보다 전처리가 중요하다. 음식 만들기 전 재료준비/손질에 대부분의 시간이 소요되는 것과 다를것이 없다.

악마가 될 직원은 뽑지마라

How Leaders Create a High Performance Culture | Ian McClean | Talks at Google

https://www.youtube.com/watch?v=auojtsHPIM8 

The 7 Do's and Don'ts that form an effective leader's operating system! In this talk you will hear from business leader, consultant, facilitator, coach and writer Ian McClean, on how leaders create a winning, dynamic high-performance culture. Founder of Flow Group, Ian has worked with international leaders and organisations to improve their performance for over 25 years. Today he focuses on the neuroscience behind Greenline Communications & the importance of separating intention from impact and how to save time through better interactions. Moderated by Karoline O'Sullivan.

효과적인 리더의 운영 체제를 구성하는 7가지 해야 할 일과 하지 말아야 할 일! 

이 강연에서는 비즈니스 리더, 컨설턴트, 촉진자, 코치 및 작가 Ian McClean으로부터 리더가 성공적이고 역동적인 고성능 문화를 만드는 방법에 대해 듣게 될 것입니다. 

Flow Group의 설립자인 Ian은 25년 넘게 국제 지도자 및 조직과 협력하여 성과를 개선해 왔습니다. 

오늘날 그는 Greenline Communications의 이면에 있는 신경 과학, 의도와 영향을 분리하는 것의 중요성, 더 나은 상호 작용을 통해 시간을 절약하는 방법에 중점을 둡니다. 

Karoline O'Sullivan이 중재했습니다.

반면 또 다른 빅테크인 구글은 선량한 인재를 뽑는 방식으로 이러한 딜레마를 피하려고 해요. 구글은 작년 기준으로 전 세계에 13만9995명에 달하는 직원들을 두고 있는데요. 채용 절차가 까다롭기로 정평이... 특히 직원수가 2만명에 불과할 때도 채용 담당자만 1000명이 넘었다는 도시 전설이 있고요.

일반적인 기업은 적당한 인재를 뽑아서 엄청난 고과를 주고 관리를 하지만, 구글은 반대로 채용에 온 신경을 쓰는 조직이에요. 한때 한 명을 뽑는데 평균 150~500시간을 들인다는 소문도 있었고요. 이를 통해 구글이 얻는 것은? 조직 문화를 망칠 직원이 들어오는 것을 방지하는 것이죠. 크게 세가지 원칙이 있대요.

·         시키지 않아도 자발적으로 한다

·         지적인 겸손함을 발휘한다

·         그럼에도, 머무려는 사람은 차단한다

구글의 선발은 크게 자기반성(Self-reflection)→일자리 찾기→이력서 작성→온라인 제출→인터뷰→선발인데요. 특히 자기반성 부분부터 숨이 턱! 첫문장을 읽어보면? "혹시, 열정을 내고 싶지 않은 일을 잘한적이 있나요? 사실 흥미롭지 않은 일에 성과를 내기는 어렵거든요. 아래 몇가지 중 스스로에 물어보세요."

·         혼자하는 것이 성과가 좋나요? 팀으로 하는 것이 성과가 좋나요?

·         문제를 직접 해결하는 것이 좋나요? 팀워크로 얻는 성과가 많나요?

·         함께 일한 최고의 팀을 설명해 보세요.

이력서를 통과해도 빡센 것은 마찬가지. 인터뷰 절차는? 전화 인터뷰 30~60분씩 두차례. 현장 면접 약 5명과 각각 45분씩 진행. 이 절차를 통과하면 고용위원회에서 적합한 일을 찾아보고, C레벨의 리뷰를 받고 드디어 채용! 이런 과정을 거치다 보니, 실제로 이곳에서 만난 구글러들의 성품은 매우매우 훌륭했어요.

일을 더 잘하게 합시다. - reWork withgoogle.com

구글에서는 설문을 통해 리더들이 9가지 원칙을 점검하는지 스스로를 되묻게 한대요. 한번씩 읽어볼만 해요.

1.     직원들이 성과를 낼 수 있도록 "실행 가능한" 피드백을 주세요.

2.     팀원을 인간답게 배려해주세요.

3.     세세하게 관리하지 마세요.

4.     관점이 달라도 존중해 주세요.

5.     결과를 달성하도록 해주세요

6.     정보사항을 제대로 공유해 주세요

7.     더 나아가, 팀원들의 경력이 쌓일수 있도록 멘토링해주세요

8.     목표치 명확하게 전달해 주세요.

9.    이제 당신은 훌륭한 리더입니다.

https://rework.withgoogle.com/

일을 더 잘하게 합시다.

re:Work는 사람을 최우선으로 생각하는 데 도움이 되는 Google 및 기타 업체의 사례, 연구 및 아이디어 모음입니다.

re:Work with Google에 대해 자세히 알아보세요. 

• 목표 설정목표를 설정하여 노력을 조정하고, 목표를 전달하고, 프로세스를 측정합니다.
• 고용직무 설명, 구조화된 인터뷰, 고용 위원회 등을 통해 더 나은 고용 결정을 내립니다.
• 혁신혁신을 위한 기술을 구축하고 이를 직장의 일부로 만드는 방법을 배우십시오.
• 학습 및 개발학습을 모든 사람의 업무의 일부로 만들어 직원이 성장하고 발전할 수 있도록 역량을 강화하십시오.
• 관리자무엇이 훌륭한 관리자인지 파악하고 피드백과 개발 기회를 제공하십시오.
• 사람 분석과학과 데이터를 사용하여 정보에 입각한 객관적인 결정을 내립니다.
• 팀팀 효율성과 심리적 안전을 촉진하는 방법을 검토합니다.
• 편향되지 않음모든 사람을 교육하고, 측정하고, 책임을 지도록 함으로써 무의식적 편견의 영향을 줄입니다.

SSO(Single Sign-On) 구현을 위한 토큰(Token)의 활용

ID/PW 로그인
AccessToken / RefreshToken 생성
AccessToken 소멸하면 RefreshToken으로 인증서버에 AccessToken 재요청
RefreshToken 소멸시 재로그인
 * JWT(JSON Web Token)
 * Token은 Base64 Encoding으로 한다. 토큰에 서명(signiture)부분을 추가해서 서명에 비밀키를 사용. 

====================================================================

SSO(Single Sign-On)는 무엇인가?

SSO(Single Sign-On)은 한 번의(Single) 로그인 인증(Sign-On)으로 여러 개의 서비스를 추가적인 인증 없이 사용할 수 있는 기술이다. 인증은 하나의 시스템(인증 서버)에서 수행하고, 그 인증 서버가 서비스를 각각 담당하는 서버에 인증 정보를 알려주는 방식이다.

주로 다양한 서비스를 유사한 도메인 혹은 동일한 탑 레벨 도메인(TLD:Top Level Domain)을 서비스하는 엔터프라이즈 서비스 제공자들이 사용자에게 간편한 로그인을 제공하기 위해 사용한다.

예를 들면, 이런 흐름이다.
① www.samsung.com에서 로그인을 하면, 인증 서버 account.samsung.com으로 이동한다.
② account.samsung.com에서 로그인을 성공하면 다시 www.samsung.com으로 돌아온다.
③ 삼성의 다른 서비스에 접속하면, 별도의 추가 로그인 없이 이미 로그인된 상태로 서비스를 즐긴다.

같은 맥락으로 Gmail에 Google 계정으로 로그인을 하면, YouTube나 Google Drive는 별도 로그인 없이 Gmail 로그인에 사용한 구글 계정을 동일하게 사용하는 것도 SSO 기술이다.

SSO를 구현하기 위한 기술 요소는?

SSO를 구현하려 한다면 인증 서버를 준비하고, 이를 다양한 서비스들과 어떻게 인증 관련으로 연계할지 설계해야 한다. 인증 서버에서 인증을 성공적으로 마쳤다는 '증거'를 다른 서비스들이 어떻게 믿게 만들 것인지에 대한 기술적 고민도 필요하다.

기업 내 솔루션에서 SSO는 전통적으로는 모든 사용자(직원)의 인증 정보를 담고 있는 AD(Active Directory)이나 LDAP(Lightweight Directory Access Protocol)을 적용한 솔루션들을 많이 사용해왔다.

SSO의 직접적인 구현을 위해서 여러 가지 방법이 있겠지만 이 글은 인증 토큰(authentication token)을 사용한 SSO 방식에 대한 글이다. 여기서 토큰이란, 최초 인증이 성공한 사용자에게 일종의 증표로 인증 서버가 발급하는 정보다.

예전의 웹 개발에서는 로그인에 성공한 사용자는 웹 서버와 Session을 맺고, SessionID 정보를 쿠키로 받아, 그 쿠키를 로그인의 증표로 사용하였다. 모든 요청 헤더에 SessionID 쿠키를 넣고 웹 서버에 접속을 하면, 웹 서버는 서버에 보관한 Session 정보와 비교하여 유효하게 로그인한 사용자임을 확인하고 콘텐츠를 제공하는 방식이었다. 매번 요청마다 서버가 Session 정보를 확인해야 하는 부담, 서버가 Session 정보를 어디엔가(DB 혹은 Redis) 저장해야 하는 번거로움과 복잡한 구현 방식이 단점이라 할 수 있다.

이에 반해 토큰 방식은 Session 방식과 다르게 서버가 각각 로그인한 사용자의 세션 정보를 따로 보관하지 않는다. 한번 인증 토큰이 클라이언트에게 발급하면, 클라이언트는 추후 요청부터는 그 토큰을 포함하고, 서버는 클라이언트 요청에 포함된 토큰을 그때그때 확인할 뿐이다. 현재 Facebook, YouTube를 비롯한 소셜미디어, 포탈, 이커머스 서비스처럼 가입자 기반의 로그인 인증이 필요한 서비스들이 토큰 인증 방식을 많이 사용하고 있다.

초기에는 SSO가 저변화되면서 많은 서비스들이 SSO 상용 서비스에서 제공하는 SAML(Security Assertion Markup Language) 방식을 사용하였다. SAML은 XML 형태의 마크업으로, 간단한 정보 전달을 위해 많은 태그가 사용되는 비효율성이 있다. 그 이후부터는 SSO에서도 토큰을 사용하고 있다.


토큰을 사용한 SSO 서비스 다이어그램 

SSO에서 세션과 토큰을 어떻게 사용하는지 아래 다이어그램으로 이해해보자.

① 사용자는 Service1에 접속하여 로그인 버튼을 클릭한다.
② Service1은 인증 서비스(idP: Identity provider)로 해당 요청을 Redirect 한다.
③ 인증 서비스는 사용자에게 로그인 화면을 제공한다.
④ 사용자는 ID/PW (혹은 OAUTH2.0)을 입력한다.
⑤ 인증 서비스는 회원 DB와 비교하여 ID/PW가 올바르면 인증 토큰을 발급하며 Service1으로 돌려보낸다.
⑥ Service1은 발급된 토큰을 확인하고, 올바른 토큰이라면 사용자의 로그인 처리를 해준다.
⑦ 사용자는 Service2에 접속한다.
⑧ Service2는 이 사용자의 세션이 아직 유효한지 확인하고 유효하다면, Service2 용도의 토큰을 발급한다.
⑨ Service1은 발급된 토큰을 확인하고, 올바른 토큰이라면 사용자의 로그인 처리를 해준다.


여전히 세션이 필요한 이유는 한번 발급된 토큰만 믿을 수없기도 하고, 일반적으로 토큰은 짧은 유효 시간을 갖는데 비해, 서버에는 세션 정보를 오랫동안 보관하고 그 기간 내에 재접속한 사용자를 지원할 수 있기 때문이다.


유효 시간이 만료된 토큰 사용자가 다시 로그인하는 것은 불편하니, 다음과 같은 방법을 사용한다.

- 인증 서버는 ID/PW를 DB에서 확인하고, 정상 로그인이면 AccessToken과 RefreshToken을 발행한다.
- AccessToken은 exp가 짧다. 만료되면 RefreshToken으로 인증 서버에게 AccessToken를 재요청한다.
- RefreshToken은 exp가 상대적으로 길고, 인증 서버의 세션 정보를 포함한다.
- AccessToken 재요청을 받은 인증 서버는 RefreshToken과 세션 정보를 비교 후 재발급해준다.
- RefreshToken 마저 유효 시간이 지나면, 사용자는 다시 ID/PW 로그인을 해야 한다.

한번 로그인했던 Facebook이나 YouTube의 로그인이 상당 기간 필요 없는 것은 위의 방법을 사용하기 때문이다. 브라우저의 쿠키와 temporary internet folder를 삭제하면 모든 토큰은 삭제된다. 때에 따라 AccessToken을 cookie에 저장하고, cookie는 브라우저가 닫히면 삭제되도록 설정할 수도 있다.


토큰에는 어떤 정보가 있고 어떻게 확인하나?

여기에서의 핵심은 토큰이 어떤 정보를 가지고 있고, 각 Service1과 Service2가 유효한 토큰임을 어떻게 확인할 것인지에 대한 디자인이다. 토큰의 종류는 여러 가지이지만 예제에선 JWT(JSON Web Token)을 사용하였다.

① 인증 서버(idP)와 각 Service 서버들은 사전에 비밀키(private key)를 공유한다.
② ID/PW로 정상적인 인증이 확인되면, 인증 서버는 토큰에 이메일, 이름, 유효 시간 등을 입력하여 발급한다.
③ 토큰을 Base64 Encoding 한다. 암호화가 아닌 인코딩이기 때문에 내용은 누구나 알 수 있다.
④ 토큰에 서명(signature) 부분을 추가하여 위 변조를 방지한다. 서명에 비밀키를 사용한다.
⑤ HTTPS 보안 채널로 토큰 확인을 요청한다. 토큰이 유실되더라도 비밀키가 없는 해커는 내용을 변조할 수 없다.
⑥ Service 서버는 비밀키로 토큰 변조 여부를 확인하고, email 등의 사용자 정보 확인 후, 인증 처리를 해준다.

이 방식의 장점은 가벼운 토큰을 사용하여 인증 처리 작업을 하는 서비스들이 부담을 갖지 않는 구조이고, 비밀키 없이는 토큰을 변조하지 못한다는 보안성이다.

단점은 아무리 HTTPS로 토큰을 보낸다고 하더라도, 중간자 공격 등으로 토큰을 훔친 해커는 토큰을 변조하지 않고 그대로 사용한다면, 로그인한 사용자와 동일하게 보일 수 있다는 보안 취약점이다. 그래서 User-Agent 혹은 IP 주소를 확인한다거나, 추가적인 여러 가지 보완책을 마련해야 한다. Naver 서비스의 경우, AccessToken이 유효하더라도 사용자의 IP 주소가 바뀌면 다시 로그인을 하도록 하는 것도 이런 이유 때문이다.


SSO(Single Sign-On) 구현을 위한 토큰(Token)의 활용 : https://brunch.co.kr/@sangjinkang/36

NPS의 개념

NPS(Net Promoter Score : 순수 고객 추천 지수) 란?    고객 순추천 지수 프레임워크

• 추천 의향 문항을 11점(0~10점) 척도로 측정하여 ‘추천고객 비율(Promoters %)’에서 ‘비추천고객 비율(Detractors %)’을 빼서 NPS를 산출합니다. 
• ‘당신은 A 제품/서비스를 친구나 동료에게 추천할 의사가 있습니까?’ 라는 질문이 기본
• ‘추천 의향’이라는 단 하나의 문항으로 고객의 서비스 로열티를 측정
• 이론적으로 점수 범위는 -100점부터 +100점까지
• 선택적으로 ‘해당 점수를 선택한 이유’를 묻는 문항을 추가하기도 함

NPS는 ‘추천 의향’이란 질문 단 하나로 고객의 실제 만족도를 파악할 수 있습니다. 문항이 짧아 고객으로부터 답변을 받기도 용이하며, 문항과 척도가 동일하기 때문에 경쟁사 및 업계 평균을 비교하여 자사의 현재 입지를 쉽게 파악할 수 있습니다. 이렇게 보니 NPS를 도입하는 장점이 한가득이죠? 게다가 NPS는 많은 기업이 채택하면 채택할수록 내가 얻는 업계 평균 서비스 만족도 정보도 많아지니 얼른 주변에도 널리 알려주세요.

NPS의 3가지 고객 유형

NPS에서는 앞서 잠깐 언급한 것처럼 고객군을 3가지 유형으로 나눕니다. Promoters / Passives / Detractors 입니다. 3개로 나누어지는 고객군을 기반으로 NPS 결과를 분석합니다. 

https://blog.jandi.com/ko/2018/11/07/what_is_nps/

KubeSphere DevOps: A Powerful CI/CD Platform Built on Top of Kubernetes for DevOps-oriented Teams.

https://kubesphere.io/devops/