Unknown Artist

작자 미상(未詳): 여기서 미상은 불분명하다는 의미다. 작가를 알 수 없는 것이 여러 의미를 갖겠지만, 누가 만들었는 지 상관없이 작품이 의미가 있어야 한다는 의미를 말하고 싶다. 작자 미상은 작가가 누군지 모르기 때문에 작가의 의도를 물어볼 수 없는데, 소프트웨어를 만든 사람에게 물어볼 필요 없이 잘 작동하도록 설계하는 것이 중요하다고 생각해서 작자 미상이라는 특징을 언급하고 싶었다.
 
운영을 하다보면 만든 사람이 직접 해결해야 하는 문제들이 생긴다. 그래서 온콜(On-call)^[각주:1]을 하게되는데 온콜이 의도와 다르게 변하는 것을 보았다. 먼저, 온콜과 런북(Runbook)^[각주:2]을 활용하여 절차에 따라 긴급 장애에 대응하는 방식으로 발전하기보다, 서비스가 파편화되어있고 복잡하기 때문에 만든 사람만이 해결할 수 있다는 이유로 단순히 긴급하게 담당자를 찾는 절차에 머물러서 안타까웠다.^[각주:3] 또 다른 안타까운 상황은, 신입 엔지니어들이 상대적으로 시스템과 서비스에 대한 이해가 부족해서 실수를 할 수 밖에 없었고, 결국 연차가 오래된 선임을 온콜로 불러내어 문제를 수습하는 것이 반복되는 상황이었다.^[각주:4]
 
좋은 소프트웨어를 만드는 단 한 개의 원칙을 선택하라고 한다면, '내 손을 떠나도 동작해야 한다'^[각주:5]를 말하고 싶다.

---

 

1. On-calls [본문으로]
2. Runbook [본문으로]
3. 페이징을 받으면 임계값 기준에따라 미리 정의한 장애 수습절차를 수행해야 하는데, 실전에서는 'System error 50건 이상'이라는 메시지를 받는 것을 봤다. 로그를 분석하고 원인을 찾고 결과에 따라 해결하거나 다른 팀을 호출하는 방식은 체계적이지 못하다. [본문으로]
4. 이런 상황이 반복되면 주니어 엔지니어의 자존감이 하락하고 퇴사율이 높아진다. 선임 엔지니어들도 번아웃(Burn-out)이 올 수 있다. [본문으로]
5. 'Software Release'라는 단어가 있는데, Release는 손을 떠났다는 의미가 들어있다. [본문으로]