AWS IAM, 칸반보드, 페어 프로그래밍, 팀 프로젝트에 가장 필요한 것을기록
AWS IAM
내 AWS 계정에는 MFA를 걸어놨다. AWS 협업을 위해서는 다른이들에게 권한을 부여해야한다.
이 과정은 그리 어렵지않다. 먼저 Aws User를 생성하고 해당 User들을 UserGroup에 옮기고 권한 설정을 해주면 된다. 필요할 때마다 IAM 설정을 건드려주면 되겠다. root계정을 모두가 사용하는 것은 위험하므로 이 과정은 필수라고 생각한다. 그리고 AWS configure의 경우도 Access Key와 Secret Key을 root계정 것으로 한번에 작업을 하는 것이 아닌 필요할 때마다 맞춤형으로 생성해서 사용한다.
Github 칸반보드
지속적인 의견 Push 유도와 프로젝트 기록을 위해 Github 칸반보드를 활용한다. 칸반보드를 활용하면 좋은 점으로 우선 프로젝트가 지금 어디쯤 있는지 진행 과정을 한 눈에 알아보기 싶다. 또한 자신이 어떤 단계에 있다는 것을 인지하기 쉽고, 본인의 기여도 또한 알기 쉬워서 어떨 때 보면 동기부여가 될 수도 있겠다.
페어 프로그래밍
예전에 페어 프로그래밍을 했을 때는 이걸 왜하지? 싶었다. 시키는 대로 했지만, 공부란 걸 같이해서 좋은 점을 잘 몰랐다. 하지만 애자일에서 페어 프로그래밍을 하라는 이유를 이제 와서 깨달았다. 우선 동질감이 생긴다. 무언가 함께하고 있다는 느낌은 동기를 부여하기에 충분하다.
그리고 내 생각에 가장 중요한 이유는 참여 강제성에 있다. 페어 프로그래밍을 하게 되면 결국 모두가 일정 시간을 투자해야 한다. ‘서당 개 3년이면 풍월을 읆는다’는 속담이 있듯 그들이 시간을 쓰는만큼 알게 모르게 무언가를 배우게 된다. 또 만약 개인별로 프로젝트나 공부를 한다고해보자, 그럼 말그대로 본인 자유다. 하기 싫어서 안하거나 우선순위가 뒤로 밀려날 수도 있다. 이러한 상황은 단순 공부 정도면 본인 인생이기 때문에 나중으로 미룰 수 있지만 기간이 임박한 팀프로젝트의 경우에는 치명적이다.
그래서 애자일 원칙 중에서 날마다 함께 일하라는 것 같다.
팀 프로젝트에 가장 필요한 것
나는 다른 건 다 못하지만 누군가가 나에게 딱 하나만 자부해보라고 하면은 사람 성향을 잘 파악한다고 말할 거다. 현재 프로젝트의 공식 일정은 주 1회 오프라인으로 진행된다. 짧은 일정인 만큼 회의 과정에서 프로젝트에 관한 무언가의 결정이 원활히 이루어져야 한다는 의미이다. 내가 생각하는 스터디와 프로젝트의 차이는 의견 교환에 가장 큰 비중이 있다고 생각한다. 스터디의 경우 만나서 각자 공부한 내용을 공유하지만 프로젝트는 도움이 되는 내용과 의견 교환이 필수적이다. 잘 모르는 내용을 맡게 된다면 주장이 가능할 만큼 조사를 해야 한다. 결국 프로젝트에는 불가피하게 책임감이 필요하다.
그동안 내가 해온 프로젝트를 되돌아보면 왜인지는 잘 모르겠지만 자의 반 타의 반으로 PM역할을 항상 맡게 되면서 팀원들의 능동적인 참여 유도와 원활한 프로젝트 마무리 방법을 항상 고민했던 것 같다. 갑자기 그 상황들을 글로 써보고 싶어졌다.
내가 프로젝트들을 진행하면서 경험한 팀내 문제사안들은 대부분 다음과 같은 케이스였다.
- 프로젝트 과정에서 본인의 주장을 만들지 못하는 팀원이 생김
- 팀원들 간 의견 마찰
- 책임감 부재
1번 케이스의 경우는 평소 주장을 하는데 익숙하지 않거나, 지식부족으로 인해 프로젝트에 자신감이 없어 주장을 못하는 사람들이다. 평소 주장을 하는데 익숙하지 않은 사람이라 판단이 되면, 우선 나는 그사람이 최대한 편안함을 느낄 수 있는 분위기를 조성하려고 했다. 또한 충분히 편안함을 느낀다고 판단이 되면 질문을 통해 자연스럽게 능동적인 참여를 이끌어 내기 위해 노력했다.
또 다른 부류로서 지식의 부재로 프로젝트 참여에 자신감이 없는 사람에게 가장 말해주고 싶은 것은 ‘본인이 현재 놓인 상황을 잘 인지하고 개선할 방법을 생각해보는 시간이 필요하다’ 이다. 당연히 모든 걸 다 알고 있는 사람은 굉장히 드물다. 다만, 본인이 부족한 점이 있다는 걸 인지했으면 그걸 개선하기 위한 방식을 생각해봐야한다. 이 방식이란게 사람마다 맞는 방식이 다 다를것이므로 하나를 추천하기가 참 애매하다. 잘하는 팀원이 있다면 어떻게든 뽑아먹거나 친해지려 노력하는 사람, 본인이 밤을 새워서라도 역량을 키우는 사람 등 본인에게 맞는 개선책을 세워야 한다. 적절히 섞을 수도 있을 것이다. 하지만 이를 행동으로 옮기는 사람도 참 드물다.
2번 케이스는 팀원들 간 주장이 과해 감정이 상한 경우이다. 실제로 프로젝트를 하면서 우는 사람도 봤고, 비난을 하는 사람도 보았다. 사실 본인들이 그린 그림과 다른 의견으로 갈 때 자주 일어나는 일이다. 개인적으로는 욕심이 많은 사람을 싫어하지는 않는다. 어쨌거나 열심히 하려는 사람이라는 생각이 들기 때문이다. 그래서 프로젝트를 하면서 가끔 언성이 커지는 모습을 보고 있자면 팀에 긴장감이 도는 걸 느끼지만, 어쩔때는 조금 변태처럼 나름 기분좋을 때도 있다. 다만 이런 케이스가 일어나는 근본적인 문제는 본인의 주장에 다른사람이 이해하고 납득할만한 근거가 부족하기 때문이라 생각한다. 결국 상대가 억지를 부리는게 아니라면 준비를 제대로 못 한 본인 잘못도 있는 것이다. 목소리가 점점 커지는 팀원이 있는 경우, 조용히 다른 장소에 데려가서 해당 주장에 이런 부분이 부족한 것 같아서 다른 팀원이 공감하기 힘들었던 것 같다는 부류의 말을 자주 하곤했던 것 같다. 그러면 대부분이 다 감정이 사그러들었던 것 같다. 납득하지 않았을까.
사실 내가 경험해본바로는 3번 케이스가 제일 난감하다. 책임감의 부재는 당황스럽기도 하다. 왜냐하면 누군가 등떠민게 아닌 자발적인 참여라는 생각이 내 기저에 항상 깔려있기 때문이다. 이런 케이스의 팀원은 1번 케이스의 지식 부재로 인한 자신감 하락과 상당히 유사한데, 차이점이라고 하면 항상 본인만의 사정이 존재한다. ‘어떤 일때문에 이걸 못했어요’라는 늬앙스를 열심히 내뿜곤 한다. 그래서 이들에게는 지식 부족에는 개선하기 위한 방식을 생각해야 함을 강조함(1번 케이스처럼)과 더불어 하나를 덧붙인다. 나는 그들에게 물어보곤 한다. 프로젝트를 하고 싶은 마음이 존재하는지, 본인의 역할을 잘 인지하고 있는지 등등 스스로 메타인지를 하게끔 한다. 누구나 누군가에게 척지고 싶은 마음은 없기에 나로서도 나름 큰 마음을 먹는 순간이다.
앞으로 어떻게 해야할지 선택지를 주면서 본인이 선택해야 하고 그 선택에는 책임이 있어야 한다고 얘기한다. 결국 나는 그들에게 시작부터 끝까지 본인의 선택이었음을 애둘러 표현한게 아닐까.. 지금에 와서는 그런 생각이 든다.
쓰다보니 말이 길어졌지만, 결국 중요한 것은 프로젝트 안에서 역량을 펼치는 것 외에도, 팀 프로젝트라고 하면 본인의 기여도를 올릴 방안을 생각해야 한다. 본인의 변화뿐만 아니라, 필요하다면 팀적인 협업시스템에 관한 어려운 점도 얘기하고 또 개선방안을 얘기할 수도 있을 것이다. 가만있으면 바뀌는 것이 없다. 이렇게 보면 팀 프로젝트는 참 생각할 게 많긴 하다. 그래서 팀플이 재밌다.