해당 글은 벨로그 저자 city7310 님의 글 5개를 참조하였습니다. 상업적 목적은 전혀 없고 너무 좋은 글이라 참조합니다.

안녕하세요 저번에는 리더쉽 관련 세미나를 했었는데 이번에는 "실무자" 버전으로 한 번 가져와봤습니다!

이전 회사에서 저는 실무적인 개발업무를 하기도 했고 개발자를 채용하는 포지션이이기도 했는데요. 그러면 적지 않은 개발자 이력서를 보았습니다. 자기 자신을 표현하는 첫 줄에는 높은 확률로 "저는 함께 일하고 싶은 개발자" 입니다 이거나 혹은 "함께 일하고 싶은 개발자"가 되고싶다 였습니다.

그렇다면 "함께 일하고 싶은 개발자", 비단 개발자 뿐만이 아니라 "함께 일하고 싶은 사람" 은 어떤 사람일까요?

조직마다 자신들의 가치관을 다루는 core value나 Leadership principle 을 장착하고 있습니다 Tesla의 The Anti-Handbook, Netflix의 Culture나 The Rare Responsible Person, Amazon의 Leadership Principles 같은 것처럼 말입니다.

전에 다니던 회사는 완전한 core value 나 leadership principle 이 없었습니다. 회사 문화와 복지, 인재상을 정리해둔 것 노션 페이지를 제가 만들었긴 했지만 조금 추상적이였습니다.

"좋은 동료가 최고의 복지" 라고 많이들 이야기합니다. 그렇다면 좋은 동료는 어떤 사람일까요??

이거 궁금하셨죠?

커뮤니케이션을 잘 해야 한다는 이야기가 많지만, 조금 답답한 주제입니다. 도대체 무엇이 "좋은 커뮤니케이션"을 결정하는 것일까요?

기본적으로 회사 동료는 서로 남이라는 것을 인지해야 합니다. 그러니까 회사 동료를 대할 때 나에게 대하는 것 처럼 하면 안된다는 것이죠. 자신의 상태를 공유하는 것은 협업의 기본입니다. 일이 잘 진행되고 있는지, 장애물이나 위험 신호는 없는지와 같은 것 말이에요.

여기에 더해, 누군가 물어보기 전에 먼저 답을 제출하는 사람이 있습니다. ‘이거 궁금하셨죠?’ 라고 하는 것 처럼요. 이러한 선제적 대응은 커뮤니케이션을 비롯한 대부분의 협업 과정에서 긍정적인 효과를 줍니다.

• ‘작업 어떻게 돼가요?’, ‘앞으로의 계획이 무엇인가요?’ 같은 질문을 받기 전에, 먼저 상황을 공유하는 것

• 피드백이 있을 법한 부분에 본인의 의사결정 흐름을 미리 첨언하는 것

• 확인 여부를 최소한 ✅ 와 같은 이모지로 응답하는 것

• 요청을 언제까지 처리할지, 또는 언제까지 상황을 공유해줄지 ETA를 알려주는 것

• 질문에 대한 시급도를 명시하는 것

옳은 일을 위해 누구와도 대화할 수 있는 사람

예전에 회계팀에서 정장입고 일할 때 막연하게 ‘높은 사람’들을 막연하게 무서워했던 것 같습니다. 회사에 대한 나쁜 환상이 있었던 건지, 나이 차이가 많아서 였는지.. 뭔가 문제를 제기하면 혼날 것 같아 자신있게 말하지 못했던 기억이 납니다. 사실 자신있게 말하고 많이 혼났던 기억이 나네요 ㅎㅎ

회사에 있는 사람들은 모두 mission을 달성하기 위해 모인 사람들입니다. 특히 스타트업은 더욱 더 그렇습니다. 눈치보지 않는 것을 넘어서, 회사 전체의 이익을 위해 누구와도 대화할 수 있는 그런 사람이 좋습니다. 옳은 일이 일어나도록 하기 위해 CEO와도 대화할 준비가 되어있는 사람과 함께 일하고 싶습니다.

이 부분은 Tesla의 The Anti-Handbook에 포함된 Communication 항목과도 닿아 있는 것 같습니다.

근거 있는 대화

똑같은 의견이라도 ‘아마 그럴 것 같아요’같은 추정은 근거가 될 수 없습니다. 데이터를 가져와 근거를 보충하고, 우리의 상황에 맞는 실험 결과를 덧붙이는 식으로 의견을 견고하게 만들어야 합니다. 이야기보다 사실을 전달해야 합니다.

그렇게 습관이 만들어지고 나면 옆자리 동료와 대화할 때도 충분한 검증을 거친 주장을 할 수 있게 됩니다. 대화가 붕 떠버려 아무 결론도 안 나는 것보다, 건설적인 토론이 항상 좋습니다.

이런 사람들은 참 소중합니다. 잠깐만 대화를 나눴는데도 혼자 삽질하던 문제가 해결되고, 우리 시스템을 개선할 수 있는 아이디어가 나오곤 합니다.

독성 말투가 없는

비난하지 말라는 이야기가 아닙니다. 개선하려는 시도조차 없이 뒷담을 하거나, 나이를 알고 반말하는 사람들, 말 끊는 사람들, 감정을 드러내는 사람들, … 이렇게 어른스럽지 못한 사람들과는 함께하는 건 좋지 않은 것 같아요.

요지는 커뮤니케이션에 배려를 담자는 이야기입니다. 배려 없는 대화의 핑계로 ‘효율적인 커뮤니케이션을 한다’, ‘나는 컴퓨터랑 대화하는 사람이다’ 같은 말을 들을 때가 있습니다. 그 있잖아요, 드라마나 영화에 차갑고 4가지 없는데 일 잘하는 캐릭터 솔직히 그냥 쏘시오패스거나 무책임한 사람처럼 보입니다. 사회성 문제로 병원을 다닐 정도가 아니라면, 동료와 팀에게 말로 피해를 끼치는 것은 금기시되어야 합니다.

독성 말투는 은연중에 조직에 해를 주게 됩니다. 말 하나에 팀워크가 깨지고, 팀 전체의 사기를 저하시키기도 합니다. ‘말’에 대한 속담이 많은 이유가 있는 것 같습니다.

사실 이것은 독성 말투가 무엇인지를 인지하는 것에서 반은 먹고 들어가는 것 같습니다. 독성 말투라는 게 생각보다 허들이 높기 때문입니다. 다음은 독성 말투의 목록을 정리한 것입니다. 듣는 입장에서 어떻게 들리는지, 그리고 개선된 말투는 무엇인지 이어붙였습니다.

“왜 이렇게 하셨나요?”

듣는 입장 : “도대체 왜 이렇게까지밖에 못 했나요? 이것보다 나은 옵션이 얼마나 많은데?” 개선된 말투 : “이렇게 판단한 이유가 있을까요? 의사결정 과정이 궁금합니다.”

“이해가 안 되시나요?”

듣는 입장 : “제가 이렇게까지 설명했는데도 이해가 안 되는 게 저도 이해가 안 되네요. 얼마나 더 쉽게 설명해드려야 하나요?” 개선된 말투 : “어떤 부분이 어려운지 알려주실 수 있나요? 그 부분부터 좀 더 설명해드릴게요”

“이거 아직도 안 되고 있나요?”

듣는 입장 : “일을 하고는 있는건가요? 혹시 놀고 있는 건 아니죠?” 개선된 말투 : “이 작업이 진행되지 못하고 있는 원인이 있을까요? 어떤 지원이 필요한가요?”

너무나도 직선적인 성격이라 어렵다면, 그냥 말 앞에 ‘혹시’만 붙여줘도 문장이 훨씬 부드러워집니다. “혹시 왜 이렇게 하셨나요?”, “혹시 이해가 안 되시나요?” 처럼 말입니다.

기본적으로 내가 잘못했을 가능성을 기저에 깔아놓고 대화해야 한다고 생각합니다. 과거에 "왜 기계 데이터 프로토콜 협업회사 개발팀에게 전달 안했냐" 라는 말을 들었던 적이 있습니다. 그러나 저는 어떠한 이메일도 받은 적이 없었고, 알고 보니 기획팀이 저에게 CC 를 안 걸어서 전송되지 않았던 것이었습니다.

신경질은 낼 수 있다고 봅니다. 오늘따라 일이 참 안 풀리는데, 오늘따라 다들 나를 찾으면 힘들긴 합니다. 그런데 그게 기본값인 사람들은 당연히 좋지 않습니다. 감정을 숨기고 이성으로 배려를 담아 대화하는 것, 적어도 그러려고 노력하는 사람이 좋습니다.

안 되는 이유보다, 되게 하려면 필요한 리소스를 제시

안 된다는 말은 가장 마지막에 나와야 합니다. 새로운 아이디어를 어떻게 만들어낼 수 있을 지 고민하는 것이 당연히 먼저입니다. 본능적으로 안 되는 이유부터 생각하는 사람들은, 일 하기 싫어 핑계대는 사람으로 보입니다.

‘안 되면 되게 하라’는 말이 있습니다. 가혹하게 들릴 지 모르겠지만, 안 되는 걸 열심히 비틀어서 어떻게든 되게 만드는 사람은 영웅과도 같습니다. 또한, 일을 되게 만들기 위해 팀원 모두 도와줄 준비가 되어 있어야 합니다.

기획자가 원하는 아이디어를 그대로 만들어내는 것은 당연히 어렵습니다. 구현 난이도가 높거나 우선순위 문제로 일정을 못 맞출수도 있고, 기술적인 문제로 기획자가 원하는 퀄리티가 나오지 못 할수도 있습니다.

이런 문제는 대화를 통해 원만하게 해결되곤 합니다. 기획자는 기술적인 세부 사항에 대해 완벽히 알지 못하므로, 구현 난이도를 측정하기 어렵기 때문입니다. “이래저래 해서 어려워요” 하면, “아 정말요?! 그렇게 구현이 어려운 기능인지 몰랐어요. 이건 그냥 spec-out 해도 돼요” 같은 답변을 받았던 기억이 많습니다.

일이 되게 만들기 위해 어떤 리소스나 변화가 필요한지를 제시하고 얻어내는 사람이 좋습니다. 때로는 설득도 필요하고, 토론도 필요합니다. 그런 과정을 거쳐 어떻게든 결과물을 만들어낼 수 있게 준비하는 모습은 정말 프로정신이 강한 사람으로 느껴집니다.

꽤나 강조하고 싶은 역량입니다. 작업이 시작되기 전부터 머리를 핑핑 돌리며 견적을 내서 대략적인 일정을 내놓고, 설득을 위한 커뮤니케이션이 되는 사람이면, 세세한 코칭 없이 일하게 해도 되겠다는 생각이 들기 때문입니다. 신뢰하는 만큼 자유를 부여하게 되는데, 이런 사람들은 자유를 얻기도 쉽습니다.

문제를 해결하고 나면, 원인을 파악하고 재발방지

“이 코드 누가 짰어!”

무서운 말입니다. 범인을 찾으려는 행동입니다.

문제가 발생했을 때 개인의 실수를 비난하지 않고, 실수가 발생하지 않는 시스템을 만드는 데에 집중하는 포스트모텀(postmortem) 문화가 필요합니다. 포스트모텀에 대해서는 "사고를 쳐도 혼나지 않는 회사라는 글"을 읽어보면 좋을 것 같습니다.(링크있습니다)

소프트웨어 개발은 모든 행동에 리스크가 있는, 위험이 도사리는 분야입니다. 마음가짐이나 규칙같은 것으로 문제를 방어하려는 것은 정말 위험한 행동입니다. 문제가 발생하는 것은 사람의 역량 문제라기보단 시스템의 문제라고 봐야 합니다. ‘실수한 게 당당하고 자랑이냐’고 하면 물론 아닙니다. 조심해야 하는 건 맞지만, 소프트웨어 시스템은 겨우 조심하는 정도로 방지가 되는 복잡성이 아니라서 그렇습니다. 범인을 찾고 사람을 타박하는 분위기에서는 팀이 100%의 역량을 발휘하기 어렵습니다.

“죄송합니다”는 사람의 기분을 풀어주기 위한 말입니다. 아무리 사과해도 소프트웨어는 바뀌지 않습니다. 중요한 건 재발 방지입니다. 실수를 했다는 것은 개인적으로 아쉽고 분한 일입니다. 하지만, 나중에 동료가 똑같은 실수를 하지 않게 만드는 것이 이상적인 모습입니다.

‘앞으로 안 그래야지’하고 마음먹기만 하는 사람보다, 재발 방지를 위해 노력해본 사람과 함께 일하고 싶습니다.

동료의 피드백으로 자신을 평가하는 사람

Co-worker, 동료 로서의 잘잘못은 ‘남이 보는 나’를 통해 평가하는 것이 좋습니다. 속히 말해 눈 가리고 귀 막는 사람들은 받아들이기 어려운 것 같습니다.

주변에서 ‘잘 했다’고 해도, 그렇게 생각하지 않고 자기 자신을 채찍질하는 사람이 있습니다. 최고 점수를 받아도 그동안의 성과 때문이라고 생각하질 않습니다. 자신이 기대를 받고 있는 것으로 받아들이고, 앞으로 더 잘하라는 격려로 받아들이곤 합니다. 이건 그래도 괜찮습니다. 제 주변에도 이런 동료들이 있는데, 달려나가는 걸 가로막을 수는 없으니 지치지 말라고만 응원해주고 싶습니다.

반대로, 주변에서 ‘못 했다’고 해도 그것을 자신에 대한 공격으로 받아들이고 꽁꽁 숨어버리는 사람이 있습니다. 당연히 부정적인 피드백은 아픕니다. 앞으로의 업무에 있어서 멘탈 관리를 위해 잠깐 방어적으로 생각하는 것은 괜찮지만, 결국은 발전을 위해 납득해야 하는 소중한 의견들입니다. 아무리 남이라고 해도, 동료에게 부정적인 피드백을 전달하는 것은 쉽지 않은 일이기 때문입니다. 피드백은 누군가의 의욕을 저하시키기 위함이 아니라, 다 같이 잘 하기 위함이라는 것을 인지해야 합니다.

Strong View, Weakly Held, Followership

We are trying to prove ourselves wrong as quickly as possible, because only in that way can we find progress! 우리는 가능한 한 빨리 틀렸음을 증명하려고 노력합니다. 그래야만 발전을 찾을 수 있기 때문입니다.

노벨 물리학상을 수상한 리처드 파인만의 명언입니다. 대부분의 조직은 가장 나은 방법을 찾고자 토론을 합니다. 여기서 토론이 올바른 방향을 찾아가기보다, 자신의 의견이 채택되는 것을 더 중요하게 여기는 사람이 있습니다.

자신이 낸 의견이 채택되지 못하면 아쉽습니다. 덜 기여한 것 같고, 도움되지 않는다는 생각이 들기도 합니다. 자신의 의견이 완벽하다고 굳게 믿고 있었다면 조직에 대한 신뢰를 의심하게 되기도 합니다. ‘이렇게 좋은 의견을 받아들이지 못 하다니’ 하며 조직의 수준에 의문을 갖습니다. 합당한 이유가 있어서 반려된 것인데도 말입니다.

하지만 협업에 있어서는, 이렇게 방어기제가 발동하는 것은 좋지 않습니다. 내 의견이 좋아보이는 것은 확증편향과 관련되어 있습니다. 자기 생각과 일치하는 정보만 받아들이고, 다른 생각은 배척하는 심리입니다. 의견이 신념이 되어버리기 전에, Weakly Held할 수 있도록 태도를 바꿔야 합니다.

좋은 동료들은 의견을 최초로 제시하기까지 오랜 시간을 갖습니다. 그리고 의견을 제시한 뒤에는 근거를 더 뒷받침하려고 하지 않습니다. 대신 다른 의견, 되도록이면 자신의 것과 상반되는 의견의 근거를 찾아보는 과정을 거칩니다. 그렇게 학습하고 나면 생각을 고수할지, 생각을 바꿀지 결정합니다.

무조건 양보하라는 것은 아닙니다. 자신의 의견에 자신감을 갖고 주장하는 것은 당연히 좋고, 자신감이 생길 만큼 충분한 논거를 쌓는 것은 의무라고 생각합니다(Strong View). 그러나 토론에서는 내 의견과 남의 의견을 나누어 생각하는 것보다, 주어를 빼고 모든 의견이 단순한 선택지라고 생각하는 모습이 필요합니다. 자기 의견의 근거를 찾아보는 만큼, 다른 의견의 근거를 찾아봐야 더 객관적일 수 있습니다(Weakly Held).

근거가 바뀌면 의견도 바꾸는 유연한 모습이 있어야 합니다. 생각이 자주 바뀌는 것을 나쁘게 생각할 필요는 없다고 봅니다. 가설로 채워야 하는 부분이 있기에, 의견이 갈리는 것은 당연합니다. 때문에 처음부터 100점짜리 정답을 찾아낼 수는 없습니다. ‘이런이런 근거 때문에 내가 생각을 바꿨다’로 마무리되는 토론이 바람직하다고 생각합니다.

토론이 끝나면 그 결과에 관계 없이, followership을 가지고 일이 잘 될 수 있도록 지원하는 사람이 좋습니다. 팀 플레이어로서 꼭 필요한 역량입니다. 선심쓰듯 양보하는 것 처럼 한다거나, 자기 의견대로 안 됐다고 토라져 아무 도움도 안 주다가, 그 방법이 틀렸다는 것이 드러나면 ‘거 봐라’ 하는 모습은 정말 보기 안 좋습니다.

‘내가 틀리진 않았을까’ 생각하며, 자기 자신과의 토론을 해왔던 사람이 이런 부분에서 좋은 모습을 보여주는 것 같습니다. 애초에 양질의, 정답에 가까운 의견을 내기도 하고 말입니다.

선의의 경쟁

회사가 성장하는 속도와 개인이 성장하는 속도는 확연하게 다릅니다. 당연히 회사가 성장하는 속도가 더 빠릅니다. 우리들이 으쌰으쌰해서 회사가 엄청 성장하고 돈을 더 벌면 회사는 그 돈으로 지금 우리보다 더 높은 값어치의 인원들을 고용합니다.

팀의 평균 수준을 상회하는 동료가 들어올 때마다, ‘저 사람이 금방 나를 대체할 수 있겠다’ 같은 생각이 들 수도 있습니다.

이때 새로운 동료와 경쟁하려 하지 마세요. 퍼포먼스를 내지 못 하게 상대방을 견재하는 태도는 전혀 프로답지 못합니다. 동료에게 과하게 높은 챌린지를 주문하거나, 아이디어를 실행한 공을 독차지하려 욕심부리거나, 조력자의 도움을 감사하게 여기지 않고 혼자 빛나려는 사람들처럼 말입니다. 다른 사람을 빛을 밟아 자신의 빛만 빛나도록 자존감을 채우는 사람과는 함께하고 싶지 않습니다.

물론 어려운 일입니다. 내가 3년 혹은 5년동안 열심히 키운 내 프로젝트인데, 새로 들어온 능력좋고 탁월한 동료가 왈가왈부하면 머리로는 이해해도 마음으로는 힘들 수 있습니다. 그래도 받아드려야 합니다.

아무리 경쟁심리 없는 사람이라도, 남들보다 뒤처져있는 걸 편하게 느낄 사람은 없습니다. 잘 하는 사람이 주변에 널려 있으면 자존감이 많이 내려갑니다.

재능의 차이를 빠르게 인정하고, 자신의 capacity 안에서 할 수 있는 최선을 하다 보면 나아지는 것 같습니다. 과도하게 열심히 할 것도 없고, ‘매일 1%씩 나아진다’ 같은 말처럼 습관화된 의식적 연습이 성장을 불러왔던 기억이 납니다.

우수한 사람이라면, 혼자 고고하게 잘나려고 하기보다 모두가 잘할 수 있도록 만들어주는 사람이 좋습니다. 팀워크를 위해, 그리고 서로가 자존심 싸움이 아닌 성장을 위한 진짜 경쟁을 할 수 있게 말입니다.

거짓말하지 않는 사람

