Make Better Software의 추천 도서

얼마 전에 StackOverflow, Trello 등으로 유명한 조엘 스폴스키Fog Creek에서 Make Better Software라는 이름의 매거진 형태의 문서를 공개했다. (얼마나 자주 그리고 정기적으로 나올지는 모르겠지만) 제 1호라서 그런지 다양한 인터뷰와 전문가 기고 등이 꽤 알차다.

Make Better Software 1호의 마지막에는 프로그래밍과 기술적 리더십에 대한 19종의 추천 도서 목록있다.

어떤 팀이 좋은 팀일까요? – Tech planet 2016 참가 후기

SONY DSC

이번 주 월요일에는 Tech planet 2016 행사장에 다녀왔다. 그 곳에서 만 하루 동안 부스를 운영하면서 얻은 성과와 느낌을 공유하고자 한다.

부스를 제안 받고 나서 한 동안 고민이었다. ‘기술 콘퍼런스에서 부스를 열어야 한다면, 우리는 어떤 주제를 다루는 것이 좋을까?’ 단순하게 제품을 홍보하고, 뻘쭘하게 질문을 던져오는 몇몇 사람들에게 피상적인 소개를 해주는 그런 부스를 운영하고 싶지는 않았다. 그래서 고심 끝에 선택한 것이 바로 “어떤 팀이 좋은 팀일까요?”라는 주제였다. 처음에는 행사 분위기와 어울리는 주제일지 반신반의 했었는데, 막상 현장에서 반응을 보니 결과적으로 색다르고 괜찮은 시도였지 않았나하는 생각이 든다.

팀 분위기에 영향을 미치는 요소

대략 2년 전쯤, NBT의 제품 개발 조직 구성원들을 대상으로 “좋은 팀이 되기 위한 요소”라는 설문 조사를 진행했던 적이 있다. 팀의 분위기를 결정하는 20가지 요소들을 구성원들에게 제시한 다음, 다음과 같은 방식으로 조사를 진행해서 그 결과를 내부에 공유하고 함께 이야기를 나누었다.

  • 20가지 요소들을 각자 중요하다고 생각하는 순서대로 나열하여 순위를 매긴다.
  • 순위마다 20점부터 1점까지 부여하고 팀 전체 평균 순위를 뽑아본다.
  • 각자의 순위, 팀 전체 순위, InfoQ 순위를 서로 비교해본다.
  • 팀도 중요하게 생각하고 나도 중요하게 생각하는 요소, 팀에서는 중요하게 생각하지만 나는 중요하지 않다고 생각하는 요소, 팀에서는 중요하게 생각하지 않지만 나는 중요하다고 생각하는 요소, 팀도 나도 중요하지 않다고 생각하는 요소가 무엇인지 살펴본다.
  • 상관 분석을 통해, 각자의 순위와 팀 전체 순위의 상관도를 알아본다.
  • 결과에 대해 함께 논의한다.

이 항목들은 InfoQ의 “What Influences the Mood of Agile Teams?”에서 가져온 것이다. 예전에는 전세계의 여러 사람들이 참여한 결과를 볼 수 있었는데, 아쉽게도 지금은 더 이상 볼 수가 없다. 당시 기록해둔  InfoQ의 순위와 NBT 내부에서 조사했던 순위는 다음과 같다.

InfoQ 순위
(2014년 11월)
NBT 순위
(2014년 12월)
  1. 상호 신뢰 수준
  2. 업무 자유도
  3. 협업
  4. 서로에게 솔직한 태도
  5. 수고에 대한 인정
  6. 집중할 수 있는 업무 환경
  7. 고객으로부터의 피드백
  8. 외부 압박으로부터의 보호
  9. 끈끈한 유대감
  10. 정기적인 회고
  11. 같은 곳에서 일하기
  12. 성공에 대한 축하
  13. 충분한 도구와 장비
  14. 심리적으로 안전한 느낌
  15. 경력과 경험
  16. 팀원 간의 피드백
  17. 팀원들의 사회성
  18. 구성원의 다양성
  19. 발전을 위한 외부 활동
  20. 훌륭한 업무 공간
  1. 상호 신뢰 수준
  2. 서로에게 솔직한 태도
  3. 협업
  4. 업무 자유도
  5. 심리적으로 안전한 느낌
  6. 끈끈한 유대감
  7. 외부 압박으로부터의 보호
  8. 경력과 경험
  9. 정기적인 회고
  10. 성공에 대한 축하
  11. 팀원들의 사회성
  12. 팀원 간의 피드백
  13. 수고에 대한 인정
  14. 구성원의 다양성
  15. 집중할 수 있는 업무 환경
  16. 고객으로부터의 피드백
  17. 같은 곳에서 일하기
  18. 훌륭한 업무 공간
  19. 충분한 도구와 장비
  20. 발전을 위한 외부 활동

좋은 팀이 되려면 어떤 요소가 필요한지, 각 개개인에게는 무엇이 중요한지, 팀은 전반적으로 어떤 지향점을 갖고 있는지, 그 지향점과 특히 가까이 있는 사람은 누구이고 멀리 있는 사람은 누구인지 이야기를 나눠보면서 여러 가지를 느끼고 배울 수 있었던 좋은 경험이었다.

또한 놀라운 것은, 전세계 불특정 다수를 대상으로 했던 InfoQ의 순위와 NBT 내부 순위 중에서 상위 네 가지 항목(상호 신뢰 수준, 서로에게 솔직한 태도, 협업, 업무 자유도)이 서로 똑같았다는 점이다. 20가지 모두가 좋은 팀이 되기 위해 중요한 요소들이지만, 그 중에서도 “서로 신뢰하는 관계 속에서 솔직한 태도로 활발하게 협업하는 팀에 속해서 자유롭게 일하고 싶어하는 마음“은 어디에서나 많은 사람들의 바람이라는 사실을 알게 되었다.

다른 사람들의 생각은 어떨까?

그렇다면 다른 환경에서 일하는 국내 개발자들의 생각은 어떨지 궁금했다. 비슷할까? 다를까? 다르다면 어떤 부분이 다를까? 얼마나 다를까? 그래서 콘퍼런스 참여자 분들에게 동일한 20가지 요소들을 제시하고 투표를 실시해서 그 결과를 모아보았다. 기념품으로 디자인팀에서 제작해준 인덱스 카드의 위력인지 모르겠지만, 생각보다 많은 분들이 길게 줄까지 서가며 적극적인 반응을 보여주셔서 감동이었다. (투표에 참여해주신 411분 모두에게 감사드립니다.)

