우리 팀의 근무 수칙
에어비앤비 페이먼츠 엔지니어링
며칠 전 팀 매니저가 보낸 우리 팀의 근무 수칙을 발췌, 번역하였다. 지금은 당연하게 보이는 원칙들이지만 실리콘밸리에 처음 와서 이런 가이드라인을 봤을 때에는 정말 충격적이었다.
Team Working Guidelines
원칙
Principles
1. 위급하고 중대한 사고가 아닌 경우에는 누구도 야근을 하거나 주말에 일을 해야 한다고 느껴서는 안된다. 긴 근무시간과 개인 건강을 희생하면서 일을 하는 것에 적극적으로 반대한다.
I want to state unequivocally that no one should feel obligated to work on nights or weekends outside of critical and urgent incident response. I am actively against building a culture where engineers are pressured to work long hours, sacrificing their health and well-being.
2. 자율적이고 탄력적인 근무 시간을 존중한다.
I recognize that a flexible working schedule is important and that some engineers may want to work outside normal business hours.
3. 근무시간 외에 일하는 것을 선호하는 직원은 보통 근무시간에 일하는 다른 직원들을 존중해야 한다.
Even if you decide that you want to work outside business hours, please acknowledge the ripple effects it can have.
4. 코드 리뷰 요청은 핵심 근무시간(10am-4pm)에만 허용한다. 주말에 코드 리뷰 요청을 보낸다면 다른 직원에게 일을 강요하는 것과 마찬가지이다. 코드 리뷰를 해주는 직원과 주말 근무에 대해 합의가 되었어도 그 외의 직원들이 코드 리뷰를 하지 못하는 문제가 발생하므로 주말에 코드 리뷰를 보내는 것을 금한다.
If you put up a PR on a weekend, and request a 'PTAL' on it, you obligate your teammate to work too. Even if both you and a reviewer have agreed to work on the weekend, we still have the issue that other developers miss the opportunity to comment on the PR and be involved in crucial decisions.
5. 서버 업데이트도 핵심 근무시간 내에만 허용한다. 만약 코드 디플로이가 서버에 문제를 야기한다면 동료들이 근무시간 외에 사고 해결을 위해 일을 해야 하기 때문에 근무시간에만 서버 업데이트를 하도록 한다.
It follows that there are similar ripple effects when deploying changes. For example, if you deploy a change to a service that either causes that service to degrade or another dependent service to degrade, you potentially obligate your teammate to respond to the incident.
업무 가이드라인
Guidelines
1. 사고 대응 시 On-call incident response
- 감당할 수 없으면 지원을 요청한다. Ask the team for support at any point if they are feeling overwhelmed
- 새벽에 대응한 경우 충분히 잠을 보충할 수 있도록 한다. (잠을 자야 할 시 회사에 나오지 않아도 된다.) Take recovery time for any lost sleep (i.e. sleep in if needed)
- 포스트모르템을 반드시 쓴다 (포스트모르템에 대한 설명: https://brunch.co.kr/@svillustrated/13). Write post-mortem report, including actions for the team to prevent similar incidents
2. 비현실적이고 타이트한 데드라인 Aggressive or unrealistic deadlines
- 고객들과 자주 만나서 데드라인을 조정한다. Meet early and often with stakeholders to set expectations
- 데드라인을 계획할 때 합리적으로 자원을 계획한다. Take resources into account when planning deadlines
- 내부적으로는 낙관적으로, 외부에는 보수적으로 타깃 날자를 지정한다. Establish optimistic internal target dates and conservative external targets
3. 동료의 압박 Social pressure from peers
- 10시부터 4시까지 핵심 근무 시간에만 대답을 기대한다. Establish “core hours” between 10:00 am - 4:00 pm when we can expect our teammates to be working
- 근무시간 외에는 메신저보다 이메일을 활용한다. Favor asynchronous communication or collaboration methods, especially outside core hours
이러한 근무 수칙은 장기적으로 지속 가능한 개발 환경을 만들기 위한 노력의 일환이다. 처음에는 프로젝트 하나하나가 타이트한 데드라인을 가지고 따로 발주되는 사고방식에 젖어 있어서 이러한 원칙들이 이해가 가지 않았었다. 그런데 장기적으로 계속 진화하는 소프트웨어를 만드는 애자일 방식으로 몇년간 개발을 경험한 후에는 이러한 원칙이 지켜지지 않으면 거의 재앙과 같은 결과가 온다는 것을 체득하였다.
이러한 원칙을 지키지 않고 짧은 시야를 가지고 개발을 무리해서 진행한 팀은 단기 개발 후에 엔지니어들이 다 팀이나 회사를 떠나고 성급하게 만들어진 버그 많은 코드만 남았다. 애자일 개발에서 번아웃은 생각보다 심각한 문제였다.