다들 회사에서 어떻게 거짓말을 하나 싶으시죠? 하지만 거짓말은 빈번하게 일어납니다. 어려운데 이해했다 하고, 어렵다고 말하지 못 하는 것, 나쁜 소식을 전달하지 않고 숨기는 것 모두 거짓말입니다. 자신의 상태를 숨김 없이 정확히 이야기하는 것은 협업에 정말 중요합니다.

소프트웨어도 그렇듯, 모든 수정과 교정은 나중에 일어날 수록 비용이 높습니다. 설명해준 지 한 달이 지나 “사실 잘 모르겠어요” 하면, 답변자 입장에서도 당시의 내용을 꾸역꾸역 찾아내 머리로 다시 떠올려야합니다. 서로 불편한 상황이 발생하는 것입니다.

참조:

지금 시간이 점심먹고 딱 졸릴때라 일부러 이때로 했는데요. 미용실에 머리하러 왔다~ 생각하시고 편하게 졸면서 들어주시면 됩니다 중간중간 나오는 짤은 너무 졸리실까봐 재미로 제가 중간중간 넣은 짤이니 세미나 본문과 상관없습니다 ㅎㅎ 시작해봅시다

챕터 5의 주제는 팀 이끌기 입니다.

이번 장의 주제는 사람 관리와 리더쉽입니다만, 여러분이 개인 기여자 (팀원) 이라해도 이 세미나를 봐두면 좋을 것이라 생각합니다. 여러분의 리더를 이해하는데 조금은 도움이 될 테니까요 :) 그리고 여러분도 미래에 리더가 되실테니까요! 그리고 여러분이 비개발팀이라도 충분히 다른 직군에 투영하셔도 무방하다고 봅니다 ㅎㅎ

거시적인 측면에서 엔지니어링 관리자는 자신이 관리하는 팀의 구성원 모두의 성과 & 생산성 & 행복을 책임져야 합니다.

그와 동시에 팀에서 만드는 제품의 사업적 요구까지 충족시켜야 하죠

공식적으로 임명되든 아니든 누군가는 운전석에 앉아야 제품이 어느 방향으로든 나아갈 수 있습니다. 스스로는 팀 내 갈등을 해결하고 결정을 내리고 사람들을 조율하는 데 소질이 없다고 생각할지도 몰라요. 하지만 어쩌다 보니 리더가 되어있는 상황은 아주 흔합니다. 리더가 될 의사가 전혀 없었더라도 말이죠.

여러분 스스로 "난 절대 관리자는 되지 않을꺼야" 라고 맹세했더라도 경력이 쌓이다 보면 어느 순간 리더의 위치에 올라서 있는 자신을 발견하게 됩니다. 주어진 역할을 성공적으로 완수한 사람일수록 더 그렇죠. 이 장의 나머지는 이런 상황이 닥쳤을 때 무엇을 해야하는지를 이해하는데 도움드릴 목적으로 세미나를 합니다.

여러분에게 관리자가 되라고 설득할 의도는 없습니다. 그대신 최고의 리더가 겸손, 존중, 신뢰라는 원칙 하에서 팀을 지원하는 이류를 보여드리고자 합니다. 프로젝트라는 배를 그저 해류를 따라 표류하게 두지 않으려면 항해술을 익혀야 합니다.

사람들 대부분이 "관리자"라는 단어를 불쾌해 합니다. 소프트웨어 개발 분야에서 가장 큰 이유는 바로 코딩할 시간이 크게 줄어든다는 점입니다.

경력 대부분을 코딩하며 보낸 사람이라면 하루의 끝에서 작성한 코드, 설계문서, 해결한 버그더미 등을 가르키며 "오.. 오늘 일 빡시게 잘했네" 라고 할수 있습니다. 하지만 "관리" 일로 바삐 보낸 하루의 끝에서는 "오늘 한 일이 하나도 없군" 이라고 생각하게 되는 경우가 허다합니다.

이는 마치 매일 사과를 선별하는 일을 수년간 해온 사람이 바나나 재배업으로 전업한 후 "오늘은 사과를 하나도 선별하지 못했군" 하고 푸념하는 꼴입니다. 관리 업무를 수량화하기는 기능 제작보다 까다로운게 사실입니다. 하지만 관리를 통해 팀에 활기를 불어넣고 생산성을 높일 수 있습니다. 바나나를 재배하면서 사과를 세는 함정에 빠지지 마세요!

관리자들에게는 일종의 질명이 있는 듯 보입니다. 선임 관리자가 자신에게 했던 끔찍한 일들을 새까맣게 잊고, 자신도 어느것 똑같은 식으로 사람들을 "관리"하게 되는 병입니다. 이 병의 증상에는 마이크로매니징, 저성과자 방치하기, 만만한 사람 고용하기 등이 있습니다. 적절히 치료하지 않으면 팀 전체를 죽일 수 있는 질병이죠.

이번 챕터의 중요 핵심 문장입니다. "무엇보다도 관리하려는 충동을 이겨내야해요" 관리자는 직원들을 능동적으로 "관리"하려는 충동에 휩싸입니다. 그것이 관리자가 하는 일이잖아요? 하지만 그 결과는 보통 재앙으로 이어집니다.

"관리"병을 치료하려면 섬기는 리더쉽을 자유롭게 응용해야합니다. 리더로서 여러분이 해야 할 가장 중요한 일은 팀을 떠받드는 것입니다. 마치 집사가 가정의 안녕과 건강을 챙기듯이요.

예컨대 팀원이 혼자서는 제거할 수 없는 관료적 장애물을 치워주고, 팀이 합의에 이르도록 도와주고, 누군가 늦게까지 야근할 떄는 저녁을 사주는 일이 될 수도 있습니다. 섬기는 리더는 팀이 나아가는 길앞의 균열을 메우고 필요할때 조언해줍니다.

섬기는 리더가 행하는 "관리"는 오직 팀의 기술적, 사회적 건강 관리뿐입니다.

구글 엔지니어링 관리자에게 주어진 주요 책임들을 이야기하기 앞서, 잠시 관리자의 역사를 되돌아보겠습니다.

나쁜 관리자는 군대조직에서 처음 기인하기도 하고 산업혁명 때부터 공장들이 우후죽순 생겨났고 보통 숙련되지 못한 노동자들을 고용해 기계를 돌렸습니다. 노동자들을 관리할 감독관이 필요해졌고 당시 노동자들은 쉽게 다른 노동자로 대체할 수 있었습니다. 당근과 채찍 관리 방식은 살아남았고 20세기 중반까지도 이런 관리자들이 활개했습니다.

당근과 채찍 방식은 비효울적이고 창의적인 사람의 생산성을 떨어뜨린다는 연구는 수도 없습니다.

여전히 우리 대부분은 "관리자"라는 용어를 사용하지만 사실 여러 면에서 시대에 뒤떨어진 이름입니다. 직책의 이름자체가 갓 부임한 관리자들에게 "관리"하게 부추기죠 관리자는 부모처럼 행동하게 되고, 그 반작용으로 직원들은 자연스럽게 아이처럼 반응하게 됩니다.

관리자가 직원들을 신뢰한다는 분명한 신호를 주면 직원들은 신뢰에 부응해야 한다는 긍정적인 압박을 느낍니다. 훌륭한 관리자는 팀이 나아갈 길을 다짐과 동시에 안전과 복지를 챙겨줍니다.