SONY DSC

투표 결과와 나의 생각

최종 투표 결과 및 순위는 다음과 같다.

result

InfoQ 순위
(2014년 11월)
NBT 순위
(2014년 12월)
Tech planet 순위
(2016년 10월)
  1. 상호 신뢰 수준
  2. 업무 자유도
  3. 협업
  4. 서로에게 솔직한 태도
  5. 수고에 대한 인정
  6. 집중할 수 있는 업무 환경
  7. 고객으로부터의 피드백
  8. 외부 압박으로부터의 보호
  9. 끈끈한 유대감
  10. 정기적인 회고
  11. 같은 곳에서 일하기
  12. 성공에 대한 축하
  13. 충분한 도구와 장비
  14. 심리적으로 안전한 느낌
  15. 경력과 경험
  16. 팀원 간의 피드백
  17. 팀원들의 사회성
  18. 구성원의 다양성
  19. 발전을 위한 외부 활동
  20. 훌륭한 업무 공간
  1. 상호 신뢰 수준
  2. 서로에게 솔직한 태도
  3. 협업
  4. 업무 자유도
  5. 심리적으로 안전한 느낌
  6. 끈끈한 유대감
  7. 외부 압박으로부터의 보호
  8. 경력과 경험
  9. 정기적인 회고
  10. 성공에 대한 축하
  11. 팀원들의 사회성
  12. 팀원 간의 피드백
  13. 수고에 대한 인정
  14. 구성원의 다양성
  15. 집중할 수 있는 업무 환경
  16. 고객으로부터의 피드백
  17. 같은 곳에서 일하기
  18. 훌륭한 업무 공간
  19. 충분한 도구와 장비
  20. 발전을 위한 외부 활동
  1. 상호 신뢰 수준
  2. 팀원 간의 피드백
  3. 수고에 대한 인정
  4. 업무 자유도
  5. 협업
  6. 집중할 수 있는 업무 환경
  7. 외부 압박으로부터의 보호
  8. 서로에게 솔직한 태도
  9. 심리적으로 안전한 느낌
  10. 경력과 경험
  11. 구성원의 다양성
  12. 충분한 도구와 장비
  13. 발전을 위한 외부 활동
  14. 훌륭한 업무 공간
  15. 팀원들의 사회성
  16. 끈끈한 유대감
  17. 고객으로부터의 피드백
  18. 정기적인 회고
  19. 성공에 대한 축하
  20. 같은 곳에서 일하기

결과에 대한 나의 생각을 가볍게 정리해보자면…

  • 신뢰! 신뢰! 신뢰! 이번에도 부동의 1위는 “상호 신뢰 수준”
  • 특히 상위 6가지 항목(상호 신뢰 수준, 팀원 간의 피드백, 수고에 대한 인정, 업무 자유도, 협업, 집중할 수 있는 업무 환경)에 의견이 집중되는 현상이 보였다. 나머지는 뭘까? 상대적으로 덜 중요함? 인식 부족? 포기 내지는 타협?
  • 세 순위에서 공통적으로 상위에 포진하고 있는 상호 신뢰 수준, 협업, 업무 자유도는 문화적인 차이를 뛰어넘는 일종의 절대 가치일 수도 있겠다는 생각이 들었다.
  • “팀원 간의 피드백”과 “수고에 대한 인정”이 이번에 상대적으로 유독 높은 득표율을 얻은 것은 무슨 의미일까? 여기에서 내 머릿속에 퍼뜩 떠오른 단어는 “외로움”이었다.
  • “정기적인 회고”나 “고객으로부터의 피드백” 등이 얻은 저조한 득표수가 놀랍다는 우리팀 내부 의견이 있었다. 많은 조직에서 이런 것들을 압박의 수단으로 악용하기 때문일까?
  • “팀장이 중요한데 팀장 항목이 없네요.”라는 의견을 주신 분이 있었다. 물론 팀장이 팀에 엄청나게 중요하고 큰 영향을 미친다는 사실에는 공감한다. 이 맥락에서 내가 생각하는 팀장, 즉 리더의 역할은 이렇다. “20가지 요소를 모두 개선할 수 있는 환경을 만드는 것”
  • 장기적 관점에서 조직의 변화를 이루어야 하는 리더, 변화 관리자, 애자일 코치들이 어떤 부분에서 단기적으로 가시적 성과를 이루어야 하는 지를 알 것 같았다.

(투표에 참여하신 분들이 어떤 맥락에서 어떤 경험을 떠올리며 투표를 했는지는 각자 전부 다를 것이기 때문에, 다양한 해석의 여지가 있다. 그래서 구체적인 해석은 이 글을 보시는 각자의 몫이 아닐까 생각한다.)

조직 문화 변화를 위한 관리자의 리더십 – #3. 변화를 만들기 위한 태도

얼마 전 SK 플래닛 내부 콘퍼런스인 @Tech에서, “조직 문화 변화를 위한 관리자의 리더십”이라는 주제로 평소에 하고 싶었던 이야기를 전해드릴 수 있는 기회가 있었다. 그 때 공유했던 내용을 중심으로 그 동안 NBT 제품 개발 조직에서 일해오면서 내가 느껴왔던 관리자의 역할과 변화에 대한 생각을 두 차례에 걸쳐 정리해보려고 한다.

두 개의 글로 마무리를 하려고 했지만 마무리가 조금 아쉬워어 세 번째 글을 추가하려고 한다.  이번 글은 “Self-organizing 팀을 만들려면 관리자는 어떤 태도로 변화를 이끌어야 하는가?”에 대한 일화다.

외국인 개발자와의 일화

지금은 그렇지 않지만, 한 때는 NBT에도 외국인 개발자가 있었다. 이 친구의 약점은 한국어 대화 능력이 매우 서툴다는 점이었다. 캐시슬라이드 개발 초기에는 인원이 몇 명 안되니 영어로 의사소통을 하는 것이 크게 부담스러운 상황이 아니었지만, 시간이 흐르고 조직이 커지면서 (나를 포함해서) 영어로 대화하기 부담스러워하는 구성원들이 늘어나자 이 외국인 개발자는 조금씩 소통에서 멀어지기 시작했다. 주변에서 나름 챙겨주고 관심을 가져주는 사람들도 있었지만 거기에 적극적으로 호응할만큼 활발하고 사교적인 성격도 아니었다. 창업 초기부터 회사에 큰 기여해왔다고 자부해왔던 이 친구는 그런 흐름이 불만스러웠고 더욱 더 주변 사람들과 멀어져갔다. 회사에 와서도 주변 사람들과 하루 종일 한 마디도 하지 않았고, 그렇게 혼자 일하다보니 업무 성과도 좋을리 없었다. 그가 잘못 마무리한 프로젝트를 다른 팀원들이 처음부터 다시 개발해야 하는 상황이 여러 번 생기니, 주변에서 바라보는 시각도 점점 나빠져갔다.

