우리 회사의 문화는 무엇 인가에 대해 정의하기 위해 미팅을 요청 주셨다.
조사해주셨던 내용 중 기억에 남아있는 건
- 문서화 (Documentation)
- 페어 프로그래밍 (Driver & Navigator)
- 워크숍 (Sharing the knowledges)
- 사내 스터디
- 코드 리뷰
이런 게 있었다.
우리 회사는 어떤가에 대해 얘기했었는데, 회사의 개발자가 많지만 팀별로 적게는 4명부터 8명까지 다 달랐고 우리 팀의 경우 2명으로 시작해서 2명에서 리뷰를 주고받았었던 게 다양한 사람들로부터 리뷰를 받다가 lead-developer 분이 합류하시고 Business Logic과 관련 없지만 Code Quality 나 방향에 대한 리뷰를 보통 주셨다.
한 분은 막 팀에 합류하셨지만 이해하고 있는 부분에 대해서는 리뷰와 승인을 주셨었다. 회사 내 다양한 더 다양한 사람들로 공감을 받으면 좋겠다고 느꼈지만 팀 내 구성원들이 공감하고 만족하는 코드라고 생각했다.
페어 프로그래밍은 초기에 클라이언트/서버 각자 자기가 더 자신 있는 분야가 있는데 둘 다 알아야 하는 팀의 경우 유익해 보였고,
문서화는 Confluence에 작성을 하고 label로 outdated나 domain관련 tag를 다시는 분도 계셨고 팀이 자주 바뀌거나 공유해야 할 내용이 자주 바뀌는 팀의 경우는 Miro에 대부분의 내용을 갖고 있는 팀도 많아 보였다.
어떻게 하던 팀에게 어느정도 권한을 주고 원하는 대로 하는 방식이 마음에 들었었다.
물론 모두가 만족하지는 않았을 수도 있어 보였다. 검색의 용이성 때문에 Confluence에 작성을 강력하게 원하시는 분들이 많으셨지만, 처음 팀에 합류한 분과 Remind 하기에는 Miro가 시각적으로 훨씬 자연스럽고 이해도가 높았다.
내가 답변한 우리 회사의 문화는 좋아보이는 기술과 방법이 있으면 굉장히 자유롭게 선택할 수 있었다. 그 내용을 공유하고 더 좋은 방향으로 나아가는 방법을 시니어분들이 좋아하셨고 이 문제로 인해 Issue가 발생하면 기존엔 많은 시니어분들이 같이 Pair로 공유받으며 책임을 분담해 주셨다. 이보다 더 좋은 개발 문화가 있을까 싶은 게 내 생각이었다.
최근엔 심지어 나만 알고 있는 domain을 공유할 수 있는 pumasi 채널이 생겨 서로서로 도와주는 모습도 좋았다.
너무 대화가 없어서 스몰톡, 서로를 소개하는 너의 이름은 그리고 Gather town을 활용한 각종 행사까지 좋은 문화를 경험할 수 있는 회사였다.