이번 장에서 기억해야 할 단 하나를 고르라면 이 문장이비낟. """전통적인 관리자는 일을 "어떻게" 처리할지를 고민하는 반면, 훌륭한 관리자는 "무슨" 일을 처리할지를 고민합니다. 그리고 "어떻게" 는 팀을 믿고 맡깁니다.

팀원들이 안전하다고 느끼게 해주는 일 역시 팀을 촉진하는 좋은 방법입니다.

회사들 대부분은 최선을 다해 위험을 회피하려 합니다. 그래서 보통은 작은 성공에 집중하는 보수적인 전략을 택합니다. 구글에선 이렇게 말합니다. "불가능한 목표에 도전하면 실패할 가능성은 그만큼 크다. 하지만 불가능에 도전해 실패하면 성공이 확실하리라 생각한 일을 성취했을 때보다 십중팔구 훨씬 큰 것을 얻는다"

요지는 팀이 위험을 감수하는 문화를 조성하는 멋진 방법은 바로 실패해도 괜찮음을 알게하는 것입니다.

실패해도 괜찮습니다.(백엔드는 말이죠) 우리는 실패를 "많은 것을 아주 빠르게 배울 수 있는 기회" 로 봅니다 (똑같은 일에 계속 실패하는건 논외입니다)

아 그리고 개인의 성공과 실패는 조금 다른 문제입니다. 성공에 기여한 개인을 축하해주는 것은 좋지만 실패시 비난할 누군가를 찾으려 하면 안됩니다. 특정 개인이 이룬 성취는 팀이 보는 앞에서 칭찬해주세요 실패한 개인에게는 "개인적으로" 따로 불러서 "건설적인" 비판을 해주세요. 어떤 경우든 배울 기회로 삼고, 겸손, 존중, 신뢰라는 원칙 하에 행동하세요. 그러면 팀이 실패로부터 배우는데 큰 도움이 될 것입니다.

안티 패턴 이란 따라해서는 안되는 패턴들입니다.

여러분보다 부족하고, 의욕이 적은 사람을 고용하거나 여러분보다 더 위태위태한 사람들 고용하면 여러분은 회사에 남을수 있고 결정권이나 위치를 지킬 수 있습니다. 그치만 만만한 사람들로 팀을 꾸리면 여러분은 휴가를 떠나지도, 심지어 의자에서 엉덩이를 떼지도 못하고 팀의 생산성은 나락으로 떨어질 테고요.

반대로 여러분보다 똑똑하고 여러분을 대체할 역량을 갖춘 사람을 적극적으로 뽑아야합니다. 물론 매우 어려운 결정이죠. 실제로 그 사람들이 여러분의 위치를 시시때때로 위협할테니까요 (여러분이 실수를 저지르면 지적해주기도 하고요) 하지만 이 사람들은 여러분에게 강렬한 자극과 함께 멋진 일들도 안겨줄 것입니다. 스스로 할 일을 찾고 확장하며, 일부는 스스로 팀을 이끌고 싶어 할 것입니다. 이를 여러분의 권위에 도전한다고 받아들여서는 안 됩니다. 반대로 팀을 하나 더 꾸릴 기회로 생각하세요. 마음놓고 휴가를 떠날 때가 온 것일지도 모르죠, 일이 잘 진행되고 있는지 매일같이 확인할 필요도 없어요! 또한 여러분 자신이 배우고 성장할 멋진 기회일 수도 있습니다. 여러분 보다 똑똑한 사람들로 주변을 채우면 자신의 전문성을 확장하는데도 훨씬 유리합니다!!

구글의 베테랑 상급 관리자의 한마디 조언이 있습니다. "모든 치아를 공평하게 대해야 하지만, 때로는 치과의사가 되어야 한다네"

우리는 멋진 리더를 많이 보았습니다. 강한 팀을 만들기 위해 할 수 있는 모든 옳은 일을 하죠. 그럼에도 팀은 실패하고 결국 해체되기도 합니다 단 한두 명의 저성과자 때문에 말이죠.

여러분이 못본 척 하더라도 저성과자의 존재는 팀원 모두가 알고 있습니다. 사실 팀은 누가 저성과자인지를 아주 "정확하게" 꿰뚫고 있습니다. 왜냐면 저성과자를 업고 뛰는 당사자가 바로 그들이기 때문이져.

저성과자를 방치하는 일은 새로운 고성과자가 팀에 합류하는 걸 막기도 하며, 그나마 있던 팀 내 고성과자를 떠나게도 합니다.

마지막으로 여러분이 그 팀원을 붙들고 있다고 해서 그들에게 이로운 것도 아닙니다. 다른 팀에 가서는 더 좋은 성과를 내는 경우도 있으니까요.

그럼 어떤 효과적인 방법이 있을까요?

짧은 기간의 마이크로매니징을 피하기는 어렵지만 전체적으로는 역시 검손, 존중, 신뢰가 바탕이 되어야 합니다. 특히 존중이 중요합니다. 기간을 정하고 아주 구체적인 목표를 제시하세요. 작고 점진적으로 측정할 수 있는 목표여야 합니다. 그래야 작은 성공들을 많이 경험할 기회가 생기니까요.

여러분이 팀을 신뢰하지 못함을 보여주는 가장 대표적인 예가 팀원들을 어린이처럼 대하는 것입니다. 마이크로매니징을 하거나, 단순히 팀원들의 능력을 존중하지 않고, 자신의 일에 책임질 기회를 주지 않으면 팀원들은 애가 됩니다. 실제로 특정 팀원을 믿지 못해서 마이크로매니징할 수밖에 없는 상황이 고착화된다면 여러분이 채용을 잘못한 것입니다.

믿을만한 사람을 뽑았고 신뢰를 보여준다면 보통은 그들도 능력을 발휘할 것입니다.

=================================== 안티 패턴을 살펴봤으니 이제 성공하는 리더십과 관리를 위한 올바른 패턴을 알아볼 차례입니당.

이 패턴을 흔히 현관 매트처럼 납작 엎드려 다른 이들이 밟고 지나다니게 하는 것이라고 오해하곤 합니다. 전혀 아닙니다.

신뢰는 "자존심 버리기"의 한 축입니다. 제발 팀을 믿으세요. 팀원들의 능력과 기존에 이룬 성과들을 존중해야한다는 뜻입니다.

팀을 하나로 모으고 방향을 정하게 도와주는 건 여러분 몫입니다. 하지만 목표를 이루기 위해 부품을 조립하는 구체적인 방법은 현장에서 손발을 맞춰 일하는 사람들이 결정하는게 훨씬 낫다는 뜻이죠.

그래야 팀원들에게 주인의식도 생기고 성공(혹은실패)에 대한 책임감도 더 크게 느끼게 됩니다.

리더 역할이 처음인 사람은 대부분 모든 사안을 올바르게 결정하고, 모든 것을 알고, 모든 질문에 답해야 한다는 강박으로 스스로를 옭아맵니다. 장담하건데 여러분은 때론 잘못된 결정을 내릴 것이며 모든 문제의 답을 알고 있지도 못합니다. 그럼에도 스스로가 완벽한 듯 자기의 결정은 절때 틀리지 않았다는 듯 행동한다면 팀원들의 존경을 빠르게 잃어갈 것입니다.

개인 기여자 시절을 떠올려 보세요. 여러분은 1km 밖에서도 문제를 직감할수 있었습니다 !

누군가 여러분이 내린 결정에 질문을 던진다면 감사해야합니다. 질문자의 의도는 대게 그저 여러분을 더 잘 이해하려는 것임을 잊지 마세요.

여러분에게 훌륭하고 건설적인 비판을 해줄 사람을 찾기란 매우 어렵습니다. 특히 부하직원 중에서 찾기란 정말로 어렵습니다. 여러분이 팀으로서 이루려는 큰 그림을 잊지 마세요. 피드백을 수용하고 비판에 마을을 여세요.

자존심을 지키려는 충동을 이겨내야 합니다.

자존심 버리기의 마지막은 간단하지만 많은 리더가 실천하지 못하는 일입니다. 바로 실수 했다면 사과하기 입니다. 말로만 '미안해요'라고 내뱉는걸 말하는게 아닙니다.

여러분은 분명 실수를 할 것입니다. 스스로 인정하든 안하든 팀원들은 다 알게 됩니다. 사과한다고 돈이 드는건 아니잖아요? 사람들은 무언가를 망쳤으면 사과할 줄 아는 리더를 존경합니다. 사과한다고 여러분이 피해를 입는건 없습니다. 오히려 존경을 얻죠. 왜냐하면 사과한다는 것은 여러분이 성숙하고 상황을 판단할 줄 알며 겸손하다는 증거로 받아 들여지기 때문입니다.

5.5.2 질문하기

팀원이 여러분에게 조언을 구한다는 것은 마침내 무언가를 해결해줄 기회가 찾아온 것입니다. !! 신나는 일이죠 ! ! 여러분은 곧장 문제 해결 모드로 전환할 것입니다.! 하지만 "직접 해결하기"는 가장 마지막에 택해야 하는 전략입니다.

스스로 문제를 해결하는 걸 도와줘야합니다. 겸손, 존중, 신뢰를 담아서 조언을 청한 사람이 자기 힘으로 문제를 해결하도록 도와주려 노력해야합니다.

문제를 다시 정의하고 탐구해보도록 보조해주세요. 그러다 보면 보통은 답을 찾아냅니다. 여러분이 아닌, 질문자 스스로가 이끌어낸 그 사람의 답이란 점이 중요합니다 !

팀원들에게 혹은 상사에게든 누구에게나 곤란한 피드백을 주는건... 네 어렵습니다. 팀원이 사고를 쳤다거나 기다한 만큼 일을 해내지 못했음을 처음 이야기할 때는 극심한 스트레스를 받습니다.

대부분의 관리자용 교재나 강의에는 칭찬 샌드위치 방식으로 충격을 완화하라고 가르칩니다.

예를들어 이렇게 하면 충격은 물론 줄겠죠.

하지만 따가운 가시를 폭신한 솜털로 칭칭 감싸 놓는다면, 면담을 끝내고 나오는 사람 대부분은 그저 "좋아! 쩌는 티셔츠가 생겼네" 라고 생각할 것입니다.

구글은 칭찬 샌드위치 하지말라고 강하게 권합니다. 가혹하고 잔인해져야 한다는게 아닙니다. 겉에 둘러진 칭찬때문에 핵심 메시지, 고쳐야할 점을 지적한 것이 제대로 인지하지 못하는 사람이 대부분이기 때문입니다. 친절과 공감이 아주 중요합니다.

보다시피 아무런 칭찬도, 사탕발림도 없었습니다. 그렇다고 기분 상하게도 하지 않았습니다.

리더로써 팀의 생산성을 장기적으로 더욱 끌어올리려면 팀월들이 행복해하는지를 확인하는 데도 시간을 써야 합니다.

구글이 겪은 최고의 리더는 모두 반은 심리학자였습니다.( 진짜 학자가아니라 그정도로 팀원들 심리를 잘안다는뜻)

수시로 팀원들의 복지를 챙기고, 그들이 하는 일을 인정해주고, 일에 만족하는지 확인했죠.

또한 가끔 일대일 면담을 하며 기술적인 이야기를 나누곤 했습니다. 업무를 수행하는 데 부족한 것은 없는지, 장애물이 있는지, 하는 일에 만족하는지, 다음 프로젝트로 무얼 하고 싶은지 같은거 말이죠...

팀이 행복한지를 추적하는 간단한 방법을 하나 소개할게요. 팀원들과 일대일 면담 마지막에 "뭐 필요한 거 없어요?" 라고 묻는 것입니다.

간단한 질문이죠. 이 질문을 면담때마다 빼놓지 않고 던진다면 팀원들은 머릿속에 담아둘 것이고, 그리고 모두의 업무를 개선해줄 일거리 목록을 준비해오는 사람도 하나둘 나타날 것입니다.

위임하되, 곤란한 일은 직접 처리하자

특히 아무도 하려 들지 않는 지저분한 일을 떠맡으세요. 경력이 아무리 길고 많은 걸 성취했더라도 그것만으로는 여러분의 실력이 얼마나 뛰어난지 그리고 어려운 일이 닥쳤을 때 진짜로 뛰어들어 겸손하게 헌신할 사람인지는 팀원들이 알 수 없습니다.

여러분을 대신할 사람을 찾자

앞에서도 얘기하였듯 이 일은 채용 과정에서부터 시작됩니다. "당신보다 똑똑한 사람을 채용하라" 라는 말로 귀결되죠. 적합한 팀원을 구했다면 그 사람에게 더 많은 책임을 질 기회를, 때때로 팀을 이끌어볼 기회를 줘야 합니다.

팀이 잘하고 있으면 칭찬하자

많은 새내기 리더가 팀원들의 단점을 처리하는 데 익숙해져서 긍정적인 피드백을 필요한 만큼 자주 주지 못합니다. 누군가 일을 잘못 처리했을 때 알려주는 것처럼 잘 처리했을 때도 꼭 알려주세요. 기대 이상으로 잘 해냈다면 당사자는 물론 팀 전체에 알려주세요.

실패해도 쉽게 되돌릴 수 있는 일에는 "해보세요" 라고 말하자

진짜로 훌륭한 리더는 어떤 일은 되돌릴 수 있고 어떤 일은 되돌리기가 생각만큼 쉽지 않은지를 판단해내는 감각이 뛰어납니다.

눈가리개 찾아서 버리기

한 문제에 너무 오래 변화가 없으면 "눈가리개"가 시야를 가려서 더는 숲을 보지 못하게 되곤 합니다. "우린 항상 이렇게 해왔어요" 라고 말하면서 현재 방식에 문제가 있을 수 있다고는 의심조차 못하는, 말 그대로 비판 능력을 상실해버리죠. 현상 유지를 정당화하기 위해 메커니즘을 억지스럽게 꼬아놓거나 합리화 논리를 만들어내기도 합니다.

마치며....

팀을 이끈다는 것은 소프트웨어 엔지니어가 되는 것과는 또 다른 일입니다. 그래서 훌륭한 개발자, 기획자, 디자이너, 마케터라고 해서 좋은 관리자가 되는 게 아닙니다. 지극히 자연스러운 현상이죠.

관리자에게도 실무적 경험이 중요하지만 유능한 관리자에게 무것보다 중요한 자질은 사회적 스킬임을 구글은 깨우쳤습니다. 좋은 관리자는 팀이 일을 스스로 잘하도록 돕고, 올바른 목표에 집중하게 하고, 조직 외부의 방해요소를 차단해줍니다. 겸손, 존중, 신뢰를 담아서 말이죠.

안녕하세요 오늘 소개할 책은 구글 엔지니어는 이렇게 일한다 ! 입니다 일단 제목부터 어그로가 상당하죠? 제목부터 안 살 수가 없어 ㅠ

((짤 2))

자 여러분들의 시간은 소중하니까 일단 시작합시다.

((짤 3))

Ch.1 소프트웨어 엔지니어링이란?

일단 이 책의 첫장은 SE 과 프로그래밍의 차이부터 짚고 넘어가는데요

((짤 4))

프로그래밍과 소프트웨어 엔지니어링의 가장 큰 차이

시간, (규모)확장, 실전에서의 트레이드 오프

구글에서는 이따금 "SE는 흐르는 시간 위에서 순간순간의 프로그래밍을 모두 합산한 것이다" 라는 말이 있는데요

((짤 5))

프로그래밍 작업: (개발 development) SE 작업: (개발 development + 수정 modification + 유지보수 maintenance) 여기에 시간이라는 요소가 더해지면서 프로그래밍에는 중요한 차원때문에 더 입체적으로 진화 ! 하는거죠

((짤 6))

우리가 코드를 보고 이런 말을 할 수 있습니다. 이 코드의 예상 수명은? 몇분 후 사라질 코드부터 수십 년을 살아남을 코드까지 다양한 경우가 있다.

SE 와 프로그래밍을 가르는 핵심은 이 사실을 인식하는데서 시작합니다.

이 사실은 바로 우리가 말하는 소프트웨어의

((짤 7))

지속 가능성 sustainability

기술적인 이유든 사업적인 이유든, SW 의 기대 생애 동안 요구되는 모든 가치 있는 변경에 대응할 수 있다면 "그 프로젝트는 지속 가능하다" 라고 말한다.

((짤 8))

의사결정의 복잡성과 이해관계 측면에서도 프로그래밍과 차이가 나요 SE에서는 주기적으로 여러 선택지 사이의 트레이드오프를 평가해야해요. 때로는 불완전한 지표에 기대어 결과에 커다란 영향을 주는 선택을 해야합니다. SE 혹은 리더는 지속 가능성을 잃지 않으면서 조직, 제품, 개발 워크플로의 규모를 확장하는 비용을 관리해야 합니다

((짤 9))

이러한 사실을 주지하고 트레이드오프를 평가하여 합리적인 결정을 내려야하고 때로는 유지보수에 도움되는 변경을 연기하거나 심지어 확장성이 떨어지는 정책을 받아들여야 할 때도 있어요 이러한 결정은 훗날 다시 검토해야 할 수 도 있을을 잊지 말아야하며, 이 결정 때문에 생긴 지연 비용을 정확히 계산해두어야 해요. 엄청 할게 많죠?

((짤 10))

1.1.1 하이럼의 법칙

API 사용자가 충분히 많다면 API 명세에 적힌 내용은 중요하지 않습니다. 시스템에서 눈에 보이는 모든 행위(동작)를 누군가는 이용하게 될 것이기 때문이다.

하이럼의 법칙은 최선의 의도, 최고의 엔지니어, 꼼꼼한 코드 리뷰가 뒷받침되더라도 공표한 계약(명세)이나 모범 사례를 완벽하게 구현해냈다고 단정할 수 없다는 현실을 표현 한 말. API 소유자가 인터페이스를 명확하게 설명해놓으면 어느 정도의 유연성과 자유를 얻을 수 있다. 하지만 현실에서는 API 사용자가 없는 기능을 찾아 활용하기도 한다.

그 기능이 유용해서 널리 쓰이면 추후 API 를 변경하기 어렵게 된다.

문맥에 따라 의역을 하자면 이렇습니다. API를 사용하는 사용자가 많아지면 API 문서에 뭐라고 적어두었는지는 더 이상 크게 중요하지 않다는 것을 의미합니다. 사용자가 API를 사용하면서, API 통해 기대하는 동작이 있을 것이고 이것들이 모여 API 문서와는 별개로 '암묵적인 인터페이스 규약'이라는 것이 생깁니다.

여기 예시가 있습니다.

((짤 11))

1.1.2 사례 : 해시 순서

해시 함수를 내가 만들었는데 버그가 있어요 해시 반복 순서가 무작위임을 눈치챈 누군가 사용자가 이를 난수 발생기로 사용할 수 도 있기 때문에, 이제 내가 무작위성(버그)를 제거하면 이 개발자(사용자)의 코드가 오작동할 것 !

결국 우리는 이 '암묵적인 인터페이스 규약'조차도 지킬 수 있어야 한다고 말합니다. 암묵적이어도 규약이기 때문입니다. 그리고 만약 API에 버그가 있었다면 이를 그냥 수정하고 문서만 바꾸기만 해서는 안 된다고 합니다. 더 나아가 구글에서는 버그를 위한 버그 하위 호환성도 지킬 수 있어야 한다고 말합니다.

하이럼 법칙은 사용자 수가 많고, API 가 노출되는 모든 곳에서 발생할 수 있다고 말합니다. 하이럼 법칙 때문에 확장이나 축소가 어려워지는 경우도 많이 셍깁니다. 그리고 확장 축소와 관련해서 하이럼 법칙이 문제가 되었던 실제 사례를 중간중간 많이 이야기하고 있습니다. 그렇기 때문에 하이럼 법칙을 API deprecation 이나 수정하기 어려운 이유 중 하나로 들고 있습니다.

((짤 12))

동작한다 : it works 옳다 : it is correct 는 다르다

"당장 돌아가야한다" "언제까지고 작동해야 한다" 코드 차이

임시방편적인 혹은 "기발한" 코드 클린하고 유지보수 "가능한" 코드

우리는 "기발한" 이 칭찬으로 느껴진다면 프로그래밍이라고 하고 질책으로 느껴진다면 SE 라고한다.

((짤 13))

비욘세 규칙: "네가 좋아했다면 CI 테스트를 준비해뒀어야지" !

"인프라를 변경하여 서비스가 중단되는 등의 문제가 발생하더라고, 문제가 CI continuous integration 시스템의 자동 테스트에서 발견되지 않는다면 인프라팀의 책임이 아니다" 라는 정책

((짤 14))

규모확장과 효율성

• 전문성: 여러방법에 대한 충분한 지식이 있었습니다.
• 안정성: 더 규칙적으로 릴리스 하여 릴리스 사이의 변경량을 줄였습니다.
• 순응: 업그레이드를 겪지 않은 코드가 많지 않습니다. 규칙적인게 도움이 됨
• 익숙함: 업그레이드를 정기적으로 수행해서 중복되는 작업을 찾고 자동화 노력,
• 정책: 비욘세 규칙과 같은 유용한 정책과 절차를 갖춥니다.

((짤 15))

원점 회귀 (왼쪽으로 옮기기)

문제 발견 시점을 왼쪽으로 이동시킬수록 수정 비용이 줄어든다는 얘기

비용을 정확히 짚어줍니다 비용은 비단 돈 뿐만을 지칭하는것이 아니죠

• 금융 (예: 돈)
• 레소스 비용 (예: CPU 시간)
• 인적 비용 (예: 엔지니어링 노력)
• 거래 비용 (예: 조치를 취하는 비용)
• 기회 비용 (예: 조치를 취하지 않는 비용)
• 사회적 비용 (예: 선택이 사회 전체에 미치는 영향)

구글이 얼마나 비용효율적이게 일하는 가를 보여주는 가벼운 사례가 있어요

((짤 16))

사례 : 화이트보드 마커

많은 조직에서 화이트보드 마커는 귀중하게 대접받습니다. 엄격하게 관리되며 항상 공급이 부족하죠. 맨날 찾으면 없고 필요하면 없고, 찾으면 절반은 말라있어서 잘 안나오고, 잘 그리다 갑자기 안나와서 회의 흐름 끊기고, 이런 경험 없나요?

((짤 17))

없다면 당신은 진정한 디지털 MZ 세대?! 빠밤! ,, 장난이구요

그래서 구글 사무실 대부분 마커가 넘쳐나고 어디든 약간 서울의 편의점 마냥 어딜가든 찾을수 있게 많이 비치되어있다, 끊김 없는 브레인스토밍이 누군가 마커를 찾아 헤매는 일보다 훨씬 중요하기 때문이죠.

((짤 18))

드디어 파트 2 입니다. 바로 문화 입니다.

문화

그리고 첫 단원은 팀워크이죠

((짤 19))

사람들은 자신이 진행중인 작업물을 다른사람이 보고 판단하는 걸 두려워합니다.

아마 인간의 본성에 속할수도 있습니다.

((짤 20))

누구라도 비난받고 싶어 하지 않으며, 작업물이 완성도기 전이라면 더욱 그렇습니다.

이 책의 저자는 불안감을 멀리하라고 합니다. 불안감은 사실 더 큰 문제의 지후입니다.

천재신화

((짤 21))

리누스 토발스, 귀도 반 로셈 빌 게이츠 SE 계의 아이돌이죠,

((짤 22))

리눅스를 만들고 파이썬을 만들었다는 유명한 천재 신화이죠 하지만 첫 부분만 만들고 나머지는 수천명의 아이디어를 모으고 기능개발하고 수정하며 만들었습니다. 인간은 본능적으로 리더와 롤모델을 찾고 그들을 우상화하고 흉내내려합니다.

((짤 23))

내면 깊숙한 곳에서 많은 엔지니어가 자신이 천재로 비치기를 원합니다. 그 환상이 실현되는 시나리오는 대략 다음과 같습니다.

• 굉장히 새로운 개념이 떠오릅니다.
• 몇 주 혹은 몇 달 동안 동굴로 사라져서 이 아이디어를 완벽하게 구현해봅니다.
• 완성된 소프트웨어를 세상에 공개하여 여러분의 천재성에 모두가 충격을 받습니다.
• 동료들이 여러분의 영리함에 놀라움을 금치 못합니다.
• 여러분의 소프트웨어를 사용하려는 사람들이 물밀듯 몰려듭니다.
• 명성과 부는 자연스럽게 따라옵니다.

((짤 24))

현실은,,, 여러분은 분명히 매우 똑똑한 사람일거에요 까다로운 코딩도 잘하고 근데 천재들도 실수를 해요. 그리고 더 중요한건 "사람들에게 가치 있는 문제" 가 아닌 "분석 자체에만 의미를 두는 문제" 일 가능성이 높아요,

이것을 위한 빌드업이였습니다

((짤 25))

숨기는 건 해롭다

우리는 우리가 올바른 일을 하고 있는지, 제대로 하고 있는지, 그리고 다른 누군가가 이미 해놓은 일은 아닌지를 확인해봐야합니다. "초기" 단계에서 이런 실수를 범할 확률은 상당히 높습니다. 그래서 피드백을 조기에 받을수록 이러한 위험이 크게 줄어듭니다.

검증된 주문입니다.

((짤 26))

일찍 실패하고, 빨리 실패하고, 자주 실패하라

너무 진지했나요? 이번에는 좀 재미있는 내용같아서 가져와봤습니다

((짤 27))

The bus factor

Bus factor 란

((짤 28))

"프로젝트 멤버 중 일부가 갑작스럽게 버스에 치여서 입원해야하느라 프로젝트를 하게 될 수 없는 경우, 몇 명까지 버스에 치여도 프로젝트가 중단되지 않을 수 있는가?"

입니다.

다시말해 프로젝트가 중단되지 않고 유지될 수 있게 하는 사람의 수가 몇이냐라는 의미입니다.

bus라고 하길래 롤에서 말하는 bus를 의미하는 줄 알았는데 실제 물리적인 버스를 의미하더라고요.

책에서 bus factor를 설명하면서 이야기하는 요점은 간단합니다. bus factor를 늘리라고 합니다. 프로젝트의 모든 짐을 혼자 감당하는 슈퍼 개발자가 되려한다면 프로젝트가 좌초될 확률이 높다 합니다. 그리고 bus factor 를 높이기 위해 본인이 가진 지식과 노하우를 팀원들에게 공유해서 분담하라고 말합니다.

결론은 ! 숨기지 말자

((짤 29))

홀로 일하기는 함께 일하기보다 본질적으로 더 위험합니다.

잘못된 일에 여러분의 천금 같은 시간을 낭비할 가능성을 더 걱정해야합니다. !

사회적 상호작용의 세 기둥

((짤 30))

위대한 소프트웨어를 만드는 최선의 길이 팀워크라면 위대한 팀은 어떻게 만들어야 할까요? 혹은 어떻게 하면 찾을 수 있을까요?

협업의 레베루에 올라가려면 가장 먼저 사회적 스킬의 세 기둥을 익혀야 합니다.

겸손: 당신과 당신 코드는 우주의 중심이 아닙니다. 당신은 모든 것을 알지도 완벽하지도 않습니다 겸손한 사람은 배움에 열려 있습니다. 존중: 함께 일하는 동료를 진심으로 생각합니다. 친절하게 대하고 그들의 능력과 성취에 감사해합니다. 신뢰: 동료들이 유능하고 올바른 일을 하리라 믿습니다 필요하면 그들에게 스스로 방향을 정하게 해도 좋습니다.

자존심 버리기

겸손은 중요하지만 바짝 엎드리라는 뜻은 아닙니다 자신감 좋습니다 그러나 모든걸 다 아는 듯 행동하지 말라. '집단적'자존심을 찾으세요 자신보다 팀의 성취와 단체의 자부심을 높이려 노력하세요

비난 없는 포스트모템 문화

사후처리라는 뜻입니다.

((짤 31))

빠르게 실패하고 반복하기 구글의 좌우명 '실패는 선택이다' 실패의 근본 원인을 분석하여 문서로 남기는 것이 실수로 부터 배우는 핵심이다. (aka 포스트모템) 포스트모템에는 무엇을 배웠는지와 배운것을 토대로 무엇을 바꿀지를 담아야한다. 제대로된 실패의 기록 = 히스토리 + 똑같은 실수 방지

• 사건의 개요
• 사건을 인지하고 해결에 이르기까지 타임라인
• 사건의 근본 원인
• 영향과 피해 평가
• 문제를 즉시 해결하기 위한 조치 항목

드디어 챕터 3 입니다. 지식공유에 관한 건입니다.

챕터3 지식공유

((짤 32))

배움을 가로막는 장애물

• 심리적 안전 부족 ( 불이익때문에 질문하기를 주저하는것 등)
• 정보 섬 (지식이 파편화되는것) 팀마다 공유안하고 따로 작업
  • 정보 파편화, 정보 중복, 정보 왜곡
• 단일 장애점 (중요한 정보를 한명이 독점)
• 전부 아니면 전무 전문성 (조직원이 모든 것을 아는 사람과 아무것도 모르는 초심자로 나뉨)
• 앵무새처럼 흉내내기 (잘은 모르겠지만 이게 맞겠거니..)
• 유령의묘지 (우리 코드 결제쪽 같은.. 손대기를 기피하는 영역)

판 깔아주기 : 심리적 안전

((짤 33))

심리적 안전은 학습 환경을 조성하는데 매우 중요합니다. 모름을 인정하는 문화가 필요합니다. 무지를 탓하지 말고 그 솔직함을 반겨야합니다.

((짤 34))

배움에는 '무언가를 시도하다가 실패해도 안전하다'는 인식이 엄청나게 중요한 환경입니다. 심리적 안전이 효과적인 팀을 이루는데 가장 중요해요!

큰 그룹에서의 심리적 안전 안전하고 편안한 근무 환경을 조성하기 위해 가장 필요한 것은 적대적이지 않고 협조적으로 일하는 문화이다.

((짤 35))

전 이거 좀 웃겼던거 같아서 통째로 집어넣었어요.

내 지식 키우기

지식 공유는 여러분으로부터 시작됩니다. 항상 무언가 배울게 있음을 인식하는 게 중요합니다.

((짤 36))

1. 질문하기 항상 배우고 항상 질문하세요. 모르는 분야가 나오면 두려워하지말고 성장하는 기회로 받아들이세요
2. 맥락 이해하기 새로운 것 뿐 아니라 기존 설계와 구현을 뒷받침하는 결정 사항들을 더 깊이 이해하는 일도 배움에 포함됩니다.

((짤 37))

문서화 촉진하기

문서 작성에 드는 시간과 노력이 있으나 코딩할 시간을 뺏길때도 있죠 그러나 N명에게 질문에 답하는 시간보다 하나의 문서가 더 시간 절약하는 것입니다. 문서화는 팀과 조직의 규모를 키우는데도 보탬이 됩니다.

((짤 38))

코드

코드도 지식에 해당하므로 코딩은 지식을 옮겨 적는 행위로 간주할 수 있어요. 코드 문서화는 다른 형태의 지식 공유 수단입니다. 자기 자신을 포함한 미래의 독자를 위해 정확하게 기록하세요.

((짤 39))

지식을 공유할 때는 상냥함과 존중을 담아야 합니다. 뛰어난 괴짜를 용인하는 것은 해롭습니다. 상냥한 전문가도 얼마든지 가능합니다.

((짤 40))

지식은 형태는 없으나 많은 측면에서 소프트웨어 엔지니어링 조직의 가장 중요한 자산입니다. 지식 공유는 조직에 탄력을 불어넣어 변화에서 생존할 수 있는 역할을 합니다. 지식을 쉽게 공유하는데 투자한 노력은 회사의 생애 동안 몇 배로 돌려받는다.

짤(원피스)

누구나, 아니 어떤 회사든 좋은 인재를 가지고 일을 하고 싶은건 당연한거죠, 여기 넷플 사장님이 인재밀도가 중요하다고 생각한 터닝 포인트가 있습니다.

회사가 갑자기 어려워져서 고심끝에 성과, 포텐셜, 인사고과 이런거로 판단해서 하위 30%를 짤랐어요,

짤 트럼프

그런데 얼마 후 우편 주문 DVD 대여업의 난데없는 호황을 맞았는데

짤 고양이

진짜 직원들 겁나 바쁘고 늦게까지 퇴근하지 못해도 사기는 하늘을 찌를듯했다고 합니다 (사장눈에만 그렇게 보였을 수도)

슬램 짤

근데 이게 생각해보면 되게 좋은거죠, 스포츠를 하던 일을하던, 무엇을 하던 손발이 척척 맞고, 일 잘하는 사람끼리 일하면 개떡같이 말해도 찰떡같이 알아듣지만 개떡같이 말하는 사람도 없고 진행 빠르고 뭔가 일 잘 풀리고 그럼 자아실현되고 WIN WIN 이져,

글자 짤

재능 있는 사람들을 서로 능률을 높인다.

짤 밀도 그림

전체로 보면 수가 줄었지만 인재의 "밀도" 가 증가한 것이죠.

짤 5명

팀에 평범한 사람이 1~2명 섞여 있으면 팀 전체의 성과가 떨어집니다. 탁월한 인재 5명과 평범한 사람 2명이 함께 있으면 그 팀은 평범한 팀이 됩니다.

짤 아래 글

• 매니저의 기운을 빼 최고의 성과를 내지 못하게 만든다. • 그룹 토의의 질을 떨어뜨려 팀의 전반적인 IQ를 낮춘다. • 사람들이 싫어할 일을 하게 만들어 능률을 떨어뜨린다. • 남보다 탁월한 능력을 발휘하고 싶은 직원을 회사에서 나가게 만든다. • 평범한 사람도 받아준다는 사실을 보여줌으로써 문제를 복잡하게만 든다.

재능이 뛰어난 (선천적이던, 후천적이던) 베스트 플레이어들이 생각하는 좋은 직장의 조건은 호화스러운 사무실이나 멋진 체육관, 혹은 공짜 스시같은 (대략 쩌는 복지) 같은게 아니라

그들에게 중요한건, 일을 더 잘할 수 있게 해주는 사람이 필요하다. 모든 직원이 뛰어나면 서로에게 배우고 서로가 의욕을 불어넣어 성과는 수직으로 상승한다.

왜냐면 실무자의 커리어는 여기서 끝나는 것이 아니기 때문에, 아무리 복지 좋아도 같이 일하는 사람들이 일을 못해서 내가 성과가 잘 안나면 내 커리어도 멈추기 마련이지 않을까요?

짤 아래 글

성과는 전염성이 강하다.

호주 뉴사우스웨일스 대학교에서 직장에서 행동이 강한 전염성을 갖는다는 사실을 보여주는 흥미로운 연구가 있죠.

짤 아래 글

각 팀마다 45분안에 관리 업무를 끝내라는 과제였고 1등한 팀에게는 100달러 보상을 주기로 했는데, 각 팀마다 몰래 연구팀 스파이를 꼈습니다.

게으름뱅이역, 삐딱이역, 우울한 비관주의자, 이런 역할이 낀 팀은 재능이 뛰어난 팀원들도 전염이되어서 전체의 능률이 떨어진다는 결과 1명이라도 수준에 미치지 못하는 사람이 1명이라도 있는 팀은 그렇지 않은 팀에 비해 성과가 무려 30~40% 뒤쳐졌습니다.

짤 아래 글

"놀라운 사실은 다른 팀원들이 문제가 되는 사람의 특성을 흉내 내기 (따라하기) 시작한다는 점"

1장요약

• 리더로서 당신의 첫 번째 목표는 직장에 비범한 동료들로만 채워진 근무 환경을 조성하는 것이다.
• 비범한 동료들은 중요한 일을 능숙하게 처리한다. 또한 놀라울 정도로 창의적이고 열정적이다.
• 심사가 비뚤어졌거나 게으르거나 착하긴 한데 성과는 별볼 일 없거나 매사를 부정적으로 보는 사람들이 끼어 있으면, 팀의 전반적인 성과가 저하된다.

짤 유재석

솔직하고 정확하게 단, 상대를 공격하거나 마음 상하게하려는 의도가 아니라, 어디까지나 선의를 가지고 정식으로 문제를 제기한 후, 자신의 감정과 의견, 상대방에 대한 피드백을 솔직하게 표현하게 한것.

짤 박명수

뒤에서 수군거릴 게 아니라, 당당히 마주 보면서 자신의 의견이나 상대방에 대한 피드백을 명확히 전달하면, 책략이나 은밀한 소통이 줄어들고 업무를 더욱 빨리 처리할 수 있다. 잘한다는 말을 많이 들을수록 사람들은 더 잘하게 되고, 이와 같은 그들의 변화가 하나의 기업 으로서의 넷플릭스의 성과를 더욱 높였다고 합니다.

물론 아주 과격한 방법이죠. 사교적인 경우든 업무와 관련된 일이든, 얼굴을 마주 보며 자신의 생각을 가감 없이 말하다가는 금방 외톨이가 되고 심지어 회사에서 쫓겨날 수도 있다. 그러나 넷플릭스에서는 그런 것들이 모두 허용된다. 우리는 직원들이 평소에 상호 발전적인 피드백을 주고받는 분위기를 만들기 위해 애쓴다. 윗사람이든 동년배이든 아랫사람이든, 가리지 않고 말이다.

높은 성과 + 사심없는 솔직함 = 대단히 높은 성과

짤 무한도전

짤 아래 글

• 사람들이 내견해를 지지하지 않을것같다. • ‘까다로운’사람이라는 인상을 주고 싶지않다. • 내키지 않는 논쟁에 말려들고 싶지않다. • 동료들의 비위를 거스르거나 화를 돋우고 싶지 않다. • ‘비협조적인’ 사람으로 낙인찍히기 싫다.

동료의 의견에 동의하지 않거나 도움이 될 만한 피드백이 있는 데도 말하지 않는 것은, 회사에 불충한 것이다. 넷플릭스에서는 그렇다. 업무에 도움이 될 수 있는데도 돕지 않기로 한 것이니까.

짤 아래 글

피드백 로프, 솔직한 문화 조성

2003년 캘리, LA 가든그로브

초등학교 인근에서 차와 보행자 관련 사고가 유난히 자주 발생해서 당국은 운전자의 속도를 낮추기 위해 속도제한 표지판을 설치했고, 경찰은 이를 위반한사람에게 범칙금을 부과했지만

그런데도 사고는 좀처럼 줄지 않았다.

도시 엔지니어들은 방법을 바꿔서 즉석 속도표시기를 설치했다.

짤 자동차

‘운전자 피드백’ 여기에는 속도제한 문구, 레이더 감지기 그리고 ‘당신의 현재 속도’가 표시되었다.

운전자가 실시간으로 자신의 현재 속도를 알 수 있게 한 것이다.

전문가들은 이와 같은 장치의 효력을 의심했다. 운전자는 계기판만 봐도 현재 속도를 알 수 있지 않은가? 게다가 매사를 범칙금으로 해결하려는 발상은 위반사항에 대한 명백한 결과가 나올 때만 법에 복종하게 만들 뿐이다. 속도표시기가 운전행위에 무슨 대단한 영향을 주겠는가?

하지만 그렇지 않았다. 학교 세 곳을 대상으로 실시한 연구 결과에 따르면, 운전자의 속도가 14% 떨어졌다.

심지어 그들의 평균 속도는 규정 속도 ‘이하’였다. 14%면 단순한 저비용 피드백치고는 대단한 결과다.

저는 이게 뭐 살짝 억지 일수도 있다고 생각이 드는데, 요지는 너의 지금 속도를 남들도 알 수 있게 하는 것, 이게 도덕적 측면도 건드릴 수 있겠지만, 어쨌든! 나를 돌아보는것이 포인트?

피드백 루프는 성과를 개선하는 데 매우 효과적인 툴이다. 피드백을 협업 방식의 일환으로 꾸준히 활용하면, 사람들은 더 빨리 배우고 더 많은 성과를 올릴 수 있다.

피드백은 오해를 피하게 해주고 공동의 책임감을 조성하며 위계와 규정의 필요성을 줄인다.

그러나 회사에서 솔직한 피드백을 권장하기란 교통 표지판을 설치하기보다 훨씬 어려운 일이다.

짤 손가락

짤 아래글

오래전부터 당연하게 여겨졌던 고정관념을 깨뜨릴 수 있어야 한다.

상대방의 감정을 건드리고 싶지 않다는 생각과 그래도 그 사람이 성공할 수 있게 도와야 한다는 생각이다. 넷플릭스에서는 간혹 상대방의 기분을 상하게 하더라도 서로 성공할 수 있게 도우라고 말한다.

무엇보다도 올바른 환경에서 올바른 방식으로 접근하면, 상대방의 감정을 상하게 하지 않고도 피드백을 줄 수 있다는 사실을 우리는 확인했다.

조직이나 팀에서 솔직한 문화를 조성할 때 밟아야 할 몇 가지 단계가 있다. 그중 첫 번째는 상당히 비상식적이다. 즉 직원들이 상사에게 솔직한 피드백을 주게 하는 것이다. 상사가 주는 피드백은 그다음이다. 솔직함이 제대로 효과를 발휘하려면, 직원이 먼저 상사에게 진심 어린 피드백을 주어야 한다.

짤 벌거벗은 임금님

여기서 예제로 벌거벗은 임금님 The Emperor's New Clothes 를 드는데 보란 듯이 속옷바람으로 섹시하게 거리를 행진한 어리석은 임금님을 아무도 지적 못하지만, 위계와 권위와 행동에 따른 결과를 제대로 이해하지 못한 꼬마만 예외였다.

조직에서 지위가 올라갈수록 연차가 올라갈수록 들어오는 피드백은 줄어들기 마련 자칫하다가는 벌거벗은 채 섹시하게 일하거나 자신만 모르고 다른 사람들은 모두 아는 실수를 저지르고도 태연할수 있지

짤 군인

넷플의 방법: 평소에 부하직원과 일대일로 만날때 피드백을 제시하게 한다. 사실 이건 쉽지: 병장이 이등병한테 나한테 뭐 아쉬운거 있냐 하면 누가 대답하나.

그때 피드백을 받는 상사의 태도도 중요합니다

짤 손흥민

어떤 비판에도 감사한 마음으로 대응하고 '소속 신호'를 줌으로써 피드백을 마음 놓고 제시해도 좋다는 사실을 보여준다. 그런 신호를 가리켜, ‘당신은 당신의 피드백 때문에 이곳에서 더욱 중요한 멤버가 되었다’ 또는 ‘당신은 내게 솔직했다. 그로 인해 우리의 관계가 위험해지는 법은 없을 것이다. 당신이야말로 여기서 일할 자격이 있다’는 사실을 암시해 주는 메시지라고 설명한다.

그래서 직원이 상사에게 피드백을 줄 때 리더들이 ‘소속 신호’를 보여주는 것이 매우 중요하다. 공개적으로 피드백을 줄 정도로 용기 있는 직원이라고해도 ‘상사가 나를 고깝게 여기면 어쩌지?’ 혹은 ‘이러다 출세에 지장 있는 것 아냐?’와 같은 걱정을 할지 모르니까.

목소리에 감사의 뜻을 담거나 상대방에게 물리적으로 가까이 다가서거나 호의적인 시선을 보내는 것 같은 사소한 제스처도 소속 신호가 될 수 있다.

용기를 내줘서 고맙다고 말하거나 사람들 앞에서 그런 용기에 관해 언급하는 식의 적극적인 제스처도 좋은 소속 신호다.

소속 신호의 기능은 ‘지금 우리는 안전한가? 우린 앞으로 이들과 어떻게 될 것인가? 보이지 않는 위험이 숨어 있는 것은 아닐까’와 같이

오래전부터 인간의 두뇌 속에 자리 잡고 있던 질문에 대답하는 것이라고 책은 설명한다. 상사이든 부하직원이든 회사에 소속된 사람들이 소속 신호를 가지고 모든 순간에 솔직하게 응답할수록 사람들은 더욱 용기를 내어 솔직해질 것이다.

짤 아래글

4A 피드백 지침

피드백을 줄때

1 AIM TO ASSIST(도움을 주겠다는 생각으로 하라): 피드백은 선의에서 비롯 되어야 한다. 불만을 털어놓거나 의도적으로 상처를 주거나 자신의 입지를 유리하게 만들기 위한 피드백은 용납되지 않는다. 구체적인 행동 변화가 상대방 개인이나 회사에 어떻게 도움이 되는지 분명히 설명해야 한다. 자신을 위한 것이 아님을 분명히 납득시켜야 한다.

“외부 파트너와 회의할 때 이를 쑤시는 모습이 무척 거슬립니다”는 잘못된 피드백 이다. 올바른 피드백은 이런 식이어야 한다. “외부 파트너와 회의할 때 이를 쑤시는 습관을 고치신다면, 파트너들이 팀장님을 좀 더 전문가다고 여길 것이고 그래서 더욱 긴밀한 관계를 쌓을 수 있을 겁니다.”

2 ACTIONABLE(실질적인 조치를 포함하라): 피드백은 받는 사람의 행동이 변화되는 것에 초점을 맞춰야 한다. 쿠바에서 에린에게 준 피드백이 “교수님의 프레젠테이션이 메시지 자체를 망치고 있다”는 코멘트로 끝났다 면 잘못된 피드백이었을 것이다. 올바른 피드백은 이런 것이다. “청중에게 그런 방식으로 의견을 구하게 되면, 결국 미국인들만 참여하게 됩니다.” 더 좋은 방법도 있다. “회의장에 있는 다른 나라 출신들에게 의견을 구하는 방법을 찾을 수 있다면, 교수님의 메시지는 더욱 분명하게 전달 될겁니다.”

피드백 받을 때

3 APPRECIATE(감사하라): 비판을 받으면 변명부터 하려 드는 것이 인간 의 자연스러운 본능이다. 그런 상황에서는 누구나 반사적으로 자존심 이나 체면을 지키려고 한다. 그러니 피드백을 받으면 이런 자연스러운 반응을 자제하고 이렇게 자문해 봐야 한다. ‘어떻게 해야 상대방의 조언을 신중하게 듣고, 열린 마음으로 그 의미를 짚어보며, 수세를 취하거나 화를 내지 않고 감사한 마음을 표현할 수 있을까?’

4 ACCEPT OR DISCARD(받아들이거나 거부하라): 넷플릭스에서 일하다 보면 많은 사람으로부터 많은 피드백을 받게 된다. 어떤 피드백이든 일단 듣고 생각해 봐야 한다. 반드시 따를 필요는 없다. 진심을 담아 “고맙다”고 말하되, 피드백의 수용 여부는 전적으로 받는 사람에게 달렸다는 사실을 양측 모두가 이해해야 한다.

2장요약

• 솔직한 문화가 조성되면 일을 잘하는 사람을 더욱 탁월한 인재로 만들 수 있다.
• 솔직한 피드백이 잦아지면 팀과 회사의 업무 속도와 능률이 기하급수적으로 증가한다.
• 정식회의에 피드백 시간을 마련하여 사람들이 솔직하게 말할 수 있는 터전을 마련하라.
• 피드백을 효과적으로 주고받을 수 있도록 직원들을 지도하되, 4A 피드백 지침을 지키게 하라.
• 리더로서 부하직원들에게 피드백을 자주 요구하고, 피드백을 받았 을 때는 소속 신호를 보내라.
• 솔직한 문화를 도입하기 전에 똑똑한 왕재수부터 녹아내라.

짤 빨간페이지

짤 텅빈 사무실

자기 인생은 자기가 책임을 지는 것이니 언제 일하고 언제 쉴지는 각자 알아서 정하게 하자는 아이디어였다.

휴가 때문에 회사가 망하는 것 아냐?

짤 아래 글

규정을 없애니 관료주의적 풍조가 줄었고, 누가 언제 얼마 동안 자리를 비우는지 추적하는 데 들여야 했던 행정 비용도 사라졌다. 무엇보다 그러한 자유는 직원들이 자신의 휴가를 잘 활용하리라는 걸 회사가 믿고 있다는 걸 보여줌으로써, 그들 스스로 더욱 책임감 있게 행동하게 끔 부추겼다.

리더부터 과감한 휴가로 솔선수범하라

책임질 자유를 주라

짤 빨간 페이지

짤 아래 글

지급할 액수뿐 아니라, 지급하는 방법도 중요하다

지급한다. 보너스는 정해진 목표를 달성했을 때 지급된다. 최고 수 준 인재들의 보수는 대부분 성과가 좌우한다.

짤 아래글

짤 아래글

보너스는 유연성에 좋지 않다

토끼 짤

내가 즐겨 인용하는 말 중에는 도이체방크 DeutscheBank의 CEO였던 존 크라이언 JohnCryan의 푸념이 있다. “나는 내 근로 계약서에 보너스 조항이 왜 들어 있는지 그 이유를 알 수가 없다. 누가 어느 날 어느 해에 돈을 더 주거나 덜 준다고 해서 더 열심히 일하거나 게으름을 피우는 일은 없을 것이라고 이미 약속하지 않았는가?” 자신의 연봉 값을 하는 임직원이라면 누구나 같은 말을 할 것이다.

짤 아래 글

다른 회사보다 더 많이 지급하라

어차피 애매하게 더 주면 또 떠나게 되어있다.

최고 수준 유지하기

그 정도의 연봉을 받고 회사에 들어오면, 처음에는 누구나 최고 수준의 보수를 받고 있다는 생각에 의욕적으로 일한다. 그러나 일을 하면서 더 좋은 기술을 갖춰갈수록, 경쟁사들로부터 더 많은보수를 주겠다는 제의가 들어온다. 그 정도의 금액을 받을 가치 가 있는 사람이라면, 시장가치가 계속 올라가기 때문에 다른 곳으로 이직할 위험도 커진다. 그런데 역설적이게도 보수를 조정하는 문제에 관한한세상의 거의 모든 회사가 직원들을 나가게 만드는 시스템을 채택한다. 당연히 인재 밀도도 떨어질 수밖에 없다.

리크루터에게서 전화가 오면 "얼마를 주실 건가요?"라고 물어라

리크루터의 전화를 받을 때 넷플릭스의 원칙은 이렇다. “‘고맙 지만 사양하겠습니다!’라고 말하기 전에, ‘얼마를 주실 건가요?’라고 물어보라.”

짤 메이플스토리

0 직원들이 네트워크를 만들고 시간을 내 자신이나 팀의 시장가치가 시간이 지나면서 어떻게 변하는지 확인하도록 교육하라. 직원들이 리크루터의 전화를 받거나 다른 회사와 인터뷰하게 될 수도 있다. 그에 따라 연봉을 조정하라.

짤 빨간 글

짤 아래글

상사의 비위를 맞추려 들지 말라. 회사에 가장 이득이 되게 행동하라.

짤 카지노

넷플릭스에 처음 왔을 때, 상사인 잭은 제게 칩을 몇 개 받은 것 으로 생각하라고 했어요. 승산이 있다고 생각하는 쪽에 칩을 걸라고요. 하지만 제 베팅이 최고의 베팅이 될 수 있도록 신중히 생각해야겠죠. 그가 요령을 설명해 주었어요. “베팅하다 보면 실패하기도 하고 성공하기도 합니다. 그런 개별적인 성패는 그다지 중요하지 않아요. 성과는 칩을 활용하여 사업을 얼마나 진척시켰는지 그 칩의 전반적인 운용 능력에 따라 평가받습니다. 넷플릭스에서는 베팅을 잘못했다고 쫓아내지 않습니다. 그 보다는 큰일을 벌일 수 있는데도 칩을 사용하지 않거나, 잘못된 판단이 장기간 이어질 경우에만 쫓겨납니다.”

짤 묻더가!

1. 이의 제기를 장려하거나, 아이디어를 공유하라.
2. 빅 아이디어는 테스트를 거쳐라.
3. 정보에 밝은 주장으로서 베팅하라.
4. 성공하면 축하하고, 실패하면 선샤이닝하라.

넷플릭스는 어떤 아이디어를 찬성하지 않을 때 그런 사실을 표현하지 않는 것은, 넷플릭스에 대한 불충이라고 말한다. 자신의 의견을 묻어두는 것은 회사를 돕지 않겠다는 말 없는 시위다.

짤 아래 글

물론,, 빅 아이디어는 테스트를 거쳐라

정보에 밝은 주장으로서 베팅하라

이의제기를 장려하라, 아이디어를 공유하라. 테스트하라. 이렇게 말하면 합의를 모으는 과정처럼 들리겠지만 그렇지 않다. 집단은 합의를 통해 결정한다. 그러나 넷플릭스에서는 그렇게 하지 않는다. 누구나 일을 하면서 필요할 때 동료에게 손을 내밀지만, 일을 진척시킬 때는 누구의 승인도 받지않는다. 우리의 4단계 혁신 사이클은 다른 사람의 의견을 바탕으로, 개인이 결정하는 과정이다.

짤 아래글

성공하면 축하하고, 실패하면 선샤이닝하라

무엇보다 ‘반드시’ 잊지 말아야 할 것이 있다. 당신이 반신반의하고 심지어 부정적인 의견을 냈는데도, 고집을 꺾지 않고 밀어붙인 셰일라의 뚝심을 드러내 칭찬해야 한다는 점이다.

공적인 자리에서 하면 더욱 좋다. “자네가 옳았어! 내 생각은 틀렸고!”

이처럼 상사의 의견에 부하직원이 제동을 걸어도 전혀 문제 될 것이 없다는 것을 전 직원에게 보여주어야 한다.

1. 그 프로젝트에서 무엇을 배웠는지 물어보라.
2. 그 일로 수선을 피우지 말라.
3. 그녀에게 실패를 선샤이닝하라고 요청하라.

성과를내지못한베팅을두고법석을떠는것은,앞으로 모험 따위는 생각도 하지 말라는 경고와 다를 바 없다.

넷플릭스에서는 실패한 모험을 숨기지 말고 백주에 다 드러내라고 말합니다. 이를 가리켜 ‘선샤이닝’이라고 하죠. 저는 리더들이 자신의 실수를 낱낱이 고백하는 모습을 보아왔기 때문에 제 실패를 선샤이닝할 뿐 아니라, 요란한 플래시 세례도 사양하지 않기로 마음먹 었어요.

한 사람이 실패 사례를 선샤이닝하면, 모두가 승자가 된다. 사람들은 그 사람이 자기의 실수를 솔직하게 말하면서 그 행동에 책임을 지는 모습을 보며 신뢰하게 되므로 그 사람 역시 승자가 된다.

그의 팀도 실패로 귀결된 프로젝트의 결과에서 분명 무언가를 배웠을 테니 역시 승자가 된다. 무엇보다 실패한 베팅은 혁신적 성공의 수레바퀴의 본래적 일부라는 사실을 모두가 똑똑히 볼 수 있 기 때문에 회사도 승자가 된다.

실패를 두려워해선 안 된다. 실패를 적극적으로 포용해야 한다.

그리고 실수를 더 많이 선샤이닝하라!

짤 아래글

큰 실수를 저질렀을 때는 본능적으로 발을 빼고 싶은 생각부터 든다. 넷플릭스에서는 권하지 않는 태도다. 실수를 저지르고도 무사하려면,

더욱더 햇볕으로 나아가야 한다. 사실대로 말하면 용서 받을 수 있다. 적어도 처음 몇 번은 말이다.

그러나 실수를 얼버무리려 하거나 같은 실수를 반복한다면(실수를 인정하지 않으면 반복할 가능성이 커진다), 결과는 심각해진다.

짤 빨간 페이퍼

가족은 ,성과와 관계없이 함께하는 집단이다

짤 심슨

프로스포츠팀은 높은 인재 밀도의 좋은 비유다. 프로팀의 선수 들은 다음과 같기 때문이다.

짤 미식축구

• 뛰어난 기량이 요구된다. 그래서 매니저들은 필요한 때 모든 자리를 최고의 인재들로 채워야 한다. • 이기는 팀이 되도록 훈련받는다. 그래서 감독과 다른 선수들이 경기에 대해 지속적으로 솔직한 피드백을 주고받는다. • 열심히 하는것 만으로는 안된다. 그래서 제일 열심히 노력했는데 도결과가 시원치 않으면, 매니저는 최대한 예의를 갖춰 그동안 고마웠다는 말과 함께 그를 내보내고 다른 선수로 교체한다.

성과가 뛰어난 팀은 협업 능력과 서로에 대한 신뢰가 남다르다. 모든 구성원이 자신이 하는 일과 다른 사람과 함께하는 일에서 뛰어난 기량을 발휘하기 때문이다. 기량이 뛰어난 사람으로 인정받 으려면 놀라운 실력만으로는 부족하다. 이기심을 자제하고 남을 먼저 생각할 줄 알아야 한다. 언제 공을 패스할지 알아야 하고, 동료가 골을 넣을 수 있도록 결정적인 어시스트를 해야 하며, 팀이 이길 때만 내가 이긴다는 사실을 인정해야 한다. 그것이 바로 넷플릭스에서 우리가 만들고자 하는 문화다.

우리는 가족이 아니라, 팀이다.

짤 아래글

키퍼 테스트

팀원 중 한 사람이 내일 그만두겠다고 하면, 다시 한번 생각해 보라고 설득하겠는가, 아니면 속으로 다행이라 생각하며 사직서를 수리하겠는가? 후자라면 지금 당장 그에게 퇴직금을 주고 스타 플레이어를 찾아라. 어떻게 해서든지 지켜야 할 사람을 말이다.

넷플릭스는 모든 사람에게 키퍼 테스트를 적용하려고 한다. 우리 자신도 예외는 아니다. 내가 맡은 일을 다른 사람이 하면 회사가 더 잘될까? 이렇게 하는 이유는 누구를 내보낼 때 부끄럽지 않기 위해서다.

넷플릭스는 직원들에게 업계 최고의 대우를 해주고, 모두 고액 연봉을 받는다. 그들은 우리 회사가 빠르게 변신해야 하고, 그런 점에서 우리가 그들에게 남다른 성과를 기대한다는 점을 이해하고 있다. 그래서 넷플릭스에서 일하기로 작정한 사람들은 모두 우리의 높은 인재 밀도를 유지하는 정책을 알고 선택했다. 우리는 우리의 전략 을 투명하게 운영하고 직원들은 그런 탁월한 수준의 동료들과 함 께 일하는 것을 즐거워하기 때문에, 그에 따른 약간의 직업적 위험은 기꺼이 감수하는 편이다. 장기간 안정을 보장해 주는 직업을 선호하는 사람들은 넷플릭스에 들어올 생각을 하지 않는다. 그렇다. 나는 우리의 방식이 윤리적으로 문제가 없다고 생각한다. 그리고 또한 대부분의 직원도 그런 방식을 좋아한다.

누군가를 내보낼 때마다 우리는 여러 달 치의 월급, 그러니까 적게는 4개월 치부터 부사장의 경우 9개월 치의 월급을 지급 한다. 그래서 우리는 이렇게 말한다. 적당히 일해도 퇴직금은 후하다.

즉각적인 키퍼 테스트

“제가 일을 그만둔다고 한다면, 어떻게 해서든 저를 붙잡으실 건가요?”

상사에게 즉각적인 키퍼 테스트 질문을 했을 때 나올 수 있는 답변은 세 가지예요. 첫째, 상사가 무슨 수를 써서라도 당신을 놓치지 않겠다고 말하는 경우죠. 이런 답을 들으면 그동안 잠을 설치게 만들었던 두려움이 말끔히 사라질 것입니다.

둘째, 상사가 명확하게 답변하지는 않지만, 성과를 개선할 수 있도록 분명한 피드백을 주는 경우입니다. 이 역시 당신이 제 역할을 할 수 있도록 도와주는 말이니 나쁘지 않죠.

셋째, 상사가 당신을 지키기 위해 노력할 기색이 없어 보이는 경우입니다. 이때는 괜히 쓸데없는 질문을 한 셈일 수도 있습니 다. 그런 질문으로 인해 당신의 상사는 그동안 딱히 생각해 보지 않았던 당신의 부정적인 측면을 진지하게 따져보게 될 테니 까요. 그러니 이런 질문을 하는 것 자체가 조금은 걱정되겠죠. 하지만 이 역시 좋은 일입니다. 이를 계기로 지금 하는 일이 당 신의 능력에 맞는지 확실히 따져볼 기회가 되기 때문이죠. 아무 것도 모르고 있다가 어느 날 아침, 느닷없이 회사를 그만두라는 통고를 받는 것보다는 낫지 않을까요?

누구나, 아니 어떤 회사든 좋은 인재를 가지고 일을 하고 싶은건 당연한거죠, 여기 넷플 사장님이 인재밀도가 중요하다고 생각한 터닝 포인트.

회사가 갑자기 어려워져서 고심끝에 성과, 포텐셜, 인사고과 이런거로 판단해서 하위 30%를 짤랐어요,

그런데 얼마 후 우편 주문 DVD 대여업의 난데없는 호황을 맞았는데

진짜 직원들 겁나 바쁘고 늦게까지 퇴근하지 못해도 사기는 하늘을 찌를듯했다고 합니다 (사장눈에만 그렇게 보였을 수도)

근데 이게 생각해보면 되게 좋은거죠, 스포츠를 하던 일을하던, 무엇을 하던 손발이 척척 맞고, 일 잘하는 사람끼리 일하면 개떡같이 말해도 찰떡같이 알아듣지만 개떡같이 말하는 사람도 없고 진행 빠르고 뭔가 일 잘 풀리고 그럼 자아실현되고 WIN WIN 이져,

재능 있는 사람들을 서로 능률을 높인다.

전체로 보면 수가 줄었지만 인재의 "밀도" 가 증가한 것이죠.

팀에 평범한 사람이 1~2명 섞여 있으면 팀 전체의 성과가 떨어집니다. 탁월한 인재 5명과 평범한 사람 2명이 함께 있으면 그 팀은 평범한 팀이 된다.

• 매니저의 기운을 빼 최고의 성과를 내지 못하게 만든다. • 그룹 토의의 질을 떨어뜨려 팀의 전반적인 IQ를 낮춘다. • 사람들이 싫어할 일을 하게 만들어 능률을 떨어뜨린다. • 남보다 탁월한 능력을 발휘하고 싶은 직원을 회사에서 나가게 만든다. • 평범한 사람도 받아준다는 사실을 보여줌으로써 문제를 복잡하게만 든다.

재능이 뛰어난 (선천적이던, 후천적이던) 베스트 플레이어들이 생각하는 좋은 직장의 조건은 호화스러운 사무실이나 멋진 체육관, 혹은 공짜 스시같은 (대략 쩌는 복지) 같은게 아니라

그들에게 중요한건, 일을 더 잘할 수 있게 해주는 사람이 필요하다. 모든 직원이 뛰어나면 서로에게 배우고 서로가 의욕을 불어넣어 성과는 수직으로 상승한다.

왜냐면 실무자의 커리어는 여기서 끝나는 것이 아니기 때문에, 아무리 복지 좋아도 같이 일하는 사람들이 일을 못해서 내가 성과가 잘 안나면 내 커리어도 멈추기 마련이지 않을까요?

성과는 전염성이 강하다.

호주 뉴사우스웨일스 대학교에서 직장에서 행동이 강한 전염성을 갖는다는 사실을 보여주는 흥미로운 연구가 있죠.

각 팀마다 45분안에 관리 업무를 끝내라는 과제였고 1등한 팀에게는 100달러 보상을 주기로 했는데, 각 팀마다 몰래 연구팀 스파이를 꼈습니다.

게으름뱅이역, 삐딱이역, 우울한 비관주의자, 이런 역할이 낀 팀은 재능이 뛰어난 팀원들도 전염이되어서 전체의 능률이 떨어진다는 결과 1명이라도 수준에 미치지 못하는 사람이 1명이라도 있는 팀은 그렇지 않은 팀에 비해 성과가 무려 30~40% 뒤쳐졌습니다. "놀라운 사실은 다른 팀원들이 문제가 되는 사람의 특성을 흉내 내기 (따라하기) 시작한다는 점"

1장요약

• 리더로서 당신의 첫 번째 목표는 직장에 비범한 동료들로만 채워진 근무 환경을 조성하는 것이다.
• 비범한 동료들은 중요한 일을 능숙하게 처리한다. 또한 놀라울 정도 로 창의적이고 열정적이다.
• 심사가비뚤어졌거나게으르거나착하긴한데성과는별볼일없 거나 매사를 부정적으로 보는 사람들이 끼어 있으면, 팀의 전반적인 성과가 저하된다.

솔직하고 정확하게 단, 상대를 공격하거나 마음 상하게하려는 의도가 아니라, 어디까지나 선의를 가지고 정식으로 문제를 제기한 후, 자신의 감정과 의견, 상대방에 대한 피드백을 솔직하게 표현하게 한것.

뒤에서 수군거릴 게 아니라, 당당히 마주 보면서 자신의 의견이 나 상대방에 대한 피드백을 명확히 전달하면, 책략이나 은밀한 소 통이 줄어들고 업무를 더욱 빨리 처리할 수 있다 나는 그러한 사 실을 여러 경로를 통해 확인했다. 잘한다는 말을 많이 들을수록 사람들은 더 잘하게 되고, 이와 같은 그들의 변화가 하나의 기업 으로서의 우리 성과를 더욱 높였다.

물론 아주 과격한 방법이다. 사교적 인 경우든 업무와 관련된 일이든, 얼굴을 마주 보며 자신의 생각 을 가감 없이 말하다가는 금방 외톨이가 되고 심지어 회사에서 쫓 겨날 수도 있다. 그러나 넷플릭스에서는 그런 것들이 모두 허용된 다. 우리는 직원들이 평소에 상호 발전적인 피드백을 주고받는 분 위기를 만들기 위해 애쓴다. 윗사람이든 동년배이든 아랫사람이 든, 가리지 않고 말이다.

높은 성과 + 사심없는 솔직함 = 대단히 높은 성과

• 사람들이 내견해를 지지하지 않을것같다. • ‘까다로운’사람이라는 인상을 주고 싶지않다. • 내키지 않는 논쟁에 말려들고 싶지않다. • 동료들의 비위를 거스르거나 화를 돋우고 싶지 않다. • ‘비협조적인’ 사람으로 낙인찍히기 싫다.

동료의 의견에 동의하지 않거나 도움이 될 만한 피드백이 있는 데도 말하지 않는 것은, 회사에 불충한 것이다. 넷플릭스에서는 그 렇다. 업무에 도움이 될 수 있는데도 돕지 않기로 한 것이니까.

피드백을 ‘자주’ 하라고 독려한다. 하지만 내 경험으로 볼 때 그렇게 해봐야 마음 상할 일만 늘어날 것 같다. 귀에 거슬리는 말 을 듣기 싫어하는 것은 인지상정 아닌가? 그래 봐야 부정적인 생 각만 들 것 같다. 솔직한 피드백을 자주 하라고 부추기는 규정은 불쾌감을 조장할 뿐 아니라, 위험해 보이기까지 한다.

우리는 솔직한 것을 싫어한다 【그러면서도 솔직하기를 바란다】

비판을 듣기 휴수하는 사람은 거의 없다. 자신이 한 일에 대해 누 가 조금이라도 안 좋은 이야기를 하면, 누구나 민감해져서 상대의 의도를 의심하고 화부터 내게 된다. 부정적인 피드백을 받을 때 인간의 두뇌는 신체적인 위협을 받을 때와 마찬가지로 싸우거나 달아나는 반응fight-or-flight reaction을 보이는데, 혈류로 호르몬이 분비 되고 대응 시간이 빨라지며 감정이 격해진다.

일대일로 비난받는 것보다 더 싫은 것은, 여러 사람 앞에서 부 정적인 피드백을 받는 것이다.

피드백 로프, 솔직한 문화 조성

2003년 캘리, LA 가든그로브

초등학교 인근에서 차와 보행자 관련 사고가 유난히 자주 발생해서 당국은 운전자의 속도를 낮추기 위해 속도제한 표지판을 설치했고, 경찰은 이를 위반한사람에게 범칙금을 부과했지만

그런데도 사고는 좀처럼 줄지 않았다.

도시 엔지니어들은 방법을 바꿔서 즉석 속도표시기를 설치했다.

‘운전자 피드백’ 여기에는 속도제한 문구, 레이더 감지기 그_리고 ‘당신의 현재 속도’가 표시되었다.

운전자가 실시간으로 자신의 현재 속도를 알 수 있게 한 것이다.

전문가들은 이와 같은 장치의 효력을 의심했다. 운전자는 계기판만 봐도 현재 속도를 알 수 있지 않은가? 게다가 매사를 범칙금 으로 해결하려는 발상은 위반사항에 대한 명백한 결과가 나올 때 만 법에 복종하게 만들 뿐이다. 속도 표시기가 운전 행위에 무슨 대단한 영향을 주겠는가?

하지만 그렇지 않았다. 학교 세 곳을 대상으로 실시한 연구 결 과에 따르면, 운전자의 속도가 14% 떨어졌다.

심지어 그들의 평균 속도는 규정 속도 ‘이하’였다. 14%면 단순한 저비용 피드백치고는 대단한 결과다.

뭐 살짝 억지 일수도 있다고 생각이 드는데, 요지는 너의 지금 속도를 남들도 알 수 있게 하는 것, 이게 도덕적 측면도 건드릴 수 있겠지만, 어쨌든! 나를 돌아보는것이 포인트?

피드백 루프는 성과를 개선하는 데 매우 효과적인 툴이다. 피드백을 협업 방식의 일환으로 꾸준히 활용하면, 사람들은 더 빨리 배우고 더 많은 성과를 올릴 수 있다. 피드백은 오해를 피하게 해주고 공동의 책임감을 조성하며 위계와 규정의 필요성을 줄인다.

그러나 회사에서 솔직한 피드백을 권장하기란 교통 표지판을 설치하기보다 훨씬 어려운 일이다.

솔직한 분위기를 조성하려면 ‘누군가가 요구할 때만 피드백을 주어라’. ‘칭찬은 공개적으로 하고 비판은 사적으로 하라’와 같이

오래전부터 당연하게 여겨졌던 고정관념을 깨뜨릴 수 있어야 한다.

갈등한다. 상대방의 감정을 건드리고 싶지 않다는 생각과 그래도 그 사람이 성공할 수 있게 도와야 한다는 생각이다. 넷플릭스에서 는 간혹 상대방의 기분을 상하게 하더라도 서로 성공할 수 있게 도우라고 말한다. 무엇보다도 올바른 환경에서 올바른 방식으로 접근하면, 상대방의 감정을 상하게 하지 않고도 피드백을 줄 수 있다는 사실을 우리는 확인했다.

조직이나 팀에서 솔직한 문화를 조성할 때 밟아야 할 몇 가지 단계가 있다. 그중 첫 번째는 상당히 비상식적이다. 흔히들 솔직하 기 위해서는 쉬운 쪽부터 시작해야 한다고 생각할지 모르겠다. 가 령 상사가 먼저 부하직원에게 피드백을 많이 주는 식이다. 하지만 나는 먼저 훨씬 더 어려운 쪽을 택할 것을 추천한다. 즉 직원들이 상사에게 솔직한 피드백을 주게 하는 것이다. 상사가 주는 피드백 은 그다음이다. 솔직함이 제대로 효과를 발휘하려면, 직원이 먼저 상사에게 진심 어린 피드백을 주어야 한다.

여기서 예제로 벌거벗은 임금님 The Emperor's New Clothes 를 드는데 보란 듯이 속옷바람으로 섹시하게 거리를 행진한 어리석은 임금님을 아무도 지적 못하지만, 위계와 권위와 행동에 따른 결과를 제대로 이해하지 못한 꼬마만 예외였다.

조직에서 지위가 올라갈수록 연차가 올라갈수록 들어오는 피드백은 줄어들기 마련 자칫하다가는 벌거벗은 채 섹시하게 일하거나 자신만 모르고 다른 사람들은 모두 아는 실수를 저지르고도 태연할수 있지

넷플의 방법: 평소에 부하직원과 일대일로 만날때 피드백을 제시하게 한다. 사실 이건 쉽지: 병장이 이등병한테 나한테 뭐 아쉬운거 있냐 하면 누가 대답하나.

그때 피드백을 받는 상사의 태도도 중요.

어떤 비판에도 감사한 마음으로 대응하고 '소속 신호'를 줌으로써 피드백을 마음 놓고 제시해도 좋다는 사실을 보여준다.그런 신호를 가리켜, ‘당신은 당신의 피드백 때문 에 이곳에서 더욱 중요한 멤버가 되었다’ 또는 ‘당신은 내게 솔직 했다. 그로 인해 우리의 관계가 위험해지는 법은 없을 것이다. 당 신이야말로 여기서 일할 자격이 있다’는 사실을 암시해 주는 메 시지라고 설명한다. 그래서 직원이 상사에게 피드백을 줄 때 리 더들이 ‘소속 신호’를 보여주는 것이 매우 중요하다. 공개적으로 피드백을줄정도로용기 있는직원이라고해도‘상사가나를고 깝게 여기면 어쩌지?’ 혹은 ‘이러다 출세에 지장 있는 것 아냐?’와 같은 걱정을 할지 모르니까.

목소리에 감사의 뜻을 담거나 상대방에게 물리적으로 가까이 다가서거나 호의적인 시선을 보내는 것 같은 사소한 제스처도 소 속 신호가 될 수 있다. 용기를 내줘서 고맙다고 말하거나 사람들 앞에서 그런 용기에 관해 언급하는 식의 적극적인 제스처도 좋은 소속 신호다. 소속 신호의 기능은 ‘지금 우리는 안전한가? 우린 앞 으로 이들과 어떻게 될 것인가? 보이지 않는 위험이 숨어 있는 것 은 아닐까’와 같이 오래전부터 인간의 두뇌 속에 자리 잡고 있던 질문에 대답하는 것이라고 코일은 설명한다. 상사이든 부하직원이든 회사에 소속된 사람들이 소속 신호를 가지고 모든 순간에 솔직하게 응답할수록 사람들은 더욱 용기를 내어 솔직해질 것이다.

4A 피드백 지침

피드백을 줄때

1 AIM TO ASSIST(도움을 주겠다는 생각으로 하라): 피드백은 선의에서 비롯 되어야 한다. 불만을 털어놓거나 의도적으로 상처를 주거나 자신의 입 지를 유리하게 만들기 위한 피드백은 용납되지 않는다. 구체적인 행동 변화가 상대방 개인이나 회사에 어떻게 도움이 되는지 분명히 설명해 야 한다. 자신을 위한 것이 아님을 분명히 납득시켜야 한다.

“외부 파트너와 회의할 때 이를 쑤시는 모습이 무척 거슬립니다”는 잘못된 피드백 이다. 올바른 피드백은 이런 식이어야 한다. “외부 파트너와 회의할 때 이를 쑤시는 습관을 고치신다면, 파트너들이 팀장님을 좀 더 전문가답 다고 여길 것이고 그래서 더욱 긴밀한 관계를 쌓을 수 있을 겁니다.”

2 ACTIONABLE(실질적인 조치를 포함하라): 피드백은 받는 사람의 행동이 변화되는 것에 초점을 맞춰야 한다. 쿠바에서 에린에게 준 피드백이 “교 수님의 프레젠테이션이 메시지 자체를 망치고 있다”는 코멘트로 끝났다 면 잘못된 피드백이었을 것이다. 올바른 피드백은 이런 것이다. “청중에 게 그런 방식으로 의견을 구하게 되면, 결국 미국인들만 참여하게 됩니 다.” 더 좋은 방법도 있다. “회의장에 있는 다른 나라 출신들에게 의견을 구하는 방법을 찾을 수 있다면, 교수님의 메시지는 더욱 분명하게 전달 될겁니다.”

피드백 받을 때

3 APPRECIATE(감사하라): 비판을 받으면 변명부터 하려 드는 것이 인간 의 자연스러운 본능이다. 그런 상황에서는 누구나 반사적으로 자존심 이나 체면을 지키려고 한다. 그러니 피드백을 받으면 이런 자연스러운 반응을 자제하고 이렇게 자문해 봐야 한다. ‘어떻게 해야 상대방의 고언 을 신중하게 듣고, 열린 마음으로 그 의미를 짚어보며, 수세를 취하거나 화를 내지 않고 감사한 마음을 표현할 수 있을까?’

4 ACCEPT OR DISCARD(받아들이거나 거부하라): 넷플릭스에서 일하다 보 면 많은 사람으로부터 많은 피드백을 받게 된다. 어떤 피드백이든 일단 듣고 생각해 봐야 한다. 반드시 따를 필요는 없다. 진심을 담아 “고맙 다”고 말하되, 피드백의 수용 여부는 전적으로 받는 사람에게 달렸다는 사실을 양측 모두가 이해해야 한다.

2장요약

• 솔직한문화가조성되면일을잘하는사람을더욱탁월한인재로만 들 수 있다.
• 솔직한 피드백이 잦아지면 팀과 회사의 업무 속도와 능 률이 기하급수적으로 증가한다.
• 정식회의에피드백시간을마련하여사람들이솔직하게말할수있 는 터전을 마련하라.
• 피드백을 효과적으로 주고받을 수 있도록 직원들을 지도하되, 4A 피드백 지침을 지키게 하라.
• 리더로서 부하직원들에게 피드백을 자주 요구하고, 피드백을 받았 을 때는 소속 신호를 보내라.
• 솔직한 문화를 도입하기 전에 똑똑한 왕재수부터 녹아내라.

자기 인생은 자기가 책임을 지는 것이니 언제 일하고 언제 쉴지 는 각자 알아서 정하게 하자는 아이디어였다.

휴가 때문에 회사가 망하는 것 아냐?

규정을 없애니 관료주의적 풍조가 줄었고, 누가 언제 얼마 동안 자리를 비우는지 추적하는 데 들여야 했던 행정 비용도 사라졌다. 무엇보다 그러한 자유는 직원들이 자신의 휴가를 잘 활용하리라는 걸 회사가 믿고 있다는 걸 보여줌으로써, 그들 스스로 더욱 책임감 있게 행동하게 끔 부추겼다.

리더부터 과감한 휴가로 솔선수범하라

책임질 자유를 주라

회삿돈을 내 돈처럼 생각하고 쓰라?

ㄴㄴ

넷플릭스에 가장 이득이 되게 행동하라

첫 단계에서 맥락을 정한 후, 마지막 단계까지 지출을 감시하라

속이는 사람이 있어도, 실보다는 득이 많다

자유를 줄 때 맥락을 설정하고 남용의 결과를 똑똑히 보 B여주어도, 제도를 악용하는 사람들은 있게 마련이다. 그 럴 때 과민반응하거나 규정을 늘릴 필요는 없다. 사정이 있을 거 라고 생각하면서 계속 밀고 나아가면 된다.

클라우디오의 사례를 보면, 규정이라는 것이 얼마나 귀에 걸면 귀걸이, 코에 걸면 코걸이인지 짐작할 수 있다. 규정을 정하면 어 떻게든 자신에게 유리한 쪽으로 해석해 보려고 열심히 머리를 굴 리는 사람들이 있다. 만약 비아콤이 ‘애피타이저 하나와 메인 코스 하나 그리고 2명에 와인 1 병을 주문할 수 있다’라는 규정을 세운 다면, 캐비어와 랍스터, 샴페인 1 병을 주문할 사람도 있을 것이다. 규정을 지켰지만, 아주 비싼 돈이 나간다. 하지만 회사에 가장 이 득이 되는 쪽으로 정하라고 말해주면, 시저샐러드와 닭가슴살, 맥 주 2병 정도를 시키는 것도 가능하다. 규정이 있다고 해서 꼭 돈이 절약되는 건 아니라는 이야기다.

지급할 액수뿐 아니라, 지급하는 방법도 중요하다

지급한다. 보너스는 정해진 목표를 달성했을 때 지급된다. 최고 수 준 인재들의 보수는 대부분 성과가 좌우한다.

보너스는 유연성에 좋지 않다

내가 즐겨 인용하는말중에는도이체방크DeutscheBank의CEO였던존크라이 언JohnCryan의 푸념이 있다. “나는 내 근로 계약서에 보너스 조항이 왜 들어 있는지 그 이유를 알 수가 없다. 누가 어느 날 어느 해에 돈을 더 주거나 덜 준다고 해서 더 열심히 일하거나 게으름을 피 우는 일은 없을 것이라고 이미 약속하지 않았는가?” 자신의 연봉 값을 하는 임직원이라면 누구나 같은 말을 할 것이다.

20만 달러에 보너스 15%를 제시하고, 또 한쪽은 연 봉 23만 달러를 제시한다. 어느 쪽을 택하겠는가? 당연히 숲속의 새보다는 당장 손 안에 들어온 새, 즉 23만 달러를 택할 것이다.

다른 회사보다 더 많이 지급하라

• 현재당신팀의프로그래머중데빈이방금그만둔애플에발탁될만한실력을 갖춘 사람이 있나요? 아뇨.

• 당신이지금데리고있는팀원중3명이힘을합하면데빈만큼의기여 를 할수 있습니까? 아뇨. • 소원을들어주는요정이나타나조용히눈치못채게현재프로그래머 몇 명을 데빈과 바꿔놓는다면, 그편이 회사에 도움이 될까요? 네.

최고 수준 유지하기

그 정도의 연봉을 받고 회사에 들어오면, 처음에는 누구나 최 고 수준의 보수를 받고 있다는 생각에 의욕적으로 일한다. 그러나 일을 하면서 더 좋은 기술을 갖춰갈수록, 경쟁사들로부터 더 많은보수를 주겠다는 제의가 들어온다. 그 정도의 금액을 받을 가치 가 있는 사람이라면, 시장가치가 계속 올라가기 때문에 다른 곳으 로 이직할 위험도 커진다. 그런데 역설적이게도 보수를 조정하는 문제에 관한한세상의 거의 모든회사가직원들을나가게 만드는 시스템을 채택한다. 당연히 인재 밀도도 떨어질 수밖에 없다.

리크루터에게서 전화가 오면 "얼마를 주실 건가요?"라고 물어라

리크루터의 전화를 받을 때 넷플릭스의 원칙은 이렇다. “‘고맙 지만 사양하겠습니다!’라고 말하기 전에, ‘얼마를 주실 건가요?’라 고 물어보라.”

® 4장요약 0 일반적인 회사들이 직원을 충원하는 방법은, 창의적이고 인재 밀도 가 높은 직장에는 그다지 바람직하지 않다. 0 창의적인 업무와 운영 업무를 구분하라. 창의적 업무를 하는 직원에 게는 시장 최고의 대우를 하라. 적당한 수준의 직원을 10명 채용하 는것보다아주뛰어난직원 1명을앉히는편이 낫다. 0 성과 기반의 보너스를 제공하지 말라. 그런 자원은 연봉에 포함하라. 0 직원들이 네트워크를 만들고 시간을 내 자신이나 팀의 시장가치가 시간이 지나면서 어떻게 변하는지 확인하도록 교육하라. 직원들이 리크루터의 전화를 받거나 다른 회사와 인터뷰하게 될 수도 있다. 그에 따라 연봉을 조정하라.

상사의 비위를 맞추려 들지 말라. 회사에 가장 이득이 되게 행동하라.

넷플릭스에 처음 왔을 때, 상사인 잭은 제게 칩을 몇 개 받은 것 으로 생각하라고 했어요. 승산이 있다고 생각하는 쪽에 칩을 걸라고요. 하지만 제 베팅이 최고의 베팅이 될 수 있도록 신중 히 생각해야겠죠. 그가 요령을 설명해 주었어요. “베팅하다 보 면 실패하기도 하고 성공하기도 합니다. 그런 개별적인 성패는 그다지 중요하지 않아요. 성과는 칩을 활용하여 사업을 얼마나 진척시켰는지 그 칩의 전반적인 운용 능력에 따라 평가받습니 다. 넷플릭스에서는 베팅을 잘못했다고 쫓아내지 않습니다. 그 보다는 큰일을 벌일 수 있는데도 칩을 사용하지 않거나, 잘못된 판단이 장기간 이어질 경우에만 쫓겨납니다.”

1. 이의 제기를 장려하거나, 아이디어를 공유하라. 2. 빅 아이디어는 테스트를 거쳐라.
2. 정보에 밝은 주장으로서 베팅하라.
3. 성공하면 축하하고, 실패하면 선샤이닝하라.

이 제 우리는 어떤 아이디어를 찬성하지 않을 때 그런 사실을 표현하 지 않는 것은, 넷플릭스에 대한 불충이라고 말한다. 자신의 의견을 묻어두는 것은 회사를 돕지 않겠다는 말 없는 시위다.

물론,, 빅 아이디어는 테스트를 거쳐라

정보에 밝은 주장으로서 베팅하라

이의제기를 장려하라, 아이디어를 공유하라. 테스트하라. 이렇게 말하면 합의를 모으는 과정처럼 들리 겠지만 그렇지 않다. 집단은 합의를 통해 결정한다. 그러나 넷플릭 스에서는 그렇게 하지 않는다. 누구나 일을 하면서 필요할 때 동 료에게 손을 내밀지만, 일을 진척시킬 때는 누구의 승인도 받지않는다. 우리의 4단계 혁신 사이클은 다른 사람의 의견을 바탕으 로, 개인이 결정하는 과정이다.

성공하면 축하하고, 실패하면 선샤이닝하라

무엇보다 ‘반드시’ 잊지 말아야 할 것이 있다. 당신이 반신반의하 고 심지어 부정적인 의견을 냈는데도, 고집을 꺾지 않고 밀어붙인 셰일라의 뚝심을 드러내 칭찬해야 한다는 점이다. 공적인 자리에 서 하면 더욱 좋다. “자네가 옳았어! 내 생각은 틀렸고!” 이처럼 상 사의 의견에 부하직원이 제동을 걸어도 전혀 문제 될 것이 없다는 것을 전 직원에게 보여주어야 한다.

1. 그 프로젝트에서 무엇을 배웠는지 물어보라.
2. 그 일로 수선을 피우지 말라.
   3. 그녀에게 실패를 선샤이닝하라고 요청하라.

성과를내지못한베팅을두고법석을떠는것은,앞으로 모험 따위는 생각도 하지 말라는 경고와 다를 바 없다.

넷플릭스에서는 실패한 모험을 숨기지 말고 백주에 다 드러내라고 말합니다. 이를 가리켜 ‘선샤이닝’이라고 하죠. 저는 리더 들이 자신의 실수를 낱낱이 고백하는 모습을 보아왔기 때문에 제 실패를 선샤이닝할 뿐 아니라, 요란한 플래시 세례도 사양하 지 않기로 마음먹 었어요.

한 사람이 실패 사례를 선샤이닝하면, 모두가 승자가 된다. 사람 들은 그 사람이 자기의 실수를 솔직하게 말하면서 그 행동에 책임 을 지는 모습을 보며 신뢰하게 되므로 그 사람 역시 승자가 된다. 그의 팀도 실패로 귀결된 프로젝트의 결과에서 분명 무언가를 배 웠을 테니 역시 승자가 된다. 무엇보다 실패한 베팅은 혁신적 성 공의 수레바퀴의 본래적 일부라는 사실을 모두가 똑똑히 볼 수 있 기 때문에 회사도 승자가 된다. 실패를 두려워해선 안 된다. 실패 를 적극적으로 포용해야 한다. 그리고 실수를 더 많이 선샤이닝하라!

큰 실수를 저질렀을 때는 본능적으로 발을 빼고 싶은 생각부터 든다. 넷플릭스에서는 권하지 않는 태도다. 실수를 저지르고도 무사하려면, 더욱더 햇볕으로 나아가야 한다. 사실대로 말하면 용서 받을 수 있다. 적어도 처음 몇 번은 말이다. 그러나 실수를 얼버무 리려 하거나 같은 실수를 반복한다면(실수를 인정하지 않으면 반복할 가능성이 커진다), 결과는 심각해진다.

® 6장요약 0 빠르고 혁신적인 회사에서, 중요하고 비용이 많이 드는 결정에 대한 소유권은 위계상 높은 사람이 아닌, 여러 직급의 모든 직원에게 분 산되어야 한다. 0 분산된 의사결정권이 효력을 발휘하려면, 직원들에게 넷플릭스의 원칙을 가르쳐야 한다. ‘상사의 비위를 맞추려 들지 말라.’ 0 새직원이들어오면베팅할수있는칩을몇개확보하라고말하라. 성공하는 베팅도 있고 실패하는 베팅도 있을 것이다. 한 직원의 성 과는 그가 베팅한 결과의 집합으로 평가될 것이다. 한 가지 사례의 결과가 아니라. 0 직원들이좋은베팅을할수있도록이의제기장려와아이디어공 유, 대대적인 테스트를 적극적으로 권하라. 0 베팅이 실패했을 때 공개적으로 선샤이닝하게 하라.

가족은 ,성과”와 관계없이 함께하는 집단이다

프로스포츠팀은 높은 인재 밀도의 좋은 비유다. 프로팀의 선수 들은 다음과 같기 때문이다.

• 뛰어난 기량이 요구된다. 그래서 매니저들은 필요한 때 모든 자리를 최고의 인재들로 채워야 한다. • 이기는 팀이 되도록 훈련받는다. 그래서 감독과 다른 선수들이 경기에 대해 지속적으로 솔직한 피드백을 주고받는다. • 열심히 하는것 만으로는 안된다. 그래서 제일 열심히 노력했는데 도결과가 시원치 않으면, 매니저는 최대한 예의를 갖춰 그동안 고마웠다는 말과 함께 그를 내보내고 다른 선수로 교체한다.

성과가 뛰어난 팀은 협업 능력과 서로에 대한 신뢰가 남다르다. 모든 구성원이 자신이 하는 일과 다른 사람과 함께하는 일에서 뛰 어난 기량을 발휘하기 때문이다. 기량이 뛰어난 사람으로 인정받 으려면 놀라운 실력만으로는 부족하다. 이기심을 자제하고 남을 먼저 생각할 줄 알아야 한다. 언제 공을 패스할지 알아야 하고, 동 료가 골을 넣을 수 있도록 결정적인 어시스트를 해야 하며, 팀이 이길 때만 내가 이긴다는 사실을 인정해야 한다. 그것이 바로 넷 플릭스에서 우리가 만들고자 하는 문화다.

우리는 가족이 아니라, 팀이다.

키퍼 테스트

팀원 중 한 사람이 내일 그만두겠다고 하면, 다시 한번 생각해 보라고 설득하겠는가, 아니면 속으로 다행이라 생각하며 사직서를 수리하겠는가? 후자라면 지금 당장 그에게 퇴직금을 주고 스타 플레이어를 찾아라. 어떻게 해서든지 지켜야 할 사람을 말이다.

넷플릭스는 모든 사람에게 키퍼 테스트를 적용하려고 한다. 우 리 자신도 예외는 아니다. 내가 맡은 일을 다른 사람이 하면 회사 가 더 잘될까? 이렇게 하는 이유는 누구를 내보낼 때 부끄럽지 않 기 위해서다.

넷플릭스는 직원들에게 업계 최고의 대우를 해주고, 모두 고액 연봉을 받는다. 그들은 우리 회사가 빠르게 변신해야 하고, 그런 점에서 우 리가 그들에게 남다른 성과를 기대한다는 점을 이해하고 있다. 그 래서 넷플릭스에서 일하기로 작정한 사람들은 모두 우리의 높은 인재 밀도를 유지하는 정책을 알고 선택했다. 우리는 우리의 전략 을 투명하게 운영하고 직원들은 그런 탁월한 수준의 동료들과 함 께 일하는 것을 즐거워하기 때문에, 그에 따른 약간의 직업적 위 험은 기꺼이 감수하는 편이다. 장기간 안정을 보장해 주는 직업을 선호하는 사람들은 넷플릭스에 들어올 생각을 하지 않는다. 그렇 다. 나는 우리의 방식이 윤리적으로 문제가 없다고 생각한다. 그리 고 또한 대부분의 직원도 그런 방식을 조 }한다.

누군가를 내보낼 때마다 우리는 여러 달 치의 월급, 그러 니까 적게는4개월 치부터 부사장의 경우9개월 치의 월급을지급 한다. 그래서 우리는 이렇게 말한다. 적당히 일해도 퇴직금은 후하다.

즉각적인 키퍼 테스트

“제가 일을 그만둔다고 한다면, 어떻게 해서든 저를 붙잡으실 건가요?”

상사에게 즉각적인 키퍼 테스트 질문을 했을 때 나올 수 있는 답변은 세 가지예요. 첫째, 상사가 무슨 수를 써서라도 당신을 놓치지 않겠다고 말하는 경우죠. 이런 답을 들으면 그동안 잠을 설치게 만들었던 두려움이 말끔히 사라질 것입니다. 둘째, 상사가 명확하게 답변하지는 않지만, 성과를 개선할 수 있도록 분명한 피드백을 주는 경우입니다. 이 역시 당신이 제 역할을 할 수 있도록 도와주는 말이니 나쁘지 않죠. 셋째, 상사가 당신을 지키기 위해 노력할 기색이 없어 보이는 경우입니다. 이때는 괜히 쓸데없는 질문을 한 셈일 수도 있습니 다. 그런 질문으로 인해 당신의 상사는 그동안 딱히 생각해 보 지 않았던 당신의 부정적인 측면을 진지하게 따져보게 될 테니 까요. 그러니 이런 질문을 하는 것 자체가 조금은 걱정되겠죠. 하지만 이 역시 좋은 일입니다. 이를 계기로 지금 하는 일이 당 신의 능력에 맞는지 확실히 따져볼 기회가 되기 때문이죠. 아무 것도 모르고 있다가 어느 날 아침, 느닷없이 회사를 그만두라는 통고를 받는 것보다는 낫지 않을까요?

Route53 은 도메인 등록 대행을 해주는 역할도 하는데

등록 대행에세 example.com 을 등록하고 싶다고 하면

대행이 등록소에 가서, IP 는 안 알려주고 등록함

그러면 등록소는 등록소서버에 example.com 이라는 도메인은 a.iana 라는 등록대행 서버에 있다 ~ 라고 저장해놓음

여기까지가 도메인 등록하는 간략한 과정.

이제 유저가 (클라이언트) 크롬 브라우저에 example.com 을 엔터 치면 어떻게 되는지 봅시다.

일단 유저 노트북에 와이파이를 연결하거나 랜선을 꽂는 순간 그 컴터만의 DNS 서버가 생기는데 (어떻게 생기는지는 모름, 생활코딩형이 그냥 마법이라고 그랬음)

example.com 적고 엔터치면 아주 빠른속도로 이 노트북의 DNS 서버가 루트네임서버한테 가서 "야, example.com ip 뭐임?" 루트네임서버: "음... 뒤에 .com 으로 끝나네, 그럼 a.gtld-servers.net 으로 가봐

이번엔 해당 등록소 서버에 가서 "야, example.com ip 뭐임?" 등록소서버: "엥 ip는 모르는데, example.com 은 a.iana-server.net 쪽에서 등록해달라고 했음"

이번엔 등록대행 서버에가서 "야, example.com ip 뭐임?" 등록대행서버: 93.184.216.34

그제야 우리의 부지런한 DNS server 는 client 에게 IP 넘버를 갖다주고, 클라이언트는 그 IP 로 접속할 수 있게 된다.

Route53의 두가지 역할

• 등록대행
• 네임서버를 임대해주는 역할

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

AWS console 들어가서

Route53 들어가서

일단 도메인 등록한다. 돈도 내야하고 도메인을 구입하는 것

Route53 으로 도메인을 사면 네임서버까지 자동으로 세팅을 해준다.

Hosted zones 에 들어가면 도메인이 있을거고 클릭하면

NS = Name Server

객체 리터럴 방식으로 생성한 객체의 경우 메서드 내부에서 메서드 자신이 속한 객체를 가리키는 식별자를 재귀적으로 참조할 수 있다. getDiameter 메서드 내에서 메서드 자신이 속한 객체를 가리키는 식별자 circle을 참조하고 있다. 이 참조 표현식이 평가되는 시점은 getDiameter 메서드가 호출되어 함수 몸체가 실행되는 시점이다.

따라서 메서드 내부의 this는 프로퍼티로 메서드를 가리키고 있는 객체와는 관계가 없고 메서드를 호출한 객체에 바인딩된다.

• 프로토타입 메서드 내부에서 사용된 this도 일반 메서드와 마찬가지로 해당 메서드를 호출한 객체에 바인딩된다.

원시값과 래퍼 객체

문자열이나 숫자, 불리언 등의 원시값이 있는데도 문자열,숫자, 불리언 객체를 생성하는 String, Number, Boolean 등의 표준 빌트인 생성자 함수가 존재하는 이유은 뭘까? 원시값을 마치 객체처럼 마침표 표기법으로 접근하면 자스 엔진이 일시적으로 원시값을 연관된 객체로 변환해주기 때문

즉, 원시값을 객체처럼 사용하면 자스 엔진은 암묵적으로 연관된 객체를 생성하여 생성된 객체로 프로퍼티에 접근하거나 메서드를 호출하고 다시 원시값으로 되돌린다.

이처럼 문자열, 숫자, 불리언 값에 대해 객체처럼 접근하면 생성되는 임시 객체를 래퍼 객체 wrapper object라고 한다. 이 때 문자열 래퍼 객체인 String 생성자 함수의 인스턴스는 String.prototype의 메서드를 상속받아 사용할수 있다. 그 후 래퍼 객체의 처리가 종료되면 래퍼 객체의 [[StringData]] 내부 슬롯에 할당된 원시값으로 원래의 상태, 즉 식별자가 원시값을 갖도록 되돌리고 래퍼 객체는 가비지 컬렉션의 대상이 된다.

프로토타입 객체란 객체지향 프로그래밍의 근간을 이루는 객체간 상속을 구현하기 위해 사용.

프로토타입은 어떤 객체의 상위(부모) 객체의 역할을 하는 객체로서 다른 객체에 공유 프로퍼티(메서드 포함)를 제공

프로토타입을 상속받은 하위(자식) 객체는 상위 객체의 프로퍼티를 자신의 프로퍼티처럼 자유롭게 사용할 수 있다.

모든 객체는 [[Prototype]] 이라는 내부 슬롯을 가지며, 여기에 저장되는 프로토타입은 객체 생성 방식에 의해 결정된다. 즉 객체가 생성 될 때 객체 생성 방식에 따라 프로토타입이 결정되고 [[Prototype]]에 저장된다.

모든 객체는 하나의 프로토타입을 갖는다. 그리고 모든 프로토타입은 생성자 함수와 연결되어 있다.

프로토타입은 자신의 Constructor 프로퍼티를 통해 생성자 함수에 접근할 수 있고, 생성자 함수는 자신의 prototype 프로퍼티를 통해 프로토타입에 접근할 수 있다.

proto 접근자 프로퍼티

모든 객체는 proto 접근자 프로퍼티를 통해 자신의 프로토타입, 즉 [[prototype]] 내부 슬롯에 간접적으로 접근할 수 있다. 예제)

• 프로토타입과 생성자 함수는 언제나 쌍으로 존재한다. (페어)
• 프로토타입은 생성자 함수가 생성되는 시점에 더불어 생성된다.

프로토타입 체인

자바스크립트는 객체의 프로퍼티(메서드 포함) 에 접근하려고 할 때 해당 객체에 접근하려는 프로퍼티가 없다면 [[Prototype]] 내부 슬롯의 참조를 따라 자신의 부모 역할을 하는 프로토타입의 프로퍼티를 순차적으로 검색한다. 이를 프로토타입 체인이라고 한다. 프로토타입 체인은 자스가 객체지향 프로그래밍의 상속을 구현하는 메커니즘이다.

오버라이딩과 프로터티 섀도잉

Instanceof 연산자

이것은 프로토타입의 constructor 프로퍼티가 가리키는 생성자 함수를 찾는 것이 아니라 생성자 함수의 prototype에 바인딩된 객체가 프로토타입 체인 상에 존재하는지 확인한다.

직접 상속

Object.create

이 메서드는 명시적으로 프로토타입을 지정하여 새로운 객체를 생성한다.

정적 프로퍼티/메서드

정적 static 프로퍼티/메서드는 생성자 함수로 인스턴스를 생성하지 않아도 참조/호출할 수 있는 프로퍼티/메서드를 말한다.

Person 생성자 함수는 객체이므로 자신의 프로퍼티/메서드를 소유할 수 있다. Person 생성자 함수 객체가 소유한 프로퍼티/메서드를 정적 프로퍼티/메서드라고 한다. 정적 프로퍼티/메서드는 생성자 함수가 생성한 인스턴스로 참조/호출할 수 없다.

생성자 함수가 생성한 인스턴스는 자신의 프로토타입 체인에 속한 객체의 프로퍼티/메서드에 접글할 수 있다. 하지만 정적 프로퍼티 /메서드는 인스턴스의 프로토타입 체인에 속한 객체의 프로퍼티/메서드가 아니므로 인스턴스로 접근할 수 없다.

1.1.1 경량코어

최소한의 기능세트를 가지고 코어의 바깥부분에 유저랜드 혹은 유저스페이스라 불리는 사용자 전용 모듈 생태계를 두는 것 (userland & userspace)

1.1.2 경량 모듈

• 노드js는 프로그램 코드를 구성하는 기본적인 수단으로서 모듈 개념을 사용한다.
• 이건 애플리케이션과 재사용 가능한 라이브러리를 만들기 위한 구성요소다.
• Unix 철학에 근거,

  작은 것이 아름답다. 각 프로그램은 한 가지 역할만 잘 하도록 만들어라

노드는 npm, yarn) 패키지 관리자의 도움을 받아 각 패키지가 자신이 필요로 하는 버전의 종속성 패키지들을 갖도록 함으로써 종속성 지옥에서 벗어나게 해준다.

작은 모듈은 재사용성이라는 장점 외에도 다음의 장점이 있다.

• 이해하기 쉽고 사용하기 쉽다.
• 테스트 및 유지보수가 쉽다.
• 사이즈가 작아 브라우저에서 사용하기에 완벽하다. 이것은 완전 다른 수준에 적용된 Don't Repeat Yourself (DRY)

1.1.3 작은 외부 인터페이스

노드js 에서 모듈을 정의하는 가장 일반적인 패턴은 명백한 단일 진입점을 제공하기 위해서 단 하나의 함수나 클래스를 노출 시키는 것

1.1.4 간결함과 실용주의

Keep it Simple, Stupid ~ (KISS) 원칙

단순함이야말로 궁극의 정교함이다 - 레오나르도 다빈치

리차드 가브리엘 - 디자인은 구현과 인터페이스 모두에서 단순해야 한다. 구현이 인터페이스보다 더 단순해야한다는 것은 더욱 중요하다. 단순함이 디자인에서 가장 중요한 고려 사항이다.

1.2 Node.js 는 어떻게 작동하는가

1.2.1 I/O 는 느리다

느려! 느리다구 ! !

1.2.2 블로킹 I/O

전통적인 블로킹 I/O 프로그래밍에서는 I/O를 요청하는 함수의 호출은 작업이 완료될 때까지 스레드의 실행을 차단한다.

1.2.3 논 블로킹 I/O

이 운영모드에서 시스템 호출은 데이터가 읽혀지거나 쓰여지기를 기다리지 않고 항상즉시 반환됩니다.

1.2.4 이벤트 디멀티플렉싱

바쁜 대기（Busy-waiting）는 논 블로킹 리소스 처리를 위한 이상적인 기법이 아닙니다 . 다행 히도 , 대부분의 운영쳬제는 논블로킹 리소스를 효율적인 방법으로 처리하기 위한 기본적인 메 커니즘을 제공합니다. 이 메커니즘을 동기 이벤트 디멀티플렉서 또는 이벤트 통지 인터페이스라고합니다． 멀티플렉싱은 전기통신 용어로서 여러 신호들을 하나로 합성하여 제한된 수용범위 내에서 매개쳬를 통하여 쉽게 전달하는 방법을 나타냅니다． 반대로 디멀티플렉상은 신호가 원래의 구성요소로 다시 분할되는 작업입니다 . 두 용어는 비디오 처리를 포함한 여러 분야에서 서로 다른 것들을 합성과분할하는 일반적인 작업을 설명하기 위해서 사용됩니다．

1.2.5 리액터 패턴

1.2.7 Node.js 를 위한 구성

내가 알아야하는거는

html 코딩하고, FTP 를 통해 웹서버에 콘텐츠를 올렸다는데..

요즘은 여러 개발자가 동시에 작업하고 배포하니까.. 일단 마이크로갓프트에서 대표 웹 배포 도구인 FP, FPSE 를 만들었다.

FP, FPSE

• 가장 대표적인 마이크로소프트의 웹 개발 및 배포 도구인 FrontPage(FP)는 "어디서든 배포한다"라는 전략

• FPSE(FrontPage Server Extentions)라는 서버측 소프트웨어와 함께 사용된다.

• FP클라이언트와 FPSE 사이에서 배포 프로토콜이 사용된다.

• FP 배포 프로토콜은 POST request 위에 RPC계층을 추가하였는데, 이 프로토콜 구현을 통해 FP 클라이언트가 서버로 명령을 내려 웹개발자들이 문서를 갱신하거나, 검색하거나 혹은 공동 작업을 가능하게 해주었다.

• 우선 통신을 시작하기에 앞서 클라이언트는 서버에 있는 FPSE 패키지 일부의 위치와 이름을 알아내야한다.

• 클라이언트는 GET요청을 보내 이 정보를 서버로부터 얻는다. (FPShtmlScriptUrl, FPAuthorScriptUrl 등과 관련된 값을 저장)

이 정보를 바탕으로 클라이언트는 Request 메시지를 작성할 수 있게 되었다. 아래는 예시 요청문이다.

이걸봐야해 이걸봐야해22

WebDAV - 공동 작업

WebDAV = Web Distributed Authoring and Versioning = 공동 작업과 버저닝 관리에 대한 협업 관리 기술이다.

마찬가지로 HTTP를 확장하는 방식으로 구현되었는데, HTTP에 추가하는 메서드들을 살펴보면 아래와 같다.

• PROPFIND : 리소스의 속성을 읽음

• PROPPATCH : 하나 이상의 리소스에 대해 하나 이상의 속성 설정

• LOCK : 하나 이상의 리소스를 잠금

• UNLOCK : 하나 이상의 리소스를 잠금 해제

HTTP는 요청과 응답 정보를 헤더에 담아 보내게 되는데, 이는 요청 하나에 여러 개의 리소스가 존재할 때 사용하는 데에 있어 한계가 있다.

따라서 구조화(structured)된 데이터를 담을 때 사용하는 XML을 지원하는데, 주로 아래와 같은 용도로 사용된다.

• 데이터 처리 설명 포맷, 서버의 복잡한 응답을 다시 표현하는데 사용 등

WebDav와 XML

WebDAV는 HTTP/1.1 프로토콜의 확장으로서 HTTP 및 XML 뿐만 아니라 텍스트, 그래픽, 스프레드시트 및 모든 기타 형식을 포함하는 모든 유형의 웹 리소스에 대해 저작 지원을 제공하는 새로운 HTML 메소드 및 헤더를 추가합니다.

WebDAV로 실행할 수 있는 작업에는 다음과 같은 것들이 있습니다.

등록정보(메타 데이터) 조작. WebDAV 메소드 PROPFIND 및 PROPPATCH를 사용하여 저작자 및 작성 날짜와 같은 웹 페이지에 대한 정보를 만들고 제거, 쿼리할 수 있습니다. 컬렉션 및 리소스 관리. WebDAV 메소드 GET, PUT, DELETE 및 MKCOL을 사용하여 문서 세트를 만들고 계층적 구성원 목록(파일 시스템의 디렉토리 목록과 유사)을 검색 잠금. WebDAV를 사용하여 한 사람 이상이 동시에 한 문서에서 작업하지 못하도록 할 수 있습니다. WebDAV 메소드 LOCK 및 UNLOCK을 사용하여 exclusive 또는 shared 잠금을 사용함으로써 "업데이트 유실"(변경 사항 겹쳐쓰기) 문제를 방지할 수 있습니다. 이름 공간 작업. WebDAV를 통해 WebDAV 메소드 COPY 및 MOVE를 사용하여 웹 리소스를 복사 및 이동하도록 서버에게 지시할 수 있습니다

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

WebDAV의 메서드는 요청과 응답 관련 정보를 모두 잘 다루어야 한다. 하지만 헤더에만 정보를 담아 전송하는 것은 하나의 요청에 있는 여러 개의 리소스나 계층 관계에 있는 리소스들에 대한 정보를 헤더에 선택적으로 기술하기 어려운 점 등 한계가 있다.

WebDAV는 이 문제를 해결하려고 XML(Extensible Markup Language)을 지원한다. WebDAV는 XML을 다음과 같은 용도로 사용한다.

데이터를 어떻게 처리할 것인지 설명하는 명령 포맷 서버의 복잡한 응답을 표현하는 데 사용하는 포맷 콜렉션과 리소스를 처리하는 데 사용하는 커스텀 정보 포맷 데이터 자체를 표현할 수 있는 유연한 포맷

WebDAV는 현재 많은 브라우저에서 지원되고 있다고 한다.

• 모듈과 함수는 소프트웨어를 구성하는 빌딩 블록이며, API는 이 블록들을 끼워 맞추는 연결부다.

함수 매개변수화 하기

두 함수의 로직이 아주 비슷하고 단지 리터럴 값만 다르다면

플래그 인수 제거하기

플래그 인수란: 호출되는 함수가 실행할 로직을 호출하는 쪽에서 선택하기 위해 전달하는 인수

호출하는 쪽에서 boolean 값으로 리터럴 값을 건네야 한다.(불리언 아니여도댐) 호출되는 함수는 그 인수를 제어 흐름을 결정하는데 사용해야 한다.

함수 매개변수화 하기 기법

• 리터럴: 계산 과정에 필요한 상수

플래그 인수 제거하기

• 플래그 인수: (함수 안에서) 로직 선택에 사용

왜 하는가

"호출할 수 있는 함수들이 무엇이고 어떻게 호출해야 하는지를 이해하기 어려워지기 때문" 호출자가 간단하길 바라는 저자의 성향 반영

명확한 이름을 가진 함수명으로 호출하는것이 boolean 값을 넘겨주는 것보다 명확

없애지 말아야 할 때?

함수 하나에서 플래그 인수를 두개 이상 사용한다면... (M x N 경우의 수의 함수) 단, 함수 하나가 너무 많은 일을 하고 있다는 의미일수도

객체 통째로 넘기기

오 이거 좋지.. 책임 떠넘기기 기법 레코드를 통째로 넘기면 변화에 대응하기 쉽다. 변수 추상화의 이점과 유사!

책임 떠넘기기 기법 2번째

예시 이상해,,, 이미 anEmployee 객체를 파라미터로 넘겼는데 굳이..? 좀 억까인데

매개변수를 질의함수로 바꾸기

왜? 중복 피하기

• 피호출 함수가 스스로 쉽게 결정할 수 있는 값을 매개변수로 보내는 것도 일종의 중복이다

다시말해 -> 그 값을 결정하는 책임을 피호출 함수에게 넘기겠다는 것

그럼 언제 하지 말아야 하는가?

• 결과로 (피호출 함수에) 원치 않는 의존성이 생길 떄

세터 제거하기

생성자를 팩터리 함수로 바꾸기

생성자 constructor 의 제약

서브클래스를 리턴할 수 없다 생성자 이름 고정 일반 함수가 기대되는 곳에 사용할 수 없다.

함수를 명령으로 바꾸기

명령?

함수를 그 함수만을 위한 객체 안으로 캡슐화하면 더 유용해지는 상황이 있다. 이런 객체를 가리켜 '명령 객체' 혹은 단순히 '명령'이라 한다.

왜 명령 객체인가

• 함수 메커니즘보다 유연하게 함수 제어하고 표현
• 되돌리기 같은 보조 연산 제공
• 수명주기 정밀 제어하는데 필요한 매개변수 생성 메서드 제공
• 상속과 훅을 이용하여 맞춤형
• 일급함수를 지우너하지않은 프로그래밍 언어를 사용할 때 일급함수의 기능 대부분을 흉내낼 수 있따.

(Java는 일급함수 지원 노노)

지난 강의에 있는 요거.... charge 를 두번 썼는데,, 쪼갤 수 있지

필드 이름 바꾸기

파생변수를 질의함수로 바꾸기

파생변수를 질의함수로 바꾸기 vs 임시변수를 질의 함수로 바꾸기

• 공통점: 다른 변수로부터 유도된 변수를 메소드로 추출해낸다는 공통점
• 차이점:

참조를 값으로 바꾸기 / 값을 참조로 바꾸기

call by reference vs Call by value

참조: 내부 객체는 그대로 둔 채 그 객체의 속성만 갱신

값: 새로운 속성을 담은 객체로 기존 내부 객체를 통째로 대체한다.

매직 리터럴 바꾸기

숫자를 상수로 바꾸기..

10장 조건부 로직 간소화

조건식 조건절 각가 함수로 추출하기

1. 여러 조건식을 하나로 통합
2. 해당 조건식을 함수로 추출

조건식 통합하기

1. 부수 효과가 없는지 확인한다.
2. 조건문 두 개를 선택하여 결합한다.
3. 테스트한다, 이 단계에서 '겉보기 동작'이 유지되어야 한다.
4. 조건이 하나만 남을 때 까지 2~3 과정을 반복한다
5. 함수로 추출할지 고려해 본다.

1. 부수 효과가 없는지 확인한다. 만일 있다면 질의 함수와 변경함수 분리하기 먼저 적용 (아마도) 모두 질의함수이므로 부수효과 없음

2. 조건문 두개를 선택하여 결합한다.

3. 테스트하고,,
4. 2번 3번 반복

5. 추출할지 고려해본다: 고고

중첩 조건문을 보호 구문으로 바꾸기

보호 구문

• 두 경로 모두 정상 동작이라면 if-else문을 사용한다 한쪽만 정상이라면 비정상 조건을 if 에서 검사한 후 함수에서 빠져나온다.

절차

1. 교체해야 할 조건중 가장 바깥 것을 보호구문으로 바꾼다
2. 테스트한다
3. 1~2번 반복
4. 모든 보호 구문이 같은 결과를 반환한다면 보호 구문들의 조건식을 통합한다.

예시 1번

4번

응용+ 변수 인라인 하기

복잡한 예시 + 테스트의 중요성

이걸 이렇게 바꿀수 있다.

먼저 의료진인지 파악하고, whenIsNotHealthWorker 함수를 넣는데 , 먼저 증상이 크리티컬하며 적정나이인지, 그리고 30상 아래랑 여자인지 그다음에 시간

특이 케이스 추가하기

모든 기법중에 가장 독특한 기법

목적: 예외적인 단 하나의 그러나 자주 쓰이는 케이스를 클래스의 한 형태로 만들어 버려서 유저 시나리오를 일원화 하기

일단 예시 결론부터 하자면

출처: 리팩토링 2판 제로베이스 유료강의 해설

코드가 사용되지 않게 됐다면 지워야 한다

혹시 다시 필요해질까.. 노 걱정, 우리에겐 버전 관리 시스템이!!!!!!!

예시

리팩터링 후

코드 바꾸다가 깨졌어!

무슨 의미일까?

더 나은 표현

• 부수효과 (side effect) 코드 사이에 인과관계가 존재하여 코드라인의 이동이 "깨짐"을 초래하는 경우

  Before

  

왜 갑자기 let 으로 선언하고, const 줄들이랑 섞여서 보기 힘들다.

After

파이프라인

반복문 파이프라인으로 바꾸기

JS: Pipe

반복문 그 자체로 악취가 되었다.

아마도 리팩터링 2판에서 가장 크게 변한 것 1판이 출판된 1999년에는 반복문을 악취라고 부를 수 없었을 것

더 가독성이 좋은가?

가독성은 익숙함의 문제

• 그러나 코드가 '방법'보다는 '의도'에 따라 정리 된다는 점에서 코드 추출하기와 유사한 변화

반복물은 사용해야 할 때

1. 반복문의 사용이 Collection의 가공을 의도하지 않았을 떄
2. 내부 로직의 우선순위가 명확하게 지켜져야 할 때

출처: 제로베이스 유료 강의 - 리팩터링2판 책 해설

여러 함수를 변환 함수로 묶기

악취

가변 데이터

• 기법 적용의 결과로 데이터는 캡슐화 됨

산탄총 수술

• 여러 곳에 흩뿌려진 코드들을 모으는 리팩터링

단계 쪼개기

함수를 계속 쪼개는거지...

어렵...

캡슐화

OOP... 은닉화..

그러나 모든 캡슐화가 OOP는 아니다! 예) 변수 캡슐화하기에는 클래스가 없다.

캡슐화란? 데이터에 대한 접근을 함수로만 한정하는 것

레코드 캡슐화

레코드 = 구조체 JS 는 모든 object는 그자체로 레코드로 사용 가능 HashMap 등으로도 레코드 사용 가능

컬렉션 캡슐화

둘의 차이점

출처: 제로베이스 유료강의 리팩터링 2판 해설

할당연산자 숫자 사칙연산은 적용해본 적도 있고 알고 있었지만 문자열 연결 연산자는 처음본다

비교연산자

삼항 조건 연산자 자스의 유일한 삼항 연산자이며, 부수 효과는 없다. 하지만 삼항 조건 연산자 표현식은 if else 문과 중요한 차이가 있다. 삼조연표는 값처럼 사용할 수 있디만 if else문은 표현식이 아니라 문이라서 값처럼 사용할 수 없다

typeof 연산자 null 은 Object 다.. 기억하자... 자스의 첫 번째 버그인데 기존 코드에 영향을 줄 수 있기 때문에 아직까지 수정이 안되고 있다고 한다.

지수 연산자 ES7 에서 도입되었다.

• 지수 연산자는 이항 연산자 중에서 우선순위가 가장 높다.

연산자 우선순위 연산자 우선순위랑 여러개의 연산자로 이뤄진 문이 실행될 때 연산자가 실행되는 순서

• 연산자는 종류가 많아서 연산자 우선순위를 모두 기억하기 어렵다.
• 기억에 의존하지 말고 그냥 우선순위가 가장 높은 그룹 연산자를 사용하여 우선순위를 명시적으로 조절하는 것을 권장

블록문에는 세미콜론(;)을 안붙힌다 (eslint)가 다 잡아주긴 해도 알고는 있어야지

조건문 만약 코드 블록 내의 문이 하나뿐이라면 중괄호를 생략할 수 있다??

조건문에서 if else 문의 조건식은 불리언 값으로 평가되어야 하지만 switch 문의 표현식은 불리언 값보다는 문자열이나 숫자 값인 경우가 많다. 다시 말해, if else 문은 논리적 참, 거짓으로 실행할 코드 블록을 결정한다. switch 문은 true/false 로직보다 다양한 case에 따라 실행할 코드 블록 결정할 때 사용한다. 이렇게 하면 터진다. 핸들이 고장난 8톤 트럭 마냥 break 없이 default 까지 달려갔기 때문이다. case 사이사이에 break 를 걸어야 11월에서 빠져 나오지... default 문에서는 break 를 생략해라.

레이블 문이라고 있는데 중첩된 for 문 외부로 탈출할 때 유용하지만 그 밖의 경우에는 일반적으로 권장하지 않음

자스에서는 사용할 수 있는 모든 값은 프로퍼티 값이 될 수 있다. 자스의 함수는 일급 객체이므로 값으로 취급할 수 있다. 따라서 함수도 프로퍼티 값으로 사용 가능. 프로퍼티 값이 함수일 경우, 일반 함수와 구분하기 위해 "메서드"라고 부른다.

• 인스턴스

출처: 모던 자바스크립트 Deep Dive 책

가장 기본적이고 많이 사용해서 제일 먼저 배워야 하는 리팩터링 즉, 다른 리팩터링 절차에서 자주 참조할 기법들

리팩터링을 체계화 하려는 저자의 의도 이에 따라 복잡한 리팩터링을 여러 작은 리팩터링으로 나눌 수 있어야

함수 vs 변수

데이터(변수)는 함수보다 다루기 까다롭다.

참조하는 모든 부분을 한 번에 바꿔야 코드가 제대로 작동한다. 함수는 일부분 변경이 가능하지만 변수는 일부분 변경이 불가

캡슐화 - 전역변수 및 가변데이터의 문제

캡슐화는 데이터 입출력의 통로를 제한함 데이터 입/출력시 추가로직을 쉽게 추가 가능함 (copy on write 등)

출처: 제로베이스 구매한 강의 중 개인 공부

악취 = 리팩터링이 필요한 코드

그럼 냄새를 어디까지 빼야하나 => 숙련된 개발자의 직관...

악취의 종류들

• 기이한 이름 만약에 이 함수의 이름이 바로 떠오르지 않는다면 설계에 문제가 있을 가능성

• 중복코드

• 긴 함수 이름에 의도를 담은 여러 함수들로 쪼개기

• 긴 매개변수 목록

• 전역 데이터

• 가변 데이터

• 기능 편애 나보다 다른 모듈과의 상호작용이 더 많을 때

• 데이터 뭉치 언제? 값 하나를 삭제 해봤을 때 의미가 없어지면

• 기본형 집착 오브젝트화 하면 좋을 것을 굳이 기본형으로 쓰지말라

• 반복되는 switch 문 옛날엔 선호되었지만, 그후에는 또 꺼려졌고, 근데 지금 많이 진화되기도 했지만 그래도 적당히 쓰자

• 반복문

• 파이프라인으로 수정: 우리가 2판을 읽어야 하는 이유*

• 성의 없는 요소 코드 한두줄과 다를 바 없는 함수, 메서드가 하나뿐인 클래스

• 추측성 일반화 (YAGNI)

• 임시 필드 특정 상황에만 값이 설정되는 필드 (예: 특이 케이스 추가)

• 메세지 체인 꼬리에 꼬리를 무는 게터

• 중개자

• 아래가 문제일 때*: 클래스가 중개자로 전락한다면 다시말해 getManagerXX() 가 Employee 구현의 대다수를 차지한다면

• 내부자 거래

• 위에가 문제일때*: (예: 클래스가 위임과 결합도가 너무 높다면

• 왜 문제일까?* Manager의 구조가 바뀌다면

• 거대한 클래스

• 서로 다른 인터페이스의 대안 클래스들 두 비슷한 클래스, 그러나 다른 인터페이스를 구현

• 데이터 클래스 게터와 세터만 존재하는 클래스 문제: 다른 클래스가 너무 깊이까지 함부로 다룰 때가 많다. 필요한 동작이 엉뚱한 데 정의돼 있다는 신호일 수 있음

• 상속 포기 부모의 public 요소를 사용할 게 아니라면 상속하지 않는 게 낫다. e.g Java의 Stack

• 주석 주석은 향기를 뿜는다. 그러나 향수를 탈취제로 쓰면 안 되는 것.

• 리팩토링의 핵심은 겉보기 동작의 유지 "코드가 깨졌다면 그것은 리팩터링이 아니라 어설픈 Restructuring" 그것을 보장해 주는 것이 테스트

SRP: Single Responsibility Principle 단일 책임 원칙

출처 - 제로베이스 강의베이스로 공부함

리팩터링: 소프트웨어의 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법

WHY - 이해하고 수정하기 쉬운코드 WHAT - 내부 구조를 변경 HOW - 겉보기 동작은 그대로 유지한 채

• "리팩처링하다 코드가 깨졌다"고 하면 그것은 리팩터링이 아니다.

• 리팩터링은 그 과정에서릐 겉보기 동작 유지가 중요한 것

• 리팩터링의 특징은 무엇을 하느냐가 아니라 어떻게 하느냐

두개의 모자

• 기능 추가와 리팩터링을 명확하게 구분하라

근데.. 리팩터링은 기능 추가와 밀접하게 엮인 경우가 너무 많기 때문에 굳이 나누는 것은 시간 낭비일수 있다.

대안책

• 최종 commit 은 하나로 묶되, cr(코드리뷰) 은 여러 revision으로 나누어 검토

git의 stash/commit/rebase 등의 기능을 잘 활용하면 예술적으로 적용할 수 있다.

리팩터링

왜 하는가?

설계 지구력 가설

내부 설계에 심혈을 기울이면 소프트웨어의 지구력이 높아져서 빠르게 개발할 수 있는 상태를 더 오래 지속할 수 있다.

언제 하는가?

3의 법칙, 3진아웃 리팩터링

1. 일단 개발한다.
2. 같은 일을 두번 하게 되면 ... 일단 한다.
3. 또 같은 일을 하게 되면, 이제야 말로 리팩터링 할 때다.

준비를 위한 리팩터링 - 기능을 쉽게 추가하게 만들기

• 기능을 추가하기 직전에, '리팩터링을 하면 더 쉽게 추가할 수 있지 않을까' 고민

이해를 위한 리팩토링 - 코드를 이해하기 쉽게 만들기

• 코드를 파악해야 할 일이 있을 때, 이해한 내용을 더 잘 반영할 수 있도록 리팩터링

쓰레기 줍기 리팩터링

• 코드를 파악하다가 '비효율적으로 처리하는 모습을 발견'하면 리팩터링

수시로 하는 리팩터링

• 따로 하지 않고 일반 개발 과정에서

코드 리뷰에 리팩터링 활용하기

• 코드리뷰를 할 때, 실제로 리팩터링을 해보기

리팩터링 하지 말아야 할 때

• 지저분해도 굳이 수정 할 필요가 없다면 차라리 새로 작성하는게 쉬울 때

근데 진짜 팀by팀 이라...

자신의 업무 체계에 따른 리팩터링 활용 방안을 고심해봐야 함

YAGNI (You Aren't Going to Need It)

1. 추측하지 말고 현재 요구사항만 충족해라
2. 대신 그것을 최대한 멋지게 해결하도록 설계 해라
3. 나중에 더 잘 이해하게 되면 리팩터링으로 바꾼다.

선제적 아키텍쳐에 소홀하라는 뜻이 아니다. 이미 알고있는 부분은 최대한 미리 준비하는게 좋지만 모르는걸 미리 대비하지 마라..

리팩터링과 성능

직관적 설계 vs 성능

리팩터링은 이해하기 쉬운 코드를 위해 '속도가 느려지는' 방향인 경우가 많다.

리팩터링이 잘 된 코드는 성능 분석에 유리하다.

출처 - 제로베이스 강의베이스로 공부함

예를 들어 우리 사이트의 주 고객이 영어 사용자와 프랑스어 사용자 양측이 존재한다면, 우리는 사용자에 맞게 콘텐츠를 제공해줘야 한다.

HTTP는 이런 판단이 가능하게 내용협상이란 방법을 제공한다.

이 방법은 하나의 URL이 여러 가지 리소스 중 적합한 것을 제공하도록 할 수 있다. 여기서는 서로 다른 버전을 배리언트( Variant ) 라고 부른다

요약 테이블

클라이언트 주도 협상

서버가 클라이언트의 요청을 받았을 때 가능한 페이지의 목록을 응답으로 돌려주어

클라이언트가 보고 싶은 것을 선택하게 하는 방법입니다.

장점: 서버 입장에서 구현하기 가장 쉬운 방법으로, 최선의 사본이 선택됩니다.

단점: 각 페이지에 두 번의 요청(목록 요청, 선택한 사본 요청)이 필요해 시간이 오래 걸립니다.

→ 클라이언트의 입장에서 화를 유발할 수 있습니다.

서버 주도 협상

클라이언트 주도 협상에는 위와 같이 커뮤니케이션 관련 단점이 존재했습니다.

서버 주도 협상은 서버가 어떤 페이지를 돌려줄 것인지 결정해서 이러한 단점을 보완하고자 했습니다. 대신, 서버가 선택할 수 있게끔 클라이언트는 무엇을 선호하는지에 대한 정보를 서버에게 제공하는데, 아래의 두 가지 메커니즘을 사용합니다.

내용 협상 헤더: 내용 협상 헤더들을 살펴보고, 서버는 클라이언트의 Accept 관련 헤더들을 확인 후 알맞은 응답 헤더를 준비 내용 협상 헤더 외의 다른 헤더를 살펴보고, (예- User-Agent 헤더 기반) 응답을 준비

투명 협상

투명 협상은 중간에 프락시를 두면서 클라이언트와의 메시지 교환을 최소화하는 동시에 서버 주도 협상으로 인한 부하를 서버에서 제거한다.

프락시는 클라이언트의 기대를 파악하고, 클라이언트와 협상할 수 있는 능력이 있다고 간주되는데, 서버는 프락시에게 Vary 헤더를 통해 어떤 조건을 확인해야 하는지를 알려줄 수 있다.

캐시 프락시가 만일 서버의 의사결정 프로세스를 알게 된다면, 캐시는 서버의 입장에서 협상을 진행할 수도 있다.

캐시와 얼터네이트 ( alternate )

캐시는 클라이언트에게 올바른 응답을 주기 위해 서버가 응답을 돌려줄 때 사용했던 의사결정 로직의 상당부분을 그대로 사용해야 한다.

캐시는 똑같은 리소스에 대하여 다른 버전을 동시에 가질 수 있도록, 이번의 응답과 저번의 응답을 모두 저장한다.

Vary 헤더

제공된 문서가 의존하고 있는 헤더를 포함하여 돌려준다.

캐시는 각 배리언트마다 알맞은 문서 버전을 저장해야 한다. 캐시가 검색을 할 때 먼저 내용 협상 헤더로 적합한 콘텐츠를 맞춰보고, 요청의 배리언트를 캐시된 배리언트와 맞춰본다.

맞는 것이 없다면 서버에서 가져온다.

• http Vary 응답 헤더는 서버가 문서를 선택하거나, 커스텀 콘텐츠를 생성할 때 고려한 클라 요청 헤더 모두를 나열한다.

• 새 요청이 도착했을 때, 캐시는 내용 협상 헤더들을 이용해 가장 잘 맞는 것을 찾는다.

• 캐시는 반드시 캐시된 응답 안에 서버가 보낸 Vary 헤더가 들어있는지 확인하고, Vary 헤더가 명시하고 있는 헤더들은 새 요청과 오래된 캐시된 요청에서 그 값이 서로 맞아야만 한다.

• 서버는 클라의 요청 헤더에 따라 그들의 응답이 달라질 수 있기 때문에 투명 협상을 구현하기 위해 캐시는 반드시 캐시된 variant와 함께 클라 요청 헤더와 그에 알맞은 서버 응답헤더 양쪽 모두를 저장해야한다.

• 서버의 Vary 헤더가 이렇다면, 거대한 수의 다른 User-Agent와 Cookie이 많은 배리언트 variant를 만들어낼 것이다.
• 캐시는 각 배리언트마다 알맞은 문서 버전을 저장해야 한다.
• 캐시가 검색을 할 때,

1. 먼저 내용 협상 헤더로 적합한 콘텐츠를 맞춰보고
2. 다음에 요청의 배리언트를 캐시된 배리언트와 맞춰본다.
3. 만약 맞는 것이 없으면, 캐시는 문서를 서버에서 가져온다. 맞는 것이 있다면, 해당 콘텐츠를 보내준다.

트랜스 코딩

무엇?

• 서버가 클라이언트의 요구에 맞는 문서를 하나도 갖고 있지 않다면, 기존의 문서를 클라이언트가 사용할 수 있는 무언가로 변환하는 옵션

• 포맷 변환

• 정보 합성

• 내용 주입

포맷 변환

• 데이터를 클라이언트가 다른 환경에서도 볼수 있도록 포맷 변환 시켜주는 것
• 내용 협상 헤더에 의해 주도된다ㅣ. (user-agent header에 의해서 주도될 수도 있다)
• 내용 변환 & 트랜스 코딩 = 콘텐츠를 특정 접근 장치에서 볼 수 있도록 하기 위한
• 콘텐츠 인코딩 & 전송 인코딩 = 콘텐츠를 더 효율적이거나 안전한 전송을 위한

정보 합성

• 보통 포털 사이트의 웹페이지 디렉터리와 같은 자동화된 웹페이지 분류 시스템에 의해 종종 사용된다.

내용 주입

이제까지는 다 뭔가 줄이는 거였는데 이거는 오히려 양을 늘리는 편

지나가는 HTML 페이지에 자동으로 광고 삽입이나 특정 사용자를 대상으로 하는 광고를 그때 그때 효과적으로 삽입하기 위해 동적으로 이루어 진다. (광고 알고리즘...?)

트랜스코딩 vs 정적으로 미리 생성해 놓기

• 트랜스코딩의 대안은 웹서버에 여러가지 사본을 만드는 것 근데 이 방식은 페이지에 대한 어떠한 작은 변화도 여러 페이지의 수정을 요구하고 각 페이지의 모든 버전을 저장하기 위해 많은 공간이 필요

광고 삽입과 같은 몇몇 트랜스 코딩은 정적인 방법으로는 수행할 수 없는데, 이는 페이지를 요청한 사용자에게 달려 있기 때문.