이 친구도 그런 상황이 무척 힘들었을거다. 그러던 어느 날 잠깐 이야기를 하고 싶다며 나를 찾아왔다.

외: “상황을 바꿔보고 싶어. 그 동안 내가 너무 불만만 표현했었던 것 같아.”

나: “뭐든 도와줄께. 뭐가 필요해?”

외: “내가 뭐부터 하면 좋을까? 좋은 의견 있어?”

나: “음…. 아침에 출근하면 사람들에게 먼저 인사부터 하면 어때? 네가 사람들과 더 친해졌으면 좋겠어.”

외: “별로 어렵지 않네. 좋아, 내일부터 할께.”

 

변화를 시도할 때 느끼는 참을 수 없는 어색함

Self-organization is not self-organized.030

드디어 다음 날.

평소에 안하던 짓을 하려니 엄청 어색했을거다. 사무실로 들어오면서 인사를 하긴 했다. “Good morning…” 하지만 목소리가 너무 작아서 알아차린 사람도 거의 없었고, 그나마 반응을 보여준 사람이 아무도 없었다. 예상치 못한 아침 인사를 들었던 사람들도 분명히 당황했을거다. ‘… 엇! 쟤가 갑자기 왜 저러지?’, ‘뭐.. 뭐.. 뭐야?’, ‘음? 어제 뭔일 있었나?’

다음 날은 목소리가 더 작아졌다. 사람들이 반응을 보이질 않으니 자신감은 반으로 줄고 어색함은 두 배로 늘어버린거다. 내가 반응을 보여주긴 했지만 상황을 바꾸기에는 역부족이었다. 이 친구는 이틀의 시도를 끝으로 아침 인사를 그만 두고 원래대로 돌아가버렸다. 그리고 지금은… 아쉽게도 더 이상 우리와 함께 일하고 있지 않다.

가끔 이런 상상을 해본다. 만약 주변 사람들이 반응을 보이건 말건 아침 인사를 한 달 동안 계속 했었더라면, 아니 열흘 정도만 계속 했었더라면 미래가 어떻게 달라졌을까?

우리는 변화의 끝에 무엇이 기다리고 있는지 알고 있다

결혼한 분이라면 배우자 분께, 아직 미혼인 분이라면 남자 친구나 여자 친구에게 오늘부터 매일 매일 “사랑합니다!”라고 말해보자. (이미 그렇게 하고 계신 분이라면 정말 훌륭한 분이라고 박수쳐드리고 싶다.)

아마도 대부분 엄청 쑥스럽고 부끄러울 것이다. 처음에는 상대방도 당황스러워 할 것이다. “아니~ 저 사람이 갑자기 왜 저러지? 무슨 사고 쳤나?” 그게 무슨 상관인가? 그 다음 날도 또 시도해보자. 하루, 이틀, 열흘, 한 달… 계속 하다보면 처음에 느꼈던 어색함과 당황스러움은 언제 그랬냐는 듯이 사라지고, 서로의 애정이 예전보다 비교할 수 없을 만큼 깊어지리라고 확신한다. 어느 순간 상대방도 거기에 적극적으로 호응해줄 날이 올 것이다. 그것도 예상보다 훨씬 빠르게…

변화란 그런 것이다. 변화는 언제나 처음에는 부끄럽고 어색하다. 굳이 그렇게까지 해야 하나 싶은 생각이 들기도 할 것이다. 하지만, 매일매일 서로 사랑한다고 이야기하는 부부의 미래가 어떤 모습으로 바뀔지 상상해보자. 우리 모두는 변화의 끝에 무엇이 기다리고 있는지 이미 잘 알고 있다. 다만 과감하게 첫 발을 내딛지 못하고 있을 뿐이다.

조직 문화 변화를 위한 관리자의 리더십 – #2. Self-organization을 위해 관리자가 알아야 할 5가지

얼마 전 SK 플래닛 내부 콘퍼런스인 @Tech에서, “조직 문화 변화를 위한 관리자의 리더십”이라는 주제로 평소에 하고 싶었던 이야기를 전해드릴 수 있는 기회가 있었다. 그 때 공유했던 내용을 중심으로 그 동안 NBT 제품 개발 조직에서 일해오면서 내가 느껴왔던 관리자의 역할과 변화에 대한 생각을 두 차례에 걸쳐 정리해보려고 한다.

  1. Self-organization is not self-organized
  2. Self-organization을 위해 관리자가 알아야 할 5가지
  3. 변화를 만들기 위한 태도

이전 글에서 강조했듯이 Self-Organization은 저절로 만들어지지 않는다. Self-Organization이 이루어지려면 관리자, 특히 실무자들과 직접 함께 일하는 현장 관리자들의 역할이 매우 중요하다. 다만, 그렇게 하기 위해서는 사람들이 흔히 생각하는 관리자와는 조금 다른 모습의 관리자가 필요하다. 즉, 관리자의 변화가 Self-Organization을 만들기 위한 첫 단계다!

첫째. 심리적으로 안전한 조직은 만든다.

Dilbert_2007-02-15

우리는 주변에서 위의 세 컷 짜리 만화와 비슷한 상황을 일상적으로 만난다. 서로 투명하게 소통해야 할 구성원들이 정보를 감추고, 그로 인해서 프로젝트가 점점 산으로 올라간다. 이런 일이 생기는 이유는 비난을 두려워하기 때문에, 즉 심리적 안전감(Psychological Safety)이 부족하기 때문이다.

구글에서는 2012년부터 엔지니어, 통계학자, 심리학자, 사회학자 등을 고용하여 팀의 생산성을 결정하는 요인이 무엇인지 알아보는 “아리스토텔레스“라는 이름의 프로젝트를 내부적으로 진행했다. 그들이 4년 동안 연구하여 밝혀낸 팀의 생산성을 결정하는 다섯 가지 요인 중에서 가장 중요한 요인이 바로 심리적 안전감이다.

