팀에 무언가 도입한다는 건...
승돌 쓰다
팀에 도구를 도입하고 싶은 경우
도구를 도입한다는 건, 일단 팀의 규모가 어느 정도 되는지에 따라 달라진다.
예를 들어, 4명인 팀과 8명인 팀, 16명인 팀인 경우 모두가 다르다.
내가 현재 속한 4명, 5명 시절부터 8명, 현재의 16명이 된 팀이 된 경우인데, 도구를 도입하고 싶은 경우 도입 했던 경험을 쓰려고 한다. 사실, 현재 속해 있는 팀원들이 모두 도구나 프로세스 도입에 대해서 보수적인 팀이 아니다 보니, 도구를 도입하는 것은 어렵진 않았다.
책임만 지면 된다.
도구를 도입 하는 것에 대해 내가 느낀 세 가지가 있었다. 그리고 문화 도입에 대한 생각을 정리 해보았습니다.
첫째로는 내가 그 도구를 잘 아는가?
일단, 내가 도입하고 싶은 도구가 뭔지? 그리고 그 도구가 왜 필요한지를 알아야 한다.
예를 들어서 내가 했던 일이 입사 이후 부터 지금까지 서버 관리 업무가 주로 있었다. 메인 역할은 아니지만, 서브로 항상 존재 해 왔는데, 예전에도 발표를 했던 적이 있지만, 예전 방식이 너무나 불편하고 수동으로 해야 하는 점이 수고스러워 서버 설정 관리를 자동으로 동일하게 할 수 있는 툴을 도입 해야겠다고 생각 했다.
중요한 건, 나는 내가 하는 업무가 더 잘 되길 바랐다. 그래서 조사를 했었다. 서버 설정을 편리하게 잘 할 수 있는 것들이 무엇이 있을까?
Chef
Puppet
Ansible
위의 툴들이 모두 프로비저닝 툴에 대표 툴들인데, 나는 사내의 시스템과도 잘 맞을 수 있는 Ansible 이라는 툴을 더 찾아 보았고, 책을 주문하고 튜토리얼을 경험 해보니 괜찮았다. 그래서 해당 도구를 도입 하기로 선택했다. 그 외 나머지 도구들에 대해서는 왜 Ansible보다 덜 좋은지에 대해 찾았고, 사람들에게 설명 했다.
결국에는 내가 편하자고 도입한 도구이고, 도움은 정말 많이 되었다. 물론, 문제점은 존재 했다.
둘째로는 그 도구를 도입하여, 얻게 될 이점은 무엇일까?
도구를 도입하는 것에 대해서는 당연히 이점이 있어야 한다.
이점이 없다면 도구를 배우고 활용하는 러닝커브의 비용을 설명 할 수 없다.
결론적으로 그 도구가 왜 좋은지? 어떻게 해서 이 팀에 도움이 되는지를 명확하게 설명할 수 있어야 한다.
결코, 내가 그 도구의 마스터 클래스에 도달 할 필요는 없다.
그냥, 지금 있는 환경에서 보다 더 나을 것 같은 도구라는 판단이 되고,
사용 해보니 도움이 된다면 도입 하는 전략이 나는 좋다고 생각 한다.
물론, 팀 사람들이 그 도구에 찬성 하지 않을 수도 있다.
그렇지만, 일정 부분 동의를 한다면, 도입 하는 것이 좋다. 어차피 책임은 내가 지게 된다.
그런데, 모두가 반대 한다면, 그것은 나의 아집 일 수 있으니 구분을 잘 하도록 하자.
실무에서 써 보지도 않고, 이걸 잘 한다고 할 수 있을까? 실무에서 쓴다고 해도 잘 아는 것도 아니며, 잘 하는 것도 아니다. (방심하지 말자) 그리고 팀 사람들 중에는 그 도구에 별 관심이 없는 사람도 있게 마련이다. 팀은 규모가 커질 수록 사용하는 도구는 많아 지고, 담당하는 역할이 나뉘게 된다. 고로, 팀 내에 도구를 도입한다는 것은, 무관심과 동의속에서 무언가를 얻어내야 하는 일련의 내가 원하는 것을 얻어내는 과정이다.
셋째로는 다른 사람도 그 도구를 잘 쓸 수 있게 만들 수 있을까?
그런데 문제는 나만 그 도구를 쓰게 되는 것이 문제가 될 수 있다.
일련의 자동화 된 시스템이라면, 한 번 구축 후에 유지보수 할 일이 없지만 만약, 지속적인 유지보수를 해줘야 하는 도구들이라면 이야기가 달라진다.
그럼, 나는 팀 내의 다른 사람에게 그 도구를 잘 쓸 수 있도록 도움을 주어야 하고 가이드를 해야 한다.
나에겐 그에 대한 책임이 있다.
그럼 내가 그렇게 할 수 있는지에 대한 부분을 생각 해야 한다.
팀 내 사람들이 찬성 했다고 해서, 도구만 도입 한다고 해결 될 문제가 아니다. 결국, 내가 A/S를 잘 해야 하고, 팀원을 위한 교육도 해야 한다는 것이다.
어떻게 생각해보면, 도구를 도입 한다는 점이 어쩌면, 개개인에게는 장기적인 손해일지도 모른다는 생각을 할 수도 있겠다. 그렇지만, 팀 내의 사람이 많아질 수록 그 도구에 관심 없는 사람과 있는 사람이 나뉘게 된다.
관심 있는 사람들이 도입한 도구에 대한 담당 그룹이 되면 된다.
그리고 도구를 많이 도입 한 사람일 수록 커뮤니케이션에 대한 스킬도 늘고, 도구에 대한 기술에 대해 잘 알게 된다.
그래서 기왕이면, 좋다고 생각 되는 도구들을 팀에 잘 정착시키는 일들을 하는 것이 개인의 개발자 경험으로써는 남는 게 많지 않을까? 싶다.
그리고, 추가적으로 쓰자면, 무분별하게 도입하는 것은 반대다. 좋다고 해서 그 모든 것들이 팀에 맞는 것은 아니기 때문이다. 그러니 적당한 도구를 도입하기 위해 고민 해보자.
팀에 문화를 도입 하고 싶은 경우
도구를 도입하는 것과 문화 혹은 프로세스를 도입하는 것은 차이가 있다.
그 이유에 대해 말해 보고자 한다. 예시는 애자일 문화에 대한 이야기이다.
내가 속한 조직은 서비스 개발 팀이다.
결국, 일정이 개발자의 니즈에 따라 결정 되지는 않는 경우가 많다.
사업적인 이슈, 제휴적인 측면, 기획적인 측면에 따라 일정은 고정 되어 있다. 그러한
일정은 개발자가 마음대로 조율 할 수 없는 환경임을 인지하자.
올해, 팀에서 경험하고 있는 부분이다. 팀에 올해 애자일 프로세스 방식을 작게 도입하게 되었는데, 내가 속한 회사의 업무 스타일이 아니다. (모두가 원활한 목표를 위해서는 관련 된 모든 직무의 사람들의 이해가 뒷받침 되어야 하고, 이미 같이 그러한 문화에 동참하고 있어야 오해가 적지 않을까?와 같은 생각을 했다.)
어쨌거나, 작게 시작하기로 했으나, 애자일에 관련 된 부분들이 다양하긴 하지만
스프린트 도입, 데일리 스크럼, 스프린트 회고, 플래닝들에 대한 부분들을 진행하고 있다.
물론, 애자일 프로세스는 도구를 이용하여 수치를 정확하게 정량적으로 계산 할 수 있는 도구의 도움이 필수적일 수도 있지만, 사람마다 애자일 프로세스를 어떻게 보느냐? 에 대한 관점이 다를 수 있다.
그런데, 애자일이 무얼까. 내가 생각 하는 애자일과 팀 내의 사람이 생각하는 애자일의 이해도가 다를 수 있고, 목표 지향점이 다를 수 있다.
내가 생각하는 애자일 프로세스는 공유 + 성장이다. 당연히, 프로덕트를 개발 하는 조직이라면, 애자일 프로세스가 정말 딱 들어 맞을 수도 있다. (내 생각이 틀렸을 수도 있다.)
그런데, 서비스 개발이라는 특성이 있는데, 아니, 회사의 특성이랄까? �그런 부분들이 아쉬울 때가 있다.
내가 생각하는 애자일 프로세스의 핵심은 공유, 성장이라 데일리 스크럼과 회고가 참 좋다고 생각 한다.
(이게 애자일의 근본이 아닐 수 있음에 주의 하자. 난 애자일을 잘 모른다.)
팀의 사람이 적을 때는 사실, 누가 말 안해도 누가 무슨 일을 하는지 대강 알 수 있다. 그런데, 팀의 사람이 배수로 늘다 보니, 코드가 굉장히 빠르게 바뀌는데, 누가 무슨 일을 하는지 모른다.
그리고, 어떤 스펙이 왜 이렇게 바뀌었는지? 나도 모르는 사이에 바뀐다.
고로, 데일리 스크럼이 필요해졌다. 왜냐하면 공유가 잘 되어야 하기 때문이다.
공유가 안되면, 서비스는 장애가 발생 한다.
수 개월 진행하면서 느낀 점은 그랬다.
애자일 프로세스의 공유가 업무 클라이언트(기획자, 혹은 고객등)간의 공유이기도 하지만, 나는 애자일 프로세스의 공유에서 제일 중요한 점은 개발자 간의 공유가 제일 중요하다고 생각 한다.
결국, 서비스는 개발자에 의해 발전 되어 가고, 동시에 녹슬기도 한다. 그런 양날의 검 같은 이슈 사이를 건너는 개발자들이 합이 잘 맞으려면, 공유가 기본이다.
그런데, 내가 생각하는 공유는, 이 일을 하고 있다 너머의 내가 이런 이슈를 만났는데, 헤매고 있다면, 누군가에게 알리고 다른 사람들도 그런 이슈를 같이 해결 하려고 노력하는 그림을 말한다.
그리고, 생각보다 기술적인 이슈 보다 서비스 도메인 측면의 이슈가 있을 수도 있기 때문에 개발자 간의 공유가 중요하다.
이 모든 것들은 팀 내의 수준 합의가 필요하다. 어떤 문화를 도입하는 것에 대해서 모두 포용할 것인지? 아니면 작게 포용할 것인지?
문화를 도입하는 것은 행동을 변화 시키는 일이다. 결국, 누군가는 책임을 지는 역할을 분담 해야 지속적으로 행동을 변화 시킬 수 있다.
그 역할은 누군가 계속 해야 하는 것이 아니라 지정제로 혹은 원하는 누군가가 돌아가면서 해야 장점만을 누릴 수 있다.
애자일 문화 도입이든, TDD의 문화 도입이든, 결국 중요한 것은 행동을 변화 시키는 일은 굉장히 어렵고 사람마다 이해도와 목표 지향점이 다를 수 있는데, 이를 잘 협의 하는 것이 중요하다.
이런 것들을 잘 생각 해보아야 한다.
사람들의 이해도가 다를 때 어떻게 할 것인가?
사람들 개개인의 목표 지향점이 다를 때 어떻게 할 것인가?
두 물음에 답을 할 수 있을 때에 팀 내에 문화를 도입 하는 것이 좋겠다.
결론적으로 쉽지 않지만, 도전은 언제나 좋다.