심리적 안전감이란 “나의 행동이 다른 사람들로부터 비난 받지 않을 것이라는 믿음“이다. 더 나아가 “나의 행동이 다른 사람들로부터 지지받을 것이라는 믿음”이라고 할 수도 있겠다. 심리적으로 안전한 조직은 하루 아침에 만들 수 없다. 리더의 행동이 조금씩 조금씩 구성원들에게 영향을 미치고, 그것이 오랜 기간 누적되어야 그런 조직을 만들 수 있다.

자기 자신을 포함하여 세상에 완벽한 사람은 존재하지 않으며, 전혀 그렇게 될 필요도 없다고 생각해보자. 그러면 부정적 피드백을 받아들이고 실수를 인정하기가 더 쉬워진다. 그리고 다른 사람들에게 좀 더 솔직하게 자신의 감정을 전달할 수 있다. 심리적으로 안전한 조직을 만들기 위한 출발 지점은 바로 그 곳이다.

둘째. 체계적으로 위임한다.

delegation-poker-cards

모든 일들을 하나부터 열까지 직접 챙길 수 있다면 좋겠지만 그건 불가능한 일이다. 그렇게 할 수 있는 상황일지라도 모든 결정을 혼자 내리고 실행하는 것은 좋은 선택이 아니라는 것을 대부분은 잘 알고 있다. 리더에게 위임이 중요하다는 이야기는 많이 들어왔겠지만, 막상 시도해보면 위임이 생각만큼 쉽지 않다는 것을 알게 된다. 어떤 일을 얼마만큼 위임해야 하는지 잘 모르기 때문이다.

얼마 전에 있었던 Agile 2016에서 위르헌 아펄로(Jurgen Appelo)는 “Managing for Happiness“라는 제목의 기조 연설을 했는데, 거기에서 그는 위임에 모두 일곱 단계가 있다고 말한다.

  1. TELL – 관리자가 결정을 내린 다음 알린다. 그 이유를 설명할 수도 있다.
  2. SELL – 관리자가 결정을 내린 다음, 다른 사람들을 설득하여 이해시킨다.
  3. CONSULT – 관리자는 먼저 의견을 물어본 다음, 그 의견을 존중하여 결정을 내린다.
  4. AGREE – 관리자는 관련이 있는 모든 사람들과 논의하고, 합의를 통해 의견 일치를 이룬다.
  5. ADVICE – 관리자는 의견을 이야기하고 다른 사람들이 결정을 내릴 때 그 의견이 받아들여지기를 기대한다.
  6. INQUIRE – 다른 사람들이 결정을 내리도록 한 다음, 나중에 그 결정의 이유를 설명해달라고 요청한다.
  7. DELEGATE – 다른 사람들이 결정을 내리도록 하고 자세한 내용까지는 알려고 하지 않는다.

위임하고자 하는 업무가 있다면 그 업무에는 어떤 단계가 적당할지 생각해보고 위임을 한 번 시도해보자. 그런 다음 최적의 위임 단계를 찾기 위해 그 단계를 앞 뒤로 올리고 내려본다. 특정 업무가 현재 어떤 단계의 위임이 이루어지고 있는지 구성원들과 함께 알고 있다면 더 좋을 것 같다.

셋째. 인력 최적화는 미신이라는 것을 인식한다.

대부분의 관리자는 구성원들의 여유로운 모습을 보면 스스로 불안해한다. 인력을 100% 최적화하는 것이 중요하며, 120~130%의 업무를 부여해야 간신히 100%의 업무를 해낼 수 있다고 생각하기 때문이 아닐까 하는 생각이 든다. 이런 생각은 단언컨대 잘못된 믿음이다.

첫째, 우리에게는 항상 “급하지는 않지만 중요한 일”이 있다. 여유 시간(slack)이 없다면 이런 일들은 도대체 언제 해결할 수 있을까? 이상적인 이야기이긴 하지만, 팀의 역량이 100%라면 업무 수준을 80~90%로 유지하는 것이 좋다. 나머지 10~20%를 어떻게 활용할지는 오로지 팀원들의 선택이어야 한다. 물론 처음에는 사람들이 그 시간을 의미있게 사용하리라는 믿음이 없어 매우 불안할 것이다. 사람들이 그 시간에 정말로 급하지는 않지만 중요한 일을 하던, 자기 계발을 위해 학습을 하던, 다른 사람들에게 도움을 주던, 심지어 놀던, 스스로 자유롭게 선택할 수 있도록 만들어 주어야 한다. Self-organization을 위해서는 관리자의 불안감을 해소하는 일보다 그것이 훨씬 더 중요하고 먼저 이루어져야 할 일이다.

rowing-wallpapers-for-mobile

둘째, 소프트웨어 개발 프로젝트에서 일어나는 상당수의 비극은 참여자들 사이에 공동의 목표가 없기 때문에 생겨난다. 지금까지 내가 경험해 왔던 모든 조직을 보면 항상, 관리자, 기획자, 개발자, QA, 테스터, 디자이너, 인프라 등 모든 참여자의 목표가 서로 전부 달랐었다. 예를 들어, 기획자는 PPT 작성 및 관리자의 승인 완료가 목표였고, 개발자는 일단 돌아가기는 하는 소프트웨어 구현이 목표였으며, 테스터는 최대한 많은 개수의 버그를 찾아내는 것이 목표였다. 사실 이들 모두의 1차 목표는 고객에게 가치를 제공하는 것이 되어야 옳다. 서로 목표가 다를 이유가 없다. 그렇게 하지 못하고 있는 것은 여기에서도 인력 최적화라는 잘못된 믿음 때문이다. 이런 이야기를 많이 듣는다. “기획자는 프로젝트 막바지에 별로 할 일이 없지 않나요? 다른 프로젝트에 투입하는 것이 더 효율적이죠.” “테스터를 프로젝트 초반에 투입하는 건 낭비에요. 다른 프로젝트를 진행하다가 마지막에 합류하면 됩니다.” 이래가지고서는 공동의 목표를 만들래야 만들 수가 없다. 나는 모든 직군이 함께 프로젝트를 시작하고 함께 끝내는 것이 이상적인 모습이라고 믿는다. 사람들에게 할 일이 없는 시간이 생겼을 때에는 어떻게 해야 할까? 그 시간을 어떻게 활용할 지 역시 그 사람들의 선택이다.

넷째. 조직 문화의 변압기가 된다.

Self-organization is not self-organized.027

조직 문화를 바꾸려면 최고 경영진으로부터의 변화(Top-down)와 일선 실무자들로부터의 변화(Bottom-up)가 동시에 이루어져야 한다. 하지만, 조직의 모든 계층이 합심하여 동시에 변화를 이뤄내기란 불가능에 가깝다. 구성원들 각자의 이해가 전부 다르고 좀 더 복잡하게 얽혀있는 대규모 조직일수록 더욱 어려울 것이다.

얼마 전에 이런 질문을 받은 일이 있다. “팀에 애자일 문화를 도입해보고 싶습니다. 그런데, 상사의 반응이 그다지 호의적이지 않아요. 그 분을 어떻게 설득해야 좋을까요?” 순간 생각난 두 가지 의견을 말씀드렸다. 그 중 하나가 “몰래 하세요”였다. 애자일에 부정적인 경험이 있는 사람들을 설득하는 최선의 방법은 말이 아닌 성과로 보여주는 것이다. 사실 애자일이 아니더라도 모두 마찬가지다. 내가 몰래 하라는 의견을 드린 이유는, 상사 분을 설득하는 일에 에너지를 쏟기보다 실질적인 성과를 얻을 수 있는 방법을 찾는 데 에너지를 쏟는 편이 더 좋겠다는 생각이 들었기 때문이다.

조직 문화가 한 번에 확 바뀔 수는 없다. 필연적으로 조직 내 어딘가는 변화를 빨리 수용하게 될테고, 다른 어딘가는 상대적으로 변화를 늦게 받아들이게 될 것이다. 그 사이에 서게 될 가능성이 가장 높은 사람들이 중간 관리자다. 중간 관리자가 할 수 있는 중요한 역할 중 한 가지가 바로 조직 문화의 변압기다. 팀 내부로는 새로운 문화를 키워가고, 동시에 외부로는 기존 시스템과 문화를 충분히 존중하면서 거기에서 요구하는 역할을 수행한다. (물론 그 반대 상황도 있을 수 있겠다.) 조직 내에서 혁명을 일으킬 것이 아니라면, 변화는 점진적으로 이루어지는 것이 좋다.

다섯째. 메시지를 일치적으로 전달한다.

Self-organization is not self-organized.029

나는 아직 일치적(congruence)인 메시지 전달에 대해 정확히 설명하는 데 어려움을 느낀다. 그래도 간단히 이야기하자면, 언행일치와는 약간 다른 개념인데, 모든 상황에서 자기(self), 타인(other), 상황(context)이라는 세 가지 요소를 전부 고려하여 행동하고 말하는 것이다. 자기(self)를 고려하지 않은 메시지는 상대방의 비위를 맞추는 메시지가 되고, 타인(other)을 고려하지 않은 메시지는 비난하는 메시지가 된다. 메시지에 자기와 타인이 모두 빠지고 상황(context)만 남게 되면 지나치게 이성만을 앞세우는 메시지가 될 것이고, 세 가지 전부 고려하지 않으면 회피나 부정과 같은 부적절한 메시지가 되어버린다. 사실 메시지를 일치적으로 전달하는 능력은 관리자 뿐만 아니라 모든 사람들에게 필요한 능력이다.

조직 문화 변화를 위한 관리자의 리더십 – #1. Self-organization is not self-organized

얼마 전 SK 플래닛 내부 콘퍼런스인 @Tech에서, “조직 문화 변화를 위한 관리자의 리더십”이라는 주제로 평소에 하고 싶었던 이야기를 전해드릴 수 있는 기회가 있었다. 그 때 공유했던 내용을 중심으로 그 동안 NBT 제품 개발 조직에서 일해오면서 내가 느껴왔던 관리자의 역할과 변화에 대한 생각을 두 차례에 걸쳐 정리해보려고 한다.

우리 NBT 같은 소규모 스타트업 조직과 SK 플래닛 같은 대규모 조직은 많은 부분에서 차이가 있겠지만, 그럼에도 불구하고 결코 다르지 않은 한 가지는 조직 문화의 변화를 위해 관리자, 특히 현장 관리자의 역할이 엄청나게 중요하다는 것이다. 이 부분에 대한 나의 생각은 시간이 지날수록 점점 확고해지고 있다.

Self-Organizing 팀

Self-organization is not self-organized.005

애자일 선언에는 12가지 애자일 선언 이면의 원칙이 있다. 그 중에서 조직과 직접적으로 관련이 있는 항목은 두 가지다.

그 중 첫 번째인 5번 원칙은 리더에게 보내는 메시지다.

“동기가 부여된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.”

그리고, 12번 원칙은 팀원들에게 보내는 메시지다.

“팀은 정기적으로 어떻게 하면 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.”

상상만 해도 행복하다. 자발적으로 동기가 부여된 사람들이 모이고 리더는 그 사람들에게 필요한 환경과 지원을 제공하고 전폭적인 신뢰를 보낸다. 그리고 팀은 어떻게 하면 더 잘 할 수 있을지 스스로 고민하고 실행한다. 우리는 이런 팀을 Self-Organizing 팀이라고 부른다.

그렇다면, Self-Organizing 팀은 왜 필요한 것일까?

Speed vs. Agility

Self-organization is not self-organized.009

우사인 볼트에게 주어진 목적지는 분명하다. 딱 100m 앞이다. 어떤 경로로 가야 할지도 명확하다. 옆 레인에서 어떤 선수가 뛰고 있는지도 크게 중요하지 않다. 이런 상황에 있는 우사인 볼트에게 가장 중요한 가치는 당연히 속도(speed)다.

리오넬 메시도 둘째가라면 서러울 정도로 스피드가 좋은 선수다. 하지만 메시에게 스피드는 중요한 여러 가지 가치 중 하나일 뿐이다. 경기의 흐름을 읽어서, 슛을 해야 할지, 드리블을 해야 할지, 아니면 패스를 해야 할지 신속하고 올바르게 결정할 수 있는 순간 순간의 판단력이 훨씬 더 중요하다. 그 판단력이 경기를 지배할 수 있는 힘을 부여한다. 메시에게 가장 중요한 가치는 기민함(agility)이다.

우리가 처해 있는 환경은 100m 트랙이라기보다는 축구 경기장에 가깝다. 하루가 다르게 새로운 기술이 나타나고, 시장에 막강한 경쟁자가 등장하기도 한다. 우리는 불활실하고 예측하기 어렵고 급변하는 상황에 놓여있다. 이런 환경에서 100m 달리기처럼 목적지를 찍어 놓고 정해놓은 길로 빠르게 달리는 것은 어리석은 일이다. 우리는, 매번 감독의 지시를 받고 움직이는 것이 아니라, 큰 전략을 이해하면서 스스로 판단하고 행동할 수 있는 축구 선수가 되어야 한다. 그리고 그 목표는 혼자가 아니라 동료들과 함께해야 이룰 수 있다.

Self-Organizing 팀이 필요한 이유는 분명하다. 90분 내내 감독의 지시를 받아 움직이는 축구 선수를 상상할 수 있을까? Self-Organizing 팀은 불확실한 환경을 극복하기 위한 필수 요소다.

관리자에 대한 부정적 인식

가장 널리 사용되고 있는 애자일 방법론인 스크럼을 살펴보면, 스크럼에서는 관리자의 역할을 그리 긍정적으로 평가하지 않는다는 생각이 든다. 스크럼 팀에 필요한 역할을 제품 책임자, 개발팀, 스크럼 마스터의 단 세 가지로 규정하고 있고, 스크럼 교육에 실제로 참여해보면 앞으로는 더 이상 관리자가 필요하지 않다고 강조한다.

스크럼의 예를 들 필요도 없이, 관리자에 대한 개발자들의 인식은 대부분 부정적이다. 개발자들은 관리자가 자신의 자율성과 창의성을 가로막고, 잘못된 의사 결정으로 프로젝트를 엉뚱한 방향으로 끌고 갈 수도 있는 사악한 존재라고 규정한다. 또한, 자신이 관리자의 책임을 맡게 되는 상황은 최대한 피해야 할 일이라고 생각한다. 덕분에 타의에 의해 관리자가 되는 운명의 그 날을 아무런 준비 없이 맞이하고, 그 결과 자신도 그런 부정적인 모습의 관리자가 되어 버린다.

그렇다면 관리자를 바라보는 일반적인 인식은 왜 그렇게 부정적인 것일까? 그 이유는 정말 단순하다. 많은 관리자가 가치를 생산해내는 데 실질적인 도움을 주지 못하고 있기 때문이다.

Self-Organizing 팀은 저절로 만들어지지 않는다

Self-organization is not self-organized.010

하지만, 관리자가 필요 없다거나 도움이 안된다는 말은 관리자들에게 위협적으로 들릴 수 있다. 조직의 변화는 모두가 이익을 얻을 수 있는 방향으로 이루어져야 한다. 누군가에게 불행한 변화가 조직에서 과연 매끄럽게 이루어질 수 있을까?

내가 지금까지 얻은 결론은 “Self-Organizing 팀이 절대 저절로 만들어지지는 않는다“는 것이다. Self-Organizing 팀은 훌륭한 조직 문화 속에서 서서히 자라나는 것이다. 그런 문화를 만드는 데 가장 큰 영향력을 미칠 수 있는 사람이 바로 관리자다. 관리자는 조직 문화를 훌륭한 모습으로 가꿀 수도 있고, 누렇게 말라 죽어버린 모습으로 망쳐버릴 수도 있다.

그렇기 때문에 관리자들, 특히 실무자들과 매일 매일 함께 일하는 현장 관리자들은 변화의 장애물이 아니라 오히려 조직 문화 변화의 중심이 되어야 하고, 또한 그렇게 될 때 조직 문화가 가장 훌륭하고 성공적으로 변화할 수 있다고 믿는다. 변화를 통해 Self-Organizing 팀이 자라날 수 있는 문화를 가꿔가기 위해서는 반드시 제일 먼저 관리자 자신의 변화가 이루어져야 한다.

마무리

그렇다면 관리자가 어떤 모습으로 변화해야 Self-organizing 팀이 자라날 수 있는 조직 문화를 만들 수 있을까? 다음 글에서는 내가 생각하기에 Self-organization을 위해 관리자가 알아야 할 다섯 가지에 대해서 이야기해보려고 한다.

다음글: Self-organization을 위해 관리자가 알아야 할 5가지

[NBT가 일하는 방식 #5] 팀 건강 검진

건강한 조직 문화를 갖추고 유지하려면, 짝 프로그래밍이나 코드 리뷰, 일일 스탠드업 회의처럼 주기가 짧은 피드백 루프도 중요하지만, 긴 안목에서 우리가 제대로 된 방향으로 가고 있는지 알아볼 수 있도록 주기가 긴 피드백 루프도 있어야 한다. 우리 NBT에서는 2014년 말부터 6개월마다 주간 회고 시간에 “팀 건강 검진“을 진행하고 있고, 얼마 전에 네 번째 건강 검진을 진행했다.
NBT의 팀 건강 검진은 내용 측면에서 Spotify의 Squad Health Check를 거의 그대로 따왔고, 진행 측면에서 우리에게 맞게 바꿔 적용하고 있다.

20141103_145437635_iOS
1) 2014년 하반기
20150828_043642820_iOS
2) 2015년 상반기
20160112_073132336_iOS
3) 2015년 하반기
20160712_114457897_iOS
4) 2016년 상반기

팀 건강 검진은 팀이 얼마나 건강한 상태인지 알 수 있는 11가지 항목(가치 전달, 쉬운 릴리스, 재미, 코드 상태, 학습, 미션, 졸인가 선수인가, 속도, 안정적 프로세스, 지원, 팀워크)에 대해 구성원들의 솔직한 의견을 묻고 대략적인 상황을 공유하는 시간이다.
아래는 우리가 팀 건강 검진 시간에 사용하는 프리젠테이션 자료다.
(물론 항목은 얼마든지 바꿀 수 있다.)

진행 순서

1) 함께 모인 구성원들에게 팀 건강 검진의 의미를 간략하게 공유한다.

2) 투표 방법을 알려준다. (우리는 내 의견이 주변 사람들로부터 영향을 받지 않도록 모든 사람이 동시에 엄지 손가락을 들어올리는 투표 방법을 사용하고 있다.)

voting.001

3) 11가지 항목에 대해 투표하고 의견을 나누는 시간은 각각 5~10분 정도가 적당하다. 우선 해당 항목에 대해 짧게 설명하고, 현재 상태에 대해 어떻게 생각하는지 투표한다. (이 때 미리 정해놓은 몇몇 자원 봉사자(?)들이 각 엄지 손가락의 수를 센다.) 그 다음에는 추세를 어떻게 생각하는지 다시 한 번 더 투표한다.

세 번째 항목인 “재미(Fun)”를 예로 들자면, “현재 담당하고 있는 업무가 너무 재미 없고 심각한 상황이라고 생각하지만, 점점 좋아지고 있음을 느낀다.”라는 의견이라면, 첫 번째 투표에서는 엄지 손가락을 아래로 들고 두 번째 투표에서는 엄지 손가락을 위로 드는 것이다.

4) 투표가 끝나면 결과의 의미와 각자의 의견을 나누는 시간을 갖는다. 이 부분이 가장 중요하다. 좋다, 보통이다, 나쁘다와 같은 의견을 그냥 투표로 모을거라면 이걸 하는 의미가 하나도 없다. 각자가 느끼는 문제점은 무엇인고, 왜 그렇게 생각하는지를 모두가 함께 나누는 것이 팀 건강 검진의 핵심이다.

이때 내가 주의를 기울이는 부분은 첫째, 소수 의견을 갖고 있는 사람에게는 반드시 의견을 밝힐 수 있도록 해주고, 둘째, 참여자들에게 최대한 공평하게 발언 기회를 부여하는 것이다.

5) 마무리 단계에서 팀 건강 검진에 대한 소감을 나누는 회고 시간을 갖는다.

결과가 아니라 과정이 중요하다

첫 번째 건강 검진을 진행한 다음 가장 기억에 남는 피드백은 “지금까지 회고 중에서 제일 좋았다. 하고 싶었던 이야기를 실컷 할 수 있었다.”였다. 물론 지금은 인원이 늘어나서 인당 발언 시간이 많이 줄어들긴 했지만, 가장 중요한 것은 팀 건강 검진이 “하고 싶었던 이야기를 할 수 있는 충분한 기회”가 되어야 한다는 점이다.

또한, 팀이 갖고 있는 중요한 개선 포인트를 찾아내고, 그런 지점들을 하나씩 바꿔나가면서 점점 나아지는 모습을 눈으로 직접 확인할 수 있다는 것도 팀 건강 검진의 큰 장점이라고 할 수 있다.

[NBT가 일하는 방식 #4] NBT 개발 문화 성장의 중심 – 엔지니어링 컬처 클래스

NBT가 일하는 방식

  1. 제품 개발 조직의 구조
  2. 칸반이 진화해 온 과정
  3. 제품 개발의 흐름
  4. NBT 개발 문화 성장의 중심 – 엔지니어링 컬처 클래스

QA 클래스의 탄생

2014년 5월, 조직에 칸반을 도입한지 석 달만에 드디어 우리의 첫 번째 병목 지점이 드러났다. 다름 아닌 “테스트” 단계였다.

20140512_025900363_iOS

처음 NBT 개발 프로세스에는 명시적 테스트 단계가 없었다. 그럼에도 불구하고 굳이 테스트 단계를 칸반 보드 상에 넣었던 이유는 단순한데, 당시 구현 마지막 시점에서 때로는 생략하기도 하고 때로는 매우 제한적으로만 이루어지기도 했던 테스트를, 개발자들이 좀 더 노력을 기울이고 의식적으로 진행하기를 원했기 때문이었다. 테스트 단계의 WIP를 제한하지도 않았고, 테스트 단계의 완료 조건을 엄격히 정의하지도 않았었지만, 이 간접적 변화의 효과가 바로 드러나기 시작했다. 칸반 보드의 테스트 단계에 한 번 발생한 티켓 집중 상태는 해소될 기미가 없었다. 그 때 이런 의견이 팀에서 나오기 시작했다.

“우리도 테스터가 필요한 것 아닐까요?”

누군가 “QA”“테스터”의 정확한 차이를 물어본다면 아직도 정확히 답변하기는 어려울 것 같다. 게다가, 내가 아무리 정확한 정의를 내린다 한들, 사람들이 머릿속에 떠올리는 이미지는 완성된 (또는 완성에 가까운) 제품의 기능을 하나씩 실행해보며 문제점을 찾아내서 보고하는 역할일 것이다.NBT에 테스터로 이루어진 그런 조직을 만들고 싶은 마음은 조금도 없었다. 기획, 개발, 디자인, 테스트 등 모든 기능이 제품 개발의 처음부터 끝까지 호흡을 함께 해야 한다고 믿기 때문이다. 우리에게 어울리는 합리적 수준의 품질을 정의하고, 그 품질을 달성 및 유지하기 위해 필요한 모든 활동을 제품 개발 생애 주기 전반에서 수행하는 역할이 필요하다고 판단했다. (주변 이야기를 들어보면 이런 역할을 보통 QA[Quality Assurance, 품질 보증]라고 부르는 듯하다. 그러나, 나는 이 이름도 전혀 옳지 않다고 본다. 왜 특정 몇몇 사람들만 품질에 대한 보증을 해야 하는가? 품질 보증은 CEO부터 제품 개발에 참여하는 모든 사람까지 하는 것이라고 생각한다.)

다행스럽게도 많은 분들이 지원해주셨고, 그 중에서 테스터의 역할을 뛰어넘어 좀 더 큰 그림을 그리고 실현하길 원하는 두 명이 합류해서, NBT에는 QA 클래스가 생겨나게 되었다. 그것이 2014년 여름에서 가을로 넘어갈 무렵이었다.

QA의 역할에 대한 고민

하지만, 모든 일이 생각대로 순조롭게 흘러가지는 않았다. QA 클래스가 생겼는데도 제품 품질이 그대로라는 불만이 조직 여기저기에서 나오기 시작했다. 사람들이 QA라는 역할에 기대하는 바와, 우리가 QA 클래스를 만들면서 지향했던 방향이 일치하지 않았으니, 어쩌면 예견된 일이었을지도 모르겠다. 나 뿐만 아니라 QA 클래스를 포함해서, “우리에게 어울리는 합리적 수준의 품질을 정의하고, 그 품질을 달성 및 유지하기 위해 필요한 모든 활동을 제품 개발 생애주기 전반에서 수행하는 역할”을 하려면 구체적으로 매일매일 어떤 일을 해야하는지 아무도 모른다는 것이 가장 큰 문제였다.

QA 클래스에 테스터의 역할을 기대하는 사람들에게, QA가 서비스 기획이나 개발 단계에 함께 참여해야 한다고 설명하기가 쉽지도 않았고, QA 클래스도 역할 범위 문제 때문에 조심스럽게 접근하다보니 적극적인 역할을 펼쳐보이기가 매우 어려웠다. (어느 조직이든지 역할과 책임 문제가 가장 예민한 폭탄이다.) QA 클래스가 제품 개발 생애 주기 전반에 참여하려면, 거기에 걸맞도록 제품 개발 프로세스 전반의 변화가 필요했다.

엔지니어링 컬처(EC) 클래스의 탄생

프로세스에 대해 사람들이 흔히 저지르는 오류 중 한 가지가, 훌륭한 프로세스를 만들면 모든 일이 잘 될 것이라는 가정이다. 원하는 결과를 얻으려면 프로세스를 만들고 가이드를 배포하는 단계에서 멈추면 안된다. 프로세스를 만든 다음, 그 목표에 공감할 수 있도록 사람들을 설득하고, 구성원들이 충분히 자발적으로 실행할 수 있을 때까지 조직에 적용하면서, 거기에서 발생하는 역동을 주의 깊게 관찰하고 문제점을 보완하는 지속적인 조정이 함께 이루어져야 한다. 다시 말해, 프로세스를 바꾼다는 것은, 조직의 문화를 바꾼다는 의미다.

QA 클래스의 역할을 조직 문화 관점에서 고민하다보니, QA란 결국 내가 하고 있던 애자일 코치 역할과 큰 틀에서 다르지 않다는 것을 깨달았고, 두 역할을 동시에 병행하는 하이브리드 조직을 시도해보면 어떨까 하는 아이디어가 떠올랐다. 문제를 이런 방향으로 풀어보려는고 시도했던 이유는, 다행스럽게도 QA 클래스 구성원들이 애자일 코치로서의 역할에도 관심을 보여주고 있었고, 1년 남짓 함께 생활하면서 두 사람 모두 그 역할을 훌륭하게 잘 해낼 수 있다는 믿음이 생겼기 때문이었다.

서로의 비전과 바람을 솔직히 이야기하면서 함께 밑그림을 그렸고, 2015년 7월에 QA 클래스는 엔지니어링 컬처 클래스(이하 EC 클래스)라는 새로운 이름과 역할로 진화했다.

20150708_155927460_iOS

그 때 세 명이 함께 만들었던, 그리고 지금도 유효한 EC 클래스의 비전은 다음과 같다.

“훌륭한 개발 문화가 매일매일 성장할 수 있는 환경을 누구보다 먼저 고민한다.”

EC 클래스의 역할

EC 클래스에서 수행하고 있는 역할은 크게 세 가지다.

  • 첫 번째는 “지속적 프로세스 개선”이다. 일일 스탠드업 미팅이나 주간 회고, 또는 그 외 모든 모임에서 의견을 조율하고 더 나은 결론을 이끌어낼 수 있는 퍼실리테이터의 역할을 담당한다. 그러면서도, 개발 프로세스의 개선 지점을 도출해내고, 정책을 명시화하며, 품질을 비롯한 개발 완료 조건에 대해서도 고민한다. 이 과정에서 다양한 린/애자일 실천 방법들을 도입하고 실행하기 위해 노력하고 있다. 아직 흔하지는 않지만, 다른 회사에서는 스크럼 마스터, 애자일 코치, 또는 프로젝트 관리자들이 주로 수행하는 역할이라고 볼 수 있다.
  • 두 번째는 “개발 지원 환경의 구축 및 운영”이다. 위키, 이슈 추적 시스템, CI, 코드 정적 분석 도구 등 각종 개발 도구를 리서치하여 구축하고 운영한다. 아울러 테스트 자동화를 위한 각종 지원을 위해서도 노력하고 있다. 대부분의 회사에서 이런 부분은 관심 있는 개발자가 자발적으로 담당하거나, 또는 몇몇 사람들에게 부가 업무로 주어진다. 나는 이런 활동들이 누군가의 선의에 의존하거나, 부가 업무가 되어서는 안된다고 생각한다.
  • 세 번째는 “품질 문화 정착 활동”이다. 제품 및 코드 품질을 측정하고 시각화해서 각 파티에서 자발적으로 개선할 수 있도록 대시 보드 및 품질 지표들을 관리한다. 또한 제품에 대한 조직 내부 및 외부의 피드백에 대한 모니터링도 꾸준히 진행하고 있고, 그런 의견들이 제품에 잘 반영될 수 있도록 개발 과정에 꾸준히 참여한다. 어떤 관점에서 보면 우리가 처음에 바라던 QA의 역할이 여기에 제일 가깝지 않을까 생각한다.

20160426_020956705_iOS20160401_083951966_iOS20160429_083920383_iOS20150923_020427173_iOS

사실 EC 클래스의 역할을 한 마디로 규정하기란 어려운 일이다. EC 클래스는 자신의 역할에 대해서도 지속적으로 개선하고 있기 때문에 상황에 따라 그 역할을 조금씩 바꾸어왔다. 프로젝트를 성공적으로 수행하고, 그 과정에서 구성원들이 만족할 수 있도록 모든 노력을 다 한다는 점에서 어찌보면 리더십 포지션에 가깝다고 볼 수 있다. 그러나 팀장이 팀원들 위에서 지시하고 통제하는 리더십을 발휘하는 것이 일반적인 모습이라면, NBT의 EC 클래스는 팀원들의 옆에서 그들의 어려움을 함께 공감하고 소통하는 방식으로 리더십을 발휘한다.

바람직한 EC 클래스 구성원의 조건

내가 생각하기에, 애자일이나 QA에 대한 경험이나 지식은 EC 클래스 구성원이 되는데 반드시 필요한 조건은 아니다. 어떤 경우에는 그런 조건들이 오히려 방해가 될 수도 있다. 가장 중요한 것은 “더 훌륭한 개발 문화를 이루고자 하는 열망”“나 자신과 주변 사람들의 성장에 대한 관심”이 아닐까.

스크럼이나 XP 또는 칸반 같은 방법을 중요하게 여기는 사람, 기존 시스템에 대한 절망이 분노와 냉소의 모습으로 남아있는 사람, 현재에서 탈출해서 새롭고 신선한 분위기를 원하는 사람보다는, 자신만의 비전을 갖고 있고 그 비전을 이루고자 하는 열정이 있는 사람, 함께 일하는 사람들에게 다가가서 먼저 신뢰를 보여줄 수 있는 사람, 지금에 만족하지 않고 서서히 더 나은 방향으로 나아갈 수 있는 사람과 함께 일하고 싶다.

그런 의미에서 지금 두 명의 EC 클래스 구성원들은 배울 점도 많고 건강한 자극이 되기도 하는 훌륭한 동료들이며, NBT 제품 길드가 지금까지 올 수 있었던 중요한 원동력 중 하나였다고 생각한다.

앞으로 어떤 사람이 새롭게 합류해서, EC 클래스와 구성원들이 어떤 방향으로 진화해갈지 매우 궁금하기도 하고 기대도 된다.


P.S. 그렇습니다. 이 글의 주 목적은 채용입니다^^ NBT의 EC 클래스에 관심이 있는 분이 계시다면, 함께 이야기를 나눠보고 싶습니다. cho.seungbin@nbt.com으로 언제든지 연락주세요.